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

Haruki Izumikawa <izumikawa@kddilabs.jp> Mon, 12 May 2008 09:08 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 D84693A680F; Mon, 12 May 2008 02:08:01 -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 5187B28C1AB for <sipping@core3.amsl.com>; Mon, 12 May 2008 02:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.532
X-Spam-Level:
X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 nXsxb36nmyZx for <sipping@core3.amsl.com>; Mon, 12 May 2008 02:07:54 -0700 (PDT)
Received: from mandala.kddilabs.jp (unknown [IPv6:2001:200:601:12:230:48ff:fe22:3a84]) by core3.amsl.com (Postfix) with ESMTP id 3F0F53A682B for <sipping@ietf.org>; Mon, 12 May 2008 02:07:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 9533FEC943; Mon, 12 May 2008 17:15:04 +0900 (JST)
Received: from wcg.radio.kddilabs.jp (wcg.radio.kddilabs.jp [172.19.84.3]) by mandala.kddilabs.jp (Postfix) with ESMTP id E5FF3EC8D3; Mon, 12 May 2008 17:15:01 +0900 (JST)
Received: from [127.0.0.1] (dhcp160.east-3f.cn.kddilabs.jp [172.19.126.160]) by wcg.radio.kddilabs.jp (Postfix) with ESMTP id DFBBA160047; Mon, 12 May 2008 17:15:01 +0900 (JST)
Message-ID: <4827FCA8.6080700@kddilabs.jp>
Date: Mon, 12 May 2008 17:15:36 +0900
From: Haruki Izumikawa <izumikawa@kddilabs.jp>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
References: <4819667D.9060600@kddilabs.jp> <4822CD69.5070205@uniroma2.it><48230468.9010602@kddilabs.jp> <48231CEF.307@cisco.com> <5D1A7985295922448D5550C94DE2918001F1C8D5@DEEXC1U01.de.lucent.com>
In-Reply-To: <5D1A7985295922448D5550C94DE2918001F1C8D5@DEEXC1U01.de.lucent.com>
X-Virus-Scanned: by amavisd-new
Cc: Paul Kyzivat <pkyzivat@cisco.com>, 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-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

Dear Keith,

Thank you for your advice, I've found about 50 past requirements 
documents in SIPPING area, and also that the I-Ds were discussed in SIP 
WG or IESG etc after the requirements were judged to require 
standardizations. I recognize that the requirement about SIP mobility 
should be initially discussed in SIPPING WG -it is true necessity or not.

Best regards,

Haruki


DRAGE, Keith (Keith) wrote:
> In SIPPING concentrate on the use cases and developing a set of
> requirements. 
> 
> SIPPING needs to endorse the requirements, not tell SIP that they need
> to develop a particular header.
> 
> So identify what the protocol mechanism needs to do; what conditions it
> needs to meet etc.
> 
> There are various requirements documents out there that SIPPING has
> dealt with in the past - look in tools.ietf.org for sipping drafts with
> requirements in the title. Try and follow what they do.
> 
> Regards
> 
> Keith 
> 
>> -----Original Message-----
>> From: sipping-bounces@ietf.org 
>> [mailto:sipping-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: Thursday, May 08, 2008 4:32 PM
>> To: Haruki Izumikawa
>> Cc: SIPPING LIST
>> Subject: Re: [Sipping] Request for Open discussion about SIP mobility
>>
>>
>>
>> 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-sipbicas
>>>>> t-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
>>
> 

-- 
Haruki Izumikawa
KDDI R&D Laboratories

_______________________________________________
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