[Home]

Summary:ASTERISK-17340: [patch] Out-of-dialog MWI from a SIP Trunk in asterisk 1.8.2.2 always responds with 489 Bad event
Reporter:Clinton Goudie-Nice (cgoudie)Labels:
Date Opened:2011-02-02 15:19:42.000-0600Date Closed:2011-06-07 14:01:03
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/Interoperability
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) patch-chan_sip-1.8.2.2-unsolicited_notify_routing.diff.txt
( 1) patch-chan_sip-1.8.2.2-unsolicited_notify_routing-2.diff.txt
( 2) patch-chan_sip-1.8.2.3-unsolicited_notify_yes_sir.diff.txt
( 3) sipsample.txt
Description:Issue 13028 is said to have fixed this issue, however in 1.8 when I send an out-of-dialog notify, I only receive 489 Bad event

Here is an example of the sip notify and response from wireshark: (.23 is the Asterisk server. .47 is the host sending the sip notify)

---- From host sending sip notify ----

NOTIFY sip:5820@10.16.0.23 SIP/2.0
From: "Anonymous"<sip:Anonymous@10.16.0.47:5065>;tag=beeafd8-0-13c9-50022-ffdc7-52327663-ffdc7
To: <sip:5820@10.16.0.23:5060>
Call-ID: beeafd8-0-13c9-50022-ffdc7-4db95f02-ffdc7
CSeq: 1 NOTIFY
Via: SIP/2.0/UDP 10.16.0.47:5065;branch=z9hG4bK-ffdc7-3e7753f9-3403d179
Max-Forwards: 70
Supported: replaces
Contact: <sip:Anonymous@10.16.0.47>
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 47

Messages-Waiting:yes
Voice Message: 1/0 (0/0).

---- Response from Asterisk server ----

SIP/2.0 489 Bad event
Via: SIP/2.0/UDP 10.16.0.47:5065;branch=z9hG4bK-ffdc7-3e7753f9-3403d179;received=10.16.0.47
From: "Anonymous"<sip:Anonymous@10.16.0.47:5065>;tag=beeafd8-0-13c9-50022-ffdc7-52327663-ffdc7
To: <sip:5820@10.16.0.23:5060>;tag=as56d33dc9
Call-ID: beeafd8-0-13c9-50022-ffdc7-4db95f02-ffdc7
CSeq: 1 NOTIFY
Server: FPBX-2.8.1(1.8.2.2)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

--------

I have a SIP phone (grandstream) on extension 5820, and if I leave a voice mail message with asterisk for that phone, it does activate the MWI light.

In doing some additional debugging, I see the code path headed through (around line 20539) if(!p->mwi). it then searches for a peer on around 20541 and doesn't find one.

Additionally, the line char *c = ast_strdupa(get_body(req, "Voice-Message", ':'));  doesn't appear to place any text into c as a result of these two packets.

My sip trunk's inbound is context=from-internal and it's able to dial the extension 5820 fine. My phone's mailbox is 5820@default


We are sending these out of dialog notifies from a SIP auto-attendant/voicemail/ivr system. I can change how these packets look (to an extent), however it's worth noting these packets currently work with cisco call manager.


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

https://issues.asterisk.org/view.php?id=13028
Comments:By: Clinton Goudie-Nice (cgoudie) 2011-02-02 15:26:11.000-0600

For a quick test, I believe you should be able to use the attached file, replace:
PHONE-EXTENSION with your phone extension
SENDER-IP-ADDR with your ip address and
ASTERISK-IP-ADDR with the asterisk server ip

and send it with nc like so:

cat sipsample.txt |nc -w 2 -u ASTERISK-IP-ADDR 5060
By: Clinton Goudie-Nice (cgoudie) 2011-02-02 15:41:00.000-0600

Here's the debug output from this type of dialog:


