Subject: Additional Info on DTMF under SIP

From: "Gregory D. Girard" <[email-masked]>
Date: Wed, 10 Nov 1999 04:26:53 -0500

DTMF under SIP

There has been much speculation on the transmission of DTMF digits for a SIP
session. Two methods have been proposed, one using INFO messages and the
other embedding the DTMF information in the RTP stream. Suffice it say that
under most conditions, both methods may prove satisfactory. My objections to
the use of the RTP stream method have heretofore been based upon 2 points:

1- AWKWARD: Not elegant insofar as it requires going to two separate places
to get information about same session; this approach would seem to voilate
the principles of simplicity and consistency that underpin clean, reliable,
flexible designs.

2- DEPENDENT ON CONNECTION NOT NECESSARILY PRESENT IN MODEL: Relies upon
media stream that is not guarranteed to exist for every session, or at least
not exist in terms of a call leg (RTP stream) directed specifically to the
Enhanced Service Platform that requires the DTMF. The entity performing the
session control using SIP may not be the anouncement server or have any RTP
capability. Remember there is added cost to supporting the RTP interface to
the extent that more HW may be needed in most cases.

Well, here is a new reason to object, and perhaps the most compelling reason
of all:

3- PROTOCOL DEPENDENT: All proposals for DTMF via RTP presume an IP bearer
channel transport. This is nolonger a valid assumption given the recent and
surprisingly strong rise in VoATM solutions. It seems clear to me that any
DTMF solution that REQUIRES an IP transport for the  media stream is
dead-on-arrival for this reason alone. There is nothing to suggest that any
IP technology at all would be used for bearer channel content in many
solutions (I know of a few in particular right now).

Now to further suggest on supporting an RTP stream interface (alongside the
ATM interfaces) soley for the purpose of collecting DTMF digits just won't
fly from a cost perspective. I believe it is a valid assumption to be IP
dependent for control information/protocols - this is an established
methodology for data communications, but not for bearer channel content.
When we utilize what is in essessence a bearer channel pathway to transmit
DTMF control information, we bind our method to a single bearer transport. I
believe that result is wholly inconsistent with the softswitch model.

Just a few thoughts to consider...

Greg Girard
CTO
Iperia, Inc.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 10 Nov 1999 04:45:30 -0800 (PST)

