Re: TURN returning multiple MAPPED-ADDRESSes

I had changed the name of elements in the diagram but hadn't updated some of 
the description below:

s/Home NAT/NAT A/g
s/Firewall NAT/NAT B/g

Thanks,
Jon

On Saturday 18 September 2004 11:17 pm, 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