Subject: Re: Detecting DTMF tones on a SIP voice session

From: "Gregory D. Girard" <[email-masked]>
Date: Fri, 29 Oct 1999 08:25:19 -0400

Jonathan,

Here is an example regarding DTMF.
The RTP stream being examined may be terminating on a Media Gateway under
control of a Softswitch. My application server is not the Softswitch, but it
attempting to use the switching and DSP resources of the Softswitch through
SIP. In this case, I would like my app to be able to "listen" to DTMF digits
on a connection bridged through the Softswitch w/out necessarily extending
an RTP stream to a media server. It is better for me to let the Softswitch
figure out the DTMF sequences and just forward them to me as SIP messages.

In other words, I don't want to be required to move RTP data from the Media
Gateway to my application server (RTP interface) or some other media server,
and then have to pipe it through DSP hardware just to know the user pressed
"5". If the RTP stream is used as the DTMF source, then the benefits of an
IP interface are largely lost due to the need for additional DSP hardware on
my (media server) endpoint.

For years it has seemed to make no sense to have to transmit digit sequences
in-band as tones that have to be decoded with a DSP rather read as simple
data messages. Virtually all digital telecommunications protocols (like ISUP
or the Q.931 message set for ISDN) abstracted those digits our of the media
channel and presented them as outband signals that may be directly
manipulated in a programatic fashion.

If SIP is to at the very least match the functionality of ISUP (to say
nothing of its areas of great advantage) it will have to (in my humble
opinion) incorporate DTMF as an out-band signaling mechanism. To push this
responsibility back on terminal device and force examination of the media
stream is big step backwards when practical application development matters
considered.

If nothing else, such a situtation will give SIGTRAN a big advantage over
SIP due to the richness of its message set.

....more below in response to your comments...

>>
>> Option 1 below is less desireable than option 2 for two reasons:
>>
>> 1- Requires one or more RTP streams even though application may only
require
>> DTMF digit sequence to provide a service
>
>I too don't understand this.
>
>> 2- Requires that digit sequences come in a serial fashion and may return
too
>> much useless information.
>>
>> In contrast, the INFO solution would allow the media gateway internal
>> functionality (as defined for MGCP) to match the digit map prior to
>> returning anything at all.
>
>Not true. I interpret your concern 2 as follows: "I don't want to send
>each digit one at a time to the IVR system; I'd rather have some
>internal logic based on digit maps that sends them in groups". If this
>is the case, it can be done with either RTP or the INFO method. With
>RTP, you would delay sending the packets containing DTMF until you had
>matched the digit map, and then send them in a clump together. This
>would allow you to use long durations for each digit (not too long, for
>reliability purposes), making it more efficient.

GG: Yes, this is a correct understanding of my point.

>
>An advantage of the RTP approach is that you don't restrict the user
>interaction to DTMF. Many IVR systems these days allow both tone and
>voice recognition - "say or press 1 to speak to a representative". Now,
>if you ship DTMF over INFO, you will absolutely not be able to do this.
>However, using DTMF RTP, which I believe to be the superior solution,
>allows such applications to exist.

GG: Yes to tone and voice input for IVR systems, however the speack recogo
is almost universally
"host-based" these days, meaning that the incoming voice is recorded and
passed to an
ASR engine residing on the application server. Most modern ASR uses HUGE
vocabularies that
are dynamically enabled and disabled for the ASR engine. This is far too
much of a task to be
buried in a terminal device except for very simple "voice activated dialing"
stuff in phones. Importantly,
speach reco does not require dedicated DSP HW like real-time DTMF decoding,
and thus the
application server may still operation on a pure-SW basis to provide very
sophisticated voice reco apps.
This circumstance argues for the INFO method.

>
>Whenever the device which needs to use DTMF for features is acting as a
>UA, there is almost never a reason to use SIP to transport DTMF. RTP
>works best in this case, and IVR falls into this category.

GG: Please indulge me in what I'm about to say because I'm still getting up
to speed on SIP. In your above comment, you mention
the application server ("device which needs to use DTMF") as almost never
needing to use SIP to transport DTMF. Well, I
would argue that any device capable of originating or answering an INVITE
(connection request) should be able to "listen" for
DTMF tone sequences from the other end.

>
>-Jonathan R.
>--
>Jonathan D. Rosenberg                       200 Executive Drive
>Chief Scientist                             Suite 210
>dynamicsoft                                 West Orange, NJ 07052
>[email-masked]                     FAX:   (732) 741-4778
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>http://www.dynamicsoft.com
>

