TURN relay-to-relay path under 5766 and 6062?

[auro tripathy]

I’m running an experiment with a trapezoidal topology as shown below:

R1 and R2 are separate & independent TURN servers and C1 and C2 are PJSIP-based clients.

        R1<———>R2

        /       \

       /         \

      /           \

     C1           C2

In my configuration, C1<-->R1 and C2<-->R2 are TCP connections (so STUN request/responses such as Allocate, Create Permission, and Channel Bindings are over TCP).

Also, channel data (C1 to R1 and C2 to R2) is over TCP as well. 

However, the R1<—>R1 path (relay-to-relay) is still UDP-based. Wanted to confirm this.

Questions

Under RFC5766, is there a way to configure the TURN server for the R1<—>R2 path to be TCP connectivity .

Under RFC6062, will the R1<--->R2  path be TCP connectivity?

Thank you

-Auro

[Oleg Moskalenko]

see in the text below:

On Tue, Feb 3, 2015 at 3:58 PM, auro tripathy <auro.t...@gmail.com> wrote:

I’m running an experiment with a trapezoidal topology as shown below:

R1 and R2 are separate & independent TURN servers and C1 and C2 are PJSIP-based clients.

        R1<———>R2

        /       \

       /         \

      /           \

     C1           C2

In my configuration, C1<-->R1 and C2<-->R2 are TCP connections (so STUN request/responses such as Allocate, Create Permission, and Channel Bindings are over TCP).

Also, channel data (C1 to R1 and C2 to R2) is over TCP as well. 

However, the R1<—>R1 path (relay-to-relay) is still UDP-based. Wanted to confirm this.

Yes

 

Questions

Under RFC5766, is there a way to configure the TURN server for the R1<—>R2 path to be TCP connectivity .

No
 

Under RFC6062, will the R1<--->R2  path be TCP connectivity?

Yes

Regards,

Oleg