[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
Internet Draft                                             D. R. Worley
Expires: August 25, 2008                                        Pingtel
                                                          D. Alexeitsev
                                                          M. Huelsemann
                                                                     DT
                                                          February 2008


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



Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 25, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2008).


Abstract

   This document analyzes the interoperability problems surrounding the
   call-completion feature that allows a callee to put a caller's
   request into a queue by which the caller can be notified to call back



Worley, et al.          Expires - August 2008                [Page 1]


Internet-Draft             Call Completion              February 2008

   the callee at later time.  This document analyzes how different
   solutions inter-operate and tries to make recommendation on how to
   best meet this requirement.


Table of Contents

   1. Introduction...................................................3
   2. Requirements terminology.......................................3
   3. Terminology....................................................3
   4. Overview.......................................................5
      4.1 General....................................................5
      4.2 Differences from SS7.......................................6
   5. Detailed Description of the Call-Completion Mechanism..........7
      5.1 Caller's Call-Completion Agent.............................7
      5.2 Callee's Call-Completion Monitor...........................8
      5.3 The Original Call Is Made..................................9
      5.4 Call-Completion Is Invoked.................................9
      5.5 The Call-Completion Request Is Queued.....................10
      5.6 Call-Completion Is Activated..............................11
      5.7 Data Provided in the Call-Completion Event Package........12
   6. Examples......................................................13
   7. Call Completion Event Package.................................17
      7.1 Event Package Name........................................17
      7.2 Event Package Parameters..................................18
      7.3 SUBSCRIBE Bodies..........................................18
      7.4 Subscribe Duration........................................18
      7.5 NOTIFY Bodies.............................................18
      7.6 Subscriber Generation of SUBSCRIBE Requests...............19
      7.7 Notifier Processing of SUBSCRIBE Requests.................19
      7.8 Notifier Generation of NOTIFY Requests....................19
      7.9 Subscriber Processing of NOTIFY Requests..................20
      7.10 Handling of Forked Requests..............................20
      7.11 Rate of Notifications....................................20
      7.12 State Agents.............................................20
   8. Call-completion information format............................21
      8.1 call-completion-state.....................................21
      8.2 service-retention.........................................21
   9. Security Considerations.......................................21
   10. Open issues..................................................22
      10.1 Suspend and resume.......................................22
      10.2 CC request and recall correlation........................23
   11. IANA Considerations..........................................24
   12. References...................................................25
      12.1 Normative References.....................................25
      12.2 Informative References...................................25




Worley, et al.         Expires August 25, 2008               [Page 2]


Internet-Draft             Call Completion              February 2008

1.   Introduction

   The call-completion architecture is driven by the interactions
   between two types of agents, a "caller's agent" which operates on
   behalf of the original caller, and a "callee's monitor", which
   operates on behalf of the original callee.  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.  (Although
   simple agents and monitors can be devised that interact with users
   and UAs entirely through standard SIP mechanisms [RFC3265] [RFC4235]
   [RFC3515]).


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

3.   Terminology

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

   CC, or call completion: a service which allows a call which failed
   to reach a desired destination user to be automatically retried at a
   later time when the destination appears to be available.

   CC indicator:  the data in responses to the INVITE of the original
   call which indicate that CC is available for this call.

   CC request:  (1) the indication by the caller to the caller's agent
   that the caller desires CC for a failed original call, (2) the
   indication transmitted from the caller's agent to the callee's
   monitor of the desire for CC processing, (3) 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: CC service when the
   initial failure was that the destination UA was busy.




Worley, et al.         Expires August 25, 2008               [Page 3]


