Detecting DTMF tones on a SIP voice session

["Gregory D. Girard" <[e-mail]>]

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 <[e-mail]>
To: Jonathan Rosenberg <[e-mail]>
Cc: Rick Workman <[e-mail]>om>; Alan Johnston
<[e-mail]>om>; SIP List <[e-mail]>
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:[e-mail] 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:[phone]. 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:[phone] -> tel:[phone]). This is basically LNP. The next
>> hop proxy doesn't need to look up tel:[phone] 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
>