[要約] RFC 6910は、SIPにおける通話の完了に関するガイドラインです。その目的は、SIPセッションの終了プロセスを明確に定義し、通話の正常な終了を確保することです。
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 5359）で「自動リダイヤル」として説明されているダイアログイベントパッケージ（RFC 4235）の使用法を参照しています。
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.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Terminology ........................................4
3. Terminology .....................................................4
4. Solution ........................................................6
4.1. CC Architecture ............................................6
4.2. CC Procedures ..............................................8
4.3. Automatic Redial as a Fallback ............................11
4.4. Differences from SS7 ......................................11
5. CC Queue Model .................................................12
6. Caller's Agent Behavior ........................................13
6.1. Receiving the CC Possible Indication ......................13
6.2. Subscribing to CC .........................................13
6.3. Receiving a CC Recall Notification ........................14
6.4. Initiating a CC Call ......................................15
6.5. Suspending CC .............................................15
6.6. Resuming CC ...............................................15
7. Callee's Monitor Behavior ......................................16
7.1. Sending the CC Possible Indication ........................16
7.2. Receiving a CC Subscription ...............................17
7.3. Sending a CC Notification .................................18
7.4. Receiving a CC Call .......................................19
7.5. Receiving a CC Suspension .................................19
7.6. Receiving a CC Resumption .................................20
8. Examples .......................................................20
9. 'call-completion' Event Package ................................24
9.1. Event Package Name ........................................24
9.2. Event Package Parameters ..................................24
9.3. SUBSCRIBE Bodies ..........................................25
9.4. Subscribe Duration ........................................25
9.5. NOTIFY Bodies .............................................26
9.6. Subscriber Generation of SUBSCRIBE Requests ...............26
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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.
呼び出し元：元の呼び出しの開始者と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.
発信者のエージェント：SS7 CCでの発信元ローカル交換の役割と同様に、発信元ユーザー/ UAに代わってCC要求を行い、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.
CCBS、またはビジーサブスクライバーへの呼び出しの完了：最初の障害が宛先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呼び出し：呼び出し元から呼び出し先への呼び出し。呼び出し先が利用可能であると判断したときにCCサービスによってトリガーされます。
CC indicator: an indication in the CC call INVITE used to prioritize the call at the destination.
CCインジケータ：宛先でのコールの優先順位付けに使用されるCCコール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リコール：呼び出し先のモニターがCCコールの開始のために特定のCC要求を選択するアクション。これにより、呼び出し元のエージェントから呼び出し元に、CCコールを開始できるようになったことが示されます。
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リコールイベント：イベントパッケージ「call-completion」のイベント通知。CCリクエストのステータスを通知するために、呼び出し先のモニターから呼び出し元のエージェントに送信されます。
CC recall timer: maximum time the callee's monitor will wait for the caller's response to a CC recall.
CC再呼び出しタイマー：呼び出し先のモニターがCC再呼び出しに対する呼び出し元の応答を待機する最大時間。
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要求：呼び出し側の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の観点からは成功する可能性があることに注意してください。たとえば、呼び出しが呼び出し先のボイスメールに到達したが、呼び出し元が呼び出し先とリアルタイムで話したい場合、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.
Notifier：呼び出し先の可用性をサブスクライバーに通知する目的でNOTIFY要求を生成するUA。 CCサービスの場合、これは呼び出し先のモニターのタスクです。
Original call: the initial call that failed to reach a desired destination.
元の通話：目的の宛先に到達できなかった最初の通話。
Retain option: a characteristic of the CC service; if supported, CC calls that again encounter a busy callee will not be queued again, but the position of the caller's entry in the queue is retained. Note that SIP CC always operates with the retain option active; a failed CC call does not cause the CC request to lose its position in the queue.
保持オプション：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.
サブスクライバー：呼び出し先の可用性の情報を含むNOTIFY要求を受け取るUA。 CCサービスの場合、これは発信者のエージェントのタスクです。
Suspended CC request: a CC request that is temporarily not to be selected for CC recall.
中断されたCC要求：一時的にCCリコール用に選択されないCC要求。
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").
これは、CC機能のターゲットになりたい各呼び出し先のUA（またはユーザーエージェントサーバー（UAS））を「CCモニター」（「呼び出し先のモニター」とも呼ばれる）で補強します。
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 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.
呼び出し元のエージェントと呼び出し先のモニター機能は、それぞれのUAに統合することも、独立したエンドシステムにすることも、集中型アプリケーションサーバーで提供することもできます。 2つの機能は、2つのUA（呼び出し元と呼び出し先）に関連付けられていますが、エンドポイントのホームプロキシまたは他のネットワーク要素によってサービスとして提供される場合もあります。 CCを実装するUAには両方の機能があり、呼び出し元と呼び出し先の両方としてCCに参加できることが期待されますが、2つの機能は互いに独立しています。
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).
発信者またはユーザーの集団がUA間で共有される場合、特にUAがレコードのアドレス（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.
呼び出し先またはユーザーの母集団がUA間で共有される場合、特にUAがAORを共有する場合、呼び出し先のモニターは、複数のUAを集合グループとしてサービスすることができます。呼び出し先のモニターは、暫定応答と最終応答のCall-Infoヘッダーフィールド値を呼び出し先の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]を介してユーザーおよびUAと完全に対話する単純な発信者のエージェントおよび着信者のモニターを考案できます。
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のリコールに使用できる時期を判断します。発信者のエージェントは、CCのリコールが進行中であることを発信者のUAに通知し、関連する発信者が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に対して行われた呼び出しを監視して、呼び出し先の状態、呼び出し元のID、および着信呼び出しの最終応答を判断することで実現できます。また、プレゼンス情報が豊富なシステムでは、プレゼンス情報がこのステータスを直接提供する場合があります。より制限されたシステムでは、この決定は、問題のCC呼び出しのモードに依存する可能性があります。これは、URI「m」パラメーターによって提供されます。たとえば、UAは、ビジー状態でない場合はCCBS（ "m = BS"）で使用可能と見なされますが、確立されたコールでビジー状態になった後にビジー状態にならない場合は、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によって受信された一連のINVITEに関する情報を維持します。実際には、呼び出し先のモニターのローカルポリシーにより、ダイアログが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は、INVITEを要求URIに送信します。このリクエストの1つ以上のフォークが、1つ以上の呼び出し先のUAに到達します。 CC機能が利用可能な場合、呼び出し先のモニター（呼び出し先のUAごとにモニターが存在する可能性があることに注意）は、URIと「purpose = call-completion」を含むCall-Infoヘッダーフィールドを、適切な非100暫定または最初のINVITEへの最終応答およびそれらを発信者に転送します。 INVITEにオプションタグ100relのサポートされたヘッダーフィールドが含まれていた場合、暫定応答を確実に送信する必要があります（SHOULD）。 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ステータスをINVITEに返しますが、呼び出し元の観点からは「応答なし」です。
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-state）とも呼ばれます。 cc-statesは、 "queued"および "ready"（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.
呼び出し先が到達可能なすべての宛先から情報を受信するために、呼び出し元のエージェントは、呼び出し完了イベントパッケージのSUBSCRIBEリクエストを、呼び出しの元の宛先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".
呼び出し元のエージェントからSUBSCRIBE要求を受信すると、呼び出し先のモニターは、呼び出し元の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呼び出しを実行し、NOTIFY要求を介してCCイベント更新（ "cc-state：ready"）を呼び出し元のエージェントの選択されたサブスクリプション。呼び出し先の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.
呼び出し元のエージェントは、Request-URIに特定のSIP URIパラメータを追加することで、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".
呼び出し元が「リコールの準備完了」通知の受信時に利用できない場合、呼び出し元のエージェントは、呼び出し先のモニターのプレゼンスサーバーにプレゼンス情報を含むPUBLISH要求を送信し、サーバーに通知することにより、呼び出し先のモニターでCC要求を中断します。プレゼンス状態は「クローズ」です。発信者がCCコールに再び対応できるようになると、発信者のエージェントは、別のPUBLISHリクエストを着信者のモニターに送信して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コールが失敗した場合、2つの可能なオプションがあります。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.
保持オプション（セクション3を参照）は、CC呼び出しが失敗したときの呼び出し先のモニターの動作を決定します。保持オプションがサポートされている場合、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-service-retentionヘッダーを提供します。保持オプションもサポートする発信者のエージェントは、このヘッダーの存在を使用して、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-service-retentionヘッダーを提供しません。 CC呼び出しが失敗すると、CC要求がキューから削除され、これらのモニターは、呼び出し元のエージェントの対応するサブスクリプションを終了して、CC要求がキューに存在しないことをエージェントに通知します。保持オプションをサポートしていない呼び出し元のエージェントは、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）で使用される）のCCBSおよび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では、CCがUA間で正常に動作するためにCCをサポートする必要があるのは、発信側の発信者のUAまたはサービスシステムと着信側の着信者のUAまたはサービスシステムのみです。中間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要求、または既存の着信CCサブスクリプションを表す、CCエンティティ（「CCE」と呼ばれる）の動的セットを管理します。このセットはキューとも呼ばれます。これは、キューデータ構造が、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は、その作成を引き起こしたSUBSCRIBE要求の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).
呼び出し先のモニターがPUBLISH要求[RFC3903]を介してプレゼンス情報データフォーマット（PIDF）本体[RFC3863]を受信すると、これらのPUBLISH要求はサブスクライバーから送信され、CCE可用性の状態を変更することにより、CC要求を間接的に一時停止および再開します。 CCEは、要求URI（CCEを識別するCCイベント通知から取得された場合）または要求の送信元URI（CCEに記録されている送信元URIと一致）によって識別されます。ステータスが "open"のPUBLISHを受信すると、CCEの可用性状態が "available"（再開）に設定されます。 status "closed"は、CCEの可用性状態を "unavailable"（一時停止）に設定します。
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リクエストをリコールのために選択してはなりません（MUST NOT）。その制約内で、呼び出し先のモニターによる選択は、そのローカルポリシーによって決定されます。多くの場合、呼び出し先のモニターは、キューに最も長く入れられている受け入れ可能な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.
次に、選択したサブスクライバーがプレゼンス状態が "closed"のPUBLISHを送信して要求を中断すると、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 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のアクティブ化の場合、呼び出し元のエージェントは、すべての既知の呼び出し先のモニターURIにSUBSCRIBEを送信する必要があります。呼び出し先のモニターURIは、呼び出し先のモニターによって送り返されたINVITEへの暫定応答と最終応答のCall-Infoヘッダーフィールドで提供されます。さらに、発信者のエージェントは、元のINVITEを送信した元のリクエストURIを着信者の監視URIのセットに含める必要があります（発信者が応答を確認していない他の着信者にコールが分岐したかどうかが不明な場合）。元のリクエストURIへのSUBSCRIBEのみが、呼び出し元のエージェントが呼び出し先のモニターURIを受信していない、または覚えていない場合に使用されます。呼び出し元のエージェントは、呼び出し先のモニターに目的のCCモードを示すために、これらのURIに「m」パラメーターを追加する必要があります（SHOULD）。 「m」パラメータは、元のINVITEへの応答のCall-Infoヘッダーフィールドで受信した「m」パラメータの値を持つ必要があります（SHOULD）。
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.
冗長なサブスクリプションを最小限に抑えるために、これらのSUBSCRIBEは、[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.
エージェントは、単一の発信者に対して単一の元の宛先URIに向けられた複数のCC要求を維持してはなりません（MUST NOT）。発信者が同じ宛先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.
これらのSUBSCRIBEを生成する場合、From URIは呼び出し元のAORでなければなりません。 To URIは元の呼び出しの宛先URIである必要があり（エージェントがそれを知っていて、それをToヘッダーに挿入できる場合）、それ以外の場合はSUBSCRIBEの要求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.
SUBSCRIBEには、ルーティングを最適化するためのヘッダーフィールドが必要です（SHOULD）。特に、「Request-Disposition：parallel」とAccept-Contactヘッダーフィールドを含めて、呼び出し元に受け入れられない呼び出し先UAを排除する必要があります（SHOULD）。
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.
呼び出し元のエージェントは、SUBSCRIBEの複数のフォークに対する複数の応答を受信し、複数のサブスクリプションを確立できるように準備する必要があります。発信者のエージェントは、SUBSCRIBEが失敗するように準備する必要もあります。この場合、この元の呼び出しで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).
cc-stateが "ready"に設定されたNOTIFYを受信すると、発信者のエージェントは、6.5の手順に従って、CCへの他のすべてのサブスクリプションを一時停止して、この発信者からの他のCCリクエストがCCのリコールを受信しないようにする必要があります。発信者のエージェントは、発信者のUAを呼び出すなどして、発信者がCCコールを開始できることを確認することにより、発信者への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に、着信者に向けて新しいINVITEを生成させます。呼び出し元のUAは、CC処理で自分の設定を指定し、CC呼び出しに優先順位を付けるために、元のINVITEへの応答のCall-Infoヘッダーで受信した「m」パラメーターの値を含む「m」URIパラメーターを追加できます（MAY）。 。 INVITEは、NOTIFYのcc-URIで指定されたURIにアドレス指定する必要があります（SHOULD）。それが利用できない場合は、元のINVITEへの応答のCall-InfoヘッダーフィールドでURIを使用する必要があります。それが利用できない場合、このURIが記録されていれば、元のINVITEのリクエスト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のプレゼンスサーバーが存在する各呼び出し先のモニターにPUBLISH要求を送信することにより、発信者のプレゼンス状態を公開する必要があります（SHALL）。プレゼンティティとしての発信者のアイデンティティ。 PUBLISHリクエストには、残りのCCサブスクリプション期間の現在の値に対応する値を持つExpiresヘッダーフィールドが含まれている必要があります（SHOULD）。
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.
各PUBLISHは、NOTIFYまたは対応するSUBSCRIBEダイアログ内で受信したCC URIに送信する必要があります。それが不可能な場合は、NOTIFYのCall-Infoヘッダーフィールドで受信した対応する呼び出し先のモニター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要求は発信者のエージェントによって再開される必要があります（SHALL）。 CCリクエストを再開するには、発信者のエージェントは[RFC3903]で説明されている手順に従ってPUBLISHリクエストを各着信者のモニターに送信し、PIDF状態が「オープン」であることを各モニターに通知して、発信者のプレゼンス状態を公開する必要があります（SHALL）。それ以外の場合、この要求は、suspend PUBLISH要求と同じ方法で作成されます。
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中断要求を送信し、呼び出し元が再び利用可能になった場合、呼び出し元のエージェントのローカル再開ポリシーによって決定されるように、呼び出し元のエージェントはPUBLISHを送信してそれぞれにCC要求を再開できます（MAY）。中断された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を有効にするために486に）に「purpose = call-completion」を含むCall-Infoヘッダーフィールドを挿入する必要があります。通話中のサブスクライバー）と、発信者に転送するときの最初のINVITEに対する少なくとも1つの非100暫定応答メッセージ（たとえば、応答がないため180に）。 INVITEにオプションタグ100relのサポートされたヘッダーフィールドが含まれていた場合、非100暫定応答メッセージを確実に送信する必要があります。この仕様で定義されているCall-Infoヘッダーフィールド値は、コールの失敗したフォークに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".
呼び出し先のモニターは、呼び出し元のエージェントがCCをサブスクライブするCall-InfoヘッダーフィールドにURIを挿入する必要があります（SHOULD）。理想的には、呼び出し先のモニターにとってグローバルにルーティング可能なURI [RFC5627]です。実際には、呼び出し先のAORである可能性があり、SUBSCRIBEは「イベント：呼び出し完了」を指定しているためにのみ呼び出し先のモニターにルーティングされます。
In order to enable CC, the Call-Info header field MUST be set up according to the following scheme:
CCを有効にするには、次のスキームに従ってCall-Infoヘッダーフィールドを設定する必要があります。
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ヘッダーフィールドで提供するすべてのURIに向けられた呼び出し完了イベントパッケージのSUBSCRIBEを受信できるように準備する必要があります。 SUBSCRIBEは、[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.
モニターが同じCall-Idヘッダーフィールド値を持つ2つ以上のSUBSCRIBEを受信し、モニターが受信したSUBSCRIBEのリクエストURIを同じUAのセットのステータスを要求すると見なす場合、それらは1つのSUBSCRIBEリクエストの冗長なフォークです。 、およびモニターは、482（マージされた要求）応答を持つ1つを除くすべての要求を拒否する必要があります。
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）Call-Idヘッダーフィールドの値が異なる、（2）From URI（つまり、呼び出し元のAOR）が同じである場合、着信CC SUBSCRIBEが既存のCCサブスクリプションの複製であることを決定できます（つまり、[ RFC3261]セクション19.1.4）、（3）To URI（元の呼び出しのリクエストURIである必要があります）は同じユーザーコンポーネントとホストポートコンポーネントを持ち、（4）モニターは受信したSUBSCRIBEのリクエストURIを考慮します同じUAのセットのステータスをリクエストします。
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]で定義されている手順に従って、既存のサブスクリプションを終了してもよい（MAY）。いずれの場合も、新しいサブスクリプションを確立する必要があります。
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]に従ってサブスクリプションを終了する必要があります（SHOULD）。
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-stateが変更された場合、呼び出し先のモニターは、CCイベントのNOTIFYを呼び出し元のエージェントに送信する必要があります。通知には、一時停止要求に使用できるURIも含まれる必要があります（SHOULD）。理想的には、呼び出し先のモニターにとってグローバルにルーティング可能なURI [RFC5627]です。実際には、呼び出し先のAORである可能性があり、SUBSCRIBEは「イベント：呼び出し完了」を指定しているためにのみ呼び出し先のモニターにルーティングされます。
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」データは、「サービス保持」属性を示します。これは、呼び出し先の理由によりCC呼び出しが失敗した場合に、CC要求を後で続行できるかどうかを示します。 UAがビジーです。呼び出し先のモニターがservice-retentionオプションをサポートする場合、呼び出し先のモニターはcc-service-retentionパラメーターを含める必要があります（SHOULD）。
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とCCBSなど）、呼び出し先のUAの状態、CC要求が到着した順序、CC要求がアクティブであった時間の長さ、および同じ元のコールに対する以前のCCアクティベーションの試行。呼び出し先のモニターは、通常、一度に1つのリコールに対して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-stateが「ready」に設定された呼び出し元のエージェントのサブスクリプションに通知を送信する必要があります（リコール通知）。 NOTIFY SHOULDには、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と呼び出し先のモニターは、「m」URIパラメーターとINVITEリクエストのFromヘッダーの存在を評価することにより、CC以外の呼び出しよりもCC呼び出しを優先する場合があります。呼び出し先のモニターは、CC呼び出しの受信を監視します。 CCコールの到着時に、再呼び出しタイマーを停止する必要があります。再呼び出しタイマーの期限が切れる前にCC呼び出しが呼び出し先のUAに到着しない場合、呼び出し先のモニターは、再呼び出しの処理を停止し、保持オプションをサポートしている場合はcc-stateデータの値を「queued」に変更する必要があります（SHOULD）。 、保持オプションをサポートしていない場合はサブスクリプションを終了します。同様に、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リクエストを一時停止するPUBLISHリクエストを受信する場合があります。 PUBLISHリクエストは、管理するURI、Call-Infoヘッダーに挿入するURI、「call-completion」イベントの通知機能として使用する連絡先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.
PUBLISH要求を受信すると、[RFC3903]で指定されているように、呼び出し先のモニターのプレゼンスサーバーで呼び出し元のIDのプレゼンスイベント状態が開始されます。
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.
注：プレゼンスサーバーは、実装によっては、SUBSCRIBEリクエストの受信時に発信者のIDのプレゼンスイベント状態を開始する場合もあります。
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.
モニターは、PUBLISH要求のrequest-URIによって、またはそれが不可能な場合はFrom URIによって、アドレス指定されたCCEを識別する必要があります（SHOULD）。
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要求の処理の結果、呼び出し元のエージェントからPUBLISH要求を受信することによってその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で説明されているように、呼び出し先のモニターが呼び出し元のエージェントからPUBLISH要求を受信した後でCC要求が再開された場合、CCモニターのプレゼンスサーバーでの呼び出し元のIDのプレゼンスイベント状態は、[RFC3903で説明されているように変更する必要があります。 ]。呼び出し先がビジーではなく、現在処理中の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 |
|<-------------------------|
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.
元のコールは通常のINVITEです。応答がないために失敗します（ring-no-answer）。この場合、プロキシがUAへのINVITEを呼び出したが、応答がなかったために長すぎたため、呼び出し先の管理プロキシが487応答を生成しました。 487応答には、「purpose = call-completion」を含むCall-Infoヘッダーフィールドが含まれています。 Call-Infoヘッダーフィールドは、コールのこの失敗したフォークに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".
Call-Infoヘッダーフィールド（<sip：456@z.b.com>）のURIは、発信者のエージェントがCC処理をサブスクライブする場所です。理想的には、呼び出し先のモニターのためにグローバルにルーティング可能なURIです。実際には、呼び出し先のAORである可能性があり、SUBSCRIBEは「イベント：呼び出し完了」を指定しているためにのみ呼び出し先のモニターにルーティングされます。
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にSUBSCRIBEを送信することによってアクティブ化されます。これらは、INVITEへの応答のCall-Infoヘッダーフィールドで提供できます。
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へのSUBSCRIBEのみが、呼び出し元のエージェントが呼び出し先のモニター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で定義されているように、適切なRequest-Dispositionで2つの宛先にSUBSCRIBEをフォークします。最初のSUBSCRIBEは、Call-Infoからの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.
2番目のSUBSCRIBEは元の要求URIに対するもので、同じ呼び出し先のモニターに到達します。呼び出し先のモニターにすでに到達しているSUBSCRIBEと同じCall-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.
成功したSUBSCRIBEの最初のNOTIFYには、本文に「cc-state：queued」が含まれています。最終的に、この呼び出し元はCCに対して選択され、 "cc-state：ready"を含むNOTIFYを介して通知されます。このNOTIFYは、CC呼び出しのINVITEの送信先となる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.
呼び出し元は、NOTIFYで指定されたURIへの新しいINVITEを生成します。そのようなURIがなかった場合、または呼び出し元のエージェントがそれを覚えていない場合は、元の要求URIを使用できます。呼び出し元は、CC処理を指定するために（可能な場合）「m」パラメーターを追加します。
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 |
|<-------------------------|
| |
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-state：ready"を含むNOTIFYリクエストを介して通知されます。現時点では、発信者は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.
呼び出し先のプレゼンスサーバーでプレゼンスイベントの状態を更新するために、呼び出し元はPUBLISH要求を送信して、プレゼンスサーバーにPIDF状態が「クローズ」であることを通知します。 PUBLISH要求は、（優先順に）次のように送信されます。（1）NOTIFYで受信されたCC URIへのダイアログ外、（2）対応するSUBSCRIBEダイアログ内、（3）へのダイアログ外NOTIFYのCall-Infoヘッダーフィールドで受信した対応する呼び出し先のモニターURI、または（4）対応する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状態が「開いている」ことをサーバーに通知するPUBLISH要求を生成することにより、呼び出し先のプレゼンスサーバーでプレゼンスイベントの状態を更新します。それ以外の場合、この要求は、suspend PUBLISH要求と同じ方法で作成されます。
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に従って、通話完了イベントパッケージを指定します。 call-completionイベントパッケージのメディアタイプは「application / call-completion」です。
Note that if the callee has a caller-queuing facility, the callee's monitor may want to treat the CC queue as part of the queuing facility and include in the event package information regarding the state of the queue. How this information is conveyed is left for further standardization.
呼び出し先に呼び出し元キューイング機能がある場合、呼び出し先のモニターは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]には、パッケージまたはテンプレートパッケージの名前を指定するパッケージ定義が必要です。このパッケージの名前は「call-completion」です。この値は、EventおよびAllow-Eventsヘッダーフィールドに表示されます。
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]は、SUBSCRIBEリクエストでのボディの使用法を定義するためのパッケージ定義を必要とします。
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".
SUBSCRIBEリクエストにはAcceptヘッダーフィールドが含まれる場合があります。そのようなヘッダーフィールドが存在しない場合、デフォルト値は「application / call-completion」になります。ヘッダーフィールドが存在する場合は、「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パッケージのSUBSCRIBEリクエストにはボディが含まれる場合があります。この本体は、サブスクリプションに適用されるフィルターを定義します。フィルタードキュメントはこのドキュメントでは指定されておらず、将来の標準化活動の対象となる可能性があります。
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ヘッダーフィールド値のURI部分がSUBSCRIBEのFromヘッダーフィールド値の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.
SUBSCRIBEが期間を明示的に要求しない場合、デフォルトの要求期間は3600秒です。これは、ETSI [ETS300.356-18]およびITU-T [ITU-TQ]のCCサービスに推奨される最大のサービス期間タイマー値であるためです。 733]ドキュメント。サブスクリプション期間は明示的なタイマーが不要であることを意味し、サブスクリプション期間は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.
通知機能は、そのポリシーに従って、要求されたサブスクリプションが一定期間後に「準備完了」状態に進むことができないと判断できる場合、付与されたサブスクリプション時間をその期間に短縮する必要があります（SHOULD）。通知機能が、ポリシーに従って、要求されたサブスクリプションが「準備完了」状態に進むことができないと判断できる場合、サブスクリプションを拒否する必要があります。
[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リクエストで許可される本文タイプのセットを記述し、SUBSCRIBEリクエストにAcceptヘッダーフィールドがない場合に使用されるデフォルト値を指定するパッケージ定義が必要です。コール完了イベントパッケージのNOTIFYには、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メッセージには、サブスクライブされたリソースの状態を説明する本文が含まれます。この本文は、SUBSCRIBEのAcceptヘッダーフィールドにリストされている形式、またはAcceptヘッダーフィールドがSUBSCRIBEから省略されている場合はパッケージ固有のデフォルト形式です。
In this event package, the body of the notification contains a CC document. All subscribers and notifiers MUST support the "application/call-completion" data format described in Section 10. The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/call-completion". If the header field is present, it MUST include "application/call-completion". Of course, the notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request.
このイベントパッケージでは、通知の本文にCCドキュメントが含まれています。すべてのサブスクライバーと通知機能は、セクション10で説明されている「application / call-completion」データ形式をサポートする必要があります。SUBSCRIBEリクエストには、Acceptヘッダーフィールドを含めることができます（MAY）。そのようなヘッダーフィールドが存在しない場合、デフォルト値は「application / call-completion」になります。ヘッダーフィールドが存在する場合は、「application / call-completion」を含める必要があります。もちろん、サーバーによって生成された通知は、SUBSCRIBEリクエストのAcceptヘッダーフィールドで指定されたフォーマットの1つである必要があります。
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通知を受信するために、着信側で呼び出し完了イベントパッケージをサブスクライブするときにSUBSCRIBE要求を生成する必要があります。 SUBSCRIBE要求の生成は、セクション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 Temporarily Unavailable応答を送信する必要があります（おそらく通知機能の再試行後のパラメーターを使用）。ポリシー。 CCサービスを防止し、引き続き防止する条件が発生したためにサブスクリプションが成功しない場合、通知機能はサブスクライバーに403 Forbidden応答を送信する必要があります。
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で定義されているように、通知機能は同じSUBSCRIBEの複数のフォークを受信する場合があります。そのような場合、他の何らかの失敗応答が適用されない限り、通知機能は482 Merged Request応答で1つを除くすべてのSUBSCRIBEを拒否する必要があります。
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.
CC情報は機密である可能性があります。したがって、すべてのサブスクリプションは、特にサブスクライバーのIDを検証するために、セクション11で説明されているセキュリティの考慮事項を考慮して処理する必要があります（SHOULD）。
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リクエストを生成する必要があります。ゼロ以外の有効期限で送信される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.
有効期限がゼロで送信されたNOTIFY（たとえば、退会要求の確認として）には、「cc-state」パラメータが含まれている場合があります。
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再呼び出しINVITEを開始していないため、またはエージェントが要求をCC再呼び出しの対象から除外しているため） 、通知機能は、選択されたリクエストのサブスクリプションにNOTIFYを送信する必要があります。このNOTIFYには、「キューに追加」に設定された「cc-state」パラメータが含まれている必要があります。
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サブスクリプションが成功し、retainオプションが呼び出し先でサポートされている場合、NOTIFYには「cc-service-retention」パラメーターが含まれている必要があります。
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-stateが "ready"に設定されたNOTIFY要求を受信すると、サブスクライバーは、他の通知機能で元の呼び出しに対する他のすべてのCCサブスクリプションを中断する必要があります（SHOULD）。サブスクライバーによってcc-stateが "ready"に設定された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イベントタイプでは一般的であると予想されます。加入者は、複数の通知者からのNOTIFY要求を処理し、このドキュメントの手順に従ってそれらから取得した情報の処理を調整する準備をしなければなりません。
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サービスは通常、「Ready」（CCの場合）への変更に関する通知者およびサブスクリプションごとに1つの通知を含みますが、「Ready」状態への変更に関するいくつかの通知を伴う場合があります。忙しい相手。通常、通知は少なくとも数十秒の間隔があります。 Notifierは、10秒間隔で1つのサブスクリプションに対して4つ以上の通知を生成してはなりません（SHOULD NOT）。無駄なリコールを避けることが重要であるため、通知機能は状態の変更を「準備完了」から「キュー」に迅速に送信する必要があります（SHOULD）。したがって、通知機能は、10秒間隔で3番目の通知として「準備完了」に状態変更を送信しないでください。これにより、「キュー」にさらに状態変更を迅速に送信することができなくなります。
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.
次の構文仕様では、[RFC5234]で説明されているようにAugmented Backus-Naur Form（ABNF）を使用しています。 application / call-completion MIMEタイプの正式な構文を以下に示します。一般に、CCボディはSIPヘッダーと同じように解釈されます：（1）行の名前では大文字と小文字が区別されません、（2）後続の行が水平方向の白で始まる場合、行の境界を越えて継続できますスペース、および（3）不明な名前の行は無視されます。このドキュメントで定義されているヘッダー行は、任意のCC情報フォーマットドキュメントで最大1回発生する可能性があります。
call-completion = 1*(cc-header CRLF)
cc-header = cc-state / cc-service-retention / cc-URI /
extension-header
The above rules whose names start with "cc-" are described below. Other rules are described in [RFC3261].
名前が「cc-」で始まる上記のルールを以下に説明します。他のルールは[RFC3261]で説明されています。
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ステータスを示します。 NOTIFYに示されている有効期限がゼロでない限り、存在する必要があります。
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.
サービス保持行は、保持オプションのサポートを示します。呼び出し先でサポートされている場合、retainオプションは、呼び出し先のビジー状態が原因でCC呼び出しが失敗した場合に、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行は、エージェントがCCリコールINVITEおよび中断/再開PUBLISHのリクエストURIとして使用する必要があるURIを提供します。すべてのNOTIFYで提供する必要があります。 URIはグローバルにルーティング可能であり、問題のCCEを一意に識別する必要があります（SHOULD）。構文は値にgeneric-paramsを提供しますが、このドキュメントではそのようなパラメーターを定義していません。サブスクライバーが理解できないパラメーターは、URIとともに保持する必要があります。
cc-URI = "cc-URI" HCOLON addr-spec
cc-URI = "cc-URI" HCOLON addr-spec
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 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サブスクリプションを確立することを許可されるべきではありません。プライバシーに特に注意を払う発信者は、すべてのCCサブスクリプションを拒否する場合があります。ただし、通常のケースでは、最適な保護は、すべての発信者がサブスクライブすることを許可しますが、長すぎる、または頻繁にサブスクライブしないようにするか、またはサブスクリプションが（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のサブスクライバーが選択された場合、呼び出しは呼び出し先に迅速に到着するか、サブスクリプションが終了する必要があります。この予想は、CCのサブスクリプションの選択と呼び出し元が利用できなくなる間の競合状態によって違反される可能性がありますが、1つのサブスクリプションが競合状態を複数回示すことはまれです。
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ファシリティは、次のテクニックを介してSpam over Internet Telephony（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.
SUBSCRIBEリクエストとPUBLISHリクエストの送信者がサービス拒否（DoS）攻撃を引き起こし、それ以外のCCエントリを一時停止しないようにするには、元の呼び出し元のIDとSUBSCRIBEリクエストとPUBLISHリクエストの送信者を関連付けるメカニズムが必要です。 。 CCに関連する要求の発信者のIDを認証するための推奨メカニズムは、SIP IDメカニズム[RFC4474]です。あるいは、管理ドメインまたはドメインのフェデレーション内のCCエージェントとモニターは、[RFC3325]で説明されているメカニズムを使用して、P-Asserted-IdentityヘッダーフィールドでIDを認証できます。
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.
さらに、プレゼンスサーバーを一時停止または再開するための使用は、呼び出し先のモニターにアクティブなキューを持つ呼び出し元に限定する必要があります（SHOULD）。これは、最初に着信側とCC通知が送信された宛先への着信コールを監視してログに記録することで実現できます。次に、最初のコールが失敗した後の短い時間枠内でのみ、コール完了イベントパッケージへのサブスクリプションが許可されるようにします。問題の発信者のアクティブなキューがある場合にのみ、プレゼンスサーバーへのPUBLISH要求を受け入れます。
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
パッケージ名：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サブタイプ名：call-completion
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]によって作成されたレジストリに従って、1つの新しい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ヘッダーフィールドの「purpose」ヘッダーフィールドパラメータに、新しい事前定義値「call-completion」が追加されています。これにより、このRFCをヘッダーフィールド "Call-Info"およびパラメーター名 'purpose'の行への参照として追加することにより、レジストリヘッダーフィールドのパラメーターとパラメーター値が変更されます。
Header field: Call-Info
ヘッダーフィールド：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]を拡張して、新しいヘッダーフィールドパラメーター 'm'をCall-Infoヘッダーフィールドに追加します。これにより、レジストリヘッダーフィールドのパラメーターとパラメーター値に行が追加されます。
Header field: Call-Info
ヘッダーフィールド：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 Luebbers、Christer Holmbergに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[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：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「Session Initiation Protocol（SIP）Refer Method」、RFC 3515、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]菅野博、藤本進、クライン、G、ベイトマン、A、カー、W、J。ピーターソン、「プレゼンス情報データフォーマット（PIDF）」、RFC 3863、2004年8月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903] Niemi、A。、「Session State Initiation Protocol（SIP）Extension for Event State Publication」、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.、「インターネット開始番号認証局（IANA）セッション開始プロトコル（SIP）のURI（Uniform Resource Identifier）パラメータレジストリ」、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）のINVITEで開始されるダイアログイベントパッケージ」、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、「Enhancements for Authenticated Identity Management in the Session Initiation Protocol（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、「Session Initiation Protocol（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。、「Session Initiation Protocol（SIP）でグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得して使用する」、RFC 5627、2009年10月。
[RFC6665] Roach, A.B., "SIP-Specific Event Notification", RFC 6665, July 2012.
[RFC6665] Roach、A.B。、「SIP固有のイベント通知」、RFC 6665、2012年7月。
[ETS300.356-18] European Telecommunications Standards Institute, "Completion of Calls to Busy Subscriber (CCBS) supplementary service", February 1995.
[ETS300.356-18] European Telecommunications Standards Institute、「Completion of Calls to Busy Subscriber（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]国際電気通信連合、「SS No. 7を使用した通話完了補足サービスの説明」、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、「Trusted Networks内のAsserted IdentityのためのSession Initiation Protocol（SIP）のプライベート拡張」、RFC 3325、2002年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、「Session Initiation Protocol（SIP）でのサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725 、2004年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、「Session Initiation Protocol Service Examples」、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.
このセクションでは、自律的な発信者のエージェントが、発信者のUAと対話するために標準のSIP機能のみを使用してどのように動作できるかについて概説します。この例は、パフォーマンスが低いため、学習補助としてのみ適しています。
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またはそのプロキシは、2つの特別なダイヤルシーケンスのいずれかで行われたコールをエージェントにルーティングします。エージェントは、UAによって行われた最新のコールに対して、BSまたはNRまたはNLモードでCC要求を行うための指示としてINVITEを解釈します。
The agent monitors the status of the UA(s) for availability to be used for a CC call by examining the dialog events.
エージェントは、ダイアログイベントを調べることにより、CCコールに使用される可用性のUAのステータスを監視します。
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を呼び出すことにより、CCリコールが進行中であることをUAに示します。 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への呼び出しを監視します。これにより、Call-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に向けられた呼び出し完了イベントパッケージのSUBSCRIBEを呼び出し先のモニターにルーティングします。
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はビジー状態ではない場合のCCBSですが、確立されたコールでビジー状態になった後でビジー状態にならない場合、CCNRにUAを使用できます。
Authors' Addresses
著者のアドレス
Dale R. Worley Ariadne Internet Services, Inc. 738 Main St. Waltham, MA 02451 US
Dale R. Worley Ariadne Internet Services、Inc. 738 Main St. Waltham、MA 02451 US
Phone: +1 781 647 9199
EMail: worley@ariadne.com
Martin Huelsemann Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany
Martin Huelsemann Deutsche Telekom Heinrich-Hertz-Strasse 3-7ダルムシュタット64307ドイツ
Phone: +4961515812765
EMail: martin.huelsemann@telekom.de
URI: http://www.telekom.de
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany
Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7ダルムシュタットドイツ
Phone: +4961515812766
EMail: r.jesske@telekom.de
URI: http://www.telekom.de
Denis Alexeitsev TeleFLASH Mainzer Landstrasse 47 Frankfurt 60329 Germany
Denis Alexeitsev TeleFLASH Mainzer Landstrasse 47フランクフルト60329ドイツ
Phone: +49-69-257-378-230
EMail: alexeitsev@teleflash.com
URI: http://www.teleflash.com