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

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 16 Nov 1999 15:23:16 -0600

Comments below.

> -----Original Message-----
> From:	Dean Willis [SMTP:[email-masked]]
> Sent:	Tuesday, November 16, 1999 2:29 PM
> To:	Jonathan Rosenberg; Taylor, Tom-PT [CAR:B904-I:EXCH]
> Cc:	sip
> Subject:	User signaling -- was DTMF signaling between media gateways
> - ouch!
> 
> Jonathan Rosenburg wrote:
> > What services could proxies provide in the SIP model by receiving DTMF?
> > Nearly every application of DTMF I have heard brought up required the
> > entity receiving the DTMF to be a UA, in which case it could get the RTP
> > stream instead.
> 
> 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.
> 
> 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.
	[[TomT]]  
	It has to happen at one end or the other.  There are several
possibilities, all assuming that the user input is captured and encoded at
the originating gateway:
	(1) Originating gateway is a single unit, not decomposed.  SIP INFO
method seems to be the best choice, so that the IVR doesn't have to
implement RTP as well as SIP.  I must have assumed decomposed gateways when
I sent my message the other day.
	(2) Originating gateway is decomposed.  User input is sent up to the
MGC via Megaco and sent on as a SIP INFO message.
	(3) Originating gateway is decomposed.  User input is encoded as a
separate RTP stream and sent to a IVR media box.  From here it is sent up to
the IVR controller via Megaco.  This only makes sense if the media box
expects to receive other media streams.
	(4) Originating gateway is decomposed.  User input is encoded as a
separate RTP stream and sent to the IVR directly from the MG.  Thus the IVR
controller has to understand RTP as well as SIP.  The originating MGC has to
tell its MG where to send the digits.  What we get in recompense is more
direct routing of the information and reduced processing demands on the
originating MGC.

	Seems to me that the choice between 2, 3, 4 isn't obvious.

> 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.
> 
> 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.
	[[TomT]]  
	Since P is a proxy, how does it know that it should consume the "R"
and not pass it on?  Seems to me your generic UA gateway has to understand
that input.

> --
> Dean

---

From: Dean Willis <[email-masked]>
Date: Thu, 18 Nov 1999 16:40:54 -0600

> Dean proposed:
tone

TomT asked:
> Since P is a proxy, how does it know that it should consume the "R" and
not pass it on?  Seems to me your generic UA gateway has to understand that
input.

P is a SIP proxy with application logic, like Calista (www.generalmagic.com)
is a PSTN proxy with application logic. We can't put the logic into a
generic gateway, becase IT'S GENERIC!

What I'm trying to say is that by simply configuring the gatway to route
calls through P, the user can receive the benefits of the applications logic
at P with some measue of independence from the features and user interface
of the user's phone and gateway. This is the key to building third-party
application capability for stupid phones into the SIP environment. Kind of
like why your browser merely displays HTML and executes a few scripting
primitives instead of containing an entire stock trading application logic.

--
Dean