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

• 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

NAT

STUN TURN

PrivateNet 1

PrivateNet 2

Internet

A

B

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?

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

UAC P1 P2 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 PolObj]

ACK [2 C->S Pol Obj]

ACK [2 C->S Pol Obj]

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