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-August/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
