[Jingle] XEP-0181: Jingle DTMF

[Robert McQueen]

I'm of the opinion that the DTMF XEP is at best, pretty redundant, and
at worst, just broken:

* RFC 4733 already covers how to negotiate support for telephony events
as a payload type.
* Sending the DTMF via the signalling path loses you the timing
information, meaning the XMPP could take 2 seconds to arrive, and
then play over something you said after you thought the DTMF was all
finished. including it in the RTP stream as telephony events means
it's got correct RTP timestamps.
* The behaviour of the media stack for sending DTMF can be identical
between SIP and Jingle if RFC 4733 is just used as-is.
* Gatewaying the DTMF stream to a SIP endpoint is a no-op if RFC 4733
is used by all Jingle client, rather than requiring a) additional
support on the client to fall back and actually support two different
DTMF methods anyway, or b) have a gateway which can detect and
synthesize the RFC 4733 things. This all seems like un-necessary work
and a good way to just break interoperability.
* The simplification of not sending up and down events breaks the
ability to send arbitrary duration tones in real-time. Specifically,
when the user pushes the button down, I don't know how long a tone
they want. I should /start/ sending DTMF immediately, but not stop
until they release the button.

There was apparently some very compelling reason for having the DTMF
sent separately in the XMPP, but nobody I've spoken to here at the
summit can remember what it is[1]. If you know what this reason is,
please speak up, otherwise my recommendation is we just drop the entire
XEP-0181 and replace it with a recommendation in XEP-0167 that DTMF is
sent by telephony events as specified in RFC 4733.

Regards,
Rob

[1]: If it involves not using RTP, I don't think we care. Something
which puts a non-RTP call over Jingle and wants to do DTMF can define
its own session info events. Any meaningful interoperability with Jingle
RTP clients is obviously completely dead in that case, so the inevitable
gateway could just convert RFC 4733 stuff into whatever the non-RTP
thing used, but whoever deviates from the norm gets to do the extra work.

[Johansson Olle E]

I agree that in most situtations, DTMF in the media stream is to be
preferred, mostly because
of timing issues. In some cases, DTMF is handled out of band for IVR
situations, then maybe
KPML could be used in the XMPP stream. It's an XML-based definition in
RFC 4730.

Please also note that 4733 REQUIRES use of SRTP, where RFC 2833 doesn't.
That's propably why most SIP devices still only claim support of 4733.

/Olle

[Robert McQueen]

Johansson Olle E wrote:
> I agree that in most situtations, DTMF in the media stream is to be
> preferred, mostly because
> of timing issues. In some cases, DTMF is handled out of band for IVR
> situations, then maybe
> KPML could be used in the XMPP stream. It's an XML-based definition in
> RFC 4730.

What IVR situations can't just process the events out of the RTP stream
in order to find out what DTMF is being sent? I don't think this is a
compelling argument for either a) requiring clients to implement two
DTMF methods, or b) preventing DTMF interoperation between normal Jingle
and SIP endpoints unless the gateway does extra work.

> Please also note that 4733 REQUIRES use of SRTP, where RFC 2833 doesn't.
> That's propably why most SIP devices still only claim support of 4733.

I think 2833-compliant endpoints can still exchange telephony events
with 4733-compliant endpoints. It'd be pretty broken if that wasn't the
case. And it doesn't REQUIRE the use of SRTP, it just says this:

To meet the need for protection both of confidentiality and
integrity, compliant implementations SHOULD implement the Secure
Real-time Transport Protocol (SRTP) [7].

When we can signal SRTP, we'll probably say the same kind of thing too. :D

> /Olle

Regards,
Rob

[Johansson Olle E]

24 jul 2008 kl. 02.16 skrev Robert McQueen:

> Johansson Olle E wrote:
>> I agree that in most situtations, DTMF in the media stream is to be
>> preferred, mostly because
>> of timing issues. In some cases, DTMF is handled out of band for IVR
>> situations, then maybe
>> KPML could be used in the XMPP stream. It's an XML-based definition
>> in
>> RFC 4730.
>
> What IVR situations can't just process the events out of the RTP
> stream
> in order to find out what DTMF is being sent? I don't think this is a
> compelling argument for either a) requiring clients to implement two
> DTMF methods, or b) preventing DTMF interoperation between normal
> Jingle
> and SIP endpoints unless the gateway does extra work.

