RFC 7329

A Session Identifier for the Session Initiation Protocol (SIP)

📅 published August 2014, from ietf

RFC 7329: A Session Identifier for SIP 🎀

okay bestie, this one is from H. Kaplan at Oracle 💅 It's an Informational doc, published August 2014 (ISSN 2070-1721), and it's the RFC (Request for Comments) that defines the Session-ID header for SIP ✨ It doesn't list anything it obsoletes or updates.

Abstract ✨

okay so the big problem is that SIP needs a globally unique session ID that stays the same across SIP proxies, B2BUAs, and other middleboxes 🦋 Why? So you can troubleshoot a call. This doc proposes a brand new SIP header called Session-ID to carry it 🎀

The mechanism is already widely deployed 🔥 and it's being followed in a backward-compatible way by a new Standards Track doc from the INSIPID Working Group 🫶

Status of This Memo ✨

This is not an Internet Standards Track spec 🌸 It's published just for info purposes 💖

This doc is a product of the Internet Engineering Task Force (IETF) 💜 It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 🙈

For the latest status, errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7329 🧚

Copyright (c) 2014 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) in effect on the date of publication of this document. Please review these documents 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
      1.1. Requirements ...............................................4
   2. Terminology .....................................................4
   3. Overview of Operation ...........................................4
   4. Session-ID Behavior .............................................5
      4.1. Generating a Session-ID Value ..............................5
      4.2. UAC Behavior ...............................................6
      4.3. UAS Behavior ...............................................6
      4.4. Proxy Behavior .............................................6
      4.5. B2BUA Behavior .............................................7
           4.5.1. B2BUA Generation of New Session-ID ..................8
           4.5.2. B2BUA Insertion of Saved Session-ID .................8
   5. Handling SIP Transfer Scenarios .................................8
      5.1. Out-of-Dialog REFER ........................................9
      5.2. Refer-To URI ...............................................9
      5.3. Out-of-Dialog INVITE with Replaces .........................9
   6. Session-ID Migration and Failure Scenarios .....................10
   7. New 'Session-ID' Header ........................................11
      7.1. Augmented BNF Definitions .................................11
   8. Example Exchange ...............................................11
   9. Security Considerations ........................................11
      9.1. Security Considerations for Administrators ................12
      9.2. Security Considerations for Session-ID Extensions .........12
   10. IANA Considerations ...........................................13
   11. Acknowledgments ...............................................13
   12. References ....................................................13
      12.1. Normative References .....................................13
      12.2. Informative References ...................................14
   Appendix A. Use Cases Not in Scope for Session-ID .................15
      A.1. Dialog Correlation for SIP ................................15

1. Introduction ✨

okay so this RFC was originally an individual Internet-Draft that was submitted to the DISPATCH Working Group 🌈 It's being published now as an Informational doc so it can serve as a reference for later RFCs 💜 The mechanism is widely deployed and is being followed in a backward-compatible way by a new Standards Track doc from the INSIPID Working Group 🦋

Quick recap of the Call-ID 🎀 The SIP [RFC3261] Call-ID header value is a globally unique identifier. It's mandatory in all requests and responses, and it identifies SIP messages that belong to the same dialog or registration ✨ It's part of the dialog-matching criteria and gets used in stuff like "Replaces" headers [RFC3891] and dialog-event packages [RFC4235] for matching to dialogs. It's also used in SIP Identity [RFC4474] and Connected Identity [RFC4916] as one of the inputs for signing 🔐

Here's the tea 🍓 In practice, the Call-ID often gets changed by SIP Back-to-Back User Agents (B2BUAs) and other middleboxes in the logical end-to-end message path 🙈 A B2BUA logically represents a SIP User Agent Server (UAS) and User Agent Client (UAC), so it generates a brand new Call-ID for the dialog it creates on its UAC side. For some B2BUA scenarios the Call-ID must be changed for SIP to function properly 💀

At the same time, we need a unique, common, consistent end-to-end identifier to help troubleshoot SIP sessions and message flows as they cross SIP nodes 🔥 Troubleshooting gets way harder when the legs of a session are on different sides of B2BUAs, because there's no common identifier like a Call-ID tying the legs together. Right now, proprietary mechanisms are used to get this done 😭

