Subject: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

From: Peter Thatcher <[email-masked]>
Date: Thu, 30 Jul 2015 12:17:28 -0700

At IETF 93 last week,  Cullen pointed out that he looked into ICE endpoints
and found that all of them support rtcp-mux.  Inspired by that, I went
around and asked about a dozen people "would you be OK if we removed
support for non-muxed RTCP?"  The range of responses went from "I'm OK with
it if Cullen is" to "yeah, that would be great".  No one said no.  Cullen
said yes.

For me, removing support for non-muxed RTCP would be like Christmas in
July.  The amount of gross code in our implementation just to support this
case is very large, especially considering the very small benefit it gives
us.  Talking to the developers at Mozilla, it sounds like they have a
similar cost in code complexity.  I'm guessing every ICE stack does.  We
could clean up a lot of code complexity in a lot of code bases by requiring
rtcp-mux.

So here's my proposal:  make RtcpMuxPolicy == "required" be not only the
default, but the only RtcpMuxPolicy available.   All rtcweb endpoints must
support rtcp-mux.   An rtcweb endpoint would be free to fail if the remote
endpoint does not support rtcp-mux.

The whole reason we didn't do this before was because we wanted to work
with legacy equipment.  But Cullen's claim is that there is no legacy
equipment that can speak ICE (and DTLS) but not rtcp-mux.

So is there any remaining reason that we cannot require rtcp-mux?

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Jul 2015 12:28:04 -0700

Peter said:

"So is there any remaining reason that we cannot require rtcp-mux?"

[BA] To be clear, you are talking about making RTP/RTCP
multiplexing mandatory-to-use?

