One document matched: draft-ietf-sip-session-policy-framework-01.txt
Differences from draft-ietf-sip-session-policy-framework-00.txt
SIPPING Working Group V. Hilt
Internet-Draft Bell Labs/Alcatel-Lucent
Expires: August 13, 2007 G. Camarillo
Ericsson
J. Rosenberg
Cisco Systems
February 9, 2007
A Framework for Session Initiation Protocol (SIP) Session Policies
draft-ietf-sip-session-policy-framework-01
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 August 13, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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. This document
specifies a framework for SIP session policies that provides a
standard mechanism by which a proxy can define or influence policies
Hilt, et al. Expires August 13, 2007 [Page 1]
Internet-Draft Session Policy Framework February 2007
on sessions, such as the codecs or media types to be used. It
defines a model, an overall architecture and new protocol mechanisms
for session policies.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Session-Independent Policies . . . . . . . . . . . . . . . . . 5
3.1. Architecture and Overview . . . . . . . . . . . . . . . . 5
3.2. Policy Subscription . . . . . . . . . . . . . . . . . . . 6
4. Session-Specific Policies . . . . . . . . . . . . . . . . . . 7
4.1. Architecture . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. Offer in Request . . . . . . . . . . . . . . . . . . . 10
4.3.2. Offer in Response . . . . . . . . . . . . . . . . . . 13
4.4. UA/Policy Server Rendezvous . . . . . . . . . . . . . . . 14
4.4.1. UAC Behavior . . . . . . . . . . . . . . . . . . . . . 14
4.4.2. Proxy Behavior . . . . . . . . . . . . . . . . . . . . 17
4.4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . 18
4.4.4. Caching the Local Policy Server URI . . . . . . . . . 18
4.4.5. Storing Session Policy Server URIs . . . . . . . . . . 19
4.4.6. Contacting the Policy Server . . . . . . . . . . . . . 19
4.4.7. Header Definition and Syntax . . . . . . . . . . . . . 20
4.5. Policy Channel . . . . . . . . . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
6.1. Registration of the "Policy-Id" Header . . . . . . . . . . 24
6.2. Registration of the "Policy-Contact" Header . . . . . . . 24
6.3. Registration of the "policy" SIP Option-Tag . . . . . . . 24
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 24
Appendix B. Session-Specific Policies - Call Flows . . . . . . . 25
B.1. Offer in Invite . . . . . . . . . . . . . . . . . . . . . 25
B.2. Offer in Response . . . . . . . . . . . . . . . . . . . . 27
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.1. Normative References . . . . . . . . . . . . . . . . . . . 28
7.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Hilt, et al. Expires August 13, 2007 [Page 2]
Internet-Draft Session Policy Framework February 2007
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 can
currently count on. 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. Similarly, a
network provider may have a service level agreement with a user that
defines the set of media types a user can use. With session
policies, the network can convey the current set of policies to user
agents, enabling them to set up sessions without inadvertently
violating any of the network policies.
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.
Domains often enforce the session policies they have in place. For
example, a domain might have a policy that disallows the use of video
and may enforce this policy by dropping all packets that contain a
video encoding. Unfortunately, enforcement mechanisms usually do not
inform the user about the policies they are enforcing. Instead, they
silently keep the user from doing anything against them. This may
Hilt, et al. Expires August 13, 2007 [Page 3]
Internet-Draft Session Policy Framework February 2007
lead to a malfunctioning of devices that is incomprehensible to the
user. With session policies, the user knows about the current
network policies and can set up policy-compliant sessions or simply
connect to a domain with less stringent policies. Thus, 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.
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, based on the session
description of this session. They enable a network intermediary to
examine the session description a UA is proposing and to return a
policy specifically for this session description. For example, an
intermediary could open pinholes in a firewall/NAT for each media
stream in a session and return a policy that replaces the internal IP
addresses and ports with external ones. Since session-specific
policies are tailored to a session, they only apply to the session
they are created for. Session-specific policies are created on a
session-by-session basis at the time the session is established.
Session-independent policies on the other hand are policies that are
created independent of a session and generally apply to all SIP
sessions set up by a user agent. A session-independent policy can,
for example, be used to inform user agents about an existing
bandwidth limit or media type restrictions. Since these policies are
not based on a specific session description, they can be created
independent of an attempt to set up a session and only need to be
conveyed to the user agent when it initializes (e.g. at the time the
device is powered on) and when the policies are changed.
This specification defines a framework for SIP session policies. It
specifies a model, the overall architecture and new protocol
mechanisms 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.
Hilt, et al. Expires August 13, 2007 [Page 4]
Internet-Draft Session Policy Framework February 2007
3. Session-Independent Policies
Session-independent policies are policies that are created
independent of a session and generally apply to all sessions a user
agent is setting up. They typically remain stable for a longer
period of time and apply to any session set up while they are valid.
However, session-independent policies may also change over time. For
example, a policy that defines a bandwidth limit for a user may
change during the day, defining a lower limit during peak hours and
allow more bandwidth off-peak.
3.1. Architecture and Overview
+-------------+
/------| policy |
+----+ / | server 1 |
| |---/ +-------------+
| UA | ...
| |---\ +-------------+
+----+ \ | policy |
\------| server n |
+-------------+
Figure 1
A SIP UA may receive session-independent policies from one or more
policy servers. In a typical configuration, a UA receives session-
independent policies from a policy server in the access or local
network domain (i.e. the domain from which the UA receives IP
service) and possibly the home network domain (i.e. the domain the UA
registers at). The local network may have policies that support the
access network infrastructure. For example, in a wireless network
where bandwidth is scarce, a provider may restrict the bandwidth
available to an individual user. The home network may have policies
that are needed to support services or policies that reflect the
service level agreement with the user. Thus, in most cases, a UA
will receive session-independent policies from one or two policy
servers.
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. A user
agent typically requests these policies when it starts up or
connects to a new network domain.
Hilt, et al. Expires August 13, 2007 [Page 5]
Internet-Draft Session Policy Framework February 2007
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.
3.2. Policy Subscription
A UA requests session-independent policies by subscribing to session-
independent policies on the policy server in a domain. Subscriptions
to session-independent policies are established using the "ua-
profile" event package defined in the Framework for SIP User Agent
Profile Delivery [4].
The "ua-profile" event package [4] provides a mechanism to discover
policy servers in the local network and the home domain. The "local-
network" profile-type enables a UA to discover a policy server in the
local domain. The "user" profile type enables the discovery of a
policy server in the home domain. A UA compliant to this
specification SHOULD attempt to discover and subscribe to the policy
servers in these two domains.
A UA SHOULD (re-)subscribe to session-independent policies when the
following events occur:
o The UA registers a new address-of-record (AoR) 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 "local-network" profile-types. The UA SHOULD terminate
all subscriptions for AoRs it has removed.
o The UA changes the domain it is connected to. The UA SHOULD
terminate all existing subscriptions for the "local-network"
profile-type. It SHOULD then create a new subscription for each
AoR using the "local-network" profile-type. This way, the UA
stops receiving policies from the previous local domain and starts
to receive the policies of the new local domain. The UA 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.
A UA compliant to this specification MUST support the User Agent
Profile Data Set for Media Policy [3]. To indicate that the UA wants
to receive session-independent policies, it includes the MIME type
"application/session-policy+xml" in the Accept header of a SUBSCRIBE
Hilt, et al. Expires August 13, 2007 [Page 6]
Internet-Draft Session Policy Framework February 2007
request.
A policy server MAY send a notification to the subscriber every time
the session-independent policies covered by the subscription change.
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, by the change in the time
of day or by an update of the service level agreement with the
customer. The session-independent policies contained in a
notification MUST represent a complete session-independent policy.
Deltas to previous policies or partial policies are not supported.
4. Session-Specific Policies
Session-specific policies are policies that are created specifically
for one particular session of a UA. Thus, session-specific policies
will typically be different for different sessions. The session-
specific policies for a session may change during the course of the
session. For example, a user may run out of credit during a session,
which will cause the network to disallow the transmission all media
streams from this point on.
4.1. Architecture
domain 1
+-----------+
/------| proxy |----...
+----+ / +-----------+
| |---/ +-----------+
| | | policy |
| UA |============| server |
| | +-----------+
| |**** +-----------+
+----+ * | policy |
*******|enforcement|****...
+-----------+
--- SIP Signaling
=== Policy Channel
*** Media
Figure 2
The following entities are needed for session-specific policies (see
Figure 2): a user agent (UA), a proxy, a policy server and possibly a
policy enforcement entity.
Hilt, et al. Expires August 13, 2007 [Page 7]
Internet-Draft Session Policy Framework February 2007
The role of the proxy is to provide a rendezvous mechanism for UAs
and policy servers. It ensures that each UA has the URI of the
policy server in its domain and knows where to retrieve policies
from. The proxy conveys the policy server URI to UAs in case they
have not yet received it (e.g. in a previous call or through other
means such as configuration). The proxy 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. The role of the policy server is to
deliver session policies to UAs. The policy server receives session
information from the UA, uses this information to determine the
policies that apply to the session and returns these policies to the
UA. The mechanism for generating policies (i.e. making policy
decisions) is outside of the scope of this specification. A policy
server may, for example, query an external entity to get policies or
it may directly incorporate a policy decision point and generate
policies locally.
A UA receives the URI of a policy server from a proxy. It uses this
URI to contact 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
enforcement of session policies and the mechanisms defined here are
orthogonal a policy enforcement infrastructure. Their goal is to
provide a mechanism to convey session information to a policy server
and to return the policies that apply to a session to the UA.
In principle, each domain that is traversed by SIP signaling messages
can define session-specific policies for a session. Each domain
needs to run a policy server and a proxy that is able to rendezvous a
UA with the policy server (as shown in Figure 2). However, it is
expected that session-specific policies will often only be provided
by the local domain of the user agent.
4.2. Overview
The protocol defined in this specification clearly separates SIP
signaling and the exchange of policies. 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 policy information between endpoint and a policy
server in the network is piggybacked onto the SIP signaling messages
Hilt, et al. Expires August 13, 2007 [Page 8]
Internet-Draft Session Policy Framework February 2007
that are exchanged between endpoints.
The main advantage of using a separate policy channel is that it
decouples the exchange of signaling messages between endpoints from
the exchange of policies between endpoint and policy server. This
decoupling has a number of desirable properties. It enables the use
of separate encryption mechanisms on the signaling path to secure the
communication between endpoints, and on the policy channel to secure
the communication between endpoint and policy server. Policies can
be submitted directly from the policy server to the endpoint and
never travel along the signaling path, possibly crossing many
domains. Endpoints set up a separate policy channel to each policy
server and can specifically decide which information they want to
disclose to which policy server. Finally, policy servers do not need
to rely on a SIP signaling message flowing by to send policies or
policy updates to an endpoint. A policy server can use the policy
channel at any time to update session policies as needed. A
disadvantage of the separate channel model is that it requires
additional messages for the exchange of policy information.
Following this model, signaling for session-specific policies
involves the following two fundamental tasks:
1. UA/policy server rendezvous: a UA setting up a session needs to
be able to discover the policy servers that are relevant to this
session.
2. Policy channel: once the UA has discovered the relevant policy
servers for a session, it needs to connect to these servers,
disclose session information and retrieve the policies that apply
to this session.
The setting up session-specific policies over the policy channel
involves the following steps:
1. A user agent submits information about the session it is trying
to establish to the policy server and asks whether a session
using these parameters is permissible.
2. The policy server generates a policy decision for this session
and returns the decision to the user agent. Possible policy
decisions are (1) to deny the session, (2) to propose changes to
the session parameters with which the session would be
acceptable, or (3) to accept the session as it was proposed.
3. The policy server can update the policy decision at a later time.
A policy decision update can, for example, propose additional
changes to the session (e.g. change the available bandwidth) or
deny a previously accepted session (i.e. disallow the
continuation of a session).
Hilt, et al. Expires August 13, 2007 [Page 9]
Internet-Draft Session Policy Framework February 2007
In many cases, the mechanism for session-specific policies will be
used to disclose session information and return session policies.
However, some scenarios may only involve the disclosure of session
information to a network intermediary. If an intermediary does not
intend to return a policy, it can simply accept the session as it was
proposed. Similarly, some session-specific policies only apply to
the offer (and therefore only require the disclosure of the offer)
whereas others apply to offer and answer. Both types of policies are
supported by session-specific policy mechanism.
4.3. Examples
This section provides two examples to illustrate the overall
operation of session-specific policies. The call flows depict the
rendezvous mechanism between UA and policy server and indicate the
points at which the UA exchanges policy information with the policy
server.
The example is based on 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 shown in Figure 3 depicts an INVITE transaction
with the offer in the request. It is assumed that this is the first
INVITE request the UAC creates in this domain and that it therefore
does not have previous knowledge about the policy server URIs in this
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. This step is needed since the UAC has
no prior knowledge about the URI of PS A. (3) UA A uses the URI to
contact 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
Hilt, et al. Expires August 13, 2007 [Page 10]
Internet-Draft Session Policy Framework February 2007
from PS A.
Hilt, et al. Expires August 13, 2007 [Page 11]
Internet-Draft Session Policy Framework February 2007
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 August 13, 2007 [Page 12]
Internet-Draft Session Policy Framework February 2007
Figure 3
4.3.2. Offer in Response
The call flow shown in Figure 4 depicts an INVITE transaction with
the offer in the response.
(1) UA A sends an INVITE without an offer to proxy P A and (2) P A
returns a 488 response containing the URI of PS A. (3) and (4) UA A
uses this policy server URI to set up the policy channel. At this
time, UA A does not disclose a session description since it does not
have the offer yet. (5) UA A re-sends the INVITE request and includes
a Policy-Id header to indicate that it has 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 discloses the offer to PS
B. (7) UA B receives policies from PS B and applies them to the
offer. (8) UA B returns the updated offer the 200 OK. (9) and (10) UA
A contacts PS and discloses the offer and the answer it is about to
send. An important difference to the flow in the previous example is
that UA A performs steps (9) and (10) before returning the answer in
step (11). This enables UA A to return the final answer in the ACK,
which includes all applicable policies. However, it requires that PS
A immediately returns a policy to avoid a delay in the transmission
of the ACK. (12) and (13) UA B also sends the answer to PS B and
applies the policies it receives to the answer before using it.
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)
| | | |
Hilt, et al. Expires August 13, 2007 [Page 13]
Internet-Draft Session Policy Framework February 2007
| | PS B | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer |
| | |<-------------------| (6)
| | | PolicyChannel |
| | | + PolicyOffer |
| | |------------------->| (7)
| | | |
| | | |
| OK offer | OK offer | OK offer |
|<----------------|<---------------|<----------------| (8)
| | | |
| | | |
| PolicyChannel | | |
| + InfoOffer | | |
| + InfoAnswer | | |
|------------------->| | | (9)
| PolicyChannel | | |
| + PolicyOffer | | |
| + PolicyAnswer | | |
|<-------------------| | | (10)
| | | |
| ACK answer |
|--------------------------------------------------->| (11)
| | | |
| | | |
| | | PolicyChannel |
| | | + InfoAnswer |
| | |<-------------------| (12)
| | | PolicyChannel |
| | | + PolicyAnswer |
| | |------------------->| (13)
| | | |
Figure 4
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
A UAC compliant to this specification MUST include a Supported header
field with the option tag "policy" into all requests that can
Hilt, et al. Expires August 13, 2007 [Page 14]
Internet-Draft Session Policy Framework February 2007
initiate an offer/answer exchange [8] (e.g. INVITE, UPDATE and PRACK
requests). The UA MUST include the "policy" option tag into these
requests even if the particular request does not contain an offer or
answer (e.g. an INVITE request without an offer).
A UAC may receive a 488 response that contains a Policy-Contact
header field. The Policy-Contact header is a new header defined in
this specification. It 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. After receiving a 488
response with a Policy-Contact header, a UAC compliant to this
specification needs to decide if it wants to continue with the
session now knowing that there is a policy server. If the UAC
decides to continue, it MUST use the policy server URI to contact the
policy server using mechanism defined in Section 4.5. After
receiving policies from the policy server, the UAC decides if it
wants to accept these policies or not. If it accepts these policies,
it MUST apply them to the current request and resend the updated
request. If no changes are required by policies or no policies have
been received, the request can be resend without any policy-induced
changes. If the UAC decides that the list of policy servers or the
received session policies are unacceptable, it MUST NOT resend the
request.
The UAC MUST insert a Policy-Id header into a request if it has
contacted a policy server and accepted the policies received for this
request. The Policy-Id header is a new header that is defined in
this specification. The UA MUST create a Policy-Id header value for
each policy server involved in the preparation of a request. A
Policy-Id header value contains two pieces of information: the policy
server URI and an optional token. The policy server URI is the URI
the UA has used to contact the policy server. The token is an opaque
string the UAC may have received from the policy server after
contacting it. If the UA has received a token from the policy server
it MUST include the token in the Policy-Id header. The format of the
Policy-Id header is defined in Section 4.4.7.
The Policy-Id header serves two main purposes: first and most
importantly, it enables a proxy to determine if the UAC already knows
the URI of its policy server. A proxy can pass through a request if
the URI of its policy server is included in the Policy-Id header. If
the policy server URI is not yet known to the UAC, the proxy can
convey this URI to the UAC by rejecting the request with a 488
response.
The second purpose of the Policy-Id header is to enable a domain to
route all requests that belong to the same session (i.e. the initial
request and requests a UA retransmits after contacting the policy
Hilt, et al. Expires August 13, 2007 [Page 15]
Internet-Draft Session Policy Framework February 2007
server) to the same proxy and policy server. This is important if a
domain has multiple proxy/policy server combinations (e.g. in a
proxy/policy server farm that receives requests through a load
balancer) and the proxies/policy servers create per-session state in
the network. An example for such a scenario is a policy server that
is associated with a session border device. The policy server
configures the session border device after receiving a session
description from the UAC via the policy channel. Retransmitted
requests for such a session need to be routed to the same proxy/
policy server as the initial request since this proxy/policy server
combination that has configured the associated border device for the
session.
Routing requests that belong to the same session to the same proxy
can be achieved by using the Policy-Id header token. It requires
that the policy server returns a token to the UAC that uniquely
identifies the specific proxy/policy server combination. The UAC
includes this token in the Policy-Id header and it can be used
(together with the policy server URI) by proxies in this domain to
route the request along the desired path. The format of this token
does not require standardization. The only requirement is that the
token provides sufficient information for proxies to route the
message inside a domain to the desired proxy/policy server. The
token can, for example, be a numeric identifier or an IP address.
Note: it has been proposed to use the Policy-Id header to provide
a hint for a proxy that the UAC has actually contacted the policy
server. This usage also requires the policy server to return a
token to the UA. In addition, the policy server needs to share
valid tokens with the proxy. After receiving a request with a
Policy-Id header, the proxy can determine if the token in the
Policy-Id header is valid. If it is valid, the proxy knows that
the UA has contacted the policy server for this session. However,
it is important to note that this token does not provide any proof
that the UA has actually used the policies it has received from
the policy server. A malicious UA may simply contact the policy
server, discard all policies it receives but still use the token
in the Policy-Id header.
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 a policy
server after receiving a 488 response from a domain and before re-
sending the request, session policies are always applied to a request
in the order in which the request traverses through the domains. The
UAC MUST NOT change this implicit order among policy servers.
A UAC frequently needs to contact the policy server in the local
Hilt, et al. Expires August 13, 2007 [Page 16]
Internet-Draft Session Policy Framework February 2007
domain before sending a new request. To avoid the retransmission of
the local policy server URI in a 488 for each new request, a UA
SHOULD maintain a cache that contains the URI of the local policy
server (see Section 4.4.4). The UAC SHOULD use the cached policy
server URI to contact the local policy server before sending the
initial request that starts an offer/answer exchange (e.g. an INVITE
request).
A UA may decide to change the session description of a session and to
initiate subsequent offer/answer exchanges (e.g. using INVITE, UPDATE
or PRACK requests) to re-negotiate the session description. When
creating such a mid-dialog request, a UA SHOULD contact the same
policy servers it has contacted during the initial offer/answer
exchange (see Section 4.4.5) before sending the request. This avoids
the retransmission of all policy server URIs in 488 responses for
mid-dialog requests.
4.4.2. Proxy Behavior
A proxy provides rendezvous functionality for UAs and a policy
server. This is achieved by conveying the URI of a policy server to
the UAC or the UAS (or both) when processing INVITE, UPDATE or PRACK
requests (or any other request that can initiate an offer/answer
exchange).
If such a 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 verify that the request does not contain a
Policy-Id header field, which has the local policy server URI as a
value. If the request does not contain such a header or the local
policy server URI is not present in this 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 its
associated policy server. The proxy MAY add the header field
parameter "non-cacheable" to prevent the UAC from caching this policy
server URI (see Section 4.4.4).
If the local policy server URI is present in a Policy-Id header value
of a request, then the proxy MUST NOT reject the request as described
above (it may still reject the request for other reasons). The proxy
SHOULD remove the Policy-Id header value for this policy server from
the Policy-Id header field before forwarding the request. This value
only increases message size and is not relevant to other proxies on
the path. It also would disclose the policy server URI to subsequent
proxies.
The proxy MAY insert a Policy-Contact header field into INVITE,
Hilt, et al. Expires August 13, 2007 [Page 17]
Internet-Draft Session Policy Framework February 2007
UPDATE or PRACK requests (or any other request that can initiate an
offer/answer exchange) 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 ahead of all existing values at
the beginning of the list. A proxy MUST NOT change the order of
existing Policy-Contact header values.
4.4.3. UAS Behavior
A UAS may receive an INVITE, UPDATE or PRACK request (or another
request that can initiate offer/answer exchanges), which contains a
Policy-Contact header filed with a list of policy server URIs. A UAS
that receives such a request needs to decide if it wants to accept
the session knowing that there are policy servers involved. If it
accepts, it MUST contact all policy server URIs in a Policy-Contact
header. The UAS MUST contact the policy server URIs in the order in
which they were contained in the Policy-Contact header, starting with
the topmost value.
If a UAS decides that it does not want to accept a session because
there are policy servers involved or because one of the session
policies received from a policy server is not acceptable, the UAS
MUST reject the request with a 488 response.
A UAS may receive a token from a policy server via the policy
channel. Since the UAS does not create a Policy-ID header, it can
simply ignore this token.
4.4.4. Caching the Local Policy Server URI
A UAC may frequently need to contact the policy server in the local
domain before sending a request. To avoid the retransmission of the
local policy server URI for each new request, a UA SHOULD maintain a
cache that contains the URI of the local policy server. A UA may
receive this URI in a Policy-Contact header of a request or a 488
response. The UA may also receive the local policy server URI
through configuration, for example, via the configuration framework
[4]. If a UA has received a local policy server URI through
configuration and receives another local policy server URI in a
Policy-Contact header, it SHOULD overwrite the configured URI with
the most recent one received in a Policy-Contact header.
Domains can prevent a UA 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". A UA MUST NOT cache a non-cacheable policy
server URI. It SHOULD remove the current URI from the cache when
Hilt, et al. Expires August 13, 2007 [Page 18]
Internet-Draft Session Policy Framework February 2007
receiving a local policy server URI that is marked as "non-
cacheable". This is to avoid the use of policy server URIs that are
outdated.
The UA 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, traversing different domains.
The UA MUST NOT cache tokens it may receive from a policy server. A
token is only valid for one request.
4.4.5. Storing Session Policy Server URIs
A UA discovers the list of policy servers relevant for a session
during the initial offer/answer exchange. It SHOULD store this list
of policy server URIs, as part of the dialog state. The UA SHOULD
maintain this list until the session is terminated. It SHOULD store
policy server URIs in this list even if they are marked as "non-
cacheable". The non-cacheable parameter only refers to caching
policy server URIs for re-use between sessions.
If a UAC has contacted all stored policy servers before sending a
mid-dialog request and receives a 488 in response to this request
with a Policy-Contact header containing a new policy server URI, it
MUST discard the stored policy server URI list for the current
dialog. Receiving a 488 response at this point indicates that the
set of policy servers relevant for the current dialog has changed.
The UAC SHOULD retry sending the request as if it was the first
request in a dialog (i.e. without applying any policies except
policies from the local policy server). This way, the UAC will re-
discover the list of policy server URIs relevant for the current
request.
If a UAS receives a mid-dialog request with a Policy-Contact header
containing a list of policy server URIs that is different from the
list stored for the dialog, then the UAS SHOULD replace the stored
list with the one received in the Policy-Contact header field.
4.4.6. Contacting the Policy Server
A UA compliant to this specification MUST contact the discovered
policy servers and apply session policies to an offer or answer
before using the offer or answer. If the UA does not want to contact
the policy servers provided or the policies received for a session
are unacceptable, it MUST NOT continue with the session. This means
that, the UA MUST cancel or reject a pending INVITE transaction for
the session or terminate the session if it is already in progress.
Hilt, et al. Expires August 13, 2007 [Page 19]
Internet-Draft Session Policy Framework February 2007
A UA that receives a SIP message containing an offer or answer SHOULD
completely process the message (e.g. according to [6]) before
contacting the policy server. The SIP processing of the message
includes, for example, updating dialog state and timers as well as
creating ACK or PRACK requests as necessary. This ensures that
contacting a policy server does not interfere with SIP message
processing and timing (e.g. by inadvertently causing timers to
expire). This implies, for example, that a UAC which has received a
response to an INVITE request SHOULD finish the processing of the
response including transmitting the ACK before it contacts the policy
server. An important exception to this rule is discussed in the next
paragraph.
In some cases, a UA needs to use the offer/answer it has received in
a SIP message to create an ACK or PRACK response for this message,
i.e. it needs to use the offer/answer before finishing the SIP
machinery for this message. For example, a UAC that has received an
offer in the response to an INVITE request needs to apply policies to
the offer and the answer before it can send the answer in an ACK. In
these cases, a UA SHOULD contact the policy server even if this is
during the processing of a SIP message. This implies that a UA,
which has received an offer in the response of an INVITE request,
SHOULD contact the policy server and apply session policies before
sending the answer in the ACK.
Note: this assumes that the policy server can always respond
immediately to a policy request and does not require manual
intervention to create a policy. This will be the case for most
policy servers. If, however, a policy server cannot respond with
a policy right away, it may return a policy that temporarily
denies the session and update this policy as the actual policy
decision becomes available. A delay in the response from the
policy server to the UA would delay the transmission of the ACK
and could trigger retransmissions of the INVITE response (also see
the recommendations for Flow I in [9]).
A UA MUST inform the policy server when a session is terminated via
the policy channel. This enables a policy server to free all
resources it may have allocated for this session. A policy server
can indicate via the policy channel that it does not need to be
contacted at the end of a session. In this case, the UA SHOULD NOT
inform the policy server about the termination of the session.
4.4.7. Header Definition and Syntax
Hilt, et al. Expires August 13, 2007 [Page 20]
Internet-Draft Session Policy Framework February 2007
4.4.7.1. Policy-Id Header
The Policy-Id header field is inserted by the UAC into INVITE, UPDATE
or PRACK requests (or any other request that can be used to initiate
an offer/answer exchange). The Policy-Id header identifies all
policy servers the UAC has contacted for this request.
The value of a Policy-Id header consists of a policy server URI. A
Policy-Id header value may have an optional token parameter. The
token parameter contains a token the UA may receive from the policy
server. If the UA has received a token, it MUST be included in the
Policy-Id header.
The syntax of the Policy-Id header field is:
Policy-Id = "Policy-Id" HCOLON policyURI
*(COMMA policyURI)
policyURI = ( SIP-URI / SIPS-URI )
[ SEMI token-param ] *( SEMI generic-param )
token-param = "token=" token
The BNF for SIP-URI, SIPS-URI, token and generic-param is defined in
[6].
4.4.7.2. Policy-Contact Header
The Policy-Contact header field can be inserted by a proxy into a 488
response to INVITE, UPDATE or PRACK requests (or other requests that
initiate an offer/answer exchange). 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 a UA MUST NOT
cache this policy server URI.
The Policy-Contact header field can also be inserted by a proxy into
INVITE, UPDATE and PRACK requests (or other requests that can be used
to initiate an offer/answer exchange). 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 syntax of the Policy-Contact header field is:
Policy-Contact = "Policy-Contact" HCOLON policyContactURI
*(COMMA policyContactURI)
policyContactURI = ( SIP-URI / SIPS-URI )
[ SEMI "non-cacheable" ] *( SEMI generic-param )
Hilt, et al. Expires August 13, 2007 [Page 21]
Internet-Draft Session Policy Framework February 2007
The BNF for SIP-URI, SIPS-URI and generic-param 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].
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
4.5. Policy Channel
The main task of the policy channel is to enable a UA to submit
information about the session it is trying to establish (i.e. the
offer and the answer) to a policy server and to receive the resulting
session-specific policies and possible updates to these policies in
response.
A UA compliant to this specification MUST implement the Event Package
for Session-Specific Session Policies [2]. It contacts a policy
server by subscribing to this event package.
A UA MUST use the policies it has received from the policy server in
the current session. If these policies are unacceptable, the UA MUST
NOT attempt to establish the session. When a UA receives a
notification about a change in the current policies, it MUST apply
the updated policies to the current session or it MUST terminate the
session. If the policy update causes a change in the session
description of a session, the UA may need to re-negotiate the
modified session description with its peer UA, for example, using a
re-INVITE or UPDATE request. For example, if a policy update
disallows the use of video and video is part of the current session
description, then the UA will need to create an new session
description offer without video. After receiving this offer, the
peer UA knows that video can't be used any more and responds with the
corresponding answer. The re-INVITE or UPDATE message need to be
generated in accordance to Section 4.4.1.
5. Security Considerations
Session policies can significantly change the behavior of a user
agent and can be used by an attacker to compromise a user agent. For
example, session policies can be used to prevent a user agent from
successfully establishing a session (e.g. by setting the available
bandwidth to zero). Such a policy can be submitted to the user agent
Hilt, et al. Expires August 13, 2007 [Page 22]
Internet-Draft Session Policy Framework February 2007
during a session, which may cause the UA to terminate the session.
A user agent transmits session information to a policy server for
session-specific policies. This session information may contain
sensitive data the user may not want an eavesdropper or an
unauthorized policy server to see. For example, the session
information may contain the encryption keys for media streams. Vice
versa, session policies may also contain sensitive information about
the network or service level agreements the service provider may not
want to disclose to an eavesdropper or an unauthorized user agent.
It is important to secure the communication between the proxy and the
user agent (for session-specific policies) as well as the user agent
and the policy server. The following four discrete attributes need
to be protected:
1. integrity of the policy server URI (for session-specific
policies),
2. authentication of the policy server and, if needed, the user
agent,
3. confidentiality of the messages exchanged between the user agent
and the policy server and
4. ensuring that private information is not exchanged between the
two parties, even over an confidentiality-assured and
authenticated session.
To protect the integrity of the policy server URI, a UA SHOULD use a
secured transport protocol such as TLS between proxies and the UA.
Protecting the integrity of the policy server URI is important since
an attacker could intercept SIP messages between the UA and the proxy
and remove the policy headers needed for session-specific policies.
This would impede the rendezvous between UA and policy server and,
since the UA would not contact the policy server, may prevent a UA
from setting up a session.
Instead of removing a policy server URI, an attacker can also modify
the policy server URI and point the UA to a compromised policy
server. To prevent such an attack from being effective, it is
RECOMMENDED that a UA authenticates policy servers.
Policy servers SHOULD authenticate UAs to protect the information
that is contained in a session policy. However, a policy server may
also frequently encounter UAs it cannot authenticate. In these
cases, the policy server MAY provide a generic policy that does not
reveal sensitive information to these UAs.
It is RECOMMENDED that administrators use SIPS URIs as policy server
URIs so that subscriptions to session policies are transmitted over
Hilt, et al. Expires August 13, 2007 [Page 23]
Internet-Draft Session Policy Framework February 2007
TLS.
The above security attributes are important to protect the
communication between the user agent and policy server. This
document does not define the protocol used for the communication
between user agent and policy server and merely refers to other
specifications for this purpose. The security considerations of
these specifications need to address the above security aspects.
6. IANA Considerations
6.1. Registration of the "Policy-Id" Header
Name of Header: Policy-Id
Short form: none
Normative description: Section 4.4.7 of this document
6.2. Registration of the "Policy-Contact" Header
Name of Header: Policy-Contact
Short form: none
Normative description: Section 4.4.7 of this document
6.3. Registration of the "policy" SIP Option-Tag
Name of option: policy
Description: Support for the Policy-Contact and Policy-Id headers.
SIP headers defined: Policy-Contact, Policy-Id
Normative description: This document
Appendix A. Acknowledgements
Many thanks to Allison Mankin for the discussions and the suggestions
for this draft and to Roni Even, Bob Penfield, Mary Barnes and Shida
Schubert for reviewing the draft and providing feedback. Many thanks
to Vijay Gurbani for the comments and feedback.
Hilt, et al. Expires August 13, 2007 [Page 24]
Internet-Draft Session Policy Framework February 2007
Appendix B. Session-Specific Policies - Call Flows
The following call flows illustrate the overall operation of session-
specific policies including the policy channel protocol as defined in
[2].
The following abbreviations are used:
o: offer
o': offer modified by a policy
po: offer policy
a: answer
a': answer modified by a policy
pa: answer policy
ps uri: policy server URI (in Policy-Contact header)
ps id: policy server id (in Policy-Id header)
B.1. Offer in Invite
Hilt, et al. Expires August 13, 2007 [Page 25]
Internet-Draft Session Policy Framework February 2007
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV <o> | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE <o> | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY <po> | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id, o'>| | | |
|-------->| | | | |
| |(9) INV <o'> | | |
| |---------------------------->| |
| | | | |(10) INV <o', ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o', a>
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po, pa>
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <a'>
| | | | |<--------|
| |(16) 200 OK <a'> | | |
| |<----------------------------| |
|(17) 200 OK <a'> | | | |
|<--------| | | | |
|(18) ACK | | | | |
|------------------------------------------------>|
|(19) SUBSCRIBE <o', a'> | | |
|------------------>| | | |
|(20) 200 OK | | | |
|<------------------| | | |
|(21) NOTIFY <pa> | | | |
|<------------------| | | |
|(22) 200 OK | | | |
|------------------>| | | |
| | | | | |
| | | | | |
Hilt, et al. Expires August 13, 2007 [Page 26]
Internet-Draft Session Policy Framework February 2007
B.2. Offer in Response
UA A P A PS A PS B P B UA B
| | | | | |
|(1) INV | | | | |
|-------->| | | | |
|(2) 488 <ps uri> | | | |
|<--------| | | | |
|(3) ACK | | | | |
|-------->| | | | |
|(4) SUBSCRIBE | | | |
|------------------>| | | |
|(5) 200 OK | | | |
|<------------------| | | |
|(6) NOTIFY | | | |
|<------------------| | | |
|(7) 200 OK | | | |
|------------------>| | | |
|(8) INV <ps id> | | | |
|-------->| | | | |
| |(9) INV | | | |
| |---------------------------->| |
| | | | |(10) INV <ps uri>
| | | | |-------->|
| | | |(11) SUBSCRIBE <o> |
| | | |<------------------|
| | | |(12) 200 OK |
| | | |------------------>|
| | | |(13) NOTIFY <po> |
| | | |------------------>|
| | | |(14) 200 OK |
| | | |<------------------|
| | | | |(15) 200 OK <o'>
| | | | |<--------|
| |(16) 200 OK <o'> | | |
| |<----------------------------| |
|(17) 200 OK <o'> | | | |
|<--------| | | | |
|(18) SUBSCRIBE <o', a> | | |
|------------------>| | | |
|(19) 200 OK | | | |
|<------------------| | | |
|(20) NOTIFY <po, pa> | | |
|<------------------| | | |
|(21) 200 OK | | | |
|------------------>| | | |
|(22) ACK <a'> | | | |
|------------------------------------------------>|
Hilt, et al. Expires August 13, 2007 [Page 27]
Internet-Draft Session Policy Framework February 2007
| | | |(23) SUBSCRIBE <o', a'>
| | | |<------------------|
| | | |(24) 200 OK |
| | | |------------------>|
| | | |(25) NOTIFY <po, pa>
| | | |------------------>|
| | | |(26) 200 OK |
| | | |<------------------|
| | | | | |
| | | | | |
7. References
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-ietf-sipping-policy-package-03 (work in progress),
January 2007.
[3] Hilt, V., Camarillo, G., and J. Rosenberg, "A User Agent Profile
Data Set for Media Policy",
draft-ietf-sipping-media-policy-dataset-02 (work in progress),
October 2006.
[4] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-10 (work in progress),
January 2007.
[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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
Hilt, et al. Expires August 13, 2007 [Page 28]
Internet-Draft Session Policy Framework February 2007
[9] 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.
Authors' Addresses
Volker Hilt
Bell Labs/Alcatel-Lucent
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 August 13, 2007 [Page 29]
Internet-Draft Session Policy Framework February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hilt, et al. Expires August 13, 2007 [Page 30]
| PAFTECH AB 2003-2026 | 2026-04-23 09:36:02 |