So, to get an identifier that won't be modified or replaced by B2BUAs, this doc proposes a new SIP header, "Session-ID", plus mandatory rules for its value 👑 The rules are designed so the Session-ID value isn't considered unsafe or private, and doesn't have any property that would make B2BUAs change it 🫶 The goal is to enable troubleshooting with a unique identifier for a given session that can successfully cross B2BUAs, like Application Servers, softswitches, Private Branch Exchanges (PBXs), Session Border Controllers (SBCs), feature servers, and so on 🧚

1.1. Requirements 🎀

These requirements are what drive the need for Session-ID:

  • REQ1: It must be possible for an administrator to use the identifier to identify a set of dialogs that have a direct correlation with each other, such that they represent the same SIP session, with as high a probability as possible.
  • REQ2: It must be possible to pass the identifier through SIP B2BUAs, with as high a probability as possible. This requirement drives the following requirements:
    • REQ2a: The identifier must not reveal any information related to any SIP device or domain identity, including IP address, port, hostname, domain name, username, Address-of-Record (AoR), MAC address, IP address family, transport type, etc.
    • REQ2b: The identifier must not reveal to the receiver of it that the Call-ID, tags, or any other SIP header or body portion have been changed by middleboxes, with as high a probability as possible.
    • REQ2c: The identifier must not be used for anything at a SIP layer to change the behavior of the SIP protocol.

2. Terminology 💅

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] 🫶

This doc uses the terms "header field" and "header field value" the way [RFC3261] defines them, and they are not interchangeable 🙈 The "header field" is the entire SIP header's contents, including any parameters. The "header field value" is only the field-value portion, which does not include header parameters 🎀

3. Overview of Operation ✨

The general idea is this 🦋 The UAC generating an out-of-dialog request creates a new, pseudorandom, unique value. That value stays constant for the duration of the transaction, for any dialog created from that request, or for a registration 💖 The value goes into a new Session-ID header field defined in this doc. Then the UAC and UAS reflect this header field value in all messages for the duration of the dialog 🌸 In other words, Session-ID is similar in nature to Call-ID, except it crosses B2BUAs and has no sensitive info in it 💅

To help deployments migrate, a B2BUA or Proxy MAY also generate and/or insert the value on behalf of a UAC or UAS, if one or the other doesn't support this doc's mechanism 🧚

Even though Session-ID is similar to Call-ID, it is not used for message dialog-matching rules in RFC 3261. It doesn't change the Call-ID usage, and it doesn't replace the Call-ID value 🙈 Instead, this new header field is an identifier for troubleshooting uses only 🔍

The format of the Session-ID value is restricted, for two reasons: to avoid detection of the system type that generated it, and to keep it a hexadecimal representation that can be stored as a 128-bit binary value in log records 🌈

4. Session-ID Behavior 💜

4.1. Generating a Session-ID Value 🔐

This doc proposes that the Session-ID header value be generated based on a defined hash mechanism that creates a 128-bit pseudorandom value, encoded as its lowercase hex representation 🎀 Specifying the mechanism is twofold: it makes it impossible to determine the manufacturer of the device that generated the value by looking at its format or value, and it lets devices generate the same value if they have the same private key 🫶

The secret key is what keeps the HMAC result from being recreated by other parties. That's necessary to prevent detection of Call-IDs being changed, as required by REQ2b. Otherwise, middleboxes may have motivation to remove the Session-ID in order to hide the fact that they changed the Call-ID 👀

Here's how it works ✨ The Session-ID value is generated by taking the Call-ID header value and SHA-1 hashing it based on HMAC (as defined in [RFC2104]). It uses a locally generated pseudorandom 128-bit system secret key to create a 128-bit resultant HMAC value 🦋

Per [RFC2104], the algorithm is thus HMAC-SHA-1-128(Call-ID_value, secret_key), and the 128-bit result is encoded using lowercase alphanumeric hex representation, as defined in Section 7.1 ("Augmented BNF Definitions") 💖

Last but not least, to enable troubleshooting of in-dialog messages, a generator needs to remember or re-create the same Session-ID value for the duration of a given dialog or dialogs 🌸 The subsequent sections of this doc go into more detail on that 🧚

Part 1 of 4. More parts are coming, so stay tuned, bestie 🫶💜

4.2. UAC Behavior 💅

okay so the rules for when a UAC makes a fresh Session-ID are basically the same vibe as the Call-ID rules 🦋 A UAC that supports this mechanism MUST generate a new unique Session-ID value whenever it sends an out-of-dialog request or starts a new Registration 💖 The exceptions are out-of-dialog REFER requests and INVITEs with a Replaces header field (see [RFC3891]), and those get their own special treatment in Section 5 🎀

The UAC MUST reuse the same Session-ID value for in-dialog messages as the one from the original dialog-creating request ✨ Same goes for any out-of-dialog request it retransmits, or re-generates after a 3xx that it reformulates because of failure responses. This follows the [RFC3261] rules for Call-ID generation, so it's giving consistency 🌸

Now the Registration drama 🙈 Session-ID values in Registration "refreshes" (REGISTER requests that just push out the expiry time without registering a new contact) MUST use the same Session-ID value as the previous REGISTER requests 🫶 New Registrations, the ones that add or change the Contact URI for the AoR but don't simply delete them, MUST use a new Session-ID value 🧚 This follows the behavior of Call-ID per RFC 3261. It's getting repeated here because some devices incorrectly change their Call-ID value on every re-Registration, and they MUST NOT do the same to the Session-ID 💀 Not on my watch 😤

Last but absolutely not least, the UAC MUST include the Session-ID header field in every SIP message it transmits 👑

4.3. UAS Behavior 🌈

A UAS compliant with this document MUST copy a Session-ID header field (the one it received in a request) into responses and subsequent upstream requests sent within the dialog 🍓

If an out-of-dialog request shows up without a Session-ID header field, the UAS SHOULD generate a new one for subsequent use in the transaction and dialog, just like a UAC would, and then use that same value in all responses and upstream in-dialog requests for the same dialog ⭐

4.4. Proxy Behavior 🦋

A Proxy MUST NOT remove or modify the Session-ID header field it receives, if one is in the message 🙅‍♀️ By definition, a Proxy that's compliant with RFC 3261 wouldn't modify or remove that header anyway, so this is just being extra and I love that for us 💅

If the Proxy forks a request, it MUST copy the same Session-ID header field into all the forked request copies 🌸 If the Proxy recurses requests because of 3xx redirection, or regenerates requests because of failures, it MUST use the same Session-ID header field as the original request, just like the UAC does 🎀

If the Proxy locally generates any response or request based on a received request, including 100 Trying, it MUST insert any received Session-ID header field from the original request into the response message it locally creates. This is necessary for troubleshooting purposes, so no skipping this one bestie 🔥

A Proxy compliant with this document MAY generate a new Session-ID or insert a previously saved one if and only if none existed in a received message. It follows the rules for doing so as a B2BUA, as defined in Section 4.5 🧚

4.5. B2BUA Behavior 👑

A B2BUA compliant with this document MUST copy:

  • the Session-ID header field it receives in requests as a UAS into the related requests it generates as a UAC, and
  • any Session-ID header field it receives in responses as a UAC into the correlated responses it generates as a UAS.

If the B2BUA forks or creates multiple requests as a UAC from a request it received as a UAS, the B2BUA MUST copy the same Session-ID header field it received into all the forks/requests ✨ If the B2BUA recurses on 3xx responses, or regenerates requests due to failures, it MUST use the same Session-ID field, just as the UAC does 💖

If the B2BUA locally generates any response or request based on a received request, including 100 Trying, it MUST insert any received Session-ID field from the original request into the response message it locally creates 🫶

A B2BUA MAY remember the received Session-ID value for the duration of the transaction and dialog, for the purpose of reinsertion, in case the far end does not support this document 🦋

