Hi all,
I would like to make a comment regarding the email thread below because I
repeatedly see that some critical issues are continually ignored by the RFC
2833 ONLY camp.
All of the forking DTMF discussions I have read have focused on an SDP that
presents two media streams. This approach outlines a call where there is a
feature server interested in DTMF in addition to an end destination media
path. This description however has been limited to a single feature server
per call. It would be extremely limiting to expect or even enforce that
multiple feature servers can not participate in the same call. If we allow
multiple feature servers to be engaged in the same call, then we would need
multiple media lines (3 or more) to be contained within the SDP.
If we establish that we will need 3 or more media lines for real world
deployment, then what should the maximum number of DTMF forkings be? This
maximum number chosen will therefore determine the number of applications
allowed in these next generation networks. In other words, this decision
will place a hard limit on the continued expansion of next generation
applications.
Once we have gone this way, then another problem will arise. The problem is
in how to handle feature interaction. Feature interaction will come into
play when multiple feature servers are looking for the same DTMF events.
Under the gateway forking model, all interested features servers will
receive the same event simultaneously. Each feature server will then
attempt to act upon the event and a non-deterministic behavior will arise.
The final point against this model (which was also pointed out below) is
that 4, 5, or 6... media forkings would place an extreme burden on media
gateways, especially high density trunking gateways. This will in turn
significantly drive up the cost of these gateways by a very substantial
amount. So much in fact, that industry economics will force other solutions
to come into play regardless of the personal opinions of the protocol
creators. (I'm sure everyone can think of instances where standards were
modified or abandoned due to real world industry issues.)
The obvious way to solve all of the problems mentioned above would be to
provide a mechanism for sending these events in the signaling path. Another
approach would be to fork only two media paths from the gateway and then
force the feature server to create a daisy chained RFC 2833 media path
between each of the feature servers thus paralleling the signaling path
entirely. This approach would require a separate RTP stream for every call
being handled by the feature server however. One can easily see the
complexity this solution would introduce, especially when security was being
enforced and I imagine the call per second performance of such a server will
be impacted.
Regards,
Jerry Ryner
Nuera Communications, Inc.
[Sip-implementors] Sending DTMF digits
Jean-Francois Mule Jean-Francois Mule <[EMAIL PROTECTED]>
<mailto:Jean-Francois%20Mule%20%3cjfmule%40clarent.com%3e>
Thu, 30 Aug 2001 13:10:34 -0700
* Previous message: [Sip-implementors] Sending DTMF digits
<http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-August/001789.
html>
* Next message: [Sip-implementors] retransmission time-out
<http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-August/001782.
html>
* Messages sorted by: [ date ]
<http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-August/date.ht
ml> [ thread ]
<http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-August/thread.
html> [ subject ]
<http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-August/subject
.html> [ author ]
<http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-August/author.
html>
This question keeps poping up and, frankly, it just shows how unclear
this topic has remained for many sip implementors.
I've followed the many threads on this topic; the mahy-signal-digits
draft is simply a work around so that noone can be blamed or even busted
on the mailing list for using INFO, but now implementors have got to
support notify or both subscribe/notify. The fact is that multiple
implementations do support dtmf via INFO today in service deployments:
it works.
The suggestion from Brett and others to redirect the rfc2833 stream to
the signaling plane is certainly a good one but:
1. at the signaling level, it means 2 m lines in sdp (and subsequent
connection/bearer control associations). What if the implementation
just rejects the second media line with 415? do you give up on passing
the DTMF or tear down the call just because of that? if it is
supported, there is still a need to open a new udp port and listen for
rfc2833 packets on it...
2. at the DSP/gw data pump level, the implications of separating the
rtp/media from rtp/dtmf and create 2 packets stream is not simple.
I'm not sure how many sip implementations with media resources could do
support that.
There are good reasons for using the rfc2833 over INFO (timestamps,
possible redundancy, named events, etc.) so I am not saying only use
INFO but why keep objecting to it when the application needs are to
simply get the DTMF alphanumeric digit and me be some other simple
parameters like DTMF duration? this will remain a sip mystery to me.
As a neutral comparison:
- in mgcp, you can do both: telephone-events end-to-end and/or report
digits to the mgc.
- in H.323, everyone uses the h.245 userinputindication which is very
similar to the info method. This has never been an issue there at all (&
btw, you can direct the digits to the signaling plane or the media plane
depending on your h245 session). Some implementations can now do both
rfc2833/userinput. When doing a SIP/H.323 IWF, the INFO would be so
easy for the mapping of h245 userinputind (alphanum or signal methods)
but... nop, it is not *allowed*.
That said, the "party line" for implementors is dtmf2833 and then may be
some subscribe/notify...
Jean-Francois Mule.
> -----Original Message-----
> From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]On Behalf Of Bert
> Culpepper
> Sent: Thursday, August 30, 2001 7:23 AM
> To: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> ;
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> Subject: RE: [Sip-implementors] Sending DTMF digits
>
>
> Hello,
>
> You can achieve somewhat equivalent results of DTMF on the
> signaling plane
> using RFC2833 and SDP as you would using some SIP method.
> That is, indicate
> a telephone-events media session in the SDP and direct it
> where you want
> independent of any/all other media streams. (See example in
> bis-04 section
> B.5.). This requires the interested party to decode RFC2833
> data, but it
> would have to decode any other representation.
>
> Several proposals have been made over time based on Kuthan's
> I-D referenced
> below. However, they have been rejected so-to-speak in favor
> of RFC2833 as
> a standard. (RFC2833 has wider applicability.) Your algorithms are a
> little more complex for handling reliability and ordering but
> not difficult
> IMO. For networks that have softswitches, it does require
> support in media
> gateways in addition to mgcp/megaco representation. However,
> this was never
> mentioned as a concern.
>
> There is a current proposal using SUB/NOT for "transport" of
> RFC2833 data.
> http://www.ietf.org/internet-drafts/draft-mahy-sip-signaled-di
<http://www.ietf.org/internet-drafts/draft-mahy-sip-signaled-di>
> gits-01.txt.
> This method does place the DTMF in the signaling plane. I
> myself have not
> seen any discussion of it however.
>
> Regards,
> Bert
>
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> > [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]On Behalf Of
> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> > Sent: Thursday, August 30, 2001 2:44 AM
> > To: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> > Subject: [Sip-implementors] Sending DTMF digits
> >
> >
> >
> >
> > Hi ,
> > Sending DTMF on signalling plane has many uses especially in
> > softswitch
> > where the softswitch may want to request collection of
> > digits during a
> > connection without using any special media detection
> > resources. What is the
> > status of these primitives discussed in draft-kuthan-info-payload-00
> > especially on reliable and in-order transport of these
> > digits? Is embedding
> > mgcp bodies no longer valid?
> > -sumit
> >
> >
> >
> > Jonathan Rosenberg <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> > on 08/30/2001
> 11:50:04 AM
> >
> > To: "'Dan Firac'" <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> >,
> > [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> > cc: (bcc: Subhash Ullal Nayak/HSSBLR)
> >
> > Subject: RE: [Sip-implementors] How to send DTMF digits?
> >
> >
> >
> >
> > There is no IETF standard mechanism for using INFO. The
> > preferred approach
> > is rfc2833.
> >
> > -Jonathan R.
> >
> > ---
> > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
> > Chief Scientist First Floor
> > dynamicsoft East Hanover, NJ 07936
> > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
FAX: (973) 952-5050
> > http://www.jdrosen.net <http://www.jdrosen.net>
PHONE: (973) 952-5000
> > http://www.dynamicsoft.com <http://www.dynamicsoft.com>
> >
> > -----Original Message-----
> > From: Dan Firac [mailto:[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> ]
> > Sent: Monday, August 27, 2001 7:48 AM
> > To: [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> > Subject: [Sip-implementors] How to send DTMF digits?
> >
> >
> > Hello,
> >
> > How should I send DTMF digits? Using RTP (RFC2833) or
> through the INFO
> > header ?
> >
> > If the answer is using RTP, where can I find solid documentation for
> > atributes like 'fmtp', 'rtpmap' for defining dynamic payload
> > types. It will
> > be usefull for me if you have a SDP message dump for two audio media
> > streams, one for G723 and other for DTMF, along with the
> > dynamic payload
> > type definitions for: the redundant type and the
> > telephony-events type.
> >
> > Thank you,
> > Dan Firac,
> > Software Engineer,
> > +4093260623
> > Redline Communications
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
