Subject: DTMF signaling between media gateways - ouch!

From: "Gregory D. Girard" <[email-masked]>
Date: Fri, 12 Nov 1999 08:26:35 -0500

Dean,
I believe your reasoning is excellent and entirely consistent with similiar
(but not the same points) I offered in
several prior messages. It would appear that this DTMF thing could keep SIP
out of Enhanced Services Platform
strategies due to the simple inability of SIP supports to decide on a way to
transmit the simplest signals of all - DTMF user input.
Aside from other considerations, in my opinion, any DTMF signalling
technique that RELIES upon an IP transport (RTP in this case) is
dead on arrival. Such an approach pre-supposes the bearer channel transport
technology and thus binds SIP to VoIP solutions. Insofar as
ATM and Frame Relay transports exist (and particularly ATM, which is coming
on strong) and are growing, it makes no sense to me to
create an artificial dependency on IP/RTP.

In fact, to take it one step further, I will share with you that more than
two of our customer prospects for enhanced services have indicated that
their primary backbone technology for bearer channel transport shall be ATM.
We hear this more an more. The IP enviroment will provide a signaling and
service-oriented network. Although the ATM transport has provisions for
carrying DTMF information, an RTP DTMF solution won't solve these problems
for this reason: we would find ourselves engineering a new DTMF
network-layer solution for each new enviroment. And once again, no one has
resolved the issue that the enhanced services platform may have no media
connection to the media gateway, or if they do, it would likely be
half-duplex for the purpose of playing prompts. Finally, an IP phone based
upon H.323 would not generate DTMF tones at all, but instead would transmit
them has digit codes (H.245 signaling I believe) to the other end, which is
likely to be a softswitch. Is the idea that the Softswitch will have to then
invoke a DSP algorithm to generate the DTMF waveform and "inject" it into
the RTP call leg to the Enhanced Services Platform ?

I may be missing something here because I'm not an expert in every protocol
in the PSTN, but see if you can follow this line of reasoning.
It is my understanding that all ISDN and H.32X (multimedia for ISDN, IP,
ATM, etc.) protocols have pushed DTMF signaling into outband signaling
pathways to get them out of the media path. In ISDN, they are carried in a
"D" channel. Certain SIP contributors suggest that it should be pushed back
into the media path. Resultantly we encounter a strange circumstance in
which the end terminal on a connection uses outband DTMF which has to be
*put back into* the media path by a media gateway DSP resource! To matters
even stanger, if the other end of the connection (passing through a set of
media gateways) was the same kind of ISDN or H.32X terminal, that DTMF
information that was injected into the media path would have to be detected
once again and re-converted back into outband signals prior to reaching the
end terminal.

Summarily, to use the media stream alone for DTMF signaling would be the
equivelent of architecting the next generation network to use outband DTMF
signaling to its end-user ISDN and H.32X terminals while using *inband
signaling* for communicating DTMF from gateway to gateway. This is the same
as the now-obsolete DTMF signaling used in the old-world PSTN before SS7
existed. In essence, our new network would be primitive compared to the
sophisticated end-user terminals connecting to it and the clean "D" channel
outband signaling model embraced by ISDN BRI. The more I consider the
proposals at hand, the more I'm moved to reject the media stream DTMF
signaling model.

Greg Girard
CTO
Iperia, Inc.

Greg Girard
CTO
Iperia, Inc.

-----Original Message-----
From: Dean Willis <[email-masked]>
To: Jean-Hugues ROBERT <[email-masked]>; Michael Thomas <[email-masked]>;
Gregory D. Girard <[email-masked]>
Cc: [email-masked] <[email-masked]>;
Dye, Robert <[email-masked]>
Date: Wednesday, November 10, 1999 4:14 PM
Subject: RE: Additional Info on DTMF under SIP

