W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2017

Re: [webrtc-pc] When ICE restarts results in connection to a new endpoint

From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Jun 2017 09:41:56 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-311916547-1498729311-sysbot+gh@w3.org>
I think we should avoid getting seduced by the names of things, and saying "'ICE transport' sounds like 'ICE context', so there should be two of them." We can define "ICE transport" to mean whatever we want. It can be "a transport that the ICE agent provides for one component of a media session", or it can be "an ICE checklist and associated candidates for an individual ICE 'generation'". Which one we choose should be decided by practical reasons. So what are the practical implications of each choice?

**One object across restarts**

- When you apply a local description that initiates the restart:
  - Transport state changes from "completed" to "connected", or "failed" to "checking"
  - Gathering state changes to "gathering"
  - `getLocalCandidates` returns the old local candidate(s) still being used, as well as newly gathered candidates
  - `getSelectedCandidatePair` returns the existing candidate pair being used
- When a new candidate pair becomes valid:
  - `getSelectedCandidatePair` returns the new pair
  - User agent can free old candidate(s), in which case they'll no longer be returned by `getLocalCandidates`

I can't think of any problems an application could have with this. Is there something I overlooked?

**Two objects across restarts**

- When does `dtlsTransport.transport` start pointing to the new `RTCIceTransport`?
  - As soon as the ICE restart begins?
    - Then if the application needs information about the current candidate pair, it needs to remember to store the old `RTCIceTransport` handle before applying the local description.
  - Only once the new `RTCIceTransport` is `connected`?
    - Then how do you get a handle to it while it's still `checking`?
- Would require more changes to the spec, since it currently assumes "one object" everywhere.

So, unless I'm missing something, it seems like having two objects would be introducing additional complexity for no practical benefit. I could be convinced, but I'd like to hear what the benefits actually are.

GitHub Notification of comment by taylor-b
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1406#issuecomment-311916547 using your GitHub account
Received on Thursday, 29 June 2017 09:42:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:21:40 UTC