1. Session-Independent Policies draft-ietf-sipping-session-indep-policy-01 Volker Hilt volkerh@bell-labs.com Gonzalo Camarillo Gonzalo.Camarillo@ericsson.com Jonathan Rosenberg jdrosen@dynamicsoft.com

2. Session-Independent Policies Major revision since –00. Session-independent policy delivery mechanism. –Based on the config-framework. –UAs subscribe to policy servers using the following profiles. user profile: retrieve policies of the users AoR domain. local profile: retrieve policies of the access network. –Rules when to sent a subscribe.

3. Generic policy schema defines common elements and attributes. XML schemas for specific policies. –Media policies –Protocol policies –Media routing policies Policy Schema

4. Specifying constraints in policy schemas. –Simple restrictions. Example: maximum bandwidth (mandatory). –UA needs to select multiple values. Multiple instances can be present in a session. Example: audio (mandatory), video (allowed), application (denied). –UA needs to select a single value. One instance needs to be selected for a session. Example: codec: PCMU (allowed), PCMA (allowed), G729 (denied). Constraints –Mandatory, allowed, denied. Policy Schema Structure

5. Container-based approach: –Containers define the constraining properties of a policy elements. –Policy elements modify the working profile (settings used by a UA). element values must be removed. element values must be added. one of the values must be added. element values may be added. Characteristic/Issues –Well aligned with the data set framework. –Based on concept of working profile. –Flexible and complex. XML Containers PCMU 4 audio video

6. Attribute-based approach: –"Policy" attribute defines constraining properties of elements. "Mandatory" - must be used in sessions. "Allow" - may be used in sessions. "Deny" - can not be used in sessions. –Policy schemas specify the use of this attribute for elements. –Default policies for an element require a separate element. Example: defines policy for codecs not listed. Characteristic –Session-based. –Required semantics. –Simple. XML Attributes 4 audio video PCMU

7. Session policies from different sources may be in conflict. General conflict resolution mechanisms are very complex. –Out of scope for this draft!! Proposal: –Specific rules for merging policies in a policy schema. –Default behavior for conflict’s that can’t be resolved (e.g. “alert user”). –Special treatment for emergency calls? Conflict Resolution

8. Session-Specific Policies draft-hilt-sipping-session-spec-policy-01 Volker Hilt volkerh@bell-labs.com Gonzalo Camarillo Gonzalo.Camarillo@ericsson.com Jonathan Rosenberg jdrosen@dynamicsoft.com

9. Major revision since –00. Mechanism based on the separate channel model. Architecture –Proxy: provides the URI of the local policy server to UA. –Policy server: receives session information from UA and returns session policies. –Policy enforcement point: may be present to enforce policies. Out of scope for this draft. Session-Specific Policies Proxy UA A Policy Server PS A Router w/ Policy Enforcmnt Proxy Policy Server PS B Router w/ Policy Enforcmnt UA B 24 1 PS A 3 PS B

10. Distributing PS URIs Two new header fields –Policy-contact header Convey the policy server URI from proxy to UAs. –Policy-Id header Used by UAC to identify the policy servers used.

11. Contacting the Policy Server When / with which information does a UA contact the PS? –Offer: generally needed for session-specific policies. –Answer: needed if policies apply to answer-specific information (e.g., IP address and port). –BYE: needed by PS to free resources (e.g. close firewall pinholes, terminate asynchronous policy updates). Proposal: PS provides indication on policy channel. –Offer cycle is mandatory. –Flag for “answer required” in offer cycle. –PS closes policy channel when done.

12. Policy Channel Proposal: SUBSCRIBE/NOTIFY-based mechanism. –Same mechanism as session-independent policies. –Use of SIP authentication and authorization mechanisms. –Allows asynchronous policy updates. –Content indirection for policy delivery. –Subscription terminated when session ends or policy server has no policy updates. Issue –Offers and answers need to be carried in SUBSCRIBE bodies.

13. Policy Channel - Flow SUBSCRIBE PS NOTIFY answer="yes" SUBSCRIBE PS NOTIFY NOTIFY SUBSCRIBE PS Expires=0 UA PS 1.UA subscribes to policies at PS. –Offer in SUBSCRIBE body. 2.UA refreshes subscription. –Offer and answer in SUBSCRIBE body. –Alternative: separate subscription for answer. 3.PS notifies UA about policy updates. 4.UA terminates subscription when session ends. NOTIFY