Network Working Group Paul E. Jones
Internet Draft Gonzalo Salgueiro
Intended status: Informational James Polk
Expires: July 9, 2013 Cisco Systems
Laura Liess
Deutsche Telekom
Hadriel Kaplan
Acme Packet
January 9, 2013
Requirements for an End-to-End Session Identification in
IP-Based Multimedia Communication Networks
draft-ietf-insipid-session-id-reqts-04.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
across multiple SIP devices, hops, and administrative domains.
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 9, 2013.
Copyright Notice
Copyright (c) 2013 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
Jones, et al. Expires July 9, 2013 [Page 1]
Internet-Draft Requirements for End-To-End Session ID January 2013
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. Conventions used in this document..............................3
3. Terminology....................................................3
4. Session Identifier Use Cases...................................4
4.1. End-to-end identification of a communication session......4
4.2. Protocol Interworking.....................................4
4.3. Traffic Monitoring........................................4
4.4. Tracking transferred sessions.............................5
4.5. Session Signal Logging....................................5
4.6. Identifier Syntax.........................................6
4.7. 3PCC Use Case.............................................6
5. Requirements for the End-to-End Session Identifier.............6
6. Related Work in other Standards Organizations..................7
6.1. Coordination with the ITU-T...............................7
6.2. Requirements within 3GPP..................................8
7. Security Considerations........................................8
8. IANA Considerations............................................8
9. Acknowledgments................................................8
10. Contributors..................................................8
11. References....................................................9
11.1. Normative References.....................................9
11.2. Informative References...................................9
Author's Addresses...............................................10
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 9, 2013 [Page 2]
Internet-Draft Requirements for End-To-End Session ID January 2013
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 Back-to-Back User Agents 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 or merges two communication
sessions together locally, the end-to-end properties of currently-
defined identifiers are lost.
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] 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.
3. 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"; "user
agent" (UA); "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 and that may pass
through one or more intermediary devices, including B2BUAs or SIP
proxies. A communication session consists of one of more SIP
transactions. A very simple communication session may be a single
out-of-dialog SIP transaction (e.g., MESSAGE/200). In the case of a
SIP dialog, the SIP message exchange includes a dialog creating
INVITE transaction, and zero of more subsequent SIP transactions
within the same dialog (e.g., ACK, re-INVITE, BYE). Due to the
existence of middle boxes, there may be multiple related SIP
transactions or dialogs chained together along the path from one end
of the communication session to the other. For example:
A Middlebox B
SIP trans1 -----------------> SIP trans 2
SIP dialog 1 <-------------- SIP dialog 2
Figure 1 - Communication Session through a Middlebox
Jones, et al. Expires July 9, 2013 [Page 3]
Internet-Draft Requirements for End-To-End Session ID January 2013
In such cases, the two SIP transactions or dialogs are part of a
single communication session.
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.
4. Session Identifier Use Cases
4.1. End-to-end identification of a communication session
For SIP messaging that either does not involve SIP servers or only
involves SIP proxies, the Call-ID header value sufficiently
identifies each SIP message within a transaction or dialog. This is
not the case when either B2BUAs or SBCs are in the signaling path
between UAs. Therefore, we need the ability to identify each
communication session through a single SIP header-value regardless of
which type of SIP servers are in the signaling path between UAs. For
transactions that create a dialog, each message within the same
dialog MUST use the same identifier.
Derived Requirements: All Requirements in Section 4
4.2. Protocol Interworking
A communication session might originate in an H.323 endpoint and pass
through a Session Border Controller before ultimately reaching a
terminating SIP user agent. Likewise, a call might originate on a SIP
user agent and terminate on an H.323 endpoint. It MUST be possible to
identify such sessions end-to-end across the plurality of devices,
networks, or administrative domains.
It is expected that the ITU-T will define protocol elements for H.323
to make the end-to-end signaling possible.
Derived Requirements: REQ5, REQ7
4.3. Traffic Monitoring
UA A and UA B communicate using SIP messaging with a SIP B2BUA acting
as a middlebox which belongs to a SIP service provider. For privacy
reasons, the B2BUA changes the SIP headers that reveal information
Jones, et al. Expires July 9, 2013 [Page 4]
Internet-Draft Requirements for End-To-End Session ID January 2013
related to the SIP users, device or domain identity. The service
provider uses an external device to monitor and log all SIP traffic
coming to and from the B2BUA. In the case of failures reported by
the customer or when security issue arise (e.g. theft of service),
the service provider has to analyze the logs from the past several
days or weeks and correlates those messages which were messages for a
single end-to-end SIP session.
For this scenario, we must consider three particular use cases:
a) The UAs A and B support the end-to-end Session Identifier.
Derived Requirements: REQ1, REQ3, REQ4, REQ6.
b) Only the UA A supports the end-to-end Session Identifier, the UA
B does not.
Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6.
c) UA A and UA B do not support the end-to-end Session Identifier.
Derived Requirements: REQ1, REQ3, REQ4, REQ5, REQ6
4.4. Tracking transferred sessions
It is difficult to track which SIP messages where involved in the
same call across transactions, especially when invoking supplementary
services such as call transfer or call join. There exists a need for
the ability to track communications sessions as they are transferred,
one side at a time, until completion of the session (i.e., until a
BYE is sent).
Derived Requirements: REQ1, REQ2, REQ9
4.5. Session Signal Logging
An after-the-fact search of SIP messages to determine which messages
were part of the same transaction or call is difficult when B2BUAs
and SBCs are involved in the signaling between UAs. Mapping more
than one Call-ID together can be challenging because all of the
values in SIP headers on one side of the B2BUA or SBC will likely be
different than those on the other side. If multiple B2BUAs and/or
SBCs are in the signaling path, more than two sets of header values
will exist, creating more of a challenge. Creating a common header
value through all SIP entities will greatly reduce any challenge for
the purposes of debugging, communication tracking (such as for
security purposes in case of theft of service), etc.
Derived Requirements: REQ1, REQ3, REQ5, REQ6
Jones, et al. Expires July 9, 2013 [Page 5]
Internet-Draft Requirements for End-To-End Session ID January 2013
4.6. Identifier Syntax
A syntax that is too restrictive (e.g., one that allows special
characters or a very long identifier) would make it difficult to
encode the identifier in other protocols. Therefore, the syntax of
the identifier should be reasonably restrictive.
Derived Requirements: REQ8
4.7. 3PCC Use Case
Third party call control refers to the ability of an entity to create
a call in which communication is actually between two or more
parties. For example, a B2BUA acting as a third party controller
could establish a call between two SIP UA's using 3PCC procedures as
described in section 4.1 of RFC 3725 [7], the flow for which is
reproduced below.
A Controller B
|(1) INVITE no SDP | |
|<------------------| |
|(2) 200 offer1 | |
|------------------>| |
| |(3) INVITE offer1 |
| |------------------>|
| |(4) 200 OK answer1 |
| |<------------------|
| |(5) ACK |
| |------------------>|
|(6) ACK answer1 | |
|<------------------| |
|(7) RTP | |
|.......................................|
Figure 2 - Session-ID 3PCC Scenario
Such a flow must result in a single session identifier being used for
the communication session between UA A and UA B. This use case does
not extend to three SIP UAs.
Derived Requirements: REQ9
5. Requirements for the End-to-End Session Identifier
The following requirements are derived from the use cases and
additional constraints regarding the construction of the identifier.
REQ1: It must be possible for an administrator or an external device
which monitors the SIP-traffic to use the identifier to identify
Jones, et al. Expires July 9, 2013 [Page 6]
Internet-Draft Requirements for End-To-End Session ID January 2013
those dialogs, transactions and messages which were at some point in
time components of a single end-to-end SIP session (e.g., parts of
the same call).
REQ2: It must be possible to correlate two end-to-end sessions when a
session is transferred or if two different sessions are joined
together via an intermediary (e.g., a PBX).
REQ3: The solution must require that the identifier, if present, pass
unchanged through SIP B2BUAs or other intermediaries.
REQ4: The identifier must not reveal any information related to any
SIP user, device or domain identity. This includes any IP Address,
port, hostname, domain name, username, Address-of-Record, MAC
address, IP address family, transport type, subscriber ID, Call-ID,
tags, or other SIP header or body parts.
REQ5: 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.
REQ6: The identifier should be unique in time and space, similar to
the Call-ID.
REQ7: The identifier should be constructed in such a way as to make
it suitable for transmission in SIP and H.323.
REQ8: The identifier should use a restricted syntax and length so as
to allow the identifier to be used in other protocols.
REQ9: It must be possible to correlate two end-to-end sessions when
the sessions are created by a third party controller using 3PCC
procedures shown in Figure 1 of RFC 3725 [7].
6. Related Work in other Standards Organizations
6.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
Jones, et al. Expires July 9, 2013 [Page 7]
Internet-Draft Requirements for End-To-End Session ID January 2013
intent that it be a coordinated and synchronized effort between the
ITU-T and the IETF.
6.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.
7. 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 REQ4, 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.
8. IANA Considerations
There are no IANA considerations associated with this document.
9. Acknowledgments
The authors would like to acknowledge Paul Kyzivat, Christer
Holmberg, Andy Hutton, Salvatore Loreto, Keith Drage, Chris Pearce
for their contribution and collaboration in developing this document.
This document was prepared using 2-Word-v2.0.template.dot.
10. Contributors
Two other people originally participated as co-authors and provided
substantial contributions to this document, namely Roland Jesske,
Parthasarathi Ravindran.
Jones, et al. Expires July 9, 2013 [Page 8]
Internet-Draft Requirements for End-To-End Session ID January 2013
11. References
11.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.
11.2. Informative References
[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.
[7] Rosenberg, J., Peterson, J., Schulzrinne, H., Camarillo, G.,
"Best Current Practices for Third Party Call Control (3pcc) in
the Session Initiation Protocol (SIP)", RFC 3725, April 2004.
Jones, et al. Expires July 9, 2013 [Page 9]
Internet-Draft Requirements for End-To-End Session ID January 2013
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
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
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
Gonzalo Salgueiro
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Phone: +1 919 392 3266
Jones, et al. Expires July 9, 2013 [Page 10]
Internet-Draft Requirements for End-To-End Session ID January 2013
Email: gsalguei@cisco.com
IM: xmpp:gsalguei@cisco.com
Jones, et al. Expires July 9, 2013 [Page 11]