Re: Phone call about ICE states

I think it's a little confusing to try to enumerate the ICE state
machines. ICE only lists
the word "machine" 6 times and "FSM once", and in the latter case,
it's referring to
a candidate pair, not to a either a media stream or a check list.

Regardless, the enumerable items here include:

0. ICE as a whole.
1. Media streams (+ check lists)
2. Components within media streams (e.g., RTP and/or RTCP)
3. Candidate pairs within components.

And the machinery for all of these things is coupled. I.e., when you start ICE
processing, you start the checks on one media stream. The candidate pairs
are checked at a certain pace within a media stream and once a component
changes state, this has an impact on other components within the stream.)
At a certain point in the checks on that stream, you start activating
other streams.
Plus, of course, when you are not ICE-lite, each STUN transaction has its own
STUN state machine.

Most of the ICE algorithm is described in terms of states of individual pairs
or various lists (Check, VALID, etc.), not in terms of an overarching state.

So, I'm not sure what people mean when they say "state machine".

-Ekr


On Thu, Sep 6, 2012 at 7:14 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> On 09/06/2012 03:23 PM, Cullen Jennings (fluffy) wrote:
>>
>> Sorry Jim … I should have been been clearer earlier.
>>
>> When we are using bundle, there is probably only one ICE machine and none
>> of this is an issue. But in the case where one end does not support bundle,
>> then we probably end up with one ICE machine per track because each one
>> needs to set up a separate DTLS/SRTP flow to the far side.
>
> To be more precise - when not using BUNDLE, we'll have one ICE state machine
> per m-line.
> One m-line can support one or more tracks, but they can only be of one type
> (either all audio or all video), which means that you'll get one mediastream
> (which usually (?) contains both audio and video) spread over at least two
> m-lines, thus at least two ICE machines.
>
> Some types of equipment much prefer to have only one track per m-line, which
> means that you could end up with as many ICE state machines as you have
> tracks.
>
> (The only time I've seen one track be spread over multiple M-lines is with
> the MST option to H.264 SVC - but that's another complication I hope we
> don't have to go into here.)
>
>
>>
>> A single ICE machine can handle multiple interfaces but it only sets up a
>> single logical flow.
>>
>> One of my goals for the design is the application does not have to worry
>> about if the far end supports bundle or not and that a app written will work
>> fine regardless of if the far end supports it or not.
>>
>>
>> On Sep 6, 2012, at 5:39 AM, Jim Barnett <Jim.Barnett@genesyslab.com>
>> wrote:
>>
>>> Justin,
>>> For my edification, what is the situation when you have a single
>>> mediastream split over multiple ICE machines?  Is that because there are
>>> multiple interfaces available?
>>>   -          Jim
>>>   From: Justin Uberti [mailto:juberti@google.com]
>>> Sent: Wednesday, September 05, 2012 5:13 PM
>>> To: Jim Barnett
>>> Cc: Cullen Jennings (fluffy); public-webrtc@w3.org
>>> Subject: Re: Phone call about ICE states
>>>   Right - I would suggest we have the single API from Option A, which I
>>> think is good enough in most cases, plus an API to get per-transport state
>>> if you need more info.
>>>   Note that tracks are not tied to ICE machines or components. You can
>>> have multiple MediaStreams on a single ICE machine, or a single MediaStream
>>> split between multiple ICE machines.
>>>
>>> On Wed, Sep 5, 2012 at 2:05 PM, Jim Barnett <Jim.Barnett@genesyslab.com>
>>> wrote:
>>> Justin,
>>> That’s what I was wondering about too.  (Could the transport objects be
>>> tied to tracks?)  You could fire events for the state changes on each
>>> transport object/state machine, and still have a very simple higher-level
>>> conbined state and query API (as in Option B) at the PeerConnection level.
>>> Developers who only wanted to know when things got started and when
>>> everything got finished could use the PeerConnection API.  Developers who
>>> wanted to manage at a lower level could use the events at the individual ICE
>>> machine level.
>>>   -          Jim
>>>
>>>   From: Justin Uberti [mailto:juberti@google.com]
>>> Sent: Wednesday, September 05, 2012 5:01 PM
>>> To: Jim Barnett
>>> Cc: Cullen Jennings (fluffy); public-webrtc@w3.org
>>> Subject: Re: Phone call about ICE states
>>>   I'll be there.
>>>   I'd also like to propose an Option C, where we have a list of read-only
>>> transport objects (1 for each machine), where each transport has a state as
>>> in Option A. This would avoid the issues you mention with Option A.
>>>
>>> On Wed, Sep 5, 2012 at 1:54 PM, Jim Barnett <Jim.Barnett@genesyslab.com>
>>> wrote:
>>> Cullen,
>>>    Just asking out of curiosity:  when you have multiple ICE state
>>> machines, do they correspond to the different tracks in the
>>> PeerConnection, or is the mapping more complex than that?
>>>
>>> - Jim
>>>
>>> -----Original Message-----
>>> From: Cullen Jennings (fluffy) [mailto:fluffy@cisco.com]
>>> Sent: Wednesday, September 05, 2012 3:31 PM
>>> To: public-webrtc@w3.org
>>> Subject: Phone call about ICE states
>>>
>>>
>>> I want to talk about ICE states a bit as this has been slowing me down.
>>> I set up a bridge for tomorrow at 8 am pacific.  If anyone wants to join
>>> me, I want to talk about the two proposals in the attached slides. If no
>>> one cares, I will just talk to my imaginary friends about making
>>> imaginary progress.
>>>
>>>
>>> Topic: WebRTC ICE State Reporting
>>> Date: Thursday, September 6, 2012
>>> Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00) Meeting
>>> Number: 207 963 719 Meeting Password: w3c
>>>
>>>
>>> -------------------------------------------------------
>>> To join the online meeting (Now from mobile devices!)
>>> -------------------------------------------------------
>>> 1. Go to
>>> https://cisco.webex.com/ciscosales/j.php?ED=204263572&UID=0&PW=NNzhiMzA1
>>> ZDI5&RT=MiM0
>>> 2. Enter your name and email address.
>>> 3. Enter the meeting password: w3c
>>> 4. Click "Join Now".
>>>
>>> To view in other time zones or languages, please click the link:
>>> https://cisco.webex.com/ciscosales/j.php?ED=204263572&UID=0&PW=NNzhiMzA1
>>> ZDI5&ORT=MiM0
>>>
>>> ----------------------------------------------------------------
>>> ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
>>> ----------------------------------------------------------------
>>>
>>> The affected toll free numbers are: (866) 432-9903 for the San
>>> Jose/Milpitas area and (866) 349-3520 for the RTP area.
>>>
>>> Please dial the local access number for your area from the list below:
>>> - San Jose/Milpitas (408) area: 525-6800
>>> - RTP (919) area: 392-3330
>>>
>>> -------------------------------------------------------
>>> To join the teleconference only
>>> -------------------------------------------------------
>>> 1. Dial into Cisco WebEx (view all Global Access Numbers at
>>> http://cisco.com/en/US/about/doing_business/conferencing/index.html
>>> 2. Follow the prompts to enter the Meeting Number (listed above) or
>>> Access Code followed by the # sign.
>>>
>>> San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
>>>
>>> US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
>>>
>>> India: +91.80.4350.1111 Germany: +49.619.6773.9002
>>>
>>> Japan: +81.3.5763.9394 China: +86.10.8515.5666
>>>
>>>
>>>
>>> To add this meeting to your calendar program (for example Microsoft
>>> Outlook), click this link:
>>> https://cisco.webex.com/ciscosales/j.php?ED=204263572&UID=0&ICS=MI&LD=1&
>>> RD=2&ST=1&SHA2=5j5w75EhhDNyDcyfDZrKGY3Wjwpx8bikjAOdbAjI4xw=&RT=MiM0
>>>
>>>
>>
>>
>
>

Received on Thursday, 6 September 2012 14:48:01 UTC