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

From: "Pete Cordell" <[email-masked]>
Date: Thu, 18 Nov 1999 14:58:16 -0000

Jonathan,

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

<some old stuff snipped>

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

A gateway can be expected to know about dialling, so your first example
works well (except for the issue of different numbering plans used
throughout the world which may need addressing later).  After that I don't
think you can expect a gateway to convert subsequent digits correctly into
an appropriate functional as you can't expect it to know about all possible
services.

>>
>> 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!
>
>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 one way you can cut a system, but it is not the only way.  There are
also other situations where the DTMF is not interpreted by the end system.
In these cases end-to-end DTMF is not appropriate.

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

I would think that the only functional equivalents that the gateway can
convert to are services that are specific to it.  These may be standard SIP
services, or they might be specials.  Either way it is an example of a
non-terminal device acting on the DTMF.  The gateway certainly can't be
expected to converted to any (probably as yet un-specified) functional
service.

>
>
>> 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.
>
>See my above point; I'm not arguing for this.
>
>

<some old stuff snipped>

>>
>> But DTMF is a signalling protocol, albeit crude, and ought to be aligned
>> 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.

DTMF may be crude, but in fact it's its simplicity that makes it so useful.
(It's a bit like ones and zeros are fairly crude, but we seem to manage with
them OK!)

Also, as you say, the timing of the DTMF is important, but this timeliness
also needs to be maintained relative to any functional service.  The best
way to do this is to put all such signalling down the the same hole.

>
>-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: Chip Sharp <[email-masked]>
Date: Fri, 19 Nov 1999 11:05:11 -0500

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

...snip...

>way to do this is to put all such signalling down the the same hole.

In designing ISDN terminals back in the early-mid '80s there was the idea 
that everything would be done via ISDN signaling and DTMF would go 
away.  Lots of functionality was built into the phones (to do both 
functional and non-DTMF stimulus signaling) and user-user information 
elements were defined (and codeset 6) for those cases in which signaling 
was needed between the user and a non-telco enhanced service provider.

However, terminal designers quickly found that inband DTMF generators were 
required on ISDN phones.  One big reason was that these phones had to 
interwork with legacy call center equipment.  The other reason was that 
reality intruded and terminal designers quickly found that not all switch 
vendors or ISDNs would actually carry these information elements in "the 
same hole".  Therefore, the only reliable method of signaling between the 
ISDN phone user and enhanced service provider was inband DTMF.

This discussion seems analogous to the old ISDN problem.  If keypad entries 
are carried in SIP messages along the signaling path, the user and the call 
center application are at the mercy of SIP service provider for their 
service and business.  Carrying keypad entries directly between the MG and 
the call center provides the only signaling transparent to the SIP service 
provider.

> >http://www.dynamicsoft.com

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------