Internet DRAFT - draft-kaplan-dispatch-sip-205-response
draft-kaplan-dispatch-sip-205-response
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]
