Re: Streams, ICE, and signaling

On 09/06/11 11:11, Adam Bergkvist wrote:
> On 2011-09-02 23:51, Justin Uberti wrote:
>> 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?
>>
> It's true that addStream/removeStream won't perform any ICE activities in the multiplexing case, but it is convenient, from an implementation point of view, that the spec defines a separation between an internal component owned by PeerConnection responsible for performing ICE and protocol-related operations, e.g. in the constructor, and the PeerConnection JavaScript object. But I agree that ICE Agent may not be the best name (we call it PeerHandler in our implementation in lack of a better name).
In the vocabulary in the overview draft, I introduced the terms "ICE 
Agent" and "SDP Agent", where the "ICE Agent" takes care of the ICE 
state machine, and the "SDP Agent" takes care of the SDP state machine. 
This seems to be clearer than the term "ICE Agent" currently used in the 
API spec, which conflates the 2 concepts.

The term "Agent" is defined as "this term is undefined" :-) - it's a 
word we should NEVER use alone.

Received on Tuesday, 6 September 2011 10:13:22 UTC