GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6910

Internet Engineering Task Force (IETF) D. Worley Request for Comments: 6910 Ariadne Internet Services, Inc. Category: Standards Track M. Huelsemann ISSN: 2070-1721 R. Jesske

                                                      Deutsche Telekom
                                                         D. Alexeitsev
                                                             TeleFLASH
                                                            April 2013
   Completion of Calls for the Session Initiation Protocol (SIP)

Abstract

 The "completion of calls" feature defined in this specification
 allows the caller of a failed call to be notified when the callee
 becomes available to receive a call.
 For the realization of a basic solution without queuing, this
 document references the usage of the dialog event package (RFC 4235)
 that is described as 'Automatic Redial' in "Session Initiation
 Protocol Service Examples" (RFC 5359).
 For the realization of a more comprehensive solution with queuing,
 this document introduces an architecture for implementing these
 features in the Session Initiation Protocol where "completion of
 calls" implementations associated with the caller's and callee's
 endpoints cooperate to place the caller's request for completion of
 calls into a queue at the callee's endpoint; when a caller's request
 is ready to be serviced, re-attempt of the original, failed call is
 then made.
 The architecture is designed to interoperate well with existing
 completion of calls solutions in other networks.

Status of This Memo

 This is an Internet Standards Track document.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Further information on
 Internet Standards is available in Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc6910.

Worley, et al. Standards Track [Page 1] RFC 6910 Completion of Calls April 2013

Copyright Notice

 Copyright (c) 2013 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.

Table of Contents

 1. Introduction ....................................................3
 2. Requirements Terminology ........................................4
 3. Terminology .....................................................4
 4. Solution ........................................................6
    4.1. CC Architecture ............................................6
    4.2. CC Procedures ..............................................8
    4.3. Automatic Redial as a Fallback ............................11
    4.4. Differences from SS7 ......................................11
 5. CC Queue Model .................................................12
 6. Caller's 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 ......................................15
    6.5. Suspending CC .............................................15
    6.6. Resuming CC ...............................................15
 7. Callee's Monitor Behavior ......................................16
    7.1. Sending the CC Possible Indication ........................16
    7.2. Receiving a CC Subscription ...............................17
    7.3. Sending a CC Notification .................................18
    7.4. Receiving a CC Call .......................................19
    7.5. Receiving a CC Suspension .................................19
    7.6. Receiving a CC Resumption .................................20
 8. Examples .......................................................20
 9. 'call-completion' Event Package ................................24
    9.1. Event Package Name ........................................24
    9.2. Event Package Parameters ..................................24
    9.3. SUBSCRIBE Bodies ..........................................25
    9.4. Subscribe Duration ........................................25
    9.5. NOTIFY Bodies .............................................26
    9.6. Subscriber Generation of SUBSCRIBE Requests ...............26

Worley, et al. Standards Track [Page 2] RFC 6910 Completion of Calls April 2013

    9.7. Notifier Processing of SUBSCRIBE Requests .................26
    9.8. Notifier Generation of NOTIFY Requests ....................27
    9.9. Subscriber Processing of NOTIFY Requests ..................27
    9.10. Handling of Forked Requests ..............................28
    9.11. Rate of Notifications ....................................28
    9.12. State Agents .............................................28
 10. CC Information Format .........................................28
    10.1. CC Status ................................................29
    10.2. CC Service-Retention Indication ..........................29
    10.3. CC URI ...................................................29
 11. Security Considerations .......................................29
 12. IANA Considerations ...........................................31
    12.1. SIP Event Package Registration for CC ....................31
    12.2. MIME Registration for application/call-completion ........31
    12.3. SIP/SIPS URI Parameter 'm' ...............................32
    12.4. The 'purpose' Parameter Value 'call-completion' ..........33
    12.5. 'm' Header Parameter for Call-Info .......................33
 13. Acknowledgements ..............................................33
 14. References ....................................................34
    14.1. Normative References .....................................34
    14.2. Informative References ...................................35
 Appendix A. Example Caller's Agent ................................36
 Appendix B. Example Callee's Monitor ..............................36

1. Introduction

 The Completion of Calls (CC) feature allows the caller of a failed
 call to have the call completed without having to make a new call
 attempt while guessing when the callee becomes available.  When the
 caller requests the use of the CC feature, the callee will be
 monitored for its availability.  When the callee becomes available,
 the callee will be given a certain time frame for initiating a call.
 If the callee does not initiate a new call within this time frame,
 then the caller will be recalled.  When the caller accepts the CC
 recall, then a CC call to the callee will automatically start.  If
 several callers have requested the CC feature on the same callee,
 they will be recalled in a predefined order, which is usually the
 order in which they have requested the CC feature.
 This document defines the following CC features:
 Completion of Calls to Busy Subscriber (CCBS):  The callee is busy.
    The caller is recalled after the callee is no longer busy.
 Completion of Calls on No Reply (CCNR):  The callee does not answer
    the call.  The caller is recalled after the callee has completed a
    new call.

Worley, et al. Standards Track [Page 3] RFC 6910 Completion of Calls April 2013

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

2. Requirements Terminology

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

3. Terminology

 For the purpose of this service, we provide the following
 terminology:
 Callee:  a destination of the original call, and a target of the CC
    call.
 Caller:  the initiator of the original call and the CC request.  The
    user on whose behalf the CC call is made.
 Callee's monitor:  a logical component that implements the CC queue
    for destination user(s)/UA(s) (User Agent(s)) and performs the
    associated tasks, including sending CC recall events, analogous to
    the destination local exchange's role in Signaling System 7
    (SS7) CC.
 Caller's agent:  a logical component that makes CC requests and
    responds to CC recall events on behalf of originating
    user(s)/UA(s), analogous to the originating local exchange's role
    in SS7 CC.
 CC, or Completion of Calls:  a service that allows a caller who
    failed to reach a desired callee to be notified when the callee
    becomes available to receive a call.
 CC activation:  the indication by the caller to the caller's agent
    that the caller desires CC for a failed original call; this
    implies an indication transmitted from the caller's agent to the
    callee's monitor of the desire for CC processing.
 CCBS, or Completion of Calls to Busy Subscriber:  a CC service
    provided when the initial failure was that the destination UA was
    busy.

Worley, et al. Standards Track [Page 4] RFC 6910 Completion of Calls April 2013

 CCNR, or Completion of Calls on No Reply:  a CC service provided when
    the initial failure was that the destination UA did not answer.
 CCNL, or Completion of Calls on Not Logged-in:  a CC service provided
    when the initial failure was that the destination UA was not
    registered.
 CC call:  a call from the caller to the callee, triggered by the CC
    service when it has determined that the callee is available.
 CC indicator:  an indication in the CC call INVITE used to prioritize
    the call at the destination.
 CC possible indication:  the data in responses to the INVITE of the
    original call that indicate that CC is available for the call.
 CC recall:  the action of the callee's monitor selecting a particular
    CC request for initiation of a CC call, resulting in an indication
    from the caller's agent to the caller that it is now possible to
    initiate a CC call.
 CC recall events:  event notifications of event package
    "call-completion", sent by the callee's monitor to the caller's
    agent to inform it of the status of its CC request.
 CC recall timer:  maximum time the callee's monitor will wait for the
    caller's response to a CC recall.
 CC request:  the entry in the callee's monitor queue representing the
    caller's request for CC processing, that is, the caller's CC
    subscription.
 CC service duration timer:  maximum time a CC request may remain
    active within the network.
 CC queue:  a buffer at the callee's monitor that stores incoming
    calls that are targets for CC.  Note: This buffer may or may not
    be organized as a queue.  The use of the term "queue" is analogous
    to SS7 usage.
 CCE, or CC Entity:  the representation of a CC request, or,
    equivalently, an existing CC subscription within the queue of a
    callee's monitor.

Worley, et al. Standards Track [Page 5] RFC 6910 Completion of Calls April 2013

 Failed call:  a call that does not reach a desired callee, from the
    caller's point of view.  Note that a failed call may be successful
    from the SIP point of view; e.g., if the call reached the callee's
    voicemail but the caller desired to speak to the callee in real
    time, the INVITE receives a 200 response, but the caller considers
    the call to have failed.
 Notifier:  the UA that generates NOTIFY requests for the purpose of
    notifying subscribers of the callee's availability; for the CC
    service, this is the task of the callee's monitor.
 Original call:  the initial call that failed to reach a desired
    destination.
 Retain option:  a characteristic of the CC service; if supported, CC
    calls that again encounter a busy callee will not be queued again,
    but the position of the caller's entry in the queue is retained.
    Note that SIP CC always operates with the retain option active; a
    failed CC call does not cause the CC request to lose its position
    in the queue.
 Signaling System 7, or SS7:  the signaling protocol of the public
    switched telephone network, defined by ITU-T Recommendations Q.700
    through Q.849.
 Subscriber:  the UA that receives NOTIFY requests with information of
    the callee's availability; for the CC service, this is the task of
    the caller's agent.
 Suspended CC request:  a CC request that is temporarily not to be
    selected for CC recall.

4. Solution

4.1. CC Architecture

 The CC architecture augments each caller's UA (or User Agent Client
 (UAC)) wishing to use the CC features with a "CC agent" (also written
 as "caller's agent").
 It augments each callee's UA (or User Agent Server (UAS)) wishing to
 be the target of the CC features with a "CC monitor" (also written as
 "callee's monitor").
 The caller's agent and callee's monitor functions can be integrated
 into the respective UAs, be independent end-systems, or be provided
 by centralized application servers.  The two functions, though
 associated with the two UAs (caller and callee), also may be provided

Worley, et al. Standards Track [Page 6] RFC 6910 Completion of Calls April 2013

 as services by the endpoints' home proxies or by other network
 elements.  Though it is expected that a UA that implements CC will
 have both functions so that it can participate in CC as both caller
 and callee, the two functions are independent of each other.
 A caller's agent may service more than one UA as a collective group
 if a caller or population of users will be shared between the UAs,
 and especially if the UAs share an address of record (AOR).
 The caller's agent monitors calls made from the caller's UA(s) in
 order to determine their destinations and (potentially) their final
 response statuses, and the Call-Info header fields of provisional and
 final responses to invoke the CC feature.
 A callee's monitor may service more than one UA as a collective group
 if a callee or population of users will be shared between the UAs,
 and especially if the UAs share an AOR.  The callee's monitor may
 supply the callee's UAS(s) with Call-Info header field values for
 provisional and final responses.
 The callee's monitor also instantiates a presence server used to
 monitor the caller's availability for CC recall.
 The callees using the UA(s) may be able to indicate to the callee's
 monitor when they wish to receive CC calls.
 In order to allow flexibility and innovation, most of the interaction
 between the caller's agent, the caller(s) (user(s)), and the caller's
 UA(s) is out of the scope of this document.  Similarly, most of the
 interaction between the callee's monitor, the callee(s), and the
 callee's UA(s) is out of the scope of this document, as is the policy
 by which the callee's monitor arbitrates between multiple CC
 requests.
 The caller's agent must be capable of performing a number of
 functions relative to the UA(s).  The method by which it does so is
 outside the scope of this document, but an example method is
 described in Appendix A.  The callee's monitor must be capable of
 performing a number of functions relative to the UA(s).  The method
 by which it does so is outside the scope of this document, but an
 example method is described in Appendix B.
 As a proof of concept, simple caller's agents and callee's monitors
 can be devised that interact with users and UAs entirely through
 standard SIP mechanisms [RFC6665] [RFC4235] [RFC3515], as described
 in the Appendices.

Worley, et al. Standards Track [Page 7] RFC 6910 Completion of Calls April 2013

 The callers using the UA(s) can indicate to the caller's agent when
 they wish to avail themselves of CC for a recently made call that the
 callers determined to be unsuccessful.  The caller's agent monitors
 the status of the caller's UA(s) to determine when they are available
 to be used for a CC recall.  The caller's agent can communicate to
 the caller's UA(s) that a CC recall is in progress and inquire if the
 relevant caller is available for the CC recall.
 The callee's monitor may utilize several methods to monitor the
 status of the callee's UA(s) and/or their users for availability to
 receive a CC call.  This can be achieved through monitoring calls
 made to the callee's UA(s) to determine the callee's status, the
 identity of callers, and the final responses for incoming calls.  And
 in a system with rich presence information, the presence information
 may directly provide this status.  In a more restricted system, this
 determination can depend on the mode of the CC call in question,
 which is provided by the URI 'm' parameter.  For example, a UA is
 considered available for CCBS ("m=BS") when it is not busy, but a UA
 is considered available for CCNR ("m=NR") when it becomes not busy
 after being busy with an established call.
 The callee's monitor maintains information about the set of INVITEs
 received by the callee's UA(s) considered unsuccessful by the caller.
 In practice, the callee's monitor may remove knowledge about an
 incoming dialog from its set if local policy at the callee's monitor
 establishes that the dialog is no longer eligible for CC activations.

4.2. CC 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 CC
 feature is available, the callee's monitor (note there can be a
 monitor for each of the callee's UAs) inserts a Call-Info header
 field with its URI and with "purpose=call-completion" in appropriate
 non-100 provisional or final responses to the initial INVITE and
 forwards them to the caller.  The provisional response SHOULD be sent
 reliably if the INVITE contained a Supported header field with the
 option tag 100rel.  On receipt of a non-100 provisional or a final
 response with the indication that the CC feature is available, the
 calling user can invoke the CC feature.
 The caller indicates to the caller's agent that he wishes to invoke
 CC services on the recent call.  Note that from the SIP point of
 view, the INVITE may have been successful, but from the user's point
 of view, the call may have been unsuccessful.  For example, the call
 may have connected to the callee's voicemail, which would return a
 200 status to the INVITE but from the caller's point of view is "no
 reply".

Worley, et al. Standards Track [Page 8] RFC 6910 Completion of Calls April 2013

 In order to receive information necessary for the caller to complete
 the call at the callee, the caller's agent subscribes to the
 call-completion event package at the callee's monitor.
 The possibility of the caller completing the call at the callee is
 also known as the CC state (cc-state) of the caller.  The cc-states
 comprehend the values "queued" and "ready" (for CC).
 In order to receive information from all destinations where the
 callee will be reachable, the caller's agent sends a SUBSCRIBE
 request for the call-completion event package to the original
 destination URI of the call and to all known URIs of the callees'
 monitors (which are provided by Call-Info header fields in
 provisional and final responses to the INVITE).  Each callee's
 monitor uses the subscription as an indication that the caller is
 interested in using the CC feature with regard to the particular
 callee.
 Each callee's monitor keeps a list or queue of subscriptions from
 callers' agents, representing the requests from the callers' agents
 to the callee's monitor for CC services.  These subscriptions are
 created, refreshed, and terminated according to the procedures of
 [RFC6665].
 Upon receiving a SUBSCRIBE request from the caller's agent, the
 callee's monitor instantiates a presence state for the caller's UA
 that can be modified by the caller's UA to indicate its availability
 for the CC call.  Upon instantiation, the caller's presence status at
 the callee's monitor is "open".
 When the callee's monitor determines that the callee and/or callee's
 UA is available for a CC call, it selects a caller to execute the CC
 call and sends a CC event update ("cc-state: ready") via a NOTIFY
 request to the selected subscription of the caller's agent, telling
 it to begin the CC call to the callee's UA.
 When the caller's agent receives this update, it initiates a CC
 recall by calling the caller's UA and then starts the CC call to the
 callee's UA, using third-party call control procedures in accordance
 with [RFC3725].  The caller's agent can also check by other means
 whether the caller is available to initiate the CC call to the
 callee's UA.  If the caller is available, the caller's agent directs
 the caller's UA to initiate the CC call to the callee's UA.
 The caller's agent marks the CC call as such by adding a specific SIP
 URI parameter to the Request-URI, so it can be given precedence by
 the callee's monitor in reaching the callee's UA.

