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

From: "Pete Cordell" <[email-masked]>
Date: Mon, 22 Nov 1999 11:50:17 -0000

-----Original Message-----
From: Adam B. Roach <[email-masked]>
To: Pete Cordell <[email-masked]>
Cc: [email-masked] <[email-masked]>;
[email-masked] <[email-masked]>
Date: 19 November 1999 00:09
Subject: Re: DTMF signaling between media gateways - ouch!

>>Atomic things like transfer can probably easily get away with being
>>functionally signalled.  However, I think transfers will occur as a result
>>of DTMF signalling, even if only indirectly, such as in a call center.  I
>>really don't want to down load a patch (that may be phone specific) for
each
>>call center I contact.
>
>You seem to be missing the bigger picture here:
>
>Call transfer is well defined within the call control draft.
>It won't be done via any sort of DTMF signalling; it'll be
>built in to the end devices. No patching involved...
>

No, you've missed what I'm saying...  Call transfer may take place using
procedures defined in the call control draft, BUT the event that causes the
call transfer to be kicked off MAY be some DTMF signal.

Pete

=============================================
Pete Cordell
[email-masked]
=============================================

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Nov 1999 15:06:12 -0500

> call transfer to be kicked off MAY be some DTMF signal.

Not in the SIP architecture. An MG may get a DTMF signal that means
transfer, and then the CA can invoke SIP procedures to perform the
transfer function. In this case, use of dtmf to signal transfer services
is not within SIP. Note that, in a pure SIP environment, a proxy cannot
transfer a call. Thats because it requires end systems cooperation, as
media is end to end. Thus, UAs invoke transfer directly.

-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: Jean-Hugues ROBERT <[email-masked]>
Date: Tue, 23 Nov 1999 16:01:11 +0100

Hi,

>Not in the SIP architecture.

Customer calls Company's IVR
IVR plays annoucement "1 for sale, 2 for support,..."
Customer send DTMF 1
IVR initiates SIP transfer.

I guess we have a "DTMF initiated call transfer" here ?

Depending on the architecture, IVR may be a single entity
or a decomposed entity with a control endpoint and a media
endpoint.

With a decomposed IVR, DTMF should get somehow to the
control endpoint.

Yours,

Jean-Hugues Robert

--------------------------------------------------------------------
[email-masked]                                        "Think globally.
www.8x8.com                                            Act locally."

---

From: Chip Sharp <[email-masked]>
Date: Tue, 23 Nov 1999 10:32:10 -0500

>With a decomposed IVR, DTMF should get somehow to the

Yes, and traditionally this is done independent of the call setup signaling 
method (e.g., inband DTMF direct from the phone to the IVR).  If the IVR is 
provided by a Company different from the SIP service provider, they 
probably don't want their IVR services totally dependent on the 
capabilities of the service provider.

>Jean-Hugues Robert

Support NetAid!  http://www.netaid.org
--------------------------------------------------
Chip Sharp                 Consulting Engineering
Cisco Systems              Telco Bio-region
Reality - Love it or Leave it.			
--------------------------------------------------

---

From: Michael Thomas <[email-masked]>
Date: Tue, 23 Nov 1999 08:02:28 -0800 (PST)

> With a decomposed IVR, DTMF should get somehow to the

All this reinforces is Jonathan's point: DTMF
signaling should be outside of the scope of the
actual signaling. I'm not sure why people are
getting so hung up about DTMF as if it were from a
different planet. If you did nothing more than
replace DTMF with your keyboard, an application
could either intercept the keys and interpret them
locally (eg, the UA acts on them directly), or it
could transport them using another protocol (eg,
telnet, or X) to another application which then
signals the local app what to do.

For example:

App1 on vertigo.cisco.com: rsh mtcc.com ivrapp
App2 on mtcc.com: 
  printf ("press 1 for sales, press 2 for support")
  >>wait for keypresses over socket<<
App1: >>user presses "1"<<
App2: rsh vertigo.cisco.com xv - `cat salesdroid.jpg`

If you substitute SIP for rsh and RTP for the
actual data flowing between the two apps, you have
this entire discussion in a nutshell.

What some people are suggesting is that this just
cannot be done unless we rewrite "rsh". Seems
pretty simple to me though.

		Mike

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Nov 1999 17:18:20 -0500

> With a decomposed IVR, DTMF should get somehow to the

Correct. This works since the IVR is acting as a UA in SIP terminology.
Similarly, a "proxy" can insert itself into the media path, and thus
receive both RTP and SIP. This would allow it to transfer calls without
the two end users actually invoking the service. Thats because its not
really a proxy, but rather back to back UAs. 

Gregory Girard wrote:
> 
> mention ? I've spoken with a whole lot, and no one is impressed by SIP
> duplicating SS7 functions to set up and tear down calls. As a body of
> interested parties, we would do well to propose a SIP model that at the very
> least can support legacy apps, if not provide some measure of obvious
> improvement.

The reason SIP doesn't duplicate SS7 functions, and achieve this parity
with it, is that this is not the goal. We already have SS7. I don't see
any reason to re-invent a protocol that is nothing more, nor less, than
SS7 over IP. Rather, SIP can do lots of really cool things, and
innovative new services, that are completely outside the realm of
possibility for traditional telephony. These, IMHO, are the selling
points for SIP, not for its ability to do "AIN feature 443". 

Later, you write:
> SIP cannot even approach parity now through its data-oriented approach, thus
> we all have some holes to plug in the model.

Better believe it that SIP takes a data-oriented, IP-centric,
web-centric approach. This is entirely the point.

-Jonathan R.