Traversal Using Relays around NAT (TURN) Extensions for TCP Allocations
RFC 6062

I stubmled a bit over "TCP allocation".
I think this is shorthand for "TURN allocation for a TCP session".
If I'm right, it is probably worth dropping this into the Introduction so that it is clear. If I am wrong, there is even more need to add an explanation.

I found the restriction on only having a single outgoing TCP connection to a particular address/port combination to be a bit too restrictive. Although I suspect why you've done that. However some discussion of the topic in the document would have been helpful.

The TCP connection used for control is sometimes called "control
connection" and sometimes "control channel".  It would help
readability to use one name consistently.

For consistency with text in section 4.1 and readability, I suggest
changing this text in section 3:

OLD:

   To obtain a TCP-based allocation, a client must have a TCP or TLS
   connection to its TURN server.  Using that connection, it sends an
   Allocate request.

NEW:

   To obtain a TCP-based allocation, a client first opens a TCP or TLS
   connection to its TURN server.  The client then sends an Allocate
   request over that control connection.

In the following paragraph in section 3, s/address/port/ ??

   If a client wishes to establish a TCP connection to a peer from that
   allocated address, it issues a Connect request to the TURN server
   over the control connection. 

At the end of section 3:

   The TURN server will relay the data between the client and peer data
   connections, utilizing an internal buffer.  However, back pressure is
   used in order to achieve end-to-end flow control.  If the buffer from
   client to peer fills up, the TURN server ceases to read off the
   client data connection, which causes TCP backpressure through the OS
   towards the client.

This text describes an implementation detail, in my opinion.  I can
imagine an implementation that simply copies directly between the two
data connections as data is available on each.  I suppose you could
argue that the implementation uses a small, one segment buffer.  In
any event, adding another buffer to the send and receive buffers in
the TCBs for the two data connections may affect scalability.

From section 4.3 (also in section 4.4):

   Once
   established, the client MUST send a ConnectionBind request.

I assume the ConnectionBind request is sent over the newly established
TCP connection (which will become the data connection).  In my
opinion, the connection to be used should be clarified here.

In section 5.5:

   When a client data connection is closed or times out, the server MUST
   close the corresponding peer data connection.

what does "times out" mean?