draft-ietf-sip-hop-limit-diagnostics-00.txt   draft-ietf-sip-hop-limit-diagnostics-01.txt 
SIP WG S. Lawrence SIP WG S. Lawrence
Internet-Draft Pingtel Corp. Internet-Draft Pingtel Corp.
Expires: August 28, 2006 A. Hawrylyshen Updates: 3261 (if approved) A. Hawrylyshen
Ditech Communications Corp. Expires: December 2, 2006 Ditech Communications Corp.
R. Sparks R. Sparks
Estacado Systems Estacado Systems
February 24, 2006 May 31, 2006
Diagnostic Responses for SIP Hop Limit Errors Diagnostic Responses for SIP Hop Limit Errors
draft-ietf-sip-hop-limit-diagnostics-00 draft-ietf-sip-hop-limit-diagnostics-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2006. This Internet-Draft will expire on December 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
The SIP protocol imposes a limit on the number of hops a request may The SIP protocol imposes a limit on the number of hops a request may
make from a sender to the recipient. When this limit is reached, a make from a sender to the recipient. When this limit is reached, a
483 error response is returned. The present form of the 483 response 483 error response is returned. The present form of the 483 response
does not provide enough information for the sender or proxies on the does not provide enough information for the sender or proxies on the
path to diagnose failures whose symptom is that the hop limit is path to diagnose failures whose symptom is that the hop limit is
reached. This document proposes additional diagnostic information to reached. This document proposes additional diagnostic information to
be returned in a 483 response. be returned in a 483 response.
Comments are solicited, and should be directed to the SIP working Comments are solicited, and should be directed to the SIP working
group list at 'sip@ietf.org'. group list at 'sip@ietf.org'.
The proposal in this document was originally presented in another
draft-lawrence-maxforward-problems-00 on the SIPPING working group
list. That draft raised a number of issues, each of which was
referred to the SIP working group to be addressed, but it was decided
to consider each issue separately. This proposal is, aside from
purely editorial corrections, unchanged from the earlier draft.
Table of Contents Table of Contents
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2. Diagnosing Hop Limit Exceeded Failures . . . . . . . . . . . . 3 2. Diagnosing Hop Limit Exceeded Failures . . . . . . . . . . . . 3
2.1. Limitations of the 483 Error Response . . . . . . . . . . 3 2.1. Limitations of the 483 Error Response . . . . . . . . . . 3
2.2. Returning Useful Diagnostic Information in 483 2.2. Returning Useful Diagnostic Information in 483
Responses . . . . . . . . . . . . . . . . . . . . . . . . 4 Responses . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Implementation Experience . . . . . . . . . . . . . . . . 8 2.4. Pruning Responses . . . . . . . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 3. Implementation Experience . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Informative References . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10
6.2. Informative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 12
1. Conventions and Definitions 1. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
2. Diagnosing Hop Limit Exceeded Failures 2. Diagnosing Hop Limit Exceeded Failures
skipping to change at page 5, line 29 skipping to change at page 5, line 29
the request looked like when it ran out of hops. One way to the request looked like when it ran out of hops. One way to
accomplish this is to return the SIP header of the rejected message accomplish this is to return the SIP header of the rejected message
to the sender. Doing so is already allowed by existing rules: to the sender. Doing so is already allowed by existing rules:
RFC 3261 (section 7.4) says: "All responses MAY include a body.". RFC 3261 (section 7.4) says: "All responses MAY include a body.".
RFC 3420 [RFC3420] defines the Content-Type "message/sipfrag" to RFC 3420 [RFC3420] defines the Content-Type "message/sipfrag" to
"allow SIP entities to make assertions about a subset of a SIP "allow SIP entities to make assertions about a subset of a SIP
message". message".
This document proposes the following new rule for all SIP This document proposes the following new rule for all SIP
implementations: implementations:
Any 483 response SHOULD be constructed with a message body of type Any 483 response SHOULD be constructed with both:
message/sipfrag containing as much as possible of the SIP header A message body of type message/sipfrag containing as much as
from the rejected request. possible of the SIP header from the rejected request.
A Warning header with a warn-code of 399 that identifies the
system returning the error.
2.3. Example 2.3. Example
We will use this proposed change to diagnose an example routing We will use this proposed change to diagnose an example routing
problem. problem.
Here is a request sent to a proxy that implements the suggested Here is a request sent to a proxy that implements the suggested
content in a 483 response. content in a 483 response.
INVITE sip:9999@interop.pingtel.com SIP/2.0 INVITE sip:9999@interop.pingtel.com SIP/2.0
skipping to change at page 7, line 8 skipping to change at page 7, line 8
The target user '9999' is one that has been deliberately configured The target user '9999' is one that has been deliberately configured
to go into a forwarding loop alternating between two addresses to go into a forwarding loop alternating between two addresses
(neither of them the original target); a situation that is currently (neither of them the original target); a situation that is currently
difficult to diagnose. A relatively low Max-Forwards value of 9 was difficult to diagnose. A relatively low Max-Forwards value of 9 was
chosen to improve readability. chosen to improve readability.
The response received was: The response received was:
SIP/2.0 483 Too many hops SIP/2.0 483 Too many hops
Warning: 399 192.0.2.162:5080 Too Many Hops
From: Sip Send <sip:sipsend@10.1.1.20>;tag=612f37e7 From: Sip Send <sip:sipsend@10.1.1.20>;tag=612f37e7
To: sip:9999@interop.pingtel.com To: sip:9999@interop.pingtel.com
Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20
Cseq: 1 INVITE Cseq: 1 INVITE
Via: SIP/2.0/TCP 10.1.1.20:40221 Via: SIP/2.0/TCP 10.1.1.20:40221
;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f
Content-Type: message/sipfrag Content-Type: message/sipfrag
Content-Length: 1014 Content-Length: 1014
Date: Fri, 14 Oct 2005 15:27:47 GMT Date: Fri, 14 Oct 2005 15:27:47 GMT
skipping to change at page 7, line 44 skipping to change at page 7, line 45
;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f ;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f
To: sip:9999@interop.pingtel.com To: sip:9999@interop.pingtel.com
From: Sip Send <sip:sipsend@10.1.1.20>;tag=612f37e7 From: Sip Send <sip:sipsend@10.1.1.20>;tag=612f37e7
Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20 Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20
Cseq: 1 INVITE Cseq: 1 INVITE
Max-Forwards: 0 Max-Forwards: 0
User-Agent: sipsend/0.02 User-Agent: sipsend/0.02
Date: Fri, 14 Oct 2005 15:35:53 GMT Date: Fri, 14 Oct 2005 15:35:53 GMT
Content-Length: 0 Content-Length: 0
This response shows what server returned the error; its' address - The Warning header in this response identifies the server returning
192.0.2.162 - is in the topmost Via of the returned request. It also the error (192.0.2.162:5080). The Via headers of the returned
shows that the target URI has been changed to the user message/sipfrag body show the path the failed message took. The
'InfiniteLoop'. returned request line also shows that the target URI has been changed
to the user 'InfiniteLoop'.
Resending the request with a hop limit one less than before (8), Resending the request with a hop limit one less than before (8),
shows that at that hop the request URI is to user 'LoopForever': shows that at that hop the request URI is to user 'LoopForever':
INVITE sip:LoopForever@interop.pingtel.com SIP/2.0 INVITE sip:LoopForever@interop.pingtel.com SIP/2.0
Record-Route: <sip:192.0.2.162:5080 Record-Route: <sip:192.0.2.162:5080
;lr;a;t=4f18a30b;s=a9711e1704ccd5273955589c5fe94745> ;lr;a;t=4f18a30b;s=a9711e1704ccd5273955589c5fe94745>
Via: SIP/2.0/TCP 192.0.2.162 Via: SIP/2.0/TCP 192.0.2.162
;branch=z9hG4bK-9b7f69455266f7cccd4ae8a285c0417c ;branch=z9hG4bK-9b7f69455266f7cccd4ae8a285c0417c
Via: SIP/2.0/TCP 192.0.2.162:5080 Via: SIP/2.0/TCP 192.0.2.162:5080
skipping to change at page 8, line 48 skipping to change at page 8, line 48
rarely be such good hints), and where in the forwarding sequence the rarely be such good hints), and where in the forwarding sequence the
original '9999' was changed to enter the loop. original '9999' was changed to enter the loop.
Without the returned request headers, the 483 response does not help Without the returned request headers, the 483 response does not help
the request originator (or any proxy administrator on the path) the request originator (or any proxy administrator on the path)
diagnose why the error has occurred. With it, in this case a diagnose why the error has occurred. With it, in this case a
diagnostic application running as a User Agent is able to at least diagnostic application running as a User Agent is able to at least
identify that there is a routing problem and which proxy is identify that there is a routing problem and which proxy is
misrouting the request. misrouting the request.
2.4. Implementation Experience 2.4. Pruning Responses
One open source implementation has been generating 483 responses as A server may be unable or unwilling to return the full request
recommended above for well over a year, and have explicitly tested message in every 483 response. The returned message may exceed the
both at SIPit and in production use for any interoperability problems maximum message size it can handle, or may include security-sensitive
it might cause. No problems have been observed, except with some information.
It is suggested in this case that at least all of the Route and Via
headers from the request be returned in the message/sipfrag body. In
the example (Section 2.3), this would at least enable the end user to
determine which proxies were in the routing loop and how the request
arrived there, but not the specific address transformations that
caused the loop.
If including all Via and Route headers is still too large, the
implementation SHOULD remove the oldest Vias (those nearest the
message originator) until the size is acceptable. This way, the
originator can detect that some Vias were removed (because the one
that it put on is missing).
3. Implementation Experience
One open source implementation has been generating 483 responses
roughly as recommended above, this has been explicitly tested both at
SIPit and in production use for any interoperability problems it
might cause. No problems have been observed, except with some
implementations that cannot reassemble fragmented UDP packets (these implementations that cannot reassemble fragmented UDP packets (these
implementations tend to have problems with long paths). implementations tend to have problems with long paths in any case).
3. IANA Considerations 4. IANA Considerations
None. None.
4. Security Considerations 5. Security Considerations
The proposed mechanism provides a means by which topology and some The proposed mechanism provides a means by which topology and some
routing information about a set of SIP systems can be discovered. routing information about a set of SIP systems can be discovered.
The mechanism is very similar to that provided for IP routing by the The mechanism is very similar to that provided for IP routing by the
traceroute tool. traceroute tool.
Some systems may not want to expose as much information as is Some systems may not want to expose as much information as is
available in the full set of SIP request headers by returning them in available in the full set of SIP request headers by returning them in
the error response body. It is suggested in this case that at least the error response body. In this case, the system returning the
all of the Route and Via headers from the request be returned in the error should prune the response as recommended in Section 2.4.
message/sipfrag body. In the example (Section 2.3), this would at
least enable the end user to determine which proxies were in the
routing loop and how the request arrived there, but not the specific
address transformations that caused the loop.
5. References 6. References
5.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag", [RFC3420] Sparks, R., "Internet Media Type message/sipfrag",
RFC 3420, November 2002. RFC 3420, November 2002.
5.2. Informative References 6.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981. September 1981.
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
[maxforward]
Lawrence, S., Hawrylyshen, A., and R. Sparks, "Problems
with Max-Forwards Processing (and Potential Solutions)".
Authors' Addresses Authors' Addresses
Scott Lawrence Scott Lawrence
Pingtel Corp. Pingtel Corp.
400 West Cummings Park 400 West Cummings Park
Suite 2200 Suite 2200
Woburn, MA 01801 Woburn, MA 01801
USA USA
Phone: +1 781 938 5306 Phone: +1 781 938 5306
 End of changes. 19 change blocks. 
46 lines changed or deleted 56 lines changed or added

This html diff was produced by rfcdiff 1.31. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/