[VOIPSEC] P2Pnat Media - A H.323 alternative to ICE

[Simon Horne]

At 05:03 AM 15/06/2007, you wrote:
>Simon Horne wrote:
>>At 07:19 AM 5/06/2007, Dan Wing wrote:
>In the most recent ICE specification (-16, released on Tuesday), this
>has been softened slightly:  if you can't get any candidates to work,
>you hope (and pray) that something is blocking ICE (and will allow
>RTP when the phone is answered) and go ahead and ring the phone
>anyway.  Not ideal, but, then, none of this NAT stuff even *smells*
>of being ideal.

I guess it really depends how you look at the NAT problem. You can get 
stuff to work through NAT (ICE) or work with NAT to get your stuff through 
(P2Pnat). Different philosophy. The proposal currently before the ITU looks 
at it intelligently, the gatekeeper knows party 1 has this type of NAT and 
party 2 has this type of NAT so a quick look at the NAT rule books says we 
have to use strategy X so party 1 & 2 go do strategy X.  We know pretty 
much the behavior of all the different types of NATs and what we have do to 
traverse them (whether allowing point to point or requiring proxying). So 
theoretically there should NEVER be a condition where a call will fail as 
we already know (from research) that that particular call scenario will 
fail and can advise the caller when they place the call of that condition. 
That's all good in theory....but in practise... there is a big problem. 
There is no way in SIP to advise the caller UA as the messages to do so 
just plain don't exist so your only option is for the UA's to attempt all 
the known NAT scenarios for every call in the HOPE of finding one that 
matches. IMHO this is a flaw in SIP and why ICE is so complex and yet still 
calls can fail.

FYI: With H.325 I have also put in a proposal to do P2Pnat signalling 
(can't do that in H.323) as well as media.

>>> > With P2Pnat Media, the status
>>>>of the remote NATed endpoint is known prior to the setup message 
>>>>(INVITE) being sent and the gatekeeper has already determined not only 
>>>>if there is connectivity but but by which strategy is to be used to 
>>>>reach the remote party, If the call will fail the caller is notified 
>>>>before the setup (INVITE) with reason "user unreachable". This is one 
>>>>of the advantages of intelligent call routing.
>>>
>>>I expect it's the same number of messages for those 95% of cases you're
>>>solving that ICE would generate, and thus the same post-dial latency.
>>No read the specification. There are NO, let me say that again NO extra 
>>messages during call establishment NONE!. The existing ARQ-LRQ-LCF-ACF is 
>>used to collect and compare NAT information (using the existing H.460 GEF 
>>framework). The NAT characteristics information is collected beforehand 
>>as part of the registration process and stored with the call record in 
>>the gatekeeper.
>
>NAT characteristics, as in if the NAT is 'symmetric'?

Yes we are really interested in Open, Cone, Others (symmetric,symmetric 
firewall etc) and Blocked.  With the first two we know they can accept 
incoming RTP, the others we know we have to send the RTP first and if we 
have a block NAT? we have big problems, don't allow calling and go flash a 
red light at the user. Also taken into consideration is whether there is a 
Border Element that must proxy media first to reach the intended targets 
and whether the comparison of apparent source addresses (IP outside NAT) 
are the same then we know they are behind the same nat.

Under P2Pnat media no call should fail due to NAT either a strategy if 
found or the call is rejected before sending the setup (invite). A few 
people have this total aversion to even thinking about proxying media (even 
if its 5-10%) so in the proposal the endpoint on registration is advised if 
the local gatekeeper can support proxying media or not If the caller is 
behind a "tough" NAT they are advised immediately "hey your NAT is dodgy 
and your provider isn't going to help you so there is a good chance some of 
the people you are calling are going to be unreachable".  One good point is 
that now instead of the developers and VoIP itself being the target of 
loathing about failure of calls for NAT, it all falls on the providers :-).

Simon


Simon