idnits 2.17.1 draft-ietf-bliss-call-completion-19.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 (February 11, 2013) is 4085 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 1512, 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: August 15, 2013 R. Jesske 6 Deutsche Telekom 7 D. Alexeitsev 8 TeleFLASH 9 February 11, 2013 11 Call Completion for Session Initiation Protocol (SIP) 12 draft-ietf-bliss-call-completion-19 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 August 15, 2013. 53 Copyright Notice 55 Copyright (c) 2013 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 . . . . . . . . . . . . . . . 8 75 4.2. Call-completion procedures . . . . . . . . . . . . . . . . 9 76 4.3. Automatic redial as a fallback . . . . . . . . . . . . . . 12 77 4.4. Differences from SS7 . . . . . . . . . . . . . . . . . . . 12 78 5. Call-completion queue model . . . . . . . . . . . . . . . . . 13 79 6. Caller's agent behavior . . . . . . . . . . . . . . . . . . . 14 80 6.1. Receiving the CC possible indication . . . . . . . . . . . 14 81 6.2. Subscribing to CC . . . . . . . . . . . . . . . . . . . . 14 82 6.3. Receiving a CC recall notification . . . . . . . . . . . . 16 83 6.4. Initiating a CC call . . . . . . . . . . . . . . . . . . . 16 84 6.5. Suspending CC . . . . . . . . . . . . . . . . . . . . . . 16 85 6.6. Resuming CC . . . . . . . . . . . . . . . . . . . . . . . 17 86 7. Callee's monitor behavior . . . . . . . . . . . . . . . . . . 17 87 7.1. Sending the CC possible indication . . . . . . . . . . . . 17 88 7.2. Receiving a CC subscription . . . . . . . . . . . . . . . 18 89 7.3. Sending a CC notification . . . . . . . . . . . . . . . . 19 90 7.4. Receiving a CC call . . . . . . . . . . . . . . . . . . . 20 91 7.5. Receiving a CC suspension . . . . . . . . . . . . . . . . 20 92 7.6. Receiving a CC resumption . . . . . . . . . . . . . . . . 21 93 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 9. Call-completion event package . . . . . . . . . . . . . . . . 26 95 9.1. Event package name . . . . . . . . . . . . . . . . . . . . 26 96 9.2. Event package parameters . . . . . . . . . . . . . . . . . 26 97 9.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 26 98 9.4. Subscribe duration . . . . . . . . . . . . . . . . . . . . 27 99 9.5. NOTIFY bodies . . . . . . . . . . . . . . . . . . . . . . 27 100 9.6. Subscriber generation of SUBSCRIBE requests . . . . . . . 28 101 9.7. Notifier processing of SUBSCRIBE requests . . . . . . . . 28 102 9.8. Notifier generation of NOTIFY requests . . . . . . . . . . 28 103 9.9. Subscriber processing of NOTIFY requests . . . . . . . . . 29 104 9.10. Handling of forked requests . . . . . . . . . . . . . . . 29 105 9.11. Rate of notifications . . . . . . . . . . . . . . . . . . 29 106 9.12. State agents . . . . . . . . . . . . . . . . . . . . . . . 30 107 10. Call-completion information format . . . . . . . . . . . . . . 30 108 10.1. Call-completion status . . . . . . . . . . . . . . . . . . 30 109 10.2. Call-completion service-retention indication . . . . . . . 30 110 10.3. Call-completion URI . . . . . . . . . . . . . . . . . . . 31 111 11. Security considerations . . . . . . . . . . . . . . . . . . . 31 112 12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 113 12.1. SIP event package registration for call-completion . . . . 33 114 12.2. MIME registration for application/call-completion . . . . 33 115 12.3. SIP/SIPS URI parameter 'm' . . . . . . . . . . . . . . . . 34 116 12.4. Call-Completion purpose parameter value . . . . . . . . . 34 117 12.5. 'm' header parameter for Call-Info . . . . . . . . . . . . 35 118 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 119 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 120 14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 121 14.2. Informative References . . . . . . . . . . . . . . . . . . 36 122 Appendix A. Example Caller's Agent . . . . . . . . . . . . . . . 37 123 Appendix B. Example Callee's Monitor . . . . . . . . . . . . . . 37 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 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 Notifier: the user agent that generates NOTIFY requests for the 245 purpose of notifying subscribers of the callee's availibility; for 246 the CC service this is task of the callee's monitor. 248 Original call: the initial call which failed to reach a desired 249 destination. 251 Retain option: a characteristic of the CC service; if supported, CC 252 calls which again encounter a busy callee will not be queued again, 253 but the position of the caller's entry in the queue is retained. 254 Note that SIP CC always operates with the retain option active; a 255 failed CC call does not cause the CC request to lose its position in 256 the queue. 258 Subscriber: the user agent that receives NOTIFY requests with 259 information of the callee's availibility; for the CC service this is 260 task of the caller's agent. 262 Suspended CC request: a CC request which is temporarily not to be 263 selected for CC recall. 265 4. Solution 266 4.1. Call-completion architecture 268 The call-completion architecture augments each caller's UA (or UAC) 269 wishing to use the call-completion features with a "call-completion 270 agent" (also written as "caller's agent"). 272 It augments each callee's UA (or UAS) wishing to be the target of the 273 call-completion features with a "call-completion monitor" (also 274 written as "callee's monitor"). 276 The caller's agent and callee's monitor functions can be integrated 277 into the respective UAs, be independent end-systems, or be provided 278 by centralized application servers. The two functions, though 279 associated with the two UAs (caller and callee), also may be provided 280 as services by the endpoints' home proxies or by other network 281 elements. Though it is expected that a UA that implements call 282 completion will have both functions so that it can participate in 283 call completion as both caller and callee, the two functions are 284 independent of each other. 286 A caller's agent may service more than one UA as a collective group 287 if a caller or population of users will be shared between the UAs, 288 and especially if the UAs share an AOR. 290 The caller's agent monitors calls made from the caller's UA(s) in 291 order to determine their destinations and (potentially) their final 292 response statuses, and the Call-Info header fields of provisional and 293 final responses for to invoke the call completion feature. 295 A callee's monitor may service more than one UA as a collective group 296 if a callee or population of users will be shared between the UAs, 297 and especially if the UAs share an AOR. The callee's monitor may 298 supply the callee's UAS(s) with Call-Info header field values for 299 provisional and final responses. 301 The callee's monitor also instantiates a presence server used to 302 monitor caller's availability for CC recall. 304 The callees using the UA(s) may be able to indicate to the callee's 305 monitor when they wish to receive CC calls. 307 In order to allow flexibility and innovation, most of the interaction 308 between the caller's agent, the caller-user(s) and the caller's UA(s) 309 is out of the scope of this document. Similarly, most of the 310 interaction between the callee's monitor, the callee(s) and the 311 callee's UA(s) is out of the scope of this document, as is also the 312 policy by which the callee's monitor arbitrates between multiple 313 call-completion requests. 315 The caller's agent must be capable of performing a number of 316 functions relative to the UA(s). The method by which it does so is 317 outside the scope of this document, but an example method is 318 described in Appendix A. The callee's monitor must be capable of 319 performing a number of functions relative to the UA(s). The method 320 by which it does so is outside the scope of this document, but an 321 example method is described in Appendix B. 323 As a proof of concept, simple caller's agents and callee's monitors 324 can be devised that interact with users and UAs entirely through 325 standard SIP mechanisms [RFC6665], [RFC4235] and [RFC3515], as 326 described in the Appendixes. 328 The callers using the UA(s) can indicate to the caller's agent when 329 they wish to avail themselves of CC for a recently-made call which 330 the callers determined to unsuccessful. The caller's agent monitors 331 the status of the caller's UA(s) to determine when they are available 332 to be used for a CC recall. The caller's agent can communicate to 333 the caller's UA(s) that a CC recall is in progress and to inquire if 334 the relevant caller is available for the CC recall. 336 The callee's monitor may utilize several methods to monitor the 337 status of the callee's UA(s) and/or their users for availability to 338 receive a CC call. This can be achieved through monitoring calls 339 made to the callee's UA(s) to determine their caller's and their 340 final response' statuses. And in a system with rich presence 341 information, the presence information may directly provide this 342 status. In a more restricted system, this determination can depend 343 on the mode of the CC call in question, which is provided by the URI 344 'm' parameter. E.g., a UA is considered available for CCBS ("m=BS") 345 when it is not busy, but a UA is considered available for CCNR 346 ("m=NR") when it becomes not busy after being busy with an 347 established call. 349 The callee's monitor maintains information about the set of INVITEs 350 received by the callee's UA(s) considered unsuccessful by the caller. 351 In practice, the callee's monitor may remove knowledge about an 352 incoming dialog from its set if local policy at the callee's monitor 353 establishes that the dialog is no longer eligible for CC activations. 355 4.2. Call-completion procedures 357 The caller's UA sends an INVITE to a request URI. One or more forks 358 of this request reach one or more of the callee's UAs. If the call- 359 completion feature is available, the callee's monitor (note there can 360 be a monitor for each of the callee's UAs) inserts a Call-Info header 361 field with its URI and with "purpose=call-completion" in appropriate 362 non-100 provisional or final response to the initial INVITE and 363 forwards them to the caller. The provisional response SHOULD be sent 364 reliably, if the INVITE contained a Supported header field with the 365 option tag 100rel. On receipt of a non-100 provisional or a final 366 response with the indication that the call-completion feature is 367 available, the calling user can invoke the CC feature. 369 The caller indicates to the caller's agent that he wishes to invoke 370 call-completion services on the recent call. Note that from the SIP 371 point of view, the INVITE may have been successful, but from the 372 user's point of view, the call may have been unsuccessful. E.g., the 373 call may have connected to the callee's voicemail, which would return 374 a 200 status to the INVITE but from the caller's point of view is "no 375 reply". 377 In order to receive information necessary for the caller to complete 378 the call at the callee, the caller's agent subscribes to the call- 379 completion event package at the callee's monitor. 381 The possibility of the caller to complete the call at the callee is 382 also known as the call-completion state (cc-state) of the caller. 383 The cc-states comprehend the values 'queued' and 'ready' (for call- 384 completion). 386 In order to receive information from all destinations where the 387 callee will be reachable, the caller's agent sends a SUBSCRIBE 388 request for the call-completion event package to the original 389 destination URI of the call and to all known callee's monitor URIs 390 (which are provided by Call-Info header fields in provisional and 391 final responses to the INVITE). The callee's monitor uses the 392 subscription as an indication that caller is interested in using the 393 CC feature with regard to the specified callee. The callee's monitor 394 keeps a list or queue of the caller's agent's subscriptions, 395 representing the requests from the caller's agent to the callee's 396 monitors for call-completion services. These subscriptions are 397 created, refreshed, and terminated according to the procedures of 398 [RFC6665]. 400 Upon receiving a SUBSCRIBE request from the caller's agent, the 401 callee's monitor instantiates a presence state for the caller's UA 402 which can be modified by the caller's UA to indicate its availability 403 for CC call. The status at the presence upon instantiation is 404 "open". 406 When the callee's monitor determines the callee and/or callee's UA 407 available for a CC call, it selects a caller to execute the CC call 408 and sends a call-completion event update (''cc-state: ready'') via a 409 NOTIFY request to the selected caller's agent's subscription, telling 410 it to begin the CC call to the callee's UA. 412 When the caller's agent receives this update, it initiates a CC 413 recall by calling the caller's UA, and then starts the CC call to the 414 callee's UA, using 3rd party call control procedures in accordance 415 with [RFC3725]. The caller's agent can also check by other means 416 whether the caller is available to initiate the CC call to the 417 callee's UA. If the caller is available, the caller's agent directs 418 the caller's UA to initiate the CC call to the callee's UA. 420 The caller's agent marks the CC call as such by adding a specific SIP 421 URI parameter to the Request-URI, so it can be given precedence by 422 the callee's monitor in reaching the callee's UA. 424 If the caller is not available on the receipt of the "ready for 425 recall" notification, the caller's agent suspends the CC request at 426 the callee's monitor by sending a PUBLISH request containing presence 427 information to the callee's monitor's presence server, informing 428 about the presence status 'closed'. Once the caller becomes 429 available for a CC call again, the caller's agent resumes the CC 430 request by sending another PUBLISH request to the callee's monitor, 431 informing about the presence status 'open'. 433 On the receipt of the suspension request, the callee's monitor 434 performs the monitoring for the next non-suspended CC request in the 435 queue. On the receipt of the resume from the previously suspended 436 caller's agent that was at the top of the queue, the callee's monitor 437 performs the callee monitoring for this caller's agent. 439 When the CC call fails there are two possible options: the CC feature 440 has to be activated again by caller's agent subscribing to callee's 441 monitor, or CC remains activated and the original CC request retains 442 its position in the queue if retain option is supported. 444 The retain option (see section 3) determines the callee's monitor's 445 behavior when a CC call fails. If the retain option is supported, CC 446 remains activated and the original CC request retains its position in 447 the queue. Otherwise the CC feature is deactivated, and the caller's 448 agent would have to subscribe again to reactivate it. 450 A monitor that supports the retain option provides the cc-service- 451 retention header in its call-completion events. A caller's agent 452 that also supports the retain option uses the presence of this header 453 to know not to generate a new CC request after a failed CC call. 455 Monitors not supporting the retain option do not provide the cc- 456 service-retention header. A failed CC call causes the CC request to 457 be deleted from the queue, and these monitors will terminate the 458 corresponding caller's agent's subscription to inform that agent that 459 its CC request is no longer in the queue. A caller's agent that does 460 not support the retain option can also terminate its subscription 461 when a CC call fails, so it is possible that both the caller's agent 462 and the monitor may be signalling the termination of the subscription 463 concurrently. This is a normal SIP Events [ [RFC6665]] scenario. 464 After the subscription is terminated, the caller's agent may create a 465 new subscription (as described in section 6.2) to reactivate the CC 466 feature for the original call. 468 4.3. Automatic redial as a fallback 470 Automatic redial is a simple end-to-end design. An automatic redial 471 scenario is described in [RFC5359], section 2.17. This solution is 472 based on the usage of the dialog event package. When the callee is 473 busy when the call arrives, the caller subscribes to the callee's 474 call state. The callee's UA sends a notification when the callee's 475 call state changes. This means the caller is also notified when the 476 callee's call state changes to 'terminated'. The caller is alerted, 477 then the caller's UA starts a call establishment to the callee again. 478 If several callers have subscribed to a busy callee's call state, 479 they will be notified at the same time that the call state has 480 changed to 'terminated'. The problem of this solution is, that it 481 might happen that several recalls are started at the same time. This 482 means it is a heuristic approach with no guarantee of success. 484 There is no interaction between call completion and automatic redial, 485 as there is a difference in the behavior of the callee's monitor and 486 the caller when using the dialog event package for receiving dialog 487 information or for aggregating a call completion state. 489 4.4. Differences from SS7 491 SIP call completion differs in some ways from the CCBS and CCNR 492 features of SS7 (which is used in the PSTN). For ease of 493 understanding, we enumerate some of the differences here. 495 As there is no equivalent to the forking mechnism in SS7, in the PSTN 496 calls can be clearly differentiated between successful or 497 unsuccessful. Due to the complex forking situations that are 498 possible in SIP, a call may "fail" from the point of view of the user 499 and yet have a "success" response from SIP's point of view. (This 500 can happen even in simple situations: e.g., a call to a busy user 501 that fails over to his voicemail receives a SIP success response, 502 even though the caller may consider it "busy subscriber".) Thus, the 503 caller must be able to invoke call completion even when the original 504 call appeared to succeed. To support this, the caller's agent must 505 record successful calls as well as unsuccessful calls. 507 In SIP, only the caller's UA or service system on the originating 508 side and the callee's UA or service system on the terminating side 509 need to support call completion for call completion to work 510 successfully between the UAs. Intermediate SIP systems (proxies or 511 B2BUAs) do not need to implement call completion; they only need to 512 be transparent to the usual range of SIP messages. In the PSTN also 513 intermediate nodes like media gateway controllers have to implement 514 the call completion service. 516 5. Call-completion queue model 518 The callee's monitor manages CC for a single URI. This URI is likely 519 to be a published AOR, or more likely "non-voicemail AOR", but it may 520 be as narrowly scoped as a single UA's contact URI. The callee's 521 monitor manages a dynamic set of call-completion entities (called 522 "CCEs") which represent CC requests, or equivalently, the existing 523 incoming call-completion subscriptions. This set is also called a 524 queue, because a queue data structure often aids in implementing the 525 callee's monitor's policies for selecting CCEs for CC recall. 527 Each CCE has an availability state, determined through caller's 528 presence status at the callee's monitor. A presence status of 529 ''open'' represents CCE's availability state of 'available' and a 530 presence status of "closed" represents CCE's availability state of 531 'unavailable'. 533 Each CCE has a recall state which is visible via subscriptions. The 534 recall state is either "queued" or "ready". 536 Each CCE carries the From URI of the SUBSCRIBE request that caused 537 its creation. 539 CC subscriptions arrive at the callee's monitor by addressing the 540 URIs the callee's monitor returns in Call-Info header fields. The 541 request URI of the SUBSCRIBE request determines the queue to which 542 the resulting CCE is added. The resulting subscription reports the 543 status of the queue. The base event data is the status of all the 544 CCEs in the queue, but the data returned by each subscription is 545 filtered to report only the status of that subscription's CCE. 546 (Further standardization may define means for obtaining more 547 comprehensive information about a queue.) 549 When a CCE is created, it is given the availability state "available" 550 and recall state "queued". 552 When the callee's monitor receives PIDF bodies [RFC3863] via PUBLISH 553 requests [ [RFC3903]], these PUBLISH requests are expected to be sent 554 by subscribers to indirectly suspend and resume their CC requests by 555 modifying its CCE availability state. A CCE is identified by the 556 request-URI (if it was taken from a call-completion event 557 notification which identifies the CCE) or the From URI of the request 558 (matching the From URI recorded in the CCE). Receipt of a PUBLISH 559 with 'status' of 'open' sets the availability state of the CCE to 560 'available' (resume); 'status' of 'closed' sets the availability 561 state of the CCE to 'not-available' (suspend). 563 A CC request is eligible for recall only when its CCE's availability 564 state is "available" and the "m" value of the CCE also indicates an 565 available state. The callee's monitor MUST NOT select for recall any 566 CC requests that fail to meet those criteria. Within that 567 constraint, the callee's monitor's selections are determined by its 568 local policy. Often, a callee's monitor will choose the acceptable 569 CCE that has been in the queue the longest. When the callee's 570 monitor has selected a CCE for recall, it changes the CCE's recall 571 state from 'queued' to 'ready', which triggers a notification on the 572 CCE's subscription. 574 If a selected subscriber then suspends its request by sending a 575 PUBLISH with the presence status 'closed', the CCE becomes not- 576 available, and the callee's monitor changes the CCE's recall state to 577 'queued'. This may cause another CCE (e.g., that has been in the 578 queue for less time) to be selected for recall. 580 The caller's presence status at the callee's monitor is terminated 581 when the caller completes its CC call or when the caller's agent's 582 subscription at the callee's monitor is terminated. 584 6. Caller's agent behavior 586 6.1. Receiving the CC possible indication 588 The caller's agent MUST record the From URI and SHOULD record the 589 final request status that the caller's UA received along with the 590 contents of Call-Info header fields of provisional and final 591 responses. 593 Note that receiving a CC possible indication also depends on the 594 aggregation of final responses by proxies, in case of 4xx responses 595 some 4xx responses are more likely to be sent to the caller. 597 6.2. Subscribing to CC 599 For CC activation the caller's agent MUST send a SUBSCRIBE to all 600 known callee's monitor URIs. A callee's monitor URI may be provided 601 in the Call-Info header field in provisional and final responses to 602 the INVITE sent back by the callee's monitor(s). Additionally, the 603 caller's agent SHOULD include the original request-URI that it sent 604 the original INVITE to, in its set of callee's monitor URIs, when it 605 is unclear if the call has forked to additional callees whose 606 responses the caller has not seen. A SUBSCRIBE to the original 607 request-URI alone is used in cases where the caller's agent has not 608 received or does not remember any callee's monitor URI. The caller's 609 agent SHOULD add an 'm' parameter to these URIs in order to indicate 610 the desired call-completion proceeding at the callee's monitor. The 611 'm' parameter SHOULD have the value of the 'm' parameter received in 612 the Call-Info header field of the responses to the original INVITE. 614 To minimize redundant subscriptions, these SUBSCRIBEs SHOULD be 615 presented as forks of the same transaction as defined by section 616 8.2.2.2 of [RFC3261], if the caller's agent is capable of doing so. 618 The agent MUST NOT maintain more than one CC request for a single 619 caller and directed to a single original destination URI. If a 620 caller requests CC a second time for the same destination URI, the 621 agent MUST consolidate the new request with the existing CC request 622 by either reusing the existing CC subscriptions or terminating and 623 then recreating them. For this purpose, equality of callers is 624 determined by comparing caller's AORs and equality of destination 625 URIs is determined by comparing them per [RFC3261] section 19.1.4. 627 When generating these SUBSCRIBEs, the From URI MUST be the caller's 628 AOR. The To URI SHOULD be the destination URI of the original call 629 (if the agent knows that and can insert it into the To header), and 630 otherwise MUST be the request-URI of the SUBSCRIBE. 632 The SUBSCRIBE SHOULD have header fields to optimize its routing. In 633 particular, it SHOULD contain "Request-Disposition: parallel", and an 634 Accept-Contact header field to eliminate callee UAs that are not 635 acceptable to the caller. 637 The caller's agent MUST be prepared to receive multiple responses for 638 multiple forks of the SUBSCRIBE and to have multiple subscriptions 639 established. The caller's agent must also be prepared to have the 640 SUBSCRIBE fail, in which case, CC cannot be invoked for this original 641 call. 643 If the caller's agent no longer wants to initiate the CC call (e.g., 644 because the caller has deactivated CC), the caller's agent terminates 645 the subscription in accordance with [RFC6665] or suspends the 646 subscription(s) as specified in subclause 6.5. 648 6.3. Receiving a CC recall notification 650 When receiving a NOTIFY with the cc-state set to 'ready', the 651 caller's agent SHOULD suspend all other subscriptions to CC, by 652 following the step in section 6.5, in order to prevent any other CC 653 requests from this caller to receive CC recalls. The caller's agent 654 starts the CC recall to the caller by confirming that the caller 655 would be able to initiate a CC call, e.g. by calling the caller's 656 UA(s). 658 6.4. Initiating a CC call 660 If the caller is available for the CC call and willing to initiate 661 the CC call, the caller's agent causes the caller's UA to generate a 662 new INVITE towards the callee. The caller's UA MAY add a 'm' URI 663 parameter with the value of the 'm' parameter received in Call-Info 664 header in the response to original INVITE, in order to specify his 665 preferences in CC processing and to prioritize the CC call. The 666 INVITE SHOULD be addressed to the URI specified in the cc-URI of the 667 NOTIFY, or if not available it SHOULD use the URI in the Call-Info 668 header field of the response to the original INVITE, or if not 669 available it MAY use the request-URI of the original INVITE, if this 670 URI was recorded. Note that the latter choice may not provide ideal 671 routing, but in simple cases it is likely to reach the desired 672 callee/callee's monitor. 674 6.5. Suspending CC 676 If the caller is not available for the CC recall, the CC request 677 SHALL be suspended by the caller's agent until the caller becomes 678 available again, or if the conditions relevant to the caller's 679 agent's local policy for suspensions have changed. To suspend the CC 680 request, the caller's agent SHALL publish the caller's presence state 681 by sending a PUBLISH request to each callee's monitor where the 682 presence server for CC resides in accordance with the procedures 683 described in [RFC3903] , giving the PIDF state 'closed' for the 684 caller's identity as presentity. The PUBLISH request SHOULD contain 685 an Expires header field with a value that corresponds to the current 686 value of the remaining CC subscription duration. 688 Each PUBLISH SHOULD be sent to the CC URI as received in the NOTIFY, 689 or within the corresponding SUBSCRIBE dialog, or if that is not 690 possible, to the corresponding callee's monitor URI received in the 691 Call-Info header field of the NOTIFY, or if one is not available, the 692 Contact address of the subscription. 694 6.6. Resuming CC 696 When the caller is no longer busy, or if the conditions relevant to 697 the caller's agent's suspension policy have changed, then the CC 698 request SHALL be resumed by the caller's agent. To resume a CC 699 request, the caller's agent SHALL publish the Caller's presence state 700 by sending a PUBLISH request to each callee's monitor a PUBLISH 701 request in accordance with the procedures described in [RFC3903] , 702 informing about the PIDF state 'open' but otherwise be constructed as 703 same as the suspend PUBLISH request. These PUBLISH requests are sent 704 to presence server that are instantiated at a CC monitor. 706 In the case where the caller's agent has sent several CC suspension 707 requests to different callee's monitors and the caller becomes 708 available again, as determined by the caller's agent's local policy 709 about resumption the caller's agent MAY send a PUBLISH to resume a CC 710 request to each callee's monitor for which there is a suspended CC 711 request. Note that the caller's agent's policy about resumption may 712 prescribe a manual resumption and thus a suspended CC request should 713 not be automatically resumed. 715 7. Callee's monitor behavior 717 7.1. Sending the CC possible indication 719 The callee's monitor MUST record the From URI and MAY record the 720 final request status(es) returned by the callee's UA(s). 722 If the callee's monitor wants to enable the caller to make use of the 723 CC service, it MUST insert a Call-Info header field with 724 "purpose=call-completion" in the final response message (e.g. in a 725 486 to enable call-completion due to busy subscriber) and at least 726 one non-100 provisional response message (e.g. in a 180 due to no 727 response) to the initial INVITE when forwarding it to the caller. 728 The non-100 provisional response message SHOULD be sent reliably if 729 the INVITE contained a Supported header field with the option tag 730 100rel. The Call-Info header field values defined in this 731 specification positively indicates that CC is available for the 732 failed fork of the call. 734 The callee's monitor SHOULD insert a URI in the Call-Info header 735 field where the caller's agent should subscribe for call-completion. 736 Ideally, it is a globally-routable URI [RFC5627] for the callee's 737 monitor. In practice, it may be the callee's AOR, and the SUBSCRIBE 738 will be routed to the callee's monitor only because it specifies 739 "Event: call-completion". 741 In order to enable call-completion, the Call-Info header field MUST 742 be set up according to the following scheme: 744 Call-Info:monitor-URI;purpose=call-completion;m=XX 746 The 'm' parameter defines the "mode" of call completion. The "m=NR" 747 parameter indicates that it failed due to lack of response, the 748 "m=BS" parameter indicates that it failed due to busy subscriber, and 749 the "m=NL" parameter indicates that it failed due to non registered 750 subscriber (no devices are registered for the AoR contacted). The 751 'm' parameter is useful for PSTN interworking and assessing presence 752 information in the callee's monitor. It is possible that other 753 values will be defined in future. It is also allowed to omit the 'm' 754 parameter entirely. Implementations MUST accept CC operations in 755 which the 'm' parameter is missing or has an unknown value, and 756 execute them at its best in their environment (which is likely to be 757 a degraded service, especially when interoperating with SS7). 759 7.2. Receiving a CC subscription 761 The callee's monitor MUST be prepared to receive SUBSCRIBEs for the 762 call-completion event package directed to the URIs of UA(s) that it 763 is servicing and any URIs that the callee's monitor provides in Call- 764 Info header fields. The SUBSCRIBEs MUST be processed in accordance 765 with the procedures defined in [RFC6665]. 767 The callee's monitor(s) that receive the SUBSCRIBE establish 768 subscriptions. These subscriptions represent the caller's agent's 769 request for call-completion services. 771 If the monitor receives two or more SUBSCRIBEs that have the same 772 Call-Id header field value and the monitor considers the request-URIs 773 of the received SUBSCRIBEs to request the status of the same set of 774 UAs, then they are redundant forks of one SUBSCRIBE request, and the 775 monitor SHOULD reject all but one of the requests with 482 (Merged 776 Request) responses. 778 The monitor MAY determine that an incoming CC SUBSCRIBE is a 779 duplicate of an existing CC subscription if: (1) the Call-Id header 780 field values are different, (2) the From URIs (i.e., the caller's 781 AORs) are the same (per [RFC3261] section 19.1.4), (3) the To URIs 782 (which should be the request-URI of the original call) have the same 783 user and hostpart components, and (4) the monitor considers the 784 request-URIs of the received SUBSCRIBEs to request the status of the 785 same set of UAs. 787 If the monitor determines that a new subscription is a duplicate of 788 an existing subscription, it MAY terminate the existing subscription 789 in accordance with the procedures defined in [RFC6665]. In any case, 790 it MUST establish the new subscription. 792 The callee's monitor may apply restrictions as to which caller's 793 agents may subscribe. 795 The continuation of the caller's agent's subscription indicates to 796 the callee's monitor that the caller's agent is prepared to initiate 797 the CC call if it is selected for the 'ready' state. If the callee's 798 monitor becomes aware of a subscription which cannot be selected for 799 a CC recall, it SHOULD terminate the subscription in accordance with 800 [RFC6665]. 802 7.3. Sending a CC notification 804 The call-completion event package returns various information to the 805 caller's agent, but the vital datum it contains is the cc-state of 806 the caller's agent's CC request in the CC queue, which in the 807 beginning is 'queued'. When the cc-state of the agent's request 808 changes, the callee's monitor MUST send a NOTIFY for a call- 809 completion event to the caller's agent. The notification SHOULD also 810 contain a URI which can be used for suspension requests. Ideally, it 811 is a globally-routable URI [RFC5627] for the callee's monitor. In 812 practice, it may be the callee's AOR, and the SUBSCRIBE will be 813 routed to the callee's monitor only because it specifies "Event: 814 call-completion". 816 The call-completion event package provides limited information about 817 the callee's monitor's policy. In particular, like in the PSTN, the 818 "'cc-service-retention" datum gives an indication of the "service 819 retention" attribute, which indicates whether the CC request can be 820 continued to a later time if the CC call fails due to the callee's 821 UA(s) being busy. If the callee's monitor supports the service- 822 retention option, the callee's monitor SHOULD include the cc-service- 823 retention parameter. 825 The callee's monitor has a policy regarding when and how it selects 826 CC requests for the recall. This policy may take into account the 827 type of the requests (e. g. CCNR vs. CCBS), the state of the 828 callee's UA(s), the order in which the CC requests arrived, the 829 length of time the CC requests have been active, and any previous 830 attempts of CC activations for the same original call. Usually the 831 callee's monitor will choose only one CC request for the recall at a 832 time, but if the callee's UA(s) can support multiple calls, it may 833 choose more than one. Usually the callee's monitor will choose the 834 oldest active request. 836 When the callee's monitor changes the state datum for the chosen 837 subscription from "queued" to "ready", the callee's monitor MUST send 838 a NOTIFY for the caller's agent's subscription with the cc-state set 839 to 'ready' (recall notification). The NOTIFY SHOULD also contain in 840 the cc-URI a URI to be used in the CC call. In practice, this may be 841 the AOR of the callee. 843 Upon sending the recall notification the callee's monitor MUST start 844 a recall timer. It is RECOMMENDED to use a value between 10 and 20 845 seconds, which corresponds to the recommendation for the call 846 completion services in ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733]. 848 7.4. Receiving a CC call 850 The callee's UA(s) and the callee's monitor may give the CC call 851 precedence over non-CC calls by evaluating the presence of the 'm' 852 URI parameter and the From header of the INVITE request. The 853 callee's monitor supervises the receiving of the CC call. Upon 854 arrival of the CC call the recall timer MUST be stopped. If the CC 855 call does not arrive at the callee's UA(s) before the expiry of the 856 recall timer, the callee's monitor SHOULD stop processing the recall 857 and change the value of the cc-state datum to "queued" if it supports 858 the retain option and terminate the subscription along with the queue 859 if it doesn't support the retain option. Similarly, if the CC call 860 is not accepted, the callee's monitor will stop the CC recall 861 processing. Depending on its policy, the same original call may be 862 selected again for a CC recall at a later time. If the CC call 863 succeeds, the callee's monitor MUST terminate the relevant 864 subscription in accordance with [RFC6665], and MUST remove any 865 associated presence event state used for suspend and resume for the 866 caller of the CC call. 868 Once the CC call has been terminated, successfully or unsuccessfully, 869 the callee's monitor's policy MAY select another CC request for a 870 recall according to the callee's monitor's policy. Note that 871 according to the callee's monitor's policy several recalls may be 872 processed at the same time. 874 7.5. Receiving a CC suspension 876 The monitor may receive PUBLISH requests to suspend CC requests from 877 caller's agent as described in section 6.5. The PUBLISH requests may 878 be received via the URI it manages, any URI that it inserts into a 879 Call-Info header, any contact URI it uses as a notifier for "call- 880 completion" events, or any URI it returns as the "URI" line of the 881 call-completion event packages. 883 The receipt of the PUBLISH request initiates a presence event state 884 for the caller's identity at the presence server functionality of the 885 callee's monitor as specified in [RFC3903] , together with a logical 886 presence server if this has not been done before for another call. 888 Note: The presence server may initiate a presence event state for the 889 caller's identity at the receipt of SUBSCRIBE request as well, 890 dependent on the implementation. 892 The monitor SHOULD identify the addressed CCE by the request-URI of 893 the PUBLISH request, or if that is not possible, by the From URI. 895 If the processing of a CC request results in suspending that CC 896 request by receiving a PUBLISH request from caller's agent as 897 described in section 6.5, the callee's monitor MUST stop the recall 898 timer and MUST ensure that the request is set to a 'queued' state, 899 and then the callee's monitor MUST attempt to process another CC 900 request in the queue according to the callee's monitor's local 901 policy. 903 7.6. Receiving a CC resumption 905 When a CC request becomes resumed by receiving a PUBLISH request from 906 caller's agent as described in section 6.6, the presence event state 907 for the caller's identity at the presence server functionality of the 908 CC monitor MUST be modified as described in [RFC3903]. If the callee 909 is not busy and there is no entry in the CC queue which is currently 910 being processed, the callee's monitor MUST process the queue as 911 described in section 7.3 above. 913 8. Examples 915 A basic call flow, with only the most significant messages of a call- 916 completion activation and invocation shown, is as follows (please 917 note this is an example and there may be variations in the failure 918 responses): 920 Caller Callee 921 sip:123@a.com sip:456@b.com 922 | | 923 | INVITE sip:456@b.com | [original call] 924 | From: sip:123@a.com | 925 |------------------------->| 926 | | 927 | 487 | 928 | Call-Info:;purpose=call-completion;m=NR 929 |<-------------------------| 930 | | 931 | SUBSCRIBE sip:456@z.b.com;m=NR [initial SUBSCRIBE] 932 | From: sip:123@a.com | 933 | Contact: sip:123@y.a.com | 934 | Request-Disposition: parallel 935 | Call-Id: abcd-efgh | 936 | Event: call-completion | 937 |------------------------->| 938 | | 939 | 200 | 940 |<-------------------------| 941 | | 942 | NOTIFY sip:123@y.a.com | [initial NOTIFY] 943 | Body: status: queued | 944 |<-------------------------| 945 | | 946 | SUBSCRIBE sip:456@b.com;m=NR [another init. SUB.] 947 | From: sip:foo@example.com| 948 | Request-Disposition: parallel 949 | Call-Id: abcd-efgh | 950 | Event: call-completion | 951 |------------------------->| 952 | | 953 | 482 | [duplicate SUB. rej.] 954 |<-------------------------| 955 | | 956 | NOTIFY sip:123@y.a.com | [CC invoked] 957 | Body: status: ready | 958 | URI: sip:recall@z.b.com 959 |<-------------------------| 960 | | 961 | INVITE sip:recall@z.b.com;m=NR [CC call] 962 | From: sip:foo@example.com| 963 |------------------------->| 964 | | 965 | NOTIFY sip:123@y.a.com | [CC terminated] 966 | Expires = 0 | 967 |<-------------------------| 969 The original call is an ordinary INVITE. It fails due to no-response 970 (ring-no-answer). In this case, the callee's governing proxy 971 generates a 487 response because the proxy canceled the INVITE to the 972 UA when it rang too long without an answer. The 487 response carries 973 a Call-Info header field with "purpose=call-completion". The Call- 974 Info header field positively indicates that CC is available for this 975 failed fork of the call. The "m=NR" parameter indicates that it 976 failed due to no-response, which is useful for PSTN interworking and 977 assessing presence information in the callee's monitor. 979 The URI in the Call-Info header field () is where 980 the caller's agent should subscribe for call-completion processing. 981 Ideally, it is a globally-routable URI for the callee's monitor. In 982 practice, it may be the callee's AOR, and the SUBSCRIBE will be 983 routed to the callee's monitor only because it specifies "Event: 984 call-completion". 986 CC is activated by sending a SUBSCRIBE to all known callee's monitor 987 URIs. These can be provided by the Call-Info header field in the 988 response to the INVITE. 990 Additionally, the caller's agent needs to include the original 991 request-URI in its set of callee's monitor URIs, because the call may 992 have forked to additional callees whose responses the caller has not 993 seen. (A SUBSCRIBE to the request-URI alone is used in cases where 994 the caller's agent has not received or cannot remember any callee's 995 monitor URI.) 997 The caller's agent adds to these URIs an 'm' parameter (if possible). 998 In this case, the caller's agent forks the SUBSCRIBE to two 999 destinations as defined by section 8.2.2.2 of [RFC3261], with 1000 appropriate Request-Disposition. The first SUBSCRIBE is to the URI 1001 from Call-Info. 1003 The second SUBSCRIBE is to the original request-URI, and reaches the 1004 same callee's monitor. Because it has the same Call-Id as the 1005 SUBSCRIBE that has already reached the callee's monitor, the callee's 1006 monitor rejects it with a 482, thus avoiding redundant subscriptions. 1008 The initial NOTIFY for the successful SUBSCRIBE has "state: queued" 1009 in its body. Eventually, this caller is selected for CC, and is 1010 informed of this via a NOTIFY containing "state: ready". This NOTIFY 1011 carries a URI to which the INVITE for CC call should be sent. In 1012 practice, this may be the AOR of the callee. 1014 The caller generates a new INVITE to the URI specified in the NOTIFY, 1015 or if there was no such URI or if the caller's agent cannot remember 1016 it, it may use the original request-URI. The caller adds the 'm' 1017 parameters (if possible), to specify CC processing. 1019 Finally the subscription for the CC request is terminated by the 1020 callee's monitor. 1022 Another flow, with only the most significant messages of call- 1023 completion suspension and resumption shown, is as follows: 1025 Caller Callee 1026 sip:123@a.com sip:456@b.com 1027 | | 1028 | NOTIFY sip:123@y.a.com | [CC notification, caller not 1029 | Body: status: ready | available for CC recall] 1030 | URI: sip:recall@z.b.com 1031 |<-------------------------| 1032 | | 1033 | 200 | 1034 |------------------------->| 1035 | | 1036 | PUBLISH sip:456@z.b.com | [non-availibility for recall 1037 | From: sip:123@a.com | is published] 1038 | Contact: sip:123@y.a.com | 1039 | Event: presence 1040 | Content-Type: 'app/pidf' | 1041 | Body: status=closed 1042 |------------------------->| 1043 | | 1044 | 200 | 1045 |<-------------------------| 1046 | | 1047 | | [caller becomes available 1048 | | again] 1049 | | 1050 | PUBLISH sip:456@z.b.com | [availibility for recall 1051 | From: sip:123@a.com | is published] 1052 | Contact: sip:123@y.a.com | 1053 | Event: presence 1054 | Content-Type: 'app/pidf' | 1055 | Body: status=open 1056 |------------------------->| 1057 | | 1058 | 200 | 1059 |<-------------------------| 1060 | | 1062 The caller is selected for CC, and is informed of this via a NOTIFY 1063 request containing "state: ready". At this time, the caller is not 1064 available for the CC recall. 1066 For updating his presence event state at the presence server 1067 functionality at the callee, the caller generates a PUBLISH request 1068 to the CC URI as received in the NOTIFY, or within the corresponding 1069 SUBSCRIBE dialog, or if that is not possible, to the corresponding 1070 callee's monitor URI received in the Call-Info header field of the 1071 NOTIFY, or if one is not available, the Contact address of the 1072 subscription, informing about the PIDF state 'closed' . 1074 When the caller is again available for the CC recall, he caller 1075 updates his presence event state at the presence server functionality 1076 at the callee by generating a PUBLISH request informing about the 1077 PIDF state 'open', but otherwise constructed as same as the suspend 1078 PUBLISH request. 1080 9. Call-completion event package 1082 This section specifies the call-completion event package, in 1083 accordance with section 4.4 of [RFC6665]. The call-completion event 1084 package has the media type "application/call-completion". 1086 Note that if the callee has a caller-queuing facility, the callee's 1087 monitor may want to treat the call-completion queue as part of the 1088 queuing facility, and include in the event package information 1089 regarding the state of the queue. How this information is conveyed 1090 is left for further standardization. 1092 9.1. Event package name 1094 The SIP Events specification requires package definitions to specify 1095 the name of their package or template-package. The name of this 1096 package is "call-completion". This value appears in the Event and 1097 Allow-events header fields. 1099 9.2. Event package parameters 1101 No package-specific Event header field parameters are defined for 1102 this event package. 1104 9.3. SUBSCRIBE bodies 1106 [RFC6665] requires package definitions to define the usage, if any, 1107 of bodies in SUBSCRIBE requests. 1109 The SUBSCRIBE request MAY contain an Accept header field. If no such 1110 header field is present, it has a default value of "application/ 1111 call-completion". If the header field is present, it MUST include 1112 "application/call-completion". 1114 A SUBSCRIBE request for a call-completion package MAY contain a body. 1115 This body defines a filter to be applied to the subscription. Filter 1116 documents are not specified in this document, and may be the subject 1117 of future standardization activity. 1119 A SUBSCRIBE request requests call-completion information regarding 1120 calls recently made from the same caller to the callee UA(s) serviced 1121 by the notifier. Calls are defined to be "from the same caller" if 1122 the URI-part of the From header field value in the INVITE is the same 1123 as the URI-part of the From header field value in the SUBSCRIBE. 1125 9.4. Subscribe duration 1127 [RFC6665] requires package definitions to define a default value for 1128 subscription durations, and to discuss reasonable choices for 1129 durations when they are explicitly specified. 1131 If a SUBSCRIBE does not explicitly request a duration, the default 1132 requested duration is 3600 seconds, as that is the highest service 1133 duration timer value recommended for the call completion services in 1134 ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733]. As because of the 1135 subscription duration no explicit timer is needed, and the 1136 subscription duration can be seen as an equivalent to the SS7 service 1137 duration timer, this specification refers to the subscription 1138 duration also as the service duration timer. It is RECOMMENDED that 1139 subscribers request, and that notifiers grant, a subscription time of 1140 at least 3600 seconds. 1142 If a notifier can determine that, according to its policy, after a 1143 certain duration the requested subscription can not any more proceed 1144 to "ready" state, it SHOULD reduce the granted subscription time to 1145 that duration. If a notifier can determine that, according to its 1146 policy, the requested subscription can never proceed to "ready" 1147 state, it should refuse the subscription. 1149 9.5. NOTIFY bodies 1151 [RFC6665] requires package definitions to describe the allowed set of 1152 body types in NOTIFY requests, and to specify the default value to be 1153 used when there is no Accept header field in the SUBSCRIBE request. 1154 A NOTIFY for a call-completion package MUST contain a body that 1155 describes the call-completion states. 1157 As described in [RFC6665], the NOTIFY message will contain bodies 1158 that describe the state of the subscribed resource. This body is in 1159 a format listed in the Accept header field of the SUBSCRIBE, or in a 1160 package-specific default format if the Accept header field was 1161 omitted from the SUBSCRIBE. 1163 In this event package, the body of the notification contains a call- 1164 completion document. All subscribers and notifiers MUST support the 1165 "application/call-completion" data format described in section 10. 1166 The SUBSCRIBE request MAY contain an Accept header field. If no such 1167 header field is present, it has a default value of "application/ 1168 call-completion". If the header field is present, it MUST include 1169 "application/call-completion". Of course, the notifications 1170 generated by the server MUST be in one of the formats specified in 1171 the Accept header field in the SUBSCRIBE request. 1173 9.6. Subscriber generation of SUBSCRIBE requests 1175 Subscribers MUST generate SUBSCRIBE requests when they want to 1176 subscribe to the call-completion event package at the terminating 1177 side in order to receive call-completion notifications. The 1178 generation of SUBSCRIBE requests can imply the usage of a call- 1179 completion service specific timer as described in section 9.4. 1181 9.7. Notifier processing of SUBSCRIBE requests 1183 Upon receiving a subscription refresh, the notifier MUST set the 1184 "expires" parameter of the Subscription-State header field to a value 1185 not higher than the current remaining duration of the subscription 1186 regardless of the value received in the Expires header field (if 1187 present) of the subscription refresh. 1189 If a subscription is not successful because the call-completion queue 1190 has reached the maximum allowed number of entries (short term 1191 denial), the notifier MUST send a 480 Temporarily Unavailable 1192 response to the subscriber, possibly with a Retry-after header field 1193 in accordance with the notifier's policy. If a subscription is not 1194 successful because a condition has occurred that prevents and will 1195 continue to prevent the call-completion service (long term denial), 1196 the notifier MUST send a 403 Forbidden response to the subscriber. 1198 A notifier MAY receive multiple forks of the same SUBSCRIBE, as 1199 defined by section 8.2.2.2 of [RFC3261]. In such a case, the 1200 notifier MUST reject all but one of the SUBSCRIBEs with a 482 Merged 1201 Request response unless some other failure response applies. 1203 The call-completion information can be sensitive. Therefore, all 1204 subscriptions SHOULD be handled with consideration of the security 1205 considerations discussed in section 11, in particular for verifying 1206 the identity of the subscriber. 1208 9.8. Notifier generation of NOTIFY requests 1210 Notifiers MUST generate NOTIFY requests when the CC request's state 1211 changes to 'queued' or to 'ready (for call-completion)'. A NOTIFY 1212 that is sent with non-zero expiration MUST contain the "cc-state" 1213 parameter. The parameter's value MUST be "queued" if the call- 1214 completion request represented by the subscription is not at this 1215 time selected by the callee's monitor for CC recall, and the 1216 parameter's value MUST be "ready" if the request is at this time 1217 selected by the callee's monitor for CC recall. 1219 A NOTIFY sent with a zero expiration (e.g., as a confirmation of a 1220 request to unsubscribe) MAY contain the "cc-state" parameter. 1222 When the callee's monitor withdraws the selection of the request for 1223 the CC recall (e.g., because the caller's agent has not initiated the 1224 CC recall INVITE before the CC recall timer expires, or because the 1225 agent has suspended the request from being considered for CC recall), 1226 the notifier MUST send a NOTIFY to the subscription of the selected 1227 request. This NOTIFY MUST contain the "cc-state" parameter set to 1228 "queued". 1230 If the call-completion subscription was successful and the retain 1231 option is supported at the callee, the NOTIFY MUST contain the "cc- 1232 service-retention" parameter. 1234 9.9. Subscriber processing of NOTIFY requests 1236 When receiving a NOTIFY requests with the cc-state set to 'ready', 1237 subscribers SHOULD suspend all other CC subscriptions for the 1238 original call at other notifiers. The receipt of a NOTIFY request 1239 with the cc-state set to 'ready' by the subscriber will also cause an 1240 interaction with the instances at the subscribers side hat are 1241 responsible for starting the CC recall. 1243 9.10. Handling of forked requests 1245 Forked requests are expected to be common for the call-completion 1246 event type. The subscriber MUST be prepared to process NOTIFY 1247 requests from multiple notifiers and to coordinate its processing of 1248 the information obtained from them in accordance with the procedures 1249 in this document. 1251 9.11. Rate of notifications 1253 The call completion service typically involves a single notification 1254 per notifier and per subscription that notifies about the change to 1255 'ready (for call-completion)', but MAY involve several notifications 1256 about the change to the 'ready' state, separated by a call completion 1257 call that failed due to a busy callee . Typically, notifications 1258 will be separated by at least tens of seconds. Notifiers SHOULD NOT 1259 generate more than three notifications for one subscription in any 1260 ten-second interval. Since it is important to avoid useless recalls, 1261 a notifier SHOULD send state changes to "queued" from "ready" 1262 promptly. Thus, a notifier SHOULD NOT send a state change to "ready" 1263 as the third notification in a ten-second interval, as that would 1264 make it impossible to promptly send a further state change to 1265 "queued". 1267 9.12. State agents 1269 State agents have no defined role in the handling of the call- 1270 completion package. 1272 10. Call-completion information format 1274 The following syntax specification uses the Augmented Backus-Naur 1275 Form (ABNF) as described in [RFC5234]. The formal syntax for the 1276 application/call-completion MIME type is described below. In 1277 general, the call-completion body is to be interpreted in the same 1278 way as SIP headers: (1) the names of the lines are case-insensitive, 1279 (2) the lines can be continued over line boundaries if the succeeding 1280 lines start with horizontal white space, and (3) lines with unknown 1281 names are to be ignored. The header lines defined in this document 1282 can occur at most once in any given call-completion document. 1284 call-completion = 1*(cc-header CRLF) 1286 cc-header = cc-state / cc-service-retention / cc-URI / extension- 1287 header 1289 The above rules whose names start with "cc-" are described below. 1290 Other rules are described in [RFC3261]. 1292 10.1. Call-completion status 1294 The cc-state line indicates the CC status of a particular user with 1295 an entry in a CC queue. It MUST be present unless the expiration 1296 time indicated in the NOTIFY is zero. 1298 cc-state = "cc-state" HCOLON ( "queued" / "ready" ) 1300 The value "queued" indicates that a subscriber's entry in the call- 1301 completion queue is not selected for CC recall. The value "ready" 1302 indicates that a user's entry in the call-completion queue has been 1303 selected for CC recall. 1305 10.2. Call-completion service-retention indication 1307 The service-retention line indicates the support of the retain 1308 option. The retain option, if supported at the callee, will maintain 1309 the entry in the CC queue, if a CC call has failed due to callee busy 1310 condition. If present, this parameter indicates that the retain 1311 option is supported, otherwise it is not supported. This parameter 1312 MAY be present in NOTIFY requests. 1314 cc-service-retention = "cc-service-retention" HCOLON "true" 1316 10.3. Call-completion URI 1318 The cc-URI line provides a URI (possibly in the form of a name-addr) 1319 which the agent SHOULD use as the request-URI of the CC recall INVITE 1320 and the suspend/resume PUBLISH. It SHOULD be provided in all 1321 NOTIFYs. The URI SHOULD be globally routable and SHOULD uniquely 1322 identify the CCE in question. The syntax provides for generic-params 1323 in the value, but this document defines no such parameters. 1324 Parameters that are not understood by the subscriber MUST be retained 1325 with the URI. 1327 cc-URI = "cc-URI" HCOLON addr-spec 1329 11. Security considerations 1331 The CC facility allows the caller's agent to determine some status 1332 information regarding the callee. This information intrinsically 1333 diminishes the privacy of the callee; in order to protect 1334 sufficiently the privacy of the callee, the overall amount of 1335 disclosure must be limited, and the amount of disclosure to any 1336 single caller must be limited. 1338 Of course, if a caller is not permitted to call the callee, that 1339 caller should not be allowed to establish a CC subscription. Callers 1340 that are particularly sensitive about their privacy may reject all CC 1341 subscriptions. But in the ordinary case, the optimal protection is 1342 to permit any caller to subscribe, but prevent any caller from 1343 subscribing for too long, or too often, or in a pattern that does not 1344 reveal to the callee (through CC calls) that the subscriptions are 1345 taking place. 1347 In legitimate use, CC event subscriptions will be made in stereotyped 1348 ways that limit the disclosure of status information: 1350 1. When a subscriber is selected for CC, a call should arrive 1351 promptly for the callee, or the subscription should be 1352 terminated. This expectation may be violated by a race condition 1353 between selection of the subscription for CC and the caller 1354 becoming unavailable, but it should be rare that a single 1355 subscription will exhibit the race condition more than once. 1357 2. Subscriptions should not remain suspended for longer than the 1358 expected duration of a call (a call by the caller to a third 1359 party). 1361 3. Subscriptions should be initiated only shortly after failed 1362 incoming calls. 1364 4. Most of the time, a callee should have no queued subscriptions. 1366 Violations of these expectations should be detected by the callee's 1367 monitor and reported as possible attempts at privacy violation. 1369 The CC facility may enhance the effectiveness of Spam over Internet 1370 Telephony (SPIT) by the following technique: The caller makes calls 1371 to a group of callees. The caller then requests CC for the calls 1372 that do not connect to the callees. The CC calls resulting are 1373 probably more likely to reach the callees than original calls to a 1374 further group of targets. 1376 In order to prevent Denial of Service (DoS) attacks and manipulations 1377 of the call-completion queue by suspending other call-completion 1378 entries than the own, a mechanism to correlate the identity of the 1379 original caller and the generator of the SUBSCRIBE and PUBLISH 1380 request is needed. The RECOMMENDED mechanism to authenticate the 1381 identity of the originator of call-completion relevant requests is 1382 the SIP Identity mechanism [RFC4474] . Alternatively, CC agents and 1383 monitors within an administrative domain or federation of domains MAY 1384 use the mechanism described in [RFC3325] to authenticate their 1385 identity with a P-Asserted-Identity header field. 1387 Furthermore, the use of presence server functionality to suspend or 1388 resume SHOULD be limited to a caller which has an active queue in the 1389 callee's monitor. This can be achieved first by monitoring and 1390 logging incoming call to the callee and the destination where CC 1391 indication was sent, then to ensure subscription to the call 1392 completion package is permitted only within a short timeframe after 1393 the initial call failed and to only accept PUBLISH request to the 1394 presence server functionality if there is an active queue for the 1395 caller in question. 1397 Note that regarding the authentication/authorization/billing logic 1398 subject to operator policy CC calls or subscriptions do not differ 1399 from other basic calls or event subscriptions. 1401 12. IANA considerations 1402 12.1. SIP event package registration for call-completion 1404 This specification registers an event package, based on the 1405 registration procedures defined in [RFC6665]. The followings is the 1406 information required for such a registration: 1408 Package Name: call-completion 1410 Is this registration for a Template-Package: No. 1412 Published Document: RFC XXXX (Note for RFC Editor: Please fill in 1413 XXXX with the RFC number of this specification). 1415 Person and e-mail to contact for further information: Martin 1416 Huelsemann, martin.huelsemann@telekom.de 1418 12.2. MIME registration for application/call-completion 1420 MIME media type name: application 1422 MIME subtype name: call-completion 1424 Required parameters: none. 1426 Optional parameters: none. 1428 Encoding considerations: Consists of lines of UTF-8-encoded 1429 characters, ended with CR-LF 1431 Security considerations: There are no security considerations 1432 internal to the media type. Its typical usage involves the security 1433 considerations described in RFC XXXX 1435 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1436 specification). 1438 Interoperability considerations: See RFC XXXX (Note for RFC Editor: 1439 Please fill in XXXX with the RFC number of this specification). 1441 Published specification: RFC XXXX (Note for RFC Editor: Please fill 1442 in XXXX with the RFC number of this specification) 1444 Applications that use this media type: the implementations of the 1445 call-completion features of the Session Initiation Protocol 1447 Additional information: 1449 Magic number(s): none 1450 File extension(s): not expected to be stored in files 1452 Macintosh file type code(s): not expected to be stored in files 1454 Person & email address to contact for further information: Martin 1455 Huelsemann, martin.huelsemann@telekom.de 1457 Intended usage: LIMITED USE 1459 Restrictions on usage: none 1461 Author/Change controller: the IETF 1463 12.3. SIP/SIPS URI parameter 'm' 1465 This specification defines one new SIP/SIPS URI parameter 'm' as per 1466 the registry created by [RFC3969]. It is used to identify that an 1467 INVITE request is a CC call, or to further identify that a SUBSCRIBE 1468 request is for the call-completion event package. The parameter may 1469 have a value that describes the type of the call-completion 1470 operation, as described in this specification. 1472 Name of the Parameter: m 1474 Predefined Values : yes 1476 RFC Reference : [RFC XXXX] 1478 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1479 specification) 1481 12.4. Call-Completion purpose parameter value 1483 This specification adds a new predefined value "call-completion" for 1484 the "purpose" header field parameter of the Call-Info header field. 1485 This modifies the registry header field parameters and parameter 1486 values by adding this RFC as a reference to the line for header field 1487 "Call-Info" and parameter name "purpose": 1489 Header Field: Call-Info 1491 Parameter Name: purpose 1493 Predefined Values: yes 1495 Reference: [RFC3261].[RFC5367][[RFC XXXX]] 1497 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1498 specification) 1500 12.5. 'm' header parameter for Call-Info 1502 This specification extends [RFC3261] to add a new header field 1503 parameter 'm' to the Call-Info header field. This adds a row to the 1504 registry header field parameters and parameter values: 1506 Header Field: Call-Info 1508 Parameter Name: m 1510 Predefined Values: yes 1512 Reference: [RFC XXXX] 1514 This RFC predefines the values 'BS', 'NR' and 'NL' . 1516 (Note for RFC Editor: Please fill in XXXX with the RFC number of this 1517 specification) 1519 13. Acknowledgements 1521 Thanks to Paul Kyzivat, John Elwell, Keith Drage, Andrew Hutton, 1522 Thomas Stach, Dennis Luebbers and Christer Holmberg who provided 1523 helpful comments, feedback and suggestions. 1525 14. References 1527 14.1. Normative References 1529 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1530 Requirement Levels", BCP 14, RFC 2119, March 1997. 1532 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1533 A., Peterson, J., Sparks, R., Handley, M., and E. 1534 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1535 June 2002. 1537 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 1538 Method", RFC 3515, April 2003. 1540 [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, 1541 W., and J. Peterson, "Presence Information Data Format 1542 (PIDF)", RFC 3863, August 2004. 1544 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1545 for Event State Publication", RFC 3903, October 2004. 1547 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 1548 (IANA) Uniform Resource Identifier (URI) Parameter 1549 Registry for the Session Initiation Protocol (SIP)", 1550 BCP 99, RFC 3969, December 2004. 1552 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 1553 Initiated Dialog Event Package for the Session Initiation 1554 Protocol (SIP)", RFC 4235, November 2005. 1556 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1557 Authenticated Identity Management in the Session 1558 Initiation Protocol (SIP)", RFC 4474, August 2006. 1560 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1561 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1563 [RFC5367] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to 1564 Request-Contained Resource Lists in the Session Initiation 1565 Protocol (SIP)", RFC 5367, October 2008. 1567 [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User 1568 Agent URIs (GRUUs) in the Session Initiation Protocol 1569 (SIP)", RFC 5627, October 2009. 1571 [RFC6665] Roach, A., "SIP-Specific Event Notification", RFC 6665, 1572 July 2012. 1574 14.2. Informative References 1576 [ETS300.356-18] 1577 "Completion of Calls to Busy Subscriber (CCBS) 1578 supplementary service", February 1995. 1580 [ITU-T.Q.733] 1581 "DESCRIPTION FOR CALL COMPLETION SUPPLEMENTARY SERVICES 1582 USING SS No. 7", February 1995. 1584 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1585 Extensions to the Session Initiation Protocol (SIP) for 1586 Asserted Identity within Trusted Networks", RFC 3325, 1587 November 2002. 1589 [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. 1590 Camarillo, "Best Current Practices for Third Party Call 1591 Control (3pcc) in the Session Initiation Protocol (SIP)", 1592 BCP 85, RFC 3725, April 2004. 1594 [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and 1595 K. Summers, "Session Initiation Protocol Service 1596 Examples", BCP 144, RFC 5359, October 2008. 1598 Appendix A. Example Caller's Agent 1600 This section outlines how an autonomous caller's agent can operate 1601 using only standard SIP features to interact with the caller's UA. 1602 This example is suitable only as a learning aid, as its performance 1603 is poor. 1605 The agent monitors calls made from the UA(s) by subscribing to the 1606 dialog event package of the UA(s). 1608 The UA(s) or their proxy routes calls made with either of two special 1609 dial sequences to the agent, which interprets the INVITEs as 1610 indications to make a CC request with BS or NR or NL mode for the 1611 latest call made by the UA. 1613 The agent monitors the status of the UA(s) for availability to be 1614 used for a CC call by examining the dialog events. 1616 The agent indicates to the UA(s) that CC recall is in progress by 1617 making call to the UA(s). If the UA is answered, the agent assumes 1618 that the caller is available and plays pre-recorded audio to indicate 1619 that CC recall is in progress. 1621 After playing the pre-recorded audio, the caller's agent uses REFER 1622 to order the UA to make the CC call to the callee. 1624 Appendix B. Example Callee's Monitor 1626 This section outlines how an autonomous callee's monitor can operate 1627 using only standard SIP features to interact with the callee's UA. 1628 This example is suitable only as a learning aid, as its performance 1629 is poor. 1631 The callee's monitor monitors calls made to the UA(s) by subscribing 1632 to the UA(s) dialog events. This enables it to determine their Call- 1633 Id's and their final response statuses. 1635 The proxy for the UA(s) routes to the callee's monitor any SUBSCRIBEs 1636 for the call-completion event package directed to the URIs serviced 1637 by the UA(s). 1639 The callee's monitor monitors the status of the UA(s) to determine 1640 when they are in a suitable state to receive a CC call by watching 1641 the busy/not-busy status of the UA(s): e.g. a UA is available for 1642 CCBS when it is not busy, but a UA is available for CCNR when it 1643 becomes not busy after being busy with an established call. 1645 Authors' Addresses 1647 Dale R. Worley 1648 Ariadne Internet Services, Inc. 1649 738 Main St. 1650 Waltham, MA, 02451 1651 US 1653 Phone: +1 781 647 9199 1654 Email: worley@ariadne.com 1655 URI: http:// 1657 Martin Huelsemann 1658 Deutsche Telekom 1659 Heinrich-Hertz-Strasse 3-7 1660 Darmstadt, 64307 1661 Germany 1663 Phone: +4961515812765 1664 Email: martin.huelsemann@telekom.de 1665 URI: http://www.telekom.de 1667 Roland Jesske 1668 Deutsche Telekom 1669 Heinrich-Hertz-Strasse 3-7 1670 Darmstadt, 64307 1671 Germany 1673 Phone: +4961515812766 1674 Email: r.jesske@telekom.de 1675 URI: http://www.telekom.de 1676 Denis Alexeitsev 1677 TeleFLASH 1678 Mainzer Landstrasse 47 1679 Frankfurt 60329 1680 Germany 1682 Phone: +49-69-257-378-230 1683 Email: alexeitsev@teleflash.com 1684 URI: http://www.teleflash.com