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

["DRAGE, Keith \(Keith\)" <[e-mail]>]

In SIPPING concentrate on the use cases and developing a set of
requirements. 

SIPPING needs to endorse the requirements, not tell SIP that they need
to develop a particular header.

So identify what the protocol mechanism needs to do; what conditions it
needs to meet etc.

There are various requirements documents out there that SIPPING has
dealt with in the past - look in tools.ietf.org for sipping drafts with
requirements in the title. Try and follow what they do.

Regards

Keith 

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: Thursday, May 08, 2008 4:32 PM
> To: Haruki Izumikawa
> Cc: SIPPING LIST
> Subject: Re: [Sipping] Request for Open discussion about SIP mobility
> 
> 
> 
> Haruki Izumikawa wrote:
> > 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?
> 
> That is true. But the work could and should start in SIPPING. 
> If it eventually is decided that a new header is needed then 
> that work would be shifted to the SIP WG with blessings from 
> SIPPING. Since there is a huge overlap in participation that 
> should not cause any difficulty.
> 
> 	Thanks,
> 	Paul
> 
> > 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-sipbicas
> >>> t-01.txt
> >>>
> >>> I would be happy to hear frank opinions of SIP specialists.
> >>>
> >>> Best regards,
> >>>
> >>> Haruki
> >>>
> >>>
> >>
> > 
> _______________________________________________
> Sipping mailing list  https://www.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://www.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