[asterisk-bugs] [JIRA] Commented: (ASTERISK-17362) Unsolicited SIP notifies cannot be routed to MWI lights on individual phones

[alexr1 (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-17362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194973#comment-194973 ] 

alexr1 commented on ASTERISK-17362:
-----------------------------------

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?

> Unsolicited SIP notifies cannot be routed to MWI lights on individual phones
> ----------------------------------------------------------------------------
>
>                 Key: ASTERISK-17362
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-17362
>             Project: Asterisk
>          Issue Type: New Feature
>          Components: Channels/chan_sip/NewFeature
>            Reporter: Clinton Goudie-Nice
>         Attachments: patch-1.8.7.1-chan_sip-unsolicited-notify-handling.jira-bug-17362.diff.txt, patch-chan_sip-unsolicited_notify_routing.diff.txt, patch-chan_sip-unsolicited_notify_routing.diff.txt, sipsample.txt
>
>
> 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.
> ****** 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.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira