RE: [midcom] Identifying Intra realm calls
"Christian Huitema" <huitema@windows.microsoft.com> Wed, 06 March 2002 16:35 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16673 for <midcom-archive@odin.ietf.org>; Wed, 6 Mar 2002 11:35:32 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA22669 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 11:35:36 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21550; Wed, 6 Mar 2002 11:26:56 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA21524 for <midcom@optimus.ietf.org>; Wed, 6 Mar 2002 11:26:54 -0500 (EST)
Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16121 for <midcom@ietf.org>; Wed, 6 Mar 2002 11:26:50 -0500 (EST)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 6 Mar 2002 08:26:23 -0800
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 06 Mar 2002 08:26:22 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 08:26:22 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 6 Mar 2002 08:26:22 -0800
Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Wed, 6 Mar 2002 08:23:28 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: [midcom] Identifying Intra realm calls
Date: Wed, 06 Mar 2002 08:23:28 -0800
Message-ID: <F66A04C29AD9034A8205949AD0C90104032700CE@win-msg-02.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: [midcom] Identifying Intra realm calls
thread-index: AcHE52v5psLMfA02QA6yKGQ1U8SzmAAQw+xQ
From: Christian Huitema <huitema@windows.microsoft.com>
To: Cedric Aoun <cedric.aoun@nortelnetworks.com>, "Midcom IETF (E-mail)" <midcom@ietf.org>
Cc: Sanjoy Sen <sanjoy@nortelnetworks.com>
X-OriginalArrivalTime: 06 Mar 2002 16:23:28.0999 (UTC) FILETIME=[3FEF2F70:01C1C52B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA21525
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <midcom.ietf.org>
X-BeenThere: midcom@ietf.org
Content-Transfer-Encoding: 8bit
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:cedric.aoun@nortelnetworks.com] 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-intrarealmcalls-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 (midcom-interest@eng.registro.br). Thanks Cedric Cedric Aoun Nortel Networks France mailto:cedric.aoun@nortelnetworks.com _______________________________________________ midcom mailing list midcom@ietf.org https://www1.ietf.org/mailman/listinfo/midcom
- [midcom] Identifying Intra realm calls Cedric Aoun
- RE: [midcom] Identifying Intra realm calls Christian Huitema
- RE: [midcom] Identifying Intra realm calls Jiri Kuthan
- RE: [midcom] Identifying Intra realm calls Sanjoy Sen
- Re: [midcom] Identifying Intra realm calls Keith Moore
- RE: [midcom] Identifying Intra realm calls Sanjoy Sen
- Re: [midcom] Identifying Intra realm calls Jonathan Rosenberg
- Re: [midcom] Identifying Intra realm calls Melinda Shore