RFC 8498

A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)

📅 published February 2019, from ietf

RFC 8498 💖 A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)

Okay bestie, here's the deal: this one's from the Internet Engineering Task Force (IETF), written by M. Mohali at Orange 🍊, dated February 2019. It's Informational 🎀, which means it's shared for info and is not a Standards Track spec. It also has an ISSN of 2070-1721 ✨. It updates RFC 5502 🦋, and its header doesn't list anything it obsoletes.

Abstract 🌸

Okay so the P-Served-User header field came from a 3GPP IMS (IP Multimedia Subsystem) requirement 📞. Its whole job is to carry the identity of the served user, their registration state, and the session case that applies to that call and that application invocation. A session case is basically metadata about a served user's session, whether or not they're registered and whether the session starts or ends with them 💅.

This doc updates RFC 5502 by adding a new P-Served-User parameter called orig-cdiv 🦋. It tells a proxy which session case it's using when it handles an originating session after Call Diversion (CDIV) services have been invoked for the served user. It also fixes the ABNF in RFC 5502 🛠️ and gives more guidance on using P-Served-User in IP networks 🌈.

Status of This Memo ✨

This doc is not an Internet Standards Track spec. It's published for info purposes only 🎀.

It's a product of the IETF, so it reflects what the IETF community agreed on. It 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 7841 if you want the details 🔍.

For the current status, any errata, and how to give feedback, head to https://www.rfc-editor.org/info/rfc8498 💜.

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved 🌸.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📜. Code Components pulled out of this doc must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🧚.

This doc may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈. Unless you get an adequate license from those copyright holders, this doc may not be modified outside the IETF Standards Process, and derivative works may not be created outside it. The one exception is formatting it for publication as an RFC or translating it into languages other than English 🌈.

Table of Contents 🎀

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.2.  Basic Use Case  . . . . . . . . . . . . . . . . . . . . .   4
     1.3.  Problem Statement . . . . . . . . . . . . . . . . . . . .   5
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   5
   3.  Applicability . . . . . . . . . . . . . . . . . . . . . . . .   6
   4.  Proxy Behavior and Parameter Handling . . . . . . . . . . . .   6
   5.  Clarification of RFC 5502 Procedures  . . . . . . . . . . . .   7
   6.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Call Flow Examples  . . . . . . . . . . . . . . . . . . . . .   9
     7.1.  Call Diversion Case . . . . . . . . . . . . . . . . . . .   9
     7.2.  Call Diversion and Privacy  . . . . . . . . . . . . . . .  11
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     10.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  15
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  15

1. Introduction ✨

1.1. General 🌷

The P-Served-User header field [RFC5502] was defined because of a requirement from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia Subsystem) 📱. Its purpose is to convey the identity of the served user, their registration state, and the session case between a Serving Call Session Control Function (S-CSCF) and an Application Server (AS) on the IMS Service Control (ISC) interface 🛰️. A session case is metadata that captures the status of a served user's session, whether or not they're registered and whether the session originates or terminates with them. For more on session cases and the IMS, check out [TS.3GPP.24.229] 📚.

[RFC5502] defines the originating and terminating session cases for a registered or unregistered user 💜. This document extends P-Served-User to include the session case for a forwarded leg, when a CDIV service has been invoked and an originating service of the diverting user has to be triggered 🦋.

The sessioncase-param parameter of P-Served-User gets extended with the orig-cdiv parameter for this originating-after-CDIV session case 🎀.

Here's the roadmap 🗺️. Section 3 covers the applicability and scope of this new header field parameter, and Section 4 specifies the proxy behavior for handling it. Section 5 clarifies some of the [RFC5502] procedures. Section 6 describes the extended syntax and corrects the syntax of [RFC5502]. Section 7 gives some call flow examples, and Section 8 registers the P-Served-User header field parameters with IANA 📝. Section 9 discusses the security properties of the environment where this new parameter is meant to be used 🔐. The section that defines usage of the orig-cdiv parameter comes right after this one, so keep reading 💖.

1.2. Basic Use Case 🍓

