Internet DRAFT - draft-hilt-sipping-session-spec-policy

draft-hilt-sipping-session-spec-policy






SIPPING Working Group                                            V. Hilt
Internet-Draft                             Bell Labs/Lucent Technologies
Expires: January 13, 2006                                   G. Camarillo
                                                                Ericsson
                                                            J. Rosenberg
                                                           Cisco Systems
                                                           July 12, 2005


 A Delivery Mechanism for Session-Specific Session Initiation Protocol
                         (SIP) Session Policies
               draft-hilt-sipping-session-spec-policy-03

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on January 13, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This specification defines a delivery mechanism for session-specific
   Session Initiation Protocol (SIP) sessions policies.





Hilt, et al.            Expires January 13, 2006                [Page 1]

Internet-Draft          Session-Specific Policies              July 2005


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Overview of Operation  . . . . . . . . . . . . . . . . . . . .  7
     4.1   Offer in Request . . . . . . . . . . . . . . . . . . . . .  7
     4.2   Offer in Response  . . . . . . . . . . . . . . . . . . . .  9
   5.  UA/Policy Server Rendezvous  . . . . . . . . . . . . . . . . . 10
     5.1   UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 10
     5.2   UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 12
     5.3   Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 12
     5.4   Header Definition and Syntax . . . . . . . . . . . . . . . 13
   6.  Policy Channel . . . . . . . . . . . . . . . . . . . . . . . . 14
     6.1   Session Information  . . . . . . . . . . . . . . . . . . . 14
     6.2   Session Policies . . . . . . . . . . . . . . . . . . . . . 15
       6.2.1   Event Header Parameters  . . . . . . . . . . . . . . . 15
       6.2.2   The Use of URIs  . . . . . . . . . . . . . . . . . . . 16
       6.2.3   Subscriber Behavior  . . . . . . . . . . . . . . . . . 16
       6.2.4   Notifier Behavior  . . . . . . . . . . . . . . . . . . 16
       6.2.5   Example  . . . . . . . . . . . . . . . . . . . . . . . 16
   7.  Updating Policies  . . . . . . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18
   10.   References . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1  Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2  Informative References . . . . . . . . . . . . . . . . . . 18
   A.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
       Intellectual Property and Copyright Statements . . . . . . . . 20





















Hilt, et al.            Expires January 13, 2006                [Page 2]

Internet-Draft          Session-Specific Policies              July 2005


1.  Introduction

   Some domains have policies in place, which impact the sessions
   established using the Session Initiation Protocol (SIP) [4].  These
   policies are often needed to support the network infrastructure or
   the execution of services.  For example, wireless networks usually
   have limited resources for media traffic.  During periods of high
   activity, a wireless network provider wants to restrict the bandwidth
   that is available in a session.  With session policies, the user
   agent is able to learn about the current bandwidth limit and can make
   an informed decision about the number of streams, the media types,
   and the codecs it can use in that session.  Similarly, a user agent
   can be informed that certain codecs or media types are disallowed and
   may not be used in the current session.

   In another example, a SIP user agent is using a network which
   connects to the public Internet through a firewall or a network
   border device.  The provider would like to tell the user agent to
   direct the media streams to the appropriate IP addresses and ports of
   that firewall or border device.  Knowing this policy enables the user
   agent to setup sessions with other user agents across the firewall or
   the network border.

   In a third example, a domain wants to perform QoS marking and traffic
   shaping on media streams.  This functionality is implemented in a
   media intermediary.  With session policies, such a media intermediary
   can be inserted into the media path.  In contrast to other methods,
   the use of session policies does not require the inspection or
   modification of SIP message bodies by intermediaries (a discussion of
   this and other design aspects can be found in [8]).

   Domains sometimes enforce policies they have in place.  For example,
   a domain might have a configuration in which all packets containing a
   certain audio codec are dropped.  Unfortunately, enforcement
   mechanisms usually do not inform the user about the policies they are
   enforcing and silently keep the user from doing anything against
   them.  This may lead to the malfunctioning of devices that is
   incomprehensible to the user.  With session policies, the user knows
   about the restricted codecs and can use a different codec or simply
   connect to a domain with less stringent policies.  Session policies
   provide an important combination of consent coupled with enforcement.
   That is, the user becomes aware of the policy and needs to act on it,
   but the provider still retains the right to enforce the policy.

   Session-policies can be set up in two different ways: specifically
   for a session or independent of a session.  Session-specific policies
   are created for one particular session, usually under consideration
   of certain aspects of this session (e.g. the IP addresses and ports



Hilt, et al.            Expires January 13, 2006                [Page 3]

Internet-Draft          Session-Specific Policies              July 2005


   that are used for media).  Since session-specific policies are
   tailored to a session, they only apply to the session they are
   created for.  These policies require a delivery mechanism that
   enables the exchange of session policy information at the time a
   session is established.  This document defines such a delivery
   mechanism.  It enables user agents to submit session details to a
   policy server and allows the policy server to provide policies for
   this session in response.

   Session-independent policies on the other hand are independent of a
   specific session and generally apply to the sessions set up by a user
   agent.  An example is a policy which generally prohibits the use of
   high-bandwidth codecs.  In principle, these policies could also be
   delivered to user agents individually for each session, using the
   session-specific delivery mechanism.  However, since these policies
   apply to many sessions, it is more efficient to deliver them to user
   agents only when the user agent is initialized or a policy changes.
   The framework for session-independent policies [6] defines a delivery
   mechanism for session-independent policies.  It also defines a
   minimal session policy format aimed at achieving interoperability
   between different user agents and policy servers.  This policy format
   is independent of the policy delivery mechanism and can be used for
   session-independent as well as for session-specific policies.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14, RFC 2119 [1] and indicate requirement levels for
   compliant implementations.




















