idnits 2.17.1 draft-ietf-insipid-logme-marking-13.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 170 has weird spacing: '...ple.com r1.e...' -- The document date (September 17, 2018) is 2048 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 1777, but not defined ** Downref: Normative reference to an Informational RFC: RFC 6064 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Dawes 3 Internet-Draft Vodafone Group 4 Intended status: Standards Track C. Arunachalam 5 Expires: March 21, 2019 Cisco Systems 6 September 17, 2018 8 Marking SIP Messages to be Logged 9 draft-ietf-insipid-logme-marking-13 11 Abstract 13 SIP networks use signaling monitoring tools to diagnose user-reported 14 problems and for regression testing if network or user agent software 15 is upgraded. As networks grow and become interconnected, including 16 connection via transit networks, it becomes impractical to predict 17 the path that SIP signaling will take between user agents, and 18 therefore impractical to monitor SIP signaling end-to-end. 20 This document describes an indicator for the SIP protocol which can 21 be used to mark signaling as being of interest to logging. Such 22 marking will typically be applied as part of network testing 23 controlled by the network operator and not used in normal user agent 24 signaling. Operators of all networks on the signaling path can agree 25 to carry such marking end-to-end, including the originating and 26 terminating SIP user agents, even if a session originates and 27 terminates in different networks. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 21, 2019. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 3. "Log Me" Marking Protocol Aspects . . . . . . . . . . . . . . 4 66 3.1. Session-ID logme Parameter . . . . . . . . . . . . . . . 4 67 3.2. Starting and Stopping Logging . . . . . . . . . . . . . . 4 68 3.3. Identifying Test Cases . . . . . . . . . . . . . . . . . 5 69 3.4. Passing the Marker . . . . . . . . . . . . . . . . . . . 6 70 3.4.1. To and From a User Device . . . . . . . . . . . . . . 6 71 3.4.2. To and From an External Network . . . . . . . . . . . 6 72 3.4.3. Across a Non-Supporting SIP Intermediary . . . . . . 6 73 3.5. Logging Multiple Simultaneous Dialogs . . . . . . . . . . 6 74 3.6. Format of Logged Signaling . . . . . . . . . . . . . . . 6 75 3.7. Marking Related Dialogs . . . . . . . . . . . . . . . . . 7 76 3.8. Forked Requests . . . . . . . . . . . . . . . . . . . . . 11 77 4. SIP Entity Behavior . . . . . . . . . . . . . . . . . . . . . 11 78 4.1. Scope of Marking . . . . . . . . . . . . . . . . . . . . 11 79 4.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 12 80 4.3. SIP Intermediaries Acting on Behalf of Endpoints . . . . 13 81 4.4. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 4.5. "Log me" Marker Processing by SIP Intermediaries . . . . 16 83 4.5.1. Stateless processing . . . . . . . . . . . . . . . . 16 84 4.5.2. Stateful processing . . . . . . . . . . . . . . . . . 16 85 4.5.2.1. "Log Me" marking not supported by Originating UA 17 86 4.5.2.2. "Log Me" marking not supported by Terminating UA 20 87 4.5.2.3. "Log Me" marking removed by Originating Network . 22 88 4.5.2.4. "Log Me" marking removed by Supporting 89 Terminating Network . . . . . . . . . . . . . . . 24 90 4.5.2.5. "Log Me" marking passed by Non-Supporting 91 Terminating Network . . . . . . . . . . . . . . . 26 92 5. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 93 5.1. Error Cases . . . . . . . . . . . . . . . . . . . . . . . 28 94 5.1.1. Missing "Log Me" Marker Error Case . . . . . . . . . 28 95 5.1.2. "Log Me" Marker Appears Mid-Dialog Error Case . . . . 32 96 5.2. Non-Error Cases . . . . . . . . . . . . . . . . . . . . . 33 97 5.2.1. Missing "Log me" Marker Non-Error Case . . . . . . . 33 98 5.2.2. "Log Me" Marker Appears Mid-Dialog Non-Error Case . . 35 99 5.2.3. Combining Dialogs Non-Error Case . . . . . . . . . . 35 100 5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 35 101 6. Augmented BNF for the "logme" Parameter . . . . . . . . . . . 36 102 7. Security Considerations . . . . . . . . . . . . . . . . . . . 36 103 7.1. "Log Me" Authorization . . . . . . . . . . . . . . . . . 36 104 7.2. "Log Me" Marker Removal . . . . . . . . . . . . . . . . . 37 105 7.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 37 106 7.4. Data Protection . . . . . . . . . . . . . . . . . . . . . 37 107 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 37 108 8.1. Personal Identifiers . . . . . . . . . . . . . . . . . . 38 109 8.2. Data Stored at SIP Intermediaries . . . . . . . . . . . . 38 110 8.3. Data Visible at Network Elements . . . . . . . . . . . . 39 111 8.4. Preventing Fingerprinting . . . . . . . . . . . . . . . . 39 112 8.5. Retaining Logs . . . . . . . . . . . . . . . . . . . . . 39 113 8.6. User Control of Logging . . . . . . . . . . . . . . . . . 40 114 8.7. Recommended Defaults . . . . . . . . . . . . . . . . . . 40 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 116 9.1. Registration of the "logme" Parameter . . . . . . . . . . 40 117 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 118 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 119 11.1. Normative References . . . . . . . . . . . . . . . . . . 41 120 11.2. Informative References . . . . . . . . . . . . . . . . . 43 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 44 123 1. Introduction 125 When users experience problems with setting up sessions using SIP, 126 enterprise or service provider network operators often have to 127 identify the root cause by examining the SIP signaling. Also, when 128 network or user agent software or hardware is upgraded, regression 129 testing is needed. Such diagnostics apply to a small proportion of 130 network traffic and can apply end-to-end, even if signaling crosses 131 several networks possibly belonging to several different network 132 operators. It may not be possible to predict the path through those 133 networks in advance, therefore a mechanism is needed to mark a 134 session as being of interest so that SIP entities along the signaling 135 path can provide diagnostic logging. [RFC8123] illustrates this 136 motivating scenario. This document describes a solution that meets 137 the requirements for such "log me" marking of SIP signaling also 138 defined in [RFC8123]. 140 This document defines a new header field parameter "logme" for the 141 "Session-ID" header field [RFC7989]. Implementations of this 142 document MUST implement [RFC7989]. 144 2. Requirements Language 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 148 "OPTIONAL" in this document are to be interpreted as described in BCP 149 14 [RFC2119] [RFC8174] when, and only when, they appear in all 150 capitals, as shown here. 152 3. "Log Me" Marking Protocol Aspects 154 3.1. Session-ID logme Parameter 156 Logging for diagnostic purposes is most effective when it is applied 157 end-to-end in a communication session. This ability requires a "log 158 me" marker to be passed through SIP intermediaries. The Session-ID 159 header field defined in [RFC7989] was chosen to carry the "log me" 160 marker as a "logme" parameter since the session identifier is 161 typically passed through SIP B2BUAs (described in [RFC7092]) or other 162 intermediaries, as per the Session-ID requirement REQ3 in [RFC7206]. 163 The "logme" parameter shown in Figure 1 does not introduce any 164 device-specific or user-specific information and MUST be passed 165 unchanged with the Session-ID header field except for the cases 166 specified in Section 3.4.2 where the "log me" marker may be removed 167 at a network boundary. 169 Alice Proxy Registrar 170 u1.example.com p1.example.com r1.example.com 171 | | | 172 |(1) INVITE | | 173 | Session-ID: ab30317f1a784dc48ff824d0d3715d86; 174 | remote=47755a9de7794ba387653f2099600ef2;logme 175 |----------------->| | 176 | | | 178 Figure 1: "Log Me" marking using the "logme" Session-ID header field 179 parameter 181 3.2. Starting and Stopping Logging 183 If a dialog is to be "log me" marked then marking MUST start with the 184 SIP request that initiates that dialog (dialog initiating requests 185 are described in Section 12.1 of [RFC3261]). For most effective 186 testing and troubleshooting, marking continues for the lifetime of 187 the dialog, applies to each request and response in that dialog, and 188 applies uninterrupted end-to-end including user devices. The "log 189 me" marking mechanism described in this document allows for parts of 190 the signaling path to not be marked, for example because an endpoint 191 does not support the "log me" marking mechanism (Section 4.5.2) or 192 because an endpoint or intermediary deliberately removes the "log me" 193 marker (see Section 4.5.2.4). Also, marking errors can terminate 194 marking before the dialog ends (see Section 5.3). 196 A user agent or intermediary adds a "log me" marker in an unmarked 197 request or response in two cases: firstly because it is configured to 198 add the marking to a dialog-creating request, or secondly because it 199 has received a dialog-creating request that is being "log me" marked, 200 causing it to maintain state to ensure that all requests and 201 responses in the dialog are similarly "log me" marked. Once the "log 202 me" marking is started for a dialog, all subsequent requests and 203 responses in this dialog are "log me" marked and marking is stopped 204 when this dialog and its related dialogs end. It is considered an 205 error (see Section 5.1.2) if "log me" marking is started in a mid- 206 dialog request or response. 208 For the first case, "log me" marking trigger condition configurations 209 that define whether a user agent or intermediary can initiate "log 210 me" marking for a given dialog are out of scope of this document. As 211 an example of trigger condition configurations, the user agent or 212 intermediary could be configured to add a "log me" marker for all 213 dialogs initiated during a specific time period (e.g., 9:00 am - 214 10:00 am every day), for specific dialogs that have a particular 215 "User-Agent" header field value, or for a specific set of called 216 party numbers for which users are experiencing call setup failures. 218 For the second case of a user agent or intermediary detecting that a 219 dialog-initiating request is being "log me" marked, the scope of such 220 marking extends to the lifetime of the dialog. In addition, as 221 discussed in Section 3.7, "log me" marked dialogs that create related 222 dialogs (e.g. REFER) may transfer the marking to the related 223 dialogs. In such cases, the entire "session", identified by the 224 Session-ID header field, is "log me" marked. 226 3.3. Identifying Test Cases 228 The local Universally Unique Identifier (UUID) portion of Session-ID 229 [RFC7989] in the initial SIP request of a dialog is used as a random 230 test case identifier (described in REQ 5 in [RFC8123]). This 231 provides the ability to collate all logged SIP requests and responses 232 to the initial SIP request in a dialog or standalone transaction. 234 3.4. Passing the Marker 236 3.4.1. To and From a User Device 238 When a user device inserts the "log me" marker, the marker MUST be 239 passed unchanged in the Session-ID header field across an edge proxy 240 or a B2BUA adjacent to the user device. 242 3.4.2. To and From an External Network 244 An external network is a peer network connected at a network boundary 245 as defined in [RFC8123]. 247 External networks may be connected directly or via a peering network 248 and such networks often have specific connection agreements. Whether 249 "log me" marking is removed depends upon the policy applied at the 250 network to network interface. Troubleshooting and testing will be 251 easier if peer networks endeavor to make agreements to pass "log me" 252 marking unchanged. However, since a "log me" marker may cause a SIP 253 entity to log the SIP header and body of a request or response, if no 254 agreement exists between peer networks then the "log me" marker MUST 255 be removed at a network boundary. 257 3.4.3. Across a Non-Supporting SIP Intermediary 259 "Log me" marking is most effective if passed end-to-end. However, 260 intermediaries that do not comply with this document might pass the 261 "log me" marker unchanged or drop it entirely. 263 3.5. Logging Multiple Simultaneous Dialogs 265 An originating or terminating user agent and SIP entities on the 266 signaling path can log multiple SIP dialogs simultaneously. These 267 dialogs are differentiated by their test case identifier (the local 268 UUID of the Session-ID header field at the originating device). 270 3.6. Format of Logged Signaling 272 The entire SIP message (SIP request line, response line, header 273 fields and message body) SHOULD be logged since troubleshooting might 274 be difficult if information is missing. Logging SHOULD use common 275 standard formats such as the SIP CLF defined in [RFC6873] and Libpcap 276 [application/vnd.tcpdump.pcap]. If SIP CLF format is used, the 277 entire message is logged using Vendor-ID = 00000000 and Tag = 02 in 278 the portion of the SIP CLF record (see [RFC6873] 279 section 4.4). Header fields SHOULD be logged in the form in which 280 they appear in the message, they SHOULD NOT be converted between long 281 and compact forms described in [RFC3261] section 7.3.3. 283 3.7. Marking Related Dialogs 285 "Log me" marking is done per-dialog and typically begins at dialog 286 creation and ends when the dialog ends. However, dialogs related to 287 a "log me" marked dialog MAY also be "log me" marked for call control 288 features such as call forward, transfer, park, and join. As 289 described in [RFC7989] section 6, related dialogs can occur when an 290 endpoint receives a 3xx message, a REFER that directs the endpoint to 291 a different peer, an INVITE request with Replaces that also 292 potentially results in communicating with a new peer, or an INVITE 293 with a Join header field as described in [RFC3911]. An example is 294 call transfer described in section 6.1 of [RFC5589] and the logged 295 signaling for related dialogs can be correlated using Session-ID 296 values as described in section 10.9 of [RFC7989]. 298 In the example shown in Figure 2, Alice has reported problems making 299 call transfers. Her terminal is placed in debug mode in preparation 300 to log marked signaling from the network administrator Bob. Bob's 301 terminal is configured to "log me" mark and log signaling for calls 302 originated during the troubleshooting session (e.g. for a duration of 303 15 minutes). Bob, who is troubleshooting the problem, arranges to 304 make a call that Alice can attempt to transfer. Bob calls Alice, 305 which creates initial dialog1, and then Alice transfers the call to 306 connect Bob to Carol. Logged signaling is correlated using the test 307 case identifier, which is the local UUID 308 ab30317f1a784dc48ff824d0d3715d86 in the Session-ID header field of 309 INVITE request F1. Logging by Alice's terminal begins when it 310 receives and echoes the "log me" marker in INVITE F1 and ends when 311 the last request or response in the dialog is sent or received (200 312 OK F7 of dialog1). Also during dialog1, Alice's terminal logs 313 related REFER dialog2 that it initiates and terminates as part of the 314 call transfer. Alice's terminal inserts a "log me" marker in the 315 REFER request and 200 OK responses to NOTIFY requests in dialog2. 316 Both dialog1 and dialog2 have the same test case identifier. 318 Logging by Bob's terminal begins when it sends INVITE F1, which 319 includes the "log me" marker, and ends when dialog3, initiated by 320 Bob, ends. Logging by Carol's terminal begins when it receives the 321 INVITE F5 with the "log me" marker and ends when dialog3 ends. 323 dialog3 is not logged by Alice's terminal, however the test case 324 identifier ab30317f1a784dc48ff824d0d3715d86 is also the test case 325 identifier (local-uuid) in INVITE F5. Also, the test case identifier 326 of dialog2, which is logged by Alice's terminal, can be linked to 327 dialog1 and dialog3 because the remote-uuid component of dialog2 is 328 the test case identifier ab30317f1a784dc48ff824d0d3715d86. 330 Alice Bob Carol 331 Transferor Transferee Transfer 332 | | Target 333 | INVITE F1 | | 334 dialog1 |<-------------------| | 335 | 200 OK F2 | | 336 dialog1 |------------------->| | 337 | ACK | | 338 dialog1 |<-------------------| | 339 | INVITE (hold) | | 340 dialog1 |------------------->| | 341 | 200 OK | | 342 dialog1 |<-------------------| | 343 | ACK | | 344 dialog1 |------------------->| | 345 | REFER F3 (Target-Dialog:1) | 346 dialog2 |------------------->| | 347 | 200 OK | | 348 dialog2 |<-------------------| | 349 | NOTIFY (100 Trying) F4 | 350 dialog2 |<-------------------| | 351 | 200 OK | | 352 dialog2 |------------------->| | 353 | | INVITE F5 | 354 dialog3 | |------------------->| 355 | | 200 OK | 356 dialog3 | |<-------------------| 357 | | ACK | 358 dialog3 | |------------------->| 359 | NOTIFY (200 OK) F6| | 360 dialog2 |<-------------------| | 361 | 200 OK | | 362 dialog2 |------------------->| | 363 | BYE | | 364 dialog1 |------------------->| | 365 | 200 OK F7 | | 366 dialog1 |<-------------------| | 367 | | BYE | 368 dialog3 | |<-------------------| 369 | | 200 OK | 370 dialog3 | |------------------->| 372 Figure 2: "Log me" marking related dialogs in call transfer 374 F1 - Bob's UA inserts the "logme" parameter in the Session-ID header 375 field of the INVITE request that creates dialog1. 377 F3 - Alice's UA inserts the "logme" parameter in the Session-ID 378 header field of the REFER request that creates dialog2 which is 379 related to dialog1. 381 F5 - Bob's UA inserts the "logme" parameter in the Session-ID header 382 field of the INVITE request that creates dialog3 which is related to 383 dialog1. 385 F1 INVITE Transferee -> Transferor 387 INVITE sips:transferor@atlanta.example.com SIP/2.0 388 Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432 389 Max-Forwards: 70 390 To: 391 From: ;tag=7553452 392 Call-ID: 090459243588173445 393 Session-ID: ab30317f1a784dc48ff824d0d3715d86 394 ;remote=00000000000000000000000000000000;logme 395 CSeq: 29887 INVITE 396 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 397 Supported: replaces, gruu, tdialog 398 Contact: 399 Content-Type: application/sdp 400 Content-Length: ... 402 F2 200 OK Transferor -> Transferee 404 SIP/2.0 200 OK 405 Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432 406 To: ;tag=31kdl4i3k 407 From: ;tag=7553452 408 Call-ID: 090459243588173445 409 Session-ID: 47755a9de7794ba387653f2099600ef2 410 ;remote=ab30317f1a784dc48ff824d0d3715d86;logme 411 CSeq: 29887 INVITE 412 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 413 Supported: replaces, gruu, tdialog 414 Contact: 415 Content-Type: application/sdp 416 Content-Length: ... 418 F3 REFER Transferor -> Transferee 420 REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0 421 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9 422 Max-Forwards: 70 423 To: 424 From: ;tag=1928301774 425 Call-ID: a84b4c76e66710 426 Session-ID: 47755a9de7794ba387653f2099600ef2 427 ;remote=ab30317f1a784dc48ff824d0d3715d86;logme 428 CSeq: 314159 REFER 429 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 430 Supported: gruu, replaces, tdialog 431 Require: tdialog 432 Refer-To: 433 Target-Dialog: 090459243588173445;local-tag=7553452 434 ;remote-tag=31kdl4i3k 435 Contact: 436 Content-Length: 0 438 F4 NOTIFY Transferee -> Transferor 440 NOTIFY sips:4889445d8kjtk3@atlanta.example.com 441 ;gr=723jd2d SIP/2.0 442 Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432 443 Max-Forwards: 70 444 To: ;tag=1928301774 445 From: 446 ;tag=a6c85cf 447 Call-ID: a84b4c76e66710 448 Session-ID: ab30317f1a784dc48ff824d0d3715d86 449 ;remote=47755a9de7794ba387653f2099600ef2;logme 450 CSeq: 73 NOTIFY 451 Contact: 452 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 453 Supported: replaces, tdialog 454 Event: refer 455 Subscription-State: active;expires=60 456 Content-Type: message/sipfrag 457 Content-Length: ... 459 F5 INVITE Transferee -> Transfer Target 461 INVITE sips:transfertarget@chicago.example.com SIP/2.0 462 Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas41234 463 Max-Forwards: 70 464 To: 465 From: ;tag=j3kso3iqhq 466 Call-ID: 90422f3sd23m4g56832034 467 Session-ID: ab30317f1a784dc48ff824d0d3715d86 468 ;remote=00000000000000000000000000000000;logme 469 CSeq: 521 REFER 470 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 471 Supported: replaces, gruu, tdialog 472 Contact: 473 Content-Type: application/sdp 474 Content-Length: ... 476 F6 NOTIFY Transferee -> Transferor 478 NOTIFY sips:4889445d8kjtk3@atlanta.example.com 479 ;gr=723jd2d SIP/2.0 480 Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432 481 Max-Forwards: 70 482 To: ;tag=1928301774 483 From: 484 ;tag=a6c85cf 485 Call-ID: a84b4c76e66710 486 Session-ID: ab30317f1a784dc48ff824d0d3715d86 487 ;remote=47755a9de7794ba387653f2099600ef2;logme 488 CSeq: 74 NOTIFY 489 Contact: 490 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY 491 Supported: replaces, tdialog 492 Event: refer 493 Subscription-State: terminated;reason=noresource 494 Content-Type: message/sipfrag 495 Content-Length: ... 497 3.8. Forked Requests 499 A SIP intermediary is required to copy the "log me" marker into 500 forked requests. SIP request forking is discussed in sections 4 and 501 16.6 of [RFC3261]. 503 4. SIP Entity Behavior 505 4.1. Scope of Marking 507 "Log me" marking is intended to be limited, in time period and number 508 of dialogs marked, to the minimum needed to troubleshoot a particular 509 problem or perform a particular test. 511 o SIP entities MUST be configured to "log me" mark only dialogs 512 needed for the current testing purpose e.g. troubleshooting or 513 regression testing. The mechanisms in this section ensure that 514 "log me" marking begins at dialog creation and, other than cases 515 of marking related dialogs or premature ending, ends when the 516 dialog being "log me" marked ends. 518 o If a dialog is to be marked, the only way to initiate "log me" 519 marking is at the dialog-creating request (e.g. SIP INVITE) sent 520 by an originating endpoint or an intermediary that marks on behalf 521 of the originating endpoint. Marking that appears mid-dialog is 522 an error as described in Section 5.1.2. The final terminating 523 endpoint or an intermediary that marks on behalf of the 524 terminating endpoint cannot initiate marking but takes action as 525 defined in Section 4.2 and Section 4.3 if it receives an incoming 526 "log me" marker. 528 Note that the error cases described in sections 5.1 and 5.2 cause SIP 529 entities to stop "log me" marking, and the requirements in Section 7 530 also place requirements on SIP entities, including allowing SIP 531 entities to not log signaling based on local policies (see 532 Section 8.6). 534 4.2. Endpoints 536 A common scenario is to have both originating and terminating 537 endpoints support "log me" marking with the originating endpoint 538 configured to initiate "log me" marking. In this simplest use case, 539 the originating user agent inserts a "log me" marker in the dialog- 540 creating SIP request and all subsequent SIP requests within that 541 dialog. The "log me" marker is passed through the SIP intermediaries 542 and arrives at the terminating user agent which echoes the "log me" 543 marker in the corresponding responses. If the terminating user agent 544 sends an in-dialog request on a dialog that is being "log me" marked, 545 it inserts a "log me" marker and the originating user agent echoes 546 the "log me" marker in responses. The terminating user agent logs 547 the "log me" marked SIP requests and responses if it is allowed as 548 per policy defined in the terminating network. This basic use case 549 suggests the following rules for originating and terminating user 550 agents. 552 For originating user agents: 554 o The originating user agent configured for "log me" marking MUST 555 insert a "log me" marker into the dialog-creating SIP request and 556 subsequent in-dialog SIP requests. 558 o The originating user agent itself logs marked requests and 559 responses. 561 o The originating user agent echoes, in responses, the "log me" 562 marker received in in-dialog requests from the terminating side. 564 o The originating user agent logs the SIP responses that it sends in 565 response to received "log me" marked in-dialog requests. 567 o The originating user agent MAY also apply these rules to any 568 subsequent related SIP dialogs as described in Section 3.7. 570 For terminating user agents: 572 o The terminating user agent detects that a dialog is of interest to 573 logging by the existence of a "log me" marker in an incoming 574 dialog-creating SIP request. 576 o The terminating user agent itself logs marked requests and 577 corresponding marked responses if allowed as per policy. 579 o The terminating user agent MUST echo a "log me" marker in 580 responses to a SIP request that included a "log me" marker. 582 o If the terminating user agent has detected that a dialog is being 583 "log me" marked, it MUST insert a "log me" marker in any in-dialog 584 SIP requests that it sends. 586 o The terminating user agent itself logs any in-dialog SIP requests 587 that it sends if allowed as per policy. 589 o The terminating user agent MAY also apply these rules to any 590 subsequent related SIP dialogs as described in Section 3.7. 592 4.3. SIP Intermediaries Acting on Behalf of Endpoints 594 A network operator may know that some of the user agents connected to 595 the network do not support "log me" marking. Subject to the 596 authorizations in Section 7.1, a SIP intermediary close to the user 597 agent (e.g. edge proxy, B2BUA) on the originating and/or terminating 598 sides inserts the "log me" marker instead in order to test sessions 599 involving such user agents. 601 The originating and terminating SIP intermediaries are not identified 602 by protocol means but are designated and explicitly configured by the 603 network administrator to "log me" mark on behalf of endpoints. The 604 intermediaries that are known to be closest to the terminals can be 605 configured to "log me" mark on behalf of terminals that do not 606 support "log me" marking. The originating SIP intermediary is the 607 first one to be traversed by a SIP request sent by the originating 608 endpoint. Similarly, the terminating SIP intermediary is last 609 intermediary traversed before the terminating endpoint is reached. 611 The SIP intermediary at the originating side is configured to insert 612 the "log me" marker on behalf of the originating endpoint. If the 613 terminating user agent does not echo the "log me" marker in responses 614 to a marked request then the SIP intermediary closest to the 615 terminating user agent, if configured to mark on behalf of the 616 terminating user agent, inserts a "log me" marker in responses to the 617 request. Likewise, if the terminating user agent sends an in-dialog 618 request, the SIP intermediary at the terminating side inserts a "log 619 me" marker and the SIP intermediary at the originating side echoes 620 the "log me" marker in responses to that request. Originating and 621 terminating intermediaries that are configured for "log me" marking 622 on behalf of the endpoint must also mark dialog-creating requests 623 that contain Target-Dialog [RFC4538], Join [RFC3911] and Replaces 624 [RFC3891] header fields and corresponding responses. The SIP 625 intermediaries at the originating and terminating sides log the "log 626 me" marked SIP requests and responses if it is allowed as per policy 627 defined in the originating and terminating networks. This scenario 628 suggests the following rules when a SIP intermediary is configured to 629 initiate or handle "log me" marking on behalf of a user agent. 631 For the originating SIP intermediary: 633 o The originating SIP intermediary configured for "log me" marking 634 MUST insert a "log me" marker into the dialog-creating SIP request 635 and subsequent in-dialog SIP requests. 637 o The originating SIP intermediary itself logs marked requests and 638 responses. 640 o The originating SIP intermediary detects the "log me" marker 641 received in in-dialog requests and echoes the "log me" marker in 642 the corresponding SIP responses. 644 o The originating SIP intermediary logs the SIP responses that it 645 sends in response to "log me" marked in-dialog requests. 647 o The originating SIP intermediary MAY also apply these rules to any 648 subsequent related SIP dialogs as described in Section 3.7). 650 For the terminating SIP intermediary: 652 o The terminating SIP intermediary detects that a dialog is of 653 interest to logging by the existence of a "log me" marker in an 654 incoming dialog-creating SIP request. 656 o The terminating SIP intermediary itself logs marked requests and 657 corresponding responses if allowed as per policy. 659 o The terminating SIP intermediary MUST echo a "log me" marker in 660 responses to a SIP request that included a "log me" marker. 662 o If terminating SIP intermediary has detected that a dialog is 663 being "log me" marked, it MUST insert a "log me" marker in any in- 664 dialog SIP requests from the terminating user agent. 666 o The terminating SIP intermediary itself logs any in-dialog SIP 667 requests that it sends if allowed as per policy. 669 o The terminating SIP intermediary MAY also apply these rules to any 670 subsequent related SIP dialogs as described in Section 3.7. 672 4.4. B2BUAs 674 B2BUA "log me" behavior is specified based on its different signaling 675 plane roles described in [RFC7092]. 677 A Proxy-B2BUA SHOULD copy "log me" marking in requests and responses 678 from its terminating to the originating side without needing explicit 679 configuration to do so. 681 A dialog on one "side" of the B2BUA may or may not be coupled to a 682 related dialog on the other "side" for "log me" purposes. To allow 683 end-to-end troubleshooting of user problems and regression testing, a 684 signaling-only and SDP-modifying signaling-only B2BUA [RFC7092] 685 SHOULD couple related dialogs for "log me" marking purposes and pass 686 on the received "log me" parameter from the originating side to 687 terminating side and vice versa. For example, a SIP B2BUA handling 688 an end-to-end session between an external caller and an agent in a 689 contact center environment can couple the dialog between itself and 690 an agent with the dialog between itself and external caller and pass 691 on the "log me" marking from originating side to terminating side to 692 enable end-to-end logging of specific sessions of interest. 694 For dialogs that are being "log me" marked, all B2BUAs MUST "log me" 695 mark in-dialog SIP requests that they generate on their own, without 696 needing explicit configuration to do so. This rule applies to both 697 the originating and terminating sides of a B2BUA. 699 4.5. "Log me" Marker Processing by SIP Intermediaries 701 4.5.1. Stateless processing 703 Typically, "log me" marking will be done by an originating UA and 704 echoed by a terminating UA. SIP intermediaries on the signaling path 705 between these UAs that do not perform the tasks described in 706 Section 4.3 or Section 4.4 MUST simply log any request or response 707 that contains a "log me" marker in a stateless manner, if it is 708 allowed per local policy. 710 4.5.2. Stateful processing 712 The originating and terminating SIP intermediaries that "log me" mark 713 on behalf of endpoints and SIP intermediaries that remove "log me" 714 marking at the network boundary must maintain state to enable "log 715 me" marking. Applicable scenarios are as follows. 717 o The originating UA does not support "log me" marking. This 718 scenario was described in Section 4.3 and requires support by the 719 originating SIP intermediary. "Log me" marker processing is 720 illustrated in Section 4.5.2.1. 722 o The terminating UA does not support "log me" marking. This 723 scenario was described in Section 4.3 and requires support by the 724 terminating SIP intermediary. "Log me" marker processing is 725 illustrated in Section 4.5.2.2. 727 o The originating network ensures that it does not pass marking 728 outside its boundaries in order to not impact any external 729 networks. The originating network removes "log me" marking from 730 SIP requests and responses before forwarding them from its network 731 boundary to external networks but adds marking back to any 732 incoming SIP requests and responses belonging to any "log me" 733 marked dialog. This scenario requires support by the SIP 734 intermediary at the originating network boundary and "log me" 735 marker processing is illustrated in Section 4.5.2.3. 737 o The terminating network ensures that it does not allow "log me" 738 marking from external networks to pass through its boundary to its 739 internal entities. The terminating network removes "log me" 740 marking from SIP requests and responses before forwarding them 741 internally but adds marking back to any outgoing SIP requests and 742 responses belonging to any "log me" marked dialog. This scenario 743 requires support by the SIP intermediary at the terminating 744 network boundary and "log me" marker processing is illustrated in 745 Section 4.5.2.4. 747 o The terminating network does not support "log me" marking and does 748 not echo marking that it receives. The originating network adds 749 marking back to any incoming SIP requests and responses belonging 750 to the "log me" marked dialog. This scenario requires support by 751 the SIP intermediary at the originating network boundary and "log 752 me" marker processing is illustrated in Section 4.5.2.5. 754 SIP intermediary behavior in these scenarios is illustrated using 755 [RFC3665] example call flow "Session Establishment Through Two 756 Proxies". 758 4.5.2.1. "Log Me" marking not supported by Originating UA 760 Alice's user agent does not support "log me" marking and hence Proxy 761 1, which is the SIP intermediary closest to Alice, is configured to 762 act on behalf of Alice's user agent to "log me" mark specific dialogs 763 of interest that are created by Alice for troubleshooting purposes. 765 In Figure 3 below, Proxy 1 in the originating network maintains state 766 of which dialogs are being logged in order to "log me" mark all SIP 767 requests and responses that it receives from Alice's user agent 768 before forwarding them to Proxy 2. 770 [ NETWORK A ] [ NETWORK B ] 771 Alice Proxy 1 Proxy 2 Bob 772 | | | | 773 | INVITE F1 | | | 774 | (no logme) | | | 775 |--------------->| | | 776 | | INVITE F2 | | 777 | | (logme) | | 778 | |--------------->| | 779 | | | | 780 | | | | 781 | 100 F3 | | INVITE F4 | 782 | (logme) | | (logme) | 783 |<---------------| 100 F5 |--------------->| 784 | | (logme) | | 785 | |<---------------| | 786 | | | 180 F6 | 787 | | | (logme) | 788 | | 180 F7 |<---------------| 789 | | (logme) | | 790 | 180 F8 |<---------------| | 791 | (logme) | | | 792 |<---------------| | 200 F9 | 793 | | | (logme) | 794 | | 200 F10 |<---------------| 795 | | (logme) | | 796 | 200 F11 |<---------------| | 797 | (logme) | | | 798 |<---------------| | | 799 | ACK F12 | | | 800 | (no logme) | | | 801 |--------------->| | | 802 | | | | 803 | | ACK F13 | | 804 | | (logme) | | 805 | |--------------->| | 806 | | | | 807 | | | ACK F14 | 808 | | | (logme) | 809 | | |--------------->| 810 | Both Way RTP Media | 811 |<================================================>| 812 | | | BYE F15 | 813 | | | (logme) | 814 | | BYE F16 |<---------------| 815 | | (logme) | | 816 | BYE F17 |<---------------| | 817 | (logme) | | | 818 |<---------------| | | 819 | 200 F18 | | | 820 | (no logme) | | | 821 |--------------->| | | 822 | | 200 F19 | | 823 | | (logme) | | 824 | |--------------->| | 825 | | | | 826 | | | 200 F20 | 827 | | | (logme) | 828 | | |--------------->| 829 | | | | 831 Figure 3: The originating UA does not support "log me" marking 833 F1 - Alice's UA does not insert a "log me" marker in the dialog- 834 creating INVITE request F1. Nevertheless, Proxy 1 is configured to 835 initiate logging on behalf of Alice. Proxy 1 logs INVITE request F1 836 and maintains state that this dialog is being logged. 838 F2 - Proxy 1 inserts a "log me" marker in INVITE request F2 before 839 forwarding it to Proxy 2 and also logs this request. 841 F3 - Proxy 1 inserts a "log me" marker in 100 response F3 before 842 forwarding it to Alice's UA since this is a response sent on a dialog 843 that is being "log me" marked and also logs this response. 845 F4 - Bob's UA detects the "log me" marker and logs the INVITE request 846 F4 if allowed as per policy. 848 F6 - Bob's UA echoes the "log me" marker in INVITE request F4 into 849 180 response F6. It logs this response if allowed as per policy. 851 F7 and F8 - Proxy 1 logs the received the "180" response F7 and 852 passes the "log me" marker to Alice's UA in F8. 854 F12 - Proxy 1 receives ACK with no "log me" marker. It doesn't 855 consider this as an error since it is configured to "log me" mark on 856 behalf of Alice's UA. 858 F13 - Proxy 1 inserts a "log me" marker in ACK request F13 before 859 forwarding it to Proxy 2 and also logs this request. 861 F15 - Bob's UA inserts a "log me" marker in the in-dialog BYE request 862 and this "log me" marker is carried back to Alice's UA in F16 and 863 F17. Bob's UA logs this request if allowed as per policy. 865 F18 - Alice's UA does not echo the "log me" marker from BYE request 866 F17 into 200 response F18. 868 F19 - Proxy 1 inserts a "log me" marker in 200 response F19 before 869 forwarding it to Proxy 2 and also logs this response. 871 4.5.2.2. "Log Me" marking not supported by Terminating UA 873 In Figure 4 below Bob's UA does not support "log me" marking, so 874 Proxy 2 in the terminating network maintains state to ensure "log me" 875 marking of SIP requests and responses from Bob's UA. 877 [ NETWORK A ] [ NETWORK B ] 878 Alice Proxy 1 Proxy 2 Bob 879 | | | | 880 | INVITE F1 | | | 881 | (log me) | | | 882 |--------------->| | | 883 | | INVITE F2 | | 884 | | (log me) | | 885 | |--------------->| | 886 | | | | 887 | | | | 888 | 100 F3 | | | 889 | (log me) | | | 890 |<---------------| | | 891 | | | INVITE F4 | 892 | | | (log me) | 893 | | 100 F5 |--------------->| 894 | | (log me) | | 895 | |<---------------| | 896 | | | 180 F6 | 897 | | | (no log me) | 898 | | |<---------------| 899 | | | | 900 | | | | 901 | | 180 F7 | | 902 | | (log me) | | 903 | |<---------------| | 904 | | | | 905 | | | | 906 | 180 F8 | | | 907 | (log me) | | | 908 |<---------------| | 200 F9 | 909 | | | (no log me) | 910 | | 200 F10 |<---------------| 911 | | (log me) | | 912 | 200 F11 |<---------------| | 913 | (log me) | | | 914 |<---------------| | | 915 | ACK F12 | | | 916 | (log me) | | | 917 |--------------->| | | 918 | | ACK F13 | | 919 | | (log me) | | 920 | |--------------->| ACK F14 | 921 | | | (log me) | 922 | | |--------------->| 923 | Both Way RTP Media | 924 |<================================================>| 925 | | | BYE F15 | 926 | | | (no log me) | 927 | | BYE F16 |<---------------| 928 | | (log me) | | 929 | BYE F17 |<---------------| | 930 | (log me) | | | 931 |<---------------| | | 932 | 200 F18 | | | 933 | (log me) | | | 934 |--------------->| | | 935 | | 200 F19 | | 936 | | (log me) | | 937 | |--------------->| 200 F20 | 938 | | | (log me) | 939 | | |--------------->| 940 | | | | 942 Figure 4: The terminating UA does not support "log me" marking. 944 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 945 INVITE request F1. 947 F2 - INVITE F2 is "log me" marked and Proxy 2 therefore maintains 948 state that this dialog is to be logged. Proxy 2 logs the request and 949 responses of this dialog if allowed per policy. 951 F5 - Proxy 2 inserts a "log me" marker in the 100 response it sends 952 to Proxy 1. 954 F6 - Bob's UA does not support "log me" marking, therefore the 180 955 response to the INVITE request doesn't have a "log me" marker. 957 F7 - Proxy 2 inserts a "log me" marker in the 180 response on behalf 958 of Bob's UA before forwarding it. The same applies to response F10 959 and the BYE request in F16. 961 4.5.2.3. "Log Me" marking removed by Originating Network 963 If network A in Figure 5 below is performing testing independently of 964 network B then network A removes "log me" marking from SIP requests 965 and responses forwarded to network B to prevent triggering unintended 966 logging in network B. Proxy 1 removes "log me" marking from requests 967 and responses that it forwards to Proxy 2 and maintains state of 968 which dialogs are being "log me" marked in order to "log me" mark 969 requests and responses that it forwards from Proxy 2 to Alice's user 970 agent. For troubleshooting purposes, Proxy 1 MAY also log the 971 requests and responses sent to or received from Proxy 2 even though 972 it removed "log me" marker prior to forwarding the messages to Proxy 973 2. 975 [ NETWORK A ] [ NETWORK B ] 976 Alice Proxy 1 Proxy 2 Bob 977 | | | | 978 | INVITE F1 | | | 979 | (logme) | | | 980 |--------------->| | | 981 | | INVITE F2 | | 982 | | (no logme) | | 983 | |--------------->| | 984 | | | | 985 | | | | 986 | 100 F3 | | | 987 | (logme) | | INVITE F4 | 988 | | | (no logme) | 989 |<---------------| 100 F5 |--------------->| 990 | | (no logme) | | 991 | |<---------------| | 992 | | | 180 F6 | 993 | | | (no logme) | 994 | | 180 F7 |<---------------| 995 | | (no logme) | | 996 | 180 F8 |<---------------| | 997 | (logme) | | | 998 |<---------------| | 200 F9 | 999 | | | (no logme) | 1000 | | 200 F10 |<---------------| 1001 | | (no logme) | | 1002 | 200 F11 |<---------------| | 1003 | (logme) | | | 1004 |<---------------| | | 1005 | ACK F12 | | | 1006 | (logme) | | | 1007 |--------------->| | | 1008 | | | | 1009 | | ACK F13 | | 1010 | | (no logme) | | 1011 | |--------------->| | 1012 | | | | 1013 | | | ACK F14 | 1014 | | | (no logme) | 1015 | | |--------------->| 1016 | Both Way RTP Media | 1017 |<================================================>| 1018 | | | BYE F15 | 1019 | | | (no logme) | 1020 | | BYE F16 |<---------------| 1021 | | (no logme) | | 1022 | BYE F17 |<---------------| | 1023 | (logme) | | | 1024 |<---------------| | | 1025 | 200 F18 | | | 1026 | (logme) | | | 1027 |--------------->| | | 1028 | | 200 F19 | | 1029 | | (no logme) | | 1030 | |--------------->| | 1031 | | | | 1032 | | | 200 F20 | 1033 | | | (no logme) | 1034 | | |--------------->| 1035 | | | | 1037 Figure 5: The originating network removes "log me" marking from 1038 outgoing SIP messages at its network edge. 1040 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 1041 INVITE request and Proxy 1 therefore maintains state that this dialog 1042 is to be logged. 1044 F2 - Proxy 1 removes "log me" marking from INVITE request before 1045 forwarding it to Proxy 2. Proxy 1 logs INVITE request F2. 1047 F3 - Proxy 1 inserts a "log me" marker in 100 response sent to 1048 Alice's user agent and logs this response. 1050 F8 - Proxy 1 inserts a "log me" marker in 180 response before 1051 forwarding it to Alice's user agent and logs this response. The same 1052 applies to responses F11, F17. 1054 F13 - Proxy 1 removes "log me" marking from ACK request and logs this 1055 request before forwarding it to Proxy 2. 1057 F19 - Proxy 1 removes "log me" marking from the 200 response of the 1058 BYE request and logs this response before forwarding it to Proxy 2. 1060 4.5.2.4. "Log Me" marking removed by Supporting Terminating Network 1062 In Figure 6 below Proxy 2 removes "log me" marking from all SIP 1063 requests and responses entering network B. However, Proxy 2 supports 1064 maintaining the marking state of the dialog and "log me" marks 1065 requests and responses that it sends towards Proxy 1. For 1066 troubleshooting purposes, Proxy 2 MAY also log the requests and 1067 responses received from or sent to Bob even though it removed "log 1068 me" marker prior to forwarding the messages to Bob. This scenario 1069 might be used for troubleshooting a signaling path between two 1070 enterprise or carrier networks, or across a transit network, with 1071 minimal logging (i.e., only at the network boundaries). 1073 [ NETWORK A ] [ NETWORK B ] 1074 Alice Proxy 1 Proxy 2 Bob 1075 | | | | 1076 | INVITE F1 | | | 1077 | (log me) | | | 1078 |--------------->| | | 1079 | | INVITE F2 | | 1080 | | (log me) | | 1081 | |--------------->| | 1082 | | | | 1083 | | | | 1084 | 100 F3 | | | 1085 | (log me) | | | 1086 |<---------------| | | 1087 | | | INVITE F4 | 1088 | | | (no log me) | 1089 | | 100 F5 |--------------->| 1090 | | (log me) | | 1091 | |<---------------| | 1092 | | | 180 F6 | 1093 | | | (no log me) | 1094 | | |<---------------| 1095 | | 180 F7 | | 1096 | | (log me) | | 1097 | |<---------------| | 1098 | | | | 1099 | | | | 1100 | 180 F8 | | | 1101 | (log me) | | | 1102 |<---------------| | 200 F9 | 1103 | | | (no log me) | 1104 | | 200 F10 |<---------------| 1105 | | (log me) | | 1106 | 200 F11 |<---------------| | 1107 | (log me) | | | 1108 |<---------------| | | 1109 | ACK F12 | | | 1110 | (log me) | | | 1111 |--------------->| | | 1112 | | ACK F13 | | 1113 | | (log me) | | 1114 | |--------------->| ACK F14 | 1115 | | | (no log me) | 1116 | | |--------------->| 1117 | Both Way RTP Media | 1118 |<================================================>| 1119 | | | BYE F15 | 1120 | | | (no log me) | 1121 | | BYE F16 |<---------------| 1122 | | (log me) | | 1123 | BYE F17 |<---------------| | 1124 | (log me) | | | 1125 |<---------------| | | 1126 | 200 F18 | | | 1127 | (log me) | | | 1128 |--------------->| | | 1129 | | 200 F19 | | 1130 | | (log me) | | 1131 | |--------------->| 200 F20 | 1132 | | | (no log me) | 1133 | | |--------------->| 1134 | | | | 1136 Figure 6: The terminating network removes "log me" marking from 1137 incoming SIP messages at its network edge. 1139 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 1140 INVITE request F1. Proxy 1 detects the "log me" marker, logs the 1141 request and maintains state that this dialog is to be logged. 1143 F2 - Proxy 2 removes "log me" marker in the INVITE request F2 before 1144 forwarding it as F4. The same applies to responses F13, F19. 1146 F6 - Proxy 2 inserts a "log me" marker in 180 response to the INVITE 1147 request and logs the request before forwarding it as F7. The same 1148 applies to response F9 and the BYE request in F15. 1150 4.5.2.5. "Log Me" marking passed by Non-Supporting Terminating Network 1152 In Figure 6 below Proxy 2 is not "log me" aware and therefore passes 1153 marking in all SIP requests and responses entering network B 1154 according to the rules in Section 16.6 and 16.7 of [RFC3261]. Proxy 1155 2 does not log requests and responses in the dialog. Proxy 1 1156 supports maintaining the marking state of the dialog. When Proxy 1 1157 observes that requests and responses received from Proxy 2 are not 1158 marked it adds the marking. 1160 For troubleshooting purposes, Proxy 1 MAY also log the requests and 1161 responses received from or sent to Proxy 2 even though Proxy 2 didn't 1162 add "log me" to messages sent to Proxy 1. 1164 [ NETWORK A ] [ NETWORK B ] 1165 Alice Proxy 1 Proxy 2 Bob 1166 | | | | 1167 | INVITE F1 | | | 1168 | (log me) | | | 1169 |--------------->| | | 1170 | | INVITE F2 | | 1171 | | (log me) | | 1172 | |--------------->| | 1173 | | | | 1174 | | | | 1175 | 100 F3 | | | 1176 | (log me) | | | 1177 |<---------------| | | 1178 | | | INVITE F4 | 1179 | | | (log me) | 1180 | | 100 F5 |--------------->| 1181 | | (no log me) | | 1182 | |<---------------| | 1183 | | | 180 F6 | 1184 | | | (no log me) | 1185 | | |<---------------| 1186 | | 180 F7 | | 1187 | | (no log me) | | 1188 | |<---------------| | 1189 | | | | 1190 | | | | 1191 | 180 F8 | | | 1192 | (log me) | | | 1193 |<---------------| | 200 F9 | 1194 | | | (no log me) | 1195 | | 200 F10 |<---------------| 1196 | | (no log me) | | 1197 | 200 F11 |<---------------| | 1198 | (log me) | | | 1199 |<---------------| | | 1200 | ACK F12 | | | 1201 | (log me) | | | 1202 |--------------->| | | 1203 | | ACK F13 | | 1204 | | (log me) | | 1205 | |--------------->| ACK F14 | 1206 | | | (log me) | 1207 | | |--------------->| 1208 | Both Way RTP Media | 1209 |<================================================>| 1210 | | | BYE F15 | 1211 | | | (no log me) | 1212 | | BYE F16 |<---------------| 1213 | | (no log me) | | 1214 | BYE F17 |<---------------| | 1215 | (log me) | | | 1216 |<---------------| | | 1217 | 200 F18 | | | 1218 | (log me) | | | 1219 |--------------->| | | 1220 | | 200 F19 | | 1221 | | (log me) | | 1222 | |--------------->| 200 F20 | 1223 | | | (log me) | 1224 | | |--------------->| 1225 | | | | 1227 Figure 7: The terminating network removes "log me" marking from 1228 incoming SIP messages at its network edge. 1230 F1 - Alice's UA inserts a "log me" marker in the dialog-creating 1231 INVITE request F1. Proxy 1 detects the "log me" marker, logs the 1232 request and maintains state that this dialog is to be logged. 1234 F2 - Proxy 2 passes the "log me" marker in the INVITE request F2 1235 before forwarding it as F4. The same applies to request F13 and 1236 response F19. 1238 F6 - Bob's UA does not support "log me" marking and does not echo the 1239 "log me" marker in response F6. The same applies to response F9 and 1240 the BYE request F15. 1242 F7 - Proxy 1 inserts a "log me" marker in 180 response of the INVITE 1243 request before forwarding it as F8. The same applies to response F10 1244 and the BYE request F16. 1246 5. Errors 1248 5.1. Error Cases 1250 The following error cases are possible for "log me" marking. 1252 1. A "log me" marker is unexpectedly missing from a dialog that is 1253 being logged. 1255 2. A "log me" marker unexpectedly appears in a dialog that is not 1256 being logged 1258 3. A "log me" marker unexpectedly disappears and then reappears in a 1259 dialog being logged. This is treated in the same way as case 1. 1261 4. A "log me" marker is unexpectedly missing from a retransmission 1262 in a dialog being logged. This is treated in the same way as 1263 case 1. 1265 These cases apply to any request or response sent by any entity and 1266 in any direction in a dialog being "log me" marked. Detection of 1267 these error cases is described in this section. 1269 5.1.1. Missing "Log Me" Marker Error Case 1271 Since "log me" marking is per dialog, if a dialog is being marked and 1272 marking is missing from a request or response then this is an error. 1274 However, detecting such errors is not as simple as checking for 1275 missing markers because of cases such as non-supporting terminals 1276 where it is normal that marking is not done. 1278 Detecting errors must be evaluated separately for each neighbor. It 1279 is an error if a particular neighbor has previously sent logme in the 1280 dialog and then stops, independently of what has been happening with 1281 other neighbors. 1283 User agents and intermediaries that are stateless with respect to 1284 "log me" marking are not able detect such errors. User agents and 1285 intermediaries that are stateful with respect to "log me" marking are 1286 able to detect that a marker is missing from a dialog that has 1287 previously been "log me" marked. Error cases are illustrated in this 1288 section, and non-error cases in Section 5.2.1. 1290 The following figures illustrate missing "Log me" Marker errors. 1292 Figure 8 shows an error detected at Proxy 1, where an expected "log 1293 me" marker is missing. 1295 [ NETWORK A ] [ NETWORK B ] 1296 Alice Proxy 1 Proxy 2 Bob 1297 | | | | 1298 | INVITE F1 | | | 1299 | (log me) | INVITE F2 | | 1300 |--------------->| (log me) | INVITE F3 | 1301 | |--------------->| (log me) | 1302 | | |--------------->| 1303 | | | | 1304 | | | 200 F4 | 1305 | | 200 F5 | (log me) | 1306 | 200 F6 | (log me) |<---------------| 1307 | (log me) |<---------------| | 1308 |<---------------| | | 1309 | | | | 1310 | ACK F7 | | | 1311 | (no log me) | | | 1312 |--------------->| | | 1313 | | ACK F8 | | 1314 | | (no log me) | | 1315 | |--------------->| | 1316 | | | ACK F9 | 1317 | | | (no log me) | 1318 | | |--------------->| 1320 Figure 8: Error case: missing "log me" marker 1322 F1 - Proxy 1 detects the "log me" marker and maintains state that 1323 this dialog is to be logged. 1325 F7 - Proxy 1 detects that the expected "log me" marker is missing, 1326 considers it as an error and stops "log me" marking in subsequent 1327 requests and responses in this dialog. 1329 Figure 9 shows an error detected at Proxy 2 and Bob's user agent. 1331 [ NETWORK A ] [ NETWORK B ] 1332 Alice Proxy 1 Proxy 2 Bob 1333 | INVITE F1 | | | 1334 | (log me) | | | 1335 |--------------->| | | 1336 | | INVITE F2 | | 1337 | | (log me) | | 1338 | |--------------->| | 1339 | | | | 1340 | | | | 1341 | 100 F3 | | | 1342 | (log me) | | | 1343 |<---------------| | | 1344 | | | INVITE F4 | 1345 | | | (log me) | 1346 | | 100 F5 |--------------->| 1347 | | (log me) | | 1348 | |<---------------| | 1349 | | | 180 F6 | 1350 | | | (log me) | 1351 | | |<---------------| 1352 | | 180 F7 | | 1353 | | (log me) | | 1354 | |<---------------| | 1355 | | | | 1356 | | | | 1357 | 180 F8 | | | 1358 | (log me) | | | 1359 |<---------------| | 200 F9 | 1360 | | | (log me) | 1361 | | 200 F10 |<---------------| 1362 | | (log me) | | 1363 | 200 F11 |<---------------| | 1364 | (log me) | | | 1365 |<---------------| | | 1366 | ACK F12 | | | 1367 | (no log me) | | | 1368 |--------------->| | | 1369 | | ACK F13 | | 1370 | | (no log me) | | 1371 | |--------------->| ACK F14 | 1372 | | | (no log me) | 1373 | | |--------------->| 1375 Figure 9: Error case: missing "log me" marker 1377 F2 - Proxy 2 detects the "log me" marker and maintains state that 1378 this dialog is to be logged. 1380 F4 - Bob's user agent detects the "log me" marker and maintains state 1381 that this dialog is to be logged. 1383 F12 - Proxy 1 detects that the expected "log me" marker is missing, 1384 considers it as an error and stops "log me" marking in subsequent 1385 requests and responses in this dialog. Hence it does not insert a 1386 "log me" marker in F13. 1388 F13 - Proxy 2 detects that the expected "log me" marker is missing, 1389 considers it as an error and stops "log me" marking in subsequent 1390 requests and responses in this dialog. 1392 F14 - Proxy 2 does not insert a "log me" marker because it has 1393 stopped "log me" marking due to an error observed in F13. Bob's UA 1394 detects that the expected "log me" marker is missing, considers it as 1395 an error and stops "log me" marking in subsequent requests and 1396 responses in this dialog. 1398 5.1.2. "Log Me" Marker Appears Mid-Dialog Error Case 1400 SIP endpoints, intermediaries acting on behalf of endpoints, and 1401 B2BUAs that can perform "log me" marking are stateful. Such entities 1402 will expect a "log me" marker only for dialogs where the initial 1403 dialog-creating request was "log me" marked, either by themselves or 1404 an upstream entity. "Log me" marking that subsequently begins mid- 1405 dialog is an error. 1407 Figure 10 illustrates a "log me" marking error observed in the middle 1408 of a dialog. Alice's UA supports "log me" marking but the call is 1409 not initially marked for logging i.e. INVITE F1 is not "log me" 1410 marked. But Alice's UA starts to "log me" mark at the ACK request 1411 F7. Proxy 1 supports "log me" marking at the originating network 1412 boundary and therefore detects the error, does not log signaling, and 1413 removes the "log me" marker before forwarding the ACK request F8. 1415 [ NETWORK A ] [ NETWORK B ] 1416 Alice Proxy 1 Proxy 2 Bob 1417 | | | | 1418 | INVITE F1 | | | 1419 | (no log me) | INVITE F2 | | 1420 |--------------->| (no log me) | INVITE F3 | 1421 | |--------------->| (no log me) | 1422 | | |--------------->| 1423 | | | | 1424 | | | 200 F4 | 1425 | | 200 F5 | (no log me) | 1426 | 200 F6 | (no log me) |<---------------| 1427 | (no log me) |<---------------| | 1428 |<---------------| | | 1429 | | | | 1430 | ACK F7 | | | 1431 | (log me) | | | 1432 |--------------->| | | 1433 | | ACK F8 | | 1434 | | (no log me) | | 1435 | |--------------->| | 1436 | | | ACK F9 | 1437 | | | (log me) | 1438 | | |--------------->| 1440 Figure 10: Error case: "log me" marker begins mid-dialog 1442 5.2. Non-Error Cases 1444 5.2.1. Missing "Log me" Marker Non-Error Case 1446 The following figure illustrates a non-error case. 1448 Figure 11 shows Proxy 2 receiving a response with no "log me" marker 1449 that is not an error case. Proxy 2 is configured by network B to 1450 perform "log me" marking on behalf of Bob's UA, which does not 1451 support "log me" marking. Proxy 2 does not therefore expect 1452 responses from Bob to include a "log me" marker. 1454 [ NETWORK A ] [ NETWORK B ] 1455 Alice Proxy 1 Proxy 2 Bob 1456 | | | | 1457 | INVITE F1 | | | 1458 | (log me) | | | 1459 |--------------->| | | 1460 | | INVITE F2 | | 1461 | | (log me) | | 1462 | |--------------->| | 1463 | | | | 1464 | | | | 1465 | 100 F3 | | | 1466 | (log me) | | | 1467 |<---------------| | | 1468 | | | INVITE F4 | 1469 | | | (log me) | 1470 | | 100 F5 |--------------->| 1471 | | (log me) | | 1472 | |<---------------| | 1473 | | | 180 F6 | 1474 | | | (no log me) | 1475 | | |<---------------| 1476 | | 180 F7 | | 1477 | | (log me) | | 1478 | |<---------------| | 1479 | 180 F8 | | | 1480 | (log me) | | | 1481 |<---------------| | | 1483 Figure 11: Non-error case: missing "log me" marker 1485 F2 - Proxy 2 detects the "log me" marker and maintains state that 1486 this dialog is to be logged. Proxy 2 inserts "log me" markers on 1487 behalf of Bob's user agent such as in F7. 1489 F6 - Proxy 2 detects that the "log me" marker is missing from the 1490 response but considers "log me" marking to be ongoing as a marker was 1491 not expected. 1493 F7 - Proxy 2 continues to "log me" mark requests and responses on 1494 behalf of Bob's user agent. 1496 5.2.2. "Log Me" Marker Appears Mid-Dialog Non-Error Case 1498 A SIP intermediary that can perform "log me" marking on behalf of an 1499 endpoint MAY optionally mark a request or response towards a non- 1500 supporting endpoint, such as the 100 response F3 in Figure 3. In 1501 this case the endpoint will receive a "log me" marker mid-dialog and 1502 is not considered an error. 1504 Another use case is a network in which some but not all endpoints 1505 support "log me" marking that wants to avoid treating endpoints 1506 differently by always managing "log me" marking at a SIP 1507 intermediary. In this case, the endpoint that supports "log me" is 1508 not configured to mark a dialog, instead the SIP intermediary is 1509 configured to perform "log me" marking on behalf of that endpoint. 1510 This case still requires authorization as described in Section 7.1. 1511 This SIP intermediary MAY optionally mark a request or response 1512 towards the endpoint, such as the 100 response F3 in Figure 3. The 1513 endpoint will receive a "log me" marker mid-dialog and this is not 1514 considered an error. 1516 5.2.3. Combining Dialogs Non-Error Case 1518 When troubleshooting call flows that involve the SIP Join header 1519 field specified in [RFC3911], the ideal scenario is to have "log me" 1520 marking enabled on all UAs and intermediaries participating in the 1521 end-to-end session. If the ideal scenario is not feasible, the 1522 following rules apply. 1524 o If a "log me"-aware endpoint or intermediary that is already "log 1525 me" marking a dialog receives a SIP INVITE with a Join header 1526 field and without a "log me" marker, it MUST NOT "log me" mark 1527 responses and requests exchanged within the new dialog established 1528 as a result of processing the SIP INVITE. 1530 o If a "log me"-aware endpoint or intermediary that is not "log me" 1531 marking a dialog receives a SIP INVITE with a Join header field 1532 and with a "log me" marker, it MUST "log me" mark responses and 1533 requests exchanged within the new dialog established as a result 1534 of processing the SIP INVITE as per Section 4 of this document. 1536 5.3. Error Handling 1538 The two error types that SIP entities must handle are defined in 1539 Section 5.1: a missing marker error and an error of "log me" marking 1540 that begins mid-dialog. Section 5.2 gives exceptions which have a 1541 missing marker or marking that begins mid-dialog but are not errors. 1543 If a missing marker error is detected by a UA, SIP intermediary, or 1544 B2BUA, it SHOULD consider this as an error condition in the "log me" 1545 functionality. It MUST NOT mark subsequent requests and responses 1546 and MUST stop logging messages in the same dialog. Any previously 1547 logged messages SHOULD be retained, for the time period defined in 1548 Section 8.5, and not deleted. 1550 If a "log me" marking that begins mid-dialog error is detected by a 1551 UA, SIP intermediary, or B2BUA, it SHOULD consider this as an error 1552 condition in the "log me" functionality. It MUST NOT forward the 1553 "log me" marker and MUST NOT log the message. It MUST NOT mark 1554 subsequent requests and responses and MUST NOT log subsequent 1555 messages in the same dialog. 1557 "Log me" marking errors can be detected and handled only by 1558 supporting UAs or B2BUAs. A SIP proxy as defined in [RFC3261] cannot 1559 detect or handle marking errors and will simply forward any "log me" 1560 marker it receives. 1562 6. Augmented BNF for the "logme" Parameter 1564 ABNF is described in [RFC5234]. This document introduces a new 1565 "logme" parameter for the Session-ID header field defined in 1566 Section 5 of [RFC7989]. 1568 sess-id-param =/ logme-param 1570 logme-param = "logme" 1572 Figure 12: Augmented BNF for the "logme" Parameter 1574 7. Security Considerations 1576 7.1. "Log Me" Authorization 1578 "Log me" marking MUST be disabled by default both at the endpoints 1579 and intermediaries and MUST be enabled only by authorized users. For 1580 example, an end user or network administrator must give permission 1581 for a terminal that supports "log me" marking in order to initiate 1582 marking. Similarly, a network administrator must enable a 1583 configuration at the SIP intermediary to perform "log me" marking on 1584 behalf of a terminal that does not support "log me" marking. The 1585 permission MUST be limited to only specific calls of interest that 1586 are originated in a given time duration. 1588 Activating a debug mode affects the operation of a terminal, 1589 therefore debugging configuration MUST be supplied by an authorized 1590 party to an authorized terminal through a secure communication 1591 channel. 1593 7.2. "Log Me" Marker Removal 1595 The log me marker is not sensitive information, although it will 1596 sometimes be inserted because a particular device is experiencing 1597 problems. 1599 The presence of a log me marker will cause some SIP entities to log 1600 signaling messages. Therefore, this marker MUST be removed at the 1601 earliest opportunity if it has been incorrectly inserted, such as 1602 appearing mid-dialog in a dialog that was not being logged or outside 1603 the configured start and stop of logging. 1605 If SIP requests and responses are exchanged with an external network 1606 with which there is no agreement to pass "log me" marking, then the 1607 "log me" marking is removed as mandated in Section 3.4.2. This 1608 behavior applies to incoming and outgoing requests and responses. 1610 7.3. Denial of Service Attacks 1612 Maliciously configuring a large number of terminals to simultaneously 1613 mark dialogs with a "log me" marker will cause high processor load on 1614 SIP entities that are logging signaling. Since "log me" marking is 1615 for the small number of dialogs subject to troubleshooting or 1616 regression testing, the number of dialogs that can be simultaneously 1617 logged can be statically limited without adversely affecting the 1618 usefulness of "log me" marking. Also, the SIP intermediary closest 1619 to the terminal and SIP intermediary at network edge (e.g Session 1620 Border Controllers) can be configured to screen-out "log me" markers 1621 when troubleshooting or regression testing is not in progress. 1623 7.4. Data Protection 1625 A SIP entity that has logged information MUST protect the logs. 1626 Storage of the log files are subject to the security considerations 1627 specified in [RFC6872]. 1629 8. Privacy Considerations 1631 Logging includes all SIP header fields. The SIP privacy mechanisms 1632 defined in [RFC3323] can be used to ensure that logs do not divulge 1633 personal identity information in the core SIP header fields specified 1634 in [RFC3261]. 1636 Privacy mechanisms might also need to be applied to header fields 1637 defined by SIP extensions and for managing the confidentiality of the 1638 Request URI and SIP header fields and bodies. 1640 8.1. Personal Identifiers 1642 "Log me" marking is defined for the SIP Protocol, and SIP has header 1643 fields such as From, Contact, P-Asserted-Identity that can carry 1644 personal identifiers. Different protocol interactions can be 1645 correlated using the Session-ID and Call-ID header fields, but such 1646 correlation is limited to a single end-to-end session. 1648 In order to protect user privacy during logging, privacy settings can 1649 be enabled or requested by the terminal used by the end user. 1650 [RFC3323] suggests two mechanisms: 1652 o By using the value anonymous in the From header field 1654 o By requesting header- and session-level privacy from SIP 1655 intermediaries using the Privacy header 1657 Endpoints that support Globally Routable User Agent URIs (GRUUs) can 1658 use a temporary GRUU (see Section 3.1.2 of [RFC5627]) assigned by the 1659 Registrar in order to protect user privacy as discussed in 1660 Section 10.3 of [RFC5627]. 1662 Intermediaries that perform "log me" marking on behalf of the 1663 endpoints (see Section 4.3) may also be configured to apply privacy 1664 (as defined in Section 3.3 of [RFC3323]) on messages that belong to a 1665 dialog that is "log me" marked. 1667 Complete anonymization (e.g. the Request URI and the "username" field 1668 in the "o=" parameter of an SDP body) may not be possible in all 1669 circumstances and therefore administrators of the originating and 1670 terminating networks should consider how privacy will be ensured when 1671 providing consent for "log me" marking. 1673 "Log me" marking is typically used for troubleshooting and regression 1674 testing, and in some cases a service provider owned device with a 1675 dummy account can be used instead of a customer device. In such 1676 cases, no personal identifiers are included in the logged signaling 1677 messages. 1679 8.2. Data Stored at SIP Intermediaries 1681 SIP endpoints and intermediaries that honor the "log me" request 1682 store all the SIP messages that are exchanged within a given dialog. 1683 SIP messages can contain the personal identifiers listed in 1684 Section 8.1 and additionally a user identity, calling party number, 1685 IP address, hostname, and other user and device related items. The 1686 SIP message bodies describe the kind of session being set up by the 1687 identified end user and device. 1689 "Log me" marking does not introduce any additional user or device 1690 data to SIP but might indicate that a specific user is experiencing a 1691 problem. 1693 If the SIP SDP parameters [sdp-parameters] contain sensitive security 1694 information (e.g. encryption keys) such as "crypto" [RFC4568], 3GPP- 1695 Integrity-Key, or 3GPP-SRTP-Config [RFC6064] attributes then the 1696 attribute value MUST be masked with a dummy value prior to storing 1697 the message in a log file. For example, the attribute value can be 1698 replaced with a string of special characters like "X", "*" and "#" as 1699 shown in the example below. 1701 a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX 1702 XXXXXXXXXXXXX 1704 8.3. Data Visible at Network Elements 1706 SIP messages that are logged due to "log me" requests are stored only 1707 by the SIP initiators, intermediaries and recipients. Enablers as 1708 defined in section 3.1 of [RFC6973], such as firewalls and DNS 1709 servers do not log messages due to the "log me" marking. 1711 8.4. Preventing Fingerprinting 1713 "Log me" functionality is typically used to troubleshoot a given 1714 problem and hence it can be used as an method to identify users and 1715 devices that are experiencing issues. The best way to prevent 1716 fingerprinting of users is to enable or request SIP privacy for the 1717 logged dialog. 1719 8.5. Retaining Logs 1721 The lifetime of "log me" marking is equivalent to the lifetime of the 1722 dialog that initiated the "log me" request. When "log me" is 1723 extended to related dialogs the lifetime is extended until there is 1724 no more related dialog for the end-to-end session. 1726 "Log me" automatically expires at the end of the dialog and there is 1727 no explicit mechanism to turn off logging within a dialog. 1729 The scope of "log me" Marking is limited i.e. an user or the network 1730 administrator has to enable it on a per session basis or for a 1731 specific time period. This minimizes the risk of exposing user data 1732 for an indefinite time. 1734 The retention time period for logged messages SHOULD be the minimum 1735 needed for each particular troubleshooting or testing case. The 1736 retention period is configured based on the data retention policies 1737 of service providers and enterprises. 1739 8.6. User Control of Logging 1741 Consent to turn on "log me" marking for a given session MUST be 1742 provided by the end user or by the network administrator. It is 1743 handled outside of the protocol through user interface or application 1744 programming interfaces at the end point, call control elements and 1745 network management systems. 1747 Originating and terminating endpoints that are "log me" aware and 1748 have a user interface MUST indicate (using text, icon etc.) to the 1749 user that a session is being logged. 1751 SIP entities across the communication path MAY be configured to pass 1752 through the "log me" marking but not honor the request i.e. not log 1753 the data based on local policies. 1755 8.7. Recommended Defaults 1757 The recommended defaults for "log me" marking are: 1759 o turn on SIP privacy as described in Section 8 or use a service 1760 provider owned device with a dummy user identity for test calls 1762 o use the local UUID of Session-ID header field at the originating 1763 device as the test case identifier as described in Section 3.3 1765 9. IANA Considerations 1767 9.1. Registration of the "logme" Parameter 1769 The following parameter is to be added to the "Header Field 1770 Parameters and Parameter Values" section of the SIP parameter 1771 registry: 1773 +-------------+---------------+-------------------------+-----------+ 1774 | Header | Parameter | Predefined Values | Reference | 1775 | Field | Name | | | 1776 +-------------+---------------+-------------------------+-----------+ 1777 | Session-ID | logme | No (no values are | [RFCXXXX] | 1778 | | | allowed) | | 1779 +-------------+---------------+-------------------------+-----------+ 1781 Table 1 1783 10. Acknowledgments 1785 The authors wish to thank Paul Giralt, Paul Kyzivat, Jorgen Axell, 1786 Christer Holmberg, Vijay Gurbani, Ben Campbell, Gonzalo Salgueiro, 1787 Francesca Palombini, Adam Roach, Mirja Kuhlewind, Benjamin Kaduk, 1788 Eric Rescorla, Alissa Cooper, Warren Kumari, and Alexey Melnikov for 1789 their constructive review comments and guidance while developing this 1790 document. 1792 11. References 1794 11.1. Normative References 1796 [application/vnd.tcpdump.pcap] 1797 Harris, G., "MIME type application/vnd.tcpdump.pcap", 1798 March 2011, . 1801 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1802 Requirement Levels", BCP 14, RFC 2119, 1803 DOI 10.17487/RFC2119, March 1997, 1804 . 1806 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1807 A., Peterson, J., Sparks, R., Handley, M., and E. 1808 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1809 DOI 10.17487/RFC3261, June 2002, 1810 . 1812 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 1813 Initiation Protocol (SIP)", RFC 3323, 1814 DOI 10.17487/RFC3323, November 2002, 1815 . 1817 [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 1818 Protocol (SIP) "Replaces" Header", RFC 3891, 1819 DOI 10.17487/RFC3891, September 2004, 1820 . 1822 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 1823 (SIP) "Join" Header", RFC 3911, DOI 10.17487/RFC3911, 1824 October 2004, . 1826 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 1827 Identification in the Session Initiation Protocol (SIP)", 1828 RFC 4538, DOI 10.17487/RFC4538, June 2006, 1829 . 1831 [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session 1832 Description Protocol (SDP) Security Descriptions for Media 1833 Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, 1834 . 1836 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1837 Agent URIs (GRUUs) in the Session Initiation Protocol 1838 (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, 1839 . 1841 [RFC6064] Westerlund, M. and P. Frojdh, "SDP and RTSP Extensions 1842 Defined for 3GPP Packet-Switched Streaming Service and 1843 Multimedia Broadcast/Multicast Service", RFC 6064, 1844 DOI 10.17487/RFC6064, January 2011, 1845 . 1847 [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, 1848 H., and O. Festor, "The Common Log Format (CLF) for the 1849 Session Initiation Protocol (SIP): Framework and 1850 Information Model", RFC 6872, DOI 10.17487/RFC6872, 1851 February 2013, . 1853 [RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the 1854 Session Initiation Protocol (SIP) Common Log Format 1855 (CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013, 1856 . 1858 [RFC7989] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End- 1859 to-End Session Identification in IP-Based Multimedia 1860 Communication Networks", RFC 7989, DOI 10.17487/RFC7989, 1861 October 2016, . 1863 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1864 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1865 May 2017, . 1867 [sdp-parameters] 1868 "Session Description Protocol (SDP) Parameters", June 1869 2001, . 1872 11.2. Informative References 1874 [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and 1875 K. Summers, "Session Initiation Protocol (SIP) Basic Call 1876 Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, 1877 December 2003, . 1879 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 1880 Specifications: ABNF", STD 68, RFC 5234, 1881 DOI 10.17487/RFC5234, January 2008, 1882 . 1884 [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session 1885 Initiation Protocol (SIP) Call Control - Transfer", 1886 BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009, 1887 . 1889 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1890 Morris, J., Hansen, M., and R. Smith, "Privacy 1891 Considerations for Internet Protocols", RFC 6973, 1892 DOI 10.17487/RFC6973, July 2013, 1893 . 1895 [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session 1896 Initiation Protocol (SIP) Back-to-Back User Agents", 1897 RFC 7092, DOI 10.17487/RFC7092, December 2013, 1898 . 1900 [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. 1901 Kaplan, "Requirements for an End-to-End Session 1902 Identification in IP-Based Multimedia Communication 1903 Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014, 1904 . 1906 [RFC8123] Dawes, P. and C. Arunachalam, "Requirements for Marking 1907 SIP Messages to be Logged", RFC 8123, 1908 DOI 10.17487/RFC8123, March 2017, 1909 . 1911 Authors' Addresses 1913 Peter Dawes 1914 Vodafone Group 1915 The Connection 1916 Newbury, Berkshire RG14 2FN 1917 UK 1919 Email: peter.dawes@vodafone.com 1921 Chidambaram Arunachalam 1922 Cisco Systems 1923 7200-12 Kit Creek Road 1924 Research Triangle Park, NC 27709 1925 US 1927 Email: carunach@cisco.com