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

[Dan Wing]

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.

>>>>
>>>>                           [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.

 > 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.

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.

-d


> Simon
> 
> 
> 
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
>