In all cases, if the SIP message received by a B2BUA contains a Session-ID header field, a B2BUA compliant with this document MUST NOT remove, modify, or replace it as it "forwards" the message on the other logical UA "side" of itself 🙈 Hands off the Session-ID, periodt 💅

4.5.1. B2BUA Generation of New Session-ID 🌸

If an out-of-dialog request is received by a B2BUA compliant with this document, and the request does not contain a Session-ID header field, the B2BUA MAY generate a new one 🧚 The new Session-ID value MUST be calculated based on the received Call-ID of the received request, even if the B2BUA uses a different Call-ID value for requests generated on its other "side(s)" 🔥 It MUST then insert the new Session-ID in any requests or responses it generates, as if it had actually received the new Session-ID from the UAC, following the rules previously defined for a B2BUA. This lets a B2BUA provide a migration to Session-ID deployment on behalf of upstream nodes that don't support it yet 🌈

As defined previously, if any received message already had a Session-ID, a B2BUA compliant with this document would not replace it 🎀

4.5.2. B2BUA Insertion of Saved Session-ID 🍓

If a Session-ID was received in an out-of-dialog request, or the B2BUA locally generated one because none existed, the B2BUA SHOULD insert the same Session-ID field into all responses and upstream in-dialog requests if and only if a Session-ID is not already in them ⭐ This lets a B2BUA provide a migration to Session-ID deployment on behalf of downstream nodes that don't support it yet ✨

5. Handling SIP Transfer Scenarios 🦋

Transfers and movement of SIP sessions are kind of a plot twist for a mechanism like Session-ID 😭 On one hand, the replacement SIP session is a brand new one, so you'd reasonably expect it to get a new Session-ID value. On the other hand, from a troubleshooting and human-user perspective, it's clearly related to, if not just a continuation of, the previous session 🫶 Since the whole point of this mechanism is to aid monitoring and troubleshooting, and it's not used for actual SIP protocol mechanics, the behavior defined in this section is to reuse the same Session-ID value for the replacement SIP session 💜

To make that happen, the Session-ID of the "original" session gets transferred too, in the Refer-To URI of a REFER request, as described in [RFC3515]. Out-of-dialog REFER and INVITE with Replaces requests, as described in [RFC3891], use the appropriate Session-ID values as well 🌸 This assumes, of course, that the UAs involved support the Session-ID mechanism. If they don't, it's possible the Session-ID won't be "carried forward" to the new SIP dialog. Unfortunately, that means troubleshooting such dialogs isn't improved or aided by this mechanism, but it wouldn't "break" anything at the SIP layer 🥲

It should also be noted that using the same Session-ID for the transferred-to dialog means the same Session-ID now exists in two independent dialogs 👀 That's because the original one may well continue due to the implicit Subscription usage created by a REFER. That implicit Subscription-based usage keeps using the same Session-ID as the new dialog created to the transferred-to party 🧚

In the following subsections, the term "UA" is used for User Agent. The language applies to the SIP device that creates the request, whether it's a UA or a B2BUA 🎀

5.1. Out-of-Dialog REFER 💖

A UA compliant with this document MUST use the same Session-ID header field value for an out-of-dialog REFER request it generates as the original dialog the REFER is targeted to (basically, as if the REFER had been in-dialog) ✨ For example, say UA Bob has a SIP dialog X to Alice, and Bob sends an out-of-dialog REFER to Alice to refer her to Charlie. The Session-ID header field value of that REFER request would be the same as the one used in dialog X 🫶

5.2. Refer-To URI 🍓

A UA compliant with this document MUST add the Session-ID header field as an embedded header in the Refer-To header field URI of any REFER request it generates, using the value of the session it's referring to 🔥 For example, say UA Bob has a SIP dialog X to Alice and dialog Y to Charlie, and Bob sends a REFER request to Alice to refer her to Charlie. The Session-ID header field value embedded in the Refer-To URI of that REFER request would be the same as the one used in dialog Y 🌈

5.3. Out-of-Dialog INVITE with Replaces 🌸

