Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16 - a=rtcp-mux and a=rtcp issue - TEXT SUGGESTION: Episode II

From: Christer Holmberg <[email-masked]>
Date: Sun, 1 Mar 2015 19:28:28 +0000

Hi,

Modified text suggestion:

OLD:

10.3.2.2.  Generating the Initial SDP Offer

   When an offerer generates an initial offer, if the offerer wants to
   negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, 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.  In addition, the offerer MUST associate an SDP
   'rtcp' attribute [RFC3605] with each bundled RTP-based "m=" line
   (including any bundle-only "m=" line), with an attribute value that
   is identical to the port value assigned to the "m=" line itself, in
   the offer.

   If the offerer does not want to negotiate usage of RTP/RTCP
   multiplexing, it MUST NOT associate the SDP attributes above with any
   bundled "m=" line.

NEW:

10.3.2.2.  Generating the Initial SDP Offer

   When an offerer generates an initial offer, if the offerer wants to
   negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, 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.

   If the offerer does not want to negotiate usage of RTP/RTCP
   multiplexing, it MUST NOT associate an SDP 'rtcp-mux' attribute
   with any bundled "m=" line in the offer.

   In addition, the offerer can associate an SDP
   'rtcp' attribute [RFC3605] with one or more bundled RTP-based "m=" lines
   (including any bundle-only "m=" line) in the offer, in order to provide a port for receiving
   RTCP packets (if the answerer does not accept usage of RTP/RTCP multiplexing, or
   if the offerer does not want to negotiate usage of RTP/RTCP multiplexing).

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

   NOTE: In case the offer wants to receive RTCP packets on the next
   higher (odd) port number, the SDP 'rtcp' attribute is not needed.

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

OLD:

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 either accept or reject the
   usage of RTP/RTCP multiplexing in the answer.

   If the answerer accepts 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 number of the selected
   offerer BUNDLE address for sending RTP and RTCP packets associated
  with each bundled RTP-based "m=" line towards the offerer.

   If the answerer rejects usage of RTP/RTCP multiplexing within the
   BUNDLE group, it MUST NOT associate an SDP 'rtcp-mux' or SDP 'rtcp'
   attribute with any bundled "m=" line in the answer.  The answerer
   MUST, based on the port number of the selected offerer BUNDLE
   address, use the next higher (odd) destination port number [RFC3550]
   for sending RTCP packets associated with each bundled RTP-based "m="
   line towards the offerer.

   NOTE: When the answerer rejects usage of RTP/RTCP multiplexing, the
   reason for mandating usage of the next higher (odd) destination port
   number for RTCP is to allign the procedures for the corresponding
   offer.

   If the usage of RTP/RTCP multiplexing has been negotiated in a
   previous offer/answer transaction, and the offerer indicates that it
   wants to continue using RTP/RTCP multiplexing in a subsequent offer,
   the answerer MUST associate an SDP 'rtcp-mux' attribute with each
   bundled "m=" line in the answer.  I.e. the answerer MUST NOT disable
   the usage of RTP/RTCP multiplexing.

NEW:

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 either accept or reject the
   usage of RTP/RTCP multiplexing for the whole BUNDLE group in the answer.

   If 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 answerer does not accept the usage of RTP/RTCP multiplexing within the
   BUNDLE group, it MUST NOT associate an SDP 'rtcp-mux'
   attribute with any bundled "m=" line in the answer.
   The answerer will use the RTP and RTCP port values associated with the
   selected offerer BUNDLE address for sending RTP and RTCP packets
   associated with each RTP-based bundled "m=" line towards the offerer.

   In addition, if the answerer rejects the usage of RTP/RTCP multiplexing within
   the BUNDLE group, it MAY associate an SDP 'rtcp' attribute, with identical
   attribute values, with each RTP-based bundled "m=" line in the answer, in
   order to provide a port value for receiving RTCP packets from the offerer.

   NOTE: In case the answerer wants to receive RTCP packets on the next
   higher (odd) port number, the SDP 'rtcp' attribute is not needed.

   If the usage of RTP/RTCP multiplexing within a BUNDLE group has been
   negotiated in a previous offer/answer transaction, and if the offerer indicates
   that it wants to continue using RTP/RTCP multiplexing in a subsequent offer,
   the answerer MUST associate an SDP 'rtcp-mux' attribute with each
   bundled "m=" line in the answer.  I.e. the answerer MUST NOT disable
   the usage of RTP/RTCP multiplexing.

   If the usage of RTP/RTCP multiplexing within a BUNDLE group has not been negotiated
   in a previous offer/answer transaction, and if the offerer indicates that it
   wants to use RTP/RTCP multiplexing in a subsequent offer, the answerer either
   accepts or rejects the usage, using the procedures above.

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

