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

[Paul Kyzivat <[e-mail]>]

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

Saverio Niccolini wrote:
> 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.     [phone]
> Fax:     [phone]
> e-mail:  [e-mail] <-- !!! 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 [e-mail] for questions on current sip
> Use [e-mail] for new developments of core SIP
> 


_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP