Subject: Re: DTMF signaling between media gateways - ouch!

From: "Pete Cordell" <[email-masked]>
Date: Tue, 16 Nov 1999 13:48:19 -0000

-----Original Message-----
From: Jonathan Rosenberg <[email-masked]>
To: Pete Cordell <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 15 November 1999 13:51
Subject: Re: DTMF signaling between media gateways - ouch!

>
>
>Pete Cordell wrote:
>>
>> Jonathan,
>>
>> I afraid I disagree with some of your points....
>
>No reason to be afraid ;)
>
>> >> (a) A number of entities along the signalling path need to know the
>> >> digits.
>> >
>> >But why? SIP is *not* a stimulus signaling protocol. Protocol features
>> >are not invoked by DTMF. I feel strongly about this since once you start
>> >doing this, you mandate a proxy server for call completion and possibly
>> >certain features which otherwise don't need one. This isn't megaco,
>> >after all. I believe it funamental to the SIP architecture that the
>> >operation of basic call completion and certain features (where
>> >appropriate) is independent of the presence of a proxy.
>>
>> Allowing for simulous signalling is very important even in an IP world.
It
>> allows people to pick up any 'phone' and run their desired application
>> service without downloading any patches that natively support the
>> application.  A lot of supplementary service suites have started out
being
>> purely functional based, but have later had to adopt a simulous approach
>> because of lack of support in the endpoints.  This is particularly the
case
>> for public services (as opposed to private networks) where the service
>> provider (who may not be the network provider) does not control the build
on
>> UAs.
>
>Yes, I've heard this many times. The issue of not being able to upgrade
>UA's is obviously critical for the PSTN, but I'm not sure this is so
>much an issue anymore for IP. Many pieces of software these days
>automatically upgrade themselves, with nothing more than an "OK" from
>the user. Furthermore, one can envision future UA's having JVMs that
>simply fetch the latest version when I call up my "provider" to enable a
>new service. Note that my network provider doesn't have to be my service
>provider at all for this to work.
>
>The issue seems to be fairly religious; there are those on one side
>(like myself) who believes that IP is a true enabler of functional
>signaling, and those on the other side (like yourself) who draw
>parallels with systems like ISDN (which do support both) and see the
>issue here as the same.

There was also a time when it was said that there was no need to standardise
call control software as you would just down load the appropriate version.
That hasn't happened, and I'm not surprised.  I agree that ISDN devices are
less easily upgradeable (by design rather than technology limitations), but
I don't think the difference is sufficient to ignore simulus based
signalling.  HTTP/HTML based control may play a big part in the future, but
I think with small mobile devices, and other similar toys, simulus based
signalling will still play a part.  There will also be the case of calls
originating off-IP, but terminating in IP space and these will still need
some form of control.

Also, a lot of people are worried about downloading software from here,
there and everywhere, and I think many of them, given the choice, would
prefer not to do it, - especially if it was just to contact the tax office
call centre etc!

So, in the short term at least, I think we need simulus signalling.  If
that's not possible then the whole thing is going to look rather silly.
Maybe in the long term things will change, but you have to move by
evolution, not revolution.

And we should definitately avoid not doing things just because ISDN does
it!!!

>
>>
>> Also, just because you can have services supplied by proxy servers using
>> DTMF, I don't see that this mandates their presence in all cases.  I may
be
>> missing the point, but in the same way that I can ring up a banking
service,
>> I don't see that this mandates that I have to ring up a banking service
>> every time (although the banks might think differently!)
>
>Banking is different in that its not a call control service. Any service
>or feature which modifies call or connection state in any way at all, if
>signaled via DTMF, will not be available in a direct UA to UA
>connection. This means things like transfer, I believe, should not be
>signaled by means of DTMF.
>

Atomic things like transfer can probably easily get away with being
functionally signalled.  However, I think transfers will occur as a result
of DTMF signalling, even if only indirectly, such as in a call center.  I
really don't want to down load a patch (that may be phone specific) for each
call center I contact.

>> >These coordination problems arise only when the DTMF is sent in INFO.
>> >When the DTMF is sent in RTP, its easy to reconstruct the timing, so you
>> >can put back the DTMF if need be.
>>
>> If SIP were signalled over UDP, and the RTP timing information (which is
>> similar to what H.323 does with DTMF - timing info part that is) was
>> included in with the INFO messages, then I can't see that RTP is any more
>> timely than INFO.
>
>Multi-hop proxies. Ask the DCS folks all about this .. :)
>
> Especially if all of those proxies only interested in the
>> location phase un-hook from the call path.  This of course is a build
>> option, but if you don't have some form of engineered QoS on your
network, I
>> believe you should be using UDP anyway.
>
>But if the proxies are not looking at the DTMF, it doesn't need to be in
>the INFO method at all. As you suggest, if INFO carries DTMF and timing
>information and goes direct, then its basically RTP with a very massive
>header.

But DTMF is a signalling protocol, albeit crude, and ought to be aligned
with other signalling information, such as transfer, end call etc.
Therefore, if there is nothing to choose between them, the information is
best associated with the signalling.  The header of an INFO message might be
bigger, but there shouldn't be too many of them, and they don't need to be
re-transmitted at regular intervals.

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

Pete

=============================================
Pete Cordell
[email-masked]
=============================================

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Nov 1999 09:01:30 -0500

> originating off-IP, but terminating in IP space and these will still need

For off IP devices, it is already the job of the gateway to determine
what is meant by the
DTMF it receives from a normal phone. In current gateway operations,
when I dial "5551212" on my phone, the gateway knows that I am really
saying "call the terminal named 555-1212", and thus converts this to a
functional equivalent (INVITE tel:5551212 SIP/2.0). The same concept can
be used to handle other services that are stimulus signaled. 

> prefer not to do it, - especially if it was just to contact the tax office

But there is no need for downloading software to contact a tax center. I
have been arguing that for IVR systems (which is what you are talking
about), DTMF "signaling" of what you want is just dandy, but that this
"signaling", which can also be based on voice recognition, resides in
the RTP stream possibly using the DTMF codec. Thus, you can call any IVR
system without having to download software for each one.

> that's not possible then the whole thing is going to look rather silly.

I'm not arguing that a user can't use a normal phone with SIP, and press
buttons. What I am arguing is that for the vast majority of what people
use DTMF for, IVR and voicemail systems, we carry these using the RTP
stream. For SIP services, the DTMF needs to be converted to its
functional equivalent at the UA, be it gateway or phone.

> really don't want to down load a patch (that may be phone specific) for each

See my above point; I'm not arguing for this.

> with other signalling information, such as transfer, end call etc.

Well, if DTMF is such a crude signaling protocol, I'd rather have the UA
point
convert it to a non-crude functional equivalent, as we already do right
now for
things like INVITE.

-Jonathan R.

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 18 Nov 1999 18:03:11 -0600 (CST)

>really don't want to down load a patch (that may be phone specific) for each

You seem to be missing the bigger picture here:

Call transfer is well defined within the call control draft.
It won't be done via any sort of DTMF signalling; it'll be
built in to the end devices. No patching involved...

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA