On 3/22/07, Daniel Petrie <[EMAIL PROTECTED]> wrote:
Thank you Keith for describing the resource messaging requirements an suggested approach. This is not a major change to the structure of the flowgraph mechanizm, but it has a big impact on the amount of flexablity that we gain in how we can arrange the resources in a flowgraph.
There is a messaging system in there now for message to resouces and
flowgraphs. Can you describe what is required that is not there today or what the problems of the existing message are.
Yes, this would allow a lot more flexibility in what resources can participate in a flowgraph. With the current implementation, we have a whole host of specific resource pointers in the MpCallFlowgraph.. With the new flowgraph class MpTopologyGraph, we 're aiming for it not to need to know which specific resources that are part of it. Any specific things that are required for it to exist could be done by specific naming convention in the resourceID given to it when resources are registered with it. MpCallFlowgraph currently has the following specifically typed resources: MprBridge* mpBridge; MprFromFile* mpFromFile; MprFromStream* mpFromStream; MprFromMic* mpFromMic; #ifdef HAVE_SPEEX // [ MprSpeexPreprocess* mpSpeexPreProcess; #endif // HAVE_SPEEX ] #if defined (SPEEX_ECHO_CANCELATION) MprSpeexEchoCancel* mpEchoCancel; #elif defined (SIPX_ECHO_CANCELATION) MprEchoSuppress* mpEchoCancel; #endif MprMixer* mpTFsMicMixer; MprMixer* mpTFsBridgeMixer; MprSplitter* mpToneFileSplitter; MprToSpkr* mpToSpkr; MprToneGen* mpToneGen; MprRecorder* mpRecorders[MAX_RECORDERS]; These, as can be seen, are speicifically typed. Now, what happens if one wishes to have two bridge mixers? or perhaps two MprToSpkrs, to output different audio to two different devices? This new topology graph would give us the flexibility to do this. But in order for it to work, we'll need a new messaging scheme to be able to send messages that are only useful to specifically typed resources (for example MprMixer::setWeight). This discussion is about defining what this new messaging scheme will ultimately look like. -- 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/
