IETF67 SIP Session 1 1. Chairs Update Charter updates, lots of RFCs published, in queue, or IESG. v6-transition and toip publication has been requested. capacity-attribute, dialogusage, consent-framework,pending-additions,config-framework WGLC completed RM - contents for config has been hanging around, when will we pick them up as WG items Chairs - get framework done first bunch of docs moved to sip b/c of sip change process KD - please comment to sip list on these documents 2. Agenda Bash 3. Chair comments on document progression: lots of reviewers, enough chair cycles. Document authors not responding quick enough. May appoint editors to work on docs 4. SIP Torture Test for IPv6 -03 faily complete. Open issue on syntax: will use [ and ] 5. littlefield-sipping-mgmnt-event-01 draft - please read 6. session-policy-framework V. Hilt SIP WG item. Lots of reviews, changes in response. Issue: Correlate Policy and INVITE - should proxy be able to correlate a policy and a subsequent INVITE? Provides a hint that the UA has policies but no guarantee that UA is using the policies. Options: provide session id to PS, token pass to UA, no correlation. Proposed: session ID to PS. AH- what stops UA from lieing? VH- Nothing ?? - What do we do with this if you can lie RM - For simplicity - do nothing GC - policy enforcement outside scope, useful to know ua has seen policies ?? - My requirement, idea was token, from policy server, could be used subsequently (same routing decisions) JR - Is there a discover aspect? Finding right policy server or proxy server in a farm of them. Would need a token VH - with address of PS? JR - Opaque maybe, but identity of PS would be nice Shida - Confused, who does what? VH - Understand the case for routing Chairs - Some people want it, others don't care, seems like token fixes more problems RE - Can't know about enforcement, does inform, no harm Chairs - token ?? - using TLS, maybe should use identity 7. event package for session specific policies Issue: Disclosure of Session Information. Which info should a subscriber disclose to a PS when setting up a subscription. Needs to sufficiently describe a session avoiding negotiation. Proposal - send all fields of a media policy doc it has deata for Ready for WGLC Chairs: okay, 8. user agent profile dataset Added session encode info. Definition of session encode needs to be added to Relax NG Issue 1: Elements for R-URI, Call-ID/token, contact, info, max BW, stream containing media type, codec, local URI, remote URI is this okay? Issue 2: Policy Elements are ipinip intermediary and ip-loose intermediary needed? GC - don't need them RM - can't make them inte roperable Should BW related elements be added? A? - do we need min BW you could count on Need to add element for local policy server URI? Suggest keeping it GC - Yes Next Steps - WGLC 9. Overload Requirements - J. Rosenberg Added simulation model, no actual requirements changed. Sim model allows non sip experts to assist in understanding problem and solution. Allows benchmarking of solutions, better understanding of problem. RM - No comfortable with this as model, how important is this model to the problem JR - think its pretty close to reality RM - what goes in the beginning and what goes in the back end varies widely JR - parameterized, you can change how much is in the front end vs back ebd Next steps, tweak model, ready for WGLC, promote to sipping work item HS - Lots of work on performance eval, should use same model/metric (malas draft) JR - Doesn't see much correlation JG - Some parms intuative, some aren't, add description to table of parms GC - WGLC sked for March 10. Overload control draft - V. Hilt Combines hilt-hopbyhop with malas congestion control Scope - only when resources to process all the messages are exhausted Samples load, send control throttle downstream, with well defined throttle behavior and algorithms to transition between throttle states JN-Need hysterises HS - Problem looks like a closed loop but dangerous (we are DROPPING things). Mostly load is bursty. Damage is immediate Need to look at spreading load before we do drop. Timers are really tricky VH - Algorithm needs to be very well defined CJ - Need knowlegge of multiple downstream elements (not one) JR - Of course. Addressing Henning, okay, but what else do we do, someone has to lose JK - Need to describe connections between sets of entites, not 2 JN - Is the traffic only from downstream to upstream, feedback from upstream to downstream? VH - Yes HS - Presenting model as single upstream to single downstream misses fundamental problem that its a set of elements talking to a set of elements. Also, drops early may not be best. May be able to buffer instead of drop. Latency may be long. VH - Agree need to consider sets of elements. Drop is useful in most cases. Increase buffer caused message timeout. JR - Don't want to spend time in intermediate element processing messages that will be subsequently dropped DM - PSTN when trunks fill, calls get dropped. Current solutions have braindead call admission control, this could be much better. ?? - Need to inform neighbors, not just upstream RM - Still arguing requirements, put requirements in the requirments doc KD - At some point will be SIP, model should be in sipping. Are we going to specify the algorithms or just the framework VH - will describe algorithm JR - Model exists to specify algorithm. Do we specify downstream and let upstream deal, or specify upstream and let downstream just decide. Wants to specify upstream. JP - Need to specify how to measure in downstream JR - Agree, well defined parameter in downstream, but not how you compute it. JG - Lots if variation in measurement, needs flexibility 11. Malas performance metrics Narrows scope end to end only, doesn't include net connectivity, switch/router perf, server processes/hdw perf Metrics changed: removed avg hops per INVITE, added registration request delay, changed session completion delay to session disconnect delay (BYE to 200 OK), separated session completion rate into successful and failed sessions. Added clarifications around message retrans. Defined new terminology, units of measure for metric outputs. Added UAS metrics, align time begin/stop to E.721, changed registration request delay to 403 rqather than 401. Add Time out cond Issue: Should failure conditions be included in SRD (Post dial delay)? RM - Don't care as much ?? - Come to other ippm meeting CJ - Discussing where to put it; keeping moving 12. Clarification of Privacy Mechanisms 3323 vs 3325 vs 4244 Clarify use of mechanism, use of headers, etc. Issue: Should draft consider parameters as well as headers? Suggest expand to parameters Issue: Does it matter who does it? Suggest no Chairs: Need meta discussion of do we need new mechanisms? RM - Agree current specification is unclear, need some work JR - World has changed, want to move to different model. Give UA tools to make what it wants private don't want to expand how a privacy service needs to muck with headers JP - Regardless of where you do it, need to know what to do. As new headers are invented, have to decide how to manage privacy. Although some UAs will have tools, may need network to do it. "Unfortunate position" RM - May need to do some deprecation, but there are still use cases. Can't make old priv values have new semantics ?? - Want to support this work JR - Even if the UA can do a lot of work, must tell network not to put more info in (maybe only need "id" priv). Accepts that network assist may be needed. Less is more. What do we do? Chairs: some interest in the group, need more discussion on list 13. Refuse handling of URI-List "495 URI-List Handling Refused" RM - Sounds like intersection of this and session policy work AR - URI may be in differnt domain, worried about size of return. Couldn't a 300 series response do this? GC - Need the list refused AM - Contact GC - Not really the same thing GC - Should this be a P header? A? - Do you get the LIST or the members on the list it couldn't handle GC - members ?? - need the list too KD - Need requirements first, then solution JR - Lots of reasons to reject. Only need a reason when the other end can DO something with the info. Not clear why we need it. AA - OMA use case, focus exploded list, there is another list embedded, need someone else to explode it. DW - No privacy issues, if you have list uri, you can get membership KD - New headers (that are not P-Headers) go to SIP, need requirements first 14. Coping with early media Identify common problems, how endpoints and proxies deal with it, identify requirements, recommendations Clipping, no correlation between media and signaling, media may be faster than signaling RM - Clipping is not recieving the media SDP in a bottle = offer must render all streams sent to it. Untrusted data may be sent prior to answer RS - Says "must recieve" not render FA - RFC says "random", this is not good RS - Tendancy to assume the world is a particular way, specs don't say that now Classifies types of early media = announcements, ringing, forking results, alert-info. Coping mechanisms - proxy SDP hacking, client fork detect, client slow start Desired result of draft - define procedures to fix problems or at least make it more predictable Where fixes can't be done, explain. JR - Don't need another one stop shop for early media GC - Separate tutorial data from changes to specs RS - Some data in SIPit reports Chairs - more list discussion