In the 3GPP IMS, the S-CSCF (Serving CSCF) is a SIP proxy that acts as a registrar and handles the originating and terminating session states for the users assigned to it 👑. That means any call originated by a specific user, or any call terminated to that user, goes through the S-CSCF assigned to them 📞.

The moment an S-CSCF gets assigned to a specific user, the user profile is downloaded from the Home Subscriber Server (HSS) to that S-CSCF; see [TS.3GPP.29.228] 📥. The user profile holds the list of actions the S-CSCF takes for the served user, depending on the session direction (originating or terminating) and the user state (registered or not) in the IMS network 🧾. With that profile, the S-CSCF figures out the current case and applies the matching actions, like forwarding the request to an AS 🚀. The AS then goes through a similar process to work out who the current served user is, what their "registration state" is, and what the "session case" of the session is 🤓. [RFC5502] defines all of those parameters, and in particular the originating and terminating session cases 💅.

In basic call scenarios, the S-CSCF and AS have no real trouble knowing which scenario needs to happen 😌. But with CDIV services, where the session gets re-targeted, the session cases defined in [RFC5502] pose some limitations, as the next section explains 😭.

1.3. Problem Statement 🙈

Let's picture this, bestie 🫶. Alice is trying to call Bob, and Bob has a CDIV service activated toward Carol's address 📲. With a CDIV service, the received request is first treated as a terminating session case (on Bob's side), so the terminating filter criteria configured in the S-CSCF get performed 🔍. A filter criteria is information in the user profile that determines whether an initial request is sent to a particular AS 🧩. When the AS gets the call initiation request, it can figure out the served user (Bob) and the session case (here "term") from the received P-Served-User header field content, and it can run the terminating services 🎬.

When the CDIV service runs (as a terminating service of Bob), the AS changes the target (Request-URI) of the session to Carol's address, and a new call leg gets created 🦋. The served user becomes the diverting user ✨. This new call leg could be considered an originating call leg from the diverting user (Bob), but it isn't 🙅‍♀️. The originating user is still Alice, and some of the diverting user's originating services shouldn't be triggered as if this were an originating call 😤.

For example, the originating user identity (Alice) shouldn't be restricted just because the diverting user (Bob) has a privacy service for his own identity 🔒. The privacy of the diverting user should apply only to information related to that user (for instance, in the History-Info header field) 💜. In the same way, some specific services need to be triggered on the outgoing leg after a CDIV 🌈. Without a dedicated session case for originating-after-CDIV, the S-CSCF can't trigger an originating service for the diverting user, and an AS can't execute the procedures for this particular session case 💀.

For this use case, this document creates a new parameter (orig-cdiv) for the originating-after-CDIV session case, to be embedded in the P-Served-User header field 🎀.

2. Conventions and Terminology 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💅.

3. Applicability 🌸

The use of the P-Served-User header field extensions is only applicable inside a Trust Domain [RFC3324] for the P-Served-User header field 🏰. Nodes in such a Trust Domain explicitly trust each other to convey the served user, and they're responsible for keeping that information from leaking outside the Trust Domain 🤝. The means by which the network determines the served user, and the policies executed for a specific served user, are outside the scope of this document 🙌.

4. Proxy Behavior and Parameter Handling ✨

okay so this section shows how this header field parameter actually gets used in a 3GPP network 🧚 let's walk through a terminating call step by step bestie 💖

For a terminating call, the following steps will be followed:

  1. The S-CSCF receives the initial INVITE request for a terminating call and determines that the session case is for a terminating user as described in [RFC5502]. 📞
  2. The S-CSCF determines who the served user is by looking at the Request-URI and saves the current Request-URI. 👀
  3. The S-CSCF analyzes the filter criteria. Then it sends the request to the AS of the served user as an INVITE that includes the P-Served-User header field, with the "sescase" parameter set to "term" and the "regstate" set to the matching value, so that terminating services get triggered 🔥
  4. Based on some criteria, the AS decides the request has to be diverted to another target user or application 💅 It replaces the received Request-URI with the new diverted-to address and stores the successive Request-URI(s) values by adding one or two History-Info header field entry(ies) [RFC7044] in the outgoing INVITE. In the History-Info header field, the served user address gets tagged using the mp-param header field parameter, which is added in the newly created entry that contains the diverted-to address. Then the AS forwards the INVITE request back to the S-CSCF. 🦋
  5. When the INVITE comes back, the S-CSCF can see that the topmost Route header field contains its own hostname, but the Request-URI does not match the saved Request-URI. So the S-CSCF updates the P-Served-User header field content by replacing the "sescase" parameter with the "orig-cdiv" parameter. The P-Served-User header field value stays unchanged. 🌸
  6. The S-CSCF forwards the INVITE request to an AS that hosts the served user's (diverting user's) originating services, which need to be executed on the forwarded leg after a CDIV service. 🎀
  7. When the AS receives the INVITE request, it sees that the session case is "orig-cdiv" and runs the originating services that should be executed after retargeting, for the diverting user (aka the served user). It's giving main character energy ✨👑

5. Clarification of RFC 5502 Procedures

okay so this part is a little clarification moment 🫶 the document gives some guidance for handling the P-Served-User header field, because [RFC5502] doesn't really cover this case:

  • The P-Served-User header field MUST NOT be repeated within a request for a particular session at a particular time, for the reason that session cases are mutually exclusive. This document updates [RFC5502] to clearly state that the P-Served-User header field MUST NOT contain multiple values, either comma-separated or header-separated. This document also updates the syntax of the header from [RFC5502] to reflect this uniqueness of parameter values. 🔒
  • [RFC5502] does not clearly state what to do with the received P-Served-User header field when a call gets diverted to another destination 😭 This document points out that there are a few ways to handle it: the S-CSCF could store the previous "regstate" value and decide that the same value applies, the "regstate" may no longer be relevant after a diverting service so the S-CSCF removes it, or the "regstate" could be combined with the "orig-cdiv" session case to give different services depending on whether the served user is registered or unregistered. These choices are implementation dependent. 🧠💜

6. Syntax

6.1. General

[RFC5502] defines the P-Served-User header field with the sessioncase-param parameter sescase, which is specified as having orig and term as predefined values. This document defines an additional parameter, orig-cdiv, for the sessioncase-param. 🍓

Because this document extends the existing sessioncase-param parameter, and because errors have been identified in the syntax, this document corrects and extends the P-Served-User header field. Bestie, that's a glow-up with receipts 💅✨

The extension of the sessioncase-param parameter to add the orig-cdiv session case is done in a way that fits the parameter format introduced in Release 11 of the 3GPP [TS.3GPP.24.229] and maintains backward compatibility. 🫶

EQUAL, HCOLON, SEMI, name-addr, addr-spec, and generic-param are defined in [RFC3261]. 📖

If the addr-spec contains a comma, question mark, or semicolon, the name-addr form MUST be used. The name-addr form requires the use of angle brackets (< and >). 🌈

6.2. ABNF

The Augmented Backus-Naur Form (ABNF) [RFC5234] syntax of the P-Served-User header field is described in [RFC5502]. 🦋

This document updates [RFC5502] to correct the P-Served-User header field ABNF syntax and extend it as follows:

P-Served-User            = "P-Served-User" HCOLON PServedUser-value
                           *(SEMI served-user-param)
served-user-param        = sessioncase-param
                           / registration-state-param
                           / generic-param
PServedUser-value        = name-addr / addr-spec
sessioncase-param        = "sescase" EQUAL ("orig"/"term")/ orig-cdiv
registration-state-param = "regstate" EQUAL ("unreg" / "reg")
orig-cdiv                = "orig-cdiv"

Examples of possible P-Served-User header fields:

P-Served-User: <sip:user@example.com>; orig-cdiv; regstate=reg
or
P-Served-User: <sip:user@example.com>; orig-cdiv
or
P-Served-User: <sip:user@example.com>; sescase=term; regstate=unreg

This document allows choosing between addr-spec and name-addr when constructing the header field value. As specified in RFC 8217, the addr-spec form MUST NOT be used if its value would contain a comma, semicolon, or question mark [RFC8217]. Be careful with those little punctuation marks, besties 🙈🎀

