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

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 28 Oct 1999 22:07:28 -0400

Cc list trimmed, since everybody is presumably a list member. There are
two short answers to the issue you raised:

1) See the RTP proposal for carrying DTMF and other tones. It's listed
on the AVT WG web page. This is the preferred mechanism as long as audio
and DTMF are going the same way, as it has a low-latency redundancy
mechanism and can readily be synchronized with the audio stream. It is
also quite feasible to set up a SIP connection that transfers only DTMF
using this mechanism. This proposal has undergone working group last
call and will be submitted for IETF last call shortly.

2) The use of the INFO method to carry DTMF within SIP has been
discussed. This would, in spirit, be very similar to carrying ISUP
information across the network, just that it is in-band signaling that
is effectively replicated out-of-band. The definition is trivial:

INFO ... SIP/2.0
To: anywhere
From: somewhere
Content-type: application/dtmf

*1

or something like that.

"Gregory D. Girard" wrote:
> 
> To the extent that I am not a "SIP insider" and have not been deeply
> involved in the evolution of SIP, I'm not exactly sure how to bring up a new
> subject in this forum. I am in the process of determining how to achieve
> third-party call control through a Softswitch using SIP as the call
> control/signaling interface. I am very familiar with the Lucent Softswitch
> model and believe that other Softswitch call control interfaces are
> possible. To that end, I really need to find something out directly related
> to SIP functionality.
> 
> In considering SIP as a call control interface to a Softswitch, it becomes
> very challenging to navigate an Interactive Voice Response session without
> the ability to collect DTMF input from the caller. Perhaps I missed
> something, but I am unaware of any SIP capacity to transmit DTMF digit
> information for a voice connection. I found no SIP messages relating to the
> feature, presumably because it requires an underlying DSP capability to
> detect the DTMF digits. SIP implemenations appear not to have focussed on
> this area.
> 
> If I have overlooked some existing SIP functionality, please accept my
> humble apologies and direct me to the righ place.
> 
> On the other hand, if the "SIP community" has overlooked DTMF digit
> collection/detection as a critical adunct necessary to make SIP work in a
> real call control application, the read on.
> 
> *** Would it be possible to extend SIP messages to enable a DTMF digit map
> to be specified for a specific SIP voice session ?
> 
> This functionality may not make sense in all cases, however in the case
> where a User Access Client and/or User Access Server is incorporated into a
> Softswitch, it would be very desirable for the Softswitch to be able to
> collect DTMF digits for a voice session (according to a digit map) and
> subsequently insert the results into the SIP message stream.
> 
> Certainly one could argue that this feature is hardware-dependent in terms
> of DSP capabilities, voilates the purity of the SIP signaling model, and
> belongs to an MGCP interface, but that would be missing the point. In
> creating a connection to a Softswitch, the media gateways are completely
> encapsulated by layers of Softswitch software. The MGCP client-server pairs
> used by the Softswitch to control one or more media gateways are not
> externally addressible outside of the domain of the Softswitch because the
> Softswitch is fully responsible for managing the media gateways as its own
> internal "switching resource".
> 
> An IVR application external to the softswitch cannot simply wrest control of
> a media gateway to create a connection for its own purposes. Unfortunately,
> the ability to present digit maps for DTMF collection on a given connection
> appears to only be available through the inaccessbile MCGP protocol
> elements. Thus, my proposal is to extend that MGCP feature into SIP.
> 
> Greg Girard
> 
> Iperia, Inc.
> 
> -----Original Message-----
> From: Henning Schulzrinne <[email-masked]>
> To: Jonathan Rosenberg <[email-masked]>
> Cc: Rick Workman <[email-masked]>; Alan Johnston
> <[email-masked]>; SIP List <[email-masked]>
> Date: Thursday, October 28, 1999 8:03 PM
> Subject: Re: I-D Action: SIP Call Flows and Service Examples
> 
> >Jonathan Rosenberg wrote:
> >>
> >
> >> Need it translate the tel URL before sending it to a local proxy? I
> >> guess you can argue this either way. In one sense, changing it to
> >> sip:[email-masked] is right since I am talking to the proxy at
> >> mydomain.com; effectively I'm trying to reach this number through this
> >> domain. On the other hand, the resource I am still trying to reach is a
> >> phone number, and the outbound domain is not really the namespace in
> >> which this number is defined.
> >
> >I suppose it is up to the proxy to either accept or reject non-SIP URIs.
> >I would guess that most current servers would not take too kindly to a
> >tel: URI. (I just fixed our sipd server to allow this, to see how
> >difficult this change might be. Two lines of code, as it turns out.)
> >
> >In general, a server should probably allow non-SIP request URIs (as well
> >as in the To header of the REGISTER).
> >
> >This should probably be made explicit. The HTTP spec only seems to imply
> >that something like
> >
> >GET sip:user@host HTTP/1.1
> >
> >would be illegal. (Having a real URI in the request line, like 'GET
> >http://www.ieee.org HTTP/1.1' is fine, albeit not common except when
> >addressing proxies.)
> >
> >
> >> > If it's tel:#, it needs to be translated to sip:#@domain, at which
> point
> >> > the # is just an identifier. Why would you need a further
> >> > identification? In particular, this is not fixed: in the future, the
> >> > same # can well refer to a legacy "black" phone at night (at home) and
> >> > an IP phone during the day (at work).
> >>
> >> I was thinking along the lines of how enum gets integrated into the SIP
> >> architecture. We start with a phone number, and this number really is a
> >> "name"; using enum, we can translate it to a sip URL, mailto URL, and so
> >> on. In many cases, this number is a name for a terminal on the PSTN with
> >> the same number. In other words, the tel URL is just a normal POTS line,
> >> and this number has no entry in the enum database. Say some IP phone
> >> makes a call to tel:1234567. The first outbound proxy uses enum, and
> >> finds that this number is not in the database. So, it forwards it to the
> >> next hop proxy, using a tel URL in the request URI. This proxy doesn't
> >> need to look it up in enum once more, as its been done. A similar issue
> >
> >However, somewhere along the way, this has to be translated to a
> >gateway. Why would this not be done at the same time?
> >
> >The first proxy has to forward this request *somewhere* on the Internet,
> >so why not translate this into
> >
> >sip:#@somewhere;user=phone
> >
> >No information is lost. The next hop will then decide whether this is
> >indeed a real phone, with a gateway to be contacted, or this actually
> >isn't, due to some other remapping.
> >
> >> arises if the first number did exist in enum, but was mapped to another
> >> number (tel:1234567 -> tel:2125551213). This is basically LNP. The next
> >> hop proxy doesn't need to look up tel:2125551213 in enum.
> >
> >This depends on whether enum is a global database or whether certain
> >translations are done locally. For example, you could have a global
> >translation to a current carrier number ("LNP"), but only the current
> >carrier keeps track of whether this number is currently on 24 ga twisted
> >pair and 48 Volts or gets IPtone. Thus, it may have to do a second
> >look-up anyway.
> >
> >>
> >> I think what you are proposing is that translation to the SIP URL
> >> basically implies that the lookup has been done. That works, but I think
> >> it might be combining two things together that are really different. Not
> >> sure...
> >
> >I'm just not sure that a single-lookup-model even works within the tel:
> >context. Why have a proxy if it doesn't do a lookup - that's it's
> >primary justification, after all...
> >--
> >Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> >

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: "Gregory D. Girard" <[email-masked]>
Date: Thu, 28 Oct 1999 21:56:23 -0400

Greg Girard

Iperia, Inc.

-----Original Message-----
From: Henning Schulzrinne <[email-masked]>
To: Jonathan Rosenberg <[email-masked]>
Cc: Rick Workman <[email-masked]>; Alan Johnston

point