Re: Streams, ICE, and signaling

On 09/09/11 00:18, Prakash wrote:
> Slightly related to the original email. The same document also talks
> about readyStates which have values like NEGOTIATING, OPEN, CLOSE etc
> with callbacks like onopen. What is this correlated to? If we have
> multiple RTP sessions, how do we differentiate which session was
> closed or open?
The way our current thinking goes (where MediaStream = cname, and 
MediaStreamTrack = ssrc), the user should not need to know or care which 
RTP sessions are closed or open.

When a MediaStream stops getting data, and/or is removed from the 
SDP-mediated maps (there are 3 states to consider, I'm not sure when the 
event should be thrown), a "close" event should occur on the MediaStream.

When all RTP sessions are closed, so that we've lost contact with the 
other end, some event should be thrown at the PeerConnection object to 
indicate this.

That's what I think should happen - YMMV.
> On Fri, Sep 2, 2011 at 2:51 PM, Justin Uberti<juberti@google.com>  wrote:
>> The existing specification indciates that MediaStreams have a 1:1
>> relationship with ICE transports, as evidenced by the mechanism of signaling
>> stream removal by sending an ICE candidate with port=0. Given the desire to
>> multiplex multiple sources and content types over a single RTP session and
>> ICE transport, this association is limiting. While ICE exists as an
>> underlying transport protocol, and requires information that must be
>> exchanged in signaling, higher level functions such as addition or removal
>> of streams should not affect ICE directly. These occurrences may require ICE
>> to establish additional connections, if multiplexing is not enabled, but
>> that detail does not need to be exposed from the API. Below I propose a
>> different way of handling streams in PeerConnection.
>> As a background for my proposal, the following associations are assumed
>> (paraphrasing a similar ontology from Harald):
>> - PeerConnection holds 1-N MediaStreams, each containing 1-N MediaTracks.
>> - Tracks within a MediaStream are synchronized, and therefore share a single
>> RTCP CNAME when sent as RTP.
>> - MediaStreams therefore have a 1:1 association with CNAMEs. This CNAME may
>> be exposed to the application, to let it identify streams.
>> - MediaTracks are identified by 1-N SSRCs; this number is typically 1, but
>> may be larger in the cases where SSRC grouping, as outlined in RFC 5576, is
>> employed.
>> - Depending on whether RTP muxing is enabled or not, PeerConnection will use
>> 1-N RTP sessions. This is an internal detail, and does not need to be
>> exposed to the application.
>> - RTP sessions are always sendrecv; individual sources are, naturally,
>> sendonly.
>>  From these associations, we can say the following:
>> - A MediaStream's label directly corresponds to the CNAME used for its
>> tracks. This CNAME should follow the short-term CNAME rules from RFC 6222.
>> - Addition of a MediaStream, or MediaTrack to a MediaStream, causes new SDP
>> to be generated according to RFC 5576, indicating the SSRC and CNAME of the
>> new track.
>> - Removal of a MediaStream results in a similar new SDP.
>> - Demux of incoming RTP into the appropriate tracks is done by SSRC, and the
>> associations are known due to the above signaling.
>> - This mechanism works identically regardless of whether we have separate
>> RTP sessions for each content type, or 1 single multiplexing session.
>> This mechanism not only simplifies multiplexing audio and video over a
>> single RTP session, but it also cleanly allows for multiplexing multiple
>> participants (i.e. in a centralized conferencing scenario).
>> I also think we should remove the notion of "ICE Agents" from the spec, at
>> least in regards to stream processing, because ICE is no longer involved in
>> these activities. It probably makes more sense to simply refer to the
>> PeerConnection itself.
>> e.g. changing
>> "When a PeerConnection ICE Agent finds that a stream from the remote peer
>> has been removed (its port has been set to zero in a media description sent
>> on the signaling channel), the user agent must follow these steps:"
>> to
>> "When a PeerConnection finds that a stream from the remote peer has been
>> removed (it has received a signaling message that no longer contains the
>> CNAME that identifies this stream), the user agent must follow these
>> steps:"
>> Thoughts?
>>
>

Received on Friday, 9 September 2011 07:45:20 UTC