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

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Feb 2015 11:05:31 +0000

Hi,

I had a chat with Magnus today, and I support his suggestion.

It would mean the following the modifications in BUNDLE:

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 addition, the offerer MAY associate an SDP
   ‘rtcp’ attribute [RFC3605] with each bundled RTP-based “m=” line
   (including any bundle-only "m=" line), with identical attribute values,
   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 indicate
   support of RTP/RTCP multiplexing in the offer.

   NOTE: In case the answerer does not accept usage of RTP/RTCP multiplexing, or
   if the offerer does not indicate support of RTP/RTCP multiplexing in the offer, if
   the offerer wants to use the next higher (odd) port number for receiving
   RTCP packets, the offerer does not need to include the SDP ‘rtcp’ attribute
   in the offer.

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

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 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'
   attribute with any bundled "m=" line in the answer. The answerer
   MAY associate an SDP ‘rtcp’ attribute with each bundled RTP-based
  “m=” line, with identical attribute values, in order to provide a port
   for receiving RTCP packets. The answerer
   will use the port number of the selected offerer BUNDLE address
   for sending RTP packets associated with each bundled RTP-based
   “m=” line towards the offerer. If the offerer associated an SDP ‘rtcp’
   attribute with each bundled RTP-based “m=” line in the offer, the
   answerer will use the attribute port value for sending RTCP packets
   associated with each bundled RTP-based “m=” line towards the
   offer. Otherwise the  answerer will, based on the port
   number of the offerer BUNDLE address,  use next higher (odd)
   port number for sending RTCP packets towards the offerer.

   NOTE: If the answerer does not accept usage of RTP/RTCP multiplexing, and
   If the answerer wants to use the next higher (odd) port number for receiving
   RTCP packets, it does not need to include the SDP ‘rtcp’ attribute in the
   answer.

   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.

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

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 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.   If the answerer associated an SDP ‘rtcp’
   attribute with each bundled RTP-based “m=” line in the answerer, 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,
   based on the port number of the answerer BUNDLE address,  use the next
   higher (odd) port number 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 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 an SDP 'rtcp-mux'
   attribute 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 an SDP 'rtcp-mux' and
   attribute with any bundled "m=" line in the subsequent offer.

   In addition, the offerer MAY associate an SDP
   ‘rtcp’ attribute with each bundled RTP-based “m=” line
   (including any bundled "m=" line that  the offerer wants to add to the
   BUNDLE group), with identical attribute values, 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 indicate support of RTP/RTCP multiplexing
   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. Similar, if usage of a separate RTCP port
   has been negotiated within a BUNDLE group, it is RECOMMENDED
   that the port value is not modified.

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

Regards,

Christer

