SIP WG S. Lawrence
Internet-Draft Pingtel Corp.
Expires: August 28, 2006 A. Hawrylyshen
Ditech Communications Corp.
R. Sparks
Estacado Systems
February 24, 2006
Diagnostic Responses for SIP Hop Limit Errors
draft-ietf-sip-hop-limit-diagnostics-00
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 August 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
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
483 error response is returned. The present form of the 483 response
does not provide enough information for the sender or proxies on the
path to diagnose failures whose symptom is that the hop limit is
Lawrence, et al. Expires August 28, 2006 [Page 1]
Internet-Draft Diagnostics for SIP 483 February 2006
reached. This document proposes additional diagnostic information to
be returned in a 483 response.
Comments are solicited, and should be directed to the SIP working
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
1. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
2. Diagnosing Hop Limit Exceeded Failures . . . . . . . . . . . . 3
2.1. Limitations of the 483 Error Response . . . . . . . . . . 3
2.2. Returning Useful Diagnostic Information in 483
Responses . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Implementation Experience . . . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Normative References . . . . . . . . . . . . . . . . . . . 9
5.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . . . 12
Lawrence, et al. Expires August 28, 2006 [Page 2]
Internet-Draft Diagnostics for SIP 483 February 2006
1. Conventions and Definitions
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 [RFC2119].
2. Diagnosing Hop Limit Exceeded Failures
The SIP protocol imposes a limit on the number of hops a request may
make from a sender to the recipient. The number of hops remaining
for the request is carried in the Max-Forwards header, and is
decremented each time the request is forwarded. When a SIP User
Agent receives a request whose Max-Forwards is zero, it returns a 483
error response to indicate that the limit was reached.
The 483 response alone does not provide enough information, for the
sender to determine where the problem lies. In the authors
experience, the problem is rarely that the target of the request was
actually further away than the Max-Forwards limit allowed. The
problem is usually incorrect routing; often a routing loop.
2.1. Limitations of the 483 Error Response
Section 20.22 of RFC 3261 [RFC3261] says:
The Max-Forwards header field must be used with any SIP method to
limit the number of proxies or gateways that can forward the
request to the next downstream server. This can also be useful
when the client is attempting to trace a request chain that
appears to be failing or looping in mid-chain.
In practice, there is too little information returned in a 483
response for it to be of much use as a diagnostic. When a request
has traversed a series of proxies, the response follows the Vias back
to the requester; in the case of a typical 483 response it can be
difficult to determine even what server the response came from. Even
when the rejecting server does identify itself, it can be difficult
to figure out why the request got there.
Lawrence, et al. Expires August 28, 2006 [Page 3]
Internet-Draft Diagnostics for SIP 483 February 2006
The following is an actual example request; the IP addresses and
domain names have been changed, but it is otherwise complete (it was
intentionally sent without SDP for brevity):
INVITE sip:9999@example.com SIP/2.0
Via: SIP/2.0/TCP 10.1.1.20:59449
;branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04
To: sip:9999@example.com
From: Sip Send <sip:sipsend@10.1.1.20>;tag=08e2f515
Call-ID: 159213b1aa5a67bc6eca6c4c2bad9f94@10.1.1.20
Cseq: 1 INVITE
Max-Forwards: 1
User-Agent: sipsend/0.02
Date: Wed, 12 Oct 2005 20:09:29 GMT
Content-Length: 0
This request was sent with the Max-Forwards value set to only 1 to
force the error response: it should traverse only the first outbound
proxy, and then be rejected by the next system that it encounters.
The response received in this case was:
SIP/2.0 483 Too Many Hops
Via: SIP/2.0/TCP 10.1.1.20:59449
;branch=z9hG4bK-56ec69968c31f498c9a5573a00c8fc04
To: sip:9999@example.com;tag=-1574266585
From: Sip Send <sip:sipsend@10.1.1.20>;tag=08e2f515
Call-ID: 159213b1aa5a67bc6eca6c4c2bad9f94@10.1.1.20
Cseq: 1 INVITE
Content-Length: 0
There is no indication in the response of what server returned the
error. Even with the error only one hop beyond the first proxy,
there is no way to determine if that first proxy has routed the
request incorrectly.
2.2. Returning Useful Diagnostic Information in 483 Responses
In some ways, the Max-Forwards mechanism is analogous to the Time To
Live (TTL) field in an IP datagram. The TTL field was originally
[RFC0791] intended to be the maximum number of seconds that a
datagram should remain in the network. In practice, IP TTL has
evolved into a hop count, since each system forwarding a datagram was
(is) required to decrement the TTL by (at least) one. As an aid to
diagnosing problems, the Internet Control Message Protocol [RFC0792]
defines a "Time Exceeded Message" to be sent by any system that
Lawrence, et al. Expires August 28, 2006 [Page 4]
Internet-Draft Diagnostics for SIP 483 February 2006
discards an IP datagram because it was received with a TTL value of
zero. The Time Exceeded Message is sent to the source address of the
discarded datagram, and includes a field that carries the "Internet
Header + 64 bits of Original Data Datagram". This allows the sender
to see the datagram as it appeared where it was discarded. The
'traceroute' tool determines the route followed between a given pair
of IP addresses by sending a series of IP packets from the source to
the destination with gradually increasing TTL values. As each packet
reaches its limit, an ICMP Time Exceeded Message is returned by the
router that is discarding it; some checks on the route can be made by
examining the original packet as it arrived at each hop.
As an aid to diagnosing problems that result in 483 responses, it
would be useful to know how the failed request arrived at the
rejecting system; both what path it followed to get there, and what
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
to the sender. Doing so is already allowed by existing rules:
RFC 3261 (section 7.4) says: "All responses MAY include a body.".
RFC 3420 [RFC3420] defines the Content-Type "message/sipfrag" to
"allow SIP entities to make assertions about a subset of a SIP
message".
This document proposes the following new rule for all SIP
implementations:
Any 483 response SHOULD be constructed with a message body of type
message/sipfrag containing as much as possible of the SIP header
from the rejected request.
2.3. Example
We will use this proposed change to diagnose an example routing
problem.
Lawrence, et al. Expires August 28, 2006 [Page 5]
Internet-Draft Diagnostics for SIP 483 February 2006
Here is a request sent to a proxy that implements the suggested
content in a 483 response.
INVITE sip:9999@interop.pingtel.com SIP/2.0
Via: SIP/2.0/TCP 10.1.1.20:40221
;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f
To: sip:9999@interop.pingtel.com
From: Sip Send <sip:sipsend@10.1.1.20>;tag=612f37e7
Call-ID: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20
Cseq: 1 INVITE
Max-Forwards: 9
User-Agent: sipsend/0.02
Date: Fri, 14 Oct 2005 15:35:53 GMT
Content-Length: 0
The target user '9999' is one that has been deliberately configured
to go into a forwarding loop alternating between two addresses
(neither of them the original target); a situation that is currently
difficult to diagnose. A relatively low Max-Forwards value of 9 was
chosen to improve readability.
Lawrence, et al. Expires August 28, 2006 [Page 6]
Internet-Draft Diagnostics for SIP 483 February 2006
The response received was:
SIP/2.0 483 Too many hops
From: Sip Send <sip:sipsend@10.1.1.20>;tag=612f37e7
To: sip:9999@interop.pingtel.com
Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20
Cseq: 1 INVITE
Via: SIP/2.0/TCP 10.1.1.20:40221
;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f
Content-Type: message/sipfrag
Content-Length: 1014
Date: Fri, 14 Oct 2005 15:27:47 GMT
INVITE sip:InfiniteLoop@interop.pingtel.com SIP/2.0
Record-Route: <sip:192.0.2.162:5080
;lr;a;t=612f37e7;s=96e09e8e8c93a8c60bf460029847f4b1>
Via: SIP/2.0/TCP 192.0.2.162
;branch=z9hG4bK-42e47bba67559bd9a3da1934a70bbc37
Via: SIP/2.0/TCP 192.0.2.162:5080
;branch=z9hG4bK-50d909f1209f7a820de85c7831846330
Via: SIP/2.0/TCP 192.0.2.162
;branch=z9hG4bK-994f162bc179fb75093166fabbfd13c7
Via: SIP/2.0/TCP 192.0.2.162:5080
;branch=z9hG4bK-708842ad6ea22f8fa6e39c503d3d803e
Via: SIP/2.0/TCP 192.0.2.162
;branch=z9hG4bK-50b581a06ca023ebcddbc82c5221149c
Via: SIP/2.0/TCP 192.0.2.14:1084
;branch=z9hG4bK994220327571023745d7996c13560a11.0
Via: SIP/2.0/TCP 192.0.2.14:40221
;branch=z9hG4bK-931ea14405e9da8c95cf4ed60a71f59f
To: sip:9999@interop.pingtel.com
From: Sip Send <sip:sipsend@10.1.1.20>;tag=612f37e7
Call-Id: 7a26fdad2cb40d48e81e10d6fce39825@10.1.1.20
Cseq: 1 INVITE
Max-Forwards: 0
User-Agent: sipsend/0.02
Date: Fri, 14 Oct 2005 15:35:53 GMT
Content-Length: 0
This response shows what server returned the error; its' address -
192.0.2.162 - is in the topmost Via of the returned request. It also
shows that the target URI has been changed to the user
'InfiniteLoop'.
Lawrence, et al. Expires August 28, 2006 [Page 7]
Internet-Draft Diagnostics for SIP 483 February 2006
Resending the request with a hop limit one less than before (8),
shows that at that hop the request URI is to user 'LoopForever':
INVITE sip:LoopForever@interop.pingtel.com SIP/2.0
Record-Route: <sip:192.0.2.162:5080
;lr;a;t=4f18a30b;s=a9711e1704ccd5273955589c5fe94745>
Via: SIP/2.0/TCP 192.0.2.162
;branch=z9hG4bK-9b7f69455266f7cccd4ae8a285c0417c
Via: SIP/2.0/TCP 192.0.2.162:5080
;branch=z9hG4bK-b9d3e2aff65e68497849a2609bf8c373
Via: SIP/2.0/TCP 192.0.2.162
;branch=z9hG4bK-a178f4c5a3b8bbf35f979bc6c6d33022
Via: SIP/2.0/TCP 192.0.2.162:5080
;branch=z9hG4bK-3c098b8d58e4b6ce98fca3495263e795
Via: SIP/2.0/TCP 192.0.2.162
;branch=z9hG4bK-e7ceb06ed917d59024c905b3ee60e4cc
Via: SIP/2.0/TCP 192.0.2.14:1085
;branch=z9hG4bK8d685f52450e87da45d7996c13560a11.0
Via: SIP/2.0/TCP 192.0.2.14:56114
;branch=z9hG4bK-4ae5a563b0cbc76aef7be17115836dea
To: sip:9999@interop.pingtel.com
From: Sip Send <sip:sipsend@10.1.1.20>;tag=4f18a30b
Call-Id: 39106d45526cb5e78bf8dac378e05817@10.1.1.20
Cseq: 1 INVITE
Max-Forwards: 0
User-Agent: sipsend/0.02
Date: Fri, 14 Oct 2005 15:42:21 GMT
Content-Length: 0
Route: <sip:192.0.2.162:5070;transport=tcp;lr>
Reducing the limit one at a time (or starting from 1 and working
forward), the sender can determine that the InfiniteLoop/LoopForever
forwarding loop exists (in reality, of course, the user names would
rarely be such good hints), and where in the forwarding sequence the
original '9999' was changed to enter the loop.
Without the returned request headers, the 483 response does not help
the request originator (or any proxy administrator on the path)
diagnose why the error has occurred. With it, in this case a
diagnostic application running as a User Agent is able to at least
identify that there is a routing problem and which proxy is
misrouting the request.
2.4. Implementation Experience
One open source implementation has been generating 483 responses as
recommended above for well over a year, and have explicitly tested
Lawrence, et al. Expires August 28, 2006 [Page 8]
Internet-Draft Diagnostics for SIP 483 February 2006
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 tend to have problems with long paths).
3. IANA Considerations
None.
4. Security Considerations
The proposed mechanism provides a means by which topology and some
routing information about a set of SIP systems can be discovered.
The mechanism is very similar to that provided for IP routing by the
traceroute tool.
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
the error response body. 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.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3420] Sparks, R., "Internet Media Type message/sipfrag",
RFC 3420, November 2002.
5.2. Informative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
Lawrence, et al. Expires August 28, 2006 [Page 9]
Internet-Draft Diagnostics for SIP 483 February 2006
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981.
[maxforward]
Lawrence, S., Hawrylyshen, A., and R. Sparks, "Problems
with Max-Forwards Processing (and Potential Solutions)".
Lawrence, et al. Expires August 28, 2006 [Page 10]
Internet-Draft Diagnostics for SIP 483 February 2006
Authors' Addresses
Scott Lawrence
Pingtel Corp.
400 West Cummings Park
Suite 2200
Woburn, MA 01801
USA
Phone: +1 781 938 5306
Email: slawrence@pingtel.com
Alan Hawrylyshen
Ditech Communications Corp.
602 - 11 Ave SW
Suite 310
Calgary, Alberta T2R 1J8
Canada
Phone: +1 403 561 7313
Email: ahawrylyshen@ditechcom.com
Robert Sparks
Estacado Systems
17210 Campbell Road
Suite 250
Dallas, Texas 75254-4203
USA
Email: RjS@nostrum.com
Lawrence, et al. Expires August 28, 2006 [Page 11]
Internet-Draft Diagnostics for SIP 483 February 2006
Intellectual Property Statement
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lawrence, et al. Expires August 28, 2006 [Page 12]
