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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 May 2008 09:39:56 -0400

Interesting document. I am happy to see more exploration of the subject 
area.

The a=bicast approach only seems sufficient when there is a single media 
stream to deal with. If there are multiple media streams, then it gets 
tricky to match them all up. The grouping framework is a better 
solution. It would be helpful to see an example where there there are 
two media streams that each need to be bicast.

One thing that isn't clear to me is now the recipient of the bicast 
traffic matches up the two streams and decides what media to render. Is 
there enough information in RTP, even when transcoding has been 
performed on one or both of the streams, to allow this to work reliably? 
(Disclaimer - I know little about RTP.)

And related to that - what about non-RTP media? This same scenario is 
applicable to less conventional media, such as IM. While technically it 
is possible to follow the pattern you have outlined to establish bicast 
MSRP, the identification of duplicate messages will require a different 
solution.

I also would be interested to hear your thoughts about the urgency of 
cutover and the mechanics of doing it. I know you state an assumption 
that there is some overlap in coverage of the two access networks. And 
without that things get very difficult. But the overlap may not be very 
extensive, so it may be wise to quickly get from one to the other 
entirely - for signaling as well as media. So for instance it might be 
desirable to switch the signaling path to AN2 ASAP, before bicasting 
ceases. Or, it may be prudent to find a way to maintain "bicast" 
signaling paths as well for the time when it is uncertain which AN might 
remain available.

	Thanks,
	Paul

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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Ashutosh Dutta <[email-masked]>
Date: Mon, 05 May 2008 10:04:55 -0400

Haruki,
        Thanks for bringing this discussion up again. Few years back we 
did create a mailing list and web page to add some of the references 
with respect to SIP-based mobility work. This reference list is not 
up-to-date by any means and needs to be updated as people have done more 
work on this recently.

Here is the pointer to the archive that has some relevant materials. I 
can update this list with more recent papers in this area.

http://www.argreenhouse.com/SIP-mobile/

Regards
Ashutosh

---

From: Haruki Izumikawa <[email-masked]>
Date: Tue, 06 May 2008 01:57:25 +0900

Hello Paul,

I should like to thank you for your useful comments.

 > The a=bicast approach only seems sufficient when
 > there is a single media stream to deal with.
 > If there are multiple media streams, then it gets
 > tricky to match them all up. The grouping framework
 > is a better solution. It would be helpful to see
 > an example where there there are

[HI] You are quite right. In the a=bicast approach, it indeed gets 
difficult to associate one media stream with others when there are 
multiple media streams. As you pointed out, the extension of grouping 
framework seems to be suitable.

 > One thing that isn't clear to me is now the recipient
 > of the bicast traffic matches up the two streams and
 > decides what media to render. Is there enough
 > information in RTP, even when transcoding has been

[HI] When I made prototype software regarding SIP-based bicasting, I 
adopted a cross-layer approach. In fact, as you concerned, I think RTP 
layer itself cannot distinguish which media streams to be rendered. In 
the prototype software, media streams from an I/F of targeted network 
are rendered.

 > And related to that - what about non-RTP media?
 > This same scenario is applicable to less conventional
 > media, such as IM. While technically it is possible
 > to follow the pattern you have outlined to establish
 > bicast MSRP, the identification of duplicate messages
 > will require a different solution.

[HI] I think the bicasting solution is needed for realtime multimedia 
streams in which re-transmission cannot be acceptable. Therefore, I 
don't know some services such as IM or file transfer using MSRP need 
bicasting support. In fact, I haven't considered the concern you pointed 
out. I'm going to have to weigh this concern more carefully. Thank you 
for bringing this matter up.

 > I also would be interested to hear your thoughts about
 > the urgency of cutover and the mechanics of doing it.
 > I know you state an assumption that there is some
 > overlap in coverage of the two access networks. And
 > without that things get very difficult. But the overlap
 > may not be very extensive, so it may be wise to
 > quickly get from one to the other entirely - for
 > signaling as well as media. So for instance it might be
 > desirable to switch the signaling path to AN2 ASAP,
 > before bicasting ceases. Or, it may be prudent
 > to find a way to maintain "bicast" signaling paths
 > as well for the time when it is uncertain which AN might
 > remain available.

[HI] As you pointed out, I should consider the case where a terminal 
loses a connection of AN1 during handoff from AN1 to AN2. In my opinion, 
same as your second view, it could be preferable to maintain bicast 
signaling paths on a stable wireless system such as cellular. In 
addition, related to that, I think it is important to consider a 
ping-pong movement. Regarding both of them, it would be necessary to 
take into consideration an underlying radio behavior, e.g., penetration 
(coverage area) and fluctuation. This kind of issue is important to 
realize an intelligent mobility service in market.

Best wishes,

Haruki

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Haruki Izumikawa <[email-masked]>
Date: Tue, 06 May 2008 02:06:32 +0900

Hi Dutta,

Thank you for all the information. I went through the web pages. Though, 
unfortunately, I could not find the SIP Mobile mailing list Archive, I 
found that the references you organized are very useful. And, I am very 
interested in "SIP-Mobile Minutes" in 50th IETF. I would care the 
conclusion of the informal meeting and the direction of the SIP 
mobility. If you have any information concerning them, please let me know.

Best regards,

Haruki

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 05 May 2008 19:50:23 -0400

> the prototype software, media streams from an I/F of targeted network 

Perhaps it doesn't matter which is rendered as long as both are being 
received adequately. But if one stops being received, either because 
connectivity is lost or because the handoff back to unicast is 
performed, if the remaining stream isn't the one that was being 
rendered, then one needs to be able to discern where in that stream to 
begin rendering. Is some of it duplicating data that has already been 
rendered?

I guess for RTP this can be handled via the time base if the streams 
remain synchronized after possibly going through a transcoder. Is that 
expected?

> for bringing this matter up.

