Network Working Group P. Jones
Internet-Draft G. Salgueiro
Obsoletes: 7329 (if approved) C. Pearce
Intended status: Standards Track P. Giralt
Expires: August 11, 2016 Cisco Systems, Inc.
February 8, 2016
End-to-End Session Identification in IP-Based Multimedia CommunicationNetworksdraft-ietf-insipid-session-id-17
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.
This document also describes a backwards compatibility mechanism for
an existing session identifier implementation (RFC 7239) that is
sufficiently different from the procedures defined in this document.
This document obsoletes RFC 7239.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2016.
Jones, et al. Expires August 11, 2016 [Page 1]

Internet-Draft End-To-End Session ID February 201615. Dedication . . . . . . . . . . . . . . . . . . . . . . . . . 3616. References . . . . . . . . . . . . . . . . . . . . . . . . . 3616.1. Normative References . . . . . . . . . . . . . . . . . . 3616.2. Informative References . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 381. Introduction
IP-based multimedia communication systems like SIP [RFC3261] and
H.323 [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 like 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 for SIP referred to as the
Session Identifier that is intended to overcome the issues that exist
with the currently defined call identifiers used in SIP. The
procedures specified in this document attempt to comply with the
requirements specified in RFC 7206 [RFC7206]. The procedures also
specify capabilities not mentioned in RFC 7206 [RFC7206], shown in
call flows in section 10. Additionally, the specification attempts
to account for a previous, proprietary version of a SIP Session
Identifier header [RFC7329], specifying a backwards compatibility
approach in section 11.
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 RFC 2119 [RFC2119]
when they appear in ALL CAPS. These words may also appear in this
document in lower case as plain English words, absent their normative
meanings.
Jones, et al. Expires August 11, 2016 [Page 3]

Internet-Draft End-To-End Session ID February 2016
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
like B2BUAs that are generally located along the call signaling path
between endpoints. The term "intermediary" refers to any SIP entity
along the call signaling path between the aforementioned endpoints,
including Back-to-Back User Agents (B2BUAs) and SIP proxies.
3. Session Identifier Requirements and Use Cases
Requirements and use cases for the end-to-end Session Identifier,
along with a definition of "session identifier" and "communication
session", can be found in RFC 2119 [RFC2119].
As mentioned in section 6.1 of RFC 7206, the ITU-T undertook a
parallel effort to define compatible procedures for an H.323 Session
Identifier. They are documented in H.460.27 [H.460.27] .
4. Constructing and Conveying the Session Identifier4.1. Constructing the Session Identifier
The Session Identifier comprises two UUIDs [RFC4122], with each UUID
representing one of the endpoints participating in the session.
The version number in the UUID indicates the manner in which the UUID
is generated, such as using random values or using the MAC address of
the endpoint. To satisfy the requirement that no user or device
information be conveyed, endpoints SHOULD generate version 4 (random)
or version 5 (SHA-1) UUIDs to address privacy concerns related to 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 RFC 4122 [RFC4122]
and employ the following "name space ID":
Jones, et al. Expires August 11, 2016 [Page 4]

Internet-Draft End-To-End Session ID February 2016
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 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) initially transmitting the SIP request
("Alice"), i.e., a User Agent Client (UAC), will create a UUID and
transmit that to the ultimate destination UA ("Bob"). Likewise, the
destination UA ("Bob"), i.e., a User Agent Server (UAS), will create
a UUID and transmit that to the first UA ("Alice"). These two
distinct UUIDs form what is referred to as the Session Identifier and
is 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}.
In the case where only one UUID is known, such as when a UA first
initiates a 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 null UUID (see section 5).
Since SIP sessions are subject to any number of service interactions,
SIP INVITE messages might be forked as sessions are established, and
Jones, et al. Expires August 11, 2016 [Page 5]

Internet-Draft End-To-End Session ID February 2016
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 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 that gets forked
to several different endpoints. A means of identifying each of these
separate communication sessions is needed and, 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.
How a device acting on Session Identifiers stores, processes, or
utilizes the Session Identifier is outside the scope of this
document.
5. The Session-ID Header Field
The syntax specified here replaces the Session-ID header field syntax
defined in RFC 7329 [RFC7329].
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. An intermediary MAY generate a UUID on
behalf of an endpoint that did not include a UUID of its own.
Jones, et al. Expires August 11, 2016 [Page 6]

