One document matched: draft-ietf-insipid-session-id-18.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3261 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC2119 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC4122 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4122.xml">
<!ENTITY RFC5234 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC4579 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4579.xml">
<!ENTITY RFC3891 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3891.xml">
<!ENTITY RFC3515 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3515.xml">
<!ENTITY RFC7329 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7329.xml">
<!ENTITY RFC3550 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC7206 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7206.xml">
<!ENTITY RFC5359 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5359.xml">
<!ENTITY RFC5589 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5589.xml">
<!ENTITY RFC2543 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2543.xml">
<!ENTITY RFC3725 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3725.xml">
<!ENTITY RFC4353 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4353.xml">
<!ENTITY RFC7092 PUBLIC "" "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7092.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, <xref target="RFC2119"></xref> instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-ietf-insipid-session-id-18" obsoletes="7329" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902,
or pre5378Trust200902
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="End-To-End Session ID">
End-to-End Session Identification in IP-Based Multimedia Communication Networks
</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Paul E. Jones" initials="P.E.J." surname="Jones">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7025 Kit Creek Rd.</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>
<phone>+1 919 476 2048</phone>
<email>paulej@packetizer.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Gonzalo Salgueiro" initials="G.S." surname="Salgueiro">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7025 Kit Creek Rd.</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>
<phone>+1 919 392 3266</phone>
<email>gsalguei@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Chris Pearce" initials="C.E.P." surname="Pearce">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>2300 East President George Bush Highway</street>
<city>Richardson</city>
<region>TX</region>
<code>75082</code>
<country>USA</country>
</postal>
<phone>+1 972 813 5123</phone>
<email>chrep@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Paul Giralt" initials="P.B.G." surname="Giralt">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>7025 Kit Creek Rd.</street>
<city>Research Triangle Park</city>
<region>NC</region>
<code>27709</code>
<country>USA</country>
</postal>
<phone>+1 919 991 5644</phone>
<email>pgiralt@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date year="2016" />
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>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.</t>
<t>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.</t>
<t>This document obsoletes RFC 7329.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>IP-based multimedia communication systems like
<xref target="RFC3261">SIP</xref> and <xref target="H.323"></xref>
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.</t>
<t>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.</t>
<t>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
<xref target="RFC7092">session border controllers</xref> 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.</t>
<t>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
<xref target="RFC7206"></xref>. The procedures also specify
capabilities not mentioned in <xref target="RFC7206"></xref>, shown
in call flows in section 10. Additionally, the specification attempts to account
for a previous, proprietary version of a
<xref target="RFC7329">SIP Session Identifier header</xref>, specifying a
backwards compatibility approach in section 11.</t>
</section>
<section title="Conventions used in this document">
<t>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 <xref target="RFC2119"></xref> 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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Session Identifier Requirements and Use Cases">
<t>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 <xref target="RFC7206"></xref>.</t>
<t>As mentioned in section 6.1 of <xref target="RFC7206"></xref>, the ITU-T
undertook a parallel effort to define compatible procedures for an H.323 Session
Identifier. They are documented in <xref target="H.460.27"></xref>.</t>
</section>
<section title="Constructing and Conveying the Session Identifier">
<section title="Constructing the Session Identifier">
<t>The Session Identifier comprises two <xref target="RFC4122">UUIDs</xref>,
with each UUID representing one of the endpoints participating in the
session.</t>
<t>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.</t>
<t>When generating a version 5 UUID, endpoints or intermediaries MUST utilize
the procedures defined in Section 4.3 of <xref target="RFC4122"></xref>
and employ the following "name space ID":</t>
<figure>
<artwork align="left"><![CDATA[
uuid_t NameSpace_SessionID = {
/* a58587da-c93d-11e2-ae90-f4ea67801e29 */
0xa58587da,
0xc93d,
0x11e2,
0xae, 0x90, 0xf4, 0xea, 0x67, 0x80, 0x1e, 0x29
}
]]></artwork>
</figure>
<t>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.</t>
<t>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
<xref target="RFC2543">older SIP implementation</xref> 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.</t>
</section>
<section title="Conveying the Session Identifier">
<t>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}.</t>
<t>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).</t>
<t>Since SIP sessions are subject to any number of service interactions, SIP
INVITE messages 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>How a device acting on Session Identifiers stores, processes, or utilizes
the Session Identifier is outside the scope of this document.</t>
</section>
</section>
<section title="The Session-ID Header Field">
<t>The syntax specified here replaces the Session-ID header field syntax defined
in <xref target="RFC7329"></xref>.</t>
<t>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.</t>
<t>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 <xref target="RFC5234">ABNF</xref> syntax:</t>
<figure>
<artwork align="left"><![CDATA[
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")
]]></artwork>
</figure>
<t>The productions "SEMI", "EQUAL", and "generic-param" are defined in
<xref target="RFC3261"></xref>. The production DIGIT is defined in
<xref target="RFC5234"></xref>.</t>
<t>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 <xref target="RFC7329"></xref>, 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 <xref target="RFC7329"></xref>, the "remote" parameter
MUST be present.</t>
<t>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.</t>
<t>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:</t>
<figure>
<artwork align="left"><![CDATA[
Session-ID: ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2
]]></artwork>
</figure>
<t>While this is the general form of the Session-ID header field, exceptions to
syntax and procedures are detailed in subsequent sections.</t>
<t>The UUID values are presented as strings of lower-case hexadecimal characters,
with the most significant octet of the UUID appearing first.</t>
<t>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.</t>
</section>
<section title="Endpoint Behavior">
<t>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. </t>
<t>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</t>
<t>
<list style="symbols">
<t>communication attempts are retried due to receipt of 4xx messages or
request timeouts;</t>
<t>the session is redirected in response to a 3xx message;</t>
<t>a session is transferred via a REFER message <xref target="RFC3515"></xref>;
or</t>
<t>a SIP dialog is replaced via an INVITE with Replaces
<xref target="RFC3891"></xref>.</t>
</list>
</t>
<t>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 change this UUID value in the process of moving the value
internally from the "local-uuid" field to the "remote-uuid" field.</t>
<t>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.</t>
<t>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.</t>
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t>A Multipoint Control Unit (MCU) is a special type of conferencing endpoint
and is discussed in Section 9.</t>
</section>
<section title="Processing by Intermediaries">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>If the intermediary aggregates several responses from different endpoints,
as described in Section 16.7 of <xref target="RFC3261"></xref>, 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.</t>
<t>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.</t>
<t>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 unaware of the UUID value that
identifies the receiving endpoint, it MUST use the null UUID value as the
"remote-uuid" value.</t>
<t>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.</t>
<t>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.)</t>
<t>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.</t>
<t>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. </t>
<t>If a SIP intermediary initiates a dialog between two endpoints in a
<xref target="RFC3725">3PCC</xref> scenario, the SIP request in the initial
INVITE will have a non-null, locally-frabricated "local-uuid" value; call this
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).</t>
<t>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.</t>
<t>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. </t>
</section>
<section title="Handling of Remote UUID Changes">
<t>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:</t>
<t><list style="symbols">
<t>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. </t>
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Associating Endpoints in a Multipoint Conference">
<t>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 <xref target="RFC4353"></xref>.
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.</t>
<t>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. <xref target="RFC4579"></xref> 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.</t>
<t>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. </t>
</section>
<section title="Examples of Various Call Flow Operations">
<t>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.</t>
<t>This section is for illustrative purposes only and is non-normative. In the
following flows, RTP refers to the
<xref target="RFC3550">Real-time Transport Protocol</xref>.</t>
<t>In the examples in this section, "N" represents a null UUID and other letters
represents the unique UUID values corresponding to endpoints or MCUs.</t>
<section title="Basic Call with 2 UUIDs">
<figure align="center" anchor="figure1"
title="Session-ID Creation when Alice calls Bob">
<artwork align="left"><![CDATA[
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==============>|
]]></artwork>
</figure>
<t>General operation of this example:</t>
<t><list style="symbols">
<t>UA-Alice populates the "local-uuid" portion of the Session-ID header field
value.</t>
<t>UA-Alice sends its UUID in the SIP INVITE, and populates the "remote"
parameter with a null value (32 zeros).</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
<t>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.</t>
<figure>
<artwork align="left"><![CDATA[
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)
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)
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
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
]]></artwork>
</figure>
<t>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.</t>
</section>
<section title="Basic Call Transfer using REFER">
<t>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.</t>
<figure align="center" anchor="figure2"
title="Call Transfer using REFER">
<artwork align="left"><![CDATA[
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---->| |
| | | |
]]></artwork>
</figure>
<t>General operation of this example:</t>
<t>Starting from the existing Alice/Bob call described in Figure 1 of this
document, which established an existing Session-ID header field value:</t>
<t><list style="symbols">
<t>UA-Bob requests Alice to call Carol, using a REFER transaction, as
described in <xref target="RFC3515"></xref>. 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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>It does not matter which UA terminates the Alice-to-Bob call; Figure 2
shows UA-Bob doing this transaction.</t>
</list></t>
</section>
<section title="Basic Call Transfer using re-INVITE">
<t>From the example built within Section 10.1, we proceed to this 'Basic Call
Transfer using re-INVITE' example.</t>
<t>Alice is talking to Bob. Bob pushes a button on his phone to transfer Alice
to Carol via the B2BUA (using re-INVITE). </t>
<figure align="center" anchor="figure3"
title="Call transfer using re-INVITE">
<artwork align="left"><![CDATA[
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-----| |
| | | |
| (Suppose Alice modifies the session) |
{A,B} |---re-INVITE--->| | |
{A,B} | |---re-INVITE------------------->|
{C,A} | |<---200 OK----------------------|
{C,A} |<---200 OK------| | |
{A,C} |------ACK------>| | |
{A,C} | |------ACK---------------------->|
| | | |
]]></artwork>
</figure>
<t>General operation of this example:</t>
<t><list style="symbols">
<t>We assume the call between Alice and Bob from Section 10.1 is operational
with Session Identifier {A,B}.</t>
<t>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.</t>
<t>The B2BUA sends a new INVITE with Alice's UUID {"local-uuid" = "A"}
to Carol.</t>
<t>Carol receives the INVITE and accepts the request and adds her UUID {C}
to the Session Identifier for this session {"local-uuid" = "C", "remote-uuid"
= "A"}.</t>
<t>The B2BUA then terminates the call to Bob with a BYE using the Session
Identifier {"local-uuid" = "A", "remote-uuid" = "B"}.</t>
<t>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.</t>
</list></t>
</section>
<section title="Single Focus Conferencing">
<t>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'.</t>
<figure align="center" anchor="figure4"
title="Single Focus Conference Bridge">
<artwork align="left"><![CDATA[
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------>|
]]></artwork>
</figure>
<t>General operation of this example:</t>
<t>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.</t>
<t><list style="symbols">
<t>Alice sends an INVITE to the conference server with her UUID {A} and a
"remote-uuid" = N.</t>
<t>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". </t>
</list></t>
<t>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.</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Single Focus Conferencing using WebEx">
<t>Alice, Bob and Carol call into same WebEx conference.</t>
<figure align="center" anchor="figure5"
title="Single Focus WebEx Conference">
<artwork align="left"><![CDATA[
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=======>|
]]></artwork>
</figure>
<t>General operation of this example:</t>
<t><list style="symbols">
<t>Alice communicates with WebEx server with desire to join a certain meeting,
by meeting number; also includes 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 play-out devices could be separate
units.</t>
<t>Conference Focus server sends INVITE (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 session with that server for this A/V conference call.</t>
<t>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, and generates her own UUID and places that into
the "local-uuid" field to complete the Session-ID construction.</t>
<t>Bob and Carol perform same function to join this same A/V conference
call as Alice. </t>
</list></t>
</section>
<section title="Cascading Conference Bridges">
<section title="Establishing a Cascaded Conference">
<t>To expand conferencing capabilities requires cascading conference bridges.
A conference bridge, or MCU, needs a way to identify itself when contacting
another MCU. <xref target="RFC4579"></xref> defines the 'isfocus' Contact:
header parameter just for this purpose.</t>
<figure align="center" anchor="figure6"
title="MCUs Communicating Session Identifier UUID for Bridge">
<artwork align="left"><![CDATA[
Session-ID
--- MCU-1 MCU-2 MCU-3 MCU-4
| | | |
{M',N} |----INVITE----->| | |
{J,M'} |<---200 OK------| | |
{M',J} |-----ACK------->| | |
]]></artwork>
</figure>
<t>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.</t>
<t>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 </t>
<t><list style="symbols">
<t>All by one MCU (that initially generates the UUID for the conference).</t>
<t>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.</t>
</list></t>
<figure align="center" anchor="figure7"
title="MCU Communicating Session Identifier UUID to More than One MCU">
<artwork align="left"><![CDATA[
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------->|
]]></artwork>
</figure>
<t>General operation of this example:</t>
<t><list style="symbols">
<t>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 <xref target="RFC4579"></xref> calls a
conference-aware SIP entity.</t>
<t>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).</t>
<t>Once the conference is terminated, the cascaded MCUs will receive a BYE
message to terminate the cascade.</t>
</list></t>
</section>
<section title="Calling into Cascaded Conference Bridges">
<t>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.</t>
<figure align="center" anchor="figure8"
title="A UA Calling into a Cascaded MCU UUID">
<artwork align="left"><![CDATA[
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-------|
]]></artwork>
</figure>
<t>General operation of this example:</t>
<t><list style="symbols">
<t>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".</t>
<t>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.</t>
<t>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.</t>
<t>Once the conference is terminated, the cascaded MCUs will receive a BYE
message to terminate the cascade.</t>
</list></t>
</section>
</section>
<section title="Basic 3PCC for two UAs">
<t>An external entity sets up calls to both Alice and Bob for them to talk to each
other.</t>
<figure align="center" anchor="figure9"
title="3PCC initiated call between Alice and Bob">
<artwork align="left"><![CDATA[
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==============>|
]]></artwork>
</figure>
<t>General operation of this example:</t>
<t><list style="symbols">
<t>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.</t>
<t>The SIP server INVITEs Alice to a session and uses a temporary UUID {X}
and a null UUID pairing.</t>
<t>Alice receives and accepts this call set-up and replaces the null UUID
with her UUID {A} in the Session Identifier, now {A,X}.</t>
<t>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.</t>
<t>Bob receives and accepts this INVITE and adds his own UUID {B} to the
Session Identifier, now {B,A} for the response.</t>
<t>The session is established.</t>
</list></t>
</section>
<section title="Handling in 100 Trying SIP Response and CANCEL Request">
<t>The following two subsections show examples of the Session Identifier for a
100 Trying response and a CANCEL request in a single call-flow.</t>
<section title="Handling in a 100 Trying SIP Response">
<t>The following 100 Trying response is taken from an existing RFC, from
<xref target="RFC5359"></xref> Section 2.9 ("Call Forwarding - No Answer").
</t>
<figure align="center" anchor="figure10"
title="Session Identifier in the 100 Trying and CANCEL Messaging">
<artwork align="left"><![CDATA[
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-------| | |
| | | |
]]></artwork>
</figure>
<t>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).</t>
<t>"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."</t>
<t>General operation of this example:</t>
<t><list style="symbols">
<t>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 places
that value in the "local-uuid" field of the Session-ID header field value.
Alice also generates a "remote-uuid" of null and sends this along with the
"local-uuid".</t>
<t>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.</t>
</list></t>
</section>
<section title="Handling a CANCEL SIP Request">
<t>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.</t>
<t>General operation of this example:</t>
<t><list style="symbols">
<t>In Figure 10 above, Alice generates an INVITE with her UUID value in the
Session-ID header field.</t>
<t>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.</t>
<t>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".</t>
<t>As it happens with this CANCEL, the SIP server intends to invite another
UA of Bob (i.e., B2) for Alice to communicate with. </t>
<t>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.</t>
</list></t>
</section>
</section>
<section title="Out-of-dialog REFER Transaction">
<t>The following call-flow was extracted from Section 6.1 of
<xref target="RFC5589"></xref> ("Successful Transfer"), with the only changes
being the names of the UAs to maintain consistency within this document.</t>
<figure align="center" anchor="figure11"
title="Out-Of-Dialog Call Transfer">
<artwork align="left"><![CDATA[
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->|
]]></artwork>
</figure>
<t>General operation of this example:</t>
<t><list style="symbols">
<t>Just as in Section 10.2, Figure 2, Alice invites Bob to a session, and
Bob eventually transfers Alice to communicate with Carol.</t>
<t>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}.</t>
<t>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.</t>
</list></t>
</section>
</section>
<section title="Compatibility with a Previous Implementation">
<t>There is a much earlier and proprietary document that specifies the use of a
Session-ID header field (namely, <xref target="RFC7329"></xref>) 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.</t>
<t>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.</t>
<t>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. </t>
<t>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.</t>
<t>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.</t>
<t><list style="symbols">
<t>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.</t>
<t>If a SIP request has a "remote-uuid" value, this comes from a standard
implementation, and not a pre-standard one.</t>
<t>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.</t>
<t>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.</t>
<t>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 <xref target="RFC3261"></xref>,
and SHOULD be checked further.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</list></t>
</section>
<section title="Security Considerations">
<t>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.</t>
<t>The Session Identifier might be utilized for logging or troubleshooting, but
MUST NOT be used for billing purposes.</t>
<t>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.</t>
</section>
<section title="IANA Considerations">
<section title="Registration of the "Session-ID" Header Field">
<t>The following is the registration for the 'Session-ID' header field to
the "Header Name" registry at</t>
<t>http://www.iana.org/assignments/sip-parameters:</t>
<t>RFC number: RFC XXXX</t>
<t>Header name: 'Session-ID'</t>
<t>Compact form: none</t>
<t>Note: This document replaces the "Session-ID" header originally
registered via <xref target="RFC7329"></xref>.</t>
<t>[RFC Editor: Please replace XXXX in this section and the next with the
this RFC number of this document.]</t>
</section>
<section title="Registration of the "remote" Parameter">
<t>The following parameter is to be added to the "Header Field Parameters
and Parameter Values" section of the SIP parameter registry:</t>
<texttable>
<ttcol align="center">Header Field</ttcol>
<ttcol align="center">Parameter Name</ttcol>
<ttcol align="center">Predefined Values</ttcol>
<ttcol align="center">Reference</ttcol>
<c>Session-ID</c>
<c>remote</c>
<c>No</c>
<c>[RFCXXXX]</c>
</texttable>
</section>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>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.</t>
</section>
<section anchor="Dedication" title="Dedication">
<t>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. </t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC3261;
&RFC2119;
&RFC4122;
&RFC5234;
&RFC4579;
&RFC3891;
&RFC3515;
&RFC7329;
</references>
<references title="Informative References">
<reference anchor="H.323">
<front>
<title>Recommendation ITU-T H.323, Packet-based multimedia communications
systems</title>
<author>
<organization abbrev="ITU">
International Telecommunications Union
</organization>
</author>
<date year="2009" month = "December" />
</front>
</reference>
&RFC3550;
&RFC7206;
&RFC5359;
&RFC5589;
&RFC2543;
<reference anchor="H.460.27">
<front>
<title>Recommendation ITU-T H.460.27, End-to-End Session Identifier for
H.323 Systems</title>
<author>
<organization abbrev="ITU">
International Telecommunications Union
</organization>
</author>
<date year="2015" month="November"/>
</front>
</reference>
&RFC3725;
&RFC4353;
&RFC7092;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 18:59:21 |