I guess it depends on what you mean by "acceptable".
If you move from wifi to cellular access while IMing, I will not be 
happy if some IMs from you are dropped or duplicated.

In fact, I think this is more noticable for IM than for voice. With 
voice a few dropped packets may cause a "glitch" but probably will not 
create a significant loss of information. But a single dropped IM can be 
a large loss of information.

And now people are talking about using MSRP for real time text as well.

So while it is perhaps of lower priority and interest, I think media 
such as MSRP are worthy of some consideration.

Thanks,
	Paul

---

From: Haruki Izumikawa <[email-masked]>
Date: Tue, 06 May 2008 13:11:09 +0900

Paul,

Thank you for your prompt reply.

> remain synchronized after possibly going through a transcoder. Is that 

[HI] Yes. Since the independent multimedia streams are transcoded, their 
RTP timestamps cannot be synchronozed and compared. So, in the prototype 
software, the transcoder associates the time for the synchronous 
rendering with the RTP header of the respective streams. In addition, an 
intra-frame is also marked on the RTP header if MPEG or H.264 is used as 
the video compression technology.

>> bicasting support. In fact, I haven't considered the concern you 
>> pointed out. I'm going to have to weigh this concern more carefully. 
>> Thank you for bringing this matter up.
> 

[HI] I understand an importance of dealing with IM. I'll take the media 
such as MSRP into account. Thanks.

Regards,

Haruki

>> loses a connection of AN1 during handoff from AN1 to AN2. In my 
>> opinion, same as your second view, it could be preferable to maintain 
>> bicast signaling paths on a stable wireless system such as cellular. 
>> In addition, related to that, I think it is important to consider a 
>> take into consideration an underlying radio behavior, e.g., 
>> penetration (coverage area) and fluctuation. This kind of issue is 
>> important to realize an intelligent mobility service in market.
> 
> Thanks,
>     Paul
> 
>> Best wishes,
>>
>> Haruki
>>
>>
>> Paul Kyzivat wrote:
>>> Interesting document. I am happy to see more exploration of the 
>>> subject area.
>>>
>>> The a=bicast approach only seems sufficient when there is a single 
>>> media stream to deal with. If there are multiple media streams, then 
>>> it gets tricky to match them all up. The grouping framework is a 
>>> better solution. It would be helpful to see an example where there 
>>> there are two media streams that each need to be bicast.
>>>
>>> traffic matches up the two streams and decides what media to render. 
>>> Is there enough information in RTP, even when transcoding has been 
>>> performed on one or both of the streams, to allow this to work 
>>> reliably? (Disclaimer - I know little about RTP.)
>>>
>>> applicable to less conventional media, such as IM. While technically 
>>> it is possible to follow the pattern you have outlined to establish 
>>> bicast MSRP, the identification of duplicate messages will require a 
>>> different solution.
>>>
>>> that there is some overlap in coverage of the two access networks. 
>>> And without that things get very difficult. But the overlap may not 
>>> be very extensive, so it may be wise to quickly get from one to the 
>>> other entirely - for signaling as well as media. So for instance it 
>>> might be desirable to switch the signaling path to AN2 ASAP, before 
>>> bicasting ceases. Or, it may be prudent to find a way to maintain 
>>> "bicast" signaling paths as well for the time when it is uncertain 
>>> which AN might remain available.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>
>>>
>>> Haruki Izumikawa wrote:
>>>> Hello folks,
>>>>

---

From: Haruki Izumikawa <[email-masked]>
Date: Thu, 08 May 2008 22:47:20 +0900

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?

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,
>>

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Stefano Salsano <[email-masked]>
Date: Thu, 08 May 2008 11:52:41 +0200

Dear Haruki,

Best regards,
Stefano

-- 
*******************************************************************
Stefano Salsano
Dipartimento Ingegneria Elettronica
Universita' di Roma "Tor Vergata"
Via del Politecnico, 1 - 00133 Roma - ITALY

http://netgroup.uniroma2.it/Stefano_Salsano/

E-mail  : [email-masked]
Cell.   : +39 320 4307310
Office  : (Tel.) +39 06 72597770  (Fax.) +39 06 72597435
*******************************************************************

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 May 2008 11:31:59 -0400

> 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

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 8 May 2008 20:32:43 +0200

Then my question is:
is SIP mobility something interesting to be investigated for the group?

I would like to stimulate discussion around this set of drafts:
http://www.ietf.org/internet-drafts/draft-izumikawa-sipping-sipbicast-01.txt
http://tools.ietf.org/html/draft-niccolini-sipping-siphandover-03
http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution

It seems to me that they both address the same issue with similar
scenarios in mind and similar requirements, in the end they differ for the
technical solution proposed (as for the standardization requirements
if it is an additional header we may need ot go to SIP, but if it is up
to changing lines in SDP then it is MMUSIC)

--> if we can get an agreement that the issues/scenario and common
set of requirements then this would be a good basis for discussion
and we can rpoceed from there

Anyone having an opinion on this?

Cheers,
Saverio

============================================================
Dr. Saverio Niccolini
NEC Laboratories Europe, Network Research Division	
Kurfuerstenanlage 36, D-69115 Heidelberg
Tel.     +49 (0)6221 4342-118
Fax:     +49 (0)6221 4342-155
e-mail:  [email-masked] <-- !!! NEW ADDRESS !!!
============================================================
NEC Europe Limited Registered Office: NEC House, 1 Victoria
Road, London W3 6BL Registered in England 2832014

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, May 08, 2008 5:32 PM
> To: Haruki Izumikawa
> Cc: SIPPING LIST
> Subject: Re: [Sipping] Request for Open discussion about SIP mobility
> 
> 
> 
> Haruki Izumikawa wrote:
> > Dear Stefano,
> > 
> 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,
> >>
> >> 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
> >> 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.
> >>
> >> 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.
> >>
> >>> 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.
> >>> large-scale commercial yet. In addition, the discussion about 
> >>> SIP-based mobility in IETF seems to be undynamic.
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 08 May 2008 15:04:50 -0400

