idnits 2.17.1 draft-jones-insipid-session-id-reqts-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 193: '...nate on an H.323 endpoint. It MUST be...' RFC 2119 keyword, line 290: '... requirements MUST NOT provide any i...' RFC 2119 keyword, line 292: '...ss or IP address MUST NOT be used when...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 25, 2012) is 4323 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Paul E. Jones 3 Internet Draft Gonzalo Salgueiro 4 Intended status: Informational James Polk 5 Expires: December 25, 2012 Cisco Systems 6 Parthasarathi Ravindran 7 Sonus Networks 8 Laura Liess 9 Roland Jesske 10 Deutsche Telekom 11 Salvatore Loreto 12 Ericsson 13 Hadriel Kaplan 14 Acme Packet 15 June 25, 2012 17 Requirements for an End-to-End Session Identification in 18 IP-Based Multimedia Communication Networks 19 draft-jones-insipid-session-id-reqts-03.txt 21 Abstract 23 This document specifies the requirements for an end-to-end session 24 identifier in IP-based multimedia communication networks. This 25 identifier would enable endpoints, intermediate devices, and 26 management and monitoring systems to identify a session end-to-end, 27 associate multiple endpoints with a given multipoint conference, 28 track communication sessions when they are redirected, and associate 29 one or more media flows with a given communication session. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on December 25, 2012. 48 Copyright Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction...................................................2 66 2. Terminology....................................................3 67 3. Session Identifier Use Cases...................................3 68 3.1. Session Recording.........................................4 69 3.2. Protocol Interworking.....................................4 70 3.3. More Use Cases............................................5 71 4. Requirements for the End-to-End Session Identifier.............5 72 5. Related Work in other Standards Organizations..................6 73 5.1. Coordination with the ITU-T...............................6 74 5.2. Requirements within 3GPP..................................6 75 6. Security Considerations........................................6 76 7. IANA Considerations............................................7 77 8. Acknowledgments................................................7 78 9. References.....................................................7 79 9.1. Normative References......................................7 80 9.2. Informative References....................................7 81 Author's Addresses................................................8 83 1. Introduction 85 IP-based multimedia communication systems like SIP [1] and H.323 [2] 86 have the concept of a "call identifier" that is globally unique. The 87 identifier is intended to represents an end-to-end communication 88 session from the originating device to the terminating device. Such 89 an identifier is useful for troubleshooting, billing, session 90 tracking, and so forth. 92 Unfortunately, there are a number of factors that contribute to the 93 fact that the current call identifiers defined in SIP and H.323 are 94 not suitable for end-to-end session identification. Perhaps most 95 significant is the fact that the syntax for the call identifier in 96 SIP and H.323 is different between the two protocols. This important 97 fact makes it impossible for call identifiers to be exchanged end-to- 98 end when a network utilizes one or more session protocols. 100 Another reason why the current call identifiers are not suitable to 101 identify the session end-to-end is that in real-world deployments 102 devices like session border controllers often change the values as 103 the session signaling passes through. This is true even when a 104 single session protocol is employed and not a byproduct of protocol 105 interworking. 107 Lastly, identifiers that might have been used to identify a session 108 end-to-end fail to meet that need when sessions are manipulated 109 through supplementary service interactions. For example, when a 110 session is transferred or if a PBX joins two communication sessions 111 together locally, the end-to-end properties of currently-defined 112 identifiers are lost. 114 This draft specifies the requirements for an end-to-end session 115 identifier. With this draft, the authors would like to encourage 116 discussion and progress work in the dispatch working group or working 117 group as designated by the IETF, the outcome of which will be a new 118 RFC that defines a session ID in conformance with these requirements. 120 2. Terminology 122 SIP defines additional terms used in this document that are specific 123 to the SIP domain such as "proxy"; "registrar"; "redirect server"; 124 "user agent server" or "UAS"; "user agent client" or "UAC"; "back-to- 125 back user agent" or "B2BUA"; "dialog"; "transaction"; "server 126 transaction". 128 In this document, the word "session" refers to a 129 "communication session" that may exist between two SIP user agents or 130 that might pass through one or more intermediary devices, including 131 B2BUAs or SIP Proxies. 133 The term "end-to-end" in this document means the communication 134 session from the point of origin, passing through any number of 135 intermediaries, to the ultimate point of termination. It is 136 recognized that legacy devices may not support the "end-to-end" 137 session identifier, though an identifier might be created by an 138 intermediary when it is absent from the session signaling. 140 3. Session Identifier Use Cases 142 The Session Identifier is intended to uniquely identify a 143 communication session end-to-end. This document does not specify how 144 the Session Identifier is to be used, but merely defines the 145 identifier in such a way as to enable it to be used for situations 146 encountered in real-world deployments of IP-based multimedia 147 communication systems, including: 149 * End-to-end identification of a communication session 151 * End-to-end identification of a communication session that 152 includes a plurality of signaling protocol (e.g., SIP, H.323, and 153 XMPP) wherein a session might originate using one protocol and 154 terminate using a different protocol 156 * Association of session signaling and media flows, made possible 157 by including the session identifier in media-related messages 158 (e.g., RSVP or RTCP) 160 * Identification of devices taking part in the same multipoint 161 conference 163 * Tracking sessions transferred from one endpoint to another 165 * Facilitate the recording of SIP sessions and correlating those 166 sessions 168 * Logging for the purposes of accounting, billing, debugging, 169 communication tracking (such as for security purposes in case of 170 theft of service), etc. 172 { NOTE: the above simple use case examples are to be replaced with 173 more elaborate text as we have started to do below. Once all use 174 case text is submitted to the editor, the above simple cases will be 175 removed from the document. } 177 3.1. Session Recording 179 A SIP Session is established between UA-A and UA-B with a SIP B2BUA 180 acting as a middlebox. Both UA-A and UA-B establish a recording 181 session with a session recording server (SRS) using the SIPREC 182 protocol. The SRS needs to be able to determine from the metadata 183 provided by UA-A and UA-B that the media streams are associated with 184 the same communication session (CS). 186 Derived Requirements: REQ1, REQ3, REQ4 188 3.2. Protocol Interworking 190 A communication session might originate in an H.323 endpoint and pass 191 through a Session Border Controller before ultimately reaching a 192 terminating SIP user agent. Likewise, a call might originate on a 193 SIP user agent and terminate on an H.323 endpoint. It MUST be 194 possible to identify such sessions end-to-end across the plurality of 195 devices, networks, or administrative domains. 197 It is expected that the ITU-T will define protocol elements for H.323 198 to make the end-to-end signaling possible. 200 Derived Requirements: REQ7, REQ9a. 202 3.3. More Use Cases 204 { Additional use cased will be added as additional sub-sections. } 206 4. Requirements for the End-to-End Session Identifier 208 The following requirements are derived from the use cases and 209 additional constraints regarding the construction of the identifier. 211 REQ1: It must be possible for an administrator or an external device 212 which monitors the SIP-traffic to use the identifier to identify 213 those dialogs which were at some point in time components of a single 214 end-to-end SIP session (e.g., parts of the same call). 216 REQ1a: { Requirement 1 for non-dialog creating transactions. Text 217 solicited. } 219 REQ2: It must be possible to correlate two end-to-end sessions when a 220 session is transferred or if two different sessions are joined 221 together via an intermediary (e.g., a PBX). This might result in a 222 change in the value of the end-to-end Session-Identifier. 224 REQ3: It must be possible for a device other than the conference 225 focus to correlate sessions participating in a multipoint or multi- 226 party conference on a single focus by observing the end-to-end 227 session identifiers of each session. 229 REQ4: It must be possible to pass the identifier unchanged through 230 SIP B2BUAs or other intermediaries. 232 REQ5: The identifier must not reveal any information related to any 233 SIP user, device or domain identity. This includes any IP Address, 234 port, hostname, domain name, username, Address-of-Record, MAC 235 address, IP address family, transport type, subscriber ID, Call-ID, 236 tags, or other SIP header or body parts. 238 REQ7: It must be possible to identity SIP traffic with an end-to-end 239 session identifier from and to end devices that do not support this 240 new identifier, such as by allowing an intermediary to inject an 241 identifier into the session signaling. 243 REQ8: The identifier should be unique in time and space, similar to 244 the Call-ID. 246 REQ9a: The identifier should be constructed in such a way as to make 247 it suitable for transmission in SIP and H.323. 249 REQ9b: The identifier should be constructed in such a way as to make 250 it suitable for transmission in SIP and RSVP [3]. 252 REQ9c: The identifier should be constructed in such a way as to make 253 it suitable for transmission in SIP and RTCP [4]. 255 5. Related Work in other Standards Organizations 257 5.1. Coordination with the ITU-T 259 IP multimedia networks are often comprised of a mix of session 260 protocols like SIP and H.323. A benefit of the Session Identifier is 261 that it uniquely identifies a communication session end-to-end across 262 session protocol boundaries. Therefore, the need for coordinated 263 standardization activities across Standards Development Organizations 264 (SDOs) is imperative. 266 To facilitate this, a parallel effort is underway in the ITU-T to 267 introduce the Session Identifier for the H.323 protocol. The ITU-T 268 SG16 has approved contribution C.552 [5] as a work item with the 269 intent that it be a coordinated and synchronized effort between the 270 ITU-T and the IETF. 272 5.2. Requirements within 3GPP 274 3GPP identified in their Release 9 the need for a Session Identifier 275 for O&M purposes to correlate flows in an end-to-end communication 276 session. TS24.229 (IP multimedia call control protocol based on 277 Session Initiation Protocol (SIP) and Session Description Protocol 278 (SDP)) [6] points to the fact that the Session Identifier can be used 279 to correlate SIP messages belonging to the same session. In the case 280 where signaling passes through SIP entities like B2BUAs, the end-to- 281 end session identifier indicates that these dialogs belong to the 282 same end-to-end SIP communication session. 284 6. Security Considerations 286 An end-to-end identifier, if not properly constructed, could provide 287 information that would allow one to identify the individual, device, 288 or domain initiating or terminating a communication session. In 289 adherence with REQ5, the solution produced in accordance with these 290 requirements MUST NOT provide any information that allow one to 291 identify a person, device, or domain. This means that information 292 elements such as the MAC address or IP address MUST NOT be used when 293 constructing the end-to-end session identifier. 295 7. IANA Considerations 297 There are no IANA considerations associated with this document. 299 8. Acknowledgments 301 The authors would like to acknowledge Chris Pearce for his 302 contribution and collaboration in developing this document. 304 This document was prepared using 2-Word-v2.0.template.dot. 306 9. References 308 9.1. Normative References 310 [1] Rosenberg, J., et al., "SIP: Session Initiation Protocol", RFC 311 3261, June 2002. 313 [2] Recommendation ITU-T H.323, "Packet-based multimedia 314 communications systems", December 2009. 316 9.2. Informative References 318 [3] Braden, R., et al., "Resource ReSerVation Protocol (RSVP) -- 319 Version 1 Functional Specification", RFC 2205, September 1997. 321 [4] Schulzrinne, H., et al., "RTP: A Transport Protocol for Real- 322 Time Applications", RFC 3550, July 2003. 324 [5] International Telecommunications Union, "End-to-End Session 325 Identifier for IP-based Multimedia Communication Systems", 326 March 2011, ITU-T Contribution C.552, http://ftp3.itu.int/av- 327 arch/avc-site/2009-2012/1103_Gen/SessionID.zip. 329 [6] 3GPP, "IP multimedia call control protocol based on Session 330 Initiation Protocol (SIP) and Session Description Protocol 331 (SDP); Stage 3", 3GPP TS 24.229 10.3.0, April 2011. 333 Author's Addresses 335 Roland Jesske 336 Deutsche Telekom NP 337 64295 Darmstadt 338 Heinrich-Hertz-Str. 3-7 339 Germany 341 Phone: +49 6151 628 2766 342 Email: R.Jesske@telekom.de 344 Paul E. Jones 345 Cisco Systems, Inc. 346 7025 Kit Creek Rd. 347 Research Triangle Park, NC 27709 348 USA 350 Phone: +1 919 476 2048 351 Email: paulej@packetizer.com 352 IM: xmpp:paulej@packetizer.com 354 Hadriel Kaplan 355 Acme Packet 356 71 Third Ave. 357 Burlington, MA 01803, USA 359 Email: hkaplan@acmepacket.com 361 Laura Liess 362 Deutsche Telekom NP 363 64295 Darmstadt 364 Heinrich-Hertz-Str. 3-7 365 Germany 367 Phone: +49 6151 268 2761 368 Email: laura.liess.dt@gmail.com 370 Salvatore Loreto 371 Ericsson 372 Hirsalantie 11 373 Jorvas 02420 374 Finland 376 Email: salvatore.loreto@ericsson.com 377 James Polk 378 Cisco Systems, Inc. 379 3913 Treemont Circle 380 Colleyville, Texas, 381 USA 383 Phone: +1 817 271 3552 384 Email: jmpolk@cisco.com 385 IM: xmpp:jmpolk@cisco.com 387 Parthasarathi Ravindran 388 Sonus Networks, Inc. 389 Prestige Shantiniketan - Business Precinct 390 Whitefield Road 391 Bangalore, Karnataka 560066 392 India 394 Email: pravindran@sonusnet.com 396 Gonzalo Salgueiro 397 Cisco Systems, Inc. 398 7025 Kit Creek Rd. 399 Research Triangle Park, NC 27709 400 USA 402 Phone: +1 919 392 3266 403 Email: gsalguei@cisco.com 404 IM: xmpp:gsalguei@cisco.com