Jonathan Rosenberg dynamicsoft

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?

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

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

Example Hard Case Internet A calls B STUN address won’t work TURN 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 Private Net 2 B NAT Private Net 1 A

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

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

Caller Preferences Use Cases Jonathan Rosenberg dynamicsoft

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

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

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

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

Jonathan Rosenberg dynamicsoft URI Leasing Jonathan Rosenberg dynamicsoft

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

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

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

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

Constructing a URI Approach I: Stateful Approach II: Embedded info 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

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

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

Session Policy Requirements Jonathan Rosenberg dynamicsoft

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

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

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

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)

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

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)

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?)

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

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

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?

App Interaction Design Team Jonathan Rosenberg dynamicsoft

Summary Current I-Ds Little activity since last meeting  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 

List Issues on KPML How are notifications done with SIP? Bigger issue: 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

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