> the use of the RTP stream method have heretofore been based upon 2 points:

   I think you're setting up a false dilemema here.
   RTP transport is a perfectly reasonable means
   of transport when the end SIP has no investment
   in the digits themselves, but they still need
   to be reliably transported. A good example is 
   using your answering machine when the audio
   codec is G.723.1.

 > the principles of simplicity and consistency that underpin clean, reliable,

   I'm not sure that I buy this. The same comment
   could be made for speech recognition. Surely
   there is a place for end-side recogntion based
   to the audio stream. In fact, that's the way I'd
   expect things to work for a long time coming.

 > the extent that more HW may be needed in most cases.

   Er, uh, the main cost is in the DTMF detector
   itself. If the idea is to save money on the
   terminating SIP, either SIP based transport
   or RTP transport will work equally well. I'm
   finding it rather difficult to believe that
   opening a socket to read NSE's for a session
   is going to set an application over some
   hardware boundary.

 > solutions (I know of a few in particular right now).

   Uh, both FRF.11 and AAL-2 support very similar
   mechanisms to transport DTMF as NSE's. AAL-1
   uses G.711 so relay is not an issue. I don't
   see what the dilemma is here.

   One of the things that you're not mentioning is
   timing. An originating side DTMF detector which
   transports DTMF via signaling will never have
   a precise timing relationship with the actual
   bearer. This could lead to some very odd things
   happening with retransmission timers, as an
   example (eg, I press '#' and two seconds later
   due to transmission loss it plays the # at the
   far end after I had already decided that it
   didn't "hear" the digit).
   
   My general rule: if you want to see it, signal
   it, otherwise transport it "inband" (via G.711
   or some bearer relay).

		  Mike

---

From: "Michael A. Ramalho" <[email-masked]>
Date: Wed, 10 Nov 1999 08:39:26 -0800

Gregory,

I ditto Mike Thomas' comments below ... and have a question for
you.

Where have you been since 1996 ... as this discussion on DTMF issues
date back to that timeframe?

Back then, most of the discussion revolved around the tradeoff of reliability
vs timing accuracy; the TCP reliability at the expense of delay under
packet loss vs. RTP method which preserved timing relationships at the
cost of adding RTP redundancy. Timing (inter DTMF tone timing in
particular) is assumed for many IVR applications (e.g., banking).

In fact, it could be shown that under certain packet loss conditions that
the TCP channel would have died and the RTP (w/redundancy) method
would have been successful. These high-loss conditions are probably
not your application area (with ATM cell losses on the order of 1 in 10^6),
but they are for other application spaces.

Mike's other comments are good also ... but I would suggest that you
read the minutes of past IETF avt wg meetings for a rendering of
some of the tradeoffs discussed in the past. Also, the Schulzrinne/Petrack
RTP payload draft for DTMF/Telephony Tones/Signals provides another
good reference (ietf-avt-tones-01.ps).

Michael Ramalho

>   it, otherwise transport it "inband" (via G.711

Michael A. Ramalho, Ph.D.
Cisco Systems
Wall Township, NJ
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.809.0188 <-NEW!

---

From: Jean-Hugues ROBERT <[email-masked]>
Date: Wed, 10 Nov 1999 18:21:09 +0100

Hi,

Looks like we do not progress very fast on this topic.

I now believe that both means of conveying DTMF are
needed. Because there are two distinct requirements.

1) Reliable and timely transport of DTMF at the media level (user plane).
	RTP is good here.
2) Supervisory of DTMF at the signal level (control plane)
	SIP dtmf INFO is good here (as a negotiated option probably).

There are many applications based on DTMF today. Voice is the future.
Lets handle both well.

Of course one can "get by" with any one of the solutions, but it can be
very inconvenient (specially when SIP and RTP do not terminate at the
same entity) :

Only RTP:
	You negotiate multiple SDPs. One for voice & DTMF will be direct
	between the endpoints. Another one for DTMF only will be directed to
	"supervisory"	entity. You need RTP besides SIP in supervisory entity.
	You need to support multiple SDPs in DTMF sender endpoint.

Only SIP:
	You reinject DTMF tones inside the RTP jitter buffer. All
	SIP msgs need to be intercepted/relayed by the "supervisory"
	entity. You need SIP besides RTP in the DTMF receiver endpoint.

I dislike both. I prefer having RTP only, because I believe that handling
multiple SDPs requires less hardware than handling SIP in addition to RTP
and I believe that VoIP market needs cheap IP phones.

My 2 cents...

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

---

From: Jean-Hugues ROBERT <[email-masked]>
Date: Wed, 10 Nov 1999 18:25:01 +0100

Hi,

>date back to that timeframe?

Do you mean that some consensus was achieved in 1996 and that still no 
widespread / standard implementation is available ? How is that ?

Jean-Hugues Robert.

---

From: "Jason Emery" <[email-masked]>
Date: Wed, 10 Nov 1999 14:49:09 -0500

Has anyone looked into how this was addressed in H.323?

I believe the H.323 standard suggests a solution like the INFO message.

How have they dealt with the time sensitivity issues outlined here?

Is there any value in following the H.323 lead?

Jason Emery
Nortel Networks

---

From: Dean Willis <[email-masked]>
Date: Wed, 10 Nov 1999 15:14:17 -0600

I think the real situation is much simpler:

If DTMF is to be carried to "the other end", it should be transported in the
RTP. Trying to remix signals that occur on the signaling path instead of the
media path is intractable. In other words, I think DTMF detection signalled
as an INFO message should never be reinserted into the audio stream.
Therefore, one needs RTP and INFO.

