- 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>
Hi 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. BR Adam
Received on Monday, 26 September 2011 15:31:49 UTC