The RTP-Usage document already mandates support for RFC 5761.  From Section
4.5:

   implementations are REQUIRED to support multiplexing RTP data packets
   and RTCP control packets on a single transport-layer flow [RFC5761
<https://tools.ietf.org/html/rfc5761>].

On Thu, Jul 30, 2015 at 12:17 PM, Peter Thatcher <[email-masked]>
wrote:

> At IETF 93 last week,  Cullen pointed out that he looked into ICE
> endpoints and found that all of them support rtcp-mux.  Inspired by that, I
> went around and asked about a dozen people "would you be OK if we removed
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 Jul 2015 15:29:45 -0400

Please, please, please make rtcp-mux mandatory to use! For me this would be
Christmas, Hanukkah and Kwanzaa rolled into one.

_____________
Roman Shpount

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 30 Jul 2015 12:35:17 -0700

I didn't quite mean mandatory-to-use.  If an rtcweb endpoint wants to use
non-muxed RTCP, it could go ahead and do that, so it's not quite
mandatory-to-use-rtcp-mux, but instead free-to-not-support-non-muxed-rtcp.

Perhaps my proposal should instead be:  rtcweb endpoints MAY make RtcpMuxPolicy
== "required" the default and MAY remove support for RtcpMuxPolicy ==
"negotiate".

That would leave the door open to endpoints that want to support non-muxed
RTCP, which mandatory-to-use would not.  But it would also leave the door
open to endpoints not having to support non-muxed RTCP.

On Thu, Jul 30, 2015 at 12:28 PM, Bernard Aboba <[email-masked]>
wrote:

> The RTP-Usage document already mandates support for RFC 5761.  From
> Section 4.5:
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 30 Jul 2015 15:38:01 -0400

Le 2015-07-30 15:29, Roman Shpount a écrit :
> Please, please, please make rtcp-mux mandatory to use! For me this would
> be Christmas, Hanukkah and Kwanzaa rolled into one.

+1

I prefer mandatory-to-use to free-to-not-support-non-muxed-rtcp.

Simon

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 30 Jul 2015 12:38:30 -0700

I guess I should have said "Winter Break in July".

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 30 Jul 2015 12:45:55 -0700

"free-to-not-support-non-muxed-rtcp."

[BA] OK.   This would involve changing "are also REQUIRED to" to "MAY" in
the following sentence within RTP-Usage Section 4.5:

   For backwards compatibility, implementations are also REQUIRED to support
   RTP and RTCP sent on separate transport-layer flows.

---

From: Randell Jesup <[email-masked]>
Date: Thu, 30 Jul 2015 15:56:09 -0400

On 7/30/2015 3:17 PM, Peter Thatcher wrote:
> So here's my proposal:  make RtcpMuxPolicy == "required" be not only 
> the default, but the only RtcpMuxPolicy available.   All rtcweb 
> endpoints must support rtcp-mux.   An rtcweb endpoint would be free to 
> fail if the remote endpoint does not support rtcp-mux.
>
>
>
> The whole reason we didn't do this before was because we wanted to 
> work with legacy equipment.  But Cullen's claim is that there is no 
> legacy equipment that can speak ICE (and DTLS) but not rtcp-mux.
>

I agree it would clean up code considerably, and simplify candidate 
gathering, etc.

This means any gateways from WebRTC/ICE/etc to legacy RTP devices (PSTN 
gateways, whatever) will need to be able to do rtcp-mux on one side, and 
non-muxed on the other, and deal with possible payload rewriting to 
avoid conflicts.  Or punt.  I just want to make that clear; I am ok with 
this restriction (to require use of (not just support of) RTCP-mux in 
WebRTC).

Cc: Colin

-- 
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email [email-masked]!  Way too much spam

---

From: Roman Shpount <[email-masked]>
Date: Thu, 30 Jul 2015 17:11:05 -0400

As long as webrtc compliant end point MUST offer rtcp-mux and MUST always
accepted if offered by the remote end point I am ok with this.

Compliant end points MAY offer additional candidates for RTCP and accept
offers and answers without rtcp-mux.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Jul 2015 05:04:18 +0200

On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher <[email-masked]>
wrote:

> July.

Realistically, August at this point.

> support rtcp-mux.

This seems reasonable.

> An rtcweb endpoint would be free to fail if the remote endpoint does not
> support rtcp-mux.
>

Given the current specification, I believe this would need to be strong.
I.e., an rtcweb
endpoint *must* fail if the remote endpoint does not support rtcp-mux. As
should
be obvious, this only applies when the rtcweb endpoint is an answerer since
with
the above setting, you will not provide an offer that the other side can
accept, but
the spec says:

"When acting as answerer, the browser will reject any m= section that does
not provide an "a=rtcp-mux" attribute."

The reason for that is to avoid asymmetrical situations in which endpoint NM
(non-mux) makes an offer to endpoint M (mux) which is accepted, but then
re-offers from NM to M fail.

So I believe the best version of this proposal is simply requiring rtcp-mux
entirely.

-Ekr

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 30 Jul 2015 21:01:15 -0700

> Realistically, August at this point.

​Close enough :)
​

> be obvious, this only applies when the rtcweb endpoint is an answerer
> since with

​That makes sense, and I would be happy with "reject any m= section without
a=rtcp-mux".​

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 31 Jul 2015 10:18:57 +0000

"The whole reason we didn't do this before was because we wanted to work with legacy equipment.  But Cullen's claim is that there is no legacy equipment that can speak ICE (and DTLS) but not rtcp-mux."

I am not sure whether this is entirely true, especially on GW front. It could be a better idea to be lenient for enhanced interoperability and making RTCWeb more deployable in practice. Can't the decision of being firm on using rtcp-mux left to the WebRTC endpoint with signaling aspects supporting negotiation of the capability?

Thanks,

Tolga

________________________________
From: rtcweb <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Thursday, July 30, 2015 11:04 PM
To: Peter Thatcher
Cc: <[email-masked]>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

On Thu, Jul 30, 2015 at 9:17 PM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
At IETF 93 last week,  Cullen pointed out that he looked into ICE endpoints and found that all of them support rtcp-mux.  Inspired by that, I went around and asked about a dozen people "would you be OK if we removed support for non-muxed RTCP?"  The range of responses went from "I'm OK with it if Cullen is" to "yeah, that would be great".  No one said no.  Cullen said yes.

For me, removing support for non-muxed RTCP would be like Christmas in July.

So here's my proposal:  make RtcpMuxPolicy == "required" be not only the default, but the only RtcpMuxPolicy available.   All rtcweb endpoints must support rtcp-mux.

This seems reasonable.

An rtcweb endpoint would be free to fail if the remote endpoint does not support rtcp-mux.

Given the current specification, I believe this would need to be strong. I.e., an rtcweb
endpoint *must* fail if the remote endpoint does not support rtcp-mux. As should
be obvious, this only applies when the rtcweb endpoint is an answerer since with
the above setting, you will not provide an offer that the other side can accept, but
the spec says:

"When acting as answerer, the browser will reject any m= section that does not provide an "a=rtcp-mux" attribute."

-Ekr

The whole reason we didn't do this before was because we wanted to work with legacy equipment.  But Cullen's claim is that there is no legacy equipment that can speak ICE (and DTLS) but not rtcp-mux.

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

---

From: "Wyss, Felix" <[email-masked]>
Date: Fri, 31 Jul 2015 10:52:38 +0000

As somebody who has to interoperate between WebRTC and legacy VoIP, I wholeheartedly support making RTP/RTCP muxing mandatory.  Having just one "pipe" for everything is IMHO an incredibly compelling feature of WebRTC.  Furthermore, the fewer RECOMMENDED vs. MUST we have in the specification, the more likely the WebRTC endpoints from different vendors will be interoperable without hacks or workarounds.

--Felix

________________________________
From: rtcweb <[email-masked]> on behalf of Asveren, Tolga <[email-masked]>
Sent: Friday, July 31, 2015 06:18
To: Eric Rescorla; Peter Thatcher
Cc: <[email-masked]>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

Thanks,

Tolga

This seems reasonable.

-Ekr

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 31 Jul 2015 11:58:02 +0000

It is not really about "what is technically better" (and event there, the beauty is in the eye of the beholder depending on the deployment scenario) but more wider interoperability. As long as there is a negotiation mechanism/freedom to reject, I don't see any harm of allowing not to mandate rtcp-mux. You still can mandate its use in a specific implementation.

Thanks,
Tolga

From: Wyss, Felix [mailto:[email-masked]]
Sent: Friday, July 31, 2015 6:53 AM
To: Asveren, Tolga <[email-masked]>; Eric Rescorla <[email-masked]>; Peter Thatcher <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

--Felix
________________________________
From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
Sent: Friday, July 31, 2015 06:18
To: Eric Rescorla; Peter Thatcher
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

Thanks,

Tolga

________________________________
From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, July 30, 2015 11:04 PM
To: Peter Thatcher
Cc: <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

This seems reasonable.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 09:45:22 -0400

On Fri, Jul 31, 2015 at 7:58 AM, Asveren, Tolga <[email-masked]>
wrote:

> It is not really about “what is technically better” (and event there, the
> beauty is in the eye of the beholder depending on the deployment scenario)
> but more wider interoperability. As long as there is a negotiation
> mechanism/freedom to reject, I don’t see any harm of allowing not to
> mandate rtcp-mux. You still can mandate its use in a specific
> implementation.
>
>
>
Is there a WebRTC gateway or some other device that you have in mind that
supports DTLS-SRTP and does not support rtcp-mux?

The whole point of this discussion is to remove the negotiation for
rtcp-mux. If there are no devices that WebRTC endpoint can communicate with
(which now means devices supporting required DTLS-SRTP) which do not
support rtcp-mux, it would be better to reduce the code size by removing
rtcp-mux negotiation and all the code related to collecting second set of
candidates for RTCP connection, supporting second component per media
stream, negotiating second DTLS-SRTP for RTCP connection, etc. This is a
non-trivial amount of code, which is not being actively tested right now.
Most of the open source webrtc gateways I looked at have it broken.
Maintaining this code without a compelling use case is too much of the
burden this is why I strongly suggest rtcp-mux must be supported.