Don't forget draft-shacham-sipping-session-mobility
which I believe predates ther rest of your work.

	Paul

Saverio Niccolini wrote:
>>>> -02

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 8 May 2008 14:21:51 -0500

And that document is sitting in the RFC editor's queue, so it is
important to consider what additional requirements these other documents
address beyond the ones in that document and the value of additional
solutions beyond those already documented. 

Mary. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Thursday, May 08, 2008 2:05 PM
To: Saverio Niccolini
Cc: SIPPING LIST
Subject: Re: [Sipping] Request for Open discussion about SIP mobility

	Paul

Saverio Niccolini wrote:
> scenarios in mind and similar requirements, in the end they differ for

> the technical solution proposed (as for the standardization 
> requirements if it is an additional header we may need ot go to SIP, 
> but if it is up to changing lines in SDP then it is MMUSIC)
> 
> set of requirements then this would be a good basis for discussion and

> we can rpoceed from there
> 
> NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, 
> London W3 6BL Registered in England 2832014
>  
>   
> 
>> 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,
>>>>
>> This list is for NEW development of the application of SIP Use 
>> [email-masked] for questions on current sip Use 
>> [email-masked] for new developments of core SIP
>>
> 
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP Use
[email-masked] for questions on current sip Use
[email-masked] for new developments of core SIP
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 09 May 2008 12:16:55 +0300

> such as MSRP are worthy of some consideration.
I completely agree with Paul, a SIP mobility solution should consider 
also the MSRP and
in general TCP scenario.
In the voice or video scenario (using rtp) a few dropped packets could 
be acceptable even
not noticed at all.
However using MSRP or in general TCP the scenario several issue should 
be considered,
for example:
- the time to setup a new TCP connection (this especially in the 
cellular world takes time several seconds)
- which messages or packets retransmit
- how avoid duplications or even retransmission of the same data

regards
Sal

---

From: "DRAGE, Keith \(Keith\)" <[email-masked]>
Date: Fri, 9 May 2008 16:57:24 +0200

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 

> Sent: Thursday, May 08, 2008 4:32 PM
> To: Haruki Izumikawa
> Cc: SIPPING LIST

---

From: Ashutosh Dutta <[email-masked]>
Date: Fri, 09 May 2008 11:56:35 -0400

Dear Haruki,
             If I remember correctly, the conclusion of the BAR BOF was 
to discuss some of these issues in the SIPPING working group that got 
formed around the same time.

	Thereafter, during 51st IETF in July 2001, we had submitted few drafts 
with respect to SIP-based terminal mobility (requirement document, 
terminal-mobility solution documents). During the discussion in SIPPING 
WG, folks within WG thought it was to early to discuss the SIP-based 
mobility stuff at that time. These old drafts can still be found at the 
same archive along with other reference materials 
(http://www.argreenhouse.com/SIP-mobile/Reference.html). However, some 
of these documents are little outdated now. Subsequently, over the years 
there have been a lot of useful work with respect to SIP-based mobility 
(e.g., session mobility, terminal mobility) that are published in many 
conferences/magazines/journals.

While there is already a draft under RFC queue to support  SIP-based 
session mobility, it would be good to see some discussion to support 
SIP-based terminal mobility in the SIPPING WG.

Regards
Ashutosh

Haruki Izumikawa wrote:
> Hi all,
> 
> Will someone tell me the conclusion of the past discussion concerning 
> SIP mobility. I have read the "SIP-Mobile Minutes" in 50th IETF and 
> understood the outline of the discussion. But, I cannot find the 
> conclusion of the meeting. So, I would be happy especially to hear the 
> conclusion.
> 
> Regards,
> 
> Haruki
> 
> 
> 
> Ashutosh Dutta wrote:
>> Haruki,
>> up-to-date by any means and needs to be updated as people have done 
>> more work on this recently.
>>

---

From: Haruki Izumikawa <[email-masked]>
Date: Sat, 10 May 2008 04:42:55 +0900

Thanks, Ashutosh.
I understood what's been going on with the discussion of SIP mobility. 
It seems that SIP mobility was not needed so much at that time. But now, 
SIP mobility have been actively studied and developed recently as you 
commented. In addition, all-IP NW environments would be just around the 
corner and SIP mobility will become more important technology to support 
flexibly mobile users. So, I also think that it's time to restart some 
discussion regarding SIP-based terminal mobility here.

Best wishes,

Haruki

Ashutosh Dutta wrote:
>     Thereafter, during 51st IETF in July 2001, we had submitted few 
> drafts with respect to SIP-based terminal mobility (requirement 
> document, terminal-mobility solution documents). During the discussion 
> in SIPPING WG, folks within WG thought it was to early to discuss the 
> SIP-based mobility stuff at that time. These old drafts can still be 
> found at the same archive along with other reference materials 
>>>        Thanks for bringing this discussion up again. Few years back 
>>> we did create a mailing list and web page to add some of the 
>>> references with respect to SIP-based mobility work. This reference 
>>> list is not up-to-date by any means and needs to be updated as people 
>>> have done more work on this recently.
>>>
>>> Here is the pointer to the archive that has some relevant materials. 
>>> I can update this list with more recent papers in this area.
>>>

---

From: Haruki Izumikawa <[email-masked]>
Date: Fri, 09 May 2008 19:31:03 +0900

Dear Paul,

Thank you for your comment. I cleary understand the process of this topic.

Regards,

Haruki

Paul Kyzivat wrote:
>> 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?
> 
>>> [1] Requirements for vertical handover of multimedia sessions using 
>>> SIP http://tools.ietf.org/html/draft-niccolini-sipping-siphandover-03
>>>

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Haruki Izumikawa <[email-masked]>
Date: Fri, 09 May 2008 19:33:33 +0900

Hi all,

Regards,

Haruki

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Haruki Izumikawa <[email-masked]>
Date: Fri, 09 May 2008 19:28:14 +0900

I agree with the Mary's comment. It should be important to clarify 
differences between Shacham's I-D and other I-Ds related to SIP mobility.
I understand that main difference between them is their focus. While 
Shacham's I-D is regarding "service mobility", Niccolini's or my I-D are 
regarding "terminal mobility". According to the Dutta's previous paper 
[1] regarding a terminal mobility using SIP, a handoff delay of media 
packet could be at least around several hundred msec even if the handoff 
is executed between homogeneous networks. Such service disruption cannot 
be acceptable for real-time multimedia communications. Indeed, the 
minimization of the service disruption during the session transfer 
appears on the Shacham's I-D as one of the requirement. Yet, its 
solution seems not to be found in the I-D. This could be because the 
service disruption is not so critical in the service mobility since the 
device itself is changed in the service mobility and a user does not 
take it so seriously. However, to minimize the service disruption should 
be high-priority for the terminal mobility.
Therefore, I think it is necessary to consider the solution to minimize 
the service disruption during handoff. So what do you think?

[1] Nakajima N., Dutta A., Das S., Schulzrinne H., "Handoff delay 
analysis and measurement for SIP based mobility in IPv6," ICC'03, 2003.

Best wishes,

Haruki

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Ashutosh Dutta <[email-masked]>
Date: Sat, 10 May 2008 16:25:13 -0400

Haruki,
        I would actually put Shacham et al.'s draft into session 
mobility category rather than service mobility since it involves 
transferring an existing session from one device to another device. 
While there is a need for fast session transfer between devices, 
fast-handoff for SIP-based terminal mobility needs to be looked into as 
well, where the existing session continues on the same device after the 
handoff (the device could be single homed or multi-homed).

Realizing the need for fast-handoff for SIP-based terminal mobility, 
subsequent to the paper that you had cited below, we did publish few 
other papers later on that looked into some possibilities of supporting 
fast-handoff for SIP-based terminal mobility. Let me cite those below. I 
am also aware of few other papers supporting SIP-based terminal mobility 
and fast-handoff as well.

1) A. Dutta, S.Madhani, H. Schulzrinne, O. Altintas, W. Chen, 
"Optimized Fast-handoff Schemes for Application Layer Mobility 
Management,"  ACM MC2R November 2002

