Subject: [MMUSIC] Issue with ICE controlling/controlled tie-breaker

From: Veera Andersson <[email-masked]>
Date: Thu, 23 Jul 2009 13:36:37 +0300

Hi,

I have a question concerning ICE that came up while implementing an ICE 
prototype. I think it is possible for two agents to end up with 
different selected pairs if both agents are initially in controlling 
role. I mean, regardless of having detecting and repairing of role 
conflicts implemented.

This could happen in a situation where it takes a long time for an ICE 
answer, from the agent with a lower tie-breaker value, to the initial 
ICE offer to arrive. For the peer (with lower tie-breaker) to realize to 
change its role, it needs to receive a Binding request (with 
ICE-CONTROLLING attribute) from the other endpoint. But this might not 
happen in time, since the agent with the higher tie-breaker value is 
still waiting for the answer to its initial ICE offer to arrive in order 
to start Binding requests. Mean while, it is responding to requests it 
receives.

In such a case, the agent with the lower tie-breaker value might already 
nominate some pair before the other endpoint has started its checks. 
When the endpoint with higher tie-breaker finally starts checks, it may 
(and is likely to) end up nominating another pair since it doesn't 
accept nomination from the lower tie-breaker peer.

Is this perhaps a feature of the specification or is there some other 
mechanism that covers this case?

In case there is not, at least adding the controlling/controlled 
attribute also to the Binding response messages would solve the problem.

Regards,
Veera