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

From: "Tom-PT Taylor" <[email-masked]>
Date: Sun, 14 Nov 1999 17:51:23 -0600

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:[email-masked]]
> Sent:	Saturday, November 13, 1999 11:55 PM
> To:	Taylor, Tom-PT [CAR:B904-I:EXCH]
> Cc:	[email-masked]
> 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. 
> 
> 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.
	[[TomT]]  
	I was enumerating logical possibilities more than anything else.  I
had no particular application in mind.

> > (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.
	[[TomT]]  
	Read my premise here.  There's nothing to put the DTMF back into
under the case I postulate.  The UA is a consumer of DTMF digits, not DTMF
signals, and there is no other media stream.  I probably used the wrong
thread to raise this, leading to your confusion.  Anyway, again this is just
a logical possibility, and I have no specific application in mind.  My main
conclusion was the one you would agree with -- that in cases other than
theoretical possibilities (a) and (b), the RTP is always preferable.
>  
> 
> -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

---

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

Tom,

I think a big difference is the number of ports a service proxy needs to support is a big issue.  It would need to support 3 times the number of ports for the same service.  These seems expensive to process 5-10 packets of information.

Also, proxies can leave the signalling path after 200 OK, so process in a lot of cases will cause the call signalling path to closely resemble the equivalent RTP DTMF signalling path.  If that does happen I think the comparisons in timeliness will be very small, especially if SIP is transported over UDP.

Pete

    -----Original Message-----
    From: Tom-PT Taylor <[email-masked]>
    To: [email-masked] <[email-masked]>
    Date: 14 November 1999 00:42
    Subject: RE: DTMF signaling between media gateways - ouch!

    Let's step back and look at the RTP DTMF payload type vs. SIP INFO transport methods in more abstract architectural terms.

    What the two methods have in common: 
    (1) They are both "out of band" compact encodings of the information concerned, so the amount of effort required to understand them at the receiving end is roughly the same.

    (2) The transport options are the same for both methods -- there is no reason you can't run RTP over a reliable transport if you want.

    (3) Both methods require prior signalling to set up the necessary relationship between the source and destination. 

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

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

---

From: "Gregory D. Girard" <[email-masked]>
Date: Thu, 18 Nov 1999 10:21:33 -0500

Pete,
Simply put, I agree with you points and don't have anything else to add
execpt that voice detection (energy and endpoint) fall in the exact same
catagory as DTMF, save only to demark voice, rather than digit-press events.

Greg Girard

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

>Jonathan,
>From: Jonathan Rosenberg <[email-masked]>
>To: Pete Cordell <[email-masked]>
>Cc: [email-masked] <[email-masked]>
>Date: 17 November 1999 13:58
><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.
>>--

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 23 Nov 1999 12:07:50 -0000

-----Original Message-----
From: Jonathan Rosenberg <[email-masked]>
To: Pete Cordell <[email-masked]>
Cc: Adam B. Roach <[email-masked]>;
[email-masked] <[email-masked]>
Date: 22 November 1999 20:08
Subject: Re: DTMF signaling between media gateways - ouch!

>
>Note that, in a pure SIP environment, a proxy cannot
>transfer a call. Thats because it requires end systems cooperation, as
>media is end to end. Thus, UAs invoke transfer directly.

Then we have a problem.  We are ruling out a whole bunch of useful services
if a non-end device can not initiate a transfer between end UAs.

Would an impure SIP device be able to do it?

---

From: "Gregory D. Girard" <[email-masked]>
Date: Tue, 23 Nov 1999 07:37:58 -0500

Pete,
I could not agree more. If it is only for session initiation, then its time
to create yet another procotol that overlaps
about 90% of SIP's current functinality.

Greg Girard

>My feeling is that SIP stopped being purely an initiation protocol a long
>time ago.  In fact, when the BYE method was added, it no longer was purely
>an initiation protocol.  It went further down the path when all the call
>transfer stuff was added.
>
>I'm here because SIP is being touted as a solution for Internet Telephony,
>which involves more, much more, than just initiation.  If that's not what
>it's about a decision needs to be made quickly and the message that is
being
>spread by SIP advocates needs to be changed to avoid confusion in the
market
>place.
>From: Schroeder, Tim <[email-masked]>
>Date: 22 November 1999 23:44
>>I'm a bit confused by much of this DTMF discussion.  SIP is a Session
>>Initiation Protocol, so it understands how to initiate sessions.  As for
>the
>>mid-call DTMF tones,
>>
>>(1) If they are coming from some network where those tones *do* have
>session
>>initiation implications, then the gateway ought to be able to map them to
>>the existing set of SIP messages in some rational fashion.  So, in a
>network
>>where the DTMF 7 tone (R for record) means to add a recording device to
the
>>call, the SIP gateway would map this to an invite of a recording device to
>>the call.
>>
>>(2) If those tones don't have session initiation implications, then I
don't
>>see why any of the SIP network servers would understand them (any more
than
>>a gateway would understand them); only the end systems would.  Yes, they
>may
>>be used for signaling, but it's not session initiation signaling, and I
>>don't understand the desire to somehow wrap them up into SIP messages and
>>send them between end systems that way.  I see SIP as being used to set up
>a
>>session between end systems, possibly consisting of two media channels,
one
>>used for end system signaling, one used for end system data.  I haven't
>made
>>the leap that because the end systems are interpreting some data as
>>signaling, that the data should be sent using SIP messages.
>>
>>My impression from reading all the DTMF messages (and in trying to catch
up
>>-- there were a lot of them!) is that two separate kinds of signaling
>>(session initiation, and some higher level service signaling) are being
>>confused.  Currently SIP handles the first type.  Adding the INFO method
>>might make it able to handle some of the second type, but I don't think it
>>can handle all service signaling that easily.
>>
>>Tim Schroeder
>>
>>
>>
>>This e-mail and any files transmitted with it are the property of SBC,
>>are confidential, and are intended solely for the use of the individual
>>or entity to whom this e-mail is addressed. If you are not one of the
>>named recipient(s) or otherwise have reason to believe that you have
>>received this message in error, please notify the sender at
>>[email-masked] and delete this message immediately from your
>>computer. Any other use, retention, dissemination, forwarding, printing,
>>or copying of this e-mail is strictly prohibited.
>>
>>
>>
>
>

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 23 Nov 1999 17:52:20 -0000

>Chip added:

>At 04:01 PM 11/23/99 +0100, Jean-Hugues ROBERT wrote:
>>Hi,
>>
>> >Pete Cordell wrote:
>> >>
>> >> >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...
>> >> >
>> >>
>> >> No, you've missed what I'm saying...  Call transfer may take place
using
>> >> procedures defined in the call control draft, BUT the event that
>> causes the
>> >> call transfer to be kicked off MAY be some DTMF signal.
>> >
>> >Not in the SIP architecture.
>>
>>Customer calls Company's IVR
>>IVR plays annoucement "1 for sale, 2 for support,..."
>>Customer send DTMF 1
>>IVR initiates SIP transfer.
>>
>>I guess we have a "DTMF initiated call transfer" here ?
>>
>>Depending on the architecture, IVR may be a single entity
>>or a decomposed entity with a control endpoint and a media
>>endpoint.
>>
>>With a decomposed IVR, DTMF should get somehow to the
>>control endpoint.
>
>Yes, and traditionally this is done independent of the call setup signaling
>method (e.g., inband DTMF direct from the phone to the IVR).  If the IVR is
>provided by a Company different from the SIP service provider, they
>probably don't want their IVR services totally dependent on the
>capabilities of the service provider.
>

Although it must be recognised that this is but one example, and therefore
should not be taken as the sole basis for making a design decision.
Unfortunately, having control only at the ends limits the sorts of services
that you can deploy.  Even today on crusty old POTS local exchanges (COs)
will act on DTMF while in the middle of a call (whether it's inband or out
of band is not really relevant).  Some of the features provided this way
could be moved to the originating UA if the system is migrated to SIP, but
there will still remain some that would have advantage operating in this
way.

>
>>Yours,
>>
>>Jean-Hugues Robert
>>
>>--------------------------------------------------------------------
>>[email-masked]                                        "Think globally.
>>www.8x8.com                                            Act locally."
>
>Support NetAid!  http://www.netaid.org
>--------------------------------------------------
>Chip Sharp                 Consulting Engineering
>Cisco Systems              Telco Bio-region
>Reality - Love it or Leave it.
>--------------------------------------------------
>
>

Pete