[Jingle] XEP-0181: Jingle DTMF
robert.mcqueen at collabora.co.uk
Wed Sep 3 19:48:25 CDT 2008
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.
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
Admittedly, it works differently depending if you're gatewaying or not.
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
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.
> 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) .
>> When we can signal SRTP, we'll probably say the same kind of thing
>> too. :D
More information about the Jingle