Hilt, et al.            Expires January 13, 2006                [Page 4]

Internet-Draft          Session-Specific Policies              July 2005


3.  Architecture

                        +-------------+
                 /------|    Proxy    |----...
      +----+    /       +-------------+
      |    |---/        +-------------+
      |    |            |   Policy    |
      | UA |============|   Server    |
      |    |            +-------------+
      |    |****        +-------------+
      +----+    *       |  Router w/  |
                 *******|   Policy    |****...
                        | Enforcement |
                        +-------------+

      --- SIP Signaling
      === Policy Channel
      *** Media

                                 Figure 1

   The following entities are involved in setting up session-specific
   policies (see Figure 1): a user agent (UA), a proxy, a policy server
   and possibly a router with policy enforcement functionality.

   The proxy's role is to provide a rendezvous mechanism for UA and
   policy server.  It conveys the URI of the policy server in its domain
   to UAs and ensures that UAs know where to retrieve policies from.  It
   does not deliver the actual policies to UAs.

   The policy server is a separate logical entity that may be physically
   co-located with the proxy.  Each domain has at most one policy
   server.  The role of the policy server is to generate session
   policies for a session.  It receives session information from a UA,
   generates a policy and returns that policy back to the UA.  The way
   policies are generated is outside the scope of this specification.  A
   policy server could, for example, use local rules, query external
   sources for additional information or retrieve policies from a
   separate policy infrastructure.

   A UA receives the URI of a policy server from the proxy.  It uses
   this URI to establish a policy channel to the policy server.  It
   provides information about the current session to the policy server
   and receives session policies in response.  The UA may also receive
   policy updates from the policy server during the course of a session.

   A network may have a policy enforcement infrastructure in place.
   However, this specification does not make any assumptions about the



Hilt, et al.            Expires January 13, 2006                [Page 5]

