Re: [Sipping] Request for Open discussion about SIP mobility

"Elwell, John" <john.elwell@siemens.com> Tue, 13 May 2008 13:00 UTC

Return-Path: <sipping-bounces@ietf.org>
X-Original-To: sipping-archive@optimus.ietf.org
Delivered-To: ietfarch-sipping-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1D813A6881; Tue, 13 May 2008 06:00:41 -0700 (PDT)
X-Original-To: sipping@core3.amsl.com
Delivered-To: sipping@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2734428C2C1 for <sipping@core3.amsl.com>; Tue, 13 May 2008 06:00:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.767
X-Spam-Level:
X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUSrN2KKHFVI for <sipping@core3.amsl.com>; Tue, 13 May 2008 06:00:39 -0700 (PDT)
Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 21CB53A6837 for <sipping@ietf.org>; Tue, 13 May 2008 06:00:39 -0700 (PDT)
Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0K0T00M0I3XPDL@siemenscomms.co.uk> for sipping@ietf.org; Tue, 13 May 2008 13:27:25 +0100 (BST)
Date: Tue, 13 May 2008 13:27:23 +0100
From: "Elwell, John" <john.elwell@siemens.com>
In-reply-to: <48294D1A.1030102@uniroma2.it>
To: Stefano Salsano <stefano.salsano@uniroma2.it>
Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0B842E5@GBNTHT12009MSX.gb002.siemens.net>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.5
Thread-Topic: [Sipping] Request for Open discussion about SIP mobility
Thread-Index: Aci00T8RvonYcJb0R4OwMtrENOwBvAAIysJg
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
References: <4819667D.9060600@kddilabs.jp> <4822CD69.5070205@uniroma2.it> <48230468.9010602@kddilabs.jp> <48231CEF.307@cisco.com> <45EDF1C5D301ED41A339796A9F979F720FDEC9@eris.office> <48234ED2.7070603@cisco.com> <F66D7286825402429571678A16C2F5EE035CBFFE@zrc2hxm1.corp.nortel.com> <4824273E.3000908@kddilabs.jp> <482604A9.2000502@research.telcordia.com> <48267A77.2080803@cisco.com> <48285DCE.6030803@uniroma2.it> <0D5F89FAC29E2C41B98A6A762007F5D0B83F6E@GBNTHT12009MSX.gb002.siemens.net> <48294D1A.1030102@uniroma2.it>
Cc: Paul Kyzivat <pkyzivat@cisco.com>, Ashutosh Dutta <adutta@research.telcordia.com>, SIPPING LIST <sipping@ietf.org>, Mary Barnes <mary.barnes@nortel.com>, Saverio Niccolini <Saverio.Niccolini@nw.neclab.eu>
Subject: Re: [Sipping] Request for Open discussion about SIP mobility
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: sipping-bounces@ietf.org
Errors-To: sipping-bounces@ietf.org

Stefano, 

> -----Original Message-----
> From: sipping-bounces@ietf.org 
> [mailto:sipping-bounces@ietf.org] On Behalf Of Stefano Salsano
> Sent: 13 May 2008 09:11
> To: Elwell, John
> Cc: Paul Kyzivat; Ashutosh Dutta; SIPPING LIST; Mary Barnes; 
> Saverio Niccolini
> Subject: Re: [Sipping] Request for Open discussion about SIP mobility
> 
> Elwell, John wrote:
> > [JRE] This is just another instance of the general problem of B2BUAs
> > (e.g. SBCs) providing functionality to compensate for 
> endpoints that do
> > not fully support fairly basic mechanisms in SIP, namely 
> re-INVITE in
> > this particular case. It is a fact that such middleboxes do 
> exist, and
> > we can argue about whether they exist for good reasons or 
> not. However,
> > does the IETF really want to specify such work-arounds for these
> > problems, rather than trying to address the fundamental problem?
> > 
> 
> Dear John,
> 
> it is not only a problem of specifying a work-around for "basic" 
> endpoints (though this may be a useful "side-achievement"...)
> 
> In my opinion there are some conceptual reasons why we should provide 
> the possibility to handle terminal mobility on the side of the Mobile 
> Device, rather then on the side of the correspondant node. 
> The user of 
> the Mobile Device has a strong interest in the reliability and 
> performance of this mobility, and may want to control it better than 
> relying on the CN capabilities.
> 
> And as I pointed out, there are some performance issues that 
> may require 
> an improvement with respect to the curent re-INVITE mechanisms.
[JRE] I am happy as long as we do this for the right reasons. If it is
purely as a work-around for non-compliant SIP devices, I have a problem.
But it there are other sound technical reasons, such as performance, I
don't have a problem.

John
_______________________________________________
Sipping mailing list  https://www.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