Does it matter to the application if it is sent via RFC2833 or inband? In my
application, a DTMF is a DTMF regardless of the protocol used to send it.
Obviously we wouldn't want duplicate DTMF notifications, if DTMF are perhaps
sent with more than one method.
But then again, if this information can be available to the application, it
probably won't hurt either.
Daníel
> From: [EMAIL PROTECTED]> To: [EMAIL PROTECTED]> Date: Tue, 31 Jul 2007
> 16:07:06 +0200> CC: [email protected]> Subject: Re:
> [sipxtapi-dev] Inband DTMF revisited> > It seems the notification signal uses
> 31 of the 32 bits> > first bit is (keyup/keydown)> second bit seems unused>
> Then there are 14 bits for the DTMF key> Then there are 16 bits for the
> detected tone duration.> > Maybe I could use the second bit set to 1 for
> INBAND DTMF ?> > What do you think ?> > stipus> > ----- Original Message
> ----- > From: "stipus" <[EMAIL PROTECTED]>> To: "stipus" <[EMAIL PROTECTED]>;
> "Alexander Chemeris"> <[EMAIL PROTECTED]>> Cc:
> <[email protected]>> Sent: Tuesday, July 31, 2007 3:48 PM>
> Subject: Re: [sipxtapi-dev] Inband DTMF revisited> > > > OK I found the (old)
> notification code.> >> > In the flowgraph we have:> > UtlBoolean
> MpCallFlowGraph::handleSetDtmfNotify(MpFlowGraphMsg& rMsg)> >> > {> >> >
> OsNotification* pNotify = (OsNotification*) rMsg.getPtr1();> >> >
> MpConnectionID connId = rMsg.getInt1();> >> > return
> mpInputConnections[connId]->handleSetDtmfNotify(pNotify);> >> > }> >> > I
> could change the return line to:> >> > return
> mpInputConnections[connId]->handleSetDtmfNotify(pNotify) &> >
> mpDecodeInBandDtmf[connId]->handleSetDtmfNotify(pNotify)> >> > Then in
> DecodeInBandDtmf::handleSetDtmfNotify() I save the pNotify> pointer,> > then
> I could try to notify using a similar code as in MpdPtAvt:> >> > if( mpNotify
> != NULL )> > mpNotify->signal(0x80000000 | (0x3fff0000 & (mCurrentToneKey <<
> 16)));> >> > However, it won't be possible from the application point of view
> to know> if> > it's a RFC2833 DTMF or INBAND DTMF (as I would use the same
> Notification> > object as MpdPtAvt).> >> > I'm now going to see how I can add
> a second Notification (dedicated to> > INBAND dtmf)... but I fear this would
> require many changes.> >> > stipus> >> > ----- Original Message ----- > >
> From: "stipus" <[EMAIL PROTECTED]>> > To: "Alexander Chemeris" <[EMAIL
> PROTECTED]>> > Cc: <[email protected]>> > Sent: Tuesday, July
> 31, 2007 3:17 PM> > Subject: Re: [sipxtapi-dev] Inband DTMF revisited> >> >>
> > > > Well, I've looked into the code and found that this way is wrong. To>
> do> > > this> > > > right we should use the way, MpdPtAvt use to signal
> tones, or use new> > > > notification system.> > >> > > I'll have a look and
> see how it's implemented in MpdPtAvt.> > >> > > > > I would also like to use
> this to get MEDIA_PLAYBUFFER_START/STOP and> > > > >
> MEDIA_PLAYFILE_START/STOP notifications from MprFromFile as it was> > >
> working> > > > > in the sipxtapi-media-update branch...> > > >> > > > Does
> they not working now?> > >> > > I don't think so... currently I have
> implemented this myself using the> > wrong> > > method (again with a
> pMediaEventListener in the flowgraph, and new> > > OnPlayBufferStart/Stop
> methods in SipConnection.)> > >> > > I'm very interested in implementing this
> "the right way", and if> possible> > > with the new notification system.> >
> >> > > stipus> > >> > > ----- Original Message ----- > > > From: "Alexander
> Chemeris" <[EMAIL PROTECTED]>> > > To: "stipus" <[EMAIL PROTECTED]>> > > Cc:
> "Daniel Sigurgeirsson" <[EMAIL PROTECTED]>;> > >
> <[email protected]>> > > Sent: Tuesday, July 31, 2007 3:06 PM>
> > > Subject: Re: [sipxtapi-dev] Inband DTMF revisited> > >> > >> > > > Hi,> >
> > >> > > > On 7/25/07, stipus <[EMAIL PROTECTED]> wrote:> > > > > If I
> understand what you mean:> > > >> > > > Well, I've looked into the code and
> found that this way is wrong. To> do> > > this> > > > right we should use the
> way, MpdPtAvt use to signal tones, or use new> > > > notification system.
> MpdPtAvt is a decoder of rfc2833 tones, sent as> RTP> > > > packets, and it
> use OsNotification to signal DTMF tone start/stop. You> > may> > > > look at
> MpdPtAVT::signalKeyDown() and MpdPtAVT::signalKeyUp()> > > > to understand
> how does it signal DTMF up (it use mpNotify for this).> > > >> > > > Much
> cleaner way would be to use new notification system. I'm unsure> > > > of its
> current status, but I believe it is working, but you'll need to> > > create>
> > > > new notification message and handler for it. If you're interested,>
> Keith> > > > could give you tips how to do this.> > > >> > > > > I would also
> like to use this to get MEDIA_PLAYBUFFER_START/STOP and> > > > >
> MEDIA_PLAYFILE_START/STOP notifications from MprFromFile as it was> > >
> working> > > > > in the sipxtapi-media-update branch...> > > >> > > > Does
> they not working now?> > > >> > > > -- > > > > Regards,> > > > Alexander
> Chemeris.> > > >> > > > 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/> > >> > >> > >> >>
> >> >> >> > _______________________________________________> sipxtapi-dev
> mailing list> [email protected]> List Archive:
> http://list.sipfoundry.org/archive/sipxtapi-dev/
_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE!
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
