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

From: Veera Andersson <[email-masked]>
Date: Tue, 04 Aug 2009 12:53:01 +0300

Hi,

Actually the described case is taken care of by the error response code.

Regards,
Veera

Veera Andersson wrote:
> 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
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic