idnits 2.17.1 draft-poetzl-bliss-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1012. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1026. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1035. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1041. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 10) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 360: '...mpletion package MAY contain a body. ...' RFC 2119 keyword, line 363: '...UBSCRIBE request MAY contain an Accept...' RFC 2119 keyword, line 366: '... MUST include "application/call-com...' RFC 2119 keyword, line 389: '...mpletion package MUST contain a body t...' RFC 2119 keyword, line 399: '...t. All subscribers and notifiers MUST...' (20 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 217 has weird spacing: '...at this time,...' == Line 516 has weird spacing: '... where prox...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '1' is defined on line 877, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 887, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 893, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 898, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 905, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '2') (Obsoleted by RFC 6665) -- Unexpected draft version: The latest known version of draft-jesske-sipping-tispan-analysis is -00, but you're referring to -03. Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Joachim Poetzl 3 Internet Draft Martin Huelsemann 4 Expires: December 2007 Deutsche Telekom 5 Intended Status: Proposed Standard Jean-Marie Stupka 6 Siemens 8 Extensions to the Session Initiation Protocol (SIP) for the support 9 of the Call Completion Services for the 10 European Telecommunications Standards Institute, 11 draft-poetzl-bliss-call-completion-00 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other 27 documents at any time. It is inappropriate to use Internet-Drafts 28 as reference material or to cite them other than as "work in 29 progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 6, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2007). 43 Abstract 45 This document specifies the extensions to the Session Initiation 46 Protocol (SIP) for the call completion services. Therefore this 47 document describes a SIP event package that enables subscribing to 48 call-completion states. Furthermore this document extends the 49 usage of the Allows-events header field to 180 Ringing and 486 Busy 50 responses. 52 Table of Contents 53 Status of this Memo.........................................1 54 Abstract..................................................1 55 Table of Contents..........................................2 56 1. Terminology.............................................3 57 2. Definitions.............................................3 58 3. Overview................................................3 59 4. Requirements motivating SIP extensions in support of call- 60 completion services.........................................4 61 4.1 Reception of call-completion information ..................4 62 4.2 Call-completion possible indication.......................5 63 5. Solution................................................5 64 5.1 Proposed solution.......................................5 65 5.2 Possible other solutions.................................6 66 6. Call Completion event package.............................7 67 6.1 Event Package Name......................................7 68 6.2 Event Package Parameters.................................7 69 6.3 SUBSCRIBE Bodies........................................7 70 6.4 Subscription Duration...................................8 71 6.5 NOTIFY Bodies..........................................8 72 6.6 Subscriber Generation of SUBSCRIBE requests................8 73 6.7 Notifier Processing of SUBSCRIBE Requests..................9 74 6.8 Notifier Generation of NOTIFY Requests....................9 75 6.9 Subscriber Processing of NOTIFY Requests .................10 76 6.10 Handling of Forked Requests............................10 77 6.11 Rate of Notifications.................................10 78 6.12 State Agents.........................................10 79 6.13 Handling of the Allow-Events Header.....................10 80 7. Call-completion information format........................11 81 7.1 call-completion-state..................................11 82 7.2 service-retention......................................11 83 8. Signaling Flows ........................................13 84 9. Security Considerations.................................19 85 10. IANA Considerations....................................19 86 10.1 SIP Event Package Registration .........................19 87 11. References............................................19 88 11.1 Normative References..................................19 89 11.2 Informative References ................................19 90 12. Contributors..........................................20 91 13. Authors' Addresses.....................................21 92 14. Acknowledgments........................................22 93 15. Full Copyright Statement................................22 94 16. Intellectual Property..................................22 95 17. Acknowledgment ........................................23 96 Terminology 98 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 99 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 100 and "OPTIONAL" are to be interpreted as described in RFC 2119 [9] 101 and indicate requirement levels for compliant implementations. 103 2. 104 Definitions 106 For the purpose of this service, we provide the following 107 definitions: 109 CCBS: Completion of Calls to Busy Subscribers 111 CCNR: Completion of Calls on No Reply 113 CCBS/CCNR service duration timer: maximum time the CCBS/CCNR 114 request will remain activated for the caller within the network. 116 Call-completion call: a call from the call-completion user to the 117 call-completion target, triggered as a result of the execution of a 118 call completion service. 120 Call-completion queue: a buffer at the callee which queues 121 automatically not answered calls due to busy or no reply. 123 Callee: called user, busy when the first call arrives, target of 124 the cal-completion call. 126 Caller: calling user, encounters a busy callee at the first call, 127 initiator of the call-completion call. 129 Retain option: a characteristic of the call-completion service; if 130 supported, call-completion calls which again encounter a busy 131 callee will not be queued again, but the position of the caller's 132 entry in the queue is retained 134 3. 135 Overview 137 The Completion of Calls to Busy Subscriber (CCBS) and the 138 Completion of Calls on no Reply (CCNR) services are very similar in 139 nature, thus we describe requirements and solutions for both 140 services at the same time. 142 Completion of Calls to Busy Subscriber (CCBS) provides the cability 143 to queue not answered calls from several callers to a busy callee 144 and to inform the caller that he can initiate a call-completion 145 call after the callee has become not busy. 147 Completion of Calls on no Reply (CCNR) provides the cability to 148 queue not answered calls from several callers to a callee and to 149 inform the caller that he can initiate a call-completion call after 150 the callee has become not busy after having initiated an activity. 152 A not answered call automatically results in an entry in a call- 153 completion queue. The caller then has the possibility to decide if 154 he wants to receive information about his cal-completion queue 155 state. 157 Usually call-completion queues are organized on a FIFO basis and 158 limited in the number of entries, and a queue entry is temporary. 159 If a queue entry reaches the top of the queue, it will be allowed 160 to establish a call-completion call when the callee is available, 161 and the caller is informed accordingly. A queue entry will be 162 deleted when it matures or when the caller successfully has 163 established a call-completion call to the callee. 165 If a call-completion call cannot be answered (e.g. the callee has 166 become busy again in the meantime), it depends on the service logic 167 if the caller keeps his position in the queue, or if his current 168 queue entry is deleted and a new queue entry for him is added. 170 4. 171 Requirements motivating SIP extensions in support of call- 172 completion services 174 This section collects the CCBS/CCNR services requirements that 175 cannot be fulfilled with existing SIP capabilities. 177 4.1 178 Reception of call-completion information 180 The CCBS and CCNR services require the capability to receive 181 information of the caller's call-completion state. This includes 182 the requirement that the caller can indicate that he is willing to 183 receive these information. 185 The call-completion state results from the user's position in a 186 call-completion queue. A new entry for a caller in the queue is in 187 the 'queued' state. If a queue entry reaches the top of the queue, 188 the caller will be informed that he can establish a call-completion 189 call when the callee is available. In this case the state of the 190 caller changes from 'queued' to 'ready-for-call-completion' and the 191 caller will be informed accordingly. 193 The realization of call-completion services includes also 194 suspending and resuming of receiving call-completion information, 195 which gives the caller the possibility to pause receiving those 196 information without loosing his position in the queue. 198 Suspending a call-completion request occurs when the caller is not 199 available for starting a call-completion call (i.e., the caller is 200 busy) but wishes to retain the position of his entry on the call- 201 completion queue in anticipation of making the call-completion call 202 later. 204 Resuming a call-completion request occurs when the condition that 205 led to suspension has been removed (i.e., the caller is free 206 again). 208 For the case that his call-completion call fails, the caller needs 209 to be informed, if the position of his entry in the queue will 210 remain the same, or if his entry will be deleted and a new entry 211 will be added to the queue. This retention information is also 212 needed for the interworking with the PSTN, where both possibilities 213 exist. 215 For the case that a caller indicates that he is willing to receive 216 information about his call-completion state, but it is not possible 217 to provide the caller with this information at this time, it is 218 required to inform the caller about the denial reasons, which can 219 be a short term denial if the call-completion queue has reached its 220 limit, or a long term denial if a general error that prevents the 221 call-completion service has occurred. 222 The information about the denial reason is also required for the 223 interworking with the PSTN, especially information about a short 224 term denial results from this interworking because of different 225 call-completion procedures in the PSTN, where a user is only added 226 to the call-completion queue when he has requested it. 228 4.2 229 Call-completion possible indication 231 In order to ensure that end-to-end functionality of the call- 232 completion services is possible, there must be an indication to the 233 caller during the attempted call establishment that call-completion 234 information are available. 236 5. 237 Solution 239 5.1 240 Proposed solution 242 The Session Initiation Protocol (SIP) event framework is described 243 in RFC 3265 [2]. It defines a generic framework for subscription 244 to, and notification of, events related to SIP systems. The 245 framework defines the methods SUBSCRIBE and NOTIFY, and introduces 246 the notion of a package. A package is a concrete application of 247 the event framework to a particular class of events. 249 This document defines in section 7 a new SIP event package (call- 250 completion event package) that enables subscribing to call- 251 completion states. After being queued automatically, a caller can 252 subscribe to a call-completion queue at a busy callee and receives 253 notifications if he is still queued or if he can establish a call- 254 completion call. The caller is also notified if the retention 255 option is supported at the callee. 257 After a successful subscription to the call-completion event 258 package using the SIP SUBSCRIBE request, relevant changes in the 259 call-completion state associated with the subscription are reported 260 to the subscriber by means of the SIP NOTIFY requests, in 261 accordance with the procedures described in RFC 3265 [2]. A NOTIFY 262 request that reports that the callee is available for a call- 263 completion call attempt to be made will cause the subscriber to 264 trigger the establishment of that call, subject to the caller being 265 available too. 267 The SUBSCRIBE method is also used to suspend and to resume the 268 subscription. Suspending is accomplished by using the 269 Unsubscribing procedures, resuming is done by using the Subscribing 270 procedures, as described in subclause 3.1.4 of RFC 3265 [2]. It is 271 assumed that the call-completion service logic can distinguish 272 between a new subscription and a resuming subscription, when there 273 is an entry for the subscriber in the call completion queue. 274 For a correlation between a suspended subscription and a new 275 subscription, procedures according to draft-ietf-sip-subnot-etags- 276 00.txt may be used. 278 Furthermore the present document specifies the usage of the Allow- 279 events header field for the realization of call-completion 280 services. 282 The possibility to subscribe to the call-completion event package 283 in case of CCBS is indicated by including the Allow-Events Header 284 field (Allow-Events:call-completion) in a 486 Busy response. 286 The possibility to subscribe to the call-completion event package 287 in case of CCNR is indicated by including the Allow-Events Header 288 field (Allow-Events:call-completion) in a 180 Ringing response. 290 This enables the recipient of the 180 or 486 messages to identify 291 that the remote server is capable of receiving a subscription for 292 call-completion events associated with the INVITE transaction. 294 Although RFC 3265 section 3.3.7 indicates that a node 295 implementing an event package should indicate this in all 296 methods which initiate dialogs and their responses, this 297 document recommends restricting the indication to particular 298 responses in order to only match the call-completion possible 299 situations on the destination side. 301 5.2 302 Possible other solutions 304 1) Usage of dialog event packages 305 Different to the call-completion event package, the dialog event 306 package is not intended for call-completion, because 'dialog 307 terminated' does not equal 'ready for recall', and a user might 308 want to receive information about dialog state as well as 309 information about call-completion state. 311 2) BFCP 313 RFC3265 obviously has a much greater implementation basis than 314 BFCP, and because it has much greater implementation basis, the 315 experience in inter-operability etc. is greater. 317 Further, although BFCP may be easy to implement, the state-machine 318 needed for BFCP and its need to exchange information with the SIP 319 state-machine is something that's not very common and hasn't been 320 done too extensively yet. 322 Lastly, RFC3265 is part of the core spec as mentioned in the 323 hitchhiker's guide, so the foundation on which the call-completion 324 is to be implemented is very likely be there to start with. 326 3) HTTP polling 328 HTTP Polling has no way for the server to find out if the message 329 has been delivered (there is no equivalence to a 200 OK to a NOTIFY 330 request), it causes a lot of message exchange and is inefficient as 331 it polls even if there is no change in the status of the queue. 333 6. 334 Call Completion event package 336 This section fills in the details needed to specify an event 337 package as defined in Section 4.4 of RFC 3265 [2]. 339 6.1 340 Event Package Name 342 The SIP Events specification requires package definitions to 343 specify the name of their package or template-package. 345 The name of this package is "call-completion". As specified in RFC 346 3265 [2], this value appears in the Event and Allow-events header 347 fields. 349 6.2 350 Event Package Parameters 352 No package specific Event header parameters are defined for this 353 event package. 355 6.3 356 SUBSCRIBE Bodies 358 RFC 3265 [2] requires package definitions to define the usage, if 359 any, of bodies in SUBSCRIBE requests. A SUBSCRIBE request for a 360 call-completion package MAY contain a body. This body defines a 361 filter to be applied to the subscription. Filter documents are not 362 specified in this document. 363 The SUBSCRIBE request MAY contain an Accept header field. If no 364 such header field is present, it has a default value of 365 "application/call-completion". If the header field is present, it 366 MUST include "application/call-completion". 368 6.4 369 Subscription Duration 371 RFC 3265 [2] requires package definitions to define a default value 372 for subscription durations, and to discuss reasonable choices for 373 durations when they are explicitly specified. 374 It is recommended to set the default duration of subscriptions to 375 call completion events to a value higher than 3600 seconds which 376 corresponds to the highest timer value recommended for the call 377 completion services in ETSI and ITU-T. 378 The duration of the subscription is also coupled to the remaining 379 duration of a queue entry. This means in case of resuming a 380 subscription the resulting duration will be less than 3600 seconds. 382 6.5 383 NOTIFY Bodies 385 RFC 3265 [2] requires package definitions to describe the allowed 386 set if body types in NOTIFY requests, and to specify the default 387 value to be used when there is no Accept header field in the 388 SUBSCRIBE request 389 A NOTIFY for a call-completion package MUST contain a body that 390 describes the call-completion states. 392 As described in RFC 3265 [2], the NOTIFY message will contain 393 bodies that describe the state of the subscribed resource. This 394 body is in a format listed in the Accept header field of the 395 SUBSCRIBE, or in a package-specific default format if the Accept 396 header field was omitted from the SUBSCRIBE. 398 In this event package, the body of the notification contains a 399 call-completion document. All subscribers and notifiers MUST 400 support the "application/call-completion" data format described in 401 section 8. The SUBSCRIBE request MAY contain an Accept header 402 field. If no such header field is present, it has a default value 403 of "application/call-completion". If the header field is present, 404 it MUST include "application/call-completion". This 405 "application/call-completion" data format is described in chapter 406 8. 407 Of course, the notifications generated by the server MUST be in one 408 of the formats specified in the Accept header field in the 409 SUBSCRIBE request. 411 6.6 412 Subscriber Generation of SUBSCRIBE requests 414 Subscribers MUST generate SUBSCRIBE requests when they want to 415 subscribe to the call-completion event package at the terminating 416 side in order to receive call-completion notifications. The 417 generation of SUBSCRIBE requests MAY imply the usage of call- 418 completion service specific timers. An example of such an 419 implementation can be found in ETSI TS 183 042 [9]. 421 6.7 422 Notifier Processing of SUBSCRIBE Requests 424 Upon receiving a subscription refresh, the notifier MUST set the 425 "expires" parameter of the Subscription-State header to the current 426 remaining duration of the subscription regardless of the value 427 received in the Expires header (if present) of the subscription 428 refresh. 430 If a subscription is not successful because the call-completion 431 queue has reached the maximum number of entries (short term 432 denial), the notifier MUST send a 480 Temporarily Unavailable 433 response to the subscriber. 434 If a subscription is not successful because a general error that 435 prevents the call-completion service has occurred (long term 436 denial), the notifier MUST send a 403 Forbidden response to the 437 subscriber. 439 The call-completion information can be sensitive. Therefore, all 440 subscriptions SHOULD be authenticated and then authorized before 441 approval. The call-completion event package specified in this 442 document is intended to be used in private domains (e.g. IMS) where 443 authentication and authorization are provided via means out of 444 scope of this document. 446 6.8 447 Notifier Generation of NOTIFY Requests 449 Notifiers MUST generate NOTIFY requests when a call-completion 450 service condition occurs at the terminating side that needs to be 451 sent towards the originating side. 453 A NOTIFY sent as a confirmation of the initial subscription or of a 454 subscription refresh MUST contain the "call-completion-state" 455 parameter set to "queued" if the user is busy and the call- 456 completion subscription was successful (i.e. initial call- 457 completion subscription, or a call-completion subscription for 458 resume reasons) and to "ready-for-call-completion" if the call- 459 completion target is not busy. 461 A NOTIFY sent as a confirmation of a request to unsubscribe MAY 462 contain the "call-completion-state" parameter. 464 When the callee's status changes from busy to not busy, the 465 notifier MUST send a NOTIFY only to first queue entry with an 466 active subscription. This NOTIFY MUST contain the "call- 467 completion-state" parameter set to "ready-for-call-completion". 469 If the call-completion subscription was successful and the 470 retention option is supported at the callee, the NOTIFY MUST 471 contain the "retention-option" parameter. 473 6.9 474 Subscriber Processing of NOTIFY Requests 476 The subscriber processing of NOTIFY requests MAY trigger additional 477 CCBS service procedures (e.g. CCBS recall, usage of CCBS timers?). 478 An example of such procedures can be found in ETSI TS 183 042 [9]. 480 6.10 481 Handling of Forked Requests 483 The SIP Events framework mandates that packages indicate whether or 484 not forked SUBSCRIBE requests can install multiple subscriptions. 485 Forked requests are NOT ALLOWED for the call completion event type. 487 6.11 488 Rate of Notifications 490 RFC 3265 [2] mandates that packages define a maximum rate of 491 notifications for their package. 493 The call completion service typically involves a single 494 notification per notifier and per subscription but MAY involve 495 several notifications separated by a call completion call that 496 failed due to a busy call completion target. 498 6.12 499 State Agents 501 RFC 3265 [2] asks packages to consider the role of state agents in 502 their design. State agents have no role in the handling of the 503 call completion package. 505 6.13 506 Handling of the Allow-Events Header 508 The Call Completion event package introduces a new Allow-Events 509 header type (Allow-Events:call-completion) to indicate the 510 possibility to activate CCBS or CCNR in a 486 Busy response or 180 511 Ringing response respectively. 513 Two new lines are added to the table in section 7.2 of RFC 3265 514 [2]. 516 Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT 517 ------------------------------------------------------------------- 518 Allow-Events 180 - - - o - - - - - 519 Allow-Events 486 - - - o - - - - - 521 7. 522 Call-completion information format 524 The following syntax specification uses the Augmented Backus-Naur 525 Form (ABNF) as described in RFC 2234. The formal syntax for the 526 application/call-completion MIME type is described below. 528 call-completion = [call-completion-state CLRF] 529 [service-retention CLRF] 531 A description of the above mentioned rules follows. 533 7.1 534 call-completion-state 536 The call-completion-state parameter indicates the call-completion 537 status of a particular user with an entry in a call-completion 538 queue. 540 call-completion-state = "call-completion-state" HCOLON ( 541 "queued" / "ready-for-call-completion" ) 543 8.1.1 queued 545 The value queued indicates that a user has an entry in a call- 546 completion queue, but which has not reached the queue position that 547 enables a call-completion call. 549 8.1.2 ready-for-call-completion 551 The value ready-for-call-completion indicates that a user has an 552 entry in a call-completion queue which has reached the queue 553 position that enables a call-completion call. 555 7.2 556 service-retention 558 The service-retention indicates the support of the retain option. 559 The retain option, if supported at the callee, will maintain the 560 entry in the call-completion queue, if a call-completion call has 561 failed due to destination busy condition. If present, this 562 parameter indicates that the retain option is supported, otherwise 563 it is not supported. This parameter MAY be present in NOTIFY 564 requests. 566 service-retention = "service-retention" 568 8. 569 Signaling Flows 571 Alice Bob Carol 572 | | | 573 | F1 INVITE | | 574 |---------------------------------->| 575 | F2 486 Busy | | 576 |<----------------------------------| 577 | F3 SUBSCRIBE | | 578 |---------------------------------->| 579 | F4 200 OK | | 580 |<----------------------------------| 581 | F5 NOTIFY | | 582 |<----------------------------------| 583 | F6 200 OK | | 584 |---------------------------------->| 585 | | | 586 | | F7 INVITE | 587 | |---------------->| 588 | | F8 486 Busy | 589 | |<----------------| 590 | | F9 SUBSCRIBE | 591 | |---------------->| 592 | | F10 200 OK | 593 | |<----------------| 594 | | F11 NOTIFY | 595 | |<----------------| 596 | | F12 200 OK | 597 | |---------------->| 598 | | | 599 | | Carols hangs up 600 | | | 601 | F13 NOTIFY | | 602 |<----------------------------------| 603 | F14 200 OK | | 604 |---------------------------------->| 605 | F15 INVITE | | 606 |---------------------------------->| 607 | F16 200 OK | | 608 |<----------------------------------| 609 | F17 ACK | | 610 |---------------------------------->| 612 Figure 1: Call completion on busy subscriber signaling flow 614 Figure 1 shows an example for a basic call completion on busy 615 subscriber signaling flow. In this example Alice wants to call 616 Carol, but Carol is already in a call and answers with a 486 Busy 617 response. Alice is added to the call-completion queue at Carol. 618 In order to indicate to Alice that a call-completion notification 619 is possible, she inserts 'Allow-events:call-completion' into the 620 response. Alice subscribes to the call-completion event package at 621 Carol. 622 Bob also encounters the busy status when he calls Carol, so he 623 subscribes to the call-completion event package, too. 624 Then Carol hangs up, and Alice is informed of the call-completion 625 condition and she initiates the call-completion call to Carol. 627 F1 629 INVITE sip:carol@example.org SIP/2.0 630 To: ; 631 From: ;tag=1111 632 Call-ID: 111aaa@phone.example.org 633 CSeq: 1 INVITE 634 Contact: 636 F2 638 SIP/2.0 486 Busy 639 To: ; 640 From: ;tag=1111 641 Call-ID: 111aaa@phone.example.org 642 CSeq: 1 INVITE 643 Contact: 644 Allow-events: call-completion 646 F3 648 SUBSCRIBE sip:carol@example.org SIP/2.0 649 To: ; 650 From: ;tag=2222 651 Call-ID: 123456@phone.example.org 652 CSeq: 1 SUBSCRIBE 653 Contact: 654 Event: call-completion 655 Expires: 3601 657 F4 659 SIP/2.0 200 OK 660 To: ;tag=3333 661 From: ;tag=2222 662 Call-ID: 123456@phone.example.org 663 CSeq: 1 SUBSCRIBE 664 Contact: 665 Expires: 3601 666 F5 668 NOTIFY sip:alice@example.org SIP/2.0 669 To: ;tag=3333 670 From: ;tag=2222 671 Call-ID: 123456@phone.example.org 672 CSeq: 1 NOTIFY 673 Contact: 674 Event: call-completion 675 Subscription-state: active 677 call-completion-state: queued 679 F6 681 SIP/2.0 200 OK 682 To: ;tag=3333 683 From: ;tag=2222 684 Call-ID: 123456@phone.example.org 685 CSeq: 1 NOTIFY 686 Contact: 688 F13 690 NOTIFY sip:alice@example.org SIP/2.0 691 To: ;tag=3333 692 From: ;tag=2222 693 Call-ID: 123456@phone.example.org 694 CSeq: 2 NOTIFY 695 Contact: 696 Event: call-completion 697 Subscription-state: active 699 call-completion-state: ready-for-call-completion 701 F14 703 SIP/2.0 200 OK 704 To: ;tag=3333 705 From: ;tag=2222 706 Call-ID: 123456@phone.example.org 707 CSeq: 2 NOTIFY 708 Contact: 709 F15 711 INVITE sip:carol@example.org SIP/2.0 712 To: ; 713 From: ;tag=4444 714 Call-ID: 222bbb@phone.example.org 715 CSeq: 1 INVITE 716 Contact: 718 F16 720 SIP/2.0 200 OK 721 To: ;tag=5555 722 From: ;tag=4444 723 Call-ID: 222bbb@example.org 724 CSeq: 1 INVITE 725 Contact: 727 Bob Carol 728 | F18 SUBSCRIBE | 729 |----------------->| 730 | F19 200 OK | 731 |<-----------------| 732 | F20 NOTIFY | 733 |<-----------------| 734 | F21 200 OK | 735 |----------------->| 736 | | 737 | F22 SUBSCRIBE | 738 |----------------->| 739 | F23 200 OK | 740 |<-----------------| 741 | F24 NOTIFY | 742 |<-----------------| 743 | F25 200 OK | 744 |----------------->| 746 Figure 2: Call completion suspend/resume procedures 748 If Bob wants to suspend his call completion subscription for a 749 certain time (because e.g. he is busy), he terminates the 750 subscription according to the procedures described in subclause 751 3.3.4 of RFC 3265 [2]. When Bob wants to resume the call- 752 completion activation, he subscribes again to the call-completion 753 event package. 755 The suspend/resume procedures are shown in figure 2. Note the 756 suspending a subscription doesn't change the position of the call- 757 completion queue entry of the subscriber. Note also that in 758 Carol's responses to Bob's subscriptions the Expires-header field 759 is set to the current remaining duration of Bob's queue entry 760 regardless of the value received in the Expires header field of 761 Bob's subscription. 763 F18 765 SUBSCRIBE sip:carol@example.org SIP/2.0 766 To: ;tag=8888 767 From: ;tag=7777 768 Call-ID: 654321@phone.example.org 769 CSeq: 2 SUBSCRIBE 770 Contact: 771 Event: call-completion 772 Expires: 0 774 F19 776 SIP/2.0 200 OK 777 To: ;tag=8888 778 From: ;tag=7777 779 Call-ID: 654321@phone.example.org 780 CSeq: 2 SUBSCRIBE 781 Contact: 783 F20 785 NOTIFY sip:bob@example.org SIP/2.0 786 To: ;tag=8888 787 From: ;tag=7777 788 Call-ID: 654321@phone.example.org 789 CSeq: 2 NOTIFY 790 Contact: 791 Event: call-completion 792 Subscription-state: terminated 794 F21 796 SIP/2.0 200 OK 797 To: ;tag=8888 798 From: ;tag=7777 799 Call-ID: 654321@phone.example.org 800 CSeq: 2 NOTIFY 801 Contact: 802 F22 804 SUBSCRIBE sip:carol@example.org SIP/2.0 805 To: ;tag=8888 806 From: ;tag=7777 807 Call-ID: 654321@phone.example.org 808 CSeq: 3 SUBSCRIBE 809 Contact: 810 Event: call-completion 811 Expires: 3601 813 F23 815 SIP/2.0 200 OK 816 To: ;tag=8888 817 From: ;tag=7777 818 Call-ID: 654321@phone.example.org 819 CSeq: 3 SUBSCRIBE 820 Contact: 821 Expires: 1400 823 F24 825 NOTIFY sip:bob@example.org SIP/2.0 826 To: ;tag=8888 827 From: ;tag=7777 828 Call-ID: 654321@phone.example.org 829 CSeq: 3 NOTIFY 830 Contact: 831 Event: call-completion 832 Subscription-state: active 834 call-completion-state=queued] 836 F25 838 SIP/2.0 200 OK 839 To: ;tag=8888 840 From: ;tag=7777 841 Call-ID: 654321@phone.example.org 842 CSeq: 3 NOTIFY 843 Contact: 845 9. 846 Security Considerations 848 Security considerations for SIP event packages are discussed in RFC 849 3265 [2], and those considerations apply here. Call Completion 850 information is sensitive, potentially private, information. 851 Subscriptions to these event packages SHOULD be authenticated and 852 authorized according to local policy. In addition, notifications 853 SHOULD be sent in such a way to ensure confidentiality, message 854 integrity and verification of subscriber identity, such as sending 855 subscriptions and notifications using a SIPS URL or protecting the 856 notification bodies with S/MIME. 858 10. 859 IANA Considerations 861 10.1 862 SIP Event Package Registration 864 Package name: call-completion 865 Type: package 867 Contact: Ultan Mulligan, 868 Change Controller: SIPPING Working Group delegated from the IESG 869 Published Specification: RFCXXXX 871 11. 872 References 874 11.1 875 Normative References 877 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 878 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 879 Session Initiation Protocol", RFC 3261, June 2002. 881 [2] Roach, A. B., " Session Initiation Protocol (SIP)-Specific 882 Event Notification ", RFC 3265, June 2002 884 11.2 885 Informative References 887 [5] ETSI, "Integrated Services Digital Network (ISDN); Completion 888 of Calls to Busy Subscriber (CCBS) Supplementary Service; 889 Service Description", ETSI EN 300 357 v1.2.1, May 2001, 890 893 [6] ETSI, "Integrated Services Digital Network (ISDN); Completion 894 of Calls on No Reply (CCNR) Supplementary Service; Service 895 Description", ETSI EN 301 134 v1.1.1, October 1998, . 898 [7] ETSI, "Integrated Services Digital Network (ISDN); Signalling 899 System No.7; ISDN User Part (ISUP) version 2 for the 900 international interface; Part 18: Completion of Calls to Busy 901 Subscriber (CCBS) supplementary service", EN 300 356-18 ed.1 902 (1995-02) 903 905 [8] ETSI, "Integrated Services Digital Network (ISDN); Signalling 906 System No.7; ISDN User Part (ISUP) version 3 for the 907 international interface; Part 20: Completion of Calls on 908 No Reply (CCNR) supplementary service", EN 300 356-20 V3.2.8 909 (1998-09), 911 [9] ETSI, "Technical Specification, Telecommunications and Internet 912 Converged Services and Protocols for Advanced Networking 913 (TISPAN); NGN Signalling Contreol Protocol; Completion of 914 Communications to Busy Subscriber (CCBS) and Completion of 915 Communications on No Reply (CCNR) PSTN/ISDN Simulation 916 Services", ETSI ES 183 042, 917 920 [12] Jesske, R., "Analysis of the Input Requirements for the 921 Session Initiation Protocol (SIP) in support for the European 922 Telecommunications Standards Institute (ETSI) Next Generation 923 Networks (NGN) simulation service", 924 draft-jesske-sipping-tispan-analysis-03 (work in progress), 925 June 2005. 927 12. 928 Contributors 930 Roland Jesske 931 Deutsche Telekom 932 Deutsche-Telekom-Allee 1 933 64307 Darmstadt 934 Germany 936 Email: r.jesske@t-com.net 938 Silvia Tessa 939 Telecom Italia 940 Via Reiss Romoli 274 941 10148 Torino 942 Italy 944 Email: silvia.tessa@telecomitalia.it 945 Alberto Cuda 946 Telecom Italia 947 Via Reiss Romoli 274 948 10148 Torino 949 Italy 951 Email: alberto.cuda@telecomitalia.it 953 Sebastien Garcin 954 France Telecom 955 38-40 Rue du General Leclerc 956 92794 Issy Les Moulineaux 957 France 959 Email: sebastien.garcin@orange-ft.com 961 13. 962 Authors' Addresses 964 Joachim Poetzl 965 Deutsche Telekom 966 Deutsche-Telekom-Allee 1 967 64307 Darmstadt 968 Germany 970 Email: joachim.poetzl@t-com.net 972 Martin Huelsemann 973 Deutsche Telekom 974 Deutsche-Telekom-Allee 1 975 64307 Darmstadt 976 Germany 978 Email: martin.huelsemann@t-com.net 980 Jean-Marie Stupka 981 Nokia Siemens Networks 982 81359 Munich 983 Germany 985 Email: jean-marie.stupka@nsn.com 987 14. 988 Acknowledgments 990 This draft was motivated based on the requirements in [12]. 992 15. 993 Full Copyright Statement 995 Copyright (C) The IETF Trust (2007). 997 This document is subject to the rights, licenses and restrictions 998 contained in BCP 78, and except as set forth therein, the authors 999 retain all their rights. 1001 This document and the information contained herein are provided on 1002 an 1003 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1004 REPRESENTS 1005 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 1006 AND 1007 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1008 EXPRESS 1009 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 1010 OF 1011 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1012 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1014 16. 1015 Intellectual Property 1017 The IETF takes no position regarding the validity or scope of any 1018 Intellectual Property Rights or other rights that might be claimed 1019 to 1020 pertain to the implementation or use of the technology described in 1021 this document or the extent to which any license under such rights 1022 might or might not be available; nor does it represent that it has 1023 made any independent effort to identify any such rights. 1024 Information 1025 on the procedures with respect to rights in RFC documents can be 1026 found in BCP 78 and BCP 79. 1028 Copies of IPR disclosures made to the IETF Secretariat and any 1029 assurances of licenses to be made available, or the result of an 1030 attempt made to obtain a general license or permission for the use 1031 of 1032 such proprietary rights by implementers or users of this 1033 specification can be obtained from the IETF on-line IPR repository 1034 at 1035 http://www.ietf.org/ipr. 1037 The IETF invites any interested party to bring to its attention any 1038 copyrights, patents or patent applications, or other proprietary 1039 rights that may cover technology that may be required to implement 1040 this standard. Please address the information to the IETF at 1041 ietf-ipr@ietf.org. 1043 17. 1044 Acknowledgment 1046 Funding for the RFC Editor function is provided by the IETF 1047 Administrative Support Activity (IASA).