doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc8498.txt b/doc/rfc/rfc8498.txt
new file mode 100644
index 0000000..b254fe8
--- /dev/null
+++ b/doc/rfc/rfc8498.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         M. Mohali
+Request for Comments: 8498                                        Orange
+Updates: 5502                                              February 2019
+Category: Informational
+ISSN: 2070-1721
+
+
+             A P-Served-User Header Field Parameter for an
+         Originating Call Diversion (CDIV) Session Case in the
+                   Session Initiation Protocol (SIP)
+
+Abstract
+
+   The P-Served-User header field was defined based on a requirement
+   from the 3rd Generation Partnership Project (3GPP) IMS (IP Multimedia
+   Subsystem) in order to convey the identity of the served user, his/
+   her registration state, and the session case that applies to that
+   particular communication session and application invocation.  A
+   session case is metadata that captures the status of the session of a
+   served user regardless of whether or not the served user is
+   registered or the session originates or terminates with the served
+   user.  This document updates RFC 5502 by defining a new P-Served-User
+   header field parameter, "orig-cdiv".  The parameter conveys the
+   session case used by a proxy when handling an originating session
+   after Call Diversion (CDIV) services have been invoked for the served
+   user.  This document also fixes the ABNF in RFC 5502 and provides
+   more guidance for using the P-Served-User header field in IP
+   networks.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are candidates for any level of Internet
+   Standard; see Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8498.
+
+
+
+
+
+
+
+Mohali                        Informational                     [Page 1]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+Copyright Notice
+
+   Copyright (c) 2019 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
+   (https://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as 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 are provided without warranty as
+   described in the Simplified BSD License.
+
+   This document 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 this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mohali                        Informational                     [Page 2]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+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 based on a
+   requirement from the 3rd Generation Partnership Project (3GPP) IMS
+   (IP Multimedia Subsystem) in order to convey the identity of the
+   served user, his/her 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 the session of a served
+   user regardless of whether or not the served user is registered or
+   the session originates or terminates with the served user.  For more
+   information on session cases and the IMS, a detailed description can
+   be found in [TS.3GPP.24.229].
+
+   [RFC5502] defines the originating and terminating session cases for a
+   registered or unregistered user.  This document extends the P-Served-
+   User header field to include the session case for a forwarded leg
+   when both a CDIV service has been invoked and an originating service
+   of the diverting user has to be triggered.
+
+
+
+
+
+
+Mohali                        Informational                     [Page 3]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+   The sessioncase-param parameter of the P-Served-User header field is
+   extended with the "orig-cdiv" parameter for this originating-after-
+   CDIV session case.
+
+   The following section defines usage of the "orig-cdiv" parameter of
+   the P-Served-User header field, Section 3 discusses the applicability
+   and scope of this new header field parameter, and Section 4 specifies
+   the proxy behavior for handling the new header field parameter.
+   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, Section 8 registers the
+   P-Served-User header field parameters with IANA, and Section 9
+   discusses the security properties of the environment where this new
+   header field parameter is intended to be used.
+
+1.2.  Basic Use Case
+
+   In the 3GPP IMS (IP Multimedia Subsystem), the S-CSCF (Serving CSCF)
+   is a SIP proxy that serves as a registrar and handles originating and
+   terminating session states for users assigned to it.  This means that
+   any call that is originated by a specific user or any call that is
+   terminated to that specific user will pass through the S-CSCF that is
+   assigned to that user.
+
+   At the moment that an S-CSCF is 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 contains the list of
+   actions to be taken by the S-CSCF for the served user depending on
+   the session direction (originating or terminating) and the user state
+   (registered or not) in the IMS network.  With this user profile, the
+   S-CSCF determines the current case and applies the corresponding
+   actions such as forwarding the request to an AS.  The AS then goes
+   through a similar process of determining who is the current served
+   user, what is his/her "registration state", and what is the "session
+   case" of the session.  [RFC5502] defines all those parameters and in
+   particular the originating and terminating session cases.
+
+   In basic call scenarios, there is no particular issue for the S-CSCF
+   and AS to know which scenario needs to be realized, but in case of
+   CDIV services for which the session is re-targeted, the session cases
+   defined in [RFC5502] pose some limitations as described in the
+   following section.
+
+
+
+
+
+
+
+
+
+Mohali                        Informational                     [Page 4]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+1.3.  Problem Statement
+
+   To illustrate the problem statement, let's imagine Alice trying to
+   call Bob and Bob having a CDIV service activated towards Carol's
+   address.  In the case of a CDIV service, the received request is
+   first treated as a terminating session case (at Bob's side), and the
+   terminating filter criteria configured in the S-CSCF is 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
+   receives the call initiation request, the AS is able to determine the
+   served user (Bob) and the session case (here "term") from the
+   received P-Served-User header field content and is able to execute
+   terminating services.  When the CDIV service is executed (as a
+   terminating service of Bob), the AS changes the target (Request-URI)
+   of the session (toward Carol's address) and a new call leg is
+   created.  The served user becomes the diverting user.  This new call
+   leg could be considered as an originating call leg from the diverting
+   user (Bob), but this is not the case.  Indeed, the originating user
+   remains the same (Alice), and some of the diverting user's
+   originating services should not be triggered as if it was an
+   originating call.  For instance, the originating user identity
+   (Alice) should not be restricted because the diverting user (Bob) has
+   a privacy service for his own identity.  The privacy of the diverting
+   user should apply to information related to this user only (e.g., in
+   the History-Info header field).  In the same manner, some specific
+   services will need to be triggered on the outgoing leg after a CDIV.
+   Without a dedicated session case for originating-after-CDIV, the
+   S-CSCF cannot trigger an originating service for the diverting user,
+   nor can an AS 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.
+
+
+
+
+
+
+
+
+
+Mohali                        Informational                     [Page 5]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+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 to be responsible for withholding
+   that information outside of the Trust Domain.  The means by which the
+   network determines the served user and the policies that are executed
+   for a specific served user is outside the scope of this document.
+
+4.  Proxy Behavior and Parameter Handling
+
+   The following section illustrates how this header field parameter can
+   be used in a 3GPP network.
+
+   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 is the served user by looking at the
+       Request-URI and saves the current Request-URI.
+
+   3.  The S-CSCF analyzes the filter criteria.  It then 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 corresponding value in
+       order to trigger execution of terminating services.
+
+   4.  Based on some criteria, the AS concludes that the request has to
+       be diverted to another target user or application.  The AS
+       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 is tagged by using the mp-param header field
+       parameter added in the newly created entry that contains the
+       diverted-to address.  The AS forwards the INVITE request back to
+       the S-CSCF.
+
+   5.  When receiving back the INVITE request, 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.  In this case,
+       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 remains unchanged.
+
+
+
+
+Mohali                        Informational                     [Page 6]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+   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 determines that the
+       session case is for the "orig-cdiv" session case and performs the
+       originating services to be executed after retargeting for the
+       diverting user (i.e., served user).
+
+5.  Clarification of RFC 5502 Procedures
+
+   This document provides the following guidance for the handling of the
+   P-Served-User header field that is missing in [RFC5502]:
+
+   o  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.
+
+   o  [RFC5502] does not clearly state what to do with the received
+      P-Served-User header field when a call is diverted to another
+      destination.  This document highlights that there are several ways
+      of handling the P-Served-User header field: 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 provide
+      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.
+
+
+
+
+Mohali                        Informational                     [Page 7]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+   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 the following:
+
+   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].
+
+
+
+
+
+
+
+
+
+Mohali                        Informational                     [Page 8]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+7.  Call Flow Examples
+
+7.1.  Call Diversion Case
+
+   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.
+
+                  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
+
+
+
+Mohali                        Informational                     [Page 9]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+   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
+
+
+
+Mohali                        Informational                    [Page 10]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+7.2.  Call Diversion and Privacy
+
+   The following call flow shows a CDIV use case for which Alice has no
+   identity restriction service and Bob has an unconditional CDIV
+   service towards Carol and an identity presentation restriction
+   service.
+
+                  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
+
+
+
+
+
+
+
+
+
+
+Mohali                        Informational                    [Page 11]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+[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
+
+
+
+
+
+
+Mohali                        Informational                    [Page 12]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+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
+
+   The security considerations in [RFC5502] apply.
+
+   As the "orig-cdiv" parameter of the P-Served-User header field can be
+   used to trigger applications when a call is diverted, it is important
+   to ensure that the parameter has not been added to the SIP message by
+   an unauthorized SIP entity.  Thus, 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mohali                        Informational                    [Page 13]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+10.  References
+
+10.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,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3324]  Watson, M., "Short Term Requirements for Network Asserted
+              Identity", RFC 3324, DOI 10.17487/RFC3324, November 2002,
+              <https://www.rfc-editor.org/info/rfc3324>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8217]  Sparks, R., "Clarifications for When to Use the name-addr
+              Production in SIP Messages", RFC 8217,
+              DOI 10.17487/RFC8217, August 2017,
+              <https://www.rfc-editor.org/info/rfc8217>.
+
+   [RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
+              (IANA) Header Field Parameter Registry for the Session
+              Initiation Protocol (SIP)", BCP 98, RFC 3968,
+              DOI 10.17487/RFC3968, December 2004,
+              <https://www.rfc-editor.org/info/rfc3968>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <https://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC7044]  Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
+              C. Holmberg, "An Extension to the Session Initiation
+              Protocol (SIP) for Request History Information", RFC 7044,
+              DOI 10.17487/RFC7044, February 2014,
+              <https://www.rfc-editor.org/info/rfc7044>.
+
+
+
+
+
+
+
+Mohali                        Informational                    [Page 14]
+
+RFC 8498         P-Served-User Parameter for CDIV in SIP   February 2019
+
+
+   [RFC5502]  van Elburg, J., "The SIP P-Served-User Private-Header
+              (P-Header) for the 3GPP IP Multimedia (IM) Core Network
+              (CN) Subsystem", RFC 5502, DOI 10.17487/RFC5502, April
+              2009, <https://www.rfc-editor.org/info/rfc5502>.
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Mohali                        Informational                    [Page 15]
+