Subject: [Sipping] New draft on session mobility

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 15 Feb 2005 15:48:39 -0500

We've written a new draft on options for providing mid-session mobility:

http://www.ietf.org/internet-drafts/draft-shacham-sipping-session-mobility-00.txt

 From the abstract:

  Session Mobility is the seamless transfer of media of an ongoing
    communication session from one device to another.  This document
    describes the general methods and specifies the flows for providing
    this service as part of the Session Initiation Protocol (SIP).  The
    basic steps involved in session mobility which are describe are
    service discovery to locate devices to use as transfer targets, for
    which the Service Location Protocol (SLP) is used, session transfer,
    and, sometimes, reconciliation of device capability differences.  The
    described session mobility methods include the possibility of
    transferring any subset of the active media to one or more devices.

This also supports the idea of splitting sessions, e.g., between a SIP 
phone and a PC-based video application. Suggestions and comments would 
be appreciated.

Henning

_______________________________________________
Sipping mailing list  https://www1.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: Paul Kyzivat <[email-masked]>
Date: Fri, 18 Feb 2005 15:31:35 -0500

Ron, Henning,

This is very interesting work! (I want this.)

I have some concern over Disruption of Media During Transfer. The 
analysis demonstrates that delays are very small, which is probably 
sufficient for voice, video, and maybe even real time text.

But what about IM? (I am thinking specifically of MSRP.) Unlike the 
other media above, loss of a single packet is a big deal. From the point 
of view of reception, the party that remains constant during a change 
needs to ensure that all the packets from the old stream are consumed 
before switching to the new one. And from the point of view of a sender 
that remains constant during a change, it must be clear when to stop 
sending to the old stream and start sending to the new one.

I think it will take for careful study of the scenarios to understand 
how this plays out, and perhaps some additional work on the MSRP spec to 
guarantee that things are always handled in a way that works for these 
scenarios. I've been trying to get MSRP nailed down in this regard, but 
it would be good to have another interested person study this.

	Thanks,
	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 18 Feb 2005 17:56:42 -0500

> This is very interesting work! (I want this.)

<ad>We plan to make a prototype available for research use.</ad>

> it would be good to have another interested person study this.

TCP sessions in general and MSRP in particular are indeed a somewhat 
open issue. We'll take a closer look at those.

These types of systems would be easier to build if we could describe 
multi-unicast systems, i.e., receiving two copies of the same logical 
stream.

Thanks for your comments.