idnits 2.17.1 draft-loreto-sipping-context-id-requirements-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2009) is 5525 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-ietf-mediactrl-sip-control-framework-10 -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft S. Loreto 4 Intended status: Informational Ericsson 5 Expires: September 6, 2009 March 5, 2009 7 Requirements for Dialog Correlation in the Session Initiation Protocol 8 (SIP) 9 draft-loreto-sipping-context-id-requirements-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 6, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document justifies the need and lists the requirements for 48 correlating SIP (Session Initiation Protocol) dialogs. The 49 correlated dialogs may or may not be related to the same multimedia 50 session. Being able to logically correlate multiple SIP dialogs is 51 useful for applications that, for different reasons, need to 52 establish several SIP dialogs to provide a given service. The 53 logical correlation of two SIP dialogs is also useful, for instance, 54 to correlate an incoming with an outgoing dialog at a B2BUA. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Media Session correlation: Use Cases . . . . . . . . . . . . . 4 60 2.1. Using Two Separate UAs to Start a Conversation . . . . . . 4 61 2.2. Showing a Pre-recorded Video During a Conversation . . . . 4 62 2.3. Sending a File from a PC During a Conversation . . . . . . 5 63 2.4. Including Live Video in a Conversation . . . . . . . . . . 5 64 2.5. Including Remote Live Video in a Conversation . . . . . . 5 65 2.6. Using Two Separate UAs in a Conversation . . . . . . . . . 6 66 3. Dialogs correlation: Use Cases . . . . . . . . . . . . . . . . 6 67 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 4.1. Media Session correlation . . . . . . . . . . . . . . . . 7 69 4.2. Dialog correlation . . . . . . . . . . . . . . . . . . . . 7 70 4.3. Common requirements . . . . . . . . . . . . . . . . . . . 7 71 5. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. Informational References . . . . . . . . . . . . . . . . . . . 9 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 77 1. Introduction 79 This document shows the need to logically correlate multiple SIP 80 (Session Initiation Protocol) dialogs. The correlated dialogs may or 81 may not be related to the same multimedia session. 83 The SIP specification [RFC3261] defines a multimedia session as "an 84 exchange of data between an association of participants". SDP 85 (Session Description Protocol) is the default session description 86 format in SIP. The SDP (Session Description Protocol) specification 87 [RFC4566] defines a multimedia session as "a set of multimedia 88 senders and receivers and the data streams flowing from senders to 89 receivers". 91 Generally, a given participant uses a single SIP dialog to establish 92 (or participate in) a given multimedia session. For example, two SIP 93 user agents can use a SIP dialog between them to establish a 94 multimedia session consisting on an audio stream and a video stream. 95 Still, in some situations, several SIP dialogs are required to 96 establish a single multimedia session. In order to treat the 97 different media streams established by the different SIP dialogs as 98 part of a single media session, there is a need to correlate those 99 dialogs. 101 Also in many situations, the processing of a SIP call involves a 102 number of different SIP dialogs that can or can not be related to the 103 same multimedia session. A special case is the presence of the 104 B2BUA's and other middle-boxes in the end-to-end path. A B2BUA is a 105 logical entity that acts as both user agent server (UAS) and user 106 agent client (UAC), and then breaks an end-to-end SIP dialog in two 107 distinct SIP dialogs that are difficult to correlate outside the 108 context of the B2BUA. In order to treat those two different SIP 109 dialogs as part of a SIP call, there is a need to correlate those 110 dialogs. 112 The requirements to correlate different SIP dialogs as part of a 113 single media session and the requirements to correlate SIP dialogs 114 that belong to the same SIP session but not necessary involve media 115 seem to be semantically different. For this reason this document 116 contains two distinct set of requirement one for correlating "media 117 sessions" and different one to correlate "dialogs". 119 The remainder of this document is organized as follows. Section 2 120 contains use cases where multiple dialogs are required to establish a 121 multimedia session. Section 3 contains use cases where multiple 122 dialogs needs to be correlate using a unique identifier. Section 4 123 contains the two set of requirements for a mechanism to correlate SIP 124 dialogs. Section 5 analyzes existing mechanisms against the 125 requirements we have identified and concludes that a new mechanism 126 will need to be developed since there is no existing mechanism that 127 meets all of them. 129 2. Media Session correlation: Use Cases 131 This section lists use cases where the UAC or the UAS is distributed. 132 That is, the user initiating the session will use several UAs in 133 parallel during the session or the user receiving the session 134 invitation will use several UAs in parallel during the session. 136 2.1. Using Two Separate UAs to Start a Conversation 138 Laura is at her office. On her desk, she has a PC with a soft client 139 and a desk phone. The PC has a low-quality built-in microphone and 140 is connected to high-quality speakers. 142 Laura wants to establish a voice session with Bob using the desk 143 phone as the microphone and the soft client as the speaker. 145 Two SIP dialogs will be established: one between the desk phone and 146 Bob's UA and one between the soft client and Bob's UA. The former 147 dialog will establish a send-only (from Laura's perspective) audio 148 stream. The latter dialog will establish a receive-only (from 149 Laura's perspective) audio stream. 151 Laura wants Bob to treat the send-only audio stream from her 152 deskphone and the receive-only audio stream from her softclient as 153 part of the same communication space. That is, Laura wants Bob to 154 treat both streams as if both had been established using a single SIP 155 dialog. 157 2.2. Showing a Pre-recorded Video During a Conversation 159 Bob has a voice-only phone and an IP-TV device. Laura has an 160 integrated advanced multimedia phone with camera. 162 Bob is talking on his voice-only phone with Laura, who is on her 163 multimedia phone. 165 Bob wants to show Laura part of the TV show he recorded last night. 166 A SIP dialog between Bob's IP-TV device and Laura's UA needs to be 167 established. This dialog will establish a video stream. 169 Bob talks about the show with Laura on his voice-only phone while 170 Laura watches the show. 172 Bob wants Laura to treat the video stream from his IP-TV device and 173 the voice stream from his voice-only phone as part of the same 174 communication space. That is, Bob wants Laura to treat both streams 175 as if both had been established using a single SIP dialog. 177 2.3. Sending a File from a PC During a Conversation 179 Bob has a voice-only phone and a PC with a soft client. Laura has an 180 integrated advanced multimedia phone with support for file transfers. 182 Bob wants to send a file to Laura from his PC during his conversation 183 with Laura on his voice-only phone. 185 A SIP dialog between Bob's PC and Laura's multimedia phone needs to 186 be established. This dialog will establish a file transfer session. 188 Bob wants Laura to treat the file transfer from his PC and the voice 189 stream from his voice-only phone as part of the same communication 190 space. That is, Bob wants Laura to treat both streams as if both had 191 been established using a single SIP dialog. 193 2.4. Including Live Video in a Conversation 195 Bob has a voice-only phone and a PC which has a soft client, a 196 Webcam, and a low-quality built-in microphone. Laura has an 197 integrated advanced multimedia phone with camera. 199 Bob wants to send a live video to Laura from his PC during his 200 conversation with Laura. 202 A SIP dialog between Bob's PC and Laura's multimedia phone needs to 203 be established. This dialog will establish a video stream. 205 Bob wants Laura to treat the live video stream from his PC and the 206 voice stream from his voice-only phone as part of the same 207 communication space. That is, Bob wants Laura to treat both streams 208 as if both had been established using a single SIP dialog. 210 2.5. Including Remote Live Video in a Conversation 212 Bob, who is at his office, has a multimedia phone. At his summer 213 cottage, Bob has a webcam-phone (e.g. a video-surveillance system). 214 Laura has an integrated advanced multimedia phone with a camera. 216 During his conversation with Laura, Bob wants to show her the new 217 summer cottage he just bought. A SIP dialog between Bob's webcam 218 phone at this summer cottage and Laura's multimedia phone needs to be 219 established. This dialog will establish a video stream. 221 Bob wants Laura to treat the live video stream from his webcam-phone 222 and the voice stream from his voice-only phone as part of the same 223 communication space. That is, Bob wants Laura to treat both streams 224 as if both had been established using a single SIP dialog. 226 2.6. Using Two Separate UAs in a Conversation 228 Laura has a PC with a softclient and a desk phone. Bob has an 229 integrated advanced multimedia phone with camera. 231 Laura receives on her desk phone an incoming voice-video call from 232 Bob. 234 Laura decides to answer the Bob's session invitation by establishing 235 a voice session with Bob using the desk phone and the video session 236 using her multimedia phone. Two SIP dialogs need to be established: 237 one between Bob's UA and Laura's desk phone and one between Bob's UA 238 and Laura's multimedia phone. 240 Laura wants Bob to treat the audio stream from her deskphone and the 241 video stream from her softclient as part of the same communication 242 space. That is, Laura wants Bob to treat both streams as if both had 243 been established using a single SIP dialog. 245 3. Dialogs correlation: Use Cases 247 This section lists use cases where multiple dialogs need to be 248 correlate. 250 1. Certain SIP applications need to reference dialogs in out-of- 251 dialog requests at a layer above the SIP message dialog matching 252 rules, and wish it to work across B2BUA domains. 253 For example, the SIP Media Control Channel Framework 254 [I-D.ietf-mediactrl-sip-control-framework] needs to reference a 255 dialog identifier used between a UAC and UAS by a third party. 256 The mechanism originally used the Call-ID and remote/local-tags 257 for such matching, but changed due to concerns over B2BUA's 258 changing them, and now uses a new "cfw-id" SDP attribute instead 259 which does not rely on the Call-ID value. 261 2. Multiple RFC 3265 Event packages use the Call-ID value in their 262 package bodies to reference established sessions, even though they 263 don't actually need to match a Call-ID per se - and should work 264 across B2BUA domains. 266 3. The call admission control (CAC) only allows SIP INVITE requests 267 if the network has sufficient bandwidth for the given SDP. 268 However if a call request is forked by B2BUA's, or crosses them, 269 the CAC model treats each fork as a separate call because there is 270 no mechanism to tie them together. This leads to rejected forks 271 due to CAC, when they should have been allowed to proceed. 272 Currently proprietary SIP headers are used for this purpose. 274 5. Troubleshooting SIP sessions becomes complicated when multiple 275 legs of the session are on different sides of B2BUA's, because it 276 is impossible to correlate the legs together. 277 Currently proprietary mechanisms are used to achieve this. 279 6. When SIP requests cross B2BUA's, the only form of loop detection 280 that will stop a loop is the Max-Forwards hop-count limit being 281 reached (value reaching zero). Via header values are removed by 282 B2BUA's, so both spirals and simple loops cannot be detected by 283 Via branch-parameter matching. 284 A mechanism to correlate legs of the sessions on both sides of 285 B2BUA's could be used to limit or avoid the loop. 287 4. Requirements 289 4.1. Media Session correlation 291 REQ1 It must be possible to correlate an already existing dialog or 292 dialogs with a new dialog or dialogs as relating to the same media 293 session. 295 4.2. Dialog correlation 297 REQ1 It must be possible to identify a set of dialogs which have a 298 direct correlation with each other such that they represent the 299 same SIP session, with as high a probability as possible. 301 4.3. Common requirements 303 REQ1 It must be possible, when establishing a dialog, to specify 304 that it be correlated with one or more already existing dialogs, 305 which dialogs, at the time they were created, did not need to 306 specify that they might be correlated with in the future. 308 REQ2 The state information associated to the correlation among a set 309 of SIP dialogs must expire (i.e., can be discarded) when the last 310 of the SIP dialogs is terminated. 312 REQ3 UAs that do not implement the correlation mechanism and, thus, 313 do not understand the correlation information they received should 314 be able to handle the individual SIP dialogs that were supposed to 315 be correlated as well as possible. That is, the correlation 316 mechanism should not keep them from trying to handle the SIP 317 dialogs. 319 REQ4 It must be possible to correlate outside the context of the 320 B2BUA the dialog entering with the one leaving a B2BUA. 321 This requirement drives the following requirements: 323 REQ4.1 It must be possible for correlated dialogs that pass 324 through B2BUA'2 to continue to be correlate. 326 REQ4.2 The correlation mechanism must not reveal any information 327 related to any SIP device or domain identity, including IP 328 Address, port, hostname, domain name, username, Address-of- 329 Record, MAC address, IP address family, transport type, etc. 331 REQ4.3 The correlation mechanism not reveal to the receiver of it 332 that the Call-ID, tags, or any other SIP header or body portion 333 have been changed by middle-boxes, with as high a probability 334 as possible. 336 5. Existing Mechanisms 338 This section analyses existing mechanisms against the requirements we 339 have identified. Currently, there is no mechanism that meets those 340 requirements. Thus, a new mechanism will need to be develop in order 341 to meet those requirements. 343 SIP Service Control [RFC3087] proposes to communicate context 344 information using a distinctive Request URI. However, dialogs to be 345 correlated do not necessary share the same Request URI. 347 The Join header field [RFC3911] allows inserting a new participant 348 into a given conversation space. However, the Join operation is 349 normally used to create or join a conference. It adds a dialog to 350 the conversation space associated with the matched dialog and 351 performs a media mixing or media combining. Therefore, while the 352 mechanics of the Join mechanism are suitable to correlate dialogs, 353 the semantics for the correlations created by Join are different than 354 the ones described in the previous requirements. 356 The Third Part Call Control mechanism [RFC3725] allows the caller to 357 make transparent for the callee the fact that it is using separate 358 devices for different media, and then making everything in one dialog 359 for the callee. However there are use cases where it is preferable 360 not to use a centralized and heavy mechanism as 3pcc but instead 361 using a distributed and lighter mechanism. Moreover in 3pcc, the 362 Controller is a central point for signaling, it has complete control 363 over the call and then it needs to be involved for all the session 364 time. With a correlation mechanism the UA that establishes the first 365 dialog does not necessarily need to be involved all the session time. 366 It could leave the session before the whole session ends. 368 6. Security Considerations 370 To be done. 372 7. IANA Considerations 374 This document does not require any actions by the IANA. 376 8. Informational References 378 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 379 A., Peterson, J., Sparks, R., Handley, M., and E. 380 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 381 June 2002. 383 [I-D.ietf-mediactrl-sip-control-framework] 384 Boulton, C., Melanchuk, T., and S. McGlashan, "Media 385 Control Channel Framework", 386 draft-ietf-mediactrl-sip-control-framework-10 (work in 387 progress), February 2009. 389 [RFC3087] Campbell, B. and R. Sparks, "Control of Service Context 390 using SIP Request-URI", RFC 3087, April 2001. 392 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 393 Description Protocol", RFC 4566, July 2006. 395 [RFC3911] Mahy, R. and D. Petrie, "The Session Initiation Protocol 396 (SIP) "Join" Header", RFC 3911, October 2004. 398 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 399 Camarillo, "Best Current Practices for Third Party Call 400 Control (3pcc) in the Session Initiation Protocol (SIP)", 401 BCP 85, RFC 3725, April 2004. 403 Authors' Addresses 405 Gonzalo Camarillo 406 Ericsson 407 Hirsalantie 11 408 Jorvas 02420 409 Finland 411 Email: gonzalo.camarillo@ericsson.com 413 Salvatore Loreto 414 Ericsson 415 Hirsalantie 11 416 Jorvas 02420 417 Finland 419 Email: salvatore.loreto@ericsson.com