Regards,
_____________
Roman Shpount

---

From: <[email-masked]>
Date: Fri, 31 Jul 2015 13:56:52 +0000

+1

M.vr.gr<http://M.vr.gr>.,

Richard van Det
06 2054 7291

Op 31 jul. 2015 om 12:52 heeft Wyss, Felix <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

--Felix

Thanks,

Tolga

This seems reasonable.

-Ekr

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 31 Jul 2015 14:12:13 +0000

If following the logic you presented, lots of other optional/negotiable procedures/functionality for every protocol, including RTCWeb, could be left out by declaring that there is only a single way of doing things. That certainly would make implementation easier but not necessarily attractive to cater different deployment models/product categories.

One can code so that the product supports only rtcp-mux without all the complexities you mentioned below. This just would mean that such a product wouldn’t interoperate with elements not supporting rtcp-mux (and that shouldn’t be a problem as long as the product owner thinks that there are no elements supporting DTLS-SRTP but not rtcp-mux or does not car about interoperating with such devices).

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Friday, July 31, 2015 9:45 AM
To: Asveren, Tolga <[email-masked]>
Cc: Wyss, Felix <[email-masked]>; Eric Rescorla <[email-masked]>; Peter Thatcher <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

On Fri, Jul 31, 2015 at 7:58 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
It is not really about “what is technically better” (and event there, the beauty is in the eye of the beholder depending on the deployment scenario) but more wider interoperability. As long as there is a negotiation mechanism/freedom to reject, I don’t see any harm of allowing not to mandate rtcp-mux. You still can mandate its use in a specific implementation.

Is there a WebRTC gateway or some other device that you have in mind that supports DTLS-SRTP and does not support rtcp-mux?

The whole point of this discussion is to remove the negotiation for rtcp-mux. If there are no devices that WebRTC endpoint can communicate with (which now means devices supporting required DTLS-SRTP) which do not support rtcp-mux, it would be better to reduce the code size by removing rtcp-mux negotiation and all the code related to collecting second set of candidates for RTCP connection, supporting second component per media stream, negotiating second DTLS-SRTP for RTCP connection, etc. This is a non-trivial amount of code, which is not being actively tested right now. Most of the open source webrtc gateways I looked at have it broken. Maintaining this code without a compelling use case is too much of the burden this is why I strongly suggest rtcp-mux must be supported.

Regards,
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Jul 2015 09:20:03 -0700

On Jul 31, 2015, at 06:45, Roman Shpount <[email-masked]> wrote:
> 
> The whole point of this discussion is to remove the negotiation for rtcp-mux.

[BA] I support removing the mandate for RTP/RTCP non-mux but do not support removing the ability to negotiate it.  If an implementation supports it,  why shouldn't it be possible to negotiate its use?

> It would be better to reduce the code size by removing rtcp-mux negotiation and all the code related to collecting second set of candidates for RTCP connection, supporting second component per media stream, negotiating second DTLS-SRTP for RTCP connection, etc.This is a non-trivial amount of code, which is not being actively tested right now. Most of the open source webrtc gateways I looked at have it broken.

[BA] I agree that removing this code is attractive, particularly given the tricky issues that arise in supporting non-mux properly.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 31 Jul 2015 09:51:16 -0700

On Fri, Jul 31, 2015 at 9:20 AM, Bernard Aboba <[email-masked]>
wrote:

> [BA] I support removing the mandate for RTP/RTCP non-mux but do not
> support removing the ability to negotiate it.  If an implementation
> supports it,  why shouldn't it be possible to negotiate its use?
>

Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, but
MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That
would work for us.

>
> It would be better to reduce the code size by removing rtcp-mux
> negotiation and all the code related to collecting second set of candidates
> for RTCP connection, supporting second component per media stream,
> negotiating second DTLS-SRTP for RTCP connection, etc.This is a
> [BA] I agree that removing this code is attractive, particularly given the
> tricky issues that arise in supporting non-mux properly.
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Jul 2015 19:03:18 +0200

