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
- Re: Detecting DTMF tones on a SIP voice session Gregory D. Girard
- Re: Detecting DTMF tones on a SIP voice session Adam B. Roach
- Re: Detecting DTMF tones on a SIP voice session Gregory D. Girard
- Re: Detecting DTMF tones on a SIP voice session Igor Slepchin
- Re: Detecting DTMF tones on a SIP voice session Gregory D. Girard
- Re: Detecting DTMF tones on a SIP voice session Henning Schulzrinne
- Re: Detecting DTMF tones on a SIP voice session Anders Kristensen
- Re: Detecting DTMF tones on a SIP voice session Lyndon Ong
- Re: Detecting DTMF tones on a SIP voice session Jonathan Rosenberg
- Re: Detecting DTMF tones on a SIP voice session Jiri Kuthan
- Re: Detecting DTMF tones on a SIP voice session Henning Schulzrinne
- Re: Detecting DTMF tones on a SIP voice session Jonathan Rosenberg
- Detecting DTMF tones on a SIP voice session Gregory D. Girard
- Re: Detecting DTMF tones on a SIP voice session Henning Schulzrinne
- Re: Detecting DTMF tones on a SIP voice session Jean-Hugues ROBERT