On 7/20/07, Daniel Sigurgeirsson <[EMAIL PROTECTED]> wrote:
1. A notification about the DTMF code must be passed upwards when detected, and in Stipus version he uses the mpFlowGraph variable defined inside MpResource - but that variable isn't necessarily initialized, and MpRtpInputAudioConnection doesn't seem to know about the flow graph, hence it probably won't be able to tell MprDecodeInBandDtmf about the flowgraph etc. So the third question is: what is the preferred way to accomplish this? As I understood then some rewrite of the messaging framework was in the pipeline, but I simply don't remember what the status on that is.
A rewrite of the messaging framework is partially implemented and used -- right now messages directed to resources work. It isn't radically different from the old model, but the main difference is that messages directed at specific named/typed resources can be sent now, without having to have a pointer to that resource. The flowgraph only needs to know it has a resource, and not what particular type of resource now, and messages for those particular resources can be constructed by calling static resource message creation functions, which then are pushed on the flowgraph's message queue. This mechanism is implemented now, and used in parallel to the old model. The old messaging system is used by MpCallFlowgraph, and new messaging system is used by the new MpTopologyGraph. Resource Notifications - messages that get sent the other way - from resource up to SipXmediaLib user and above, still needs to be finished up. Currently there exists an MpNotificationDispatcher, which contains a message queue. MpNotificationDispatcher is intended to be held by a flowgraph or multiple flowgraphs (I'm not clear on whether it needs to be held by all flowgraphs in the call, or a separate one for each flowgraph). Resources then contact their flowgraph to send a notification message, which then gets posted to the notification dispatcher provided to the flowgraph (if one exists). users of sipXmediaLib provide a notification dispatcher to the flowgraph themselves, and they can use the notification dispatcher to pull messages out of the dispatcher, or query the status of the queue. The use of a dispatcher class instead of just a queue also enables the possibility of message filtering -- if one subclasses MpNotificationDispatcher, one can dictate what types of messages are worthy of being received. The currently undefined part is the API for this mechanism for all layers above sipXmediaLib -- i.e. API for sipXtapi. I need to discuss this with all interested parties to get some ideas on how this should work, and once that is talked about and agreed to, I plan on finishing up the new resource framework. I'd like to have a Jabber conference about this sometime, -- time is flexible, but the sooner the better... If you're interested in the meeting about this, I'll email directly with those interested, and pass off conference information. To participate in a Jabber conference, all you need is any public Jabber login (Google Talk account also works - but not their client! - their client doesn't connect to Jabber conferences), and a client that can participate in Jabber conferences (Pidgin (formerly GAIM), and Miranda are both reasonable Jabber clients for the purpose). Thanks! -- 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/
