Requirements for an End-to-End Session Identification in IP-Based Multimedia Communication Networks
draft-ietf-insipid-session-id-reqts-00

The information below is for an old version of the document
Document Type Active Internet-Draft (insipid WG)
Authors Paul Jones  , Gonzalo Salgueiro  , James Polk  , Laura Liess  , Hadriel Kaplan 
Last updated 2012-07-07
Replaces draft-jones-insipid-session-id-reqts
Stream Internet Engineering Task Force (IETF)
Formats pdf htmlized (tools) htmlized bibtex
Reviews
Stream WG state WG Document
Document shepherd None
IESG IESG state I-D Exists
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                      Paul E. Jones
Internet Draft                                         Gonzalo Salgueiro
Intended status: Informational                                James Polk
Expires: January 7, 2013                                   Cisco Systems
                                                             Laura Liess
                                                        Deutsche Telekom
                                                          Hadriel Kaplan
                                                             Acme Packet
                                                            July 7, 2012

         Requirements for an End-to-End Session Identification in
                IP-Based Multimedia Communication Networks
                draft-ietf-insipid-session-id-reqts-00.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, and
   track communication sessions when they are redirected.

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 January 7, 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

Jones, et al.          Expires January 7, 2013                  [Page 1]
Internet-Draft  Requirements for End-To-End Session ID         July 2012

   (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. Session Identifier Use Cases...................................3
      3.1. Session Recording.........................................4
      3.2. Protocol Interworking.....................................4
      3.3. More Use Cases............................................4
   4. Requirements for the End-to-End Session Identifier.............5
   5. Related Work in other Standards Organizations..................6
      5.1. Coordination with the ITU-T...............................6
      5.2. Requirements within 3GPP..................................6
   6. Security Considerations........................................6
   7. IANA Considerations............................................6
   8. Acknowledgments................................................7
   9. References.....................................................7
      9.1. Normative References......................................7
      9.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
   devices like session border controllers often change the values as
   the session signaling passes through.  This is true even when a

Jones, et al.          Expires January 7, 2013                  [Page 2]
Internet-Draft  Requirements for End-To-End Session ID         July 2012

   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. 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

     * End-to-end identification of a communication session that
       includes a plurality of signaling protocol (e.g., SIP, H.323, and

Jones, et al.          Expires January 7, 2013                  [Page 3]
Internet-Draft  Requirements for End-To-End Session ID         July 2012

       XMPP) wherein a session might originate using one protocol and
       terminate using a different protocol

     * Identification of devices taking part in the same multipoint
       conference

     * 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.

   { NOTE: the above simple use case examples are to be replaced with
   more elaborate text as we have started to do below.  Once all use
   case text is submitted to the editor, the above simple cases will be
   removed from the document. }

3.1. 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.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: REQ7, REQ9a.

3.3. More Use Cases

   { Additional use cased will be added as additional sub-sections. }

Jones, et al.          Expires January 7, 2013                  [Page 4]
Internet-Draft  Requirements for End-To-End Session ID         July 2012

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 which were at some point in time components of a single
   end-to-end SIP session (e.g., parts of the same call).

   REQ1a: { Requirement 1 for non-dialog creating transactions.  Text
   solicited. }

   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.

   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.

   REQ9b: The identifier should be constructed in such a way as to make
   it suitable for transmission in SIP and RSVP [3].

   REQ9c: The identifier should be constructed in such a way as to make
   it suitable for transmission in SIP and RTCP [4].

Jones, et al.          Expires January 7, 2013                  [Page 5]
Internet-Draft  Requirements for End-To-End Session ID         July 2012

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.

7. IANA Considerations

   There are no IANA considerations associated with this document.

Jones, et al.          Expires January 7, 2013                  [Page 6]
Internet-Draft  Requirements for End-To-End Session ID         July 2012

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 January 7, 2013                  [Page 7]
Internet-Draft  Requirements for End-To-End Session ID         July 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 January 7, 2013                  [Page 8]
Internet-Draft  Requirements for End-To-End Session ID         July 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 January 7, 2013                  [Page 9]