When generating an out-of-dialog INVITE with a Replaces header field, as described in [RFC3891], a UA compliant with this document MUST use the same Session-ID header field value for the INVITE request as the one used for the dialog it's replacing, if it knows the value 👑 Typically, the UA would know the value by having received it in the Refer-To header field of a REFER, as described previously 🦋 For example, say UA Bob has a SIP dialog X to Alice and dialog Y to Charlie, and Bob sends a REFER request to Alice to refer her to Charlie. The Session-ID header field value embedded in the Refer-To URI of that REFER request would be the one used in dialog Y, which Alice would then use as the Session-ID header field value for her INVITE to Charlie 💜

If the UA doesn't know the Session-ID of the dialog it's replacing, for example because it isn't embedded in the Refer-To URI of a received REFER, then it MUST use a new Session-ID value, calculated using the mechanism defined in Section 4.1 with the Call-ID of the INVITE 🧚

6. Session-ID Migration and Failure Scenarios 💀

SIP is already widely deployed on the Internet, so it's impractical to expect every UA to be upgraded to support this mechanism in the near future 😭 A solution for gradual migration is necessary, and this document provides one by letting B2BUAs or Proxies perform the Session-ID generator and inserter role 🌈 Even within those device types, it's impractical to expect all B2BUAs to support this mechanism all at once, or anytime soon. So it's expected that some B2BUAs and/or UAs will support generating and inserting Session-ID, while others won't support Session-ID at all 🫶

Because B2BUAs come in so many flavors (PBXs, SBCs, Application Servers, feature servers, and softswitches of various kinds) and there are so many SIP deployment models in use, there are going to be cases where Session-ID fails to be a consistent value for all related dialogs, or fails to successfully match 🙃 The goal of this document is to improve troubleshooting of current deployments as much as possible. In this author's opinion, that's the best that can be done given the constraints 🍓

One example is forked requests. If a UAC that doesn't support this mechanism sends a request to a Proxy or B2BUA that also doesn't support it, each fork could reach B2BUAs or UASs that do support this mechanism 👀 In that case, each of those forked-to B2BUA/UAS will generate unique Session-IDs and put them in their responses, which temporarily leads to multiple, different Session-ID values for the same related early dialogs. Typically, the UAC would eventually accept only one of the dialogs, and only one Session-ID would remain ✨

7. New 'Session-ID' Header 💜

This document adds the "Session-ID" token to the definition of the element "message-header" in the SIP message grammar 🎀 The Session-ID header is a single-instance header 🌸

7.1. Augmented BNF Definitions 📝

okay so here's the grammar, bestie 💅 the header is Session-ID, it takes one sess-id, and it can carry any number of generic-params after it 🎀

Session-ID           =  "Session-ID" HCOLON sess-id
                        *( SEMI generic-param )
sess-id              =  32(DIGIT / %x61-66)  ; 32 chars of [0-9a-f]

NOTE: the sess-id value is technically case-INSENSITIVE 🙈 but only lowercase characters are allowed. so write it lowercase, always 🍓

Also, see the Security Considerations section for the drama around using header parameters in Session-ID header fields 👀

8. Example Exchange 🦋

in this example, Alice starts a call to Bob 📞 and she makes the Session-ID header herself in the out-of-dialog INVITE 💖

Alice sends this (heads up, lots got left out to keep it simple 🙈):

INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.1:5060;branch=z9hG4bKnashds10
From: Alice <sip:alice@example.net>;tag=1234567
To: Bob <sip:bob@example.com>
Call-Id: 123456mcmxcix@1.2.3.4
Session-ID: f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 1 INVITE
Contact: <sip:alice@192.168.1.1>

9. Security Considerations 💀

ok this part is serious, so pay attention 🫶 there are a few security things going on with this mechanism

the Session-ID generation algorithm should give you a reasonably random 32-character value so you dodge collisions, and it should not let anyone rebuild the original Call-ID. that would be a whole mess 😭

there's no known security issue with looking at or changing the Session-ID, except it can make troubleshooting harder. annoying, but not a disaster ✨

9.1. Security Considerations for Administrators 🧑‍💻

