3.12.1 Abstract Data Model

This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.

If an ms-correlation-id header field is present, it MUST contain a UUID, as defined in [RFC4122] Section 3. If the same value of the ms-correlation-id header field is included in messages for multiple SIP dialogs, those dialogs are considered to be correlated. No specific semantics are defined for which dialogs can be considered correlated; the correlation identifier is intended solely as a hint which log analysis and diagnostic tools can use to infer a relationship between two otherwise-unrelated dialogs.

For example, consider Client B that acts as a back-to-back user agent. This client receives an INVITE from Client A, and sends another INVITE to the final recipient of the message, Client C. Client B generates a new random correlation identifier, and includes the ID in the INVITE to Client C and the response to Client A. Once Client C responds, two otherwise-unrelated dialogs, D1 and D2, have been established. Server processing for both dialogs is unaffected by the additional header, but a server captures and stores the correlation identifier in a log. A log analysis or diagnostic tool later run on the log uses the correlation identifier to identify that dialogs D1 and D2 are related, and hence that Client A and Client C were in communication via the intermediary back-to-back user agent.

If the header is absent, or the value of the header is not used by any other dialog, the dialog is not correlated.