Network Working Group Paul E. Jones
Internet Draft Gonzalo Salgueiro
Intended status: Informational James Polk
Expires: July 30, 2012 Parthasarathi Ravindran
Cisco Systems
Laura Liess
Roland Jesske
Deutsche Telekom
Salvatore Loreto
Ericsson
Hadriel Kaplan
Acme Packet
January 30, 2012
Requirements for an End-to-End Session Identification in
IP-Based Multimedia Communication Networks
draft-jones-ipmc-session-id-reqts-01.txt
Abstract
This document specifies the requirements for an end-to-end session
identifier in IP-based multimedia communication networks. This
identifier would enable endpoints, intermediate devices, and
management and monitoring 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 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 July 30, 2012.
Jones, et al. Expires July 30, 2012 [Page 1]
Internet-Draft Requirements for 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. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction...................................................2
2. Terminology....................................................3
3. Requirements for the End-to-End Session Identifier.............3
4. Session Identifier Use Cases...................................4
5. Related Work in other Standards Organizations..................5
5.1. Coordination with the ITU-T...............................5
5.2. Requirements within 3GPP..................................5
6. Security Considerations........................................5
7. IANA Considerations............................................6
8. Acknowledgments................................................6
9. References.....................................................6
9.1. Normative References......................................6
9.2. Informative References....................................6
Author's Addresses................................................7
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.
Jones, et al. Expires July 30, 2012 [Page 2]
Internet-Draft Requirements for End-To-End Session ID January 2012
Another reason why the current call identifiers are not suitable to
identify the session end-to-end is that in real-world deployments
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.
Lastly, identifiers that might have been used to identify a session
end-to-end fail to meet that need when sessions are manipulated
through supplementary service interactions. For example, when a
session is transferred or if a PBX joins two communication sessions
together locally, the end-to-end properties of currently-defined
identifiers are lost.
This draft specifies the requirements for an end-to-end session
identifier. With this draft, the authors would like to encourage
discussion and progress work in the dispatch working group or working
group as designated by the IETF, the outcome of which will be a new
RFC that defines a session ID in conformance with these requirements.
2. Terminology
SIP defines additional terms used in this document that are specific
to the SIP domain such as "proxy"; "registrar"; "redirect server";
"user agent server" or "UAS"; "user agent client" or "UAC"; "back-to-
back user agent" or "B2BUA"; "dialog"; "transaction"; "server
transaction".
In this document, the word "session" refers to a
"communication session" that may exist between two SIP user agents or
that might pass through one or more intermediary devices, including
B2BUAs or SIP Proxies.
The term "end-to-end" in this document means the communication
session from the point of origin, passing through any number of
intermediaries, to the ultimate point of termination. It is
recognized that legacy devices may not support the "end-to-end"
session identifier, though an identifier might be created by an
intermediary when it is absent from the session signaling.
3. Requirements for the End-to-End Session Identifier
REQ1: It must be possible for an administrator or an external device
which monitors the SIP-traffic to use the identifier to identify a
set of dialogs which have a relationship with each other, such that
they represent the same SIP session, with as high a probability as
possible.
Jones, et al. Expires July 30, 2012 [Page 3]
Internet-Draft Requirements for End-To-End Session ID January 2012
REQ2: It must be possible to identify the end-to-end session when a
session is transferred or if two different sessions are joined
together via an intermediary (e.g., a PBX).
REQ3: It must be possible to identify all sessions participating in a
multipoint or multi-party conference by observing the end-to-end
session identifiers of each session.
REQ4: It must be possible to pass the identifier unchanged through
SIP B2BUAs or other intermediaries.
REQ5: The identifier must not reveal any information related to any
SIP device or domain identity, including IP Address, port, hostname,
domain name, username, Address-of-Record, MAC address, IP address
family, transport type, etc.
REQ6: The identifier must not reveal to the receiver of it that the
Call-ID, tags, or any other SIP header or body portion have been
changed by middleboxes, with as high a probability as possible.
REQ7: It must be possible to identity SIP traffic with an end-to-end
session identifier from and to end devices that do not support this
new identifier, such as by allowing an intermediary to inject an
identifier into the session signaling.
REQ8: The identifier should be unique in time and space, similar to
the Call-ID.
REQ9: The identifier should be constructed in such a way as to make
it suitable for transmission in SIP, H.323, RSVP [3], and RTCP [4].
4. Session Identifier Use Cases
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 or RTCP)
* Identification of devices taking part in the same multipoint
conference
Jones, et al. Expires July 30, 2012 [Page 4]
Internet-Draft Requirements for End-To-End Session ID January 2012
* Tracking sessions transferred from one endpoint to another
* Facilitate the recording of SIP sessions and correlating those
sessions
* Logging for the purposes of accounting, billing, debugging,
communication tracking (such as for security purposes in case of
theft of service), etc.
5. Related Work in other Standards Organizations
5.1. Coordination with the ITU-T
IP multimedia networks are often comprised of a mix of session
protocols like SIP and H.323. A benefit of the Session Identifier is
that it uniquely identifies a communication session end-to-end across
session protocol boundaries. Therefore, the need for coordinated
standardization activities across Standards Development Organizations
(SDOs) is imperative.
To facilitate this, a parallel effort is underway in the ITU-T to
introduce the Session Identifier for the H.323 protocol. The ITU-T
SG16 has approved contribution C.552 [5] as a work item with the
intent that it be a coordinated and synchronized effort between the
ITU-T and the IETF.
5.2. Requirements within 3GPP
3GPP identified in their Release 9 the need for a Session Identifier
for O&M purposes to correlate flows in an end-to-end communication
session. TS24.229 (IP multimedia call control protocol based on
Session Initiation Protocol (SIP) and Session Description Protocol
(SDP)) [6] points to the fact that the Session Identifier can be used
to correlate SIP messages belonging to the same session. In the case
where signaling passes through SIP entities like B2BUAs, the end-to-
end session identifier indicates that these dialogs belong to the
same end-to-end SIP communication session.
6. Security Considerations
An end-to-end identifier, if not properly constructed, could provide
information that would allow one to identify the individual, device,
or domain initiating or terminating a communication session. In
adherence with REQ5, the solution produced in accordance with these
requirements MUST NOT provide any information that allow one to
identify a person, device, or domain. This means that information
elements such as the MAC address or IP address MUST NOT be used when
constructing the end-to-end session identifier.
Jones, et al. Expires July 30, 2012 [Page 5]
Internet-Draft Requirements for End-To-End Session ID January 2012
7. IANA Considerations
There are no IANA considerations associated with this document.
8. Acknowledgments
The authors would like to acknowledge Chris Pearce for his
contribution and collaboration in developing this document.
This document was prepared using 2-Word-v2.0.template.dot.
9. References
9.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.
9.2. Informative References
[3] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September 1997.
[4] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real-
Time Applications", RFC 3550, July 2003.
[5] International Telecommunications Union, "End-to-End Session
Identifier for IP-based Multimedia Communication Systems",
March 2011, ITU-T Contribution C.552, http://ftp3.itu.int/av-
arch/avc-site/2009-2012/1103_Gen/SessionID.zip.
[6] 3GPP, "IP multimedia call control protocol based on Session
Initiation Protocol (SIP) and Session Description Protocol
(SDP); Stage 3", 3GPP TS 24.229 10.3.0, April 2011.
Jones, et al. Expires July 30, 2012 [Page 6]
Internet-Draft Requirements for End-To-End Session ID January 2012
Author's Addresses
Roland Jesske
Deutsche Telekom NP
64295 Darmstadt
Heinrich-Hertz-Str. 3-7
Germany
Phone: +49 6151 628 2766
Email: R.Jesske@telekom.de
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
Hadriel Kaplan
Acme Packet
71 Third Ave.
Burlington, MA 01803, USA
Email: hkaplan@acmepacket.com
Laura Liess
Deutsche Telekom NP
64295 Darmstadt
Heinrich-Hertz-Str. 3-7
Germany
Phone: +49 6151 268 2761
Email: laura.liess.dt@gmail.com
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: salvatore.loreto@ericsson.com
Jones, et al. Expires July 30, 2012 [Page 7]
Internet-Draft Requirements for End-To-End Session ID January 2012
James Polk
Cisco Systems, Inc.
3913 Treemont Circle
Colleyville, Texas,
USA
Phone: +1 817 271 3552
Email: jmpolk@cisco.com
IM: xmpp:jmpolk@cisco.com
Parthasarathi Ravindran
Cisco Systems, Inc.
Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103
India
E-Mail: partr@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]