Re: Spec question: precise meaning of PeerState and IceState

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