No Service To This Number Reject Code

The Session Initiation Protocol (SIP) 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.

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.

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.

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.

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.

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.

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

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.

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.