idnits 2.17.1 draft-ietf-bliss-call-completion-16.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (September 07, 2012) is 4250 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 XXXX' is mentioned on line 1407, but not defined ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 bliss D. Worley 3 Internet-Draft Ariadne Internet Services, Inc. 4 Intended status: Standards Track M. Huelsemann 5 Expires: March 11, 2013 R. Jesske 6 Deutsche Telekom 7 D. Alexeitsev 8 TeleFLASH 9 September 07, 2012 11 Call Completion for Session Initiation Protocol (SIP) 12 draft-ietf-bliss-call-completion-16 14 Abstract 16 The call completion feature defined in this specification allows the 17 caller of a failed call to be notified when the callee becomes 18 available to receive a call. 20 For the realization of a basic solution without queuing, this 21 document references the usage of the dialog event package (RFC 4235) 22 that is described as 'automatic redial' in the SIP Service Examples 23 (RFC 5359). 25 For the realization of a more comprehensive solution with queuing , 26 this document introduces an architecture for implementing these 27 features in the Session Initiation Protocol where "Call completion" 28 implementations associated with the caller's and callee's endpoints 29 cooperate to place the caller's request for call completion into a 30 queue at the callee's endpoint, and when a caller's request is ready 31 to be serviced, re-attempt of the original, failed call is made. 33 The architecture is designed to interoperate well with existing call- 34 completion solutions in other networks. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on March 11, 2013. 53 Copyright Notice 55 Copyright (c) 2012 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 2. Requirements terminology . . . . . . . . . . . . . . . . . . . 5 72 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 4.1. Call-completion architecture . . . . . . . . . . . . . . . 7 75 4.2. Call-completion procedures . . . . . . . . . . . . . . . . 9 76 4.3. Automatic redial as a fallback . . . . . . . . . . . . . . 11 77 4.4. Differences from SS7 . . . . . . . . . . . . . . . . . . . 12 78 5. Call-completion queue model . . . . . . . . . . . . . . . . . 12 79 6. Caller's agent behavior . . . . . . . . . . . . . . . . . . . 13 80 6.1. Receiving the CC possible indication . . . . . . . . . . . 13 81 6.2. Subscribing to CC . . . . . . . . . . . . . . . . . . . . 14 82 6.3. Receiving a CC recall notification . . . . . . . . . . . . 14 83 6.4. Initiating a CC call . . . . . . . . . . . . . . . . . . . 15 84 6.5. Suspending CC . . . . . . . . . . . . . . . . . . . . . . 15 85 6.6. Resuming CC . . . . . . . . . . . . . . . . . . . . . . . 15 86 7. Callee's monitor behavior . . . . . . . . . . . . . . . . . . 16 87 7.1. Sending the CC possible indication . . . . . . . . . . . . 16 88 7.2. Receiving a CC subscription . . . . . . . . . . . . . . . 17 89 7.3. Sending a CC notification . . . . . . . . . . . . . . . . 17 90 7.4. Receiving a CC call . . . . . . . . . . . . . . . . . . . 18 91 7.5. Receiving a CC suspension . . . . . . . . . . . . . . . . 19 92 7.6. Receiving a CC resumption . . . . . . . . . . . . . . . . 19 93 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 9. Call-completion event package . . . . . . . . . . . . . . . . 24 95 9.1. Event package name . . . . . . . . . . . . . . . . . . . . 24 96 9.2. Event package parameters . . . . . . . . . . . . . . . . . 24 97 9.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 24 98 9.4. Subscribe duration . . . . . . . . . . . . . . . . . . . . 25 99 9.5. NOTIFY bodies . . . . . . . . . . . . . . . . . . . . . . 25 100 9.6. Subscriber generation of SUBSCRIBE requests . . . . . . . 26 101 9.7. Notifier processing of SUBSCRIBE requests . . . . . . . . 26 102 9.8. Notifier generation of NOTIFY requests . . . . . . . . . . 26 103 9.9. Subscriber processing of NOTIFY requests . . . . . . . . . 27 104 9.10. Handling of forked requests . . . . . . . . . . . . . . . 27 105 9.11. Rate of notifications . . . . . . . . . . . . . . . . . . 27 106 9.12. State agents . . . . . . . . . . . . . . . . . . . . . . . 28 107 10. Call-completion information format . . . . . . . . . . . . . . 28 108 10.1. Call-completion status . . . . . . . . . . . . . . . . . . 28 109 10.2. Call-completion service-retention indication . . . . . . . 28 110 10.3. Call-completion URI . . . . . . . . . . . . . . . . . . . 29 111 11. Security considerations . . . . . . . . . . . . . . . . . . . 29 112 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 30 113 12.1. SIP event package registration for call-completion . . . . 30 114 12.2. MIME registration for application/call-completion . . . . 30 115 12.3. SIP/SIPS URI parameter 'm' . . . . . . . . . . . . . . . . 31 116 12.4. Call-Completion purpose parameter value . . . . . . . . . 32 117 12.5. 'm' header parameter for Call-Info . . . . . . . . . . . . 32 118 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32 119 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 120 14.1. Normative References . . . . . . . . . . . . . . . . . . . 33 121 14.2. Informative References . . . . . . . . . . . . . . . . . . 33 122 Appendix A. Example Caller's Agent . . . . . . . . . . . . . . . 34 123 Appendix B. Example Callee's Monitor . . . . . . . . . . . . . . 35 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 126 1. Introduction 128 The call completion (CC) feature allows the caller of a failed call 129 to have the call completed without having to make a new call attempt 130 while guessing when the callee becomes available. When the caller 131 requests the use of the CC feature, the callee will be monitored for 132 its availability. When the callee becomes available the callee will 133 be given a certain timeframe for initiating a call. If the callee 134 does not initiate a new call within this timeframe, then the caller 135 will be recalled. When the caller accepts the CC recall then a CC 136 call to the callee will automatically start. If several callers have 137 requested the CC feature on the same callee, they will be recalled in 138 a predefined order, which is usually the order in which they have 139 requested the CC feature. 141 This draft defines the following CC features: 143 Call Completion on Busy Subscriber (CCBS): The callee is busy. The 144 caller is recalled after the callee is not busy any longer. 146 Call Completion on No Reply (CCNR): The callee does not answer the 147 call. The caller is recalled after the callee has completed a new 148 call. 150 Call Completion on Not Logged-in (CCNL): The callee is not 151 registered. The caller is recalled after the callee has registered 152 again. 154 2. Requirements terminology 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 157 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 158 document are to be interpreted as described in [RFC2119]. 160 This document uses terms from [RFC3261]. 162 3. Terminology 164 For the purpose of this service, we provide the following 165 terminology: 167 Callee: a destination of the original call, and a target of the CC 168 call. 170 Caller: The initiator of the original call and the CC request. The 171 user on whose behalf the CC call is made. 173 Callee's monitor: a logical component which implements the call- 174 completion queue for destination user(s)/UA(s), and performs the 175 associated tasks, including sending CC recall events, analogous to 176 the destination local exchange's role in SS7 CC. 178 Caller's agent: a logical component which makes CC requests and 179 responds to CC recall events on behalf of originating user(s)/UA(s), 180 analogous to the originating local exchange's role in SS7 CC. 182 CC, or call completion: a service which allows a caller who failed to 183 reach a desired callee to be notified when the callee becomes 184 available to receive a call. 186 CC activation: the indication by the caller to the caller's agent 187 that the caller desires CC for a failed original call; this implies 188 an indication transmitted from the caller's agent to the callee's 189 monitor of the desire for CC processing. 191 CCBS, or Call Completion on Busy Subscriber: a CC service when the 192 initial failure was that the destination UA was busy. 194 CCNR, or Call Completion on No Reply: a CC service when the initial 195 failure was that the destination UA did not answer. 197 CCNL, or Call Completion on Not Logged-in: a CC service when the 198 initial failure was that the destination UA was not registered. 200 CC call: a call from the caller to the callee, triggered by the CC 201 service when it has determined that the callee is available. 203 CC indicator: an indication in the CC call INVITE used to prioritize 204 the call at the destination. 206 CC possible indication: the data in responses to the INVITE of the 207 original call which indicate that CC is available for the call. 209 CC recall: the action of the callee's monitor selecting a particular 210 CC request for initiation of a CC call, resulting in an indication 211 from the caller's agent to the caller that it is now possible to 212 initiate a CC call. 214 CC recall events: event notifications of event package "call- 215 completion", sent by the callee's monitor to the caller's agent to 216 inform it of the status of its CC request. 218 CC recall timer: maximum time the callee's monitor will wait for the 219 caller's response to a CC recall. 221 CC request: the entry in the callee's monitor queue representing the 222 caller's request for CC processing, that is, the caller's call- 223 completion subscription. 225 CC service duration timer: maximum time a CC request may remain 226 active within the network. 228 CC queue: a buffer at the callee's monitor which stores incoming 229 calls which are target for call completion. Note: This buffer may or 230 may not be organized as a queue. The use of the term "queue" is by 231 analogy with SS7 usage. 233 CCE: or call-completion entity: the representation of a CC request, 234 or equivalently, an existing call-completion subscription within a 235 callee's monitor's queue 237 Failed call: a call which does not reach a desired callee, from the 238 caller's point of view. Note that a failed call may be successful 239 from the SIP point of view; e.g., if the call reached the callee's 240 voicemail, but the caller desired to speak to the callee in person, 241 the INVITE receives a 200 response, but the caller considers the call 242 to have failed. 244 Original call: the initial call which failed to reach a desired 245 destination. 247 Retain option: a characteristic of the CC service; if supported, CC 248 calls which again encounter a busy callee will not be queued again, 249 but the position of the caller's entry in the queue is retained. 250 Note that SIP CC always operates with the retain option active; a 251 failed CC call does not cause the CC request to lose its position in 252 the queue. 254 Suspended CC request: a CC request which is temporarily not to be 255 selected for CC recall. 257 4. Solution 259 4.1. Call-completion architecture 261 The call-completion architecture augments each caller's UA (or UAC) 262 which wishes to use the call-completion features with a "call- 263 completion agent" (also written as "caller's agent"). 265 It augments each callee's UA (or UAS) which wishes to be the target 266 of the call-completion features with a "call-completion monitor" 267 (also written as "callee's monitor"). 269 The caller's agent and callee's monitor functions can be integrated 270 into the respective UAs, be independent end-systems, or be provided 271 by centralized application servers. The two functions, though they 272 are associated with the two UAs, also may be provided as services by 273 the endpoints' home proxies or other network elements. Though it is 274 expected that a UA that implements call completion will have both 275 types of functions so that it can participate in call completion as 276 both caller and callee, the two functions are independent of each 277 other. 279 A caller's agent may service more than one UA as a collective group 280 if it is common that a caller or population of users will be shared 281 between the UAs, and especially if the UAs share an AOR. The 282 caller's agent monitors calls made from the UA(s) in order to 283 determine their destinations and (potentially) their final response 284 statuses, and the Call-Info header fields of provisional and final 285 responses for information necessary to invoke call completion 286 feature. 288 A callee's monitor may service more than one UA as a collective group 289 if it is common that a callee or population of users will be shared 290 between the UAs, and especially if the UAs share an AOR. The 291 callee's monitor may supply the callee's UAS(s) with Call-Info header 292 field values for provisional and final responses. 294 The callees using the UA(s) may be able to indicate to the callee's 295 monitor when they wish to receive CC calls. 297 In order to allow flexibility and innovation, most of the interaction 298 between the caller's agent, the caller-user(s) and the caller's UA(s) 299 is out of the scope of this document. Similarly, most of the 300 interaction between the callee's monitor, the callee(s) and the 301 callee's UA(s) is out of the scope of this document, as is also the 302 policy by which the callee's monitor arbitrates between multiple 303 call-completion requests. 305 The caller's agent must be capable of performing a number of 306 functions relative to the UA(s). The method by which it does so is 307 outside the scope of this document, but an example method is 308 described in Appendix A. The callee's monitor must be capable of 309 performing a number of functions relative to the UA(s). The method 310 by which it does so is outside the scope of this document, but an 311 example method is described in Appendix B. 313 As a proof of concept, simple caller's agents and callee's monitors 314 can be devised that interact with users and UAs entirely through 315 standard SIP mechanisms [RFC6665], [RFC4235] and [RFC3515], as 316 described in the Appendixes. 318 The callers using the UA(s) can indicate to the caller's agent when 319 they wish to avail themselves of CC for a recently-made call which 320 the callers estimated to not have been successful. The caller's 321 agent monitors the status of the UA(s) to determine when they are 322 available to be used for a CC recall. The caller's agent can 323 communicate to the UA(s) that a CC recall is in progress and to 324 inquire if the relevant caller is available for the CC recall. The 325 caller's agent can order the UA(s) at which the relevant caller is 326 available to generate a CC call to the callee. 328 The callee's monitor has a method of monitoring the status of the 329 UA(s) and/or their users to determine when they are "available" for a 330 CC call, that is, in a suitable state to receive a CC call. This can 331 be achieved by monitoring calls made to the UA(s) in order to 332 determine their callers and (potentially) their final response 333 statuses. In a system with rich presence information, the presence 334 information may directly provide this status. In a more restricted 335 system, this determination can depend on the mode of the CC call in 336 question, which is provided by the 'm' parameter. E.g., a UA is 337 considered available for CCBS ("m=BS") when it is not busy, but a UA 338 is considered available for CCNR ("m=NR") when it becomes not busy 339 after being busy with an established call. 341 The callee's monitor maintains information about the set of INVITEs 342 received by the UA(s) that may not have been considered successful by 343 the caller. In practice, the callee's monitor may remove knowledge 344 about an incoming dialog from its set if local policy at the callee's 345 monitor establishes that the dialog is no longer eligible for CC 346 activations. 348 4.2. Call-completion procedures 350 The caller's UA sends an INVITE to a request URI. One or more forks 351 of this request reach one or more of the callee's UAs. If the call- 352 completion feature is available, the callee's monitor (note there can 353 be a monitor for each of the callee's UAs) inserts a Call-Info header 354 field with its URI and with "purpose=call-completion" in appropriate 355 non-100 provisional or final response messages to the initial INVITE 356 and forwards them to the caller. The provisional response messages 357 SHOULD be sent reliably, if the INVITE contained a Supported header 358 field with the option tag 100rel. On receipt of a non-100 359 provisional or a final response with the indication that the call- 360 completion feature is available, the calling user can invoke the 361 feature. 363 The caller indicates to the caller's agent that he wishes to invoke 364 call-completion services on the recent call. Note that from the SIP 365 point of view, the INVITE may have been successful, but from the 366 user's point of view, the call may have been unsuccessful. E.g., the 367 call may have connected to the callee's voicemail, which would return 368 a 200 status to the INVITE but from the caller's point of view is "no 369 reply". 371 In order to receive information on changes in the possibility for the 372 caller to complete the call at the callee, the caller's agent 373 subscribes to the call-completion event package at the callee's 374 monitor. This subscription is used to coordinate with the callee's 375 monitor (and indirectly with other caller's agents and other callee's 376 monitors) to implement the call-completion features. 378 The possibility of the caller to complete the call at the callee is 379 also known as the call-completion state (cc-state) of the caller. 380 The cc-states comprehend the values 'queued' and 'ready' (for call- 381 completion). 383 In order to receive information from all destinations where the 384 callee will probably be reachable again, the caller's agent sends a 385 SUBSCRIBE request for the call-completion event package to the 386 original destination URI of the call and to all known callee's 387 monitor URIs (which are provided by Call-Info header fields in 388 provisional and final responses to the INVITE). This SUBSCRIBE 389 reaches the callee's monitor. The callee's monitor uses the 390 subscription as an indication that caller is interested in using the 391 CC feature with regard to the specified callee. The callee's monitor 392 keeps a list or queue of the caller's agent's subscriptions, which 393 indicate the callers waiting for the CC recall. 395 The subscriptions generated by the SUBSCRIBE requests represent the 396 requests from the caller's agent to the callee's monitors for call- 397 completion services. These subscriptions are created, refreshed, and 398 terminated according to the procedures of [RFC6665]. 400 When the callee's monitor judges that the callee and/or callee's UA 401 is available for call-completion, the callee's monitor selects a 402 caller to execute the CC call to the callee. The callee's monitor 403 sends a call-completion event update (''cc-state: ready'') to the 404 selected caller's agent's subscription, telling it to begin the CC 405 recall. 407 When the caller's agent receives this update, it initiates the CC 408 recall by calling the caller's UA or otherwise tests whether the 409 caller is available to initiate the CC call. If the caller is 410 available, the caller's agent directs the caller's UA to make the 411 call to the callee again (CC call). This call is marked as a CC call 412 by adding a specific SIP URI parameter to the Request-URI, so it can 413 be given precedence by the callee's monitor in reaching the callee's 414 UA. 416 If the caller is not available on the receipt of the "ready for 417 recall" notification, the CC agent suspends the CC request at the CC 418 monitor by sending a PUBLISH request containing presence information 419 to the callee's monitor, informing about the presence status 420 'closed'. The receipt of the PUBLISH request initiates a presence 421 event state for this call at the CC monitor, together with a logical 422 presence server if this has not been done before for another call. 423 Once the caller becomes available for CC again, the CC agent resumes 424 the CC request by sending another PUBLISH request to the callee's 425 monitor, informing about the presence status 'open'. 427 On the receipt of the suspension request from the caller's agent at 428 the top of the queue, the callee's monitor shall perform the 429 monitoring for the next non-suspended cc request in the queue. On 430 the receipt of the resume from the previously suspended caller's 431 agent that was at the top of the queue, the callee's monitor shall 432 perform the callee monitoring for this caller's agent. 434 When the call completion call fails there are two possible options: 435 the CC feature has to be activated again by caller's agent 436 subscribing to callee's monitor, or CC remains activated and the 437 original CC request retains its position in the queue if retain 438 option is supported. Note that the caller's agent can refresh the 439 subscription. 441 4.3. Automatic redial as a fallback 443 Automatic redial is a simple end-to-end design. An automatic redial 444 scenario is described in [RFC5359], section 2.17. This solution is 445 based on the usage of the dialog event package. When the callee is 446 busy when the call arrives, the caller subscribes to the callee's 447 call state. The callee's UA sends a notification when the callee's 448 call state changes. This means the caller is also notified when the 449 callee's call state changes to 'terminated'. The caller is alerted, 450 then the caller's UA starts a call establishment to the callee again. 451 If several callers have subscribed to a busy callee's call state, 452 they will be notified at the same time that the call state has 453 changed to 'terminated'. The problem of this solution is, that it 454 might happen that several recalls are started at the same time. This 455 means it is a heuristic approach with no guarantee of success. 457 There is no interaction between call completion and automatic redial, 458 as there is a difference in the behavior of the callee's monitor and 459 the caller when using the dialog event package for receiving dialog 460 information or for aggregating a call completion state. 462 4.4. Differences from SS7 464 SIP call completion differs in some ways from the CCBS and CCNR 465 features of SS7 (which is used in the PSTN). For ease of 466 understanding, we enumerate some of the differences here. 468 Due to the complex forking situations that are possible in SIP, a 469 call may "fail" from the point of view of the user and yet have a 470 "success" response from SIP's point of view. (This can happen even 471 in simple situations: e.g., a call to a busy user that fails over to 472 his voicemail receives a SIP success response, even though the caller 473 may consider it "busy subscriber".) Thus, the caller must be able to 474 invoke call completion even when the original call appeared to 475 succeed. To support this, the caller's agent must record successful 476 calls as well as unsuccessful calls. 478 In SIP, only the caller's UA or service system on the originating 479 side and the callee's UA or service system on the terminating side 480 need to support call completion for call completion to work 481 successfully between the UAs. Intermediate SIP systems (proxies or 482 B2BUAs) do not need to implement call completion; they only need to 483 be transparent to the usual range of SIP messages. 485 Due to flexibility needed to support legacy systems that are not 486 optimized to support call completion, there are a larger number of 487 situations in SIP where call completion services are offered but 488 cannot be successfully executed. 490 5. Call-completion queue model 492 The callee's monitor manages CC for a single URI. This URI is likely 493 to be a published AOR, or more likely "non-voicemail AOR", but it may 494 be as narrowly scoped as a single UA's contact URI. The callee's 495 monitor manages a dynamic set of call-completion entities (called 496 "CCEs") which represent CC requests, or equivalently, the existing 497 incoming call-completion subscriptions. This set is also called a 498 queue, because a queue data structure often aids in implementing the 499 callee's monitor's policies for selecting CCEs for CC recall. 501 Each CCE has an availability state, which is either "available" (for 502 recall) or "not-available" (for recall). It is not visible via 503 subscriptions. 505 Each CCE has a recall state which is visible via subscriptions. The 506 recall state is either "queued" or "ready". 508 Each CCE carries the From URI of the SUBSCRIBE request that caused 509 its creation. 511 CC subscriptions arrive at the callee's monitor by addressing the 512 URIs the callee's monitor returns in Call-Info header fields. The 513 request URI of the SUBSCRIBE request determines the queue to which 514 the resulting CCE is added. The resulting subscription reports the 515 status of the queue. The base event data is the status of all the 516 CCEs in the queue, but the data returned by each subscription is 517 filtered to report only the status of that subscription's CCE. 518 (Further standardization may define means for obtaining more 519 comprehensive information about a queue.) 521 When a CCE is created, it is given the availability state "available" 522 and recall state "queued". 524 The callee's monitor may receive PIDF bodies [RFC3863] via PUBLISH 525 requests [ [RFC3903]] directed at its URI. These PUBLISH requests 526 are expected to be sent by subscribers to suspend and resume their CC 527 requests. A CCE is identified by the request-URI (if it was taken 528 from a call-completion event notification which identifies the CCE) 529 or the From URI of the request (matching the From URI recorded in the 530 CCE). Receipt of a PUBLISH with 'status' of 'open' sets the 531 availability state of the CCE to 'available'; 'status' of 'closed' 532 sets the availability state of the CCE to 'not-available'. 534 The callee's monitor MUST select for recall only CC requests whose 535 CCE's have availability state 'available', and for which the callee 536 appears to be available when considering the 'm' value of the CCE. 537 Within that constraint, the callee's monitor's selections are 538 determined by its policy. Often, a callee's monitor will choose the 539 acceptable CCE that has been in the queue the longest. When the 540 callee's monitor has selected a CCE for recall, it changes the CCE's 541 recall state from 'queued' to 'ready', which triggers a notification 542 on the CCE's subscription. 544 If a selected subscriber then suspends its request by sending a 545 PUBLISH with the presence status 'closed', the CCE becomes not- 546 available, and the callee's monitor changes the CCE's recall state to 547 'queued'. This may cause another CCE (e.g., that has been in the 548 queue for less time) to be selected for recall. 550 6. Caller's agent behavior 552 6.1. Receiving the CC possible indication 554 The caller's agent MUST record the From URI and SHOULD record the 555 final request status that the caller's UA received along with the 556 contents of Call-Info header fields of provisional and final 557 responses. 559 Note that receiving a CC possible indication also depends on the 560 aggregation of final responses by proxies, in case of 4xx responses 561 some 4xx responses are more likely to be sent to the caller. 563 6.2. Subscribing to CC 565 For CC activation the caller's agent MUST send a SUBSCRIBE to all 566 known callee's monitor URIs. A callee's monitor URI may be provided 567 by the Call-Info header field in provisional and final responses to 568 the INVITE sent back by the callee's monitor(s). Additionally, the 569 caller's agent SHOULD include the original request-URI that it sent 570 the original INVITE to, in its set of callee's monitor URIs, when it 571 is unclear if the call has forked to additional callees whose 572 responses the caller has not seen. A SUBSCRIBE to the original 573 request-URI alone is used in cases where the caller's agent has not 574 received or does not remember any callee's monitor URI. The caller's 575 agent SHOULD add an 'm' parameter to these URIs in order to indicate 576 the desired call-completion proceeding at the callee's monitor. The 577 'm' parameter SHOULD have the value of the 'm' parameter received in 578 the Call-Info header field, if a Call-Info header field was received 579 with 'm' parameter in responses to the original INVITE. 581 To minimize redundant subscriptions, these SUBSCRIBEs SHOULD 582 presented as forks of the same transaction as defined by section 583 8.2.2.2 of [RFC3261], if the caller's agent is capable of doing so. 585 The SUBSCRIBE SHOULD have header fields to optimize its routing. In 586 particular, it SHOULD contain "Request-Disposition: parallel", and an 587 Accept-Contact header field to eliminate callee UAs that are not 588 acceptable to the caller. 590 The caller's agent MUST be prepared to receive multiple responses for 591 multiple forks of the SUBSCRIBE and to have multiple subscriptions 592 established. The agent must also be prepared to have the SUBSCRIBE 593 fail, in which case, CC cannot be invoked for this original call. 595 If the caller's agent no longer wants to initiate the CC call (e.g., 596 because the caller has deactivated CC), the caller's agent terminates 597 the subscription in accordance with [RFC6665] or suspends the 598 subscription(s) as specified in subclause 6.5. 600 6.3. Receiving a CC recall notification 602 When receiving a NOTIFY with the cc-state set to 'ready', the 603 caller's agent SHOULD suspend all subscriptions to CC for all other 604 original calls, by following the step in section 6.5, in order to 605 prevent any other CC requests from this caller to receive cc recalls. 606 The caller's agent starts the CC recall to the caller by confirming 607 that the caller would be able to initiate a CC call, e.g. by calling 608 the caller's UA(s). 610 6.4. Initiating a CC call 612 If the caller is available for the CC call and willing to initiate 613 the CC call, the caller's agent causes the caller's UA to generate a 614 new INVITE towards the callee. The caller's UA MAY add a 'm' URI 615 parameter with the value of the 'm' parameter received in Call-Info 616 header in the response to original INVITE, in order to specify his 617 preferences in CC processing and to prioritize the CC call. The 618 INVITE SHOULD be addressed to the URI specified in the cc-URI of the 619 NOTIFY, or if not available it SHOULD use the URI in the Call-Info 620 header field of the response to the original INVITE, or if not 621 available it MAY use the request-URI of the original INVITE, if this 622 URI was recorded. Note that the latter choice may not provide ideal 623 routing, but in simple cases it is likely to reach the desired 624 callee/callee's monitor. 626 6.5. Suspending CC 628 If the caller is not available for the CC recall, or if determined by 629 the caller's agent's suspension policy, the CC request SHALL be 630 suspended by the caller's agent until the caller becomes available 631 again, or if the conditions relevant to the caller's agent's local 632 policy for suspensions have changed. To suspend the CC request, the 633 caller's agent SHALL publish the caller's presence state by sending a 634 PUBLISH request to each callee's monitor in accordance with the 635 procedures described in [RFC3903] , giving the PIDF state 'closed' 636 for the caller's identity as presentity. The PUBLISH request SHOULD 637 contain an Expires header field with a value that corresponds to the 638 current value of the remaining CC subscription duration. 640 Each PUBLISH SHOULD be sent to the CC URI as received in the NOTIFY, 641 or within the corresponding SUBSCRIBE dialog, or if that is not 642 possible, to the corresponding callee's monitor URI received in the 643 Call-Info header field of the NOTIFY, or if one is not available, the 644 Contact address of the subscription. If a queue entry is suspended, 645 it is stepped over during CC processing at the callee's monitor. 647 6.6. Resuming CC 649 When the caller is no longer busy, or if the conditions relevant to 650 the caller's agent's suspension policy have changed, then the CC 651 request SHALL be resumed by the caller's agent. To resume a CC 652 request, the caller's agent SHALL publish the Caller's presence state 653 by sending a PUBLISH request to each callee's monitor a PUBLISH 654 request in accordance with the procedures described in [RFC3903] , 655 informing about the PIDF state 'open' but otherwise be constructed as 656 same as the suspend PUBLISH request. 658 In the case where the caller's agent has sent several CC suspension 659 requests to different callee's monitors and the caller becomes 660 available again, as determined by the caller's agent's local policy 661 about resumption the caller's agent MAY send a PUBLISH to resume a CC 662 request to each callee's monitor for which there is a suspended CC 663 request. Note that the caller's agent's policy about resumption may 664 prescribe a manual resumption and thus a suspended CC request should 665 not be automatically resumed. 667 7. Callee's monitor behavior 669 7.1. Sending the CC possible indication 671 The callee's monitor MUST record the From URI and MAY record the 672 final request status(es) returned by the callee's UA(s). 674 If the callee's monitor wants to enable the caller to make use of the 675 CC service, it MUST insert a Call-Info header field with 676 "purpose=call-completion" in the final response message (e.g. in a 677 486 to enable call-completion due to busy subscriber) and at least 678 one non-100 provisional response message (e.g. in a 180 due to no 679 response) to the initial INVITE when forwarding it to the caller. 680 The non-100 provisional response message SHOULD be sent reliably if 681 the INVITE contained a Supported header field with the option tag 682 100rel. The Call-Info header field values defined in this 683 specification positively indicates that CC is available for this 684 failed fork of the call. 686 The callee's monitor SHOULD insert a URI in the Call-Info header 687 field where the caller's agent should subscribe for call-completion 688 processing. Ideally, it is a globally-routable URI for the callee's 689 monitor. In practice, it may be the callee's AOR, and the SUBSCRIBE 690 will be routed to the callee's monitor only because it specifies 691 "Event: call-completion". 693 In order to enable call-completion, the Call-Info header field MUST 694 be set up according to the following scheme: 696 Call-Info:monitor-URI;purpose=call-completion;m=XX 698 The 'm' parameter defines the "mode" of call completion. The "m=NR" 699 parameter indicates that it failed due to no response, the "m=BS" 700 parameter indicates that it failed due to busy subscriber, and the 701 "m=NL" parameter indicates that it failed due to not registered 702 subscriber. The 'm' parameter is useful for PSTN interworking and 703 assessing presence information in the callee's monitor. It is 704 possible that other values will be defined in future. It is also 705 allowed to omit the 'm' parameter entirely. Implementations MUST 706 accept CC operations in which the 'm' parameter is missing or has an 707 unknown value, and execute them at its best in their environment 708 (which is likely to be a degraded service, especially in 709 interoperation with SS7). 711 7.2. Receiving a CC subscription 713 The callee's monitor MUST be prepared to receive SUBSCRIBEs for the 714 call-completion event package directed to the URIs of UA(s) serviced 715 by the callee's monitor and any URIs that the callee's monitor 716 provides in Call-Info header fields. The SUBSCRIBEs MUST be 717 processed in accordance with the procedures defined in [RFC6665]. 719 The callee's monitor(s) that receive the SUBSCRIBE establish 720 subscriptions. These subscriptions represent the caller's agent's 721 request for call-completion services. The callee's monitor may apply 722 restrictions as to which caller's agents may subscribe. 724 The continuation of the caller's agent's subscription indicates to 725 the callee's monitor that the caller's agent is prepared to initiate 726 the CC call if it is selected for the 'ready' state. If the callee's 727 monitor becomes aware of a subscription which cannot be selected for 728 a cc recall, it SHOULD terminate the subscription in accordance with 729 [RFC6665]. 731 7.3. Sending a CC notification 733 The call-completion event package returns various information to the 734 caller's agent, but the vital datum is that it contains is the cc- 735 state of the caller's agent's CC request in the CC queue, which in 736 the beginning is 'queued'. When the cc-state of the agent's request 737 changes, the callee's monitor MUST send a NOTIFY for a call- 738 completion event to the caller's agent. The notification SHOULD also 739 contain a URI which can be used for suspension requests. Ideally, it 740 is a globally-routable URI for the callee's monitor. In practice, it 741 may be the callee's AOR, and the SUBSCRIBE will be routed to the 742 callee's monitor only because it specifies "Event: call-completion". 744 The call-completion event package provides limited information about 745 the callee's monitor's policy. In particular, like in the PSTN, the 746 "'cc-service-retention" datum gives an indication of the "service 747 retention" attribute, which indicates whether the CC request can be 748 continued to a later time if the cc call fails due to the callee's 749 UA(s) being busy. If the callee's monitor supports the service- 750 retention option, the callee's monitor SHOULD include the cc-service- 751 retention parameter. 753 The callee's monitor has a policy regarding when and how it selects 754 CC requests for the recall. This policy may take into account the 755 type of the requests (e. g. CCNR vs. CCBS), the state of the 756 callee's UA(s), the order in which the CC requests arrived, the 757 length of time the CC requests have been active, and any previous 758 attempts of CC activations for the same original call. Usually the 759 callee's monitor will choose only one CC request for the recall at a 760 time, but if the callee's UA(s) can support multiple calls, it may 761 choose more than one. Usually the callee's monitor will choose the 762 oldest active request. 764 When the callee's monitor changes the state datum for the chosen 765 subscription from "queued" to "ready", the callee's monitor MUST send 766 a NOTIFY for the caller's agent's subscription with the cc-state set 767 to 'ready' (recall notification). The NOTIFY SHOULD also contain in 768 the cc-URI a URI to be used in the CC call. In practice, this may be 769 the AOR of the callee. 771 Upon sending the recall notification the callee's monitor MUST start 772 a recall timer. It is RECOMMENDED to use a value between 10 and 20 773 seconds, which corresponds to the recommendation for the call 774 completion services in ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733]. 776 7.4. Receiving a CC call 778 The callee's UA(s) and the callee's monitor may give the CC call 779 precedence over non-CC calls by evaluating the presence of the 'm' 780 URI parameter and the From header of the INVITE request. The 781 callee's monitor supervises the receiving of the CC call. Upon 782 arrival of the CC call the recall timer MUST be stopped. If the CC 783 call does not arrive at the callee's UA(s) before the expiry of the 784 recall timer, the callee's monitor SHOULD stop processing the recall 785 and change the value of the cc-state datum to "queued". Similarly, 786 if the CC call is not accepted, the callee's monitor will stop the CC 787 recall processing. Depending on its policy, the same original call 788 may be selected again for a CC recall at a later time. If the CC 789 call succeeds, the callee's monitor MUST terminate the relevant 790 subscription in accordance with [RFC6665], and MUST remove any 791 remaining presence event state for the caller of the CC call. 793 Once the CC call has been terminated, successfully or unsuccessfully, 794 the callee's monitor's policy MAY select another CC request for a 795 recall according to the callee's monitor's policy. Note that 796 according to the callee's monitor's policy also several recalls at a 797 time can be processed. 799 7.5. Receiving a CC suspension 801 The monitor may receive PUBLISH requests to suspend CC requests from 802 caller's agent as described in section 6.5. The PUBLISH requests may 803 be received via the URI it manages, any URI that it inserts into a 804 Call-Info header, any contact URI it uses as a notifier for "call- 805 completion" events, or any URI it returns as the "URI" line of the 806 call-completion event packages. 808 The receipt of the PUBLISH request initiates a presence event state 809 for the caller's identity at the presence server functionality of the 810 CC monitor as specified in [RFC3903] , together with a logical 811 presence server if this has not been done before for another call. 813 The monitor SHOULD identify the addressed CCE by the request-URI of 814 the PUBLISH request, or if that is not possible, by the From URI. 816 If the processing of a CC request results in suspending that CC 817 request by receiving a PUBLISH request from caller's agent as 818 described in section 6.5, the callee's monitor MUST stop the recall 819 timer and MUST ensure that the request is set to a 'queued' state, 820 and then the callee's monitor MUST attempt to process another CC 821 request in the queue according to the callee's monitor's local 822 policy. 824 7.6. Receiving a CC resumption 826 When a CC request becomes resumed by receiving a PUBLISH request from 827 caller's agent as described in section 6.6, the presence event state 828 for the caller's identity at the presence server functionality of the 829 CC monitor MUST be modified as described in [RFC3903]. If the callee 830 is not busy and there is no entry in the CC queue which is currently 831 being processed, the callee's monitor MUST process the queue as 832 described in section 7.3 above. 834 8. Examples 836 A basic flow, with only the most significant messages of a call- 837 completion activation and invocation shown, is as follows (please 838 note this is an example and there may be variations in the failure 839 responses): 841 Caller Callee 842 sip:123@a.com sip:456@b.com 843 | | 844 | INVITE sip:456@b.com | [original call] 845 | From: sip:123@a.com | 846 |------------------------->| 847 | | 848 | 487 | 849 | Call-Info:;purpose=call-completion;m=NR 850 |<-------------------------| 851 | | 852 | SUBSCRIBE sip:456@z.b.com;m=NR [initial SUBSCRIBE] 853 | From: sip:123@a.com | 854 | Contact: sip:123@y.a.com | 855 | Request-Disposition: parallel 856 | Call-Id: abcd-efgh | 857 | Event: call-completion | 858 |------------------------->| 859 | | 860 | 200 | 861 |<-------------------------| 862 | | 863 | NOTIFY sip:123@y.a.com | [initial NOTIFY] 864 | Body: status: queued | 865 |<-------------------------| 866 | | 867 | SUBSCRIBE sip:456@b.com;m=NR [another init. SUB.] 868 | From: sip:foo@example.com| 869 | Request-Disposition: parallel 870 | Call-Id: abcd-efgh | 871 | Event: call-completion | 872 |------------------------->| 873 | | 874 | 482 | [duplicate SUB. rej.] 875 |<-------------------------| 876 | | 877 | NOTIFY sip:123@y.a.com | [CC invoked] 878 | Body: status: ready | 879 | URI: sip:recall@z.b.com 880 |<-------------------------| 881 | | 882 | INVITE sip:recall@z.b.com;m=NR [CC call] 883 | From: sip:foo@example.com| 884 |------------------------->| 885 | | 886 | NOTIFY sip:123@y.a.com | [CC terminated] 887 | Expires = 0 | 888 |<-------------------------| 890 The original call is an ordinary INVITE. It fails due to no-response 891 (ring-no-answer). In this case, the callee's governing proxy 892 generates a 487 response because the proxy canceled the INVITE to the 893 UA when it rang too long without an answer. The 487 response carries 894 a Call-Info header field with "purpose=call-completion". The Call- 895 Info header field positively indicates that CC is available for this 896 failed fork of the call. The "m=NR" parameter indicates that it 897 failed due to no-response, which is useful for PSTN interworking and 898 assessing presence information in the callee's monitor. 900 The URI in the Call-Info header field () is where 901 the caller's agent should subscribe for call-completion processing. 902 Ideally, it is a globally-routable URI for the callee's monitor. In 903 practice, it may be the callee's AOR, and the SUBSCRIBE will be 904 routed to the callee's monitor only because it specifies "Event: 905 call-completion". 907 CC is activated by sending a SUBSCRIBE to all known callee's monitor 908 URIs. These can be provided by the Call-Info header field in the 909 response to the INVITE. 911 Additionally, the caller's agent needs to include the original 912 request-URI in its set of callee's monitor URIs, because the call may 913 have forked to additional callees whose responses the caller has not 914 seen. (A SUBSCRIBE to the request-URI alone is used in cases where 915 the caller's agent has not received or cannot remember any callee's 916 monitor URI.) 918 The caller's agent adds to these URIs an 'm' parameter (if possible). 919 In this case, the caller's agent forks the SUBSCRIBE to two 920 destinations as defined by section 8.2.2.2 of [RFC3261], with 921 appropriate Request-Disposition. The first SUBSCRIBE is to the URI 922 from Call-Info. 924 The second SUBSCRIBE is to the original request-URI, and reaches the 925 same callee's monitor. Because it has the same Call-Id as the 926 SUBSCRIBE that has already reached the callee's monitor, the callee's 927 monitor rejects it with a 482, thus avoiding redundant subscriptions. 929 The initial NOTIFY for the successful SUBSCRIBE has "state: queued" 930 in its body. Eventually, this caller is selected for CC, and is 931 informed of this via a NOTIFY containing "state: ready". This NOTIFY 932 carries a URI to which the INVITE for CC call should be sent. In 933 practice, this may be the AOR of the callee. 935 The caller generates a new INVITE to the URI specified in the NOTIFY, 936 or if there was no such URI or if the caller's agent cannot remember 937 it, it may use the original request-URI. The caller adds the 'm' 938 parameters (if possible), to specify CC processing. 940 Finally the subscription for the CC request is terminated by the 941 callee's monitor. 943 Another flow, with only the most significant messages of call- 944 completion suspension and resumption shown, is as follows: 946 Caller Callee 947 sip:123@a.com sip:456@b.com 948 | | 949 | NOTIFY sip:123@y.a.com | [CC notification, caller not 950 | Body: status: ready | available for CC recall] 951 | URI: sip:recall@z.b.com 952 |<-------------------------| 953 | | 954 | 200 | 955 |------------------------->| 956 | | 957 | PUBLISH sip:456@z.b.com | [non-availibility for recall 958 | From: sip:123@a.com | is published] 959 | Contact: sip:123@y.a.com | 960 | Event: presence 961 | Content-Type: 'app/pidf' | 962 | Body: status=closed 963 |------------------------->| 964 | | 965 | 200 | 966 |<-------------------------| 967 | | 968 | | [caller becomes available 969 | | again] 970 | | 971 | PUBLISH sip:456@z.b.com | [availibility for recall 972 | From: sip:123@a.com | is published] 973 | Contact: sip:123@y.a.com | 974 | Event: presence 975 | Content-Type: 'app/pidf' | 976 | Body: status=open 977 |------------------------->| 978 | | 979 | 200 | 980 |<-------------------------| 981 | | 983 The caller is selected for CC, and is informed of this via a NOTIFY 984 request containing "state: ready". At this time, the caller is not 985 available for the CC recall. 987 For updating his presence event state at the presence server 988 functionality at the callee, the caller generates a PUBLISH request 989 to the CC URI as received in the NOTIFY, or within the corresponding 990 SUBSCRIBE dialog, or if that is not possible, to the corresponding 991 callee's monitor URI received in the Call-Info header field of the 992 NOTIFY, or if one is not available, the Contact address of the 993 subscription, informing about the PIDF state 'closed' . 995 When the caller is again available for the CC recall, he caller 996 updates his presence event state at the presence server functionality 997 at the callee by generating a PUBLISH request informing about the 998 PIDF state 'open', but otherwise constructed as same as the suspend 999 PUBLISH request. 1001 9. Call-completion event package 1003 This section specifies the call-completion event package, in 1004 accordance with section 4.4 of [RFC6665]. The call-completion event 1005 package has the media type "application/call-completion". 1007 Note that if the callee has a caller-queuing facility, the callee's 1008 monitor may want to treat the call-completion queue as part of the 1009 queuing facility, and include in the event package information 1010 regarding the state of the queue. How this information is conveyed 1011 is left for further standardization. 1013 9.1. Event package name 1015 The SIP Events specification requires package definitions to specify 1016 the name of their package or template-package. The name of this 1017 package is "call-completion". This value appears in the Event and 1018 Allow-events header fields. 1020 9.2. Event package parameters 1022 No package-specific Event header field parameters are defined for 1023 this event package. 1025 9.3. SUBSCRIBE bodies 1027 [RFC6665] requires package definitions to define the usage, if any, 1028 of bodies in SUBSCRIBE requests. 1030 The SUBSCRIBE request MAY contain an Accept header field. If no such 1031 header field is present, it has a default value of "application/ 1032 call-completion". If the header field is present, it MUST include 1033 "application/call-completion". 1035 A SUBSCRIBE request for a call-completion package MAY contain a body. 1036 This body defines a filter to be applied to the subscription. Filter 1037 documents are not specified in this document, and may be the subject 1038 of future standardization activity. 1040 A SUBSCRIBE request requests call-completion information regarding 1041 calls recently made from the same caller to the callee UA(s) serviced 1042 by the notifier. Calls are defined to be "from the same caller" if 1043 the URI-part of the From header field value in the INVITE is the same 1044 as the URI-part of the From header field value in the SUBSCRIBE. 1046 9.4. Subscribe duration 1048 [RFC6665] requires package definitions to define a default value for 1049 subscription durations, and to discuss reasonable choices for 1050 durations when they are explicitly specified. 1052 If a SUBSCRIBE does not explicitly request a duration, the default 1053 requested duration is 3600 seconds, as that is the highest service 1054 duration timer value recommended for the call completion services in 1055 ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733]. As because of the 1056 subscription duration no explicit timer is needed, and the 1057 subscription duration can be seen as an equivalent to the SS7 service 1058 duration timer, this specification refers to the subscription 1059 duration also as the service duration timer. It is RECOMMENDED that 1060 subscribers request, and that notifiers grant, a subscription time of 1061 at least 3600 seconds. 1063 If a notifier can determine that, according to its policy, after 1064 certain duration the requested subscription can not any more proceed 1065 to "ready" state, it SHOULD reduce the granted subscription time to 1066 that duration. If a notifier can determine that, according to its 1067 policy, the requested subscription can never proceed to "ready" 1068 state, it should refuse the subscription. 1070 9.5. NOTIFY bodies 1072 [RFC6665] requires package definitions to describe the allowed set of 1073 body types in NOTIFY requests, and to specify the default value to be 1074 used when there is no Accept header field in the SUBSCRIBE request. 1075 A NOTIFY for a call-completion package MUST contain a body that 1076 describes the call-completion states. 1078 As described in [RFC6665], the NOTIFY message will contain bodies 1079 that describe the state of the subscribed resource. This body is in 1080 a format listed in the Accept header field of the SUBSCRIBE, or in a 1081 package-specific default format if the Accept header field was 1082 omitted from the SUBSCRIBE. 1084 In this event package, the body of the notification contains a call- 1085 completion document. All subscribers and notifiers MUST support the 1086 "application/call-completion" data format described in section 10. 1087 The SUBSCRIBE request MAY contain an Accept header field. If no such 1088 header field is present, it has a default value of "application/ 1089 call-completion". If the header field is present, it MUST include 1090 "application/call-completion". Of course, the notifications 1091 generated by the server MUST be in one of the formats specified in 1092 the Accept header field in the SUBSCRIBE request. 1094 9.6. Subscriber generation of SUBSCRIBE requests 1096 Subscribers MUST generate SUBSCRIBE requests when they want to 1097 subscribe to the call-completion event package at the terminating 1098 side in order to receive call-completion notifications. The 1099 generation of SUBSCRIBE requests can imply the usage of a call- 1100 completion service specific timer as described in section 9.4. 1102 9.7. Notifier processing of SUBSCRIBE requests 1104 Upon receiving a subscription refresh, the notifier MUST set the 1105 "expires" parameter of the Subscription-State header field to a value 1106 not higher than the current remaining duration of the subscription 1107 regardless of the value received in the Expires header field (if 1108 present) of the subscription refresh. 1110 If a subscription is not successful because the call-completion queue 1111 has reached the maximum allowed number of entries (short term 1112 denial), the notifier MUST send a 480 Temporarily Unavailable 1113 response to the subscriber, possibly with a Retry-after header field 1114 in accordance with the notifier's policy. If a subscription is not 1115 successful because a condition has occurred that prevents and will 1116 continue to prevent the call-completion service (long term denial), 1117 the notifier MUST send a 403 Forbidden response to the subscriber. 1119 A notifier MAY receive multiple forks of the same SUBSCRIBE, as 1120 defined by section 8.2.2.2 of [RFC3261]. In such a case, the 1121 notifier MUST reject all but one of the SUBSCRIBEs with a 482 Merged 1122 Request response unless some other failure response applies. 1124 The call-completion information can be sensitive. Therefore, all 1125 subscriptions SHOULD be handled with consideration of the security 1126 considerations discussed in section 11, in particular for verifying 1127 the identity of the subscriber. 1129 9.8. Notifier generation of NOTIFY requests 1131 Notifiers MUST generate NOTIFY requests when the CC request's state 1132 changes to 'queued' or to 'ready (for call-completion)'. A NOTIFY 1133 that is sent with non-zero expiration MUST contain the "cc-state" 1134 parameter. The parameter's value MUST be "queued" if the call- 1135 completion request represented by the subscription is not at this 1136 time selected by the callee's monitor for CC recall, and the 1137 parameter's value MUST be "ready" if the request is at this time 1138 selected by the callee's monitor for CC recall. 1140 A NOTIFY sent with a zero expiration (e.g., as a confirmation of a 1141 request to unsubscribe) MAY contain the "cc-state" parameter. 1143 When the callee's monitor withdraws the selection of the request for 1144 the CC recall (e.g., because the caller's agent has not initiated the 1145 CC recall INVITE before the CC recall timer expires, or because the 1146 agent has suspended the request from being considered for CC recall), 1147 the notifier MUST send a NOTIFY to the subscription of the selected 1148 request. This NOTIFY MUST contain the "cc-state" parameter set to 1149 "queued". 1151 If the call-completion subscription was successful and the retention 1152 option is supported at the callee, the NOTIFY MUST contain the "cc- 1153 service-retention" parameter. 1155 9.9. Subscriber processing of NOTIFY requests 1157 When receiving a NOTIFY requests with the cc-state set to 'ready', 1158 subscribers SHOULD suspend all other CC subscriptions for the 1159 original call at other notifiers. The receipt of a NOTIFY request 1160 with the cc-state set to 'ready' by the subscriber will also cause an 1161 interaction with the instances at the subscribers side hat are 1162 responsible for starting the CC recall. 1164 9.10. Handling of forked requests 1166 Forked requests are expected to be common for the call-completion 1167 event type. The subscriber MUST be prepared to process NOTIFY 1168 requests from multiple notifiers and to coordinate its processing of 1169 the information obtained from them in accordance with the procedures 1170 in this document. 1172 9.11. Rate of notifications 1174 The call completion service typically involves a single notification 1175 per notifier and per subscription that notifies about the change to 1176 'ready (for call-completion)', but MAY involve several notifications 1177 about the change to the 'ready' state, separated by a call completion 1178 call that failed due to a busy callee . Typically, notifications 1179 will be separated by at least tens of seconds. Notifiers SHOULD NOT 1180 generate more than three notifications for one subscription in any 1181 ten-second interval. Since it is important to avoid useless recalls, 1182 a notifier SHOULD send state changes to "queued" from "ready" 1183 promptly. Thus, a notifier SHOULD NOT send a state change to "ready" 1184 as the third notification in a ten-second interval, as that would 1185 make it impossible to promptly send a further state change to 1186 "queued". 1188 9.12. State agents 1190 State agents have no defined role in the handling of the call- 1191 completion package. 1193 10. Call-completion information format 1195 The following syntax specification uses the Augmented Backus-Naur 1196 Form (ABNF) as described in [RFC5234]. The formal syntax for the 1197 application/call-completion MIME type is described below. In 1198 general, the call-completion body is to be interpreted in the same 1199 way as SIP headers: (1) the names of the lines are case-insensitive, 1200 (2) the lines can be continued over line boundaries if the succeeding 1201 lines start with horizontal white space, and (3) lines with unknown 1202 names are to be ignored. The header lines defined in this document 1203 can occur at most once in any given call-completion document. 1205 call-completion = 1*(cc-header CRLF) 1207 cc-header = cc-state / cc-service-retention / cc-URI / extension- 1208 header 1210 The above rules whose names start with "cc-" are described below. 1211 Other rules are described in [RFC3261]. 1213 10.1. Call-completion status 1215 The cc-state line indicates the CC status of a particular user with 1216 an entry in a CC queue. It MUST be present unless the expiration 1217 time indicated in the NOTIFY is zero. 1219 cc-state = "cc-state" HCOLON ( "queued" / "ready" ) 1221 The value "queued" indicates that a subscriber's entry in the call- 1222 completion queue is not selected for CC recall. The value "ready" 1223 indicates that a user's entry in the call-completion queue has been 1224 selected for CC recall. 1226 10.2. Call-completion service-retention indication 1228 The service-retention line indicates the support of the retain 1229 option. The retain option, if supported at the callee, will maintain 1230 the entry in the CC queue, if a CC call has failed due to callee busy 1231 condition. If present, this parameter indicates that the retain 1232 option is supported, otherwise it is not supported. This parameter 1233 MAY be present in NOTIFY requests. 1235 cc-service-retention = "cc-service-retention" HCOLON "true" 1237 10.3. Call-completion URI 1239 The cc-URI line provides a URI (possibly in the form of a name-addr) 1240 which the agent SHOULD use as the request-URI of the CC recall INVITE 1241 and the suspend/resume PUBLISH. It SHOULD be provided in all 1242 NOTIFYs. The URI SHOULD be globally routable and SHOULD uniquely 1243 identify the CCE in question. The syntax provides for generic-params 1244 in the value, but this document defines no such parameters. 1245 Parameters that are not understood by the subscriber MUST be retained 1246 with the URI. 1248 cc-URI = "cc-URI" HCOLON addr-spec 1250 11. Security considerations 1252 The use of the CC facility allows the caller's agent to determine 1253 some status information regarding the callee. The information is 1254 confined to a busy/not-busy indication, and in legitimate use, will 1255 be subscribed to stereotyped ways that limit the disclosure of status 1256 information: 1258 1. When a subscriber is selected for CC, a call should arrive 1259 promptly for the callee, or the subscription should be 1260 terminated. This expectation may be violated by a race condition 1261 between selection of the subscription for CC and the caller 1262 becoming unavailable, but it should be rare that a single 1263 subscription will exhibit the race condition more than once. 1265 2. Subscriptions should not remain suspended for longer than the 1266 expected duration of a call (a call by the caller to a third 1267 party). 1269 3. Subscriptions should be initiated only shortly after failed 1270 incoming calls. 1272 4. Most of the time, a callee should have no queued subscriptions. 1274 Violations of these expectations should be detected by the callee's 1275 monitor and reported as possible attempts at privacy violation. 1277 The CC facility may enhance the effectiveness of SPIT by the 1278 following technique: The caller makes calls to a group of callees. 1279 The caller then requests CC for the calls that do not connect to the 1280 callees. The CC calls resulting are probably more likely to reach 1281 the callees than original calls to a further group of targets. 1283 In order to prevent DoD attacks and manipulations of the call- 1284 completion queue by suspending other call-completion entries than the 1285 own, a mechanism to correlate the identity of the original caller and 1286 the generator of the SUBSCRIBE and PUBLISH request is needed. The 1287 RECOMMENDED mechanism to authenticate the identity of the originator 1288 of call-completion relevant requests is the SIP Identity mechanism 1289 [RFC4474] . Alternatively, CC agents and monitors within an 1290 administrative domain or federation of domains MAY use the mechanism 1291 described in [RFC3325] to authenticate their identity with a 1292 P-Asserted-Identity header field. 1294 12. IANA considerations 1296 12.1. SIP event package registration for call-completion 1298 This specification registers an event package, based on the 1299 registration procedures defined in [RFC6665]. The followings is the 1300 information required for such a registration: 1302 Package Name: call-completion 1304 Is this registration for a Template-Package: No. 1306 Published Document: RFC XXXX (Note for RFC Editor: Please fill in 1307 XXXX with the RFC number of this specification). 1309 Person and e-mail to contact for further information: Martin 1310 Huelsemann, martin.huelsemann@telekom.de 1312 12.2. MIME registration for application/call-completion 1314 MIME media type name: application 1316 MIME subtype name: call-completion 1318 Required parameters: none. 1320 Optional parameters: none. 1322 Encoding considerations: Consists of lines of UTF-8-encoded 1323 characters, ended with CR-LF 1325 Security considerations: There are no security considerations 1326 internal to the media type. Its typical usage involves the security 1327 considerations described in RFC XXXX 1329 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1330 specification). 1332 Interoperability considerations: See RFC XXXX (Note for RFC Editor: 1333 Please fill in XXXX with the RFC number of this specification). 1335 Published specification: RFC XXXX (Note for RFC Editor: Please fill 1336 in XXXX with the RFC number of this specification) 1338 Applications that use this media type: the implementations of the 1339 call-completion features of the Session Initiation Protocol 1341 Additional information: 1343 Magic number(s): none 1345 File extension(s): not expected to be stored in files 1347 Macintosh file type code(s): not expected to be stored in files 1349 Person & email address to contact for further information: Martin 1350 Huelsemann, martin.huelsemann@telekom.de 1352 Intended usage: LIMITED USE 1354 Restrictions on usage: none 1356 Author/Change controller: the IETF 1358 12.3. SIP/SIPS URI parameter 'm' 1360 This specification defines one new SIP/SIPS URI parameter 'm' as per 1361 the registry created by [RFC3969]. It is used to identify that an 1362 INVITE request is a CC call, or to further identify that a SUBSCRIBE 1363 request is for the call-completion event package. The parameter may 1364 have a value that describes the type of the call-completion 1365 operation, as described in this specification. 1367 Name of the Parameter: m 1369 Predefined Values : yes 1371 RFC Reference : [RFC XXXX] 1373 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1374 specification) 1376 12.4. Call-Completion purpose parameter value 1378 This specification adds a new predefined value "call-completion" for 1379 the "purpose" header field parameter of the Call-Info header field. 1380 This modifies the registry header field parameters and parameter 1381 values by adding this RFC as a reference to the line for header field 1382 "Call-Info" and parameter name "purpose": 1384 Header Field: Call-Info 1386 Parameter Name: purpose 1388 Predefined Values: yes 1390 Reference: [RFC3261].[RFC5367][[RFC XXXX]] 1392 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1393 specification) 1395 12.5. 'm' header parameter for Call-Info 1397 This specification extends [RFC3261] to add a new header field 1398 parameter 'm' to the Call-Info header field. This adds a row to the 1399 registry header field parameters and parameter values: 1401 Header Field: Call-Info 1403 Parameter Name: m 1405 Predefined Values: yes 1407 Reference: [RFC XXXX] 1409 This RFC predefines the values 'BS', 'NR' and 'NL' . 1411 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1412 specification) 1414 13. Acknowledgements 1416 Thanks to Paul Kyzivat, John Elwell, Keith Drage, Andrew Hutton, 1417 Thomas Stach, Dennis Luebbers and Christer Holmberg who provided 1418 helpful comments, feedback and suggestions. 1420 14. References 1421 14.1. Normative References 1423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1424 Requirement Levels", BCP 14, RFC 2119, March 1997. 1426 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1427 A., Peterson, J., Sparks, R., Handley, M., and E. 1428 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1429 June 2002. 1431 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1432 Method", RFC 3515, April 2003. 1434 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 1435 W., and J. Peterson, "Presence Information Data Format 1436 (PIDF)", RFC 3863, August 2004. 1438 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1439 for Event State Publication", RFC 3903, October 2004. 1441 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1442 (IANA) Uniform Resource Identifier (URI) Parameter 1443 Registry for the Session Initiation Protocol (SIP)", 1444 BCP 99, RFC 3969, December 2004. 1446 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1447 Initiated Dialog Event Package for the Session Initiation 1448 Protocol (SIP)", RFC 4235, November 2005. 1450 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1451 Authenticated Identity Management in the Session 1452 Initiation Protocol (SIP)", RFC 4474, August 2006. 1454 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1455 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1457 [RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to 1458 Request-Contained Resource Lists in the Session Initiation 1459 Protocol (SIP)", RFC 5367, October 2008. 1461 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1462 July 2012. 1464 14.2. Informative References 1466 [ETS300.356-18] 1467 "Completion of Calls to Busy Subscriber (CCBS) 1468 supplementary service", February 1995. 1470 [ETS300.359-1] 1471 "Completion of Calls to Busy Subscriber (CCBS) 1472 supplementary service; Digital Subscriber Signalling 1473 System No. one (DSS1) protocol", November 1995. 1475 [ITU-T.Q.733] 1476 "DESCRIPTION FOR CALL COMPLETION SUPPLEMENTARY SERVICES 1477 USING SS No. 7", February 1995. 1479 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1480 Extensions to the Session Initiation Protocol (SIP) for 1481 Asserted Identity within Trusted Networks", RFC 3325, 1482 November 2002. 1484 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 1485 K. Summers, "Session Initiation Protocol Service 1486 Examples", BCP 144, RFC 5359, October 2008. 1488 Appendix A. Example Caller's Agent 1490 This section outlines how an autonomous caller's agent can operate 1491 using only standard SIP features to interact with the caller's UA. 1492 This example is suitable only as a learning aid, as its performance 1493 is poor. 1495 The agent monitors calls made from the UA(s) by subscribing to the 1496 dialog event package of the UA(s). 1498 The UA(s) or their proxy routes calls made with either of two special 1499 dial sequences to the agent, which interprets the INVITEs as 1500 indications to make a CC request with BS or NR or NL mode for the 1501 latest call made by the UA. 1503 The agent monitors the status of the UA(s) for availability to be 1504 used for a CC call by examining the dialog events. 1506 The agent indicates to the UA(s) that CC recall is in progress by 1507 making call to the UA(s). If the UA is answered, the agent assumes 1508 that the caller is available and plays pre-recorded audio to indicate 1509 that CC recall is in progress. 1511 After playing the pre-recorded audio, the caller's agent uses REFER 1512 to order the UA to make the CC call to the callee. 1514 Appendix B. Example Callee's Monitor 1516 This section outlines how an autonomous callee's monitor can operate 1517 using only standard SIP features to interact with the callee's UA. 1518 This example is suitable only as a learning aid, as its performance 1519 is poor. 1521 The callee's monitor monitors calls made to the UA(s) by subscribing 1522 to the UA(s) dialog events. This enables it to determine their Call- 1523 Id's and their final response statuses. 1525 The proxy for the UA(s) routes to the callee's monitor any SUBSCRIBEs 1526 for the call-completion event package directed to the URIs serviced 1527 by the UA(s). 1529 The callee's monitor monitors the status of the UA(s) to determine 1530 when they are in a suitable state to receive a CC call by watching 1531 the busy/not-busy status of the UA(s): e.g. a UA is available for 1532 CCBS when it is not busy, but a UA is available for CCNR when it 1533 becomes not busy after being busy with an established call. 1535 Authors' Addresses 1537 Dale R. Worley 1538 Ariadne Internet Services, Inc. 1539 738 Main St. 1540 Waltham, MA, 02451 1541 US 1543 Phone: +1 781 647 9199 1544 Email: worley@ariadne.com 1545 URI: http:// 1547 Martin Huelsemann 1548 Deutsche Telekom 1549 Heinrich-Hertz-Strasse 3-7 1550 Darmstadt, 64307 1551 Germany 1553 Phone: +4961515812765 1554 Email: martin.huelsemann@telekom.de 1555 URI: http://www.telekom.de 1556 Roland Jesske 1557 Deutsche Telekom 1558 Heinrich-Hertz-Strasse 3-7 1559 Darmstadt, 64307 1560 Germany 1562 Phone: +4961515812766 1563 Email: r.jesske@telekom.de 1564 URI: http://www.telekom.de 1566 Denis Alexeitsev 1567 TeleFLASH 1568 Mainzer Landstrasse 47 1569 Frankfurt 60329 1570 Germany 1572 Phone: +49-69-257-378-230 1573 Email: alexeitsev@teleflash.com 1574 URI: http://www.teleflash.com