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). /AdamReceived on Tuesday, 6 September 2011 09:11:57 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:21 UTC