IETF Logo Mail Archive

RE: [Sipping] Making SBCs more transparent for NAT traversal

Markus.Isomaki@nokia.com Wed, 02 November 2005 20:59 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXPhn-0008Eg-EQ; Wed, 02 Nov 2005 15:59:35 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EXPhl-0008EY-AS for sipping@megatron.ietf.org; Wed, 02 Nov 2005 15:59:33 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07783 for <sipping@ietf.org>; Wed, 2 Nov 2005 15:59:12 -0500 (EST)
From: Markus.Isomaki@nokia.com
Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EXPwP-0006PG-3Q for sipping@ietf.org; Wed, 02 Nov 2005 16:14:42 -0500
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jA2KxPd1017040; Wed, 2 Nov 2005 22:59:28 +0200
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 22:59:29 +0200
Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 2 Nov 2005 22:59:27 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sipping] Making SBCs more transparent for NAT traversal
Date: Wed, 02 Nov 2005 22:59:27 +0200
Message-ID: <C84E0A4ABA6DD74DA5221E0833A35DF303816CEE@esebe101.NOE.Nokia.com>
Thread-Topic: [Sipping] Making SBCs more transparent for NAT traversal
Thread-Index: AcXfe0uyxebRdGlrQZ6iR8fOigpGiAAc9FMA
To: jh@tutpro.com, mhammer@cisco.com
X-OriginalArrivalTime: 02 Nov 2005 20:59:27.0729 (UTC) FILETIME=[50009E10:01C5DFF0]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: quoted-printable
Cc: john.loughney@nokia.com, sipping@ietf.org
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Juha,

> 
> i still haven't got any answer why something would need to be
> standardized for this kind of stupid UA/stupid NAT scenario, 
> intelligent
> sip proxy/media proxy, since it seems to work fine within the 
> limits of
> already existing standards.
>

I think you are right, but in that case you will run into issues discussed in http://www.ietf.org/internet-drafts/draft-camarillo-sipping-sbc-funcs-02.txt and also to scaling issues if all media needs to traverse the media proxies.

ICE, STUN and TURN provide another set of tools, and the question is whether they are good enough in the cases constrained by power consumption and session setup latency. If yes, there is no new standardization needed. If not, we may need to reconsider.
 
> -- juha
> 

Markus

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sip@ietf.org for new developments of core SIP

v2.23.0 | Report a Bug | By Email