Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7989

End-to-End Session Identification in IP-Based Multimedia Communication Networks

Pages: 45
Proposed Standard
Obsoletes:  7329
Part 1 of 3 – Pages 1 to 17
None   None   Next

Top   ToC   RFC7989 - Page 1
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.
Top   ToC   RFC7989 - Page 2
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.
Top   ToC   RFC7989 - Page 3

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
Top   ToC   RFC7989 - Page 4

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.
Top   ToC   RFC7989 - Page 5

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.
Top   ToC   RFC7989 - Page 6
   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
Top   ToC   RFC7989 - Page 7
   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.
Top   ToC   RFC7989 - Page 8
   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].
Top   ToC   RFC7989 - Page 9
   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.
Top   ToC   RFC7989 - Page 10
   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
Top   ToC   RFC7989 - Page 11
   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
Top   ToC   RFC7989 - Page 12
   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.
Top   ToC   RFC7989 - Page 13
   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).
Top   ToC   RFC7989 - Page 14
   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:
Top   ToC   RFC7989 - Page 15
   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
Top   ToC   RFC7989 - Page 16
      "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
Top   ToC   RFC7989 - Page 17
   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.



(page 17 continued on part 2)

Next Section