Internet-Draft             Call Completion              February 2008

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

   CCBS/CCNR service duration timer, or CC service duration timer:
   maximum time a CC request will remain activated within the network.

   CC call: a call from the caller to the callee, triggered by the CC
   service when it determines that the callee is available.

   CC recall:  (1) the action of the callee's monitor selecting a
   particular CC request as one that should initiate a CC call, (2) the
   indication from the caller's agent to the caller that it is now
   possible to initiate a CC call, (3) the indication by the caller to
   initiate a CC call.

   Call-completion queue:  a buffer at the callee which stores
   automatically answered 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, or call-completion user:  The initiator of the
   original call and the CC request.  The user on whose behalf the
   call-completion call is made.

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

   Callee's monitor, or monitor:  a component which implements the
   call-completion queue for user(s)/UA(s), and performs the associated
   tasks.  Analogous to the destination local exchange's role in SS7
   CC.

   Caller's agent, or agent:  a component which makes CC requests and
   responds to CC recall events.  Analogous to the originating local
   exchange's role in SS7 CC.

   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 call-completion service; if
   supported, call-completion 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.



Worley, et al.         Expires August 25, 2008               [Page 4]


Internet-Draft             Call Completion              February 2008

4.   Overview

4.1    General

   The call-completion architecture augments each caller's UA (or UAC)
   which wishes to be able to use the call-completion features with 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.

   In order to request call-completion, the caller's agent subscribes to
   the call-completion event package (as defined in chapter 6) 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.

   When the caller's UA makes a call to a callee that fails (e.g.,
   because the callee was busy or the callee did not answer), and the
   caller wishes to use CC to contact the callee later, the caller
   instructs the caller's agent to activate the CC feature.

   The caller's agent sends a SUBSCRIBE request for the call-completion
   event package to the original destination URI of the call.  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.

   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.  This
   call is identified as a call-completion call so it can be given
   precedence in reaching the callee's UA.



Worley, et al.         Expires August 25, 2008               [Page 5]


Internet-Draft             Call Completion              February 2008

   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 top CC agent
   in 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 top CC agent in the queue the CC
   monitor shall perform the callee monitoring for this top 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, possibly
   with the possibility to update the subscription.

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

   SIP call completion does not fundamentally distinguish "call
   completion on no reply" (CCNR) from "call completion on busy
   subscriber" (CCBS), because the network does not need to make a
   distinction, and given the potential complexity of SIP routing,
   agents in the network may not be able to.  However, SIP call
   completion operations MAY carry an 'm' parameter to label call
   completion actions as to the original cause of the failure.
   Currently, the only defined values are "BS" and "NR". Other values
   may be defined in the future, and SIP call completion operations
   should succeed even if the 'm' parameter is omitted.  However, in
   these latter cases, interoperation with SS7 is likely to be impaired.

   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 and the callee's UA or
   service needs to support call completion to work successfully between
   them.  Intermediate SIP systems do not need to implement call
   completion.


Worley, et al.         Expires August 25, 2008               [Page 6]


Internet-Draft             Call Completion              February 2008


   Due to flexibility needed to support legacy systems that are not
   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.   Detailed Description of the Call-Completion Mechanism

5.1    Caller's Call-Completion Agent

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

   An agent may be an integrated part of the UA, a separate end-system,
   integrated with a proxy serving the UA, or a function of an
   application server that provides these services to many UAs.

   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 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 agent monitors calls made from the UA(s) in order to determine
   their Call-Id's and (potentially) their final response statuses, and
   the Call-Info headers of final responses and any HERFP provisional
   responses.

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

   The agent can communicate to the UA(s) that CC recall is in progress
   and to inquire if the relevant calling user is available for the CC
   call.

   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 August 25, 2008               [Page 7]


Internet-Draft             Call Completion              February 2008

