TURN

1
TURN

• Jonathan Rosenberg
• Cisco Systems

2
History in Brief

• Originally part of STUN (never issued that way
  though)
• Brought forward as a candidate for one of the two
  pre-midcom deliverables
• Second pre-midcom deliverable evaporated,
  interest in TURN waned
• Gradual increase in interest, revived as an
  individual ID
• Now integrated as core part of the SIP NAT
  traversal strategy stronger industry support,
  but no home

3
Proposal

• Having a WG home and moving to PS brings many
  benefits
• Proper review and comment
• Forum for discussion of issues and comment
• Brings additional resources to work on it
• Show of support to the industry
• Provides a vehicle for extensions
• Behave is a natural choice
• Closest of the existing WG in this area
• Finishing up its existing items
• Already working on STUN, TURNs close cousin (and
  possibly parent next slide)
• Experts whose input I would want are already
  participating

4
TURN Structure

• TURN is confused about whether it is a totally
  separate protocol or whether it is an extension
  to STUN
• Stems from originally being part of STUN
• Makes it difficult to extend separately from STUN
• Makes it less likely that an implementation can
  do both together
• Proposal
• Define as a STUN Usage
• (needs validation)

5
Technical Open Issues

• Differentiating shared secret request from TCP
  binding discovery
• Server starts TLS procedures after TCP connection
  setup in former, not latter
• Simplifications
• Eliminate TURN messaging after setting active
  destination
• Unifies with TCP
• Removes explicit deallocation
• Combined binding discovery and relay allocation
• TURN response also contains source IP/port
• Really nice for ICE