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

[Ranjit Avasarala <[e-mail]>]

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

-- 
Regards
Ranjit