To debug problems, it's very good to know if the recognized DTMF is RFC2833 or InBand. Also I have seen some cases where you get both at the same time... So it's easy from the application to shut down RFC2833 or InBand.
In my implementation, I have added a new SIPX_MEDIA_CAUSE = MEDIA_CAUSE_DTMF_INBAND When I get a MEDIA EVENT= MEDIA_REMOTE_DTMF, I look at the MEDIA_CAUSE It can be one of MEDIA_CAUSE_DTMF_START, /**< A RFC2833 DTMF tone has started */ MEDIA_CAUSE_DTMF_STOP, /**< A RFC2833 DTMF tone has stopped */ MEDIA_CAUSE_DTMF_INBAND // INBAND DTMF detected (ADDED BY STIPUS) stipus ----- Original Message ----- From: "Daniel Sigurgeirsson" <[EMAIL PROTECTED]> To: "stipus" <[EMAIL PROTECTED]>; "Alexander Chemeris" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Tuesday, July 31, 2007 4:33 PM Subject: RE: [sipxtapi-dev] Inband DTMF revisited 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/
