Re: Call for Consensus: ICE Transport Extensions for WebRTC

On 18.04.2018 22:55, Bernard Aboba wrote:
> Lennar said: 
> 
> "So, if I understand correctly this is the beginning of a series of
> extension documents that can run on top of this ICE transport."
> 
> [BA] The ICE Transport Extension was developed to enable 
> data transport scenarios where no A/V was negotiated (if an RTCPeerConnection had already been
> constructed, then a QuicTransport or DtlsTransport/SctpTransport could be constructed from the
> existing IceTransport). 
> 
> "Is this intended to be part of 1.0 or as part of NV?"
> 
> [BA] The ICE Transport Extension is compatible with WebRTC 1.0, which does not
> have an IceGatherer object (or a SliceTransport, for that matter). 
> 
> Whether NV should combine the IceTransport/IceGatherer as in this
> extension, keep them separate as in ORTC or go for a different model (such as SliceTransport)
> merits a separate discussion in my opinion, since the answer may depend on the NV use
> cases that need to be supported.

Mh, so, Harald says it's likely part of NV but you say it's not part of
NV? :)

Let me summarise my opinion. I'm uncertain whether I'm in favour of
adopting this or not, although I generally very much like the concept:
Without any further extension this ICE transport is too abstract for my
taste. Maybe it could be bundled with how to construct an DTLS and SCTP
transport and data channels on top of it. Then it's clear what one can
do with it and especially how it's supposed to work API-wise. If it's
intended to be part of NV, then I would agree with you that it's too
early and we should wait for the use cases we come up with.

> "It could be a bit more low-level (thinking of the `SliceTransport` Peter
> mentioned a while ago) but that can be solved later (possibly a
> compatible interface that both implement)."
> 
> [BA] The ORTC design utilizes distinct IceGatherer and IceTransport objects
> in order to support parallel forking and peer-to-peer use cases. However, at TPAC
> other use cases and potential ICE protocol changes were discussed.  
> 
> "I'm not sure it's a good idea to nreinvent the wheel with a third API that allows the usage of ICE
> (especially since we then have three RTCIceTransport interfaces, all
> slightly different).... Adopting ORTC and extending on that seems more reasonable to me."
> 
> [BA] I would agree that there is no need to reinvent the wheel if the NV use cases end up being
> similar to the ORTC use cases (e.g. same as WebRTC 1.0 plus parallel forking and support for
> scalable video coding). 
> 
> However, there have been some NV use cases discussed (such as access to raw media and
> support for ICE enhancements) that could require modifications to the ORTC design.

Agree. But I think we should strongly consider modifying the ORTC API
until it fits our use cases and only roll our own API if it's
fundamentally incompatible with the ORTC design principle.

> "I think it would be a lost opportunity to not be able to run audio/video
> on top of this. But I guess we don't need to discuss that now."
> 
> [BA] If the intent is to construct an IceTransport and use it alongside a PeerConnection, we'd
> probably need an understanding of how that would affect the SDP.  

I've started running... ;)

Cheers
Lennart

Received on Saturday, 28 April 2018 13:51:37 UTC