| 01:51.53 | *** join/#asterisk-doc cvschleich (n=cvs@65.127.122.56) |
| 01:52.10 | *** part/#asterisk-doc cvschleich (n=cvs@65.127.122.56) |
| 01:56.20 | *** join/#asterisk-doc jsmith (n=jsmith@000-193-159.area3.spcsdns.net) |
| 01:56.20 | *** mode/#asterisk-doc [+o jsmith] by ChanServ |
| 04:37.03 | Juggie | blitzrage: ping |
| 12:27.15 | blitzrage | morning all! |
| 12:29.25 | blitzrage | file: woh --- March 30th is the final date to send the presentation for inclusion in the CD proceding |
| 12:31.19 | *** join/#asterisk-doc jsmith (n=jsmith@000-193-159.area3.spcsdns.net) |
| 12:31.19 | *** mode/#asterisk-doc [+o jsmith] by ChanServ |
| 12:37.25 | blitzrage | jsmith: !!! |
| 12:37.40 | blitzrage | Happy Saturday! |
| 14:32.30 | *** join/#asterisk-doc Juggie (i=Juggie@CPE00c049d9f271-CM000a73a18a20.cpe.net.cable.rogers.com) |
| 17:39.33 | *** join/#asterisk-doc jsmith (n=jsmith@000-193-159.area3.spcsdns.net) |
| 17:39.33 | *** mode/#asterisk-doc [+o jsmith] by ChanServ |
| 17:39.49 | file | yay jsmith |
| 17:40.09 | jsmith | Hey file... |
| 17:53.45 | blitzrage | welcome to the weekend jsmith |
| 17:54.30 | jsmith | Thanks |
| 18:24.14 | jsmith | Time to hack on docs |
| 18:24.18 | jsmith | (finally!) |
| 18:40.09 | blitzrage | jsmith: suggestion for a good application in gnome that I can use to record something from a mic? |
| 18:40.26 | blitzrage | I'm having issues with my mic working into applications, and wanna test recording into another application |
| 18:40.35 | jsmith | Did you try audacity? |
| 18:40.54 | blitzrage | so strange, I can hear the mic through the speakers if I unmute it in the mixer, but not into apps |
| 18:41.02 | blitzrage | ahhh... audacity, couldn't remember the app name |
| 18:52.13 | Juggie | blitzrage, has that patch kept working |
| 18:52.25 | blitzrage | so far so good |
| 18:52.29 | blitzrage | no crashes or anything |
| 18:52.35 | blitzrage | let me leave a VM to test |
| 18:52.44 | Juggie | meh, nothing was changed that could cause a crash. |
| 18:52.49 | Juggie | its too simplistic for that |
| 18:52.49 | blitzrage | you never know :) |
| 18:52.53 | blitzrage | haha |
| 18:53.12 | Juggie | did you post it |
| 18:53.33 | blitzrage | it works :) |
| 18:53.36 | blitzrage | haven't posted yet |
| 18:53.46 | blitzrage | honestly, it probably doesn't need to go on the bug tracker |
| 18:53.57 | Juggie | i didnt think so either but you thought so yesterday |
| 18:53.58 | blitzrage | because the reason for the patch will be resolved in 1.6 |
| 18:54.09 | blitzrage | yah, I changed my mind in further consideration |
| 18:54.27 | blitzrage | the event branch is basically going to resolve the issue that patch resolved |
| 18:54.38 | Juggie | it should be hopefully yeah.. BUT the event system still wont solve the dis-contunity between * and SER |
| 18:54.40 | blitzrage | but it probably could go into an asterisk patch repo |
| 18:54.56 | blitzrage | hrmmm |
| 18:55.04 | blitzrage | unless the event system becomes a push system |
| 18:55.09 | blitzrage | I need to talk to Russell about this |
| 18:55.21 | blitzrage | make sure it will solve the issue, and if not, figure out if this is the first approach to that |
| 18:55.28 | Juggie | the event system is for communication between asterisk modules. |
| 18:55.43 | blitzrage | right, but there is an MWI so chan_sip can subscribe to a voicemail box in app_voicemail |
| 18:55.56 | blitzrage | I guess that doesn't mean chan_sip becomes push |
| 18:56.00 | Juggie | there are a number of ways you could approach it. |
| 18:56.02 | blitzrage | so maybe I need to talk to oej |
| 18:56.17 | Juggie | you could just have app_voicemail post the event |
| 18:56.18 | blitzrage | what we really need to figure out is what the approach is to resolve this for 1.6 |
| 18:56.28 | Juggie | or you could have chan_sip subscribe to the events for the mailbox it wants |
| 18:56.45 | Juggie | either way the goal of the event system is to send a 'hey i have a message for mailbox whoever to the channel driver that needs to know |
| 18:56.53 | blitzrage | well, from what I can tell, that is what Russell is building in the event system |
| 18:56.57 | Juggie | right. |
| 18:57.03 | Juggie | but that still doesnt solve your problem |
| 18:57.06 | blitzrage | right |
| 18:57.16 | Juggie | your problem is that you dont know the state of the phones. |
| 18:57.16 | blitzrage | the issue is when to send a NOTIFY |
| 18:57.18 | blitzrage | right |
| 18:57.25 | Juggie | hmmmmMMMMMMMMMmmmmm |
| 18:57.36 | Juggie | would it be possible for you to pass registration requests on to asterisk |
| 18:57.36 | blitzrage | so how do we solve *that* issue |
| 18:57.42 | blitzrage | well, not really |
| 18:57.46 | Juggie | didnt think so |
| 18:57.56 | blitzrage | that's a scalabilty issue really |
| 18:58.03 | blitzrage | because calls are distributed to several asterisk boxes |
| 18:58.21 | blitzrage | assume asterisk cannot know the phone status.... |
| 18:58.26 | Juggie | right |
| 18:58.31 | Juggie | and the event system wont change that. |
| 18:58.57 | blitzrage | agreed |
| 18:59.04 | Juggie | now, if you got subscribes working. |
| 18:59.06 | blitzrage | so we're back to what you and Kristian were talking about yesterday I guess |
| 18:59.19 | blitzrage | I think that's the real approach |
| 18:59.20 | Juggie | it may be possible that if you re-subscribe to MWI that asterisk will resend the last mwi status. |
| 18:59.23 | blitzrage | so I gotta make the phone subscribe |
| 18:59.39 | Juggie | or make SER subscribe for the phone |
| 18:59.42 | blitzrage | well, basically, if the phone polls for status when it wants, then that SUBSCRIBE is passed to Asterisk |
| 18:59.44 | Juggie | on a registration to ser. |
| 18:59.56 | blitzrage | all SER does is take wahtever the phone sends to it and passes it to an asterisk box |
| 19:00.03 | blitzrage | oooo |
| 19:00.06 | Juggie | something like that, i am not sure how subscribe works. |
| 19:00.10 | blitzrage | yah, SER could subscribe for the phone |
| 19:00.15 | blitzrage | then its not device dependant.... |
| 19:00.16 | blitzrage | hrmmmmmm |
| 19:00.21 | blitzrage | that's an interesting approach :) |
| 19:00.36 | blitzrage | because SER knows the status of the phone |
| 19:00.47 | Juggie | i dont know exactally how subscribe works, you would need to talk to olle perhaps |
| 19:00.47 | blitzrage | so it only has to poll for those phones that are registered (devices registered) |
| 19:00.51 | blitzrage | ya |
| 19:05.38 | jsmith | blitzrage: I think that's going to fail, and here's why |
| 19:05.58 | blitzrage | jsmith: sure, I'm for all ears in the discussion! |
| 19:06.03 | jsmith | blitzrage: SER only acts based on packets coming in... it's can't go out and send SUBSCRIBES on its own (at least the way I understand it) |
| 19:06.18 | blitzrage | you're probably 100% right |
| 19:06.21 | jsmith | blitzrage: But! |
| 19:06.41 | jsmith | You could probably use a cronjob + sipsak to send something to SER that would trigger a SUBSCRIBE |
| 19:06.46 | blitzrage | so then, as Juggie suggested in MSN, do I then build a daemon (maybe in PHP or something) that talks to the database and sends the NOTIFYs itself? |
| 19:06.59 | blitzrage | sounds like it :) |
| 19:07.13 | jsmith | Well, either get SER to send them, or write your own daemon. |
| 19:08.03 | jsmith | Yuck -- there goes my working on docs this weekend |
| 19:08.11 | blitzrage | the trick is basically you need to send a NOTIFY when you get a REGISTER, so I guess if you run a daemon, then SER could send it a message when it gets a REGISTER, and then that would trigger the daemon to send a NOTIFY |
| 19:08.11 | jsmith | Just had a client call with a so-called "emergency" |
| 19:08.18 | blitzrage | ewwwwww |
| 19:08.28 | jsmith | Wait... |
| 19:08.30 | file | I like having my apartment room mate working at Superstore... he knows when all of the sales are happening ahead of time |
| 19:08.37 | jsmith | ... That's it! |
| 19:08.45 | file | like small appliances are going on sale in a week |
| 19:08.46 | blitzrage | jsmith: eh? |
| 19:09.11 | jsmith | SER can run on script on REGISTERs... and that script would lookup the VM status (over AMI) and give SER the info it needs for the NOTIFY. |
| 19:09.24 | blitzrage | yes |
| 19:09.28 | jsmith | By golly, I think that might work. |
| 19:09.28 | blitzrage | what would AMI do? |
| 19:09.31 | blitzrage | I think so too |
| 19:09.44 | jsmith | Tell SER how many voicemails (new/old) there were for that phone |
| 19:09.46 | blitzrage | would you need to build a new function to trigger the NOTIFY? |
| 19:09.53 | jsmith | Yup. |
| 19:09.55 | blitzrage | I don't think you even care about that |
| 19:10.02 | jsmith | Sure you do. |
| 19:10.06 | blitzrage | you just say, "I want an update", and the NOTIFY tells you what the current status is |
| 19:10.26 | blitzrage | who cares what the phone used to think it used to know |
| 19:10.29 | jsmith | Well, if SER is sending the NOTIFY to the phone, it's gotta send them "You have 5 messages", right? |
| 19:10.30 | blitzrage | it wants to know the current status |
| 19:10.43 | blitzrage | you look that up in the daemon |
| 19:10.48 | jsmith | No! |
| 19:10.54 | jsmith | I'm saying we don't need a daemon |
| 19:11.00 | blitzrage | or script, whatever |
| 19:11.06 | blitzrage | but the phone isn't going to tell you how many msgs |
| 19:11.09 | jsmith | The script won't be sending the NOTIFY |
| 19:11.09 | blitzrage | and who cares? |
| 19:11.15 | blitzrage | ok, Asterisk will |
| 19:11.21 | jsmith | No, SER will |
| 19:11.25 | jsmith | Let me explain. |
| 19:11.27 | blitzrage | SER will what? |
| 19:11.29 | blitzrage | ok |
| 19:11.31 | jsmith | send the notify |
| 19:11.35 | jsmith | Let me explain. |
| 19:11.40 | blitzrage | the SER is just a switch.... |
| 19:11.49 | jsmith | Step 1: SIP UA registers with SER |
| 19:12.20 | jsmith | Step 2: Before replying with a 200 OK, SER runs a script |
| 19:12.50 | jsmith | Step 3: The script queries Asterisk via AMI to ask "How many VMs for mailbox 123@foo?" |
| 19:13.13 | jsmith | Step 4: Asterisk says "4 new messages, 2 old message, 1 new urgent message, and 0 old urgent messages" |
| 19:13.26 | jsmith | Step 5: The script passes that info back to SER |
| 19:13.33 | Juggie | way to confusing. |
| 19:13.38 | jsmith | Step 6: SER sends out the 200 OK for the register, and then the NOTIFY |
| 19:13.44 | blitzrage | yes, ok, then I agree.... I thought something else |
| 19:13.50 | blitzrage | that's what I was kinda thinking too |
| 19:14.02 | blitzrage | confusing? that's very clear |
| 19:14.04 | blitzrage | that's exactly it |
| 19:14.06 | blitzrage | you got it |
| 19:14.15 | blitzrage | how do you trigger the script though |
| 19:14.17 | Juggie | but why add the extra complexity of quering over AMI. |
| 19:14.28 | blitzrage | I agree -- just look it up in the DB |
| 19:14.34 | Juggie | why not just have SER remember the last notify it got, and spit it back out to any new registrations. |
| 19:14.38 | blitzrage | at least in my sitation, the VM is in the DB |
| 19:14.45 | blitzrage | just run a SELECT statement |
| 19:15.00 | Juggie | every time ser gets a notify for a peer, remember it, overwriting the old one. |
| 19:15.01 | blitzrage | Juggie: I think that's confusing too |
| 19:15.09 | Juggie | if a phone registers, send the same notify again. |
| 19:15.13 | blitzrage | Juggie: too much memory used in remembering stuff, all that data is in the DB |
| 19:15.29 | Juggie | no way, it would be like <1k per peer. |
| 19:15.37 | blitzrage | just build a new NOTIFY on the fly |
| 19:15.41 | blitzrage | why memorize stuff |
| 19:15.49 | Juggie | all you have to do is remember 4 numbers. |
| 19:15.51 | blitzrage | who cares about the previous info, we want the now |
| 19:16.01 | Juggie | because the now is the previous info. |
| 19:16.04 | blitzrage | still -- thousands and thousands of registrations will kill a box |
| 19:16.23 | blitzrage | I disagree -- the now is the current state of the VM box |
| 19:16.34 | Juggie | if asterisk only sends a notify when something changes (as it does) then, you will know the current status. |
| 19:16.52 | blitzrage | SELECT COUNT(messages) FROM voicemessages WHERE mailbox = '100' AND context = 'lmentinc' |
| 19:17.08 | jsmith | blitzrage: SER triggers the script |
| 19:17.09 | blitzrage | aha |
| 19:17.18 | blitzrage | Juggie: you're right -- SER isn't going to know when to trigger the script |
| 19:17.22 | blitzrage | whent he VM changes |
| 19:17.26 | blitzrage | only on new registrations |
| 19:17.26 | jsmith | blitzrage: As part of it's processing of the REGISTER statement |
| 19:17.29 | jsmith | Right. |
| 19:17.42 | blitzrage | right, but if you register 3600s in the future, then you don't know current data |
| 19:17.59 | jsmith | Why would you ever register that long? |
| 19:17.59 | blitzrage | the polycoms let you press the Messages button to look at the number of new messages |
| 19:18.08 | blitzrage | from what I've seen on devices, 3600 is the defult |
| 19:18.26 | jsmith | That's an awful default. |
| 19:18.36 | jsmith | Someting between 180 and 300 is much better. |
| 19:18.43 | jsmith | Especially in fail-over situations |
| 19:19.03 | Juggie | do this: 1) ser gets notify 2) ser remembers 4 message counts for that peer 3) ser passes notify to peer |||| on new registration ser goes, hey, i have mwi for this peer, and builds a notify packet and passes it on after the registration. |
| 19:19.25 | jsmith | SER gets the notify from whom? |
| 19:19.38 | Juggie | the voice mail box. |
| 19:19.41 | blitzrage | jsmith: I think you're right.... easier to just trigger the script to get the current data |
| 19:19.57 | blitzrage | a reasonable re-reg is 120 or so |
| 19:19.57 | jsmith | Juggie: How do you get Asterisk to send the NOTIFY to SER? |
| 19:20.12 | blitzrage | although I don't think the AMI socket is required |
| 19:20.14 | Juggie | jsmith, ask blitzrage, thats how he has it setup now. |
| 19:20.15 | jsmith | Juggie: Also, SER is a *proxy*... it isn't supposed to remember |
| 19:20.18 | blitzrage | the script could just build the NOTIFY |
| 19:20.23 | jsmith | blitzrage: Database or AMI... either way |
| 19:20.28 | jsmith | blitzrage: It sure could |
| 19:20.35 | blitzrage | I guess AMI is useful when not saved in the DB |
| 19:20.49 | blitzrage | for a more all around solution |
| 19:20.54 | Juggie | so what are you going to do, only send out MWI on a registration |
| 19:20.56 | Juggie | thats dumb. |
| 19:21.04 | blitzrage | that's how it works now.... |
| 19:21.07 | blitzrage | afaik |
| 19:21.07 | Juggie | no its not. |
| 19:21.26 | jsmith | Juggie: Your suggestion was just the same... only send the NOTIFY to the end device on REG |
| 19:21.27 | blitzrage | oh ya -- checkmwi |
| 19:21.45 | Juggie | when app_voicemail gets a VM, you send the MWI immeditally if the peer is registered. |
| 19:22.08 | Juggie | it has nothing to do with the reigstration |
| 19:22.14 | Juggie | absolutely nothing. |
| 19:22.16 | blitzrage | ok, I get what you're saying now |
| 19:22.21 | blitzrage | that's why you would store the info |
| 19:22.33 | Juggie | so if the registration is 5min you are going to update MWI every 5min |
| 19:22.36 | Juggie | thats retarded. |
| 19:22.36 | blitzrage | in SER, becauset hen SER knows whether it needs to send a NOTIFY I guess |
| 19:22.58 | blitzrage | but it seems silly to force Asterisk into sending a NOTIFY all the time to SER and to have it do all that logic |
| 19:22.58 | Juggie | and any lower then 5min and you are yoing to super spam your server (not to mention db requests) if you have alot of phones. |
| 19:23.05 | blitzrage | seems heavy on the registration end point |
| 19:23.05 | Juggie | over all, just a bad idea. |
| 19:23.31 | Juggie | blitzrage, if you have SER remember it, then * can work as usual, you woudnt need persistantmwi. |
| 19:23.55 | Juggie | its very simple, get notify, write down message counts, pass to peer. |
| 19:23.58 | blitzrage | when would Asteirsk trigger a NOTIFY? |
| 19:24.07 | blitzrage | whenever a VM box was updated I guess? |
| 19:24.21 | Juggie | * only triggers a notify on, 1) sip reload 2) vm status change 3) new registrations |
| 19:24.25 | blitzrage | but then you don't send a message on a re-reg (i.e. I reboot my phone, and then SER would need to ask for the current status) |
| 19:24.52 | blitzrage | but Asterisk doesn't know about registration, so basically you need the jsmith approach and trigger the script on registration too |
| 19:24.55 | Juggie | well, ser cant ask (unless you can get subscribe working) so the only way for ser to know is to remember the last notify. |
| 19:24.59 | blitzrage | so you need BOTH of your guys solutions :) |
| 19:25.24 | Juggie | no, you just need ser to remember the last status for each peer from *. |
| 19:25.30 | Juggie | and repass it on a new registration. |
| 19:25.46 | jsmith | That requires a custom SER module to write that to a database |
| 19:26.17 | Juggie | doesnt ser already have variables and db functionality? |
| 19:26.36 | jsmith | Well, barely |
| 19:26.43 | Juggie | define barely. |
| 19:26.46 | jsmith | I'm afraid it would need a custom module |
| 19:27.06 | jsmith | Unless you're running the very latest version of OpenSER, variables are difficult |
| 19:28.20 | jsmith | SER is designed to not have to remember anything... it's a proxy right. |
| 19:28.28 | blitzrage | I agree |
| 19:28.30 | jsmith | So there's not much functionality for remembering things across transactions |
| 19:28.31 | Juggie | can ser differentiate between a registration and a new registration? |
| 19:28.34 | blitzrage | I think having SER remember stuff is a bad idea |
| 19:28.39 | jsmith | Juggie: Not that I know of |
| 19:29.26 | Juggie | i dont know SER at all. |
| 19:29.35 | blitzrage | I think the real solution is to make chan_sip trigger a NOTIFY to peers on a new VM to the system, which requires chan_sip to subscribe to an event in app_voicemail. |
| 19:29.54 | Juggie | blitzrage, it already does that. |
| 19:29.55 | blitzrage | or.... |
| 19:29.56 | jsmith | blitzrage: It already does. |
| 19:29.59 | Juggie | you just need a way to rerequest it. |
| 19:30.02 | Juggie | thats the issue. |
| 19:30.04 | blitzrage | only when something is registered |
| 19:30.14 | jsmith | blitzrage: Oh, you mean for a *static* peer. |
| 19:30.14 | blitzrage | it needs to not care about that |
| 19:30.17 | blitzrage | yes |
| 19:30.17 | brac | Oh, you must think that makes people sit there? |
| 19:30.22 | jsmith | blitzrage: Right, that's a bug. |
| 19:30.24 | brac | Right, that's what happens when I want this http://www.amazon.com/gp/product/B00004R91I/ |
| 19:30.24 | blitzrage | no |
| 19:30.28 | blitzrage | not really.... |
| 19:30.40 | blitzrage | code specifically says it won't do that |
| 19:30.52 | jsmith | Why not? |
| 19:30.56 | blitzrage | *shrug* |
| 19:31.04 | Juggie | blitzrage, it says it wont, but it does. |
| 19:31.14 | blitzrage | that's what Juggies patch basically does as far as I can tell |
| 19:31.26 | Juggie | blitzrage, all my patch does is ignore the state. |
| 19:31.29 | blitzrage | but it sends it all the time because it doesn't know the status of the phone |
| 19:31.30 | blitzrage | right |
| 19:31.39 | Juggie | and resend it every checkmwi regardless of if it changed or not. |
| 19:32.10 | Juggie | which eliminates ser having to remember, but causes un-necessairy traffic |
| 19:32.14 | blitzrage | ok so how about this |
| 19:32.32 | blitzrage | actually, question |
| 19:34.16 | blitzrage | why can't the NOTIFY only be triggered by Asterisk when something changes? Mostly because if the phone reboots, then we only tell it the status when something changes -- not ideal. So in order to not worry about that, we send NOTIFY's all the time -- also not ideal. So if we made Asterisk only send a NOTIFY when something changes (why let SER worry about that when Asterisk can just know the info), then the only ot |
| 19:34.16 | blitzrage | her time you need a NOTIFY is when a REGISTER happens... so SER needs to trigger a script or something that says, "This peer re-reg'd, what is the current status" |
| 19:34.43 | Juggie | we can do that. |
| 19:34.53 | blitzrage | that seems to make the most sense to me right now |
| 19:35.03 | Juggie | the reason we did persistantmwi was because that way the peer allways gets the latest mwi info |
| 19:35.14 | Juggie | so if he reboots, he gets it within 30seconds or whatever checkmwi is setto. |
| 19:35.16 | blitzrage | so Juggie, if you change the patch to only send NOTIFY's when something changes between the previous checkmwi and the recent one, we're half way there |
| 19:35.22 | blitzrage | exactly |
| 19:35.31 | Juggie | blitzrage, that what asterisk already does. |
| 19:35.38 | blitzrage | not for static peers though |
| 19:35.42 | Juggie | yes... |
| 19:35.47 | Juggie | you were mistaken, static peers work fine. |
| 19:36.00 | blitzrage | but it wasn't triggering correctly |
| 19:36.07 | blitzrage | oh wait |
| 19:36.11 | blitzrage | it did send the NOTIFY |
| 19:36.29 | blitzrage | sorry, too many thoughts clouding my memory :) |
| 19:36.31 | Juggie | i changed nothing related to that, all the patch changes is the check to see if anything has changed. |
| 19:36.38 | blitzrage | you're right |
| 19:37.02 | Juggie | if you want to work on ser and add the functionality to build a MWI when a phone registers, then persistant mwi is not necessairy. |
| 19:37.53 | blitzrage | basically, SER needs to process the REGISTER, but also send a copy to a daemon to trigger a script to tell chan_sip to send a new NOTIFY |
| 19:38.02 | blitzrage | or... |
| 19:38.16 | blitzrage | could SER send a REGISTER to Asterisk so Asterisk thinks the phone is registered, but at the location of SER |
| 19:38.20 | blitzrage | Juggie: I think you said that earlier |
| 19:38.31 | blitzrage | then handle the Asterisk 200 OK |
| 19:38.53 | Juggie | yes, i did. |
| 19:38.55 | blitzrage | but packets processing would happen as normal because Asterisk would send all other packets to SER |
| 19:39.07 | blitzrage | interesting |
| 19:39.27 | Juggie | on any registration to SER you could have ser fake a registration to asterisk |
| 19:39.31 | blitzrage | Juggie: the issue I was thinking was that SER would just forward the REGISTER packet, which would not work |
| 19:39.46 | blitzrage | but if SER re-wrote the packet so SER was basically registering to Asterisk.... |
| 19:39.47 | Juggie | yah. |
| 19:39.52 | Juggie | indeed. |
| 19:39.53 | blitzrage | bingo |
| 19:40.00 | blitzrage | could it really be that simple? |
| 19:40.09 | blitzrage | that seems like something SER could do |
| 19:40.13 | blitzrage | then it doesn't have to remember anything |
| 19:40.49 | blitzrage | can anyone think of a reason that might not work? |
| 19:40.58 | blitzrage | or is that basically the answer... ? |
| 19:41.08 | Juggie | i dunno, try it :) |
| 19:41.20 | blitzrage | let me call Kristian |
| 19:42.28 | blitzrage | VM.... |
| 19:42.29 | blitzrage | booo |
| 19:42.39 | blitzrage | and it wouldn't even let me leave a VM |
| 19:43.20 | jsmith | BEST IDEA EVER! |
| 19:43.22 | jsmith | No VM! |
| 19:43.34 | Juggie | talk to olle |
| 19:43.38 | Juggie | he would be the person to ask |
| 19:43.39 | jsmith | "Hi! You've reached this message. If it's important, you'll call back" |
| 19:43.46 | blitzrage | lol |
| 19:43.48 | blitzrage | pretty much |
| 19:43.57 | blitzrage | no idea what number I got here though |
| 19:44.08 | blitzrage | Juggie: seems like it wouldn't even require a change to Asterisk.... |
| 19:44.17 | blitzrage | Juggie: or do you mean because he knows OpenSER as well? |
| 19:44.30 | Juggie | well, because using a subscribe may be a possibility. |
| 19:44.47 | blitzrage | yah, but then the end point needs to send the SUBSCRIBE |
| 19:44.58 | blitzrage | I think faking the registration is the least intrusive way of doing it |
| 19:45.12 | Juggie | i dunno, i thought ser could send it... but i have no idea, the reason i said ask olle is he knows the sip protocol |
| 19:45.24 | blitzrage | right |
| 19:45.41 | blitzrage | I think faking the REGISTRATION with SER might just work though.... it'll be interesting to try |
| 19:49.34 | blitzrage | jsmith: nice! |
| 19:49.39 | blitzrage | secret SER expects kick ass |
| 19:49.59 | blitzrage | errr.... experts |
| 19:56.07 | jsmith | blitzrage: OK, so I've got three ideas I'm bouncing off him |
| 19:56.17 | blitzrage | nice! |
| 19:56.20 | jsmith | #1: SER rewrites REGISTERS for Asterisk |
| 19:56.26 | blitzrage | nice one |
| 19:56.28 | blitzrage | :) |
| 19:56.32 | jsmith | #2: SER calls script which queries VM status on reregister |
| 19:56.48 | jsmith | #3: standalone daemon that queries SER db directly and sends it own NOTIFY messages |
| 19:57.04 | blitzrage | I like #1 the best |
| 19:57.12 | blitzrage | it just seems like that's what SER does best |
| 19:57.22 | blitzrage | very SEResque |
| 19:57.58 | *** join/#asterisk-doc bkruse_home (n=kruz@69.73.127.92) |
| 19:58.12 | blitzrage | bkruse_home: !!!!!!!!!!! |
| 19:59.44 | bkruse_home | ! |
| 19:59.47 | bkruse_home | omg blitzrage wuts up |
| 19:59.50 | bkruse_home | how you doin man |
| 20:00.12 | blitzrage | bkruse_home: not much... you've missed a very wicked conversation re: MWI w/ Asterisk+SER integration |
| 20:00.50 | bkruse_home | ohh, ive done that, its not hard |
| 20:00.55 | blitzrage | lol |
| 20:00.57 | bkruse_home | theres some good docs on it |
| 20:01.00 | blitzrage | where? |
| 20:01.13 | bkruse_home | people are like, "OMG IT DOESNT WORK BLAME *" |
| 20:01.14 | blitzrage | everything I read was way more complicated than what we're discussing trying to do |
| 20:01.15 | bkruse_home | let me google it |
| 20:01.20 | bkruse_home | actually, its book marked i think |
| 20:01.26 | bkruse_home | ya, it is kind of annoying to do |
| 20:01.28 | blitzrage | at least the voip-info wiki was useless |
| 20:01.31 | bkruse_home | nono |
| 20:01.36 | bkruse_home | yes your right |
| 20:02.00 | bkruse_home | you have to make sure you setup your ser in a special way |
| 20:02.04 | bkruse_home | what was that problem again.......... |
| 20:02.08 | bkruse_home | we labbed it up like a week ago |
| 20:02.25 | bkruse_home | there are some setups where you have to go out of your way to make it work, but its unusual, let me pull up my configs from last weeks tests :D |
| 20:02.45 | blitzrage | issue: |
| 20:02.47 | blitzrage | Asterisk deosn't know the registration status of the phone |
| 20:02.55 | Juggie | the issue is phones rebooting, and not getting their vm status because asterisk doesnt know they re-registered. |
| 20:03.03 | blitzrage | thanks Juggie |
| 20:03.05 | Juggie | so their mwi isnt correct until it changes. |
| 20:03.07 | blitzrage | yes, that's the main issue |
| 20:03.11 | Juggie | when * sends another notify. |
| 20:04.15 | bkruse_home | Juggie: oh, i see what you mean |
| 20:04.20 | bkruse_home | well, sharing state is OUT of the question. |
| 20:04.22 | bkruse_home | hmm |
| 20:04.25 | blitzrage | yes |
| 20:04.31 | bkruse_home | Juggie: interesting............. |
| 20:04.37 | bkruse_home | you could hack it to make it work |
| 20:04.42 | blitzrage | so we were talking about SER re-writing the REGISTER packet so SER basically registers on behalf of the phone |
| 20:04.44 | Juggie | did that. |
| 20:04.45 | bkruse_home | or, it would be a ser side hack, actually, probably |
| 20:04.50 | bkruse_home | right |
| 20:04.51 | bkruse_home | well |
| 20:04.52 | blitzrage | persistantmwi=yes |
| 20:04.52 | bkruse_home | well............ |
| 20:04.55 | bkruse_home | yes |
| 20:04.59 | blitzrage | always send NOTIFY on every checkmwi interval |
| 20:05.00 | blitzrage | it works |
| 20:05.03 | Juggie | bkruse_home, my initial suggestion was to have ser remember the last notify packet. |
| 20:05.03 | blitzrage | but not ideal |
| 20:05.06 | jsmith | blitzrage: Quick question... do you know the state of SUBSCRIBE support in Asterisk? |
| 20:05.15 | Juggie | jsmith: we do not. |
| 20:05.29 | Juggie | which is why i told blitzrage he needed to talk to olle. |
| 20:05.33 | bkruse_home | Juggie: yes! instead of sharing state(has been thought about, but its SO dumb) have it remember/send |
| 20:05.42 | bkruse_home | ser needs to communicate better.........or.........hmm |
| 20:05.42 | bkruse_home | thats the thing........reregistering to phone -> ser then ser -> asterisk.........hmmmm |
| 20:05.45 | bkruse_home | hmmmm |
| 20:05.52 | bkruse_home | jsmith: chan_sip.c |
| 20:06.10 | jsmith | bkruse_home: Uh, yeah... I know where the SIP code is found, thanks. |
| 20:06.12 | bkruse_home | totally kidding, i hate when people tell me that... |
| 20:06.35 | bkruse_home | jsmith: that was kind of a lame comment, my bad, that was a moronic phrase on my part |
| 20:06.53 | bkruse_home | hmm....... |
| 20:07.14 | bkruse_home | yay proof of concept code! |
| 20:07.31 | blitzrage | bkruse_home: lol |
| 20:07.37 | blitzrage | ok, off to call the parents for a bit |
| 20:07.47 | bkruse_home | blitzrage: this stuff im writing is a hack ;[ but what it does is awesome |
| 20:08.10 | Juggie | well, we have it totally working, but its not an ideal solution. |
| 20:08.42 | bkruse_home | Juggie: a hack? what did you do? |
| 20:08.49 | bkruse_home | maybe it could be more "formally" integrated ;] |
| 20:08.56 | blitzrage | always send NOTIFY on every checkmwi interval |
| 20:09.03 | blitzrage | parents didn't answer |
| 20:09.05 | bkruse_home | hmm...... |
| 20:09.08 | Juggie | created a new sip.conf flag called 'persistantmwi' which basically sends the notify regardless of if the state changes, every checkmwi interval. |
| 20:09.11 | bkruse_home | well...... |
| 20:09.12 | bkruse_home | hmm |
| 20:09.12 | jsmith | blitzrage: What about option #4... |
| 20:09.21 | blitzrage | what would that be? |
| 20:09.26 | bkruse_home | Juggie: and that works well? |
| 20:09.32 | jsmith | #4: Phones register to SER. SER sends a SUBSCRIBE to Asterisk on behalf of the phone |
| 20:09.43 | blitzrage | that might work |
| 20:09.44 | Juggie | jsmith, i've said that already. |
| 20:10.01 | Juggie | but we dont know how subscribe works. |
| 20:10.09 | Juggie | bkruse_home, yes besides the unnecessiary traffic |
| 20:10.11 | Juggie | it works great. |
| 20:10.32 | blitzrage | Juggie: I heard it, but I still figured it'd be triggered by SER or the phone which wasn't idea, but if the REGiSTER triggers the SUBSCRIBE, that might work |
| 20:10.47 | blitzrage | yah, it's solving my MWI issue for now |
| 20:10.51 | blitzrage | just a lot of network traffic though |
| 20:11.07 | Juggie | indeed, assuming this, when ser does a subscribe even if its subscribing again it will resend the notify. |
| 20:11.08 | blitzrage | every 30s you get a burst of traffic for every peer |
| 20:11.14 | bkruse_home | Juggie: is the traffic to the point where its anoying |
| 20:11.14 | bkruse_home | oh |
| 20:11.15 | bkruse_home | hmm |
| 20:11.19 | bkruse_home | that is kind of a hack ;[ |
| 20:11.21 | blitzrage | bkruse_home: yah |
| 20:11.28 | bkruse_home | it would be better to submit a patch to ser/openser |
| 20:11.34 | bkruse_home | i wonder how hard that would be...........hmm. |
| 20:11.43 | bkruse_home | it would have to send it via the phone, but as, hmmm |
| 20:11.49 | bkruse_home | this is an awesome thought provoking talk :D |
| 20:12.07 | blitzrage | bkruse_home: not a patch, but just a script in openser.cfg |
| 20:12.33 | bkruse_home | oh...... |
| 20:12.33 | bkruse_home | hmm |
| 20:12.34 | bkruse_home | well |
| 20:12.45 | bkruse_home | it would be cool to intergrate it into ser, sense ALOT of people use ser with asterisk...... |
| 20:12.56 | bkruse_home | but ya, your right, that would becool, then paste it on freaking voip-info, gah |
| 20:13.02 | blitzrage | yah, but just a script to openser.cfg requires no patching |
| 20:13.12 | blitzrage | if we can make it work with just scripting, then SER already might do what we need |
| 20:13.17 | blitzrage | no kidding |
| 20:22.08 | bkruse_home | right |
| 20:22.09 | bkruse_home | i agree |
| 20:22.14 | bkruse_home | good point |
| 20:22.59 | blitzrage | see: asterisk-dev :) |
| 20:23.01 | bkruse_home | yes, #1 and #4 |
| 20:23.02 | bkruse_home | lol |
| 20:24.38 | jsmith | brb |
| 20:41.23 | blitzrage | ok, so Kristian basically agrees this should be possible (#4), but we need to talk to Olle about how to handle the SUBSCRIBE stuff |
| 20:41.51 | blitzrage | anyways, great discussion guys! I'm off to finish this wine, shower, change, and get ready for hockey/Pamela |
| 20:42.05 | blitzrage | <PROTECTED> |
| 21:20.09 | blitzrage | http://bugs.digium.com/view.php?id=3644 |
| 21:20.37 | jsmith | blitzrage: I thought you were away smooching your honey |
| 21:20.44 | blitzrage | not yet |
| 21:20.46 | blitzrage | :) |
| 21:20.48 | jsmith | (or getting gussied up to) |
| 21:21.00 | blitzrage | yah, I showered and such |
| 21:21.10 | blitzrage | changed, etc.... that took about 20 mins |
| 21:22.11 | jsmith | Had an idea... |
| 21:22.18 | blitzrage | ideas are nice |
| 21:22.38 | jsmith | If SUBSCRIBEs to VM don't work... we have the new DEVICESTATE function from RUSSELL |
| 21:22.49 | jsmith | Couldn't we just do something like |
| 21:24.00 | jsmith | exten => vm101_default,hint,${DEVICESTATE(${VMCOUNT(101@default,INBOX)})) |
| 21:24.24 | jsmith | The syntax is obviously wrong |
| 21:24.30 | jsmith | But I think you get the idea |
| 21:25.18 | blitzrage | hrmmm |
| 21:25.35 | blitzrage | I think so |
| 21:26.08 | blitzrage | seems like need to run trunk for the VM server right now |
| 21:26.15 | jsmith | Have you paid attention to any of the eventing stuff that Russell is doing? |
| 21:26.20 | blitzrage | I'm watching it |
| 21:26.23 | jsmith | Shoot... |
| 21:26.33 | blitzrage | so yes, paying attention |
| 21:26.34 | jsmith | Russell just added a "send_mwi_to_peer" function |
| 21:26.35 | blitzrage | quite a bit |
| 21:26.38 | blitzrage | oh yah? |
| 21:26.45 | jsmith | Wouldn't take me more than a day or two to wrap a manager command around that |
| 21:26.55 | jsmith | And we'd be in hog heaven |
| 21:27.07 | blitzrage | you;'re right |
| 21:27.22 | jsmith | A year from now, we'll have a whole different mess of beans to deal with |
| 21:27.37 | blitzrage | well, that's the fun in it :) |
| 21:27.47 | jsmith | Beats digging ditches, that's for sure |
| 21:27.51 | blitzrage | I can't even believe there is as much we can do now compared to 3 years ago |
| 21:28.01 | blitzrage | could you even imagine? |
| 21:28.03 | jsmith | Well, don't let me hold you up... I know you have plans tonight |
| 21:28.10 | jsmith | Yeah, I could imagine :-p |
| 21:28.10 | blitzrage | nah, no hold up |
| 21:28.27 | blitzrage | I'm just hanging out until Pamela gets here, adn that won't be until at least 6pm, and most likely later |
| 21:28.33 | blitzrage | I'm playing with idefisk2 |
| 21:28.41 | blitzrage | it's a total geek day :) |
| 21:28.58 | jsmith | Oh, she's coming to visit *you* |
| 21:29.02 | blitzrage | yep |
| 21:29.06 | jsmith | I thought you were catching the train |
| 21:29.07 | blitzrage | watch hockey |
| 21:29.16 | jsmith | That's why I was afraid I was making you lte |
| 21:29.19 | jsmith | s/lte/late/ |
| 21:29.26 | blitzrage | it's all good, I go when I need to go :) |
| 21:29.27 | file | oh *hockey* |
| 21:29.31 | blitzrage | file: ! |
| 21:30.10 | blitzrage | lol |
| 21:31.32 | file | is it sad that I dreamed lastnight about high latency on my DSL connection? |
| 21:31.56 | blitzrage | lol |
| 21:32.02 | blitzrage | I've dreamed like that before |
| 21:32.17 | blitzrage | brb, reboot time |
| 21:45.28 | jsmith | file: Yup, that's some pretty sad dreamin' |
| 21:45.43 | jsmith | Problem is, when I wake up in the morning, I still have high latency :-( |