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

[Simon Horne]

Dan

Yeah I finally got that idea out for my head. :-)
Unfortunately I'm a programmer so I had to go off and prove the concept in 
code before writing the specification.

inline..

At 06:11 AM 5/06/2007, Simon Horne wrote:
>>At 05:14 AM 5/06/2007, Dan Wing wrote:
>>>Simon Horne wrote:
>>>>I guess the big design differentiator between P2Pnat Media and ICE is 
>>>>that its smarts are in the network and not the client. The network 
>>>>(local gatekeeper) decides, as part of existing call routing and before 
>>>>the call setup message is sent, how any relevant NATs are to be 
>>>>transversed for the call, removing all the complexity from the client 
>>>>and avoiding the need for the long list of "candidates"
>>>
>>>What does it do in a situation like this:
>>>
>>>                           [h.323 gateway]
>>>                                |
>>>                   +---------[router]-------------+
>>>                   |                              |
>>>                 [NAT]                            |
>>>                   |                              |
>>>   [endpoint]--[router]----------------------[endpoint]
>>>
>>>With ICE in this situation, ICE would cause the media to take the 
>>>southern route.  If I understand your new approach correctly, this 
>>>situation would cause the media to be relayed through the H.323 gateway 
>>>or routed up through the NAT (I'm not sure which), but never just along 
>>>that southern route.

Yes you are correct, the network cannot know where the parties are behind 
the same NAT. This is exactly why the proxying requirement for P2Pnat media 
is slightly higher than ICE because it doesn't attempt to solve every 
scenario. However, although not covered in the current specification, the 
important factor is that the network does know they are behind the same NAT 
and notifies the endpoints of this in advance so endpoint implementors have 
the choice to perform some form of interoperable media optimization 
independent of the network.

(It's a separate argument for how often network topologies such as this 
appear in the wild, and how important it is to optimize the media path for 
such topologies).
This is exactly the point of P2Pnat to take a more pragmatic approach to 
NAT Traversal and cover 95+% of cases and detect (and proxy) for cases it 
cannot resolve.

>>> > and associated media establishment delays
>>>>generally associated with ICE.
>>>
>>>ICE hides those delays by only ringing the phone after a connectivity 
>>>check has completed -- sortof a "poor-man's connectivity precondition".
>>>http://tools.ietf.org/html/draft-ietf-mmusic-ice-15#section-12.1.1

Collecting candidates before you even call? ok? You still don't have any 
idea if the call will succeed or not. You still have to wait until all the 
candidates have been exhausted and timed out. 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.

Simon