Discussion Leader	Topic	Relevant Documents	Discussion
Chairs	Status and Agenda Bash		Supplementaty web page now has WGLC information listed... Lot of charter updates being requested (and not making it onto the charter page) - please look at the version at softarmor site for details. Five RFCs published since last IETF, three in editor's queue. Four drafts in post-publication request status (coordinating with SIP on transcoding framework). Requested publication of two drafts, WGLC completed on six drafts. Consent also being coordinated with SIP. Config framework has no agenda time, but some discussions are discussing on mailing list about complexity. Please meet with Dan and interested parties this week. Rohan - when is config ready to go? Gonzalo - get agreement on framework first. Seven drafts moved to SIP (because of normative SIP changes). Keith - please comment on these drafts to the SIP list. New charter proposal has five items (SBC requirements, race conditions, overload, offer-answer, and IPv6 torture test drafts). Agenda changes? Having some problems getting editors to revise drafts - may be assigning WG draft editors to overcome this problem. SIP IPv6 torture test messages - 03 is fairly complete. Some comments on use of brackets (implementations must parse both styles of addresses). Management Events - please notice use of SUBSCRIBE/NOTIFY for this function.
Volker Hilt	Session Policies	draft-ietf-sipping-policy-package-02.txt draft-ietf-sipping-media-policy-dataset-02.txt draft-ietf-sip-session-policy-framework-00.txt	Thanks for comments on previous versions. Have been adding examples and clarifications. Issue - correlate policy with INVITE? Using session identifier to PS, or passing token to UA? Proposing session identifier to PS, no strong feelings in the room. What stops the UA from lying? This is a hint. Don't like token because the assertion is too strong. There is no requirement to make sure the UA doesn't lie. Andrew - what's the use case? doesn't seem useful, especially if you can like about this. Rohan - prefer no correlation for privacy reasons. Gonzalo - policy enforcement is outside the scope of the document. Policy enforement will happen a different way if you lie. Bob - raised this issue, not so much about proxy knowing PS was contacted, but about routing about media for secondary invite. Token from PS would tell proxy this. Jonathan - is there a discovery aspect to this? If there's a farm of proxies and a farm of policy servers, with state involved, this is similar to media authentication token ("dreaded"). Volker - is the address of the policy server good? Jonathan - suggest IP address plus token - not SIP URL, PS URL. Shridar - Completely lost. Thought it was proxy who did the work? Does it matter if the proxy complies with the policy? Gonzalo - some people said they needed correlation, most people didn't have a strong opinion. Proxy can't ensure that policy was enforced, anyway. Decision is to use token in the document. TLS to protect policy - relies on transitive trust? Can take this discussion to the list. Event package... Issue - disclosure of session info? Proposal - UA populates all fields of a media policy document it has data for, media policy dataset format defines a basic set of elements needed to summarize a session. Will resolve issue and aim for WGLC in January. Moving to Relax NG for schema. Other drafts depend on this draft, need to advance soon. Issue - Example shown in session is slightly different from what's in the current draft, codec and media are encoded per-stream. Issue - are ipinip-intermediary and iplosose-intermediary used? Gonzalo - get rid of this, no one would use it, and add bandwidth-related elements. Rohan - don't see any way to implement intermediary elements in interoperable way. Brian - minimum bandwidth that you can count on? requested by other SDOs. Remove configured-intermediary? we used this heavily in examples, would allow parallel contact, not sequential. Need to make last changes, and switch to Relax NG for schema definitions.
Jonathan Rosenberg	Overload Requirements	draft-rosenberg-sipping-overload-reqs-02.txt	Not a lot of changes in the document. Major change is addition of simulation model. Want to help non-SIP experts understand the problem and help with solution (requested by TSVWG last two meetings). SIP can use to evaluate solutions, SIP/SIPPING can use to understand problem. Rohan - not comfortable with this model - how important is this specific model to the problem you're solving? Discomfort is that I see different separation of what goes in first pass analysis among implementations. Jonathan - just tune parameters - classification and overload rejection are the only things that have to be in the first pass. Next steps - tweaks on model if needed, WLGC and promotion to SIPPING work item. No comments, no open issues on requirements, we're well into solutions. Henning - somebody should look at consistent terminology. We have a multi-company group looking at this - some parameters are intuitive, some aren't - would be clearer if definition was part of the table. Gonzalo - WGLC scheduled for March, want to move up but we have so many documents in process, don't want people to diverge.
Volker Hilt	Overload Control	draft-hilt-sipping-overload-00.txt	Combined two overload drafts from previous meeting (hop-by-hop, congestion header). Overload only applies when a SIP server lacks capacity to process all incoming SIP messages. What about oscillation? Henning - fundamental problem is that it looks like a closed loop, but we're talking about dropping things. Probably unlikely to push all the way back to the end system. Large caliber weapon pointing at my foot - overloads tend to be bursty, schemes may penalize hosts that aren't contributing to overload any more. Defining right time constants isn't easy - there are no "right time constaints". Volker - Agree that algorithms need to be really well defined, don't say we understand this yet. Cullen - came around this problem in TRIP - can't choose between two downstreams without knowing about both downstreams. Jonathan - doesn't exclude that, but we have a lot more work to do. Don't know what the alternative is, for Henning's problem - call is not going to go through. Someone is going to lose. We'll drop calls, we have no choice. Need to consider load balancing as a system. Volker - agree. Tina - overload upstream and downstream in both directions? Volker - Only to the upstream (neighbors contributing to overload).  This applies only to SIP. Multiprotocol initiator shouldn't be a problem. Henning - problem is that one upstream with two downstreams understates the complexity of the problem. To drop requests at all may be doing more load balancing, or may assume we want to drop requests early as possible, if you can't push back all the way. Sometimes, you might be able to buffer instead of dropping messages. Volker - agree that there are cases where we want to drop messages in the upstream entity.  Simulation with large buffers gives you lots of buffered expired messages. Jonathan - our simulation shows our proxy that's busy just dropping messages. Daryl - keep in mind that PSTN drops calls when you run out of trunks today, even for emergency calls. Because there hasn't been a recommendation here, carriers are doing simple admission policy ("accept thirty calls, drop 31st call"). Rohan - let's look at the requirements more before we architect a lot more. Keith - assume we aren't going to specify algorithms at all? Volker - think we must do this. Jonathan - just pick one model and go with it. For algorithm - upstream entity or downstream entity? Stong believer that we specify behavior for upstream entity. This is why TCP works. James - have to define what the downstream is reporting, of course. Jonathan - yeah, but not in a lot of detail about what "I'm overloaded" really means - let downstream entity figure that out. Further discussion on mailing list, right? Vendors use very different definitions of overload in wireless, agree with Jonathan. Current feedback is mostly "throttle plus report load". Backwards compatibility issues...
Daryl Malas	SIP End-to-end Performance Metrics	draft-malas-performance-metrics-05.txt	Trying to move beyond PSTN metrics. Request at previous IETF was to narrow scope of document.  Focus is on end-to-end performance, not on hop-by-hop performance. Removed average hops per INVITE, added registration request delay, changed to Session Disconnect Delay, separated Session completion rate metric into secess/failed metrics. Added clarification about message retransmission mechanics. Uses first transmit (because that's what UAC sees). Defined "end to end", but there's still some confusion about this with B2BUAs, PSTN gateways, etc. Defined time-begin, time-stop. Have gotten good feedback from mailing list. Proposed changes since last draft - applicable UAS metrics, align TB/TS with E.721, clarify registration failures. Should I include failure conditions for SRD/PDD? Add timeouts for applicable metrics to draft. Rohan - you don't care as much about post-dial delay. Focus on what we know we need. Henning - registration failutes should not normally ocurr. "My server fails registration the fastest" - not terribly useful. Drop failure conditions that really aren't supposed to occur. 404 just confuses people. Is average the right thing to report, since it's usually not the right metric in operational networks? Daryl - don't specify interval for averages. Distinguish between slow 401/200 and 400 that never completes. Need a new parameter for this definition. Al Morton - please help with BMWG - we need your expertise for single-device performance work we are doing in  BMWG. Cullen - IPPM is also interested - discussing with Lars, Dan, etc. on who should be involved.  But don't stop working on this while we figure out where to do the work!
Mayumi Munakata	Clarification of Privacy Mechanism	draft-munakata-sipping-privacy-clarified-00.txt	Problem - semantics of priv-values aren't clear. Issue - SIP headers only, or SIP parameters as well? Recommend including parameters as well. Issue - clarify where privacy service should be executed? Recommend "no". Interest in this draft? (Please meta-discuss) Rohan - current specification is unclear, please continue as individual. Jonathan - think this is perfectly appropriate if we want to continue with this mechanism, but not getting deployment of this mechanism. Move to different model? Don't want to change specification every time we have a new header. Jon - agree with Jonathan, doing privacy at UA is best. Some UAs will be deployed without this new capability, we should continue this work as a story for what we do with UAs in this unfortunate situation. Rohan - should deprecate, but can't change deployed items just becase we deprecated. What we have seen is that out of 20 terminals,. vendors differ on how they handle privacy.; Must interop with ISDN/PSTN, that's where 90-something percent of SIP ends up. Jonathan - assume UA does most of the work, indicate to the network that you shouldn't ADD privacy-sensitive information. Are we deprecating this or trying to make this usable? Please discuss futher on the list. Two use cases - media gateway, plus additional privacy for remaining SIP-to-SIP traffic.
Jani Hautakorpi	Method for URI-List Servers to Refuse the Handling of a URI-List	draft-hautakorpi-sipping-uri-list-handling-refused-00.txt	Rohan - there's some interaction between this and session policy work. UAC is likely to have a relationship with its URI list server, know whether it supports recursion/how big a list it allows, etc. Is this a one-time thing? Jani - yes. Gonzalo - one discussion is whether this is OMA-specific or not. Andew - scenario is URI list server doesn't want to act as an exploder? Gonzalo - OMA is looking at two servers, one is controlling, need to say "please explode this URI yourself". Dale - useage seems hard to work out. UAC doesn't know the list contents, right? Doesn't tell UAC enough to explode itself? Gonzalo explained the use case in some detail. Dale - can't send INVITE to two URIs, so am confused. IPR issue - Ericsson has IPR on this solution, has been disclosed ("royalty-free"). Keith - what is the problem we're trying to solve? Need to be clearer about this. Is UAC entitled to see the members of this list? Didn't say you can't do a concatenation of lists. Jonathan - don't understand the problem. Usually you give a reason because there is some remedial action the requestor can take - what is action here? For OMA, we're trying to go back to a single point of explosion. Dale - not really any privacy issues for any list URI you can subscribe to. Keith - new headers go to SIP, new response codes go to SIP codes, we need the requirements draft before we go into the solution.
Brian Stucker	Early Media	draft-stucker-sipping-early-media-coping-03.txt draft-ejzak-sipping-p-em-auth-02.txt	Goal is to identify common problems and make recommendations that may include steps toward deprecation. Problems - signaling and media are disconnected, "SDP in a bottle", forking interactions. Lots of points about details on problem statement here, including references to RFC 3960, but Francois pointed out that we need to not shoot the messenger here. Rohan - Need to talk about what's new versus what we've already recommended. Robert - remember specs don't say the world must be a certain way. We can change that, but that's not what they say today. . Drafts also talks about coping mechanisms (which are not recommended, only cataloged). Rohan - Proxy stripping - this isn't legal, how can this work? Not a coping mechanism, it's broken and illegal. Brian - yes, but I've seen this used. Rohan - fine, call it something else. Francois - draft gives impression that coping mechanisms are recommended - they aren't, they are broken, but they are still there. Change the title and move on. Jonathan - lots of similar comments, there's a long list of things people do that cause problems. Is the real problem that people don't know how to select a media stream? Desired results of drafts - not advocating broken behavior, clearly stating what is still broken. Gonzalo - correlation between signaling and media isn't completely specified, and we want to find a simpler way of doing RFC 3969. Even if there are no changes to the protocol. it's useful to say what is broken and what problems are solved. Francois - to make progress, split open issues (what needs to be fixed, discouragement of bad ideas) into two drafts. People don't seem to agree that we should publish a list of bad ideas. Jonathan - some of this stuff feels like we're ignoring existing RFCs on early media and starting over. Don't think we need a one-stop shopping draft with early media. Robert - about halfway through the long SIPit report, asked what people really did when they received multiple media streams. Gonzalo - will continue discussions on the lists and make discussions there. Has anyone implemented 3969? No hands in the room...

TUESDAY, November 7, 2006, 1850-1950, Room Grande Ballroom B

Discussion Leader	Topic	Relevant Documents	Discussion
Chairs	Status and Agenda Bash		Config Framework - will be rewritten, picking up a couple of editors just for this work.
Adam Roach	Call Completion Service	draft-roach-sipping-callcomp-bfcp-00.txt	Uses SIP option tags for support and use, uses BFCP for callback requests, uses RFC 3087 to prioritize incoming call completion events over other calls. Why BFCP? SIP doesn't deal with queue management, granting exclusive access to a series of parties is like floor control. Issue - conveying URIs - Contact headers isn't a good match for this.  ACK and BYE go to wrong place. Using separate servers to provide this service, server provides URI used for call completion service. Could - convey re-attempt URI in BFCP. Adam doesn't think this is a good fit, but Jonathan doesn't know why. Could - new header field ("To-Recall") - we decided not to do this a long time ago (London?) after Dave Oran's "To-Explode-My-Phone:" rant. Could - put it in a REFER? Jonathan rants on REFER with implicit semantics (see previous rants on same subject). "Blind call transfer", but highly contextual. Jonathan prefers BFCP approach. Rohan - don't object to Jonathan's preference, but thinks REFER is fine. RFC 3261 seems to say this is OK. Dale - tried to enumerate all the REFER uses. In this context, REFER means backend dialog is going somewhere else, don't think this is the way CCBS works. (some confusion here) REFER inside dialog means dialog changes, right? REFER inside an existing dialog doesn't ring the phone where it is received. Back to Rohan and Jonathan - 183 needs to contain URI because 486 doesn't go to the right place. Dale - REFER in the middle is out of dialog REFER - that works, it's 3PCC. Jonathan - let's step back, we're in SIPPING level, but we're way down in the details. This service is interesting because feature/complexity tradeoff is very wide - queue management, forking ... Adam - yes, feature creep - how hard are we going to make this? Jonathan - this is the hardest problem we've tried to solve in SIP. Don't just look at requirements, look at complexity trade-off. This is not a trivial problem. TISPAN photocopied the existing PSTN definition - they don't do presence. You can do better without anchoring ourselves to existing PSTN definition. Adam - user agent could subscribe to own presence and say when others should call user. Gonzalo - want concensus on overarching plan. Most feedback to Adam has been positive (John Elwell aside). John - not sure this is headed in the right direction - making things work. Visualize the complexity of doing this in a gateway. Not most efficient way of meeting these requirements. What if final call comes in another gateway? (this is Adam's Issue 4b). Brian Stucker - didn't understand why we couldn't use dialog event package. Adam - if it's a free-for-all callback service, we have all the mechanisms we need now. One additional requirement (pause and resume queue) can't be done in current event package. Francois - jumping into something really complicated, took requirements for granted, using BFCP for this is insane, too complicated, if people who gave us the requirements saw this they wouldn't implement it. CCFB is different around the world - this isn't good. Figure out a different way to deal with queuing - don't match exactly, be similar or something. Miguel - think BFCP is correct, even if complicated - expect BFCP will be implemented, this isn't a problem - for PTT, etc. Complication in PSTN gateway is real but nothing else makes it better. Deutch Telecom - not about legacy protocols, it's about user experience for the service as defined in ETSI specifications and used today. Queue management is one flavor, also ITU. Francois - more to life than ITU specs, North America is not the same, this is a slippery slope, we're going to have lots of these variants. Sense of the room - using BFCP is the right choice? Cullen - no, ask if requirements are reasonable. Keith - be careful about what SIPPING does and what other people do - provide protocol mechanism, not define service. Adam - not defining the service, defining the protocol building blocks. Draft has several permutations of this. Sense of the room - using BFCP is the right choice?  Rohan - please ask who doesn't know enough to answer the question.
Paul Kyzivat	Offer/answer usage	draft-sawada-sipping-sip-offeranswer-01.txt	Have had folklore on the list forever, people are constantly confused. Not a normative document, no normative changes, just clarification. Not sure if this will end up as BCP or as Informational. Consolidates material from many sources, including folklore. Will be a need for normative clarifications, and this document may propose some. Has already been valuable as a resources. Not in final form yet. A few open issues still remain,. Some useful review, need more and more thorough review because of the kind of document this is intended to be. Need newcomer review as well. Some clarifications and additions will be added to the document in the next revision. "Unacceptable offer handling" needs to be clarified. Jonathan - we knew about this in 3261 - it just sucked. Also would like to reject an offer in a PRACK without rejecting a PRACK. Rohan - Have had lots of discussions about required offer in reliable provisional - why do you want to do this? Made suggestions about PRACK simplification - willing to do 3262bis if there was interest - is there interest? Jonathan - never liked offer in PRACK - why not send an UPDATE instead? Always thought this was a bad idea. Christer question (missed it) What do you call SDP in an unreliable provisional response? Not offer, not answer ... "preview" of the offer? Passing the buck on early media - nothing to add. Commit/rollback of offer/answer is the big remaining issue. What about a failed re-INVITE? What happens? Preconditions can have multiple offer/answers followed by a failure. Draft will become a WG item, very interesting please send comments to the list. Will talk to ADs about Informational, update 3264, etc. Christer - also take this draft to SIPits and see what people actually implemented. Robert - will put this in the next SIPit survey.
Jun Koshiko	Race Conditions	draft-hasebe-sipping-race-examples-02.txt	This draft is also working group item in new proposed charter. Previous discussion on mailing list - "Does UAC send ACK in terminated state?" Conclusion is UAC send ACK, UAS keeps retransmitting 200 OK for INVITE. Open issue - completion of INVITE dialog usage. Think draft is almost finished, plan to update within a month, seeking reviewers for SIPPING 00 version (next month) - please contact the chairs. Robert - please skim this draft if you haven't read this. It looks arcane, but is very important, very good work, pretty close to right. Plan is to advance this draft by April. Talking to ADs about status - not PS - BCP or Informational?