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
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)
完成对会话启动协议（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).
为了实现无需排队的基本解决方案，本文档引用了对话事件包（RFC 4235）的用法，该程序包在“会话启动协议服务示例”（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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6910.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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
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
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.
呼叫完成（CC）功能允许失败呼叫的呼叫方完成呼叫，而无需在猜测被呼叫方何时可用时进行新的呼叫尝试。当调用者请求使用CC功能时，将监视被调用者的可用性。当被呼叫者可用时，被呼叫者将获得启动呼叫的特定时间范围。如果被呼叫者在此时间范围内未发起新呼叫，则呼叫者将被召回。当调用者接受CC调用时，将自动启动对被调用者的CC调用。如果多个呼叫者对同一被呼叫者请求了CC功能，他们将按照预定义的顺序被调用，这通常是他们请求CC功能的顺序。
This document defines the following CC features:
本文档定义了以下CC功能：
Completion of Calls to Busy Subscriber (CCBS): The callee is busy. The caller is recalled after the callee is no longer busy.
呼叫忙用户（CCBS）完成：被叫方忙。在被叫方不再忙后，将调用被叫方。
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.
无应答呼叫完成（CCNR）：被叫方不应答呼叫。在被叫方完成新呼叫后，将调用被叫方。
Completion of Calls on Not Logged-in (CCNL): The callee is not registered. The caller is recalled after the callee has registered again.
未登录时完成呼叫（CCNL）：被叫方未注册。在被叫方再次注册后，将调用被叫方。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document uses terms from [RFC3261].
本文件使用[RFC3261]中的术语。
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.
被叫方：原始呼叫的目的地和CC呼叫的目标。
Caller: the initiator of the original call and the CC request. The user on whose behalf the CC call is made.
Caller：原始呼叫和CC请求的发起方。代表其进行CC呼叫的用户。
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.
被叫方监控器：一个逻辑组件，用于实现目标用户/UA（用户代理）的CC队列，并执行相关任务，包括发送CC回调事件，类似于目标本地交换机在信令系统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.
呼叫方代理：代表发起用户/UA发出CC请求并响应CC回调事件的逻辑组件，类似于发起本地交换机在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，或呼叫完成：一种服务，当被呼叫者可以接收呼叫时，允许未能到达所需被呼叫者的呼叫者收到通知。
CC activation: the indication by the caller to the caller's agent that the caller desires CC for a failed original call; this implies an indication transmitted from the caller's agent to the callee's monitor of the desire for CC processing.
CC激活：呼叫者向呼叫者的代理表明，呼叫者希望对失败的原始呼叫进行CC；这意味着从呼叫者的代理传输到被呼叫者的监视器的指示需要CC处理。
CCBS, or Completion of Calls to Busy Subscriber: a CC service provided when the initial failure was that the destination UA was busy.
CCB，或完成对繁忙用户的呼叫：当初始故障是目标UA繁忙时提供的CC服务。
CCNR, or Completion of Calls on No Reply: a CC service provided when the initial failure was that the destination UA did not answer.
CCNR，或无应答呼叫完成：当初始故障是目标UA未应答时提供的CC服务。
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.
CCNL，或在未登录时完成呼叫：当初始故障是目标UA未注册时提供的CC服务。
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 call：从呼叫者到被呼叫者的呼叫，由CC服务在确定被呼叫者可用时触发。
CC indicator: an indication in the CC call INVITE used to prioritize the call at the destination.
CC指示符：CC call INVITE中的一个指示，用于确定目的地呼叫的优先级。
CC possible indication: the data in responses to the INVITE of the original call that indicate that CC is available for the call.
CC可能指示：原始呼叫的INVITE响应数据，表明CC可用于呼叫。
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 events：事件包“呼叫完成”的事件通知，由被叫方的监视器发送给呼叫方的代理，通知其CC请求的状态。
CC recall timer: maximum time the callee's monitor will wait for the caller's response to a CC recall.
CC recall timer：被呼叫方的监视器等待呼叫方对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 request：被调用方的监视器队列中的条目，表示调用方的CC处理请求，即调用方的CC订阅。
CC service duration timer: maximum time a CC request may remain active within the network.
CC服务持续时间计时器：CC请求在网络中保持活动状态的最长时间。
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.
CC队列：被呼叫方监视器上的缓冲区，用于存储作为CC目标的传入呼叫。注意：此缓冲区可以组织为队列，也可以不组织为队列。术语“队列”的使用类似于SS7的使用。
CCE, or CC Entity: the representation of a CC request, or, equivalently, an existing CC subscription within the queue of a callee's monitor.
CCE或CC实体：CC请求的表示形式，或等效地，被调用方监控器队列中现有CC订阅的表示形式。
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.
失败呼叫：从呼叫方的角度来看，未到达所需被呼叫方的呼叫。注意，从SIP的角度来看，失败的呼叫可能是成功的；e、 例如，如果呼叫到达被呼叫方的语音信箱，但呼叫方希望与被呼叫方实时通话，INVITE将收到200响应，但呼叫方认为呼叫失败。
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.
通知者：为通知订户被叫方的可用性而生成通知请求的UA；对于CC服务，这是被叫方监控器的任务。
Original call: the initial call that failed to reach a desired destination.
Original call: the initial call that failed to reach a desired destination.translate error, please retry
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.
保留选项：CC服务的一个特征；如果支持，再次遇到忙碌被叫方的CC呼叫将不会再次排队，但会保留呼叫者条目在队列中的位置。请注意，SIP CC始终在保留选项处于活动状态时运行；失败的CC调用不会导致CC请求失去其在队列中的位置。
Signaling System 7, or SS7: the signaling protocol of the public switched telephone network, defined by ITU-T Recommendations Q.700 through Q.849.
信令系统7，或SS7：公共交换电话网的信令协议，由ITU-T建议Q.700至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.
订户：接收带有被叫方可用性信息的通知请求的UA；对于CC服务，这是调用方代理的任务。
Suspended CC request: a CC request that is temporarily not to be selected for CC recall.
暂停抄送请求：暂时不选择用于抄送召回的抄送请求。
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").
CC体系结构增强了希望将CC功能与“CC代理”（也称为“调用方代理”）一起使用的每个调用方的UA（或用户代理客户端（UAC））。
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").
它使用“抄送监视器”（也称为“被呼叫者监视器”）来增强每个希望成为抄送功能目标的被呼叫者的UA（或用户代理服务器（UAS））。
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
呼叫者的代理和被呼叫者的监控功能可以集成到各自的UAs中，可以是独立的终端系统，也可以由集中式应用服务器提供。这两个功能虽然与两个ua（呼叫者和被呼叫者）关联，但也可以提供
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.
作为端点的主代理或其他网络元素提供的服务。虽然预期实现CC的UA将同时具有这两个功能，以便它可以作为调用者和被调用者参与CC，但这两个功能是相互独立的。
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).
如果呼叫者或用户群将在UAs之间共享，并且特别是如果UAs共享记录地址（AOR），则呼叫者的代理可以将多个UA作为一个集合组来服务。
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.
呼叫方的代理监控来自呼叫方UA的呼叫，以确定其目的地和（可能）最终响应状态，以及调用CC功能的临时和最终响应的Call Info报头字段。
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.
如果被叫方或用户群将在UAs之间共享，并且特别是如果UAs共享AOR，则被叫方的监控器可以作为一个集合组为多个UA提供服务。被叫方的监视器可以向被叫方的UAS提供呼叫信息头字段值，用于临时和最终响应。
The callee's monitor also instantiates a presence server used to monitor the caller's availability for CC recall.
被呼叫者的监视器还实例化了一个状态服务器，用于监视呼叫者的CC调用可用性。
The callees using the UA(s) may be able to indicate to the callee's monitor when they wish to receive CC calls.
使用UA的被叫方可以在希望接收CC呼叫时向被叫方的监视器指示。
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.
为了实现灵活性和创新性，呼叫者的代理、呼叫者（用户）和呼叫者的UA之间的大部分交互不在本文档的范围内。类似地，被叫方的监视器、被叫方和被叫方的UA之间的大多数交互不在本文档的范围内，被叫方的监视器在多个CC请求之间进行仲裁的策略也不在本文档的范围内。
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.
呼叫方的代理必须能够执行与UA相关的许多功能。其使用的方法不在本文件范围内，但附录A中描述了示例方法。被叫方的监控器必须能够执行与UA相关的多项功能。其使用的方法不在本文件范围内，但附录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.
作为概念证明，可以设计简单的呼叫者代理和被呼叫者监视器，完全通过标准SIP机制[RFC6665][RFC4235][RFC3515]与用户和UAs交互，如附录中所述。
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.
使用UA的呼叫者可以向呼叫者的代理指示，当他们希望利用CC来进行最近拨打的呼叫时，呼叫者被确定为不成功。呼叫者的代理监控呼叫者的UA的状态，以确定它们何时可用于CC调用。呼叫者的代理可以向呼叫者的UA传达正在进行CC召回，并询问相关呼叫者是否可用于CC召回。
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.
被叫方的监视器可以利用几种方法来监视被叫方的UA和/或其用户的状态，以获取接收CC呼叫的可用性。这可以通过监视对被叫方UA的呼叫来实现，以确定被叫方的状态、呼叫者的身份以及传入呼叫的最终响应。并且在具有丰富存在信息的系统中，存在信息可以直接提供该状态。在更受限的系统中，此确定可能取决于相关CC调用的模式，该模式由URI“m”参数提供。例如，UA在不忙时被认为可用于CCB（“m=BS”），但UA在忙于已建立呼叫后变得不忙时被认为可用于CCNR（“m=NR”）。
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.
被呼叫者的监视器维护被呼叫者认为不成功的被呼叫者的UA接收到的邀请集的信息。实际上，如果被叫方监控器的本地策略确定该对话框不再符合CC激活的条件，则被叫方监控器可能会从其集合中删除有关传入对话框的知识。
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.
调用方的UA向请求URI发送邀请。此请求的一个或多个分支到达被叫方的一个或多个UAs。如果CC功能可用，则被叫方的监视器（注意，每个被叫方的UAs都可以有一个监视器）在对初始邀请的适当非100临时或最终响应中插入一个带有URI和“目的=呼叫完成”的呼叫信息头字段，并将其转发给主叫方。如果INVITE包含带有选项标记100rel的受支持标头字段，则应可靠地发送临时响应。在收到指示CC功能可用的非100临时或最终响应时，呼叫用户可以调用CC功能。
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".
调用者向调用者的代理表明他希望在最近的呼叫中调用CC服务。注意，从SIP的角度来看，INVITE可能已经成功，但从用户的角度来看，呼叫可能已经失败。例如，呼叫可能已连接到被呼叫方的语音邮件，该语音邮件将向邀请返回200状态，但从呼叫方的角度来看是“无应答”。
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).
调用方在被调用方完成调用的可能性也称为调用方的CC状态（CC状态）。cc状态理解值“排队”和“准备就绪”（对于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.
为了从被呼叫方可到达的所有目的地接收信息，呼叫方的代理向呼叫的原始目的地URI和被呼叫方监控器的所有已知URI发送呼叫完成事件包的订阅请求（由INVITE的临时和最终响应中的Call Info头字段提供）。每个被叫方的监视器都使用订阅作为指示，表明被叫方有兴趣针对特定被叫方使用CC功能。
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].
每个被叫方的监控器都保存一个来自被叫方代理的订阅列表或队列，表示从被叫方代理到被叫方监控器的CC服务请求。根据[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".
当从呼叫者的代理接收到订阅请求时，被呼叫者的监视器实例化呼叫者的UA的存在状态，该状态可由呼叫者的UA修改以指示其可用于CC呼叫。实例化后，调用方在被调用方监视器上的状态为“打开”。
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.
当被呼叫者的监视器确定被呼叫者和/或被呼叫者的UA可用于CC呼叫时，它选择呼叫者执行CC呼叫，并通过通知请求向呼叫者的代理的所选订阅发送CC事件更新（“CC状态：就绪”），告知其开始向被呼叫者的UA进行CC呼叫。
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.
当呼叫者的代理收到此更新时，它通过呼叫呼叫者的UA启动CC调用，然后根据[RFC3725]使用第三方呼叫控制程序启动对被呼叫者的UA的CC调用。呼叫者的代理还可以通过其他方式检查呼叫者是否可以向被呼叫者的UA发起CC呼叫。如果呼叫者可用，呼叫者的代理指示呼叫者的UA向被呼叫者的UA发起CC呼叫。
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.
调用者的代理通过向请求URI添加特定的SIPURI参数来标记CC调用，因此，在到达被调用者的UA时，被调用者的监视器可以给予它优先权。
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".
如果呼叫者在收到“准备召回”通知时不可用，则呼叫者的代理通过向被呼叫者的监视器的状态服务器发送包含状态信息的发布请求，通知服务器状态为“关闭”，从而在被呼叫者的监视器上挂起CC请求。一旦呼叫者再次可用于CC呼叫，呼叫者的代理通过向被呼叫者的监视器发送另一个发布请求来恢复CC请求，通知监视器状态为“打开”。
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.
收到挂起请求后，被叫方的监控器将对队列中的下一个非挂起CC请求执行监控。从位于队列顶部的先前挂起的调用方代理收到恢复后，被调用方的监控器将对此调用方的代理执行被调用方监控。
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.
当CC调用失败时，有两种可能的选项：呼叫方代理订阅被呼叫方的监视器时必须再次激活CC功能，或者CC保持激活状态，如果支持保留选项，则原始CC请求保留其在队列中的位置。
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.
retain选项（参见第3节）确定了CC调用失败时被调用方监控器的行为。如果支持retain选项，CC将保持激活状态，原始CC请求将保留其在队列中的位置。否则，CC功能将被停用，调用方的代理必须再次订阅才能重新激活它。
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.
支持保留选项的监视器在其cc事件中提供cc服务保留标头。也支持retain选项的调用方代理使用此标头的存在来知道在CC调用失败后不生成新的CC请求。
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.
不支持保留选项的监控器不提供cc服务保留标头。失败的CC调用将导致从队列中删除CC请求，这些监控器将终止调用方代理的相应订阅，以通知该代理其CC请求不再在队列中。不支持retain选项的呼叫者的代理也可以在CC呼叫失败时终止其订阅，因此呼叫者的代理和被呼叫者的监视器可能同时发出终止订阅的信号。这是正常的SIP事件[RFC6665]场景。订阅终止后，呼叫者的代理可以创建新的订阅（如第6.2节所述），以重新激活原始呼叫的CC功能。
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.
自动重拨是一种简单的端到端设计。[RFC5359]第2.17节介绍了自动重拨方案。此解决方案基于对话框事件包的使用。如果呼叫到达时被叫方正忙，则呼叫者订阅被叫方的呼叫状态。被叫方的UA在被叫方的呼叫状态更改时发送通知。这意味着当被叫方的呼叫状态更改为“已终止”时，也会通知呼叫者。呼叫方收到警报，然后呼叫方的UA再次开始与被呼叫方建立呼叫。如果多个呼叫者已经订阅了忙碌的被呼叫者的呼叫状态，则会同时通知他们呼叫状态已更改为“已终止”。此解决方案的问题在于，可能会同时启动多个召回。这意味着这是一种启发式方法，不能保证成功。
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.
CC和自动重拨之间没有交互，因为当使用对话事件包接收对话信息或聚合CC状态时，被调用方的监视器和调用方的行为有所不同。
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.
SIP CC在某些方面不同于SS7（用于公共交换电话网（PSTN））的CCB和CCNR功能。为了便于理解，我们在此列举一些差异。
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.
由于SS7中没有等效的分叉机制，在PSTN中，呼叫可以清楚地区分为成功或失败。由于SIP中可能存在复杂的分叉情况，从用户的角度来看，呼叫可能会失败，但从SIP的角度来看，呼叫可能会成功响应。（即使在简单的情况下，这也可能发生：例如，呼叫到忙语音用户的忙用户收到SIP成功响应，即使呼叫方可能认为它是“忙订户”）。因此，即使原始呼叫出现成功，呼叫者也必须能够调用CC。为了支持这一点，呼叫者的代理必须记录成功的呼叫以及失败的呼叫。
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.
在SIP中，只有发起方的呼叫者的UA或服务系统和终止方的被呼叫者的UA或服务系统需要支持CC for CC才能在UAs之间成功工作。中间SIP系统（代理或背靠背用户代理（B2BUA））不需要实现CC；它们只需要对通常范围的SIP消息透明。此外，在PSTN中，媒体网关控制器等中间节点必须实现CC服务。
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.
被调用方的监视器管理单个URI的CC。此URI可能是已发布的AOR，或者更可能是“非语音邮件AOR”，但其范围可能与单个UA的联系人URI一样狭窄。被叫方的监视器管理一组动态的CC实体（称为“CCE”），它们表示CC请求，或者等效地表示现有的传入CC订阅。此集合也称为队列，因为队列数据结构通常有助于实现被叫方监控器的策略，以便为CC回调选择CCE。
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".
每个CCE都有一个可用性状态，通过呼叫者在被呼叫者监视器上的状态来确定。状态为“打开”表示CCE的可用状态为“可用”，状态为“关闭”表示CCE的可用状态为“不可用”。
Each CCE has a recall state that is visible via subscriptions. The recall state is either "queued" or "ready".
每个CCE都有一个通过订阅可见的回调状态。召回状态为“排队”或“准备就绪”。
Each CCE carries the From URI of the SUBSCRIBE request that caused its creation.
每个CCE都携带导致其创建的订阅请求的From URI。
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.)
CC订阅通过寻址被调用方监控器在Call Info标头字段中返回的URI到达被调用方监控器。SUBSCRIBE请求的请求URI确定向其添加结果CCE的队列。生成的订阅报告队列的状态。基本事件数据是队列中所有CCE的状态，但每个订阅返回的数据都经过筛选，仅报告该订阅的CCE状态。（进一步的标准化可以定义获取队列更全面信息的方法。）
When a CCE is created, it is given the availability state "available" and recall state "queued".
创建CCE时，它被赋予可用性状态“available”和调用状态“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).
当被叫方的监视器通过发布请求[RFC3903]接收到状态信息数据格式（PIDF）主体[RFC3863]时，这些发布请求预计将由订阅者发送，以通过修改其CCE可用性状态间接挂起和恢复其CC请求。CCE由请求URI（如果它来自识别CCE的CC事件通知）或请求的from URI（匹配CCE中记录的from URI）标识。收到状态为“打开”的发布后，将CCE的可用状态设置为“可用”（恢复）；状态“关闭”将CCE的可用性状态设置为“不可用”（挂起）。
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.
CC请求只有在其CCE的可用性状态为“可用”且CCE的“m”值也指示可用状态时才有资格召回。被呼叫者的监视器不得选择任何不符合这些条件的CC请求进行回调。在该约束内，被调用方的监视器所做的选择由其本地策略决定。通常，被叫方的监视器会选择队列中最长的可接受CCE。当被叫方的监视器选择了要召回的CCE时，它会将CCE的召回状态从“排队”更改为“就绪”，从而触发CCE订阅的通知。
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.
如果所选订户随后通过发送状态为“关闭”的发布来暂停其请求，则CCE变为“不可用”，被叫方的监视器将CCE的召回状态更改为“排队”。这可能导致选择另一个CCE（例如，排队时间较短的CCE）进行召回。
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.
当呼叫者完成其CC呼叫或在被呼叫者监视器上终止对呼叫者代理的订阅时，呼叫者在被呼叫者监视器上的存在状态终止。
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.
呼叫者的代理必须记录From URI，并应记录呼叫者的UA收到的最终请求状态以及临时和最终响应的Call Info报头字段的内容。
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.
注意，接收CC可能的指示还取决于代理的最终响应的聚合；在4xx响应的情况下，一些4xx响应更有可能发送给调用方。
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
对于CC激活，调用方的代理必须向所有已知被调用方的监视器URI发送订阅。被呼叫者的监视器URI可以在被呼叫者的监视器发送回的邀请的临时和最终响应中的Call Info header字段中提供。此外，调用方的代理应该在其被调用方的监视器URI集合中包含它发送原始邀请的原始请求URI，如果不清楚调用是否已转移到调用方未看到其响应的其他被调用方。在调用方的代理没有收到或不记得任何被调用方的监视器URI的情况下，只使用对原始请求URI的订阅。调用方的代理应该向这些URI添加一个“m”参数，以指示
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.
将所需的CC模式发送到被叫方的监视器。“m”参数的值应为原始邀请响应的Call Info header字段中接收到的“m”参数的值。
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.
为了最大限度地减少冗余订阅，如果调用方的代理能够这样做，则应按照[RFC3261]第8.2.2.2节的定义，将这些订阅显示为同一事务的分支。
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.
代理不能为单个调用方维护多个CC请求，并且不能指向单个原始目标URI。如果调用方再次请求相同目标URI的CC，则代理必须通过重用现有CC订阅或终止并重新创建它们，将新请求与现有CC请求合并。为此，根据[RFC3261]第19.1.4节，通过比较呼叫者的AOR来确定呼叫者的平等性，通过比较它们来确定目标URI的平等性。
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.
生成这些订阅时，From URI必须是调用方的AOR。To URI应该是原始调用的目标URI（如果代理知道并可以将其插入到To头中），否则必须是订阅的请求URI。
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.
订阅应具有头字段以优化其路由。特别是，它应该包含“Request Disposition:parallel”和Accept Contact头字段，以消除调用者不可接受的被调用者ua。
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.
调用方的代理必须准备好接收订阅的多个分支的多个响应，并建立多个订阅。调用方的代理还必须准备好让订阅失败；在这种情况下，无法为此原始调用调用CC。
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.
如果呼叫者的代理不再希望发起CC呼叫（例如，因为呼叫者已停用CC），则呼叫者的代理根据[RFC6665]终止订阅或按照第6.5节的规定暂停订阅。
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).
当收到抄送状态设置为“就绪”的通知时，呼叫者的代理应按照第6.5节中的步骤暂停对抄送的所有其他订阅，以防止来自该呼叫者的任何其他抄送请求接收抄送撤回。呼叫者的代理通过确认呼叫者将能够发起CC呼叫（例如，通过呼叫呼叫者的UA）来启动对呼叫者的CC回调。
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.
如果呼叫者可用于CC呼叫并且愿意发起CC呼叫，则呼叫者的代理会使呼叫者的UA向被呼叫者生成新的邀请。呼叫者的UA可以添加一个'm'URI参数，该参数的值为在对原始邀请的响应中在Call Info报头中接收到的'm'参数，以便在CC处理中指定其偏好并对CC呼叫进行优先级排序。INVITE应该发送到NOTIFY的cc URI中指定的URI，或者，如果不可用，它应该使用原始INVITE响应的Call Info header字段中的URI；如果不可用，它可能会使用原始邀请的请求URI（如果记录了此URI）。请注意，后一种选择可能不会提供理想的路由，但在简单的情况下，它可能会到达所需的被叫方或被叫方的监视器。
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.
如果呼叫方无法进行CC召回，呼叫方代理应暂停CC请求，直到呼叫方再次可用，或者如果与呼叫方代理的本地暂停策略相关的条件发生变化。为了挂起CC请求，呼叫者的代理应根据[RFC3903]中描述的程序，通过向CC的状态服务器所在的每个被呼叫者的监视器发送发布请求来发布呼叫者的状态，为呼叫者作为存在实体的身份提供PIDF状态“关闭”。发布请求应包含Expires标头字段，该字段的值对应于剩余CC订阅持续时间的当前值。
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.
每次发布都应发送到NOTIFY中接收到的CC URI或相应的SUBSCRIBE对话框中的CC URI，如果不可能，则发送到NOTIFY的Call Info header字段中接收到的相应被调用方的监视器URI，如果没有，则发送到订阅的联系人地址。
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.
当呼叫者不再忙时，或者如果与呼叫者代理的暂停策略相关的条件发生了变化，则呼叫者代理应恢复CC请求。为了恢复CC请求，呼叫者的代理应根据[RFC3903]中描述的程序向每个被呼叫者的监视器发送发布请求，通知每个监视器PIDF状态为“打开”，从而发布呼叫者的状态；否则，此请求将以与挂起发布请求相同的方式构造。
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.
在呼叫者的代理已经向不同的被呼叫者的监视器发送了多个CC暂停请求并且呼叫者再次可用的情况下，如由呼叫者的代理的本地恢复策略所确定的，呼叫者的代理可以向存在暂停的CC请求的每个被呼叫者的监视器发送恢复CC请求的发布。请注意，呼叫方代理的恢复策略可能规定手动恢复；因此，挂起的CC请求不应自动恢复。
The callee's monitor MUST record the From URI and MAY record the final request status(es) returned by the callee's UA(s).
被叫方的监视器必须记录From URI，并且可以记录被叫方UA返回的最终请求状态。
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.
如果被呼叫者的监视器希望使呼叫者能够使用CC服务，则必须在最终响应消息（例如，在486中，由于用户忙而启用CC）和至少一条非100临时响应消息（例如，在180中，由于没有响应）中插入带有“目的=呼叫完成”的呼叫信息报头字段将初始邀请转发给呼叫者时，将其发送到初始邀请。如果INVITE包含带有选项标记100rel的受支持标头字段，则应可靠地发送非100临时响应消息。本规范中定义的Call Info header字段值明确表示CC可用于失败的调用分支。
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".
被叫方的监视器应该在Call Info头字段中插入一个URI，在该字段中，被叫方的代理应该订阅CC。理想情况下，它是被叫方监视器的全局可路由URI[RFC5627]。实际上，它可能是被叫方的AOR，订阅将被路由到被叫方的监视器，因为它指定了“事件：调用完成”。
In order to enable CC, the Call-Info header field MUST be set up according to the following scheme:
要启用CC，必须根据以下方案设置Call Info header字段：
Call-Info: monitor-URI;purpose=call-completion;m=XX
Call-Info: monitor-URI;purpose=call-completion;m=XX
The 'm' parameter defines the "mode" of 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
“m”参数定义CC的“模式”。“m=NR”参数表示由于缺少响应而失败，“m=BS”参数表示由于用户忙而失败，“m=NL”参数表示由于未注册用户而失败（没有为所联系的AOR注册设备）。“m”参数对于PSTN互通和评估被叫方监视器中的状态信息非常有用。将来可能会定义其他值。也可以省略以下内容：
'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).
“m”参数完全相同。实现必须接受缺少“m”参数或具有未知值的CC操作，并在其环境中尽可能地执行这些操作（这可能是降级服务，尤其是在与SS7互操作时）。
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.
被叫方的监控器必须准备好接收呼叫完成事件包的订阅，该事件包指向其正在服务的UA的URI以及被叫方监控器在call Info header字段中提供的任何URI。必须按照[RFC6665]中定义的程序处理订阅，建立订阅。这些订阅表示调用方代理对CC服务的请求。
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.
如果监视器接收到两个或多个具有相同呼叫Id标头字段值的订阅，并且监视器考虑接收到的订阅的请求URI以请求同一组UAs的状态，则它们是一个订阅请求的冗余分叉，并且监视器应以482（合并请求）拒绝除一个之外的所有请求响应。
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.
如果（1）呼叫Id报头字段值不同，（2）From URI（即，呼叫者的AOR）相同（根据[RFC3261]第19.1.4节），（3）To URI（应为原始呼叫的请求URI），则监视器可确定传入CC订阅是现有CC订阅的副本具有相同的用户和主机端口组件，并且（4）监视器考虑接收到的订阅的请求URI，以请求相同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.
如果监控器确定新订阅是现有订阅的副本，则可以根据[RFC6665]中定义的程序终止现有订阅。在任何情况下，它都必须建立新的订阅。
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].
如果呼叫方的代理被选择为“就绪”状态，则继续订阅呼叫方的代理将向被呼叫方的监视器指示呼叫方的代理已准备好发起CC呼叫。如果被叫方的监控器发现无法选择用于CC回调的订阅，则应根据[RFC6665]终止订阅。
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".
调用完成事件包将各种信息点返回给调用方的代理，但它包含的重要数据是存储在cc队列中的调用方代理的cc请求的cc状态；开始时，此cc状态为“排队”。当代理请求的cc状态更改时，被调用方的监控器必须向调用方的代理发送cc事件通知。通知还应包含可用于暂停请求的URI。理想情况下，它是被叫方监视器的全局可路由URI[RFC5627]。实际上，它可能是被叫方的AOR，订阅将被路由到被叫方的监视器，因为它指定了“事件：调用完成”。
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.
呼叫完成事件包提供有关被叫方监控器策略的有限信息。特别地，如在PSTN中，“cc service retention”数据给出了“service retention”属性的指示，该属性指示如果cc呼叫由于被叫方的UA忙而失败，则cc请求是否可以继续到稍后的时间。如果被叫方的监视器支持服务保留选项，则被叫方的监视器应包括cc service retention参数。
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.
被叫方的监视器有一个关于何时以及如何为召回选择CC请求的策略。该策略可考虑请求的类型（例如，CCNR与CCB）、被叫方UA的状态、CC请求到达的顺序、CC请求已激活的时间长度，以及之前针对同一原始呼叫的任何CC激活尝试。被叫方的监视器通常一次只选择一个CC请求进行召回，但是如果被叫方的UA可以支持多个呼叫，它可能会选择多个。被叫方的监视器通常会选择最早的活动请求。
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.
当被叫方的监视器将所选订阅的状态数据从“排队”更改为“就绪”时，被叫方的监视器必须发送呼叫方代理订阅的通知，cc状态设置为“就绪”（调用通知）。NOTIFY还应该在cc URI中包含一个用于cc调用的URI。实际上，这可能是被叫方的AOR。
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.
发送召回通知后，被叫方的监视器必须启动召回计时器。建议使用10到20秒之间的值，该值对应于ETSI[ETS300.356-18]和ITU-T[ITU-T.Q.733]文件中对CC服务的建议。
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.
被叫方的UA和被叫方的监控器可以通过评估INVITE请求的“m”URI参数和From头的存在情况，赋予CC调用优先于非CC调用的优先级。被叫方的监视器监控CC呼叫的接收。CC呼叫到达后，必须停止调用计时器。如果CC呼叫未在调用计时器到期之前到达被叫方的UA，被叫方的监控器应停止处理调用，并将CC状态数据的值更改为“排队”（如果支持retain选项），如果不支持retain选项，则终止订阅。类似地，如果CC呼叫未被接受，被叫方的监视器将停止CC调用处理。根据其策略，以后可能会再次选择相同的原始呼叫进行CC召回。如果CC呼叫成功，被呼叫方的监视器必须根据[RFC6665]终止相关订阅，并且必须删除用于CC呼叫呼叫方挂起和恢复的任何关联存在事件状态。
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.
一旦CC呼叫成功或不成功地终止，被叫方的监视器的策略可以指定选择另一个用于召回的CC请求。另请注意，根据被叫方监控器的策略，可能会同时处理多个召回。
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.
如第6.5节所述，监视器可能会从调用方代理接收发布请求以暂停CC请求。发布请求可以通过其管理的URI、其插入到呼叫信息报头中的任何URI、其用作“呼叫完成”事件通知器的任何联系人URI或其作为呼叫完成事件包的“URI”行返回的任何URI来接收。
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.
如[RFC3903]中所述，接收到发布请求将在被叫方监视器的状态服务器上启动呼叫者身份的状态事件状态，如果之前未对另一个呼叫执行此操作，则会与逻辑状态服务器一起启动。
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.
监视器应该通过发布请求的请求URI来识别寻址的CCE，如果不可能，则通过From URI来识别。
If the processing of a CC request results in suspending that CC request by receiving a PUBLISH request from the caller's agent as described in Section 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.
如第6.5节所述，如果CC请求的处理通过从调用者的代理接收发布请求而导致挂起该CC请求，则被调用者的监视器必须停止调用计时器，并且必须确保该请求设置为“排队”状态，然后被叫方的监视器必须根据其本地策略尝试处理队列中的另一个CC请求。
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.
如第6.6节所述，当被呼叫方的监视器收到来自呼叫方代理的发布请求后恢复CC请求时，必须按照[RFC3903]中所述修改CC监视器状态服务器上呼叫方身份的状态事件状态。如果被叫方不忙，且当前正在处理的CC队列中没有条目，被叫方的监控器必须按照上述第7.3节的说明处理队列。
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):
基本的调用流（仅显示CC激活和调用的最重要消息）如下所示（请注意，这是一个示例，失败响应中可能会有变化）：
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 |
|<-------------------------|
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 |
|<-------------------------|
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.
最初的电话是一个普通的邀请。由于无响应（响铃无应答）而失败。在本例中，被调用方的管理代理生成487响应，因为当UA的邀请没有应答时，代理取消了邀请。487响应包含一个带有“目的=呼叫完成”的呼叫信息标题字段。Call Info header字段明确表示CC可用于此失败的调用分支。“m=NR”参数表示由于没有响应而失败，这对于PSTN互通和评估被叫方监视器中的存在信息很有用。
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".
呼叫信息标头字段中的URI（<sip:456@z.b.com>)是调用方的代理应订阅CC处理的位置。理想情况下，它是被调用方监视器的全局可路由URI。实际上，它可能是被叫方的AOR，订阅将被路由到被叫方的监视器，因为它指定了“事件：调用完成”。
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.
CC通过向所有已知被调用方的监视器URI发送订阅来激活。这些信息可由邀请响应中的Call Info header字段提供。
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.)
此外，调用者的代理需要在其被调用者的监视器URI集中包含原始请求URI，因为调用可能已转移到调用者未看到其响应的其他被调用者。（如果调用方的代理尚未收到或无法记住任何被调用方的监视器URI，则仅使用订阅请求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.
调用方的代理向这些URI添加一个“m”参数（如果可能）。在这种情况下，调用方的代理通过适当的请求处理将订阅分叉到[RFC3261]第8.2.2.2节定义的两个目的地。第一个订阅是来自callinfo的URI。
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.
第二个订阅是原始请求URI，并到达同一被调用方的监视器。因为它与已到达被叫方监视器的订阅具有相同的调用Id，被叫方监视器以482拒绝它，从而避免了冗余订阅。
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.
成功订阅的初始通知正文中有“cc state:queued”。最终，这个调用者被选中进行CC，并通过一个包含“CC状态：就绪”的通知被告知。此通知包含一个URI，CC调用的邀请应发送到该URI。实际上，这可能是被叫方的AOR。
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.
调用者生成一个新的INVITE到NOTIFY中指定的URI，或者如果没有这样的URI，或者如果调用者的代理无法记住它，那么它可以使用原始的请求URI。调用方添加“m”参数（如果可能）以指定CC处理。
Finally, the subscription for the CC request is terminated by the callee's monitor.
最后，被调用方的监视器终止对CC请求的订阅。
Another flow, with only the most significant messages of CC suspension and resumption shown, is as follows:
另一个流程仅显示CC暂停和恢复的最重要消息，如下所示：
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 |
|<-------------------------|
| |
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.
选择呼叫方进行CC，并通过包含“CC状态：就绪”的通知请求通知呼叫方。此时，呼叫方无法进行CC调用。
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.
为了在被调用方的状态服务器上更新其状态事件状态，调用方发送一个发布请求，通知状态服务器PIDF状态为“关闭”。发布请求按如下方式发送（按优先顺序）：（1）从对话中发送到NOTIFY中接收到的CC URI，（2）在相应的SUBSCRIBE对话框中，（3）从对话中发送到NOTIFY的Call Info header字段中接收到的相应被叫方的monitor URI，或（4）out of dialog到相应SUBSCRIBE对话框的远程联系人地址。
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.
当调用者再次可用于CC调用时，调用者通过生成发布请求来更新其在被调用者的状态服务器上的状态事件状态，该发布请求通知服务器PIDF状态为“打开”；否则，此请求将以与挂起发布请求相同的方式构造。
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".
本节根据[RFC6665]第5.4节规定了呼叫完成事件包。呼叫完成事件包的媒体类型为“应用程序/呼叫完成”。
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.
请注意，如果被叫方具有呼叫者队列设施，则被叫方的监控器可能希望将CC队列视为队列设施的一部分，并在事件包中包含有关队列状态的信息。这些信息的传达方式有待进一步标准化。
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.
SIP事件规范[RFC6665]要求包定义指定其包或模板包的名称。此包的名称为“呼叫完成”。此值显示在事件和允许事件标题字段中。
No package-specific Event header field parameters are defined for this event package.
没有为此事件包定义包特定的事件标头字段参数。
[RFC6665] requires package definitions to define the usage, if any, of bodies in SUBSCRIBE requests.
[RFC6665]需要包定义来定义订阅请求中实体的用法（如果有）。
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.
CC包的订阅请求可能包含正文。此正文定义要应用于订阅的筛选器。本文件未规定过滤文件，可能是未来标准化活动的主题。
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.
SUBSCRIBE请求请求有关最近从同一呼叫者呼叫被通知者UA的CC信息。如果INVITE中from header字段值的URI部分与SUBSCRIBE中from header字段值的URI部分相同，则调用被定义为“来自同一调用方”。
[RFC6665] requires package definitions to define a default value for subscription durations and to discuss reasonable choices for durations when they are explicitly specified.
[RFC6665]要求包定义定义订阅持续时间的默认值，并在明确指定时讨论持续时间的合理选择。
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.
如果订阅未明确请求持续时间，则默认请求的持续时间为3600秒，因为这是ETSI[ETS300.356-18]和ITU-T[ITU-T.Q.733]文档中针对CC服务建议的最高服务持续时间计时器值。由于订阅持续时间意味着不需要显式计时器，并且订阅持续时间可以被视为等同于SS7服务持续时间计时器，因此本规范也将订阅持续时间称为服务持续时间计时器。建议订阅者请求订阅时间至少为3600秒，并由通知者授予订阅时间。
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.
如果通知程序可以根据其策略确定，在某个持续时间之后，请求的订阅无法继续进入“就绪”状态，则应将授予的订阅时间缩短到该持续时间。如果通知程序可以根据其策略确定请求的订阅永远无法进入“就绪”状态，则应拒绝订阅。
[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.
[RFC6665]需要包定义来描述NOTIFY请求中允许的正文类型集，并指定订阅请求中没有Accept header字段时使用的默认值。呼叫完成事件包的通知必须包含描述CC状态的正文。
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.
如[RFC6665]所述，NOTIFY消息将包含描述订阅资源状态的主体。此正文采用订阅的Accept header字段中列出的格式，或者如果订阅中省略了Accept header字段，则采用包特定的默认格式。
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.
在此事件包中，通知正文包含一个CC文档。所有订阅者和通知者必须支持第10节所述的“应用程序/呼叫完成”数据格式。订阅请求可能包含接受标头字段。如果不存在此类标头字段，则其默认值为“应用程序/调用完成”。如果标题字段存在，则必须包括“应用程序/呼叫完成”。当然，服务器生成的通知必须采用订阅请求中Accept header字段中指定的格式之一。
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.
当订阅者想要在终止端订阅呼叫完成事件包以接收CC通知时，他们必须生成订阅请求。如第9.4节所述，订阅请求的生成可能意味着使用CC服务特定计时器。
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.
收到订阅刷新后，通知程序必须将订阅状态标头字段的“expires”参数设置为不高于订阅当前剩余持续时间的值，而不管订阅刷新的expires标头字段（如果存在）中接收到的值如何。
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.
如果由于CC队列已达到允许的最大条目数（短期拒绝）而导致订阅未成功，则通知程序必须向订阅服务器发送480个暂时不可用的响应，可能会根据通知程序的策略使用retry after参数。如果由于发生阻止并将继续阻止CC服务（长期拒绝）的情况而导致订阅失败，则通知程序必须向订阅服务器发送403禁止响应。
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.
根据[RFC3261]第8.2.2.2节的定义，通知程序可以接收同一订阅的多个分支。在这种情况下，通知程序必须使用482合并请求响应拒绝除一个之外的所有订阅，除非应用其他故障响应。
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.
抄送信息可能是敏感的。因此，在处理所有订阅时，应考虑第11节中讨论的安全注意事项，特别是验证订阅方的身份。
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.
当CC请求的状态更改为“排队”或“准备就绪（用于CC）”时，通知程序必须生成NOTIFY请求。以非零过期时间发送的通知必须包含“cc state”参数。如果此时被调用方的监控器未选择订阅所代表的CC请求进行CC回调，则参数值必须为“排队”；如果此时被调用方的监控器已选择请求进行CC回调，则参数值必须为“就绪”。
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".
当被呼叫者的监视器撤回对CC调用请求的选择时（例如，因为呼叫者的代理在CC调用计时器到期之前未启动CC调用邀请，或者因为代理已暂停考虑CC调用请求），通知程序必须向所选请求的订阅发送通知。此通知必须包含设置为“排队”的“cc状态”参数。
If the CC subscription was successful and the retain option is supported at the callee, the NOTIFY MUST contain the "cc-service-retention" parameter.
如果CC订阅成功并且被调用方支持保留选项，则通知必须包含“CC服务保留”参数。
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.
当收到cc状态设置为“就绪”的NOTIFY请求时，订户应在其他通知程序上暂停原始呼叫的所有其他cc订阅。订阅服务器接收到cc状态设置为“就绪”的NOTIFY请求时，也会导致与订阅服务器端负责启动cc回调的实例进行交互。
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.
对于CC事件类型，分叉请求应该是常见的。订阅者必须准备好处理来自多个通知者的通知请求，并根据本文件中的程序协调其对从这些通知者处获得的信息的处理。
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".
CC服务通常涉及每个通知者和每个订阅的关于更改为“就绪”（对于CC）的单个通知，但可能涉及关于更改为“就绪”状态的多个通知，由因被呼叫方忙而失败的CC呼叫分隔。通常，通知之间的间隔至少为数十秒。通知程序不应在任何10秒钟的时间间隔内为一个订阅生成三个以上的通知。由于避免无用的召回非常重要，通知程序应立即将状态更改从“就绪”发送到“排队”。因此，通知程序不应将状态更改发送到“就绪”，作为十秒钟间隔内的第三个通知，因为这将导致无法立即将进一步的状态更改发送到“排队”。
State agents have no defined role in the handling of the call-completion event package.
状态代理在处理呼叫完成事件包中没有定义的角色。
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.
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.translate error, please retry
call-completion = 1*(cc-header CRLF)
call-completion = 1*(cc-header CRLF)
cc-header = cc-state / cc-service-retention / cc-URI /
extension-header
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].
The above rules whose names start with "cc-" are described below. Other rules are described in [RFC3261].translate error, please retry
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队列中的条目的特定用户的cc状态。它必须存在，除非通知中指示的过期时间为零。
cc-state = "cc-state" HCOLON ( "queued" / "ready" )
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.
值“queued”表示未选择CC队列中的订阅者条目进行CC调用。值“ready”表示已选择CC队列中的用户条目进行CC调用。
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呼叫失败，则如果被叫方支持retain选项，则该选项将保留CC队列中的条目。如果存在，此参数表示支持保留选项；否则，它不受支持。此参数可能存在于NOTIFY请求中。
cc-service-retention = "cc-service-retention" HCOLON "true"
cc service retention=“cc service retention”HCOLON“true”
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行提供了一个URI，代理应该将该URI用作cc-recall-INVITE和suspend/resume-PUBLISH的请求URI。应在所有NOTIFY中提供。URI应该是全局可路由的，并且应该唯一地标识有问题的CCE。语法在值中提供了泛型参数，但本文档未定义此类参数。订阅服务器无法理解的参数必须与URI一起保留。
cc-URI = "cc-URI" HCOLON addr-spec
cc URI=“cc URI”HCOLON地址规范
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.
CC功能允许调用方的代理确定有关被调用方的一些状态信息。该信息本质上减少了被叫人的隐私；为了充分保护被呼叫者的隐私，必须限制披露的总金额，并且必须限制对任何单个呼叫者的披露金额。
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
当然，如果不允许调用方调用被调用方，则不应允许该调用方建立CC订阅。对隐私特别敏感的来电者可能会拒绝所有CC订阅。但在一般情况下，最佳保护是
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.
允许任何呼叫者订阅，但防止任何呼叫者订阅时间过长或次数过多，或以不向被呼叫者（通过CC呼叫）透露订阅正在进行的模式订阅。
In legitimate use, CC event subscriptions will be made in stereotyped ways that limit the disclosure of status information:
在合法使用中，CC事件订阅将以限制状态信息披露的定型方式进行：
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.
1. 当选择一个用户进行抄送时，被叫方的呼叫应及时到达，或者应终止订阅。选择CC订阅和调用方变得不可用之间的竞争条件可能会违反此预期，但单个订阅很少会多次出现竞争条件。
2. Subscriptions should not remain suspended for longer than the expected duration of a call (a call by the caller to a third party).
2. 订阅的挂起时间不应超过呼叫的预期持续时间（呼叫方对第三方的呼叫）。
3. Subscriptions should be initiated only shortly after failed incoming calls.
3. 只有在传入呼叫失败后不久才能启动订阅。
4. Most of the time, a callee should have no queued subscriptions.
4. 大多数情况下，被叫方不应该有排队订阅。
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.
CC设施可通过以下技术增强互联网电话（SPIT）上垃圾邮件的有效性：呼叫者呼叫一组被呼叫者。然后，呼叫者请求CC处理未连接到被呼叫者的呼叫。结果CC调用可能比原始调用更有可能到达被调用方，从而到达另一组目标。
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.
为了防止订阅和发布请求的发送方引起拒绝服务（DoS）攻击并挂起其自身以外的其他CC条目，需要一种机制来关联原始调用方和订阅和发布请求的发送方的身份。建议使用SIP身份验证机制[RFC4474]来验证与CC相关的请求的发起人的身份。或者，管理域或域联盟内的CC代理和监控器可以使用[RFC3325]中描述的机制，使用P-Asserted-Identity报头字段验证其身份。
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
此外，状态服务器暂停或恢复的使用应限于在被叫方监视器中具有活动队列的呼叫方。这可以首先通过监测和评估来实现
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.
记录到被呼叫方和发送CC指示的目的地的传入呼叫，然后确保只有在初始呼叫失败后的短时间内才允许订阅呼叫完成事件包，并且仅在存在相关呼叫方的活动队列时才接受对状态服务器的发布请求。
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.
请注意，关于受运营商策略约束的身份验证/授权/计费逻辑，CC呼叫或订阅与其他基本呼叫或事件订阅没有区别。
This specification registers an event package, based on the registration procedures defined in [RFC6665]. The following information is required for such a registration:
本规范根据[RFC6665]中定义的注册过程注册事件包。此类注册需要以下信息：
Package name: call-completion
包名称：调用完成
Is this registration for a Template-Package: No.
这是模板包的注册：否。
Published specification: RFC 6910.
已发布规范：RFC 6910。
Person & email address to contact for further information: Martin Huelsemann, martin.huelsemann@telekom.de
联系人和电子邮件地址，以获取更多信息：Martin Huelsemann，Martin。huelsemann@telekom.de
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: call-completion
MIME子类型名称：调用完成
Required parameters: none.
所需参数：无。
Optional parameters: none.
可选参数：无。
Encoding considerations: Consists of lines of UTF-8-encoded characters, ended with CRLF.
编码注意事项：由UTF-8编码字符行组成，以CRLF结尾。
Security considerations: There are no security considerations internal to the media type. Its typical usage involves the security considerations described in RFC 6910.
安全注意事项：媒体类型内部没有安全注意事项。其典型用法涉及RFC 6910中描述的安全注意事项。
Interoperability considerations: See RFC 6910.
互操作性注意事项：参见RFC 6910。
Published specification: RFC 6910.
已发布规范：RFC 6910。
Applications that use this media type: The implementations of the CC features of the Session Initiation Protocol.
使用此媒体类型的应用程序：会话启动协议CC功能的实现。
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.
Macintosh文件类型代码：不应存储在文件中。
Person & email address to contact for further information: Martin Huelsemann, martin.huelsemann@telekom.de
联系人和电子邮件地址，以获取更多信息：Martin Huelsemann，Martin。huelsemann@telekom.de
Intended usage: LIMITED USE
预期用途：有限用途
Restrictions on usage: none
使用限制：无
Author/Change controller: The IETF
作者/变更控制者：IETF
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.
本规范根据[RFC3969]创建的注册表定义了一个新的SIP/SIPS URI参数“m”。它用于标识INVITE请求是CC调用，或者进一步标识SUBSCRIBE请求是针对调用完成事件包的。该参数的值可以描述CC操作的类型，如本规范所述。
Name of the parameter: m
参数名称：m
Predefined values: yes
预定义值：是
Reference: [RFC6910]
参考文献：[RFC6910]
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':
本规范为call Info header字段的'purpose'header字段参数添加了一个新的预定义值“call completion”。通过添加此RFC作为对标题字段“Call Info”和参数名称“purpose”行的引用，修改注册表标题字段参数和参数值：
Header field: Call-Info
标题字段：呼叫信息
Parameter name: purpose
参数名称：用途
Predefined values: yes
预定义值：是
Reference: [RFC3261] [RFC5367] [RFC6910]
参考文献：[RFC3261][RFC5367][RFC6910]
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:
本规范对[RFC3261]进行了扩展，在Call Info报头字段中添加了一个新的报头字段参数“m”。这将向注册表头字段参数和参数值添加一行：
Header field: Call-Info
标题字段：呼叫信息
Parameter name: m
参数名称：m
Predefined values: yes
预定义值：是
Reference: [RFC6910]
参考文献：[RFC6910]
The predefined values are 'BS', 'NR', and 'NL'.
预定义值为“BS”、“NR”和“NL”。
Thanks to Paul Kyzivat, John Elwell, Keith Drage, Andrew Hutton, Thomas Stach, Dennis Luebbers, and Christer Holmberg, who provided helpful comments, feedback, and suggestions.
感谢Paul Kyzivat、John Elwell、Keith Drage、Andrew Hutton、Thomas Stach、Dennis Luebers和Christer Holmberg，他们提供了有用的评论、反馈和建议。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.translate error, please retry
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]Sparks，R.，“会话启动协议（SIP）引用方法”，RFC3515，2003年4月。
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[RFC3863]Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[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.
[RFC3969]Camarillo，G.“会话启动协议（SIP）的Internet分配号码管理机构（IANA）统一资源标识符（URI）参数注册表”，BCP 99，RFC 3969，2004年12月。
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, November 2005.
[RFC4235]Rosenberg，J.，Schulzrinne，H.，和R.Mahy，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 4235，2005年11月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]Peterson，J.和C.Jennings，“会话启动协议（SIP）中身份验证管理的增强”，RFC 4474，2006年8月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[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.
[RFC5367]Camarillo，G.，Roach，A.B.和O.Levin，“会话启动协议（SIP）中包含资源列表的请求订阅”，RFC 5367，2008年10月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627]Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，RFC 5627，2009年10月。
[RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665]Roach，A.B.，“SIP特定事件通知”，RFC 66652012年7月。
[ETS300.356-18] European Telecommunications Standards Institute, "Completion of Calls to Busy Subscriber (CCBS) supplementary service", February 1995.
[ETS300.356-18]欧洲电信标准协会，“忙用户（CCBS）补充业务呼叫的完成”，1995年2月。
[ITU-T.Q.733] International Telecommunication Union, "Description for Call Completion Supplementary Services Using SS No. 7", February 1995.
[ITU-T.Q.733]国际电信联盟，“使用第7号SS的呼叫完成补充业务说明”，1995年2月。
[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.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[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.
[RFC3725]Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的当前最佳实践”，BCP 85，RFC 37252004年4月。
[RFC5359] Johnston, A., Sparks, R., Cunningham, C., Donovan, S., and K. Summers, "Session Initiation Protocol Service Examples", BCP 144, RFC 5359, October 2008.
[RFC5359]Johnston，A.，Sparks，R.，Cunningham，C.，Donovan，S.，和K.Summers，“会话启动协议服务示例”，BCP 144，RFC 5359，2008年10月。
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.
本节概述了自治呼叫者的代理如何仅使用标准SIP功能与呼叫者的UA交互。此示例仅适用于学习辅助，因为其性能较差。
The agent monitors calls made from the UA(s) by subscribing to the dialog event package of the UA(s).
代理通过订阅UA的对话事件包来监视UA发出的呼叫。
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.
UA或其代理将使用两个特殊拨号序列之一进行的呼叫路由到代理，代理将邀请解释为使用BS或NR或NL模式对UA进行的最新呼叫进行CC请求的指示。
The agent monitors the status of the UA(s) for availability to be used for a CC call by examining the dialog events.
代理通过检查对话框事件来监视UA的状态，以确定用于CC呼叫的可用性。
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.
代理通过呼叫UA向UA指示CC召回正在进行中。如果UA得到应答，则代理假定呼叫者可用，并播放预先录制的音频，以指示CC调用正在进行。
After playing the pre-recorded audio, the caller's agent uses REFER to order the UA to make the CC call to the callee.
播放预录制的音频后，呼叫者的代理使用REFER命令UA向被呼叫者进行CC呼叫。
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.
本节概述了仅使用标准SIP功能与被叫方的UA交互时，自主被叫方的监控器如何工作。此示例仅适用于学习辅助，因为其性能较差。
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.
被叫方的监控器通过订阅UA的对话事件来监控对UA的呼叫。这使它能够确定他们的呼叫ID和最终响应状态。
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).
UA的代理将呼叫完成事件包的任何订阅路由到被呼叫方的监控器，该事件包指向UA所服务的URI。
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.
被叫方的监视器监视UA的状态，以通过观察UA的忙/不忙状态来确定其何时处于接收CC呼叫的合适状态：例如，UA在不忙时可用于CCB，但UA在忙于已建立的呼叫后变为不忙时可用于CCNR。
Authors' Addresses
作者地址
Dale R. Worley Ariadne Internet Services, Inc. 738 Main St. Waltham, MA 02451 US
Dale R.Worley Ariadne互联网服务有限公司，地址：美国马萨诸塞州圣沃尔瑟姆大街738号，邮编：02451
Phone: +1 781 647 9199
EMail: worley@ariadne.com
Phone: +1 781 647 9199
EMail: worley@ariadne.com
Martin Huelsemann Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany
马丁·赫尔斯曼德国电信海因里希·赫兹大街3-7号达姆施塔特64307德国
Phone: +4961515812765
EMail: martin.huelsemann@telekom.de
URI: http://www.telekom.de
Phone: +4961515812765
EMail: martin.huelsemann@telekom.de
URI: http://www.telekom.de
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany
罗兰·杰西克德国电信海因里希·赫兹大街3-7号达姆施塔特64307德国
Phone: +4961515812766
EMail: r.jesske@telekom.de
URI: http://www.telekom.de
Phone: +4961515812766
EMail: r.jesske@telekom.de
URI: http://www.telekom.de
Denis Alexeitsev TeleFLASH Mainzer Landstrasse 47 Frankfurt 60329 Germany
Denis Alexetsev TeleFLASH Mainzer Landstrasse 47法兰克福60329德国
Phone: +49-69-257-378-230
EMail: alexeitsev@teleflash.com
URI: http://www.teleflash.com
Phone: +49-69-257-378-230
EMail: alexeitsev@teleflash.com
URI: http://www.teleflash.com