Hi,
You can not assume that DTMF will or will not be present as audio in either of the two cases below. The different SDP fragments below only indicate that telephone events are supported/requested to be received on the specified port with the specified payload type. In the first case the events and audio will be combined in the RTP packets arriving on port 8000. In the second case audio will arrive on port 8000 and the telephone events will arrive on port 8002.
I don't know of any way to determine whether the other end will or will not transmit DTMF as audio. The right thing to do far as stripping DTMF from the audio will depend on its use by the participants of a session. And IMO can only be known in certain circumstances. Hence, it's not specified in the standards.
Best Regards, Bert
Troy Cauble wrote:
Thanks Ranjit,
The RFC also says
A source MAY send events and coded audio packets for the same time instants, using events as the redundant encoding for the audio stream, or it MAY block outgoing audio while event tones are active and only send named events as both the primary and redundant encodings.
But the RFC doesn't address SIP/SDP coding for either technique.
I'm guessing that one would use this form
m=audio 8000 RTP/AVP 0 97 a=rtpmap:0 PCMU/8000 a=rtpmap:97 telephone-event/8000
when blocking audio, and this form
m=audio 8000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=audio 8002 RTP/AVP 97 a=rtpmap:97 telephone-event/8000
when sending both events and audio (on different streams). I don't know how you would negotiate RFC2198 style packets with both types of content.
Can anyone confirm or correct these assumptions?
-troy
[EMAIL PROTECTED] wrote:
Hi The RFC says "The Internet Telephony gateway detects DTMF on incoming side and sends RTP packets instead of regular audio packets."
So the Gateway can negotiate as supporting telephone-event in SDP as:
m=audio 8000 RTP/AVP xyz a=rtpmap:xyz telephone-event/8000
where 'xyz' is the dynamic payload type, since 'telephone-event' does not have static payload type defined.
Regards Ranjit
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Troy Cauble Sent: Tuesday, June 15, 2004 4:33 AM To: [EMAIL PROTECTED] Subject: [Sip-implementors] RFC 2833 SIP/SDP negotiation questions
RFC 2833 states that telephone-event RTP packets can be sent instead-of *OR* in-addition-to voice.
Is it correct that negotiating telephone-event as one format in a media stream
m=audio 8000 RTP/AVP 0 97 a=rtpmap:0 PCMU/8000 a=rtpmap:97 telephone-event/8000
implies the former ("instead-of"), while multiple media streams
m=audio 8000 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=audio 8002 RTP/AVP 97 a=rtpmap:97 telephone-event/8000
implies the latter ("in-addition-to") ??
Which technique is usually used?
In the latter case, would you expect the 8002 stream to send anything when no telephone-events were happening (normal voice)?
Thanks, -troy
_______________________________________________ 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
