[Jingle] ICE/Raw UDP Candidate IDs and Generations

Peter Saint-Andre stpeter at stpeter.im
Wed Apr 22 10:53:34 CDT 2009

Hash: SHA1

On 4/22/09 7:37 AM, Paul Witty wrote:
> I'm somewhat unsure about the use of IDs and generations for candidates
> in both ICE and Raw UDP.
> For Raw UDP, there is only one candidate per component per channel, so
> why do we need an additional identifier attribute?  

IIRC we added 'id' for consistency with ICE-UDP (so that in both cases
you could have a unique ID for referencing the candidate in the same way
for both transport methods).

> And if we want to
> switch to a different IP/Port, is that just a new generation of
> candidate with the same ID, or a new candidate with a different ID and
> generation?  I'd favour dropping either the generation or the ID
> attribute, as both seems redundant.

I agree that 'generation' is under-specified. Perhaps Justin Uberti can
explain it a bit, since I think they use it in Google Talk.

> With ICE UDP, the idea that you can modify candidates in-use mid-call by
> declaring a new generation of that candidate seems like a bad idea.  The
> whole point of ICE is to guarantee that, once candidates have been
> chosen, media can flow.  If one end can then modify the chosen
> candidate, this may no longer be true.  If a switch to a new address is
> required, this is best done by offering a new candidate to the far end,
> which will then be tested using ICE, and a switch to this new candidate
> made if appropriate.

Yes, I'd be more comfortable with saying that you send and negotiate a
new candidate rather than change the existing one mid-session.


- --
Peter Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Jingle mailing list