Re: Call for Consensus: ICE Transport Extensions for WebRTC

On 04/18/2018 05:53 PM, Lennart Grahl wrote:
> 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?

For all extension documents, I think it makes sense to regard them as
part of NV.

Just a reminder: Publishing a FPWD doesn't commit the WG to the
technology described in the draft.
It's still subject to working group consensus.
>
> 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.

The charter says that this is what we're doing:

The Working Group will take the work done by the ORTC Community Group as
a source of input, and when contemplating similar APIs in the Working
Group, make efforts to align with the ORTC CG on API methodologies and
nomenclature.

>
>> [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 hope that we can specify RTP to run over the ICETransport too. I think
there would be greater clarity in our specification if we specified an
RTP transport that used ICE/DTLStransport as its substrate. But we don't
have drafts for that one yet.

I think we're in violent agreement more than we disagree here.

>
> (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 16:44:33 UTC