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

[Eric Rescorla <[e-mail]>]

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

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

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,
>
> 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]
> <[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]>
> *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] <[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] <[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]>
> *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] <[e-mail]>] *On
> Behalf Of *Christer Holmberg
> *Sent:* Friday, July 31, 2015 2:44 PM
> *To:* 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
>
>
>
> 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] <[e-mail]>] *On
> Behalf Of *Bernard Aboba
> *Sent:* 31 July 2015 21:32
> *To:* Roman Shpount <[e-mail]>
> *Cc:* <[e-mail]> <[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]> 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.
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>