Hello,
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.
Thanks
Debasish
_____
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 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:
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/
