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

Paul Kyzivat <pkyzivat@cisco.com> Thu, 08 May 2008 15:35 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 A0CD528D1CC; Thu, 8 May 2008 08:35:06 -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 E71CF28D0CD for <sipping@core3.amsl.com>; Thu, 8 May 2008 08:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.089
X-Spam-Level:
X-Spam-Status: No, score=-6.089 tagged_above=-999 required=5 tests=[AWL=0.510, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 eQ-itmvU-RQc for <sipping@core3.amsl.com>; Thu, 8 May 2008 08:34:28 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 7ADCF3A7244 for <sipping@ietf.org>; Thu, 8 May 2008 08:31:28 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.27,455,1204520400"; d="scan'208";a="7685937"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 08 May 2008 11:31:24 -0400
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m48FVOHh006145; Thu, 8 May 2008 11:31:24 -0400
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m48FVOfv028637; Thu, 8 May 2008 15:31:24 GMT
Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 11:31:24 -0400
Received: from [161.44.174.168] ([161.44.174.168]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 May 2008 11:31:24 -0400
Message-ID: <48231CEF.307@cisco.com>
Date: Thu, 08 May 2008 11:31:59 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Haruki Izumikawa <izumikawa@kddilabs.jp>
References: <4819667D.9060600@kddilabs.jp> <4822CD69.5070205@uniroma2.it> <48230468.9010602@kddilabs.jp>
In-Reply-To: <48230468.9010602@kddilabs.jp>
X-OriginalArrivalTime: 08 May 2008 15:31:24.0165 (UTC) FILETIME=[92E59B50:01C8B120]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4590; t=1210260684; x=1211124684; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20<pkyzivat@cisco.com> |Subject:=20Re=3A=20[Sipping]=20Request=20for=20Open=20disc ussion=20about=20SIP=20mobility |Sender:=20 |To:=20Haruki=20Izumikawa=20<izumikawa@kddilabs.jp>; bh=xc4TGBO0TIhK01f3jAmu0kvYc7A1rOfqtR8DQBkbJGI=; b=KKT7ntA0/UyLtSkpC6HOytkB0tD3r3Ba3NDjGXSeFWfc9WPgoLFCWVAoog g1KBOXttvB82/8fu9pfV5bAEolast9pcWmfOdfjJZMhtcc1SGYNjLpAKQZQU mgS09Tg//0;
Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: SIPPING LIST <sipping@ietf.org>
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-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


Haruki Izumikawa wrote:
> Dear Stefano,
> 
> Thank you for your interest. I have reviewed your updated I-Ds. As you 
> pointed, I also think that we share common requirements and scenarios.
> 
> I understand the addition of a new SIP header could not be a major 
> concern. In fact, I have proposed a new SIP header for bicasting before. 
> But, I'm afraid that the addition of a new SIP header falls into terms 
> of reference of SIP WG, not SIPPING WG. How do you feel about it?

That is true. But the work could and should start in SIPPING. If it 
eventually is decided that a new header is needed then that work would 
be shifted to the SIP WG with blessings from SIPPING. Since there is a 
huge overlap in participation that should not cause any difficulty.

	Thanks,
	Paul

> Best wishes,
> 
> Haruki
> 
> 
> Stefano Salsano wrote:
>> Dear Haruki,
>>
>> thank you for restarting discussion on SIP mobility. I agree with the
>> importance to discuss this topic in this WG.
>>
>> I'd like to bring again to the attention of the WG two related internet
>> drafts that we submitted some time ago and that we've now updated
>>
>> [1] Requirements for vertical handover of multimedia sessions using SIP 
>> http://tools.ietf.org/html/draft-niccolini-sipping-siphandover-03
>>
>> [2] A solution for vertical handover of multimedia sessions using SIP 
>> http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution-02
>>
>> Now I would like in particular to focus on the requirements draft [1] 
>> and to make some comparison with your work.
>>
>> It seems that the requirements and scenarios we consider are largely
>> overlapping (while we take different approaches for solutions).
>>
>> We have in common the idea of letting the Correspondant Node as much as
>> possible not involved in the seamless handover procedure and the
>> introduction of some sort of B2BUA to assist in the procedure. We also
>> share the idea that bi-casting can improve the handover and needs to be
>> properly managed.
>>
>> As you have already outlined in your draft, a difference in the
>> requirements is that you would like not to introduce new
>> headers/parameters while we allow it.
>>
>> My point here is that the introduction of the new headers in our
>> scenario only concerns the handover-capable mobile device and the
>> intermediate element which is in charge to assist in the handover
>> procedure. Correspondant Node and all other SIP elements are not touched
>> anyhow. I feel that in any case there the need to implement a lot of
>> specicif logic to properly handle the bi-casting (not to mention the
>> problem of discovery of intermediate element that you deliberately
>> neglect in your draft to simplify the problem). Therefore the addition
>> of a new header may not be the biggest issue.
>>
>> Anyway these aspects could be clarified with some deeper technical
>> discussion, which I hope can start in the WG.
>>
>> Best regards,
>> Stefano
>>
>> Haruki Izumikawa wrote:
>>> Hello folks,
>>>
>>> I'd like to have an open discussion about SIP-based mobility in this ML.
>>> Mobility managements using SIP have been actively studied and developed
>>> worldwide since "Mobility Support Using SIP" (by Elin and Henning) was
>>> published. SIP-based mobility would have strong advantages such as its
>>> great affinity for an application as well as flexibility, i.e., terminal
>>> mobility can be optimally supported independent from underlying network.
>>> On the other hand, despite many advantages, it is not used for
>>> large-scale commercial yet. In addition, the discussion about SIP-based
>>> mobility in IETF seems to be undynamic.
>>> These days, a multimode terminal is getting popular. Each access
>>> networks, e.g., cellular and WLAN, have different characteristics in
>>> terms of throughput or delay. In such a heterogeneous network, SIP
>>> becomes more useful tool for mobility management because of its
>>> flexibility. The quality of a multimedia service can be adaptively
>>> changed in accordance with a nature of an access networks even after
>>> changing an access network. I think it is time to resume discussing
>>> about SIP-based mobility. For your information, I have submitted I-D
>>> regarding seamless session handoff by SIP-based bicasting.
>>> http://www.ietf.org/internet-drafts/draft-izumikawa-sipping-sipbicast-01.txt 
>>>
>>> I would be happy to hear frank opinions of SIP specialists.
>>>
>>> Best regards,
>>>
>>> Haruki
>>>
>>>
>>
> 
_______________________________________________
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