Well, I agree. SIP has way too many DTMF methods and we don't want to
fall into the same traps. Let's try to keep Jingle clean. At least
cleaner.

One big question here is how much we want to implement PSTN gateway
functionality. All of that is overloading SIP at this point. That's a
big design
decision moving forward, a decision that would help us sort out stuff
like
this. Is this something needed for jingle or something that is just
copied
from PSTN?

>
>
>> Please also note that 4733 REQUIRES use of SRTP, where RFC 2833
>> doesn't.
>> That's propably why most SIP devices still only claim support of
>> 4733.
>
> I think 2833-compliant endpoints can still exchange telephony events
> with 4733-compliant endpoints. It'd be pretty broken if that wasn't
> the
> case. And it doesn't REQUIRE the use of SRTP, it just says this:
>
> To meet the need for protection both of confidentiality and
> integrity, compliant implementations SHOULD implement the Secure
> Real-time Transport Protocol (SRTP) [7].

There was a discussion about this a while ago on one of the SIP mailing
lists where they emphasized that a SHOULD in an RFC should be parsed
as a requirement, unless you had extremely good reasons not to follow
it. For implementors a SHOULD should be treated as a MUST, according
to that discussion.

Also, please note this part above your quote:

"The telephone-event payload defined in this specification is highly
compressed. A change in value of just one bit can result in a major
change in meaning as decoded at the receiver. Thus, message integrity
MUST be provided for the telephone-event payload type."
So message integrity is a MUST; confidentiality with SRTP is a SHOULD.
/O

[Diana Cionoiu]

Hi Rob,

When you do PBX and you use DTMF's to make all kinds of functionalities,
than you need to have the DTMF's on the signalling path not in the RTP,
because the RTP goes directly between end points.
This is why SIP people added SIP INFO, so don't even think that you
don't need DTMF's in signalling.

Regards,
Diana

Robert McQueen wrote:
> Johansson Olle E wrote:
>
>> I agree that in most situtations, DTMF in the media stream is to be
>> preferred, mostly because
>> of timing issues. In some cases, DTMF is handled out of band for IVR
>> situations, then maybe
>> KPML could be used in the XMPP stream. It's an XML-based definition in
>> RFC 4730.
>>
>
> What IVR situations can't just process the events out of the RTP stream
> in order to find out what DTMF is being sent? I don't think this is a
> compelling argument for either a) requiring clients to implement two
> DTMF methods, or b) preventing DTMF interoperation between normal Jingle
> and SIP endpoints unless the gateway does extra work.
>
>
>> Please also note that 4733 REQUIRES use of SRTP, where RFC 2833 doesn't.
>> That's propably why most SIP devices still only claim support of 4733.
>>
>
> I think 2833-compliant endpoints can still exchange telephony events
> with 4733-compliant endpoints. It'd be pretty broken if that wasn't the
> case. And it doesn't REQUIRE the use of SRTP, it just says this:
>
> To meet the need for protection both of confidentiality and
> integrity, compliant implementations SHOULD implement the Secure
> Real-time Transport Protocol (SRTP) [7].
>
> When we can signal SRTP, we'll probably say the same kind of thing too. :D
>
>
>> /Olle
>>
>
> Regards,
> Rob
>

[Diana Cionoiu]

Hi,

I've forgot to mention that this applies also when you use SRTP. Because
you still can have something on the way doing the PBX functionalities,
so you still need the DTMF's on the signalling path.
I agree that Jingle shouldn't have everything for no good reasons, but
there are minimal features that is a must to be there.

Regards,
Diana


