My suggestion: avoid STUN, TURN, and ICE like the plague. Don't read
the specs, don't talk with the P2P-SIP group -- just stay away. Far
away. It's a tarpit that will suck you down into the depths of
irrelevance. Just write your own system by reading the archives of this
mailing list and you'll get something working far faster and much
better. If you like, you're welcome to read the source code of iGlance
(which has NAT traversal). It's here:
http://www.iglance.com/code.html
(It has some classes named SIP and TURN, but they're utterly nothing
like the protocols by those names.)
-david
Ali Fessi wrote:
> Necati Demir wrote:
>> Hello,
>>
>> I am beginner for p2p and nat-traversal.
>> I have a client-server application. If one peer (client) want to
>> access other peer (server), the server peer should set a port mapping
>> with his ADSL modem. But i read some documents; with ICE, STUN and
>> TURN, this can be done without this setting. Can you suggest me a way
>> to do this?
> -
>
> STUN, TURN and ICE were primarily developed for VoIP but you should be
> able to use them for other applications as well. You should consider
> however, that you need some out-of-band mechanisms that you can use, how
> the 2 end points can agree on what IP addresses and port numbers they
> will use for the e2e communication. In SIP, this is done using the SIP
> servers (proxies, registrars, etc.). You can probably do this using P2P
> signalling as well.
>
> ICE can be considered as a negotiation between 2 peers and it finds out
> the optimal IP addresses to be used between them (this means, e.g., if 2
> peers are in the same subnet, they will use the private IP addresses to
> communicate within the subnet). ICE uses STUN and TURN as parts of it.
>
> If you have an application server, which does not know yet, which is the
> other peer/client, it may find out its public IP address using STUN
> first. When the STUN signalling passes the NAT, the NAT will perform a
> volatile NAT binding. If you are lucky, this NAT binding will allow for
> incoming connections from any client. The IP address and port number
> that you will receive from the STUN server can be used to announce the
> service. (this depends on the NAT implementation, but STUN seems to work
> in most of the cases) I assume that pjnath sends keep-alive messages to
> the STUN server in order to keep the NAT binding. Otherwise, you'll have
> to do by yourself.
>
> I would suggest you to start with STUN, write a small STUN client and
> test it with some public STUN servers. (There are many STUN servers that
> are public but be careful not to hardcode one of them in your
> application! ;-) )
>
> If you want to use TURN, you may need to make sure you have some servers
> that can relay the traffic. Or you may want to have some peers in the
> p2p network that could “volunteer” to do it.
>
> You may also consider UPnP as an alternative. Good luck!
>
> -
>> I really need a good documentation. Can i do this with pjnath library?
>> Can you show me some examples with this library?
>>
>> --
>> Necati Demir
>> http://demir.web.tr
>> http://blog.demir.web.tr
>> ndemir [~] demir.web.tr <http://demir.web.tr>
>> necati83 [~] gmail.com <http://gmail.com>
>> --------------------------------------
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> p2p-hackers mailing list
>> p2p-hackers@lists.zooko.com
>> http://lists.zooko.com/mailman/listinfo/p2p-hackers
>>
>
> _______________________________________________
> p2p-hackers mailing list
> p2p-hackers@lists.zooko.com
> http://lists.zooko.com/mailman/listinfo/p2p-hackers
_______________________________________________
p2p-hackers mailing list
p2p-hackers@lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers
