Subject: [MMUSIC] BUNDLE: Modified text based on decision to mandate RTP/RTCP mux for bundled RTP-based media

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Nov 2015 08:03:30 +0000

Hi,

Based on the decision to mandate RTP/RTCP mux for BUNDLE, I've modified the associated section in BUNDLE. See below.

(We may need some more text, based on where we go with the mux-only issue)

For the Github fans, the text can also be found at:

https://github.com/cdh4u/draft-sdp-bundle

(Note that it is a private repo)

Regards,

Christer

-------------------------

10.3.  RTP/RTCP Multiplexing

10.3.1.  General

   Within a BUNDLE group, the offerer and answerer MUST enable RTP/RTCP
   multiplexing [RFC5761] for the RTP-based media associated with the
   BUNDLE group.

   When RTP/RTCP multiplexing is enabled, the same address:port
   combination will be used for sending all RTP packets and the RTCP
   packets associated with the BUNDLE group.  Each endpoint will send
   the packets towards the BUNDLE address of the other endpoint.  The
   same address:port combination MAY be used for receiving RTP packets
   and RTCP packets.

10.3.2.  SDP Offer/Answer Procedures

10.3.2.1.  General

   This section describes how an offerer and answerer use the SDP 'rtcp-
   mux' attribute [RFC5761] to negotiate usage of RTP/RTCP multiplexing
   for RTP-based media associated with a BUNDLE group.

   The procedures in this section only apply to RTP-based "m=" lines.

10.3.2.2.  Generating the Initial SDP Offer

   When an offerer generates an initial offer, the offerer MUST
   associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled
   RTP-based "m=" line (including any bundle-only "m=" line) in the
   offer.

   NOTE: The offerer might also associate an SDP 'rtcp' attribute
   [RFC3605] with a bundled "m=" line, excluding a bundle-only "m="
   line, in order to provide a fallback port for RTCP.  However, the
   fallback port will only be used in case the answerer does not include
   the "m=" line in the BUNDLE group in the associated answer.

   In the initial offer, the IP address and port combination for RTCP
   MUST be unique in each bundled RTP-based "m=" line (excluding a
   'bundle-only' "m=" line), similar to RTP.

10.3.2.3.  Generating the SDP Answer

   When an answerer generates an answer, if the offerer indicated
   support of RTP/RTCP multiplexing [RFC5761] within a BUNDLE group in
   the associated offer, the answerer MUST accept usage of RTP/RTCP
   multiplexing within the BUNDLE group.  If an SDP "rtcp-mux" attribute
   was not associated with a bundled "m=" line in the associated offer,
   the answerer MUST NOT included that "m=" line in the BUNDLE group.

   When the answerer accepts the usage of RTP/RTCP multiplexing within
   the BUNDLE group, it MUST associate an SDP 'rtcp-mux' attribute with
   each bundled RTP-based "m=" line in the answer.  The answerer MUST
   NOT associate an SDP 'rtcp' attribute with any bundled "m=" line in
   the answer.  The answerer will use the port value of the selected
   offerer BUNDLE address for sending RTP and RTCP packets associated
   with each RTP-based bundled "m=" line towards the offerer.

   If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
   negotiated in a previous offer/answer transaction, the answerer MUST
   associate an SDP 'rtcp-mux' attribute with each bundled RTP-based
   "m=" line in the answer.

10.3.2.4.  Offerer Processing of the SDP Answer

   When an offerer receives an answer, if the answerer has accepted the
   usage of RTP/RTCP multiplexing (see Section 10.3.2.3), the answerer
   follows the procedures for RTP/RTCP multiplexing defined in
   [RFC5761].  The offerer will use the port value associated with the
   answerer BUNDLE address for sending RTP and RTCP packets associated
   with each RTP-based bundled "m=" line towards the answerer.

   NOTE: If is considered a protocol error if the answerer has not
   accpeted the usage of RTP/RTCP multiplexing for RTP-based "m=" lines
   that the answerer included in the BUNDLE group.

10.3.2.5.  Modifying the Session

   When an offerer generatees a subsequent offer, it MUST associate an
   SDP 'rtcp-mux' attribute with each RTP-based bundled "m=" line
   (including any bundled "m=" line that the offerer wants to add to the
   BUNDLE group), unless the offerer wants to disable or remove the "m="
   line from the BUNDLE group.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 6 Nov 2015 09:39:54 -0500

Christer,

This works for me. It solves the problem *for bundle* while sidestepping 
the problem for unbundled m-lines.

Of course, an offerer who is trying to establish a new bundle group, and 
who does not control port+1 still has a problem of how to safely 
construct the offer. This is just the problem with a=rtcp, and has 
nothing to do with bundle. Such an offerer will cope with this however 
it can. (E.g., hope for the best.)

	Thanks,
	Paul

On 11/6/15 3:03 AM, Christer Holmberg wrote:
> Hi,
>
> Based on the decision to mandate RTP/RTCP mux for BUNDLE, I’ve modified
> the associated section in BUNDLE. See below.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>