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

[Dan Wing]

Simon Horne wrote:
> 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). 

Yahoo uses ICE, too (I hadn't confirmed that until last week, but a 
tcpdump confirmed it).

 > What about
> interoperability with older version/non ICE equipment?

There isn't any -- ICE is not yet a standard and is, thus, still in
flux.  This isn't too important for those early adopters (GoogleChat,
Yahoo, MSN), though, because they have little interoperability
amongst themselves for text instant messaging let alone voice or
video.  That lack of interoperability isn't ICE's fault, but
rather their different protocols.  The business models seem to
avoid interconnecting the services, too.

 > Does the whole
> network need to be upgrades for the latest version (RFC) ICE? I'm not 
> totally up to speed with the specification.

It hasn't been issued as an RFC yet.  When it does, it would be 
reasonable to expect that implementations that want to interwork
will interwork using the RFC rather than a certain version of the
Internet Draft.

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

Sorry, my use of "Gotcha" was intended to convey "I understand", not 
"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.
> 
> LOL Now that is funny....So what happens when none succeed?

If none succeeded, then none would carry RTP.  It seems undesirable to
ring the phone.

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.

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

NAT characteristics, as in if the NAT is 'symmetric'?

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

-d

> Simon
> 
> 
> 
> 
> 
>