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

From: Christer Holmberg <[email-masked]>
Date: Sat, 1 Aug 2015 10:42:52 +0000

Hi,

>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.

Well, I still think it shall be correctly negotiated. And, if NOT negotiated, the device would not be compliant with the spec.

Regards,

Christer

_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Sat, 1 Aug 2015 23:01:50 +0000

This list of expected behavior sounds good to me as well. GWs being "WebRTC-compatible endpoint" rather than "WebRTC endpoint" would have some freedom and browsers still can choose the path of mandating rtcp-mux (and otherwise failing the sessions) if the choose to do so.

Thanks,

Tolga

________________________________
From: rtcweb <[email-masked]> on behalf of Victor Pascual Avila <[email-masked]>
Sent: Friday, July 31, 2015 1:31 PM
To: Roman Shpount
Cc: <[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:27 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
On Fri, Jul 31, 2015 at 1:11 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
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?

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.

+1

Cheers,
-Victor

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Mon, 3 Aug 2015 07:19:02 +0000

The primary justification of webrtc gateways is to increase the propability of successfully end-to-end webrtc calls; -
between webrtc and non-webrtc clients, between two webrtc clients with different capability support.
That said, the supported capabilities of a webrtc gateway should not lead to an inherent reduction of the successful webrtc call establishment rate, i.e., not negatively impact the call control level negotiation procedures.

Conclusion: the webrtc gateway MUST support RTCP transport multiplexed and RTCP transport unmultiplexed modes, as well as the interworking between both modes.

Regards,
Albrecht

PS
With regards to DTLS-SRTP, i.e., the DTLS-based key management scheme for SRTP:
A webrtc gateway might need to support interworking between a webrtc domain with DTLS-SRTP and a non-webrtc domain with SDES-based key management scheme, i.e. a scenario of type SRTP-to-SRTP interworking. But I guess that use case is beyond the IETF gateway draft.

From: rtcweb [mailto:[email-masked]] On Behalf Of Rauschenbach, Uwe (Nokia - DE/Munich)
Sent: Freitag, 31. Juli 2015 21:08
To: ext Asveren, Tolga; Christer Holmberg; Bernard Aboba; Roman Shpount
Cc: <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

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]<mailto:[email-masked]>>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

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]<mailto:[email-masked]>>; Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Bernard Aboba <[email-masked]<mailto:[email-masked]>>; 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

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]<mailto:[email-masked]>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

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]<mailto:[email-masked]>>; 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

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]<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

On Jul 31, 2015, at 10:57, Roman Shpount <[email-masked]<mailto:[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: Eric Rescorla <[email-masked]>
Date: Mon, 3 Aug 2015 04:12:50 -0700

On Mon, Aug 3, 2015 at 12:19 AM, Schwarz, Albrecht (Albrecht) <
[email-masked]> wrote:

> The primary justification of webrtc gateways is to increase the
> propability of successfully end-to-end webrtc calls; -
>
> That said, the supported capabilities of a webrtc gateway should not lead
> to an inherent reduction of the successful webrtc call establishment rate,
> i.e., not negatively impact the call control level negotiation procedures.
>
>
>
> Conclusion: the webrtc gateway MUST support RTCP transport multiplexed and
> RTCP transport unmultiplexed modes, as well as the interworking between
> both modes.
>

I don't see how this conclusion follows.

I think this goes back to the question Peter and Cullen have been asking.
What
concrete scenario (i.e., real equipment) will fail to interoperate if we
simple require
MUX all the time?

-Ekr

Regards,
> A webrtc gateway might need to support interworking between a webrtc
> domain with DTLS-SRTP and a non-webrtc domain with SDES-based key
> management scheme, i.e. a scenario of type SRTP-to-SRTP interworking. But I
> guess that use case is beyond the IETF gateway draft.
>
>
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Rauschenbach,
> Uwe (Nokia - DE/Munich)
> *Sent:* Freitag, 31. Juli 2015 21:08
> *To:* ext Asveren, Tolga; Christer Holmberg; Bernard Aboba; Roman Shpount
>
> *Cc:* <[email-masked]>
> *Subject:* Re: [rtcweb] What the gateway draft should say about
> mux/non-mux
>
>
>
> RTCP mux is an optimization – not supporting it doubles the number of
> ports to be used, and slows down ICE gathering.
>
> *From:* ext Asveren, Tolga [mailto:[email-masked]
> <[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
>
>
>
> 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] <[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
>
>
>
> 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.
>
> 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?
>
> *From:* rtcweb [mailto:[email-masked] <[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
>
>
>
> 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] <[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,
>
>
>
> *From:* rtcweb [mailto:[email-masked] <[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]> wrote:
>
>
>
> [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 :
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Aug 2015 08:24:53 -0700

> I don't see how this conclusion follows. 

[BA]  It is logical that a gateway needs to support both WEBRTC endpoints and non-WEBRTC endpoints. However, it does not follow that WEBRTC endpoints should be required to support features of non-WEBRTC endpoints (e.g. like non-mux or SRTP/SDES). 

> I think this goes back to the question Peter and Cullen have been asking. What
> concrete scenario (i.e., real equipment) will fail to interoperate if we simply require
> MUX all the time?

[BA] From what I can tell, none. The gateway can speak mux to WEBRTC endpoints and non-mux to legacy.

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 3 Aug 2015 17:47:17 +0000

There are/will be deployment models, where WebRTC is used as a "Real Time Communication Profile" with endpoints as native applications rather than browsers ( I am not arguing/advocating that this interpretation/use of WebRTC specifications is completely kosher). In such environments, certain characteristics/capabilities/expectations will be a bit different than the "traditional" WebRTC use with browsers+Internet. So, a gateway, which is purpose-built for such specific deployments may not need to interwork with browsers. If it needs, it needs to support rtcp-mux.

I think a "SHOULD" strength statement for gateway rtcp-mux support with some explanation about the rationale behind it could be a good path forward.

Thanks,
Tolga

> -----Original Message-----
> From: Bernard Aboba [mailto:[email-masked]]
> Sent: Monday, August 03, 2015 11:25 AM
> To: Eric Rescorla <[email-masked]>
> Cc: Schwarz, Albrecht (Albrecht) <[email-masked]>;
> Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked]>;
> Asveren, Tolga <[email-masked]>; Christer Holmberg
> <[email-masked]>; Roman Shpount <[email-masked]>;
> <[email-masked]> <[email-masked]>
> [BA]  It is logical that a gateway needs to support both WEBRTC endpoints
> and non-WEBRTC endpoints. However, it does not follow that WEBRTC
> endpoints should be required to support features of non-WEBRTC endpoints
> (e.g. like non-mux or SRTP/SDES).
> 
> > I think this goes back to the question Peter and Cullen have been
> > asking. What concrete scenario (i.e., real equipment) will fail to
> > interoperate if we simply require MUX all the time?
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 3 Aug 2015 14:45:45 -0400

I think offering rtcp-mux and accepting rtcp-mux if offered should be a
MUST for WebRTC gateways. The gateway MAY accept offers or handle answers
without rtcp-mux, if it is needed for the particular deployment scenario.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Aug 2015 11:51:50 -0700

Some mobile applications do not care about interoperating with browsers,
only interoperating with their own backend infrastructure and the same
application running on other mobile platforms.  Those applications can
customize the WebRTC stack significantly, adding or removing functionality
such as RTP/RTCP features, codecs, transports, etc. without having to test
interoperability with browsers.

Although this kind of customization occurs very frequently today, it
isn't that relevant to the IETF RTCWEB specifications which apply to
browser implementations and gateways that support browser implementations.
Just as a mobile application can deviate from the WebRTC specifications, a
gateway developed for that application may not conform to the WebRTC
gateway specification either.  Cataloging every way that non-compliant
implementations can deviate is a potentially endless task.

On Mon, Aug 3, 2015 at 10:47 AM, Asveren, Tolga <[email-masked]>
wrote:

> There are/will be deployment models, where WebRTC is used as a "Real Time
> Communication Profile" with endpoints as native applications rather than
> browsers ( I am not arguing/advocating that this interpretation/use of
> WebRTC specifications is completely kosher). In such environments, certain
> characteristics/capabilities/expectations will be a bit different than the
> "traditional" WebRTC use with browsers+Internet. So, a gateway, which is
> purpose-built for such specific deployments may not need to interwork with
> browsers. If it needs, it needs to support rtcp-mux.
>
> I think a "SHOULD" strength statement for gateway rtcp-mux support with
> some explanation about the rationale behind it could be a good path forward.
>
> Thanks,
> Tolga
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 3 Aug 2015 23:21:47 +0000

With this interpretation, is there really a raison d'être for the GW draft? One just could view it as an entity with one side facing WebRTC universe as a "full WebRTC endpoint". Honestly, that would make life easier rather than muddying the water with what a GW should/must/may do.

Thanks,

Tolga

________________________________
From: Bernard Aboba <[email-masked]>
Sent: Monday, August 3, 2015 2:51 PM
To: Asveren, Tolga
Cc: Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; Roman Shpount; <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Some mobile applications do not care about interoperating with browsers, only interoperating with their own backend infrastructure and the same application running on other mobile platforms.  Those applications can customize the WebRTC stack significantly, adding or removing functionality such as RTP/RTCP features, codecs, transports, etc. without having to test interoperability with browsers.

Although this kind of customization occurs very frequently today, it isn't that relevant to the IETF RTCWEB specifications which apply to browser implementations and gateways that support browser implementations.  Just as a mobile application can deviate from the WebRTC specifications, a gateway developed for that application may not conform to the WebRTC gateway specification either.  Cataloging every way that non-compliant implementations can deviate is a potentially endless task.

On Mon, Aug 3, 2015 at 10:47 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
There are/will be deployment models, where WebRTC is used as a "Real Time Communication Profile" with endpoints as native applications rather than browsers ( I am not arguing/advocating that this interpretation/use of WebRTC specifications is completely kosher). In such environments, certain characteristics/capabilities/expectations will be a bit different than the "traditional" WebRTC use with browsers+Internet. So, a gateway, which is purpose-built for such specific deployments may not need to interwork with browsers. If it needs, it needs to support rtcp-mux.

Thanks,
Tolga

> From: Bernard Aboba [mailto:[email-masked]<mailto:[email-masked]>]
> To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
> Cc: Schwarz, Albrecht (Albrecht) <[email-masked]<mailto:[email-masked]>>;
> Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked]<mailto:[email-masked]>>;
> Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; Christer Holmberg
> <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
> On Aug 3, 2015, at 04:12, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Roman Shpount <[email-masked]>
Date: Mon, 3 Aug 2015 19:39:46 -0400

On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga <[email-masked]>
wrote:

> With this interpretation, is there really a raison d'être for the GW
> draft? One just could view it as an entity with one side facing WebRTC
> universe as a "full WebRTC endpoint". Honestly, that would make life easier
> rather than muddying the water with what a GW should/must/may do.
>
GW is different from the "full WebRTC endpoint" since it would typically be
placed on public IP. This allows for slightly different requirements. For
instance gateway can be ICE-lite instead of full ICE required by WebRTC end
point.

Regards,
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 3 Aug 2015 23:57:19 +0000

Well, the same would apply to a WebRTC-endpoint, which is deployed with a public IP. Why invent a new term as GW? These are just choices based on deployment model.

And who said there are universal guarantees that GWs will be deployed with routable IP Addresses? Again, deployment choices are best left unspecified.

Thanks,

Tolga

________________________________
From: Roman Shpount <[email-masked]>
Sent: Monday, August 3, 2015 7:39 PM
To: Asveren, Tolga
Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

GW is different from the "full WebRTC endpoint" since it would typically be placed on public IP. This allows for slightly different requirements. For instance gateway can be ICE-lite instead of full ICE required by WebRTC end point.

Regards,
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 3 Aug 2015 22:05:07 -0700

As Roman said, gateways have only slightly different requirements on the WEBRTC side due to potential ability to use a Public IP address, allowing use of ICE-LITE.  Requirements on the other side depend on what the legacy endpoint is. The lowest legacy endpoint is one with IPv4, g.711, RTP/AVP or perhaps RTP/SAVP, no ICE, maybe no RTCP. 

> On Aug 3, 2015, at 16:57, Asveren, Tolga <[email-masked]> wrote:
> 
>> On Mon, Aug 3, 2015 at 7:21 PM, Asveren, Tolga <[email-masked]> wrote:

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 4 Aug 2015 08:47:34 +0000

These are just some *assumptions*. There are/will be gateways deployed with no public IP Addresses. Similarly what is "on the other side" of the gateway is/will be varied as well.

If one goes into the guessing game, it can be argued that "A gateway potentially may be deployed with only endpoints supporting x/y/z etc..". There could be many such combinations.

In the light of this, I really don't see a point for the GW draft, especially after seeing that folks have the view that it should fully interoperate with a "vanilla WebRTC endpoint". That pretty much means that a GW itself a WebRTC endpoint and there is nothing else to specify from RTCWeb WG perspective (and hence there is even no need to define an entity as "WebRTC GW").

Thanks,

Tolga

________________________________
From: Bernard Aboba <[email-masked]>
Sent: Tuesday, August 4, 2015 1:05 AM
To: Asveren, Tolga
Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On Aug 3, 2015, at 16:57, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Tolga

________________________________
From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Sent: Monday, August 3, 2015 7:39 PM
To: Asveren, Tolga
Cc: Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Aug 2015 14:30:22 +0000

Hi,

> In the light of this, I really don't see a point for the GW draft, especially after seeing that folks have the view that it should fully interoperate with a "vanilla WebRTC endpoint". That pretty

> much means that a GW itself a WebRTC endpoint and there is nothing else to specify from RTCWeb WG perspective (and hence there is even no need to define an entity as "WebRTC GW").

As has been said, a WebRTC GW differs from a vanilla WebRTC endpoint e.g. in that it can be ICE-lite and that it is not mandated to send consent refresh requests. However, that doesn't prevent it from fully interoperating with a vanilla endpoint.

Regards,

Christer

________________________________
From: Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, August 4, 2015 1:05 AM
To: Asveren, Tolga
Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Thanks,

Tolga

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Aug 2015 14:36:44 +0000

Hi Bernard,

I don’t think the IETF RTCWEB specifications apply only to browser clients. If so, where is that defined?

Regards,

Christer

From: Bernard Aboba [mailto:[email-masked]]
Sent: 3. elokuuta 2015 21:52
To: Asveren, Tolga
Cc: Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; Roman Shpount; <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Thanks,
Tolga

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 4 Aug 2015 23:24:35 +0000

There are broadly two different categories of behavior when it comes to standards organizations/specifications:

i- Standards, which define the actual protocol mechanics, e.g. on the wire messages, negotiation procedures between peers. These are essential for different elements to communicate and "do the right thing".

ii- Profiles, which usually specify a subset of the whole functionality defined in i- as a functionality set to be used in a particular deployment environment.

I think IETF in general is more interested in i-. Defining what a "WebRTC GW" is and how it can use/omit certain core functionalities does not fall into this category.

Just as an example, let's take the example of se of public IP Addresses: If the actual standard allows use of ICE-lite, it is up to an implementer to build a box with only ICE-lite support if it is going to be used exclusively in an environment where it will be assigned a public IP Address. This does not require "standardization" AFAICS. So, I don't think a document like GW-draft is really much useful and should be "Informational", if it should exist at all.

Admittedly, the issue of rtcp-mux is a bit more grey. In running code we trust and several parties indicated that supporting DTLS-SRTP with full rtcp-mux negotiation support is a pain in the neck. Actually even here one could take a more "this is not a core protocol issue" approach. If all browsers support only rtcp-mux and do not interoperate with elements which do not support it, well that would be just it. Any such other entity either would not be able to communicate with the browsers and realize its mistake or it won't care about it at all as it is designed to be deployed in a non-browser environment. I understand that this is perceived as having a detrimental effect on practical interoperability but I am not sure whether a core protocol level mandate of forbidding no-rtcp-mux is justified. When it comes to browser-to-non browser entity communication, I think the cards are stacked very heavily in favor of browsers for such functionality mismatches. In other words, whatever browsers do would be the "de facto Internet Profile".

Thanks,

Tolga

________________________________
From: Christer Holmberg <[email-masked]>
Sent: Tuesday, August 4, 2015 10:30 AM
To: Asveren, Tolga; Bernard Aboba
Cc: Roman Shpount; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); <[email-masked]>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

Hi,

> much means that a GW itself a WebRTC endpoint and there is nothing else to specify from RTCWeb WG perspective (and hence there is even no need to define an entity as "WebRTC GW").

As has been said, a WebRTC GW differs from a vanilla WebRTC endpoint e.g. in that it can be ICE-lite and that it is not mandated to send consent refresh requests. However, that doesn’t prevent it from fully interoperating with a vanilla endpoint.

Regards,

Christer

Thanks,

Tolga

Regards,

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 4 Aug 2015 19:33:40 -0400

On Tue, Aug 4, 2015 at 7:24 PM, Asveren, Tolga <[email-masked]>
wrote:

> In running code we trust and several parties indicated that supporting
> DTLS-SRTP with full rtcp-mux negotiation support is a pain in the neck.
>
Did you mean to say "*supporting **DTLS-SRTP without rtcp-mux is a pain in
the neck*"?

Most of the people implement this wrong, since you need to create two DTLS
sessions: one for RTP and another for RTCP. And then use different keys or
possibly even encryption profiles for RTP and RTCP. I commonly see one
session for RTP and keys negotiated there used for both RTP and RTCP, which
is wrong.
_____________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Tue, 4 Aug 2015 23:43:13 +0000

Mea culpa, yes, thanks for the correction.

Again, my opinion (actually more than an opinion, it is an observation) is that whatever browsers do is followed/implemented by other entities if they are expected to interface with them -even to the level of specification violations-. So, the notion of "de facto Internet Profile" seems to be working pretty efficiently.

Thanks,

Tolga

________________________________
From: Roman Shpount <[email-masked]>
Sent: Tuesday, August 4, 2015 7:33 PM
To: Asveren, Tolga
Cc: Christer Holmberg; Bernard Aboba; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On Tue, Aug 4, 2015 at 7:24 PM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

In running code we trust and several parties indicated that supporting DTLS-SRTP with full rtcp-mux negotiation support is a pain in the neck.

Did you mean to say "supporting DTLS-SRTP without rtcp-mux is a pain in the neck"?

Most of the people implement this wrong, since you need to create two DTLS sessions: one for RTP and another for RTCP. And then use different keys or possibly even encryption profiles for RTP and RTCP. I commonly see one session for RTP and keys negotiated there used for both RTP and RTCP, which is wrong.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Tue, 4 Aug 2015 19:53:37 -0400

On Tue, Aug 4, 2015 at 7:43 PM, Asveren, Tolga <[email-masked]>
wrote:

> Again, my opinion (actually more than an opinion, it is an observation) is
> that whatever browsers do is followed/implemented by other entities if they
> are expected to interface with them -even to the level of specification
> violations-. So, the notion of "de facto Internet Profile" seems to be
> working pretty efficiently.
>
In some ways you are right and this group is just a way for web browser
makers to ask the technical community opinion on how things should be
built. It worked well so far.

So, I guess, you can treat this whole discussion as web browser makers
asking nicely if anybody have any objections to removing support for non
muxed RTCP in web browsers. So far nobody here voice any.
_____________
Roman Shpount

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 4 Aug 2015 19:03:57 -0700

> Most of the people implement this wrong, since you need to create two DTLS sessions: one for RTP and another for RTCP. And then use different keys or possibly even encryption profiles for RTP and R…

[BA] Yes, that is only one of several common mistakes.  Unfortunately, RFC 5764 does not rule out all of these and the security documents are not crystal clear on how things must be done. It is much harder to mess up RTP/RTCP mux.  Given what I've seen so far, non-mux could become a support nightmare.

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 5 Aug 2015 08:03:37 +0000

Roman, Bernard,
right, RFC 5764 is too vague on that aspect. Thanks for confirming the number of DTLS sessions, which is inline with our understanding.
Would appreciate if this could be somewhere fixed in an rtcweb draft due to significant side effects.
This topic is also an ongoing FAQ.

The most simple case is given by a scenario with usage of bundling plus usage of RTP/RTCP transport multiplexing, leading to a single DTLS session/DTLS connection, which could be then also shared for WebRTC data.

Both capabilities are mandated in the rtp usage draft:
https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.4
=> bundling
https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5
=> RTP/RTCP transport multiplexing

Now, IF bundling is not used OR RTP/RTCP transport multiplexing is not used THEN there will be more than one DTLS session/DTLS connection (either 2 or 4 in case of audio & video).
Raising the question which DTLS connection is used for additional WebRTC data traffic? - Because
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5
indicates the sharing option.
Would then be a 3rd (or 5th) self-contained DTLS session/DTLS connection for WebRTC data traffic?

Proposal:
Add explicit text to clause https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#section-3.5
about (in red), something like:

   WebRTC implementations MUST support multiplexing of DTLS and RTP over
   the same port pair, as described in the DTLS-SRTP specification
   [RFC5764], section 5.1.2<https://tools.ietf.org/html/rfc5764#section-5.1.2>.  All application layer protocol payloads
   over this DTLS connection are SCTP packets.

   Note 1: There will be two DTLS sessions/DTLS connections when RTP/RTCP transport multiplexing is not applied. WebRTC data traffic could still share one of these DTLS connections … (“which one?”) … or There should be then a separate, self-contained DTLS session/DTLS connection established exclusively for WebRTC data.

   Note 2: There are similar considerations in case of bundling.

   Protocol identification MUST be supplied as part of the DTLS
   handshake, as specified in [I-D.ietf-rtcweb-alpn<https://tools.ietf.org/html/draft-ietf-rtcweb-transports-09#ref-I-D.ietf-rtcweb-alpn>].

Comments?
Regards,
Albrecht

PS
Using (D)TLS terminology according to http://tools.ietf.org/id/draft-guballa-tls-terminology-01.txt

From: Bernard Aboba [mailto:[email-masked]]
Sent: Mittwoch, 5. August 2015 04:04
To: Roman Shpount
Cc: Asveren, Tolga; Christer Holmberg; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On Aug 4, 2015, at 16:33, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Aug 2015 08:12:34 +0000

Hi,

We shall not make RFC 5764 corrections in the RTCWEB specs.

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Schwarz, Albrecht (Albrecht)
Sent: 5. elokuuta 2015 11:04
To: <[email-masked]>
Cc: [email-masked] ([email-masked])
Subject: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux

Roman, Bernard,

Proposal:

Comments?
Regards,
Albrecht

PS

From: Bernard Aboba [mailto:[email-masked]]
Sent: Mittwoch, 5. August 2015 04:04
To: Roman Shpount
Cc: Asveren, Tolga; Christer Holmberg; Eric Rescorla; Schwarz, Albrecht (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 5 Aug 2015 08:16:56 +0000

Christer,
do agree of course.
But independent of the RFC 5764 correction, below clarification proposal for rtcweb-transport remains valid (“due to the sharing assumption”).

Regards,
Albrecht

From: Christer Holmberg [mailto:[email-masked]]
Sent: Mittwoch, 5. August 2015 10:13
To: Schwarz, Albrecht (Albrecht); <[email-masked]>
Cc: [email-masked] ([email-masked])
Subject: RE: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux

Hi,

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Schwarz, Albrecht (Albrecht)
Sent: 5. elokuuta 2015 11:04
To: <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>)
Subject: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux

Roman, Bernard,

Proposal:

Comments?
Regards,
Albrecht

PS

---

From: "Rauschenbach, Uwe (Nokia - DE/Munich)" <[email-masked]>
Date: Wed, 5 Aug 2015 08:47:38 +0000

From: ext Eric Rescorla [mailto:[email-masked]]
Sent: Monday, August 03, 2015 1:13 PM

I think this goes back to the question Peter and Cullen have been asking. What
concrete scenario (i.e., real equipment) will fail to interoperate if we simple require
MUX all the time?

-Ekr

Hello Ekr,

Media gateway implementations according to 3GPP TS 23.228 may not support rtcp-mux, as rtcp-mux is optional there.
So if we drop non-mux support from web browsers, those media gateways that have not implemented rtcp-mux will stop interoperating.

From TS 23.228:
U.1.3.3   eP-CSCF (P-CSCF enhanced for WebRTC)
The P-CSCF enhanced for WebRTC (eP-CSCF) is a P-CSCF including the IMS-ALG functionality and with the following additional functions:

…

-     The eP-CSCF shall ensure via signalling that RTP streams are not multiplexed ("bundled") onto the same port.

-     The eP-CSCF shall ensure via signalling that RTP and RTCP flows of an RTP stream are not multiplexed onto the same port if entities anchoring the session media path in the IMS domain do not support that capability.

Kind regards,
Uwe

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 5 Aug 2015 10:58:22 +0200

On 05/08/2015 10:47, Rauschenbach, Uwe (Nokia - DE/Munich) wrote:
>
> So if we drop non-mux support from web browsers, those media gateways 
> that have not implemented rtcp-mux will stop interoperating.
>

Hi Uwe!

Then just mandate the media gateways to support RTCP muxing if DTLS is 
enabled on 3GPP TS 23.228.. ;)

Let's be realistic, anyone implementing a media gateway compatible with 
WebRTC today and pretend to have an stable version while the WebRTC 
specs are not yet finish and in constant evolution is a bit naive, and 
IMHO that should not be a showstopper for this kind of changes on 
WebRTC. (Disclaimer: I am myself the lead developer of media gateway)

Best regards
Sergio

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 5 Aug 2015 12:27:17 +0000

Yes, completely agree.

And I think what Albrecht proposes below is the right way of addressing the “no-rtcp-mux implementation difficulties” problem: Adding clarifications/amendments in the respective normative specification rather than disallowing a combination in a profile because it is “confusing”.
Honestly, I think the number of DTLS connections to use, when bundling/muxing is not used, is not really that hard to figure out (for somebody who actually understands the whole story) but obviously no harm of adding some clarifications. DataChannel aspects need to be crisply specified though. What is the main advantage of letting DataChannel potentially use one of the exsiting DTLS connections? Just to save some time on negotiation?

Thanks,
Tolga

From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, August 05, 2015 4:13 AM
To: Schwarz, Albrecht (Albrecht) <[email-masked]>; <[email-masked]> <[email-masked]>
Cc: [email-masked] ([email-masked]) <[email-masked]>
Subject: Re: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux

Hi,

Regards,

Christer

Roman, Bernard,

Proposal:

Comments?
Regards,
Albrecht

PS

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Aug 2015 12:39:10 +0000

Hi,

I guess we could add some clarification text to the SDP-DTLS draft.

Regards,

Christer

From: Asveren, Tolga [mailto:[email-masked]]
Sent: 5. elokuuta 2015 15:27
To: Christer Holmberg; Schwarz, Albrecht (Albrecht); <[email-masked]>
Cc: [email-masked] ([email-masked])
Subject: RE: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux

Yes, completely agree.

Thanks,
Tolga

From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Wednesday, August 05, 2015 4:13 AM
To: Schwarz, Albrecht (Albrecht) <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]> ([email-masked]<mailto:[email-masked]>) <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] Number of DTLS sessions/DTLS connections; RE: What the gateway draft should say about mux/non-mux

Hi,

Regards,

Christer

Roman, Bernard,

Proposal:

Comments?
Regards,
Albrecht

PS

---

From: Ranjit Avasarala <[email-masked]>
Date: Wed, 05 Aug 2015 10:17:18 -0500

Given a case where one side of the WebRTC GW supports DTLS-SRTp and the 
other end supports SDES, then should WebRTC take care of doing the 
conversion?

Regards
Ranjit

On 2015-08-03 2:19 am, Schwarz, Albrecht (Albrecht) wrote:
> That said, the supported capabilities of a webrtc gateway should not
> lead to an inherent reduction of the successful webrtc call
> establishment rate, i.e., not negatively impact the call control level
> negotiation procedures.
> 
> Conclusion: the webrtc gateway MUST support RTCP transport multiplexed
> and RTCP transport unmultiplexed modes, as well as the interworking
> between both modes.
> 
> Regards,
> 
> Albrecht
> 
> PS
> 
> management scheme, i.e. a scenario of type SRTP-to-SRTP interworking.
> But I guess that use case is beyond the IETF gateway draft.
> 
> FROM: rtcweb [mailto:[email-masked]] ON BEHALF OF
> Rauschenbach, Uwe (Nokia - DE/Munich)
>  SENT: Freitag, 31. Juli 2015 21:08
>  TO: ext Asveren, Tolga; Christer Holmberg; Bernard Aboba; Roman
> Shpount
>  CC: <[email-masked]>
>  SUBJECT: Re: [rtcweb] What the gateway draft should say about
> mux/non-mux
> 
> RTCP mux is an optimization – not supporting it doubles the number
> of ports to be used, and slows down ICE gathering.
> 
> 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
> 
> 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
> 
> 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.
> 
> 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?
> 
> 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
> 
> Yes, you *COULD* mandate the whole universe to support it, that
> 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,
> 
> 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
> 
> https://tools.ietf.org/html/draft-ietf-rtcweb-gateways [1] :
> 
> "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.
> 
> 
> Links:
> ------
> [1] https://tools.ietf.org/html/draft-ietf-rtcweb-gateways
> 

-- 
Regards
Ranjit

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 5 Aug 2015 08:25:31 -0700

No. That's the gateway's job.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Aug 2015 08:42:48 -0700

-tls@

My reading is that we are close to concluding that rtcpmux is
required.  Therefore, this becomes a non-issue.

On 5 August 2015 at 01:03, Schwarz, Albrecht (Albrecht)
<[email-masked]> wrote:
> Roman, Bernard,
>
> right, RFC 5764 is too vague on that aspect. Thanks for confirming the
> number of DTLS sessions, which is inline with our understanding.
>
> The most simple case is given by a scenario with usage of bundling plus
> usage of RTP/RTCP transport multiplexing, leading to a single DTLS
> session/DTLS connection, which could be then also shared for WebRTC data.
>
>
>
> Now, IF bundling is not used OR RTP/RTCP transport multiplexing is not used
> THEN there will be more than one DTLS session/DTLS connection (either 2 or 4
> in case of audio & video).
>
> Add explicit text to clause
>    [RFC5764], section 5.1.2.  All application layer protocol payloads
>
>    Note 1: There will be two DTLS sessions/DTLS connections when RTP/RTCP
> transport multiplexing is not applied. WebRTC data traffic could still share
> one of these DTLS connections … (“which one?”) … or There should be then a
> separate, self-contained DTLS session/DTLS connection established
> exclusively for WebRTC data.
>
>
>
>    handshake, as specified in [I-D.ietf-rtcweb-alpn].
>
>
>
> Comments?
>
> Regards,
>
> Albrecht
>
>
>
> PS
>
> Using (D)TLS terminology according to
> http://tools.ietf.org/id/draft-guballa-tls-terminology-01.txt
>
>
>
>
>
> Cc: Asveren, Tolga; Christer Holmberg; Eric Rescorla; Schwarz, Albrecht
> (Albrecht); Rauschenbach, Uwe (Nokia - DE/Munich); <[email-masked]>
> [BA] Yes, that is only one of several common mistakes.  Unfortunately, RFC
> 5764 does not rule out all of these and the security documents are not
> crystal clear on how things must be done. It is much harder to mess up
> RTP/RTCP mux.  Given what I've seen so far, non-mux could become a support
> nightmare.
>
>
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 5 Aug 2015 12:28:32 -0400

On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) <
[email-masked]> wrote:

> So if we drop non-mux support from web browsers, those media gateways that
> have not implemented rtcp-mux will stop interoperating.
>
>
>
First of all, do you know of any WebRTC to IMS gateways that do not
implement rtcp-mux on the WebRTC side? I strongly suspect there are none.

Second, the only reasons not to use rtcp-mux that I can think of are the
following:

1. Using different QOS settings for RTCP vs RTP
2. Sending RTCP to a different device from RTP

I do not think the first use case warrants making rtcp-mux optional, since,
practically no one does this.
Second use case is also fairly marginal. Plus it can be handled by the
gateway which can send RTCP to one device and RTP to another.

So, unless someone can come up with a use case why RTP and RTCP should use
different transports, I think rtcp-mux should be mandatory.

Regards,
______________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Wed, 5 Aug 2015 17:46:46 +0000

i- I humbly disagree that using different QoS RTCP/RTP, e.g. different DiffServ values , should be dismissed.
ii- Let me also add another reason why no-rtcp-mux may be needed: Implementation difficulties in certain GWs.

Considering that there is already a negotiation mechanism for rtcp-mux support, that it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to move forward: provide clarifications for vague points. I don’t understand why lack of clarity in existing specifications should cause imposing restrictions. This would be akin to dropping a feature due to a bug. In this case, the “bug” is lack of clarity in normative specifications and it can be addressed by further specification.

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked]>
Cc: ext Eric Rescorla <[email-masked]>; Schwarz, Albrecht (Albrecht) <[email-masked]>; Asveren, Tolga <[email-masked]>; Christer Holmberg <[email-masked]>; Bernard Aboba <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked]<mailto:[email-masked]>> wrote:
Media gateway implementations according to 3GPP TS 23.228 may not support rtcp-mux, as rtcp-mux is optional there.
So if we drop non-mux support from web browsers, those media gateways that have not implemented rtcp-mux will stop interoperating.

