IETF Logo Mail Archive

Re: [SAFE] nat-control-stun-usage-04

Rémi Denis-Courmont <remi.denis-courmont@nokia.com> Thu, 11 October 2007 10:57 UTC

Return-path: <safe-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ifvjb-0005m8-4b; Thu, 11 Oct 2007 06:57:43 -0400
Received: from safe by megatron.ietf.org with local (Exim 4.43) id 1IfvjZ-0005ko-Vj for safe-confirm+ok@megatron.ietf.org; Thu, 11 Oct 2007 06:57:41 -0400
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IfvjZ-0005kf-Kw for safe@ietf.org; Thu, 11 Oct 2007 06:57:41 -0400
Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IfvjZ-0005SA-3V for safe@ietf.org; Thu, 11 Oct 2007 06:57:41 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l9BAvYfa017592; Thu, 11 Oct 2007 13:57:34 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:57:14 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:57:14 +0300
Received: from esdhcp04049.research.nokia.com ([172.21.40.49]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Oct 2007 13:57:14 +0300
From: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Organization: Nokia TP-SP-SWD
To: safe@ietf.org
Subject: Re: [SAFE] nat-control-stun-usage-04
Date: Thu, 11 Oct 2007 13:57:44 +0300
User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405)
References: <042001c80b74$509c46b0$c3f0200a@cisco.com>
In-Reply-To: <042001c80b74$509c46b0$c3f0200a@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Message-Id: <200710111357.44688.remi.denis-courmont@nokia.com>
X-OriginalArrivalTime: 11 Oct 2007 10:57:14.0105 (UTC) FILETIME=[7B262690:01C80BF5]
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc:
X-BeenThere: safe@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Self-Address Fixing Evolution <safe.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/safe>, <mailto:safe-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/safe>
List-Post: <mailto:safe@ietf.org>
List-Help: <mailto:safe-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/safe>, <mailto:safe-request@ietf.org?subject=subscribe>
Errors-To: safe-bounces@ietf.org

Le Wednesday 10 October 2007 22:32:37 ext Dan Wing, vous avez écrit :
> We just submitted a new version of STUN Control,
> http://www.ietf.org/internet-drafts/draft-wing-behave-nat-control-stun-usag
>e-0 4.txt
>
> The changes were mostly organizational and editorial, and included:
>
>    o  Clarified that all existing bindings, for that source IP address
>       and UDP port, are controlled with STUN Control.
>
>    o  Introduction now concentrates on the primary purpose of STUN
>       Control, namely reducing keepalive traffic for SIP-Outbound.

As far as I understand, STUN in general, and STUN in particular, can be used 
for any UDP-based always-on protocol. ESP-in-UDP, TEREDO, perhaps some long 
usages of RTP (such as MIDI-over-RTP(?) or RTSP-based streaming), proprietary 
UDP overlays (not giving any names)...

And then, there is the relation to ICE in finding "intermediary" NAT mappings 
in nested NATs scenarios.

At the same time, I thought SIP Outbound was going to recommend TCP, so that 
it could end up being a less likely "customer" of STUN control??

-- 
Rémi Denis-Courmont


_______________________________________________
SAFE mailing list
SAFE@ietf.org
https://www1.ietf.org/mailman/listinfo/safe

v2.23.0 | Report a Bug | By Email