TURN-TCP and eliminating the STUN "Send Indication" and "Data Indication" Encapsulations

[auro tripathy]

Hi,

My application is about reliable and secure file-transfer (client-to-client) via a TURN-TCP relay. As always, TURN-TCP is the fallback to a failure in the direct path (port-punching/port-forwarding).

I understand that using TURN (either UDP or TCP relay) is a three-step process, (1) getting an allocation (2) getting permissions (3) sending/receiving data

I'm new to the STUN/TURN RFCs (and rfc5766-turn-server); my question is the following:

         Is there a configuration in rfc5766-turn-server to eliminate the encapsulation layers (the "Send Indication" and "Data Indication", even the Data Channel encapsulation)?

         Once the client gets an allocation and a permission, can it just use TCP sockets to the turn server and transfer data to the other side?

I'm hopeful because the TURN-TCP spec talks about sending "as-is" data.

Thank you.

Auro

p.s. My app has nothing to do with WebRTC, so I can entertain client-side changes (in PJNATH) 

[Oleg Moskalenko]

You do not need any extra configuration. The TURN server supports TURN-TCP (RFC 6062) as-is, by default. You just have to establish the TCP connections exactly how the process is described in RFC 6062 document. Then you will have a "clean" "channel" (connection), without encapsulation.

Regards,

Oleg

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.