RFC 6910
Completion of Calls for the Session Initiation Protocol (SIP)
RFC 6910: Completion of Calls for the Session Initiation Protocol (SIP) 📞✨
Okay bestie, this one is RFC 6910 💖, titled Completion of Calls for the Session Initiation Protocol (SIP). It's a Standards Track doc from April 2013 🗓️, published by the IETF (ISSN 2070-1721). The authors are D. Worley from Ariadne Internet Services, Inc., M. Huelsemann and R. Jesske from Deutsche Telekom, and D. Alexeitsev from TeleFLASH 🫶. It doesn't obsolete or update any other RFCs, so nothing gets replaced here 🌸.
Abstract
The "completion of calls" feature 🎀 lets the caller of a failed call get notified when the callee is free to receive a call. So you don't have to keep redialing and guessing 😭.
For a basic version with no queue, this doc points at the dialog event package (RFC 4235). It's described as 'Automatic Redial' in "Session Initiation Protocol Service Examples" (RFC 5359) 💅.
For a fuller version with a queue, this doc brings in an architecture 🧚. The "completion of calls" implementations on the caller's and callee's endpoints work together. They put the caller's request into a queue at the callee's endpoint. When a request is ready to be serviced, the original failed call gets re-attempted 🦋.
The architecture is built to play nicely with existing completion of calls solutions in other networks 👑.
Status of This Memo
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community 🌈. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. For more on Internet Standards, check Section 2 of RFC 5741 🍓.
For the current status, any errata, and how to give feedback, go to 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) as in effect on the date of publication 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come 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
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 ..............................361. Introduction 🌟
The Completion of Calls (CC) feature 💫 lets the caller of a failed call get the call completed without making a new attempt while guessing when the callee is available. When the caller asks for CC, the callee gets monitored for availability 👀. Once the callee becomes available, the callee gets a set time window to start a call 🕰️. If the callee doesn't start a new call in that window, the caller gets recalled 📲. When the caller accepts the CC recall, a CC call to the callee starts automatically 🦄. If several callers have asked for CC on the same callee, they get recalled in a predefined order. That order is usually the order they asked for CC in 🎀.
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 doesn't answer the call. The caller is recalled after the callee has completed a new call 📞.
- Completion of Calls on Not Logged-in (CCNL): The callee isn't 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 ✨
okay so before the good stuff, the doc sets up some vocab so everyone's on the same page 🎀 these terms are the whole vibe, so bookmark them bestie 💖
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. 📵
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. 📭
Plot twist: a call can be a "success" in SIP land and still be a failed call in the caller's world. Voicemail said "hi" and the caller said "nope" 💀
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
okay, the architecture section is where the pieces get their jobs 🧩
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 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. 🗂️
4.2. CC Procedures ✨
Okay bestie, here's the CC handshake 💅 The caller's UA sends an INVITE to a request-URI, and one or more forks of that request reach one or more of the callee's UAs. If the CC feature is available, the callee's monitor (there can be a monitor for each of the callee's UAs, iykyk) inserts a Call-Info header field with its URI and purpose=call-completion into appropriate non-100 provisional or final responses to the initial INVITE, then 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. Once the caller gets a non-100 provisional or final response saying CC is available, the calling user can invoke CC 🎀
The caller tells their agent they want CC on the recent call. Now here's the tea 🫖 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. Like, the call might've gone straight to the callee's voicemail, which returns a 200 to the INVITE, but from the caller's side it's giving "no reply" 💀
To get the info needed to complete the call at the callee, the caller's agent subscribes to the call-completion event package at the callee's monitor 🦋
The chance of the caller completing the call at the callee is called the CC state (cc-state) of the caller. The cc-states are "queued" and "ready" (for CC) 🌸
To hear from every place the callee might 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 show up in Call-Info header fields in provisional and final responses to the INVITE). Each callee's monitor reads that subscription as "this caller wants CC for this particular callee" 👑
Each callee's monitor keeps a list or queue of subscriptions from callers' agents, which represent their CC requests. These subscriptions get created, refreshed, and terminated following the procedures of [RFC6665] 🧚
When a SUBSCRIBE comes in from the caller's agent, the callee's monitor makes a presence state for the caller's UA. The caller's UA can change it to show availability for the CC call. Right after it's created, the caller's presence status at the callee's monitor is "open" ✨
When the callee's monitor decides the callee and/or the callee's UA is free for a CC call, it picks a caller and sends a CC event update (cc-state: ready) in a NOTIFY request to that caller's agent's subscription, telling it to start the CC call to the callee's UA 🔥
When the caller's agent gets this update, it starts a CC recall by calling the caller's UA, then kicks off the CC call to the callee's UA using third-party call control in line with [RFC3725]. The agent can also check other ways whether the caller is available for the CC call. If the caller is available, the agent tells the caller's UA to start the CC call to the callee's UA 💖
The agent marks the CC call as special by adding a specific SIP URI parameter to the Request-URI, so the callee's monitor can give it precedence when reaching the callee's UA 🌈
If the caller isn't available when the "ready for recall" notification lands, the agent pauses the CC request at the callee's monitor by sending a PUBLISH request with presence info to the callee's monitor's presence server, saying the presence status is "closed". Once the caller is free again, the agent resumes the CC request by sending another PUBLISH to the callee's monitor, saying the presence status is "open" 🫶
When the monitor gets a suspension request, it monitors the next non-suspended CC request in the queue. When it gets a resume from the previously suspended caller's agent that was at the top of the queue, it goes back to monitoring that caller's agent 🍓
When a CC call fails, there are two possible options: either the caller's agent has to activate CC again by subscribing to the callee's monitor, OR CC stays activated and the original CC request keeps its spot in the queue, if the retain option is supported 😭
The retain option (see Section 3) decides what the callee's monitor does when a CC call fails. If the retain option is supported, CC stays activated and the original CC request keeps its position in the queue. Otherwise, CC gets deactivated and the caller's agent would have to subscribe again to reactivate it 🙈
A monitor that supports the retain option includes the cc-service-retention header in its CC events. A caller's agent that also supports the retain option uses that header to know it should NOT generate a new CC request after a failed call 💅
Monitors that don't support the retain option don't include the cc-service-retention header. For them, a failed CC call means the CC request gets deleted from the queue, and these monitors terminate the matching subscription of the caller's agent to let it know its CC request isn't in the queue anymore. A caller's agent that doesn't support the retain option can also end its subscription when a CC call fails, so both the caller's agent and the callee's monitor might be signaling the termination at the same time. This is a totally normal SIP events [RFC6665] scenario 🦋 After the subscription is gone, the caller's agent can create a new subscription (as described in Section 6.2) to reactivate CC for the original call ✨
4.3. Automatic Redial as a Fallback
Automatic Redial is a simple end-to-end design, and you can read about its scenario in [RFC5359], Section 2.17 🌸 This one is built on the dialog event package. If the callee is busy when the call arrives, the caller subscribes to the callee's call state. The callee's UA sends a notification whenever the callee's call state changes, so the caller also gets told when it changes to 'terminated'. The caller gets alerted, and then the caller's UA starts a call establishment to the callee again 📞
Here's the catch 🙈 If several callers have subscribed to a busy callee's call state, they all get notified at the same moment the call state changes to 'terminated'. That means several recalls might start at the exact same time! Basically, it's a heuristic approach with no guarantee of success 💀
There's no interaction between CC and Automatic Redial, because the callee's monitor and the caller behave differently when they use the dialog event package for receiving dialog information or for aggregating a CC state 🎀
4.4. Differences from SS7
Okay, so SIP CC is different from the CCBS and CCNR features of SS7 (the one used in the Public Switched Telephone Network (PSTN)) in a few ways 🧚 Let's go through them so it's easier to get 💖
SS7 has no equivalent to the forking mechanism, so in the PSTN, calls can be clearly labeled as successful or unsuccessful 🌈 But SIP has super complex forking situations, so a call can fail from the user's point of view and still get a success response from SIP's point of view. (This can happen even in simple setups! Like, a call to a busy user that fails over to their voicemail gets a SIP success response, even though the caller might think of it as "busy subscriber" 💀) So the caller MUST be able to invoke CC even when the original call looked like it succeeded 👑 To make that work, the caller's agent has to record successful calls as well as unsuccessful ones 🫶
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 it to work between the UAs ✨ Intermediate SIP systems (proxies or back-to-back user agents (B2BUAs)) don't need to implement CC. They just need to be transparent to the usual range of SIP messages 🦋 In the PSTN, on the other hand, intermediate nodes like media gateway controllers have to implement the CC service 🔥
5. CC Queue Model 🎀
Okay so the callee's monitor handles CC for a single URI 💅 This is probably a published AOR, or lowkey more likely a "non-voicemail AOR", but it could be as tiny as one UA's contact URI 🦋 The monitor keeps a dynamic set of CC entities (called "CCEs") 🧚 Each CCE stands for a CC request, or basically an existing incoming CC subscription. This whole set is also called a queue, because a queue data structure is often what helps the monitor actually carry out its policies for picking CCEs for CC recall 👑
Each CCE has an availability state, and it's decided by the caller's presence status at the monitor ✨ A presence status of "open" means the CCE is "available", and "closed" means it's "unavailable" 🌸
Each CCE also has a recall state that you can see through subscriptions. It's either "queued" or "ready" 💜
Each CCE carries the From URI from the SUBSCRIBE request that created it 🍓
CC subscriptions show up at the monitor by hitting the URIs the monitor gave back in Call-Info header fields 🫶 The request-URI of that SUBSCRIBE decides which queue the CCE gets added to, and the subscription reports the status of that queue. The base event data is the status of all the CCEs in the queue, but each subscription only gets back the status of its own CCE 💅 (Further standardization may define means for obtaining more comprehensive information about a queue.)
When a CCE is created, it starts out with availability state "available" and recall state "queued" 🦋
When the callee's monitor gets PIDF bodies [RFC3863] through PUBLISH requests [RFC3903], those PUBLISH requests are expected to come from subscribers who want to indirectly suspend and resume their CC requests by changing the CCE's availability state 🙈 A CCE gets identified by the request-URI (if it came from a CC event notification that identifies the CCE) or by the From URI of the request, which has to match the From URI recorded in the CCE. A PUBLISH with status "open" sets the availability state to "available" (resume), and status "closed" sets it to "unavailable" (suspend) ⭐
A CC request is only eligible for recall 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 are made by the callee's monitor's local policy 🔥 Often, the monitor will pick the acceptable CCE that has been waiting in the queue the longest 🌈 Once the monitor has selected a CCE for recall, it changes that CCE's recall state from "queued" to "ready", and that triggers a notification on the CCE's subscription 🔔
If a selected subscriber then suspends its request by sending a PUBLISH with presence status "closed", the CCE becomes "unavailable" and the monitor flips its recall state back to "queued" 😭 This may cause another CCE (e.g., one that has been in the queue for less time) to get 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 might come in the Call-Info header field in provisional and final responses to the INVITE that the callee's monitor(s) sent back 🦋 On top of that, the caller's agent SHOULD include the original request-URI it sent the original INVITE to in its set of callee's monitor URIs, especially when it's unclear whether the call forked to extra callees whose responses the caller hasn't seen 🧚 A SUBSCRIBE to just the original request-URI is used when the caller's agent hasn't received or doesn't remember any callee's monitor URI 🫶 The caller's agent SHOULD add an 'm' parameter to these URIs so the callee's monitor knows which CC mode is wanted 💅 That '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 keep things from getting redundant, 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 can do that 🔥
The agent MUST NOT maintain more than one CC request for a single caller that's 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 one, either by reusing the existing CC subscriptions or by terminating them and then recreating them 🍓 For this purpose, equality of callers is determined by comparing their 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 it and can put it in the To header), and otherwise MUST be the request-URI of the SUBSCRIBE 🎀
The SUBSCRIBE SHOULD have header fields that optimize its routing. In particular, it SHOULD contain Request-Disposition: parallel and an Accept-Contact header field to rule out callee UAs the caller wouldn't find acceptable 🚀
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 for the SUBSCRIBE to fail, in which case CC cannot be invoked for this original call 😬
If the caller's agent no longer wants to start 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 of its other subscriptions to CC, by following the step in Section 6.5. That way, no other CC requests from this caller can receive CC recalls 🙅♀️ The caller's agent then 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) 📞
6.4. Initiating a CC Call
If the caller is available for the CC call and willing to start it, the caller's agent makes the caller's UA 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, so it can state its preferences in CC processing and prioritize the CC call ✨ The INVITE SHOULD be addressed to the URI specified in the cc-URI of the NOTIFY. 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 either, it MAY use the request-URI of the original INVITE, if this URI was recorded 🧚 The last choice may not give ideal routing, but in simple cases it's 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 until the conditions relevant to the caller's agent's local suspension policy 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 lives, following the procedures in [RFC3903], and giving the PIDF state "closed" for the caller's identity as presentity 🙈 The PUBLISH request SHOULD contain an Expires header field whose value matches the current remaining CC subscription duration ⏳
Each PUBLISH SHOULD be sent to the CC URI as received in the NOTIFY, or within the corresponding SUBSCRIBE dialog. If that's not possible, it goes to the corresponding callee's monitor URI received in the Call-Info header field of the NOTIFY, or, if one isn't available, to the Contact address of the subscription 🗺️
6.6. Resuming CC
When the caller is no longer busy, or the conditions relevant to the caller's agent's suspension policy have changed, 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, following the procedures in [RFC3903], telling each monitor that the PIDF state is "open". This request gets built the same way as the suspend PUBLISH request otherwise 💖
If the caller's agent has sent several CC suspension requests to different callee's monitors, and the caller becomes available again (as decided by the caller's agent's local resumption policy), the caller's agent MAY send a PUBLISH to resume a CC request to each callee's monitor where there's a suspended CC request ✨ Heads up: the resumption policy may require a manual resumption, so a suspended CC request should not be automatically resumed 🚨
7. Callee's Monitor Behavior 🌟
7.1. Sending the CC Possible Indication ✨
okay so the callee's monitor MUST record the From URI, and it MAY record the final request status(es) that the callee's UA(s) return 📝
if the callee's monitor wants the caller to be able to use the CC service 🎀, it MUST insert a Call-Info header field with purpose=call-completion into the final response (like a 486 for a busy subscriber) and into at least one non-100 provisional response (like a 180 for no response) to the initial INVITE when it forwards that INVITE to the caller. the non-100 provisional response 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's a globally routable URI [RFC5627] for the callee's monitor. in practice it may be the callee's AOR, and the SUBSCRIBE will only get routed to the callee's monitor because it specifies Event: call-completion 🦋
to enable CC, the Call-Info header field MUST be set up according to this scheme:
Call-Info: monitor-URI;purpose=call-completion;m=XXthe m parameter defines the "mode" of CC 🧚 m=NR means it failed due to lack of response, m=BS means it failed due to busy subscriber, and m=NL means it failed due to non-registered subscriber (no devices are registered for the AOR contacted). the m parameter is useful for PSTN interworking and for assessing presence information in the callee's monitor. other values might be defined in the future 🌸 it's 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) 💀
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 the UA(s) it's servicing, and to any URIs the callee's monitor provides in Call-Info header fields. the SUBSCRIBEs MUST be processed according to the procedures defined in [RFC6665], which establishes subscriptions. these subscriptions represent the caller's agent's request 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're redundant forks of one SUBSCRIBE request. 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 according to 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 caller's agent's subscription tells the callee's monitor that the caller's agent is prepared to initiate the CC call if it's selected for the "ready" state. if the callee's monitor becomes aware of a subscription that can't be selected for a CC recall, it SHOULD terminate the subscription according to [RFC6665] 🍓
7.3. Sending a CC Notification 🎀
the call-completion event package returns various bits of info to the caller's agent, but the vital datum in it 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's a globally routable URI [RFC5627] for the callee's monitor. in practice it may be the callee's AOR, and the SUBSCRIBE will only get routed to the callee's monitor because it specifies Event: call-completion 💅
the call-completion event package gives limited info about the policy of the callee's monitor. in particular, just like in the PSTN, the cc-service-retention datum gives an indication of the "service retention" attribute, which shows whether the CC request can be continued to a later time if the CC call fails because the callee's UA(s) are busy. if the callee's monitor supports the service-retention option, it SHOULD include the cc-service-retention parameter 🦋
the callee's monitor has a policy about 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, how long the CC requests have been active, and any previous attempts at 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", it 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 matches the recommendation for the CC services in the ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733] documents ⏰
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. when the CC call arrives, the recall timer MUST be stopped. if the CC call doesn't arrive at the callee's UA(s) before the recall timer expires, 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 isn't 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 later. if the CC call succeeds, the callee's monitor MUST terminate the relevant subscription according to [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 not, the policy of the callee's monitor MAY specify that another CC request for a recall be selected. also note 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 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 🌈
receiving the PUBLISH request starts 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 one hasn't been set up 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, depending on the implementation.
the monitor SHOULD identify the addressed CCE by the request-URI of the PUBLISH request, or, if that isn't possible, by the From URI 💅
if processing 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. 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 isn't busy and there's no entry in the CC queue that's currently being processed, the callee's monitor MUST process the queue as described in Section 7.3 above 🎉
8. Examples 🎬
Okay, here's a basic call flow, bestie! It only shows the most significant messages of a CC activation and invocation, so it's giving highlight reel. Heads up that this is just an example, and the failure responses might vary 💅
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 |
|<-------------------------|So the original call is an ordinary INVITE, and it fails with no-response (ring-no-answer) 📞 The callee's governing proxy sends back a 487 because it canceled the INVITE to the UA after it rang way too long with no answer. That 487 carries a Call-Info header field with purpose=call-completion, which is basically the proxy saying "yes, CC is available for this failed fork of the call" ✨ The m=NR parameter tells you it failed due to no-response, which is super useful for PSTN interworking and for 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, that's a globally routable URI for the callee's monitor. In practice it might just be the callee's AOR, and the SUBSCRIBE still gets routed to the callee's monitor because it says Event: call-completion 🦋
CC gets activated by sending a SUBSCRIBE to all known callee's monitor URIs. You can get these from the Call-Info header field in the response to the INVITE.
The caller's agent also has to include the original request-URI in its set of callee's monitor URIs, because the call might have forked to other callees whose responses the caller never saw 👀 (A SUBSCRIBE to the request-URI alone is for when the caller's agent hasn't received or can't remember any callee's monitor URI.)
The caller's agent adds an m parameter to these URIs if it's possible. Here, it forks the SUBSCRIBE to two destinations, as defined by Section 8.2.2.2 of [RFC3261], with the right Request-Disposition. The first SUBSCRIBE goes to the URI from Call-Info.
The second SUBSCRIBE goes to the original request-URI and lands at the same callee's monitor. Since it has the same Call-Id as the SUBSCRIBE that already reached the monitor, the monitor rejects it with a 482, so no redundant subscriptions 🙅♀️
The initial NOTIFY for the successful SUBSCRIBE has cc-state: queued in its body. Eventually this caller gets selected for CC and hears about it through a NOTIFY with cc-state: ready. That NOTIFY carries a URI where the INVITE for the CC call should go. In practice, that might be the callee's AOR 🎀
The caller generates a new INVITE to the URI in the NOTIFY. If there wasn't one, or the caller's agent can't remember it, it can use the original request-URI instead. The caller adds the m parameters, if possible, to specify CC processing.
Last but not least, the callee's monitor terminates the subscription for the CC request 🔚
Here's another flow, showing only the most significant messages of CC suspension and resumption, bestie 💖
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 |
|<-------------------------|
| |So the caller gets selected for CC and is told via a NOTIFY containing cc-state: ready. But right now, the caller is not available for the CC recall 🙈
To update its presence event state at the callee's presence server, the caller sends a PUBLISH telling the server that the PIDF state is "closed". The PUBLISH gets sent in this order of preference: (1) out-of-dialog to the CC URI from the NOTIFY, (2) within the corresponding SUBSCRIBE dialog, (3) out-of-dialog to the corresponding callee's monitor URI from the Call-Info header field of the NOTIFY, or (4) out-of-dialog to the remote Contact address of the corresponding SUBSCRIBE dialog. Ranked, bestie 📊
When the caller is available for the CC recall again, it updates its presence event state at the callee's presence server by sending a PUBLISH that says the PIDF state is "open". That request gets built 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 💜
Quick aside: if the callee has a caller-queuing facility, the callee's monitor might want to treat the CC queue as part of that queuing facility and put info about the queue's state in the event package. How that info gets 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. This package's name is call-completion, and that value shows up 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. Nothing to see here, bestie 🫶
9.3. SUBSCRIBE Bodies
[RFC6665] requires package definitions to define how bodies in SUBSCRIBE requests get used, if at all.
The SUBSCRIBE request MAY contain an Accept header field. If there's no such header field, its default value is 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. That body defines a filter to apply to the subscription. Filter documents aren't specified in this document and might be the subject of future standardization work 🔮
A SUBSCRIBE request asks for CC information about calls recently made from the same caller to the callee UA(s) the notifier services. Calls count as "from the same caller" if the URI-part of the From header field value in the INVITE matches 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're explicitly specified ⏰
If a SUBSCRIBE doesn't explicitly request a duration, the default requested duration is 3600 seconds. That's because it's the highest service duration timer value recommended for CC services in the ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733] documents. Since the subscription duration means no explicit timer is needed, and it can be seen as the equivalent of the SS7 service duration timer, this specification also calls the subscription duration 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, the requested subscription can no longer proceed to the "ready" state after a certain duration, 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 🙅♀️
9.5. NOTIFY Bodies 💌
Okay so [RFC6665] says package definitions have to spell out which body types are allowed in NOTIFY requests, and which default to use when the SUBSCRIBE has no Accept header field. A NOTIFY for a call-completion event package MUST contain a body that describes the CC states. 💅
As [RFC6665] explains, the NOTIFY carries bodies that describe the state of the subscribed resource. That body has to be in a format listed in the SUBSCRIBE's Accept header field, or in the package's default format if the SUBSCRIBE left the Accept header out. 🎀
In this event package, the notification body is a CC document. All subscribers and notifiers MUST support the "application/call-completion" data format from Section 10, no exceptions 🫶. The SUBSCRIBE request MAY contain an Accept header field. If there isn't one, it defaults to "application/call-completion". If there is one, it MUST include "application/call-completion". And obviously, the notifications the server generates MUST be in one of the formats listed in the SUBSCRIBE's Accept header field ✨.
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, so they can receive CC notifications. Generating those requests can mean using 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. This applies no matter what the Expires header field said in the refresh, if it was there at all 🧚.
If a subscription doesn't work out because the CC queue has hit its maximum number of entries (short-term denial), the notifier MUST send a 480 Temporarily Unavailable response to the subscriber, possibly with a retry-after parameter based on the notifier's policy. If it fails because something has come up that prevents the CC service and will keep preventing it (long-term denial), the notifier MUST send a 403 Forbidden response to the subscriber 🙈.
A notifier MAY receive multiple forks of the same SUBSCRIBE, as defined in Section 8.2.2.2 of [RFC3261]. In that 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, so all subscriptions SHOULD be handled with the security considerations from Section 11 firmly in mind, especially when it comes to verifying the identity of the subscriber. This is not the place to cut corners, bestie 😭🔐
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 sent with a non-zero expiration MUST contain the "cc-state" parameter. Its value MUST be "queued" if the CC request behind the subscription is not currently selected by the callee's monitor for CC recall. Its value MUST be "ready" if the request is currently selected by the callee's monitor for CC recall 🍓.
A NOTIFY sent with a zero expiration (like confirming a request to unsubscribe) MAY contain the "cc-state" parameter 💜.
When the callee's monitor withdraws the selection of the request for CC recall (for example, because the caller's agent hasn't started 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. That 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 a subscriber receives a NOTIFY request with cc-state set to "ready", it SHOULD suspend all of its other CC subscriptions for the original call at other notifiers. Getting that NOTIFY also triggers an interaction with the instances on the subscriber's side that are responsible for starting the CC recall. Main character energy, but make it coordinated ✨.
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 how it processes the information it gets from them, following the procedures in this document 💖.
9.11. Rate of Notifications ⏱️
The CC service typically involves a single notification per notifier and per subscription about the change to "ready" (for CC). It MAY involve several notifications about the change to the "ready" state, though, separated by a CC call that failed because the callee was busy. Typically, notifications are at least tens of seconds apart. Notifiers SHOULD NOT generate more than three notifications for one subscription in any ten-second interval. Since avoiding useless recalls really matters, a notifier SHOULD send state changes to "queued" from "ready" promptly. So a notifier SHOULD NOT send a state change to "ready" as the third notification in a ten-second interval, because 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. Nothing to see here, babe 🫶.
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 shown below. Generally, the CC body is read the same way as SIP headers 🎀: (1) the names of the lines are case-insensitive, (2) lines can be continued across line boundaries if the succeeding lines start with horizontal white space, and (3) lines with unknown names are ignored. Each header line 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-headerThe rules above whose names start with "cc-" are described below. Other rules are described in [RFC3261] 📚.
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" means a subscriber's entry in the CC queue is not selected for CC recall. The value "ready" means 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 support for the retain option. The retain option, if supported at the callee, keeps the entry in the CC queue when a CC call has failed because of a callee busy condition. If this parameter is present, the retain option is supported. If it isn't, the retain option isn't 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 allows 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-spec11. Security Considerations 🔐✨
Okay bestie, this part is serious 😭 The CC facility lets the caller's agent figure out some status info about the callee, and that info literally makes the callee's privacy smaller 🥺 So to protect it enough, the overall amount of disclosure must be limited, and the amount of disclosure to any single caller must be limited too.
Of course, if a caller is not permitted to call the callee, that caller should not be allowed to establish a CC subscription. Callers who are super sensitive about their privacy may reject all CC subscriptions 🙈 But in the ordinary case, the optimal protection is to permit any caller to subscribe while preventing 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. Main character energy for privacy 💅
In legit use, CC event subscriptions show up in super stereotyped ways that keep the status disclosure small:
- 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.
- Subscriptions should not remain suspended for longer than the expected duration of a call (a call by the caller to a third party).
- Subscriptions should be initiated only shortly after failed incoming calls.
- 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 🚨 Not it!!
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, then requests CC for the calls that do not connect to those callees. The resultant CC calls are probably more likely to reach the callees than original calls to a further group of targets. Yikes, that's a sneaky one.
In order to stop senders of SUBSCRIBE and PUBLISH requests from causing Denial-of-Service (DoS) attacks and from suspending other CC entries that aren't their own, a mechanism is needed to correlate the identity of the original caller with the sender of those SUBSCRIBE and PUBLISH requests. 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 you make sure subscription to the call-completion event package is permitted only within a short time frame after the initial call failed, and only accept PUBLISH requests to the presence server if there is an active queue for the caller in question. Very strict, very iconic 👑
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.de12.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.
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 IETF12.3. SIP/SIPS URI Parameter 'm'
This specification defines one new SIP/SIPS URI parameter 'm' as per the registry created by [RFC3969]. It's 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]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. It also modifies the registry for 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 for 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. Iconic squad 💜
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.
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.
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. The agent 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 a 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 ✨
okay bestie, this one is a fun little learning aid 🎀 It shows how an autonomous callee's monitor can work using only standard SIP features to chat with the callee's UA. Fair warning though: its performance is poor, so treat it as a sketch, not a production plan 💀
The monitor keeps tabs on calls to the UA(s) by subscribing to their dialog events 👀 That's how it finds out their Call-Ids and their final response statuses. Iconic, right?
The proxy for the UA(s) routes any SUBSCRIBEs for the call-completion event package that are aimed at the URIs the UA(s) serve over to the callee's monitor 🦋
The callee's monitor also watches the busy/not-busy status of the UA(s) to figure out when they're ready to take a CC call 💅 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. The timing difference is everything, no cap 🫶
Authors' Addresses
Here are the authors and their contact details, copied exactly as they appear in the original 💖
Dale R. Worley:
Dale R. Worley
Ariadne Internet Services, Inc.
738 Main St.
Waltham, MA 02451
US
Phone: +1 781 647 9199
EMail: worley@ariadne.comMartin Huelsemann:
Martin Huelsemann
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt 64307
Germany
Phone: +4961515812765
EMail: martin.huelsemann@telekom.de
URI: http://www.telekom.deRoland Jesske:
Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt 64307
Germany
Phone: +4961515812766
EMail: r.jesske@telekom.de
URI: http://www.telekom.deDenis Alexeitsev:
Denis Alexeitsev
TeleFLASH
Mainzer Landstrasse 47
Frankfurt 60329
Germany
Phone: +49-69-257-378-230
EMail: alexeitsev@teleflash.com
URI: http://www.teleflash.comThat's the whole document, bestie! 🌈👑 Four legends wrote this, and it's giving pure main character energy 🧚
📦 where this page comes from
- ietf: rfc6910 2013-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms