Call for Consensus: ICE Transport Extensions for WebRTC

On 17.04.2018 23:19, Harald Alvestrand wrote:
> Thanks for the document review!
> 
> This call for consensus is to confirm the previous percieved consensus
> to adopt this document; if we're going to be able to instantiate
> transports without using the PeerConnection API, they have to be
> instantiated using an ICE transport or something similar, so this seems
> like an useful building block, no matter which transports we decide to
> run on top of it.

So, if I understand correctly this is the beginning of a series of
extension documents that can run on top of this ICE transport. And the
call for consensus is whether this looks good as a concept and whether
we want to adopt and go forward with specifying "building blocks" on top
of (or below) it?

Is this intended to be part of 1.0 or as part of NV?

Let me first point out: I like this approach (because I like ORTC). 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).

However, since this has been obviously borrowed from the ORTC API... why
can't we take that as a starting point since it does a good job in
providing these building blocks? I'm not sure it's a good idea to
reinvent the wheel with a third API that allows the usage of ICE
(especially since we then have three RTCIceTransport interfaces, all
slightly different). Forgive me in proposing this with my rather
idealistic (and possibly naive) mindset, but adopting ORTC and extending
on that seems more reasonable to me. And merging the two working groups
should be a possibility - in fact, the ORTC FAQ even mentions it:
https://ortc.org/faq/. Speaking as a member of both groups, I would
certainly endorse it.

> [BA] The IceTransport, once created, could be used to construct other objects,
> such as SctpTransport, DtlsTransport or QuicTransport objects. 
> 
> With respect to the interaction with RTCPeerConnection, I believe that the intent
> was to use this in scenarios not involving audio or video
> (e.g. data-transport only). 

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.

(I've CCed the ORTC mailing list since people there might want to raise
their opinion - sorry for the confusion and please only respond to the
WebRTC mailing list to keep the discussion there.)

Cheers
Lennart

Received on Wednesday, 18 April 2018 15:53:35 UTC