Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

From: Justin Uberti <[email-masked]>
Date: Wed, 1 May 2013 15:29:01 -0700

+1 to mandating rtcp-mux when BUNDLEing.

Otherwise, we have weird situations, such as if you try to BUNDLE a SCTP
session and a non-RTCP-mux RTP session together; the former has 1 ICE
component, the latter has 2.

On Tue, Apr 30, 2013 at 12:30 PM, Paul Kyzivat <[email-masked]>wrote:

> On 4/30/13 3:00 PM, Martin Thomson wrote:
>
>> On 30 April 2013 10:12, Paul Kyzivat <[email-masked]> wrote:
>>
>>> What are the implications of *not* mandating it?
>>>
>>
>> I'm more interesting in learning why someone might want to split it
>> out.  I can't see any reason for doing that...
>>
>> ...that is, except perhaps for some of the fictitious attacks I invent
>> when someone suggests that RTCP is a good place for a security
>> mechanism of one sort or other.
>>
>
> Well, IIUC it was separate before there was a way to combine them.
> Why was that? Why hasn't separate RTCP gone away entirely?
>
>         Thanks,
>         Paul
>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 May 2013 10:00:54 +0000

Hi,

Things would certainly work with separate RTCP ports. But, it would mean an additional 5-tuple, with associated ICE etc, which is what we want to avoid by using BUNDLE.

And, as BUNDLE already mandates the SDP offerer to offer rtcp-mux, my suggestion is to mandate the SDP answerer to accept it (assuming it enables BUNDLE, that is).

However, if people have issues with a MUST, a compromise would be “SHOULD, unless some mechanism explicitly requires the usage of separate RTCP ports”… or something like that.

Regards,

Christer

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 2. toukokuuta 2013 1:29
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

Otherwise, we have weird situations, such as if you try to BUNDLE a SCTP session and a non-RTCP-mux RTP session together; the former has 1 ICE component, the latter has 2.

On Tue, Apr 30, 2013 at 12:30 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
On 4/30/13 3:00 PM, Martin Thomson wrote:
On 30 April 2013 10:12, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
What are the implications of *not* mandating it?

        Thanks,
        Paul

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Thu, 2 May 2013 12:55:27 +0000

+1 for MUST in offer and answer.

On May 2, 2013, at 6:01 AM, "Christer Holmberg" <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: 2. toukokuuta 2013 1:29
To: Paul Kyzivat
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

        Thanks,
        Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 2 May 2013 13:02:23 +0000

Hi,

In fact, I noticed that, in the second offer, BUNDLE already mandates it in both the offer and answer :)

So, the only addition would be to mandate it also in the first answer.

Regards,

Christer

From: Mo Zanaty (mzanaty) [mailto:[email-masked]]
Sent: 2. toukokuuta 2013 15:55
To: Christer Holmberg
Cc: Justin Uberti; Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

However, if people have issues with a MUST, a compromise would be "SHOULD, unless some mechanism explicitly requires the usage of separate RTCP ports"... or something like that.

Regards,

Christer

        Thanks,
        Paul

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 2 May 2013 21:15:44 -0400 (EDT)

> From: Christer Holmberg <[email-masked]>
> 
> In fact, I noticed that, in the second offer, BUNDLE already
> mandates it in both the offer and answer :)
> 

I can see why it would be useful to mandate rtcp-mux in the bundled
offer/answer, because it is more port-efficient, and the code that
handles the multiplexing and demultiplexing the constituent streams
only has to handle the case where the RTCP is multiplexed with the
RTP.

But it doesn't seem that there is much to gain by mandating rtcp-mux
in the first offer/answer, the one where actual bundling is not being
done.  All of the RTP/RTCP routing code that is active at that point
has to support non-rtcp-mux operation already.

Dale

---

From: Justin Uberti <[email-masked]>
Date: Thu, 2 May 2013 18:56:54 -0700

Bundling is done during the first offer/answer. Any subsequent ones are
just for the benefit of middleboxes.

Mandating rtcp-mux for BUNDLE, even in the first offer/answer, avoids a
couple ugly edge cases.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 2 May 2013 22:13:20 -0700

> has to support non-rtcp-mux operation already.
[BA]  Support for rtcp-mux in the first offer/answer is mandated by RFC 5761 Section 5.1.3:
   The initial SDP offer MUST include this
   attribute at the media level to request multiplexing of RTP and RTCP
   on a single port. 
[RFC5761]  Section 5.1.3 also requires a fallback port for RTCP in the offer, in case the answerer doesn't support RTCP-mux:  
   If it is desired to use both ICE and multiplexed RTP and RTCP, the
   initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
   RTP and RTCP multiplexing is desired and MUST contain "a=candidate:"
   lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
   fallback port for RTCP in the case that the answerer does not support
   RTP and RTCP multiplexing.  This MUST be done for each media where
   RTP and RTCP multiplexing is desired.
Given the existing normative text,  and all the other problems we need to solve, I think the burden of proof is on those who advocate deviation from RFC 5761.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 May 2013 06:22:21 +0000

Hi Bernard,

I am not suggesting a deviation from RFC 5761.