Internet-Draft          Session-Specific Policies              July 2005


   enforcement of session policies and the mechanisms defined here are
   orthogonal a policy enforcement infrastructure.  Their goal is to
   provide a means for the UA to convey session information to a policy
   server and to receive the policies that apply to this session in
   response.

   The protocol defined in this specification follows a separate channel
   model.  SIP signaling is only used to rendezvous the UA with the
   policy server.  From this point on, UA and policy server communicate
   directly with each other over a separate policy channel.  This is
   opposed to a piggyback model, where the exchange of session and
   policy information between the user agent and the policy server is
   piggybacked onto SIP signaling messages exchanged between the two
   user agents.

   A disadvantage of the separate channel model is that it requires
   additional messages for the exchange of policy information.  The
   advantages of using a separate policy channel is that it decouples
   the exchange of signaling messages between endpoints from the
   exchange of policy information between endpoint and policy server.
   This decoupling enables the use of encryption on the signaling path
   (to secure the communication between endpoints) and on the policy
   channel (to secure the communication between endpoint and policy
   server).  Existing schemes for authorization, authentication, signing
   and encryption can be used on the policy channel.  This is not
   possible if policies are piggybacked onto the signaling messages.
   Another advantage of the separate channel model is that policies do
   not travel along the signaling path possibly crossing may domains.
   If policy server and UA are in the same network, policy information
   never leaves this network.  In addition, endpoints can specifically
   decide which aspects of a session they want to disclose to a certain
   policy server.  Finally, a policy server does not rely on a SIP
   signaling message flowing by to provide a session policy to an
   endpoint.  A policy server can use the separate channel at any time
   to update session policies as needed.

   The communication on the policy channel between a UA and a policy
   server involves two main operations:

   1.  The UA discloses information about the current session and the
       offer/answer exchange to the policy server.
   2.  The policy server sends policy instructions to the UA.

   Some types of policies do not involve sending policy instructions,
   but only information disclosure.  Still, a general session-specific
   policy mechanism needs to support both operations.

   The same way, some policy servers only need to inspect the offer, but



Hilt, et al.            Expires January 13, 2006                [Page 6]

Internet-Draft          Session-Specific Policies              July 2005


   not the answer.  Nevertheless, a general mechanism needs to consider
   policy servers which need to inspect both.

   Finally, some policy servers need to update the session policies that
   have been sent to a UA.  Again, a general mechanism should provide
   this capability.

4.  Overview of Operation

   This section provides example call flows to illustrate the
   establishment of session-specific policies.  It does not contain a
   normative protocol definition.

   In the following scenario, there are two domains (domain A and domain
   B), which both have session-specific policies for UAs in their
   domain.  Both domains do not provide policies to UAs outside of their
   domain.  The two domains have a proxy (P A and P B) and a policy
   server (PS A and PS B).  The policies in both domains involve the
   session description offer and answer.

4.1  Offer in Request

   The first call flow depicts an INVITE transaction with the offer in
   the request.  It is assumed that the UAC does not have previous
   knowledge about the policy server in its domain.

   (1) UA A sends an INVITE to proxy P A. P A knows that policies apply
   to this session and (2) returns a 488 to UA A. P A includes the URI
   of PS A in the 488 response. (3) UA A contacts PS A, discloses the
   session description offer to PS A and (4) receives policies for the
   offer. (5) UA A reformulates the INVITE request under consideration
   of the received policies and includes a Policy-Id header to indicate
   that it has already contacted PS A. P A does not reject the INVITE
   this time and removes the Policy-Id header when forwarding the
   INVITE.  P B adds a Policy-Contact header containing the URI of PS B.
   (6) UA B uses this URI to contact PS B and discloses the offer and
   the answer it is about to send. (7) UA B receives policies from PS B
   and applies them to the offer and answer respectively. (8) UA B
   returns the updated answer in the 200 OK. (9) UA A contacts PS A with
   the answer and (10) retrieves answer policies from PS A.











Hilt, et al.            Expires January 13, 2006                [Page 7]

Internet-Draft          Session-Specific Policies              July 2005


    UA A              P A              P B             UA B
     |                 |                |                 |
     | INVITE offer    |                |                 |
     |---------------->|                |                 | (1)
     | 488             |                |                 |
     | + Policy-Contact|                |                 |
     |<----------------|                |                 | (2)
     | ACK             |                |                 |
     |---------------->|                |                 |
     |                 | PS A           |                 |
     |                    |             |                 |
     | PolicyChannel      |             |                 |
     | + InfoOffer        |             |                 |
     |------------------->|             |                 | (3)
     | PolicyChannel      |             |                 |
     | + PolicyOffer      |             |                 |
     |<-------------------|             |                 | (4)
     |                    |             |                 |
     |                 |                |                 |
     | INVITE offer'   | INVITE offer'  | INVITE offer    |
     | + Policy-Id     |                | + Policy-Contact|
     |---------------->|--------------->|---------------->| (5)
     |                 |                |                 |
     |                 |           PS B |                 |
     |                 |             |                    |
     |                 |             | PolicyChannel      |
     |                 |             | + InfoOffer        |
     |                 |             | + InfoAnswer       |
     |                 |             |<-------------------| (6)
     |                 |             | PolicyChannel      |
     |                 |             | + PolicyOffer      |
     |                 |             | + PolicyAnswer     |
     |                 |             |------------------->| (7)
     |                 |             |                    |
     |                 |                |                 |
     | OK answer       | OK answer      | OK answer       |
     |<----------------|<---------------|<----------------| (8)
     | ACK                                                |
     |--------------------------------------------------->|
     |                 |                |                 |
     |                    |             |                 |
     | PolicyChannel      |             |                 |
     | + InfoAnswer       |             |                 |
     |------------------->|             |                 | (9)
     | PolicyChannel      |             |                 |
     | + PolicyAnswer     |             |                 |
     |<-------------------|             |                 | (10)
     |                    |             |                 |