OLD:

10.3.2.4.  Offerer Processing of the SDP Answer

   When the offerer receives an answer, if the answerer accepts the
   usage of RTP/RTCP multiplexing, by including an SDP 'rtcp-mux'
   attribute to each bundled "m=" line in the answer [Section 10.3.2.3],
   the answerer follows the procedures for RTP/RTCP multiplexing defined
   in [RFC5761].  The offerer will use the port number of the answerer
   BUNDLE address for sending RTP and RTCP packets associated with each
   bundled "m=" line towards the answerer.

   If the answerer does not accept the usage of RTP/RTCP multiplexing
   [Section 10.3.2.3], the offerer MUST use separate address:port
   combinations for RTP and RTCP.  The offerer will, based on the port
   number of the answerer BUNDLE address, use the next higher (odd)
   destination port number [RFC3550] for sending RTCP packets associated
   with a bundled "m=" line towards the answerer.

NEW:

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.

   If the answerer did not accept the usage of RTP/RTCP multiplexing
   [Section 10.3.2.3], the offerer will use separate address + port
   combinations for sending RTP and RTCP packets towards the answerer.
   If the answerer associated an SDP 'rtcp' attribute with the "m=" line
   representing the answerer BUNDLE address,  the offerer will use the
   attribute port value for sending RTCP packets associated with each
   bundled RTP-based "m=" line towards the answerer. Otherwise the
   offerer will use the next higher (odd) port number associated with the
   answerer BUNDLE address for sending RTCP packets towards the answerer.

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

OLD:

10.3.2.5.  Modifying the Session

   When an offerer generates a subsequent offer, if it wants to
   negotiate usage of RTP/RTCP multiplexing within a BUNDLE group, or if
   it wants to continue usage of RTP/RTCP multiplexing (negotiated in a
   previous offer/answer transaction), it MUST associate SDP 'rtcp-mux'
   and 'rtcp' attributes with each 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.

   If the offerer does not want to negotiate usage of RTP/RTCP
   multiplexing within the BUNDLE group, or if it wants to disable usage
   of RTP/RTCP multiplexing (negotiated in a previous offer/answer
   transaction), the offerer MUST NOT associate SDP 'rtcp-mux' and
   'rtcp' attributes with any bundled "m=" line in the subsequent offer.

   NOTE: It is RECOMMENDED that, once usage of RTP/RTCP multiplexing has
   been negotiated within a BUNDLE group, that the usage is not
   disabled.  Disabling RTP/RTCP multiplexing means that the offerer and
   answerer need to reserve new ports, to be used for sending and
   receiving RTCP packets.

NEW:

10.3.2.5.  Modifying the Session

   When an offerer generates a subsequent offer, if it wants to
   negotiate the usage of RTP/RTCP multiplexing within a BUNDLE group, or if
   it wants to continue the use of previously negotiated RTP/RTCP multiplexing,
   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.

   If the offerer does not want to negotiate the usage of RTP/RTCP
   multiplexing within the BUNDLE group, or if it wants to disable previously
   negotiated usage of RTP/RTCP multiplexing, it MUST NOT associate an
   SDP 'rtcp-mux' and attribute with any bundled "m=" line in the subsequent offer.

   In addition, if the offerer does not indicate support of RTP/RTCP multiplexing
   within the subsequent offer, it MAY associate an SDP 'rtcp' attribute, with
   identical attribute values, with each RTP-based bundled "m=" line (including any
   bundled "m=" line that  the offerer wants to add to the BUNDLE group), in order
   to provide a port for receiving RTCP packets.

   NOTE: It is RECOMMENDED that, once the usage of RTP/RTCP multiplexing has
   been negotiated within a BUNDLE group, that the usage is not
   disabled.  Disabling RTP/RTCP multiplexing means that the offerer and
   answerer need to reserve new ports, to be used for sending and
   receiving RTCP packets. Similar, if the usage of a specific RTCP port
   has been negotiated within a BUNDLE group, it is RECOMMENDED
   that the port value is not modified.

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

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 01 Mar 2015 17:18:48 -0500

This works for me.