As the text says, the initial offer must contain candidates also for RTCP, as it is still now known whether the answerer will support rtcp-mux.

My suggestion is to mandate BUNDLE entities to support rtcp-mux.

Regards,

Christer

From: Bernard Aboba [mailto:[email-masked]]
Sent: 3. toukokuuta 2013 8:13
To: Dale R. Worley; Christer Holmberg
Cc: [email-masked]
Subject: RE: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?

   on a single port.

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 6 May 2013 14:00:45 -0400 (EDT)

> From: Bernard Aboba <[email-masked]>
> 

I don't see how 5761 mandates that a=rtcp-mux MUST be used in the
first offer of a bundle negotiation.  The context of your quote is:

   5.1.3.  Interactions with ICE
   [...]

That is, if the device desires to use both ICE and multiplex, it has
to use a=rtcp-mux in the first offer of ICE's set of offers.  But
we're talking about bundling, which (in the current design) contains
*two* ICE cycles, since the second offer (in the bundle spec) is going
to restart ICE.  And the device need not "desire" to use "both ICE and
multiplexed RTP and RTCP" during the first of the ICE cycles.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 09:53:38 +0000

Hi,

>>> in the first offer/answer, the one where actual bundling is not 
>>> being done.  All of the RTP/RTCP routing code that is active at that 
>>> point has to support non-rtcp-mux operation already.
>>
> I don't see how 5761 mandates that a=rtcp-mux MUST be used in the first offer of a bundle negotiation.  The context of your quote is:
>
>   RTP and RTCP multiplexing is desired.<
>
> That is, if the device desires to use both ICE and multiplex, it has to use a=rtcp-mux in the first offer of ICE's set of offers.  But we're talking about bundling, which (in the current design) contains
> *two* ICE cycles, since the second offer (in the bundle spec) is going to restart ICE.  And the device need not "desire" to use "both ICE and multiplexed RTP and RTCP" during the first of the ICE cycles.

As indicated, BUNDLE actually already DOES mandate a=rtcp-mux in the first offer, but it is optional for the answer, to the suggestion is to mandate it in the first answer.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 07 May 2013 14:36:36 -0400

I'd just like to point out that AFAIK bundling doesn't *require* ICE.
So lets not make any assumptions that assume ICE is used.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 May 2013 19:23:21 +0000

Hi,

>So lets not make any assumptions that assume ICE is used.

Agree.

We do need to describe how ICE is used with BUNDLE, but BUNDLE can also be used without ICE.

Regards,

Christer

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 8 May 2013 12:24:13 +0000

Whilst I agree that BUNDLE should not assume ICE is used as Christer stated we do need to show how it is used with ICE.

The interaction between ICE and Bundle is a potential problem and looks quite messy to me given the multitude of transport addresses that might be contained in the various candidates relating to the different candidate type, components, and rel-addr/port. The meaning/relevance of all these addresses when bundle is used needs to be explained.

My initial feeling was that we should include something in the candidate itself to make it clear what transport address is relevant if bundle is used but so far I have not had much feedback and I am not sure whether it makes things worse or better.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: 07 May 2013 20:23
> To: Paul Kyzivat; [email-masked]

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 9 May 2013 14:33:52 +0000

+1 

On Apr 30, 2013, at 8:21 AM, Bernard Aboba <[email-masked]> wrote:

> No objection here to requiring rtcp-mux with BUNDLE.   Implementations not supporting rtcp-mux probably don't support BUNDLE either.  
> 
> From: [email-masked]
> To: [email-masked]
> Date: Tue, 30 Apr 2013 13:26:35 +0000
> Subject: [MMUSIC] BUNDLE: mandate RTP/RTCP multiplexing?
> 
> Hi,
>  
> As currently indicated in BUNDLE, and SDP offer for RTP must contain an rtcp-mux attribute, indicating support of RTP/RTCP multiplexing.
>  
> However, it is currently optional to include it in the SDP answer.
>  
> There has been some discussions on whether we should MANDATE the usage of rtcp-mux whenever BUNDLE is enabled.
>  
> Would anyone OBJECT to that?
>  
> Regards,
>  
> Christer
> 
> _______________________________________________ mmusic mailing list [email-masked]://www.ietf.org/mailman/listinfo/mmusic

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 22 May 2013 19:46:08 -0700

+1

I would also like to think if we need to mandate a=rtcp:<port> with BUNDLE.
 Since RFC5761 requires offerer to specify a separate RTCP port to enable
fallback if the Answerer doesn't support RTCPMux.

Any thoughts ?

Cheers
Suhas Nandakumar

On Tue, Apr 30, 2013 at 6:26 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,****
>
> ** **
>
> As currently indicated in BUNDLE, and SDP offer for RTP must contain an
> rtcp-mux attribute, indicating support of RTP/RTCP multiplexing.****
>
> ** **
>
> However, it is currently optional to include it in the SDP answer.****
>
> ** **
>
> There has been some discussions on whether we should MANDATE the usage of
> rtcp-mux whenever BUNDLE is enabled.****
>
> ** **
>
> Would anyone OBJECT to that?****
>
> ** **
>
> Regards,****
>
> ** **
>
> Christer****
>