Internet-Draft End-To-End Session ID February 2016
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 / null
remote-uuid = sess-uuid / null
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
null = 32("0")
The productions "SEMI", "EQUAL", and "generic-param" are defined in
RFC 3261 [RFC3261]. The production DIGIT is defined in RFC 5234
[RFC5234].
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
RFC 7329 [RFC7329], the "remote" parameter may be absent, but
otherwise the remote parameter MUST be present. The details under
which those conditions apply are described in Section 11. Except for
backwards compatibility with RFC 7329 [RFC7329], the "remote"
parameter MUST be present.
A special null UUID value composed of 32 zeros is required in certain
situations. A null 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 null
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 null 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:
Jones, et al. Expires August 11, 2016 [Page 7]

Internet-Draft End-To-End Session ID February 2016
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 lower-case hexadecimal
characters, with the most significant octet of the UUID appearing
first.
The Session-ID header field value is technically case-INSENSITIVE,
but only lowercase characters are allowed in the sess-uuid
components. Receiving entities MUST treat sess-uuid components as
case-insensitive and not produce an error if an uppercase hexadecimal
character is received.
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 null UUID value MUST be used
if the peer device's UUID is not known.
Once an endpoint allocates a UUID value for a communication session,
the endpoint 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 RFC 3515 [RFC3515];
or
o a SIP dialog is replaced via an INVITE with Replaces RFC 3891
[RFC3891].
An endpoint that receives a Session-ID header field MUST take note of
any non-null "local-uuid" value that it receives and assume that is
the UUID of the peer endpoint within that communications session.
Endpoints MUST include this received UUID value as the "remote"
parameter when transmitting subsequent messages, making sure not to
Jones, et al. Expires August 11, 2016 [Page 8]

Internet-Draft End-To-End Session ID February 2016
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, receives a REFER that directs
the endpoint to a different peer, or receives an INVITE 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 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 negatively affect the
communication session. However, the endpoint may log this event for
the purposes of troubleshooting.
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
contains a different UUID ("local-uuid") value. Endpoints MUST take
care to 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 message, in which case
the Session-ID header field value MUST be identical to the Session-ID
header field value sent in the original INVITE.
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.
A Multipoint Control Unit (MCU) is a special type of conferencing
endpoint and is discussed in Section 9.
Jones, et al. Expires August 11, 2016 [Page 9]

Internet-Draft End-To-End Session ID February 20167. 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 to not provide any special treatment for
the Session-ID header field.
The Call-ID often reveals personal, device, domain or other sensitive
information associated with a user, which is 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 which 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.
If the intermediary aggregates several responses from different
endpoints, as described in Section 16.7 of RFC 3261 [RFC3261], the
intermediary MUST set the local-uuid field to the null UUID value
when forwarding the aggregated response to the endpoint since the
true UUID value of the peer is undetermined at that point.
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 from an endpoint without a
Session-ID header field or valid header field 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
Jones, et al. Expires August 11, 2016 [Page 10]

Internet-Draft End-To-End Session ID February 2016
unaware of the UUID value that identifies the receiving endpoint, it
MUST use the null UUID value as the "remote-uuid" value.
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.
Otherwise, the intermediary MAY set the "local-uuid" field of the
header value to the "null" 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 "null" 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 "null" 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 "null" 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 INVITE.
If a SIP intermediary initiates a dialog between two endpoints in a
3PCC [RFC3725] scenario, the SIP request in the initial INVITE will
have a non-null, locally-frabricated "local-uuid" value; call this
Jones, et al. Expires August 11, 2016 [Page 11]

Internet-Draft End-To-End Session ID February 2016
temporary UUID X. The request will still have a null "remote-uuid"
value; call this value N. The SIP server MUST be transaction
stateful. The UUID pair in the INVITE will be {X,N}. A non-
redirected or rejected 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 null UUID (i.e., {A,N}) as expected by
other UAS (see Section 10.7 for an example).
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, of what UUID values the receiving
endpoint should have knowledge 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 message.
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 end to end
session identifiers are consistent for all participants in a session.
Section 8 discusses how intermediaries must handle remote UUID
changes.
8. Handling of Remote UUID Changes
Both endpoints and intermediaries MUST assume that the UUID value of
the session peer MAY change at any time due to service interactions.
To ensure that all endpoints and intermediaries involved in a session
agree upon the current session identifier, the new UUID MUST be
accepted as the peer's UUID under the following conditions:
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.
Jones, et al. Expires August 11, 2016 [Page 12]

