diff options
Diffstat (limited to 'doc/rfc/rfc7989.txt')
| -rw-r--r-- | doc/rfc/rfc7989.txt | 2523 |
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] + |