SIPPING notes 1640 Tuesday November 7, 2006 Reported by Dean Willis Topic: Call Completion using BFCP led by Adam Roach Slides presented Proposed by author that BFCP's serialized access control model is similar to call-completion requirements. Issue: Option 1, using re-attempt URI in BFCP. Adam's slides suggest this is not a preferred alternative. JDR is not sure that this is inconsistent with BFCP model and thinks this might be reasonable. JDR thinks that the proposed REFER approach is a "refer with implicit semantics" making for a tricky correlation problem. JDR believes that this is "in the context of the CCBS service" and BFCP seems natural. Discussion continued, with JDR essentially suggesting that a new TLD be added to BFCP to convey the URI. Rohan believes this is a perfectly reasonable place to use a REFER, but quotes Reply-To text from RFC 3261. The suggestion is that the failed invite's response (a 183?) would contain a Reply-To: header field with the URI for the call completion service. Discussion extended for some time at the front of the room. Dale Worley suggested that the proposed usage of REFER raises questions similar to those discussed in his REFER-usage draft. Noted that REFER inside an existing dialog does not normally ring the user agent by which it is received. Dale Worley noted that the media-flow refer on the Issue 1 Proposal: Use REFER slide should be an out-of-dialog refer, not in-dialog, and this would clear up much of the REFER-semantic confusion. Jonathan raised the discussion of "feature creep" (issue 3 from slides) a this point, with the suggestion that the requirements be evaluated based on the amount of complexity they might introduce. Back to Issue 2: Endpoint Queues vs Server Queues Chair interrupts to raise discussion of the general approach. Noted that most arguments have been at detail level, not at general approach level. John Elwell noted that there are some issues about the semantics of subscribe/notify for PSTN interworking based on the earlier proposal, and that this might even be worse, especially in a decomposed gateway or where the call comes in on a different gateway. Brian Stucker also raises the question of why we need yet another protocol vs an event package. Adam responds that the requirement is for a controlled, not free-for-all service. This is complicated by the requirement from TISPAN of pausing one's place in the queue, then resuming it. Francois Audet proposes that BFCP is way overkill for this task, and that we should probably go back and look at the requirements and re-analyze them. In general, he feels that this approach is too complicated. Miguel Angel Garcia-Martin thinks the fundamental approach of using BFCP to control queueing is reasonable, and is likely to be a co-implemented protocol anyhow. Denis Alekseitev notes that the queue management is critical to the service as defined in ANSI and ITU specifications. Francois notes that there is more to life than the ITU feature specification, and that we should not be locked into doing a feature exactly like the ITU spec unless it really meets our needs. Cullen suggests poll "Do we accept these requirements now that we understand the level of complexity that results?" Keith Drage notes that it is not SIPPING's duty to define the service -- just extensions needed to define the service. Adam responds that the draft under discussion simply defines tools, and the "service examples" in the draft are just examples. Chair concluded that further analysis is required before choosing a direction. Topic: Offer-Answer Usage led by Paul Kyzivat Slides presented Noted that this work is essentially a collection of folklore accumulated using oral history recovery techniques as well as mailing lists, and its eventual path is unclear. Noted that problem of rejecting an offer in a PRACK was known as early as the writing of RFC 3261, and is a major problem. Rohan noted wrt 2nd bullet of "Planned Clarifications and Additions" slide that he had previously volunteered to write up a simplified PRACK but got no consensus on the work. JDR notes that the best response to the PRACK offer problem is "Just don't do that, use UPDATE instead". Question from Brian Stucker about inability to update early dialog being confusing. That conversation was directed off-line. Issue: Commit/Rollback of Offer/Answer: If an O/A negotiation completes during a reINVITE, but the re-INVITE fails, what happens? Chair notes that this draft will become a WG effort in its next rev, but the class of document remains to be reviewed with ADs. Christer suggests that some of these questions be asked at SIPIt. Robert reports that he will do that, but that similar questions are being answered with almost random responses. Race Condition Examples led by Jun Koshiko Slides presented Changes since last version reviewed. Author requests comments before end of month, and will request reviewers for next version (to be published next month). Chair notes that this next version will be a WG document, and requests volunteers for formal review. Robert notes that this work is very important and will have significant impact in many error conditions, and should be read by all WG participants. Noted that it is uncertain whether the draft would be PS or INFO or BCP. Robert pointed out that this draft is not written in a PS mode. Chair says "Read it". Meeting dismissed.