W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2011

RE: Streams, ICE, and signaling

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 6 Sep 2011 11:11:31 +0200
To: Justin Uberti <juberti@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, webrtc-webkit <webrtc-webkit@google.com>
Message-ID: <A1249B08688639468D1CB181445EE79D26E1C663D9@ESESSCMS0355.eemea.ericsson.se>
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).

/Adam
Received on Tuesday, 6 September 2011 09:11:57 UTC

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