RFC4538 日本語訳
4538 Request Authorization through Dialog Identification in theSession Initiation Protocol (SIP). J. Rosenberg. June 2006. (Format: TXT=36089 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 4538 Cisco Systems Category: Standards Track June 2006
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 4538年のシスコシステムズカテゴリ: 標準化過程2006年6月
Request Authorization through Dialog Identification
in 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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This specification defines the Target-Dialog header field for the Session Initiation Protocol (SIP), and the corresponding option tag, tdialog. This header field is used in requests that create SIP dialogs. It indicates to the recipient that the sender is aware of an existing dialog with the recipient, either because the sender is on the other side of that dialog, or because it has access to the dialog identifiers. The recipient can then authorize the request based on this awareness.
この仕様はSession Initiationプロトコル(SIP)、および対応するオプションタグ、tdialogのためのTarget-対話ヘッダーフィールドを定義します。 このヘッダーフィールドはSIP対話を作成する要求で使用されます。 それは、送付者が受取人と共に既存の対話を意識しているのを受取人に示します、送付者がその対話の反対側の上にいるか、または対話識別子に近づく手段を持っているので。 そして、受取人はこの認識に基づく要求を認可できます。
Rosenberg Standards Track [Page 1] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[1ページ]
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Overview of Operation ...........................................4
3. User Agent Client (UAC) Behavior ................................5
4. User Agent Server Behavior ......................................7
5. Proxy Behavior ..................................................8
6. Extensibility Considerations ....................................8
7. Header Field Definition .........................................9
8. Security Considerations .........................................9
9. Relationship with In-Reply-To ..................................10
10. Example Call Flow .............................................10
11. IANA Considerations ...........................................13
11.1. Header Field .............................................13
11.2. Header Field Parameters ..................................13
11.2.1. local-tag .........................................13
11.2.2. remote-tag ........................................13
11.3. SIP Option Tag ...........................................14
12. Acknowledgements ..............................................14
13. References ....................................................14
13.1. Normative References .....................................14
13.2. Informative References ...................................15
1. 序論…3 1.1. 用語…4 2. 操作の概要…4 3. ユーザエージェントのクライアント(UAC)の振舞い…5 4. ユーザエージェントサーバの振舞い…7 5. プロキシの振舞い…8 6. 伸展性問題…8 7. ヘッダーフィールド定義…9 8. セキュリティ問題…9 9. 関係、…に対して…10 10. 例の呼び出し流動…10 11. IANA問題…13 11.1. ヘッダー分野…13 11.2. ヘッダーフィールドパラメタ…13 11.2.1. 地方のタグ…13 11.2.2. リモートタグ…13 11.3. オプションタグをちびちび飲んでください…14 12. 承認…14 13. 参照…14 13.1. 標準の参照…14 13.2. 有益な参照…15
Rosenberg Standards Track [Page 2] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[2ページ]
1. Introduction
1. 序論
The Session Initiation Protocol (SIP) [2] defines the concept of a dialog as a persistent relationship between a pair of user agents. Dialogs provide context, including sequence numbers, proxy routes, and dialog identifiers. Dialogs are established through the transmission of SIP requests with particular methods. Specifically, the INVITE, REFER [8], and SUBSCRIBE [3] requests all create dialogs.
Session Initiationプロトコル(SIP)[2]は1組のユーザエージェントの間の永続的な関係と対話の概念を定義します。 対話は一連番号、プロキシルート、および対話識別子を含む文脈を提供します。 対話は特定のメソッドでSIP要求の伝達で確立されます。 そして、INVITE、明確にREFER[8]、登録、[3] 要求はすべて、対話を作成します。
When a user agent receives a request that creates a dialog, it needs to decide whether to authorize that request. For some requests, authorization is a function of the identity of the sender, the request method, and so on. However, many situations have been identified in which a user agent's authorization decision depends on whether the sender of the request is currently in a dialog with that user agent, or whether the sender of the request is aware of a dialog the user agent has with another entity.
ユーザエージェントが対話を作成する要求を受け取るとき、それは、その要求を認可するかどうか決める必要があります。 いくつかの要求のために、承認は送付者のアイデンティティ、要求メソッドなどの機能です。 しかしながら、ユーザエージェントの承認決定が現在、対話には要求の送付者がそのユーザエージェントと共にいるか、または要求の送付者がユーザエージェントが別の実体で持っている対話を意識しているかどうかによる多くの状況が特定されました。
One such example is call transfer, accomplished through REFER. If user agents A and B are in an INVITE dialog, and user agent A wishes to transfer user agent B to user agent C, user agent A needs to send a REFER request to user agent B, asking user agent B to send an INVITE request to user agent C. User agent B needs to authorize this REFER. The proper authorization decision is that user agent B should accept the request if it came from a user with whom B currently has an INVITE dialog relationship. Current implementations deal with this by sending the REFER on the same dialog as the one in place between user agents A and B. However, this approach has numerous problems [12]. These problems include difficulties in determining the lifecycle of the dialog and its usages and in determining which messages are associated with each application usage. Instead, a better approach is for user agent A to send the REFER request to user agent B outside of the dialog. In that case, a means is needed for user agent B to authorize the REFER.
その一例はREFERを通して実行された呼び出し転送です。 INVITE対話にはユーザエージェントAとBがいて、ユーザエージェントAがユーザエージェントBをユーザエージェントCに移したいなら、ユーザエージェントAは、ユーザエージェントBにREFER要求を送る必要があります、UserエージェントBがこのREFERを認可する必要があるユーザエージェントC.にINVITE要求を送るようにユーザエージェントBに頼んで。 適切な承認決定は現在、BにはINVITE対話関係があるユーザから来るならユーザエージェントBが要請を受け入れるということです。 このアプローチには、ユーザエージェントAとB.Howeverの間でものと同じ対話のREFERを適所に送ることによって、現在の実装はこれに対処して、多数の問題[12]があります。 これらの問題は対話とその用法のlifecycleを決定して、どのメッセージがそれぞれのアプリケーション用法に関連しているかを決定することにおける苦労を含んでいます。 代わりに、より良いアプローチはユーザエージェントAが対話の外でユーザエージェントBにREFER要求を送ることです。 その場合、ユーザエージェントBがREFERを認可するのに手段が必要です。
Another example is the application interaction framework [14]. In that framework, proxy servers on the path of a SIP INVITE request can place user interface components on the user agent that generated or received the request. To do this, the proxy server needs to send a REFER request to the user agent, targeted to its Globally Routable User Agent URI (GRUU) [13], asking the user agent to fetch an HTTP resource containing the user interface component. In such a case, a means is needed for the user agent to authorize the REFER. The application interaction framework recommends that the request be authorized if it was sent from an entity on the path of the original dialog. This can be done by including the dialog identifiers in the
別の例はアプリケーション間連携フレームワーク[14]です。 そのフレームワークでは、SIP INVITE要求の経路のプロキシサーバは要求を生成したか、または受け取ったユーザエージェントにユーザーインタフェースコンポーネントを置くことができます。 これをするために、ユーザーインタフェースコンポーネントを含むHTTPリソースをとって来るようにユーザエージェントに頼みながら、プロキシサーバは、Globally Routable Userのエージェントのユリ(GRUU)の[13]に狙うユーザエージェントにREFER要求を送る必要があります。 このような場合には、ユーザエージェントがREFERを認可するのに手段が必要です。 アプリケーション間連携フレームワークは、オリジナルの対話の経路で実体からそれを送ったなら要求を認可することを勧めます。 対話識別子をこれに含むことができます。
Rosenberg Standards Track [Page 3] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[3ページ]
REFER, which prove that the user agent that sent the REFER is aware of those dialog identifiers (this needs to be secured against eavesdroppers through the sips mechanism, of course).
REFER。(そのREFERはREFERを送ったユーザエージェントがそれらの対話識別子(これは、メカニズム、もちろんという一口を通して立ち聞きする者に対して機密保護されて、ことである必要がある)を意識していると立証します)。
Another example is if two user agents share an INVITE dialog, and an element on the path of the INVITE request wishes to track the state of the INVITE. In such a case, it sends a SUBSCRIBE request to the GRUU of the user agent, asking for a subscription to the dialog event package. If the SUBSCRIBE request came from an element on the INVITE request path, it should be authorized.
別の例は2人のユーザエージェントがINVITE対話を共有するかどうかということです、そして、INVITE要求の経路の要素はINVITEの州を追跡したがっています。 このような場合には、ユーザエージェントのGRUUへの要求を登録に送ります、対話イベントパッケージの購読を求めて。 登録、要求はINVITE要求経路の要素から来て、それは認可されるべきです。
1.1. Terminology
1.1. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?
2. Overview of Operation
2. 操作の概要
+--------+ +--------+
| | INVITE | |
| Server |----------->| Server |
| A | | B |
| |...........>| |
+--------+ +--------+
^ REFER . \
/ . \
/ . \
/ . \
/ . \
/ V V
+--------+ +--------+
| | | |
| User | | User |
| Agent | | Agent |
| A | | B |
+--------+ +--------+
+--------+ +--------+ | | 招待| | | サーバ|、-、-、-、-、-、-、-、-、-、--、>| サーバ| | A| | B| | |...........>|、| +--------+ +--------+ ^ REFER . \ / . \ / . \ / . \ / . \ / V V +--------+ +--------+ | | | | | ユーザ| | ユーザ| | エージェント| | エージェント| | A| | B| +--------+ +--------+
Figure 1
図1
Figure 1 shows the basic model of operation. User agent A sends an INVITE to user agent B, traversing two servers, server A and server B. Both servers act as proxies for this transaction. User B sends a 200 OK response to the INVITE. This 200 OK includes a Supported header field indicating support for this specification (through the presence of the tdialog option tag). The 200 OK response establishes a dialog between the two user agents.
図1は操作の基本型を示しています。 ユーザエージェントAはユーザエージェントBにINVITEを送ります、Bothサーバがこのトランザクションのためのプロキシとして機能させる2つのサーバ、サーバA、およびサーバB.を横断して。 ユーザBは200OK応答をINVITEに送ります。 この200OKはこの仕様(tdialogオプションタグの存在を通した)のサポートを示すSupportedヘッダーフィールドを含んでいます。 200OK応答は2人のユーザエージェントの間の対話を確立します。
Rosenberg Standards Track [Page 4] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[4ページ]
Next, an entity that was present along the request path (server A, for example) wishes to send a dialog-forming request (such as REFER) to user agent A or B (user B for example). So, the entity acts as a user agent and sends the request to user agent B. This request is addressed to the URI of user agent B, which server A learned from inspecting the Contact header field in the 200 OK of the INVITE request. If this URI has the GRUU [11] property (it can be used by any element on the Internet, such as server A, to reach the specific user agent instance that generated that 200 OK to the INVITE), then the mechanism will work across NAT boundaries.
次に、要求経路(例えば、サーバA)に沿って存在している実体はユーザエージェントAかB(例えば、ユーザB)に対話を形成する要求(REFERなどの)を送りたがっています。 それで、実体は、宛てられるThisがサーバAがINVITE要求の200OKのContactヘッダーフィールドを点検するので学んだユーザエージェントBのURIに要求するユーザエージェントB.に、ユーザエージェントとして務めて、要求を送ります。 このURIにGRUU[11]特性があると(それはインターネットのサーバAなどのどんな原理によっても使用されて、その200OKをINVITEに生成した特定のユーザエージェントインスタンスに達することができます)、メカニズムはNAT境界の向こう側に動作するでしょう。
The request generated by server A will contain a Target-Dialog header field. This header field contains the dialog identifiers for the INVITE dialog between user agents A and B, composed of the Call-ID, local tag, and remote tag. Server A knew to include the Target- Dialog header field in the REFER request because it knows that user agent B supports it.
サーバAによって生成された要求はTarget-対話ヘッダーフィールドを含むでしょう。 このヘッダーフィールドはユーザエージェントAとBの間にINVITE対話のための対話識別子を含んでいます、Call-ID、地方のタグ、およびリモートタグを落ち着かせます。 サーバAはユーザエージェントBがそれをサポートするのを知っているのでREFER要求にTarget対話ヘッダーフィールドを含んでいるのを知っていました。
When the request arrives at user agent B, it needs to make an authorization decision. Because the INVITE dialog was established using a sips URI, and because the dialog identifiers are cryptographically random [2], no entity except for user agent A or the proxies on the path of the initial INVITE request can know the dialog identifiers. Thus, because the request contains those dialog identifiers, user agent B can be certain that the request came from user agent A, the two proxies, or an entity to whom the user agent or proxies gave the dialog identifiers. As such, it authorizes the request and performs the requested actions.
要求がユーザエージェントBに到着するとき、それは、承認決定をする必要があります。 INVITE対話が一口URIを使用することで確立されて、対話識別子が暗号で、いずれの無作為の[2]、ユーザエージェントA以外の実体もまたは初期のINVITE要求の経路のプロキシも対話識別子を知ることができないということであるので。 したがって、要求がそれらの対話識別子を含んでいるので、ユーザエージェントBは要求がユーザエージェントA、2つのプロキシ、またはユーザエージェントかプロキシが対話識別子を与えた実体から来たのを確信している場合があります。 そういうものとして、それは、要求を認可して、要求された動作を実行します。
3. User Agent Client (UAC) Behavior
3. ユーザエージェントのクライアント(UAC)の振舞い
A UAC SHOULD include a Target-Dialog header field in a request if the following conditions are all true:
以下の条件がすべて本当であるなら、UAC SHOULDは要求にTarget-対話ヘッダーフィールドを含んでいます:
1. The request is to be sent outside of any existing dialog.
1. 要求はどんな既存の対話の外にも送ることです。
2. The user agent client believes that the request may not be
authorized by the user agent server unless the user agent client
can prove that it is aware of the dialog identifiers for some
other dialog. Call this dialog the target dialog.
2. ユーザエージェントのクライアントは、ユーザエージェントのクライアントが、それがある他の対話のための対話識別子を意識していると立証できないなら要求がユーザエージェントサーバによって認可されないかもしれないと信じています。 目標対話にこの対話に電話をしてください。
3. The request does not otherwise contain information that indicates
that the UAC is aware of those dialog identifiers.
3. そうでなければ、要求はUACがそれらの対話識別子を意識しているのを示す情報を含んでいません。
Rosenberg Standards Track [Page 5] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[5ページ]
4. The user agent client knows that the user agent server supports
the Target-Dialog header field. It can know this if it has seen
a request or response from the user agent server within the
target dialog that contained a Supported header field that
included the tdialog option tag.
4. ユーザエージェントのクライアントは、ユーザエージェントサーバが、Target-対話がヘッダーフィールドであるとサポートするのを知っています。 tdialogオプションタグを含んでいたSupportedヘッダーフィールドを含んだ目標対話の中でユーザエージェントサーバから要求か応答を見たなら、それはこれを知ることができます。
If the fourth condition is not met, the UAC SHOULD NOT use this specification. Instead, if it is currently within a dialog with the User Agent Server (UAS), it SHOULD attempt to send the request within the existing target dialog.
第4条件が満たされないなら、UAC SHOULD NOTはこの仕様を使用します。 代わりに、現在、対話の中にそれはUserエージェントServer(UAS)と共にあって、既存の目標対話の中で要求を送るSHOULD試みです。
The following are examples of use cases in which these conditions are met:
以下による使用に関する例が会われた状態でこれらの状態がそうであるコネをケースに入れるということです:
o A REFER request is sent according to the principles of [14].
These REFER are sent outside of a dialog and do not contain any
other information that indicates awareness of the target dialog.
[14] also mandates that the REFER be sent only if the UA indicates
support for the target dialog specification.
o [14]の原則に応じて、REFER要求を送ります。 これらのREFERは対話の外に送られて、目標対話の認識を示すいかなる他の情報も含んでいません。 また、[14]は、UAが目標対話仕様のサポートを示す場合にだけREFERが送られるのを強制します。
o User A is in separate calls with users B and C. User A decides to
start a three way call, and so morphs into a focus [17]. User B
would like to learn the other participants in the conference. So,
it sends a SUBSCRIBE request to user A (who is now acting as the
focus) for the conference event package [16]. It is sent outside
of the existing dialog between user B and the focus, and it would
be authorized by A if user B could prove that it knows the dialog
identifiers for its existing dialog with the focus. Thus, the
Target-Dialog header field would be included in the SUBSCRIBE.
o ユーザAはユーザBとの別々の呼び出し中です、そして、C.User Aは3道が呼ぶので焦点[17]に変形する始めに決めます。 ユーザBは会議の他の関係者を学びたがっています。 それで、それは会議イベントパッケージ[16]のためにユーザA(現在、焦点として機能しています)への要求を登録に送ります。 ユーザBと焦点の間の既存の対話の外にそれを送ります、そして、ユーザBが、焦点がある既存の対話のための対話識別子を知っていると立証できるなら、Aはそれを認可するでしょうに。 その結果、Target-対話ヘッダーフィールドが含まれているだろう、登録。
The following are examples of use cases in which these conditions are not met:
以下による使用に関する例が会われた状態でこれらの状態がそうでないコネをケースに入れるということです:
o A server acting as a proxy is a participant in an INVITE dialog
that establishes a session. The server would like to use the
Keypad Markup Language (KPML) event package [18] to find out about
keypresses from the originating user agent. To do this, it sends
a SUBSCRIBE request. However, the Event header field of this
SUBSCRIBE contains event parameters that indicate the target
dialog of the subscription. As such, the request can be
authorized without additional information.
o プロキシとして務めるサーバはセッションを確立するINVITE対話の関係者です。 サーバは、起因しているユーザエージェントからkeypressesを見つけるのにKeypad Markup Language(KPML)イベントパッケージ[18]を使用したがっています。 これをするために、それは要求を登録に送ります。 しかしながら、このEventヘッダーフィールド、登録、購読の目標対話を示すイベントパラメタを含んでいます。 そういうものとして、追加情報なしで要求を認可できます。
o A server acting as a proxy is a participant in an INVITE dialog
that establishes a session. The server would like to use the
dialog event package [15] to find out about dialogs at the
originating user agent. To do this, it sends a SUBSCRIBE request.
However, the Event header field of this SUBSCRIBE contains event
parameters that indicate the target dialog of the subscription.
o プロキシとして務めるサーバはセッションを確立するINVITE対話の関係者です。 サーバは、起因しているユーザエージェントに対話を見つけるのに対話イベントパッケージ[15]を使用したがっています。 これをするために、それは要求を登録に送ります。 しかしながら、このEventヘッダーフィールド、登録、購読の目標対話を示すイベントパラメタを含んでいます。
Rosenberg Standards Track [Page 6] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[6ページ]
As such, the request can be authorized without additional
information.
そういうものとして、追加情報なしで要求を認可できます。
Specifications that intend to make use of the Target-Dialog header field SHOULD discuss specific conditions in which it is to be included.
それが含まれることになっているヘッダーフィールドSHOULDが議論するTarget-対話一定の条件を利用するつもりである仕様。
Assuming it is to be included, the value of the callid production in the Target-Dialog header field MUST be equal to the Call-ID of the target dialog. The "remote-tag" header field parameter MUST be present and MUST contain the tag that would be viewed as the remote tag from the perspective of the recipient of the new request. The "local-tag" header field parameter MUST be present and MUST contain the tag that would be viewed as the local tag from the perspective of the recipient of the new request.
それが含まれることになっていると仮定する場合、Target-対話ヘッダーフィールドにおける、callid生産の値は目標対話のCall-IDと等しいに違いありません。 「リモートタグ」ヘッダーフィールドパラメタは、存在していなければならなくて、リモートタグとして新しい要求の受取人の見解から見なされるタグを含まなければなりません。 「地方のタグ」ヘッダーフィールドパラメタは、存在していなければならなくて、地方のタグとして新しい要求の受取人の見解から見なされるタグを含まなければなりません。
The request sent by the UAC SHOULD include a Require header field that includes the tdialog option tag. This request should, in principle, never fail with a 420 (Bad Extension) response, because the UAC would not have sent the request unless it believed the UAS supported the extension. If a Require header field was not included, and the UAS didn't support the extension, it would normally reject the request because it was unauthorized, probably with a 403. However, without the Require header field, the UAC would not be able to differentiate between the following:
UAC SHOULDによって送られた要求はtdialogオプションタグを含んでいるRequireヘッダーフィールドを含んでいます。 420(悪いExtension)応答に応じて、この要求は原則として決して失敗するべきではありません、それが拡大であるとサポートされたUASを信じていない場合UACが要求を送らないので。 Requireヘッダーフィールドが含まれないで、またUASが拡大をサポートしないなら、通常、権限がなかったので、要求を拒絶するでしょうに、たぶん403で。 しかしながら、Requireヘッダーフィールドがなければ、UACは以下を区別できないでしょう:
o a 403 that arrived because the UAS didn't actually understand the
Target-Dialog header field (in which case the client should send
the request within the target dialog if it can)
o UASが実際にTarget-対話ヘッダーフィールドを理解していなかったので到着した403(その場合、それが送ることができるなら、クライアントは目標対話の中で要求を送るべきです)
o a 403 that arrived because the UAS understood the Target-Dialog
header field, but elected not to authorize the request despite the
fact that the UAC proved its awareness of the target dialog (in
which case the client should not resend the request within the
target dialog, even if it could).
o UASがTarget-対話ヘッダーフィールドを理解していたので到着しましたが、UACが目標対話の認識を立証したという(その場合、クライアントは目標対話の中で要求を再送するべきではありません、そうすることができても)事実にもかかわらず、要求を認可しないのを選んだ403。
4. User Agent Server Behavior
4. ユーザエージェントサーバの振舞い
If a user agent server receives a dialog-creating request and wishes to authorize the request, and if that authorization depends on whether or not the sender has knowledge of an existing dialog with the UAS, and information outside of the Target-Dialog header field does not provide proof of this knowledge, the UAS SHOULD check the request for the existence of the Target-Dialog header field. If this header field is not present, the UAS MAY still authorize the request by other means.
ユーザエージェントサーバが対話を作成する要求を受け取って、要求を認可したがっていて、その承認が送付者には既存の対話に関する知識がUAS、およびTarget-対話ヘッダーフィールドの外部がこの知識の証拠を提供しないという情報と共にあるかどうかによるなら、UAS SHOULDはTarget-対話ヘッダーフィールドの存在を求める要求をチェックします。 このヘッダーフィールドが存在していないなら、UAS MAYは他の手段でまだ要求を認可しています。
Rosenberg Standards Track [Page 7] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[7ページ]
If the header field is present, and the value of the callid production, the "remote-tag", and "local-tag" values match the Call-ID, remote tag, and local tag of an existing dialog, and the dialog that they match was established using a sips URI, the UAS SHOULD authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog.
ヘッダーフィールドが存在していて、callid生産の値、「リモートタグ」、および「地方のタグ」値が既存の対話のCall-ID、リモートタグ、および地方のタグに合って、それらが合っている対話が一口URIを使用することで確立されたなら、何かその対話、またはその対話を作成した要求の経路の実体によって信じられたどんな実体も作成した要求の経路の実体を認可するなら、UAS SHOULDは要求を認可します。
If the dialog identifiers match, but they match a dialog not created with a sips URI, the UAS MAY authorize the request if it would authorize any entity on the path of the request that created that dialog, or any entity trusted by an entity on the path of the request that created that dialog. However, in this case, any eavesdropper on the original dialog path would have access to the dialog identifiers, and thus the authorization is optional.
対話識別子が合っていますが、一口URIで作成されなかった対話に合っているなら、何かその対話、またはその対話を作成した要求の経路の実体によって信じられたどんな実体も作成した要求の経路の実体を認可するなら、UAS MAYは要求を認可します。 しかしながら、この場合、元の対話経路のどんな立ち聞きする者も対話識別子に近づく手段を持っているでしょう、そして、その結果、承認は任意です。
If the dialog identifiers don't match, or if they don't contain both a "remote-tag" and "local-tag" parameter, the header field MUST be ignored, and authorization MAY be determined by other means.
「リモートタグ」の、そして、「地方のタグ」のパラメタを含んでいないなら対話識別子が合っていないなら、ヘッダーフィールドを無視しなければなりません、そして、承認は他の手段で決定するかもしれません。
5. Proxy Behavior
5. プロキシの振舞い
Proxy behavior is unaffected by this specification.
プロキシの振舞いはこの仕様で影響を受けないです。
6. Extensibility Considerations
6. 伸展性問題
This specification depends on a user agent client knowing, ahead of sending a request to a user agent server, whether or not that user agent server supports the Target-Dialog header field. As discussed in Section 3, the UAC can know this because it saw a request or response sent by that UAS within the target dialog that contained the Supported header field whose value included the tdialog option tag.
この仕様をユーザエージェントサーバに要求を送る前に知っているユーザエージェントのクライアントに頼っています、そのユーザエージェントサーバがTarget-対話ヘッダーフィールドをサポートするか否かに関係なく。 セクション3で議論するように、要求か応答が値がtdialogオプションタグを含んでいたSupportedヘッダーフィールドを含んだ目標対話の中のそのUASによって送られるのを見たので、UACはこれを知ることができます。
Because of this requirement, it is especially important that user agents compliant to this specification include a Supported header field in all dialog forming requests and responses. Inclusion of the Supported header fields in requests is at SHOULD strength per RFC 3261. This specification does not alter that requirement. However, implementers should realize that, unless the tdialog option tag is placed in the Supported header field of requests and responses, this extension is not likely to be used, and instead, the request is likely to be re-sent within the existing target dialog (assuming the sender is the UA on the other side of the target dialog). As such, the conditions in which the SHOULD would not be followed would be those rare cases in which the UA does not want to enable usage of this extension.
この要件のために、この仕様に言いなりになっているユーザエージェントが要求と応答を形成しながらすべての対話でSupportedヘッダーフィールドを入れるのは、特に重要です。 要求でのSupportedヘッダーフィールドの包含がRFC3261あたりのSHOULDの強さであります。 この仕様はその要件を変更しません。 しかしながら、implementersは、tdialogオプションタグが要求と応答のSupportedヘッダーフィールドに置かれない場合この拡大が使用されそうにないとわかるはずです、そして、代わりに、要求は既存の目標対話の中で再送されそうです(送付者を仮定するのは、目標対話の反対側の上のUAです)。 そういうものとして、状態はSHOULDが続かれていないUAがこの拡大の用法を可能にしたがっていないそれらのまれなケースでしょう。
Rosenberg Standards Track [Page 8] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[8ページ]
7. Header Field Definition
7. ヘッダーフィールド定義
The grammar for the Target-Dialog header field is defined as follows:
Target-対話ヘッダーフィールドのための文法は以下の通り定義されます:
Target-Dialog = "Target-Dialog" HCOLON callid *(SEMI
td-param) ;callid from RFC 3261
td-param = remote-param / local-param /
generic-param
remote-param = "remote-tag" EQUAL token
local-param = "local-tag" EQUAL token
;token and generic-param from RFC 3261
目標対話=「目標対話」HCOLON callid*(SEMI td-param); ジェネリック-paramのリモート地方のリモートparam/param/param=「リモートタグ」EQUALトークン地方のparam=「地方のタグ」EQUAL RFC3261td-paramからのcallid=トークン; RFC3261からのトークンとジェネリック-param
Figures 3 and 4 are an extension of Tables 2 and 3 in RFC 3261 [2] for the Target-Dialog header field. The column "INF" is for the INFO method [4], "PRA" is for the PRACK method [5], "UPD" is for the UPDATE method [6], "SUB" is for the SUBSCRIBE method [3], "NOT" is for the NOTIFY method [3], "MSG" is for the MESSAGE method [7], "REF" is for the REFER method [8], and "PUB" is for the PUBLISH method [9].
数字3と4はTarget-対話ヘッダーフィールドのためのRFC3261[2]でのTables2と3の拡大です。 「INF」というコラムがインフォメーションメソッド[4]のためのものであり、"PRA"がPRACKメソッド[5]のためのものであり、"UPD"がアップデートメソッド[6]のためのものであり、「潜水艦」がある、登録、メソッド[3]、「NOT」がそう、メソッド[3]に通知してください、「エムエスジー」がメッセージメソッド[7]のためのものであり、「審判」がある、メソッド[8]を参照してください。そうすれば、「パブ」が参照する、メソッド[9]を発行してください。
Header field where proxy ACK BYE CAN INV OPT REG PUB
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG PUB
Target-Dialog R - - - - o - - -
目標対話R--、--、--、--o----、-
Figure 3: Allowed Methods for Target-Dialog
図3: 目標対話のための許容メソッド
Header field where proxy PRA UPD SUB NOT INF MSG REF
ヘッダーフィールドどこプロキシPRA UPD SUB NOT INF MSG REF
Target-Dialog R - - - o - - - o
目標対話R--、--、--o----、--、o
Figure 4: Allowed Methods for Target-Dialog
図4: 目標対話のための許容メソッド
8. Security Considerations
8. セキュリティ問題
The Target-Dialog header field is used to authorize requests based on the fact that the sender of the request has access to information that only certain entities have access to. In order for such an authorization decision to be secure, two conditions have to be met. Firstly, no eavesdroppers can have access to this information. That requires the original SIP dialog to be established using a sips URI, which provides TLS on each hop. With a sips URI, only the user agents and proxies on the request path will be able to know the dialog identifiers. The second condition is that the dialog identifiers be sufficiently cryptographically random that they cannot be guessed. RFC 3261 requires global uniqueness for the Call-ID and 32 bits of cryptographic randomness for each tag (there are two tags for a dialog). Given the short duration of a typical dialog (perhaps as long as a day), this amount of randomness appears adequate for
Target-対話ヘッダーフィールドは、要求の送付者が、ある実体だけが近づく手段を持っている情報に近づく手段を持っているという事実に基づく要求を認可するのに使用されます。 安全であるというそのような承認決定の注文では、2つの条件が満たされなければなりません。 まず第一に、どんな立ち聞きする者もこの情報に近づく手段を持つことができません。 それは、オリジナルのSIP対話が確立されるのを一口URI(各ホップの上でTLSを提供する)を使用することで必要とします。 一口で、要求経路のURI、ユーザエージェント、およびプロキシだけが対話識別子を知ることができるでしょう。 第2状態が対話識別子が十分暗号でそうであるということである、無作為である、それらを推測できません。 RFC3261は各タグのためにグローバルなユニークさを暗号の偶発性のCall-IDと32ビット必要とします(対話のための2個のタグがあります)。 典型的な対話(1日と恐らく同じくらい長い)の短期間を考えて、この量の偶発性が適切に見えます。
Rosenberg Standards Track [Page 9] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[9ページ]
preventing guessing attacks. However, it's important to note that this specification requires true cryptographic randomness as set forth in RFC 4086 [11]. Weaker pseudorandom identifiers reduce the probability of collision, but because they are guessable, they are not sufficient to prevent an attacker from observing a sequence of identifiers, guessing the next one, and then using this specification to launch an attack.
推測するのを防ぐのを攻撃されます。 しかしながら、この仕様がRFC4086[11]に詳しく説明されるように本当の暗号の偶発性を必要とすることに注意するのは重要です。 より弱い擬似ランダム識別子は衝突確率を減少させますが、それらは推測可能であるので、攻撃者が識別子の系列を観測するのを防ぐために十分ではありません、次のものを推測して、次に、攻撃を開始するのにこの仕様を使用して。
9. Relationship with In-Reply-To
9. に対して関係。
RFC 3261 defines the In-Reply-To header field. It provides a list of Call-IDs for calls that the current request references or returns. It was meant to serve a similar purpose as the Reply-To in email: to facilitate the construction of "threads" of conversations in a user interface. Target-Dialog is similar, in that it also references a previous session. Due to their similarities, it is important to understand the differences, as these two header fields are not substitutes for each other.
RFC3261が定義する、Inが答える、ヘッダーフィールド。 それは、Call-IDのリストを電流が参照を要求するという要求に提供するか、または戻ります。 同様の目的に役立つことになっていた、Reply、-、メールで: ユーザーインタフェースでの会話の「スレッド」の工事を容易にするために。 目標対話は前のセッションに参照をつけるという点においても同様です。 それらの類似性のために、違いを理解しているのは重要です、これらの2つのヘッダーフィールドが互いの代用品でないので。
Firstly, In-Reply-To is meant for consumption by a human or a user interface widget, for providing the user with a context that allows them to decide what a call is about and whether they should take it. Target-Dialog, on the other hand, is meant for consumption by the user agent itself, to facilitate authorization of session requests in specific cases where authorization is not a function of the user, but rather the underlying protocols. A UA will authorize a call containing Target-Dialog based on a correct value of the Target- Dialog header field.
まず第一に、Inが答える、人間かユーザーインタフェースウィジェットによる消費、周囲でそれを取るべきであるか否かに関係なく、彼らが呼び出しが何であるかを決めることができる文脈をユーザに提供するために、意味されます。 他方では、消費で、目標対話が承認がユーザの機能ではなく、むしろ基本的なプロトコルである特定の場合におけるセッション要求の承認を容易にするのがユーザエージェント自身によって意図されます。 UAはTarget対話ヘッダーフィールドの正しい値に基づくTarget-対話を含む呼び出しを認可するでしょう。
Secondly, Target-Dialog references a specific dialog that must be currently in progress. In-Reply-To references a previous call attempt, most likely one that did not result in a dialog. This is why In-Reply-To uses a Call-ID, and Target-Dialog uses a set of dialog identifiers.
第二に、Target-対話は現在進行していなければならない特定の対話に参照をつけます。 中で答える、前の呼び出し試み、たぶん対話をもたらさなかったものに、参照をつけます。 これが理由である、Inが答える、Call-ID、およびaが設定した対話識別子のTarget-対話用途を使用します。
Finally, In-Reply-To implies cause and effect. When In-Reply-To is present, it means that the request is being sent because of the previous request that was delivered. Target-Dialog does not imply cause and effect, merely awareness for the purposes of authorization.
最終的である、Inが答える、因果を含意します。 いつ、Inが答えるか、存在している、それは、要求が提供された前の要求のために送られることを意味します。 目標対話は承認の目的のために因果、単に認識を含意しません。
10. Example Call Flow
10. 例の呼び出し流動
In this example, user agent A and user agent B establish an INVITE- initiated dialog through Server-A and Server-B, each of which acts as a proxy for the INVITE. Server B would then like to use the application interaction framework [14] to request that user agent A fetch an HTML user interface component. To do that, it sends a REFER request to A's URI. The flow for this is shown in Figure 5. The
この例に、ユーザエージェントAとユーザエージェントBはServer-AとServer-Bを通してINVITEの開始している対話を確立します。それはINVITEのプロキシとしてそれぞれ務めます。 そして、サーバBは、ユーザエージェントAがHTMLユーザーインタフェースコンポーネントをとって来るよう要求するのにアプリケーション間連携フレームワーク[14]を使用したがっています。 それをするために、それはREFER要求をAのURIに送ります。 これのための流れは図5に示されます。 The
Rosenberg Standards Track [Page 10] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[10ページ]
conventions of [19] are used to describe representation of long message lines.
[19]のコンベンションは、長いメッセージ行の表現について説明するのに使用されます。
A Server-A Server-B B
|(1) INVITE | | |
|----------->| | |
| |(2) INVITE | |
| |----------->| |
| | |(3) INVITE |
| | |----------->|
| | |(4) 200 OK |
| | |<-----------|
| |(5) 200 OK | |
| |<-----------| |
|(6) 200 OK | | |
|<-----------| | |
|(7) ACK | | |
|------------------------------------->|
| |(8) REFER | |
| |<-----------| |
|(9) REFER | | |
|<-----------| | |
|(10) 200 OK | | |
|----------->| | |
| |(11) 200 OK | |
| |----------->| |
サーバAサーバB B|(1) 招待| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(2) 招待| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(3) 招待| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、| |(4) 200 OK| | | | <、-、-、-、-、-、-、-、-、-、--、|、| |(5) 200 OK| | | | <、-、-、-、-、-、-、-、-、-、--、|、| |(6) 200 OK| | | | <、-、-、-、-、-、-、-、-、-、--、|、|、| |(7) ACK| | | |------------------------------------->| | |(8) 参照してください。| | | | <、-、-、-、-、-、-、-、-、-、--、|、| |(9) 参照してください。| | | | <、-、-、-、-、-、-、-、-、-、--、|、|、| |(10) 200 OK| | | |、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |(11) 200 OK| | | |、-、-、-、-、-、-、-、-、-、--、>|、|
Figure 5
図5
First, the caller sends an INVITE, as shown in message 1.
まず最初に、訪問者はメッセージ1に示されるようにINVITEを送ります。
INVITE sips:B@example.com SIP/2.0 Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller <sip:A@example.com>;tag=kkaz- To: Callee <sip:B@example.org> Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Max-Forwards: 70 Supported: tdialog Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, REFER Accept: application/sdp, text/html <allOneLine> Contact: <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>;schemes="http,sip,sips" </allOneLine> Content-Length: ... Content-Type: application/sdp
INVITE一口: B@example.com SIP/2.0Via: 一口/2.0/TLS host.example.com; ブランチ=z9hG4bK9zz8From: 訪問者<一口: A@example.com 、gt;、;=kkaz-To:にタグ付けをしてください 訪問される人<一口: B@example.org 、gt;、呼び出しID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 前方へマックスを招待してください: 70は支持しました: tdialog Allow: さようなら、招待、オプション、キャンセル、ACKは参照します。受け入れてください: アプリケーション/sdp、テキスト/html<allOneLine>Contact: <一口: A@example.com;gruu;opaque =つぼ:uuid:f81d4f ae-7dec-11d0-a765-00a0c91e6bf6; 格子=99a>; 計画は「http(一口)はちびちび飲み」</allOneLine>のContent-長さと等しいです: ... コンテントタイプ: アプリケーション/sdp
Rosenberg Standards Track [Page 11] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[11ページ]
--SDP not shown--
--見せられなかったSDP--
The INVITE indicates that the caller supports GRUU (note its presence in the Contact header field of the INVITE) and the Target-Dialog header field. This INVITE is forwarded to the callee (messages 2-3), which generates a 200 OK response that is forwarded back to the caller (message 4-5). Message 5 might look like:
INVITEは、訪問者がGRUU(INVITEのContactヘッダーフィールドで存在に注意する)とTarget-対話ヘッダーフィールドを支持するのを示します。 訪問される人(メッセージ2-3)にこのINVITEを送ります。(それは、訪問者(メッセージ4-5)に送って戻される200OK応答を発生させます)。 メッセージ5に似るかもしれません:
SIP/2.0 200 OK Via: SIP/2.0/TLS host.example.com;branch=z9hG4bK9zz8 From: Caller <sip:A@example.com>;tag=kkaz- To: Callee <sip:B@example.org>;tag=6544 Call-ID: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 INVITE Contact: <sips:B@pc.example.org> Content-Length: ... Content-Type: application/sdp
以下を通って一口/2.0 200OK 一口/2.0/TLS host.example.com; ブランチ=z9hG4bK9zz8From: 訪問者<一口: A@example.com 、gt;、;=kkaz-To:にタグ付けをしてください 訪問される人<一口: B@example.org 、gt;、; タグは6544年の呼び出しIDと等しいです: fa77as7dad8-sd98ajzz@host.example.com CSeq: 1 接触を招いてください: <一口: B@pc.example.org 、gt;、コンテンツの長さ: ... コンテントタイプ: アプリケーション/sdp
--SDP not shown--
--見せられなかったSDP--
In this case, the called party does not support GRUU or the Target- Dialog header field. The caller generates an ACK (message 7). Server B then decides to send a REFER to user A:
この場合、被呼者はGRUUかTarget対話ヘッダーフィールドを支持しません。 訪問者はACK(メッセージ7)を発生させます。 そして、サーバBは、ユーザA:にREFERを送ると決めます。
<allOneLine>
REFER sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a SIP/2.0
</allOneLine>
Via: SIP/2.0/TLS serverB.example.org;branch=z9hG4bK9zz10
From: Server B <sip:serverB.example.org>;tag=mreysh
<allOneLine>
To: Caller <sips:A@example.com;gruu;opaque=urn:uuid:f81d4f
ae-7dec-11d0-a765-00a0c91e6bf6;grid=99a>
</allOneLine>
Target-Dialog: fa77as7dad8-sd98ajzz@host.example.com
;local-tag=kkaz-
;remote-tag=6544
Refer-To: http://serverB.example.org/ui-component.html
Call-ID: 86d65asfklzll8f7asdr@host.example.com
CSeq: 1 REFER
Max-Forwards: 70
Require: tdialog
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, NOTIFY
Contact: <sips:serverB.example.org>
Content-Length: 0
<allOneLine>REFER一口: A@example.com;gruu;opaque はつぼ:uuid:f81d4f ae-7dec-11d0-a765-00a0c91e6bf6と等しいです; 格子は99a SIP/2.0</allOneLine>Viaと等しいです: 一口/2.0/TLS serverB.example.org; ブランチ=z9hG4bK9zz10From: サーバB<一口: serverB.example.org>; =mreysh<allOneLine>To:にタグ付けをしてください。 訪問者<はちびちび飲みます: A@example.com;gruu;opaque はつぼ:uuid:f81d4f ae-7dec-11d0-a765-00a0c91e6bf6と等しいです; 格子は99a></allOneLine>Target-対話と等しいです: fa77as7dad8-sd98ajzz@host.example.com ; =kkazにローカルと同じくらいタグ付けをしてください、-、;リモートタグが6544とTo:を参照する状態で等しい http://serverB.example.org/ui-component.html 呼び出しID: 86d65asfklzll8f7asdr@host.example.com CSeq: 1 前方へマックスを参照してください: 70 必要です: tdialog Allow: さようなら、招待、オプション、キャンセル、ACKは接触に通知します: <一口: serverB.example.org>コンテンツの長さ: 0
Rosenberg Standards Track [Page 12] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[12ページ]
This REFER will be delivered to server A because it was sent to the GRUU. From there, it is forwarded to user agent A (message 9) and authorized because of the presence of the Target-Dialog header field.
それをGRUUに送ったので、このREFERをサーバAに届けるでしょう。 そこから、それは、ユーザエージェントA(メッセージ9)に送られて、Target-対話ヘッダーフィールドの存在のために認可されます。
11. IANA Considerations
11. IANA問題
This specification registers a new SIP header field, a new option tag according to the processes of RFC 3261 [2], and two new header field parameters according to the processes of RFC 3968 [10].
RFC3968[10]の過程に従って、この仕様は新しいSIPヘッダーフィールド、RFC3261[2]の過程に従った新しいオプションタグ、および2つの新しいヘッダーフィールドパラメタを示します。
11.1. Header Field
11.1. ヘッダーフィールド
RFC Number: RFC 4538
RFC番号: RFC4538
Header Field Name: Target-Dialog
ヘッダーフィールド名: 目標対話
Compact Form: none
コンパクト形: なし
11.2. Header Field Parameters
11.2. ヘッダーフィールドパラメタ
This section registers two header field parameters according to the processes of RFC 3968 [10].
RFC3968[10]の過程に従って、このセクションは2つのヘッダーフィールドパラメタを示します。
11.2.1. local-tag
11.2.1. 地方のタグ
Header Field: Target-Dialog
ヘッダーフィールド: 目標対話
Header Field Parameter: local-tag
ヘッダーフィールドパラメタ: 地方のタグ
Predefined Values: None
事前に定義された値: なし
RFC: RFC 4538
RFC: RFC4538
11.2.2. remote-tag
11.2.2. リモートタグ
Header Field: Target-Dialog
ヘッダーフィールド: 目標対話
Header Field Parameter: remote-tag
ヘッダーフィールドパラメタ: リモートタグ
Predefined Values: None
事前に定義された値: なし
RFC: RFC 4538
RFC: RFC4538
Rosenberg Standards Track [Page 13] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[13ページ]
11.3. SIP Option Tag
11.3. 一口オプションタグ
This specification registers a new SIP option tag per the guidelines in Section 27.1 of RFC 3261.
この仕様はRFC3261のセクション27.1に1ガイドラインあたり1個の新しいSIPオプションタグを登録します。
Name: tdialog
以下を命名してください。 tdialog
Description: This option tag is used to identify the target dialog
header field extension. When used in a Require header field, it
implies that the recipient needs to support the Target-Dialog
header field. When used in a Supported header field, it implies
that the sender of the message supports it.
記述: このオプションタグは、目標対話ヘッダーフィールド拡大を特定するのに使用されます。 Requireヘッダーフィールドに使用されると、それは、受取人が、Target-対話ヘッダーフィールドを支持する必要であるのを含意します。 Supportedヘッダーフィールドに使用されると、それは、メッセージ送信者がそれを支持するのを含意します。
12. Acknowledgements
12. 承認
This specification is based on a header field first proposed by Robert Sparks in the dialog usage draft [12]. John Elwell provided helpful comments.
この仕様は対話用法草稿[12]で最初にロバート・スパークスによって提案されたヘッダーフィールドに基づいています。 ジョン・エルウェルは役に立つコメントを提供しました。
13. References
13. 参照
13.1. Normative References
13.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] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[3] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[4] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[4] ドノヴァン、S.、「一口インフォメーション方法」、RFC2976、2000年10月。
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[5] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
[6] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE
Method", RFC 3311, October 2002.
[6] ローゼンバーグ、J.、「セッション開始プロトコル(一口)アップデート方法」、RFC3311、2002年10月。
[7] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[7] キャンベル、B.、ローゼンバーグ、J.、Schulzrinne、H.、Huitema、C.、およびD.Gurle、「インスタントメッセージングのためのセッション開始プロトコル(一口)拡大」、RFC3428(2002年12月)。
[8] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[8] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、2003年4月。
Rosenberg Standards Track [Page 14] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[14ページ]
[9] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[9]Niemi、A.、「イベント州政府出版物のためのセッション開始プロトコル(一口)拡大」、RFC3903、2004年10月。
[10] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Header Field Parameter Registry for the Session Initiation
Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[10] キャマリロ、G.、「セッション開始プロトコル(一口)のためのISOCの機関の一つで(IANA)ヘッダーフィールドパラメタ登録」、BCP98、RFC3968(2004年12月)。
13.2. Informative References
13.2. 有益な参照
[11] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005.
[11] イーストレークとD.とシラー、J.とS.クロッカー、「セキュリティのための偶発性要件」BCP106、2005年6月のRFC4086。
[12] Sparks, R., "Multiple Dialog Usages in the Session Initiation
Protocol", Work in Progress, March 2006.
[12] R.、「セッション開始プロトコルの複数の対話用法」というスパークは進歩、2006年3月に働いています。
[13] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", Work in Progress, May 2006.
[13] ローゼンバーグ、J.、「セッション開始プロトコル(一口)にRoutableユーザエージェント(UA)URI(GRUU)をグローバルに得て、使用すること」は進行中(2006年5月)で働いています。
[14] Rosenberg, J., "A Framework for Application Interaction in the
Session Initiation Protocol (SIP)", Work in Progress,
July 2005.
[14] ローゼンバーグ、J.、「セッション開始プロトコル(一口)におけるアプリケーション間連携のための枠組み」が進歩、2005年7月に働いています。
[15] Rosenberg, J., Schulzrinne, H., and R. Mahy, "An INVITE-
Initiated Dialog Event Package for the Session Initiation
Protocol (SIP)", RFC 4235, November 2005.
[15] ローゼンバーグ、J.、Schulzrinne、H.、およびR.マーイ、「招待はセッション開始プロトコル(一口)のために対話イベントパッケージを開始しました」、RFC4235、2005年11月。
[16] Rosenberg, J., "A Session Initiation Protocol (SIP) Event
Package for Conference State", Work in Progress, July 2005.
[16] ローゼンバーグ、J.、「コンファレンス状態へのセッション開始プロトコル(一口)イベントパッケージ」が進歩、2005年7月に働いています。
[17] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
2006年2月の[17] ローゼンバーグ、J.、「セッション開始プロトコル(一口)がある会議のための枠組み」RFC4353。
[18] Burger, E., "A Session Initiation Protocol (SIP) Event Package
for Key Press Stimulus (KPML)", Work in Progress,
December 2004.
[18] バーガー、E.、「主要なプレス刺激(KPML)のためのセッション開始プロトコル(一口)イベントパッケージ」が進歩、2004年12月に働いています。
[19] Sparks, R., Ed., Hawrylyshen, A., Johnston, A., Rosenberg, J.,
and H. Schulzrinne, "Session Initiation Protocol (SIP) Torture
Test Messages", RFC 4475, May 2006.
[19] スパーク、R.Hawrylyshen、A.、ジョンストン、A.、ローゼンバーグ、J.、およびH.Schulzrinne(エド)、「セッション開始プロトコル(一口)耐久テストメッセージ」(RFC4475)は2006がそうするかもしれません。
Rosenberg Standards Track [Page 15] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[15ページ]
Author's Address
作者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)
Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Rosenberg Standards Track [Page 16] RFC 4538 Target Dialog June 2006
RFC4538が対話2006年6月に狙うローゼンバーグ標準化過程[16ページ]
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rosenberg Standards Track [Page 17]
ローゼンバーグ標準化過程[17ページ]
一覧
スポンサーリンク