Diana Cionoiu wrote:
> Hi Rob,
>
> When you do PBX and you use DTMF's to make all kinds of
> functionalities, than you need to have the DTMF's on the signalling
> path not in the RTP, because the RTP goes directly between end points.
> This is why SIP people added SIP INFO, so don't even think that you
> don't need DTMF's in signalling.
>
> Regards,
> Diana
>
> Robert McQueen wrote:
>> Johansson Olle E wrote:
>>
>>> I agree that in most situtations, DTMF in the media stream is to be
>>> preferred, mostly because
>>> of timing issues. In some cases, DTMF is handled out of band for IVR
>>> situations, then maybe
>>> KPML could be used in the XMPP stream. It's an XML-based definition in
>>> RFC 4730.
>>>
>>
>> What IVR situations can't just process the events out of the RTP stream
>> in order to find out what DTMF is being sent? I don't think this is a
>> compelling argument for either a) requiring clients to implement two
>> DTMF methods, or b) preventing DTMF interoperation between normal Jingle
>> and SIP endpoints unless the gateway does extra work.
>>
>>
>>> Please also note that 4733 REQUIRES use of SRTP, where RFC 2833
>>> doesn't.
>>> That's propably why most SIP devices still only claim support of 4733.
>>>
>>
>> I think 2833-compliant endpoints can still exchange telephony events
>> with 4733-compliant endpoints. It'd be pretty broken if that wasn't the
>> case. And it doesn't REQUIRE the use of SRTP, it just says this:
>>
>> To meet the need for protection both of confidentiality and
>> integrity, compliant implementations SHOULD implement the Secure
>> Real-time Transport Protocol (SRTP) [7].
>>
>> When we can signal SRTP, we'll probably say the same kind of thing
>> too. :D
>>
>>
>>> /Olle
>>>
>>
>> Regards,
>> Rob
>>

[Peter Saint-Andre]

Robert McQueen wrote:

> There was apparently some very compelling reason for having the DTMF
> sent separately in the XMPP, but nobody I've spoken to here at the
> summit can remember what it is[1]. If you know what this reason is,
> please speak up, otherwise my recommendation is we just drop the entire
> XEP-0181 and replace it with a recommendation in XEP-0167 that DTMF is
> sent by telephony events as specified in RFC 4733.
>
> Regards,
> Rob
>
> [1]: If it involves not using RTP, I don't think we care. Something
> which puts a non-RTP call over Jingle and wants to do DTMF can define
> its own session info events. Any meaningful interoperability with Jingle
> RTP clients is obviously completely dead in that case, so the inevitable
> gateway could just convert RFC 4733 stuff into whatever the non-RTP
> thing used, but whoever deviates from the norm gets to do the extra work.

As Diana points out, RFCs 2833/4733 are RTP-specific. If in Jingle we
use transports other than RTP, we might want to define a method for
sending DTMF in the signalling channel. I agree that we could do that as
session-info messages, but that's what XEP-0181 defines. (!) So perhaps
it makes sense to let this gently lapse into deferred until someone
needs it?

/psa

[Robert McQueen]

Diana Cionoiu wrote:
> Hi Rob,

Hi there,

> When you do PBX and you use DTMF's to make all kinds of functionalities,
> than you need to have the DTMF's on the signalling path not in the RTP,
> because the RTP goes directly between end points.
> This is why SIP people added SIP INFO, so don't even think that you
> don't need DTMF's in signalling.

SIP calls can indeed be redirected from one proxy to another as they are
established in this PBX kind of use case, but this isn't normal in XMPP
at all. XMPP signalling is generally end-to-end, so having your call
signalling bounced between several XMPP entities as a call is
established/routed is very unusual. After you've decided who to call,
then you direct your Jingle calls by turning it into the JID you want,
and it's routed by XMPP servers who look at the address, not by punching
numbers.

Admittedly, it works differently depending if you're gatewaying or not.
Either:

You're talking to something which must be controlled by DTMF, so it's
going through a gateway to some kind of telephony service. This gateway
is talking XMPP to signal with you, and receiving your media, and then
passing it on however it wants. In this gateway situation, the the
Jingle client can use RTP DTMF with the gateway, which can either pass
it on if it wishes, or interpret it and make some signalling events if
it wishes.

Or:

You're /not/ talking to something which must be controlled by DTMF,
because it's an XMPP capable endpoint. You can control your Jingle
middle-man using something better than DTMF, so mapping DTMF tone
events into XMPP is meaningless. You can use XMPP technologies like
service discovery, ad-hoc commands, data forms, etc, to browse the men
or route your call or pick a song to play or whatever.

Either way, I don't really buy your reason at all. Note that the SIP
INFO DTMF method was added by Cisco who make their money selling you
expensive things which will take your SIP call and redirect it via or to
their other expensive SIP things. :P

It think it's really harmful for us to have two different mechanisms for
doing the same thing, one signalling mechanism which makes very little
sense and is required and has weird/useless semantics/timing, and the
other in the RTP stream which is far more interoperable but not required
to be supported by Jingle clients. It means everyone just has to have
two code paths for the same thing, even the gateways.

> Regards,
> Diana

