idnits 2.17.1 draft-yusef-dispatch-action-ref-00.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 : ---------------------------------------------------------------------------- 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 date (January 14, 2011) is 4851 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) == Missing Reference: 'RFC 3265' is mentioned on line 123, but not defined ** Obsolete undefined reference: RFC 3265 (Obsoleted by RFC 6665) == Missing Reference: 'Trying' is mentioned on line 245, but not defined == Missing Reference: '200 OK' is mentioned on line 256, but not defined == Missing Reference: 'RFC 3261' is mentioned on line 524, but not defined == Unused Reference: 'TR87' is defined on line 859, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT R. Shekh-Yusef 3 Intended Status: Standards Track Avaya 4 Expires: July 18, 2011 C. Jennings 5 Cisco Systems 6 A. Johnston 7 Avaya 8 F. Audet 9 Skype 10 January 14, 2011 12 Action Referral in the Session Initiation Protocol (SIP) 13 draft-yusef-dispatch-action-ref-00 15 Abstract 17 This specification defines action referral that allows an application 18 to make a high level request to a User Agent to perform an action, 19 and let the the User Agent execute the action as it sees fit. Action 20 referral uses the SIP REFER method with a Refer-To header field 21 containing a URN, which indicates the requested action. 23 This specification also defines the option tag 'action-ref' to allow 24 the UA to indicate its support for action referral. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as 34 Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 Copyright and License Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 3.1. Third-Party/Proxy Application . . . . . . . . . . . . . . 7 67 3.2. Loosely Coupled UAs . . . . . . . . . . . . . . . . . . . 7 68 3.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 3.3.1. Answer an audio call . . . . . . . . . . . . . . . . 8 70 3.3.2. Answer an A/V call on two separate devices . . . . . 9 71 3.3.3. Click-to-Dial . . . . . . . . . . . . . . . . . . . 10 72 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.1. URN Structure . . . . . . . . . . . . . . . . . . . . . 11 74 4.2. URN Categories . . . . . . . . . . . . . . . . . . . . . 12 75 5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 13 76 5.1. Dialog usage . . . . . . . . . . . . . . . . . . . . . . 13 77 5.2. Capabilities Indications . . . . . . . . . . . . . . . . 13 78 5.3. Addressing the relevant parties . . . . . . . . . . . . 14 79 5.4. Monitoring Device Specific Events . . . . . . . . . . . 14 80 5.5. Request Authorization . . . . . . . . . . . . . . . . . 15 81 6. Call Flows . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 6.1. Answer Call Operation . . . . . . . . . . . . . . . . . 17 83 6.2. Terminate Call Operation . . . . . . . . . . . . . . . . 19 84 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 85 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 86 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 88 10.1. Normative References . . . . . . . . . . . . . . . . . 22 89 10.2 Informative References . . . . . . . . . . . . . . . . . 22 90 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 92 1. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [RFC2119]. 98 To simplify discussions of the REFER method and its extensions, the 99 three terms below are being used throughout the document: 101 o REFER-Issuer: the UA issuing the REFER request 103 o REFER-Recipient: the UA receiving the REFER request 105 o REFER-Target: the UA designated in the Refer-To Uniform Resource 106 Identifier (URI), which, for this specification, is a Uniform 107 Resource Name (URN) 109 2. Introduction 111 The Session Initiation Protocol (SIP) [RFC3261] provides users with 112 the ability to initiate, manage and terminate multimedia sessions. 113 Many deployments have SIP applications in the SIP signaling path that 114 get involved in the setup and management of these multimedia 115 sessions. 117 A SIP application is a program running on a SIP network element that 118 provides some value-added function to a user. Some of these 119 applications need mechanisms to monitor or/and control a SIP User 120 Agent (UA). 122 SIP already provides an extensible framework, (SIP)-Specific Event 123 Notification [RFC 3265], by which SIP UAs can monitor remote UAs and 124 get indications that certain events have occurred. For example, the 125 following are widely used event packages: 127 o Dialog package - call states 129 o Registration package - phone status 131 o Conference package - conference status 133 SIP also provides a method for requesting UAs to perform certain 134 task, i.e., REFER [RFC3515]. This REFER method is limited, as today 135 it does not support the following: 137 o REFER does not allow for a UA to request another UA to respond to 138 requests, e.g., 140 * A UA cannot request another UA to answer a call 142 * A UA cannot request another UA to reject a call 144 o REFER does not allow for a UA to request another UA to invoke 145 actions, e.g., 147 * REFER does not allow for a UA to request another UA to 148 place a call on hold or to mute it 150 Action referral allows an application to make a high level request to 151 a SIP [RFC3261] User Agent (UA) to perform an action or, and let the 152 User Agent execute the action as it sees fit. 154 Action referral uses the SIP REFER method [RFC3515] with a Refer-To 155 header field containing a URN [RFC2141] to indicate the requested 156 action. Action referral is consistent with the SIP call control 157 framework [RFC5850] and is a natural expansion of the Framework for 158 Application Interaction [RFC5629] which allows for referral to SIP 159 and HTTP resources. 161 OPEN QUESTION: 163 The REFER method seems to be already overloaded with various 164 capabilities. Take a look at the following draft draft-worley-sip- 165 many-refers-00 for more details. 167 Should a new SIP method be defined for this purpose? 169 3. Use Cases 171 This section describes these applications for which the Action 172 Referral can be useful. 174 3.1. Third-Party/Proxy Application 176 Action referral is useful for a wide range of third party or proxy 177 applications that need to remotely control or influence a User Agent, 178 e.g. Contact Center environment. In pre-SIP environments, these 179 environments have been using "Computer Telephony Integration": for 180 example, traditional PBXs use CTI protocols such as CSTA [ECMA269] to 181 provide this functionality. CSTA works fine for legacy PBXs with 182 legacy phones but is problematic in a SIP environment. For example, 183 SIP includes totally new capabilities such as presence and instant 184 messaging. SIP also supports multiple users with multiple devices 185 operating at once, and with complex User Interfaces. Furthermore, 186 multiple applications may want to simultaneously wish to interact 187 with the device. Because of the lack of a native mechanism to 188 achieve such control for SIP, implementers have had to implement such 189 techniques as mapping CSTA's ASN.1 encoding to XML then encapsulate 190 it into SIP INFO requests in order to tunnel it to a SIP B2BUA 191 [ECMA323], which then maps it to proprietary device control protocols 192 or to SIP with proprietary and incompatible extensions. This 193 document provides a clean and native way to meet the requirements. 195 3.2. Loosely Coupled UAs 197 Action referral is useful for collections of loosely coupled User 198 Agents which would like to present a coordinated user experience. 199 Among other things, this allows User Agents which handle orthogonal 200 media types but which would like to be present in a single 201 conversation to add and remove each other from the conversation as 202 needed. This is especially appropriate when coordinating 203 conversations among organizers, general purpose computers, and 204 special purpose communications appliances like telephones, Internet 205 televisions, in-room video systems, electronic whiteboards, and 206 gaming devices. For example using action referral, an Instant 207 Messaging client could initiate a multi-player gaming session and an 208 audio session to a chat conversation. Likewise a telephone could add 209 an electronic whiteboard session to a voice conversation. Finally, a 210 computer or organizer could cause a nearby phone to dial from numbers 211 or URIs in a document, email, or address book, allow users to answer 212 or redirect incoming calls without removing hands from the computer 213 keyboard, place calls on hold, and join other sessions on the phone 214 or otherwise. 216 3.3. Examples 218 In the following examples, Alice has two SIP clients; a PC with a 219 soft client and a desk phone. Alice prefers to answer incoming audio 220 calls on her desk phone. 222 3.3.1. Answer an audio call 224 In this example, Bob makes an audio call to Alice and the proxy forks 225 the call to both of Alice's clients. Alice decided that she wants to 226 answer the call on her desk phone remotely using her soft client. 228 To do that, the soft client sends a REFER with a well-defined URN, 229 which instructs the desk phone to answer the call. As a result, the 230 desk phone sends a 200 OK to answer the incoming call, and the proxy 231 then cancels the INVITE to the soft client. 233 Alice Alice Proxy Bob 234 PC Desk Phone 235 | | | INVITE Alice | 236 | | |<--------------------| 237 | | INVITE Alice | | 238 | |<--------------------| | 239 | INVITE Alice | | | 240 |<------------------------------------------| | 241 | REFER Refer-To: urn:sip-action:call:answer| | 242 |-------------------->| | | 243 | 202 | | | 244 |<--------------------| | | 245 | NOTIFY [Trying] | | | 246 |<--------------------| | | 247 | 200 OK | | | 248 |-------------------->| | | 249 | | 200 OK | | 250 | |-------------------->| 200 OK | 251 | | |-------------------->| 252 | | | ACK | 253 | | |<--------------------| 254 | | ACK | | 255 | |<--------------------| | 256 | NOTIFY [200 OK] | | | 257 |<--------------------| | | 258 | 200 OK | | | 259 |-------------------->| | | 260 | CANCEL | | | 261 |<------------------------------------------| | 262 | | | | 264 3.3.2. Answer an A/V call on two separate devices 266 In this example, Bob makes a video call to Alice. Alice interested in 267 accepting the video using her soft client on her PC and accepting the 268 audio on her desk phone. 270 To do that, the soft client sends a REFER with the URN urn:sip- 271 action:audio:answer which asks the desk phone to return its audio 272 answer to the incoming call. The desk phone returns its audio answer 273 in the body of the sipfrag message in the NOTIFY request. The soft 274 client then aggregates the audio SDP answer from the desk phone with 275 the video answer from the soft client and sends it to Bob's phone. As 276 a result a video call is established, with the video streaming 277 between Alice's PC and Bob's phone while the audio is streaming 278 between Alice's desk phone and Bob's phone. 280 Alice Alice Proxy Bob 281 PC Desk Phone 282 | | | INVITE Alice [A/V] | 283 | | |<--------------------| 284 | | INVITE Alice [A/V] | | 285 | |<--------------------| | 286 | INVITE Alice [A/V] | | | 287 |<------------------------------------------| | 288 | REFER Refer-To: urn:sip-action:audio:answer | 289 |-------------------->| | | 290 | 202 | | | 291 |<--------------------| | | 292 | NOTIFY [100 Trying] | | | 293 |<--------------------| | | 294 | 200 OK | | | 295 |-------------------->| | | 296 | NOTIFY [200 OK [Audio SDP answer]] | | 297 |<--------------------| | | 298 | 200 OK | | | 299 |-------------------->| | | 300 | 200 OK [A/V SDP answer] | | 301 |------------------------------------------>| | 302 | | | 200 OK [A/V] | 303 | | |-------------------->| 304 | | CANCEL | | 305 | |<--------------------| | 306 | |<======audio==============================>| 307 |<============================video==============================>| 308 | | | | 310 3.3.3. Click-to-Dial 312 In this example, while browsing the web on her PC, Alice clicks on 313 Bob's SIP URI, intending to initiate a call to Bob. Alice's web 314 browser passes the SIP URI to the soft client on Alice's PC. The 315 soft client is configured with the URI of Alice's desk phone. A 316 REFER is sent to the desk phone, which results in Alice's desk phone 317 initiating a call to Bob. 319 Alice decided to cancel the call to Bob because he is no answering. 320 To do that, the soft client sends a REFER request with the URN 321 urn:sip-action:call:terminate which results in Alice's desk phone 322 sending a CANCEL request to terminate the call to Bob. 324 Alice Alice Bob 325 PC Desk Phone 326 | | | 327 | REFER Refer-To: Bob | | 328 |-------------------->| | 329 | 202 Accepted | | 330 |<--------------------| | 331 | | INVITE | 332 | |-------------------->| 333 | | 180 Ringing | 334 | |<--------------------| 335 | | | 336 | REFER Refer-To: urn:sip-action:call:terminate 337 |-------------------->| | 338 | 202 Accepted | | 339 |<--------------------| | 340 | | | 341 | | CANCEL | 342 | |-------------------->| 343 | | | 345 4. Overview 347 A prototypical action referral flow looks as per section 4.1 of 348 [RFC3515]. The Refer-To URI in the REFER message includes a URN 349 describing the action. 351 Action referral is sent to a GRUU when a specific instance of a UA is 352 the desired target. When the action referral needs to be correlated 353 to a specific dialog, the Target-Dialog header field is used 354 [RFC4538]. 356 Some primitives require a second dialog identifier (such as 357 ConferenceCalls which causes the media from two dialogs to be mixed). 358 To address the multiple dialogs need, one REFER is sent per dialog 359 with a URN with a bridge action telling the phone to put the dialog 360 on the bridge. While this requires multiple requests to be sent, the 361 requests can be sent overlapped at the same time. This approach is 362 flexible enough to allow adding and removing parties to the 363 conference in very simple and straightforward way without changes to 364 existing standard behavior. 366 4.1. URN Structure 368 The Namespace Identifier (NID) of the URN is intended to be in the 369 formal space and assigned by IANA, as per the procedures of 370 [RFC3406]. An alternative would be to use the service URN space 371 [RFC5031]. Until this is resolved, this document will use the 372 following namespace: "sip-action". 374 The Namespace Specific String (NSS) of the URN includes the action 375 name, and may be followed by a semi-colon and additional action- 376 specific parameters. 378 The action name might consist of a number of categories that start 379 from the most general category and go down to more specific category, 380 with the last value representing the request. 382 For example, the structure of the NSS of the urn:sip- 383 action:call:answer has two categories: 'service' and 'call' and the 384 request 'answer'. 386 The reason behind the above structure is to avoid the creation of a 387 namespace with a very long list of unrelated actions. 389 The above structure allows grouping of related actions under one 390 category to allow application to apply actions, e.g. enable/disable, 391 to the whole category. 393 4.2. URN Categories 395 This document defines the following categories as part of the NSS of 396 the URN: 398 o call: to allow access to call actions available on a SIP UA, 399 e.g. answer a call, decline a call, ... 401 o conference: to allow access to conference actions available on a 402 SIP UA, e.g. add, remove, ... 404 This document defines the following actions: 406 o Answer call - urn:sip-action:call:answer 407 o Terminate call - urn:sip-action:call:terminate 408 o Decline call - urn:sip-action:call:decline 409 The REFER-Recipient returns 603 Decline 410 o Ignore call - urn:sip-action:call:ignore 411 The REFER-Recipient stops ringing and clears the call 412 o Send call to VM - urn:sip-action:call:sendvm 413 Stop ringing and send the call to VM. 414 o Hold call - urn:sip-action:call:hold 415 o Unhold call - urn:sip-action:call:unhold 416 o Mute call - urn:sip-action:call:mute 417 o Unmute call - urn:sip-action:call:unmute 418 o Conference - urn:sip-action:conference:add 419 - urn:sip-action:conference:remove 421 Note that the very important "Make call" CTI primitive does not 422 require a action referral URN since it is accomplished by sending a 423 normal REFER with a URI identifying the resource (e.g., a sip, sips 424 or tel URI). 426 This specification defines the above list as an initial set of URNs, 427 to be registered with IETF, for use with this specification. 429 In order to add any new action URN to the list above, it must go 430 through the "IETF review" process as defined in RFC 5226. 432 5. User Agent Behavior 434 5.1. Dialog usage 436 This document attempts to avoid using multiple dialog usages, for the 437 reasons described in [RFC5057]. Therefore, this document will make 438 use of the GRUU [RFC5627], and the Target-Dialog header field 439 [RFC4538] to associate an existing INVITE usage with a REFER arriving 440 on a new dialog to facilitate authorization of that REFER. 442 In many use cases of action referral, receiving notifications about 443 the status of a REFER request are superfluous, as the Refer issuer 444 often maintains a long duration subscription to the dialog package 445 [RFC4235]. Suppression of the REFER notifications is done with the 446 norefersub option-tag, defined in section 7 of [RFC4488]. When the 447 norefersub option tag is present, a REFER request which would have 448 created a new subscription and dialog becomes a standalone 449 transaction instead, eliminating a multiple dialog usage. Each such 450 standalone REFER transaction use a new (unique) Call-ID header field 451 value. 453 In the most common usage, the controller maintains a long duration 454 subscription to the dialog package, and sends REFER requests in 455 separate dialogs. Each REFER would include the norefersub option-tag 456 in a Supported header field. 458 In some cases, the controller does not maintain a dialog package 459 subscription for the REFER-Recipient. This might be the case for a 460 "webdialer" or other application which associates with other UAs on 461 an adhoc and intermittent basis. An initial REFER request is sent to 462 start a new dialog, which is followed by notifications for the refer 463 event type (the norefersub option-tag is not used in this case). 465 5.2. Capabilities Indications 467 A UA compliant to this specification SHOULD indicate its support by 468 including the option tag 'action-ref' in the Supported header of all 469 requests it sends. 471 The UA MAY also indicate its support for this action referral by 472 adding the 'action-ref' value to the extentions parameter in the 473 Contact header field of its REGISTER request, as described in [RFC 474 3840]. 476 5.3. Addressing the relevant parties 478 REFER requests contain a number of URIs which need to address the 479 appropriate parties. A list of the relevant fields include the 480 Request-URI, To URI, From URI, Contact URI, Refer-To URI, and the 481 Referred-By URI, as well as the Target-Dialog itself. This section 482 attempts to clarify what needs to be placed in each field. 484 Action referral applies to dialogs or sessions on a specific UA, 485 which requires the use of GRUU [RFC5627] for a single UA. Contact 486 URIs for a UA can be discovered by subscribing to the registration 487 package [RFC3680] for the relevant AORs. 489 The To header field in the REFER request normally contains the same 490 URI as in the Request-URI. The From identifies the AOR of the 491 controller. The Refer-To URI is the action referral URN. 493 Many uses of action referral require that the REFER-Recipient take 494 some action in the context of an existing dialog. For example, the 495 controller might want the REFER-Recipient to terminate an existing 496 dialog. To select the appropriate dialog from which to source the 497 request, the Target-Dialog header specified in [RFC4538] is used. 499 5.4. Monitoring Device Specific Events 501 Some applications need a mechanism to monitor events on a SIP UA that 502 are device specific. 504 The following is a list of some these device specific events: 506 1. Hook status 507 2. Transducer status (handset, headset, speaker) 508 3. Active call 509 4. Volume status 510 5. Mute status 511 6. MWI light status 512 7. IM light status 514 A separate document that defines a new event package will be created 515 to address this need. 517 5.5. Request Authorization 519 When a UA receives a request to invoke an action, it needs to 520 authorize that request. Some requests can be authorized based on the 521 identity of the sender, the request method, local policy, etc. 523 All action referral requests MUST be challenged using the digest 524 authentication mechanism described by [RFC 3261]. In most cases, the 525 same user will be logged in to the different devices using the same 526 credentials provided in the REGISTER requests. 528 6. Call Flows 530 This sample provides non-normative sample calls flows for some of the 531 actions listed in Section 4. It is important to understand that the 532 actual "realization" of the action (i.e., the actual procedures 533 invoked) are the sole responsibility of the Refer-Recipient. This 534 document in no way attempts to standardize those procedures, and the 535 call flow below are merely examples. 537 In all cases, the "controller" (i.e., the Refer-Issuer) could be 538 Alice's PC, PDA, or a third party application. The controlled device 539 is Alice's phone (i.e., the Refer-Recipient). The Refer-Target is 540 obviously the action referral URN. In all cases, it is assumed that 541 the controller is subscribed to Alice's Phone's dialog package. 543 The call flows in this document use the following conventions. The 544 dialog each message is sent in is shown on the left hand side. 545 Selected Request-URI and header fields are shown. The contents of 546 message bodies are shown for dialog-info+xml, sdp, and sipfrag 547 message bodies. For responses, the method is shown in parentheses. 548 For reference, the messages are labeled F1, F2, etc. 550 6.1. Answer Call Operation 552 In message 1, Bob makes a call to Alice's Phone. A notification of 553 "trying" is sent to the controller. Alice's phone automatically 554 sends a "ringing" to Bob. Another notification of "early" is then 555 sent to the controller. The controller then tells the phone to 556 answer the call. Alice's phone sends a notification of "confirmed" 557 to the controller. 559 Controller Alice Bob 560 |<<< Controller subscribed >>>| | 561 |<< to Alice's dialog events >>| | 562 dialog1 | | F1 INVITE sip:Alice-AOR | 563 | |<---------------------------| 564 dialog2 | F2 NOTIFY sip:Controller-GRUU| | 565 | dialog-info+xml: dialog1=trying | 566 |<-----------------------------| | 567 | | | 568 dialog2 | F3 200 (NOTIFY) | | 569 |----------------------------->| | 570 dialog1 | | F4 180 (INVITE) | 571 | |--------------------------->| 572 dialog2 | F5 NOTIFY sip:Controller-GRUU| | 573 | dialog-info+xml: dialog1=early | 574 |<-----------------------------| | 575 | | | 576 dialog2 | F6 200 (NOTIFY) | | 577 |----------------------------->| | 578 | | | 579 dialog3 | F7 REFER sip:Alice-GRUU | | 580 | To: sip:Alice-GRUU | | 581 | Refer-To: urn:sip-action:call:answer | 582 | Target-Dialog: dialog1 | | 583 |----------------------------->| | 584 | | | 585 dialog3 | F8 202 (REFER) | | 586 |<-----------------------------| | 587 dialog1 | | F9 200 (INVITE) | 588 | |--------------------------->| 589 | | | 590 dialog1 | | F10 ACK | 591 | |<---------------------------| 592 dialog2 | F11 NOTIFY sip:Controller-GRUU | 593 | dialog-info+xml: dialog1=confirmed | 594 |<-----------------------------| | 595 | | | 596 dialog2 | F12 200 (NOTIFY) | | 597 |----------------------------->| | 599 In the following flow, the application is in the signaling path 600 between Alice and Bob and is aware of a dialog that was established 601 between the UAs. 603 Alice calls Bob, and Bob's UA is ringing. At this stage, the 604 application decides that it wants to ask Bob's UA to answer the call. 605 The application sends a REFER request asking Bob's UA to answer the 606 call, which results on Bob's UA sending an 200 OK and a call is 607 established with Alice. 609 Alice Application Bob 610 | F1 INVITE | | 611 |----------------------->| | 612 | | F2 INVITE | 613 | |----------------------->| 614 | | F3 180 Ringing | 615 | |<-----------------------| 616 | F4 180 Ringing | | 617 |<-----------------------| | 618 | | | 619 | | F5 REFER sip:Bob-GRUU | 620 | | To: sip:Bob-GRUU | 621 | | Refer-To: | 622 | | urn:sip-action:call:answer 623 | | Target-Dialog: dialog1 624 | |----------------------->| 625 | | F6 202 (REFER) | 626 | |<-----------------------| 627 | | | 628 | | | 629 | | F7 200 OK | 630 | |<-----------------------| 631 | F8 200 OK | | 632 |<-----------------------| | 633 | F9 ACK | | 634 |----------------------->| | 635 | | F10 ACK | 636 | |----------------------->| 637 | | | 638 | | | 639 | | F11 NOTIFY | 640 | |<-----------------------| 641 | | | 642 | | F12 200 OK | 643 | |----------------------->| 644 | | | 646 6.2. Terminate Call Operation 648 Terminate Call is a perfect example of an action whose treatment (and 649 consequently, the resulting call flow) depends on the situation, for 650 example, the state of the dialog between the remote parties. 652 Alice's Phone and Bob are currently in an established dialog. The 653 controller tells Alice's phone to terminate the call with Bob's 654 phone. 656 Controller Alice Bob 657 |<< Controller subscribed to >>|<<< Established dialog1 >>>>| 658 |<<< Alice's dialog events >>>>| | 659 | | | 660 dialog3 | F1 REFER sip:Alice-GRUU | | 661 | To: sip:Alice-GRUU | | 662 | Refer-To: urn:sip-action:call:terminate | 663 | Target-Dialog: dialog1 | | 664 |----------------------------->| | 665 | | | 666 dialog3 | F2 202 (REFER) | | 667 |<-----------------------------| | 668 dialog1 | | F3 BYE sip:Bob-GRUU | 669 | |--------------------------->| 670 | | | 671 dialog1 | | F4 200 (BYE) | 672 | |<---------------------------| 673 | F5 NOTIFY sip:Controller-GRUU | 674 | dialog-info+xml: dialog2=local-bye | 675 |<-----------------------------| | 676 | | | 677 dialog2 | F6 200 (NOTIFY) | | 678 |----------------------------->| | 680 Terminate Call in Established Dialog Call Flow Example 682 If Alice's Phone and Bob are in an early dialog with Bob calling 683 Alice, the call flow could be as follows. 685 Controller Alice Bob 686 |<< Controller subscribed to >>| | 687 |<<< Alice's dialog events >>>>| | 688 dialog1 | | F1 INVITE sip:Alice-AOR | 689 | (dialog2) |<---------------------------| 690 | | | 691 dialog2 | F2 NOTIFY sip:Controller-GRUU| | 692 | dialog-info+xml: dialog1=trying | 693 |<-----------------------------| | 694 | | | 695 dialog2 | F3 200 (NOTIFY) | | 696 |----------------------------->| | 697 dialog1 | | F4 180 (INVITE) | 698 | |--------------------------->| 699 dialog2 | F5 NOTIFY sip:Controller-GRUU| | 700 | dialog-info+xml: dialog1=early | 701 |<-----------------------------| | 702 | | | 703 dialog2 | F6 200 (NOTIFY) | | 704 |----------------------------->| | 705 | | | 706 dialog3 | F7 REFER sip:Alice-GRUU | | 707 | To: sip:Alice-GRUU | | 708 | Refer-To: urn:sip-action:call:terminate | 709 | Target-Dialog: dialog1 | | 710 |----------------------------->| | 711 | | | 712 dialog3 | F8 202 (REFER) (dialog3) | | 713 |<-----------------------------| | 714 dialog1 | | F9 480 (INVITE) | 715 | |--------------------------->| 716 | | | 717 dialog1 | | F10 ACK | 718 | |<---------------------------| 719 dialog2 | F11 NOTIFY (Controller-GRUU) | | 720 | dialog-info+xml: dialog1=rejected | 721 |<-----------------------------| | 722 | | | 723 dialog2 | F12 200 (NOTIFY) | | 724 |----------------------------->| | 726 Terminate Call in Early Dialog Call Flow Example 728 If Alice's Phone and Bob are in an early dialog with Alice calling 729 Bob, the call flow could be as follows. 731 Controller Alice Bob 732 |<< Controller subscribed to >>| | 733 |<<< Alice's dialog events >>>| | 734 dialog1 | | F1 INVITE sip:Bob-AOR | 735 | |--------------------------->| 736 dialog2 | F2 NOTIFY sip:Controller-GRUU| | 737 | dialog-info+xml: dialog1=trying | 738 |<-----------------------------| | 739 | | | 740 dialog2 | F3 200 (NOTIFY) | | 741 |----------------------------->| | 742 dialog1 | | F4 180 (INVITE) | 743 | |<---------------------------| 744 dialog2 | F5 NOTIFY sip:Controller-GRUU| | 745 | dialog-info+xml: dialog1=early | 746 |<-----------------------------| | 747 | | | 748 dialog2 | F6 200 (NOTIFY) | | 749 |----------------------------->| | 750 | | | 751 dialog3 | F7 REFER sip:Alice-GRUU | | 752 | To: sip:Alice-GRUU | | 753 | Refer-To: urn:sip-action:call:terminate | 754 | Target-Dialog: dialog1 | | 755 |----------------------------->| | 756 | | | 757 dialog3 | F8 202 (REFER) | | 758 |<-----------------------------| | 759 dialog1 | | F9 CANCEL | 760 | |--------------------------->| 761 dialog1 | | F10 200 (CANCEL) | 762 | |<---------------------------| 763 | | | 764 dialog1 | | F11 487 (INVITE) | 765 | |<---------------------------| 766 dialog1 | | F12 ACK | 767 | |--------------------------->| 768 | | | 769 dialog1 | F13 NOTIFY sip:Controller-GRUU | 770 | dialog-info+xml: dialog1=rejected | 771 |<-----------------------------| | 772 dialog2 | F14 200 (NOTIFY) | | 773 |----------------------------->| | 775 Terminate Call Initiated Call Flow Example 777 7. Security Considerations 779 The functionality described in this document allows an authorized 780 party to manipulate SIP sessions and dialogs in arbitrary ways. Any 781 user agent that accepts these types of requests needs to be very 782 careful in who it authorizes to send these types of requests. The 783 same security considerations as [RFC3515] apply. 785 8. IANA Considerations 787 TODO: Need to register urn namespace according to procedures of 788 [RFC3406]. 790 9. Acknowledgments 792 TODO 794 10. References 796 10.1. Normative References 798 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 799 Requirement Levels", BCP 14, RFC 2119, March 1997. 801 10.2 Informative References 803 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 805 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 806 A., Peterson, J., Sparks, R., Handley, M., and E. 807 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 808 June 2002. 810 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 811 "Uniform Resource Names (URN) Namespace Definition 812 Mechanisms", BCP 66, RFC 3406, October 2002. 814 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 815 Method", RFC 3515, April 2003. 817 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 818 Package for Registrations", RFC 3680, March 2004. 820 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 821 Initiated Dialog Event Package for the Session Initiation 822 Protocol (SIP)", RFC 4235, November 2005. 824 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol 825 (SIP) REFER Method Implicit Subscription", RFC 4488, 826 May 2006. 828 [RFC4538] Rosenberg, J., "Request Authorization through Dialog 829 Identification in the Session Initiation Protocol (SIP)", 830 RFC 4538, June 2006. 832 [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for 833 Emergency and Other Well-Known Services", RFC 5031, 834 January 2008. 836 [RFC5057] Sparks, R., "Multiple Dialog Usages in the Session 837 Initiation Protocol", RFC 5057, November 2007. 839 [RFC5629] Rosenberg, J., "A Framework for Application Interaction in 840 the Session Initiation Protocol (SIP)", RFC 5629, 841 October 2009. 843 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 844 Agent (UA) URIs (GRUU) in the Session Initiation 845 Protocol (SIP)", RFC 5627, October 2009. 847 [RFC5850] Mahy, R., "A Call Control and Multi-party usage framework 848 for the Session Initiation Protocol (SIP)", RFC 5850, 849 May 2010. 851 [ECMA269] ECMA International, "Services for Computer Suported 852 Telecommunications Communications Applications (CSTA) 853 Phase III", Standard ECMA-269, December 2006. 855 [ECMA323] ECMA International, "XML Protocol for Computer Supported 856 Telecommunications Applications (CSTA) Phase III", 857 Standard ECMA-323, December 2006. 859 [TR87] ECMA International, "Using CSTA for SIP Phone User Agents 860 (uaCSTA)", Technical Report TR/87, June 2004. 862 Author's Addresses 864 Rifaat Shekh-Yusef 865 Avaya 866 250 Sidney Street 867 Belleville, Ontario K8P 5B7 868 Canada 870 Phone: +1-613-967-5267 871 Email: rifatyu@avaya.com 873 Cullen Jennings 874 Cisco Systems 875 170 West Tasman Drive 876 Mailstop SJC-21/2 877 San Jose, CA 95134 878 USA 880 Phone: +1-408-902-3341 881 Email: fluffy@cisco.com 883 Alan Johnston 884 Avaya 885 St. Louis, MO 63124 886 USA 888 Email: alan.b.johnston@gmail.com 890 Francois Audet 891 Skype 892 USA 894 Email: francois.audet@skype.net