[midcom] Identifying Intra realm calls

"Cedric Aoun"<cedric.aoun@nortelnetworks.com> Wed, 06 March 2002 08:18 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 DAA27176 for <midcom-archive@odin.ietf.org>; Wed, 6 Mar 2002 03:18:31 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id DAA21656 for midcom-archive@odin.ietf.org; Wed, 6 Mar 2002 03:18:33 -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 DAA21576; Wed, 6 Mar 2002 03:16:13 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21546 for <midcom@optimus.ietf.org>; Wed, 6 Mar 2002 03:16:12 -0500 (EST)
Received: from znsgs01r.europe.nortel.com (h90s128a211n47.user.nortelnetworks.com [47.211.128.90]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27150 for <midcom@ietf.org>; Wed, 6 Mar 2002 03:16:08 -0500 (EST)
Received: from zwcwc012.europe.nortel.com (zwcwc012.europe.nortel.com [47.73.112.187]) by znsgs01r.europe.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g268FD508907 for <midcom@ietf.org>; Wed, 6 Mar 2002 08:15:13 GMT
Received: by zwcwc012.europe.nortel.com with Internet Mail Service (5.5.2653.19) id <FQTTBXN8>; Wed, 6 Mar 2002 08:15:42 -0000
Message-ID: <C76021BAF2A6D5119DE500508BCF4552012FF1C4@zctfc004.europe.nortel.com>
From: Cedric Aoun <cedric.aoun@nortelnetworks.com>
To: "Midcom IETF (E-mail)" <midcom@ietf.org>
Cc: Sanjoy Sen <sanjoy@nortelnetworks.com>
Date: Wed, 06 Mar 2002 08:15:34 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1C4E7.1742D570"
Subject: [midcom] Identifying Intra realm calls
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

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


>  
>