turn to turn relay

170 views
Skip to first unread message

naveen ks

unread,
May 28, 2015, 6:11:02 AM5/28/15
to turn-server-project...@googlegroups.com
Hi guys,

I was wondering whether such a functionality exists or what could be the merits/demerits of a system where.
There are 2 turn servers in a cascade between the peers.

For Ex: Suppose there are 2 servers t1 and t2, 2 clients p1 and p2.

Communication between p1 and p2 is happening via

p1->t1->t2->p2
and the reverse being
p2->t2->t1->p1

As we could assume that t1, t2  are in different geographic locations and have very good reserved bandwidth which can be used. 
Please suggest whether such a design is possible or let me know if there are any flaws

Oleg Moskalenko

unread,
May 28, 2015, 12:00:29 PM5/28/15
to naveen ks, turn-server-project...@googlegroups.com
I do not see any problem why such network design cannot be used if that is beneficial for your purpose.

Sent from my iPhone
--
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.

naveen ks

unread,
May 29, 2015, 12:33:07 AM5/29/15
to Oleg Moskalenko, turn-server-project...@googlegroups.com
Does the coturn project have something inbuilt for such a requirement

Oleg Moskalenko

unread,
May 30, 2015, 3:00:09 AM5/30/15
to turn-server-project...@googlegroups.com, naveen.sh...@gmail.com, mom0...@gmail.com
You do not need any special server functionality. That configuration
is supported as-is. You have to inform both parties about the relay
endpoints IP:port addresses. Nothing has to be done on the TURN server
side; the client is responsible for the correct network connections.
So this is a question for your client software providers, all TURN
servers support the network topology that you suggested.


On Thursday, May 28, 2015 at 9:33:07 PM UTC-7, naveen ks wrote:
Does the coturn project have something inbuilt for such a requirement
On 28 May 2015 at 21:30, Oleg Moskalenko <mom0...@gmail.com> wrote:
I do not see any problem why such network design cannot be used if that is beneficial for your purpose.

Sent from my iPhone

On May 28, 2015, at 3:11 AM, naveen ks <naveen.sh...@gmail.com> wrote:

Hi guys,

I was wondering whether such a functionality exists or what could be the merits/demerits of a system where.
There are 2 turn servers in a cascade between the peers.

For Ex: Suppose there are 2 servers t1 and t2, 2 clients p1 and p2.

Communication between p1 and p2 is happening via

p1->t1->t2->p2
and the reverse being
p2->t2->t1->p1

As we could assume that t1, t2  are in different geographic locations and have very good reserved bandwidth which can be used. 
Please suggest whether such a design is possible or let me know if there are any flaws

--
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-rfc5766-turn-server+unsubscribe@googlegroups.com.
To post to this group, send email to turn-server-project-rfc5766-turn-...@googlegroups.com.

naveen ks

unread,
Jun 1, 2015, 3:15:08 AM6/1/15
to Oleg Moskalenko, turn-server-project...@googlegroups.com
Hi,

Thanks a lot Oleg for the response. 
I have just started working on TURN servers and these things are slightly confuding for me.
Can you let me know what kind of client setup would be required for such a functionality.

As I understand The TURN server connects 2 peers. So to implement the requirement I had posted, the TURN servers will have to behave as peers for each other and in turn forward the packets to the actual peers. I was not able to find such a setting as per the RFC.

Thanks,
Naveen

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.

--
You received this message because you are subscribed to a topic in the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/turn-server-project-rfc5766-turn-server/moa8g02QbGA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to turn-server-project-rfc57...@googlegroups.com.

To post to this group, send email to turn-server-project...@googlegroups.com.

Oleg Moskalenko

unread,
Jun 1, 2015, 3:27:19 AM6/1/15
to naveen ks, turn-server-project...@googlegroups.com
On Mon, Jun 1, 2015 at 12:15 AM, naveen ks
<naveen.sh...@gmail.com> wrote:
> Hi,
>
> Thanks a lot Oleg for the response.
> I have just started working on TURN servers and these things are slightly
> confuding for me.
> Can you let me know what kind of client setup would be required for such a
> functionality.

see below

>
> As I understand The TURN server connects 2 peers. So to implement the
> requirement I had posted, the TURN servers will have to behave as peers for
> each other and in turn forward the packets to the actual peers.

yes

> I was not
> able to find such a setting as per the RFC.

no, that's not the TURN server responsibility. Where to send the
packets is the responsibility of the client. The client is defining
the destination of the packets, so there is nothing to configure on
the server side. The TURN client application is in full control.

If you draw the network diagram and try to go, step-by-step, with the
network communications required to get that path, then you will see
what I am saying.
Reply all
Reply to author
Forward
0 new messages