Hilt, et al.            Expires January 13, 2006                [Page 8]

Internet-Draft          Session-Specific Policies              July 2005


                                 Figure 2


4.2  Offer in Response

   This call flow depicts an INVITE transaction with the offer in the
   response.

   Steps (1) - (8) are analogous to steps (1) - (8) in the above flow.
   An important difference is that in steps (9) and (10) UA A contacts
   PS A after receiving the offer in the 200 OK but before returning the
   answer in step (11).  This enables UA A to return the final answer,
   which includes all applicable policies, in the ACK.  However, it
   requires that PS A immediately returns a policy to avoid a delay in
   the transmission of the ACK.  This is similar to Flow I in [7].

    UA A              P A              P B             UA B
     |                 |                |                 |
     | INVITE          |                |                 |
     |---------------->|                |                 | (1)
     | 488             |                |                 |
     | + Policy-Contact|                |                 |
     |<----------------|                |                 | (2)
     | ACK             |                |                 |
     |---------------->|                |                 |
     |                 | PS A           |                 |
     |                    |             |                 |
     | PolicyChannel      |             |                 |
     |------------------->|             |                 | (3)
     | PolicyChannel      |             |                 |
     |<-------------------|             |                 | (4)
     |                    |             |                 |
     |                 |                |                 |
     | INVITE          | INVITE         | INVITE          |
     | + Policy-Id     |                | + Policy-Contact|
     |---------------->|--------------->|---------------->| (5)
     |                 |                |                 |
     |                 |           PS B |                 |
     |                 |             |                    |
     |                 |             | PolicyChannel      |
     |                 |             | + InfoOffer        |
     |                 |             |<-------------------| (6)
     |                 |             | PolicyChannel      |
     |                 |             | + PolicyOffer      |
     |                 |             |------------------->| (7)
     |                 |             |                    |
     |                 |                |                 |
     | OK offer        | OK offer       | OK offer        |



Hilt, et al.            Expires January 13, 2006                [Page 9]

Internet-Draft          Session-Specific Policies              July 2005


     |<----------------|<---------------|<----------------| (8)
     |                 |                |                 |
     |                    |             |                 |
     | PolicyChannel      |             |                 |
     | + InfoOffer        |             |                 |
     | + InfoAnswer       |             |                 |
     |------------------->|             |                 | (9)
     | PolicyChannel      |             |                 |
     | + PolicyOffer      |             |                 |
     | + PolicyAnswer     |             |                 |
     |<-------------------|             |                 | (10)
     |                    |             |                 |
     | ACK answer                                         |
     |--------------------------------------------------->| (11)
     |                 |                |                 |
     |                 |             |                    |
     |                 |             | PolicyChannel      |
     |                 |             | + InfoAnswer       |
     |                 |             |<-------------------| (12)
     |                 |             | PolicyChannel      |
     |                 |             | + PolicyAnswer     |
     |                 |             |------------------->| (13)
     |                 |             |                    |

                                 Figure 3


5.  UA/Policy Server Rendezvous

   The first step in setting up session-specific policies is to
   rendezvous the UAs with the relevant policy servers.  This is
   achieved by providing the URIs of all policy servers relevant for a
   session to the UAs.

