[Home]

Summary:ASTERISK-17362: Unsolicited SIP notifies cannot be routed to MWI lights on individual phones
Reporter:Clinton Goudie-Nice (cgoudie)Labels:patch
Date Opened:2011-02-07 11:43:16.000-0600Date Closed:2018-07-11 04:41:29
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/NewFeature
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 0001-Asterisk-13-implementation-of-ASTERISK-17362.patch
( 1) patch-1.8.7.1-chan_sip-unsolicited-notify-handling.jira-bug-17362.diff.txt
( 2) patch-chan_sip-unsolicited_notify_routing.diff.txt
( 3) patch-chan_sip-unsolicited_notify_routing.diff.txt
( 4) sipsample.txt
Description:Currently, the implementation for unsolicited_mailbox routes all inbound unsolicited sip notifies to a single mailbox at the hard coded context SIP_Remote.

This makes it impossible for 3rd party SIP integrations to light MWI lights on phones attached to Asterisk. This is critical for 3rd party applications such as voicemail and IVR systems (IE: Exchange UM and Callware Callegra) to fully integrate with Asterisk as they can with other PBX systems such as Cisco Unified Communications Manager.

For these types of integrations, Asterisk needs the ability to receive unsolicited SIP notifies and route them as MWI lights to the appropriate physical device, within a context defined per trunk. This needs to occur without breaking anyone relying on the current Asterisk functionality of routing all unsolicited sip notifies to a single box.

The submitted patch handles this as follows:
If unsolicited_mailbox is unset, unsolicited notifies are not delivered anywhere.
If unsolicited_mailbox=somebox all unsolicited notifies will be delivered to somebox@SIP_Remote to preserve existing functionality.
If unsolicited_mailbox=somebox@somecontext all unsolicited notifies will be delivered to somebox@somecontext
If unsolicited_mailbox=@somecontext the box from the sip notify will be used to deliver the sip notify to the specified box@somecontext.

The box is specified either through the Message-Account portion of the body, and if unspecified there, the To header, as specified in RFC3842.

Additionally, this patch adds debug logging so that an end user can troubleshoot unsolicited sip notify issues by turning on debug logging.

****** ADDITIONAL INFORMATION ******

This issue supersedes issue 18736. Thanks also go to cmaj for his submission of the UM patch and additional guidance as we created this patch.
Comments:By: Leif Madsen (lmadsen) 2011-02-07 11:49:02.000-0600

Thanks for the submission! Please post to the asterisk-users and/or asterisk-dev mailing lists to see if you can get some additional testing from people. Thanks again!
By: Clinton Goudie-Nice (cgoudie) 2011-02-07 14:26:12.000-0600

This patch is quite easy to test. If you define a sip trunk (as a peer or friend) for a different (or even the same) machine, you can netcat the attached sipsample.txt to your asterisk server and see the results like so:

cat sipsample.txt |nc -p 5065 -w 2 -u asterisk-ip-addr 5060

You'll have to edit sipsample.txt to represent your IP addresses and ports first.


By: Leif Madsen (lmadsen) 2011-02-07 14:54:00.000-0600

An issue you were previously working on is now being handled here. Thanks!
By: Clinton Goudie-Nice (cgoudie) 2011-02-07 15:44:41.000-0600

Also related to issue 0013028 https://issues.asterisk.org/view.php?id=13028
By: cmaj (cmaj) 2011-02-07 19:36:39.000-0600

Tested and works great against Exchange 2010, using:

unsolicited_mailbox=@exum2010

This example causes the MWI NOTIFY to be properly stored on a per-user basis in the "exum2010" voicemail context - no change to voicemail.conf needed. Only setting the sip.conf definition for the peer/friend is required, for example, for extension 1234 you can use "mailbox=1234@exum2010" - very nice.

On the CLI, "event dump cache MWI" may prove helpful for other testers. (And of course "sip set debug ip whatever.sends.unsolicited.notifies" is also helpful.)

