60 likes | 165 Views
SIP Session Policies. Volker Hilt volkerh@bell-labs.com. History. Problem statement 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
E N D
SIP Session Policies Volker Hilt volkerh@bell-labs.com
History • Problem statement • 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) Access Network Policy Server Home Domain Policy Server • 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”. SUBSCRIBE SUBSCRIBE NOTIFY NOTIFY GET Policy 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?