Good point - we probably need to clarify this in the draft. I think that implementors do one of two things when joining
1) don't include a TURN candidate in the Attaches used in the Join. This still works fine because the node they are connecting to in the ring will include an TURN server in it list of addresses if one is needed. You will note in section 5.5.1.5, 2nd para, it tries to make it clear that you only need a host address and not a the address of a TURN server. I'll try to clarify this for the case you raised here. and alternative approach is 2) route the requests to discover a TURN server though the peer being used to join the DHT by adding that peer to the destination list. This allows the TURN discovery to happen before the node joins the ring. I agree this looks like a deadlock problem in the current draft. I updated section 5.5.1.5. to try and make this clearer. On Feb 3, 2010, at 10:07 PM, JeffreyHo wrote: > Dear all, > > I have a question about the Joining procedure for a peer who is behind > symmetric NAT. > Per the specification from RELOAD base (step 3 in the sec. 9.4), > JP SHOULD send Attach requests to initiate connections to each of the > peers in the neighbor table ... > Before sending an Attach request, it has to prepare all IP candidates via ICE > including the Relay-reflexive candidate obtained from a TURN Server. A peer > can get the TURN Server information on the P2P RELOAD Overlay through TURN > Usage. So I suppose the joining behavior in order below, > > Joining Peer -> Connection to Bootstrap Peer -> Ping -> Fetch TURN Usage > (obtain TURN Server) -> ICE -> Attach Request -> .... > > The problem is how an un-joining peer fetches the TURN Usage from the > overlay, it is even not part of the RELOAD chord ring. That means it can't > send the Attach request, then it can't join the overlay. It seems deadlock > here? Or I have something wrong on such understanding? > > I think this question could be also addressed as "how can an un-joining peer > find the TURN Server over the overlay?" > > Any comment and answer will be appreciated. > Thanks a lot in advance. > > BR, > Jeffrey > > 本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。 > This email may contain confidential information. Please do not use or > disclose it in any way and delete it if you are not the intended recipient. > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
