On Wed, Nov 19, 2008 at 9:43 PM, jiangxingfeng 36340
<[EMAIL PROTECTED]> wrote:
> Hi:
>
> 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.

Bruce


>
> On the other hand, for a peer, there might be several relay peers. The relay 
> peer is on per-transaction basis. That means that the peer can use different 
> relay peer in different transactions. So the peer has no strong reliance on 
> the stablility of the relay peer. If a relay peer failed, it may only 
> influence one. Other relay peer can be used in the next transactions.
>
> Any comments are appreciated.
>
> Regards
>
> Jiang XingFeng
>
>
> _______________________________________________
> P2PSIP mailing list
> [EMAIL PROTECTED]
> https://www.ietf.org/mailman/listinfo/p2psip
>
_______________________________________________
P2PSIP mailing list
[EMAIL PROTECTED]
https://www.ietf.org/mailman/listinfo/p2psip

Reply via email to