[Feb  1 17:47:20] DEBUG[28674] chan_sip.c: Allocating new SIP dialog for beca918-0-13c9-50022-eea80-9e105ed-eea80 - NOTIFY (No RTP)
[Feb  1 17:47:20] DEBUG[28674] chan_sip.c: **** Received NOTIFY (4) - Command in SIP NOTIFY
[Feb  1 17:47:20] DEBUG[28674] chan_sip.c: Trying to put 'SIP/2.0 489' onto UDP socket destined for 10.16.0.47:5065
[Feb  1 17:47:20] DEBUG[28674] chan_sip.c: SIP message could not be handled, bad request: beca918-0-13c9-50022-eea80-9e105ed-eea80


By: Clinton Goudie-Nice (cgoudie) 2011-02-02 16:57:58.000-0600

Looks like we're using "Voice Message" instead of "Voice-Message" for our header. That's easy enough for me to fix on my side, but that still doesn't resolve the lookup for the mailbox.
By: Clinton Goudie-Nice (cgoudie) 2011-02-02 18:15:40.000-0600

Our current thoughts are that the find_peer call needs to be executed with the extension information from the to header, in this case 5920... To: <sip:5920@10.16.0.67:5060>

in the if(peer) block, it should use unsolicited_mailbox if set, otherwise continue to use the information from the to header for mailbox.

Finally, in the ast_event_new call, it seems that the context shouldn't be hard coded to SIP_Remote, but rather be a context configured from the sip.conf.

I may have a patch to submit tomorrow, unless someone can explain why p->mwi isn't being set.
By: cmaj (cmaj) 2011-02-02 23:09:43.000-0600

Uploaded patch-chan_sip-1.8.2.3-unsolicited_notify_yes_sir.diff.txt to allow setting "unsolicited_mailbox=yes" on a peer. Instead of dumping all the voicemail into one box@SIP_Remote context, this patch parses out the "Message-Account" line to determine which box@SIP_Remote context to use.

Realized now that this is not exactly what you want, as you want to parse the "To" header instead of "Message-Account" but the latter is what Exchange UM 2010 sends. Patch should be easy to modify either way.

Related to 18061.
By: Clinton Goudie-Nice (cgoudie) 2011-02-03 11:31:35.000-0600

cmaj based on what I see in http://social.technet.microsoft.com/Forums/en-US/exchangesvrunifiedmessaging/thread/c81b3ad0-6911-4f58-8547-754cd878baa8/ it looks like parsing from the To line will work the same as the Message-Account line as they both contain the same data.
By: cmaj (cmaj) 2011-02-03 12:10:56.000-0600

cgoudie, MS claims its MWI is RFC 3842 compliant in http://technet.microsoft.com/en-us/library/dd298001.aspx but double checking http://www.ietf.org/rfc/rfc3842.txt states in Section 3.5:

  If the Request-URI or To header in a message-summary subscription
  corresponds to a group or collection of individual messaging
  accounts, the notifier MUST specify to which account the message-
  summary body corresponds.  Note that the account URI MUST NOT be
  delimited with angle brackets ("<" and ">").

     Message-Account: sip:alice@example.com

...so I think we need to take "Message-Account" & "To"/"Request-URI" into account, perhaps looking for "Message-Account" first as my patch does AND adding in "To" (and "Request-URI") parsing as you suggest, especially in the case where "Message-Account" was not set. Provided it exists, however, it looks like "Message-Account" will always be of finer accuracy than "To".
By: Clinton Goudie-Nice (cgoudie) 2011-02-03 12:39:00.000-0600

cmaj: In your case, I'm still not sure how it gets inside the initial if(peer) block. My lookup for the peer always fails. I'm not sure if it's configuration problem on my part or if there's something wrong with my sip packet.

Still I think the peer lookup should be based on the Message-Account or TO instead of &p->recv as a lookup for the mailbox completes successfully. Thoughts?
By: cmaj (cmaj) 2011-02-03 12:55:03.000-0600

