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]