First of all, do you know of any WebRTC to IMS gateways that do not implement rtcp-mux on the WebRTC side? I strongly suspect there are none.

Second, the only reasons not to use rtcp-mux that I can think of are the following:

I do not think the first use case warrants making rtcp-mux optional, since, practically no one does this.
Second use case is also fairly marginal. Plus it can be handled by the gateway which can send RTCP to one device and RTP to another.

So, unless someone can come up with a use case why RTP and RTCP should use different transports, I think rtcp-mux should be mandatory.

Regards,
______________
Roman Shpount

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 6 Aug 2015 06:44:54 +0000

The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already RTP/RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be the limiting factor in this discussion.
For ones interested in the RTCP port allocation rules, see H.248.57:
https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.248.57-201410-I!!PDF-E&type=items
Clause 7 describes RTP/RTCP transport multiplexing. ITU-T H.248.57 is already supported by 3GPP 29.334.

The rationale behind the “optional tagging” by 23.228 is a third reason, beyond
>2. Sending RTCP to a different device from RTP

Don’t want to go in the 3GPP specific details, but it has nothing to do with the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC gateways.

Thus, a WebRTC gateway MUST support RTP/RTCP transport multiplexing due to its purpose in interworking support.

Regards,
Albrecht

From: Asveren, Tolga [mailto:[email-masked]]
Sent: Mittwoch, 5. August 2015 19:47
To: Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Bernard Aboba; <[email-masked]>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

