That, I'm not entirely sure about.. I'd appreciate any feedback. What I have now allows for media notifications to be accessible up through users of sipXmediaAdapterLib -- now, this does break a bit of the separation of the mediaLib from those above, as was why sipXmediaAdapterLib was created, but I'm not sure how else to do this.
What I've provided right now is: - The concept of a MediaNotificationDispatcher, which is used to receive messages, and can be subclassed to filter if one wishes (hence the reason for it's creation over just using an OsMsgQ). - OsMsgDispatcher* CpMediaInterface::setMediaNotificationDispatcher(OsMsgDispatcher*), where user creates an OsMsgDispatcher, and passes it to the media interface, which passes it down to the MediaLib -- ownership remains with the user. - MpResNotificationMsg class - which provides a subclassed OsMsg that holds the new notification codes (this is where you'd add new ones). New methods on CpMediaInterface: - OsMsgDispatcher* setMediaNotificationDispatcher(OsMsgDispatcher*) - as stated above - OsStatus setMediaNotificationsEnabled(bool enabled, const UtlString& resourceName = NULL) Used to enable sending of notications -- if not set, then no notifications will be sent for either a particular named resource, or for all resources. (Maybe this is assuming too much about the underlying mediaLib?) - OsMsgDispatcher* getMediaNotificationDispatcher() - return a pointer to the notification dispatcher set on the flowgraph, NULL if none was set. New methods on MpFlowGraphBase: - OsStatus MpFlowGraphBase::postNotification(MpResNotificationMsg&) - used by resources to post a notification to the dispatcher. - OsMsgDispatcher* setNotificationDispatcher(OsMsgDispatcher* notifyDispatcher) - as stated above -- flowgraph ultimately is the one holding the pointer, mediaAdapterLib is just an interface to it. - OsMsgDispatcher* getNotificationDispatcher() - returns a pointer to the dispatcher that was set on the flowgraph, NULL if none was set. - OsStatus setNotificationsEnabled(bool enabled, const UtlString& resourceName = NULL) - a passthrough of CpMediaInterface::setMediaNotificationsEnabled -- this one actually posts messages to one (if named) or all resources to get them to change whether or not they send or don't send notifications. It sounds like I'm missing an easy, generic way for notifications not to be sent -- right now, each resource on it's own needs to receive and deal with the MPRM_ENABLE_ALL_NOTIFICATIONS and MPRM_DISABLE_ALL_NOTIFICATIONS messages, and use that held state to send only when appropriate (when MPRM_ENABLE_ALL_NOTIFICATIONS is received). So, I believe I should add protected methods MpResource::postNotification(MpResNotification::RNMsgType), and, if a generic resource notification message isn't good enough, MpResource::postNotification(MpResNotificationMsg&) -- The specific resource (like MprFromFile) would call either of these as necessary when wishing to post a notification. In addition to that, if the preparation for notifiying would involve time consuming calculations that the writer of the resource wishes to only incur if notifications are enabled, then MpResource should provide a protected method for determining the notification send status -- enabled/disabled, so in the subclassed resource one can check to see if they're enabled, and only do those time consuming calculations if they are. So, to add notification capability to your In-Band DTMF decoder, I think I'll need to add this generic postNotification code and hold notification enabled/disabled status to MpResource first, BUT, I'd definitely like your input. I want this to work for everyone, not just for my particular project's needs. Please, just shoot me an email if anyone has any concerns, feedback, etc - either on the list or off the list (though on the list would be preferable so other folks know what's going on). Thanks! ~Keith On 8/17/07, stipus <[EMAIL PROTECTED]> wrote: > > I have seen the new media notification framework started to get > implemented > in latest versions of MprFromFile. > > I have tried to follow the logic, but I still don't get how it works > exactly. My goal would be to use this new resource notification framework > for my MprDecodeInBandDtmf resource, before I can release a clean patch. > > Another goal would be to get distinct SipxTapi media events from > MprFromFile > PLAY_FILE and PLAY_BUFFER. I can see in the new mprFromFile that the old > notify->signal(PLAY_FINISHED) is still in use... ?!? > > In short: > > >From the MprDecodeInBandDtmf resource, I want to be able to fire a > sipxtapi > media event such as > - MEDIA_REMOTE_DTMF, MEDIA_CAUSE_DTMF_INBAND, dtmfCode > > >From the MprFromFile resource, I want to get sipxtapi media events such > as > - MEDIA_PLAYFILE_START, MEDIA_CAUSE_NORMAL, mediaType > - MEDIA_PLAYFILE_STOP, MEDIA_CAUSE_NORMAL, mediaType > - MEDIA_PLAYBUFFER_START, MEDIA_CAUSE_NORMAL, mediaType > - MEDIA_PLAYBUFFER_STOP, MEDIA_CAUSE_NORMAL, mediaType > > How can the resource notification message result in a sipxtapi event being > fired ? > > Thanks in advance, > > stipus > > _______________________________________________ > sipxtapi-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/ > -- 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/
