Summary:	ASTERISK-21441: New SIP Channel Driver: Create an API on top of the pub/sub framework for extension state notifications
Reporter:	Matt Jordan (mjordan)	Labels:	Asterisk12 NewSIP
Date Opened:	2013-04-15 20:51:10	Date Closed:	2013-06-17 10:48:03
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_pjsip
Versions:		Frequency of Occurrence
Related Issues:	is related to ASTERISK-21442 New SIP Channel Driver - Create an extension state provider for RFC 3863 is related to ASTERISK-21443 New SIP Channel Driver - Create a state provider for dialog-info+xml
Environment:		Attachments:
Description:	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.
Comments: