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

[Simon Horne]

At 07:19 AM 5/06/2007, Dan Wing wrote:
>Simon Horne wrote:
>>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.
>
>It's not like ICE isn't used -- MSN Messenger has been using ICE
>for over a year, and MSN is used by more than a dozen users.

I'm not good on specification writing and had to go off and see if it was 
even possible to do. I wasn't making a swipe at ICE. On that note Google 
also uses ICE (version 8 variant I think).  What about interoperability 
with older version/non ICE equipment? Does the whole network need to be 
upgrades for the latest version (RFC) ICE? I'm not totally up to speed with 
the specification.



>>>>>                           [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.
>
>My ASCII art isn't great, but I was trying to have the endpoint
>on the left behind a NAT, and the endpoint on the right _not_ behind
>a NAT at all.  Of course, without seeing routing tables I guess
>either interpretation is valid.
>
> > This is exactly why the proxying requirement for P2Pnat media
>>is slightly higher than ICE because it doesn't attempt to solve every 
>>scenario.
>
>Gotcha.

So? It was never ever the intention to solve every scenario. You guys have 
a 4 year 15 revision and almost 100 page specification head start on that..:-)


> > 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.
>
>That's fair.
>
>>>>>>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.
>
>No, you don't need to wait until you've tried them all -- you wait until
>one has succeeded.  Then you can ring the phone.

LOL Now that is funny....So what happens when none succeed?


>You could ring the phone immediately, but if the user answers and says
>"hello" you're tempting fate for clipping:  the firewalls (if any) and 
>NATs (if any) might not be prepared to accept the incoming RTP stream.
>
> > 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. The gatekeeper calculates the NAT strategy to use (internal 
comparison of NAT characteristics) and then instructs the local endpoint to 
configure itself for the call. There is NO media establishment delays 
(aside from STUN port openings when part of the configuration instructions) 
as both parties know how they are going to send media beforehand. They just 
send the media as per normal (albeit to modified co-ordinates).

Simon