Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP
Ericsson
Hirsalantie 11
Jorvas
02420
Finland
christer.holmberg@ericsson.com
Transport
RTP
RTCP
SDP
OFFER
ANSWER
MUX
MULTIPLEX
RTCWEB
WEBRTC
JSEP
This document defines how an endpoint can indicate exclusive support of
RTP/RTCP multiplexing using the Session Description Protocol (SDP).
The document updates RFC 5761, by defining how the SDP 'rtcp' attribute
is used, together with the SDP 'rtcp-mux' attribute, to indicate exclusive
support of RTP/RTCP multiplexing.
Editor's note: 'exclusive' is probably not the best terminology, so feel
free to suggest something more appropriate.
defines how to
multiplex RTP and RTCP on a single port, referred to as RTP/RTCP multiplexing.
also defines an
Session Description Protocol (SDP) attribute, 'rtcp-mux' that can be used by entities
to indicate support of RTP/RTCP multiplexing.
specifies that, if
the peer endpoint does not support RTP/RTCP multiplexing, there must be a
fallback to usage of different ports for RTP and RTCP. However, the RTCWEB
WG have defined that the support of using different ports is optional.
Therefor, there needs to be a mechanism for an endpoint to indicate exclusive
support of RTP/RTCP multiplexing, i.e. indicate that the endpoint only
supports RTP/RTCP multiplexing.
The document updates section 5.1.1 of , by defining how the SDP 'rtcp' attribute
is used, together with the SDP 'rtcp-mux' attribute, to indicate exclusive
support of RTP/RTCP multiplexing.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in .
When an offerer sends an offer, if the offerer supports
RTP/RTCP multiplexing, the offerer must associate an
SDP 'rtcp-mux' attribute
This section updates section 5.1.1 of , by replacing the text in
the first paragraph with the new text defined in this section.
ISSUE #1: We may want to specify an explicit procedure for the
answerer too, saying that it must select mux if it receives
rtcp-mux and rtcp with the RTP port value.
ISSUE #2: We may want to specify something about the case when
the answerer only supports mux, and receives an offer without mux.
This document does not introduce new security considerations
in additions to those specified in and .
This document makes no requests from IANA.
[RFC EDITOR NOTE: Please remove this section when publishing]