RFC 7989
End-to-End Session Identification in IP-Based Multimedia Communication Networks
RFC 7989 📜✨
Okay bestie, this is RFC 7989, End-to-End Session Identification in IP-Based Multimedia Communication Networks 🎀. Written by P. Jones, G. Salgueiro, C. Pearce, and P. Giralt, all from Cisco Systems, Inc. 💅 It's a Standards Track doc (ISSN 2070-1721), dated October 2016, and it obsoletes RFC 7329 🫶. It doesn't update anything else.
Abstract 🦋
Okay so the big idea 💖 is an end-to-end session identifier for IP-based multimedia communication systems. It lets endpoints, intermediary devices, and management systems identify a session end-to-end, tie multiple endpoints to one multipoint conference, keep track of sessions when they get redirected, and link one or more media flows to a given communication session. The identifier is meant to work across multiple protocols, but this doc only describes how it's used in the Session Initiation Protocol (SIP) 🌸.
This doc also has a backwards-compatibility mechanism for an existing session identifier implementation (RFC 7329) that's different enough from the procedures here to need its own thing 🙈.
This document obsoletes RFC 7329. 💀
Status of This Memo 📝
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check out Section 2 of RFC 7841 🎀.
Info about the current status of this document, any errata, and how to give feedback is at http://www.rfc-editor.org/info/rfc7989 ✨.
Copyright Notice ⚖️
Copyright (c) 2016 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 (http://trustee.ietf.org/license-info) as they stand on the date of publication. Please read these carefully, bestie, because they explain your rights and restrictions for this document 👀. Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🌈.
Table of Contents 📑
1. Introduction ....................................................4
2. Conventions Used in This Document ...............................5
3. Session Identifier Definitions, Requirements, and Use Cases .....5
4. Constructing and Conveying the Session Identifier ...............5
4.1. Constructing the Session Identifier ........................5
4.2. Conveying the Session Identifier ...........................6
5. The Session-ID Header Field .....................................8
6. Endpoint Behavior ...............................................9
7. Processing by Intermediaries ...................................11
8. Handling of Remote UUID Changes ................................14
9. Associating Endpoints in a Multipoint Conference ...............16
10. Examples of Various Call Flow Operations ......................17
10.1. Basic Call with Two UUIDs ................................18
10.2. Basic Call Transfer Using REFER ..........................22
10.3. Basic Call Transfer Using Re-INVITE ......................24
10.4. Single Focus Conferencing ................................26
10.5. Single Focus Conferencing Using a Web-Based
Conference Service .......................................28
10.6. Cascading Conference Bridges .............................30
10.6.1. Establishing a Cascaded Conference ................30
10.6.2. Calling Into Cascaded Conference Bridges ..........31
10.7. Basic 3PCC for Two UAs ...................................33
10.8. Handling in 100 Trying SIP Response and CANCEL Request ...33
10.8.1. Handling in a 100 Trying SIP Response .............34
10.8.2. Handling a CANCEL SIP Request .....................35
10.9. Out-of-Dialog REFER Transaction ..........................36
11. Compatibility with a Previous Implementation ..................37
12. Security and Privacy Considerations ...........................39
13. IANA Considerations ...........................................40
13.1. Registration of the "Session-ID" Header Field ............40
13.2. Registration of the "remote" Parameter ...................40
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................42
Acknowledgements ..................................................44
Dedication ........................................................44
Authors' Addresses ................................................451. Introduction ✨
Okay, so IP-based multimedia communication systems, like the Session Initiation Protocol (SIP) [RFC3261] and [H.323], have this idea of a "call identifier" that's globally unique 🌟. It's meant to represent an end-to-end communication session, from the originating device all the way to the terminating device. It's super useful for troubleshooting, session tracking, and stuff like that 🔍.
BUT, the call identifiers that SIP and H.323 currently define aren't really built for end-to-end session identification 😭. One big problem is that the call identifier syntax in SIP and H.323 is different 🙃. So if a call uses both protocols, you literally can't pass the call identifier end-to-end 💀.
Another reason is that real-world devices, like session border controllers [RFC7092], often change the session signaling (including the call identifier value) as it passes through them 🫠. That's deliberate and useful, but it makes tracking a session end-to-end really hard 😩.
So this doc defines a new identifier, called the "session identifier" 🦋. It's meant to fix the problems with the call identifiers that SIP and other IP-based communication systems use today. The ITU ([H.460.27]) has adopted this identifier for H.323-based systems 🎀, so you can trace a session end-to-end even when it goes through both SIP and H.323 systems. This doc covers how it's used in SIP 💅.
The procedures here try to meet the requirements in [RFC7206] 💖. They also specify capabilities that [RFC7206] doesn't mention, which you can see in the call flows in Section 10 🌸. On top of that, this spec tries to account for a previous, pre-standard version of a SIP session identifier header [RFC7329], with a backwards-compatibility approach in Section 11 🧚.
2. Conventions Used in This Document 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] when they appear in ALL CAPS 🔑. These words may also show up in lowercase in this document, and in that case they don't have their normative meanings 🙈.
Quick vocab check 💅: "session identifier" is the value of the identifier, while "Session-ID" is the header field that carries it. The session identifier is a set of two Universally Unique Identifiers (UUIDs), and each element of that set is just called a "UUID" 🩷.
Throughout this doc, "endpoint" means a SIP User Agent (UA) that either starts or ends a SIP session, like a user's mobile phone or a conference server 📱. It does NOT include things like Back-to-Back User Agents (B2BUAs), which usually sit along the call-signaling path between endpoints 🚫. "Intermediary" means any entity along that call-signaling path between endpoints, including B2BUAs and SIP proxies 🔀. In some scenarios, intermediaries can originate and terminate SIP messages without an endpoint being part of the session or transaction 🌈. An intermediary might also be doing interworking between different protocols (for example, SIP and H.323) that both support the session identifier defined here ✨.
3. Session Identifier Definitions, Requirements, and Use Cases 🧠
The requirements and use cases for the end-to-end session identifier are in [RFC7206], and that's also where you'll find the definitions of "session identifier," "communication session," and "end-to-end" 📚. In this doc, when we say "session," we mean a "communication session" as [RFC7206] defines it 💜.
As mentioned in Section 6.1 of [RFC7206], the ITU-T ran a parallel effort to define compatible procedures for an H.323 session identifier 🌍. Those are documented in [H.460.27] 🫶.
4. Constructing and Conveying the Session Identifier 🛠️
4.1. Constructing the Session Identifier 💖
Okay so the session identifier is made of two UUIDs [RFC4122], and each UUID stands for one of the endpoints taking part in the session 👯.
The version number inside a UUID tells you how it was generated, like with random values or with the Media Access Control (MAC) address of the endpoint 🔢. To meet the requirement that no user or device information gets conveyed, endpoints MUST generate version 4 (random) or version 5 (SHA-1) UUIDs 🙅♀️. That's how they dodge the privacy issues that come with putting MAC addresses in UUIDs 🔒.
When generating a version 5 UUID, endpoints or intermediaries MUST follow the procedures in Section 4.3 of [RFC4122] and use this "namespace ID" 🧁:
uuid_t NameSpace_SessionID = {
/* a58587da-c93d-11e2-ae90-f4ea67801e29 */
0xa58587da,
0xc93d,
0x11e2,
0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
};The "name" for version 5 UUIDs is the Call-ID header-value concatenated with the "tag" parameter that's on the "From" or "To" line for the device the UUID is being made for 🏷️. Once an endpoint generates a UUID for a session, that UUID NEVER changes, even if the values that went into building it change over time 🔒✨. Lowkey iconic.
Stateless intermediaries that insert a Session-ID header field into a SIP message on behalf of an endpoint MUST use version 5 UUIDs 🎀, so the UUIDs for the communication session stay consistently generated 💅. If a stateless intermediary doesn't know the tag value for the endpoint, the intermediary MUST NOT try to generate a UUID for that endpoint 🚫. That can happen with a new INVITE request that has no To: tag value, or with an older SIP implementation [RFC2543] that didn't include a "tag" parameter 🙈. Also, if a stateless intermediary's endpoint on one end of the call gets swapped out for another endpoint because of some service interaction, the values used to create the UUID should change, and if they do, the intermediary will compute a different UUID 🦋. It's giving "new call, new identity" energy 💜.
4.2. Conveying the Session Identifier 💌
Okay bestie, so the SIP User Agent (UA) that starts a new session by sending a SIP request ("Alice") is a User Agent Client (UAC), and she MUST create a brand new, previously unused UUID and send it along to the ultimate destination UA ("Bob") 💖. Then Bob, who is a User Agent Server (UAS), MUST also create his own new, previously unused UUID and send it back to Alice 🎀. Those two UUIDs together are the "session identifier" ✨, and we write it in set notation like {A,B}, where "A" is the UUID Alice made and "B" is the UUID Bob made. The order doesn't matter, so {A,B} is the same as {B,A} 🫶. Section 6 explains how those UUIDs stick around for the whole session 💅.
Now, what if you only know one UUID? That happens when a UA first starts a request that could kick off a dialog 🧚. Then the session identifier looks like {A,N}, where "A" is Alice's UUID and "N" is the "nil UUID" [RFC4122] (more on that in Section 5 of this document) 🙈.
Sessions are kinda chaotic, ngl 😭. Service interactions can happen, SIP INVITE requests might get forked while the session is being set up, and conferences can grow when endpoints call in or when the conference focus calls people out. That's exactly why building the session identifier as a set of UUIDs matters so much 👑.
Let's make it concrete. Imagine an endpoint in a call gets swapped out for another one, like when two "legs" of a call get joined together by a Private Branch Exchange (PBX) 🌸. Say "Alice" and "Bob" both call UA "C" ("Carol"). Now you've got two totally separate session identifiers: {A,C} and {B,C} 👯. Then Carol uses a local PBX function to connect her call with Alice to her call with Bob, so now Alice and Bob are on one remaining call 🦋. That merged call can be identified by the two UUIDs that each party in the session made, which in this example is {A,B} 💜.
Forking is its own thing 🍓. Alice might send an INVITE that gets forked out to a bunch of different endpoints. You need a way to tell all of those sessions apart. Since each destination UA creates its own UUID, each session gets identified by {A, B1}, {A, B2}, {A, B3}, and so on, where each Bn is the UUID made by one of the UAs the SIP session was forked to 🌈.
For conferences, it's also handy to have a two-part session identifier where the conference focus gives the same UUID to every participant 🎀. That way you can connect everyone in a single conference together. For example, in a conference with three people, the session identifiers might be {A,M}, {B,M}, and {C,M}, where "M" is assigned by the conference focus ✨. Only a conference focus will purposely use the same UUID for more than one SIP session, and even then, that reuse MUST be limited to the participants in the same conference 🔥.
How a device uses the session identifier after it gets it is out of scope for this document 💅. But devices that store a session identifier in a log file SHOULD follow the security considerations in [RFC6872] 🔒. Also, the main reason a session identifier exists is troubleshooting, so it should be included in logs at rest that get used for troubleshooting 🧚.
5. The Session-ID Header Field 🌷
This document replaces the definition of the "Session-ID" token that [RFC7329] added to the "message-header" element in the SIP message grammar 💫. The Session-ID header is a single-instance header, so only one shows up per message 🦋.
Every endpoint in a communication session has its own UUID that's distinct from everyone else's 💖. Ideally, the endpoint generates that UUID locally 🏡. That endpoint's UUID stays the same for the whole duration of the communication session 💜. Multipoint conferences can bridge sessions from multiple endpoints, and they come with their own special requirements, which are defined in Section 9 👑. An intermediary MAY generate a UUID on behalf of an endpoint that didn't include a UUID of its own 🫶.
The UUID values for each endpoint go into the Session-ID header field of every SIP message that gets sent 🍓. The Session-ID header field uses the following ABNF [RFC5234] syntax 📜:
session-id = "Session-ID" HCOLON session-id-value
session-id-value = local-uuid *(SEMI sess-id-param)
local-uuid = sess-uuid / nil
remote-uuid = sess-uuid / nil
sess-uuid = 32(DIGIT / %x61-66) ;32 chars of [0-9a-f]
sess-id-param = remote-param / generic-param
remote-param = "remote" EQUAL remote-uuid
nil = 32("0")The productions "SEMI", "EQUAL", and "generic-param" come from [RFC3261] ✨. The production DIGIT comes from [RFC5234] 🌸.
The Session-ID header field MUST NOT have more than one "remote" parameter 🙅♀️. If an entity that follows this specification is interworking with an entity that implemented a session identifier as defined in [RFC7329], the "remote" parameter may be absent 🤝. Otherwise, the "remote" parameter MUST be present 💅. The details of when those conditions apply are described in Section 11 📖. Except for backwards compatibility with [RFC7329], the "remote" parameter MUST be present, period 🎀.
A special nil UUID value made of 32 zeros is required in certain situations 🕳️. A nil UUID is expected as the "remote-uuid" of every initial standard SIP request, because the initiating endpoint wouldn't know the remote endpoint's UUID yet 🌙. That nil value gets replaced by the ultimate destination UAS once that UAS generates a response message ✨. There's one caveat for a possible backwards-compatibility case, and it's explained in Section 11 🔍. Some intermediary devices also send back a nil UUID as the "local-uuid" component of the Session-ID header field value in provisional or other responses, as described in Section 7 🧚.
The "local-uuid" in the Session-ID header field is the UUID of the endpoint sending a message, and the "remote-uuid" is the UUID of that endpoint's peer 💜. For example, a Session-ID header field might look like this 💖:
Session-ID: ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2That's the general vibe of the Session-ID header field, but exceptions to the syntax and procedures get detailed in later sections 🦋.
The UUID values are written as strings of lowercase hexadecimal characters, with the most significant octet of the UUID coming first 🔢.
6. Endpoint Behavior 🦋
To follow this specification, endpoints (that is, non-intermediaries) MUST include a Session-ID header field value in every SIP message they send as part of a communication session 💅. The transmitter's own locally generated UUID MUST show up in the "local-uuid" portion of the Session-ID header field value 💖. The peer device's UUID, if the transmitter knows it, MUST show up as the "remote" parameter right after the transmitter's UUID 🫶. If the peer device's UUID isn't known, the nil UUID value MUST be used 🕳️.
Once an endpoint has allocated a UUID value for a communication session, the endpoint that originated the request MUST NOT change that UUID value for the whole duration of the session 🔒. That includes when:
- communication attempts get retried because of a received 4xx message or request timeouts 🔁;
- the session gets redirected in response to a 3xx message 🛣️;
- the session gets transferred via a REFER message [RFC3515] 📞; or
- a SIP dialog gets replaced via an INVITE request with Replaces [RFC3891] 🔄.
When an endpoint receives a Session-ID header field, it MUST take note of any non-nil "local-uuid" value it gets, and it should assume that value is the UUID of the peer endpoint in that communication session 👀. Endpoints MUST include that received UUID value as the "remote" parameter whenever they send later messages 💌. They also have to make sure they don't change the UUID value while moving it from the "local-uuid" field over to the "remote-uuid" field 🧠.
If an endpoint receives a 3xx message, a REFER that points it to a different peer, or an INVITE request with Replaces that might also end up talking to a new peer, the endpoint MUST finish any message exchanges with its current peer using the existing session identifier 🏁. But it MUST NOT use the current peer's UUID value when it sends the first message to what it thinks might be a new peer endpoint 🚫. That's true even if the exchange ends up talking to the same physical or logical entity 🙃. The endpoint MUST still keep its own UUID value, as described above 💜.
Messages an endpoint receives might contain a "local-uuid" value that doesn't match what the endpoint expected its peer's UUID to be 🤔. It's also possible for an endpoint to receive a "remote-uuid" value that doesn't match the UUID it generated for the session 😳. Either one might happen because of service interactions by intermediaries, and it MUST NOT affect how the endpoint processes the session 🙅♀️. The endpoint may log the event, though, for troubleshooting purposes 📝.
An endpoint MUST assume that the peer endpoint's UUID value can change at any time because of service interactions ⚡. Section 8 talks about how endpoints have to handle remote UUID changes 🧩.
Also, if an intermediary forks a session, the endpoint that started the session may get multiple responses back from different endpoints, and each one contains a different "local-uuid" UUID value 🍓. Endpoints MUST make sure the correct UUID value goes into the "remote" parameter when they interact with each endpoint 🎯. The one exception is when the endpoint sends a CANCEL request, and in that case the Session-ID header field value MUST be identical to the Session-ID header field value sent in the original request 🔁.
If an endpoint receives a message that doesn't contain a Session-ID header field, that message must have no effect on what the endpoint believes the remote endpoint's UUID value is 🙈. In other words, the endpoint MUST NOT change the internally maintained "remote-uuid" value for the peer 🔐.
If an endpoint receives a SIP response with a non-nil "local-uuid" that isn't 32 octets long, that response comes from a misbehaving implementation, and its Session-ID header field MUST be discarded 🗑️. Even so, the response might still be valid under the rules in SIP [RFC3261], so it SHOULD be checked further 🔍.
A Multipoint Control Unit (MCU) is a special type of conferencing endpoint, and it gets its own discussion in Section 9 👑✨.
7. Processing by Intermediaries 🦋
okay bestie, this part is only for intermediaries that want to follow this spec 💅 if you're an intermediary that doesn't want any special treatment for the Session-ID header field, you don't have to do any of this. (fyi, those intermediaries might just pass the header through unchanged or drop it entirely 💀)
The Call-ID is lowkey a leaker 🙈 it often reveals personal, device, domain, or other sensitive info about a user, which is one reason why things like session border controllers sometimes change it. To keep the end-to-end session identifier safe, it's built so it doesn't reveal any of that, so intermediaries don't need to touch it. Main character energy 👑
When an intermediary gets messages from one endpoint that cause messages to go out toward the second endpoint, the intermediary MUST include the Session-ID header field in those transmitted messages with the same UUID values found in the received message, except as outlined in this section and in Section 8. 🫶
If the intermediary aggregates several responses from different endpoints, as described in Section 16.7 of [RFC3261], the intermediary MUST set the local-uuid field to the nil UUID value when forwarding the aggregated response to the endpoint, since the true UUID value of the peer is undetermined at that point. Note that an intermediary that doesn't implement this spec might forward a non-nil value, which means the originating endpoint gets different UUID values in the responses 😭 It's possible for this to make the endpoint temporarily use the wrong remote UUID. Later messages in the dialog should fix the temporary mismatch, as long as the endpoint follows the rules in Section 8 for handling remote UUID changes ✨
Intermediary devices that transfer a call, like by joining together two different "call legs," MUST properly construct a Session-ID header field that contains the UUID values for the endpoints in the joined session, with those values placed correctly 🎀 As described in Section 6, the endpoint receiving a message from the intermediary will assume that the first UUID value belongs to its peer endpoint.
If an intermediary receives a SIP message without a Session-ID header field or a valid header field value from an endpoint that the intermediary is not storing a remote-uuid value for, the intermediary MAY assign a local-uuid value to represent that endpoint. Having done so, it MUST insert that assigned value into all signaling messages on behalf of the endpoint for that dialog. In effect, the intermediary becomes dialog-stateful 🧚 It MUST follow the endpoint procedures in Section 6 for Session-ID header field value treatment, with itself acting as the endpoint (for the purposes of the Session-ID header field) for which it inserted a component into the header field value. If the intermediary knows the UUID value that identifies the endpoint a message is directed to, it MUST insert that UUID value into the Session-ID header field value as the remote-uuid value. If the intermediary doesn't know the UUID value that identifies the receiving endpoint, it MUST use the nil UUID value as the remote-uuid value.
If an intermediary receives a SIP message without a Session-ID header field or a valid Session-ID header field value from an endpoint that the intermediary has previously received a Session-ID from, and it's storing a remote-uuid value for that endpoint, then the lack of a Session-ID must have no effect on what the intermediary believes the endpoint's UUID value is. Basically, the intermediary MUST NOT change the internally maintained remote-uuid value for the peer 🙅♀️
When an intermediary originates a response, like a provisional response or a response to a CANCEL request, the remote-uuid field will contain the UUID value of the receiving endpoint. When the UUID of the peer endpoint is known, the intermediary MUST insert the UUID of the peer endpoint in the local-uuid field of the header value. Otherwise, the intermediary MAY set the local-uuid field of the header value to the nil UUID value.
When an intermediary originates a request message without first having received a SIP message that triggered it (for example, sending a BYE message to end a call for policy reasons), the intermediary MUST, if it knows the UUID values for both communicating endpoints, insert a Session-ID header field with the remote-uuid field of the header value set to the UUID value of the receiving endpoint, and the local-uuid field of the header value set to the UUID value of the other endpoint. When the intermediary doesn't know the UUID value of an endpoint in the communication session, it SHOULD set the unknown UUID value(s) to the nil UUID value. (If both are unknown, the Session-ID header value SHOULD NOT be included at all, since it would have no practical value 🤷♀️)
Okay, now pay attention, because this part matters 🔥 If an intermediary transmits a nil UUID value, the receiving endpoint might use that value in subsequent messages it sends. That effectively breaks the requirement to maintain an end-to-end session identifier for the communication session, if a UUID for the peer endpoint was already shared. So an intermediary MUST only send the nil UUID when it hasn't communicated with the peer endpoint to learn its UUID. This means intermediaries SHOULD maintain state related to the UUID values for both ends of a communication session if they plan to originate messages (versus merely conveying them). An intermediary that doesn't maintain this state, and that originates a message as described in the previous two paragraphs, MUST NOT insert a Session-ID header field, so it can avoid an unintended, incorrect reassignment of a UUID value 🚫
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 💖
If a SIP intermediary starts a dialog between two endpoints in a third-party call control (3PCC [RFC3725]) scenario, the initial INVITE request will have a non-nil, locally made-up local-uuid value. Let's call this temporary UUID X. The request will still have a nil remote-uuid value, which we'll call N. The SIP server MUST be transaction-stateful. The UUID pair in the INVITE request will be {X,N}, and a 1xx or 2xx response will have a UUID pair of {A,X}. This transaction-stateful, dialog-initiating SIP server MUST replace its own UUID, i.e., X, with a nil UUID (so {A,N}) in the INVITE request it sends toward the other UAS, as expected (see Section 10.7 for an example) 🍓
Intermediaries that manipulate messages containing a Session-ID header field SHOULD be aware of which UUID values they last sent toward an endpoint. Following any kind of service interaction that the intermediary starts or affects, they should also know which UUID values the receiving endpoint should have, so both endpoints in the session have the correct and same UUID values 🌈 If an intermediary can tell that an endpoint might not have received a current, correct Session-ID field, the intermediary SHOULD try to provide the correct Session-ID header field to the endpoint, such as by sending a re-INVITE request. Not doing this can make troubleshooting harder because of the mismatched identifiers, so it is strongly advised that intermediaries attempt to provide the correct session identifier whenever they're able to 🫠
⚠️ If an intermediary receives a SIP response with a non-nillocal-uuidthat is not 32 octets long, that response comes from a misbehaving implementation, and itsSession-IDheader field MUST be discarded. That said, the response might still be valid according to the rules within SIP [RFC3261], so it SHOULD be checked further 👀
An intermediary MUST assume that the UUID value of session peers may change at any time due to service interactions, and it MAY itself change UUID values for sessions under its control, so that end-to-end session identifiers stay consistent for all participants in a session 💜 Section 8 explains how intermediaries must handle remote UUID changes if they maintain state for the session identifier.
An intermediary may perform protocol interworking between different IP-based communications systems, e.g., interworking between H.323 and SIP. If the intermediary supports the session identifier for both protocols it's interworking between, it SHOULD pass the identifier between the two call legs to maintain an end-to-end identifier, regardless of protocol ✨
8. Handling of Remote UUID Changes ✨
okay bestie, when the UUID changes mid-session, everyone involved really wants to agree on the current session identifier 🫶 It's giving teamwork. Race conditions and certain interworking scenarios can get in the way, so it's not always possible to guarantee session identifier consistency 💀. To get the best odds anyway, all endpoints and intermediaries in a session MUST accept a peer's new UUID under the following conditions 🎀:
- When an endpoint or intermediary receives a mid-dialog request containing a new UUID from a peer, all responses to that request MUST contain the new UUID value as the "remote" parameter unless a subsequent successful transaction (for example, an UPDATE) contains a different UUID, in which case, the newest UUID MUST be used.
- If an endpoint or intermediary sends a successful (2xx) or redirection (3xx) response to the request containing the new UUID value, the endpoint or intermediary MUST accept the peer's UUID and include this new UUID as the "remote" parameter for any subsequent messages unless the UUID from a subsequent transaction has already been accepted. The one exception is a CANCEL request, as outlined below. 💅
- If the endpoint or intermediary sends a failure (4xx, 5xx, or 6xx) response, it MUST NOT accept the new UUID value and any subsequent messages MUST contain the previously stored UUID value in the "remote" parameter for any subsequent message. Note that the failure response itself will contain the new UUID value from the request in the "remote" parameter. 😭
- When an endpoint or intermediary receives an ACK for a successful (2xx) or redirection (3xx) response with a new UUID value, it MUST accept the peer's new UUID value and include this new UUID as the "remote" parameter for any subsequent messages. If the ACK is for a failure (4xx, 5xx, or 6xx) response, the new value MUST NOT be used. 🌸
- As stated in Sections 6 and 7, 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 INVITE request. Upon receiving a CANCEL request, an endpoint or intermediary would normally send a 487 Request Terminated response (see Section 15.1.2 of [RFC3261]) which, by the rules outlined above, would result in the endpoint or intermediary not storing any UUID value contained in the CANCEL request. Section 3.8 of [RFC6141] specifies conditions where a CANCEL request can result in a 2xx response. Because a CANCEL request is not passed end-to-end and will always contain the UUID from the original INVITE request, retaining a new UUID value received in a CANCEL request may result in inconsistency with the Session-ID value stored on the endpoints and intermediaries involved in the session. To avoid this situation, an endpoint or intermediary MUST NOT accept the new UUID value received in a CANCEL request and any subsequent messages MUST contain the previously stored UUID value in the "remote" parameter". Note that the response to the CANCEL request will contain the UUID value from the CANCEL request in the "remote" parameter. 🙈
- When an endpoint or intermediary receives a response containing a new UUID from a peer, the endpoint or intermediary MUST accept the new UUID as the peer's UUID and include this new UUID as the "remote" parameter for any subsequent messages. 🦋
When an intermediary accepts a new UUID from a peer, it SHOULD try to give the other endpoints in the session the correct Session-ID header field, for example by sending a re-INVITE request 🧚. If an intermediary gets a message with a "remote" parameter in the session identifier that doesn't match the updated UUID, it MUST update the "remote" parameter with the latest stored UUID. Keep those receipts! 🧾
If an intermediary is doing interworking between two different protocols that both support the session identifier defined in this document (for example, SIP to H.323), UUID changes SHOULD be communicated between protocols to keep the end-to-end session identifier intact ✨.
9. Associating Endpoints in a Multipoint Conference 🎀
okay so Multipoint Control Units (MCUs) group two or more sessions into one multipoint conference, and there's a conference focus in charge of keeping the dialogs connected to it [RFC4353] 👑. MCUs, cascaded ones included, MUST use the same UUID value (the "local-uuid" portion of the Session-ID header field value) with all participants in the conference. Each session is still unique, because every endpoint makes its own UUID, but they all share one UUID with everyone else in the conference 💜. Main character group energy, literally 🫶.
When a cascaded conference is set up, an MCU MUST convey the UUID value for the conference through the "local-uuid" portion of the Session-ID header field value in an INVITE request to a second MCU, when SIP is used to set up the cascade. A conference bridge, or MCU, needs a way to say who it is when it contacts another MCU, and [RFC4579] defines the "isfocus" Contact header field value parameter for exactly that 🧚. The initial MCU MUST include the UUID of that conference in the "local-uuid" of an INVITE request to the other MCU(s) in that conference. That INVITE also carries an "isfocus" Contact header field value parameter, which says the request is coming from an MCU and that this UUID should be handed out in all responses to endpoints in the MCUs of the same conference 🌈. The result: one UUID is shared across every MCU in the same conference, but it stays unique between different conferences ✨.
If two existing conferences get joined, there should be a session between the two MCUs whose session identifier is made of the UUID values of both conferences. That session identifier can be used to connect the sessions of participants in the joined conference 🦋. This specification doesn't add any extra requirements when two existing conferences are joined 💅.
Intermediary devices and network-diagnostic equipment might assume that when they see two or more sessions with different session identifiers but one UUID in common, the sessions belong to the same conference. That isn't always right though 🙈. In a SIP-forking scenario, for example, there can also be what looks like multiple sessions sharing a UUID value, and that's intended! The goal is to let related sessions be linked together, whether they're forked or part of a conference 🫶.
10. Examples of Various Call Flow Operations 🧚
seeing something a bunch makes it way easier to get, so this section has a few call flow examples 🍓. Each message shows the initial UUID and the complete session identifier, plus examples of when the session identifier changes under the rules in this document during certain operations and functions ✨.
This section is for illustrative purposes only and is non-normative 🙈. In the flows below, "RTP" refers to the Real-time Transport Protocol [RFC3550] 🎶.
In the examples in this section, "N" represents a nil UUID, and other letters represent the unique UUID values for the endpoints or MCUs 💖.
10.1. Basic Call with Two UUIDs ✨
Okay bestie, let's watch a basic call happen step by step 🦋. Alice calls Bob through a B2BUA (the middleman that sits between them), and we follow the Session-ID the whole way through 💅
Session-ID
--- Alice B2BUA Bob Carol
{A,N} |---INVITE F1--->| |
{A,N} | |---INVITE F2--->|
{B,A} | |<---200 OK F3---|
{B,A} |<---200 OK F4---| |
{A,B} |-----ACK F5---->| |
{A,B} | |-----ACK F6---->|
|<==============RTP==============>|Figure 1: Session-ID Creation When Alice Calls Bob
So here's the general vibe 🌸
- UA-Alice fills in the "local-uuid" part of the Session-ID header field value 🫶
- UA-Alice sends her UUID in the SIP INVITE and sets the "remote" parameter to a nil value (32 zeros) 🙈
- The B2BUA gets the INVITE with UA-Alice's "local-uuid" and the nil "remote-uuid", then passes the INVITE on to UA-Bob with the Session-ID left completely unchanged ✨
- UA-Bob gets the Session-ID and generates his own "local-uuid", which completes the whole Session-ID. At the same time, he copies UA-Alice's UUID unchanged into the "remote-uuid" part of the 200 OK 🎀
- The B2BUA gets the 200 OK with the complete Session-ID from UA-Bob and passes the 200 OK to UA-Alice, Session-ID unchanged 💖
- When UA-Alice gets the 200 OK from the B2BUA, she sends the ACK back. In this ACK, UA-Alice's UUID is the "local-uuid" and UA-Bob's UUID is the "remote-uuid". The two UUIDs have swapped places, bestie 🔥
- The B2BUA gets that ACK with the complete Session-ID from UA-Alice and sends the ACK to UA-Bob, Session-ID unchanged 👑
Here's a SIP message exchange showing the Session-ID header field being used properly. To keep things short, the non-essential headers and message bodies are left out 🧚
Here's F1, the INVITE from Alice to the B2BUA:
INVITE sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)Here's F2, the INVITE from the B2BUA to Bob:
INVITE sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.1
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
Max-Forwards: 69
To: Bob <sip:bob@biloxi.example.com>
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 314159 INVITE
Contact: <sip:alice@pc33.atlanta.example.com>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 142
(Alice's SDP not shown)Here's F3, the 200 OK from Bob to the B2BUA. Look at that Session-ID now, it's complete and giving main character energy ✨
SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)Here's F4, the 200 OK from the B2BUA to Alice:
SIP/2.0 200 OK
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bK776asdhds;received=10.1.3.33
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: 47755a9de7794ba387653f2099600ef2
;remote=ab30317f1a784dc48ff824d0d3715d86
CSeq: 314159 INVITE
Contact: <sip:bob@192.168.10.20>
Record-Route: <sip:server10.biloxi.example.com;lr>
Content-Type: application/sdp
Content-Length: 131
(Bob's SDP not shown)Here's F5, the ACK from Alice to the B2BUA. Notice how the two UUIDs have swapped spots, iykyk 💅
ACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bKnashds8
Route: <sip:server10.biloxi.example.com;lr>
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2
CSeq: 314159 ACK
Content-Length: 0And here's F6, the ACK from the B2BUA to Bob:
ACK sip:bob@192.168.10.20 SIP/2.0
Via: SIP/2.0/UDP server10.biloxi.example.com
;branch=z9hG4bK4b43c2ff8.2
Via: SIP/2.0/UDP pc33.atlanta.example.com
;branch=z9hG4bKnashds8;received=10.1.3.33
Max-Forwards: 70
To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.atlanta.example.com
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=47755a9de7794ba387653f2099600ef2
CSeq: 314159 ACK
Content-Length: 0The remaining examples in this section don't show the full SIP message exchange. Instead, they use the set notation from Section 4.2 to show how the session identifier moves through each call flow 🦋
10.2. Basic Call Transfer Using REFER 🎀
Okay so, this example picks up right where the one in Section 10.1 left off 💖 This is a mid-dialog REFER, which is different from the out-of-dialog REFER in Section 10.9, so don't mix them up, bestie 🙈
Session-ID
--- Alice B2BUA Bob Carol
| | | |
|<==============RTP==============>| |
{B,A} | |<---re-INVITE---| |
{B,A} |<---re-INVITE---| (puts Alice on Hold) |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
{B,A} | |<-----ACK-------| |
{B,A} |<-----ACK-------| | |
| | | |
{B,A} | |<----REFER------| |
{B,A} |<----REFER------| | |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
{A,B} |-----NOTIFY---->| | |
{A,B} | |-----NOTIFY---->| |
{B,A} | |<----200 OK-----| |
{B,A} |<----200 OK-----| | |
| | | |
{A,N} |-----INVITE---->| |
{A,N} | |-----INVITE-------------------->|
{C,A} | |<----200 OK---------------------|
{C,A} |<----200 OK-----| |
{A,C} |------ACK------>| |
{A,C} | |------ACK---------------------->|
| | | |
|<======================RTP======================>|
| | | |
{A,B} |-----NOTIFY---->| | |
{A,B} | |-----NOTIFY---->| |
{B,A} | |<----200 OK-----| |
{B,A} |<----200 OK-----| | |
{B,A} | |<-----BYE-------| |
{B,A} |<-----BYE-------| | |
{A,B} |-----200 OK---->| | |
{A,B} | |-----200 OK---->| |
| | | |Figure 2: Call Transfer Using REFER
Here's the general vibe, starting from the existing Alice/Bob call in Figure 1, which already set up a Session-ID header field value ✨
- UA-Bob asks Alice to call Carol using a REFER transaction, as described in [RFC3515]. UA-Alice gets put on hold first, then the REFER tells her who to call with a new INVITE, which here is UA-Carol. This Alice-to-Carol dialog gets a new Call-ID, so it needs a brand-new Session-ID header field value. The wrinkle? We can, and will, reuse Alice's UUID from her existing dialog with Bob in the new INVITE to Carol 🧚
- UA-Alice keeps her UUID from the Alice-to-Bob call {A} when she requests a call with UA-Carol. It goes in the "local-uuid" part, and she puts a nil "remote-uuid" value in, because Carol's UA hasn't received a UUID yet. That same UUID passes through the B2BUA unchanged 🫶
- UA-Carol gets the INVITE with the session identifier {A,N}. She copies the "A" UUID into the "remote-uuid" part, makes her own UUID {C} and puts it in the "local-uuid" part, which gets rid of the "N" (nil) value completely. Together these form the full session identifier {C,A} in the 200 OK to the INVITE. The Session-ID header field goes through the B2BUA unchanged on its way to UA-Alice 🌈
- UA-Alice gets the 200 OK with the session identifier {C,A}. She answers UA-Carol with an ACK (just like in Figure 1, the two UUID fields swap places). Then she sends a NOTIFY to Bob with the session identifier {A,B} to say the call transfer worked 🎉
- It doesn't matter which UA ends the Alice-to-Bob call. Figure 2 shows UA-Bob ending it 👑
10.3. Basic Call Transfer Using Re-INVITE 🦋
okay so this one picks up right where the Section 10.1 example left off 💅 Alice and Bob are chatting, and Bob presses a button on his phone to transfer Alice over to Carol through the B2BUA (this time with a re-INVITE, not a REFER) 📞✨
Session-ID
--- Alice B2BUA Bob Carol
| | | |
|<==============RTP==============>| |
| | | |
| | <--- (non-standard signaling) |
{A,B} | |---re-INVITE--->| |
{B,A} | |<-----200 OK----| |
{A,B} | |-----ACK------->| |
| | | |
{A,N} | |-----INVITE-------------------->|
{C,A} | |<----200 OK---------------------|
{A,C} | |------ACK---------------------->|
| | | |
|<======================RTP======================>|
| | | |
{A,B} | |------BYE------>| |
{B,A} | |<----200 OK-----| |
| | | |
{C,A} |<--re-INVITE----| | |
{A,C} |----200 OK----->| | |
{C,A} |<-----ACK-------| | |
| (Suppose Alice modifies the session) |
{A,C} |---re-INVITE--->| | |
{A,C} | |---re-INVITE------------------->|
{C,A} | |<---200 OK----------------------|
{C,A} |<---200 OK------| | |
{A,C} |------ACK------>| | |
{A,C} | |------ACK---------------------->|
| | | |Figure 3: Call Transfer Using Re-INVITE 🌸
okay so the general vibe of this one:
- we're building on the call between Alice and Bob from Section 10.1, and it's already running with session identifier {A,B} 💖
- Bob uses non-standard signaling to the B2BUA to start the transfer from Alice to Carol 🙈 it could also come in as a REFER from Bob, and the flow after that would still look pretty similar. either way, Alice is totally in the dark about the transfer until she gets a message from Carol at some later point 💀
- the B2BUA sends a re-INVITE with the session identifier {"local-uuid" = "A", "remote-uuid" = "B"} to renegotiate with Bob 🫶
- the B2BUA sends a brand new INVITE to Carol carrying Alice's UUID {"local-uuid" = "A"} 🧚
- Carol gets the INVITE, accepts it, and adds her own UUID {C} to the session identifier, so it becomes {"local-uuid" = "C", "remote-uuid" = "A"} 👑
- the B2BUA then ends the call to Bob with a BYE, using the session identifier {"local-uuid" = "A", "remote-uuid" = "B"} 💅
- the B2BUA sends a re-INVITE to Alice to update her view of the session identifier 🦋
- later, when Alice wants to modify the session with a re-INVITE, she sends "remote-uuid" = "C" toward Carol, because she already got the updated UUID in the re-INVITE from the B2BUA ✨ the B2BUA keeps the session identifier {"local-uuid" = "A", "remote-uuid" = "C"} 🎀 Carol replies with "local-uuid" = "C", "remote-uuid" = "A", which matches what she got in the INVITE (she already knew this from earlier chats with the B2BUA) 🌈 then Alice puts "remote-uuid" = "C" in the ACK that follows 🫶
10.4. Single Focus Conferencing 🎀
okay now this is giving conference call energy 📞💜 a bunch of users call into a conference server (an MCU, for example) to join one of the many conferences that server hosts or manages 🍓 each user has to say which conference they want, but that info doesn't have to show up in the SIP messages 🙈 it could come from a dedicated address for the conference or from an Interactive Voice Response (IVR) system, which is what this example assumes, shown with M1, M2, and M3 🧚 every user goes through a two-step signaling process to get into their conference call, and the conference focus labels it "M" ✨
Session-ID Conference
--- Alice Focus Bob Carol
| | | |
| | | |
{A,N} |----INVITE----->| | |
{M1,A} |<---200 OK------| | |
{A,M1} |-----ACK------->| | |
|<====RTP=======>| | |
{M',A} |<---re-INVITE---| | |
{A,M'} |-----200 OK---->| | |
{M',A} |<-----ACK-------| | |
| | | |
| | | |
{B,N} | |<----INVITE-----| |
{M2,B} | |-----200 OK---->| |
{B,M2} | |<-----ACK-------| |
| |<=====RTP======>| |
{M',B} | |---re-INVITE--->| |
{B,M'} | |<----200 OK-----| |
{M',B} | |------ACK------>| |
| | | |
| | | |
{C,N} | |<--------------------INVITE-----|
{M3,C} | |---------------------200 OK---->|
{C,M3} | |<---------------------ACK-------|
| |<=====================RTP======>|
{M',C} | |-------------------re-INVITE--->|
{C,M'} | |<--------------------200 OK-----|
{M',C} | |----------------------ACK------>|
Figure 4: Single Focus Conference Bridge 🌸
okay the general operation:
- Alice calls into a conference server to join a certain conference 💖 this is a two-step thing, because Alice can't put the conference ID in the INVITE, and she can't put any passcode in it either 🙈 step one is Alice's UA calling another UA to join a session, which looks pretty much like the call flow in Figure 1 (in Section 10.1) 🫶 what makes this one unique is step two: the conference server sends a re-INVITE with its second UUID, but it keeps the UUID Alice sent in the first INVITE 👑 that second UUID from the conference server is the same for every UA that calls into this server for this same conference bridge/call, and it's generated once Alice typically authenticates and picks which bridge she wants 🔥
- Alice sends an INVITE to the conference server with her UUID {A} and a "remote-uuid" = "N" 🦋
- the conference server answers with a 200 OK, which swaps the "N" UUID for a temporary UUID ("M1") as the "local-uuid" and sets "remote-uuid" = "A" ✨
NOTE: this 'temporary' UUID is a real UUID 💅 it's only temporary from the conference server's point of view, because the server already knows it's going to generate another UUID to replace the one it just sent in the 200 OK response 💀
- once Alice gets into the IVR for this conference server, she enters a specific conference ID and whatever passcode is needed to join a particular conference call 📞
- once the conference server is happy that Alice picked the right conference (passcode check included), it re-INVITEs Alice into that specific conference with the Session-ID header field value component "local-uuid" = "M'" (and "remote-uuid" = "A") 🌈 everyone who's a valid participant in the same conference gets this same UUID, which helps with identification and makes monitoring and tracking easier 🎀
- Bob goes through this same two-step thing: an INVITE transaction, then a re-INVITE transaction to get the same UUID ("M'") for the conference 🧚
- in this example, Carol (and every other user) goes through the same steps as Alice and Bob to get into this same conference 🫶
10.5. Single Focus Conferencing Using a Web-Based Conference Service 📞
Okay bestie, Alice, Bob, and Carol all call into the same web-based conference 🎀. Heads up though: this is just one of many ways to pull this off, so it should not be construed as the preferred way of establishing a web-based conference 💅.
Session-ID Conference
--- Alice Focus Bob Carol
| | | |
|<** HTTPS *****>| | |
| Transaction | | |
| | | |
{M,N} |<----INVITE-----| | |
{A,M} |-----200 OK---->| | |
{M,A} |<-----ACK-------| | |
|<=====RTP======>| | |
| | | |
| |<** HTTPS *****>| |
| | Transaction | |
| | | |
{M,N} | |-----INVITE---->| |
{B,M} | |<----200 OK-----| |
{M,B} | |------ACK------>| |
| |<=====RTP======>| |
| | | |
| |<****************** HTTPS *****>|
| | Transaction |
| | | |
{M,N} | |--------------------INVITE----->|
{C,M} | |<-------------------200 OK------|
{M,C} | |---------------------ACK------->|
| |<====================RTP=======>|Figure 5: Single Focus Web-Based Conference
Here's the general vibe of this one 🦋:
- Alice tells the web server she wants to join a certain meeting by using a meeting number, and she includes UA-Alice's contact information (phone number, URI, and/or IP address, etc.) for each device she wants for this conference call. For example, the audio and video (A/V) play-out devices could be separate units. 🎧
- The Conference Focus server sends the INVITE request (Session-ID header field value components
"local-uuid"="M"and a remote UUID of"N", where"M"equals the"local-uuid"for each participant on this conference bridge) to UA-Alice to start a session with that server for this A/V conference call. 📨 - Once Alice gets that INVITE from the conference focus server, she replies with a 200 OK. Her UA moves the
"local-uuid"unchanged into the"remote-uuid"field, generates her own UUID, and places that into the"local-uuid"field to complete the Session-ID construction. ✨ - Bob and Carol do the same thing to join this same A/V conference call as Alice. 👯♀️
10.6. Cascading Conference Bridges 🌈
10.6.1. Establishing a Cascaded Conference
Okay so, expanding conferencing capabilities requires cascading conference bridges 🧚. A conference bridge, or MCU, needs a way to identify itself when it contacts another MCU. [RFC4579] defines the "isfocus" Contact header field value parameter just for this purpose 💜.
Session-ID
--- MCU-1 MCU-2 MCU-3 MCU-4
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |Figure 6: MCUs Communicating Session Identifier UUID for Bridge
Regardless of which MCU (1 or 2) a UA contacts for this conference, once the above exchange has been received and acknowledged, the UA will get the same {M',N} UUID pair from the MCU for the complete session identifier. Iconic consistency 👑.
A more complex form would be a series of MCUs all being informed of the same UUID to use for a specific conference. This series of MCUs can be informed in one of two ways:
- All by one MCU (the one that initially generates the UUID for the conference). 🌸
- The MCU that generates the UUID informs one or several MCUs of this common UUID, and then they inform downstream MCUs of this common UUID that each will be using for this one conference. 🔥
Session-ID
--- MCU-1 MCU-2 MCU-3 MCU-4
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
| | | |
{M',N} |---------------------INVITE----->| |
{K,M'} |<--------------------200 OK------| |
{M',K} |----------------------ACK------->| |
| | | |
{M',N} |-------------------------------------INVITE----->|
{L,M'} |<------------------------------------200 OK------|
{M',L} |--------------------------------------ACK------->|Figure 7: MCU Communicating Session Identifier UUID to More Than One MCU
Here's the general operation of this one 💅:
- The MCU generating the session identifier UUID communicates this in a separate INVITE, having a Contact header with the
"isfocus"Contact header field value parameter. This identifies the MCU as what [RFC4579] calls a "conference-aware" SIP entity. 🫶 - An MCU that receives this
{M',N}UUID pair in an inter-MCU transaction can communicate the M' UUID in the manner in which it was received, to construct a hierarchical cascade (though this time, this second MCU would be the UAC MCU). 🍓 - Once the conference is terminated, the cascaded MCUs will receive a BYE message to terminate the cascade. 💀
10.6.2. Calling Into Cascaded Conference Bridges
Here's how a UA, Robert for example, calls into a cascaded conference focus 🎀. Because MCU-1 has already contacted MCU-3 (the MCU where Robert is going to join the conference), MCU-3 already has the Session-ID (M') for this particular conference call.
Session-ID
--- MCU-1 MCU-2 MCU-3 Robert
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
| | | |
{M',N} |---------------------INVITE----->| |
{K,M'} |<--------------------200 OK------| |
{M',K} |----------------------ACK------->| |
| | | |
{R,N} | | |<---INVITE-----|
(M',R} | | |----200 OK---->|
{R,M'} | | |<----ACK-------|Figure 8: A UA Calling Into a Cascaded MCU UUID
General operation, but make it cute 🦋:
- The UA, Robert in this case, INVITEs the MCU to join a particular conference call. Robert's UA doesn't know whether this is the main MCU of the conference call or a cascaded MCU. Robert likely doesn't know MCUs can be cascaded, he just wants to join a particular call. As is the case with any standard implementation, he includes a nil "remote-uuid". 🙈
- The cascaded MCU, upon receiving this INVITE request from Robert, replaces the nil UUID with the UUID value communicated from MCU-1 for this conference call as the
"local-uuid"in the SIP response, thus moving Robert's UUID "R" to the"remote-uuid"value. 🔁 - The ACK has the Session-ID
{R,M'}, which completes the three-way handshake for this call establishment. Robert has now joined the conference call originated from MCU-1. 🥳 - Once the conference is terminated, the cascaded MCUs will receive a BYE message to terminate the cascade. 💀
10.7. Basic 3PCC for Two UAs 🎧
An external entity sets up calls to both Alice and Bob so they can talk to each other. Main character energy 👑.
Session-ID
--- Alice B2BUA Bob Carol
| | |
{X,N} |<----INVITE-----| |
{A,X} |-----200 OK---->| |
{A,N} | |----INVITE----->|
{B,A} | |<---200 OK------|
{B,A} |<-----ACK-------| |
{A,B} | |------ACK------>|
|<==============RTP==============>|Figure 9: 3PCC-Initiated Call between Alice and Bob
General operation of this example 💖:
- Some out-of-band procedure directs a B2BUA (or other SIP server) to have Alice and Bob talk to each other. In this case, the SIP server has to be transaction stateful, if not dialog stateful. 🧩
- The SIP server INVITEs Alice to a session and uses a temporary UUID
{X}and a nil UUID pairing. 📩 - Alice receives and accepts this call setup, and she replaces the nil UUID with her UUID
{A}in the session identifier, which is now{A,X}. 🙌 - The transaction-stateful SIP server receives Alice's UUID
{A}in the local UUID portion and keeps it there. It discards its own UUID{X}, replacing it with a nil UUID value in the INVITE request to Bob, as if this came from Alice originally. 🪄 - Bob receives and accepts this INVITE request and adds his own UUID
{B}to the session identifier, which is now{B,A}, for the response. 🫶 - The session is established. Slay 💅✨.
10.8. Handling in 100 Trying SIP Response and CANCEL Request 🌸
The following two subsections show examples of the session identifier for a 100 Trying response and a CANCEL request in a single call flow. Let's get into it 🧚.
10.8.1. Handling in a 100 Trying SIP Response ✨
okay so this one is giving call forwarding drama 🦋 The following 100 Trying response is taken from [RFC5359], Section 2.9 ("Call Forwarding - No Answer").
Session-ID Alice SIP Server Bob-1 Bob-2
| | | |
{A,N} |----INVITE----->| | |
{A,N} | |---INVITE---->| |
{N,A} |<--100 Trying---| | |
{B1,A} | |<-180 Ringing-| |
{B1,A} |<--180 Ringing--| | |
| | | |
| *Request Timeout* |
| | | |
{A,N} | |---CANCEL---->| |
{B1,A} | |<--200 OK-----| |
{B1,A} | |<---487-------| |
{A,B1} | |---- ACK ---->| |
| | | |
{N,A} |<-181 Call Fwd--| | |
| | | |
{A,N} | |------------------INVITE------>|
{B2,A} | |<----------------180 Ringing---|
{B2,A} |<-180 Ringing---| | |
{B2,A} | |<-----------------200 OK ------|
{B2,A} |<--200 OK-------| | |
{A,B2} |----ACK-------->| | |
{A,B2} | |------------------ACK--------->|
| | | |
|<=========== Both way RTP Established =========>|
| | | |
{A,B2} |----BYE-------->| | |
{A,B2} | |--------------------BYE------->|
{B2,A} | |<------------------200 OK------|
{B2,A} |<--200 OK-------| | |
| | | |Figure 10: Session Identifier in the 100 Trying and CANCEL Messaging
Below is the explanatory text from [RFC5359], Section 2.9, detailing what the desired behavior is in the above call flow (i.e., what the call flow is attempting to achieve). 💅
Bob wants calls to B1 forwarded to B2 if B1 is not answered (information is known to the SIP server). Alice calls B1, and no one answers. The SIP server then places the call to B2.
General operation of this example:
- Alice generates an INVITE request because she wants to invite Bob to join her session. 🎀 She creates a UUID as described in Section 10.1, and she places that value in the
local-uuidfield of theSession-IDheader field value. Alice also generates aremote-uuidof nil and sends this along with thelocal-uuid. - The SIP server (imagine this is a B2BUA), upon receiving Alice's INVITE request, generates the optional provisional response 100 Trying. 🧚 Since the SIP server has no knowledge of Bob's UUID for his part of the session identifier value, it cannot include his
local-uuid. Rather, any 100 Trying response includes Alice's UUID in theremote-uuidportion of the Session-ID header-value with a nillocal-uuidvalue in the response. This is consistent with what Alice's UA expects to receive in any SIP response containing this UUID. 🫶
10.8.2. Handling a CANCEL SIP Request 🌸
the CANCEL request is the plot twist of this whole call flow 😭 In the same call flow example as the 100 Trying response is a CANCEL request. Please refer to Figure 10 for the CANCEL request example.
General operation of this example:
- In Figure 10 above, Alice generates an INVITE request with her UUID value in the
Session-IDheader field. - Bob-1 responds to this INVITE request with a 180 Ringing. In that response, he includes his UUID in the
Session-IDheader field value (i.e.,{B1,A}); thus completing theSession-IDheader field for this session, even though no final response has been generated by any of Bob's UAs. 👑 - While this means that if the SIP server were to generate a SIP request within this session it could include the complete SessionID, the server sends a CANCEL request and a CANCEL request always uses the same
Session-IDheader field as the original INVITE request. Thus, the CANCEL request would have a session identifier with thelocal-uuid= "A", and theremote-uuid= "N". - As it happens with this CANCEL, the SIP server intends to invite another UA of Bob's (i.e., B2) for Alice to communicate with. 🦋
- In this example call flow, taken from [RFC5359], Section 2.9, a 181 Call is Being Forwarded response is sent to Alice. Since the SIP server generated this SIP request, and has no knowledge of Bob-2's UUID value, it cannot include that value in this 181. Thus, and for the exact reasons the 100 Trying including the session identifier value, only Alice's UUID is included in the
remote-uuidcomponent of theSession-IDheader field value, with a nil UUID present in thelocal-uuidcomponent. 🍓
10.9. Out-of-Dialog REFER Transaction 🧚♀️
this one is so fun because Bob's REFER shows up outside the dialog and it still counts as the same session 🤭 The following call flow was extracted from Section 6.1 of [RFC5589] ("Successful Transfer"), with the only changes being the names of the UAs to maintain consistency within this document.
Alice is the transferee
Bob is the transferer
and Carol is the transfer-target Session-ID Bob Alice Carol
| | |
{A,N} |<-----INVITE--------| |
{B,A} |------200 OK------->| |
{A,B} |<------ACK----------| |
| | |
{B,A} |--INVITE {hold}---->| |
{A,B} |<-200 OK------------| |
{B,A} |--- ACK ----------->| |
| | |
{B,A} |--REFER------------>|(Refer-To:Carol) |
{A,B} |<-202 Accepted------| |
| | |
{A,B} |<NOTIFY {100 Trying}| |
{B,A} |-200 OK------------>| |
| | |
{A,N} | |--INVITE------------>|
{C,A} | |<-200 OK-------------|
{A,C} | |---ACK-------------->|
| | |
{A,B} |<--NOTIFY {200 OK}--| |
{B,A} |---200 OK---------->| |
| | |
{B,A} |--BYE-------------->| |
{A,B} |<-200 OK------------| |
{C,A} | |<------------BYE-----|
{A,C} | |-------------200 OK->|Figure 11: Out-Of-Dialog Call Transfer
General operation of this example:
- Just as in Section 10.2, Figure 2, Alice invites Bob to a session, and Bob eventually transfers Alice to communicate with Carol. 💖
- What is different about the call flow in Figure 11 is that Bob's REFER is not in-dialog. Even so, this is treated as part of the same communication session and, thus, the session identifier in those messages is
{A,B}. ✨ - Alice will use her existing UUID and the nil UUID (
{A,N}) in the INVITE request towards Carol (who generates UUID "C" for this session), thus maintaining the common UUID within the session identifier for this new Alice-to-Carol session. 🌈
11. Compatibility with a Previous Implementation ✨
okay so bestie, this section is all about the OG Session-ID spec, [RFC7329], which never got standardized but got implemented SO much that other standards orgs adopted it anyway 💅 so we need to make the new version play nice with the old one 🫶 there's no version number in either header, so just saying "this is version 2" isn't gonna cut it, you know? 🙈 so we'll call the pre-standard one the "old" version and this one the "new" version. lowkey iconic naming 🎀
the old version only has one UUID as its Session-ID value, but it does have a generic-param that can be useful 🦋
talking old to old? nothing to do here, the IETF doesn't care 💖 new to new? both sides just follow this doc to the letter and it's giving harmony 🌸
but new talking to old (and old talking to new) needs some extra rules 👑 every "new" implementation MUST follow these when it's chatting with devices that run the old version:
- since neither option tags nor feature tags are used to tell versions apart, the presence and order of any "remote-uuid" value in the Session-ID header field value is how you tell which version you're dealing with 🔥
- if a SIP request has a "remote-uuid" value, it came from a standard implementation, not a pre-standard one 💅
- if a SIP request has no "remote-uuid" value, it came from a pre-standard implementation, not a standard one 💀 in that case one UUID identifies the dialog, even if the responder is a standard implementor of this spec 😭
- if a SIP response has a non-nil "local-uuid" that is 32 octets long and differs from the endpoint's own UUID value, it came from a standard implementation 🌈
- if a SIP response has the same Session-ID UUIDs, in the same order as was sent, it came from a pre-standard implementation, and it MUST NOT be discarded even though the "remote-uuid" may be nil ✨ and any new transaction in this dialog MUST preserve the order of the two UUIDs within all Session-ID header fields, including the ACK, until the dialog is terminated 🎀
- if a SIP response only contains the "local-uuid" that was originally sent, it came from a pre-standard implementation and MUST NOT be discarded for removing the nil "remote-uuid" 🍓 in that case all future transactions in this dialog MUST contain only the UUID from the first SIP response 🦋 and any new transaction starting a new dialog from a standard Session-ID implementation MUST include a "local-uuid" and a nil "remote-uuid", even if that new dialog is between the same two UAs 🫶
- standard implementations should NOT expect pre-standard implementations to be consistent, even within the same dialog 🙈 like maybe the first, third, and tenth responses have a "remote-uuid" and the rest don't 🌸 this behavior MUST be allowed by implementations of this spec 💜
- none of the above applies to other, currently unknown parameters that might be defined later 🧚 they get ignored for interop purposes with previous implementations 💖
12. Security and Privacy Considerations 🔐
okay this part is SERIOUS bestie, so let's get into it 🥺
the session identifier MUST be built so it doesn't convey any user or device information, as outlined in Section 4.1 💖 that way the data in the session identifier itself doesn't reveal user or device info 🎀 BUT the session identifier may still reveal relationships between endpoints that messages without a session identifier wouldn't reveal 👀
Section 4.2 says a UA always has to generate a new, previously unused UUID when it sends a request to start a new session ✨ so two unrelated sessions from the same UA will never share a UUID value 🙌 which means an attacker can't use the session identifier to link those two sessions to the same user 🛡️
here's the tricky part 🫣 session identifiers get passed end-to-end and a UA doesn't change them for the whole session 🦋 so they could be misused to find relationships between two or more parties in sessions with multiple parties, like redirects, transfers, or conferences 💅 for example, say Alice calls Bob, and Bob (through his PBX, acting as a B2BUA) forwards or transfers the call to Carol 📞 without the session identifier, an unauthorized third party watching Alice and Bob's traffic wouldn't know Alice is actually talking to Carol 🤷♀️ but if Alice, Bob, and Carol all include the session identifier in their signaling, the third party can see that Bob's UA changed to some other UA 👀 and if they also have access to signaling between Bob and Carol, they can figure out that Alice is talking to Carol 😱 this is true even if the PBX changes everything else, both signaling info and media addresses 💀 BUT the session identifier doesn't reveal who Alice, Bob, or Carol are 🌸 it just reveals that those endpoints were part of the same session 💜
this doc lets additional parameters (generic-param) be included in the Session-ID header 🧚 that's so future extensions can be added while staying backward compatible 🔥 to protect privacy, the data for any generic-param in the Session-ID header value MUST NOT include any user or device information ✨ and any info carried through an additional parameter MUST NOT persist beyond the current session, so it MUST NOT be reused between unrelated sessions 🙅♀️ future extensions MAY use additional parameters to correlate related communication sessions that can't already be correlated by this doc's procedures, as long as the privacy and persistence rules above are followed 🎀
an intermediary running a privacy service that provides user privacy per Section 5.3 of [RFC3323] MAY choose to treat the Session-ID header as a nonessential informational header 🦋 just know that doing this will hurt your ability to use the session identifier for troubleshooting 🙈
13. IANA Considerations 📋
13.1. Registration of the "Session-ID" Header Field 🎀
the following is the registration for the Session-ID header field in the "Header Name" registry at
<http://www.iana.org/assignments/sip-parameters>:
RFC number: RFC 7989
Header name: 'Session-ID'
Compact form: none
Note: This document replaces the Session-ID header originally
registered via [RFC7329].13.2. Registration of the "remote" Parameter 🌈
the following parameter has been added to the "Header Field Parameters and Parameter Values" section of the "Session Initiation Protocol (SIP) Parameters" registry 💖
+--------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+--------------+----------------+-------------------+-----------+
| Session-ID | remote | No | [RFC7989] |
+--------------+----------------+-------------------+-----------+14. References 📚
14.1. Normative References 🫶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://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, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, DOI 10.17487/RFC3891, September 2004, <http://www.rfc-editor.org/info/rfc3891>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006, <http://www.rfc-editor.org/info/rfc4579>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[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, <http://www.rfc-editor.org/info/rfc7206>.
14.2. Informative References 📚
[H.323]International Telecommunications Union, "Packet-based multimedia communications systems", ITU-T Recommendation H.323, December 2009. 🎀[H.460.27]International Telecommunications Union, "End-to-End Session Identifier for H.323 Systems", ITU-T Recommendation H.460.27, November 2015. 🌸[RFC2543]Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, DOI 10.17487/RFC2543, March 1999,<http://www.rfc-editor.org/info/rfc2543>. 💖[RFC3323]Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, DOI 10.17487/RFC3323, November 2002,<http://www.rfc-editor.org/info/rfc3323>. 🦋[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003,<http://www.rfc-editor.org/info/rfc3550>. 🔥[RFC3725]Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,<http://www.rfc-editor.org/info/rfc3725>. 👑[RFC4353]Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006,<http://www.rfc-editor.org/info/rfc4353>. 🧚[RFC5359]Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359, October 2008,<http://www.rfc-editor.org/info/rfc5359>. ✨[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,<http://www.rfc-editor.org/info/rfc5589>. 💜[RFC6141]Camarillo, G., Ed., Holmberg, C., and Y. Gao, "Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)", RFC 6141, DOI 10.17487/RFC6141, March 2011,<http://www.rfc-editor.org/info/rfc6141>. 🍓[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,<http://www.rfc-editor.org/info/rfc6872>. 🌈[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,<http://www.rfc-editor.org/info/rfc7092>. 🫶[RFC7329]Kaplan, H., "A Session Identifier for the Session Initiation Protocol (SIP)", RFC 7329, DOI 10.17487/RFC7329, August 2014,<http://www.rfc-editor.org/info/rfc7329>. 💅
Acknowledgements 🫶
Big thank yous, bestie! The authors would like to thank Robert Sparks, Hadriel Kaplan, Christer Holmberg, Paul Kyzivat, Brett Tate, Keith Drage, Mary Barnes, Charles Eckel, Peter Dawes, Andrew Hutton, Arun Arunachalam, Adam Gensler, Roland Jesske, and Faisal Siyavudeen for their invaluable comments during the development of this document. 💖
Dedication 🕊️
This document is dedicated to the memory of James Polk, a long-time friend and colleague. James made important contributions to this specification, including being one of its primary editors. The IETF global community mourns his loss, and he will be missed dearly. 💜🌸
Authors' Addresses 💌
Paul E. Jones 🦋
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
United States of America
Phone: +1 919 476 2048
Email: paulej@packetizer.comGonzalo Salgueiro 🌟
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
United States of America
Phone: +1 919 392 3266
Email: gsalguei@cisco.comChris Pearce 🎀
Cisco Systems, Inc.
2300 East President George Bush Highway
Richardson, TX 75082
United States of America
Phone: +1 972 813 5123
Email: chrep@cisco.comPaul Giralt 🍓
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
United States of America
Phone: +1 919 991 5644
Email: pgiralt@cisco.com📦 where this page comes from
- ietf: rfc7989 2016-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms