[要約] RFC 7865は、SIP通信の録音メタデータに関する標準仕様です。このRFCの目的は、SIPセッションの録音に関する情報を提供し、録音データの管理と解釈を容易にすることです。
Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 7865 Cisco Systems
Category: Standards Track P. Ravindran
ISSN: 2070-1721 Nokia Networks
P. Kyzivat
Huawei
May 2016
Session Initiation Protocol (SIP) Recording Metadata
セッション開始プロトコル（SIP）記録メタデータ
Abstract
概要
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format.
セッションの録音は、コールセンターや金融取引組織などの多くの通信環境で重要な要件です。これらの環境の一部では、規制、コンプライアンス、および消費者保護の理由から、すべての通話を記録する必要があります。セッションの記録は、通常、メディアストリームのコピーを記録デバイスに送信することによって実行されます。このドキュメントでは、Session Recording Server（SRS）で表示されるメタデータモデルとレコーディングメタデータ形式について説明します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc7865.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7865で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 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. Terminology .....................................................3
3. Definitions .....................................................4
4. Metadata Model ..................................................5
5. Recording Metadata Format from SRC to SRS .......................6
5.1. XML Data Format ............................................7
5.1.1. Namespace ...........................................7
5.1.2. 'recording' Element .................................7
6. Recording Metadata Classes ......................................7
6.1. Recording Session ..........................................8
6.1.1. Attributes ..........................................8
6.1.2. Linkages ............................................9
6.2. Communication Session Group ................................9
6.2.1. Attributes .........................................10
6.2.2. Linkages ...........................................10
6.3. Communication Session .....................................11
6.3.1. Attributes .........................................11
6.3.2. Linkages ...........................................12
6.4. CS-RS Association .........................................13
6.4.1. Attributes .........................................14
6.4.2. Linkages ...........................................14
6.5. Participant ...............................................14
6.5.1. Attributes .........................................15
6.5.2. Linkages ...........................................15
6.6. Participant-CS Association ................................16
6.6.1. Attributes .........................................17
6.6.2. Linkages ...........................................17
6.7. Media Stream ..............................................18
6.7.1. Attributes .........................................18
6.7.2. Linkages ...........................................19
6.8. Participant-Stream Association ............................19
6.8.1. Attributes .........................................20
6.8.2. Linkages ...........................................20
6.9. Syntax of XML Elements for Date and Time ..................21
6.10. Format of Unique ID ......................................21
6.11. Metadata Version Indicator ...............................21
7. Recording Metadata Snapshot Request Format .....................22
8. SIP Recording Metadata Examples ................................23
8.1. Complete SIP Recording Metadata Example ...................23
8.2. Partial Update of Recording Metadata XML Body .............25
9. XML Schema Definition for Recording Metadata ...................26
10. Security Considerations .......................................30
11. IANA Considerations ...........................................31
11.1. SIP Recording Metadata Schema Registration ...............31
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Acknowledgements ..................................................34
Authors' Addresses ................................................34
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document focuses on the recording metadata, which describes the Communication Session (CS). The document describes a metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format, the requirements for which are described in [RFC6341] and the architecture for which is described in [RFC7245].
セッションの録音は、コールセンターや金融取引組織などの多くの通信環境で重要な要件です。これらの環境の一部では、規制、コンプライアンス、および消費者保護の理由から、すべての通話を記録する必要があります。セッションの記録は、通常、メディアストリームのコピーを記録デバイスに送信することによって実行されます。このドキュメントでは、通信セッション（CS）を説明する記録メタデータに焦点を当てています。このドキュメントでは、Session Recording Server（SRS）で表示されるメタデータモデルと記録メタデータ形式について説明します。その要件は[RFC6341]で説明されており、そのアーキテクチャは[RFC7245]で説明されています。
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]. This document only uses these key words when referencing normative statements in existing RFCs.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。このドキュメントでは、既存のRFCの規範的ステートメントを参照するときにのみこれらのキーワードを使用します。
Metadata model: A metadata model is an abstract representation of metadata using a Unified Modeling Language (UML) [UML] class diagram.
メタデータモデル：メタデータモデルは、統一モデリング言語（UML）[UML]クラス図を使用したメタデータの抽象的な表現です。
Metadata classes: Each block in the model represents a class. A class is a construct that is used as a blueprint to create instances (called "objects") of itself. The description of each class also has a representation of its attributes in a second compartment below the class name.
メタデータクラス：モデルの各ブロックはクラスを表します。クラスは、それ自体のインスタンス（「オブジェクト」と呼ばれる）を作成するための青写真として使用される構造です。各クラスの説明には、クラス名の下の2番目のコンパートメントにその属性の表現もあります。
Attributes: Attributes represent the elements listed in each of the classes. The attributes of a class are listed in the second compartment below the class name. Each instance of a class conveys values for the attributes of that class. These values get added to the recording's metadata.
属性：属性は、各クラスにリストされている要素を表します。クラスの属性は、クラス名の下の2番目のコンパートメントにリストされます。クラスの各インスタンスは、そのクラスの属性の値を伝えます。これらの値は、レコーディングのメタデータに追加されます。
Linkages: Linkages represent the relationship between the classes in the model. Each linkage represents a logical connection between classes (or objects) in class diagrams (or object diagrams). The linkages used in the metadata model of this document are associations.
リンケージ：リンケージは、モデル内のクラス間の関係を表します。各リンケージは、クラス図（またはオブジェクト図）のクラス（またはオブジェクト）間の論理接続を表します。このドキュメントのメタデータモデルで使用されるリンケージは関連です。
This document also refers to the terminology defined in [RFC6341].
このドキュメントは、[RFC6341]で定義されている用語にも言及しています。
Metadata is the information that describes recorded media and the CS to which they relate. The diagram below shows a model for metadata as viewed by an SRS.
メタデータは、記録されたメディアとそれらが関連するCSを説明する情報です。以下の図は、SRSによって表示されるメタデータのモデルを示しています。
+-------------------------------+ 1..*
| Recording Session (RS) |----+
+-------------------------------+ |
| 1..* | 1..* |
| | |
| | 0..* |
| +-----------------+ |
+------------+ | | Communication | |
| CS-RS | | | Session Group | |
| Association|--+ | (CS-Group) | |
| | | +-----------------+ |
+------------+ | | 0..1 |
| | |
| 0..* | 1..* |
+-------------------------------+ |
| Communication Session (CS) | |
| | |
+-------------------------------+ |
| 1..* | 0..1 |
+-----+ | |
| | 0..* | 0..* | 0..*
| +-------------+ receives +----------------+ |
| | Participant |----------| Media Stream |--+
| | |0..* 0..*| |
| | | | |
| | | | |
| | | sends | |
| | |----------| |
| | |1.* 0..*| |
| +-------------+ +----------------+
| | |
| | |
| +------------------------+------------+
| |
| |
| +------------------+ +----------------------+
| |Participant-CS | | Participant-Stream |
+-----------| Association | | Association |
| | | |
+------------------+ +----------------------+
The metadata model is a class diagram in UML. The model describes the structure of metadata in general by showing the classes, their attributes, and the relationships among the classes. Each block in the model above represents a class. The linkages between the classes represent the relationships, which can be associations or compositions. The metadata is conveyed from the Session Recording Client (SRC) to the SRS.
メタデータモデルは、UMLのクラス図です。モデルは、クラス、その属性、およびクラス間の関係を示すことにより、一般的にメタデータの構造を記述します。上記のモデルの各ブロックはクラスを表します。クラス間のリンケージは、関連または構成であり得る関係を表します。メタデータは、Session Recording Client（SRC）からSRSに伝達されます。
The model allows metadata describing CSs to be communicated to the SRS as a series of snapshots, each representing the state as seen by a single SRC at a particular instant in time. Metadata changes from one snapshot to another reflect changes in what is being recorded. For example, if a participant joins a conference, then the SRC sends the SRS a snapshot of metadata having that participant information (with attributes like (Name, AoR) tuple and associate-time). (Note: "AoR" means "Address-of-Record".)
このモデルを使用すると、CSを説明するメタデータを一連のスナップショットとしてSRSに伝達できます。それぞれのスナップショットは、特定の時点で単一のSRCから見た状態を表します。あるスナップショットから別のスナップショットへのメタデータの変更は、記録されているものの変更を反映しています。たとえば、参加者が会議に参加した場合、SRCはSRSに、その参加者情報（（名前、AoR）タプルや関連付け時間などの属性を持つ）を持つメタデータのスナップショットを送信します。 （注：「AoR」は「レコードのアドレス」を意味します。）
Some of the metadata is not required to be conveyed explicitly from the SRC to the SRS, if it can be obtained contextually by the SRS (e.g., from SIP or Session Description Protocol (SDP) signaling). For example, the 'label' attribute within the 'stream' XML element references an SDP "a=label" attribute that identifies an m-line within the Recording Session (RS) SDP. The SRS would learn the media properties from the media line.
メタデータの一部は、SRSによってコンテキストで取得できる場合（SIPやセッション記述プロトコル（SDP）シグナリングなどから）、SRCからSRSに明示的に伝達する必要はありません。たとえば、 'stream' XML要素内の 'label'属性は、レコーディングセッション（RS）SDP内のm行を識別するSDP "a = label"属性を参照します。 SRSはメディアラインからメディアプロパティを学習します。
This section gives an overview of the recording metadata format. Some data from the metadata model is assumed to be made available to the SRS through SDP [RFC4566], and therefore this data is not represented in the XML document format specified in this document. SDP attributes describe different media formats like audio and video. The other metadata attributes, such as participant details, are represented in a new recording-specific XML document of type 'application/rs-metadata+xml'. The SDP "label" attribute [RFC4574] provides an identifier by which a metadata XML document can refer to a specific media description in the SDP sent from the SRC to the SRS.
このセクションでは、記録メタデータ形式の概要について説明します。メタデータモデルの一部のデータは、SDP [RFC4566]を介してSRSで利用できるようになっていると想定されているため、このデータは、このドキュメントで指定されているXMLドキュメント形式では表されません。 SDP属性は、オーディオやビデオなどのさまざまなメディア形式を記述します。参加者の詳細など、その他のメタデータ属性は、「application / rs-metadata + xml」タイプの新しい録音固有のXMLドキュメントで表されます。 SDP「ラベル」属性[RFC4574]は、メタデータXMLドキュメントがSRCからSRSに送信されるSDP内の特定のメディア記述を参照できる識別子を提供します。
The XML document format can be used to represent either the complete metadata or a partial update to the metadata. The latter includes only elements that have changed compared to the previously reported metadata.
XMLドキュメント形式を使用して、メタデータ全体またはメタデータの部分的な更新を表すことができます。後者には、以前に報告されたメタデータと比較して変更された要素のみが含まれます。
Every recording metadata XML document sent from the SRC to the SRS contains a 'recording' element. The 'recording' element acts as a container for all other elements in this XML document. A 'recording' object is an XML document. It has the XML declaration and contains an encoding declaration in the XML declaration, e.g., "<?xml version="1.0" encoding="UTF-8"?>". If the charset parameter of the MIME content type declaration is present and it is different from the encoding declaration, the charset parameter takes precedence.
SRCからSRSに送信されるすべての記録メタデータXMLドキュメントには、「記録」要素が含まれています。 「recording」要素は、このXMLドキュメント内の他のすべての要素のコンテナとして機能します。 「記録」オブジェクトはXMLドキュメントです。 XML宣言があり、XML宣言にエンコーディング宣言が含まれています（例： "<？xml version =" 1.0 "encoding =" UTF-8 "？>"）。 MIMEコンテンツタイプ宣言のcharsetパラメータが存在し、それがエンコーディング宣言と異なる場合、charsetパラメータが優先されます。
Every application conforming to this specification MUST accept the UTF-8 character encoding to ensure minimal interoperability.
この仕様に準拠するすべてのアプリケーションは、相互運用性を最小限に抑えるために、UTF-8文字エンコーディングを受け入れる必要があります。
Syntax and semantic errors in an XML document should be reported to the originator, using application-specific mechanisms.
XMLドキュメントの構文エラーと意味エラーは、アプリケーション固有のメカニズムを使用して発信者に報告する必要があります。
With the following URN, this document defines a new namespace URI for elements defined herein:
次のURNを使用して、このドキュメントは、ここで定義された要素の新しい名前空間URIを定義します。
urn:ietf:params:xml:ns:recording:1
The 'recording' element MUST contain an xmlns namespace attribute with a value of urn:ietf:params:xml:ns:recording:1. Exactly one 'recording' element MUST be present in every recording metadata XML document.
「recording」要素には、値がurn：ietf：params：xml：ns：recording：1のxmlns名前空間属性が含まれている必要があります。正確に1つの「recording」要素が、すべてのレコーディングメタデータXMLドキュメントに存在する必要があります。
A 'recording' element MAY contain a 'dataMode' element indicating whether the XML document is a complete document or a partial update. If no 'dataMode' element is present, then the default value is "complete".
「recording」要素には、XMLドキュメントが完全なドキュメントであるか部分的な更新であるかを示す「dataMode」要素が含まれる場合があります。 「dataMode」要素が存在しない場合、デフォルト値は「complete」です。
This section describes each class of the metadata model and the attributes of each class. This section also describes how different classes are linked and the XML element for each of them.
このセクションでは、メタデータモデルの各クラスと各クラスの属性について説明します。このセクションでは、さまざまなクラスがリンクされる方法と、それぞれのXML要素についても説明します。
+-------------------------------+
| Recording Session (RS) |
+-------------------------------+
| | 1..* 0..*
| start-time |-------------- Media Stream
| end-time |
| |
| |
+-------------------------------+
| 1..* | 1..*
| |
| 0..* | 0..*
Communication Communication
Session (CS) Session Group (CS-Group)
Each instance of an RS class, namely the RS object, represents a SIP session created between an SRC and SRS for the purpose of recording a CS.
RSクラスの各インスタンス、つまりRSオブジェクトは、CSを記録する目的でSRCとSRSの間に作成されたSIPセッションを表します。
The RS object is represented in the XML schema using the 'recording' element, which in turn relies on the SIP/SDP session with which the XML document is associated to provide the attributes of the RS element.
RSオブジェクトは 'recording'要素を使用してXMLスキーマで表されます。これは、XMLドキュメントが関連付けられているSIP / SDPセッションに依存して、RS要素の属性を提供します。
An RS class has the following attributes:
RSクラスには次の属性があります。
o start-time - Represents the start time of an RS object.
o start-time-RSオブジェクトの開始時間を表します。
o end-time - Represents the end time of an RS object.
o end-time-RSオブジェクトの終了時間を表します。
'start-time' and 'end-time' attribute values are derivable from the Date header (if present in the SIP message) in the RS. In cases where the Date header is not present, 'start-time' is derivable from the time at which the SRS receives the notification of the SIP message to set up the RS, and 'end-time' is derivable from the time at which the SRS receives a disconnect on the RS SIP dialog.
'start-time'および 'end-time'属性値は、RSのDateヘッダー（SIPメッセージに存在する場合）から導出できます。 Dateヘッダーが存在しない場合、「start-time」は、SRSがSIPメッセージの通知を受信してRSをセットアップする時間から導出でき、「end-time」は、 SRSは、RS SIPダイアログで切断を受信します。
Each instance of an RS has:
RSの各インスタンスには次のものが含まれます。
o Zero or more instances of CS-Groups.
o CSグループの0個以上のインスタンス。
o Zero or more instances of CS objects.
o CSオブジェクトの0個以上のインスタンス。
o Zero or more instances of MediaStream objects.
o MediaStreamオブジェクトのゼロ個以上のインスタンス。
Zero instances of CSs and CS-Groups in a 'recording' element are allowed to accommodate persistent recording scenarios. A persistent RS is a SIP dialog that is set up between the SRC and the SRS, even before any CS is set up. The metadata sent from the SRC to the SRS when the persistent RS SIP dialog is set up may not have any CS (and the related CS-Group) elements in the XML, as there may not be a session that is associated to the RS yet. For example, a phone acting as an SRC can set up an RS with the SRS, possibly even before the phone is part of a CS. Once the phone joins a CS, the same RS would be used to convey the CS metadata.
「recording」要素内のCSおよびCSグループのインスタンスがゼロの場合、永続的な記録シナリオに対応できます。永続的RSは、CSがセットアップされる前であっても、SRCとSRSの間にセットアップされるSIPダイアログです。 RSに関連付けられているセッションがないため、XMLにCS（および関連するCS-Group）要素が含まれていない可能性があります。 。たとえば、SRCとして機能している電話は、おそらく電話がCSの一部である前でも、SRSでRSを設定できます。電話がCSに参加すると、同じRSがCSメタデータの伝達に使用されます。
Recording Session (RS)
| 1..*
|
| 0..*
+-------------------------------+
| Communication Session |
| Group (CS-Group) |
+-------------------------------+
| group_id |
| associate-time |
| disassociate-time |
| |
+-------------------------------+
| 0..1
|
| 1..*
Communication Session (CS)
One instance of a CS-Group class, namely the CS-Group object, provides association or grouping of all related CSs. For example, in a contact center flow, a call can get transferred to multiple agents. Each of these can trigger the setup of a new CS. In cases where the SRC knows the related CSs, it can group them using the CS-Group element. The CS-Group object is represented in the XML schema using the 'group' element.
CS-Groupクラスの1つのインスタンス、つまりCS-Groupオブジェクトは、関連するすべてのCSの関連付けまたはグループ化を提供します。たとえば、コンタクトセンターフローでは、コールが複数のエージェントに転送されることがあります。これらのそれぞれは、新しいCSのセットアップをトリガーできます。 SRCが関連するCSを知っている場合は、CS-Group要素を使用してそれらをグループ化できます。 CS-Groupオブジェクトは、「group」要素を使用してXMLスキーマで表されます。
A CS-Group has the following attributes:
CSグループには次の属性があります。
o group_id - This attribute groups different CSs that are related. The SRC (or the SRS) is responsible for ensuring the uniqueness of 'group_id' in cases where multiple SRCs interact with the same SRS. The mechanism by which the SRC groups the CS is outside the scope of this document.
o group_id-この属性は、関連するさまざまなCSをグループ化します。 SRC（またはSRS）は、複数のSRCが同じSRSと対話する場合に「group_id」の一意性を保証する責任があります。 SRCがCSをグループ化するメカニズムは、このドキュメントの範囲外です。
o associate-time - This is the time when a grouping is formed. The rules that determine how a grouping of different CS objects is done by the SRC are outside the scope of this document.
o 準時間-これは、グループ化が形成される時間です。さまざまなCSオブジェクトのグループ化がSRCによってどのように行われるかを決定するルールは、このドキュメントの範囲外です。
o disassociate-time - 'disassociate-time' for the CS-Group is calculated by the SRC as the time when the grouping ends.
o disassociate-time-CSグループの「disassociate-time」は、グループ化が終了する時間としてSRCによって計算されます。
The linkages between a CS-Group class and other classes are associations. A CS-Group is associated with the RS and CS in the following manner:
CS-Groupクラスと他のクラス間のリンケージは関連です。 CSグループは、次の方法でRSおよびCSに関連付けられます。
o There are one or more RS objects per CS-Group.
o CSグループごとに1つ以上のRSオブジェクトがあります。
o Each CS-Group object has to be associated with one or more RSs. Here, each RS can be set up by the potentially different SRCs.
o 各CS-Groupオブジェクトは、1つ以上のRSに関連付けられている必要があります。ここで、各RSは潜在的に異なるSRCによってセットアップできます。
o There are one or more CSs per CS-Group (for example, in cases where the call is transferred). A CS cannot be associated with more than one CS-Group.
o CSグループごとに1つ以上のCSがあります（たとえば、コールが転送される場合）。 1つのCSを複数のCSグループに関連付けることはできません。
Recording Communication
Session (RS) Session Group (CS-Group)
| 1..* | 0..1
| |
| 0..* | 1..*
+-------------------------------+
| Communication Session (CS) |
+-------------------------------+
| session_id |
| sipSessionID |
| reason |
| group-ref |
| start-time |
| stop-time |
+-------------------------------+
| |
| 0..* | 0..1
| |
| 0..* | 0..*
Participant Media Stream
A CS class and its object in the metadata model represent the CS and its properties as seen by the SRC. The CS object is represented in the XML schema using the 'session' element.
メタデータモデルのCSクラスとそのオブジェクトは、SRCから見たCSとそのプロパティを表します。 CSオブジェクトは、「session」要素を使用してXMLスキーマで表されます。
A CS class has the following attributes:
CSクラスには次の属性があります。
o session_id - This attribute is used to uniquely identify an instance of a CS object, namely the 'session' XML element within the metadata XML document. 'session_id' is generated using the rules mentioned in Section 6.10.
o session_id-この属性は、CSオブジェクトのインスタンス、つまりメタデータXMLドキュメント内の「セッション」XML要素を一意に識別するために使用されます。 「session_id」は、セクション6.10で説明されているルールを使用して生成されます。
o reason - This represents the reason why a CS was terminated. The value for this attribute is derived from the SIP Reason header [RFC3326] of the CS. There MAY be multiple instances of the 'reason' XML element inside a 'session' element. The 'reason' XML element has 'protocol' as an attribute, which indicates the protocol from which the reason string is derived. The default value for the 'protocol' attribute is "SIP". The 'reason' element can be derived from a SIP Reason header in the CS.
o reason-これは、CSが終了した理由を表します。この属性の値は、CSのSIP Reasonヘッダー[RFC3326]から取得されます。 「セッション」要素内に「理由」XML要素の複数のインスタンスが存在する場合があります。 'reason' XML要素には、属性として 'protocol'があります。これは、理由文字列の派生元のプロトコルを示します。 「プロトコル」属性のデフォルト値は「SIP」です。 「reason」要素は、CSのSIP Reasonヘッダーから派生できます。
o sipSessionID - This attribute carries a SIP Session-ID as defined in [SessionID]. Each CS object can have zero or more 'sipSessionID' elements. More than one 'sipSessionID' attribute may be present in a CS. For example, if three participants -- A, B, and C -- are in a conference that has a focus acting as an SRC, the metadata sent from the SRC to the SRS will likely have three 'sipSessionID' elements that correspond to the SIP dialogs that the focus has with each of the three participants.
o sipSessionID-この属性は、[SessionID]で定義されているSIPセッションIDを伝達します。各CSオブジェクトには、0個以上の「sipSessionID」要素を含めることができます。 CSには複数の「sipSessionID」属性が存在する場合があります。たとえば、A、B、Cの3人の参加者が、SRCとして機能するフォーカスを持つ会議に参加している場合、SRCからSRSに送信されるメタデータには、対応する3つの「sipSessionID」要素が含まれる可能性があります。フォーカスが3人の参加者のそれぞれと持っているSIPダイアログ。
o group-ref - A 'group-ref' attribute MAY be present to indicate the group (identified by 'group_id') to which the enclosing session belongs.
o group-ref-囲んでいるセッションが属するグループ（「group_id」で識別される）を示す「group-ref」属性が存在する場合があります。
o start-time - This optional attribute represents the start time of the CS as seen by the SRC.
o start-time-このオプション属性は、SRCから見たCSの開始時間を表します。
o stop-time - This optional attribute represents the stop time of the CS as seen by the SRC.
o stop-time-このオプション属性は、SRCから見たCSの停止時間を表します。
This document does not specify attributes relating to what should happen to a recording of a CS after it has been delivered to the SRS (e.g., how long to retain the recording, what access controls to apply). The SRS is assumed to behave in accordance with its local policy. The ability of the SRC to influence this policy is outside the scope of this document. However, if there are implementations where the SRC desires to specify its own policy preferences, this information could be sent as extension data attached to the CS.
このドキュメントでは、CSのレコーディングがSRSに配信された後に何が起こるかに関する属性（たとえば、レコーディングを保持する期間、適用するアクセス制御）は指定していません。 SRSは、そのローカルポリシーに従って動作すると想定されています。このポリシーに影響を与えるSRCの機能は、このドキュメントの範囲外です。ただし、SRCが独自のポリシー設定を指定したい実装がある場合、この情報はCSに添付された拡張データとして送信できます。
A CS is linked to the CS-Group, participant, MediaStream (MS), and RS classes by using the association relationship. The association between the CS and the participant allows the following:
CSは、関連付け関係を使用して、CSグループ、参加者、MediaStream（MS）、およびRSクラスにリンクされます。 CSと参加者の関連付けにより、次のことが可能になります。
o A CS will have zero or more participants.
o CSには0人以上の参加者がいます。
o A participant is associated with zero or more CSs. This includes participants who are not directly part of any CS. An example of such a case is participants in a pre-mixed media stream. The SRC may have knowledge of such participants but not have any signaling relationship with them. This might arise if one participant in a CS is a conference focus. To summarize, even if the SRC does not have direct signaling relationships with all participants in a CS, it should nevertheless create a participant object for each participant that it knows about.
o 参加者は0個以上のCSに関連付けられています。これには、CSに直接参加していない参加者も含まれます。このようなケースの例は、事前に混合されたメディアストリームの参加者です。 SRCはそのような参加者の知識を持っている可能性がありますが、それらとのシグナリング関係はありません。これは、CSの1人の参加者が会議の焦点である場合に発生する可能性があります。要約すると、SRCがCSのすべての参加者と直接の信号関係を持っていない場合でも、それがわかっている参加者ごとに参加者オブジェクトを作成する必要があります。
o The model also allows participants in a CS that are not participants in the media. An example is the identity of a Third Party Call Control (3pcc) that has initiated a CS to two or more participants in the CS. Another example is the identity of a conference focus. Of course, a focus is probably in the media, but since it may only be there as a mixer, it may not report itself as a participant in any of the media streams.
o このモデルでは、メディアの参加者ではないCSの参加者も許可されます。たとえば、CSの2人以上の参加者に対してCSを開始したサードパーティコール制御（3pcc）のIDです。別の例は、会議の焦点のアイデンティティです。もちろん、フォーカスはおそらくメディアにありますが、ミキサーとしてのみ存在する可能性があるため、メディアストリームの参加者として自分自身を報告することはできません。
The association between the CS and the media stream allows the following:
CSとメディアストリームの関連付けにより、次のことが可能になります。
o A CS will have zero or more streams.
o CSには0個以上のストリームがあります。
o A stream can be associated with at most one CS. A stream in a persistent RS is not required to be associated with any CS before the CS is created, and hence the zero association is allowed.
o ストリームは最大で1つのCSに関連付けることができます。永続的RSのストリームは、CSが作成される前にCSに関連付ける必要がないため、ゼロ関連付けが許可されます。
The association between the CS and the RS allows the following:
CSとRS間の関連付けにより、次のことが可能になります。
o Each instance of an RS has zero or more instances of CS objects.
o RSの各インスタンスには、CSオブジェクトのインスタンスが0個以上あります。
o Each CS has to be associated with one or more RSs. Each RS can be potentially set up by different SRCs.
o 各CSは1つ以上のRSに関連付けられている必要があります。各RSは、異なるSRCによってセットアップされる可能性があります。
1..* 0..*
Recording Communication
Session ----------+---------- Session
|
|
|
+-----------------------+
| CS-RS Association |
| |
+-----------------------+
| associate-time |
| disassociate-time |
| session_id |
+-----------------------+
The CS-RS Association class describes the association of a CS to an RS for a period of time. A single CS may be associated with different RSs (perhaps by different SRCs) and may be associated and dissociated several times.
CS-RSアソシエーションクラスは、一定期間のCSとRSの関連付けを記述します。単一のCSは異なるRSに関連付けられている可能性があり（おそらく異なるSRCによって）、複数回関連付けられ、関連付けが解除される場合があります。
The CS-RS Association class is represented in XML using the 'sessionrecordingassoc' XML element.
CS-RS Associationクラスは、「sessionrecordingassoc」XML要素を使用してXMLで表されます。
The CS-RS Association class has the following attributes:
CS-RS Associationクラスには、次の属性があります。
o associate-time - associate-time is calculated by the SRC as the time it sees a CS associated to an RS.
o 準時間-準時間は、RSに関連付けられたCSを認識する時間としてSRCによって計算されます。
o disassociate-time - disassociate-time is calculated by the SRC as the time it sees a CS disassociate from an RS.
o disassociate-time-disassociate-timeは、CSがRSから分離されているのをSRCが確認した時間としてSRCによって計算されます。
o session_id - Each instance of this class MUST have a 'session_id' attribute that identifies the CS to which this association belongs.
o session_id-このクラスの各インスタンスには、この関連付けが属するCSを識別する「session_id」属性が必要です。
The CS-RS Association class is linked to the CS and RS classes.
CS-RSアソシエーションクラスは、CSおよびRSクラスにリンクされています。
Communication Session (CS)
| 0..*
|
| 0..*
+-------------------------------+
| Participant |
+-------------------------------+
| nameID |
| participant_id |
| |
+-------------------------------+
| 0..* 1..* |
receives| |sends
| 0..* 0..* |
Media Stream
A participant class and its objects have information about a device that is part of a CS and/or contributes/consumes media stream(s) belonging to a CS.
参加者クラスとそのオブジェクトは、CSの一部であるデバイスに関する情報を持っているか、CSに属するメディアストリームを提供/消費しています。
The participant object is represented in the XML schema using the 'participant' element.
参加者オブジェクトは、「participant」要素を使用してXMLスキーマで表されます。
A participant class has two attributes:
参加者クラスには2つの属性があります。
o nameID - This attribute is a list of (Name, AoR) tuples. An AoR (Section 6 of [RFC3261]) can be either a SIP/SIPS/tel URI ("SIPS" means "SIP Secure"; the tel URI is discussed in [RFC3966]), a Fully Qualified Domain Name (FQDN), or an IP address. For example, the AoR may be drawn from the From header field or the P-Asserted-Identity header [RFC3325] field. The SRC's local policy is used to decide where to draw the AoR from. The Name parameter represents the participant name (SIP display name) or dialed number (when known). Multiple tuples are allowed for cases where a participant has more than one AoR. For example, a P-Asserted-Identity header can have both SIP and tel URIs.
o nameID-この属性は、（名前、AoR）タプルのリストです。 AoR（[RFC3261]のセクション6）は、SIP / SIPS / tel URI（「SIPS」は「SIPセキュア」を意味します。telURIは[RFC3966]で説明されています）、完全修飾ドメイン名（FQDN）、またはIPアドレス。たとえば、AoRはFromヘッダーフィールドまたはP-Asserted-Identityヘッダー[RFC3325]フィールドから取得できます。 SRCのローカルポリシーは、どこからAoRを引き出すかを決定するために使用されます。 Nameパラメーターは、参加者名（SIP表示名）またはダイヤル番号（既知の場合）を表します。参加者が複数のAoRを持っている場合、複数のタプルが許可されます。たとえば、P-Asserted-Identityヘッダーには、SIP URIとtel URIの両方を含めることができます。
o participant_id - This attribute is used to identify the 'participant' XML element within the XML document. It is generated using the rules mentioned in Section 6.10. This attribute MUST be used for all references to a participant within a CS-Group, and MAY be used to reference the same participant more globally.
o participant_id-この属性は、XMLドキュメント内の「participant」XML要素を識別するために使用されます。セクション6.10で説明したルールを使用して生成されます。この属性は、CSグループ内の参加者へのすべての参照に使用する必要があり、同じ参加者をよりグローバルに参照するために使用できます（MAY）。
This document does not specify other attributes relating to participants (e.g., participant role, participant type). An SRC that has information regarding these attributes can provide this information as part of extension data to the 'participant' XML element from the SRC to the SRS.
このドキュメントでは、参加者に関連するその他の属性（参加者の役割、参加者のタイプなど）は指定していません。これらの属性に関する情報を持つSRCは、SRCからSRSへの「参加者」XML要素への拡張データの一部としてこの情報を提供できます。
The participant class is linked to the MS and CS classes by using an association relationship. The association between the participant and the MS allows the following:
参加者クラスは、関連付け関係を使用してMSおよびCSクラスにリンクされます。参加者とMS間の関連付けにより、次のことが可能になります。
o A participant will receive zero or more media streams.
o 参加者は0個以上のメディアストリームを受け取ります。
o A participant will send zero or more media streams. (The same participant provides multiple streams, e.g., audio and video.)
o 参加者は0個以上のメディアストリームを送信します。 （同じ参加者が複数のストリーム（オーディオやビデオなど）を提供します。）
o A media stream will be received by zero or more participants. It is possible, though perhaps unlikely, that a stream is generated but sent only to the SRC and SRS, not to any participant -- for example, in conferencing where all participants are on hold and the SRC is collocated with the focus. Also, a media stream may be received by multiple participants (e.g., "whisper" calls, side conversations).
o メディアストリームは、0人以上の参加者によって受信されます。可能性は低いですが、ストリームが生成されてもSRCとSRSにのみ送信され、参加者には送信されない可能性があります。たとえば、すべての参加者が保留になっていて、SRCがフォーカスと共に配置されている会議では。また、メディアストリームは複数の参加者によって受信される場合があります（たとえば、「ささやき」通話、サイドカンバセーション）。
o A media stream will be sent by one or more participants (pre-mixed streams).
o メディアストリームは、1人以上の参加者（事前混合ストリーム）によって送信されます。
An example of a case where a participant receives zero or more streams is where a supervisor may have a side conversation with an agent while the agent converses with a customer.
参加者が0個以上のストリームを受信する場合の例は、エージェントが顧客と会話しているときに、スーパーバイザがエージェントとサイドカンバセーションを行う場合です。
1..* 0..*
Communication
Session -----------+----------- Participant
|
|
|
+---------------------------+
| Participant-CS Association|
| |
| |
+---------------------------+
| associate-time |
| disassociate-time |
| param |
| participant_id |
| session_id |
+---------------------------+
The Participant-CS Association class describes the association of a participant to a CS for a period of time. A participant may be associated to and dissociated from a CS several times (for example, connecting to a conference, then disconnecting, then connecting again).
Participant-CS Associationクラスは、一定期間のCSへの参加者の関連付けを記述します。参加者は、CSに数回関連付けられたり、CSから切り離されたりすることがあります（たとえば、会議に接続してから切断し、再度接続するなど）。
The Participant-CS Association object is represented in the XML schema using the 'participantsessionassoc' element.
Participant-CS Associationオブジェクトは、「participantsessionassoc」要素を使用してXMLスキーマで表されます。
The Participant-CS Association class has the following attributes:
Participant-CS Associationクラスには、次の属性があります。
o associate-time - associate-time is calculated by the SRC as the time it sees a participant associated to a CS.
o 準時間-準時間は、CSに関連付けられた参加者を確認する時間としてSRCによって計算されます。
o disassociate-time - disassociate-time is calculated by the SRC as the time it sees a participant disassociate from a CS. It is possible that a given participant can have multiple associate times / disassociate times within a given communication session.
o disassociate-time-disassociate-timeは、SRCが参加者がCSとの関連付けを解除したと見なす時間として計算されます。特定の参加者が特定の通信セッション内で複数の関連付け時間/関連付け解除時間を持つことが可能です。
o param - The capabilities here are those that are indicated in the Contact header as defined in Section 9 of [RFC3840]. For example, in a CS (which can be a conference), you can have participants who are playing the role of "focus". These participants do not contribute to media in the CS; however, they switch the media received from one participant to every other participant in the CS. Indicating the capabilities of the participants (here, "focus") would be useful for the recorder to learn about these kinds of participants. The capabilities are represented using the 'param' XML element in the metadata. The 'param' XML element encoding defined in [RFC4235] is used to represent the capability attributes in metadata. Each participant may have zero or more capabilities. A participant may use different capabilities, depending on the role it plays at a particular instance -- for example, if a participant moves across different CSs (e.g., due to transfer) or is simultaneously present in different CSs with different roles.
o param-ここでの機能は、[RFC3840]のセクション9で定義されているContactヘッダーに示されている機能です。たとえば、CS（会議の場合もあります）では、「フォーカス」の役割を果たす参加者を含めることができます。これらの参加者は、CSのメディアに貢献していません。ただし、CSの1人の参加者から受信したメディアを他のすべての参加者に切り替えます。参加者の能力（ここでは「フォーカス」）を示すことは、レコーダーがこれらの種類の参加者について学ぶのに役立ちます。機能は、メタデータの「param」XML要素を使用して表されます。 [RFC4235]で定義されている 'param' XML要素エンコーディングは、メタデータの機能属性を表すために使用されます。各参加者は、0個以上の機能を持つことができます。参加者は、特定のインスタンスで果たす役割に応じて、異なる機能を使用する場合があります。たとえば、参加者が異なるCS間を移動した場合（転送など）、または異なる役割を持つ異なるCSに同時に存在する場合などです。
o participant_id - This attribute identifies the participant to which this association belongs.
o participant_id-この属性は、この関連付けが属する参加者を識別します。
o session_id - This attribute identifies the session to which this association belongs.
o session_id-この属性は、この関連付けが属するセッションを識別します。
The Participant-CS Association class is linked to the participant and CS classes.
Participant-CS Associationクラスは、参加者とCSクラスにリンクされています。
Participant
| 0..* 1..* |
receives| |sends
| 0..* 0..* |
+-------------------------+
| Media Stream |
0..1 0..* +-------------------------+
Communication ------------| |
Session | label |
| content-type |
| stream_id |
| session_id |
+-------------------------+
0..* |
|
|
1..* |
Recording Session
A MS class (and its objects) has the properties of media as seen by the SRC and sent to the SRS. Different snapshots of MS objects may be sent whenever there is a change in media (e.g., a direction change, like pause/resume, codec change, and/or participant change).
MSクラス（およびそのオブジェクト）には、SRCによって認識され、SRSに送信されるメディアのプロパティがあります。メディアに変更がある場合（たとえば、一時停止/再開、コーデックの変更、参加者の変更などの方向の変更）、MSオブジェクトのさまざまなスナップショットが送信される場合があります。
The MS object is represented in the XML schema using the 'stream' element.
MSオブジェクトは、 'stream'要素を使用してXMLスキーマで表されます。
A MS class has the following attributes:
MSクラスには次の属性があります。
o label - The 'label' attribute within the 'stream' XML element references an SDP "a=label" attribute that identifies an m-line within the RS SDP. That m-line carries the media stream from the SRC to the SRS.
o label-'stream' XML要素内の 'label'属性は、RS SDP内のm行を識別するSDP "a = label"属性を参照します。そのm行は、SRCからSRSにメディアストリームを伝送します。
o content-type - The content of a MS element will be described in terms of the "a=content" attribute defined in Section 5 of [RFC4796]. If the SRC wishes to convey the content-type to the SRS, it does so by including an "a=content" attribute with the m-line in the RS SDP.
o content-type-MS要素のコンテンツは、[RFC4796]のセクション5で定義されている「a = content」属性に関して記述されます。 SRCがコンテンツタイプをSRSに伝えたい場合は、RS SDPのm行に「a = content」属性を含めることでそれを行います。
o stream_id - Each 'stream' element has a unique 'stream_id' attribute that helps to uniquely identify the stream. This identifier is generated using the rules mentioned in Section 6.10.
o stream_id-各「stream」要素には、ストリームを一意に識別するのに役立つ一意の「stream_id」属性があります。この識別子は、セクション6.10で説明されているルールを使用して生成されます。
o session_id - This attribute associates the stream with a specific 'session' element.
o session_id-この属性は、ストリームを特定の「セッション」要素に関連付けます。
The metadata model can include media streams that are not being delivered to the SRS. For example, an SRC offers audio and video towards an SRS that accepts only audio in response. The metadata snapshots sent from the SRC to the SRS can continue to indicate the changes to the video stream as well.
メタデータモデルには、SRSに配信されていないメディアストリームを含めることができます。たとえば、SRCは、応答としてオーディオのみを受け入れるSRSに向けてオーディオとビデオを提供します。 SRCからSRSに送信されるメタデータスナップショットは、ビデオストリームへの変更も示し続けることができます。
A MS class is linked to the participant and CS classes by using the association relationship. Details regarding associations with the participant are described in Section 6.5. Details regarding associations with the CS are mentioned in Section 6.3.
MSクラスは、関連付け関係を使用して参加者とCSクラスにリンクされます。参加者との関連付けに関する詳細は、セクション6.5で説明されています。 CSとの関連付けに関する詳細は、セクション6.3で説明されています。
+-------------------------+
| Participant-Stream |
| Association |
+-------------------------+ +-----------Participant
| associate-time | | 0..* | 1..* |
| disassociate-time |---+ receives| |sends
| send | | 0..* | 0..* |
| recv | | | |
| participant_id | | | |
+-------------------------+ | | |
+-----------Media Stream
A Participant-Stream Association class describes the association of a participant to a MS for a period of time, as a sender or as a receiver, or both.
パーティシパントストリームアソシエーションクラスは、送信者または受信者、あるいはその両方として、一定期間のMSへの参加者の関連付けを記述します。
This class is represented in XML using the 'participantstreamassoc' element.
このクラスは、「participantstreamassoc」要素を使用してXMLで表されます。
A Participant-Stream Association class has the following attributes:
参加者とストリームの関連付けクラスには、次の属性があります。
o associate-time - This attribute indicates the time a participant started contributing to a MS.
o 準時間-この属性は、参加者がMSへの貢献を開始した時間を示します。
o disassociate-time - This attribute indicates the time a participant stopped contributing to a MS.
o disassociate-time-この属性は、参加者がMSへの貢献を停止した時間を示します。
o send - This attribute indicates whether a participant is contributing to a stream or not. This attribute has a value that points to a stream represented by its unique_id. The presence of this attribute indicates that a participant is contributing to a stream. If a participant stops contributing to a stream due to changes in a CS, a snapshot MUST be sent from the SRC to the SRS with no 'send' element for that stream.
o send-この属性は、参加者がストリームに貢献しているかどうかを示します。この属性には、unique_idで表されるストリームを指す値があります。この属性の存在は、参加者がストリームに貢献していることを示します。 CSの変更が原因で参加者がストリームへの貢献を停止した場合、そのストリームの「送信」要素なしで、SRCからSRSにスナップショットを送信する必要があります。
o recv - This attribute indicates whether a participant is receiving a media stream or not. This attribute has a value that points to a stream represented by its unique_id. The presence of this attribute indicates that a participant is receiving a stream. If the participant stops receiving a stream due to changes in a CS (like hold), a snapshot MUST be sent from the SRC to the SRS with no 'recv' element for that stream.
o recv-この属性は、参加者がメディアストリームを受信しているかどうかを示します。この属性には、unique_idで表されるストリームを指す値があります。この属性の存在は、参加者がストリームを受信していることを示しています。 CSの変更（保留など）が原因で参加者がストリームの受信を停止した場合、そのストリームの 'recv'要素なしでSRCからSRSにスナップショットを送信する必要があります。
o participant_id - This attribute points to the participant with which a 'stream' element is associated.
o participant_id-この属性は、「ストリーム」要素が関連付けられている参加者を指します。
The 'participantstreamassoc' XML element is used to represent a participant association with a stream. The 'send' and 'recv' XML elements MUST be used to indicate whether a participant is contributing to a stream or receiving a stream. There MAY be multiple instances of the 'send' and 'recv' XML elements inside a 'participantstreamassoc' element. If a metadata snapshot is sent with a 'participantstreamassoc' element that does not have any 'send' and 'recv' elements, it means that the participant is neither contributing to any streams nor receiving any streams.
'participantstreamassoc' XML要素は、ストリームとの参加者の関連付けを表すために使用されます。 'send'および 'recv' XML要素を使用して、参加者がストリームに貢献しているか、ストリームを受信しているかを示す必要があります。 「participantstreamassoc」要素内に「send」および「recv」XML要素の複数のインスタンスが存在する場合があります。 「send」および「recv」要素のない「participantstreamassoc」要素を使用してメタデータスナップショットが送信された場合、それは参加者がストリームに貢献しておらず、ストリームも受信していないことを意味します。
The Participant-Stream Association class is linked to the participant and MS classes.
パーティシパントストリームアソシエーションクラスは、パーティシパントとMSクラスにリンクされています。
The XML elements 'associate-time', 'disassociate-time', 'start-time', and 'stop-time' contain strings representing the date and time. The value of these elements MUST follow the Instant Messaging and Presence Protocol (IMPP) date-time format [RFC3339]. Timestamps that contain "T" or "Z" MUST use the capitalized forms.
XML要素「associate-time」、「disassociate-time」、「start-time」、および「stop-time」には、日付と時刻を表す文字列が含まれています。これらの要素の値は、インスタントメッセージングおよびプレゼンスプロトコル（IMPP）の日時形式[RFC3339]に従う必要があります。 「T」または「Z」を含むタイムスタンプは、大文字の形式を使用する必要があります。
As a security measure, the 'timestamp' element MUST be included in all tuples, unless the exact time of the status change cannot be determined.
セキュリティ対策として、ステータス変更の正確な時刻を特定できない場合を除き、すべてのタプルに「timestamp」要素を含める必要があります。
A unique_id is generated in two steps:
unique_idは2つのステップで生成されます。
o The Universally Unique Identifier (UUID) is created using any of the procedures mentioned in Sections 4.3, 4.4, and 4.5 of [RFC4122]. The algorithm MUST ensure that it does not use any potentially personally identifying information to generate the UUIDs. If implementations are using a Name-Based UUID as defined in Section 4.3 of [RFC4122], a namespace ID generated using the guidance in Section 4.2 or 4.5 of [RFC4122] might be a good choice.
o [Universally Unique Identifier（UUID）]は、[RFC4122]のセクション4.3、4.4、および4.5で言及されている手順のいずれかを使用して作成されます。アルゴリズムは、個人を特定する可能性のある情報を使用してUUIDを生成しないようにする必要があります。 [RFC4122]のセクション4.3で定義されている名前ベースのUUIDを実装が使用している場合は、[RFC4122]のセクション4.2または4.5のガイダンスを使用して生成された名前空間IDが適切な選択である可能性があります。
o The UUID is encoded using base64 as defined in [RFC4648].
o [RFC4648]で定義されているように、UUIDはbase64を使用してエンコードされます。
The above-mentioned unique_id mechanism SHOULD be used for each metadata element. Multiple SRCs can refer to the same element/UUID (how each SRC learns the UUID here is beyond the scope of this document). If two SRCs use the same UUID, they MUST retain the UUID/element mapping. If the SRS detects that a UUID is mapped to more than one element at any point in time, it MUST treat this as an error. For example, the SRS may choose to reject or ignore the portions of metadata where it detects that the same UUID is mapped to an element that is different than the expected element (the SRS learns the mapped UUID when it sees an element for the first time in a metadata instance).
上記のunique_idメカニズムは、メタデータ要素ごとに使用する必要があります（SHOULD）。複数のSRCが同じ要素/ UUIDを参照できます（各SRCがここでUUIDを学習する方法は、このドキュメントの範囲外です）。 2つのSRCが同じUUIDを使用する場合、それらはUUID /要素のマッピングを保持する必要があります。 SRSがUUIDがいつでも複数の要素にマッピングされていることを検出した場合、SRSはこれをエラーとして処理する必要があります。たとえば、SRSは、メタデータの一部を拒否または無視することを選択できます。この場合、同じUUIDが予期された要素とは異なる要素にマップされていることが検出されます（SRSは、初めて要素を検出したときに、マップされたUUIDを学習しますメタデータインスタンス内）。
The Metadata version is defined to help the SRC and SRS know the version of metadata XML schema used. SRCs and SRSs that support this specification MUST use version 1 in the namespace (urn:ietf:params:xml:ns:recording:1) in all the XML documents. Implementations may not interoperate if the version implemented by the sender is not known by the receiver. No negotiation of versions is provided. The version number has no significance, although documents that update or obsolete this document (possibly including drafts of such documents) should include a higher version number if the metadata XML schema changes.
メタデータバージョンは、SRCおよびSRSが使用されるメタデータXMLスキーマのバージョンを認識できるように定義されています。この仕様をサポートするSRCおよびSRSは、すべてのXMLドキュメントの名前空間（urn：ietf：params：xml：ns：recording：1）でバージョン1を使用する必要があります。送信者が実装したバージョンが受信者に知られていない場合、実装は相互運用できない場合があります。バージョンのネゴシエーションは提供されていません。バージョン番号は重要ではありませんが、メタデータXMLスキーマが変更された場合、このドキュメントを更新または廃止するドキュメント（そのようなドキュメントのドラフトを含む可能性があります）には、より高いバージョン番号を含める必要があります。
The SRS can explicitly request a metadata snapshot from the SRC. To request a metadata snapshot, the SRS MUST send a SIP request message with an XML document having the namespace urn:ietf:params:xml:ns:recording:1. The XML document has the following elements:
SRSは、SRCからメタデータスナップショットを明示的に要求できます。メタデータスナップショットを要求するには、SRSは、名前空間urn：ietf：params：xml：ns：recording：1を持つXMLドキュメントを含むSIP要求メッセージを送信する必要があります。 XMLドキュメントには次の要素があります。
o A 'requestsnapshot' XML element MUST be present as the top-level element in the XML document.
o 'requestsnapshot' XML要素は、XMLドキュメントの最上位要素として存在する必要があります。
o A 'requestreason' XML element that indicates the reason (as a string) for requesting the snapshot MAY be present as a child XML element of 'requestsnapshot'.
o スナップショットを要求する理由を（文字列として）示す「requestreason」XML要素は、「requestsnapshot」の子XML要素として存在してもよい（MAY）。
The example below shows a metadata snapshot request from the SRS.
以下の例は、SRSからのメタデータスナップショット要求を示しています。
<?xml version="1.0" encoding="UTF-8"?>
<requestsnapshot xmlns='urn:ietf:params:xml:ns:recording:1'>
<requestreason xml:lang="it">SRS internal error</requestreason>
</requestsnapshot>
Example Metadata Snapshot Request from SRS to SRC
SRSからSRCへのメタデータスナップショット要求の例
The following example provides all the tuples involved in the recording metadata XML body.
次の例は、レコーディングメタデータのXML本文に含まれるすべてのタプルを提供します。
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<group group_id="7+OTCyoxTmqmqyA/1weDAg==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
<!-- Standardized extension -->
<call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
<supervisor>sip:alice@atlanta.com</supervisor>
</call-center>
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2</sipSessionID>
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</session>
<participant participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:bob@biloxi.com">
<name xml:lang="it">Bob</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<participant participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Paul@biloxi.com">
<name xml:lang="it">Paul</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>98</label>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>99</label>
</stream>
<sessionrecordingassoc session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</sessionrecordingassoc>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
Example Metadata Snapshot from SRC to SRS
SRCからSRSへのメタデータスナップショットの例
The following example provides a partial update in the recording metadata XML body for the above example. The example has a snapshot that carries the disassociate-time for a participant from a session.
次の例は、上記の例の記録メタデータXMLボディの部分的な更新を示しています。この例には、セッションからの参加者の関連付け解除時間を伝えるスナップショットがあります。
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:bob@biloxi.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
Partial Update of SIP Recording Example XML Body
SIP録音サンプルXML本文の部分更新
This section defines the XML schema for the recording metadata document.
このセクションでは、記録メタデータドキュメントのXMLスキーマを定義します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:recording:1"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:recording:1"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang -->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="https://www.w3.org/2001/xml.xsd"/>
<xs:element name="recording" type="tns:recording"/>
<xs:complexType name="recording">
<xs:sequence>
<xs:element name="datamode" type="tns:dataMode"
minOccurs="0"/>
<xs:element name="group" type="tns:group"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="session" type="tns:session"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participant" type="tns:participant"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="stream" type="tns:stream"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="sessionrecordingassoc"
type="tns:sessionrecordingassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participantsessionassoc"
type="tns:participantsessionassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participantstreamassoc"
type="tns:participantstreamassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="group">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="group_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="session">
<xs:sequence>
<xs:element name="sipSessionID" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="reason" type="tns:reason"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="group-ref" type="xs:base64Binary"
minOccurs="0" maxOccurs="1"/>
<xs:element name="start-time" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:element name="stop-time" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="sessionrecordingassoc">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="nameID" type="tns:nameID"
maxOccurs='unbounded'/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participantsessionassoc">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="param" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participantstreamassoc">
<xs:sequence>
<xs:element name="send" type="xs:base64Binary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="recv" type="xs:base64Binary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="stream">
<xs:sequence>
<xs:element name="label" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="stream_id" type="xs:base64Binary"
use="required"/>
<xs:attribute name="session_id" type="xs:base64Binary"/>
</xs:complexType>
<xs:simpleType name="dataMode">
<xs:restriction base="xs:string">
<xs:enumeration value="complete"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="nameID">
<xs:sequence>
<xs:element name="name" type ="tns:name" minOccurs="0"
maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="aor" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="name">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="reason">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute type="xs:short" name="cause" use="required"/>
<xs:attribute type="xs:string" name="protocol" default="SIP"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="requestsnapshot" type="tns:requestsnapshot"/>
<xs:complexType name="requestsnapshot">
<xs:sequence>
<xs:element name="requestreason" type="tns:name"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
</xs:complexType>
</xs:schema>
This document describes an extensive set of metadata that may be recorded by the SRS. Most of the metadata could be considered private data. The procedures mentioned in the Security Considerations section of [RFC7866] MUST be followed by the SRC and the SRS for mutual authentication and to protect the content of the metadata in the RS.
このドキュメントでは、SRSによって記録される可能性がある広範なメタデータセットについて説明します。ほとんどのメタデータはプライベートデータと見なすことができます。 [RFC7866]のセキュリティに関する考慮事項セクションで言及されている手順は、相互認証とRSのメタデータの内容を保護するためにSRCとSRSが従わなければなりません（MUST）。
An SRC MAY, by policy, choose to limit the parts of the metadata sent to the SRS for recording. Also, the policy of the SRS might not require recording all the metadata it receives. For the sake of data minimization, the SRS MUST NOT record additional metadata that is not explicitly required by local policy. Metadata in storage needs to be provided with a level of security that is comparable to that of the recording session.
SRCは、ポリシーにより、記録のためにSRSに送信されるメタデータの部分を制限することを選択できます。また、SRSのポリシーでは、受信したすべてのメタデータを記録する必要がない場合があります。データの最小化のために、SRSはローカルポリシーで明示的に必要とされない追加のメタデータを記録してはなりません（MUST NOT）。ストレージ内のメタデータには、レコーディングセッションと同等のセキュリティレベルを提供する必要があります。
This specification registers a new XML namespace and a new XML schema.
この仕様は、新しいXML名前空間と新しいXMLスキーマを登録します。
URI: urn:ietf:params:xml:ns:recording:1
Registrant Contact: IETF SIPREC working group, Ram Mohan R (rmohanr@cisco.com)
登録者の連絡先：IETF SIPRECワーキンググループ、Ram Mohan R（rmohanr@cisco.com）
XML: The registered XML schema is contained in Section 9.
XML：登録されたXMLスキーマはセクション9に含まれています。
Its first line is <?xml version="1.0" encoding="UTF-8"?>, and its last line is </xs:schema>.
最初の行は<？xml version = "1.0" encoding = "UTF-8"？>で、最後の行は</ xs：schema>です。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G。およびC. Newman、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<http://www.rfc-editor.org/info/rfc3339 >。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）でのユーザーエージェント機能の表示」、RFC 3840、DOI 10.17487 / RFC3840、2004年8月、<http：// www .rfc-editor.org / info / rfc3840>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「A Universally Unique Identifier（UUID）URN Namespace」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<http：//www.rfc- editor.org/info/rfc4122>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, DOI 10.17487/RFC4574, August 2006, <http://www.rfc-editor.org/info/rfc4574>.
[RFC4574] Levin、O。およびG. Camarillo、「セッション記述プロトコル（SDP）ラベル属性」、RFC 4574、DOI 10.17487 / RFC4574、2006年8月、<http://www.rfc-editor.org/info/ rfc4574>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description Protocol (SDP) Content Attribute", RFC 4796, DOI 10.17487/RFC4796, February 2007, <http://www.rfc-editor.org/info/rfc4796>.
[RFC4796] Hautakorpi、J。およびG. Camarillo、「Session Description Protocol（SDP）Content Attribute」、RFC 4796、DOI 10.17487 / RFC4796、2007年2月、<http://www.rfc-editor.org/info/ rfc4796>。
[RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. Hutton, "Session Recording Protocol", RFC 7866, DOI 10.17487/RFC7866, May 2016, <http://www.rfc-editor.org/info/rfc7866>.
[RFC7866]ポートマン、L。、ラム、H。、エド、エッケル、C。、ジョンストン、A。、およびA.ハットン、「Session Recording Protocol」、RFC 7866、DOI 10.17487 / RFC7866、2016年5月、<http ：//www.rfc-editor.org/info/rfc7866>。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325]ジェニングス、C。、ピーターソン、J。、およびM.ワトソン、「信頼できるネットワーク内のアサートされたIDのためのセッション開始プロトコル（SIP）のプライベート拡張」、RFC 3325、DOI 10.17487 / RFC3325、2002年11月、<http ：//www.rfc-editor.org/info/rfc3325>。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <http://www.rfc-editor.org/info/rfc3326>.
[RFC3326] Schulzrinne、H.、Oran、D。、およびG. Camarillo、「セッション開始プロトコル（SIP）の理由ヘッダーフィールド」、RFC 3326、DOI 10.17487 / RFC3326、2002年12月、<http：// www .rfc-editor.org / info / rfc3326>。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966] Schulzrinne、H.、「電話番号のtel URI」、RFC 3966、DOI 10.17487 / RFC3966、2004年12月、<http://www.rfc-editor.org/info/rfc3966>。
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, DOI 10.17487/RFC4235, November 2005, <http://www.rfc-editor.org/info/rfc4235>.
[RFC4235] Rosenberg、J.、Schulzrinne、H。、およびR. Mahy、編、「セッション開始プロトコル（SIP）のINVITEで開始されるダイアログイベントパッケージ」、RFC 4235、DOI 10.17487 / RFC4235、2005年11月、 <http://www.rfc-editor.org/info/rfc4235>。
[RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, <http://www.rfc-editor.org/info/rfc6341>.
[RFC6341] Rehor、K.、Ed。、Portman、L.、Ed。、Hutton、A.、and R. Jain、 "Use Cases and Requirements for SIP-Based Media Recording（SIPREC）"、RFC 6341、DOI 10.17487 / RFC6341、2011年8月、<http://www.rfc-editor.org/info/rfc6341>。
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, "An Architecture for Media Recording Using the Session Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 2014, <http://www.rfc-editor.org/info/rfc7245>.
[RFC7245]ハットン、A。、編、ポートマン、L。、編、ジャイナ、R。、およびK.リホル、「セッション開始プロトコルを使用したメディア録音のアーキテクチャ」、RFC 7245、DOI 10.17487 / RFC7245、 2014年5月、<http://www.rfc-editor.org/info/rfc7245>。
[SessionID] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End-to-End Session Identification in IP-Based Multimedia Communication Networks", Work in Progress, draft-ietf-insipid-session-id-22, April 2016.
[SessionID] Jones、P.、Salgueiro、G.、Pearce、C。、およびP. Giralt、「IPベースのマルチメディア通信ネットワークにおけるエンドツーエンドのセッション識別」、進行中の作業、draft-ietf-insipid- session-id-22、2016年4月。
[UML] Object Management Group, "OMG Unified Modeling Language (UML)", 2011, <http://www.omg.org/spec/UML/2.4/>.
[UML]オブジェクト管理グループ、「OMG統一モデリング言語（UML）」、2011年、<http://www.omg.org/spec/UML/2.4/>。
Acknowledgements
謝辞
Thanks to John Elwell, Henry Lum, Leon Portman, De Villiers de Wet, Andrew Hutton, Deepanshu Gautam, Charles Eckel, Muthu Arul Mozhi Perumal, Michael Benenson, Hadriel Kaplan, Brian Rosen, Scott Orton, Ofir Roth, Mary Barnes, Ken Rehor, Gonzalo Salgueiro, Yaron Pdut, Alissa Cooper, Stephen Farrell, and Ben Campbell for their valuable comments and inputs.
John Elwell、Henry Lum、Leon Portman、De Villiers de Wet、Andrew Hutton、Deepanshu Gautam、Charles Eckel、Muthu Arul Mozhi Perumal、Michael Benenson、Hadriel Kaplan、Brian Rosen、Scott Orton、Ofir Roth、Mary Barnes、Ken Rehorに感謝します。 、貴重なコメントと意見をいただいたゴンザロサルゲイロ、ヤロンプドゥット、アリッサクーパー、スティーブンファレル、ベンキャンベル。
Thanks to Joe Hildebrand, Peter Saint-Andre, and Matt Miller for helping in writing the XML schema, and to Martin Thomson for validating the XML schema and providing comments on the same.
XMLスキーマの作成を支援してくれたJoe Hildebrand、Peter Saint-Andre、およびMatt Millerに感謝します。また、XMLスキーマを検証し、コメントを提供してくれたMartin Thomsonに感謝します。
Authors' Addresses
著者のアドレス
Ram Mohan Ravindranath Cisco Systems Cessna Business Park Bangalore, Karnataka India
Ram Mohan Rabindranath Cisco Systems Sasna Business Park Bangalore、Karnataka India
Email: rmohanr@cisco.com
Parthasarathi Ravindran Nokia Networks Bangalore, Karnataka India
Parthasarathi Ravindran Nokia Networks Bangalore、Karnatakaインド
Email: partha@parthasarathi.co.in
Paul Kyzivat Huawei Hudson, MA United States
Paul Kyzivat Huawei Hudson、MAアメリカ合衆国
Email: pkyzivat@alum.mit.edu