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
