TURN issue #1: MAPPED-ADDRESS reunification
Jonathan Rosenberg <jdrosen <at> cisco.com>
2005-12-05 15:56:41 GMT
As I mentioned during the IETF meeting, I am working on a revision of
STUN that structures the protocol into a "framework" layer (though we
agreed not to call it that per se), and various "usages" that can define
extensions, define what messages and attributes get used, and define
various security considerations. The plan is for TURN to become a STUn
usage rather than a separate protocol. I think this is a good thing,
since TURN repeats a lot of stun, and its relationship with it is unclear.
One of the things I mentioned as a side benefit of this unification is
that the TURN Allocate request could perform a stun check as a side
effect. The Allocate response can include the source IP/port of the
Allocate request (equivalent to the MAPPED-ADDRESS in the STUn Binding
Response). This way, an ICE endpoint, for example, can issue just a
single Allocate request to a turn server, and get back its stun-derived
AND turn-derived addresses in one operation. This will reduce the
overhead of ICE and simplify things. There seemed to be good support for
doing this when I proposed it in the meeting last month.
So, whats the issue? Syntax, unfortunately.
The IDEAL solution for doing this is that the MAPPED-ADDRESS attribute
always indicate the source IP/port as seen by the server in the request,
and that it be usable with the existing STUN Binding Response and the
TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS,
and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the
address allocated by the TURN server itself.
So, there are several options:
1. break backwards compatibility with TURN, and define MAPPED-ADDRESS to