Internet DRAFT - draft-jones-ipmc-session-id
draft-jones-ipmc-session-id
Network Working Group P. Jones
Internet Draft C. Pearce
Intended status: Standards Track J. Polk
Expires: July 30, 2012 G. Salgueiro
Cisco Systems
January 30, 2012
End-to-End Session Identification in IP-Based Multimedia
Communication Networks
draft-jones-ipmc-session-id-03.txt
Abstract
This document describes an end-to-end Session Identifier for use in
IP-based Multimedia Communication systems that enables endpoints,
intermediate 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.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 30, 2012.
Jones, et al. Expires July 30, 2012 [Page 1]
Internet-Draft End-To-End Session ID January 2012
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
Table of Contents
1. Introduction...................................................2
2. Conventions used in this document..............................3
3. Session Identifier Requirements................................3
4. Session Identifier Usage.......................................3
5. Constructing the Session Identifier............................4
6. Transmitting the Session Identifier in SIP.....................4
7. Associating Endpoints in a Multipoint Conference...............5
8. Correlating Media Flows with Sessions..........................6
9. Security Considerations........................................6
10. IANA Considerations...........................................6
11. Acknowledgments...............................................6
12. References....................................................6
12.1. Normative References.....................................6
12.2. Informative References...................................7
Author's Addresses................................................8
1. Introduction
IP-based multimedia communication systems like SIP [1] and H.323 [2]
have the concept of a "call identifier" that is globally unique. The
identifier is intended to represents an end-to-end communication
session from the originating device to the terminating device. Such
an identifier is useful for troubleshooting, billing, session
tracking, and so forth.
Unfortunately, there are a number of factors that contribute to the
fact that the current call identifiers defined in SIP and H.323 are
not suitable for end-to-end session identification. Perhaps most
significant is the fact that the syntax for the call identifier in
SIP and H.323 is different between the two protocols. This important
fact makes it impossible for call identifiers to be exchanged end-to-
end when a network utilizes one or more session protocols.
Another reason why the current call identifiers are not suitable to
identify the session end-to-end is that in real-world deployments
Jones, et al. Expires July 30, 2012 [Page 2]
Internet-Draft End-To-End Session ID January 2012
devices like session border controllers often change the values as
the session signaling passes through. This is true even when a
single session protocol is employed and not a byproduct of protocol
interworking.
This draft presents a new identifier, referred to as the Session
Identifier or "Session ID", and associated syntax intended to
overcome the issues that exist with the currently defined call
identifiers. The proposal in this document attempts to comply with
the requirements specified in [5].
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
3. Session Identifier Requirements
Requirements for the end-to-end Session Identifier can be found in a
separate memo titled "Requirements for an End-to-End Session
Identification in IP-Based Multimedia Communication Networks" [5].
4. Session Identifier Usage
The Session Identifier is intended to uniquely identify a
communication session end-to-end. This document does not specify how
the Session Identifier is to be used, but merely defines the
identifier in such a way as to enable it to be used for situations
encountered in real-world deployments of IP-based multimedia
communication systems, including:
* End-to-end identification of a communication session
* Association of session signaling and media flows, made possible
by including the session identifier in media-related messages
(e.g., RSVP [7] or RTCP [8])
* Identification of devices taking part in the same multipoint
conference
* Tracking sessions transferred from one endpoint to another
* Identification of recorded sessions
* Logging for the purposes of accounting, billing, debugging, etc.
Jones, et al. Expires July 30, 2012 [Page 3]
Internet-Draft End-To-End Session ID January 2012
5. Constructing the Session Identifier
The Session Identifier is comprised of two UUIDs [4] that are
concatenated together, with each UUID created by the endpoints
participating in the session. The first endpoint in the session will
create a UUID and transmit that to the second endpoint. Likewise,
the second endpoint will create a UUID and transmit that to the first
endpoint. Each endpoint will then concatenate the two UUIDs to form
the Session Identifier.
Note that it does not matter which endpoint might be considered the
originating or terminating endpoint. For the purposes of session
identification, it is only important that each endpoint create a UUID
and transmit that value to the remote endpoint. Intermediaries such
as session border controllers MUST NOT change any Session Identifier
component received from an endpoint in a session.
What is also important is the order in which the UUIDs are
concatenated together. To ensure that concatenation is performed
consistently, a binary comparison is performed on the two UUIDs
starting with the most significant byte. The UUID with the higher
binary value is placed after the UUID with the lower binary value.
Consider the following example.
Endpoint 1 produces this UUID: 0xaeffa652b22911dfa81f12313a006823
Endpoint 2 produces this UUID: 0xbe11afc8b22911df86c412313a006823
The resulting Session Identifier would be:
0xaeffa652b22911dfa81f12313a006823be11afc8b22911df86c412313a006823
In the above example, the UUIDs are presented as a string of
hexadecimal characters that correspond to the binary values
comprising the UUID as shown in the table at the end of Section 4.1.2
of RFC 4122 [4].
6. Transmitting the Session Identifier in SIP
Each session initiated or accepted MUST have a locally generated UUID
associated with the session. This value MUST remain unchanged
throughout the duration of the session and MUST persist even when the
session is redirected (e.g., via a 3xx response) or transferred (e.g,
via REFER [6]).
A SIP user agent MUST convey its Session Identifier UUID in all
transmitted messages. To do this, each transmitted message MUST
include the following header:
Session-ID-UUID: aeffa652-b229-11df-a81f-12313a006823
Jones, et al. Expires July 30, 2012 [Page 4]
Internet-Draft End-To-End Session ID January 2012
In the above example, the UUID is presented in string form with
hyphens inserted as shown in the UUID ABNF syntax shown in Section 3
of [4]. Note that the namespace-related syntax "urn:uuid:" is NOT
present in the Session-ID-UUID header.
The formal Session-ID-UUID header syntax is:
Session-ID-UUID = "Session-ID-UUID" HCOLON UUID
The actual Session Identifier is derived, as described in the
previous section, by concatenating the locally generated UUID value
and the UUID value received from the remote endpoint.
Intermediaries that wish to utilize the Session Identifier must take
note of the UUIDs transmitted in each direction between endpoints.
Intermediaries MUST NOT alter the UUIDs. If performing interworking
between SIP and another session protocol, the intermediary MUST
convert the Session-ID-UUID header as necessary so that it preserves
the value of the UUID.
Developers should understand that a session MAY be transferred at any
point and without any explicit signaling. This is not uncommon for
back-to-back user agents that provide various call control functions.
When the session is transferred, joined, or merged, perhaps a new
INVITE message might be received bearing a new Session-ID-UUID value.
When a new UUID is received, the endpoint MUST compute a new Session
Identifier value, as the session has in fact changed. The endpoint
MUST NOT generate a new UUID in response, however.
7. Associating Endpoints in a Multipoint Conference
Multipoint Control Units (MCUs) group two or more sessions into a
single multipoint conference. Each session that is grouped into a
conference SHOULD utilize the same UUID from the MCU to each of the
endpoints 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.
Intermediary devices, such as proxies or session border controllers,
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.
Note, however, that this assumption is true only if the sessions are
operating in parallel. If A tries to establish a session with B and
B redirects the session to C, each of A, B, and C will share at least
one UUID in common (i.e., the UUID created by A). Likewise, if B
transfers the session between A and B to C, A will retain its UUID
Jones, et al. Expires July 30, 2012 [Page 5]
Internet-Draft End-To-End Session ID January 2012
and it will appear that A, B, and C are in a single conference. This
is a desirable behavior, even though it may not be precise. It is
assumed that any device that might wish to utilize this information
would also recognize that a session is redirected or transferred.
8. Correlating Media Flows with Sessions
As mentioned previously, it may be desirable to insert the Session
Identifier into media-related packets, such as RSVP messages or RTCP
packets. In so doing, it is possible for network elements to
1. correlate session signaling with media flows,
2. associate multiple media flows with a single session, and
3. associate multiple media flows from multiple devices that are part
of a single conference
Notwithstanding the foregoing, the use of the Session Identifier for
purposes other than end-to-end session identification is outside the
scope of this document.
9. Security Considerations
TBD
10. IANA Considerations
There are no IANA considerations associated with this document.
11. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
12. References
12.1. Normative References
[1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC
3261, June 2002.
[2] Recommendation ITU-T H.323, "Packet-based multimedia
communications systems", December 2009.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[4] Leach, P., Mealling, M., Salz, R., "A Universally Unique
IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
Jones, et al. Expires July 30, 2012 [Page 6]
Internet-Draft End-To-End Session ID January 2012
[5] Jones, et al., "Requirements for an End-to-End Session
Identification in IP-Based Multimedia Communication Networks",
draft-jones-ipmc-session-id-reqts-01.txt, January 2012.
12.2. Informative References
[6] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[7] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September 1997.
[8] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-
Time Applications", RFC 3550, July 2003.
Jones, et al. Expires July 30, 2012 [Page 7]
Internet-Draft End-To-End Session ID January 2012
Author's Addresses
Paul E. Jones
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Phone: +1 919 476 2048
Email: paulej@packetizer.com
IM: xmpp:paulej@packetizer.com
Chris Pearce
Cisco Systems, Inc.
2300 East President George Bush Highway
Richardson, TX 75082
USA
Phone: +1 972 813 5123
Email: chrep@cisco.com
IM: xmpp:chrep@cisco.com
James Polk
Cisco Systems, Inc.
3913 Treemont Circle
Colleyville, Texas, USAUSA
Phone: +1 817 271 3552
Email: jmpolk@cisco.com
IM: xmpp:jmpolk@cisco.com
Gonzalo Salgueiro
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Phone: +1 919 392 3266
Email: gsalguei@cisco.com
IM: xmpp:gsalguei@cisco.com
Jones, et al. Expires July 30, 2012 [Page 8]