If DTMF needs to be sent to the control plane -- i.e. the detection of DTMF
is being sent to a supervisory system, many benefits are gained by adding
INFO support. These include:

1) Reliability
2) Simplification of the control application
3) Delivery of the detected DTMF to as many proxies in the signaling chain
as need it.
4) Transparency of the signaling path to the UA -- INFOs can be moved along
the proxy path, whereas RTP would either require either an RTP proxy chain
and vast amounts of additional signaling OR a direct RTP paths between the
UA and N-many control nodes. This also simplifies the UAS implementation.

Look, there's a reason why MGCP defined an event package for DTMF instead of
just sending the RTP all the way to the softswitch. This is exactly the same
thing, with a distributed control model described by the proxy chain. I
suspect it is the same reason that led to detected DTMF being transmitted in
user-info in H.323.

There's a non-aristotelian aspect here -- knowledge of a keypress is not the
same as the data of the tone produced by that keypress.

--
Dean Willis

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jean-Hugues
> ROBERT
> Sent: Wednesday, November 10, 1999 11:21 AM
> To: Michael Thomas; Gregory D. Girard
> Cc: [email-masked]; Dye, Robert
> Subject: Re: Additional Info on DTMF under SIP
>
>
> Hi,
>

---

From: Jiri Kuthan <[email-masked]>
Date: Wed, 10 Nov 1999 23:56:52 -0600

> particular) is assumed for many IVR applications (e.g., banking).

Please, could you explain me why timing is assumed for many IVR applications?
 The most IVR applications I know need realiable in-order delivery rather than
exact timing. In my understanding, a banking IVR from the example will be
affected by insufficient reliability (i.e. by a loss of a digit) rather than by
missing
timing accuracy.

> but they are for other application spaces.

The RTP method (avt-tones) meets certainly requirements of most applications.
However, if a bursty loss or jitter occurs it may fail to deliver a DTMF digit.
This is not so likely if DTMF/SIP-INFO/UDP is used, since the recevier's
SIP stack (unlike RTP stack) does not impose real-time constraints which
may lead to packet discarding and its exponential back-off retransmission mechanism
resists bursty loss better. Thus, applications with a strong need for reliable
in-order delivery like the phone banking application may prefer to choose this
method.

Additionally, DTMF/SIP-INFO
- may explore the SIP security which is likely to find faster acceptance than RTP
security
- may be preferable if the signaling path difers from media path (e.g. if an IVR
  consists of two boxes with signaling and IVR intelligence residing in one unit
  and media player/recorder in the other)

Jiri
--
Jiri Kuthan, MCI WorldCom, E-mail [email-masked], VNET 777-6536, phone
972-729-6536

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Nov 1999 14:58:16 -0500

> affected by insufficient reliability (i.e. by a loss of a digit) rather than by

The time it takes to recover from a single loss of the INFO packet can
be several seconds. Now, lets look at your banking application. The
machine says "enter the amount now". Then, I press "1", but it is lost.
As the banking system doesn't get the digit yet, it continues to talk to
me, and I think it didn't work, so I press "1" again. Both then arrive,
and I've just transferred twice the amount needed.

Note that a single loss will not have such an affect on the RTP
encapsulation. In the case of heavy bursty losses, neither approach will
work. I won't be able to hear the audio from the IVR system telling me
to enter my digits, and the delays until the digits register might be so
bad that the above problem is significantly amplified. To realistically
deploy IP based IVR banking solutions, you must have good transport
service, period.

>   and media player/recorder in the other)

I'm glad you raise this. I believe it is precisely this case where RTP
encapsulation is superior. In the model above, there is a controller
which is responsible for the service. It issues commands, and gets
responses, from a media device that plays the audio and receives the
audio. These commands probably include things like "play this
announcement", or "speak the number 55". The decisions the controller
makes about what to do are going to be based on *both* the digits (and
voice) the user inputs (number 5 was pressed), as well as the state of
the media device (finished playing announcement X).