7. Call Flow Examples

7.1. Call Diversion Case

Okay this is my favorite part 😭 The following call flow shows a session establishment when Alice calls Bob, who has a CDIV service that diverts to Carol when Bob is busy. It's literally a whole drama 🍿

                  proxy           server            UA
Alice    Bob's...S-CSCF-B..........AS-B.............Bob            Carol
  |                |                |                |                |
  |   INVITE F1    |                |                |                |
  |--------------->|   INVITE F2    |                |                |
  |                |--------------->|                |                |
  |                |   INVITE F3    |                |                |
  |                |<---------------|  INVITE F4     |                |
  |                |-------------------------------->|                |
  |                |                486   F5         |                |
  |                |<--------------------------------|                |
  |                |    486   F6    |                |                |
  |                |--------------->|                |                |
  |                |   INVITE F7    |                |                |
  |                |<---------------|                |                |
  |                |   INVITE F8    |                |                |
  |                |--------------->|                |                |
  |                |   INVITE F9    |                |                |
  |                |<---------------|      INVITE F10                 |
  |                |------------------------------------------------->|
  |                |                |                |                |
  |                |                |                |    180   F11   |
  |                |                |    180   F12   |<---------------|
  |                |    180   F13   |<---------------|                |
  |    180   F14   |<---------------|                |                |
  |<---------------|                |                |                |
  |                |                |                |                |

[Alice calls Bob]

F1 INVITE Alice -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>

F2 INVITE S-CSCF-B -> AS-B
INVITE sip:bob@example.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>
     P-Served-User: <sip:bob@example.com>; term; regstate=reg

F3 INVITE AS-B -> S-CSCF-B
INVITE sip:bob@example.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>
     P-Served-User: <sip:bob@example.com>; term; regstate=reg

F4 INVITE S-CSCF-B -> Bob
INVITE sip:bob@192.0.2.4 SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>
     P-Served-User: <sip:bob@example.com>; term; regstate=reg

[Bob is busy. His CDIV when busy is invoked towards Carol]

F5-F6 486 BUSY Bob -> S-CSCF-B  -> AS-B
486 BUSY
 From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>;tag=es43sd

