bliss D. Worley
Internet-Draft Nortel Networks Corp.
Intended status: Standards Track M. Huelsemann
Expires: December 27, 2010 R. Jesske
D. Alexeitsev
Deutsche Telekom
June 25, 2010
Call Completion for Session Initiation Protocol (SIP)
draft-ietf-bliss-call-completion-06
Abstract
The call completion features allow the calling user of a failed call
to be notified when the called user becomes available to receive a
call.
For the realization of a basic solution without queueing call-
completion requests, this document references the usage of the the
dialog event package [RFC4235] as described as 'automatic redial' in
[RFC5359].
For the realization of a more comprehensive solution with queueing
call-completion requests, this document introduces an architecture
for implementing these features in the Session Initiation Protocol:
"Call completion" implementations associated with the caller's and
callee's endpoints cooperate to place the caller's request for call
completion into a queue at the callee's endpoint, and, when a
caller's request is ready to be serviced, re-attempt the original,
failed call.
The deployment of a certain SIP call-completion solution is also
dependent on the needed level of interoperability with existing call-
completion solutions in other networks.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Worley, et al. Expires December 27, 2010 [Page 1]
Internet-Draft Call Completion June 2010
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 December 27, 2010.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Worley, et al. Expires December 27, 2010 [Page 2]
Internet-Draft Call Completion June 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements terminology . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Call-Completion architecture . . . . . . . . . . . . . . . 7
4.2. Call-Completion procedures . . . . . . . . . . . . . . . . 9
4.3. Automatic redial as a fallback . . . . . . . . . . . . . . 11
4.4. Differences from SS7 . . . . . . . . . . . . . . . . . . . 11
5. Call-Completion Queue model . . . . . . . . . . . . . . . . . 12
6. Caller's Call-Completion Agent behaviour . . . . . . . . . . . 13
6.1. Receiving the CC possible indication . . . . . . . . . . . 13
6.2. Subscribing to CC . . . . . . . . . . . . . . . . . . . . 13
6.3. Receiving a CC notification . . . . . . . . . . . . . . . 14
6.4. Initiating a CC call . . . . . . . . . . . . . . . . . . . 14
6.5. Suspending CC . . . . . . . . . . . . . . . . . . . . . . 14
6.6. Resuming CC . . . . . . . . . . . . . . . . . . . . . . . 15
7. Callee's Call-Completion Monitor behaviour . . . . . . . . . . 15
7.1. Sending the CC possible indication . . . . . . . . . . . . 15
7.2. Receiving a CC subscription . . . . . . . . . . . . . . . 16
7.3. Sending a CC notification . . . . . . . . . . . . . . . . 16
7.4. Receiving a CC call . . . . . . . . . . . . . . . . . . . 17
7.5. Receiving a CC suspension . . . . . . . . . . . . . . . . 18
7.6. Receiving a CC resumption . . . . . . . . . . . . . . . . 18
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Call Completion Event Package . . . . . . . . . . . . . . . . 21
9.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 21
9.2. Event Package Parameters . . . . . . . . . . . . . . . . . 21
9.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 21
9.4. Subscribe Duration . . . . . . . . . . . . . . . . . . . . 22
9.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 22
9.6. Subscriber Generation of SUBSCRIBE Requests . . . . . . . 22
9.7. Notifier Processing of SUBSCRIBE Requests . . . . . . . . 23
9.8. Notifier Generation of NOTIFY Requests . . . . . . . . . . 23
9.9. Subscriber Processing of NOTIFY Requests . . . . . . . . . 24
9.10. Handling of Forked Requests . . . . . . . . . . . . . . . 24
9.11. Rate of Notifications . . . . . . . . . . . . . . . . . . 24
9.12. State Agents . . . . . . . . . . . . . . . . . . . . . . . 24
10. Call-completion information format . . . . . . . . . . . . . . 24
10.1. call-completion-state . . . . . . . . . . . . . . . . . . 25
10.2. service-retention . . . . . . . . . . . . . . . . . . . . 25
10.3. cc-URI . . . . . . . . . . . . . . . . . . . . . . . . . . 25
11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12.1. SIP Event Package Registration for call-completion . . . . 26
12.2. MIME Registration for application/call-completion . . . . 26
12.3. SIP/SIPS URI parameter 'm' . . . . . . . . . . . . . . . . 27
Worley, et al. Expires December 27, 2010 [Page 3]
Internet-Draft Call Completion June 2010
12.4. 'purpose=call-completion' header parameter for
Call-Info . . . . . . . . . . . . . . . . . . . . . . . . 27
12.5. 'm' header parameter for Call-Info . . . . . . . . . . . . 27
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
14. Normative References . . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Example Caller's Agent . . . . . . . . . . . . . . . 28
Appendix B. Example Callee's Monitor . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Worley, et al. Expires December 27, 2010 [Page 4]
Internet-Draft Call Completion June 2010
1. Introduction
The call completion (CC) feature allows the caller of a failed call
to have the call completed without having to make a new call attempt
when the callee becomes available. When the caller requests the CC
feature, the callee will be monitored for becoming available. When
the callee becomes available he will be given a certain time for
initiating a call himself. If the callee does not initiate a new
call within this time, then the caller will be recalled. When the
caller accepts the CC recall then a CC call to the callee will be
automatically started. 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 defines the following CC features:
Call Completion on Busy Subscriber (CCBS): The callee is busy. The
caller is recalled after the callee is not busy any longer.
Call Completion 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 on Not Logged-in (CCNL): The callee is not
registered. The caller is recalled after the callee has registered
again.
2. Requirements terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses terms from [RFC3261].
3. Terminology
For the purpose of this service, we provide the following
terminology:
CC, or call completion: a service which allows a caller who failed to
reach a desired destination user to be notified when the called party
becomes available to receive a call.
CC possible indication: the data in responses to the INVITE of the
Worley, et al. Expires December 27, 2010 [Page 5]
Internet-Draft Call Completion June 2010
original call which indicate that CC is available for this call.
CC indicator: a iniction in the CC call INVITE used to prioritize the
call at the destination.
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.
CC request: the entry in the callee's monitor queue representing the
original call and the caller's request for CC processing.
CCBS, or Completion of Calls to Busy Subscriber: a CC service when
the initial failure was that the destination UA was busy.
CCNR, or Completion of Calls on No Reply: a CC service when the
initial failure was that the destination UA was not answered.
CCNL, or Completion of Call on Not Logged-in: a CC service when the
initial failure was that the destination UA was not registered.
CCBS/CCNR/CCNL service duration timer, or CC service duration timer:
maximum time a CC request may remain active within the network.
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 recall: the action of the callee's monitor selecting a particular
CC request as one that should initiate 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 queue: a buffer at the callee' monitor which stores incoming calls
which have failed or may have failed. Note: This buffer may or may
not be organized as a queue. The use of the term "queue" is by
analogy with SS7 usage.
Caller, calling user, originator, or CC user: the initiator of the
original call and the CC request. The user on whose behalf the CC
call is made.
Callee, called user, destination, or CC target: a destination of the
original call, and a target of the CC call.
Worley, et al. Expires December 27, 2010 [Page 6]
Internet-Draft Call Completion June 2010
Caller's agent, or agent: a component which 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.
Callee's monitor, or monitor: a component which implements the call-
completion queue for destination user(s)/UA(s), and performs the
associated tasks, including sending CC recall events, analogous to
the destination local exchange's role in SS7 CC.
Failed call: a call which 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 person,
the INVITE receives a 200 response, but the caller considers the call
to have failed.
Original call: the initial call which failed to reach a desired
destination.
Suspended CC request: a CC request which is temporarily not to be
selected for CC recall.
Retain option: a characteristic of the CC service; if supported, CC
calls which again encounter a busy callee will not be queued again,
but the position of the caller's entry in the queue is retained
4. Solution
4.1. Call-Completion architecture
The call-completion architecture augments each caller's UA (or UAC)
which wishes to be able to use the call-completion features with a
"call-completion agent" (also written as "CC agent", "agent", or
"caller's agent").
It augments each callee's UA (or UAS) which wishes to be able to be
the target of the call-completion features with a "call-completion
monitor" (also written as "CC monitor", "monitor", or "callee's
monitor").
The agent and monitor functions can be integrated into the respective
UAs, be independent end-systems, or be provided by a centralized
application server. The two functions, though they are associated
with the two UAs, also may be provided as services by the endpoints'
home proxies or other network elements. Though it is expected that a
UA that "implements call completion" will have both types of agents
so that it can participate in call completion as both caller and
Worley, et al. Expires December 27, 2010 [Page 7]
Internet-Draft Call Completion June 2010
callee, the two agents are independent of each other.
An agent may service more than one UA as a collective group if it is
common that a caller or population of users will be shared between
the UAs, and especially if the UAs share an AOR. The agent monitors
calls made from the UA(s) in order to determine their destinations
and (potentially) their final response statuses, and the Call-Info
headers of provisional and final responses.
A monitor may service more than one UA as a collective group if it is
common that a callee or population of users will be shared between
the UAs, and especially if the UAs share an AOR. The monitor may
supply the callee's UAS(s) with Call-Info header values for
provisional and final responses.
The callees using the UA(s) may be able to indicate to the monitor
when they wish to receive CC calls.
In order to allow flexibility and innovation, most of the interaction
between the caller's agent and the caller-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 and the callee-user(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 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 agents and monitors can be devised that
interact with users and UAs entirely through standard SIP mechanisms
[RFC3265], [RFC4235] and [RFC3515], as described in the Appendixes.
The callers using the UA(s) can indicate to the agent when they wish
to avail themselves of CC for a recently-made call which failed to
reach their chosen destination. The agent monitors the status of the
UA(s) to determine when they are available to be used for a CC
recall. The agent can communicate to the UA(s) that a CC recall is
in progress and to inquire if the relevant calling user is available
for the CC recall. The agent can order the UA(s) at which the
relevant calling user is available to generate a CC call to the
callee.
Worley, et al. Expires December 27, 2010 [Page 8]
Internet-Draft Call Completion June 2010
The monitor has a method of monitoring the status of the UA(s) and/or
their users to determine when they are "available" for a CC call,
that is, in a suitable state to receive a CC call. This can be
achieved by monitoring calls made to the UA(s) in order to determine
their callers and (potentially) their final response statuses. 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 'm' parameter. E.g., 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 monitor maintains information about the set of INVITEs that have
been received by the UA(s) that may not have been considered
successful by the calling user. In practice, the monitor may remove
knowledge about an incoming dialog from its set if its CC policy
establishes that the dialog is no longer eligible for CC requests.
4.2. Call-Completion procedures
The caller's UA sends an INVITE to a request URI. One or more forks
of this request reach one or more of the callee's UAs. By
hypothesis, none of the callee's UAs returns a success response, as
otherwise, call completion services would not be needed for this
call.
However, the caller's INVITE might succeed at some other UA that the
calling user considers insufficient to satisfy his needs.
Eventually, the INVITE fails, or the resulting dialog(s) are
terminated.
If the call-completion feature is available, the callee's monitor
inserts a Call-Info header with its URI and with "purpose=call-
completion" in an appropriate non-100 provisional or final response
message to the initial INVITE and forwards it to the caller.
The calling user indicates to the caller's agent that he wishes to
invoke call-completion services on the recent call. Note that from
the SIP point of view, the INVITE may be successful, but from the
user's point of view, the call may be unsuccessful. E.g., 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 request call-completion, the caller's agent subscribes to
the call-completion event package of the callee's monitor. This
subscription is used to coordinate with the monitor (and indirectly
Worley, et al. Expires December 27, 2010 [Page 9]
Internet-Draft Call Completion June 2010
with other caller's agents and other callee's monitors) to implement
the call-completion features.
The caller's agent sends a SUBSCRIBE request for the call-completion
event package to all known monitor URIs and to the original
destination URI of the call, which are provided by a Call-Info header
in provisional and final responses to the INVITE. This SUBSCRIBE
reaches the callee's monitor. The callee's monitor uses the
existence of the subscription to know that the caller is interested
in using the CC feature in regard to the specified original call.
The monitor keeps a list or queue of failed calls to the callee, and
of the caller's agent's subscriptions, which indicate the callers
that are waiting to use the CC features.
When the callee's monitor judges that the callee and/or callee's UA
is available for call-completion, the callee's monitor selects
(usually) one request to be the next caller to execute call-
completion to the callee. The callee's monitor sends a call-
completion event update to the selected caller's agent's
subscription, telling it to begin execution of call-completion (CC
recall).
When the caller's agent receives this update, it calls the caller's
UA or otherwise tests whether the caller is available to take
advantage of call-completion. If the caller is available, the agent
directs the caller's UA to make again the call to the callee (CC
call). This call is marked as a CC call by adding a specific SIP URI
parameter, so it can be given precedence by the monitor in reaching
the callee's UA.
If the caller is not available on the receipt of the "ready for
recall" notification, the CC agent suspends the CC request at the CC
monitor. The CC agent resumes the CC request once the caller becomes
available for CC again. On the receipt of the suspension from the CC
agent at the top of the queue, the CC monitor shall perform the
callee monitoring for the next not suspended CC agent in the queue.
On the receipt of the resume from the previously suspended CC agent
that was at the top of the queue the CC monitor shall perform the
callee monitoring for this CC agent.
When the call completion call fails there are two possible options:
the CC feature has to be activated again, or CC remains activated and
the original CC request retains its position in the queue (retain
option), optionally with the possibility to update the subscription.
Worley, et al. Expires December 27, 2010 [Page 10]
Internet-Draft Call Completion June 2010
4.3. Automatic redial as a fallback
Automatic redial is a simple end-to-end design. An automatic redial
scenario is described in [RFC5359], Section 2.17. This solution is
based on the usage of the dialog event package. When the callee is
busy when the call arrives, 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 nofified 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 this solution is, that it
might occur that several CC recalls are started at the same time.
This means it is a heuristic approach with no guarantee in the order
of sucessfull recalls.
There is no interaction between call completion and automatic redial,
as there is a difference in the behaviour of the callee's monitor and
the caller when using the dialog event package for receiving dialog
information or for aggregating a call completion state.
4.4. Differences from SS7
SIP call completion differs in some ways from the CCBS and CCNR
features of SS7 (which is used in the PSTN). For ease of
understanding, we enumerate some of the differences here.
Due to the complex forking situations that are possible in SIP, a
call may "fail" from the point of view of the user and yet have a
"success" response from SIP's point of view. (This can happen even
in simple situations: e.g., a call to a busy user that fails over to
his voicemail receives a SIP success response, even though the caller
may consider it "busy subscriber".) Thus, the calling user must be
able to invoke call completion even when the original call appeared
to succeed. To support this, the caller's agent (and to a lesser
degree the callee's monitor) 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 specifically to support call completion in order that call
completion work successfully between the UAs. Intermediate SIP
systems (proxies or B2BUAs) do not need specifically to implement
call completion; they only need to be transparent to the usual range
of SIP messages.
Due to flexibility needed to support legacy systems that are not
Worley, et al. Expires December 27, 2010 [Page 11]
Internet-Draft Call Completion June 2010
optimized to support call completion, there are a larger number of
situations in SIP where call completion services are offered but
eventually cannot be successfully executed.
5. Call-Completion Queue model
The callee's monitor manages CC for a single URI. This URI is likely
to be a published AOR, or more likely "an AOR without its voicemail",
but it may be as narrowly scoped as a single UA's contact URI. The
monitor manages a dynamic set of entities which represent calls
eligible for completion ("CECEs" for short). When an INVITE reaches
the URI but does not result in a confirmed dialog, a CECE is created
which carries the From-URI of the INVITE. (If a CECE already exists
carrying the From-URI, no additional CECE is created, however its
lifetime timer is reset to 0.) A CECE is removed from the set after
its lifetime timer exceeds a particular time limit.
A subset of the CECEs are organized into a queue. Each CECE has an
availability state, which is either "available for recall" or "not
available for recall". This availability state is only significant
for CECEs in the queue. It is not visible via subscriptions. Each
CECE has a recall state which is visible via subscriptions.
The recall state is either "queued" or "ready". This recall state is
only significant for CECEs in the queue. CC subscriptions arrive at
the the monitor by being addressed to the managed URI. The CECEs
being subscribed to are identified by the Request URI.
When a CECE is destroyed, any subscriptions to its state are
terminated.
The monitor maintains "call-completion" subscriptions to all of the
CECEs. (And it knows the identities of all the CECEs, since it
creates them.) When a CECE becomes the target of a subscription, the
CECE is added to the queue (if it is not already there), and is given
the availability state "available" and recall state "queued".
When a CECE loses its last subscription, the CECE is removed from the
queue (though it remains in the set of CECEs).
The monitor may receive PIDF bodies (RFC 3863[RFC3863]), via PUBLISH
requests directed at its URI. These PUBLISH requests are expected to
be sent by subscribers to suspend and resume their CC requests. A
PIDF body contains an 'entity' attribute of the 'presence' element
which is the From-URI of the original call in question, which
therefore identifies a CECE. Receipt of a PUBLISH with 'status' of
'open' sets the availability state of the CECE to 'available';
Worley, et al. Expires December 27, 2010 [Page 12]
Internet-Draft Call Completion June 2010
'status' of 'closed' sets the availability state of the CECE to 'not-
available'.
The monitor uses the following algorithm to select callers for
recall: When the callee is available for recall, and there is at
least one CECE in the queue with availability state 'available', then
the monitor selects from these CECEs the one that has resided in the
queue the longest. The CECE's recall state is changed from 'queued'
to 'ready', which triggers a notification on the CECE's subscription.
When the monitor discovers that an CC INVITE has arrived containing a
From-URI of a CECE, it deletes the CECE from the set. However if
that INVITE fails, it may cause the creation of another CECE with the
same From-URI, or if the retain option is supported, the CECE is
retained in the set.
If the monitor discovers after a time interval that no INVITE arrives
containing the From-URI of the CECE, it deletes the CECE. This may
cause another caller to be selected for recall.
If the subscriber suspends its request by sending a PUBLISH with
status 'closed', the CECE becomes not-available, and the monitor
changes the CECE's recall state to 'queued'. This may cause another
CECE (that has been in the queue for less time) to be selected for
recall.
6. Caller's Call-Completion Agent behaviour
6.1. Receiving the CC possible indication
The caller's agent MUST record the From URI and MAY record the final
request status that the caller's UA received and the contents of
Call-Info headers of provisional and final responses.
6.2. Subscribing to CC
For CC activation the agent MUST send a SUBSCRIBE to all known
monitor URIs. These can be provided by the Call-Info header in
provisional and final responses to the INVITE. Additionally, the
caller's agent MUST include the original request-URI in its set of
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 monitor URI. The caller's agent MAY add an
'm' parameter to these URIs. The 'm' parameter SHOULD have the value
of the 'm' parameter in the Call-Info header, if a Call-Info header
was received.
Worley, et al. Expires December 27, 2010 [Page 13]
Internet-Draft Call Completion June 2010
The SUBSCRIBE should have headers to optimize its routing. In
particular, it SHOULD contain "Request-Disposition: parallel, no-
cancel", and an Accept-Contact header to eliminate callee UAs that
are not acceptable to the calling user.
If the caller's agent becomes unwilling to initiate the CC call
(e.g., because the calling user has deactivated CC), the caller's
agent terminates the subscription(s).
6.3. Receiving a CC notification
When receiving a CC notification with the cc-state set to 'ready',
the caller's agent SHOULD terminate or suspend all other CC
subscriptions (at other monitors) for this original call, and all CC
subscriptions for all other original calls, in order to prevent any
other CC requests from this caller from being activated. The agent
then determines whether the calling user is available for the CC
call, usually by calling the caller's UA(s).
6.4. Initiating a CC call
If the calling user is available, the caller's agent causes the
caller's UA to generate a new INVITE to the URI specified in the
NOTIFY. The caller MAY add the 'm' parameters (if possible), to
specify CC processing and prioritize the CC call. If the caller's
agent cannot remember the URIs returned in the Call-Info header and
the call-completion NOTIFY or if there was no such URI, it SHOULD use
the request-URI of the original INVITE. This may not provide ideal
routing, but in simple cases it is likely to reach the desired
callee/callee's monitor.
6.5. Suspending CC
If the caller is found to be busy previous to or on receipt of the CC
recall, then the CC request is suspended by the CC agent until the
caller becomes not busy again. To suspend the CC request, the CC
agent SHALL send a PUBLISH request to each CC monitor, giving the
PIDF state 'closed' for the caller's identity as presentity.
Each PUBLISH SHOULD be sent to the URI as received in the NOTIFY, or
within the corresponding SUBSCRIBE dialog, or if that is not
possible, to the corresponding monitor URI as received in the Call-
Info header, or if one is not available, the Contact address of the
subscription. If a queue entry is suspended, it is stepped over
during CC processing at the CC monitor.
Worley, et al. Expires December 27, 2010 [Page 14]
Internet-Draft Call Completion June 2010
6.6. Resuming CC
When the caller is no longer busy, then the CC request is resumed by
the CC agent. To resume a CC request, the CC agent SHALL send to
each CC monitor a PUBLISH request informing about the PIDF state
'open' but otherwise constructed as the suspend PUBLISH request.
Each PUBLISH SHOULD be sent to the URI as received in the NOTIFY, or
within the corresponding SUBSCRIBE dialog, or if that is not
possible, to the corresponding monitor URI as received in the Call-
Info header, or if one is not available, the Contact address of the
subscription.
In the case where the CC agent has sent several CC suspension
requests to different CC monitors and the caller becomes not busy
again, the CC agent shall send a CC resumption request to each CC
monitor for which there is a suspended CC request.
7. Callee's Call-Completion Monitor behaviour
7.1. Sending the CC possible indication
The callee's monitor MUST record the From URI and MAY record the
final request status(es) returned by the callee's UA(s).
If the callee's monitor wants to enable the caller to make use of the
CC service, it inserts a Call-Info header with "purpose=call-
completion" in an appropriate response message to the initial INVITE
and forwards it to the caller. The Call-Info header positively
indicates that CC is available for this failed fork of the call.
The callee's monitor SHOULD insert a URI in the Call-Info header
where the caller's agent should subscribe for call-completion
processing. Ideally, it is a globally-routable URI for the callee's
monitor. In practice, it may be the callee's AOR, and the SUBSCRIBE
will be routed to the callee's monitor only because it specifies
"Event: call-completion".
When applicable, the Call-Info header MUST be set up according to the
following scheme:
Call-Info:monitor-URI;purpose=call-completion;m=XX
The 'm' parameter defines the "mode" of call completion. The "m=NR"
parameter indicates that it failed due to no-response, the "m=BS"
parameter indicates that it failed due to busy subscriber, and the
"m=NL" parameter indicates that it failed due to not registered
subscriber. The 'm' parameter is useful for PSTN interworking and
Worley, et al. Expires December 27, 2010 [Page 15]
Internet-Draft Call Completion June 2010
assessing presence information in the callee's monitor. It is
possible that other values will be defined in future. It is also
allowed to omit the 'm' parameter entirely. Implementations MUST
accept CC operations in which the 'm' parameter is missing or has an
unknown value, and perform them as well as is possible in their
environment (which is likely to be with degraded service, especially
in interoperation with SS7).
7.2. Receiving a CC subscription
The monitor MUST be prepared to receive SUBSCRIBEs for the call-
completion event package directed to the URIs of UA(s) serviced by
the monitor and any URIs that the monitor provides for use in Call-
Info headers.
The callee's monitor(s) that receive the SUBSCRIBE establish
subscriptions. These subscriptions represent the caller's agent's
request for call-completion services. The callee's monitor MUST be
prepared to receive multiple forks of a single SUBSCRIBE, and should
respond 482 (Merged Request) to all but one fork. The callee's
monitor MUST be prepared to receive SUBSCRIBEs regarding original
calls that it has no knowledge of, and should respond 481 (Call/
Transaction Does Not Exist) to such SUBSCRIBEs. The monitor may
apply additional restrictions as which caller's agents may subscribe.
The caller's agent MUST be prepared to receive multiple responses to
the SUBSCRIBE and to have multiple subscriptions established. The
agent must also be prepared to have the SUBSCRIBE fail, in which
case, CC cannot be invoked for this original call.
The continuation of the caller's agent's subscription indicates that
the caller's agent is prepared to initiate the CC call when it is
selected by the callee's monitor. If the callee's monitor becomes
aware that, according to its policy, the original call referenced by
a subscription will never be selected for call-completion, it SHOULD
terminate the subscription and respond to any attempt to start a new
subscription for that original call with 404.
7.3. Sending a CC notification
When the cc-state of the agent's request changes, the monitor MUST
send a NOTIFY for a call-completion event to the agent. The call-
completion event package returns various information to the caller's
agent, but the vital datum is that it contains an indication about
the cc-state, which in the beginning is 'queued'. The notification
SHOULD also contain a URI which can be used for suspension requestst.
Ideally, it is a globally-routable URI for the callee's monitor. In
practice, it may be the callee's AOR, and the SUBSCRIBE will be
Worley, et al. Expires December 27, 2010 [Page 16]
Internet-Draft Call Completion June 2010
routed to the callee's monitor only because it specifies "Event:
call-completion".
The call-completion event package provides information about the
callee's monitor's policy. In particular, like in the PSTN, the
"'cc-service-retention" datum gives an indication of the "service
retention" attribute, which indicates whether the CC request can be
continued to a later time if the call-completion call fails due to
the callee's UA(s) being busy. If the callee's monitor supports the
service-retention option, the monitor SHOULD include the cc-service-
retention parameter.
The callee's monitor has a policy regarding when and how it selects
CC requests to be activated. 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 original calls arrived, and
any previous CC attempts for the same original call. Usually the
callee's monitor will choose only one CC request for activation at a
time, but if the callee's UA(s) can support multiple calls, it may
choose more than one.
When the callee's monitor changes the "call completion active" datum
for the chosen caller's agent from false to true, the monitor MUST
send a notification for the agent's subscription with the CC-state
set to 'ready'. The notification SHOULD also contain also a URI
which should be used in the CC call. In practice, this may be the
AOR of the callee.
7.4. Receiving a CC call
The callee's UA(s) and any associated proxies may give the CC call
precedence over non-CC calls. The callee's monitor supervises the
receiving of the CC call. If the CC call does not arrive at the
callee's UA(s) promptly, the monitor should withdraw the CC
activation from the caller's agent by changing the value of its CC
active datum to false. Similarly, if the CC call fails, the monitor
will withdraw CC activation. Depending on its policy, the same
original call may be selected again for CC activation at a later
time. If the CC call succeeds, the monitor should withdraw CC
activation.
Once the CC call has failed, or if it has succeeded, once the CC call
has been terminated, the callee's monitor's policy MAY select another
CC request for activation.
Worley, et al. Expires December 27, 2010 [Page 17]
Internet-Draft Call Completion June 2010
7.5. Receiving a CC suspension
If the processing of a CC request results in suspending that CC
request, the monitor SHALL stop the recall timer and attempt to
process the next CC request in the queue.
7.6. Receiving a CC resumption
When a CC request becomes resumed, then, if the callee is not busy
and there is no entry in the CC queue which is currently being
processed, the CC monitor SHALL process the queue as described above.
8. Examples
A basic flow, with only the most significant messages shown, is this:
Worley, et al. Expires December 27, 2010 [Page 18]
Internet-Draft Call Completion June 2010
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, no-cancel
| Call-Id: abcd-efgh |
| Event: call-completion |
|------------------------->|
| |
| 200 |
|<-------------------------|
| |
| NOTIFY sip:123@y.a.com | [initial NOTIFY]
| Body: status: queued |
|<-------------------------|
| |
| SUBSCRIBE sip:456@b.com;m=NR [another init. SUB.]
| From: sip:foo@example.com|
| Request-Disposition: parallel, no-cancel
| Call-Id: abcd-efgh |
| Event: call-completion |
|------------------------->|
| |
| 482 | [duplicate SUB. rejected]
|<-------------------------|
| |
| NOTIFY sip:123@y.a.com | [CC invoked]
| Body: status: ready |
| URI: sip:recall@z.b.com
|<-------------------------|
| |
| INVITE sip:recall@z.b.com;m=NR [CC recall]
| From: sip:foo@example.com|
|------------------------->|
| |
The original call is an ordinary INVITE. It fails due to no-response
(ring-no-answer). In this case, the callee's governing proxy
Worley, et al. Expires December 27, 2010 [Page 19]
Internet-Draft Call Completion June 2010
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 with "purpose=call-completion". The Call- Info
header 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 (<sip:456@z.b.com>) is the where the
caller's agent should subscribe for call-completion processing.
Ideally, it is a globally-routable URI for the callee's monitor. In
practice, it may be the callee's AOR, and the SUBSCRIBE will be
routed to the callee's monitor only because it specifies "Event:
call-completion".
CC activation is done by sending a SUBSCRIBE to all known monitor
URIs. These can be provided by the Call-Info header in the response
to the INVITE.
Additionally, the caller's agent needs to include the original
request-URI in its set of 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 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, with appropriate Request-Disposition. The first
SUBSCRIBE is to the URI from Call-Info.
The second SUBSCRIBE is to the original request-URI, and reaches the
same callee's monitor. Because it has the same Call-Id as the
SUBSCRIBE that has already reached the monitor, the monitor rejects
it with a 482, thus avoiding redundant subscriptions.
The initial NOTIFY for the successful SUBSCRIBE has "state: queued"
in its body. Eventually, this caller is selected for CC, and is
informed of this via a NOTIFY containing "state: ready". This NOTIFY
carries a URI to which the CC INVITE should be sent. In practice,
this may be the AOR of the callee.
The caller generates a new INVITE to the URI specified in the NOTIFY,
or if there was no such URI or if the caller's agent cannot remember
it, it may use the original request-URI. The caller adds the 'm'
parameters (if possible), to specify CC processing.
Worley, et al. Expires December 27, 2010 [Page 20]
Internet-Draft Call Completion June 2010
9. Call Completion Event Package
This section specifies the call-completion event package, in
accordance with section 4.4 of [RFC3265]. 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 queue as part of the
queuing facility, and include in the event package information
regarding the state of the queue. How this information is conveyed
is left for further standardization.
9.1. Event Package Name
The SIP Events specification requires package definitions to specify
the name of their package or template-package. The name of this
package is "call-completion". This value appears in the Event and
Allow-events header fields.
9.2. Event Package Parameters
No package-specific Event header parameters are defined for this
event package.
9.3. SUBSCRIBE Bodies
[RFC3265] requires package definitions to define the usage, if any,
of bodies in SUBSCRIBE requests.
The SUBSCRIBE request MAY contain an Accept header field. If no such
header field is present, it has a default value of "application/
call-completion". If the header field is present, it MUST include
"application/call-completion".
A SUBSCRIBE request for a call-completion package MAY contain a body.
This body defines a filter to be applied to the subscription. Filter
documents are not specified in this document, and may be the subject
of future standardization activity.
A SUBSCRIBE request requests call-completion information regarding
calls recently made from the same originator to the destination UA(s)
serviced by the notifier. Calls are defined to be "from the same
originator" if the URI-part of the From header value in the INVITE is
the same as the URI-part of the From header value in the SUBSCRIBE.
Worley, et al. Expires December 27, 2010 [Page 21]
Internet-Draft Call Completion June 2010
9.4. Subscribe Duration
[RFC3265] requires package definitions to define a default value for
subscription durations, and to discuss reasonable choices for
durations when they are explicitly specified.
If a SUBSCRIBE does not explicitly request a duration, the default
requested duration is 3600 seconds, as that is the highest service
duration timer value recommended for the call completion services in
ETSI and ITU-T. 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
certain duration the requested subscription cannot proceed to "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 cannot proceed to "ready" state, it should
refuse the subscription. For example, in many cases when resuming a
subscription the granted duration will be less than 3600 seconds.
9.5. NOTIFY Bodies
[RFC3265] requires package definitions to describe the allowed set of
body types in NOTIFY requests, and to specify the default value to be
used when there is no Accept header field in the SUBSCRIBE request.
A NOTIFY for a call-completion package MUST contain a body that
describes the call-completion states.
As described in [RFC3265], 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 document. All subscribers and notifiers MUST support the
"application/call-completion" data format described in section 8.
The SUBSCRIBE request MAY contain an Accept header field. If no such
header field is present, it has a default value of "application/
call-completion". If the header field is present, it MUST include
"application/call-completion". Of course, the notifications
generated by the server MUST be in one of the formats specified in
the Accept header field in the SUBSCRIBE request.
9.6. Subscriber Generation of SUBSCRIBE Requests
Subscribers MUST generate SUBSCRIBE requests when they want to
subscribe to the call-completion event package at the terminating
Worley, et al. Expires December 27, 2010 [Page 22]
Internet-Draft Call Completion June 2010
side in order to receive call-completion notifications. The
generation of SUBSCRIBE requests MAY imply the usage of a call-
completion 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 to the current
remaining duration of the subscription regardless of the value
received in the Expires header (if present) of the subscription
refresh.
If a subscription is not successful because the call-completion queue
has reached the maximum allowed number of entries (short term
denial), the notifier MUST send a 480 Temporarily Unavailable
response to the subscriber. If a subscription is not successful
because an error has occurred that prevents and will continue to
prevent the call-completion service (long term denial), the notifier
MUST send a 403 Forbidden response to the subscriber.
If it is not possible to correlate a SUBSCRIBE request with a queue
entry then the notifier SHOULD send a 481 Call/Transaction Does Not
Exist response.
A notifier MAY receive multiple forks of the same SUBSCRIBE.
(Multiple forks are, as always, identified by having the same
Call-Id.) In such a case, the notifier SHOULD reject all but one of
the SUBSCRIBEs with a 482 Merged Request response unless some other
failure response applies.
The call-completion information can be sensitive. Therefore, all
subscriptions SHOULD be handled with consideration of the issues
discussed in Section 11.
9.8. Notifier Generation of NOTIFY Requests
Notifiers MUST generate NOTIFY requests when a call-completion
service condition occurs at the terminating side that needs to be
sent towards the originating side. 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 request
represented by the subscription is not at this time selected by the
monitor for CC recall, and the parameter's value MUST be "ready" if
the request is at this time selected by the 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.
Worley, et al. Expires December 27, 2010 [Page 23]
Internet-Draft Call Completion June 2010
When the callee's monitor withdraws selection of the request for CC
recall (e.g., because the agent has not initiated the CC recall
INVITE promptly, 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 subscription was successful and the retention
option is supported at the callee, the NOTIFY MUST contain the "cc-
service-retention" parameter.
9.9. Subscriber Processing of NOTIFY Requests
The subscriber processing of NOTIFY requests MAY trigger additional
CC service procedures, as described in this document and possibly in
other documents.
9.10. Handling of Forked Requests
Forked requests are expected to be common for the call-completion
event type. The subscriber MUST be prepared to process NOTIFY
requests from multiple notifiers and to coordinate its processing of
the information obtained from them in accordance with the procedures
in this document.
9.11. Rate of Notifications
The call completion service typically involves a single notification
per notifier and per subscription but MAY involve several
notifications separated by a call completion call that failed due to
a busy call completion target. 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 to avoid useless re-calls, a
notifier SHOULD send state changes to "queued" promptly. Thus, a
notifier SHOULD NOT send a state change to "ready" as the third
notification in a ten-second interval, as that would make it
impossible to promptly send a further state change to "queued".
9.12. State Agents
State agents have no defined role in the handling of the call-
completion package.
10. Call-completion information format
The following syntax specification uses the Augmented Backus-Naur
Worley, et al. Expires December 27, 2010 [Page 24]
Internet-Draft Call Completion June 2010
Form (ABNF) as described in RFC 2234. The formal syntax for the
application/call-completion MIME type is described below. In
general, the call-completion 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, (3) lines with unknown names
are to be ignored, and (4) names starting with "X-" are reserved for
non-standardized uses. Two lines with the same name MUST NOT be
present, except when specifically permitted.
call-completion = +(cc-header CRLF)
cc-header = cc-state / cc-service-retention / cc-URI / extension-
header
The above rules whose names start with "cc-" are described below.
Other rules are described in RFC 3261.
10.1. call-completion-state
The cc-state line indicates the call-completion status of a
particular user with an entry in a call-completion queue. It MUST be
present unless the expiration time indicated in the NOTIFY is zero.
cc-state = "cc-state" HCOLON ( "queued" / "ready" )
The value "queued" indicates that a user's entry in the call-
completion queue is not selected for CC recall. The value "ready"
indicates that a user's entry in the call-completion queue has been
selected for CC recall.
10.2. service-retention
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 call-completion queue, if a call-completion call has
failed due to destination busy condition. If present, this parameter
indicates that the retain option is supported, otherwise it is not
supported. This parameter MAY be present in NOTIFY requests.
cc-service-retention = "cc-service-retention" HCOLON "true"
10.3. cc-URI
The cc-URI line provides a URI (possibly in the form of a name-addr)
which the agent SHOULD use as the request-URI of the CC recall
INVITE. It SHOULD NOT be provided and MUST be ignored unless the cc-
state value is "ready". The URI SHOULD be globally routable. The
Worley, et al. Expires December 27, 2010 [Page 25]
Internet-Draft Call Completion June 2010
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 ignored.
cc-URI = "cc-URI" HCOLON (name-addr / addr-spec) *(SEMI generic-
param)
11. Security Considerations
The use of the CC facility allows the caller's agent to determine
some status information regarding the callee. The information is
confined to a busy/not-busy indication, and is to a considerable
degree protected by the necessity of presenting the Call-Id of a
recent call to the callee in order to obtain information.
The CC facility may enhance the effectiveness of SPIT by the
following technique: The caller makes calls to a group of targets.
The caller then requests CC for the calls that do not connect to the
targets. The CC calls resulting are probably more likely to reach
the targets than original calls to a further group of targets.
12. IANA Considerations
12.1. SIP Event Package Registration for call-completion
This specification registers an event package, based on the
registration procedures defined in . The followings is the
information required for such a registration:
Package Name: call-completion
Package or Template-Package: This is a package.
Published Document: RFC XXXX (Note for RFC Editor: Please fill in
XXXX with the RFC number of this specification).
Person to Contact: Martin Huelsemann, martin.huelsemann@telekom.de
12.2. MIME Registration for application/call-completion
MIME media type name: application
MIME subtype name: call-completion
Required parameters: none.
Worley, et al. Expires December 27, 2010 [Page 26]
Internet-Draft Call Completion June 2010
Optional parameters: none.
to be defined
12.3. SIP/SIPS URI parameter 'm'
This RFC adds a URI parameter 'm'. 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
operation, as described in this RFC. This adds a row to the registry
SIP/SIPS URI Parameters:
Parameter Name Predefined Values Reference
------------------------ ------------------------- --------------
m Yes [this RFC]
12.4. 'purpose=call-completion' header parameter for Call-Info
This RFC adds a new predefined value "call-completion" for the
"purpose" header parameter of the Call-Info header. This modifies
the registry Header Field Parameters and Parameter Values by adding
this RFC as a Reference to the line for Header Field "Call-Info" and
Parameter Name "purpose":
Header Field Parameter Name Predefined Values Reference
--------------------- ---------------------------
------------------------- ---------
Call-Info purpose Yes [ RFC3261][RFC5367][this RFC]
12.5. 'm' header parameter for Call-Info
This RFC adds a new header parameter 'm' of the Call-Info header.
This adds a row to the registry Header Field Parameters and Parameter
Values:
Header Field Parameter Name Predefined Values Reference
--------------------- ---------------------------
------------------------- ---------
Call-Info m Yes [this RFC]
Worley, et al. Expires December 27, 2010 [Page 27]
Internet-Draft Call Completion June 2010
13. Acknowledgements
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
14. 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.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, 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)", August 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.
[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
Worley, et al. Expires December 27, 2010 [Page 28]
Internet-Draft Call Completion June 2010
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 monitor monitors calls made to the UA(s) by subscribing to the
UA(s) dialog events. This enables it to determine their Call-Id's
and their final response statuses.
The proxy for the UA(s) routes to the monitor any SUBSCRIBEs for the
call-completion event package directed to the URIs serviced by the
UA(s).
The 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. 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
Nortel Networks Corp.
600 Technology Park Dr.
Billerica, MA, 01821
US
Phone: +1 781 229 0533 x173
Email: dworley@nortel.com
URI: URI: http://www.nortel.com
Worley, et al. Expires December 27, 2010 [Page 29]
Internet-Draft Call Completion June 2010
Martin Huelsemann
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307
Germany
Phone: +4961516282765
Email: martin.huelsemann@telekom.de
Roland Jesske
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
Darmstadt, 64307
Germany
Phone: +4961516282766
Email: r.jesske@telekom.de
Denis Alexeitsev
Deutsche Telekom
Friedrich-Ebert-Allee
Bonn 53113
Germany
Phone: +49-228-18112010
Email: d.alexeitsev@telekom.de
Worley, et al. Expires December 27, 2010 [Page 30]
