wdiff rfc6910.original rfc6910.txt

bliss
Internet Engineering Task Force (IETF) D. Worley
Internet-Draft
Request for Comments: 6910 Ariadne Internet Services, Inc.
Intended status:
Category: Standards Track M. Huelsemann
Expires: August 15, 2013
ISSN: 2070-1721 R. Jesske
Deutsche Telekom
D. Alexeitsev
TeleFLASH
February 11,
April 2013

Call

Completion of Calls for the Session Initiation Protocol (SIP)
draft-ietf-bliss-call-completion-19

Abstract

The call completion "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' 'Automatic Redial' in the SIP "Session Initiation
Protocol Service Examples 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 "call completion" "completion of
calls" implementations associated with the caller's and callee's
endpoints cooperate to place the caller's request for call completion of
calls into a queue at the callee's endpoint, and 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 call-
completion of calls solutions in other networks.

Status of this This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum 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 six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 15, 2013.
http://www.rfc-editor.org/info/rfc6910.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 ....................................................3
2. Requirements terminology . . . . . . . . . . . . . . . . . . . 5 Terminology ........................................4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 .....................................................4
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 ........................................................6
4.1. Call-completion architecture . . . . . . . . . . . . . . . 8 CC Architecture ............................................6
4.2. Call-completion procedures . . . . . . . . . . . . . . . . 9 CC Procedures ..............................................8
4.3. Automatic redial Redial as a fallback . . . . . . . . . . . . . . 12 Fallback ............................11
4.4. Differences from SS7 . . . . . . . . . . . . . . . . . . . 12 ......................................11
5. Call-completion queue model . . . . . . . . . . . . . . . . . 13 CC Queue Model .................................................12
6. Caller's agent behavior . . . . . . . . . . . . . . . . . . . 14 Agent Behavior ........................................13
6.1. Receiving the CC possible indication . . . . . . . . . . . 14 Possible Indication ......................13
6.2. Subscribing to CC . . . . . . . . . . . . . . . . . . . . 14 .........................................13
6.3. Receiving a CC recall notification . . . . . . . . . . . . 16 Recall Notification ........................14
6.4. Initiating a CC call . . . . . . . . . . . . . . . . . . . 16 Call ......................................15
6.5. Suspending CC . . . . . . . . . . . . . . . . . . . . . . 16 .............................................15
6.6. Resuming CC . . . . . . . . . . . . . . . . . . . . . . . 17 ...............................................15
7. Callee's monitor behavior . . . . . . . . . . . . . . . . . . 17 Monitor Behavior ......................................16
7.1. Sending the CC possible indication . . . . . . . . . . . . 17 Possible Indication ........................16
7.2. Receiving a CC subscription . . . . . . . . . . . . . . . 18 Subscription ...............................17
7.3. Sending a CC notification . . . . . . . . . . . . . . . . 19 Notification .................................18
7.4. Receiving a CC call . . . . . . . . . . . . . . . . . . . 20 Call .......................................19
7.5. Receiving a CC suspension . . . . . . . . . . . . . . . . 20 Suspension .................................19
7.6. Receiving a CC resumption . . . . . . . . . . . . . . . . 21 Resumption .................................20
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 .......................................................20
9. Call-completion event package . . . . . . . . . . . . . . . . 26 'call-completion' Event Package ................................24
9.1. Event package name . . . . . . . . . . . . . . . . . . . . 26 Package Name ........................................24
9.2. Event package parameters . . . . . . . . . . . . . . . . . 26 Package Parameters ..................................24
9.3. SUBSCRIBE bodies . . . . . . . . . . . . . . . . . . . . . 26 Bodies ..........................................25
9.4. Subscribe duration . . . . . . . . . . . . . . . . . . . . 27 Duration ........................................25
9.5. NOTIFY bodies . . . . . . . . . . . . . . . . . . . . . . 27 Bodies .............................................26
9.6. Subscriber generation Generation of SUBSCRIBE requests . . . . . . . 28 Requests ...............26
9.7. Notifier processing Processing of SUBSCRIBE requests . . . . . . . . 28 Requests .................26
9.8. Notifier generation Generation of NOTIFY requests . . . . . . . . . . 28 Requests ....................27
9.9. Subscriber processing Processing of NOTIFY requests . . . . . . . . . 29 Requests ..................27
9.10. Handling of forked requests . . . . . . . . . . . . . . . 29 Forked Requests ..............................28
9.11. Rate of notifications . . . . . . . . . . . . . . . . . . 29 Notifications ....................................28
9.12. State agents . . . . . . . . . . . . . . . . . . . . . . . 30 Agents .............................................28
10. Call-completion information format . . . . . . . . . . . . . . 30 CC Information Format .........................................28
10.1. Call-completion status . . . . . . . . . . . . . . . . . . 30 CC Status ................................................29
10.2. Call-completion service-retention indication . . . . . . . 30 CC Service-Retention Indication ..........................29
10.3. Call-completion CC URI . . . . . . . . . . . . . . . . . . . 31 ...................................................29
11. Security considerations . . . . . . . . . . . . . . . . . . . 31 Considerations .......................................29
12. IANA considerations . . . . . . . . . . . . . . . . . . . . . 32 Considerations ...........................................31
12.1. SIP event package registration Event Package Registration for call-completion . . . . 33 CC ....................31
12.2. MIME registration Registration for application/call-completion . . . . 33 ........31
12.3. SIP/SIPS URI parameter Parameter 'm' . . . . . . . . . . . . . . . . 34 ...............................32
12.4. Call-Completion purpose parameter value . . . . . . . . . 34 The 'purpose' Parameter Value 'call-completion' ..........33
12.5. 'm' header parameter Header Parameter for Call-Info . . . . . . . . . . . . 35 .......................33
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 ..............................................33
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 ....................................................34
14.1. Normative References . . . . . . . . . . . . . . . . . . . 35 .....................................34
14.2. Informative References . . . . . . . . . . . . . . . . . . 36 ...................................35
Appendix A. Example Caller's Agent . . . . . . . . . . . . . . . 37 ................................36
Appendix B. Example Callee's Monitor . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 ..............................36