Thanks,
Tolga

From: Roman Shpount [mailto:[email-masked]]
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked]<mailto:[email-masked]>>
Cc: ext Eric Rescorla <[email-masked]<mailto:[email-masked]>>; Schwarz, Albrecht (Albrecht) <[email-masked]<mailto:[email-masked]>>; Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Bernard Aboba <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Regards,
______________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 6 Aug 2015 09:18:07 +0000

Why should we consider 3GPP the sole "owner/user" of the term/entity WebRTC-GW? I think it has a much more general meaning and use in practice. It can refer to many different types of elements which can be deployed in many different environments, hence any attempt to define it strictly/restrict its capabilities are futile IMHO.

Thanks,

Tolga

________________________________
From: Schwarz, Albrecht (Albrecht) <[email-masked]>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <[email-masked]>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

Regards,

Albrecht

Thanks,

Tolga

Regards,

______________

Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Aug 2015 09:51:29 +0000

Hi,

No matter whether the gateway supports RTP/RTCP mux or not, there are cases where the legacy network/endpoints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux "end-to-end", rather than having the gateway to demux/mux RTP and RTCP.

Regards,

Christer

From: Asveren, Tolga [mailto:[email-masked]]
Sent: 6. elokuuta 2015 12:18
To: Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Thanks,