[Alice's call is diverted to Carol]

F7 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>
     P-Served-User: <sip:bob@example.com>; term; regstate=reg

[The forwarded leg to Carol is identified as an originating call after CDIV, which should not trigger all of Bob's originating services]

F8 INVITE S-CSCF-B -> AS-B
INVITE sip:carol@domainc.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>
     P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg

F9 INVITE AS-B -> S-CSCF-B
INVITE sip:carol@domainc.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>
     P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg

F10 INVITE S-CSCF-B -> Carol
INVITE sip:carol@192.0.2.7 SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>

Figure 1. P-Served-User During CDIV Service 🦋✨

7.2. Call Diversion and Privacy 🎀

okay so this one is giving privacy drama 💅 Alice has no identity restriction service (so she's showing up with her name), and Bob has an unconditional CDIV service sending calls to Carol, plus an identity presentation restriction service on his side. Let's see how it plays out 🍓

Call flow overview:

                  proxy           server            UA
Alice    Bob's...S-CSCF-B..........AS-B.............Bob            Carol
  |                |                |                |                |
  |   INVITE F1    |                |                |                |
  |--------------->|   INVITE F2    |                |                |
  |                |--------------->|                |                |
  |                |   INVITE F3    |                |                |
  |                |<---------------|                |                |
  |                |   INVITE F4    |                |                |
  |                |--------------->|                |                |
  |                |   INVITE F5    |                |                |
  |                |<---------------|      INVITE F6 |                |
  |                |------------------------------------------------->|
  |                |                |                |                |
  |                |                |                |    180   F7    |
  |                |                |    180   F8    |<---------------|
  |                |    180   F9    |<---------------|                |
  |    180   F10   |<---------------|                |                |
  |<---------------|                |                |                |
  |                |                |                |                |

[Alice calls Bob]

F1 INVITE Alice -> S-CSCF-B

INVITE sip:bob@example.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>
     Supported: histinfo

F2 INVITE S-CSCF-B -> AS-B

INVITE sip:bob@example.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Bob <sip:bob@example.com>
     P-Served-User: <sip:bob@example.com>; term; regstate=reg

[Bob's unconditional CDIV to Carol is triggered]

F3 INVITE AS-B -> S-CSCF-B

INVITE sip:carol@domainc.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Carol <sip:carol@domainc.com>
     P-Served-User: <sip:bob@example.com>; term; regstate=reg
     History-Info:
             <sip:bob@example.com>;index=1,
             <sip:carol@domainc.com;cause=302>;index=1.1;mp=1

[Alice's call is diverted to Carol]

F4 INVITE S-CSCF-B -> AS-B

INVITE sip:carol@domainc.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Carol <sip:carol@domainc.com>
     P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
     History-Info:
             <sip:bob@example.com>;index=1,
             <sip:carol@domainc.com;cause=302>;index=1.1;mp=1

F5 INVITE AS-B -> S-CSCF-B

INVITE sip:carol@domainc.com SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Carol <sip:carol@domainc.com>
     P-Served-User: <sip:bob@example.com>; orig-cdiv; regstate=reg
     History-Info:
             <sip:bob@example.com?privacy=history>;index=1,
             <sip:carol@domainc.com;cause=302>;index=1.1;mp=1

[Forwarded leg to Carol is identified as an originating call after CDIV that allows Bob's privacy service to be applied to his identity within the History-Info header field]

F6 INVITE S-CSCF-B -> Carol

INVITE sip:carol@192.0.2.7 SIP/2.0
     From: Alice <sip:alice@domaina.com>;tag=1928301774
     To: Carol <sip:carol@domainc.com>
     History-Info:
             <sip:bob@example.com?privacy=history>;index=1,
             <sip:carol@domainc.com;cause=302>;index=1.1;mp=1
             <sip:carol@192.0.2.7>;index=1.1.1;rc=1.1

Figure 2. P-Served-User When Privacy Requested ✨

8. IANA Considerations 📚

The syntax of the P-Served-User header field [RFC5502] is updated in Section 4 of this document. 🦋

IANA has updated the existing row for the P-Served-User header field in the "Header Fields" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry:

       Header Name        Compact Form          Reference
      -------------       ------------     ------------------
      P-Served-User          none          [RFC5502][RFC8498]

IANA has added new rows for the P-Served-User header field parameters in the "Header Field Parameters and Parameter Values" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry (as per the registry created by [RFC3968]):

 Header Field   Parameter Name    Predefined Values    Reference
--------------  ----------------  -----------------  -------------
P-Served-User     sescase              Yes             [RFC5502]
P-Served-User     regstate             Yes             [RFC5502]
P-Served-User     orig-cdiv            No              [RFC8498]

9. Security Considerations 🔐

Okay, this section is serious business, bestie 💀 The security considerations in [RFC5502] apply. 💜

The "orig-cdiv" parameter of the P-Served-User header field can be used to trigger applications when a call is diverted, so it is super important to make sure that the parameter has not been added to the SIP message by an unauthorized SIP entity. 🚨 So the P-Served-User header field is to be used in a trusted environment, and proxies MUST NOT insert the header unless they have sufficient knowledge that the route set includes another trusted proxy. No sneaking it in, periodt 🙅‍♀️

10. References 📖

10.1. Normative References

10.2. Informative References

  • [TS.3GPP.24.229] 3GPP, "IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3", 3GPP TS 24.229 11.28.0, December 2018.
  • [TS.3GPP.29.228] 3GPP, "IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents", 3GPP TS 29.228 15.1.0, September 2018.

Acknowledgments 🫶

The author wishes to thank the 3GPP community for providing guidance, input, and comments on the document. Thanks to Dale Worley, Jean Mahoney, and Ben Campbell for their careful review of the document. Thanks to Paul Kyzivat and Adam Roach. A special thanks to Christer Holmberg 💖

Author's Address 🌸

Marianne Mohali Orange Orange Gardens, 44 avenue de la Republique Chatillon 92326 France

Email: marianne.mohali@orange.com

📦 where this page comes from