ICE freezing and Bandwidth Estimation

In the draft F2F agenda sent to the mailing list yesterday, I have included a session on ICE freezing and Bandwidth Estimation. 

These topics might seem somewhat obscure, so an explanation of their potential relevance to "WebRTC NV" is in order. 

One of the implications of designing an NV API that does not utilize SDP is that the information currently provided by SDP will not be available unless API surface is added to explicitly provide that information. 

In the design of the ORTC API, the IceTransportController object was defined in order to enable the operation of ICE freezing and Bandwidth Estimation in the absence of SDP:
http://draft.ortc.org/#rtcicetransportcontroller*

By ordering IceTransport objects in a list, the IceTransportController can provide some of the same information for use in ICE freezing as is available in SDP with respect to ordering of m-lines and bundle groups. 

As far as I know, there is only a single implementation of this (ORTC lib). 

The other use of the IceTransportController was for Bandwidth Estimation.  Here the goal was to group together related IceTransports for the purpose of a group bandwidth estimate. Something along those lines (though grouping IceGatherer objects instead of IceTransports) was implemented in Edge ORTC.  

Since bandwidth usage is more directly related to RTP streams than to IceTransports, there has also been discussion of a potential RtpController object:
https://github.com/w3c/ortc/issues/603

Given that this topic has generated inconsistent implementations and differing points of view, some discussion might be worthwhile (assuming that the group is willing and we can find volunteers to lead it).

Received on Thursday, 17 May 2018 15:54:36 UTC