W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2015

Re: Specify the negotiationneeded event

From: Justin Uberti <juberti@google.com>
Date: Wed, 25 Feb 2015 23:14:38 -0800
Message-ID: <CAOJ7v-0xD4iECLML2qGqZ0SEN4Ri+cvJSP28dR5yasfm_LaJkQ@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>
Cc: Cullen Jennings <fluffy@cisco.com>, Martin Thomson <martin.thomson@gmail.com>, public-webrtc <public-webrtc@w3.org>
PTAL at https://github.com/w3c/webrtc-pc/pull/186

On Wed, Feb 18, 2015 at 9:23 AM, Justin Uberti <juberti@google.com> wrote:

>
>
> On Wed, Feb 18, 2015 at 2:23 AM, Adam Bergkvist <
> adam.bergkvist@ericsson.com> wrote:
>
>> On 13/02/15 01:25, Justin Uberti wrote:
>> > How about this version:
>> >
>> > The PC is considered 'dirty' when:
>> > * A track is added, removed, or stopped (local or remote).
>> > * A property that requires signaling is mutated on RTCRtpSender (e.g.
>> > .active).
>> > * A datachannel is created, and the association does not exist.
>> >
>> > 'dirty' is cleared when:
>> > * setLocalDescription is called (either offer or answer), and the # of
>> > tracks/SCTP association in the supplied description is compatible with
>> > the tracks/datachannels in existence on the PeerConnection.
>>
>> What happens if the 'dirty' state is not cleared when setLocal is done?
>>
>
> Stays dirty, and a new onNN is fired when the state returns to stable.
>
>>
>> > For simplicity, 'dirty' is not cleared by any other operations, such as
>> > addTrack(X) followed by removeTrack(X). *We should accept that it is far
>> > better to fire too many onNN events than too few*; spurious onNNs are
>> > essentially harmless, whereas missing onNNs may be fatal.
>> >
>> > When the PC is marked as 'dirty', and it is not already 'dirty':
>> > * if the signaling state is 'stable', a task to fire onNN is scheduled.
>> > * otherwise, wait for the state to return to 'stable', and then fire
>> onNN.
>>
>>
>
Received on Thursday, 26 February 2015 07:15:25 UTC

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