On Wed, Jun 22, 2011 at 8:34 AM, Federico Kouyoumdjian <fedekp at autistici.org> wrote: > Hello, we are a team that is actually working in a free software project > called goalbit (http://goalbit.sourceforge.net/) about streaming video. Our > goal is to find a solution for the NAT problem for a protocol based on > bittorrent. > Sounds cool! > As a solution or library to implement the solution we chose PJNATH because > of its detailed documentation, its popularity and that we want to use the > ICE protocol for the solution of the NAT problem in P2P. > Thanks! :) > We started reading ICEdemo.c and we have some doubts that we will be > grateful if you could answer. > > - In ICE demo there is a part where one have to copy and paste the SDP of > the other host. Shouldn't this be done by a rendezvous server? If it should, > is there an example of one we could use? > Yes, that sounds like correct. The information about each agent/endpoint's ICE properties must be communicated to the other agent/endpoint, using mechanism outside ICE. In SIP, that information is encoded as SDP and transmitted as part of SIP signaling to the other endpoint. Your protocol needs to do something similar, maybe using rendezvous server or something else (I don't know the detail about your protocol). The use of SDP to encode this information is also not mandated by ICE. You may encode it as binary if that's more efficient, although with SDP the icedemo already provides the code to encode and parse it. > - Is there any example of a STUN server we could use to make the ICE demo > work? > There are plenty out there. You could use stun.pjsip.org too. > - Is it necessary to use a TURN server? In our case we would like that if a > P2P connection can't be established, a "couldn't establish connection" error > should be displayed instead of using TURN. > Any of the ICE candidates (host, srflx, relay) are optional, you don't have to use them if you don't want them. Benny
