Subject: Re: More on DTMF signaling between media gateways

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 17 Nov 1999 15:27:00 -0500

"Gregory D. Girard" wrote:
> 
> That is, what if the objective is to not require ANY real-time or RTP
> transport at all between the MG and the ESP.

I don't know what an ESP is. You have never defined it nor given
reference to it. I had guessed it was some kind of logic ontop of a
softswitch. Now you seem to be implying its a seperate server with some
media function. 

 In sofar as the ESP really need
> only to "play" and "record" voice/fax to/from the end user, it may be
> possible for the MG, acting as an intermediate entity, to utilize more of a
> streaming interface in its connections with the ESP.
> 
> It would appear that simply playing prompts and recording voice could be
> accomplished without RTP as there is no real-time full-duplex session
> between the MG and ESP. Thus the playing of a prompt could proceed as as any
> other media connection, but with relaxed realtime component. The only
> requirement is that the MG have enough voice data to continue the play
> operation. Whether it arrives in realtime is not a requirement. Of course,
> multi-second delays would not be acceptable without large buffer sizes. Why
> do this ? because it removes all need for RTP HW/SW on the ESP for both play
> and record operations. The same goes for T.38 fax data.

I'm at a total loss here about what you are talking about. Relaxing the
real time requirement doesn't mean RTP or media goes away. If you want
to send media from this ESP thing to a MG, whether your playout buffer
in the MG is big or small doesn't change the need for RTP. Streaming
media, ala RealPlayer, still use RTP.

> 
> Of course, the result is that DTMF over the media stream would be of no use
> because the digits need to be instantly propogated to the ESP, not caught up
> in some audio buffer. Thus DTMF reliance upon RTP is awkward when the
> solution has no RTP in use. There are a lot of other reasons for the MG
> media i/o to operate in a streaming fashion: for instance, the ESP will only
> be able to store and retreive message data in a streaming fashion, so why
> add the real-time requirement on ESP ?

This also makes no sense to me, since based on your description, you are
still using RTP.

> 
> Above and beyond that issue, it has come to my attention from a variety of
> sources (and suggestions from MG manufacturers) to incorporate all or most
> of MGCP  in SIP according to a tunneling method.

While we're at it, lets put all of RTP into SIP also. This way, we can
avoid the need for this additional RTP protocol; we just tunnel the
header and payload through SIP. While we're at it, RSVP should go also,
since this would allow the MGC/proxy/router to know about QoS
reservations!! Wow! We've just thrown away three extra protocols
(MGCP,RTP,RSVP). Amazing how tunneling one protocol in another magically
makes the problem of protocols and state machinery go away. Now, if we
can just get BGP in there too....

<note intense sarcasm>

 I currently stand opposed
> to this because the goals of MGCP and SIP seem to part company in many
> areas, namely in the level of matrix control afforded by MGCP.

One might add that they are also completely different protocols with
totally different functions.

> TO THAT END, it would seem a reasonable solution that at the very least the
> DTMF digit map method be incorporated into SIP so that a request for digits
> can be kept in the MG without generating a lot of DTMF traffic in either the
> signaling or media planes. 

The MG doesn't speak SIP.

Of course, any use of the media plane to resolve
> a DTMF digit map request would need to return a very structured response as
> part of a negotiation.

Given that you haven't defined "digit map request" or "negotiation" in
this context, the statement seems hardly obvious to me.

-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: "Gregory D. Girard" <[email-masked]>
Date: Tue, 16 Nov 1999 19:13:31 -0500

Jonathan, Pete,

In yet another of my discussions with an MG manufacturer today, the issue
was raised as to how to create the simplest, most cost effective interface
between an enhanced services platform (ESP) and a MG - a solution that would
require the least amount of work, the fewest components, and preferable no
additional HW (since much of the point of this excercise is to get rid of
TDM HW). While Iperia is in discusssions with most MG manufacturers
regarding this same subject, a new DTMF issue was raise that we have not yet
considered in our wide and varied explorations.

transport at all between the MG and the ESP. In sofar as the ESP really need

Above and beyond that issue, it has come to my attention from a variety of
sources (and suggestions from MG manufacturers) to incorporate all or most
of MGCP  in SIP according to a tunneling method. I currently stand opposed
to this because the goals of MGCP and SIP seem to part company in many
areas, namely in the level of matrix control afforded by MGCP. I'm sure that
Jonathan might have some words to say about this, perhaps to the exent of
even agreeing with it :). But in any case, it seem quite crucial that (and
here I refer to a point made by Pete ? or someone else ?) that if DTMF gets
popular, it will put a load on SIP elements for which it may not be
designed.

TO THAT END, it would seem a reasonable solution that at the very least the
DTMF digit map method be incorporated into SIP so that a request for digits
can be kept in the MG without generating a lot of DTMF traffic in either the
signaling or media planes. Of course, any use of the media plane to resolve
a DTMF digit map request would need to return a very structured response as
part of a negotiation. I think we could all agree that it would be an
entirely inappropriate use of a media stream to try and run a DTMF digit map
query protocol in it. Thus, while I am not supporting the merging or
incorporating MGCP in SIP, I am proposing that the DTMF digit collection
mechanism of MGCP be incorporated in the SIP feature set. My apologies if
this combinations of the ideas and issues of many has already been
considered; however I personally have not heard this particular solution
suggested.

So, to summarize my proposed solution:

1- DTMF digit map technique becomes part of SIP; client simply presents map
and waits for SIP to fulful it, returning result in INFO
2- Media stream may contain raw DTMF digits in form of tone waveforms, but
no special RTP DTMF passing would be used
3- Technique in (1) confines DTMF binary digit input to control/signaling
plane as prompted user stimulus initiated by SIP client and resolved by SIP
server
4- MGCP in Softswitch used to implement/support functionality in (3)
5- SIP used for all connection initiation and management as originally
intended
6- Technique in (2) is by-product of tones inserted into media stream by
terminal and supported transparently as a pass-thru for analog devices on
the other end of the connection.

In addition, a few DSP operations such as voice energy level detection, as
used for barge-in, need to be detected by DSPs on the MG rather than the
ESP. Otherwise we are back to a HW solution for the ESP. The solution, I
would think, would be to add a few more functions to SIP for the remaining
voice-oriented DSP functions that are best left to the huge DSP capabilities
of most MG.

Summarily, DTMF and voice detection are simply user stimulants that must be
requested by the the client, and SIP may provide a perfect protocol
framework for these operations.

Regards,

Greg Girard
CTO
Iperia, Inc.