RFC 8497
Marking SIP Messages to Be Logged
Marking SIP Messages to Be Logged 🎀
Okay bestie, this is RFC 8497 💖 Here's the title block tea: it's from the IETF, it's on the Standards Track, and it was published in November 2018. The authors are P. Dawes (Vodafone Group) and C. Arunachalam (Cisco Systems), and the ISSN is 2070-1721. The header doesn't list anything it obsoletes or updates. ✨
Abstract ✨
Okay so SIP networks use signaling monitoring tools 🔍 to figure out why users are reporting problems, and to run regression testing whenever network or user agent (UA) software gets upgraded. As networks get bigger and more interconnected, including connections through transit networks, it becomes impractical to predict which path SIP signaling will take between user agents, so it's also impractical to monitor that signaling end to end 😭
This document describes an indicator for SIP that can mark signaling as being of interest to logging 🦋 That marking is usually applied during network testing that the network operator controls, and it's not used in normal user agent signaling. Operators of every network on the signaling path can agree to carry the marking end to end, including the originating and terminating SIP user agents, even when a session starts and ends in different networks 🫶
Status of This Memo
This is an Internet Standards Track document. 💅
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has had public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. ✨
Information about the current status of this document, any errata, and how to give feedback on it can be found at https://www.rfc-editor.org/info/rfc8497. 🌸
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License. 💜
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. "Log Me" Marking Protocol Aspects . . . . . . . . . . . . . . 4
3.1. Session-ID "logme" Parameter . . . . . . . . . . . . . . 4
3.2. Starting and Stopping Logging . . . . . . . . . . . . . . 5
3.3. Identifying Test Cases . . . . . . . . . . . . . . . . . 6
3.4. Passing the Marker . . . . . . . . . . . . . . . . . . . 6
3.4.1. To/From a User Device . . . . . . . . . . . . . . . . 6
3.4.2. To/From an External Network . . . . . . . . . . . . . 6
3.4.3. Across a Non-supporting SIP Intermediary . . . . . . 6
3.5. Logging Multiple Simultaneous Dialogs . . . . . . . . . . 6
3.6. Format of Logged Signaling . . . . . . . . . . . . . . . 7
3.7. Marking-Related Dialogs . . . . . . . . . . . . . . . . . 7
3.8. Forked Requests . . . . . . . . . . . . . . . . . . . . . 13
4. SIP Entity Behavior . . . . . . . . . . . . . . . . . . . . . 13
4.1. Scope of Marking . . . . . . . . . . . . . . . . . . . . 13
4.2. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. SIP Intermediaries Acting on Behalf of Endpoints . . . . 15
4.4. B2BUAs . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.5. "Log Me" Marker Processing by SIP Intermediaries . . . . 17
4.5.1. Stateless Processing . . . . . . . . . . . . . . . . 17
4.5.2. Stateful Processing . . . . . . . . . . . . . . . . . 17
4.5.2.1. "Log Me" Marking Not Supported by Originating UA 18
4.5.2.2. "Log Me" Marking Not Supported by Terminating UA 21
4.5.2.3. "Log Me" Marking Removed by Originating Network . 23
4.5.2.4. "Log Me" Marking Removed by Supporting
Terminating Network . . . . . . . . . . . . . . . 26
4.5.2.5. "Log Me" Marking Passed by Non-supporting
Terminating Network . . . . . . . . . . . . . . . 28
5. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1. Error Cases . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1. Missing "Log Me" Marker Error Case . . . . . . . . . 31
5.1.2. "Log Me" Marker Appears Mid-dialog Error Case . . . . 35
5.2. Non-error Cases . . . . . . . . . . . . . . . . . . . . . 36
5.2.1. Missing "Log Me" Marker Non-error Case . . . . . . . 36
5.2.2. "Log Me" Marker Appears Mid-dialog Non-error Case . . 37
5.2.3. Combining Dialogs Non-error Case . . . . . . . . . . 37
5.3. Error Handling . . . . . . . . . . . . . . . . . . . . . 38
6. Augmented BNF for the "logme" Parameter . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
7.1. "Log Me" Authorization . . . . . . . . . . . . . . . . . 39
7.2. "Log Me" Marker Removal . . . . . . . . . . . . . . . . . 39
7.3. Denial-of-Service Attacks . . . . . . . . . . . . . . . . 39
7.4. Data Protection . . . . . . . . . . . . . . . . . . . . . 40
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 40
8.1. Personal Identifiers . . . . . . . . . . . . . . . . . . 40
8.2. Data Stored at SIP Intermediaries . . . . . . . . . . . . 41
8.3. Data Visible at Network Elements . . . . . . . . . . . . 41
8.4. Preventing Fingerprinting . . . . . . . . . . . . . . . . 41
8.5. Retaining Logs . . . . . . . . . . . . . . . . . . . . . 42
8.6. User Control of Logging . . . . . . . . . . . . . . . . . 42
8.7. Recommended Defaults . . . . . . . . . . . . . . . . . . 42
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Registration of the "logme" Parameter . . . . . . . . . . 43
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 45
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 461. Introduction ✨
Okay so when users have trouble setting up sessions with SIP, enterprise or service provider network operators often have to find the root cause by examining the SIP signaling 🕵️♀️ Also, whenever network or user agent (UA) software or hardware gets upgraded, regression testing is needed. These diagnostics apply to a small share of network traffic, and they can apply end to end, even when signaling crosses several networks that might belong to different network operators. It may not be possible to predict the path through those networks in advance, so we need a mechanism to mark a session as being of interest, so that SIP entities along the signaling path can provide diagnostic logging. [RFC8123] illustrates this motivating scenario. This document describes a solution that meets the requirements for this "log me" marking of SIP signaling, which are also defined in [RFC8123]. 💖
This document also defines a new header field parameter, "logme", for the Session-ID header field [RFC7989]. Implementations of this document MUST implement [RFC7989]. 🎀
2. Requirements Language 🌈
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 💅
3. "Log Me" Marking Protocol Aspects 🦋
3.1. Session-ID "logme" Parameter 🧚
Logging for diagnostic purposes works best when it's applied end to end in a communication session 🙌 That means the "log me" marker has to get passed through SIP intermediaries. The Session-ID header field defined in [RFC7989] was picked to carry the "log me" marker as a "logme" parameter, because the session identifier usually gets passed through SIP Back-to-Back User Agents (B2BUAs) (described in [RFC7092]) or other intermediaries. That's per the Session-ID requirement REQ3 in [RFC7206]. The "logme" parameter shown in Figure 1 does not introduce any device-specific or user-specific information, and it MUST be passed unchanged with the Session-ID header field. 🔐 There is one exception, though: in the cases specified in Section 3.4.2, the "log me" marker may be removed at a network boundary. 🫣
Alice Proxy Registrar
u1.example.com p1.example.com r1.example.com
| | |
|(1) INVITE | |
| Session-ID: ab30317f1a784dc48ff824d0d3715d86;
| remote=47755a9de7794ba387653f2099600ef2;logme
|----------------->| |
| | |
Figure 1: "Log Me" Marking Using the
"logme" Session-ID Header Field Parameter3.2. Starting and Stopping Logging 💖
Okay so, if a dialog is getting the "log me" treatment, the marking MUST start with the SIP request that kicks off that dialog. (Dialog-initiating requests are described in Section 12.1 of [RFC3261], so go check that if you want the details 🤓.) For the best testing and troubleshooting, the marking keeps going for the whole lifetime of the dialog, covers every request and response in it, and runs uninterrupted end to end, including user devices 🎀.
The "log me" mechanism in this document does allow for some parts of the signaling path to be left unmarked. That can happen because an endpoint doesn't support "log me" marking (see Section 4.5.2), or because an endpoint or intermediary deliberately strips the "log me" marker (see Section 4.5.2.4). Also, marking errors can end the marking before the dialog is over (see Section 5.3). Messy, but it happens 🙈.
A UA or intermediary adds a "log me" marker to an unmarked request or response in two situations. The first is when it's configured to add the marking to a dialog-creating request. The second is when it has received a dialog-creating request that's already being "log me" marked, so it keeps state to make sure every request and response in that dialog gets marked too 🧚. Once the marking has started for a dialog, every later request and response in that dialog is "log me" marked. Marking stops when this dialog and its related dialogs end. And here's the big rule: it's an error (see Section 5.1.2) if "log me" marking starts in a mid-dialog request or response. Not cute 💀.
For the first case, the trigger configurations that decide whether a UA or intermediary can start "log me" marking for a given dialog are out of scope for this document. Just an example of what those configurations could look like: the UA or intermediary might be set to add a "log me" marker to every dialog started during a specific time window (say, 9:00 am - 10:00 am every day), or to dialogs carrying a particular User-Agent header field value. It could also be set to mark a specific set of called party numbers where users are having call setup failures 📞✨.
For the second case, where a UA or intermediary notices that a dialog-initiating request is already being "log me" marked, the marking covers the lifetime of the dialog. Also, as Section 3.7 explains, "log me" marked dialogs that create related dialogs (like with REFER) can pass the marking along to those related dialogs. When that happens, the entire "session", identified by the Session-ID header field, gets "log me" marked 🌈.
3.3. Identifying Test Cases 🦋
The local Universally Unique Identifier (UUID) part of the Session-ID header field value [RFC7989] in the initial SIP request of a dialog is used as a random test case identifier (described in REQ 5 in [RFC8123]). This is the magic bit: it lets you collate all the logged SIP requests and responses that belong to the initial SIP request, whether they're in a dialog or a standalone transaction 🔥.
3.4. Passing the Marker 🍓
3.4.1. To/From a User Device
When a user device inserts the "log me" marker, the marker MUST be passed unchanged in the Session-ID header field across an edge proxy or a B2BUA next to the user device. No edits, no drama 💅.
3.4.2. To/From an External Network
An external network is a peer network connected at a network boundary, as defined in [RFC8123].
External networks can connect directly or through a peering network, and those connections often come with specific agreements. Whether the "log me" marking gets removed depends on the policy at the network-to-network interface. Troubleshooting and testing get way easier if peer networks try their best to agree to pass the "log me" marking through unchanged 🫶. But here's the catch: since a "log me" marker can make a SIP entity log the SIP header and body of a request or response, the "log me" marker MUST be removed at a network boundary if no agreement exists between peer networks.
Privacy check, bestie: no agreement means the marker has to go at the boundary 🔒.
3.4.3. Across a Non-supporting SIP Intermediary
"Log me" marking works best when it's passed end to end. The thing is, intermediaries that don't comply with this document might pass the "log me" marker through unchanged, or they might drop it entirely 😭.
3.5. Logging Multiple Simultaneous Dialogs 👑
Multiple SIP dialogs can be logged at the same time by an originating UA, a terminating UA, and SIP entities on the signaling path. These dialogs are told apart by their test case identifier, which is the local UUID part of the Session-ID header field value at the originating device. Multitasking, but make it organized 💜.
3.6. Format of Logged Signaling ✨
The entire SIP message (SIP request line, response line, header fields, and message body) SHOULD be logged, because troubleshooting can be really hard if info is missing. Logging SHOULD use common standard formats, like the SIP Common Log Format (CLF) defined in [RFC6873] and Libpcap as defined in "vnd.tcpdump.pcap" in the Media Types registry [MEDIA-TYPES].
If SIP CLF is used, the entire message is logged using Vendor-ID = 00000000 and Tag = 02 in the <OptionalFields> portion of the SIP CLF record (see Section 4.4 of [RFC6873]). And for header fields, they SHOULD be logged in the form they appear in the message. They SHOULD NOT be converted between the long and compact forms described in Section 7.3.3 of [RFC3261]. Keep it exactly as it came in, babe 🎀🌸.
3.7. Marking Related Dialogs 💜
okay so "log me" marking is done per dialog 💅. It usually starts when the dialog is created and ends when the dialog ends ✨. BUT dialogs related to a "log me" marked dialog MAY also get "log me" marked for call control features like call forward, transfer, park, and join 🦋. As Section 6 of [RFC7989] explains, related dialogs can pop up when an endpoint gets a 3xx message, a REFER that points it at a different peer, an INVITE request with Replaces that might end up talking to a new peer, or an INVITE with a Join header field as described in [RFC3911]. The call transfer feature in Section 6.1 of [RFC5589] is a classic example 📞. You can correlate the logged signaling for related dialogs using Session-ID header field values, see Section 10.9 of [RFC7989] 🔗.
In Figure 2, Alice has been reporting problems making call transfers 😭. Her terminal goes into debug mode to get ready for "log me" marked signaling from the network admin, Bob 🧑💻. Bob's terminal is set to "log me" mark and log signaling for calls started during the troubleshooting session (e.g., for a duration of 15 minutes) ⏱️. Bob sets up a call that Alice can try to transfer. He calls Alice, which creates initial dialog1, and then Alice transfers the call to connect Bob to Carol 🎀. The logged signaling is correlated using the test case identifier, which is the local UUID ab30317f1a784dc48ff824d0d3715d86 in the Session-ID header field of INVITE request F1 🥰.
Logging by Alice's terminal starts when it receives and echoes the "log me" marker in INVITE F1, and ends when the last request or response in the dialog is sent or received (200 OK F7 of dialog1) 🛑. Also during dialog1, Alice's terminal logs related REFER dialog2, which it initiates and terminates as part of the call transfer. Alice's terminal inserts a "log me" marker in the REFER request and in 200 OK responses to NOTIFY requests in dialog2 🌸. Both dialog1 and dialog2 have the same test case identifier 👯.
Logging by Bob's terminal begins when it sends INVITE F1, which includes the "log me" marker, and ends when dialog3, initiated by Bob, ends 🍓. Logging by Carol's terminal begins when it receives INVITE F5 with the "log me" marker and ends when dialog3 ends 🧚.
Alice's terminal does not log dialog3 🙈. However, the test case identifier ab30317f1a784dc48ff824d0d3715d86 is also the test case identifier (local-uuid) in INVITE F5. Also, the test case identifier of dialog2, which Alice's terminal logs, can be linked to dialog1 and dialog3 because the remote-uuid component of dialog2 is ab30317f1a784dc48ff824d0d3715d86 🧩.
Alice Bob Carol
Transferor Transferee Transfer
| | Target
| INVITE F1 | |
dialog1 |<-------------------| |
| 200 OK F2 | |
dialog1 |------------------->| |
| ACK | |
dialog1 |<-------------------| |
| INVITE (hold) | |
dialog1 |------------------->| |
| 200 OK | |
dialog1 |<-------------------| |
| ACK | |
dialog1 |------------------->| |
| REFER F3 (Target-Dialog:1) |
dialog2 |------------------->| |
| 200 OK | |
dialog2 |<-------------------| |
| NOTIFY (100 Trying) F4 |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| | INVITE F5 |
dialog3 | |------------------->|
| | 200 OK |
dialog3 | |<-------------------|
| | ACK |
dialog3 | |------------------->|
| NOTIFY (200 OK) F6| |
dialog2 |<-------------------| |
| 200 OK | |
dialog2 |------------------->| |
| BYE | |
dialog1 |------------------->| |
| 200 OK F7 | |
dialog1 |<-------------------| |
| | BYE |
dialog3 | |<-------------------|
| | 200 OK |
dialog3 | |------------------->|Figure 2: "Log Me" Marking Related Dialogs in Call Transfer
F1: Bob's UA inserts the "logme" parameter in the Session-ID header field of the INVITE request that creates dialog1.
F3: Alice's UA inserts the "logme" parameter in the Session-ID header field of the REFER request that creates dialog2, which is related to dialog1.
F5: Bob's UA inserts the "logme" parameter in the Session-ID header field of the INVITE request that creates dialog3, which is related to dialog1.
Here are the messages in the call, so you can see the markers in action 👀.
F1 INVITE Transferee -> Transferor
INVITE sips:transferor@atlanta.example.com SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000;logme
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...F2 200 OK Transferor -> Transferee
SIP/2.0 200 OK
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
To: <sips:transferor@atlanta.example.com>;tag=31kdl4i3k
From: <sips:transferee@biloxi.example.com>;tag=7553452
Call-ID: 090459243588173445
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86;logme
CSeq: 29887 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Type: application/sdp
Content-Length: ...F3 REFER Transferor -> Transferee
REFER sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKna9
Max-Forwards: 70
To: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
From: <sips:transferor@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86;logme
CSeq: 314159 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: gruu, replaces, tdialog
Require: tdialog
Refer-To: <sips:transfertarget@chicago.example.com>
Target-Dialog: 090459243588173445;local-tag=7553452
;remote-tag=31kdl4i3k
Contact: <sips:4889445d8kjtk3@atlanta.example.com;gr=723jd2d>
Content-Length: 0F4 NOTIFY Transferee -> Transferor
NOTIFY sips:4889445d8kjtk3@atlanta.example.com
;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2;logme
CSeq: 73 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: active;expires=60
Content-Type: message/sipfrag
Content-Length: ...F5 INVITE Transferee -> Transfer Target
INVITE sips:transfertarget@chicago.example.com SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas41234
Max-Forwards: 70
To: <sips:transfertarget@chicago.example.com>
From: <sips:transferee@biloxi.example.com>;tag=j3kso3iqhq
Call-ID: 90422f3sd23m4g56832034
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000;logme
CSeq: 521 REFER
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, gruu, tdialog
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Content-Type: application/sdp
Content-Length: ...F6 NOTIFY Transferee -> Transferor
NOTIFY sips:4889445d8kjtk3@atlanta.example.com
;gr=723jd2d SIP/2.0
Via: SIP/2.0/TLS [2001:db8::1];branch=z9hG4bKnas432
Max-Forwards: 70
To: <sips:transferor@atlanta.example.com>;tag=1928301774
From: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
;tag=a6c85cf
Call-ID: a84b4c76e66710
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2;logme
CSeq: 74 NOTIFY
Contact: <sips:3ld812adkjw@biloxi.example.com;gr=3413kj2ha>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY
Supported: replaces, tdialog
Event: refer
Subscription-State: terminated;reason=noresource
Content-Type: message/sipfrag
Content-Length: ...3.8. Forked Requests 🍴
okay so a SIP intermediary is required to copy the "log me" marker into forked requests 💖. SIP request forking is discussed in Sections 4 and 16.6 of [RFC3261] 📖.
4. SIP Entity Behavior ✨
4.1. Scope of Marking ✨
okay so the whole vibe of "log me" marking is that it's supposed to be limited 🎀 like, limited in how long it runs and how many dialogs get marked, so you only mark the bare minimum you need to troubleshoot a problem or run a specific test 💅
- SIP entities MUST be configured to "log me" mark only dialogs needed for the current testing purpose, e.g., troubleshooting or regression testing. The mechanisms in this section make sure "log me" marking starts at dialog creation and, except for marking related dialogs or premature ending, stops when the marked dialog ends 🦋
- If a dialog is going to be marked, the ONLY way to start "log me" marking is at the dialog-creating request (e.g., SIP INVITE) sent by an originating endpoint, or by an intermediary that marks on behalf of the originating endpoint 💖 Marking that shows up mid-dialog is an error (see Section 5.1.2) 😭 The final terminating endpoint, or the intermediary that marks on behalf of the terminating endpoint, is NOT allowed to start marking 🙅♀️ but it does take the actions defined in Sections 4.2 and 4.3 if it gets an incoming "log me" marker 🫶
ngl the error cases in Section 5.1 make SIP entities stop "log me" marking, and the requirements in Section 7 also put rules on SIP entities, including letting them skip logging based on local policies (see Section 8.6) 💀
4.2. Endpoints 🌸
so the most common setup is that BOTH the originating and terminating endpoints support "log me" marking, with the originating endpoint being the one that starts it 👑 In this simplest case, the originating UA puts a "log me" marker in the dialog-creating SIP request AND in every later request in that dialog 🎀 The marker gets passed along through the SIP intermediaries and lands at the terminating UA, which echoes it back in the matching responses 🦋 If the terminating UA sends an in-dialog request on a dialog that's being marked, it adds a "log me" marker too, and the originating UA echoes it in responses 💅 The terminating UA logs the marked requests and responses if its network policy says it's allowed 🧚 Basically, this basic use case gives us these rules for originating and terminating UAs 💖
For originating UAs: 🚀
- The originating UA configured for "log me" marking MUST insert a "log me" marker into the dialog-creating SIP request and subsequent in-dialog SIP requests. 💜
- The originating UA itself logs marked requests and responses. 📝
- The originating UA echoes, in responses, the "log me" marker received in in-dialog requests from the terminating side. 🔁
- The originating UA logs the SIP responses that it sends in response to received "log me" marked in-dialog requests. 📋
- The originating UA MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7. ✨
For terminating UAs: 🌈
- The terminating UA detects that a dialog is of interest to logging by the existence of a "log me" marker in an incoming dialog-creating SIP request. 👀
- The terminating UA itself logs marked requests and corresponding marked responses if allowed as per policy. 📝
- The terminating UA MUST echo a "log me" marker in responses to a SIP request that included a "log me" marker. 🫶
- If the terminating UA has detected that a dialog is being "log me" marked, it MUST insert a "log me" marker in any in-dialog SIP requests that it sends. 💌
- The terminating UA itself logs any in-dialog SIP requests that it sends if allowed as per policy. 🗂️
- The terminating UA MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7. ⭐
4.3. SIP Intermediaries Acting on Behalf of Endpoints 🦋
okay so sometimes the network operator knows that some UAs on the network can't do "log me" marking at all 😭 So, subject to the authorizations in Section 7.1, a SIP intermediary close to the UA (like an edge proxy or B2BUA) on the originating side and/or the terminating side inserts the "log me" marker INSTEAD, so they can still test sessions involving those UAs 💅
The originating and terminating SIP intermediaries aren't identified by any protocol mechanism 🙈 they're picked and explicitly configured by the network admin to mark on behalf of endpoints 🎀 The intermediaries closest to the terminals can be set up to mark for terminals that don't support it 💖 The originating SIP intermediary is the first one a SIP request from the originating endpoint goes through 🚪 And the terminating SIP intermediary is the last one traversed before the terminating endpoint 🧚
So the originating-side intermediary is set up to insert the marker for the originating endpoint 💜 If the terminating UA doesn't echo the marker in responses to a marked request, then the SIP intermediary closest to the terminating UA (if it's configured to mark on its behalf) inserts a "log me" marker into the responses to that request 🔁 Same deal the other way: if the terminating UA sends an in-dialog request, the terminating-side intermediary inserts a "log me" marker, and the originating-side intermediary echoes it in responses to that request 🫶 Originating and terminating intermediaries that are configured for "log me" marking on behalf of the endpoint ALSO have to mark dialog-creating requests that contain Target-Dialog [RFC4538], Join [RFC3911], and Replaces [RFC3891] header fields, plus the matching responses 🌸 The originating and terminating intermediaries log the marked requests and responses if their network policies allow it 📋 So this scenario gives us these rules for when an intermediary is set up to start or handle marking on behalf of a UA 🌈
For the originating SIP intermediary: 🚀
- The originating SIP intermediary configured for "log me" marking MUST insert a "log me" marker into the dialog-creating SIP request and subsequent in-dialog SIP requests. 💖
- The originating SIP intermediary itself logs marked requests and responses. 📝
- The originating SIP intermediary detects the "log me" marker received in in-dialog requests and echoes the "log me" marker in the corresponding SIP responses. 🔁
- The originating SIP intermediary logs the SIP responses that it sends in response to "log me" marked in-dialog requests. 📋
- The originating SIP intermediary MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7. ✨
For the terminating SIP intermediary: 🌈
- The terminating SIP intermediary detects that a dialog is of interest to logging by the existence of a "log me" marker in an incoming dialog-creating SIP request. 👀
- The terminating SIP intermediary itself logs marked requests and corresponding responses if allowed as per policy. 📝
- The terminating SIP intermediary MUST echo a "log me" marker in responses to a SIP request that included a "log me" marker. 🫶
- If the terminating SIP intermediary has detected that a dialog is being "log me" marked, it MUST insert a "log me" marker in any in-dialog SIP requests from the terminating UA. 💌
- The terminating SIP intermediary itself logs any in-dialog SIP requests that it sends if allowed as per policy. 🗂️
- The terminating SIP intermediary MAY also apply these rules to any subsequent related SIP dialogs as described in Section 3.7. ⭐
4.4. B2BUAs 🎀
B2BUA "log me" behavior is specified based on its different signaling plane roles, which are described in [RFC7092] 💅
A Proxy-B2BUA SHOULD copy "log me" marking in requests and responses from its terminating side to the originating side, and it doesn't need explicit configuration to do that 🦋
A dialog on one "side" of the B2BUA may or may not be coupled to a related dialog on the other "side" for "log me" purposes 🙃 To allow end-to-end troubleshooting of user problems and regression testing, a signaling-only B2BUA and an SDP-modifying signaling-only B2BUA [RFC7092] SHOULD couple related dialogs for "log me" marking purposes, and pass on the received "log me" parameter from the originating side to the terminating side and vice versa 💖 For example, a SIP B2BUA handling an end-to-end session between an external caller and an agent in a contact center can couple the dialog between itself and the agent with the dialog between itself and the external caller 📞 It can pass the "log me" marking from the originating side to the terminating side, so you get end-to-end logging of specific sessions of interest 🧚
For dialogs that are being "log me" marked, ALL B2BUAs MUST "log me" mark in-dialog SIP requests that they generate on their own, without needing explicit configuration to do so 🔥 This rule applies to both the originating and terminating sides of a B2BUA 👑
4.5. "Log Me" Marker Processing by SIP Intermediaries 🌸
4.5.1. Stateless Processing 🧚
typically the "log me" marking is done by an originating UA and echoed by a terminating UA 💜 SIP intermediaries on the signaling path between these UAs that do NOT do the tasks described in Sections 4.3 or 4.4 MUST simply log any request or response containing a "log me" marker in a stateless manner, if local policy allows it ✨
4.5.2. Stateful Processing 💖
Okay bestie, so the originating and terminating SIP intermediaries that "log me" mark on behalf of endpoints, plus the ones that remove "log me" marking at the network edge, have to keep state so the marking actually works ✨ Here are the scenarios where that happens:
- The originating UA doesn't support "log me" marking. This was covered in Section 4.3, and the originating SIP intermediary has to step up 💅 Marker processing is shown in Section 4.5.2.1.
- The terminating UA doesn't support "log me" marking. Also covered in Section 4.3, and now the terminating SIP intermediary has to handle it 🫶 Marker processing is shown in Section 4.5.2.2.
- The originating network doesn't let marking escape its boundaries, so external networks aren't affected 🦋 It removes "log me" marking from SIP requests and responses before they leave its network boundary for external networks, but it adds marking back to any incoming SIP requests and responses that belong to a "log me" marked dialog. This needs support from the SIP intermediary at the originating network boundary. Marker processing is shown in Section 4.5.2.3.
- The terminating network makes sure "log me" marking from external networks can't get through its boundary to its internal entities 🌸 It removes "log me" marking from SIP requests and responses before forwarding them internally, but it adds marking back to any outgoing SIP requests and responses that belong to a "log me" marked dialog. This needs support from the SIP intermediary at the terminating network boundary. Marker processing is shown in Section 4.5.2.4.
- The terminating network doesn't support "log me" marking and doesn't echo any marking it receives 🙈 The originating network adds marking back to incoming SIP requests and responses that belong to the "log me" marked dialog. This needs support from the SIP intermediary at the originating network boundary, and marker processing is shown in Section 4.5.2.5.
SIP intermediary behavior in all of these scenarios is illustrated using the [RFC3665] example call flow "Session Establishment Through Two Proxies" 🧚
4.5.2.1. "Log Me" Marking Not Supported by Originating UA
Alice's UA doesn't support "log me" marking, so Proxy 1 (the SIP intermediary closest to Alice) is configured to act on her behalf and "log me" mark the specific dialogs of interest that Alice creates for troubleshooting purposes 🔍
In Figure 3, Proxy 1 in the originating network keeps track of which dialogs are being logged so it can "log me" mark all the SIP requests and responses it gets from Alice's UA before forwarding them to Proxy 2. It's giving main character energy 👑
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (no logme) | | |
|--------------->| | |
| | INVITE F2 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | INVITE F4 |
| (logme) | | (logme) |
|<---------------| 100 F5 |--------------->|
| | (logme) | |
| |<---------------| |
| | | 180 F6 |
| | | (logme) |
| | 180 F7 |<---------------|
| | (logme) | |
| 180 F8 |<---------------| |
| (logme) | | |
|<---------------| | 200 F9 |
| | | (logme) |
| | 200 F10 |<---------------|
| | (logme) | |
| 200 F11 |<---------------| |
| (logme) | | |
|<---------------| | |
| ACK F12 | | |
| (no logme) | | |
|--------------->| | |
| | | |
| | ACK F13 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | ACK F14 |
| | | (logme) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (logme) |
| | BYE F16 |<---------------|
| | (logme) | |
| BYE F17 |<---------------| |
| (logme) | | |
|<---------------| | |
| 200 F18 | | |
| (no logme) | | |
|--------------->| | |
| | 200 F19 | |
| | (logme) | |
| |--------------->| |
| | | |
| | | 200 F20 |
| | | (logme) |
| | |--------------->|
| | | |Figure 3: The Originating UA Does Not Support "Log Me" Marking
- F1: Alice's UA doesn't put a "log me" marker in the dialog-creating INVITE request F1. That's fine, because Proxy 1 is set up to start logging on Alice's behalf anyway 🎀 Proxy 1 logs INVITE request F1 and keeps track of the fact that this dialog is being logged.
- F2: Proxy 1 inserts a "log me" marker into INVITE request F2 before sending it on to Proxy 2, and it logs this request too 📝
- F3: Proxy 1 inserts a "log me" marker into 100 response F3 before forwarding it to Alice's UA, since it's a response on a dialog that's being "log me" marked. Proxy 1 logs this response as well 💜
- F4: Bob's UA detects the "log me" marker and logs INVITE request F4 if its policy allows it 👀
- F6: Bob's UA echoes the "log me" marker from INVITE request F4 into 180 response F6. It logs this response if its policy allows it 🦋
- F7 and F8: Proxy 1 logs the 180 response F7 it receives, then passes the "log me" marker along to Alice's UA in F8 🌈
- F12: Proxy 1 gets an ACK with no "log me" marker. That's not treated as an error, because it's set up to "log me" mark on behalf of Alice's UA 🫶
- F13: Proxy 1 inserts a "log me" marker into ACK request F13 before forwarding it to Proxy 2, and it logs this request ✨
- F15: Bob's UA inserts a "log me" marker into the in-dialog BYE request, and that marker gets carried back to Alice's UA in F16 and F17. Bob's UA logs this request if its policy allows it 💅
- F18: Alice's UA doesn't echo the "log me" marker from BYE request F17 into 200 response F18 🙃
- F19: Proxy 1 inserts a "log me" marker into 200 response F19 before forwarding it to Proxy 2, and it logs this response 🍓
4.5.2.2. "Log Me" Marking Not Supported by Terminating UA ✨
okay so here's the vibe: in Figure 4, Bob's UA can't do "log me" marking at all 🙈 so Proxy 2 in the terminating network has to hold onto state and make sure "log me" marking happens on the SIP requests and responses coming from Bob's UA. it's giving backup dancer energy 💅
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | | |
| | | |
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (log me) |
| | |--------------->|
| | | |
Figure 4: The Terminating UA Does Not Support "Log Me" Marking.- F1: Alice's UA slaps a "log me" marker on the dialog-creating INVITE request F1 💖
- F2: INVITE F2 is "log me" marked, so Proxy 2 keeps state saying this dialog is to be logged 🧚 Proxy 2 logs the request and responses of this dialog if allowed per policy.
- F5: Proxy 2 adds a "log me" marker to the 100 response it sends to Proxy 1 🎀
- F6: Bob's UA doesn't support "log me" marking, so the 180 response to the INVITE request has no "log me" marker. not her fault, honestly 🥺
- F7: Proxy 2 inserts a "log me" marker in the 180 response on behalf of Bob's UA before forwarding it. the same goes for response F10 and the BYE request in F16 🦋
4.5.2.3. "Log Me" Marking Removed by Originating Network
this one is giving privacy-first protagonist 👑 If network A in Figure 5 is doing testing on its own, separate from network B, then network A removes "log me" marking from SIP requests and responses forwarded to network B, so it doesn't accidentally trigger logging in network B 🫶 Proxy 1 removes "log me" marking from requests and responses it forwards to Proxy 2, and keeps track of which dialogs are "log me" marked so it can put the marking back on requests and responses it forwards from Proxy 2 to Alice's UA. full circle 🔥 For troubleshooting purposes, Proxy 1 MAY also log the requests and responses sent to or received from Proxy 2, even though it removed the "log me" marker before forwarding the messages to Proxy 2 📝
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (logme) | | |
|--------------->| | |
| | INVITE F2 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (logme) | | INVITE F4 |
| | | (no logme) |
|<---------------| 100 F5 |--------------->|
| | (no logme) | |
| |<---------------| |
| | | 180 F6 |
| | | (no logme) |
| | 180 F7 |<---------------|
| | (no logme) | |
| 180 F8 |<---------------| |
| (logme) | | |
|<---------------| | 200 F9 |
| | | (no logme) |
| | 200 F10 |<---------------|
| | (no logme) | |
| 200 F11 |<---------------| |
| (logme) | | |
|<---------------| | |
| ACK F12 | | |
| (logme) | | |
|--------------->| | |
| | | |
| | ACK F13 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | ACK F14 |
| | | (no logme) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no logme) |
| | BYE F16 |<---------------|
| | (no logme) | |
| BYE F17 |<---------------| |
| (logme) | | |
|<---------------| | |
| 200 F18 | | |
| (logme) | | |
|--------------->| | |
| | 200 F19 | |
| | (no logme) | |
| |--------------->| |
| | | |
| | | 200 F20 |
| | | (no logme) |
| | |--------------->|
| | | |
Figure 5: The Originating Network Removes "Log Me" Marking from
Outgoing SIP Messages at its Network Edge.- F1: Alice's UA inserts a "log me" marker in the dialog-creating INVITE request, so Proxy 1 keeps state that this dialog is to be logged 🌸
- F2: Proxy 1 strips the "log me" marking off the INVITE request before forwarding it to Proxy 2. Proxy 1 logs INVITE request F2 📓
- F3: Proxy 1 inserts a "log me" marker in the 100 response it sends to Alice's UA. Proxy 1 logs this response ✨
- F8: Proxy 1 inserts a "log me" marker in the 180 response before forwarding it to Alice's UA. Proxy 1 logs this response. the same goes for responses F11 and F17 💅
- F13: Proxy 1 removes "log me" marking from the ACK request. Proxy 1 logs this request before forwarding it to Proxy 2 🫶
- F19: Proxy 1 removes "log me" marking from the 200 response to the BYE request. Proxy 1 logs this response before forwarding it to Proxy 2 🍓
4.5.2.4. "Log Me" Marking Removed by Supporting Terminating Network 💅
okay so in Figure 6, Proxy 2 strips the "log me" marking off every SIP request and response entering network B 🫣. BUT, plot twist, Proxy 2 totally supports keeping track of the dialog's marking state, so it still marks the "log me" stuff it sends toward Proxy 1 ✨. For troubleshooting, Proxy 2 MAY also log the requests and responses it gets from or sends to Bob, even though it already removed the "log me" marker before forwarding things to Bob 🔍. This is minimal logging energy 🦋: it only happens at the network boundaries, which makes it useful for troubleshooting a signaling path between two enterprise or carrier networks, or across a transit network 🌸.
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (no log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (no log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (no log me) |
| | |--------------->|
| | | |
Figure 6: The terminating network removes "log me" marking from
incoming SIP messages at its network edge.- F1: Alice's UA slaps a "log me" marker on the dialog-creating INVITE request F1 💌. Proxy 1 spots the marker, logs the request, and remembers that this dialog is supposed to be logged 📝.
- F2: Proxy 2 removes the "log me" marker from INVITE request F2 before it goes out as F4 🧹. Same vibe for responses F13 and F19.
- F6: Proxy 2 inserts a "log me" marker into the 180 response to the INVITE, logs the request, and then forwards it as F7 🎀. Same deal for response F9 and the BYE request in F15.
4.5.2.5. "Log Me" Marking Passed by Non-supporting Terminating Network 🫠
so in Figure 6, Proxy 2 isn't "log me" aware 🙈. That means it just passes the marking along in every SIP request and response entering network B, following the rules in Sections 16.6 and 16.7 of [RFC3261]. Proxy 2 doesn't log anything in the dialog. Proxy 1, on the other hand, does support keeping the marking state of the dialog 🧠. So when Proxy 1 notices that requests and responses coming from Proxy 2 aren't marked, it adds the marking itself 🩵.
For troubleshooting, Proxy 1 MAY also log the requests and responses it gets from or sends to Proxy 2, even though Proxy 2 didn't add "log me" to the messages it sent to Proxy 1 📚.
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (no log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (no log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (no log me) |
| | 200 F10 |<---------------|
| | (no log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (log me) | |
| |--------------->| ACK F14 |
| | | (log me) |
| | |--------------->|
| Both Way RTP Media |
|<================================================>|
| | | BYE F15 |
| | | (no log me) |
| | BYE F16 |<---------------|
| | (no log me) | |
| BYE F17 |<---------------| |
| (log me) | | |
|<---------------| | |
| 200 F18 | | |
| (log me) | | |
|--------------->| | |
| | 200 F19 | |
| | (log me) | |
| |--------------->| 200 F20 |
| | | (log me) |
| | |--------------->|
| | | |Figure 7: The Terminating Network Removes "Log Me" Marking from Incoming SIP Messages at its Network Edge.
- F1: Alice's UA slaps a "log me" marker on the dialog-creating INVITE request F1 💌. Proxy 1 spots the marker, logs the request, and remembers that this dialog is supposed to be logged 📝.
- F2: Proxy 2 passes the "log me" marker through on INVITE request F2 before it goes out as F4 🚀. Same for request F13 and response F19.
- F6: Bob's UA doesn't support "log me" marking, so it doesn't echo the marker back in response F6 😬. Same story for response F9 and the BYE request F15.
- F7: Proxy 1 inserts a "log me" marker into the 180 response to the INVITE before forwarding it as F8 🩷. Same for response F10 and the BYE request F16.
5. Errors 🚨
5.1. Error Cases
okay bestie, let's talk about what can go wrong 😭. These are the error cases that are possible for "log me" marking:
- A "log me" marker is unexpectedly missing from a dialog that is being logged. 🫥
- A "log me" marker unexpectedly appears in a dialog that is not being logged. 👀
- A "log me" marker unexpectedly disappears and then reappears in a dialog being logged. This is treated in the same way as case 1. 🔄
- A "log me" marker is unexpectedly missing from a retransmission in a dialog being logged. This is treated in the same way as case 1. 📦
These cases apply to any request or response sent by any entity and in any direction in a dialog being "log me" marked 💜. Detection of these error cases is described in this section ✨.
5.1.1. Missing "Log Me" Marker Error Case ✨
okay so "log me" marking is per-dialog, which means if a dialog is being marked and the marker just... goes missing from a request or response, that's an error 💅
BUT spotting it isn't as simple as checking for missing markers 🙈 because some terminals just don't do marking at all, so a missing marker is totally normal for them. no cap, it's a vibe check.
You have to evaluate each neighbor separately. It's an error when a particular neighbor has already sent "log me" in the dialog and then stops, and that's true no matter what the other neighbors are doing 🫶
UAs and intermediaries that are stateless about "log me" marking can't detect these errors, bestie. Only the ones that are stateful, the ones that track marking, can notice that a marker is missing from a dialog that was already "log me" marked 😭 The error cases are in this section, and the non-error cases are in Section 5.2.1 💖
Here are the figures for missing "log me" marker errors 🦋
Figure 8 shows an error caught at Proxy 1, where an expected "log me" marker is missing.
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | INVITE F2 | |
|--------------->| (log me) | INVITE F3 |
| |--------------->| (log me) |
| | |--------------->|
| | | |
| | | 200 F4 |
| | 200 F5 | (log me) |
| 200 F6 | (log me) |<---------------|
| (log me) |<---------------| |
|<---------------| | |
| | | |
| ACK F7 | | |
| (no log me) | | |
|--------------->| | |
| | ACK F8 | |
| | (no log me) | |
| |--------------->| |
| | | ACK F9 |
| | | (no log me) |
| | |--------------->|
Figure 8: Error Case: Missing "Log Me" MarkerF1: Proxy 1 spots the "log me" marker and keeps track that this dialog is to be logged 🎀
F7: Proxy 1 notices the expected "log me" marker is missing, calls it an error, and stops "log me" marking in later requests and responses in this dialog 🙅♀️
Figure 9 shows an error caught at both Proxy 2 and Bob's UA 👑
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| | | |
| | | |
| 180 F8 | | |
| (log me) | | |
|<---------------| | 200 F9 |
| | | (log me) |
| | 200 F10 |<---------------|
| | (log me) | |
| 200 F11 |<---------------| |
| (log me) | | |
|<---------------| | |
| ACK F12 | | |
| (no log me) | | |
|--------------->| | |
| | ACK F13 | |
| | (no log me) | |
| |--------------->| ACK F14 |
| | | (no log me) |
| | |--------------->|
Figure 9: Error Case: Missing "Log Me" MarkerF2: Proxy 2 spots the "log me" marker and keeps track that this dialog is to be logged 🌸
F4: Bob's UA spots the "log me" marker and keeps track that this dialog is to be logged 🧚
F12: Proxy 1 notices the expected "log me" marker is missing, calls it an error, and stops "log me" marking in later requests and responses in this dialog. So it doesn't add a "log me" marker in F13 🙈
F13: Proxy 2 notices the expected "log me" marker is missing, calls it an error, and stops "log me" marking in later requests and responses in this dialog 💀
F14: Proxy 2 doesn't add a "log me" marker because it already stopped "log me" marking after the error it saw in F13. Bob's UA notices the expected "log me" marker is missing, calls it an error, and stops "log me" marking in later requests and responses in this dialog 🫶
5.1.2. "Log Me" Marker Appears Mid-dialog Error Case 🦋
SIP endpoints, intermediaries acting on behalf of endpoints, and B2BUAs that can do "log me" marking are stateful 💜 They only expect a "log me" marker in dialogs where the very first dialog-creating request was "log me" marked, either by themselves or by something upstream. So if "log me" marking starts partway through a dialog, that's an error 😭
Figure 10 shows a "log me" marking error that shows up in the middle of a dialog 🎀 Alice's UA supports "log me" marking, but the call isn't marked for logging at the start, so INVITE F1 has no "log me" marker. Then Alice's UA starts "log me" marking at the ACK request F7 😳 Proxy 1 supports "log me" marking at the originating network boundary, so it catches the error, doesn't log the signaling, and removes the "log me" marker before forwarding the ACK request F8 ✨
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (no log me) | INVITE F2 | |
|--------------->| (no log me) | INVITE F3 |
| |--------------->| (no log me) |
| | |--------------->|
| | | |
| | | 200 F4 |
| | 200 F5 | (no log me) |
| 200 F6 | (no log me) |<---------------|
| (no log me) |<---------------| |
|<---------------| | |
| | | |
| ACK F7 | | |
| (log me) | | |
|--------------->| | |
| | ACK F8 | |
| | (no log me) | |
| |--------------->| |
| | | ACK F9 |
| | | (log me) |
| | |--------------->|
Figure 10: Error Case: "Log Me" Marker Begins Mid-dialog5.2. Non-error Cases ✨
5.2.1. Missing "Log Me" Marker Non-error Case ✨
okay so here's a case that looks like an error but actually isn't 🫶 Figure 11 shows it. Proxy 2 is set up by network B to do "log me" marking for Bob's UA, which doesn't support "log me" marking itself. So Proxy 2 isn't expecting Bob's responses to carry a "log me" marker. Totally fine, no drama 💅
[ NETWORK A ] [ NETWORK B ]
Alice Proxy 1 Proxy 2 Bob
| | | |
| INVITE F1 | | |
| (log me) | | |
|--------------->| | |
| | INVITE F2 | |
| | (log me) | |
| |--------------->| |
| | | |
| | | |
| 100 F3 | | |
| (log me) | | |
|<---------------| | |
| | | INVITE F4 |
| | | (log me) |
| | 100 F5 |--------------->|
| | (log me) | |
| |<---------------| |
| | | 180 F6 |
| | | (no log me) |
| | |<---------------|
| | 180 F7 | |
| | (log me) | |
| |<---------------| |
| 180 F8 | | |
| (log me) | | |
|<---------------| | |Figure 11: Non-error Case: Missing "Log Me" Marker
- F2: Proxy 2 spots the "log me" marker and keeps track of the fact that this dialog needs logging 🔍 It then adds "log me" markers on behalf of Bob's user agent, like in F7.
- F6: Proxy 2 notices the "log me" marker is missing from the response, but it's still treating "log me" marking as ongoing, because a marker wasn't expected here anyway 🦋
- F7: Proxy 2 keeps "log me" marking the requests and responses on behalf of Bob's UA 💜
5.2.2. "Log Me" Marker Appears Mid-dialog Non-error Case 🌸
okay so a SIP intermediary that can do "log me" marking for an endpoint MAY optionally mark a request or response headed toward a non-supporting endpoint. Think of the 100 response F3 in Figure 3 as the example 💖 The endpoint ends up getting a "log me" marker mid-dialog, but that's not treated as an error. Not a bug, just the network being helpful ✨
Another vibe is a network where only some endpoints support "log me" marking, and the network wants to stop treating endpoints differently. So it handles "log me" marking at the SIP intermediary instead 🧚 In that setup, the endpoint that supports "log me" is NOT set up to mark a dialog. The SIP intermediary is the one configured to do the marking for it. This still needs the authorization covered in Section 7.1, no skipping that 🔒 This SIP intermediary MAY optionally mark a request or response towards the endpoint, like the 100 response F3 in Figure 3. The endpoint gets a "log me" marker mid-dialog, and yep, that's not an error either 🎀
5.2.3. Combining Dialogs Non-error Case 🍓
when you're troubleshooting call flows that involve the SIP Join header field from [RFC3911], the dream scenario is "log me" marking turned on for every UA and intermediary in the end-to-end session 👑 Realistically that's not always doable, so these rules kick in:
- If an endpoint or an intermediary that is "log me" aware and is already "log me" marking a dialog gets a SIP INVITE with a Join header field and without a "log me" marker, it MUST NOT "log me" mark responses and requests exchanged within the new dialog established as a result of processing the SIP INVITE.
- If an endpoint or an intermediary that is "log me" aware and is not "log me" marking a dialog gets a SIP INVITE with a Join header field and with a "log me" marker, it MUST "log me" mark responses and requests exchanged within the new dialog established as a result of processing the SIP INVITE as per Section 4 of this document.
5.3. Error Handling 💅
okay so there are two error types that SIP entities have to handle, and they're defined in Section 5.1: a missing marker error, and a "log me" marking that starts mid-dialog error 😭 Section 5.2 is where the exceptions live, the marking-that-starts-mid-dialog or missing-marker situations that are not errors.
If a UA, SIP intermediary, or B2BUA detects a missing marker error, it SHOULD treat it as an error condition in the "log me" functionality 🚨 It MUST NOT mark subsequent requests and responses, and it MUST stop logging messages in the same dialog. Any messages that were already logged SHOULD be retained, for the time period defined in Section 8.5, and not deleted 🗂️
If a UA, SIP intermediary, or B2BUA detects a "log me" marking that begins mid-dialog error, it SHOULD treat it as an error condition in the "log me" functionality 💀 It MUST NOT forward the "log me" marker, and it MUST NOT log the message. It MUST NOT mark subsequent requests and responses, and it MUST NOT log subsequent messages in the same dialog.
Only supporting UAs or B2BUAs can detect and handle "log me" marking errors 🙈 A SIP proxy as defined in [RFC3261] can't detect or handle marking errors, so it just forwards any "log me" marker it gets. No judgment, just forwarding ✨
6. Augmented BNF for the "logme" Parameter 🧚
ABNF is described in [RFC5234]. This document adds a brand-new "logme" parameter for the Session-ID header field, which is defined in Section 5 of [RFC7989] 💜
sess-id-param =/ logme-param
logme-param = "logme"Figure 12: Augmented BNF for the "logme" Parameter
7. Security Considerations 🔒
okay, security time, and it's SERIOUS 😤 Every bit of this section matters.
7.1. "Log Me" Authorization 👑
"Log me" marking MUST be disabled by default both at the endpoints and intermediaries, and it MUST be enabled only by authorized users. For example, an end user or network administrator has to give permission for a terminal that supports "log me" marking before it can start marking. Likewise, a network administrator MUST enable a configuration at the SIP intermediary so it can do "log me" marking on behalf of a terminal that doesn't support it. The permission MUST be limited to only specific calls of interest that are originated in a given time duration ⏳
Turning on a debug mode changes how a terminal operates, so the debugging configuration MUST be supplied by an authorized party to an authorized terminal through a secure communication channel 🔐
7.2. "Log Me" Marker Removal 🧹
The "log me" marker isn't sensitive information 🌈 It just sometimes gets inserted because a particular device is having problems.
Having a "log me" marker can make some SIP entities log signaling messages. So if the marker was inserted by mistake, this marker MUST be removed at the earliest opportunity. Examples of a mistake are it showing up mid-dialog in a dialog that wasn't being logged, or showing up outside the configured start and stop of logging 🙅♀️
If SIP requests and responses get exchanged with an external network that has no agreement to pass "log me" marking, then the "log me" marking is removed as mandated in Section 3.4.2. This behaviour applies to incoming and outgoing requests and responses 🦋
7.3. Denial-of-Service Attacks 💀
Maliciously configuring a large number of terminals to simultaneously mark dialogs with a "log me" marker will cause high processor load on SIP entities that are logging signaling 😱 "Log me" marking is meant for the small number of dialogs under troubleshooting or regression testing, so the number of dialogs that can be logged at the same time can be statically limited without hurting how useful "log me" marking is. Also, the SIP intermediary closest to the terminal and the SIP intermediary at the network edge (for example, Session Border Controllers) can be configured to screen out "log me" markers when troubleshooting or regression testing isn't in progress 🛡️
7.4. Data Protection 🫶
A SIP entity that has logged information MUST protect the logs. Storage of the log files is subject to the security considerations specified in [RFC6872] 🔐
8. Privacy Considerations 🌸
Logging includes all SIP header fields 👀 The SIP privacy mechanisms defined in [RFC3323] can be used to make sure logs don't reveal personal identity information in the core SIP header fields specified in [RFC3261].
Privacy mechanisms might also need to be applied to header fields defined by SIP extensions, and to managing the confidentiality of the Request-URI and SIP header fields and bodies 🎀
8.1. Personal Identifiers 🧚
"Log me" marking is defined for the SIP protocol, and SIP has header fields such as From, Contact, and P-Asserted-Identity that can carry personal identifiers 🪪 Different protocol interactions can be correlated using the Session-ID and Call-ID header fields, but that correlation is limited to a single end-to-end session.
To protect user privacy during logging, privacy settings can be enabled or requested by the terminal the end user is using 💖 [RFC3323] suggests two mechanisms:
- By using the value "anonymous" in the From header field
- By requesting header-level and session-level privacy from SIP intermediaries using the Privacy header
Endpoints that support Globally Routable User Agent URIs (GRUUs) can use a temporary GRUU (see Section 3.1.2 of [RFC5627]) assigned by the Registrar to protect user privacy, as discussed in Section 10.3 of [RFC5627] ✨
Intermediaries that perform "log me" marking on behalf of the endpoints (see Section 4.3) may also be configured to apply privacy (as defined in Section 3.3 of [RFC3323]) to messages that belong to a dialog that is "log me" marked 🦋
Complete anonymization (for example, of the Request-URI and the "username" field in the "o=" parameter of an SDP body) may not be possible in every circumstance. So administrators of the originating and terminating networks should consider how privacy will be ensured when they give consent for "log me" marking 🤔
"Log me" marking is typically used for troubleshooting and regression testing. In some cases, a service-provider-owned device with a dummy account can be used instead of a customer device 🍓 In those cases, no personal identifiers are included in the logged signaling messages 💜
8.2. Data Stored at SIP Intermediaries 📦
okay bestie, storage time 🫶 SIP endpoints and intermediaries that honor the "log me" request store every SIP message exchanged within a given dialog. Those messages can carry the personal identifiers from Section 8.1, plus a user identity, calling party number, IP address, hostname, and other user or device details. The message bodies describe the kind of session the identified end user and device are setting up 🧚
"Log me" marking doesn't add any extra user or device data to SIP, but it might signal that a specific user is having a problem 🙈
If the SIP SDP parameters [SDP-PARAMETERS] contain sensitive security info, like encryption keys in "crypto" [RFC4568], 3GPP-Integrity-Key, or 3GPP-SRTP-Config [RFC6064] attributes, the attribute value MUST be masked with a dummy value before the message gets stored in a log file 🔐 You can swap the value for a string of special characters like "X", "*", and "#", as in this example:
a=crypto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXX8.3. Data Visible at Network Elements 👀
SIP messages logged because of "log me" requests only get stored by the SIP initiators, intermediaries, and recipients. Enablers defined in Section 3.1 of [RFC6973], like firewalls and DNS servers, don't log messages because of the "log me" marking 💅
8.4. Preventing Fingerprinting 🕵️♀️
"Log me" is usually used to troubleshoot a particular problem, which means it can also be used to identify users and devices that are having issues. Scary, right? 😭 The best way to stop people from fingerprinting users is to enable or request SIP privacy for the logged dialog 🔒
8.5. Retaining Logs 🗓️
The "log me" marking lasts exactly as long as the dialog that started it. When "log me" gets extended to related dialogs, it lasts until there's no related dialog left for the end-to-end session 🦋
"Log me" automatically expires at the end of the dialog, and there's no explicit mechanism to turn logging off within a dialog. No take-backs mid-call 💀
The scope of "log me" marking is limited: a user or network administrator has to turn it on per session or for a specific time period. That keeps user data from getting exposed forever 🌸
The retention period for logged messages SHOULD be the minimum needed for each troubleshooting or testing case. The retention period gets configured based on the data-retention policies of service providers and enterprises 📚
8.6. User Control of Logging 🎛️
Consent to turn on "log me" marking for a given session MUST be given by the end user or by the network administrator. This happens outside the protocol, through user interfaces or application programming interfaces at the endpoint, call control elements, and network management systems 🙋♀️
Originating and terminating endpoints that are "log me" aware and have a user interface MUST tell the user, using text, an icon, or something similar, that a session is being logged ✨
SIP entities across the communication path MAY be configured to pass through the "log me" marking without honoring the request, meaning they don't log the data based on local policies 🌈
8.7. Recommended Defaults 💖
The recommended defaults for "log me" marking are:
- Turn on SIP privacy as described in Section 8, or use a device that is owned by the service provider with a dummy user identity for test calls 🎀
- Use the local UUID portion of the Session-ID header field value at the originating device as the test case identifier, as described in Section 3.3 🍓
9. IANA Considerations 📋
9.1. Registration of the "logme" Parameter 💜
The "logme" parameter has been added to the "Header Field Parameters and Parameter Values" section of the "Session Initiation Protocol (SIP) Parameters" registry. Here's the registry entry, in Table 1 ✨
+-------------+---------------+-------------------------+-----------+
| Header | Parameter | Predefined Values | Reference |
| Field | Name | | |
+-------------+---------------+-------------------------+-----------+
| Session-ID | logme | No (no values are | [RFC8497] |
| | | allowed) | |
+-------------+---------------+-------------------------+-----------+
Table 110. References 📚
10.1. Normative References 🔗
- [MEDIA-TYPES] IANA, "Media Types",
<https://www.iana.org/assignments/media-types/>. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. - [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. - [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002,
<https://www.rfc-editor.org/info/rfc3323>. - [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004,
<https://www.rfc-editor.org/info/rfc3891>. - [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) "Join" Header", RFC 3911, DOI 10.17487/RFC3911, October 2004,
<https://www.rfc-editor.org/info/rfc3911>. - [RFC4538] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, DOI 10.17487/RFC4538, June 2006,
<https://www.rfc-editor.org/info/rfc4538>. - [RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006,
<https://www.rfc-editor.org/info/rfc4568>. - [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009,
<https://www.rfc-editor.org/info/rfc5627>. - [RFC6064] Westerlund, M. and P. Frojdh, "SDP and RTSP Extensions Defined for 3GPP Packet-Switched Streaming Service and Multimedia Broadcast/Multicast Service", RFC 6064, DOI 10.17487/RFC6064, January 2011,
<https://www.rfc-editor.org/info/rfc6064>. - [RFC6872] Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur, H., and O. Festor, "The Common Log Format (CLF) for the Session Initiation Protocol (SIP): Framework and Information Model", RFC 6872, DOI 10.17487/RFC6872, February 2013,
<https://www.rfc-editor.org/info/rfc6872>. - [RFC6873] Salgueiro, G., Gurbani, V., and A. Roach, "Format for the Session Initiation Protocol (SIP) Common Log Format (CLF)", RFC 6873, DOI 10.17487/RFC6873, February 2013,
<https://www.rfc-editor.org/info/rfc6873>. - [RFC7989] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End-to-End Session Identification in IP-Based Multimedia Communication Networks", RFC 7989, DOI 10.17487/RFC7989, October 2016,
<https://www.rfc-editor.org/info/rfc7989>. - [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>. - [SDP-PARAMETERS] IANA, "Session Description Protocol (SDP) Parameters",
<https://www.iana.org/assignments/sdp-parameters/>.
10.2. Informative References 🧠
- [RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, DOI 10.17487/RFC3665, December 2003,
<https://www.rfc-editor.org/info/rfc3665>. - [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. - [RFC5589] Sparks, R., Johnston, A., Ed., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009,
<https://www.rfc-editor.org/info/rfc5589>. - [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. - [RFC7092] Kaplan, H. and V. Pascual, "A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents", RFC 7092, DOI 10.17487/RFC7092, December 2013,
<https://www.rfc-editor.org/info/rfc7092>. - [RFC7206] Jones, P., Salgueiro, G., Polk, J., Liess, L., and H. Kaplan, "Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014,
<https://www.rfc-editor.org/info/rfc7206>. - [RFC8123] Dawes, P. and C. Arunachalam, "Requirements for Marking SIP Messages to be Logged", RFC 8123, DOI 10.17487/RFC8123, March 2017,
<https://www.rfc-editor.org/info/rfc8123>.
Acknowledgments 🫶
The authors want to thank Paul Giralt, Paul Kyzivat, Jorgen Axell, Christer Holmberg, Vijay Gurbani, Ben Campbell, Gonzalo Salgueiro, Francesca Palombini, Adam Roach, Mirja Kuhlewind, Benjamin Kaduk, Eric Rescorla, Alissa Cooper, Warren Kumari, and Alexey Melnikov for their constructive review comments and guidance while they were developing this document 👑
Authors' Addresses 💌
Peter Dawes
Vodafone Group
The Connection
Newbury, Berkshire RG14 2FN
United Kingdom
Phone: +44 7717 275009
Email: peter.dawes@vodafone.com
Chidambaram Arunachalam
Cisco Systems
7200-12 Kit Creek Road
Research Triangle Park, NC 27709
United States of America
Email: carunach@cisco.com📦 where this page comes from
- ietf: rfc8497 2018-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms