Summary: | ASTERISK-18067: REGRESSION: After upgrading from 1.4.41 to *1.8.4.2 a SIP extension with a voicemail box can no longer monitor mwi of another extension | ||||
Reporter: | David Brillert (aragon) | Labels: | |||
Date Opened: | 2011-06-27 11:22:00 | Date Closed: | 2011-08-19 08:07:29 | ||
Priority: | Minor | Regression? | |||
Status: | Closed/Complete | Components: | Channels/chan_sip/Subscriptions | ||
Versions: | SVN 1.8.4 | Frequency of Occurrence | Constant | ||
Related Issues: |
| ||||
Environment: | Attachments: | ( 0) ext_5386_6386_mwi_bug_18067_sip_debug.txt | |||
Description: | To reproduce: Configure an extension in sip.conf to monitor the mwi status of its own extension another extension. Send a voicemail message to 6010 as in my example and wait for mwi at extension 6003. The important bit is mailbox=6003@default, 6010@default Result: 6003 never gets mwi light when leaving a message in mailbox 6010. I have tested and reproduced always and have also tested with patches from the following bug reports: 18002 17866 17997 sip.conf [6003] type = friend transport = udp mohinterpret = g722 mohsuggest = g722 subscribecontext = default-local accountcode = 6003 amaflags = default parkinglot = parkinglot_default defaultuser = 6003 secret = secret host = dynamic language = en callgroup = 1 pickupgroup = 1 t38pt_udptl = no dtmfmode = rfc2833 callerid = "6003" <6003> qualify = 2000 trustrpid = no sendrpid = pai nat = no canreinvite = no mailbox = 6003@default, 6010@default disallow = all allow = g722 allow = ulaw context = default-super cc_agent_policy = generic cc_monitor_policy = generic cc_offer_timer = 20 setvar = EXTCONTEXT=default-super setvar = TRANSFER_CONTEXT=default-super setvar = FORCE_RECORDING=6003 setvar = AUTO_RECORDING=6003 setvar = INBOUND_GROUP=6003@INCOMING setvar = SPYGROUP=default call-limit = 4 limitonpeers = yes notifyringing = yes notifyhold = yes [6010] type = friend transport = udp mohinterpret = g722 mohsuggest = g722 subscribecontext = default-local accountcode = 6010 amaflags = default parkinglot = parkinglot_default defaultuser = 6010 secret = secret host = dynamic language = en callgroup = 1 pickupgroup = 1 t38pt_udptl = no dtmfmode = rfc2833 qualify = 2000 trustrpid = yes sendrpid = pai nat = no canreinvite = no mailbox = 6010@default disallow = all allow = g722 allow = ulaw context = default-super cc_agent_policy = generic cc_monitor_policy = generic cc_offer_timer = 20 setvar = EXTCONTEXT=default-super setvar = TRANSFER_CONTEXT=default-super setvar = AUTO_RECORDING=6010 setvar = MONITOR_OPTION=wW setvar = INBOUND_GROUP=6010@INCOMING setvar = SPYGROUP=default call-limit = 8 limitonpeers = yes notifyringing = yes notifyhold = yes Useragent : PolycomSoundPointIP-SPIP_450-UA/3.2.5.0508 | ||||
Comments: | By: Leif Madsen (lmadsen) 2011-07-11 15:36:40.211-0500 I can't reproduce this, and I know MWI was broken for a period of time. Are you able to reproduce this with 1.8 from subversion? (or even 1.8.5-rc1 should really have this fixed in it as well). I have done this exact same thing with a system running 1.8.5-rc1 and it works for me. By: David Brillert (aragon) 2011-07-13 12:02:09.147-0500 Hi Leif, I have no problem reproducing on 1.8.5.0 official release. By: Jonathan Rose (jrose) 2011-08-12 14:44:11.890-0500 The way I understand this right now, Leif is under the impression that this is something along the lines of having multiple voicemail's listed in sip.conf for a sip peer and then if you have two users listening to the same voicemail box that only one of them will be notified. At the same time, when I was looking at this bug, that wasn't really the impression I got since you explicitly described subscription handling as a problem in here... but I'm actually haven't a bit of trouble figuring out how to deal with subscriptions in general, so I figured I'd ask you for some information on this bug... 1. Can you please describe the scenario in more detail? Is this something that involves subscriptions or is this something more simple and configuration based? 2. I'd like to see the sip dialog that occurs when you register the SIP device. Use sip set debug on and post those to the issue if you would. 3. I'd like to see any sip messages going out of Asterisk when the voicemail you are referring to is messaged. Normally what I'd expect to happen is that Asterisk should send out NOTIFY messages to the receiving devices. 4. If this is actually subscription related, I'd like to see console output for "sip show subscriptions" 5. Could you put up your sip.conf general section and any relevant peers? Thanks in advance if you can get to it, this should be enough information to get me on better footing. By: David Brillert (aragon) 2011-08-15 09:43:26.813-0500 Hi jrose: Here is the info you requested. The test has changed because I am posting info using a different test rig. Test: extension 6386 should be mwi monitoring ext 5386 if 5386 receives new vmail. So the test is 5386 calling lv msg feature code *980 to extension 5386. The expected result is to light Polycom MWI lights on ext 5386 and 6386 once 5386 receives the message. This would work in ast 1.4 with the line in [6386] sip.conf mailbox = 6386@default, 5386@default 1. Can you please describe the scenario in more detail? Is this something that involves subscriptions or is this something more simple and configuration based? - I assume this is to do with subscriptions since the only configuration is to include the extension number of the other mailbox the user wants to monitor as in example mailbox = 6003@default, 6010@default or mailbox = 6386@default, 5386@default 2. I'd like to see the sip dialog that occurs when you register the SIP device. Use sip set debug on and post those to the issue if you would. - will upload trace = ext 5386 6386 mwi bug 18067 sip debug.txt 3. I'd like to see any sip messages going out of Asterisk when the voicemail you are referring to is messaged. Normally what I'd expect to happen is that Asterisk should send out NOTIFY messages to the receiving devices. - will upload ext 5386 6386 mwi bug 18067 sip debug.txt 4. If this is actually subscription related, I'd like to see console output for "sip show subscriptions" - will upload ext 5386 6386 mwi bug 18067 sip debug.txt 5. Could you put up your sip.conf general section and any relevant peers? - [5386] type = friend transport = udp mohinterpret = default_default mohsuggest = default_default subscribecontext = default-local accountcode = 5386 parkinglot = parkinglot_default defaultuser = 5386 secret = scrubbed host = dynamic language = en t38pt_udptl = no dtmfmode = rfc2833 qualify = 2000 trustrpid = no sendrpid = pai nat = no canreinvite = no mailbox = 5386@default disallow = all allow = g722 allow = ulaw context = default-default cc_agent_policy = generic cc_monitor_policy = generic cc_offer_timer = 20 setvar = EXTCONTEXT=default-default setvar = TRANSFER_CONTEXT=default-default setvar = AUTO_RECORDING=5386 setvar = INBOUND_GROUP=5386@INCOMING call-limit = 8 limitonpeers = yes notifyringing = yes notifyhold = yes [6386] type = friend transport = udp mohinterpret = default_default mohsuggest = default_default subscribecontext = default-local accountcode = 6386 parkinglot = parkinglot_default defaultuser = 6386 secret = scrubbed host = dynamic language = en t38pt_udptl = no dtmfmode = rfc2833 callerid = "Test Two" <6386> qualify = 2000 trustrpid = no sendrpid = pai nat = no canreinvite = no mailbox = 6386@default, 5386@default disallow = all allow = g722 allow = ulaw allow = alaw allow = gsm allow = h261 allow = h263 allow = h263p allow = h264 context = default-default cc_agent_policy = generic cc_monitor_policy = generic cc_offer_timer = 20 setvar = EXTCONTEXT=default-default setvar = TRANSFER_CONTEXT=default-default setvar = AUTO_RECORDING=6386 setvar = INBOUND_GROUP=6386@INCOMING call-limit = 8 limitonpeers = yes notifyringing = yes notifyhold = yes By: David Brillert (aragon) 2011-08-15 09:44:04.501-0500 info for jrose requesting feedback. By: Jonathan Rose (jrose) 2011-08-15 13:28:56.474-0500 Thank you, I have produced a similar situation on my own box now and this issue occurs for me in 1.8 only. Currently working on figuring out what changed. I don't think this is going to take a horribly long time to fix. By: Jonathan Rose (jrose) 2011-08-15 13:49:16.202-0500 Ok, this problem is actually stupidly simple, at least on my end. Looks like something changed with parsing so that mailbox=a@a, b@b is no longer the same as mailbox=a@a,b@b When I made that minor change, I started getting all the expected mwi. I was somewhat suspicious about that being the problem. At the same time though, there is no reason for this to be a problem, so I'll be fixing it shortly in 1.8 svn. If you would, please make that change and then try again and report your results. By: David Brillert (aragon) 2011-08-15 13:58:36.380-0500 jrose: - mailbox = 6386@default, 5386@default + mailbox = 6386@default,5386@default Removing the space in sip.conf [6386] fixes the problem and both extensions now get MWI immediately on reload. Nice catch; funny bug By: Jonathan Rose (jrose) 2011-08-15 14:14:57.373-0500 It's really not that odd. It's just that app_voicemail.c has been hit in a lot of recent changes, so the part that delimits the string at the 's probably isn't trimming the whitespace any more. In terms of chan_sip.c though, the behavior is actually the same as it ever was. By: Jonathan Rose (jrose) 2011-08-15 14:51:41.175-0500 Actually, I'm noticing that while they get mwi on reload, and while they even get mwi for any mailboxes they are subscribed to, the behavior is still different than 1.4. Instead of giving the user a complete count of messages on all voicemail accounts subscribed, they only get the one most recently messaged. By: David Brillert (aragon) 2011-08-18 09:36:24.072-0500 jrose: I just tested your patch at https://reviewboard.asterisk.org/r/1365/ All seems to work correctly. I tested by sending two voicemails to a multiply subscribed mailbox. I deleted one message and MWI was still lit. I deleted second message and MWI turned off. SIP show peer of the secondly subscribed extension = LastMsgsSent : 32767/65535 I am not sure if that is correct but the patch does seem to be working. |