In this architecture, we also have it such that the signaling goes to
the controller, and the media to the media device. There is some kind of
control and response protocol (MGCP plus some package for IVR, or
something equivalent). So, our architecture is this:

   +----------+
   |controller|  --------------SIP-------------------
   |          |
   +----------+
        |
        |
       MGCP
        |
        |
   +----------+
   |  media   |
   | device   | ---------------RTP --------------------
   +----------+

Now, if the DTMF is being transported by INFO, the controller is
receiving data about the service progression from two independent places
- the media device, and the SIP stream from the user. Lets say the media
device is playing some announcement, and then reports to the controller
that the announcement finished playing, and then a SIP INFO method
arrives containing the digit 3. Did this digit get dialed before, or
after, the tone finished playing? What if it matters? Perhaps I replay
the announcement on timeout, but play some other announcement if a key
is pressed? 

Consider also the case where the calling user doesn't have the DTMF
codec. Now, we need to place this function in the media device. The
controller won't know, in this case, whether the dtmf reporting will
come from the media device or the SIP signaling. Worse yet, what if it
gets both? Lets say a user has a DTMF codec, but its not very good. The
user presses 7, which the DTMF codec fails to detect, so it gets sent in
the audio stream. Then, the user presses 8, and this is send as an INFO
payload. The poor controller receives a report of a digit 7 from the
media device, and an 8 in the INFO method. Which came first?????

It gets even worse. Even a good DTMF detector takes some time to detect.
Thus, the beginning part of the DTMF may get into the audio stream (some
implementations force buffering at the sender to allow these packets to
be discarded; that doesn't work for frame based codecs where the DTMF
might cross frame boundaries...). Thus, the media device may report a
digit, and its also sent in the INFO method. The result is duplication
at the controller. Just what I want - insertion of an extra 0 in my
withdrawal amount.

Since, in this architecture, the media device is *already* reporting
events to the controller, and since we have also determined that it must
be prepared to do dtmf detection and report digits anyway (this is a
standard baseline function for an MG in the MGCP architecture), what is
gained by ALSO forcing the controller to expect the DTMF in the
signalling stream?

There is also the issue of voice recognition. "Say or speak 1" simply
doesn't work with dtmf over INFO, but works nicely if the dtmf reporting
is done in the media device only. In fact, having the dtmf sent in RTP,
and reported by the media device, means the controller doesn't even need
to know (although it can) whether the 1 was spoken or pressed. 

Control systems are harder to do when the data about the controlled
device state is being reported by two independent, unsynchronized
sources. All of the problems above go away by keeping the DTMF transport
within RTP.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       200 Executive Drive
Chief Scientist                             Suite 120 
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: Jean-Hugues ROBERT <[email-masked]>
Date: Thu, 11 Nov 1999 18:06:50 +0100

Hi Dean,

>Therefore, one needs RTP and INFO.

DTMF is an issue with some codecs. That is the main reason why they must
be transported using a specific RTP payload.

Another reason is that DTMF tone detection, when it is needed, can
sometimes be more cost effective if done by the sending entity, while
still handled "in-band" for convenience.

Regarding the "reinsertion" of DTMF tone inside the media stream...
well it is the only solution that I found to "get by" with a SIP
dtmf INFO  when the sending entity does not have a DTMF payload
and when the codec does not handle DTMF well. It is ugly. That is
why I believe both SIP dtmf INFO and DTMF RTP payload are needed.

>INFO support.
> ...

I agree.

>just sending the RTP all the way to the softswitch.
> ...

ditto

>I suspect it is the same reason that led to detected DTMF being
transmitted in
>user-info in H.323.

It may be H.323's solution to DTMF unfriendly Codecs...

>same as the data of the tone produced by that keypress.

That is an interesting point, should we need a SIP keypressed INFO msg :-)

Sometimes WorseIsBetter. There may not exist such a thing as an "elegant
DTMF handling". Who says "PSTN is elegant" anyways ?

Jean-Hugues Robert