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

[Eric Rescorla <[e-mail]>]

No. That's the gateway's job.

-Ekr


On Wed, Aug 5, 2015 at 8:17 AM, Ranjit Avasarala <[e-mail]>
wrote:

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