[Jingle] open issue: removing candidates

Justin Uberti juberti at google.com
Tue May 12 00:23:19 CDT 2009

Removal of candidates is unnecessary. The client that offered the candidate
can simply stop using it, at which point connectivity will no longer exist,
and ICE will force the use of a different candidate.
The generation attribute is used for when ICE connectivity fails on all
candidates, and a new set of candidates is needed. In this the client
allocates a new set of candidates, and the candidates from the older
generation are to be discarded upon receipt of a candidate from a newer
generation. This would be useful in the case mentioned above where you get a
new IP while the call is active.

On Wed, May 6, 2009 at 3:23 PM, Justin Karneges <justin at affinix.com> wrote:

> On Wednesday 06 May 2009 14:23:54 Olivier Crête wrote:
> > 1. The ICE negotiation is only done at the start, the current draft has
> > no provision to allow restarting it if the connection fail.
> An interesting aspect of ICE is that it adapts during the negotiation.
>  Media
> simply flows over the highest priority candidate pair.  And with XEP-176's
> variant of ICE, this negotiation essentially never ends.  This is because
> candidates can trickle in at any time, even after session-accept.
> The existence of the 'generation' attribute has me wondering if ICE-176 was
> originally intended to be able to adapt to changing network conditions
> mid-session.  For example, maybe an hour into a voice call your IP address
> suddenly changes, and so you send transport-replace.
> Maybe it's worth asking Google what they were trying to do here, since
> these
> deviations (trickling / generation) to standard ICE came from them I think.
> > I would also drop the "transport-replace" and just add more candidates.
> But yes, if we only expect to add candidates at the start of the session,
> and
> not arbitrarily throughout a session's lifetime, then I don't think we need
> candidate removal.  And in that case we can get rid of candidate modifying
> (via transport-replace).
> -Justin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/jingle/attachments/20090511/ef753d29/attachment.htm>

More information about the Jingle mailing list