Internet Engineering Task Force (IETF) K. Rehor, Ed.
Request for Comments: 6341 Cisco Systems
Category: Informational L. Portman, Ed.
ISSN: 2070-1721 NICE Systems
A. Hutton
Siemens Enterprise Communications
R. Jain
IPC Systems
August 2011
Use Cases and Requirements for SIP-Based Media Recording (SIPREC)
SIPベースのメディア記録するためのケースと要件を使用します（SIPREC）
Abstract
抽象
Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.
セッション記録は、コールセンターや金融取引フロアなど、多くのビジネス通信環境では重要な要件です。これらの環境の一部では、すべての呼び出しは、規制やコンプライアンス上の理由のために記録しなければなりません。他では、呼び出しは、品質管理やビジネス分析のために記録することができます。
Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording.
記録は通常、記録装置へのセッションのメディアのコピーを送信することにより行われます。この文書では、記録装置にRTPメディアの配信を管理しますSIPへの拡張のための要件を指定します。これは、SIPベースのメディア記録と呼ばれています。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6341.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6341で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
2. Requirements Notation ...........................................4
3. Definitions .....................................................4
4. Use Cases .......................................................5
5. Requirements ...................................................10
6. Privacy Considerations .........................................13
7. Security Considerations ........................................14
8. Acknowledgements ...............................................15
9. Normative References ...........................................15
Session recording is a critical operational requirement in many businesses, especially where voice is used as a medium for commerce and customer support. A prime example where voice is used for trade is the financial industry. The call recording requirements in this industry are quite stringent. The recorded calls are used for dispute resolution and compliance. Other businesses, such as customer support call centers, typically employ call recording for quality control or business analytics, with different requirements.
セッション記録は、音声が商取引や顧客サポートのための媒体として使用され、特に場合は、多くの企業で重要な業務要件です。音声は、貿易のために使用されている典型的な例は、金融業界です。この業界での通話録音の要件は非常に厳しいです。記録されたコールは、紛争解決やコンプライアンスのために使用されています。そのような顧客サポートコールセンターなどの他の企業は、一般的に異なる要件で、品質管理やビジネス分析のための通話録音を採用しています。
Depending on the country and its regulatory requirements, financial trading floors typically must record all calls. In contrast, call centers typically only record a subset of the calls, and calls must not fail, regardless of the availability of the recording device.
国とその規制の要件に応じて、金融取引フロアは、一般的にすべてのコールを記録しなければなりません。これとは対照的に、関係なく、記録装置の可用性の、コールセンターは、一般的に呼び出しのみのサブセットを記録し、呼び出しは失敗してはいけません。
Respecting the privacy rights and wishes of users engaged in a call is of paramount importance. In many jurisdictions, participants have a right to know that the session is being recorded or might be recorded, and they have a right to opt out, either by terminating the call or by demanding that the call not be recorded. Therefore, this document contains requirements for being able to notify users that a call is being recorded and for users to be able to request that a call not be recorded. Use cases where users participating in a call are not informed that the call is or might be recorded are outside the scope of this document. In particular, lawful intercept is outside the scope of this document.
コールに従事し、ユーザーのプライバシーの権利と願いを尊重することは極めて重要です。多くの国では、参加者はセッションが記録されているか、記録される可能性があることを知る権利を持っている、と彼らは、通話を終了するか、呼び出しが記録されていないことを要求のいずれかによって、オプトアウトする権利を有します。したがって、このドキュメントは、通話が録音されていることをユーザーに通知することが可能であるために、ユーザはコールが記録されないように要求することができるようにするための要件が含まれています。コールに参加しているユーザは、コールがあるか、この文書の範囲外で記録される可能性があることを知らされていない場合に使用します。具体的には、合法的傍受は、この文書の範囲外です。
Furthermore, a one-size-fits-all model will not fit all markets where the scale and cost burdens vary widely and where needs differ for such solution capabilities as media injection, transcoding, and security. If a standardized solution supports all of the requirements from every recording market but doing so would be expensive for markets with lesser needs, then proprietary solutions for those markets will continue to propagate. Care must be taken, therefore, to make a standards-based solution support optionality and flexibility.
さらに、ワンサイズ全てのモデルは、規模やコスト負担が大きく異なるとニーズがメディア注入、トランスコーディング、およびセキュリティなどのソリューション機能のために異なる場合、すべての市場に適合しません。標準化されたソリューションは、すべての記録、市場からの要求のすべてをサポートしていますが、そうすることが、より少ないニーズと市場のために高価である場合には、これらの市場のための独自のソリューションが伝播していきます。ケアは、標準ベースのソリューション・サポート・選択性と柔軟性を作るために、そのため、注意する必要があります。
This document specifies requirements for using SIP [RFC3261] between a Session Recording Client and a Session Recording Server to control the recording of media that has been transmitted in the context of a Communication Session. A Communication Session is the "call" between participants. The Session Recording Client is the source of the recorded media. The Session Recording Server is the sink of recorded media. It should be noted that the requirements for the protocol between a Session Recording Server and Session Recording Client have very similar requirements (such as codec and transport negotiation, encryption key interchange, and firewall traversal) as compared to regular SIP media sessions. The choice of SIP for session recording provides reuse of an existing protocol.
この文書では、通信セッションのコンテキストで送信されたメディアの記録を制御するために、セッションの記録クライアントとセッションの録画サーバーの間でSIP [RFC3261]を使用するための要件を指定します。通信セッションは、参加者の間で「呼び出し」です。セッションの録画クライアントが記録されたメディアのソースです。セッションの録画サーバーは、記録されたメディアのシンクです。セッションの録画サーバーとセッション録音クライアント間のプロトコルのための要件は、通常のSIPメディアセッションと比較して（例えばコーデックや輸送のネゴシエーション、暗号鍵の交換、およびファイアウォールトラバーサルなど）非常に同様の要件を持っていることに留意すべきです。セッション記録のためのSIPの選択は、既存のプロトコルの再利用を提供します。
The recorded sessions can be any RTP media sessions, including voice, dual-tone multifrequency (DTMF) (as defined by [RFC4733]), video, and text (as defined by [RFC4103]).
記録されたセッションは、音声、デュアルトーン多重周波数（DTMF）（[RFC4733]で定義されるように）、ビデオ、及び（[RFC4103]で定義されるように）テキストを含む任意のRTPメディアセッションとすることができます。
An archived session recording is typically comprised of the Communication Session media content and the Communication Session Metadata. The Communication Session Metadata allows recording archives to be searched and filtered at a later time and allows a session to be played back in a meaningful way, e.g., with correct synchronization between the media. The Communication Session Metadata needs to be conveyed from the Session Recording Client to the Session Recording Server.
アーカイブセッションの記録は通常、通信セッションのメディアコンテンツと通信セッション・メタデータで構成されています。通信セッション・メタデータが記録アーカイブが後で検索およびフィルタリングすることを可能にするとメディアの間の正しい同期で、例えば、有意義な方法で再生するセッションを可能にします。通信セッション・メタデータは、セッションレコーディングサーバーへのセッション録音クライアントから搬送する必要があります。
This document only considers active recording, where the Session Recording Client purposefully streams media to a Session Recording Server. Passive recording, where a recording device detects media directly from the network, is outside the scope of this document.
この文書では、唯一のセッション録音クライアントが意図的にセッションの録画サーバーにメディアをストリームアクティブな記録を、と考えています。記録装置はネットワークから直接メディアを検出する受動的記録は、この文書の範囲外です。
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] and indicate requirement levels for compliant mechanisms.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載のコンプライアント機構の要求レベルを示すものと解釈されます。
Session Recording Server (SRS): A Session Recording Server (SRS) is a SIP User Agent (UA) that is a specialized media server or collector that acts as the sink of the recorded media. An SRS is typically implemented as a multi-port device that is capable of receiving media from multiple sources simultaneously. An SRS is the sink of the recorded session metadata.
セッション記録サーバ（SRS）：セッション記録サーバー（SRS）は、記録媒体のシンクとして機能する特殊なメディアサーバまたはコレクタであるSIPユーザエージェント（UA）です。 SRSは、典型的には、同時に複数のソースからのメディアを受信することができるマルチポートデバイスとして実装されます。 SRSは、記録されたセッションのメタデータのシンクです。
Session Recording Client (SRC): A Session Recording Client (SRC) is a SIP User Agent (UA) that acts as the source of the recorded media, sending it to the SRS. An SRC is a logical function. Its capabilities may be implemented across one or more physical devices. In practice, an SRC could be a personal device (such as a SIP phone), a SIP Media Gateway (MG), a Session Border Controller (SBC), or a SIP Media Server (MS) integrated with an Application Server (AS). This specification defines the term "SRC" such that all such SIP entities can be generically addressed under one definition. The SRC provides metadata to the SRS.
セッション記録クライアント（SRC）：セッション記録クライアント（SRC）は、SRSに送信、記録媒体の供給源として作用するSIPユーザエージェント（UA）です。 SRCは、論理的な機能です。その機能は、1つまたは複数の物理デバイスにわたって実施することができます。実際には、SRCは、（例えばSIPフォンなど）の個人装置でもよいアプリケーションサーバ（AS）と統合SIPメディアゲートウェイ（MG）、セッションボーダーコントローラー（SBC）、またはSIPメディアサーバ（MS） 。この仕様書は、そのようなすべてのSIPエンティティは、一般的に一つの定義の下で対処することができるような用語「SRC」を定義します。 SRCは、SRSにメタデータを提供します。
Communication Session (CS): A session created between two or more SIP User Agents (UAs) that is the subject of recording.
通信セッション（CS）：二つ以上のSIPユーザエージェント（UAS）との間で作成されたセッション記録の対象です。
Recording Session (RS): The SIP session created between an SRC and SRS for the purpose of recording a Communication Session.
レコーディングセッション（RS）：通信セッションを記録する目的のためにSRCとSRSの間で作成されたSIPセッション。
Figure 1 pictorially represents the relationship between a Recording Session and Communication Session.
図1は、絵の記録セッションとの通信セッションとの関係を示します。
+-------------+ +-----------+
| | Communication Session | |
| A |<------------------------------------>| B |
| | | |
+-------------+ +-----------+
..................................................................
. Session .
. Recording .
. Client .
..................................................................
|
| Recording
| Session
|
v
+------------+
| Session |
| Recording |
| Server |
+------------+
Figure 1
図1
Metadata: Information that describes recorded media and the CS to which they relate.
メタデータ：記録されたメディアとは、関連するCSを記述する情報。
Pause and Resume during a Communication Session: Pause: The action of temporarily discontinuing the transmission and collection of RS media. Resume: The action of recommencing the transmission and collection of RS media.
通信セッション中に一時停止と再開：一時停止：一時的にRSメディアの送信と収集を中止する作用を。再開：RSメディアの送信と収集を再開するのアクションを。
Most security-related terms in this document are to be understood in the sense defined in [RFC4949]; such terms include, but are not limited to, "authentication", "confidentiality", "encryption", "identity", and "integrity".
この文書に記載されているほとんどのセキュリティ関連の用語は[RFC4949]で定義された意味で理解されるべきです。このような用語には、それだけ、「認証」、「機密性」、「暗号化」、「アイデンティティ」、および「整合性」に限定されるものではありません。
Use Case 1: Full-time Recording: One Recording Session for each Communication Session.
ユースケース1：フルタイム録音：各通信セッションのための一つの記録セッション。
For example, the diagram below shows the life cycle of Communication Sessions (CSs) and the relationship to the Recording Sessions (RS).
例えば、以下の図は、記録セッション（RS）への通信セッション（CSS）のライフサイクルとの関係を示しています。
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---|
t--->
Figure 2
図2
Record every CS for each specific extension/person.
各特定の拡張子/人ごとにCSを記録します。
The need to record all calls is typically due to business process purposes (such as transaction confirmation or dispute resolution) or to ensure compliance with governmental regulations. Applications include enterprise, contact center, and financial trading floors.
すべてのコールを記録する必要性は、一般的に（例えば、取引の確認や紛争解決など）、ビジネス・プロセスの目的によるものであるか、政府の規制の遵守を確保します。アプリケーションは、企業、コンタクトセンター、および金融取引フロアが含まれています。
This is also commonly known as Total Recording.
これはまた、一般的にトータルレコーディングとして知られています。
Use Case 2: Selective Recording: Start a Recording Session when a Communication Session to be recorded is established.
選択録音：記録する通信セッションが確立されたときに録音セッションを開始ケース2を使用してください。
In this example, Communication Sessions 1 and 3 are recorded but CS 2 is not.
この例では、通信セッション1および3は、記録が、CS 2ではないれています。
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1----| |--- RS 2 ---|
t--->
Figure 3
図3
Use Case 3: Start/Stop a Recording Session during a Communication Session.
ユースケース3：通信セッション中にレコーディング・セッションを開始/停止。
The Recording Session starts during a Communication Session, either manually via a user-controlled mechanism (e.g., a button on a user's phone) or automatically via an application (e.g., a contact center customer service application) or business event. A Recording Session ends either during the Communication Session or when the Communication Session ends. One or more Recording Sessions may record each Communication Session.
レコーディング・セッションは、手動ユーザ制御メカニズム（例えば、利用者の携帯電話上のボタン）を介して、または自動的にアプリケーション（例えば、コンタクトセンターの顧客サービスアプリケーション）やビジネスイベントを経由して、通信セッション中に開始されます。レコーディング・セッションは、通信セッションが終了する通信セッションの間、またはいずれかの場合に終了します。一つまたは複数のレコーディングセッションは、各通信セッションを記録することができます。
CS |------------- Communication Session -----------|
RS |---- RS 1 ----| |---- RS 2 -----|
t--->
Figure 4
図4
Use Case 4: Persistent Recording: A single Recording Session captures one or more Communication Sessions.
ユースケース4：持続録音：シングルレコーディング・セッションは、1つまたは複数の通信セッションをキャプチャします。
|--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |------------------- Recording Session ------------------|
t--->
Figure 5
図5
A Recording Session records continuously without interruption. Periods when there is no CS in progress must be reproduced upon playback (e.g., by recording silence during such periods, or by not recording such periods but marking them by means of metadata for utilization on playback, etc.). Applications include financial trading desks and emergency (first-responder) service bureaus. The length of a Persistent Recording Session is independent from the length of the actual Communication Sessions. Persistent Recording Sessions avoid issues such as media clipping that can occur due to delays in Recording Session establishment.
レコーディング・セッションは中断することなく継続的に記録します。進行中のCSが存在しない期間は、（期間沈黙を記録することによって、例えば、または等、このような期間を記録するが、再生に利用するためのメタデータを用いて、それらをマーキングしないことによって）、再生時に再生されなければなりません。アプリケーションは、金融トレーディングデスクや緊急時（ファーストレスポンダー）サービスビューローが含まれます。永続的な記録セッションの長さは、実際の通信セッションの長さから独立しています。永続的なレコーディングセッションは、このようなレコーディング・セッションの確立の遅れが原因で発生する可能性がありますメディアクリッピングなどの問題を避けます。
The connection and attributes of media in the Recording Session are not dynamically signaled for each Communication Session before it can be recorded; however, codec re-negotiation is possible.
それは記録することができます前に、レコーディング・セッションでの接続やメディアの属性を動的に各通信セッションの合図をしていません。しかし、コーデックの再ネゴシエーションが可能です。
In some cases, more than one concurrent Communication Session (on a single end-user apparatus, e.g., trading-floor turret) is mixed into one Recording Session:
いくつかのケースでは、複数の同時通信セッション（シングルエンドユーザ装置に、例えば、トレーディングフロアタレット）は、一つの記録セッションに混合されます。
|-------- CS 1 -------|
|-------- CS 2 -------|
|-------- CS 3 -------|
RS |----------- Recording Session --------------|
t--->
Figure 6
図6
Use Case 5: Real-time Recording Controls.
ユースケース5：リアルタイム録音を制御します。
For an active Recording Session, privacy or security reasons may demand not capturing a specific portion of a conversation. An example is for PCI (payment card industry) compliance where credit card information must be protected. One solution is not to record a caller speaking their credit card information.
アクティブなレコーディング・セッションについては、プライバシーやセキュリティ上の理由は、会話の特定の部分をキャプチャしない要求することができます。例では、クレジットカード情報は保護されなければならないPCI（クレジットカード業界）コンプライアンスのためのものです。一つの解決策は、自分のクレジットカード情報を話す発信者を記録することではありません。
An example of a real-time control is Pause/Resume.
リアルタイム制御の例は、一時停止/再開です。
Use Case 6: IVR / Voice Portal Recording.
ユースケース6：IVR /音声ポータルレコーディング。
Self-service Interactive Voice Response (IVR) applications may need to be recorded for application performance tuning or to meet compliance requirements.
セルフサービスの対話型音声応答（IVR）アプリケーションは、アプリケーションのパフォーマンス・チューニングのために記録する必要があるかもしれないか、コンプライアンス要件を満たすために。
Metadata about an IVR session recording must include session information and may include application context information (e.g., VoiceXML session variables, dialog names, etc.).
IVRセッション記録に関するメタデータは、セッション情報が含まれている必要があり、アプリケーションのコンテキスト情報（例えば、VoiceXMLのセッション変数、ダイアログ名、等）を含むことができます。
Use Case 7: Enterprise Mobility Recording.
ユースケース7：エンタープライズモビリティ録音。
Many agents and enterprise workers whose calls are to be recorded are not located on company premises.
その通話記録される会社の敷地内に置かれていない多くのエージェントと企業の労働者。
Examples:
例：
o Home-based agents or enterprise workers.
ホームベースのエージェントや企業の労働者O。
o Mobile phones of knowledge workers (e.g., insurance agents, brokers, or physicians) when they conduct work-related (and legally required recording) calls.
O知識労働者の携帯電話（例えば、保険代理店、ブローカー、または医師）彼らは仕事関連（および法的に必要な記録）を行って呼び出します。
Use Case 8: Geographically distributed or centralized recording.
ユースケース8：地理的に分散または集中記録。
Enterprises such as banks, insurance agencies, and retail stores may have many locations, possibly up to thousands of small sites. Frequently, only phones and network infrastructure are installed in branches, without local recording services. In cases where calls inside or between branches must be recorded, a centralized recording system in data centers together with telephony infrastructure (e.g., Private Branch Exchange (PBX)) may be deployed.
銀行、保険代理店、小売店などの企業は、おそらく小さな数千のサイトまで、多くの場所であってもよいです。多くの場合、唯一の携帯電話とネットワークインフラストラクチャは、ローカル記録サービスなしで、支店内に設置されています。 （例えば、構内交換機（PBX））一緒に電話インフラストラクチャとデータセンターに集中記録システム、内部又は分岐間のコール記録されなければならない場合には展開されてもよいです。
Use Case 9: Record complex call scenarios.
ユースケース9：レコード複雑なコールシナリオ。
The following is an example of a scenario where one call that is recorded must be associated with a related call that also must be recorded.
以下に、記録されたものコールも記録されなければならない関連するコールに関連付けられなければならないシナリオの一例です。
o A Customer is in a conversation with a Customer Service Agent.
Oお客様は、カスタマー・サービスのエージェントとの会話です。
o The Agent puts the Customer on hold in order to consult with a Supervisor.
Oエージェントがスーパーバイザに相談するために保留に顧客を置きます。
o The Agent enters into a conversation with the Supervisor.
Oエージェントがスーパーバイザとの会話に入ります。
o The Agent disconnects from the Supervisor, then reconnects with the Customer.
エージェントがスーパーバイザから切断O、そしてお客様との再接続します。
o The Supervisor call must be associated with the original Customer call.
Oスーパーバイザコールは、元のカスタマー・コールに関連付ける必要があります。
Use Case 10: High availability and continuous recording.
ユースケース10：高可用性と連続記録。
Specific deployment scenarios present different requirements for system availability, error handling, etc., including the following:
具体的な展開シナリオ以下を含むなど、システムの可用性、エラー処理、のために存在する異なる要件：
o An SRS must always be available at call setup time.
O SRSは常にコールの設定時に使用可能でなければなりません。
o No loss of media recording can occur, including during failure of an SRS.
Oメディア記録の損失は、SRSの故障時も含めて、発生しないことができます。
o The Communication Session must be terminated (or suitable notification given to parties) in the event of a recording failure.
O通信セッションが終了しなければならない（または適切な通知が相手に与えられた）記録に障害が発生した場合に。
Use Case 11: Record multi-channel, multimedia session.
ユースケース11：録音マルチチャンネル、マルチメディアセッション。
Some applications require the recording of more than one media stream, possibly of different types. Media are synchronized, either at storage or at playback.
一部のアプリケーションでは、おそらく、異なる種類の複数のメディアストリームの記録を、必要としています。メディアストレージに、または再生のいずれかで、同期されます。
Speech analytics technologies (e.g., word spotting, emotion detection, speaker identification) may require speaker-separated recordings for optimum performance.
音声分析技術（例えば、ワードスポッティング、感情検出、話者識別）が最適な性能のために話者分離録音を必要とするかもしれません。
Multi-modal contact centers may include audio, video, IM, or other interaction modalities.
マルチモーダルコンタクトセンターは、オーディオ、ビデオ、IM、または他の相互作用の様式を含むことができます。
In trading-floor environments, in order to minimize storage and recording system resources, it may be preferable to mix multiple concurrent calls (Communication Sessions) on different handsets/ speakers on the same turret into a single recording session.
取引階の環境では、ストレージおよび記録システムリソースを最小化するためには、単一の記録セッションに同じタレット上の異なる携帯電話/スピーカーで複数の同時通話（通信セッション）を混合することが好ましいかもしれません。
Use Case 12: Real-time media processing.
リアルタイムメディア処理：ケース12を使用してください。
It must be possible for an SRS to support real-time media processing, such as speech analytics of trading-floor interactions. Real-time analytics may be employed for automatic intervention (stopping interaction or alerting) if, for example, a trader is not following regulations.
SRSは、このような取引階の相互作用の音声分析など、リアルタイムのメディア処理をサポートすることが可能でなければなりません。リアルタイム分析は、例えば、トレーダーが規制に従っていない自動介入場合（相互作用を停止または警告）のために使用することができます。
Speaker separation is required in order to reliably detect who is saying specific phrases.
スピーカーの分離を確実に特定のフレーズを言っている人に検出するために必要とされます。
The following are requirements for SIP-based Media Recording:
以下は、SIPベースのメディアの録音のための要件は次のとおりです。
o REQ-001: The mechanism MUST provide a means for using the SIP protocol for establishing, maintaining, and terminating Recording Sessions between a Session Recording Client and a Session Recording Server.
O REQ-001：機構は、確立、維持、およびセッション記録クライアントおよびセッション記録サーバとの間で記録セッションを終了するためのSIPプロトコルを使用するための手段を提供しなければなりません。
o REQ-002: The mechanism MUST support the ability to record all CSs in their entirety.
REQ-002 O：メカニズムは、その全体がすべてのCSSを記録する機能をサポートしなければなりません。
o REQ-003: The mechanism MUST support the ability to record selected CSs in their entirety, according to policy.
REQ-003 O：メカニズムは、ポリシーに応じて、それらの全体が選択したCSSを記録する能力をサポートしなければなりません。
o REQ-004: The mechanism MUST support the ability to record selected parts of selected CSs.
REQ-004 O：機構が選択したCSSの選択された部分を記録する能力をサポートしなければなりません。
o REQ-005: The mechanism MUST support the ability to record a CS without loss of media of RS (for example, clipping media at the beginning of the CS) due to RS recording preparation and also without impacting the quality or timing of the CS (for example, delaying the start of the CS while preparing for a recording session). See Use Case 4 in Section 4 for more details.
REQ-005 O：メカニズムが原因の準備を記録RSにしても、CSの品質やタイミングに影響を与えることなく（CSの先頭にメディアをクリッピング、例えば）RSのメディアの損失なしにCSを記録する機能をサポートしなければなりません（記録セッションのための準備中に、例えば、CSの開始を遅らせます）。詳細は、第4節ではユースケース4を参照してください。
o REQ-006: The mechanism MUST support the recording of IVR sessions.
REQ-006 O：メカニズムは、IVRセッションの記録をサポートしなければなりません。
o REQ-007: The mechanism MUST support the recording of the following RTP media types: voice, DTMF (as defined by [RFC4733]), video, and text (as defined by [RFC4103]).
REQ-007 O：音声、DTMF（[RFC4733]で定義されるように）、ビデオ、およびテキスト（[RFC4103]で定義されるような）メカニズムは、次のRTPメディアタイプの記録をサポートしなければなりません。
o REQ-008: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from multiple Communication Sessions to an SRS.
REQ-008 O：機構がSRSに複数の通信セッションからの混合オーディオストリームを配信するSRC能力をサポートしなければなりません。
Note: A mixed audio stream is where several related Communication Sessions are carried in a single Recording Session. A mixed-media stream is typically produced by a mixer function. The RS MAY be informed about the composition of the mixed streams through session metadata.
注意：いくつかの関連通信セッションを単一のレコーディングセッションで運ばれるところ混合されたオーディオストリームです。混合メディア・ストリームは、典型的には、ミキサ関数によって生成されます。 RSは、セッションメタデータを介し混合ストリームの構成について通知されるかもしれません。
o REQ-009: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from different parties of a given Communication Session to an SRS.
REQ-009 O：メカニズムは、SRSに与えられた通信セッションの異なる政党から混合されたオーディオストリームを配信するSRCのための能力をサポートしなければなりません。
o REQ-010: The mechanism MUST support the ability to deliver to the SRS multiple media streams for a given CS.
REQ-010 O：メカニズムは、与えられたCSのためにSRSの複数のメディアストリームを送達する能力をサポートしなければなりません。
o REQ-011: The mechanism MUST support the ability to pause and resume the transmission and collection of RS media.
REQ-011 O：メカニズムは、RSメディアの送信と収集を一時停止し、再開する機能をサポートしなければなりません。
o REQ-012: The mechanism MUST include a means for providing the SRS with metadata describing CSs that are being recorded, including the media being used and the identifiers of parties involved.
O REQ-012：機構が使用されているメディアと関係者の識別子を含む、記録されているメタデータ記述CSSでSRSを提供するための手段を含まなければなりません。
o REQ-013: The mechanism MUST include a means for the SRS to be able to correlate RS media with CS participant media.
O REQ-013：メカニズムは、SRSは、CSの参加者のメディアとRSメディアを関連付けることができるようにするための手段を含まなければなりません。
o REQ-014: Metadata format must be agnostic of the transport protocol.
O REQ-014：メタデータ・フォーマットは、トランスポートプロトコルのとらわれなければなりません。
o REQ-015: The mechanism MUST support a means to stop the recording.
REQ-015 O：メカニズムは、録画を停止する手段をサポートしなければなりません。
o REQ-016: The mechanism MUST support a means for a recording-aware UA involved in a CS to request at session establishment time that the CS should be recorded or should not be recorded, the honoring of such a request being dependent on policy.
REQ-016 O：メカニズムは、ポリシーに依存するような要求の礼拝をCSを記録するか、記録されるべきではないことを、セッション確立時に要求するためにCSに関与記録対応のUAのための手段をサポートしなければなりません。
o REQ-017: The mechanism MUST support a means for a recording-aware UA involved in a CS to request during a session that the recording of the CS should be started, paused, resumed, or stopped, the honoring of such a request being dependent on policy. Such recording-aware UAs MUST be notified about the outcome of such requests.
O REQ-017は：メカニズムは、CSの録画が開始されるべきであるとのセッション中に要求するためにCSに関わる記録を意識したUAのための手段をサポートしなければならない、一時停止、再開、またはされ、そのような要求の礼拝を停止政策に依存。このような記録対応のUAは、このような要求の結果を通知しなければなりません。
o REQ-018: The mechanism MUST NOT prevent the application of tones or announcements during recording or at the start of a CS to support notification to participants that the call is being recorded or may be recorded.
REQ-018 O：メカニズムは、コールが記録されているか、記録することができることを参加者に通知をサポートするために、記録中またはCSの開始時トーンまたはアナウンスの適用を妨げてはなりません。
o REQ-019: The mechanism MUST provide a means of indicating to recording-aware UAs whether recording is taking place, for appropriate rendering at the user interface.
REQ-019 O：メカニズムは、記録は、ユーザインタフェースにおける適切なレンダリングのため、行われているかどうかを記録対応のUAに知らせる手段を提供しなければなりません。
o REQ-020: The mechanism MUST provide a way for metadata to be conveyed to the SRS incrementally during the CS.
REQ-020 O：メカニズムは、CS中増分SRSに搬送されるメタデータのための方法を提供しなければなりません。
o REQ-021: The mechanism MUST NOT prevent high-availability deployments.
REQ-021 O：メカニズムは、高可用性の展開を妨げてはなりません。
o REQ-022: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata.
REQ-022（O）メカニズムが記録されたメディア・ストリーム及びメタデータの同期化を容易にするための手段を提供しなければなりません。
o REQ-023: The mechanism MUST provide means for facilitating synchronization among the recorded media streams.
REQ-023 O：メカニズムは、記録されたメディアストリーム間の同期を容易にするための手段を提供しなければなりません。
o REQ-024: The mechanism MUST provide means to relate recording and recording controls, such as start/stop/pause/resume, to the wall clock time.
REQ-024 O：メカニズムは、壁時計時間に、そのような開始/停止/一時停止/再開のように、記録及び記録制御を関連付けるための手段を提供しなければなりません。
o REQ-025: The mechanism MUST provide means for an SRS to authenticate the SRC on RS initiation.
REQ-025 O：メカニズムは、RS開始にSRCを認証するためにSRSのための手段を提供しなければなりません。
o REQ-026: The mechanism MUST provide means for an SRC to authenticate the SRS on RS initiation.
O REQ-026：メカニズムはRS開始にSRSを認証するために、SRCのための手段を提供しなければなりません。
o REQ-027: The mechanism MUST include a means for ensuring that the integrity of the metadata sent from the SRC to the SRS is an accurate representation of the original CS metadata.
REQ-027 O：機構がSRSにSRCから送信されたメタデータの整合性は、元のCSメタデータの正確な表現であることを保証するための手段を含まなければなりません。
o REQ-028: The mechanism MUST include a means for ensuring that the integrity of the media sent from the SRC to the SRS is an accurate representation of the original CS media.
O REQ-028：機構がSRSにSRCから送信されたメディアの完全性は、元のCSメディアの正確な表現であることを保証するための手段を含まなければなりません。
o REQ-029: The mechanism MUST include a means for ensuring the confidentiality of the metadata sent from the SRC to the SRS.
REQ-029 O：機構がSRSにSRCから送信されたメタデータの機密性を確保するための手段を含まなければなりません。
o REQ-030: The mechanism MUST provide a means to support RS confidentiality.
REQ-030 O：メカニズムは、RSの機密性をサポートするための手段を提供しなければなりません。
o REQ-031: The mechanism MUST support the ability to deliver to the SRS multiple media streams of the same media type (e.g., audio, video). One example is the case of delivering unmixed audio for each participant in the CS.
O REQ-031：機構は、同じメディアタイプ（例えば、オーディオ、ビデオ）のSRS複数のメディアストリームを送達する能力をサポートしなければなりません。一例としては、CSの各参加者のために混合されていないオーディオを提供する場合です。
Respecting the privacy rights and wishes of users engaged in a call is of paramount importance. In many jurisdictions, participants have a right to know that the session is being recorded or might be recorded, and they have a right to opt out, either by terminating the call or by demanding that the call not be recorded. Therefore, this document contains requirements for being able to notify users that a call is being recorded and for users to be able to request that a call not be recorded. Use cases where users participating in a call are not informed that the call is or might be recorded are outside the scope of this document. In particular, lawful intercept is outside the scope of this document.
コールに従事し、ユーザーのプライバシーの権利と願いを尊重することは極めて重要です。多くの国では、参加者はセッションが記録されているか、記録される可能性があることを知る権利を持っている、と彼らは、通話を終了するか、呼び出しが記録されていないことを要求のいずれかによって、オプトアウトする権利を有します。したがって、このドキュメントは、通話が録音されていることをユーザーに通知することが可能であるために、ユーザはコールが記録されないように要求することができるようにするための要件が含まれています。コールに参加しているユーザは、コールがあるか、この文書の範囲外で記録される可能性があることを知らされていない場合に使用します。具体的には、合法的傍受は、この文書の範囲外です。
Requirements for participant notification of recording vary widely by jurisdiction. In a given deployment, not all users will be authorized to stop the recording of a CS (although any user can terminate its participation in a CS). Typically, users within the domain that is carrying out the recording will be subject to policies of that domain concerning whether CSs are recorded. For example, in a call center, agents will be subject to policies of the call center and may or may not have the right to prevent the recording of a CS or part of a CS. Users calling into the call center, on the other hand, will typically have to ask the agent not to record the CS. If the agent is unable to prevent recording, or if the caller does not trust the agent, the only option generally is to terminate the CS.
記録の参加通知するための要件は、管轄によって大きく異なります。所与の配備では、すべてのユーザが（任意のユーザがCSへの参加を終了することができるが）CSの記録を停止することを許可されません。典型的には、記録を行っているドメイン内のユーザーは、CSSが記録されているかどうかについて、そのドメインのポリシーの対象となります。例えば、コールセンターでは、薬剤は、コールセンターの方針の対象となりますし、あるいはCSまたはCSの一部の記録を防止するための権利を持っていない可能性があります。一方、コールセンターにコールするユーザーは、通常、CSを記録していないエージェントを依頼する必要があります。エージェントが記録を阻止することができない場合は、発信者がエージェントを信頼していない場合、または、唯一のオプションは、一般的にCSを終了することです。
Privacy considerations also extend to what happens to a recording once it has been created. Typical issues are who can access the recording (e.g., receive a copy of the recording, view the metadata, play back the media, etc.), for what purpose the recording can be used (e.g., for training purposes, for quality control purposes, etc.), and for how long the recording is to be retained before deletion. These are typically policies of the domain that makes the recording, rather than policies of individual users involved in a recorded CS, whether those users be in the same domain or in a different domain. Taking the call center example again, agents might be made aware of call center policy regarding retention and use of recordings as part of their employment contract, and callers from outside the call center might be given some information about policy when notified that a CS will be recorded (e.g., through an announcement that says that calls may be recorded for quality purposes).
プライバシーの考慮はまた、作成された後に記録に何が起こるかまで延びています。典型的な問題は、品質管理の目的のために、記録は例えば、訓練目的のために使用することができる（どのような目的のために、（メディアなどを再生し、例えば、記録のコピーを受け取るメタデータを表示）記録にアクセスできる人ですなど）、および記録は削除する前に保持する時間の長さについて。これらは、典型的には、それらのユーザーが同じドメイン内または異なるドメインに存在するかどうか、むしろ記録CSに関わる個々のユーザの政策よりも、記録を作るドメインのポリシーです。再度、コールセンターの例に取ると、薬剤は、彼らの雇用契約の一部として保持し、録音の使用に関するコールセンター方針を認識されるかもしれない、とCSがなることを通知されたとき、コールセンターの外部から発信者は、ポリシーに関するいくつかの情報を与える可能性があります（例えば、通話品質の目的のために記録することができることを言うの発表を通じて）を記録。
This document does not specify any requirements for a user engaged in a CS to be able to dictate policy for what happens to a recording, or for such information to be conveyed from an SRC to an SRS. It is assumed that the SRS has access to policy applicable to its environment and can ensure that recordings are stored and used in accordance with that policy.
この文書では、記録に何が起こるかについて、またはSRSのSRCから搬送されるような情報のための政策を決定することができるようにCSに従事したユーザーのいずれかの要件を指定していません。 SRSは、その環境に適用可能なポリシーにアクセスし、録音が保存され、そのポリシーに従って使用されていることを確認することができるものとします。
Session recording has substantial security implications, for the SIP UAs being recorded, the SRC, and the SRS.
SIP UAは、記録SRC、およびSRSされるためのセッション記録は、かなりのセキュリティへの影響を持っています。
For the SIP UAs involved in the Communication Session, the requirements in this document enable the UA to identify that a Communication Session is being recorded and to request that a given Communication Session not be subject to recording.
通信セッションに関与するSIPのUAのために、この文書の要件は、通信セッションが記録されていることを識別し、所与の通信セッションは、記録の対象としないことを要求するUAを可能にします。
Since humans don't typically look at or know about protocol signaling such as SIP, and indeed the SIP session might have originated through a Public Switched Telephone Network (PSTN) gateway without any ability to pass on in-signaling indications of recording, users can be notified of recording in the media itself through voice announcements, a visual indicator on the endpoint, or other means.
人間は一般的に見またはプロトコルはSIPなどのシグナリングを知って、そして実際にSIPセッションが公開を通じて発信している場合がありますしていないので、ユーザーができ、中にシグナリング記録の兆候に合格する任意の能力なしで電話網（PSTN）ゲートウェイを交換音声アナウンス、エンドポイント上の視覚インジケータ、または他の手段を介してメディア自体に記録を通知します。
With regard to security implications of the protocol(s), clearly there is a need for authentication, authorization, and eavesdropping protection for the solution. The SRC needs to know the SRS it is communicating with is legitimate, and vice versa, even if they are in different domains. Both the signaling and media for the Recording Session need the ability to be authenticated and protected from eavesdropping. Requirements are detailed in Section 5.
プロトコル（複数可）のセキュリティへの影響に関しては、明確に解決のための認証、許可、および盗聴の保護の必要性があります。 SRCは、彼らが異なるドメインにある場合でも、それが正当なものである、とその逆と通信しているSRSを知っている必要があります。シグナリングとレコーディング・セッションのためのメディアの両方が認証され、盗聴から保護する能力を必要とします。要件は、第5節で詳述されています。
Communication Sessions and Recording Sessions can require different security levels both for signaling and media, depending on deployment configurations. For some environments, e.g., the SRS and SRC will be collocated in a secure network region, and therefore the RS will not require the same protection level as a CS that extends over a public network, for example. For other environments, the SRS can be located in a public cloud, for example, and the RS will require a higher protection level than the CS. For these reasons, there is not a direct relationship between the security level of Communication Sessions and the security level of Recording Sessions.
通信セッションとレコーディングセッションは、シグナリングとメディア、配置構成に応じてのために両方の異なるセキュリティレベルを必要とすることができます。いくつかの環境では、例えば、SRSとSRCは、安全なネットワーク領域に並置され、したがって、RSは、例えば、公衆ネットワークを介して延びているCSと同じ保護レベルを必要としません。他の環境では、SRSは、例えば、パブリッククラウドに配置することができ、およびRSはCSよりも高い保護レベルが必要になります。これらの理由から、通信セッションと記録セッションのセキュリティレベルのセキュリティレベルとの間に直接の関係はありません。
A malicious or corrupt SRC can tamper with media and metadata relating to a CS before sending the data to an SRS. Also, CS media and signaling can be tampered with in the network prior to reaching an SRC, unless proper means are provided to ensure integrity protection during transmission on the CS. Means for ensuring the correctness of media and metadata emitted by an SRC are outside the scope of this work. Other organizational and technical controls will need to be used to prevent tampering.
悪意のあるまたは破損したSRCはメディアとメタデータは、SRSにデータを送信する前にCSに関係を改ざんすることができます。適切な手段はCSでの送信時に整合性保護を確保するために提供されていない限り、また、CSメディアとシグナリングは、SRCに到達する前にネットワークに改ざんすることができます。 SRCによって放出されたメディアおよびメタデータの正しさを確保するための手段は、この仕事の範囲外です。他の組織との技術的なコントロールは、改ざんを防ぐために使用する必要があります。
Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and Charles Eckel for their significant contributions and assistance with this document and the SIPREC WG, and to all the members of the DISPATCH WG and SIPREC WG mailing lists for providing valuable input to this work.
彼らの重要な貢献のためのダン・ウィングのおかげで、アラン・ジョンソン、ビジェイGurbani、カレン・ジェニングス、Hadrielカプラン、ヘンリー・ラム、デイブ・スミス、マーティン・パーマー、アリッサ・クーパー、Deepanshuゴータム、ポールKyzivat、Parthasarathi R、ラムモハンR、およびチャールズEckel氏とこの作品への貴重な入力を提供するため、このドキュメントとSIPREC WGで、発送WGとSIPREC WGメーリングリストのすべてのメンバーへの支援。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のためのRTPペイロード"、RFC 4103、2005年6月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733] Schulzrinneと、H.、およびT.テイラー、 "DTMFケタ、電話トーン、およびテレフォニーシグナルのためのRTPペイロード"、RFC 4733、2006年12月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.
[RFC4949] Shirey、R.、 "インターネットセキュリティ用語集、バージョン2"、FYI 36、RFC 4949、2007年8月。
Authors' Addresses
著者のアドレス
Ken Rehor (editor) Cisco Systems 170 West Tasman Dr. Mail Stop SJC30/2/ San Jose, CA 95134 USA
ケンRehor（編集者）、シスコシステムズ170西タスマン博士メールストップSJC30 / 2 /サンノゼ、CA 95134 USA
EMail: krehor@cisco.com
メールアドレス：krehor@cisco.com
Leon Portman (editor) NICE Systems 8 Hapnina Ra'anana 43017 Israel
レオン・ポートマン（エディタ）NICEシステムズ8 Hapnina Ra'anana 43017イスラエル
EMail: leon.portman@nice.com
メールアドレス：leon.portman@nice.com
Andrew Hutton Siemens Enterprise Communications
アンドリュー・ハットンシーメンスエンタープライズコミュニケーションズ
EMail: andrew.hutton@siemens-enterprise.com URI: http://www.siemens-enterprise.com
電子メール：andrew.hutton@siemens-enterprise.com URI：http://www.siemens-enterprise.com
Rajnish Jain IPC Systems 777 Commerce Drive Fairfield, CT 06825 USA
RajnishジャイナIPCシステム777コマースドライブフェアフィールド、CT 06825 USA
EMail: rajnish.jain@ipc.com
メールアドレス：rajnish.jain@ipc.com