[要約] RFC 6341は、SIPREC（SIPベースのメディア録音）の使用事例と要件を定義しています。その目的は、SIPセッションの録音をサポートするための標準化とガイドラインを提供することです。
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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電話など）、SIPメディアゲートウェイ（MG）、セッションボーダーコントローラー（SBC）、またはアプリケーションサーバー（AS）と統合されたSIPメディアサーバー（MS）である可能性があります。。この仕様は、「SRC」という用語を定義し、そのようなすべてのSIPエンティティに1つの定義の下で一般的に対処できるようにします。SRCは、SRSにメタデータを提供します。
Communication Session (CS): A session created between two or more SIP User Agents (UAs) that is the subject of recording.
通信セッション（CS）：録音の主題である2つ以上の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：フルタイムの録音：各通信セッションの1つの録音セッション。
For example, the diagram below shows the life cycle of Communication Sessions (CSs) and the relationship to the Recording Sessions (RS).
たとえば、以下の図は、通信セッション（CSS）のライフサイクルとレコーディングセッション（RS）との関係を示しています。
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.
レコーディングセッションは、ユーザーが制御するメカニズム（ユーザーの電話のボタンなど）を介して手動で手動で、またはアプリケーション（コンタクトセンターのカスタマーサービスアプリケーションなど）またはビジネスイベントを介して自動的に行われます。レコーディングセッションは、通信セッション中または通信セッションが終了したときに終了します。1つ以上の録音セッションは、各通信セッションを記録する場合があります。
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:
場合によっては、複数の同時通信セッション（単一のエンドユーザー装置、たとえば、取引フロアタレットなど）が1つの録音セッションに混ざり合っています。
|-------- 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（支払いカード業界）コンプライアンスの場合です。解決策の1つは、クレジットカード情報を話している発信者を記録しないことです。
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セッションの録音に関するメタデータには、セッション情報を含める必要があり、アプリケーションコンテキスト情報（beoveXMLセッション変数、ダイアログ名など）を含めることができます。
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.
以下は、記録される1つの呼び出しが、記録する必要がある関連する呼び出しに関連付けられている必要があるシナリオの例です。
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.
o REQ-002：メカニズムは、すべてのCSS全体を記録する能力をサポートする必要があります。
o REQ-003: The mechanism MUST support the ability to record selected CSs in their entirety, according to policy.
o REQ-003：メカニズムは、ポリシーに従って、選択したCSS全体を記録する能力をサポートする必要があります。
o REQ-004: The mechanism MUST support the ability to record selected parts of selected CSs.
o REQ-004：メカニズムは、選択した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.
o REQ-005：メカニズムは、RSの記録準備とCSの品質やタイミングに影響を与えることなく、RSのメディア（たとえば、CSの開始時にメディアを切り取る）を失うことなくCSを記録する能力をサポートする必要があります（CSの開始）たとえば、録音セッションの準備中にCSの開始を遅らせる）。詳細については、セクション4のユースケース4を参照してください。
o REQ-006: The mechanism MUST support the recording of IVR sessions.
o REQ-006：メカニズムは、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]).
o REQ-007：メカニズムは、次のRTPメディアタイプの記録をサポートする必要があります：Voice、DTMF（[RFC4733]で定義）、ビデオ、およびテキスト（[RFC4103]で定義）。
o REQ-008: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from multiple Communication Sessions to an SRS.
o REQ-008：メカニズムは、SRCが複数の通信セッションからSRSに混合オーディオストリームを配信する機能をサポートする必要があります。
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.
o REQ-009：メカニズムは、SRCが特定の通信セッションのさまざまなパーティーからSRSに混合オーディオストリームを配信する能力をサポートする必要があります。
o REQ-010: The mechanism MUST support the ability to deliver to the SRS multiple media streams for a given CS.
o REQ-010：メカニズムは、特定のCSの複数のメディアストリームをSRSに配信する機能をサポートする必要があります。
o REQ-011: The mechanism MUST support the ability to pause and resume the transmission and collection of RS media.
o REQ-011：メカニズムは、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がRSメディアをCS参加者メディアと相関させるための手段を含める必要があります。
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.
o REQ-015：メカニズムは、記録を停止する手段をサポートする必要があります。
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.
o REQ-016：メカニズムは、CSに関与する録音認識UAが、CSを記録するか、記録すべきではないことをセッション設立時間に要求するための手段をサポートする必要があります。
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に関与する録音認識UAがCSの録音を開始、一時停止、再開、または停止することを要求するための手段をサポートする必要があります。ポリシーについて。そのような録音認識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.
o REQ-018：メカニズムは、録画中または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.
o REQ-019：メカニズムは、ユーザーインターフェイスでの適切なレンダリングのために、記録が行われているかどうかを記録するUASに示す手段を提供する必要があります。
o REQ-020: The mechanism MUST provide a way for metadata to be conveyed to the SRS incrementally during the CS.
o REQ-020：メカニズムは、CS中にメタデータをSRSに段階的に伝達する方法を提供する必要があります。
o REQ-021: The mechanism MUST NOT prevent high-availability deployments.
o REQ-021：メカニズムは、高可用性の展開を防止してはなりません。
o REQ-022: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata.
o REQ-022：メカニズムは、記録されたメディアストリームとメタデータの同期を促進する手段を提供する必要があります。
o REQ-023: The mechanism MUST provide means for facilitating synchronization among the recorded media streams.
o REQ-023：メカニズムは、記録されたメディアストリーム間の同期を促進する手段を提供する必要があります。
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.
o REQ-024：メカニズムは、登録/停止/一時停止/履歴書などの記録と記録のコントロールを壁の時計時間に関連付ける手段を提供する必要があります。
o REQ-025: The mechanism MUST provide means for an SRS to authenticate the SRC on RS initiation.
o REQ-025：メカニズムは、SRSがRS開始時にSRCを認証する手段を提供する必要があります。
o REQ-026: The mechanism MUST provide means for an SRC to authenticate the SRS on RS initiation.
o REQ-026：メカニズムは、SRCがRS開始時にSRSを認証する手段を提供する必要があります。
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.
o REQ-027：メカニズムには、SRCからSRSに送られたメタデータの完全性が元の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：メカニズムには、SRCからSRSに送信されるメディアの完全性が元のCSメディアの正確な表現であることを保証するための手段を含める必要があります。
o REQ-029: The mechanism MUST include a means for ensuring the confidentiality of the metadata sent from the SRC to the SRS.
o REQ-029：メカニズムには、SRCからSRSに送信されたメタデータの機密性を確保するための手段を含める必要があります。
o REQ-030: The mechanism MUST provide a means to support RS confidentiality.
o REQ-030：メカニズムは、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に配信する機能をサポートする必要があります（たとえば、オーディオ、ビデオ）。1つの例は、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.
このドキュメントでは、CSに従事するユーザーが、録音に何が起こるか、またはSRCからSRSに伝えられるような情報についてポリシーを決定できるようにするための要件を指定していません。SRSは、その環境に適用されるポリシーにアクセスできると想定されており、そのポリシーに従って記録が保存および使用されることを保証できます。
Session recording has substantial security implications, for the SIP UAs being recorded, the SRC, and the SRS.
セッション記録には、SIP UAS、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
悪意のあるまたは腐敗したSRCは、データをSRSに送信する前に、CSに関連するメディアとメタデータを改ざんすることができます。また、CSのメディアとシグナリングは、SRCに到達する前にネットワーク内で改ざんすることができます。を確保するための手段
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によって放出されるメディアとメタデータの正しさは、この作業の範囲外です。改ざんを防ぐために、他の組織的および技術的な制御を使用する必要があります。
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.
ダン・ウィング、アラン・ジョンソン、ヴィジェイ・ガーバニ、カレン・ジェニングス、ハドリエル・カプラン、ヘンリー・ラム、デイブ・スミス、マーティン・パーマー、アリッサ・クーパー、ディーパン・ガウタム、ポール・カジバット、パルタサラティR、ラム・モハンR、チャールズ・エッケルのおかげでこのドキュメントと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] 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 INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103] Hellstrom、G。およびP. Jones、「テキスト会話のための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. Taylor、「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
Ken Rehor（編集者）Cisco Systems 170 West Tasman Dr. Mail Stop SJC30/ 2/ San Jose、CA 95134 USA
EMail: krehor@cisco.com
Leon Portman (editor) NICE Systems 8 Hapnina Ra'anana 43017 Israel
レオン・ポートマン（編集者）素敵なシステム8ハプニナ・ラアナナ43017イスラエル
EMail: leon.portman@nice.com
Andrew Hutton Siemens Enterprise Communications
Andrew Hutton Siemens Enterprise Communications
EMail: andrew.hutton@siemens-enterprise.com
URI: http://www.siemens-enterprise.com
Rajnish Jain IPC Systems 777 Commerce Drive Fairfield, CT 06825 USA
Rajnish Jain IPC Systems 777 Commerce Driveフェアフィールド、CT 06825 USA
EMail: rajnish.jain@ipc.com