Worley, et al. Standards Track [Page 9] RFC 6910 Completion of Calls April 2013

 If the caller is not available on receipt of the "ready for recall"
 notification, the caller's agent suspends the CC request at the
 callee's monitor by sending a PUBLISH request containing presence
 information to the presence server of the callee's monitor, informing
 the server that the presence status is "closed".  Once the caller
 becomes available for a CC call again, the caller's agent resumes the
 CC request by sending another PUBLISH request to the callee's
 monitor, informing the monitor that the presence status is "open".
 On receipt of the suspension request, the callee's monitor performs
 the monitoring for the next non-suspended CC request in the queue.
 On receipt of the resume from the previously suspended caller's agent
 that was at the top of the queue, the callee's monitor performs the
 callee monitoring for this caller's agent.
 When the CC call fails, there are two possible options: the CC
 feature has to be activated again by the caller's agent subscribing
 to the callee's monitor, or CC remains activated and the original CC
 request retains its position in the queue if the retain option is
 supported.
 The retain option (see Section 3) determines the behavior of the
 callee's monitor when a CC call fails.  If the retain option is
 supported, CC remains activated, and the original CC request
 retains its position in the queue.  Otherwise, the CC feature is
 deactivated, and the caller's agent would have to subscribe again to
 reactivate it.
 A monitor that supports the retain option provides the
 cc-service-retention header in its CC events.  A caller's agent that
 also supports the retain option uses the presence of this header to
 know not to generate a new CC request after a failed CC call.
 Monitors not supporting the retain option do not provide the
 cc-service-retention header.  A failed CC call causes the CC request
 to be deleted from the queue, and these monitors will terminate the
 corresponding subscription of the caller's agent to inform that agent
 that its CC request is no longer in the queue.  A caller's agent that
 does not support the retain option can also terminate its
 subscription when a CC call fails, so it is possible that both the
 caller's agent and the callee's monitor may be signaling the
 termination of the subscription concurrently.  This is a normal SIP
 events [RFC6665] scenario.  After the subscription is terminated, the
 caller's agent may create a new subscription (as described in
 Section 6.2) to reactivate the CC feature for the original call.

Worley, et al. Standards Track [Page 10] RFC 6910 Completion of Calls April 2013

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.  If the callee is
 busy when the call arrives, then the caller subscribes to the
 callee's call state.  The callee's UA sends a notification when the
 callee's call state changes.  This means the caller is also notified
 when the callee's call state changes to 'terminated'.  The caller is
 alerted, then the caller's UA starts a call establishment to the
 callee again.  If several callers have subscribed to a busy callee's
 call state, they will be notified at the same time that the call
 state has changed to 'terminated'.  The problem with this solution is
 that it might happen that several recalls are started at the same
 time.  This means it is a heuristic approach with no guarantee of
 success.
 There is no interaction between CC 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 CC state.

4.4. Differences from SS7

 SIP CC differs in some ways from the CCBS and CCNR features of SS7
 (which is used in the Public Switched Telephone Network (PSTN)).  For
 ease of understanding, we enumerate some of the differences here.
 As there is no equivalent to the forking mechanism in SS7, in the
 PSTN, calls can be clearly differentiated as successful or
 unsuccessful.  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
 caller must be able to invoke CC even when the original call appeared
 to succeed.  To support this, the caller's agent must record
 successful calls as well as unsuccessful calls.
 In SIP, only the caller's UA or service system on the originating
 side and the callee's UA or service system on the terminating side
 need to support CC for CC to work successfully between the UAs.
 Intermediate SIP systems (proxies or back-to-back user agents
 (B2BUAs)) do not need to implement CC; they only need to be
 transparent to the usual range of SIP messages.  In the PSTN,
 additionally, intermediate nodes like media gateway controllers have
 to implement the CC service.

Worley, et al. Standards Track [Page 11] RFC 6910 Completion of Calls April 2013

5. CC Queue Model

 The callee's monitor manages CC for a single URI.  This URI is likely
 to be a published AOR, or more likely "non-voicemail AOR", but it may
 be as narrowly scoped as a single UA's contact URI.  The callee's
 monitor manages a dynamic set of CC entities (called "CCEs"), which
 represent CC requests, or equivalently, the existing incoming CC
 subscriptions.  This set is also called a queue, because a queue data
 structure often aids in implementing the policies of the callee's
 monitor for selecting CCEs for CC recall.
 Each CCE has an availability state, determined through the caller's
 presence status at the callee's monitor.  A presence status of "open"
 represents a CCE's availability state of "available", and a presence
 status of "closed" represents a CCE's availability state of
 "unavailable".
 Each CCE has a recall state that is visible via subscriptions.  The
 recall state is either "queued" or "ready".
 Each CCE carries the From URI of the SUBSCRIBE request that caused
 its creation.
 CC subscriptions arrive at the callee's monitor by addressing the
 URIs the callee's monitor returns in Call-Info header fields.  The
 request-URI of the SUBSCRIBE request determines the queue to which
 the resulting CCE is added.  The resulting subscription reports the
 status of the queue.  The base event data is the status of all the
 CCEs in the queue, but the data returned by each subscription is
 filtered to report only the status of that subscription's CCE.
 (Further standardization may define means for obtaining more
 comprehensive information about a queue.)
 When a CCE is created, it is given the availability state "available"
 and recall state "queued".
 When the callee's monitor receives Presence Information Data Format
 (PIDF) bodies [RFC3863] via PUBLISH requests [RFC3903], these PUBLISH
 requests are expected to be sent by subscribers to indirectly suspend
 and resume their CC requests by modifying its CCE availability state.
 A CCE is identified by the request-URI (if it was taken from a CC
 event notification that identifies the CCE) or the From URI of the
 request (matching the From URI recorded in the CCE).  Receipt of a
 PUBLISH with status "open" sets the availability state of the CCE to
 "available" (resume); status "closed" sets the availability state of
 the CCE to "unavailable" (suspend).

