Re: TURN returning multiple MAPPED-ADDRESSes

Jon,

Apologies for the long delay.

This feature (the ability to provide multiple mapped addresses), was 
actually in a prior revision of the TURN spec. In particular:

http://www.jdrosen.net/papers/draft-rosenberg-midcom-turn-02.txt

Here is the relevant text from that draft:

9.2.6 MORE-AVAILABLE

    In some cases, the server may wish to allocate a user multiple
    addresses when a request is made. An example of this is when the TURN
    server has interfaces on multiple networks, and the client needs to
    obtain an address on each one. In that case, the server itself
    performs one or more pre-allocations when a TURN request is made. To
    inform the client that such a pre-allocation has been made, the
    MORE-AVAILABLE attribute is used. There MAY be more than one of these
    attributes per message. Each one has the same syntax as
    MAPPED-ADDRESS, and indicates the address and port that has been
    pre-allocated.

    A client would allocate one of these pre-allocated addresses by
    including it in a TRANSPORT-PREFERENCES attribute in a subsequence
    Allocate Request.

The motivation was exactly the problem you describe, which came up 
primarily in an enterprise setting where the enterprise wanted to deploy 
a turn server internally, which could be used to receive calls from 
outside (in which case the enterprise NAT/FW was doing port forwarding, 
and the TURN server would need to give out public IP) and also from the 
inside (when there were nats within the enterprise).

I removed this feature in the subsequent revision. As I worked through 
the details, it got more and more complicated. How did refreshes work? 
How did adjacent port reservation work? I found that a lot of complexity 
needed to be added in.

An alternative solution, which I decided was better, was just to 
configure the client with two TURN server addresses, and to have it 
allocate an address from each one. These two addresses could actually be 
the same physical server; it would just be programmed to return public 
IPs for queries on one address, and private for queries against the 
other (note that "address" here refers to the transport address and 
includes port).

There was no impact on the call setup latency, since the turn queries 
could be done in parallel. There is some extra packet overhead for the 
extra turn messaging, but its insignificant compared to the media 
traffic that will flow through it. Since it was simpler and provided the 
same capability, I decided to go that route.

A consequence of this is that it didn't really become an issue for TURN 
the protocol, so much as a usage of TURN. However, I think it would 
probably be a good idea to better document this, and I will add text in 
the coming revision of the specification.

Does that work for you?

Thanks,
Jonathan R.


Jon Ringle wrote:

> Hello,
> 
> I have been studying ICE, STUN, and TURN. I believe that I have come up with a 
> theoretical scenario where TURN in it's current incarnation would have a 
> problem. Perhaps there is another way to solve the problem I describe below?
> 
> Consider the following topology:
> 
>                      +--------+       +----------+
>                      |        |       |   /  \   |
>                      |  PC    |          /SIP \
>                      |        |         /Phone \
>                      |        |        /  102   \
>                      +--------+       ------------
> 
>                          +--------+-------+
>                          |      NAT A     |
>                          |    Symmetric   |
>                          +----------------+
>                                   | DSL, Cable
>                          --+-------------+--
>                   ///////                   \\\\\\\
>                ///                                 \\\
>              ||                                       ||
>             |                Internet                   |
>            |                                             |
>             |                                           |
>              ||                                       ||
>                \\\                                 ///
>                   \\\\\\\                   ///////
>                          ---------+---------
>                                   |
>                               192.0.2.1
>                             +------------+
>                             |   NAT B    |
>        ---------------------| Symmetric  |--------------------------
>                             | No hairpin |
>         10.0.0.0/16         +------------+                  DMZ
> 
> 
> 
>                  +---------+              +---------+
>                  |         |              | TURN/   |
>                  | Proxy   |              | STUN    |
>                  |         |              |  Server |
>                  +---------+              +---------+
>                                            10.0.1.1
> 
>       ...........................................................
> 
> 
>                               +----------+
>                               |   /  \   |
>                                  /SIP \
>                                 /Phone \
>                                /  101   \
>                               ------------
> 
> The following properties apply to the devices:
> SIP Phone 102:
> 	Initiator
> 	Configured to use TURN/STUN server at 192.0.2.1
> 
> NAT A:
> 	symmetric
> 
> NAT B:
> 	symmetric, no hairpin.
> 	Forwards 5060 to Proxy.
> 	Forwards 3478, 5556, and range of UDP ports for RTP to TURN/STUN Server.
> 
> SIP Phone 101:
> 	Responder
> 	Configured to use TURN/STUN server at 10.0.1.1
> 
> Both 102 and 101 will collect a set of local, STUN and TURN derived addresses. 
> However, when 101 does it's connectivity checks on the derived addresses 
> supplied by 102, none of them will succeed. The local address will obviously 
> not work. 101's attempt on STUN on 102's STUN derived address will not 
> succeed because the Home NAT is symmetric. 101's attempt on STUN on 102's 
> TURN derived address (192.0.2.1:xyz) will also not work because Firewall NAT 
> does not support hairpinning.
> 
> The scenario could work if the TURN server had a way of returning multiple 
> MAPPED-ADDRESSes for a single Allocate request. Then the following could 
> happen:
> 
> 1) SIP Phone 102 requests TURN Allocate.
> 2) TURN server Responds with 2 MAPPED-ADDRESSes: 192.0.2.1:xyz and 
> 10.0.1.1:xyz
> 3) SIP Phone 102 now has 2 TURN derived addresses to offer SIP Phone 101.
> 4) SIP Phone 101 could attempt STUN on TURN derived address 10.0.1.1:xyz first 
> based on the fact that it is itself a part of a net-10 network (although this 
> does not guarantee connectivity, but would result in a shorter path than the 
> other TURN derived address in the case where NAT B did support hairpinning).
> 5) SIP Phone 102 successfully contacts SIP Phone 101's STUN server.
> 
> Thanks for taking the time to review this idea. If there is a way to 
> accomplish this already with the current proposed drafts, kindly point me in 
> the right direction.
> 
> Jon
> 
> _______________________________________________
> midcom mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/midcom
> 

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com