With my patch, I set "unsolicited_mailbox=yes" in the peer definition from which Asterisk will be receiving unsolicited NOTIFY MWI messages. Otherwise, you'd open yourself to accepting & processing unsolicited NOTIFY MWI messages from the world. So this patch requires a peer definition in sip.conf - can you try it with my patch like that? Maybe:

[somepeer]
host=10.16.0.47
type=friend
unsolicited_mailbox=yes

Also, you'd need to change the mailbox for your peer:

[5820]
mailbox=5820@SIP_Remote

(I think you can set multiple mailboxes there, so "mailbox=5820@SIP_Remote,5820@default" might work.)

Then modify your sipsample.txt like so to add the "Message-Account" line:

Messages-Waiting:yes
Message-Account: sip:5820@whatever
Voice Message: 1/0 (0/0).
By: Clinton Goudie-Nice (cgoudie) 2011-02-04 11:01:58.000-0600

cmaj, will you try that patch I just submitted? It should handle both the Message-Account and To headers. It also allows you to specify the context as part of unsolicited_mailbox so that all your phones don't have to be in SIP_Remote.
By: Clinton Goudie-Nice (cgoudie) 2011-02-04 11:15:35.000-0600

If that code works with UM, I'll write up a new bug clarifying the issues, and submit this patch to it.
By: cmaj (cmaj) 2011-02-04 12:20:58.000-0600

I like your idea to move away from the "SIP_Remote" voicemail context, and the "Message-Account" then "To" check looks clean. (I need to double-check on what else "SIP_Remote" interacts with, though.)

But perhaps a larger problem is that I think both our patches run the risk of breaking existing installations.

In the case of my patch, a user who had a voicemail box in the "SIP_Remote" context labeled "yes" would see a conflict. Not much chance of that, but still.

In your patch, however, the breakage might be more severe. If a user made no change to their sip.conf, but simply upgraded to a version of Asterisk with this patch, they would still get MWI NOTIFYs into the "SIP_Remote" context - but with different mailbox numbers than what they specified because Asterisk is now digging into the received NOTIFY headers to get the mailbox number, silently overriding what the user said in sip.conf

What if we only jump to this header digging code if the user specifies just a context in the peer definition from where we are accepting the MWI NOTIFYs:

unsolicited_mailbox=@context

...leaving out the mailbox number entirely so it can be filled in as-needed, based on the "Message-Account" or "To" lines.

Or do we add another option like "unsolicited_context" instead? (As if sip.conf needed another option!)
By: Clinton Goudie-Nice (cgoudie) 2011-02-04 16:30:45.000-0600

cmaj: I agree. I think you'll dig this updated patch.
if unsolicited_mailbox=2000 all unsolicited MWIs go to 2000@SIP_Remote
if unsolicited_mailbox=2000@default all unsolicited MWIs go to 2000@default
if unsolicited_mailbox=@default unsolicited MWIs go to the box specified in the Message-Account and then To @default.
if unsolicited_mailbox= then no unsolicited MWIs go anywhere.

It wont it wont break existing installations, you can still send all mwis to a single box (although I dont know why you'd want to). You can specify the context as you want. Finally, you can specify no box, and have the MWIs go to the box specified in the sip notify.


By: Clinton Goudie-Nice (cgoudie) 2011-02-07 11:22:37.000-0600

Bug moderators: Will you close this issue. The original write up isn't representative of the scope of entire issue. I'll write up a more accurate issue and include the appropriate patch file. Thanks.
By: Leif Madsen (lmadsen) 2011-02-07 11:28:32.000-0600

Closing this issue per the reporter. It looks like this has turned into a feature with patch, and thus should be opened as a new feature addition to Asterisk.
Thanks!
By: Clinton Goudie-Nice (cgoudie) 2012-10-12 12:15:05.084-0500

If you're visiting this issue, you should go to the updated issue here: https://issues.asterisk.org/jira/browse/ASTERISK-17362