Subject: Tie breaker (was RE: [MMUSIC] Re: ICE micro-lite for support of I Pv6 transition)

From: "Elwell, John" <[email-masked]>
Date: Wed, 11 Apr 2007 08:36:57 +0100

Jonathan,

Looking again at ice-15, it doesn't really explain why we need the tie
breaker - it just says "in unusual cases". The basic rule is that the
controlling role is assigned to the sender of the offer. This is true also
for 3PCC. Well, OK, I could imagine there are some 3PCC implementations that
break this, but I think there are other things in SDP that are broken if you
start mixing up offers and answers. For example, embedded MIKEY using
a=key-mgmt, or the recent SDP capability negotiation. We have not built
anything into those mechanisms to help cater for rogue 3PCC implementations,
so why is it necessary to do so for ICE?

John

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: 09 April 2007 14:14
> To: Guylain Lavoie
> Cc: [email-masked]
> Subject: Re: [MMUSIC] Re: ICE micro-lite for support of IPv6 
> transition
> 
> inline.
> 
> Guylain Lavoie wrote:
> 
> 
> > By the way, can someone more knowledgeable than me explain 
> why ICE-lite
> > cannot include more than one host candidate per component 
> when he knows
> > that both are always accessible? Is this an arbitrary decision or is
> > there something that does not allow this?
> 
> It is most certainly NOT arbitrary. ICE-lite falls apart when 
> you do this.
> 
> The reason is as follows. Remember that an important part of ICE 
> processing is this 'fix-up' operation, whereby, if the candidate 
> selected by ICE is not matching the m/c-line, the controlling 
> agent does 
> an updated offer to make them match. This was deemed important for 
> backwards compatibility with lots of middleboxes that want to 
> see media 
> sent to the target of the m/c-line.
> 
> With ice-lite, since there is only ever one candidate, it 
> always matches 
> the m/c-line, and so the agent never needs to do fix-ups.
> 
> Now, if you allow multiple candidates, what happens if both sides are 
> ice-lite, but a candidate is selected that does NOT match the 
> m/c-line? 
> Well, now you need to do the fix-up re-invite. So, you'd now lose the 
> property that, when both sides are ice-lite, you basically 
> don't do ICE 
> at all. You'd have to do some third subset of ICE.
> 
> So, let us continue down this line of thought. What if we 
> specify that? 
> What if, with ice-lite, you still do some kind of third mode 
> when both 
> sides are ice-lite, so that the fix-up reinvite is done? 
> Well, to do the 
> fix-up, you need to select a controlling and controlled node. 
> Folks will 
> recall that, in certain 3pcc cases, it is possible for both agents to 
> think they are controlled, or both to think they are controlling. THe 
> fix for this in ice-15 is to use flags in the STUN checks 
> themselves to 
> sort out this ambiguity. However, we wouldn't be having any 
> checks here, 
> so we'd have an unresolved ambiguity.
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> Cisco Fellow                                   Parsippany, NJ 
> 07054-2711
> Cisco Systems
> [email-masked]                              FAX:   (973) 952-5050
> http://www.jdrosen.net                         PHONE: (973) 952-5000
> http://www.cisco.com
> 
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/mmusic
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic