IETF72 SIPPING Monday AM Session Notes by Brian Rosen Chair Notes: Lots of drafts in progress, as usual Charter Update, several dates slipping, as usual 3GPP Dependency Docs Served USer on track service identification completed IETF LC Not progressing ngn reason private network indication rfc3455bis Real Time Text Taskforce (ISOC sponsored activity) 1. draft-ietf-profile-datasets-01 Martin Dolly Two values for visibility attribute: user & admin. Display of value not displayed if admin Policy attribute used only inside container Closest value first merging attritribute local network takes precedence over other profile type subs followed by device and then user Propose WGLC 2. draft-ietf-sipping-service-identification-02 Jonathan Rosenberg Separated 3 concepts: Service Identifier, Declarative Service Defn, Derived Service Indentification Added use case where sip adds audio to non-sip game URIs as a key architectural principle Litmus test for DWIM vs DWIS Delayed Offer: don't do that, not compatible with media based service id CH - Hasn't read latest draft, owe you comments. 3GPP still has issues with text string compare in Accept Contact. JR - 3840/41 is still available. Aggregate wrappers may be difficult beyond that CH - Can continue on the list, case by case decision (how many feature tags would it take?). "Audio" is too broad JR - Disagree. Tags are binary (all or nothing). Would have to have lots of collection of features to have descrete tags for pieces SD - 01 was good enough 02 was improvement. Time to get it out HK - Simplest case of delayed offer is handled JR - Will hunt Christer down and deal with issues f2f at IETF72 3. draft-hilt-sipping-overload-design-00.txt Volker Hilt Design considerations and models for overload control Not a proposal for a solution Implict vs Explicit Overload control Sip server load is regenerative which increases load at an overloaded server. Selecting messages to drop takes resources. Random drop doesn't work because transactions are not completed, causing more messaging. Explicit actually reduces the load JP - Doesn't mention RPH VH - Mentioned in solution draft Topologies Feedback types: rate based, loss based, window based Wants to know if doc should be working group item? Chairs: Should this doc become WG item and request early cross area review JR - Is this in addition to a mechanism doc? Chairs - Yes Humm for adoption - Unanimous Hands for who read it? Significant number; better than average Next steps: Evaluate different network conditions (network loss and transmission delay) Offered load distribution (esp uneven distribution) Overload events: Sudden peak, sudden peak with gradual release, temporary light overload Changes in neighbor set fairness criteria: user-centric fairness, provider- centric, "customized" (ex specific source sending unusually high load is TD - "Airplane algorithm"= some users already delayed, don't delay more users VH - Think this is covered HS - Sometimes a local matter. Sometimes need to be fed back to earlier entities TH - Unfairly disadvantage some set of users HS - Push overload indication to unloaded server. That server can choose who gets hurt 4. draft-shen-sipping-load-control-event-package-00.txt Henning Schulzrinne Legitimate (user voting in game show, disaster event causes lots of calls in/out) Don't affect other users Design consideration drafts generalize load sharing (destination agnostic) and wouldn't work well This draft complements the general problem. Push a filter to as close to generative user as possible Possibility to distribute filter in advance Flexible filter identity Solution Load Control Event Package Load Control XML document Recursive subscription from downstream entities MD - "American Idol" example best resides at gateway rather than app server. Subscription model may not work HS - Separate filter mechanism (xml) from way to get filter (event) JR - Interesting, but how does it overlap with main work? AR - Interesting, but not clear how it works in unknown routing rather than predetermined paths HS - Agree. No SIP broadcast mechanism ?? - Same kind of thing as Internet designed DOS. Works in closed environments, doesn't work where sender and sendee don't know each other (security issues) JG - Same envrionment as where RPH is used 5. draft-ietf-sipping-update-pai-04.txt John Ewell Should it work beyond tel/sip/sips Should it work with more than one tel, one sip Some URI schemes incompatible, need some guidelines Interacts with Identity, which is still in flux, wait until it settles Could progress now, extend scope and immediately progress, or put on hold pending identity issue resolutions FA - Worries about simple extensions causing more backwards compatibility issues JE = Already a potential problem, all we can do is incremental improvement TH = Agree, always an issue with extending what is allowed. Sticking to current scope best. Maybe better to use a different header if "ignore if you don't understand it. JP = Ghost of Identity responses. Extend the scope CJ = Sent lots of comments on responses, etc KD = Concerned about compatibility. Some implementations may choke on first URI they don't understand JR = At least extend to forward compatibility (eggregious error in 3325) Chairs want sense of room on how to proceed Humm for continue work vs hold for Identity stuff: Continue work JR - Response identity issues must be dealt with JE - Need another draft for sure Chairs - Agreeing to progress the document, new draft, another WGLC 6. draft-loreto-sipping-context-id-requirements-00.txt Salvatore Loreto Form of preservation of state across sessions and to correlate an existing dialog with multiple transactions, including some outside a dialog Example: Correlating an isolated Message with a succeeding MSRP session Correlate a new conversation with a previous one Correlating separate devices with the same conversation (not a Join) Requirements: correlate dialog with anothe existing dialog correlate a new conversation with a previous one End to End Defined Time to Live (per app) JR - Still starting with assumption for context ids (ie put mechanism aside). The case of multiple devices with same user is interesting and worth exploring KD - Not convinced connection to CCVS is valid (ISDN similarity). Re-creates MSRP. Also considered about layering. SL - Agree on layering issues. Draft starts discussion. Maybe CCVS is not the best example. More like cookies. DW - Another requirement not explicit, first message didn't know there would be a following session. This is a low overhead bookmark so suceeding operation can do more work and take advantage. Chairs: Possibly two sets of problems (history issues and multiple devices issues) 7. draft-ietf-sipping-sip-offeranswer-08.txt Christer If re-INVITE faile, what happens with offer/answer transactions that were successfully completed? reINVITE/183/4xx (reINVITE/183 succeeds) reINVITE/183/Update/183/4xx Two Alternatives: Roll back to before reINVITE or keep successful o/a Pros and cons of each Need to decide and document JR - Letting process get in the way. This is a problem. MB - O/A update just lists issues HH - Need a decision in the meeting, and need a document JR - Mild preference for accept sucessful O/A. Preconditions within established dialog cruft for original INVITE probably doesn't apply. RS - Decoupled from dialog state, probably right thing to do. Mild discomfort over accept successful O/A, will eventually roll dialog state back and this weird unless we REALLY decouple O/A state from dialog state Chairs: We will answer the liaison and then do a document Humm for Rollback (option 1), accept sucessful O/A (option 2): Consensus on Option 2 RS - Are people confortable making decisions now? Chairs: show of hands of who wants to wait? (maybe a dozen). List discussion with bias towards accepting the humm. 8. draft-johnston-sipping-cc-uui-04.txt UUI transport over SIP Not a full Q.931 transport Not a candidate for INFO (conveyed at time of call setup) Requirements: Inserted by a UA, consumed by a UA Can be inserted/used by a proxy Can be included in redirect Can survive proxy retargeting and Request-URI rewriting MD - UUI can be sent mid call AJ - then you could use INFO KD - proxy case may not be there Could use MIME type, URI param, existing header (?Call-Info) or new header Proposes header DW - May need Require/Supported tag Chairs: P header or regular header? AJ - Not private, not restricted. When used with retargeting, has to carry though networks, so regular header KD - Doc doesn't actually list requirements AR - Agree, need crisp requirement. Not sure in header is right; should look like SIP-T body approach. Esp if could be used with INFO JRaf - Need this JR - Confusing why this is so different from SIP-T. Need more motivation AJ - Agree, need more context and diagrams Chairs: Is this interesting (not adoption)? Humm: Clear indication of interest 9. draft-schwartz-sipping-nsr-code-00.txt David Schwartz Existing sip Not Found response codes not good enough for non-valid numbers 410, 604, 404 604 and 404 may not be relevant for an e.164 We use 404 today, but response is inconsistant. Need something that "nothing wrong, but I can't tell you anything else" HS - Disagree with interpretation of 404. Adding more status codes which are similar but not the same is a bad idea. Clarification is always welcome. DS - Find ambiguity with how 3261 codes are distinguished. In this case its the fact that the domain is not authoritative for the e.164 but has no way to express this JP - Agree that there is a problem, but should we have response codes only applicable to TNs? For example 404 on a tel URI, what does that mean? DW - We can't differentiate the cases. The inherent problem is TN@domain. Should use tel URI. Chairs: Need to decide if there is a problem to be worked on JH - Don't guess what the intent of the request was. Must repond to what recipient was given DS - Okay, so the question is what to do if it was tel URI, what is the right error if some other domain could respond, but this domain cannot. 10. draft-niccolini-sipping-siphandover-04.txt Jan Seedorf Not the author, questions perhaps answered by Eric Burger "Mobile Host" needs seamless handover as mobile host moves Needs to be fast, not a transport (MIP) issue, needs to work with NAT Some solutions out there, but not fast enough, other requirements above. Two solution drafts. Authors teamed on requirements draft HS - Many moons ago we had a session mobility draft. Some day, it will be an RFC. This is not fundamentaly different. Also not taking into account prior work on terminal mobility. FA - Lots of solns out there JS - Yes, but they are not fast enough CH - Work in 3GPP, have you looked at them JS - Yes, we've looked at it. One of solutions is similar. Henry - Is this designed to avoid roaming charges? JR - Nice doc, good problem statement, good requirements. Want to see more like this. ?? - General comment on "faster". Typically architecture flawed, or bad implementations. Need precise definition of why current stuff is too slow JS - Existing soln need complete re-INVITE EB - Fast enough means no loss of media Chairs: Who is interested? Slight preference for yes, it's interesting. CH = Christer Holmberg, JR = Jonathan Rosenberg, VH = Volker Hilt SD = Spencer Dawkins, HK - Hadrial Kaplan, JP = James Polk, TH - Ted Hardie, HS = Henning Schulzrinne, MD = Martin Dolly, AR = Adam Roach, JG = Janet Gunn, FA = Francois Audet, JP = Jon Peterson, CJ = Cullen Jennings, KD = Keith Drage, AJ - Alan Johnson, JRaf = Jim Rafferty, DW = Dale Worley, MB = Mary Barnes, HH = Hannu Hietalahti, DW = Deal Willis, JH = Joel Halepern, JS = Jan Seedorf, Henry = Henry Sinnreich, EB = Eric Burger