One document matched: draft-schwartz-sip-nsr-code-00.txt

Network Working Group                                        D. Schwartz
Internet-Draft                                           Kayote Networks
Intended status: Standards Track                               July 2007
Expires: January 2, 2008


                  No Service To This Number Reject Code
                   draft-schwartz-sip-nsr-code-00.txt

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 January 2, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   The Session Initiation Protocol (SIP) allows calls to both addresses
   of record (AORs) such as sip:alice@example.com and telephone numbers
   with either sip or tel schemes such as tel:+12127771234.  As opposed
   to the AOR where the domain specifies the exact location or realm of
   the user and a reject code provides enough visiblity to the calling
   party to exit gracefully (e.g. a 404 indicates that there is no point
   in trying further as the requested user either does not exist or is
   offline with no voicemail) with telephone numbers (TNs) this is not



Schwartz                 Expires January 2, 2008                [Page 1]

Internet-Draft          Termination Based Reject               July 2007


   the case.  With more and more TNs representing actual IP endpoints
   there is a need to differentiate in an error code between rejecting a
   call due to a misdialed number (i.e. the number does not exist) and a
   number that is just not associated with an IP endpoint (for example
   in a case where there is no billing relationship and as such the
   rejecting proxy cannot forward to a PSTN termination provider.  This
   specification defines a new SIP response code (No Service Reject -
   nsr) for this purpose.


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  UAS Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  UAC Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  4XX (No Service To This Number) Definition  . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7


























Schwartz                 Expires January 2, 2008                [Page 2]

Internet-Draft          Termination Based Reject               July 2007


1.  Introduction

   The Session Initiation Protocol (SIP) [SIP] facilitates outgoing
   calls to a UAS, or proxy acting on its behalf, by having the caller
   enter either an address of record in the form sip:user@domain, sip:
   telephone-number or tel:telephone-number with some additional tags
   (e.g. phone-context).  The underlying premise behind both the AOR and
   TN approach is that the requested user is either served by the UAS
   receiving the request or that this proxy/server will find the
   requested user and connect the call.  Any failure to complete the
   call is held against the UAS in the form of reduced ASR or other such
   metrics.  While this makes perfect sense in the case where the
   request uri contains an AOR where the implicit assumption is that the
   requested user is IP enabled, in the case where the request URI
   contains a TN this is not always the case.  More and more IP
   endpoints are using TNs in the form of Direct Inward Dial (DID)
   numbers that look and smell like ordinary numbers but in reality are
   actual IP termination endpoints.  A service providing free
   termination to IP endpoints only may wish to respond to a request for
   an actual PSTN resource (discovered for example by dipping into a
   private ENUM registry and not finding the TN) with an error code
   other than 404 to indicate that this number was not found in the free
   space and perhaps should be reattempted using a different outbound
   proxy and that the failure should not be held against the ASR rating
   of this original proxy.

   SIP does not provide a response code that allows the UAS, or a proxy
   acting on its behalf, to explicitly indicate that the request was
   rejected because it was not an IP endpoint served by this UAS.  The
   closest response code is 404 (Not Found), which doesn't convey a
   specific reason.  While it is possible to include a reason phrase in
   a 404 response that indicates to the human user that the call was
   rejected because this particular UAS does not service that number, a
   reason phrase is not useful for automata in the form of LCR engines
   receiving the response.  An indication that can be understood by an
   automaton would allow for programmatic handling, including automatic
   retries and proper classification of error in dynamic LCR
   environments.  To remedy this, this specification defines the 4XX (No
   Service To This Number) response code.


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [TERM].





Schwartz                 Expires January 2, 2008                [Page 3]

Internet-Draft          Termination Based Reject               July 2007


3.  UAS Behavior

   A server (generally acting on behalf of the called party, though this
   need not be the case) MAY generate a 4XX (No Service To This Number)
   response when it receives a request for a TN that is not serviced by
   this UAS.  The reasons for lack of service may be any one of the
   following cases:
      * The requested TN does not exist in the realm that this UAS is
        responsible for and no forwarding rules are defined
      * The requested TN exists however it is part of a number block 
        that has been assigned but not activated
      * The requested TN exists however the caller has an assumed 
        behavior (e.g. free calls) and the requested TN does not fulfill 
        this assumption
   In all these cases the 4XX (No Service To This Number) response
   should be returned indicating this case.


4.  UAC Behavior

   A UAC receiving a 4XX (No Service To This Number) MUST NOT retry the
   request to same UAS and SHOULD fail over to alternate User Agent
   Servers if these are available to try to complete the call.

   Receipt of a 4XX response to a mid-dialog request SHOULD NOT cause
   the dialog to terminate, and SHOULD NOT cause the specific usage of
   that dialog to terminate [MIDDIALOG].

   A UAC that does not understand or care about the specific semantics
   of the 4XX response will treat it as a 400 response.


5.  4XX (No Service To This Number) Definition

   This response indicates that the server refused to fulfill the
   request because the resource being requested by the caller is not
   availble at this UAS but may be available elsewhere.

   Its default reason phrase is "No Service To This Number".


6.  IANA Considerations

   This section registers a new SIP response code according to the
   procedures of RFC 3261.

   RFC Number: RFC XXXX [[NOTE TO IANA: Please replace XXXX with the RFC
   number of this specification]]



Schwartz                 Expires January 2, 2008                [Page 4]

Internet-Draft          Termination Based Reject               July 2007


   Response Code Number: 4XX

   Default Reason Phrase: No Service To This Number


7.  Security Considerations

   The fact that a request was rejected because it was targeted at a
   resource that is not available at a particular UAS does in fact
   reveal sensitive information about the called party - the actual
   numberspace served by this UAS.  This information may or may not be
   sensitive.  If it is, a UAS SHOULD reject the request with a 404
   instead.


8.  Acknowledgements

   This draft was motivated by trials at XConnect Global Networks where
   rejection of TN requests by participating operators led to reduced
   ASRs and consequential automatic removal from operator LCR tables
   when rejection by XConnect was due to TN being an PSTN endpoint
   (non-IP) and not server error or other termination failure problem
   justifying the reduced ASR.


9.  References

9.1.   Normative References

   [SIP]      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.

   [TERM]     Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", RFC 2119, March 1997.

9.2.   Informative References

   [MIDDIALOG]
              Sparks, R., "Multiple Dialog Usages in the Session
              Initiation Protocol",  draft-ietf-sipping-dialogusage-06
              (work in progress), February 2007.

   [WARNING]  Hautakorpi, J. and G. Camarillo, "Extending the Session
              Initiation Protocol Reason Header with Warning Codes",
               draft-hautakorpi-reason-header-for-warnings-00 (work in
              progress), October 2005.



Schwartz                 Expires January 2, 2008                [Page 5]

Internet-Draft          Termination Based Reject               July 2007


Author's Address

   David Schwartz
   Kayote Networks
   Malcha Technology Park
   Building # 1
   Jerusalem  90961
   Israel

   Phone: +972 52 347 4656
   Email: david.schwartz@kayote.com
   URI:   www.kayote.com






































Schwartz                 Expires January 2, 2008                [Page 6]

Internet-Draft          Termination Based Reject               July 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).





Schwartz                 Expires January 2, 2008                [Page 7]