[Standards-JIG] Jingle: DTMF
jean-louis.seguineau at laposte.net
Wed Feb 15 18:48:24 UTC 2006
Joe, this is exactly the kind of issues I was trying to express. You just
did it better ;)
Doing DTMF in the signaling path will in turn implies the gateway to be also
in the media path if it converts the signaling to DTMF tones. This will not
lead to scalable solutions, as you said.
There is another way to interact with media device. Many IVRs, almost all
PBXs and a large number of PSTN gateways offer a CSTA interface, or better a
CSTA-XML over SIP. If we want to pass commands in the signaling path, we
must consider a solution that would not require the media going through the
When the call is established with an IVR over RTP, we are better doing it
with RFC2833 (why re-invent the wheel).
In other cases, where CSTA information is available over SIP, we would be
better off using it. In this scenario, a CSTA enabled endpoint would be
providing the information on the signaling path without affecting the media
That said, it may not cover all use cases. I'm just saying it would be worth
Date: Wed, 15 Feb 2006 09:31:10 -0800
From: "Joe Beda" <jbeda at google.com>
Subject: Re: [Standards-JIG] Jingle: DTMF
To: "Jabber protocol discussion list" <standards-jig at jabber.org>
<dbfdfee20602150931l635cd2bu565f3e2f92d2e73f at mail.google.com>
Content-Type: text/plain; charset="iso-8859-1"
>From my quick research into the topic, it looks like there are two ways
SIP does DTMF:
1) Over RTP w/ rfc2833
2) Over the signalling path with a custom cisco SIP extension (
If someone wants to connect to a SIP network (the most common way to connect
to the PSTN network and a major scenario behind DTMF) then you are dealing
with one of these cases:
1) Requiring DTMF to go over the signalling pathway will, in effect, require
the media to go via the same path as the signalling. This is because the
gateway will have to interpret the media stream enough to hoist DTMF events
onto the signalling channel -- or if going the other way -- convert DTMF
signals to RTP packets. This means that a service provider would have to
relay *all* media traffic. This can add *significantly* to the bandwdith
cost of providing a SIP gateway.
2) Limit the types and numbers of PSTN service providers you can work with
because they may or may not support the cisco extension. It isn't clear to
me how widely supported this extension is.
So -- in the interests of being pragmatic, we should support both ways of
doing DTMF. In an ideal world we wouldn't have to do this two ways but we
don't live in an ideal world.
Support for RFC 2833 is signalled in jingle-audio by declaring support for
that 'payload-type''. We should have another element under the jingle-audio
description to signify support for DTMF 'info' messages over the XMPP
More information about the Standards