| Summary: | ASTERISK-16149: MWI NOTIFY is not being sent to phones subscribed to events | ||||
| Reporter: | rbosch (rbosch) | Labels: | |||
| Date Opened: | 2010-05-25 16:46:39 | Date Closed: | 2010-09-07 16:17:49 | ||
| Priority: | Minor | Regression? | No | ||
| Status: | Closed/Complete | Components: | Channels/chan_sip/Subscriptions | ||
| Versions: | Frequency of Occurrence | ||||
| Related Issues: |
| ||||
| Environment: | Attachments: | ( 0) consoledebug.txt ( 1) sipdebug.txt ( 2) voicemail.conf.txt | |||
| Description: | Even though a phone is subscribed for mailbox events the MWI indicator is not changing when messages are left or deleted. The MWI indicator only gets updated every 30 minutes. Attached is a sip debug of a call made to device 9903 and a message is left in voicemail. No notification is sent to the SIP device. The PBX public IP has been replaced with the value PBXPUBLICIP, phone public IP is PHONEPUBLICIP, and phone private IP is PHONEPRIVATEIP. NAT is not the issue since BLF works without a problem. The output of sip show subscriptions is as follows: PHONEPUBLICIP 9903 3c26702391f1-yo -- <none> mwi 9903@devic 003600 ****** ADDITIONAL INFORMATION ****** BLF works fine on the same phone and is shown in the subscription. Email notifications for voicemail are working correctly. Just MWI not working. | ||||
| Comments: | By: Leif Madsen (lmadsen) 2010-05-26 10:06:23 I think a sample of the configuration files for your SIP peers along with console output leading up to the voicemail being left would be useful. Since this is a SIP issue please also enable sip history in sip.conf. By: rbosch (rbosch) 2010-05-26 10:13:12 Here is the device sip.conf and the general options. We're using FreePBX to generate the files. I'll have to run the test on our test system to get your the console output because there are so many calls on the system where this original capture was done the output is almost useless for analysis. Both systems experience the same issue (as do all our 1.6.2.7 installs). When observing the console output directly myself there was nothing other than the dialplan execution that was shown. I will capture it however. [9903] deny=0.0.0.0/0.0.0.0 secret=SECRET dtmfmode=rfc2833 canreinvite=no context=from-internal host=dynamic type=friend nat=yes port=5060 qualify=yes callgroup= pickupgroup= dial=SIP/9903 accountcode= mailbox=9903@device permit=PUBLICIPPHONE/255.255.255.128 callerid=Rob Office <9903> call-limit=50 faxdetect=no General SIP options faxdetect=yes vmexten=*97 context=from-sip-external callerid=Unknown notifyringing=yes notifyhold=yes limitonpeers=yes tos_sip=cs3 tos_audio=ef tos_video=af41 alwaysauthreject=yes disallow=all allow=ulaw allow=gsm allow=alaw rfc2833compensate=yes relaxdtmf=yes t38pt_udptl=yes jbenable=no maxexpiry=3600 minexpiry=60 srvlookup=no defaultexpiry=120 allowguest=yes registerattempts=0 registertimeout=20 notifyhold=yes rtpkeepalive=0 g726nonstandard=no t38pt_udptl=yes videosupport=no maxcallbitrate=384 canreinvite=yes notifyringing=yes checkmwi=10 rtptimeout=30 rtpholdtimeout=300 nat=no externip=PUBLICIPPBX By: rbosch (rbosch) 2010-05-26 13:43:39 Console information included. By: rbosch (rbosch) 2010-06-04 10:22:37 Is anything being done with this issue? Just wondering, no notes or response has been entered. By: rbosch (rbosch) 2010-06-12 19:04:38 Additional debugging shows that the ast_event_queue_and_cache(event); is properly called in queue_mwi_event but there is no event going to the sip channel. I have verified the extension and context are set properly in this event call. I can't speak to what happens in ast_event_queue_and_cache since I'm not a C programmer. If additional logs are needed please let me know. As of right now, MWI does NOT work in 1.6.2, period. I also tried updating to 1.6.2.8 and the problem persists. By: Leif Madsen (lmadsen) 2010-06-14 12:58:51 Nothing has been done yet, but there is a good chance it will be worked on in the next sprint. By: Digium Subversion (svnbot) 2010-07-14 17:58:23 Repository: asterisk Revision: 276571 U trunk/channels/chan_sip.c ------------------------------------------------------------------------ r276571 | jpeeler | 2010-07-14 17:58:23 -0500 (Wed, 14 Jul 2010) | 21 lines Fix MWI notification transmission problems over SIP. MWI updates were not being sent if no messages were found in the event cache. This was corrected since a phone may need to clear its MWI status configured previously from another mailbox. Upon module or sip reload, MWI updates could not be sent due to the sipsock socket not being set early enough in reload_config. The code handling the descriptor assignment and such has simply been moved before the call to build_peer. Issuing a sip reload cleared the IP address of the peer, but skipped checking the database for registration information. The database is now checked both for sip reload and actually reloading the module. If a transmission occurs before the do_monitor thread has started, do not attempt to send a signal to it. (closes issue ASTERISK-16149) Reported by: ip-rob ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=276571 By: Digium Subversion (svnbot) 2010-07-14 18:07:49 Repository: asterisk Revision: 276572 _U branches/1.6.2/ U branches/1.6.2/channels/chan_sip.c ------------------------------------------------------------------------ r276572 | jpeeler | 2010-07-14 18:07:49 -0500 (Wed, 14 Jul 2010) | 28 lines Merged revisions 276571 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ........ r276571 | jpeeler | 2010-07-14 17:58:24 -0500 (Wed, 14 Jul 2010) | 21 lines Fix MWI notification transmission problems over SIP. MWI updates were not being sent if no messages were found in the event cache. This was corrected since a phone may need to clear its MWI status configured previously from another mailbox. Upon module or sip reload, MWI updates could not be sent due to the sipsock socket not being set early enough in reload_config. The code handling the descriptor assignment and such has simply been moved before the call to build_peer. Issuing a sip reload cleared the IP address of the peer, but skipped checking the database for registration information. The database is now checked both for sip reload and actually reloading the module. If a transmission occurs before the do_monitor thread has started, do not attempt to send a signal to it. (closes issue ASTERISK-16149) Reported by: ip-rob ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=276572 By: rbosch (rbosch) 2010-08-12 12:06:36 I downloaded and installed version 1.6.11 which has this fix in it. The behavior has not changed. MWI is still not working. By: Jeff Peeler (jpeeler) 2010-09-02 16:09:21 Can you also upload your voicemail.conf? I'll try and start investigating but MWI does work for me now when previously it did not. By: rbosch (rbosch) 2010-09-02 22:16:18 I was just going to update this ticket yesterday. I could not get MWI to work at all previously but forgot to test changing the poll setting with 1.6.11. When I enable polling and set the polling frequency to 5-10 seconds I get MWI working. The subscription part is not working with the phones I have (soft phones from zoiper, x-lite and hard phones from snom) but with polling enabled the MWI does work. Do you still want the voicemail.conf? By: Jeff Peeler (jpeeler) 2010-09-03 11:06:14 Yeah it looks like you were using the old checkmwi option. Are you modifying the mailboxes outside of app_voicemail? If not I don't know why you would need to enable polling. Let me know a little bit more about the setup here so I can confirm whether you just need to open a separate bug. By: rbosch (rbosch) 2010-09-03 11:21:37 Nothing special going on with the configuration. I'm using FreePBX 2.8 on top of Asterisk 1.6.11. No DAHDI installed, just asterisk and asterisk addons. There isn't anything with voicemail being done outside of app_voicemail. The only thing that is a little unique is I'm running asterisk in a container in openvz. This shouldn't impact MWI though. I didn't think I should have to put in the polling option either but it does resolve the issue. I'm open to any other suggestions and happy to provide whatever data you need. By: Jeff Peeler (jpeeler) 2010-09-03 11:50:12 Go ahead and upload your voicemail.conf. By: rbosch (rbosch) 2010-09-04 12:04:38 Uploaded...I just removed some personalization information such as voicemail passwords, email addresses, URL, etc. All the variable settings are the same as in the live system. By: Jeff Peeler (jpeeler) 2010-09-07 14:07:21 Can you tell me how you are testing the MWI? Are you leaving a voicemail message for 9903 and then hanging up? By: rbosch (rbosch) 2010-09-07 14:42:00 I'll leave a message for extension 903, not device 9903, and see if MWI lights up. In FreePBX, devices are linked to extensions in device and extension mode via a file system link (the device directory is linked to the extension device). I think I see where you are going...you think that the subscription that 9903 has registered will not be triggered if a voicemail is left for extension 903. I could see where that would make sense and hadn't even thought about that issue. Is that what you think? By: Jeff Peeler (jpeeler) 2010-09-07 15:57:54 Yeah so modify your sip.conf to match the actual mailbox of 903 then and see what happens. By: rbosch (rbosch) 2010-09-07 16:03:08 I think we can close the issue. I suspect it is related to the way FreePBX implements devices and users. With polling everything works fine. By: Jeff Peeler (jpeeler) 2010-09-07 16:06:36 Well the point is that polling shouldn't be required, but if you can't test directly then I'll go ahead and close it. | ||||