doc: Add RFC documents

1 files changed, 2523 insertions, 0 deletions

diff --git a/doc/rfc/rfc7989.txt b/doc/rfc/rfc7989.txt
new file mode 100644
index 0000000..512d0a8
--- /dev/null
+++ b/doc/rfc/rfc7989.txt
@@ -0,0 +1,2523 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          P. Jones
+Request for Comments: 7989                                  G. Salgueiro
+Obsoletes: 7329                                                C. Pearce
+Category: Standards Track                                      P. Giralt
+ISSN: 2070-1721                                      Cisco Systems, Inc.
+                                                            October 2016
+
+
+                  End-to-End Session Identification in
+               IP-Based Multimedia Communication Networks
+
+Abstract
+
+   This document describes an end-to-end session identifier for use in
+   IP-based multimedia communication systems that enables endpoints,
+   intermediary devices, and management systems to identify a session
+   end-to-end, associate multiple endpoints with a given multipoint
+   conference, track communication sessions when they are redirected,
+   and associate one or more media flows with a given communication
+   session.  While the identifier is intended to work across multiple
+   protocols, this document describes its usage in the Session
+   Initiation Protocol (SIP).
+
+   This document also describes a backwards-compatibility mechanism for
+   an existing session identifier implementation (RFC 7329) that is
+   sufficiently different from the procedures defined in this document.
+
+   This document obsoletes RFC 7329.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   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).  Further information on
+   Internet Standards is available in 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
+   http://www.rfc-editor.org/info/rfc7989.
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                    [Page 1]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                    [Page 2]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Conventions Used in This Document ...............................5
+   3. Session Identifier Definitions, Requirements, and Use Cases .....5
+   4. Constructing and Conveying the Session Identifier ...............5
+      4.1. Constructing the Session Identifier ........................5
+      4.2. Conveying the Session Identifier ...........................6
+   5. The Session-ID Header Field .....................................8
+   6. Endpoint Behavior ...............................................9
+   7. Processing by Intermediaries ...................................11
+   8. Handling of Remote UUID Changes ................................14
+   9. Associating Endpoints in a Multipoint Conference ...............16
+   10. Examples of Various Call Flow Operations ......................17
+      10.1. Basic Call with Two UUIDs ................................18
+      10.2. Basic Call Transfer Using REFER ..........................22
+      10.3. Basic Call Transfer Using Re-INVITE ......................24
+      10.4. Single Focus Conferencing ................................26
+      10.5. Single Focus Conferencing Using a Web-Based
+            Conference Service .......................................28
+      10.6. Cascading Conference Bridges .............................30
+           10.6.1. Establishing a Cascaded Conference ................30
+           10.6.2. Calling Into Cascaded Conference Bridges ..........31
+      10.7. Basic 3PCC for Two UAs ...................................33
+      10.8. Handling in 100 Trying SIP Response and CANCEL Request ...33
+           10.8.1. Handling in a 100 Trying SIP Response .............34
+           10.8.2. Handling a CANCEL SIP Request .....................35
+      10.9. Out-of-Dialog REFER Transaction ..........................36
+   11. Compatibility with a Previous Implementation ..................37
+   12. Security and Privacy Considerations ...........................39
+   13. IANA Considerations ...........................................40
+      13.1. Registration of the "Session-ID" Header Field ............40
+      13.2. Registration of the "remote" Parameter ...................40
+   14. References ....................................................41
+      14.1. Normative References .....................................41
+      14.2. Informative References ...................................42
+   Acknowledgements ..................................................44
+   Dedication ........................................................44
+   Authors' Addresses ................................................45
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                    [Page 3]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+1.  Introduction
+
+   IP-based multimedia communication systems, such as Session Initiation
+   Protocol (SIP) [RFC3261] and [H.323], have the concept of a "call
+   identifier" that is globally unique.  The identifier is intended to
+   represent an end-to-end communication session from the originating
+   device to the terminating device.  Such an identifier is useful for
+   troubleshooting, session tracking, and so forth.
+
+   For several reasons, however, the current call identifiers defined in
+   SIP and H.323 are not suitable for end-to-end session identification.
+   A fundamental issue in protocol interworking is the fact that the
+   syntax for the call identifier in SIP and H.323 is different.  Thus,
+   if both protocols are used in a call, it is impossible to exchange
+   the call identifier end-to-end.
+
+   Another reason why the current call identifiers are not suitable to
+   identify a session end-to-end is that, in real-world deployments,
+   devices such as session border controllers [RFC7092] often change the
+   session signaling, including the value of the call identifier, as it
+   passes through the device.  While this is deliberate and useful, it
+   makes it very difficult to track a session end-to-end.
+
+   This document defines a new identifier, referred to as the "session
+   identifier", that is intended to overcome the issues that exist with
+   the currently defined call identifiers used in SIP and other IP-based
+   communication systems.  The identifier defined here has been adopted
+   by the ITU ([H.460.27]) for use in H.323-based systems, allowing for
+   the ability to trace a session end-to-end for sessions traversing
+   both SIP and H.323-based systems.  This document defines its use in
+   SIP.
+
+   The procedures specified in this document attempt to comply with the
+   requirements specified in [RFC7206].  The procedures also specify
+   capabilities not mentioned in [RFC7206], shown in the call flows in
+   Section 10.  Additionally, this specification attempts to account for
+   a previous, pre-standard version of a SIP session identifier header
+   [RFC7329], specifying a backwards-compatibility approach in
+   Section 11.
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                    [Page 4]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119] when they
+   appear in ALL CAPS.  These words may also appear in this document in
+   lowercase, absent their normative meanings.
+
+   The term "session identifier" refers to the value of the identifier,
+   whereas "Session-ID" refers to the header field used to convey the
+   identifier.  The session identifier is a set of two Universally
+   Unique Identifiers (UUIDs) and each element of that set is simply
+   referred to herein as a "UUID".
+
+   Throughout this document, the term "endpoint" refers to a SIP User
+   Agent (UA) that either initiates or terminates a SIP session, such as
+   a user's mobile phone or a conference server, but excludes entities
+   such as Back-to-Back User Agents (B2BUAs) that are generally located
+   along the call-signaling path between endpoints.  The term
+   "intermediary" refers to any entity along the call-signaling path
+   between the aforementioned endpoints, including B2BUAs and SIP
+   proxies.  In certain scenarios, intermediaries are allowed to
+   originate and terminate SIP messages without an endpoint being part
+   of the session or transaction.  An intermediary may be performing
+   interworking between different protocols (e.g., SIP and H.323) that
+   support the session identifier defined in this document.
+
+3.  Session Identifier Definitions, Requirements, and Use Cases
+
+   Requirements and use cases for the end-to-end session identifier,
+   along with the definition of "session identifier", "communication
+   session", and "end-to-end" can be found in [RFC7206].  Throughout
+   this document, the term "session" refers to a "communication session"
+   as defined in [RFC7206].
+
+   As mentioned in Section 6.1 of [RFC7206], the ITU-T undertook a
+   parallel effort to define compatible procedures for an H.323 session
+   identifier.  They are documented in [H.460.27].
+
+4.  Constructing and Conveying the Session Identifier
+
+4.1.  Constructing the Session Identifier
+
+   The session identifier comprises two UUIDs [RFC4122], with each UUID
+   representing one of the endpoints participating in the session.
+
+
+
+
+
+
+Jones, et al.                Standards Track                    [Page 5]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   The version number in the UUID indicates the manner in which the UUID
+   is generated, such as using random values or using the Media Access
+   Control (MAC) address of the endpoint.  To satisfy the requirement
+   that no user or device information be conveyed, endpoints MUST
+   generate version 4 (random) or version 5 (SHA-1) UUIDs to address
+   privacy concerns related to the use of MAC addresses in UUIDs.
+
+   When generating a version 5 UUID, endpoints or intermediaries MUST
+   utilize the procedures defined in Section 4.3 of [RFC4122] and employ
+   the following "namespace ID":
+
+       uuid_t NameSpace_SessionID = {
+           /* a58587da-c93d-11e2-ae90-f4ea67801e29 */
+           0xa58587da,
+           0xc93d,
+           0x11e2,
+           0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
+       };
+
+   Further, the "name" to utilize for version 5 UUIDs is the
+   concatenation of the Call-ID header-value and the "tag" parameter
+   that appears on the "From" or "To" line associated with the device
+   for which the UUID is created.  Once an endpoint generates a UUID for
+   a session, the UUID never changes, even if values originally used as
+   input into its construction change over time.
+
+   Stateless intermediaries that insert a Session-ID header field into a
+   SIP message on behalf of an endpoint MUST utilize version 5 UUIDs to
+   ensure that UUIDs for the communication session are consistently
+   generated.  If a stateless intermediary does not know the tag value
+   for the endpoint (e.g., a new INVITE request without a To: tag value
+   or an older SIP implementation [RFC2543] that did not include a "tag"
+   parameter), the intermediary MUST NOT attempt to generate a UUID for
+   that endpoint.  Note that, if an intermediary is stateless and the
+   endpoint on one end of the call is replaced with another endpoint due
+   to some service interaction, the values used to create the UUID
+   should change and, if so, the intermediary will compute a different
+   UUID.
+
+4.2.  Conveying the Session Identifier
+
+   The SIP User Agent (UA) initiating a new session by transmitting a
+   SIP request ("Alice"), i.e., a User Agent Client (UAC), MUST create a
+   new, previously unused UUID and transmit that to the ultimate
+   destination UA ("Bob").  Likewise, the destination UA ("Bob"), i.e.,
+   a User Agent Server (UAS), MUST create a new, previously unused UUID
+   and transmit that to the first UA ("Alice").  These two distinct
+   UUIDs form what is referred to as the "session identifier" and is
+
+
+
+Jones, et al.                Standards Track                    [Page 6]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   represented in this document in set notation of the form {A,B}, where
+   "A" is UUID value created by UA "Alice" and "B" is the UUID value
+   created by UA "Bob".  The session identifier {A,B} is equal to the
+   session identifier {B,A}.  Section 6 describes how the UUIDs selected
+   by the source and destination UAs persist for the duration of the
+   session.
+
+   In the case where only one UUID is known, such as when a UA first
+   initiates a potentially dialog-initiating SIP request, the session
+   identifier would be {A,N}, where "A" represents the UUID value
+   transmitted by the UA "Alice", and "N" is what is referred to as the
+   "nil UUID" [RFC4122] (see Section 5 of this document).
+
+   Since SIP sessions are subject to any number of service interactions,
+   SIP INVITE requests might be forked as sessions are established, and
+   since conferences might be established or expanded with endpoints
+   calling in or the conference focus calling out, the construction of
+   the session identifier as a set of UUIDs is important.
+
+   To understand this better, consider that an endpoint participating in
+   a communication session might be replaced with another, such as the
+   case where two "legs" of a call are joined together by a Private
+   Branch Exchange (PBX).  Suppose "Alice" and "Bob" both call UA "C"
+   ("Carol").  There would be two distinctly identifiable session
+   identifiers, namely {A,C} and {B,C}.  Then, suppose that "Carol" uses
+   a local PBX function to join the call between herself and "Alice"
+   with the call between herself and "Bob", resulting in a single
+   remaining call between "Alice" and "Bob".  This merged call can be
+   identified using two UUID values assigned by each entity in the
+   communication session, namely {A,B} in this example.
+
+   In the case of forking, "Alice" might send an INVITE request that
+   gets forked to several different endpoints.  A means of identifying
+   each of these separate communication sessions is needed; since each
+   of the destination UAs will create its own UUID, each communication
+   session would be uniquely identified by the values {A, B1}, {A, B2},
+   {A, B3}, and so on, where each of the Bn values refers to the UUID
+   created by the different UAs to which the SIP session is forked.
+
+   For conferencing scenarios, it is also useful to have a two-part
+   session identifier where the conference focus specifies the same UUID
+   for each conference participant.  This allows for correlation among
+   the participants in a single conference.  For example, in a
+   conference with three participants, the session identifiers might be
+   {A,M}, {B,M}, and {C,M}, where "M" is assigned by the conference
+   focus.  Only a conference focus will purposely utilize the same UUID
+   for more than one SIP session and, even then, such reuse MUST be
+   restricted to the participants in the same conference.
+
+
+
+Jones, et al.                Standards Track                    [Page 7]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   How a device acting on session identifiers processes or utilizes the
+   session identifier is outside the scope of this document.  However,
+   devices storing a session identifier in a log file SHOULD follow the
+   security considerations outlined in [RFC6872].  Note that the primary
+   intent of a session identifier is for troubleshooting; therefore, it
+   should be included in logs at rest that will be used for
+   troubleshooting purposes.
+
+5.  The Session-ID Header Field
+
+   This document replaces the definition of the "Session-ID" token that
+   was added to the definition of the element "message-header" in the
+   SIP message grammar by [RFC7329].  The Session-ID header is a single-
+   instance header.
+
+   Each endpoint participating in a communication session has a
+   distinct, preferably locally generated UUID associated with it.  The
+   endpoint's UUID value remains unchanged throughout the duration of
+   the communication session.  Multipoint conferences can bridge
+   sessions from multiple endpoints and impose unique requirements
+   defined in Section 9.  An intermediary MAY generate a UUID on behalf
+   of an endpoint that did not include a UUID of its own.
+
+   The UUID values for each endpoint are inserted into the Session-ID
+   header field of all transmitted SIP messages.  The Session-ID header
+   field has the following ABNF [RFC5234] syntax:
+
+     session-id          = "Session-ID" HCOLON session-id-value
+
+     session-id-value    = local-uuid *(SEMI sess-id-param)
+
+     local-uuid          = sess-uuid / nil
+
+     remote-uuid         = sess-uuid / nil
+
+     sess-uuid           = 32(DIGIT / %x61-66)  ;32 chars of [0-9a-f]
+
+     sess-id-param       = remote-param / generic-param
+
+     remote-param        = "remote" EQUAL remote-uuid
+
+     nil                 = 32("0")
+
+   The productions "SEMI", "EQUAL", and "generic-param" are defined in
+   [RFC3261].  The production DIGIT is defined in [RFC5234].
+
+
+
+
+
+
+Jones, et al.                Standards Track                    [Page 8]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   The Session-ID header field MUST NOT have more than one "remote"
+   parameter.  In the case where an entity compliant with this
+   specification is interworking with an entity that implemented a
+   session identifier as defined in [RFC7329], the "remote" parameter
+   may be absent; otherwise, the "remote" parameter MUST be present.
+   The details under which those conditions apply are described in
+   Section 11.  Except for backwards compatibility with [RFC7329], the
+   "remote" parameter MUST be present.
+
+   A special nil UUID value composed of 32 zeros is required in certain
+   situations.  A nil UUID is expected as the "remote-uuid" of every
+   initial standard SIP request since the initiating endpoint would not
+   initially know the UUID value of the remote endpoint.  This nil value
+   will get replaced by the ultimate destination UAS when that UAS
+   generates a response message.  One caveat is explained in Section 11
+   for a possible backwards-compatibility case.  A nil UUID value is
+   also returned by some intermediary devices that send provisional or
+   other responses as the "local-uuid" component of the Session-ID
+   header field value, as described in Section 7.
+
+   The "local-uuid" in the Session-ID header field represents the UUID
+   value of the endpoint transmitting a message and the "remote-uuid" in
+   the Session-ID header field represents the UUID of the endpoint's
+   peer.  For example, a Session-ID header field might appear like this:
+
+     Session-ID: ab30317f1a784dc48ff824d0d3715d86;
+                 remote=47755a9de7794ba387653f2099600ef2
+
+   While this is the general form of the Session-ID header field,
+   exceptions to syntax and procedures are detailed in subsequent
+   sections.
+
+   The UUID values are presented as strings of lowercase hexadecimal
+   characters, with the most significant octet of the UUID appearing
+   first.
+
+6.  Endpoint Behavior
+
+   To comply with this specification, endpoints (non-intermediaries)
+   MUST include a Session-ID header field value in all SIP messages
+   transmitted as a part of a communication session.  The locally
+   generated UUID of the transmitter of the message MUST appear in the
+   "local-uuid" portion of the Session-ID header field value.  The UUID
+   of the peer device, if known, MUST appear as the "remote" parameter
+   following the transmitter's UUID.  The nil UUID value MUST be used if
+   the peer device's UUID is not known.
+
+
+
+
+
+Jones, et al.                Standards Track                    [Page 9]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   Once an endpoint allocates a UUID value for a communication session,
+   the endpoint originating the request MUST NOT change that UUID value
+   for the duration of the session, including when:
+
+   o  communication attempts are retried due to receipt of 4xx messages
+      or request timeouts;
+
+   o  the session is redirected in response to a 3xx message;
+
+   o  a session is transferred via a REFER message [RFC3515]; or
+
+   o  a SIP dialog is replaced via an INVITE request with Replaces
+      [RFC3891].
+
+   An endpoint that receives a Session-ID header field MUST take note of
+   any non-nil "local-uuid" value that it receives and assume that is
+   the UUID of the peer endpoint within that communication session.
+   Endpoints MUST include this received UUID value as the "remote"
+   parameter when transmitting subsequent messages, making sure not to
+   change this UUID value in the process of moving the value internally
+   from the "local-uuid" field to the "remote-uuid" field.
+
+   If an endpoint receives a 3xx message, a REFER that directs the
+   endpoint to a different peer, or an INVITE request with Replaces that
+   also potentially results in communicating with a new peer, the
+   endpoint MUST complete any message exchanges with its current peer
+   using the existing session identifier, but it MUST NOT use the
+   current peer's UUID value when sending the first message to what it
+   believes may be a new peer endpoint (even if the exchange results in
+   communicating with the same physical or logical entity).  The
+   endpoint MUST retain its own UUID value, however, as described above.
+
+   It should be noted that messages received by an endpoint might
+   contain a "local-uuid" value that does not match what the endpoint
+   expected its peer's UUID to be.  It is also possible for an endpoint
+   to receive a "remote-uuid" value that does not match its generated
+   UUID for the session.  Either might happen as a result of service
+   interactions by intermediaries and MUST NOT affect how the endpoint
+   processes the session; however, the endpoint may log this event for
+   troubleshooting purposes.
+
+   An endpoint MUST assume that the UUID value of the peer endpoint may
+   change at any time due to service interactions.  Section 8 discusses
+   how endpoints must handle remote UUID changes.
+
+   It is also important to note that if an intermediary in the network
+   forks a session, the endpoint initiating a session may receive
+   multiple responses back from different endpoints, each of which
+
+
+
+Jones, et al.                Standards Track                   [Page 10]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   contains a different UUID ("local-uuid") value.  Endpoints MUST
+   ensure that the correct UUID value is returned in the "remote"
+   parameter when interacting with each endpoint.  The one exception is
+   when the endpoint sends a CANCEL request, in which case the Session-
+   ID header field value MUST be identical to the Session-ID header
+   field value sent in the original request.
+
+   If an endpoint receives a message that does not contain a Session-ID
+   header field, that message must have no effect on what the endpoint
+   believes is the UUID value of the remote endpoint.  That is, the
+   endpoint MUST NOT change the internally maintained "remote-uuid"
+   value for the peer.
+
+   If an endpoint receives a SIP response with a non-nil "local-uuid"
+   that is not 32 octets long, this response comes from a misbehaving
+   implementation, and its Session-ID header field MUST be discarded.
+   That said, the response might still be valid according to the rules
+   within SIP [RFC3261], and it SHOULD be checked further.
+
+   A Multipoint Control Unit (MCU) is a special type of conferencing
+   endpoint and is discussed in Section 9.
+
+7.  Processing by Intermediaries
+
+   The following applies only to an intermediary that wishes to comply
+   with this specification and does not impose a conformance requirement
+   on intermediaries that elect not to provide any special treatment for
+   the Session-ID header field.  Intermediaries that do not comply with
+   this specification might pass the header unchanged or drop it
+   entirely.
+
+   The Call-ID often reveals personal, device, domain, or other
+   sensitive information associated with a user, which is one reason why
+   intermediaries, such as session border controllers, sometimes alter
+   the Call-ID.  In order to ensure the integrity of the end-to-end
+   session identifier, it is constructed in a way that does not reveal
+   such information, removing the need for intermediaries to alter it.
+
+   When an intermediary receives messages from one endpoint in a
+   communication session that causes the transmission of one or more
+   messages toward the second endpoint in a communication session, the
+   intermediary MUST include the Session-ID header field in the
+   transmitted messages with the same UUID values found in the received
+   message, except as outlined in this section and in Section 8.
+
+   If the intermediary aggregates several responses from different
+   endpoints, as described in Section 16.7 of [RFC3261], the
+   intermediary MUST set the local-uuid field to the nil UUID value when
+
+
+
+Jones, et al.                Standards Track                   [Page 11]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   forwarding the aggregated response to the endpoint since the true
+   UUID value of the peer is undetermined at that point.  Note that an
+   intermediary that does not implement this specification might forward
+   a non-nil value, resulting in the originating endpoint receiving
+   different UUID values in the responses.  It is possible for this to
+   result in the endpoint temporarily using the wrong remote UUID.
+   Subsequent messages in the dialog should resolve the temporary
+   mismatch as long as the endpoint follows the rules outlined in
+   Section 8 dealing with the handling of remote UUID changes.
+
+   Intermediary devices that transfer a call, such as by joining
+   together two different "call legs", MUST properly construct a
+   Session-ID header field that contains the UUID values associated with
+   the endpoints involved in the joined session and correct placement of
+   those values.  As described in Section 6, the endpoint receiving a
+   message transmitted by the intermediary will assume that the first
+   UUID value belongs to its peer endpoint.
+
+   If an intermediary receives a SIP message without a Session-ID header
+   field or valid header field value from an endpoint for which the
+   intermediary is not storing a "remote-uuid" value, the intermediary
+   MAY assign a "local-uuid" value to represent that endpoint and,
+   having done so, MUST insert that assigned value into all signaling
+   messages on behalf of the endpoint for that dialog.  In effect, the
+   intermediary becomes dialog-stateful, and it MUST follow the endpoint
+   procedures in Section 6 with respect to Session-ID header field value
+   treatment with itself acting as the endpoint (for the purposes of the
+   Session-ID header field) for which it inserted a component into the
+   Session-ID header field value.  If the intermediary is aware of the
+   UUID value that identifies the endpoint to which a message is
+   directed, it MUST insert that UUID value into the Session-ID header
+   field value as the "remote-uuid" value.  If the intermediary is
+   unaware of the UUID value that identifies the receiving endpoint, it
+   MUST use the nil UUID value as the "remote-uuid" value.
+
+   If an intermediary receives a SIP message without a Session-ID header
+   field or a valid Session-ID header field value from an endpoint for
+   which the intermediary has previously received a Session-ID and is
+   storing a "remote-uuid" value for that endpoint, the lack of a
+   Session-ID must have no effect on what the intermediary believes is
+   the UUID value of the endpoint.  That is, the intermediary MUST NOT
+   change the internally maintained "remote-uuid" value for the peer.
+
+   When an intermediary originates a response, such as a provisional
+   response or a response to a CANCEL request, the "remote-uuid" field
+   will contain the UUID value of the receiving endpoint.  When the UUID
+   of the peer endpoint is known, the intermediary MUST insert the UUID
+   of the peer endpoint in the "local-uuid" field of the header value.
+
+
+
+Jones, et al.                Standards Track                   [Page 12]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   Otherwise, the intermediary MAY set the "local-uuid" field of the
+   header value to the "nil" UUID value.
+
+   When an intermediary originates a request message without first
+   having received a SIP message that triggered the transmission of the
+   message (e.g., sending a BYE message to terminate a call for policy
+   reasons), the intermediary MUST, if it has knowledge of the UUID
+   values for the two communicating endpoints, insert a Session-ID
+   header field with the "remote-uuid" field of the header value set to
+   the UUID value of the receiving endpoint and the "local-uuid" field
+   of the header value set to the UUID value of the other endpoint.
+   When the intermediary does not have knowledge of the UUID value of an
+   endpoint in the communication session, the intermediary SHOULD set
+   the unknown UUID value(s) to the "nil" UUID value.  (If both are
+   unknown, the Session-ID header value SHOULD NOT be included at all,
+   since it would have no practical value.)
+
+   With respect to the previous two paragraphs, note that if an
+   intermediary transmits a "nil" UUID value, the receiving endpoint
+   might use that value in subsequent messages it sends.  This
+   effectively violates the requirement of maintaining an end-to-end
+   session identifier value for the communication session if a UUID for
+   the peer endpoint had been previously conveyed.  Therefore, an
+   intermediary MUST only send the "nil" UUID when the intermediary has
+   not communicated with the peer endpoint to learn its UUID.  This
+   means that intermediaries SHOULD maintain state related to the UUID
+   values for both ends of a communication session if it intends to
+   originate messages (versus merely conveying messages).  An
+   intermediary that does not maintain this state and that originates a
+   message as described in the previous two paragraphs MUST NOT insert a
+   Session-ID header field in order to avoid unintended, incorrect
+   reassignment of a UUID value.
+
+   The Session-ID header field value included in a CANCEL request MUST
+   be identical to the Session-ID header field value included in the
+   corresponding request being cancelled.
+
+   If a SIP intermediary initiates a dialog between two endpoints in a
+   third-party call control (3PCC [RFC3725]) scenario, the initial
+   INVITE request will have a non-nil, locally fabricated "local-uuid"
+   value; call this temporary UUID "X".  The request will still have a
+   nil "remote-uuid" value; call this value "N".  The SIP server MUST be
+   transaction-stateful.  The UUID pair in the INVITE request will be
+   {X,N}.  A 1xx or 2xx response will have a UUID pair {A,X}.  This
+   transaction-stateful, dialog-initiating SIP server MUST replace its
+   own UUID, i.e.,"X", with a nil UUID (i.e., {A,N}) in the INVITE
+   request sent towards the other UAS as expected (see Section 10.7 for
+   an example).
+
+
+
+Jones, et al.                Standards Track                   [Page 13]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   Intermediaries that manipulate messages containing a Session-ID
+   header field SHOULD be aware of what UUID values it last sent towards
+   an endpoint and, following any kind of service interaction initiated
+   or affected by the intermediary, what UUID values the receiving
+   endpoint should have knowledge of to ensure that both endpoints in
+   the session have the correct and same UUID values.  If an
+   intermediary can determine that an endpoint might not have received a
+   current, correct Session-ID field, the intermediary SHOULD attempt to
+   provide the correct Session-ID header field to the endpoint such as
+   by sending a re-INVITE request.  Failure to take such measures may
+   make troubleshooting more difficult because of the mismatched
+   identifiers; therefore, it is strongly advised that intermediaries
+   attempt to provide the correct session identifier if able to do so.
+
+   If an intermediary receives a SIP response with a non-nil "local-
+   uuid" that is not 32 octets long, this response comes from a
+   misbehaving implementation, and its Session-ID header field MUST be
+   discarded.  That said, the response might still be valid according to
+   the rules within SIP [RFC3261], and it SHOULD be checked further.
+
+   An intermediary MUST assume that the UUID value of session peers may
+   change at any time due to service interactions and MAY itself change
+   UUID values for sessions under its control to ensure that end-to-end
+   session identifiers are consistent for all participants in a session.
+   Section 8 discusses how intermediaries must handle remote UUID
+   changes if they maintain state of the session identifier.
+
+   An intermediary may perform protocol interworking between different
+   IP-based communications systems, e.g., interworking between H.323 and
+   SIP.  If the intermediary supports the session identifier for both
+   protocols for which it is interworking, it SHOULD pass the identifier
+   between the two call legs to maintain an end-to-end identifier,
+   regardless of protocol.
+
+8.  Handling of Remote UUID Changes
+
+   It is desirable to have all endpoints and intermediaries involved in
+   a session agree upon the current session identifier when these
+   changes occur.  Due to race conditions or certain interworking
+   scenarios, it is not always possible to guarantee session identifier
+   consistency; however, in an attempt to ensure the highest likelihood
+   of consistency, all endpoints and intermediaries involved in a
+   session MUST accept a peer's new UUID under the following conditions:
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 14]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   o  When an endpoint or intermediary receives a mid-dialog request
+      containing a new UUID from a peer, all responses to that request
+      MUST contain the new UUID value as the "remote" parameter unless a
+      subsequent successful transaction (for example, an UPDATE)
+      contains a different UUID, in which case, the newest UUID MUST be
+      used.
+
+   o  If an endpoint or intermediary sends a successful (2xx) or
+      redirection (3xx) response to the request containing the new UUID
+      value, the endpoint or intermediary MUST accept the peer's UUID
+      and include this new UUID as the "remote" parameter for any
+      subsequent messages unless the UUID from a subsequent transaction
+      has already been accepted.  The one exception is a CANCEL request,
+      as outlined below.
+
+   o  If the endpoint or intermediary sends a failure (4xx, 5xx, or 6xx)
+      response, it MUST NOT accept the new UUID value and any subsequent
+      messages MUST contain the previously stored UUID value in the
+      "remote" parameter for any subsequent message.  Note that the
+      failure response itself will contain the new UUID value from the
+      request in the "remote" parameter.
+
+   o  When an endpoint or intermediary receives an ACK for a successful
+      (2xx) or redirection (3xx) response with a new UUID value, it MUST
+      accept the peer's new UUID value and include this new UUID as the
+      "remote" parameter for any subsequent messages.  If the ACK is for
+      a failure (4xx, 5xx, or 6xx) response, the new value MUST NOT be
+      used.
+
+   o  As stated in Sections 6 and 7, the Session-ID header field value
+      included in a CANCEL request MUST be identical to the Session-ID
+      header field value included in the corresponding INVITE request.
+      Upon receiving a CANCEL request, an endpoint or intermediary would
+      normally send a 487 Request Terminated response (see
+      Section 15.1.2 of [RFC3261]) which, by the rules outlined above,
+      would result in the endpoint or intermediary not storing any UUID
+      value contained in the CANCEL request.  Section 3.8 of [RFC6141]
+      specifies conditions where a CANCEL request can result in a 2xx
+      response.  Because a CANCEL request is not passed end-to-end and
+      will always contain the UUID from the original INVITE request,
+      retaining a new UUID value received in a CANCEL request may result
+      in inconsistency with the Session-ID value stored on the endpoints
+      and intermediaries involved in the session.  To avoid this
+      situation, an endpoint or intermediary MUST NOT accept the new
+      UUID value received in a CANCEL request and any subsequent
+      messages MUST contain the previously stored UUID value in the
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 15]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+      "remote" parameter".  Note that the response to the CANCEL request
+      will contain the UUID value from the CANCEL request in the
+      "remote" parameter.
+
+   o  When an endpoint or intermediary receives a response containing a
+      new UUID from a peer, the endpoint or intermediary MUST accept the
+      new UUID as the peer's UUID and include this new UUID as the
+      "remote" parameter for any subsequent messages.
+
+   When an intermediary accepts a new UUID from a peer, the intermediary
+   SHOULD attempt to provide the correct Session-ID header field to
+   other endpoints involved in the session, for example, by sending a
+   re-INVITE request.  If an intermediary receives a message with a
+   "remote" parameter in the session identifier that does not match the
+   updated UUID, the intermediary MUST update the "remote" parameter
+   with the latest stored UUID.
+
+   If an intermediary is performing interworking between two different
+   protocols that both support the session identifier defined in this
+   document (e.g., SIP to H.323), UUID changes SHOULD be communicated
+   between protocols to maintain the end-to-end session identifier.
+
+9.  Associating Endpoints in a Multipoint Conference
+
+   Multipoint Control Units (MCUs) group two or more sessions into a
+   single multipoint conference and have a conference focus responsible
+   for maintaining the dialogs connected to it [RFC4353].  MCUs,
+   including cascaded MCUs, MUST utilize the same UUID value ("local-
+   uuid" portion of the Session-ID header field value) with all
+   participants in the conference.  In so doing, each individual session
+   in the conference will have a unique session identifier (since each
+   endpoint will create a unique UUID of its own), but will also have
+   one UUID in common with all other participants in the conference.
+
+   When creating a cascaded conference, an MCU MUST convey the UUID
+   value to be utilized for a conference via the "local-uuid" portion of
+   the Session-ID header field value in an INVITE request to a second
+   MCU when using SIP to establish the cascaded conference.  A
+   conference bridge, or MCU, needs a way to identify itself when
+   contacting another MCU.  [RFC4579] defines the "isfocus" Contact
+   header field value parameter just for this purpose.  The initial MCU
+   MUST include the UUID of that particular conference in the "local-
+   uuid" of an INVITE request to the other MCU(s) participating in that
+   conference.  Also included in this INVITE request is an "isfocus"
+   Contact header field value parameter identifying that this INVITE
+   request is coming from an MCU, and that this UUID is to be given out
+   in all responses from endpoints into those MCUs participating in this
+
+
+
+
+Jones, et al.                Standards Track                   [Page 16]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   same conference.  This ensures that a single UUID is common across
+   all participating MCUs of the same conference, but that it is unique
+   between different conferences.
+
+   In the case where two existing conferences are joined, there should
+   be a session between the two MCUs where the session identifier is
+   comprised of the UUID values of the two conferences.  This session
+   identifier can be used to correlate the sessions between participants
+   in the joined conference.  This specification does not impose any
+   additional requirements when two existing conferences are joined.
+
+   Intermediary devices or network-diagnostic equipment might assume
+   that when they see two or more sessions with different session
+   identifiers but with one UUID in common, the sessions are part of the
+   same conference.  However, the assumption that two sessions having
+   one common UUID being part of the same conference is not always
+   correct.  In a SIP-forking scenario, for example, there might also
+   exist what appears to be multiple sessions with a shared UUID value;
+   this is intended.  The desire is to allow for the association of
+   related sessions, regardless of whether a session is forked or part
+   of a conference.
+
+10.  Examples of Various Call Flow Operations
+
+   Seeing something frequently makes understanding easier.  With that in
+   mind, this section includes several call flow examples with the
+   initial UUID and the complete session identifier indicated per
+   message, as well as examples of when the session identifier changes
+   according to the rules within this document during certain
+   operations/functions.
+
+   This section is for illustrative purposes only and is non-normative.
+   In the following flows, "RTP" refers to the Real-time Transport
+   Protocol [RFC3550].
+
+   In the examples in this section, "N" represents a nil UUID and other
+   letters represent the unique UUID values corresponding to endpoints
+   or MCUs.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 17]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+10.1.  Basic Call with Two UUIDs
+
+   Session-ID
+     ---     Alice            B2BUA             Bob            Carol
+    {A,N}      |---INVITE F1--->|                |
+    {A,N}      |                |---INVITE F2--->|
+    {B,A}      |                |<---200 OK F3---|
+    {B,A}      |<---200 OK F4---|                |
+    {A,B}      |-----ACK F5---->|                |
+    {A,B}      |                |-----ACK F6---->|
+               |<==============RTP==============>|
+
+            Figure 1: Session-ID Creation When Alice Calls Bob
+
+   General operation of this example:
+
+   o  UA-Alice populates the "local-uuid" portion of the Session-ID
+      header field value.
+
+   o  UA-Alice sends its UUID in the SIP INVITE request and populates
+      the "remote" parameter with a nil value (32 zeros).
+
+   o  The B2BUA receives an INVITE request with both a "local-uuid"
+      portion of the Session-ID header field value from UA-Alice as well
+      as the nil "remote-uuid" value and transmits the INVITE request
+      towards UA-Bob with an unchanged Session-ID header field value.
+
+   o  UA-Bob receives the Session-ID and generates its "local-uuid"
+      portion of the Session-ID header field value UUID to construct the
+      whole/complete Session-ID header field value, at the same time
+      transferring UA-Alice's UUID unchanged to the "remote-uuid"
+      portion of the Session-ID header field value in the 200 OK SIP
+      response.
+
+   o  The B2BUA receives the 200 OK response with a complete Session-ID
+      header field value from UA-Bob and transmits the 200 OK response
+      towards UA-Alice with an unchanged Session-ID header field value.
+
+   o  UA-Alice, upon reception of the 200 OK from the B2BUA, transmits
+      the ACK towards the B2BUA.  The construction of the Session-ID
+      header field in this ACK is that of UA-Alice's UUID is the "local-
+      uuid", and UA-Bob's UUID populates the "remote-uuid" portion of
+      the header-value.
+
+   o  The B2BUA receives the ACK with a complete Session-ID header field
+      from UA-Alice and transmits the ACK towards UA-Bob with an
+      unchanged Session-ID header field value.
+
+
+
+
+Jones, et al.                Standards Track                   [Page 18]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   Below is a SIP message exchange illustrating proper use of the
+   Session-ID header field.  For the sake of brevity, non-essential
+   headers and message bodies are omitted.
+
+
+   F1 INVITE Alice -> B2BUA
+
+   INVITE sip:bob@biloxi.example.com SIP/2.0
+   Via: SIP/2.0/UDP pc33.atlanta.example.com
+    ;branch=z9hG4bK776asdhds
+   Max-Forwards: 70
+   To: Bob <sip:bob@biloxi.example.com>
+   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
+   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
+   Session-ID: ab30317f1a784dc48ff824d0d3715d86
+    ;remote=00000000000000000000000000000000
+   CSeq: 314159 INVITE
+   Contact: <sip:alice@pc33.atlanta.example.com>
+   Content-Type: application/sdp
+   Content-Length: 142
+
+   (Alice's SDP not shown)
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 19]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   F2 INVITE B2BUA -> Bob
+
+   INVITE sip:bob@192.168.10.20 SIP/2.0
+   Via: SIP/2.0/UDP server10.biloxi.example.com
+    ;branch=z9hG4bK4b43c2ff8.1
+   Via: SIP/2.0/UDP pc33.atlanta.example.com
+    ;branch=z9hG4bK776asdhds;received=10.1.3.33
+   Max-Forwards: 69
+   To: Bob <sip:bob@biloxi.example.com>
+   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
+   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
+   Session-ID: ab30317f1a784dc48ff824d0d3715d86
+    ;remote=00000000000000000000000000000000
+   CSeq: 314159 INVITE
+   Contact: <sip:alice@pc33.atlanta.example.com>
+   Record-Route: <sip:server10.biloxi.example.com;lr>
+   Content-Type: application/sdp
+   Content-Length: 142
+
+   (Alice's SDP not shown)
+
+
+   F3 200 OK Bob -> B2BUA
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/UDP server10.biloxi.example.com
+    ;branch=z9hG4bK4b43c2ff8.1;received=192.168.10.1
+   Via: SIP/2.0/UDP pc33.atlanta.example.com
+    ;branch=z9hG4bK776asdhds;received=10.1.3.33
+   To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
+   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
+   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
+   Session-ID: 47755a9de7794ba387653f2099600ef2
+    ;remote=ab30317f1a784dc48ff824d0d3715d86
+   CSeq: 314159 INVITE
+   Contact: <sip:bob@192.168.10.20>
+   Record-Route: <sip:server10.biloxi.example.com;lr>
+   Content-Type: application/sdp
+   Content-Length: 131
+
+   (Bob's SDP not shown)
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 20]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   F4 200 OK B2BUA -> Alice
+
+   SIP/2.0 200 OK
+   Via: SIP/2.0/UDP pc33.atlanta.example.com
+    ;branch=z9hG4bK776asdhds;received=10.1.3.33
+   To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
+   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
+   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
+   Session-ID: 47755a9de7794ba387653f2099600ef2
+    ;remote=ab30317f1a784dc48ff824d0d3715d86
+   CSeq: 314159 INVITE
+   Contact: <sip:bob@192.168.10.20>
+   Record-Route: <sip:server10.biloxi.example.com;lr>
+   Content-Type: application/sdp
+   Content-Length: 131
+
+   (Bob's SDP not shown)
+
+
+   F5 ACK Alice -> B2BUA
+
+   ACK sip:bob@192.168.10.20 SIP/2.0
+   Via: SIP/2.0/UDP pc33.atlanta.example.com
+    ;branch=z9hG4bKnashds8
+   Route: <sip:server10.biloxi.example.com;lr>
+   Max-Forwards: 70
+   To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
+   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
+   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
+   Session-ID: ab30317f1a784dc48ff824d0d3715d86
+    ;remote=47755a9de7794ba387653f2099600ef2
+   CSeq: 314159 ACK
+   Content-Length: 0
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 21]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   F6 ACK B2BUA -> Bob
+
+   ACK sip:bob@192.168.10.20 SIP/2.0
+   Via: SIP/2.0/UDP server10.biloxi.example.com
+    ;branch=z9hG4bK4b43c2ff8.2
+   Via: SIP/2.0/UDP pc33.atlanta.example.com
+    ;branch=z9hG4bKnashds8;received=10.1.3.33
+   Max-Forwards: 70
+   To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
+   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
+   Call-ID: a84b4c76e66710@pc33.atlanta.example.com
+   Session-ID: ab30317f1a784dc48ff824d0d3715d86
+    ;remote=47755a9de7794ba387653f2099600ef2
+   CSeq: 314159 ACK
+   Content-Length: 0
+
+
+   The remaining examples in this section do not display the complete
+   SIP message exchange.  Instead, they simply use the set notation
+   described in Section 4.2 to show the session identifier exchange
+   throughout the particular call flow being illustrated.
+
+10.2.  Basic Call Transfer Using REFER
+
+   From the example built within Section 10.1, we proceed to this 'Basic
+   Call Transfer using REFER' example.  Note that this is a mid-dialog
+   REFER in contrast with the out-of-dialog REFER in Section 10.9.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 22]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+      Session-ID
+         ---     Alice            B2BUA             Bob            Carol
+                   |                |                |               |
+                   |<==============RTP==============>|               |
+        {B,A}      |                |<---re-INVITE---|               |
+        {B,A}      |<---re-INVITE---| (puts Alice on Hold)           |
+        {A,B}      |-----200 OK---->|                |               |
+        {A,B}      |                |-----200 OK---->|               |
+        {B,A}      |                |<-----ACK-------|               |
+        {B,A}      |<-----ACK-------|                |               |
+                   |                |                |               |
+        {B,A}      |                |<----REFER------|               |
+        {B,A}      |<----REFER------|                |               |
+        {A,B}      |-----200 OK---->|                |               |
+        {A,B}      |                |-----200 OK---->|               |
+        {A,B}      |-----NOTIFY---->|                |               |
+        {A,B}      |                |-----NOTIFY---->|               |
+        {B,A}      |                |<----200 OK-----|               |
+        {B,A}      |<----200 OK-----|                |               |
+                   |                |                |               |
+        {A,N}      |-----INVITE---->|                                |
+        {A,N}      |                |-----INVITE-------------------->|
+        {C,A}      |                |<----200 OK---------------------|
+        {C,A}      |<----200 OK-----|                                |
+        {A,C}      |------ACK------>|                                |
+        {A,C}      |                |------ACK---------------------->|
+                   |                |                |               |
+                   |<======================RTP======================>|
+                   |                |                |               |
+        {A,B}      |-----NOTIFY---->|                |               |
+        {A,B}      |                |-----NOTIFY---->|               |
+        {B,A}      |                |<----200 OK-----|               |
+        {B,A}      |<----200 OK-----|                |               |
+        {B,A}      |                |<-----BYE-------|               |
+        {B,A}      |<-----BYE-------|                |               |
+        {A,B}      |-----200 OK---->|                |               |
+        {A,B}      |                |-----200 OK---->|               |
+                   |                |                |               |
+
+                    Figure 2: Call Transfer Using REFER
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 23]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   General operation of this example:
+
+   Starting from the existing Alice/Bob call described in Figure 1 of
+   this document, which established an existing Session-ID header field
+   value:
+
+   o  UA-Bob requests Alice to call Carol, using a REFER transaction, as
+      described in [RFC3515].  UA-Alice is initially put on hold, then
+      told in the REFER who to contact with a new INVITE, in this case
+      UA-Carol.  This Alice-to-Carol dialog will have a new Call-ID;
+      therefore, it requires a new Session-ID header field value.  The
+      wrinkle here is we can, and will, use Alice's UUID from her
+      existing dialog with Bob in the new INVITE request to Carol.
+
+   o  UA-Alice retains her UUID from the Alice-to-Bob call {A} when
+      requesting a call with UA-Carol.  This is placed in the "local-
+      uuid" portion of the Session-ID header field value, at the same
+      time inserting a nil "remote-uuid" value (because Carol's UA has
+      not yet received the UUID value).  This same UUID traverses the
+      B2BUA unchanged.
+
+   o  UA-Carol receives the INVITE request with a session identifier
+      UUID {A,N}, replaces the "A" UUID value into the "remote-uuid"
+      portion of the Session-ID header field value and creates its own
+      UUID {C}, and places this value in the "local-uuid" portion of the
+      Session-ID header field value, thereby removing the "N" (nil)
+      value altogether.  This combination forms a full session
+      identifier {C,A} in the 200 OK to the INVITE.  This Session-ID
+      header field traverses the B2BUA unchanged towards UA-Alice.
+
+   o  UA-Alice receives the 200 OK with the session identifier {C,A} and
+      responds to UA-Carol with an ACK (just as in Figure 1, this
+      switches the places of the two UUID fields), and generates a
+      NOTIFY request to Bob with a session identifier {A,B} indicating
+      that the call transfer was successful.
+
+   o  It does not matter which UA terminates the Alice-to-Bob call;
+      Figure 2 shows UA-Bob terminating the call.
+
+10.3.  Basic Call Transfer Using Re-INVITE
+
+   From the example built within Section 10.1, we proceed to this 'Basic
+   Call Transfer using re-INVITE' example.
+
+   Alice is talking to Bob.  Bob pushes a button on his phone to
+   transfer Alice to Carol via the B2BUA (using re-INVITE).
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 24]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+      Session-ID
+         ---     Alice            B2BUA             Bob            Carol
+                   |                |                |               |
+                   |<==============RTP==============>|               |
+                   |                |                |               |
+                   |                | <--- (non-standard signaling)  |
+        {A,B}      |                |---re-INVITE--->|               |
+        {B,A}      |                |<-----200 OK----|               |
+        {A,B}      |                |-----ACK------->|               |
+                   |                |                |               |
+        {A,N}      |                |-----INVITE-------------------->|
+        {C,A}      |                |<----200 OK---------------------|
+        {A,C}      |                |------ACK---------------------->|
+                   |                |                |               |
+                   |<======================RTP======================>|
+                   |                |                |               |
+        {A,B}      |                |------BYE------>|               |
+        {B,A}      |                |<----200 OK-----|               |
+                   |                |                |               |
+        {C,A}      |<--re-INVITE----|                |               |
+        {A,C}      |----200 OK----->|                |               |
+        {C,A}      |<-----ACK-------|                |               |
+                   | (Suppose Alice modifies the session)            |
+        {A,C}      |---re-INVITE--->|                |               |
+        {A,C}      |                |---re-INVITE------------------->|
+        {C,A}      |                |<---200 OK----------------------|
+        {C,A}      |<---200 OK------|                |               |
+        {A,C}      |------ACK------>|                |               |
+        {A,C}      |                |------ACK---------------------->|
+                   |                |                |               |
+
+                  Figure 3: Call Transfer Using Re-INVITE
+
+   General operation of this example:
+
+   o  We assume the call between Alice and Bob from Section 10.1 is
+      operational with session identifier {A,B}.
+
+   o  Bob uses non-standard signaling to the B2BUA to initiate a call
+      transfer from Alice to Carol.  This could also be initiated via a
+      REFER message from Bob, but the signaling that follows might still
+      be similar to the above flow.  In either case, Alice is completely
+      unaware of the call transfer until a future point in time when
+      Alice receives a message from Carol.
+
+   o  The B2BUA sends a re-INVITE request with the session identifier
+      {"local-uuid" = "A", "remote-uuid" = "B"} to renegotiate the
+      session with Bob.
+
+
+
+Jones, et al.                Standards Track                   [Page 25]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   o  The B2BUA sends a new INVITE request with Alice's UUID {"local-
+      uuid" = "A"} to Carol.
+
+   o  Carol receives the INVITE request and accepts the request and adds
+      her UUID {C} to the session identifier for this session {"local-
+      uuid" = "C", "remote-uuid" = "A"}.
+
+   o  The B2BUA then terminates the call to Bob with a BYE using the
+      session identifier {"local-uuid" = "A", "remote-uuid" = "B"}.
+
+   o  The B2BUA sends a re-INVITE request to Alice to update Alice's
+      view of the session identifier.
+
+   o  When Alice later attempts to modify the session with a re-INVITE,
+      Alice will send "remote-uuid" = "C" toward Carol because it had
+      previously received the updated UUID in the re-INVITE request from
+      the B2BUA.  The B2BUA maintains the session identifier {"local-
+      uuid" = "A", "remote-uuid" = "C"}.  Carol replies with the "local-
+      uuid" = "C", "remote-uuid" = "A" to reflect what was received in
+      the INVITE request (which Carol already knew from previous
+      exchanges with the B2BUA).  Alice then includes "remote-uuid" =
+      "C" in the subsequent ACK message.
+
+10.4.  Single Focus Conferencing
+
+   Multiple users call into a conference server (for example, an MCU) to
+   attend one of many conferences hosted on or managed by that server.
+   Each user has to identify which conference they want to join, but
+   this information is not necessarily in the SIP messaging.  It might
+   be done by having a dedicated address for the conference or via an
+   Interactive Voice Response (IVR), as assumed in this example and
+   depicted with the use of M1, M2, and M3.  Each user in this example
+   goes through a two-step process of signaling to gain entry onto their
+   conference call, which the conference focus identifies as "M".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 26]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+      Session-ID                Conference
+         ---     Alice            Focus             Bob            Carol
+                   |                |                |               |
+                   |                |                |               |
+        {A,N}      |----INVITE----->|                |               |
+        {M1,A}     |<---200 OK------|                |               |
+        {A,M1}     |-----ACK------->|                |               |
+                   |<====RTP=======>|                |               |
+        {M',A}     |<---re-INVITE---|                |               |
+        {A,M'}     |-----200 OK---->|                |               |
+        {M',A}     |<-----ACK-------|                |               |
+                   |                |                |               |
+                   |                |                |               |
+        {B,N}      |                |<----INVITE-----|               |
+        {M2,B}     |                |-----200 OK---->|               |
+        {B,M2}     |                |<-----ACK-------|               |
+                   |                |<=====RTP======>|               |
+        {M',B}     |                |---re-INVITE--->|               |
+        {B,M'}     |                |<----200 OK-----|               |
+        {M',B}     |                |------ACK------>|               |
+                   |                |                |               |
+                   |                |                |               |
+        {C,N}      |                |<--------------------INVITE-----|
+        {M3,C}     |                |---------------------200 OK---->|
+        {C,M3}     |                |<---------------------ACK-------|
+                   |                |<=====================RTP======>|
+        {M',C}     |                |-------------------re-INVITE--->|
+        {C,M'}     |                |<--------------------200 OK-----|
+        {M',C}     |                |----------------------ACK------>|
+
+                 Figure 4: Single Focus Conference Bridge
+
+   General operation of this example:
+
+   Alice calls into a conference server to attend a certain conference.
+   This is a two-step operation since Alice cannot include the
+   conference ID at this time and/or any passcode in the INVITE request.
+   The first step is Alice's UA calling another UA to participate in a
+   session.  This will appear to be similar as the call flow in Figure 1
+   (in Section 10.1).  What is unique about this call is the second
+   step: the conference server sends a re-INVITE request with its second
+   UUID, but maintaining the UUID Alice sent in the first INVITE.  This
+   subsequent UUID from the conference server will be the same for each
+   UA that calls into this conference server participating in this same
+   conference bridge/call, which is generated once Alice typically
+   authenticates and identifies which bridge she wants to participate
+   on.
+
+
+
+
+Jones, et al.                Standards Track                   [Page 27]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   o  Alice sends an INVITE request to the conference server with her
+      UUID {A} and a "remote-uuid" = "N".
+
+   o  The conference server responds with a 200 OK response, which
+      replaces the "N" UUID with a temporary UUID ("M1") as the "local-
+      uuid" and a "remote-uuid" = "A".
+
+   NOTE: this 'temporary' UUID is a real UUID; it is only temporary to
+   the conference server because it knows that it is going to generate
+   another UUID to replace the one just sent in the 200 OK response.
+
+   o  Once Alice, the user, gains access to the IVR for this conference
+      server, she enters a specific conference ID and whatever passcode
+      (if needed) to enter a specific conference call.
+
+   o  Once the conference server is satisfied Alice has identified which
+      conference she wants to attend (including any passcode
+      verification), the conference server re-INVITEs Alice to the
+      specific conference and includes the Session-ID header field value
+      component "local-uuid" = "M'" (and "remote-uuid" = "A") for that
+      conference.  All valid participants in the same conference will
+      receive this same UUID for identification purposes and to better
+      enable monitoring and tracking functions.
+
+   o  Bob goes through this two-step process of an INVITE transaction,
+      followed by a re-INVITE transaction to get this same UUID ("M'")
+      for the conference.
+
+   o  In this example, Carol (and each additional user) goes through the
+      same procedures as Alice and Bob to get on this same conference.
+
+10.5.  Single Focus Conferencing Using a Web-Based Conference Service
+
+   Alice, Bob, and Carol call into the same web-based conference.  Note
+   that this is one of many ways of implementing this functionality, and
+   it should not be construed as the preferred way of establishing a
+   web-based conference.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 28]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+      Session-ID                Conference
+         ---     Alice            Focus             Bob            Carol
+                   |                |                |               |
+                   |<** HTTPS *****>|                |               |
+                   |  Transaction   |                |               |
+                   |                |                |               |
+        {M,N}      |<----INVITE-----|                |               |
+        {A,M}      |-----200 OK---->|                |               |
+        {M,A}      |<-----ACK-------|                |               |
+                   |<=====RTP======>|                |               |
+                   |                |                |               |
+                   |                |<** HTTPS *****>|               |
+                   |                |  Transaction   |               |
+                   |                |                |               |
+        {M,N}      |                |-----INVITE---->|               |
+        {B,M}      |                |<----200 OK-----|               |
+        {M,B}      |                |------ACK------>|               |
+                   |                |<=====RTP======>|               |
+                   |                |                |               |
+                   |                |<****************** HTTPS *****>|
+                   |                |                   Transaction  |
+                   |                |                |               |
+        {M,N}      |                |--------------------INVITE----->|
+        {C,M}      |                |<-------------------200 OK------|
+        {M,C}      |                |---------------------ACK------->|
+                   |                |<====================RTP=======>|
+
+                Figure 5: Single Focus Web-Based Conference
+
+   General operation of this example:
+
+   o  Alice communicates with the web server that she wants to join a
+      certain meeting by using a meeting number and including UA-Alice's
+      contact information (phone number, URI, and/or IP address, etc.)
+      for each device she wants for this conference call.  For example,
+      the audio and video (A/V) play-out devices could be separate
+      units.
+
+   o  The Conference Focus server sends the INVITE request (Session-ID
+      header field value components "local-uuid" = "M" and a remote UUID
+      of "N", where "M" equals the "local-uuid" for each participant on
+      this conference bridge) to UA-Alice to start a session with that
+      server for this A/V conference call.
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 29]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   o  Upon receiving the INVITE request from the conference focus
+      server, Alice responds with a 200 OK.  Her UA moves the "local-
+      uuid" unchanged into the "remote-uuid" field, generates her own
+      UUID, and places that into the "local-uuid" field to complete the
+      Session-ID construction.
+
+   o  Bob and Carol perform same function to join this same A/V
+      conference call as Alice.
+
+10.6.  Cascading Conference Bridges
+
+10.6.1.  Establishing a Cascaded Conference
+
+   Expanding conferencing capabilities requires cascading conference
+   bridges.  A conference bridge, or MCU, needs a way to identify itself
+   when contacting another MCU.  [RFC4579] defines the "isfocus" Contact
+   header field value parameter just for this purpose.
+
+
+      Session-ID
+         ---     MCU-1            MCU-2            MCU-3           MCU-4
+                   |                |                |               |
+        {M',N}     |----INVITE----->|                |               |
+        {J,M'}     |<---200 OK------|                |               |
+        {M',J}     |-----ACK------->|                |               |
+
+      Figure 6: MCUs Communicating Session Identifier UUID for Bridge
+
+   Regardless of which MCU (1 or 2) a UA contacts for this conference,
+   once the above exchange has been received and acknowledged, the UA
+   will get the same {M',N} UUID pair from the MCU for the complete
+   session identifier.
+
+   A more complex form would be a series of MCUs all being informed of
+   the same UUID to use for a specific conference.  This series of MCUs
+   can be informed in one of two ways:
+
+   o  All by one MCU (that initially generates the UUID for the
+      conference).
+
+   o  The MCU that generates the UUID informs one or several MCUs of
+      this common UUID, and then they inform downstream MCUs of this
+      common UUID that each will be using for this one conference.
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 30]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+      Session-ID
+         ---     MCU-1            MCU-2            MCU-3           MCU-4
+                   |                |                |               |
+        {M',N}     |----INVITE----->|                |               |
+        {J,M'}     |<---200 OK------|                |               |
+        {M',J}     |-----ACK------->|                |               |
+                   |                |                |               |
+        {M',N}     |---------------------INVITE----->|               |
+        {K,M'}     |<--------------------200 OK------|               |
+        {M',K}     |----------------------ACK------->|               |
+                   |                |                |               |
+        {M',N}     |-------------------------------------INVITE----->|
+        {L,M'}     |<------------------------------------200 OK------|
+        {M',L}     |--------------------------------------ACK------->|
+
+                        Figure 7: MCU Communicating
+               Session Identifier UUID to More Than One MCU
+
+   General operation of this example:
+
+   o  The MCU generating the session identifier UUID communicates this
+      in a separate INVITE, having a Contact header with the "isfocus"
+      Contact header field value parameter.  This will identify the MCU
+      as what [RFC4579] calls a "conference-aware" SIP entity.
+
+   o  An MCU that receives this {M',N} UUID pair in an inter-MCU
+      transaction can communicate the M' UUID in a manner in which it
+      was received to construct a hierarchical cascade (though this time
+      this second MCU would be the UAC MCU).
+
+   o  Once the conference is terminated, the cascaded MCUs will receive
+      a BYE message to terminate the cascade.
+
+10.6.2.  Calling Into Cascaded Conference Bridges
+
+   Here is an example of how a UA, Robert for example, calls into a
+   cascaded conference focus.  Because MCU-1 has already contacted MCU-3
+   (the MCU where Robert is going to join the conference), MCU-3 already
+   has the Session-ID (M') for this particular conference call.
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 31]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+      Session-ID
+         ---     MCU-1            MCU-2            MCU-3          Robert
+                   |                |                |               |
+        {M',N}     |----INVITE----->|                |               |
+        {J,M'}     |<---200 OK------|                |               |
+        {M',J}     |-----ACK------->|                |               |
+                   |                |                |               |
+        {M',N}     |---------------------INVITE----->|               |
+        {K,M'}     |<--------------------200 OK------|               |
+        {M',K}     |----------------------ACK------->|               |
+                   |                |                |               |
+        {R,N}      |                |                |<---INVITE-----|
+        (M',R}     |                |                |----200 OK---->|
+        {R,M'}     |                |                |<----ACK-------|
+
+              Figure 8: A UA Calling Into a Cascaded MCU UUID
+
+   General operation of this example:
+
+   o  The UA, Robert in this case, INVITEs the MCU to join a particular
+      conference call.  Robert's UA does not know anything about whether
+      this is the main MCU of the conference call or a cascaded MCU.
+      Robert likely does not know MCUs can be cascaded, he just wants to
+      join a particular call.  As is the case with any standard
+      implementation, he includes a nil "remote-uuid".
+
+   o  The cascaded MCU, upon receiving this INVITE request from Robert,
+      replaces the nil UUID with the UUID value communicated from MCU-1
+      for this conference call as the "local-uuid" in the SIP response,
+      thus moving Robert's UUID "R" to the "remote-uuid" value.
+
+   o  The ACK has the Session-ID {R,M'}, completing the three-way
+      handshake for this call establishment.  Robert has now joined the
+      conference call originated from MCU-1.
+
+   o  Once the conference is terminated, the cascaded MCUs will receive
+      a BYE message to terminate the cascade.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 32]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+10.7.  Basic 3PCC for Two UAs
+
+   An external entity sets up calls to both Alice and Bob for them to
+   talk to each other.
+
+      Session-ID
+         ---     Alice            B2BUA             Bob            Carol
+                   |                |                |
+        {X,N}      |<----INVITE-----|                |
+        {A,X}      |-----200 OK---->|                |
+        {A,N}      |                |----INVITE----->|
+        {B,A}      |                |<---200 OK------|
+        {B,A}      |<-----ACK-------|                |
+        {A,B}      |                |------ACK------>|
+                   |<==============RTP==============>|
+
+            Figure 9: 3PCC-Initiated Call between Alice and Bob
+
+   General operation of this example:
+
+   o  Some out-of-band procedure directs a B2BUA (or other SIP server)
+      to have Alice and Bob talk to each other.  In this case, the SIP
+      server has to be transaction stateful, if not dialog stateful.
+
+   o  The SIP server INVITEs Alice to a session and uses a temporary
+      UUID {X} and a nil UUID pairing.
+
+   o  Alice receives and accepts this call setup and replaces the nil
+      UUID with her UUID {A} in the session identifier, now {A,X}.
+
+   o  The transaction-stateful SIP server receives Alice's UUID {A} in
+      the local UUID portion and keeps it there; and it discards its own
+      UUID {X}, replacing this with a nil UUID value in the INVITE
+      request to Bob as if this came from Alice originally.
+
+   o  Bob receives and accepts this INVITE request and adds his own UUID
+      {B} to the session identifier, now {B,A}, for the response.
+
+   o  The session is established.
+
+10.8.  Handling in 100 Trying SIP Response and CANCEL Request
+
+   The following two subsections show examples of the session identifier
+   for a 100 Trying response and a CANCEL request in a single call flow.
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 33]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+10.8.1.  Handling in a 100 Trying SIP Response
+
+   The following 100 Trying response is taken from [RFC5359],
+   Section 2.9 ("Call Forwarding - No Answer").
+
+    Session-ID   Alice         SIP Server        Bob-1            Bob-2
+                   |                |              |                |
+      {A,N}        |----INVITE----->|              |                |
+      {A,N}        |                |---INVITE---->|                |
+      {N,A}        |<--100 Trying---|              |                |
+      {B1,A}       |                |<-180 Ringing-|                |
+      {B1,A}       |<--180 Ringing--|              |                |
+                   |                |              |                |
+                   |                *Request Timeout*               |
+                   |                |              |                |
+      {A,N}        |                |---CANCEL---->|                |
+      {B1,A}       |                |<--200 OK-----|                |
+      {B1,A}       |                |<---487-------|                |
+      {A,B1}       |                |---- ACK ---->|                |
+                   |                |              |                |
+      {N,A}        |<-181 Call Fwd--|              |                |
+                   |                |              |                |
+      {A,N}        |                |------------------INVITE------>|
+      {B2,A}       |                |<----------------180 Ringing---|
+      {B2,A}       |<-180 Ringing---|              |                |
+      {B2,A}       |                |<-----------------200 OK ------|
+      {B2,A}       |<--200 OK-------|              |                |
+      {A,B2}       |----ACK-------->|              |                |
+      {A,B2}       |                |------------------ACK--------->|
+                   |                |              |                |
+                   |<=========== Both way RTP Established =========>|
+                   |                |              |                |
+      {A,B2}       |----BYE-------->|              |                |
+      {A,B2}       |                |--------------------BYE------->|
+      {B2,A}       |                |<------------------200 OK------|
+      {B2,A}       |<--200 OK-------|              |                |
+                   |                |              |                |
+
+   Figure 10: Session Identifier in the 100 Trying and CANCEL Messaging
+
+   Below is the explanatory text from RFC 5359, Section 2.9, detailing
+   what the desired behavior is in the above call flow (i.e., what the
+   call flow is attempting to achieve).
+
+      Bob wants calls to B1 forwarded to B2 if B1 is not answered
+      (information is known to the SIP server).  Alice calls B1, and no
+      one answers.  The SIP server then places the call to B2.
+
+
+
+
+Jones, et al.                Standards Track                   [Page 34]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   General operation of this example:
+
+   o  Alice generates an INVITE request because she wants to invite Bob
+      to join her session.  She creates a UUID as described in
+      Section 10.1, and she places that value in the "local-uuid" field
+      of the Session-ID header field value.  Alice also generates a
+      "remote-uuid" of nil and sends this along with the "local-uuid".
+
+   o  The SIP server (imagine this is a B2BUA), upon receiving Alice's
+      INVITE request, generates the optional provisional response 100
+      Trying.  Since the SIP server has no knowledge of Bob's UUID for
+      his part of the session identifier value, it cannot include his
+      "local-uuid".  Rather, any 100 Trying response includes Alice's
+      UUID in the "remote-uuid" portion of the Session-ID header-value
+      with a nil "local-uuid" value in the response.  This is consistent
+      with what Alice's UA expects to receive in any SIP response
+      containing this UUID.
+
+10.8.2.  Handling a CANCEL SIP Request
+
+   In the same call flow example as the 100 Trying response is a CANCEL
+   request.  Please refer to Figure 10 for the CANCEL request example.
+
+   General operation of this example:
+
+   o  In Figure 10 above, Alice generates an INVITE request with her
+      UUID value in the Session-ID header field.
+
+   o  Bob-1 responds to this INVITE request with a 180 Ringing.  In that
+      response, he includes his UUID in the Session-ID header field
+      value (i.e., {B1,A}); thus completing the Session-ID header field
+      for this session, even though no final response has been generated
+      by any of Bob's UAs.
+
+   o  While this means that if the SIP server were to generate a SIP
+      request within this session it could include the complete
+      SessionID, the server sends a CANCEL request and a CANCEL request
+      always uses the same Session-ID header field as the original
+      INVITE request.  Thus, the CANCEL request would have a session
+      identifier with the "local-uuid" = "A", and the "remote-uuid" =
+      "N".
+
+   o  As it happens with this CANCEL, the SIP server intends to invite
+      another UA of Bob's (i.e., B2) for Alice to communicate with.
+
+   o  In this example call flow, taken from RFC 5359, Section 2.9, a 181
+      Call is Being Forwarded response is sent to Alice.  Since the SIP
+      server generated this SIP request, and has no knowledge of Bob-2's
+
+
+
+Jones, et al.                Standards Track                   [Page 35]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+      UUID value, it cannot include that value in this 181.  Thus, and
+      for the exact reasons the 100 Trying including the session
+      identifier value, only Alice's UUID is included in the remote-uuid
+      component of the Session-ID header field value, with a nil UUID
+      present in the "local-uuid" component.
+
+10.9.  Out-of-Dialog REFER Transaction
+
+   The following call flow was extracted from Section 6.1 of [RFC5589]
+   ("Successful Transfer"), with the only changes being the names of the
+   UAs to maintain consistency within this document.
+
+         Alice is the transferee
+         Bob is the transferer
+         and Carol is the transfer-target
+
+     Session-ID     Bob                 Alice                 Carol
+                     |                    |                     |
+        {A,N}        |<-----INVITE--------|                     |
+        {B,A}        |------200 OK------->|                     |
+        {A,B}        |<------ACK----------|                     |
+                     |                    |                     |
+        {B,A}        |--INVITE {hold}---->|                     |
+        {A,B}        |<-200 OK------------|                     |
+        {B,A}        |--- ACK ----------->|                     |
+                     |                    |                     |
+        {B,A}        |--REFER------------>|(Refer-To:Carol)     |
+        {A,B}        |<-202 Accepted------|                     |
+                     |                    |                     |
+        {A,B}        |<NOTIFY {100 Trying}|                     |
+        {B,A}        |-200 OK------------>|                     |
+                     |                    |                     |
+        {A,N}        |                    |--INVITE------------>|
+        {C,A}        |                    |<-200 OK-------------|
+        {A,C}        |                    |---ACK-------------->|
+                     |                    |                     |
+        {A,B}        |<--NOTIFY {200 OK}--|                     |
+        {B,A}        |---200 OK---------->|                     |
+                     |                    |                     |
+        {B,A}        |--BYE-------------->|                     |
+        {A,B}        |<-200 OK------------|                     |
+        {C,A}        |                    |<------------BYE-----|
+        {A,C}        |                    |-------------200 OK->|
+
+                  Figure 11: Out-Of-Dialog Call Transfer
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 36]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   General operation of this example:
+
+   o  Just as in Section 10.2, Figure 2, Alice invites Bob to a session,
+      and Bob eventually transfers Alice to communicate with Carol.
+
+   o  What is different about the call flow in Figure 11 is that Bob's
+      REFER is not in-dialog.  Even so, this is treated as part of the
+      same communication session and, thus, the session identifier in
+      those messages is {A,B}.
+
+   o  Alice will use her existing UUID and the nil UUID ({A,N}) in the
+      INVITE request towards Carol (who generates UUID "C" for this
+      session), thus maintaining the common UUID within the session
+      identifier for this new Alice-to-Carol session.
+
+11.  Compatibility with a Previous Implementation
+
+   There is a much earlier document that specifies the use of a Session-
+   ID header field (namely, [RFC7329]) that we will herewith attempt to
+   achieve backwards compatibility.  Neither Session-ID header field has
+   any versioning information, so merely adding that this document
+   describes "version 2" is insufficient.  This section contains the set
+   of rules for compatibility between the two specifications.  Although
+   the previous version was never standardized, it has been heavily
+   implemented and adopted by other standards development organizations.
+   For the purposes of this discussion, we will label the pre-standard
+   specification of the Session-ID as the "old" version and this
+   specification as the "new" version of the Session-ID.
+
+   The previous (i.e., "old") version only has a single UUID value as a
+   Session-ID header field value, but has a generic-parameter value that
+   can be of use.
+
+   In order to have an "old" version talk to an "old" version
+   implementation, nothing needs to be done as far as the IETF is
+   concerned.
+
+   In order to have a "new" version talk to a "new" version
+   implementation, both implementations need to follow this document (to
+   the letter) and everything should be just fine.
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 37]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   For this "new" implementation to work with the "old" implementation
+   and an "old" implementation to work with "new" implementations, there
+   needs to be a set of rules that all "new" implementations MUST follow
+   if the "new" implementation will be communicating with devices that
+   have implemented the "old" implementation.
+
+   o  Since no option tags or feature tags are to be used for
+      distinguishing versions, the presence and order of any "remote-
+      uuid" value within the Session-ID header field value is to be used
+      to distinguish implementation versions.
+
+   o  If a SIP request has a "remote-uuid" value, this comes from a
+      standard implementation, and not a pre-standard one.
+
+   o  If a SIP request has no "remote-uuid" value, this comes from a
+      pre-standard implementation, and not a standard one.  In this
+      case, one UUID is used to identify this dialog, even if the
+      responder is a standard implementor of this specification.
+
+   o  If a SIP response has a non-nil "local-uuid" that is 32 octets
+      long and differs from the endpoint's own UUID value, this response
+      comes from a standard implementation.
+
+   o  If a SIP response arrives that has the same value of Session-ID
+      UUIDs in the same order as was sent, this comes from a pre-
+      standard implementation and MUST NOT be discarded even though the
+      "remote-uuid" may be nil.  In this case, any new transaction
+      within this dialog MUST preserve the order of the two UUIDs within
+      all Session-ID header fields, including the ACK, until this dialog
+      is terminated.
+
+   o  If a SIP response only contains the "local-uuid" that was sent
+      originally, this comes from a pre-standard implementation and MUST
+      NOT be discarded for removing the nil "remote-uuid".  In this
+      case, all future transactions within this dialog MUST contain only
+      the UUID received in the first SIP response.  Any new transaction
+      starting a new dialog from the standard Session-ID implementation
+      MUST include a "local-uuid" and a nil "remote-uuid", even if that
+      new dialog is between the same two UAs.
+
+   o  Standard implementations should not expect pre-standard
+      implementations to be consistent in their implementation, even
+      within the same dialog.  For example, perhaps the first, third,
+      and tenth responses contain a "remote-uuid", but all the others do
+      not.  This behavior MUST be allowed by implementations of this
+      specification.
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 38]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   o  The foregoing does not apply to other, presently unknown
+      parameters that might be defined in the future.  They are ignored
+      for the purposes of interoperability with previous
+      implementations.
+
+12.  Security and Privacy Considerations
+
+   The session identifier MUST be constructed in such a way that does
+   not convey any user or device information as outlined in Section 4.1.
+   This ensures that the data contained in the session identifier itself
+   does not convey user or device information; however, the session
+   identifier may reveal relationships between endpoints that might not
+   be revealed by messages without a session identifier.
+
+   Section 4.2 requires that a UA always generate a new, previously
+   unused UUID when transmitting a request to initiate a new session.
+   This ensures that two unrelated sessions originating from the same UA
+   will never have the same UUID value, thereby removing the ability for
+   an attacker to use the session identifier to identify the two
+   unrelated sessions as being associated with the same user.
+
+   Because of the inherent property that session identifiers are
+   conveyed end-to-end and remain unchanged by a UA for the duration of
+   a session, the session identifier could be misused to discover
+   relationships between two or more parties when multiple parties are
+   involved in the same session such as the case of a redirect,
+   transfer, or conference.  For example, suppose that Alice calls Bob
+   and Bob, via his PBX (acting as a B2BUA), forwards or transfers the
+   call to Carol.  Without use of the session identifier, an
+   unauthorized third party that is observing the communications between
+   Alice and Bob might not know that Alice is actually communicating
+   with Carol.  If Alice, Bob, and Carol include the session identifier
+   as a part of the signaling messages, it is possible for the third
+   party to observe that the UA associated with Bob changed to some
+   other UA.  If the third party also has access to signaling messages
+   between Bob and Carol, the third party can then discover that Alice
+   is communicating with Carol.  This would be true even if all other
+   information relating to the session is changed by the PBX, including
+   both signaling information and media address information.  That said,
+   the session identifier would not reveal the identity of Alice, Bob,
+   or Carol.  It would only reveal the fact that those endpoints were
+   associated with the same session.
+
+   This document allows for additional parameters (generic-param) to be
+   included in the Session-ID header.  This is done to allow for future
+   extensions while preserving backward compatibility with this
+   document.  To protect privacy, the data for any generic-param
+   included in the Session-ID header value MUST NOT include any user or
+
+
+
+Jones, et al.                Standards Track                   [Page 39]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   device information.  Additionally, any information conveyed through
+   an additional parameter MUST NOT persist beyond the current session,
+   and therefore MUST NOT be reused between unrelated sessions.
+   Additional parameters MAY be used by future extensions of this
+   document to correlate related communication sessions that cannot
+   already be correlated by the procedures described in this document as
+   long as the requirements regarding privacy and persistence defined
+   above are followed.
+
+   An intermediary implementing a privacy service that provides user
+   privacy as per Section 5.3 of [RFC3323] MAY choose to consider the
+   Session-ID header as being a nonessential informational header with
+   the understanding that doing so will impair the ability to use the
+   session identifier for troubleshooting purposes.
+
+13.  IANA Considerations
+
+13.1.  Registration of the "Session-ID" Header Field
+
+   The following is the registration for the Session-ID header field to
+   the "Header Name" registry at
+
+   <http://www.iana.org/assignments/sip-parameters>:
+
+   RFC number: RFC 7989
+
+   Header name: 'Session-ID'
+
+   Compact form: none
+
+   Note: This document replaces the Session-ID header originally
+   registered via [RFC7329].
+
+13.2.  Registration of the "remote" Parameter
+
+   The following parameter has been added to the "Header Field
+   Parameters and Parameter Values" section of the "Session Initiation
+   Protocol (SIP) Parameters" registry:
+
+     +--------------+----------------+-------------------+-----------+
+     | Header Field | Parameter Name | Predefined Values | Reference |
+     +--------------+----------------+-------------------+-----------+
+     |  Session-ID  |     remote     |         No        | [RFC7989] |
+     +--------------+----------------+-------------------+-----------+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 40]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+14.  References
+
+14.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
+              A., Peterson, J., Sparks, R., Handley, M., and E.
+              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
+              DOI 10.17487/RFC3261, June 2002,
+              <http://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
+              Method", RFC 3515, DOI 10.17487/RFC3515, April 2003,
+              <http://www.rfc-editor.org/info/rfc3515>.
+
+   [RFC3891]  Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
+              Protocol (SIP) "Replaces" Header", RFC 3891,
+              DOI 10.17487/RFC3891, September 2004,
+              <http://www.rfc-editor.org/info/rfc3891>.
+
+   [RFC4122]  Leach, P., Mealling, M., and R. Salz, "A Universally
+              Unique IDentifier (UUID) URN Namespace", RFC 4122,
+              DOI 10.17487/RFC4122, July 2005,
+              <http://www.rfc-editor.org/info/rfc4122>.
+
+   [RFC4579]  Johnston, A. and O. Levin, "Session Initiation Protocol
+              (SIP) Call Control - Conferencing for User Agents",
+              BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006,
+              <http://www.rfc-editor.org/info/rfc4579>.
+
+   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234,
+              DOI 10.17487/RFC5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC7206]  Jones, P., Salgueiro, G., Polk, J., Liess, L., and H.
+              Kaplan, "Requirements for an End-to-End Session
+              Identification in IP-Based Multimedia Communication
+              Networks", RFC 7206, DOI 10.17487/RFC7206, May 2014,
+              <http://www.rfc-editor.org/info/rfc7206>.
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 41]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+14.2.  Informative References
+
+   [H.323]    International Telecommunications Union, "Packet-based
+              multimedia communications systems", ITU-T
+              Recommendation H.323, December 2009.
+
+   [H.460.27] International Telecommunications Union, "End-to-End
+              Session Identifier for H.323 Systems", ITU-T
+              Recommendation H.460.27, November 2015.
+
+   [RFC2543]  Handley, M., Schulzrinne, H., Schooler, E., and J.
+              Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
+              DOI 10.17487/RFC2543, March 1999,
+              <http://www.rfc-editor.org/info/rfc2543>.
+
+   [RFC3323]  Peterson, J., "A Privacy Mechanism for the Session
+              Initiation Protocol (SIP)", RFC 3323,
+              DOI 10.17487/RFC3323, November 2002,
+              <http://www.rfc-editor.org/info/rfc3323>.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
+              July 2003, <http://www.rfc-editor.org/info/rfc3550>.
+
+   [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
+              Camarillo, "Best Current Practices for Third Party Call
+              Control (3pcc) in the Session Initiation Protocol (SIP)",
+              BCP 85, RFC 3725, DOI 10.17487/RFC3725, April 2004,
+              <http://www.rfc-editor.org/info/rfc3725>.
+
+   [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
+              Session Initiation Protocol (SIP)", RFC 4353,
+              DOI 10.17487/RFC4353, February 2006,
+              <http://www.rfc-editor.org/info/rfc4353>.
+
+   [RFC5359]  Johnston, A., Ed., Sparks, R., Cunningham, C., Donovan,
+              S., and K. Summers, "Session Initiation Protocol Service
+              Examples", BCP 144, RFC 5359, DOI 10.17487/RFC5359,
+              October 2008, <http://www.rfc-editor.org/info/rfc5359>.
+
+   [RFC5589]  Sparks, R., Johnston, A., Ed., and D. Petrie, "Session
+              Initiation Protocol (SIP) Call Control - Transfer",
+              BCP 149, RFC 5589, DOI 10.17487/RFC5589, June 2009,
+              <http://www.rfc-editor.org/info/rfc5589>.
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 42]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+   [RFC6141]  Camarillo, G., Ed., Holmberg, C., and Y. Gao, "Re-INVITE
+              and Target-Refresh Request Handling in the Session
+              Initiation Protocol (SIP)", RFC 6141,
+              DOI 10.17487/RFC6141, March 2011,
+              <http://www.rfc-editor.org/info/rfc6141>.
+
+   [RFC6872]  Gurbani, V., Ed., Burger, E., Ed., Anjali, T., Abdelnur,
+              H., and O. Festor, "The Common Log Format (CLF) for the
+              Session Initiation Protocol (SIP): Framework and
+              Information Model", RFC 6872, DOI 10.17487/RFC6872,
+              February 2013, <http://www.rfc-editor.org/info/rfc6872>.
+
+   [RFC7092]  Kaplan, H. and V. Pascual, "A Taxonomy of Session
+              Initiation Protocol (SIP) Back-to-Back User Agents",
+              RFC 7092, DOI 10.17487/RFC7092, December 2013,
+              <http://www.rfc-editor.org/info/rfc7092>.
+
+   [RFC7329]  Kaplan, H., "A Session Identifier for the Session
+              Initiation Protocol (SIP)", RFC 7329,
+              DOI 10.17487/RFC7329, August 2014,
+              <http://www.rfc-editor.org/info/rfc7329>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 43]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+Acknowledgements
+
+   The authors would like to thank Robert Sparks, Hadriel Kaplan,
+   Christer Holmberg, Paul Kyzivat, Brett Tate, Keith Drage, Mary
+   Barnes, Charles Eckel, Peter Dawes, Andrew Hutton, Arun Arunachalam,
+   Adam Gensler, Roland Jesske, and Faisal Siyavudeen for their
+   invaluable comments during the development of this document.
+
+Dedication
+
+   This document is dedicated to the memory of James Polk, a long-time
+   friend and colleague.  James made important contributions to this
+   specification, including being one of its primary editors.  The IETF
+   global community mourns his loss, and he will be missed dearly.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 44]
+
+RFC 7989                  End-To-End Session ID             October 2016
+
+
+Authors' Addresses
+
+   Paul E. Jones
+   Cisco Systems, Inc.
+   7025 Kit Creek Rd.
+   Research Triangle Park, NC  27709
+   United States of America
+
+   Phone: +1 919 476 2048
+   Email: paulej@packetizer.com
+
+
+   Gonzalo Salgueiro
+   Cisco Systems, Inc.
+   7025 Kit Creek Rd.
+   Research Triangle Park, NC  27709
+   United States of America
+
+   Phone: +1 919 392 3266
+   Email: gsalguei@cisco.com
+
+
+   Chris Pearce
+   Cisco Systems, Inc.
+   2300 East President George Bush Highway
+   Richardson, TX  75082
+   United States of America
+
+   Phone: +1 972 813 5123
+   Email: chrep@cisco.com
+
+
+   Paul Giralt
+   Cisco Systems, Inc.
+   7025 Kit Creek Rd.
+   Research Triangle Park, NC  27709
+   United States of America
+
+   Phone: +1 919 991 5644
+   Email: pgiralt@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+Jones, et al.                Standards Track                   [Page 45]
+