Peter Nijhuis wrote:
> 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.
Or *not* 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.
You have summarized fairly well. Except that KPML may also be negotiated
(via a SUBSCRIBE message). Its availablility can be indicated via
Allow-Events.
Thanks,
Paul
> 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
