[Jingle] XEP-0181: Jingle DTMF

Robert McQueen robert.mcqueen at collabora.co.uk
Tue Jul 22 18:52:47 CDT 2008


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.


More information about the Jingle mailing list