idnits 2.17.1 draft-ietf-bliss-call-completion-17.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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 27, 2012) is 4158 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 1439, 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: May 31, 2013 R. Jesske 6 Deutsche Telekom 7 D. Alexeitsev 8 TeleFLASH 9 November 27, 2012 11 Call Completion for Session Initiation Protocol (SIP) 12 draft-ietf-bliss-call-completion-17 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 May 31, 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 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 2. Requirements terminology . . . . . . . . . . . . . . . . . . . 5 84 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 4.1. Call-completion architecture . . . . . . . . . . . . . . . 7 87 4.2. Call-completion procedures . . . . . . . . . . . . . . . . 9 88 4.3. Automatic redial as a fallback . . . . . . . . . . . . . . 11 89 4.4. Differences from SS7 . . . . . . . . . . . . . . . . . . . 12 90 5. Call-completion queue model . . . . . . . . . . . . . . . . . 12 91 6. Caller's agent behavior . . . . . . . . . . . . . . . . . . . 14 92 6.1. Receiving the CC possible indication . . . . . . . . . . . 14 93 6.2. Subscribing to CC . . . . . . . . . . . . . . . . . . . . 14 94 6.3. Receiving a CC recall notification . . . . . . . . . . . . 15 95 6.4. Initiating a CC call . . . . . . . . . . . . . . . . . . . 15 96 6.5. Suspending CC . . . . . . . . . . . . . . . . . . . . . . 15 97 6.6. Resuming CC . . . . . . . . . . . . . . . . . . . . . . . 16 98 7. Callee's monitor behavior . . . . . . . . . . . . . . . . . . 16 99 7.1. Sending the CC possible indication . . . . . . . . . . . . 16 100 7.2. Receiving a CC subscription . . . . . . . . . . . . . . . 17 101 7.3. Sending a CC notification . . . . . . . . . . . . . . . . 17 102 7.4. Receiving a CC call . . . . . . . . . . . . . . . . . . . 18 103 7.5. Receiving a CC suspension . . . . . . . . . . . . . . . . 19 104 7.6. Receiving a CC resumption . . . . . . . . . . . . . . . . 19 105 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 9. Call-completion event package . . . . . . . . . . . . . . . . 25 107 9.1. Event package name . . . . . . . . . . . . . . . . . . . . 25 108 9.2. Event package parameters . . . . . . . . . . . . . . . . . 25 109 9.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 25 110 9.4. Subscribe duration . . . . . . . . . . . . . . . . . . . . 26 111 9.5. NOTIFY bodies . . . . . . . . . . . . . . . . . . . . . . 26 112 9.6. Subscriber generation of SUBSCRIBE requests . . . . . . . 27 113 9.7. Notifier processing of SUBSCRIBE requests . . . . . . . . 27 114 9.8. Notifier generation of NOTIFY requests . . . . . . . . . . 27 115 9.9. Subscriber processing of NOTIFY requests . . . . . . . . . 28 116 9.10. Handling of forked requests . . . . . . . . . . . . . . . 28 117 9.11. Rate of notifications . . . . . . . . . . . . . . . . . . 28 118 9.12. State agents . . . . . . . . . . . . . . . . . . . . . . . 29 119 10. Call-completion information format . . . . . . . . . . . . . . 29 120 10.1. Call-completion status . . . . . . . . . . . . . . . . . . 29 121 10.2. Call-completion service-retention indication . . . . . . . 29 122 10.3. Call-completion URI . . . . . . . . . . . . . . . . . . . 30 123 11. Security considerations . . . . . . . . . . . . . . . . . . . 30 124 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 31 125 12.1. SIP event package registration for call-completion . . . . 31 126 12.2. MIME registration for application/call-completion . . . . 31 127 12.3. SIP/SIPS URI parameter 'm' . . . . . . . . . . . . . . . . 32 128 12.4. Call-Completion purpose parameter value . . . . . . . . . 33 129 12.5. 'm' header parameter for Call-Info . . . . . . . . . . . . 33 130 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 131 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 132 14.1. Normative References . . . . . . . . . . . . . . . . . . . 34 133 14.2. Informative References . . . . . . . . . . . . . . . . . . 35 134 Appendix A. Example Caller's Agent . . . . . . . . . . . . . . . 35 135 Appendix B. Example Callee's Monitor . . . . . . . . . . . . . . 36 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 138 1. Introduction 140 The call completion (CC) feature allows the caller of a failed call 141 to have the call completed without having to make a new call attempt 142 while guessing when the callee becomes available. When the caller 143 requests the use of the CC feature, the callee will be monitored for 144 its availability. When the callee becomes available the callee will 145 be given a certain timeframe for initiating a call. If the callee 146 does not initiate a new call within this timeframe, then the caller 147 will be recalled. When the caller accepts the CC recall then a CC 148 call to the callee will automatically start. If several callers have 149 requested the CC feature on the same callee, they will be recalled in 150 a predefined order, which is usually the order in which they have 151 requested the CC feature. 153 This draft defines the following CC features: 155 Call Completion on Busy Subscriber (CCBS): The callee is busy. The 156 caller is recalled after the callee is not busy any longer. 158 Call Completion on No Reply (CCNR): The callee does not answer the 159 call. The caller is recalled after the callee has completed a new 160 call. 162 Call Completion on Not Logged-in (CCNL): The callee is not 163 registered. The caller is recalled after the callee has registered 164 again. 166 2. Requirements terminology 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 This document uses terms from [RFC3261]. 174 3. Terminology 176 For the purpose of this service, we provide the following 177 terminology: 179 Callee: a destination of the original call, and a target of the CC 180 call. 182 Caller: The initiator of the original call and the CC request. The 183 user on whose behalf the CC call is made. 185 Callee's monitor: a logical component which implements the call- 186 completion queue for destination user(s)/UA(s), and performs the 187 associated tasks, including sending CC recall events, analogous to 188 the destination local exchange's role in SS7 CC. 190 Caller's agent: a logical component which makes CC requests and 191 responds to CC recall events on behalf of originating user(s)/UA(s), 192 analogous to the originating local exchange's role in SS7 CC. 194 CC, or call completion: a service which allows a caller who failed to 195 reach a desired callee to be notified when the callee becomes 196 available to receive a call. 198 CC activation: the indication by the caller to the caller's agent 199 that the caller desires CC for a failed original call; this implies 200 an indication transmitted from the caller's agent to the callee's 201 monitor of the desire for CC processing. 203 CCBS, or Call Completion on Busy Subscriber: a CC service when the 204 initial failure was that the destination UA was busy. 206 CCNR, or Call Completion on No Reply: a CC service when the initial 207 failure was that the destination UA did not answer. 209 CCNL, or Call Completion on Not Logged-in: a CC service when the 210 initial failure was that the destination UA was not registered. 212 CC call: a call from the caller to the callee, triggered by the CC 213 service when it has determined that the callee is available. 215 CC indicator: an indication in the CC call INVITE used to prioritize 216 the call at the destination. 218 CC possible indication: the data in responses to the INVITE of the 219 original call which indicate that CC is available for the call. 221 CC recall: the action of the callee's monitor selecting a particular 222 CC request for initiation of a CC call, resulting in an indication 223 from the caller's agent to the caller that it is now possible to 224 initiate a CC call. 226 CC recall events: event notifications of event package "call- 227 completion", sent by the callee's monitor to the caller's agent to 228 inform it of the status of its CC request. 230 CC recall timer: maximum time the callee's monitor will wait for the 231 caller's response to a CC recall. 233 CC request: the entry in the callee's monitor queue representing the 234 caller's request for CC processing, that is, the caller's call- 235 completion subscription. 237 CC service duration timer: maximum time a CC request may remain 238 active within the network. 240 CC queue: a buffer at the callee's monitor which stores incoming 241 calls which are target for call completion. Note: This buffer may or 242 may not be organized as a queue. The use of the term "queue" is by 243 analogy with SS7 usage. 245 CCE: or call-completion entity: the representation of a CC request, 246 or equivalently, an existing call-completion subscription within a 247 callee's monitor's queue 249 Failed call: a call which does not reach a desired callee, from the 250 caller's point of view. Note that a failed call may be successful 251 from the SIP point of view; e.g., if the call reached the callee's 252 voicemail, but the caller desired to speak to the callee in person, 253 the INVITE receives a 200 response, but the caller considers the call 254 to have failed. 256 Original call: the initial call which failed to reach a desired 257 destination. 259 Retain option: a characteristic of the CC service; if supported, CC 260 calls which again encounter a busy callee will not be queued again, 261 but the position of the caller's entry in the queue is retained. 262 Note that SIP CC always operates with the retain option active; a 263 failed CC call does not cause the CC request to lose its position in 264 the queue. 266 Suspended CC request: a CC request which is temporarily not to be 267 selected for CC recall. 269 4. Solution 271 4.1. Call-completion architecture 273 The call-completion architecture augments each caller's UA (or UAC) 274 wishing to use the call-completion features with a "call-completion 275 agent" (also written as "caller's agent"). 277 It augments each callee's UA (or UAS) wishing to be the target of the 278 call-completion features with a "call-completion monitor" (also 279 written as "callee's monitor"). 281 The caller's agent and callee's monitor functions can be integrated 282 into the respective UAs, be independent end-systems, or be provided 283 by centralized application servers. The two functions, though 284 associated with the two UAs (caller and callee), also may be provided 285 as services by the endpoints' home proxies or by other network 286 elements. Though it is expected that a UA that implements call 287 completion will have both functions so that it can participate in 288 call completion as both caller and callee, the two functions are 289 independent of each other. 291 A caller's agent may service more than one UA as a collective group 292 if a caller or population of users will be shared between the UAs, 293 and especially if the UAs share an AOR. 295 The caller's agent monitors calls made from the caller's UA(s) in 296 order to determine their destinations and (potentially) their final 297 response statuses, and the Call-Info header fields of provisional and 298 final responses for to invoke the call completion feature. 300 A callee's monitor may service more than one UA as a collective group 301 if a callee or population of users will be shared between the UAs, 302 and especially if the UAs share an AOR. The callee's monitor may 303 supply the callee's UAS(s) with Call-Info header field values for 304 provisional and final responses. 306 The callee's monitor also instantiates a presence server used to 307 monitor caller's availability for CC recall. 309 The callees using the UA(s) may be able to indicate to the callee's 310 monitor when they wish to receive CC calls. 312 In order to allow flexibility and innovation, most of the interaction 313 between the caller's agent, the caller-user(s) and the caller's UA(s) 314 is out of the scope of this document. Similarly, most of the 315 interaction between the callee's monitor, the callee(s) and the 316 callee's UA(s) is out of the scope of this document, as is also the 317 policy by which the callee's monitor arbitrates between multiple 318 call-completion requests. 320 The caller's agent must be capable of performing a number of 321 functions relative to the UA(s). The method by which it does so is 322 outside the scope of this document, but an example method is 323 described in Appendix A. The callee's monitor must be capable of 324 performing a number of functions relative to the UA(s). The method 325 by which it does so is outside the scope of this document, but an 326 example method is described in Appendix B. 328 As a proof of concept, simple caller's agents and callee's monitors 329 can be devised that interact with users and UAs entirely through 330 standard SIP mechanisms [RFC6665], [RFC4235] and [RFC3515], as 331 described in the Appendixes. 333 The callers using the UA(s) can indicate to the caller's agent when 334 they wish to avail themselves of CC for a recently-made call which 335 the callers determined to unsuccessful. The caller's agent monitors 336 the status of the caller's UA(s) to determine when they are available 337 to be used for a CC recall. The caller's agent can communicate to 338 the caller's UA(s) that a CC recall is in progress and to inquire if 339 the relevant caller is available for the CC recall. 341 The callee's monitor may utilize several methods to monitor the 342 status of the callee's UA(s) and/or their users for availability to 343 receive a CC call. This can be achieved through monitoring calls 344 made to the callee's UA(s) to determine their caller's and their 345 final response' statuses. And in a system with rich presence 346 information, the presence information may directly provide this 347 status. In a more restricted system, this determination can depend 348 on the mode of the CC call in question, which is provided by the 'm' 349 parameter. E.g., a UA is considered available for CCBS ("m=BS") when 350 it is not busy, but a UA is considered available for CCNR ("m=NR") 351 when it becomes not busy after being busy with an established call. 353 The callee's monitor maintains information about the set of INVITEs 354 received by the callee's UA(s) considered unsuccessful by the caller. 355 In practice, the callee's monitor may remove knowledge about an 356 incoming dialog from its set if local policy at the callee's monitor 357 establishes that the dialog is no longer eligible for CC activations. 359 4.2. Call-completion procedures 361 The caller's UA sends an INVITE to a request URI. One or more forks 362 of this request reach one or more of the callee's UAs. If the call- 363 completion feature is available, the callee's monitor (note there can 364 be a monitor for each of the callee's UAs) inserts a Call-Info header 365 field with its URI and with "purpose=call-completion" in appropriate 366 non-100 provisional or final response to the initial INVITE and 367 forwards them to the caller. The provisional response SHOULD be sent 368 reliably, if the INVITE contained a Supported header field with the 369 option tag 100rel. On receipt of a non-100 provisional or a final 370 response with the indication that the call-completion feature is 371 available, the calling user can invoke the CC feature. 373 The caller indicates to the caller's agent that he wishes to invoke 374 call-completion services on the recent call. Note that from the SIP 375 point of view, the INVITE may have been successful, but from the 376 user's point of view, the call may have been unsuccessful. E.g., the 377 call may have connected to the callee's voicemail, which would return 378 a 200 status to the INVITE but from the caller's point of view is "no 379 reply". 381 In order to receive information necessary for the caller to complete 382 the call at the callee, the caller's agent subscribes to the call- 383 completion event package at the callee's monitor. 385 The possibility of the caller to complete the call at the callee is 386 also known as the call-completion state (cc-state) of the caller. 387 The cc-states comprehend the values 'queued' and 'ready' (for call- 388 completion). 390 In order to receive information from all destinations where the 391 callee will be reachable, the caller's agent sends a SUBSCRIBE 392 request for the call-completion event package to the original 393 destination URI of the call and to all known callee's monitor URIs 394 (which are provided by Call-Info header fields in provisional and 395 final responses to the INVITE). The callee's monitor uses the 396 subscription as an indication that caller is interested in using the 397 CC feature with regard to the specified callee. The callee's monitor 398 keeps a list or queue of the caller's agent's subscriptions, 399 representing the requests from the caller's agent to the callee's 400 monitors for call-completion services. These subscriptions are 401 created, refreshed, and terminated according to the procedures of 402 [RFC6665]. 404 Upon receiving a SUBSCRIBE request from the caller's agent, the 405 callee's monitor instantiates a presence state for the caller's UA 406 which can be modified by the caller's UA to indicate its availability 407 for CC call. The status at the presence upon instantiation is 408 "open". 410 When the callee's monitor determines the callee and/or callee's UA 411 available for a CC call, it selects a caller to execute the CC call 412 and sends a call-completion event update (''cc-state: ready'') via a 413 NOTIFY request to the selected caller's agent's subscription, telling 414 it to begin the CC call to the callee's UA. 416 When the caller's agent receives this update, it initiates a CC 417 recall by calling the caller's UA, and then starts the CC call to the 418 callee's UA, using 3rd party call control procedures in accordance 419 with [RFC3725]. The caller's agent can also check by other means 420 whether the caller is available to initiate the CC call to the 421 callee's UA. If the caller is available, the caller's agent directs 422 the caller's UA to initiate the CC call to the callee's UA. 424 The caller's agent marks the CC call as such by adding a specific SIP 425 URI parameter to the Request-URI, so it can be given precedence by 426 the callee's monitor in reaching the callee's UA. 428 If the caller is not available on the receipt of the "ready for 429 recall" notification, the caller's agent suspends the CC request at 430 the callee's monitor by sending a PUBLISH request containing presence 431 information to the callee's monitor's presence server, informing 432 about the presence status 'closed'. Once the caller becomes 433 available for a CC call again, the caller's agent resumes the CC 434 request by sending another PUBLISH request to the callee's monitor, 435 informing about the presence status 'open'. 437 On the receipt of the suspension request, the callee's monitor 438 performs the monitoring for the next non-suspended CC request in the 439 queue. On the receipt of the resume from the previously suspended 440 caller's agent that was at the top of the queue, the callee's monitor 441 performs the callee monitoring for this caller's agent. 443 When the call completion call fails there are two possible options: 444 the CC feature has to be activated again by caller's agent 445 subscribing to callee's monitor, or CC remains activated and the 446 original CC request retains its position in the queue if retain 447 option is supported. 449 4.3. Automatic redial as a fallback 451 Automatic redial is a simple end-to-end design. An automatic redial 452 scenario is described in [RFC5359], section 2.17. This solution is 453 based on the usage of the dialog event package. When the callee is 454 busy when the call arrives, the caller subscribes to the callee's 455 call state. The callee's UA sends a notification when the callee's 456 call state changes. This means the caller is also notified when the 457 callee's call state changes to 'terminated'. The caller is alerted, 458 then the caller's UA starts a call establishment to the callee again. 459 If several callers have subscribed to a busy callee's call state, 460 they will be notified at the same time that the call state has 461 changed to 'terminated'. The problem of this solution is, that it 462 might happen that several recalls are started at the same time. This 463 means it is a heuristic approach with no guarantee of success. 465 There is no interaction between call completion and automatic redial, 466 as there is a difference in the behavior of the callee's monitor and 467 the caller when using the dialog event package for receiving dialog 468 information or for aggregating a call completion state. 470 4.4. Differences from SS7 472 SIP call completion differs in some ways from the CCBS and CCNR 473 features of SS7 (which is used in the PSTN). For ease of 474 understanding, we enumerate some of the differences here. 476 Due to the complex forking situations that are possible in SIP, a 477 call may "fail" from the point of view of the user and yet have a 478 "success" response from SIP's point of view. (This can happen even 479 in simple situations: e.g., a call to a busy user that fails over to 480 his voicemail receives a SIP success response, even though the caller 481 may consider it "busy subscriber".) Thus, the caller must be able to 482 invoke call completion even when the original call appeared to 483 succeed. To support this, the caller's agent must record successful 484 calls as well as unsuccessful calls. 486 In SIP, only the caller's UA or service system on the originating 487 side and the callee's UA or service system on the terminating side 488 need to support call completion for call completion to work 489 successfully between the UAs. Intermediate SIP systems (proxies or 490 B2BUAs) do not need to implement call completion; they only need to 491 be transparent to the usual range of SIP messages. 493 Due to flexibility needed to support legacy systems that are not 494 optimized to support call completion, there are a larger number of 495 situations in SIP where call completion services are offered but 496 cannot be successfully executed. 498 5. Call-completion queue model 500 The callee's monitor manages CC for a single URI. This URI is likely 501 to be a published AOR, or more likely "non-voicemail AOR", but it may 502 be as narrowly scoped as a single UA's contact URI. The callee's 503 monitor manages a dynamic set of call-completion entities (called 504 "CCEs") which represent CC requests, or equivalently, the existing 505 incoming call-completion subscriptions. This set is also called a 506 queue, because a queue data structure often aids in implementing the 507 callee's monitor's policies for selecting CCEs for CC recall. 509 Each CCE has an availability state, determined through caller's 510 presence status at the callee's monitor. A presence status of 511 ''open'' represents CCE's availability state of 'available' and a 512 presence status of "closed" represents CCE's availability state of 513 'unavailable'. 515 Each CCE has a recall state which is visible via subscriptions. The 516 recall state is either "queued" or "ready". 518 Each CCE carries the From URI of the SUBSCRIBE request that caused 519 its creation. 521 CC subscriptions arrive at the callee's monitor by addressing the 522 URIs the callee's monitor returns in Call-Info header fields. The 523 request URI of the SUBSCRIBE request determines the queue to which 524 the resulting CCE is added. The resulting subscription reports the 525 status of the queue. The base event data is the status of all the 526 CCEs in the queue, but the data returned by each subscription is 527 filtered to report only the status of that subscription's CCE. 528 (Further standardization may define means for obtaining more 529 comprehensive information about a queue.) 531 When a CCE is created, it is given the availability state "available" 532 and recall state "queued". 534 When the callee's monitor receives PIDF bodies [RFC3863] via PUBLISH 535 requests [ [RFC3903]], these PUBLISH requests are expected to be sent 536 by subscribers to indirectly suspend and resume their CC requests by 537 modifying its CCE availability state. A CCE is identified by the 538 request-URI (if it was taken from a call-completion event 539 notification which identifies the CCE) or the From URI of the request 540 (matching the From URI recorded in the CCE). Receipt of a PUBLISH 541 with 'status' of 'open' sets the availability state of the CCE to 542 'available' (resume); 'status' of 'closed' sets the availability 543 state of the CCE to 'not-available' (suspend). 545 The callee's monitor MUST select for recall only CC requests with a 546 CCE's availability state 'available', and for which the callee 547 appears to be available when considering the 'm' value of the CCE. 548 Within that constraint, the callee's monitor's selections are 549 determined by its local policy. Often, a callee's monitor will 550 choose the acceptable CCE that has been in the queue the longest. 551 When the callee's monitor has selected a CCE for recall, it changes 552 the CCE's recall state from 'queued' to 'ready', which triggers a 553 notification on the CCE's subscription. 555 If a selected subscriber then suspends its request by sending a 556 PUBLISH with the presence status 'closed', the CCE becomes not- 557 available, and the callee's monitor changes the CCE's recall state to 558 'queued'. This may cause another CCE (e.g., that has been in the 559 queue for less time) to be selected for recall. 561 The caller's presence status at the callee's monitor is terminated 562 when the caller completes its CC call or when the caller's agent's 563 subscription at the callee's monitor is terminated. 565 6. Caller's agent behavior 567 6.1. Receiving the CC possible indication 569 The caller's agent MUST record the From URI and SHOULD record the 570 final request status that the caller's UA received along with the 571 contents of Call-Info header fields of provisional and final 572 responses. 574 Note that receiving a CC possible indication also depends on the 575 aggregation of final responses by proxies, in case of 4xx responses 576 some 4xx responses are more likely to be sent to the caller. 578 6.2. Subscribing to CC 580 For CC activation the caller's agent MUST send a SUBSCRIBE to all 581 known callee's monitor URIs. A callee's monitor URI may be provided 582 in the Call-Info header field in provisional and final responses to 583 the INVITE sent back by the callee's monitor(s). Additionally, the 584 caller's agent SHOULD include the original request-URI that it sent 585 the original INVITE to, in its set of callee's monitor URIs, when it 586 is unclear if the call has forked to additional callees whose 587 responses the caller has not seen. A SUBSCRIBE to the original 588 request-URI alone is used in cases where the caller's agent has not 589 received or does not remember any callee's monitor URI. The caller's 590 agent SHOULD add an 'm' parameter to these URIs in order to indicate 591 the desired call-completion proceeding at the callee's monitor. The 592 'm' parameter SHOULD have the value of the 'm' parameter received in 593 the Call-Info header field of the responses to the original INVITE. 595 To minimize redundant subscriptions, these SUBSCRIBEs SHOULD 596 presented as forks of the same transaction as defined by section 597 8.2.2.2 of [RFC3261], if the caller's agent is capable of doing so. 599 The SUBSCRIBE SHOULD have header fields to optimize its routing. In 600 particular, it SHOULD contain "Request-Disposition: parallel", and an 601 Accept-Contact header field to eliminate callee UAs that are not 602 acceptable to the caller. 604 The caller's agent MUST be prepared to receive multiple responses for 605 multiple forks of the SUBSCRIBE and to have multiple subscriptions 606 established. The caller's agent must also be prepared to have the 607 SUBSCRIBE fail, in which case, CC cannot be invoked for this original 608 call. 610 If the caller's agent no longer wants to initiate the CC call (e.g., 611 because the caller has deactivated CC), the caller's agent terminates 612 the subscription in accordance with [RFC6665] or suspends the 613 subscription(s) as specified in subclause 6.5. 615 6.3. Receiving a CC recall notification 617 When receiving a NOTIFY with the cc-state set to 'ready', the 618 caller's agent SHOULD suspend all other subscriptions to CC, by 619 following the step in section 6.5, in order to prevent any other CC 620 requests from this caller to receive CC recalls. The caller's agent 621 starts the CC recall to the caller by confirming that the caller 622 would be able to initiate a CC call, e.g. by calling the caller's 623 UA(s). 625 6.4. Initiating a CC call 627 If the caller is available for the CC call and willing to initiate 628 the CC call, the caller's agent causes the caller's UA to generate a 629 new INVITE towards the callee. The caller's UA MAY add a 'm' URI 630 parameter with the value of the 'm' parameter received in Call-Info 631 header in the response to original INVITE, in order to specify his 632 preferences in CC processing and to prioritize the CC call. The 633 INVITE SHOULD be addressed to the URI specified in the cc-URI of the 634 NOTIFY, or if not available it SHOULD use the URI in the Call-Info 635 header field of the response to the original INVITE, or if not 636 available it MAY use the request-URI of the original INVITE, if this 637 URI was recorded. Note that the latter choice may not provide ideal 638 routing, but in simple cases it is likely to reach the desired 639 callee/callee's monitor. 641 6.5. Suspending CC 643 If the caller is not available for the CC recall, the CC request 644 SHALL be suspended by the caller's agent until the caller becomes 645 available again, or if the conditions relevant to the caller's 646 agent's local policy for suspensions have changed. To suspend the CC 647 request, the caller's agent SHALL publish the caller's presence state 648 by sending a PUBLISH request to each callee's monitor where the 649 presence server for CC resides in accordance with the procedures 650 described in [RFC3903] , giving the PIDF state 'closed' for the 651 caller's identity as presentity. The PUBLISH request SHOULD contain 652 an Expires header field with a value that corresponds to the current 653 value of the remaining CC subscription duration. 655 Each PUBLISH SHOULD be sent to the CC URI as received in the NOTIFY, 656 or within the corresponding SUBSCRIBE dialog, or if that is not 657 possible, to the corresponding callee's monitor URI received in the 658 Call-Info header field of the NOTIFY, or if one is not available, the 659 Contact address of the subscription. 661 6.6. Resuming CC 663 When the caller is no longer busy, or if the conditions relevant to 664 the caller's agent's suspension policy have changed, then the CC 665 request SHALL be resumed by the caller's agent. To resume a CC 666 request, the caller's agent SHALL publish the Caller's presence state 667 by sending a PUBLISH request to each callee's monitor a PUBLISH 668 request in accordance with the procedures described in [RFC3903] , 669 informing about the PIDF state 'open' but otherwise be constructed as 670 same as the suspend PUBLISH request. These PUBLISH requests are sent 671 to presence server that are instantiated at a CC monitor. 673 In the case where the caller's agent has sent several CC suspension 674 requests to different callee's monitors and the caller becomes 675 available again, as determined by the caller's agent's local policy 676 about resumption the caller's agent MAY send a PUBLISH to resume a CC 677 request to each callee's monitor for which there is a suspended CC 678 request. Note that the caller's agent's policy about resumption may 679 prescribe a manual resumption and thus a suspended CC request should 680 not be automatically resumed. 682 7. Callee's monitor behavior 684 7.1. Sending the CC possible indication 686 The callee's monitor MUST record the From URI and MAY record the 687 final request status(es) returned by the callee's UA(s). 689 If the callee's monitor wants to enable the caller to make use of the 690 CC service, it MUST insert a Call-Info header field with 691 "purpose=call-completion" in the final response message (e.g. in a 692 486 to enable call-completion due to busy subscriber) and at least 693 one non-100 provisional response message (e.g. in a 180 due to no 694 response) to the initial INVITE when forwarding it to the caller. 695 The non-100 provisional response message SHOULD be sent reliably if 696 the INVITE contained a Supported header field with the option tag 697 100rel. The Call-Info header field values defined in this 698 specification positively indicates that CC is available for the 699 failed fork of the call. 701 The callee's monitor SHOULD insert a URI in the Call-Info header 702 field where the caller's agent should subscribe for call-completion. 703 Ideally, it is a globally-routable URI [RFC5627] for the callee's 704 monitor. In practice, it may be the callee's AOR, and the SUBSCRIBE 705 will be routed to the callee's monitor only because it specifies 706 "Event: call-completion". 708 In order to enable call-completion, the Call-Info header field MUST 709 be set up according to the following scheme: 711 Call-Info:monitor-URI;purpose=call-completion;m=XX 713 The 'm' parameter defines the "mode" of call completion. The "m=NR" 714 parameter indicates that it failed due to lack of response, the 715 "m=BS" parameter indicates that it failed due to busy subscriber, and 716 the "m=NL" parameter indicates that it failed due to non registered 717 subscriber (no devices are registered for the AoR contacted). The 718 'm' parameter is useful for PSTN interworking and assessing presence 719 information in the callee's monitor. It is possible that other 720 values will be defined in future. It is also allowed to omit the 'm' 721 parameter entirely. Implementations MUST accept CC operations in 722 which the 'm' parameter is missing or has an unknown value, and 723 execute them at its best in their environment (which is likely to be 724 a degraded service, especially when interoperating with SS7). 726 7.2. Receiving a CC subscription 728 The callee's monitor MUST be prepared to receive SUBSCRIBEs for the 729 call-completion event package directed to the URIs of UA(s) that it 730 is servicing and any URIs that the callee's monitor provides in Call- 731 Info header fields. The SUBSCRIBEs MUST be processed in accordance 732 with the procedures defined in [RFC6665]. 734 The callee's monitor(s) that receive the SUBSCRIBE establish 735 subscriptions. These subscriptions represent the caller's agent's 736 request for call-completion services. The callee's monitor may apply 737 restrictions as to which caller's agents may subscribe. 739 The continuation of the caller's agent's subscription indicates to 740 the callee's monitor that the caller's agent is prepared to initiate 741 the CC call if it is selected for the 'ready' state. If the callee's 742 monitor becomes aware of a subscription which cannot be selected for 743 a CC recall, it SHOULD terminate the subscription in accordance with 744 [RFC6665]. 746 7.3. Sending a CC notification 748 The call-completion event package returns various information to the 749 caller's agent, but the vital datum it contains is the cc-state of 750 the caller's agent's CC request in the CC queue, which in the 751 beginning is 'queued'. When the cc-state of the agent's request 752 changes, the callee's monitor MUST send a NOTIFY for a call- 753 completion event to the caller's agent. The notification SHOULD also 754 contain a URI which can be used for suspension requests. Ideally, it 755 is a globally-routable URI [RFC5627] for the callee's monitor. In 756 practice, it may be the callee's AOR, and the SUBSCRIBE will be 757 routed to the callee's monitor only because it specifies "Event: 758 call-completion". 760 The call-completion event package provides limited information about 761 the callee's monitor's policy. In particular, like in the PSTN, the 762 "'cc-service-retention" datum gives an indication of the "service 763 retention" attribute, which indicates whether the CC request can be 764 continued to a later time if the CC call fails due to the callee's 765 UA(s) being busy. If the callee's monitor supports the service- 766 retention option, the callee's monitor SHOULD include the cc-service- 767 retention parameter. 769 The callee's monitor has a policy regarding when and how it selects 770 CC requests for the recall. This policy may take into account the 771 type of the requests (e. g. CCNR vs. CCBS), the state of the 772 callee's UA(s), the order in which the CC requests arrived, the 773 length of time the CC requests have been active, and any previous 774 attempts of CC activations for the same original call. Usually the 775 callee's monitor will choose only one CC request for the recall at a 776 time, but if the callee's UA(s) can support multiple calls, it may 777 choose more than one. Usually the callee's monitor will choose the 778 oldest active request. 780 When the callee's monitor changes the state datum for the chosen 781 subscription from "queued" to "ready", the callee's monitor MUST send 782 a NOTIFY for the caller's agent's subscription with the cc-state set 783 to 'ready' (recall notification). The NOTIFY SHOULD also contain in 784 the cc-URI a URI to be used in the CC call. In practice, this may be 785 the AOR of the callee. 787 Upon sending the recall notification the callee's monitor MUST start 788 a recall timer. It is RECOMMENDED to use a value between 10 and 20 789 seconds, which corresponds to the recommendation for the call 790 completion services in ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733]. 792 7.4. Receiving a CC call 794 The callee's UA(s) and the callee's monitor may give the CC call 795 precedence over non-CC calls by evaluating the presence of the 'm' 796 URI parameter and the From header of the INVITE request. The 797 callee's monitor supervises the receiving of the CC call. Upon 798 arrival of the CC call the recall timer MUST be stopped. If the CC 799 call does not arrive at the callee's UA(s) before the expiry of the 800 recall timer, the callee's monitor SHOULD stop processing the recall 801 and change the value of the cc-state datum to "queued" if it supports 802 the retain option and terminate the subscription along with the queue 803 if it doesn't support the retain option. Similarly, if the CC call 804 is not accepted, the callee's monitor will stop the CC recall 805 processing. Depending on its policy, the same original call may be 806 selected again for a CC recall at a later time. If the CC call 807 succeeds, the callee's monitor MUST terminate the relevant 808 subscription in accordance with [RFC6665], and MUST remove any 809 associated presence event state used for suspend and resume for the 810 caller of the CC call. 812 Once the CC call has been terminated, successfully or unsuccessfully, 813 the callee's monitor's policy MAY select another CC request for a 814 recall according to the callee's monitor's policy. Note that 815 according to the callee's monitor's policy several recalls may be 816 processed at the same time. 818 7.5. Receiving a CC suspension 820 The monitor may receive PUBLISH requests to suspend CC requests from 821 caller's agent as described in section 6.5. The PUBLISH requests may 822 be received via the URI it manages, any URI that it inserts into a 823 Call-Info header, any contact URI it uses as a notifier for "call- 824 completion" events, or any URI it returns as the "URI" line of the 825 call-completion event packages. 827 The receipt of the PUBLISH request initiates a presence event state 828 for the caller's identity at the presence server functionality of the 829 callee's monitor as specified in [RFC3903] , together with a logical 830 presence server if this has not been done before for another call. 832 Note: The presence server may initiate a presence event state for the 833 caller's identity at the receipt of SUBSCRIBE request as well, 834 dependent on the implementation. 836 The monitor SHOULD identify the addressed CCE by the request-URI of 837 the PUBLISH request, or if that is not possible, by the From URI. 839 If the processing of a CC request results in suspending that CC 840 request by receiving a PUBLISH request from caller's agent as 841 described in section 6.5, the callee's monitor MUST stop the recall 842 timer and MUST ensure that the request is set to a 'queued' state, 843 and then the callee's monitor MUST attempt to process another CC 844 request in the queue according to the callee's monitor's local 845 policy. 847 7.6. Receiving a CC resumption 849 When a CC request becomes resumed by receiving a PUBLISH request from 850 caller's agent as described in section 6.6, the presence event state 851 for the caller's identity at the presence server functionality of the 852 CC monitor MUST be modified as described in [RFC3903]. If the callee 853 is not busy and there is no entry in the CC queue which is currently 854 being processed, the callee's monitor MUST process the queue as 855 described in section 7.3 above. 857 8. Examples 859 A basic call flow, with only the most significant messages of a call- 860 completion activation and invocation shown, is as follows (please 861 note this is an example and there may be variations in the failure 862 responses): 864 Caller Callee 865 sip:123@a.com sip:456@b.com 866 | | 867 | INVITE sip:456@b.com | [original call] 868 | From: sip:123@a.com | 869 |------------------------->| 870 | | 871 | 487 | 872 | Call-Info:;purpose=call-completion;m=NR 873 |<-------------------------| 874 | | 875 | SUBSCRIBE sip:456@z.b.com;m=NR [initial SUBSCRIBE] 876 | From: sip:123@a.com | 877 | Contact: sip:123@y.a.com | 878 | Request-Disposition: parallel 879 | Call-Id: abcd-efgh | 880 | Event: call-completion | 881 |------------------------->| 882 | | 883 | 200 | 884 |<-------------------------| 885 | | 886 | NOTIFY sip:123@y.a.com | [initial NOTIFY] 887 | Body: status: queued | 888 |<-------------------------| 889 | | 890 | SUBSCRIBE sip:456@b.com;m=NR [another init. SUB.] 891 | From: sip:foo@example.com| 892 | Request-Disposition: parallel 893 | Call-Id: abcd-efgh | 894 | Event: call-completion | 895 |------------------------->| 896 | | 897 | 482 | [duplicate SUB. rej.] 898 |<-------------------------| 899 | | 900 | NOTIFY sip:123@y.a.com | [CC invoked] 901 | Body: status: ready | 902 | URI: sip:recall@z.b.com 903 |<-------------------------| 904 | | 905 | INVITE sip:recall@z.b.com;m=NR [CC call] 906 | From: sip:foo@example.com| 907 |------------------------->| 908 | | 909 | NOTIFY sip:123@y.a.com | [CC terminated] 910 | Expires = 0 | 911 |<-------------------------| 913 The original call is an ordinary INVITE. It fails due to no-response 914 (ring-no-answer). In this case, the callee's governing proxy 915 generates a 487 response because the proxy canceled the INVITE to the 916 UA when it rang too long without an answer. The 487 response carries 917 a Call-Info header field with "purpose=call-completion". The Call- 918 Info header field positively indicates that CC is available for this 919 failed fork of the call. The "m=NR" parameter indicates that it 920 failed due to no-response, which is useful for PSTN interworking and 921 assessing presence information in the callee's monitor. 923 The URI in the Call-Info header field () is where 924 the caller's agent should subscribe for call-completion processing. 925 Ideally, it is a globally-routable URI for the callee's monitor. In 926 practice, it may be the callee's AOR, and the SUBSCRIBE will be 927 routed to the callee's monitor only because it specifies "Event: 928 call-completion". 930 CC is activated by sending a SUBSCRIBE to all known callee's monitor 931 URIs. These can be provided by the Call-Info header field in the 932 response to the INVITE. 934 Additionally, the caller's agent needs to include the original 935 request-URI in its set of callee's monitor URIs, because the call may 936 have forked to additional callees whose responses the caller has not 937 seen. (A SUBSCRIBE to the request-URI alone is used in cases where 938 the caller's agent has not received or cannot remember any callee's 939 monitor URI.) 941 The caller's agent adds to these URIs an 'm' parameter (if possible). 942 In this case, the caller's agent forks the SUBSCRIBE to two 943 destinations as defined by section 8.2.2.2 of [RFC3261], with 944 appropriate Request-Disposition. The first SUBSCRIBE is to the URI 945 from Call-Info. 947 The second SUBSCRIBE is to the original request-URI, and reaches the 948 same callee's monitor. Because it has the same Call-Id as the 949 SUBSCRIBE that has already reached the callee's monitor, the callee's 950 monitor rejects it with a 482, thus avoiding redundant subscriptions. 952 The initial NOTIFY for the successful SUBSCRIBE has "state: queued" 953 in its body. Eventually, this caller is selected for CC, and is 954 informed of this via a NOTIFY containing "state: ready". This NOTIFY 955 carries a URI to which the INVITE for CC call should be sent. In 956 practice, this may be the AOR of the callee. 958 The caller generates a new INVITE to the URI specified in the NOTIFY, 959 or if there was no such URI or if the caller's agent cannot remember 960 it, it may use the original request-URI. The caller adds the 'm' 961 parameters (if possible), to specify CC processing. 963 Finally the subscription for the CC request is terminated by the 964 callee's monitor. 966 Another flow, with only the most significant messages of call- 967 completion suspension and resumption shown, is as follows: 969 Caller Callee 970 sip:123@a.com sip:456@b.com 971 | | 972 | NOTIFY sip:123@y.a.com | [CC notification, caller not 973 | Body: status: ready | available for CC recall] 974 | URI: sip:recall@z.b.com 975 |<-------------------------| 976 | | 977 | 200 | 978 |------------------------->| 979 | | 980 | PUBLISH sip:456@z.b.com | [non-availibility for recall 981 | From: sip:123@a.com | is published] 982 | Contact: sip:123@y.a.com | 983 | Event: presence 984 | Content-Type: 'app/pidf' | 985 | Body: status=closed 986 |------------------------->| 987 | | 988 | 200 | 989 |<-------------------------| 990 | | 991 | | [caller becomes available 992 | | again] 993 | | 994 | PUBLISH sip:456@z.b.com | [availibility for recall 995 | From: sip:123@a.com | is published] 996 | Contact: sip:123@y.a.com | 997 | Event: presence 998 | Content-Type: 'app/pidf' | 999 | Body: status=open 1000 |------------------------->| 1001 | | 1002 | 200 | 1003 |<-------------------------| 1004 | | 1006 The caller is selected for CC, and is informed of this via a NOTIFY 1007 request containing "state: ready". At this time, the caller is not 1008 available for the CC recall. 1010 For updating his presence event state at the presence server 1011 functionality at the callee, the caller generates a PUBLISH request 1012 to the CC URI as received in the NOTIFY, or within the corresponding 1013 SUBSCRIBE dialog, or if that is not possible, to the corresponding 1014 callee's monitor URI received in the Call-Info header field of the 1015 NOTIFY, or if one is not available, the Contact address of the 1016 subscription, informing about the PIDF state 'closed' . 1018 When the caller is again available for the CC recall, he caller 1019 updates his presence event state at the presence server functionality 1020 at the callee by generating a PUBLISH request informing about the 1021 PIDF state 'open', but otherwise constructed as same as the suspend 1022 PUBLISH request. 1024 9. Call-completion event package 1026 This section specifies the call-completion event package, in 1027 accordance with section 4.4 of [RFC6665]. The call-completion event 1028 package has the media type "application/call-completion". 1030 Note that if the callee has a caller-queuing facility, the callee's 1031 monitor may want to treat the call-completion queue as part of the 1032 queuing facility, and include in the event package information 1033 regarding the state of the queue. How this information is conveyed 1034 is left for further standardization. 1036 9.1. Event package name 1038 The SIP Events specification requires package definitions to specify 1039 the name of their package or template-package. The name of this 1040 package is "call-completion". This value appears in the Event and 1041 Allow-events header fields. 1043 9.2. Event package parameters 1045 No package-specific Event header field parameters are defined for 1046 this event package. 1048 9.3. SUBSCRIBE bodies 1050 [RFC6665] requires package definitions to define the usage, if any, 1051 of bodies in SUBSCRIBE requests. 1053 The SUBSCRIBE request MAY contain an Accept header field. If no such 1054 header field is present, it has a default value of "application/ 1055 call-completion". If the header field is present, it MUST include 1056 "application/call-completion". 1058 A SUBSCRIBE request for a call-completion package MAY contain a body. 1059 This body defines a filter to be applied to the subscription. Filter 1060 documents are not specified in this document, and may be the subject 1061 of future standardization activity. 1063 A SUBSCRIBE request requests call-completion information regarding 1064 calls recently made from the same caller to the callee UA(s) serviced 1065 by the notifier. Calls are defined to be "from the same caller" if 1066 the URI-part of the From header field value in the INVITE is the same 1067 as the URI-part of the From header field value in the SUBSCRIBE. 1069 9.4. Subscribe duration 1071 [RFC6665] requires package definitions to define a default value for 1072 subscription durations, and to discuss reasonable choices for 1073 durations when they are explicitly specified. 1075 If a SUBSCRIBE does not explicitly request a duration, the default 1076 requested duration is 3600 seconds, as that is the highest service 1077 duration timer value recommended for the call completion services in 1078 ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733]. As because of the 1079 subscription duration no explicit timer is needed, and the 1080 subscription duration can be seen as an equivalent to the SS7 service 1081 duration timer, this specification refers to the subscription 1082 duration also as the service duration timer. It is RECOMMENDED that 1083 subscribers request, and that notifiers grant, a subscription time of 1084 at least 3600 seconds. 1086 If a notifier can determine that, according to its policy, after 1087 certain duration the requested subscription can not any more proceed 1088 to "ready" state, it SHOULD reduce the granted subscription time to 1089 that duration. If a notifier can determine that, according to its 1090 policy, the requested subscription can never proceed to "ready" 1091 state, it should refuse the subscription. 1093 9.5. NOTIFY bodies 1095 [RFC6665] requires package definitions to describe the allowed set of 1096 body types in NOTIFY requests, and to specify the default value to be 1097 used when there is no Accept header field in the SUBSCRIBE request. 1098 A NOTIFY for a call-completion package MUST contain a body that 1099 describes the call-completion states. 1101 As described in [RFC6665], the NOTIFY message will contain bodies 1102 that describe the state of the subscribed resource. This body is in 1103 a format listed in the Accept header field of the SUBSCRIBE, or in a 1104 package-specific default format if the Accept header field was 1105 omitted from the SUBSCRIBE. 1107 In this event package, the body of the notification contains a call- 1108 completion document. All subscribers and notifiers MUST support the 1109 "application/call-completion" data format described in section 10. 1110 The SUBSCRIBE request MAY contain an Accept header field. If no such 1111 header field is present, it has a default value of "application/ 1112 call-completion". If the header field is present, it MUST include 1113 "application/call-completion". Of course, the notifications 1114 generated by the server MUST be in one of the formats specified in 1115 the Accept header field in the SUBSCRIBE request. 1117 9.6. Subscriber generation of SUBSCRIBE requests 1119 Subscribers MUST generate SUBSCRIBE requests when they want to 1120 subscribe to the call-completion event package at the terminating 1121 side in order to receive call-completion notifications. The 1122 generation of SUBSCRIBE requests can imply the usage of a call- 1123 completion service specific timer as described in section 9.4. 1125 9.7. Notifier processing of SUBSCRIBE requests 1127 Upon receiving a subscription refresh, the notifier MUST set the 1128 "expires" parameter of the Subscription-State header field to a value 1129 not higher than the current remaining duration of the subscription 1130 regardless of the value received in the Expires header field (if 1131 present) of the subscription refresh. 1133 If a subscription is not successful because the call-completion queue 1134 has reached the maximum allowed number of entries (short term 1135 denial), the notifier MUST send a 480 Temporarily Unavailable 1136 response to the subscriber, possibly with a Retry-after header field 1137 in accordance with the notifier's policy. If a subscription is not 1138 successful because a condition has occurred that prevents and will 1139 continue to prevent the call-completion service (long term denial), 1140 the notifier MUST send a 403 Forbidden response to the subscriber. 1142 A notifier MAY receive multiple forks of the same SUBSCRIBE, as 1143 defined by section 8.2.2.2 of [RFC3261]. In such a case, the 1144 notifier MUST reject all but one of the SUBSCRIBEs with a 482 Merged 1145 Request response unless some other failure response applies. 1147 The call-completion information can be sensitive. Therefore, all 1148 subscriptions SHOULD be handled with consideration of the security 1149 considerations discussed in section 11, in particular for verifying 1150 the identity of the subscriber. 1152 9.8. Notifier generation of NOTIFY requests 1154 Notifiers MUST generate NOTIFY requests when the CC request's state 1155 changes to 'queued' or to 'ready (for call-completion)'. A NOTIFY 1156 that is sent with non-zero expiration MUST contain the "cc-state" 1157 parameter. The parameter's value MUST be "queued" if the call- 1158 completion request represented by the subscription is not at this 1159 time selected by the callee's monitor for CC recall, and the 1160 parameter's value MUST be "ready" if the request is at this time 1161 selected by the callee's monitor for CC recall. 1163 A NOTIFY sent with a zero expiration (e.g., as a confirmation of a 1164 request to unsubscribe) MAY contain the "cc-state" parameter. 1166 When the callee's monitor withdraws the selection of the request for 1167 the CC recall (e.g., because the caller's agent has not initiated the 1168 CC recall INVITE before the CC recall timer expires, or because the 1169 agent has suspended the request from being considered for CC recall), 1170 the notifier MUST send a NOTIFY to the subscription of the selected 1171 request. This NOTIFY MUST contain the "cc-state" parameter set to 1172 "queued". 1174 If the call-completion subscription was successful and the retain 1175 option is supported at the callee, the NOTIFY MUST contain the "cc- 1176 service-retention" parameter. 1178 9.9. Subscriber processing of NOTIFY requests 1180 When receiving a NOTIFY requests with the cc-state set to 'ready', 1181 subscribers SHOULD suspend all other CC subscriptions for the 1182 original call at other notifiers. The receipt of a NOTIFY request 1183 with the cc-state set to 'ready' by the subscriber will also cause an 1184 interaction with the instances at the subscribers side hat are 1185 responsible for starting the CC recall. 1187 9.10. Handling of forked requests 1189 Forked requests are expected to be common for the call-completion 1190 event type. The subscriber MUST be prepared to process NOTIFY 1191 requests from multiple notifiers and to coordinate its processing of 1192 the information obtained from them in accordance with the procedures 1193 in this document. 1195 9.11. Rate of notifications 1197 The call completion service typically involves a single notification 1198 per notifier and per subscription that notifies about the change to 1199 'ready (for call-completion)', but MAY involve several notifications 1200 about the change to the 'ready' state, separated by a call completion 1201 call that failed due to a busy callee . Typically, notifications 1202 will be separated by at least tens of seconds. Notifiers SHOULD NOT 1203 generate more than three notifications for one subscription in any 1204 ten-second interval. Since it is important to avoid useless recalls, 1205 a notifier SHOULD send state changes to "queued" from "ready" 1206 promptly. Thus, a notifier SHOULD NOT send a state change to "ready" 1207 as the third notification in a ten-second interval, as that would 1208 make it impossible to promptly send a further state change to 1209 "queued". 1211 9.12. State agents 1213 State agents have no defined role in the handling of the call- 1214 completion package. 1216 10. Call-completion information format 1218 The following syntax specification uses the Augmented Backus-Naur 1219 Form (ABNF) as described in [RFC5234]. The formal syntax for the 1220 application/call-completion MIME type is described below. In 1221 general, the call-completion body is to be interpreted in the same 1222 way as SIP headers: (1) the names of the lines are case-insensitive, 1223 (2) the lines can be continued over line boundaries if the succeeding 1224 lines start with horizontal white space, and (3) lines with unknown 1225 names are to be ignored. The header lines defined in this document 1226 can occur at most once in any given call-completion document. 1228 call-completion = 1*(cc-header CRLF) 1230 cc-header = cc-state / cc-service-retention / cc-URI / extension- 1231 header 1233 The above rules whose names start with "cc-" are described below. 1234 Other rules are described in [RFC3261]. 1236 10.1. Call-completion status 1238 The cc-state line indicates the CC status of a particular user with 1239 an entry in a CC queue. It MUST be present unless the expiration 1240 time indicated in the NOTIFY is zero. 1242 cc-state = "cc-state" HCOLON ( "queued" / "ready" ) 1244 The value "queued" indicates that a subscriber's entry in the call- 1245 completion queue is not selected for CC recall. The value "ready" 1246 indicates that a user's entry in the call-completion queue has been 1247 selected for CC recall. 1249 10.2. Call-completion service-retention indication 1251 The service-retention line indicates the support of the retain 1252 option. The retain option, if supported at the callee, will maintain 1253 the entry in the CC queue, if a CC call has failed due to callee busy 1254 condition. If present, this parameter indicates that the retain 1255 option is supported, otherwise it is not supported. This parameter 1256 MAY be present in NOTIFY requests. 1258 cc-service-retention = "cc-service-retention" HCOLON "true" 1260 10.3. Call-completion URI 1262 The cc-URI line provides a URI (possibly in the form of a name-addr) 1263 which the agent SHOULD use as the request-URI of the CC recall INVITE 1264 and the suspend/resume PUBLISH. It SHOULD be provided in all 1265 NOTIFYs. The URI SHOULD be globally routable and SHOULD uniquely 1266 identify the CCE in question. The syntax provides for generic-params 1267 in the value, but this document defines no such parameters. 1268 Parameters that are not understood by the subscriber MUST be retained 1269 with the URI. 1271 cc-URI = "cc-URI" HCOLON addr-spec 1273 11. Security considerations 1275 The use of the CC facility allows the caller's agent to determine 1276 some status information regarding the callee. The information is 1277 confined to a busy/not-busy indication, and in legitimate use, will 1278 be subscribed to stereotyped ways that limit the disclosure of status 1279 information: 1281 1. When a subscriber is selected for CC, a call should arrive 1282 promptly for the callee, or the subscription should be 1283 terminated. This expectation may be violated by a race condition 1284 between selection of the subscription for CC and the caller 1285 becoming unavailable, but it should be rare that a single 1286 subscription will exhibit the race condition more than once. 1288 2. Subscriptions should not remain suspended for longer than the 1289 expected duration of a call (a call by the caller to a third 1290 party). 1292 3. Subscriptions should be initiated only shortly after failed 1293 incoming calls. 1295 4. Most of the time, a callee should have no queued subscriptions. 1297 Violations of these expectations should be detected by the callee's 1298 monitor and reported as possible attempts at privacy violation. 1300 The CC facility may enhance the effectiveness of SPIT by the 1301 following technique: The caller makes calls to a group of callees. 1302 The caller then requests CC for the calls that do not connect to the 1303 callees. The CC calls resulting are probably more likely to reach 1304 the callees than original calls to a further group of targets. 1306 In order to prevent DoD attacks and manipulations of the call- 1307 completion queue by suspending other call-completion entries than the 1308 own, a mechanism to correlate the identity of the original caller and 1309 the generator of the SUBSCRIBE and PUBLISH request is needed. The 1310 RECOMMENDED mechanism to authenticate the identity of the originator 1311 of call-completion relevant requests is the SIP Identity mechanism 1312 [RFC4474] . Alternatively, CC agents and monitors within an 1313 administrative domain or federation of domains MAY use the mechanism 1314 described in [RFC3325] to authenticate their identity with a 1315 P-Asserted-Identity header field. 1317 Furthermore, the use of presence server functionality to suspend or 1318 resume SHOULD be limited to a caller which has an active queue in the 1319 callee's monitor. This can be achieved first by monitoring and 1320 logging incoming call to the callee and the destination where CC 1321 indication was sent, then to ensure subscription to the call 1322 completion package is permitted only within a short timeframe after 1323 the initial call failed and to only accept PUBLISH request to the 1324 presence server functionality if there is an active queue for the 1325 caller in question. 1327 12. IANA considerations 1329 12.1. SIP event package registration for call-completion 1331 This specification registers an event package, based on the 1332 registration procedures defined in [RFC6665]. The followings is the 1333 information required for such a registration: 1335 Package Name: call-completion 1337 Is this registration for a Template-Package: No. 1339 Published Document: RFC XXXX (Note for RFC Editor: Please fill in 1340 XXXX with the RFC number of this specification). 1342 Person and e-mail to contact for further information: Martin 1343 Huelsemann, martin.huelsemann@telekom.de 1345 12.2. MIME registration for application/call-completion 1347 MIME media type name: application 1349 MIME subtype name: call-completion 1350 Required parameters: none. 1352 Optional parameters: none. 1354 Encoding considerations: Consists of lines of UTF-8-encoded 1355 characters, ended with CR-LF 1357 Security considerations: There are no security considerations 1358 internal to the media type. Its typical usage involves the security 1359 considerations described in RFC XXXX 1361 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1362 specification). 1364 Interoperability considerations: See RFC XXXX (Note for RFC Editor: 1365 Please fill in XXXX with the RFC number of this specification). 1367 Published specification: RFC XXXX (Note for RFC Editor: Please fill 1368 in XXXX with the RFC number of this specification) 1370 Applications that use this media type: the implementations of the 1371 call-completion features of the Session Initiation Protocol 1373 Additional information: 1375 Magic number(s): none 1377 File extension(s): not expected to be stored in files 1379 Macintosh file type code(s): not expected to be stored in files 1381 Person & email address to contact for further information: Martin 1382 Huelsemann, martin.huelsemann@telekom.de 1384 Intended usage: LIMITED USE 1386 Restrictions on usage: none 1388 Author/Change controller: the IETF 1390 12.3. SIP/SIPS URI parameter 'm' 1392 This specification defines one new SIP/SIPS URI parameter 'm' as per 1393 the registry created by [RFC3969]. It is used to identify that an 1394 INVITE request is a CC call, or to further identify that a SUBSCRIBE 1395 request is for the call-completion event package. The parameter may 1396 have a value that describes the type of the call-completion 1397 operation, as described in this specification. 1399 Name of the Parameter: m 1401 Predefined Values : yes 1403 RFC Reference : [RFC XXXX] 1405 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1406 specification) 1408 12.4. Call-Completion purpose parameter value 1410 This specification adds a new predefined value "call-completion" for 1411 the "purpose" header field parameter of the Call-Info header field. 1412 This modifies the registry header field parameters and parameter 1413 values by adding this RFC as a reference to the line for header field 1414 "Call-Info" and parameter name "purpose": 1416 Header Field: Call-Info 1418 Parameter Name: purpose 1420 Predefined Values: yes 1422 Reference: [RFC3261].[RFC5367][[RFC XXXX]] 1424 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1425 specification) 1427 12.5. 'm' header parameter for Call-Info 1429 This specification extends [RFC3261] to add a new header field 1430 parameter 'm' to the Call-Info header field. This adds a row to the 1431 registry header field parameters and parameter values: 1433 Header Field: Call-Info 1435 Parameter Name: m 1437 Predefined Values: yes 1439 Reference: [RFC XXXX] 1441 This RFC predefines the values 'BS', 'NR' and 'NL' . 1443 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1444 specification) 1446 13. Acknowledgements 1448 Thanks to Paul Kyzivat, John Elwell, Keith Drage, Andrew Hutton, 1449 Thomas Stach, Dennis Luebbers and Christer Holmberg who provided 1450 helpful comments, feedback and suggestions. 1452 14. References 1454 14.1. Normative References 1456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1457 Requirement Levels", BCP 14, RFC 2119, March 1997. 1459 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1460 A., Peterson, J., Sparks, R., Handley, M., and E. 1461 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1462 June 2002. 1464 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1465 Method", RFC 3515, April 2003. 1467 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 1468 W., and J. Peterson, "Presence Information Data Format 1469 (PIDF)", RFC 3863, August 2004. 1471 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1472 for Event State Publication", RFC 3903, October 2004. 1474 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1475 (IANA) Uniform Resource Identifier (URI) Parameter 1476 Registry for the Session Initiation Protocol (SIP)", 1477 BCP 99, RFC 3969, December 2004. 1479 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1480 Initiated Dialog Event Package for the Session Initiation 1481 Protocol (SIP)", RFC 4235, November 2005. 1483 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1484 Authenticated Identity Management in the Session 1485 Initiation Protocol (SIP)", RFC 4474, August 2006. 1487 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1488 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1490 [RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to 1491 Request-Contained Resource Lists in the Session Initiation 1492 Protocol (SIP)", RFC 5367, October 2008. 1494 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1495 Agent URIs (GRUUs) in the Session Initiation Protocol 1496 (SIP)", RFC 5627, October 2009. 1498 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1499 July 2012. 1501 14.2. Informative References 1503 [ETS300.356-18] 1504 "Completion of Calls to Busy Subscriber (CCBS) 1505 supplementary service", February 1995. 1507 [ITU-T.Q.733] 1508 "DESCRIPTION FOR CALL COMPLETION SUPPLEMENTARY SERVICES 1509 USING SS No. 7", February 1995. 1511 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1512 Extensions to the Session Initiation Protocol (SIP) for 1513 Asserted Identity within Trusted Networks", RFC 3325, 1514 November 2002. 1516 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1517 Camarillo, "Best Current Practices for Third Party Call 1518 Control (3pcc) in the Session Initiation Protocol (SIP)", 1519 BCP 85, RFC 3725, April 2004. 1521 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 1522 K. Summers, "Session Initiation Protocol Service 1523 Examples", BCP 144, RFC 5359, October 2008. 1525 Appendix A. Example Caller's Agent 1527 This section outlines how an autonomous caller's agent can operate 1528 using only standard SIP features to interact with the caller's UA. 1529 This example is suitable only as a learning aid, as its performance 1530 is poor. 1532 The agent monitors calls made from the UA(s) by subscribing to the 1533 dialog event package of the UA(s). 1535 The UA(s) or their proxy routes calls made with either of two special 1536 dial sequences to the agent, which interprets the INVITEs as 1537 indications to make a CC request with BS or NR or NL mode for the 1538 latest call made by the UA. 1540 The agent monitors the status of the UA(s) for availability to be 1541 used for a CC call by examining the dialog events. 1543 The agent indicates to the UA(s) that CC recall is in progress by 1544 making call to the UA(s). If the UA is answered, the agent assumes 1545 that the caller is available and plays pre-recorded audio to indicate 1546 that CC recall is in progress. 1548 After playing the pre-recorded audio, the caller's agent uses REFER 1549 to order the UA to make the CC call to the callee. 1551 Appendix B. Example Callee's Monitor 1553 This section outlines how an autonomous callee's monitor can operate 1554 using only standard SIP features to interact with the callee's UA. 1555 This example is suitable only as a learning aid, as its performance 1556 is poor. 1558 The callee's monitor monitors calls made to the UA(s) by subscribing 1559 to the UA(s) dialog events. This enables it to determine their Call- 1560 Id's and their final response statuses. 1562 The proxy for the UA(s) routes to the callee's monitor any SUBSCRIBEs 1563 for the call-completion event package directed to the URIs serviced 1564 by the UA(s). 1566 The callee's monitor monitors the status of the UA(s) to determine 1567 when they are in a suitable state to receive a CC call by watching 1568 the busy/not-busy status of the UA(s): e.g. a UA is available for 1569 CCBS when it is not busy, but a UA is available for CCNR when it 1570 becomes not busy after being busy with an established call. 1572 Authors' Addresses 1574 Dale R. Worley 1575 Ariadne Internet Services, Inc. 1576 738 Main St. 1577 Waltham, MA, 02451 1578 US 1580 Phone: +1 781 647 9199 1581 Email: worley@ariadne.com 1582 URI: http:// 1583 Martin Huelsemann 1584 Deutsche Telekom 1585 Heinrich-Hertz-Strasse 3-7 1586 Darmstadt, 64307 1587 Germany 1589 Phone: +4961515812765 1590 Email: martin.huelsemann@telekom.de 1591 URI: http://www.telekom.de 1593 Roland Jesske 1594 Deutsche Telekom 1595 Heinrich-Hertz-Strasse 3-7 1596 Darmstadt, 64307 1597 Germany 1599 Phone: +4961515812766 1600 Email: r.jesske@telekom.de 1601 URI: http://www.telekom.de 1603 Denis Alexeitsev 1604 TeleFLASH 1605 Mainzer Landstrasse 47 1606 Frankfurt 60329 1607 Germany 1609 Phone: +49-69-257-378-230 1610 Email: alexeitsev@teleflash.com 1611 URI: http://www.teleflash.com