Now that we've got the beginnings of resource operation messages, now we need something analogous on the notification side. A way for resources to notify an application of events independantly -- without the need for the flowgraph to be hardcoded with resource pointers.
This is primarily for the new MpTopologyFlowGraph, but is also going to be retrofitted onto the MpCallFlowGraph, and made to be backward compatible. Notifications we want to support now are: - "Done playing" from a FromFile - DTMF from an input audio connection - "Start RTP stream" from an input audio connection - "Continue RTP stream" from an input audio connection - "Stop RTP stream" from an input audio connection - RTCP events from an input audio connection - "Who's talking" from a bridge mixer. - some form of "VU meter" on local and remote inputs and outputs. - Signal strength (so app can provide signal "bars" like cell phones) from an input audio connection. To do this, I was thinking a separate notification message queue alongside the flowgraph's normal message queue would be the proper thing -- either a full blown queue created when the flowgraph is created, or a pointer to one passed in later from the app via the media interface. so - options for implementation are: 1. Have flowgraph contain a notification queue (OsMsgQ), paired with a method that lets the flowgraph know someone plans to read the events on the queue (one that indicates it's being drained). 2. Flowgraph contains a pointer to a notification queue. MediaInterface then provides a setNotificationQueue(OsMsgQ*) method, and the app calls this, passing a queue that it (the app) created. If setNotificationQueue never gets called, then notification messages that come in just get dropped on the floor. All of this needs a method on the flowgraph for posting a message to the resource notification queue. When the app wishes to receive a message, it calls receiveMsg on the notification queue, looks at the message type and subtype fields, and based on that, casts the message to the appropriate class with extra data needed for a particular message. The app then uses accessors on the derived resource message to get the information it needs. Future: We may wish to filter the notification messages - Consider the case where an app may only be interested in DTMF notifications, and may not care about other things like donePlaying, who's talking, etc. Filtering of notification messages as specified by the app could be handled in: 1. the flowgraph - FG holds a list of notification message types the app is interested in, and when a message is asked to be received, if the top item doesn't match one of the desired message types, it's dropped on the floor. 2. the message queue itself - make a derived OsMsgQ that is smart -- it holds the filters, and when a message comes in that doesn't match the filter, it's dropped on the floor. Is there a problem (memory leaking, etc) with dropping things from the queue from within the queue itself? What do people think? -- Keith Kyzivat SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000
_______________________________________________ sipxtapi-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
