Subject: RE: Additional Info on DTMF under SIP

From: "Fox, Mike" <[email-masked]>
Date: Wed, 10 Nov 1999 17:13:23 -0800

I suspect that there was a lot of commentary on this issues at the IETF
meeting in DC with avt-tones on this afternoons agenda.  It would be nice to
see a summary of the AVT minutes on this topic forwarded to this list. 

Lets think about  the INFO option:
Ok so now you have the DTMF in an INFO message, What exactly is the
information conveyed, what event happened (given), when the event
happened(?), how long(?). When do you transmit the event: when it starts?
When it ends? Both? What about hook flash, fax/modem answer tones, and all
the other kinds of line signalling events that a SIP softswitch application
may be interested in? So one would suspect this would lead to having all the
avt-tones indications stuffed into the INFO method. Then to get this to work
for a MGCP controlled GW (gateway) you will have to define packages to
register these events via MGCP, then you would have to translate the MGCP
events into SIP INFO methods in the MGC controller, adding more propagation
delay. To get this to work with H.323 endpoints you would have to convert
INFO methods to H.245 UII or the avt-tones format if you wanted to convey
tone duration or other signalling events/attributes not represented in the
UII. This is complexity.

Now consider the rtp-avt-tones method:
GWs and softswitches (MGCP or SIP) could  just listen to the sdp (H.323
endpoints listen to H.245 create/delete connection) and send/receive the
avt-tones stream as they are told. This could be to SIP/MGCP softswitches
and/or other GW endpoints. By sending only to, and listening from a
softswitch, the softswitch could mediate the avt-tones information so that
control of the signalling between endpoints is possible. Or the avt-tones
stream could be sent to both the destination GW(s) and softswitch, or just
between the destination GW(s).  The control of where avt-tones goes, is done
using the sdp syntax which has been already defined for both SIP and MGCP,
or using H.245 for H.323 systems. So once avt-tones is an IETF draft there
is no need make new methods, packages, signalling event  formats,
conversions between different protocols, or a requirement to forward events
though intermediary softswitches . This is simplicity!

The avt-tones approach allows as much "reliability" as you want to
implement, so arguments that an "reliable" ACKed INFO method is better than
avt-tones are less than compelling. The simplification argument does not
seem correct, especially in light of the need to use event packages for MGCP
gateways, and event format conversions between SIP and other protocols
(namely MGCP and H.323).

The idea, posted earlier, that the H.323 group has looked into this issue is
correct. The avt-tones draft is in part the result of the IMTC VOIP work,
and the agreement of H.323 implementers in this IMTC forum that a rtp
signalling mechanism is the preferred method to propagate DTMF/signalling
information. The recommendation of the IMTC VOIP IA is to use a rtp-dtmf
signalling method when one becomes available.

Best regards,
Mike Fox

		-----Original Message-----
		From:	Dean Willis [mailto:[email-masked]]
		Sent:	Wednesday, November 10, 1999 1:14 PM
		To:	Jean-Hugues ROBERT; Michael Thomas; Gregory D.
Girard
		Cc:	[email-masked]; Dye, Robert
		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: Dean Willis <[email-masked]>
Date: Thu, 11 Nov 1999 13:46:24 -0600

> see a summary of the AVT minutes on this topic forwarded to this list.

Oddly enough, the avt-tones discussion passed with almost no commentary.
There was however some discussion of the topic in the SIP WG. The division
was along the lines of:

a) DTMF is just noises in the media path which need to be conveyed to the
other end and dropped off, synchronized to the other noises, in the most
loss-and bandwitdh efficient and compression-tolerant manner possible.

vs.

b) DTMF is user input to the signaling process and can affect call state and
the invocation of features, including features implemented on systems which
exist only in the control plane.

> for a MGCP controlled GW (gateway) you will have to define packages to
 . . .

That's why the draft on using tones-in-info uses the same event package as
MGCP.

> And the avt-tones option

Why does MGCP use media signals rather than just passing the RTP up to the
softswitch?

Answer: because signaling is not the same as media. Passing the RTP upstream
would require splitting off the tones RTP stream, forking it, and proxying
it numerous times along the control path. Messy and awkward.

Thinking of a softswitch as an enhancd services platform is a vey limited
approach. I visualize the current round of softswitch products as
large-scale media gateway controllers and telephony signaling gateways that
adapt from GSTN to SIP. Enhanced services can then be built very simply on
general purpose computers using the same SIP interface to the softswitch
that softswitches use between themselves. These enhanced services often
don't need to be anywhere near the media path.

This structure is directly analogous to the computational model for GSTN
switching that MCI introduced some yeas ago -- the service logic controls
the switching logic which conrols the port hardware. It's very scalable and
very distributable. Of course, doing it with robust IP protocols also makes
it a lot easier than the GSTN network ever was . . .

Let's consider the common IVR (interactive voice response) application:

A caller places a call to the IVR.

If the caller is on GSTN, the call routes to a gateway, becomes SIP, and is
passed to a service node as a SIP INVITE through one or more SIP proxies.

-or-

If the caller is on IP, the call is passed as a SIP INVITE to a service
node, perhaps through one or more SIP proxies.

The service node responds to the IN with a 200 OK describing a media path to
a media player conrolled by the service node via RTSP.

The caller responds with an ACK, and the service node activates playout of a
greeting on the media player.

The caller barges in by pressing key 4 partway through message play.

If the caller is on PSTN, the gateway detects the 4 and sends it along the
signaling path as an INFO message.
-or-
If the caller is on IP, the caller's device generates an INFO message
containing "4" and sends it along the signaling path as an INFO message.

The service node receives the INFO "4" and executes service logic to forward
the call.

Based on the service logic, the service node terminates menu play via RTSP
to the media server and uses SIP call control (INVITE Replaces) to forward
teh call to another destination.

Conclusion: We have demonstrated a useful, modular aproach to application
building which allows for service logic to be completely separate from the
media path. It is enabled by sending detected user input as INFO messages
along the SIP signaling path. Cool.

--
Dean

---

From: Colin Perkins <[email-masked]>
Date: Sat, 13 Nov 1999 17:47:14 +0000

--> Dean Willis writes:
>> meeting in DC with avt-tones on this afternoons agenda.  It would be
>> nice to see a summary of the AVT minutes on this topic forwarded to this
>> list.
>

The RTP payload format for DTMF tones has not been controversial in AVT,
and the main issues were resolved some time ago. The discussion at this 
meeting was just to note that the working group last call on this draft
has completed, and that it would shortly be submitted to the IESG for
consideration as a proposed standard.

>b) DTMF is user input to the signaling process and can affect call state
>and the invocation of features, including features implemented on systems
>which exist only in the control plane.

If there are significant problems with the current RTP payload format for
DTMF which prevent it achieving the goals of (a), then these should be
raised in the AVT group as soon as possible. The choice between (a) and 
(b) is for other working groups to consider.

Colin (AVT co-chair)