Subject: RE: [SIP] DTMF digit handling

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 10 Jul 2000 06:54:02 -0700

> > In-band RTP is likely to be the preferred way of sending 
> DTMF to a UA.
> > If some of the systems along signaling path are interested 
> in the DTMF,
> > the INFO method may also be used. There are a few ways to 
> encode DTMF in
> > the body of INFO: by using the payload format described in 
> RFC2833, by
> > using MGCP/Megaco packages, etc.
> 
> I should note that this is still an issue of some controversy, both on
> whether its needed (a UAS will still get the DTMF through RTP), and on
> how to do it. So, you should not take any of the extensions 
> proposed so
> far as authoritative or normative. I hope to resolve this at the next
> meeting.

Jonathan, I am unsure what issue you beleive needs to be debated. Are you
debating the need for a SIP Proxy or User-Agent to receive DTMF digit
information (when it is not in the media path); or are you debating that the
proposed methods are the wrong way to go about it?

Robert.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 10 Jul 2000 10:37:24 -0400

> proposed methods are the wrong way to go about it?

Both.

So far pretty much every application requiring DTMF was for a device
that was a user agent and media termination point, so sending it in SIP
seems redundant. These kinds of applications include IVR, pre-paid
billing, credit card collection, etc. For those applications where the
application resides on a device that is not a media termination point,
the device has always appeared to be a SIP user agent (typically doing
things like 3pcc). In this case, I would argue along the lines that
Scott Petrack has been arguing - the right way to handle these is to
allow the UA to insert a field into SDP that allows it to get RTP but
only RTP with the DTMF codec. This allows it to get DTMF, but not see
"all" the media otherwise. 

Note that I am still cautious about these kinds of things. They
basically imply that providing the service *relies* on the origination
point correctly doing DTMF. There is such a wide range of access devices
supporting SIP; counting on each and every one of them everywhere always
performing DTMF correctly seems dangerous. So, the safe way to get the
DTMF is to terminate the entire media stream, so that you can do your
own detection if needed.. In any case, most DTMF-based apps often also
allow for speech recognition, which requires termination of the media
stream at the application point anyway.

As for the current proposals, I think most also include a control
component that allows the proxy/app server to tell the UA things like
what digit mask to use. These are completely inappropriate in SIP. THey
rule out the possibility of multiple application servers handling a
call, and they also imply a trust relationship between the app server
and the originator, which may not always exist. SIP is a poor control
protocol, primarily because of its distributed nature. If we were to do
DTMF over SIP itself, it would have to be restricted to just the
mechanism for encapsulating the digits in SIP messages, thats it. If you
NEED more control than that for your application, well, sounds like it
might be more suitable to user megaco. See another thread on this
subject recently on the list....

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Jul 2000 08:53:50 -0700 (PDT)

> stream at the application point anyway.

   I guess I'm not as worried here: if you're using
   a codec which isn't good at transporting DTMF like
   G.723 or G.729, you have pretty good incentive to
   get your DTMF codec ala RFC2833 correct. Also: things
   like IP phones or PC's don't need DTMF detectors 
   for local digit collection at all. If the far
   end wants to see DTMF for an IVR, say, the
   phone is going to have to manufacture DTMF
   anyway. If anything, I'd expect that the
   likelihood of getting NSE's correct is a lot
   higher than injecting DTMF waveforms into a
   G.711 stream...

		Mike