SIPPING IETF 57 Jonathan Rosenberg dynamicsoft

Status IETF 56 –First introduced –Proposal was: Adopt as WG item Replace sipping-nat-scenarios with ICE-based flows Preconditions work in sip –Good interest, hum to make it working item, but seemed like few had really read it yet –Concerns expressed during meeting Backwards compatibility Replace nat-scenarios: need to see it Too complex

Ice-01 Addressed concerns expressed in IETF 56 –Backwards compatibility No longer using ALT semantic of SDP grouping extension Instead, using an “alt” attribute M and c lines contain address most likely to succeed Result is that when ICE-aware client calls non-ICE- aware, there is no extra RTT, no Require header needed

Scenarios Ice-01 has nearly 50 pages of example flows These are the content of the proposed replacement of sipping-nat-scenarios Outcome –Shows how the same client behavior and overall algorithm work for Residential Enterprise Centrex –Some more flows needed, some more work needed

Other ICE changes Answer construction simplified – including all your addresses. –Used to need to fragment to deal with m-line matching requirements Optimization to avoid extra cycles: don’t offer a new address if peer has already connected to a higher priority one –Connected determined by receipt of STUN Removed suggested q-values – only ordering important Partial alignment to parallel TURN rev

Technical Open Issues Determining “address most likely to work” for population into m and c lines – need an algorithm –Won’t always be right – enterprise Do we need to deal with enterprise firewall policies which prevent outbound UDP from any internal host? –May need to add outbound relay – ala MSRP – to TURN

Process Open Issues Do we want to proceed with this, and if so, where? ICE helps with many problems –NAT traversal –IPv4/IPv6 transition – used in v6ops transition documents –RTSP – may be used by them too –RTP DoS Prevention: see draft-rosenberg-mmusic-rtp- denialofservice Proposal: Proceed

How to proceed ICE needs to be split into four documents: –Main ICE Behavior: BCP in sipping or mmusic –SDP Extensions: mmusic –Precondition: do people care? If so, sip wg (will need requirements) –Usage Scenarios with SIP: sipping – replacing sipping-nat-scenarios Volunteers to help with some of this?

Session Policy

Changes from previous version Name change to reflect wg item Minor typos and cleanup No real substantial changes – has had limited discussion, though folks have continued to express interest

Open Issues Issue 1: Dynamic vs. Static Policies –The requirements are written in a way that assumes that policies are made during call setup (dynamic) –Some policies can be done outside of a call (static): What codecs to use –Some policies are inherently dynamic Intermediary to use – port is specified per call –Static is much simpler –Do we need dynamic?? May be other approaches – ICE ?? May not work for CALEA – depends on your interpretation

Open Issues Do UAC and UAS need to know about media changes requested of their peer? Do we need to encrypt media policies so that only UAC/UAS can see them? –Hard to achieve –Sips would get us privacy excepting in-path elements – seems good enough to me Mechanism must not introduce DoS – is this stating the obvious? –Proposal: rephrase as – must not introduce amplification on unauthenticated requests

URI Leasing

History General problem: How to route a request outside of a dialog to a specific UA instance –Conferencing – ad-hoc conferences –Assisted Transfer –Presence Draft-rosenberg-sipping-lease written with requirements and proposed solution –Assumes that the right answer is to “lease” an AOR for the UA instace

IETF 56 Others feel that using embedded Route headers is a better solution Confusion about level of complexity implied by lease solution Confusion about what the requirements document should look like

Progress An informal group –Rosenberg, Jennings, Kyzivat, Johnston, Mahy Our conclusions –Leasing approach is the right way to go –The sipping requirements document should focus on the small number of requirements for solving the GRUU problem I.e., they are not leasing requirements

Why leasing? Embedded route headers imply that the proxy doesn’t know that this is a request to an AOR (a GRUU is an AOR) –Proxies can’t apply policy –Proxies can’t apply user services Can be done statelessly –Side effect of register request Can provide privacy

Current Mechanism Thinking Client sends REGISTER request Response contains a GRUU Prefix in a header Client can append user- data to GRUU Prefix to build an AOR Proxy forwards requests for that AOR to the contact it is bound to –User-data also passed to user Registrar Client REG 200 OK GRUU: aahu INV INV

Open Issues Do we need to generally allow a UA to obtain an unlimited number of GRUU? –Needed for conferencing, but other applications? Does the GRUU go into the Contact header of INV/200? –Will be the end of direct signaling… Syntax of the URIs