SIP D. Worley
Internet-Draft Pingtel
Expires: August 27, 2007 February 23, 2007
6xx-Class Responses Considered Harmful in the Session Initiation
Protocol (SIP)
draft-worley-6xx-considered-harmful-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Worley Expires August 27, 2007 [Page 1]
Internet-Draft 6xx Considered Harmful February 2007
Abstract
The specification of the Session Initiation Protocol (SIP) permits a
user agent (UA) that receives a call to generate a response in the
"6xx class" that not only rejects the call but also requires the
termination of all attempts to route the call to alternative
destinations. As the call may have reached the UA through multiple
forwardings whose meanings cannot be known by the UA, the global
termination of alternative routing can only rarely be correctly
requested by the UA. Because such responses are almost never
appropriate, ability of a UA to generate such responses is harmful,
and all 6xx class responses should be replaced with 4xx class
responses with similar meanings. However, there is no 4xx class
response similar to "603 Decline", and so one needs to be created.
Table of Contents
1. Statement of the Problem . . . . . . . . . . . . . . . . . . . 3
2. Typical Failure Cases . . . . . . . . . . . . . . . . . . . . 5
2.1. Call Rejection . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Do Not Disturb . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Ringing Groups . . . . . . . . . . . . . . . . . . . . . . 5
3. Steps to Be Taken . . . . . . . . . . . . . . . . . . . . . . 6
4. Possible Useful Semantics for 6xx Class Responses . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Worley Expires August 27, 2007 [Page 2]
Internet-Draft 6xx Considered Harmful February 2007
1. Statement of the Problem
The specification of the Session Initiation Protocol (SIP) [1]
permits a user agent (UA) that receives a call (that is, receives an
out-of-dialog INVITE) to generate a response in the "6xx class". A
response of this type not only only rejects the call but also
requires the termination of all attempts to route the call to
alternative destinations, due to the rules of section 16.7 items 5
and 6 of [1]: When a proxy receives a 6xx class response, it must
cancel all other forks of the transaction and forward the 6xx class
response upstream. As the 6xx class response proceeds back to the
UAC, all other forks of the call are canceled.
(Note that the consequences of a 6xx class response are rigidly
defined by section 16.7, and do not always match the description of
secton 21.6 of [1]:
21.6 Global Failures 6xx
6xx responses indicate that a server has definitive information
about a particular user, not just the particular instance
indicated in the Request-URI.
6xx responses give definitive instructions regarding all destinations
of a call, not just those pertaining to a particular user.)
However, the call may have reached the UA through multiple
forwardings whose meanings cannot be known by the UA, and can only
sometimes be known by the user (if the user recognizes the "To"
header URI and has positive knowledge of all forks of its routing).
Nonetheless, the 6xx class response from one destination UA prevents
the SIP network from attempting to deliver the call to any other UA.
As a result, there is a serious risk that the specified effect of the
6xx class response is an incorrect implementation of the desires of
the users involved, as the caller may be willing to accept
communication with the user at an alternative fork, and the callee
who gave the 6xx class response may not wish to prevent contact with
the alternative user (or may not have authority to forbid it).
The best immediate solution of this problem is for UAs to not
generate 6xx class responses under any circumstances, but instead
generate 4xx class responses with similar meanings. 4xx class
responses only cause termination of the fork of the request which
reached the UA and permit alternative forks to proceed, thus
eliminating this problem.
There are four defined 6xx class responses, of which three have
reasonable 4xx class equivalents:
Worley Expires August 27, 2007 [Page 3]
Internet-Draft 6xx Considered Harmful February 2007
600 Busy Everywhere - can be replaced by 486 Busy Here
603 Decline - no 4xx class equivalent
604 Does Not Exist Anywhere - 410 Gone has a very similar
definition (these responses are part of the morass of overlapping
"cannot reach resource" responses)
606 Not Acceptable - can be replaced by 488 Not Acceptable Here
Thus, to fully alleviate this problem requires defining a new 4xx
class response meaning "Decline Here" (with the tentative proposed
response code 441):
441 Decline
The callee's machine was successfully contacted but the user
explicitly does not wish to or cannot participate. The response
MAY indicate a better time to call in the Retry-After header
field.
Worley Expires August 27, 2007 [Page 4]
Internet-Draft 6xx Considered Harmful February 2007
2. Typical Failure Cases
2.1. Call Rejection
SIP-based PBX systems often provide voicemail for users. This is
usually implemented by having each address-of-record (AOR) forward to
two contact URIs: with higher priority, the URI of the user's phone,
and with lower priority, a voicemail service. An incoming call will
be routed by the domain's proxy first to the user's phone, and if
that fork does not result in a successful call, it will then route
the call to the voicemail system to allow the caller to record a
message.
A popular make of SIP hardware telephone provides a "Reject" function
which defeats such routing to a voicemail system. When a call
arrives and the phone alerts the user, the user can press the
"Reject" button to not answer the call and stop the alerting.
Unfortunately, this function generates a 603 Decline response, which
prevents the proxy from forwarding the call to the voicemail system.
The ideal solution in this circumstance would be to generate a 441
Decline Here response.
2.2. Do Not Disturb
The same phone as described in the previous section has a "Do Not
Disturb" mode. When the phone is in "Do Not Disturb" mode, incoming
requests do not cause alerting of the user. Instead, the call is
immediately rejected. Unfortunately, the call is rejected with a 603
Decline response, which again has the problem that the call will not
be routed to the user's voicemail service (if one is configured).
2.3. Ringing Groups
In many circumstances, it is convenient to configure SIP AORs that
parallel fork to multiple UAs to allow more than one user the
opportunity to answer the call. In such cases, having one UA
generate a 6xx class response to a call that was made to a group AOR
is undesirable, as the user of the UA rarely has complete knowledge
of what UAs have been contacted or the status of their users.
Worley Expires August 27, 2007 [Page 5]
Internet-Draft 6xx Considered Harmful February 2007
3. Steps to Be Taken
1. Define response code meaning "Decline Here" to be used as a
replacement for "603 Decline (Everywhere)".
2. Deprecate 6xx class responses, and change proxy requirements to
permit proxies to handle them similarly to 4xx class responses.
3. Convince user agent implementors to use 4xx class responses in
preference to 6xx class responses.
Worley Expires August 27, 2007 [Page 6]
Internet-Draft 6xx Considered Harmful February 2007
4. Possible Useful Semantics for 6xx Class Responses
However, with suitable redefinition, 6xx class responses might be
useful in some circumstances. The circumstance is to use 6xx to
signal that the call should not contact any other UA within some
particular defined forking context containing the UA that generated
the 6xx response. The forking context would contain only UAs which
the user has authority over. This redefinition could bring the
behavior of 6xx class responses into line with the meaning of section
21.6 of [1].
One possible example is the case described above, with the forking
context being the user's phone and his voicemail server. In such a
case, the user has the authority to reject a call in a way that
instructs the proxy to not attempt to forward the call to the
voicemail server either. (Although it is unlikely that this should
be the default or standard way to reject a call.)
Another example is within a defined ringing group, where any user
within the ringing group has the authority to reject an incoming call
on behalf of all members of the ringing group. (Again, it is
unlikely that this will be a common operation.)
In any such case, the proxy whose forking defines the forking context
would process a 6xx class response by: (1) canceling any other forks
of the call that it has generated, (2) not generating any other forks
for the call, but (3) forwarding a 4xx class response back toward the
UAC.
The difficulty with configuring a SIP network to provide this
behavior is in ensuring that mis-configuration doesn't cause a 6xx
class response to "escape", to be taken as authoritative over forks
over which the user does not have authority. It appears that the way
to avoid this is to have all proxies by default treat 6xx class
responses as 4xx responses, including translating them into 4xx
responses for forwarding upstream. But it would also be possible to
configure a proxy treat a 6xx class response as it is currently
defined (if the fork target is authoritative for the request-URI that
is being expanded) and to forward the 6xx class response upstream (if
the proxy believes that the fork target is authoritative for a larger
enclosing context).
Worley Expires August 27, 2007 [Page 7]
Internet-Draft 6xx Considered Harmful February 2007
5. IANA Considerations
This document proposes to register a new response code, namely 441
(Decline Here). The response code would be defined by the following
information:
Response Code Number: 441
Default Reason Phrase: Decline Here
Worley Expires August 27, 2007 [Page 8]
Internet-Draft 6xx Considered Harmful February 2007
6. Security Considerations
Adoption of this change would improve the security of SIP.
Currently, the UA or user at any one fork of a call can cause the
termination of the call to all other forks, even if the user giving
the 6xx class response has no authority over the other UAs or over
the SIP URI whose routing forked to the other UAs.
Worley Expires August 27, 2007 [Page 9]
Internet-Draft 6xx Considered Harmful February 2007
7. 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.
Worley Expires August 27, 2007 [Page 10]
Internet-Draft 6xx Considered Harmful February 2007
Author's Address
Dale R. Worley
Pingtel Corp.
400 West Cummings Park, Suite 2200
Woburn, MA 01801
US
Phone: +1 781 938 5306 x173
Email: dworley@pingtel.com
URI: http://www.pingtel.com
Worley Expires August 27, 2007 [Page 11]
Internet-Draft 6xx Considered Harmful 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).
Worley Expires August 27, 2007 [Page 12]