Completion of Calls for the Session Initiation Protocol (SIP)
Extracted elements (27)
Because SIP forking allows a call to fail from the user's perspective while succeeding from SIP's (e.g., a busy user's call routed to voicemail returns 200 but the caller considers it 'no reply'), the caller's agent must record successful SIP calls as failures and callers must be able to invoke CC even after receiving a 200 response.
Unlike SS7/PSTN where intermediate media gateway controllers must implement CC, in SIP only the caller's UA and callee's UA (or their associated service systems) need CC support. Intermediate proxies and B2BUAs need only be transparent to ordinary SIP messages, simplifying deployment.
There is no interaction between SIP CC with queuing (this specification) and Automatic Redial (RFC 5359 Section 2.17, based on the dialog event package). The two solutions differ in callee's monitor and caller behavior; a CC event subscription and a dialog event subscription serve different roles and are independent.
A NOTIFY sent with non-zero expiration MUST contain the 'cc-state' parameter set to 'queued' or 'ready'. When the callee's monitor withdraws a selection (e.g., recall timer expires), it MUST send a NOTIFY with cc-state set to 'queued'.
Notifiers MUST generate NOTIFY requests whenever the CC request's state changes to 'queued' or 'ready'. The NOTIFY SHOULD include a cc-URI providing a globally routable URI for the CC recall INVITE and suspend/resume PUBLISH requests.
The callee's monitor MUST insert a Call-Info header field with 'purpose=call-completion' in the final response and at least one non-100 provisional response to the initial INVITE when enabling the CC feature. The provisional response SHOULD be sent reliably if the INVITE contained 'Supported: 100rel'.
The callee's monitor MUST NOT select for CC recall any CCE whose availability state is not 'available' or whose 'm' value does not indicate an available callee. Within those constraints, selection policy is determined by local implementation.
The caller's agent MUST NOT maintain more than one CC request for a single caller directed to a single original destination URI. If CC is requested a second time for the same destination, the agent MUST consolidate by reusing or terminating and recreating the existing subscriptions.
The default CC subscription duration is 3600 seconds (equivalent to the SS7 service duration timer maximum from ETSI/ITU-T). It is RECOMMENDED that subscribers request and notifiers grant a subscription time of at least 3600 seconds.
To suspend a CC request, the caller's agent SHALL publish PIDF state 'closed' via PUBLISH to each callee's monitor. To resume, the agent SHALL publish PIDF state 'open'. The PUBLISH SHOULD include an Expires header matching the remaining CC subscription duration.
Upon arrival of the CC call at the callee, the recall timer MUST be stopped. If the CC call succeeds, the callee's monitor MUST terminate the relevant subscription per RFC 6665 and MUST remove any associated presence event state used for suspend/resume.
Upon receiving a subscription refresh, the notifier MUST set the 'expires' parameter of the Subscription-State header to a value not higher than the current remaining subscription duration, regardless of any Expires header value in the refresh request.
Upon sending the CC recall notification (cc-state: ready), the callee's monitor MUST start a recall timer. The RECOMMENDED value is 10 to 20 seconds, matching the ETSI ETS 300.356-18 and ITU-T Q.733 recommendations for CC services.
When a notifier receives multiple forks of the same SUBSCRIBE (identified by matching Call-Id and overlapping request-URI scope), it MUST reject all but one with 482 Merged Request. Short-term queue-capacity denial requires 480 Temporarily Unavailable; permanent denial requires 403 Forbidden.
When generating CC SUBSCRIBE requests, the From URI MUST be the caller's AOR. The To URI SHOULD be the destination URI of the original call if known, and MUST otherwise be the request-URI of the SUBSCRIBE itself.
The 'call-completion' event package defined in this specification allows callers' agents to subscribe to CC status at callee's monitors. Notifications carry an 'application/call-completion' body reporting the CCE's cc-state ('queued' or 'ready'). The default and required MIME type is application/call-completion.
The callee's monitor signals CC availability by inserting a Call-Info header field with 'purpose=call-completion' into appropriate non-100 provisional and final responses to the initial INVITE. The required format is: Call-Info: monitor-URI;purpose=call-completion;m=XX, where the 'm' parameter conveys the failure mode.
The CC architecture comprises two logical components: a 'caller's agent' on the originating side and a 'callee's monitor' on the terminating side. These may be integrated into UAs, implemented as independent end-systems, or provided by centralized application servers, and either endpoint may support both roles independently.
The 'm' URI parameter identifies the CC mode: 'm=NR' (no reply, CCNR), 'm=BS' (busy subscriber, CCBS), and 'm=NL' (not logged in, CCNL). Implementations MUST accept CC operations where the 'm' parameter is missing or has an unknown value and execute them as best they can.
MIME type application/call-completion registered. Encoding: UTF-8 lines terminated with CRLF. Intended usage: LIMITED USE. Not expected to be stored in files. No security considerations internal to the media type.
New predefined value 'call-completion' added to the 'purpose' parameter of the Call-Info header field. New header field parameter 'm' added to Call-Info with predefined values 'BS', 'NR', and 'NL' for CC mode identification.
New SIP/SIPS URI parameter 'm' registered per RFC 3969, used in INVITE to mark a CC call and in SUBSCRIBE to indicate CC subscription mode. Predefined values: 'BS' (busy subscriber), 'NR' (no reply), 'NL' (not logged in).
SIP event package 'call-completion' registered per RFC 6665. Not a template package. Published specification: RFC 6910.
CC may enhance SPIT by allowing attackers to use CC callbacks (more likely to connect) as a high-yield follow-up to mass calling attempts. To prevent DoS via unauthorized SUBSCRIBE/PUBLISH suspending other callers' CC entries, SIP Identity (RFC 4474) is RECOMMENDED; P-Asserted-Identity (RFC 3325) is an alternative within trusted domains.
CC subscriptions intrinsically disclose callee availability status, diminishing callee privacy. Callee's monitors should limit per-caller and total disclosure, enforce that subscriptions are initiated only shortly after failed calls, and detect patterns (long suspension, frequent subscription) as possible privacy attacks.
Each CC Entity (CCE) in the callee's monitor queue has two orthogonal states: availability state ('available' when PIDF is 'open', 'unavailable' when 'closed') and recall state ('queued' on creation, changed to 'ready' when selected for CC recall). A CCE is eligible for recall only when availability='available' and its 'm' value indicates an available callee.
The CC Information Format is an ABNF-defined MIME type (application/call-completion) consisting of header-like lines: cc-state (REQUIRED when NOTIFY expiry is nonzero, values 'queued' or 'ready'), cc-service-retention ('true' when retain option supported), and cc-URI (addr-spec for CC call and suspend/resume PUBLISH). Names are case-insensitive; unknown lines are ignored.