Minutes of the SIPPING WG Session at IETF 72: Monday, July 28th, 9-11 am ========================================================================== Minutes edited by Mary Barnes Based on detailed notes by Brian Rosen and Spencer Dawkins Meeting chaired by Mary Barnes and Gonzalo Camarillo Slides presented included in the proceedings Summary of action items/way forward: ------------------------------------ - WG charter. Mary to post proposed charter updates to mailing list. Once agreed, forward to AD (Jon P) for approval. Mary to update WG s/s with new dates and post status to WG mailing list. - draft-ietf-sipping-profile-datasets-01.txt: Ready for "pre-WGLC" Review. Three week WG review targetted for mid-late August. - draft-ietf-sipping-service-identification-03.txt: Christer to review most recent document and discuss any remaining concerns with Jonathan offline. Jonathan to summarize way forward on mailing list and update document. Two week WG re-review prior to progression. - draft-hilt-sipping-overload-design-00.txt: Volker to submit document as a WG document. "Initial" WG review to start in Sept/Oct. timeframe, along with a cross area review (per RAI review guidelines) within Transport Area. - draft-shen-sipping-load-control-event-package-00.txt: Discussion on this topic to continue on the list. - draft-ietf-sipping-update-pai-04.txt: JOhn to update document. Two week (2nd) WGLC review prior to PROTO write-up/publication request. - draft-loreto-sipping-context-id-requirements-00.txt: Discussion on this topic to continue on the list. - 3GPP liaison on usage of offer/answer (related to draft-ietf-sipping-offer-answer-08): Mary to work with Paul Kyzivat (editor offer-answer document) to craft a response to the LS. WG to agree proposed way forward summarized in LS response. SIPPING chairs to work with ADs/relevant WG chairs on work plan to solve the problem. - draft-johnston-sipping-cc-uui-04.txt: Authors to further develop requirements based on WG feedback and submit updated version for WG consideration. - draft-schwartz-sipping-nsr-code-00.txt: Discussion on this topic to continue on the list. - draft-niccolini-sipping-siphandover-04.txt: Discussion on this topic to continue on the list. Individual topic summaries: --------------------------- Topic: Agenda Bash Discussions led by: Chairs The chairs presented the current status of the WG. Progress since IETF-71 has been somewhat sluggish due to authors not able to update documents in a timely manner due to day job commitments. There are lots of drafts in progress, with the usual charter updates, with dates slipping, etc. as usual. The 3GPP dependency documents were summarized. The draft-vanelburg-sipping-private- network-indication-02.txt is on track and the service identification document (draft-rosenberg-sipping-service-identification-03) has completed IETF LC (author revision due). However, some documents are not progressing including draft-jesske-sipping-etsi-ngn-reason, draft-vanelburg-sipping-private-network- indication-02.txt and draft-drage-sipping-rfc3455bis-01. Keith Drage mentioned that rfc3455bis is under discussion in 3GPP and once it is agreed there, the doc will be revised one more time before progression. The Real Time Text Taskforce (ISOC sponsored activity) was highlighted - this relates to the ToIP requirements doc that has recently been published as RFC 5194 (the only new RFC published since IETF-71). Topic: User Agent Profile Datasets Discussion led by: Martin Dolly Relevant documents: draft-ietf-sipping-profile-datasets-01.txt The primary changes were wrt the invisible attribute. Editor believes the doc is ready for WGLC, however, we first need to get some detailed reviews from the WG to allow the WG to determine the readiness for WGLC. Action: Chairs to get reviewers and start a "Pre-WGLC" review on this ("Initial" review not deemed applicable since this doc has previously received lots of WG review as an individual document). Conclusion: Document ready for WG "Pre-WGLC" review. Topic: Service Identification Discussion led by: Jonathan Rosenberg Relevant documents: draft-ietf-sipping-service-identification-03.txt Jonathan discussed changes as a result of WGLC comments: - separate concepts: Service Identifier, Declarative Service Identifer, Derived Service Identifer - a new Game use case was added - URIs as a service differentiator is still a key concept - Litmus test of DWIM vs DWIS Christer believes that there are still some 3GPP issues with the document, but he has not reviewed this version. As far as aggregrate tags, Jonathan is resisting the use thereof and suggests the use of RFC 3840/41. As far as delayed offer, Jonathan emphasized that it's not compatible with media based service ID. Action: Christer is to review the latest document and get with Jonathan ASAP wrt any remaining concerns. Conclusion: WG re-review pending resolution of Christer's (3GPP) concerns. Topic: Overload Design Team Discussion led by: Volker Hilt Relevant documents: draft-hilt-sipping-overload-design-00.txt Volker highlighted that this document describes design considerations and models for overload control and is not a proposal for a solution. The primary content from this document reflects input from the design team (who have regular bi-weekly conference calls). Implicit versus Explicit overload control was discussed. It was highlighted that explicit actually reduces the load. There was a question about Resource Priority header to which the response was that it is mentioned in the solution draft. A question was also raised as to whether the design will support the "Airline Algorithm" whereby the folks that are already disrupted are disrupted even more to minimize the impact on non-disrupted customers (i.e., proposing the model of not delaying more users by maximizing the delay of a subset of users). Conclusion: Document agreed as a WG document. A cross area review with TSV is necessary early on. Topic: Load Control Event Package Discussion led by: Henning Schulzrinne Relevant documents: draft-shen-sipping-load-control-event-package-00.txt Concerns were raised about the overlap with general congestion control and inter-domain problems. As well, concerns were raised about the cases whereby the next hop is unknown. The author's response was that this is intended to complement the general problem and work as close to generative user as possible. It was highlighted that this problem is what Resource Priority header is supposed to help with. Conclusion: Discussion on this topic to continue on the list. Topic: Updates to Asserted Identity Discussion led by: John Elwell Relevant documents: draft-ietf-sipping-update-pai-04.txt John discussed the outstanding issue from WGLC as to whether additional URI schemas should be supported. Concerns were raised about impact on existing implementations if additional URI schemas were supported. Additional points were raised in terms of concerns if none of the URI schemas were understood and it was suggested that forward compatibility should be added. John presented 3 options for the way forward: 1. Progress now (with present scope - i.e., not supporting new URI schemas) 2. Extend scope and immediately progress. 3. Put on hold pending conclusion of identity discussions. Both ADs have concerns about this document in particular with regards to including PAI in responses and relation to Identity problems that are currently undefined. However, it was felt that this document solves existing problems with PAI, which is far more widely deployed that anticipated. Conclusion: WG support for addressing the short-term holes and progressing the document. Another draft can address forward-compatibility issues and consideration of broader impact of SIP Identity crisis. Topic: SIP Context-ID requirements Discussion led by: Salvatore Loreto Relevant documents: draft-loreto-sipping-context-id-requirements-00.txt The problem was summarized as having to do with correlating multiple SIP dialogs when they form part of the same conversation (e.g., an isolated message with an MSRP session). A concern was raised that the document is still assuming a solution for problem areas that are quite different. It was suggested to consider splitting media streams when people have loosely coupled devices. Other concerns were that this appeared to be binding messages together and re-inventing MSRP and that the layering is within the body of the message rather than at the SIP layer. The author agreed with the concern on layering, but clarified that this is done before MSRP. There may also be multiple issues involved (i.e., multiple device issues and history). Conclusion: Discussion on this topic to continue on the list. Topic: 3GPP Usage of the Offer/Answer Model from 3GPP - Mailing list discussion Discussion led by: Christer Holmberg Relevant documents: draft-ietf-sipping-offer-answer-08.txt (Note: doc has been "Publication Requested") SIPPING WG owes 3GPP a response to the liaison wrt the proposed 3GPP usage of the offer/answer model, in particular with regards to the problem identified in section 6.2 of the offer-answer document. The alternatives as to how to handle the situation when a re-invite fails were put forth: 1. Full rollback 2. Continue with negotiated SDP During the discussion, concerns were raised over letting process get in the way, however, it was clarified that the existing document is only informational, thus any normative changes must be documented in a separate document (and likely done in a different WG). A hum vote was taken as to whether folks supported the idea of a rollback as a solution. The consensus of the discussion was that folks were not yet ready to agree the technical way forward. The WG was encouraged to provide feedback on the proposal on or before Friday. Conclusion: WG agreement that we need to work towards solving the problem. There are two items to resolve: 1.response to 3GPP, summarizing proposed way forward (agreed on WG mailing list). 2. Agreement on a proposed solution and target WG for solution (to be discussed with ADs). Action: Mary to work with Paul Kyzivat (editor offer-answer document) to craft a response to the LS. SIPPING chairs to work with ADs/relevant WG chairs on way forward for solution to resolve the problem. Topic: Transporting User to User Information for SIP Call Control Discussion led by: Alan Johnston Relevant Document: draft-johnston-sipping-cc-uui-04.txt Dean highlighted that for this header to work correctly, you need an option tag and "Require". There were questions as to whether this should be a p-header and whether this applied only in the case of ISDN to ISDN/SIP interworking. The author will update document to ensure that pure SIP is addressed as well. In general, folks want requirements more clearly spelled out (e.g., "REQ-1: blah blah blah, etc.). Conclusion: There was strong support from the WG for the authors to further develop the requirements for the solution. Topic: No Service To This Number Reject Code Discussion led by: David Schwartz Relevant Document: draft-schwartz-sipping-nsr-code-00.txt David highlighted that the fundamental problem is that it's not clear as to whether one should try elsewhere if a 404 is received, although there was disagreement on this interpretation of a 404. The point was also raised that 404 (and 604) may not be relevant for an E.164 number. Jon P mentioned that this is all about telephone numbers (E.164 and Tel-URIs) and relates to the "unused" ENUM Service. Although, David disagreed that the problem was about SIP URIs versus Tel-URIs. It was also suggested that the problem being discussed cannot be adequately resolved with just a SIP response code. The WG needs to continue to discuss whether there is really a problem to be solved. Conclusion: Discussion on this topic to continue on the list. Topic: Requirements for vertical handover of multimedia sessions using SIP Discussion led by: Jan Seedorf (for Saverio Niccolini) Relevant Document: draft-niccolini-sipping-siphandover-04.txt It was highlighted that there is lots of previous work on this topic (including the document draft-shacham-sipping-session-mobility-05.txt which is awaiting publication as AD sponsored/individual ID). One of the reasons suggested as to why the handover needs to occur at the SIP layer (versus using Mobile IP) was due to a need for the handover to be "faster". However, there wasn't a clear quantification of "faster". There was a medium amount of interest in this topic. Conclusion: Discussion on this topic to continue on the list.