5.1  UAC Behavior

   When a UA compliant to this specification generates an INVITE or
   UPDATE request, it MUST include a Supported header field with the
   option tag "policy" in the request.

   A UAC may receive a 488 in response to an INVITE or UPDATE request,
   which contains a Policy-Contact header field.  This is a new header
   that contains the URI of a policy server.  A 488 response with this
   header is generated by a proxy to convey the URI of the local policy
   server to the UAC.  The UAC SHOULD contact this URI to retrieve the
   session policies that apply to the current request.  If the UAC
   decides to accept the received policies, it SHOULD apply them to the
   request and resend the updated request.



Hilt, et al.            Expires January 13, 2006               [Page 10]

Internet-Draft          Session-Specific Policies              July 2005


   If the UAC has applied session policies to a request, it MUST insert
   a Policy-Id header into that request.  The Policy-Id header MUST
   include the URIs of all policy servers the UAC has contacted during
   the processing of that request.  The Policy-Id header enables a proxy
   to determine whether the URI of its policy server is already known to
   the UAC (and thus the request can be passed through) or whether the
   URI still needs to be conveyed to the UAC in a 488 response.

   In some cases, a request may traverse multiple domains with session-
   policies in place.  Each of these domains may return a 488 response
   containing a policy server URI.  Since the UAC contacts the policy
   server URI received in a 488 response before it resends the request,
   session policies are always applied to a session in the order in
   which the request traverses through these domains.  Policies of the
   local network are applied first (since the local proxy is the first
   proxy that responds with a 488 response), policies of the first
   policy-enabled transit network are applied next, and so on.  The
   order in which policies are applied to a session may be significant,
   for example, if a policy inserts media intermediaries into the media
   path.

   Session policies may apply to the offer, the answer or both session
   descriptions.  Depending on the requirements of the policy, a UAC may
   need to contact the policy server with the offer and with the answer.
   A UAC MUST always contact the same policy servers for the offer and
   the answer.  If the UAC receives an answer in the response to an
   INVITE request (i.e. the request contained the offer), it MUST send
   the ACK before retrieving the policies for the answer from the policy
   server.  If the UAC receives a response with an offer (i.e. the
   INVITE request did not contain an offer), the UAC MUST first contact
   the policy server to retrieve session policies and apply these
   policies before sending the answer in the ACK.  The answer in the ACK
   will therefore already consider the relevant policies.

      This approach assumes that the policy server immediately responds
      to a policy request and does not require manual intervention to
      create a policy.  A delay in the response from the policy server
      would delay the transmission of the ACK and could trigger
      retransmissions of the INVITE response (also see the
      recommendations for Flow I in [7]).

   A UAC SHOULD cache the URI of the local policy server.  It receives
   this URI in a 488 from the proxy in the local domain.  The UAC SHOULD
   use this URI to retrieve session policies for a new INVITE or UPDATE
   request before it is sent.  Caching the local policy server URI
   avoids the retransmission of this URI for each new INVITE or UPDATE
   request.  Some domains may want to prevent the UAC from caching the
   local policy server URI.  For example, if the policy server does not



Hilt, et al.            Expires January 13, 2006               [Page 11]

Internet-Draft          Session-Specific Policies              July 2005


   need to be involved in all sessions or the policy server URI changes
   from session to session.  A proxy can mark the URI of such a policy
   server as "non-cacheable".  The UA SHOULD NOT cache a non-cacheable
   policy server URI and SHOULD remove the current URI from its cache
   when receiving such a URI.

   The UAC SHOULD NOT cache policy server URIs it has received from
   proxies outside of the local domain.  These policy servers may not be
   relevant for subsequent sessions, which may go to a different
   destination and may traverse different domains.

   The UAC SHOULD maintain a list of policy server URIs for each dialog.
   This list SHOULD include all policy server URIs that were contacted
   for the initial INVITE that created the dialog.  The UAC should keep
   this list until the dialog is terminated.  The UAC SHOULD contact the
   policy server URIs in this list before sending an INVITE or UPDATE
   request within that dialog.  This avoids the retransmission of policy
   server URIs for mid-dialog requests.  Contacting policy servers for
   mid-dialog INVITE or UPDATE requests is needed to enable policy
   servers to keep track of the session description and to update
   policies accordingly.

5.2  UAS Behavior

   An incoming INVITE or UPDATE request may contain a Policy-Contact
   header with a list of policy server URIs.  The UAS SHOULD use these
   URIs to retrieve session policies.  The UAS MUST use the policy
   server URIs in the order in which they were contained in the Policy-
   Contact header, starting with the topmost value.

   If the UAS receives an ACK with an answer, it may need to contact the
   policy servers again depending on the policy.  In this case, it MUST
   contact the same policy servers it has contacted for the offer.

5.3  Proxy Behavior

   A proxy may provide the URI of the local policy server to the UAC or
   the UAS when processing an INVITE or UPDATE request.

   If an INVITE or UPDATE request contains a Supported header field with
   the option tag "policy", the proxy MAY reject the request with a 488
   response to provide the local policy server URI to the UAC.  Before
   rejecting a request, the proxy MUST check whether the request has a
   Policy-Id header field that already contains this policy server URI.
   If the request does not have such a header or the local policy server
   URI is not present in that header, then the proxy MAY reject the
   request with a 488.  The proxy MUST insert a Policy-Contact header in
   the 488 response that contains the URI of the local policy server.



Hilt, et al.            Expires January 13, 2006               [Page 12]

Internet-Draft          Session-Specific Policies              July 2005


   The proxy MAY add the header field parameter "non-cacheable" to
   prevent the UAC from caching this policy server URI.

   If the local policy server URI is already present in the Policy-Id
   header of an INVITE or UPDATE request, the proxy MUST NOT reject the
   request as described above.  The proxy SHOULD remove this policy
   server URI from the Policy-Id header field before forwarding the
   request.

   The proxy MAY insert a Policy-Contact header field into an INVITE or
   UPDATE request in order to convey the policy server URI to the UAS.
   If the request already contains a Policy-Contact header field, the
   proxy MUST insert the URI before of all existing values at the
   beginning of the list.  A proxy MUST NOT change the order of existing
   Policy-Contact header values.

5.4  Header Definition and Syntax

   The Policy-Id header field is inserted into an INVITE or UPDATE
   request by the UAC.  It identifies all policy servers the UAC has
   contacted for the request.  A Policy-Id header value is the URI of a
   policy server.

   The syntax of the Policy-Id header field is:

     Policy-Id        = "Policy-Id" HCOLON absoluteURI
                        *(COMMA absoluteURI)

   The Policy-Contact header field can be inserted into INVITE and
   UPDATE requests by a proxy.  It contains an ordered list of policy
   server URIs that need to be contacted by the UAS.  The UAS starts to
   process the header field at the topmost value of this list.  New
   header field values are inserted at the top.  The Policy-Contact
   header field effectively forms a stack.  The "non-cacheable" header
   field parameter MUST NOT be used in a request.

   The Policy-Contact header field can also be inserted into a 488
   response to an INVITE or UPDATE request by a proxy.  It contains a
   policy server URI that needs to be contacted by the UAC.  A proxy MAY
   add the "non-cacheable" header field parameter to indicate that the
   UAC should not cache the policy server URI.

   The syntax of the Policy-Contact header field is:

     Policy-Contact   = "Policy-Contact" HCOLON policyURI
                        *(COMMA policyURI)
     policyURI        = absoluteURI [ SEMI "non-cacheable" ]




Hilt, et al.            Expires January 13, 2006               [Page 13]

Internet-Draft          Session-Specific Policies              July 2005


   The BNF for absoluteURI is defined in [4].

   Table 1 is an extension of Tables 2 and 3 in [4].  The column 'UPD'
   is for the UPDATE method [3].

     Header field          where   proxy ACK BYE CAN INV OPT REG UPD
     _______________________________________________________________
     Policy-Id               R       rd   -   -   -   o   -   -   o
     Policy-Contact          R       a    -   -   -   o   -   -   o
     Policy-Contact         488      a    -   -   -   o   -   -   o
           Table 1: Policy-Id and Policy-Contact Header Fields

                                 Figure 6


6.  Policy Channel

   The policy channel is set up between the UA and the policy server.
   This channel is needed to accomplish two tasks: first, to convey
   information about the current session from the UA to the policy
   server and, second, to return the policies for that session from the
   policy server back to the UA.

