Internet DRAFT - draft-worley-ex-uri


SIP                                                            D. Worley
Internet-Draft                                                   Pingtel
Expires: August 28, 2007                               February 24, 2007

Response Codes Regarding URIs that Cannot Be Routed to a Destination in
                 the Session Initiation Protocol (SIP)

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on August 28, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Worley                   Expires August 28, 2007                [Page 1]
Internet-Draft                   Ex-URIs                   February 2007


   The Session Initiation Protocol (SIP) provides a number of response
   codes which a SIP agent can use to indicate that it cannot find a
   suitable destination to which to send a request.  Unfortunately, this
   set of response codes was not carefully designed, making it difficult
   in many cases for a proxy to select a response code that accurately
   reflects the proxy's knowledge about the request URI.  This document
   describes these response codes and their current usage.

Table of Contents

   1.  The Current Response Codes . . . . . . . . . . . . . . . . . .  3
     1.1.  404 Not Found  . . . . . . . . . . . . . . . . . . . . . .  3
     1.2.  410 Gone . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.3.  480 Temporarily Unavailable  . . . . . . . . . . . . . . .  3
     1.4.  604 Does Not Exist Anywhere  . . . . . . . . . . . . . . .  4
   2.  Examples in RFCs . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Deficiencies . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  Normative References . . . . . . . . . . . . . . . . . . . . .  8
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 10

Worley                   Expires August 28, 2007                [Page 2]
Internet-Draft                   Ex-URIs                   February 2007

1.  The Current Response Codes

   This section lists the existing response codes that can be used by an
   agent to indicate that it cannot find a destination for a request-
   URI, and their definitions in [1].

1.1.  404 Not Found

      The server has definitive information that the user does not exist
      at the domain specified in the Request-URI.  This status is also
      returned if the domain in the Request-URI does not match any of
      the domains handled by the recipient of the request.

   It is not clear what the statement "the user does not exist at the
   domain" means.  If it were to just mean that the agent has no
   contacts for the request-URI, then it would be redundant, since if
   there were contact points, no 4xx class response would be generated.
   So it appears to be intended that the agent should have a database of
   "existing users", some of which might not have contact points at
   presenct, and the 404 response means that the user-part of the
   request-URI was in the database.

1.2.  410 Gone

      The requested resource is no longer available at the server and no
      forwarding address is known.  This condition is expected to be
      considered permanent.  If the server does not know, or has no
      facility to determine, whether or not the condition is permanent,
      the status code 404 (Not Found) SHOULD be used instead.

   The 410 response indicates that the agent has no contact for the
   request-URI and that it has knowledge that it will not have a contact
   in the future.

1.3.  480 Temporarily Unavailable

      The callee's end system was contacted successfully but the callee
      is currently unavailable (for example, is not logged in, logged in
      but in a state that precludes communication with the callee, or
      has activated the "do not disturb" feature).  The response MAY
      indicate a better time to call in the Retry-After header field.
      The user could also be available elsewhere (unbeknownst to this
      server).  The reason phrase SHOULD indicate a more precise cause
      as to why the callee is unavailable.  This value SHOULD be
      settable by the UA.  Status 486 (Busy Here) MAY be used to more
      precisely indicate a particular reason for the call failure.

Worley                   Expires August 28, 2007                [Page 3]
Internet-Draft                   Ex-URIs                   February 2007

      This status is also returned by a redirect or proxy server that
      recognizes the user identified by the Request-URI, but does not
      currently have a valid forwarding location for that user.

   It is not clear what is meant by "not logged in", as the obvious
   meaning for "logged in" would be "having a registered contact".  But
   given that it says "the callee's end system was contacted
   successfully", it seems that the 480 response is to be used by a UA
   to indicate "do not disturb" status and similar situations.  Within
   this interpretation, the 480 response is not to be used by proxies,
   only UAs.

