diff options
Diffstat (limited to 'doc/rfc/rfc6910.txt')
| -rw-r--r-- | doc/rfc/rfc6910.txt | 2075 |
1 files changed, 2075 insertions, 0 deletions
diff --git a/doc/rfc/rfc6910.txt b/doc/rfc/rfc6910.txt new file mode 100644 index 0000000..f62329a --- /dev/null +++ b/doc/rfc/rfc6910.txt @@ -0,0 +1,2075 @@ + + + + + + +Internet Engineering Task Force (IETF) D. Worley +Request for Comments: 6910 Ariadne Internet Services, Inc. +Category: Standards Track M. Huelsemann +ISSN: 2070-1721 R. Jesske + Deutsche Telekom + D. Alexeitsev + TeleFLASH + April 2013 + + + Completion of Calls for the Session Initiation Protocol (SIP) + +Abstract + + The "completion of calls" feature defined in this specification + allows the caller of a failed call to be notified when the callee + becomes available to receive a call. + + For the realization of a basic solution without queuing, this + document references the usage of the dialog event package (RFC 4235) + that is described as 'Automatic Redial' in "Session Initiation + Protocol Service Examples" (RFC 5359). + + For the realization of a more comprehensive solution with queuing, + this document introduces an architecture for implementing these + features in the Session Initiation Protocol where "completion of + calls" implementations associated with the caller's and callee's + endpoints cooperate to place the caller's request for completion of + calls into a queue at the callee's endpoint; when a caller's request + is ready to be serviced, re-attempt of the original, failed call is + then made. + + The architecture is designed to interoperate well with existing + completion of calls solutions in other networks. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6910. + + + +Worley, et al. Standards Track [Page 1] + +RFC 6910 Completion of Calls April 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction ....................................................3 + 2. Requirements Terminology ........................................4 + 3. Terminology .....................................................4 + 4. Solution ........................................................6 + 4.1. CC Architecture ............................................6 + 4.2. CC Procedures ..............................................8 + 4.3. Automatic Redial as a Fallback ............................11 + 4.4. Differences from SS7 ......................................11 + 5. CC Queue Model .................................................12 + 6. Caller's Agent Behavior ........................................13 + 6.1. Receiving the CC Possible Indication ......................13 + 6.2. Subscribing to CC .........................................13 + 6.3. Receiving a CC Recall Notification ........................14 + 6.4. Initiating a CC Call ......................................15 + 6.5. Suspending CC .............................................15 + 6.6. Resuming CC ...............................................15 + 7. Callee's Monitor Behavior ......................................16 + 7.1. Sending the CC Possible Indication ........................16 + 7.2. Receiving a CC Subscription ...............................17 + 7.3. Sending a CC Notification .................................18 + 7.4. Receiving a CC Call .......................................19 + 7.5. Receiving a CC Suspension .................................19 + 7.6. Receiving a CC Resumption .................................20 + 8. Examples .......................................................20 + 9. 'call-completion' Event Package ................................24 + 9.1. Event Package Name ........................................24 + 9.2. Event Package Parameters ..................................24 + 9.3. SUBSCRIBE Bodies ..........................................25 + 9.4. Subscribe Duration ........................................25 + 9.5. NOTIFY Bodies .............................................26 + 9.6. Subscriber Generation of SUBSCRIBE Requests ...............26 + + + +Worley, et al. Standards Track [Page 2] + +RFC 6910 Completion of Calls April 2013 + + + 9.7. Notifier Processing of SUBSCRIBE Requests .................26 + 9.8. Notifier Generation of NOTIFY Requests ....................27 + 9.9. Subscriber Processing of NOTIFY Requests ..................27 + 9.10. Handling of Forked Requests ..............................28 + 9.11. Rate of Notifications ....................................28 + 9.12. State Agents .............................................28 + 10. CC Information Format .........................................28 + 10.1. CC Status ................................................29 + 10.2. CC Service-Retention Indication ..........................29 + 10.3. CC URI ...................................................29 + 11. Security Considerations .......................................29 + 12. IANA Considerations ...........................................31 + 12.1. SIP Event Package Registration for CC ....................31 + 12.2. MIME Registration for application/call-completion ........31 + 12.3. SIP/SIPS URI Parameter 'm' ...............................32 + 12.4. The 'purpose' Parameter Value 'call-completion' ..........33 + 12.5. 'm' Header Parameter for Call-Info .......................33 + 13. Acknowledgements ..............................................33 + 14. References ....................................................34 + 14.1. Normative References .....................................34 + 14.2. Informative References ...................................35 + Appendix A. Example Caller's Agent ................................36 + Appendix B. Example Callee's Monitor ..............................36 + +1. Introduction + + The Completion of Calls (CC) feature allows the caller of a failed + call to have the call completed without having to make a new call + attempt while guessing when the callee becomes available. When the + caller requests the use of the CC feature, the callee will be + monitored for its availability. When the callee becomes available, + the callee will be given a certain time frame for initiating a call. + If the callee does not initiate a new call within this time frame, + then the caller will be recalled. When the caller accepts the CC + recall, then a CC call to the callee will automatically start. If + several callers have requested the CC feature on the same callee, + they will be recalled in a predefined order, which is usually the + order in which they have requested the CC feature. + + This document defines the following CC features: + + Completion of Calls to Busy Subscriber (CCBS): The callee is busy. + The caller is recalled after the callee is no longer busy. + + Completion of Calls on No Reply (CCNR): The callee does not answer + the call. The caller is recalled after the callee has completed a + new call. + + + + +Worley, et al. Standards Track [Page 3] + +RFC 6910 Completion of Calls April 2013 + + + Completion of Calls on Not Logged-in (CCNL): The callee is not + registered. The caller is recalled after the callee has + registered again. + +2. Requirements Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This document uses terms from [RFC3261]. + +3. Terminology + + For the purpose of this service, we provide the following + terminology: + + Callee: a destination of the original call, and a target of the CC + call. + + Caller: the initiator of the original call and the CC request. The + user on whose behalf the CC call is made. + + Callee's monitor: a logical component that implements the CC queue + for destination user(s)/UA(s) (User Agent(s)) and performs the + associated tasks, including sending CC recall events, analogous to + the destination local exchange's role in Signaling System 7 + (SS7) CC. + + Caller's agent: a logical component that makes CC requests and + responds to CC recall events on behalf of originating + user(s)/UA(s), analogous to the originating local exchange's role + in SS7 CC. + + CC, or Completion of Calls: a service that allows a caller who + failed to reach a desired callee to be notified when the callee + becomes available to receive a call. + + CC activation: the indication by the caller to the caller's agent + that the caller desires CC for a failed original call; this + implies an indication transmitted from the caller's agent to the + callee's monitor of the desire for CC processing. + + CCBS, or Completion of Calls to Busy Subscriber: a CC service + provided when the initial failure was that the destination UA was + busy. + + + + + +Worley, et al. Standards Track [Page 4] + +RFC 6910 Completion of Calls April 2013 + + + CCNR, or Completion of Calls on No Reply: a CC service provided when + the initial failure was that the destination UA did not answer. + + CCNL, or Completion of Calls on Not Logged-in: a CC service provided + when the initial failure was that the destination UA was not + registered. + + CC call: a call from the caller to the callee, triggered by the CC + service when it has determined that the callee is available. + + CC indicator: an indication in the CC call INVITE used to prioritize + the call at the destination. + + CC possible indication: the data in responses to the INVITE of the + original call that indicate that CC is available for the call. + + CC recall: the action of the callee's monitor selecting a particular + CC request for initiation of a CC call, resulting in an indication + from the caller's agent to the caller that it is now possible to + initiate a CC call. + + CC recall events: event notifications of event package + "call-completion", sent by the callee's monitor to the caller's + agent to inform it of the status of its CC request. + + CC recall timer: maximum time the callee's monitor will wait for the + caller's response to a CC recall. + + CC request: the entry in the callee's monitor queue representing the + caller's request for CC processing, that is, the caller's CC + subscription. + + CC service duration timer: maximum time a CC request may remain + active within the network. + + CC queue: a buffer at the callee's monitor that stores incoming + calls that are targets for CC. Note: This buffer may or may not + be organized as a queue. The use of the term "queue" is analogous + to SS7 usage. + + CCE, or CC Entity: the representation of a CC request, or, + equivalently, an existing CC subscription within the queue of a + callee's monitor. + + + + + + + + +Worley, et al. Standards Track [Page 5] + +RFC 6910 Completion of Calls April 2013 + + + Failed call: a call that does not reach a desired callee, from the + caller's point of view. Note that a failed call may be successful + from the SIP point of view; e.g., if the call reached the callee's + voicemail but the caller desired to speak to the callee in real + time, the INVITE receives a 200 response, but the caller considers + the call to have failed. + + Notifier: the UA that generates NOTIFY requests for the purpose of + notifying subscribers of the callee's availability; for the CC + service, this is the task of the callee's monitor. + + Original call: the initial call that failed to reach a desired + destination. + + Retain option: a characteristic of the CC service; if supported, CC + calls that again encounter a busy callee will not be queued again, + but the position of the caller's entry in the queue is retained. + Note that SIP CC always operates with the retain option active; a + failed CC call does not cause the CC request to lose its position + in the queue. + + Signaling System 7, or SS7: the signaling protocol of the public + switched telephone network, defined by ITU-T Recommendations Q.700 + through Q.849. + + Subscriber: the UA that receives NOTIFY requests with information of + the callee's availability; for the CC service, this is the task of + the caller's agent. + + Suspended CC request: a CC request that is temporarily not to be + selected for CC recall. + +4. Solution + +4.1. CC Architecture + + The CC architecture augments each caller's UA (or User Agent Client + (UAC)) wishing to use the CC features with a "CC agent" (also written + as "caller's agent"). + + It augments each callee's UA (or User Agent Server (UAS)) wishing to + be the target of the CC features with a "CC monitor" (also written as + "callee's monitor"). + + The caller's agent and callee's monitor functions can be integrated + into the respective UAs, be independent end-systems, or be provided + by centralized application servers. The two functions, though + associated with the two UAs (caller and callee), also may be provided + + + +Worley, et al. Standards Track [Page 6] + +RFC 6910 Completion of Calls April 2013 + + + as services by the endpoints' home proxies or by other network + elements. Though it is expected that a UA that implements CC will + have both functions so that it can participate in CC as both caller + and callee, the two functions are independent of each other. + + A caller's agent may service more than one UA as a collective group + if a caller or population of users will be shared between the UAs, + and especially if the UAs share an address of record (AOR). + + The caller's agent monitors calls made from the caller's UA(s) in + order to determine their destinations and (potentially) their final + response statuses, and the Call-Info header fields of provisional and + final responses to invoke the CC feature. + + A callee's monitor may service more than one UA as a collective group + if a callee or population of users will be shared between the UAs, + and especially if the UAs share an AOR. The callee's monitor may + supply the callee's UAS(s) with Call-Info header field values for + provisional and final responses. + + The callee's monitor also instantiates a presence server used to + monitor the caller's availability for CC recall. + + The callees using the UA(s) may be able to indicate to the callee's + monitor when they wish to receive CC calls. + + In order to allow flexibility and innovation, most of the interaction + between the caller's agent, the caller(s) (user(s)), and the caller's + UA(s) is out of the scope of this document. Similarly, most of the + interaction between the callee's monitor, the callee(s), and the + callee's UA(s) is out of the scope of this document, as is the policy + by which the callee's monitor arbitrates between multiple CC + requests. + + The caller's agent must be capable of performing a number of + functions relative to the UA(s). The method by which it does so is + outside the scope of this document, but an example method is + described in Appendix A. The callee's monitor must be capable of + performing a number of functions relative to the UA(s). The method + by which it does so is outside the scope of this document, but an + example method is described in Appendix B. + + As a proof of concept, simple caller's agents and callee's monitors + can be devised that interact with users and UAs entirely through + standard SIP mechanisms [RFC6665] [RFC4235] [RFC3515], as described + in the Appendices. + + + + + +Worley, et al. Standards Track [Page 7] + +RFC 6910 Completion of Calls April 2013 + + + The callers using the UA(s) can indicate to the caller's agent when + they wish to avail themselves of CC for a recently made call that the + callers determined to be unsuccessful. The caller's agent monitors + the status of the caller's UA(s) to determine when they are available + to be used for a CC recall. The caller's agent can communicate to + the caller's UA(s) that a CC recall is in progress and inquire if the + relevant caller is available for the CC recall. + + The callee's monitor may utilize several methods to monitor the + status of the callee's UA(s) and/or their users for availability to + receive a CC call. This can be achieved through monitoring calls + made to the callee's UA(s) to determine the callee's status, the + identity of callers, and the final responses for incoming calls. And + in a system with rich presence information, the presence information + may directly provide this status. In a more restricted system, this + determination can depend on the mode of the CC call in question, + which is provided by the URI 'm' parameter. For example, a UA is + considered available for CCBS ("m=BS") when it is not busy, but a UA + is considered available for CCNR ("m=NR") when it becomes not busy + after being busy with an established call. + + The callee's monitor maintains information about the set of INVITEs + received by the callee's UA(s) considered unsuccessful by the caller. + In practice, the callee's monitor may remove knowledge about an + incoming dialog from its set if local policy at the callee's monitor + establishes that the dialog is no longer eligible for CC activations. + +4.2. CC Procedures + + The caller's UA sends an INVITE to a request-URI. One or more forks + of this request reach one or more of the callee's UAs. If the CC + feature is available, the callee's monitor (note there can be a + monitor for each of the callee's UAs) inserts a Call-Info header + field with its URI and with "purpose=call-completion" in appropriate + non-100 provisional or final responses to the initial INVITE and + forwards them to the caller. The provisional response SHOULD be sent + reliably if the INVITE contained a Supported header field with the + option tag 100rel. On receipt of a non-100 provisional or a final + response with the indication that the CC feature is available, the + calling user can invoke the CC feature. + + The caller indicates to the caller's agent that he wishes to invoke + CC services on the recent call. Note that from the SIP point of + view, the INVITE may have been successful, but from the user's point + of view, the call may have been unsuccessful. For example, the call + may have connected to the callee's voicemail, which would return a + 200 status to the INVITE but from the caller's point of view is "no + reply". + + + +Worley, et al. Standards Track [Page 8] + +RFC 6910 Completion of Calls April 2013 + + + In order to receive information necessary for the caller to complete + the call at the callee, the caller's agent subscribes to the + call-completion event package at the callee's monitor. + + The possibility of the caller completing the call at the callee is + also known as the CC state (cc-state) of the caller. The cc-states + comprehend the values "queued" and "ready" (for CC). + + In order to receive information from all destinations where the + callee will be reachable, the caller's agent sends a SUBSCRIBE + request for the call-completion event package to the original + destination URI of the call and to all known URIs of the callees' + monitors (which are provided by Call-Info header fields in + provisional and final responses to the INVITE). Each callee's + monitor uses the subscription as an indication that the caller is + interested in using the CC feature with regard to the particular + callee. + + Each callee's monitor keeps a list or queue of subscriptions from + callers' agents, representing the requests from the callers' agents + to the callee's monitor for CC services. These subscriptions are + created, refreshed, and terminated according to the procedures of + [RFC6665]. + + Upon receiving a SUBSCRIBE request from the caller's agent, the + callee's monitor instantiates a presence state for the caller's UA + that can be modified by the caller's UA to indicate its availability + for the CC call. Upon instantiation, the caller's presence status at + the callee's monitor is "open". + + When the callee's monitor determines that the callee and/or callee's + UA is available for a CC call, it selects a caller to execute the CC + call and sends a CC event update ("cc-state: ready") via a NOTIFY + request to the selected subscription of the caller's agent, telling + it to begin the CC call to the callee's UA. + + When the caller's agent receives this update, it initiates a CC + recall by calling the caller's UA and then starts the CC call to the + callee's UA, using third-party call control procedures in accordance + with [RFC3725]. The caller's agent can also check by other means + whether the caller is available to initiate the CC call to the + callee's UA. If the caller is available, the caller's agent directs + the caller's UA to initiate the CC call to the callee's UA. + + The caller's agent marks the CC call as such by adding a specific SIP + URI parameter to the Request-URI, so it can be given precedence by + the callee's monitor in reaching the callee's UA. + + + + +Worley, et al. Standards Track [Page 9] + +RFC 6910 Completion of Calls April 2013 + + + If the caller is not available on receipt of the "ready for recall" + notification, the caller's agent suspends the CC request at the + callee's monitor by sending a PUBLISH request containing presence + information to the presence server of the callee's monitor, informing + the server that the presence status is "closed". Once the caller + becomes available for a CC call again, the caller's agent resumes the + CC request by sending another PUBLISH request to the callee's + monitor, informing the monitor that the presence status is "open". + + On receipt of the suspension request, the callee's monitor performs + the monitoring for the next non-suspended CC request in the queue. + On receipt of the resume from the previously suspended caller's agent + that was at the top of the queue, the callee's monitor performs the + callee monitoring for this caller's agent. + + When the CC call fails, there are two possible options: the CC + feature has to be activated again by the caller's agent subscribing + to the callee's monitor, or CC remains activated and the original CC + request retains its position in the queue if the retain option is + supported. + + The retain option (see Section 3) determines the behavior of the + callee's monitor when a CC call fails. If the retain option is + supported, CC remains activated, and the original CC request + retains its position in the queue. Otherwise, the CC feature is + deactivated, and the caller's agent would have to subscribe again to + reactivate it. + + A monitor that supports the retain option provides the + cc-service-retention header in its CC events. A caller's agent that + also supports the retain option uses the presence of this header to + know not to generate a new CC request after a failed CC call. + + Monitors not supporting the retain option do not provide the + cc-service-retention header. A failed CC call causes the CC request + to be deleted from the queue, and these monitors will terminate the + corresponding subscription of the caller's agent to inform that agent + that its CC request is no longer in the queue. A caller's agent that + does not support the retain option can also terminate its + subscription when a CC call fails, so it is possible that both the + caller's agent and the callee's monitor may be signaling the + termination of the subscription concurrently. This is a normal SIP + events [RFC6665] scenario. After the subscription is terminated, the + caller's agent may create a new subscription (as described in + Section 6.2) to reactivate the CC feature for the original call. + + + + + + +Worley, et al. Standards Track [Page 10] + +RFC 6910 Completion of Calls April 2013 + + +4.3. Automatic Redial as a Fallback + + Automatic Redial is a simple end-to-end design. An Automatic Redial + scenario is described in [RFC5359], Section 2.17. This solution is + based on the usage of the dialog event package. If the callee is + busy when the call arrives, then the caller subscribes to the + callee's call state. The callee's UA sends a notification when the + callee's call state changes. This means the caller is also notified + when the callee's call state changes to 'terminated'. The caller is + alerted, then the caller's UA starts a call establishment to the + callee again. If several callers have subscribed to a busy callee's + call state, they will be notified at the same time that the call + state has changed to 'terminated'. The problem with this solution is + that it might happen that several recalls are started at the same + time. This means it is a heuristic approach with no guarantee of + success. + + There is no interaction between CC and Automatic Redial, as there is + a difference in the behavior of the callee's monitor and the caller + when using the dialog event package for receiving dialog information + or for aggregating a CC state. + +4.4. Differences from SS7 + + SIP CC differs in some ways from the CCBS and CCNR features of SS7 + (which is used in the Public Switched Telephone Network (PSTN)). For + ease of understanding, we enumerate some of the differences here. + + As there is no equivalent to the forking mechanism in SS7, in the + PSTN, calls can be clearly differentiated as successful or + unsuccessful. Due to the complex forking situations that are + possible in SIP, a call may fail from the point of view of the user + and yet have a success response from SIP's point of view. (This can + happen even in simple situations: e.g., a call to a busy user that + fails over to his voicemail receives a SIP success response, even + though the caller may consider it "busy subscriber".) Thus, the + caller must be able to invoke CC even when the original call appeared + to succeed. To support this, the caller's agent must record + successful calls as well as unsuccessful calls. + + In SIP, only the caller's UA or service system on the originating + side and the callee's UA or service system on the terminating side + need to support CC for CC to work successfully between the UAs. + Intermediate SIP systems (proxies or back-to-back user agents + (B2BUAs)) do not need to implement CC; they only need to be + transparent to the usual range of SIP messages. In the PSTN, + additionally, intermediate nodes like media gateway controllers have + to implement the CC service. + + + +Worley, et al. Standards Track [Page 11] + +RFC 6910 Completion of Calls April 2013 + + +5. CC Queue Model + + The callee's monitor manages CC for a single URI. This URI is likely + to be a published AOR, or more likely "non-voicemail AOR", but it may + be as narrowly scoped as a single UA's contact URI. The callee's + monitor manages a dynamic set of CC entities (called "CCEs"), which + represent CC requests, or equivalently, the existing incoming CC + subscriptions. This set is also called a queue, because a queue data + structure often aids in implementing the policies of the callee's + monitor for selecting CCEs for CC recall. + + Each CCE has an availability state, determined through the caller's + presence status at the callee's monitor. A presence status of "open" + represents a CCE's availability state of "available", and a presence + status of "closed" represents a CCE's availability state of + "unavailable". + + Each CCE has a recall state that is visible via subscriptions. The + recall state is either "queued" or "ready". + + Each CCE carries the From URI of the SUBSCRIBE request that caused + its creation. + + CC subscriptions arrive at the callee's monitor by addressing the + URIs the callee's monitor returns in Call-Info header fields. The + request-URI of the SUBSCRIBE request determines the queue to which + the resulting CCE is added. The resulting subscription reports the + status of the queue. The base event data is the status of all the + CCEs in the queue, but the data returned by each subscription is + filtered to report only the status of that subscription's CCE. + (Further standardization may define means for obtaining more + comprehensive information about a queue.) + + When a CCE is created, it is given the availability state "available" + and recall state "queued". + + When the callee's monitor receives Presence Information Data Format + (PIDF) bodies [RFC3863] via PUBLISH requests [RFC3903], these PUBLISH + requests are expected to be sent by subscribers to indirectly suspend + and resume their CC requests by modifying its CCE availability state. + A CCE is identified by the request-URI (if it was taken from a CC + event notification that identifies the CCE) or the From URI of the + request (matching the From URI recorded in the CCE). Receipt of a + PUBLISH with status "open" sets the availability state of the CCE to + "available" (resume); status "closed" sets the availability state of + the CCE to "unavailable" (suspend). + + + + + +Worley, et al. Standards Track [Page 12] + +RFC 6910 Completion of Calls April 2013 + + + A CC request is eligible for recall only when its CCE's availability + state is "available" and the "m" value of the CCE also indicates an + available state. The callee's monitor MUST NOT select for recall any + CC requests that fail to meet those criteria. Within that + constraint, the selections made by the callee's monitor are + determined by its local policy. Often, a callee's monitor will + choose the acceptable CCE that has been in the queue the longest. + When the callee's monitor has selected a CCE for recall, it changes + the CCE's recall state from "queued" to "ready", which triggers a + notification on the CCE's subscription. + + If a selected subscriber then suspends its request by sending a + PUBLISH with the presence status "closed", the CCE becomes + "unavailable", and the callee's monitor changes the CCE's recall + state to "queued". This may cause another CCE (e.g., a CCE that has + been in the queue for less time) to be selected for recall. + + The caller's presence status at the callee's monitor is terminated + when the caller completes its CC call or when the subscription of the + caller's agent at the callee's monitor is terminated. + +6. Caller's Agent Behavior + +6.1. Receiving the CC Possible Indication + + The caller's agent MUST record the From URI and SHOULD record the + final request status that the caller's UA received along with the + contents of Call-Info header fields of provisional and final + responses. + + Note that receiving a CC possible indication also depends on the + aggregation of final responses by proxies; in the case of 4xx + responses, some 4xx responses are more likely to be sent to the + caller. + +6.2. Subscribing to CC + + For CC activation, the caller's agent MUST send a SUBSCRIBE to all + known callee's monitor URIs. A callee's monitor URI may be provided + in the Call-Info header field in provisional and final responses to + the INVITE sent back by the callee's monitor(s). Additionally, the + caller's agent SHOULD include the original request-URI that it sent + the original INVITE to, in its set of callee's monitor URIs, when it + is unclear if the call has forked to additional callees whose + responses the caller has not seen. A SUBSCRIBE to the original + request-URI alone is used in cases where the caller's agent has not + received or does not remember any callee's monitor URI. The caller's + agent SHOULD add an 'm' parameter to these URIs in order to indicate + + + +Worley, et al. Standards Track [Page 13] + +RFC 6910 Completion of Calls April 2013 + + + to the callee's monitor the desired CC mode. The 'm' parameter + SHOULD have the value of the 'm' parameter received in the Call-Info + header field of the responses to the original INVITE. + + To minimize redundant subscriptions, these SUBSCRIBEs SHOULD be + presented as forks of the same transaction, as defined by + Section 8.2.2.2 of [RFC3261], if the caller's agent is capable of + doing so. + + The agent MUST NOT maintain more than one CC request for a single + caller and directed to a single original destination URI. If a + caller requests CC a second time for the same destination URI, the + agent MUST consolidate the new request with the existing CC request + by either reusing the existing CC subscriptions or terminating and + then recreating them. For this purpose, equality of callers is + determined by comparing callers' AORs and equality of destination + URIs is determined by comparing them per [RFC3261] Section 19.1.4. + + When generating these SUBSCRIBEs, the From URI MUST be the caller's + AOR. The To URI SHOULD be the destination URI of the original call + (if the agent knows that and can insert it into the To header) and + otherwise MUST be the request-URI of the SUBSCRIBE. + + The SUBSCRIBE SHOULD have header fields to optimize its routing. In + particular, it SHOULD contain "Request-Disposition: parallel" and an + Accept-Contact header field to eliminate callee UAs that are not + acceptable to the caller. + + The caller's agent MUST be prepared to receive multiple responses for + multiple forks of the SUBSCRIBE and to have multiple subscriptions + established. The caller's agent must also be prepared to have the + SUBSCRIBE fail; in which case, CC cannot be invoked for this original + call. + + If the caller's agent no longer wants to initiate the CC call (e.g., + because the caller has deactivated CC), the caller's agent terminates + the subscription in accordance with [RFC6665] or suspends the + subscription(s) as specified in Section 6.5. + +6.3. Receiving a CC Recall Notification + + When receiving a NOTIFY with the cc-state set to "ready", the + caller's agent SHOULD suspend all other subscriptions to CC, by + following the step in Section 6.5, in order to prevent any other CC + requests from this caller from receiving CC recalls. The caller's + agent starts the CC recall to the caller by confirming that the + caller would be able to initiate a CC call, e.g., by calling the + caller's UA(s). + + + +Worley, et al. Standards Track [Page 14] + +RFC 6910 Completion of Calls April 2013 + + +6.4. Initiating a CC Call + + If the caller is available for the CC call and willing to initiate + the CC call, the caller's agent causes the caller's UA to generate a + new INVITE towards the callee. The caller's UA MAY add an 'm' URI + parameter with the value of the 'm' parameter received in the + Call-Info header in the response to the original INVITE, in order to + specify his preferences in CC processing and to prioritize the CC + call. The INVITE SHOULD be addressed to the URI specified in the + cc-URI of the NOTIFY, or, if that's not available, it SHOULD use the + URI in the Call-Info header field of the response to the original + INVITE; if that's not available, it MAY use the request-URI of the + original INVITE, if this URI was recorded. Note that the latter + choice may not provide ideal routing, but, in simple cases, it is + likely to reach the desired callee or callee's monitor. + +6.5. Suspending CC + + If the caller is not available for the CC recall, the CC request + SHALL be suspended by the caller's agent until the caller becomes + available again or if the conditions relevant to the local suspension + policy of the caller's agent have changed. To suspend the CC + request, the caller's agent SHALL publish the caller's presence state + by sending a PUBLISH request to each callee's monitor where the + presence server for CC resides in accordance with the procedures + described in [RFC3903], giving the PIDF state "closed" for the + caller's identity as presentity. The PUBLISH request SHOULD contain + an Expires header field with a value that corresponds to the current + value of the remaining CC subscription duration. + + Each PUBLISH SHOULD be sent to the CC URI as received in the NOTIFY, + or within the corresponding SUBSCRIBE dialog, or if that is not + possible, to the corresponding callee's monitor URI received in the + Call-Info header field of the NOTIFY, or if one is not available, the + Contact address of the subscription. + +6.6. Resuming CC + + When the caller is no longer busy, or if the conditions relevant to + the suspension policy of the caller's agent have changed, then the CC + request SHALL be resumed by the caller's agent. To resume a CC + request, the caller's agent SHALL publish the caller's presence state + by sending a PUBLISH request to each callee's monitor in accordance + with the procedures described in [RFC3903], informing each monitor + that the PIDF state is "open"; this request will otherwise be + constructed in the same way as the suspend PUBLISH request. + + + + + +Worley, et al. Standards Track [Page 15] + +RFC 6910 Completion of Calls April 2013 + + + In the case where the caller's agent has sent several CC suspension + requests to different callee's monitors and the caller becomes + available again, as determined by the local resumption policy of the + caller's agent, the caller's agent MAY send a PUBLISH to resume a CC + request to each callee's monitor for which there is a suspended CC + request. Note that the resumption policy of the caller's agent may + prescribe a manual resumption; thus, a suspended CC request should + not be automatically resumed. + +7. Callee's Monitor Behavior + +7.1. Sending the CC Possible Indication + + The callee's monitor MUST record the From URI and MAY record the + final request status(es) returned by the callee's UA(s). + + If the callee's monitor wants to enable the caller to make use of the + CC service, it MUST insert a Call-Info header field with + "purpose=call-completion" in the final response message (e.g., in a + 486 to enable CC due to busy subscriber) and at least one non-100 + provisional response message (e.g., in a 180 due to no response) to + the initial INVITE when forwarding it to the caller. The non-100 + provisional response message SHOULD be sent reliably if the INVITE + contained a Supported header field with the option tag 100rel. The + Call-Info header field values defined in this specification + positively indicate that CC is available for the failed fork of the + call. + + The callee's monitor SHOULD insert a URI in the Call-Info header + field where the caller's agent should subscribe for CC. Ideally, it + is a globally routable URI [RFC5627] for the callee's monitor. In + practice, it may be the callee's AOR, and the SUBSCRIBE will be + routed to the callee's monitor only because it specifies "Event: + call-completion". + + In order to enable CC, the Call-Info header field MUST be set up + according to the following scheme: + + Call-Info: monitor-URI;purpose=call-completion;m=XX + + The 'm' parameter defines the "mode" of CC. The "m=NR" parameter + indicates that it failed due to lack of response, the "m=BS" + parameter indicates that it failed due to busy subscriber, and the + "m=NL" parameter indicates that it failed due to non-registered + subscriber (no devices are registered for the AOR contacted). The + 'm' parameter is useful for PSTN interworking and assessing presence + information in the callee's monitor. It is possible that other + values will be defined in future. It is also permissible to omit the + + + +Worley, et al. Standards Track [Page 16] + +RFC 6910 Completion of Calls April 2013 + + + 'm' parameter entirely. Implementations MUST accept CC operations in + which the 'm' parameter is missing or has an unknown value, and + execute them as best they can in their environment (which is likely + to be a degraded service, especially when interoperating with SS7). + +7.2. Receiving a CC Subscription + + The callee's monitor MUST be prepared to receive SUBSCRIBEs for the + call-completion event package directed to the URIs of UA(s) that it + is servicing and any URIs that the callee's monitor provides in + Call-Info header fields. The SUBSCRIBEs MUST be processed in + accordance with the procedures defined in [RFC6665], establishing + subscriptions. These subscriptions represent the request from the + caller's agent for CC services. + + If the monitor receives two or more SUBSCRIBEs that have the same + Call-Id header field value and the monitor considers the request-URIs + of the received SUBSCRIBEs to request the status of the same set of + UAs, then they are redundant forks of one SUBSCRIBE request, and the + monitor SHOULD reject all but one of the requests with 482 (Merged + Request) responses. + + The monitor MAY determine that an incoming CC SUBSCRIBE is a + duplicate of an existing CC subscription if (1) the Call-Id header + field values are different, (2) the From URIs (i.e., the caller's + AORs) are the same (per [RFC3261] Section 19.1.4), (3) the To URIs + (which should be the request-URI of the original call) have the same + user and hostport components, and (4) the monitor considers the + request-URIs of the received SUBSCRIBEs to request the status of the + same set of UAs. + + If the monitor determines that a new subscription is a duplicate of + an existing subscription, it MAY terminate the existing subscription + in accordance with the procedures defined in [RFC6665]. In any case, + it MUST establish the new subscription. + + The callee's monitor may apply restrictions as to which caller's + agents may subscribe. + + The continuation of the subscription of the caller's agent indicates + to the callee's monitor that the caller's agent is prepared to + initiate the CC call if it is selected for the "ready" state. If the + callee's monitor becomes aware of a subscription that cannot be + selected for a CC recall, it SHOULD terminate the subscription in + accordance with [RFC6665]. + + + + + + +Worley, et al. Standards Track [Page 17] + +RFC 6910 Completion of Calls April 2013 + + +7.3. Sending a CC Notification + + The call-completion event package returns various points of + information to the caller's agent, but the vital datum it contains is + the cc-state of the CC request of the caller's agent as stored in the + CC queue; in the beginning, this cc-state is "queued". When the + cc-state of the agent's request changes, the callee's monitor MUST + send a NOTIFY for a CC event to the caller's agent. The notification + SHOULD also contain a URI that can be used for suspension requests. + Ideally, it is a globally routable URI [RFC5627] for the callee's + monitor. In practice, it may be the callee's AOR, and the SUBSCRIBE + will be routed to the callee's monitor only because it specifies + "Event: call-completion". + + The call-completion event package provides limited information about + the policy of the callee's monitor. In particular, as in the PSTN, + the "cc-service-retention" datum gives an indication of the "service + retention" attribute, which indicates whether the CC request can be + continued to a later time if the CC call fails due to the callee's + UA(s) being busy. If the callee's monitor supports the + service-retention option, the callee's monitor SHOULD include the + cc-service-retention parameter. + + The callee's monitor has a policy regarding when and how it selects + CC requests for the recall. This policy may take into account the + type of the requests (e.g., CCNR vs. CCBS), the state of the callee's + UA(s), the order in which the CC requests arrived, the length of time + the CC requests have been active, and any previous attempts of CC + activations for the same original call. The callee's monitor will + usually choose only one CC request for the recall at a time, but if + the callee's UA(s) can support multiple calls, it may choose more + than one. The callee's monitor will usually choose the oldest active + request. + + When the callee's monitor changes the state datum for the chosen + subscription from "queued" to "ready", the callee's monitor MUST send + a NOTIFY for the subscription of the caller's agent with the cc-state + set to "ready" (recall notification). The NOTIFY SHOULD also contain + in the cc-URI a URI to be used in the CC call. In practice, this may + be the AOR of the callee. + + Upon sending the recall notification, the callee's monitor MUST start + a recall timer. It is RECOMMENDED to use a value between 10 and + 20 seconds, which corresponds to the recommendation for the CC + services in the ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733] + documents. + + + + + +Worley, et al. Standards Track [Page 18] + +RFC 6910 Completion of Calls April 2013 + + +7.4. Receiving a CC Call + + The callee's UA(s) and the callee's monitor may give the CC call + precedence over non-CC calls by evaluating the presence of the 'm' + URI parameter and the From header of the INVITE request. The + callee's monitor supervises the receiving of the CC call. Upon + arrival of the CC call, the recall timer MUST be stopped. If the CC + call does not arrive at the callee's UA(s) before the expiry of the + recall timer, the callee's monitor SHOULD stop processing the recall + and change the value of the cc-state datum to "queued" if it supports + the retain option, and terminate the subscription if it doesn't + support the retain option. Similarly, if the CC call is not + accepted, the callee's monitor will stop the CC recall processing. + Depending on its policy, the same original call may be selected again + for a CC recall at a later time. If the CC call succeeds, the + callee's monitor MUST terminate the relevant subscription in + accordance with [RFC6665] and MUST remove any associated presence + event state used for suspend and resume for the caller of the CC + call. + + Once the CC call has been terminated, successfully or unsuccessfully, + the policy of the callee's monitor MAY specify that another CC + request for a recall be selected. Note also that according to the + policy of the callee's monitor several recalls may be processed at + the same time. + +7.5. Receiving a CC Suspension + + The monitor may receive PUBLISH requests to suspend CC requests from + the caller's agent as described in Section 6.5. The PUBLISH requests + may be received via the URI it manages, any URI that it inserts into + a Call-Info header, any contact URI it uses as a notifier for + "call-completion" events, or any URI it returns as the "URI" line of + the call-completion event packages. + + The receipt of the PUBLISH request initiates a presence event state + for the caller's identity at the presence server of the callee's + monitor as specified in [RFC3903], together with a logical presence + server if this has not been done before for another call. + + Note: The presence server may initiate a presence event state for the + caller's identity on receipt of a SUBSCRIBE request as well, + dependent on the implementation. + + The monitor SHOULD identify the addressed CCE by the request-URI of + the PUBLISH request, or if that is not possible, by the From URI. + + + + + +Worley, et al. Standards Track [Page 19] + +RFC 6910 Completion of Calls April 2013 + + + If the processing of a CC request results in suspending that CC + request by receiving a PUBLISH request from the caller's agent as + described in Section 6.5, the callee's monitor MUST stop the recall + timer and MUST ensure that the request is set to a "queued" state, + and then the callee's monitor MUST attempt to process another CC + request in the queue according to its local policy. + +7.6. Receiving a CC Resumption + + When a CC request has been resumed after the callee's monitor has + received a PUBLISH request from the caller's agent as described in + Section 6.6, the presence event state for the caller's identity at + the presence server of the CC monitor MUST be modified as described + in [RFC3903]. If the callee is not busy and there is no entry in the + CC queue that is currently being processed, the callee's monitor MUST + process the queue as described in Section 7.3 above. + +8. Examples + + A basic call flow, with only the most significant messages of a CC + activation and invocation shown, is as follows (please note that this + is an example, and there may be variations in the failure responses): + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Worley, et al. Standards Track [Page 20] + +RFC 6910 Completion of Calls April 2013 + + + Caller Callee + sip:123@a.com sip:456@b.com + | | + | INVITE sip:456@b.com | [original call] + | From: sip:123@a.com | + |------------------------->| + | | + | 487 | + | Call-Info:<sip:456@z.b.com>;purpose=call-completion;m=NR + |<-------------------------| + | | + | SUBSCRIBE sip:456@z.b.com;m=NR [initial SUBSCRIBE] + | From: sip:123@a.com | + | Contact: sip:123@y.a.com | + | Request-Disposition: parallel + | Call-Id: abcd-efgh | + | Event: call-completion | + |------------------------->| + | | + | 200 | + |<-------------------------| + | | + | NOTIFY sip:123@y.a.com | [initial NOTIFY] + | Body: cc-state: queued | + |<-------------------------| + | | + | SUBSCRIBE sip:456@b.com;m=NR [another init. SUB.] + | From: sip:foo@example.com| + | Request-Disposition: parallel + | Call-Id: abcd-efgh | + | Event: call-completion | + |------------------------->| + | | + | 482 | [duplicate SUB. rej.] + |<-------------------------| + | | + | NOTIFY sip:123@y.a.com | [CC invoked] + | Body: cc-state: ready | + | URI: sip:recall@z.b.com + |<-------------------------| + | | + | INVITE sip:recall@z.b.com;m=NR [CC call] + | From: sip:foo@example.com| + |------------------------->| + | | + | NOTIFY sip:123@y.a.com | [CC terminated] + | Expires = 0 | + |<-------------------------| + + + +Worley, et al. Standards Track [Page 21] + +RFC 6910 Completion of Calls April 2013 + + + The original call is an ordinary INVITE. It fails due to no-response + (ring-no-answer). In this case, the callee's governing proxy + generates a 487 response because the proxy canceled the INVITE to the + UA when it rang too long without an answer. The 487 response carries + a Call-Info header field with "purpose=call-completion". The + Call-Info header field positively indicates that CC is available for + this failed fork of the call. The "m=NR" parameter indicates that it + failed due to no-response, which is useful for PSTN interworking and + assessing presence information in the callee's monitor. + + The URI in the Call-Info header field (<sip:456@z.b.com>) is where + the caller's agent should subscribe for CC processing. Ideally, it + is a globally routable URI for the callee's monitor. In practice, it + may be the callee's AOR, and the SUBSCRIBE will be routed to the + callee's monitor only because it specifies "Event: call-completion". + + CC is activated by sending a SUBSCRIBE to all known callee's monitor + URIs. These can be provided by the Call-Info header field in the + response to the INVITE. + + Additionally, the caller's agent needs to include the original + request-URI in its set of callee's monitor URIs, because the call may + have forked to additional callees whose responses the caller has not + seen. (A SUBSCRIBE to the request-URI alone is used in cases where + the caller's agent has not received or cannot remember any callee's + monitor URI.) + + The caller's agent adds to these URIs an 'm' parameter (if possible). + In this case, the caller's agent forks the SUBSCRIBE to two + destinations as defined by Section 8.2.2.2 of [RFC3261], with + appropriate Request-Disposition. The first SUBSCRIBE is to the URI + from Call-Info. + + The second SUBSCRIBE is to the original request-URI and reaches the + same callee's monitor. Because it has the same Call-Id as the + SUBSCRIBE that has already reached the callee's monitor, the callee's + monitor rejects it with a 482, thus avoiding redundant subscriptions. + + The initial NOTIFY for the successful SUBSCRIBE has "cc-state: + queued" in its body. Eventually, this caller is selected for CC and + is informed of this via a NOTIFY containing "cc-state: ready". This + NOTIFY carries a URI to which the INVITE for the CC call should be + sent. In practice, this may be the AOR of the callee. + + The caller generates a new INVITE to the URI specified in the NOTIFY, + or if there was no such URI or if the caller's agent cannot remember + it, it may use the original request-URI. The caller adds the 'm' + parameters (if possible), to specify CC processing. + + + +Worley, et al. Standards Track [Page 22] + +RFC 6910 Completion of Calls April 2013 + + + Finally, the subscription for the CC request is terminated by the + callee's monitor. + + Another flow, with only the most significant messages of CC + suspension and resumption shown, is as follows: + + Caller Callee + sip:123@a.com sip:456@b.com + | | + | NOTIFY sip:123@y.a.com | [CC notification, caller not + | Body: cc-state: ready | available for CC recall] + | URI: sip:recall@z.b.com + |<-------------------------| + | | + | 200 | + |------------------------->| + | | + | PUBLISH sip:456@z.b.com | [non-availability for recall + | From: sip:123@a.com | is published] + | Contact: sip:123@y.a.com | + | Event: presence | + | Content-Type: 'app/pidf' | + | Body: status=closed | + |------------------------->| + | | + | 200 | + |<-------------------------| + | | + | | [caller becomes available + | | again] + | | + | PUBLISH sip:456@z.b.com | [availability for recall + | From: sip:123@a.com | is published] + | Contact: sip:123@y.a.com | + | Event: presence | + | Content-Type: 'app/pidf' | + | Body: status=open | + |------------------------->| + | | + | 200 | + |<-------------------------| + | | + + The caller is selected for CC and is informed of this via a NOTIFY + request containing "cc-state: ready". At this time, the caller is + not available for the CC recall. + + + + + +Worley, et al. Standards Track [Page 23] + +RFC 6910 Completion of Calls April 2013 + + + For updating its presence event state at the callee's presence + server, the caller sends a PUBLISH request informing the presence + server that the PIDF state is "closed". The PUBLISH request is sent + (in order of preference) as follows: (1) out-of-dialog to the CC URI + as received in the NOTIFY, (2) within the corresponding SUBSCRIBE + dialog, (3) out-of-dialog to the corresponding callee's monitor URI + received in the Call-Info header field of the NOTIFY, or (4) out-of- + dialog to the remote Contact address of the corresponding SUBSCRIBE + dialog. + + When the caller is again available for the CC recall, the caller + updates his presence event state at the callee's presence server by + generating a PUBLISH request informing the server that the PIDF state + is "open"; this request will otherwise be constructed in the same way + as the suspend PUBLISH request. + +9. 'call-completion' Event Package + + This section specifies the call-completion event package, in + accordance with Section 5.4 of [RFC6665]. The call-completion event + package has the media type "application/call-completion". + + Note that if the callee has a caller-queuing facility, the callee's + monitor may want to treat the CC queue as part of the queuing + facility and include in the event package information regarding the + state of the queue. How this information is conveyed is left for + further standardization. + +9.1. Event Package Name + + The SIP events specification [RFC6665] requires package definitions + to specify the name of their package or template-package. The name + of this package is "call-completion". This value appears in the + Event and Allow-Events header fields. + +9.2. Event Package Parameters + + No package-specific Event header field parameters are defined for + this event package. + + + + + + + + + + + + +Worley, et al. Standards Track [Page 24] + +RFC 6910 Completion of Calls April 2013 + + +9.3. SUBSCRIBE Bodies + + [RFC6665] requires package definitions to define the usage, if any, + of bodies in SUBSCRIBE requests. + + The SUBSCRIBE request MAY contain an Accept header field. If no + such header field is present, it has a default value of + "application/call-completion". If the header field is present, it + MUST include "application/call-completion". + + A SUBSCRIBE request for a CC package MAY contain a body. This body + defines a filter to be applied to the subscription. Filter documents + are not specified in this document and may be the subject of future + standardization activity. + + A SUBSCRIBE request requests CC information regarding calls recently + made from the same caller to the callee UA(s) serviced by the + notifier. Calls are defined to be "from the same caller" if the + URI-part of the From header field value in the INVITE is the same as + the URI-part of the From header field value in the SUBSCRIBE. + +9.4. Subscribe Duration + + [RFC6665] requires package definitions to define a default value for + subscription durations and to discuss reasonable choices for + durations when they are explicitly specified. + + If a SUBSCRIBE does not explicitly request a duration, the default + requested duration is 3600 seconds, as that is the highest service + duration timer value recommended for the CC services in the ETSI + [ETS300.356-18] and ITU-T [ITU-T.Q.733] documents. Because the + subscription duration means that no explicit timer is needed, and the + subscription duration can be seen as an equivalent to the SS7 service + duration timer, this specification refers to the subscription + duration also as the service duration timer. It is RECOMMENDED that + subscribers request, and that notifiers grant, a subscription time of + at least 3600 seconds. + + If a notifier can determine that, according to its policy, after a + certain duration the requested subscription can no longer proceed to + the "ready" state, it SHOULD reduce the granted subscription time to + that duration. If a notifier can determine that, according to its + policy, the requested subscription can never proceed to the "ready" + state, it should refuse the subscription. + + + + + + + +Worley, et al. Standards Track [Page 25] + +RFC 6910 Completion of Calls April 2013 + + +9.5. NOTIFY Bodies + + [RFC6665] requires package definitions to describe the allowed set of + body types in NOTIFY requests and to specify the default value to be + used when there is no Accept header field in the SUBSCRIBE request. + A NOTIFY for a call-completion event package MUST contain a body that + describes the CC states. + + As described in [RFC6665], the NOTIFY message will contain bodies + that describe the state of the subscribed resource. This body is in + a format listed in the Accept header field of the SUBSCRIBE, or in a + package-specific default format if the Accept header field was + omitted from the SUBSCRIBE. + + In this event package, the body of the notification contains a CC + document. All subscribers and notifiers MUST support the + "application/call-completion" data format described in Section 10. + The SUBSCRIBE request MAY contain an Accept header field. If no + such header field is present, it has a default value of + "application/call-completion". If the header field is present, it + MUST include "application/call-completion". Of course, the + notifications generated by the server MUST be in one of the formats + specified in the Accept header field in the SUBSCRIBE request. + +9.6. Subscriber Generation of SUBSCRIBE Requests + + Subscribers MUST generate SUBSCRIBE requests when they want to + subscribe to the call-completion event package at the terminating + side in order to receive CC notifications. The generation of + SUBSCRIBE requests can imply the usage of a CC service-specific timer + as described in Section 9.4. + +9.7. Notifier Processing of SUBSCRIBE Requests + + Upon receiving a subscription refresh, the notifier MUST set the + "expires" parameter of the Subscription-State header field to a value + not higher than the current remaining duration of the subscription, + regardless of the value received in the Expires header field (if + present) of the subscription refresh. + + If a subscription is not successful because the CC queue has reached + the maximum allowed number of entries (short-term denial), the + notifier MUST send a 480 Temporarily Unavailable response to the + subscriber, possibly with a retry-after parameter in accordance with + the notifier's policy. If a subscription is not successful because a + condition has occurred that prevents and will continue to prevent the + CC service (long-term denial), the notifier MUST send a 403 Forbidden + response to the subscriber. + + + +Worley, et al. Standards Track [Page 26] + +RFC 6910 Completion of Calls April 2013 + + + A notifier MAY receive multiple forks of the same SUBSCRIBE, as + defined by Section 8.2.2.2 of [RFC3261]. In such a case, the + notifier MUST reject all but one of the SUBSCRIBEs with a 482 Merged + Request response, unless some other failure response applies. + + The CC information can be sensitive. Therefore, all subscriptions + SHOULD be handled with consideration of the security considerations + discussed in Section 11, in particular for verifying the identity of + the subscriber. + +9.8. Notifier Generation of NOTIFY Requests + + Notifiers MUST generate NOTIFY requests when the CC request's state + changes to "queued" or to "ready (for CC)". A NOTIFY that is sent + with non-zero expiration MUST contain the "cc-state" parameter. The + parameter's value MUST be "queued" if the CC request represented by + the subscription is not at this time selected by the callee's monitor + for CC recall, and the parameter's value MUST be "ready" if the + request is at this time selected by the callee's monitor for CC + recall. + + A NOTIFY sent with a zero expiration (e.g., as a confirmation of a + request to unsubscribe) MAY contain the "cc-state" parameter. + + When the callee's monitor withdraws the selection of the request for + the CC recall (e.g., because the caller's agent has not initiated the + CC recall INVITE before the CC recall timer expires, or because the + agent has suspended the request from being considered for CC recall), + the notifier MUST send a NOTIFY to the subscription of the selected + request. This NOTIFY MUST contain the "cc-state" parameter set to + "queued". + + If the CC subscription was successful and the retain option is + supported at the callee, the NOTIFY MUST contain the + "cc-service-retention" parameter. + +9.9. Subscriber Processing of NOTIFY Requests + + When receiving a NOTIFY request with the cc-state set to "ready", + subscribers SHOULD suspend all other CC subscriptions for the + original call at other notifiers. The receipt of a NOTIFY request + with the cc-state set to "ready" by the subscriber will also cause an + interaction with the instances at the subscriber's side that are + responsible for starting the CC recall. + + + + + + + +Worley, et al. Standards Track [Page 27] + +RFC 6910 Completion of Calls April 2013 + + +9.10. Handling of Forked Requests + + Forked requests are expected to be common for the CC event type. The + subscriber MUST be prepared to process NOTIFY requests from multiple + notifiers and to coordinate its processing of the information + obtained from them in accordance with the procedures in this + document. + +9.11. Rate of Notifications + + The CC service typically involves a single notification, per notifier + and per subscription, regarding the change to "ready" (for CC) but + MAY involve several notifications about the change to the "ready" + state, separated by a CC call that failed due to a busy callee. + Typically, notifications will be separated by at least tens of + seconds. Notifiers SHOULD NOT generate more than three notifications + for one subscription in any ten-second interval. Since it is + important to avoid useless recalls, a notifier SHOULD send state + changes to "queued" from "ready" promptly. Thus, a notifier SHOULD + NOT send a state change to "ready" as the third notification in a + ten-second interval, as that would make it impossible to promptly + send a further state change to "queued". + +9.12. State Agents + + State agents have no defined role in the handling of the + call-completion event package. + +10. CC Information Format + + The following syntax specification uses the Augmented Backus-Naur + Form (ABNF) as described in [RFC5234]. The formal syntax for the + application/call-completion MIME type is described below. In + general, the CC body is to be interpreted in the same way as SIP + headers: (1) the names of the lines are case-insensitive, (2) the + lines can be continued over line boundaries if the succeeding lines + start with horizontal white space, and (3) lines with unknown names + are to be ignored. The header lines defined in this document can + occur at most once in any given CC information format document. + + call-completion = 1*(cc-header CRLF) + + cc-header = cc-state / cc-service-retention / cc-URI / + extension-header + + The above rules whose names start with "cc-" are described below. + Other rules are described in [RFC3261]. + + + + +Worley, et al. Standards Track [Page 28] + +RFC 6910 Completion of Calls April 2013 + + +10.1. CC Status + + The cc-state line indicates the CC status of a particular user with + an entry in a CC queue. It MUST be present, unless the expiration + time indicated in the NOTIFY is zero. + + cc-state = "cc-state" HCOLON ( "queued" / "ready" ) + + The value "queued" indicates that a subscriber's entry in the CC + queue is not selected for CC recall. The value "ready" indicates + that a user's entry in the CC queue has been selected for CC recall. + +10.2. CC Service-Retention Indication + + The service-retention line indicates the support of the retain + option. The retain option, if supported at the callee, will maintain + the entry in the CC queue, if a CC call has failed due to a callee + busy condition. If present, this parameter indicates that the retain + option is supported; otherwise, it is not supported. This parameter + MAY be present in NOTIFY requests. + + cc-service-retention = "cc-service-retention" HCOLON "true" + +10.3. CC URI + + The cc-URI line provides a URI that the agent SHOULD use as the + request-URI of the CC recall INVITE and the suspend/resume PUBLISH. + It SHOULD be provided in all NOTIFYs. The URI SHOULD be globally + routable and SHOULD uniquely identify the CCE in question. The + syntax provides for generic-params in the value, but this document + defines no such parameters. Parameters that are not understood by + the subscriber MUST be retained with the URI. + + cc-URI = "cc-URI" HCOLON addr-spec + +11. Security Considerations + + The CC facility allows the caller's agent to determine some status + information regarding the callee. This information intrinsically + diminishes the privacy of the callee; in order to protect + sufficiently the privacy of the callee, the overall amount of + disclosure must be limited, and the amount of disclosure to any + single caller must be limited. + + Of course, if a caller is not permitted to call the callee, that + caller should not be allowed to establish a CC subscription. Callers + that are particularly sensitive about their privacy may reject all CC + subscriptions. But in the ordinary case, the optimal protection is + + + +Worley, et al. Standards Track [Page 29] + +RFC 6910 Completion of Calls April 2013 + + + to permit any caller to subscribe but prevent any caller from + subscribing for too long, or too often, or in a pattern that does not + reveal to the callee (through CC calls) that the subscriptions are + taking place. + + In legitimate use, CC event subscriptions will be made in stereotyped + ways that limit the disclosure of status information: + + 1. When a subscriber is selected for CC, a call should arrive + promptly for the callee, or the subscription should be + terminated. This expectation may be violated by a race condition + between selection of the subscription for CC and the caller + becoming unavailable, but it should be rare that a single + subscription will exhibit the race condition more than once. + + 2. Subscriptions should not remain suspended for longer than the + expected duration of a call (a call by the caller to a third + party). + + 3. Subscriptions should be initiated only shortly after failed + incoming calls. + + 4. Most of the time, a callee should have no queued subscriptions. + + Violations of these expectations should be detected by the callee's + monitor and reported as possible attempts at privacy violation. + + The CC facility may enhance the effectiveness of Spam over Internet + Telephony (SPIT) via the following technique: the caller makes calls + to a group of callees. The caller then requests CC for the calls + that do not connect to the callees. The resultant CC calls are + probably more likely to reach the callees than original calls to a + further group of targets. + + In order to prevent senders of SUBSCRIBE and PUBLISH requests from + causing Denial-of-Service (DoS) attacks and suspending other CC + entries than their own, a mechanism to correlate the identity of the + original caller and the sender of SUBSCRIBE and PUBLISH requests is + needed. The RECOMMENDED mechanism to authenticate the identity of + the originator of requests relevant to CC is the SIP Identity + mechanism [RFC4474]. Alternatively, CC agents and monitors within an + administrative domain or federation of domains MAY use the mechanism + described in [RFC3325] to authenticate their identities with a + P-Asserted-Identity header field. + + Furthermore, the use of the presence server to suspend or resume + SHOULD be limited to a caller that has an active queue in the + callee's monitor. This can be achieved first by monitoring and + + + +Worley, et al. Standards Track [Page 30] + +RFC 6910 Completion of Calls April 2013 + + + logging incoming calls to the callee and the destination where CC + indication was sent, then to ensure that subscription to the + call-completion event package is permitted only within a short time + frame after the initial call failed and to only accept PUBLISH + requests to the presence server if there is an active queue for the + caller in question. + + Note that regarding authentication/authorization/billing logic + subject to operator policy, CC calls or subscriptions do not differ + from other basic calls or event subscriptions. + +12. IANA Considerations + +12.1. SIP Event Package Registration for CC + + This specification registers an event package, based on the + registration procedures defined in [RFC6665]. The following + information is required for such a registration: + + Package name: call-completion + + Is this registration for a Template-Package: No. + + Published specification: RFC 6910. + + Person & email address to contact for further information: Martin + Huelsemann, martin.huelsemann@telekom.de + +12.2. MIME Registration for application/call-completion + + MIME media type name: application + + MIME subtype name: call-completion + + Required parameters: none. + + Optional parameters: none. + + Encoding considerations: Consists of lines of UTF-8-encoded + characters, ended with CRLF. + + Security considerations: There are no security considerations + internal to the media type. Its typical usage involves the security + considerations described in RFC 6910. + + Interoperability considerations: See RFC 6910. + + Published specification: RFC 6910. + + + +Worley, et al. Standards Track [Page 31] + +RFC 6910 Completion of Calls April 2013 + + + Applications that use this media type: The implementations of the CC + features of the Session Initiation Protocol. + + Additional information: + + Magic number(s): none + + File extension(s): Not expected to be stored in files. + + Macintosh file type code(s): Not expected to be stored in files. + + Person & email address to contact for further information: + Martin Huelsemann, martin.huelsemann@telekom.de + + Intended usage: LIMITED USE + + Restrictions on usage: none + + Author/Change controller: The IETF + +12.3. SIP/SIPS URI Parameter 'm' + + This specification defines one new SIP/SIPS URI parameter 'm' as per + the registry created by [RFC3969]. It is used to identify that an + INVITE request is a CC call, or to further identify that a SUBSCRIBE + request is for the call-completion event package. The parameter may + have a value that describes the type of the CC operation, as + described in this specification. + + Name of the parameter: m + + Predefined values: yes + + Reference: [RFC6910] + + + + + + + + + + + + + + + + + +Worley, et al. Standards Track [Page 32] + +RFC 6910 Completion of Calls April 2013 + + +12.4. The 'purpose' Parameter Value 'call-completion' + + This specification adds a new predefined value "call-completion" for + the 'purpose' header field parameter of the Call-Info header field. + This modifies the registry header field parameters and parameter + values by adding this RFC as a reference to the line for header field + "Call-Info" and parameter name 'purpose': + + Header field: Call-Info + + Parameter name: purpose + + Predefined values: yes + + Reference: [RFC3261] [RFC5367] [RFC6910] + +12.5. 'm' Header Parameter for Call-Info + + This specification extends [RFC3261] to add a new header field + parameter 'm' to the Call-Info header field. This adds a row to the + registry header field parameters and parameter values: + + Header field: Call-Info + + Parameter name: m + + Predefined values: yes + + Reference: [RFC6910] + + The predefined values are 'BS', 'NR', and 'NL'. + +13. Acknowledgements + + Thanks to Paul Kyzivat, John Elwell, Keith Drage, Andrew Hutton, + Thomas Stach, Dennis Luebbers, and Christer Holmberg, who provided + helpful comments, feedback, and suggestions. + + + + + + + + + + + + + + +Worley, et al. Standards Track [Page 33] + +RFC 6910 Completion of Calls April 2013 + + +14. References + +14.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, + A., Peterson, J., Sparks, R., Handley, M., and E. + Schooler, "SIP: Session Initiation Protocol", RFC 3261, + June 2002. + + [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer + Method", RFC 3515, April 2003. + + [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, + W., and J. Peterson, "Presence Information Data Format + (PIDF)", RFC 3863, August 2004. + + [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension + for Event State Publication", RFC 3903, October 2004. + + [RFC3969] Camarillo, G., "The Internet Assigned Number Authority + (IANA) Uniform Resource Identifier (URI) Parameter + Registry for the Session Initiation Protocol (SIP)", + BCP 99, RFC 3969, December 2004. + + [RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE- + Initiated Dialog Event Package for the Session Initiation + Protocol (SIP)", RFC 4235, November 2005. + + [RFC4474] Peterson, J. and C. Jennings, "Enhancements for + Authenticated Identity Management in the Session + Initiation Protocol (SIP)", RFC 4474, August 2006. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5367] Camarillo, G., Roach, A.B., and O. Levin, "Subscriptions + to Request-Contained Resource Lists in the Session + Initiation Protocol (SIP)", RFC 5367, October 2008. + + [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User + Agent URIs (GRUUs) in the Session Initiation Protocol + (SIP)", RFC 5627, October 2009. + + [RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, + July 2012. + + + +Worley, et al. Standards Track [Page 34] + +RFC 6910 Completion of Calls April 2013 + + +14.2. Informative References + + [ETS300.356-18] + European Telecommunications Standards Institute, + "Completion of Calls to Busy Subscriber (CCBS) + supplementary service", February 1995. + + [ITU-T.Q.733] + International Telecommunication Union, "Description for + Call Completion Supplementary Services Using SS No. 7", + February 1995. + + [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private + Extensions to the Session Initiation Protocol (SIP) for + Asserted Identity within Trusted Networks", RFC 3325, + November 2002. + + [RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. + Camarillo, "Best Current Practices for Third Party Call + Control (3pcc) in the Session Initiation Protocol (SIP)", + BCP 85, RFC 3725, April 2004. + + [RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and + K. Summers, "Session Initiation Protocol Service + Examples", BCP 144, RFC 5359, October 2008. + + + + + + + + + + + + + + + + + + + + + + + + + + +Worley, et al. Standards Track [Page 35] + +RFC 6910 Completion of Calls April 2013 + + +Appendix A. Example Caller's Agent + + This section outlines how an autonomous caller's agent can operate + using only standard SIP features to interact with the caller's UA. + This example is suitable only as a learning aid, as its performance + is poor. + + The agent monitors calls made from the UA(s) by subscribing to the + dialog event package of the UA(s). + + The UA(s) or their proxy routes calls made with either of two special + dial sequences to the agent, which interprets the INVITEs as + indications to make a CC request with BS or NR or NL mode for the + latest call made by the UA. + + The agent monitors the status of the UA(s) for availability to be + used for a CC call by examining the dialog events. + + The agent indicates to the UA(s) that CC recall is in progress by + making call to the UA(s). If the UA is answered, the agent assumes + that the caller is available and plays pre-recorded audio to indicate + that CC recall is in progress. + + After playing the pre-recorded audio, the caller's agent uses REFER + to order the UA to make the CC call to the callee. + +Appendix B. Example Callee's Monitor + + This section outlines how an autonomous callee's monitor can operate + using only standard SIP features to interact with the callee's UA. + This example is suitable only as a learning aid, as its performance + is poor. + + The callee's monitor monitors calls made to the UA(s) by subscribing + to the dialog events of the UA(s). This enables it to determine + their Call-Ids and their final response statuses. + + The proxy for the UA(s) routes to the callee's monitor any SUBSCRIBEs + for the call-completion event package directed to the URIs serviced + by the UA(s). + + The callee's monitor monitors the status of the UA(s) to determine + when they are in a suitable state to receive a CC call by watching + the busy/not-busy status of the UA(s): for example, a UA is available + for CCBS when it is not busy, but a UA is available for CCNR when it + becomes not busy after being busy with an established call. + + + + + +Worley, et al. Standards Track [Page 36] + +RFC 6910 Completion of Calls April 2013 + + +Authors' Addresses + + Dale R. Worley + Ariadne Internet Services, Inc. + 738 Main St. + Waltham, MA 02451 + US + + Phone: +1 781 647 9199 + EMail: worley@ariadne.com + + + Martin Huelsemann + Deutsche Telekom + Heinrich-Hertz-Strasse 3-7 + Darmstadt 64307 + Germany + + Phone: +4961515812765 + EMail: martin.huelsemann@telekom.de + URI: http://www.telekom.de + + + Roland Jesske + Deutsche Telekom + Heinrich-Hertz-Strasse 3-7 + Darmstadt 64307 + Germany + + Phone: +4961515812766 + EMail: r.jesske@telekom.de + URI: http://www.telekom.de + + + Denis Alexeitsev + TeleFLASH + Mainzer Landstrasse 47 + Frankfurt 60329 + Germany + + Phone: +49-69-257-378-230 + EMail: alexeitsev@teleflash.com + URI: http://www.teleflash.com + + + + + + + + +Worley, et al. Standards Track [Page 37] + |