DISPATCH WG V. Pascual
Internet-Draft J. Janak
Intended status: BCP J. Kuthan
Expires: January 4, 2010 R. Coeffic
Tekelec
July 3, 2009
A SIP Flight Data Recorder Extension
draft-kuthan-dispatch-diagrevived-00
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 4, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Pascual, et al. Expires January 4, 2010 [Page 1]
Internet-Draft SIP Flight Data Recorder July 2009
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
A major responsibility of Session Initiation Protocol (SIP) servers
is to provide application-layer routing. SIP routing can be quite
complex and lead to similarly complicated paths that SIP requests
traverse on the way to their actual destinations. It is therefore
important to be in position to troubleshoot errors that occur along a
SIP path, inside and outside troubleshooters' administrative domains.
Particularly important for the troubleshooters is knowledge of where
an error occurred in a SIP path. This document introduces a new
header field called Debug. The purpose of the header field is to
convey extra debugging information that can be used to locate errors
in SIP implementations involved in processing of a SIP transaction.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Mode of Operation . . . . . . . . . . . . . . . . . . . . . . 5
4.1. Event SIP.RX . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Event SIP.TX . . . . . . . . . . . . . . . . . . . . . . . 7
4.3. UAS Behavior . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Proxy Server Behavior . . . . . . . . . . . . . . . . . . 8
4.6. B2BUA Behavior . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Redirect Server Behavior . . . . . . . . . . . . . . . . . 9
5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Simple REGISTER Request . . . . . . . . . . . . . . . . . 9
6.2. INVITE Without Forking . . . . . . . . . . . . . . . . . . 10
6.3. INVITE With Parallel Forking . . . . . . . . . . . . . . . 11
6.4. INVITE With Serial Forking . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 14
Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 14
Pascual, et al. Expires January 4, 2010 [Page 2]
Internet-Draft SIP Flight Data Recorder July 2009
1. Introduction
Session Initiation Protocol (SIP) is an application-layer control
(signaling) protocol for creating, modifying, and terminating
sessions with one or more participants. These sessions include
Internet telephone calls, multimedia distribution, and multimedia
conferences [RFC3261]. SIP networks typically consist of User Agent
Clients (UAC), User Agent Servers (UAS) and SIP servers between them.
SIP requests, such as call invitations or instant messages, are
routed from UACs down to UASs directly or via one or more SIP
servers.
The path of a SIP request can be arbitrarily complex in a distributed
environment. The request can visit as many proxy servers along its
path as the Max-Forwards header field permits. If an attempt to
forward the request to a destination fails, stateful servers may
decide to fork the request to one or more other destinations. Also,
it is perfectly valid and useful for a request to visit a server
several times, which is called "spiral". The following graph shows
an example of such a non-trivial request path:
+-----+ REQ 1 +--------+ REQ 2 +----+
| UAC |-------->| ...... |--------------->|UAS1|
+-----+ | |<--- 500 -------+----+
| |
| proxy1 | REQ 3 +--------+
| |---------------------------->| proxy2 |--+
| | REQ 5 +----+ +--------+ |
+->| ...... |------------------->|UAS2| |
| +--------+ +----+ v
| REQ 4 |
+----------------------<------------------------------+
Figure 1: A SIP Request Path with Many Hops, Forking and a Spiral
While such application-layer routing ability gains flexibility, it
makes tracing network errors quite difficult. When an error occurs
in the request path, upstream elements have very little knowledge
about what has gone wrong and why. They know final status from
status lines in SIP responses, and at the server's discretion, the
server's name (without port number) in Warning header field.
Important information for locating the cause of negative reply
remains hidden downstream. Particularly, upstream troubleshooters do
not know:
Pascual, et al. Expires January 4, 2010 [Page 3]
Internet-Draft SIP Flight Data Recorder July 2009
- What was the resource requested and identified by a URI. The
request originally requesting the resource sip:john@doe.com could
have failed because at the moment of failure it was requesting
sip:voicemail@foo.bar.
- If spirals occurred, which spiral iteration failed. The same
request can visit the same server several times and fail at a
later iteration.
- Who was the second-to-last hop, which might have indeed caused
the request to fail. It may be that in fact every thinkable SIP
server would decline a request malformed by a previous hop. We
however do not know, which server it was.
- Should forwarding to next hop have failed, we do not know what
the hop was.
- Status of individual branches on a SIP server that forked the
SIP request to multiple downstream destinations, either using
serial or parallel forking.
- Processing delay introduced by SIP servers along the path of a
SIP request or SIP resonse.
Lack of this information makes troubleshooting of SIP networks
difficult, even if very few SIP hops are involved in a request's
path. Manual troubleshooting is difficult without sufficient
information and even more difficult is automated error detection,
reporting, and statistics collection. The difficulty grows with the
complexity of the request path and by the presence of multiple
administrative domains, which prohibit troubleshooters from watching
operation at foreign SIP hops.
The Warning header field [RFC3261] is used to carry additional
information about the status of a response and contain a three-digit
warning code, host name, and warning text. But this is often not
sufficient. Here we propose to introduce a place for additional
debugging information to SIP.
Details are described in the following sections.
2. Applicability
This draft updates [RFC3261] and applies to any of its extensions.
Pascual, et al. Expires January 4, 2010 [Page 4]
Internet-Draft SIP Flight Data Recorder July 2009
3. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC 2119 [RFC2119].
The other concepts and terminology used in this document are
compatible with [RFC3261].
4. Mode of Operation
We propose a very simple answer to the problem of SIP's lack of
debugging information. Have SIP servers declining a request shared
additional information about the failing request as it appeared to
the SIP server. This way, all elements along the SIP path, that have
logical interest in learning the error cause regardless to which
administrative domain they belong, obtain visibility to the problem.
Fortunately, SIP servers know lot of information that can facilitate
troubleshooting:
1. They know the Request-URI of the incoming SIP request. SIP
servers usually rewrite the incoming Request-URI with a different
value and thus the original value may be lost after the server
forwarded the request downstream. The original value of the
Request-URI is useful for troubleshooting purposes, because it
refers to the original target of the SIP request and it is useful
for troubleshooting of routing plans.
2. SIP Servers know the number of Via header fields in a request.
This information is useful for troubleshooting of scenarios that
involve spiraling, i.e. when the request hits the same SIP server
several times. SIP servers add Via headers to SIP requests and
remove them from SIP responses, thus the information about the
number of Via header fields is lost when the final response
reaches the originating user agent.
3. The troubleshooter may need to know the source IP address and
port of the incoming request. This is useful to know because the
previous hop might be the hop that is responsible for the error.
4. The destination IP address and port of the outgoing SIP message
could be useful to troubleshoot transport level problems, such as
misrouted SIP messages or unresponsive servers or user agents.
5. Processing delay. SIP servers can record how long it took to
process a SIP message, from the moment the SIP message was
Pascual, et al. Expires January 4, 2010 [Page 5]
Internet-Draft SIP Flight Data Recorder July 2009
received until it was sent out. The routing logic implemented in
SIP servers may involve operations that take some time to
complete, such as DNS queries, ENUM lookups, database queries,
etc.
SIP servers can collect this information and store it in SIP requests
or responses. This document introduces a new header field called
Debug that can be used to collect debugging information in SIP
messages. The header field can be later used by a troubleshooter to
reconstruct what happened on individual SIP servers along a path of a
SIP request and associated SIP responses.
A SIP message may contain multiple Debug header fields. SIP
implementations add new Debug header fields at the beginning of the
SIP message, before any other existing Debug headers. This header
field order facilitates processing at SIP servers, because SIP
servers can always add their Debug header fields at the beginning of
the SIP message, without parsing the whole SIP message header and
searching for the last Debug header.
Each Debug header fields contains an identifier of the SIP server or
user agent that generated it, followed by a comma separated list of
events that occurred while the SIP messages was being processed. If
a single Debug header field contains more than one event then they
are ordered from the most recent one to the least recent one. Just
like Debug headers themselves within the SIP message header.
Each event is is identified by a name. This document specifies only
a minimal set of events that every conforming implementation should
support, but the mechanism is extensible. Implementations may record
additional implementation-specific events. Additional information,
such as source IP address and port or the incoming Request-URI are
stored in form of a list of semicolon-separated parameters.
The following SIP message header excerpt shows an example of Debug
header fields generated by a SIP server. The first event, bottom-
most, named SIP.RX, shows that the SIP server received a SIP request.
The second event, named SIP.TX, shows that the SIP server forwarded
the request downstream.
Debug: 192.0.2.10:5060
SIP.TX;dst=UDP:192.0.2.1:5060;code=500;delay=20,
SIP.RX;src=UDP:192.0.2.1:5060;ruri="sip:example.com";via=1
Debug Header Example
Pascual, et al. Expires January 4, 2010 [Page 6]
Internet-Draft SIP Flight Data Recorder July 2009
4.1. Event SIP.RX
This event records a receipt of a SIP request or response. SIP
implementations conforming to this specification MUST record this
event. The following parameters are specified for this event:
src - This parameter contains the source IP address and port of
the packet, as well as transport protocol.
ruri - This parameter contains the Request-URI of the incoming
request. This parameter is not present if the SIP message was a
reply.
code - This parameter contains the reason code of the received SIP
reply. Not used for SIP requests.
via - The number of Via header fields in the incoming message.
delay - This parameter records the processing delay that occurred
since the previous event. The value of this parameter is the
relative number of ms since the previous event.
4.2. Event SIP.TX
This event records that a SIP request or response was sent out. All
SIP implementations conforming to this specification MUST record this
event as soon as the SIP message has been sent. The following
parameters are mandatory for this event:
dst - This parameter contains the destination IP address and port
of the outgoing packet, as well as the transport protocol used.
ruri - This parameter contains the Request-URI of the incoming
request. This parameter is not present if the SIP message was a
reply.
code - This parameter contains the reason code of the received SIP
reply. Not used for SIP requests.
delay - This parameter records the processing delay that occurred
since the previous event. The value of this parameter is the
relative number of ms since the previous event.
4.3. UAS Behavior
The troubleshooting information is produced by RFC3261 User Agent
Servers (UAS) that terminate SIP request path. The user agent that
generates a final reply first copies any existing Debug header fields
Pascual, et al. Expires January 4, 2010 [Page 7]
Internet-Draft SIP Flight Data Recorder July 2009
from the request to the reply and then it adds its own Debug headers
(if any) at the beginning of the reply.
The following example response demonstrates content of additional
diagnostic information.
SIP/2.0 500 Really Bad Error
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK14f54300fc.0
From: sip:21004041@example.com;tag=123
To: sip:21004041@example.com;tag=456
Call-ID: 415392@192.0.2.1
CSeq: 2 REGISTER
Content-Length: 0
Warning: 392 192.0.2.10 "downstream ICMP failure"
Debug: 192.0.2.10:5060
SIP.TX;dst=UDP:192.0.2.1:5060;code=500;delay=20,
SIP.RX;src=UDP:192.0.2.1:5060;ruri="sip:example.com";via=1
Figure 2: SIP Response with Embedded Diagnostic Information
Here the user agent recorded that it received a SIP request with
Request-URI sip:example.com and it generate a 500 final reply which
was then sent upstream. There were no Debug headers present in the
incoming SIP request.
4.4. UAC Behavior
User Agent Clients (UAC) that originate or forward SIP messages MAY
add Debug headers just like any other SIP elements (UAS or proxies).
4.5. Proxy Server Behavior
A proxy server acts as both a server and a client for the purpose of
making requests on behalf of other clients.
Proxy servers MUST follow the rules defined for both UAC and UAS. In
addition, proxy servers forwarding responses MUST forward debugging
information from the downstream path segment to the upstream path
segment. Forking proxy servers MUST aggregate Debug headers from all
downstream branches into the final reply that is forwarded upstream.
4.6. B2BUA Behavior
There are also Back-to-Back User Agents (concatenation of a UAC and
UAS) that terminate SIP request path while concatenating it to other
SIP paths. B2BUAs MUST follow the rules defined for both UAC and
UAS.
Pascual, et al. Expires January 4, 2010 [Page 8]
Internet-Draft SIP Flight Data Recorder July 2009
In addition, B2BUAs with roles other than topology hiding/privacy,
MUST forward debugging information from the downstream path segment
to the upstream path segment.
4.7. Redirect Server Behavior
A redirect server is a user agent server. Hence, it must follow the
rules defined for UAS.
5. Syntax
This section contains a description of the syntax of the new header
field in Augmented Backus-Naur Form (ABNF). See [RFC3261] for non-
terminals that are not defined in this document.
Debug = "Debug" HCOLON generated-by LWS debug-event *(COMMA debug-event)
generated-by = host [ COLON port ]
debug-event = event-name *( SEMI debug-params )
event-name = "SIP.TX" / "SIP.RX" / token
debug-params = debug-src / debug-dst
/ debug-ruri / debug-code
/ debug-delay / generic-param
debug-src = "src" EQUAL received
debug-dst = "dst" EQUAL received
debug-ruri = "ruri EQUAL quoted-string
debug-code = "code" EQUAL 3DIGIT
debug-delay = "delay" EQUAL 1*DIGIT
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
6. Examples
6.1. Simple REGISTER Request
In this scenario a user agent sends a REGISTER message to a registrar
and the registrar reports with an error message that indicates a
server side error.
192.0.2.1 192.0.2.10
--------- ----------
| REGISTER |
|------------->|
| |
| 500 |
|<-------------|
Pascual, et al. Expires January 4, 2010 [Page 9]
Internet-Draft SIP Flight Data Recorder July 2009
| |
Simple REGISTER Request
The following reply contains diagnostics information for two events,
the first event (bottom-most) records that the REGISTER request was
received by the registrar. The second event records that the
registrar generated a 500 reply and forwarded it to the source IP
address of the REGISTER request. Parameter delay=20 in the second
event means that it took 20ms to process the REGISTER request to the
point where the final reply was sent out.
SIP/2.0 500 Server Internal Error
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK14f54300fc.0
From: sip:bob@example.com;tag=123
To: sip:bob@example.com;tag=456
Call-ID: 415392@192.0.2.42
CSeq: 2 REGISTER
Content-Length: 0
Debug: 192.0.2.10:5060
SIP.TX;dst=UDP:192.0.2.1:5060;code=500;delay=20,
SIP.RX;src=UDP:192.0.2.1:5060;ruri="sip:example.com";via=1
Response to REGISTER Request
6.2. INVITE Without Forking
This example presents an INVITE request processed by one proxy server
without forking. The proxy server forwards the request to the target
user agent but it cannot reach the target UA because its IP address
in the user location database is not correct. After several
retransmission attempts the proxy server sends a 408 reply to the
caller
192.0.2.1 192.0.2.10 192.0.2.20
--------- ---------- ----------
| INVITE | |
|------------->| INVITE |
| |------------X |
| | INVITE |
| 408 |------------X |
|<-------------| |
| | |
Simple INVITE Without Forking
Pascual, et al. Expires January 4, 2010 [Page 10]
Internet-Draft SIP Flight Data Recorder July 2009
The following example presents the 408 response with one Debug header
generated by the proxy server. The debug header lists three events.
The second event shows that the destination IP address of the
outgoing request is different than the IP address in the Request-URI
(registered contact) and it is is probably the reason why no reply
was received from the target user agent.
SIP/2.0 408 Request Timeout
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK14f54300fc.0
From: sip:bob@example.com;tag=123
To: sip:alice@example.com;tag=456
Call-ID: 415392@192.0.2.1
CSeq: 2 INVITE
Debug: 192.0.2.10:5060
SIP.TX;dst=UDP:192.0.2.1;5060;code=408,delay=7000;via=1,
SIP.TX;dst=UDP:192.0.2.40:5060;ruri="sip:alice@192.0.2.20";via=2,delay=50,
SIP.RX;src=UDP:192.0.2.1:5060;ruri="sip:alice@example.com";via=1
6.3. INVITE With Parallel Forking
This example illustrates how the Debug header can be used to ease
debugging of a forking proxy. In this scenario the proxy server
forks a requeset to two user agents. One of the user agents replies
with a 400 reply immediately, indicating that it cannot parse the
request. The other user agent replies with a 200 OK and this reply
is then forwarded upstream by the proxy server.
192.0.2.1 192.0.2.10 192.0.2.20 192.0.2.21
--------- ---------- ---------- ----------
| INVITE | | |
|------------->| INVITE | |
| |------------->| INVITE |
| |------------- | ------------>|
| | | 400 |
| |<------------ | -------------|
| | 200 | |
| 200 |<-------------| |
|<-------------| | |
Headers as seen by CALLER. Here we can tell that the proxy used
parallel forking because both SIP.TX events for downstream branches
are recorded before any SIP.RX event responses generated by CALLEE1
and CALLEE2. Also, as you can see in this example, the proxy server
first appended Debug headers from the received response (Debug:
Pascual, et al. Expires January 4, 2010 [Page 11]
Internet-Draft SIP Flight Data Recorder July 2009
CALLEE1) and the event that records the receipt of the response was
recorded after that (Debug: PROXY).
The following example shows the 200 OK reply forwarded by the proxy
server to the calling user agent. The message contains three Debug
header fields, the bottom most header field was generated by the
proxy server for the INVITE request. The middle Debug header field
was generated by the user agent that generated 400 and it was
appended to the 400 and later copied by the proxy server into the 200
reply forwarded upstream. The top-most Debug header field was
generated by the proxy server and added to the final 200. One of the
called user agents did not generate any Debug header field.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK14f54300fc.0
From: sip:bob@example.com;tag=123
To: sip:alice@example.com;tag=456
Call-ID: 415392@192.0.2.1
CSeq: 2 INVITE
Debug: 192.0.2.10:5060
SIP.TX;dst=UDP:192.0.2.1:5060;code=200;via=1,
SIP.RX;src=UDP:192.0.2.21:5060;code=200;via=2,
SIP.RX;src=UDP:192.0.2.20:5060;code=400;via=2
Debug: 192.0.2.20:5060
SIP.TX;dst=UDP:192.0.2.10:5060;code=400;delay=80,
SIP.RX;src=UDP:192.0.2.10:5060;via=2
Debug: 192.0.2.10:5060
SIP.TX;dst=UDP:192.0.2.21:5060;ruri="sip:alice2@192.0.2.21";via=2;delay=50,
SIP.TX;dst=UDP:192.0.2.20:5060;ruri="sip:alice1@192.0.2.20";via=2;delay=50,
SIP.RX;src=UDP:192.0.2.1:5060;ruri="sip:alice@example.com";via=1
Without Debug header fields the troubleshooter would only get the
final 200 and there would be nothing to indicate that the proxy
server forked the request and one of the branches received a 400
reply. With the Debug headers the troubleshooter knows exactly how
many downstream branches were created by the forking proxy server and
what was their status. Note that the troubleshooter can tell that
the proxy used parallel forking from the bottom-most Debug header
field, because both SIP.TX events (representing the outgoing INVITE
requests) are recorded one after another, without any SIP.RX
(representing a message received from downstream) in between.
6.4. INVITE With Serial Forking
This example is similar to the previous one, except that this time
the proxy server used serial forking and forwarded the INVITE request
to the second branch after it received a 400 from the first branch.
Pascual, et al. Expires January 4, 2010 [Page 12]
Internet-Draft SIP Flight Data Recorder July 2009
192.0.2.1 192.0.2.10 192.0.2.20 192.0.2.21
--------- ---------- ---------- ----------
| INVITE | | |
|----------->| INVITE | |
| |------------->| |
| | 400 | |
| |<-------------| |
| | | INVITE |
| |------------- | ----------->|
| | 200 | |
| 200 |<------------ | ------------|
|<-----------| | |
| | | |
In this particular example the SIP.TX event with the ruri parameter
set to "sip:alice2@192.0.2.21" comes after a SIP.RX event generated
for the 400 received from one of the user agents. This indicates
that the proxy used serial forking.
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bK14f54300fc.0
From: sip:bob@example.com;tag=123
To: sip:alice@example.com;tag=456
Call-ID: 415392@192.0.2.1
CSeq: 2 INVITE
Debug: 192.0.2.10
SIP.TX;dst=UDP:192.0.2.1:5060;code=200;via=1,
SIP.RX;src=UDP:192.0.2.21:5060;code=200;via=2,
SIP.TX;dst=UDP:192.0.2.21:5060;ruri="sip:alice2@192.0.2.21";via=2;delay=50,
SIP.RX;src=UDP:192.0.2.20:5060;code=400;via=2
Debug: 192.0.2.20
SIP.TX;dst=UDP:192.0.2.10:5060;code=400;delay=80;via=2,
SIP.RX;src=UDP:192.0.2.10:5060;via=2
Debug: 192.0.2.10
SIP.TX;dst=UDP:192.0.2.20:5060;ruri="sip:alice1@192.0.2.20";via=2;delay=50,
SIP.RX;src=UDP:192.0.2.1:5060;ruri="sip:alice@example.com";via=1
7. Security Considerations
The key concern is disclosure of information which may not suit a SIP
operator's policy. See [Appendix B. Open Issues] for more details.
We are leaving this decision to operational policies and recommend
disclosing troubleshooting information. Similarly like with 'ping'
and 'traceroute', troubleshooting information is invaluable in daily
Internet's operation.
Pascual, et al. Expires January 4, 2010 [Page 13]
Internet-Draft SIP Flight Data Recorder July 2009
8. IANA Considerations
TBD
9. Acknowledgments
Thanks to Alan Johnston for a review of the original version of the
document
10. References
10.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.
10.2. Informative References
[I-D.ietf-sip-hop-limit-diagnostics] Lawrence, S., Hawrylyshen, A.,
and R. Sparks, "Diagnostic
Responses for Session
Initiation Protocol Hop Limit
Errors", June 2006.
Appendix A. Change Log
Initial version has been submitted in October 2002 as
draft-kuthan-sipping-diag-00.txt
Appendix B. Open Issues
1. Topology Hiding. Numerous discussions on the IETF mailing list
have revealed that many seem to be concerned about privacy of SIP
networks. The additional troubleshooting information disclosed
as suggested in this document can indeed provide many
disclosures. Disclosing URIs can tell more about routing and
callee preferences. Disclosing one's IP addresses as well as its
neighbors provides hints about topology of a SIP network. It is
obviously a trade-off between ability to troubleshoot and ability
Pascual, et al. Expires January 4, 2010 [Page 14]
Internet-Draft SIP Flight Data Recorder July 2009
to hide (Topology Hiding) -- one cannot have both. We are
leaving this trade-off as a policy decision to operators and
RECOMMEND to favor the troubleshooting aspect.
2. Amount of troubleshooting information. SIP replies cannot be
endless in size. If transported over UDP, packets may be
fragmented and fail to traverse NATs that do not support
defragmentation. To make sure that reply delivery will not fail,
we are limiting ourselves only to the information specified in
previous section. Note that there has been attempt to provide
more exhaustive debugging information by mirroring the whole SIP
requests or parts of it [I-D.ietf-sip-hop-limit-diagnostics].
This attempt has not advanced due to unresolved handling of reply
size.
3. Selective logging. A mechanism that would instruct SIP entities
to selectively enable/disable logging of debugging information
might be required in order to prevent too big SIP messages
4. B2BUA traversal. The troubleshooting information is produced by
RFC3261 User Agent Servers that terminate SIP request path.
There are also Back-to-Back User Agents that terminate SIP
request path while concatenating it to other SIP paths. We
suggest that these elements forward debugging information from
the downstream path segment to the upstream path segment. This
may create additional confusion that needs to be addressed.
(Whose IP is it in Warning: B2BUA's or the error originator's
from downstream path segment?)
Authors' Addresses
V. Pascual
Tekelec
Am Borsigturm 11
Berlin
Germany
Phone: +49 30 32 51 32 12
EMail: victor@iptel.org
Pascual, et al. Expires January 4, 2010 [Page 15]
Internet-Draft SIP Flight Data Recorder July 2009
J. Janak
Tekelec
Luzna 2
Prague
Czech Republic
EMail: jan@iptel.org
J. Kuthan
Tekelec
Am Borsigturm 11
Berlin
Germany
Phone: +49 30 32 51 32 13
EMail: Jiri.Kuthan@tekelec.com
R. Coeffic
Tekelec
Am Borsigturm 11
Berlin
Germany
Phone: +49 30 32 51 32 18
EMail: raphael@iptel.org
Pascual, et al. Expires January 4, 2010 [Page 16]