[要約] RFC 8068は、SIP通話の録音呼び出しフローに関するガイドラインです。このRFCの目的は、SIPベースの通信システムでの通話録音の実装と相互運用性を向上させることです。
Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 8068 Cisco Systems, Inc.
Category: Informational P. Ravindran
ISSN: 2070-1721 Nokia Networks
P. Kyzivat
Huawei
February 2017
Session Initiation Protocol (SIP) Recording Call Flows
セッション開始プロトコル（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 lists call flows with metadata snapshots sent from a Session Recording Client (SRC) to a Session Recording Server (SRS).
セッションの録音は、コールセンターや金融取引組織などの多くの通信環境で重要な要件です。これらの環境の一部では、規制、コンプライアンス、および消費者保護の理由から、すべての通話を記録する必要があります。セッションの記録は、通常、メディアストリームのコピーを記録デバイスに送信することによって実行されます。このドキュメントでは、Session Recording Client（SRC）からSession Recording Server（SRS）に送信されたメタデータスナップショットを含むコールフローをリストします。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc8068.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8068で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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. Overview ........................................................3
2. Terminology .....................................................3
3. Metadata XML Instances ..........................................3
3.1. Sample Call Flow ...........................................3
3.2. Call Scenarios with SRC Recording Streams without Mixing ...5
3.2.1. Example 1: Basic Call ...............................5
3.2.2. Example 2: Hold/Resume ..............................9
3.2.3. Example 3:Call Transfer (RE-INVITE and
REFER Based) .......................................12
3.2.4. Example 4: Call Disconnect .........................19
3.3. Call Scenarios with SRC Recording Streams by Mixing .......20
3.3.1. Example 1: Basic Call with SRC Mixing Streams ......20
3.3.2. Example 2: Hold/Resume with SRC Recording
by Mixing Streams ..................................23
3.3.3. Example 3: Metadata Snapshot of
Joining/Dropping of a ..............................25
3.3.4. Example 4: Call Disconnect .........................28
3.4. Call Scenarios with Persistent RS between SRC and SRS .....28
3.4.1. Example 1: Metadata Snapshot during CS
Disconnect with ....................................29
3.5. Turret-Case: Multiple CS into Single RS with Mixed
Stream ....................................................30
4. Security Considerations ........................................32
5. IANA Considerations ............................................32
6. References .....................................................33
6.1. Normative References ......................................33
6.2. Informative References ....................................33
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. [RFC7865] focuses on the recording metadata that describes the Communication Session (CS). This document lists few examples and shows the snapshots of metadata sent from a Session Recording Client (SRC) to Session Recording Server (SRS). For the sake of simplicity, the entire Session Initiation Protocol (SIP) [RFC3261] messages are not shown, instead only snippets of the SIP and Session Description Protocol (SDP) [RFC4566] messages and the XML snapshot of metadata is shown.
セッションの録音は、コールセンターや金融取引組織などの多くの通信環境で重要な要件です。これらの環境の一部では、規制、コンプライアンス、および消費者保護の理由から、すべての通話を記録する必要があります。セッションの記録は、通常、メディアストリームのコピーを記録デバイスに送信することによって実行されます。 [RFC7865]は、通信セッション（CS）を説明する記録メタデータに焦点を当てています。このドキュメントでは、いくつかの例を示し、Session Recording Client（SRC）からSession Recording Server（SRS）に送信されるメタデータのスナップショットを示します。簡単にするために、セッション開始プロトコル（SIP）[RFC3261]メッセージ全体は表示されず、代わりにSIPおよびセッション記述プロトコル（SDP）[RFC4566]メッセージのスニペットとメタデータのXMLスナップショットのみが表示されます。
The terms used in this document are defined in [RFC7865] and [RFC6341]. No new definitions are introduced in this document.
このドキュメントで使用される用語は、[RFC7865]と[RFC6341]で定義されています。このドキュメントでは、新しい定義は導入されていません。
The following subsections have examples that contain the metadata snapshot sent from the SRC to the SRS.
以下のサブセクションには、SRCからSRSに送信されたメタデータスナップショットを含む例があります。
The following is a sample call flow that shows the SRC establishing a Recording Session (RS) towards the SRS. In this example, the SRC could be part of any one of the architectures described in Section 3 of [RFC7245].
以下は、SRSがSRSへのレコーディングセッション（RS）を確立することを示すサンプルコールフローです。この例では、SRCは[RFC7245]のセクション3で説明されているいずれかのアーキテクチャの一部である可能性があります。
Figure 1: Sample Call Flow between SRC and SRS
図1：SRCとSRS間のサンプルコールフロー
SRC SRS
| |
|(1) INVITE (metadata snapshot) F1 |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
|(4) RTP |
|====================================================>|
|====================================================>|
|====================================================>|
|====================================================>|
|(5) UPDATE/RE-INVITE (metadata update 1) F2 |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
| ................................................... |
| ................................................... |
| |
|====================================================>|
|====================================================>|
|(7) UPDATE/RE-INVITE (metadata update n-1) Fn-1 |
|---------------------------------------------------->|
| 200 OK |
|<----------------------------------------------------|
For the sake of simplicity, ACKs to RE-INVITES and BYEs are not shown. The subsequent sections describe the snapshot of metadata sent from the SRC to the SRS for each of the above transactions (F1 ... Fn-1). There may be multiple UPDATES/RE-INVITES mid call to indicate snapshots of different CS changes. Depending on the architecture described in Section 3 of [RFC7245], an SRC may be an endpoint, a B2BUA, or part of the MEDIACTRL architecture or the Conference focus. The subsequent sections in this document try to list some example metadata snapshots for three major categories.
簡単にするために、RE-INVITESおよびBYEへのACKは表示されていません。以降のセクションでは、上記の各トランザクション（F1 ... Fn-1）についてSRCからSRSに送信されるメタデータのスナップショットについて説明します。異なるCS変更のスナップショットを示すために、複数のUPDATES / RE-INVITES呼び出しが途中である場合があります。 [RFC7245]のセクション3で説明されているアーキテクチャに応じて、SRCはエンドポイント、B2BUA、またはMEDIACTRLアーキテクチャまたは会議の焦点の一部になる場合があります。このドキュメントの後続のセクションでは、3つの主要なカテゴリのメタデータスナップショットの例をいくつか示します。
o The SRC recording streams unmixed to the SRS. This includes cases where the SRC is a SIP UA or B2BUA.
o SRCレコーディングストリームはSRSにミックスされません。これには、SRCがSIP UAまたはB2BUAである場合が含まれます。
o The SRC recording mixed streams to the SRS. This includes cases where the SRC is part of SIP conference model, as explained in [RFC4353].
o SRCは混合ストリームをSRSに記録します。これには、[RFC4353]で説明されているように、SRCがSIP会議モデルの一部である場合が含まれます。
o The SRC having a persistent RS with the SRS.
o SRSとの永続的なRSを持つSRC。
o Special flows like turret flows (used on financial trading floors to manage call activity). A trading turret is a specialized telephony key system that has a highly distributed switching architecture enabling parallel processing of calls. Figure 6 in Section 4 of [RFC6341] has the turret use case.
o タレットフローなどの特別なフロー（金融取引フロアでコールアクティビティを管理するために使用されます）。トレーディングタレットは、高度に分散されたスイッチングアーキテクチャを備えた特殊なテレフォニーキーシステムであり、コールの並列処理を可能にします。 [RFC6341]のセクション4の図6は、砲塔の使用例です。
Note that only those examples where metadata changes are listed in each category. For some of the call flows, the snapshots may be the same (like in case of endpoint or B2BUA acting as SRC) and the same is mentioned in the text preceding the example.
メタデータが変更される例のみが各カテゴリにリストされていることに注意してください。一部のコールフローでは、スナップショットが同じである場合があります（エンドポイントまたはB2BUAがSRCとして機能している場合など）。例の前のテキストでも同じことが説明されています。
This section describes example flows where SRC can be a SIP-UA or B2BUA as described in Section 3 of [RFC7245]. The SRS here can be a SIP-UA or an entity part of the MEDIACTRL architecture described in Section 3 of [RFC7245].
このセクションでは、[RFC7245]のセクション3で説明されているように、SRCがSIP-UAまたはB2BUAの場合のフローの例について説明します。ここでのSRSは、SIP-UAまたは[RFC7245]のセクション3で説明されているMEDIACTRLアーキテクチャのエンティティ部分です。
Basic call between two participants, Alice and Bob, who are part of the same CS. In this use case, each participant sends two media streams (audio and video). Media streams sent by each participant are received by the other participant in this use case. In this example, the SRC is a B2BUA in the path between Alice and Bob, as described in Section 3.1.1 of [RFC7245]. Below is the initial snapshot sent by SRC in the INVITE to SRS. This snapshot has the complete metadata. For the sake of simplicity, only snippets of SIP/ SDP are shown. In this example, the SRCs records the streams of each participant to SRS without mixing.
同じCSの一部である2人の参加者、アリスとボブの間の基本的なコール。この使用例では、各参加者が2つのメディアストリーム（オーディオとビデオ）を送信します。この使用例では、各参加者によって送信されたメディアストリームが他の参加者によって受信されます。この例では、[RFC7245]のセクション3.1.1で説明されているように、SRCはアリスとボブの間のパスにあるB2BUAです。以下は、SRCがINVITEでSRSに送信した初期スナップショットです。このスナップショットには完全なメタデータが含まれています。簡単にするために、SIP / SDPのスニペットのみを示しています。この例では、SRCは各参加者のストリームをミキシングせずにSRSに記録します。
Metadata snapshot for CS setup:
CSセットアップのメタデータスナップショット：
INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=00000000000000000000000000000000
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?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:alice@atlanta.com">
<name xml:lang="it">Alice</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:bob@biloxy.com">
<name xml:lang="it">Bob</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>
A call between two participants Alice and Bob is established and an RS is created for recording, as in example 1. Bob puts Alice on hold and then resumes as part of the same CS. The 'send' and 'recv' XML elements of a 'participantstreamassoc' XML element is used to indicate whether or not a participant is contributing to a media stream. SRC sends a snapshot with only the changed XML elements.
例1のように、2人の参加者アリスとボブの間の通話が確立され、RSが録音用に作成されます。ボブはアリスを保留にしてから、同じCSの一部として再開します。 「participantstreamassoc」XMLエレメントの「send」および「recv」XMLエレメントは、参加者がメディアストリームに貢献しているかどうかを示すために使用されます。 SRCは、変更されたXML要素のみを含むスナップショットを送信します。
During hold
ホールド中
Metadata snapshot for CS hold:
CSホールドのメタデータスナップショット：
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar Content-Type: application/rs-metadata Content-Disposition: recording-session
--foobar Content-Type：application / rs-metadata Content-Disposition：recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
</participantstreamassoc>
</recording>
In the above snippet, Alice with participant_id srfBElmCRp2QB23b7Mpk0w== only receives media streams and does not send any media. The same is indicated by the absence of a 'send' XML element. On the other hand, Bob (participant_id zSfPoSvdSDCmU3A3TRDxAw==) would be sending media, but he does not receive any media from Alice; therefore, the 'recv' XML element is absent in this instance.
上記のスニペットでは、participant_idがsrfBElmCRp2QB23b7Mpk0w ==のアリスはメディアストリームのみを受信し、メディアを送信しません。同じことは、「送信」XML要素がないことによって示されます。一方、ボブ（participant_id zSfPoSvdSDCmU3A3TRDxAw ==）はメディアを送信しますが、アリスからメディアを受け取りません。したがって、この例では「recv」XML要素はありません。
During resume
再開中
The snapshot now has 'send' and 'recv' XML elements for both Alice and Bob, indicating that both are receiving and sending media.
スナップショットには、AliceとBobの両方の「送信」および「受信」XML要素が含まれ、両方がメディアを受信および送信していることを示しています。
Metadata snapshot for CS resume:
CS再開のメタデータスナップショット：
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49174 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49176 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<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>i1Pz3to5hGk8fuXl+PbwCw==</recv>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
</recording>
A basic call between two participants, Alice and Bob, is connected, and SRC (a B2BUA acting as SRC as per Section 3.1.1 of [RFC7245]) has sent a snapshot as described in example 1. Transfer is initiated by one of the participants (Alice). After the transfer is completed, the SRC sends a snapshot of the participant changes to the SRS. In this transfer scenario, Alice drops out after transfer is completed, Bob and Carol get connected, and recording of media between Bob and Carol is done by the SRC. There are two flows that can happen here as described below.
2人の参加者、アリスとボブの間の基本的な通話が接続され、SRC（[RFC7245]のセクション3.1.1に従ってSRCとして機能するB2BUA）が例1で説明したようにスナップショットを送信しました。転送は、参加者（アリス）。転送が完了すると、SRCは参加者の変更のスナップショットをSRSに送信します。この転送シナリオでは、転送が完了した後にアリスが脱落し、ボブとキャロルが接続され、ボブとキャロル間のメディアの記録はSRCによって行われます。以下で説明するように、ここでは2つのフローが発生する可能性があります。
Transfer within the same session (e.g., a RE-INVITE-based transfer): Alice drops out and Carol is added to the same session. No change to the session/group element is made. A 'participantsessassoc' XML element indicating that Alice has disassociated from the CS will be present in the snapshot. A new 'participant' XML element representing Carol with mapping to the same RS SDP stream used for mapping earlier Alice's stream is sent in the snapshot. A new 'sipSessionID' XML element that has Universally Unique Identifier (UUID) tuples and that corresponds to Bob and Carol is sent in the snapshot from the SRC to the SRS. Note that one half of the session ID, that which corresponds to Bob, remains the same.
同じセッション内での転送（例：RE-INVITEベースの転送）：アリスがドロップアウトし、キャロルが同じセッションに追加されます。セッション/グループ要素は変更されません。アリスがCSとの関連付けを解除したことを示す「participantsessassoc」XML要素がスナップショットに表示されます。以前のアリスのストリームのマッピングに使用されたものと同じRS SDPストリームへのマッピングを伴うCarolを表す新しい「参加者」XML要素がスナップショットで送信されます。 Universally Unique Identifier（UUID）タプルを持ち、BobとCarolに対応する新しい「sipSessionID」XML要素が、SRCからSRSにスナップショットで送信されます。ボブに対応するセッションIDの半分は同じままであることに注意してください。
Metadata snapshot for INVITE based transfer in CS:
CSでのINVITEベースの転送のメタデータスナップショット：
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
</session>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameID aor="sip:carol@example.com">
<name xml:lang="it">Carol</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2013-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2013-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
<associate-time>2013-12-16T23:42:07Z</associate-time>
</participantstreamassoc>
</recording>
Transfer with a new session (e.g., REFER-based transfer): in this case, a new session (CS) is created and shall be part of same CS-group (done by the SRC).
新しいセッションでの転送（例：REFERベースの転送）：この場合、新しいセッション（CS）が作成され、同じCSグループの一部になります（SRCによって行われます）。
The SRC first sends an *optional* snapshot indicating disassociation of the participant from the old CS. An SRC may choose to just send an INVITE with a new 'session' XML element to implicitly indicate that the participants are now part of a different CS without sending disassociation from the old CS. In this example, the SRC uses the same RS. In case the SRC wishes to use a new RS, it will tear down the current RS using normal SIP procedures (BYE) with metadata, as in example 4.
SRCはまず、参加者と古いCSの関連付けを解除することを示す*オプション*のスナップショットを送信します。 SRCは、新しい「セッション」XML要素を含むINVITEを送信することを選択して、古いCSからの関連付け解除を送信せずに、参加者が別のCSの一部であることを暗黙的に示すことができます。この例では、SRCは同じRSを使用します。 SRCが新しいRSを使用したい場合、例4のように、メタデータ付きの通常のSIPプロシージャ（BYE）を使用して現在のRSを破棄します。
Metadata snapshot for REFER based transfer in CS:
CSでのREFERベースの転送のメタデータスナップショット：
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar Content-Type: application/rs-metadata Content-Disposition: recording-session
--foobar Content-Type：application / rs-metadata Content-Disposition：recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
In the above snapshot, the 'participantsessionassoc' XML element is optional as indicating a 'session' XML element with a 'stop-time' XML element implicitly means that all the participants associated with that session have been disassociated.
上記のスナップショットでは、「participantsessionassoc」XML要素はオプションであり、「stop-time」XML要素を持つ「session」XML要素は暗黙的に、そのセッションに関連付けられたすべての参加者の関連付けが解除されたことを示します。
The SRC sends another snapshot to indicate the participant change (due to REFER) and new session information after transfer. In this example, it is assumed that the SRC uses the same RS to continue recording the call. The 'sipSessionID' XML element in the metadata snapshot now indicates Bob and Carol in the (local, remote) UUID pair.
SRCは別のスナップショットを送信して、参加者の変更（REFERによる）と転送後の新しいセッション情報を示します。この例では、SRCが同じRSを使用して通話の録音を継続すると想定しています。メタデータスナップショットの「sipSessionID」XML要素は、（ローカル、リモート）UUIDペアのボブとキャロルを示します。
Metadata snapshot for REFER based transfer in CS:
CSでのREFERベースの転送のメタデータスナップショット：
RE-INVITE SRC-------------------->SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49180 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
...
m=video 49182 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:97
a=sendonly
...
m=audio 51374 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:98
a=sendonly
...
m=video 49178 RTP/AVPF 96
a=rtpmap:96 H.264/90000
a=label:99
a=sendonly
....
--foobar Content-Type: application/rs-metadata
--foobar Content-Type：application / rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<session session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<sipSessionID>3363127f0d084c10876dddd4f8e5eeb9
;remote=2272bb7e70fe41dba0025ae9a26d54cf</sipSessionID>
<start-time>2010-12-16T23:41:07Z</start-time>
</session>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Bob@biloxy.com"/>
</participant>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameID aor="sip:carol@example.com"/>
</participant>
<stream stream_id="60JAJm9UTvik0Ltlih/Gzw=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>96</label>
</stream>
<stream stream_id="AcR5FUd3Edi8cACQJy/3JQ=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>98</label>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<label>99</label>
</stream>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<associate-time>2010-12-16T23:32:03Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="bfLZ+NTFEeCNxQTuRyQBmw==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>60JAJm9UTvik0Ltlih/Gzw==</recv>
<recv>AcR5FUd3Edi8cACQJy/3JQ==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>60JAJm9UTvik0Ltlih/Gzw==</send>
<send>AcR5FUd3Edi8cACQJy/3JQ==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
</recording>
This example shows a snapshot of metadata sent by the SRC to the SRS when a CS with Alice and Bob as participants is disconnected.
この例は、アリスとボブが参加者であるCSが切断されたときに、SRCからSRSに送信されるメタデータのスナップショットを示しています。
SRC SRS
| |
|(1) BYE (metadata snapshot) F1 |
|---------------------------------------------------->|
| 200 OK F2 |
|<----------------------------------------------------|
Metadata snapshot for a CS disconnect:
CS切断のメタデータスナップショット：
F1 BYE SRC -----------> SRS
BYE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 102 BYE
Max-Forwards: 70
Require: siprec
Accept: application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar Content-Type: application/rs-metadata
--foobar Content-Type：application / rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
This section describes a few example call flows where the SRC may be part of conference model either as focus or a participant in conference as explained in Section 3.1.5 of [RFC7245]. The SRS here can be a SIP User Agent (UA) or an entity part of the MEDIACTRL architecture. Note that the disconnect case is not shown since the metadata snapshot will be same as for a non-mixing case.
このセクションでは、[RFC7245]のセクション3.1.5で説明されているように、フォーカスまたは会議の参加者としてSRCが会議モデルの一部である可能性があるいくつかのコールフローの例について説明します。ここでのSRSは、SIPユーザーエージェント（UA）またはMEDIACTRLアーキテクチャのエンティティ部分です。メタデータスナップショットは非混合ケースと同じであるため、切断ケースは表示されないことに注意してください。
A basic call between two participants, Alice and Bob, who are part of one CS. In this use case, each participant calls into a conference server (say, a Multipoint Control Unit (MCU)) to attend one of many conferences hosted on or managed by that server. Media streams sent by each participant are received by all the other participants in the conference. Below is the initial snapshot sent by the SRC in the INVITE to the SRS that has the complete metadata. For the sake of simplicity, only snippets of SIP/SDP are shown. The SRC records the streams of each participant to SRS by mixing in this example. The SRC here is part of conference model described in Section 3 of [RFC7245] as a focus and does mixing. The SRC here is not a participant by itself and hence it does not contribute to media.
1人のCSの一部である2人の参加者、アリスとボブの間の基本的なコール。この使用例では、各参加者が会議サーバー（たとえば、マルチポイントコントロールユニット（MCU））を呼び出して、そのサーバーでホストまたは管理されている多くの会議の1つに参加します。各参加者が送信したメディアストリームは、会議の他のすべての参加者が受信します。以下は、INVITEのSRCから完全なメタデータを持つSRSに送信される初期スナップショットです。簡単にするために、SIP / SDPのスニペットのみを示しています。 SRCは、この例で混合することにより、各参加者のストリームをSRSに記録します。ここのSRCは、[RFC7245]のセクション3で説明されている会議モデルの一部であり、ミキシングを行います。ここのSRCはそれ自体は参加者ではないため、メディアには貢献しません。
Metadata snapshot with the SRC mixing streams to the SRS:
SRCへのSRCミキシングストリームを含むメタデータのスナップショット：
F1 INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=00000000000000000000000000000000
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
<start-time>2010-12-16T23:41:07Z</start-time>
</session>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:alice@atlanta.com">
<name xml:lang="it">Alice</name>
</nameID>
</participant>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:bob@biloxy.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<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>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
In the above example, there are two participants, Alice and Bob, in the conference. Among other things, the SRC sends Session-ID in the metadata snapshot. There are two Session-IDs here: one that corresponds to the SIP session between Alice and the Conference focus and the other for the SIP session between Bob and the Conference focus. In this use case, since Alice and Bob call into the conference, these Session-IDs are different.
上記の例では、会議に2人の参加者、アリスとボブがいます。特に、SRCはセッションIDをメタデータスナップショットで送信します。ここには2つのセッションIDがあります。1つはアリスと会議フォーカス間のSIPセッションに対応し、もう1つはボブと会議フォーカス間のSIPセッションに対応します。この使用例では、アリスとボブが会議にコールするため、これらのセッションIDは異なります。
This is the continuation of example 1 (basic call with SRC mixing streams). A call between two participants, Alice and Bob, is established and an RS is created for recording, as in example 5. One of the participants, Bob, puts Alice on hold, and then resumes as part of the same CS. The 'send' and 'recv' XML elements of a 'participant' XML element are used to indicate whether or not a participant is contributing to a media stream. The metadata snapshot is represented below:
これは、例1（SRCミキシングストリームを使用した基本的な呼び出し）の続きです。例5のように、2人の参加者、アリスとボブの間の通話が確立され、RSが録音用に作成されます。参加者の1人、ボブは、アリスを保留にしてから、同じCSの一部として再開します。 'participant' XML要素の 'send'および 'recv' XML要素は、参加者がメディアストリームに貢献しているかどうかを示すために使用されます。メタデータのスナップショットを以下に示します。
During hold
ホールド中
Metadata snapshot when a CS participant goes on hold and the SRC is mixing the streams:
CS参加者が保留になり、SRCがストリームを混合しているときのメタデータのスナップショット：
RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
</participantstreamassoc>
</recording>
During resumption, a snapshot shown below will be sent from the SRC to the SRS.
再開中、以下に示すスナップショットがSRCからSRSに送信されます。
Metadata snapshot when a CS participant resumes and the SRC is mixing the streams:
CS参加者が再開し、SRCがストリームを混合しているときのメタデータのスナップショット：
RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
3.3.3. Example 3: Metadata Snapshot of Joining/Dropping of a Participant to a Session
3.3.3. 例3：セッションへの参加者の参加/削除のメタデータスナップショット
In a conference model, participants can join and drop a session any time during the session. Below is a snapshot sent from the SRC to the SRS in this case. Note the SRC here can be a focus or a participant in the conference. In the case where the SRC is a participant, it may learn the information required for metadata by subscribing to a conference event package [RFC4575]. Assume Alice and Bob were in the conference and a third participant (Carol) joins, then the SRC sends the below snapshot with the indication of new participant.
会議モデルでは、参加者はセッション中いつでもセッションに参加してドロップできます。以下は、この場合にSRCからSRSに送信されるスナップショットです。ここでのSRCは、会議の焦点または参加者である場合があります。 SRCが参加者である場合、会議イベントパッケージ[RFC4575]にサブスクライブすることにより、メタデータに必要な情報を学習できます。アリスとボブが会議に参加していて、3人目の参加者（キャロル）が参加したとすると、SRCは新しい参加者を示す以下のスナップショットを送信します。
Metadata snapshot for a new participant joining CS:
CSに参加する新しい参加者のメタデータスナップショット：
RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID>
</session>
<participant
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<nameID aor="sip:carol@example.com">
<name xml:lang="it">Carol</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2013-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="Atnm1ZRnOC6Pm5MApkrDzQ==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
After some time, Alice drops from the conference. The SRC generates a new snapshot showing Alice disassociating from the session.
しばらくすると、アリスは会議を辞退します。 SRCは、アリスがセッションから切り離されていることを示す新しいスナップショットを生成します。
Metadata snapshot for a participant dropping from CS:
CSからドロップする参加者のメタデータスナップショット：
RE-INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: a358d2b81a444a8c8fb05950cef331e7
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/SDP
...
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=label:96
a=sendonly
....
--foobar
Content-Type: application/rs-metadata
Content-Disposition: recording-session
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=68caf509b9284b7ea45f84a049febf0a</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=0e8a82bedda74f57be4a4a4da54167c4</sipSessionID>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
When a CS is disconnected, the SRC sends a BYE with a snapshot of metadata having a session stop time and participant disassociation times. The snapshot looks the same as listed in Section 3.2.4.
CSが切断されると、SRCはBYEに、セッション停止時間と参加者の関連付け解除時間を持つメタデータのスナップショットを送信します。スナップショットは、セクション3.2.4にリストされているものと同じように見えます。
This section shows the snapshots of metadata for the cases where a persistent RS exists between the SRC and the SRS. An SRC here may be a SIP UA or a B2BUA, or it may be part of a conference model as either the focus or a participant in a conference. The SRS here could be a SIP UA or an entity part of the MEDIACTRL architecture. Except in the disconnect case, the snapshot remains same as mentioned in previous sections.
このセクションでは、SRCとSRSの間に永続的なRSが存在する場合のメタデータのスナップショットを示します。ここでのSRCは、SIP UAまたはB2BUAの場合もあれば、フォーカスまたは会議の参加者としての会議モデルの一部の場合もあります。ここでのSRSは、SIP UAまたはMEDIACTRLアーキテクチャのエンティティ部分である可能性があります。切断の場合を除いて、スナップショットは前のセクションで説明したものと同じままです。
3.4.1. Example 1: Metadata Snapshot during CS Disconnect with Persistent RS between SRC and SRS
3.4.1. 例1：SRCとSRSの間の永続的なRSを使用したCS切断中のメタデータスナップショット
Metadata snapshot for a CS disconnect with a persistent RS:
永続的なRSを使用したCS切断のメタデータスナップショット：
RE-INVITE sent from SRC -----------> SRS
INVITE sip:2001@example.com SIP/2.0
Via: SIP/2.0/UDP src.example.com;branch=z9hG4bK47c8eb30
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
Session-ID: ab30317f1a784dc48ff824d0d3715d86
;remote=f81d4fae7dec11d0a76500a0c91e6bf6
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/rs-metadata,
application/rs-metadata-request
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar Content-Type: application/rs-metadata
--foobar Content-Type：application / rs-metadata
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<stop-time>2010-12-16T23:41:07Z</stop-time>
</session>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
In trading-floor environments, in order to minimize storage and recording system resources, it may be preferable to mix multiple concurrent calls (each call is one CS) on different handsets/speakers on the same turret into a single RS. This would mean media in each CS is mixed and recorded as part of single media stream, and multiple such CSs are recording in one RS from an SRC to an SRS.
トレーディングフロア環境では、ストレージと記録のシステムリソースを最小限に抑えるために、同じタレット上の異なるハンドセット/スピーカーで複数の同時呼び出し（各呼び出しは1つのCS）を単一のRSに混在させることが望ましい場合があります。これは、各CSのメディアが単一のメディアストリームの一部として混合および記録され、そのような複数のCSが1つのRSでSRCからSRSに記録していることを意味します。
Taking an example where there are two CSs [CS1 and CS2]: assume mixing is done in each of these CSs and both these CSs are recorded as part of single RS from a single SRC, which is part of both the CSs. There are three possibilities here:
2つのCS [CS1とCS2]がある例を取り上げます。これらのCSのそれぞれでミキシングが行われ、これらの両方のCSが、両方のCSの一部である単一のSRCから単一のRSの一部として記録されます。ここには3つの可能性があります。
o CS1 and CS2 use the same focus for mixing, and that focus is also acting as SRC in each of the CSs.
o CS1とCS2はミキシングに同じフォーカスを使用し、そのフォーカスは各CSでSRCとしても機能しています。
o One CS (e.g. CS1) SRC is the focus and the other CS (e.g. CS2), SRC is just one of the participants of the conference.
o 一方のCS（CS1など）のSRCがフォーカスで、もう一方のCS（CS2など）のSRCは、会議の参加者の1人にすぎません。
o In both CS1 and CS2, the SRC is just a participant of conference.
o CS1とCS2の両方で、SRCは会議の参加者にすぎません。
The following example shows the first possibility where CS1 and CS2 use the same focus for mixing, and that focus is also acting as SRC in each of the CSs.
次の例は、CS1とCS2がミキシングに同じフォーカスを使用し、そのフォーカスが各CSでSRCとしても機能している最初の可能性を示しています。
Metadata snapshot with two CSs recorded as part of the same RS:
同じRSの一部として記録された2つのCSのメタデータスナップショット：
INVITE SRC --------------> SRS
INVITE sip:recorder@example.com SIP/2.0 Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9 From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247 To: <sip:recorder@example.com> Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID: a358d2b81a444a8c8fb05950cef331e7 ;remote=00000000000000000000000000000000 Content-Type: application/SDP ... m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=label:96 a=sendonly ...
INVITE sip：recorder@example.com SIP / 2.0 Via：SIP / 2.0 / TCP src.example.com; branch = z9hG4bKdf6b622b648d9 From：<sip：2000@example.com>; tag = 35e195d2-947d-4585-946f-09839247 To：<sip：recorder@example.com> Call-ID：d253c800-b0d1ea39-4a7dd-3f0e20a Session-ID：a358d2b81a444a8c8fb05950cef331e7; remote = 00000000000000000000000000000000 Content-Type：application / SDP ... m = audio 49170 RTP / AVP 0 a = rtpmap：0 PCMU / 8000 a = label：96 a = sendonly ...
<?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>
</group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>fa3b60f27e91441e84c55a9a0095f075
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>ca718e1430474b5485a53aa5d0bea45e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>497c0f13929643b4a16858e2a3885edc
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<start-time>2010-12-16T23:41:07Z</start-time>
</session>
<session session_id="e6370VVGEeWAG6886p18uA==">
<sipSessionID>ae10731ca50343a5aaae2dd0904a65de
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>33c77aac7deb414cbc8c10f363fccb71
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<sipSessionID>fd6932e9e5fc489fae2d5b3779723b7e
;remote=a358d2b81a444a8c8fb05950cef331e7</sipSessionID>
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<start-time>2010-12-16T23:43:07Z</start-time>
</session>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:alice@atlanta.com">
<name xml:lang="it">Alice</name>
</nameID>
</participant>
<participant
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Bob@biloxy.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<participant
participant_id="EiXGlc+4TruqqoDaNE76ag==">
<nameID aor="sip:Carol@example.com">
<name xml:lang="it">Carol</name>
</nameID>
</participant>
<stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<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>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="e6370VVGEeWAG6886p18uA==">
<associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="e6370VVGEeWAG6886p18uA==">
<associate-time>2010-12-16T23:43:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="EiXGlc+4TruqqoDaNE76ag==">
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
</participantstreamassoc>
</recording>
Security and privacy considerations mentioned in [RFC7865] and [RFC7866] have to be followed by the SRC and the SRS for setting up RS SIP dialogs and sending metadata.
[RFC7865]と[RFC7866]で言及されているセキュリティとプライバシーの考慮事項の後には、RS SIPダイアログをセットアップしてメタデータを送信するためのSRCとSRSが続く必要があります。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[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>。
[RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", RFC 7865, DOI 10.17487/RFC7865, May 2016, <http://www.rfc-editor.org/info/rfc7865>.
[RFC7865] Ravindranath、R.、Ravindran、P。、およびP. Kyzivat、「Session Initiation Protocol（SIP）Recording Metadata」、RFC 7865、DOI 10.17487 / RFC7865、2016年5月、<http：//www.rfc-editor .org / info / rfc7865>。
[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>。
[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>。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、編、「会議状態用のSession Initiation Protocol（SIP）イベントパッケージ」、RFC 4575、DOI 10.17487 / RFC4575、2006年8月、<http： //www.rfc-editor.org/info/rfc4575>。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <http://www.rfc-editor.org/info/rfc4353>.
[RFC4353] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のフレームワーク」、RFC 4353、DOI 10.17487 / RFC4353、2006年2月、<http://www.rfc-editor.org/info/rfc4353 >。
[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：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[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>。
Acknowledgements
謝辞
Thanks to Ofir Rath, Charles Eckel, Yaron Pdut, Dmitry Andreyev, and Charles Armitage for their review comments.
Ofir Rath、Charles Eckel、Yaron Pdut、Dmitry Andreyev、Charles Armitageのレビューコメントに感謝します。
Thanks to Alissa Cooper, Stephen Farrell, Kathleen Moriarty, Suresh Krishnan, Benoit Claise, Carlos Pignataro, Dan Romascanu, and Derek Atkins for their feedback and comments during IESG reviews.
IESGレビュー中のフィードバックとコメントを提供してくれたAlissa Cooper、Stephen Farrell、Kathleen Moriarty、Suresh Krishnan、Benoit Claise、Carlos Pignataro、Dan Romascanu、Derek Atkinsに感謝します。
Authors' Addresses
著者のアドレス
Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India
Ram Mohan Ravindranath Cisco Systems、Inc. Cessna Business Park、Kadabeesanahalli Village、Varthur Hobli、Sarjapur-Marathahalli Outer Ring Road Bangalore、Karnatakaインド
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 of America
Paul Kyzivat Huawei Hudson、MAアメリカ合衆国
Email: pkyzivat@alum.mit.edu