Network Working Group D. Schwartz Internet-Draft XConnect Global Networks Intended status: Standards Track November 4, 2008 Expires: May 8, 2009 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. Copyright Notice Copyright (C) The IETF Trust (2008). 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 Schwartz Expires May 8, 2009 [Page 1] Internet-Draft No Service To This Number Reject Code November 2008 document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SIP error response code classes . . . . . . . . . . . . . . . . 3 3. Not found error response code . . . . . . . . . . . . . . . . . 4 4. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10.2. Informational References . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Schwartz Expires May 8, 2009 [Page 2] Internet-Draft No Service To This Number Reject Code November 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. 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. Schwartz Expires May 8, 2009 [Page 3] Internet-Draft No Service To This Number Reject Code November 2008 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. Schwartz Expires May 8, 2009 [Page 4] Internet-Draft No Service To This Number Reject Code November 2008 "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. Schwartz Expires May 8, 2009 [Page 5] Internet-Draft No Service To This Number Reject Code November 2008 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 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. Schwartz Expires May 8, 2009 [Page 6] Internet-Draft No Service To This Number Reject Code November 2008 [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. 10.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 May 8, 2009 [Page 7] Internet-Draft No Service To This Number Reject Code November 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 May 8, 2009 [Page 8]