| TOC |
|
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 August 23, 2007.
Copyright © The IETF Trust (2007).
An increasing number of SIP architectures implement multiple path routing (MPR), which is the providing of more than one path for a call to reach a destination user agent (UA). To implement MPR well, the proxy which forks a request onto the paths needs to be able to determine if a fork that failed reached the destination UA and was rejected by the UA (and so an alternate path should not be tried), or if the fork failed before reaching the UA (and so an alternate path should be attempted). In order that the proxy can distinguish these two situations, response codes should unambiguously identify which of these situations applies. This Internet-Draft begins classifying the current usage of response codes, their implications for MPR, and possible improvements.
1.
Background
2.
What Is a Final Response?
3.
Response Codes
3.1.
400 Bad Request
3.2.
401 Unauthorized
3.3.
402 Payment Required
3.4.
403 Forbidden
3.5.
404 Not Found
3.6.
405 Method Not Allowed
3.7.
406 Not Acceptable
3.8.
407 Proxy Authentication Required
3.9.
408 Request Timeout
3.10.
410 Gone
3.11.
412 Conditional Request Failed
3.12.
413 Request Entity Too Large
3.13.
414 Request-URI Too Long
3.14.
415 Unsupported Media Type
3.15.
416 Unsupported URI Scheme
3.16.
417 Unknown Resource-Priority
3.17.
420 Extension Not Supported
3.18.
421 Extension Required
3.19.
422 Session Interval Too Small
3.20.
423 Interval Too Brief
3.21.
428 Use Identity Header
3.22.
429 Provide Referrer Identity
3.23.
436 Bad Identity-Info
3.24.
437 Unsupported Certificate
3.25.
438 Invalid Identity Header
3.26.
480 Temporarily Unavailable
3.27.
481 Call/Transaction Does Not Exist
3.28.
482 Loop Detected
3.29.
483 Too Many Hops
3.30.
484 Address Incomplete
3.31.
485 Ambiguous
3.32.
486 Busy Here
3.33.
487 Request Terminated
3.34.
488 Not Acceptable Here
3.35.
489 Bad Event
3.36.
491 Request Pending
3.37.
493 Undecipherable
3.38.
494 Security Agreement Required
3.39.
500 Server Internal Error
3.40.
501 Not Implemented
3.41.
502 Bad Gateway
3.42.
503 Service Unavailable
3.43.
504 Server Time-out
3.44.
505 Version Not Supported
3.45.
513 Message Too Large
3.46.
580 Precondition Failure
3.47.
6xx
4.
Ambiguous Response Codes
5.
Security Considerations
6.
Revision History
6.1.
draft-worley-sip-redundancy-response-00
7.
Normative References
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
An increasing number of Session Initiation Protocol (SIP) [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) system architectures implement multiple path routing (MPR), the feature of providing more than one path for a call to reach a destination user agent (UA). (MPR is also called path redundancy (PR) or alternate path retry (APR).) Typical situations are:
From a protocol point of view, a proxy is presented with the situation where a request (typically an INVITE) should be serially forked to more than one SIP URI, and from an application-layer point of view, all of the URIs are expected to ultimately reach the same user agent (UA). (Here we assume the proxy knows that this is the situation. How the proxy does so is beyond the scope of this document. Also beyond the scope of this document is the question of when two destinations are considered "the same".) Of course, if one fork of the request succeeds, the proxy should not attempt any further forks. But if a request fails, in order to know whether to attempt any further forks, the proxy needs to know if the request succeeded in reaching the destination UA or not.
If the request did not reach the destination UA, then in order implement MPR, the proxy must attempt the next fork. But if the request did reach the destination UA, and the UA returned a failure response, sending the request to the same UA via a different path is unlikely to yield success, and may even degrade the user experience. For example, if the first request was not accepted by the attending human (Ring-No-Answer), sending a second request to the UA by a different path, which will cause the UA to alert again, is not the desired behavior.
Ideally, in order that the proxy can distinguish these cases, each final response code should identify whether the request was rejected by the UA or an intermediate agent, or equivalently, whether the request reached the destination UA or not. (There are also some special cases when a failure response is returned by an intermediate agent, but MPR should not be attempted.) This Internet-Draft begins classifying the current usage of response codes and their implications for MPR, and begins suggesting improvements to the system of response codes.
Initially, this document is intended as a statement of current practice and a discussion of the implications of supporting MPR. It should evolve into a statement of best common practice. If problems with the existing semantics of responses are discovered, it may evolve into a draft standard that updates the semantics of response codes.
| TOC |
First, we need to clarify what is meant by a "final response" for MPR purposes. For implementing MPR, a final response is one which is the result of the proxy's actions in attempting to reach a particular target URI in the set of redundant targets. A final response is always the "best response" chosen from the set of responses from the set forks generated while attempting to reach one of the target URI. It is this response that is examined to determine whether to attempt the next target URI of the set of redundant URIs.
(We note that the proxy might have the set of redundant targets contained as a sub-set within a set of non-redundant targets for the incoming request-URI. That case is harder to keep straight in one's mind, but it is handled in the straightforward way: The proxy proceeds through the sub-sets using the MPR rules, but when moving from one sub-set to the next, it terminates when it receives a success response and continues when it receives a failure response.)
Redirection (3xx) responses are final if they are considered for being returned as the "best response" to an incoming request, that is, if the proxy will not act on the 3xx response to generate further forks whose responses are to be put in the response set. But if the proxy will act on the 3xx to generate new forks in place of the original target URI, the 3xx is not put into the response set and will not become a final response -- Rather, the final responses of the new forks are added to the response set to produce the final response for the target URI. Whether the proxy chooses to act on a 3xx response ("recurse on a redirect response") or to consider it final for its fork is a matter of local policy. (But implementors should be aware of the requirement of section 16.5 of [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) to not recurse on a 3xx response unless the incoming request-URI was for a domain that the proxy "is responsible for".)
A proxy is sometimes permitted to act on a 416 (Unsupported URI Scheme) response by rewriting the request-URI into a sip: or sips: URI and acting on that new URI. (See section 16.7 of [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.).) In such as case, the 416 is treated in the same way as a 3xx. But if the 416 does not trigger rewriting, it is added to the response set and may become the final response.
| TOC |
The following enumeration of response codes was taken from the IANA registry (http://www.iana.org/assignments/sip-parameters) on 31 Jan 2007.
| TOC |
The 400 response is used by an agent to report that a request is malformed. This indicates positive knowledge on the part of the agent that the request is malformed (and not that the agent has detected an an extension that it cannot understand). Hence, MPR should not be attempted on the request. (This is an example of a failure that suppresses MPR, but is not from a destination UA.)
| TOC |
The 401 response is used by a UA to report that the request is not adequately authorized to be processed, but if the UAC provides authorization, the request might be processable. Since an MPR fork will presumably be met with the same authorization requirement, MPR should not be attempted. Instead, the 401 should be returned to the UAC, which should retry the request with authorization.
| TOC |
The 402 response is reserved for further standardization. However, in regard to MPR, it is likely that it will prove useful to separate this response into two response codes, "UAS Payment Required" and "Transport Payment Required".
| TOC |
The 403 response is used by a UAS to indicate that it will not carry out the requested operation, even if provided with credentials. MPR should not be attempted.
| TOC |
The 404 response is used to indicate that an agent had positive knowledge that the request-URI presented to it does not exist. However, since the UAC has no way to know what request-URI was presented, this assertion of positive knowledge has limited usefulness. Because the 404 response is relative to the routing of a particular fork of the request, MPR should be attempted.
| TOC |
Since all well-behaved proxies do not filter requests based on method, 405 responses should only be generated by destination UAs. Hence, MPR should not be attempted for 405 responses.
| TOC |
The 406 response is used by UAs to reject a request because they cannot service any of the media formats listed in the Accept header. 406 responses should only be generated by destination UAs. Hence, MPR should not be attempted for 406 responses.
| TOC |
The 407 response is like the 401 response, but it is generated by proxies and gateways to demand authentication before allowing access to a transport resource. Since the 407 response is relative to the transport path, MPR should be attempted for 407 responses.
| TOC |
The 408 response is used by a SIP agent to report or describe that its attempt to contact the next agent downstream failed with no response. Since the 408 response is always a transport error, MPR should be attempted for 408 responses.
Note that 408 is not used by a UAS to report a Ring-No-Answer condition. The limitation of ringing time is described to the UAS by an Expires header in the INVITE, but the termination of the INVITE is done by an upstream agent sending a CANCEL. See [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) section 13.2.1. So the response generated by Ring-No-Answer is 487. (See Section 3.33 (487 Request Terminated).
| TOC |
The 410 response, like the 404 response, is relative to the request-URI that is in the request when it reaches the agent generating the response, and so is transport-dependent. Hence, MPR should be attempted for 410 responses.
| TOC |
The 412 response [3] (Niemi, A., “Session Initiation Protocol (SIP) Extension for Event State Publication,” October 2004.) is used by a destination UA to indicate that the request cannot be processed because UA does not have information which is a precondition for successfully processing the request. Hence, MPR should not be attempted for 412 responses.
| TOC |
According to [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) section 21.4.11, the 413 response is generated only by destination a UAS to indicate that it cannot process the body of the request. Hence, MPR should not be attempted for 413 responses.
| TOC |
According to [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) section 21.4.12, the 414 response is generated only by destination a UAS to indicate that the request-URI is longer than it can process. The request-URI of a request can depend on the path by which the request reached the UAS, but it not expected in practice that the request-URI seen by the UAS (almost always one of its contact URIs) will be different in an MPR fork. Hence, MPR should not be attempted for 414 responses.
| TOC |
According to [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) section 21.4.13, the 415 response is generated only by destination a UAS to indicate that it cannot process the body of the request. Hence, MPR should not be attempted for 415 responses.
| TOC |
According to [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) section 21.4.14, the 416 response is generated only by destination a UAS to indicate that the request-URI has a scheme that the UAS does not support The request-URI of a request can depend on the path by which the request reached the UAS, but it not expected in practice that the request-URI seen by the UAS will be different in an MPR fork. Hence, MPR should not be attempted for 416 responses.
| TOC |
The 417 response [4] (Schulzrinne, H. and J. Polk, “Communications Resource Priority for the Session Initiation Protocol (SIP),” February 2006.) means that an actor did not understand the Resource-Priority header. Since the Resource-Priority header controls access to transport resources, an MPR fork may avoid the problem, and so MPR should be attempted.
| TOC |
The 420 response means that an actor did not support an extension that was named in a Require or Proxy-Require header. If the failure was due to Proxy-Require, MPR should be attempted. If the failure was due to Require, MPR should not be attempted. Unfortunately, these two conditions cannot be distinguished, which indicates that it is desirable to create a new response code for one of these cases.
| TOC |
The 421 response is used by a UAS to indicate that a response to the request cannot be generated without using an extension that is not listed in the Supported header of the request. Since the response is only generated by a UAS, MPR should not be attempted.
| TOC |
The 422 response [5] (Donovan, S. and J. Rosenberg, “Session Timers in the Session Initiation Protocol (SIP),” April 2005.) can be generated with by a UAS or by a proxy, so it is not possible to determine whether to attempt MPR or not. It is desirable that a new response code is defined for one of these situations.
| TOC |
The 423 response is generated by a registrar in response to a REGISTER request. Hence, MPR should never be attempted for 423 responses.
| TOC |
The 428 response, along with the 436, 437, and 438 responses, are generated by a SIP agent acting as a verifier [2] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.). Since the invocation of the verifier can depend on the transport path of the request, MPR should be attempted for these responses.
| TOC |
The 429 response [6] (Sparks, R., “The Session Initiation Protocol (SIP) Referred-By Mechanism,” September 2004.) is used by UA that is a referee or a refer-target to demand that the REFER or the REFER-generated request contain a Referred-By header. Hence, MPR should not be attempted for a 429 response.
| TOC |
See Section 3.21 (428 Use Identity Header).
| TOC |
See Section 3.21 (428 Use Identity Header).
| TOC |
See Section 3.21 (428 Use Identity Header).
| TOC |
The 480 response is used to indicate various conditions which prevent the user from being contacted, but which may change with time. These conditions include "no UA registered for this AOR" and "do not disturb". Unfortunately, for transport-related errors like "no UA registered for this AOR", MPR would be helpful, but for end-user conditions like "do not disturb", MPR would not be helpful. So this response code should be split into two response codes.
| TOC |
The 481 response is used by UAs to indicate that handling the request requires the existence of a referenced dialog, but the UA has no knowledge of such a dialog. This response is used to reject apparent within-dialog requests for which the necessary dialog does not exist, or for which the necessary dialog usage does not exist within the dialog. In addition, it is used to reject a CANCEL request which does not match a current transaction. In all of these cases, MPR is of no use.
| TOC |
The 482 response indicates that an agent has discovered a loop in request routing. Since an MPR fork might travel over a route that does not lead into a loop, MPR should be attempted for 482 responses.
| TOC |
The 483 response indicates that an agent has discovered a loop in request routing via exhaustion of the Max-Forwards count. Since an MPR fork might travel over a route that does not lead into a loop, MPR should be attempted for 483 responses.
| TOC |
The 484 response is returned to a UAC only by an originating proxy which is cooperating with the UAC to accumulate a dial string. Since such processing does not admit MPR processing, the MPR forking decision will never be presented with a 484 response.
| TOC |
The 485 response indicates that a SIP agent could not determine how to resolve an ambiguous request-URI. Like all responses commenting on a request-URI, it is path-dependent, and so MPR should be attempted for this response.
| TOC |
The 486 response is used by a UAS to indicate that it or its user is busy and so cannot accept another INVITE at this time. (486 is also used to indicate a Do-Not-Disturb condition.) MPR should not be attempted on a 486 response.
| TOC |
The 487 response is used to indicate that a request has been prematurely terminated because the UAC or agent received a CANCEL request before the request was fully processed. This can result from the UAC canceling the request, a destination proxy canceling a request to a UA because of Ring-No-Answer, or (slightly outside of the standard) a UA rejecting a request due to Ring-No-Answer. In any case, MPR would not help the situation.
Unfortunately, RFC 3261 leaves a UAS no proper response to report that it terminated an unanswered INVITE on its own, as the 487 response is supposed to be generated only when a CANCEL is received for an INVITE. In addition, the same response code is used if the UAC cancels an INVITE as if the destination proxy cancels a Ring-No-Answer call, which works against coherent call processing logic. For protocol cleanliness, it would be desirable to define a "Ring No Answer" 4xx response. However, MPR should not be tried either for requests that are canceled by the UAS or requests that met with Ring-No-Answer, and so, strictly speaking, no additional response code is needed to support MPR.
| TOC |
The 488 response is used by a UAS to indicate that the proposed session offer in an INVITE is unacceptable. Hence, MPR forking should not be tried for a 488 response.
| TOC |
The 489 response [7] (Roach, A., “Session Initiation Protocol (SIP)-Specific Event Notification,” June 2002.) is used by a UAS to indicate that it does not implement the Event header in a SUBSCRIBE request. Hence, MPR forking should not be tried for a 489 request.
| TOC |
The 491 response is used by a UAS to reject a re-INVITE which it received while it has an INVITE request outstanding on the dialog. Since 491 can only be returned within-dialog, MPR forking never applies.
| TOC |
The 493 response indicates that the UAS cannot decrypt the request. Hence, MPR forking should not be attempted.
| TOC |
The 494 response [8] (Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, “Security Mechanism Agreement for the Session Initiation Protocol (SIP),” January 2003.) is used by a SIP agent to tell the UAC what security mechanisms it supports. Since it depends on the transport path, MPR forking should be attempted for 494 responses.
| TOC |
The 500 response code is used by SIP agents to report a number of error conditions, some of them intrinsic to the request, and others internal to the agent:
The first two cases are discovered by UAs, and MPR would be no help. But (since 503 responses are in practice always generated by proxies) the final case is a path-dependent failure of a proxy, and MPR should be attempted. Thus, it would help if the 500 response code was split into two codes.
| TOC |
The 501 response, like the similar 405 response, should never be generated by a proxy, and so MPR should not be attempted for it.
| TOC |
The 502 response is used by a proxy or gateway to indicate that it received an invalid response from a downstream agent. Thus, this response is path-dependent, and MPR should be attempted for it.
| TOC |
From RFC 3261 [1] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) section 21.5.4:
A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server.
Thus, MPR should be attempted for 503 responses.
| TOC |
Like the 502 response, the 504 response is path-dependent, and so MPR should be attempted for it.
| TOC |
Like the 501 response, the 505 response is path-dependent, and so MPR should be attempted for it.
| TOC |
Like the 502 response, the 513 response is path-dependent, and so MPR should be attempted for it.
| TOC |
A 580 response [9] (Marshall, W. and J. Rosenberg, “Integration of Resource Management and Session Initiation Protocol (SIP),” October 2002.) is generated by a server to indicate that it is unwilling to meet the preconditions in an SDP offer. Thus, MPR should not be attempted for it.
| TOC |
All 6xx responses request termination of all forking for the request, and a fortiori, prevent any attempt at MPR.
(Since an automated agent cannot reliably determine the original source of the request (which may have been forwarded from one AOR to another several times), 6xx responses are NOT RECOMMENDED, and if used, should only be generated by a UA under direct instruction from a user (or a user-specified policy).)
| TOC |
The following response codes are defined in ways which prevents a proxy from determining whether it should attempt multiple path routing or not. Ideally, their function should be split into two different response codes, one for to be generated by proxies (for which MPR should be attempted) and one to be generated by UAs (for which MPR should not be attempted).
- 402
- The 402 response will (presumably) be used to request that payment information be provided, in much the same way that 401/407 is used to request that authentication credentials be presented. But the 402 response does not distinguish between whether payment is demanded for transport or for UA access.
- 420
- The 420 response code is used to report that a proxy or UAS does not support an extension listed in a Require or Proxy-Require header. But it does not distinguish whether a proxy or UAS is rejecting the request.
- 422
- The 422 response code is used to report that a session timer interval is considered too small by a proxy or UAS. But it does not distinguish whether a proxy or UAS is rejecting the request.
- 480
- The 480 response code is used to report various conditions which prevent the user from being contacted, but which may change with time. These conditions include "no UA registered for this AOR" and "do not disturb". But it does not distinguish transport-related conditions from UA (or end-user) conditions.
- 487
- The 487 response can be the response from a request canceled by the UAC or the result of a Ring-No-Answer condition. For protocol cleanliness, it would be helpful to split Ring-No-Answer from other uses of 487, and to allow a UAS to spontaneously time out an INVITE with a a Ring-No-Answer response.
- 500
- The 500 response code is used to report UA-related errors, as well as when a request could not reach its destination because intermediate agents were overloaded. For MPR, it would be helpful to split the latter condition into a separate response code.
| TOC |
Alternate path retry presents no security considerations that are known to the author beyond what is present in non-MPR SIP system architectures.
| TOC |
| TOC |
First version.
| TOC |
| TOC |
| Dale R. Worley | |
| Pingtel Corp. | |
| 400 West Cummings Park, Suite 2200 | |
| Woburn, MA 01801 | |
| US | |
| Phone: | +1 781 938 5306 |
| Email: | dworley@pingtel.com |
| URI: | http://www.pingtel.com |
| TOC |
Copyright © The IETF Trust (2007).
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.
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.
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).