On Fri, Jul 31, 2015 at 6:51 PM, Justin Uberti <[email-masked]> wrote:

> Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP,
> but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That
> would work for us.
>

In this case, would browsers be able to reject attempts to set the policy to
anything other than always-mux? Because I'm pretty sure that's what both
we and Chrome want to do.

-Ekr

It would be better to reduce the code size by removing rtcp-mux negotiation
>> and all the code related to collecting second set of candidates for RTCP
>> connection, supporting second component per media stream, negotiating
>> second DTLS-SRTP for RTCP connection, etc.This is a non-trivial amount
>> of code, which is not being actively tested right now. Most of the open
>> source webrtc gateways I looked at have it broken.
>>
>>
>> [BA] I agree that removing this code is attractive, particularly given
>> the tricky issues that arise in supporting non-mux properly.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Jul 2015 17:04:59 +0000

Hi,

In my opinion, even if we mandate the usage of rtcp-mux, the negotiation (read: include the SDP rtcp-mux attribute in offers and answers) should not be removed. If there are ways to signal features we should do it.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Bernard Aboba<mailto:[email-masked]>
Sent: ‎31/‎07/‎2015 19:20
To: Roman Shpount<mailto:[email-masked]>
Cc: <[email-masked]><mailto:[email-masked]>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

On Jul 31, 2015, at 06:45, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Justin Uberti <[email-masked]>
Date: Fri, 31 Jul 2015 10:11:37 -0700

Mandating usage rtcp-mux means that an implementation is free to not
negotiate it (or fail if the remote side does not support it). Right?

