RFC4244 日本語訳
4244 An Extension to the Session Initiation Protocol (SIP) for RequestHistory Information. M. Barnes, Ed.. November 2005. (Format: TXT=98992 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Barnes, Ed. Request for Comments: 4244 Nortel Category: Standards Track November 2005
ワーキンググループのM.バーンズ、エドをネットワークでつないでください。コメントのために以下を要求してください。 4244年のノーテルカテゴリ: 標準化過程2005年11月
An Extension to the Session Initiation Protocol (SIP)
for Request History Information
要求履歴情報のためのセッション開始プロトコル(一口)への拡大
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 (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a call arrives at a specific application or user. This document defines a new optional SIP header, History-Info, for capturing the history information in requests.
このドキュメントは、歴史が(SIP)が要求するSession Initiationプロトコルに関連している情報であるとキャプチャするために標準のメカニズムを定義します。 この能力は、呼び出しが特定のアプリケーションかユーザに到達するどのように、理由に関して情報を提供するかによって、多くの高度サービスを可能にします。 このドキュメントは、要求における履歴情報を得るために新しい任意のSIPヘッダー、歴史インフォメーションを定義します。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Overview ...................................................2
1.2. Conventions Used in This Document ..........................3
1.3. Background: Why define a Generic "Request History"
capability? ................................................3
2. "Request History" Requirements ..................................4
2.1. Security Requirements ......................................6
2.2. Privacy Requirements .......................................7
3. Request History Information Description .........................7
3.1. Optionality of History-Info ................................8
3.2. Securing History-Info ......................................8
3.3. Ensuring the Privacy of History-Info .......................9
4. Request History Information Protocol Details ....................9
4.1. Protocol Structure of History-Info ........................10
4.2. Protocol Examples .........................................11
4.3. Protocol Usage ............................................12
1. 序論…2 1.1. 概要…2 1.2. このドキュメントで中古のコンベンション…3 1.3. バックグラウンド: なぜGeneric「要求歴史」能力を定義しますか? ................................................3 2. 「要求歴史」要件…4 2.1. セキュリティ要件…6 2.2. プライバシー要件…7 3. 履歴情報記述を要求してください…7 3.1. 歴史インフォメーションのOptionality…8 3.2. 歴史インフォメーションを保証します…8 3.3. 歴史インフォメーションのプライバシーを確実にします…9 4. 履歴情報プロトコルの詳細を要求してください…9 4.1. 歴史インフォメーションの構造について議定書の中で述べてください…10 4.2. 例について議定書の中で述べてください…11 4.3. 用法を議定書の中で述べてください…12
Barnes Standards Track [Page 1] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[1ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
4.3.1. User Agent Client (UAC) Behavior ...................12
4.3.2. User Agent Server (UAS) Behavior ...................13
4.3.3. Proxy Behavior .....................................13
4.3.4. Redirect Server Behavior ...........................18
4.4. Security for History-Info .................................18
4.5. Example Applications Using History-Info ...................19
4.5.1. Example with Privacy Header for Entire
Request at Proxy2 ..................................21
4.5.2. Example with Privacy Header for Specific
URI (UA4) at Proxy2 ................................22
5. Application Considerations .....................................24
6. Security Considerations ........................................25
7. IANA Considerations ............................................25
7.1. Registration of New SIP History-Info Header ...............25
7.2. Registration of "history" for SIP Privacy Header ..........26
8. Normative References ...........................................26
9. Informative References .........................................26
10. Acknowledgements ..............................................26
11. Contributors' Addresses .......................................27
Appendix. Example Scenarios........................................28
Appendix A. Sequentially forking (History-Info in Response).....28
Appendix B. Voicemail...........................................34
Appendix C. Automatic Call Distribution Example.................39
Appendix D. Session via Redirect and Proxy Servers..............41
4.3.1. ユーザエージェントのクライアント(UAC)の振舞い…12 4.3.2. ユーザエージェントサーバ(UAS)の振舞い…13 4.3.3. プロキシの振舞い…13 4.3.4. サーバの振舞いを向け直してください…18 4.4. 歴史インフォメーションのためのセキュリティ…18 4.5. 歴史インフォメーションを使用する例のアプリケーション…19 4.5.1. Proxy2での全体の要求のためのプライバシーヘッダーがある例…21 4.5.2. Proxy2の特定のURI(UA4)のためのプライバシーヘッダーがある例…22 5. アプリケーション問題…24 6. セキュリティ問題…25 7. IANA問題…25 7.1. 新しい一口歴史インフォメーションヘッダーの登録…25 7.2. 一口プライバシーヘッダーへの「歴史」の登録…26 8. 標準の参照…26 9. 有益な参照…26 10. 承認…26 11. 貢献者のアドレス…27付録。 例のシナリオ…28 付録A.Sequentially分岐(Responseの歴史インフォメーション)…28付録B.ボイスメール…34付録C.自動着信呼分配の例…39 RedirectとProxyサーバを通した付録D.Session…41
1. Introduction
1. 序論
1.1. Overview
1.1. 概要
Many services that SIP is anticipated to support require the ability to determine why and how the call arrived at a specific application. Examples of such services include (but are not limited to) sessions initiated to call centers via "click to talk" SIP Uniform Resource Locators (URLs) on a web page, "call history/logging" style services within intelligent "call management" software for SIP User Agents (UAs), and calls to voicemail servers. Although SIP implicitly provides the redirect/retarget capabilities that enable calls to be routed to chosen applications, there is currently no standard mechanism within SIP for communicating the history of such a request. This "request history" information allows the receiving application to determine hints about how and why the call arrived at the application/user.
SIPがサポートするために予期される多くのサービスが呼び出しがなぜ、どのように特定のアプリケーションに到達したかを決定する能力を必要とします。 しかし、そのようなサービスに関する例が含んでいる、(制限されない、)、ウェブページでUniform Resource Locator(URL)に「話すクリック」SIPを通したセンターに電話をするために開始されたセッション、「呼び出し歴史/伐採」スタイルはSIP Userエージェント(UAs)のために知的な「呼び出し管理」の中でソフトウェアを調整して、ボイスメールサーバに呼びかけます。 SIPはそれとなく選ばれたアプリケーションに発送されるという要求を可能にする再直接の/「再-目標」能力を提供しますが、そのような要求の歴史を伝えるためのSIPの中にどんな標準のメカニズムも現在、ありません。 この「要求歴史」情報で、受信アプリケーションは呼び出しがアプリケーション/ユーザに到着したどのように、理由に関してヒントを決定できるか。
This document defines a new SIP header, History-Info, to provide a standard mechanism for capturing the request history information to enable a wide variety of services for networks and end-users. The History-Info header provides a building block for development of new services.
このドキュメントは、要求が履歴情報であるとキャプチャするのにネットワークとエンドユーザのためにさまざまなサービスを可能にするために標準のメカニズムを提供するために新しいSIPヘッダー、歴史インフォメーションを定義します。 歴史インフォメーションヘッダーは新種業務の開発にブロックを提供します。
Barnes Standards Track [Page 2] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[2ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
Section 1.3 provides additional background motivation for the Request History capability. Section 2 identifies the requirements for a solution, with Section 3 providing an overall description of the solution.
セクション1.3はRequest歴史能力に関する追加バックグラウンド動機を提供します。 セクション3がソリューションの総合的な記述を提供している状態で、セクション2はソリューションのための要件を特定します。
Section 4 provides the details of the additions to the SIP protocol. Example uses of the new header are included in Section 4.5, with additional scenarios included in the Appendix.
セクション4はSIPプロトコルに追加の詳細を明らかにします。 新しいヘッダーの例の用途は追加シナリオがAppendixに含まれているセクション4.5に含まれています。
Section 5 summarizes the application considerations identified in the previous sections. Section 6 summarizes the security solution.
セクション5は前項で特定されたアプリケーション問題をまとめます。 セクション6はセキュリティソリューションをまとめます。
1.2. Conventions Used in This Document
1.2. 本書では使用されるコンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.3. Background: Why define a Generic "Request History" capability?
1.3. バックグラウンド: なぜGeneric「要求歴史」能力を定義しますか?
SIP implicitly provides redirect/retarget capabilities that enable calls to be routed to specific applications as defined in [RFC3261]. The term 'retarget' will be used henceforth in this document to refer to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request and thus changing the target of the request. This term is chosen to avoid associating this request history only with the specific SIP Redirect Server capability that provides for a response to be sent back to a UAC requesting that the UAC should retarget the original request to an alternate URI. The rules for determining request targets as described in Section 16.5 of [RFC3261] are consistent with the use of the retarget term in this document.
SIPはそれとなく[RFC3261]で定義されるように特定のアプリケーションに発送されるという要求を可能にする再直接の/「再-目標」能力を提供します。 '「再-目標」'という用語は、今後は、要求におけるUniform Resource Identifier(URI)を変えて、その結果、要求の目標を変えながらProxyサーバ/ユーザエージェントClient(UAC)のプロセスについて言及するのに本書では使用されるでしょう。 今期は、この要求歴史を関連づけるのを避けるために単にUACはオリジナルが代替のURIに要求する「再-目標」がそうするべきであるよう要求するUACが送り返されるために応答に備える特定のSIP Redirect Server能力で選ばれています。 [RFC3261]のセクション16.5で説明されるように要求目標を決定するための規則は本書ではという「再-目標」用語の使用と一致しています。
The motivation for the request history is that in the process of retargeting, old routing information can be forever lost. This lost information may be important history that allows elements to which the call is retargeted to process the call in a locally defined, application-specific manner. The proposal in this document is to provide a mechanism for transporting the request history. It is not proposing any application-specific behavior for a Proxy or UA upon receipt of the information. Indeed, such behavior should be a local decision for the recipient application.
要求歴史に関する動機は「再-狙」いの途中にいつまでも古いルーティング情報を失うことができるということです。 この無くなっている情報は呼び出しが「再-狙」う要素が局所的に定義されて、アプリケーション特有の方法で呼び出しを処理できる重要な歴史であるかもしれません。 このドキュメントにおける提案は要求歴史を輸送するのにメカニズムを提供することです。 それは情報を受け取り次第ProxyかUAのために少しのアプリケーション特異的行動も提案していません。 本当に、そのような振舞いは受取人アプリケーションのためのローカルの決定であるべきです。
Current network applications provide the ability for elements involved with the call to exchange additional information relating to how and why the call was routed to a particular destination. The following are examples of such applications:
現在のネットワーク応用は呼び出しが特定の目的地に発送されたどのように、理由に関連する追加情報を交換するという要求に伴われる要素に能力を供給します。 ↓これはそのようなアプリケーションに関する例です:
Barnes Standards Track [Page 3] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[3ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
1. Web "referral" applications, whereby an application residing
within a web server determines that a visitor to a website has
arrived at the site via an "associate" site that will receive some
"referral" commission for generating this traffic
1. ウェブ「紹介」アプリケーション。(ウェブサーバーの中にあるアプリケーションは、ウェブサイトへの訪問者がこのトラフィックを生成するために何らかの「紹介」コミッションを受け取る「副」のサイトを通してサイトに到着したことをそのアプリケーションで決定します)。
2. Email forwarding whereby the forwarded-to user obtains a "history"
of who sent the email to whom and at what time
2. 転送しているユーザがだれがだれと何時にメールを送ったかに関する「歴史」を得るメール推進
3. Traditional telephony services such as voicemail, call-center
"automatic call distribution", and "follow-me" style services
3. そして、伝統的な電話がボイスメール、コールセンターなどのように「自動呼び出し分配」を修理する、「私に続く、」 スタイルサービス
Several of the aforementioned applications currently define application-specific mechanisms through which it is possible to obtain the necessary history information.
いくつかの前述のアプリケーションが現在、必要な履歴情報を得るのが可能であるアプリケーション特有のメカニズムを定義します。
In addition, request history information could be used to enhance basic SIP functionality by providing the following:
さらに、以下を提供することによって基本のSIPの機能性を高めるのに履歴情報を使用できたよう要求してください:
o Some diagnostic information for debugging SIP requests. (Note that
the diagnostic utility of this mechanism is limited by the fact
that its use by entities that retarget is optional.)
o デバッグSIP要求のための何らかの診断情報。 (「再-狙」う実体による使用が任意であるという事実によってこのメカニズムの診断ユーティリティが制限されることに注意してください。)
o A stronger security solution for SIP. A side effect is that each
proxy that captures the "request history" information in a secure
manner provides an additional means (without requiring signed keys)
for the original requestor to be assured that the request was
properly retargeted.
o SIPには、より強いセキュリティソリューション。 副作用は安全な方法で「要求歴史」が情報であるとキャプチャする各プロキシがオリジナルの要請者が要求が適切に「再-狙」ったと確信する追加手段(キーであると署名される必要のない)を提供するということです。
2. "Request History" Requirements
2. 「要求歴史」要件
The following list constitutes a set of requirements for a "Request History" capability.
以下のリストは「要求歴史」能力のための1セットの要件を構成します。
1) CAPABILITY-req: The "Request History" capability provides a
capability to inform proxies and UAs involved in processing a
request about the history/progress of that request. Although this
is inherently provided when the retarget is in response to a SIP
redirect, it is deemed useful for non-redirect retargeting
scenarios, as well.
1) 能力-req: 「要求歴史」能力はその要求の歴史/進歩に関する要求を処理するのにかかわるプロキシとUAsに知らせる能力を提供します。 「再-目標」が本来a SIP再直接に対応しているとき、これを提供しますが、また、非再直接の「再-狙」いシナリオの役に立つとそれを考えます。
2) OPTIONALITY-req: The "Request History" information is optional.
2) OPTIONALITY-req: 「要求歴史」情報は任意です。
2.1) In many cases, it is anticipated that whether the history is
added to the Request would be a local policy decision
enforced by the specific application; thus, no specific
protocol element is needed.
2.1) 多くの場合、歴史がRequestに加えられるかどうかが、特定のアプリケーションによって励行されるローカルの政策決定であると予期されます。 したがって、どんな特定のプロトコル要素も必要ではありません。
Barnes Standards Track [Page 4] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[4ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
2.2) Due to the capability being "optional" from the SIP protocol
perspective, the impact to an application of not having the
"Request History" must be described. Applicability
guidelines to be addressed by applications using this
capability must be provided as part of the solution to these
requirements.
2.2) SIPプロトコル見解から「任意」の能力のために、影響は「要求歴史」を持たないアプリケーションに説明されなければなりません。 ソリューションの一部としてこの能力を使用するアプリケーションで扱われる適用性ガイドラインをこれらの要件に提供しなければなりません。
3) GENERATION-req: "Request History" information is generated when
the request is retargeted.
3) 世代-req: 要求がいつ「再-狙」うかという「要求歴史」情報は発生しています。
3.1) In some scenarios, it might be possible for more than one
instance of retargeting to occur within the same Proxy. A
proxy should also generate Request History information for
the 'internal retargeting'.
3.1) いくつかのシナリオでは、「再-狙」いの1つ以上のインスタンスが同じProxyの中に起こるのは、可能であるかもしれません。 また、プロキシは、Request歴史が'内部の「再-狙」い'のための情報であると生成するべきです。
3.2) An entity (UA or proxy) retargeting in response to a redirect
or REFER should include any Request History information from
the redirect/REFER in the new request.
3.2) aに対応して再直接で「再-狙」う実体(UAかプロキシ)かREFERが新しい要求における再直接の/REFERからのどんなRequest歴史情報も含んでいるはずです。
4) ISSUER-req: "Request History" information can be generated by a UA
or proxy. It can be passed in both requests and responses.
4) 発行人-req: UAかプロキシが「要求歴史」情報を生成することができます。 要求と応答の両方でそれを通過できます。
5) CONTENT-req: The "Request History" information for each
occurrence of retargeting shall include the following:
5) 満足しているreq: 「再-狙」いの各発生のための「要求歴史」情報は以下を含んでいるものとします:
5.1) The new URI or address to which the request is in the process
of being retargeted,
5.1) 要求があることの途中にある新しいURIかアドレスが「再-狙」いました。
5.2) The URI or address from which the request was retargeted,
5.2) URIかアドレスが要求がどれであったかから「再-狙」いました。
5.3) The reason for the Request-URI or address modification,
5.3) Request-URIかアドレス変更の理由
5.4) Chronological ordering of the Request History information.
5.4) Request歴史情報の年代順の注文。
6) REQUEST-VALIDITY-req: Request History is applicable to requests
not sent within an established dialog (e.g., INVITE, REGISTER,
MESSAGE, and OPTIONS).
6) 要求正当性req: 歴史が確立した対話(例えば、INVITE、REGISTER、MESSAGE、およびOPTIONS)の中で送られなかった要求に適切であるよう要求してください。
7) BACKWARDS-req: Request History information may be passed from the
generating entity backwards towards the UAC. This is needed to
enable services that inform the calling party about the dialog
establishment attempts.
7) 遅れているreq: 歴史情報が生成する実体よりUACに向かって後方に移られるかもしれないよう要求してください。 これが、対話設立試みに関して起呼側に知らせるサービスを可能にするのに必要です。
8) FORWARDS-req: Request History information may also be included by
the generating entity in the request, if it is forwarded onwards.
8) フォワード-req: また、前方へそれを進めるなら要求に生成する実体で歴史情報を含むかもしれないよう要求してください。
Barnes Standards Track [Page 5] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[5ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
2.1. Security Requirements
2.1. セキュリティ要件
The Request History information is being inserted by a network element retargeting a Request, resulting in a slightly different problem than the basic SIP header problem, thus requiring specific consideration. It is recognized that these security requirements can be generalized to a basic requirement of being able to secure information that is inserted by proxies.
Request歴史情報はRequestを「再-狙」うネットワーク要素によって挿入されています、わずかに異なった問題をもたらして基本的なSIPヘッダー問題より、その結果、特定の考慮を必要とします。 できるのがプロキシによって挿入される情報を保証するという基本的な要件にこれらのセキュリティ要件を一般化できると認められます。
The potential security problems include the following:
潜在的警備上の問題は以下を含んでいます:
1) A rogue application could insert a bogus Request History entry
either by adding an additional entry as a result of retargeting or
entering invalid information.
1) 凶暴なアプリケーションは、無効の情報を「再-狙」うか、または入力することの結果、追加エントリーを加えることによって、にせのRequest歴史エントリーを挿入するかもしれません。
2) A rogue application could re-arrange the Request History
information to change the nature of the end application or to
mislead the receiver of the information.
2) 凶暴なアプリケーションは、エンドアプリケーションの本質を変えるか、または情報の受信機をミスリードするためにRequest歴史情報を再配列するかもしれません。
3) A rogue application could delete some or all of the Request
History information.
3) 凶暴なアプリケーションはRequest歴史情報のいくつかかすべてを削除するかもしれません。
Thus, a security solution for "Request History" must meet the following requirements:
したがって、「要求歴史」のためのセキュリティソリューションは以下の必要条件を満たさなければなりません:
1) SEC-req-1: The entity receiving the Request History must be able
to determine whether any of the previously added Request History
content has been altered.
1) SEC-req-1: Request歴史を受け取る実体は、以前に付記されたRequest歴史内容のどれかが変更されたかどうか決定できなければなりません。
2) SEC-req-2: The ordering of the Request History information must be
preserved at each instance of retargeting.
2) SEC-req-2: 「再-狙」いの各インスタンスでRequest歴史情報の注文を保存しなければなりません。
3) SEC-req-3: The entity receiving the information conveyed by the
Request History must be able to authenticate the entity providing
the request.
3) SEC-req-3: 知らせを聞くのがRequest歴史で伝えた実体は要求を提供する実体を認証できなければなりません。
4) SEC-req-4: To ensure the confidentiality of the Request History
information, only entities that process the request should have
visibility to the information.
4) SEC-req-4: Request歴史情報の秘密性を確実にするために、要求を処理する実体だけが情報に目に見えることを持つべきです。
It should be noted that these security requirements apply to any entity making use of the Request History information, either by retargeting and capturing the information, or as an application making use of the information received in either a Request or Response.
情報を「再-狙」って、得のどちらかによってRequest歴史情報を利用するどんな実体、または情報を利用するアプリケーションがRequestかResponseのどちらかで受信されたのでも、これらのセキュリティ要件が適用されるのが有名であるべきです。
Barnes Standards Track [Page 6] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[6ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
2.2. Privacy Requirements
2.2. プライバシー要件
Since the Request-URI that is captured could inadvertently reveal information about the originator, there are general privacy requirements that MUST be met:
捕らわれているRequest-URIがうっかり創始者の情報を明らかにするかもしれないので、満たさなければならない一般的なプライバシー必要条件があります:
1) PRIV-req-1: The entity retargeting the Request must ensure that it
maintains the network-provided privacy (as described in [RFC3323])
associated with the Request as it is retargeted.
1) PRIV-req-1: Requestを「再-狙」う実体は、「再-狙」うときネットワークによって提供されたプライバシー([RFC3323]で説明されるように)をRequestに関連しているのに維持するのを確実にしなければなりません。
2) PRIV-req-2: The entity receiving the Request History must maintain
the privacy associated with the information.
2) PRIV-req-2: Request歴史を受け取る実体は情報に関連しているのにプライバシーを維持しなければなりません。
In addition, local policy at a proxy may identify privacy
requirements associated with the Request-URI being captured in the
Request History information.
さらに、プロキシのローカルの方針はRequest歴史情報で得るRequest-URIに関連しているプライバシー要件を特定するかもしれません。
3) PRIV-req-3: Request History information subject to privacy
requirements shall not be included in outgoing messages unless it
is protected as described in [RFC3323].
3) PRIV-req-3: それが[RFC3323]で説明されるように保護されないと送信されるメッセージにプライバシー要件を条件とした歴史情報を含まないよう要求してください。
3. Request History Information Description
3. 履歴情報記述を要求してください。
The fundamental functionality provided by the request history information is the ability to inform proxies and UAs involved in processing a request about the history or progress of that request (CAPABILITY-req). The solution is to capture the Request-URIs as a request is forwarded in a new header for SIP messages: History-Info (CONTENT-req). This allows for the capturing of the history of a request that would be lost with the normal SIP processing involved in the subsequent forwarding of the request. This solution proposes no changes in the fundamental determination of request targets or in the request forwarding as defined in Sections 16.5 and 16.6 of the SIP protocol specification [RFC3261].
要求履歴情報によって提供された基本的な機能性はプロキシに知らせる能力です、そして、UAsはその要求(CAPABILITY-req)の歴史か進歩に関する要求に処理にかかわりました。 ソリューションはSIPメッセージのために新しいヘッダーで要求を転送するときRequest-URIを得ることです: 歴史インフォメーション(内容-req)。 これは要求のその後の推進にかかわる通常のSIP処理に失われている要求の歴史をキャプチャすることを考慮します。 このソリューションはSIPプロトコル仕様[RFC3261]のセクション16.5と16.6で定義されるように要求目標の基本的な決断か要求推進における変化を全く提案しません。
The History-Info header can appear in any request not associated with an established dialog (e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH and SUBSCRIBE, etc.) (REQUEST-VALIDITY-req) and any valid response to these requests (ISSUER-req).
歴史インフォメーションヘッダーは確立した対話(登録、例えば、INVITE、REGISTER、MESSAGE、REFER、OPTIONS、PUBLISH、など)に関連づけられなかったどんな要求にも現れることができます。 (正当性reqを要求してください) そして、これらへのどんな有効回答も(ISSUER-req)を要求します。
The History-Info header is added to a Request when a new request is created by a UAC or forwarded by a Proxy, or when the target of a request is changed. The term 'retarget' is introduced to refer to this changing of the target of a request and the subsequent forwarding of that request. It should be noted that retargeting only occurs when the Request-URI indicates a domain for which the processing entity is responsible. In terms of the SIP protocol, the processing associated with retargeting is described in Sections 16.5
新しい要求をUACが作成するか、Proxyが転送する、または要求の目標を変えるとき、歴史インフォメーションヘッダーをRequestに加えます。 '「再-目標」'という用語は、要求の目標とその要求のその後の推進のこの変化について言及するために紹介されます。 Request-URIが処理実体が原因となるドメインを示すときだけ、「再-狙」いが起こることに注意されるべきです。 SIPプロトコルで、「再-狙」いに関連している処理はセクション16.5で説明されます。
Barnes Standards Track [Page 7] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[7ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
and 16.6 of [RFC3261]. As described in Section 16.5 of [RFC3261], it is possible for the target of a request to be changed by the same proxy multiple times (referred to as 'internal retargeting' in Section 2), as the proxy MAY add targets to the target set after beginning Request Forwarding. Section 16.6 of [RFC3261] describes Request Forwarding. It is during this process of Request Forwarding that the History Information is captured as an optional, additional header field. Thus, the addition of the History-Info header does not impact fundamental SIP Request Forwarding. An entity (UA or proxy) changing the target of a request in response to a redirect or REFER SHOULD also propagate any History-Info header from the initial Request in the new request (GENERATION-req, FORWARDS-req).
そして、16.6[RFC3261。] [RFC3261]のセクション16.5で説明されるように、複数の回(セクション2に'内部の「再-狙」い'と呼ばれる)同じプロキシによって変えられるという要求の目標に、それは可能です、プロキシが、Request Forwardingを始めた後に目標への目標がセットしたと言い足すとき。 [RFC3261]のセクション16.6はRequest Forwardingについて説明します。 Request Forwardingのこのプロセスの間、任意の、そして、追加しているヘッダーフィールドとして歴史情報を得ます。 したがって、歴史インフォメーションヘッダーの追加は基本的なSIP Request Forwardingに影響を与えません。 また、aに対応して再直接で要求の目標を変える実体(UAかプロキシ)かREFER SHOULDが新しい要求(GENERATION-req、FORWARDS-req)で初期のRequestからどんな歴史インフォメーションヘッダーも伝播します。
3.1. Optionality of History-Info
3.1. 歴史インフォメーションのOptionality
The History-Info header is optional in that neither UAs nor Proxies are required to support it. A new Supported header, "histinfo", is included in the Request to indicate whether the History-Info header is returned in Responses (BACKWARDS-req). In addition to the "histinfo" Supported header, local policy determines whether or not the header is added to any request, or for a specific Request-URI, being retargeted. It is possible that this could restrict the applicability of services that make use of the Request History Information to be limited to retargeting within domain(s) controlled by the same local policy, or between domain(s) which negotiate policies with other domains to ensure support of the given policy, or services for which complete History Information isn't required to provide the service (OPTIONALITY-req). All applications making use of the History-Info header MUST clearly define the impact of the information not being available and specify the processing of such a request.
UAsもProxiesもそれをサポートする必要はないので、歴史インフォメーションヘッダーは任意です。 新しいSupportedヘッダー"histinfo"は、歴史インフォメーションヘッダーがResponses(BACKWARDS-req)で返されるかどうかを示すためにRequestに含まれています。 "histinfo"Supportedヘッダーに加えて、ローカルの方針は、ヘッダーが何か要求、または「再-狙」う特定のRequest-URIのために加えられるかどうか決定します。 これが同じローカルの方針で制御されたドメインの中で「再-狙」うのに制限されるのにRequest歴史情報を利用するサービスの適用性を制限するかもしれないのが、可能であるか、またはドメインの間では、どれが与えられた方針のサポートを確実にするために他のドメインと方針を交渉するか、そして、完全な歴史情報がそうでないサービスがサービス(OPTIONALITY-req)を提供するのが必要です。 歴史インフォメーションヘッダーを利用するすべてのアプリケーションが、明確に利用可能でない情報の影響を定義して、そのような要求の処理を指定しなければなりません。
3.2. Securing History-Info
3.2. 歴史インフォメーションを保証します。
This document defines a new header for SIP. The use of the Transport Layer Security (TLS) protocol [RFC2246] as a mandatory mechanism to ensure the overall confidentiality of the History-Info headers (SEC- req-4) is strongly RECOMMENDED. This results in History-Info having at least the same level of security as other headers in SIP that are inserted by intermediaries. If TLS is not available for the connection over which the request is being forwarded, then the request MUST NOT include the History-Info header or the request MUST be redirected to the client, including the History-Info header, so that the request can be retargeted by the client.
このドキュメントはSIPのために新しいヘッダーを定義します。 Transport Layer Security(TLS)の使用は、歴史インフォメーションヘッダー(SEC req-4)の総合的な秘密性が強くそうであることを保証するために義務的なメカニズムとして[RFC2246]について議定書の中で述べます。RECOMMENDED。 これは、仲介者によって挿入されるSIPに少なくとも同じレベルのセキュリティを他のヘッダーに持ちながら、歴史インフォメーションをもたらします。 TLSが要求が転送されている接続に利用可能でないなら、要求が歴史インフォメーションヘッダーを含んではいけませんか、またはクライアントに要求を向け直さなければなりません、歴史インフォメーションヘッダーを含んでいて、クライアントが要求を「再-狙」うことができるように。
With the level of security provided by TLS (SEC-req-3), the information in the History-Info header can thus be evaluated to determine if information has been removed by evaluating the indices
セキュリティのレベルがTLS(SEC-req-3)によって提供されている状態で、その結果、インデックスリストを評価することによって情報を取り除いてあるかどうか決定するために歴史インフォメーションヘッダーの情報を評価できます。
Barnes Standards Track [Page 8] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[8ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
for gaps (SEC-req-1, SEC-req-2). It would be up to the application to define whether it can make use of the information in the case of missing entries.
ギャップ(SEC-req-1、SEC-req-2)に。 それがなくなったエントリーの場合で情報を利用できるかどうかを定義するのがアプリケーションまで達しているでしょう。
Note that while using the SIPS scheme protects History-Info from tampering by arbitrary parties outside the SIP message path, all the intermediaries on the path are trusted implicitly. A malicious intermediary could arbitrarily delete, rewrite, or modify History- Info. This specification does not attempt to prevent or detect attacks by malicious intermediaries.
SIPS体系を使用している間にSIPメッセージ経路の外の任意のパーティーでいじるのから歴史インフォメーションを保護する注意、経路のすべての仲介者がそれとなく信じられます。 悪意がある仲介者は、任意に歴史インフォメーションを削除するか、書き直すか、または変更できました。 この仕様は、悪意がある仲介者による攻撃を防ぐか、または検出するのを試みません。
3.3. Ensuring the Privacy of History-Info
3.3. 歴史インフォメーションのプライバシーを確実にします。
Since the History-Info header can inadvertently reveal information about the requestor as described in [RFC3323], the Privacy header SHOULD be used to determine whether an intermediary can include the History-Info header in a Request that it receives and forwards (PRIV-req-2) or that it retargets (PRIV-req-1). Thus, the History- Info header SHOULD NOT be included in Requests where the requestor has indicated a priv-value of Session- or Header-level privacy.
歴史インフォメーションヘッダーがうっかり情報を明らかにすることができるので、[RFC3323]、PrivacyヘッダーSHOULDで説明される要請者に関して使用されて、仲介者が(PRIV-req-2)を受けて、進めるか、またはそれが「再-狙」うRequest(PRIV-req-1)で歴史インフォメーションヘッダーを入れることができるかどうか決定してください。 したがって、歴史インフォメーションヘッダーSHOULD NOTは要請者がSessionのpriv値を示したRequestsに含まれているか、またはプライバシーをHeader平らにします。
In addition, the History-Info header can reveal general routing information, which may be viewed by a specific intermediary or network, to be subject to privacy restrictions. Thus, local policy MAY also be used to determine whether to include the History-Info header at all, whether to capture a specific Request-URI in the header, or whether it be included only in the Request as it is retargeted within a specific domain (PRIV-req-3). In the latter case, this is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating whether any or a specific History-Info header(s) SHOULD be forwarded.
さらに、歴史インフォメーションヘッダーは、一般的なルーティング情報がプライバシー制限を受けることがあるのを明らかにすることができます。(情報は特定の仲介者かネットワークによって見られるかもしれません)。 したがって、また、ヘッダーの捕獲のa特定のRequest-URIにか否かに関係なく、ローカルの方針が全く歴史インフォメーションヘッダーを含んでいるかどうか決定するのに使用されたかもしれませんか、またはそれがあるとき、それが含まれているか否かに関係なく、Requestは特定のドメイン(PRIV-req-3)の中で中だけでは、「再-狙」いました。 後者の場合では、これは新しいpriv-価値を高めることによって、達成されます、歴史、いずれか特定の歴史インフォメーションヘッダーSHOULDであることにかかわらず進められるように示すPrivacyヘッダー[RFC3323]に。
It is recognized that satisfying the privacy requirements can impact the functionality of this solution by overriding the request to generate the information. As with the optionality and security requirements, applications making use of History-Info SHOULD address any impact this may have or MUST explain why it does not impact the application.
プライバシー要件を満たすと情報を生成するという要求に優越することによってこのソリューションの機能性に影響を与えることができると認められます。 optionalityとセキュリティ要件なら、歴史インフォメーションSHOULDを利用するアプリケーションで、これが持っているどんな影響力も扱わなければならないか、またはそれがなぜアプリケーションに影響を与えないかがわからなければなりません。
4. Request History Information Protocol Details
4. 履歴情報プロトコルの詳細を要求してください。
This section contains the details and usage of the proposed new SIP protocol elements. It also discusses the security aspects of the solution.
このセクションは提案された新しいSIPプロトコル要素の詳細と使用法を含みます。 また、それはソリューションのセキュリティ局面について議論します。
Barnes Standards Track [Page 9] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[9ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
4.1. Protocol Structure of History-Info
4.1. 歴史インフォメーションのプロトコル構造
History-Info is a header field as defined by [RFC3261]. It is an optional header field and MAY appear in any request or response not associated with a dialog or which starts a dialog. For example, History-Info MAY appear in INVITE, REGISTER, MESSAGE, REFER, OPTIONS, SUBSCRIBE, and PUBLISH and any valid responses, plus NOTIFY requests that initiate a dialog.
[RFC3261]によって定義されるように歴史インフォメーションはヘッダーフィールドです。 それは、任意のヘッダーフィールドであり、対話を始める対話に関連づけられなかった少しの要求や応答にも現れるかもしれません。 例えば、歴史インフォメーションはINVITEに現れるかもしれません、REGISTER、MESSAGE、REFER、OPTIONS、登録、そして、PUBLISHとどんな有効回答、プラスNOTIFYもそれを要求します。対話を開始してください。
This document adds the following entry to Table 2 of [RFC3261]. The additions to this table are also provided for extension methods at the time of publication of this document. This is provided as a courtesy to the reader and is not normative in any way.
このドキュメントは[RFC3261]のTable2に以下のエントリーを加えます。 また、このドキュメントの公表時点で、このテーブルへの追加を拡大メソッドに提供します。 これは、礼儀として読者に提供されて、何らかの方法で規範的ではありません。
Header field where proxy ACK BYE CAN INV OPT REG MSG
------------ ----- ----- --- --- --- --- --- --- ---
History-Info amdr - - - o o o o
ヘッダーフィールドどこプロキシACK BYE CAN INV OPT REG MSG------------ ----- ----- --- --- --- --- --- --- --- 歴史インフォメーションamdr--、--、--、o o o o
SUB NOT REF INF UPD PRA PUB
--- --- --- --- --- --- ---
History-Info amdr o o o - - - o
審判INF UPD PRAパブではなく、潜水艦--- --- --- --- --- --- --- 歴史インフォメーションamdr o o o--、--、--、o
The History-Info header carries the following information, with the mandatory parameters required when the header is included in a request or response:
歴史インフォメーションヘッダーは以下の情報を運びます、ヘッダーが要求か応答に含まれているとき必要である義務的なパラメタで:
o Targeted-to-URI (hi-targeted-to-uri): A mandatory parameter for
capturing the Request-URI for the specific Request as it is
forwarded.
o URIに狙いにされる(uriに高狙っている): 特定のRequestのためにそれとしてRequest-URIを得るための義務的なパラメタを転送します。
o Index (hi-index): A mandatory parameter for History-Info
reflecting the chronological order of the information, indexed to
also reflect the forking and nesting of requests. The format for
this parameter is a string of digits, separated by dots to
indicate the number of forward hops and retargets. This results
in a tree representation of the history of the request, with the
lowest-level index reflecting a branch of the tree. By adding
the new entries in order (i.e., following existing entries per
the details in Section 4.3.3.1), including the index and securing
the header, the ordering of the History-Info headers in the
request is assured (SEC-req-2). In addition, applications may
extract a variety of metrics (total number of retargets, total
number of retargets from a specific branch, etc.) based upon the
index values.
o (高インデックス)に索引をつけてください: また、要求の分岐と巣篭もりを反映するために索引をつけられた情報の年代順を反映する歴史インフォメーションのための義務的なパラメタ。 このパラメタのための形式はドットによって切り離された、早稲のホップと「再-目標」の数を示した一連のケタです。 これは要求の歴史の木の表現をもたらします、最も低いレベルインデックスが木の枝を反映していて。 整然とした状態で(すなわち、1詳細あたりの既存のエントリーに、セクション4.3.3で.1に続きます)新しいエントリーを加えて、インデックスを含んで、ヘッダーを固定することによって、(SEC-req-2)は要求における、歴史インフォメーションヘッダーの注文に保証されます。 さらに、アプリケーションはインデックス値に基づくさまざまな測定基準(「再-目標」の総数、特定のブランチからの「再-目標」の総数など)を抜粋するかもしれません。
o Reason: An optional parameter for History-Info, reflected in the
History-Info header by including the Reason Header [RFC3326]
escaped in the hi-targeted-to-uri. A reason is not included for
o 理由: uriに高狙いにされるので逃げられたReason Header[RFC3326]を含んでいることによって歴史インフォメーションヘッダーに反映された歴史インフォメーションのための任意のパラメタ。 理由は含まれていません。
Barnes Standards Track [Page 10] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[10ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
a hi-targeted-to-uri when it is first added in a History-Info
header, but rather is added when the retargeting actually occurs.
Note that this does appear to complicate the security problem;
however, retargeting only occurs when the hi-targeted-to-uri
indicates a domain for which the processing entity is
responsible. Thus, it would be the same processing entity that
initially added the hi-targeted-to-URI to the header that would
be updating it with the Reason.
それが最初に歴史インフォメーションヘッダーで加えられますが、「再-狙」いが実際に起こるときむしろ加えられると、uriに高狙います。 これが警備上の問題を複雑にするように見えることに注意してください。 しかしながら、uriへの高狙いにされるのが処理実体が原因となるドメインを示すときだけ、「再-狙」いは起こります。 したがって、Reasonと共にそれをアップデートするのは、初めはURIへの高狙いにされるのをヘッダーに加えた同じ処理実体でしょう。
o Privacy: An optional parameter for History-Info, reflected in the
History-Info header field values by including the Privacy Header
[RFC3323] with a priv-value of "history" escaped in the hi-
targeted-to-uri or by adding the Privacy header with a priv-value
of "history" to the Request. The use of the Privacy Header with
a priv-value of "history" indicates whether a specific or all
History-Info headers should not be forwarded.
o プライバシー: uriに高狙いにされるので逃げられる「歴史」のpriv-値かRequestへの「歴史」のpriv-値でPrivacyヘッダーを加えることによってPrivacy Header[RFC3323]を含んでいることによって歴史インフォメーションヘッダーフィールド値に反映された歴史インフォメーションのための任意のパラメタ。 「歴史」のpriv-値があるPrivacy Headerの使用は、詳細かすべての歴史インフォメーションヘッダーが進められるべきであるというわけではないかどうかを示します。
o Extension (hi-extension): An optional parameter to allow for
future optional extensions. As per [RFC3261], any implementation
not understanding an extension should ignore it.
o 拡大(高拡大): 今後の任意の拡大のために許容する任意のパラメタ。 [RFC3261]に従って、拡大を理解していないどんな実現もそれを無視するべきです。
The following summarizes the syntax of the History-Info header, based upon the standard SIP syntax [RFC3261]:
以下は標準のSIP構文[RFC3261]に基づく歴史インフォメーションヘッダーの構文をまとめます:
History-Info = "History-Info" HCOLON
hi-entry *(COMMA hi-entry)
歴史インフォメーションは「歴史インフォメーション」HCOLON高エントリー*と等しいです。(COMMA高エントリー)
hi-entry = hi-targeted-to-uri *( SEMI hi-param )
高エントリーはuriに狙われる高*と等しいです。(SEMI高param)
hi-targeted-to-uri= name-addr
高、-狙って、uriに、=は名前でaddrされます。
hi-param = hi-index / hi-extension
高paramは高高インデックス/拡大と等しいです。
hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT)
高インデックス=「インデックス」EQUAL1*DIGIT*(ドット1*ケタ)
hi-extension = generic-param
高拡大はジェネリック-paramと等しいです。
4.2. Protocol Examples
4.2. プロトコルの例
The following provides some examples of the History-Info header. Note that the backslash and CRLF between the fields in the examples below are for readability purposes only.
以下は歴史インフォメーションヘッダーに関するいくつかの例を提供します。 以下の例の分野の間のバックスラッシュとCRLFが読み易さ目的だけのためのものであることに注意してください。
History-Info:<sip:UserA@ims.example.com?Reason=SIP%3B\
cause%3D302>;index=1;foo=bar
歴史インフォメーション: <一口: UserA@ims.example.com?Reason は3B\原因%3D302>; インデックス=1; %foo=が禁じる一口と等しいです。
History-Info: <sip:UserA@ims.example.com?Reason=SIP%3B \
cause%3D302>; index=1.1,
歴史インフォメーション: <一口: 一口 UserA@ims.example.com?Reason =%3B\原因%3D302>。 =1.1に索引をつけてください。
Barnes Standards Track [Page 11] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[11ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
<sip:UserB@example.com?Privacy=history&Reason=SIP%3B\
cause%3D486>;index=1.2,
<sip:45432@vm.example.com>;index=1.3
<一口: UserB@example.com?Privacy =歴史と理由=は%3B\原因%3D486>をちびちび飲みます; <一口: =1.2、 45432@vm.example.com に索引をつけてください、gt;、;=1.3に索引をつけてください
4.3. Protocol Usage
4.3. プロトコル用法
This section describes the processing specific to UAs and Proxies for the History-Info header, the "histinfo" option tag, and the priv- value of "history". As discussed in Section 1.3, the fundamental objective is to capture the target Request-URIs as a request is forwarded. This allows for the capturing of the history of a request that would be lost due to subsequent (re)targeting and forwarding. To accomplish this for the entire history of a request, either the UAC must capture the Request-URI in a History-Info header in the initial request or a proxy must add a History-Info header with both a hi-entry for the Request-URI in the initial request and a hi-entry for the target Request-URI as the request is forwarded. The basic processing is for each entity forwarding a request to add a hi-entry for the target Request-URI, updating the index and adding the Reason as appropriate for any retargeted Request-URI.
このセクションは歴史インフォメーションヘッダー、"histinfo"オプションタグ、および「歴史」のpriv値に、UAsとProxiesに特定の処理について説明します。 セクション1.3で議論するように、基本的な目的は要求を転送するとき目標Request-URIを得ることです。 これはその後の(re)の狙いのため失われている要求と推進の歴史を捕らえることを考慮します。 要求の全体の歴史のためにこれを達成するために、UACが初期の要求における歴史インフォメーションヘッダーでRequest-URIを得なければなりませんか、または要求を転送するとき、プロキシは初期の要求におけるRequest-URIのための高エントリーと目標Request-URIのための高エントリーの両方で歴史インフォメーションヘッダーを加えなければなりません。 基本的な処理は目標Request-URIのための高エントリーを加えるという要求を転送する各実体のためのものです、どんなretargeted Request-URIのためにもインデックスをアップデートして、適宜Reasonを加えて。
4.3.1. User Agent Client (UAC) Behavior
4.3.1. ユーザエージェントのクライアント(UAC)の振舞い
The UAC SHOULD include the "histinfo" option tag in the Supported header in any request not associated with an established dialog for which the UAC would like the History-Info header in the response. In addition, the UAC MAY improve the diagnostic utility of its request by adding a History-Info header, using the Request-URI of the request as the hi-target-to-uri and initializing the index to the RECOMMENDED value of 1 in the hi-entry. As a result, intermediaries and the UAS will know at least the original Request-URI, and if the Request-URI was modified by a previous hop.
UAC SHOULDはUACが応答で歴史インフォメーションヘッダーが欲しい確立した対話に関連づけられなかったどんな要求でもSupportedヘッダーに"histinfo"オプションタグを含んでいます。 さらに、UAC MAYは歴史インフォメーションヘッダーを加えることによって、要求の診断ユーティリティを改良します、uriへの高目標として要求のRequest-URIを使用して、高エントリーにおける、1のRECOMMENDED値にインデックスを初期化して。 その結果、仲介者とUASは、少なくともオリジナルのRequest-URIとRequest-URIが前のホップによって変更されたかどうかを知るでしょう。
In the case where the request is routed to a redirect server and the UAC receives a 3xx response with a Contact header, the UAC MAY maintain the previous hi-entry(s) in the request. In this case, the reason header SHOULD be associated with the hi-targeted-to-uri in the previous (last) hi-entry, as described in Section 4.3.3.1.2. A new hi-entry MAY then be added for the URI from the Contact header (which becomes the new Request-URI). In this case, the index is created by reading and incrementing the value of the index from the previous hi-entry, thus following the same rules as those prescribed for a proxy in retargeting, described in Section 4.3.3.1.3. An example of this scenario can be found in Appendix D.
要求が再直接のサーバに発送されて、UACがContactヘッダーと共に3xx応答を受ける場合では、UAC MAYは要求における前の高エントリーを維持します。 この場合、関連セクション4.3.3における説明されるとしてのuriに前で高狙いにされる(最終)による高エントリーの.1が.2であったならヘッダーSHOULDを推論してください。 そして、新しい高エントリーはURIのためにContactヘッダー(新しいRequest-URIになる)から加えられるかもしれません。 この場合、インデックスは読書することによって、作成されました、そして、前の高エントリーからインデックスの値を増加して、その結果、「再-狙」いでプロキシに処方されたものと同じ規則に従う場合、セクション4.3.3では、.1は.3に説明されました。 Appendix Dでこのシナリオに関する例を見つけることができます。
A UAC that does not want the History-Info header added due to privacy considerations SHOULD include a Privacy header with a priv-value(s) of "session", "header", or "history" in the request.
歴史インフォメーションヘッダーが欲しくないUACは、プライバシーのため問題SHOULDが要求に「セッション」、「ヘッダー」、または「歴史」のpriv-値でPrivacyヘッダーを含んでいると言い足しました。
Barnes Standards Track [Page 12] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[12ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
With the exception of the processing of a 3xx response described above, the processing of the History-Info header received in the Response is application specific and outside the scope of this document. However, the validity of the information SHOULD be ensured prior to any application usage. For example, the entries MAY be evaluated to determine gaps in indices, which could indicate that an entry has been maliciously removed or removed for privacy reasons. Either way, an application MAY want to be aware of potentially missing information.
上で説明された3xx応答の処理を除いてアプリケーション特有であり、このドキュメントの範囲の外でResponseに受け取られた歴史インフォメーションヘッダーの処理。 しかしながら、正当性、情報SHOULDでは、どんなアプリケーション用法の前にも確実にされてください。 例えば、エントリーは、エントリーを陰湿に取り除くか、またはプライバシー理由で取り除いたのを示すことができたインデックスリストのギャップを決定するために評価されるかもしれません。 いずれにせよ、アプリケーションは潜在的になくなった情報を意識していたがっているかもしれません。
4.3.2. User Agent Server (UAS) Behavior
4.3.2. ユーザエージェントサーバ(UAS)の振舞い
The processing of the History-Info header by a UAS in a Request depends upon local policy and specific applications at the UAS that might make use of the information. Prior to any application usage of the information, the validity SHOULD be ascertained. For example, the entries MAY be evaluated to determine gaps in indices, which could indicate that an entry has been maliciously removed or removed for privacy reasons. Either way, an application MAY want to be aware of potentially missing information.
RequestのUASによる歴史インフォメーションヘッダーの処理は情報を利用するかもしれないUASでローカルの方針と特定のアプリケーションによります。 情報のどんなアプリケーション用法、正当性SHOULDの前、も確かめられてください。 例えば、エントリーは、エントリーを陰湿に取り除くか、またはプライバシー理由で取り除いたのを示すことができたインデックスリストのギャップを決定するために評価されるかもしれません。 いずれにせよ、アプリケーションは潜在的になくなった情報を意識していたがっているかもしれません。
If the "histinfo" option tag is received in a request, the UAS SHOULD include any History-Info received in the request in the subsequent response.
要求に"histinfo"オプションタグを受け取るなら、UAS SHOULDはその後の応答における要求に受け取られたどんな歴史インフォメーションも含んでいます。
4.3.3. Proxy Behavior
4.3.3. プロキシの振舞い
The inclusion of the History-Info header in a Request does not alter the fundamental processing of proxies for determining request targets as defined in Section 16.5 of [RFC3261]. Whether a proxy adds the History-Info header or a new hi-entry as it forwards a Request depends upon the following considerations:
Requestでの歴史インフォメーションヘッダーの包含は、[RFC3261]のセクション16.5で定義されるように要求目標を決定するためにプロキシの基本的な処理を変更しません。 Requestを進めるときプロキシが歴史インフォメーションヘッダーか新しい高エントリーを加えるかどうかが以下の問題によります:
1. Whether the Request contains the "histinfo" option tag in the
Supported header.
2. Whether the proxy supports the History-Info header.
3. Whether the Request contains a Privacy header with a priv-value
of "session", "header", or "history".
4. Whether any History-Info header added for a proxy/domain should
go outside that domain. An example being the use of the
History-Info header within the specific domain in which it is
retargeted, however, policies (for privacy, user and network
security, etc.) would prohibit the exposure of that information
outside that domain. To accommodate such a scenario, a proxy
MAY insert the Privacy header with a priv-value of "history"
when the request is being forwarded within the same domain. An
example of such an application is provided in Appendix C.
1. RequestはSupportedヘッダーに"histinfo"オプションタグを含むのであるかどうか 2. プロキシは歴史インフォメーションヘッダーを支えるのであるかどうか 3. Requestは「セッション」、「ヘッダー」、または「歴史」のpriv-値でPrivacyヘッダーを含むのであるかどうか 4. 何か歴史インフォメーションヘッダーがプロキシ/ドメインに加えたかどうかがそのドメインの外に行くべきです。 しかしながら、例がそれが「再-狙」う特定のドメインの中の歴史インフォメーションヘッダーの使用であるなら、方針(プライバシーとユーザとネットワークセキュリティなどのための)はそのドメインの外でその情報の露出を禁止するでしょう。 同じドメインの中で要求を転送しているとき、そのようなシナリオに対応するために、プロキシは「歴史」のpriv-値でPrivacyヘッダーを挿入するかもしれません。 そのようなアプリケーションに関する例をAppendix Cに提供します。
Barnes Standards Track [Page 13] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[13ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
5. Whether a hi-entry is added for a specific Request-URI due to
local privacy policy considerations. A proxy MAY add the
Privacy header with a priv-value of "history" associated with
the specific hi-targeted-to-uri.
5. 高エントリーはローカルのプライバシーに関する方針問題のため特定のRequest-URIのために加えられるのであるかどうか プロキシは特定に関連している「歴史」のpriv-値でuriに高狙った状態でPrivacyヘッダーを加えるかもしれません。
An example policy would be a proxy that only adds the History-Info header if the "histinfo" option tag is in the Supported header. Other proxies may have a policy that they always add the header, but never forward it outside a particular domain, accomplishing this by adding a Privacy header with a priv-value of "history" to each hi- entry to allow the information to be collected for internal retargeting only.
例の方針は"histinfo"オプションタグがSupportedヘッダーにある場合にだけ歴史インフォメーションヘッダーを加えるプロキシでしょう。 他のプロキシには、方針があるかもしれません。情報は許容するそれぞれの高エントリーへの「歴史」のpriv-値でPrivacyヘッダーを加えることによって、これを達成して、特定のドメインの外にそれを決して送らないのを除いて、彼らがいつもヘッダーを加えることの内部の「再-狙」いの寄付を募りました。
Each application making use of the History-Info header SHOULD address the impacts of the local policies on the specific application (e.g., what specification of local policy is optimally required for a specific application and any potential limitations imposed by local policy decisions).
歴史インフォメーションヘッダーSHOULDアドレスの使用を特定のアプリケーションへのローカルの方針の影響にする(例えば、ローカルの方針のどんな仕様がローカルの政策決定で課された特定のアプリケーションと何か潜在的制限に最適に必要ですか)各アプリケーション。
Consistent with basic SIP processing of optional headers, proxies SHOULD maintain the History-Info header(s), received in messages being forwarded, independent of whether local policy supports History-Info.
任意のヘッダーの基本的なSIP処理と一致しています、ローカルの方針が歴史インフォメーションを支持するかどうかの如何にかかわらずプロキシSHOULDは転送されるメッセージに受け取られた歴史インフォメーションヘッダーを維持します。
The specific processing by proxies for adding the History-Info headers in Requests and Responses, to accommodate the considerations outlined above, is described in detail in the following sections.
RequestsとResponsesで歴史インフォメーションヘッダーを加えるためのプロキシによる特定の処理は、上に概説された問題に対応するために以下のセクションで詳細に説明されます。
4.3.3.1. Adding the History-Info Header to Requests
4.3.3.1. 歴史インフォメーションヘッダーを要求に追加します。
Upon evaluation of the considerations under which the History-Info header is to be included in requests (e.g., no Privacy header overriding inclusion, local policy supports, etc.), detailed in Section 4.3.3, a proxy SHOULD add a hi-entry as it forwards a Request. Section 16.6 of [RFC3261] defines the steps to be followed as the proxy forwards a Request. Step 5 prescribes the addition of optional headers. Although this would seem the appropriate step for adding the History-Info header, the interaction with Step 6, "Postprocess routing information", and the impact of a strict route in the Route header could result in the Request-URI being changed; thus, adding the History-Info header between Steps 8 (adding Via header) and 9 (adding Content-Length) is RECOMMENDED. Note that in the case of loose routing, the Request-URI does not change during the forwarding of a Request; thus, the capturing of History-Info for such a request would result in duplicate Request-URIs with different indices. The hi-entry MUST be added following any hi-entry received in the request being forwarded. Additionally, if a request is received that doesn't include a History-Info header, the proxy MAY
歴史インフォメーションヘッダーが(例えば、包含をくつがえしていないどんなPrivacyヘッダー、地方の方針サポートなど)がセクション4.3.3、プロキシSHOULDで詳しく述べた要求に含まれることになっている問題の評価のときに、Requestを進めるとき、高エントリーを加えてください。 [RFC3261]のセクション16.6は、プロキシがRequestを進めるのに従って続かれるようにステップを定義します。 ステップ5は任意のヘッダーの追加を定めます。 これは歴史インフォメーションヘッダーを加えるための適切なステップに見えるでしょうが、Step6との相互作用、「ルーティング情報を後処理してください」、およびRouteヘッダーでの厳しいルートの影響は変えられるRequest-URIをもたらすかもしれません。 したがって、Steps8(Viaヘッダーを加えます)と9(Content-長さを加える)の間の歴史インフォメーションヘッダーを加えるのは、RECOMMENDEDです。 Requestの推進の間、ゆるいルーティングの場合では、Request-URIが変化しないことに注意してください。 したがって、そのような要求のための歴史インフォメーションを捕らえるのは異なったインデックスリストで写しRequest-URIをもたらすでしょう。 転送される要求で受けられたどんな高エントリーにも続いて、高エントリーを加えなければなりません。 さらに、要求が受信されているなら、それは歴史インフォメーションヘッダーを含まないで、プロキシは5月です。
Barnes Standards Track [Page 14] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[14ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
add a History-Info header with a hi-entry preceding the one being added for the current request being forwarded. The index for this hi-entry is RECOMMENDED to start at 1. The following subsections define the details of creating the information associated with each hi-entry.
転送される現在の要求のために加えられるものに先行しながら、高エントリーがある歴史インフォメーションヘッダーを加えてください。 この高エントリーへのインデックスは1時に始まるRECOMMENDEDです。 以下の小区分はそれぞれの高エントリーに関連づけられた情報を作成する詳細を定義します。
4.3.3.1.1. Privacy in the History-Info Header
4.3.3.1.1. 歴史インフォメーションヘッダーのプライバシー
If there is a Privacy header in the request with a priv-value of "session", "header", or "history", a hi-entry MAY be added, if the request is being forwarded to a Request-URI associated with a domain for which the processing entity is responsible (and provided local policy supports the History-Info header, etc.). If a request is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and there is a Privacy header in the request with a priv-value of "session", "header", or "history", the proxy SHOULD remove any hi-entry(s) prior to forwarding, depending upon local policy and whether the proxy might know a priori that it can rely on a downstream privacy service to apply the requested privacy.
要求にPrivacyヘッダーが「セッション」、「ヘッダー」、または「歴史」のpriv-値と共にあれば、高エントリーは加えられるかもしれません、処理実体が原因となる(そして、歴史インフォメーションヘッダーを地方の方針サポートに提供しますなど)ドメインに関連しているRequest-URIに要求を転送しているなら。 プロキシは責任がないドメインに関連しているRequest-URIに要求を転送していて、要求にPrivacyヘッダーが「セッション」、「ヘッダー」、または「歴史」のpriv-値と共にあれば、プロキシSHOULDは推進の前にどんな高エントリーも取り除きます、ローカルの方針とプロキシが、要求されたプライバシーを適用するために川下のプライバシーサービスに依存できるのを先験的に知るかもしれないかどうかによって。
For the scenario where there is no Privacy header in the request and the request is being forwarded to a Request-URI associated with the domain(s) for which this entity is responsible, there are several additional considerations:
要求にはPrivacyヘッダーが全くなくて、要求がこの実体が原因となるドメインに関連しているRequest-URIに転送されているシナリオのために、いくつかの追加問題があります:
o If there is no local policy associated with privacy, then a hi-
entry MAY be added to the Request.
o プライバシーに関連しているどんなローカルの方針もなければ、高エントリーはRequestに加えられるかもしれません。
o If the proxy's local policies, per consideration 4 in section
4.3.3, indicate that the History-Info header should not be
forwarded beyond the domain for which this intermediary is
responsible, then a Privacy header with a priv-value of "history"
SHOULD be associated with each hi-entry added by that proxy in
this scenario.
o プロキシのローカルの方針が、歴史インフォメーションヘッダーがこの仲介者は責任があるドメインを超えて進められるべきでないのをセクション4.3.3における考慮4単位で示すなら、「歴史」SHOULDのpriv-値がそれぞれの高エントリーに関連づけられている状態で、Privacyヘッダーはこのシナリオでそのプロキシで加えました。
o If the proxy's policy, per consideration 5 in Section 4.3.3,
indicates that History-Info for a specific Request-URI should not
be forwarded beyond the domain for which this intermediary is
responsible, then a Privacy header with a priv-value of "history"
SHOULD be associated with the specific hi-entry, for that
specific hi-targeted-to-uri, added by that proxy in this
scenario.
o プロキシの方針が、特定のRequest-URIのための歴史インフォメーションがそうするべきであるのをセクション4.3.3における考慮5単位で示すなら、次に、この仲介者は責任があるドメイン、「歴史」SHOULDのpriv-値が特定に関連づけられている高エントリーの、そして、それに、特定のPrivacyヘッダーを超えてuriに高狙った状態で進められないでください、このシナリオでそのプロキシによって加えられて。
If a request is being forwarded to a Request-URI associated with a domain for which the proxy is not responsible and local policy requires privacy associated with any, or with specific, hi-entries it
要求であるなら、プロキシは責任がなくて、ローカルの方針が何かに関連しているプライバシーを必要とするドメイン、または特定の高エントリーに関連しているRequest-URIに送るのは、それですか?
Barnes Standards Track [Page 15] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[15ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
has added, any hi-entry with a priv-value of "history" SHOULD be removed prior to forwarding.
推進の前に「歴史」SHOULDのpriv-値を取り除いていて高エントリーでいくらか加えました。
4.3.3.1.2. Reason in the History-Info Header
4.3.3.1.2. 歴史インフォメーションヘッダーの理由
For retargets that are the result of an explicit SIP response, a Reason MUST be associated with the hi-targeted-to-uri. If the SIP response does not include a Reason header, the SIP Response Code that triggered the retargeting MUST be included as the Reason associated with the hi-targeted-to-uri that has been retargeted. If the response contains a non-SIP Reason header (e.g., Q.850), it MUST be captured as an additional Reason associated with the hi-targeted-to- uri that has been retargeted, along with the SIP Response Code. If the Reason header is a SIP reason, then it MUST be used as the Reason associated with the hi-targeted-to-uri rather than the SIP response code.
明白なSIP応答の結果である「再-目標」に関しては、Reasonはuriに高狙いにされるのに関連しているに違いありません。 SIP応答がReasonヘッダーを含んでいないなら、uriに高狙いにされるのに「再-狙」った関連しているReasonとして「再-狙」いの引き金となったSIP Response Codeを含まなければなりません。 -狙って、uriに、それは行ったことがあります。応答が非SIP Reasonヘッダー(例えば、Q.850)を含んでいるなら、交際した追加Reasonとしてそれを捕らえなければならない、高、SIP Response Codeと共に「再-狙」いました。 ReasonヘッダーがSIP理由であるなら、ReasonがSIP応答コードよりむしろuriに高狙いにされると交際したので、使用されているに違いありません。
For retargets as a result of timeouts or internal events, a Reason MAY be associated with the hi-targeted-to-uri that has been retargeted.
タイムアウトか内部の出来事の結果、「再-目標」に関しては、Reasonはuriに高狙いにされるのに「再-狙」った関連しているかもしれません。
The addition of the Reason should occur prior to the forwarding of the request (which may add a new hi-entry with a new hi-targeted-to- uri) as it is associated with the hi-targeted-to-uri that has been retargeted, since it reflects the reason why the Request to that specific URI was not successful.
Reasonの添加が要求の推進の前に起こるべきである、(aが新しい状態でどれが狙われる高新しい高エントリーを加えるかもしれないか、-、-、uri) それがuriに高狙いにされるのに関連しているとき、それは「再-狙」いました、その特定のURIへのRequestがうまくいかなかった理由を反映するので。
4.3.3.1.3. Indexing in the History-Info Header
4.3.3.1.3. 歴史インフォメーションヘッダーでは、索引をつけます。
In order to maintain ordering and accurately reflect the nesting and retargeting of the request, an index MUST be included along with the Targeted-to-URI being captured. Per the syntax in Section 4.1, the index consists of a dot-delimited series of digits (e.g., 1.1.2). Each dot reflects a hop or level of nesting; thus, the number of hops is determined by the total number of dots. Within each level, the integer reflects the number of peer entities to which the request has been routed. Thus, the indexing results in a logical tree representation for the history of the Request. It is recommended that for each level of indexing, the index start at 1. It is recommended that an increment of 1 is used for advancing to a new branch.
秩序を維持して、正確に要求の巣篭もりと「再-狙」いを反映するために、得られるTargetedからURIと共にインデックスを含まなければなりません。 インデックスがセクション4.1の構文に従ってドットで区切られたシリーズのケタから成る、(例えば、1.1、.2、) 各ドットは巣篭もりのホップかレベルを反映します。 したがって、ドットの総数に従って、ホップの数は決定しています。 各レベルの中では、整数は要求が発送された同輩実体の数を反映します。 したがって、インデックスはRequestの歴史の論理的な木の表現をもたらします。 それはそれをそれぞれのレベルのインデックス、1時のインデックス始めに推薦されます。 1の増分が新しいブランチに達するのに使用されるのは、お勧めです。
The basic rules for adding the index are summarized as follows:
インデックスを加えるための基本的なルールは以下の通りまとめられます:
1. Basic Forwarding: In the case of a Request that is being
forwarded, the index is determined by adding another level of
indexing since the depth/length of the branch is increasing. To
accomplish this, the proxy reads the value from the History-Info
1. 基本的な推進: 進められているRequestの場合では、インデックスは、ブランチの深さ/長さが増加しているので別のレベルのインデックスを加えることによって、決定します。 これを達成するために、プロキシは歴史インフォメーションから値を読みます。
Barnes Standards Track [Page 16] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[16ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
header in the received request, if available, and adds another
level of indexing by appending the dot delimiter followed by an
initial index for the new level RECOMMENDED to be 1. For
example, if the index in the last History-Info header field in
the received request is 1.1, this proxy would initialize its
index to 1.1.1 and forward the request.
受信された要求における利用可能のヘッダー、新しい平らなRECOMMENDEDが初期のインデックスがあとに続いたドットデリミタを追加するのによる別のレベルのインデックスによる1歳であると言い足します。 例えば、1.1が最後の歴史インフォメーションヘッダーフィールドにおけるインデックスであるなら受信された要求に、あって、このプロキシは1.1の.1とフォワードにインデックスを初期化するでしょう。要求。
2. Retargeting within a Proxy - 1st instance: For the first
instance of retargeting within a Proxy, the calculation of the
index follows that prescribed for basic forwarding.
2. Proxyの中でRetargetingします--最初の例: Proxyの中で「再-狙」う最初の例のために、インデックスの計算は基本的な推進に処方されたそれに続きます。
3. Retargeting within a Proxy - subsequent instance: For each
subsequent retargeting of a request by the same proxy, another
branch is added. With the index for each new branch calculated
by incrementing the last/lowest digit at the current level, the
index in the next request forwarded by this same proxy,
following the example above, would be 1.1.2.
3. Proxyの中でRetargetingします--、その後の例: 同じプロキシによる要求のそれぞれのその後の「再-狙」いにおいて、別のブランチは加えられます。 現在のレベルにおける増加している最後の、または、最も低いケタによって計算されたそれぞれの新しいブランチのためのインデックスと共に、上記の例に倣っていて、この同じプロキシによって転送された次の要求におけるインデックスがあるだろう、1.1、.2
4. Retargeting based upon a Response: In the case of retargeting
due to a specific response (e.g., 302), the index would be
calculated per rule 3. That is, the lowest/last digit of the
index is incremented (i.e., a new branch is created), with the
increment RECOMMENDED to be 1. For example, if the index in the
History-Info header of the received request was 1.2, then the
index in the History-Info header field for the new hi-targeted-
to-URI would be 1.3.
4. RetargetingはResponseに基づかせました: 特定の応答(例えば、302)のため「再-狙」う場合では、インデックスは規則3単位で計算されるでしょう。 すなわち、インデックスの最も低いか下ケタは、1になるように増分のRECOMMENDEDと共に増加されます(すなわち、新しいブランチは創設されます)。 例えば、中のインデックスであるなら、受信された要求の歴史インフォメーションヘッダーは1.2であり、次に、歴史インフォメーションのインデックスは新しく高狙われるヘッダーフィールドです。-URIには、1.3があるでしょう。
5. Retargeting the request in parallel (forking): If the request
forwarding is done in parallel, the index MUST be captured for
each forked request per the rules above, with each new Request
having a unique index. The only difference in the messaging for
this scenario and the messaging produced per basic proxy
retargeting in rules 2 and 3 is these forwarded requests do not
have History-Info entries associated with their peers. The
proxy builds the subsequent response (or request) using the
aggregated information associated with each of those requests
and including the header entries in the order indicated by the
indexing. Responses are processed as described in Section 16.7
of [RFC3261] with the aggregated History-Info entries processed
similar to Step 7 "Aggregate Authentication Header Field
Values". Section 4.5 provides an example of a parallel request
scenario, highlighting this indexing mechanism.
5. 平行な要求(分岐)をRetargetingします: 平行で要求推進をするなら、それぞれの1規則あたりの股状の要求のためにインデックスを上として得なければなりません、ユニークなインデックスを持っているそれぞれの新しいRequestと共に。 メッセージングの唯一の違いが、規則2と3で「再-狙」う基本的なプロキシ単位で製作されたこのシナリオとメッセージングが進められたこれらであるので、彼らの同輩に関連している歴史インフォメーションエントリーを持たないよう要求します。 それぞれのそれらの要求に関連している集められた情報を使用して、指示された順番にインデックスでヘッダーエントリーを含んでいて、プロキシはその後の応答(または、要求)を組み込みます。 応答はStep7「集合認証ヘッダーフィールド値」と同様の処理されている集められた歴史インフォメーションエントリーで[RFC3261]のセクション16.7で説明されるように処理されます。 このインデックスメカニズムを強調して、セクション4.5は平行な要求シナリオに関する例を提供します。
Barnes Standards Track [Page 17] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[17ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
4.3.3.2. Processing History-Info in Responses
4.3.3.2. 応答における処理歴史インフォメーション
A proxy that receives a Request with the "histinfo" option tag in the Supported header, and depending upon a local policy supporting the capture of History-Info, SHOULD return captured History-Info in subsequent, provisional, and final responses to the Request, subject to the following considerations for privacy:
Supportedヘッダーの"histinfo"オプションタグとローカルの方針による歴史インフォメーションの捕獲を支持するRequestを受け取るプロキシ、SHOULDリターンはプライバシーのための以下の問題を条件としてRequestへのその後の、そして、暫定的で、最終的な応答における歴史インフォメーションを得ました:
o If the response is being forwarded to a Request-URI associated
with a domain for which the proxy is not responsible and there
was a Privacy header, in the request received by the proxy, with
a priv-value of "session", "header", or "history", the proxy MUST
remove the History-Info header (i.e., all hi-entries) prior to
forwarding.
o プロキシは責任がないドメインに関連しているRequest-URIに応答を送っていて、Privacyヘッダーがあったなら、「セッション」、「ヘッダー」、または「歴史」のpriv-値でプロキシによって受け取られた要求では、プロキシは推進の前に歴史インフォメーションヘッダー(すなわちすべての高エントリー)を取り除かなければなりません。
o If a request is being forwarded to a Request-URI associated with
a domain for which the proxy is not responsible and local policy
requires privacy associated with any or all hi-entry(s) it has
added, any hi-entry with a priv-value of "history" MUST be
removed prior to forwarding.
o プロキシは責任がないドメインに関連しているRequest-URIに要求を転送していて、ローカルの方針がそれが加えたいずれかかすべての高エントリーに関連しているプライバシーを必要とするなら、推進の前に「歴史」のpriv-値があるどんな高エントリーも取り除かなければなりません。
o If a proxy receives a response from another intermediary
associated with a domain for which it is responsible, including
hi-entry(s) with privacy headers, and that response is to be
forwarded to a domain for which it is not responsible, then those
hi-entry(s) MUST be removed.
o その応答がプロキシがプライバシーヘッダーによる高エントリーを含むそれは責任があるドメインに関連している別の仲介者から応答を受けて、それは責任がないドメインに送ることであるなら、高エントリーであるそれらを取り除かなければなりません。
The processing of History-Info in responses follows the methodology described in Section 16.7 of [RFC3261], with the processing of History-Info headers adding an additional step, just before Step 9, "Forwarding the Response".
応答における、歴史インフォメーションの処理は[RFC3261]のセクション16.7で説明された方法論に従います、歴史インフォメーションヘッダーの処理が追加ステップを加えていて、Step9のすぐ前で、「応答を進め」て。
4.3.4. Redirect Server Behavior
4.3.4. サーバの振舞いを向け直してください。
A redirect server SHOULD NOT add any new History-Info, as that would be done by the entity receiving the 3xx response. However, a redirect server MAY include History-Info in responses by adding any History-Info headers received in a request to a subsequent response.
再直接のサーバSHOULD NOTはどんな新しい歴史インフォメーションも加えます、3xx応答を受ける実体でそれをするように。 しかしながら、どんな歴史インフォメーションヘッダーも要求でその後の応答に受信したと言い足すことによって、再直接のサーバは応答に歴史インフォメーションを含むかもしれません。
4.4. Security for History-Info
4.4. 歴史インフォメーションのためのセキュリティ
As discussed in Section 3, the security requirements are met by recommending the use of TLS (a basic SIP requirement per [RFC3261]) for hop-by-hop security. If TLS is not available on the connection over which a request containing a History-Info header is being forwarded, then either of the following two options MUST be implemented:
セクション3で議論するように、セキュリティ必要条件はTLS([RFC3261]あたり1つの基本のSIP要件)のホップごとのセキュリティの使用を推薦することによって、満たされます。 TLSが歴史インフォメーションヘッダーを含む要求が転送されている接続のときに利用可能でないなら、以下の2つのオプションのどちらかを実行しなければなりません:
Barnes Standards Track [Page 18] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[18ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
o The History-Info header MUST be removed prior to forwarding the
request, or
o The request MUST be redirected, including the History-Info header
in the response, to allow the UAC to securely issue the request,
including the History-Info header.
o 要求を転送する前に、歴史インフォメーションヘッダーを取り除かなければなりませんか、または○ 要求を向け直さなければなりません、UACがしっかりと要求を出すのを許容するために応答に歴史インフォメーションヘッダーを含んでいて、歴史インフォメーションヘッダーを含んでいて。
4.5. Example Applications Using History-Info
4.5. 歴史インフォメーションを使用する例のアプリケーション
This scenario highlights an example where the History-Info in the response is primarily of use in not retrying routes that have already been tried by another proxy. Note that this is just an example and that there may be valid reasons why a Proxy would want to retry the routes, and thus, this would likely be a local proxy or even user- specific policy.
このシナリオは応答における歴史インフォメーションが別のプロキシによって既に試みられたルートを再試行しない際に主として役に立つ例を強調します。 その結果、これは、おそらくこれがただ例であり、Proxyがルートを再試行したがっている正当な理由があるかもしれないことに注意して、地元のプロキシかユーザ特定保険証券でさえあるでしょう。
UA1 sends a call to Bob to proxy 1. Proxy 1 forwards the request to Proxy 2. Proxy 2 sends the requests in parallel and tries several places (UA2, UA3, and UA4) before sending a response to Proxy 1 that all the places are busy. Proxy 1, without the History-Info, would try some of the same places (e.g., UA3) based upon registered contacts for Bob, before completing at UA5. However, with the History-Info, Proxy 1 determines that UA3 has already received the invite; thus, the INVITE goes directly to UA5.
UA1はプロキシ1へのボブに呼び出しを送ります。 プロキシ1はProxy2に要求を転送します。 プロキシ2は、平行な要求を送って、Proxy1へのすべての場所がそうである応答を送る前の(UA2、UA3、およびUA4)が忙しくする処々方々を試みます。 プロキシ1はボブのために歴史インフォメーションなしで登録された接触に基づく同じ場所(例えば、UA3)のいくつかを試みるでしょう、UA5での完成の前に。 しかしながら、歴史インフォメーションで、Proxy1は、UA3が既に招待を受けたことを決定します。 したがって、INVITEは直接UA5に行きます。
Section 4.5.1 provides this same scenario using one of the privacy mechanisms, with Proxy2 (P2) adding the Privacy header indicating that the History-Info header is not to be propagated outside P2's domain. This scenario highlights the potential functionality lost with the use of "history" privacy in the Privacy header for the entire request and the need for careful consideration on the use of privacy for History-Info.
セクション4.5 .1 プライバシーメカニズムの1つを使用するこの同じシナリオ、Proxy2(P2)が加えているP2のドメインの外で歴史インフォメーションヘッダーを伝播してはいけないのを示すPrivacyヘッダーを提供します。 このシナリオはPrivacyヘッダーにおける、「歴史」プライバシーの全体の要求と熟慮の必要性の使用に失われた潜在的機能性をプライバシーの歴史インフォメーションの使用に目立たせます。
Section 4.5.2 also provides the same scenario using one of the privacy mechanisms, however, due to local policy at Proxy2, only one of the Request-URIs (UA4) in the History-Info contains a priv-value of "history", thus allowing some optimized functionality in the routing of the request, but still maintaining privacy for specific URIs.
セクション4.5 .2 また、要求のルーティングでしかしながら、Proxy2、1だけのRequest-URI(UA4)のローカルの方針のため歴史インフォメーションでプライバシーメカニズムの1つを使用すると含む同じシナリオに「歴史」のpriv-値を提供して、その結果、何らかの最適化された機能性を許容しますが、特定のURIのためにプライバシーを維持して、まだ提供しています。
The formatting in these scenarios is for visual purposes; thus, backslash and CRLF are used between the fields for readability and the headers in the URI are not shown properly formatted for escaping. Refer to Section 4.2 examples for the proper formatting. Additional detailed scenarios are available in the appendix.
これらのシナリオの形式は視覚目的のためのものです。 したがって、バックスラッシュとCRLFは読み易さに分野の間で使用されます、そして、URIにおけるヘッダーは逃げるために適切にフォーマットされていた状態で見せられません。 セクション4.2 適切な形式のための例を参照してください。 追加詳細なシナリオは付録で利用可能です。
Barnes Standards Track [Page 19] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[19ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
| | |-INVITE>| | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com>;index=1.1.3
| | | | | | | |--招待-->|、|、|、|、|、|、| |-招待>|、|、|、|、| 支持される: histinfo歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 インデックス=1.1| | | | | | | | | |-招待>|、|、|、| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、;、<一口: =1.1、 User2@UA2.example.com に索引をつけてください gt;、;=1.1.1に索引をつけてください | | | | | | | | | |-----招待---->|、|、| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 <一口: =1.1、 User3@UA3.example.com に索引をつけてください、gt;、;=1.1.2に索引をつけてください | | | | | | | | | |-------招待------------>|、| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、;、<一口: =1.1、 User4@UA4.example.com に索引をつけてください gt;、;=1.1.3に索引をつけてください
/* All Responses from the INVITEs indicate non-success/non-
availability*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;\
cause=603;text="Decline">; index=1.1.3
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
/、*INVITEsからのすべてのResponsesが非成功であるか非有用性の*/を示します。| | | | | | | | | <、-480 ---| | | | | 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 =1.1、<一口に索引をつけてください: User2@UA2.example.com?Reason がSIP; \原因=408; テキスト=と等しい、「RequestTimeout、「>; =に索引をつけてください、1.1、.1、<はちびちび飲まれます: User3@UA3.example.com?Reason =SIP、」 \が=487 ; テキスト=を引き起こす、「終えられた">"を要求してください。 =に索引をつけてください、1.1、.2、<一口: User4@UA4.example.com?Reason がSIP; \原因=603; テキスト=と等しい、「">"を傾けてください。 インデックス=1.1.3| | | | | | | 応答を受け取り次第/*、P1はINVITEのために別のルートを決定しますが、それが既に試みられたルート(例えば、UA3)に合っているのがわかります、その結果、INVITEをUA5に送るだけです。そこでは、セッションが首尾よく設立された*/です。| | | | | | | | |----------------招待--------------------->| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 =1.1、<一口に索引をつけてください: User2@UA2.example.com?Reason がSIP; 原因=408; \テキスト=と等しい、「RequestTimeout、「>; =に索引をつけてください、1.1、.1、<一口: User3@UA3.example.com?Reason がSIP; 原因=487; \と等しい、」
Barnes Standards Track [Page 20] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[20ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
text="Request Terminated">; index=1.1.2,
<sip:User4@UA4.example.com?Reason=SIP;cause=603;\
text="Decline">; index=1.1.3
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
テキストが等しい、「終えられた">"を要求してください。 =に索引をつけてください、1.1、.2、<一口: User4@UA4.example.com?Reason がSIP; 原因=603; \テキスト=と等しい、「">"を傾けてください。 インデックス=1.1.3<一口: User5@UA5.example.com 、gt;、;=1.2に索引をつけてください | | | | | | | | | <、-、-、-、--200 OK---------------------------------| | <--200 OK---| | | | | | | | | | | | | |--ACK--------------------------------------------------->|
4.5.1. Example with Privacy Header for Entire Request at Proxy2
4.5.1. Proxy2での全体の要求のためのプライバシーヘッダーがある例
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1
| | | | | | |
| | |-INVITE>| | | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | |-------INVITE------------>| |
Privacy: history
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com>;index=1.1.3
| | | | | | | |--招待-->|、|、|、|、|、|、| |-招待>|、|、|、|、| 支持される: histinfo歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、;=1.1に索引をつけてください | | | | | | | | | |-招待>|、|、|、| プライバシー: 歴史歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、;、<一口: =1.1、 User2@UA2.example.com に索引をつけてください gt;、;=1.1.1に索引をつけてください | | | | | | | | | |-----招待---->|、|、| プライバシー: 歴史歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 <一口: =1.1、 User3@UA3.example.com に索引をつけてください、gt;、;=1.1.2に索引をつけてください | | | | | | | | | |-------招待------------>|、| プライバシー: 歴史歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、;、<一口: =1.1、 User4@UA4.example.com に索引をつけてください gt;、;=1.1.3に索引をつけてください
/* All Responses from the INVITEs indicate non-success/non-
availability and only the initial, received History-Info entries
are NOT returned to P1 due to the Privacy header value.*/
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
/、*INVITEsからのすべてのResponsesがPrivacyヘッダー価値のため、非の有用性、および初期の、そして、容認された歴史インフォメーションエントリーだけが返されない非成功/をP1に示す、*/| | | | | | | | | <、-480 ---| | | | | 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 インデックス=1.1| | | | | | | 応答、P1を受け取り次第/*は別のルートを決定します。
Barnes Standards Track [Page 21] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[21ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
INVITE, including UA3, which was attempted by P2, but due to
Privacy P1 is not aware of this, so UA3 is re-attempted prior to
forwarding the INVITE to UA5, where the session is successfully
established */
| | | | | | |
| |--------------INVITE ----->| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |<-- 486 -------------------| | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com>; index=1.2
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=486;\
text="Busy Here">;index=1.2,
<sip:User5@UA5.example.com>;index=1.3
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
UA3を含むP2によって試みられましたが、Privacy P1のため試みられたINVITEがこれを意識していないので、UA3はセッションが首尾よく確立されるUA5にINVITEを送る前再試みられた*/です。| | | | | | | | |--------------招待----->|、|、| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 <一口: =1.1、 User3@UA3.example.com に索引をつけてください、gt;、。 インデックス=1.2| | | | | | | | | <-- 486 -------------------| | | 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 <一口: =1.1、 User3@UA3.example.com に索引をつけてください、gt;、。 インデックス=1.2| | | | | | | | |----------------招待--------------------->| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 =1.1、<一口に索引をつけてください: User3@UA3.example.com?Reason がSIP; 原因=486; \テキスト=と等しい、「Hereと忙しくしてください、「>; <一口: =1.2、 User5@UA5.example.com に索引をつけてください、gt;、; インデックス=1.3」| | | | | | | | | <、-、-、-、--200 OK---------------------------------| | <--200 OK---| | | | | | | | | | | | | |--ACK--------------------------------------------------->|
4.5.2. Example with Privacy Header for Specific URI (UA4) at Proxy2
4.5.2. Proxy2の特定のURI(UA4)のためのプライバシーヘッダーがある例
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
UA1 Proxy1 Proxy2 UA2 UA3 UA4 UA5
| | | | | | |
|--INVITE -->| | | | | |
| |-INVITE->| | | | |
Supported: histinfo
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1
| | | | | | |
| | |-INVITE>| | | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User2@UA2.example.com>;index=1.1.1
| | | | | | |
| | |-----INVITE ---->| | |
History-Info:<sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User3@UA3.example.com>;index=1.1.2
| | | | | | |
| | | | | | | |--招待-->|、|、|、|、|、|、| |-招待>|、|、|、|、| 支持される: histinfo歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 インデックス=1.1| | | | | | | | | |-招待>|、|、|、| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、;、<一口: =1.1、 User2@UA2.example.com に索引をつけてください gt;、;=1.1.1に索引をつけてください | | | | | | | | | |-----招待---->|、|、| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、;、<一口: =1.1、 User3@UA3.example.com に索引をつけてください gt;、;=1.1.2に索引をつけてください | | | | | | |
Barnes Standards Track [Page 22] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[22ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
| | |-------INVITE------------>| |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>;index=1.1,
<sip:User4@UA4.example.com?\
Privacy=history>; index=1.1.3
| | |-------招待------------>|、| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、;=1.1、<一口に索引をつけてください: User4@UA4.example.com? \プライバシー=歴史> インデックス=1.1.3
/* All Responses from the INVITEs indicate non-success/non-
availability. The History-Info associated with UA4 is not returned
in the response due to the privacy header associated with that URI */
| | | | | | |
| |<-480 ---| | | | |
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;\
cause=408;text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP; \
cause=487;text="Request Terminated">; index=1.1.2,
| | | | | | |
/* Upon receipt of the response, P1 determines another route for the
INVITE, but finds that it matches a route already attempted
(e.g., UA3), thus the INVITE is only forwarded to UA5, where
the session is successfully established */
| | | | | | |
| |----------------INVITE --------------------->|
History-Info: <sip:Bob@P1.example.com>;index=1,
<sip:Bob@P2.example.com>; index=1.1,
<sip:User2@UA2.example.com?Reason=SIP;cause=408;\
text="RequestTimeout">;index=1.1.1,
<sip:User3@UA3.example.com?Reason=SIP;cause=487;\
text="Request Terminated">; index=1.1.2,
<sip:User5@UA5.example.com>;index=1.2
| | | | | | |
| |<-----200 OK---------------------------------|
|<--200 OK---| | | | | |
| | | | | | |
|--ACK --------------------------------------------------->|
*すべてのResponsesがINVITEsから非成功/を示します。/、非の有用性。 UA4に関連している歴史インフォメーションはそのURI*/に関連づけられたプライバシーヘッダーによる応答で返されません。| | | | | | | | | <、-480 ---| | | | | 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 =1.1、<一口に索引をつけてください: User2@UA2.example.com?Reason がSIP; \原因=408; テキスト=と等しい、「RequestTimeout、「>; =に索引をつけてください、1.1、.1、<はちびちび飲まれます: User3@UA3.example.com?Reason =SIP、」 \が=487 ; テキスト=を引き起こす、「終えられた">"を要求してください。 =1.1.2に索引をつけてください。| | | | | | | 応答を受け取り次第/*、P1はINVITEのために別のルートを決定しますが、それが既に試みられたルート(例えば、UA3)に合っているのがわかります、その結果、INVITEをUA5に送るだけです。そこでは、セッションが首尾よく設立された*/です。| | | | | | | | |----------------招待--------------------->| 歴史インフォメーション: <一口: Bob@P1.example.com 、gt;、;、<一口: =1、 Bob@P2.example.com に索引をつけてください gt;、。 =1.1、<一口に索引をつけてください: User2@UA2.example.com?Reason がSIP; 原因=408; \テキスト=と等しい、「RequestTimeout、「>; =に索引をつけてください、1.1、.1、<一口: User3@UA3.example.com?Reason はSIPと等しいです; =487を引き起こしてください; \」 テキスト=要求Terminated">" <一口: =1.1.2、 User5@UA5.example.com に索引をつけてください、gt;、;=1.2に索引をつけてください | | | | | | | | | <、-、-、-、--200 OK---------------------------------| | <--200 OK---| | | | | | | | | | | | | |--ACK--------------------------------------------------->|
Barnes Standards Track [Page 23] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[23ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
5. Application Considerations
5. アプリケーション問題
As seen by the example scenarios in the appendix, History-Info provides a very flexible building block that can be used by intermediaries and UAs for a variety of services. As such, any services making use of History-Info must be designed with the following considerations:
付録の例のシナリオによって見られるように、歴史インフォメーションは仲介者とUAsがさまざまなサービスに使用できる非常にフレキシブルなブロックを提供します。 そういうものとして、以下の問題で歴史インフォメーションを利用するどんなサービスも設計しなければなりません:
1) History-Info is optional; thus, a service MUST define default
behavior for requests and responses not containing History-Info
headers.
2) History-Info may be impacted by privacy considerations.
Applications requiring History-Info need to be aware that if
Header-, Session-, or History-level privacy is requested by a UA
(or imposed by an intermediary) that History-Info may not be
available in a request or response. This would be addressed by an
application in the same manner as the previous consideration by
ensuring there is reasonable default behavior should the
information not be available.
3) History-Info may be impacted by local policy. Each application
making use of the History-Info header SHOULD address the impacts
of the local policies on the specific application (e.g., what
specification of local policy is optimally required for a specific
application and any potential limitations imposed by local policy
decisions). Note that this is related to the optionality and
privacy considerations identified in 1 and 2 above, but goes
beyond that. For example, due to the optionality and privacy
considerations, an entity may receive only partial History-Info
entries; will this suffice? Note that this would be a limitation
for debugging purposes, but might be perfectly satisfactory for
some models whereby only the information from a specific
intermediary is required.
4) The security associated with the History-Info header requires the
use of TLS. In the case of TLS not being available for a
connection over which a request is being forwarded, the History-
Info header may be removed from a request. The impact of lack of
having the information depends upon the nature of the specific
application (e.g., Is the information something that appears on a
display or is it processed by automata which could have negative
impacts on the subsequent processing of a request?). It is
suggested that the impact of an intermediary not supporting the
security recommendations should be evaluated by the application to
ensure that the impacts have been sufficiently addressed by the
application.
1) 歴史インフォメーションは任意です。 したがって、サービスは歴史インフォメーションヘッダーを含まない要求と応答のためのデフォルトの振舞いを定義しなければなりません。 2) プライバシー問題は歴史インフォメーションに影響を与えるかもしれません。 歴史インフォメーションを必要とするアプリケーションは、UA(または、仲介者が課される)によって要求されていて、その歴史インフォメーションがHeader、Session、または歴史レベルプライバシーがそうなら要求か応答で利用可能でないかもしれないことを意識している必要があります。 情報が利用可能でないなら合理的なデフォルトの振舞いがあるのを確実にすることによって、これは前の考慮と同じ方法でアプリケーションで記述されるでしょう。 3) ローカルの方針で歴史インフォメーションに影響を与えるかもしれません。 歴史インフォメーションヘッダーSHOULDアドレスの使用を特定のアプリケーションへのローカルの方針の影響にする(例えば、ローカルの方針のどんな仕様がローカルの政策決定で課された特定のアプリケーションと何か潜在的制限に最適に必要ですか)各アプリケーション。 上で問題が1と2で特定したoptionalityとプライバシーに関連されますが、これはそれを越えることに注意してください。 例えば、optionalityとプライバシー問題のため、実体は部分的な歴史インフォメーションエントリーだけを受けるかもしれません。 これは十分でしょうか? これがデバッグ目的のための制限でしょうが、特定の仲介者からの情報だけが必要とされる何人かのモデルにおいて、完全に満足できるかもしれないことに注意してください。 4) 歴史インフォメーションヘッダーに関連しているセキュリティはTLSの使用を必要とします。 要求が転送されている接続に利用可能でないTLSの場合では、要求から歴史インフォメーションヘッダーを取り除くかもしれません。 情報を持つ不足の影響を特定のアプリケーションの本質に依存する、(例えば、Is、表示に見えるか、それである何かが要求のその後の処理のときに負の衝撃を持つことができたオートマトンを処理したという情報)? セキュリティ推薦を支持していない仲介者の衝撃がアプリケーションで衝撃を十分記述してあるのを保証するためにアプリケーションで評価されるべきであると示唆されます。
Barnes Standards Track [Page 24] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[24ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
6. Security Considerations
6. セキュリティ問題
The threat model and related security and privacy requirements for the History-Info header are described in Sections 2.1 and 2.2 of this document. Sections 3.2, 3.3, and 4.4 provide normative recommendations related to security and privacy fulfilling these requirements. The use of TLS is mandated between the entities (i.e., UAC to Proxy, Proxy to Proxy, and Proxy to UAS) that use the History-Info header. The appropriate handling of a request in the case that TLS is not available for a specific connection is described in Section 5.
歴史インフォメーションヘッダーのための脅威モデル、関連するセキュリティ、およびプライバシー要件はこのドキュメントのセクション2.1と2.2で説明されます。 セクション3.2、3.3、および4.4 セキュリティに関連する標準の推薦とこれらの要件を実現させるプライバシーを提供してください。 TLSの使用は歴史インフォメーションヘッダーを使用する実体(すなわち、ProxyへのUAC、ProxyへのProxy、およびUASへのProxy)の間で強制されます。 TLSが特定の接続に利用可能でないことで、要求の適切な取り扱いはセクション5で説明されます。
With TLS, History-Info headers are no less, nor no more, secure than other SIP headers, which generally have even more impact on the subsequent processing of SIP sessions than the History-Info header.
TLSと共に、歴史インフォメーションヘッダーは、よりノー以下であり、一般に、そうさえした他のSIPヘッダーより多くて、安全な以上は歴史インフォメーションヘッダーよりSIPセッションのその後の処理への影響です。
7. IANA Considerations
7. IANA問題
7.1. Registration of New SIP History-Info Header
7.1. 新しい一口歴史インフォメーションヘッダーの登録
This document defines a new SIP header field name: History-Info and a new option tag: histinfo.
このドキュメントは新しいSIPヘッダーフィールド名を定義します: 歴史インフォメーションと新しいオプションタグ: histinfo。
The following changes have been made to http:///www.iana.org/assignments/sip-parameters
以下の変更を http:///www.iana.org/assignments/sip-parameters にしました。
The following row has been added to the header field section:
以下の列をヘッダーフィールド部分に追加してあります:
Header Name Compact Form Reference ----------- ------------ --------- History-Info none [RFC4244]
ヘッダー名前コンパクト形参照----------- ------------ --------- 歴史インフォメーション、なし[RFC4244]
The following has been added to the Options Tags section:
Options Tags部に以下を追加してあります:
Name Description Reference
---- ----------- ---------
histinfo When used with the Supported header, [RFC4244]
this option tag indicates support
for the History Information to be
captured for requests and returned in
subsequent responses. This tag is not
used in a Proxy-Require or Require
header field since support of
History-Info is optional.
名前記述参照---- ----------- --------- Supportedヘッダーと共に使用されるhistinfo When、この[RFC4244]オプションタグは歴史情報を要求のために得て、その後の応答で返すためにサポートを示します。 歴史インフォメーションのサポートが任意であるので、このタグは、aがProxy必要としないどんな中古のコネと、またはRequireヘッダーフィールドでもありません。
Barnes Standards Track [Page 25] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[25ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
7.2. Registration of "history" for SIP Privacy Header
7.2. 一口プライバシーヘッダーへの「歴史」の登録
This document defines a new priv-value for the SIP Privacy header: history
このドキュメントはSIP Privacyヘッダーのために新しいpriv-値を定義します: 歴史
The following changes have been made to http://www.iana.org/assignments/sip-priv-values
以下の変更を http://www.iana.org/assignments/sip-priv-values にしました。
The following has been added to the registration for the SIP Privacy header:
以下はSIP Privacyヘッダーのために登録に加えられます:
Name Description Registrant Reference
---- ----------- ---------- ---------
history Privacy requested for Mary Barnes [RFC4244]
History-Info header(s) mary.barnes@nortel.com
名前記述記入者参照---- ----------- ---------- --------- 歴史Privacyはメアリ・バーンズ[RFC4244]のために歴史インフォメーションヘッダー mary.barnes@nortel.com を要求しました。
8. Normative References
8. 引用規格
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3261] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 2002.
[RFC3326] Schulzrinne、H.、オラン、D.、およびG.キャマリロ、「セッション開始プロトコル(一口)のための理由ヘッダーフィールド」、RFC3326(2002年12月)。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323] ピーターソン、J.、「セッション開始プロトコル(一口)のためのプライバシーメカニズム」、RFC3323、2002年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2246] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
9. Informative References
9. 有益な参照
[RFC3665] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and
K. Summers, "Session Initiation Protocol (SIP) Basic Call
Flow Examples", BCP 75, RFC 3665, December 2003.
[RFC3665] ジョンストン、A.、ドノヴァン、S.、スパークス、R.、カニンハム、C.、およびK.夏、「セッション開始プロトコル(一口)基本的な呼び出し流れの例」、BCP75、RFC3665、2003年12月。
10. Acknowledgements
10. 承認
The editor would like to acknowledge the constructive feedback provided by Robert Sparks, Paul Kyzivat, Scott Orton, John Elwell, Nir Chen, Francois Audet, Palash Jain, Brian Stucker, Norma Ng, Anthony Brown, Jayshree Bharatia, Jonathan Rosenberg, Eric Burger,
エディタはロバート・スパークスによって提供された建設的なフィードバックを承認したがっています、ポールKyzivat、スコット・オートン、ジョン・エルウェル、ニール・チェン、フランソアAudet、ジャイナ教のPalashブライアンStucker、ノーマ・ウン、アンソニー・ブラウン、Jayshree Bharatia、ジョナサン・ローゼンバーグ、エリックBurger
Barnes Standards Track [Page 26] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[26ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
Martin Dolly, Roland Jesske, Takuya Sawada, Sebastien Prouvost, and Sebastien Garcin.
マーチン・ドリー、ローランドJesske、Takuya Sawada、セバスチアンProuvost、およびセバスチアンGarcin。
The editor would like to acknowledge the significant input from Rohan Mahy on some of the normative aspects of the ABNF, particularly around the need for and format of the index and around the security aspects.
エディタはABNFの標準の局面のいくつかでRohanマーイからの重要な入力を承諾したがっています、特に必要性の周りでそして、インデックスとセキュリティ局面の周りの形式。
11. Contributors' Addresses
11. 貢献者のアドレス
Cullen, Mark, and Jon contributed to the development of the initial requirements.
カレン、マーク、およびジョンは初期の要件の開発に貢献しました。
Cullen and Mark provided substantial input in the form of email discussion in the development of the initial version of the individual solution document.
カレンとマークは個々の解決策ドキュメントの初期のバージョンの開発における、メール議論の形にかなりの入力を供給しました。
Cullen Jennings Cisco Systems 170 West Tasman Dr MS: SJC-21/3
カレンジョニングスシスコシステムズ170の西タスマン博士MS: SJC-21/3
Phone: +1 408 421 9990 EMail: fluffy@cisco.com
以下に電話をしてください。 +1 9990年の408 421メール: fluffy@cisco.com
Jon Peterson NeuStar, Inc. 1800 Sutter Street, Suite 570 Concord, CA 94520 USA
ジョンピーターソンNeuStar, Inc.1800Sutter通り、スイート570一致、カリフォルニア94520米国
Phone: +1 925-363-8720 EMail: Jon.Peterson@NeuStar.biz
以下に電話をしてください。 +1 925-363-8720 メールしてください: Jon.Peterson@NeuStar.biz
Mark Watson Digital Fountain 39141 Civic Center Drive Suite 300 Fremont, CA 94538 U.S.A.
フレモント、マークワトソンデジタル噴水39141シビック・センタードライブスイート300カリフォルニア94538米国
EMail: mark@digitalfountain.com
メール: mark@digitalfountain.com
Barnes Standards Track [Page 27] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[27ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
Appendix. Example Scenarios
付録。 例のシナリオ
The scenarios in Appendices A-D provide sample use cases for the History-Info header for informational purposes only. They are not intended to be normative and the formatting is for visual purposes; thus, the headers in the URI are not shown properly formatted for escaping. Refer to Section 4.2 examples with the proper formatting.
Appendices A-Dのシナリオは情報の目的だけのための歴史インフォメーションヘッダーのためにサンプル使用にケースを供給します。 それらが規範的であることを意図しないで、形式は視覚目的のためのものです。 したがって、URIにおけるヘッダーは逃げるために適切にフォーマットされていた状態で見せられません。 適切な形式でセクション4.2 例を参照してください。
Appendix A. Sequentially Forking (History-Info in Response)
付録A.は連続してフォーク状にされます。(応答における歴史インフォメーション)
This scenario highlights an example where the History-Info in the response is useful to an application or user that originated the request.
このシナリオは応答における歴史インフォメーションが要求を溯源したアプリケーションかユーザの役に立つ例を強調します。
Alice at UA1 sends a call to Bob via Proxy1. Proxy1 sequentially tries several places (UA2, UA3 and UA4) unsuccessfully before sending a response to Alice.
UA1のアリスはProxy1を通して呼び出しをボブに送ります。 応答をアリスに送る前に、Proxy1は処々方々(UA2、UA3、およびUA4)を連続して、試みて失敗した。
This scenario is provided to show that by providing the History-Info to UA1, the end-user or an application at UA1 could make a decision on how best to attempt finding Bob. Without this mechanism, UA1 might well attempt UA3 (and thus UA4) and then re-attempt UA4 on a third manual attempt at reaching Bob. With this mechanism, either the end-user or application could know that Bob is busy on his home phone and is physically not in the office. If there were an alternative address for Bob known to this end-user or application, that hasn't been attempted, then either the application or the end- user could attempt that. The intent here is to highlight an example of the flexibility of this mechanism that enables applications well beyond SIP as it is certainly well beyond the scope of this document to prescribe detailed applications.
エンドユーザかUA1のアプリケーションが歴史インフォメーションをUA1に供給することによって、ボブを見つけるのをどのように最もよく試みるかに関する決定をするかもしれないのを示すためにこのシナリオを提供します。 このメカニズムがなければ、UA1はUA3(そして、その結果、UA4)を試みて、次に、ボブに届くことへの3番目の手動の試みのときにたぶんUA4を再試みるでしょう。 このメカニズムで、エンドユーザかアプリケーションがボブが彼の家の電話で忙しく、オフィスで物理的にそうしていないのを知るかもしれません。 このエンドユーザかアプリケーションに知られていて、ボブのための代替アドレスがあるなら、それは試みられていなく、だろうにて、次に、アプリケーションか終わりのユーザのどちらかがそれを試みることができました。 ここの意図は詳細なアプリケーションを定めるためにかなり確かにこのドキュメントの範囲を超えているときSIPでアプリケーションをよく可能にするこのメカニズムの柔軟性に関する例を強調することです。
In this scenario, since UA1 has not included the original Request-URI in the INVITE, the proxy adds a hi-entry to capture the original Request-URI to provide the complete set of information, as discussed in Section 4.3.3.1.
このシナリオでは、UA1がINVITEにオリジナルのRequest-URIを含んでいないので、プロキシは完全な情報を提供するためにオリジナルのRequest-URIを得るために高エントリーを加えます、セクション4.3.3で.1に議論するように
Barnes Standards Track [Page 28] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[28ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
UA1 Proxy1 UA2 UA3 UA4 | | | | | |-INVITE F1->| | | | | | | | | | |--INVITE F2------>| | | |<--100 F3---| | | | | |<-302 F4----------| | | | | | | | | |-------INVITE F5 --------->| | | | | | | | |<-------180 F6 ------------| | |<---180 F7--| | | | | . . |---retransmit INVITE ----->| | | | | | | | | ( timeout ) | | | | | | | | | |------INVITE F8 ------------------->| |<--100 F9 --| | | | | | | | | | |<-486 F10 --------------------------| | | | | | | |-- ACK F11------------------------->| |<--486 F12--| | | | | | | | | |--ACK F13-->| | | | | | | | |
UA1 Proxy1 UA2 UA3 UA4| | | | | |-F1を招いてください。>|、|、|、|、|、|、|、|、|、| |--F2を招待してください。------>|、|、| | <--100 F3---| | | | | | <、-302 F4----------| | | | | | | | | |-------F5を招待してください。--------->|、|、|、|、|、|、|、| | <、-、-、-、-、-、--180 F6------------| | | <、-、--180F7--| | | | | . . |---INVITEを再送してください。----->|、|、|、|、|、|、|、|、| (タイムアウト) | | | | | | | | | |------F8を招待してください。------------------->| | <--100F9--| | | | | | | | | | | <、-486 F10--------------------------| | | | | | | |-- ACK F11------------------------->| | <--486F12--| | | | | | | | | |--ACK F13-->|、|、|、|、|、|、|、|、|
Message Details
メッセージの詳細
F1 INVITE UA1 ->Proxy1
F1招待UA1->、Proxy1
INVITE sip:UserA@example.com SIP/2.0 Via: SIP/2.0/UDP example.net:5060 From: Alice <sip:User1@example.net> To: Bob <sip:UserA@example.com> Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: Alice <sip:User1@example.net> Content-Type: application/sdp Content-Length: <appropriate value>
INVITE一口: UserA@example.com SIP/2.0Via: SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 接触を招いてください: アリス<一口: User1@example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: <の適切な値の>。
v=0 o=UserA 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0セッションSDP c=IN IP4 192.0.2.3v=0 o=UserA2890844526 2890844526IN IP4 client.example.net s=t=m=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000
Barnes Standards Track [Page 29] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[29ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
/*Client for UA1 prepares to receive data on port 49170 from the network. */
UA1のための/*クライアントは、ネットワークからポート49170に関するデータを受け取るのを準備します。 */
F2 INVITE Proxy1 ->UA2
F2がProxy1->を招待する、UA2
INVITE sip:UserA@ims.example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
Record-Route: <sip:UserA@example.com>
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com>; index=1.1
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE一口: UserA@ims.example.com SIP/2.0Via: SIP/2.0/UDP ims.example.com: 5060; ブランチは1Viaと等しいです: SIP/2.0/UDP example.net: 5060年のRecord-ルート: <一口: UserA@example.com 、gt;、From: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 歴史インフォメーションを招待してください: <一口: UserA@example.com 、gt;、。 <一口: =1、 UserA@ims.example.com に索引をつけてください、gt;、。 =1.1Contactに索引をつけてください: アリス<一口: User1@example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: <の適切な値の>。
v=0
o=UserA 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
0 0セッションSDP c=IN IP4 192.0.2.3v=0 o=UserA2890844526 2890844526IN IP4 client.example.net s=t=m=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000
F3 100 Trying Proxy1 ->UA1
F3 100の骨の折れるProxy1->、UA1
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
以下を通って試みる一口/2.0 100 SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 コンテンツの長さを招待してください: 0
F4 302 Moved Temporarily UA2 ->Proxy1
F4 302が一時UA2->を動かした、Proxy1
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP ims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>;tag=3
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Contact: <sip:UserB@example.com>
Content-Length: 0
一口/2.0 302は以下を通って一時動きました。 SIP/2.0/UDP ims.example.com: 5060; ブランチは1Viaと等しいです: SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、; タグは3呼び出しイドと等しいです: 12345600@example.net CSeq: 1 接触を招いてください: <一口: UserB@example.com 、gt;、コンテンツの長さ: 0
Barnes Standards Track [Page 30] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[30ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
F5 INVITE Proxy1 -> UA3
F5はProxy1->UA3を招待します。
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=2
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">; index=1.1,
<sip:UserB@example.com>;index=1.2
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE一口: UserB@example.com SIP/2.0Via: SIP/2.0/UDP ims.example.com: 5060; ブランチは2Viaと等しいです: SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net 歴史インフォメーション: <一口: UserA@example.com 、gt;、。 インデックス=1、<一口: UserA@ims.example.com?Reason はSIPと等しいです; \原因=302 テキストが等しい、「一時、">"を動かします。 <一口: =1.1、 UserB@example.com に索引をつけてください、gt;、; インデックスは1.2CSeqと等しいです: 1 接触を招いてください: アリス<一口: User1@example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: <の適切な値の>。
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
0 0セッションSDP c=IN IP4 192.0.2.3v=0 o=User1 2890844526 2890844526IN IP4 client.example.net s=t=m=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000
F6 180 Ringing UA3 ->Proxy1
UA3->を鳴らすF6 180、Proxy1
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>;tag=5
Call-ID: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
以下を通って鳴る一口/2.0 180 SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、; タグは5呼び出しIDと等しいです: 12345600@example.net CSeq: 1 コンテンツの長さを招待してください: 0
F7 180 Ringing Proxy1 -> UA1
Proxy1->UA1を鳴らすF7 180
SIP/2.0 180 Ringing
SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
SIP/2.0 180Ringing SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 コンテンツの長さを招待してください: 0
/* User B is not available. INVITE is sent multiple
times until it times out. */
/*ユーザBは手があいていません。 それまで複数の回をINVITEに送ります。回のアウト。 */
Barnes Standards Track [Page 31] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[31ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
/* The proxy forwards the INVITE to UA4 after adding the
additional History Information entry. */
追加歴史情報エントリーを加えた後にプロキシがUA4へのINVITEを送る/*。 */
F8 INVITE Proxy1 -> UA4
F8はProxy1->UA4を招待します。
INVITE sip:UserC@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2,
<sip:UserC@example.com>;index=1.3
CSeq: 1 INVITE
Contact: Alice <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE一口: UserC@example.com SIP/2.0Via: SIP/2.0/UDP ims.example.com: 5060; ブランチは3Viaと等しいです: SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net 歴史インフォメーション: <一口: UserA@example.com 、gt;、。 インデックス=1、<一口: UserA@ims.example.com?Reason はSIPと等しいです; \原因=302 テキストが等しい、「一時一時「>; <一口: インデックス=1.1、 UserB@example.com?Reason =一口; =480を引き起こします;\テキスト=」を動かす、入手できなさ、」 >; <一口: =1.2、 UserC@example.com に索引をつけてください、gt;、; インデックスは1.3CSeqと等しいです: 1 接触を招いてください: アリス<一口: User1@example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: <の適切な値の>。
v=0
o=User1 2890844526 2890844526 IN IP4 client.example.net
s=Session SDP
c=IN IP4 192.0.2.3
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
0 0セッションSDP c=IN IP4 192.0.2.3v=0 o=User1 2890844526 2890844526IN IP4 client.example.net s=t=m=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000
F9 100 Trying Proxy1 ->UA1
F9 100の骨の折れるProxy1->、UA1
SIP/2.0 100 Trying
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
Content-Length: 0
以下を通って試みる一口/2.0 100 SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 コンテンツの長さを招待してください: 0
F10 486 Busy Here UA4 -> Proxy1
F10 486はここでUA4->Proxy1と忙しくします。
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
ここで以下を通って/2.0 486忙しい状態でちびちび飲んでください。 SIP/2.0/UDP ims.example.com: 5060; ブランチは3Viaと等しいです: SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net
Barnes Standards Track [Page 32] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[32ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
CSeq: 1 INVITE
Content-Length: 0
CSeq: 1 コンテンツの長さを招待してください: 0
F11 ACK Proxy1 -> UA4
F11 ACK Proxy1->UA4
ACK sip:UserC@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 ACK
Content-Length: 0
ACK一口: UserC@example.com SIP/2.0Via: SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 ACKコンテンツの長さ: 0
/* The proxy forwards the 486 to Alice after adding the
associated History Information entries from the series of
INVITES */
INVITES*/のシリーズから関連歴史情報エントリーを加えるプロキシがアリスへの486を進める/*
F12 486 Busy Here Proxy1 -> UA1
F12 486はここでProxy1->UA1と忙しくします。
SIP/2.0 486 Busy Here
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@example.com>; index=1,
<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1.1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=1.2,
<sip:UserC@example.com>;index=1.3
CSeq: 1 INVITE
Content-Length: 0
ここで以下を通って/2.0 486忙しい状態でちびちび飲んでください。 SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net 歴史インフォメーション: <一口: UserA@example.com 、gt;、。 インデックス=1、<一口: UserA@ims.example.com?Reason はSIPと等しいです; \原因=302 テキストが等しい、「一時一時「>; <一口: インデックス=1.1、 UserB@example.com?Reason =一口; =480を引き起こします;\テキスト=」を動かす、入手できなさ、」 >; <一口: =1.2、 UserC@example.com に索引をつけてください、gt;、; インデックスは1.3CSeqと等しいです: 1 コンテンツの長さを招待してください: 0
F13 ACK Alice -> Proxy 1
F13 ACKアリス->プロキシ1
ACK sip:UserA@example.com SIP/2.0
Via: SIP/2.0/UDP example.net:5060
From: Alice <sip:User1@example.net>
To: Bob <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 ACK
Content-Length: 0
ACK一口: UserA@example.com SIP/2.0Via: SIP/2.0/UDP example.net: 5060年のFrom: アリス<一口: User1@example.net 、gt;、To: ボブ<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 ACKコンテンツの長さ: 0
Barnes Standards Track [Page 33] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[33ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
Appendix B. Voicemail
付録B.ボイスメール
This scenario highlights an example where the History-Info in the request is primarily of use by an edge service (e.g., voicemail server). It should be noted that this isn't intended to be a complete specification for this specific edge service as it is quite likely that additional information is needed by the edge service. History-Info is just one building block that this service makes use of.
このシナリオは縁のサービス(例えば、ボイスメールサーバ)で要求における歴史インフォメーションが主として役に立つ例を強調します。 これがこの特定の縁のサービスのための追加情報が縁のサービスでかなり必要でありそうであるので完全な仕様であることを意図しないことに注意されるべきです。 歴史インフォメーションはこのサービスが利用するちょうど1つのブロックです。
UA1 called UA A, which had been forwarded to UA B, which forwarded to a UA VM (voicemail server). Based upon the retargeted URIs and Reasons (and other information) in the INVITE, the VM server makes a policy decision about what mailbox to use, which greeting to play, etc.
UA1は、UA Aと呼びました。(UA AはUA Bに送られました)。(UA Bは(ボイスメールサーバ)をUA VMに送りました)。 INVITEの「再-狙」っているURIとReasons(そして、他の情報)に基づいて、VMサーバは使用へのどんなメールボックス、どの挨拶をプレーしたらよいかに関する政策決定などを作ります。
UA1 Proxy UA-A UA-B UA-VM
UA1プロキシUA-A UA-B UA-VM
| | | | | |--INVITE F1-->| | | | | | | | | | |--INVITE F2-->| | | |<--100 F3-----| | | | | |<-302 F4------| | | | | | | | | |--------INVITE F5---------->| | | | | | | | |<--------180 F6-------------| | |<---180 F7----| | | | | . . . | | | | | |------retransmit INVITE---->| | | . . . | | | | | | (timeout) | | | | | | | | |-------INVITE F8---------------------->| | | | | | | |<-200 F9-------------------------------| | | | | | |<-200 F10-----| | | | | | | | | |--ACK F11-------------------------------------------->|
| | | | | |--F1を招いてください-->|、|、|、|、|、|、|、|、|、| |--F2を招待してください-->|、|、| | <--100 F3-----| | | | | | <、-302 F4------| | | | | | | | | |--------F5を招待してください。---------->|、|、|、|、|、|、|、| | <、-、-、-、-、-、-、--180 F6-------------| | | <、-、--180 F7----| | | | | . . . | | | | | |------INVITEを再送してください。---->|、|、| . . . | | | | | | (タイムアウト) | | | | | | | | |-------F8を招待してください。---------------------->|、|、|、|、|、|、| | <、-200 F9-------------------------------| | | | | | | <、-200 F10-----| | | | | | | | | |--ACK F11-------------------------------------------->|
Barnes Standards Track [Page 34] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[34ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
Message Details
メッセージの詳細
INVITE F1 UA1->Proxy
F1を招いてください、UA1->、プロキシ
INVITE sip:UserA@example.com SIP/2.0 Via: SIP/2.0/UDP example.net:5060 From: BigGuy <sip:User1@example.net> To: LittleGuy <sip:UserA@example.com> Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: BigGuy <sip:User1@example.net> Content-Type: application/sdp Content-Length: <appropriate value> v=0 o=UserA 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
INVITE一口: UserA@example.com SIP/2.0Via: SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 接触を招いてください: BigGuy<一口: User1@example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 0 0セッションSDP c=IN IP4 192.0.2.3<の適切な値の>v=0 o=UserA2890844526 2890844526IN IP4 client.example.net s=t=m=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000
/*Client for UA1 prepares to receive data on port 49170 from the network. */
UA1のための/*クライアントは、ネットワークからポート49170に関するデータを受け取るのを準備します。 */
INVITE F2 Proxy->UA-A
F2プロキシ->を招待してください、UA-A
INVITE sip:UserA@ims.example.com SIP/2.0
Via: SIP/2.0/UDPims.example.com:5060;branch=1
Via: SIP/2.0/UDP example.net:5060
Record-Route: <sip:UserA@example.com>
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
CSeq: 1 INVITE
History-Info: <sip:UserA@ims.example.com>; index=1
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE一口: UserA@ims.example.com SIP/2.0Via: 一口/2.0/UDPims.example.com: 5060; 以下を通ってブランチ=1 SIP/2.0/UDP example.net: 5060年のRecord-ルート: <一口: UserA@example.com 、gt;、From: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 歴史インフォメーションを招待してください: <一口: UserA@ims.example.com 、gt;、。 =1Contactに索引をつけてください: BigGuy<一口: User1@example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: <の適切な値の>。
v=0 o=UserA 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0セッションSDP c=IN IP4 192.0.2.3v=0 o=UserA2890844526 2890844526IN IP4 client.example.net s=t=m=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000
100 Trying F3 Proxy->UA1
100の骨の折れるF3プロキシ->、UA1
Barnes Standards Track [Page 35] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[35ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
SIP/2.0 100 Trying Via: SIP/2.0/UDP example.net:5060 From: BigGuy <sip:User1@example.net> To: LittleGuy <sip:UserA@example.com> Call-Id: 12345600@example.net CSeq: 1 INVITE Content-Length: 0
以下を通って試みる一口/2.0 100 SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 コンテンツの長さを招待してください: 0
302 Moved Temporarily F4 UserA->Proxy SIP/2.0 302 Moved Temporarily Via: SIP/2.0/UDP ims.example.com:5060;branch=1 Via: SIP/2.0/UDP example.net:5060 From: BigGuy <sip:User1@example.net> To: LittleGuy<sip:UserA@example.com>;tag=3 Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: <sip:UserB@example.com> Content-Length: 0
302が一時動いた、F4 UserA->、プロキシ、一口/2.0 302は以下を通って一時動きました。 SIP/2.0/UDP ims.example.com: 5060; ブランチは1Viaと等しいです: SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、; タグは3呼び出しイドと等しいです: 12345600@example.net CSeq: 1 接触を招いてください: <一口: UserB@example.com 、gt;、コンテンツの長さ: 0
INVITE F5 Proxy-> UA-B
F5プロキシ->UA-Bを招待してください。
INVITE sip:UserB@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=2
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info: <sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">; index=1,
<sip:UserB@example.com>;index=2
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE一口: UserB@example.com SIP/2.0Via: SIP/2.0/UDP ims.example.com: 5060; ブランチは2Viaと等しいです: SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net 歴史インフォメーション: <一口: UserA@ims.example.com?Reason はSIPと等しいです; \原因=302 テキストが等しい、「一時、">"を動かします。 <一口: =1、 UserB@example.com に索引をつけてください、gt;、; インデックスは2CSeqと等しいです: 1 接触を招いてください: BigGuy<一口: User1@example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: <の適切な値の>。
v=0 o=User1 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0セッションSDP c=IN IP4 192.0.2.3v=0 o=User1 2890844526 2890844526IN IP4 client.example.net s=t=m=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000
180 Ringing F6 UA-B ->Proxy
180鳴るF6 UA-B->、プロキシ
SIP/2.0 180 Ringing Via: SIP/2.0/UDP example.net:5060 From: BigGuy <sip:User1@example.net>
以下を通って鳴る一口/2.0 180 SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt。
Barnes Standards Track [Page 36] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[36ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
To: LittleGuy <sip:UserA@example.com>;tag=5 Call-ID: 12345600@example.net CSeq: 1 INVITE Content-Length: 0
To: LittleGuy<一口: UserA@example.com 、gt;、; タグは5呼び出しIDと等しいです: 12345600@example.net CSeq: 1 コンテンツの長さを招待してください: 0
180 Ringing F7 Proxy-> UA1
180 F7プロキシ->UA1を鳴らすこと。
SIP/2.0 180 Ringing SIP/2.0/UDP example.net:5060 From: BigGuy <sip:User1@example.net> To: LittleGuy <sip:UserA@example.com> Call-Id: 12345600@example.net CSeq: 1 INVITE Content-Length: 0
SIP/2.0 180Ringing SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net CSeq: 1 コンテンツの長さを招待してください: 0
/* User B is not available. INVITE is sent multiple times until it times out. */
/*ユーザBは手があいていません。 それまで複数の回をINVITEに送ります。回のアウト。 */
/* The proxy forwards the INVITE to UA-VM after adding the
additional History Information entry. */
追加歴史情報エントリーを加えた後にプロキシがUA-VMへのINVITEを送る/*。 */
INVITE F8 Proxy-> UA-VM
F8プロキシ->UA-VMを招待してください。
INVITE sip:VM@example.com SIP/2.0
Via: SIP/2.0/UDP ims.example.com:5060;branch=3
Via: SIP/2.0/UDP example.net:5060
From: BigGuy <sip:User1@example.net>
To: LittleGuy <sip:UserA@example.com>
Call-Id: 12345600@example.net
History-Info:<sip:UserA@ims.example.com?Reason=SIP;\
cause=302; text="Moved Temporarily">;index=1,
<sip:UserB@example.com?Reason=SIP;cause=480;\
text="Temporarily Unavailable" >;index=2,
<sip:VM@example.com>;index=3
CSeq: 1 INVITE
Contact: BigGuy <sip:User1@example.net>
Content-Type: application/sdp
Content-Length: <appropriate value>
INVITE一口: VM@example.com SIP/2.0Via: SIP/2.0/UDP ims.example.com: 5060; ブランチは3Viaと等しいです: SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、呼び出しイド: 12345600@example.net 歴史インフォメーション: <一口: UserA@ims.example.com?Reason はSIPと等しいです; \原因=302 テキストが等しい、「一時一時「>; <一口: インデックス=1、 UserB@example.com?Reason =一口; =480を引き起こします;\テキスト=」を動かす、入手できなさ、」 >; <一口: =2、 VM@example.com に索引をつけてください、gt;、; インデックスは3CSeqと等しいです: 1 接触を招いてください: BigGuy<一口: User1@example.net 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: <の適切な値の>。
v=0 o=User1 2890844526 2890844526 IN IP4 client.example.net s=Session SDP c=IN IP4 192.0.2.3 t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0セッションSDP c=IN IP4 192.0.2.3v=0 o=User1 2890844526 2890844526IN IP4 client.example.net s=t=m=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000
200 OK F9
200 OK F9
Barnes Standards Track [Page 37] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[37ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
SIP/2.0 200 OK UA-VM->Proxy
一口/2.0 200OK、UA-VM->、プロキシ
Via: SIP/2.0/UDP ims.example.com:5060;branch=3 Via: SIP/2.0/UDP example.net:5060 From: BigGuy <sip:User1@example.net> To: LittleGuy <sip:UserA@example.com>;tag=3 Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: TheVoiceMail <sip:VM@example.com> Content-Type: application/sdp Content-Length: <appropriate value>
以下を通って SIP/2.0/UDP ims.example.com: 5060; ブランチは3Viaと等しいです: SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、; タグは3呼び出しイドと等しいです: 12345600@example.net CSeq: 1 接触を招いてください: TheVoiceMail<一口: VM@example.com 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: <の適切な値の>。
v=0 o=UserA 2890844527 2890844527 IN IP4 vm.example.com s=Session SDP c=IN IP4 192.0.2.4 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0v=0 o=UserA2890844527 2890844527IN IP4 vm.example.com s=セッションSDP c=IN IP4 192.0.2.4t=m=オーディオの3456RTP/AVP0a=rtpmap: 0PCMU/8000
200 OK F10 Proxy->UA1
200がF10プロキシ->を承認する、UA1
SIP/2.0 200 OK Via: SIP/2.0/UDP ims.example.com:5060;branch=3 Via: SIP/2.0/UDP example.net:5060 From: BigGuy <sip:User1@example.net> To: LittleGuy <sip:UserA@example.com>;tag=3 Call-Id: 12345600@example.net CSeq: 1 INVITE Contact: TheVoiceMail <sip:VM@example.com> Content-Type: application/sdp Content-Length: <appropriate value>
以下を通って一口/2.0 200OK SIP/2.0/UDP ims.example.com: 5060; ブランチは3Viaと等しいです: SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、; タグは3呼び出しイドと等しいです: 12345600@example.net CSeq: 1 接触を招いてください: TheVoiceMail<一口: VM@example.com 、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: <の適切な値の>。
v=0 o=UserA 2890844527 2890844527 IN IP4 vm.example.com s=Session SDP c=IN IP4 192.0.2.4 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0v=0 o=UserA2890844527 2890844527IN IP4 vm.example.com s=セッションSDP c=IN IP4 192.0.2.4t=m=オーディオの3456RTP/AVP0a=rtpmap: 0PCMU/8000
ACK F11 UA1-> UA-VM
ACK F11 UA1->Ua-VM
ACK sip:VM@example.com SIP/2.0 Via: SIP/2.0/UDP example.net:5060 From: BigGuy <sip:User1@example.net> To: LittleGuy<sip:UserA@example.com>;tag=3 Call-Id: 12345600@example.net
ACK一口: VM@example.com SIP/2.0Via: SIP/2.0/UDP example.net: 5060年のFrom: BigGuy<一口: User1@example.net 、gt;、To: LittleGuy<一口: UserA@example.com 、gt;、; タグは3呼び出しイドと等しいです: 12345600@example.net
Barnes Standards Track [Page 38] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[38ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
CSeq: 1 ACK Content-Length: 0
CSeq: 1 ACKコンテンツの長さ: 0
/* RTP streams are established between UA1 and UA-VM. UA-VM starts announcement for UA1 */
/*RTPの流れはUA1とUA-VMの間で確立されます。 UA-VMはUA1*/のための発表を始めます。
Appendix C. Automatic Call Distribution Example
付録C.自動着信呼分配の例
This scenario highlights an example of an Automatic Call Distribution service, where the agents are divided into groups based upon the type of customers they handle. In this example, the Gold customers are given higher priority than Silver customers, so a Gold call would get serviced even if all the agents servicing the Gold group (ACDGRP1) were busy, by retargeting the request to the Silver Group. Upon receipt of the call at the agent assigned to handle the incoming call, based upon the History-Info header in the message, the application at the agent can provide an indication that this is a Gold call, from how many groups it might have overflowed before reaching the agent, etc. and thus can be handled appropriately by the agent.
このシナリオは自動着信呼分配サービスの例を強調します。そこでは、エージェントが彼らが扱う顧客のタイプに基づくグループに分割されます。 Goldグループ(ACDGRP1)にサービスを提供するすべてのエージェントが忙しかったとしても、この例では、Gold顧客が優先するので、シルヴァー顧客より高いGold電話は修理されるでしょうに、シルヴァーGroupに要求を「再-狙」うことによって。 呼び出しを受け取り次第、エージェントのアプリケーションを、これがエージェントに届く前にそれがいくつのグループをはみ出させたかもしれないかからのGold呼び出しであるという指示などを提供できて、エージェントはその結果、適切に扱うことができます。
For scenarios whereby calls might overflow from the Silver to the Gold, clearly the alternate group identification, internal routing, or actual agent that handles the call SHOULD not be sent to UA1. Thus, for this scenario, one would expect that the Proxy would not support the sending of the History-Info in the response, even if requested by the calling UA.
呼び出しSHOULDを扱う呼び出しがシルヴァーからGoldまであふれるかもしれないシナリオ、明確に交互のグループ識別、内部のルーティング、または実際のエージェントに関しては、UA1に送られないでください。 したがって、このシナリオのために、人は、Proxyが応答における、歴史インフォメーションの発信を支持しないと予想するでしょう、呼んでいるUAによって要求されても。
As with the other examples, this is not prescriptive of how one would do this type of service but an example of a subset of processing that might be associated with such a service. In addition, this example is not addressing any aspects of Agent availability, which might also be done via a SIP interface.
他の例のように、1つがどうそのようなサービスに関連するかもしれないこのタイプのサービスにもかかわらず、処理の部分集合の例をするだろうかにこれは規範的ではありません。 さらに、この例はエージェントの有用性の少しの局面も記述していません。(また、SIPインタフェースを通して有用性をするかもしれません)。
Barnes Standards Track [Page 39] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[39ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
UA1 Proxy ACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2
UA1プロキシACDGRP1 Svr ACDGRP2 Svr UA2-ACDGRP2
| | | | |
|--INVITE F1-->| | | |
Supported:histinfo
| | | | |
| |--INVITE F2-->| | |
Supported:histinfo
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
| | | | |
| |<-302 F3------| | |
Contact: <sip:ACDGRP2@ACD.com>
| | | | |
| |--------INVITE F4---------->| |
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
| | | | |
| | | | |
| | | |INVITE F5>|
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
| | | | |
| | | |<-200 F6--|
| | | | |
| |<-200 F7--------------------| |
History-Info: <sip:Gold@example.com>; index=1
History-Info: <sip:ACDGRP1@example.com>; index=1.1
History-Info: <sip:ACDGRP2@example.com>; index=1.2
|<-200 F8------| | | |
< No History-Info included in the response due to Local Policy>
| | | | |
|--ACK F9--------------------------------------------->|
| | | | | |--F1を招いてください-->|、|、|、| : histinfoを支持します。| | | | | | |--F2を招待してください-->|、|、| : histinfo歴史インフォメーションを支持します: <一口: Gold@example.com 、gt;、。 =1歴史インフォメーションに索引をつけてください: <一口: ACDGRP1@example.com 、gt;、。 インデックス=1.1| | | | | | | <、-302 F3------| | | 接触: <一口: ACDGRP2@ACD.com 、gt。| | | | | | |--------F4を招待してください。---------->|、| 歴史インフォメーション: <一口: Gold@example.com 、gt;、。 =1歴史インフォメーションに索引をつけてください: <一口: ACDGRP1@example.com 、gt;、。 =1.1歴史インフォメーションに索引をつけてください: <一口: ACDGRP2@example.com 、gt;、。 インデックス=1.2| | | | | | | | | | | | | |F5を招待してください。>| 歴史インフォメーション: <一口: Gold@example.com 、gt;、。 =1歴史インフォメーションに索引をつけてください: <一口: ACDGRP1@example.com 、gt;、。 =1.1歴史インフォメーションに索引をつけてください: <一口: ACDGRP2@example.com 、gt;、。 インデックス=1.2| | | | | | | | | <、-200F6--| | | | | | | | <、-200 F7--------------------| | 歴史インフォメーション: <一口: Gold@example.com 、gt;、。 =1歴史インフォメーションに索引をつけてください: <一口: ACDGRP1@example.com 、gt;、。 =1.1歴史インフォメーションに索引をつけてください: <一口: ACDGRP2@example.com 、gt;、。 インデックス=1.2| <、-200 F8------| | | | Local Policy>による応答に歴史インフォメーションを全く含んでいない<。| | | | | |--ACK F9--------------------------------------------->|
Barnes Standards Track [Page 40] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[40ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
Appendix D. Session via Redirect and Proxy Servers
RedirectとProxyサーバを通した付録D.Session
In this scenario, Alice places a call to Bob using first a Redirect server then a Proxy Server. The INVITE message is first sent to the Redirect Server. The Server returns a 302 Moved Temporarily response (F2) containing a Contact header with Bob's current SIP address. Alice then generates a new INVITE with Bob's current SIP address included in another History-Info entry. The INVITE is then sent to Bob via the Proxy Server, with Bob receiving the complete History information; the call then proceeds normally. The complete call flow for this scenario, without the use of History-Info, is described in Section 3.6 of the SIP Basic Call Flow Examples [RFC3665].
このシナリオでは、最初に、Redirectサーバを使用することでアリスはボブに電話して、ボブの現在のSIPアドレスでContactヘッダーを含んでいて、次に. INVITEメッセージが最初に送られるProxyサーバは302Moved Temporarily応答(F2)を. Redirect Server Serverに返します。 そして、ボブの現在のSIPアドレスが別の歴史インフォメーションエントリーに含まれている状態で、アリスは新しいINVITEを発生させます。 次に、ボブが完全な歴史情報を受け取っていて、ProxyサーバでINVITEをボブに送ります。 そして、通常、呼び出しは続きます。 このシナリオのための完全な呼び出し流動はSIP Basic Call Flow Examples[RFC3665]のセクション3.6で歴史インフォメーションの使用なしで説明されます。
Alice Redirect Server Proxy 3 Bob
| | | |
| INVITE F1 | | |
|--------------->| | |
| 302 F2 | | |
|<---------------| | |
| ACK F3 | | |
|--------------->| | |
| INVITE F4 | |
|-------------------------------->| INVITE F5 |
| 100 F6 |--------------->|
アリス・再直接のサーバプロキシ3ボブ| | | | | F1を招いてください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 302 F2| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK F3| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| F4を招待してください。| | |-------------------------------->| F5を招待してください。| | 100 F6|、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|
Message Details
メッセージの詳細
F1 INVITE Alice -> Redirect Server
F1はアリス->再直接のサーバを招待します。
INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com> Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 INVITE History-Info: <sip:bob@biloxi.example.com>; index=1 Contact: <sip:alice@client.atlanta.example.com> Content-Length: 0
INVITE一口: bob@biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bKbf9f44マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、呼び出しID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 歴史インフォメーションを招待してください: <一口: bob@biloxi.example.com 、gt;、。 =1Contactに索引をつけてください: <一口: alice@client.atlanta.example.com 、gt;、コンテンツの長さ: 0
F2 302 Moved Temporarily Redirect Proxy -> Alice
F2 302は一時再直接のプロキシ->アリスを動かしました。
SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44
;received=192.0.2.1
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
一口/2.0 302は以下を通って一時動きました。 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチ=z9hG4bKbf9f44;は=192.0.2.1From:を受けました。 アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; =53fHlqlQ2呼び出しIDにタグ付けをしてください: 2xTb9vxSit55XU7p8@atlanta.example.com
Barnes Standards Track [Page 41] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[41ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
CSeq: 1 INVITE History-Info: <sip:bob@biloxi.example.com>; index=1 Contact: <sip:bob@chicago.example.com;transport=tcp> Content-Length: 0
CSeq: 1 歴史インフォメーションを招待してください: <一口: bob@biloxi.example.com 、gt;、。 =1Contactに索引をつけてください: <一口: bob@chicago.example.com;transport はtcp>コンテンツの長さと等しいです: 0
F3 ACK Alice -> Redirect Server
F3 ACKアリス->再直接のサーバ
ACK sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKbf9f44 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=53fHlqlQ2 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACK Content-Length: 0
ACK一口: bob@biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bKbf9f44マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; =53fHlqlQ2呼び出しIDにタグ付けをしてください: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACKコンテンツの長さ: 0
F4 INVITE Alice -> Proxy 3
F4はアリス->プロキシ3を招待します。
INVITE sip:bob@chicago.example.com SIP/2.0
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
text="Moved Temporarily">; index=1,
<sip:bob@chicago.example.com>; index=2
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Content-Length: 0
INVITE一口: bob@chicago.example.com SIP/2.0Via: 一口/2.0/TCP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf9マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、呼び出しID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 歴史インフォメーションを招待してください: <一口: bob@biloxi.example.com?Reason は一口と等しいです; 原因が302>円のテキスト=と等しい、「一時、">"を動かします。 <一口: =1、 bob@chicago.example.com に索引をつけてください、gt;、。 =2Contactに索引をつけてください: <一口: alice@client.atlanta.example.com;transport がtcpと等しい、gt;、コンテンツの長さ: 0
F5 INVITE Proxy 3 -> Bob
F5はプロキシ3->ボブを招待します。
INVITE sip:bob@client.chicago.example.com SIP/2.0
Via: SIP/2.0/TCP ss3.chicago.example.com:5060;branch=z9hG4bK721e.1
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.1
Max-Forwards: 69
Record-Route: <sip:ss3.chicago.example.com;lr>
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 2 INVITE
History-Info: <sip:bob@biloxi.example.com?Reason=SIP;cause=302>\
text="Moved Temporarily">; index=1,
<sip:bob@chicago.example.com>; index=2,
<sip:bob@client.chicago.example.com>; index=2.1
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
INVITE一口: bob@client.chicago.example.com SIP/2.0Via: 一口/2.0/TCP ss3.chicago.example.com: 5060; ブランチは以下を通ってz9hG4bK721e.1と等しいです。 一口/2.0/TCP client.atlanta.example.com: 5060; ブランチ=z9hG4bK74bf9; 容認された=192.0.2の.1のマックス-フォワード: 69の記録的なルート: <一口: ss3.chicago.example.com; lr>From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、呼び出しID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 2 歴史インフォメーションを招待してください: <一口: bob@biloxi.example.com?Reason は一口と等しいです; 原因が302>円のテキスト=と等しい、「一時、">"を動かします。 <一口: =1、 bob@chicago.example.com に索引をつけてください、gt;、。 <一口: =2、 bob@client.chicago.example.com に索引をつけてください、gt;、。 =2.1Contactに索引をつけてください: <一口: alice@client.atlanta.example.com;transport がtcpと等しい、gt。
Barnes Standards Track [Page 42] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[42ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
Content-Length: 0
コンテンツの長さ: 0
Detailed Call Flow continues per section 6.3 in [RFC3665].
詳細なCall Flowは[RFC3665]でセクション6.3単位で続きます。
Editor's Address
エディタのアドレス
Mary Barnes Nortel 2201 Lakeside Blvd Richardson, TX USA
メアリバーンズノーテル2201の湖畔Blvdテキサスリチャードソン(米国)
Phone: 1-972-684-5432 EMail: mary.barnes@nortel.com
以下に電話をしてください。 1-972-684-5432 メールしてください: mary.barnes@nortel.com
Barnes Standards Track [Page 43] RFC 4244 SIP Request History Information November 2005
バーンズ標準化過程[43ページ]RFC4244は要求履歴情報2005年11月にちびちび飲みます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Barnes Standards Track [Page 44]
バーンズ標準化過程[44ページ]
一覧
スポンサーリンク
