Ericsson

Hirsalantie 11 Jorvas 02420 Finland christer.holmberg@ericsson.com

RAI This document updates RFC 5761 by clarifying the SDP offer/answer negotiation of RTP and RTCP multiplexing. It makes it clear that an answerer can only include an "a=rtcp-mux" attribute in an SDP answer if the associated SDP offer contained the attribute.

RFC 5761 specifies how to multiplex RTP data packets and RTP Control Protocol (RTCP) packets on a single UDP port, and how to negotiate usage of such multiplexing using the SDP offer/answer mechanism , using an "a=rtcp-mux" attribute. However, the text is unclear on whether an answerer is allowed to include the attribute in an answer even if the associated offer did not contain an attribute. This document updates RFC 5761 by clarifying that an answerer can only include an "a=rtcp-mux" attribute in an answer if the associated offer contained the attribute. It also clarifies that the negotiation of RTP and RTCP multiplexing is for usage in both directions.

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 .

This section updates section 5.1.1 of RFC 5761.

The security considerations for RTP and RTCP multiplexing are described in RFC 5761. This specification does not impact those security considerations.

This specifcation makes no requests from IANA.

TBD

[RFC EDITOR NOTE: Please remove this section when publishing] Changes from foo Add text