SIPPING IETF 57

1
SIPPING IETF 57

• Jonathan Rosenberg
• dynamicsoft

2
(No Transcript)
3
Status

• IETF 56
• First introduced
• Proposal was
• Adopt as WG item
• Replace sipping-nat-scenarios with ICE-based
  flows
• Preconditions work in sip
• Good interest, hum to make it working item, but
  seemed like few had really read it yet
• Concerns expressed during meeting
• Backwards compatibility
• Replace nat-scenarios need to see it
• Too complex

4
Ice-01

• Addressed concerns expressed in IETF 56
• Backwards compatibility
• No longer using ALT semantic of SDP grouping
  extension
• Instead, using an alt attribute
• M and c lines contain address most likely to
  succeed
• Result is that when ICE-aware client calls
  non-ICE-aware, there is no extra RTT, no Require
  header needed

5
Scenarios

• Ice-01 has nearly 50 pages of example flows
• These are the content of the proposed replacement
  of sipping-nat-scenarios
• Outcome
• Shows how the same client behavior and overall
  algorithm work for
• Residential
• Enterprise
• Centrex
• Some more flows needed, some more work needed

6
Other ICE changes

• Answer construction simplified including all
  your addresses.
• Used to need to fragment to deal with m-line
  matching requirements
• Optimization to avoid extra cycles dont offer a
  new address if peer has already connected to a
  higher priority one
• Connected determined by receipt of STUN
• Removed suggested q-values only ordering
  important
• Partial alignment to parallel TURN rev

7
Technical Open Issues

• Determining address most likely to work for
  population into m and c lines need an algorithm
• Wont always be right enterprise
• Do we need to deal with enterprise firewall
  policies which prevent outbound UDP from any
  internal host?
• May need to add outbound relay ala MSRP to
  TURN

8
Process Open Issues

• Do we want to proceed with this, and if so,
  where?
• ICE helps with many problems
• NAT traversal
• IPv4/IPv6 transition used in v6ops transition
  documents
• RTSP may be used by them too
• RTP DoS Prevention see draft-rosenberg-mmusic-rtp
  -denialofservice
• Proposal Proceed

9
How to proceed

• ICE needs to be split into four documents
• Main ICE Behavior BCP in sipping or mmusic
• SDP Extensions mmusic
• Precondition do people care? If so, sip wg (will
  need requirements)
• Usage Scenarios with SIP sipping replacing
  sipping-nat-scenarios
• Volunteers to help with some of this?

10
Session Policy
11
Changes from previous version

• Name change to reflect wg item
• Minor typos and cleanup
• No real substantial changes has had limited
  email discussion, though folks have continued to
  express interest

12
Open Issues

• Issue 1 Dynamic vs. Static Policies
• The requirements are written in a way that
  assumes that policies are made during call setup
  (dynamic)
• Some policies can be done outside of a call
  (static)
• What codecs to use
• Some policies are inherently dynamic
• Intermediary to use port is specified per call
• Static is much simpler
• Do we need dynamic??
• May be other approaches ICE ??
• May not work for CALEA depends on your
  interpretation

13
Open Issues

• Do UAC and UAS need to know about media changes
  requested of their peer?
• Do we need to encrypt media policies so that only
  UAC/UAS can see them?
• Hard to achieve
• Sips would get us privacy excepting in-path
  elements seems good enough to me
• Mechanism must not introduce DoS is this
  stating the obvious?
• Proposal rephrase as must not introduce
  amplification on unauthenticated requests

14
URI Leasing
15
History

• General problem How to route a request outside
  of a dialog to a specific UA instance
• Conferencing ad-hoc conferences
• Assisted Transfer
• Presence
• Draft-rosenberg-sipping-lease written with
  requirements and proposed solution
• Assumes that the right answer is to lease an
  AOR for the UA instace

16
IETF 56

• Others feel that using embedded Route headers is
  a better solution
• Confusion about level of complexity implied by
  lease solution
• Confusion about what the requirements document
  should look like

17
Progress

• An informal group met _at_IETF57
• Rosenberg, Jennings, Kyzivat, Johnston, Mahy
• Our conclusions
• Leasing approach is the right way to go
• The sipping requirements document should focus on
  the small number of requirements for solving the
  GRUU problem
• I.e., they are not leasing requirements

18
Why leasing?

• Embedded route headers imply that the proxy
  doesnt know that this is a request to an AOR (a
  GRUU is an AOR)
• Proxies cant apply policy
• Proxies cant apply user services
• Can be done statelessly
• Side effect of register request
• Can provide privacy

19
Current Mechanism Thinking
INV sipaahu.userpart_at_example.com

• Client sends REGISTER request
• Response contains a GRUU Prefix in a header
• Client can append user-data to GRUU Prefix to
  build an AOR
• Proxy forwards requests for that AOR to the
  contact it is bound to
• User-data also passed to user

Registrar
200 OK GRUU aahu
REG Msipc1_at_1.2.3.4
Client
INV sipc1_at_1.2.3.4gruu-infouserpart
20
Open Issues

• Do we need to generally allow a UA to obtain an
  unlimited number of GRUU?
• Needed for conferencing, but other applications?
• Does the GRUU go into the Contact header of
  INV/200?
• Will be the end of direct signaling
• Syntax of the URIs