1.4.  604 Does Not Exist Anywhere

      The server has authoritative information that the user indicated
      in the Request-URI does not exist anywhere.

   This description is similar to the description of the 404 response in
   that it talks of the "existence" of "users".  But it suffers from the
   deficiency of all 6xx class responses, in that it terminates all
   forks of the request, and an agent cannot have the knowledge needed
   to do so legitimately, because it cannot know the URIs through which
   the request was forwarded to it.

Worley                   Expires August 28, 2007                [Page 4]
Internet-Draft                   Ex-URIs                   February 2007

2.  Examples in RFCs

   Some examples of the problematic 480 response code are given in RFCs:

      [2] shows two examples: (1) a proxy responding 480 to report that
      it got no response from the destination UA, and (2) a UA
      responding 480 to report unwillingness to take the call (reason
      unspecified).  (The first example seems incorrect, and I wonder if
      it should have been 408?)

      [3], [4], and [5] show response code 480 to report a variety of
      call failure situations (including "ring no answer") in
      interworking with the PSTN.

      The caller preferences system ([6] and [7]) uses a 480 response
      that there are no acceptable contacts according to the caller
      preferences in the request.

Worley                   Expires August 28, 2007                [Page 5]
Internet-Draft                   Ex-URIs                   February 2007

3.  Deficiencies

   Setting aside the 604 response (because it is a 6xx class response),
   we have the 404, 410, and 480 responses for use by proxies.

   The first deficiency is that both of these responses assert more than
   that there is no contact for the request-URI.  The 404 response
   asserts that the request-URI identifies a user, and that user is not
   contained in a defined set of users.  The 410 response asserts that
   there will not be a contact for the request-URI in the future as
   well.  The 480 response appears to assert that the identified user is
   contained in a defined set of users.  The result is that there is no
   way for an agent to assert the absence of contacts for a request-URI
   without asserting additional facts about the request-URI (which it
   may not possess).

Worley                   Expires August 28, 2007                [Page 6]
Internet-Draft                   Ex-URIs                   February 2007

4.  Security Considerations

   The only known security consideration for this topic is a matter of
   privacy: When a call is not routable to a destination, the response
   code may provide more information about the targeted user than just
   the fact of non-routability.  Under some circumstances, this might be
   a breach of the user's privacy.

Worley                   Expires August 28, 2007                [Page 7]
Internet-Draft                   Ex-URIs                   February 2007

5.  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]  Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
        Summers, "Session Initiation Protocol (SIP) Basic Call Flow
        Examples", RFC 3665, BCP 75, December 2003.

   [3]  Camarillo, G., Roach, A., Peterson, J., and L. Ong, "Integrated
        Services Digital Network (ISDN) User Part (ISUP) to Session
        Initiation Protocol (SIP) Mapping", RFC 3398, December 2002.

   [4]  Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K.
        Summers, "Session Initiation Protocol (SIP) Public Switched
        Telephone Network (PSTN) Call Flows", RFC 3666, BCP 76,
        December 2003.

   [5]  Elwell, J., Derks, F., Mourot, P., and O. Rousseau,
        "Interworking between the Session Initiation Protocol (SIP) and
        QSIG", RFC 4497, BCP 117, May 2006.

   [6]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
        Preferences for the Session Initiation Protocol (SIP)",
        RFC 3841, August 2004.

   [7]  Rosenberg, J. and P. Kyzivat, "Guidelines for Usage of the
        Session Initiation Protocol (SIP) Caller Preferences Extension",
        RFC 4596, July 2006.

Worley                   Expires August 28, 2007                [Page 8]
Internet-Draft                   Ex-URIs                   February 2007

Author's Address

   Dale R. Worley
   Pingtel Corp.
   400 West Cummings Park, Suite 2200
   Woburn, MA  01801

   Phone: +1 781 938 5306 x173

Worley                   Expires August 28, 2007                [Page 9]
Internet-Draft                   Ex-URIs                   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

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

   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


   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Worley                   Expires August 28, 2007               [Page 10]