2) P-Y Hsieh, A. Dutta, H. Schulzrinne,  "Application Layer Mobility 
Proxy for Real-time communication," 3G Wireless 2003, San Francisco, CA

3) A. Dutta, S. Madhani, W. Chen, O. Altintas, H. Schulzrinne, 
"Fast-handoff Schemes for Application Layer Mobility Management," PIMRC 
2004, Barcelona, Spain

While there are variations of fast-handoff techniques for network layer 
mobility (e.g., FMIPV6, HMIPv6, FPMIPv6), I think it is probably a good 
idea to investigate if existing techniques can support fast-handoff for 
SIP-based terminal mobility. This need becomes more apparent if a 
carrier or any application service provider does not want to deploy any 
MIP variants to support purely SIP-based applications.

Regards
Ashutosh

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 11 May 2008 00:47:51 -0400

I'll try to channel Henry for a moment, and ask why we need to do 
*anything* at the sip level to handle a device moving from one IP access 
network to another.

	Paul

Ashutosh Dutta wrote:
> Haruki,
>        I would actually put Shacham et al.'s draft into session mobility 
> category rather than service mobility since it involves transferring an 
> existing session from one device to another device. While there is a 
> need for fast session transfer between devices, fast-handoff for 
> SIP-based terminal mobility needs to be looked into as well, where the 
> existing session continues on the same device after the handoff (the 
> device could be single homed or multi-homed).
> 
> 1) A. Dutta, S.Madhani, H. Schulzrinne, O. Altintas, W. Chen, "Optimized 
> Fast-handoff Schemes for Application Layer Mobility Management,"  ACM 
> MC2R November 2002
> 
>> Shacham's I-D is regarding "service mobility", Niccolini's or my I-D 
>> are regarding "terminal mobility". According to the Dutta's previous 
>> paper [1] regarding a terminal mobility using SIP, a handoff delay of 
>> media packet could be at least around several hundred msec even if the 
>> handoff is executed between homogeneous networks. Such service 
>> disruption cannot be acceptable for real-time multimedia 
>> communications. Indeed, the minimization of the service disruption 
>> during the session transfer appears on the Shacham's I-D as one of the 
>> requirement. Yet, its solution seems not to be found in the I-D. This 
>> could be because the service disruption is not so critical in the 
>> service mobility since the device itself is changed in the service 
>> mobility and a user does not take it so seriously. However, to 
>> minimize the service disruption should be high-priority for the 
>> terminal mobility.
>> Therefore, I think it is necessary to consider the solution to 
>> minimize the service disruption during handoff. So what do you think?
>>
>>>>> 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,
>>>>>>>
>>>>>>> internet drafts that we submitted some time ago and that we've 
>>>>>>> now updated
>>>>>>>
>>>>>>> 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,
>>>>>>>>

---

From: Haruki Izumikawa <[email-masked]>
Date: Mon, 12 May 2008 14:32:41 +0900

Dear Salvatore,

 > - how avoid duplications or even retransmission of the same data

Thank you for pointing out the controversial issues. I have recognized 
the necessity and the importance of the support for the general TCP 
scenario (incl. the MSRP). I just think that make-before-break switching 
(handoff) can be one of the solutions to deal with duration taken to 
setup a new TCP connection...  The other two should be also solved in 
some way.

Rgds,