>
>
>I think the real situation is much simpler:
>
>If DTMF is to be carried to "the other end", it should be transported in
the
>RTP. Trying to remix signals that occur on the signaling path instead of
the
>media path is intractable. In other words, I think DTMF detection signalled
>as an INFO message should never be reinserted into the audio stream.
>Therefore, one needs RTP and INFO.
>
>If DTMF needs to be sent to the control plane -- i.e. the detection of DTMF
>is being sent to a supervisory system, many benefits are gained by adding
>INFO support. These include:
>
>1) Reliability
>2) Simplification of the control application
>3) Delivery of the detected DTMF to as many proxies in the signaling chain
>as need it.
>4) Transparency of the signaling path to the UA -- INFOs can be moved along
>the proxy path, whereas RTP would either require either an RTP proxy chain
>and vast amounts of additional signaling OR a direct RTP paths between the
>UA and N-many control nodes. This also simplifies the UAS implementation.
>
>Look, there's a reason why MGCP defined an event package for DTMF instead
of
>just sending the RTP all the way to the softswitch. This is exactly the
same
>thing, with a distributed control model described by the proxy chain. I
>suspect it is the same reason that led to detected DTMF being transmitted
in
>user-info in H.323.
>
>There's a non-aristotelian aspect here -- knowledge of a keypress is not
the
>same as the data of the tone produced by that keypress.
>
>--
>Dean Willis
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Jean-Hugues
>> ROBERT
>> Sent: Wednesday, November 10, 1999 11:21 AM
>> To: Michael Thomas; Gregory D. Girard
>> Cc: [email-masked]; Dye, Robert
>> Subject: Re: Additional Info on DTMF under SIP
>>
>>
>> Hi,
>>
>> Looks like we do not progress very fast on this topic.
>>
>> I now believe that both means of conveying DTMF are
>> needed. Because there are two distinct requirements.
>>
>> 1) Reliable and timely transport of DTMF at the media level (user plane).
>> RTP is good here.
>> 2) Supervisory of DTMF at the signal level (control plane)
>> SIP dtmf INFO is good here (as a negotiated option probably).
>>
>> There are many applications based on DTMF today. Voice is the future.
>> Lets handle both well.
>>
>> Of course one can "get by" with any one of the solutions, but it can be
>> very inconvenient (specially when SIP and RTP do not terminate at the
>> same entity) :
>>
>> Only RTP:
>> You negotiate multiple SDPs. One for voice & DTMF will be direct
>> between the endpoints. Another one for DTMF only will be directed to
>> "supervisory" entity. You need RTP besides SIP in
>> supervisory entity.
>> You need to support multiple SDPs in DTMF sender endpoint.
>>
>> Only SIP:
>> You reinject DTMF tones inside the RTP jitter buffer. All
>> SIP msgs need to be intercepted/relayed by the "supervisory"
>> entity. You need SIP besides RTP in the DTMF receiver endpoint.
>>
>> I dislike both. I prefer having RTP only, because I believe that handling
>> multiple SDPs requires less hardware than handling SIP in addition to RTP
>> and I believe that VoIP market needs cheap IP phones.
>>
>> My 2 cents...
>>
>> Jean-Hugues ROBERT
>> --------------------------------------------------------------------
>> [email-masked]                                        "Think globally.
>> www.8x8.com                                            Act locally."
>>
>

---

From: Michael Thomas <[email-masked]>
Date: Fri, 12 Nov 1999 05:47:47 -0800 (PST)

Gregory D. Girard writes:
 > dead on arrival. 

  This is a wholesale misreading of what Dean wrote.
  Nobody's talking about "RELYING" on IP transport
  for bearer DTMF relay. In fact I mentioned two
  others bearer DTMF relay schemes that do no rely
  on IP. I suggest you re-read what was written. 
  As I said, you're setting up a whole lot of false
  dilemmas as the rest of this post demonstrates.

	      Mike

---

From: Dean Willis <[email-masked]>
Date: Fri, 12 Nov 1999 09:52:09 -0600

Gregory D. Girard wrote:
> several prior messages. It would appear that this DTMF thing

Ahh! Great minds think alike ;-). Thanks!

> the simplest signals of all - DTMF user input.
. . .

I had a very similar discussion with Jonathan Lennox the other day at lunch.

His point as I understand it was that both the RTP approach and the "info
digits" appoach are fundamentally flawed for native IP phones. When one can
put a softkey on a phone that sends a SIP INFO "Delete this voicemail"
command, or any other appropriate and arbitrary string defined by an
application, then DTMF controls begin to look very primiive!

I pointed out, however, that we're stuck with more than a few analog phones
out there, many of which will end up downstream from gateway devices. For
example, my office has about 70,000 such devices . . . so a lot of people
will be using 12-key phones for a while.

So, how to grant the power of arbitrary INFO strings as defined above to
legacy phone users? We came up with a simple idea -- it may or not have
promise, but I'll describe it for the entertainment value.

It is very simple to build a SIP proxy that accepts INFO messages, rewrites
them, and passes them along the signaling chain. For example, an "INFO
{digit 4}" might become an "INFO exec delete message". This translation
could be controlled by simple tables, be XML or otherwise defined, and be
included in the signaling path based on content or capabiliies negotiation
between the endpoint and the application. Or, the INFO message might we
translated into WAP WMLSCRIPT input -- perhaps a generalized WAP client that
lets 12-key users access WAP pages . . .