5.2    Callee's Call-Completion Monitor

   The call-completion architecture 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".

   A monitor may be an integrated part of the UA, a separate end-
   system, integrated with a proxy serving the UA, or a function of an
   application server that provides these services to many UAs.

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

   The monitor monitors calls made to the UA(s) in order to determine
   their Call-Id's and (potentially) their final response statuses.

   The monitor may supply Call-Info header values for final responses
   and any HERFP provisional responses.

   The monitor receives SUBSCRIBEs for the call-completion event
   package directed to the URIs serviced by the UA(s) and any URIs that
   it provides for Call-Info headers.

   The callees using the UA(s) may be able to indicate to the monitor
   when they wish to receive CC calls.

   The monitor has a method of monitoring the status of the UA(s)
   and/or their users to determine when they are in a suitable state to
   receive a CC call.  This determination depends on the mode of CC
   ('m' parameter) call in question.  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.
   In a system with rich presence information, the determination may be
   "Is the callee available for a call?"  This monitoring may be
   achieved by subscribing to the dialog event package of the UA(s) or
   by other means.

   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.


Worley, et al.         Expires August 25, 2008               [Page 8]


Internet-Draft             Call Completion              February 2008


   The CC monitor MAY provide an URI to which the CC agent can
   subscribe for call completion.  When applicable the CC URI SHALL be
   sent to the CC agent in the Call Info header of an appropriate
   response message to the initial INVITE, according to the following
   sceme:

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

   The 'm' parameter defines the mode of call cmpletion and can have
   the values 'BS' for busy subscribers and 'NR' for no reply.  It is
   possible to define other codes in future, and also to omitt the 'm'
   parameter entirely (though that is likely to degrade service).

   Issue: How does the the CC monitor inform the CC agent if CC
   retantion is supported or not?

5.3    The Original Call Is Made

   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.
   E.g., a call that is not answered by the callee user may connect to
   the callee user's voicemail server.  Eventually, the INVITE fails, or
   the resulting dialog(s) are terminated.  Note that the Call-Id of the
   INVITE is a unique identifier of this call attempt.

   The caller's agent records the request URI, the Call-Id, and possibly
   the final request status that the caller's UA received.  The callee's
   monitor records the Call-Id and possibly the final request status(es)
   returned by the callee's UA(s).

   Note that the caller's UA may not receive any response from any of
   the callee's UA(s), as the final response returned to the caller's UA
   may have been from a fork that reached a UA that was not the
   callee's.

5.4    Call-Completion Is Invoked

   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



Worley, et al.         Expires August 25, 2008               [Page 9]


Internet-Draft             Call Completion              February 2008

   200 status to the INVITE but from the caller's point of view is "no
   reply".

   Question: At this point, it seems that the best choice is that the
   caller's agent need not determine what type of CC is being requested
   (CCNR vs. CCBS), as (1) it cannot determine this from the INVITE
   final response, (2) it would be a burden to make the calling user to
   specify it, and (3) the callee's monitor can determine this from the
   responses returned by the callee's UAs.

   The caller's agent subscribes to the call-completion event package
   using the request URI of the original call.  This SUBSCRIBE should be
   routed in much the same way as the original INVITE, but ultimately
   being routed not to the callee's UAs but to the callee's monitor.
   The Event header of the subscribe specifies the call-completion event
   package with a parameter call_id={Call-Id of the original call}.

   Question: Should the specification of the original call be done in
   the SUBSCRIBE body rather than in an event-param?

   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.

   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 404 (Not Found)
   to such SUBSCRIBEs.  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 call-completion event package returns various information to the
   caller's agent, but the vital datum is that it contains an indication
   whether the callee's monitor has chosen the caller's agent to perform
   the next CC call to the callee.  This datum is initially false.

5.5    The Call-Completion Request Is Queued




Worley, et al.         Expires August 25, 2008              [Page 10]


Internet-Draft             Call Completion              February 2008

   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 caller's agent becomes
   unwilling to initiate the CC call (e.g., because the calling user has
   deactivated CC or because the caller's UA becomes busy), the caller's
   agent must terminate or suspend the subscription(s).  (Currently, no
   method of suspending a subscription is defined.)  If the caller's
   agent later becomes willing again to initiate CC for the original
   call, it may resume the suspended subscription(s) or initiate new
   one(s).

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

5.6    Call-Completion Is Activated

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

   The callee's monitor changes the "call completion active" datum for
   the chosen caller's agent from false to true.  This triggers a
   notification for the agent's subscription.

   The agent receives the notification with the CC active datum set to
   true.  It then terminates or suspends all other CC subscriptions 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).

   If the calling user is not available, the caller's agent indicates
   this to the callee's monitor by terminating the CC subscription.

   If the calling user is available, the caller's agent causes the
   caller's UA to initiate a call to the request URI (which is expected
   to be routed to the callee's UA(s)).




