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

[Stefano Salsano <[e-mail]>]

Dear Paul,

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

Paul Kyzivat wrote:
> 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.)
> 

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)

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

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

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,
> 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".)
> 
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

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


-- 
*******************************************************************
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  : [e-mail]
Cell.   : [phone]
Office  : (Tel.) [phone]  (Fax.) [phone]
*******************************************************************


_______________________________________________
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