Re: New Resource Notification design..
2007-05-01 14:38:28 GMT
When CpMediaInterface::setNotificationQueue(OsMsgQ* pQueue) is appended, how we are planning to set it from test application? Means how cascaded changes are made throughout the outer shell APIs (CallManager, CpPeerCall)? sipxPhone is a test application in that sense.
sipxtapi-dev-bounces <at> list.sipfoundry.org
[mailto:sipxtapi-dev-bounces <at> list.sipfoundry.org] On Behalf Of Keith Kyzivat
Sent: Thursday, April 26, 2007 4:46 AM
To: sipXtapi developers list; Dan Petrie; Alexander Chemeris; Sergey Kostanbaev
Subject: [sipxtapi-dev] New Resource Notification design..
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:
- 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).
- Flowgraph contains a pointer to a notification
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.
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:
- 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.
- 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?
SIP VoIP, IM and Presence Consulting
tel: +1 (617) 273-4000
_______________________________________________ sipxtapi-dev mailing list sipxtapi-dev <at> list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/