---

From: Anders Kristensen <[email-masked]>
Date: Fri, 29 Oct 1999 14:02:01 +0100

I have some sympathy for your DTMF-in-RTP gripes, but I'm not sure its
really accurate to call RTP carried DTMF "inband" signalling.  You'd
arrange for the gateway to detect DTMF and send collected digits in a
DTMF RTP stream to your app server. The server does NOT need DSP
resources as its just going to receive low-bandwidth DTMF packets which
happen to be ancapsulated in RTP packets... it doesn't have to process
the entire audio stream.

-- 
Anders Kristensen <[email-masked]>,
http://www-uk.hpl.hp.com/people/ak/
Hewlett-Packard Labs, Bristol, UK

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 29 Oct 1999 09:59:04 -0400

> my (media server) endpoint.

No. As Anders correctly stated, the DTMF over RTP *does not* send the
DTMF as normal audio. It is explicitly named by either a frequency or
the actual meaning (i.e., digit 1). Please take a look at
http://www.ietf.org/internet-drafts/draft-ietf-avt-tones-02.txt.

> manipulated in a programatic fashion.

Using the DTMF payload format gets you the best of both worlds. You
still get the DTMF sent "out of band" in the sense that its not as
audio, but as named tones/events. But, you get the synchronization and
generality of having them in the RTP stream. 

> stream is big step backwards when practical application development matters

Again, see above. You are getting what you want.

> SIP due to the richness of its message set.

SIPs strength is not that it can emulate completely ISUP (although I
believe we can do all the call signaling we need for traditional
telephony), but that it does so much more. Its use of MIME, general
URI's, and its close relationship with http and smtp means its a great
tool for creating services that integrate web, email, and telephony. Its
hard, IMHO, to argue against a protocol that can do the basic stuff, as
all these protocols can, but leaves the door open for bringing telephony
into the Internet era. Tunneling ISUP over sigtran gets you toll bypass
just fine, but last I checked ISUP didn't carry URLs for redirecting
calls to web pages.....

> This circumstance argues for the INFO method.

No. As discussed above, you will not need to do any DTMF detection, as
its already done. Furthermore, no matter where you do the IVR services,
being able to support "press or say 1" is most easily supported when
pressing 1 or saying 1 are in the same place. Not having this means you
get all kinds of nasty synchronization problems between the signaling
messages and the media streams.

> DTMF tone sequences from the other end.

Thats what I'm saying; if a device that needs DTMF is the one that sends
and receives INVITEs, using RTP to carry the DTMF events is always a
better solution.

-Jonathan R.

---

From: "Lyndon Ong" <[email-masked]>
Date: Fri, 29 Oct 1999 08:56:18 -0700

>> opinion) incorporate DTMF as an out-band signaling mechanism. 

But ISUP does not do generic DTMF transport - it only transports DTMF that has been recognized by the originating switch as comprising the dialed number.  ISUP will not transport DTMF digits received after call setup, this goes in-band.

Also, DTMF over RTP is independent of whether SIP, Megaco or H.323 is used by the end systems.

Cheers,

L. Ong

---

From: Jean-Hugues ROBERT <[email-masked]>
Date: Fri, 29 Oct 1999 17:30:17 +0200

Hi,

I believe there is a confusion about third party control
& DTMF.

1) Third party control

This is about the remote 'control & observation' of a SIP
call, by a third entity, neither the caller nor the callee.

Example of third party control (Distributed IVR):

	Customer make a Call to Company (INVITE)
	Company SIP Server redirect call to IVR Application (BYE(Also))
	IVR Application redirect Call to Announcement Server (3rparty-INVITE)
	Announcement Server Play 'Greeding + please enter you ID'
	IVR Application receives entered ID (one digit at a time or as a block, INFO)
	IVR Application transfers Call to proper destination (3rparty-BYE(Also))

As you can see the RTP stream never terminates at the IVR Application.
It terminates at the Announcement Server.
However the 'control' is done by the IVR Application, the Announcement Server
is merely a media resource under the control of the IVR Application.

This is a mean to achieve control / media separation, where the media is
handled by a media entity distinct from the control entity.

This separation of concern / untighting between media & control is one of the
advantages of third party control. One can argue that this is already done
in SIP with SDP. However the DTMF issue is not clearly solved.

This achievement was reached in the MGC/MG solution using MGCP (now MEGACO),
as pointed out earlier. Lucent Softswitch (& others) can already get
DTMF without terminating the media.

