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. Example Hard Case 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 NAT STUNTURN Private Net 1 Private Net 2 Internet A B

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= –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. Leasing Mechanism Requirements 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

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 UAC P1P2 UAS INV [Info Obj] INV [Info Obj + S->C Pol Obj] INV [Info Obj + 2 S->C Pol Obj] 200 [Info Obj + S->C Pol Objs] 200 [Info Obj + S->C Pol Objs + C->S Pol Obj] 200 [Info Obj + S->C Pol Objs + 2 C->S Pol Obj] ACK [2 C->S Pol Obj] ACK [2 C->S Pol Obj]

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