On 3/1/15 2:28 PM, Christer Holmberg wrote:
>     multiplexing, it MUST NOT associate an SDP ‘rtcp-mux’ attribute
>     ‘rtcp’ attribute [RFC3605] with one or more bundled RTP-based “m=” lines
>     MUST be unique in each bundled RTP-based “m=” line, similar to RTP.
>     higher (odd) port number, the SDP ‘rtcp’ attribute is not needed.
> ---------------------
> OLD:
> within the
>     associated with each RTP-based bundled “m=” line towards the offerer.
>     the BUNDLE group, it MAY associate an SDP ‘rtcp’ attribute, with
> identical
>     attribute values, with each RTP-based bundled “m=” line in the
> answer, in
>     higher (odd) port number, the SDP ‘rtcp’ attribute is not needed.
>     If the answerer associated an SDP ‘rtcp’ attribute with the “m=” line
>     bundled RTP-based “m=” line towards the answerer. Otherwise the
>     within the subsequent offer, it MAY associate an SDP ‘rtcp’
> attribute, with
>     identical attribute values, with each RTP-based bundled “m=” line
> (including any

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 2 Mar 2015 13:55:58 +0100

Hi,

I also think this works fine and appear to encode my preferred solution.

However, there is one minor detail.

>    higher (odd) port number, the SDP ‘rtcp’ attribute is not needed.

I note that Section 5.1 in RFC 3264 says:

Unless there is an explicit indication otherwise, reports are sent to
   the port number one higher than the number indicated.

This is not equivalent to the higher (odd) port number rule written here
and which originates from RFC 3550 (Section 11).

They will produce the equivalent result as long as the RTP port is even,
but if would be an odd number the result is different.

I don't know how to deal with this inconsistency. Which rule shall
prevail in this case?

Cheers

Magnus

On 2015-03-01 20:28, Christer Holmberg wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Roman Shpount <[email-masked]>
Date: Mon, 2 Mar 2015 08:42:53 -0500

>    the port number one higher than the number indicated.
I think we should go with the rule from RFC 3264. There is nothing that
enforces RTP ports to be even and RTCP ports to be odd.
_____________
Roman Shpount

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 2 Mar 2015 14:50:52 +0100

On 2015-03-02 14:42, Roman Shpount wrote:
> On Mon, Mar 2, 2015 at 7:55 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 

Well, I wouldn't say enforces, but RFC 3550 has a SHOULD writing:

   For UDP and similar protocols,
   RTP SHOULD use an even destination port number and the corresponding
   RTCP stream SHOULD use the next higher (odd) destination port number.

But, I would support that the O/A rule that has been in place for many
year is the one to continue to use.

Cheers

Magnus Westerlund

---

From: Roman Shpount <[email-masked]>
Date: Mon, 2 Mar 2015 09:00:36 -0500

> year is the one to continue to use.
If we are striving for complete backwards compatibility, we should state
that rtp ports SHOULD be even. This being said, RTCP ports, if not
specified by rtcp attribute MUST use the next port after RTP. It is not the
next odd port which will create interop problems in cases where the rtp
port is not even in violation of the SHOULD.
_____________
Roman Shpount

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 2 Mar 2015 14:01:04 +0000

What about omitting the “(odd)” in the proposed text?

It would be inline with 3264 and wouldn't be in conflict with 3550 either

Regards
Thomas

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Montag, 2. März 2015 14:51
To: Roman Shpount
Cc: [email-masked]; Paul Kyzivat; Christer Holmberg
Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16 - a=rtcp-mux and a=rtcp issue - TEXT SUGGESTION: Episode II

Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Mar 2015 09:40:52 +0000

Hi,

I support omitting the "(odd)".

It is not the task of BUNDLE to give guidance on how to select RTP port numbers. 

Regards,

Christer

-----Original Message-----
From: Stach, Thomas [mailto:[email-masked]] 
Sent: 2. maaliskuuta 2015 16:01
To: Magnus Westerlund; Roman Shpount
Cc: [email-masked]; Paul Kyzivat; Christer Holmberg
Subject: RE: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16 - a=rtcp-mux and a=rtcp issue - TEXT SUGGESTION: Episode II

Regards
Thomas

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Magnus Westerlund
Sent: Montag, 2. März 2015 14:51
To: Roman Shpount
Cc: [email-masked]; Paul Kyzivat; Christer Holmberg
Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16 - a=rtcp-mux and a=rtcp issue - TEXT SUGGESTION: Episode II

On 2015-03-02 14:42, Roman Shpount wrote:
> I think we should go with the rule from RFC 3264. There is nothing 
> that enforces RTP ports to be even and RTCP ports to be odd.

But, I would support that the O/A rule that has been in place for many year is the one to continue to use.

Cheers

Magnus Westerlund