idnits 2.17.1 draft-loreto-sipping-dialog-correlation-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 639. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 616. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 629. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 25, 2006) is 6513 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 375, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 384, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 414, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 418, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 421, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 424, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 426, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 429, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2617 (ref. '8') (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 3851 (ref. '11') (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '13') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2976 (ref. '15') (Obsoleted by RFC 6086) == Outdated reference: A later version (-05) exists of draft-shacham-sipping-session-mobility-02 Summary: 6 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group S. Loreto 3 Internet-Draft G. Camarillo 4 Expires: December 27, 2006 Ericsson 5 June 25, 2006 7 The Session Initiation Protocol (SIP) Dialog Correlation 8 draft-loreto-sipping-dialog-correlation-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 27, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 This document defines a new header field for use with SIP. The Same- 42 Session header field is used to logically correlate an existing SIP 43 dialog with a new SIP dialog when the media sessions established by 44 both dialogs can be considered a single logical session. This 45 mechanism can be used to share the user interface and other resources 46 between all the media streams from both sessions. 48 Table of Contents 50 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Use case . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Same-Session Header Field Syntax . . . . . . . . . . . . . . . 4 55 6. User Agent Server Behavior . . . . . . . . . . . . . . . . . . 4 56 7. User Agent Client Behavior . . . . . . . . . . . . . . . . . . 6 57 8. New Same-Session Option Tag . . . . . . . . . . . . . . . . . 6 58 9. Usage Example . . . . . . . . . . . . . . . . . . . . . . . . 7 59 9.1. Correlate a Dialog . . . . . . . . . . . . . . . . . . . . 7 60 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 11.1. Registration of Same-Session SIP header field . . . . . . 9 63 11.2. Registration of Same-Session SIP Option-tag . . . . . . . 9 64 12. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 13.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 13.2. Informational References . . . . . . . . . . . . . . . . . 9 68 Appendix A. Same Session header AND Third Party Call Controll . 11 69 Appendix A.1. Example: preconditions using the Same-Session 70 Header . . . . . . . . . . . . . . . . . . . . . . . 11 71 Appendix A.2. Example: preconditions using the 3pcc . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 73 Intellectual Property and Copyright Statements . . . . . . . . . . 16 75 1. Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [3]. 81 2. Overview 83 This document defines a new SIP [5] header field: Same-Session. The 84 Same-Session header field is used to logically correlate an existing 85 SIP dialog with a new SIP dialog when the media sessions established 86 by both dialogs can be considered a single logical session. This is 87 especially useful in peer-to-peer call control environments. 89 While is possible insert a new participant into a multimedia 90 conversation with the Join header field [6], the Join operation is 91 normally used to create or join a conference. It adds a dialog to 92 the conversation space associated with the matched dialog and 93 performs a media mixing or media combining. 95 Instead, the Same-Session operation inserts a new dialog into a 96 multimedia conversation. It enables a dialog to share all the 97 resources and the user interface with the matched dialog. 99 Obviously it is also possible to achive the Same-Session operetion 100 effect using Third Party Call Controll (3pcc) [18] and the SIP 101 Session Mobility [20]. However there are various disadvantages in 102 the use of 3pcc. 104 Appendix A provides some concrete examples regarding the different 105 complexity level using the 3pcc or the Same-Session header. 107 3. Requirements 109 This specification was created in order to meet the following 110 requirement: 112 It should be possible for a user agent to correlate two dialogs so 113 that all the media streams associated to them are treated as a single 114 media session. 116 4. Use case 118 Alice establishes a voice session with Bob. Alice wants add video to 119 the session using her SIP-enabled camera. Alice sends a REFER to her 120 camera, which has SIP user agent on it, so that her camera sends an 121 INVITE request to Bob in order to establish a video stream. Alice 122 wants Bob to treat the video stream from her camera and the voice 123 stream from her voice-only user agent as part of the same media 124 session. That is, Alice wants Bob to treat both streams as if both 125 had been established using a single SIP dialog. 127 5. Same-Session Header Field Syntax 129 The following is the augmented Backus-Naur Form (BNF) syntax [2] of 130 the Same-Session header field: 132 Same-Session = "Same-Session" HCOLON callid * (SEMI same-session-param) 133 same-session-param = to-tag / form-tag / strictly-flag / generic-param 134 to-tag = "to-tag" EQUAL token 135 from-tag = "from-tag" EQUAL token 137 Examples: 139 Same-Session: 98732@sip.example.com 140 ;from-tag=r33th4x0r 141 ;to-tag=ff87ff 143 Same-Session: 12adf2f34456gs5;to-tag=12345;from-tag=54321;strictly 145 Same-Session: 87134@171.161.34.23;to-tag=24796;from-tag=0 147 6. User Agent Server Behavior 149 The Same-Session header field contains information used to match an 150 existing SIP dialog (Call-ID, to-tag, and from-tag). Upon receiving 151 an INVITE with a Same-Session header field, the UA (User Agent) 152 attempts to match this information with a confirmed or early dialog. 153 The to-tag and from-tag parameters are matched as if they were tags 154 present in an incoming request. In other words the to-tag parameter 155 is compared to the local tag, and the from-tag parameter is compared 156 to the remote tag. 158 If more than one Same-Session header field is present in an INVITE, 159 or if a Same-Session header field is present in a request other than 160 INVITE, the UAS (User Agent Server) MUST reject the request with a 161 400 (Bad Request) response. 163 The Same-Session header has specific call control semantics. If both 164 a Same-Session header field and another header field with 165 contradictory semantics (for example a Replaces [7] header field) are 166 present in a request, the request MUST be rejected with a 400 (Bad 167 Request) response. 169 If the Same-Session header field matches more than one dialog, the UA 170 MUST act as if no match is found. 172 If no match is found, the UAS rejects the INVITE and returns a 481 173 (Call/Transaction Does Not Exist) response. Likewise, if the Same- 174 Session header field matches a dialog which was not created with an 175 INVITE, the UAS MUST reject the request with a 481 (Call/Transaction 176 Does Not Exist) response. 178 If the Same-Session header field matches a dialog which has already 179 terminated, the UA SHOULD decline the request with a 603 (Decline) 180 response. 182 If the Same-Session header field matches an active dialog, the UA 183 MUST verifies that the initiator of the new INVITE is authorized to 184 be part of the session previously established by the matched dialog. 185 If the initiator of the new INVITE has authenticated successfully as 186 equivalent to the user who established the matched dialog, then the 187 merging of both session is authorized. For example, if the user who 188 established the initial dialog and the initiator of the new INVITE 189 request share the same credentials for Digest authentication [8], or 190 they sign the correlation request with S/MIME [11] with the same 191 private key and present the (same) corresponding certificate used in 192 the original dialog, then the merging of the session is authorized. 194 Alternatively, the Referred-By mechanism [9] defines a mechanism that 195 the UAS can use to verify that an INVITE request with a Same-Session 196 header field was sent on behalf of the other participant in the 197 matched dialog (in this case, triggered by a REFER request). If the 198 INVITE request contains a Referred-By header which corresponds to the 199 user that established the matched dialog, the UA SHOULD authorize the 200 merging of the sessions. The Referred-By header field MUST reference 201 a corresponding, valid Referred-By Authenticated Identity Body [10]. 202 The UA MAY apply other local policy to authorize the remainder of the 203 request. In other words, the UAS may apply different policy to the 204 new dialog than was applied to the matched dialog. 206 If authorization is successful, the UA attempts to accept the new 207 INVITE and treats the session newly-established and the previously 208 established session as if they were one. It SHOULD return in the 209 response the Contact header filled in the same way as it returned 210 during the original dialog establishment phase; in this way, 211 subsequent users joining the session will be able to use the same 212 URL. 214 If the authorization is successful, but the UA cannot accept the new 215 INVITE (for example: it cannot establish required QoS or keying, or 216 it has incompatible media), the UA MUST return an appropriate error 217 response and MUST leave the matched dialog unchanged. 219 If the UAS is incapable of satisfying the Same-Session request, it 220 MUST return a 488 (Not Acceptable Here) response. 222 7. User Agent Client Behavior 224 A User Agent that wishes to add a new dialog of its own to a single 225 existing early or confirmed dialog sends the target User Agent an 226 INVITE request containing a Same-Session header field. The UAC (User 227 Agent Client) places the Call-ID, to-tag, and from-tag information 228 for the target dialog in a single Same-Session header field and sends 229 the new INVITE to the target. 231 If the User Agent receives a 300-class response, and acts on this 232 response by sending an INVITE to a Contact in the response, this 233 redirected INVITE MUST contain the same Same-Session header which was 234 present in the original request. Although this is unusual, this 235 allows INVITE requests with a Same-Session header to be redirected 236 before reaching the target UAS. 238 Note that use of the Same-Session mechanism does not provide a way to 239 match multiple dialogs, nor does it provide a way to match an entire 240 call, an entire transaction, or to follow a chain of proxy forking 241 logic. 243 8. New Same-Session Option Tag 245 This specification defines a new Require/Supported header option tag 246 "Same-Session". UAs which support the Same-Session header field MUST 247 include the "Same-Session" option tag in a Supported header field. 248 UAs that want explicit failure notification if Same-Session is not 249 supported MAY include the "Same-Session" option in a Require header 250 field. 252 The following is an example of a Require header field with the "Same- 253 Session" option tag: 255 Require: Same-Session 257 9. Usage Example 259 The following non-normative examples are not intended to enumerate 260 all the possibilities for the usage of this extension, but rather to 261 provide examples or ideas only. 263 9.1. Correlate a Dialog 265 Alice's phone Alice's video Bob 266 | | | 267 | | | 268 |(1) INVITE | | 269 |---------------------------->| 270 |(2) 200 Ok | | 271 |<----------------------------| 272 |(3) ACK | | 273 |---------------------------->| 274 |dialog 1 | | 275 |.............................| 276 |(4) REFER (Target-Dialog: 1) | 277 |------------->| | 278 |(5) 202 Accepted | 279 |<-------------| | 280 |(6) NOTIFY (100 Trying) | 281 |<-------------| | 282 |(7) 200 Ok | | 283 |------------->| | 284 | |(8) INVITE | 285 | |------------->| 286 | |(9) 200 Ok | 287 | |<-------------| 288 | |(10) ACK | 289 | |------------->| 290 | |dialog 2 (correlated to dialog 1) 291 | |..............| 292 |(11) NOTIFY (200 Ok) | 293 |<-------------| | 294 |(12) 200 Ok | | 295 |------------->| | 296 | | | 297 | | | 299 In this example, Alice starts a phone call with Bob (messages 1,2,3). 300 At a later point, Alice wants to add video to the session using a 301 different user agent that supports video. Alice wants Bob to treat 302 media stream (i.e., audio and video)as if they had been established 303 using a single INVITE-initiated dialog. Consequently, Alice's user 304 agent generates the following REFER request. 306 REFER sip:aliceVideo@b.example.org SIP/2.0 307 To: 308 From: ;tag=iii 309 Call-Id: 7@a.example.org 310 CSeq: 1 REFER 311 Contact: 312 Refer-to: 314 Referred-By: < sip:alicePhone@example.org> 316 When Alice video-enabled user agent receives the REFER request, it 317 establish a new dialog (message 8,9,10) with Bob using the 318 information received in the REFER request. 320 INVITE sip:bob@b.example.org SIP/2.0 321 To: 322 From: ;tag=iii 323 Call-Id: 777@a.example.org 324 CSeq: 1 INVITE 325 Contact: 326 Same-Session: 425928@phone.example.org;to-tag=xyz;from-tag=pdq 328 SIP/2.0 200 OK 329 To: 330 From: ;tag=iii 331 Call-Id: 777@a.example.org 332 CSeq 1 INVITE 333 Contact: 335 10. Security Considerations 337 The extension specified in this document significantly changes the 338 relative security of SIP devices. It has the same problems of both 339 "Join" and "Replace" header fields. 341 This extension can be used to insert a new dialog in a multimedia 342 conversation in order to monitor potentially sensitive content. As 343 such, invitations with the Same-Session header field MUST only be 344 accepted if the peer requesting a Same-Session has been properly 345 authenticated as a user already involved in the call. 347 11. IANA Considerations 349 11.1. Registration of Same-Session SIP header field 351 Name of Header: Same-Session 353 Short form: none 355 Normative description: RFC xxxx 357 11.2. Registration of Same-Session SIP Option-tag 359 Name of option: Same-Session 361 Description: Support for the SIP Correlation header 363 SIP headers defined: Same-Session 365 Normative description: RFC xxxx 367 12. Acknowledges 369 Goeran Ericsson provided valuable ideas for this document. 371 13. References 373 13.1. Normative References 375 [1] Handley, M., "SDP: Session Description Protocol", 376 draft-ietf-mmusic-sdp-new-26 (work in progress), January 2006. 378 [2] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 379 Specifications: ABNF", RFC 2234, November 1997. 381 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 382 Levels", BCP 14, RFC 2119, March 1997. 384 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 385 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 387 13.2. Informational References 389 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 390 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 392 Session Initiation Protocol", RFC 3261, June 2002. 394 [6] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP) 395 "Join" Header", RFC 3911, October 2004. 397 [7] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation 398 Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. 400 [8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 401 Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: 402 Basic and Digest Access Authentication", RFC 2617, June 1999. 404 [9] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By 405 Mechanism", RFC 3892, September 2004. 407 [10] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 408 Identity Body (AIB) Format", RFC 3893, September 2004. 410 [11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions 411 (S/MIME) Version 3.1 Message Specification", RFC 3851, 412 July 2004. 414 [12] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and 415 D. Gurle, "Session Initiation Protocol (SIP) Extension for 416 Instant Messaging", RFC 3428, December 2002. 418 [13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 419 Notification", RFC 3265, June 2002. 421 [14] Sparks, R., "The Session Initiation Protocol (SIP) Refer 422 Method", RFC 3515, April 2003. 424 [15] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 426 [16] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 427 Method", RFC 3311, October 2002. 429 [17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 430 Responses in Session Initiation Protocol (SIP)", RFC 3262, 431 June 2002. 433 [18] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, 434 "Best Current Practices for Third Party Call Control (3pcc) in 435 the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, 436 April 2004. 438 [19] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of 439 Resource Management and Session Initiation Protocol (SIP)", 440 RFC 3312, October 2002. 442 [20] Shacham, R., "Session Initiation Protocol (SIP) Session 443 Mobility", draft-shacham-sipping-session-mobility-02 (work in 444 progress), March 2006. 446 Appendix A. Same Session header AND Third Party Call Controll 448 It is possible to achive the Same-Session operation effect using 449 Third Party Call Controll (3pcc) [18] and the SIP Session Mobility 450 [20]. However there are various cons in the use of 3pcc: 452 o complexity: some use cases that are quite complex implemented 453 using the Third Party Call Controll (3pcc) become more simpler 454 using the Same-Session Header. 455 o implementation: not many terminals are going to implement what is 456 needed to be a 3pcc controller. However, any terminal will 457 implement REFER. 458 o support of an extension at the remote end: the controller needs to 459 understand all the SIP extensions applied to both dialogs. 461 Moreover Same-Session Header solves the SIP lack, underlined in the 462 SIP Session Mobility [20], of a standard way to associate multiple 463 sessions as part of a single call in SIP. 465 The following examples show the different complexity, in term of 466 amount of messages, using the Same-Session header or the 3pcc, in the 467 scenario where the user A has an on-going session with the user agent 468 B and then A wants to add a new media to the session using a 469 different user agent C. 471 Appendix A.1. Example: preconditions using the Same-Session Header 473 A ------------------ B 474 | 475 C -------------------| 477 Figure 1: Same-Session architecture 479 Fig.1 shows the architecture achived using the Same-Sessione header 480 peer to peer call control model. 482 Using the same-session header, as showed in fig.2, A issues a REFER 483 transaction to C, then C send an INVITE to B following the basic 484 session establishment call flow showed in Figure 1 of [19]. The flow 485 if fig.2 has 17 messages. 487 A C B 489 | | | 490 |............dialog 1............................| 491 |(1) REFER | | 492 |-------------->| | 493 |(2) 202 Accepted | 494 |<--------------| | 495 |(3) NOTIFY (100 Trying) | 496 |-------------->| | 497 |(4) 200 Ok | | 498 |<--------------| | 499 | | | 500 | |--------(5) INVITE SDP1-------->| 501 | | | 502 | |<-(6) 183 Session Progress SDP2-| 503 | | | 504 | |-----------(7) PRACK----------->| 505 | | | 506 | |<------(8) 200 OK (PRACK)-------| 507 | | | 508 | |--------(9) UPDATE SDP3-------->| 509 | | | 510 | |<---(10) 200 OK (UPDATE) SDP4---| 511 | | | 512 | |<--------(11) 180 Ringing-------| 513 | | | 514 | |------------(12) PRACK--------->| 515 | | | 516 | |<-------(13) 200 OK (PRACK)-----| 517 | | | 518 | |<------(15) 200 OK (INVITE)-----| 519 | | | 520 | |-------------(15) ACK---------->| 521 | | | 522 | |............dialog 2............| 523 |(16) NOTIFY (200 Ok) | 524 |<--------------| | 525 |(17) 200 Ok | | 526 |-------------->| | 528 Figure 2: Basic session establishment using Same-Session and 529 preconditions 531 Appendix A.2. Example: preconditions using the 3pcc 533 A ------------------ B 534 | 535 C 537 Figure 3: 3pcc architecture 539 Fig.3 shows the architecture achived using the Third Party Call 540 Control (3pcc) model. 542 Using 3pcc, A behaves as the controller in Figure 11 of [18]. In 543 this scenario the flow contains 26 messages. We don't insert the 544 figure for the sake of space. 546 Alternatively, it is possible using 3pcc in a different way. A 547 issues a REFER to C and C send the INVITE towards A. The flow, as 548 showed in fig.4, without precondition already has 16 messages. 550 C A B 551 | | | 552 |(1)REFER | | 553 |<------------------| | 554 |(2) 202 Accepted | | 555 |------------------>| | 556 |(3) NOTIFY(100 Trying) | 557 |<------------------| | 558 |(4) 200 Ok | | 559 |------------------>| | 560 |(5) INVITE | | 561 |------------------>| | 562 | |(6) INVITE SDP C | 563 | |----------------->| 564 | |(7) 200 Ok SDP AB+AC 565 | |<-----------------| 566 | |(8) ACK | 567 | |----------------->| 568 |(9) 200 OK SDP AC | | 569 |<------------------| | 570 |(10) ACK SDP C | | 571 |------------------>| | 572 | |(11) INVITE | 573 | |----------------->| 574 | |(12) 200 OK SDP AB+AC 575 | |<-----------------| 576 |(13) INVITE SDP AC | | 577 |<------------------| | 578 |(14) 200 OK SDP C | | 579 |------------------>| | 580 |(15) ACK | | 581 |<------------------| | 582 | |(16) ACK SDP A+C | 583 | |----------------->| 584 | |dialog 1 | 585 | |..................| 587 Figure 4 589 Authors' Addresses 591 Salvatore Loreto 592 Ericsson 593 Hirsalantie 11 594 Jorvas 02420 595 Finland 597 Email: Salvatore.Loreto@ericsson.com 599 Gonzalo Camarillo 600 Ericsson 601 Hirsalantie 11 602 Jorvas 02420 603 Finland 605 Email: Gonzalo.Camarillo@ericsson.com 607 Intellectual Property Statement 609 The IETF takes no position regarding the validity or scope of any 610 Intellectual Property Rights or other rights that might be claimed to 611 pertain to the implementation or use of the technology described in 612 this document or the extent to which any license under such rights 613 might or might not be available; nor does it represent that it has 614 made any independent effort to identify any such rights. Information 615 on the procedures with respect to rights in RFC documents can be 616 found in BCP 78 and BCP 79. 618 Copies of IPR disclosures made to the IETF Secretariat and any 619 assurances of licenses to be made available, or the result of an 620 attempt made to obtain a general license or permission for the use of 621 such proprietary rights by implementers or users of this 622 specification can be obtained from the IETF on-line IPR repository at 623 http://www.ietf.org/ipr. 625 The IETF invites any interested party to bring to its attention any 626 copyrights, patents or patent applications, or other proprietary 627 rights that may cover technology that may be required to implement 628 this standard. Please address the information to the IETF at 629 ietf-ipr@ietf.org. 631 Disclaimer of Validity 633 This document and the information contained herein are provided on an 634 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 635 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 636 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 637 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 638 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 639 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 641 Copyright Statement 643 Copyright (C) The Internet Society (2006). This document is subject 644 to the rights, licenses and restrictions contained in BCP 78, and 645 except as set forth therein, the authors retain all their rights. 647 Acknowledgment 649 Funding for the RFC Editor function is currently provided by the 650 Internet Society.