[asterisk-bugs] [Asterisk 0018762]: Unsolicited SIP notifies cannot be routed to MWI lights on individual phones

[Asterisk Bug Tracker]

A NOTE has been added to this issue. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18762 
====================================================================== 
Reported By:                cgoudie
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18762
Category:                   Channels/chan_sip/NewFeature
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     ready for testing
Asterisk Version:           SVN 
JIRA:                       SWP-3040 
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2011-02-07 11:43 CST
Last Modified:              2011-02-07 14:26 CST
====================================================================== 
Summary:                    Unsolicited SIP notifies cannot be routed to MWI
lights on individual phones
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 at SIP_Remote to preserve existing functionality.
If unsolicited_mailbox=somebox at somecontext all unsolicited notifies will
be delivered to somebox at somecontext
If unsolicited_mailbox=@somecontext the box from the sip notify will be
used to deliver the sip notify to the specified box at 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.
======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
has duplicate       0018736 [patch] Out-of-dialog MWI from a SIP Tr...
====================================================================== 

---------------------------------------------------------------------- 
 (0131614) cgoudie (reporter) - 2011-02-07 14:26
 https://issues.asterisk.org/view.php?id=18762#c131614 
---------------------------------------------------------------------- 
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 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2011-02-07 14:26 cgoudie        Note Added: 0131614                          
======================================================================