In as much as I would have liked to see my proposal (or a similar one)
"accepted" within the IETF I do understand why it (and other similar ones)
wasn't. It has limited (although very useful IMHO :)) applicability. That
is, networks that use mgcp/megaco. The IETF prefers general solutions that
have wide applicability. I understand this philosophy in that it also
promotes interoperability. Which is most important.
<commentary>
I suspect there are IETF standards that may have less applicability (in
terms of potential deployments/implementations) than what I proposed. And
if you're asking about my I-D, providing sufficient interest I can revive
the I-D. Now that SUB/NOT exists, I might propose using those methods
instead of INFO (since it really is a request to get DTMF events). However,
implementations may already exist in which case the I-D can be revived as is
(given the IETF "party line" I don't believe this is worth pursuing though
:-). Although the IETF accepts individual submissions I don't know that
it's advisable to pursue.
I believe the mgcp/megaco event syntax is much easier than RFC2833. There
is no impact on media gateways, the MGCs already do DTMF (and other
telephony events) using mgcp/megaco, they already know how to correlate SIP
call legs to mgcp/megaco "call legs", and we can keep signaling in the
signaling plane. However, this approach is "terrible" for SIP phones. They
need to interact with SIP application servers just like the MGCs. For SIP
phones, RFC2833 is great. It is a very valid view/argument that DTMF is
media, so transport it like media.
I suppose we could ask which device do we burden? Media gateways with
RFC2833 or SIP phones with mgcp/megaco events. I suspect in terms of
numbers the SIP phones win out. However, there are networks that exist that
don't "care" about SIP phones...
For some common situations RFC2833 does not comply with the KISS
principle... From the app server point of view RFC2833 can work with extra
implementation effort. As Jean-Francois says, there is the problem of
de-multiplexing the 2833 from the media. To do this I have to use 2 media
sessions directing the 2833 stream to a different IP address/port from the
audio. (My vocoders can't handle 2833 packets mixed in with G.xxx packets.
And I can't get between the RTP processing and DSP processing to do it
myself.) I can then de-multiplex calls based on IP port at the single IP
address. As I said in an earlier post, we can direct it around independent
of other media and use it as signaling if we choose to. Besides
implementing it (2833), it only requires SIP UA support for multiple media
sessions to different destinations :( Something SIP phones may find odd.
And I suspect a big pain for media gateways.
</commentary>
regards,
Bert
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Ghai, Rajat
> (Rajat)
> Sent: Friday, August 31, 2001 1:50 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] Sending DTMF digits
>
>
> I strongly agree that for simple applications like pre-paid
> PIN collection
> or 2 stage dialling, RFC 2833 based implementation is a
> overkill and puts
> hard requirements on the gateways..
>
> Is there anyway, the now expired draft on DTMF via INFO can
> be revived ?
>
> thanks
> Rajat Ghai
>
> > >-----Original Message-----
> > >From: Barry Desborough [mailto:[EMAIL PROTECTED]]
> > >Sent: Friday, August 31, 2001 6:28 AM
> > >To: 'Jean-Francois Mule'; 'Bert Culpepper'; [EMAIL PROTECTED];
> > >[EMAIL PROTECTED]
> > >Subject: RE: [Sip-implementors] Sending DTMF digits
> > >
> > >
> > >I agree with Jean-Francois. Alphanum userinputindication
> is perfectly
> > >adequate in the H.323 realm for transmitting DTMF events.
> > >Surely, minimal
> > >SIP INFO usage is sufficient for two-stage dialing, PIN entry and
> > >hook-flash. If these are the majority requirements, then rfc2833 is
> > >overkill. Remember KISS?
> > >
> > >Barry Desborough
> > >
> > >-----Original Message-----
> > >From: Jean-Francois Mule [mailto:[EMAIL PROTECTED]]
> > >Sent: 30 August 2001 21:11
> > >To: 'Bert Culpepper'; [EMAIL PROTECTED];
> > >[EMAIL PROTECTED]
> > >Subject: RE: [Sip-implementors] Sending DTMF digits
> > >
> > >
> > >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]]On Behalf Of Bert
> > >> Culpepper
> > >> Sent: Thursday, August 30, 2001 7:23 AM
> > >> To: [EMAIL PROTECTED]; [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
> > >> 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]]On Behalf Of
> > >> > [EMAIL PROTECTED]
> > >> > Sent: Thursday, August 30, 2001 2:44 AM
> > >> > To: [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]> on 08/30/2001
> > >> 11:50:04 AM
> > >> >
> > >> > To: "'Dan Firac'" <[EMAIL PROTECTED]>,
> > >> > [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] FAX:
> (973) 952-5050
> > >> > http://www.jdrosen.net PHONE:
> (973) 952-5000
> > >> > http://www.dynamicsoft.com
> > >> >
> > >> > -----Original Message-----
> > >> > From: Dan Firac [mailto:[EMAIL PROTECTED]]
> > >> > Sent: Monday, August 27, 2001 7:48 AM
> > >> > To: [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
> > >
> _______________________________________________
> 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
