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

In a contributor role,

I largely agree. Splitting up ICE and SDP o/a makes sense.

Detailed comments in-line.

Stefan
On 2011-09-19 18:44, Harald Alvestrand wrote:
> 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 also think that there was a discussion last week leading to that all
MediaStreamTracks (and MediaStreams) originating from a browser instance 
should (usually) share CNAME.
The discussion started at
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01079.html

And maybe there can be max two RTP sessions: either all media tracks go
in one session, or there are two sessions (one audio, one video). I 
guess this is for further discussion.

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

There is a proposal in
http://www.ietf.org/mail-archive/web/rtcweb/current/msg01079.html to use 
the ssrc attribute in combination with mslabel
I agree there is not consensus, but at least a concrete proposal

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

I agree to this.

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

Agree.

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

Sounds reasonable.

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

Agree. This should not be part of this spec.

> - Remove, for now, all mention of "label".

(I assume that you mean from the PeerConnection section only) Yes. That
is not needed. As what becomes available at the receiving side is a
MediaStream, and a MediaStream object has a label attribute it is
obvious that the received stream will have a label. Maybe it should be
clarified that it is the same label as the MediaStream that was added at 
the sending side has.

> - Remove, for now, all mention of the data channel (singular) from the
> state machinery. It's not a privilleged object.

Right. We need to define it before putting it back. But I think it must
be clear the the PeerConnection will establish a connection even if no
streams have been added to it.

>
> 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 Tuesday, 20 September 2011 13:44:27 UTC