Worley, et al.         Expires August 25, 2008              [Page 11]


Internet-Draft             Call Completion              February 2008

   Question: Should the callee's monitor supply a URI which should be
   used in the CC call?  This seems like it would be more reliable, as
   the monitor is probably "for" a particular callee URI, and it has no
   information about the destinations of any other forks of the original
   call.

   Question: The CC must be marked in some way as a CC call in order for
   the callee's monitor to know that the CC activation is being acted
   upon by the caller's agent.  And the marking must include the
   original Call-Id to allow correlation with the original call.
   Possibilities for a marking are a special URI-parameter on the
   request URI or a special header.

   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
   will withdraw 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
   will also withdraw CC activation, but the original call will never
   again be selected for CC activation (and in practice, can be deleted
   from the monitor's records).

   Question: Is that last statement true?  Can a call appear to succeed
   from the monitor's point of view but fail from the calling user's
   point of view?

   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.

5.7    Data Provided in the Call-Completion Event Package

   Question: What format should the event package data be presented in?
   This draft proposes a simple attribute-value format.  We might also
   consider yet another XML format.

   The only necessary information to be provided by the call-completion
   event package is the CC activation datum, whose value is false
   (meaning that this CC request has not been chosen for activation) or
   true (meaning that it has).





Worley, et al.         Expires August 25, 2008              [Page 12]


Internet-Draft             Call Completion              February 2008

   Question: If we decide to let the callee's monitor provide the
   request URI for the CC call, that request URI should probably be a
   mandatory datum as well.

   The event package may provide information about the callee's
   monitor's policy.  In particular, the PSTN CC feature 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 has a caller-queuing facility, we 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, such
   as number of callers ahead of this caller and expected wait time.  In
   that case, this data should probably not trigger a notification every
   time it changes, but rather at suitable time increments.




6.   Examples

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

     Caller                     Callee
     sip:123@a.com              sip:456@b.com
       |                          |
       | INVITE sip:456@b.com     |
       |------------------------->|
       |                          |
       | 487                      |
       | Call-Info: <sip:456@b.com;monitor>;purpose=call-completion;m=NR
       |<-------------------------|
       |                          |
       | SUBSCRIBE sip:456@b.com;monitor;id=xxxx;m=NR
       | Request-Disposition: parallel, no-cancel
       |------------------------->|
       |                          |
       | 200                      |
       |<-------------------------|
       |                          |
       | SUBSCRIBE sip:456@b.com;id=xxxx;m=NR
       | Request-Disposition: parallel, no-cancel
       |------------------------->|
       |                          |
       | 482                      |
       |<-------------------------|
       |                          |


Worley, et al.         Expires August 25, 2008              [Page 13]


Internet-Draft             Call Completion              February 2008

       | NOTIFY sip:123@a.com     |
       |<-------------------------|
       |                          |
       | INVITE sip:456@b.com;id=xxxx;m=NR
       |------------------------->|
       |                          |

   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 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 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 because it specifies "Event: call-completion".

   CC activation is done by sending a SUBSCRIBE to any known monitor
   URIs.  These can be provided by the Call-Info header in the response
   to the INVITE.  These can also be provided by any HERFP provisional
   responses that are received.  (More about that below.)  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 the URIs the 'id' and (if possible) 'm'
   parameters.

   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.

   Eventually, this caller is selected for CC, and is informed of this
   via a NOTIFY.  This NOTIFY carries a URI to which the CC completion
   INVITE should be sent.  In practice, this may be the AOR of the
   callee.


Worley, et al.         Expires August 25, 2008              [Page 14]


Internet-Draft             Call Completion              February 2008


   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 'id'
   and (if possible) 'm' parameters, to specify CC processing.

   Complication:  The caller's agent cannot remember the URIs returned
   in the Call-Info header and the call-completion NOTIFY.

   The caller's agent uses 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.

   Complication:  Multiple callees are contacted in a deep forking
   structure.

   The caller's agent attempts to reach these by including a SUBSCRIBE
   to the original request-URI.

   Complication:  Depending on the request-URI to reach all callee's
   monitors is not reliable in deep forking structures.

   The best solution I know of is to use the proposed 130 response code
   (draft-mahy-sipping-herfp-fix) to allow callee UAs or their governing
   proxies to directly carry callee's monitor URIs back to the caller.
   The body of the 130 is a sipfrag which is the failure response of the
   original call at that callee.  In this application, most of the
   apparatus described in the referenced draft is ignored, the body
   sipfrag is only examined for a Call-Info header with purpose=call-
   completion.  If it is found, the URI is added to the list of URIs to
   be contacted for CC activation.

   (While the proposed 130 response code and the proposed 199 response
   code (draft-holmberg-sipping-199) are generated in nearly identical
   circumstances, they have different purposes and only the 130 carries
   the final response as its body.  If both purposes are to be served,
   the two proposals should be merged.)

   Fortunately, the 130 response proposal has good upward-compatibility
   -- only the callee UA/proxy and the caller UA need to understand its
   semantics, and if a caller UA that does not understand 130 receives
   one, it will just discard it.








Worley, et al.         Expires August 25, 2008              [Page 15]


Internet-Draft             Call Completion              February 2008

   An example call flow is:

       Caller              Proxy               Callee           Callee
       sip:123@a.com       b.com          ip:456@b.com   sip:789@b.com
       |                   |                   |                   |
       | INVITE sip:abc@b.com                  |                   |
       |------------------>|                   |                   |
       |                   | INVITE sip:456@b.com                  |
       |                   |------------------>|                   |
       |                   |                   |                   |
       |                   | 487               |                   |
       |                   | Call-Info: <sip:456@b.com;monitor>    |
       |                   |            ;purpose=call-completion;m=NR
       |                   |<------------------|                   |
       |                   |                   |                   |
       |                   | 130 carrying:     |                   |
       |                   | 487               |                   |
       |                   | Call-Info: <sip:456@b.com;monitor>    |
       |                   |            ;purpose=call-completion;m=NR
       |<--------------------------------------|                   |
       |                   |                   |                   |
       |                   | INVITE sip:789@b.com                  |
       |                   |-------------------------------------->|
       |                   |                   |                   |
       |                   | 487               |                   |
       |                   | Call-Info: <sip:789@b.com;monitor>    |
       |                   |            ;purpose=call-completion;m=NR
       |                   |<--------------------------------------|
       |                   |                   |                   |
       |                   | 130 carrying:     |                   |
       |                   | 487               |                   |
       |                   | Call-Info: <sip:789@b.com;monitor>    |
       |                   |            ;purpose=call-completion;m=NR
       |<----------------------------------------------------------|
       |                   |                   |                   |
       | 487               |                   |                   |
       | Call-Info: <sip:789@b.com;monitor>;purpose=call-completion;m=NR
       |<------------------|                   |                   |
       |                   |                   |                   |
       | SUBSCRIBE sip:456@b.com;monitor;id=xxxx;m=NR              |
       | Request-Disposition: parallel, no-cancel                  |
       |-------------------------------------->|                   |
       |                   |                   |                   |
       | 200               |                   |                   |
       |<--------------------------------------|                   |
       |                   |                   |                   |
       | SUBSCRIBE sip:789@b.com;monitor;id=xxxx;m=NR              |
       | Request-Disposition: parallel, no-cancel                  |


Worley, et al.         Expires August 25, 2008              [Page 16]


Internet-Draft             Call Completion              February 2008

       |---------------------------------------------------------->|
       |                   |                   |                   |
       | 200               |                   |                   |
       |<----------------------------------------------------------|
       |                   |                   |                   |
       | SUBSCRIBE sip:abc@b.com;id=xxxx;m=NR  |                   |
       | Request-Disposition: parallel, no-cancel                  |
       |------------------>|                   |                   |
       |                   |                   |                   |
       |                   | SUBSCRIBE sip:456@b.com;id=xxxx;m=NR  |
       |                   | Request-Disposition: parallel, no-cancel
       |                   |------------------>|                   |
       |                   |                   |                   |
       |                   | 482               |                   |
       |                   |<------------------|                   |
       |                   |                   |                   |
       |                   | SUBSCRIBE sip:789@b.com;id=xxxx;m=NR  |
       |                   | Request-Disposition: parallel, no-cancel
       |                   |-------------------------------------->|
       |                   |                   |                   |
       |                   | 482               |                   |
       |                   |<--------------------------------------|
       |                   |                   |                   |
       | 482               |                   |                   |
       |<------------------|                   |                   |
       |                   |                   |                   |
       | NOTIFY sip:123@a.com                  |                   |
       |<--------------------------------------|                   |
       |                   |                   |                   |
       | INVITE sip:456@b.com;id=xxxx;m=NR     |                   |
       |-------------------------------------->|                   |
       |                   |                   |                   |



7.   Call Completion Event Package

   This section fills in the details needed to specify a possible call-
   completion event package, in accordance with section 4.4 of
   [RFC3265].

7.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".  As specified in [RFC3265], this value
   appears in the Event and Allow-events header fields.



Worley, et al.         Expires August 25, 2008              [Page 17]


Internet-Draft             Call Completion              February 2008

7.2    Event Package Parameters

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

7.3    SUBSCRIBE Bodies

   [RFC3265] requires package definitions to define the usage, if any,
   of bodies in SUBSCRIBE requests.  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.

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

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

   It is recommended to set the default duration of subscriptions to
   call completion events to a value higher than 3600 seconds which
   corresponds to the highest timer value recommended for the call
   completion services in ETSI and ITU-T.  The duration of the
   subscription is also coupled to the remaining duration of a queue
   entry.  This means in case of resuming a subscription the resulting
   duration will be less than 3600 seconds.

7.5    NOTIFY Bodies

   [RFC3265] requires package definitions to describe the allowed set if
   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


Worley, et al.         Expires August 25, 2008              [Page 18]


Internet-Draft             Call Completion              February 2008

   "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".  This "application/call-completion"
   data format is described in chapter 8.  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.

7.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 call-
   completion service specific timers.  An example of such an
   implementation can be found in ETSI TS 183 042.

   Issue: timers have to be specified, a timer section has to be added.

7.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 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 a general
   error that prevents the call-completion service has occurred (long
   term denial), the notifier MUST send a 403 Forbidden response to the
   subscriber.

   The call-completion information can be sensitive.  Therefore, all
   subscriptions SHOULD be authenticated and then authorized before
   approval.  The call-completion event package specified in this
   document is intended to be used in private domains (e.g. IMS) where
   authentication and authorization are provided via means out of scope
   of this document.

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


Worley, et al.         Expires August 25, 2008              [Page 19]


Internet-Draft             Call Completion              February 2008


   A NOTIFY sent as a confirmation of the initial subscription or of a
   subscription refresh MUST contain the "call-completion-state"
   parameter set to "queued" if the user is busy and the call-completion
   subscription was successful (i.e. initial call-completion
   subscription, or a call-completion subscription for resume reasons)
   and to "ready-for-call-completion" if the call-completion target is
   not busy.

   A NOTIFY sent as a confirmation of a request to unsubscribe MAY
   contain the "call-completion-state" parameter.

   When the callee's status changes from busy to not busy, the notifier
   MUST send a NOTIFY only to first queue entry with an active
   subscription.  This NOTIFY MUST contain the "call-completion-state"
   parameter set to "ready-for-call-completion".

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

7.9    Subscriber Processing of NOTIFY Requests

   The subscriber processing of NOTIFY requests MAY trigger additional
   CCBS service procedures (e.g.  CCBS recall, usage of CCBS timers?).
   An example of such procedures can be found in ETSI TS 183 042.

7.10     Handling of Forked Requests

   The SIP Events framework mandates that packages indicate whether or
   not forked SUBSCRIBE requests can install multiple subscriptions.
   Forked requests are MAY occur for the call completion event type.

7.11     Rate of Notifications

   [RFC3265] mandates that packages define a maximum rate of
   notifications for their package.  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.

7.12     State Agents

   [RFC3265] asks packages to consider the role of state agents in their
   design.  State agents have no role in the handling of the call
   completion package.



Worley, et al.         Expires August 25, 2008              [Page 20]


Internet-Draft             Call Completion              February 2008


8.   Call-completion information format

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) as described in RFC 2234. The formal syntax for the
   application/call-completion MIME type is described below.

   call-completion = [call-completion-state CLRF]
      [service-retention CLRF]

   A description of the above mentioned rules follows.

