DISPATCH Working Group H. Kaplan Internet Draft Oracle Intended status: Standards Track July 29, 2013 Expires: January 30, 2014 Session Initiation Protocol (SIP) Success Response Code for Indication of Alternate Target Answerer draft-kaplan-dispatch-sip-205-response-00 Abstract This document defines a new Session Initiation Protocol (SIP) response, 205 Alternate Answerer, that a SIP User Agent Server (UAS) can use to indicate to the User Agent Client (UAC) that the UAS is answering the request for which it was not the intended target. This is useful for cases where the UAC might wish to perform different actions based on such knowledge, such as terminate the dialog or re-attempt the request in a different way. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 January 29, 2014. Kaplan Expires January 2014 [Page 1] Internet-Draft 205 Alternate Answerer July 2013 Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction..................................................2 2. Terminology...................................................3 3. Applicability and Limitation..................................3 3.1. Rationale for 205 vs. 200................................3 4. User Agent Server Behavior....................................4 5. User Agent Client Behavior....................................5 6. Proxy Behavior................................................5 7. Open Issues...................................................5 8. Security Considerations.......................................5 9. IANA Considerations...........................................6 10. Acknowledgments..............................................6 11. References...................................................6 11.1. Normative References....................................6 11.2. Informative References..................................6 Author's Address..................................................7 1. Introduction In certain cases user agents other than the intended target may answer a SIP request with a 2xx-class response. For example, a Back-to-Back User Agent (B2BUA) might answer a [draft-traceroute] INVITE request with a 200 response if the received Max-Forwards header field value is 0, in order to establish a media-loopback dialog. Another example is a voicemail or announcement server might wish to answer an INVITE request intended for a temporarily or permanently unavailable Address-of-Record target user, in order to establish a dialog with the UAC to play and record media. In such cases, the answering UAS may wish to indicate it is not the intended target in order to let the UAC perform additional logic based upon this knowledge. For example, in order to let the UAC Kaplan Expires January 2014 [Page 2] Internet-Draft 205 Alternate Answerer July 2013 generating [draft-traceroute] requests know that it has not yet reached the final target and should increase the Max-Forwards value for its next request. In the voicemail case, the UAS voicemail server might indicate to the UAC it is not the intended target so that the UAC can terminate the dialog immediately instead of leaving a voicemail message. This document defines a new SIP response code: 205 Alternate Answerer. A UAS can send a 205 response instead of a 200 response in order to indicate it is an alternate answerer, instead of the originally intended target. The SIP Reason header field is also included in the 205 response message, to indicate the underlying cause that made the UAS answer the request. 2. 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 RFC 2119. The terminology in this document conforms to RFC 2828, "Internet Security Glossary". 3. Applicability and Limitation The 205 response code MAY be used in response of any SIP method request outside of a dialog. The 205 response code does not change the rules for dialog establishment defined in RFC 3261, and behaves in all ways as a 200 OK response. A UAC that does not implement explicit support for 205 will treat it as a 200. In some cases a UAS that answers a request does not know it is not the originally intended target; for example an upstream proxy might have redirected the request and changed the target before forwarding the request to the UAS. In such cases, the SIP proxy MAY change a received 200 from the UAS to a 205 response code as described in section 6, and include a Reason header field for why it retargeted the request to the UAS. In some cases a SIP proxy or B2BUA might change a 205 response code to a 200 response, before the response reaches the UAC. The Reason header field might still reach the UAC in such cases, however. 3.1. Rationale for 205 vs. 200 The 205 response provides a means for the UAS to indicate to the UAC that some entity other than the original target is answering the request, in order to let the UAC perform different actions than it otherwise would have with a 200 OK response. Kaplan Expires January 2014 [Page 3] Internet-Draft 205 Alternate Answerer July 2013 In the INVITE-based sip-traceroute case this is necessary to let the UAC know when it has not yet reached the final target of its traceroute testing. Likewise it might be useful for an OPTIONS- based traceroute as described in section 11 of [RFC3261]. For voicemail cases this is useful in order to avoid wasting resources on the UAS if the calling agent will not leave a voicemail in the end anyway. It might also be useful if the UAC can immediately terminate the dialog and automatically attempt another target AoR it might know about, instead of having the calling user hang up and try a different called party. For [RFC3428] MESSAGE-based requests a 205 response might be useful to indicate the instant message is being stored on another server until the intended target user retrieves it some time later. [Note: this used to be possible with a 202 response code, but it appears the 202 has been deprecated by RFC 6665?] 4. User Agent Server Behavior When a UAS receives a request that it is not the intended target for, and if it is going to answer the request with a 200 anyway, it MAY instead send a 205 Alternate Answerer response. A Reason header field [RFC3326] SHOULD be inserted in the response, with a cause parameter value and reason-text string indicating the failure code that caused it to answer the request. Generally a UAS will not answer a request that is not targeted for it with a 200 OK, but will instead respond with a 404 Not Found per RFC 3261. Local policy can dictate otherwise, for example a B2BUA might answer an INVITE as part of the sip-traceroute mechanism, or a voicemail system might answer an INVITE on behalf of a temporarily or permanently unavailable user. The Reason header field cause parameter value SHOULD be based on the failure condition that triggered the UAS to answer the request instead of the true target, or the failure SIP response code it would otherwise have returned in a failure response. For example, a B2BUA answering a sip-traceroute request per [draft- traceroute] would generate a 205 Alternate Answerer response with a Reason header field of: Reason: SIP;cause=483;text="Too Many Hops" Kaplan Expires January 2014 [Page 4] Internet-Draft 205 Alternate Answerer July 2013 A voicemail server or answering machine might answer an INVITE for an unavailable user with a 205 Alternate Answerer response and a Reason header field of: Reason: SIP;cause=480;text="Temporarily Unavailable" Or an announcement server or dialing-operator system might answer an INVITE for an unknown Address-of-Record for its domain with a 205 Alternate Answerer response and a Reason header field of: Reason: SIP;cause=404;text="Not Found" 5. User Agent Client Behavior A UAC receiving a 205 response MUST follow the rules for 2xx responses defined in RFC 3261, as if the response was a 200 OK. The UAC MAY have additional specific logic for subsequent processing when receiving the 205 response and Reason header field cause parameter. For example it might decide to immediately terminate an INVITE-based session by sending a BYE request (after sending the ACK). 6. Proxy Behavior A proxy that retargets a request to a different UAS based upon a failure to reach the original intended target MAY change a 200 OK response from the retargeted-to UAS to a 205 Alternate Answerer. The proxy SHOULD insert a Reason header field with a cause parameter value indicating the failure code that caused it to retarget the request. For example, if a proxy retargets a request to a voicemail server because the original target is busy, and the voicemail server responds with a 200 OK, then the proxy might change it to a 205 Alternate Answerer response with a Reason header field of: Reason: SIP;cause=486;text="User Busy" 7. Open Issues o Should the 205 only apply to INVITEs, OPTIONS and MESSAGE request methods? (I can't imagine a purpose for REGISTER, SUBSCRIBE, or PUBLISH request method types) 8. Security Considerations SIP response codes are not protected from modification between the UAS and UAC, and thus a middleman might change a 205 to a 200, or Kaplan Expires January 2014 [Page 5] Internet-Draft 205 Alternate Answerer July 2013 vice-versa. This might be abused in order to force the UAC to perform an action it would otherwise not perform; for example to make it perform additional sip-traceroute requests when it should stop instead, or stop performing them when it should continue instead. Having voicemail servers or answering machines generate a 205 response might benefit malicious auto-dialers, since it enables them to conserve resources and to move on more quickly to other targets in search of human answerers. 9. IANA Considerations This document registers one new response code. The response code is defined by the following information, which is to be added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters. Response Code Number: 205 Default Reason Phrase: Alternate Answerer 10. Acknowledgments The concept of creating a new 205 response code with a Reason header field came out of discussions with Paul Kyzivat and Brett Tate. 11. References 11.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. [RFC3326] Schulzrinne, H., Oran, D., Camarillo, G., "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, December, 2002. 11.2. Informative References [RFC3428] Campbell, B., ed., et al, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002. [draft-traceroute] Kaplan, H., "A Media-based Traceroute Function for the Session Initiation Protocol (SIP)", draft-ietf-straw- sip-traceroute-00, July 2013. Kaplan Expires January 2014 [Page 6] Internet-Draft 205 Alternate Answerer July 2013 Author's Address Hadriel Kaplan Oracle Email: hadriel.kaplan@oracle.com Kaplan Expires January 2014 [Page 7]