Look at draft-rajesh-sipping-605-01.txt.

<?xml version='1.0'?>
<!DOCTYPE rfc SYSTEM 'rfcXXXX.dtd'>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc ipr='full3978' category='std' docName='draft-worley-6xx-considered-harmful-00'>

<front>
<title abbrev='6xx Considered Harmful'>
6xx-Class Responses Considered Harmful in the Session Initiation Protocol (SIP)
</title>
<author initials='D.R.' surname='Worley' fullname='Dale R. Worley'>
   <organization abbrev='Pingtel'>
       Pingtel Corp.
   </organization>
   <address>
       <postal>
           <street>400 West Cummings Park, Suite 2200</street>
           <city>Woburn</city>
           <region>MA</region>
           <code>01801</code>
           <country>US</country>
       </postal>
       <phone>+1 781 938 5306 x173</phone>
       <email>dworley@pingtel.com</email>
       <uri>http://www.pingtel.com</uri>
   </address>
</author>
<date month='February' year='2007' />
<area>Transport</area>
<workgroup>SIP</workgroup>
<keyword></keyword>
<abstract>
<t>
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.
</t>
</abstract>
</front>

<middle>

<section title='Statement of the Problem' anchor='problem'>

<t>
The specification of the Session Initiation Protocol (SIP)
<xref target='sip'/> 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 <xref target='sip'/>:
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.
</t>

<t>
(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 <xref target='sip'/>:
<list style='empty'>
<t>
21.6 Global Failures 6xx
</t>
<t>
6xx responses indicate that a server has definitive information about
a particular user, not just the particular instance indicated in the
Request-URI.
</t>
</list>
6xx responses give definitive instructions regarding all destinations
of a call, not just those pertaining to a particular user.)
</t>

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

<t>
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.
</t>

<t>
There are four defined 6xx class responses, of which three have
reasonable 4xx class equivalents:

<list style='empty'>
<t>
600 Busy Everywhere - can be replaced by 486 Busy Here
</t>
<t>
603 Decline - no 4xx class equivalent
</t>
<t>
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)
</t>
<t>
606 Not Acceptable - can be replaced by 488 Not Acceptable Here
</t>
</list>

Thus, to fully alleviate this problem requires defining a new 4xx
class response meaning "Decline Here" (with the tentative proposed
response code 441):

<list style='empty'>
<t>
441 Decline
</t>
<t>
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.
</t>
</list>
</t>

</section>

<section title='Typical Failure Cases' anchor='typical'>

<section title='Call Rejection'>

<t>
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.
</t>

<t>
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.
</t>

<t>
The ideal solution in this circumstance would be to generate a 441
Decline Here response.
</t>

</section>

<section title='Do Not Disturb' anchor='DND'>

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

</section>

<section title='Ringing Groups' anchor='groups'>

<t>
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.
</t>

</section>

</section>

<section title='Steps to Be Taken' anchor='steps'>

<t>
<list style='numbers'>
<t>
Define response code meaning "Decline Here" to be used as a
replacement for "603 Decline (Everywhere)".
</t>
<t>
Deprecate 6xx class responses, and change proxy requirements to permit
proxies to handle
them similarly to 4xx class responses.
</t>
<t>
Convince user agent implementors to use 4xx class responses in
preference to 6xx class responses.
</t>
</list>
</t>

</section>

<section title='Possible Useful Semantics for 6xx Class Responses'
anchor='possible'>

<t>
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 <xref target='sip'/>.
</t>

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

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

<t>
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.
</t>

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

</section>

<section title='IANA Considerations' anchor='IANA'>

<t>
This document proposes to register a new response code, namely 441
(Decline Here).  The response code would be defined by the following
information:
<list style='empty'>
<t>
Response Code Number:     441<vspace blankLines='0'/>
Default Reason Phrase:    Decline Here
</t>
</list>
</t>

</section>

<section title='Security Considerations' anchor='security'>

<t>
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.
</t>

</section>

</middle>

<back>
<references title='Normative References'>

<reference anchor='sip'>
<!-- RFC 3261 -->
    <front>
	<title>SIP: Session Initiation Protocol</title>
        <author initials='J.' surname='Rosenberg'><organization/></author>
        <author initials='H.' surname='Schulzrinne'><organization/></author>
        <author initials='G.' surname='Camarillo'><organization/></author>
        <author initials='A.' surname='Johnston'><organization/></author>
        <author initials='J.' surname='Peterson'><organization/></author>
        <author initials='R.' surname='Sparks'><organization/></author>
        <author initials='M.' surname='Handley'><organization/></author>
        <author initials='E.' surname='Schooler'><organization/></author>
	<date month='June' year='2002'/>
    </front>
    <seriesInfo name='RFC' value='3261' />
    <format type='TXT'
            target='ftp://ftp.isi.edu/in-notes/rfc3261.txt' />
</reference>

</references>
</back>

</rfc>