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

From: Scott Petrack <[email-masked]>
Date: Sun, 5 Dec 1999 13:08:53 -0500 (EST)

If the following is to out of date, forget it:

On Tue, 16 Nov 1999, Dean Willis wrote:

> Jonathan Rosenburg wrote:
> 
> See my previously posted example of an IVR which participates as a SIP
> signaling system but has all of its media paths terminated on set of media
> servers somewhere else.
> 
If there is DTMF involved, then somewhere in the system the DTMF
information must be produced or extracted or detected. (It is possible
that this happens in the end-system, if you are building a client that
is explicitly designed to reproduce the beautiful IVR UI). At that point,
wherever it is, DTMF events are being produced. All that we have ever been
saying is that in the overwhelming number of cases, the timing of the DTMF
events (at least their timing relative to something else) is important,
and the RTP format is the way to encode the events in such a way that
information is not lost. Whether this information is "media" or "not" is
sort of a red herring. What is not is if you really are encoding DTMF
information. If you are, then the application is probably best served by
using the standard encoding rather than invent a new one. If for whatever
reason it is vital that some SIP servers or clients get the DTMF
information synchronized with some other signals, then it would make sense
to put an audio/tones or audio/events payload into a SIP message. But in
fact this doesn't make sense very often. This is because if you are
interested in actual control signals and not lower-level DTMF events,
well, then you are not interesed in DTMF events.

> Yeah, I suppose we could have the detected tones schlepped back from the
> media server to the IVR over yet-another-potocol, but that doesn't seem
> particularly efficient.
> 
If you're detecting tones, then you have to detect them somewhere.
Wherever that place is, media is involved. If you're not detecting tones,
then I don't think you need any DTMF payload, since no DTMF was produced.

> Consider also that the end goal is NOT to ship DTMF, but to ship user input
> notifications. Today, a user input notification is DTMF because that's what
> the phones have, but it isn't going to stay that way.
> 
Yes, and the end goal is not to need gateways that receive DTMF and
translate them into some functional command. Today, there is a need for
DTMF detection in some place and then a translation into digital
information. That place is in fact a media gateway.

> If that isn't enough, let me propose another application.
> 
> 
> User A completes all calls through proxy P.
> 
> P provides additional services, along the lines of a "personal assistant".
> One of these services is a "voice recorder" ala President Nixon.
> 
> A uses an analog phone connected to a generic UA gateway.
> A calls party B, leaving P in the proxy path.
> A decides B is saying something interesting and wants B recorded.
> A presses the "R" key.
> P uses call control to add a voice recorder and recording announcement tone
> generator and conference bridge to the call.
> P never saw a single byte of media.
> 
No, P presumably saw a "record command" perhaps it was an RTSP server
(perhaps not, you didn't say). BUT if A's device sent some DTMF events in
response to A pressing the "R" key, then there will be a server somewhere
in the middle which gets the DTMF event and transforms it into a server
command.

I have no problem with the result of A's pressing the "R" key being that
A's device sends a SIP invite to a recording server, inviting the server
to listen in. In this case, it is entirely normal for the "R" key
resulting in a SIP INVITE being sent. (Although RTSP wouldn't be bad
either). But I certainly can't see how this is a reason to send DTMF
within a SIP message.

Now that we've allowed the INFO method as a way of transporting a
signalling payload along the SIP signalling path, I don't think that we
can stop putting an rtp payload in there.

Scott

---

From: Dean Willis <[email-masked]>
Date: Mon, 06 Dec 1999 11:48:51 -0600

Scott said:
. . .
> well, then you are not interesed in DTMF events.

Bingo. My position is that DTMF is in some cases a manifestation of a
control signal. We use it because it is the only user-invokable control
signal we know how to produce on a black phone (except maybe for speech
recognition).

> > media server to the IVR over yet-another-potocol, but that doesn't seem

. . .
> information. That place is in fact a media gateway.

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.

Initially, I suggest just putting the DTMF representation into the INFO
message, as this requires no additional knowledge of the application in the
media gateway. This gives us a basic set of "function keys" that are going
to be present on every phone device -- kind of like F1-F12 on your PC
keyboard. Why use a DTMF representation? Because the phones send the data in
DTMF, and the gateway has to implement DTMF detection/decoding anyhow -- a
DTMF representation in INFO then becomes a very easy thing to build and is
rather generically useful.

Someday somebody may want to develop a gateway or phone that throws
customized INFO events, and probably a method for loading digit-event maps
into the gateway of phone so that the event thrown can correspond with the
application being used. One might even envision acivating custome soft-keys
on the keypad of an advanced phone. For basic telephony interaction, we
don't need that right now, and I'm not prepared to think about it yet.

> in the middle which gets the DTMF event and transforms it into a server

Yes, I think you have it here.

> either). But I certainly can't see how this is a reason to send DTMF

I want to decouple control of the application from the endpoint and move it
to a server. In other words, A's device would not send an invite to the
recording server. A's device's proxy would. The question is how does A
signal the proxy so that the proxy can invoke the recorder.

I've proposed that in the absence of any specialized application logic, that
A's device can just throw DTMF-event INFO messages at the network, and a
network application (in a proxy) can control the application. This requires
no specialized applications logic in A's device because the interaction with
the proxy is entirely standard and generic.

> can stop putting an rtp payload in there.

Huh? The media stays in RTP . . .

--
Dean

---

From: Scott Petrack <[email-masked]>
Date: Mon, 6 Dec 1999 16:44:29 -0500 (EST)

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

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

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. 

Scott

> rather generically useful.

All this is even more "generic" if you just use the same DTMF
representation in every case.

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 07 Dec 1999 15:11:49 -0600

> in the Internet architecture, real-time DTMF is encoded in RTP.

We have no control over H.xxx in the IETF, so need to look here what works
best in the Internet conferencing architecture.
SIP INFO seems to the job. What specifically does it not do? (If we keep the
required SIP servers in the signaling path)

Henry

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Scott
> Petrack
> Sent: Monday, December 06, 1999 3:44 PM
> To: Dean Willis
> Cc: [email-masked]
> Subject: RE: User signaling -- was DTMF signaling between media gateways
> -ouch!
>
>
>
>

---

From: "Adam B. Roach" <[email-masked]>
Date: Mon, 13 Dec 1999 15:58:20 -0600 (CST)

>From: Henry Sinnreich <[email-masked]>

>required SIP servers in the signaling path)

It does not allow trivial synchronized re-insertion of DTMF at the 
far end of a PSTN-SIP-PSTN connection using an voice compression codec
(e.g. GSM 6.10 or G.723) in the middle.

That is the key argument for RTP based DTMF encoding.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA