re: Spec question: precise meaning of PeerState and IceState

Hi Uberti:


Note: "new" has been removed, as such a state no longer exists; "waiting"/"gathering" have been merged into "starting", as gathering is not a well-defined state.Note: these represent more or less the most pessimistic view across all the streams. So “connected” means all components are connected.

As I suppose, the components means all usable ICE candidates pairs (local+remote), so I guess “connected” should not mean all components are connected, because we have no reason that PeerConnection should use all the ICE candidates pairs, we should use as few pairs as possible to save the resources. So I think “connected” means components needed by peerconnection  are all connected.


________________________________

华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]

Phone:
Fax:
Mobile:
Email:
地址：深圳市龙岗区坂田华为基地 邮编：518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

________________________________
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
发件人: Justin Uberti [mailto:juberti@google.com]
发送时间: 2012年6月16日 5:34
收件人: public-webrtc@w3.org
主题: Spec question: precise meaning of PeerState and IceState

Reviewing the latest draft, the meanings of some of the values of PeerState and IceState were unclear. In addition, there was no IceState to indicate a liveness check failure.

The following is a proposal to provide clear state information from both PeerState and IceState as well as to notify the application of liveness check failures.

If you can't see the state diagrams below, you can view them at https://docs.google.com/document/d/13TYiNSEmFkB7IeNLEJFxI0xMNk8q_LhXE_hbvFbXRTU/edit#<https://docs.google.com/document/d/13TYiNSEmFkB7IeNLEJFxI0xMNk8q_LhXE_hbvFbXRTU/edit>.
PeerState
enum PeerState { "new", "sent-offer", "received-offer", "sent-pranswer", "received-pranswer", "active", "closed"  }

"new"<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-NEW>
The object was just created, and no descriptions have been set.
"sent-offer"
A local description, of type "offer", has been supplied.
"received-offer"
A remote description, of type "offer", has been supplied.
"sent-pranswer"
A remote description of type "offer" has been supplied and a local description of type "pranswer"
has been supplied.
"received-pranswer"
A local description of type "offer" has been supplied and a remote description of type "pranswer" has been supplied.
"active" <http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-ACTIVE> (also could be called "open", "stable")
Both local and remote descriptions have been supplied, and the offer-answer exchange is complete.
"closed"<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-CLOSED>
The connection is closed.

Note: "opening" and "closing" have been removed, as they don't reflect any real-world state of the PeerConnection.

[https://docs.google.com/drawings/image?id=sgZNHkc7aH6ba4R7DjxUe2A&w=482&h=266&rev=1&ac=1]
Example:
Caller transition:

  *   new PeerConnection(): new
  *   setLocal(offer): sent-offer
  *   setRemote(pranswer): received-pranswer
  *   setRemote(answer): active
  *   close(): closed

Callee transition:

  *   new PeerConnection(): new
  *   setRemote(offer): received-offer
  *   setLocal(pranswer): sent-pranswer
  *   setLocal(answer): active
  *   close(): closed

________________________________

IceState

enum IceState { "starting", "checking", "connected", "completed","failed", "disconnected", "closed" }

"starting"
The ICE Agent is gathering addresses and/or waiting for remote candidates to be supplied.
"checking"<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-ACTIVE>
The ICE Agent is checking candidate pairs but has not yet found a connection. In addition to checking, it may also still be gathering.
"connected"<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-CLOSED>
The ICE Agent has found a usable connection for all components but is still checking other candidate pairs to see if there is a better connection. It may also still be gathering.
"completed"<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-CLOSED>
The ICE Agent has finished gathering and checking and found a connection for all components.
"failed"<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-CLOSED>
The ICE Agent is finished checking all candidate pairs and failed to find a connection for at least one component.
"disconnected"
Liveness checks have failed for one or more components.
"closed"<http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-PeerConnection-CLOSED>
The ICE Agent has shut down and is no longer responding to STUN requests.

Note: "new" has been removed, as such a state no longer exists; "waiting"/"gathering" have been merged into "starting", as gathering is not a well-defined state.
Note: these represent more or less the most pessimistic view across all the streams. So “connected” means all components are connected.
[https://docs.google.com/drawings/image?id=sxFbWPyLfQKxiSzohMYYQAw&w=617&h=391&rev=1&ac=1]
Example:
Caller/callee transition:

  *   new PeerConnection(): Starting
  *   (Starting, remote candidates received): Checking
  *   (Checking, found usable connection): Connected
  *   (Checking, gave up): Failed
  *   (Connected, finished all checks): Completed
  *   (Completed, lost connectivity): Disconnected
  *   (any state, ICE restart occurs): Starting
  *   close(): Closed