idnits 2.17.1 draft-ietf-sipclf-problem-statement-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 6, 2011) is 4708 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-sipclf-format-01 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCLF V. Gurbani, Ed. 3 Internet-Draft Bell Laboratories, Alcatel-Lucent 4 Intended status: Informational E. Burger, Ed. 5 Expires: December 8, 2011 Georgetown University 6 T. Anjali 7 Illinois Institute of Technology 8 H. Abdelnur 9 O. Festor 10 INRIA 11 June 6, 2011 13 The Common Log Format (CLF) for the Session Initiation Protocol (SIP) 14 draft-ietf-sipclf-problem-statement-07 16 Abstract 18 Well-known web servers such as Apache and web proxies like Squid 19 support event logging using a common log format. The logs produced 20 using these de-facto standard formats are invaluable to system 21 administrators for trouble-shooting a server and tool writers to 22 craft tools that mine the log files and produce reports and trends. 23 Furthermore, these log files can also be used to train anomaly 24 detection systems and feed events into a security event management 25 system. The Session Initiation Protocol does not have a common log 26 format, and as a result, each server supports a distinct log format 27 that makes it unnecessarily complex to produce tools to do trend 28 analysis and security detection. We propose a common log file format 29 for SIP servers that can be used uniformly by proxies, registrars, 30 redirect servers as well as back-to-back user agents. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on December 8, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 69 4. What SIP CLF is and what it is not . . . . . . . . . . . . . . 4 70 5. Alternative approaches to SIP CLF . . . . . . . . . . . . . . 5 71 5.1. SIP CLF and CDRs . . . . . . . . . . . . . . . . . . . . . 5 72 5.2. SIP CLF and Wireshark packet capture . . . . . . . . . . . 6 73 6. Motivation and use cases . . . . . . . . . . . . . . . . . . . 6 74 7. Challenges in establishing a SIP CLF . . . . . . . . . . . . . 8 75 8. Data model . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 8.1. SIP CLF mandatory fields . . . . . . . . . . . . . . . . . 10 77 8.2. Mandatory fields and SIP entities . . . . . . . . . . . . 12 78 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 9.1. UAC registration . . . . . . . . . . . . . . . . . . . . . 14 80 9.2. Direct call between Alice and Bob . . . . . . . . . . . . 15 81 9.3. Single downstream branch call . . . . . . . . . . . . . . 17 82 9.4. Forked call . . . . . . . . . . . . . . . . . . . . . . . 22 83 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 84 11. Operational guidance . . . . . . . . . . . . . . . . . . . . . 32 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 86 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 88 14.1. Normative References . . . . . . . . . . . . . . . . . . . 33 89 14.2. Informative References . . . . . . . . . . . . . . . . . . 33 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 92 1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 RFC 3261 [RFC3261] defines additional terms used in this document 99 that are specific to the SIP domain such as "proxy"; "registrar"; 100 "redirect server"; "user agent server" or "UAS"; "user agent client" 101 or "UAC"; "back-to-back user agent" or "B2BUA"; "dialog"; 102 "transaction"; "server transaction". 104 This document uses the term "SIP Server" that is defined to include 105 the following SIP entities: user agent server, registrar, redirect 106 server, a SIP proxy in the role of user agent server, and a B2BUA in 107 the role of a user agent server. 109 2. Introduction 111 Servers executing on Internet hosts produce log records as part of 112 their normal operations. A log record is, in essence, a summary of 113 an application layer protocol data unit (PDU), that captures in 114 precise terms an event that was processed by the server. These log 115 records serve many purposes, including analysis and troubleshooting. 117 Well-known web servers such as Apache and Squid support event logging 118 using a Common Log Format (CLF), the common structure for logging 119 requests and responses serviced by the web server. It can be argued 120 that a good part of the success of Apache has been its CLF because it 121 allowed third parties to produce tools that analyzed the data and 122 generated traffic reports and trends. The Apache CLF has been so 123 successful that not only did it become the de-facto standard in 124 producing logging data for web servers, but also many commercial web 125 servers can be configured to produce logs in this format. An example 126 of Apache CLF is depicted next: 128 %h %l %u %t \"%r\" %s %b 129 remotehost rfc931 authuser [date] request status bytes 131 remotehost: Remote hostname (or IP number if DNS hostname is not 132 available, or if DNSLookup is Off. 134 rfc931: The remote logname of the user. 136 authuser: The username by which the user has authenticated himself. 138 [date]: Date and time of the request. 140 request: The request line exactly as it came from the client. 142 status: The HTTP status code returned to the client. 144 bytes: The content-length of the document transferred. 146 The inspiration for the SIP CLF is the Apache CLF. However, the 147 state machinery for a HTTP transaction is much simpler than that of 148 the SIP transaction (as evidenced in Section 7). The SIP CLF needs 149 to do considerably more. 151 3. Problem statement 153 The Session Initiation Protocol [RFC3261](SIP) is an Internet 154 multimedia session signaling protocol that is increasingly used for 155 other services besides session establishment. A typical deployment 156 of SIP in an enterprise will consist of SIP entities from multiple 157 vendors. Currently, if these entities are capable of producing a log 158 file of the transactions being handled by them, the log files are 159 produced in a proprietary format. The result of multiplicity of the 160 log file formats is the inability of the support staff to easily 161 trace a call from one entity to another, or even to craft common 162 tools that will perform trend analysis, debugging and troubleshooting 163 problems uniformly across the SIP entities of multiple vendors. 165 SIP does not currently have a CLF format and this document serves to 166 provide the rationale to establish a SIP CLF and identifies the 167 required minimal information that must appear in any SIP CLF record. 169 4. What SIP CLF is and what it is not 171 The SIP CLF is a standardized manner of producing a log file. This 172 format can be used by SIP clients, SIP Servers, proxies, and B2BUAs. 173 The SIP CLF is simply an easily digestible log of currently occurring 174 events and past transactions. It contains enough information to 175 allow humans and automata to derive relationships between discrete 176 transactions handled at a SIP entity or to search for a certain 177 dialog or a related set of transactions. 179 The SIP CLF is amenable to quick parsing (i.e., well-delimited 180 fields) and it is platform and operating system neutral. 182 The SIP CLF is amenable to easy parsing and lends itself well to 183 creating other innovative tools. 185 The SIP CLF is not a billing tool. It is not expected that 186 enterprises will bill customers based on SIP CLF. The SIP CLF 187 records events at the signaling layer only and does not attempt to 188 correlate the veracity of these events with the media layer. Thus, 189 it cannot be used to trigger customer billing. 191 The SIP CLF is not a quality of service (QoS) measurement tool. If 192 QoS is defined as measuring the mean opinion score (MOS) of the 193 received media, then SIP CLF does not aid in this task since it does 194 not summarize events at the media layer. 196 5. Alternative approaches to SIP CLF 198 It is perhaps tempting to consider other approaches --- which though 199 not standardized, are in wide enough use in networks today --- to 200 determine whether or not a SIP CLF would benefit a SIP network 201 consisting of multi-vendor products. The two existing approaches 202 that approximate what SIP CLF does are Call Detail Records (CDRs) and 203 Wireshark packet sniffing. 205 5.1. SIP CLF and CDRs 207 CDRs are used in operator networks widely and with the adoption of 208 SIP, standardization bodies such as 3GPP have subsequently defined 209 SIP-related CDRs as well. Today, CDRs are used to implement the 210 functionality approximated by SIP CLF, however, there are important 211 differences. 213 One, SIP CLF operates natively at the transaction layer and maintains 214 enough information in the information elements being logged that 215 dialog-related data can be subsequently derived from the transaction 216 logs. Thus, esoteric SIP fields and parameters like the To header, 217 including tags; the From header, including tags, the CSeq number, 218 etc. are logged in SIP CLF. By contrast, a CDR is used mostly for 219 charging and thus saves information to facilitate that very aspect. 220 A CDR will most certainly log the public user identification of a 221 party requesting a service (which may not correspond to the From 222 header) and the public user identification of the party called party 223 (which may not correspond to the To header.) Furthermore, the 224 sequence numbers maintained by the CDR may not correspond to the SIP 225 CSeq header. Thus it will be hard to piece together the state of a 226 dialog through a sequence of CDR records. 228 Two, a CDR record will, in all probability, be generated at a SIP 229 entity performing some form of proxy-like functionality of a B2BUA 230 providing some service. By contrast, SIP CLF is light- weight enough 231 that it can be generated by a canonical SIP user agent server and 232 user agent client as well, including those that execute on resource 233 constrained devices (mobile phones). 235 Finally, SIP is also being deployed outside of operator- managed VoIP 236 networks. Universities, research laboratories, and small-to-medium 237 size companies are deploying SIP-based VoIP solutions on networks 238 owned and managed by them. Much of the latter constituencies will 239 not have an interest in generating CDRs, but they will like to have a 240 concise representation of the messages being handled by the SIP 241 entities in a common format. 243 5.2. SIP CLF and Wireshark packet capture 245 Wireshark is a popular raw packet capture tool. It contains filters 246 that can understand SIP at the protocol level and break down a 247 captured message into its individual header components. While 248 Wireshark is appropriate to capture and view discrete SIP messages, 249 it does not suffice to serve in the same capacity as SIP CLF for two 250 reasons. 252 First, all SIP entities that need to save SIP CLF records would 253 require a Wireshark library for different operating systems and 254 configurations to link into. Second, and more importantly, if the 255 SIP messages are exchanged over a TLS-oriented transport, Wireshark 256 will be unable to decrypt them and render them as individual SIP 257 headers. 259 6. Motivation and use cases 261 As SIP becomes pervasive in multiple business domains and ubiquitous 262 in academic and research environments, it is beneficial to establish 263 a CLF for the following reasons: 265 Common reference for interpreting events: In a laboratory 266 environment or an enterprise service offering there will typically 267 be SIP entities from multiple vendors participating in routing 268 requests. Absent a CLF format, each entity will produce output 269 records in a native format making it hard to establish commonality 270 for tools that operate on the log file. 272 Writing common tools: A CLF format allows independent tool providers 273 to craft tools and applications that interpret the CLF data to 274 produce insightful trend analysis and detailed traffic reports. 275 The format should be such that it retains the ability to be read 276 by humans and processed using traditional Unix text processing 277 tools. 279 Session correlation across diverse processing elements: In 280 operational SIP networks, a request will typically be processed by 281 more than one SIP server. A SIP CLF will allow the network 282 operator to trace the progression of the request (or a set of 283 requests) as they traverse through the different servers to 284 establish a concise diagnostic trail of a SIP session. 286 Note that tracing the request through a set of servers is 287 considerably less challenging if all the servers belong to the 288 same administrative domain. 290 Message correlation across transactions: A SIP CLF can enable a 291 quick lookup of all messages that comprise a transaction (e.g., 292 "Find all messages corresponding to server transaction X, 293 including all forked branches.") 295 Message correlation across dialogs: A SIP CLF can correlate 296 transactions that comprise a dialog (e.g., "Find all messages for 297 dialog created by Call-ID C, From tag F and To tag T.") 299 Trend analysis: A SIP CLF allows an administrator to collect data 300 and spot patterns or trends in the information (e.g., "What is the 301 domain where the most sessions are routed to between 9:00 AM and 302 12:00 PM?") 304 Train anomaly detection systems: A SIP CLF will allow for the 305 training of anomaly detection systems that once trained can 306 monitor the CLF file to trigger an alarm on the subsequent 307 deviations from accepted patterns in the data set. Currently, 308 anomaly detection systems monitor the network and parse raw 309 packets that comprise a SIP message -- a process that is 310 unsuitable for anomaly detection systems [rieck2008]. With all 311 the necessary event data at their disposal, network operations 312 managers and information technology operation managers are in a 313 much better position to correlate, aggregate, and prioritize log 314 data to maintain situational awareness. 316 Testing: A SIP CLF allows for automatic testing of SIP equipment by 317 writing tools that can parse a SIP CLF file to ensure behavior of 318 a device under test. 320 Troubleshooting: A SIP CLF can enable cursory trouble shooting of a 321 SIP entity (e.g., "How long did it take to generate a final 322 response for the INVITE associated with Call-ID X?") 324 Offline analysis: A SIP CLF allows for offline analysis of the data 325 gathered. Once a SIP CLF file has been generated, it can be 326 transported (subject to the security considerations in Section 10) 327 to a host with appropriate computing resources to perform 328 subsequent analysis. 330 Real-time monitoring: A SIP CLF allows administrators to visually 331 notice the events occurring at a SIP entity in real-time providing 332 accurate situational awareness. 334 7. Challenges in establishing a SIP CLF 336 Establishing a CLF for SIP is a challenging task. The behavior of a 337 SIP entity is more complex when compared to the equivalent HTTP 338 entity. 340 Base protocol services such as parallel or serial forking elicit 341 multiple final responses. Ensuing delays between sending a request 342 and receiving a final response all add complexity when considering 343 what fields should comprise a CLF and in what manner. Furthermore, 344 unlike HTTP, SIP groups multiple discrete transactions into a dialog, 345 and these transactions may arrive at a varying inter-arrival rate at 346 a proxy. For example, the BYE transaction usually arrives much after 347 the corresponding INVITE transaction was received, serviced and 348 expunged from the transaction list. Nonetheless, it is advantageous 349 to relate these transactions such that automata or a human monitoring 350 the log file can construct a set consisting of related transactions. 352 ACK requests in SIP need careful consideration as well. In SIP, an 353 ACK is a special method that is associated with an INVITE only. It 354 does not require a response, and furthermore, if it is acknowledging 355 a non-2xx response, then the ACK is considered part of the original 356 INVITE transaction. If it is acknowledging a 2xx-class response, 357 then the ACK is a separate transaction consisting of a request only 358 (i.e., there is not a response for an ACK request.) CANCEL is 359 another method that is tied to an INVITE transaction, but unlike ACK, 360 the CANCEL request elicits a final response. 362 While most requests elicit a response immediately, the INVITE request 363 in SIP can pend at a proxy as it forks branches downstream or at a 364 user agent server while it alerts the user. RFC 3261 [RFC3261] 365 instructs the server transaction to send a 1xx-class provisional 366 response if a final response is delayed for more than 200 ms. A SIP 367 CLF log file needs to include such provisional responses because they 368 help train automata associated with anomaly detection systems and 369 provide some positive feedback for a human observer monitoring the 370 log file. 372 Finally, beyond supporting native SIP actors such as proxies, 373 registrars, redirect servers, and user agent servers (UAS), it is 374 beneficial to derive a CLF format that supports back-to-back user 375 agent (B2BUA) behavior, which may vary considerably depending on the 376 specific nature of the B2BUA. 378 8. Data model 380 The minimal SIP CLF fields are defined below. Some of these fields 381 contain URIs. If the URI contains an escaped character (""%" HEX 382 HEX" mechanism), the escaped character MUST be logged as received. 383 The maximum size (in number of bytes) for a SIP CLF field is 4096 384 bytes. This limit is the same regardless of whether the SIP CLF 385 field is a meta-field (see "Timestamp" and "Directionality" defined 386 below) or a normal SIP header. If the body of the SIP message is to 387 be logged, it MUST conform to this limit as well. 389 Logging bodies of a SIP message is left optional (and is not shown in 390 the examples of Section 9). If the body is to be logged, the 391 specific syntax and semantics used to log bodies MUST be defined by 392 the specific representation format used to generate the SIP CLF 393 record. 395 The data model supports extensibility by providing the capability to 396 log "optional fields". Optional fields are those SIP header fields 397 (or field components) that are not mandatory (see Section 8.1 for the 398 mandatory field list). Optional fields may contain SIP headers or 399 other elements present in a SIP message (for example, the Reason- 400 Phrase element from the Status-Line production rule in RFC 3261 401 [RFC3261]). Optional fields may also contain additional information 402 that a particular vendor desires to log. The specific syntax and 403 semantics to be accorded to optional fields MUST be defined by the 404 specific representation format used to generate the SIP CLF record. 406 Finally, [I-D.ietf-sipclf-format] is an example of a representation 407 format draft that provides an ASCII-based encoding scheme. 409 8.1. SIP CLF mandatory fields 411 The following SIP CLF fields are defined as minimal information that 412 MUST appear in any SIP CLF record: 414 Timestamp - Date and time of the request or response represented as 415 the number of seconds and milliseconds since the Unix epoch. 417 Message type - An indicator on whether the SIP message is a request 418 or a response. The allowable values for this field are 'R' (for 419 Request) and 'r' (for response). 421 Directionality - An indicator on whether the SIP message is received 422 by the SIP entity or sent by the SIP entity. The allowable values 423 for this field are 's' (for message sent) and 'r' (for message 424 received). 426 Transport - The transport over which a SIP message is sent or 427 received. The allowable values for the transport are governed by 428 the "transport" production rule in Section 25.1 of RFC3261 429 [RFC3261]. 431 Source-address - The IP address of the sender of the SIP message. 433 Source-port - The source port number of the sender of the SIP 434 message. 436 Destination-address - The IP address of the recipient of the SIP 437 message. 439 Destination-port - The port number of the recipient of the SIP 440 message. 442 From - The From URI. Whilst one may question the value of the From 443 URI in light of RFC4744 [RFC4474], the From URI, nonetheless, 444 imparts some information. As an example, in the case of a 445 REGISTER request, the From URI can provide information on whether 446 this was a third-party registration or a first-party one. For the 447 sake of brevity, URI parameters SHOULD NOT be logged. 449 From-tag - The tag parameter of the From header. 451 To - The To URI. For the sake of brevity, URI parameters SHOULD NOT 452 be logged. 454 To-tag - The tag parameter of the To header. Note that the tag 455 parameter will be absent in the initial request that forms a 456 dialog. 458 Callid - The Call-ID. 460 CSeq-Method - The method from the CSeq header. 462 CSeq-Number - The number from the CSeq header. 464 R-URI - The Request-URI, including any URI parameters. 466 Status - The SIP response status code. 468 SIP Proxies may fork, creating several client transactions that 469 correlate to a single server transaction. Responses arriving on 470 these client transactions, or new requests (CANCEL, ACK) sent on the 471 client transaction need log file entries that correlate with a server 472 transaction. Similarly, a B2BUA may create one or more client 473 transactions in response to an incoming request. These transactions 474 will require correlation as well. The last two data model elements 475 provide this correlation. 477 Server-Txn - Server transaction identification code - the 478 transaction identifier associated with the server transaction. 479 Implementations can reuse the server transaction identifier (the 480 topmost branch-id of the incoming request, with or without the 481 magic cookie), or they could generate a unique identification 482 string for a server transaction (this identifier needs to be 483 locally unique to the server only.) This identifier is used to 484 correlate ACKs and CANCELs to an INVITE transaction; it is also 485 used to aid in forking as explained later in this section. (See 486 Section 9 for usage.) 488 Client-Txn - Client transaction identification code - this field is 489 used to associate client transactions with a server transaction 490 for forking proxies or B2BUAs. Upon forking, implementations can 491 reuse the value they inserted into the topmost Via header's branch 492 parameter, or they can generate a unique identification string for 493 the client transaction. (See Section 9 for usage.) 495 This data model applies to all SIP entities --- a UAC, UAS, Proxy, a 496 B2BUA, registrar and redirect server. Note that a B2BUA is a 497 degenerate case of a proxy and as such the SIP CLF fields prescribed 498 for a proxy is equally applicable to the B2BUA. Similarly, 499 registrars and redirect servers are a degenerate case of a UAS, and 500 as such the SIP CLF fields prescribed for a UAS is equally applicable 501 to registrars and redirect servers. 503 The next section specifies the individual SIP CLF data model elements 504 that form a log record for specific instance of a SIP entity. We 505 limit our specification to using the minimum data model elements. It 506 is understood that a SIP CLF record is extensible using extension 507 mechanisms appropriate to the specific representation used to 508 generate the SIP CLF record. This document, however, does not 509 prescribe a specific representation format and it limits the 510 discussion to the mandatory data elements described above. 512 8.2. Mandatory fields and SIP entities 514 Each SIP CLF record MUST consist of all the mandatory data model 515 elements outlined in Section 8.1. This document does not specify a 516 representation of a logging format; it is expected that other 517 documents will do so. Each SIP CLF record MUST contain the mandatory 518 elements shown below: 520 Timestamp, Message type, Directionality, CSeq-Method, 521 CSeq-Number, Transport, R-URI, Destination-address, 522 Destination-port, Source-address, Source-port, To, 523 To-tag, From, From-tag, Call-ID, Status, Server-Txn, 524 Client-Txn 526 Table 1 summarizes how the mandatory fields are logged by a UAC, UAS, 527 or UAC-half, UAS-half of a SIP proxy and B2BUA. In the table below: 529 R: implies that the field is logged when a request is handled by that 530 SIP entity. 532 r: implies that the field is logged when a response is handled by 533 that SIP entity. 535 -: implies that the field is not applicable to that SIP entity. 537 +---------------------+-----+-----+----------+----------+ 538 | | UAC | UAS | UAS-half | UAC-half | 539 +---------------------+-----+-----+----------+----------+ 540 | Timestamp | R,r | R,r | R,r | R,r | 541 | Message type | R,r | R,r | R,r | R,r | 542 | Directionality | R,r | R,r | R,r | R,r | 543 | Transport | R,r | R,r | R,r | R,r | 544 | CSeq-Method | R,r | R,r | R,r | R,r | 545 | CSeq-Number | R,r | R,r | R,r | R,r | 546 | R-URI | R | R | R | R | 547 | Destination-address | R,r | R,r | R,r | R,r | 548 | Destination-port | R,r | R,r | R,r | R,r | 549 | Source-address | R,r | R,r | R,r | R,r | 550 | Source-port | R,r | R,r | R,r | R,r | 551 | To | R,r | R,r | R,r | R,r | 552 | To-tag | R,r | R,r | R,r | R,r | 553 | From | R,r | R,r | R,r | R,r | 554 | From-tag | R,r | R,r | R,r | R,r | 555 | Call-ID | R,r | R,r | R,r | R,r | 556 | Status | r | r | r | r | 557 | Server-Txn | - | R,r | R,r | R,r | 558 | Client-Txn | R,r | - | r | R,r | 559 +---------------------+-----+-----+----------+----------+ 561 SIP CLF fields logged per entity 563 Table 1 565 9. Examples 567 The examples use only the mandatory data elements defined in 568 Section 8.1. Extension elements are not considered. The examples 569 below use the template defined in Section 8.2 when logging a SIP CLF 570 record. When a given mandatory field is not applicable to a SIP 571 entity as determined by Table 1, we use the horizontal dash ("-") to 572 represent it. 574 There are five principals in the examples below. They are Alice, the 575 initiator of requests. Alice's user agent uses IPv4 address 576 198.51.100.1, port 5060. P1 is a proxy that Alice's request traverse 577 on their way to Bob, the recipient of the requests. P1 also acts as 578 a registrar to Alice. P1 uses an IPv4 address of 198.51.100.10, port 579 5060. Bob has two instances of his user agent running on different 580 hosts. The first instance uses an IPv4 address of 203.0.113.1, port 581 5060 and the second instance uses an IPv6 address of 2001:db8::9, 582 port 5060. P2 is a proxy responsible for Bob's domain. Table 2 583 summarizes these addresses. 585 +-------------------+--------------------+-------------------+ 586 | Principal | IP:port | Host/Domain name | 587 +-------------------+--------------------+-------------------+ 588 | Alice | 198.51.100.1:5060 | alice.example.com | 589 | P1 | 198.51.100.10:5060 | p1.example.com | 590 | P2 | 203.0.113.200:5060 | p2.example.net | 591 | Bob UA instance 1 | 203.0.113.1:5060 | bob1.example.net | 592 | Bob UA instance 2 | [2001:db8::9]:5060 | bob2.example.net | 593 +-------------------+--------------------+-------------------+ 595 Principal to IP address asignment 597 Table 2 599 Illustrative examples of SIP CLF follow. 601 9.1. UAC registration 603 Alice sends a registration registrar P1 and receives a 2xx-class 604 response. The register requests causes Alice's UAC to produce a log 605 record shown below. The mandatory data model elements correspond to 606 those listed in Table 1. 608 Timestamp: 1275930743.699 609 Message Type: R 610 Directionality: s 611 Transport: udp 612 CSeq-Number: 1 613 CSeq-Method: REGISTER 614 R-URI: sip:example.com 615 Destination-address: 198.51.100.10 616 Destination-port: 5060 617 Source-address: 198.51.100.1 618 Source-port: 5060 619 To: sip:example.com 620 To-tag: - 621 From: sip:alice@example.com 622 From-tag: 76yhh 623 Call-ID: f81-d4-f6@example.com 624 Status: - 625 Server-Txn: - 626 Client-Txn: c-tr-1 628 After some time, Alice's UAC will receive a response from the 629 registrar. The response causes Alice's agent to produce a log record 630 shown below. The mandatory data elements correspond to those listed 631 in Table 1. 633 Timestamp: 1275930744.100 634 Message Type: r 635 Directionality: r 636 Transport: udp 637 CSeq-Number: 1 638 CSeq-Method: REGISTER 639 R-URI: - 640 Destination-address: 198.51.100.1 641 Destination-port: 5060 642 Source-address: 198.51.100.10 643 Source-port: 5060 644 To: sip:example.com 645 To-tag: reg-1-xtr 646 From: sip:alice@example.com 647 From-tag: 76yhh 648 Call-ID: f81-d4-f6@example.com 649 Status: 100 650 Server-Txn: - 651 Client-Txn: c-tr-1 653 9.2. Direct call between Alice and Bob 655 In this example, Alice sends a session initiation request directly to 656 Bob's agent (instance 1.) Bob's agent accepts the session 657 invitation. We first present the SIP CLF logging from Alice's UAC 658 point of view. In line 1, Alice's user agent sends out the INVITE. 659 Shortly, it receives a "180 Ringing" (line 2), followed by a "200 OK" 660 response (line 3). Upon the receipt of the 2xx-class response, 661 Alice's user agent sends out an ACK request (line 4). 663 Timestamp: 1275930743.699 664 Message Type: R 665 Directionality: s 666 Transport: udp 667 CSeq-Number: 32 668 CSeq-Method: INVITE 669 R-URI: sip:bob@bob1.example.net 670 Destination-address: 203.0.113.1 671 Destination-port: 5060 672 Source-address: 198.51.100.1 673 Source-port: 5060 674 To: sip:bob@bob1.example.net 675 To-tag: - 676 From: sip:alice@example.com 677 From-tag: 76yhh 678 Call-ID: f82-d4-f7@example.com 679 Status: - 680 Server-Txn: - 681 Client-Txn: c-1-xt6 683 Timestamp: 1275930745.002 684 Message Type: r 685 Directionality: r 686 Transport: udp 687 CSeq-Number: 32 688 CSeq-Method: INVITE 689 R-URI: - 690 Destination-address: 198.51.1.100 691 Destination-port: 5060 692 Source-address: 203.0.113.1 693 Source-port: 5060 694 To: sip:bob@example.net 695 To-tag: b-in6-iu 696 From: sip:alice@example.com 697 From-tag: 76yhh 698 Call-ID: f82-d4-f7@example.com 699 Status: 180 700 Server-Txn: - 701 Client-Txn: c-1-xt6 703 Timestamp: 1275930746.100 704 Message Type: r 705 Directionality: r 706 Transport: udp 707 CSeq-Number: 32 708 CSeq-Method: INVITE 709 R-URI: - 710 Destination-address: 198.51.1.100 711 Destination-port: 5060 712 Source-address: 203.0.113.1 713 Source-port: 5060 714 To: sip:bob@example.net 715 To-tag: b-in6-iu 716 From: sip:alice@example.com 717 From-tag: 76yhh 718 Call-ID: f82-d4-f7@example.com 719 Status: 200 720 Server-Txn: - 721 Client-Txn: c-1-xt6 723 Timestamp: 1275930746.120 724 Message Type: R 725 Directionality: s 726 Transport: udp 727 CSeq-Number: 32 728 CSeq-Method: ACK 729 R-URI: sip:bob@bob1.example.net 730 Destination-address: 203.0.113.1 731 Destination-port: 5060 732 Source-address: 198.51.100.1 733 Source-port: 5060 734 To: sip:bob@example.net 735 To-tag: b-in6-iu 736 From: sip:alice@example.com 737 From-tag: 76yhh 738 Call-ID: f82-d4-f7@example.com 739 Status: - 740 Server-Txn: - 741 Client-Txn: c-1-xt6 743 9.3. Single downstream branch call 745 In this example, Alice sends a session invitation request to Bob 746 through proxy P1, which inserts a Record-Route header causing 747 subsequent requests between Alice and Bob to traverse the proxy. The 748 SIP CLF log records correspond to the viewpoint of P1. The line 749 numbers below refer to Figure 1 751 Alice P1 Bob 752 +---INV--------->| | Line 1 753 | | | 754 |<---------100---+ | Line 2 755 | | | 756 | +---INV-------->| Line 3 757 | | | 758 | |<--------100---+ Line 4 759 | | | 760 | |<--------180---+ Line 5 761 | | | 762 |<---------180---+ | Line 6 763 | | | 764 | |<--------200---+ Line 7 765 | | | 766 |<---------200---+ | Line 8 767 | | | 768 +---ACK--------->| | Line 9 769 | | | 770 | |---ACK-------->| Line 10 772 Figure 1: Simple proxy-aided call flow 774 1 Timestamp: 1275930743.699 775 Message Type: R 776 Directionality: r 777 Transport: udp 778 CSeq-Number: 43 779 CSeq-Method: INVITE 780 R-URI: sip:bob@example.net 781 Destination-address: 198.51.100.10 782 Destination-port: 5060 783 Source-address: 198.51.100.1 784 Source-port: 5060 785 To: sip:bob@example.net 786 To-tag: - 787 From: sip:alice@example.com 788 From-tag: al-1 789 Call-ID: tr-87h@example.com 790 Status: - 791 Server-Txn: s-x-tr 792 Client-Txn: - 794 Note that at this point P1 has created a server transaction 795 identification code and populated the SIP CLF field Server-Txn with 796 it. P1 has not yet created a client transaction identification code, 797 thus Client-Txn contains a "-". 799 2 Timestamp: 1275930744.001 800 Message Type: r 801 Directionality: s 802 Transport: udp 803 CSeq-Number: 43 804 CSeq-Method: INVITE 805 R-URI: - 806 Destination-address: 198.51.100.1 807 Destination-port: 5060 808 Source-address: 198.51.100.10 809 Source-port: 5060 810 To: sip:bob@example.net 811 To-tag: - 812 From: sip:alice@example.com 813 From-tag: al-1 814 Call-ID: tr-87h@example.com 815 Status: 100 816 Server-Txn: s-x-tr 817 Client-Txn: - 819 In line 3 below, P1 has created a client transaction identification 820 code for the downstream branch and populated the SIP CLF field 821 Client-Txn. 823 3 Timestamp: 1275930744.998 824 Message Type: R 825 Directionality: s 826 Transport: udp 827 CSeq-Number: 43 828 CSeq-Method: INVITE 829 R-URI: sip:bob@bob1.example.net 830 Destination-address: 203.0.113.1 831 Destination-port: 5060 832 Source-address: 198.51.100.10 833 Source-port: 5060 834 To: sip:bob@example.net 835 To-tag: - 836 From: sip:alice@example.com 837 From-tag: al-1 838 Call-ID: tr-87h@example.com 839 Status: - 840 Server-Txn: s-x-tr 841 Client-Txn: c-x-tr 843 4 Timestamp: 1275930745.200 844 Message Type: r 845 Directionality: r 846 Transport: udp 847 CSeq-Number: 43 848 CSeq-Method: INVITE 849 R-URI: - 850 Destination-address: 198.51.100.10 851 Destination-port: 5060 852 Source-address: 203.0.113.1 853 Source-port: 5060 854 To: sip:bob@example.net 855 To-tag: b1-1 856 From: sip:alice@example.com 857 From-tag: al-1 858 Call-ID: tr-87h@example.com 859 Status: 100 860 Server-Txn: s-x-tr 861 Client-Txn: c-x-tr 863 5 Timestamp: 1275930745.800 864 Message Type: r 865 Directionality: r 866 Transport: udp 867 CSeq-Number: 43 868 CSeq-Method: INVITE 869 R-URI: - 870 Destination-address: 198.51.100.10 871 Destination-port: 5060 872 Source-address: 203.0.113.1 873 Source-port: 5060 874 To: sip:bob@example.net 875 To-tag: b1-1 876 From: sip:alice@example.com 877 From-tag: al-1 878 Call-ID: tr-87h@example.com 879 Status: 180 880 Server-Txn: s-x-tr 881 Client-Txn: c-x-tr 883 6 Timestamp: 1275930746.009 884 Message Type: r 885 Directionality: s 886 Transport: udp 887 CSeq-Number: 43 888 CSeq-Method: INVITE 889 R-URI: - 890 Destination-address: 198.51.100.1 891 Destination-port: 5060 892 Source-address: 198.51.100.10 893 Source-port: 5060 894 To: sip:bob@example.net 895 To-tag: b1-1 896 From: sip:alice@example.com 897 From-tag: al-1 898 Call-ID: tr-87h@example.com 899 Status: 180 900 Server-Txn: s-x-tr 901 Client-Txn: c-x-tr 903 7 Timestamp: 1275930747.120 904 Message Type: r 905 Directionality: r 906 Transport: udp 907 CSeq-Number: 43 908 CSeq-Method: INVITE 909 R-URI: - 910 Destination-address: 198.51.100.10 911 Destination-port: 5060 912 Source-address: 203.0.113.1 913 Source-port: 5060 914 To: sip:bob@example.net 915 To-tag: b1-1 916 From: sip:alice@example.com 917 From-tag: al-1 918 Call-ID: tr-87h@example.com 919 Status: 200 920 Server-Txn: s-x-tr 921 Client-Txn: c-x-tr 923 8 Timestamp: 1275930747.300 924 Message Type: r 925 Directionality: s 926 Transport: udp 927 CSeq-Number: 43 928 CSeq-Method: INVITE 929 R-URI: - 930 Destination-address: 198.51.100.1 931 Destination-port: 5060 932 Source-address: 198.51.100.10 933 Source-port: 5060 934 To: sip:bob@example.net 935 To-tag: b1-1 936 From: sip:alice@example.com 937 From-tag: al-1 938 Call-ID: tr-87h@example.com 939 Status: 200 940 Server-Txn: s-x-tr 941 Client-Txn: c-x-tr 943 9 Timestamp: 1275930749.100 944 Message Type: R 945 Directionality: r 946 Transport: udp 947 CSeq-Number: 43 948 CSeq-Method: ACK 949 R-URI: sip:bob@example.net 950 Destination-address: 198.51.100.10 951 Destination-port: 5060 952 Source-address: 198.51.100.1 953 Source-port: 5060 954 To: sip:bob@example.net 955 To-tag: b1-1 956 From: sip:alice@example.com 957 From-tag: al-1 958 Call-ID: tr-87h@example.com 959 Status: - 960 Server-Txn: s-x-tr 961 Client-Txn: c-x-tr 963 10 Timestamp: 1275930749.100 964 Message Type: R 965 Directionality: s 966 Transport: udp 967 CSeq-Number: 43 968 CSeq-Method: ACK 969 R-URI: sip:bob@bob1.example.net 970 Destination-address: 203.0.113.1 971 Destination-port: 5060 972 Source-address: 198.51.100.10 973 Source-port: 5060 974 To: sip:bob@example.net 975 To-tag: b1-1 976 From: sip:alice@example.com 977 From-tag: al-1 978 Call-ID: tr-87h@example.com 979 Status: - 980 Server-Txn: s-x-tr 981 Client-Txn: c-x-tr 983 9.4. Forked call 985 In this example, Alice sends a session invitation to Bob's proxy, P2. 986 P2 forks the session invitation request to two registered endpoints 987 corresponding to Bob's address-of-record. Both endpoints respond 988 with provisional responses. Shortly thereafter, one of Bob's user 989 agent instances accepts the call, causing P2 to send a CANCEL request 990 to the second user agent. P2 does not Record-Route, therefore the 991 subsequent ACK request from Alice to Bob's user agent does not 992 traverse through P2 (and is not shown below.) 994 Figure 2 depicts the call flow. 996 Bob Bob 997 Alice P2 (Instance 1) (Instance 2) 998 +---INV--->| | | Line 1 999 | | | | 1000 |<---100---+ | | Line 2 1001 | | | | 1002 | +---INV--->| | Line 3 1003 | | | | 1004 | +---INV----+-------->| Line 4 1005 | | | | 1006 | |<---100---+ | Line 5 1007 | | | | 1008 | |<---------+---100---+ Line 6 1009 | | | | 1010 | |<---180---+---------+ Line 7 1011 | | | | 1012 |<---180---+ | | Line 8 1013 | | | | 1014 | |<---180---+ | Line 9 1015 | | | | 1016 |<---180---+ | | Line 10 1017 | | | | 1018 | |<---200---+ | Line 11 1019 | | | | 1020 |<---200---+ | | Line 12 1021 | | | | 1022 | +---CANCEL-+-------->| Line 13 1023 | | | | 1024 | |<---------+---487---+ Line 14 1025 | | | | 1026 | +---ACK----+-------->| Line 15 1027 | | | | 1028 | |<---------+---200---+ Line 16 1030 Figure 2: Forked call flow 1032 The SIP CLF log correspond to the viewpoint of P2. The fields logged 1033 are shown below; the line numbers refer to Figure 2. 1035 1 Timestamp: 1275930743.699 1036 Message Type: R 1037 Directionality: r 1038 Transport: udp 1039 CSeq-Number: 43 1040 CSeq-Method: INVITE 1041 R-URI: sip:bob@example.net 1042 Destination-address: 203.0.113.200 1043 Destination-port: 5060 1044 Source-address: 198.51.100.1 1045 Source-port: 5060 1046 To: sip:bob@example.net 1047 To-tag: - 1048 From: sip:alice@example.com 1049 From-tag: a1-1 1050 Call-ID: tr-88h@example.com 1051 Status: - 1052 Server-Txn: s-1-tr 1053 Client-Txn: - 1055 2 Timestamp: 1275930744.001 1056 Message Type: r 1057 Directionality: s 1058 Transport: udp 1059 CSeq-Number: 43 1060 CSeq-Method: INVITE 1061 R-URI: - 1062 Destination-address: 198.51.100.1 1063 Destination-port: 5060 1064 Source-address: 203.0.113.200 1065 Source-port: 5060 1066 To: sip:bob@example.net 1067 To-tag: - 1068 From: sip:alice@example.com 1069 From-tag: a1-1 1070 Call-ID: tr-88h@example.com 1071 Status: 100 1072 Server-Txn: s-1-tr 1073 Client-Txn: - 1075 3 Timestamp: 1275930744.998 1076 Message Type: R 1077 Directionality: s 1078 Transport: udp 1079 CSeq-Number: 43 1080 CSeq-Method: INVITE 1081 R-URI: sip:bob@bob1.example.net 1082 Destination-address: 203.0.113.1 1083 Destination-port: 5060 1084 Source-address: 203.0.113.200 1085 Source-port: 5060 1086 To: sip:bob@example.net 1087 To-tag: - 1088 From: sip:alice@example.com 1089 From-tag: a1-1 1090 Call-ID: tr-88h@example.com 1091 Status: - 1092 Server-Txn: s-1-tr 1093 Client-Txn: c-1-tr 1095 4 Timestamp: 1275930745.500 1096 Message Type: R 1097 Directionality: s 1098 Transport: udp 1099 CSeq-Number: 43 1100 CSeq-Method: INVITE 1101 R-URI: sip:bob@bob2.example.net 1102 Destination-address: [2001:db8::9] 1103 Destination-port: 5060 1104 Source-address: 203.0.113.200 1105 Source-port: 5060 1106 To: sip:bob@example.net 1107 To-tag: - 1108 From: sip:alice@example.com 1109 From-tag: a1-1 1110 Call-ID: tr-88h@example.com 1111 Status: - 1112 Server-Txn: s-1-tr 1113 Client-Txn: c-2-tr 1115 5 Timestamp: 1275930745.800 1116 Message Type: r 1117 Directionality: r 1118 Transport: udp 1119 CSeq-Number: 43 1120 CSeq-Method: INVITE 1121 R-URI: - 1122 Destination-address: 203.0.113.200 1123 Destination-port: 5060 1124 Source-address: 203.0.113.1 1125 Source-port: 5060 1126 To: sip:bob@example.net 1127 To-tag: b1=-1 1128 From: sip:alice@example.com 1129 From-tag: a1-1 1130 Call-ID: tr-88h@example.com 100 1131 Status: 100 1132 Server-Txn: s-1-tr 1133 Client-Txn: c-1-tr 1135 6 Timestamp: 1275930746.100 1136 Message Type: r 1137 Directionality: r 1138 Transport: udp 1139 CSeq-Number: 43 1140 CSeq-Method: INVITE 1141 R-URI: - 1142 Destination-address: 203.0.113.200 1143 Destination-port: udp 1144 Source-address: [2001:db8::9] 1145 Source-port: 5060 1146 To: sip:bob@example.net 1147 To-tag: b2-2 1148 From: sip:alice@example.com 1149 From-tag: a1-1 1150 Call-ID: tr-88h@example.com 1151 Status: 100 1152 Server-Txn: s-1-tr 1153 Client-Txn: c-2-tr 1155 7 Timestamp: 1275930746.700 1156 Message Type: r 1157 Directionality: r 1158 Transport: udp 1159 CSeq-Number: 43 1160 CSeq-Method: INVITE 1161 R-URI: - 1162 Destination-address: 203.0.113.200 1163 Destination-port: udp 1164 Source-address: [2001:db8::9] 1165 Source-port: 5060 1166 To: sip:bob@example.net 1167 To-tag: b2-2 1168 From: sip:alice@example.com 1169 From-tag: a1-1 1170 Call-ID: tr-88h@example.com 1171 Status: 180 1172 Server-Txn: s-1-tr 1173 Client-Txn: c-2-tr 1175 8 Timestamp: 1275930746.990 1176 Message Type: r 1177 Directionality: s 1178 Transport: udp 1179 CSeq-Number: 43 1180 CSeq-Method: INVITE 1181 R-URI: - 1182 Destination-address: 198.51.100.1 1183 Destination-port: 5060 1184 Source-address: 203.0.113.200 1185 Source-port: 5060 1186 To: sip:bob@example.net 1187 To-tag: b2-2 1188 From: sip:alice@example.com 1189 From-tag: a1-1 1190 Call-ID: tr-88h@example.com 1191 Status: 180 1192 Server-Txn: s-1-tr 1193 Client-Txn: c-2-tr 1195 9 Timestamp: 1275930747.100 1196 Message Type: r 1197 Directionality: r 1198 Transport: udp 1199 CSeq-Number: 43 1200 CSeq-Method: INVITE 1201 R-URI: - 1202 Destination-address: 203.0.113.200 1203 Destination-port: 5060 1204 Source-address: 203.0.113.1 1205 Source-port: 5060 1206 To: sip:bob@example.net 1207 To-tag: b1-1 1208 From: sip:alice@example.com 1209 From-tag: a1-1 1210 Call-ID: tr-88h@example.com 100 1211 Status: 180 1212 Server-Txn: s-1-tr 1213 Client-Txn: c-1-tr 1215 10 Timestamp: 1275930747.300 1216 Message Type: r 1217 Directionality: s 1218 Transport: udp 1219 CSeq-Number: 43 1220 CSeq-Method: INVITE 1221 R-URI: - 1222 Destination-address: 198.51.100.1 1223 Destination-port: 5060 1224 Source-address: 203.0.113.200 1225 Source-port: 5060 1226 To: sip:bob@example.net 1227 To-tag: b1-1 1228 From: sip:alice@example.com 1229 From-tag: a1-1 1230 Call-ID: tr-88h@example.com 1231 Status: 180 1232 Server-Txn: s-1-tr 1233 Client-Txn: c-2-tr 1235 11 Timestamp: 1275930747.800 1236 Message Type: r 1237 Directionality: r 1238 Transport: udp 1239 CSeq-Number: 43 1240 CSeq-Method: INVITE 1241 R-URI: - 1242 Destination-address: 203.0.113.200 1243 Destination-port: 5060 1244 Source-address: 203.0.113.1 1245 Source-port: 5060 1246 To: sip:bob@example.net 1247 To-tag: b1-1 1248 From: sip:alice@example.com 1249 From-tag: a1-1 1250 Call-ID: tr-88h@example.com 100 1251 Status: 200 1252 Server-Txn: s-1-tr 1253 Client-Txn: c-1-tr 1255 12 Timestamp: 1275930748.000 1256 Message Type: r 1257 Directionality: s 1258 Transport: udp 1259 CSeq-Number: 43 1260 CSeq-Method: INVITE 1261 R-URI: - 1262 Destination-address: 198.51.100.1 1263 Destination-port: 5060 1264 Source-address: 203.0.113.200 1265 Source-port: 5060 1266 To: sip:bob@example.net 1267 To-tag: b1-1 1268 From: sip:alice@example.com 1269 From-tag: a1-1 1270 Call-ID: tr-88h@example.com 1271 Status: 200 1272 Server-Txn: s-1-tr 1273 Client-Txn: c-1-tr 1275 13 Timestamp: 1275930748.201 1276 Message Type: R 1277 Directionality: s 1278 Transport: udp 1279 CSeq-Number: 43 1280 CSeq-Method: CANCEL 1281 R-URI: sip:bob@bob2.example.net 1282 Destination-address: [2001:db8::9] 1283 Destination-port: 5060 1284 Source-address: 203.0.113.200 1285 Source-port: 5060 1286 To: sip:bob@example.net 1287 To-tag: b2-2 1288 From: sip:alice@example.com 1289 From-tag: a1-1 1290 Call-ID: tr-88h@example.com 1291 Status: - 1292 Server-Txn: s-1-tr 1293 Client-Txn: c-2-tr 1295 14 Timestamp: 1275930748.991 1296 Message Type: r 1297 Directionality: r 1298 Transport: udp 1299 CSeq-Number: 43 1300 CSeq-Method: INVITE 1301 R-URI: - 1302 Destination-address: 203.0.113.200 1303 Destination-port: udp 1304 Source-address: [2001:db8::9] 1305 Source-port: 5060 1306 To: sip:bob@example.net 1307 To-tag: b2-2 1308 From: sip:alice@example.com 1309 From-tag: a1-1 1310 Call-ID: tr-88h@example.com 1311 Status: 487 1312 Server-Txn: s-1-tr 1313 Client-Txn: c-2-tr 1315 15 Timestamp: 1275930749.455 1316 Message Type: R 1317 Directionality: s 1318 Transport: udp 1319 CSeq-Number: 43 1320 CSeq-Method: ACK 1321 R-URI: sip:bob@bob2.example.net 1322 Destination-address: [2001:db8::9] 1323 Destination-port: 5060 1324 Source-address: 203.0.113.200 1325 Source-port: 5060 1326 To: sip:bob@example.net 1327 To-tag: b2-2 1328 From: sip:alice@example.com 1329 From-tag: a1-1 1330 Call-ID: tr-88h@example.com 1331 Status: - 1332 Server-Txn: s-1-tr 1333 Client-Txn: c-2-tr 1335 16 Timestamp: 1275930750.001 1336 Message Type: r 1337 Directionality: r 1338 Transport: udp 1339 CSeq-Number: 43 1340 CSeq-Method: CANCEL 1341 R-URI: - 1342 Destination-address: 203.0.113.200 1343 Destination-port: udp 1344 Source-address: [2001:db8::9] 1345 Source-port: 5060 1346 To: sip:bob@example.net 1347 To-tag: b2-2 1348 From: sip:alice@example.com 1349 From-tag: a1-1 1350 Call-ID: tr-88h@example.com 1351 Status: 200 1352 Server-Txn: s-1-tr 1353 Client-Txn: c-2-tr 1355 The above SIP CLF log makes it easy to search for a specific 1356 transaction or a state of the session. Searching for the string 1357 "c-1-tr" on the log records will readily yield the information that 1358 an INVITE was sent to sip:bob@bob1.example.com, it elicited a 100 1359 followed by a 180 and then a 200. The absence of the ACK request 1360 signifies that the ACK was exchanged end-to-end. 1362 Searching on "c-2-tr" yields a more complex scenario of sending an 1363 INVITE to sip:bob@bob2.example.net, receiving 100 and 180. However, 1364 the log makes it apparent that the request to 1365 sip:bob@bob2.example.net was subsequently CANCEL'ed before a final 1366 response was generated, and that the pending INVITE returned a 487. 1367 The ACK to the final non-2xx response and a 200 to the CANCEL request 1368 complete the exchange on that branch. 1370 10. Security Considerations 1372 A log file by its nature reveals both the state of the entity 1373 producing it and the nature of the information being logged. To the 1374 extent that this state should not be publicly accessible and that the 1375 information is to be considered private, appropriate file and 1376 directory permissions attached to the log file should be used. The 1377 following threats may be considered for the log file while it is 1378 stored: 1380 o An attacker may gain access to view the log file, or may 1381 surreptitiously make a copy of the log file for later viewing; 1382 o An attacker may mount a replay attack by modifying existing 1383 records in the log file or inserting new records; 1384 o An attacker may delete parts of --- or indeed, the whole --- file. 1386 It is outside the scope of this document to specify how to protect 1387 the log file while it is stored on disk. However, operators may 1388 consider using common administrative features such as disk encryption 1389 and securing log files [schneier-1]. Operators may also consider 1390 hardening the machine on which the log files are stored by 1391 restricting physical access to the host as well as restricting access 1392 to the files themselves. 1394 In the worst case, public access to the SIP log file provides the 1395 same information that an adversary can gain using network sniffing 1396 tools (assuming that the SIP traffic is in clear text.) If all SIP 1397 traffic on a network segment is encrypted, then as noted above, 1398 special attention must be directed to the file and directory 1399 permissions associated with the log file to preserve privacy such 1400 that only a privileged user can access the contents of the log file. 1402 Transporting SIP CLF files across the network pose special challenges 1403 as well. The following threats may be considered for transferring 1404 log files or while transferring individual log records: 1406 o An attacker may view the records; 1407 o An attacker may modify the records in transit or insert previously 1408 captured records into the stream; 1409 o An attacker may remove records in transit, or may stage a man- in- 1410 the-middle attack to deliver a partially or entirely falsified log 1411 file. 1413 It is also outside the scope of this document to specify protection 1414 methods for log files or log records that are being transferred 1415 between hosts. However, operators may consider using common security 1416 protocols described in [RFC3552] to transfer log files or individual 1417 records. Alternatively, the log file may be transferred through bulk 1418 methods that also guarantees integrity, or at least detects and 1419 alerts to modification attempts. 1421 The SIP CLF represents the minimum fields that lend themselves to 1422 trend analysis and serve as information that may be deemed useful. 1423 Other formats can be defined that include more headers (and the body) 1424 from Section 8.1. However, where to draw a judicial line regarding 1425 the inclusion of non-mandatory headers can be challenging. Clearly, 1426 the more information a SIP entity logs, the longer time the logging 1427 process will take, the more disk space the log entry will consume, 1428 and the more potentially sensitive information could be breached. 1429 Therefore, adequate tradeoffs should be taken in account when logging 1430 more fields than the ones recommended in Section 8.1. 1432 Implementers need to pay particular attention to buffer handling when 1433 reading or writing log files. SIP CLF entries can be unbounded in 1434 length. It would be reasonable for a full dump of a SIP message to 1435 be thousands of octets long. This is of particular importance to CLF 1436 log parsers, as a SIP CLF log writers may add one or more extension 1437 fields to the message to be logged. 1439 11. Operational guidance 1441 SIP CLF log files will take up substantive amount of disk space 1442 depending on traffic volume at a processing entity and the amount of 1443 information being logged. As such, any enterprise using SIP CLF 1444 should establish operational procedures for file rollovers as 1445 appropriate to the needs of the organization. 1447 Listing such operational guidelines in this document is out of scope 1448 for this work. 1450 12. IANA Considerations 1452 This document does not require any considerations from IANA. 1454 13. Acknowledgments 1456 Members of the sipping, dispatch, ipfix and syslog working groups 1457 provided invaluable input to the formulation of the draft. These 1458 include Benoit Claise, Spencer Dawkins, John Elwell, David 1459 Harrington, Christer Holmberg, Hadriel Kaplan, Atsushi Kobayashi, 1460 Jiri Kuthan, Scott Lawrence, Chris Lonvick, Peter Musgrave, Simon 1461 Perreault, Adam Roach, Dan Romascanu, Robert Sparks, Brian Trammell, 1462 Dale Worley, Theo Zourzouvillys and others that we have undoubtedly, 1463 but inadvertently, missed. 1465 Rainer Gerhards, David Harrington, Cullen Jennings and Gonzalo 1466 Salgueiro helped tremendously in discussions related to arriving at 1467 the beginnings of a data model. 1469 14. References 1470 14.1. Normative References 1472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1473 Requirement Levels", BCP 14, RFC 2119, March 1997. 1475 14.2. Informative References 1477 [I-D.ietf-sipclf-format] 1478 Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1479 Session Initiation Protocol (SIP) Common Log Format 1480 (CLF)", draft-ietf-sipclf-format-01 (work in progress), 1481 March 2011. 1483 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1484 A., Peterson, J., Sparks, R., Handley, M., and E. 1485 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1486 June 2002. 1488 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1489 Text on Security Considerations", BCP 72, RFC 3552, 1490 July 2003. 1492 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1493 Authenticated Identity Management in the Session 1494 Initiation Protocol (SIP)", RFC 4474, August 2006. 1496 [rieck2008] 1497 Rieck, K., Wahl, S., Laskov, P., Domschitz, P., and K-R. 1498 Muller, "A Self-learning System for Detection of Anomalous 1499 SIP Messages", Principles, Systems and Applications of IP 1500 Telecommunications Services and Security for Next 1501 Generation Networks (IPTComm), LNCS 5310, pp. 90-106, 1502 2008. 1504 [schneier-1] 1505 Schneier, B. and J. Kelsey, "Secure audit logs to support 1506 computer forensics", ACM Transactions on Information and 1507 System Security (TISSEC), 2(2), pp. 159,176, May 1999. 1509 Authors' Addresses 1511 Vijay K. Gurbani (editor) 1512 Bell Laboratories, Alcatel-Lucent 1513 1960 Lucent Lane 1514 Naperville, IL 60566 1515 USA 1517 Email: vkg@bell-labs.com 1519 Eric W. Burger (editor) 1520 Georgetown University 1521 USA 1523 Email: eburger@standardstrack.com 1524 URI: http://www.standardstrack.com 1526 Tricha Anjali 1527 Illinois Institute of Technology 1528 316 Siegel Hall 1529 Chicago, IL 60616 1530 USA 1532 Email: tricha@ece.iit.edu 1534 Humberto Abdelnur 1535 INRIA 1536 INRIA - Nancy Grant Est 1537 Campus Scientifique 1538 54506, Vandoeuvre-les-Nancy Cedex 1539 France 1541 Email: Humberto.Abdelnur@loria.fr 1543 Olivier Festor 1544 INRIA 1545 INRIA - Nancy Grant Est 1546 Campus Scientifique 1547 54506, Vandoeuvre-les-Nancy Cedex 1548 France 1550 Email: Olivier.Festor@loria.fr