cgoudie, thanks for working on this! Glad I could help!
By: cmaj (cmaj) 2011-02-09 10:18:08.000-0600

This feature was requested previously in 18061 https://issues.asterisk.org/bug_view_page.php?bug_id=18061
By: Kevin Pare (kspare) 2011-02-09 10:49:38.000-0600

cmaj, i'm going to get a 1.8 box up and running here to test, but i'm curious as to how exactly you had your trunks to exchange 2010 setup?

What does exum2010 represent? I'd like to help out in documenting this so it's easy for others to follow. This is GREAT news that we can finally make this work!
By: Clinton Goudie-Nice (cgoudie) 2011-02-09 10:52:15.000-0600

kspare: It represents context your boxes/extensions are in. At a guess, I'd say you want unsolicited_mailbox=@default, but it really depends on your system. If you take a look at the patch, you'll see some additional doc I added to the sip config.
By: cmaj (cmaj) 2011-02-09 11:16:49.000-0600

Here's an example sip.conf to try - change the parts in <>'s to suite your needs (and drop the <>'s before you save it):

; exchange 2010 server
[exum2010]
type =                  friend
host =                  <exchange_box_ip_or_hostname>
qualify =               yes
transport =             tcp
context =               <context_from_extensions_dot_conf>
promiscredir =          yes
insecure =              port,invite
fromdomain =            <exchange_box.example.com>
unsolicited_mailbox =   @default

; phone extension 1234
[1234]
type =                  friend
host =                  dynamic
context =               <another_context_from_extensions_dot_conf>
secret =                <secret>
mailbox =               1234
By: cmaj (cmaj) 2011-02-09 11:21:06.000-0600

Note for folks coming from the forums - where I just spammed all comments related to this issue - you can create a new account on the bug tracker and then click the "Monitor Issue" button to get email notifications when this issue is updated with a new comment, code submission, etc.
By: Clinton Goudie-Nice (cgoudie) 2011-02-09 16:28:53.000-0600

I don't know that it needs saying, but I can confirm this works with Callware Callegra.

I also tested each of the use cases specified in the sip config.

unsolicited_mailbox=Box sends all mwi to that box@SIP_Remote.
unsolicited_mailbox=box@context sends the mwi to box@context
unsolicited_mailbox=@context sends the mwi to the sip specified box@context
By: cmaj (cmaj) 2011-03-01 22:22:44.000-0600

Still patches clean against 1.8.4-rc2
By: Clinton Goudie-Nice (cgoudie) 2011-03-02 10:02:32.000-0600

kspare: Would it help if I got you some prebuilt 1.8.2.2 i386 RPMs with the patch included to test with?
By: rsw686 (rsw686) 2011-06-07 12:31:03.419-0500

I can verify this patch works on Asterisk 1.8.4.2 with Exchange 2010 UM. I have the setting defined as unsolicited_mailbox=@context. What needs to happen for this patch to be committed into trunk?
By: Kai Hoerner (kaii) 2011-06-15 13:38:47.265-0500

I can also confirm that this patch works with Asterisk 1.8.4 and Exchange 2010 UM.
Active MWI subscribers for the specified mailbox (e.g. SIP phone) receive the unsolicited MWI.

But i did realize, that a rebooted phone which issues a new Subscribe does receive a "0/0" MWI, instead of the real that was contained in the last matching unsolicited MWI.
When a new message is left on the mailbox, the MWI is updated correctly to "7/0"

Most possibly this has nothing to do with the attached patch.
Is asterisk caching unsolicited MWI somehow or is it just "passed through"?

Exchange 2010 UM does only send the MWI once, when the voicemail count changes - if you restart the phone or asterisk, the MWI is lost on the user device.
A local mailboxes MWI is always available / recovers when a phone or asterisk is restarted.

Whats your opinions about this?
Should asterisk store the information about unsolicited MWI? (in memory.. on disk?)

I guess this should be addressed by a seperate patch.
By: rsw686 (rsw686) 2011-06-15 14:03:39.187-0500

Kai, I submitted ASTERISK-17997 to address the initial message count being 0 when subscribing. It is a regression from ASTERISK-16149. The asterisk-1.8.4.2-sip-mwi-event-v2.patch attached to it will solve your issue.

However if you restart Asterisk the message count will revert to 0 until exchange sends a notification. This is due to the event cache in Asterisk not being persistent. Hopefully we will see a patch in the future to save events to astdb and reload the event cache from astdb when starting. This would be similar to how we store SIP registry information in astdb.
By: Clinton Goudie-Nice (cgoudie) 2011-06-15 15:27:07.633-0500

In creating this patch, we wanted the scope to be as small as possible, so this is working the same way that unsolocited notifies used to work, just that it can route them to more than a single mailbox. I believe having Asterisk store the MWI information would be ideal, but a separate feature request.

We've been running this patch in house for a while now without issue, and it sounds like several others have as well.

@Leif Madsen do we have enough people whom have confirmed that it is tested and functional to get this change committed?
By: Kai Hoerner (kaii) 2011-06-20 11:59:54.245-0500

Hi all, please have a look on ASTERISK-18042

I implemented caching of the unsolicited MWI contents in ast_db to make the information available on asterisk restart.
By: cmaj (cmaj) 2011-10-30 18:21:42.969-0500

Patch applies clean on 1.8.7.1
By: cmaj (cmaj) 2011-11-01 19:19:12.735-0500

Slightly re-worked patch compiles clean with latest gcc on Debian Squeeze.
By: Clinton Goudie-Nice (cgoudie) 2011-11-02 14:22:36.365-0500

Re-uploading with contribution. I believe this was lost with the migration to jira.
By: Chad Monroe (cmonroe) 2012-05-16 17:18:25.899-0500

Is there any plan to include this patch in a release? I've applied it to 1.8.12.0 and it has been working well.
By: Clinton Goudie-Nice (cgoudie) 2012-05-16 17:20:38.841-0500

We would like to see it in one. I'm not sure what else we need to do to get it included into the codebase.
By: alexr1 (alexr1) 2012-07-18 05:09:13.351-0500

I am using the most recent Unsolicited Notify patch from above with asterisk 1.8.11

My phone (Cisco SPA504G2) does not subscribe to MWI, but Asterisk sends notifies anyway (AFAIK it adds a subscription on register anyway?).

Everything works perfectly within 32 seconds of a REGISTER or INVITE from my phone. I can send unsolicited notifies to asterisk from my PC and it will pass it onto the phone. As soon as the 32 seconds is up, asterisk no longer sends the new notifies to the phone - but the next time the phone registers, it receives the most recent unsolicited notify that was cached by the event queue/cache thing.

It seems the Event Queueing function requires a subscription (or at least an active dialog). Can it not create new dialogs for the purpose of sending an MWI instantly?
Is it possible that I could just slip in a ast_event_check_subscriber(host_event_type, AST_EVENT_IE_END) before I queue an event so that I could ALSO send an MWI directly after receiving the unsolicited notify?

ASTERISK-20119 talks about other dialogs removing MWI subscriptions when they are destroyed. It fits perfectly with what is happening to me, however the guys in that thread are COMPLETELY ignoring me. Hoping you guys have something more to say about it?
By: alexr1 (alexr1) 2012-07-18 05:15:12.527-0500

Slightly off-topic but related to the above, I've noticed that Asterisk will send a Notify to a phone with "mailbox" parameter set even if it has no subscription (which is great), but Asterisk seems to send a Notify on Register and Invite TWICE if it sends a 401 Unauthorised (All of our peers need to re-authenticate for every call). So each time they make a call it is:

Phone -> Register
Phone <- NOTIFY (MWI)
Phone <- Unauthorised

Phone -> Register (With auth)
Phone <- NOTIFY (MWI)
Phone <- OK (Register OK)

Probably undesirable behaviour, so I thought I'd throw that in for anyone who's clued up enough to do anything with it...
By: Clinton Goudie-Nice (cgoudie) 2012-07-19 10:17:31.168-0500

Greetings Alexr1,

This patch allows a sip trunk or other device to send unsolicited sip notifies (usually for MWI) to the sip trunk. It doesn't do anything beyond allowing Asterisk to be able to receive these notifies. Other Asterisk code then relays them to wherever they end up.

As to the event queuing, and how they get sent to the phone, I'm afraid that discussion isn't related to this patch.

I'm glad to hear the reception end of the code is working for you though.
By: Jordan McQuown (jmcquown) 2012-10-09 08:41:04.213-0500

Any reason we can't get this integrated? Exchange support would be great for us and I'd imagine plenty of other organizations.
By: Clinton Goudie-Nice (cgoudie) 2012-10-12 12:07:25.724-0500

We would sure like to see this integrated. Does anyone know the way to increase the priority?
By: Matt Jordan (mjordan) 2012-10-12 16:59:05.729-0500

There are several ways this can get integrated into trunk.  Note that because its a new feature, it is not a candidate for inclusion in any release branch (1.8, 10, or 11).
# Eventually, it will be assigned to a Digium developer to evaluate and review.  At that time, it will be integrated into what is at the time trunk.  When trunk is turned into a new release of Asterisk, it will be included in that version.  I do not have a time estimate as to when that will occur.
# An Asterisk developer may decide they like this feature and take it on for free.  They will then shephard the patch through the process.
## Alternatively, you can pay an Asterisk developer to do that.  The asterisk-biz mailing list is the appropriate place to look for a developer.
## Alternatively, someone can clean up this patch and write it for the current trunk.  That leads us to...
# Someone else (not a Digium developer, not an Asterisk community developer) can clean up this patch for inclusion.  While that doesn't necessarily mean it will be committed, it can possibly make the process go a bit faster.  In general, patches that have been (a) well tested, (b) follow the coding guidelines [1], (c) can be verified to be 'correct' and non-intrusive based on a cursory code inspection, will be addressed much faster than patches that don't meet that criteria.  If you decide to go down that road, you can contact developers when you feel you have something ready for code review in the #asterisk-dev channel.

(FYI: I took a cursory look at this patch, and it does not follow the Asterisk coding guidelines.  The minimum someone could do would be to write the patch for trunk and make it follow the guidelines linked below.)

[1] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines

By: Jordan McQuown (jmcquown) 2012-10-17 08:53:42.922-0500

Clinton,

Are Matt's comments something you can address or do you want to put a bounty out for it? Let me know what I can do to assist.
By: Clinton Goudie-Nice (cgoudie) 2013-02-15 16:34:36.995-0600

Hello Jordan,

At this point, Callware has the patch if one of their customers wishes to implement it. Also I am with a different development operation now, so it's unlikely I will be changing the formatting to meet the Coding Guidelines; however, this patch is not large, so it would be possible for another developer to come in and have it meet the coding guidelines.

I am still hopeful that a Digium developer will pick this issue up and submit it to upstream. As Matt said, eventually a developer will be assigned, however we just passed the 2 year anniversary of this patch. Without this patch, it's not really possible to receive unsolicited MWI from 3rd party CPE equipment into the asterisk PBX.
By: Sean Bright (seanbright) 2017-02-15 08:28:30.505-0600

Which of the attached patches is the most recent? There are two uploaded within a day of each other that are slightly different.
By: Sean Bright (seanbright) 2017-02-15 10:22:30.631-0600

Asterisk 13 implementation of ASTERISK-17362
By: Sean Bright (seanbright) 2017-02-15 10:23:17.984-0600

I've added an Asterisk 13 version of this patch. If you can test and confirm that it works, I will see if I can get it merged.
By: Joshua C. Colp (jcolp) 2017-12-20 06:08:58.943-0600

[~cgoudie] Did you try the patch provided by [~seanbright]?
By: Joshua C. Colp (jcolp) 2018-07-11 04:41:29.524-0500

Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines