So if I'm understanding it right, RFC2833 is negotiated in the SDP. If not, DTMF can be send as tones in rtp payload or as SIP INFO packets.
SIP INFO is not negotiated, but wil just be sent. At receiver side it can be accepted if supported, or if not supported it will be rejected with message 415 (Unsupported Media Type) and there will be no fallback to another way of sending DTMF. Met vriendelijke groet, with kind regards, mit freundlichen Gruß Peter Nijhuis peter.nij...@televersal.com Tel.: +31 13 5231189 Please consider the environment - do you really need to print this email? Dit e-mailbericht is vertrouwelijk en alleen bestemd voor de geadresseerde(n). Gebruik door anderen is niet toegestaan. Indien u niet de geadresseerde(n) bent, wordt u verzocht de verzender hiervan op de hoogte te stellen en het bericht te verwijderen. Aan de inhoud van dit bericht kunnen geen rechten worden ontleend. This e-mail is confidentail and may also be privleged. It is intended only for the addressee. If you are not the intended, we request you to Noltify us immediately and delete this e-mail. No rights may be derived from this e-mail. > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz > Castillo > Sent: woensdag 8 april 2009 1:06 > To: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] DTMF tones > > El Miércoles 08 Abril 2009, Paul Kyzivat escribió: > > "forget negotiation". Look at the base note of this thread. The guy > > needs a way to negotiate between INFO and 2833. > > > > Our products support 3 or 4 ways of sending DTMF. And ad hoc means of > > negotiating among them have been developed. > > > > Normally you don't want the DTMF both places, because that causes its > > own set of problems. Somebody instead filters the dtmf out of the > media > > and puts it in the signaling. We have very common situations where > one > > side has it in media and the other side needs it in signaling. During > > call setup we have to figure out whether to put in a media relay to > > convert between the two, or if we can omit that. > > Good reasons, you are right. For example there are phones sending DTMF > in both > SIP INFO and RFC2833 at the same time. How should react a UAS receiving > both? > which one to filter? the first arriving? > > > > > > Ok, let's make complex something so easy as DTMF. Now the solution > for > > > DTMF is KPML with lot of exotic XML and so on. Great, sure it will > > > inmediatelly adopted by most of the vendors and implementation, > sure. > > > > In retrospect, perhaps KPML was over engineered. > > If so, then it will not widely implemented. Vendors don't like complex > mechanisms. :( > > > Thanks. > > > > -- > Iñaki Baz Castillo <i...@aliax.net> > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
