I'd very much like to be involved in this discussion, not sure I can bring
anything intelligent to it! but at least I'm interested in getting this part of
sipxtapi stable. As I may have mentioned several weeks or months ago, I would
like to incorporate additional functionality into the file/buffer start/stop
features of sipxtapi(as a matter of fact, I have it implemented in revision
9924 but I don't have a working patch for the latest revision - not yet). What
I would like is the following:
each call to sipxCallPlayFile and sipxCallPlayBuffer would have an additional
(optional) parameter which would be a "cookie" value. This cookie would then
get passed back to the application when the corresponding START/STOP messages
are fired. I believe this is necessary under some circumstances, such as in my
application, where I'm both playing "static" files (i.e. files that are
predefined), as well as files created as a result of recording input from the
caller. I really don't care about START/STOP notifications for the first one,
but I need them for the latter. Since notifications are asyncronous, I need a
way to identify what notification matches what start command.
each STOP notification would (in addition to supplying this new cookie value)
supply a value which would say how much was actually played. This is useful in
my case, where the user may want to listen to something he recorded, then pause
in the middle of the recording, and then either insert or overwrite with a new
recording. In order to implement this, I must know how much was actually played.
As I said, I already have a working version of this, but it was written with
the old notification framework in mind. I can supply a patch if anyone is
interested, but I guess it would be best to wait until the notification system
becomes stable.
Regards,
DanÃel
Date: Fri, 17 Aug 2007 17:57:53 -0400From: [EMAIL PROTECTED]: [EMAIL
PROTECTED]: [EMAIL PROTECTED]: Re: [sipxtapi-dev] About the new resource
notification framework...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 implementedin
latest versions of MprFromFile.I have tried to follow the logic, but I still
don't get how it worksexactly. 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 MprFromFilePLAY_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
sipxtapimedia 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,
mediaTypeHow can the resource notification message result in a sipxtapi event
beingfired ?Thanks in
advance,stipus_______________________________________________ sipxtapi-dev
mailing [EMAIL PROTECTED] Archive:
http://list.sipfoundry.org/archive/sipxtapi-dev/ -- Keith KyzivatSIPez LLC.SIP
VoIP, IM and Presence Consultinghttp://www.SIPez.comtel: +1 (617) 273-4000
_________________________________________________________________
Connect to the next generation of MSN MessengerÂ
http://imagine-msn.com/messenger/launch80/default.aspx?locale=en-us&source=wlmailtagline
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