Internet-Draft End-To-End Session ID February 2016
o If the endpoint or intermediary sends a failure (4xx, 5xx, 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 latest UUID value in the
"remote" parameter.
o The ACK method is a special case as there is no response. 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, 6xx) response, the new value MUST NOT be
used.
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.
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 utilize for a conference via the "local-uuid" portion of the
Session-ID header field value in an INVITE 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.
RFC 4579 [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
to the other MCU(s) participating in that conference. Also included
in this INVITE is an "isfocus" Contact header field value parameter
identifying that this INVITE 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 same conference. This ensures a single UUID is
common across all participating MCUs of the same conference, but is
unique between different conferences.
Jones, et al. Expires August 11, 2016 [Page 13]

Internet-Draft End-To-End Session ID February 2016
Intermediary devices or network diagnostics equipment might assume
that when they see two or more sessions with different Session
Identifiers, but with one UUID in common, that 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 be 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 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 null UUID and other
letters represents the unique UUID values corresponding to endpoints
or MCUs.
10.1. Basic Call with 2 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, and populates the
"remote" parameter with a null value (32 zeros).
Jones, et al. Expires August 11, 2016 [Page 14]

Internet-Draft End-To-End Session ID February 2016
o B2BUA receives an INVITE with both a "local-uuid" portion of the
Session-ID header field value from UA-Alice as well as the null
"remote-uuid" value, and transmits the INVITE towards UA-Bob with
an unchanged Session-ID header field value.
o UA-Bob receives 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 Alice's UUID unchanged to the "remote-uuid" portion
of the Session-ID header field value in the 200 OK SIP response.
o B2BUA receives the 200 OK response with a complete Session-ID
header field value from UA-Bob, and transmits 200 OK 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 Alice's UUID is the "local-
uuid", and Bob's UUID populates the "remote-uuid" portion of the
header-value.
o B2BUA receives the ACK with a complete Session-ID header field
from UA-Alice, and transmits ACK towards UA-Bob with an unchanged
Session-ID header field value.
Below is a complete 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.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. Expires August 11, 2016 [Page 15]

Internet-Draft End-To-End Session ID February 2016
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. Expires August 11, 2016 [Page 18]

Internet-Draft End-To-End Session ID February 2016
o UA-Bob requests Alice to call Carol, using a REFER transaction, as
described in RFC 3515 [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 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 null "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 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 (null) 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 - switches
places of the two UUID fields), and generates a NOTIFY to Bob with
a Session Identifier {A,B} indicating the call transfer was
successful.
o It does not matter which UA terminates the Alice-to-Bob call;
Figure 2 shows UA-Bob doing this transaction.
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. Expires August 11, 2016 [Page 20]

Internet-Draft End-To-End Session ID February 2016
o The B2BUA then terminates the call to Bob with a BYE using the
Session Identifier {"local-uuid" = "A", "remote-uuid" = "B"}.
o Since Alice never received Carol's UUID from the B2BUA, when Alice
later attempts to modify the session with a re-INVITE, Alice would
send the "remote-uuid" = "B" toward Carol. Carol replies with the
"local-uuid" = "A", "remote-uuid" = "A" to reflect what was
received in the INVITE (which Carol already knew from previous
exchanges with the B2BUA). Alice then includes "remote-uuid" =
"C" in the following ACK message.
10.4. Single Focus Conferencing
Multiple users call into a conference server (say, 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 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. Expires August 11, 2016 [Page 22]

Internet-Draft End-To-End Session ID February 2016
o Alice sends an INVITE 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 send in the 200 OK.
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 that conference.
o In this example, Carol (and each additional user) goes through the
same procedures and steps as Alice and Bob to get on this same
conference.
10.5. Single Focus Conferencing using WebEx
Alice, Bob and Carol call into same WebEx conference.
Jones, et al. Expires August 11, 2016 [Page 24]

Internet-Draft End-To-End Session ID February 2016
o Bob and Carol perform same function to join this same A/V
conference call as Alice.
10.6. Cascading Conference Bridges10.6.1. Establishing a Cascaded Conference
To expand conferencing capabilities requires cascading conference
bridges. A conference bridge, or MCU, needs a way to identify itself
when contacting another MCU. RFC 4579 RFC 4579 [RFC4579] defines the
'isfocus' Contact: header 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 either be informed
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 they inform downstream MCUs of this common
UUID that each will be using for this one conference.
Jones, et al. Expires August 11, 2016 [Page 26]

Internet-Draft End-To-End Session ID February 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'
header parameter. This will identify the MCU as what RFC 4579
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, say Robert, 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. Expires August 11, 2016 [Page 27]

Internet-Draft End-To-End Session ID February 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. Like as with any standard implementation,
he includes a null "remote-uuid".
o The cascaded MCU, upon receiving this INVITE from Robert, replaces
the null 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 3-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.
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.
Jones, et al. Expires August 11, 2016 [Page 28]

Internet-Draft End-To-End Session ID February 2016
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 null UUID pairing.
o Alice receives and accepts this call set-up and replaces the null
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 discards its own
UUID {X}, replacing this with a null UUID value in the INVITE to
Bob as if this came from Alice originally.
o Bob receives and accepts this INVITE 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.
10.8.1. Handling in a 100 Trying SIP Response
The following 100 Trying response is taken from an existing RFC, from
RFC 5359[RFC5359] Section 2.9 ("Call Forwarding - No Answer").
Jones, et al. Expires August 11, 2016 [Page 29]

Internet-Draft End-To-End Session ID February 2016
Session-ID header field value. Alice also generates a "remote-
uuid" of null and sends this along with the "local-uuid".
o The SIP server (imagine this is a B2BUA), upon receiving Alice's
INVITE, generates the optional provisional response 100 Trying.
Since the SIP server has no knowledge 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 null
"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 with her UUID value
in the Session-ID header field.
o Bob-1 responds to this INVITE 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 and a CANCEL always uses the
same Session-ID header field as the original INVITE. Thus, the
CANCEL 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 (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 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
null UUID present in the "local-uuid" component.
Jones, et al. Expires August 11, 2016 [Page 31]

Internet-Draft End-To-End Session ID February 2016
same communication session and, thus, the Session Identifier in
those messages is {A,B}.
o Alice will use her existing UUID and the null UUID ({A,N}) in the
INVITE 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 and proprietary document that specifies the
use of a Session-ID header field (namely, RFC 7329 [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.
Here are the set of rules for compatibility between the two
specifications. For the purposes of this discussion, we will label
the proprietary 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.
But that is where compatibility is not ensured, given the unknowns
related to the behavior of entities implementing the pre-standard
implementation. 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.
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.
Jones, et al. Expires August 11, 2016 [Page 33]

Internet-Draft End-To-End Session ID February 2016
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 implementation of this specification.
o If a SIP response has a non-null "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 has a non-null "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 RFC 3261 [RFC3261], and SHOULD be checked
further.
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 for not
altering the null "remote-uuid". In this case, any new
transaction within this dialog MUST preserve the order of the two
UUIDs within all Session-ID header field, 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 null "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 null "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.
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.
Jones, et al. Expires August 11, 2016 [Page 34]

Internet-Draft End-To-End Session ID February 201612. Security Considerations
When creating a UUID value, UAs MUST ensure that there is no user or
device-identifying information contained within the UUID. In
particular, this means that a UUID MUST NOT be constructed using a
MAC address on the host.
The Session Identifier might be utilized for logging or
troubleshooting, but MUST NOT be used for billing purposes.
The Session Identifier could be misused to discover relationships
between two or more parties. For example, suppose that Alice calls
Bob and Bob, via his PBX, 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.
13. IANA Considerations13.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 XXXX
Header name: 'Session-ID'
Compact form: none
Note: This document replaces the "Session-ID" header originally
registered via RFC 7329 [RFC7329].
[RFC Editor: Please replace XXXX in this section and the next with
the this RFC number of this document.]
Jones, et al. Expires August 11, 2016 [Page 35]