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

From: "Gregory D. Girard" <[email-masked]>
Date: Tue, 23 Nov 1999 08:48:33 -0500

Henry,
It real gets back to a simple issue regarding the scope of the problems one
is trying to solve. Certainly the SIP-related issues will be much more tidy
if one closes the aperature to only address a theoretical problem set. Well,
as Pete has correctly and repeated pointed out, the world begs to differ.
SIP, realistically or not, has been touted as a general purpose signaling
interface extensible to a wide range of applications. If SIP is
inappropriate for this task, then lets just move on to creating the next
protocol that will directly compete with SIP, much the way that SS7 overtook
its predessessor.

For example, one could propose Session Management Protocol. It will
incorporate all the existing functionality of SIP, plus the telephony user
stimulus and other mid-session management features required to support
real-world services, such as DTMF support, existing SIP call control
extension for blind-transfers, and a host of other things that you just
cannot do without (if you want to at least reach functional parity with
legacy PSTN products).

I don't recall reading the "Requirements Document" for SIP (there is none),
so I'm not aware of any boundaries on functionality beside those related to
establishing and managing a call session involving one or more connections.
Henry, have you spoken with any customers about the "new services" you
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.

SIP cannot even approach parity now through its data-oriented approach, thus
we all have some holes to plug in the model. In my opinion, Pete is simply
approaching it from the requirements/market side, while some seem to be
driven to incorporate nuances related to some very very basic functionality
(seriously no personal insinuation here, just a general observation that
rightfully much of the discussion surrounds refining simple functions. Some
of us who have less expertise and involvement with the subtleties of SIP are
more interested in how larger problems get solved, some of which may be
slightly different than once envisioned at time of inception).

Greg Girard

-----Original Message-----
From: Henry Sinnreich <[email-masked]>
To: Pete Cordell <[email-masked]>; Schroeder, Tim
<[email-masked]>; [email-masked]
<[email-masked]>
Date: Tuesday, November 23, 1999 8:28 AM
Subject: RE: DTMF signaling between media gateways - ouch!

>Pete Cordell wrote
>> I'm here because
>
>Pete, if this is the reason for stuffing our mail, just say so and let's
get
>back to designing features we need for new services. As mentioned,
telephony
>legacy systems can be accommodated by gateway features and their ways need
>not be ported to the Internet. I suggest we stop this thread, it's been a
>drag already.
>
>Henry
>
>Henry Sinnreich
>MCI WorldCom
>400 International Parkway
>Richardson, Texas 75081, USA
>
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]On Behalf Of Pete Cordell
>> Sent: Tuesday, November 23, 1999 5:24 AM
>> To: Schroeder, Tim; [email-masked]
>> Subject: Re: DTMF signaling between media gateways - ouch!
>>
>>
>> My feeling is that SIP stopped being purely an initiation protocol a long
>> time ago.  In fact, when the BYE method was added, it no longer was
purely
>> an initiation protocol.  It went further down the path when all the call
>> transfer stuff was added.
>>
>> I'm here because SIP is being touted as a solution for Internet
Telephony,
>> which involves more, much more, than just initiation.  If that's not what
>> it's about a decision needs to be made quickly and the message
>> that is being
>> spread by SIP advocates needs to be changed to avoid confusion in
>> the market
>> place.
>>
>> Pete
>>
>> =============================================
>> Pete Cordell
>> [email-masked]
>> =============================================
>>
>> -----Original Message-----
>> From: Schroeder, Tim <[email-masked]>
>> To: [email-masked] <[email-masked]>
>> Date: 22 November 1999 23:44
>> Subject: RE: DTMF signaling between media gateways - ouch!
>>
>>
>> >I'm a bit confused by much of this DTMF discussion.  SIP is a Session
>> >Initiation Protocol, so it understands how to initiate sessions.  As for
>> the
>> >mid-call DTMF tones,
>> >
>> >(1) If they are coming from some network where those tones *do* have
>> session
>> >initiation implications, then the gateway ought to be able to map them
to
>> >the existing set of SIP messages in some rational fashion.  So, in a
>> network
>> >where the DTMF 7 tone (R for record) means to add a recording
>> device to the
>> >call, the SIP gateway would map this to an invite of a recording
>> device to
>> >the call.
>> >
>> >(2) If those tones don't have session initiation implications,
>> then I don't
>> >see why any of the SIP network servers would understand them
>> (any more than
>> >a gateway would understand them); only the end systems would.  Yes, they
>> may
>> >be used for signaling, but it's not session initiation signaling, and I
>> >don't understand the desire to somehow wrap them up into SIP messages
and
>> >send them between end systems that way.  I see SIP as being used
>> to set up
>> a
>> >session between end systems, possibly consisting of two media
>> channels, one
>> >used for end system signaling, one used for end system data.  I haven't
>> made
>> >the leap that because the end systems are interpreting some data as
>> >signaling, that the data should be sent using SIP messages.
>> >
>> >My impression from reading all the DTMF messages (and in trying
>> to catch up
>> >-- there were a lot of them!) is that two separate kinds of signaling
>> >(session initiation, and some higher level service signaling) are being
>> >confused.  Currently SIP handles the first type.  Adding the INFO method
>> >might make it able to handle some of the second type, but I
>> don't think it
>> >can handle all service signaling that easily.
>> >
>> >Tim Schroeder
>> >
>> >
>> >
>> >This e-mail and any files transmitted with it are the property of SBC,
>> >are confidential, and are intended solely for the use of the individual
>> >or entity to whom this e-mail is addressed. If you are not one of the
>> >named recipient(s) or otherwise have reason to believe that you have
>> >received this message in error, please notify the sender at
>> >[email-masked] and delete this message immediately from your
>> >computer. Any other use, retention, dissemination, forwarding, printing,
>> >or copying of this e-mail is strictly prohibited.
>> >
>> >
>> >
>>
>>
>
>

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 23 Nov 1999 10:12:19 -0600

Gregory,
> For example, one could propose Session Management Protocol.
may be an interesting proposal. Why don't you write a 1st draft?
Let's see it.

Henry

> From: Gregory D. Girard [mailto:[email-masked]]
> Sent: Tuesday, November 23, 1999 7:49 AM
> To: Henry Sinnreich; Pete Cordell; Schroeder, Tim;
> [email-masked]