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 © The IETF Trust (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
2.  Typical Failure Cases
    2.1.  Call Rejection
    2.2.  Do Not Disturb
    2.3.  Ringing Groups
3.  Steps to Be Taken
4.  Possible Useful Semantics for 6xx Class Responses
5.  IANA Considerations
6.  Security Considerations
7.  Normative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Statement of the Problem

The specification of the Session Initiation Protocol (SIP) [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.): 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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.):

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:

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.

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.

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.

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] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).

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).

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

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.

7. Normative References

Author's Address

Full Copyright Statement

Copyright © 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).