Tolga

________________________________
From: Schwarz, Albrecht (Albrecht) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, August 6, 2015 2:44 AM
To: Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <[email-masked]<mailto:[email-masked]>>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

The rationale behind the "optional tagging" by 23.228 is a third reason, beyond

>2. Sending RTCP to a different device from RTP

Don't want to go in the 3GPP specific details, but it has nothing to do with the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC gateways.

Regards,

Albrecht

Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Bernard Aboba; <[email-masked]<mailto:[email-masked]>>

Considering that there is already a negotiation mechanism for rtcp-mux support, that it can be de-facto mandated by the choice of browsers for Internet, I think what Christer/Albrecht suggested is the right way to move forward: provide clarifications for vague points. I don't understand why lack of clarity in existing specifications should cause imposing restrictions. This would be akin to dropping a feature due to a bug. In this case, the "bug" is lack of clarity in normative specifications and it can be addressed by further specification.

Thanks,

Tolga

Regards,

______________

Roman Shpount

---

From: "Wyss, Felix" <[email-masked]>
Date: Thu, 6 Aug 2015 10:36:44 +0000

Why shouldn't the gateway be required to do the mux/demux?  Making the WebRTC endpoints a lot more complex just so the legacy interop might potentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, the gateway would not be able to do "end-to-end" pass-through anyway as legacy equipment will either be unencrypted or use SDES (RFC#4568) for key exchange.  So the gateway will have to perform DTLS-SRTP to SDES-SRTP transcryption--which already is way more hassle than RTP/RTCP mux/demux.

--Felix

________________________________
From: rtcweb <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Sent: Thursday, August 6, 2015 05:51
To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Hi,

No matter whether the gateway supports RTP/RTCP mux or not, there are cases where the legacy network/endpoints will not use RTP/RTCP mux, so I guess people then would want to be able to negotiate non-mux “end-to-end”, rather than having the gateway to demux/mux RTP and RTCP.

Regards,

Christer

Thanks,

Tolga

Regards,

Albrecht

Thanks,

Tolga

Regards,

______________

Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 6 Aug 2015 11:44:12 +0000

These assumptions are not necessarily true in a universal sense (like almost any other assumption about different deployment models).

Furthermore, and more importantly, there is nothing mandating WebRTC endpoints to support non-rtcp-mux. It is a negotiated functionality. Any entity can enforce rtcp-mux as a local policy.

The issue with supporting non-rtcp-mux seems to be lack of clarity in the relevant specifications. Fixing this -regardless of the outcome of any other discussion- seems to be prudent IMHO.

Thanks,
Tolga

From: Wyss, Felix [mailto:[email-masked]]
Sent: Thursday, August 06, 2015 6:37 AM
To: Christer Holmberg <[email-masked]>; Asveren, Tolga <[email-masked]>; Schwarz, Albrecht (Albrecht) <[email-masked]>; Roman Shpount <[email-masked]>; Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

--Felix

From: rtcweb <[email-masked]<mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked]<mailto:[email-masked]>>

Hi,

Regards,

Christer

Thanks,

Tolga

Regards,

Albrecht

Thanks,

Tolga

Regards,

______________

Roman Shpount

---

From: tim panton <[email-masked]>
Date: Thu, 6 Aug 2015 07:52:51 -0500

So we are positing the existence of a webRTC gateway designed to support thousands of calls which does ICE and DTLS but the
designer decided deliberately to double the number of ICE sessions required and double the number of DTLS sessions (and key 
generation costs) so that they can run RTCP (over ICE and DTLS) on a separate port. In my estimation that’s one poor decision
and should not be used as the basis of this (or any) standard. 

I’d rather not support rtcp-no-mux as I see zero advantages in having it. (I know theoretically it might be possible to get
a RTCP packet through a congested net on a different port with a separate diffserv setting but that just seems so contrived).

Tim.

