RFC5057 日本語訳
5057 Multiple Dialog Usages in the Session Initiation Protocol. R.Sparks. November 2007. (Format: TXT=62654 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Sparks Request for Comments: 5057 Estacado Systems Category: Informational November 2007
スパークがコメントのために要求するワーキンググループR.をネットワークでつないでください: 5057年のエスタカードシステムカテゴリ: 情報の2007年11月
Multiple Dialog Usages in the Session Initiation Protocol
セッション開始プロトコルの複数の対話用法
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
Several methods in the Session Initiation Protocol (SIP) can create an association between endpoints known as a dialog. Some of these methods can also create a different, but related, association within an existing dialog. These multiple associations, or dialog usages, require carefully coordinated processing as they have independent life-cycles, but share common dialog state. Processing multiple dialog usages correctly is not completely understood. What is understood is difficult to implement.
Session Initiationプロトコル(SIP)のいくつかの方法が対話として知られている終点の間の協会を創設できます。 また、これらの方法のいくつかが既存の対話の中に異なりましたが、関連する協会を創設できます。 複数の協会、または対話用法が慎重に必要とするこれらは、独立しているライフサイクルを過すので処理を調整しますが、一般的な対話状態を共有します。 複数の対話用法を処理するのは正しく完全に理解されているというわけではありません。 理解されていることは実行するのが難しいです。
This memo argues that multiple dialog usages should be avoided. It discusses alternatives to their use and clarifies essential behavior for elements that cannot currently avoid them.
このメモは、複数の対話用法が避けられるべきであると主張します。 それは、彼らの使用への代替手段について議論して、現在それらを避けることができない要素のための不可欠の振舞いをはっきりさせます。
This is an informative document and makes no normative statements of any kind.
これは、有益なドキュメントであり、どんな種類のどんな規範的陳述にもなりません。
Sparks Informational [Page 1] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[1ページ]のRFC5057をかきたてます。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Examples of Multiple Usages . . . . . . . . . . . . . . . . . 4
3.1. Transfer . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Reciprocal Subscription . . . . . . . . . . . . . . . . . 6
4. Usage Creation and Destruction . . . . . . . . . . . . . . . . 9
4.1. Invite Usages . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Subscribe usages . . . . . . . . . . . . . . . . . . . . . 9
5. Proper Handling of Multiple Usages . . . . . . . . . . . . . . 9
5.1. A Survey of the Effect of Failure Responses on Usages
and Dialogs . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Transaction Timeouts . . . . . . . . . . . . . . . . . . . 15
5.3. Matching Requests to Usages . . . . . . . . . . . . . . . 16
5.4. Target Refresh Requests . . . . . . . . . . . . . . . . . 17
5.5. Refreshing and Terminating Usages . . . . . . . . . . . . 17
5.6. Refusing New Usages . . . . . . . . . . . . . . . . . . . 18
5.7. Replacing Usages . . . . . . . . . . . . . . . . . . . . . 18
6. Avoiding Multiple Usages . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 23
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
10. Informative References . . . . . . . . . . . . . . . . . . . . 24
1. 概観. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 複数の用法. . . . . . . . . . . . . . . . . 4 3.1に関する例 .43.2を移してください。 相互的な購読. . . . . . . . . . . . . . . . . 6 4。 用法創造と破壊. . . . . . . . . . . . . . . . 9 4.1。 用法. . . . . . . . . . . . . . . . . . . . . . 9 4.2を招待してください。 用法. . . . . . . . . . . . . . . . . . . . . 9 5を申し込んでください。 複数の用法. . . . . . . . . . . . . . 9 5.1の適切な取り扱い 用法と対話. . . . . . . . . . . . . . . . . . . . . . . 9 5.2への失敗応答の効果の調査。 取引タイムアウト. . . . . . . . . . . . . . . . . . . 15 5.3。 用法. . . . . . . . . . . . . . . 16 5.4に要求に合っています。 目標は要求. . . . . . . . . . . . . . . . . 17 5.5をリフレッシュします。 用法. . . . . . . . . . . . 17 5.6をリフレッシュして、終えます。 新しい用法. . . . . . . . . . . . . . . . . . . 18 5.7を拒否します。 用法. . . . . . . . . . . . . . . . . . . . . 18 6を置き換えます。 .187に複数の用法を避けます。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 23 8。 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 24 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 24 10。 有益な参照. . . . . . . . . . . . . . . . . . . . 24
1. Overview
1. 概観
This is an informative document. It makes no normative statements of any kind. This document refines the concept of a dialog usage in the Session Initiation Protocol (SIP [1]), and discusses what led to its existence. It explores ambiguity associated with processing multiple dialog usages that share a dialog. In particular, it surveys the effect of SIP failure responses on transaction, dialog usage, and dialog state. This document will help the implementer understand what is required to process multiple dialog usages correctly, and will provide information for future standards-track work that will clarify RFC 3261 and other related documents. Finally, the document explores single-usage dialog alternatives (using SIP extensions) to multiple dialog usages.
これは有益なドキュメントです。 それはどんな種類の規範的陳述も全く作りません。 このドキュメントがSession Initiationプロトコルの対話用法の概念を洗練する、(SIP[1])、存在につながったことについて議論します。 それは対話を共有する複数の対話用法を処理すると関連しているあいまいさについて調査します。 特に、それは取引、対話用法、および対話状態へのSIP失敗応答の効果について調査します。 このドキュメントは、implementerが、何が正しく複数の対話用法を処理するのに必要であるかを理解しているのを助けて、RFC3261と他の関連するドキュメントをはっきりさせる今後の標準化過程仕事のための情報を前提とするでしょう。 最終的に、ドキュメントはただ一つの用法対話代替手段を複数の対話用法に探ります(SIP拡張子を使用します)。
2. Introduction
2. 序論
Several methods in SIP can establish a dialog. When they do so, they also establish an association between the endpoints within that dialog. This association has been known for some time as a "dialog usage" in the developer community. A dialog initiated with an INVITE request has an invite usage. A dialog initiated with a SUBSCRIBE
SIPのいくつかの方法が対話を確立できます。 また、彼らがそうすると、彼らはその対話の中に終点の間の協会を設立します。 この協会はしばらく「対話用法」として開発者社会で知られています。 INVITE要求で開始された対話は招待用法を持っています。 登録で開始された対話
Sparks Informational [Page 2] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[2ページ]のRFC5057をかきたてます。
request has a subscribe usage. A dialog initiated with a REFER request has a subscribe usage.
要求で、aは用法を申し込みます。 REFER要求で開始された対話で、aは用法を申し込みます。
Dialogs with multiple usages arise when a usage-creating action occurs inside an existing dialog. Such actions include accepting a REFER or SUBSCRIBE issued inside a dialog established with an INVITE request. Multiple REFERs within a dialog create multiple subscriptions, each of which is a new dialog usage sharing common dialog state. (Note that any REFER issued utilizing the subscription-suppression mechanism specified in [2] creates no new usage.) Similarly, an endpoint in a dialog established with an INVITE might subscribe to its peer's Key Press Markup Language (KPML) [3] and later issue a REFER, resulting in three dialog usages sharing common dialog state.
用法を作成する動作が既存の対話で起こると、複数の用法がある対話は起こります。 そのような動作は、REFERを受け入れるのを含んでいるか、登録。INVITE要求で確立された対話では、発行されます。 対話の中の複数のREFERsが複数の購読を作成します。それはそれぞれ一般的な対話状態を共有する新しい対話用法です。 ([2]で指定された購読抑圧メカニズムを利用することで発行されたどんなREFERもどんな新しい用法も作成しないことに注意してください。) 同様に、INVITEと共に確立された対話における終点は、同輩のKey Press Markup Language(KPML)[3]に加入して、後でREFERを発行するかもしれません、一般的な対話状態を共有する3つの対話用法をもたらして。
The common state in the dialog shared by any usages is exactly:
どんな用法でも共有された対話における一般的な状態はまさに以下の通りです。
o the Call-ID
o 呼び出しID
o the local Tag
o 地方のTag
o the remote Tag
o リモートTag
o the local CSeq
o 地方のCSeq
o the remote CSeq
o リモートCSeq
o the Route-set
o ルートセット
o the local contact
o 地方の接触
o the remote target
o リモート目標
o the secure flag
o 安全な旗
Usages have state that is not shared in the dialog. For example, a subscription has a duration, along with other usage-specific state. Multiple subscriptions in the same dialog each have their own duration.
用法には、対話で共有されない状態があります。 例えば、購読には、他の用法特有の状態に伴う持続時間があります。 同じ対話における複数の購読には、それぞれそれら自身の持続時間があります。
A dialog comes into existence with the creation of the first usage, and continues to exist until the last usage is terminated (reference counting). Unfortunately, many of the usage management aspects of SIP, such as authentication, were originally designed with the implicit assumption that there was one usage per dialog. The resulting mechanisms have mixed effects, some influencing the usage, and some influencing the entire dialog.
対話は、最初の用法の創造で生まれて、最後の用法が終えられるまで(参照が重要であることで)、存続します。 残念ながら、認証などのSIPの用法管理局面の多くが元々、1対話あたり1つの用法があったという暗黙の仮定で設計されました。 結果として起こるメカニズムが効果を混ぜて、いくつかの影響が用法であり、何かが全体の対話に影響を及ぼすことです。
Sparks Informational [Page 3] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[3ページ]のRFC5057をかきたてます。
The current specifications define two usages, invite and subscribe. A dialog can share up to one invite usage and arbitrarily many subscribe usages.
現在の仕様は、2つの用法、招待を定義して、申し込まれます。 対話は最大1つの招待用法を共有できます、そして、任意に、多くが用法を申し込みます。
Because RFC 3261 [1] states that user-agents should reuse Call-ID and increment CSeq across a series of registration requests (and that to- tags appear in register responses in some of the examples), some implementations have treated REGISTER as if it were in a dialog. However, RFC 3261 explicitly calls out that REGISTER does not create a dialog. A series of REGISTER requests does not create any usage or dialog. Similarly, PUBLISH [4] does not create any usage or dialog.
RFC3261[1]が、ユーザエージェントがCall-IDを再利用して、一連の登録要求の向こう側にCSeqを増加するべきであると述べる、(それ、-、タグが例のいくつかにおけるレジスタ応答に現れる、)、まるで対話にはそれがあるかのようにいくつかの実現がREGISTERを扱いました。 しかしながら、RFC3261は、REGISTERが対話を作成しないと明らかに大声で叫びます。 一連のREGISTER要求はどんな用法や対話も作成しません。 同様に、PUBLISH[4]はどんな用法や対話も作成しません。
3. Examples of Multiple Usages
3. 複数の用法に関する例
3.1. Transfer
3.1. 転送
In Figure 1, Alice transfers a call she received from Bob to Carol. A dialog (and an invite dialog usage) between Alice and Bob comes into being with the 200 OK labeled F1. A second usage (a subscription to event refer) comes into being with the NOTIFY labeled F2. This second usage ends when the subscription is terminated by the NOTIFY transaction labeled F3. The dialog still has one usage (the invite usage), which lasts until the BYE transaction labeled F4. At this point, the dialog has no remaining usages, so it ceases to exist. Details of each of these messages are shown in Figure 2.
図1では、アリスはボブからキャロルまで受けた呼び出しを移します。 200OKがF1とラベルされている状態で、アリスとボブの間の対話(そして、招待対話用法)は生まれます。 NOTIFYがF2とラベルされている状態で、2番目の用法(出来事の購読は参照される)は生まれます。 購読がF3とラベルされたNOTIFY取引で終えられるとき、この2番目の用法は終わります。 対話には、ある用法(招待用法)がまだあります。(それは、F4とラベルされたBYE取引を続けます)。 ここに、対話には残っている用法が全くないので、それは消滅します。 それぞれに関するこれらのメッセージの詳細は図2に示されます。
Sparks Informational [Page 4] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[4ページ]のRFC5057をかきたてます。
Alice Bob Carol
| INVITE | |
|<----------------| |
Dialog 1 Usage 1 | 200 OK (F1) | |
-start- -start- ----------->|---------------->| |
| | | ACK | |
| | |<----------------| |
| | | reINVITE/200/ACK| |
| | | (hold) | |
| | |---------------->| |
| | | REFER | |
| | Dialog 1 |---------------->| |
| | Usage 2 | NOTIFY (F2) | |
| | -start- -->|<----------------| INVITE |
| | | | 200 NOTIFY |----------->|
| | | |---------------->| 200 OK |
| | | | 200 REFER |<-----------|
| | | |<----------------| ACK |
| | | | NOTIFY (F3) |----------->|
| | | |<----------------| |
| | | | 200 | . |
| | -end- -->|---------------->| . |
| | | BYE (F4) | Dialog 2 |
| | |<----------------| proceeds |
| | | 200 | . |
-end- -end- ------------>|---------------->| . |
アリス・ボブ・キャロル| 招待| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 対話1用法1| 200 OK(F1)| | -スタート始め、------------>|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| ACK| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| reINVITE/200/ACK| | | | | (保持) | | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 参照してください。| | | | 対話1|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 用法2| (F2)に通知してください。| | | | -始まってください-->| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 招待| | | | | 200に通知します。|、-、-、-、-、-、-、-、-、-、--、>|、|、|、| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 200 OK| | | | | 200は参照されます。| <、-、-、-、-、-、-、-、-、-、--、|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| ACK| | | | | (F3)に通知してください。|、-、-、-、-、-、-、-、-、-、--、>|、|、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| 200 | . | | | -終わってください-->|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| . | | | | さようなら(F4)| 対話2| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 売り上げ| | | | 200 | . | -終わり-終わり、------------->|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| . |
Figure 1
図1
Message Details (abridged to show only dialog or usage details)
F1
SIP/2.0 200 OK
Call-ID: dialog1@bob.example.com
CSeq: 100 INVITE
To: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:aliceinstance@alice.example.com>
メッセージDetails(対話か利用明細だけを示しているために、要約される)F1 SIP/2.0 200 OK Call-ID: dialog1@bob.example.com CSeq: 100はTo:を招待します。 <一口: Alice@alice.example.com 、gt;、;=alicetag1From:にタグ付けをしてください <一口: Bob@bob.example.com 、gt;、; =bobtag1接触にタグ付けをしてください: <一口: aliceinstance@alice.example.com 、gt。
F2
NOTIFY sip:aliceinstance@alice.example.com SIP/2.0
Event: refer
Call-ID: dialog1@bob.example.com
CSeq: 101 NOTIFY
To: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:bobinstance@bob.example.com>
F2 NOTIFY一口: aliceinstance@alice.example.com SIP/2.0Event: Call-IDを参照してください: dialog1@bob.example.com CSeq: 101はTo:に通知します。 <一口: Alice@alice.example.com 、gt;、;=alicetag1From:にタグ付けをしてください <一口: Bob@bob.example.com 、gt;、; =bobtag1接触にタグ付けをしてください: <一口: bobinstance@bob.example.com 、gt。
Sparks Informational [Page 5] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[5ページ]のRFC5057をかきたてます。
F3
NOTIFY sip:aliceinstance@alice.example.com SIP/2.0
Event: refer
Subscription-State: terminated;reason=noresource
Call-ID: dialog1@bob.example.com
CSeq: 102 NOTIFY
To: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:bobinstance@bob.example.com>
Content-Type: message/sipfrag
F3 NOTIFY一口: aliceinstance@alice.example.com SIP/2.0Event: Subscription-状態を参照してください: 終わり、; 理由はnoresource Call-IDと等しいです: dialog1@bob.example.com CSeq: 102はTo:に通知します。 <一口: Alice@alice.example.com 、gt;、;=alicetag1From:にタグ付けをしてください <一口: Bob@bob.example.com 、gt;、; =bobtag1接触にタグ付けをしてください: <一口: bobinstance@bob.example.com 、gt;、コンテントタイプ: メッセージ/sipfrag
SIP/2.0 200 OK
一口/2.0 200OK
F4
BYE sip:aliceinstance@alice.example.com SIP/2.0
Call-ID: dialog1@bob.example.com
CSeq: 103 BYE
To: <sip:Alice@alice.example.com>;tag=alicetag1
From: <sip:Bob@bob.example.com>;tag=bobtag1
Contact: <sip:bobinstance@bob.example.com>
F4 BYE一口: aliceinstance@alice.example.com SIP/2.0Call-ID: dialog1@bob.example.com CSeq: 103不戦勝To: <一口: Alice@alice.example.com 、gt;、;=alicetag1From:にタグ付けをしてください <一口: Bob@bob.example.com 、gt;、; =bobtag1接触にタグ付けをしてください: <一口: bobinstance@bob.example.com 、gt。
Figure 2
図2
3.2. Reciprocal Subscription
3.2. 相互的な購読
In Figure 3, Alice subscribes to Bob's presence. For simplicity, assume Bob and Alice are both serving their presence from their endpoints instead of a presence server. To focus on the essential points, the figure leaves out any rendezvous signaling through which Alice discovers Bob's endpoint.
図3では、アリスはボブの存在に加入します。 簡単さには、ボブとアリスが存在サーバの代わりにそれらの終点からそれらの存在にともに勤めていると仮定してください。不可欠のポイントに焦点を合わせるために、図はアリスがボブの終点を発見するどんなランデブーシグナリングも省きます。
Bob is interested in Alice's presence too, so he subscribes to Alice (in most deployed presence/IM systems, people watch each other). He decides to skip the rendezvous step since he's already in a dialog with Alice, and sends his SUBSCRIBE inside that dialog (a few early SIMPLE clients behaved exactly this way).
ボブがアリスの存在にも興味を持っているので、彼はアリスに加入します(ほとんどの配備された存在/IMシステムでは、人々は互いを見ます)。 彼は、その対話で登録と彼が対話にはアリスと共に既にいて、彼のものを送るのでランデブーが踏むスキップに決めます(数人の初期のSIMPLEクライアントがまさにこのように振る舞いました)。
The dialog and its first usage comes into being at F1, which establishes Alice's subscription to Bob. Its second usage begins at F2, which establishes Bob's subscription to Alice. These two subscriptions are independent - they have distinct and different expirations, but they share all the dialog state.
対話とその最初の用法はF1で生まれます。(それは、ボブのアリスの購読を確立します)。 2番目の用法はF2で始まります。(F2はアリスのボブの購読を確立します)。 これらの2つの購読が独立しています--異なって異なった満期を過しますが、それらはすべての対話状態を共有します。
The first usage ends when Alice decides to unsubscribe at F3. Bob's subscription to Alice, and thus the dialog, continues to exist. Alice's UA must maintain this dialog state even though the subscription that caused it to exist in the first place is now over. The second usage ends when Alice decides to terminate Bob's
アリスが、F3で外すと決めると、最初の用法は終わります。 アリスのボブの購読、およびその結果対話は存続します。 それが第一に存在した購読は現在、終わっていますが、アリスのUAはこの対話状態を維持しなければなりません。アリスが、ボブのものを終えると決めると、2番目の用法は終わります。
Sparks Informational [Page 6] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[6ページ]のRFC5057をかきたてます。
subscription at F4 (she's probably going to reject any attempt on Bob's part to resubscribe until she's ready to subscribe to Bob again). Since this was the last usage, the dialog also terminates. Details of these messages are shown in Figure 4.
F4(彼女はたぶん再びボブに加入する準備ができるまでボブの部分へのどんな試みもresubscribeに拒絶する)での購読。 また、これが最後の用法であったことで、対話は終わります。 これらのメッセージの詳細は図4に示されます。
Alice Bob
| |
| SUBSCRIBE |
|------------------->|
Dialog Usage 1 | NOTIFY (F1) |
-start- -start- --------->|<-------------------|
| | | 200 SUBSCRIBE |
| | |<-------------------|
| | | 200 NOTIFY |
| | |------------------->|
| | | SUBSCRIBE |
| | |<-------------------|
| | Usage 2 | NOTIFY (F2) |
| | -start- -->|------------------->|
| | | | 200 SUBSCRIBE
| | | |------------------->|
| | | | 200 NOTIFY |
| | | |<-------------------|
| | | | : |
| | | | : |
| | | | (un)SUBSCRIBE (F3) |
| | | |------------------->|
| | | | 200 |
| | | |<-------------------|
| | | | NOTIFY |
| | | |<-------------------|
| | | | 200 |
| -end- ----------->|------------------->|
| | | : |
| | | : |
| | | NOTIFY (F4) |
| | | (Terminated) |
| | |------------------->|
| | | 200 |
-end- -end- -->|<-------------------|
| |
アリス・ボブ| | | 登録| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 対話用法1| (F1)に通知してください。| -スタート始め、---------->| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200 登録| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200に通知します。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 登録| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 用法2| (F2)に通知してください。| | | -始まってください-->|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 200 登録| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 200に通知します。| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| : | | | | | : | | | | | (不-、)(F3)を申し込んでください。| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 200 | | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| 通知してください。| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| 200 | | -終わり----------->|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| : | | | | : | | | | (F4)に通知してください。| | | | (終えられます) | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200 | -終わり-終わり、-、-->| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|
Figure 3
図3
Sparks Informational [Page 7] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[7ページ]のRFC5057をかきたてます。
Message Details (abridged to show only dialog or usage details)
F1
NOTIFY sip:aliceinstance@alice.example.com SIP/2.0
Event: presence
Subscription-State: active;expires=600
Call-ID: alicecallid1@alice.example.com
From: <sip:Bob@bob.example.com>;tag=bobtag2
To: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 100 NOTIFY
Contact: <sip:bobinstance@bob.example.com>
メッセージDetails(対話か利用明細だけを示しているために、要約される)F1 NOTIFY一口: aliceinstance@alice.example.com SIP/2.0Event: 存在Subscription-州: 能動態; =600Call-IDを吐き出します: alicecallid1@alice.example.com From: <一口: Bob@bob.example.com 、gt;、;=bobtag2To:にタグ付けをしてください <一口: Alice@alice.example.com 、gt;、; =alicetag2 CSeqにタグ付けをしてください: 100 接触に通知してください: <一口: bobinstance@bob.example.com 、gt。
F2
NOTIFY sip:bobinstance@bob.example.com SIP/2.0
Event: presence
Subscription-State: active;expires=1200
Call-ID: alicecallid1@alice.example.com
To: <sip:Bob@bob.example.com>;tag=bobtag2
From: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 500 NOTIFY
Contact: <sip:aliceinstance@alice.example.com>
F2 NOTIFY一口: bobinstance@bob.example.com SIP/2.0Event: 存在Subscription-州: 能動態; =1200Call-IDを吐き出します: alicecallid1@alice.example.com To: <一口: Bob@bob.example.com 、gt;、;=bobtag2From:にタグ付けをしてください <一口: Alice@alice.example.com 、gt;、; =alicetag2 CSeqにタグ付けをしてください: 500 接触に通知してください: <一口: aliceinstance@alice.example.com 、gt。
F3
SUBSCRIBE sip:bobinstance@bob.example.com SIP/2.0
Event: presence
Expires: 0
Call-ID: alicecallid1@alice.example.com
To: <sip:Bob@bob.example.com>;tag=bobtag2
From: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 501 SUBSCRIBE
Contact: <sip:aliceinstance@alice.example.com>
F3 SUBSCRIBE一口: bobinstance@bob.example.com SIP/2.0Event: 存在Expires: 0呼び出しID: alicecallid1@alice.example.com To: <一口: Bob@bob.example.com 、gt;、;=bobtag2From:にタグ付けをしてください <一口: Alice@alice.example.com 、gt;、; =alicetag2 CSeqにタグ付けをしてください: 501 接触を申し込んでください: <一口: aliceinstance@alice.example.com 、gt。
F4
NOTIFY sip:bobinstance@bob.example.com SIP/2.0
Event: presence
Subscription-State: terminated;reason=deactivated
Call-ID: alicecallid1@alice.example.com
To: <sip:Bob@bob.example.com>;tag=bobtag2
From: <sip:Alice@alice.example.com>;tag=alicetag2
CSeq: 502 NOTIFY
Contact: <sip:aliceinstance@alice.example.com>
F4 NOTIFY一口: bobinstance@bob.example.com SIP/2.0Event: 存在Subscription-州: 終わり、; 理由=はCall-IDを非活性化しました: alicecallid1@alice.example.com To: <一口: Bob@bob.example.com 、gt;、;=bobtag2From:にタグ付けをしてください <一口: Alice@alice.example.com 、gt;、; =alicetag2 CSeqにタグ付けをしてください: 502 接触に通知してください: <一口: aliceinstance@alice.example.com 、gt。
Figure 4
図4
Sparks Informational [Page 8] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[8ページ]のRFC5057をかきたてます。
4. Usage Creation and Destruction
4. 用法創造と破壊
Dialogs come into existence along with their first usage. Dialogs terminate when their last usage is destroyed. The messages that create and destroy usages vary per usage. This section provides a high-level categorization of those messages. The section does not attempt to explore the REGISTER pseudo-dialog.
対話はそれらの最初の用法と共に生まれます。 それらの最後の用法が破壊されるとき、対話は終わります。 用法を作成して、破壊するメッセージは用法単位で異なります。 このセクションはそれらのメッセージのハイレベルの分類を提供します。 セクションは、REGISTER疑似対話を探るのを試みません。
4.1. Invite Usages
4.1. 用法を招待してください。
Created by: non-100 provisional responses to INVITE; 200 response to
INVITE
以下によって作成されました。 INVITEへの非100の暫定的な応答。 200 INVITEへの応答
Destroyed by: 200 responses to BYE; certain failure responses to
INVITE, UPDATE, PRACK, INFO, or BYE; anything that destroys a
dialog and all its usages
以下によって破壊されました。 BYEへの200の応答。 INVITE、UPDATE、PRACK、INFO、またはBYEへのある失敗応答。 対話とそのすべての用法を破壊する何でも
4.2. Subscribe usages
4.2. 用法を申し込んでください。
Created by: 200 class responses to SUBSCRIBE; 200 class responses to
REFER; NOTIFY requests
以下によって作成されました。 200が応答を分類する、登録。 200 REFERへのクラス応答。 NOTIFY要求
Destroyed by: 200 class responses to NOTIFY-terminated; NOTIFY or
refresh-SUBSCRIBE request timeout; certain failure responses to
NOTIFY or SUBSCRIBE; expiration without refresh if network issues
prevent the terminal NOTIFY from arriving; anything that destroys
a dialog and all its usages
以下によって破壊されました。 200 NOTIFYによって終えられることへのクラス応答。 または、NOTIFY、リフレッシュ、-、登録、タイムアウトを要求してください。 または、NOTIFYへのある失敗応答、登録。 満了、ネットワーク問題が、端末のNOTIFYが到着するのを防ぐなら、リフレッシュしてください。 対話とそのすべての用法を破壊する何でも
5. Proper Handling of Multiple Usages
5. 複数の用法の適切な取り扱い
The examples in Section 3 show straightforward cases where it is fairly obvious when the dialog begins and ends. Unfortunately, there are many scenarios where such clarity is not present. For instance, in Figure 1, what would it mean if the response to the NOTIFY (F2) were a 481? Does that simply terminate the refer subscription, or does it destroy the entire dialog? This section explores the problem areas with multiple usages that have been identified to date.
セクション3の例はそれがかなり明白であるところに対話がいつ始まって、終わるかを簡単なケースに示します。 残念ながら、多くのシナリオがそのような明快が存在していないところにあります。 例えば、図1では、それはNOTIFY(F2)への応答が481であるなら何を意味するでしょうか? それが単に終わる、購読を参照してください、またはそれは全体の対話を破壊しますか? このセクションはこれまで特定された複数の用法で問題領域を探検します。
5.1. A Survey of the Effect of Failure Responses on Usages and Dialogs
5.1. 用法と対話への失敗応答の効果の調査
For this survey, consider a subscribe usage inside a dialog established with an invite usage. Unless stated otherwise, we'll discuss the effect on each usage and the dialog when a client issuing a NOTIFY inside the subscribe usage receives a failure response (such as a transferee issuing a NOTIFY to event refer). Further, unless otherwise stated, the conclusions apply to arbitrary multiple usages. This survey is written from the perspective of a client receiving the
この調査には、aが招待用法で確立された対話で用法を申し込むと考えてください。 用法を申し込んでください。中でNOTIFYを発行するクライアントであるときに、別の方法で述べられない場合、私たちが各用法と対話への効果について検討するつもりである、失敗応答(出来事にNOTIFYを発行すると参照される譲受人などの)を受けます。 さらに、別の方法で述べられない場合、結論は複数の用法を任意に当てはまります。 この調査はクライアント受信の見解から書かれます。
Sparks Informational [Page 9] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[9ページ]のRFC5057をかきたてます。
error response. The effect on dialogs and usages at the server issuing the response is the same.
誤り応答。 応答を発行するサーバにおける対話と用法への効果は同じです。
3xx responses: Redirection mid-dialog is not well understood in SIP,
but whatever effect it has impacts the entire dialog and all of
its usages equally. In our example scenario, both the
subscription and the invite usage would be redirected by this
single response.
3xx応答: リダイレクションの中間の対話はSIPでよく理解されていませんが、それにはどういった効果があるかが等しく用法の全体の対話とすべてに影響を与えます。 私たちの例のシナリオでは、購読と招待用法の両方がこのただ一つの応答で向け直されるでしょう。
For the failure responses with code 400 and greater, there are three common ways the failure can affect the transaction, usage, and dialog state.
失敗応答、400をコード化してください。そうすれば、よりすばらしくて、失敗が取引、用法、および対話状態に影響できる3つの一般的な方法があります。
Transaction Only The error affects only the transaction, not the
usage or dialog the transaction occurs in (beyond affecting the
local CSeq). Any other usage of the dialog is unaffected. The
error is a complaint about this transaction, not the usage or
dialog that the transaction occurs in.
取引Only、誤りは用法か対話ではなく、取引が起こる取引(地方のCSeqに影響することを超えた)だけに影響します。 対話のいかなる他の用法も影響を受けないです。 誤りは取引が起こる用法か対話ではなく、この取引に関する苦情です。
Destroys Usage The error destroys the usage, but not the dialog.
Any other usages sharing this dialog are not affected.
Usageを破壊する、誤りは対話ではなく、用法を破壊します。 この対話を共有するいかなる他の用法も影響を受けません。
Destroys Dialog The error destroys the dialog and all usages sharing
it.
Dialogを破壊する、誤りは対話とそれを共有するすべての用法を破壊します。
Table 1 and Table 2 display how the various codes affect transaction, usage, or dialog state. Response code specific comments or exceptions follow the table.
テーブル1とTable2は様々なコードがどう取引、用法、または対話状態に影響するかを表示します。 応答のコードの特定のコメントか例外がテーブルに続きます。
+----------------------+----------------+-----------------+
| Transaction Only | Destroys Usage | Destroys Dialog |
+----------------------+----------------+-----------------+
| 400 (or unknown 4xx) | 405, 480 | 404, 410, 416 |
| 401, 402, 403, 406 | 481, 489 | 482, 483 |
| 407, 408, 412-415 | 501 | 484, 485 |
| 417, 420, 421, 422 | | 502, 604 |
| 423, 428, 429 | | |
| 436-438, 486, 487 | | |
| 488, 491, 493, 494 | | |
| 500 (or unknown 5xx) | | |
| 503, 504, 505 | | |
| 513, 580 | | |
| 600 (or unknown 6xx) | | |
| 603, 606 | | |
+----------------------+----------------+-----------------+
+----------------------+----------------+-----------------+ | 取引専用| 用法を破壊します。| 対話を破壊します。| +----------------------+----------------+-----------------+ | 400(または、未知の4xx)| 405, 480 | 404, 410, 416 | | 401, 402, 403, 406 | 481, 489 | 482, 483 | | 407, 408, 412-415 | 501 | 484, 485 | | 417, 420, 421, 422 | | 502, 604 | | 423, 428, 429 | | | | 436-438, 486, 487 | | | | 488, 491, 493, 494 | | | | 500(または、未知の5xx)| | | | 503, 504, 505 | | | | 513, 580 | | | | 600(または、未知の6xx)| | | | 603, 606 | | | +----------------------+----------------+-----------------+
Table 1
テーブル1
Sparks Informational [Page 10] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[10ページ]のRFC5057をかきたてます。
+---------+---------------------------------+-------------+-------+
| Code | Reason | Impact | Notes |
+---------+---------------------------------+-------------+-------+
| 400/4xx | Bad Request | Transaction | |
| 401 | Unauthorized | Transaction | |
| 402 | Payment Required | Transaction | (1) |
| 403 | Forbidden | Transaction | |
| 404 | Not Found | Dialog | (2) |
| 405 | Method Not Allowed | Usage | (3) |
| 406 | Not Acceptable | Transaction | |
| 407 | Proxy Authentication Required | Transaction | |
| 408 | Request Timeout | Transaction | (4) |
| 410 | Gone | Dialog | (2) |
| 412 | Conditional Request Failed | Transaction | |
| 413 | Request Entity Too Large | Transaction | |
| 414 | Request-URI Too Long | Transaction | |
| 415 | Unsupported Media Type | Transaction | |
| 416 | Unsupported URI Scheme | Dialog | (2) |
| 417 | Unknown Resource-Priority | Transaction | |
| 420 | Bad Extension | Transaction | |
| 421 | Extension Required | Transaction | |
| 422 | Session Interval Too Small | Transaction | (5) |
| 423 | Interval Too Brief | Transaction | |
| 428 | Use Identity Header | Transaction | |
| 429 | Provide Referrer Identity | Transaction | (6) |
| 436 | Bad Identity-Info | Transaction | |
| 437 | Unsupported Certificate | Transaction | |
| 438 | Invalid Identity Header | Transaction | |
| 480 | Temporarily Unavailable | Usage | (7) |
| 481 | Call/Transaction Does Not Exist | Usage | (8) |
| 482 | Loop Detected | Dialog | (9) |
| 483 | Too Many Hops | Dialog | (10) |
| 484 | Address Incomplete | Dialog | (2) |
| 485 | Ambiguous | Dialog | (2) |
| 486 | Busy Here | Transaction | (11) |
| 487 | Request Terminated | Transaction | |
| 488 | Not Acceptable Here | Transaction | |
| 489 | Bad Event | Usage | (12) |
| 491 | Request Pending | Transaction | |
| 493 | Undecipherable | Transaction | |
| 494 | Security Agreement Required | Transaction | |
| 500/5xx | Server Internal Error | Transaction | (13) |
| 501 | Not Implemented | Usage | (3) |
| 502 | Bad Gateway | Dialog | (14) |
| 503 | Service Unavailable | Transaction | (15) |
| 504 | Server Time-Out | Transaction | (16) |
| 505 | Version Not Supported | Transaction | |
| 513 | Message Too Large | Transaction | |
+---------+---------------------------------+-------------+-------+ | コード| 理由| 衝撃| 注意| +---------+---------------------------------+-------------+-------+ | 400/4xx| 悪い要求| 取引| | | 401 | 権限のない| 取引| | | 402 | 支払いが必要です。| 取引| (1) | | 403 | 禁じられます。| 取引| | | 404 | 見つけられません。| 対話| (2) | | 405 | 許容されなかった方法| 用法| (3) | | 406 | 許容できない| 取引| | | 407 | プロキシ認証が必要です。| 取引| | | 408 | タイムアウトを要求してください。| 取引| (4) | | 410 | 行きます。| 対話| (2) | | 412 | 条件付き要求は失敗しました。| 取引| | | 413 | 大き過ぎる状態で実体を要求してください。| 取引| | | 414 | 要求URIも長さ| 取引| | | 415 | サポートされないメディアタイプ| 取引| | | 416 | サポートされないURI計画| 対話| (2) | | 417 | 未知のリソース優先権| 取引| | | 420 | 悪い拡大| 取引| | | 421 | 拡大が必要です。| 取引| | | 422 | セッション間隔、も小ささ| 取引| (5) | | 423 | 間隔も事情を知らせます。| 取引| | | 428 | アイデンティティヘッダーを使用してください。| 取引| | | 429 | リファラーのアイデンティティを提供してください。| 取引| (6) | | 436 | 悪いアイデンティティインフォメーション| 取引| | | 437 | サポートされない証明書| 取引| | | 438 | 無効のアイデンティティヘッダー| 取引| | | 480 | 一時入手できません。| 用法| (7) | | 481 | 呼び出し/取引は存在していません。| 用法| (8) | | 482 | 検出された輪| 対話| (9) | | 483 | あまりに多くのホップ| 対話| (10) | | 484 | アドレス不完全です。| 対話| (2) | | 485 | あいまい| 対話| (2) | | 486 | ここで、忙しいです。| 取引| (11) | | 487 | 要求は終わりました。| 取引| | | 488 | ここで、許容できません。| 取引| | | 489 | 悪い出来事| 用法| (12) | | 491 | 未定の要求| 取引| | | 493 | Undecipherable| 取引| | | 494 | 担保契約が必要です。| 取引| | | 500/5xx| サーバ内部エラー| 取引| (13) | | 501 | 実行されません。| 用法| (3) | | 502 | 悪いゲートウェイ| 対話| (14) | | 503 | 入手できないサービス| 取引| (15) | | 504 | サーバタイムアウト| 取引| (16) | | 505 | 支持されなかったバージョン| 取引| | | 513 | また、多、を通信させてください。| 取引| |
Sparks Informational [Page 11] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[11ページ]のRFC5057をかきたてます。
| 580 | Precondition Failure | Transaction | |
| 600/6xx | Busy Everywhere | Transaction | (17) |
| 603 | Decline | Transaction | |
| 604 | Does Not Exist Anywhere | Dialog | (2) |
| 606 | Not Acceptable | Transaction | |
+---------+---------------------------------+-------------+-------+
| 580 | 前提条件失敗| 取引| | | 600/6xx| いたる所では、忙しいです。| 取引| (17) | | 603 | 衰退| 取引| | | 604 | 何処にも、存在していません。| 対話| (2) | | 606 | 許容できない| 取引| | +---------+---------------------------------+-------------+-------+
Table 2
テーブル2
(1) 402 Payment Required: This is a reserved response code. If
encountered, it should be treated as an unrecognized 4xx.
(1) 402支払いが必要です: これは予約された応答コードです。 遭遇するなら、それは認識されていない4xxとして扱われるべきです。
(2) 404 Not Found:
(2) 404は以下を設立しません。
410 Gone:
410 過ぎ去る:
416 Unsupported URI Scheme:
416のサポートされないURI計画:
484 Address Incomplete:
484 アドレス不完全:
485 Ambiguous:
485 あいまい:
604 Does Not Exist Anywhere:
604 何処にも、存在していません:
The Request-URI that is being rejected is the remote target set by
the Contact provided by the peer. Getting this response means
that something has gone fundamentally wrong with the dialog state.
拒絶されているRequest-URIは同輩によって提供されたContactによって設定されたリモート目標です。 この応答を得るのは、対話状態が何かに基本的にうまくいっていないことを意味します。
(3) 405 Method Not Allowed:
(3)405方法は許容しませんでした:
501 Not Implemented:
501は実行しませんでした:
Either of these responses would be aberrant in our example
scenario since support for the NOTIFY method is required by the
usage. In this case, the UA knows the condition is unrecoverable
and should stop sending NOTIFYs on the usage. Any refresh
subscriptions should be rejected. In general, these errors will
affect at most the usage. If the request was not integral to the
usage (it used an unknown method, or was an INFO inside an INVITE
usage, for example), only the transaction will be affected.
NOTIFY方法のサポートが用法によって必要とされるので、これらの応答のどちらかが私たちの例のシナリオで常軌をはずしているでしょう。 この場合、UAは、状態が復しないのを知って、用法でNOTIFYsを送るのを止めるはずです。 いずれも購読をリフレッシュします。拒絶されるべきです。 一般に、これらの誤りは用法に高々影響するでしょう。 要求が用法に不可欠でなかったなら(例えば、それは、未知の方法を使用するか、またはINVITE用法でINFOでした)、取引だけが影響を受けるでしょう。
(4) 408 Request Timeout: Receiving a 408 will have the same effect
on usages and dialogs as a real transaction timeout as described
in Section 5.2.
(4) 408はタイムアウトを要求します: 408を受け取ると、同じ効果はセクション5.2で説明される実物取引タイムアウトとして用法と対話に持たれるでしょう。
Sparks Informational [Page 12] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[12ページ]のRFC5057をかきたてます。
(5) 422 Session Interval Too Small: This response does not make
sense for any mid-usage request. If it is received, an element in
the path of the request is violating protocol, and the recipient
should treat this as it would an unknown 4xx response.
(5) 422セッション間隔、も小さい: この応答はどんな中間の用法要求のためにも理解できません。 それが受け取られているなら、要求の経路の要素はプロトコルに違反しています、そして、未知の4xx応答を扱うように受取人はこれを扱うべきです。
(6) 429 Provide Referrer Identity: This response won't be returned
to a NOTIFY as in our example scenario, but when it is returned to
a REFER, it is objecting only to the REFER request itself.
(6) 429はリファラーのアイデンティティを提供します: 私たちの例のシナリオにもかかわらず、それをREFERに返す時この応答をNOTIFYに返さないでしょう、とそれはREFER要求自体だけに反対しています。
(7) 480 Temporarily Unavailable: RFC 3261 is unclear on what this
response means for mid-usage requests. Future updates to that
specification are expected to clarify that this response affects
only the usage in which the request occurs. No other usages are
affected. If the response included a Retry-After header field,
further requests in that usage should not be sent until the
indicated time has past. Requests in other usages may still be
sent at any time.
(7) 一時入手できない480: RFC3261はこの応答が中間の用法要求のために意味することに不明瞭です。 その仕様への将来のアップデートはそれをはっきりさせると予想されて、この応答が要求が現れる用法だけに影響するということです。 他のどんな用法も影響を受けません。 応答が後のRetryヘッダーフィールドを含んでいるなら、示された時間には過去があるまで、その用法によるさらなる要求を送らないでしょうに。 いつでも、まだ他の用法による要求を送るかもしれません。
(8) 481 Call/Transaction Does Not Exist: This response indicates
that the peer has lost its copy of the dialog usage state. The
dialog itself should not be destroyed unless this was the last
usage.
(8) 481呼び出し/取引は存在していません: この応答は、同輩が対話用法状態のコピーをなくしたのを示します。 これが最後の用法でないなら対話自体を破壊しないでしょうに。
The effects of a 481 on a dialog and its usages are the most
ambiguous of any final response. There are implementations that
have chosen the meaning recommended here, and others that destroy
the entire dialog without regard to the number of outstanding
usages. Going forward with this clarification will allow those
deployed implementations that assumed only the usage was destroyed
to work with a wider number of implementations. Existing
implementations that destroy all other usages in the dialog will
continue to function as they do now, except that peers following
the recommendation will attempt to do things with the other usages
and this element will return 481s for each of them until they are
all gone. However, the necessary clarification to RFC 3261 needs
to make it very clear that the ability to terminate usages
independently from the overall dialog using a 481 is not
justification for designing new applications that count on
multiple usages in a dialog.
対話とその用法への481の効果はどんな最終的な応答も最もあいまいです。 ここのお勧めの意味を選んだ実現、および関係なしで傑出している用法の数に全体の対話を破壊する他のものがいます。 この明確化と共に進んでいるのに、用法だけが破壊されたと仮定したそれらの配備された実現が、より広い数の実現で働くでしょう。 対話における他のすべての用法を破壊する既存の実現は、現在するように機能し続けるでしょう、推薦の後をつける同輩が、他の用法でことをするのを試みて、それらがすべてなくなるまでこの要素がそれぞれのそれらのために481を返すのを除いて。 しかしながら、RFC3261への必要な明確化は、総合的な対話から481を使用することで用法を独自に終える能力が対話における複数の用法を頼りにする新しいアプリケーションを設計するための正当化でないことを非常に明確にする必要があります。
The 481 response to a CANCEL request has to be treated
differently. For CANCEL, a 481 means the UAS can't find a
matching transaction. A 481 response to a CANCEL affects only the
CANCEL transaction. The usage associated with the INVITE is not
affected.
キャンセル要求への481応答は異なって扱われなければなりません。 キャンセル、UASがマッチング取引を見つけることができない481の手段のために。 キャンセルへの481応答はキャンセル取引だけに影響します。 INVITEに関連している用法は影響を受けません。
Sparks Informational [Page 13] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[13ページ]のRFC5057をかきたてます。
(9) 482 Loop Detected: This response is aberrant mid-dialog. It
will only occur if the Record-Route header field were improperly
constructed by the proxies involved in setting up the dialog's
initial usage, or if a mid-dialog request forks and merges (which
should never happen). Future requests using this dialog state
will also fail.
(9)482輪は検出しました: この応答は常軌をはずしている中間の対話です。 中間の対話要求がRecord-ルートヘッダーフィールドが対話の初期の用法をセットアップするのにかかわるプロキシによって不適切に構成されたか、分岐して、または合併する場合にだけ(決して起こるべきではありません)、それは起こるでしょう。 また、この対話状態を使用する今後の要求が失敗するでしょう。
An edge condition exists during RFC 3263 failover at the
element sending a request, where the request effectively forks
to multiple destinations from the client. Some implementations
increase risk entering this edge condition by trying the next
potential location as determined by RFC 3263 very rapidly if
the first does not immediately respond. In any situation where
a client sends the same request to more than one endpoint, it
must be prepared to receive a response from each branch (and
should choose a "best" response to act on following the same
guidelines as a forking proxy). In this particular race
condition, if multiple branches respond, all but one will most
likely return a 482 Merged Request. The client should select
the remaining non-482 response as the "best" response.
周辺条件は、3263年のRFCフェイルオーバーの間、要求(事実上、要求はクライアントから複数の目的地に分岐する)を送りながら、要素に存在しています。 いくつかの実現が1番目がすぐに応じないならRFC3263によって非常に急速に決定されるように次の潜在的位置を試みることによってこの周辺条件に入る危険を増加させます。 クライアントが同じ要求を1つ以上の終点に送るどんな状況でも、各ブランチ(そして、同じ次のガイドラインに影響する分岐しているプロキシとしての「最も良い」応答を選ぶべきである)から応答を受けるのは準備していなければなりません。 この特定の競合条件では、複数のブランチが応じると、ほとんど1つはたぶん482Merged Requestを返すでしょう。 クライアントは「最も良い」応答として残っている非482応答を選定するべきです。
(10) 483 Too Many Hops: Similar to 482, receiving this mid-dialog is
aberrant. Unlike 482, recovery may be possible by increasing Max-
Forwards (assuming that the requester did something strange like
using a smaller value for Max-Forwards in mid-dialog requests than
it used for an initial request). If the request isn't tried with
an increased Max-Forwards, then the agent should follow the
Destroy Dialog actions.
(10) 多く過ぎるのが飛び越す483: 482と同様であることで、この中間の対話を受けるのは常軌をはずしています。 482と異なって、回復はマックスを前方(リクエスタが初期の要求に使用したより前方へマックスに中間の対話要求でさらに小さい値を使用するように何か奇妙なことをしたと仮定する)に増加させることによって、可能であるかもしれません。 要求が前方へ増加するマックスと共に試みられないなら、エージェントはDestroy Dialog動作の後をつけるべきです。
(11) 486 Busy Here: This response is nonsensical in our example
scenario, or in any scenario where this response comes inside an
established usage. If it occurs in that context, it should be
treated as an unknown 4xx response.
(11) 486はここで以下と忙しくします。 この応答は私たちの例のシナリオ、またはこの応答が確立した用法で来るどんなシナリオでも無意味です。 その文脈に起こるなら、それは未知の4xx応答として扱われるべきです。
(12) 489 Bad Event: In our example scenario, [5] declares that the
subscription usage in which the NOTIFY is sent is terminated.
This response is only valid in the context of SUBSCRIBE and
NOTIFY. UAC behavior for receiving this response to other methods
is not specified, but treating it as an unknown 4xx is a
reasonable practice.
(12) 489の悪い出来事: 私たちの例のシナリオでは、[5]は、NOTIFYが送られる購読用法が終えられると宣言します。 この応答が単に文脈で有効である、登録、そして、NOTIFY。 他の方法へのこの応答を受けるためのUACの振舞いは指定されませんが、未知の4xxとしてそれを扱うのは、妥当な習慣です。
(13) 500 and 5xx unrecognized responses: If the response contains a
Retry-After header field value, the server thinks the condition is
temporary, and the request can be retried after the indicated
interval. If the response does not contain a Retry-After header
field value, the UA may decide to retry after an interval of its
choosing or attempt to gracefully terminate the usage. Whether or
not to terminate other usages depends on the application. If the
(13)500と5xxの認識されていない応答: 応答が後のRetryヘッダーフィールド価値を含んでいるなら、サーバは、状態が一時的であると考えます、そして、示された間隔の後に要求は再試行できます。 応答が後のRetryヘッダーフィールド価値を含んでいないなら、UAは、選ぶことぶりに再試行するか、または優雅に用法を終えるのを試みると決めるかもしれません。 他の用法を終えるかどうかがアプリケーションによります。 the
Sparks Informational [Page 14] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[14ページ]のRFC5057をかきたてます。
UA receives a 500 (or unrecognized 5xx) in response to an attempt
to gracefully terminate this usage, it can treat this usage as
terminated. If this is the last usage sharing the dialog, the
dialog is also terminated.
UAは優雅にこの用法を終える試みに対応して500(または、認識されていない5xx)を受け取って、それは終えられるとしてこの用法を扱うことができます。 また、これが対話を共有する最後の用法であるなら、対話は終えられます。
(14) 502 Bad Gateway: This response is aberrant mid-dialog. It will
only occur if the Record-Route header field were improperly
constructed by the proxies involved in setting up the dialog's
initial usage. Future requests using this dialog state will also
fail.
(14) 502の悪いゲートウェイ: この応答は常軌をはずしている中間の対話です。 Record-ルートヘッダーフィールドが対話の初期の用法をセットアップするのにかかわるプロキシによって不適切に構成された場合にだけ、それは起こるでしょう。 また、この対話状態を使用する今後の要求が失敗するでしょう。
(15) 503 Service Unavailable: As per [6], the logic handling
locating SIP servers for transactions may handle 503 requests
(effectively, sequentially forking at the endpoint based on DNS
results). If this process does not yield a better response, a 503
may be returned to the transaction user. Like a 500 response, the
error is a complaint about this transaction, not the usage.
Because this response occurred in the context of an established
usage (hence an existing dialog), the route-set has already been
formed and any opportunity to try alternate servers (as
recommended in [1]) has been exhausted by the RFC3263 logic.
(15) 入手できない503サービス: [6]に従って、取引のためのSIPサーバの場所を見つける論理取り扱いは503の要求(DNS結果に基づく終点で事実上、連続して分岐する)を扱うかもしれません。 この過程が、より良い応答をもたらさないなら、取引ユーザに503を返すかもしれません。 500応答のように、誤りは用法ではなく、この取引に関する苦情です。 この応答が確立した用法(したがって、既存の対話)の文脈に起こったので、ルートセットは、既に形成されていて交互のサーバを試みるあらゆる機会です。(中で推薦されるように、[1])はRFC3263論理によって消耗させられました。
(16) 504 Server Time-out: It is not obvious under what circumstances
this response would be returned to a request in an existing
dialog.
(16) 504サーバタイムアウト: どんな状況で、既存の対話における要求にこの応答を返すのは明白でないか。
(17) 600 and 6xx unrecognized responses: Unlike 400 Bad Request, a
600 response code says something about the recipient user, not the
request that was made. This end user is stating an unwillingness
to communicate. If the response contains a Retry-After header
field value, the user is indicating willingness to communicate
later and the request can be retried after the indicated interval.
This usage, and any other usages sharing the dialog are
unaffected. If the response does not contain a Retry-After header
field value, the UA may decide to retry after an interval of its
choosing or attempt to gracefully terminate the usage. Whether or
not to terminate other usages depends on the application. If the
UA receives a 600 (or unrecognized 6xx) in response to an attempt
to gracefully terminate this usage, it can treat this usage as
terminated. If this is the last usage sharing the dialog, the
dialog is also terminated.
(17)600と6xxの認識されていない応答: 400Bad Requestと異なって、600応答コードはされた要求ではなく、受取人ユーザに関して何かを言います。 このエンドユーザは、交信するために気がすすまないことを述べています。 応答が後のRetryヘッダーフィールド価値を含んでいるなら、ユーザは、示された間隔の後に後で交信する意欲と要求を再試行できるのを示しています。 この用法、および対話を共有するいかなる他の用法もそうです。影響を受けない。 応答が後のRetryヘッダーフィールド価値を含んでいないなら、UAは、選ぶことぶりに再試行するか、または優雅に用法を終えるのを試みると決めるかもしれません。 他の用法を終えるかどうかがアプリケーションによります。 UAが優雅にこの用法を終える試みに対応して600(または、認識されていない6xx)を受け取るなら、それは終えられるとしてこの用法を扱うことができます。 また、これが対話を共有する最後の用法であるなら、対話は終えられます。
5.2. Transaction Timeouts
5.2. 取引タイムアウト
[1] states that a UAC should terminate a dialog (by sending a BYE) if no response is received for a request sent within a dialog. This recommendation should have been limited to the invite usage instead of the whole dialog. [5] states that a timeout for a NOTIFY removes a
[1]は、対話の中で送られた要求のために応答を全く受けないならUACが対話(BYEを送るのによる)を終えるはずであると述べます。 この推薦は全体の対話の代わりに招待用法に制限されるべきでした。 [5]は、NOTIFYのためのタイムアウトがaを取り除くと述べます。
Sparks Informational [Page 15] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[15ページ]のRFC5057をかきたてます。
subscription, but a SUBSCRIBE that fails with anything other than a 481 does not. Given these statements, it is unclear whether a refresh SUBSCRIBE issued in a dialog shared with an invite usage destroys either usage or the dialog if it times out.
登録はしかし、購読、481以外の何でも失敗するそうしません。 対話が招待用法と共有した発行されたコネはそれであるなら用法か対話のどちらかを破壊します。これらの声明を考えて、aがリフレッシュするかどうかが、不明瞭である、登録、回のアウト。
Generally, a transaction timeout should affect only the usage in which the transaction occurred. Other uses sharing the dialog should not be affected. In the worst case of timeout due to total transport failure, it may require multiple failed messages to remove all usages from a dialog (at least one per usage).
一般に、取引タイムアウトは取引が起こった用法だけに影響するべきです。 対話を共有する他の用途は影響を受けるべきではありません。 総輸送失敗による最悪の場合にはタイムアウトでは、それは対話(少なくとも1用法あたり1つ)からすべての用法を取り除く複数の失敗したメッセージを必要とするかもしれません。
There are some mid-dialog messages that never belong to any usage. If they timeout, they will have no effect on the dialog or its usages.
どんな用法にも決して属さないいくつかの中間の対話メッセージがあります。 それらである、タイムアウト、それらは対話かその用法で効き目がないでしょう。
5.3. Matching Requests to Usages
5.3. 用法に要求に合っています。
For many mid-dialog requests, identifying the usage they belong to is obvious. A dialog can have at most one invite usage, so any INVITE, UPDATE, PRACK, ACK, CANCEL, BYE, or INFO requests belong to it. The usage (i.e. the particular subscription) SUBSCRIBE, NOTIFY, and REFER requests belong to can be determined from the Event header field of the request. REGISTER requests within a (pseudo)-dialog belong to the registration usage. (As mentioned before, implementations aren't mixing registration usages with other usages, so this document isn't exploring the consequences of that bad behavior).
多くの中間の対話要求において、それらが属す用法を特定するのは明白です。 対話は、最も1つで用法を招待するので、それに属させることができますいずれもINVITE、UPDATE、PRACK、ACK、キャンセル、BYE、またはINFOが、要求する。 登録、Eventヘッダーフィールドから決定して、要求がであることができる要求を属させる用法(すなわち、特定の購読)のNOTIFY、およびREFER。 (疑似な)対話の中のREGISTER要求は登録用法に属します。 (実現が以前言及されるように登録用法を他の用法に混ぜていないので、このドキュメントはその悪い振舞いの結果について調査していません。)
According to [1], "an OPTIONS request received within a dialog generates a 200 OK response that is identical to one constructed outside a dialog and does not have any impact on that dialog". Thus, OPTIONS does not belong to any usage. Only those failures discussed in Section 5.1 and Section 5.2 that destroy entire dialogs will have any effect on the usages sharing the dialog with a failed OPTIONS request.
[1]によると、「対話の中に受け取られたOPTIONS要求は、対話の外で構成された1つと同じ200OK応答を発生させて、その対話にどんな影響力も持っていません」。 したがって、OPTIONSはどんな用法にも属しません。 全体の対話を破壊するセクション5.1とセクション5.2で議論したそれらの失敗だけが、失敗したOPTIONS要求と対話を共有しながら、用法にどんな効果も持つでしょう。
MESSAGE requests are discouraged inside a dialog. Implementations are restricted from creating a usage for the purpose of carrying a sequence of MESSAGE requests (though some implementations use it that way, against the standard recommendation). A failed MESSAGE occurring inside an existing dialog will have similar effects on the dialog and its usages as a failed OPTIONS request.
MESSAGE要求は対話でお勧めできないです。 実現は、MESSAGE要求の系列を運ぶ目的のために用法を作成するので、制限されます(いくつかの実現がそのように標準の推薦に対してそれを使用しますが)。 失敗したOPTIONSが要求するように既存の対話で起こる失敗したMESSAGEは対話とその用法に同様の影響を与えるでしょう。
Mid-dialog requests with unknown methods cannot be matched with a usage. Servers will return a failure response (likely a 501). The effect on the dialog and its usages at either the client or the server should be similar to that of a failed OPTIONS request.
未知の方法がある中間の対話要求に用法に合うことができません。 サーバは失敗応答(ありそうなa501)を返すでしょう。 対話への効果とクライアントかサーバのどちらかにおけるその用法は失敗したOPTIONS要求のものと同様であるべきです。
Sparks Informational [Page 16] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[16ページ]のRFC5057をかきたてます。
These guidelines for matching messages to usages (or determining there is no usage) apply equally when acting as a UAS, a UAC, or any third party tracking usage and dialog state by inspecting all messages between two endpoints.
どんなUASや、UACや、第三者の追跡用法と対話も2つの終点の間のすべてのメッセージを点検することによって述べるように行動するとき、用法(用法が全くないことを決定して)にメッセージを合わせるためのこれらのガイドラインは等しく適用されます。
5.4. Target Refresh Requests
5.4. 目標は要求をリフレッシュします。
Target refresh requests update the remote target of a dialog when they are successfully processed. The currently defined target refresh requests are INVITE, UPDATE, SUBSCRIBE, NOTIFY, and REFER [7]).
それらが首尾よく処理されるとき、目標はリモートが狙う対話の要求最新版をリフレッシュします。 現在定義された目標はリフレッシュします。要求は、INVITEと、UPDATEと、登録、NOTIFYと、REFER[7])です。
The remote target is part of the dialog state. When a target refresh request affects it, it affects it for ALL usages sharing that dialog. If a subscription and invite usage are sharing a dialog, sending a refresh SUBSCRIBE with a different contact will cause reINVITEs from the peer to go to that different contact.
リモート目標は対話状態の一部です。 目標がリフレッシュするとき、要求はそれに影響して、それはその対話を共有するすべての用法のためにそれに影響します。 購読と招待用法が対話を共有することであるなら、aを送って、その異なった接触に行くために同輩から異なった接触で登録、意志の原因reINVITEsをリフレッシュしてください。
A UAS will only update the remote target if it sends a 200 class response to a target refresh request. A UAC will only update the remote target if it receives a 200 class response to a target refresh request. Again, any update to a dialog's remote target affects all usages of that dialog.
目標への応答がリフレッシュする200のクラスに要求を送る場合にだけ、UASはリモート目標をアップデートするでしょう。 A UACは目標への応答がリフレッシュする200のクラスを受けるならリモートが狙うアップデートだけに要求を望んでいます。 一方、対話のリモート目標へのどんなアップデートもその対話のすべての用法に影響します。
There is known ambiguity around the effects of provisional responses on remote targets that a future specification will attempt to clarify. Furthermore, because the remote target is part of the dialog state, not any usage state, there is ambiguity in having target refresh requests in progress simultaneously on multiple usages in the same dialog. Implementation designers should consider these conditions with care.
将来の仕様が、はっきりさせるのを試みるというリモート目標への暫定的な応答の効果の周りのあいまいさは知られています。 その上、リモート目標がどんな用法状態ではなく、対話状態の一部であるのでも、目標に同時に複数の用法で進行中の要求をリフレッシュさせるのにおいてあいまいさが同じ対話にはあります。 実現デザイナーは慎重にこれらの状態を考えるべきです。
5.5. Refreshing and Terminating Usages
5.5. 用法をリフレッシュして、終えます。
Subscription and registration usages expire over time and must be refreshed (with a refresh SUBSCRIBE, for example). This expiration is usage state, not dialog state. If several subscriptions share a dialog, refreshing one of them has no effect on the expiration of the others.
購読と登録用法は時間がたつにつれて、期限が切れて、リフレッシュしなければならない、(aで、リフレッシュしてください、登録、例えば、) この満了は対話状態ではなく、用法状態です。 いくつかの購読が対話を共有するなら、それらの壮快な1つは他のものの満了のときに効き目がありません。
Normal termination of a usage has no effect on other usages sharing the same dialog. For instance, terminating a subscription with a NOTIFY/Subscription-State: terminated will not terminate an invite usage sharing its dialog. Likewise, ending an invite usage with a BYE does not terminate any active Event: refer subscriptions established on that dialog.
用法の正常終了は、同じ対話を共有しながら、他の用法で効き目がありません。 例えば、NOTIFY/で購読を終えて、以下を購読して述べてください。 終えられて、対話を共有する招待用法を終えないために望んでください。 同様に、BYEと共に招待用法を終わらせるのは少しのアクティブなEventも終えません: その対話で確立された購読を参照してください。
Sparks Informational [Page 17] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[17ページ]のRFC5057をかきたてます。
5.6. Refusing New Usages
5.6. 新しい用法を拒否します。
As the survey of the effect of failure responses shows, care must be taken when refusing a new usage inside an existing dialog. Choosing the wrong response code will terminate the dialog and all of its usages. Generally, returning a 603 Decline is the safest way to refuse a new usage.
既存の対話で新しい用法を拒否するとき、失敗応答の効果の調査が示すように、注意しなければなりません。 間違った応答コードを選ぶと、用法の対話とすべてが終えられるでしょう。 一般に、603Declineを返すのは、新しい用法を拒否する最も安全な方法です。
5.7. Replacing Usages
5.7. 用法を置き換えます。
[8] defines a mechanism through which one usage can replace another. It can be used, for example, to associate the two dialogs in which a transfer target is involved during an attended transfer. It is written using the term "dialog", but its intent was only to affect the invite usage of the dialog it targets. Any other usages inside that dialog are unaffected. For some applications, the other usages may no longer make sense, and the application may terminate them as well.
[8]は用法が別のものを取り替えることができるメカニズムを定義します。 例えば、転送目標が出席された転送の間にかかわる2つの対話を関連づけるのにそれを使用できます。 それは「対話」という用語を使用することで書かれていますが、意図は単にそれが狙う対話の招待用法に影響することでした。 その対話におけるいかなる他の用法も影響を受けないです。 いくつかのアプリケーションのために、他の用法はもう理解できないかもしれません、そして、また、アプリケーションはそれらを終えるかもしれません。
However, the interactions between Replaces and multiple dialog usages have not been well explored. More discussion of this topic is needed. Implementers should avoid this scenario completely.
しかしながら、Replacesと複数の対話用法との相互作用は上手に探検されていません。 この話題の、より多くの議論が必要です。 Implementersはこのシナリオを完全に避けるはずです。
6. Avoiding Multiple Usages
6. 複数の用法を避けます。
Processing multiple usages correctly is not completely understood. What is understood is difficult to implement and is very likely to lead to interoperability problems. The best way to avoid the trouble that comes with such complexity is to avoid it altogether.
複数の用法を処理するのは正しく完全に理解されているというわけではありません。 理解されていることは、実行するのが難しく、相互運用性問題を非常に引き起こしそうです。そのような複雑さと共に来る問題を避ける最も良い方法はそれを全体で避けることです。
When designing new applications or features that use SIP dialogs, do not require endpoints to construct multiple usages to participate in the application or use the feature. When designing endpoints, address the existing multiple usage scenarios as best as possible. Outside those scenarios, if a peer attempts to create a second usage inside a dialog, refuse it.
SIP対話を使用する新しいアプリケーションか特徴を設計するときには、アプリケーションに参加するか、または特徴を使用するために複数の用法を構成するために終点を必要としないでください。 終点を設計するときには、存在複数の用法シナリオをできるだけ最もよく記述してください。 それらのシナリオの外では、同輩が、対話で2番目の用法を作成するのを試みるなら、それを拒否してください。
Unfortunately, there are existing applications, like transfer, that currently entail multiple usages, so the simple solution of "don't do it" will require some transitional work. This section looks at the pressures that led to these existing multiple usages and suggests alternatives.
残念ながら、転送のような現在複数の用法を伴う既存の利用があるので、「それをしないでください」の簡単な解決策はいくらかの過渡的な仕事を必要とするでしょう。 このセクションは、これらの存在複数の用法につながった圧力を調べて、代替手段を示します。
When executing a transfer, the transferor and transferee currently share an invite usage and a subscription usage within the dialog between them. This is a result of sending the REFER request within the dialog established by the invite usage. Implementations were led to this behavior by these primary problems:
現在転送を実行するとき、譲渡人と譲受人はそれらの間の対話の中で招待用法と購読用法を共有します。 これはREFERが招待用法で確立された対話の中で要求する発信の結果です。 実現はこれらの第一の問題によってこの振舞いに導かれました:
Sparks Informational [Page 18] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[18ページ]のRFC5057をかきたてます。
1. There was no way to ensure that a REFER on a new dialog would
reach the particular endpoint involved in a transfer. Many
factors, including details of implementations and changes in
proxy routing between an INVITE and a REFER could cause the REFER
to be sent to the wrong place. Sending the REFER down the
existing dialog ensured it got to the same endpoint with which
the dialog was established.
1. 新しい対話のREFERが転送にかかわる特定の終点に達するのを保証する方法が全くありませんでした。 INVITEとREFERの間のルーティングで間違った場所にREFERを送ることができたプロキシにおける実現と変化の細部を含む多くの要素。 既存の対話の下側にREFERを送るのは、対話が確立されたのと同じ終点に着いたのを確実にしました。
2. It was unclear how to associate an existing invite usage with a
REFER arriving on a new dialog, where it was completely obvious
what the association was when the REFER came on the invite
usage's dialog.
2. REFERがいつ招待用法の対話をついたかは、協会が何であったかが完全に明白であった新しい対話で到着するREFERに既存の招待用法を関連づける方法が不明瞭でした。
3. There were concerns with authorizing out-of-dialog REFERs. The
authorization policy for REFER in most implementations piggybacks
on the authorization policy for INVITE (which is, in most cases,
based simply on "I placed or answered this call").
3. 対話の外でREFERsを認可する関心がありました。 ほとんどの実現におけるREFERのための認可方針はINVITE(多くの場合、単に「私は、この電話にしたか、または答えたこと」に基づいている)のために認可方針で便乗します。
Globally Routable User Agent (UA) URIs (GRUUs) [9] have been defined specifically to address problem 1 by providing a URI that will reach one specific user-agent. The Target-Dialog header field [10] was created to address problems 2 and 3. This header field allows a request to indicate the dialog identifiers of some other dialog, providing association with the other dialog that can be used in an authorization decision.
グローバルに、Routable Userエージェント(UA)URI(GRUUs)[9]は、特に1人の特定のユーザエージェントに届くURIを提供することによってその問題1を訴えるために定義されました。 Target-対話ヘッダーフィールド[10]は、その問題2と3を訴えるために作成されました。 このヘッダーフィールドはある他の対話に関する対話識別子を示すために要求を認めます、認可決定に使用できるもう片方の対話を協会に提供して。
The Join [11] and Replaces [8] mechanisms can also be used to address problem 1. When using this technique, a new request is sent outside any dialog with the expectation that it will fork to possibly many endpoints, including the one we're interested in. This request contains a header field listing the dialog identifiers of a dialog in progress. Only the endpoint holding a dialog matching those identifiers will accept the request. The other endpoints the request may have forked to will respond with an error. This mechanism is reasonably robust, failing only when the routing logic for out-of- dialog requests changes such that the new request does not arrive at the endpoint holding the dialog of interest.
また、その問題1を訴えるのにJoin[11]とReplaces[8]メカニズムを使用できます。 このテクニックを使用するとき、それがことによると多くの終点に分岐させる期待と共にどんな対話の外でも新しい要求を送ります、私たちが興味を持っているものを含んでいて。 この要求は進行中の対話に関する対話識別子をリストアップするヘッダーフィールドを含んでいます。 それらの識別子に合っている対話を保持する終点だけが要請を受け入れるでしょう。 要求が分岐したかもしれない他の終点は誤りで応じるでしょう。 -このメカニズムが合理的に強健である、外のためのルーティング論理であるときにだけ、失敗して、対話では、要求が変化するので、新しい要求は興味がある対話を保持しながら、終点に到着しません。
The reachability aspects of using a GRUU to address problem 1 can be combined with the association-with-other-dialogs aspects of the Join/ Replaces and Target-Dialog mechanisms. A REFER request sent out-of- dialog can be sent towards a GRUU, and identify an existing dialog as part of the context the receiver should use. The Target-Dialog header field can be included in the REFER listing the dialog this REFER is associated with. Figure 5 sketches how this could be used to achieve transfer without reusing a dialog. For simplicity, the diagram and message details do not show the server at example.com
その問題1を訴えるのにGRUUを使用する可到達性局面は、Target-対話メカニズム他の対話とのJoin/の局面が取って代わる協会と出された対話はGRUUに向かって送ることができるというREFER要求に結合されて、既存の対話が受信機が使用するはずである文脈の一部であると認識できます。 このREFERが関連している対話を記載するREFERにTarget-対話ヘッダーフィールドを含むことができます。 図5は対話を再利用しないで転送を達成するのにどうこれを使用できたかをスケッチします。 簡単さのために、ダイヤグラムとメッセージの詳細はexample.comにサーバを示しません。
Sparks Informational [Page 19] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[19ページ]のRFC5057をかきたてます。
that will be involved in routing the GRUU. Refer to [9] for those details.
それはGRUUを発送するのにかかわるでしょう。 それらの詳細のための[9]を参照してください。
Alice Bob Carol
| | |
| F1 INVITE (Bob's AOR) | |
| Call-ID: (call-id one) | |
| Contact: (Alice's-GRUU) | |
|------------------------------->| |
| F2 200 OK | |
| To: <>;tag=totag1 | |
| From: <>;tag=fromtag1 | |
| Call-ID: (call-id one) | |
| Contact: (Bob's-GRUU) | |
|<-------------------------------| |
| ACK | |
|------------------------------->| |
| : | |
| (Bob places Alice on hold) | |
| : | F3 INVITE (Carol's AOR) |
| | Call-ID: (call-id two) |
| | Contact: (Bob's-GRUU) |
| |----------------------------->|
| | F4 200 OK |
| | To: <>;tag=totag2 |
| | From: <>;tag=fromtag2 |
| | Call-ID: (call-id two) |
| | Contact: (Carol's-GRUU) |
| |<-----------------------------|
| | ACK |
| |----------------------------->|
| | : |
| | (Bob places Carol on hold) |
| F5 REFER (Alice's-GRUU) | : |
| Call-ID: (call-id three) | |
| Refer-To: (Carol's-GRUU) | |
| Target-Dialog: (call-id one,totag1,fromtag1) |
| Contact: (Bob's-GRUU) | |
|<-------------------------------| |
| 202 Accepted | |
|------------------------------->| |
アリス・ボブ・キャロル| | | | F1は(ボブのAOR)を招待します。| | | 呼び出しID: (呼び出しイド1) | | | 接触: (アリスのもの-GRUU) | | |------------------------------->| | | F2 200OK| | | To: <>; タグ=totag1| | | From: <>; タグ=fromtag1| | | 呼び出しID: (呼び出しイド1) | | | 接触: (ボブのもの-GRUU) | | |<-------------------------------| | | ACK| | |------------------------------->| | | : | | | (ボブはアリスを保持に任命します) | | | : | F3は(キャロルのAOR)を招待します。| | | 呼び出しID: (呼び出しイド2) | | | 接触: (ボブのもの-GRUU) | | |----------------------------->| | | F4 200OK| | | To: <>; タグ=totag2| | | From: <>; タグ=fromtag2| | | 呼び出しID: (呼び出しイド2) | | | 接触: (キャロルのもの-GRUU) | | |<-----------------------------| | | ACK| | |----------------------------->| | | : | | | (ボブはキャロルを保持に任命します) | | F5は(アリスのもの-GRUU)を参照します。| : | | 呼び出しID: (呼び出しイド3) | | | To:を参照します。 (キャロルのもの-GRUU) | | | 目標対話: (呼び出しイド1、totag1、fromtag1) | | 接触: (ボブのもの-GRUU) | | |<-------------------------------| | | 202は受け入れました。| | |------------------------------->| |
Sparks Informational [Page 20] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[20ページ]のRFC5057をかきたてます。
| NOTIFY (Bob's-GRUU) | |
| Call-ID: (call-id three) | |
|------------------------------->| |
| 200 OK | |
|<-------------------------------| |
| | |
| F6 INVITE (Carol's-GRUU) |
| Call-ID: (call-id four) |
| Contact: (Alice's-GRUU) |
|-------------------------------------------------------------->|
| 200 OK |
| Contact: (Carol's-GRUU) |
|<--------------------------------------------------------------|
| ACK |
|-------------------------------------------------------------->|
| | |
| F7 NOTIFY (Bob's-GRUU) | |
| Call-ID: (call-id three) | |
|------------------------------->| |
| 200 OK | |
|<-------------------------------| |
| BYE (Alice's-GRUU) | |
| Call-ID: (call-id one) | |
|<-------------------------------| BYE (Carol's-GRUU) |
| | Call-ID: (call-id two) |
| 200 OK |----------------------------->|
|------------------------------->| 200 OK |
| |<-----------------------------|
| | |
| (ボブのもの-GRUU)に通知してください。| | | 呼び出しID: (呼び出しイド3) | | |------------------------------->| | | 200 OK| | |<-------------------------------| | | | | | F6は(キャロルのもの-GRUU)を招待します。| | 呼び出しID: (呼び出しイド4) | | 接触: (アリスのもの-GRUU) | |-------------------------------------------------------------->| | 200 OK| | 接触: (キャロルのもの-GRUU) | |<--------------------------------------------------------------| | ACK| |-------------------------------------------------------------->| | | | | F7は(ボブのもの-GRUU)に通知します。| | | 呼び出しID: (呼び出しイド3) | | |------------------------------->| | | 200 OK| | |<-------------------------------| | | さようなら(アリスのもの-GRUU)| | | 呼び出しID: (呼び出しイド1) | | |<-------------------------------| さようなら(キャロルのもの-GRUU)| | | 呼び出しID: (呼び出しイド2) | | 200 OK|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| |------------------------------->| 200 OK| | |<-----------------------------| | | |
Figure 5: Transfer without dialog reuse
図5: 対話再利用なしで移してください。
In message F1, Alice invites Bob indicating support for GRUUs (and offering a GRUU for herself):
メッセージF1では、アリスはGRUUsのサポートを示すボブを招待します(自分のためにGRUUを提供して):
Message F1 (abridged, detailing pertinent fields)
メッセージF1(適切な分野を詳しく述べて、要約されます)
INVITE sip:bob@example.com SIP/2.0
Call-ID: 13jfdwer230jsdw@alice.example.com
Supported: gruu
Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
INVITE一口: bob@example.com SIP/2.0Call-ID: 13jfdwer230jsdw@alice.example.com は支持しました: gruu Contact: <一口: alice@example.com;gr はつぼ: uuidと等しいです:(アリスのUAのビット)>。
Sparks Informational [Page 21] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[21ページ]のRFC5057をかきたてます。
Message F2 carries Bob's GRUU to Alice.
メッセージF2はボブのGRUUをアリスまで運びます。
Message F2 (abridged, detailing pertinent fields)
メッセージF2(適切な分野を詳しく述べて、要約されます)
SIP/2.0 200 OK
Supported: gruu
To: <sip:bob@example.com>;tag=totag1
From: <sip:alice@example.com>;tag=fromtag1
Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
OKが支持した一口/2.0 200: gruu To: <一口: bob@example.com 、gt;、;=totag1From:にタグ付けをしてください <一口: alice@example.com 、gt;、; =fromtag1接触にタグ付けをしてください: <一口: bob@example.com;gr はつぼ: uuidと等しいです:(ボブのUAのビット)>。
Bob decides to try to transfer Alice to Carol, so he puts Alice on hold and sends an INVITE to Carol. Carol and Bob negotiate GRUU support similar to what happened in F1 and F2.
ボブが、アリスをキャロルに移そうとすると決めるので、彼は、アリスを保留にして、INVITEをキャロルに送ります。 キャロルとボブはF1とF2で起こったことと同様のGRUUサポートを交渉します。
Message F3 (abridged, detailing pertinent fields)
メッセージF3(適切な分野を詳しく述べて、要約されます)
INVITE sip:carol@example.com SIP/2.0
Supported: gruu
Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com
Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
INVITE一口: carol@example.com SIP/2.0Supported: gruu Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com 接触: <一口: bob@example.com;gr はつぼ: uuidと等しいです:(ボブのUAのビット)>。
Message F4 (abridged, detailing pertinent fields)
メッセージF4(適切な分野を詳しく述べて、要約されます)
SIP/2.0 200 OK
Supported: gruu
To: <sip:carol@example.com>;tag=totag2
From: <sip:bob@example.com>;tag=fromtag2
Call-ID: 23rasdnfoa39i4jnasdf@bob.example.com
Contact: <sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits)>
OKが支持した一口/2.0 200: gruu To: <一口: carol@example.com 、gt;、;=totag2From:にタグ付けをしてください <一口: bob@example.com 、gt;、; =fromtag2呼び出しIDにタグ付けをしてください: 23rasdnfoa39i4jnasdf@bob.example.com 接触: <一口: carol@example.com;gr はつぼ: uuidと等しいです:(キャロルのUAのビット)>。
After consulting Carol, Bob places her on hold and refers Alice to her using message F5. Notice that the Refer-To URI is Carol's GRUU, and that this is on a different Call-ID than message F1. (The URI in the Refer-To header is line-broken for readability in this document; it would not be valid to break the URI this way in a real message.)
キャロルに相談した後に、ボブは、彼女を保持に任命して、メッセージF5を使用することでアリスを彼女に差し向けます。 それに注意してください、Refer、-、URI、キャロルのGRUU、そして、これはメッセージF1と異なったCall-IDにあります。 読み易さにおいて、線で壊れているコネはこのドキュメントです。(中のURI、Refer、-、ヘッダー、; 本当のメッセージでこのようにURIを壊すのが有効でないだろう、)
Message F5 (abridged, detailing pertinent fields)
メッセージF5(適切な分野を詳しく述べて、要約されます)
REFER sip:aanewmr203raswdf@example.com SIP/2.0
Call-ID: 39fa99r0329493asdsf3n@bob.example.com
Refer-To: <sip:carol@example.com;g=urn:uid:(Carol's UA's bits)
?Replaces=23rasdnfoa39i4jnasdf@bob.example.com;
to-tag=totag2;from-tag=fromtag2>
Target-Dialog: 13jfdwer230jsdw@alice.example.com;
local-tag=fromtag1;remote-tag=totag1
Supported: gruu
Contact: <sip:bob@example.com;gr=urn:uuid:(Bob's UA's bits)>
REFER一口: aanewmr203raswdf@example.com SIP/2.0Call-ID: 39fa99r0329493asdsf3n@bob.example.com 、To:を参照します。 <一口: carol@example.com;g はつぼ: uidと等しいです: (キャロルのUAのビット)Replacesは 23rasdnfoa39i4jnasdf@bob.example.com; と等しいです。 タグと、タグからの=totag2はfromtag2>Target-対話と等しいです: 13jfdwer230jsdw@alice.example.com; 地方のタグ=fromtag1; リモートタグはtotag1 Supportedと等しいです: gruu Contact: <一口: bob@example.com;gr はつぼ: uuidと等しいです:(ボブのUAのビット)>。
Sparks Informational [Page 22] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[22ページ]のRFC5057をかきたてます。
Alice uses the information in the Target-Dialog header field to determine that this REFER is associated with the dialog she already has in place with Bob. Alice is now in a position to use the same admission policy she used for in-dialog REFERs: "Do I have a call with this person?". She accepts the REFER, sends Bob the obligatory immediate NOTIFY, and proceeds to INVITE Carol with message F6.
アリスは、このREFERが彼女がボブと共に適所に既に持っている対話に関連していることを決定するのにTarget-対話ヘッダーフィールドに情報を使用します。 アリスは現在、彼女が対話におけるREFERsに使用した同じ入場方針を使用する立場にいます: 「私には、この人との呼び出しがありますか?」? 彼女は、REFERを受け入れて、義務的な即座のNOTIFYをボブに送って、メッセージF6と共にINVITEキャロルに続きます。
Message F6 (abridged, detailing pertinent fields)
メッセージF6(適切な分野を詳しく述べて、要約されます)
sip:carol@example.com;gr=urn:uuid:(Carol's UA's bits)
\ /
\ /
| |
v v
INVITE SIP/2.0
Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com
Replaces: 23rasdnfoa39i4jnasdf@bob.example.com;
to-tag=totag2;from-tag=fromtag2
Supported: gruu
Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
一口: carol@example.com;gr はつぼ: uuid: (キャロルのUAのビット)\/\/と等しいです。| | v v INVITE SIP/2.0Call-ID: 4zsd9f234jasdfasn3jsad@alice.example.com は以下を取り替えます。 23rasdnfoa39i4jnasdf@bob.example.com; タグと、タグからの=totag2はfromtag2 Supportedと等しいです: gruu Contact: <一口: alice@example.com;gr はつぼ: uuidと等しいです:(アリスのUAのビット)>。
Carol accepts Alice's invitation to replace her dialog (invite usage) with Bob, and notifies him that the REFERenced INVITE succeeded with F7:
キャロルは、彼女の対話(用法を招待する)をボブに取り替えるアリスの招待に応じて、REFERenced INVITEがF7と共に成功したことを彼に通知します:
Message F7 (abridged, detailing pertinent fields)
メッセージF7(適切な分野を詳しく述べて、要約されます)
NOTIFY sip:boaiidfjjereis@example.com SIP/2.0
Subscription-State: terminated;reason=noresource
Call-ID: 39fa99r0329493asdsf3n@bob.example.com
Contact: <sip:alice@example.com;gr=urn:uuid:(Alice's UA's bits)>
Content-Type: message/sipfrag
NOTIFY一口: boaiidfjjereis@example.com SIP/2.0Subscription-州: 終わり、; 理由はnoresource Call-IDと等しいです: 39fa99r0329493asdsf3n@bob.example.com 接触: <一口: alice@example.com;gr =つぼ: uuid: (アリスのUAのビット) >コンテントタイプ: メッセージ/sipfrag
SIP/2.0 200 OK
一口/2.0 200OK
Bob then ends his invite usages with both Alice and Carol using BYEs.
そして、ボブは、アリスとキャロルの両方でBYEsを使用することで彼の招待用法を終わらせます。
7. Security Considerations
7. セキュリティ問題
Handling multiple usages within a single dialog is complex and introduces scenarios where the right thing to do is not clear. The ambiguities described here can result in unexpected disruption of communication if response codes are chosen carelessly. Furthermore, these ambiguities could be exploited, particularly by third-parties injecting unauthenticated requests or inappropriate responses. Implementations choosing to create or accept multiple usages within a dialog should give extra attention to the security considerations in
ただ一つの対話の中で複数の用法を扱うのは、複雑であり、する正しいことが明確でないシナリオを紹介します。 応答コードが不注意に選ばれているなら、ここで説明されたあいまいさはコミュニケーションの予期していなかった分裂をもたらすことができます。 その上、特に非認証された要求か不適当な応答を注入している第三者はこれらのあいまいさを利用できました。 対話の中の用法がセキュリティ問題に関する余分な注意を与えるべきである倍数を作成するか、または受け入れるのを選ぶ実現
Sparks Informational [Page 23] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[23ページ]のRFC5057をかきたてます。
[1], especially those concerning the authenticity of requests and processing of responses.
[1]、特に要求の信憑性と応答の処理に関するそれら。
Service implementations should carefully consider the effects on their service of peers making different choices in these areas of ambiguity. A service that requires multiple usages needs to pay particular attention to the effect on service and network utilization when a client fails to destroy a dialog the service believes should be destroyed. A service that disallows multiple usages should consider the effect on clients that, for instance, destroy the entire dialog when only a usage should be torn down. In the worst case of a service deployed into a network with a large number of misbehaving clients trying to create multiple usages in an automated fashion, a retry storm similar to an avalanche restart could be induced.
サービス実現は慎重に彼らのあいまいさのこれらの領域で異なった選択をしている同輩のサービスへの効果を考えるべきです。 複数の用法を必要とするサービスは、サービスへの効果に関する特別の注意を向ける必要があります、そして、クライアントがサービスが信じている対話を破壊しないと、ネットワーク利用は破壊されるべきです。 複数の用法を禁じるサービスは例えば用法だけを取りこわすべきであるとき全体の対話を破壊するクライアントへの効果を考えるべきです。 最悪の場合には多くのふらちな事をしているクライアントが自動化されたファッションで複数の用法を作成していようとする状態でネットワークに配備されたサービスでは、雪崩再開と同様の再試行嵐を引き起こすことができました。
8. Conclusion
8. 結論
Handling multiple usages within a single dialog is complex and introduces scenarios where the right thing to do is not clear. Implementations should avoid entering into multiple usages whenever possible. New applications should be designed to never introduce multiple usages.
ただ一つの対話の中で複数の用法を扱うのは、複雑であり、する正しいことが明確でないシナリオを紹介します。 実現は、可能であるときはいつも、複数の用法に入るのを避けるべきです。 新しいアプリケーションは、複数の用法を決して導入しないように設計されるべきです。
There are some accepted SIP practices, including transfer, that currently require multiple usages. Recent work, most notably GRUU, makes those practices unnecessary. The standardization of those practices and the implementations should be revised as soon as possible to use only single-usage dialogs.
転送を含む現在複数の用法を必要とするいくつかの受け入れられたSIP習慣があります。 近作(最も著しくGRUU)で、それらの習慣は不要になります。 それらの習慣と実現の標準化は、できるだけ早く、ただ一つの用法対話だけを使用するために改訂されるべきです。
9. Acknowledgments
9. 承認
The ideas in this document have been refined over several IETF meetings with many participants. Significant contribution was provided by Adam Roach, Alan Johnston, Ben Campbell, Cullen Jennings, Jonathan Rosenberg, Paul Kyzivat, and Rohan Mahy. Members of the reSIProcate project also shared their difficulties and discoveries while implementing multiple-usage dialog handlers.
考えは多くの関係者とのいくつかのIETFミーティングの上で本書では洗練されました。 重要な貢献はアダム・ローチ、アラン・ジョンストン、ベン・キャンベル、Cullenジョニングス、ジョナサン・ローゼンバーグ、ポールKyzivat、およびRohanマーイによって提供されました。 また、reSIProcateプロジェクトのメンバーは複数の用法対話操作者を実行している間、彼らの困難と発見を共有しました。
10. Informative References
10. 有益な参照
[1] 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.
[1] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[2] Levin, O., "Suppression of Session Initiation Protocol (SIP)
REFER Method Implicit Subscription", RFC 4488, May 2006.
[2] レヴィン(O.、「セッション開始プロトコル(一口)の抑圧は方法の暗黙の購読を参照する」RFC4488)は2006がそうするかもしれません。
Sparks Informational [Page 24] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[24ページ]のRFC5057をかきたてます。
[3] Burger, E. and M. Dolly, "A Session Initiation Protocol (SIP)
Event Package for Key Press Stimulus (KPML)", RFC 4730,
November 2006.
[3] バーガー、E.、およびM.は、「主要なプレス刺激(KPML)のためのセッション開始プロトコル(一口)イベントパッケージ」とドリーに載せて移動させます、RFC4730、2006年11月。
[4] Niemi, A., "Session Initiation Protocol (SIP) Extension for
Event State Publication", RFC 3903, October 2004.
[4]Niemi、A.、「イベント州政府出版物のためのセッション開始プロトコル(一口)拡大」、RFC3903、2004年10月。
[5] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[5] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。
[7] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[7] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、2003年4月。
[8] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[8] マーイ、R.、ビッグズ、B.、およびR.ディーン、RFC3891、「セッション開始プロトコル(一口)はヘッダーを「取り替え」であっ」て、9月は2004です。
[9] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", Work in Progress, June 2006.
[9] ローゼンバーグ、J.、「セッション開始プロトコル(一口)にRoutableユーザエージェント(UA)URI(GRUU)をグローバルに得て、使用すること」は進行中(2006年6月)で働いています。
[10] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006.
[10] ローゼンバーグ、J.、「セッション開始プロトコル(一口)における対話識別による要求認可」、RFC4538、2006年6月。
[11] Mahy, R. and D. Petrie, "The Session Initiation Protocol (SIP)
"Join" Header", RFC 3911, October 2004.
2004年10月の[11] マーイ、R. and D.ピートリー、「「接合してください」というセッション開始プロトコル(一口)ヘッダー」RFC3911。
Author's Address
作者のアドレス
Robert J. Sparks Estacado Systems
ロバートJ.はエスタカードシステムをかきたてます。
EMail: RjS@estacado.net
メール: RjS@estacado.net
Sparks Informational [Page 25] RFC 5057 Multiple Dialog Usages November 2007
複数の対話用法2007年11月に情報[25ページ]のRFC5057をかきたてます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Sparks Informational [Page 26]
スパークスInformationalです。[26ページ]
一覧
スポンサーリンク
