Response Codes Regarding URIs that Cannot Be Routed to a Destination in the Session Initiation Protocol (SIP)

This section lists the existing response codes that can be used by an agent to indicate that it cannot find a destination for a request-URI, and their definitions in .

The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. It is not clear what the statement "the user does not exist at the domain" means. If it were to just mean that the agent has no contacts for the request-URI, then it would be redundant, since if there were contact points, no 4xx class response would be generated. So it appears to be intended that the agent should have a database of "existing users", some of which might not have contact points at presenct, and the 404 response means that the user-part of the request-URI was in the database.

The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. The 410 response indicates that the agent has no contact for the request-URI and that it has knowledge that it will not have a contact in the future.

The callee's end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the "do not disturb" feature). The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure. This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user. It is not clear what is meant by "not logged in", as the obvious meaning for "logged in" would be "having a registered contact". But given that it says "the callee's end system was contacted successfully", it seems that the 480 response is to be used by a UA to indicate "do not disturb" status and similar situations. Within this interpretation, the 480 response is not to be used by proxies, only UAs.

The server has authoritative information that the user indicated in the Request-URI does not exist anywhere. This description is similar to the description of the 404 response in that it talks of the "existence" of "users". But it suffers from the deficiency of all 6xx class responses, in that it terminates all forks of the request, and an agent cannot have the knowledge needed to do so legitimately, because it cannot know the URIs through which the request was forwarded to it.

Some examples of the problematic 480 response code are given in RFCs: shows two examples: (1) a proxy responding 480 to report that it got no response from the destination UA, and (2) a UA responding 480 to report unwillingness to take the call (reason unspecified). (The first example seems incorrect, and I wonder if it should have been 408?) , , and show response code 480 to report a variety of call failure situations (including "ring no answer") in interworking with the PSTN. The caller preferences system ( and ) uses a 480 response that there are no acceptable contacts according to the caller preferences in the request.

Setting aside the 604 response (because it is a 6xx class response), we have the 404, 410, and 480 responses for use by proxies. The first deficiency is that both of these responses assert more than that there is no contact for the request-URI. The 404 response asserts that the request-URI identifies a user, and that user is not contained in a defined set of users. The 410 response asserts that there will not be a contact for the request-URI in the future as well. The 480 response appears to assert that the identified user is contained in a defined set of users. The result is that there is no way for an agent to assert the absence of contacts for a request-URI without asserting additional facts about the request-URI (which it may not possess).

The only known security consideration for this topic is a matter of privacy: When a call is not routable to a destination, the response code may provide more information about the targeted user than just the fact of non-routability. Under some circumstances, this might be a breach of the user's privacy.