[要約] RFC 3959は、SIP（Session Initiation Protocol）の早期セッションの処理タイプに関する規格です。このRFCの目的は、SIPセッションの処理方法を改善し、通信の効率性を向上させることです。
Network Working Group G. Camarillo
Request for Comments: 3959 Ericsson
Category: Standards Track December 2004
The Early Session Disposition Type for the Session Initiation Protocol (SIP)
セッション開始プロトコル (SIP) の初期セッション処理タイプ
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
Abstract
概要
This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs.
この文書は、Session Initiation Protocol (SIP) の Content-Disposition ヘッダー フィールドの新しい処理タイプ (初期セッション) を定義します。「初期セッション」ボディの処理は、「セッション」ボディの処理と同様です。つまり、オファー/アンサー モデルに従います。それらの唯一の違いは、通常のダイアログ内の通常のセッションとは対照的に、性質タイプが「初期セッション」であるセッション記述は、初期のダイアログ内で初期のメディア セッションを確立するために使用されることです。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Issues Related to Early Media Session Establishment . . . . . 2
4. The Early Session Disposition Type . . . . . . . . . . . . . . 4
5. Preconditions . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Option tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informational References . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
Early media refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user. Within a dialog, early media occurs from the moment the initial INVITE is sent until the User Agent Server (UAS) generates a final response. It may be unidirectional or bidirectional, and can be generated by the caller, the callee, or both. Typical examples of early media generated by the callee are ringing tone and announcements (e.g., queuing status). Early media generated by the caller typically consists of voice commands or dual tone multi-frequency (DTMF) tones to drive interactive voice response (IVR) systems.
初期メディアとは、特定のセッションが呼び出されたユーザーによって受け入れられる前に交換されるメディア (オーディオやビデオなど) を指します。ダイアログ内では、最初の INVITE が送信された瞬間からユーザー エージェント サーバー (UAS) が最終応答を生成するまで、初期メディアが発生します。これは一方向または双方向の場合があり、呼び出し元、呼び出し先、またはその両方によって生成されます。着信者によって生成される初期メディアの典型的な例は、着信音やアナウンス (キューイング ステータスなど) です。発信者によって生成される初期のメディアは通常、音声コマンドまたは自動音声応答 (IVR) システムを駆動するデュアル トーン多重周波数 (DTMF) トーンで構成されます。
The basic SIP specification (RFC 3261 [2]) only supports very simple early media mechanisms. These simple mechanisms have a number of problems related to forking and security, and do not satisfy the requirements of most applications. RFC 3960 [8] goes beyond the mechanisms defined in RFC 3261 [2] and describes two models of early media using SIP: the gateway model and the application server model.
基本的な SIP 仕様 (RFC 3261 [2]) は、非常に単純な初期のメディア メカニズムのみをサポートしています。これらの単純なメカニズムには、フォークとセキュリティに関連する多くの問題があり、ほとんどのアプリケーションの要件を満たしていません。RFC 3960 [8] は、RFC 3261 [2] で定義されているメカニズムを超えており、SIP を使用する初期メディアの 2 つのモデル、つまりゲートウェイ モデルとアプリケーション サーバー モデルについて説明しています。
Although both early media models described in RFC 3960 [8] are superior to the one specified in RFC 3261 [2], the gateway model still presents a set of issues. In particular, the gateway model does not work well with forking. Nevertheless, the gateway model is needed because some SIP entities (in particular, some gateways) cannot implement the application server model.
RFC 3960 [8] で説明されている初期のメディア モデルはどちらも RFC 3261 [2] で指定されているものより優れていますが、ゲートウェイ モデルには依然として一連の問題が存在します。特に、ゲートウェイ モデルはフォークではうまく機能しません。それにもかかわらず、一部の SIP エンティティ (特に一部のゲートウェイ) はアプリケーション サーバー モデルを実装できないため、ゲートウェイ モデルが必要です。
The application server model addresses some of the issues present in the gateway model. This model uses the early-session disposition type specified in this document.
アプリケーション サーバー モデルは、ゲートウェイ モデルに存在する問題のいくつかに対処します。このモデルは、このドキュメントで指定されている初期セッションの性質タイプを使用します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
この文書では、「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨される」、「推奨されない」、「してもよい」というキーワードが使用されます。、および「OPTIONAL」は、BCP 14、RFC 2119 [1] に記載されているように解釈され、準拠する実装の要件レベルを示します。
Traditionally, early media sessions have been established in the same way as regular sessions. That is, using an offer/answer exchange where the disposition type of the session descriptions is "session". Application servers perform an offer/answer exchange with the User Agent Client (UAC) to exchange early media exclusively, while UASs use the same offer/answer exchange, first to exchange early media, and once the regular dialog is established, to exchange regular media. This way of establishing early media sessions is known as the gateway model [8], which presents some issues related to forking and security. These issues exist when this model is used by either an application server or by a UAS.
従来、初期のメディア セッションは通常のセッションと同じ方法で確立されてきました。つまり、セッション記述の処理タイプが「セッション」であるオファー/アンサー交換を使用します。アプリケーション サーバーはユーザー エージェント クライアント (UAC) とオファー/アンサー交換を実行してアーリー メディアのみを交換しますが、UAS は同じオファー/アンサー交換を使用して、最初にアーリー メディアを交換し、通常のダイアログが確立されると通常のメディアを交換します。。初期のメディア セッションを確立するこの方法はゲートウェイ モデル [8] として知られており、フォークとセキュリティに関連するいくつかの問題が発生します。これらの問題は、このモデルがアプリケーション サーバーまたは UAS によって使用される場合に発生します。
Application servers may not be able to generate an answer for an offer received in the INVITE. The UAC created the offer for the UAS, and so, it may have applied end-to-end encryption or have included information (e.g., related to key management) that the application server is not supposed to use. Therefore, application servers need a means to perform an offer/answer exchange with the UAC that is independent from the offer/answer exchange between both UAs.
アプリケーション サーバーは、INVITE で受信したオファーに対する応答を生成できない場合があります。UAC は UAS 用のオファーを作成したため、エンドツーエンド暗号化が適用されているか、アプリケーション サーバーが使用することを想定されていない情報 (キー管理など) が含まれている可能性があります。したがって、アプリケーション サーバーには、両方の UA 間のオファー/回答交換とは独立して、UAC とのオファー/回答交換を実行する手段が必要です。
UASs using the offer/answer exchange that will carry regular media for sending and receiving early media can cause media clipping, as described in Section 2.1.1 of [8]. Some UACs cannot receive early media from different UASs at the same time. So, when an INVITE forks and several UASs start sending early media, the UAC mutes all the UASs but one (which is usually chosen at random). If the UAS that accepts the INVITE (i.e., sends a 200 OK) was muted, a new offer/answer exchange is needed to unmute it. This usually causes media clipping. Therefore, UASs need a means of performing an offer/answer exchange with the UAC to exchange early media that is independent from the offer/answer exchanged used to exchange regular media.
[8] のセクション 2.1.1 で説明されているように、初期メディアの送受信に通常のメディアを搬送するオファー/アンサー交換を使用する UAS は、メディア クリッピングを引き起こす可能性があります。一部の UAC は、異なる UAS から同時に初期メディアを受信できません。したがって、INVITE がフォークし、複数の UAS が初期メディアの送信を開始すると、UAC は 1 つ (通常はランダムに選択される) を除くすべての UAS をミュートします。INVITE を受け入れる (つまり 200 OK を送信する) UAS がミュートされている場合、ミュートを解除するには新しいオファー/アンサー交換が必要です。これにより通常、メディアのクリッピングが発生します。したがって、UAS には、通常のメディアの交換に使用されるオファー/アンサー交換とは独立した初期メディアを交換するために、UAC とのオファー/アンサー交換を実行する手段が必要です。
A potential solution to this need would be to establish a different dialog using a globally routable URI to perform an independent offer/answer exchange. This dialog would be labelled as a dialog for early media and would be somehow related to the original dialog at the UAC. However, performing all the offer/answer exchanges within the original dialog has many advantages:
このニーズに対する潜在的な解決策は、グローバルにルーティング可能な URI を使用して別のダイアログを確立し、独立したオファー/回答交換を実行することです。このダイアログは初期メディア用のダイアログとしてラベル付けされ、UAC の元のダイアログと何らかの形で関連します。ただし、すべてのオファー/回答の交換を元のダイアログ内で実行すると、多くの利点があります。
o It is simpler.
o よりシンプルです。
o It does not have synchronization problems, because all the early dialogs are terminated when the session is accepted.
o セッションが受け入れられると初期のダイアログはすべて終了するため、同期の問題は発生しません。
o It does not require globally routable URIs.
o グローバルにルーティング可能な URI は必要ありません。
o It does not introduce service interaction issues related to services that may be wrongly applied to the new dialog.
o 新しいダイアログに誤って適用される可能性のあるサービスに関連するサービス相互作用の問題は発生しません。
o It makes firewall management easier.
o ファイアウォールの管理が容易になります。
This way of performing offer/answer exchanges for early media is referred to as the application server model [8]. This model uses the early-session disposition type defined in the following section.
初期メディアのオファー/アンサー交換を実行するこの方法は、アプリケーション サーバー モデルと呼ばれます [8]。このモデルは、次のセクションで定義される初期セッションの性質タイプを使用します。
We define a new disposition type for the Content-Disposition header field: early-session. User agents MUST use early-session bodies to establish early media sessions in the same way as they use session bodies to establish regular sessions, as described in RFCs 3261 [2] and 3264 [3]. Particularly, early-session bodies MUST follow the offer/answer model and MAY appear in the same messages as session bodies do with the exceptions of 2xx responses for an INVITE and ACKs. Nevertheless, it is NOT RECOMMENDED that early offers in INVITEs be included because they can fork, and the UAC could receive multiple early answers establishing early media streams at roughly the same time. Also, the use of the same transport address (IP address plus port) in a session body and in an early-session body is NOT RECOMMENDED. Using different transport addresses (e.g., different ports) to receive early and regular media makes it easy to detect the start of the regular media.
Content-Disposition ヘッダー フィールドの新しい性質タイプ、early-session を定義します。ユーザーエージェントは、RFC 3261 [2] および 3264 [3] で説明されているように、通常のセッションを確立するためにセッションボディを使用するのと同じ方法で、初期セッションボディを使用して初期メディアセッションを確立しなければなりません (MUST)。特に、初期セッションのボディは、オファー/アンサー モデルに従わなければならず (MUST)、INVITE と ACK に対する 2xx 応答を除き、セッション ボディと同じメッセージに表示されてもよい(MAY)。それにもかかわらず、INVITE に早期オファーを含めることは推奨されません。なぜなら、早期オファーは分岐する可能性があり、UAC がほぼ同時に初期メディア ストリームを確立する複数の早期アンサーを受信する可能性があるからです。また、セッション本体とセッションの初期本体で同じトランスポート アドレス (IP アドレスとポート) を使用することは推奨されません。異なるトランスポート アドレス (異なるポートなど) を使用して初期メディアと通常のメディアを受信すると、通常のメディアの開始を検出しやすくなります。
If a User Agent (UA) needs to refuse an early-session offer, it MUST do so by refusing all the media streams in it. When SDP [7] is used, this is done by setting the port number of all the media streams to zero.
ユーザーエージェント (UA) が初期セッションのオファーを拒否する必要がある場合、その中のすべてのメディア ストリームを拒否することによって拒否しなければなりません。SDP [7] が使用される場合、これはすべてのメディア ストリームのポート番号を 0 に設定することによって行われます。
This is the same mechanism that UACs use to refuse regular offers that arrive in a response to an empty INVITE.
これは、UAC が空の INVITE への応答として到着する通常のオファーを拒否するために使用するメカニズムと同じです。
An early media session established using early-session bodies MUST be terminated when its corresponding early dialog is terminated or it transitions to a regular dialog.
初期セッションボディを使用して確立された初期メディアセッションは、対応する初期ダイアログが終了するか、通常のダイアログに移行するときに終了されなければなりません(MUST)。
It is RECOMMENDED that UAs generating regular and early session descriptions use, as long as it is possible, the same codecs in both. This way, the remote UA does not need to change codecs when the early session transitions to a regular session.
通常のセッション記述と初期のセッション記述を生成する UA は、可能な限り両方で同じコーデックを使用することが推奨されます。このようにして、リモート UA は、初期セッションから通常のセッションに移行するときにコーデックを変更する必要がありません。
RFC 3312 [4] defines a framework for preconditions for SDP. Early-sessions MAY contain preconditions, which are treated in the same way as preconditions in regular sessions. That is, the UAs do not exchange media, and the called user is not alerted until the preconditions are met.
RFC 3312 [4] は、SDP の前提条件のフレームワークを定義しています。初期セッションには前提条件が含まれていてもよく (MAY)、通常のセッションの前提条件と同じように扱われます。つまり、UA はメディアを交換せず、前提条件が満たされるまで着信側のユーザーに通知されません。
We define an option tag to be used in Require and Supported header fields: early-session. A UA adding the early-session option tag to a message indicates that it understands the early-session disposition type.
Require および Supported ヘッダー フィールドで使用されるオプション タグを定義します: 初期セッション。UA が初期セッション オプション タグをメッセージに追加することは、UA が初期セッションの性質タイプを理解していることを示します。
Figure 1 shows the message flow between two UAs. INVITE (1) has an early-session option tag in its Supported header field and the body shown in Figure 2. The UAS sends back a response with two body parts, as shown in Figure 3: one of disposition type session and the other early-session. The session body part is the answer to the offer in the INVITE. The early-session body part is an offer to establish an early media session. When the UAC receives the 183 (Session Progress) response, it sends the answer to the early-session offer in a PRACK, as shown in Figure 4. This early media session is terminated when the early dialog transitions to a regular dialog. That is, when the UAS sends the (5) 200 (OK) response for the INVITE.
図 1 は、2 つの UA 間のメッセージ フローを示しています。INVITE (1) には、図 2 に示すように、Supported ヘッダー フィールドと本文に初期セッション オプション タグがあります。UAS は、図 3 に示すように、2 つの本文部分を含む応答を送り返します。1 つは性質タイプのセッションで、もう 1 つは初期セッションです。-セッション。セッション本体部分は、INVITE 内のオファーに対する回答です。初期セッションの本文部分は、初期のメディア セッションを確立するためのオファーです。UAC は 183 (セッション進行状況) 応答を受信すると、図 4 に示すように、初期セッション オファーに対する応答を PRACK で送信します。この初期メディア セッションは、初期ダイアログが通常のダイアログに移行すると終了します。つまり、UAS が INVITE に対して (5) 200 (OK) 応答を送信したときです。
A B
| |
|--------(1) INVITE-------->|
| offer |
| |
|<--(2) Session Progress----|
| early-offer |
| answer |
| |
|---------(3) PRACK-------->|
| early-answer |
| |
|<--------(4) 200 OK--------|
| |
| * * |
| ************************* |
|* Early Media *|
| ************************* |
| * * |
| |
|<--------(5) 200 OK--------|
| |
|----------(6) ACK--------->|
| |
Figure 1: Message flow
図 1: メッセージ フロー
Content-Type: application/sdp
Content-Disposition: session
v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0
v=0 o=アリス 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=オーディオ 20000 RTP/AVP 0
Figure 2: Offer
図 2: オファー
Content-Type: multipart/mixed; boundary="boundary1"
Content-Length: 401
--boundary1
Content-Type: application/sdp
Content-Disposition: session
v=0 o=Bob 2890844725 2890844725 IN IP4 host.example.org s= c=IN IP4 192.0.2.2 t=0 0 m=audio 30000 RTP/AVP 0
v=0 o=ボブ 2890844725 2890844725 IN IP4 host.example.org s= c=IN IP4 192.0.2.2 t=0 0 m=オーディオ 30000 RTP/AVP 0
--boundary1
Content-Type: application/sdp
Content-Disposition: early-session
v=0 o=Bob 2890844714 2890844714 IN IP4 host.example.org s= c=IN IP4 192.0.2.2 t=0 0 m=audio 30002 RTP/AVP 0
v=0 o=ボブ 2890844714 2890844714 IN IP4 host.example.org s= c=IN IP4 192.0.2.2 t=0 0 m=オーディオ 30002 RTP/AVP 0
--boundary1--
--境界1--
Figure 3: Early offer and answer
図 3: 早期のオファーと回答
Content-Type: application/sdp
Content-Disposition: early-session
v=0 o=alice 2890844717 2890844717 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 20002 RTP/AVP 0
v=0 o=アリス 2890844717 2890844717 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=オーディオ 20002 RTP/AVP 0
Figure 4: Early answer
図 4: 初期の回答
The security implications of using early-session bodies in SIP are the same as when using session bodies; they are part of the offer/answer model.
SIP で初期セッション ボディを使用する場合のセキュリティへの影響は、セッション ボディを使用する場合と同じです。それらはオファー/アンサー モデルの一部です。
SIP uses the offer/answer model [3] to establish early sessions in both the gateway and the application server models. User Agents (UAs) generate a session description, which contains the transport address (i.e., IP address plus port) where they want to receive media, and send it to their peer in a SIP message. When media packets arrive at this transport address, the UA assumes that they come from the receiver of the SIP message carrying the session description. Nevertheless, attackers may attempt to gain access to the contents of the SIP message and send packets to the transport address contained in the session description. To prevent this situation, UAs SHOULD encrypt their session descriptions (e.g., using S/MIME).
SIP は、オファー/アンサー モデル [3] を使用して、ゲートウェイ モデルとアプリケーション サーバー モデルの両方で初期セッションを確立します。ユーザー エージェント (UA) は、メディアを受信するトランスポート アドレス (つまり、IP アドレスとポート) を含むセッション記述を生成し、それを SIP メッセージでピアに送信します。メディア パケットがこのトランスポート アドレスに到着すると、UA は、メディア パケットがセッション記述を運ぶ SIP メッセージの受信者から送信されたものであると想定します。それにもかかわらず、攻撃者は SIP メッセージの内容にアクセスし、セッション記述に含まれるトランスポート アドレスにパケットを送信しようとする可能性があります。この状況を防ぐために、UA はセッション記述を暗号化する必要があります (例: S/MIME を使用)。
Still, even if a UA encrypts its session descriptions, an attacker may try to guess the transport address used by the UA and send media packets to that address. Guessing such a transport address is sometimes easier than it may seem because many UAs always pick up the same initial media port. To prevent this situation, UAs SHOULD use media-level authentication mechanisms (e.g., Secure Realtime Transport Protocol (SRTP)[6]). In addition, UAs that wish to keep their communications confidential SHOULD use media-level encryption mechanisms (e.g, SRTP [6]).
それでも、UA がセッション記述を暗号化したとしても、攻撃者は UA が使用するトランスポート アドレスを推測し、そのアドレスにメディア パケットを送信しようとする可能性があります。多くの UA は常に同じ最初のメディア ポートを選択するため、このようなトランスポート アドレスを推測することは、思っているよりも簡単な場合があります。この状況を防ぐために、UA はメディアレベルの認証メカニズム (例: Secure Realtime Transport Protocol (SRTP)[6]) を使用すべきです (SHOULD)。さらに、通信の機密性を維持したい UA は、メディアレベルの暗号化メカニズム (例: SRTP [6]) を使用する必要があります (SHOULD)。
Attackers may attempt to make a UA send media to a victim as part of a DoS attack. This can be done by sending a session description with the victim's transport address to the UA. To prevent this attack, the UA SHOULD engage in a handshake with the owner of the transport address received in a session description (just verifying willingness to receive media) before sending a large amount of data to the transport address. This check can be performed by using a connection oriented transport protocol, by using Simple Traversal of the UDP Protocol through NAT (STUN)[5] in an end-to-end fashion, or by the key exchange in SRTP [6].
攻撃者は、DoS 攻撃の一環として、UA にメディアを被害者に送信させようとする可能性があります。これは、被害者のトランスポート アドレスを含むセッション記述を UA に送信することで実行できます。この攻撃を防ぐために、UA は、トランスポート アドレスに大量のデータを送信する前に、セッション記述で受信したトランスポート アドレスの所有者とハンドシェイクを行う必要があります (メディアを受信する意思を確認するだけです)。このチェックは、コネクション指向トランスポート プロトコルを使用するか、エンドツーエンド方式で NAT を介した UDP プロトコルの単純通過 (STUN)[5]を使用するか、SRTP [6] のキー交換によって実行できます。
In any event, note that the previous security considerations are not early media specific, but apply to the usage of the offer/answer model in SIP to establish sessions in general.
いずれにせよ、前述のセキュリティに関する考慮事項は初期のメディア固有のものではなく、セッションを確立するための SIP でのオファー/アンサー モデルの使用方法全般に適用されることに注意してください。
Additionally, an early media-specific risk (roughly speaking, an equivalent to forms of "toll fraud" in the Public Switched Telephone Network (PSTN)) attempts to exploit the different charging policies some operators apply to early and to regular media. When UAs are allowed to exchange early media for free, but are required to pay for regular media sessions, rogue UAs may try to establish a bidirectional early media session and never send a 2xx response for the INVITE.
さらに、初期メディア固有のリスク (大まかに言えば、公衆交換電話網 (PSTN) における「料金詐欺」の形態と同等) は、一部の通信事業者が初期メディアと通常のメディアに適用する異なる料金ポリシーを悪用しようとします。UA がアーリー メディアを無料で交換できるが、通常のメディア セッションの料金を支払う必要がある場合、不正な UA は双方向のアーリー メディア セッションを確立しようとし、INVITE に対する 2xx 応答を送信しない可能性があります。
On the other hand, some application servers (e.g., Interactive Voice Response systems) use bidirectional early media to obtain information from the callers (e.g., the Personal Identification Number (PIN) code of a calling card). So, we do not recommend that operators disallow bidirectional early media. Instead, operators should consider a remedy of charging early media exchanges that last too long, or stopping them at the media level (according to the operator's policy).
一方、一部のアプリケーション サーバー (自動音声応答システムなど) は、双方向の初期メディアを使用して発信者から情報 (テレホン カードの暗証番号 (PIN) コードなど) を取得します。したがって、通信事業者が双方向のアーリーメディアを禁止することはお勧めしません。代わりに、事業者は、あまりにも長く続く初期のメディア交換に課金するか、(事業者のポリシーに従って) メディア レベルで停止するという救済策を検討する必要があります。
This document defines a new Content-Disposition header field disposition type (early-session) in Section 4. This value has been registered in the IANA registry for Content-Dispositions with the following description:
この文書は、セクション 4 で新しい Content-Disposition ヘッダー フィールドの処理タイプ (初期セッション) を定義します。この値は、次の説明とともに Content-Disposition の IANA レジストリに登録されています。
early-session The body describes an early communications session, for example, an RFC 2327 SDP body
early-session 本文は初期の通信セッションを記述します。たとえば、RFC 2327 SDP 本文です。
This document defines a SIP option tag (early-session) in Section 6. It has been registered in the SIP parameters registry (http://www.iana.org/assignments/sip-parameters) under "Option Tags", with the following description.
この文書は、セクション 6 で SIP オプション タグ (初期セッション) を定義します。このタグは、SIP パラメータ レジストリ (http://www.iana.org/assignments/sip-parameters) の「オプション タグ」に登録されています。以下の説明。
early-session A UA adding the early-session option tag to a message indicates that it understands the early-session content disposition.
初期セッション UA がメッセージに初期セッション オプション タグを追加することは、初期セッションのコンテンツの性質を理解していることを示します。
Francois Audet, Christer Holmberg, and Allison Mankin provided useful comments on this document.
Francois Audet、Christer Holmberg、Allison Mankin がこの文書に関して有益なコメントを提供してくれました。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[2] 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.
[2] Rosenberg, J.、Schulzrinne, H.、Camarillo, G.、Johnston, A.、Peterson, J.、Sparks, R.、Handley, M.、および E. Schooler、「SIP: セッション開始プロトコル」、RFC 3261、2002年6月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Rosenberg, J. および H. Schulzrinne、「セッション記述プロトコル (SDP) を使用したオファー/アンサー モデル」、RFC 3264、2002 年 6 月。
[4] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[4] Camarillo, G.、Marshall, W.、および J. Rosenberg、「リソース管理とセッション開始プロトコル (SIP) の統合」、RFC 3312、2002 年 10 月。
[5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[5] Rosenberg, J.、Weinberger, J.、Huitema, C.、および R. Mahy、「STUN - ネットワーク アドレス トランスレータ (NAT) を介したユーザー データグラム プロトコル (UDP) の単純なトラバーサル」、RFC 3489、2003 年 3 月。
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[6] Baugher, M.、McGrew, D.、Naslund, M.、Carrara, E.、および K. Norrman、「セキュア リアルタイム トランスポート プロトコル (SRTP)」、RFC 3711、2004 年 3 月。
[7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7] Handley、M. および V. Jacobson、「SDP: セッション記述プロトコル」、RFC 2327、1998 年 4 月。
[8] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[8] Camarillo, G. および H. Schulzrinne、「セッション開始プロトコル (SIP) における初期のメディアと着信音の生成」、RFC 3960、2004 年 12 月。
Author's Address
著者の連絡先
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロ・エリクソン・ヒルサランティエ 11 ジョルバス 02420 フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2004).
著作権 (C) インターネット協会 (2004)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/ipr) から入手してください。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。