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

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.

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

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?

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

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?