End-to-End Session Identification in IP-Based Multimedia Communication Networks
obsoletes
- rfc-7329 — A Session Identifier for the Session Initiation Protocol (SIP)
Extracted elements (30)
A specific version 5 UUID namespace (a58587da-c93d-11e2-ae90-f4ea67801e29) is defined so that stateless intermediaries can deterministically reproduce the same UUID for an endpoint given the Call-ID and tag, enabling consistent session identification without requiring state storage.
Backwards compatibility with RFC 7329 is achieved by inspecting the presence and order of the 'remote-uuid' parameter rather than using option tags or feature tags, because neither the old nor new specification has versioning information embedded and adding it retroactively would break deployed implementations.
The session identifier is deliberately constructed to not reveal user, device, domain, or other sensitive information, removing the incentive for session border controllers to alter it. This ensures end-to-end integrity of the identifier through intermediaries that would otherwise rewrite Call-IDs.
The session identifier is designed as a set of two UUIDs (one per endpoint) rather than a single value to handle forking and conferencing: in a fork, each answering UA contributes a distinct UUID yielding {A,B1}, {A,B2}, etc.; in a conference, the focus reuses its UUID across all participants to enable session correlation.
Backwards compatibility with RFC 7329 ('old' version) is determined by the presence or absence of the 'remote-uuid' parameter: a request with a 'remote-uuid' comes from a standard (new) implementation; one without it comes from a pre-standard (old) implementation and MUST be handled by preserving UUID order throughout the dialog.
If a SIP response contains the same UUID values in the same order as was sent, this indicates a pre-standard RFC 7329 implementation. Such a response MUST NOT be discarded, and all subsequent transactions in that dialog MUST preserve the UUID order until the dialog terminates.
An endpoint that receives a Session-ID with a non-nil 'local-uuid' MUST treat that value as the peer's UUID and include it as the 'remote' parameter in subsequent messages. If a message is received without a Session-ID header, the endpoint MUST NOT change its internally maintained remote-uuid value.
Devices storing a session identifier in a log file SHOULD follow the security considerations outlined in RFC 6872. The primary intent of a session identifier is for troubleshooting, so it should be included in logs used for troubleshooting purposes.
Endpoints MUST generate version 4 (random) or version 5 (SHA-1) UUIDs to address privacy concerns related to the use of MAC addresses in UUIDs. Version 1 UUIDs (which embed the MAC address) are explicitly prohibited.
Endpoints MUST include a Session-ID header field value in all SIP messages transmitted as part of a communication session. The locally generated UUID MUST appear in the 'local-uuid' portion and the peer's UUID, if known, MUST appear as the 'remote' parameter; the nil UUID MUST be used if the peer's UUID is not yet known.
If an endpoint receives a SIP response with a non-nil 'local-uuid' that is not 32 octets long, the response comes from a misbehaving implementation and its Session-ID header field MUST be discarded; however, the response itself SHOULD still be checked for SIP validity.
In a 3PCC scenario, a transaction-stateful SIP server MUST replace its own temporary UUID 'X' with a nil UUID when forwarding the INVITE to the second UAS, so that the second UAS sees the originating endpoint's UUID as the remote peer rather than the intermediary's fabricated UUID.
MCUs (Multipoint Control Units) MUST utilize the same UUID value ('local-uuid') with all participants in a conference, enabling correlation across conference sessions while preserving uniqueness of each individual session identifier.
Once an endpoint allocates a UUID for a session, it MUST NOT change that UUID for the duration of the session, including when communication attempts are retried (4xx/timeout), the session is redirected (3xx), transferred via REFER, or an INVITE with Replaces is used.
Stateless intermediaries that insert a Session-ID header on behalf of an endpoint MUST use version 5 UUIDs. If the tag value for the endpoint is unknown (e.g., a new INVITE without a To: tag), the intermediary MUST NOT attempt to generate a UUID for that endpoint.
The Session-ID header field MUST NOT have more than one 'remote' parameter. Except for backwards compatibility with RFC 7329, the 'remote' parameter MUST be present in all Session-ID header fields.
The Session-ID header field value included in a CANCEL request MUST be identical to the Session-ID header field value included in the corresponding request being cancelled.
The UAC initiating a session MUST create a new, previously unused UUID and transmit it; likewise, the UAS MUST create a new, previously unused UUID and transmit it to the UAC. These two distinct UUIDs together form the session identifier {A,B}, which is symmetric ({A,B} equals {B,A}).
When an endpoint or intermediary receives a mid-dialog request with a new UUID from a peer, all responses MUST contain the new UUID as the 'remote' parameter; acceptance is confirmed only upon a 2xx or 3xx response, not a failure response. For CANCEL requests, the new UUID MUST NOT be accepted.
When an intermediary forwards a SIP message, it MUST include the Session-ID header field with the same UUID values found in the received message, except as outlined for specific cases such as aggregated responses, call joins, 3PCC, and CANCEL requests.
When an intermediary originates a request without a triggering received message and has no knowledge of both endpoint UUIDs, the Session-ID header value SHOULD NOT be included at all, since a header with two nil UUIDs has no practical value.
When generating a version 5 UUID, endpoints or intermediaries MUST use the procedures in RFC 4122 Section 4.3 with the namespace ID a58587da-c93d-11e2-ae90-f4ea67801e29, and the 'name' MUST be the concatenation of the Call-ID header value and the 'tag' parameter from the 'From' or 'To' line.
To prevent user or device information from being conveyed, endpoints MUST generate only version 4 (random) or version 5 (SHA-1) UUIDs. Version 1 UUIDs embed the MAC address of the endpoint and are therefore prohibited as they would expose device identity.
A special nil UUID composed of 32 zeros is required when the peer's UUID is not yet known, such as in the initial INVITE request from a UAC before the UAS has responded. The nil value is replaced once the peer's UUID is learned.
The Session-ID header field conveys a session identifier comprising two UUIDs: a 'local-uuid' representing the transmitting endpoint and a 'remote-uuid' (carried in the 'remote' parameter) representing the peer. The header is a single-instance header and replaces the definition introduced in RFC 7329.
This document registers the 'remote' parameter for the 'Session-ID' SIP header field in the IANA 'Header Field Parameters and Parameter Values' registry.
This document registers the 'Session-ID' SIP header field in the IANA 'Header Fields' registry under the 'Session Initiation Protocol (SIP) Parameters' registry, replacing the registration made by RFC 7329.
Session identifiers may inadvertently reveal information about the network topology or the relationships between devices. Endpoints and intermediaries should be aware that logging session identifiers, while useful for troubleshooting, must be done in accordance with RFC 6872 to limit unintended disclosure.
UUID change acceptance follows a state machine: on receiving a mid-dialog request with a new UUID, tentatively accept it in responses; commit if a 2xx/3xx response or ACK for 2xx/3xx is sent; revert to the previously stored UUID if a 4xx/5xx/6xx response is sent or a CANCEL is received.
The Session-ID header field uses ABNF syntax: session-id-value = local-uuid *(SEMI sess-id-param), where sess-uuid is exactly 32 lowercase hexadecimal characters ([0-9a-f]) and nil is 32 zeros. The remote UUID is carried as a 'remote' parameter after a semicolon.