I may be a bit shortsighted here, but I can't see a situation where there
would be more than 2 application servers in a single call, at least not ones
that would care about DTMF. And in that situation one of the servers would
be an endpoint, so still only 2 destinations for the RFC2833 stream.
-John
On 31 Aug 2001, at 19:46, Ryner, Jerry wrote:
>
> 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
>
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