Haruki

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Haruki Izumikawa <[email-masked]>
Date: Mon, 12 May 2008 17:15:36 +0900

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

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Stefano Salsano <[email-masked]>
Date: Mon, 12 May 2008 17:10:06 +0200

Dear Paul,

I think that SIP is already concerned with "devices moving from one IP 
access network to another".
The re-INVITE mechanisms already described in current SIP RFCs allows to 
support terminal mobility, taking care of "devices moving from one IP 
access network to another".

The point is: do we think that this already defined re-INVITE mechanism 
suits all the requirements for having a SIP based terminal mobility ?

In my opinion there at least two big issues with the current mechanism, 
that could deserve the investigation of additional requirements and 
solutions:

1) The responsibility for supporting the mobility of a Mobile Node (MN) 
is assigned to the Corresponding Node (CN). If the CN does not support 
(or does not support well) the re-INVITES you cannot offer a reliable 
mobility service using SIP. If you are an enterprise and you want to 
offer to your employees a SIP based mobility service supporting 
handovers you have to be sure that the procedure works well 
independently from the remote CN you are talking (not to talk if you are 
a service provider and you are selling a SIP based mobility services...)

2) Performance issues: the current solution is not very well suited for 
a seamless handover, comparable in performance with cellular networks. 
Mechanisms like bi-casting could improve the performance.

Comments are welcome!

Best regards,
Stefano

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 12 May 2008 16:29:04 +0100