From: mmusic [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Roman Shpount
Sent: 26 February 2015 17:42
To: Magnus Westerlund
Cc: mmusic (E-mail)
Subject: Re: [MMUSIC] Comments on draft-ietf-mmusic-sdp-bundle-negotiation-16 - a=rtcp-mux and a=rtcp issue

On Thu, Feb 26, 2015 at 9:02 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
My proposal for changes to the text causing these issue are the following:

In 10.3.2.2<http://10.3.2.2>:

1. Offerer: MAY include a=rtcp attribute as required or desired by other
specification to indicate the port where RTCP will be received if
a=rtcp-mux is rejected. In case a=rtcp is excluded the normal +1 rule
applies.

2. Offerer: the a=rtcp attribute shall have a port value different than
the m-line

In 10.3.2.3<http://10.3.2.3>:

3. Answerer: if the answerer rejects rtcp-mux, it is allowed in include
an a=rtcp attribute to indicate where it will receive RTCP, or fall back
on the +1 rule.

+1. I think this would make rtpc attribute usage much more logical.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Feb 2015 16:26:27 -0500

I'm seeing a major issue with use of a=rtcp here:

Consider how the offerer sets this up so that it will work for an 
answerer who doesn't support bundle. It assigns unique address/port 
pairs for each m-line (other than bundle only). But there is a 
requirement that a=rtcp use an *identical* port in each m-line. If 
bundle is rejected, then the RTCP for each m-line must go to a unique 
place. The only way to achieve that is for each line to have a distinct 
*address*, and that the *same* port be assigned to rtcp on each address. 
In many environments that is likely to be difficult/impossible to achieve.

This of course is less of an issue when the rtcp port defaults to the 
rtp port plus one.

	Thanks,
	Paul

On 2/27/15 6:05 AM, Christer Holmberg wrote:
> *From:*mmusic [mailto:[email-masked]]
> <mailto:[mailto:[email-masked]]> *On Behalf Of *Roman Shpount
> *Sent:* 26 February 2015 17:42
> *To:* Magnus Westerlund
> *Cc:* mmusic (E-mail)
> *Subject:* Re: [MMUSIC] Comments on
> draft-ietf-mmusic-sdp-bundle-negotiation-16 - a=rtcp-mux and a=rtcp issue
>
> On Thu, Feb 26, 2015 at 9:02 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     In 10.3.2.2 <http://10.3.2.2>:
>
>     In 10.3.2.3 <http://10.3.2.3>:
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 27 Feb 2015 21:56:19 +0000

Hi,

>Consider how the offerer sets this up so that it will work for an answerer who doesn't support bundle. It assigns unique >address/port pairs for each m-line (other than bundle only). But there is a requirement that a=rtcp use an *identical* port >in each m-line. If bundle is rejected, then the RTCP for each m-line must go to a unique place. The only way to achieve that >is for each line to have a distinct *address*, and that the *same* port be assigned to rtcp on each address. 
>This of course is less of an issue when the rtcp port defaults to the rtp port plus one.

Correct.

But, I think the suggested text is wrong: in the initial offer, if the rtcp attribute is used, it shall have a unique value. Then, if BUNDLE is accepted by the answerer, but rtcp-mux is NOT accepted, the rtcp attribute value associated with the BUNDLE address will apply - in the same way as the rtp port.

Then, in subsequent offers, the same rtcp attribute value can be used for each bundled m- line - in the same way as the rtp port.

Regards,

Christer

On 2/27/15 6:05 AM, Christer Holmberg wrote:
>     multiplexing, it MUST NOT associate an SDP 'rtcp-mux' attribute
>
>     RTCP packets, the offerer does not need to include the SDP 'rtcp'
> attribute
>
>     in the offer.
>
> ---------------------
>
> OLD:
>
>     MAY associate an SDP 'rtcp' attribute with each bundled RTP-based
>
>    "m=" line, with identical attribute values, in order to provide a 
> port
>
>     "m=" line towards the offerer. If the offerer associated an SDP 'rtcp'
>
>     attribute with each bundled RTP-based "m=" line in the offer, the
>
>     associated with each bundled RTP-based "m=" line towards the
>
>     RTCP packets, it does not need to include the SDP 'rtcp' attribute 
> in the
>
>     answer.
>
>     combinations for RTP and RTCP.   If the answerer associated an SDP
> 'rtcp'
>
>     attribute with each bundled RTP-based "m=" line in the answerer, 
> the offerer
>
>     RTP-based "m=" line towards the answerer. Otherwise the offerer 
> will,
>
>     'rtcp' attribute with each bundled RTP-based "m=" line
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Feb 2015 17:10:08 -0500

On 2/27/15 4:56 PM, Christer Holmberg wrote:
> But, I think the suggested text is wrong: in the initial offer, if the rtcp attribute is used, it shall have a unique value.

Almost. It is not the port that must be unique. Rather it is the 
address+port that must be unique (from any other address+port in all of 
the m-lines, for either rtp or rtcp). So you can use the same port with 
different addresses, or different ports for the same address.

> Then, if BUNDLE is accepted by the answerer, but rtcp-mux is NOT accepted, the rtcp attribute value associated with the BUNDLE address will apply - in the same way as the rtp port.

Yes, that will work.

> Then, in subsequent offers, the same rtcp attribute value can be used for each bundled m- line - in the same way as the rtp port.

Yes.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 28 Feb 2015 23:54:44 +0000

Hi,

>>> Consider how the offerer sets this up so that it will work for an answerer who doesn't 
>>> support bundle. It assigns unique address/port pairs for each m-line (other than bundle only). 
>>> But there is a requirement that a=rtcp use an *identical* port in each m-line. If bundle is 
>>> rejected, then the RTCP for each m-line must go to a unique place. The only way to achieve that 
>>> is for each line to have a distinct *address*, and that the *same* port be assigned to rtcp on each 
>>> address.
>>>
>>> This of course is less of an issue when the rtcp port defaults to the rtp port plus one.>
>>
>> Correct.
>>
> the m-lines, for either rtp or rtcp). So you can use the same port with different 
> addresses, or different ports for the same address.

Yes. I can add a generic statement saying that, similar to RTP, the address+port combination for RTCP must be unique in the initial offer, and shared once the bundle group has been accepted.

Also, if the offerer wants to add an rtcp attribute to a bundled m- line in the initial offer, I don't think we need to mandate it to add rtcp attributes to all other bundled m- lines. It may of course do so.

My understanding is also that an answer can contain rtcp attributes even if the offer doesn't. At least I couldn't find any text in RFC 3605 preventing it.

Regards,

Christer

>>      RTCP packets, it does not need to include the SDP 'rtcp' 
>> attribute in the
>>
>>      answer.
>>