Worley, et al. Standards Track [Page 12] RFC 6910 Completion of Calls April 2013

 A CC request is eligible for recall only when its CCE's availability
 state is "available" and the "m" value of the CCE also indicates an
 available state.  The callee's monitor MUST NOT select for recall any
 CC requests that fail to meet those criteria.  Within that
 constraint, the selections made by the callee's monitor are
 determined by its local policy.  Often, a callee's monitor will
 choose the acceptable CCE that has been in the queue the longest.
 When the callee's monitor has selected a CCE for recall, it changes
 the CCE's recall state from "queued" to "ready", which triggers a
 notification on the CCE's subscription.
 If a selected subscriber then suspends its request by sending a
 PUBLISH with the presence status "closed", the CCE becomes
 "unavailable", and the callee's monitor changes the CCE's recall
 state to "queued".  This may cause another CCE (e.g., a CCE that has
 been in the queue for less time) to be selected for recall.
 The caller's presence status at the callee's monitor is terminated
 when the caller completes its CC call or when the subscription of the
 caller's agent at the callee's monitor is terminated.

6. Caller's Agent Behavior

6.1. Receiving the CC Possible Indication

 The caller's agent MUST record the From URI and SHOULD record the
 final request status that the caller's UA received along with the
 contents of Call-Info header fields of provisional and final
 responses.
 Note that receiving a CC possible indication also depends on the
 aggregation of final responses by proxies; in the case of 4xx
 responses, some 4xx responses are more likely to be sent to the
 caller.

6.2. Subscribing to CC

 For CC activation, the caller's agent MUST send a SUBSCRIBE to all
 known callee's monitor URIs.  A callee's monitor URI may be provided
 in the Call-Info header field in provisional and final responses to
 the INVITE sent back by the callee's monitor(s).  Additionally, the
 caller's agent SHOULD include the original request-URI that it sent
 the original INVITE to, in its set of callee's monitor URIs, when it
 is unclear if the call has forked to additional callees whose
 responses the caller has not seen.  A SUBSCRIBE to the original
 request-URI alone is used in cases where the caller's agent has not
 received or does not remember any callee's monitor URI.  The caller's
 agent SHOULD add an 'm' parameter to these URIs in order to indicate

Worley, et al. Standards Track [Page 13] RFC 6910 Completion of Calls April 2013

 to the callee's monitor the desired CC mode.  The 'm' parameter
 SHOULD have the value of the 'm' parameter received in the Call-Info
 header field of the responses to the original INVITE.
 To minimize redundant subscriptions, these SUBSCRIBEs SHOULD be
 presented as forks of the same transaction, as defined by
 Section 8.2.2.2 of [RFC3261], if the caller's agent is capable of
 doing so.
 The agent MUST NOT maintain more than one CC request for a single
 caller and directed to a single original destination URI.  If a
 caller requests CC a second time for the same destination URI, the
 agent MUST consolidate the new request with the existing CC request
 by either reusing the existing CC subscriptions or terminating and
 then recreating them.  For this purpose, equality of callers is
 determined by comparing callers' AORs and equality of destination
 URIs is determined by comparing them per [RFC3261] Section 19.1.4.
 When generating these SUBSCRIBEs, the From URI MUST be the caller's
 AOR.  The To URI SHOULD be the destination URI of the original call
 (if the agent knows that and can insert it into the To header) and
 otherwise MUST be the request-URI of the SUBSCRIBE.
 The SUBSCRIBE SHOULD have header fields to optimize its routing.  In
 particular, it SHOULD contain "Request-Disposition: parallel" and an
 Accept-Contact header field to eliminate callee UAs that are not
 acceptable to the caller.
 The caller's agent MUST be prepared to receive multiple responses for
 multiple forks of the SUBSCRIBE and to have multiple subscriptions
 established.  The caller's agent must also be prepared to have the
 SUBSCRIBE fail; in which case, CC cannot be invoked for this original
 call.
 If the caller's agent no longer wants to initiate the CC call (e.g.,
 because the caller has deactivated CC), the caller's agent terminates
 the subscription in accordance with [RFC6665] or suspends the
 subscription(s) as specified in Section 6.5.

6.3. Receiving a CC Recall Notification

 When receiving a NOTIFY with the cc-state set to "ready", the
 caller's agent SHOULD suspend all other subscriptions to CC, by
 following the step in Section 6.5, in order to prevent any other CC
 requests from this caller from receiving CC recalls.  The caller's
 agent starts the CC recall to the caller by confirming that the
 caller would be able to initiate a CC call, e.g., by calling the
 caller's UA(s).

Worley, et al. Standards Track [Page 14] RFC 6910 Completion of Calls April 2013

6.4. Initiating a CC Call

 If the caller is available for the CC call and willing to initiate
 the CC call, the caller's agent causes the caller's UA to generate a
 new INVITE towards the callee.  The caller's UA MAY add an 'm' URI
 parameter with the value of the 'm' parameter received in the
 Call-Info header in the response to the original INVITE, in order to
 specify his preferences in CC processing and to prioritize the CC
 call.  The INVITE SHOULD be addressed to the URI specified in the
 cc-URI of the NOTIFY, or, if that's not available, it SHOULD use the
 URI in the Call-Info header field of the response to the original
 INVITE; if that's not available, it MAY use the request-URI of the
 original INVITE, if this URI was recorded.  Note that the latter
 choice may not provide ideal routing, but, in simple cases, it is
 likely to reach the desired callee or callee's monitor.

6.5. Suspending CC

 If the caller is not available for the CC recall, the CC request
 SHALL be suspended by the caller's agent until the caller becomes
 available again or if the conditions relevant to the local suspension
 policy of the caller's agent have changed.  To suspend the CC
 request, the caller's agent SHALL publish the caller's presence state
 by sending a PUBLISH request to each callee's monitor where the
 presence server for CC resides in accordance with the procedures
 described in [RFC3903], giving the PIDF state "closed" for the
 caller's identity as presentity.  The PUBLISH request SHOULD contain
 an Expires header field with a value that corresponds to the current
 value of the remaining CC subscription duration.
 Each PUBLISH SHOULD be sent to the CC URI as received in the NOTIFY,
 or within the corresponding SUBSCRIBE dialog, or if that is not
 possible, to the corresponding callee's monitor URI received in the
 Call-Info header field of the NOTIFY, or if one is not available, the
 Contact address of the subscription.

6.6. Resuming CC

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

Worley, et al. Standards Track [Page 15] RFC 6910 Completion of Calls April 2013

 In the case where the caller's agent has sent several CC suspension
 requests to different callee's monitors and the caller becomes
 available again, as determined by the local resumption policy of the
 caller's agent, the caller's agent MAY send a PUBLISH to resume a CC
 request to each callee's monitor for which there is a suspended CC
 request.  Note that the resumption policy of the caller's agent may
 prescribe a manual resumption; thus, a suspended CC request should
 not be automatically resumed.

7. Callee's 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 MUST insert a Call-Info header field with
 "purpose=call-completion" in the final response message (e.g., in a
 486 to enable CC due to busy subscriber) and at least one non-100
 provisional response message (e.g., in a 180 due to no response) to
 the initial INVITE when forwarding it to the caller.  The non-100
 provisional response message SHOULD be sent reliably if the INVITE
 contained a Supported header field with the option tag 100rel.  The
 Call-Info header field values defined in this specification
 positively indicate that CC is available for the failed fork of the
 call.
 The callee's monitor SHOULD insert a URI in the Call-Info header
 field where the caller's agent should subscribe for CC.  Ideally, it
 is a globally routable URI [RFC5627] for the callee's monitor.  In
 practice, it may be the callee's AOR, and the SUBSCRIBE will be
 routed to the callee's monitor only because it specifies "Event:
 call-completion".
 In order to enable CC, 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 CC.  The "m=NR" parameter
 indicates that it failed due to lack of response, the "m=BS"
 parameter indicates that it failed due to busy subscriber, and the
 "m=NL" parameter indicates that it failed due to non-registered
 subscriber (no devices are registered for the AOR contacted).  The
 'm' parameter is useful for PSTN interworking and assessing presence
 information in the callee's monitor.  It is possible that other
 values will be defined in future.  It is also permissible to omit the