On Fri, Jul 31, 2015 at 10:04 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> In my opinion, even if we mandate the usage of rtcp-mux, the negotiation
> (read: include the SDP rtcp-mux attribute in offers and answers) should not
> be removed. If there are ways to signal features we should do it.
>
> Regards,
>
> Christer
>
> ------------------------------
> From: Bernard Aboba <[email-masked]>
> To: Roman Shpount <[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 13:27:11 -0400

> negotiate it (or fail if the remote side does not support it). Right?
What I want to see precisely is the following:

1. WebRTC end point MUST include rtcp-mux for every SDP m-line in any offer
it generates
2. WebRTC end point MAY include RTCP ICE component, RTCP ICE candidates,
and "rtcp" SDP attribute with distinct RTCP address/port in the offer if it
wants to support non mux RTCP traffic or it MAY ommit all of those
attributes.
3. WebRTC end point MUST include rtcp-mux in response to any offer which
contains rtcp-mux. It should not include RTCP ICE components or RTCP ICE
candidates in the answer. "rtcp" SDP attribute MUST contain only port which
should be the same as port associated with m-line (or address from c-line
and port from m-line).
4. WebRTC end point MAY accept offers without rtcp-mux or MAY reject them.

So, basically, rtcp-mux must be offered and must be accepted if offered.
End point can continue to create offers which will work without rtcp-mux or
accept offers without rtcp-mux if it needs to interop with legacy.
_____________
Roman Shpount

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 31 Jul 2015 19:31:57 +0200

On Fri, Jul 31, 2015 at 7:27 PM, Roman Shpount <[email-masked]> wrote:

> 1. WebRTC end point MUST include rtcp-mux for every SDP m-line in any
> offer it generates

+1

Cheers,
-Victor

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Jul 2015 10:39:32 -0700

On Jul 31, 2015, at 10:03, Eric Rescorla <[email-masked]> wrote:
>> 
>> Are you saying that compliant RTCWEB endpoints MUST support muxed RTCP, but MAY support non-muxed RTCP (i.e. it is not explicitly prohibited)? That would work for us.

[BA] Yes.  Since RTP-Usage already requires mux support, we would only need to change the sentence requiring non-mux to make it optional. 

> we and Chrome want to do.

[BA] Yes, that should be possible. If non-mux is optional, then an implementation that doesn't support it would only allow setting the policy to always mux.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 31 Jul 2015 19:42:00 +0200

On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba <[email-masked]>
wrote:

> [BA] Yes.  Since RTP-Usage already requires mux support, we would only
> need to change the sentence requiring non-mux to make it optional.
>
> [BA] Yes, that should be possible. If non-mux is optional, then an
> implementation that doesn't support it would only allow setting the policy
> to always mux.
>

That seems satisfactory to me, since it means we can remove the code for
non-mux.

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Jul 2015 10:46:18 -0700

>> So, basically, rtcp-mux must be offered and must be accepted if offered. End point can continue to create offers which will work without rtcp-mux or accept offers without rtcp-mux if it needs to interop with legacy.

[BA] This is a bit weird because if a browser supporting non-mux negotiates with a gateway that supports non-mux, the implication is that if the browser is the offerer, mux is negotiated, but if the gateway is the offerer, non-mux can be negotiated. That would seem to imply that the gateway would need to reject the browser's offer, then send its own offer in order to negotiate non-mux.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 13:57:55 -0400

On Fri, Jul 31, 2015 at 1:46 PM, Bernard Aboba <[email-masked]>
wrote:

> [BA] This is a bit weird because if a browser supporting non-mux
> negotiates with a gateway that supports non-mux, the implication is that if
> the browser is the offerer, mux is negotiated, but if the gateway is the
> offerer, non-mux can be negotiated. That would seem to imply that the
> gateway would need to reject the browser's offer, then send its own offer
> in order to negotiate non-mux.
>

Why would the gateway need to negotiate non-mix if rtcp-mux is supported? I
have not seen anything that would normally accept an offer with rtcp-mux,
but will send an offer without rtcp-mux. In any case, if the gateway
behaves in such asymmetric manner, it will produce asymmetric results.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Jul 2015 11:31:43 -0700

On Jul 31, 2015, at 10:57, Roman Shpount <[email-masked]> wrote:
> 
> Why would the gateway need to negotiate non-mux if rtcp-mux is supported?

[BA] IMHO, Gateways should be required to support mux like any other WEBRTC endpoint, but this is not what it says in Section 2 of https://tools.ietf.org/html/draft-ietf-rtcweb-gateways :

"If a gateway serves as a media relay into another RTP domain, it MAY choose to support only features available in that network. This means that it MAY choose to not support Bundle and any of the RTP/ RTCP extensions related to it, RTCP-Mux, or Trickle Ice. However, the gateway MUST support DTLS-SRTP, since this is required for interworking with WebRTC endpoints."

Assuming that browsers remove or do not implement non-mux, it seems prudent to require gateways to support mux so as to avoid negotiation failures. If we make that change then gateways would always negotiate RTCP-mux with browsers.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 31 Jul 2015 11:33:19 -0700

likewise. That is the salient point here, after all.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Jul 2015 18:39:47 +0000

Hi,

My suggestion is that the offerer MUST include the attribute, and the answerer MUST include the attribute (assuming we go ahead with mandating usage of rtcp-mux).

Regards,

Christer

From: Justin Uberti [mailto:[email-masked]]
Sent: 31 July 2015 20:12
To: Christer Holmberg <[email-masked]>
Cc: Bernard Aboba <[email-masked]>; Roman Shpount <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

Mandating usage rtcp-mux means that an implementation is free to not negotiate it (or fail if the remote side does not support it). Right?

On Fri, Jul 31, 2015 at 10:04 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Jul 2015 18:41:33 +0000

Hi,

>So, basically, rtcp-mux must be offered and must be accepted if offered.

Yes, that is my opinion too. And “must be offered” means including the SDP rtcp-mux attribute.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 31 Jul 2015 18:43:42 +0000

Hi,

If we choose to mandate usage of rtcp-mux, we could also mandate gateways to support it.

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 31 July 2015 21:32
To: Roman Shpount <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On Jul 31, 2015, at 10:57, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

---

From: "Rauschenbach, Uwe (Nokia - DE/Munich)" <[email-masked]>
Date: Fri, 31 Jul 2015 18:44:46 +0000

Hi,

I can accept “must be offered”. But I do not understand “must be accepted if offered”. This is against the spirit of negotiation.
If the other endpoint does not support rtcp-mux it rejects this. Am I missing something?

Kind regards,
Uwe

From: rtcweb [mailto:[email-masked]] On Behalf Of ext Christer Holmberg
Sent: Friday, July 31, 2015 11:42 AM
To: Roman Shpount; Justin Uberti
Cc: <[email-masked]>
Subject: Re: [rtcweb] Proposal: require rtcp-mux (remove non-muxed RTCP; it would be Christmas in July!)

Hi,

Regards,

Christer

---

From: "Rauschenbach, Uwe (Nokia - DE/Munich)" <[email-masked]>
Date: Fri, 31 Jul 2015 18:45:10 +0000

I would say that to interwork with legacy networks, browsers need to implement non-mux. Whether or not it is actually negotiated is a different story.

Kind regards,
Uwe

From: rtcweb [mailto:[email-masked]] On Behalf Of ext Bernard Aboba
Sent: Friday, July 31, 2015 11:32 AM
To: Roman Shpount
Cc: <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 31 Jul 2015 18:49:21 +0000

Yes, you *could* mandate the whole universe to support it, that shouldn’t be too difficult to describe on paper ;-)

