RFC3959 日本語訳
3959 The Early Session Disposition Type for the Session InitiationProtocol (SIP). G. Camarillo. December 2004. (Format: TXT=22160 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo Request for Comments: 3959 Ericsson Category: Standards Track December 2004
コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 3959年のエリクソンカテゴリ: 標準化過程2004年12月
The Early Session Disposition Type for
the Session Initiation Protocol (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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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プロトコル(SIP)でContent-気質ヘッダーフィールドのための新しい気質タイプ(前場)を定義します。 「前場」ボディーの処理は「セッション」ボディーの処理と同様です。 すなわち、彼らは申し出/答えモデルに従います。 それらの唯一の違いは気質タイプが「前場」であるセッション記述が早めの対話の中で早めのメディアセッションを証明するのに使用されるということです、通常の対話の中の定例会と対照的に。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 問題は早めのメディアセッションまで設立. . . . . 2 4を関係づけました。 前場の気質タイプ. . . . . . . . . . . . . . 4 5。 前提条件. . . . . . . . . . . . . . . . . . . . . . . . 4 6。 オプションタグ. . . . . . . . . . . . . . . . . . . . . . . . . . 5 7。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 7 9。 IANA問題. . . . . . . . . . . . . . . . . . . . . 8 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 9 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1。 引用規格. . . . . . . . . . . . . . . . . . 9 11.2。 情報の参照. . . . . . . . . . . . . . . . 9作者のアドレスの.10の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 11
Camarillo Standards Track [Page 1] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[1ページ]。
1. Introduction
1. 序論
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.
早めのメディアはメディア(例えば、オーディオとビデオ)を示します、すなわち、以前交換して、特定のセッションが呼ばれたユーザによって受け入れられます。 対話の中では、早めのメディアはUserエージェントServer(UAS)が最終的な応答を生成するまで初期のINVITEが送られる瞬間から起こります。 それは、単方向か双方向であるかもしれなく、訪問者、訪問される人、または両方で生成することができます。 訪問される人によって作られた早めのメディアの典型的な例は、呼出音と発表(例えば、状態を列に並ばせる)です。 訪問者によって作られた早めのメディアは、対話的な声の応答(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.
RFC3261[2])は、非常に簡単な早めのメディアがメカニズムであるとサポートするだけです。基本のSIP仕様、(これらの簡単なメカニズムは、多くの問題を分岐とセキュリティに関連させて、ほとんどのアプリケーションの要件を満たしません。 RFC3960[8]はRFC3261[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.
RFC3960[8]で説明された両方の早めのメディアモデルはRFC3261[2]で指定されたものより上級ですが、ゲートウェイモデルはまだ1セットの問題を提示しています。 特に、ゲートウェイモデルは分岐でうまくいきません。 それにもかかわらず、いくつかの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.
アプリケーション・サーバーモデルはゲートウェイモデルの現在の問題のいくつかを扱います。 このモデルは本書では指定された前場の気質タイプを使用します。
2. Terminology
2. 用語
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.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実装のために要件レベルを示すべきであるかをさせましょう。
3. Issues Related to Early Media Session Establishment
3. 早めのメディアセッション設立に関連する問題
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
定例会と同様に、伝統的に、早めのメディアセッションは確立されました。 すなわち、セッション記述の気質タイプが「セッション」であるところで申し出/答え交換を使用すること。 アプリケーション・サーバーは排他的に早めのメディアを交換するためにUserエージェントClient(UAC)との申し出/答え交換を実行します、UASsが最初に、早めのメディアを交換するのに同じ申し出/答え交換を使用して、通常の対話がいったん交換に通常の状態で確立されると
Camarillo Standards Track [Page 2] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[2ページ]。
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.
メディア。 早めのメディアセッションを確立するこの方法はゲートウェイモデル[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のために申し出を作成したので、それは、終端間暗号化を適用したか、またはアプリケーション・サーバーが使用するべきでない情報(例えば、かぎ管理に関連する)を含んだかもしれません。 したがって、アプリケーション・サーバーは両方のUAsの間の申し出/答え交換によって独立している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.
送受信の早めのメディアのために通常のメディアを運ぶ申し出/答え交換を使用するUASsは[8]についてセクション2.1.1で説明されるように切り取られるメディアを引き起こす場合があります。 いくつかのUACsは同時に、異なったUASsから早めのメディアを受け取ることができません。 INVITEが分岐して、数個のUASsが早めのメディアを送り始めると、UACは、すべてのUASsに音を消すので、1つ(通常、無作為に選ばれている)に音を消します。 INVITE(すなわち、200OKを送る)を受け入れるUASが音を消されたなら、新しい申し出/答え交換が、それが「非-無言」であるのに必要です。 通常、これはメディア切り取りを引き起こします。 したがって、UASsは早めのメディアを交換する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]と呼ばれます。 このモデルは以下のセクションで定義された前場の気質タイプを使用します。
Camarillo Standards Track [Page 3] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[3ページ]。
4. The Early Session Disposition Type
4. 前場の気質タイプ
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-気質ヘッダーフィールドのための新しい気質タイプを定義します: 前場。 ユーザエージェントは定例会を証明するのにセッション本体を使用するとき同様に、早めのメディアセッションを証明するのに前場の本体を使用しなければなりません、RFCs3261[2]と3264[3]で説明されるように。 特に、前場の本体は、セッション本体が2xx応答の例外で見えるようにINVITEとACKsに関して申し出/答えモデルに従わなければならなくて、同じメッセージで見えるかもしれません。 それにもかかわらず、彼らが分岐できるのでINVITEsの早めの申し出が含まれているのが、NOT RECOMMENDEDであり、UACはおよそ同時に早めのメディアストリームを確立する複数の早めの答えを受けることができました。 また、セッション本体と前場の本体における同じ輸送アドレス(IPアドレスとポート)の使用はNOT RECOMMENDEDです。 早くて通常のメディアを受け取るのに、異なった輸送アドレス(例えば、異なったポート)を使用するのに、通常のメディアの始まりを検出するのは簡単になります。
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.
Userエージェント(UA)が、前場の申し出を拒否する必要があるなら、それは、すべてのメディアにそれのストリームを拒否することによって、そうしなければなりません。 SDP[7]が使用されているとき、すべてのメディアストリームのポートナンバーをゼロに設定することによって、これをします。
This is the same mechanism that UACs use to refuse regular offers
that arrive in a response to an empty INVITE.
これはUACsが空の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.
対応する早めの対話が終えられるか、または通常の対話に移行するとき、前場の本体を使用することで確立された早めのメディアセッションを終えなければなりません。
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.
それが可能である限り、通常の、そして、早めのセッション記述を生成するUAsが両方で同じコーデックを使用するのは、RECOMMENDEDです。 前場が定例会に移行するとき、このように、リモートUAはコーデックを変える必要はありません。
5. Preconditions
5. 前提条件
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.
RFC3312[4]はSDPのための前提条件のためにフレームワークを定義します。 早めのセッションは前提条件を含むかもしれません。(同様に、前提条件は定例会における前提条件として扱われます)。 すなわち、UAsはメディアを交換しません、そして、前提条件が満たされるまで、呼ばれたユーザは警告されません。
Camarillo Standards Track [Page 4] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[4ページ]。
6. Option Tag
6. オプションタグ
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は、前場の気質タイプを理解しているのを示します。
7. Example
7. 例
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は2UAsの間のメッセージ流動を示しています。 INVITE(1)はSupportedヘッダーフィールドと図2のボディーに前場のオプションタグを持っています。 UASは図3に示されるように2つの身体の部分で応答を返送します: 気質タイプセッションともう片方の前場の1つ。 セッション身体の部分はINVITEの申し出の答えです。 前場の身体の部分は早めのメディアセッションを確立するという申し出です。 UACが183(セッションProgress)応答を受けるとき、PRACKの前場の申し出に答えを送ります、図4に示されるように。 早めの対話が通常の対話に移行するとき、この早めのメディアセッションは終えられます。 すなわち、UASがINVITEのために200(OK)応答を(5)に送るとき。
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--------->|
| |
B| | |--------(1) 招待-------->|、| 申し出| | | | <--(2) セッション進歩----| | 早い申し出| | 答え| | | |---------(3) PRACK-------->|、| 早い答え| | | | <、-、-、-、-、-、-、--(4) 200 OK--------| | | | * * | | ************************* | |* 早めのメディア*| | ************************* | | * * | | | | <、-、-、-、-、-、-、--(5) 200 OK--------| | | |----------(6) ACK--------->|、|、|
Figure 1: Message flow
図1: メッセージ流動
Camarillo Standards Track [Page 5] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[5ページ]。
Content-Type: application/sdp Content-Disposition: session
コンテントタイプ: sdp Contentアプリケーション/気質: セッション
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=alice2890844730 2890844731IN IP4 host.example.com s=cは0 0t=mのIN IP4 192.0.2.1=オーディオの20000RTP/AVP0と等しいです。
Figure 2: Offer
図2: 申し出
Content-Type: multipart/mixed; boundary="boundary1" Content-Length: 401
コンテントタイプ: 複合か混ぜられる。 境界=、「boundary1" Content-長さ:」 401
--boundary1 Content-Type: application/sdp Content-Disposition: session
--boundary1コンテントタイプ: sdp Contentアプリケーション/気質: セッション
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
ボブ2890844725 2890844725IN v=0o=IP4 host.example.org s=cは0 0t=mのIN IP4 192.0.2.2=オーディオの30000RTP/AVP0と等しいです。
--boundary1 Content-Type: application/sdp Content-Disposition: early-session
--boundary1コンテントタイプ: sdp Contentアプリケーション/気質: 前場
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
ボブ2890844714 2890844714IN v=0o=IP4 host.example.org s=cは0 0t=mのIN IP4 192.0.2.2=オーディオの30002RTP/AVP0と等しいです。
--boundary1--
--boundary1--
Figure 3: Early offer and answer
図3: 早めの申し出と答え
Camarillo Standards Track [Page 6] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[6ページ]。
Content-Type: application/sdp Content-Disposition: early-session
コンテントタイプ: sdp Contentアプリケーション/気質: 前場
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=alice2890844717 2890844717IN IP4 host.example.com s=cは0 0t=mのIN IP4 192.0.2.1=オーディオの20002RTP/AVP0と等しいです。
Figure 4: Early answer
図4: 早く、答えてください。
8. Security Considerations
8. セキュリティ問題
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]を使用します。 ユーザエージェント(UAs)はセッション記述を生成します。(それは、SIPメッセージに彼らが同輩にメディアを受け取って、それを送りたがっている輸送アドレス(すなわち、IPアドレスとポート)を含みます)。 メディア向けの資料セットがこの輸送アドレスに到着するとき、UAは、セッション記述を運ぶSIPメッセージの受信機から来ると仮定します。 それにもかかわらず、攻撃者は、SIPメッセージのコンテンツへのアクセスを得て、セッション記述に含まれた輸送アドレスにパケットを送るのを試みるかもしれません。 この状況を防ぐために、UAs SHOULDは彼らのセッション記述(例えば、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によって使用された輸送アドレスを推測して、そのアドレスにメディア向けの資料セットを送ろうとするかもしれません。 そのような輸送アドレスを推測するのは多くのUAsがいつも同じ初期のメディアポートを拾うので見えるかもしれないより時々簡単です。 この状況を防ぐのに、UAs SHOULDはメディアレベル認証機構を使用します。(例えば、Secure Realtime Transportプロトコル(SRTP)[6])。 さらに、彼らのコミュニケーションが秘密のSHOULDであることを保ちたがっているUAsがメディアレベル暗号化メカニズムを使用します。(e.g、SRTP[6])。
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
攻撃者は、UAにDoS攻撃の一部としてメディアを犠牲者に送らせるのを試みるかもしれません。 犠牲者の輸送アドレスでセッション記述を送ることによって、これがUAにできます。 この攻撃を防ぐために、多量のデータを輸送アドレスに送る前に、UA SHOULDはセッション記述(ただ、メディアを受け取る意欲について確かめる)で輸送アドレスの所有者を受け取っていて握手に従事しています。 接続を使用することによって、このチェックを実行できます。
Camarillo Standards Track [Page 7] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[7ページ]。
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].
NAT(STUN)[5]を通して終わりから終わりへのファッションでUDPプロトコルのSimple Traversalを使用するか、または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.
さらに、早めのメディア固有のリスク(大まかに言えばPublic Switched Telephone Network(PSTN)の「料金詐欺」のフォームと同等物)は、何人かのオペレータが当てはまる異なった充電方針を早期と通常のメディアに利用するのを試みます。 UAsがただで早めのメディアを交換するのが許容されていますが、定期的なメディアセッションの対価を支払わなければならないとき、凶暴なUAsは双方向の早めのメディアセッションを確立して、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).
他方では、いくつかのアプリケーション・サーバー(例えば、Interactive Voice Responseシステム)が、訪問者(例えば、テレホンカードのパーソナルIdentification Number(暗証番号)コード)から情報を得るのに双方向の早めのメディアを使用します。 それで、私たちは、オペレータが双方向の早めのメディアを禁じることを勧めません。 代わりに、オペレータはあまりに長い間続く早めのメディア交換を請求するか、またはメディアレベル(オペレータの方針によると)でそれらを止める療法を考えるべきです。
9. IANA Considerations
9. IANA問題
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-気質ヘッダーフィールド気質タイプ(前場)を定義します。 この値はContent-気質のためにIANA登録に以下の記述に示されました:
early-session The body describes an early communications
session, for example, an RFC 2327 SDP body
ボディーが早めのコミュニケーションセッションについて説明する前場、例えば、RFC2327SDPボディー
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.
前場のオプションタグをメッセージに追加する前場A UAは、セッションの早めの内容気質を理解しているのを示します。
Camarillo Standards Track [Page 8] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[8ページ]。
10. Acknowledgements
10. 承認
Francois Audet, Christer Holmberg, and Allison Mankin provided useful comments on this document.
フランソアAudet、Christer Holmberg、およびアリソン・マンキンはこのドキュメントの役に立つコメントを提供しました。
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[4] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002.
[4] キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、「資源管理とセッション開始プロトコル(一口)の統合」、RFC3312(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] ローゼンバーグ、J.、ワインバーガー、J.、Huitema、C.、およびR.マーイ、「気絶させてください--ネットワークアドレス変換機構(NATs)を通したユーザー・データグラム・プロトコル(UDP)の簡単な縦断」、RFC3489、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.
2004年の[6]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
11.2. Informational References
11.2. 情報の参照
[7] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[7] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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] キャマリロ、G.、およびH.Schulzrinne、「早くメディアと鳴るのはセッション開始プロトコル(一口)における世代に調子を変えます」、RFC3960、2004年12月。
Camarillo Standards Track [Page 9] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[9ページ]。
Author's Address
作者のアドレス
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メール: Gonzalo.Camarillo@ericsson.com
Camarillo Standards Track [Page 10] RFC 3959 Early Session Disposition Type December 2004
キャマリロ規格は前場の気質タイプ2004年12月にRFC3959を追跡します[10ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Camarillo Standards Track [Page 11]
キャマリロ標準化過程[11ページ]
一覧
スポンサーリンク
