[要約] RFC 7195は、PSTN上の回線交換ベアラを介してオーディオおよびビデオメディアストリームを設定するためのSDP拡張を提供しています。このRFCの目的は、PSTN上でのメディアストリームの設定を効率化し、互換性を向上させることです。
Internet Engineering Task Force (IETF) M. Garcia-Martin
Request for Comments: 7195 Ericsson
Category: Standards Track S. Veikkolainen
ISSN: 2070-1721 Nokia
May 2014
Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)
公衆交換電話網（PSTN）の回線交換ベアラを介してオーディオおよびビデオメディアストリームを設定するためのセッション記述プロトコル（SDP）拡張
Abstract
概要
This memo describes use cases, requirements, and protocol extensions for using the Session Description Protocol (SDP) offer/answer model for establishing audio and video media streams over circuit-switched bearers in the Public Switched Telephone Network (PSTN).
このメモは、公衆交換電話網（PSTN）の回線交換ベアラを介してオーディオおよびビデオメディアストリームを確立するためのセッション記述プロトコル（SDP）オファー/アンサーモデルを使用するための使用例、要件、およびプロトコル拡張について説明します。
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 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7195.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7195で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Requirements ....................................................5
4. Overview of Operation ...........................................5
4.1. Example Call Flow ..........................................6
5. Protocol Description ............................................7
5.1. Level of Compliance ........................................7
5.2. Extensions to SDP ..........................................7
5.2.1. Connection Data .....................................7
5.2.2. Media Descriptions ..................................9
5.2.3. Correlating the PSTN Circuit-Switched
Bearer with SDP ....................................10
5.2.3.1. The "cs-correlation" Attribute ............11
5.2.3.2. Caller ID Correlation Mechanism ...........12
5.2.3.3. User-User Information Element
Correlation Mechanism .....................13
5.2.3.4. DTMF Correlation Mechanism ................14
5.2.3.5. External Correlation Mechanism ............15
5.2.3.6. Extensions to Correlation Mechanisms ......16
5.3. Negotiating the Correlation Mechanisms ....................17
5.3.1. Determining the Direction of the
Circuit-Switched Bearer Setup ......................17
5.3.2. Populating the "cs-correlation" Attribute ..........18
5.3.3. Considerations for Correlations ....................18
5.4. Considerations for Usage of Existing SDP ..................19
5.4.1. Originator of the Session ..........................19
5.4.2. Contact Information ................................20
5.5. Considerations for Usage of Third Party Call
Control (3PCC) ............................................20
5.6. Offer/Answer Mode Extensions ..............................20
5.6.1. Generating the Initial Offer .......................21
5.6.2. Generating the Answer ..............................23
5.6.3. Offerer Processing the Answer ......................26
5.6.4. Modifying the Session ..............................27
5.7. Formal Syntax .............................................28
6. Examples .......................................................30
6.1. Single PSTN Audio Stream ..................................30
6.2. Advanced SDP Example: Circuit-Switched Audio and
Video Streams .............................................32
7. Security Considerations ........................................33
8. IANA Considerations ............................................35
8.1. Registration of the New "cs-correlation" SDP Attribute ....35
8.2. Registration of a New "nettype" Value .....................36
8.3. Registration of a New "addrtype" Value ....................36
8.4. Registration of a New "proto" Value .......................36
9. Acknowledgments ................................................37
10. References ....................................................37
10.1. Normative References .....................................37
10.2. Informative References ...................................38
The Session Description Protocol (SDP) [RFC4566] is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP is most commonly used for describing media streams that are transported over the Real-Time Transport Protocol (RTP) [RFC3550], using the profiles for audio and video media defined in "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551].
セッション記述プロトコル（SDP）[RFC4566]は、セッションのアナウンス、セッションへの招待、および他の形式のマルチメディアセッション開始のために、マルチメディアセッションを記述することを目的としています。 SDPは、リアルタイムトランスポートプロトコル（RTP）[RFC3550]を介してトランスポートされるメディアストリームの記述に最も一般的に使用され、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」[RFC3551 ]。
However, SDP can be used to describe media transport protocols other than RTP. Previous work includes SDP conventions for describing ATM bearer connections [RFC3108] and the Message Session Relay Protocol [RFC4975].
ただし、SDPは、RTP以外のメディア転送プロトコルを記述するために使用できます。前の作業には、ATMベアラ接続[RFC3108]およびメッセージセッションリレープロトコル[RFC4975]を説明するためのSDP規則が含まれています。
SDP is commonly carried in Session Initiation Protocol (SIP) [RFC3261] messages in order to agree on a common media description among the endpoints. "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264] defines a framework by which two endpoints can exchange SDP media descriptions and come to an agreement as to which media streams should be used, along with the media-related parameters.
SDPは一般に、エンドポイント間で共通のメディア記述に合意するために、Session Initiation Protocol（SIP）[RFC3261]メッセージで伝達されます。 「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」[RFC3264]は、2つのエンドポイントがSDPメディア記述を交換し、使用するメディアストリームとメディア関連の合意について合意に至るフレームワークを定義しますパラメーター。
In some scenarios, it might be desirable to establish the media stream over a circuit-switched bearer connection even if the signaling for the session is carried over an IP bearer. An example of such a scenario is illustrated with two mobile devices capable of both circuit-switched and packet-switched communication over a low-bandwidth radio bearer. The radio bearer may not be suitable for carrying real-time audio or video media, and using a circuit-switched bearer would offer a better perceived quality of service. So, according to this scenario, SDP and its higher-layer session control protocol (e.g., the Session Initiation Protocol (SIP) [RFC3261]) are used over regular IP connectivity, while the audio or video is received through the classical circuit-switched bearer.
一部のシナリオでは、セッションのシグナリングがIPベアラで伝送される場合でも、回線交換ベアラ接続でメディアストリームを確立することが望ましい場合があります。このようなシナリオの例は、低帯域幅の無線ベアラを介した回線交換とパケット交換の両方の通信が可能な2つのモバイルデバイスで示されています。無線ベアラは、リアルタイムのオーディオまたはビデオメディアの伝送には適していない場合があり、回線交換ベアラを使用すると、より良いサービス品質が得られます。したがって、このシナリオによれば、SDPとその上位層のセッション制御プロトコル（たとえば、Session Initiation Protocol（SIP）[RFC3261]）は通常のIP接続で使用され、オーディオまたはビデオは従来の回線交換で受信されます。無記名。
This document addresses only the use of circuit-switched bearers in the PSTN, not a generic circuit-switched network. The mechanisms presented below require a call signaling protocol of the PSTN to be used (such as ITU-T Q.931 [ITU.Q931.1998] or 3GPP TS 24.008 [TS.24.008]).
このドキュメントでは、公衆回線交換ネットワークではなく、PSTNでの回線交換ベアラの使用のみを扱います。以下に示すメカニズムでは、PSTNのコールシグナリングプロトコルを使用する必要があります（ITU-T Q.931 [ITU.Q931.1998]または3GPP TS 24.008 [TS.24.008]など）。
Setting up a signaling relationship in the IP domain instead of just setting up a circuit-switched call also offers the possibility of negotiating, in the same session, other IP-based media that is not sensitive to jitter and delay, for example, text messaging or presence information.
回線交換コールをセットアップするだけでなく、IPドメインでシグナリング関係をセットアップすると、同じセッションで、ジッターや遅延の影響を受けにくい他のIPベースのメディア（テキストメッセージングなど）をネゴシエートする可能性も提供されます。またはプレゼンス情報。
At a later point in time, the mobile device might move to an area where a high-bandwidth packet-switched bearer, for example, a Wireless Local Area Network (WLAN) connection, is available. At this point, the mobile device may perform a handover and move the audio or video media streams over to the high-speed bearer. This implies a new exchange of SDP offer/answer that leads to a renegotiation of the media streams.
後の時点で、モバイルデバイスは、高帯域幅のパケット交換ベアラ、たとえばワイヤレスローカルエリアネットワーク（WLAN）接続が利用可能なエリアに移動する可能性があります。この時点で、モバイルデバイスはハンドオーバを実行し、オーディオまたはビデオメディアストリームを高速ベアラに移動します。これは、メディアストリームの再交渉につながるSDPオファー/アンサーの新しい交換を意味します。
Other use cases exist. For example, an endpoint might have at its disposal circuit-switched and packet-switched connectivity, but the same audio or video codecs are not feasible for both access networks. For example, the circuit-switched audio or video stream supports narrow-bandwidth codecs, while the packet-switched access allows any other audio or video codec implemented in the endpoint. In this case, it might be beneficial for the endpoint to describe different codecs for each access type and get an agreement on the bearer together with the remote endpoint.
他のユースケースが存在します。たとえば、エンドポイントは回線交換接続とパケット交換接続を自由に使用できますが、両方のアクセスネットワークで同じオーディオまたはビデオコーデックを使用することはできません。たとえば、回線交換のオーディオまたはビデオストリームは狭帯域幅のコーデックをサポートし、パケット交換のアクセスはエンドポイントに実装された他のオーディオまたはビデオコーデックを許可します。この場合、エンドポイントがアクセスタイプごとに異なるコーデックを記述し、リモートエンドポイントと一緒にベアラで合意を得ることが有益な場合があります。
There are additional use cases related to third party call control where the session setup time is improved when the circuit-switched bearer in the PSTN is described together with one or more codecs.
PSTNの回線交換ベアラが1つ以上のコーデックと一緒に記述されている場合、セッションのセットアップ時間が改善されるサードパーティの呼制御に関連する追加の使用例があります。
The rest of the document is structured as follows: Section 2 provides the document conventions, Section 3 introduces the requirements, Section 4 presents an overview of the proposed solutions, and Section 5 contains the protocol description. Section 6 provides examples of circuit-switched audio or video streams in SDP. Sections 7 and 8 contain the Security and IANA considerations, respectively.
ドキュメントの残りの部分は次のように構成されています。セクション2はドキュメントの規則を示し、セクション3は要件を紹介し、セクション4は提案されたソリューションの概要を示し、セクション5はプロトコルの説明を含みます。セクション6では、SDPでの回線交換オーディオまたはビデオストリームの例を示します。セクション7と8には、それぞれセキュリティとIANAに関する考慮事項が含まれています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL "このドキュメントでは、BCP 14、RFC 2119 [RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。
This section presents the general requirements that are specific for the audio or video media streams over circuit-switched bearers.
このセクションでは、回線交換ベアラを介したオーディオまたはビデオメディアストリームに固有の一般的な要件について説明します。
REQ-1: A mechanism for endpoints to negotiate and agree on an audio or video media stream established over a circuit-switched bearer MUST be available.
REQ-1：回線交換ベアラを介して確立されたオーディオまたはビデオのメディアストリームをエンドポイントがネゴシエートおよび合意するためのメカニズムが利用可能でなければなりません。
REQ-2: The mechanism MUST allow the endpoints to combine circuit-switched audio or video media streams with other complementary media streams, for example, text messaging.
REQ-2：メカニズムは、エンドポイントが回線交換オーディオまたはビデオメディアストリームを他の補完的なメディアストリーム（テキストメッセージングなど）と結合できるようにする必要があります。
REQ-3: The mechanism MUST allow the endpoint to negotiate the direction of the circuit-switched bearer, i.e., which endpoint is active when initiating the circuit-switched bearer.
REQ-3：メカニズムは、エンドポイントが回線交換ベアラの方向をネゴシエートできるようにする必要があります。つまり、回線交換ベアラを開始するときにどのエンドポイントがアクティブかを確認する必要があります。
REQ-4: The mechanism MUST be independent of the type of the circuit-switched access (e.g., Integrated Services Digital Network (ISDN), Global System for Mobile Communication (GSM), etc.)
REQ-4：メカニズムは、回線交換アクセスのタイプ（たとえば、統合デジタルサービス通信網（ISDN）、モバイルシステムのグローバルシステム（GSM）など）から独立している必要があります。
REQ-5: There MUST be a mechanism that helps an endpoint to correlate an incoming circuit-switched bearer with the one negotiated in SDP, as opposed to another incoming call that is not related to that. In case correlation by programmatic means is not possible, correlation may also be performed by the human user.
REQ-5：エンドポイントが、それに関連しない別の着信コールとは対照的に、着信回線交換ベアラをSDPでネゴシエートされたベアラと関連付けるのに役立つメカニズムが必要です。プログラム的な手段による相関が不可能な場合、相関は人間のユーザーによっても実行され得る。
REQ-6: It MUST be possible for endpoints to advertise different lists of audio or video codecs in the circuit-switched audio or video stream from those used in a packet-switched audio or video stream.
REQ-6：パケット交換のオーディオまたはビデオストリームで使用されるものとは異なる、回路交換のオーディオまたはビデオストリームのオーディオまたはビデオコーデックの異なるリストをエンドポイントがアドバタイズできるようにする必要があります。
REQ-7: It MUST be possible for endpoints to not advertise the list of available codecs for circuit-switched audio or video streams.
REQ-7：回線交換のオーディオまたはビデオストリームで使用可能なコーデックのリストをエンドポイントが通知しないようにする必要があります。
The mechanism defined in this memo extends SDP [RFC4566] and allows describing an audio or video media stream established over a circuit-switched bearer. A new network type ("PSTN") and a new protocol type ("PSTN") are defined for the "c=" and "m=" lines to be able to describe a media stream over a circuit-switched bearer. These SDP extensions are described in Section 5.2. Since circuit-switched bearers are connection-oriented media streams, the mechanism reuses the connection-oriented extensions defined in RFC 4145 [RFC4145] to negotiate the active and passive sides of a connection setup. This is further described in Section 5.3.1.
このメモで定義されたメカニズムは、SDP [RFC4566]を拡張し、回線交換ベアラを介して確立されたオーディオまたはビデオメディアストリームを記述することを可能にします。新しいネットワークタイプ（「PSTN」）と新しいプロトコルタイプ（「PSTN」）は、回線交換ベアラ上のメディアストリームを記述できるように、「c =」行と「m =」行に定義されています。これらのSDP拡張機能については、セクション5.2で説明しています。回線交換ベアラは接続指向のメディアストリームであるため、メカニズムはRFC 4145 [RFC4145]で定義されている接続指向の拡張を再利用して、接続設定のアクティブ側とパッシブ側をネゴシエートします。これについては、セクション5.3.1で詳しく説明します。
Consider the example presented in Figure 1. In this example, Endpoint A is located in an environment where it has access to both IP and circuit-switched bearers for communicating with other endpoints. Endpoint A decides that the circuit-switched bearer offers a better perceived quality of service for voice and issues an SDP offer containing the description of an audio media stream over a circuit-switched bearer.
図1の例を考えてみます。この例では、エンドポイントAは、他のエンドポイントと通信するためにIPベアラと回線交換ベアラの両方にアクセスできる環境にあります。エンドポイントAは、回線交換ベアラーが音声に対してより良いサービス品質を提供すると判断し、回線交換ベアラーを介したオーディオメディアストリームの説明を含むSDPオファーを発行します。
Endpoint A Endpoint B
| (1) SDP offer (PSTN audio) |
|----------------------------------->|
| |
| (2) SDP answer (PSTN audio) |
|<-----------------------------------|
| |
| PSTN call setup |
|<-----------------------------------|
| |
| |
|<===== media over PSTN bearer =====>|
| |
Figure 1: Example Flow
図1：フローの例
Endpoint B receives the SDP offer and determines that it is located in an environment where the IP-based bearer is not suitable for real-time audio media. However, Endpoint B also has a PSTN circuit-switched bearer available for audio. Endpoint B generates an SDP answer containing a description of the audio media stream over a circuit-switched bearer.
エンドポイントBはSDPオファーを受信し、IPベースのベアラがリアルタイムオーディオメディアに適さない環境にあると判断します。ただし、エンドポイントBには、音声用のPSTN回線交換ベアラもあります。エンドポイントBは、回線交換ベアラを介したオーディオメディアストリームの説明を含むSDP応答を生成します。
During the offer/answer exchange, Endpoints A and B also agree upon the direction in which the circuit-switched bearer should be established. In this example, Endpoint B becomes the active party; in other words, it establishes the circuit-switched call to the other endpoint. The offer/answer exchange contains identifiers or references that can be used on the circuit-switched network for addressing the other endpoint, as well as information that is used to determine that the incoming circuit-switched bearer establishment is related to the ongoing session between the two endpoints.
オファー/アンサー交換中に、エンドポイントAとBは、回線交換ベアラを確立する方向についても合意します。この例では、エンドポイントBがアクティブパーティになります。つまり、他のエンドポイントへの回線交換コールを確立します。オファー/アンサー交換には、他のエンドポイントをアドレス指定するために回線交換ネットワークで使用できる識別子または参照、および着信回線交換ベアラー確立がの間の進行中のセッションに関連していることを決定するために使用される情報が含まれます2つのエンドポイント。
Endpoint B establishes a circuit-switched bearer towards Endpoint A using whatever mechanisms are defined for the network type in question. When receiving the incoming circuit-switched connection attempt, Endpoint A is able to determine that the attempt is related to the session it is just establishing with B.
エンドポイントBは、問題のネットワークタイプに対して定義されているメカニズムを使用して、エンドポイントAへの回線交換ベアラを確立します。着信回線交換接続の試行を受信すると、エンドポイントAは、その試行がBとの確立中のセッションに関連していると判断できます。
Endpoint A accepts the circuit-switched connection; the circuit-switched bearer setup is completed. The two endpoints can now use the circuit-switched connection for two-way audio media.
エンドポイントAは回線交換接続を受け入れます。回線交換ベアラのセットアップが完了しました。これで、2つのエンドポイントは、双方向音声メディアに回線交換接続を使用できます。
If, for some reason, Endpoint B would like to reject the offered stream, it would set the port number of the specific stream to zero, as specified in RFC 3264 [RFC3264]. Also, if B does not understand some of the SDP attributes specified in this document, it would ignore them, as specified in RFC 4566 [RFC4566].
何らかの理由で、エンドポイントBが提供されたストリームを拒否したい場合、RFC 3264 [RFC3264]で指定されているように、特定のストリームのポート番号をゼロに設定します。また、Bがこのドキュメントで指定されているSDP属性の一部を理解していない場合、RFC 4566 [RFC4566]で指定されているように、それらは無視されます。
Implementations that are compliant with this specification MUST implement the SDP extensions described in Section 5.2 and MUST implement the considerations discussed in Sections 5.3, 5.4, and 5.6.
この仕様に準拠する実装は、セクション5.2で説明されているSDP拡張機能を実装する必要があり、セクション5.3、5.4、および5.6で説明されている考慮事項を実装する必要があります。
This section provides the syntax and semantics of the extensions required for providing a description of audio or video media streams over circuit-switched bearers in SDP.
このセクションでは、SDPの回線交換ベアラを介したオーディオまたはビデオメディアストリームの説明を提供するために必要な拡張機能の構文とセマンティクスを提供します。
According to SDP [RFC4566], the connection data line in SDP has the following syntax:
SDP [RFC4566]によると、SDPの接続データ行の構文は次のとおりです。
c=<nettype> <addrtype> <connection-address>
where <nettype> indicates the network type, <addrtype> indicates the address type, and <connection-address> is the connection address, which is dependent on the address type.
ここで、<nettype>はネットワークタイプを示し、<addrtype>はアドレスタイプを示し、<connection-address>は接続アドレスであり、アドレスタイプによって異なります。
At the moment, the only network type defined is "IN", which indicates Internet network type. The address types "IP4" and "IP6" indicate the type of IP addresses.
現時点では、定義されているネットワークタイプは「IN」のみです。これは、インターネットネットワークタイプを示します。アドレスタイプ「IP4」および「IP6」は、IPアドレスのタイプを示します。
This memo defines a new network type for describing a circuit-switched bearer network type in the PSTN. The mnemonic "PSTN" is used for this network type.
このメモは、PSTNで回線交換ベアラネットワークタイプを記述するための新しいネットワークタイプを定義します。このネットワークタイプには、ニーモニック「PSTN」が使用されます。
For the address type, we initially considered the possibility of describing E.164 telephone numbers. We define a new "E164" address type to be used within the context of a "PSTN" network type. The "E164" address type indicates that the connection address contains an E.164 number represented according to the ITU-T E.164 [ITU.E164.2010] recommendation.
アドレスタイプについては、最初にE.164電話番号を記述する可能性を検討しました。 「PSTN」ネットワークタイプのコンテキスト内で使用される新しい「E164」アドレスタイプを定義します。 「E164」アドレスタイプは、接続アドレスにITU-T E.164 [ITU.E164.2010]勧告に従って表されたE.164番号が含まれていることを示します。
It is a common convention that an international E.164 number contains a leading '+' sign. For consistency's sake, we also require the E.164 telephone is prepended with a '+', even if that is not necessary for routing of the call in the PSTN network.
国際的なE.164番号に先頭に「+」記号が含まれることは一般的な慣習です。一貫性を保つために、PSTNネットワークでの通話のルーティングに不要な場合でも、E.164電話の先頭に「+」を付ける必要があります。
There are cases, though, when the endpoint is merely aware of a circuit-switched bearer, without having further information about the E.164 number allocated to it. In these cases, a dash ("-") is used to indicate an unknown connection address. This makes the connection data line consistent with SDP syntax.
ただし、エンドポイントが回線交換ベアラを認識しているだけで、割り当てられたE.164番号に関する詳細情報がない場合もあります。これらの場合、ダッシュ（ "-"）は不明な接続アドレスを示すために使用されます。これにより、接続データラインがSDP構文と一致します。
Please note that the "E164" address type defined in this memo is exclusively defined to be used in conjunction with the "PSTN" network type in accordance with regular offer/answer procedures [RFC4566].
このメモで定義されている「E164」アドレスタイプは、通常のオファー/アンサー手順[RFC4566]に従って「PSTN」ネットワークタイプと組み合わせて使用するためにのみ定義されていることに注意してください。
Note: RFC 3108 [RFC3108] also defines address type "E.164". This definition is distinct from the one defined by this memo and shall not be used with <nettype> "PSTN".
注：RFC 3108 [RFC3108]では、アドレスタイプ「E.164」も定義されています。この定義は、このメモで定義されたものとは異なり、<nettype> "PSTN"では使用されません。
This memo exclusively uses the international representation of E.164 numbers, i.e., those including a country code and, as described above, prepended with a '+' sign. Implementations conforming to this specification and using the "E164" address type together with the "PSTN" network type MUST use the 'global-number-digits' construction specified in RFC 3966 [RFC3966] for representing international E.164 numbers. This representation requires the presence of the '+' sign and additionally allows for the presence of one or more 'visual-separator' constructions for easier human readability (see Section 5.7).
このメモは、E.164番号の国際的な表現、つまり国コードを含み、上記のように先頭に「+」記号を付加したもののみを使用します。この仕様に準拠し、「PS164」ネットワークタイプとともに「E164」アドレスタイプを使用する実装では、国際的なE.164番号を表すためにRFC 3966 [RFC3966]で指定されている「global-number-digits」構造を使用する必要があります。この表現には「+」記号の存在が必要であり、さらに人間が読みやすくするために1つ以上の「ビジュアルセパレーター」構造の存在を許可します（セクション5.7を参照）。
Note that <connection-address> MUST NOT be omitted when unknown since this would violate basic syntax of SDP [RFC4566]. In such cases, it MUST be set to a "-".
<connection-address>は、SDP [RFC4566]の基本構文に違反するため、不明な場合は省略してはならないことに注意してください。そのような場合、「-」に設定する必要があります。
The following are examples of the extension to the connection data line:
以下は、接続データラインへの拡張の例です。
c=PSTN E164 +441134960123
c = PSTN E164 +441134960123
c=PSTN E164 -
c = PSTN E164-
When the <addrtype> is E164, the connection address is defined as follows:
<addrtype>がE164の場合、接続アドレスは次のように定義されます。
o an international E.164 number (prepended with a '+' sign)
o 国際E.164番号（先頭に「+」記号が付いている）
o the value "-", signifying that the address is unknown
o 値「-」は、アドレスが不明であることを示します
o any other value resulting from the production rule of connection-address in RFC 4566 [RFC4566], but in all cases any value encountered will be ignored.
o RFC 4566 [RFC4566]のconnection-addressの生成規則に起因するその他の値。ただし、発生した値はすべて無視されます。
According to SDP [RFC4566], the media description line in SDP has the following syntax:
SDP [RFC4566]によると、SDPのメディア記述行の構文は次のとおりです。
m=<media> <port> <proto> <fmt> ...
m = <メディア> <ポート> <プロトコル> <fmt> ...
The <media> subfield carries the media type. For establishing an audio bearer, the existing "audio" media type is used. For establishing a video bearer, the existing "video" media type is used.
<media>サブフィールドには、メディアタイプが含まれます。オーディオベアラを確立するには、既存の「オーディオ」メディアタイプが使用されます。ビデオベアラを確立するために、既存の「ビデオ」メディアタイプが使用されます。
The <port> subfield is the transport port to which the media stream is sent. Circuit-switched access lacks the concept of a port number; therefore, the <port> subfield does not carry any meaningful value. In order to be compliant with SDP syntax, implementations SHOULD set the <port> subfield to the discard port value "9" and MUST ignore it on reception.
<port>サブフィールドは、メディアストリームの送信先のトランスポートポートです。回線交換アクセスには、ポート番号の概念がありません。したがって、<port>サブフィールドには意味のある値はありません。 SDP構文に準拠するために、実装では<port>サブフィールドを破棄ポート値「9」に設定する必要があり、受信時に無視する必要があります。
According to RFC 3264 [RFC3264], a port number of zero in the offer of a unicast stream indicates that the stream is offered but must not be used. If a port number of zero is present in the answer of a unicast stream, it indicates that the stream is rejected. These rules are still valid when the media line in SDP represents a circuit-switched bearer.
RFC 3264 [RFC3264]によると、ユニキャストストリームのオファーのポート番号0は、そのストリームが提供されているが使用してはならないことを示しています。ユニキャストストリームの応答にポート番号0が含まれている場合は、ストリームが拒否されていることを示しています。これらのルールは、SDPのメディアラインが回線交換ベアラを表す場合でも有効です。
The <proto> subfield is the transport protocol. The circuit-switched bearer uses whatever transport protocol it has available. This subfield SHOULD be set to the mnemonic "PSTN" to be syntactically correct with SDP [RFC4566] and to indicate the usage of circuit-switched protocols in the PSTN.
<proto>サブフィールドはトランスポートプロトコルです。回線交換ベアラは、使用可能なトランスポートプロトコルを使用します。このサブフィールドは、SDP [RFC4566]と構文的に正しく、PSTNでの回線交換プロトコルの使用を示すために、ニーモニック「PSTN」に設定する必要があります（SHOULD）。
The <fmt> subfield is the media format description. In the classical usage of SDP to describe RTP-based media streams, when the <proto> subfield is set to "RTP/AVP" or "RTP/SAVP", the <fmt> subfield contains the payload types as defined in the RTP audio profile [RFC3551].
<fmt>サブフィールドは、メディア形式の説明です。 RTPベースのメディアストリームを記述するためのSDPの従来の使用法では、<proto>サブフィールドが「RTP / AVP」または「RTP / SAVP」に設定されている場合、<fmt>サブフィールドには、RTPオーディオで定義されているペイロードタイプが含まれます。プロファイル[RFC3551]。
When "RTP/AVP" is used in the <proto> field, the <fmt> subfield contains the RTP payload type numbers. We use the <fmt> subfield to indicate the list of available codecs over the circuit-switched bearer, by reusing the conventions and payload type numbers defined for RTP / AVP. The RTP audio and video media types, when applied to PSTN circuit-switched bearers, represent merely an audio or video codec. If the endpoint is able to determine the list of available codecs for circuit-switched media streams, it MUST use the corresponding payload type numbers in the <fmt> subfield.
<proto>フィールドで「RTP / AVP」が使用されている場合、<fmt>サブフィールドにはRTPペイロードタイプ番号が含まれます。 <fmt>サブフィールドを使用して、RTP / AVPに定義された規則とペイロードタイプ番号を再利用することにより、回線交換ベアラで使用可能なコーデックのリストを示します。 RTPオーディオおよびビデオメディアタイプは、PSTN回線交換ベアラに適用されると、単にオーディオまたはビデオコーデックを表します。エンドポイントが回線交換メディアストリームに利用可能なコーデックのリストを決定できる場合、エンドポイントは<fmt>サブフィールドで対応するペイロードタイプ番号を使用する必要があります。
In some cases, the endpoint is not able to determine the list of available codecs for circuit-switched media streams. In this case, in order to be syntactically compliant with SDP [RFC4566], the endpoint MUST include a single dash ("-") in the <fmt> subfield.
場合によっては、エンドポイントは回線交換メディアストリームに使用可能なコーデックのリストを決定できません。この場合、SDP [RFC4566]に構文的に準拠するために、エンドポイントは<fmt>サブフィールドに単一のダッシュ（ "-"）を含める必要があります。
As per RFC 4566 [RFC4566], the media format descriptions are listed in priority order.
RFC 4566 [RFC4566]に従い、メディア形式の説明は優先順位順にリストされています。
Examples of media descriptions for circuit-switched audio streams are:
回線交換オーディオストリームのメディア記述の例は次のとおりです。
m=audio 9 PSTN 3 0 8
m =音声PSTN 9 3 0 8
m=audio 9 PSTN -
m = 9 PSTNオーディオ-
Similarly, an example of a media description for circuit-switched video stream is:
同様に、回線交換ビデオストリームのメディア記述の例は次のとおりです。
m=video 9 PSTN 34
m =ビデオPSTN 9 34
m=video 9 PSTN -
m = 9 PSTN参照-
The endpoints should be able to correlate the circuit-switched bearer with the session negotiated with SDP in order to avoid ringing for an incoming circuit-switched bearer that is related to the session controlled with SDP (and SIP).
エンドポイントは、SDP（およびSIP）で制御されるセッションに関連する着信回線交換ベアラの呼び出しを回避するために、回線交換ベアラをSDPとネゴシエートされたセッションと関連付けることができる必要があります。
Several alternatives exist for performing this correlation. This memo provides three mutually non-exclusive correlation mechanisms. Additionally, we define a fourth mechanism where correlation may be performed by external means, typically by the human user, in case using other correlation mechanisms is not possible or does not succeed. Other correlation mechanisms may exist, and their usage will be specified when need arises.
この相関を実行するためのいくつかの選択肢があります。このメモは、3つの相互に非排他的な相関メカニズムを提供します。さらに、他の相関メカニズムを使用できない場合や成功しない場合に備えて、通常は人間のユーザーが外部の手段によって相関を実行できる4番目のメカニズムを定義します。他の相関メカニズムが存在する場合があり、それらの使用法は必要が生じたときに指定されます。
All mechanisms share the same principle: some unique information is sent in the SDP and in the circuit-switched signaling protocol. If these pieces of information match, then the circuit-switched bearer is part of the session described in the SDP exchange. Otherwise, there is no guarantee that the circuit-switched bearer is related to such session.
すべてのメカニズムは同じ原則を共有します。いくつかの固有の情報は、SDPおよび回線交換シグナリングプロトコルで送信されます。これらの情報が一致する場合、回線交換ベアラはSDP交換で説明されているセッションの一部です。そうでない場合、回線交換ベアラがそのようなセッションに関連しているという保証はありません。
The first mechanism is based on the exchange of PSTN Caller ID between the endpoints. The Caller ID is also available as the Calling Party Number in the circuit-switched signaling.
最初のメカニズムは、エンドポイント間のPSTN発信者IDの交換に基づいています。発信者IDは、回線交換シグナリングの発信者番号としても使用できます。
The second mechanism is based on the inclusion in SDP of a value that is also sent in the User-User Information Element that is part of the bearer setup signaling in the PSTN.
2番目のメカニズムは、PSTNのベアラセットアップシグナリングの一部であるUser-User Information Elementでも送信される値をSDPに含めることに基づいています。
The third mechanism is based on sending in SDP a string that represents Dual-Tone Multi-Frequency (DTMF) digits that will be later sent right after the circuit-switched bearer is established.
3番目のメカニズムは、回線交換ベアラが確立された直後に送信されるデュアルトーンマルチ周波数（DTMF）の数字を表す文字列をSDPで送信することに基づいています。
The fourth correlation mechanism declares support for cases where correlation is done by external means. Typically, this means that the decision is left to the human user. This is how some current conferencing systems operate: after logging on to the conference, the system calls back to the user's phone number to establish audio communications, and it is up to the human user to accept or reject the incoming call. By declaring explicit support for this mechanism, endpoints can use it only when such a possibility exists.
4番目の相関メカニズムは、相関が外部手段によって行われる場合のサポートを宣言します。通常、これは決定が人間のユーザーに委ねられることを意味します。これが現在の一部の会議システムの動作方法です。会議にログオンした後、システムはユーザーの電話番号にコールバックして音声通信を確立し、着信を受け入れるか拒否するかはユーザー次第です。このメカニズムの明示的なサポートを宣言することにより、エンドポイントはそのような可能性が存在する場合にのみそれを使用できます。
Endpoints may opt to implement any combination of the correlation mechanisms specified in Sections 5.2.3.2, 5.2.3.3, 5.2.3.4, and 5.2.3.5, including the option to implement none at all.
エンドポイントは、セクション5.2.3.2、5.2.3.3、5.2.3.4、および5.2.3.5で指定された相関メカニズムの任意の組み合わせを実装することを選択できます。これには、何も実装しないオプションも含まれます。
In order to provide support for the correlation mechanisms, we define a new media-level SDP attribute called "cs-correlation". There MUST be at most one "cs-correlation" attribute per media description.
相関メカニズムのサポートを提供するために、「cs-correlation」と呼ばれる新しいメディアレベルのSDP属性を定義します。メディアの説明ごとに「cs-correlation」属性が1つだけ存在する必要があります。
This "cs-correlation" attribute MAY contain zero or more subfields -- "callerid", "uuie", "dtmf", or "external" to specify additional information required by the Caller ID, User-User Information Element, DTMF, or external correlation mechanisms, respectively. The list of correlation mechanisms may be extended by other specifications; see Section 5.2.3.6 for more details.
この「cs-correlation」属性には、ゼロ以上のサブフィールドが含まれる場合があります。「callerid」、「uuie」、「dtmf」、または「external」は、発信者ID、ユーザー-ユーザー情報要素、DTMF、またはそれぞれ外部相関メカニズム。相関メカニズムのリストは、他の仕様によって拡張される場合があります。詳細については、セクション5.2.3.6を参照してください。
The following sections provide more detailed information about these subfields.
以下のセクションでは、これらのサブフィールドに関する詳細情報を提供します。
The values "callerid", "uuie", "dtmf", and "external" refer to the correlation mechanisms defined in Sections 5.2.3.2, 5.2.3.3, 5.2.3.4, and 5.2.3.5, respectively. The formal Augmented Backus-Naur Format (ABNF) syntax of the "cs-correlation" attribute is presented in Section 5.7.
値「callerid」、「uuie」、「dtmf」、および「external」は、それぞれセクション5.2.3.2、5.2.3.3、5.2.3.4、および5.2.3.5で定義された相関メカニズムを参照します。 「cs-correlation」属性の正式な拡張バッカスナウアフォーマット（ABNF）構文は、セクション5.7に示されています。
The Caller ID correlation mechanism consists of an exchange of the Calling Party Number as an international E.164 number in SDP, followed by the availability of the Calling Party Number Information Element in the call setup signaling of the circuit-switched connection. If both pieces of information match, the circuit-switched bearer is correlated to the session described in SDP.
発信者IDの相関メカニズムは、SDPでの国際E.164番号としての発呼者番号の交換と、それに続く回線交換接続の呼設定シグナリングでの発呼者番号情報要素の可用性で構成されます。両方の情報が一致する場合、回線交換ベアラはSDPで説明されているセッションに関連付けられます。
An example of inclusion of an international E.164 number in the "cs-correlation" attribute is:
「cs-correlation」属性に国際E.164番号を含める例は次のとおりです。
a=cs-correlation:callerid:+441134960123
The presence of the "callerid" subfield indicates that the endpoint supports use of the Calling Party Number as a means of correlating a PSTN call with the session being negotiated. The "callerid" subfield MAY be accompanied by the international E.164 number of the party inserting the parameter.
「callerid」サブフィールドの存在は、PSTNコールをネゴシエートされているセッションと相関させる手段として、エンドポイントが発呼者番号の使用をサポートしていることを示しています。 「callerid」サブフィールドには、パラメータを挿入するパーティの国際E.164番号が付随する場合があります。
Note that there are no guarantees that this correlation mechanism works or is even available, due a number of problems:
多くの問題により、この相関メカニズムが機能する、または利用可能であることさえ保証されていないことに注意してください。
* The endpoint might not be aware of its own E.164 number, in which case it cannot populate the SDP appropriately.
* エンドポイントは、自身のE.164番号を認識していない場合があります。その場合、SDPを適切に設定できません。
* The Calling Party Number Information Element in the circuit-switched signaling might not be available, e.g., due to policy restrictions of the network operator or caller restriction due to privacy.
* 回線交換シグナリングの発呼側番号情報要素は、たとえば、ネットワークオペレーターのポリシー制限やプライバシーによる発呼者の制限が原因で使用できない場合があります。
* The Calling Party Number Information Element in the circuit-switched signaling might be available, but the digit representation of the E.164 number might differ from the one expressed in the SDP, due to, e.g., lack of country code. To mitigate this problem, implementations should consider only some of the rightmost digits from the E.164 number for correlation. For example, the numbers +44-113-496-0123 and 0113-496-0123 could be considered as the same number. This is also the behavior of some cellular phones, which correlate the incoming calling party with a number stored in the phone book, for the purpose of displaying the caller's name. Please refer to ITU-T E.164 recommendation [ITU.E164.2010] for consideration of the relevant number of digits to consider.
*回線交換シグナリングの発呼者番号情報要素は利用できる場合がありますが、E.164番号の数字表現は、たとえば国コードがないために、SDPで表現されたものとは異なる場合があります。この問題を軽減するために、実装では相関のためにE.164番号の右端の数字の一部のみを考慮する必要があります。たとえば、+ 44-113-496-0123と0113-496-0123は同じ番号と見なすことができます。これは、発信者の名前を表示するために、着信した発呼者を電話帳に保存されている番号と関連付ける一部の携帯電話の動作でもあります。考慮すべき関連桁数については、ITU-T E.164勧告[ITU.E164.2010]を参照してください。
A second correlation mechanism is based on including in SDP a string that represents the User-User Information Element that is part of the call setup signaling of the circuit-switched bearer. The User-User Information Element is specified in ITU-T Q.931 [ITU.Q931.1998] and 3GPP TS 24.008 [TS.24.008], among others. The User-User Information Element has a maximum size of 35 or 131 octets, depending on the actual message of the PSTN protocol where it is included and the network settings.
第2の相関メカニズムは、回線交換ベアラのコールセットアップシグナリングの一部であるUser-User Information Elementを表す文字列をSDPに含めることに基づいています。ユーザー-ユーザー情報要素は、ITU-T Q.931 [ITU.Q931.1998]および3GPP TS 24.008 [TS.24.008]などで指定されています。 User-User Information Elementの最大サイズは、それが含まれているPSTNプロトコルの実際のメッセージとネットワーク設定に応じて、35または131オクテットです。
The mechanism works as follows. An endpoint creates a User-User Information Element, according to the requirements of the call setup signaling protocol. The same value is included in the SDP offer or SDP answer, in the "uuie" subfield of the "cs-correlation" attribute. When the SDP offer/answer exchange is completed, each endpoint has become aware of the value that will be used in the User-User Information Element of the call setup message of the PSTN protocol. The endpoint that initiates the call setup attempt includes this value in the User-User Information Element. The recipient of the call setup attempt can extract the User-User Information Element and correlate it with the value previously received in the SDP. If both values match, then the call setup attempt corresponds to that indicated in the SDP.
このメカニズムは次のように機能します。エンドポイントは、コールセットアップシグナリングプロトコルの要件に従って、User-User Information Elementを作成します。同じ値が、「cs-correlation」属性の「uuie」サブフィールドのSDPオファーまたはSDP回答に含まれています。 SDPオファー/アンサー交換が完了すると、各エンドポイントは、PSTNプロトコルのコールセットアップメッセージのUser-User Information Elementで使用される値を認識します。コールセットアップ試行を開始するエンドポイントは、この値をユーザー/ユーザー情報要素に含めます。コールセットアップ試行の受信者は、User-User情報要素を抽出し、それをSDPで以前に受信した値と関連付けることができます。両方の値が一致する場合、コールセットアップの試行はSDPに示されているものに対応します。
According to ITU-T Q.931 [ITU.Q931.1998], the User-User Information Element (UUIE) identifier is composed of a first octet identifying this as a User-User Information Element, a second octet containing the length of the user-user contents, a third octet containing a Protocol Discriminator, and a value of up to 32 or 128 octets (depending on network settings) containing the actual User Information (see Figure 4-36 in [ITU.Q931.1998]). The first two octets of the UUIE MUST NOT be used for correlation; only the octets carrying the Protocol Discriminator and the User Information value are input to the creation of the value of the "uuie" subfield in the "cs-correlation" attribute. Therefore, the value of the "uuie" subfield in the "cs-correlation" attribute MUST start with the Protocol Discriminator octet, followed by the User Information octets. The value of the Protocol Discriminator octet is not specified in this document; it is expected that organizations using this technology will allocate a suitable value for the Protocol Discriminator.
ITU-T Q.931 [ITU.Q931.1998]によれば、User-User Information Element（UUIE）識別子は、これをUser-User Information Elementとして識別する最初のオクテットで構成され、2番目のオクテットは、ユーザーとユーザーのコンテンツ、プロトコル識別子を含む3番目のオクテット、および実際のユーザー情報を含む最大32または128オクテットの値（ネットワーク設定による）（[ITU.Q931.1998]の図4-36を参照）。 UUIEの最初の2つのオクテットを相関に使用してはなりません（MUST NOT）。 「cs-correlation」属性の「uuie」サブフィールドの値の作成には、Protocol DiscriminatorおよびUser Information値を保持するオクテットのみが入力されます。したがって、「cs-correlation」属性の「uuie」サブフィールドの値は、プロトコル識別子オクテットで始まり、その後にユーザー情報オクテットが続く必要があります。 Protocol Discriminatorオクテットの値は、このドキュメントでは指定されていません。このテクノロジーを使用する組織は、プロトコル識別子に適切な値を割り当てることが期待されています。
Once the binary value of the "uuie" subfield in the "cs-correlation" attribute is created, it MUST be base 16 (also known as "hex") encoded before it is inserted in SDP. Please refer to RFC 4648 [RFC4648] for a detailed description of base 16 encoding. The resulting encoded value needs to have an even number of hexadecimal digits and MUST be considered invalid if it has an odd number.
「cs-correlation」属性の「uuie」サブフィールドのバイナリ値を作成したら、SDPに挿入する前に、ベース16（「hex」とも呼ばれる）でエンコードする必要があります。ベース16エンコーディングの詳細については、RFC 4648 [RFC4648]を参照してください。結果のエンコードされた値は、偶数の16進数である必要があり、奇数の場合は無効と見なされなければなりません（MUST）。
Note: The encoding of the "uuie" subfield of the "cs-correlation" attribute is largely inspired by the encoding of the same value in the User-to-User header field in SIP, according to "A Mechanism for Transporting User to User Call Control Information in SIP" [SIP-UUI].
注：「cs-correlation」属性の「uuie」サブフィールドのエンコードは、「ユーザーからユーザーへの転送メカニズム」によると、SIPのユーザー間ヘッダーフィールドの同じ値のエンコードに大きく影響を受けています。 SIPの呼制御情報」[SIP-UUI]。
As an example, an endpoint willing to send a UUIE containing a Protocol Discriminator with the hexadecimal value of %x56 and an hexadecimal User Information value of %xA390F3D2B7310023 would include an "a=cs-correlation" attribute line as follows:
例として、16進数の値が％x56で、16進数のユーザー情報の値が％xA390F3D2B7310023であるプロトコル識別子を含むUUIEを送信するエンドポイントには、次のように「a = cs-correlation」属性行が含まれます。
a=cs-correlation:uuie:56A390F3D2B7310023
Note that the value of the User-User Information Element is considered as an opaque string and only used for correlation purposes. Typically, call signaling protocols impose requirements on the creation of a User-User Information Element for end-user protocol exchange. The details regarding the generation of the User-User Information Element are outside the scope of this specification.
User-User Information Elementの値は不透明な文字列と見なされ、相関の目的でのみ使用されることに注意してください。通常、コールシグナリングプロトコルは、エンドユーザープロトコル交換のためのユーザー/ユーザー情報要素の作成に要件を課します。 User-User Information Elementの生成に関する詳細は、この仕様の範囲外です。
Please note that there are no guarantees that this correlation mechanism works. On one side, policy restrictions might not make the User-User information available end to end in the PSTN. On the other hand, the generation of the User-User Information Element is controlled by the PSTN circuit-switched call protocol, which might not offer enough freedom for generating different values from one endpoint to another one or from one call to another in the same endpoint. This might result in the same value of the User-User Information Element for all calls.
この相関メカニズムが機能することを保証するものではないことに注意してください。一方では、ポリシーの制限により、PSTNでエンドツーエンドの情報をユーザー間で利用できない場合があります。一方、ユーザー-ユーザー情報要素の生成は、PSTN回線交換呼び出しプロトコルによって制御されます。これにより、エンドポイント間または同じ通話内の別のエンドポイント間で異なる値を生成するための十分な自由度が提供されない場合があります。終点。これにより、すべての呼び出しのUser-User Information Elementの値が同じになる場合があります。
We introduce a third mechanism for correlating the circuit-switched bearer with the session described with SDP. This is based on agreeing on a sequence of digits that are negotiated in the SDP offer/answer exchange and sent as DTMF tones as described in ITU-T Recommendation Q.23 [ITU.Q23.1988] over the circuit-switched bearer once this bearer is established. If the DTMF digit sequence received through the circuit-switched bearer matches the digit string negotiated in the SDP, the circuit-switched bearer is correlated with the session described in the SDP. The mechanism is similar to many voice conferencing systems that require the user to enter a PIN code using DTMF tones in order to be accepted in a voice conference.
回線交換ベアラをSDPで記述されたセッションと関連付けるための3番目のメカニズムを紹介します。これは、SDPオファー/アンサー交換でネゴシエートされ、DTMFトーンとして送信される一連の数字の合意に基づいています。これは、ITU-T勧告Q.23 [ITU.Q23.1988]で説明されているように、回線交換ベアラを介してベアラが確立されます。回線交換ベアラを介して受信されたDTMFディジットシーケンスがSDPでネゴシエートされたディジットストリングと一致する場合、回線交換ベアラはSDPで記述されたセッションと関連付けられます。このメカニズムは、ユーザーが音声会議に参加するためにDTMFトーンを使用してPINコードを入力する必要がある多くの音声会議システムと同様です。
The mechanism works as follows. An endpoint selects a DTMF digit sequence. The same sequence is included in the SDP offer or SDP answer, in a "dtmf" subfield of the "cs-correlation" attribute. When the SDP offer/answer exchange is completed, each endpoint has become aware of the DTMF sequence that will be sent right after the circuit-switched bearer is set up. The endpoint that initiates the call setup attempt sends the DTMF digits according to the procedures defined for the circuit-switched bearer technology used. The recipient (passive side of the bearer setup) of the call setup attempt collects the digits and compares them with the value previously received in the SDP. If the digits match, then the call setup attempt corresponds to that indicated in the SDP.
このメカニズムは次のように機能します。エンドポイントはDTMFディジットシーケンスを選択します。同じシーケンスが、「cs-correlation」属性の「dtmf」サブフィールドのSDPオファーまたはSDPアンサーに含まれています。 SDPオファー/アンサー交換が完了すると、各エンドポイントは、回線交換ベアラーのセットアップ直後に送信されるDTMFシーケンスを認識します。コールセットアップ試行を開始するエンドポイントは、使用される回線交換ベアラテクノロジーに対して定義された手順に従って、DTMFディジットを送信します。コールセットアップ試行の受信者（ベアラセットアップのパッシブ側）は、数字を収集し、それらを以前にSDPで受信した値と比較します。数字が一致する場合、コールセットアップの試行はSDPに示されているものに対応します。
Note: Implementations are advised to select a number of DTMF digits that provide enough assurance that the call is related but do not prolong the bearer setup time unnecessarily. A number of 5 to 10 digits is a good compromise.
注：実装は、コールが関連していることを十分に保証するが、ベアラのセットアップ時間を不必要に延長しない、DTMF桁の数を選択することをお勧めします。 5〜10桁の数字は、適切な妥協案です。
As an example, an endpoint willing to send DTMF tone sequence "14D*3" would include an "a=cs-correlation" attribute line as follows:
例として、DTMFトーンシーケンス「14D * 3」を送信する意思があるエンドポイントには、次のように「a = cs-correlation」属性行が含まれます。
a=cs-correlation:dtmf:14D*3
If the endpoints successfully agree on the usage of the DTMF digit correlation mechanism but the passive side does not receive any DTMF digits after successful circuit-switched bearer setup or receives a set of DTMF digits that do not match the value of the "dtmf" attribute (including receiving too many digits), the passive side SHOULD consider that this DTMF mechanism has failed to correlate the incoming call.
エンドポイントがDTMFディジット相関メカニズムの使用に同意するが、回線交換ベアラのセットアップが成功した後、パッシブ側がDTMFディジットを受信しないか、「dtmf」属性の値と一致しないDTMFディジットのセットを受信する場合（受信する桁数が多すぎることを含む）、パッシブ側は、このDTMFメカニズムが着信コールの関連付けに失敗したと見なす必要があります。
The fourth correlation mechanism relies on external means for correlating the incoming call to the session. Since endpoints can select which correlation mechanisms they support, it may happen that no other common correlation mechanism is found or that the selected correlation mechanism does not succeed due to the required feature not being supported by the underlying PSTN network. In these cases, the human user can make the decision to accept or reject the incoming call, thus "correlating" the call with the session. Since not all endpoints are operated by a human user and since there may be no other external means implemented by the endpoint for the correlation function, we explicitly define support for such an external correlation mechanism.
4番目の相関メカニズムは、着信呼び出しをセッションに関連付けるための外部手段に依存しています。エンドポイントはサポートする相関メカニズムを選択できるため、他の一般的な相関メカニズムが見つからないか、必要な機能が基盤のPSTNネットワークでサポートされていないために、選択した相関メカニズムが成功しない場合があります。これらの場合、人間のユーザーは、着信コールを受け入れるか拒否するかを決定し、コールをセッションと「関連付ける」ことができます。すべてのエンドポイントが人間のユーザーによって操作されるわけではなく、相関関数のエンドポイントによって実装される他の外部手段がない可能性があるため、このような外部相関メカニズムのサポートを明示的に定義します。
Endpoints wishing to use this external correlation mechanism would use the "external" subfield in the "cs-correlation" attribute. Unlike the other three correlation mechanisms, the "external" subfield does not accept a value. The following is an example of an "a=cs-correlation" attribute line:
この外部相関メカニズムを使用したいエンドポイントは、「cs-correlation」属性の「external」サブフィールドを使用します。他の3つの相関メカニズムとは異なり、「外部」サブフィールドは値を受け入れません。以下は、「a = cs-correlation」属性行の例です。
a=cs-correlation:external
a = cs-correlation：external
Endpoints that are willing to only use the three explicit correlation mechanisms defined in this document ("callerid", "uuie", and/or "dtmf") would not include the "external" mechanism in the offer/answer exchange.
このドキュメントで定義されている3つの明示的な相関メカニズム（「callerid」、「uuie」、「dtmf」）のみを使用するエンドポイントは、オファー/アンサー交換に「外部」メカニズムを含みません。
The external correlation mechanism typically relies on the human user to make the decision on whether or not the call is related to the ongoing session. After the user accepts the call, that bearer is considered as related to the session. There is a small chance that the user receives at the same time another circuit-switched call that is not related to the ongoing session. The user may reject this call if he is able to determine (e.g., based on the calling line identification) that the call is not related to the session and continue waiting for another call attempt. If the user accepts the incoming circuit-switched call, but it turns out to be not related to the session, the endpoints need to rely on the human user to take appropriate action (typically, the user would hang up).
外部相関メカニズムは、通常、通話が進行中のセッションに関連しているかどうかを人間のユーザーが判断します。ユーザーがコールを受け入れると、そのベアラはセッションに関連していると見なされます。ユーザーが、進行中のセッションに関連しない別の回線交換コールを同時に受信する可能性はわずかです。呼び出しがセッションに関連していないことを（たとえば、呼び出し回線IDに基づいて）判別できる場合、ユーザーはこの呼び出しを拒否し、別の呼び出しの試行を待ち続けることができます。ユーザーが着信回線交換呼び出しを受け入れたが、セッションに関連していないことが判明した場合、エンドポイントは適切なアクションを実行するために人間のユーザーに依存する必要があります（通常、ユーザーは電話を切ります）。
New values for the "cs-correlation" attribute may be specified. The registration policy for new values is "Specification Required"; see Section 8. Any such specification MUST include a description of how the SDP offer/answer mechanism is used to negotiate the use of the new values, taking into account how endpoints determine which side will become active or passive (see Section 5.3 for more details).
「cs-correlation」属性の新しい値を指定できます。新しい値の登録ポリシーは「指定が必要」です。セクション8を参照してください。そのような仕様には、エンドポイントがアクティブまたはパッシブになる側を決定する方法を考慮に入れて、SDPオファー/アンサーメカニズムを使用して新しい値の使用をネゴシエートする方法の説明を含める必要があります（詳細については、セクション5.3を参照） ）。
If, during the offer/answer negotiation, either endpoint encounters an unknown value in the "cs-correlation" attribute, it MUST consider that mechanism as unsupported and MUST NOT include that value in subsequent offer/answer negotiation.
オファー/アンサーネゴシエーション中にいずれかのエンドポイントが「cs-correlation」属性で不明な値を検出した場合、そのメカニズムはサポートされていないと見なし、その値を後続のオファー/アンサーネゴシエーションに含めてはなりません。
The four correlation mechanisms presented above (based on Called Party Number, User-User Information Element, DTMF digit sending, and external) are non-exclusive and can be used independently of each other. In order to know how to populate the "cs-correlation" attribute, the endpoints need to agree which endpoint will become the active party, i.e., the one that will set up the circuit-switched bearer.
上記の4つの相関メカニズム（着信者番号、ユーザー-ユーザー情報要素、DTMFディジット送信、および外部に基づく）は、排他的ではなく、互いに独立して使用できます。 「cs-correlation」属性を設定する方法を知るために、エンドポイントは、どのエンドポイントがアクティブパーティになるか、つまり回線交換ベアラをセットアップするエンドポイントに同意する必要があります。
In order to avoid a situation where both endpoints attempt to initiate a connection simultaneously, the direction in which the circuit-switched bearer is set up MUST be negotiated during the offer/answer exchange.
両方のエンドポイントが同時に接続を開始しようとする状況を回避するために、回線交換ベアラがセットアップされる方向は、オファー/アンサー交換中にネゴシエートされなければなりません（MUST）。
The framework defined in RFC 4145 [RFC4145] allows the endpoints to agree which endpoint acts as the active endpoint when initiating a TCP connection. While RFC 4145 [RFC4145] was originally designed for establishing TCP connections, it can be easily extrapolated to the connection establishment of circuit-switched bearers. This specification uses the concepts specified in RFC 4145 [RFC4145] for agreeing on the direction of establishment of a circuit-switched bearer.
RFC 4145 [RFC4145]で定義されているフレームワークにより、エンドポイントは、TCP接続を開始するときにアクティブなエンドポイントとして機能するエンドポイントを合意できます。 RFC 4145 [RFC4145]はもともとTCP接続を確立するために設計されましたが、回線交換ベアラの接続確立に容易に推定できます。この仕様では、回線交換ベアラの確立の方向について合意するために、RFC 4145 [RFC4145]で指定された概念を使用しています。
RFC 4145 [RFC4145] defines two new attributes in SDP: "setup" and "connection". The "setup" attribute indicates which of the endpoints should initiate the connection establishment of the PSTN circuit-switched bearer. Four values are defined in Section 4 of RFC 4145 [RFC4145]: "active", "passive", "actpass", and "holdconn". Please refer to Section 4 of RFC 4145 [RFC4145] for a detailed description of this attribute.
RFC 4145 [RFC4145]は、SDPで「セットアップ」と「接続」という2つの新しい属性を定義しています。 「セットアップ」属性は、PSTN回線交換ベアラの接続確立を開始するエンドポイントを示します。 RFC 4145 [RFC4145]のセクション4で定義されている4つの値：「アクティブ」、「パッシブ」、「アクトパス」、および「ホールドコン」。この属性の詳細な説明については、RFC 4145 [RFC4145]のセクション4を参照してください。
The "connection" attribute indicates whether a new connection is needed or an existing connection is reused. The attribute can take the values "new" or "existing". Please refer to Section 5 of RFC 4145 [RFC4145] for a detailed description of this attribute.
「接続」属性は、新しい接続が必要か、既存の接続が再利用されるかを示します。この属性は、「新規」または「既存」の値をとることができます。この属性の詳細については、RFC 4145 [RFC4145]のセクション5を参照してください。
Implementations that are compliant with this specification MUST support the "setup" and "connection" attributes specified in RFC 4145 [RFC4145], but applied to circuit-switched bearers in the PSTN.
この仕様に準拠する実装は、RFC 4145 [RFC4145]で指定されている「設定」および「接続」属性をサポートする必要がありますが、PSTNの回線交換ベアラーに適用されます。
We define the active party as the one that initiates the circuit-switched bearer after the offer/answer exchange. The passive party is the one receiving the circuit-switched bearer. Either party may indicate its desire to become the active or passive party during the offer/answer exchange using the procedures described in Section 5.6.
アクティブパーティは、オファー/アンサー交換後に回線交換ベアラを開始するパーティと定義します。パッシブパーティは、回線交換ベアラを受信するパーティです。どちらの当事者も、セクション5.6で説明されている手順を使用して、オファー/アンサー交換中にアクティブまたはパッシブパーティーになることを希望する場合があります。
By defining values for the subfields in the "cs-correlation" attribute, the endpoint indicates that it is willing to become the active party and that it can use those values in the Calling Party Number, in the User-User Information Element, or as DTMF tones during the circuit-switched bearer setup.
エンドポイントは、「cs-correlation」属性のサブフィールドの値を定義することにより、アクティブパーティになることをいとわないこと、およびそれらの値を発呼側番号、ユーザ/ユーザ情報要素、または次のように使用できることを示します。回線交換ベアラのセットアップ中のDTMFトーン。
Thus, the following rules apply:
したがって、次の規則が適用されます。
o An endpoint that can only become the active party in the circuit-switched bearer setup MUST include all correlation mechanisms it supports in the "cs-correlation" attribute and MUST also specify values for the "callerid", "uuie", and "dtmf" subfields. Notice that the "external" subfield does not accept a value.
o 回線交換ベアラセットアップでのみアクティブパーティになることができるエンドポイントは、「cs-correlation」属性にサポートするすべての相関メカニズムを含める必要があり、「callerid」、「uuie」、および「dtmf」の値も指定する必要があります。サブフィールド。 「external」サブフィールドは値を受け入れないことに注意してください。
o An endpoint that can only become the passive party in the circuit-switched bearer setup MUST include all correlation mechanisms it supports in the "cs-correlation" attribute but MUST NOT specify values for the subfields.
o 回線交換ベアラの設定でのみパッシブパーティになることができるエンドポイントは、「cs-correlation」属性でサポートするすべての相関メカニズムを含める必要がありますが、サブフィールドの値を指定してはなりません（MUST NOT）。
o An endpoint that is willing to become either the active or passive party (by including the "a=setup:actpass" attribute in the offer) MUST include all correlation mechanisms it supports in the "cs-correlation" attribute and MUST also specify values for the "callerid", "uuie", and "dtmf" subfields. Notice that the "external" subfield does not accept a value.
o （オファーに「a = setup：actpass」属性を含めることにより）アクティブまたはパッシブパーティーのいずれかになろうとするエンドポイントは、「cs-correlation」属性でサポートするすべての相関メカニズムを含める必要があり、また、 「callerid」、「uuie」、および「dtmf」サブフィールド。 「external」サブフィールドは値を受け入れないことに注意してください。
Passive endpoints should expect an incoming circuit-switched (CS) call for setting up the audio bearer. Passive endpoints MAY suppress the incoming CS alert during certain time periods. Additional restrictions can be applied, such as the passive endpoint not alerting incoming calls originated from the number that was observed during the offer/answer negotiation.
パッシブエンドポイントは、オーディオベアラをセットアップするための着信回線交換（CS）呼び出しを予期する必要があります。パッシブエンドポイントは、特定の期間中の着信CSアラートを抑制してもよい（MAY）。オファー/アンサーネゴシエーション中に監視された番号から発信された着信コールにパッシブエンドポイントがアラートしないなど、追加の制限を適用できます。
There may be cases when an endpoint is not willing to include one or more correlation mechanisms in the "a=cs-correlation" attribute line even if it supports it. For example, some correlation mechanisms can be omitted if the endpoint is certain that the PSTN network does not support carrying the correlation identifier. Also, since using the DTMF-based correlation mechanism requires the call to be accepted before DTMF tones can be sent, some endpoints may enforce a policy restricting this due to, for example, cost associated with received calls, making the DTMF-based mechanism unusable.
エンドポイントが「a = cs-correlation」属性行にそれをサポートしている場合でも、1つ以上の相関メカニズムを含めることをいとわない場合があります。たとえば、PSTNネットワークが相関識別子の伝送をサポートしていないことをエンドポイントが確信している場合、一部の相関メカニズムを省略できます。また、DTMFベースの相関メカニズムを使用するには、DTMFトーンを送信する前にコールを受け入れる必要があるため、一部のエンドポイントでは、たとえば、受信したコールに関連するコストが原因でこれを制限するポリシーを実施し、DTMFベースのメカニズムを使用できなくなる場合があります。 。
Note that it cannot be guaranteed that the correlation mechanisms relying on caller identification, User-User Information Element, and DTMF sending will succeed even if the usage of those was agreed beforehand. This is due to the fact that correlation mechanisms require support from the circuit-switched bearer technology used.
呼び出し元の識別、ユーザー-ユーザー情報要素、およびDTMF送信に依存する相関メカニズムが、それらの使用法が事前に合意されていても成功することは保証されないことに注意してください。これは、相関メカニズムが、使用されている回線交換ベアラテクノロジーのサポートを必要とするためです。
Therefore, even a single positive indication using any of these mechanisms SHOULD be interpreted by the passive endpoint so that the circuit-switched bearer establishment is related to the ongoing session, even if the other correlation mechanisms fail.
したがって、他の相関メカニズムが失敗した場合でも、回線交換ベアラの確立が進行中のセッションに関連するように、これらのメカニズムのいずれかを使用する単一の肯定的な表示であってもパッシブエンドポイントによって解釈される必要があります。
If, after successfully negotiating any of the "callerid", "uuie", or "dtmf" correlation mechanisms in the SDP offer/answer exchange, an endpoint receives an incoming establishment of a circuit-switched bearer with no correlation information present, the endpoint first checks whether or not the offer/answer exchange was also used to successfully negotiate the "external" correlation mechanism. If it was, the endpoint should let the decision be made by external means, typically the human user. If the "external" correlation mechanism was not successfully negotiated, the endpoint should treat the call as unrelated to the ongoing session in the IP domain.
SDPオファー/アンサー交換で「callerid」、「uuie」、または「dtmf」相関メカニズムのいずれかを正常にネゴシエートした後、エンドポイントが相関情報のない回線交換ベアラの着信確立を受信した場合、エンドポイントまず、オファー/アンサー交換が「外部」相関メカニズムのネゴシエーションに成功したかどうかを確認します。そうであった場合、エンドポイントは、外部の手段（通常は人間のユーザー）によって決定を行わせる必要があります。 「外部」相関メカニズムが正常にネゴシエートされなかった場合、エンドポイントは、コールをIPドメインで進行中のセッションに関連しないものとして扱う必要があります。
According to SDP [RFC4566], the origin line in SDP has the following syntax:
SDP [RFC4566]によると、SDPの起点行の構文は次のとおりです。
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
Of interest here are the <nettype> and <addrtype> fields, which indicate the type of network and type of address, respectively. Typically, this field carries the IP address of the originator of the session. Even if the SDP was used to negotiate an audio or video media stream transported over a circuit-switched bearer, the originator is using SDP over an IP bearer. Therefore, <nettype> and <addrtype> fields in the "o=" line should be populated with the IP address identifying the source of the signaling.
ここで興味深いのは、ネットワークのタイプとアドレスのタイプをそれぞれ示す<nettype>フィールドと<addrtype>フィールドです。通常、このフィールドには、セッションの発信者のIPアドレスが含まれます。回線交換ベアラを介して転送されるオーディオまたはビデオメディアストリームのネゴシエーションにSDPが使用されていても、発信者はIPベアラを介してSDPを使用しています。したがって、「o =」行の<nettype>および<addrtype>フィールドには、シグナリングのソースを識別するIPアドレスを入力する必要があります。
SDP [RFC4566] defines the "p=" line, which may include the phone number of the person responsible for the conference. Even though this line can carry a phone number, it is not suited for the purpose of defining a connection address for the media. Therefore, we have selected to define the PSTN-specific connection addresses in the "c=" line.
SDP [RFC4566]は "p ="行を定義します。これには、会議の責任者の電話番号が含まれる場合があります。この回線は電話番号を運ぶことができますが、メディアの接続アドレスを定義する目的には適していません。したがって、「c =」行でPSTN固有の接続アドレスを定義することを選択しました。
"Best Current Practices for Third Party Call Control (3PCC) in the Session Initiation Protocol (SIP)" [RFC3725] outlines several flows that are possible in third party call control scenarios and recommends some flows for specific situations.
「セッション開始プロトコル（SIP）でのサードパーティコール制御（3PCC）の現在のベストプラクティス」[RFC3725]は、サードパーティコール制御シナリオで可能ないくつかのフローの概要を示し、特定の状況でいくつかのフローを推奨しています。
One of the assumptions in [RFC3725] is that an SDP offer may include a "black hole" connection address, which has the property that packets sent to it will never leave the host that sent them. For IPv4, this "black hole" connection address is 0.0.0.0 or a domain name within the .invalid DNS top level domain.
[RFC3725]の前提の1つは、SDPオファーに「ブラックホール」接続アドレスが含まれる可能性があることです。このアドレスには、送信されたパケットが送信元のホストを離れることはありません。 IPv4の場合、この「ブラックホール」接続アドレスは0.0.0.0または.invalid DNSトップレベルドメイン内のドメイン名です。
When using an E.164 address scheme in the context of third party call control, when the User Agent needs to indicate an unknown phone number, it MUST populate the <addrtype> of the SDP "c=" line with a "-" string.
サードパーティコール制御のコンテキストでE.164アドレススキームを使用する場合、ユーザーエージェントが不明な電話番号を示す必要がある場合、SDP "c ="行の<addrtype>に "-"文字列を入力する必要があります。 。
Note: This may result in the recipient of the initial offer rejecting such offer if the recipient of the offer was not aware of its own E.164 number. Consequently, it will not be possible to establish a circuit-switched bearer, since neither party is aware of its E.164 number.
注：これにより、オファーの受信者が自分のE.164番号を認識していない場合、最初のオファーの受信者がそのようなオファーを拒否する可能性があります。したがって、どちらの当事者もそのE.164番号を認識していないため、回線交換ベアラを確立することはできません。
In this section, we define extensions to the offer/answer model defined in "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264] to allow for PSTN addresses to be used with the offer/answer model.
このセクションでは、「セッション記述プロトコル（SDP）を使用したオファー/アンサーモデル」[RFC3264]で定義されているオファー/アンサーモデルの拡張を定義して、PSTNアドレスをオファー/アンサーモデルで使用できるようにします。
The offerer, wishing to use PSTN audio or video stream, MUST populate the "c=" and "m=" lines as follows.
PSTNオーディオまたはビデオストリームを使用したい提供者は、次のように "c ="および "m ="行を入力する必要があります。
The endpoint MUST set the <nettype> in the "c=" line to "PSTN" and the <addrtype> to "E164". Furthermore, the endpoint SHOULD set the <connection-address> field to its own international E.164 number (with a leading "+"). If the endpoint is not aware of its own E.164 number, it MUST set the <connection-address> to "-".
エンドポイントは、「c =」行の<nettype>を「PSTN」に設定し、<addrtype>を「E164」に設定する必要があります。さらに、エンドポイントは、<connection-address>フィールドを独自の国際E.164番号（先頭に「+」を付ける）に設定する必要があります（SHOULD）。エンドポイントが独自のE.164番号を認識していない場合は、<connection-address>を「-」に設定する必要があります。
In the "m=" line, the endpoint MUST set the <media> subfield to "audio" or "video", depending on the media type, and the <proto> subfield to "PSTN". The <port> subfield SHOULD be set to "9" (the discard port). The values "audio" or "video" in the <media> subfield MUST NOT be set by the endpoint unless it has knowledge that these bearer types are available on the circuit-switched network.
「m =」行では、エンドポイントは、メディアタイプに応じて、<media>サブフィールドを「audio」または「video」に設定し、<proto>サブフィールドを「PSTN」に設定する必要があります。 <port>サブフィールドは "9"（破棄ポート）に設定する必要があります（SHOULD）。 <media>サブフィールドの値「audio」または「video」は、回線交換ネットワークでこれらのベアラタイプが使用可能であるという知識がない限り、エンドポイントで設定してはなりません（MUST NOT）。
The <fmt> subfield carries the payload type number(s) the endpoint is wishing to use. Payload type numbers in this case refer to the codecs that the endpoint wishes to use on the PSTN media stream. For example, if the endpoint wishes to use the GSM codec, it would add payload type number 3 in the list of codecs. The list of payload types MUST only contain those codecs the endpoint is able to use on the PSTN bearer. In case the endpoint is not aware of the codecs available for the circuit-switched media streams, it MUST include a dash ("-") in the <fmt> subfield.
<fmt>サブフィールドには、エンドポイントが使用したいペイロードタイプ番号が含まれます。この場合のペイロードタイプ番号は、エンドポイントがPSTNメディアストリームで使用することを望むコーデックを指します。たとえば、エンドポイントがGSMコーデックを使用したい場合、コーデックのリストにペイロードタイプ番号3を追加します。ペイロードタイプのリストには、エンドポイントがPSTNベアラで使用できるコーデックのみを含める必要があります。エンドポイントが回線交換メディアストリームで使用可能なコーデックを認識していない場合は、<fmt>サブフィールドにダッシュ（ "-"）を含める必要があります。
The mapping table of static payload types numbers to payload types is initially specified in [RFC3551] and maintained by IANA. For dynamic payload types, the endpoint MUST define the set of valid encoding names and related parameters using the "a=rtpmap" attribute line. See Section 6 of RFC 4566 [RFC4566] for details.
ペイロードタイプへの静的ペイロードタイプ番号のマッピングテーブルは、[RFC3551]で最初に指定され、IANAによって維持されます。動的ペイロードタイプの場合、エンドポイントは、「a = rtpmap」属性行を使用して、有効なエンコーディング名と関連パラメーターのセットを定義する必要があります。詳細については、RFC 4566 [RFC4566]のセクション6を参照してください。
When generating the offer, the offerer MUST include an "a=cs-correlation" attribute line in the SDP offer. The offerer MUST NOT include more than one "cs-correlation" attribute per media description. The "a=cs-correlation" line SHOULD contain an enumeration of all the correlation mechanisms supported by the offerer, in the format of subfields. See Section 5.3.3 for more information on usage of the correlation mechanisms.
オファーを生成するとき、オファー者はSDPオファーに「a = cs-correlation」属性行を含める必要があります。提供者は、メディアの説明ごとに複数の「cs-correlation」属性を含めることはできません。 「a = cs-correlation」の行には、サブフィールドの形式で、提供者がサポートするすべての相関メカニズムの列挙が含まれている必要があります（SHOULD）。相関メカニズムの使用の詳細については、セクション5.3.3を参照してください。
The current list of subfields include "callerid", "uuie", "dtmf", and "external", and they refer to the correlation mechanisms defined in Sections 5.2.3.2, 5.2.3.3, 5.2.3.4, and 5.2.3.5, respectively.
サブフィールドの現在のリストには、「callerid」、「uuie」、「dtmf」、「external」が含まれ、セクション5.2.3.2、5.2.3.3、5.2.3.4、および5.2.3.5で定義された相関メカニズムを参照します。それぞれ。
If the offerer supports any of the correlation mechanisms defined in this memo and is willing to become the active party, the offerer MUST add the "callerid", "uuie", "dtmf", and/or "external" subfields and MUST specify values for them as follows:
提案者がこのメモで定義された相関メカニズムのいずれかをサポートし、アクティブなパーティーになる意思がある場合、提案者は「callerid」、「uuie」、「dtmf」、および/または「external」サブフィールドを追加し、値を指定する必要があります彼らのために次のように：
o The international E.164 number as the value in the "callerid" subfield.
o 「callerid」サブフィールドの値としての国際E.164番号。
o The contents of the User-User Information Element as the value of the "uuie" subfield.
o 「uuie」サブフィールドの値としてのユーザー-ユーザー情報要素の内容。
o The DTMF tone string as the value of the "dtmf" subfield.
o 「dtmf」サブフィールドの値としてのDTMFトーンストリング。
o The endpoint MUST NOT specify any value for the "external" subfield.
o エンドポイントは、「外部」サブフィールドの値を指定してはなりません（MUST NOT）。
If the offerer is only able to become the passive party in the circuit-switched bearer setup, it MUST add at least one of the possible correlation mechanisms but MUST NOT specify values for those subfields.
提供者が回線交換ベアラ設定でパッシブパーティになることができるだけの場合は、可能な相関メカニズムの少なくとも1つを追加する必要がありますが、これらのサブフィールドの値を指定してはなりません（MUST NOT）。
For example, if the offerer is willing to use the User-User Information Element and DTMF digit-sending mechanisms but can only become the passive party, and is also able to let the human user decide whether the correlation should be done or not, it includes the following lines in the SDP:
たとえば、オファー提供者がユーザー-ユーザー情報要素とDTMFディジット送信メカニズムを使用する意思があるが、パッシブパーティになることができるだけであり、人間のユーザーに相関を行うかどうかを決定させることができる場合、 SDPに次の行が含まれています。
a=cs-correlation:uuie dtmf external
a = cs-correlation：uuie dtmf external
a=setup:passive
a = setup：passive
If, on the other hand, the offerer is willing to use the User-User Information Element and the DTMF correlation mechanisms and is able to become the active or passive side, and is also able to let the human user decide whether the correlation should be done or not, it includes the following lines in the SDP:
一方、オファー提供者がユーザー-ユーザー情報要素とDTMF相関メカニズムを使用する意思があり、アクティブ側またはパッシブ側になることができ、相関関係が必要かどうかを人間のユーザーに決定させることができる場合完了したかどうかにかかわらず、SDPには次の行が含まれます。
a=cs-correlation:uuie:56A390F3D2B7310023 dtmf:14D*3 external
a=setup:actpass
a = setup：actpass
The negotiation of the value of the "setup" attribute takes place as defined in Section 4.1 of RFC 4145 [RFC4145].
「setup」属性の値のネゴシエーションは、RFC 4145 [RFC4145]のセクション4.1で定義されているように行われます。
The offerer states which role or roles it is willing to perform; the answerer, taking the offerer's willingness into consideration, chooses which roles both endpoints will actually perform during the circuit-switched bearer setup.
提案者は、実行する用意がある1つまたは複数の役割を示します。回答者は、提供者の意欲を考慮して、回線交換ベアラのセットアップ中に両方のエンドポイントが実際に実行する役割を選択します。
By "active" endpoint, we refer to an endpoint that will establish the circuit-switched bearer; by "passive" endpoint, we refer to an endpoint that will receive a circuit-switched bearer.
「アクティブ」エンドポイントとは、回線交換ベアラを確立するエンドポイントを指します。 「パッシブ」エンドポイントとは、回線交換ベアラを受信するエンドポイントを指します。
If an offerer does not know its international E.164 number, it MUST set the "setup" attribute to the value "active". If the offerer knows its international E.164 number, it SHOULD set the value to either "actpass" or "passive".
提供者が国際的なE.164番号を知らない場合は、「setup」属性を値「active」に設定する必要があります。出品者が国際的なE.164番号を知っている場合は、値を「actpass」または「passive」に設定する必要があります。
Also "holdconn" is a permissible value in the "setup" attribute. It indicates that the connection should not be established for the time being.
また、「holdconn」は、「setup」属性の許容値です。当面は接続を確立すべきではないことを示しています。
The offerer uses the "connection" attribute to decide whether a new circuit-switched bearer is to be established or not. For the initial offer, the offerer MUST use value "new".
提供者は、「接続」属性を使用して、新しい回線交換ベアラを確立するかどうかを決定します。最初のオファーの場合、オファー側は値「new」を使用する必要があります。
If the offer contained a circuit-switched audio or video stream, the answerer first determines whether it is able to accept and use such streams on the circuit-switched network. If the answerer does not support or is not willing to use circuit-switched media for the session, it MUST construct an answer where the port number for such media stream(s) is set to zero, according to Section 6 of [RFC3264]. If the answerer is willing to use circuit-switched media for the session, it MUST ignore the received port number (unless the port number is set to zero).
オファーに回線交換オーディオまたはビデオストリームが含まれている場合、回答者はまず、回線交換ネットワークでそのようなストリームを受け入れて使用できるかどうかを判断します。 [RFC3264]のセクション6に従って、回答者がセッションで回線交換メディアをサポートしていない、または使用したくない場合は、そのようなメディアストリームのポート番号がゼロに設定されている回答を作成する必要があります。応答側がセッションで回線交換メディアを使用する場合は、受信したポート番号を無視する必要があります（ポート番号がゼロに設定されている場合を除く）。
If the offer included a "-" as the payload type number, it indicates that the offerer is not willing or able to define any specific payload type. Most often, a "-" is expected to be used instead of the payload type when the endpoint is not aware of or not willing to define the codecs that will eventually be used on the circuit-switched bearer. The circuit-switched signaling protocols have their own means of negotiating or indicating the codecs; therefore, an answerer SHOULD accept such offers and SHOULD set the payload type to "-" in the answer.
オファーにペイロードタイプ番号として「-」が含まれている場合、それはオファー側が特定のペイロードタイプを定義する意思がない、または定義できないことを示しています。ほとんどの場合、エンドポイントが、回線交換ベアラで最終的に使用されるコーデックを認識していないか、定義する意思がない場合、ペイロードタイプの代わりに「-」が使用されると予想されます。回線交換シグナリングプロトコルには、コーデックをネゴシエートまたは示す独自の手段があります。したがって、回答者はそのようなオファーを受け入れる必要があり（SHOULD）、回答のペイロードタイプを「-」に設定する必要があります（SHOULD）。
If the answerer explicitly wants to specify a codec for the circuit-switched media, it MAY set the respective payload numbers in the <fmt> subfield in the answer. This behavior, however, is NOT RECOMMENDED.
回答者が回線交換メディアのコーデックを明示的に指定したい場合は、回答の<fmt>サブフィールドにそれぞれのペイロード番号を設定できます（MAY）。ただし、この動作は推奨されません。
When receiving the offer, the answerer MUST determine whether it becomes the active or passive party.
オファーを受け取ると、回答者はそれがアクティブパーティになるかパッシブパーティになるかを決定する必要があります。
If the SDP in the offer indicates that the offerer is only able to become the active party, the answerer needs to determine whether it is able to become the passive party. If this is not possible, e.g., due to the answerer not knowing its international E.164 number, the answerer MUST reject the circuit-switched media by setting the port number to zero on the answer. If the answerer is aware of its international E.164 number, it MUST include the "setup" attribute in the answer and set it to value "passive" or "holdconn". The answerer MUST also include its E.164 number in the "c=" line.
オファー内のSDPが、オファー側がアクティブパーティになることができるだけであることを示している場合、回答側は、それがパッシブパーティになることができるかどうかを判断する必要があります。これが不可能な場合、たとえば、国際的なE.164番号を知らない回答者が原因で、回答者は、回答のポート番号をゼロに設定して、回線交換メディアを拒否する必要があります。回答者がその国際的なE.164番号を認識している場合は、回答に「setup」属性を含め、値を「passive」または「holdconn」に設定する必要があります。回答者は、E.164番号も「c =」行に含める必要があります。
If the SDP in the offer indicates that the offerer is only able to become the passive party, the answerer MUST verify that the offerer's E.164 number is included in the "c=" line of the offer. If the number is included, the answerer MUST include the "setup" attribute in the answer and set it to value "active" or "holdconn". If the number is not included, the recipient of the offer is not willing to establish a connection the E.164 based on a priori knowledge of cost, or other reasons, call establishment is not possible, and the answerer MUST reject the circuit-switched media by setting the port number to zero in the answer.
オファーのSDPが、オファー側がパッシブパーティになることができるだけであることを示している場合、応答側はオファー側のE.164番号がオファーの「c =」行に含まれていることを確認する必要があります。番号が含まれている場合、回答者は回答に「setup」属性を含めて、「active」または「holdconn」の値に設定する必要があります。番号が含まれていない場合、オファーの受信者はコストやその他の理由に基づいてE.164に接続を確立する意思がなく、コールの確立は不可能であり、応答者は回線交換を拒否する必要があります回答でポート番号をゼロに設定することによってメディア。
If the SDP in the offer indicates that the offerer is able to become either the active or passive party, the answerer determines which role it will take. If the offer includes an international E.164 number in the "c=" line, the answerer SHOULD become the active party. If the answerer does not become the active party and if the answerer is aware of its E.164 number, it MUST become the passive party. If the answerer does not become the active or the passive party, it MUST reject the circuit-switched media by setting the port number to zero in the answer.
オファー内のSDPが、オファー側がアクティブパーティまたはパッシブパーティのいずれかになることができることを示している場合、アンサーはそれが担う役割を決定します。オファーの「c =」行に国際E.164番号が含まれている場合、回答者がアクティブパーティになる必要があります。回答者がアクティブパーティにならない場合、および回答者がそのE.164番号を認識している場合、それはパッシブパーティになる必要があります。回答者がアクティブまたはパッシブパーティにならない場合、回答でポート番号をゼロに設定することにより、回線交換メディアを拒否する必要があります。
For each media description where the offer includes a "cs-correlation" attribute, the answerer MUST select from the offer those correlation mechanisms it supports and include in the answer one "a=cs-correlation" attribute line containing those mechanisms it is willing to use. The answerer MUST only add one "cs-correlation" attribute in those media descriptions where also the offer included a "cs-correlation" attribute. The answerer MUST NOT add any mechanisms that were not included in the offer. If there is more than one "cs-correlation" attribute per media description in the offer, the answerer MUST discard all but the first for any media description. Also, the answerer MUST discard all unknown "cs-correlation" attribute values.
オファーに「cs-correlation」属性が含まれている各メディアの説明について、回答者は、オファーからサポートする相関メカニズムを選択し、回答に、意図するメカニズムを含む1つの「a = cs-correlation」属性行を含める必要があります。使用する。回答者は、オファーに「cs-correlation」属性も含まれているメディアの説明に「cs-correlation」属性を1つだけ追加する必要があります。回答者は、オファーに含まれていないメカニズムを追加してはなりません。オファーのメディア記述ごとに複数の「cs-correlation」属性がある場合、回答者は、メディア記述の最初のものを除いてすべてを破棄する必要があります。また、アンサーはすべての不明な「cs-correlation」属性値を破棄する必要があります。
If the answerer becomes the active party, it MUST add a value to any of the possible subfields.
回答者がアクティブパーティになる場合、可能なサブフィールドのいずれかに値を追加する必要があります。
If the answerer becomes the passive party, it MUST NOT add any values to the subfields in the "cs-correlation" attribute.
回答者がパッシブパーティになる場合、「cs-correlation」属性のサブフィールドに値を追加してはなりません（MUST NOT）。
After generating and sending the answer, if the answerer became the active party, it
回答を生成して送信した後、回答者がアクティブパーティーになった場合、
o MUST extract the E.164 number from the "c=" line of the offer and MUST establish a circuit-switched bearer to that address.
o オファーの「c =」行からE.164番号を抽出し、そのアドレスへの回線交換ベアラを確立する必要があります。
o if the SDP answer contained a value for the "callerid" subfield, MUST set the Calling Party Number Information Element to that number.
o SDP応答に「callerid」サブフィールドの値が含まれている場合、発番号情報要素をその番号に設定する必要があります。
o if the SDP answer contained a value for the "uuie" subfield, MUST send the User-User Information Element according to the rules defined for the circuit-switched technology used and set the value of the Information Element to that received in the SDP offer.
o SDP回答に「uuie」サブフィールドの値が含まれている場合は、使用される回線交換テクノロジー用に定義されたルールに従ってユーザー/ユーザー情報要素を送信し、情報要素の値をSDPオファーで受信した値に設定する必要があります。
o if the SDP answer contained a value for the "dtmf" subfield, MUST send those DTMF digits according to the circuit-switched technology used.
o SDP回答に「dtmf」サブフィールドの値が含まれている場合は、使用されている回線交換テクノロジーに従って、それらのDTMFディジットを送信する必要があります。
If, on the other hand, the answerer became the passive party, it
一方、回答者がパッシブパーティーになった場合、
o MUST be prepared to receive a circuit-switched bearer,
o 回線交換ベアラーを受信する準備ができていなければなりません。
o if the offer contained a value for the "callerid" subfield, MUST compare that value to the Calling Party Number Information Element of the circuit-switched bearer. If the received Calling Party Number Information Element matches the value of the "callerid" subfield, the call SHOULD be treated as correlated to the ongoing session.
o オファーに「callerid」サブフィールドの値が含まれている場合、その値を回線交換ベアラの発番号情報要素と比較する必要があります。受信した発呼者番号情報要素が「callerid」サブフィールドの値と一致する場合、その呼び出しは、進行中のセッションに関連付けられているものとして扱われる必要があります（SHOULD）。
o if the offer contained a value for the "dtmf" subfield, MUST be prepared to receive and collect DTMF digits once the circuit-switched bearer is set up. The answerer MUST compare the received DTMF digits to the value of the "dtmf" subfield. If the received DTMF digits match the value of the "dtmf" subfield in the "cs-correlation" attribute, the call SHOULD be treated as correlated to the ongoing session.
o オファーに「dtmf」サブフィールドの値が含まれている場合は、回線交換ベアラがセットアップされたら、DTMFディジットを受信して収集する準備をしておく必要があります。回答者は、受信したDTMFディジットを「dtmf」サブフィールドの値と比較する必要があります。受信したDTMFディジットが「cs-correlation」属性の「dtmf」サブフィールドの値と一致する場合、コールは進行中のセッションに相関しているものとして扱われる必要があります。
o if the offer contained a value for the "uuie" subfield, MUST be prepared to receive a User-User Information Element once the circuit-switched bearer is set up. The answerer MUST compare the received UUIE to the value of the "uuie" subfield. If the value of the received UUIE matches the value of the "uuie" subfield, the call SHOULD be treated as correlated to the ongoing session.
o オファーに「uuie」サブフィールドの値が含まれている場合、回線交換ベアラがセットアップされたら、User-User情報要素を受信できるように準備する必要があります。回答者は、受信したUUIEを「uuie」サブフィールドの値と比較する必要があります。受信したUUIEの値が「uuie」サブフィールドの値と一致する場合、呼び出しは進行中のセッションに関連付けられているものとして扱われる必要があります（SHOULD）。
o if the offer contained an "external" subfield, MUST be prepared to receive a circuit-switched call and use the external means (typically, the human user) for accepting or rejecting the call.
o オファーに「外部」サブフィールドが含まれている場合は、回線交換呼び出しを受信し、外部の手段（通常は人間のユーザー）を使用して呼び出しを承諾または拒否できるように準備する必要があります。
If the answerer becomes the active party, generates an SDP answer, and then it finds out that the circuit-switched call cannot be established, then the answerer MUST create a new SDP offer where the circuit-switched stream is removed from the session (actually, by setting the corresponding port in the "m=" line to zero) and send it to its counterpart. This is to synchronize both parties (and potential intermediaries) on the state of the session.
応答側がアクティブパーティになり、SDP応答を生成し、回線交換コールを確立できないことが判明した場合、応答側は、回線交換ストリームがセッションから削除される新しいSDPオファーを作成する必要があります（実際には、 "m ="行の対応するポートをゼロに設定して）、対応するポートに送信します。これは、セッションの状態で両方の当事者（および潜在的な仲介者）を同期させるためです。
When receiving the answer, if the SDP does not contain an "a=cs-correlation" attribute line, the offerer should take that as an indication that the other party does not support or is not willing to use the procedures defined in the document for this session and MUST revert to normal processing of SDP.
回答を受け取ったときに、SDPに「a = cs-correlation」属性行が含まれていない場合、提供者は、それを相手がドキュメントで定義されている手順をサポートしていないか、または使用する意思がないことを示すものと見なす必要があります。このセッションは、SDPの通常の処理に戻さなければなりません。
When receiving the answer, the offerer MUST first determine whether it becomes the active or passive party, as described in Section 5.3.1.
回答を受け取ると、オファーは最初に、それがアクティブパーティになるかパッシブパーティになるかをセクション5.3.1で説明されているように決定する必要があります。
If the offerer becomes the active party, it
提案者がアクティブパーティーになると、
o MUST extract the E.164 number from the "c=" line and MUST establish a circuit-switched bearer to that address.
o 「c =」行からE.164番号を抽出する必要があり、そのアドレスへの回線交換ベアラを確立する必要があります。
o if the SDP answer contained a value for the "uuie" subfield, MUST send the User-User Information Element according to the rules defined for the circuit-switched technology used and set the value of the Information Element to that received in the SDP answer.
o SDP回答に「uuie」サブフィールドの値が含まれている場合は、使用される回線交換テクノロジー用に定義されたルールに従ってユーザー/ユーザー情報要素を送信し、情報要素の値をSDP回答で受信したものに設定する必要があります。
o if the SDP answer contained a value for the "dtmf" subfield, MUST send those DTMF digits according to the circuit-switched technology used.
o SDP回答に「dtmf」サブフィールドの値が含まれている場合は、使用されている回線交換テクノロジーに従って、それらのDTMFディジットを送信する必要があります。
If the offerer becomes the passive party:
提案者がパッシブパーティーになる場合：
o It MUST be prepared to receive a circuit-switched bearer.
o 回線交換ベアラを受信できるように準備する必要があります。
o Note that if delivery of the answer is delayed for some reason, the circuit-switched call attempt may arrive at the offerer before the answer has been processed. In this case, since the correlation mechanisms are negotiated as part of the offer/answer exchange, the answerer cannot know whether or not the incoming circuit-switched call attempt is correlated with the session being negotiated; thus, the offerer SHOULD answer the circuit-switched call attempt only after it has received and processed the answer.
oなんらかの理由で回答の配信が遅れた場合、回線交換呼び出しが回答が処理される前にオファー側に到着する場合があることに注意してください。この場合、相関メカニズムはオファー/アンサー交換の一部としてネゴシエートされるため、応答者は、着信回線交換コールの試行がネゴシエートされているセッションと相関しているかどうかを知ることができません。したがって、提供者は、応答を受信して処理した後でのみ、回線交換コールの試行に応答する必要があります。
o If the answer contained a value for the "dtmf" subfield, the offerer MUST be prepared to receive and collect DTMF digits once the circuit-switched bearer is set up. The offerer SHOULD compare the received DTMF digits to the value of the "dtmf" subfield. If the received DTMF digits match the value of the "dtmf" subfield in the "cs-correlation" attribute, the call SHOULD be treated as correlated to the ongoing session.
o 回答に「dtmf」サブフィールドの値が含まれている場合は、回線交換ベアラーがセットアップされたら、提供者はDTMFディジットを受信して収集する準備をしている必要があります。提案者は、受信したDTMFディジットを「dtmf」サブフィールドの値と比較する必要があります（SHOULD）。受信したDTMFディジットが「cs-correlation」属性の「dtmf」サブフィールドの値と一致する場合、コールは進行中のセッションに相関しているものとして扱われる必要があります。
o If the answer contained a value for the "uuie" subfield, the offerer MUST be prepared to receive a User-User Information Element once the circuit-switched bearer is set up. The offerer SHOULD compare the received UUIE to the value of the "uuie" subfield. If the value of the received UUIE matches the value of the "uuie" subfield, the call SHOULD be treated as correlated to the ongoing session.
o 回答に「uuie」サブフィールドの値が含まれていた場合、回線交換ベアラーがセットアップされたら、オファー提供者はユーザー・ユーザー情報エレメントを受信する準備をしなければなりません（MUST）。提案者は、受信したUUIEを「uuie」サブフィールドの値と比較する必要があります（SHOULD）。受信したUUIEの値が「uuie」サブフィールドの値と一致する場合、呼び出しは進行中のセッションに関連付けられているものとして扱われる必要があります（SHOULD）。
o If the answer contained an "external" subfield, the offerer MUST be prepared to receive a circuit-switched call and use the external means (typically, the human user) for accepting or rejecting the call.
o 回答に「外部」サブフィールドが含まれている場合、提供者は、回線交換呼び出しを受信し、外部の手段（通常は人間のユーザー）を使用して呼び出しを承認または拒否する準備をしている必要があります。
According the "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264], the offerer needs to be ready to receive media as soon as the offer has been sent. It may happen that the answerer, if it became the active party, will initiate a circuit-switched bearer setup that will arrive at the offerer before the answer has arrived. However, the offerer needs to receive the answer and examine the information about the correlation mechanisms in order to successfully perform correlation of the circuit-switched call to the session. Therefore, if the offerer receives an incoming circuit-switched call, it MUST NOT accept the call before the answer has been received. If no answer is received during an implementation-specific time, the offerer MUST either modify the session according to [RFC3264] or terminate it according to the session signaling procedures in question (for terminating a SIP session, see Section 15 of [RFC3261]).
「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」[RFC3264]によると、オファーが送信されるとすぐに、オファー者はメディアを受信する準備ができている必要があります。回答者がアクティブパーティになった場合、回答が到着する前に提供者に到着する回線交換ベアラセットアップを開始することがあります。ただし、サーチャスイッチドコールとセッションの相関を正常に実行するには、オファーを受信して相関メカニズムに関する情報を確認する必要があります。したがって、提供者が着信回線交換コールを受信した場合、回答を受信する前にそのコールを受け入れてはなりません。実装固有の時間内に応答が受信されない場合、提供者は[RFC3264]に従ってセッションを変更するか、問題のセッションシグナリング手順に従ってセッションを終了する必要があります（SIPセッションの終了については、[RFC3261]のセクション15を参照）。 。
If, at a later time, one of the parties wishes to modify the session, e.g., by adding a new media stream or by changing properties used on an existing stream, it may do so via the mechanisms defined in "An Offer/Answer Model with the Session Description Protocol (SDP)" [RFC3264].
後で、一方の当事者が、たとえば新しいメディアストリームを追加したり、既存のストリームで使用されているプロパティを変更したりして、セッションを変更したい場合は、「オファー/アンサーモデル」で定義されたメカニズムを介して行うことができます。セッション記述プロトコル（SDP）を使用して」[RFC3264]。
If there is an existing circuit-switched bearer between the endpoints and the offerer wants to reuse that, the offerer MUST set the value of the "connection" attribute to "existing".
エンドポイント間に既存の回線交換ベアラーがあり、それを再利用したい場合、オファー者は「接続」属性の値を「既存」に設定する必要があります。
If either party removes the circuit-switched media from the session (by setting the port number to zero), it MUST terminate the circuit-switched bearer using whatever mechanism is appropriate for the technology in question.
いずれかの当事者が（ポート番号をゼロに設定することにより）回線交換メディアをセッションから削除する場合、問題のテクノロジーに適切なメカニズムを使用して回線交換ベアラを終了しなければなりません（MUST）。
If either party wishes to drop and reestablish an existing call, that party MUST first remove the circuit-switched media from the session by setting the port number to zero and then use another offer/answer exchange where it MUST set the "connection" attribute to "new". If the media types are different (for example, a different codec will be used for the circuit-switched bearer), the media descriptions for terminating the existing bearer and the new bearer can be in the same offer.
いずれかのパーティが既存のコールをドロップして再確立したい場合、そのパーティは最初にポート番号をゼロに設定して回線交換メディアを削除し、次に「接続」属性を設定する必要がある別のオファー/アンサー交換を使用する必要があります。 "新着"。メディアタイプが異なる場合（たとえば、回線交換ベアラに異なるコーデックが使用される場合）、既存のベアラと新しいベアラを終了するためのメディアの説明は、同じオファーである可能性があります。
If either party would like to remove existing RTP-based media from the session and replace that with a circuit-switched bearer, it would create a new offer to add the circuit-switched media as described in Section 5.6.1 above, replacing the RTP-based media description with the circuit-switched media description, as specified in RFC 3264 [RFC3264].
いずれかの当事者がセッションから既存のRTPベースのメディアを削除し、それを回線交換ベアラーに置き換える場合、上記のセクション5.6.1で説明されているように、回線交換メディアを追加する新しいオファーを作成し、RTPを置き換えます。 RFC 3264 [RFC3264]で指定されている、回線交換メディア記述を使用した、ベースのメディア記述。
Once the offer/answer exchange is done, but the circuit-switched bearer is not yet established, there may be a period of time when no media is available. Also, it may happen that correlating the circuit-switched call fails for reasons discussed in Section 5.3.3. In this case, even if the offer/answer exchange was successful, endpoints are not able to receive or send media. It is up to the implementation to decide the behavior in this case; if nothing else is done, the user most likely hangs up after a while if there is no other media in the session. Note that this may also happen when switching from one RTP media to another RTP media (for example, when firewall blocks the new media stream).
オファー/アンサーの交換が完了しても、回線交換ベアラがまだ確立されていない場合は、使用可能なメディアがない期間がある可能性があります。また、5.3.3で説明した理由により、回線交換コールの関連付けが失敗する場合もあります。この場合、オファー/アンサーの交換が成功しても、エンドポイントはメディアを送受信できません。この場合の動作を決定するのは実装次第です。他に何も行われない場合、セッション内に他のメディアがないと、ユーザーはしばらくして電話を切る可能性があります。これは、あるRTPメディアから別のRTPメディアに切り替えるときにも発生する可能性があることに注意してください（たとえば、ファイアウォールが新しいメディアストリームをブロックする場合）。
If either party would like to remove existing circuit-switched media from the session and replace that with RTP-based media, it would modify the media description as per the procedures defined in RFC 3264 [RFC3264]. The endpoint MUST then terminate the circuit-switched bearer using whatever mechanism is appropriate for the technology in question.
いずれかの当事者がセッションから既存の回線交換メディアを削除し、それをRTPベースのメディアに置き換える場合、RFC 3264 [RFC3264]で定義されている手順に従ってメディアの説明を変更します。次に、エンドポイントは、問題のテクノロジーに適切なメカニズムを使用して、回線交換ベアラを終了する必要があります。
The following is the formal Augmented Backus-Naur Form (ABNF) [RFC5234] syntax that supports the extensions defined in this specification. The syntax is built above the SDP [RFC4566] and the tel URI [RFC3966] grammars. Implementations that are compliant with this specification MUST be compliant with this syntax.
以下は、この仕様で定義されている拡張機能をサポートする正式な拡張バッカスナウアフォーム（ABNF）[RFC5234]構文です。構文は、SDP [RFC4566]およびtel URI [RFC3966]文法の上に構築されています。この仕様に準拠する実装は、この構文に準拠する必要があります。
Figure 2 shows the formal syntax of the extensions defined in this memo.
図2は、このメモで定義された拡張の正式な構文を示しています。
; extension to the connection field originally specified ; in RFC 4566
;最初に指定された接続フィールドの拡張。 RFC 4566
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
; CRLF defined in RFC 5234
;nettype and addrtype are defined in RFC 4566
; nettypeとaddrtypeはRFC 4566で定義されています
connection-address =/ global-number-digits / "-"
; global-number-digits specified in RFC 3966
;subrules for correlation attribute
attribute =/ cs-correlation-attr
; attribute defined in RFC 4566
cs-correlation-attr = "cs-correlation:" corr-mechanisms
corr-mechanisms = corr-mech *(SP corr-mech)
corr-mech = caller-id-mech / uuie-mech /
dtmf-mech / external-mech /
ext-mech
caller-id-mech = "callerid" [":" caller-id-value]
caller-id-value = "+" 1*15DIGIT
; DIGIT defined in RFC 5234
uuie-mech = "uuie" [":" uuie-value]
uuie-value = 1*65(HEXDIG HEXDIG)
;This represents up to 130 HEXDIG
; (65 octets)
;HEXDIG defined in RFC 5234
;HEXDIG defined as 0-9, A-F
dtmf-mech = "dtmf" [":" dtmf-value]
dtmf-value = 1*32(DIGIT / %x41-44 / %x23 / %x2A )
;0-9, A-D, '#' and '*'
external-mech = "external"
ext-mech = ext-mech-name [":" ext-mech-value]
ext-mech-name = token
ext-mech-value = token
; token is specified in RFC 4566
Figure 2: Syntax of the SDP Extensions
図2：SDP拡張の構文
In the examples below, where an SDP line is too long to be displayed as a single line, a breaking character "\" indicates continuation in the following line. Note that this character is included for display purposes only. Implementations MUST write a single line without breaks.
以下の例では、SDP行が長すぎて1行として表示できない場合、改行文字「\」は次の行に続くことを示します。この文字は表示目的でのみ含まれていることに注意してください。実装では、改行なしで1行を記述する必要があります。
Endpoint A Endpoint B
| |
| (1) SDP offer (PSTN audio) |
|--------------------------------->|
| |
| (2) SDP answer (PSTN audio) |
|<---------------------------------|
| |
| PSTN call setup |
|<---------------------------------|
| |
|<==== media over PSTN bearer ====>|
| |
Figure 3: Basic Flow
図3：基本フロー
Figure 3 shows a basic example that describes a single audio media stream over a circuit-switched bearer. Endpoint A generates an SDP offer, which is shown in Figure 4. The offer describes a PSTN circuit-switched bearer in the "m=" and "c=" line where it also indicates its international E.164 number format. Additionally, Endpoint A expresses that it can initiate the circuit-switched bearer or be the recipient of it in the "a=setup" attribute line. The SDP offer also includes correlation identifiers that this endpoint will insert in the Calling Party Number and/or User-User Information Element of the PSTN call setup if eventually this endpoint initiates the PSTN call. Endpoint A also includes "external" as one correlation mechanism, indicating that it can use the human user to perform correlation in case other mechanisms fail.
図3は、回線交換ベアラを介した単一のオーディオメディアストリームを説明する基本的な例を示しています。エンドポイントAはSDPオファーを生成します。これは図4に示されています。オファーは、国際E.164番号形式も示す「m =」および「c =」行のPSTN回線交換ベアラを記述しています。さらに、エンドポイントAは、「a = setup」属性行で、回線交換ベアラーを開始したり、その受信者になったりできることを示しています。 SDPオファーには、最終的にこのエンドポイントがPSTNコールを開始した場合に、このエンドポイントがPSTNコールセットアップの発呼者番号やユーザー-ユーザー情報要素に挿入する相関識別子も含まれます。エンドポイントAには1つの相関メカニズムとして「外部」も含まれており、他のメカニズムが失敗した場合に人間のユーザーを使用して相関を実行できることを示します。
v=0
o=alice 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +441134960123
a=setup:actpass
a=connection:new
a=cs-correlation:callerid:+441134960123 \
uuie:56A390F3D2B7310023 external
Figure 4: SDP Offer (1)
図4：SDPオファー（1）
Endpoint B generates an SDP answer (Figure 5), describing a PSTN audio media on port 9 without information on the media subtype on the "m=" line. The "c=" line contains B's international E.164 number. In the "a=setup" line, Endpoint B indicates that it is willing to become the active endpoint when establishing the PSTN call, and it also includes the "a=cs-correlation" attribute line containing the values it is going to include in the Calling Party Number and User-User Information Element of the PSTN call establishment. Endpoint B is also able to perform correlation by external means, in case other correlation mechanisms fail.
エンドポイントBは、「m =」行のメディアサブタイプに関する情報なしで、ポート9のPSTNオーディオメディアを記述するSDP回答（図5）を生成します。 「c =」行には、Bの国際E.164番号が含まれています。 「a = setup」行のエンドポイントBは、PSTNコールを確立するときにアクティブエンドポイントになることをいとわないことを示し、「a = cs-correlation」属性行に含まれます。 PSTNコール確立の発呼者番号とユーザー/ユーザー情報要素。エンドポイントBは、他の相関メカニズムが失敗した場合に備えて、外部の手段によって相関を実行することもできます。
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
m=audio 9 PSTN -
c=PSTN E164 +441134960124
a=setup:active
a=connection:new
a=cs-correlation:callerid:+441134960124 \
uuie:74B9027A869D7966A2 external
Figure 5: SDP Answer with Circuit-Switched Media
図5：回線交換メディアを使用したSDP回答
When Endpoint A receives the answer, it examines that B is willing to become the active endpoint when setting up the PSTN call. Endpoint A temporarily stores B's E.164 number and the User-User IE value of the "cs-correlation" attribute and waits for a circuit-switched bearer establishment.
エンドポイントAが応答を受信すると、PSTNコールをセットアップするときに、Bがアクティブエンドポイントになる意思があるかどうかを調べます。エンドポイントAは、BのE.164番号と「cs-correlation」属性のUser-User IE値を一時的に格納し、回線交換ベアラの確立を待ちます。
Endpoint B initiates a circuit-switched bearer using whatever circuit-switched technology is available for it. The Called Party Number is set to A's number, and the Calling Party Number is set to B's own number. Endpoint B also sets the User-User Information Element value to the one contained in the SDP answer.
エンドポイントBは、使用可能な回線交換テクノロジーを使用して、回線交換ベアラーを開始します。着信者番号はAの番号に設定され、発信者番号はB自身の番号に設定されます。エンドポイントBは、User-User Information Element値をSDP回答に含まれている値に設定します。
When Endpoint A receives the circuit-switched bearer establishment, it examines the UUIE and the Calling Party Number and, by comparing those received during the offer/answer exchange, determines that the call is related to the SDP session.
エンドポイントAが回線交換ベアラ確立を受信すると、UUIEと発信者番号を調べ、オファー/アンサー交換中に受信したものを比較することにより、コールがSDPセッションに関連していると判断します。
It may also be that neither the UUIE nor the Calling Party Number is received by the called party, or the format of the Calling Party Number is changed by the PSTN. Implementations may still accept such call establishment attempts as being related to the session that was established in the IP network. As it cannot be guaranteed that the values used for correlation are always passed intact through the network, they should be treated as additional hints that the circuit-switched bearer is actually related to the session.
また、UUIEと発信者番号のどちらも着信者が受信していないか、または発信者番号の形式がPSTNによって変更されている可能性もあります。実装は、IPネットワークで確立されたセッションに関連するものとして、そのようなコール確立試行を引き続き受け入れる場合があります。相関に使用される値がネットワークを介して常に渡されることは保証されないため、これらの値は、回線交換ベアラが実際にセッションに関連しているという追加のヒントとして扱う必要があります。
Endpoint A Endpoint B
| |
| (1) SDP offer (PSTN audio and video) |
|------------------------------------------->|
| |
| (2) SDP answer (PSTN audio) |
|<-------------------------------------------|
| |
| PSTN call setup |
|<-------------------------------------------|
| |
|<======== media over PSTN bearer ==========>|
| |
Figure 6: Circuit-Switched Audio and Video Streams
図6：回線交換オーディオおよびビデオストリーム
Figure 6 shows an example of negotiating audio and video media streams over circuit-switched bearers.
図6は、回線交換ベアラを介したオーディオおよびビデオメディアストリームのネゴシエーションの例を示しています。
v=0
o=alice 2890844526 2890842807 IN IP4 192.0.2.5
s=
t=0 0
a=setup:actpass
a=connection:new
c=PSTN E164 +441134960123
m=audio 9 PSTN -
a=cs-correlation:dtmf:1234536
m=video 9 PSTN 34
a=rtpmap:34 H263/90000
a=cs-correlation:callerid:+441134960123
Figure 7: SDP Offer with Circuit-Switched Audio and Video (1)
図7：SDPオファーと回線交換オーディオおよびビデオ（1）
Upon receiving the SDP offer described in Figure 7, Endpoint B rejects the video stream as the device does not currently support video, but it accepts the circuit-switched audio stream. As Endpoint A indicated that it is able to become either the active or passive party, Endpoint B gets to select which role it would like to take. Since the offer contained the international E.164 number of Endpoint A, Endpoint B decides that it becomes the active party in setting up the circuit-switched bearer. B includes a new value in the "dtmf" subfield of the "cs-correlation" attribute, which it is going to send as DTMF tones once the bearer setup is complete. The answer is described in Figure 8.
図7で説明されているSDPオファーを受信すると、デバイスは現在ビデオをサポートしていないため、エンドポイントBはビデオストリームを拒否しますが、回線交換オーディオストリームは受け入れます。エンドポイントAがアクティブパーティまたはパッシブパーティになることができることを示したので、エンドポイントBは、実行する役割を選択します。オファーにはエンドポイントAの国際E.164番号が含まれていたため、エンドポイントBは、回線交換ベアラの設定でアクティブパーティになることを決定します。 Bは、「cs-correlation」属性の「dtmf」サブフィールドに新しい値を含めます。この値は、ベアラのセットアップが完了すると、DTMFトーンとして送信されます。その答えを図8に示します。
v=0
o=- 2890973824 2890987289 IN IP4 192.0.2.7
s=
t=0 0
a=setup:active
a=connection:new
c=PSTN E164 +441134960124
m=audio 9 PSTN -
a=cs-correlation:dtmf:654321
m=video 0 PSTN 34
a=cs-correlation:callerid:+441134960124
Figure 8: SDP Answer with Circuit-Switched Audio and Video (2)
図8：回線交換オーディオとビデオによるSDP応答（2）
This document provides an extension to RFC 4566 [RFC4566] and RFC 3264 [RFC3264]. As such, the security considerations of those documents apply.
このドキュメントは、RFC 4566 [RFC4566]およびRFC 3264 [RFC3264]の拡張機能を提供します。そのため、これらのドキュメントのセキュリティに関する考慮事項が適用されます。
This memo provides mechanisms to agree on a correlation identifier or identifiers that are used to evaluate whether an incoming circuit-switched bearer is related to an ongoing session in the IP domain. If an attacker replicates the correlation identifier and establishes a call within the time window the receiving endpoint is expecting a call, the attacker may be able to hijack the circuit-switched bearer. These types of attacks are not specific to the mechanisms presented in this memo. For example, Caller ID spoofing is a well-known attack in the PSTN. Users are advised to use the same caution before revealing sensitive information as they would on any other phone call. Furthermore, users are advised that mechanisms that may be in use in the IP domain for securing the media, like Secure RTP (SRTP) [RFC3711], are not available in the CS domain.
このメモは、着信回線交換ベアラがIPドメインで進行中のセッションに関連しているかどうかを評価するために使用される1つまたは複数の相関識別子について合意するメカニズムを提供します。攻撃者が相関識別子を複製し、受信エンドポイントが通話を予期している時間枠内に通話を確立すると、攻撃者は回線交換ベアラを乗っ取ることができる可能性があります。これらのタイプの攻撃は、このメモに示されているメカニズムに固有のものではありません。たとえば、発信者IDのスプーフィングはPSTNのよく知られた攻撃です。ユーザーは、他の電話と同じように機密情報を公開する前に同じ注意を払うことをお勧めします。さらに、ユーザーは、Secure RTP（SRTP）[RFC3711]など、メディアを保護するためにIPドメインで使用されている可能性のあるメカニズムは、CSドメインでは使用できないことをお勧めします。
For the purposes of establishing a circuit-switched bearer, the active endpoint needs to know the passive endpoint's phone number. Phone numbers are sensitive information, and some people may choose not to reveal their phone numbers when calling using supplementary services like Calling Line Identification Restriction (CLIR) in GSM. Implementations should take the caller's preferences regarding calling line identification into account if possible, by restricting the inclusion of the phone number in the SDP "c=" line if the caller has chosen to use CLIR. If this is not possible, implementations may present a prompt informing the user that their phone number may be transmitted to the other party.
回線交換ベアラを確立するために、アクティブエンドポイントはパッシブエンドポイントの電話番号を知っている必要があります。電話番号は機密情報であり、GSMのCalling Line Identification Restriction（CLIR）などの補足サービスを使用して電話をかけるときに、電話番号を公開しないことを選択する場合があります。実装は、発信者がCLIRを使用することを選択した場合、SDP "c ="回線への電話番号の組み込みを制限することにより、可能であれば、発信者の識別に関する発信者の設定を考慮する必要があります。これが不可能な場合、実装は、電話番号が相手に送信される可能性があることをユーザーに通知するプロンプトを表示する場合があります。
As with IP addresses, if there is a desire to protect the SDP containing phone numbers carried in SIP, implementers are advised to follow the security mechanisms defined in [RFC3261].
IPアドレスと同様に、SIPで運ばれる電話番号を含むSDPを保護したい場合、実装者は[RFC3261]で定義されているセキュリティメカニズムに従うことをお勧めします。
It is possible that an attacker creates a circuit-switched session whereby the attacked endpoint should dial a circuit-switched number, perhaps even a premium-rate telephone number. To mitigate the consequences of this attack, endpoints MUST authenticate and trust remote endpoints users who try to remain passive in the circuit-switched connection establishment. It is RECOMMENDED that endpoints have local policies precluding the active establishment of circuit-switched connections to certain numbers (e.g., international, premium, and long distance). Additionally, it is strongly RECOMMENDED that the end user is asked for consent prior to the endpoint initiating a circuit-switched connection.
攻撃者が回線交換セッションを作成し、攻撃されたエンドポイントが回線交換番号、おそらくプレミアムレートの電話番号をダイヤルする可能性があります。この攻撃の影響を緩和するために、エンドポイントは、回線交換接続の確立でパッシブを維持しようとするリモートエンドポイントのユーザーを認証および信頼する必要があります。エンドポイントには、特定の番号（国際、プレミアム、長距離など）への回線交換接続のアクティブな確立を妨げるローカルポリシーがあることをお勧めします。さらに、エンドポイントが回線交換接続を開始する前に、エンドユーザーに同意を求めることを強くお勧めします。
IANA has registered a number of SDP tokens according to the following data.
IANAは、以下のデータに従って、いくつかのSDPトークンを登録しています。
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Attribute name: cs-correlation
属性名：cs-correlation
Long-form attribute name: PSTN Correlation Identifier
長い形式の属性名：PSTN相関識別子
Type of attribute: media level only
属性のタイプ：メディアレベルのみ
Subject to charset: No
文字セットの対象：いいえ
Description: This attribute provides the Correlation Identifier used in PSTN signaling
説明：この属性は、PSTNシグナリングで使用される相関識別子を提供します
Appropriate values: see Section 5.2.3.1
適切な値：セクション5.2.3.1を参照
Specification: RFC 7195
仕様：RFC 7195
The IANA has created a subregistry for the "cs-correlation" attribute under the "Session Description Protocol (SDP) Parameters" registry. The initial values for the subregistry are presented in the following; IANA has registered these values accordingly:
IANAは、「Session Description Protocol（SDP）Parameters」レジストリの下に「cs-correlation」属性のサブレジストリを作成しました。サブレジストリの初期値は次のとおりです。 IANAはこれらの値を適宜登録しています。
Value of "cs-correlation" attribute Reference Description
----------------------------------- --------- -------------------
callerid RFC 7195 Caller ID
uuie RFC 7195 User-User
Information Element
dtmf RFC 7195 Dual-Tone
Multi-Frequency
external RFC 7195 External
As per the terminology in [RFC5226], the registration policy for new values of the "cs-correlation" attribute is "Specification Required".
[RFC5226]の用語に従って、「cs-correlation」属性の新しい値の登録ポリシーは「Specification Required」です。
IANA has registered a new "nettype" in the "Session Description Protocol (SDP) Parameters" registry [IANA]. The registration data, according to RFC 4566 [RFC4566], is as follows.
IANAは、「Session Description Protocol（SDP）Parameters」レジストリ[IANA]に新しい「nettype」を登録しました。 RFC 4566 [RFC4566]による登録データは次のとおりです。
Type SDP Name Reference
-------------- ------------------ ---------
nettype PSTN RFC 7195
IANA has registered a new "addrtype" in the "Session Description Protocol (SDP) Parameters" registry [IANA]. The registration data, according to RFC 4566 [RFC4566], is as follows.
IANAは、「Session Description Protocol（SDP）Parameters」レジストリ[IANA]に新しい「addrtype」を登録しました。 RFC 4566 [RFC4566]による登録データは次のとおりです。
Type SDP Name Reference
-------------- ------------------ ---------
addrtype E164 RFC 7195
Note: This document defines the "E164" addrtype in the context of the "PSTN" nettype only. RFC 3108 [RFC3108] also defines address type "E.164". This definition is distinct from the one defined by this memo and shall not be used with <nettype> "PSTN".
注：このドキュメントでは、「PSTN」ネットタイプのコンテキストでのみ「E164」addrtypeを定義しています。 RFC 3108 [RFC3108]もアドレスタイプ「E.164」を定義しています。この定義は、このメモで定義されたものとは異なり、<nettype> "PSTN"では使用されません。
IANA has registered a new "proto" in the "Session Description Protocol (SDP) Parameters" registry [IANA]. The registration data, according to RFC 4566 [RFC4566], is as follows.
IANAは、「Session Description Protocol（SDP）Parameters」レジストリ[IANA]に新しい「proto」を登録しました。 RFC 4566 [RFC4566]による登録データは次のとおりです。
Type SDP Name Reference
-------------- ------------------ ---------
proto PSTN RFC 7195
The related "fmt" namespace reuses the conventions and payload type number defined for RTP/AVP. In this document, the RTP audio and video media types, when applied to PSTN circuit-switched bearers, represent merely an audio or video codec in its native format directly on top of a single PSTN bearer.
関連する「fmt」名前空間は、RTP / AVPに定義された規則とペイロードタイプ番号を再利用します。このドキュメントでは、RTPオーディオおよびビデオメディアタイプをPSTN回線交換ベアラーに適用すると、単一のPSTNベアラーのすぐ上のネイティブ形式のオーディオまたはビデオコーデックのみを表します。
In some cases, the endpoint is not able to determine the list of available codecs for circuit-switched media streams. In this case, in order to be syntactically compliant with SDP [RFC4566], the endpoint MUST include a single dash ("-") in the <fmt> subfield.
場合によっては、エンドポイントは回線交換メディアストリームに使用可能なコーデックのリストを決定できません。この場合、SDP [RFC4566]に構文的に準拠するために、エンドポイントは<fmt>サブフィールドに単一のダッシュ（ "-"）を含める必要があります。
The authors want to thank Paul Kyzivat, Flemming Andreasen, Thomas Belling, John Elwell, Jari Mutikainen, Miikka Poikselka, Jonathan Rosenberg, Ingemar Johansson, Christer Holmberg, Alf Heidermark, Tom Taylor, Thomas Belling, Keith Drage, and Andrew Allen for providing their insight and comments on this document.
著者は、Paul Kyzivat、Flemming Andreasen、Thomas Belling、John Elwell、Jari Mutikainen、Miikka Poikselka、Jonathan Rosenberg、Ingemar Johansson、Christer Holmberg、Alf Heidermark、Tom Taylor、Thomas Belling、Keith Drage、およびAndrew Allenに提供してくれたことに感謝しますこのドキュメントに関する洞察とコメント。
[ITU.Q931.1998] International Telecommunications Union, "Digital Subscriber Signalling System No. 1 - ISDN User-Network Interface Layer 3 Specification for Basic Call Control", ITU-T Recommendation Q931, May 1998.
[ITU.Q931.1998] International Telecommunications Union、「Digital Subscriber Signaling System No. 1-ISDN User-Network Interface Layer 3 Specification for Basic Call Control」、ITU-T Recommendation Q931、1998年5月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「オファー/アンサーモデルとセッション記述プロトコル（SDP）」、RFC 3264、2002年6月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966] Schulzrinne、H。、「電話番号のtel URI」、RFC 3966、2004年12月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon、D。、およびG. Camarillo、「セッション記述プロトコル（SDP）におけるTCPベースのメディア転送」、RFC 4145、2005年9月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[IANA] IANA, "Session Description Protocol (SDP) Parameters Registry", <http://www.iana.org/assignments/ sdp-parameters>.
[IANA] IANA、「Session Description Protocol（SDP）Parameters Registry」、<http://www.iana.org/assignments/ sdp-parameters>。
[ITU.E164.2010] International Telecommunications Union, "The International Public Telecommunication Numbering Plan", ITU-T Recommendation E.164, 2010.
[ITU.E164.2010]国際電気通信連合、「国際公衆電気通信番号計画」、ITU-T勧告E.164、2010。
[ITU.Q23.1988] International Telecommunications Union, "Technical features of push-button telephone sets", ITU-T Technical Recommendation Q.23, 1988.
[ITU.Q23.1988]国際電気通信連合、「プッシュボタン式電話機の技術的特徴」、ITU-T技術勧告Q.23、1988。
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001.
[RFC3108] Kumar、R。およびM. Mostafa、「ATMベアラ接続用のセッション記述プロトコル（SDP）の使用に関する規約」、RFC 3108、2001年5月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[RFC3551] Schulzrinne、H。およびS. Casner、「最小制御のオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「Session Initiation Protocol（SIP）でのサードパーティコール制御（3pcc）のベストプラクティス」、BCP 85、RFC 3725 、2004年4月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「メッセージセッションリレープロトコル（MSRP）」、RFC 4975、2007年9月。
[SIP-UUI] Johnston, A. and J. Rafferty, "A Mechanism for Transporting User to User Call Control Information in SIP", Work in Progress, April 2014.
[SIP-UUI]ジョンストンA.およびJ.ラファティ、「SIPでユーザーからユーザーへの呼制御情報を転送するためのメカニズム」、進行中の作業、2014年4月。
[TS.24.008] 3GPP, "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3", 3GPP TS 24.008 3.20.0, December 2005.
[TS.24.008] 3GPP、「モバイル無線インターフェースレイヤー3仕様、コアネットワークプロトコル、ステージ3」、3GPP TS 24.008 3.20.0、2005年12月。
Authors' Addresses
著者のアドレス
Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid, ES 28033 Spain
ミゲルA.ガルシアマルティンエリクソンCalle Via de los Poblados 13マドリード、ES 28033スペイン
EMail: miguel.a.garcia@ericsson.com
Simo Veikkolainen Nokia P.O. Box 226 NOKIA GROUP, FI 00045 Finland
Simo Veikkolainen Nokia P.O.ボックス226 NOKIA GROUP、FI 00045フィンランド
Phone: +358 50 486 4463
EMail: simo.veikkolainen@nokia.com