OTOH, why? If there are folks, for whom no-rtcp-mux is just fine (for whatever reason), let their implementations function that way (and let them suffer if this is really such a terrible thing from implementation difficulty perspective). And it will be their problem if that causes interoperability issues for them, e.g. they won’t be able to talk to browsers, which mandate use of rtcp-mux.

Browsers (or any other implementation) always mandate use of rtcp-mux by always offering it and terminating a session if the answer indicates no rtcp-mux support. Similarly, they can reject offers with rtcp-mux.

Thanks,
Tolga

From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Friday, July 31, 2015 2:44 PM
To: Bernard Aboba <[email-masked]>; Roman Shpount <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Hi,

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: 31 July 2015 21:32
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 14:57:48 -0400

On Fri, Jul 31, 2015 at 2:45 PM, Rauschenbach, Uwe (Nokia - DE/Munich) <
[email-masked]> wrote:

> I would say that to interwork with legacy networks, browsers need to
> implement non-mux. Whether or not it is actually negotiated is a different
> story.
>
>
>
Can you provide an example of a legacy network that implements DTLS-SRTP
and does not implement rtcp-mux?

>From my point of view this is no different that requirement to support ICE.
This is supposed to be negotiated as well, but failure to negotiate ICE
with WebRTC end point will cause connection to fail. I think suggestion
here is that rtcp-mux should be treated the same.
_____________
Roman Shpount

---

From: "Rauschenbach, Uwe (Nokia - DE/Munich)" <[email-masked]>
Date: Fri, 31 Jul 2015 18:58:07 +0000

Well: non-mux is not a “new thing” that we mandate the whole universe to support – it is on the contrary the way RTCP/RTP used to function since the beginning.
MUXing is the “new thing”.

Of course you can take away legacy support if no-one is interested in supporting it anymore.

I think this is the core of the discussion that we are having – do we want to retire the original way RTP+RTCP were working w.r.t. port usage?
I have my doubts (for the time being).

Kind regards,
Uwe

From: rtcweb [mailto:[email-masked]] On Behalf Of ext Asveren, Tolga
Sent: Friday, July 31, 2015 11:49 AM
To: Christer Holmberg; Bernard Aboba; Roman Shpount
Cc: <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Thanks,
Tolga

To: Bernard Aboba <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 14:59:32 -0400

On Fri, Jul 31, 2015 at 2:49 PM, Asveren, Tolga <[email-masked]>
wrote:

