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

[Asterisk Bug Tracker]

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-02 18:15 CST
====================================================================== 
Summary:                    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.

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

---------------------------------------------------------------------- 
 (0131426) cgoudie (reporter) - 2011-02-02 18:15
 https://issues.asterisk.org/view.php?id=18736#c131426 
---------------------------------------------------------------------- 
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 at 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. 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-02 18:15 cgoudie        Note Added: 0131426                          
======================================================================