the whole point of the Session-ID is to be an identifier that a recipient can't use to figure out whether middleboxes changed the Call-ID 🕵️‍♀️ so a UAS or UAC can't see the original Call-ID, and can't tell if it got changed. which means admins shouldn't stress if the Session-ID header field gets "passed through" 💜

9.2. Security Considerations for Session-ID Extensions 🔐

here's the tea ☕ the Session-ID value is made from the Call-ID using a hashing mechanism based on [RFC2104], with SHA-1 and a secret key that only the generating system knows. because the algorithm is defined in this document, it should be pretty hard to figure out who generated the Session-ID (manufacturer, code base, all that) 🌸

the algorithm should also give a reasonably random 128-bit Session-ID value, so you avoid collisions and nobody can rebuild the original Call-ID 💅 and the secret key MUST only be used for the Session-ID mechanism, just in case someone finds a weakness that reveals the key 😱 one possible weakness is a UAC generating one or more Call-IDs that make the key easier to figure out, so be careful 🙈

ngl B2BUAs are a wild card 🃏 standards can't really dictate what they do. they do whatever their owners or operators want, or whatever keeps their apps working. this document tries to normatively pin down some B2BUA behavior by making a SIP header value with properties that give B2BUAs no good reason to mess with it ✨ basically it's a promise that future uses of this Session-ID header field, including its value and any future defined parameters, keep this harmless quality 🫶 any future extensions to the Session-ID mechanism and header field MUST maintain this property, or else B2BUAs will start changing it again or removing it, and its value will be lost 😭

manufacturers of SIP devices, listen up 📣 a B2BUA may inspect the Session-ID header field and may remove it if it doesn't follow this document's value restrictions. also, any Session-ID header parameters MUST be registered with IANA and documented in RFCs from the IETF stream, following the requirements of [RFC3968] 🎀

10. IANA Considerations 📋

IANA has registered a new SIP header field called 'Session-ID' 🎉 following the registration policies for that kind of thing in [RFC5727]. it's a single-instance header field, and it's fine for any SIP message, any Method type, in any request or response ✨

the ABNF rules [RFC5234] for this new header allow header parameters 💖 but they must be registered following the rules of [RFC3968], as [RFC5727] requires 🫶

this registration is meant to be temporary 🦋 the author expects a Standards Track definition of Session-ID to get published at some point. once that document exists, it will replace this registration with a reference to itself, and at that point this document won't be referenced by IANA anymore 🌈

11. Acknowledgments 🫶

huge thanks to Raphael Coeffic, Bob Penfield, Dale Worley, Paul Kyzivat, Ian Elz, Marco Stura, Martin Dolly, Martin Huelsemann, Laura Liess, and Adam Roach for their input 💜✨

12. References 📚