Of course, this would require some analysis to understand security and
end-to-end implications, but it might be equally applicable to VoFR and
VoATM and other non-RTP command and control models.

--
Dean

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 12 Nov 1999 12:05:23 -0500

> transmit the simplest signals of all - DTMF user input.

It would be beneficial to avoid these grandiose proclamations about the
future of SIP based on our technical decisions on this one issue. No one
is arguing DTMF isn't supported in the SIP architecture; rather, I (and
others) are arguing that the problems people have, and the requirements
that they need met, are solved by having DTMF transported in RTP, and,
are solved better.

> create an artificial dependency on IP/RTP.

As others have pointed out, this is plain wrong. One can always run RTP
ontop of ATM (I'll note that H.323 actually specifies how to do this),
in which case this point is totally moot. Secondly, any native ATM
solution that can't support DTMF in a reasonable way in the bearer
channel is, IMHO, DOA. H.323 specifies and allows both, as has been
pointed out. So, are you arguing you won't support H.323 either?

> half-duplex for the purpose of playing prompts.

Its hard to argue this based on high level notions of what you mean by
an "enhanced services platform". I have, in a prior email, suggested a
particular model of reference. THis model is not half duplex, as you
seem to indicate, in its control relationship. MGCP/megaco, which has
been proposed as a control platform for IVR, *already* supports
notification of DTMF from the controlled device to the controller. If
DTMF is transported in RTP using the DTMF codec, it is a no-brainer to
do this. In fact, you will probably have to pay money to remove this
basic function from any MGCP/megaco stack. Furthermore, you are going to
want to know about all kinds of state transitions in the controller
device, including prompt timeouts, errors (no such announcement
available), voice recognition, available DSP resources, and so on.  

 Finally, an IP phone based
> the RTP call leg to the Enhanced Services Platform ?

Well, as already pointed out by some real H.323 experts, this is false.
H.323 allows both.

> *put back into* the media path by a media gateway DSP resource!

Sorry, outband DTMF is the INFO method, which you seem to be supporting.
If the DTMF is carried in INFO, and the remote side is a gateway, you
will need to reinsert it into the media path. THis is *not* true with
the DTMF over RTP solution. So, you seem to be arguing in favor of the
RTP over DTMF solution. Actually, it is *hard* to reinsert the DTMF into
the audio stream if its sent in the INFO method, since you have lost the
timing and synchronization. For example, the audio segment that
contained the DTMF may have already passed, temporally, at the gateway,
before the INFO method arrives.... not true with the DTMF over RTP
solution.

 To matters
> once again and re-converted back into outband signals prior to reaching the

No. In both the DTMF over RTP and INFO method solutions, the detection
can be done at the originator. The RTP format conveys the digit itself,
just as is done in the INFO method. Thus, if the terminating gateway is
an ISDN terminal, it is equally easy in both cases to insert it into the
signaling (H.245 user input indication in the H.323 case, for example)
without redetection.

> signaling* for communicating DTMF from gateway to gateway. 

This would be the case if you use INFO method, but it is clean in the
case of DTMF over RTP. So, your argument only supports the opposite of
your conclusion.

This is the same
> outband signaling model embraced by ISDN BRI.

Again, these abstract "sophisticated vs. primitive" arguments are
completely non-technical and without merit. You seem to be trying to
argue a technical point with marketing terms. I would argue the exact
opposite marketing spin anyway:

<silly marketing argument>
The idea of sending DTMF in the RTP stream, but not as audio, is quite
sophisticated and totally beyond what is done in ISDN or SS7. Sending
DTMF in the INFO method is akin to the "old" technology of ISDN. We've
done it better! 
</silly marketing argument>

Enough about marketing. Lets address the technical issues. 

-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: Colin Perkins <[email-masked]>
Date: Sat, 13 Nov 1999 18:06:46 +0000

--> "Gregory D. Girard" writes:
>technique that RELIES upon an IP transport (RTP in this case) is dead on
>arrival. Such an approach pre-supposes the bearer channel transport
>technology and thus binds SIP to VoIP solutions. Insofar as ATM and Frame
>Relay transports exist (and particularly ATM, which is coming on strong)
>and are growing, it makes no sense to me to create an artificial
>dependency on IP/RTP.

To clarify, whilst most RTP implementations use UDP/IP as their transport,
the protocol was intentionally defined to be transport neutral and does not
mandate IP.

Colin