> [mailto:[email-masked]] On Behalf Of Stefano Salsano
> Sent: 12 May 2008 16:10
> To: Paul Kyzivat
> Cc: Ashutosh Dutta; SIPPING LIST; Mary Barnes; Saverio Niccolini
[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?

John

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 May 2008 16:13:49 -0400

> access network to another".

Sip can do lots of things, many of which are probably a bad idea.

I said I was channeling Henry here, and I will continue for a bit, 
playing the devil's advocate.

Why would you want to establish a new sip signaling path just because 
you have chosen to use a new access network? *Why* won't the IP address 
you were using with the first access network continue to work with the 
new access network?

(I'm sure there are answers to this, but perhaps they need to be flushed 
out.)

In the case of IPv6 I know there are limits to where IP addresses can be 
connected. And there is mobile IPv6. So there the question may be "why 
won't IPv6 mobility be enough to preserve you sip and media sessions as 
you move from one access network to another?"

It would seem that often the answer is that the operators of the access 
networks insist on participating at the application protocol level so 
that they can charge more and avoid being commoditized, even if what we 
really need are some good commodity IP access networks. Having been 
locked out of participating in HTTP they want to avoid repeating that 
situation with SIP.

	Paul

---

From: Stefano Salsano <[email-masked]>
Date: Tue, 13 May 2008 02:13:38 +0200

Paul Kyzivat wrote:
>>> *anything* at the sip level to handle a device moving from one IP 
>>> access network to another.
>>
>> Dear Paul,
>>
>> The re-INVITE mechanisms already described in current SIP RFCs allows 
>> to support terminal mobility, taking care of "devices moving from one 
>> IP access network to another".
> 

Dear Paul,

I think that ability of performing terminal mobility or "application 
level mobility" is one of the major claims of the SIP protocol and one 
thing that the "inventors" of SIP had in mind from the beginning...

> (I'm sure there are answers to this, but perhaps they need to be flushed 

Thank you for these provocative questions... Handling mobility at the 
network layer is for sure an interesting option. I guess we could spend 
days discussing the merits of application layer mobility vs network 
layer mobility...

You definitly need to have an ubiquitous deployment of mobile IPv6 if 
you want to start using network level mobility keeping your IP address 
when you roam across networks... I think this is a very long term 
solution. Or you can choose to use this mobility only on the subset of 
mobile IPv6 enabled networks.

On the other hand, tomorrow morning I can set up for you a demo of a SIP 
based application layer mobility. You will be connected to an SBC that I 
run on my desktop PC (I am not an operator!), you can roam on whatever 
IPv4 network you want with public or private addresses (as long as there 
are no firewalls, but only NATs) you can make and receive phone calls 
and perform seamless handovers (the quality is of course dependent on 
the internet connection between my SBC and the network you roam in, but 
the handover process virtually does not introduce any additional 
degradation)

Of course, I need to send you my VoIP client... because my solution is 
"proprietary" :-(

My point is that it is worth discussing requirements for this types of 
solutions and see if there is interest to go for a standard. This will 
avoid to have a set of non interoperable solutions offered as plugins of 
VoIP clients or as complement of proprietary SBCs...

Best regards,
Stefano

PS by the way the demo solution I mentioned is described in:
"SIP-based mobility management in next generation networks", IEEE 
wireless communications April 2008
http://dx.doi.org/10.1109/MWC.2008.4492982

and in

>> The point is: do we think that this already defined re-INVITE 
>> mechanism suits all the requirements for having a SIP based terminal 
>> mobility ?
>>
>> In my opinion there at least two big issues with the current 
>> mechanism, that could deserve the investigation of additional 
>> requirements and solutions:
>>
>> 1) The responsibility for supporting the mobility of a Mobile Node 
>> (MN) is assigned to the Corresponding Node (CN). If the CN does not 
>> support (or does not support well) the re-INVITES you cannot offer a 
>> reliable mobility service using SIP. If you are an enterprise and you 
>> want to offer to your employees a SIP based mobility service 
>> supporting handovers you have to be sure that the procedure works well 
>> independently from the remote CN you are talking (not to talk if you 
>> are a service provider and you are selling a SIP based mobility 
>> services...)
>>
>> 2) Performance issues: the current solution is not very well suited 
>> for a seamless handover, comparable in performance with cellular 
>> networks. Mechanisms like bi-casting could improve the performance.
>>
>> Comments are welcome!
>>
>> Best regards,
>> Stefano
>>
>>> Ashutosh Dutta wrote:
>>>> Haruki,
>>>> fast-handoff for SIP-based terminal mobility needs to be looked into 
>>>> as well, where the existing session continues on the same device 
>>>> after the handoff (the device could be single homed or multi-homed).
>>>>
>>>> other papers later on that looked into some possibilities of 
>>>> supporting fast-handoff for SIP-based terminal mobility. Let me cite 
>>>> those below. I am also aware of few other papers supporting 
>>>> SIP-based terminal mobility and fast-handoff as well.
>>>>
>>>> "Fast-handoff Schemes for Application Layer Mobility Management," 
>>>> PIMRC 2004, Barcelona, Spain
>>>>
>>>>
>>>> While there are variations of fast-handoff techniques for network 
>>>> layer mobility (e.g., FMIPV6, HMIPv6, FPMIPv6), I think it is 
>>>> probably a good idea to investigate if existing techniques can 
>>>> support fast-handoff for SIP-based terminal mobility. This need 
>>>> becomes more apparent if a carrier or any application service 
>>>> provider does not want to deploy any MIP variants to support purely 
>>>> SIP-based applications.
>>>>
>>>> Regards
>>>> Ashutosh
>>>>
>>>> Haruki Izumikawa wrote:
>>>>> I understand that main difference between them is their focus. 
>>>>> While Shacham's I-D is regarding "service mobility", Niccolini's or 
>>>>> my I-D are regarding "terminal mobility". According to the Dutta's 
>>>>> previous paper [1] regarding a terminal mobility using SIP, a 
>>>>> handoff delay of media packet could be at least around several 
>>>>> hundred msec even if the handoff is executed between homogeneous 
>>>>> networks. Such service disruption cannot be acceptable for 
>>>>> real-time multimedia communications. Indeed, the minimization of 
>>>>> the service disruption during the session transfer appears on the 
>>>>> Shacham's I-D as one of the requirement. Yet, its solution seems 
>>>>> not to be found in the I-D. This could be because the service 
>>>>> disruption is not so critical in the service mobility since the 
>>>>> device itself is changed in the service mobility and a user does 
>>>>> not take it so seriously. However, to minimize the service 
>>>>> disruption should be high-priority for the terminal mobility.

---

From: Stefano Salsano <[email-masked]>
Date: Tue, 13 May 2008 10:11:06 +0200

> 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.

Best regards,
Stefano

---

From: Haruki Izumikawa <[email-masked]>
Date: Tue, 13 May 2008 17:18:09 +0900

> In the case of IPv6 I know there are limits to where IP
 > addresses can be connected. And there is mobile IPv6.
 > So there the question may be "why won't IPv6 mobility
 > be enough to preserve you sip and media sessions as

[HI] I know the advantages of network-level mobility since I had studied 
MIP/MIPv6 for years. One of the merits of MIP should be making the 
mobility of a terminal transparent to an application by keeping the same 
IP address. This scheme is useful to run existing applications. I think 
MIP is enough technology to deal with the mobility only when a handoff 
occurs in homogeneous network and non-realtime application is used.

However, MIP has limitations in my view. For example, an available 
bandwidth and delay may well differ significantly among heterogeneous 
networks, such as wireless LAN and cellular. So, I think an application, 
especially a realtime application, needs to recognize, for example, an 
available bandwidth and delay before or during handoff to adjust a 
transmitting rate or buffer space to a target network. Since MIP makes 
the mobility transparent to the upper layer, it is difficult to do it. 
And, the realtime stream can be aborted or interrupted just after handoff.

On the other hand, SIP has an affinity for applications, which can make 
handoff more flexible. So I believe that SIP is worth discussing as a 
technique to support the terminal mobility for a terminal that runs a 
realtime application in heterogeneous networks.

In my view, both network and application layer mobility are necessary, 
and they have different roles.

I would be happy to hear views of many.

Regards,

Haruki

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Haruki Izumikawa <[email-masked]>
Date: Tue, 13 May 2008 17:49:55 +0900

Dear Stefano,

 > mobile IPv6 enabled networks.

[HI] I agree with you. Fast/Seamless handoff is needed if users enjoy 
multimedia services over an IP-based mobile network. This requirement is 
also stated in RFC 4068 (FMIPv6). And, FMIPv6 has been already 
standardized for suppoting fast handoff. But, I'm afraid when all of 
access routers worldwide would support FMIPv6, incl. buffering and 
forwarding functions. Application layer mobility enables the mobility 
service deployment to be more and more rapidly, which should be one of 
the merits of application layer mobility.

Best wishes,

Haruki

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 13 May 2008 05:29:52 -0400

Paul,
	While application layer mobility has its merits in terms of its ease of 
deployment, its usage is best suited to support SIP-based application. 
However, as Haruki and Stefano have pointed out, we still need to have 
fast-handoff support to make SIP-based mobility more useful to the end 
users.

	Thus, a discussion in this regard could be useful. I am not sure if 
recently formed MEXT WG would like to include SIP-based mobility in 
their charter. Otherwise, these issues can probably best be addressed in 
the SIPPING WG.

Since we are discussing SIP-based mobility vs. MIPv6, here is a pointer 
to a short paper that provides a comparative analysis between SIP-based 
mobility and MIPv6, titled, "Comparative Analysis of Network Layer and 
Application Layer IP Mobility Protocols for IPv6 Networks," that 
appeared in WPMC 2006.

http://www1.cs.columbia.edu/~dutta/research/WP061002.PDF

Regards
Ashutosh

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 13 May 2008 13:27:23 +0100

Stefano, 

> Sent: 13 May 2008 09:11
> To: Elwell, John
> Cc: Paul Kyzivat; Ashutosh Dutta; SIPPING LIST; Mary Barnes; 
> Saverio Niccolini
[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

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 14 May 2008 11:20:44 +0300

I agree with the fact that network and application layer mobility may 
have different roles and utilizations.
Of course MIP/MIPv6 make the terminal mobility transparent at the 
application level, however they introduce
a latency (a path not optimized) that could be avoided using the 
mobility at the application level

About the needs to recognize the available bandwidth and delay before or 
during the handoff,
I think it is not a big problem and it could be resolved even also right 
after the handoff with a re-invite.
Am I wrong in that?

Sal

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 14 May 2008 11:35:24 +0300

Hi Haruki,

of course make-before-break (setup a new a new TCP connection before 
tear down the  old one)  is  the right strategy,
I don't think will solve all the problems, you have to assure  not to  
loose any packets  and this is not so easy
just to mention a possible scenario some packets sent on the original 
TCP connection that need to be retransmit on the new one,
perhaps because during the handoff the quality channel was bed.

Some years ago during my PhD I have investigated a similar scenario in:
-G. De Marco, L. Barolli, S. Loreto "/Performance Analysis of IP 
Micro-mobility Protocols in Single and Simultaneous Movements Scenario/",
 The second International Symposium on Ubiquitous Intelligence and Smart 
Worlds (UISW2005)

regards
Sal

Haruki Izumikawa wrote:
> scenario (incl. the MSRP). I just think that make-before-break 
> switching (handoff) can be one of the solutions to deal with duration 
> taken to setup a new TCP connection...  The other two should be also 
> solved in some way.
>
> Rgds,
>
> Haruki
>
>
>
> Salvatore Loreto wrote:
>> Paul Kyzivat wrote:
>>> Haruki Izumikawa wrote:
>>>  
>>>> [HI] I think the bicasting solution is needed for realtime 
>>>> multimedia streams in which re-transmission cannot be acceptable. 
>>>> Therefore, I don't know some services such as IM or file transfer 
>>>> using MSRP need bicasting support. In fact, I haven't considered 
>>>> the concern you pointed out. I'm going to have to weigh this 
>>>> concern more carefully. Thank you for bringing this matter up.
>>>>     
>>>
>>> voice a few dropped packets may cause a "glitch" but probably will 
>>> not create a significant loss of information. But a single dropped 
>>> IM can be a large loss of information.
>>>
>> In the voice or video scenario (using rtp) a few dropped packets 
>> could be acceptable even
>> not noticed at all.
>> However using MSRP or in general TCP the scenario several issue 
>> should be considered,
>> for example:

---

From: Haruki Izumikawa <[email-masked]>
Date: Thu, 15 May 2008 15:23:55 +0900

> after the handoff with a re-invite.

[HI] Personally, I think it is important to recognize the available 
bandwidth and delay and make an accommodation with a target NW in 
advance for an enhancement of users' QoE. Realtime services, especially 
bi-directional realtime services that is much delay sensitive, could be 
interrupted right after handoff, e.g. from WLAN to cellular, because of 
such as a lack of bandwidth if a new media information is updated by a 
re-invite after the handoff.
Though I'm not sure I'm right or not, I believe that an affinity for 
applications is one of the merits of application layer mobility.

Rgds,

Haruki

-- 
Haruki Izumikawa
KDDI R&D Laboratories

---

From: Salvatore Loreto <[email-masked]>
Date: Thu, 15 May 2008 10:54:29 +0300

Haruki Izumikawa wrote:
>> About the needs to recognize the available bandwidth and delay before 
>> or during the handoff,
>> I think it is not a big problem and it could be resolved even also 
>> right after the handoff with a re-invite.
>> Am I wrong in that?
>
> advance for an enhancement of users' QoE. Realtime services, 
> especially bi-directional realtime services that is much delay 
> sensitive, could be interrupted right after handoff, e.g. from WLAN to 
> cellular, because of such as a lack of bandwidth if a new media 
> information is updated by a re-invite after the handoff.
the handoff WLAN to cellular is a particular scenario,
if the scenario you have in mind is where the WLAN belong in somehow to 
the same operator of the cellular network then the 3GPP mobility 
management is already almost able to perform the handoff and the IMS 
subsystem provide you the session continuity.

if you are thinking of a scenario where the WLAN and the cellular are 
two totally different networks and you want use the cellular network as 
a simple pipe, then the situation is different and more complicate. 
However from a bandwidth point of view the performance of cellular 
network nowadays with HSDPA and in future with LTE are more then enough 
to provide the realtime service.

Sal

>>> [HI] I know the advantages of network-level mobility since I had 
>>> studied MIP/MIPv6 for years. One of the merits of MIP should be 
>>> making the mobility of a terminal transparent to an application by 
>>> keeping the same IP address. This scheme is useful to run existing 
>>> applications. I think MIP is enough technology to deal with the 
>>> mobility only when a handoff occurs in homogeneous network and 
>>> non-realtime application is used.
>>>
>>> bandwidth and delay may well differ significantly among 
>>> heterogeneous networks, such as wireless LAN and cellular. So, I 
>>> think an application, especially a realtime application, needs to 
>>> recognize, for example, an available bandwidth and delay before or 
>>> during handoff to adjust a transmitting rate or buffer space to a 
>>> target network. Since MIP makes the mobility transparent to the 
>>> upper layer, it is difficult to do it. And, the realtime stream can 
>>> be aborted or interrupted just after handoff.
>>>
>>> On the other hand, SIP has an affinity for applications, which can 
>>> make handoff more flexible. So I believe that SIP is worth 
>>> discussing as a technique to support the terminal mobility for a 
>>> terminal that runs a realtime application in heterogeneous networks.
>>>
>>> In my view, both network and application layer mobility are 
>>> necessary, and they have different roles.
>>>
>>>>> I think that SIP is already concerned with "devices moving from 
>>>>> one IP access network to another".
>>>>> The re-INVITE mechanisms already described in current SIP RFCs 
>>>>> allows to support terminal mobility, taking care of "devices 
>>>>> moving from one IP access network to another".
>>>>>       
>>>> Why would you want to establish a new sip signaling path just 
>>>> because you have chosen to use a new access network? *Why* won't 
>>>> the IP address you were using with the first access network 
>>>> continue to work with the new access network?
>>>>
>>>> (I'm sure there are answers to this, but perhaps they need to be 
>>>> flushed out.)
>>>>
>>>> In the case of IPv6 I know there are limits to where IP addresses 
>>>> can be connected. And there is mobile IPv6. So there the question 
>>>> may be "why won't IPv6 mobility be enough to preserve you sip and 
>>>> media sessions as you move from one access network to another?"
>>>>
>>>> It would seem that often the answer is that the operators of the 
>>>> access networks insist on participating at the application protocol 
>>>> level so that they can charge more and avoid being commoditized, 
>>>> even if what we really need are some good commodity IP access 
>>>> networks. Having been locked out of participating in HTTP they want 
>>>> to avoid repeating that situation with SIP.
>>>>
>>>>     Paul
>>>>
>>>>    
>>>>> mechanism suits all the requirements for having a SIP based 
>>>>> terminal mobility ?
>>>>>
>>>>> (MN) is assigned to the Corresponding Node (CN). If the CN does 
>>>>> not support (or does not support well) the re-INVITES you cannot 
>>>>> offer a reliable mobility service using SIP. If you are an 
>>>>> enterprise and you want to offer to your employees a SIP based 
>>>>> mobility service supporting handovers you have to be sure that the 
>>>>> procedure works well independently from the remote CN you are 
>>>>> talking (not to talk if you are a service provider and you are 
>>>>> selling a SIP based mobility services...)
>>>>>
>>>>> 2) Performance issues: the current solution is not very well 
>>>>> suited for a seamless handover, comparable in performance with 
>>>>> cellular networks. Mechanisms like bi-casting could improve the 
>>>>> performance.
>>>>>
>>>>> Comments are welcome!
>>>>>
>>>>> Best regards,
>>>>> Stefano
>>>>>
>>>>>      
>>>>>> Ashutosh Dutta wrote:
>>>>>>        
>>>>>>> Haruki,
>>>>>>> transferring an existing session from one device to another 
>>>>>>> device. While there is a need for fast session transfer between 
>>>>>>> devices, fast-handoff for SIP-based terminal mobility needs to 
>>>>>>> be looked into as well, where the existing session continues on 
>>>>>>> the same device after the handoff (the device could be single 
>>>>>>> homed or multi-homed).
>>>>>>>
>>>>>>> Realizing the need for fast-handoff for SIP-based terminal 
>>>>>>> mobility, subsequent to the paper that you had cited below, we 
>>>>>>> did publish few other papers later on that looked into some 
>>>>>>> possibilities of supporting fast-handoff for SIP-based terminal 
>>>>>>> mobility. Let me cite those below. I am also aware of few other 
>>>>>>> papers supporting SIP-based terminal mobility and fast-handoff 
>>>>>>> as well.
>>>>>>>
>>>>>>> 2) P-Y Hsieh, A. Dutta, H. Schulzrinne,  "Application Layer 
>>>>>>> Mobility Proxy for Real-time communication," 3G Wireless 2003, 
>>>>>>> San Francisco, CA
>>>>>>>
>>>>>>> "Fast-handoff Schemes for Application Layer Mobility 
>>>>>>> Management," PIMRC 2004, Barcelona, Spain
>>>>>>>
>>>>>>>
>>>>>>> While there are variations of fast-handoff techniques for 
>>>>>>> network layer mobility (e.g., FMIPV6, HMIPv6, FPMIPv6), I think 
>>>>>>> it is probably a good idea to investigate if existing techniques 
>>>>>>> can support fast-handoff for SIP-based terminal mobility. This 
>>>>>>> need becomes more apparent if a carrier or any application 
>>>>>>> service provider does not want to deploy any MIP variants to 
>>>>>>> support purely SIP-based applications.
>>>>>>>
>>>>>>> Regards
>>>>>>> Ashutosh
>>>>>>>
>>>>>>> Haruki Izumikawa wrote:
>>>>>>>          
>>>>>>>> I agree with the Mary's comment. It should be important to 
>>>>>>>> clarify differences between Shacham's I-D and other I-Ds 
>>>>>>>> related to SIP mobility.
>>>>>>>> While Shacham's I-D is regarding "service mobility", 
>>>>>>>> Niccolini's or my I-D are regarding "terminal mobility". 
>>>>>>>> According to the Dutta's previous paper [1] regarding a 
>>>>>>>> terminal mobility using SIP, a handoff delay of media packet 
>>>>>>>> could be at least around several hundred msec even if the 
>>>>>>>> communications. Indeed, the minimization of the service 
>>>>>>>> disruption during the session transfer appears on the Shacham's 
>>>>>>>> I-D as one of the requirement. Yet, its solution seems not to 
>>>>>>>> be found in the I-D. This could be because the service 
>>>>>>>> device itself is changed in the service mobility and a user 
>>>>>>>> does not take it so seriously. However, to minimize the service

---

From: Haruki Izumikawa <[email-masked]>
Date: Thu, 15 May 2008 19:21:56 +0900

> to provide the realtime service.

[HI] In fact, I don't assume the IMS. I simply consider the Internet. 
Given the IMS, a session continuity can be indeed performed. But, TMK, 
the 3GPP mobility management does not provide a fast/seamless handoff. 
The mobility management only provides a hard handoff. Is that correct?

Regarding HSDPA/LTE, as you pointed out, they can be enough to provide 
the realtime service to users. However, I also think that the available 
bandwidth per user might not become so high because a number of users 
simultaneously connect the same BS and radio resource is shared among 
the users...

I'm afraid the focus would move over a little. But anyway, thank you for 
the discussion.:-)

Best regards,

Haruki

-- 
Haruki Izumikawa
KDDI R&D Laboratories