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

Status Session-independent policy delivery mechanism Minor editorial changes. Policy document format Major revision to simplify format New section about policy format design Basic Session Policy Format (BSPF) Minimal policy format. Covers aspects defined in requirements draft only. Can be extended to cover other aspects as needed.

BSPF: Design Policy Structure Merging policies Policies are defined as XML elements. Flat structure (i.e. no “combined” policies). "policy" attribute Mandatory, allowed, denied Optional "direction" attribute (defined per-element). Optional "label" attribute (defined per-element). Merging policies Merging rules are defined individually for each policy element.

Open Issue #1: BSPF Elements Included elements Media types Codecs Media intermediary QoS Max bandwidth Proposed media elements Max no of streams Max no of sessions Max no of streams per session Max bandwidth per session Max bandwidth per stream External address and port Media transport protocol Proposed protocol elements Outbound proxy SIP methods SIP option tags SIP transport protocol Body format/disposition Body encryption

Open Issue #2: Policy Conflicts Merging policies may result in conflicts. Example: Policy 1: only G.711 / Policy 2: only G.729 If policies are enforced in the network, setting up a call might not be possible. Can this be prevented or resolved? Define a default value for a baseline call that must be allowed (e.g. G.711)?

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

Status Minor editorial changes. Mechanism to hand out policy server URI in INVITE transaction. Minor changes. Removed use of tokens in Policy-Id header. Removed interaction with policy server on BYE. Policy Channel Protocol Open issue.

Open Issue: Policy Channel Protocol (1) #1: SIP SUBSCRIBE/NOTIFY UA subscribes to session policies using provided URI. UA submits session description in SUBSCRIBE body. Policies are returned in NOTIFY messages. Asynchronous policy updates via NOTIFY messages. Use (possibly long-lived) TLS connection to proxy or policy server. #2: SIP SUBSCRIBE/NOTIFY + PUBLISH Same as #1. UA submits session description in PUBLISH.

Open Issue: Policy Channel Protocol (2) #3: HTTP UA retrieves policies using provided URI. No asynchronous policy updates. #4: COPS UA has the role of a COPS Policy Enforcement Point (PEP), policy server has role of Policy Decision Point (PDP). UA submits policy requests to the policy server. Policies can be updated at any time by the policy server. #5: BEEP UA establishes a BEEP channel to the policy server. The UA sends the session description to the policy server and receives policies through this channel.

Other Issues Allow the use of alternative policy channel protocols? Example: HTTP if asynchronous updates are not needed. Proxy provides multiple URIs to UA. Which information does the UA submit to the policy server? Session description Policy-specific data