idnits 2.17.1 draft-bliss-ietf-call-completion-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 707. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 725. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 731. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 15, 2008) is 5908 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-sip-gruu' is defined on line 635, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC3841' is defined on line 661, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BLISS D. Worley 3 Internet-Draft Pingtel 4 Expires: August 18, 2008 M. Huelsemann 5 D. Alexeitsev 6 DT 7 February 15, 2008 9 Call Completion for Session Initiation Protocol(SIP) 10 draft-bliss-ietf-call-completion-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on August 18, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document analyzes the interoperability problems surrounding the 44 call-completion feature that allows a callee to put a caller's 45 request into a queue by which the caller can be notified to call back 46 the callee at later time. This document analyzes how different 47 solutions inter-operate and tries to make recommendation on how to 48 best meet this requirement 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 5. Detailed Description of the Call-Completion Mechanism . . . . 5 57 5.1. Caller's Call-Completion Agent . . . . . . . . . . . . . . 5 58 5.2. Callee's Call-Completion Monitor . . . . . . . . . . . . . 6 59 5.3. The Original Call Is Made . . . . . . . . . . . . . . . . 6 60 5.4. Call-Completion Is Invoked . . . . . . . . . . . . . . . . 7 61 5.5. The Call-Completion Request Is Queued . . . . . . . . . . 8 62 5.6. Call-Completion Is Activated . . . . . . . . . . . . . . . 8 63 5.7. Data Provided in the Call-Completion Event Package . . . . 10 64 6. Call Completion Event Package . . . . . . . . . . . . . . . . 10 65 6.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 10 66 6.2. Event Package Parameters . . . . . . . . . . . . . . . . . 10 67 6.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 11 68 6.4. Subscribe Duration . . . . . . . . . . . . . . . . . . . . 11 69 6.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 11 70 6.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 12 71 6.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 12 72 6.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 12 73 6.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 13 74 6.10. Handling of Forked Requests . . . . . . . . . . . . . . . 13 75 6.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 13 76 6.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 13 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 78 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 80 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 81 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 83 Intellectual Property and Copyright Statements . . . . . . . . . . 16 85 1. Introduction 87 The call-completion architecture is driven by the interactions 88 between two types of agents, a "caller's agent" which operates on 89 behalf of the original caller, and a "callee's monitor", which 90 operates on behalf of the original callee. In order to allow 91 flexibility and innovation, most of the interaction between the 92 caller's agent and the caller-user(s) and the caller's UA(s) is out 93 of the scope of this document. 95 Similarly, most of the interaction between the callee's monitor and 96 the callee-user(s) and the callee's UA(s) is out of the scope of this 97 document, as is also the policy by which the callee's monitor 98 arbitrates between multiple call-completion requests. (Although 99 simple agents and monitors can be devised that interact with users 100 and UAs entirely through standard SIP 101 mechanisms[RFC3265][RFC4235][RFC3515].) 103 2. Requirements Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 3. Terminology 111 For the purpose of this service, we provide the following 112 terminologies: 114 CCBS: Completion of Calls to Busy Subscribers 116 CCNR: Completion of Calls on No Reply 118 CCBS/CCNR service duration timer: maximum time the CCBS/CCNR request 119 will remain activated for the caller within the network. 121 Call-completion call: a call from the call-completion user to the 122 call-completion target, triggered as a result of the execution of a 123 call completion service. 125 Call-completion queue: a buffer at the callee which queues 126 automatically not answered calls due to busy or no reply. 128 Callee: called user, busy when the first call arrives, target of the 129 cal-completion call. 131 Callee Monitor: 133 Caller Agent: 135 Caller: calling user, encounters a busy callee at the first call, 136 initiator of the call-completion call. 138 Retain option: a characteristic of the call-completion service; if 139 supported, call-completion calls which again encounter a busy callee 140 will not be queued again, but the position of the caller's entry in 141 the queue is retained. 143 4. Overview 145 The call-completion architecture augments each caller's UA (or UAC) 146 which wishes to be able to use the call-completion features with with 147 a "call-completion agent" (also written as "CC agent", "agent", or 148 "caller's agent"). It augments each callee's UA (or UAS) which 149 wishes to be able to be the target of the call-completion features 150 with a "call-completion monitor" (also written as "CC monitor", 151 "monitor", or "callee's monitor"). The caller's agent subscribes to 152 the call-completion event package[RFC3265] of the callee's monitor in 153 order to coordinate with the monitor (and indirectly with other 154 callee's monitors) to implement the call-completion features. 156 When the caller's UA makes a call to a callee that fails (e.g., 157 because the callee was busy or the callee did not answer), and the 158 caller wishes to use CC to contact the callee later, the caller 159 instructs the caller's agent to activate the CC feature. 161 Note that SIP call-completion does not inherently distinguish "call 162 completion on no reply" (CCNR) from "call completion on busy 163 subscriber" (CCBS), because the network does not need to make a 164 distinction, and given the potential complexity of SIP routing, 165 agents in the network may not be able to. 167 The caller's agent sends a SUBSCRIBE request for the call-completion 168 event package to the original destination URI of the call. This 169 SUBSCRIBE reaches the callee's monitor. The callee's monitor uses 170 the existence of the subscription to know that the caller is 171 interested in using the CC feature in regard to the original call. 172 The monitor keeps a list or queue of failed calls to the callee, and 173 of the caller's agent subscriptions, which indicate the callers that 174 are waiting to use the CC features. 176 When the callee's monitor judges that the user and/or user's UA is 177 available for call-completion, the callee's monitor selects (usually) 178 one caller's agent to be the next caller to execute call-completion 179 to the callee. The callee's monitor sends a call-completion event 180 update to the selected caller's agent telling it to begin execution 181 of call-completion. 183 When the caller's agent receives this update, it calls the caller's 184 UA or otherwise tests whether the caller is available to take 185 advantage of call-completion. If the caller is available, the agent 186 directs the caller's UA to make again the call to the callee. This 187 call is identified as a call-completion call so it can be given 188 precedence in reaching the callee's UA. 190 5. Detailed Description of the Call-Completion Mechanism 192 5.1. Caller's Call-Completion Agent 194 The call-completion architecture augments each caller's UA (or UAC) 195 which wishes to be able to use the call-completion features with with 196 a "call-completion agent". An agent may be associated with more than 197 one UA if it is common that a caller or population of users will be 198 shared between the UAs, and especially if the UAs share an AOR. 200 The caller's agent has a method of monitoring calls made from the 201 UA(s) in order to determine their Call-Id's and (potentially) their 202 final response statuses. This may be achieved by subscribing to the 203 dialog event package of the UA(s) or by other means. 205 The callers using the UA(s) can indicate to the caller's agent when 206 they wish to avail themselves of CC for a recently-made call which 207 failed to reach their chosen destination. This may be achieved by an 208 INVITE to a special URI which is routed to the caller's agent or by 209 other means. 211 The caller's agent has a method of monitoring the status of the UA(s) 212 to determine when they are available to be used for a CC call. This 213 may be achieved by subscribing to the dialog event package of the 214 UA(s) or by other means. 216 The caller's agent can communicate to the UA(s) that CC has become 217 active and to inquire if the relevant calling user is available for 218 the CC call. This may be achieved by sending an INVITE to the UA(s) 219 or by other means. 221 The caller's agent can order the UA(s) at which the relevant calling 222 user is available to generate a CC call to the callee. This may be 223 achieved by sending a REFER to the UA(s) or by other means. 225 5.2. Callee's Call-Completion Monitor 227 The call-completion architecture augments callee's UA (or UAS) which 228 wishes to be able to be the target of the call-completion features 229 with a "call-completion monitor". A monitor may be associated with 230 more than one UA if it is common that a callee or population of users 231 will be shared between the UAs, and especially if the UAs share an 232 AOR. 234 The callee's monitor has a method of monitoring calls made to the 235 UA(s) in order to determine their Call-Id's and (potentially) their 236 final response statuses. This may be achieved by subscribing to the 237 dialog event package of the UA(s) or by other means (e.g., by 238 communication with the UA's "home proxy"). 240 The callee's using the UA(s) may be able to indicate to the callee's 241 monitor when they wish to receive CC calls. This may be achieved by 242 an INVITE to a special URI which is routed to the callee's monitor or 243 by other means. 245 The callee's monitor has a method of monitoring the status of the 246 UA(s) to determine when they are in a suitable state to receive a CC 247 call. This state may vary depending on the type of CC call in 248 question. E.g., a UA is available for CCBS when it is not busy, but 249 a UA is available for CCNR when it becomes not busy after being busy 250 with an established call. This monitoring may be achieved by 251 subscribing to the dialog event package of the UA(s) or by other 252 means. 254 The callee's monitor maintains information about the set of INVITEs 255 that have been received by the UA(s) that did not obtain successful 256 final responses. In practice, the monitor may remove knowledge about 257 an incoming dialog from its set if its CC policy establishes that the 258 dialog is no longer eligible for CC. 260 5.3. The Original Call Is Made 262 The caller's UA sends an INVITE to a request URI. One or more forks 263 of this request reach one or more of the callee's UAs. By 264 hypothesis, none of the callee's UAs returns a success response, as 265 otherwise, call completion services would not be needed for this 266 call. However, the caller's INVITE might succeed at some other UA 267 that the calling user considers insufficient to satisfy his needs. 268 E.g., a call that is not answered by the callee user may connect to 269 the callee user's voicemail server. Eventually, the INVITE fails, or 270 the resulting dialog(s) are terminated. Note that the Call-Id of the 271 INVITE is a unique identifier of this call attempt. 273 The caller's agent records the request URI, the Call-Id, and possibly 274 the final request status that the caller's UA received. The callee's 275 monitor records the Call-Id and possibly the final request status(es) 276 returned by the callee's UA(s). 278 Note that the caller's UA may not receive any response from any of 279 the callee's UA(s), as the final response returned to the caller's UA 280 may have been from a fork that reached a UA that was not the 281 callee's. 283 5.4. Call-Completion Is Invoked 285 The calling user indicates to the caller's agent that he wishes to 286 invoke call-completion services on the recent call. Note that from 287 the SIP point of view, the INVITE may be successful, but from the 288 user's point of view, the call may be unsuccessful. E.g., the call 289 may have connected to the callee's voicemail, which would return a 290 200 status to the INVITE but from the caller's point of view is "no 291 reply". 293 Question: At this point, it seems that the best choice is that the 294 caller's agent need not determine what type of CC is being requested 295 (CCNR vs. CCBS), as (1) it cannot determine this from the INVITE 296 final response, (2) it would be a burden to make the calling user to 297 specify it, and (3) the callee's monitor can determine this from the 298 responses returned by the callee's UAs. 300 The caller's agent subscribes to the call-completion event package 301 using the request URI of the original call. This SUBSCRIBE should be 302 routed in much the same way as the original INVITE, but ultimately 303 being routed not to the callee's UAs but to the callee's monitor. 304 The Event header of the subscribe specifies the call-completion event 305 package with a parameter call_id={Call-Id of the original call}. 307 Question: Should the specification of the original call be done in 308 the SUBSCRIBE body rather than in an event-param? 310 The SUBSCRIBE should have headers to optimize its routing. In 311 particular, it should contain "Request-Disposition: parallel, no- 312 cancel", and an Accept-Contact header to eliminate callee UAs that 313 are not acceptable to the calling user. 315 The callee's monitor(s) that receive the SUBSCRIBE establish 316 subscriptions. These subscriptions represent the caller's agent's 317 request for call-completion services. The callee's monitor must be 318 prepared to receive multiple forks of a single SUBSCRIBE, and should 319 respond 482 (Merged Request) to all but one fork. The callee's 320 monitor must be prepared to receive SUBSCRIBEs regarding original 321 calls that it has no knowledge of, and should respond 404 (Not Found) 322 to such SUBSCRIBEs. The monitor may apply additional restrictions as 323 to which caller's agents may subscribe. 325 The caller's agent must be prepared to receive multiple responses to 326 the SUBSCRIBE and to have multiple subscriptions established. The 327 agent must also be prepared to have the SUBSCRIBE fail, in which 328 case, CC cannot be invoked for this original call. 330 The call-completion event package returns various information to the 331 caller's agent, but the vital datum is that it contains an indication 332 whether the callee's monitor has chosen the caller's agent to perform 333 the next CC call to the callee. This datum is initially false. 335 5.5. The Call-Completion Request Is Queued 337 The continuation of the caller's agent's subscription indicates that 338 the caller's agent is prepared to initiate the CC call when it is 339 selected by the callee's monitor. If the caller's agent becomes 340 unwilling to initiate the CC call (e.g., because the calling user has 341 deactivated CC or because the caller's UA becomes busy), the caller's 342 agent must terminate or suspend the subscription(s). (Currently, no 343 method of suspending a subscription is defined.) If the caller's 344 agent later becomes willing again to initiate CC for the original 345 call, it may resume the suspended subscription(s) or initiate new 346 one(s). 348 If the callee's monitor becomes aware that, according to its policy, 349 the original call referenced by a subscription will never be selected 350 for call-completion, it should terminate the subscription. (And 351 respond to any attempt to start a new subscription for that original 352 call with 404.) 354 5.6. Call-Completion Is Activated 356 The callee's monitor has a policy regarding when and how it selects 357 CC requests to be activated. This policy may take into account the 358 type of the requests (CCNR vs. CCBS), the state of the callee's 359 UA(s), the order in which the original calls arrived, and any 360 previous CC attempts for the same original call. Usually the 361 callee's monitor will choose only one CC request for activation at a 362 time, but if the callee's UA(s) can support multiple calls, it may 363 choose more than one. 365 The callee's monitor changes the "call completion active" datum for 366 the chosen caller's agent from false to true. This triggers a 367 notification for the agent's subscription. 369 The agent receives the notification with the CC active datum set to 370 true. It then terminates or suspends all other CC subscriptions for 371 this original call, and all CC subscriptions for all other original 372 calls, in order to prevent any other CC requests from this caller 373 from being activated. The agent then determines whether the calling 374 user is available for the CC call, usually by calling the caller's 375 UA(s). 377 If the calling user is not available, the caller's agent indicates 378 this to the callee's monitor by terminating the CC subscription. 380 If the calling user is available, the caller's agent causes the 381 caller's UA to initiate a call to the request URI (which is expected 382 to be routed to the callee's UA(s)). 384 Question: Should the callee's monitor supply a URI which should be 385 used in the CC call? This seems like it would be more reliable, as 386 the monitor is probably "for" a particular callee URI, and it has no 387 information about the destinations of any other forks of the original 388 call. 390 Question: The CC must be marked in some way as a CC call in order for 391 the callee's monitor to know that the CC activation is being acted 392 upon by the caller's agent. And the marking must include the 393 original Call-Id to allow correlation with the original call. 394 Possibilities for a marking are a special URI-parameter on the 395 request URI or a special header. 397 The callee's UA(s) and any associated proxies may give the CC call 398 precedence over non-CC calls. 400 The callee's monitor supervises the receiving of the CC call. If the 401 CC call does not arrive at the callee's UA(s) promptly, the monitor 402 will withdraw CC activation from the caller's agent by changing the 403 value of its CC active datum to false. Similarly, if the CC call 404 fails, the monitor will withdraw CC activation. Depending on its 405 policy, the same original call may be selected again for CC 406 activation at a later time. If the CC call succeeds, the monitor 407 will also withdraw CC activation, but the original call will never 408 again be selected for CC activation (and in practice, can be deleted 409 from the monitor's records). 411 Question: Is that last statement true? Can a call appear to succeed 412 from the monitor's point of view but fail from the calling user's 413 point of view? 415 Once the CC call has failed, or if it has succeeded, once the CC call 416 has been terminated, the callee's monitor's policy may select another 417 CC request for activation. 419 5.7. Data Provided in the Call-Completion Event Package 421 Question: What format should the event package data be presented in? 422 This draft proposes a simple attribute-value format. We might also 423 consider yet another XML format. 425 The only necessary information to be provided by the call-completion 426 event package is the CC activation datum, whose value is false 427 (meaning that this CC request has not been chosen for activation) or 428 true (meaning that it has). 430 Question: If we decide to let the callee's monitor provide the 431 request URI for the CC call, that request URI should probably be a 432 mandatory datum as well. 434 The event package may provide information about the callee's 435 monitor's policy. In particular, the PSTN CC feature gives an 436 indication of the "service retention" attribute, which indicates 437 whether the CC request can be continued to a later time if the call- 438 completion call fails due to the callee's UA(s) being busy. 440 If the callee has a caller-queuing facility, we want to treat the 441 call-completion queue as part of the queuing facility, and include in 442 the event package information regarding the state of the queue, such 443 as number of callers ahead of this caller and expected wait time. In 444 that case, this data should probably not trigger a notification every 445 time it changes, but rather at suitable time increments. 447 6. Call Completion Event Package 449 This section fills in the details needed to specify a possible call- 450 completion event package, in accordance with section 4.4 of 451 [RFC3265]. 453 6.1. Event Package Name 455 The SIP Events specification requires package definitions to specify 456 the name of their package or template-package. The name of this 457 package is "call-completion". As specified in [RFC3265], this value 458 appears in the Event and Allow-events header fields. 460 6.2. Event Package Parameters 462 No package specific Event header parameters are defined for this 463 event package. 465 6.3. SUBSCRIBE Bodies 467 [RFC3265] requires package definitions to define the usage, if any, 468 of bodies in SUBSCRIBE requests. A SUBSCRIBE request for a call- 469 completion package MAY contain a body. This body defines a filter to 470 be applied to the subscription. Filter documents are not specified 471 in this document. 473 The SUBSCRIBE request MAY contain an Accept header field. If no such 474 header field is present, it has a default value of "application/ 475 call-completion". If the header field is present, it MUST include 476 "application/call-completion". 478 6.4. Subscribe Duration 480 [RFC3265] requires package definitions to define a default value for 481 subscription durations, and to discuss reasonable choices for 482 durations when they are explicitly specified. 484 It is recommended to set the default duration of subscriptions to 485 call completion events to a value higher than 3600 seconds which 486 corresponds to the highest timer value recommended for the call 487 completion services in ETSI and ITU-T. The duration of the 488 subscription is also coupled to the remaining duration of a queue 489 entry. This means in case of resuming a subscription the resulting 490 duration will be less than 3600 seconds. 492 6.5. NOTIFY Bodies 494 [RFC3265] requires package definitions to describe the allowed set if 495 body types in NOTIFY requests, and to specify the default value to be 496 used when there is no Accept header field in the SUBSCRIBE request A 497 NOTIFY for a call-completion package MUST contain a body that 498 describes the call-completion states. 500 As described in [RFC3265], the NOTIFY message will contain bodies 501 that describe the state of the subscribed resource. This body is in 502 a format listed in the Accept header field of the SUBSCRIBE, or in a 503 package-specific default format if the Accept header field was 504 omitted from the SUBSCRIBE. 506 In this event package, the body of the notification contains a call- 507 completion document. All subscribers and notifiers MUST support the 508 "application/call-completion" data format described in section 8. 509 The SUBSCRIBE request MAY contain an Accept header field. If no such 510 header field is present, it has a default value of "application/ 511 call-completion". If the header field is present, it MUST include 512 "application/call-completion". This "application/call-completion" 513 data format is described in chapter 8. Of course, the notifications 514 generated by the server MUST be in one of the formats specified in 515 the Accept header field in the SUBSCRIBE request. 517 6.6. Subscriber Generation of SUBSCRIBE Requests 519 Subscribers MUST generate SUBSCRIBE requests when they want to 520 subscribe to the call-completion event package at the terminating 521 side in order to receive call-completion notifications. The 522 generation of SUBSCRIBE requests MAY imply the usage of call- 523 completion service specific timers. An example of such an 524 implementation can be found in ETSI TS 183 042. 526 6.7. Notifier Processing of SUBSCRIBE Requests 528 Upon receiving a subscription refresh, the notifier MUST set the 529 "expires" parameter of the Subscription-State header to the current 530 remaining duration of the subscription regardless of the value 531 received in the Expires header (if present) of the subscription 532 refresh. 534 If a subscription is not successful because the call-completion queue 535 has reached the maximum number of entries (short term denial), the 536 notifier MUST send a 480 Temporarily Unavailable response to the 537 subscriber. If a subscription is not successful because a general 538 error that prevents the call-completion service has occurred (long 539 term denial), the notifier MUST send a 403 Forbidden response to the 540 subscriber. 542 The call-completion information can be sensitive. Therefore, all 543 subscriptions SHOULD be authenticated and then authorized before 544 approval. The call-completion event package specified in this 545 document is intended to be used in private domains (e.g. IMS) where 546 authentication and authorization are provided via means out of scope 547 of this document. 549 6.8. Notifier Generation of NOTIFY Requests 551 Notifiers MUST generate NOTIFY requests when a call-completion 552 service condition occurs at the terminating side that needs to be 553 sent towards the originating side. 555 A NOTIFY sent as a confirmation of the initial subscription or of a 556 subscription refresh MUST contain the "call-completion-state" 557 parameter set to "queued" if the user is busy and the call-completion 558 subscription was successful (i.e. initial call-completion 559 subscription, or a call-completion subscription for resume reasons) 560 and to "ready-for-call-completion" if the call-completion target is 561 not busy. 563 A NOTIFY sent as a confirmation of a request to unsubscribe MAY 564 contain the "call-completion-state" parameter. 566 When the callee's status changes from busy to not busy, the notifier 567 MUST send a NOTIFY only to first queue entry with an active 568 subscription. This NOTIFY MUST contain the "call-completion-state" 569 parameter set to "ready-for-call-completion". 571 If the call-completion subscription was successful and the retention 572 option is supported at the callee, the NOTIFY MUST contain the 573 "retention-option" parameter. 575 6.9. Subscriber Processing of NOTIFY Requests 577 The subscriber processing of NOTIFY requests MAY trigger additional 578 CCBS service procedures (e.g. CCBS recall, usage of CCBS timers?). 579 An example of such procedures can be found in ETSI TS 183 042. 581 6.10. Handling of Forked Requests 583 The SIP Events framework mandates that packages indicate whether or 584 not forked SUBSCRIBE requests can install multiple subscriptions. 585 Forked requests are NOT ALLOWED for the call completion event type. 587 6.11. Rate of Notifications 589 [RFC3265] mandates that packages define a maximum rate of 590 notifications for their package. The call completion service 591 typically involves a single notification per notifier and per 592 subscription but MAY involve several notifications separated by a 593 call completion call that failed due to a busy call completion 594 target. 596 6.12. State Agents 598 [RFC3265] asks packages to consider the role of state agents in their 599 design. State agents have no role in the handling of the call 600 completion package. 602 7. Security Considerations 604 The use of the CC facility allows the caller's agent to determine 605 some status information regarding the callee. The information is 606 confined to a busy/not-busy indication, and is to a considerable 607 degree protected by the necessity of presenting the Call-Id of a 608 recent call to the callee in order to obtain information. 610 The CC facility may enhance the effectiveness of SPIT by the 611 following technique: The caller makes calls to a group of targets. 612 The caller then requests CC for the calls that do not connect to the 613 targets. The CC calls resulting are probably more likely to reach 614 the targets than original calls to a further group of targets. 616 8. IANA Considerations 618 This specification registers an event package, based on the 619 registration procedures defined in . The followings is the 620 information required for such a registration: 622 Package Name: call-completion 624 Package or Template-Package: This is a package. 626 Published Document: RFC XXXX(Note for RFC Editor: Please fill in XXXX 627 with the RFC number of this specification). 629 Person to Contact: Martin Huelsemann, martin.huelsemann@t-com.net 631 9. References 633 9.1. Normative References 635 [I-D.ietf-sip-gruu] 636 Rosenberg, J., "Obtaining and Using Globally Routable User 637 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 638 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 639 October 2007. 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 645 A., Peterson, J., Sparks, R., Handley, M., and E. 646 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 647 June 2002. 649 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 650 Event Notification", RFC 3265, June 2002. 652 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 653 Method", RFC 3515, April 2003. 655 [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- 656 Initiated Dialog Event Package for the Session Initiation 657 Protocol (SIP)", RFC 4235, November 2005. 659 9.2. Informative References 661 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 662 Preferences for the Session Initiation Protocol (SIP)", 663 RFC 3841, August 2004. 665 Authors' Addresses 667 Dale R. Worley 668 Pingtel Corp. 669 10 North Ave. 670 Burlington, MA 01803 671 US 673 Phone: +1 781 229 0533 x173 674 Email: dworley@pingtel.com 675 URI: http://www.pingtel.com 677 Martin Huelsemann 678 Deutsche Telekom 679 Deutsche-Telekom-Allee 1 680 Darmstadt 64307 681 Germany 683 Email: martin.huelsemann@t-com.net 685 Denis Alexeitsev 686 Deutsche Telekom 687 Deutsche-Telekom-Allee 1 688 Darmstadt 64307 689 Germany 691 Email: d.alexeitsev@t-com.net 693 Full Copyright Statement 695 Copyright (C) The IETF Trust (2008). 697 This document is subject to the rights, licenses and restrictions 698 contained in BCP 78, and except as set forth therein, the authors 699 retain all their rights. 701 This document and the information contained herein are provided on an 702 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 703 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 704 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 705 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 706 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 707 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 709 Intellectual Property 711 The IETF takes no position regarding the validity or scope of any 712 Intellectual Property Rights or other rights that might be claimed to 713 pertain to the implementation or use of the technology described in 714 this document or the extent to which any license under such rights 715 might or might not be available; nor does it represent that it has 716 made any independent effort to identify any such rights. Information 717 on the procedures with respect to rights in RFC documents can be 718 found in BCP 78 and BCP 79. 720 Copies of IPR disclosures made to the IETF Secretariat and any 721 assurances of licenses to be made available, or the result of an 722 attempt made to obtain a general license or permission for the use of 723 such proprietary rights by implementers or users of this 724 specification can be obtained from the IETF on-line IPR repository at 725 http://www.ietf.org/ipr. 727 The IETF invites any interested party to bring to its attention any 728 copyrights, patents or patent applications, or other proprietary 729 rights that may cover technology that may be required to implement 730 this standard. Please address the information to the IETF at 731 ietf-ipr@ietf.org. 733 Acknowledgment 735 Funding for the RFC Editor function is provided by the IETF 736 Administrative Support Activity (IASA).