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

From: "Donovan, Steven R." <[email-masked]>
Date: Wed, 08 Dec 1999 15:23:56 +0000

Scott Petrack wrote:

> 
> On Mon, 6 Dec 1999, Dean Willis wrote:
> 
> > 
> > Yes. I would suggest that a media gateway take a DS0 in one 
> side, do a tone
> > detction, ship RTP audio and RTP tones out along its media 
> path, and throw
> > SIP INFO messages on its signaling path.
> > 
> 
> The only issue is how the media gateway sends the message to the
> signalling server. There are already two solutions available:
> 
> 	a) the media gateway sends the DTMF events encoded within RTP
> to both the signaling server and the remote media endpoint. 
> This could be
> done either out two unicast streams or out to a multicast group. 

I'm not sure what you mean by the signaling server here.  In addition to
sending the DTMF to the remote media endpoint, it also needs to make sure
that the SIP user agent is notified of the DTMF events.

> 	b) the media gateway sends the DTMF events encoded in Megaco, as
> if it were talking to an MGC that wants notification.
> 
> If the signalling server can take the information and do with 
> it whatever
> is appropriate. Those of us who like encoding DTMF within RTP 
> point out
> that DTMF is time-based information, often synchronized with 
> other media
> streams. 

It is certainly the case the DTMF, as part of the media stream, is time
based information.  It is also the case that DTMF events are used for
service control.  The time sensitivity for this use of DTMF is much less
stringent and the synchronization with other media is not necessarily
important.

> 
> A simple way to put it is to say that the INFO approach forces a
> media gateway to know about SIP INFO messages, while the RTP approach
> forces a signalling server to know about the RTP DTMF payload.

The SIP user agent needs to know about SIP INFO messages.  The media server
needs to be able to notify the UA of the DTMF events.

> 
> The problem I have with making the media gateway speak SIP is 
> that there
> are a lot of competing signaling protocols which could transport DTMF.
> One customer will want it in a SIP INFO message, another in an H.245
> message, a third in a Q.931 message, etc. Isn't it simplest 
> to say that
> in the Internet architecture, real-time DTMF is encoded in RTP.

Maybe this is the distinction that we have been missing.  I would argue that
we are not really talking about "real-time" DTMF for the SIP INFO message.
If the DTMF is meant to be re-inserted into the media stream or there is a
need to maintain a temporal relationship with other media information, then
RTP encoding and transport is the only thing that makes sense.  

The use of DTMF for service level signaling information does not have the
same real-time constraints.  Yes, it is important that it be delivered in a
timely manner, but not with the same constraints as RTP transport of DTMF.

> 
> Isn't it simpler just to say that DTMF events are always
> encoded in a single way which doesn't lose information -- 
> encoded in an
> RTP payload format. 
> 

The question is where the SIP user agent resides.  In the case that the user
agent is physically part of the media server, then the DTMF events would be
sent as part of the RTP media session and as a payload in the INFO message.
The communication of between the media server and the SIP UA in this case
would be an internal issue.

If the SIP user agent resides in the media gateway controller, then there
needs to be a method for the media server to report on the DTMF events to
the MGC.  MEGACO has defined a method for this to happen.  The media server
would still send the DTMF as part of the RTP session.  It would also need to
send the DTMF event notifications to the MGC.  The SIP UA in the MGC would
then be responsible for sending the SIP INFO message.

Steve

<snip>