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

["Schwarz, Albrecht (Albrecht)" <[e-mail]>]

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:[e-mail]] 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: <[e-mail]>
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:[e-mail]]
Sent: Friday, July 31, 2015 12:03 PM
To: Rauschenbach, Uwe (Nokia - DE/Munich); Christer Holmberg; Bernard Aboba; Roman Shpount
Cc: <[e-mail]<mailto:[e-mail]>>
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:[e-mail]]
Sent: Friday, July 31, 2015 2:58 PM
To: Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; Christer Holmberg <[e-mail]<mailto:[e-mail]>>; Bernard Aboba <[e-mail]<mailto:[e-mail]>>; Roman Shpount <[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

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:[e-mail]] On Behalf Of ext Asveren, Tolga
Sent: Friday, July 31, 2015 11:49 AM
To: Christer Holmberg; Bernard Aboba; Roman Shpount
Cc: <[e-mail]<mailto:[e-mail]>>
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:[e-mail]] On Behalf Of Christer Holmberg
Sent: Friday, July 31, 2015 2:44 PM
To: Bernard Aboba <[e-mail]<mailto:[e-mail]>>; Roman Shpount <[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

Hi,

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

Regards,

Christer

From: rtcweb [mailto:[e-mail]] On Behalf Of Bernard Aboba
Sent: 31 July 2015 21:32
To: Roman Shpount <[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

On Jul 31, 2015, at 10:57, Roman Shpount <[e-mail]<mailto:[e-mail]>> 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.