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.

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 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Table of Contents

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

1.  Introduction

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

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

8.2. Informational References

Author's Address

Full Copyright Statement

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