Something similar in the SIP world would be nice too.

Please note that the media / control distinction is at the heart of the
Intelligent
Network architecture (SS7, more than ISUP).

A simple solution to extend SIP for third party control would be to
consider a SIP endpoint as an '3rd party relay'.
	On receipt of 3rd-INVITE the relay understand that it is in presence
	of a third party initiated call.
	It sends the INVITE as if initiated locally.
	And from now on it proceeds normally but:
		Every message it receives or sends from/to the remote entity
		is 'relayed' (copied, notified) to the 3rd party that initiated
		the call (Notified-Entity).
	That way the 3rd party can 'observe' the call.
	The 3rd party may also 'control' the call (BYE, re-INVITE...), by
	ways of 3rd-BYE...
	Nota: this could be implemented by adding an optionnal parameter
			"Notified-entity:3RD-PARTY-SIP-URL"

Third party control is at the heart of CTI in the enterprise world.

2) DTMF

DTMF signal can be carried with RTP using to solutions:
	Blended with the media stream (G711 payload for example)
	On the media stream with a specific payload (dtmf or tone payload)

Obviously the second solution helps detecting DTMF at the receiving
entity. No DSP is needed to analyse the sound. The detection was
either done in a PSTN-GW or the dtmf payload was directly sent by
the remote entity.

This is nice.

But one can argue that both scheme are in fact 'in-band' signaling.
'out of band' signaling would then mean that another entity, distinct
from the one that receives the media, would receive the dtmf RTP payload.

Unfortunately I do not believe there is a way for a SDP profile to
specify how to achieve that. Maybe we can get by using 2 SDPs, one
for voice (G711 or whatever) and another for DTMF. If this can work
then we can specify distinct entities, one in each SDP.

The previous IVR example becomes:

	Customer make a Call to Company (INVITE)
	Company SIP Server Redirects Call to IVR Application.
	IVR Application act as a proxy and Forwards the Call to
	the Announcement Server, asking for DTMF notifications to
	be delivered to it (INVITE(sdp1,sdp2)).
	When IVR Application receives enough DTMF it transfers the
	initial Call to the proper destination (BYE(Also))
	And then breaks the Annoucement leg (BYE)

In this case the Annoucement Server terminates the 'voice' part of
the RTP Media Steam, and the IVR terminates the 'dtmf' part of the
steam.

Which solution is more SIP, third party control or dual SDPs ?
Are there other ongoing work on that matter ?

Thanks,

Jean-Hugues Robert
Engineering Manager

--------------------------------------------------------------------
[email-masked]                                        "Think globally.
www.8x8.com                                            Act locally."

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 29 Oct 1999 19:08:15 -0400

Igor Slepchin wrote:
> 
> Jean-Hugues ROBERT wrote:
> >

> 
> v=0
> o=bob 5675785768 IN IP4 host.example.com
> s=DTMF example
> m=audio 48906 RTP/AVP 0
> c=IN IP4 host.example.com
> a=rtpmap:0 PCMU/8000
> m=audio 76990 RTP/AVP 100
> c=IN IP4 ivr.example.com
> a=rtpmap:100 dtmf_tone/8000
> 
> RFC2543 never defines this kind of payloads but I don't think that it
> specifically disables this either.

Since SIP tries to be session-description-neutral, it shouldn't have to
say anything about this. Yes, having different destination addresses
might actually be quite common, even beyond DTMF. Imagine, for example,
a videophone, with audio going to an Internet phone and video to the PC
next to it. The PC would act as the MGC, for example. Or you could have
several video screens for a whole video wall for large conferences.

> Also, I am not sure what the encoding
> name for DTMF stream should be since draft-ietf-avt-tones-02.txt only
> defines the MIME types, audio/tone and audio/telephone-event.

I believe they are defined as 'tone' and 'telephone-event' in the draft:

e.g., "The RTP payload format is designated as ``telephone-event'', the
MIME type as
``audio/telephone-event''."

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 29 Oct 1999 19:00:39 -0400

> then we can specify distinct entities, one in each SDP.

Actually, SDP allows specifying multiple media streams with different
connection parameters (c= lines) within a single SDP session. Thus, you
could use the following SDP payload to have DTMF stream sent to a
different entity than the media stream:

v=0

RFC2543 never defines this kind of payloads but I don't think that it
specifically disables this either. Also, I am not sure what the encoding
name for DTMF stream should be since draft-ietf-avt-tones-02.txt only
defines the MIME types, audio/tone and audio/telephone-event.

---
Igor Slepchin