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

Hello all,

I think we need to do some rather solid hacks to the PeerConnection 
object in the current API spec.
At the moment, I believe we have rough consensus that:

- A MediaStramTrack travels on a single SSRC
- A MediaStream may have tracks in multiple RTP sessions (for example 
one for video and one for audio), or in a single RTP session
- All MediaStreamTracks in a MediaStream are intended to be synchronized 
- thus should have the same CNAME
- A PeerConnection may have multiple RTP sessions and multiple MediaStreams

I don't think we've got consensus on how we mark two SSRCs with the same 
CNAME as belonging to two different MediaStreams - we can't use the SDP 
"a=label" attribute, because that attaches to RTP sessions, not media 
streams. But we need such a mechanism.

I also think the draft is quite bad at separating out SDP processing and 
ICE processing - the term "ICE Agent" seems to be used for both items 
dealing with SDP and items dealing with ICE.
Also, the data channel is still undefined, but discussions seem to be 
converging towards regarding data channels (plural) as more-or-less 
stream-like, rather than there being "only one" and having that always 
present.

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.
- 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.
- 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).

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".
- 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?

                                Harald

Received on Monday, 19 September 2011 16:44:30 UTC