W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2011

RE: API changes to clarify ICE/SDP split, and align with MediaStream mapping

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Mon, 26 Sep 2011 17:31:05 +0200
To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <A1249B08688639468D1CB181445EE79D330AAB2822@ESESSCMS0355.eemea.ericsson.se>

I have some questions regarding the proposed changes and clean-up.

> So I suggest we make the following changes:
> - Change the role of ICE Agent to deal only with ICE
> negotiation - a process that starts after the SDP negotiation
> is complete.
> - Introduce a new state "connecting" which is the state
> between finishing SDP negotiation and finishing ICE negotiation.

What's the use case for the "connecting" state?

> - Let the ICE agent signal the PeerConnection object if
> connectivity is established, and if it's broken and can't be
> reestablished with the candidates negotiated.

This is a quite big change. It would require async error reporting which is not present in the API today. What's the suggested approach to achive this?

> - Introduce a new concept of "SDP state", which can be either
> Idle (nothing happening), Waiting (I have sent an SDP offer
> and am waiting for the SDP answer), or Glare (both sides sent
> an SDP offer simultaneously, and need to back down).

Is the SDP state exposed to the web developer or spec internal (like, e.g., the ice started flag)?

> And some cleanup:
> - Remove references to "sendonly" and "recvonly" streams.
> These are RTP terms, and we do not map media streams 1:1 to
> RTP sessions.
> - Remove, for now, all mention of "label".

I saw that Stefan and Harald started to discuss this change. What's the status, does it only deal with PeerConnection or the entire spec?

> - Remove, for now, all mention of the data channel (singular)
> from the state machinery. It's not a privilleged object.
> I have some suggested changes that I've sent separately to
> the editors on how to achieve this. But it seems to make
> sense to first post this summary on the list, and ask: Is
> this a reasonable set of changes to apply?

I think the suggested changes should be a part of this mail for everyone to see, along with use cases to motivate the changes.

Received on Monday, 26 September 2011 15:31:49 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:25 UTC