12.1. Normative References

  • [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
  • [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
  • [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
  • [RFC3968] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
  • [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
  • [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.

12.2. Informative References

  • [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
  • [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
  • [RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, June 2007.

Appendix A. Use Cases Not in Scope for Session-ID 🚫

it's SO tempting to use a header field value like the one Session-ID gives you for other stuff besides troubleshooting 👀 in an earlier document for this same Session-ID concept, the proposal did include other uses 🙈 but those got cut, because any use other than troubleshooting can easily make a B2BUA need to change the value in certain cases. and that would wreck the troubleshooting value of Session-ID 😭 this section talks about those use cases and explains why they could be harmful 💅

A.1. Dialog Correlation for SIP 🦋

okay so Session-ID does help you correlate separate SIP dialogs, messages, and transactions, but it does that at a higher layer than SIP itself 💅 It does NOT replace the usual SIP stuff with Call-ID and To/From tags for correlating dialogs, and it doesn't replace Replaces headers or dialog-event packages either. ngl it's super tempting to use it for exactly that in some cases 🙈

Let's look at a call transfer case. Alice calls Bob through B2BUA-1. Then Bob calls Charlie and sends Charlie a REFER with an embedded Replaces, so Charlie sends Alice an INVITE with a Replaces header to swap out the Alice-Bob session. But if Charlie reaches Alice through a different B2BUA-2, the INVITE with Replaces just fails 💀 The Call-ID/tags won't match anything that B2BUA-2 or Alice knows about.

   +-----+     +-------+    +-------+    +-----+     +-------+
   |Alice|     |B2BUA-1|    |B2BUA-2|    | Bob |     |Charlie|
   +-----+     +-------+    +-------+    +-----+     +-------+
      |            |            |           |            |
      |INVITE      |            |           |            |
      |callid:1a   |callid:1b   |           |            |
      |----------->|----------------------->|INVITE      |
      |sessid:1    |sessid:1    |           |callid:2a   |
      |            |            |           |----------->|
      |            |            |           |sessid:2    |
      |            |            |           |            |
      |            |            |           |REFER       |
      |            |            |           |referto:1b  |
      |            |            |           |----------->|
      |            |            |           |            |
      |            |            |           |      INVITE|
      |            |            |           | replaces:1b|
      |            |            X<-----------------------|
      |            |      INVITE|           |    sessid:1|
      |            | replaces:1b|           |            |
      X<------------------------|           |            |
      |            |    sessid:1|           |            |

                 Example 1: Call Transfer Case

Now, if Alice used the Session-ID value to correlate, she'd see it matches her dialog with Bob (assuming the Session-ID got passed along in the Refer-To and Replaces info). ✨

BUT there are problems with this approach, bestie 😭 The first one: because the INVITE with Replaces never gets sent to B2BUA-1, B2BUA-1 ends up in the wrong state. The dialog is getting replaced and the B2BUA has no idea 🙃

The second issue is that Session-ID just doesn't identify enough info to replace a dialog. Picture a third B2BUA, like a softswitch, sitting between Alice and both B2BUA-1 and B2BUA-2, and the INVITE with Replaces hits the softswitch before it gets to Alice. The softswitch won't know which "side" the INVITE is replacing 😵‍💫 The To/From tags don't match anything it knows, so it can't tell if the INVITE is replacing the dialog from softswitch to Alice or the one to Bob. And if we tried fixing that by making a tag-type value pair for Session-ID, we'd be right back to devices changing those tag values, which defeats the whole matching property 🥲

Here's another example, based on 3GPP 24.605 Annex A.2.2. Alice has a call with Bob going through multiple B2BUAs and an Application Server (AS). All the dialogs in that call share the same Session-ID, but each one has its own unique Call-ID/tags 🧚

Alice wants to bring in a third-party conference facility on the AS and reference her call with Bob for that. In this particular 3GPP scenario, she sends a brand new INVITE to the AS with a resource-list body (a la RFC 5366) that contains the call info for the original call. That's the "RL<sessid:1>" piece in the diagram. It also has Call-ID/tags, but those'll be wrong by the time they reach the AS 🙈

The AS processes that list. It can't match the Call-ID/tags in the resource-lit, but it does match the Session-ID, so it sends a re-INVITE to party B inside the original call's dialog. slay 💖

   +-----+     +-------+      +----+    +-------+     +-----+
   |Alice|     |B2BUA-1|      | AS |    |B2BUA-2|     | Bob |
   +-----+     +-------+      +----+    +-------+     +-----+
      |            |            |           |            |
      |INVITE      |            |           |            |
      |callid:1a   |callid:1b   |callid:1c  |callid:1d   |
      |----------->|----------->|---------->|----------->|
      |sessid:1    |sessid:1    |sessid:1   |sessid:1    |
      |            |            |           |            |
      |INVITE      |            |           |            |
      |callid:2a   |callid:2b   |           |            |
      |----------->|----------->|           |            |
      |sessid:2    |sessid:2    |re-INVITE  |            |
      |RL<sessid:1>|RL<sessid:1>|callid:1c  |callid:1d   |
      |            |            |---------->|----------->|
      |            |            |sessid:1   |sessid:1    |
      |            |            |           |            |

                    Example 2: Resource List

Author's Address 🎀

Hadriel Kaplan Oracle EMail: hadrielk@yahoo.com

📦 where this page comes from