Re: TURN

Thank you for your comment.
My comments and question start from ***  to find them easily.

>> Q.1
>> Assuming the following topology.
>>
>>
>> 　　+---------+
>> |TURNserver|
>> 　　+---------+
>> |
>> |
>> 　　+--------+ +--------+
>> |symmetric1| |symmetric2|
>> 　　+--------+ +--------+
>> | |
>> | |
>> 　　+-------+ +--------+
>> | client1 | | client2 |
>> 　　+-------+ +--------+
>>
>> Client1 and clients wants to connect each other. Client1 knows TURN server, and it is behind 
>> symmetric 1.
>> But client2 doesn't know TURN server, and it is behind symmetric2.
>> Client1 and client2 can exchange data channel information using signaling channel, like SDP of 
>> SIP.
>>
>> Then, can client1 and client2 be connected?
>
> Assuming the data transport is RTP, which is a uni-directional data transport, only 
> client2-to-client1 data channel might be able to be established.
> Otherwise, a bi-directional data channel might be able to be established, depending on the 
> transport protocol used.

***
As to above topology, why might client2-to-client1 data channel
be able to be established?
How does client know derived trasport address of client2 behind
symmetric2?  BTW, I assume UDP.

>> If turn server emulates Restricted NAT, but not Port Restricted NAT,
>> then I think client 1 and client2 can be connected.
>> Are there any problem if turn server emulated Restricted NAT.
>
> A TURN server is a application layer media relay, but not a NAT emulator.
> If a TURN server relays packets in a similar manner as a restricted NAT routes packets, you would 
> not be able to differentiate which packets are from which transport address.

***
I am envisoning that client can specifiy "*" as port of DESTINATION-ADDRESS
attribute of SEND Request. If Turn server receives this request, it doesn't send any packet.
Turn server sets default ip-address to the ip-address of DESTINATION-ADDRESS,
and default port to "*".  At this time, non-turn packets from client to some peer can not
be sent to anywhere.

At this condition, if some peer send a packet to the port allocated by turn server and
mapped above SEND Requret, turn server checks only source ip address, not port,
because default port is "*" that means any port.

If souce ip address of packet sent by peer matches default ip-address, turn server sets
the default port to source port of packet sent by peer, and relays this packet to client
using allocate five-tuple.

If I can do this, even if peer is behaind symmetric NAT, then I realize only one turn
server relay, not double relay.


>> Q.2
>> Assuming the following topology.
>>
>>
>> 　　+----------+ 　　+----------+
>> |TURNserver1| |TURNserver2|
>> 　　+----------+ 　　+----------+
>> | |
>> | |
>> 　　+--------+ +--------+
>> |symmetric1| |symmetric2|
>> 　　+--------+ +--------+
>> | |
>> | |
>> 　　+-------+ +--------+
>> | client1 | | client2 |
>> 　　+-------+ +--------+
>>
>> Client1 and clients wants to connect each other. Client1 knows TURN server, and it is behind 
>> symmetric1.
>> Client2 knows TURN server, and it is behind symmetric2.
>> Client1 and client2 can exchange data channel information using signaling channel, like SDP of 
>> SIP.
>>
>> Then, I think client1 and client2 can be connected, using double relaying.
>> This is, clietn1 <-> TURNserver1 <-> TURNserver2 <-> client2.
>> But, this is not efficient. Do you have good idea for connecting peers under
>> above situation?
>
> Yes, they could be connected (two uni-directional data paths).
> If they were both authorized for use of the same TURN server, they could do that for the sake of 
> efficiency, latency and etc.
> There are probably better solution for this scenaio, I would like to know, too.
>
>>
>> Thank you for advices.
>
> Hope my response would be helpful : ).
>