Worley, et al. Standards Track [Page 16] RFC 6910 Completion of Calls April 2013

 'm' parameter entirely.  Implementations MUST accept CC operations in
 which the 'm' parameter is missing or has an unknown value, and
 execute them as best they can in their environment (which is likely
 to be a degraded service, especially when interoperating with SS7).

7.2. Receiving a CC Subscription

 The callee's monitor MUST be prepared to receive SUBSCRIBEs for the
 call-completion event package directed to the URIs of UA(s) that it
 is servicing and any URIs that the callee's monitor provides in
 Call-Info header fields.  The SUBSCRIBEs MUST be processed in
 accordance with the procedures defined in [RFC6665], establishing
 subscriptions.  These subscriptions represent the request from the
 caller's agent for CC services.
 If the monitor receives two or more SUBSCRIBEs that have the same
 Call-Id header field value and the monitor considers the request-URIs
 of the received SUBSCRIBEs to request the status of the same set of
 UAs, then they are redundant forks of one SUBSCRIBE request, and the
 monitor SHOULD reject all but one of the requests with 482 (Merged
 Request) responses.
 The monitor MAY determine that an incoming CC SUBSCRIBE is a
 duplicate of an existing CC subscription if (1) the Call-Id header
 field values are different, (2) the From URIs (i.e., the caller's
 AORs) are the same (per [RFC3261] Section 19.1.4), (3) the To URIs
 (which should be the request-URI of the original call) have the same
 user and hostport components, and (4) the monitor considers the
 request-URIs of the received SUBSCRIBEs to request the status of the
 same set of UAs.
 If the monitor determines that a new subscription is a duplicate of
 an existing subscription, it MAY terminate the existing subscription
 in accordance with the procedures defined in [RFC6665].  In any case,
 it MUST establish the new subscription.
 The callee's monitor may apply restrictions as to which caller's
 agents may subscribe.
 The continuation of the subscription of the caller's agent indicates
 to the callee's monitor that the caller's agent is prepared to
 initiate the CC call if it is selected for the "ready" state.  If the
 callee's monitor becomes aware of a subscription that cannot be
 selected for a CC recall, it SHOULD terminate the subscription in
 accordance with [RFC6665].

Worley, et al. Standards Track [Page 17] RFC 6910 Completion of Calls April 2013

7.3. Sending a CC Notification

 The call-completion event package returns various points of
 information to the caller's agent, but the vital datum it contains is
 the cc-state of the CC request of the caller's agent as stored in the
 CC queue; in the beginning, this cc-state is "queued".  When the
 cc-state of the agent's request changes, the callee's monitor MUST
 send a NOTIFY for a CC event to the caller's agent.  The notification
 SHOULD also contain a URI that can be used for suspension requests.
 Ideally, it is a globally routable URI [RFC5627] for the callee's
 monitor.  In practice, it may be the callee's AOR, and the SUBSCRIBE
 will be routed to the callee's monitor only because it specifies
 "Event: call-completion".
 The call-completion event package provides limited information about
 the policy of the callee's monitor.  In particular, as in the PSTN,
 the "cc-service-retention" datum gives an indication of the "service
 retention" attribute, which indicates whether the CC request can be
 continued to a later time if the CC call fails due to the callee's
 UA(s) being busy.  If the callee's monitor supports the
 service-retention option, the callee's monitor SHOULD include the
 cc-service-retention parameter.
 The callee's monitor has a policy regarding when and how it selects
 CC requests for the recall.  This policy may take into account the
 type of the requests (e.g., CCNR vs. CCBS), the state of the callee's
 UA(s), the order in which the CC requests arrived, the length of time
 the CC requests have been active, and any previous attempts of CC
 activations for the same original call.  The callee's monitor will
 usually choose only one CC request for the recall at a time, but if
 the callee's UA(s) can support multiple calls, it may choose more
 than one.  The callee's monitor will usually choose the oldest active
 request.
 When the callee's monitor changes the state datum for the chosen
 subscription from "queued" to "ready", the callee's monitor MUST send
 a NOTIFY for the subscription of the caller's agent with the cc-state
 set to "ready" (recall notification).  The NOTIFY SHOULD also contain
 in the cc-URI a URI to be used in the CC call.  In practice, this may
 be the AOR of the callee.
 Upon sending the recall notification, the callee's monitor MUST start
 a recall timer.  It is RECOMMENDED to use a value between 10 and
 20 seconds, which corresponds to the recommendation for the CC
 services in the ETSI [ETS300.356-18] and ITU-T [ITU-T.Q.733]
 documents.

Worley, et al. Standards Track [Page 18] RFC 6910 Completion of Calls April 2013

7.4. Receiving a CC Call

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

7.5. Receiving a CC Suspension

 The monitor may receive PUBLISH requests to suspend CC requests from
 the caller's agent as described in Section 6.5.  The PUBLISH requests
 may be received via the URI it manages, any URI that it inserts into
 a Call-Info header, any contact URI it uses as a notifier for
 "call-completion" events, or any URI it returns as the "URI" line of
 the call-completion event packages.
 The receipt of the PUBLISH request initiates a presence event state
 for the caller's identity at the presence server of the callee's
 monitor as specified in [RFC3903], together with a logical presence
 server if this has not been done before for another call.
 Note: The presence server may initiate a presence event state for the
 caller's identity on receipt of a SUBSCRIBE request as well,
 dependent on the implementation.
 The monitor SHOULD identify the addressed CCE by the request-URI of
 the PUBLISH request, or if that is not possible, by the From URI.

Worley, et al. Standards Track [Page 19] RFC 6910 Completion of Calls April 2013

 If the processing of a CC request results in suspending that CC
 request by receiving a PUBLISH request from the caller's agent as
 described in Section 6.5, the callee's monitor MUST stop the recall
 timer and MUST ensure that the request is set to a "queued" state,
 and then the callee's monitor MUST attempt to process another CC
 request in the queue according to its local policy.

7.6. Receiving a CC Resumption

 When a CC request has been resumed after the callee's monitor has
 received a PUBLISH request from the caller's agent as described in
 Section 6.6, the presence event state for the caller's identity at
 the presence server of the CC monitor MUST be modified as described
 in [RFC3903].  If the callee is not busy and there is no entry in the
 CC queue that is currently being processed, the callee's monitor MUST
 process the queue as described in Section 7.3 above.

8. Examples

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

