1.1 SIPPING Audio will be separated and annotated by discussion item (this is an experiment). Not getting updates before the deadline on working group documents (except for John Elwell). Note that next IETF follows quickly after the yearend holidays. Service Identification has been publication-requested. TURN is going through working group last call. Have added overload as working group item. Expecting to close or recharter in April 2009. Three 3GPP documents are not progressing 3GPP needs to drive this work, or find someone here who will drive it. (NGN reason, private network indication, RFC 3455bis). There is a VoIP lawful intercept draft please look at this and provide input. Key issues are scalability, interface specification design issues, security considerations. EKR says this work is precluded in the IETF by RFC. Mary says the authors keep pointing to Fred Baker's work and adding to it. 1.1.1 Update-PAI Does not specify use of PAI in responses based on October 3rd consensus call onlist. Hadriel : were no responses on mailing list and you decided to remove it? Mary : there were some responses. Hadriel : there are two or three people who don't like this and everyone else knows we need it. John : was further consensus call on November 14th, got late objections but no text proposals received as of yesterday noon. Hadriel : didn't have consensus to remove at last face-to-face. Gonzalo : we're talking about scope of a working group item. Hadriel : but this is a charter item. Gonzalo : but we're working on the scope of the charter item we have. Hadriel : but if we don't fix this now it will be another six years. People will ignore what we say. We have a couple of people who object and chairs are looking for negative ACKs. Gonzalo : we need to publish what we do have agreement on. Keith : document doesn't quite say what I wanted document doesn't say anything about 3325 at all. John : 06 text was broken, had to come out. Want non-broken text to add back in, I'm the editor and if the working group isn't saying anything, I can't update it. Add Keith's document makes no changes to 3325 text and leave this ambiguous? Keith : I'm convinced that 3325 covers responses within a trust domain, Cullen isn't convinced. Gonzalo : will make a decision in three weeks based on working group discussion at that time. Proposal : add service URNs? No feedback from the list. Jon : not what people envisioned, but can imagine why people want to do that. John : will add to next revision. Cullen : how do you authenticate a service URN? Current draft text is fine. If you add service URN, I'll be asking how it works. John : can you reply to the mailing list? Hannes : what the heck are you doing? Is this a callback method? Could you explain how it interacts with the PSAP? Not an authentication question when you have a callback, will bypass policies. This is a little premature, because ECRIT hasn't made a decision yet. Brian : please don't add text, but leave wiggle room to add it later. Andrew : should allow us to update this document again. Christer : specific usage would be specified elsewhere, but ABNF would allow this. Will discuss on the list and decide there. Brett Tate proposed to disallow PAI in ACK and CANCEL (same issue as responses). Hadriel : SIP ignores what we don't understand why would we disallow this? Just say nothing? Listing methods is problematic because we have to maintain the list if we add methods. Robert : just point out that these are hop-by-hop messages and you're good. Will make decision in three weeks. Cullen raised point about registrar Cullen thinks we're both OK with text. 1.1.2 SIP Overload Control Design Team Report No changes to design team membership since last meeting. Now a working group draft (00). Document is stable, does not include simulation results. Ready for WGLC? Who has read? A fair number of hands. Mary will do pre-WGLC review. We can start working on solutions and do a gentle handoff to SIP. Keith : object, that's not the problem with 199 draft. Simulation : upper bound results. Long delays trigger retransmissions and increase messages per call that must be handled. Not seeing big differences between control scenarios. Design team has produced a couple of technical papers. Mary : developers don't care about this stuff, it's all systems engineers. 1.1.3 SIP UA Profile Datasets Was in WGLC, removed references to Application-Profile, added normative statement at the top of the merging algorithms section. Mary : people don't seem to want to get this work done, but we need to get it done because it's holding other work up last remaining SIP dependency for Keith. Need expert schema review. Applicability of RelaxNG for schema? Dale Worley to make editorial pass. Gonzalo : need to work on the mailing list, not in meeting cycles Malta may not happen. 1.1.4 Offer/Answer Open Issues How to reject SDP offer in PRACK? With 488. Should be the same for dialog parameters. Do we commit/failback on failed re-INVITE? We commit successful changes. Does retransmission of reliable 18x stop regardless of final response? John : non-200 responses how do you know these responses didn't come from a proxy? You don't UAC has to send new PRACK. Does update 3261 normative text in Section 14.1 must be restored to last values successfully negotiated. PRACK is harder requires more text in 3262 requires 3262bis. Andrew : requires new option tag (rel100plus or something similar). Paul : we could always have gotten these error responses, we just never defined what happened if you do. Keith : please get Andrew's comment onto the list so we can actually see if having an option tag makes a difference. Does non-2XX response stop retransmission of a request? If not, can generate 481 for retransmission, may result in call drops need to remember that there's no retransmission. Are there other things we want to fix in 3262? First reliable response must contain SDP offer if INVITE does not remove this statement? Francois : concerned about interop problems if we remove this statement. Robert : this ended up as a compromise MUST to deal with glare conditions, need to look in archives, but it was an engineering decision to address a problem don't change this without a reason. If we revisit, remember this wasn't capricious. John : thinks there's something in 3261 that needs to change, too. Francois : need to do this in a backward-compatible way. We'll discuss this onlist. Keith : please make sure we've identified all the known issues with O/A if we're going to change 3262. 1.1.5 Event Throttle RFC 3265 has an absolute limit on rate of notifications and allows a further reduction for specific packages. Recent discussions about geopriv notifications. Force maximum notification time period between notifications, in seconds. Subscriber can suggest throttle/force/average, notifier can adjust, this can be dynamically changed. Is formula for timeout on average good enough? Should we be able to tune period dynamically? This is an OMA dependency put next version in hopper for working group review. Keith : only defines header fields, at IETF consensus doesn't have to move to SIP working group, any working group can create these. How many people have read the document? Enough. Will find reviewers for the next version. Will make decision about becoming working group document after we get feedback. Become a working group item? Sense of room was general interest. Robert : GEOPRIV has been making decisions assuming that this work was taking place. Mary : haven't gotten any feedback, should increase priority and quickly finish this one. 1.1.6 Correlation of multiple SIP dialogs Have removed a lot of use cases since Dublin, removed solution text. Want to accommodate distributed user agent clients. Have requirements correlate, expire state when last dialog is terminated, be backward compatible with endpoints that don't understand correlation. Alan : similar issue in BLISS looking at multiple appearances. Ended up defining dialog parameters. Do you need to know this at call setup, or at some later time? Don't have specific requirements about when correlation happens. Hadriel : is the goal to get all the use cases agreed here? Could have lots of other use cases (including B2BUAs). Had same issue as Alan, do you need parameter at call setup time for these use cases? Gonzalo thinks there's not a hard requirement for the identifier to be available at call setup time. Seeing several drafts that require this what's the level of interest? John : requirements are halfway to mechanism anyway. Burden is not on the person using uncorrelated media endpoints, it's falling on the OTHER person. Can't figure out why we need a mechanism from the use case diagrams. Gonzalo : person would treat two dialogs as one multimedia session. ??? Ingrid??? France Telecom needs such a correlation mechanism across a B2BUA. Paul : agree with John. Have no problem with use case wording, but there's more involved here. Can't get from use cases to requirements. Are lines in the picture signaling? They are signaling. Can set up two media sessions without using two dialogs. Cullen : interested in solving use case on related dialogs (sorry, missed this). Roni : whole solution needs to be specified before you go to requirements so you can see how it works. Also need to do correlation on m-lines, etc. Keith : lots of work to do before this goes to SIP for solution. Is this mobile? Only on dialogs, or on applications? How many dialogs can I correlate? Gonzalo : Keith is right, we need to check semantics. 1.1.7 CC-UUI New draft has explicit requirements, driven by use cases. Some discussion onlist, most issues resolved. Any requirements we need to discuss now? Who has read? A fair amount. Are people happy with requirements? Seem to be, in the room. Just looking for feedback on these requirements. Interested in working on solutions? Handover to SIP working group after three week review. Cullen : asking two questions. Gonzalo : adopt as working group item and ship in three weeks? Keith : needs to be a SIP charter item, new header, has to come through SIP. Are people willing to work on this draft? Gonzalo : SIP working group should take this? Hum is that we should agree on requirements and then take this to SIP. 1.1.8 Handover Requirements This is terminal mobility, not session mobility. Person is actually moving from terminal to terminal. Have addressed comments from IETF 72. Interested in forming a design team for IETF 74 ? is there interest? Some people self-identified as interested. 1.1.9 Debugging SIP Networks Debugging should be part of SIP network fabric. Adressed using AoR, debugging is as-needed, single logical entity controls debugging configuration, SIP entities can be triggered to debug based on SIP signaling. Two drafts : new event package and new header field. Do people agree on these requirements? Hadriel : thank you for coming. We need operational feedback. Agree that troubleshooting is a major issue right now. This is wrong architecturally in SIP. how do you debug when debugging doesn't work? Need vertical protocol (management/northbound), not SIP-based. There are tools we should add to SIP, but event packages will be problematic with B2BUAs. Need correlation header to correlate across B2BUAs. Gonzalo : have three IPR disclosures, one related to these drafts. Dan : also seeing security red flags, security considerations section is empty now. Dale : problems are important. Draft is about event package, and problem is how you use the event package , need a lot more information about how to use the procedures around the event package. You can trigger logging, but you probably want to filter on message types, retrieve logs, there are a lot of details you haven't documented yet. The problem is useful to solve, need to flesh out this architecture to see if this is the correct approach to the problem. Scott : thanks for bringing your perspective. anyone who has debugged SIP should agree. Agree we should not use an event package to trigger debugging. Should start a catalog of best practices for debugging SIP based on what's in the messaging itself. A SIP phone gets clues about what's gone wrong but developers don't know how to help the users. Also need to look at gaps in information that, if filled, would provide debugging capabilities. You get back a 400 and don't know what to do next. When SIP goes wrong it's almost impossible to figure out :why?. Scott plugged an expired draft suggesting that error responses include the request that generated the error have been doing this for about four years without UDP MTU problems. Andrew : is this intended as a general solution, or in controlled deployments? Dan : no way to restrict scope to 3GPP but that's where the motivation is coming from. Hadriel : is being proposed in 3GPP? Already agreed in 3GPP. Topic is incredibly important. Mary : need to see lots of interest on the mailing list (before the next meeting). Robert : Hadriel's comments carry assumption that we have to talk about documents in meetings to advance them decisions can be made entirely on the mailing list, running all the way to RFC. Read the list! Mary : encouraging this. Hadriel : apologize for misstating previously. Keith : please look at trace documentation before you leave Minneapolis incredibly important. Mary : first I heard about this was on the coordination call two weeks ago can't expect quick response that way.