[Jingle] ICE/Raw UDP Candidate IDs and Generations
stpeter at stpeter.im
Wed Apr 22 10:53:34 CDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Jingle