[要約] RFC 7245は、セッション開始プロトコルを使用したメディア録音のためのアーキテクチャに関するものであり、その目的は、セッション開始プロトコルを使用してメディア録音を実現するためのフレームワークを提供することです。
Internet Engineering Task Force (IETF) A. Hutton, Ed.
Request for Comments: 7245 Unify
Category: Informational L. Portman, Ed.
ISSN: 2070-1721 NICE Systems
R. Jain
IPC Systems
K. Rehor
Cisco Systems, Inc.
May 2014
An Architecture for Media Recording Using the Session Initiation Protocol
セッション開始プロトコルを使用したメディア録音のアーキテクチャ
Abstract
概要
Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions in an environment that is based on the Session Initiation Protocol (SIP).
セッションの録音は、コールセンターや金融取引などの多くの通信環境で重要な要件です。これらの環境の一部では、規制、コンプライアンス、および消費者保護の理由から、すべての通話を記録する必要があります。セッションの記録は、通常、メディアストリームのコピーを記録デバイスに送信することによって実行されます。このドキュメントでは、Session Initiation Protocol（SIP）に基づく環境でセッション記録ソリューションを展開するためのアーキテクチャについて説明します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、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/rfc7245.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7245で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Session Recording Architecture . . . . . . . . . . . . . . . 5
3.1. Location of the SRC . . . . . . . . . . . . . . . . . . . 5
3.1.1. B2BUA Acts as a SRC . . . . . . . . . . . . . . . . . 5
3.1.2. Endpoint Acts as SRC . . . . . . . . . . . . . . . . 6
3.1.3. A SIP Proxy Cannot Be a SRC . . . . . . . . . . . . . 7
3.1.4. Interaction with MEDIACTRL . . . . . . . . . . . . . 7
3.1.5. Interaction with Conference Focus . . . . . . . . . . 9
3.2. Establishing the Recording Session . . . . . . . . . . . 10
3.2.1. SRC-Initiated Recording . . . . . . . . . . . . . . . 11
3.2.2. SRS-Initiated Recording . . . . . . . . . . . . . . . 11
3.2.3. Pause/Resume Recording Session . . . . . . . . . . . 12
3.2.4. Media Stream Mixing . . . . . . . . . . . . . . . . . 12
3.2.5. Media Transcoding . . . . . . . . . . . . . . . . . . 12
3.2.6. Lossless Recording . . . . . . . . . . . . . . . . . 12
3.3. Recording Metadata . . . . . . . . . . . . . . . . . . . 13
3.3.1. Contents of Recording Metadata . . . . . . . . . . . 13
3.3.2. Mechanisms for Delivery of Metadata to SRS . . . . . 13
3.4. Notifications to the Recorded User Agents . . . . . . . . 13
3.5. Preventing the Recording of a SIP Session . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. Informative References . . . . . . . . . . . . . . . . . . . 15
Session recording is a critical requirement in many communications environments such as call centers and financial trading. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. Recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions as defined in "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)" [RFC6341].
セッションの録音は、コールセンターや金融取引などの多くの通信環境で重要な要件です。これらの環境の一部では、規制、コンプライアンス、および消費者保護の理由から、すべての通話を記録する必要があります。セッションの記録は、通常、メディアストリームのコピーを記録デバイスに送信することによって実行されます。このドキュメントでは、「SIPベースのメディア録音（SIPREC）の使用例と要件」[RFC6341]で定義されている、セッション録音ソリューションを展開するためのアーキテクチャについて説明します。
This document focuses on how sessions are established between a Session Recording Client (SRC) and the Session Recording Server (SRS) for the purpose of conveying the Replicated Media and Recording Metadata (e.g., identity of the parties involved) relating to the Communication Session.
このドキュメントでは、通信セッションに関連するレプリケートメディアとレコーディングメタデータ（関係者のIDなど）を伝達する目的で、Session Recording Client（SRC）とSession Recording Server（SRS）の間でセッションが確立される方法に焦点を当てています。
Once the Replicated Media and Recording Metadata have been received by the SRS, they will typically be archived for retrieval at a later time. The procedures relating to the archiving and retrieval of this information are outside the scope of this document.
複製されたメディアとレコーディングメタデータがSRSによって受信されると、それらは通常、後で取得するためにアーカイブされます。この情報のアーカイブと取得に関連する手順は、このドキュメントの範囲外です。
This document only considers active recording, where the SRC purposefully streams media to a SRS. Passive recording, where a recording device detects media directly from the network (e.g., using port-mirroring techniques), is outside the scope of this document. In addition, lawful intercept is outside the scope of this document, which takes account of the IETF policy on wiretapping [RFC2804].
このドキュメントでは、SRCが意図的にメディアをSRSにストリーミングするアクティブレコーディングのみを考慮しています。記録デバイスがネットワークから直接メディアを検出する（たとえば、ポートミラーリング技術を使用する）パッシブ記録は、このドキュメントの範囲外です。さらに、合法的傍受はこのドキュメントの範囲外であり、盗聴に関するIETFポリシー[RFC2804]を考慮しています。
The Recording Session that is established between the SRC and the SRS uses the normal procedures for establishing INVITE-initiated dialogs as specified in [RFC3261] and uses the Session Description Protocol (SDP) for describing the media to be used during the session as specified in [RFC4566]. However, it is intended that some extensions to SIP (e.g., Headers, Option Tags, etc.) will be defined to support the requirements for media recording. The Replicated Media is required to be sent in real-time to the SRS and is not buffered by the SRC to allow for real-time analysis of the media by the SRS.
SRCとSRSの間で確立される記録セッションは、[RFC3261]で指定されているINVITEで開始されるダイアログを確立する通常の手順を使用し、セッション記述プロトコル（SDP）を使用して、セッション中に使用されるメディアを[RFC4566]。ただし、メディア録音の要件をサポートするために、SIPの一部の拡張機能（ヘッダー、オプションタグなど）が定義される予定です。複製されたメディアは、SRSにリアルタイムで送信する必要があり、SRSによるメディアのリアルタイム分析を可能にするためにSRCによってバッファーされません。
The first four definitions are quoted from RFC 6341.
最初の4つの定義はRFC 6341から引用されています。
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ユーザーエージェント（UA）間で作成されたセッション。
Recording Session (RS): The SIP session created between an SRC and SRS for the purpose of recording a CS.
記録セッション（RS）：CSを記録する目的でSRCとSRSの間に作成されたSIPセッション。
The following terms are defined by this document.
このドキュメントでは、次の用語が定義されています。
Recording-aware User Agent (UA): A SIP User Agent that is aware of SIP extensions associated with the CS. Such extensions may be used to notify the recording-aware UA that a session is being recorded, or by a recording-aware UA to express preferences as to whether a recording should be started, paused, resumed, or stopped.
録音対応ユーザーエージェント（UA）：CSに関連付けられたSIP拡張を認識するSIPユーザーエージェント。そのような拡張機能は、セッションが記録されていることを記録認識UAに通知するために、または記録認識UAによって、記録を開始、一時停止、再開、または停止するかどうかに関する設定を表すために使用できます。
Recording-unaware User Agent (UA): A SIP User Agent that is unaware of SIP extensions associated with the CS. Such a recording-unaware UA will be notified that a session is being recorded or will express preferences as to whether a recording should be started, paused, resumed, or stopped via some other means that is out of scope for the SIP media recording architecture.
記録非対応ユーザーエージェント（UA）：CSに関連付けられたSIP拡張を認識しないSIPユーザーエージェント。そのような録音を認識しないUAは、セッションが録音されていることを通知されるか、SIPメディア録音アーキテクチャの範囲外である他の手段を介して録音を開始、一時停止、再開、または停止するかどうかに関する設定を示します。
Recording Metadata: The metadata describing the CS that is required by the SRS. This will include, for example, the identities of users that participate in the CS and dialog state. Typically, this metadata is archived with the Replicated Media at the SRS. The recording metadata is delivered in real-time to the SRS.
メタデータの記録：SRSが必要とするCSを説明するメタデータ。これには、たとえば、CSに参加するユーザーのIDとダイアログの状態が含まれます。通常、このメタデータは、SRSで複製されたメディアとともにアーカイブされます。記録メタデータは、リアルタイムでSRSに配信されます。
Replicated Media: A copy of the media that is associated with the CS, was created by the SRC, and was sent to the SRS. It may contain all the media associated with the CS (e.g., audio and video) or just a subset (e.g., audio). Replicated Media is part of the Recording Session.
複製されたメディア：CSに関連付けられ、SRCによって作成され、SRSに送信されたメディアのコピー。これには、CSに関連付けられているすべてのメディア（オーディオやビデオなど）またはサブセット（オーディオなど）のみが含まれます。複製されたメディアは、録音セッションの一部です。
This section contains some example session recording architectures showing how the SRC is a logical function that can be located in or split between various physical components.
このセクションには、SRCがさまざまな物理コンポーネント内に配置したり、さまざまな物理コンポーネント間で分割したりできる論理機能であることを示す、セッション記録アーキテクチャの例がいくつか含まれています。
A SIP Back-to-Back User Agent (B2BUA) that has access to the media to be recorded may act as an SRC. The B2BUA may already be aware that a session needs to be recorded before the initial establishment of the CS, or the decision to record the session may occur after the session has been established.
記録されるメディアにアクセスできるSIPバックツーバックユーザーエージェント（B2BUA）は、SRCとして機能します。 B2BUAは、CSの最初の確立の前にセッションを記録する必要があることをすでに認識している場合があります。または、セッションの確立後にセッションを記録する決定が行われる場合があります。
If the SRC makes the decision to initiate the RS, then it will do so by sending a SIP INVITE request to the SRS.
SRCがRSを開始することを決定した場合、SRCにSIP INVITE要求を送信することによってそれを行います。
If the SRS makes the decision to initiate the Recording Session, then it will initiate the establishment of a SIP RS by sending an INVITE to the SRC.
SRSが録音セッションを開始することを決定した場合、SRSにINVITEを送信してSIP RSの確立を開始します。
The RS INVITE contains information that identifies the session as being established for the purposes of recording and prevents the session from being accidentally rerouted to a UA that is not an SRS if the RS was initiated by the SRC or vice versa.
RS INVITEには、記録の目的で確立されているセッションを識別する情報が含まれており、RSがSRCによって開始された場合、またはその逆の場合、セッションが誤ってSRSでないUAに再ルーティングされるのを防ぎます。
The B2BUA/SRC is responsible for notifying the UAs involved in the CS that the session is being recorded.
B2BUA / SRCは、セッションが記録されていることをCSに関係するUAに通知する責任があります。
The B2BUA/SRC is responsible for complying with requests from recording aware UAs or through some configured policies indicating that the CS should not be recorded.
B2BUA / SRCは、認識しているUAの記録からの要求、またはCSを記録しないことを示すいくつかの構成されたポリシーを遵守する責任があります。
+-----------+
(Recording Session) | Session |
+------SIP------>| Recording |
| | Server |
| +--RTP/RTCP-->| (SRS) |
| | +-----------+
V V ^
+-------------+ |
| | |
| |-- Metadata -+
| |
| B2BUA |
| |
| Session |
+--------+ | Recording | +---------+
| |<- SIP ->| Client |<- SIP ->| |
| UA-A | | (SRC) | | UA-B |
| |<- RTP/->| |<- RTP/->| |
+--------+ RTCP | | RTCP +---------+
+-------------+
|____________________________________________________|
(Communication Session)
Figure 1: B2BUA Acts as the Session Recording Client
図1：B2BUAがセッション記録クライアントとして機能
A SIP endpoint / UA may act as a SRC. In that case, the endpoint sends the Replicated Media to the SRS.
SIPエンドポイント/ UAはSRCとして機能します。その場合、エンドポイントは複製されたメディアをSRSに送信します。
If the endpoint makes the decision to initiate the Recording Session, then it will initiate the establishment of a SIP Session by sending an INVITE to the SRS.
エンドポイントが録音セッションを開始することを決定した場合、INVITEをSRSに送信することにより、SIPセッションの確立を開始します。
If the SRS makes the decision to initiate the Recording Session, then it will initiate the establishment of a SIP Session by sending an INVITE to the endpoint. The actual decision mechanism is out of scope for the SIP media recording architecture.
SRSが録音セッションを開始することを決定した場合、SRSはINVITEをエンドポイントに送信することでSIPセッションの確立を開始します。実際の決定メカニズムは、SIPメディアレコーディングアーキテクチャの範囲外です。
(Recording Session) +-----------+
+----------SIP------>| |
| +----RTP/RTCP---->| Session |
| | | Recording |
| | | Server |
| | +-- Metadata -->| (SRS) |
| | | | |
| | | +-----------+
| | |
| | |
| | |
| | |
V V | (Communication Session)
+--+------+ +---------+
| |<-------SIP--------->| |
| UA-A | | UA-B |
| (SRC) |<-----RTP/RTCP------>| |
+---------+ +---------+
Figure 2: SIP Endpoint Acts as the Session Recording Client
図2：SIPエンドポイントがセッション記録クライアントとして機能
A SIP Proxy is unable to act as an SRC because it does not have access to the media and therefore has no way of enabling the delivery of the Replicated Media to the SRS.
SIPプロキシはメディアにアクセスできないため、SRCへの複製されたメディアの配信を有効にする方法がないため、SRCとして機能できません。
The MEDIACTRL architecture [RFC5567] describes an architecture in which an Application Server (AS) controls a Media Server (MS), which may be used for purposes such as conferencing and recording media streams. In the architecture described in [RFC5567], the AS typically uses SIP Third Party Call Control (3PCC) to instruct the SIP UAs to direct their media to the Media Server.
MEDIACTRLアーキテクチャ[RFC5567]は、アプリケーションサーバー（AS）がメディアサーバー（MS）を制御するアーキテクチャを示しています。これは、メディアストリームの会議や記録などの目的で使用できます。 [RFC5567]で説明されているアーキテクチャでは、ASは通常、SIPサードパーティコール制御（3PCC）を使用して、メディアをメディアサーバーに転送するようにSIP UAに指示します。
The SRC or the SRS described in this document may be architected according to [RFC5567]; therefore, when further decomposed, they may be made up of an AS that uses a MEDIACTRL interface to control an MS.
このドキュメントで説明されているSRCまたはSRSは、[RFC5567]に従って設計されている場合があります。したがって、さらに分解すると、MEDIACTRLインターフェイスを使用してMSを制御するASで構成されます。
As shown in Figure 3, when the SRS is architected according to [RFC5567], the MS acts as a sink of the recording media, and the AS acts as a sink of the metadata and the termination point for RS SIP signaling. As shown in Figure 4, when the SRC is architected according to [RFC5567], the MS acts as a source of recording media, and the AS acts as a source of the metadata and the termination point for RS SIP signaling.
図3に示すように、SRSが[RFC5567]に従って設計されている場合、MSは記録メディアのシンクとして機能し、ASはメタデータとRS SIPシグナリングの終端ポイントのシンクとして機能します。図4に示すように、SRCが[RFC5567]に従って設計されている場合、MSは記録メディアのソースとして機能し、ASはメタデータとRS SIPシグナリングの終端ポイントのソースとして機能します。
Session Recording Server (SRS)
+----------------------------------------+
| |
(Recording Session) | +-----------+ +------------+ |
+------------SIP----|->| | | | |
| | | MEDIACTRL |MEDIACTRL | Media | |
| | |Application|<-------->| Server | |
| +-----Metadata--->| Server | | (Recorder)| |
| | | | | | | |
| | | +-----------+ +------------+ |
| | | ^ |
| | +------------------------------|---------+
| | +--------------- RTP/RTCP -----------------+
| | |
V | V
+---+------+ +---------+
| |<-------SIP-------------->| |
| UA-A | (Communication Session) | UA-B |
| (SRC) |<-------RTP/RTCP--------->| |
+----------+ +---------+
Figure 3: Example of Session Recording Server using MEDIACTRL
図3：MEDIACTRLを使用したSession Recordingサーバーの例
+----------+
(Recording Session) | Session |
+-----------SIP------------------------->|Recording |
| +----------Metadata------------------->| Server |
| | | (SRS) |
V | UA-A Session Recording Client (SRC) +----------+
+----------------------------------------+ ^
| | |
| +-----------+ +------------+ | |
| | | Control | |<-RTP/RTCP-+ +---------+
| | UA | Protocol | Media | | | |
| |Application|<-------->| Server | |<----SIP----->| UA-B |
| | Server | | |<-----RTP------>| |
| | | | | | +---------+
| +-----------+ +------------+ |
| |
+----------------------------------------+
Figure 4: Example of Session Recording Client Decomposition
図4：セッション記録クライアント分解の例
In the case of a centralized conference, a combination of the conference focus and mixer [RFC4353] may act as a SRC and therefore provide the SRS with the Replicated Media and associated recording metadata. In this arrangement, the SRC is able to provide media and metadata relating to each of the participants, including, for example, any side conversations where the media passes through the mixer.
集中型会議の場合、会議のフォーカスとミキサーの組み合わせ[RFC4353]がSRCとして機能し、SRSに複製されたメディアと関連する記録メタデータを提供します。この構成では、SRCは、たとえば、メディアがミキサーを通過するサイドカンバセーションなど、参加者のそれぞれに関連するメディアとメタデータを提供できます。
The conference focus can either provide mixed Replicated Media or separate streams per conference participant (as depicted in Figure 5).
会議の焦点は、レプリケートされたメディアを混在させることも、会議の参加者ごとに個別のストリームを提供することもできます（図5を参照）。
The conference focus may also act as a recording-aware UA in the case when one of the participants acts as a SRC.
会議のフォーカスは、参加者の1人がSRCとして機能する場合に、録音対応UAとしても機能します。
In an alternative arrangement, a SIP endpoint that is a conference participant can act as an SRC. The SRC will in this case have access to the media and metadata relating to that particular participant and may be able to obtain additional metadata from the conference focus. The SRC may, for example, use the conference event package as described in [RFC4575] to obtain information about other participants that it provides to the SRS within the recording metadata.
代替構成では、会議の参加者であるSIPエンドポイントがSRCとして機能できます。この場合、SRCはその特定の参加者に関連するメディアとメタデータにアクセスでき、会議のフォーカスから追加のメタデータを取得できる場合があります。 SRCは、たとえば、[RFC4575]で説明されている会議イベントパッケージを使用して、レコーディングメタデータ内でSRSに提供する他の参加者に関する情報を取得できます。
The SRC may be involved in the conference from the very beginning or may join at some later point of time.
SRCは最初から会議に参加する場合と、後で参加する場合があります。
User 1
+-----------+
| |
| |
|Participant|
| 1 |
| |
+-----------+
^ ^SIP
RTP | |Dialog
| |1
User 2 V V Recording
+-----------+ +-----------+ Session *************
| | | |<------------>* *
| |<-- RTP -->| |<-RTP/RTCP 1->* *
|Participant|<--------->| Focus/SRC |<-RTP/RTCP 2->* SRS *
| 2 | SIP | |<-RTP/RTCP 3->* *
| | Dialog | | * *
+-----------+ 2 +-----------+ *************
^ ^
| |SIP
RTP | |Dialog
| |3
V V
+-----------+
| |
| |
|Participant|
| 3 |
| |
+-----------+
User 3
Figure 5: Conference Focus Acting as an SRC
図5：SRCとして機能する会議の焦点
The SRC or the SRS may initiate the Recording Session.
SRCまたはSRSが記録セッションを開始できます。
It should be noted that the Recording Session is independent from the CS that is being recorded at both the SIP dialog level and at the session level.
記録セッションは、SIPダイアログレベルとセッションレベルの両方で記録されているCSから独立していることに注意してください。
Concerning media negotiation, regular SIP/SDP capabilities should be used, and existing transcoding capabilities and media encryption should not be precluded.
メディアネゴシエーションに関しては、通常のSIP / SDP機能を使用する必要があり、既存のトランスコーディング機能とメディア暗号化を排除しないでください。
When the SRC initiates the Recording Session for the purpose of conveying media to the SRS, it performs the following actions:
SRCがメディアをSRSに伝達する目的で記録セッションを開始すると、SRCは次のアクションを実行します。
o Is provisioned with a Unified Resource Identifier (URI) for the SRS; the URI is resolved through normal [RFC3263] procedures.
o SRSの統合リソース識別子（URI）でプロビジョニングされます。 URIは通常の[RFC3263]手順で解決されます。
o Initiates the dialog by sending an INVITE request to the SRS. The dialog is established according to the normal procedures for establishing an INVITE-initiated dialog as specified in [RFC3261].
o INVITE要求をSRSに送信してダイアログを開始します。ダイアログは、[RFC3261]で指定されているINVITEで開始されるダイアログを確立するための通常の手順に従って確立されます。
o Includes in the INVITE an indication that the session is established for the purpose of recording the associated media.
o INVITEに、関連するメディアを記録する目的でセッションが確立されているという指示を含めます。
o Includes an SDP attribute of "a=sendonly" for each media line if the Replicated Media is to be started immediately, or includes "a=inactive" if it is not ready to transmit the media.
o 複製されたメディアをすぐに開始する場合は、各メディア行の「a = sendonly」のSDP属性を含めます。メディアを送信する準備ができていない場合は、「a = inactive」を含めます。
o Replicates the media streams that are to be recorded and transmits the media to the SRS.
o 記録されるメディアストリームを複製し、メディアをSRSに送信します。
The Recording Session may replicate all media associated with the CS or only a subset.
記録セッションは、CSに関連付けられたすべてのメディアまたはサブセットのみを複製できます。
When the SRS initiates the media Recording Session with the SRC, it performs the following actions:
SRSがSRCとのメディア録音セッションを開始すると、次のアクションが実行されます。
o Is provisioned with a Unified Resource Identifier (URI) for the SRC; the URI is resolved through normal [RFC3263] procedures.
o SRCの統合リソース識別子（URI）でプロビジョニングされます。 URIは通常の[RFC3263]手順で解決されます。
o Sends an INVITE request to the SRC.
o INVITE要求をSRCに送信します。
o Includes in the INVITE an indication that the session is established for the purpose of recording the associated media.
o INVITEに、関連するメディアを記録する目的でセッションが確立されているという指示を含めます。
o Identifies the sessions that are to be recorded. The actual mechanism of the identification depends on SRC policy.
o 記録されるセッションを識別します。識別の実際のメカニズムは、SRCポリシーによって異なります。
o Includes an SDP attribute of "a=recvonly" for each media line if the Recording Session is to be started immediately, or includes "a=inactive" if it is not ready to receive the media.
o レコーディングセッションをすぐに開始する場合は、各メディアラインに「a = recvonly」のSDP属性を含めます。メディアを受信する準備ができていない場合は、「a = inactive」を含めます。
If the SRS does not have prior knowledge of what media streams are available to be recorded, it can make use of an offerless INVITE, which allows the SRC to make the initial SDP offer.
SRSは、どのメディアストリームが記録に利用できるかについて事前の知識がない場合、オファーのないINVITEを利用できます。これにより、SRCが最初のSDPオファーを行うことができます。
The SRS or the SRC may pause the recording by changing the SDP direction attribute to "inactive" and resume the recording by changing the direction back to "recvonly" or "sendonly".
SRSまたはSRCは、SDP方向属性を「非アクティブ」に変更して記録を一時停止し、方向を「recvonly」または「sendonly」に戻すことで記録を再開できます。
In a basic session involving only audio, there are typically two audio/RTP streams between the two UAs involved in transporting media in each direction. When recording this media, the two streams may be mixed or not mixed at the SRC before being transmitted to the SRS. In the case when they are not mixed, two separate streams are sent to the SRS, and the SDP offer sent to the SRS must describe two separate media streams. In the mixed case, a single mixed media stream is sent to the SRS.
オーディオのみを含む基本的なセッションでは、通常、各方向のメディアの転送に関与する2つのUA間に2つのオーディオ/ RTPストリームがあります。このメディアを記録するとき、SRSに送信される前に、2つのストリームがSRCで混合される場合と混合されない場合があります。それらが混合されていない場合、2つの別々のストリームがSRSに送信され、SRSに送信されるSDPオファーは2つの別々のメディアストリームを記述する必要があります。混合の場合、単一の混合メディアストリームがSRSに送信されます。
The CS and the RS are negotiated separately using the standard SDP offer/answer exchange which may result in the SRC having to perform media transcoding between the two sessions. If the SRC is not capable of performing media transcoding it may limit the media formats in the offer to the SRS depending on what media is negotiated on the CS or may limit what it includes in the offer on the CS if it has prior knowledge of the media formats supported by the SRS. However typically the SRS will be a more capable device which can provide a wide range of media format options to the SRC and may also be able to make use of a media transcoder as detailed in [RFC5369].
CSとRSは、標準のSDPオファー/アンサー交換を使用して別々にネゴシエートされるため、SRCは2つのセッション間でメディアトランスコーディングを実行する必要があります。 SRCがメディアトランスコーディングを実行できない場合、CSでネゴシエートされるメディアに応じて、SRSへのオファーのメディアフォーマットを制限するか、CSの事前知識がある場合は、CSのオファーに含める内容を制限します。 SRSでサポートされているメディア形式。ただし、通常、SRSは、SRCに幅広いメディアフォーマットオプションを提供でき、[RFC5369]で詳述されているようにメディアトランスコーダーを利用できる、より機能的なデバイスです。
Session recording may be a regulatory requirement in certain communication environments. Such environments may impose a requirement generally known as "lossless recording". An overall solution for lossless recording may involve multiple layers of solutions. Individual aspects of the solutions may range from administering networks for appropriate QoS, reliable transmission of recorded media, and perhaps certain SIPREC protocol-level capabilities in SRC and SRS.
セッションの記録は、特定の通信環境では規制要件になる場合があります。このような環境では、一般に「ロスレスレコーディング」と呼ばれる要件が課される場合があります。ロスレス録音の全体的なソリューションには、ソリューションの複数のレイヤーが含まれる場合があります。ソリューションの個々の側面は、適切なQoS、記録されたメディアの信頼性の高い伝送、およびおそらくSRCとSRSの特定のSIPRECプロトコルレベルの機能のためのネットワークの管理に及ぶ場合があります。
The metadata model is defined in [REC-METADATA].
メタデータモデルは[REC-METADATA]で定義されています。
The SRS obtains session recording metadata from the SRC. The metadata is transported via SIP-based mechanisms as specified in [REC-PROTOCOL]
SRSは、SRCからセッション記録メタデータを取得します。メタデータは、[REC-PROTOCOL]で指定されているSIPベースのメカニズムを介して転送されます
It is also possible that metadata is transported via non-SIP-based mechanisms, but these are considered out of scope.
メタデータがSIP以外のメカニズムを介して転送される可能性もありますが、これらは範囲外と見なされます。
It is also possible to have an RS session without the metadata; in that case, the SRS will be receiving the metadata by some other means or not at all.
メタデータなしでRSセッションを行うことも可能です。その場合、SRSは他の方法でメタデータを受信するか、まったく受信しません。
Typically, a user that is involved in a session that is to be recorded is notified by an announcement at the beginning of the session or may receive some warning tones within the media. However, SIPREC enables an indication that the call is being recorded to be included in the SIP requests and responses associated with that CS.
通常、記録されるセッションに関与しているユーザーは、セッションの開始時にアナウンスによって通知されるか、メディア内でいくつかの警告音を受け取る場合があります。ただし、SIPRECを使用すると、そのCSに関連付けられたSIP要求と応答に、通話が記録されているという表示を含めることができます。
The SRC provides the notification to all SIP UAs for which it is replicating received media for the purpose of recording. If the SRC is acting as a SIP endpoint, as described in Section 3.1.2, then it also provides a notification to the local user.
SRCは、記録の目的で受信したメディアを複製しているすべてのSIP UAに通知を提供します。セクション3.1.2で説明されているように、SRCがSIPエンドポイントとして機能している場合は、ローカルユーザーにも通知を提供します。
During the initial session establishment or during an established session, a recording-aware UA may provide an indication of its preference with regard to recording the media in the CS. The mechanisms for this are specified in [REC-PROTOCOL]
最初のセッションの確立中または確立されたセッション中に、記録認識UAは、CSでのメディアの記録に関する優先度の表示を提供できます。このメカニズムは[REC-PROTOCOL]で指定されています
This document has no actions for IANA. This document mentions SIP/SDP extensions. The associated IANA considerations are addressed in [REC-PROTOCOL], which defines them.
このドキュメントには、IANAに対するアクションはありません。このドキュメントでは、SIP / SDP拡張について説明します。関連するIANAの考慮事項は、それらを定義する[REC-PROTOCOL]で対処されます。
The Recording Session is fundamentally a standard SIP dialog and media session and therefore makes use of existing SIP security mechanisms for securing the Recording Session and Recording Metadata.
録音セッションは基本的に標準のSIPダイアログおよびメディアセッションであるため、録音セッションおよび録音メタデータを保護するために既存のSIPセキュリティメカニズムを利用します。
The intended use of this architecture is only for the case where the users are aware that they are being recorded, and the architecture provides the means for the SRC to notify users that they are being recorded.
このアーキテクチャの使用目的は、ユーザーが記録されていることをユーザーが認識している場合に限られ、このアーキテクチャは、SRCがユーザーに記録されていることを通知する手段を提供します。
This architectural solution is not intended to support lawful intercept, which in contrast requires that users are not informed.
このアーキテクチャソリューションは、合法的傍受をサポートすることを目的としていません。これに対して、ユーザーに通知する必要はありません。
It is the responsibility of the SRS to protect the Replicated Media and Recording Metadata once it has been received and archived. The stored content must be protected using a cipher at least as strong (or stronger) than the original content; however, the mechanism for protecting the storage and retrieval from the SRS is out of scope of this work. The keys used to store the data must also be securely maintained by the SRS and should only be released, securely, to authorized parties. How to secure these keys, properly authorize a receiving party, or securely distribute the keying material is also out of scope of this work.
レプリケートされたメディアとレコーディングメタデータを受け取ってアーカイブした後、それらを保護するのはSRSの責任です。保存されたコンテンツは、少なくとも元のコンテンツと同じかそれよりも強い（または強い）暗号を使用して保護する必要があります。ただし、SRSからの保存と取得を保護するメカニズムは、この作業の範囲外です。データの保存に使用されるキーも、SRSによって安全に維持する必要があり、承認された関係者にのみ安全にリリースする必要があります。これらのキーを保護する方法、受信者を適切に承認する方法、またはキーイング資料を安全に配布する方法も、この作業の範囲外です。
Protection of the RS should not be weaker than protection of the CS and may need to be stronger because the media is retransmitted (allowing more possibility for interception). This applies to both the signaling and media paths.
RSの保護は、CSの保護よりも弱くてはならず、メディアが再送信されるため、より強力にする必要があります（傍受の可能性が高くなります）。これは、シグナリングパスとメディアパスの両方に適用されます。
It is essential that the SRC will authenticate the SRS because the client must be certain that it is recording on the right recording system. It is less important that the SRS authenticate the SRC, but implementations must have the ability to perform mutual authentication.
クライアントはSRSが正しいレコーディングシステムでレコーディングしていることを確認する必要があるため、SRCがSRSを認証することが不可欠です。 SRSがSRCを認証することはそれほど重要ではありませんが、実装には相互認証を実行する機能が必要です。
In some environments, it is desirable to not decrypt and re-encrypt the media. This means the same media encryption key is negotiated and used within the CS and RS. If for any reason the media are decrypted on the CS and are re-encrypted on the RS, a new key must be used.
一部の環境では、メディアを復号化および再暗号化しないことが望ましいです。つまり、同じメディア暗号化キーがネゴシエートされ、CSとRS内で使用されます。何らかの理由でメディアがCSで復号化され、RSで再暗号化される場合は、新しいキーを使用する必要があります。
The retrieval mechanism for media recorded by this protocol is out of scope. Implementations of retrieval mechanisms should consider the security implications carefully, as the retriever is not usually a party to the call that was recorded. Retrievers should be authenticated carefully. The cryptosuites on the retrieval should be no less strong than those used on the RS and may need to be stronger.
このプロトコルで記録されたメディアの取得メカニズムは範囲外です。検索メカニズムは通常、記録された通話の当事者ではないため、検索メカニズムの実装では、セキュリティへの影響を慎重に検討する必要があります。レトリバーは慎重に認証する必要があります。取得の暗号化スイートは、RSで使用される暗号化スイートよりも強力である必要があり、より強力である必要がある場合があります。
Thanks to John Elwell, Brian Rosen, Alan Johnson, Cullen Jennings, Hadriel Kaplan, Henry Lum, Paul Kyzivat, Parthasarathi R., Ram Mohan R., Charles Eckel, Friso Feenstra, and Dave Higton for their significant contributions and assistance with this document and working group. Also, thanks to all the members of the SIPREC WG mailing list for providing valuable input to this work.
John Elwell、Brian Rosen、Alan Johnson、Cullen Jennings、Hadriel Kaplan、Henry Lum、Paul Kyzivat、Parthasarathi R.、Ram Mohan R.、Charles Eckel、Friso Feenstra、およびDave Higtonに、このドキュメントに対する多大な貢献と支援に感謝します。そしてワーキンググループ。また、この作業に貴重な情報を提供してくれたSIPREC WGメーリングリストのすべてのメンバーに感謝します。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)", RFC 6341, August 2011.
[RFC6341] Rehor、K.、Portman、L.、Hutton、A.、and R. Jain、 "Use Cases and Requirements for SIP-Based Media Recording（SIPREC）"、RFC 6341、August 2011。
[REC-METADATA] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", Work in Progress, February 2014.
[REC-METADATA] Ravindranath、R.、Ravindran、P。、およびP. Kyzivat、「Session Initiation Protocol（SIP）Recording Metadata」、Work in Progress、2014年2月。
[REC-PROTOCOL] Portman, L., Lum, H., Eckel, C., Johnston, A., and A. Hutton, "Session Recording Protocol", Work in Progress, February 2014.
[REC-PROTOCOL]ポートマンL.、ラムH.、エッケルC.、ジョンストンA.、およびA.ハットン、「Session Recording Protocol」、Work in Progress、2014年2月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353] Rosenberg、J。、「Session Initiation Protocol（SIP）との会議のフレームワーク」、RFC 4353、2006年2月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、「会議状態用のSession Initiation Protocol（SIP）イベントパッケージ」、RFC 4575、2006年8月。
[RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.
[RFC5567] Melanchuk、T。、「An Architectural Framework for Media Server Control」、RFC 5567、2009年6月。
[RFC5369] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol (SIP)", RFC 5369, October 2008.
[RFC5369] Camarillo、G。、「Session Initiation Protocol（SIP）によるトランスコーディングのフレームワーク」、RFC 5369、2008年10月。
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[RFC2804] IABおよびIESG、「盗聴に関するIETFポリシー」、RFC 2804、2000年5月。
Authors' Addresses
著者のアドレス
Andrew Hutton (editor) Unify Hofmannstrasse 51 81359 Munich Germany
Andrew Hutton（編集者）Unify Hofmannstrasse 51 81359ミュンヘンドイツ
EMail: andrew.hutton@unify.com
Leon Portman (editor) NICE Systems 8 Hapnina Ra'anana 43017 Israel
Leon Portman（編集者）Nice Systems ৮喘息
EMail: leon.portman@gmail.com
Rajnish Jain IPC Systems 777 Commerce Drive Fairfield, CT 06825 USA
Rajnish Jain IPC Systems 777 Commerce Drive Fairfield、CT 06825 USA
EMail: rajnish.jain@outlook.com
Ken Rehor Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Ken Rehor Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134-1706 USA
EMail: krehor@cisco.com