1. Introduction

The call completion Completion of Calls (CC) feature allows the caller of a failed
call to have the call completed without having to make a new call
attempt while guessing when the callee becomes available. When the
caller requests the use of the CC feature, the callee will be
monitored for its availability. When the callee becomes available available,
the callee will be given a certain timeframe time frame for initiating a call.
If the callee does not initiate a new call within this timeframe, time frame,
then the caller will be recalled. When the caller accepts the CC recall
recall, then a CC call to the callee will automatically start. If
several callers have requested the CC feature on the same callee,
they will be recalled in a predefined order, which is usually the
order in which they have requested the CC feature.

This draft document defines the following CC features:

Call

Completion on of Calls to Busy Subscriber (CCBS): The callee is busy.
The caller is recalled after the callee is not busy any longer.

Call no longer busy.

Completion of Calls on No Reply (CCNR): The callee does not answer
the call. The caller is recalled after the callee has completed a
new call.

Call

Completion of Calls on Not Logged-in (CCNL): The callee is not
registered. The caller is recalled after the callee has
registered again.

2. Requirements terminology Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].

This document uses terms from [RFC3261].

3. Terminology

For the purpose of this service, we provide the following
terminology:

Callee: a destination of the original call, and a target of the CC
call.

Caller: The 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 which that implements the call-
completion CC queue
for destination user(s)/UA(s), 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 SS7 Signaling System 7
(SS7) CC.

Caller's agent: a logical component which 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 call completion: Completion of Calls: a service which 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 Call Completion on of Calls to Busy Subscriber: a CC service
provided when the initial failure was that the destination UA was
busy.

CCNR, or Call Completion of Calls on No Reply: a CC service provided when
the initial failure was that the destination UA did not answer.

CCNL, or Call 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 which 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",
"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 call-
completion 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 which that stores incoming
calls which that are target targets for call completion. CC. Note: This buffer may or may not
be organized as a queue. The use of the term "queue" is by
analogy with analogous
to SS7 usage.

CCE, or call-completion entity: CC Entity: the representation of a CC request,
or or,
equivalently, an existing call-completion CC subscription within the queue of a
callee's monitor's queue monitor.

Failed call: a call which 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,
voicemail but the caller desired to speak to the callee in person, real
time, the INVITE receives a 200 response, but the caller considers
the call to have failed.

Notifier: the user agent UA that generates NOTIFY requests for the purpose of
notifying subscribers of the callee's availibility; availability; for the CC service
service, this is the task of the callee's monitor.

Original call: the initial call which that failed to reach a desired
destination.

Retain option: a characteristic of the CC service; if supported, CC
calls which 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 user agent UA that receives NOTIFY requests with information of
the callee's availibility; availability; for the CC service service, this is the task of
the caller's agent.

Suspended CC request: a CC request which that is temporarily not to be
selected for CC recall.

4. Solution

4.1. Call-completion architecture CC Architecture

The call-completion CC architecture augments each caller's UA (or UAC) User Agent Client
(UAC)) wishing to use the call-completion CC features with a "call-completion "CC agent" (also written
as "caller's agent").

It augments each callee's UA (or UAS) User Agent Server (UAS)) wishing to
be the target of the
call-completion CC features with a "call-completion "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 call
completion CC will
have both functions so that it can participate in
call completion 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 AOR. 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 for to invoke the call completion 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-user(s) 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) callee(s), and the
callee's UA(s) is out of the scope of this document, as is also the policy
by which the callee's monitor arbitrates between multiple
call-completion 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], [RFC6665] [RFC4235] and [RFC3515], as described
in the Appendixes. 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 recently made call which 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 to 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 their caller's the callee's status, the
identity of callers, and their the final response' statuses. 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. E.g., 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. Call-completion procedures CC Procedures

The caller's UA sends an INVITE to a request URI. request-URI. One or more forks
of this request reach one or more of the callee's UAs. If the call-
completion CC
feature is available, the callee's monitor (note there can be a
monitor for each of the callee's UAs) inserts a Call-Info header
field with its URI and with "purpose=call-completion" in appropriate
non-100 provisional or final response responses to the initial INVITE and
forwards them to the caller. The provisional response SHOULD be sent
reliably,
reliably if the INVITE contained a Supported header field with the
option tag 100rel. On receipt of a non-100 provisional or a final
response with the indication that the call-completion CC feature is available, the
calling user can invoke the CC feature.

The caller indicates to the caller's agent that he wishes to invoke
call-completion
CC services on the recent call. Note that from the SIP point of
view, the INVITE may have been successful, but from the user's point
of view, the call may have been unsuccessful. E.g., For example, the call
may have connected to the callee's voicemail, which would return a
200 status to the INVITE but from the caller's point of view is "no
reply".

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
call-completion event package at the callee's monitor.

The possibility of the caller to complete completing the call at the callee is
also known as the call-completion CC state (cc-state) of the caller. The cc-states
comprehend the values 'queued' "queued" and 'ready' "ready" (for call-
completion). 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 callee's monitor URIs of the callees'
monitors (which are provided by Call-Info header fields in
provisional and final responses to the INVITE). The Each callee's
monitor uses the subscription as an indication that the caller is
interested in using the CC feature with regard to the specified particular
callee. The

Each callee's monitor keeps a list or queue of the caller's agent's subscriptions, subscriptions from
callers' agents, representing the requests from the caller's agent callers' agents
to the callee's
monitors monitor for call-completion 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
which
that can be modified by the caller's UA to indicate its availability
for the CC call. The Upon instantiation, the caller's presence status at
the presence upon instantiation 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 call-completion CC event update (''cc-state: ready'') ("cc-state: ready") via a NOTIFY
request to the selected subscription of the caller's agent's subscription, 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, UA and then starts the CC call to the
callee's UA, using 3rd party 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 the 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 callee's monitor's presence server, server of the callee's monitor, informing
about
the server that the presence status 'closed'. 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 about the monitor that the presence status 'open'. is "open".

On the receipt of the suspension request, the callee's monitor performs
the monitoring for the next non-suspended CC request in the queue.
On the 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 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 Section 3) determines the callee's monitor's behavior of the
callee's monitor when a CC call fails. If the retain option is
supported, CC remains activated activated, and the original CC request
retains its position in the queue. Otherwise 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
cc-service-retention header in its call-completion 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
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 caller's agent's 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 signalling signaling the
termination of the subscription concurrently. This is a normal SIP Events [ [RFC6665]]
events [RFC6665] scenario. After the subscription is terminated, the
caller's agent may create a new subscription (as described in section
Section 6.2) to reactivate the CC feature for the original call.

4.3. Automatic redial Redial as a fallback Fallback

Automatic redial Redial is a simple end-to-end design. An automatic redial Automatic Redial
scenario is described in [RFC5359], section Section 2.17. This solution is
based on the usage of the dialog event package. When 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 of with this solution is, 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 call completion CC and automatic redial, 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 call completion CC state.

4.4. Differences from SS7

SIP call completion CC differs in some ways from the CCBS and CCNR features of SS7
(which is used in the PSTN). Public Switched Telephone Network (PSTN)). For
ease of understanding, we enumerate some of the differences here.

As there is no equivalent to the forking mechnism mechanism in SS7, in the PSTN
PSTN, calls can be clearly differentiated between as successful or
unsuccessful. Due to the complex forking situations that are
possible in SIP, a call may "fail" fail from the point of view of the user
and yet have a "success" success response from SIP's point of view. (This can
happen even in simple situations: e.g., a call to a busy user that
fails over to his voicemail receives a SIP success response, even
though the caller may consider it "busy subscriber".) Thus, the
caller must be able to invoke call completion CC even when the original call appeared
to succeed. To support this, the caller's agent must record
successful calls as well as unsuccessful calls.

In SIP, only the caller's UA or service system on the originating
side and the callee's UA or service system on the terminating side
need to support call completion CC for call completion CC to work successfully between the UAs.
Intermediate SIP systems (proxies or
B2BUAs) back-to-back user agents
(B2BUAs)) do not need to implement call completion; CC; they only need to be
transparent to the usual range of SIP messages. In the PSTN also PSTN,
additionally, intermediate nodes like media gateway controllers have
to implement the call completion CC service.

5. Call-completion queue model CC Queue Model

The callee's monitor manages CC for a single URI. This URI is likely
to be a published AOR, or more likely "non-voicemail AOR", but it may
be as narrowly scoped as a single UA's contact URI. The callee's
monitor manages a dynamic set of call-completion CC entities (called
"CCEs") "CCEs"), which
represent CC requests, or equivalently, the existing incoming call-completion CC
subscriptions. This set is also called a queue, because a queue data
structure often aids in implementing the
callee's monitor's policies of the callee's
monitor for selecting CCEs for CC recall.

Each CCE has an availability state, determined through the caller's
presence status at the callee's monitor. A presence status of
''open'' "open"
represents a CCE's availability state of 'available' "available", and a presence
status of "closed" represents a CCE's availability state of
'unavailable'.
"unavailable".

Each CCE has a recall state which that is visible via subscriptions. The
recall state is either "queued" or "ready".

Each CCE carries the From URI of the SUBSCRIBE request that caused
its creation.

CC subscriptions arrive at the callee's monitor by addressing the
URIs the callee's monitor returns in Call-Info header fields. The
request URI
request-URI of the SUBSCRIBE request determines the queue to which
the resulting CCE is added. The resulting subscription reports the
status of the queue. The base event data is the status of all the
CCEs in the queue, but the data returned by each subscription is
filtered to report only the status of that subscription's CCE.
(Further standardization may define means for obtaining more
comprehensive information about a queue.)

When a CCE is created, it is given the availability state "available"
and recall state "queued".

When the callee's monitor receives PIDF Presence Information Data Format
(PIDF) bodies [RFC3863] via PUBLISH requests [ [RFC3903]], [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 call-completion CC
event notification which 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' of 'open' status "open" sets the availability state of the CCE to
'available'
"available" (resume); 'status' of 'closed' status "closed" sets the availability state of
the CCE to 'not-available' "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's selections 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' "queued" to 'ready', "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', "closed", the CCE becomes not-
available,
"unavailable", and the callee's monitor changes the CCE's recall
state to
'queued'. "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 caller's agent's subscription of the
caller's agent at the callee's monitor is terminated.

6. Caller's agent behavior Agent Behavior

6.1. Receiving the CC possible indication 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, proxies; in the case of 4xx responses
responses, some 4xx responses are more likely to be sent to the
caller.

6.2. Subscribing to CC

For CC activation activation, the caller's agent MUST send a SUBSCRIBE to all
known callee's monitor URIs. A callee's monitor URI may be provided
in the Call-Info header field in provisional and final responses to
the INVITE sent back by the callee's monitor(s). Additionally, the
caller's agent SHOULD include the original request-URI that it sent
the original INVITE to, in its set of callee's monitor URIs, when it
is unclear if the call has forked to additional callees whose
responses the caller has not seen. A SUBSCRIBE to the original
request-URI alone is used in cases where the caller's agent has not
received or does not remember any callee's monitor URI. The caller's
agent SHOULD add an 'm' parameter to these URIs in order to indicate
the desired call-completion proceeding at
to the callee's monitor. 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 transaction, as defined by section
Section 8.2.2.2 of [RFC3261], if the caller's agent is capable of
doing so.

The agent MUST NOT maintain more than one CC request for a single
caller and directed to a single original destination URI. If a
caller requests CC a second time for the same destination URI, the
agent MUST consolidate the new request with the existing CC request
by either reusing the existing CC subscriptions or terminating and
then recreating them. For this purpose, equality of callers is
determined by comparing caller's callers' AORs and equality of destination
URIs is determined by comparing them per [RFC3261] section 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), 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", 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, 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 subclause Section 6.5.

6.3. Receiving a CC recall notification Recall Notification

When receiving a NOTIFY with the cc-state set to 'ready', "ready", the
caller's agent SHOULD suspend all other subscriptions to CC, by
following the step in section Section 6.5, in order to prevent any other CC
requests from this caller to receive 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. e.g., by calling the
caller's UA(s).

6.4. Initiating a CC call Call

If the caller is available for the CC call and willing to initiate
the CC call, the caller's agent causes the caller's UA to generate a
new INVITE towards the callee. The caller's UA MAY add a an 'm' URI
parameter with the value of the 'm' parameter received in the
Call-Info header in the response to the original INVITE, in order to
specify his preferences in CC processing and to prioritize the CC
call. The INVITE SHOULD be addressed to the URI specified in the
cc-URI of the NOTIFY, or or, if that's not available available, it SHOULD use the
URI in the Call-Info header field of the response to the original INVITE, or
INVITE; if that's not
available available, it MAY use the request-URI of the
original INVITE, if this URI was recorded. Note that the latter
choice may not provide ideal routing, but but, in simple cases cases, it is
likely to reach the desired
callee/callee's 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, again or if the conditions relevant to the caller's
agent's local suspension
policy for suspensions of the caller's agent have changed. To suspend the CC
request, the caller's agent SHALL publish the caller's presence state
by sending a PUBLISH request to each callee's monitor where the
presence server for CC resides in accordance with the procedures
described in [RFC3903] , [RFC3903], giving the PIDF state 'closed' "closed" for the
caller's identity as presentity. The PUBLISH request SHOULD contain
an Expires header field with a value that corresponds to the current
value of the remaining CC subscription duration.

Each PUBLISH SHOULD be sent to the CC URI as received in the NOTIFY,
or within the corresponding SUBSCRIBE dialog, or if that is not
possible, to the corresponding callee's monitor URI received in the
Call-Info header field of the NOTIFY, or if one is not available, the
Contact address of the subscription.

6.6. Resuming CC

When the caller is no longer busy, or if the conditions relevant to
the caller's agent's suspension policy of the caller's agent have changed, then the CC
request SHALL be resumed by the caller's agent. To resume a CC
request, the caller's agent SHALL publish the Caller's caller's presence state
by sending a PUBLISH request to each callee's monitor a PUBLISH
request in accordance
with the procedures described in [RFC3903] , [RFC3903], informing about each monitor
that the PIDF state 'open' but is "open"; this request will otherwise be
constructed as in the same way as the suspend PUBLISH request. These PUBLISH requests are sent
to presence server that are instantiated at a CC monitor.

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 caller's agent's local policy
about 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 caller's agent's policy about resumption policy of the caller's agent may
prescribe a manual resumption and thus resumption; thus, a suspended CC request should
not be automatically resumed.

7. Callee's monitor behavior Monitor Behavior

7.1. Sending the CC possible indication Possible Indication

The callee's monitor MUST record the From URI and MAY record the
final request status(es) returned by the callee's UA(s).

