> > In today P2PSIP WG meeting, Eric showed his concerns about the difference > between relay peer and turn server(peer). Let me give some explanations here. > > > > As mentioned in the relay draft, the relay peer forwards the response from > the destination peer towards the sending peer. Turn server(peer) works in the > similar way. > > > > But the only difference is: if the client A of turn server B wants to accept > message from peer C, client A should set permission in turn server B for peer > C before the the message is sent by peer C. Otherwise, it would be dropped > silently. > > > > In P2PSIP request/response transaction, before a peer sends a request, it > does not know which peer is the destination peer exactly beforehand. It > depends > on the overlay topology. And the destination peer also changes according to > the overlay topology. It is impossible for the sending peer to set the > permission for the destination peer in turn server case. So if turn server is > used instead of relay peer, the response will be filtered and dis > > carded. > > > exactly. The underlying problem is that TURN resolved many of its > security issues by essentially acting as an address-restricted filter. > TURN can be used as the final resolution of an Attach, but it doesn't > provide any facility for an unsolicited message. And since reload has > a built-in authentication and routing mechanism that helps resolve > some of the concerns that led to the restrictions in TURN, I don't > think it makes any sense to attempt to modify TURN to accomplish this.
> > The other aspect of this question that I think was unclear during the > session is that the relay peer concept doesn't depend on > nat-behavior-discovery to be useful. A service provider operating an > overlay could choose to deploy a set of relay peers for use by > customers running behind NATs. > Good point. The proposed modified NAT behavior discovery mechanism in the draft is used to show that publicly reachable peers can be found if there is any. Maybe the presentation and the description in the draft are not very clear. The only requirement for relay is to find some publicly reachable transport addresses. These addresses can be got through several mechanisms, such as relay peers provided by service providers (as Bruce suggested and service providers choose peers with publicly reachable addresses intentionally), transport addresses got by using NAT-PMP or Upnp-IGD, etc. With these addresses, the peer can use RM_TEST to check whether it is publicly reachable or not. If the test shows it is publicly reachable, the peer can use direct response later and be a relay for other peers. I hope the above text can make communities more clear about the idea. I will revise the draft in these two weeks. Any comments are appreciated. Regards Jiang XingFeng _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