Worley, et al. Standards Track [Page 20] RFC 6910 Completion of Calls April 2013

     Caller                     Callee
     sip:123@a.com              sip:456@b.com
       |                          |
       | INVITE sip:456@b.com     |         [original call]
       | From: sip:123@a.com      |
       |------------------------->|
       |                          |
       | 487                      |
       | Call-Info:<sip:456@z.b.com>;purpose=call-completion;m=NR
       |<-------------------------|
       |                          |
       | SUBSCRIBE sip:456@z.b.com;m=NR     [initial SUBSCRIBE]
       | From: sip:123@a.com      |
       | Contact: sip:123@y.a.com |
       | Request-Disposition: parallel
       | Call-Id: abcd-efgh       |
       | Event: call-completion   |
       |------------------------->|
       |                          |
       | 200                      |
       |<-------------------------|
       |                          |
       | NOTIFY sip:123@y.a.com   |         [initial NOTIFY]
       | Body: cc-state: queued   |
       |<-------------------------|
       |                          |
       | SUBSCRIBE sip:456@b.com;m=NR       [another init. SUB.]
       | From: sip:foo@example.com|
       | Request-Disposition: parallel
       | Call-Id: abcd-efgh       |
       | Event: call-completion   |
       |------------------------->|
       |                          |
       | 482                      |         [duplicate SUB. rej.]
       |<-------------------------|
       |                          |
       | NOTIFY sip:123@y.a.com   |         [CC invoked]
       | Body: cc-state: ready    |
       |        URI: sip:recall@z.b.com
       |<-------------------------|
       |                          |
       | INVITE sip:recall@z.b.com;m=NR     [CC call]
       | From: sip:foo@example.com|
       |------------------------->|
       |                          |
       | NOTIFY sip:123@y.a.com   |         [CC terminated]
       | Expires = 0              |
       |<-------------------------|

Worley, et al. Standards Track [Page 21] RFC 6910 Completion of Calls April 2013

 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 where
 the caller's agent should subscribe for CC 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 is activated by sending a SUBSCRIBE to all known callee's monitor
 URIs.  These can be provided by the Call-Info header field in the
 response to the INVITE.
 Additionally, the caller's agent needs to include the original
 request-URI in its set of callee's monitor URIs, because the call may
 have forked to additional callees whose responses the caller has not
 seen.  (A SUBSCRIBE to the request-URI alone is used in cases where
 the caller's agent has not received or cannot remember any callee's
 monitor URI.)
 The caller's agent adds to these URIs an 'm' parameter (if possible).
 In this case, the caller's agent forks the SUBSCRIBE to two
 destinations as defined by Section 8.2.2.2 of [RFC3261], with
 appropriate Request-Disposition.  The first SUBSCRIBE is to the URI
 from Call-Info.
 The second SUBSCRIBE is to the original request-URI and reaches the
 same callee's monitor.  Because it has the same Call-Id as the
 SUBSCRIBE that has already reached the callee's monitor, the callee's
 monitor rejects it with a 482, thus avoiding redundant subscriptions.
 The initial NOTIFY for the successful SUBSCRIBE has "cc-state:
 queued" in its body.  Eventually, this caller is selected for CC and
 is informed of this via a NOTIFY containing "cc-state: ready".  This
 NOTIFY carries a URI to which the INVITE for the CC call should be
 sent.  In practice, this may be the AOR of the callee.
 The caller generates a new INVITE to the URI specified in the NOTIFY,
 or if there was no such URI or if the caller's agent cannot remember
 it, it may use the original request-URI.  The caller adds the 'm'
 parameters (if possible), to specify CC processing.

Worley, et al. Standards Track [Page 22] RFC 6910 Completion of Calls April 2013

 Finally, the subscription for the CC request is terminated by the
 callee's monitor.
 Another flow, with only the most significant messages of CC
 suspension and resumption shown, is as follows:
     Caller                     Callee
     sip:123@a.com              sip:456@b.com
       |                          |
       | NOTIFY sip:123@y.a.com   |      [CC notification, caller not
       | Body: cc-state: ready    |      available for CC recall]
       |        URI: sip:recall@z.b.com
       |<-------------------------|
       |                          |
       | 200                      |
       |------------------------->|
       |                          |
       | PUBLISH sip:456@z.b.com  |      [non-availability for recall
       | From: sip:123@a.com      |       is published]
       | Contact: sip:123@y.a.com |
       | Event: presence          |
       | Content-Type: 'app/pidf' |
       | Body: status=closed      |
       |------------------------->|
       |                          |
       | 200                      |
       |<-------------------------|
       |                          |
       |                          |      [caller becomes available
       |                          |       again]
       |                          |
       | PUBLISH sip:456@z.b.com  |      [availability for recall
       | From: sip:123@a.com      |       is published]
       | Contact: sip:123@y.a.com |
       | Event: presence          |
       | Content-Type: 'app/pidf' |
       | Body: status=open        |
       |------------------------->|
       |                          |
       | 200                      |
       |<-------------------------|
       |                          |
 The caller is selected for CC and is informed of this via a NOTIFY
 request containing "cc-state: ready".  At this time, the caller is
 not available for the CC recall.

Worley, et al. Standards Track [Page 23] RFC 6910 Completion of Calls April 2013

 For updating its presence event state at the callee's presence
 server, the caller sends a PUBLISH request informing the presence
 server that the PIDF state is "closed".  The PUBLISH request is sent
 (in order of preference) as follows: (1) out-of-dialog to the CC URI
 as received in the NOTIFY, (2) within the corresponding SUBSCRIBE
 dialog, (3) out-of-dialog to the corresponding callee's monitor URI
 received in the Call-Info header field of the NOTIFY, or (4) out-of-
 dialog to the remote Contact address of the corresponding SUBSCRIBE
 dialog.
 When the caller is again available for the CC recall, the caller
 updates his presence event state at the callee's presence server by
 generating a PUBLISH request informing the server that the PIDF state
 is "open"; this request will otherwise be constructed in the same way
 as the suspend PUBLISH request.

9. 'call-completion' Event Package

 This section specifies the call-completion event package, in
 accordance with Section 5.4 of [RFC6665].  The call-completion event
 package has the media type "application/call-completion".
 Note that if the callee has a caller-queuing facility, the callee's
 monitor may want to treat the CC 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 [RFC6665] requires package definitions
 to specify the name of their package or template-package.  The name
 of this package is "call-completion".  This value appears in the
 Event and Allow-Events header fields.

9.2. Event Package Parameters

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

Worley, et al. Standards Track [Page 24] RFC 6910 Completion of Calls April 2013

9.3. SUBSCRIBE Bodies

 [RFC6665] requires package definitions to define the usage, if any,
 of bodies in SUBSCRIBE requests.
 The SUBSCRIBE request MAY contain an Accept header field.  If no
 such header field is present, it has a default value of
 "application/call-completion".  If the header field is present, it
 MUST include "application/call-completion".
 A SUBSCRIBE request for a CC package MAY contain a body.  This body
 defines a filter to be applied to the subscription.  Filter documents
 are not specified in this document and may be the subject of future
 standardization activity.
 A SUBSCRIBE request requests CC information regarding calls recently
 made from the same caller to the callee UA(s) serviced by the
 notifier.  Calls are defined to be "from the same caller" if the
 URI-part of the From header field value in the INVITE is the same as
 the URI-part of the From header field value in the SUBSCRIBE.

9.4. Subscribe Duration

 [RFC6665] 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 CC services in the ETSI
 [ETS300.356-18] and ITU-T [ITU-T.Q.733] documents.  Because the
 subscription duration means that no explicit timer is needed, and the
 subscription duration can be seen as an equivalent to the SS7 service
 duration timer, this specification refers to the subscription
 duration also as the service duration timer.  It is RECOMMENDED that
 subscribers request, and that notifiers grant, a subscription time of
 at least 3600 seconds.
 If a notifier can determine that, according to its policy, after a
 certain duration the requested subscription can no longer proceed to
 the "ready" state, it SHOULD reduce the granted subscription time to
 that duration.  If a notifier can determine that, according to its
 policy, the requested subscription can never proceed to the "ready"
 state, it should refuse the subscription.

Worley, et al. Standards Track [Page 25] RFC 6910 Completion of Calls April 2013

