Transcript Jonathan`s slides

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
STUN
TURN
Internet
NAT
– But uses a relay
B
• ICE would send media
directly from A to B
Private
Net 2
NAT
– Uses an address obtained
from the STUN server
running in B
A
Private
Net 1
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
INV [Info Obj] INV [Info Obj
+ S->C Pol Obj] INV [Info Obj
+ 2 S->C Pol Obj]
200 [Info Obj + 200 [Info Obj +
200 [Info Obj +
S->C Pol Objs S->C Pol Objs]
S->C Pol Objs
+ 2 C->S Pol Obj] + C->S Pol Obj]
ACK [2 C->S Pol ACK [2 C->S
Obj]
Pol Obj]
UAC
P1
ACK [2 C->S
Pol Obj]
P2
UAS
Open Issues
• Which session policy parameters require
dynamic negotiation during a call?
– Can allowed codecs be determined out-ofband?
• 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-interactionframework-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