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

On 09/26/2011 05:31 PM, Adam Bergkvist wrote:
> 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?
Showing that we're now in ICE negotiation rather than in SDP negotation.
If state sticks in something before connection, it can be valuable to 
know how far we got.
>> - 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?
Why would it require async error reporting? This is internal to the 
PeerConnection implementation; all that happens is that the 
PeerConnection changes state, and calls the callbacks already defined.
>> - 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)?
I don't know. I know that we need to keep track of the state internally; 
there might be a need to observe it externally; if so, we can expose it. 
I suggest keeping it invisible for now.
>> 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?
I think the resolution is that a MediaStream has to have a concept of 
"label", that can be communicated between but we don't know who assigns 
it yet, or whether it has a format or is an opaque ID.
>> - 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.
When I took this proposal to the editors a week ago, the editors 
proposed that I send a more high level description to the mailing list, 
because a diff would be hard to read; I did so.
> Adam

Received on Monday, 26 September 2011 15:50:47 UTC