> On 6 Aug 2015, at 06:44, Asveren, Tolga <[email-masked]> wrote:
> 
> The issue with supporting non-rtcp-mux seems to be lack of clarity in the relevant specifications. Fixing this –regardless of the outcome of any other discussion- seems to be prudent IMHO.
>  
> Thanks,
> Tolga
>  
> From: rtcweb <[email-masked] <mailto:[email-masked]>> on behalf of Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>>
> From: Asveren, Tolga [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <[email-masked] <mailto:[email-masked]>>
> From: Schwarz, Albrecht (Albrecht) <[email-masked] <mailto:[email-masked]>>
> Cc: ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <[email-masked] <mailto:[email-masked]>>
> https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.248.57-201410-I!!PDF-E&type=items <https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-H.248.57-201410-I!!PDF-E&type=items>
> From: Asveren, Tolga [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg; Bernard Aboba; <[email-masked] <mailto:[email-masked]>>
> From: Roman Shpount [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked] <mailto:[email-masked]>>
> Cc: ext Eric Rescorla <[email-masked] <mailto:[email-masked]>>; Schwarz, Albrecht (Albrecht) <[email-masked] <mailto:[email-masked]>>; Asveren, Tolga <[email-masked] <mailto:[email-masked]>>; Christer Holmberg <[email-masked] <mailto:[email-masked]>>; Bernard Aboba <[email-masked] <mailto:[email-masked]>>; <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> On Wed, Aug 5, 2015 at 4:47 AM, Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked] <mailto:[email-masked]>> wrote:

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 6 Aug 2015 13:30:25 +0000

+1 to what Tim said.

I don’t think this discussion is really about gateways at all it is surely about whether WebRTC browsers have to support non-mux and I don’t really see any good reason why they need to.

If we had thought about this at the time we mandated DTLS-SRTP then we would have mandated rtp-mux at the same time but unfortunately we didn’t but we can fix that now.

Andy

From: rtcweb [mailto:[email-masked]] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Tim.

On 6 Aug 2015, at 06:44, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Tolga

To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; Schwarz, Albrecht (Albrecht) <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>; Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked]<mailto:[email-masked]>>

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

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

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 6 Aug 2015 13:35:28 +0000

“it is surely about whether WebRTC browsers have to support non-mux”
precisely.

If there is a need for profiling, it needs to be done as applicable to browsers. So, any clarification/statement does not belong to GW-draft but somewhere else.

BTW, “fixing” the lack of clarity about use of DTLS when rtcp-mux is not used/for DataChannel is a separate issue and should be addressed as well.

Thanks,
Tolga

From: Hutton, Andrew [mailto:[email-masked]]
Sent: Thursday, August 06, 2015 9:30 AM
To: tim panton <[email-masked]>; Asveren, Tolga <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

+1 to what Tim said.

Andy

Tim.

Thanks,
Tolga

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

Regards,
______________
Roman Shpount

---

From: Simon Perreault <[email-masked]>
Date: Thu, 06 Aug 2015 09:42:37 -0400

Le 2015-08-06 09:30, Hutton, Andrew a écrit :
> If we had thought about this at the time we mandated DTLS-SRTP then we
> would have mandated rtp-mux at the same time but unfortunately we didn’t
> but we can fix that now.

To be clear, rtcp-mux is already mandatory. It's non-mux that needs to
be made optional.

Text proposal:

> --- text.old	2015-08-06 09:37:19.000000000 -0400
> +++ text.new	2015-08-06 09:40:03.000000000 -0400
> @@ -10,5 +10,5 @@
>     Such RTP and RTCP multiplexing MUST be negotiated in the signalling
>     channel before it is used.  If SDP is used for signalling, this
>     negotiation MUST use the attributes defined in [RFC5761].  For
> -   backwards compatibility, implementations are also REQUIRED to support
> -   RTP and RTCP sent on separate transport-layer flows.
> +   backwards compatibility, implementations MAY support RTP and RTCP
> +   sent on separate transport-layer flows.

Simon

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 6 Aug 2015 14:00:40 +0000

> https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-25#section-4.5

Agreed and that's what I meant to say sorry for not being clear.

Andy

---

From: tim panton <[email-masked]>
Date: Thu, 6 Aug 2015 09:07:05 -0500

> On 6 Aug 2015, at 08:30, Hutton, Andrew <[email-masked]> wrote:
> 
> +1 to what Tim said.
>  

Sadly true, but the situation in a browser is manageable since you might expect 10 peer connections, resulting 
in a worst case of 60 UDP ports/DTLS sessions in use 
(assuming voice+video+data unbundled and RTCP-non-mux vs the 10 needed). We 
also assume a relatively well endowed CPU - devoted largely to this task.

On the gateway you’d hope to have thousands of sessions and presumably much less CPU/memory resource per channel.
So while I think it is unfortunate that browsers can do non-mux, it would be plain stupid to do that on a gateway. Do we 
really want to encourage that ?

T.

> On 6 Aug 2015, at 06:44, Asveren, Tolga <[email-masked] <mailto:[email-masked]>> wrote:
>  
> From: Wyss, Felix [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>; Asveren, Tolga <[email-masked] <mailto:[email-masked]>>; Schwarz, Albrecht (Albrecht) <[email-masked] <mailto:[email-masked]>>; Roman Shpount <[email-masked] <mailto:[email-masked]>>; Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked] <mailto:[email-masked]>>
> Cc: <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 6 Aug 2015 14:12:23 +0000

I think implementers themselves can weigh out the advantages/disadvantaged/deployment models they are targeting/etc… and decide what to support/not to support. I don’t see any issue with this as long as there is a negotiation mechanism (which there is). I don’t think the availability of negotiation is encouraging people this or that way.

Thanks,
Tolga

From: tim panton [mailto:[email-masked]]
Sent: Thursday, August 06, 2015 10:07 AM
To: Hutton, Andrew <[email-masked]>
Cc: Asveren, Tolga <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

On 6 Aug 2015, at 08:30, Hutton, Andrew <[email-masked]<mailto:[email-masked]>> wrote:

+1 to what Tim said.

T.

Andy

Tim.

Thanks,
Tolga

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

Regards,
______________
Roman Shpount

---

From: tim panton <[email-masked]>
Date: Thu, 6 Aug 2015 09:23:12 -0500

> On 6 Aug 2015, at 09:12, Asveren, Tolga <[email-masked]> wrote:
> 
> I think implementers themselves can weigh out the advantages/disadvantaged/deployment models they are way.
> 

Certainly true for a standards track document, but if the gateway draft ends up being Informational, 
I do think would be appropriate to steer implementers in the direction of sanity :-) 

Tim.

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 6 Aug 2015 14:33:20 +0000

> On Aug 6, 2015, at 9:42 AM, Simon Perreault <[email-masked]> wrote:
> 

The problem is that there’s no way in SDP for an offerer to express the difference between “I’d like to do RTCP-mux, but I’m willing to fall back to non-muxed” and “I only support RTCP-mux, and if you can’t do it please reject my offer.”

This is a general consequence of the fact that SDP has no comprehension-mandatory attributes.  (We were able to get away with this for DTLS-SRTP because the “proto” field is single-valued and thus effectively comprehension-mandatory.)

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Aug 2015 07:35:54 -0700

I feel like people are talking past each other here.

The browser vendors (at least Chrome and Firefox) want to completely remove
support for
non-mux from their code. If we make this change, that means that there will
be no way for a
browser to do non-mux and so as a practical matter we might as well simply
say that
WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, there is
similarly no
need to support non-mux, This only leaves the question of the non-WebRTC
side of
the gateway, but that's out of scope here. So, I'm not sure what you are
asking for.

WRT to the issue Jonathan raises about SDP being a negotiation, that's
true, but as
a practical matter we're already far down the road of WebRTC offerers
offering SDP
which in principle the answerer might choose not to accept but if it does
so the
connection will fail

-Ekr

On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga <[email-masked]>
wrote:

