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

RE: Phone call about ICE states

From: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>
Date: Tue, 11 Sep 2012 03:55:42 +0000
To: Justin Uberti <juberti@google.com>
CC: Jim Barnett <Jim.Barnett@genesyslab.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <311BE885E0DA8D4BB369A037CF5B64A72E81F35E@ORSMSX102.amr.corp.intel.com>
Justin:

I just reread the JSEP RFC and I now understand your state diagram better. Thanks for your patience.

Cheers --
ganesh

From: Justin Uberti [mailto:juberti@google.com]
Sent: Monday, September 10, 2012 11:16 AM
To: Venkatesan, Ganesh
Cc: Jim Barnett; Cullen Jennings (fluffy); public-webrtc@w3.org
Subject: Re: Phone call about ICE states

Ganesh,

Not sure I follow you.

Active goes to "sent offer" upon a setLocalDescription call with a SessionDescription of type "offer". "sent offer" goes back to "active", upon a setRemoteDescription call with a SessionDescription of type "answer.

Note though that PeerState indicates signaling states, not the ICE states that were the original topic of this email thread.

On Mon, Sep 10, 2012 at 9:40 AM, Venkatesan, Ganesh <ganesh.venkatesan@intel.com<mailto:ganesh.venkatesan@intel.com>> wrote:
Hello Justin:

Thanks for this work.

I am a little confused about transitions from “Active” to “Sent Offer” and “Received Offer” States? Could you help me understand the rationale behind these states? Also, under what conditions would the transition from “Received Offer” to “Active” and “Sent Offer” to “Active” occur?

Based on what I understand, the transitions identified above muse be removed from the state diagram.

Cheers --
ganesh

From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com<mailto:Jim.Barnett@genesyslab.com>]
Sent: Monday, September 10, 2012 7:05 AM
To: Justin Uberti; Cullen Jennings (fluffy)
Cc: public-webrtc@w3.org<mailto:public-webrtc@w3.org>
Subject: RE: Phone call about ICE states

Justin,
A question about the PeerConnection callbacks on the offering side.  The offering side would initially call SetLocal and move to state ‘sent-offer’.    At some point it gets a response, calls SetRemote and moves to ‘active’  (for simplicity I’m leaving out pranswer.)  The SetRemote should cause ‘onaddstream’ to fire, and since both sides have accepted the description,  addTrack should follow.  A) is that correct?  B) if there are multiple streams, does ‘onaddstream’ fire for all of them before any ‘addTrack’, or can the two be interleaved?

Conversely, on the receiving side,  ‘onnaddstream’ would fire when the offer was received and SetRemote was called.  Would ‘addTrack’ then fire when the receiving side accepted the offer by calling SetLocal?

Thanks,
Jim

From: Justin Uberti [mailto:juberti@google.com]<mailto:[mailto:juberti@google.com]>
Sent: Monday, September 10, 2012 2:26 AM
To: Cullen Jennings (fluffy)
Cc: public-webrtc@w3.org<mailto:public-webrtc@w3.org>
Subject: Re: Phone call about ICE states

I updated my IceState proposal (which corresponds to Option A, or the high-level part of Option C) based on the points raised at Thursday's discussions. Please take a look at the "IceState proposal" section in the attached document, and let me know what you think.

On Thu, Sep 6, 2012 at 7:55 AM, Cullen Jennings (fluffy) <fluffy@cisco.com<mailto:fluffy@cisco.com>> wrote:

Updated slides with Justin Option C added ..


Received on Tuesday, 11 September 2012 03:56:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 11 September 2012 03:56:13 GMT