Index
Jonathan Rosenberg noted that call part flows he has seen in practice are different from this. He asked for real experience with interop of park. Responses should be posted to the list.
A hum was taken on acceptingthe current document as WG draft: there was consensus.
Issue: can we agree on 480 for explicit rejection / local? No hum, but no negative comments from room.
Issue: do we need normative response code usage? (If so this would be a BCP, though 98% informational.) General sense of the room seemed to be that BCP was desired.
Issue: Do we need an event package for changes to ACH config? Conclusion this should be a separate document.
Jonathan Rosenberg presented a set of slides by JDR. This stimulated a lot of discussion. One question of interest was how to get notifications of changes. Jonathan proposed to postpone dealing with that. Francois Audet & Jason Fischl felt the need for notification could not be postponed. Both seemed to be agreeable to doing as two documents. Dan York thinks this general approach could be used elsewhere in SIP, but there was concern not to get bogged down - keep scope to BLISS for now. Somebody from chatroom asked why not use BOSH to transport the event. There didn't seem to be much understanding of BOSH to respond to this.
Room poll: is there a problem that needs to be solved. Hum indicated consensus.
Room poll: do we take restful approach, using data model of sort shown in JDR's slides? Keith Drage comments that 3gpp already has a data model so maybe we shouldn't be defining a different one. Eric Burger suggests having an apps area review before doing a lot in this direction, because there might be a lot of feedback. Hum on if REST is is proper way to address this issue. Lots of pro, no con.
Request for comments on what should be configurable.
Jonathan Rosenberg says less is more - the only thing that requires a standard protocol is when automaton is doing the configuration. So support the few things that will be done that way, plus arbitrary and unspecified web interface for everything else. The things he said needed to be supported are DND on/off, call forward on/off, call forward number.
John Elwell wanted to try to confirm that the need here is this minimal.
Transport protocol options shown and a discussion of RESTful ensued. No conclusion that I noticed.
Issue: Support for Reg event package: Alan Johnston stated that this is no longer needed since publish is being used rather than subscribe between UA and Agent. Jonathan commented that this should be moot anyway because this is about interaction between appearance agent and proxy, which isn't being standardized. General agreement.
Issue: Server mode of operation: Could simplify UA and reduce number of messages, but requires all messages to go thru the agent. Proposal is to define as a separate draft. An option tag is suggested about this. Jonathan Rosenberg questioned which should be the default, based on common implementation. Alan also stated that "the first implementation of this draft" will use this server mode. So there is question by the authors about whether to define a separate draft. Scott Laurence stated there should not be an option of two mechanisms because it will reduce chances of interop. Adam Roach said if there is choice then it should be the one that works for all. Andy Hutton preferred there to only be one mechanism, possibly some possible optimizations. Dale Worley identified aproduct with a non call-stateful proxy.
Issue: what URI to publish to: Discussion from floor was in favor of using AOR as the assumed publish target, wondered why other things being considered. Authors thought IESG had problems with this, but Cullen said that was special case that didn't apply here. Some audience concern with routing rules – to agent rather than UA.
Other issues were mentioned but no notable discussion from floor.
There was a request for people from companies that implement this to provide a detailed review.
There might have been some statement of what was agreed that I didn't catch.
There was a discussion of Suspend/Resume procecdures – debate between special mechanism vs unsubscribe/resubscribe. Someone from 3gpp said it has requirement for explicit sus/res. Adam Roach commented on possibility of sus/res procedures for arbitrary subscriptions.
Dale Worley, speaking for design team proposed a direction: two level: simple and more complex. Simple level uses "standard" mechanisms such a dialog event package. The complex mechanism uses the devised special event package.
Paul Kyzivat commented that need the UAC to try whatever works, without depending on the UAS to have special capabilities, but exploiting them if available. Francois Audet generally agreed. Adam Roach wanted to know if we should have one or two drafts. Dale proposed just one, with the new mechanism – that other mechanisms already exist. Francois wants one draft to have it all, so it will be clear how to specify what is supported – different modes, etc. Basic mode already defined in dialog event package and service-examples. Dan York thought better to have two different RFCs because compliance is easy to state.
THE END
Detail Notes by Christian Schmidt