[asterisk-bugs] [Asterisk 0018736]: [patch] Out-of-dialog MWI from a SIP Trunk in asterisk 1.8.2.2 always responds with 489 Bad event

Fri Feb 4 12:20:59 CST 2011

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18736 
====================================================================== 
Reported By:                cgoudie
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18736
Category:                   Channels/chan_sip/Interoperability
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.8.2.3 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-02-02 15:19 CST
Last Modified:              2011-02-04 12:20 CST
====================================================================== 
Summary:                    [patch] Out-of-dialog MWI from a SIP Trunk in
asterisk 1.8.2.2 always responds with 489 Bad event
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 at 10.16.0.23 SIP/2.0
From:
"Anonymous"<sip:Anonymous at 10.16.0.47:5065>;tag=beeafd8-0-13c9-50022-ffdc7-52327663-ffdc7
To: <sip:5820 at 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 at 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 at 10.16.0.47:5065>;tag=beeafd8-0-13c9-50022-ffdc7-52327663-ffdc7
To: <sip:5820 at 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 at 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.

====================================================================== 

---------------------------------------------------------------------- 
 (0131508) cmaj (reporter) - 2011-02-04 12:20
 https://issues.asterisk.org/view.php?id=18736#c131508 
---------------------------------------------------------------------- 
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!) 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-04 12:20 cmaj           Note Added: 0131508                          
======================================================================