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

Network Working Group                                        D. Schwartz
Internet-Draft                                  XConnect Global Networks
Intended status:  Standards Track                          June 24, 2008
Expires:  December 26, 2008


                 No Service To This Number Reject Code
                   draft-schwartz-sipping-nsr-code-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 December 26, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

Abstract

   The Session Initiation Protocol (SIP) allows for users to make calls
   using telephone numbers embedded in either "sip" [RFC3261] or "tel"
   [RFC3966] URIs.  Either way, the telephone number (TN) itself is not
   restricted and can represent an entity in the public telephone
   network, an entity in a private telephone network or an entity on the
   Internet.  This TN resolution ambiguity highlights the difference
   between the LUF and LRF functions defined in
   [I-D.draft-ietf-speermint-terminology] and underscores the need for



Schwartz                Expires December 26, 2008               [Page 1]

Internet-Draft    No Service To This Number Reject Code        June 2008


   more precise SIP error rejection codes.  SIP has no way to indicate
   to the calling UAC that the reason for call rejection is due to the
   fact that this number does not exist in the requested domain or realm
   but it does exist in the public telephone network for instance.  Such
   an indication is useful to allow the call to be retried at a
   different context (i.e. the public PSTN in this case) with possibly
   better results.  This specification defines a new SIP response code
   for this purpose.

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


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  UAS Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  UAC Behavior  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     8.2.  Informational References  . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Intellectual Property and Copyright Statements  . . . . . . . . . . 7





















Schwartz                Expires December 26, 2008               [Page 2]

Internet-Draft    No Service To This Number Reject Code        June 2008


1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] facilitates outgoing
   calls by having the caller compose a request message using a request
   uri containing an address of record (AOR) of the form
   sip:username@domain or tel:username, and sending the request to a
   server (UAS, proxy acting on UASs behalf or redirect server)
   responsible for the request's domain or some other pre-determined
   domain (e.g. outgoing proxy or server providing LUF
   [I-D.draft-ietf-speermint-terminology].  There is no real restriction
   on the value that the username part of the request URI can take, and
   in reality, in most cases today this value contains a telephone
   number (TN) representing either an entity in the public telephone
   network, an entity in a private telephone network or an entity on the
   Internet.

   On the receiving side, the UAS/redirect server must either resolve
   the AOR (TN in this case) and forward/redirect appropriately or
   reject the call outright.  The AOR may not contain a domain
   "responsible" for this TN (i.e. in the case of a "tel" URI) or even
   if it does, the domain may simply refer to the recieving UAS/redirect
   realm and not necessarily the "owner" network of this TN (see
   [I-D.draft-schwartz-sip-e164-ownership] for discussion of TN
   ownership).  It is therefore quite possible that the UAS/redirect
   server will not be able to resolve the TN to an authoritative URI.
   In this case the call will have to be rejected and an appropriate
   error response code returned upstream to the caller.  The point to
   realize, however, is that the semantics of this rejection are
   differnt than the typical 404 "Not Found" error code.  Since non TN
   AORs are tied to a domain, the "Not Found" is final as the UAS/
   redirect server bound to this domain is the ultimate authority on the
   matter.  There is no point in retrying the call at a different domain
   as it will get forwarded back to authoritative domain that has
   already rejected the call.  In the TN case, however, the semantics
   merely imply that the current domain cannot resolve the call, BUT
   that the call should be tried again elsewhere as a different domain
   may yield a positive result.

   SIP does not provide a response code that allows for this
   differentiation.  The closest response code is 404 "Not Found", and
   while it is possible to include a reason phrase with this response,
   this approach is not useful for automata.  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.



Schwartz                Expires December 26, 2008               [Page 3]

Internet-Draft    No Service To This Number Reject Code        June 2008


2.  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
   the domain for which the server is responsible.  The reasons for lack
   of service may be any one of the following two cases:

      The requested TN does not exist in the realm that this server is
      responsible for and no forwarding rules are defined

      The requested TN does exist however it is not routable (e.g. part
      of an allocated number block that is not assigned to any user)

   It is important to note that rejections due to policy affecting the
   caller are out of scope and should use error codes such as 402
   "Payment Required" or 403 "Prohibited".  Similarly, rejection due to
   policy affecting network usage (e.g. call gapping or throttling)
   should be dealt with using a 503 "Service Unavailable".


3.  UAC Behavior

   A UAC receiving a 4XX (No Service To This Number) MUST NOT retry the
   request to the same server and SHOULD fail over to alternate 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 [I-D.draft-ietf-sipping-dialogusage]

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


4.  Requirements

   The following issues should be addressed when considering this new
   error response code:

      Req 1:  It MUST be possible to differentiate between the case
      where a resource is not found at its authoritative domain and the
      case where it is not found by some other domain.

      Req 2:  Specifically, it MUST be possible differentiate between
      the case when a domian knows a resource does not exist (here or
      anywhere) and the case where all that is knows by the domain is
      that it can not say authoritatively whether or not the resource



Schwartz                Expires December 26, 2008               [Page 4]

Internet-Draft    No Service To This Number Reject Code        June 2008


      exists anywhere else.

      Req 3:  It MUST be possible for a UAS to return a different SIP
      error message depending on the above differentiation.

      Req 4:  A definative rejection error response code MUST not be
      retargetted by the UAC.

      Req 5:  An uncertain rejection error response code MAY be
      retargetted by the UAC.


5.  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]]


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


7.  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
   even in cases where the rejection by XConnect was due to TN being a
   PSTN endpoint (non-IP) and not server error or other termination
   failure problem justifying the reduced ASR.


8.  References

8.1.  Normative References

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,



Schwartz                Expires December 26, 2008               [Page 5]

Internet-Draft    No Service To This Number Reject Code        June 2008


              June 2002.

   [RFC3966]  Schulzrinne, H., "The tel URI for Telephone Numbers",
              RFC 3966, December 2004.

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

8.2.  Informational References

   [I-D.ietf-speermint-terminology]
              Malas, D. and D. Meyer, "SPEERMINT Terminology",
              draft-ietf-speermint-terminology-16 (work in progress),
              February 2008.

   [I-D.schwartz-sip-e164-ownership]
              Schwartz, D., Kaplan, H., Darilion, K., and H. Tschofenig,
              "E.164 Ownership Problem Statement",
              draft-schwartz-sip-e164-ownership-01 (work in progress),
              February 2008.

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


Author's Address

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

   Phone:  +972 2 621 8002
   Email:  dschwartz@xconnect.net
   URI:    www.xconnect.net












Schwartz                Expires December 26, 2008               [Page 6]

Internet-Draft    No Service To This Number Reject Code        June 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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 December 26, 2008               [Page 7]