[Jingle] open issue: removing candidates

[Justin Karneges]

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