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)
AbstractThe "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.
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. 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
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
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.
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.
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.
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.
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.
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.
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.
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).
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.
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 18.104.22.168 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. 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).
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. 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.
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. 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
'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). 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].
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.
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. 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.
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. 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.
Caller Callee sip:email@example.com sip:firstname.lastname@example.org | | | INVITE sip:email@example.com | [original call] | From: sip:firstname.lastname@example.org | |------------------------->| | | | 487 | | Call-Info:<sip:email@example.com>;purpose=call-completion;m=NR |<-------------------------| | | | SUBSCRIBE sip:firstname.lastname@example.org;m=NR [initial SUBSCRIBE] | From: sip:email@example.com | | Contact: sip:firstname.lastname@example.org | | Request-Disposition: parallel | Call-Id: abcd-efgh | | Event: call-completion | |------------------------->| | | | 200 | |<-------------------------| | | | NOTIFY sip:email@example.com | [initial NOTIFY] | Body: cc-state: queued | |<-------------------------| | | | SUBSCRIBE sip:firstname.lastname@example.org;m=NR [another init. SUB.] | From: sip:email@example.com| | Request-Disposition: parallel | Call-Id: abcd-efgh | | Event: call-completion | |------------------------->| | | | 482 | [duplicate SUB. rej.] |<-------------------------| | | | NOTIFY sip:firstname.lastname@example.org | [CC invoked] | Body: cc-state: ready | | URI: sip:email@example.com |<-------------------------| | | | INVITE sip:firstname.lastname@example.org;m=NR [CC call] | From: sip:email@example.com| |------------------------->| | | | NOTIFY sip:firstname.lastname@example.org | [CC terminated] | Expires = 0 | |<-------------------------|
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:email@example.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 22.214.171.124 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.
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:firstname.lastname@example.org sip:email@example.com | | | NOTIFY sip:firstname.lastname@example.org | [CC notification, caller not | Body: cc-state: ready | available for CC recall] | URI: sip:email@example.com |<-------------------------| | | | 200 | |------------------------->| | | | PUBLISH sip:firstname.lastname@example.org | [non-availability for recall | From: sip:email@example.com | is published] | Contact: sip:firstname.lastname@example.org | | Event: presence | | Content-Type: 'app/pidf' | | Body: status=closed | |------------------------->| | | | 200 | |<-------------------------| | | | | [caller becomes available | | again] | | | PUBLISH sip:email@example.com | [availability for recall | From: sip:firstname.lastname@example.org | is published] | Contact: sip:email@example.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.
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. 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. 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.
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. 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.
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. Section 9.4.
A notifier MAY receive multiple forks of the same SUBSCRIBE, as defined by Section 126.96.36.199 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.
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].
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
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. 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, firstname.lastname@example.org
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, email@example.com Intended usage: LIMITED USE Restrictions on usage: none Author/Change controller: The IETF 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]
RFC3261] [RFC5367] [RFC6910] 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'.
[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.
[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.
http://www.telekom.de Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany Phone: +4961515812766 EMail: firstname.lastname@example.org URI: http://www.telekom.de Denis Alexeitsev TeleFLASH Mainzer Landstrasse 47 Frankfurt 60329 Germany Phone: +49-69-257-378-230 EMail: email@example.com URI: http://www.teleflash.com