6.1  Session Information

   OPEN ISSUE: Which method should be used to convey session information
   from the UA to the policy server?  Use cases for session-specific
   policies that may help resolving this issue are discussed in [6].
   The following proposals have been made:

   1.  SIP SUBSCRIBE: session information is conveyed to the policy
       server in the body of SUBSCRIBE requests.  The UA subscribes to
       session policies for each session.  Semantically, session
       information is a filter criteria that selects the policies, which
       apply to the current session from the pool of all available
       policies.  This semantics may not be applicable to all policies,
       in particular, if they are generated dynamically based on session
       information.  Also, session information can only be provided by
       the subscriber and not by a third party.
   2.  SIP PUBLISH: the UA submits session information to the policy
       server in the body of a SIP PUBLISH request.  The policy server
       uses this information to generate policies and makes these
       policies available for subscriptions.  The UA can subscribe to
       these policies and will receive all policies (new or updated) via
       NOTIFY requests.  The subscription can be established at the same
       time the PUBLISH request is sent.  The UA may even use a single
       subscription to receive the policies for all sessions it sets up.
       In this case, each NOTIFY would cover all policies from that



Hilt, et al.            Expires January 13, 2006               [Page 14]

Internet-Draft          Session-Specific Policies              July 2005


       server (content indirection may be used).
   3.  HTTP: Similar to PUBLISH.  Instead of using a PUBLISH request,
       the UA submits session information in the body of a HTTP request.
       The policies are received through a subscription.  The UA needs
       two policy server URIs: a SIP URI (for the subscription) and a
       HTTP URI (to upload session information).
   4.  XCAP: Similar to HTTP.  Instead of using plain HTTP, XCAP is used
       to upload session information.

   OPEN ISSUE: Which information should be disclosed to the policy
   server.  Is this policy specific?  Or should the UA generally
   disclose the session description?

6.2  Session Policies

   The UA accesses the policies that apply to the current session
   through the policy server URIs it has received during session
   establishment (see Section 5).  The UA subscribes to these URIs and
   receives the current session policies.  The policies for a session
   may change while the session is in progress.  The UA is notified
   about updates to policies through the subscription.

   The session policy documents may be contained directly in the body of
   a NOTIFY message or they may be retrieved from an URI contained in
   the NOTIFY via content indirection.

   The subscription to session-specific policies is based on the
   Framework for SIP User Agent Profile Delivery [2].  It uses the new
   profile-type 'policy', which is defined in this document.  Defining a
   new profile type for session-policies enables the decoupling of
   session-specific policies from other sources of profile information,
   such as user, device, or local profiles.  'Policy' profiles are
   provided by domains that have session-specific policies in place.

6.2.1  Event Header Parameters

   The new token 'policy' is defined for the 'profile-type' event header
   parameter.  This extends the syntax of the profile-type event header
   parameter [2] as follows:

      profile-types      =  "device" / "user" / "application" /
                            "local" / "policy"

   A SUBSCRIBE request for the policy profile-type may contain the
   'network-user' parameter with the user's AoR.  This parameter may be
   needed since the subscription URI does not reveal the user's AOR.
   Knowing the user's AOR may help a policy server to decide whether or
   not to accept a subscription and to determine which policies are



Hilt, et al.            Expires January 13, 2006               [Page 15]

Internet-Draft          Session-Specific Policies              July 2005


   applicable.

6.2.2  The Use of URIs

   The SUBSCRIBE request URI for the 'policy' profile is a policy server
   URI the user agent has received through mechanisms described in
   Section 5.

   A policy server URI MAY contain a 'document' URI parameter when it is
   received by the UA.  This parameters can be used to identify a
   specific document on the policy server, to which the UA should
   subscribe.  If this parameter is present in a policy server URI, it
   MUST be copied into the 'document' event header parameter of the
   SUBSCRIBE request.  The 'document' parameter MUST be removed from the
   policy server URI before it is used in the SUBSCRIBE request URI.

6.2.3  Subscriber Behavior

   The 'policy' profile SHOULD be used when subscribing to a policy
   server URI.  The UA SHOULD establish a separate subscription to each
   policy server URI it has received.  It may receive session-specific
   policies through each of these subscriptions.  The subscriber SHOULD
   include the 'network-user' parameter in the SUBSCRIBE request.