9.5. NOTIFY Bodies

 [RFC6665] 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 event package MUST contain a body that
 describes the CC states.
 As described in [RFC6665], the NOTIFY message will contain bodies
 that describe the state of the subscribed resource.  This body is in
 a format listed in the Accept header field of the SUBSCRIBE, or in a
 package-specific default format if the Accept header field was
 omitted from the SUBSCRIBE.
 In this event package, the body of the notification contains a CC
 document.  All subscribers and notifiers MUST support the
 "application/call-completion" data format described in Section 10.
 The SUBSCRIBE request MAY contain an Accept header field.  If no
 such header field is present, it has a default value of
 "application/call-completion".  If the header field is present, it
 MUST include "application/call-completion".  Of course, the
 notifications generated by the server MUST be in one of the formats
 specified in the Accept header field in the SUBSCRIBE request.

9.6. Subscriber Generation of SUBSCRIBE Requests

 Subscribers MUST generate SUBSCRIBE requests when they want to
 subscribe to the call-completion event package at the terminating
 side in order to receive CC notifications.  The generation of
 SUBSCRIBE requests can imply the usage of a CC 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 a value
 not higher than 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 CC queue has reached
 the maximum allowed number of entries (short-term denial), the
 notifier MUST send a 480 Temporarily Unavailable response to the
 subscriber, possibly with a retry-after parameter in accordance with
 the notifier's policy.  If a subscription is not successful because a
 condition has occurred that prevents and will continue to prevent the
 CC service (long-term denial), the notifier MUST send a 403 Forbidden
 response to the subscriber.

Worley, et al. Standards Track [Page 26] RFC 6910 Completion of Calls April 2013

 A notifier MAY receive multiple forks of the same SUBSCRIBE, as
 defined by Section 8.2.2.2 of [RFC3261].  In such a case, the
 notifier MUST reject all but one of the SUBSCRIBEs with a 482 Merged
 Request response, unless some other failure response applies.
 The CC information can be sensitive.  Therefore, all subscriptions
 SHOULD be handled with consideration of the security considerations
 discussed in Section 11, in particular for verifying the identity of
 the subscriber.

9.8. Notifier Generation of NOTIFY Requests

 Notifiers MUST generate NOTIFY requests when the CC request's state
 changes to "queued" or to "ready (for CC)".  A NOTIFY that is sent
 with non-zero expiration MUST contain the "cc-state" parameter.  The
 parameter's value MUST be "queued" if the CC request represented by
 the subscription is not at this time selected by the callee's monitor
 for CC recall, and the parameter's value MUST be "ready" if the
 request is at this time selected by the callee's monitor for CC
 recall.
 A NOTIFY sent with a zero expiration (e.g., as a confirmation of a
 request to unsubscribe) MAY contain the "cc-state" parameter.
 When the callee's monitor withdraws the selection of the request for
 the CC recall (e.g., because the caller's agent has not initiated the
 CC recall INVITE before the CC recall timer expires, or because the
 agent has suspended the request from being considered for CC recall),
 the notifier MUST send a NOTIFY to the subscription of the selected
 request.  This NOTIFY MUST contain the "cc-state" parameter set to
 "queued".
 If the CC subscription was successful and the retain option is
 supported at the callee, the NOTIFY MUST contain the
 "cc-service-retention" parameter.

9.9. Subscriber Processing of NOTIFY Requests

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

Worley, et al. Standards Track [Page 27] RFC 6910 Completion of Calls April 2013

9.10. Handling of Forked Requests

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

9.11. Rate of Notifications

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

9.12. State Agents

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

10. CC Information Format

 The following syntax specification uses the Augmented Backus-Naur
 Form (ABNF) as described in [RFC5234].  The formal syntax for the
 application/call-completion MIME type is described below.  In
 general, the CC body is to be interpreted in the same way as SIP
 headers: (1) the names of the lines are case-insensitive, (2) the
 lines can be continued over line boundaries if the succeeding lines
 start with horizontal white space, and (3) lines with unknown names
 are to be ignored.  The header lines defined in this document can
 occur at most once in any given CC information format document.
 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].

Worley, et al. Standards Track [Page 28] RFC 6910 Completion of Calls April 2013

10.1. CC Status

 The cc-state line indicates the CC status of a particular user with
 an entry in a CC queue.  It MUST be present, 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 CC
 queue is not selected for CC recall.  The value "ready" indicates
 that a user's entry in the CC queue has been selected for CC recall.

10.2. CC Service-Retention Indication

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

10.3. CC URI

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

11. Security Considerations

 The CC facility allows the caller's agent to determine some status
 information regarding the callee.  This information intrinsically
 diminishes the privacy of the callee; in order to protect
 sufficiently the privacy of the callee, the overall amount of
 disclosure must be limited, and the amount of disclosure to any
 single caller must be limited.
 Of course, if a caller is not permitted to call the callee, that
 caller should not be allowed to establish a CC subscription.  Callers
 that are particularly sensitive about their privacy may reject all CC
 subscriptions.  But in the ordinary case, the optimal protection is

Worley, et al. Standards Track [Page 29] RFC 6910 Completion of Calls April 2013

 to permit any caller to subscribe but prevent any caller from
 subscribing for too long, or too often, or in a pattern that does not
 reveal to the callee (through CC calls) that the subscriptions are
 taking place.
 In legitimate use, CC event subscriptions will be made in stereotyped
 ways that limit the disclosure of status information:
 1.  When a subscriber is selected for CC, a call should arrive
     promptly for the callee, or the subscription should be
     terminated.  This expectation may be violated by a race condition
     between selection of the subscription for CC and the caller
     becoming unavailable, but it should be rare that a single
     subscription will exhibit the race condition more than once.
 2.  Subscriptions should not remain suspended for longer than the
     expected duration of a call (a call by the caller to a third
     party).
 3.  Subscriptions should be initiated only shortly after failed
     incoming calls.
 4.  Most of the time, a callee should have no queued subscriptions.
 Violations of these expectations should be detected by the callee's
 monitor and reported as possible attempts at privacy violation.
 The CC facility may enhance the effectiveness of Spam over Internet
 Telephony (SPIT) via the following technique: the caller makes calls
 to a group of callees.  The caller then requests CC for the calls
 that do not connect to the callees.  The resultant CC calls are
 probably more likely to reach the callees than original calls to a
 further group of targets.
 In order to prevent senders of SUBSCRIBE and PUBLISH requests from
 causing Denial-of-Service (DoS) attacks and suspending other CC
 entries than their own, a mechanism to correlate the identity of the
 original caller and the sender of SUBSCRIBE and PUBLISH requests is
 needed.  The RECOMMENDED mechanism to authenticate the identity of
 the originator of requests relevant to CC is the SIP Identity
 mechanism [RFC4474].  Alternatively, CC agents and monitors within an
 administrative domain or federation of domains MAY use the mechanism
 described in [RFC3325] to authenticate their identities with a
 P-Asserted-Identity header field.
 Furthermore, the use of the presence server to suspend or resume
 SHOULD be limited to a caller that has an active queue in the
 callee's monitor.  This can be achieved first by monitoring and

Worley, et al. Standards Track [Page 30] RFC 6910 Completion of Calls April 2013

 logging incoming calls to the callee and the destination where CC
 indication was sent, then to ensure that subscription to the
 call-completion event package is permitted only within a short time
 frame after the initial call failed and to only accept PUBLISH
 requests to the presence server if there is an active queue for the
 caller in question.
 Note that regarding authentication/authorization/billing logic
 subject to operator policy, CC calls or subscriptions do not differ
 from other basic calls or event subscriptions.

