1. Volker Hilt volkerh@bell-labs.com
SIP Session Policies
Volker Hilt

2. History Problem statement History
Enable the network to request the use of session policies from UAs.
History
draft-rosenberg-sipping-session-policy-00
draft-hilt-sipping-session-policy-00
draft-camarillo-sipping-policy-package-00
Session-Specific Intermediary Session Policies
draft-hilt-sipping-session-spec-policy-00
Created during a specific session.
Affect the current session.
Session-Independent Intermediary Session Policies
draft-hilt-sipping-session-indep-policy-00
Created outside of a session.
Affect selected sessions during a period of time.

3. Session-Independent Policies (1)
Overview
UAs subscribes to policies.
Policy documents conveyed
through content indirection.
Defines a framework.
Open issues
Policy server discovery
Assumption: Session policies will most likely be provided by the access network domain and the home domain.
Policy server discovery would simplify deployment.
Issue: Current procedures overload user name “sessionpolicies”.
Access Network
Policy Server
Home Domain
Policy Server
SUBSCRIBE
NOTIFY
SUBSCRIBE
GET Policy
NOTIFY
GET Policy

4. Session-Independent Policies (2)
Open issues (cont.)
Policy documents
XCAP event package and XCAP-based documents.
Use the existing XCAP framework to deliver policies.
Define the general properties of policy documents.
But: XCAP event package assumes that the UAs know the path to the relevant documents.
XCAP-based policy documents.
Limits the number of protocols and document formats used in policy packages.
But: simple UAs may prefer plain HTTP and text documents.
Allow any policy document format.
How to proceed?

5. Session-Dependent Policies (1)
Overview
Policies are requested using MIO/MFO headers individually for each session during an offer/answer exchange.
Defines a framework.
Open issues
Preconditions
UAC may reject policies and terminate the session, which may cause “ghost rings” on the UAS side.
Use of precondition could prevent “ghost rings”.
Subsequent offer/answer exchanges
How to handle policies in subsequent offer/answer exchanges?
INVITE(offer) + MIO-1
INVITE(offer) + MIO-1 + MFO-1
MFO-1
MFO-1
MFO-2
OK(answer) + MIO-2 + MFO-1 + MFO-2
OK(answer) + MIO-2 + MFO-1
ACK + MFO-2
ACK + MFO-2
MFO-2

6. Session-Dependent Policies (2)
Open issues (cont.)
Two party consent vs. one party consent.
The current requirements are based on a two party consent model:
Both UAs need to know all policies (REQ-CON-1 and REQ-CON-2)
Proxies need to know the accepted policies (REQ-CON-5 and REQ-CON-6).
Two party consent requires a three pass policy exchange.
But: the third pass does not exist in “empty” INVITE and UPDATE flows.
Approach 1: Two party consent
Send policy information in a separate message (SUBSCRIBE/NOTIFY, INFO,...).
Approach 2: One party consent (as discussed for OPES in RFC3238)
Only one UA needs to know about and agree to a policies.
Since each UA can set up a session policy locally, one party consent does not change the current model.
Works with the two-way offer answer model.
How to proceed?