Re: [tram] New Version Notification for draft-williams-peer-redirect-02.txt

Hi Aijun,

TURN was originally written as a backup service when ICE fails. It also did provide fallback when ICE clients wanted to talk to non-ICE clients (But then the default candidate must be set to the relay address. The point is that the allocated public RELAY address on the turn server works as a normal UDP (or TCP if that is in use) port. That means that any client can send its RTP packet or whatever as normal without any knowledge regarding TURN.As long as the client have installed the necessary permissions.

If the to TURN servers are needed due to restricting FWs the traffic between the two public RELAY addresses will be pure UDP or TCP.  No need for any additional information. 

With ICE it might be possible to end up with asymmetrical routing. Not sure how common that is. I am inclined to blame the network if that occurs, ICE only probes and ties to get the packets through. 

I do not understand what you are trying to solve below.

.-.
Pål-Erik

> On 12 Jan 2015, at 01:43, Aijun Wang <wangaijun@tsinghua.org.cn> wrote:
> 
> Hi, Brandon:
> 
> In http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-10.1, it is
> described as below:
> 
> When forming a Send indication, the client MUST include an XOR-PEER-
>   ADDRESS attribute and a DATA attribute.  The XOR-PEER-ADDRESS
>   attribute contains the transport address of the peer to which the
>   data is to be sent, and the DATA attribute contains the actual
>   application data to be sent to the peer.
> 
> So, there is no XOR-RELAYED-ADDRESS attribute included to identify the
> peer's allocated relay address. On the other hand, XOR-RELAYED-ADDRESS is
> mainly refer to the requester's allocated relay address, not the
> corresponding peer. Will we define again one new attribute, such as
> XOR-PEER-RELAYED-ADDRESS to transfer the next TURN server's information?
> 
> Even if so, what will be the source address for the packet from the second
> TURN server to destination peer? If we use the XOR-RELAYED-ADDRESS, then the
> return packet from the peer will be passed back directly to the first TURN
> server, results in non-symmetric route. If we use XOR-PEER-RELAYED-ADDRESS,
> then what is the source address for the packet from the second TURN server
> back to the first TURN server?
> 
> Best Regards.
> 
>> -----Original Message-----
>> From: Brandon Williams [mailto:bowill@akamai.com]
>> Sent: Saturday, January 10, 2015 1:09 AM
>> To: Aijun Wang; tram@ietf.org
>> Subject: Re: [tram] Fwd: New Version Notification for
>> draft-williams-peer-redirect-02.txt
>> 
>> By relay address, I mean the XOR-RELAYED-ADDRESS returned in the
> allocation
>> request. This clearly identifies the true source and destination for the
> data in
>> the packet as well as the two relay servers involved. If both relayed
> addresses
>> are on the same server, it will of course know that and be able to
> optimize as
>> Simon indicated in an earlier e-mail.
>> 
>> --Brandon
>> 
>> On 01/08/2015 09:40 PM, Aijun Wang wrote:
>>> 
>>> [Aijun]: There are two relay address, one is the TURN server
>>> well-known address, another is the relay address that allocated to
>>> each client. Which one should be used then? On the other hand, when
>>> client want to send traffic to other peer, it does not know whether
>>> the other part is under the same TURN server or not, how do it select
> this
>> information?
>>> 
>> 
>>> 
>>> [Aijun]: as the definition in
>>> http://tools.ietf.org/html/draft-ietf-tram-turnbis-00#section-14.3,
>>> the XOR-PEER-ADDRESS is the address seen from the TURN server, so it
>>> can't be used to find the relay address of the remote peer, and then
>>> can't be used to direct traffic to downstream relay.
>>> 
>>> 
>> 
>> 
>> --
>> Brandon Williams; Senior Principal Software Engineer Emerging Products
>> Engineering; Akamai Technologies Inc.
> 
> 
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram