Network Working Group Paul E. Jones Internet Draft Gonzalo Salgueiro Intended status: Informational James Polk Expires: March 14, 2013 Cisco Systems Laura Liess Deutsche Telekom Hadriel Kaplan Acme Packet September 14, 2012 Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks draft-ietf-insipid-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 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 March 14, 2013. 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 Jones, et al. Expires March 14, 2013 [Page 1] Internet-Draft Requirements for End-To-End Session ID September 2012 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. Session Identifier Use Cases...................................3 3.1. End-to-end identification of a communication session......3 3.2. Session Recording.........................................4 3.3. Protocol Interworking.....................................4 3.4. Traffic Monitoring........................................4 3.5. Identification of devices in the same conference..........5 3.6. Tracking transferred sessions.............................5 3.7. Session Signal Logging....................................5 3.8. Identifier Porting to Other Protocols - RTCP..............5 3.9. 3PCC Use Case.............................................6 4. Requirements for the End-to-End Session Identifier.............6 5. Related Work in other Standards Organizations..................7 5.1. Coordination with the ITU-T...............................7 5.2. Requirements within 3GPP..................................8 6. Security Considerations........................................8 7. IANA Considerations............................................8 8. Acknowledgments................................................8 9. References.....................................................8 9.1. Normative References......................................8 9.2. Informative References....................................8 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 March 14, 2013 [Page 2] Internet-Draft Requirements for End-To-End Session ID September 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 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. 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 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. Session Identifier Use Cases 3.1. End-to-end identification of a communication session 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 per transaction 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, have each message within the same dialog MUST use the same identifier. Derived Requirements: All Requirements in Section 4 Jones, et al. Expires March 14, 2013 [Page 3] Internet-Draft Requirements for End-To-End Session ID September 2012 3.2. Session Recording A SIP Session is established between UA A and UA B with a SIP B2BUA acting as a middlebox. Both UA A and UA B establish a recording session with a session recording server (SRS) using the SIPREC protocol. The SRS needs to be able to determine from the metadata provided by UA A and UA B that the media streams are associated with the same communication session (CS). Derived Requirements: REQ1, REQ3, REQ4 3.3. 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: REQ7, REQ9a 3.4. 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 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, REQ4, REQ5, REQ8. b) Only the UA A supports the end-to-end Session Identifier, the UA B does not. Derived Requirements: REQ1, REQ4, REQ5, REQ7, REQ8. Jones, et al. Expires March 14, 2013 [Page 4] Internet-Draft Requirements for End-To-End Session ID September 2012 c) UA A and UA B do not support the end-to-end Session Identifier. Derived Requirements: REQ1, REQ4, REQ5, REQ7, REQ8 3.5. Identification of devices in the same conference SIP messaging can easily be multipoint in nature, specifically with several UAs communicating with a multipoint control unit (MCU) as part of a conference. The ability to distinguish all participants in single focus based multipoint conference to be identified as in the same communications session with all the other participants (i.e., in a single star configuration), verses in another conference session. Derived Requirements: REQ3 3.6. 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. The ability to track communications sessions as they are transferred, one side at a time, through until completion of the session (i.e., until a BYE is sent). Derived Requirements: REQ1, REQ2, REQ10 3.7. Session Signal Logging An after the fact search of SIP messages to determine which 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 accounting, billing, debugging, communication tracking (such as for security purposes in case of theft of service), etc. Derived Requirements: REQ1, REQ4, REQ7, REQ8 3.8. Identifier Porting to Other Protocols - RTCP There may be a desire to associate SIP session signaling with corresponding media flows. To facilitate this association, it should be possible to insert the Session-ID into a media-related message, such as an RTCP sender report message. This association would allow, as an example, for network monitoring equipment to associate troubled network flows with the end-to-end SIP session signaling. Jones, et al. Expires March 14, 2013 [Page 5] Internet-Draft Requirements for End-To-End Session ID September 2012 Derived Requirements: REQ9c 3.9. 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 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 1 - 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. Derived Requirements: REQ10 4. 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 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). This might result in a change in the value of the end-to-end Session-Identifier. Jones, et al. Expires March 14, 2013 [Page 6] Internet-Draft Requirements for End-To-End Session ID September 2012 REQ3: It must be possible for a device other than the conference focus to correlate sessions participating in a multipoint or multi- party conference on a single focus 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 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. 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. REQ9a: The identifier should be constructed in such a way as to make it suitable for transmission in SIP and H.323. REQ9c: The identifier should be constructed in such a way as to make it suitable for transmission in SIP and RTCP [4]. REQ10: 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]. 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. Jones, et al. Expires March 14, 2013 [Page 7] Internet-Draft Requirements for End-To-End Session ID September 2012 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. 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. Jones, et al. Expires March 14, 2013 [Page 8] Internet-Draft Requirements for End-To-End Session ID September 2012 [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 March 14, 2013 [Page 9] Internet-Draft Requirements for End-To-End Session ID September 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 March 14, 2013 [Page 10] Internet-Draft Requirements for End-To-End Session ID September 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 Sonus Networks, Inc. Prestige Shantiniketan - Business Precinct Whitefield Road Bangalore, Karnataka 560066 India Email: pravindran@sonusnet.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 March 14, 2013 [Page 11]