[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

-- 
Haruki Izumikawa
KDDI R&D Laboratories


_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP