[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-poetzl-bliss-call-completion) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 RFC 6910

bliss                                                          D. Worley
Internet-Draft                                                Avaya Inc.
Intended status: Standards Track                           M. Huelsemann
Expires: November 7, 2011                                      R. Jesske
                                                           D. Alexeitsev
                                                        Deutsche Telekom
                                                            May 06, 2011


         Call Completion for Session Initiation Protocol (SIP)
                  draft-ietf-bliss-call-completion-10

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 queuing call-
   completion requests, this document references the usage of the the
   dialog event package (RFC 4235) that is described as 'automatic
   redial' in the SIP Service Examples (RFC 5359).

   For the realization of a more comprehensive solution with queuing
   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 November 7, 2011                [Page 1]


Internet-Draft               Call Completion                    May 2011


   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 November 7, 2011.

Copyright Notice

   Copyright (c) 2011 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 November 7, 2011                [Page 2]


Internet-Draft               Call Completion                    May 2011


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 behavior  . . . . . . . . . . . 13
     6.1.  Receiving the CC possible indication . . . . . . . . . . . 13
     6.2.  Subscribing to CC  . . . . . . . . . . . . . . . . . . . . 13
     6.3.  Receiving a CC recall notification . . . . . . . . . . . . 14
     6.4.  Initiating a CC call . . . . . . . . . . . . . . . . . . . 14
     6.5.  Suspending CC  . . . . . . . . . . . . . . . . . . . . . . 14
     6.6.  Resuming CC  . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  Callee's Call-Completion Monitor behavior  . . . . . . . . . . 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  . . . . . . . 23
     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 status . . . . . . . . . . . . . . . . . . 25
     10.2. Call Completion service-retention indication . . . . . . . 25
     10.3. Call Completion 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  . . . . 27
     12.3. SIP/SIPS URI parameter 'm' . . . . . . . . . . . . . . . . 27



Worley, et al.          Expires November 7, 2011                [Page 3]


Internet-Draft               Call Completion                    May 2011


     12.4. 'purpose=call-completion' header parameter for
           Call-Info  . . . . . . . . . . . . . . . . . . . . . . . . 27
     12.5. 'm' header parameter for Call-Info . . . . . . . . . . . . 28
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
   14. Normative References . . . . . . . . . . . . . . . . . . . . . 28
   Appendix A.  Example Caller's Agent  . . . . . . . . . . . . . . . 29
   Appendix B.  Example Callee's Monitor  . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30











































Worley, et al.          Expires November 7, 2011                [Page 4]


Internet-Draft               Call Completion                    May 2011


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 November 7, 2011                [Page 5]


Internet-Draft               Call Completion                    May 2011


   original call which indicate that CC is available for this call.

   CC indicator: an indiction 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
   the caller's request for CC processing, that is, the caller's call-
   completion subscription.

   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 for initiation of a CC call, resulting in an indication
   from the caller's agent to the caller that it is now possible to
   initiate a CC call.

   CC recall events: event notifications of event package "call-
   completion", sent by the callee's monitor to the caller's agent to
   inform it of the status of its CC request.

   CC recall timer: maximum time the callee's monitor will wait for the
   caller's response to a CC recall

   CC queue: a buffer at the callee's monitor which stores incoming
   calls which are target for call completion.  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



Worley, et al.          Expires November 7, 2011                [Page 6]


Internet-Draft               Call Completion                    May 2011


   call is made.

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

   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.

   CCE: call-completion entity

   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.

   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.
   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.

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


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



Worley, et al.          Expires November 7, 2011                [Page 7]


Internet-Draft               Call Completion                    May 2011


   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 centralized
   application servers.  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 functions
   so that it can participate in call completion as both caller and
   callee, the two functions 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
   header fields 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 field 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.




Worley, et al.          Expires November 7, 2011                [Page 8]


Internet-Draft               Call Completion                    May 2011


   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 the callers
   estimated to not have been successful.  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.

   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 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 activations.

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.  If the call-
   completion 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 messages to the initial INVITE
   and forwards them to the caller.  On receipt of a non-100 provisional
   or a final response with the indication that the call-completion
   feature is available, the calling user can invoke the feature.

   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 have been successful, but from
   the user's point of view, the call may have been 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".



Worley, et al.          Expires November 7, 2011                [Page 9]


Internet-Draft               Call Completion                    May 2011


   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
   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 the original destination URI of the call and to all
   known monitor URIs (which are provided by Call-Info header fields 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 callee.  The
   monitor keeps a list or queue 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 November 7, 2011               [Page 10]


Internet-Draft               Call Completion                    May 2011


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 sucessful recalls.

   There is no interaction between call completion and automatic redial,
   as there is a difference in the behavior of the callee's monitor and
   the caller when using the dialog event package for receiving dialog
   information or for aggregating a 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 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
   optimized to support call completion, there are a larger number of



Worley, et al.          Expires November 7, 2011               [Page 11]


Internet-Draft               Call Completion                    May 2011


   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 call-completion entities (called
   "CCEs") which represent CC requests, or equivalently, the existing
   incoming call-completion subscriptions.  This set is also called a
   queue, because a queue data structure often aids in implementing the
   monitor's policies for selecting CCEs for CC recall.

   Each CCE has an availability state, which is either "available" (for
   recall) or "not available" (for recall).  It is not visible via
   subscriptions.

   Each CCE has a recall state which 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 monitor by being addressed to the
   managed URI, or URIs the monitor returns in Call-Info header fields.
   The 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".

   The monitor may receive PIDF bodies [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 CCE is
   identified by the request-URI (if it was taken from a call-completion
   event notification and 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' sets the availability state of the
   CCE to 'available'; 'status' of 'closed' sets the availability state
   of the CCE to 'not-available'.




Worley, et al.          Expires November 7, 2011               [Page 12]


Internet-Draft               Call Completion                    May 2011


   The monitor MUST select for recall only CC requests whose CCE's have
   availability state 'available', and for which the callee appears to
   be available considering the 'm' value of the CCE.  Within that
   constraint, the monitor's selections are determined by its policy.
   Often, a monitor will choose the acceptable CCE that has been in the
   queue the longest.  When the monitor has selected a CCE for recall,
   it changes the CCE's recall state from 'queued' to 'ready', which
   triggers a notification on the CCE's subscription.

   If a selected subscriber then suspends its request by sending a
   PUBLISH with status 'closed', the CCE becomes not-available, and the
   monitor changes the CCE's recall state to 'queued'.  This may cause
   another CCE (e.g., that has been in the queue for less time) to be
   selected for recall.


6.  Caller's Call-Completion Agent behavior

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 header fields of provisional and final responses.

6.2.  Subscribing to CC

   For CC activation the agent MUST send a SUBSCRIBE to all known
   monitor URIs.  A monitor URI can be provided by the Call-Info header
   field in provisional and final responses to the INVITE sent back by
   the callee's CC monitor(s).  Additionally, the caller's agent SHOULD
   include the original request-URI in its set of monitor URIs, if 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
   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 field, if a Call-Info
   header field was received.

   To minimize redundant subscriptions, these SUBSCRIBEs SHOULD have the
   same Call-Id, that is, be presented as forks of the same transaction,
   if the caller's agent is capable of doing so.

   The SUBSCRIBE SHOULD have header fields to optimize its routing.  In
   particular, it SHOULD contain "Request-Disposition: parallel, no-
   cancel", and an Accept-Contact header field to eliminate callee UAs
   that are not acceptable to the calling user.




Worley, et al.          Expires November 7, 2011               [Page 13]


Internet-Draft               Call Completion                    May 2011


   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 or suspends the subscription(s).

6.3.  Receiving a CC recall 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 it
   SHOULD suspend all CC subscriptions for all other original calls, in
   order to prevent any other CC requests from this caller from being
   activated.  The agent confirms that the calling user would be able to
   initiate a CC call, e.g. by calling the caller's UA(s).

6.4.  Initiating a CC call

   If the calling user 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 MAY add a 'm'
   parameter, 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 NOTIFY in the cc-URI, or if not available it SHOULD
   use the URI returned in the Call-Info header field, or if not
   available it MAY use the request-URI of the original INVITE, if this
   URI was recorded.  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 not available for the CC recall, or if determined by
   the CC agent's suspension policy, the CC request SHALL be suspended
   by the CC agent until the caller becomes not busy again, or if the
   conditions relevant to the CC agent's suspension policy have changed.
   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 field, 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.

6.6.  Resuming CC

   When the caller is no longer busy, or if the conditions relevant to
   the CC agent's suspension policy have changed, then the CC request



Worley, et al.          Expires November 7, 2011               [Page 14]


Internet-Draft               Call Completion                    May 2011


   SHALL be 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.

   In the case where the CC agent has sent several CC suspension
   requests to different CC monitors and the caller becomes not busy
   again, as determined by the CC agent's resumption policy the CC agent
   MAY send a CC resumption request to each CC monitor for which there
   is a suspended CC request.  Note that the CC agent's suspension
   policy may allow suspensions that are manually initiated and thus
   should not be automatically resumed


7.  Callee's Call-Completion Monitor behavior

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 field with "purpose=call-
   completion" in an appropriate response message to the initial INVITE
   and forwards it to the caller.  The Call-Info header field 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
   field 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 field MUST be set up according
   to the following scheme:

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

   The 'm' parameter defines the "mode" of 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
   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



Worley, et al.          Expires November 7, 2011               [Page 15]


Internet-Draft               Call Completion                    May 2011


   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 header fields.  The SUBSCRIBEs SHALL be processed in accordance
   with the procedures defined in [RFC3265].

   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 monitor may
   apply additional restrictions as to 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 to
   the callee's monitor that the caller's agent is prepared to initiate
   the CC call if it is selected for the 'ready' state.  If the callee's
   monitor becomes aware that, according to its policy, a subscription
   is unlikely to be selected for call-completion, it SHOULD terminate
   the subscription.

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 is 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 requests.
   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".

   The call-completion event package provides limited 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



Worley, et al.          Expires November 7, 2011               [Page 16]


Internet-Draft               Call Completion                    May 2011


   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 CC requests arrived, the
   length of time the CC requests have been active, 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.  Usually the callee's monitor will choose the oldest active
   request.

   When the callee's monitor changes the state datum for the chosen
   subscription from "queued" to "ready", the monitor MUST send a
   notification for the agent's subscription with the CC-state set to
   'ready'.  The notification SHOULD also contain in the cc-URI a URI
   which should be used in the CC call.  In practice, this may be the
   AOR of the callee.

   The monitor SHALL start a recall timer.  It is RECOMMENDED to use a
   default value between 10 and 20 seconds, which corresponds to the
   recommendation for the call completion services in ETSI and ITU-T.

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.  On arrival of the CC call the recall timer
   SHALL be stopped.  If the CC call does not arrive at the callee's
   UA(s) before expiry of the recall timer, the monitor SHOULD withdraw
   the CC activation from the caller's agent by changing the value of
   its state datum to "queued".  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 terminate the CC
   activation.

   Once the CC call has been terminated, successfully or unsuccessfully,
   the callee's monitor's policy MAY select another CC request for
   activation according to the monitor's policy.






Worley, et al.          Expires November 7, 2011               [Page 17]


Internet-Draft               Call Completion                    May 2011


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 SHALL ensure
   that the request is set to a 'queued' state, and then the monitor
   SHALL attempt to process another CC request in the queue according to
   the monitor's policy.

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 in
   subclause 7.3 above.


8.  Examples

   A basic flow, with only the most significant messages shown, is this:
































Worley, et al.          Expires November 7, 2011               [Page 18]


Internet-Draft               Call Completion                    May 2011


    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|
      |------------------------->|
      |                          |
      | NOTIFY sip:123@y.a.com   |                 [CC terminated]
      | Expires = 0              |
      |                          |



Worley, et al.          Expires November 7, 2011               [Page 19]


Internet-Draft               Call Completion                    May 2011


   The original call is an ordinary INVITE.  It fails due to no-response
   (ring-no-answer).  In this case, the callee's governing proxy
   generates a 487 response because the proxy canceled the INVITE to the
   UA when it rang too long without an answer.  The 487 response carries
   a Call-Info header field with "purpose=call-completion".  The Call-
   Info header field positively indicates that CC is available for this
   failed fork of the call.  The "m=NR" parameter indicates that it
   failed due to no-response, which is useful for PSTN interworking and
   assessing presence information in the callee's monitor.

   The URI in the Call-Info header field (<sip: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 field 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 November 7, 2011               [Page 20]


Internet-Draft               Call Completion                    May 2011


   Finally the subscription for the CC request is terminated by the
   monitor.


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 field 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 field value in the
   INVITE is the same as the URI-part of the From header field value in



Worley, et al.          Expires November 7, 2011               [Page 21]


Internet-Draft               Call Completion                    May 2011


   the SUBSCRIBE.

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.






Worley, et al.          Expires November 7, 2011               [Page 22]


Internet-Draft               Call Completion                    May 2011


9.6.  Subscriber Generation of SUBSCRIBE Requests

   Subscribers MUST generate SUBSCRIBE requests when they want to
   subscribe to the call-completion event package at the terminating
   side 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 field to the
   current remaining duration of the 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 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.

   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 November 7, 2011               [Page 23]


Internet-Draft               Call Completion                    May 2011


   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 avoid useless recalls, 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 November 7, 2011               [Page 24]


Internet-Draft               Call Completion                    May 2011


   Form (ABNF) as described in [RFC5234].  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 = 1*(cc-header CRLF)

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

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

10.1.  Call Completion status

   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 subscriber'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.  Call Completion 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 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.  Call Completion 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 November 7, 2011               [Page 25]


Internet-Draft               Call Completion                    May 2011


   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 in legitimate use, will
   be subscribed to 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 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 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



Worley, et al.          Expires November 7, 2011               [Page 26]


Internet-Draft               Call Completion                    May 2011


   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.

   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 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":

   Header Field Parameter Name Predefined Values Reference




Worley, et al.          Expires November 7, 2011               [Page 27]


Internet-Draft               Call Completion                    May 2011


   --------------------- ---------------------------
   ------------------------- ---------

   Call-Info purpose Yes [ RFC3261][RFC5367][this RFC]

12.5.  'm' header parameter for Call-Info

   This RFC adds a new header field parameter 'm' of the Call-Info
   header field.  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]


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.



Worley, et al.          Expires November 7, 2011               [Page 28]


Internet-Draft               Call Completion                    May 2011


   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [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 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



Worley, et al.          Expires November 7, 2011               [Page 29]


Internet-Draft               Call Completion                    May 2011


   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
   Avaya Inc.
   600 Technology Park Dr.
   Billerica, MA,   01821
   US

   Phone: +1 978 671 3465
   Email: dworley@avaya.com
   URI:   http://www.avaya.com


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

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


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

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









Worley, et al.          Expires November 7, 2011               [Page 30]


Internet-Draft               Call Completion                    May 2011


   Denis Alexeitsev
   Deutsche Telekom
   Heinrich-Hertz-Strasse 3-7
   Darmstadt  64307
   Germany

   Phone: +49-6151-628 2773
   Email: d.alexeitsev@telekom.de
   URI:   http://www.telekom.de










































Worley, et al.          Expires November 7, 2011               [Page 31]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/