Subject: [Sipping] SIP Handover and 3GPP Multimedia Session Continuity?

From: "Saverio Niccolini" <[email-masked]>
Date: Mon, 8 Oct 2007 11:32:57 +0200

Dear SIPPING group,

we recently submitted an update of the drafts:
-- "Requirements for vertical handover of multimedia sessions using SIP"
http://tools.ietf.org/html/draft-niccolini-sipping-siphandover
-- "A solution for vertical handover of multimedia sessions using SIP"
http://tools.ietf.org/html/draft-salsano-sipping-siphandover-solution

We received some comments after submitting the last version but discussion 
on the mailing list was not enough to justify asking for a slot at the
meeting.

Why we would really like to discuss this in SIPPING?
-1- we believe this solution to be ready and performing better than available
ones in addressing the requirements listed
-2- 3GPP started looking into the issue (refer to Multimedia Session Continuity)
and if they require protocol work then IETF should have a look into that 

Our draft present a solution we already implemented and tested solving a real
problem of a roaming mobile host equipped with multiple interfaces (what is
referred to as Multimedia Session Continuity, MMSC, in 3GPP).

We propose to extend the mobility support in SIP using an intermediate anchoring
element (the same solution envisioned by 3GPP).

For doing this we have identified extension required to the SIP signaling consisting in:
-- an additional header to carry handover related information
-- an additional tag to help in the identification of users at intermediate elements

I would like to comment together with you on this draft, if the look is looking for 
intersting new WG item we really think this is something to have a look at.

Thanks in advance for your comments,
Saverio

============================================================
Dr. Saverio Niccolini
Senior Research Staff Member
NEC Europe Ltd., NEC Laboratories Europe, Network 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

_______________________________________________
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: Tue, 09 Oct 2007 16:54:08 -0400

Saverio,

The solution draft is interesting. I for one am interested in discussing 
it here.

I would like to suggest a different characterization of your proposal:

Your MMS is in reality a B2BUA. As far as the MH proxy, CH proxy, and CH 
are concerned it *is* the UA the CH is talking to. You don't show the 
real registrar for the MH (it may be the same as the MH proxy), but it 
too thinks of the the MMS as the UA which has registered.

Then there is a relationship between the MH and the MMS. This 
relationship is used to cause the MMS to make calls and relay the 
results to the MH, or to relay calls it receives to the MH.

I think you have muddied the role of the MMS, whether it is a B2BUA or a 
proxy. This shows up in the use of the Via headers. There really isn't 
any need for extra via header parameters, which are only needed because 
the vias are propagated through the MMS rather than terminated there. 
Then you are free to encode info in your own via header that will allow 
you to associate requests with corresponding ones on the other side. 
(However there is something dubious about starting a transaction on one 
IP address and network, and finishing it on another. I think that at 
least needs to be explored further.)

The user of REGISTER to control this relationship is interesting. I 
think it is probably ok. However I question the combination of 
terminating some REGISTER requests and B2BUA'ing some others. I don't 
see why that is necessary. IMO it makes more sense to configure the MMS 
regarding the registrations it should make. These can persist whether 
there is an MH registered or not. Since you have this stateful device in 
the network anyway, it is a natural place to put lots of long term 
stateful behavior. For instance it can provide forwarding and answering 
behavior. However, if you really want to make this a more dynamic 
relationship then I guess terminating some REGISTERs and relaying some 
others isn't so bad.

I don't understand the details of the HO registration. Are you saying 
that it carries an SDP body? (And hence is effectively a reinvite?) If 
so, that seems pretty weird. If we acknowledge that the MMS is a B2BUA, 
then it seems quite straightforward for the MH to send an 
INVITE/Replaces to pick up the call on the new access network. That is 
much more standard SIP. (Though I suppose it makes it harder to hide 
this from the "UA".)

That is about as much as I have to say to kick off discussion.

	Thanks,
	Paul

---

From: Stefano Salsano <[email-masked]>
Date: Thu, 11 Oct 2007 01:34:14 +0200

Dear Paul,

thank you for your interest and your comments, see below !

> least needs to be explored further.)

May be you are right that the MMS is more a B2BUA than a proxy... and 
that there are details in our approach that deserve further exploration 
and discussion.

The interesting thing (in our opinion) is that with our proposed use of 
Via headers and Contact headers we are able to provide an element (the 
MMS) that is fully stateless from the point of view of SIP signalling. 
Of course the MMS has to keep some state, in particular the association 
between the MH SIP address and the MH current IP address, but it does 
not need to keep a "session" state at SIP level for each session it 
handles on behalf of the MH. This is different from the traditional 
behavior of a B2BUA that keeps the session state as it breaks a session 
into two different sessions. (Of course our MMS will also keep some 
state at the "media proxy" level for each active media that it has to 
forward toward the MH)

> relationship then I guess terminating some REGISTERs and relaying some 
These are interesting comments that are worth discussing. We made some 
choices based on some requirements that we identified... but if we can 
collect more comments and requirements we can improve the proposed solution!
In particular our requirement was to have an "as simple as possible" 
MMS. We immagine (but this is not reported in our current draft!) that 
you can have multiple "local" MMSs that can handle your mobility in the 
network so that you can be registered to the "nearest" available MMS. In 
this "multiple MMS" scenario of course it is not good to have persistent 
registration in an MMS.
On the other hand if you consider our solution as it is presented in the 
draft, it appears that there is a single MMS and it fully makes sense to 
add forwarding and answering behavior as you propose.

> so, that seems pretty weird.

I think you spotted a mistake in the solution draft! If you refer to the 
sentence "the HandOver (HO) REGISTER request contains in the
message body the reference to the active session(s) to which the
handover is referred", this is related to a previous version of our 
solution. We have now changed it with the more correct approach to 
define a specific header, called "Handover" to carry this information, 
without carrying information in the SDP. The new header is described in 
section 5 of the solution draft, but we forgot to update the sentence at 
page 11. Thank you for noticing it.

If we acknowledge that the MMS is a B2BUA,
> much more standard SIP. (Though I suppose it makes it harder to hide 
You got the point... we prefer not to use INVITE/replaces, as these 
should be originated by the UA. In our solution the UAs (both in MH and 
in CH) are completely unaware of the mobility management aspects.

> That is about as much as I have to say to kick off discussion.

It was a good kick off of discussion... we think that these comments 
(and more comments that can come out from the discussion) can lead to a 
revision of the drafts (the requirement draft and/or the solution draft) 
and we welcome cooperation from interested people.

Best regards,
Stefano

>> We received some comments after submitting the last version but 
>> discussion on the mailing list was not enough to justify asking for a 
>> slot at the
>> meeting.
>>
>> I would like to comment together with you on this draft, if the look 
>> is looking for intersting new WG item we really think this is 
>> something to have a look at.
>>

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