is specified in Section 10. Note that a compact form, using the
letter d, has been defined. The directives are grouped into types.
There can only be one directive of each type per request (e.g., you
cannot have both "proxy" and "redirect" in the same Request-
Disposition header field).
When the caller specifies a directive, the server SHOULD honor that
directive.
The following types of directives are defined:
proxy-directive: This type of directive indicates whether the caller
would like each server to proxy ("proxy") or redirect
("redirect").
cancel-directive: This type of directive indicates whether the caller
would like each proxy server to send a CANCEL request downstream
("cancel") in response to a 200 OK from the downstream server
(which is the normal mode of operation, making it redundant), or
whether this function should be left to the caller ("no-cancel").
If a proxy receives a request with this parameter set to "no-
cancel", it SHOULD NOT CANCEL any outstanding branches upon
receipt of a 2xx. However, it would still send CANCEL on any
outstanding branches upon receipt of a 6xx.
fork-directive: This type of directive indicates whether a proxy
should fork a request ("fork"), or proxy to only a single address
("no-fork"). If the server is requested not to fork, the server
SHOULD proxy the request to the "best" address (generally the one
with the highest q-value). If there are multiple addresses with
the highest q-value, the server chooses one based on its local
policy. The directive is ignored if "redirect" has been
requested.
recurse-directive: This type of directive indicates whether a proxy
server receiving a 3xx response should send requests to the
addresses listed in the response ("recurse"), or forward the list
of addresses upstream towards the caller ("no-recurse"). The
directive is ignored if "redirect" has been requested.
parallel-directive: For a forking proxy server, this type of
directive indicates whether the caller would like the proxy server
to proxy the request to all known addresses at once ("parallel"),
or go through them sequentially, contacting the next address only
after it has received a non-2xx or non-6xx final response for the
previous one ("sequential"). The directive is ignored if
"redirect" has been requested.
queue-directive: If the called party is temporarily unreachable,
e.g., because it is in another call, the caller can indicate that
it wants to have its call queued ("queue") or rejected immediately
("no-queue"). If the call is queued, the server returns "182
Queued". A queued call can be terminated as described in [1].
Example:
Request-Disposition: proxy, recurse, parallel
The set of request disposition directives is not extensible on
purpose. This is to avoid a proliferation of new extensions to SIP
that are "tunneled" through this header field.
9.2. Accept-Contact and Reject-Contact Header Fields
The syntax for these header fields is described in Section 10. A
compact form, with the letter a, has been defined for the Accept-
Contact header field, and with the letter j for the Reject-Contact
header field.
10. Augmented BNF
The BNF for the Request-Disposition header field is:
Request-Disposition = ( "Request-Disposition" / "d" ) HCOLON
directive *(COMMA directive)
directive = proxy-directive / cancel-directive /
fork-directive / recurse-directive /
parallel-directive / queue-directive
proxy-directive = "proxy" / "redirect"
cancel-directive = "cancel" / "no-cancel"
fork-directive = "fork" / "no-fork"
recurse-directive = "recurse" / "no-recurse"
parallel-directive = "parallel" / "sequential"
queue-directive = "queue" / "no-queue"
The BNF for the Accept-Contact and Reject-Contact header fields is:
Accept-Contact = ("Accept-Contact" / "a") HCOLON ac-value
*(COMMA ac-value)
Reject-Contact = ("Reject-Contact" / "j") HCOLON rc-value
*(COMMA rc-value)
ac-value = "*" *(SEMI ac-params)
rc-value = "*" *(SEMI rc-params)
ac-params = feature-param / req-param
/ explicit-param / generic-param
;;feature param from RFC 3840
;;generic-param from RFC 3261
rc-params = feature-param / generic-param
req-param = "require"
explicit-param = "explicit"
Despite the BNF, there MUST NOT be more than one req-param or
explicit-param in an ac-params. Furthermore, there can only be one
instance of any feature tag in feature-param.
11. Security Considerations
The presence of caller preferences in a request has an effect on the
ways in which the request is handled at a server. As a result,
requests with caller preferences SHOULD be integrity-protected with
the sips mechanism specified in RFC 3261, Section 26.
Processing of caller preferences requires set operations and searches
which can require some amount of computation. This enables a DOS
attack whereby a user can send requests with substantial numbers of
caller preferences, in the hopes of overloading the server. To
counter this, servers SHOULD reject requests with too many rules. A
reasonable number is around 20.
12. IANA Considerations
This specification registers three new SIP header fields, according
to the process of RFC 3261 [1].
The following is the registration for the Accept-Contact header
field:
RFC Number: RFC 3841
Header Field Name: Accept-Contact
Compact Form: a
The following is the registration for the Reject-Contact header
field:
RFC Number: RFC 3841
Header Field Name: Reject-Contact
Compact Form: j
The following is the registration for the Request-Disposition header
field:
RFC Number: RFC 3841
Header Field Name: Request-Disposition
Compact Form: d
13. Acknowledgments
The initial set of media feature tags used by this specification were
influenced by Scott Petrack’s CMA design. Jonathan Lennox, Bob
Penfield, Ben Campbell, Mary Barnes, Rohan Mahy, and John Hearty
provided helpful comments. Graham Klyne provided assistance on the
usage of RFC 2533.
14. References
14.1. Normative References
[1] 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.
[2] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
2533, March 1999.
[3] Rosenberg, J., Schulzrinne, J., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[6] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[7] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262, June
2002.
[8] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[9] Campbell, B., Ed., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[10] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
14.2. Informative References
[11] Lennox, J. and H. Schulzrinne, "Call Processing Language
Framework and Requirements", RFC 2824, May 2000.
[12] Rosenberg, J., "Guidelines for Authors of Extensions to the
Session Initiation Protocol (SIP)", Work in Progress, November
2002.
[13] Holtman, K., Muntz, A., and T. Hardie, "Media Feature Tag
Registration Procedure", BCP 31, RFC 2506, March 1999.
15. Authors’ Addresses
Jonathan Rosenberg
dynamicsoft
600 Lanidex Plaza
Parsippany, NJ 07054
US
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
URI: http://www.jdrosen.net
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027
US
EMail: schulzrinne@cs.columbia.edu
URI: http://www.cs.columbia.edu/~hgs
Paul Kyzivat
Cisco Systems
1414 Massachusetts Avenue
BXB500 C2-2
Boxboro, MA 01719
US
EMail: pkyzivat@cisco.com
16. Full 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.
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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.