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

From: "Schroeder, Tim" <[email-masked]>
Date: Mon, 22 Nov 1999 17:38:37 -0600

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: "Paul E. Jones" <[email-masked]>
Date: Tue, 23 Nov 1999 02:10:45 -0500

Tim,

> can handle all service signaling that easily.

I doubt folks have confused the two.  I, for one, completely agree with your
comments.  SIP is exactly that-- a Session Initiation Protocol.  It is not a
Session Control Protocol (which we arguably need) or anything else.  I think
people understand that, but are trying to provoke some discussion on how to
fill in the gaps.

I've seen several proposals that attempt to twist SIP into something it is
not.  As a complete system, there are some deficiencies in using SIP alone,
but those deficiencies can be worked out.  In order to do so, we must
present the problems that need to be solved.

Paul