On 7/3/07, Daniel Sigurgeirsson <[EMAIL PROTECTED]> wrote:
Another thing, apparently you must also call the corresponding sipxCallAudioStop function inbetween, otherwise sipxtapi doesn't correctly decrement the count of files being played, and hence the call will never be torn down properly. I also believe this will change, once the modifications from Jaroslav will be incorporated into the main trunk (what is the status of that BTW?)
Yep, the initial infrastructure for the new message notification scheme has been written -- using MpResourceNotificationMsgs posted to an OsMsgQ, as opposed to the callback/OsNotification approach that seems to be used in the past. MpNotificationDispatcher manages the queue to hold and dispatch the messages. The goal is to somehow allow users of sipXmediaLib to supply an MpNotificationDispatcher to the flowgraph(s), and then, when resources need to send notifications, they'll use the notification dispatcher(s) that are available in the flowgraph. How this is going to be exposed up through the higher levels, and even how a notification dispatcher is set on a flowgraph I still haven't determined. I'll be discussing this with other active developers within the next few weeks. The reason for a Notification Dispatcher as opposed to just using an OsMsgQ directly is that the notification dispatcher allows more flexibility -- One can derive from MpNotificationDispatcher and make a smarter dispatcher that can filter. The default Notification Dispatcher just dispatches all messages that are sent to it. If you're interested, please do go poking around the messaging code, and give me feedback, or if you have suggestions for a different/better approach other than the notification dispatcher, by all means, speak up. -- 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/
