Re: Detecting DTMF tones on a SIP voice session

Jonathan Rosenberg <jdrosen@dynamicsoft.com> Fri, 29 October 1999 04:28 UTC

Received: from lists.research.bell-labs.com (paperless.dnrc.bell-labs.com [135.180.161.172]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01067 for <sip-archive@odin.ietf.org>; Fri, 29 Oct 1999 00:28:19 -0400 (EDT)
Received: by lists.research.bell-labs.com (Postfix) id F1C5A52F3; Fri, 29 Oct 1999 00:24:04 -0400 (EDT)
Delivered-To: sip-outgoing-local@paperless.dnrc.bell-labs.com
Received: by lists.research.bell-labs.com (Postfix, from userid 20006) id EFA3552F4; Fri, 29 Oct 1999 00:24:02 -0400 (EDT)
Delivered-To: sip-local@paperless.dnrc.bell-labs.com
Received: from grubby.research.bell-labs.com (grubby.research.bell-labs.com [135.104.2.9]) by lists.research.bell-labs.com (Postfix) with SMTP id 1CEBA52F3 for <sip@lists.research.bell-labs.com>; Fri, 29 Oct 1999 00:23:12 -0400 (EDT)
Received: from dusty.research.bell-labs.com ([135.104.2.7]) by grubby; Fri Oct 29 00:21:15 EDT 1999
Received: from wodc7mr3.ffx.ops.us.uu.net ([192.48.96.19]) by dusty; Fri Oct 29 00:20:19 EDT 1999
Received: from dynamicsoft.com by wodc7mr3.ffx.ops.us.uu.net with ESMTP (peer crosschecked as: 1Cust100.tnt1.freehold.nj.da.uu.net [63.17.113.100]) id QQhmyz26733; Fri, 29 Oct 1999 04:24:41 GMT
Message-ID: <38192104.E6CFC67E@dynamicsoft.com>
Date: Fri, 29 Oct 1999 00:22:28 -0400
From: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
Organization: Dynamicsoft
X-Mailer: Mozilla 4.7 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Gregory D. Girard" <ggirard@mediaone.net>
Cc: Henning Schulzrinne <schulzrinne@cs.columbia.edu>, SIP List <sip@lists.research.bell-labs.com>
Subject: Re: Detecting DTMF tones on a SIP voice session
References: <008301bf21b4$e0236870$122cda18@goliath.ne.mediaone.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-sip@lists.research.bell-labs.com
Precedence: bulk
Content-Transfer-Encoding: 7bit


"Gregory D. Girard" wrote:
> Thanks so much for the information. In my opinion, it important that one way
> or the other makes its way into the new SIP standard as required elements.
> Lucent, in particular, has absolutely no intention of doing anything to
> allow third party call control of their Softswith. The reason is a separate
> discussion that we can have some time. They do, however, tout a SIP
> signaling interface. If SIP requires support for this feature, the Lucent
> Softswitch will provide de facto support for third-party call control and
> the critical DTMF functionality discussed. To allow the feature to remain a
> simple SIP enhancement would not accomplish the goal of having SIP serve as
> the universal IP Telephony call control and signaling interface that it
> potentially could be.

SIP does not, can not, and should not specify RTP payload formats and
codecs. DTMF is an example of such a codec. If your system wants to use
it, go ahead. SIP/SDP allows such information to be signaled.

> 
> 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.

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.

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.

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