[asterisk-bugs] [JIRA] (ASTERISK-21441) New SIP Channel Driver: Create an API on top of the pub/sub framework for extension state notifications

[Digium Subversion (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-21441?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Digium Subversion closed ASTERISK-21441.
----------------------------------------

    Resolution: Fixed
    
> New SIP Channel Driver: Create an API on top of the pub/sub framework for extension state notifications
> -------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-21441
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21441
>             Project: Asterisk
>          Issue Type: New Feature
>      Security Level: None
>          Components: Channels/chan_gulp
>            Reporter: Matt Jordan
>            Assignee: Kevin Harwell
>              Labels: Asterisk12, NewSIP
>
> See [Event Subscription and Publication Design|https://wiki.asterisk.org/wiki/display/AST/Event+Subscription+and+Publication+Design] for information regarding the existing pub/sub framework.
> This task is to build out support for extension state notifications for the new SIP channel driver. This task does not include building out XML profiles or providing special services for a particular device type. Instead, the focus of this task is to create a resource module that provides an API that device specific modules can attach to in order to provide NOTIFY requests for specific event packages.
> The module should:
> * Use the facilities in the pub/sub framework for managing subscriptions.
> * Implement callbacks for extension state via {{ast_extension_state_add_destroy*}} (extended or non-extended, whatever)
> ** In the callback, properly marshal the data from an Asterisk managed thread to a PJSIP managed thread
> ** Manage the extension state changes. This includes swallowing state changes for duplicate transmissions (that is, if we get a RINGING twice we don't send a NOTIFY request for the second extension state change), etc. As much as I hate to say it, see {{chan_sip}} for the non-device specific logic applied to extension state handling.
> * Create an API that allows a resource module to:
> ** Register as a provider for a particular event/media type tuple. The registration should provide a callback function that returns a formatted package suitable for a NOTIFY request.
> ** The callback has to be able to take in the {{state_notify_data}} object.
> ** Note that multiple modules may register for a particular tuple. A module should be able to determine whether or not it should handle a particular extension state based on the devices that have subscribed for that extension state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira