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

From: "Pete Cordell" <[email-masked]>
Date: Mon, 15 Nov 1999 12:02:18 -0000

Jonathan,

I afraid I disagree with some of your points....

-----Original Message-----
From: Jonathan Rosenberg <[email-masked]>
To: Tom-PT Taylor <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: 14 November 1999 04:57
Subject: Re: DTMF signaling between media gateways - ouch!

>
>
>> Tom-PT Taylor wrote:
>>
>> How the two methods differ:
>> (1) The SIP INFO  message must pass along the signalling path, and in
>> particular must have the same endpoints as the rest of the SIP
>> session.  The RTP stream can take a different path from the
>> signalling; it can therefore originate at the point of extraction from
>> an audio stream, and terminate at the point of consumption of the
>> digit information.
>>
>> Somewhat to my surprise, it looks like RTP is probably always the best
>> answer.  There are two possibilities that come to mind that might
>> contradict that conclusion:
>>
>> (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.

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!)

>
>What services could proxies provide in the SIP model by receiving DTMF?
>Nearly every application of DTMF I have heard brought up required the
>entity receiving the DTMF to be a UA, in which case it could get the RTP
>stream instead.
>
>> (b) The receiver of the digits is one end of the SIP session and
>> neither sends nor receives media.  In this case it ends up having to
>> support a second protocol (RTP) where otherwise it could just use
>> SIP.  In addition, there could be coordination problems between SIP
>> messaging and the independently-received RTP packets.
>
>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.  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.

>
>-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 Cordell
[email-masked]
=============================================

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 15 Nov 1999 08:49:47 -0500

> I afraid I disagree with some of your points....

No reason to be afraid ;)

> provider (who may not be the network provider) does not control the build on

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.

> 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.

> timely than INFO. 

Multi-hop proxies. Ask the DCS folks all about this .. :)

 Especially if all of those proxies only interested in the
> 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.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 15 Nov 1999 09:14:37 -0500

Jonathan Rosenberg wrote:

> Multi-hop proxies. Ask the DCS folks all about this .. :)

It should be noted that loss recovery speed is not primarily a UDP vs.
TCP issue. The timeliness of RTP-based delivery is due to the "FEC-like"
redundancy mechanism where DTMF status updates are transmitted every 50
ms or so, allowing very fast recovery, much faster than the SIP
retransmission timer. (To further confound the simple "UDP is faster"
issue, TCP can recover from losses significantly faster than fixed-timer
UDP for long-lived signaling channels if RTT estimation is used.)

Compared to the normal audio stream, RTP DTMF is no increase in packet
rate. Doing something similar as SIP INFO may, however, strain proxy
resources if DTMF signaling becomes popular.

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