Subject: [MMUSIC] BUNDLE: RTCP port issue solution alternatives

From: Christer Holmberg <[email-masked]>
Date: Wed, 21 Oct 2015 11:18:46 +0000

Hi,

Based on the discussions so far, I have identified 3 alternative solutions for the RTCP port issue:

1)      Mandate RTCP-MUX whenever BUNDLE is used

Note: In order to maintain alignment with SDP, my suggestion would be to still mandate including of a=rtcp-mux in all RTP m- lines. I.e. the rtcp-mux usage would not be implicit.

2)      Select the RTCP port based on the RTCP properties (implicit or explicit) associated with the FIRST RTP m- line within the BUNDLE group, or the RTCP properties associated with the selected offerer BUNDLE address m- line if RTP.

3)      Allow usage of RTCP properties (a=rtcp, ICE RTCP components, etc) also in non-RTP m- lines.

Note: This MAY require updates of some RFCs.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 22 Oct 2015 11:02:11 +0000

Hi,

A clarification to alternative 1).

The suggestion is that clients must still support non-rtcp-mux, and are free to include a=rtcp etc if they want, for cases where the remote endpoint does not support (or does not want to use) BUNDLE and there is a fallback to non-BUNDLE.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21. lokakuuta 2015 14:19
To: [email-masked]
Subject: [MMUSIC] BUNDLE: RTCP port issue solution alternatives

Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 23 Oct 2015 09:56:16 +0000

https://www.youtube.com/watch?v=K8E_zMLCRNg

Assuming silence means "I don't care, do whatever", does that mean we could move forward with Alternative 1?

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 22. lokakuuta 2015 14:02
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] BUNDLE: RTCP port issue solution alternatives

Hi,

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21. lokakuuta 2015 14:19
To: [email-masked]<mailto:[email-masked]>
Subject: [MMUSIC] BUNDLE: RTCP port issue solution alternatives

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Oct 2015 13:07:18 -0400

On 10/23/15 5:56 AM, Christer Holmberg wrote:
> Assuming silence means “I don’t care, do whatever”, does that mean we
> could move forward with Alternative 1?

Given that everything else seems worse, I agree with alternative 1.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 22. lokakuuta 2015 14:02
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [MMUSIC] BUNDLE: RTCP port issue solution alternatives
>
> Hi,
>
> The suggestion is that clients must still support non-rtcp-mux, and are
> free to include a=rtcp etc if they want, for cases where the remote
> endpoint does not support (or does not want to use) BUNDLE and there is
> a fallback to non-BUNDLE.
>
> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 21. lokakuuta 2015 14:19
> *To:* [email-masked] <mailto:[email-masked]>
> *Subject:* [MMUSIC] BUNDLE: RTCP port issue solution alternatives
>
> Hi,
>
> 1)Mandate RTCP-MUX whenever BUNDLE is used
>
> Note: In order to maintain alignment with SDP, my suggestion would be to
> still mandate including of a=rtcp-mux in all RTP m- lines. I.e. the
> rtcp-mux usage would not be implicit.
>
> 2)Select the RTCP port based on the RTCP properties (implicit or
> explicit) associated with the FIRST RTP m- line within the BUNDLE group,
> or the RTCP properties associated with the selected offerer BUNDLE
> address m- line if RTP.
>
> 3)Allow usage of RTCP properties (a=rtcp, ICE RTCP components, etc) also
> in non-RTP m- lines.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>