12. IANA Considerations

12.1. SIP Event Package Registration for CC

 This specification registers an event package, based on the
 registration procedures defined in [RFC6665].  The following
 information is required for such a registration:
 Package name: call-completion
 Is this registration for a Template-Package: No.
 Published specification: RFC 6910.
 Person & email address to contact for further information: 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.
 Encoding considerations: Consists of lines of UTF-8-encoded
 characters, ended with CRLF.
 Security considerations: There are no security considerations
 internal to the media type.  Its typical usage involves the security
 considerations described in RFC 6910.
 Interoperability considerations: See RFC 6910.
 Published specification: RFC 6910.

Worley, et al. Standards Track [Page 31] RFC 6910 Completion of Calls April 2013

 Applications that use this media type: The implementations of the CC
 features of the Session Initiation Protocol.
 Additional information:
    Magic number(s): none
    File extension(s): Not expected to be stored in files.
    Macintosh file type code(s): Not expected to be stored in files.
 Person & email address to contact for further information:
 Martin Huelsemann, martin.huelsemann@telekom.de
 Intended usage: LIMITED USE
 Restrictions on usage: none
 Author/Change controller: The IETF

12.3. SIP/SIPS URI Parameter 'm'

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

Worley, et al. Standards Track [Page 32] RFC 6910 Completion of Calls April 2013

12.4. The 'purpose' Parameter Value 'call-completion'

 This specification 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: Call-Info
 Parameter name: purpose
 Predefined values: yes
 Reference: [RFC3261] [RFC5367] [RFC6910]

12.5. 'm' Header Parameter for Call-Info

 This specification extends [RFC3261] to add a new header field
 parameter 'm' to the Call-Info header field.  This adds a row to the
 registry header field parameters and parameter values:
 Header field: Call-Info
 Parameter name: m
 Predefined values: yes
 Reference: [RFC6910]
 The predefined values are 'BS', 'NR', and 'NL'.

13. Acknowledgements

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

Worley, et al. Standards Track [Page 33] RFC 6910 Completion of Calls April 2013

14. References

14.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            June 2002.
 [RFC3515]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
            Method", RFC 3515, April 2003.
 [RFC3863]  Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
            W., and J. Peterson, "Presence Information Data Format
            (PIDF)", RFC 3863, August 2004.
 [RFC3903]  Niemi, A., "Session Initiation Protocol (SIP) Extension
            for Event State Publication", RFC 3903, October 2004.
 [RFC3969]  Camarillo, G., "The Internet Assigned Number Authority
            (IANA) Uniform Resource Identifier (URI) Parameter
            Registry for the Session Initiation Protocol (SIP)",
            BCP 99, RFC 3969, December 2004.
 [RFC4235]  Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
            Initiated Dialog Event Package for the Session Initiation
            Protocol (SIP)", RFC 4235, November 2005.
 [RFC4474]  Peterson, J. and C. Jennings, "Enhancements for
            Authenticated Identity Management in the Session
            Initiation Protocol (SIP)", RFC 4474, August 2006.
 [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
            Specifications: ABNF", STD 68, RFC 5234, January 2008.
 [RFC5367]  Camarillo, G., Roach, A.B., and O. Levin, "Subscriptions
            to Request-Contained Resource Lists in the Session
            Initiation Protocol (SIP)", RFC 5367, October 2008.
 [RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
            Agent URIs (GRUUs) in the Session Initiation Protocol
            (SIP)", RFC 5627, October 2009.
 [RFC6665]  Roach, A.B., "SIP-Specific Event Notification", RFC 6665,
            July 2012.

Worley, et al. Standards Track [Page 34] RFC 6910 Completion of Calls April 2013

14.2. Informative References

 [ETS300.356-18]
            European Telecommunications Standards Institute,
            "Completion of Calls to Busy Subscriber (CCBS)
            supplementary service", February 1995.
 [ITU-T.Q.733]
            International Telecommunication Union, "Description for
            Call Completion Supplementary Services Using SS No. 7",
            February 1995.
 [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
            Extensions to the Session Initiation Protocol (SIP) for
            Asserted Identity within Trusted Networks", RFC 3325,
            November 2002.
 [RFC3725]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G.
            Camarillo, "Best Current Practices for Third Party Call
            Control (3pcc) in the Session Initiation Protocol (SIP)",
            BCP 85, RFC 3725, April 2004.
 [RFC5359]  Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and
            K. Summers, "Session Initiation Protocol Service
            Examples", BCP 144, RFC 5359, October 2008.

Worley, et al. Standards Track [Page 35] RFC 6910 Completion of Calls April 2013

Appendix A. Example Caller's Agent

 This section outlines how an autonomous caller's agent can operate
 using only standard SIP features to interact with the caller's UA.
 This example is suitable only as a learning aid, as its performance
 is poor.
 The agent monitors calls made from the UA(s) by subscribing to the
 dialog event package of the UA(s).
 The UA(s) or their proxy routes calls made with either of two special
 dial sequences to the agent, which interprets the INVITEs as
 indications to make a CC request with BS or NR or NL mode for the
 latest call made by the UA.
 The agent monitors the status of the UA(s) for availability to be
 used for a CC call by examining the dialog events.
 The agent indicates to the UA(s) that CC recall is in progress by
 making call to the UA(s).  If the UA is answered, the agent assumes
 that the caller is available and plays pre-recorded audio to indicate
 that CC recall is in progress.
 After playing the pre-recorded audio, the caller's agent uses REFER
 to order the UA to make the CC call to the callee.

Appendix B. Example Callee's Monitor

 This section outlines how an autonomous callee's monitor can operate
 using only standard SIP features to interact with the callee's UA.
 This example is suitable only as a learning aid, as its performance
 is poor.
 The callee's monitor monitors calls made to the UA(s) by subscribing
 to the dialog events of the UA(s).  This enables it to determine
 their Call-Ids and their final response statuses.
 The proxy for the UA(s) routes to the callee's monitor any SUBSCRIBEs
 for the call-completion event package directed to the URIs serviced
 by the UA(s).
 The callee's monitor monitors the status of the UA(s) to determine
 when they are in a suitable state to receive a CC call by watching
 the busy/not-busy status of the UA(s): for example, a UA is available
 for CCBS when it is not busy, but a UA is available for CCNR when it
 becomes not busy after being busy with an established call.

Worley, et al. Standards Track [Page 36] RFC 6910 Completion of Calls April 2013

Authors' Addresses

 Dale R. Worley
 Ariadne Internet Services, Inc.
 738 Main St.
 Waltham, MA  02451
 US
 Phone: +1 781 647 9199
 EMail: worley@ariadne.com
 Martin Huelsemann
 Deutsche Telekom
 Heinrich-Hertz-Strasse 3-7
 Darmstadt  64307
 Germany
 Phone: +4961515812765
 EMail: martin.huelsemann@telekom.de
 URI:   http://www.telekom.de
 Roland Jesske
 Deutsche Telekom
 Heinrich-Hertz-Strasse 3-7
 Darmstadt  64307
 Germany
 Phone: +4961515812766
 EMail: r.jesske@telekom.de
 URI:   http://www.telekom.de
 Denis Alexeitsev
 TeleFLASH
 Mainzer Landstrasse 47
 Frankfurt  60329
 Germany
 Phone: +49-69-257-378-230
 EMail: alexeitsev@teleflash.com
 URI:   http://www.teleflash.com

Worley, et al. Standards Track [Page 37]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6910.txt · Last modified: 2013/04/15 21:46 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki