Subject: RE: [MMUSIC] ICE-12, SBCs and hotel ALGs

From: "Kevin Johns" <[email-masked]>
Date: Fri, 27 Oct 2006 10:40:45 -0600

I agree as well. This is not something I would like to see solved by
ICE.

Thanks
Kevin

-----Original Message-----
From: Francois Audet [mailto:[email-masked]] 
Sent: Thursday, October 26, 2006 6:42 PM
To: Jonathan Rosenberg; IETF MMUSIC WG
Subject: RE: [MMUSIC] ICE-12, SBCs and hotel ALGs

I agree with your conclusion.

Your last paragraph is exaclty what I've been saying before.

Thanks. 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, October 26, 2006 2:40 PM
> To: IETF MMUSIC WG
> Subject: [MMUSIC] ICE-12, SBCs and hotel ALGs
> 
> A big topic of discussion on the list and in our calls has been what 
> ICE should do in the presence of SBCs and hotel-ALG and similar beasts

> which try and 'help' but get in the way.
> 
> I had proposed a solution on the list here:
> http://www1.ietf.org/mail-archive/web/mmusic/current/msg04696.html
> 
> THe essential idea was that ICE would look for the m/c-line to not 
> match any existing candidates, and if not, treat it as a high priority

> candidate. If it works, use it, if not, fall back.
> 
> This sounds great in theory, but when I got down to writing it up, 
> some issues arose.
> 
> Firstly, the proposal was based on the theory that an SBC would pass 
> STUN packets on the RTP ports. I spoke to several vendors of SBCs and 
> it turns out this is often not the case.
> Indeed, in their role as "security boxes", many of them will rate 
> limit the RTP, or prevent early media, or check for the right payload 
> types, etc., all of which will cause the STUN checks to fail even 
> though the RTP will work. Furthermore, some SBCs will in fact 
> terminate a call if they see no media traffic, so bypassing them will 
> not help. THus, my proposed approach would make calls fail when they 
> would otherwise work if we didn't try and make ICE work in the 
> presence of SBCs.
> 
> Secondly, the proposal flat out doesn't work for TCP, since the 
> candidate line for TCP includes some crucial information 
> (active/passive roles or SO), which is missing for the m/c-line. One 
> of the things I accomplished with this set of revisions is a 
> unification of the UDP and TCP mecahnisms. I think its a mistake to 
> break that.
> 
> Finally, it was going to make it harder to specify this "passive-only"
> mode, also known as ICE-for-gateways. In the current -12 a gateway 
> doesn't even maintain a candidate list for its peer; with this 
> proposal it would need to do some of it.
> 
> So, ICE-12 does not contain the proposal in the mail above. 
> Rather, it specifies that if an offer shows up, and the m/c-line 
> doesn't match any candidate, you abort ICE processing (just like -11 
> and -10 said). It also adds that, when a re-invite comes to confirm 
> the pairs selected by ICE, if the m/c-line doesn't match what is 
> selected by ICE, use the pairs selected by ICE.
> 
> My main rationale on the first piece of this (if m/c-line doesnt match

> a candidate, abort) is that we dont know what SBCs will or won't do. 
> Their behaviors are not specified, and they are highly variable. If 
> the purpose of ICE is to make voip *reliable*, then the most reliable 
> thing is to abort ICE processing and go with the relays. In a real 
> sense, the b2bua is a UA on the path; we abort ICE when an ICE-capable

> UA calls an ICE-unaware UA - thats the only safe thing to do. Same 
> here.
> 
> This does mean that if you have a non-ICE SBC in a network with ICE 
> endpoints, you get an extra relay hop in the call path. Extra latency 
> - but reliable. If however you make the SBC ice-aware, that problem 
> goes away, and there are many ways to do that which we don't need to 
> specify.
> I might argue that, within your own network, if you deploy ICE to 
> endpoints and have non-ICE SBC, you should be happy it works at all 
> let alone that it works with just an extra media hop.
> 
> Consequently, ICE will only proceed in -12 if the m/c-line MATCHES a 
> candidate. There is only one case I found where you still have some 
> kind of non-ICE media intermediary on the path, and ICE would proceed 
> - an ALG which leaves the m/c-line alone with its on the public side 
> of the NAT. In that case, ICE checks can proceed and will most often 
> validate that address anyway. In the case where both endpoints are 
> behind the same NAT/ALG, ICE would find that the direct path works, 
> and re-invite to it. NOW, the helpful ALG might rewrite the SDP to the

> public value.
> With ICE-12, media would still flow direct.
> 
> There is also a case where the m/c-line don't match what ICE selected,

> even though there isn't an intermediary. That case is when severe 
> packet loss causes each side to disagree on the selected candidates. 
> In that case I think an agent should use what it thinks works, and 
> that is why
> ICE-12 specifies to ignore the m/c-line in this case.
> 
> Generally I don't like sending media to somewhere else than the 
> m/c-lines. However, the important point is that in ICE-12, that ISNT 
> going to happen except for these two cases, and the former case you 
> reallly want to fix with TLS. That reduces the mismatch to one of a 
> bad failure case, and if that is our only mismatch use case I am not 
> so worried about it.
> 
> 
> Backing up one step further, this idea of 'getting around SBCs and 
> ALGs'
> was never a real requirement for ICE, and I am worried that it is 
> something that is fraught with problems. I don't want to try and dump 
> lots more complexity into ICE to try and guess our way around SBC and 
> ALG implementations. TLS is the surefire way to deal with ALGs. Let us

> design ICE for how it ought to work without SBCs and ALGs, make sure 
> it has a backwards compatibility mode when they are present, and then 
> declare victory. Right now, I think the market needs a 
> light-as-possible and FINISHED ICE spec more than anything else.
> 
> Thanks,
> 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

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