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

Replying to the points where I think it will be helpful; looks like we 
basically agree.

On 09/20/11 15:43, Stefan Håkansson LK wrote:
> 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
I concluded from that discussion that we can say that all tracks in a 
MediaStream share a CNAME, but we can't say that all tracks with the 
same CNAME go to the same MediaStream.
I think it would simplify things for at least one common case if we 
state that all tracks with the same CNAME and no label (where the 
definition of "label" isn't formalized yet, so we can't refer to it) go 
to the same MediaStream.
>
> 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 think we need to support the two-RTP-session model. We have 
discussions that seem likely to result in the option of having one RTP 
session, but until this is finalized, we can't make it mandatory (and 
may never make it mandatory).
>
>>
>> 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
Yes, the mslabel attribute isn't in any internet-draft yet, but seems 
like a reasonable suggestion.
>
>>
>> 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.
Yes; my thought at the moment is that this will generate an SDP OFFER 
listing all the codecs the implementation is willing to negotiate, but 
no SSRC-specific information.
>
>>
>> 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 Thursday, 22 September 2011 09:22:33 UTC