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

From: "Gregory D. Girard" <[email-masked]>
Date: Tue, 23 Nov 1999 18:17:29 -0500

I'd love to hear a service one can't do with PSTN telephony that one can do
with SIP. Any suggestions would be nice to propose to service providers. I
have yet to hear of any yet besides some variations on location services
already implemented as follow-me services. Thanks for any info.

Greg Girard

-----Original Message-----
From: Jonathan Rosenberg <[email-masked]>
To: Jean-Hugues ROBERT <[email-masked]>
Cc: Pete Cordell <[email-masked]>; Adam B. Roach
<[email-masked]>; [email-masked]
<[email-masked]>
Date: Tuesday, November 23, 1999 5:17 PM
Subject: Re: DTMF signaling between media gateways - ouch!

>
>
>Jean-Hugues ROBERT wrote:
>>
>> 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.
>
>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.
>--
>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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Nov 1999 18:31:49 -0500

> already implemented as follow-me services. Thanks for any info.

Well, thats easy. Nearly any service that integrates voice with web,
email, instant messaging, chat, presence, IRC or any other IP
application obviously doesn't work on the PSTN. Here's a few examples:

call transfer to web
call redirect to email
Web IVR
Web voicemail
jpeg caller ID (as we've discussed, include a URL in the INVITE that
gets a JPEG image of the caller. Last I checked, ISUP and Q.931 didn't
have MIME support and URLs)

The list of possibilities is quite extensive.

-Jonathan R.