SIPPING IETF 57

1. SIPPING IETF 57 Jonathan Rosenberg dynamicsoft

3. 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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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?

10. Session Policy

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

12. 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

13. 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

14. URI Leasing

15. 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

16. 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

17. Progress • An informal group met @IETF57 • 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

18. 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

19. 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 Current Mechanism Thinking INV sip:aahu.userpart@example.com Registrar 200 OK GRUU: aahu REG M:sip:c1@1.2.3.4 Client INV sip:c1@1.2.3.4;gruu-info=userpart

20. 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