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

["Asveren, Tolga" <[e-mail]>]

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]>; Christer Holmberg <[e-mail]>; Bernard Aboba <[e-mail]>; Roman Shpount <[e-mail]>
Cc: <[e-mail]> <[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.