W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: Spec question: precise meaning of PeerState and IceState

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Fri, 22 Jun 2012 15:58:05 +0000
To: Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <957D01C1-5A8D-425F-A20C-53E33FD9FDD3@cisco.com>

On Jun 17, 2012, at 7:30 , Harald Alvestrand wrote:

> On 06/17/2012 08:33 AM, Sunyang (Eric) wrote:
>> Hi Uberti:
>> Note: "new" has been removed, as such a state no longer exists; "waiting"/"gathering" have been merged into "starting", as gathering is not a well-defined state.Note: these represent more or less the most pessimistic view across all the streams. So “connected” means all components are connected.
>> As I suppose, the components means all usable ICE candidates pairs (local+remote), so I guess “connected” should not mean all components are connected, because we have no reason that PeerConnection should use all the ICE candidates pairs, we should use as few pairs as possible to save the resources. So I think “connected” means components needed by peerconnection  are all connected.
> No, that's not what "component" means in this context.
> If we have a single RTP session, with RTP + RTCP multiplexed, we have one component.
> If we have a single RTP session, but RTP and RTCP use different ports, we have two components.
> If we have two RTP sessions (one for audio and one for video), and RTP and RTCP use different ports, we have four components.
> We need to have at least one working pair connected for each component.
> The definition is in RFC 5245 (ICE) section 3:
>  Component:  A component is a piece of a media stream requiring a
>      single transport address; a media stream may require multiple
>      components, each of which has to work for the media stream as a
>      whole to work.  For media streams based on RTP, there are two
>      components per media stream -- one for RTP, and one for RTCP.
> (this was written pre RTP/RTCP multiplexing, which is RFC 5761, and pre BUNDLE)
>                     Harald

Harald, agree with you but I think I agree with the fundamentals of what Justin is trying to say. The connected state is not entered until every media/data stream has something it can successfully flow over. So in the multiplexed case, that might be a single thing while in the other cases there might be a bunch of ICE components that have to be successfully connected before it can work. Any suggestion on how we should phrase the text describing when this state is entered.
Received on Friday, 22 June 2012 15:58:35 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC