Jonathan Rosenberg dynamicsoft

1. Jonathan Rosenberg dynamicsoft

2. Problem Statement • We still don’t have a good answer for NAT traversal in SIP!! • That is clear from nat-scenarios • Tons of cases • Best solution in each case depends on network topology, business issues, etc. • Lots of components • STUN, TURN, MIDCOM, RSIP, etc. • How can we expect interop or reliability?

3. Solution: Interactive Connectivity Establishment (ICE) • ICE is a methodology for NAT traversal • Makes use of STUN, TURN, RSIP, MIDCOM • Entirely resident within the clients • ICE explains how to use the other protocols for NAT traversal • ICE Properties • Always will find a means for communicating if one physically exists • Always finds the lowest latency communications path • Always finds the communication path cheapest for the service provider • Does not require any knowledge of topology, NAT types, or anything

4. Basic ICE Algorithm • Client obtains addresses • Local interfaces • UNSAF protocols • VPNs • Client lists all of them in an offer • Answerer tests connectivity to each of those • Connectivity test uses peer-to-peer STUN • Connectivity test may yield more addresses • Answer provides all its addresses (local interfaces, UNSAF, VPNs + STUN derived addresses) • Offer performs the same connectivity check • Highest priority address is used • May require several iterations

5. A calls B STUN address won’t work TURN address works But uses a relay ICE would send media directly from A to B Uses an address obtained from the STUN server running in B Example Hard Case Internet STUN TURN NAT Private Net 2 B NAT Private Net 1 A

6. ICE Drawbacks • Requires both sides to support it • If not, falls back to what we have now • MAY require an extra RTT in call setup • Port restricted NATs on both sides • Requires muxing STUN and media on same port • Ugly but works • Requires definition of SDP attributes • “Alternate” semantics for a c line • STUN attributes

7. Proposed Plan • Deprecate current nat-scenarios • Replace with the procedures defined in ICE • Specify needed SDP attributes in mmusic • Specify preconditions in SIP • Phone doesn’t ring unless both sides can hear each other • Benefit: • A single mechanism that handles all NAT cases cheaply

8. Caller Preferences Use Cases Jonathan Rosenberg dynamicsoft

9. Problem Statement • Not clear what problems caller preferences is trying to solve • Not clear how to properly use caller preferences • Not clear how to properly implement algorithms in a proxy • Not clear what services are enabled by caller preferences

10. Solution: Use Cases • Defines a set of use cases for caller prefs • Formatted in problem/solution pattern • Examples: • How to route a call to voicemail directly • How to reach a videophone first, voice-only phone second • How to force a call to reach a person, not a machine • Will also provide explanation on how to implement proxy algorithms • Will provide explanation on how to set various attributes

11. Scope • Use cases are driving requirements into caller preferences mechanism • Limit scope to things that can be done with caller preferences today

12. Proposal • SIPPING should adopt caller preferences use cases as a work item for Informational RFC • Perhaps BCP?

13. URI Leasing Jonathan Rosenberg dynamicsoft

14. Problem Statement • Many uses of SIP require a call to be routed to a specific UA instance • Attended call transfer • Ad-hoc conferences • Presence • Would also like an alternative to dialog sharing! • Has many problems • Rather have a separate request which can route to the same UA instance

15. Globally Routable UA URI (GRUU) • Routable from anywhere • Routes to a specific UA instance • May be temporally scoped

16. Alternatives for getting a GRUU • Use user AOR • Clearly doesn’t work • Use device IP address as URI • Not reachable from everywhere – firewalls, NATs, policy, etc. • Caller Preferences • A-C:*;uri-domain=<IP of device> • Doesn’t always work – call centers • Embedded Route Headers • Not allowed in Contact URI • Long term loose routes have reliability problems • Route may only work from certain places

17. Proposal: URI Leasing • Provide a mechanism for a UA to obtain an infinite supply of URIs • Each URI routes to the same device instance • URI is constructed by the owner of the domain • URI is “leased” – URIs become invalid if not refreshed • Important Characteristics • Owner of domain constructs URI as they wish! • Infinite supply means that UA need not obtain a new lease for each call

18. Constructing a URI • Approach I: Stateful • Domain provider pushes state into proxies for each URI • Approach II: Embedded info • User part of URI contains embedded info: • Sip:E[username,device-IP,HMAC]@example.com • Much like embedded Route headers, BUT has none of the problems • Other approaches are possible

19. Be possible to obtain a GRUU Can specify time of lease Domain provider can negotiate lease time Domain provider can specify format of URI When URI expires response is 404 Must not incur provisioning overhead Can be done statelessly Can provide anonymity Call centers Features can be associated with a GRUU like any other AOR Can obtain infinite number of URIs without protocol operations Authentication, integrity Leasing Mechanism Requirements

20. Proposal • Work on a URI leasing mechanism to meet the needs of • Transfer • Presence • Replacement for dialog sharing

21. Session Policy Requirements Jonathan Rosenberg dynamicsoft

22. History • Initially, proxies do routing and signaling services, no say on the sessions and their parameters • However, experience shows that there is increasing need for proxies to impact sessions: • NAT/FW traversal • Codec grooming • Principal technique for this to date is SDP modification

23. Problems with SDP Modification • Fails in the presence of e2e encryption • May cause integrity checks to fail when used with e2e authentication • Requires proxies to have knowledge of session descriptions • Proxies have to pay attention to Require • Proxy complexity significantly increases – scale concerns • Introduces new points of failure • CONSENT

24. Consent • IMPORTANT: Robust networks are based on a contract between the client and network • Network does what its asked, no more, no less • Contract violations means that applications will eventually fail • Example: NATs • Example: SDP rewriting • Example: OPES • These failures will be nearly impossible to trace

25. Better Solution: 488 • Client sends INVITE w. SDP • Network rejects with 488 and provides allowed codecs and media types • Benefits: • User explicitly knows what has happened • Drawbacks: • Increases call setup time, significant for multi-hops • Only useful for codec and media stream grooming • Client still doesn’t know that it’s the NETWORK that has the constraints • Still doesn’t work with e2e encryption (authentication OK)

26. Requirements for Ideal Solution • Works w. e2e authentication and encryption • Allows RFC3261 compliant proxies (I.e., no spec violations) • Small processing load • Session Description Format agnostic (SDP, SDPng) • Minimal to zero increase in call setup delays • Minimal protocol overhead (wireless!) • Support new policy types • Works inter-domain

27. Requirements for Ideal Solution • Each proxy can assert an independent policy • Policies can be per-media stream and in each direction • Allows insertion of media intermediaries • Allows specification of source routing (probably useless for RTP) • Intermediaries through FQDN or IP • Can bar media streams by type (no video) • Can bar specific codecs • Can ask the UA to perform QoS reservation • Can ask UA to provide specific credential in QoS reservation (RFC 3313 alternative)

28. Consent Requirements • UAC and UAS both know what proxies want • UAC and UAS can reject policies • Proxies can know whether UAC/UAS accepts or rejects • Proxies can inform UAC/UAS of implications of non-compliance (needed?)

29. Security Requirements • UAs can verify the identities of proxies who made policy requests • Integrity protection on policy requirements • UA can have a guarantee of policy setting by on-path elements • Confidentiality of policy requests (hope not) • No new DoS attacks • Don’t interfere with RTP security

30. Proposed Information Flow INV [Info Obj + S->C Pol Obj] INV [Info Obj] INV [Info Obj + 2 S->C Pol Obj] 200 [Info Obj + S->C Pol Objs + C->S Pol Obj] 200 [Info Obj + S->C Pol Objs] 200 [Info Obj + S->C Pol Objs + 2 C->S Pol Obj] ACK [2 C->S Pol Obj] ACK [2 C->S Pol Obj] ACK [2 C->S Pol Obj] UAC P1 P2 UAS

31. Open Issues • Which session policy parameters require dynamic negotiation during a call? • Can allowed codecs be determined out-of-band? • From 3gpp/ietf workshop, 3gpp is expecting activity here • Is IETF interested?

32. App Interaction Design Team Jonathan Rosenberg dynamicsoft

33. Summary • Current I-Ds • Draft-rosenberg-sipping-app-interaction-framework-00 • Draft-culpepper-sipping-app-interact-reqs-03 [refreshed] • Draft-jennings-sip-app-info-00 • Draft-burger-sipping-kpml [refreshed] • Little activity since last meeting 

34. List Issues on KPML • How are notifications done with SIP? • Are they one shot, or can you get another document (and if so, should you be using HTTP) • Is this an implicit subscription? • How to handle proxy-based applications • Bigger issue: • Does anything BUT one-shots make sense for KPML? • Can rule other usages out of scope… • Digit suppression – don’t send subsequent digits in the media stream if they match a pattern • Proposal: Do this only if one pattern can possibly match

35. Continuing Issues • Framework scope and complexity? • Supporting immediate barge functionality in KPML? • Lifecycle management of UI components