There were two specific proposals made last year that I'm aware of. Links
follow.
http://www.globecom.net/ietf/draft/draft-choudhuri-sip-info-digit-00.html
http://www.softarmor.com/sipwg/drafts/morgue/draft-culpepper-sip-info-event-
00.txt
I am not aware of which one (if either) others have implemented.
Being able to ask for, and knowing whether you will receive DTMF is a
desired capability IMHO. Both RFC2833 in SDP and the info-event (although
SIP-T focused) provide for that. So for myself, the SUB/NOT is a good way
to go, with a textual representation preferred.
Regards,
Bert
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> John Oliver
> Sent: Friday, September 07, 2001 10:27 AM
> To: Bert Culpepper
> Cc: [EMAIL PROTECTED]
> Subject: RE: [Sip-implementors] Sending DTMF digits
>
>
> Would you happen to have a copy of the expired DTMF/INFO
> draft or know where
> I can get it? I would like to see what people are asking to have
> resurrected.
>
> It is true that RFC2833 is not there unless you ask for it,
> but is there a
> way to determine that you will be getting DTMF/INFO before
> one actually
> arrives? If not, then one must request RFC2833, thereby creating the
> potential for duplication.
>
> Maybe the body defined in the old INFO draft should be put into
> SUBSCRIBE/NOTIFY, as an alternative to the signalled-digits draft.
>
> -John
>
> On 4 Sep 2001, at 16:44, Bert Culpepper wrote:
>
> >
> > The I-Ds that described using INFO for DTMF are now
> expired, RFC 2976
> > mentions the use of INFO for sending DTMF but does not
> define how to do it.
> >
> > I don't think anyone can argue that RFC2833 does not meet
> the requirements
> > listed below. However, unlike H.245 the RFC2833 data is not in the
> > signaling path.
> >
> > If we acknowledge that ability to send DTMF along the
> signaling path as a
> > valid requirement, using RFC2833 is problematic as described in
> >
> http://lists.cs.columbia.edu/pipermail/sip-implementors/2001-A
> ugust/001803.h
> >
> > tml. There is no simple method for the application set
> that simply wants
> > the digits and their order. BTW, if there was a method,
> RFC2833 is only
> > present when asked for so preventing duplicate events is easy.
> >
> > Regards,
> > Bert
> >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]]On Behalf Of
> > > John Oliver
> > > Sent: Friday, August 31, 2001 5:32 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: RE: [Sip-implementors] Sending DTMF digits
> > >
> > >
> > > I do not recall any draft or RFC that defines just how to
> > > include DTMF in
> > > the INFO method. (If there is such a specification, please
> > > let me know). I
> > > have seen one gateway that included DTMF simply as one or
> > > more characters in
> > > the body of a SIP INFO method.
> > > My work involves application servers and depending on which
> > > application is
> > > involved, I need to:
> > > - Receive notification of a DTMF event as soon as possible
> > > after it starts
> > > - Know the final duration of that DTMF event
> > > - Receive a CNG indication if the call is a fax
> > > - Potentially receive other information that is currently
> > > carried in the
> > > audio stream of a PSTN call.
> > > - Have the ability to align the received event with the audio
> > > stream. I
> > > admit this is not a frequent need, but it can be useful
> information.
> > >
> > > INFO, as I have seen it used, does not provide most of this.
> > > The H.245 userInputIndication has the ability to provide
> > > DTMF, duration,
> > > and RTP timestamp, with the ability to update the duration as
> > > needed until
> > > the DTMF event completes. RFC2833 provides all of this
> information.
> > > Since I can receive the information I need via RFC2833/RTP,
> > > then I do not
> > > want the confusion of receiving this information through any
> > > other path.
> > > Duplication of a DTMF event is as bad if not worse than
> missing one.
> > >
> > > Finding a single method of delivering DTMF and other
> > > telephone-events while
> > > including all of the above capabilities is the essence of my
> > > requirements.
> > > Using RFC2833 only, with multiple m= lines if necessary, is a
> > > way that is
> > > already covered by completed specifications, a blessing
> > > within the shifting
> > > sands of SIP implementation.
> > >
> > > -John
> > >
> >
> >
> > [snip]
> >
> > _______________________________________________
> > 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