> Yes, you **could** mandate the whole universe to support it, that
> shouldn’t be too difficult to describe on paper ;-)
>
>
>
We are trying to mandate that WebRTC endpoints (browsers and gateways) must
support. The rest of the universe can continue to negotiate rtcp-mux and/or
not support it.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 15:01:37 -0400

On Fri, Jul 31, 2015 at 2:58 PM, Rauschenbach, Uwe (Nokia - DE/Munich) <
[email-masked]> wrote:

> I think this is the core of the discussion that we are having – do we want
> to retire the original way RTP+RTCP were working w.r.t. port usage?
>

I agree this is the core of this discussion, so can you please clarify why
you are having doubts? What is you argument or use case on why original
RTP+RTCP on separate ports is needed in context of WebRTC?

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 15:02:12 -0400

+1
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Fri, 31 Jul 2015 19:02:53 +0000

Yes, completely agree on the “new” v.s. “the way things used to work for many years” point as far as rtcp-mux is concerned.

Furthermore, -for example-, not mandating ICE would have serious impact as far as “making things work from end user perspective” is concerned. OTOH, the same does not necessarily hold true for rtcp-mux. Two WebRTC elements, which do not want to use it can communicate successfully.

Thanks,
Tolga

From: Rauschenbach, Uwe (Nokia - DE/Munich) [mailto:[email-masked]]
Sent: Friday, July 31, 2015 2:58 PM
To: Asveren, Tolga <[email-masked]>; Christer Holmberg <[email-masked]>; Bernard Aboba <[email-masked]>; Roman Shpount <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

Kind regards,
Uwe

Thanks,
Tolga

Hi,

Regards,

Christer

---

From: "Rauschenbach, Uwe (Nokia - DE/Munich)" <[email-masked]>
Date: Fri, 31 Jul 2015 19:08:13 +0000

Yes, agreed, these are in two different categories.

RTCP mux is an optimization – not supporting it doubles the number of ports to be used, and slows down ICE gathering.
Whereas ICE non-support is a showstopper

Let me have some internal discussions on this topic and get back to the list next week.

Kind regards,
Uwe

From: ext Asveren, Tolga [mailto:[email-masked]]
Sent: Friday, July 31, 2015 12:03 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; Bernard Aboba; Roman Shpount
Cc: <[email-masked]>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

Thanks,
Tolga

To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Bernard Aboba <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>

Kind regards,
Uwe

Thanks,
Tolga

Hi,

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 31 Jul 2015 15:35:41 -0400

On Fri, Jul 31, 2015 at 2:44 PM, Rauschenbach, Uwe (Nokia - DE/Munich) <
[email-masked]> wrote:

> I can accept “must be offered”. But I do not understand “must be accepted
> if offered”. This is against the spirit of negotiation.
>
I am trying to differentiate here end points that can be compliant with RFC
5761 by never offering rtcp-mux and rejecting all offers with rtcp-mux.
What we are proposing here is that rtcp-mux is actually used for all the
RTP/RTCP streams, not just correctly negotiated away.
_____________
Roman Shpount

---

From: <[email-masked]>
Date: Fri, 31 Jul 2015 19:37:09 +0000

When we choose this path, can we still support webrtc that is applied in devices / no-browser's?

Richard

Op 31 jul. 2015 om 19:42 heeft Eric Rescorla <[email-masked]<mailto:[email-masked]>> het volgende geschreven:

On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> wrote:
On Jul 31, 2015, at 10:03, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 31 Jul 2015 13:56:47 -0700

New WebRTC devices typically use mux since it results in sending fewer packets, using fewer ports, better energy consumption and reliability, etc. 

> On Jul 31, 2015, at 12:37 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Op 31 jul. 2015 om 19:42 heeft Eric Rescorla <[email-masked]> het volgende geschreven:
> 
>> 
>> 
>>> On Fri, Jul 31, 2015 at 7:39 PM, Bernard Aboba <[email-masked]> wrote: