SIPPING IETF 57

Jonathan Rosenberg

dynamicsoft

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

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

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

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: don’t 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

Technical Open Issues

• Determining “address most likely to work” for population into m and c lines – need an algorithm– Won’t 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

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

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?

Session Policy

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

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

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

URI Leasing

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

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

Progress

• An informal group met @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

Why leasing?

• Embedded route headers imply that the proxy doesn’t know that this is a request to an AOR (a GRUU is an AOR)– Proxies can’t apply policy– Proxies can’t apply user services

• Can be done statelessly– Side effect of register request

• Can provide privacy

Current Mechanism Thinking

• 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

Client

REGM:sip:c1@1.2.3.4

200 OKGRUU: aahu

INV sip:aahu.userpart@example.com

INV sip:c1@1.2.3.4;gruu-info=userpart

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