No Service To This Number Reject Code
draft-schwartz-sipping-nsr-code-01

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 May 8, 2009.

Abstract

This specification discusses a SIP response error code ambiguity that may exist due to sematic differences between SIP [RFC3261] and TEL [RFC3966] URIs.

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.  SIP error response code classes
3.  Not found error response code
4.  UAS Behavior
5.  UAC Behavior
6.  Requirements
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.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. SIP URIs will often contain alphanumeric usernames while TEL URIs will always contain telephone number (TN) usernames 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. In the case of a request containing a SIP URI, the UAS acting on behalf of the target domain can "authoritatively" reject a call with a 404 when the username is not found. For example, a registrar server acting on behalf of "example.com" can authoritatively reject a call with a request line containing the URI sip:alice@example.com if no user with the name "alice" exists at "example.com". The implication of the 404 in this case vis-a-vis the UAC is that no further action should be taken as this would be futile since no user named alice exists at this target. A request containing a TEL URI, on the other hand, that is rejected with a similar error code may indeed find success if failover routing is undertaken by the UAC.

As such either clearer more precise definitions are required for the existing error codes or an additional response code is necessary to disambiguate the cases described above. This specification chooses the latter and defines the 4XX (No Service To This Number) response code for this purpose.

2.  SIP error response code classes

When examining SIP error response codes, the following classes or types of scenarios exist:

Something is wrong with request; either malformed or not acceptable at this particular server: e.g. 400, 405, 413, 414, 415, 416, 420, etc.

Nothing is wrong with request but receiving user refuses to accept the call: e.g. 480, 486, 488, 6XX, etc.

There is some network or other issue that preventing this call from getting to its destination: e.g. 5XX

There is some permission based reason to reject the call: e.g. 401, 402, 403, 407, etc.

Message formatting is OK but resource identified in request line URI is not found at this target and no retargeting information is available: e.g. 404, 410, etc.

3.  Not found error response code

There are a few use cases where this class of error may occur and the goal of this document is to highlight the problamatic ones. In these cases we need to either re-define clearly the meaning of the response codes or define a new response code to address the case/s that are not currently addressed.

"Authoritative rejection" - as in the case of sip:alice@example.com and no such user (Alice) exists at example.com. Similarly, this can be the case of a number in an allocated NPA-NXX block that is not currently assigned to any user. Implications to UAC are: "stop trying to reach this user - she doesn't exist". The current definition of 404 should suffice for this case.

"Authoritative rejection with possible recourse - server assisted" as in the case where a number has been ported out of a range and the server will return a 3XX indicating the possible (possible but not definite since the requested resource may have already been ported out of recipient network as well) new target for this call. Implications to UAC in this case are: "I can't help you - go there - he may be able to help you". The current definition of 3XX responses should suffice for this case.

"Non-Authoritative rejection" - server is not carrier of record for the requested resource and has no access to data store (e.g. central database used for number portability data) to populate a 3XX response. Implications to UAC are: "Don't stop trying to reach this user - he MAY or MAY NOT exist - try looking elsewhere if you can." Need to find a suitable error code for this case or define a new one.

"Proxy of Authoritative rejection" - Request has been retargeted through this server to a downstream server that has authoritatively rejected the call with a 404. While this information is authoritative, since it was retargeted and possibly modified (the request URI that is) in the process, the UAC must be made aware of this fact to decide if he wishes to try alternate routing. Can probably use the Warning header which includes the retargeted URI.

4.  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 not serviced by the domain for which the server is responsible and no retargeting information is available.

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

6.  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 domain 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 definitive rejection error response code MUST not be retargeted by the UAC.

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

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

8.  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 number space 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.

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

10.  References

10.1. Normative References

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