TURN -04

1
TURN -04

• Rohan Mahy
• rohan_at_ekabal.com

2
Normative Change - SetActiveDest

• The client MUST NOT send a Set Active Destination
  request with a REMOTE-ADDRESS attribute over an
  unreliable link (ex UDP) if an active
  destination is already set for that allocation.
• If the client wishes to set a new active
  destination, it MUST wait until a successful
  response is received to a Set Destination Request
  removing the active destination. The client
  SHOULD then continue to wait for an additional
  period of up to 5 seconds until it is extremely
  unlikely that any data from the previous active
  destination might still arrive. Failure to wait
  could cause the client to receive and attribute
  late data forwarded by the TURN server to the
  wrong peer.
• The client MAY wait a shorter period of time if
  the application has built-in addressing (such as
  the RTP Sender Source) that makes it unlikely the
  client would incorrectly attribute late data.

3
Non-Technical Changes

• Change name from STUN Relay back to TURN
• Make consistent with STUN 3489bis draft TURN is
  a STUN extension, it is not a usage
• Greatly shorten UNSAF considerations

4
TCP flow control issue

• TURN server should only buffer a limited amount
  of data
• read enough to keep the TCP connection with the
  longest RTT full at the target data rate
• when too much data in output buffer to peer,
  stop reading from client connection, and vice
  versa
• Need text describing when to start and stop
  reading on TCP connections
• Complicated when there are multiple connections
  between TURN server and peers for the same TURN
  client connection.

peer 1
server
client
peer 2
5
Please review

• Review for
• Mechanism works as described
• Self Consistency
• Readability of prose
• Dont bother with NITS

6
Planned for next rev

• Design Motivations Appendix
• Normative text for TCP flow control issue
• Incorporate design team review of technical
  content and flow of the prose
• Goal of WGLC in October