Subject: RE: [midcom] Identifying Intra realm calls

From: "Sanjoy Sen"<[email-masked]>
Date: Wed, 6 Mar 2002 11:18:52 -0600

Right. This end-to-end STUN may be useful in detecting direct connectivity
in some cases (basically detecting that there's no NAT between them). I've
not given enough thought on the error cases though. Thoughts from STUN
authors?

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Sent: Wednesday, March 06, 2002 10:50 AM
> To: Christian Huitema; Aoun, Cedric [QPD:MA01:EXCH]; Midcom IETF
> (E-mail)
> Cc: Sen, Sanjoy [NGC:B692:EXCH]
> Subject: RE: [midcom] Identifying Intra realm calls
> 
> 
> Note there is also the option of having end-to-end STUN and embedding
> STUN servers in hosts like we do with ping. That makes some cases more
> simple.
> 
> -Jiri
> 
> At 05:23 PM 3/6/2002, Christian Huitema wrote:
> >You are correct: many NATs will not "send back" the traffic. 
> The STUN statement is wrong: when two parties are behind the 
> same NAT, not only is the solution not very efficient; in 
> fact, it does not always work. We should only use a solution 
> like STUN when we know that the two stations are "far apart". 
> Even so, there are failure modes, e.g. in the cases of dual 
> NAT: an ISP allocate 10/8 addresses to its customers, who in 
> turn run a NAT.
> >
> >A partial solution is to use multicast discovery to find out 
> whether the other party is local: from the UDP port that uses 
> STUN, send a multicast packet to a conventional IPv4 
> multicast address and port, documenting something like "I am 
> local and my STUN address is x.x.x.x:p"; the receiver of 
> these packet keeps a catalog; this is what is document in 
> version 04 of the shipworm/teredo draft. You may combine the 
> solution with a hint, e.g. the fact that the STUN mapped 
> addresses of the parties look alike. However, there will 
> still be failure modes, such as the 10/8 ISP.
> >
> >The only real solution to this problem is to use IPv6 and 
> global addresses. All other solutions are hacks.
> >
> >-- Christian Huitema
> >
> >-----Original Message-----
> >From: Cedric Aoun [mailto:[email-masked]] 
> >Sent: Wednesday, March 06, 2002 12:16 AM
> >To: Midcom IETF (E-mail)
> >Cc: Sanjoy Sen
> >Subject: [midcom] Identifying Intra realm calls
> >
> >Hello, 
> >One of the open issues that had been briefly discussed in 
> the mailing list in the context of the pre-Midcom solutions - 
> STUN, PHANTOM and MINT - is how to effectively route 
> intra-realm calls (e.g. calls behind the same NAT), i.e., how 
> does the client or a signaling server determine that the 
> called party is in the same network realm and the media is 
> directly routable without going through the NAT or a relay 
> NAT (i.e. a Media Proxy). For example, the last para of Sec 
> 9.3 in STUN draft states: It is possible that both 
> participants in the multimedia session are behind the same 
> NAT. In that case, both will repeat this procedure
> >   above, and both will obtain public address bindings. When 
> one sends 
> >   media to the other, the media is routed to the nat, and 
> then turns 
> >   right back around to come back into the enterprise, where it is 
> >   translated to the private address of the recipient. This is not 
> >   particularly efficient, but it does work. 
> >Note that, the above solution is not applicable to NATs all 
> vendors. Given that a significant percentage of Enterprise 
> calls are intra-realm, the issue, if resolved, will lead to 
> considerable saving of egress bandwidth at the NAT and will 
> lead to general improvement in service quality.
> >Note that this is also an issue within the MIDCOM framework. 
> >An ID was submitted to discuss this issue 
> http://www.ietf.org/internet-drafts/draft-aoun-midcom-intrarea
lmcalls-00.txt 
>The intent of this ID is to initiate some discussions (perhaps, offline)
towards a solution for this issue. The intent is in no way to disrupt the
progress of the WG's chartered work items, so, if you're interested to work
on this problem, please send comments offline and we can move the
discussions to a private mailing list ([email-masked]).
>Thanks 
>Cedric 
>Cedric Aoun 
>Nortel Networks 
>France 
>mailto:[email-masked] 
>
>  
>
>_______________________________________________
>midcom mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/midcom

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Mar 2002 02:01:19 -0500

Sanjoy Sen wrote:
> 
> Right. This end-to-end STUN may be useful in detecting direct
> connectivity in some cases (basically detecting that there's no NAT
> between them). I've not given enough thought on the error cases though.
> Thoughts from STUN authors?

I think its workable. stun-01 did make it in before the I-D deadline, so
you should see it shortly. There is additional text in there that
mentions the possibility of e2e usage between endpoints directly.
However, it does not go into any details on the application of this to
discover whether two parties are behind the same nat. 

-Jonathan R.

> > From: Jiri Kuthan [ mailto:[email-masked]
> <mailto:[email-masked]> ]
> > >From: Cedric Aoun [ mailto:[email-masked]
> <mailto:[email-masked]> ]
> <http://www.ietf.org/internet-drafts/draft-aoun-midcom-intrarea>
> lmcalls-00.txt
> >The intent of this ID is to initiate some discussions (perhaps,
> offline) towards a solution for this issue. The intent is in no way to
> disrupt the progress of the WG's chartered work items, so, if you're
> interested to work on this problem, please send comments offline and we
> can move the discussions to a private mailing list
> ([email-masked]).
> 
> >Thanks
> >Cedric
> >Cedric Aoun
> >Nortel Networks
> >France
> <mailto:[email-masked]>
> >
> >
> >
> <https://www1.ietf.org/mailman/listinfo/midcom>

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

---

From: Melinda Shore <[email-masked]>
Date: Thu, 07 Mar 2002 08:39:48 -0500

>discover whether two parties are behind the same nat. 

Not to be tiresome about this, but it's basically the network-
friendlier proposal with the far endpoint writing the address it
sees rather than having the NAT write the address it's going to
use.  It solves a bunch of problems, including some identified by
the IAB in the UNSAF document.

Melinda