If the callee's monitor wants to enable the caller to make use of the
CC service, it MUST insert a Call-Info header field with
"purpose=call-completion" in the final response message (e.g. (e.g., in a
486 to enable call-completion CC due to busy subscriber) and at least one non-100
provisional response message (e.g. (e.g., in a 180 due to no response) to
the initial INVITE when forwarding it to the caller. The non-100
provisional response message SHOULD be sent reliably if the INVITE
contained a Supported header field with the option tag 100rel. The
Call-Info header field values defined in this specification
positively indicates 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 call-completion. CC. Ideally, it
is a globally-routable globally routable URI [RFC5627] for the callee's monitor. In
practice, it may be the callee's AOR, and the SUBSCRIBE will be
routed to the callee's monitor only because it specifies "Event:
call-completion".

In order to enable call-completion, CC, the Call-Info header field MUST be set up
according to the following scheme:

Call-Info:monitor-URI;purpose=call-completion;m=XX

Call-Info: monitor-URI;purpose=call-completion;m=XX

The 'm' parameter defines the "mode" of call completion. 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 non-registered
subscriber (no devices are registered for the AoR 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 allowed 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 at its 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 Subscription

The callee's monitor MUST be prepared to receive SUBSCRIBEs for the
call-completion event package directed to the URIs of UA(s) that it
is servicing and any URIs that the callee's monitor provides in Call-
Info
Call-Info header fields. The SUBSCRIBEs MUST be processed in
accordance with the procedures defined in [RFC6665].

The callee's monitor(s) that receive the SUBSCRIBE establish [RFC6665], establishing
subscriptions. These subscriptions represent the caller's agent's request from the
caller's agent for call-completion 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: 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 Section 19.1.4), (3) the To URIs
(which should be the request-URI of the original call) have the same
user and hostpart 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 caller's agent's 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' "ready" state. If the
callee's monitor becomes aware of a subscription which that cannot be
selected for a CC recall, it SHOULD terminate the subscription in
accordance with [RFC6665].

7.3. Sending a CC notification Notification

The call-completion event package returns various points of
information to the caller's agent, but the vital datum it contains is
the cc-state of the caller's agent's CC request of the caller's agent as stored in the
CC queue, which queue; in the
beginning beginning, this cc-state is 'queued'. "queued". When the
cc-state of the agent's request changes, the callee's monitor MUST
send a NOTIFY for a call-
completion CC event to the caller's agent. The notification
SHOULD also contain a URI which that can be used for suspension requests.
Ideally, it is a globally-routable globally routable URI [RFC5627] for the callee's
monitor. In practice, it may be the callee's AOR, and the SUBSCRIBE
will be routed to the callee's monitor only because it specifies
"Event: call-completion".

The call-completion event package provides limited information about
the policy of the callee's monitor's policy. monitor. In particular, like as in the PSTN,
the
"'cc-service-retention" "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
service-retention option, the callee's monitor SHOULD include the cc-service-
retention
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. (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. Usually the 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. Usually the 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 caller's agent's subscription of the caller's agent with the cc-state
set to 'ready' "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 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 call
completion CC
services in the ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733]. [ITU-T.Q.733]
documents.

7.4. Receiving a CC call Call

The callee's UA(s) and the callee's monitor may give the CC call
precedence over non-CC calls by evaluating the presence of the 'm'
URI parameter and the From header of the INVITE request. The
callee's monitor supervises the receiving of the CC call. Upon
arrival of the CC call call, the recall timer MUST be stopped. If the CC
call does not arrive at the callee's UA(s) before the expiry of the
recall timer, the callee's monitor SHOULD stop processing the recall
and change the value of the cc-state datum to "queued" if it supports
the retain option option, and terminate the subscription along with the queue if it doesn't
support the retain option. Similarly, if the CC call is not
accepted, the callee's monitor will stop the CC recall processing.
Depending on its policy, the same original call may be selected again
for a CC recall at a later time. If the CC call succeeds, the
callee's monitor MUST terminate the relevant subscription in
accordance with [RFC6665], [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 callee's monitor's policy of the callee's monitor MAY select specify that another CC
request for a recall according to the callee's monitor's policy. be selected. Note also that according to the callee's monitor's
policy of the callee's monitor several recalls may be processed at
the same time.

7.5. Receiving a CC suspension Suspension

The monitor may receive PUBLISH requests to suspend CC requests from
the caller's agent as described in section 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"
"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 functionality of the callee's
monitor as specified in [RFC3903] , [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 at the 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 Section 6.5, the callee's monitor MUST stop the recall
timer and MUST ensure that the request is set to a 'queued' "queued" state,
and then the callee's monitor MUST attempt to process another CC
request in the queue according to the callee's monitor's its local policy.

7.6. Receiving a CC resumption Resumption

When a CC request becomes has been resumed by receiving after the callee's monitor has
received a PUBLISH request from the caller's agent as described in section
Section 6.6, the presence event state for the caller's identity at
the presence server functionality 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 which that is currently being processed, the callee's monitor MUST
process the queue as described in section Section 7.3 above.

8. Examples

A basic call flow, with only the most significant messages of a call-
completion CC
activation and invocation shown, is as follows (please note that this
is an example example, and there may be variations in the failure responses):

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: status: 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: status: 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 |
|<-------------------------|
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
Call-Info header field positively indicates that CC is available for
this failed fork of the call. The "m=NR" parameter indicates that it
failed due to no-response, which is useful for PSTN interworking and
assessing presence information in the callee's monitor.

The URI in the Call-Info header field (<sip:456@z.b.com>) is where
the caller's agent should subscribe for call-completion CC processing. Ideally, it
is a globally-routable 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 Section 8.2.2.2 of [RFC3261], with
appropriate Request-Disposition. The first SUBSCRIBE is to the URI
from Call-Info.

The second SUBSCRIBE is to the original request-URI, 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 "state: "cc-state:
queued" in its body. Eventually, this caller is selected for CC, CC and
is informed of this via a NOTIFY containing "state: "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

Finally, the subscription for the CC request is terminated by the
callee's monitor.

Another flow, with only the most significant messages of call-
completion CC
suspension and resumption shown, is as follows:

Caller Callee
sip:123@a.com sip:456@b.com
| |
| NOTIFY sip:123@y.a.com | [CC notification, caller not
| Body: status: cc-state: ready | available for CC recall]
| URI: sip:recall@z.b.com
|<-------------------------|
| |
| 200 |
|------------------------->|
| |
| PUBLISH sip:456@z.b.com | [non-availibility [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 | [availibility [availability for recall
| From: sip:123@a.com | is published]
| Contact: sip:123@y.a.com |
| Event: presence |
| Content-Type: 'app/pidf' |
| Body: status=open |
|------------------------->|
| |
| 200 |
|<-------------------------|
| |

The caller is selected for CC, CC and is informed of this via a NOTIFY
request containing "state: "cc-state: ready". At this time, the caller is
not available for the CC recall.

For updating his its presence event state at the callee's presence server
functionality at the callee,
server, the caller generates 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, or (2) within the corresponding SUBSCRIBE
dialog, or if that is not possible, (3) out-of-dialog to the corresponding callee's monitor URI
received in the Call-Info header field of the NOTIFY, or if one is not available, (4) out-of-
dialog to the remote Contact address of the
subscription, informing about the PIDF state 'closed' . corresponding SUBSCRIBE
dialog.

When the caller is again available for the CC recall, he the caller
updates his presence event state at the callee's presence server functionality
at the callee by
generating a PUBLISH request informing about the server that the PIDF state 'open', but
is "open"; this request will otherwise be constructed as in the same way
as the suspend PUBLISH request.

9. Call-completion event package 'call-completion' Event Package

This section specifies the call-completion event package, in
accordance with section 4.4 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 call-completion CC queue as part of the queuing facility,
facility and include in the event package information regarding the
state of the queue. How this information is conveyed is left for
further standardization.

9.1. Event package name Package Name

The SIP Events events specification [RFC6665] requires package definitions
to specify the name of their package or template-package. The name
of this package is "call-completion". This value appears in the
Event and
Allow-events Allow-Events header fields.

9.2. Event package parameters Package Parameters

No package-specific Event header field parameters are defined for
this event package.

9.3. SUBSCRIBE bodies Bodies

[RFC6665] requires package definitions to define the usage, if any,
of bodies in SUBSCRIBE requests.

The SUBSCRIBE request MAY contain an Accept header field. If no
such header field is present, it has a default value of "application/
call-completion".
"application/call-completion". If the header field is present, it
MUST include "application/call-completion".

A SUBSCRIBE request for a call-completion 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, document and may be the subject of future
standardization activity.

A SUBSCRIBE request requests call-completion CC information regarding calls recently
made from the same caller to the callee UA(s) serviced by the
notifier. Calls are defined to be "from the same caller" if the
URI-part of the From header field value in the INVITE is the same as
the URI-part of the From header field value in the SUBSCRIBE.

9.4. Subscribe duration Duration

[RFC6665] requires package definitions to define a default value for
subscription durations, 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 call completion CC services in the ETSI
[ETS300.356-18] and ITU-T [ITU-T.Q.733]. As because of [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 not any more 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.

9.5. NOTIFY bodies Bodies

[RFC6665] requires package definitions to describe the allowed set of
body types in NOTIFY requests, 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 call-completion 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 call-
completion CC
document. All subscribers and notifiers MUST support the
"application/call-completion" data format described in section 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".
"application/call-completion". If the header field is present, it
MUST include "application/call-completion". Of course, the
notifications generated by the server MUST be in one of the formats
specified in the Accept header field in the SUBSCRIBE request.

9.6. Subscriber generation Generation of SUBSCRIBE requests Requests

Subscribers MUST generate SUBSCRIBE requests when they want to
subscribe to the call-completion event package at the terminating
side in order to receive call-completion CC notifications. The generation of
SUBSCRIBE requests can imply the usage of a call-
completion service specific CC service-specific timer
as described in section Section 9.4.

9.7. Notifier processing Processing of SUBSCRIBE requests 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 subscription,
regardless of the value received in the Expires header field (if
present) of the subscription refresh.

If a subscription is not successful because the call-completion CC queue has reached
the maximum allowed number of entries (short term (short-term denial), the
notifier MUST send a 480 Temporarily Unavailable response to the
subscriber, possibly with a Retry-after header field retry-after parameter in accordance with
the notifier's policy. If a subscription is not successful because a
condition has occurred that prevents and will continue to prevent the call-completion
CC service (long term (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 by section Section 8.2.2.2 of [RFC3261]. In such a case, the
notifier MUST reject all but one of the SUBSCRIBEs with a 482 Merged
Request response response, unless some other failure response applies.

The call-completion CC information can be sensitive. Therefore, all subscriptions
SHOULD be handled with consideration of the security considerations
discussed in section Section 11, in particular for verifying the identity of
the subscriber.

9.8. Notifier generation Generation of NOTIFY requests Requests

Notifiers MUST generate NOTIFY requests when the CC request's state
changes to 'queued' "queued" or to 'ready "ready (for call-completion)'. CC)". A NOTIFY that is sent
with non-zero expiration MUST contain the "cc-state" parameter. The
parameter's value MUST be "queued" if the call-
completion CC request represented by
the subscription is not at this time selected by the callee's monitor
for CC recall, and the parameter's value MUST be "ready" if the
request is at this time selected by the callee's monitor for CC
recall.

A NOTIFY sent with a zero expiration (e.g., as a confirmation of a
request to unsubscribe) MAY contain the "cc-state" parameter.

When the callee's monitor withdraws the selection of the request for
the CC recall (e.g., because the caller's agent has not initiated the
CC recall INVITE before the CC recall timer expires, or because the
agent has suspended the request from being considered for CC recall),
the notifier MUST send a NOTIFY to the subscription of the selected
request. This NOTIFY MUST contain the "cc-state" parameter set to
"queued".

If the call-completion CC subscription was successful and the retain option is
supported at the callee, the NOTIFY MUST contain the "cc-
service-retention"
"cc-service-retention" parameter.

9.9. Subscriber processing Processing of NOTIFY requests Requests

When receiving a NOTIFY requests request with the cc-state set to 'ready', "ready",
subscribers SHOULD suspend all other CC subscriptions for the
original call at other notifiers. The receipt of a NOTIFY request
with the cc-state set to 'ready' "ready" by the subscriber will also cause an
interaction with the instances at the subscribers subscriber's side hat that are
responsible for starting the CC recall.

9.10. Handling of forked requests Forked Requests

Forked requests are expected to be common for the call-completion CC event type. The
subscriber MUST be prepared to process NOTIFY requests from multiple
notifiers and to coordinate its processing of the information
obtained from them in accordance with the procedures in this
document.

9.11. Rate of notifications Notifications

The call completion CC service typically involves a single notification notification, per notifier
and per subscription that notifies about subscription, regarding the change to
'ready "ready" (for call-completion)', CC) but
MAY involve several notifications about the change to the 'ready' "ready"
state, separated by a call completion CC call that failed due to a busy callee . callee.
Typically, notifications will be separated by at least tens of
seconds. Notifiers SHOULD NOT generate more than three notifications
for one subscription in any ten-second interval. Since it is
important to avoid useless recalls, a notifier SHOULD send state
changes to "queued" from "ready" promptly. Thus, a notifier SHOULD
NOT send a state change to "ready" as the third notification in a
ten-second interval, as that would make it impossible to promptly
send a further state change to "queued".

9.12. State agents Agents

State agents have no defined role in the handling of the call-
completion
call-completion event package.

10. Call-completion information format CC Information Format

The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) as described in [RFC5234]. The formal syntax for the
application/call-completion MIME type is described below. In
general, the call-completion 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 call-completion CC information format document.

call-completion = 1*(cc-header CRLF)

cc-header = cc-state / cc-service-retention / cc-URI / extension-
header
extension-header

The above rules whose names start with "cc-" are described below.
Other rules are described in [RFC3261].

10.1. Call-completion status 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 present, unless the expiration
time indicated in the NOTIFY is zero.

cc-state = "cc-state" HCOLON ( "queued" / "ready" )

The value "queued" indicates that a subscriber's entry in the call-
completion CC
queue is not selected for CC recall. The value "ready" indicates
that a user's entry in the call-completion CC queue has been selected for CC recall.

10.2. Call-completion service-retention indication CC Service-Retention Indication

The service-retention line indicates the support of the retain
option. The retain option, if supported at the callee, will maintain
the entry in the CC queue, if a CC call has failed due to a callee
busy condition. If present, this parameter indicates that the retain
option is supported, otherwise supported; otherwise, it is not supported. This parameter
MAY be present in NOTIFY requests.

cc-service-retention = "cc-service-retention" HCOLON "true"

10.3. Call-completion CC URI

The cc-URI line provides a URI (possibly in the form of a name-addr)
which that the agent SHOULD use as the
request-URI of the CC recall INVITE and the suspend/resume PUBLISH.
It SHOULD be provided in all NOTIFYs. The URI SHOULD be globally
routable and SHOULD uniquely identify the CCE in question. The
syntax provides for generic-params in the value, but this document
defines no such parameters. Parameters that are not understood by
the subscriber MUST be retained with the URI.

cc-URI = "cc-URI" HCOLON addr-spec

11. Security considerations Considerations

The CC facility allows the caller's agent to determine some status
information regarding the callee. This information intrinsically
diminishes the privacy of the callee; in order to protect
sufficiently the privacy of the callee, the overall amount of
disclosure must be limited, and the amount of disclosure to any
single caller must be limited.

Of course, if a caller is not permitted to call the callee, that
caller should not be allowed to establish a CC subscription. Callers
that are particularly sensitive about their privacy may reject all CC
subscriptions. But in the ordinary case, the optimal protection is
to permit any caller to subscribe, 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) by via the following technique: The 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 resulting are
probably more likely to reach the callees than original calls to a
further group of targets.

In order to prevent Denial senders of Service SUBSCRIBE and PUBLISH requests from
causing Denial-of-Service (DoS) attacks and manipulations
of the call-completion queue by suspending other call-completion CC
entries than the their own, a mechanism to correlate the identity of the
original caller and the generator sender of the SUBSCRIBE and PUBLISH
request requests is
needed. The RECOMMENDED mechanism to authenticate the identity of
the originator of call-completion relevant requests relevant to CC is the SIP Identity
mechanism [RFC4474] . [RFC4474]. Alternatively, CC agents and monitors within an
administrative domain or federation of domains MAY use the mechanism
described in [RFC3325] to authenticate their
identity identities with a
P-Asserted-Identity header field.

Furthermore, the use of the presence server functionality to suspend or resume
SHOULD be limited to a caller which that has an active queue in the
callee's monitor. This can be achieved first by monitoring and
logging incoming call calls to the callee and the destination where CC
indication was sent, then to ensure that subscription to the call
completion
call-completion event package is permitted only within a short timeframe time
frame after the initial call failed and to only accept PUBLISH request
requests to the presence server functionality if there is an active queue for the
caller in question.

Note that regarding the authentication/authorization/billing logic
subject to operator policy policy, CC calls or subscriptions do not differ
from other basic calls or event subscriptions.

12. IANA considerations Considerations

12.1. SIP event package registration Event Package Registration for call-completion CC

This specification registers an event package, based on the
registration procedures defined in [RFC6665]. The followings is the following
information is required for such a registration:

Package Name: name: call-completion

Is this registration for a Template-Package: No.

Published Document: RFC XXXX (Note for RFC Editor: Please fill in
XXXX with the specification: RFC number of this specification). 6910.

Person and e-mail & email address to contact for further information: Martin
Huelsemann, martin.huelsemann@telekom.de

12.2. MIME registration 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 CR-LF CRLF.

Security considerations: There are no security considerations
internal to the media type. Its typical usage involves the security
considerations described in RFC XXXX

(Note for RFC Editor: Please fill in XXXX with the RFC number of this
specification). 6910.

Interoperability considerations: See RFC XXXX (Note for RFC Editor:
Please fill in XXXX with the RFC number of this specification). 6910.

Published specification: RFC XXXX (Note for RFC Editor: Please fill
in XXXX with the RFC number of this specification) 6910.

Applications that use this media type: the The implementations of the
call-completion CC
features of the Session Initiation Protocol Protocol.

Additional information:

Magic number(s): none

File extension(s): not Not expected to be stored in files files.

Macintosh file type code(s): not Not expected to be stored in files 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 The IETF

12.3. SIP/SIPS URI parameter Parameter 'm'

This specification defines one new SIP/SIPS URI parameter 'm' as per
the registry created by [RFC3969]. It is used to identify that an
INVITE request is a CC call, or to further identify that a SUBSCRIBE
request is for the call-completion event package. The parameter may
have a value that describes the type of the call-completion CC operation, as
described in this specification.

Name of the Parameter: parameter: m

Predefined Values : values: yes

RFC Reference : [RFC XXXX]

(Note for RFC Editor: Please fill in XXXX with the RFC number of this
specification)

Reference: [RFC6910]

12.4. Call-Completion purpose parameter value The 'purpose' Parameter Value 'call-completion'

This specification adds a new predefined value "call-completion" for
the "purpose" 'purpose' header field parameter of the Call-Info header field.
This modifies the registry header field parameters and parameter
values by adding this RFC as a reference to the line for header field
"Call-Info" and parameter name "purpose": 'purpose':

Header Field: field: Call-Info

Parameter Name: name: purpose

Predefined Values: values: yes

Reference: [RFC3261].[RFC5367][[RFC XXXX]]

(Note for RFC Editor: Please fill in XXXX with the RFC number of this
specification) [RFC3261] [RFC5367] [RFC6910]

12.5. 'm' header parameter Header Parameter for Call-Info

This specification extends [RFC3261] to add a new header field
parameter 'm' to the Call-Info header field. This adds a row to the
registry header field parameters and parameter values:

Header Field: field: Call-Info

Parameter Name: name: m

Predefined Values: values: yes

Reference: [RFC XXXX] [RFC6910]

This RFC predefines the values 'BS', 'NR' 'NR', and 'NL' .

(Note for RFC Editor: Please fill in XXXX with the RFC number of this
specification) 'NL'.

13. Acknowledgements

Thanks to Paul Kyzivat, John Elwell, Keith Drage, Andrew Hutton,
Thomas Stach, Dennis Luebbers Luebbers, and Christer Holmberg Holmberg, who provided
helpful comments, feedback feedback, and suggestions.

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., 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., 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]
"DESCRIPTION FOR CALL COMPLETION SUPPLEMENTARY SERVICES
USING
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, which interprets the INVITEs as
indications to make a CC request with BS or NR or NL mode for the
latest call made by the UA.

The agent monitors the status of the UA(s) for availability to be
used for a CC call by examining the dialog events.

The agent indicates to the UA(s) that CC recall is in progress by
making call to the UA(s). If the UA is answered, the agent assumes
that the caller is available and plays pre-recorded audio to indicate
that CC recall is in progress.

After playing the pre-recorded audio, the caller's agent uses REFER
to order the UA to make the CC call to the callee.

Appendix B. Example Callee's Monitor

This section outlines how an autonomous callee's monitor can operate
using only standard SIP features to interact with the callee's UA.
This example is suitable only as a learning aid, as its performance
is poor.

The callee's monitor monitors calls made to the UA(s) by subscribing
to the UA(s) dialog events. events of the UA(s). This enables it to determine
their Call-
Id's Call-Ids and their final response statuses.

The proxy for the UA(s) routes to the callee's monitor any SUBSCRIBEs
for the call-completion event package directed to the URIs serviced
by the UA(s).

The callee's monitor monitors the status of the UA(s) to determine
when they are in a suitable state to receive a CC call by watching
the busy/not-busy status of the UA(s): e.g. 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.

Authors' Addresses

Dale R. Worley
Ariadne Internet Services, Inc.
738 Main St.
Waltham, MA, MA 02451
US

Phone: +1 781 647 9199
Email:
EMail: worley@ariadne.com
URI: http://

Martin Huelsemann
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt,
Darmstadt 64307
Germany

Phone: +4961515812765
Email:
EMail: martin.huelsemann@telekom.de
URI: http://www.telekom.de

Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt,
Darmstadt 64307
Germany

Phone: +4961515812766
Email:
EMail: r.jesske@telekom.de
URI: http://www.telekom.de

Denis Alexeitsev
TeleFLASH
Mainzer Landstrasse 47
Frankfurt 60329
Germany

Phone: +49-69-257-378-230
Email:
EMail: alexeitsev@teleflash.com
URI: http://www.teleflash.com