6.2.4  Notifier Behavior

   A notifier (i.e. a policy server) MUST immediately respond to
   SUBSCRIBE requests and MUST immediately send a NOTIFY in case it
   accepts the subscription.  If the notifier cannot respond with a
   session policy right away, it must send an empty policy document and
   later update this policy.  Note that updating a policy may require
   the subscriber to re-negotiate session parameters and should be
   avoided if possible.

      The timely transmission of session policies is in particular
      important if the UA (i.e. the subscriber) is requesting policies
      for an offer in an INVITE response (see Section 4.2).

   The policy server SHOULD authenticate the user before submitting a
   policy that grants additional privileges to the user.

6.2.5  Example

   The following example contains a policy server URI and a SUBSCRIBE
   message.






Hilt, et al.            Expires January 13, 2006               [Page 16]

Internet-Draft          Session-Specific Policies              July 2005


   Policy Server URI:
     sip:policy@ps.example.com;document=session-id/48ei48rj474k


   SUBSCRIBE sip:policy@ps.example.com SIP/2.0
   Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bK6d6d35b6
   Event: sip-profile;profile-type="policy";
     document="session-id/48ei48rj474k";
     vendor="vendor.example.com";model="Z100";version="1.2.3";
     network-user="alice@example.com"
   To: sip:policy@ps.example.com
   From: sip:alice@example.com;tag=1234
   Call-ID: ue8K743jRhr83@terminal.example.com
   CSeq: 1 SUBSCRIBE
   Contact: <sip:alice@terminal.example.com>
   Accept: message/external-body, application/session-policy+xml
   Content-Length: 0


7.  Updating Policies

   A UA may receive policy updates through a policy channel.  The UA
   SHOULD apply these policies to the current session.  It MUST generate
   a re-INVITE or UPDATE request if the updated policies modify aspects
   of the session that need to be communicated to the peer UA.

8.  Security Considerations

   In particular authentication and authorization are critical issues
   that need to be addressed here.

   [TBD.]

9.  IANA Considerations

   [TBD.]

10.  References

10.1  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Petrie, D., "A Framework for Session Initiation Protocol User
        Agent Profile Delivery", draft-ietf-sipping-config-framework-06
        (work in progress), February 2005.




Hilt, et al.            Expires January 13, 2006               [Page 17]

Internet-Draft          Session-Specific Policies              July 2005


   [3]  Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
        Method", RFC 3311, October 2002.

   [4]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

10.2  Informative References

   [5]  Hilt, V. and G. Camarillo, "Use Cases for Session-Specific
        Session Initiation Protocol (SIP) Session Policies",
        draft-hilt-sipping-policy-usecases-00 (work in progress),
        June 2005.

   [6]  Hilt, V., Camarillo, G., and J. Rosenberg, "Session Initiation
        Protocol (SIP) Session Policies - Document Format and Session-
        Independent Delivery Mechanism",
        draft-ietf-sipping-session-indep-policy-03 (work in progress),
        June 2005.

   [7]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
        "Best Current Practices for Third Party Call Control (3pcc) in
        the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
        April 2004.

   [8]  Rosenberg, J., "Requirements for Session Policy for the Session
        Initiation Protocol (SIP)",
        draft-ietf-sipping-session-policy-req-02 (work in progress),
        July 2004.


Authors' Addresses

   Volker Hilt
   Bell Labs/Lucent Technologies
   101 Crawfords Corner Rd
   Holmdel, NJ  07733
   USA

   Email: volkerh@bell-labs.com











Hilt, et al.            Expires January 13, 2006               [Page 18]

Internet-Draft          Session-Specific Policies              July 2005


   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: Gonzalo.Camarillo@ericsson.com


   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   USA

   Email: jdrosen@cisco.com

Appendix A.  Acknowledgements

   Many thanks to Allison Mankin for the discussions and the suggestions
   for this draft.  A big thanks also to everyone who contributed by
   providing feedback on the mailing list and in IETF meetings.





























Hilt, et al.            Expires January 13, 2006               [Page 19]

Internet-Draft          Session-Specific Policies              July 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Hilt, et al.            Expires January 13, 2006               [Page 20]