> I think implementers themselves can weigh out the
> advantages/disadvantaged/deployment models they are targeting/etc… and
> decide what to support/not to support. I don’t see any issue with this as
> long as there is a negotiation mechanism (which there is). I don’t think
> the availability of negotiation is encouraging people this or that way.
>
>
>
> Thanks,
>
> Tolga
>
>
>
> *From:* tim panton [mailto:[email-masked]]
> *Sent:* Thursday, August 06, 2015 10:07 AM
> *To:* Hutton, Andrew <[email-masked]>
> *Cc:* Asveren, Tolga <[email-masked]>; <[email-masked]> <
> [email-masked]>
>
> I don’t think this discussion is really about gateways at all it is surely
> about whether WebRTC browsers have to support non-mux and I don’t really
> see any good reason why they need to.
>
>
>
> On the gateway you’d hope to have thousands of sessions and presumably
> much less CPU/memory resource per channel.
>
> So while I think it is unfortunate that browsers can do non-mux, it would
> be plain stupid to do that on a gateway. Do we
>
> Behalf Of *tim panton
> *Sent:* 06 August 2015 13:53
> *To:* Asveren, Tolga
> *Cc:* <[email-masked]>
> So we are positing the existence of a webRTC gateway designed to support
> thousands of calls which does ICE and DTLS but the
>
> designer decided deliberately to double the number of ICE sessions
> required and double the number of DTLS sessions (and key
>
> generation costs) so that they can run RTCP (over ICE and DTLS) on a
> separate port. In my estimation that’s one poor decision
>
> I’d rather not support rtcp-no-mux as I see zero advantages in having it.
> (I know theoretically it might be possible to get
>
> a RTCP packet through a congested net on a different port with a separate
> diffserv setting but that just seems so contrived).
>
>
>
> Tim.
>
>
>
>
>
> These assumptions are not necessarily true in a universal sense (like
> almost any other assumption about different deployment models).
>
>
>
> Furthermore, and more importantly, there is nothing mandating WebRTC
> endpoints to support non-rtcp-mux. It is a negotiated functionality. Any
> entity can enforce rtcp-mux as a local policy.
>
>
>
> The issue with supporting non-rtcp-mux seems to be lack of clarity in the
> relevant specifications. Fixing this –regardless of the outcome of any
> other discussion- seems to be prudent IMHO.
>
>
>
> Thanks,
>
> Tolga
>
>
>
> *From:* Wyss, Felix [mailto:[email-masked] <[email-masked]>]
> *Sent:* Thursday, August 06, 2015 6:37 AM
> *To:* Christer Holmberg <[email-masked]>; Asveren, Tolga <
> [email-masked]>; Schwarz, Albrecht (Albrecht) <
> [email-masked]>; Roman Shpount <[email-masked]>;
> Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked]>
> Why shouldn't the gateway be required to do the mux/demux?  Making the
> WebRTC endpoints a lot more complex just so the legacy interop might
> potentially be a teeny-tiny bit easier makes no sense IMHO.  Actually, the
> gateway would not be able to do "end-to-end" pass-through anyway as legacy
> equipment will either be unencrypted or use SDES (RFC#4568) for key
> exchange.  So the gateway will have to perform DTLS-SRTP to SDES-SRTP
> transcryption--which already is way more hassle than RTP/RTCP mux/demux.
>
>
>
> --Felix
>
>
> ------------------------------
>
> *From:* rtcweb <[email-masked]> on behalf of Christer Holmberg <
> [email-masked]>
> *Sent:* Thursday, August 6, 2015 05:51
> *To:* Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount;
> No matter whether the gateway supports RTP/RTCP mux or not, there are
> cases where the legacy network/endpoints will not use RTP/RTCP mux, so I
> guess people then would want to be able to negotiate non-mux “end-to-end”,
> rather than having the gateway to demux/mux RTP and RTCP.
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* Asveren, Tolga [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* 6. elokuuta 2015 12:18
> *To:* Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe
> (Nokia - DE/Munich)
> *Cc:* ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <
> [email-masked]>
> Why should we consider 3GPP the sole "owner/user" of the term/entity
> WebRTC-GW? I think it has a much more general meaning and use in practice.
> It can refer to many different types of elements which can be deployed in
> many different environments, hence any attempt to define it
> strictly/restrict its capabilities are futile IMHO.
>
>
>
> Thanks,
>
> Tolga
>
>
> ------------------------------
>
> *From:* Schwarz, Albrecht (Albrecht) <[email-masked]>
> *Sent:* Thursday, August 6, 2015 2:44 AM
> *To:* Asveren, Tolga; Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
> *Cc:* ext Eric Rescorla; Christer Holmberg; Bernard Aboba; <
> [email-masked]>
> The concerned 3GPP WebRTC gateway (3GPP 23.334/29.334) supports already
> RTP/RTCP transport multiplexing (since 3GPP Release 12), i.e. should not be
> the limiting factor in this discussion.
>
> Don’t want to go in the 3GPP specific details, but it has nothing to do
> with the 3GPP UE-embedded WebRTC client nor any constraints by 3GPP WebRTC
> gateways.
>
>
>
> *From:* Asveren, Tolga [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Mittwoch, 5. August 2015 19:47
> *To:* Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
> *Cc:* ext Eric Rescorla; Schwarz, Albrecht (Albrecht); Christer Holmberg;
> Bernard Aboba; <[email-masked]>
> ii- Let me also add another reason why no-rtcp-mux may be needed:
> Implementation difficulties in certain GWs.
>
>
>
> Considering that there is already a negotiation mechanism for rtcp-mux
> support, that it can be de-facto mandated by the choice of browsers for
> Internet, I think what Christer/Albrecht suggested is the right way to move
> forward: provide clarifications for vague points. I don’t understand why
> lack of clarity in existing specifications should cause imposing
> restrictions. This would be akin to dropping a feature due to a bug. In
> this case, the “bug” is lack of clarity in normative specifications and it
> can be addressed by further specification.
>
>
>
> Thanks,
>
> Tolga
>
>
>
> *From:* Roman Shpount [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, August 05, 2015 12:29 PM
> *To:* Rauschenbach, Uwe (Nokia - DE/Munich) <[email-masked]>
> *Cc:* ext Eric Rescorla <[email-masked]>; Schwarz, Albrecht (Albrecht) <
> [email-masked]>; Asveren, Tolga <
> [email-masked]>; Christer Holmberg <[email-masked]>;
> Bernard Aboba <[email-masked]>; <[email-masked]> <
> [email-masked]>

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 6 Aug 2015 14:51:46 +0000

In practice –if not as initially targeted- a WebRTC-endpoint does not necessarily mean a “browser”. I completely agree with our statements about browser based deployments though. All I am saying is “Let people decide what they want to support, they are smart enough to know what a particular deployment model requires”. For example, regardless of what specifications say, non-browser equipment vendors, whose products need to interoperate with browsers, are following/implementing how Chrome/Firefox are behaving.

Thanks,
Tolga

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, August 06, 2015 10:36 AM
To: Asveren, Tolga <[email-masked]>
Cc: tim panton <[email-masked]>; Hutton, Andrew <[email-masked]>; <[email-masked]> <[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

The browser vendors (at least Chrome and Firefox) want to completely remove support for
non-mux from their code. If we make this change, that means that there will be no way for a
browser to do non-mux and so as a practical matter we might as well simply say that
WebRTC is mux and hence for the WebRTC side of a WebRTC gateway, there is similarly no
need to support non-mux, This only leaves the question of the non-WebRTC side of
the gateway, but that's out of scope here. So, I'm not sure what you are asking for.

WRT to the issue Jonathan raises about SDP being a negotiation, that's true, but as
a practical matter we're already far down the road of WebRTC offerers offering SDP
which in principle the answerer might choose not to accept but if it does so the
connection will fail

-Ekr

On Thu, Aug 6, 2015 at 7:12 AM, Asveren, Tolga <[email-masked]<mailto:[email-masked]>> wrote:
I think implementers themselves can weigh out the advantages/disadvantaged/deployment models they are targeting/etc… and decide what to support/not to support. I don’t see any issue with this as long as there is a negotiation mechanism (which there is). I don’t think the availability of negotiation is encouraging people this or that way.

Thanks,
Tolga

From: tim panton [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 06, 2015 10:07 AM
To: Hutton, Andrew <[email-masked]<mailto:[email-masked]>>
Cc: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>

+1 to what Tim said.

T.

Andy

Tim.

Thanks,
Tolga

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

Regards,
______________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Aug 2015 08:23:38 -0700

On Thu, Aug 6, 2015 at 7:51 AM, Asveren, Tolga <[email-masked]>
wrote:

> In practice –if not as initially targeted- a WebRTC-endpoint does not
> necessarily mean a “browser”. I completely agree with our statements about
> browser based deployments though. All I am saying is “Let people decide
> what they want to support, they are smart enough to know what a particular
> deployment model requires”.
>

I don't think there's any material difference between "browsers can totally
refuse
to do non-mux" and "WebRTC is mux-only", but as a browser vendor, I also
don't care if it's the first.

-Ekr

For example, regardless of what specifications say, non-browser equipment
> vendors, whose products need to interoperate with browsers, are
> following/implementing how Chrome/Firefox are behaving.
>
>
>
> Thanks,
>
> Tolga
>
>
>
> *From:* Eric Rescorla [mailto:[email-masked]]
> *Sent:* Thursday, August 06, 2015 10:36 AM
> *To:* Asveren, Tolga <[email-masked]>
> *Cc:* tim panton <[email-masked]>; Hutton, Andrew <
> [email-masked]>; <[email-masked]> <[email-masked]>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Aug 2015 16:51:30 +0000

Hi,

As an implementer, and as an IETF participant, I don't want a standard which says "look what the browsers do and follow". That will only cause trouble - especially if different browsers do different things. I want a standard, when correctly implemented, ensures interoperability with browsers (and other types of WebRTC entities).

Implementations that only need to work in specific environments can of course do whatever they want, but I don't think we consider e.g. Chrome and Firefox such implementations.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Asveren, Tolga<mailto:[email-masked]>
Sent: ‎06/‎08/‎2015 17:52
To: Eric Rescorla<mailto:[email-masked]>
Cc: <[email-masked]><mailto:[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Thanks,
Tolga

-Ekr

Thanks,
Tolga

+1 to what Tim said.

T.

Andy

Tim.

Thanks,
Tolga

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

Regards,
______________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Aug 2015 17:07:16 +0000

The SDP issue applies also to e.g. codecs: you can't mandate a codec in an SDP offer, but you can do it in a specification.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Eric Rescorla<mailto:[email-masked]>
Sent: ‎06/‎08/‎2015 17:36
To: Asveren, Tolga<mailto:[email-masked]>
Cc: <[email-masked]><mailto:[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

-Ekr

Thanks,
Tolga

+1 to what Tim said.

T.

Andy

Tim.

Thanks,
Tolga

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

Regards,
______________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Aug 2015 17:15:36 +0000

Hi Tim,

When it comes to gateways towards legacy network, in many cases there will only be audio, so even without bundle and/or rtcp-mux the number of ports won't be an issue.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: tim panton<mailto:[email-masked]>
Sent: ‎06/‎08/‎2015 17:07
To: Hutton, Andrew<mailto:[email-masked]>
Cc: <[email-masked]><mailto:[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

+1 to what Tim said.

T.

Andy

Tim.

Thanks,
Tolga

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

Regards,
______________
Roman Shpount

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 6 Aug 2015 17:35:58 +0000

On Aug 6, 2015, at 10:35 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

I’m not sure what you mean here — what are the scenarios where you can’t take a WebRTC offer, put it in a SIP INVITE, and any standards-compliant 3264 answer to the message isn’t allowed for WebRTC?

The only one I can think of currently is the answerer declining to do ICE — so that hypothetical SIP INVITE would have to have “Require: ice” (RFC 5768) in it.

If you want to say that WebRTC browsers MUST NOT support non-RTCP-mux, that’s fine (and would mean implicitly defining “Require: rtcp-mux”).  But if you want to say that browsers MAY support non-rtcp-mux, there needs to be some way for applications to discover whether the browser does indeed support it, or else there’s no point. And I believe that SDP doesn’t currently have any explicit syntax for this, and the nature of SDP means it’s somewhat hard to define.

For implicit syntax, I guess the application could check whether RTCP mux is supported by checking whether the offer contains any ICE candidates for component 2.  But this ties ICE and RTCP-mux together in IMO an unfortunate way.

-Ekr

Thanks,
Tolga

+1 to what Tim said.

T.

Andy

Tim.

Thanks,
Tolga

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

Regards,
______________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 6 Aug 2015 17:38:23 +0000

“I don't want a standard which says "look what the browsers do and follow".”
I don’t want this either.

“I want a standard, when correctly implemented, ensures interoperability with browsers (and other types of WebRTC entities).”
And isn’t this achieved mainly by rtcp-mux being a negotiated functionality? Or maybe we have a different understanding of what “interoperability” means and you are referring to what I would call “profiling”, i.e. selecting a subset of functionality from a (set of) specification(s) and mandating it on elements, which claim to be compliant to that particular profile.

Thanks,
Tolga

From: Christer Holmberg [mailto:[email-masked]]
Sent: Thursday, August 06, 2015 12:52 PM
To: Asveren, Tolga <[email-masked]>; Eric Rescorla <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

Hi,

Regards,

Christer

Thanks,
Tolga

From: Eric Rescorla [mailto:[email-masked]]
Sent: Thursday, August 06, 2015 10:36 AM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>
Cc: tim panton <[email-masked]<mailto:[email-masked]>>; Hutton, Andrew <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

-Ekr

Thanks,
Tolga

+1 to what Tim said.

T.

Andy

Tim.

Thanks,
Tolga

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

Regards,
______________
Roman Shpount

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 6 Aug 2015 10:43:21 -0700

We have "bundle-only".  It would be pretty simply to define
"rtcp-mux-only", if we think it's worth the effort.

On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox <[email-masked]> wrote:

> The problem is that there’s no way in SDP for an offerer to express the
> difference between “I’d like to do RTCP-mux, but I’m willing to fall back
> to non-muxed” and “I only support RTCP-mux, and if you can’t do it please
> reject my offer.”
>
> This is a general consequence of the fact that SDP has no
> comprehension-mandatory attributes.  (We were able to get away with this
> for DTLS-SRTP because the “proto” field is single-valued and thus
> effectively comprehension-mandatory.)

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Aug 2015 19:18:18 +0000

I don't think we should do that, or soon people would want to have "only tags" for every possible extension... :)

bundle-only makes sense,  because you can use it to ensure that you won't end up with a large number of media 5-tuples.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Peter Thatcher<mailto:[email-masked]>
Sent: ‎06/‎08/‎2015 20:44
To: Jonathan Lennox<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

We have "bundle-only".  It would be pretty simply to define "rtcp-mux-only", if we think it's worth the effort.

On Thu, Aug 6, 2015 at 7:33 AM, Jonathan Lennox <[email-masked]<mailto:[email-masked]>> wrote:

> On Aug 6, 2015, at 9:42 AM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Aug 2015 19:23:06 +0000

Hi,

Interoperability is achieved if implementations support the outcome of what is negotiated.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Asveren, Tolga<mailto:[email-masked]>
Sent: ‎06/‎08/‎2015 20:38
To: Christer Holmberg<mailto:[email-masked]>; Eric Rescorla<mailto:[email-masked]>
Cc: <[email-masked]><mailto:[email-masked]>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

Thanks,
Tolga

Hi,

Regards,

Christer

Thanks,
Tolga

-Ekr

Thanks,
Tolga

+1 to what Tim said.

T.

Andy

Tim.

Thanks,
Tolga

--Felix

Hi,

Regards,

Christer

Thanks,
Tolga

Regards,
Albrecht

Thanks,
Tolga

Regards,
______________
Roman Shpount

---

From: "Asveren, Tolga" <[email-masked]>
Date: Thu, 6 Aug 2015 19:26:18 +0000

I agree with you if you mean “no new tag/no paper enforced behavior”, i.e. let the negotiation mechanism handle the interoperability.

Thanks,
Tolga

From: rtcweb [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, August 06, 2015 3:18 PM
To: Peter Thatcher <[email-masked]>; Jonathan Lennox <[email-masked]>
Cc: [email-masked]
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 6 Aug 2015 19:59:48 +0000

My comment was only regarding a new tag. Whatever the outcome of the muc discussion is, I don't think we shall define rtcp-mux-only tags.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Asveren, Tolga<mailto:[email-masked]>
Sent: ‎06/‎08/‎2015 22:26
To: Christer Holmberg<mailto:[email-masked]>; Peter Thatcher<mailto:[email-masked]>; Jonathan Lennox<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

Thanks,
Tolga

Regards,

Christer