One document matched: draft-hilt-sipping-session-spec-policy-01.txt
Differences from draft-hilt-sipping-session-spec-policy-00.txt
Session Initiation Proposal V. Hilt
Investigation Working Group Bell Labs/Lucent Technologies
Internet-Draft G. Camarillo
Expires: April 24, 2005 Ericsson
J. Rosenberg
Cisco Systems
October 24, 2004
A Framework for Session-Specific Session Policies in the Session
Initiation Protocol (SIP)
draft-hilt-sipping-session-spec-policy-01
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 24, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This specification defines a framework for session-specific policies
in Session Initiation Protocol (SIP) sessions. It enables
intermediaries to request the use of policies in a SIP session and
Hilt, et al. Expires April 24, 2005 [Page 1]
Internet-Draft Session-Specific Policy Framework October 2004
defines the transport mechanisms needed for creating and delivering
policies on a per-session basis.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 6
4.1 Offer in Request . . . . . . . . . . . . . . . . . . . . . 6
4.2 Offer in Response . . . . . . . . . . . . . . . . . . . . 7
5. Distributing Policy Server URIs . . . . . . . . . . . . . . . 9
5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . 12
5.4 Header Definition and Syntax . . . . . . . . . . . . . . . 12
6. Policy Channel . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Updating Policies . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 17
Hilt, et al. Expires April 24, 2005 [Page 2]
Internet-Draft Session-Specific Policy Framework October 2004
1. Introduction
Some domains have policies in place, which impact the sessions
established using the Session Initiation Protocol (SIP). These
policies are often needed to support the network infrastructure or
the execution of services. For example, wireless networks usually
have limited resources for media traffic. During periods of high
activity, a wireless network provider may want to restrict codec
usage on the network to lower rate codecs.
In another example, a SIP user agent is using a network which
connects to the public Internet through a firewall at the network
edge. The provider would like to tell the user agent to direct the
media streams to the appropriate open ip/ports on that firewall.
Knowing this policy enables these user agents to setup sessions with
user agents on the public Internet.
In a third example, a domain A has a limited bandwidth pipe to
another domain B. The pipe is realized through two routers that are
managed. Domain A would like to direct each call to one of the
routers based on their capacity. With session policies, the domain
can inform the user agent about the route with the most capacity
available.
Domains sometimes enforce policies they have in place. For example,
a domain might have a configuration in which all packets containing a
certain audio codec are dropped. Unfortunately, enforcement
mechanisms usually do not inform the user about the policies they are
enforcing and silently keep the user from doing anything against
them. This may lead to the malfunctioning of devices that is
incomprehensible to the user. With session policies, the user knows
about the restricted codecs and can use a different codec or simply
connect to a domain with less stringent policies. Session policies
provide an important combination of consent coupled with enforcement.
That is, the user becomes aware of the policy and needs to act on it,
but the provider still retains the right to enforce the policy.
This specification defines a framework for delivering
session-specific policies to user agents. Session-specific policies
are conveyed to user agents on a per session basis. They are created
with knowledge about the details of a session that is being
established and apply only to this session. This framework defines
mechanisms to announce the presence of session-specific policy
servers to user agents. It defines a protocol for user agents to
submit session details to a policy server in a secure way and to
deliver policies for this session in response.
Session policies that are independent of a certain session and
Hilt, et al. Expires April 24, 2005 [Page 3]
Internet-Draft Session-Specific Policy Framework October 2004
generally apply to the sessions of a user agent can be delivered
using the framework for session-independent policies [4]. The
current situation in imposing session policies and the drawbacks of
these practices as well as the requirements for a session policy
solution are discussed in [5].
Note: The difference between session-independent and
session-specific policies needs to be discussed here.
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. Architecture
+-------------+
/------| Proxy |----...
+----+ / +-------------+
| |---/ +-------------+
| | | Policy |
| UA |============| Server |
| | +-------------+
| |**** +-------------+
+----+ * | Router w/ |
*******| Policy |****...
| Enforcement |
+-------------+
--- SIP Signaling
=== Policy Channel
*** Media
Figure 1
This framework enables a network domain to set up policies for
specific SIP sessions. The following entities are involved in
setting up session-specific policies (see Figure 1): a user agent, a
proxy, a policy server and possibly a router acting as policy
enforcement point. The proxy's role is to convey the URI of the
policy server in its domain to user agents. The proxy does not
provide the actual policies. It merely ensures that the user agents
know where to retrieve policies from.
A policy server is a separate logical entity that may be physically
Hilt, et al. Expires April 24, 2005 [Page 4]
Internet-Draft Session-Specific Policy Framework October 2004
co-located with the proxy. Each domain has one policy server. Its
task is to deliver session policies to user agents. The policy
server and the user agent communicate through an end-to-end channel.
A policy-enabled user agent receives the URI of a policy server from
the proxy. The user agent contacts this policy server and retrieves
session policies. The user agent may provide information about the
current session to the policy server and may receive session policies
in response. It is also possible for the policy server to update the
policies asynchronously during the course of a session and to receive
a notification when the session is terminated.
A network may have routers in place, which enforce session policies
acting as policy enforcement points. This specification assumes that
enforcement points, if they are present, have knowledge about the
current policies and their enforcement. The goal of this framework
is to support enforcement points by informing user agents about the
current policies helping them to avoid policy violations.
Note: The reasoning for the separate channel model needs to be
discussed here.
The communication between a user agent and a policy server to set up
session-specific policies involves two main operations:
1. The UA disclose information about the current session and the
offer/answer exchange to a policy server.
2. The policy server sends instructions to the UA.
Some types of policies do not involve sending instructions, but only
information disclosure. Still, a general session-specific policy
mechanism needs to support both operations.
The same way, some policy servers only need to inspect the offer, but
not the answer. Nevertheless, a general mechanism needs to consider
policy servers which need to inspect both.
OPEN ISSUE: Is the inspection of the answer needed or can it be
avoided (on a case-by-case basis or even in general) for
simplification purposes.
Finally, some policy servers need to asynchronously update session
policies or need to receive a notification when a session is
terminated. For example, a policy server managing firewalls may want
to free resources once a session is terminated. A general mechanism
needs to enable these interactions between policy server and user
agent.
Hilt, et al. Expires April 24, 2005 [Page 5]
Internet-Draft Session-Specific Policy Framework October 2004
4. Overview of Operation
The section provides example call flows to illustrate the
establishment of session policies. It does not contain a normative
protocol definition.
In this scenario, there are two domains (domain A and B), which both
have session-specific policies for the UAs in their domain. Both do
not provide session 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 two policy servers have policies for the session
description offer and answer.
4.1 Offer in Request
The first call flow depicts an INVITE transaction with the offer in
the request. It is assumed that UAC does not have previous knowledge
about the policy server in its domain.
UA A creates an INVITE that is routed to proxy P A. P A knows that
policies apply to this session. It rejects the INVITE and delivers
the URI of PS A to UA A. UA A contacts PS A, discloses information
about the session description offer to PS A and receives policies for
the offer. P A does not reject the second INVITE since the UAC has
now included a token, which it has received from PS A along with the
policies, in the Policy-Id header. P A removes the Policy-Id header
when forwarding the INVITE. P B provides the URI of PS B to UA B in
the Policy-Contact header. UA B contacts PS B, discloses information
about the offer and the answer it is about to return to the UA A. It
receives policies for the offer and answer. It applies these
policies and returns the answer in the 200 OK. Finally, UA A
contacts PS A with the answer and retrieves policies from PS A.
UA A P A P B UA B
| | | |
| | | |
| INVITE offer | | |
|---------------->| | |
| 488 | | |
| + Policy-Contact| | |
|<----------------| | |
| ACK | | |
|---------------->| | |
| | PS A | |
| | | |
| PolicyChannel | | |
| + InfoOffer | | |
|------------------->| | |
Hilt, et al. Expires April 24, 2005 [Page 6]
Internet-Draft Session-Specific Policy Framework October 2004
| PolicyChannel | | |
| + PolicyOffer | | |
|<-------------------| | |
| | | |
| | | |
| INVITE offer' | INVITE offer' | INVITE offer |
| + Policy-Id | | + Policy-Contact|
|---------------->|--------------->|---------------->|
| | | |
| | PS B | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer |
| | | + InfoAnswer |
| | |<-------------------|
| | | PolicyChannel |
| | | + PolicyOffer |
| | | + PolicyAnswer |
| | |------------------->|
| | | |
| | | |
| OK answer | OK answer | OK answer |
|<----------------|<---------------|<----------------|
| ACK |
|--------------------------------------------------->|
| | | |
| | | |
| PolicyChannel | | |
| + InfoAnswer | | |
|------------------->| | |
| PolicyChannel | | |
| + PolicyAnswer | | |
|<-------------------| | |
| | | |
Figure 2
4.2 Offer in Response
This call flow depicts an INVITE transaction with the offer in the
response.
The steps in this call flow are similar to the steps in the previous
flow. An important difference is that UA A now contacts PS A after
receiving an offer in the 200 OK and before returning the answer in
the ACK. This approach is discussed in more detail in the sections
below.
Hilt, et al. Expires April 24, 2005 [Page 7]
Internet-Draft Session-Specific Policy Framework October 2004
UA A P A P B UA B
| | | |
| | | |
| INVITE offer | | |
|---------------->| | |
| 488 | | |
| + Policy-Contact| | |
|<----------------| | |
| ACK | | |
|---------------->| | |
| | PS A | |
| | | |
| PolicyChannel | | |
|------------------->| | |
| PolicyChannel | | |
|<-------------------| | |
| | | |
| | | |
| INVITE | INVITE | INVITE |
| + Policy-Id | | + Policy-Contact|
|---------------->|--------------->|---------------->|
| | | |
| | PS B | |
| | | |
| | | PolicyChannel |
| | | + InfoOffer |
| | |<-------------------|
| | | PolicyChannel |
| | | + PolicyOffer |
| | |------------------->|
| | | |
| | | |
| OK offer | OK offer | OK offer |
|<----------------|<---------------|<----------------|
| | | |
| | | |
| PolicyChannel | | |
| + InfoOffer | | |
| + InfoAnswer | | |
|------------------->| | |
| PolicyChannel | | |
| + PolicyOffer | | |
| + PolicyAnswer | | |
|<-------------------| | |
| | | |
| ACK answer |
|--------------------------------------------------->|
| | | |
Hilt, et al. Expires April 24, 2005 [Page 8]
Internet-Draft Session-Specific Policy Framework October 2004
| | | |
| | | PolicyChannel |
| | | + InfoAnswer |
| | |<-------------------|
| | | PolicyChannel |
| | | + PolicyAnswer |
| | |------------------->|
| | | |
Figure 3
5. Distributing Policy Server URIs
The first step in setting up policies for a session is to convey the
URIs of policy servers to the UAs, which may have policies for the
current session. The policy server URIs need to be conveyed to the
UAs in the initial INVITE that sets up the session as well as in
re-INVITEs and UPDATEs during the session.
5.1 UAC Behavior
When a UA compliant to this specification generates an INVITE or
UPDATE request, it MUST include the Supported header field with the
option tag "policy" in the request.
A UA that supports session-specific policies SHOULD cache the URI of
the policy server in the local domain. It receives this URI from the
local proxy after sending an INVITE or UPDATE request. The UAC
SHOULD use the cached policy server URI to retrieve session policies
before sending subsequent INVITE or UPDATE requests. Contacting the
local policy server before sending a request avoids the
retransmission of the policy server URI for every new request.
The UA SHOULD NOT cache policy server URIs that are outside of the
local domain since these servers may not be relevant for new sessions
a UA sets up. A new session might traverse different networks and
have a different destination. Some policies require that the request
is routed in part to a proxy before policies can be provided by a
policy server. A proxy marks the URI of such policy servers as
non-cacheable when providing them to the UA. The UA SHOULD NOT cache
a non-cacheable policy server URI and SHOULD remove the current URI
from the cache when it receives one. In addition, a UA SHOULD NOT
cache policy server URIs it receives when acting as UAS.
If the UAC generates a re-INVITE or UPDATE request within an existing
session, it SHOULD contact all policy server URIs it has contacted
when generating the previous INVITE or UPDATE request in this session
Hilt, et al. Expires April 24, 2005 [Page 9]
Internet-Draft Session-Specific Policy Framework October 2004
before sending the new request.
The UAC receives a token from each policy server it has successfully
contacted when generating a INVITE or UPDATE request. The UAC must
include this token into the request. This enables a proxy to
determine whether the UAC has already contacted the local policy
server for this request or whether the policy server URI still needs
to be conveyed to the UAC. The UAC MUST include all tokens it has
received when generating a request into the Policy-Id header field.
If it has not received a token, for example, because the policy
server was unreachable, the UAC SHOULD use the policy server URI as
the token. If no policy server has been contacted for a request, the
UAC SHOULD NOT include a Policy-Id field. The syntax of the
Policy-Id header is defined in Section 5.4.
The creation of policy server tokens is out of scope for this
specification. The token needs to enable a proxy to verify that
the policy server in its domain is known to the UAC and has
successfully been contacted.
The UAC may receive a 488 response with a Policy-Contact header
field. The Policy-Contact header contains a policy server URI. The
UAC SHOULD use this URI to retrieve session policies for the current
request. It should re-try the request after applying the received
policies. The UAC MUST add the token it receives from this policy
server to the Policy-Id header field. The UAC should cache the
policy server URI if the policy server is in the same domain as the
UAC and the Policy-Contact header does not contain the header field
parameter "non-cacheable". The syntax of the Policy-Contact header
is defined in Section 5.4.
If the UAC has received multiple 488 responses for the same request,
it MUST use the policy server URIs in the order in which the 488
responses were received. The UAC MUST contact the first policy
server and apply the received policies before contacting the next
server. When it discloses session information to a policy server, it
MUST use the most recent session information that considers the
policies received previously. This ensures that policy servers are
contacted in the order in which the request travels through the
proxies. The order in which policy servers are contacted and session
policies are applied to a session is significant for the final result
of the policy process. For example, a policy for NAT traversal
requires that the policy server can examine the IP address on which
the media stream will be sent/received in the previous domain.
If required by the policy, the UAC should contact the policy servers
again after receiving a 2xx response. In this case, the UAC MUST
contact the same policy servers it has contacted for the successful
Hilt, et al. Expires April 24, 2005 [Page 10]
Internet-Draft Session-Specific Policy Framework October 2004
request.
If the 2xx to an INVITE request contains a session description answer
(i.e. the UAC did include an offer in the request), the UAC MUST
send the ACK before it contacts the policy servers. If however the
2xx to an INVITE request contains an offer and the UAC must respond
with an answer, the UAC MUST first contact the policy servers before
sending the ACK. A policy server must respond immediately to
requests on the policy channel (see Section 6). The UAC uses these
policies to formulate an answer and ships this answer in the ACK.
This is analogous to call flow I defined in [7].
OPEN ISSUE: Retrieving policies from the policy server before
sending the ACK may delay the transmission of the ACK and trigger
retransmissions of the 2xx by the UAS. An alternative approach is
to generate a preliminary answer without contacting a policy
server and return this answer in the ACK. The UAC then contacts
the policy servers after the ACK has been sent. If the retrieved
policies change the preliminary answer, the UAC must generate a
new UPDATE request which contains an offer that considers these
policies. This offer effectively replaces the preliminary answer
sent in the ACK.
The advantage of contacting the policy server after sending the
ACK is that it avoids 2xx retransmissions caused by policy servers
not responding in time. A disadvantage is that the preliminary
answer might trigger the use of policy enforcement mechanisms
since it may not be compliant with policies.
The advantage of contacting the policy server before sending the
ACK is simplicity. There is no overhead for updating the session
description answer in policed sessions. A drawback is that
retransmissions of 2xx may occur in cases where the UAC needs to
contact a number of policy servers or policy servers respond
poorly. However, such configurations are problematic in general
and should be avoided. If they occur, the number of 2xx
retransmissions and the overhead associated with them is however
usually very small.
A policy may require the UAC to contact the policy server when a
session is terminated. In this case, the UAC MUST contact the same
policy server URIs it has used for the last successful request within
this session, when the session is terminated.
5.2 UAS Behavior
If an incoming INVITE or UPDATE request includes a Policy-Contact
header containing a list of policy server URIs, the UAS SHOULD use
Hilt, et al. Expires April 24, 2005 [Page 11]
Internet-Draft Session-Specific Policy Framework October 2004
these URIs to retrieve session policies. The UAS MUST use the policy
server URIs in the order they were contained in the Policy-Contact
header, starting with the topmost value.
If the UAS receives an ACK with a session description answer, it may
need to contact the policy servers again. In this case, it MUST
contact the same policy servers it has contacted after receiving the
corresponding INVITE request.
A policy may require the UAS to contact the policy server when a
session is terminated. In this case, the UAS MUST contact the same
policy server URIs it has used for the last successful request within
this session, when the session is terminated.
5.3 Proxy Behavior
A proxy may provide the contact URI of the local policy server to the
UAC or the UAS when processing a INVITE or UPDATE request.
If a 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 policy server URI to the UAC. If the request
contains a Policy-Id header field, the proxy MUST determine if it
contains a token identifying the local policy server. If such a
token is not present or if the Policy-Id header field is not present,
the proxy MAY reject the request with a 488. The proxy MUST include
a Policy-Contact header in the 488 with the URI of the local policy
server as the value. Some policies require that the request is
routed in part to a proxy before policies can be provided to the UAC.
If this is the case, the proxy SHOULD add the header field parameter
"non-cacheable" to the Policy-Contact header. This will prevent the
UAC from contacting the policy server before the request is sent.
A token from the local policy server in the Policy-Id header
indicates that the UAC has already contacted the policy server for
this request. In this case, the proxy SHOULD remove the token from
the Policy-Id header before forwarding the request.
The proxy MAY insert a Policy-Contact header field into a INVITE or
UPDATE request in order to provide 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.
5.4 Header Definition and Syntax
The Policy-Id header field is inserted into a INVITE or UPDATE
Hilt, et al. Expires April 24, 2005 [Page 12]
Internet-Draft Session-Specific Policy Framework October 2004
request by the UAC. It identifies all policy servers the UAC has
contacted for the request. A Policy-Id header value can either be a
token that identifies a policy server to the proxy in the same domain
or the URI of a policy server.
The syntax of the Policy-Id header field is:
Policy-Id = "Policy-Id" HCOLON pol-id-params
*(COMMA pol-id-params)
pol-id-params = token / 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 inserted into 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 [8].
Table 1 is an extension of Tables 2 and 3 in [8]. The column 'UPD'
is for the UPDATE method [6].
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
Hilt, et al. Expires April 24, 2005 [Page 13]
Internet-Draft Session-Specific Policy Framework October 2004
6. Policy Channel
A UA and policy server compliant with this specification MUST use the
mechanism defined in this section for the policy channel.
[TBD.]
OPEN ISSUE: The policy channel mechanism needs to be defined. One
option is the use of a SUBSCRIBE/NOTIFY based mechanism. It would
allow policy servers to deliver the initial policies and
asynchronously update those policies if needed. This would
however require the use of SDP announcements as filter in the
SUBSCRIBE request, which is a debatable approach.
7. Updating Policies
A UA may receive policy updates through a policy channel. The UA
SHOULD apply these policies to the current session. It MUST generate
a re-INVITE or UPDATE request if the updated policies modify aspects
of the session that need to be communicated to the peer UA.
8. Security Considerations
In particular authentication and authorization are critical issues
that need to be addressed here.
[TBD.]
9. IANA Considerations
[TBD.]
10 References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667,
February 2004.
[3] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[4] Hilt, V., Camarillo, G. and J. Rosenberg, "Session-Independent
Session Initiation Protocol (SIP) Policies - Profile Data and
Mechanisms", draft-ietf-sipping-session-indep-policy-01 (work in
progress), October 2004.
Hilt, et al. Expires April 24, 2005 [Page 14]
Internet-Draft Session-Specific Policy Framework October 2004
[5] Rosenberg, J., "Requirements for Session Policy for the Session
Initiation Protocol (SIP)",
draft-ietf-sipping-session-policy-req-02 (work in progress),
July 2004.
[6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[7] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April
2004.
[8] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
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@dynamicsoft.com
Hilt, et al. Expires April 24, 2005 [Page 15]
Internet-Draft Session-Specific Policy Framework October 2004
Appendix A. Acknowledgements
Many thanks to Allison Mankin for the discussions and the suggestions
for this draft.
Hilt, et al. Expires April 24, 2005 [Page 16]
Internet-Draft Session-Specific Policy Framework October 2004
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 (2004). 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 24, 2005 [Page 17]| PAFTECH AB 2003-2026 | 2026-04-22 22:58:03 |