8.1    call-completion-state

   The call-completion-state parameter indicates the call-completion
   status of a particular user with an entry in a call-completion queue.

   call-completion-state  =  "call-completion-state" HCOLON    (
   "queued" / "ready-for-call-completion" )

   The value "queued" indicates that a user has an entry in a call-
   completion queue, but which has not reached the queue position that
   enables a call-completion call.

   The value "ready-for-call-completion" indicates that a user has an
   entry in a call-completion queue which has reached the queue position
   that enables a call-completion call.

8.2    service-retention

   The service-retention 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.

   service-retention  =  "service-retention"


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



Worley, et al.         Expires August 25, 2008              [Page 21]


Internet-Draft             Call Completion              February 2008

   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.

10.    Open issues

10.1     Suspend and resume

   General Architecture:
   There are two modes of transporting the suspend-resume information
   from the CC agent to the CC monitor - push and pull. In the push mode
   the CC agent actively changes (pushes) the state of the queue at the
   CC monitor. In the pull mode the CC monitor collects information
   (pulls) about the CC agent and changes the state of the queue based
   on that information.

   Solutions:

   - Push solutions:

   A) Implicit change of the queue state at the CC monitor by un-
      subscribing and re-subscribing to the CC service.

   Advantage: easy to implement

   Disadvantage: no explicit suspend-resume operation


   B) Explicit change of the queue state using notify=off" mechanism
      proposed in draft-vakil-sipping-notify-pause

   Advantage: explicit operation

   Disadvantage: the "notify" parameter specifies whether notifications
   should be generated, which is independent of what their content is.
   change of the state by the SUBSCRIBE method


   C) Use of a new Event header parameter like available=no/yes

   Advantage: explicit operation

   Disadvantage: change of the state by the SUBSCRIBE method





Worley, et al.         Expires August 25, 2008              [Page 22]


Internet-Draft             Call Completion              February 2008

   D) Use of XCAP to change the queue state

   Advantage: explicit operation, in line with presence architecture

   Disadvantage: introduction of the a new protocol (http) complicates
   the solution and interworking


   - Pull solution:

   E) The CC monitor makes a reverse dialog-info subscription over the
   same CC dialog to the CC agent. The CC monitoring is suspended if the
   CC agent is in the busy at the ready for recall moment. The CC
   monitoring is resumed once the CC agent becomes free.

   Advantage: automated process, similar to KPML

   Disadvantage: Additional subscription, implicit suspend-resume based
   on the CC agent state.


10.2     CC request and recall correlation

   On the receipt of the ready for recall notification the caller send
   the recall INVITE to the callee. The CC monitor shall be able to
   recognize that the incoming INVITE is the recall. Otherwise the
   INVITE will be rejected.
   The CC monitor shall also be able to recognize the relationship
   between the SUBSCRIBE request for the CC monitoring and the initial
   INVITE.

   3 methods have been discussed for the purpose of recall
   identification:

   A) Recall INVITE and SUBSCRIBE for CC monitoring shall have the same
     Call-Id as the initial INVITE.

   Advantage: This method works in the open SIP space.

   Disadvantage:   The method does not work in the distributed gateway
   environment where a recall INVITE can be generated by the different
   gateway, as the one that send the initial invite.


   B) Recall INVITE and SUBSCRIBE for CC monitoring shall have the
     constructed hash of the caller and callee's E.164 number as the
     Request-URI 'id' parameter.



Worley, et al.         Expires August 25, 2008              [Page 23]


Internet-Draft             Call Completion              February 2008

   Advantage: This method overcomes the gateway problem as the caller
   and callee address information stays the same for initial and recall
   call even if the relevant INVITEs were generated by different
   gateways. The anonymity of the caller is preserved by using the hash
   over his number.  Works in the open SIP environment.

   Disadvantage: Additional complexity of implementing the hash
   function, especially relevant for the gateways.  Every INVITE has to
   have the 'id' parameter.


   C) Recall INVITE and SUBSCRIBE for CC monitoring shall have the
     concatenation of the caller and callee's E.164 number, in the 'id'
     parameter without hash (simplified B solution).

   Advantage: For systems, that want to avoid the complexity of hashing.

   Disadvantage: Works only in trusted environments, as the caller
   identity is revealed in the 'id' parameter.


   All three methods to identify the recall INVITE and SUBSCRIBE for CC
   monitoring can be used by the CC monitor in parallel. The decision to
   use a particular method can be done by the CC monitor by analysing
   the trust relationship with the caller domain.



11.    IANA Considerations

   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








Worley, et al.         Expires August 25, 2008              [Page 24]


Internet-Draft             Call Completion              February 2008

12.    References

12.1     Normative References

   [I-D.ietf-sip-gruu]
              Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent (UA) URIs (GRUU) in the  Session Initiation Protocol
              (SIP)", draft-ietf-sip-gruu-15 (work in progress),
              October 2007.

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

   [RFC4235]  Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
              Initiated Dialog Event Package for the Session Initiation
              Protocol (SIP)", RFC 4235, November 2005.

12.2     Informative References

   [RFC3841]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller
              Preferences for the Session Initiation Protocol (SIP)",
              RFC 3841, August 2004.


Authors' Addresses

   Dale R. Worley
   Pingtel Corp.
   10 North Ave.
   Burlington, MA  01803
   US

   Phone: +1 781 229 0533 x173
   Email: dworley@pingtel.com
   URI:   http://www.pingtel.com




Worley, et al.         Expires August 25, 2008              [Page 25]


Internet-Draft             Call Completion              February 2008

   Martin Huelsemann
   Deutsche Telekom
   Heinrich-Hertz-Str. 3-7
   Darmstadt  64295
   Germany

   Email: martin.huelsemann@telekom.de


   Denis Alexeitsev
   Deutsche Telekom
   Heinrich-Hertz-Str. 3-7
   Darmstadt  64295
   Germany

   Email: d.alexeitsev@telekom.de

Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of


Worley, et al.         Expires August 25, 2008              [Page 26]


Internet-Draft             Call Completion              February 2008

   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

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).  Since this does not give the
   agent access to the Call-Info headers of responses, the agent is
   limited to using the original request URI for making CC requests.

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


Worley, et al.         Expires August 25, 2008              [Page 27]


Internet-Draft             Call Completion              February 2008


   The monitor does not supply Call-Info header values.  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 callees cannot indicate to the monitor when they wish to receive
   CC calls.

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

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).































Worley, et al.         Expires August 25, 2008              [Page 28]


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