Regards,
Rob

> Robert McQueen wrote:
>> Johansson Olle E wrote:
>>
>>> I agree that in most situtations, DTMF in the media stream is to be
>>> preferred, mostly because
>>> of timing issues. In some cases, DTMF is handled out of band for IVR
>>> situations, then maybe
>>> KPML could be used in the XMPP stream. It's an XML-based definition in
>>> RFC 4730.
>>>
>>
>> What IVR situations can't just process the events out of the RTP stream
>> in order to find out what DTMF is being sent? I don't think this is a
>> compelling argument for either a) requiring clients to implement two
>> DTMF methods, or b) preventing DTMF interoperation between normal Jingle
>> and SIP endpoints unless the gateway does extra work.
>>
>>
>>> Please also note that 4733 REQUIRES use of SRTP, where RFC 2833 doesn't.
>>> That's propably why most SIP devices still only claim support of 4733.
>>>
>>
>> I think 2833-compliant endpoints can still exchange telephony events
>> with 4733-compliant endpoints. It'd be pretty broken if that wasn't the
>> case. And it doesn't REQUIRE the use of SRTP, it just says this:
>>
>> To meet the need for protection both of confidentiality and
>> integrity, compliant implementations SHOULD implement the Secure
>> Real-time Transport Protocol (SRTP) [7].
>>
>> When we can signal SRTP, we'll probably say the same kind of thing
>> too. :D
>>
>>
>>> /Olle
>>>
>>
>> Regards,
>> Rob
>>
>
>

[Robert McQueen]

Peter Saint-Andre wrote:
>> [1]: If it involves not using RTP, I don't think we care. Something
>> which puts a non-RTP call over Jingle and wants to do DTMF can define
>> its own session info events. Any meaningful interoperability with Jingle
>> RTP clients is obviously completely dead in that case, so the inevitable
>> gateway could just convert RFC 4733 stuff into whatever the non-RTP
>> thing used, but whoever deviates from the norm gets to do the extra work.
>
> As Diana points out, RFCs 2833/4733 are RTP-specific. If in Jingle we
> use transports other than RTP, we might want to define a method for
> sending DTMF in the signalling channel. I agree that we could do that as
> session-info messages, but that's what XEP-0181 defines. (!) So perhaps
> it makes sense to let this gently lapse into deferred until someone
> needs it?

I still think it's best to make it very lapsed, because having two ways
to do it when RTP /is/ in use is pretty harmful I think. I think we
should put XEP-0181 on ice and instead just make it a MUST in the RTP
XEP that if you're doing DTMF, you use the RFC 4733 stuff. If we do fins
a stunningly important non-RTP content description that still needs us
to do gatewaying to PSTN and send DTMFs, we can cross that bridge when
we get to it. :)

> /psa

Regards,
Rob

[Peter Saint-Andre]

Robert McQueen wrote:
> Peter Saint-Andre wrote:
>>> [1]: If it involves not using RTP, I don't think we care. Something
>>> which puts a non-RTP call over Jingle and wants to do DTMF can define
>>> its own session info events. Any meaningful interoperability with Jingle
>>> RTP clients is obviously completely dead in that case, so the inevitable
>>> gateway could just convert RFC 4733 stuff into whatever the non-RTP
>>> thing used, but whoever deviates from the norm gets to do the extra work.
>> As Diana points out, RFCs 2833/4733 are RTP-specific. If in Jingle we
>> use transports other than RTP, we might want to define a method for
>> sending DTMF in the signalling channel. I agree that we could do that as
>> session-info messages, but that's what XEP-0181 defines. (!) So perhaps
>> it makes sense to let this gently lapse into deferred until someone
>> needs it?
>
> I still think it's best to make it very lapsed, because having two ways
> to do it when RTP /is/ in use is pretty harmful I think. I think we
> should put XEP-0181 on ice and instead just make it a MUST in the RTP
> XEP that if you're doing DTMF, you use the RFC 4733 stuff. If we do fins
> a stunningly important non-RTP content description that still needs us
> to do gatewaying to PSTN and send DTMFs, we can cross that bridge when
> we get to it. :)

I think Diana is saying that she has already arrived at that bridge and
that she needs in-band DTMF for her application. Yes, we can say that if
you're using RTP then do your DTMF signalling there. But if you're not
using RTP then do your DTMF signalling via XEP-0181.

/psa