My comments below:- > - Is it preferred that DTMF is also sent in-band and as SIP INFO when > the remote VoIP application announces that it is ready to receive RFC > 2833 packets?
GK>> I believe that if you advertise RFC 2833 in SDP & it is negotiated successfully, you should send/receive DTMF as RFC 2833. However, theoretically speaking, nothing prohibits you from using SIP INFO or in-band mechanisms. It's merely a waste of negotiating something that you would not eventually use. - What if the remote VoIP application does not announce that it is > ready to receive RFC 2833 packets? Which method should be preferred, > In-band or SIP INFO, or both for reliability purposes? GK>> SIP INFO marks a textual way of sending DTMF so it provides codec independence. Moreover, it provides transport of DTMF digits along with signaling path as opposed to the media path. SIP INFO was primarily introduced to support the transport of mid-call ISUP messages which could not be mapped to any other SIP request. OTOH, it's also believed that its "content-free framework" is the root cause to discourage the use of SIP INFO (see draft-rosenberg-sip-info-harmful-00). So, SIP INFO has it's share of pros & cons. > - I have observed that sending DTMF as RFC 2833 packets is mostly > preferred considering that sending DTMF In-band requires the remote > VoIP application to perform tone detection in RTP level which requires > considerable processing overhead as RFC also states. Is there a known > issue about SIP INFO method for DTMF sending? GK>> You are right that with in-band DTMF, you need to perform tone detection at RTP level which isn't exactly an ideal scenario. KPML is another mechanism for DTMF processing that you may want to explore. >From an interoperability stand point, it's good to support at least RFC 2833 & in-band modes. My 2 cents, Gaurav > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:sip- > [EMAIL PROTECTED] On Behalf Of Murat Artun > Sent: Wednesday, June 20, 2007 2:15 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [Sip-implementors] DTMF interoperability: In-band,RFC 2833 or SIP > INFO > > Hello all, > > I want to ask about the interoperability issues for DTMF sending. > > There exist three ways for DTMF sending: In-band (I use this term > meaning in audio as a voice data), RFC 2833 (currently 4733 obsoletes, > but no change to previous procedure exists) and SIP INFO. > > Among these three ways, I know that only RFC 2833 is announced in the > SDP of a VoIP application when it is ready to receive DTMF events as > RFC 2833 packets. > > I have a few points to be clarified in the sense of interoperability > issues: > > - Is it preferred that DTMF is also sent in-band and as SIP INFO when > the remote VoIP application announces that it is ready to receive RFC > 2833 packets? > > - What if the remote VoIP application does not announce that it is > ready to receive RFC 2833 packets? Which method should be preferred, > In-band or SIP INFO, or both for reliability purposes? > > - I have observed that sending DTMF as RFC 2833 packets is mostly > preferred considering that sending DTMF In-band requires the remote > VoIP application to perform tone detection in RTP level which requires > considerable processing overhead as RFC also states. Is there a known > issue about SIP INFO method for DTMF sending? > > Thanks in advice... > > -- > M u r at A r t u n, MSc. > Design Engineer > _______________________________________________ > Sip-implementors mailing list > [email protected] > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
