Subject: [BEHAVE] Question regarding sending data to a peer via TURN

From: Todd Herman <[email-masked]>
Date: Thu, 13 Dec 2012 01:55:57 +0000

I have a question related to section 10 of RFC 5766.

My understanding is that a TURN client sends data to a peer by sending a SEND indication with the data to be relayed.  I get that then the next part confuses me.  I expected the server to send a DATA message but the specification says that it sends just a standard UDP datagram, which I take to mean NOT a STUN/TURN message.  If the peer sends data back, it is also sent as a standard UDP datagram.  The server then creates a Data indication and sends that back to the client.

Why the standard UDP datagram rather than exchanging Data Indications?  Is it because the sending IS a TURN client and the receiver is not.  Do we always assume that the initiator is a TURN client and the receiver is not a TURN client?  I am trying to get a better understanding of how the TURN client and peer are differentiated.

Todd Herman
Senior Software Engineer

APX Labs
2350 Corporate Park Drive, Ste. 510 | Herndon, VA 20171
m: 703-489-8761 | www.apx-labs.com<http://www.apx-labs.com> | @APXLabs

---

From: "Dan Wing" <[email-masked]>
Date: Wed, 12 Dec 2012 19:24:09 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Todd Herman
> Sent: Wednesday, December 12, 2012 5:56 PM
> To: [email-masked]
> Subject: [BEHAVE] Question regarding sending data to a peer via TURN
> 
> My understanding is that a TURN client sends data to a peer by sending a
> SEND indication with the data to be relayed.  I get that then the next
> part confuses me.  I expected the server to send a DATA message but the
> specification says that it sends just a standard UDP datagram, which I
> take to mean NOT a STUN/TURN message.  If the peer sends data back, it
> is also sent as a standard UDP datagram.  The server then creates a Data
> indication and sends that back to the client.
> 
> 
> 
> Why the standard UDP datagram rather than exchanging Data Indications?

So that the remote peer needs not understand TURN and needs not know
(or care) that it is communicating with a TURN server.

>  Is it because the sending IS a TURN client and the receiver is not. 

Right.

> Do
> we always assume that the initiator is a TURN client and the receiver is
> not a TURN client?  I am trying to get a better understanding of how the
> TURN client and peer are differentiated.

The peer always gets normal, un-TURN-encapsulated data.

By doing it this way, we don't care if the remote peer is a
non-ICE-supporting
peer, or if the remote peer is really a TURN server.  That is, to Alice and
to Alice's TURN server, this sort of network diagram where Bob might not
even understand ICE, TURN, or STUN:

     Alice's TURN server----(normal RTP)----Bob
      |
  (TURN-encapsulated RTP)
      |
    Alice

works exactly like this one:

     Alice's TURN server----(normal RTP)----Bob's TURN server
      |                                       |
  (TURN-encapsulated RTP)         (TURN-encapsulated RTP)
      |                                       |
    Alice                                    Bob

Effectively, TURN is a tunneling mechanism between a TURN client
and its TURN server.  Once on the 'far side' of the TURN server,
the data is no longer tunneled.

-d

---

From: Todd Herman <[email-masked]>
Date: Thu, 13 Dec 2012 04:49:16 +0000

> From: Dan Wing [mailto:[email-masked]]
> Sent: Wednesday, December 12, 2012 10:24 PM
> To: Todd Herman; [email-masked]
> Subject: RE: [BEHAVE] Question regarding sending data to a peer via TURN
> 
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Todd Herman
> > My understanding is that a TURN client sends data to a peer by sending
> > a SEND indication with the data to be relayed.  I get that then the
> > next part confuses me.  I expected the server to send a DATA message
> > but the specification says that it sends just a standard UDP datagram,
> > which I take to mean NOT a STUN/TURN message.  If the peer sends data
> > back, it is also sent as a standard UDP datagram.  The server then
> > creates a Data indication and sends that back to the client.
> >
> >
> >
> > we always assume that the initiator is a TURN client and the receiver
> > is not a TURN client?  I am trying to get a better understanding of
> > how the TURN client and peer are differentiated.
> 
> By doing it this way, we don't care if the remote peer is a non-ICE-supporting
> peer, or if the remote peer is really a TURN server.  That is, to Alice and to
> Alice's TURN server, this sort of network diagram where Bob might not even
> understand ICE, TURN, or STUN:
> 

Ok, that makes sense.  So a Send indication is only used by a client for sending data to the server to be relayed and a Data indication is only used by the server to send data relayed from a peer to the client?  That is what I am seeing from the specification and from your additional notes.

I was missing it a little but your explanation cleared it up.  Once the server has the data the tunneling is no longer needed to get the data to the peer.  All it needs is the address, which the client should already have.  

Thanks for the information.  It helps a lot.

> Effectively, TURN is a tunneling mechanism between a TURN client and its
> TURN server.  Once on the 'far side' of the TURN server, the data is no longer
> tunneled.
> 
> -d
> 
>