SIPPING Working Group V. Hilt Internet-Draft Bell Labs/Lucent Technologies Expires: April 19, 2006 G. Camarillo Ericsson J. Rosenberg Cisco Systems October 16, 2005 A Framework for Session Initiation Protocol (SIP) Session Policies draft-hilt-sipping-session-policy-framework-00 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 April 19, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Proxy servers play a central role as an intermediary in the Session Initiation Protocol (SIP) as they define and impact policies on call routing, rendezvous, and other call features. However, there is currently no standard mechanism by which a proxy can influence session policies, such as the codecs or media types to be used. This Hilt, et al. Expires April 19, 2006 [Page 1] Internet-Draft Session Policy Framework October 2005 document specifies a framework for SIP session policies. It defines two types of session policies, session-specific and session- independent policies, and introduces a model, an overall architecture and the protocol components needed for session policies. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Session-Independent Policies . . . . . . . . . . . . . . . . . 4 3.1. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Subscription . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Content . . . . . . . . . . . . . . . . . . . . . . . 6 4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 6 4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Overview of Operation . . . . . . . . . . . . . . . . . . 9 4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 9 4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 11 4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 12 4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 12 4.4.2. Caching of Policy Server URIs . . . . . . . . . . . . 13 4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 14 4.4.4. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 14 4.4.5. Header Definition and Syntax . . . . . . . . . . . . . 15 4.5. Policy Channel Protocol . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Normative References . . . . . . . . . . . . . . . . . . . 17 7.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Hilt, et al. Expires April 19, 2006 [Page 2] Internet-Draft Session Policy Framework October 2005 1. Introduction The Session Initiation Protocol (SIP) [6] is a signaling protocol for creating, modifying and terminating multimedia sessions. A central element in SIP is the proxy server. Proxy servers are intermediaries that are responsible for request routing, rendezvous, authentication and authorization, mobility, and other signaling services. However, proxies are divorced from the actual sessions - audio, video, and messaging - that SIP establishes. Details of the sessions are carried in the payload of SIP messages, and are usually described with the Session Description Protocol (SDP) [7]. Indeed, SIP provides end-to-end encryption features using S/MIME, so that all information about the sessions can be hidden from eavesdroppers and proxies alike. However, experience has shown that there is a need for SIP intermediaries to impact aspects of a session. For example, SIP may be used in a wireless network, which has limited resources for media traffic. During periods of high activity, the wireless network provider wants to restrict the amount of bandwidth available to each individual user. With session policies, an intermediary in the wireless network can inform the user agent about the bandwidth it currently has available. This information enables the user agent to make an informed decision about the number of streams, the media types, and the codecs it can successfully use in a session. In another example, a SIP user agent is using a network which is connected to the public Internet through a firewall or a network border device. The network provider would like to tell the user agent that it needs to send its media streams to a specific IP address and port on the firewall or border device to reach the public Internet. Knowing this policy enables the user agent to set up sessions across the firewall or the network border. In contrast to other methods for inserting a media intermediary, the use of session policies does not require the inspection or modification of SIP message bodies. Other user cases for session policies are described 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. Hilt, et al. Expires April 19, 2006 [Page 3] Internet-Draft Session Policy Framework October 2005 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. Two types of session policies exist: session-specific policies and session-independent policies. Session-specific policies are policies that are created for one particular session, in response to (certain aspects of) the session description for this session (e.g. the IP addresses and ports that are used for media). Since session-specific policies are tailored to a session, they only apply to the session they are created for. They are created on a session-by-session basis during the establishment of the session at the time the session description is known. Session-independent policies on the other hand are policies that are created independent of a session and generally apply to the SIP sessions set up by a user agent. Since these policies are not based on a specific session description, they can be created and conveyed to the user agent at any time, independent of an attempt to set up a session. This specification defines a framework for SIP session policies. It specifies a model, the overall architecture, and the protocol components that are needed for session-independent and 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. 3. Session-Independent Policies This section defines a model and the protocol components for session- independent policies. 3.1. Model Setting up session-independent policies involves the following steps: 1. A user agent requests session-independent policies from the policy servers in the local network and home domain. These two domains most likely have session-independent policies for a user agent. A user agent typically request these policies when it Hilt, et al. Expires April 19, 2006 [Page 4] Internet-Draft Session Policy Framework October 2005 starts up or connects to a new network domain. 2. The policy server selects the policies that apply to this user agent. The policy server may have general policies that apply to all users or maintain separate policies for each individual user. The selected policies are returned to the user agent. 3. The policy server may update the policies, for example, when network conditions change. 4. The user agent considers the policies received when creating or managing session descriptions for SIP sessions. 3.2. Protocol A UA subscribes to session-independent policies using the "ua profile" event package defined in the Framework for SIP User Agent Profile Delivery [4]. This event package has been designed to support subscriptions to user agent configuration information as well as to session-specific policies. A server can provide session- independent policies and configuration information through the same subscription. However, it is expected that session-independent policies and configuration information will often be provided by different servers, which may even be in different domains. In addition, session-independent policies may change more frequently than configuration information since they may consider external information, such as the network status or simply the time of day. 3.2.1. Subscription Session-independent policies are usually provided by the network domain the UA is physically connected to (i.e. the local network domain). This domain may, for example, have policies needed to support the network infrastructure (e.g. by limiting the bandwidth available to a user). Frequently, the domain a user registers at (i.e., the domain in the address-of-record (AoR)) will also provides session-independent policies. This domain may, for example, provide policies needed for services the user has subscribed to. The "ua profile" event package [4] provides a mechanism to discover policy servers in these two domains. The "localnetwork" profile-type enables a UA to discover a servers in the local network domain; the "user" profile type enables the discovery of a server in the AoR domain. A UA SHOULD attempt to discover and subscribe to the policy servers in these two domains. A UA SHOULD create a SUBSCRIBE request in the following events: o The UA registers a AoR for the first time or removes a AoR from the set of AoRs it has registered. In these cases, the UA SHOULD establish subscriptions for each new AoR using the "user" and the Hilt, et al. Expires April 19, 2006 [Page 5] Internet-Draft Session Policy Framework October 2005 "localnetwork" profile-types. It SHOULD terminate all subscriptions for the AoRs that have been removed. o The UA changes the domain it is connected to. The UA SHOULD create a new subscription for each AoR using the "localnetwork" profile-type. It SHOULD terminate all existing subscriptions for the "localnetwork" profile-type. It does not need to change the subscriptions for "user" profiles. If a subscriber is unable to establish a subscription, it SHOULD NOT attempt to re-try this subscription, unless one of the above events occurs again. This is to limit the number of SUBSCRIBE requests sent within domains that do not support session-independent policies. 3.2.2. Content The "ua profile" event package is an abstract event package that does not define a default content type for subscriptions. A user agent subscribing to session-independent policies SHOULD include the MIME type for the Schema for SIP User Agent Profile Data Sets [9] and the "application/session-policy+xml" format [3] in the Accept header of a SUBSCRIBE request. The Schema for SIP User Agent Profile Data Sets is an abstract format for configuration data that is extended by the "application/session-policy+xml" format for media-related policies. These are the default formats for subscriptions to session- independent policies and MUST be supported by a user agent compliant to this specification. OPEN ISSUE: Do we need a separate MIME type for the policy format or is it sufficient to use the MIME type of the UA data set schema? It is unclear how the user agent indicates that it supports the session policy format and that it wants to receive session policies. A policy server MAY send a notification to the subscriber every time the session-independent policy covered by the subscription changes. The definition of what causes a policy to change is at the discretion of the administrator. A change in the policy may be triggered, for example, by a change in the network status or simply by an update of the service level agreement with the customer. The session- independent policy contained in notification MUST represent a complete session-independent policy. Deltas to previous policies or partial policies are not supported. 4. Session-Specific Policies This section defines a model, an architecture and the protocol components for session-specific policies. Hilt, et al. Expires April 19, 2006 [Page 6] Internet-Draft Session Policy Framework October 2005 4.1. 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 role of the proxy 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 April 19, 2006 [Page 7] Internet-Draft Session Policy Framework October 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. 4.2. Model 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 the following steps: 1. A user agent submits a session description to the policy server and asks whether a session using this session description is permissible. 2. The policy server creates a policy decision for this particular session and returns the decision to the user agent. Possible policy decisions are to (1) deny the session, (2) propose changes to the session description with which the session is acceptable, Hilt, et al. Expires April 19, 2006 [Page 8] Internet-Draft Session Policy Framework October 2005 or (3) accept the session as it was proposed. 3. The policy server may update the policy decision at any time. 4. The user agent applies the policy decision to the session it is establishing or managing. 4.3. Overview of Operation This section provides example call flows to illustrate the establishment of session-specific policies. In the following scenario, there are two domains (domain A and domain B), which both have session-specific policies for the UAs in their domain. Both domains do not provide policies to the 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.3.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 April 19, 2006 [Page 9] Internet-Draft Session Policy Framework October 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 April 19, 2006 [Page 10] Internet-Draft Session Policy Framework October 2005 Figure 2 4.3.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 [10]. 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 | |<----------------|<---------------|<----------------| (8) Hilt, et al. Expires April 19, 2006 [Page 11] Internet-Draft Session Policy Framework October 2005 | | | | | | | | | PolicyChannel | | | | + InfoOffer | | | | + InfoAnswer | | | |------------------->| | | (9) | PolicyChannel | | | | + PolicyOffer | | | | + PolicyAnswer | | | |<-------------------| | | (10) | | | | | ACK answer | |--------------------------------------------------->| (11) | | | | | | | | | | | PolicyChannel | | | | + InfoAnswer | | | |<-------------------| (12) | | | PolicyChannel | | | | + PolicyAnswer | | | |------------------->| (13) | | | | Figure 3 4.4. 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. 4.4.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 defined in this specification 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 use this URI to contact the policy server and ask for policies for current session. The UAC SHOULD apply the policies received and resend the updated request. The UAC MUST a Policy-Id header into the updated request. The Hilt, et al. Expires April 19, 2006 [Page 12] Internet-Draft Session Policy Framework October 2005 Policy-Id header MUST include the URIs of all policy servers the UAC has contacted during the processing of the 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. The UAC SHOULD NOT change this implicit order among policy servers. Session policies may apply to the offer, the answer or both session descriptions. Depending on the type of session policies, a UAC may need to submit the offer and/or the answer to the policy server. If offer and answer are submitted separately, they MUST be submitted to the same policy servers. 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 [10]). 4.4.2. Caching of Policy Server URIs 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. Domains can prevent the UAC from caching the local policy server URI. This is useful, for example, if the policy server does not 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- Hilt, et al. Expires April 19, 2006 [Page 13] Internet-Draft Session Policy Framework October 2005 cacheable policy server URI. It SHOULD remove the current URI from the cache when receiving a "non-cacheable" 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 store the list of policy server URIs is has contacted for a session. The UAC should keep this list until the session is terminated. The UAC SHOULD contact the policy server URIs in this list for each mid-dialog INVITE or UPDATE request. This avoids the retransmission of policy server URIs for each mid-dialog requests. 4.4.3. 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 ask for 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 type. In this case, it MUST contact the same policy servers it has contacted for the offer. 4.4.4. 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. 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. Hilt, et al. Expires April 19, 2006 [Page 14] Internet-Draft Session Policy Framework October 2005 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 all existing values at the beginning of the list. A proxy MUST NOT change the order of existing Policy- Contact header values. 4.4.5. 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" ] The BNF for absoluteURI is defined in [6]. Table 1 is an extension of Tables 2 and 3 in [6]. The column 'UPD' is for the UPDATE method [5]. Hilt, et al. Expires April 19, 2006 [Page 15] Internet-Draft Session Policy Framework October 2005 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 4.5. Policy Channel Protocol The policy channel is implemented by the "session-spec-policy" event package defined in [2]. When a UA needs to contact a policy server it creates (or refreshes) a subscription to the policy server using the above event package. All implementations MUST support this event package as a policy channel implementation. A UA may receive policy updates through the policy channel. The UA SHOULD apply these policies to the current session. It may need to generate a re-INVITE or UPDATE request to communicate the changes in the session to the peer UA. 5. Security Considerations In particular authentication and authorization are critical issues that need to be addressed here. [TBD.] 6. IANA Considerations [TBD.] Appendix A. Acknowledgements Many thanks to Allison Mankin for the discussions and the suggestions for this draft. Many thanks also to everyone who contributed by providing feedback on the mailing list and in IETF meetings. 7. References Hilt, et al. Expires April 19, 2006 [Page 16] Internet-Draft Session Policy Framework October 2005 7.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hilt, V. and G. Camarillo, "A Session Initiation Protocol (SIP) Event Package for Session-Specific Session Policies.", draft-hilt-sipping-session-policy-package-00 (work in progress), October 2005. [3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile Data Set for Media Policy", draft-hilt-sipping-media-policy-dataset-00 (work in progress), October 2005. [4] Petrie, D., "A Framework for Session Initiation Protocol User Agent Profile Delivery", draft-ietf-sipping-config-framework-07 (work in progress), July 2005. [5] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002. [6] 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. 7.2. Informative References [7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [8] 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. [9] Petrie, D., Lawrence, S., Dolly, M., and V. Hilt, "A Schema and Guidelines for Defining Session Initiation Protocol User Agent Profile Data Sets", draft-petrie-sipping-profile-datasets-02 (work in progress), October 2005. [10] 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. Hilt, et al. Expires April 19, 2006 [Page 17] Internet-Draft Session Policy Framework October 2005 Authors' Addresses Volker Hilt Bell Labs/Lucent Technologies 101 Crawfords Corner Rd Holmdel, NJ 07733 USA Email: volkerh@bell-labs.com 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 Hilt, et al. Expires April 19, 2006 [Page 18] Internet-Draft Session Policy Framework October 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 April 19, 2006 [Page 19]