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/
