Re: [rtcweb] What the gateway draft should say about mux/non-mux

["Hutton, Andrew" <[e-mail]>]

+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:[e-mail]] On Behalf Of tim panton
Sent: 06 August 2015 13:53
To: Asveren, Tolga
Cc: <[e-mail]>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

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 <[e-mail]<mailto:[e-mail]>> wrote:

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:[e-mail]]
Sent: Thursday, August 06, 2015 6:37 AM
To: Christer Holmberg <[e-mail]<mailto:[e-mail]>>; Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; Schwarz, Albrecht (Albrecht) <[e-mail]<mailto:[e-mail]>>; Roman Shpount <[e-mail]<mailto:[e-mail]>>; Rauschenbach, Uwe (Nokia - DE/Munich) <[e-mail]<mailto:[e-mail]>>
Cc: <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

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 <[e-mail]<mailto:[e-mail]>> on behalf of Christer Holmberg <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 6, 2015 05:51
To: Asveren, Tolga; Schwarz, Albrecht (Albrecht); Roman Shpount; Rauschenbach, Uwe (Nokia - DE/Munich)
Cc: <[e-mail]<mailto:[e-mail]>>
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

From: Asveren, Tolga [mailto:[e-mail]]
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; <[e-mail]<mailto:[e-mail]>>
Subject: Re: [rtcweb] What the gateway draft should say about mux/non-mux

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

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
>1. Using different QOS settings for RTCP vs RTP
>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:[e-mail]]
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; <[e-mail]<mailto:[e-mail]>>
Subject: RE: [rtcweb] What the gateway draft should say about mux/non-mux

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:[e-mail]]
Sent: Wednesday, August 05, 2015 12:29 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich) <[e-mail]<mailto:[e-mail]>>
Cc: ext Eric Rescorla <[e-mail]<mailto:[e-mail]>>; Schwarz, Albrecht (Albrecht) <[e-mail]<mailto:[e-mail]>>; Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; Christer Holmberg <[e-mail]<mailto:[e-mail]>>; Bernard Aboba <[e-mail]<mailto:[e-mail]>>; <[e-mail]<mailto:[e-mail]>> <[e-mail]<mailto:[e-mail]>>
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) <[e-mail]<mailto:[e-mail]>> 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:

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
_______________________________________________
rtcweb mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtcweb