NAT traversal implementation: modify nat_detect.c?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jul 14, 2008 at 7:10 PM, Enrico De Razza <ederazza at yahoo.it> wrote:

> Yes, you were faster than light... ;-) Thank you a lot.
>
> Just to be clear:
> since NAT behavior may vary according to time, traffic, and so on,...
> in order to implement an application NAT-independent, we need to model the
> NAT device: let f(t) be the NAT behavior "at time t", based on the local
> socket address of the client, and the destination socket address for
> outgoing packets.
> For these variables I wanna know:
>  - the public address for the local socket;
>  - if the mapping is Endpoint-Independent;
>  - if the filtering is Endpoint-Indipendent.
>
> Thanks to these 3 informations, I know all it's needed to do NAT traversal
> (and I can choose among 2 techniques: Hole Punch and TURN).
>

These sound like the old way of doing NAT traversal (the RFC 3489 way), and
it's supposed to be succeeded by ICE. With ICE, you don't need to know
what's the NAT type in front of the application, you just give it the
candidates (local, mapped, and relayed candidates) and ICE will find out
which address it can communicate with.



> Your API "pj_stun_detect_nat_type()" does the first job: model the NAT
> device, at the time t when I start my application, for a local socket.
> The next step is doing UDP Hole Punch between 2 peers:
>  - every client detects its NAT;
>  - every client sends these info to an Introducer Server;
>  - the Introducer Server replies these data among peers.
> When a peer receives the client data, the Hole Punch starts: every client
> tries to send a simple "Hello World" to the peer, via the local or the
> mapped address.
> At this moment, I'm not considering the case where clients are both behind
> a symmetric NAT, so this procedure would be succeful.
> And that's why I'm studying your libraries...
>
> So, if you have some idea or if you think I'm wrong, I'm listening...;-)
>

Just use ICE and it will do most of the things you mentioned above,
including handling the symmetric case, for you. If you don't use SIP then
yes you'd need to implement some kind of rendezvous server (the Introducer
Server in your list above) to exchange ICE candidates between peers.

Cheers
 Benny
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080714/41925bf3/attachment.html 


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux