RFC5407 日本語訳
5407 Example Call Flows of Race Conditions in the Session InitiationProtocol (SIP). M. Hasebe, J. Koshiko, Y. Suzuki, T. Yoshikawa, P.Kyzivat. December 2008. (Format: TXT=120005 bytes) (Also BCP0147) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Hasebe
Request for Comments: 5407 J. Koshiko
BCP: 147 NTT-east Corporation
Category: Best Current Practice Y. Suzuki
NTT Corporation
T. Yoshikawa
NTT-east Corporation
P. Kyzivat
Cisco Systems, Inc.
December 2008
Hasebeがコメントのために要求するワーキンググループM.をネットワークでつないでください: 5407J.Koshiko BCP: 147のNTT東の社のカテゴリ: 最も良い現在のNTT東の練習の社のP.KyzivatシスコシステムズInc.Y.鈴木NTT社のT.吉川2008年12月
Example Call Flows of Race Conditions in the
Session Initiation Protocol (SIP)
セッション開始プロトコルにおける、競合条件の例の呼び出し流れ(一口)
Status of This Memo
このメモの状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright(c)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
Abstract
要約
This document gives example call flows of race conditions in the Session Initiation Protocol (SIP). Race conditions are inherently confusing and difficult to thwart; this document shows the best practices to handle them. The elements in these call flows include SIP User Agents and SIP Proxy Servers. Call flow diagrams and message details are given.
このドキュメントはSession Initiationプロトコル(SIP)における、競合条件の例の呼び出し流れを与えます。 競合条件は、本来紛らわしくて、邪魔するのは難しいです。 このドキュメントは、それらを扱うために最も良い習慣を示しています。 これらの呼び出し流れにおける要素はSIP UserエージェントとSIP Proxyサーバを含んでいます。 呼び出しフローチャートとメッセージ詳細は述べられます。
Hasebe, et al. Best Current Practice [Page 1] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[1ページ]RFC5407例の呼び出し流れ
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. General Assumptions . . . . . . . . . . . . . . . . . . . 3
1.2. Legend for Message Flows . . . . . . . . . . . . . . . . . 3
1.3. SIP Protocol Assumptions . . . . . . . . . . . . . . . . . 4
2. The Dialog State Machine for INVITE Dialog Usage . . . . . . . 5
3. Race Conditions . . . . . . . . . . . . . . . . . . . . . . . 10
3.1. Receiving Message in the Moratorium State . . . . . . . . 11
3.1.1. Callee Receives Initial INVITE Retransmission
(Preparative State) While in the Moratorium State . . 11
3.1.2. Callee Receives CANCEL (Early State) While in the
Moratorium State . . . . . . . . . . . . . . . . . . . 13
3.1.3. Callee Receives BYE (Early State) While in the
Moratorium State . . . . . . . . . . . . . . . . . . . 15
3.1.4. Callee Receives re-INVITE (Established State)
While in the Moratorium State (Case 1) . . . . . . . . 17
3.1.5. Callee Receives re-INVITE (Established State)
While in the Moratorium State (Case 2) . . . . . . . . 22
3.1.6. Callee Receives BYE (Established State) While in
the Moratorium State . . . . . . . . . . . . . . . . . 26
3.2. Receiving Message in the Mortal State . . . . . . . . . . 28
3.2.1. UA Receives BYE (Established State) While in the
Mortal State . . . . . . . . . . . . . . . . . . . . . 28
3.2.2. UA Receives re-INVITE (Established State) While in
the Mortal State . . . . . . . . . . . . . . . . . . . 30
3.2.3. UA Receives 200 OK for re-INVITE (Established
State) While in the Mortal State . . . . . . . . . . . 32
3.2.4. Callee Receives ACK (Moratorium State) While in
the Mortal State . . . . . . . . . . . . . . . . . . . 35
3.3. Other Race Conditions . . . . . . . . . . . . . . . . . . 36
3.3.1. Re-INVITE Crossover . . . . . . . . . . . . . . . . . 36
3.3.2. UPDATE and re-INVITE Crossover . . . . . . . . . . . . 40
3.3.3. Receiving REFER (Established State) While in the
Mortal State . . . . . . . . . . . . . . . . . . . . . 45
4. Security Considerations . . . . . . . . . . . . . . . . . . . 46
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1. Normative References . . . . . . . . . . . . . . . . . . . 47
6.2. Informative References . . . . . . . . . . . . . . . . . . 47
Appendix A. BYE in the Early Dialog . . . . . . . . . . . . . . . 48
Appendix B. BYE Request Overlapping with re-INVITE . . . . . . . 49
Appendix C. UA's Behavior for CANCEL . . . . . . . . . . . . . . 52
Appendix D. Notes on the Request in the Mortal State . . . . . . 54
Appendix E. Forking and Receiving New To Tags . . . . . . . . . . 54
1. 概観. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 一般仮定. . . . . . . . . . . . . . . . . . . 3 1.2。 メッセージのための伝説は.31.3に流れます。 プロトコル仮定. . . . . . . . . . . . . . . . . 4 2をちびちび飲んでください。 招待対話用法. . . . . . . 5 3のための対話州のマシン。 競合条件. . . . . . . . . . . . . . . . . . . . . . . 10 3.1。 モラトリアム州. . . . . . . . 11 3.1の.1におけるメッセージを受け取ります。 訪問される人はRetransmission(予備の状態)がモラトリアム州. . 11 3.1.2でゆったり過ごす初期の招待を受けます。 モラトリアム州. . . . . . . . . . . . . . . . . . . 13 3.1の.3にはある間、訪問される人はキャンセル(早めの状態)を受けます。 モラトリアム州. . . . . . . . . . . . . . . . . . . 15 3.1の.4にはある間、訪問される人は、さようならを受けます(早めの状態)。 訪問される人がモラトリアム状態(ケース1)にある間、再招待(状態を設置する)を受ける、.173.1、.5 訪問される人がモラトリアム状態(ケース2)にある間、再招待(状態を設置する)を受ける、.223.1、.6 モラトリアム状態. . . . . . . . . . . . . . . . . 26 3.2にある間、訪問される人は、さようならを受けます(状態を設置します)。 致命的な州. . . . . . . . . . 28 3.2の.1におけるメッセージを受け取ります。 致命的な州. . . . . . . . . . . . . . . . . . . . . 28 3.2の.2にはある間、UAは、さようならを受けます(状態を設置します)。 致命的な州. . . . . . . . . . . . . . . . . . . 30 3.2.3にはある間、UAは再招待(状態を設置する)を受けます。 UAが再招待(状態を設置する)のために致命的な状態にある間、200OKを受け取る、.323.2、.4 致命的な状態. . . . . . . . . . . . . . . . . . . 35 3.3にある間、訪問される人はACK(モラトリアム状態)を受けます。 他の競合条件. . . . . . . . . . . . . . . . . . 36 3.3.1。 横断歩道. . . . . . . . . . . . . . . . . 36 3.3.2を再招待してください。 横断歩道. . . . . . . . . . . . 40 3.3.3をアップデートして、再招待してください。 受信して、致命的な状態. . . . . . . . . . . . . . . . . . . . . 45 4にある間、参照してください(状態を設置します)。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 46 5。 承認. . . . . . . . . . . . . . . . . . . . . . . 46 6。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 47 6.1。 引用規格. . . . . . . . . . . . . . . . . . . 47 6.2。 早めの対話. . . . . . . . . . . . . . . 48付録B.不戦勝における付録A.不戦勝が重なることを要求する有益な参照. . . . . . . . . . . . . . . . . . 47はタグ. . . . . . . . . . 54に新しい致命的な州. . . . . . 54の付録E.分岐と受信における要求に関するキャンセル. . . . . . . . . . . . . . 52付録D.注のための.49付録C.UAの振舞いを再招待します。
Hasebe, et al. Best Current Practice [Page 2] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[2ページ]RFC5407例の呼び出し流れ
1. Overview
1. 概観
The call flows shown in this document were developed in the design of a SIP IP communications network. These examples are of race conditions, which stem from transitions in dialog states -- mainly transitions during session establishment after the sending of an INVITE.
本書では示された呼び出し流れはSIP IP通信網のデザインで発生しました。 これらの例は対話州で変遷による競合条件のものです--INVITEの発信の後のセッション設立の間の主に変遷。
When implementing SIP, various complex situations may arise. Therefore, it is helpful to provide implementors of the protocol with examples of recommended terminal and server behavior.
SIPを実行するとき、様々な複雑な情勢は起こるかもしれません。 したがって、お勧めの端末とサーバの振舞いに関する例をプロトコルの作成者に提供するのは役立っています。
This document clarifies SIP User Agent (UA) behaviors when messages cross each other as race conditions. By clarifying the operation under race conditions, inconsistent interpretations between implementations are avoided and interoperability is expected to be promoted.
メッセージが競合条件として互いに交差するとき、このドキュメントはSIP Userエージェント(UA)の振舞いをはっきりさせます。 競合条件の下で操作をはっきりさせることによって、実現の間の無節操な解釈は避けられます、そして、相互運用性が促進されると予想されます。
It is the hope of the authors that this document will be useful for SIP implementors, designers, and protocol researchers and will help them achieve the goal of a standard implementation of RFC 3261 [1].
それはこのドキュメントが、SIP作成者、デザイナー、およびプロトコル研究者の役に立って、彼らがRFC3261[1]の標準の実現の目標を達成するのを助けるという作者の望みです。
These call flows are based on version 2.0 of SIP, defined in RFC 3261 [1], with SDP usage as described in RFC 3264 [2].
これらの呼び出し流れはRFC3264[2]で説明されるようにSDP用法でRFC3261[1]で定義されたSIPのバージョン2.0に基づいています。
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 BCP 14, RFC 2119 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[3])で説明されるように本書では解釈されることであるべきです。
1.1. General Assumptions
1.1. 一般仮定
A number of architectural, network, and protocol assumptions underlie the call flows in this document. Note that these assumptions are not requirements. They are outlined in this section so that they may be taken into consideration and help understanding of the call flow examples.
建築することの数、ネットワーク、およびプロトコル仮定は本書では呼び出し流れの基礎となります。 これらの仮定が要件でないことに注意してください。 それらは、彼らが考慮に入れられて、呼び出し流れの例の理解を助けることができるように、このセクションで概説されています。
These flows do not assume specific underlying transport protocols such as TCP, TLS, and UDP. See the discussion in RFC 3261 [1] for details of the transport issues for SIP.
これらの流れは、特定の基本的な輸送がTCPや、TLSや、UDPなどのプロトコルであると仮定しません。 輸送問題の詳細のためのRFC3261[1]でSIPに関して議論を見てください。
1.2. Legend for Message Flows
1.2. メッセージのための伝説は流れます。
Dashed lines (---) and slash lines (/, \) represent signaling messages that are mandatory to the call scenario. (X) represents the crossover of signaling messages. (->x, x<-) indicate that the packet is lost. The arrow indicates the direction of message flow. Double dashed lines (===) represent media paths between network elements.
投げつけられた線(---)とスラッシュ線(/、\)は呼び出しシナリオに義務的なシグナリングメッセージを表します。 (X) シグナリングメッセージの横断歩道を表します。 (-、>x、x<、-、) パケットが無くなるのを示してください。 矢はメッセージ流動の方向を示します。 二重投げつけられた線(===)はネットワーク要素の間のメディア経路を表します。
Hasebe, et al. Best Current Practice [Page 3] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[3ページ]RFC5407例の呼び出し流れ
Messages are identified in the figures as F1, F2, etc. These numbers are used for references to the message details that follow the figure. Comments in the message details are shown in the following form:
メッセージはF1、F2などとして数字で特定されます。 これらの数は図に従うメッセージの詳細の参照に使用されます。 メッセージの詳細におけるコメントは以下のフォームに示されます:
/* Comments. */
/*はコメントします。 */
1.3. SIP Protocol Assumptions
1.3. 一口プロトコル仮定
This document does not prescribe the flows precisely as they are shown, but rather illustrates the principles for best practice. They are best practice usages (orderings, syntax, selection of features for the purpose, or handling of errors) of SIP methods, headers, and parameters. Note: The flows in this document must not be copied as-is by implementors because additional annotations have been incorporated into this document for ease of explanation. To sum up, the procedures described in this document represent well-reviewed examples of SIP usage, which exemplify best common practice according to IETF consensus.
このドキュメントは、まさにそれらが見せられるように流れを定めませんが、最も良い習慣のためにむしろ原則を例証します。 それらはSIP方法、ヘッダー、およびパラメタの最も良い習慣用法(受注業務、構文、目的のための特徴の品揃え、または誤りの取り扱い)です。 以下に注意してください。 追加注釈が法人組織であったので、流れは作成者によって本書ではそのままで説明の容易さのためのこのドキュメントにコピーされてはいけません。 要するに、本書では説明された手順はSIP用法のよく見直された例を表します。(IETFコンセンサスに従って、例は例示します中で一般的な習慣最も良い)。
For reasons of simplicity in reading and editing the document, there are a number of differences between some of the examples and actual SIP messages. For instance, Call-IDs are often replicated, CSeq often begins at 1, header fields are usually shown in the same order, usually only the minimum required header field set is shown, and other headers that would usually be included, such as Accept, Allow, etc., are not shown.
ドキュメントを読んで、編集することにおける簡単さの理由で、例と実際のSIPメッセージのいくつかの間には、多くの違いがあります。 例えば、Call-IDはしばしば模写されます、そして、CSeqは1時にしばしば始まります、そして、通常、ヘッダーフィールドは同次で示されます、そして、通常、最小の必要なヘッダーフィールドセットだけが見せられます、そして、通常、Accept、Allowなどのように含まれている他のヘッダーは見せられません。
Actors:
俳優:
Element Display Name URI IP Address ------- ------------ --- ----------
要素表示名前URI IPアドレス------- ------------ --- ----------
User Agent Alice sip:alice@atlanta.example.com 192.0.2.101 User Agent Bob sip:bob@biloxi.example.com 192.0.2.201 User Agent Carol sip:carol@chicago.example.com 192.0.2.202 Proxy Server ss.atlanta.example.com 192.0.2.111
ユーザのエージェントのアリスの一口: alice@atlanta.example.com 192.0.2の.101Userエージェントのボブの一口: bob@biloxi.example.com 192.0.2の.201Userエージェントのキャロルの一口: carol@chicago.example.com 192.0.2.202Proxyサーバss.atlanta.example.com192.0.2.111
The term "session" is used in this document in the same way it is used in Sections 13-15 of RFC 3261 [1] (which differs somewhat from the definition of the term in RFC 3261). RFC 5057 [6] introduces another term, "invite dialog usage", which is more precisely defined. The term "session" used herein is almost, but not quite, identical to the term "invite dialog usage". The two have differing definitions of when the state ends -- the session ends earlier, when BYE is sent or received.
「セッション」という用語は本書ではそれがRFC3261[1](RFC3261との用語の定義といくらか異なっている)のセクション13-15で使用される同じように使用されます。 RFC5057[6]は別の用語、「対話用法を招待してください」を導入します。(それは、より正確に定義されます)。 ほとんどである「セッション」というここに使用される用語は全く同じであるというわけではありません。「対話用法を招待する」という用語と同じです。 2には、状態が終わる時に関する異なった定義があります--セッションは、より早く終わります、BYEを送るか、または受け取るとき。
Hasebe, et al. Best Current Practice [Page 4] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[4ページ]RFC5407例の呼び出し流れ
2. The Dialog State Machine for INVITE Dialog Usage
2. 招待対話用法のための対話州のマシン
Race conditions are generated when the dialog state of the receiving side differs from that of the sending side.
受信側の対話状態が送付側のものと異なっているとき、競合条件は発生します。
For instance, a race condition occurs when a UAC (User Agent Client) sends a CANCEL in the Early state while the UAS (User Agent Server) is transitioning from the Early state to the Confirmed state by sending a 200 OK to an initial INVITE (indicated as "ini-INVITE" hereafter). The DSM (dialog state machine) for the INVITE dialog usage is presented as follows to help understanding of the UA's behavior in race conditions.
例えば、UAS(ユーザエージェントServer)が初期のINVITE(将来を「ini招待する」とき、示される)に200OKを送ることによってEarly状態からConfirmed状態に移行している間UAC(ユーザエージェントClient)がEarly状態でキャンセルを送るとき、競合条件は起こります。 競合条件における、UAの振舞いの理解を助けるために、以下の通り、INVITE対話用法のためのDSM(対話州のマシン)を寄贈します。
The DSM clarifies the UA's behavior by subdividing the dialog state shown in RFC 3261 [1] into various internal states. We call the state before the establishment of a dialog the Preparative state. The Confirmed state is subdivided into two substates, the Moratorium and the Established states, and the Terminated state is subdivided into the Mortal and Morgue states. Messages that are the triggers for the state transitions between these states are indicated with arrows. In this figure, messages that are not related to state transition are omitted.
DSMは、RFC3261[1]で見せられた対話状態を様々な内部の州に分筆することによって、UAの振舞いをはっきりさせます。 私たちは、対話の確立の前の状態をPreparative状態と呼びます。 Confirmed状態は2「副-状態」、Moratorium、およびEstablished州に分筆されます、そして、Terminated状態はMortalとMorgue州に分筆されます。 これらの州の間の状態遷移のための引き金であるメッセージは矢で示されます。 この図では、状態遷移に関連しないメッセージは省略されます。
Below are the DSMs, first for the caller and then for the callee.
以下に、DSMsは最初に訪問者とそして、訪問される人のためにあります。
Hasebe, et al. Best Current Practice [Page 5] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[5ページ]RFC5407例の呼び出し流れ
INV +-----------------------------------------------+
--->| Preparative |
+-----------------------------------------------+
| | |
| 3xx-6xx | 1xx-tag | 2xx
| | |
| | 1xx-tag |
| V w/new tag |
| +-----------------+ [new DSM] |
| 3xx-6xx | | | (new DSM |
+<--------| Early | | instance |
| | |<--+ created) |
| +-----------------+ |
| | | | 2xx w/new tag
| | BYE | 2xx | [new DSM]
| | +------------>+<-+ | (new DSM
| | | | instance
+-----C------------C-----+ +-----------C------+ | created)
| | Terminated | | | Confirmed | | |
| | +<----C---------| | | |
| | | | BYE(sr) | | | |
| | V | | V | |
| 2xx | +-----------+ | | +-----------+ | |
| +---C--| |---C-+ | | | | |
| | | | Mortal | | | BYE(r)| | Moratorium|<-C--+
| +---C->| |<--C-+ | | | |
| ACK | +-----------+ | | +-----------+ |
| | | | | | |
| | | Timeout | | | ACK |
| | | | | | |
| V V | | V |
| +---------------+ | | +-----------+ |
| | | | | | |--C-+
| | Morgue | | | |Established| | | 2xx,ACK
| | | | | | |<-C-+
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
INV+-----------------------------------------------+ --->| 予備| +-----------------------------------------------+ | | | | 3xx-6xx| 1xx-タグ| 2xx| | | | | 1xx-タグ| | 新しいタグがあるV| | +-----------------+ [新しいDSM]| | 3xx-6xx| | | (新しいDSM| + <、-、-、-、-、-、-、--、|、早期である、| | 例| | | | <--、作成された+) | | +-----------------+ | | | | | 新しいタグがある2xx| | さようなら| 2xx| [新しいDSM]| | +------------>+<-+| (new DSM | | | | instance +-----C------------C-----+ +-----------C------+ | created) | | 終わります。| | | 確認されます。| | | | | + <。----C---------| | | | | | | | さようなら(sr)| | | | | | V| | V| | | 2xx| +-----------+ | | +-----------+ | | | +---C--| |---C-+| | | | | | | | | 死すべき者| | | さようなら(r)| | モラトリアム| <、-C--+| +---C>| | <--C-+| | | | | ACK| +-----------+ | | +-----------+ | | | | | | | | | | | タイムアウト| | | ACK| | | | | | | | | V V| | V| | +---------------+ | | +-----------+ | | | | | | | |--C-+| | 死体公示所| | | |設立されます。| | | 2xx、ACK| | | | | | | <、-C-+| +---------------+ | | +-----------+ | | | | | +------------------------+ +------------------+
(r): indicates that only reception is allowed.
Where (r) is not used as an indicator, "response" means
receive, and "request" means send.
(sr): indicates that both sending and reception are allowed.
(r): レセプションだけが許容されているのを示します。 「応答」手段が、(r)がインディケータとして使用されないよう受けて、「要求する」ところに、手段は発信します。 (sr): 発信とレセプションの両方が許容されているのを示します。
Figure 1: DSM for INVITE dialog usage (caller)
図1: INVITE対話用法のためのDSM(訪問者)
Hasebe, et al. Best Current Practice [Page 6] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[6ページ]RFC5407例の呼び出し流れ
Figure 1 represents the caller's DSM for the INVITE dialog usage. The caller MAY send a BYE in the Early state, even though this behavior is not recommended. A BYE sent in the Early state terminates the early dialog using a specific To tag. That is, when a proxy is performing forking, the BYE is only able to terminate the early dialog with a particular UA. If the caller wants to terminate all early dialogs instead of that with a particular UA, it needs to send CANCEL, not BYE. However, it is not illegal to send BYE in the Early state to terminate a specific early dialog if this is the caller's intent. Moreover, until the caller receives a final response and terminates the INVITE transaction, the caller MUST be prepared to establish a dialog by receiving a new response to the INVITE even if it has already sent a CANCEL or BYE and terminated the dialog (see Appendix A).
図1はINVITE対話用法のために訪問者のDSMを表します。 この振舞いは推薦されませんが、訪問者はEarly状態でBYEを送るかもしれません。 BYEは、Early州が特定のToタグを使用することで早めの対話を終えるのを送りました。 すなわち、プロキシが分岐を実行しているとき、BYEは特定のUAと共に早めの対話を終えることができるだけです。 訪問者が特定のUAがあるそれの代わりにすべての早めの対話を終えたいなら、それは、BYEではなく、キャンセルを送る必要があります。 しかしながら、特定の早めの対話を終えるためにEarly状態でBYEを送るのはこれが訪問者の意図であるなら不法ではありません。 そのうえ、訪問者が最終的な応答を受けて、INVITE取引を終えるまで、訪問者は既にキャンセルかBYEを送り、対話を終えたとしても(Appendix Aを見てください)INVITEへの新しい応答を受けることによって対話を確立する用意ができていなければなりません。
Hasebe, et al. Best Current Practice [Page 7] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[7ページ]RFC5407例の呼び出し流れ
INV +-----------------------------------------------+
--->| Preparative |
+-----------------------------------------------+
| | |
| 3xx-6xx | 1xx-tag | 2xx
| | |
| V |
| +------------------+ |
| 3xx-6xx | | |
+<--------| Early | |
| | | |
| +------------------+ |
| | | |
| |BYE/487(INV) | 2xx |
| | +------------>+<-+
| | |
+-----C------------C-----+ +-----------C------+
| | Terminated | | | Confirmed | |
| | +<----C---------| | |
| | | | BYE(sr) | | |
| | V | | V |
| | +------------+ | | +-----------+ |
| | | |---C-+ | | |--C-+
| | | Mortal | | | BYE | | Moratorium| | | 2xx
| | | |<--C-+ | | |<-C-+ if ACK not
| | +------------+ | | +-----------+ | received
| | | | | | |
| | | Timeout | | | ACK |
| | | | | | |
| V V | | V |
| +---------------+ | | +-----------+ |
| | | | | | | |
| | Morgue | | | |Established| |
| | | | | | | |
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
INV+-----------------------------------------------+ --->| 予備| +-----------------------------------------------+ | | | | 3xx-6xx| 1xx-タグ| 2xx| | | | V| | +------------------+ | | 3xx-6xx| | | + <。--------| 早い| | | | | | | +------------------+ | | | | | | |さようなら/487(INV)| 2xx| | | +------------>+<-+| | | +-----C------------C-----+ +-----------C------+ | | 終わります。| | | 確認されます。| | | | + <。----C---------| | | | | | | さようなら(sr)| | | | | V| | V| | | +------------+ | | +-----------+ | | | | |---C-+| | |--C-+| | | 死すべき者| | | さようなら| | モラトリアム| | | 2xx| | | | <--C-+| | | <、-C-+、ACKです。| | +------------+ | | +-----------+ | 受信します。| | | | | | | | | | タイムアウト| | | ACK| | | | | | | | | V V| | V| | +---------------+ | | +-----------+ | | | | | | | | | | | 死体公示所| | | |設立されます。| | | | | | | | | | | +---------------+ | | +-----------+ | | | | | +------------------------+ +------------------+
(sr): indicates that both sending and reception are allowed.
Where (sr) is not used as an indicator, "response" means send,
and "request" means receive.
(sr): 発信とレセプションの両方が許容されているのを示します。 (sr)がインディケータとして使用されないところに、「応答」手段は発信します、そして、「要求」手段は受信されます。
Figure 2: DSM for INVITE dialog usage (callee)
図2: INVITE対話用法のためのDSM(訪問される人)
Figure 2 represents the callee's DSM for the INVITE dialog usage. The figure does not illustrate the state transition related to CANCEL requests. A CANCEL request does not cause a dialog state transition. However, the callee terminates the dialog and triggers the dialog
図2はINVITE対話用法のために訪問される人のDSMを表します。 図はキャンセル要求に関連する状態遷移を例証しません。 キャンセル要求は対話状態遷移を引き起こしません。 しかしながら、訪問される人は、対話を終えて、対話の引き金となります。
Hasebe, et al. Best Current Practice [Page 8] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[8ページ]RFC5407例の呼び出し流れ
transition by sending a 487 immediately after the reception of the CANCEL. This behavior upon the reception of the CANCEL request is further explained in Appendix C.
キャンセルのレセプション直後487を送るのによる変遷。 キャンセル要求のレセプションのこの振舞いはAppendix Cでさらに説明されます。
The UA's behavior in each state is as follows.
各状態のUAの振舞いは以下の通りです。
Preparative (Pre): The Preparative state is in effect until the
early dialog is established by sending or receiving a provisional
response with a To tag after an ini-INVITE is sent or received.
The dialog does not yet exist in the Preparative state. If the UA
sends or receives a 2xx response, the dialog state transitions
from the Preparative state to the Moratorium state, which is a
substate of the Confirmed state. In addition, if the UA sends or
receives a 3xx-6xx response, the dialog state transitions to the
Morgue state, which is a substate of the Terminated state.
Sending an ACK for a 3xx-6xx response and retransmissions of 3xx-
6xx are not shown on the DSMs because they are sent by the INVITE
transaction.
予備、(前、)、: 早めの対話がini-INVITEを送るか、または受け取った後に、Toタグで暫定的な応答を送るか、または受けることによって確立されるまで、Preparative状態は有効です。 対話はPreparative州にまだ存在していません。 Preparativeからの対話状態遷移は、UAが2xx応答を送るか、または受けるならConfirmed状態の「副-状態」がどれであるかとMoratorium状態に述べます。 さらに、UAが3xx-6xx応答を送るか、または受けるなら、対話状態はMorgue状態に移行します。(それは、Terminated状態の「副-状態」です)。 3xx6xxの3xx-6xx応答のためのACKを送って、「再-トランスミッション」は、INVITE取引で彼らを送るので、DSMsで見せられません。
Early (Ear): The early dialog is established by sending or receiving
a provisional response except 100 Trying. The early dialog exists
even though the dialog does not exist in this state yet. The
dialog state transitions from the Early state to the Moratorium
state, a substate of the Confirmed state, by sending or receiving
a 2xx response. In addition, the dialog state transitions to the
Morgue state, a substate of the Terminated state, by sending or
receiving a 3xx-6xx response. Sending an ACK for a 3xx-6xx
response and retransmissions of 3xx-6xx are not shown on this DSM
because they are automatically processed on the transaction layer
and don't influence the dialog state. The UAC may send a CANCEL
in the Early state. The UAC may also send a BYE (although it is
not recommended). The UAS may send a 1xx-6xx response. The
sending or receiving of a CANCEL request does not have a direct
influence on the dialog state. The UA's behavior upon the
reception of the CANCEL request is explained further in Appendix
C.
早さ(耳): 早めの対話は、100Tryingを除いて、暫定的な応答を送るか、または受けることによって、確立されます。 対話はこの州にまだ存在していませんが、早めの対話は存在しています。 対話状態はEarly状態からMoratorium状態に移行します、Confirmed状態の「副-状態」、2xx応答を送るか、または受けることによって。 さらに、対話状態はMorgue状態に移行します、Terminated状態の「副-状態」、3xx-6xx応答を送るか、または受けることによって。 彼らが自動的に取引層に処理されて、対話状態に影響を及ぼさないので、3xx-6xxの3xx-6xx応答のためのACKを送って、「再-トランスミッション」はこのDSMで見せられません。 UACはEarly状態でキャンセルを送るかもしれません。 また、UACはBYEを送るかもしれません(それが推薦されませんが)。 UASは1xx-6xx応答を送るかもしれません。 キャンセル要求の発信か受信が対話状態に直接の影響を持っていません。 キャンセル要求のレセプションのUAの振舞いはAppendix Cで、より詳しく説明されます。
Confirmed (Con): The sending or receiving of a 2xx final response
establishes a dialog. The dialog starts in this state. The
Confirmed state transitions to the Mortal state, a substate of the
Terminated state, by sending or receiving a BYE request. The
Confirmed state has two substates, the Moratorium and the
Established states, which are different with regard to the
messages that UAs are allowed to send.
確認されます(だまします): 2xxの最終的な応答の発信か受信が対話を確立します。 対話はこの状態で始まります。 ConfirmedはMortal状態への変遷を述べます、Terminated状態の「副-状態」、BYE要求を送るか、または受け取ることによって。 Confirmed州には、2「副-状態」、Moratorium、およびEstablished州があります。(それは、UAsが発信できるというメッセージに関して異なっています)。
Hasebe, et al. Best Current Practice [Page 9] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[9ページ]RFC5407例の呼び出し流れ
Moratorium (Mora): The Moratorium state is a substate of the
Confirmed state and inherits its behavior. The Moratorium state
transitions to the Established state by sending or receiving an
ACK request. The UAC may send an ACK and the UAS may send a 2xx
final response.
モラトリアム(モーラ): Moratorium状態は、Confirmed状態の「副-状態」であり、振舞いを引き継ぎます。 Moratoriumは、ACK要求を送るか、または受け取ることによって、Established状態への変遷を述べます。 UACはACKを送るかもしれません、そして、UASは2xxの最終的な応答を送るかもしれません。
Established (Est): The Established state is a substate of the
Confirmed state and inherits its behavior. Both caller and callee
may send various messages that influence a dialog. The caller
supports the transmission of ACK to the retransmission of a 2xx
response to an ini-INVITE.
確立(エスト): Established状態は、Confirmed状態の「副-状態」であり、振舞いを引き継ぎます。 訪問者と訪問される人の両方が対話に影響を及ぼす様々なメッセージを送るかもしれません。 訪問者はini-INVITEへの2xx応答の「再-トランスミッション」にACKのトランスミッションを支持します。
Terminated (Ter): The Terminated state is subdivided into two
substates, the Mortal and Morgue states, to cover the behavior
when a dialog is being terminated. In this state, the UA holds
information about the dialog that is being terminated.
終えられる(Ter): Terminated状態は、対話が終えられているとき、振舞いをカバーするために2つの「副-状態」、Mortal、およびMorgue州に分筆されます。 この状態では、UAは終えられている対話の情報を保持します。
Mortal (Mort): The caller and callee enter the Mortal state by
sending or receiving a BYE. The UA MUST NOT send any new requests
within the dialog because there is no dialog. (Here, the new
requests do not include ACK for 2xx and BYE for 401 or 407, as
further explained in Appendix D below.) In the Mortal state, BYE
can be accepted, and the other messages in the INVITE dialog usage
are responded to with an error. This addresses the case where a
caller and a callee exchange reports about the session when it is
being terminated. Therefore, the UA possesses dialog information
for internal processing but the dialog shouldn't be externally
visible. The UA stops managing its dialog state and changes it to
the Morgue state when the BYE transaction is terminated.
死すべき者(角笛の音): 訪問者と訪問される人は、送付か不戦勝を得ることによって、Mortal状態に入ります。 対話が全くないので、Uaは対話の中でどんな新しい要求も送ってはいけません。 (ここに、新しい要求は2xxのためのACKと401か407のためのBYEを含んでいません、以下のAppendix Dでさらに説明されるように。) Mortal状態では、BYEを受け入れることができます、そして、誤りでINVITE対話用法による他のメッセージに応じます。 これは訪問者と訪問される人交換がセッションのときにそれが終えられる予定である頃報告するケースを記述します。 したがって、UAには、内部の処理のための対話情報がありますが、対話は外部的に目に見えるべきではありません。 BYE取引が終えられるとき、UAは対話状態を経営するのを止めて、それをMorgue状態に変えます。
Morgue (Morg): The dialog no longer exists in this state. The
sending or receiving of signaling that influences a dialog is not
performed. (A dialog is literally terminated.) The caller and
callee enter the Morgue state via the termination of the BYE or
INVITE transaction.
死体公示所(Morg): 対話はもうこの州に存在していません。 対話に影響を及ぼすシグナリングの発信か受信が実行されません。 (対話は文字通り終えられます。) 訪問者と訪問される人はBYEかINVITE取引の終了でMorgue状態に入ります。
3. Race Conditions
3. 競合条件
This section details a race condition between two SIP UAs, Alice and Bob. Alice (sip:alice@atlanta.example.com) and Bob (sip:bob@biloxi.example.com) are assumed to be SIP phones or SIP- enabled devices. Only significant signaling is illustrated. Dialog state transitions caused by the sending or receiving of SIP messages are shown, and race conditions are indicated by '*race*'. (For abbreviations for the dialog state transitions, refer to Section 2.) '*race*' indicates the moment when a race condition occurs.
このセクションは2SIP UAsと、アリスとボブの間の競合条件を詳しく述べます。 アリス(一口: alice@atlanta.example.com )とボブ(一口: bob@biloxi.example.com )がSIP電話であると思われたか、またはSIPは装置を可能にしました。 重要なシグナリングだけが例証されます。 'SIPメッセージの発信か受信で引き起こされた対話状態遷移は示されます、そして、競合条件は'*レース*'で示されます。 (対話状態遷移のための略語について、セクション2を参照してください。) '*レース*'は競合条件が起こる瞬間を示します。
Examples of race conditions are described below.
競合条件に関する例は以下で説明されます。
Hasebe, et al. Best Current Practice [Page 10] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[10ページ]RFC5407例の呼び出し流れ
3.1. Receiving Message in the Moratorium State
3.1. モラトリアム状態にメッセージを受け取ります。
This section shows some examples of call flow race conditions when receiving messages from other states while in the Moratorium state.
他の州からメッセージを受け取るとき、Moratorium状態にある間、このセクションは呼び出し流れ競合条件に関するいくつかの例を示しています。
3.1.1. Callee Receives Initial INVITE Retransmission (Preparative
State) While in the Moratorium State
3.1.1. 訪問される人はRetransmission(予備の状態)がモラトリアム状態でゆったり過ごす初期の招待を受けます。
State Alice Bob State
| |
| ini-INVITE F1 |
|------------------------------------>|
Pre | 180 F2(Packet loss) | Pre
| x<-----------------------|
| | Ear
| ini-INVITE F4(=F1) 200 F3 |
|------------------ --------------|
| \ / | Mora
| X |
| / \ |
|<----------------- ------------->| *race*
Mora | ACK F5 |
|------------------------------------>|
Est | | Est
| |
州のアリスボブ状態| | | F1をini招いてください。| |------------------------------------>| 前| 180 F2(パケット損失)| 前| x<。-----------------------| | | 耳| F4(F1と等しい)200F3をini招待してください。| |------------------ --------------| | \ / | モーラ| X| | / \ | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- ------------->| *レース*モーラ| ACK F5| |------------------------------------>| エスト| | エスト| |
This scenario illustrates the race condition that occurs when the UAS receives a Preparative message while in the Moratorium state. All provisional responses to the initial INVITE (ini-INVITE F1) are lost, and the UAC retransmits an ini-INVITE (F4). At the same time as this retransmission, the UAS generates a 200 OK (F3) to the ini-INVITE and terminates the INVITE server transaction, according to Section 13.3.1.4 of RFC 3261 [1].
Moratorium状態にある間、このシナリオはUASがPreparativeメッセージを受け取るとき起こる競合条件を例証します。 初期のINVITE(ini-INVITE F1)へのすべての暫定的な応答が無くなります、そして、UACはini-INVITE(F4)を再送します。 UASはこの「再-トランスミッション」と同時に200OK(F3)をini-INVITEに発生させて、INVITEサーバ取引を終えます、セクション13.3によると。.1 .4RFC3261[1]。
However, it is reported that terminating an INVITE server transaction when sending a 200 OK is an essential correction to SIP [7]. Therefore, the INVITE server transaction is not terminated by F3, and F4 MUST be handled properly as a retransmission.
しかしながら、200OKを送るときINVITEサーバ取引を終えるのが、SIP[7]への不可欠の修正であると報告されます。 したがって、INVITEサーバ取引はF3、およびF4 MUSTによって終えられません。「再-トランスミッション」として適切に扱われます。
In RFC 3261 [1], it is not specified whether the UAS retransmits 200 to the retransmission of ini-INVITE. Considering the retransmission of 200 triggered by a timer (the transaction user (TU) keeps retransmitting 200 based on T1 and T2 until it receives an ACK), according to Section 13.3.1.4 of RFC 3261 [1], it seems unnecessary to retransmit 200 when the UAS receives the retransmission of the ini-INVITE. (For implementation, it does not matter if the UAS sends the retransmission of 200, since the 200 does not cause any problem.)
RFC3261[1]では、UASがini-INVITEの「再-トランスミッション」に200を再送するかどうかは指定されません。 200の「再-トランスミッション」を考えると、タイマは引き金となりました(取引ユーザ(TU)はACKを受けるまでT1とT2に基づいて200を再送し続けます)、セクション13.3によると。.1 .4RFC3261[1]、UASがini-INVITEの「再-トランスミッション」を受けるとき、200を再送するのは不要に思えます。 (実現のために、UASが200の「再-トランスミッション」を送るかどうかは重要ではありません、200がどんな問題も引き起こさないので。)
Hasebe, et al. Best Current Practice [Page 11] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[11ページ]RFC5407例の呼び出し流れ
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
/* 180 response is lost and does not reach Alice. */
/*180応答は、無くなって、アリスに届きません。 */
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
/* According to Section 13.3.1.4 of RFC 3261 [1], the INVITE server
transaction is terminated at this point. However, this has been
reported as an essential correction to SIP, and the UAS MUST
correctly recognize the ini-INVITE (F4) as a retransmission. */
/、*セクション13.3.1に従って、.4RFC3261[1]、INVITEサーバ取引はここに終えられます。 しかしながら、これは不可欠の修正としてSIPに報告されました、そして、UAS MUSTはini-INVITE(F4)が「再-トランスミッション」であると正しく認めます。 */
F4 INVITE (retransmission) Alice -> Bob
F4は(「再-トランスミッション」)アリス・->ボブを招待します。
/* F4 is a retransmission of F1. They are exactly the same INVITE
request. For UAs that have not dealt with the correction [7] (an
INVITE server transaction is terminated when sending 200 to
INVITE), this request does not match the transaction as well as
the dialog since it does not have a To tag. However, Bob must
recognize the retransmitted INVITE correctly, without treating it
as a new INVITE. */
/*F4はF1の「再-トランスミッション」です。 それらはまさに同じINVITE要求です。 修正[7](200をINVITEに送るとき、INVITEサーバ取引は終えられます)に対処していないUAsに関しては、Toタグを持っていないので、この要求は対話と同様に取引に合っていません。 しかしながら、新しいINVITEとしてそれを扱わないで、ボブは正しく再送されたINVITEを認識しなければなりません。 */
F5 ACK Alice -> Bob
F5 ACKアリス・->ボブ
Hasebe, et al. Best Current Practice [Page 12] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[12ページ]RFC5407例の呼び出し流れ
3.1.2. Callee Receives CANCEL (Early State) While in the Moratorium
State
3.1.2. モラトリアム状態にある間、訪問される人はキャンセル(早めの状態)を受けます。
State Alice Bob State
| |
| INVITE F1 |
|----------------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------------|
Ear | | Ear
|CANCEL F3 200(INVITE) F4|
|------------ -------------|
| \ / | Mora
| X |
| / \ |
|<----------- ------------>| *race*
Mora | |
| ACK F6 200(CANCEL) F5|
|------------ -------------|
Est | \ / |
| X |
| / \ |
|<----------- ------------>|
| | Est
| One Way RTP Media |
| (Two Way RTP Media possible) |
|<=============================|
| BYE F7 |
|----------------------------->|
Mort | 200 F8 | Mort
|<-----------------------------|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
州のアリスボブ状態| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 前| 180 F2を鳴らすこと。| 前| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 耳| | 耳|F3 200(招待します)F4を取り消してください。| |------------ -------------| | \ / | モーラ| X| | / \ | | <、-、-、-、-、-、-、-、-、-、-- ------------>| *レース*モーラ| | | ACK F6 200(取り消します)F5| |------------ -------------| エスト| \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-、-- ------------>|、|、| エスト| 一方通行のRTPメディア| | (可能な2つのWay RTPメディア) | |<===============| | さようならF7| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 角笛の音| 200 F8| 角笛の音|<-----------------------------| | ^ ^ | | | タイマK| | | V| | Morg| タイマJ| | | V| | | Morg| |
This scenario illustrates the race condition that occurs when the UAS receives an Early message, CANCEL, while in the Moratorium state. Alice sends a CANCEL, and Bob sends a 200 OK response to the initial INVITE message at the same time. As described in the previous section, according to RFC 3261 [1], an INVITE server transaction is supposed to be terminated by a 200 response, but this has been corrected in [7].
このシナリオはUASがEarlyメッセージを受け取るとき起こる競合条件を例証します、キャンセル、Moratorium状態で。 アリスはキャンセルを送ります、そして、ボブは同時に、200OK応答を初期のINVITEメッセージに送ります。 RFC3261[1]に従って前項で説明されるように、200応答でINVITEサーバ取引は終えられるべきですが、[7]でこれを修正してあります。
Hasebe, et al. Best Current Practice [Page 13] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[13ページ]RFC5407例の呼び出し流れ
This section describes a case in which an INVITE server transaction is not terminated by a 200 response to the INVITE request. In this case, there is an INVITE transaction that the CANCEL request matches, so a 200 response to the request is sent. This 200 response simply means that the next hop receives the CANCEL request (successful CANCEL (200) does not mean the INVITE was actually canceled). When a UAS has not dealt with the correction [7], the UAC MAY receive a 481 response to the CANCEL since there is no transaction that the CANCEL request matches. This 481 simply means that there is no matching INVITE server transaction and CANCEL is not sent to the next hop. Regardless of the success/failure of the CANCEL, Alice checks the final response to the INVITE, and if she receives 200 to the INVITE request she immediately sends a BYE and terminates the dialog. (See Section 15, RFC 3261 [1].)
このセクションはINVITEサーバ取引がINVITE要求への200応答で終えられない場合について説明します。 この場合、キャンセルが合っているよう要求するINVITE取引があるので、要求への200応答を送ります。 この200応答は、次のホップがキャンセル要求を受け取ることを単に意味します(うまくいっているキャンセル(200)は、INVITEが実際に取り消されたことを意味しません)。 UASが修正[7]に対処していないとき、キャンセルが合っているよう要求する取引が全くないので、UAC MAYはキャンセルへの481応答を受けます。 この481は、合っているINVITEサーバ取引が全くないことを単に意味します、そして、キャンセルは次のホップに送られません。 キャンセルの成功/失敗にかかわらず、アリスはINVITEへの最終的な応答をチェックして、彼女が受信するなら、INVITEへの200は、彼女がすぐに、BYEを送って、対話を終えるよう要求します。 (セクション15、RFC3261[1]を見てください。)
From the time F1 is received by Bob until the time that F8 is sent by Bob, media may be flowing one way from Bob to Alice. From the time that an answer is received by Alice from Bob, there is the possibility that media may flow from Alice to Bob as well. However, once Alice has decided to cancel the call, she presumably will not send media, so practically speaking the media stream will remain one way.
時間F1から、ボブによってF8がボブによって送られる時にメディアがボブからアリスまでの一方通行の流れになるかもしれないまで受け取られます。 答えがアリスによってボブから受けられる時間から、メディアがアリスからまた、ボブまで流れるかもしれない可能性があります。 しかしながら、アリスが、呼び出しを中止するといったん決めると、彼女がおそらくメディアを送らないので、実際にメディアの流れを話すのは一方通行のままで残るでしょう。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 CANCEL Alice -> Bob
F3はアリス・->ボブを取り消します。
/* Alice sends a CANCEL in the Early state. */
/*アリスはEarly状態でキャンセルを送ります。 */
F4 200 OK (INVITE) Bob -> Alice
F4 200OK(招待する)ボブ・->アリス
/* Alice receives a 200 to INVITE (F1) in the Moratorium state.
Alice has the potential to send as well as receive media, but in
practice will not send because there is an intent to end the
call. */
/*アリスはMoratorium状態にINVITE(F1)に200を受け取ります。 アリスは、メディアを送って、受け取る可能性を持っていますが、呼び出しを終わらせる意図があるので、実際には発信しないでしょう。 */
F5 200 OK (CANCEL) Bob -> Alice
F5 200OK(取り消す)ボブ・->アリス
/* 200 to CANCEL simply means that the CANCEL was received. The 200
response is sent, since this case assumes the correction [7] has
been made. If an INVITE server transaction is terminated
according to the procedure stated in RFC 3261 [1], the UAC MAY
receive a 481 response instead of 200. */
キャンセルへの/*200は、キャンセルが受けられたことを単に意味します。 本件が、修正[7]をしたと仮定するので、200応答を送ります。 RFC3261[1]に述べられた手順によると、INVITEサーバ取引が終えられるなら、UAC MAYは200の代わりに481応答を受けます。 */
Hasebe, et al. Best Current Practice [Page 14] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[14ページ]RFC5407例の呼び出し流れ
F6 ACK Alice -> Bob
F6 ACKアリス・->ボブ
/* INVITE is successful, and the CANCEL becomes invalid. Bob
establishes RTP streams. However, the next BYE request
immediately terminates the dialog and session. */
/*INVITEは成功しています、そして、キャンセルは無効になります。 ボブはRTPの流れを確立します。しかしながら、次のBYE要求はすぐに、対話とセッションを終えます。 */
F7 BYE Alice -> Bob
F7さようならアリス・->ボブ
F8 200 OK Bob -> Alice
F8 200OKボブ・->アリス
3.1.3. Callee Receives BYE (Early State) While in the Moratorium State
3.1.3. モラトリアム状態にある間、訪問される人は、さようならを受けます(早めの状態)。
State Alice Bob State
| |
| ini-INVITE F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| BYE F4 200(INVITE) F3|
|------------- --------------|
Mort | \ / | Mora
| X |
| / \ |
|<------------ ------------->| *race*
| | Mort
| ACK F5 200(BYE) F6 |
|------------- --------------|
| \ / ^ |
| X | |
| / \ | |
|<------------ ------------->|
| ^ | |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
州のアリスボブ状態| | | F1をini招いてください。| |------------------------------->| 前| 180 F2| 前|<-------------------------------| 耳| | 耳| さようならF4 200(招待します)F3| |------------- --------------| 角笛の音| \ / | モーラ| X| | / \ | | <、-、-、-、-、-、-、-、-、-、-、-- ------------->| *レース*| | 角笛の音| ACK F5 200(さようなら)F6| |------------- --------------| | \ / ^ | | X| | | / \ | | | <、-、-、-、-、-、-、-、-、-、-、-- ------------->|、| ^ | | | | タイマK| | | V| | Morg| タイマJ| | | V| | | Morg| |
This scenario illustrates the race condition that occurs when the UAS receives an Early message, BYE, while in the Moratorium state. Alice sends a BYE in the Early state, and Bob sends a 200 OK to the initial INVITE request at the same time. Bob receives the BYE in the Confirmed dialog state although Alice sent the request in the Early state (as explained in Section 2 and Appendix A, this behavior is not recommended). When a proxy is performing forking, the BYE is only able to terminate the early dialog with a particular UA. If the
このシナリオはUASがEarlyメッセージを受け取るとき起こる競合条件を例証します、BYE、Moratorium状態で。 アリスはEarly状態でBYEを送ります、そして、ボブは同時に、初期のINVITE要求に200OKを送ります。 アリスはEarly状態で要求を送りましたが(セクション2とAppendix Aで説明されるように、この振舞いは推薦されません)、ボブはConfirmed対話状態にBYEを受け取ります。 プロキシが分岐を実行しているとき、BYEは特定のUAと共に早めの対話を終えることができるだけです。 the
Hasebe, et al. Best Current Practice [Page 15] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[15ページ]RFC5407例の呼び出し流れ
caller wants to terminate all early dialogs instead of only that with a particular UA, it needs to send CANCEL, not BYE. However, it is not illegal to send BYE in the Early state to terminate a specific early dialog if that is the caller's intent.
特定のUAがあるそれだけの代わりにすべての早めの対話を終える訪問者必需品、それはBYEではなく、キャンセルを送る必要があります。 しかしながら、特定の早めの対話を終えるためにEarly状態でBYEを送るのはそれが訪問者の意図であるなら不法ではありません。
The BYE functions normally even if it is received after the INVITE transaction termination because BYE differs from CANCEL, and is sent not to the request but to the dialog. Alice enters the Mortal state on sending the BYE request, and remains Mortal until the Timer K timeout occurs. In the Mortal state, the UAC does not establish a session even though it receives a 200 response to the INVITE. Even so, the UAC sends an ACK to 200 in order to complete the INVITE transaction. The ACK is always sent to complete the three-way handshake of the INVITE transaction (further explained in Appendix D below).
それをBYEがキャンセルと異なっているのでINVITE取引終了の後に受け取り、要求ではなく、対話に送っても、通常、BYEは機能します。 アリスは、BYEが要求する発信のときにMortal状態に入って、Timer Kタイムアウトが起こるまで、Mortalのままで残っています。 Mortal状態には、INVITEへの200応答を受けますが、UACはセッションを確立しません。 たとえそうだとしても、UACは、INVITE取引を完了するためにACKを200に送ります。 INVITE取引(以下のAppendix Dでさらに説明される)の3方向ハンドシェイクを終了するためにいつもACKを送ります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK (ini-INVITE) Bob -> Alice
F3 200OK(ini招待する)ボブ・->アリス
F4 BYE Alice -> Bob
F4さようならアリス・->ボブ
/* Alice transitions to the Mortal state upon sending BYE.
Therefore, after this, she does not begin a session even though
she receives a 200 response with an answer. */
BYEを送るとき、/*アリスはMortal状態に移行します。 したがって、この後、答えで200応答を受けますが、彼女は開会しません。 */
F5 ACK Alice -> Bob
F5 ACKアリス・->ボブ
F6 200 OK (BYE) Bob -> Alice
F6 200OK(さようなら)ボブ・->アリス
Hasebe, et al. Best Current Practice [Page 16] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[16ページ]RFC5407例の呼び出し流れ
3.1.4. Callee Receives re-INVITE (Established State) While in the
Moratorium State (Case 1)
3.1.4. モラトリアム状態にある間、訪問される人は再招待(状態を設置する)を受けます。(ケース1)
State Alice Bob State
| |
| ini-INVITE w/offer1 F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| 200(ini-INV) w/answer1 F3 |
|<-------------------------------|
Mora | ACK F4(packet loss) | Mora
|-------------------->x |
Est | |
| re-INVITE F6 200 F5(=F3) |
| w/offer2 w/answer1 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->| *race*
| 200(re-INV) F8|
| ACK F7(=F4) w/answer2 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK (re-INV) F9 | Est
|------------------------------->|
| |
| |
州のアリスボブ状態| | | offer1F1を伴うini-INVITE| |------------------------------->| 前| 180 F2| 前|<-------------------------------| 耳| | 耳| 200 answer1 F3がある(ini-INV)| |<-------------------------------| モーラ| ACK F4(パケット損失)| モーラ|-------------------->x| エスト| | | F6 200F5(F3と等しい)を再招待してください。| | answer1とoffer2で| |------------- --------------| | \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-、-、-- ------------->| *レース*| 200(再INV)F8| | answer2とACK F7(F4と等しいです)| |------------- --------------| | \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-、-、-- ------------->|、| ACK(再INV)F9| エスト|------------------------------->| | | | |
This scenario illustrates the race condition that occurs when a UAS in the Moratorium state receives a re-INVITE sent by a UAC in the Established state.
このシナリオはMoratorium状態のUASがEstablished状態でUACによって送られた再INVITEを受けるとき起こる競合条件を例証します。
The UAS receives a re-INVITE (with offer2) before receiving an ACK for the ini-INVITE (with offer1). The UAS sends a 200 OK (with answer2) to the re-INVITE (F8) because it has sent a 200 OK (with answer1) to the ini-INVITE (F3, F5) and the dialog has already been established. (Because F5 is a retransmission of F3, SDP negotiation is not performed here.)
ini-INVITE(offer1と)のためにACKを受ける前に、UASは再INVITE(offer2と)を受けます。 200OK(answer1と)をini-INVITE(F3、F5)に送って、対話が既に確立されたので、UASは200OK(answer2と)を再INVITE(F8)に送ります。 (F5がF3の「再-トランスミッション」であるので、SDP交渉はここで実行されません。)
As can be seen in Section 3.3.2 below, the 491 response seems to be closely related to session establishment, even in cases other than INVITE crossover. This example recommends that 200 be sent instead
セクション3.3.2未満で見ることができるように、491応答は密接にセッション設立に関連したように思えます、INVITE横断歩道以外の場合でさえ。この例は、200が代わりに送られることを勧めます。
Hasebe, et al. Best Current Practice [Page 17] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[17ページ]RFC5407例の呼び出し流れ
of 491 because it does not have an influence on the session. However, a 491 response can also lead to the same outcome, so either response can be used.
491では、影響しないので、セッションのときに影響してください。 しかしながら、また、491応答が同じ結果につながることができるので、応答を使用できます。
Moreover, if the UAS doesn't receive an ACK for a long time, it should send a BYE and terminate the dialog. Note that ACK F7 has the same CSeq number as ini-INVITE F1 (see Section 13.2.2.4 of RFC 3261 [1]). The UA should not reject or drop the ACK on grounds of the CSeq number.
そのうえ、UASが長い間ACKを受けないなら、それは、BYEを送って、対話を終えるべきです。 セクション13.2を見てください。ACK F7にはini-INVITE F1と同じCSeq番号があることに注意してください、(.2 .4RFC3261[1])。 UAはCSeq番号の理由でACKを拒絶するはずがありませんし、また落とすはずがありません。
Note: Implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. The caller can delay sending re-INVITE F6 for some period of time (2 seconds, perhaps), after which the caller can reasonably assume that its ACK has been received. Implementors can decouple the actions of the user (e.g., pressing the hold button) from the actions of the protocol (the sending of re-INVITE F6), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful to prevent the type of race condition shown in this section. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
以下に注意してください。 このドキュメントの範囲の外に導入問題がありますが、以下のチップは、このタイプの競合条件を避けながら、備えられます。 訪問者は、いつかの期間(恐らく2秒)の間、再INVITE F6を送るのを遅らせることができます。(その時、訪問者は、ACKが受け取られたと合理的に仮定したことができました後)。 作成者はプロトコル(再INVITE F6の発信)の動作からユーザ(例えば、成立ボタンを押す)の動作の衝撃を吸収できます、UAがこのように振る舞うことができるように。 この場合、それはどのように長く待つかに関する作成者の選択です。 多くの場合、そのような実現は、このセクションで示された競合条件のタイプを防ぐために役に立つかもしれません。 このドキュメントは、彼らが、ACKが届けられるのを待つべきであるかどうかと好みを全く言い表しません。 ユーザー・エクスペリエンスへの影響を考えた後に、作成者は、しばらく待つかどうか決めるべきです、ユーザー・エクスペリエンスが実現によって、プロトコルの振舞いに直接の関係を全く持っていないので。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP 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: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: <sip:alice@client.atlanta.example.com;transport=udp> Content-Type: application/sdp Content-Length: 137
INVITE一口: bob@biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf9マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、呼び出しID: 3848276298220188511@atlanta.example.com CSeq: 1 接触を招いてください: <一口: alice@client.atlanta.example.com;transport がudpと等しい、gt;、コンテントタイプ: sdp Contentアプリケーション/長さ: 137
v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0v=0 o=alice2890844526 2890844526IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000
Hasebe, et al. Best Current Practice [Page 18] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[18ページ]RFC5407例の呼び出し流れ
/* Detailed messages are shown for the sequence to illustrate the
offer and answer examples. */
系列が申し出と答えの例を例証するように、*詳細な/メッセージは示されます。 */
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
SIP/2.0 180 Ringing Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: <sip:bob@client.biloxi.example.com;transport=udp> Content-Length: 0
以下を通って鳴る一口/2.0 180 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチ=z9hG4bK74bf9;は=192.0.2.101From:を受けました。 アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 1 接触を招いてください: <一口: bob@client.biloxi.example.com;transport はudp>コンテンツの長さと等しいです: 0
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: <sip:bob@client.biloxi.example.com;transport=udp> Content-Type: application/sdp Content-Length: 133
以下を通って一口/2.0 200OK 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチ=z9hG4bK74bf9;は=192.0.2.101From:を受けました。 アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 1 接触を招いてください: <一口: bob@client.biloxi.example.com;transport はudp>コンテントタイプと等しいです: sdp Contentアプリケーション/長さ: 133
v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0ボブの2890844527 2890844527IN IP4 client.biloxi.example.com s=c=IN IP4 192.0.2.201v=0o=t=m=オーディオの3456RTP/AVP0a=rtpmap: 0PCMU/8000
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
ACK一口: bob@client.biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bKnashd8マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、;=8321234356にタグ付けをしてください
Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0
呼び出しID: 3848276298220188511@atlanta.example.com CSeq: 1 ACKコンテンツの長さ: 0
Hasebe, et al. Best Current Practice [Page 19] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[19ページ]RFC5407例の呼び出し流れ
/* The ACK request is lost. */
ACKが要求する/*は無くなっています。 */
F5(=F3) 200 OK Bob -> Alice (retransmission)
F5(F3と等しい)200はボブ・->アリスを承認します。(「再-トランスミッション」)
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
/、*ACKを受けていないので、UASは200OKをini-INVITEに再送します。 */
F6 re-INVITE Alice -> Bob
F6はアリス・->ボブを再招待します。
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Length: 147
INVITE一口:一口: bob@client.biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf91マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 2 コンテンツの長さを招待してください: 147
v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly
0 0v=0 o=alice2890844526 2890844527IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000a=sendonly
F7(=F4) ACK Alice -> Bob (retransmission)
F7(F4と等しい)ACKアリス・->ボブ(「再-トランスミッション」)
/* "(=F4)" of ACK F7 shows that it is equivalent to F4 in that it is
an ACK for F3. This doesn't mean that F4 and F7 must be equal in
Via-branch value. Although it is ambiguous in RFC 3261 whether
the Via-branch of ACK F7 differs from that of F4, it doesn't
affect the UAS's behavior. */
「(F4と等しいです)」というACK F7の/*は、それがF3のためのACKであるのでF4に同等であることを示します。 これは、F4とF7がVia-ブランチ値において等しいに違いないことを意味しません。 ACK F7のVia-ブランチがF4のものと異なっているか否かに関係なく、RFC3261であいまいですが、それはUASの振舞いに影響しません。 */
F8 200 OK (re-INVITE) Bob -> Alice
F8 200OK(再招待する)ボブ・->アリス
SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Max-Forwards: 70
以下を通って一口/2.0 200OK 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf91マックスと等しいです: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Length: 143
From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 2 コンテンツの長さを招待してください: 143
Hasebe, et al. Best Current Practice [Page 20] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[20ページ]RFC5407例の呼び出し流れ
v=0 o=bob 2890844527 2890844528 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=recvonly
0 0ボブの2890844527 2890844528IN IP4 client.biloxi.example.com s=c=IN IP4 192.0.2.201v=0o=t=m=オーディオの3456RTP/AVP0a=rtpmap: 0PCMU/8000a=recvonly
F9 ACK (re-INVITE) Alice -> Bob
F9 ACK(再招待する)アリス・->ボブ
ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 ACK Content-Length: 0
ACK一口:一口: bob@client.biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK230f21マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 2 ACKコンテンツの長さ: 0
Hasebe, et al. Best Current Practice [Page 21] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[21ページ]RFC5407例の呼び出し流れ
3.1.5. Callee Receives re-INVITE (Established State) While in the
Moratorium State (Case 2)
3.1.5. モラトリアム状態にある間、訪問される人は再招待(状態を設置する)を受けます。(ケース2)
State Alice Bob State
| |
| ini-INVITE (no offer) F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| 200(ini-INV) w/offer1 F3 |
|<-------------------------------|
Mora | ACK w/answer1 F4(packet loss) | Mora
|-------------------->x |
Est | |
| re-INVITE F6 200 F5(=F3) |
| w/offer2 w/offer1 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK F7(=F4) 491(re-INV) F8|
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK (re-INV) F9 | Est
|------------------------------->|
| |
| |
州のアリスボブ状態| | | ini-INVITE(ノー・オファー)F1| |------------------------------->| 前| 180 F2| 前|<-------------------------------| 耳| | 耳| 200 offer1 F3がある(ini-INV)| |<-------------------------------| モーラ| answer1 F4(パケット損失)とACK| モーラ|-------------------->x| エスト| | | F6 200F5(F3と等しい)を再招待してください。| | offer1とoffer2で| |------------- --------------| | \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-、-、-- ------------->|、| ACK F7(F4と等しい)491(再INV)F8| |------------- --------------| | \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-、-、-- ------------->|、| ACK(再INV)F9| エスト|------------------------------->| | | | |
This scenario is basically the same as that of Section 3.1.4, but differs in sending an offer in the 200 and an answer in the ACK. In contrast to the previous case, the offer in the 200 (F3) and the offer in the re-INVITE (F6) collide with each other.
このシナリオは、セクション3.1.4のものと基本的に同じですが、ACKで200と答えにおける申し出を送るのにおいて異なります。 先の事件と対照して、200(F3)における申し出と再INVITE(F6)の申し出は互いと衝突します。
Bob sends a 491 to the re-INVITE (F6) since he is not able to properly handle a new request until he receives an answer. (Note: 500 with a Retry-After header may be returned if the 491 response is understood to indicate request collision. However, 491 is recommended here because 500 applies to so many cases that it is difficult to determine what the real problem was.) The same result will be reached if F6 is an UPDATE with offer.
彼が答えを受けるまで適切に新しい要求を扱うことができないので、ボブは再INVITE(F6)に491を送ります。 (以下に注意してください。 要求衝突を示すのを491応答を理解しているなら、後のRetryヘッダーがある500を返すかもしれません。 しかしながら、500が、申し込むので491がここでお勧めであるので、それが難しい多くのケースが、実際の問題が何であったかを決定します。) 同じ結果にF6が申し出があるUPDATEであるなら達するでしょう。
Hasebe, et al. Best Current Practice [Page 22] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[22ページ]RFC5407例の呼び出し流れ
Note: As noted in Section 3.1.4, the caller may delay sending a re- INVITE F6 for some period of time (2 seconds, perhaps), after which the caller may reasonably assume that its ACK has been received, to prevent this type of race condition. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
以下に注意してください。 セクション3.1.4で注意されるように、訪問者は、いつかの期間(恐らく2秒)の間、再INVITE F6を送るのを遅らせるかもしれません。(その時、訪問者は、ACKがこのタイプの競合条件を防ぐために受け取られたと合理的に仮定したかもしれません後)。 このドキュメントは、彼らが、ACKが届けられるのを待つべきであるかどうかと好みを全く言い表しません。 ユーザー・エクスペリエンスへの影響を考えた後に、作成者は、しばらく待つかどうか決めるべきです、ユーザー・エクスペリエンスが実現によって、プロトコルの振舞いに直接の関係を全く持っていないので。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP 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: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: <sip:alice@client.atlanta.example.com;transport=udp> Content-Length: 0
INVITE一口: bob@biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf9マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、呼び出しID: 3848276298220188511@atlanta.example.com CSeq: 1 接触を招いてください: <一口: alice@client.atlanta.example.com;transport がudpと等しい、gt;、コンテンツの長さ: 0
/* The request does not contain an offer. Detailed messages are
shown for the sequence to illustrate offer and answer
examples. */
要求がする/*は申し出を含んでいません。 系列が申し出と答えの例を例証するように、詳細なメッセージは示されます。 */
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 ;received=192.0.2.101 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: <sip:bob@client.biloxi.example.com;transport=udp> Content-Type: application/sdp Content-Length: 133
以下を通って一口/2.0 200OK 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチ=z9hG4bK74bf9;は=192.0.2.101From:を受けました。 アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 1 接触を招いてください: <一口: bob@client.biloxi.example.com;transport はudp>コンテントタイプと等しいです: sdp Contentアプリケーション/長さ: 133
v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201
v=0oはボブの2890844527 2890844527IN IP4 client.biloxi.example.com s=c=IN IP4 192.0.2.201と等しいです。
Hasebe, et al. Best Current Practice [Page 23] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[23ページ]RFC5407例の呼び出し流れ
t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
オーディオの3456RTP/AVP0 0 0t=m=a=rtpmap: 0PCMU/8000
/* An offer is made in 200. */
申し出が200でされる/*。 */
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Type: application/sdp Content-Length: 137
ACK一口: bob@client.biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bKnashd8マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 1 ACKコンテントタイプ: sdp Contentアプリケーション/長さ: 137
v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0v=0 o=alice2890844526 2890844526IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000
/* The request contains an answer, but the request is lost. */
/、*要求は答えを含んでいますが、要求は無くなっています。 */
F5(=F3) 200 OK Bob -> Alice (retransmission)
F5(F3と等しい)200はボブ・->アリスを承認します。(「再-トランスミッション」)
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
/、*ACKを受けていないので、UASは200OKをini-INVITEに再送します。 */
F6 re-INVITE Alice -> Bob
F6はアリス・->ボブを再招待します。
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Length: 147
INVITE一口:一口: bob@client.biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf91マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 2 コンテンツの長さを招待してください: 147
v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101
v=0 o=alice2890844526 2890844527IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101
Hasebe, et al. Best Current Practice [Page 24] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[24ページ]RFC5407例の呼び出し流れ
t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly
オーディオの49172RTP/AVP0 0 0t=m=a=rtpmap: 0PCMU/8000a=sendonly
/* The request contains an offer. */
/、*要求は申し出を含んでいます。 */
F7(=F4) ACK Alice -> Bob (retransmission)
F7(F4と等しい)ACKアリス・->ボブ(「再-トランスミッション」)
/* A retransmission triggered by the reception of a retransmitted
200. "(=F4)" of ACK F7 shows that it is equivalent to the F4 in
that it is an ACK for F3. This doesn't mean that F4 and F7 are
necessarily equal in Via-branch value. Although it is ambiguous
in RFC 3261 whether the Via-branch of ACK F7 differs from that of
F4, it doesn't affect the UAS's behavior. */
「再-トランスミッション」がaのレセプションで引き金となった/*は200を再送しました。 ACK F7の「(=F4)」は、それがF3のためのACKであるのでF4に同等であることを示します。 これは、F4とF7が必ずVia-ブランチ値において等しいことを意味しません。 ACK F7のVia-ブランチがF4のものと異なっているか否かに関係なく、RFC3261であいまいですが、それはUASの振舞いに影響しません。 */
F8 491 (re-INVITE) Bob -> Alice
F8 491(再招待します)ボブ・->アリス
/* Bob sends 491 (Request Pending), since Bob has a pending
offer. */
ボブには未定の申し出があるので、/*ボブは491(Pendingを要求する)を送ります。 */
F9 ACK (re-INVITE) Alice -> Bob
F9 ACK(再招待する)アリス・->ボブ
Hasebe, et al. Best Current Practice [Page 25] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[25ページ]RFC5407例の呼び出し流れ
3.1.6. Callee Receives BYE (Established State) While in the Moratorium
State
3.1.6. モラトリアム状態にある間、訪問される人は、さようならを受けます(状態を設置します)。
State Alice Bob State
| |
| INVITE F1 |
|-------------------------->|
Pre | 180 Ringing F2 | Pre
|<--------------------------|
Ear | | Ear
| 200 OK F3 |
|<--------------------------|
Mora | ACK F4(packet loss) | Mora
|--------------->x |
Est | Both Way RTP Media |
|<=========================>|
| BYE F6 200 F5(=F3)|
|----------- -----------|
Mort | \ / |
| X |
| / \ |
|<---------- ---------->| *race*
|ACK F7(=F4) 200(BYE) F8| Mort
|----------- -----------|
| \ / |
| X |
| / \ |
|<---------- ---------->|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
州のアリスボブ状態| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 前| 180 F2を鳴らすこと。| 前| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 耳| | 耳| 200 OK F3| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| モーラ| ACK F4(パケット損失)| モーラ|--------------->x| エスト| 両方、道のRTPメディア| |<=============>|、| さようなら、F6 200F5(F3と等しいです)| |----------- -----------| 角笛の音| \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-- ---------->| *レース*|ACK F7(F4と等しい)200(さようなら)F8| 角笛の音|----------- -----------| | \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-- ---------->|、| ^ ^ | | | タイマK| | | V| | Morg| タイマJ| | | V| | | Morg| |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, BYE, while in the Moratorium state. An ACK request for a 200 OK response is lost (or delayed). Bob retransmits the 200 OK to the ini-INVITE, and at the same time Alice sends a BYE request and terminates the session. Upon receipt of the retransmitted 200 OK, Alice's UA might be inclined to reestablish the session. But that is wrong -- the session should not be reestablished when the dialog is in the Mortal state. Moreover, in the case where the UAS sends an offer in a 200 OK, the UAS should not start a session again, for the same reason, if the UAS receives a retransmitted ACK after receiving a BYE.
このシナリオはUASがEstablishedメッセージを受け取るとき起こる競合条件を例証します、BYE、Moratorium状態で。 200OK応答を求めるACK要求は無くなっています(または、遅らせられます)。 ボブは、同時間アリスのときに200OKをini-INVITEに再送して、BYE要求を送って、セッションを終えます。 再送された200OKを受け取り次第、アリスのUAはセッションを回復させる傾向があるかもしれません。 しかし、それは間違っています--対話がMortal状態にあるとき、セッションは回復するべきではありません。 そのうえ、UASが200OKにおける申し出を送る場合では、UASは再びセッションを始めるはずがありません、同じ理由から、UASが不戦勝を得た後に再送されたACKを受けるなら。
Hasebe, et al. Best Current Practice [Page 26] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[26ページ]RFC5407例の呼び出し流れ
Note: As noted in Section 3.1.4, implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. The caller can delay sending BYE F6 for some period of time (2 seconds, perhaps), after which the caller can reasonably assume that its ACK has been received. Implementors can decouple the actions of the user (e.g., hanging up) from the actions of the protocol (the sending of BYE F6), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful to prevent the type of race condition shown in this section. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
以下に注意してください。 セクション3.1.4で注意されるように、このドキュメントの範囲の外に導入問題がありますが、以下のチップはこのタイプの競合条件を避けながら、備えられます。 訪問者は、いつかの期間(恐らく2秒)の間、BYE F6を送るのを遅らせることができます。(その時、訪問者は、ACKが受け取られたと合理的に仮定できました後)。 作成者はプロトコル(BYE F6の発信)の動作からユーザ(例えば、ハングアップする)の動作の衝撃を吸収できます、UAがこのように振る舞うことができるように。 この場合、それはどのように長く待つかに関する作成者の選択です。 多くの場合、そのような実現は、このセクションで示された競合条件のタイプを防ぐために役に立つかもしれません。 このドキュメントは、彼らが、ACKが届けられるのを待つべきであるかどうかと好みを全く言い表しません。 ユーザー・エクスペリエンスへの影響を考えた後に、作成者は、しばらく待つかどうか決めるべきです、ユーザー・エクスペリエンスが実現によって、プロトコルの振舞いに直接の関係を全く持っていないので。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
/* ACK request is lost. */
ACKが要求する/*は無くなっています。 */
F5(=F3) 200 OK Bob -> Alice
F5(F3と等しい)200はボブ・->アリスを承認します。
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
/、*ACKを受けていないので、UASは200OKをini-INVITEに再送します。 */
F6 BYE Alice -> Bob
F6さようならアリス・->ボブ
/* Bob retransmits a 200 OK and Alice sends a BYE at the same time.
Alice transitions to the Mortal state, so she does not begin a
session after this even though she receives a 200 response to the
re-INVITE. */
/*ボブは200OKを再送します、そして、アリスは同時に、BYEを送ります。 Mortal状態へのアリス変遷、したがって、再INVITEへの200応答を受けますが、彼女はこの後、開会しません。 */
F7(=F4) ACK Alice -> Bob
F7(F4と等しい)ACKアリス・->ボブ
/* "(=F4)" of ACK F7 shows that it is equivalent to the F4 in that it
is an ACK for F3. This doesn't mean that F4 and F7 must be equal
in Via-branch value. Although it is ambiguous in RFC 3261 whether
the Via-branch of ACK F7 differs from that of F4, it doesn't
affect the UAS's behavior. */
「(F4と等しいです)」というACK F7の/*は、それがF3のためのACKであるのでF4に同等であることを示します。 これは、F4とF7がVia-ブランチ値において等しいに違いないことを意味しません。 ACK F7のVia-ブランチがF4のものと異なっているか否かに関係なく、RFC3261であいまいですが、それはUASの振舞いに影響しません。 */
Hasebe, et al. Best Current Practice [Page 27] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[27ページ]RFC5407例の呼び出し流れ
F8 200 OK (BYE) Bob -> Alice
F8 200OK(さようなら)ボブ・->アリス
/* Bob sends a 200 OK to the BYE. */
/*ボブは200OKをBYEに送ります。 */
3.2. Receiving Message in the Mortal State
3.2. 致命的な状態にメッセージを受け取ります。
This section shows some examples of call flow race conditions when receiving messages from other states while in the Mortal state.
他の州からメッセージを受け取るとき、Mortal状態にある間、このセクションは呼び出し流れ競合条件に関するいくつかの例を示しています。
3.2.1. UA Receives BYE (Established State) While in the Mortal State
3.2.1. 致命的な状態にある間、UAは、さようならを受けます(状態を設置します)。
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| BYE F5 BYE F6 |
|--------- ----------|
Mort | \ / | Mort
| X |
| / \ |
|<-------- --------->| *race*
| |
| 200 F8 200 F7 |
|--------- ----------|
| \ / |
| X |
| / \ |
|<-------- --------->|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
州のアリスボブ状態| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 前| 180 F2を鳴らすこと。| 前| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 耳| | 耳| 200 OK F3| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| モーラ| ACK F4| モーラ|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| エスト| 両方、道のRTPメディア| エスト|<===========>|、|、|、| さようならF5さようならF6| |--------- ----------| 角笛の音| \ / | 角笛の音| X| | / \ | | <、-、-、-、-、-、-、-- --------->| *レース*| | | 200 F8 200F7| |--------- ----------| | \ / | | X| | / \ | | <、-、-、-、-、-、-、-- --------->|、| ^ ^ | | | タイマK| | | V| | Morg| タイマJ| | | V| | | Morg| |
Hasebe, et al. Best Current Practice [Page 28] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[28ページ]RFC5407例の呼び出し流れ
This scenario illustrates the race condition that occurs when the UAS receives an Established message, BYE, while in the Mortal state. Alice and Bob send a BYE at the same time. A dialog and session are ended shortly after a BYE request is passed to a client transaction. As shown in Section 2, the UA remains in the Mortal state.
このシナリオはUASがEstablishedメッセージを受け取るとき起こる競合条件を例証します、BYE、Mortal状態で。 アリスとボブは同時に、BYEを送ります。 BYE要求がクライアント取引に合格された後に対話とセッションはまもなく、終わります。 セクション2に示されるように、UAはMortal州に残っています。
UAs in the Mortal state return error responses to the requests that operate within a dialog or session, such as re-INVITE, UPDATE, or REFER. However, the UA shall return a 200 OK to the BYE taking the use case into consideration where a caller and a callee exchange reports about the session when it is being terminated. (Since the dialog and the session both terminate when a BYE is sent, the choice of sending a 200 or an error response upon receiving a BYE while in the Mortal state does not affect the resulting termination. Therefore, even though this example uses a 200 response, other responses can also be used.)
Mortal状態のUAsは対話かセッション以内に作動する要求への誤り応答を返します、再INVITE、UPDATE、またはREFERなどのように。 しかしながら、UAは訪問者と訪問される人交換がそれが終えられる予定であるセッション頃に報告するところで使用が考慮にケースに入れるBYEの取りに200OKを返すものとします。 (BYEを送るとき、対話とセッションがともに終わるので、200を送ることの選択かMortal状態にある間、不戦勝を得るときの誤り応答が結果として起こる終了に影響しません。 したがって、この例は200応答を使用しますが、また、他の応答を使用できます。)
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
F5 BYE Alice -> Bob
F5さようならアリス・->ボブ
/* The session is terminated at the moment Alice sends a BYE. The
dialog still exists then, but it is certain to be terminated in a
short period of time. The dialog is completely terminated when
the timeout of the BYE request occurs. */
アリスがBYEを送るとすぐに、セッションが終えられる/*。 対話はその時、まだ存在していますが、短時間に終えられるのは確かです。 BYE要求のタイムアウトが起こるとき、対話は完全に終えられます。 */
F6 BYE Bob -> Alice
F6さようならボブ・->アリス
/* Bob has also transmitted a BYE simultaneously with Alice. Bob
terminates the session and the dialog. */
また、/*ボブは同時に、アリスと共にBYEを伝えました。 ボブはセッションと対話を終えます。 */
F7 200 OK Bob -> Alice
F7 200OKボブ・->アリス
/* Since the dialog is in the Moratorium state, Bob responds with a
200 to the BYE request. */
対話以来の/*がMoratorium状態にあって、ボブは200でBYE要求に応じます。 */
Hasebe, et al. Best Current Practice [Page 29] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[29ページ]RFC5407例の呼び出し流れ
F8 200 OK Alice -> Bob
F8 200OKアリス・->ボブ
/* Since Alice has transitioned from the Established state to the
Mortal state by sending a BYE, Alice responds with a 200 to the
BYE request. */
アリス以来の/*はBYEを送ることによって、Established状態からMortal状態に移行して、アリスは200でBYE要求に応じます。 */
3.2.2. UA Receives re-INVITE (Established State) While in the Mortal
State
3.2.2. 致命的な状態にある間、UAは再招待(状態を設置する)を受けます。
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| BYE F5 re-INVITE F6|
|--------- ----------|
Mort | \ / |
| X |
| / \ |
*race* |<-------- --------->|
| | Mort
| 481 F8 200 F7 |
| (re-INV) (BYE) |
|--------- ----------|
| \ / |^
| X ||
| / \ ||Timer J
|<-------- --------->||
^| ACK (re-INV) F9 ||
||<-----------------------||
Timer K|| ||
V| ||
Morg | |V
| | Morg
| |
州のアリスボブ状態| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 前| 180 F2を鳴らすこと。| 前| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 耳| | 耳| 200 OK F3| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| モーラ| ACK F4| モーラ|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| エスト| 両方、道のRTPメディア| エスト|<===========>|、|、|、| さようならF5はF6を再招待します。| |--------- ----------| 角笛の音| \ / | | X| | / \ | *レース*| <、-、-、-、-、-、-、-- --------->|、|、| 角笛の音| 481 F8 200F7| | (再INV) (さようなら) | |--------- ----------| | \ / |^ | X|| | / \ ||タイマJ| <、-、-、-、-、-、-、-- --------->|、| ^| ACK(再INV)F9|| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| タイマK|| || V| || Morg| |V| | Morg| |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, re-INVITE, while in the Mortal state. Bob sends a re-INVITE, and Alice sends a BYE at the same
このシナリオはUASがEstablishedメッセージを受け取るとき起こる競合条件を例証します、再INVITE、Mortal状態で。 ボブは再INVITEを送ります、そして、アリスは同じくらいでBYEを送ります。
Hasebe, et al. Best Current Practice [Page 30] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[30ページ]RFC5407例の呼び出し流れ
time. The re-INVITE receives a 481 response since the TU of Alice has transitioned from the Established state to the Mortal state by sending BYE. Bob sends an ACK for the 481 response because the ACK for error responses is handled by the transaction layer and, at the point of receiving the 481, the INVITE client transaction still remains (even though the dialog has been terminated).
時間。 アリスのTUがBYEを送ることによってEstablished状態からMortal状態に移行したので、再INVITEは481応答を受けます。 誤り応答のためのACKが取引層によって扱われるので、ボブは481応答のためにACKを送ります、そして、481を受け取る意味では、INVITEクライアント取引はまだ留まっています(対話が終えられましたが)。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
F5 BYE Alice -> Bob
F5さようならアリス・->ボブ
/* Alice sends a BYE and terminates the session, and transitions from
the Established state to the Mortal state. */
/*アリスは、BYEを送って、セッションを終えて、Established状態からMortal状態に移行します。 */
F6 re-INVITE Bob -> Alice
F6はボブ・->アリスを再招待します。
/* Alice sends a BYE, and Bob sends a re-INVITE at the same time.
The dialog state transitions to the Mortal state at the moment
Alice sends the BYE, but Bob does not know this until he receives
the BYE. Therefore, the dialog is in the Terminated state from
Alice's point of view, but in the Confirmed state from Bob's point
of view. A race condition occurs. */
/*アリスはBYEを送ります、そして、ボブは同時に、再INVITEを送ります。 Mortalへの対話状態遷移は、現在、アリスがBYEを送ると述べますが、彼がBYEを受け取るまで、ボブはこれを知りません。 したがって、対話は、Terminated状態でアリスの観点から来ていますが、ボブの観点からのConfirmed状態にあります。 競合条件は起こります。 */
F7 200 OK (BYE) Bob -> Alice
F7 200OK(さようなら)ボブ・->アリス
F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob
F8 481呼び出し/取引が存在していない、(再招待します)アリス・->ボブ
/* Since Alice is in the Mortal state, she responds with a 481 to the
re-INVITE. */
アリス以来の/*がMortal状態にあって、彼女は481で再INVITEに応じます。 */
F9 ACK (re-INVITE) Bob -> Alice
F9 ACK(再招待する)ボブ・->アリス
/* ACK for an error response is handled by Bob's INVITE client
transaction. */
誤り応答のための/*ACKはボブのINVITEクライアント取引で扱われます。 */
Hasebe, et al. Best Current Practice [Page 31] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[31ページ]RFC5407例の呼び出し流れ
3.2.3. UA Receives 200 OK for re-INVITE (Established State) While in
the Mortal State
3.2.3. 致命的な状態にある間、UAは再招待(状態を設置する)のために200OKを受け取ります。
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| re-INVITE F5 |
|<-----------------------|
| 200 F7 BYE F6 |
|--------- ----------|
| \ / | Mort
| X |
| / \ |
|<-------- --------->| *race*
Mort | 200 F8 ACK F9 |
| (BYE) (re-INV) |
|--------- ----------|
| ^ \ / |
| | X |
| | / \ |
|<-------- --------->|
| | ^ |
| | Timer K | |
| | V |
| | Timer J | Morg
| V |
Morg | |
| |
州のアリスボブ状態| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 前| 180 F2を鳴らすこと。| 前| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 耳| | 耳| 200 OK F3| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| モーラ| ACK F4| モーラ|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| エスト| 両方、道のRTPメディア| エスト|<===========>|、|、|、| F5を再招待してください。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 200 F7さようならF6| |--------- ----------| | \ / | 角笛の音| X| | / \ | | <、-、-、-、-、-、-、-- --------->| *レース*角笛の音| 200 F8 ACK F9| | (さようなら) (再INV) | |--------- ----------| | ^ \ / | | | X| | | / \ | | <、-、-、-、-、-、-、-- --------->|、|、| ^ | | | タイマK| | | | V| | | タイマJ| Morg| V| Morg| | | |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, 200 to a re-INVITE, while in the Mortal state. Bob sends a BYE immediately after sending a re-INVITE. (For example, in the case of a telephone application, it is possible that a user hangs up the phone immediately after refreshing the session.) Bob sends an ACK for a 200 response to INVITE while in the Mortal state, completing the INVITE transaction.
このシナリオはUASがEstablishedメッセージを受け取るとき起こる競合条件を例証します、200対1再INVITE、Mortal状態で。 再INVITEを送る直後ボブはBYEを送ります。 (例えば、電話アプリケーションの場合では、セッションをリフレッシュする直後ユーザが受話器をかけるのは、可能です。) Mortal状態にある間、INVITE取引を完了して、ボブはINVITEへの200応答のためにACKを送ります。
Hasebe, et al. Best Current Practice [Page 32] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[32ページ]RFC5407例の呼び出し流れ
Note: As noted in Section 3.1.4, implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. The UAC can delay sending a BYE F6 until the re-INVITE transaction F5 completes. Implementors can decouple the actions of the user (e.g., hanging up) from the actions of the protocol (the sending of BYE F6), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful in preventing the type of race condition described in this section. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
以下に注意してください。 セクション3.1.4で注意されるように、このドキュメントの範囲の外に導入問題がありますが、以下のチップはこのタイプの競合条件を避けながら、備えられます。 UACは、F5が完了する再INVITE取引までBYE F6を送るのを遅らせることができます。 作成者はプロトコル(BYE F6の発信)の動作からユーザ(例えば、ハングアップする)の動作の衝撃を吸収できます、UAがこのように振る舞うことができるように。 この場合、それはどのように長く待つかに関する作成者の選択です。 多くの場合、そのような実現はこのセクションで説明された競合条件のタイプを防ぐ際に役に立つかもしれません。 このドキュメントは、彼らが、ACKが届けられるのを待つべきであるかどうかと好みを全く言い表しません。 ユーザー・エクスペリエンスへの影響を考えた後に、作成者は、しばらく待つかどうか決めるべきです、ユーザー・エクスペリエンスが実現によって、プロトコルの振舞いに直接の関係を全く持っていないので。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
F5 re-INVITE Bob -> Alice
F5はボブ・->アリスを再招待します。
INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 Session-Expires: 300;refresher=uac Supported: timer Max-Forwards: 70 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0
INVITE一口: alice@client.atlanta.example.com SIP/2.0Via: 一口/2.0/UDP client.biloxi.example.com: 5060; ブランチ=z9hG4bKnashd7はセッションで期限が切れます: 300; uacが支えた酒=: タイママックス-フォワード: 70 From: ボブ<一口: bob@biloxi.example.com 、gt;、;=8321234356To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; =9fxced76sl呼び出しIDにタグ付けをしてください: 3848276298220188511@atlanta.example.com CSeq: 1 コンテンツの長さを招待してください: 0
/* Some detailed messages are shown for the sequence to illustrate
that the re-INVITE is handled in the usual manner in the Mortal
state. */
系列が、再INVITEが常法でMortal状態で扱われるのを例証するようにいくつかの詳細なメッセージが示される/*。 */
F6 BYE Bob -> Alice
F6さようならボブ・->アリス
/* Bob sends BYE immediately after sending the re-INVITE. Bob
terminates the session and transitions from the Established state
to the Mortal state. */
再INVITEを送る直後/*ボブはBYEを送ります。 ボブはEstablished状態からMortal状態までのセッションと変遷を終えます。 */
Hasebe, et al. Best Current Practice [Page 33] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[33ページ]RFC5407例の呼び出し流れ
F7 200 OK (re-INVITE) Alice -> Bob
F7 200OK(再招待する)アリス・->ボブ
SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7 ;received=192.0.2.201 Require: timer Session-Expires: 300;refresher=uac From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0
以下を通って一口/2.0 200OK 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチ=z9hG4bKnashd7;は.201が必要とする=192.0.2を受け取りました: タイマはSession期限が切れます: 300; 酒=のuac From: ボブ<一口: bob@biloxi.example.com 、gt;、;=8321234356To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; =9fxced76sl呼び出しIDにタグ付けをしてください: 3848276298220188511@atlanta.example.com CSeq: 1 コンテンツの長さを招待してください: 0
/* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE.
A race condition occurs. */
/*ボブはBYEを送ります、そして、アリスは200OKで再INVITEに応じます。 競合条件は起こります。 */
F8 200 OK (BYE) Alice -> Bob
F8 200OK(さようなら)アリス・->ボブ
F9 ACK (re-INVITE) Bob -> Alice
F9 ACK(再招待する)ボブ・->アリス
ACK sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44 Max-Forwards: 70 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 ACK Content-Length: 0
ACK一口: alice@client.atlanta.example.com SIP/2.0Via: 一口/2.0/UDP client.biloxi.example.com: 5060; ブランチは前方へz9hG4bK74b44マックスと等しいです: 70 From: ボブ<一口: bob@biloxi.example.com 、gt;、;=8321234356To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; =9fxced76sl呼び出しIDにタグ付けをしてください: 3848276298220188511@atlanta.example.com CSeq: 2 ACKコンテンツの長さ: 0
/* Bob sends ACK in the Mortal state to complete the three-way
handshake of the INVITE transaction. */
/*ボブは、INVITE取引の3方向ハンドシェイクを終了するためにMortal状態でACKを送ります。 */
Hasebe, et al. Best Current Practice [Page 34] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[34ページ]RFC5407例の呼び出し流れ
3.2.4. Callee Receives ACK (Moratorium State) While in the Mortal State
3.2.4. 致命的な状態にある間、訪問される人はACK(モラトリアム状態)を受けます。
State Alice Bob State
| |
| ini-INVITE F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | 200 F3 | Ear
|<-------------------------------|
Mora | | Mora
| ACK F4 BYE F5 |
|------------- --------------|
Est | \ / | Mort
| X |
| / \ |
|<------------ ------------->| *race*
Mort | 200 F6 |
|------------------------------->|
| ^ ^ |
| | Timer K | |
| | V |
| | Timer J | Morg
| V |
Morg | |
| |
州のアリスボブ状態| | | F1をini招いてください。| |------------------------------->| 前| 180 F2| 前|<-------------------------------| 耳| 200 F3| 耳|<-------------------------------| モーラ| | モーラ| ACK F4さようならF5| |------------- --------------| エスト| \ / | 角笛の音| X| | / \ | | <、-、-、-、-、-、-、-、-、-、-、-- ------------->| *レース*角笛の音| 200 F6| |------------------------------->| | ^ ^ | | | タイマK| | | | V| | | タイマJ| Morg| V| Morg| | | |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, ACK to 200, while in the Mortal state. Alice sends an ACK and Bob sends a BYE at the same time. When the offer is in a 2xx, and the answer is in an ACK, there is a race condition. A session is not started when the ACK is received because Bob has already terminated the session by sending a BYE. The answer in the ACK request is just ignored.
このシナリオはUASがEstablishedメッセージを受け取るとき起こる競合条件を例証します、200へのACK、Mortal状態で。 アリスはACKを送ります、そして、ボブは同時に、BYEを送ります。 申し出が2xxにあって、答えがACKにあるとき、競合条件があります。 ボブがBYEを送ることによって既にセッションを終えたのでACKが受け取られているとき、セッションは始められません。 ACK要求における答えはただ無視されます。
Note: As noted in Section 3.1.4, implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. Implementors can decouple the actions of the user (e.g., hanging up) from the actions of the protocol (the sending of BYE F5), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful in preventing the type of race condition described in this section. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
以下に注意してください。 セクション3.1.4で注意されるように、このドキュメントの範囲の外に導入問題がありますが、以下のチップはこのタイプの競合条件を避けながら、備えられます。 作成者はプロトコル(BYE F5の発信)の動作からユーザ(例えば、ハングアップする)の動作の衝撃を吸収できます、UAがこのように振る舞うことができるように。 この場合、それはどのように長く待つかに関する作成者の選択です。 多くの場合、そのような実現はこのセクションで説明された競合条件のタイプを防ぐ際に役に立つかもしれません。 このドキュメントは、彼らが、ACKが届けられるのを待つべきであるかどうかと好みを全く言い表しません。 ユーザー・エクスペリエンスへの影響を考えた後に、作成者は、しばらく待つかどうか決めるべきです、ユーザー・エクスペリエンスが実現によって、プロトコルの振舞いに直接の関係を全く持っていないので。
Hasebe, et al. Best Current Practice [Page 35] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[35ページ]RFC5407例の呼び出し流れ
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
/* RTP streams are established between Alice and Bob. */
/*RTPの流れはアリスとボブの間で確立されます。 */
F5 BYE Alice -> Bob
F5さようならアリス・->ボブ
F6 200 OK Bob -> Alice
F6 200OKボブ・->アリス
/* Alice sends a BYE and terminates the session and dialog. */
/*アリスは、BYEを送って、セッションと対話を終えます。 */
3.3. Other Race Conditions
3.3. 他の競合条件
This section shows examples of race conditions that are not directly related to dialog state transition. In SIP, processing functions are deployed in three layers: dialog, session, and transaction. They are related to each other, but have to be treated separately. Section 17 of RFC 3261 [1] details the processing of transactions. This document has tried so far to clarify the processing on dialogs. This section explains race conditions that are related to sessions established with SIP.
このセクションは直接対話状態遷移に関連しない競合条件に関する例を示しています。 SIPでは、処理機能は3つの層で配備されます: 対話、セッション、および取引。 それらは、互いに関連されますが、別々に扱われなければなりません。 RFC3261[1]のセクション17は取引の処理を詳しく述べます。 このドキュメントは今までのところ、対話で処理をはっきりさせようとしました。 このセクションはSIPと共に確立したセッションに関連する競合条件について説明します。
3.3.1. Re-INVITE Crossover
3.3.1. 横断歩道を再招待してください。
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| 200 OK F3 |
|<---------------------------|
| ACK F4 |
|--------------------------->|
| Both Way RTP Media |
|<==========================>|
| |
|re-INVITE F5 re-INVITE F6 |
|------------ -------------|
アリス・ボブ| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 180 F2を鳴らすこと。| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 200 OK F3| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| ACK F4| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 両方、道のRTPメディア| |<=============>|、|、| |F5再招待F6を再招待してください。| |------------ -------------|
Hasebe, et al. Best Current Practice [Page 36] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[36ページ]RFC5407例の呼び出し流れ
| \ / |
| X |
| / \ |
|<----------- ------------>|
| 491 F8 491 F7 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| ^ ACK F9 ^ ACK F10|
|--|--------- ----|--------|
| | \ / | |
| | X | |
| | / \ | |
|<-|---------- ---|------->|
| | | |
| |0-2.0 sec | |
| | | |
| v re-INVITE F11(=F6) |
|<------------------|--------|
| 200 OK F12 | |
|-------------------|------->|
| ACK F13 | |
|<------------------|--------|
| | |
| |2.1-4.0 sec
| | |
|re-INVITE F14(=F5) v |
|--------------------------->|
| 200 OK F15 |
|<---------------------------|
| ACK F16 |
|--------------------------->|
| |
| |
| \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-、-- ------------>|、| 491 F8 491F7| |------------ -------------| | \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-、-- ------------>|、| ^ACK F9^ACK F10| |--|--------- ----|--------| | | \ / | | | | X| | | | / \ | | | <、-、|、-、-、-、-、-、-、-、-、-- ---|、-、-、-、-、-、--、>|、|、|、|、|、| |0-2.0秒| | | | | | | 再INVITE F11(F6と等しい)に対して| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-、-、-、-、--、|、| 200 OK F12| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-、-、-、--、>|、| ACK F13| | |<------------------|--------| | | | | |2.1-4.0秒| | | |再INVITE F14(F5と等しい)v| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 200 OK F15| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| ACK F16| |--------------------------->| | | | |
In this scenario, Alice and Bob send re-INVITEs at the same time. When two re-INVITEs cross in the same dialog, they are retried, each after a different interval, according to Section 14.1 of RFC 3261 [1]. When Alice sends the re-INVITE and it crosses with Bob's, the re-INVITE will be retried after 2.1-4.0 seconds because she owns the Call-ID (she generated it). Bob will retry his INVITE again after 0.0-2.0 seconds, because Bob isn't the owner of the Call-ID.
このシナリオでは、アリスとボブは同時に、再INVITEsを送ります。 2再INVITEsが同じ対話で交差するとき、彼らは再試行されます、異なった間隔のそれぞれ後に、RFC3261[1]のセクション14.1によると。 アリスが再INVITEを送って、ボブのものを交配すると、彼女がCall-IDを所有しているので(彼女はそれを発生させました)、再INVITEは2.1-4.0秒以降、再試行されるでしょう。 ボブがCall-IDの所有者でないので、ボブは0.0-2.0秒以降、再び彼のINVITEを再試行するでしょう。
Therefore, each User Agent must remember whether or not it has generated the Call-ID of the dialog, in case an INVITE may cross with another INVITE.
したがって、それぞれのUserエージェントは、それが対話のCall-IDを発生させたかどうかを覚えていなければなりません、INVITEが別のINVITEを交配するといけないかもしれないので。
Hasebe, et al. Best Current Practice [Page 37] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[37ページ]RFC5407例の呼び出し流れ
In this example, Alice's re-INVITE is for session modification and Bob's re-INVITE is for session refresh. In this case, after the 491 responses, Bob retries the re-INVITE for session refresh earlier than Alice. If Alice was to retry her re-INVITE (that is, if she was not the owner of Call-ID), the request would refresh and modify the session at the same time. Then Bob would know that he does not need to retry his re-INVITE to refresh the session.
この例では、アリスの再INVITEはセッション変更のためのそうです、そして、ボブの再INVITEはセッションがリフレッシュするからであることです。 491の応答の後にこの場合セッションのための再INVITEがアリスより早くリフレッシュするボブの再試行。 アリスが彼女の再INVITEを再試行するなら(すなわち、彼女がCall-IDの所有者でなかったなら)、要求は、同時に、セッションをリフレッシュして、変更するでしょうに。 そして、ボブは、彼がセッションをリフレッシュするために再INVITEを再試行する必要はないのを知っているでしょう。
In another instance, where two re-INVITEs for session modification cross over, retrying the same re-INVITE again after a 491 by the Call-ID owner (the UA that retries its re-INVITE after the other UA) may result in unintended behavior, so the UA must decide if the retry of the re-INVITE is necessary. (For example, when a call hold and an addition of video media cross over, mere retry of the re-INVITE at the firing of the timer may result in the situation where the video is transmitted immediately after the holding of the audio. This behavior is probably not intended by the users.)
したがって、Call-ID所有者(次々と再INVITE UAを再試行するUA)による491が故意でない振舞いをもたらしたかもしれない後に再びセッション変更のための2再INVITEsがわたるところで同じ再INVITEを再試行する別の例では、UAは、再INVITEの再試行が必要であるかどうか決めなければなりません。 (例えば、呼び出し保持とビデオメディアの参加がわたると、タイマの発火における再INVITEの単なる再試行はビデオがオーディオの把持直後送られる状況をもたらすかもしれません。 この振舞いはたぶんユーザによって意図されません。)
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
F5 re-INVITE Alice -> Bob
F5はアリス・->ボブを再招待します。
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP 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>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Length: 147
INVITE一口:一口: bob@client.biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf9マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 2 コンテンツの長さを招待してください: 147
v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly
0 0v=0 o=alice2890844526 2890844527IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000a=sendonly
Hasebe, et al. Best Current Practice [Page 38] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[38ページ]RFC5407例の呼び出し流れ
/* Some detailed messages are shown for the sequence to illustrate
what sort of INVITE requests crossed over each other. */
いくつかの詳細なメッセージが系列が例証するために示される/*は互いを越えましたどういうINVITEが、要求する。 */
F6 re-INVITE Bob -> Alice
F6はボブ・->アリスを再招待します。
INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 Session-Expires: 300;refresher=uac Supported: timer Max-Forwards: 70 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Content-Length: 0
INVITE一口: alice@client.atlanta.example.com SIP/2.0Via: 一口/2.0/UDP client.biloxi.example.com: 5060; ブランチ=z9hG4bKnashd7はセッションで期限が切れます: 300; uacが支えた酒=: タイママックス-フォワード: 70 From: ボブ<一口: bob@biloxi.example.com 、gt;、;=8321234356To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; =9fxced76sl呼び出しIDにタグ付けをしてください: 3848276298220188511@atlanta.example.com CSeq: 1 コンテンツの長さを招待してください: 0
/* A re-INVITE request for a session refresh and another for a call
hold are sent at the same time. */
同時に、呼び出し保持のためのセッションを求める再INVITE要求がリフレッシュする/*と別のものを送ります。 */
F7 491 Request Pending Bob -> Alice
F7 491は未定のボブ・->アリスを要求します。
/* Since a re-INVITE is in progress, a 491 response is returned. */
再INVITE以来の/*が進行している、491応答を返します。 */
F8 491 Request Pending Alice -> Bob
F8 491は未定のアリス・->ボブを要求します。
F9 ACK (INVITE) Alice -> Bob
F9 ACK(招待する)アリス・->ボブ
F10 ACK (INVITE) Bob -> Alice
F10 ACK(招待する)ボブ・->アリス
F11 re-INVITE Bob -> Alice
F11はボブ・->アリスを再招待します。
INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
INVITE一口: alice@client.atlanta.example.com SIP/2.0Via: 一口/2.0/UDP client.biloxi.example.com:5060; ブランチ=z9hG4bKnashd71
Session-Expires: 300;refresher=uac Supported: timer Max-Forwards: 70 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Type: application/sdp Content-Length: 133
セッションで期限が切れます: 300; uacが支えた酒=: タイママックス-フォワード: 70 From: ボブ<一口: bob@biloxi.example.com 、gt;、;=8321234356To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; =9fxced76sl呼び出しIDにタグ付けをしてください: 3848276298220188511@atlanta.example.com CSeq: 2 コンテントタイプを招待してください: sdp Contentアプリケーション/長さ: 133
v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201
v=0oはボブの2890844527 2890844527IN IP4 client.biloxi.example.com s=c=IN IP4 192.0.2.201と等しいです。
Hasebe, et al. Best Current Practice [Page 39] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[39ページ]RFC5407例の呼び出し流れ
t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
オーディオの3456RTP/AVP0 0 0t=m=a=rtpmap: 0PCMU/8000
/* Since Bob is not the owner of the Call-ID, he sends a re-INVITE
again after 0.0-2.0 seconds. */
ボブ以来の/*がCall-IDの所有者でない、彼は0.0-2.0秒以降、再び再INVITEを送ります。 */
F12 200 OK Alice -> Bob
F12 200OKアリス・->ボブ
F13 ACK Bob -> Alice
F13 ACKボブ・->アリス
F14 re-INVITE Alice -> Bob
F14はアリス・->ボブを再招待します。
INVITE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 3 INVITE Content-Length: 147
INVITE一口:一口: bob@client.biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf91マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 3 コンテンツの長さを招待してください: 147
v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly
0 0v=0 o=alice2890844526 2890844527IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000a=sendonly
/* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE
again after 2.1-4.0 seconds. */
アリス以来の/*がCall-IDの所有者である、アリスは2.1-4.0秒以降、再び再INVITEを送ります。 */
F15 200 OK Bob -> Alice
F15 200OKボブ・->アリス
F16 ACK Alice -> Bob
F16 ACKアリス・->ボブ
3.3.2. UPDATE and re-INVITE Crossover
3.3.2. 横断歩道をアップデートして、再招待してください。
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| |
| 200 OK F3 |
アリス・ボブ| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 180 F2を鳴らすこと。| |<---------------------------| | | | 200 OK F3|
Hasebe, et al. Best Current Practice [Page 40] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[40ページ]RFC5407例の呼び出し流れ
|<---------------------------|
| ACK F4 |
|--------------------------->|
| Both Way RTP Media |
|<==========================>|
| |
| UPDATE F5 re-INVITE F6 |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| 491 F8 491 F7 |
| (re-INVITE) (UPDATE) |
|------------ -------------|
| \ / |
| X |
| / \ |
|<----------- ------------>|
| ^ ACK F9 ^ |
|<-|----------------|--------|
| | | |
| |0-2.0 sec | |
| | | |
| v re-INVITE F10 | |
|<------------------|--------|
| 200 OK F11 | |
|-------------------|------->|
| ACK F12 | |
|<------------------|--------|
| | |
| |2.1-4.0 sec
| | |
| UPDATE F13 v |
|--------------------------->|
| 200 OK F14 |
|<---------------------------|
| |
| |
| <。---------------------------| | ACK F4| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 両方、道のRTPメディア| |<=============>|、|、|、| アップデートF5はF6を再招待します。| |------------ -------------| | \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-、-- ------------>|、| 491 F8 491F7| | (再招待します) (アップデート) | |------------ -------------| | \ / | | X| | / \ | | <、-、-、-、-、-、-、-、-、-、-- ------------>|、| ^ACK F9^| |<-|----------------|--------| | | | | | |0-2.0秒| | | | | | | 再INVITE F10に対して| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-、-、-、-、--、|、| 200 OK F11| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、-、-、-、-、-、--、>|、| ACK F12| | |<------------------|--------| | | | | |2.1-4.0秒| | | | UPDATE F13v| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 200 OK F14| |<---------------------------| | | | |
In this scenario, the UPDATE contains an SDP offer; therefore, the UPDATE and re-INVITE are both responded to with 491 as in the case of "re-INVITE crossover". When an UPDATE for session refresh that doesn't contain a session description and a re-INVITE cross each other, both requests succeed with 200 (491 means that a UA has a pending request). The same is true for UPDATE crossover. In the former case where either UPDATE contains a session description, the requests fail with 491; in the latter cases, they succeed with 200.
このシナリオでは、UPDATEはSDP申し出を含んでいます。 したがって、「再INVITE横断歩道」に関するケースのように491でともにUPDATEと再INVITEに応じます。 セッションがそれをリフレッシュするのでUPDATEがいつ、セッション記述を含まないか、そして、再INVITEは互いに交差していて、両方の要求は200で成功します(491は、UAには未定の要求があることを意味します)。 UPDATE横断歩道において、同じくらいは当てはまります。UPDATEがセッション記述を含む前の場合では、要求は491で失敗します。 後者の場合では、それらは200で成功します。
Hasebe, et al. Best Current Practice [Page 41] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[41ページ]RFC5407例の呼び出し流れ
Note: A 491 response is sent because an SDP offer is pending, and 491 is an error that is related to matters that impact the session established by SIP.
以下に注意してください。 SDP申し出が未定であるので、491応答を送ります、そして、491はSIPによって確立されたセッションに影響を与える件に関連する誤りです。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
F5 UPDATE Alice -> Bob
F5アップデートアリス・->ボブ
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP 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>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 UPDATE Content-Length: 147
UPDATE一口:一口: bob@client.biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf9マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 2 コンテンツの長さをアップデートしてください: 147
v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly
0 0v=0 o=alice2890844526 2890844527IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000a=sendonly
/* Some detailed messages are shown for the sequence to illustrate
messages crossing over each other. */
系列が互いを越えるメッセージを例証するようにいくつかの詳細なメッセージが示される/*。 */
F6 re-INVITE Bob -> Alice
F6はボブ・->アリスを再招待します。
INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7 Session-Expires: 300;refresher=uac Supported: timer Max-Forwards: 70 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE
INVITE一口: alice@client.atlanta.example.com SIP/2.0Via: 一口/2.0/UDP client.biloxi.example.com: 5060; ブランチ=z9hG4bKnashd7はセッションで期限が切れます: 300; uacが支えた酒=: タイママックス-フォワード: 70 From: ボブ<一口: bob@biloxi.example.com 、gt;、;=8321234356To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; =9fxced76sl呼び出しIDにタグ付けをしてください: 3848276298220188511@atlanta.example.com CSeq: 1 招待
Hasebe, et al. Best Current Practice [Page 42] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[42ページ]RFC5407例の呼び出し流れ
Content-Type: application/sdp Content-Length: 133
コンテントタイプ: sdp Contentアプリケーション/長さ: 133
v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0ボブの2890844527 2890844527IN IP4 client.biloxi.example.com s=c=IN IP4 192.0.2.201v=0o=t=m=オーディオの3456RTP/AVP0a=rtpmap: 0PCMU/8000
/* This is a case where a re-INVITE for a session refresh and an
UPDATE for a call hold are sent at the same time. */
/、*これはセッションのためのa再INVITEがリフレッシュするそうであり、同時に、呼び出し保持のためのUPDATEを送ります。 */
F7 491 Request Pending (UPDATE) Bob -> Alice
F7 491は(アップデート)ボブ->までアリスを要求します。
/* Since a re-INVITE is in process, a 491 response is returned. */
再INVITE以来の/*が過程にあって、491応答を返します。 */
F8 491 Request Pending (re-INVITE) Alice -> Bob
F8 491は(再招待します)未定のアリス・->ボブを要求します。
F9 ACK (re-INVITE) Alice -> Bob
F9 ACK(再招待する)アリス・->ボブ
F10 re-INVITE Bob -> Alice
F10はボブ・->アリスを再招待します。
INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71 Session-Expires: 300;refresher=uac Supported: timer Max-Forwards: 70
INVITE一口: alice@client.atlanta.example.com SIP/2.0Via: 一口/2.0/UDP client.biloxi.example.com: 5060; ブランチ=z9hG4bKnashd71はセッションで期限が切れます: 300; uacが支えた酒=: タイママックス-フォワード: 70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Type: application/sdp Content-Length: 133
From: ボブ<一口: bob@biloxi.example.com 、gt;、;=8321234356To:にタグ付けをしてください アリス<一口: alice@atlanta.example.com 、gt;、; =9fxced76sl呼び出しIDにタグ付けをしてください: 3848276298220188511@atlanta.example.com CSeq: 2 コンテントタイプを招待してください: sdp Contentアプリケーション/長さ: 133
v=0 o=bob 2890844527 2890844527 IN IP4 client.biloxi.example.com s=- c=IN IP4 192.0.2.201 t=0 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000
0 0ボブの2890844527 2890844527IN IP4 client.biloxi.example.com s=c=IN IP4 192.0.2.201v=0o=t=m=オーディオの3456RTP/AVP0a=rtpmap: 0PCMU/8000
/* Since Bob is not the owner of the Call-ID, Bob sends an INVITE
again after 0.0-2.0 seconds. */
ボブ以来の/*がCall-IDの所有者でない、ボブは0.0-2.0秒以降、再びINVITEを送ります。 */
Hasebe, et al. Best Current Practice [Page 43] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[43ページ]RFC5407例の呼び出し流れ
F11 200 OK Alice -> Bob
F11 200OKアリス・->ボブ
F12 ACK Bob -> Alice
F12 ACKボブ・->アリス
F13 UPDATE Alice -> Bob
F13アップデートアリス・->ボブ
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 3 UPDATE Content-Length: 147
UPDATE一口:一口: bob@client.biloxi.example.com SIP/2.0Via: 一口/2.0/UDP client.atlanta.example.com: 5060; ブランチは前方へz9hG4bK74bf91マックスと等しいです: 70 From: アリス<一口: alice@atlanta.example.com 、gt;、;=9fxced76sl To:にタグ付けをしてください ボブ<一口: bob@biloxi.example.com 、gt;、; タグは8321234356呼び出しIDと等しいです: 3848276298220188511@atlanta.example.com CSeq: 3 コンテンツの長さをアップデートしてください: 147
v=0
o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com
s=-
c=IN IP4 192.0.2.101
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendonly
/* Since Alice is the owner of the Call-ID, Alice sends the UPDATE
again after 2.1-4.0 seconds. */
v=0 o=alice2890844526 2890844527IN IP4 client.atlanta.example.com s=c=IN IP4 192.0.2.101tは0 0m=オーディオの49172RTP/AVP0a=rtpmapと等しいです: アリスがCall-IDの所有者である時から0PCMU/8000a=sendonly/*、アリスは2.1-4.0秒以降、再びUPDATEを送ります。 */
F14 200 OK Bob -> Alice
F14 200OKボブ・->アリス
Hasebe, et al. Best Current Practice [Page 44] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[44ページ]RFC5407例の呼び出し流れ
3.3.3. Receiving REFER (Established State) While in the Mortal State
3.3.3. 受信して、致命的な状態にある間、参照してください(状態を設置します)。
State Alice Bob State
| |
| INVITE F1 |
|----------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------|
Ear | | Ear
| 200 OK F3 |
|<-----------------------|
Mora | ACK F4 | Mora
|----------------------->|
Est | Both Way RTP Media | Est
|<======================>|
| |
| BYE F5 REFER F6 |
|--------- ----------|
Mort | \ / |
| X |
| / \ |
*race* |<-------- --------->|
| | Mort
| 481 F8 200 F7 |
| (REFER) (BYE) |
|--------- ----------|
| \ / ^ |
| X | |
| / \ | |
|<-------- --------->|
| ^ | |
| | Timer K | |
| V Timer J | |
Morg | V |
| | Morg
| |
州のアリスボブ状態| | | F1を招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| 前| 180 F2を鳴らすこと。| 前| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 耳| | 耳| 200 OK F3| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| モーラ| ACK F4| モーラ|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| エスト| 両方、道のRTPメディア| エスト|<===========>|、|、|、| さようならF5はF6を参照します。| |--------- ----------| 角笛の音| \ / | | X| | / \ | *レース*| <、-、-、-、-、-、-、-- --------->|、|、| 角笛の音| 481 F8 200F7| | (参照します) (さようなら) | |--------- ----------| | \ / ^ | | X| | | / \ | | | <、-、-、-、-、-、-、-- --------->|、| ^ | | | | タイマK| | | VタイマJ| | Morg| V| | | Morg| |
This scenario illustrates the race condition that occurs when the UAS receives an Established message, REFER, while in the Mortal state. Bob sends a REFER, and Alice sends a BYE at the same time. Bob sends the REFER in the same dialog. Alice's dialog state moves to the Mortal state at the point of sending BYE. In the Mortal state, the UA possesses dialog information for an internal process but the dialog shouldn't exist outwardly. Therefore, the UA sends an error response to the REFER, which is transmitted as a mid-dialog request. So Alice, in the Mortal state, sends an error response to the REFER. However, Bob has already started the SUBSCRIBE usage with REFER, so
このシナリオはUASがEstablishedメッセージを受け取るとき起こる競合条件を例証します、REFER、Mortal状態で。 ボブはREFERを送ります、そして、アリスは同時に、BYEを送ります。 ボブは同じ対話でREFERを送ります。 アリスの対話状態はBYEを送る意味のMortal状態に動きます。 Mortal状態では、UAは内部の過程のための対話情報を持っていますが、対話は外面的に存在するべきではありません。 したがって、UAはREFERへの誤り応答を送ります。(REFERは中間の対話要求として伝えられます)。 それで、アリスはMortal状態で誤り応答をREFERに送ります。 しかしながら、ボブが既に始めた、登録、REFERがある用法、そのように。
Hasebe, et al. Best Current Practice [Page 45] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[45ページ]RFC5407例の呼び出し流れ
the dialog continues until the SUBSCRIBE usage terminates, even though the INVITE dialog usage terminates by receiving BYE. Bob's behavior in this case needs to follow the procedures in RFC 5057 [6].
対話が続く、登録、INVITE対話用法はBYEを受けることによって、終わりますが、用法は終わります。 ボブの振舞いは、この場合RFC5057[6]で手順に従う必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1はアリス・->ボブを招待します。
F2 180 Ringing Bob -> Alice
ボブ・->アリスに電話をするF2 180
F3 200 OK Bob -> Alice
F3 200OKボブ・->アリス
F4 ACK Alice -> Bob
F4 ACKアリス・->ボブ
F5 BYE Alice -> Bob
F5さようならアリス・->ボブ
/* Alice sends a BYE request and terminates the session, and
transitions from the Confirmed state to the Terminated state. */
/*アリスは、BYE要求を送って、セッションを終えて、Confirmed状態からTerminated状態に移行します。 */
F6 REFER Bob -> Alice
F6はボブ・->アリスを参照します。
/* Alice sends a BYE, and Bob sends a REFER at the same time. Bob
sends the REFER on the INVITE dialog. The dialog state
transitions to the Mortal state at the moment Alice sends the BYE,
but Bob doesn't know this until he receives the BYE. A race
condition occurs. */
/*アリスはBYEを送ります、そして、ボブは同時に、REFERを送ります。 ボブはINVITE対話のREFERを送ります。 Mortalへの対話状態遷移は、現在、アリスがBYEを送ると述べますが、彼がBYEを受け取るまで、ボブはこれを知りません。 競合条件は起こります。 */
F7 200 OK (BYE) Bob -> Alice
F7 200OK(さようなら)ボブ・->アリス
F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob
F8 481呼び出し/取引が存在していない、(参照してください)アリス・->ボブ
/* Alice in the Mortal state sends a 481 to the REFER. */
Mortal状態の/*アリスは481をREFERに送ります。 */
4. Security Considerations
4. セキュリティ問題
This document contains clarifications of behavior specified in RFC 3261 [1], RFC 3264 [2], and RFC 3515 [4]. The security considerations of those documents continue to apply after the application of these clarifications.
このドキュメントはRFC3261[1]、RFC3264[2]、およびRFC3515[4]で指定された振舞いの明確化を含んでいます。 それらのドキュメントのセキュリティ問題は、これらの明確化の応用の後に適用し続けています。
5. Acknowledgements
5. 承認
The authors would like to thank Robert Sparks, Dean Willis, Cullen Jennings, James M. Polk, Gonzalo Camarillo, Kenichi Ogami, Akihiro Shimizu, Mayumi Munakata, Yasunori Inagaki, Tadaatsu Kidokoro, Kenichi Hiragi, Dale Worley, Vijay K. Gurbani, and Anders Kristensen for their comments on this document.
作者はこのドキュメントの彼らのコメントについてロバート・スパークス、ディーン・ウィリス、Cullenジョニングス、ジェームス・M.ポーク、ゴンサロ・キャマリロ、健一Ogami、Akihiro清水、マユミ宗像、稲垣保典、Tadaatsu Kidokoro、健一Hiragi、デール・ウォーリー、ビジェイK.Gurbani、およびアンダースKristensenに感謝したがっています。
Hasebe, et al. Best Current Practice [Page 46] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[46ページ]RFC5407例の呼び出し流れ
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[2] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[4] スパークス、R.、「セッション開始プロトコル(一口)は方法を参照する」RFC3515、2003年4月。
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional
Responses in Session Initiation Protocol (SIP)", RFC 3262,
June 2002.
[5] ローゼンバーグとJ.とH.Schulzrinne、「セッション開始プロトコル(一口)の暫定的な応答の信頼性」、RFC3262、2002年6月。
6.2. Informative References
6.2. 有益な参照
[6] Sparks, R., "Multiple Dialog Usages in the Session Initiation
Protocol", RFC 5057, November 2007.
[6] スパークス、R.、「セッション開始プロトコルの複数の対話用法」、RFC5057、2007年11月。
[7] Sparks, R., "Correct transaction handling for 200 responses to
Session Initiation Protocol INVITE requests", Work in Progress,
July 2008.
[7] スパークス、R.、「Session InitiationプロトコルINVITE要求への200の応答のための正しい取引取り扱い」、Progress、2008年7月のWork。
Hasebe, et al. Best Current Practice [Page 47] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[47ページ]RFC5407例の呼び出し流れ
Appendix A. BYE in the Early Dialog
早めの対話における付録A.不戦勝
This section, related to Section 3.1.3, explains why BYE is not recommended in the Early state, illustrating a case in which a BYE in the early dialog triggers confusion.
セクション3.1.3に関係づけられたこのセクションは、BYEがなぜEarly状態で推薦されないかを説明します、早めの対話におけるBYEが混乱の引き金となる場合を例証して。
Alice Proxy Bob Carol
| | | |
| INVITE F1 | | |
|--------------->| INVITE F2 | |
| 100 F3 |----------------->| |
|<---------------| 180(To tag=A) F4 | |
| 180(A) F5 |<-----------------| |
|<---------------| | |
| | INVITE(Fork) F6 |
| |------------------------>|
| | 100 F7 |
| BYE(A) F8 |<------------------------|
|--------------->| BYE(A) F9 | |
| |----------------->| |
| | 200(A,BYE) F10 | |
| 200(A,BYE) F11 |<-----------------| |
|<---------------| 487(A,INV) F12 | |
| |<-----------------| |
| | ACK(A) F13 | |
| |----------------->| |
| | | |
| | |
| | 200(To tag=B) F13 |
| 200(B) F14 |<------------------------|
|<---------------| |
| ACK(B) F15 | |
|--------------->| ACK(B) F16 |
| |------------------------>|
| BYE(B) F17 | |
|--------------->| BYE(B) F18 |
| |------------------------>|
| | 200(B) F19 |
| 200(B) F20 |<------------------------|
|<---------------| |
| | |
| | |
アリス・プロキシボブ・キャロル| | | | | F1を招いてください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| F2を招待してください。| | | 100 F3|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 180、(タグ=a)F4| | | 180(A) F5| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| (フォーク)F6を招待してください。| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 100 F7| | BYE(A) F8| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| BYE(A) F9| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200(A、さようなら)F10| | | 200(A、さようなら)F11| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| 487(A、INV)F12| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK(A) F13| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、|、|、|、|、|、| 200(=Bにタグ付けをする)F13| | 200(B) F14| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ACK(B) F15| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| ACK(B) F16| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| さようなら(B)F17| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| さようなら(B)F18| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 200(B) F19| | 200(B) F20| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、|、|、|
Care is advised in sending BYE in the Early state when forking by a proxy is expected. In this example, the BYE request progresses normally, and it succeeds in correctly terminating the dialog with Bob. After Bob terminates the dialog by receiving the BYE, he sends a 487 to the ini-INVITE. According to Section 15.1.2 of RFC 3261
注意はEarly状態でBYEを送る際にプロキシで分岐するのがいつ予想されるよう教えられます。 この例では、通常、BYE要求は進歩をします、そして、それはボブと共に対話を正しく終えるのに成功します。 ボブがBYEを受けることによって対話を終えた後に、彼は487をini-INVITEに送ります。 .2セクション15.1RFC3261によると
Hasebe, et al. Best Current Practice [Page 48] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[48ページ]RFC5407例の呼び出し流れ
[1], it is RECOMMENDED for the UAS to generate a 487 to any pending requests after receiving a BYE. In this example, Bob sends a 487 to the ini-INVITE since he receives the BYE while the ini-INVITE is in pending state.
[1] それはUASが不戦勝を得た後にどんな未定の要求にも487を発生させるRECOMMENDEDです。 この例では、ini-INVITEが未定の状態にある間、彼がBYEを受け取るので、ボブは487をini-INVITEに送ります。
However, Alice receives a final response to the INVITE (a 200 from Carol) even though she has successfully terminated the dialog with Bob. This means that, regardless of the success/failure of the BYE in the Early state, Alice MUST be prepared for the establishment of a new dialog until receiving the final response for the INVITE and terminating the INVITE transaction.
しかしながら、ボブと共に対話を首尾よく終えましたが、アリスはINVITE(キャロルからの200)への最終的な応答を受けます。 これは、アリスがEarly状態のBYEの成功/失敗にかかわらず新しい対話の確立のためにINVITEのために最終的な応答を受けるまで準備されていて、INVITE取引を終えなければならないことを意味します。
It is not illegal to send a BYE in the Early state to terminate a specific early dialog -- it may satisfy the intent of some callers. However, the choice of BYE or CANCEL in the Early state must be made carefully. CANCEL is appropriate when the goal is to abandon the call attempt entirely. BYE is appropriate when the goal is to abandon a particular early dialog while allowing the call to be completed with other destinations. When using either BYE or CANCEL, the UAC must be prepared for the possibility that a call may still be established to one or more destinations.
特定の早めの対話を終えるためにEarly状態でBYEを送るのは不法ではありません--それは何人かの訪問者の意図を満たすかもしれません。 しかしながら、慎重にEarly状態のBYEかキャンセルの選択をしなければなりません。 目標が呼び出し試みを完全に捨てることであるときに、キャンセルは適切です。 目標が他の目的地で完成されるという要求を許している間、特定の早めの対話を捨てることであるときに、BYEは適切です。 BYEかキャンセルのどちらかを使用するとき、呼び出しがまだ1つ以上の目的地に確立されているかもしれない可能性のためにUACを準備しなければなりません。
Appendix B. BYE Request Overlapping with re-INVITE
再招待に重なる付録B.さようなら要求
UAC UAS
| |
The session has been already established
==========================
| re-INVITE F1 |
|--------------------->|
| BYE F2 |
|--------------------->|
| 200(BYE) F3 |
|<---------------------|
| INVITE F4(=F1) |
|--------------------->|
| |
| |
UAC UAS| | セッションは既に確立されました。========================== | F1を再招いてください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| さようならF2| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 200(さようなら)F3| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| F4(F1と等しい)を招待してください。| |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|
This case could look similar to the one in Section 3.2.3. However, it is not a race condition. This case describes the behavior when there is no response to the INVITE for some reason. The appendix explains the behavior in this case and its rationale, since this case is likely to cause confusion.
本件はセクション3.2.3においてものと同様に見えることができました。 しかしながら、それは競合条件ではありません。 INVITEへの応答が全くある理由でないとき、本件は振舞いについて説明します。 付録で、本件が混乱を引き起こしそうであって、この場合、振舞いとその原理がわかります。
First of all, it is important not to confuse the behavior of the transaction layer and that of the dialog layer. RFC 3261 [1] details the transaction layer behavior. The dialog layer behavior is
まず、取引層の動きと対話層のものを混乱させないのは重要です。 RFC3261[1]は取引層の振舞いを詳しく述べます。 対話層の振舞いはそうです。
Hasebe, et al. Best Current Practice [Page 49] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[49ページ]RFC5407例の呼び出し流れ
explained in this document. It has to be noted that these two behaviors are independent of each other, even though both layers may be triggered to change their states by sending or receiving the same SIP messages. (A dialog can be terminated even though a transaction still remains, and vice versa.)
本書では説明されます。 これらの2つの振舞いが互いから独立していることに注意されなければなりません、両方の層は同じSIPメッセージを送るか、または受け取ることによってそれらの州を変えるために引き起こされるかもしれませんが。 (取引がまだ残っていて、逆もまた同様ですが、対話を終えることができます。)
In the sequence above, there is no response to F1, and F2 (BYE) is sent immediately after F1. (F1 is a mid-dialog request. If F1 was an ini-INVITE, BYE could not be sent before the UAC received a provisional response to the request with a To tag.)
系列には、F1への応答が全く上では、ありません、そして、F1直後F2(BYE)を送ります。 (F1は中間の対話要求です。 F1がini-INVITEであるなら、UACがToタグで要求への暫定的な応答を受ける前にBYEを送ることができないでしょうに。)
Below is a figure that illustrates the UAC's dialog state and the transaction state.
以下に、UACの対話州と取引状態を例証する図があります。
BYE INV dialog UAC UAS
: | |
: | |
| | re-INVITE F1 |
o | |--------------------->|
| | | BYE F2 |
o | (Mortal) |--------------------->|
| | | | 200(BYE) F3 |
| | | |<---------------------|
| | | | INVITE F4(=F1) |
| | | |--------------------->|
| | | | 481(INV) F5 |
| | | |<---------------------|
| | | | ACK(INV) F6 |
| | | |--------------------->|
| | | | |
o | o | |
| | |
o | |
| |
BYE INV対話UAC UAS: | | : | | | | F1を再招いてください。| o | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| さようならF2| o | (死すべき者) |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 200(さようなら)F3| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| F4(F1と等しい)を招待してください。| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、| 481 (INV)F5| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、| ACK(INV)F6| | | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、|、|、| o | o | | | | | o | | | |
For the UAC, the INVITE client transaction begins at the point F1 is sent. The UAC sends BYE (F2) immediately after F1. This is a legitimate behavior. (Usually, the usage of each SIP method is independent, for BYE and others. However, it should be noted that it is prohibited to send a request with an SDP offer while the previous offer is in progress.)
UACに関しては、INVITEクライアント取引はF1が送られるポイントで始まります。 UACはF1直後BYE(F2)を送ります。 これは正統の振舞いです。 (通常、BYEと他のものにとって、それぞれのSIP方法の用法は独立しています。 しかしながら、それが前の申し出が進行している間、要求をSDP申し出と共に送るために禁止されていることに注意されるべきです。)
After that, F2 triggers the BYE client transaction. At the same time, the dialog state transitions to the Mortal state and then only a BYE or a response to a BYE can be handled.
その後に、F2はBYEクライアント取引の引き金となります。 同時に、次にBYEへのMortal状態への対話状態遷移とBYEか応答しか扱うことができません。
Hasebe, et al. Best Current Practice [Page 50] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[50ページ]RFC5407例の呼び出し流れ
It is permitted to send F4 (a retransmission of INVITE) in the Mortal state because the retransmission of F1 is handled by the transaction layer, and the INVITE transaction has not yet transitioned to the Terminated state. As is mentioned above, the dialog and the transaction behave independently each other. Therefore, the transaction handling has to be continued even though the dialog has moved to the Terminated state.
F1の「再-トランスミッション」が取引層によって扱われるのでそれがMortal状態でF4(INVITEの「再-トランスミッション」)を送ることが許可されていて、INVITE取引はまだTerminated状態に移行していません。 そのままで、上で言及されていて、対話と取引は互いを独自に振る舞わせます。 したがって、対話はTerminated状態に動きましたが、取引取り扱いは続けられなければなりません。
Note: As noted in Section 3.1.4, implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. The UAC can delay sending BYE F2 until the re-INVITE transaction F1 completes. Implementors can decouple the actions of the user (e.g., hanging up) from the actions of the protocol (the sending of BYE F2), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful to prevent this case. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
以下に注意してください。 セクション3.1.4で注意されるように、このドキュメントの範囲の外に導入問題がありますが、以下のチップはこのタイプの競合条件を避けながら、備えられます。 UACは、F1が完了する再INVITE取引までBYE F2を送るのを遅らせることができます。 作成者はプロトコル(BYE F2の発信)の動作からユーザ(例えば、ハングアップする)の動作の衝撃を吸収できます、UAがこのように振る舞うことができるように。 この場合、それはどのように長く待つかに関する作成者の選択です。 多くの場合、そのような実現は、本件を防ぐために役に立つかもしれません。 このドキュメントは、彼らが、ACKが届けられるのを待つべきであるかどうかと好みを全く言い表しません。 ユーザー・エクスペリエンスへの影響を考えた後に、作成者は、しばらく待つかどうか決めるべきです、ユーザー・エクスペリエンスが実現によって、プロトコルの振舞いに直接の関係を全く持っていないので。
Next, the UAS's state is shown below.
次に、UASの状態は以下で見せられます。
UAC UAS dialog INV BYE
| | :
| | :
| re-INVITE F1 | |
|-------------->x | |
| BYE F2 | |
|--------------------->| | o
| 200(BYE) F3 | (Mortal) |
|<---------------------| | |<-Start Timer J
| INVITE F4(=F1) | | |
|--------------------->| | o |
| 4xx/5xx(INV) F5 | o | o
|<---------------------| |
| ACK(INV) F6 | |
|--------------------->| |<-Start Timer I
| | |
| | |
| | o
| |
UAC UAS対話INV BYE| | : | | : | F1を再招いてください。| | |-------------->x| | | さようならF2| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| o | 200(さようなら)F3| (死すべき者) | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| | <、-タイマJを始動してください。| F4(F1と等しい)を招待してください。| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| o | | 4xx/5xx(INV)F5| o | o | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| ACK(INV)F6| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| | <、-タイマIを始動してください。| | | | | | | | o | |
For the UAS, it can be considered that packet F1 is lost or delayed (here, the behavior is explained for the case that the UAS receives F2 BYE before F1 INVITE). Therefore, F2 triggers the BYE transaction
UASに関しては、パケットF1が負けられるか、または遅れると考えることができる、(ここで、振舞いがUASがF2 BYEを受けるケースのために説明される、F1 INVITE) したがって、F2はBYE取引の引き金となります。
Hasebe, et al. Best Current Practice [Page 51] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[51ページ]RFC5407例の呼び出し流れ
for the UAS, and simultaneously the dialog moves to the Mortal state. Then, upon the reception of F4, the INVITE server transaction begins. (It is permitted to start the INVITE server transaction in the Mortal state. The INVITE server transaction begins to handle the received SIP request regardless of the dialog state.) The UAS's TU sends an appropriate error response for the F4 INVITE, either 481 (because the TU knows that the dialog that matches the INVITE is in the Terminated state) or 500 (because the re-sent F4 has an out-of-order CSeq). (It is mentioned above that INVITE message F4 (and F1) is a mid-dialog request. Mid-dialog requests have a To tag. It should be noted that the UAS's TU does not begin a new dialog upon the reception of INVITE with a To tag.)
UAS、および同時にMortal状態への対話移動のために。 そして、F4のレセプションでは、INVITEサーバ取引は始まります。 (それがMortal状態でINVITEサーバ取引を始めることが許可されています。 INVITEサーバ取引は対話状態にかかわらず受信されたSIP要求を扱い始めます。) UASのTUがF4 INVITE、どちらかの481(TUが、INVITEに合っている対話がTerminated状態にあるのを知っているので)か500のための適切な誤り応答を送る、(再送して、F4には故障しているCSeqがある、) (そのINVITEメッセージを超えてF4(そして、F1)が中間の対話要求であると言及されます。 中間の対話要求には、Toタグがあります。 UASのTUがToタグがあるINVITEのレセプションで新しい対話を始めないことに注意されるべきです。)
Appendix C. UA's Behavior for CANCEL
キャンセルのための付録C.UAの振舞い
This section explains the CANCEL behaviors that indirectly impact the dialog state transition in the Early state. CANCEL does not have any influence on the UAC's dialog state. However, the request has an indirect influence on the dialog state transition because it has a significant effect on ini-INVITE. For the UAS, the CANCEL request has more direct effects on the dialog than on the sending of a CANCEL by the UAC, because it can be a trigger to send the 487 response. Figure 3 explains the UAS's behavior in the Early state. This flow diagram is only an explanatory figure, and the actual dialog state transition is as illustrated in Figures 1 and 2.
このセクションはEarly状態で間接的に対話状態遷移に影響を与えるキャンセルの振舞いについて説明します。 キャンセルはUACの対話状態に少しの影響も与えません。 しかしながら、それが重要な影響をini-INVITEに与えるので、要求は対話状態遷移に間接的な影響を与えます。 UASに関しては、キャンセル要求には、対話に関するUACによるキャンセルの発信より多くの直接効果があります、それが487応答を送るためには引き金であるかもしれないので。 図3はEarly状態でUASの振舞いについて説明します。 このフローチャートは説明している数字にすぎません、そして、実際の対話状態遷移は図1と2でイラスト入りです。
In the flow, full lines are related to dialog state transition, and dotted lines are involved with CANCEL. (r) represents the reception of signaling, and (s) means sending. There is no dialog state for CANCEL, but here the Cancelled state is handled virtually just for the ease of understanding of the UA's behavior when it sends and receives CANCEL.
流れでは、実線は対話状態遷移に関連します、そして、点線はキャンセルにかかわります。 (r) (s) シグナリングのレセプション、および手段発信を表します。 キャンセルのための対話状態が全くありませんが、ここで、キャンセルを送って、受けるとき、Cancelled状態はまさしくUAの振舞いの理解の容易さのために実際には扱われます。
Hasebe, et al. Best Current Practice [Page 52] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[52ページ]RFC5407例の呼び出し流れ
+-------------+
| Preparative |---+
+-------------+ |
: | 1xx(s) |
: V |
: +-------+ | 2xx(s)
: | Early |-----+------+
: +-------+ |
: : V
: : +-----------+
: : | Confirmed |<...
:.....: +-----------+ :
: | : :
: BYE(r)| : :
: CANCEL(r) | :.......:
V | CANCEL(r)
............. |
: Cancelled : |
:...........: |
| 487(s) |
| |
+--------------------+
|
V
+------------+
| Terminated |
+------------+
+-------------+ | 予備|---+ +-------------+ | : | 1xx(s)| : V| : +-------+ | 2xx(s): | 早い|-----+------+ : +-------+ | : : V: : +-----------+ : : | 確認されます。|<… :.....: +-----------+ : : | : : : さようなら(r)| : : : (r)を取り消してください。| :.......: V| キャンセル(r)… | : 取り消される: | :...........: | | 487(s)| | | +--------------------+ | +に対して------------+ | 終わります。| +------------+
Figure 3: CANCEL flow diagram for UAS
図3: UASのためのキャンセルフローチャート
There are two behaviors for the UAS depending on the state when it receives a CANCEL.
UASのためのキャンセルを受けるとき状態に依存する2つの振舞いがあります。
The first behavior is when the UAS receives a CANCEL in the Early state. In this case, the UAS immediately sends a 487 for the INVITE, and the dialog transitions to the Terminated state.
最初の振舞いはUASがEarly状態でキャンセルを受ける時です。 この場合、UASはすぐに、INVITE、および対話変遷のためにTerminated状態に487を送ります。
The other is the case in which the UAS receives a CANCEL while in the Confirmed state. In this case, the dialog state transition does not occur, because the UAS has already sent a final response to the INVITE to which the CANCEL is targeted. (Note that, because of the UAC's behavior, a UAS that receives a CANCEL in the Confirmed state can expect to receive a BYE immediately and move to the Terminated state. However, the UAS's state does not transition until it actually receives a BYE.)
Confirmed状態で、もう片方がUASがキャンセルを受ける場合です。 この場合、対話状態遷移は起こりません、UASが既にキャンセルが狙うINVITEへの最終的な応答を送ったので。 (Confirmed状態でキャンセルを受けるUASがUACの振舞いのためにすぐに、不戦勝を得て、Terminated状態に動くと予想できることに注意してください。 しかしながら、UASの州は実際に不戦勝を得るまでどんな変化もしません。)
Hasebe, et al. Best Current Practice [Page 53] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[53ページ]RFC5407例の呼び出し流れ
Appendix D. Notes on the Request in the Mortal State
致命的な状態での要求に関する付録D.注
This section describes the UA's behavior in the Mortal state, which needs careful attention. Note that every transaction completes independently of others, following the principle of RFC 3261 [1].
このセクションはMortal州でUAの振舞いについて説明します。(それは、慎重な注意を必要とします)。 RFC3261[1]の原則に従って、あらゆる取引が他のものの如何にかかわらず完成する注意。
In the Mortal state, only a BYE can be accepted, and the other messages in the INVITE dialog usage are responded to with an error. However, sending of ACK and the authentication procedure for BYE are conducted in this state. (The handling of messages concerning multiple dialog usages is out of the scope of this document. Refer to RFC 5057 [6] for further information.)
Mortal状態では、BYEしか受け入れることができません、そして、誤りでINVITE対話用法による他のメッセージに応じます。 しかしながら、BYEのためにACKと認証手順を発信させるのがこの状態で行われます。 (このドキュメントの範囲の外に複数の対話用法に関するメッセージの取り扱いがあります。 詳細のためのRFC5057[6]を参照してください。)
ACK for error responses is handled by the transaction layer, so the handling is not related to the dialog state. Unlike the ACK for error responses, ACK for 2xx responses is a request newly generated by a TU. However, the ACK for 2xx and the ACK for error responses are both part of the INVITE transaction, even though their handling differs (Section 17.1.1.1, RFC 3261 [1]). Therefore, the INVITE transaction is completed by the three-way handshake, which includes ACK, even in the Mortal state.
誤り応答のためのACKが取引層によって扱われるので、取り扱いは対話状態に関連しません。 誤り応答のためのACKと異なって、2xx応答のためのACKはTUによって新たに発生した要求です。 しかしながら、2xxとACKのためのACKは誤り応答が両方であるので、INVITE取引を離れさせます、彼らの取り扱いが異なりますが(セクション17.1 .1 .1 RFC3261[1])。 したがって、INVITE取引は3方向ハンドシェイクによって完了されます。(それは、Mortal状態にさえACKを含んでいます)。
Considering actual implementation, the UA needs to keep the INVITE dialog usage until the Mortal state finishes, so that it is able to send ACK for a 2xx response in the Mortal state. If a 2xx to INVITE is received in the Mortal state, the duration of the INVITE dialog usage will be extended to 64*T1 seconds after the receipt of the 2xx, to cope with the possible 2xx retransmission. (The duration of the 2xx retransmission is 64*T1, so the UA needs to be prepared to handle the retransmission for this duration.) However, the UA shall send an error response to other requests, since the INVITE dialog usage in the Mortal state is kept only for the sending of ACK for 2xx.
実際の実現を考える場合、UAは、Mortal状態が終わるまでINVITE対話用法を保つ必要があります、Mortal状態の2xx応答のためにACKを送ることができるように。 Mortal状態にINVITEへの2xxを受け取ると、2xxの領収書の秒後に可能な2xx retransmissionに対処するためにINVITE対話用法の持続時間を64*T1に与えるでしょう。 (2xx retransmissionの持続時間が64*T1であるので、UAは、この持続時間のために「再-トランスミッション」を扱うように準備される必要があります。) しかしながら、UAは誤り応答を他の要求に送るものとします、Mortal状態のINVITE対話用法が2xxのためのACKの発信のためだけに保たれるので。
The BYE authentication procedure shall be processed in the Mortal state. When authentication is requested by a 401 or 407 response, the UAC resends BYE with appropriate credentials. Also, the UAS handles the retransmission of the BYE for which it requested authentication.
BYE認証手順はMortal状態で処理されるものとします。 認証が401か407応答で要求されているとき、UACは適切な信任状があるBYEを再送します。 また、UASはそれが認証を要求したBYEの「再-トランスミッション」を扱います。
Appendix E. Forking and Receiving New To Tags
付録E.分岐とタグに新しい受信
This section details the behavior of the TU when it receives multiple responses with different To tags to the ini-INVITE.
異なったToタグで複数の応答をini-INVITEに受けるとき、このセクションはTUの動きを詳しく述べます。
When an INVITE is forked inside a SIP network, there is a possibility that the TU receives multiple responses to the ini-INVITE with differing To tags (see Sections 12.1, 13.1, 13.2.2.4, 16.7, 19.3,
INVITEがSIPネットワークの中でフォーク状にされるとき、TUが異なったToタグでini-INVITEへの複数の応答を受ける可能性がある、(見る、セクション12.1、13.1、13.2 .2 .4、16.7、19.3
Hasebe, et al. Best Current Practice [Page 54] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[54ページ]RFC5407例の呼び出し流れ
etc., of RFC 3261 [1]). If the TU receives multiple 1xx responses with different To tags, the original DSM forks and a new DSM instance is created. As a consequence, multiple early dialogs are generated.
RFC3261[1])のなど。 TUが異なったToタグで複数の1xx応答を受けるなら、オリジナルのDSMは分岐します、そして、新しいDSM例は作成されます。 結果として、複数の早めの対話が発生します。
If one of the multiple early dialogs receives a 2xx response, it naturally transitions to the Confirmed state. No DSM state transition occurs for the other early dialogs, and their sessions (early media) terminate. The TU of the UAC terminates the INVITE transaction after 64*T1 seconds, starting at the point of receiving the first 2xx response. Moreover, all mortal early dialogs that do not transition to the Established state are terminated (see Section 13.2.2.4 of RFC 3261 [1]). By "mortal early dialog", we mean any early dialog that the UA will terminate when another early dialog is confirmed.
複数の早めの対話の1つが2xx応答を受けるなら、それは自然にConfirmed状態に移行します。 DSM状態遷移は全く他の早めの対話のために起こりません、そして、彼らのセッション(早めのメディア)は終わります。 UACのTUは64*T1秒以降INVITE取引を終えます、最初の2xx応答を受ける意味で始まって。 セクション13.2を見てください。そのうえ、Established状態へのどんな変化もしないすべての致命的な早めの対話が終えられる、(.2 .4RFC3261[1])。 別の早めの対話が確認されるとき、「致命的な早めの対話」で、私たちはUAが終えるどんな早めの対話も言っています。
Below is an example sequence in which two 180 responses with different To tags are received, and then a 200 response for one of the early dialogs (dialog A) is received. Dotted lines (..) in the sequences are auxiliary lines to represent the influence on dialog B.
異なったToタグによる2つの180応答が受け取られている例の系列が以下にあって、次に、早めの対話(対話A)の1つの200応答は受け取られています。 点線、()、系列には、対話Bへの影響を表す補助の線があります。
Hasebe, et al. Best Current Practice [Page 55] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[55ページ]RFC5407例の呼び出し流れ
UAC
dialog(A) | INVITE F1
Pre o |------------------------->
| | 100 F2
| |<-------------------------
| | 180(To tag=A) F3
Ear | |<-------------------------
dialog(B) | |
forked new DSM | | 180(To tag=B) F4
Ear o..........|..........|<-------------------------
| | |
| | | 200(A) F5
terminate->|.....Mora |..........|<-------------------------
early | | ^ | ACK(A) F6
media | Est | | |------------------------->
| | | |
| | |64*T1 |
| | |(13.2.2.4 of RFC 3261 [1])
| | | |
| | | |
| | V |
o..........|.(terminate INVITE transaction)
terminated | |
dialog(B) | |
| |
UAC dialog(A)| INVITE F1Pre o|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 100 F2| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 180、(タグ=a)F3耳| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- 対話(B)| | 股状の新しいDSM| | 180 (=Bにタグ付けをする) F4 Ear o.…|..........|<------------------------- | | | | | | 200(A) F5は終わります。>|.....モーラ|..........| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- 早い| | ^ | ACK(A) F6メディア| エスト| | |-------------------------> | | | | | | |64*T1| | | |(13.2、.2、.4RFC3261[1]) | | | | | | | | | | V| o..........|終わります(INVITE取引を終えます)。| | 対話(B)| | | |
Figure 4: Receiving 1xx responses with different To tags
図4: 異なったToタグで1xx応答を受けます。
The figure above shows the DSM inside a SIP TU. Triggered by the reception of a provisional response with a different To tag (F4 180(To tag=B)), the DSM forks and the early dialog B is generated. 64*T1 seconds later, dialog A receives a 200 OK response. Dialog B, which does not transition to the Established state, terminates.
上の図形はSIP TUの中でDSMを見せています。 異なったToタグ(F4 180(=Bにタグ付けをする))による暫定的な応答のレセプションによって引き起こされて、DSMは分岐します、そして、早めの対話Bは発生します。 64*T1秒後に、対話Aは200OK応答を受けます。 対話B(Established状態へのどんな変化もしません)は終わります。
Next, the behavior of a TU that receives multiple 2xx responses with different To tags is explained. When a mortal early dialog that did not match the first 2xx response that the TU received receives another 2xx response that matches its To tag before the 64*T1 INVITE transaction timeout, its DSM transitions to the Confirmed state. However, the session on the mortal early dialog is terminated when the TU receives the first 2xx to establish a dialog, so no session is established for the mortal early dialog. Therefore, when the mortal early dialog receives a 2xx response, the TU sends an ACK and, immediately after, the TU usually sends a BYE to terminate the DSM. (In special cases, e.g., if a UA intends to establish multiple dialogs, the TU may not send the BYE.)
次に、異なったToタグで複数の2xx応答を受けるTUの動きは説明されます。 TUが受けた最初の2xx応答に合っていなかった致命的な早めの対話が64*T1 INVITE取引タイムアウトの前にToタグに合っている別の2xx応答を受けるとき、DSMはConfirmed状態に移行します。 しかしながら、TUが対話を確立する最初の2xxを受けるとき、致命的な早めの対話のセッションが終えられるので、セッションは全く致命的な早めの対話のために確立されません。 したがって、致命的な早めの対話が2xx応答を受けるとき、TUはACKを送ります、そして、直後に、通常、TUはDSMを終えるためにBYEを送ります。 (特別な場合では、例えば、UAが複数の対話を確立するつもりであるなら、TUはBYEを送らないかもしれません。)
Hasebe, et al. Best Current Practice [Page 56] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[56ページ]RFC5407例の呼び出し流れ
The handling of the second early dialog after receiving the 200 for the first dialog is quite appropriate for a typical device, such as a phone. It is important to note that what is being shown is a typical useful action and not the only valid one. Some devices might want to handle things differently. For instance, a conference focus that has sent out an INVITE that forks may want to accept and mix all the dialogs it gets. In that case, no early dialog is treated as mortal.
典型的な装置に、最初の対話のために200を受け取った後の2番目の早めの対話の取り扱いはかなり適切です、電話のように。 示されていることが唯一の有効なものではなく、典型的な役に立つ動きであることに注意するのは重要です。 いくつかの装置がものを異なって扱いたがっているかもしれません。 例えば、分岐するINVITEを出した会議焦点は、それが得るすべての対話を受け入れて、混ぜたがっているかもしれません。 その場合、どんな早めの対話も死すべき者として扱われません。
Below is an example sequence in which two 180 responses with a different To tag are received and then a 200 response for each of the early dialogs is received.
以下に、異なったToとの180の応答がタグ付けをする2が受け取られていて、次に、それぞれの早めの対話のための200応答が受け取られている例の系列があります。
UAC
dialog(A) | INVITE F1
Pre o |----------------------->
| | 100 F2
| |<-----------------------
| | 180(To tag=A) F3
dialog(B) Ear | |<-----------------------
forked new DSM | | 180(To tag=B) F4
Ear o..........|..........|<-----------------------
| | |
| | | 200(A) F5
terminate->|.....Mora |..........|<-----------------------
early | | ^ | ACK(A) F6
media | Est | | |----------------------->
| | |64*T1 |
| | | | 200(B) F7
Mora |..........|.|........|<-----------------------
| | | | ACK(B) F8
Est |..........|.|........|----------------------->
| | | | BYE(B) F9
Mort |..........|.|........|----------------------->
^ | | | | 200(B) F10
| | | | |<-----------------------
|Timer K | | |
| | | V |
| | | (terminate INVITE transaction)
V | | |
Morg o | |
| |
UAC dialog(A)| INVITE F1Pre o|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 100 F2| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 180、(タグ=a)F3対話(B)耳| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- 股状の新しいDSM| | 180 (=Bにタグ付けをする) F4 Ear o.…|..........| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、|、|、| 200(A) F5は終わります。>|.....モーラ|..........| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- 早い| | ^ | ACK(A) F6メディア| エスト| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| |64*T1| | | | | 200(B) F7モーラ|..........|.|........| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK(B) F8エスト|..........|.|........|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| さようなら(B)F9角笛の音|..........|.|........|----------------------->^| | | | 200(B) F10| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-- |タイマK| | | | | | V| | | | (INVITE取引を終えます) V| | | Morg o| | | |
Figure 5: Receiving 1xx and 2xx responses with different To tags
図5: 異なったToタグで1xxと2xx応答を受けます。
Below is an example sequence when a TU receives multiple 200 responses with different To tags before the 64*T1 timeout of the INVITE transaction in the absence of a provisional response. Even though a TU does not receive a provisional response, the TU needs to
TUが暫定的な応答がないときINVITE取引の64*T1タイムアウトの前の異なったToタグで複数の200応答を受けるとき、以下に、例の系列があります。 TUは暫定的な応答を受けませんが、TUは、受けます。
Hasebe, et al. Best Current Practice [Page 57] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[57ページ]RFC5407例の呼び出し流れ
process the 2xx responses (see Section 13.2.2.4 of RFC 3261 [1]). In that case, the DSM state is forked at the Confirmed state, and then the TU sends an ACK for the 2xx response and, immediately after, the TU usually sends a BYE. (In special cases, e.g., if a UA intends to establish multiple dialogs, the TU may not send the BYE.)
セクション13.2を見てください。2xx応答を処理してください、(.2 .4RFC3261[1])。 その場合、DSM状態はConfirmed状態で分岐します、そして、次に、TUは2xx応答のためにACKを送ります、そして、直後に、通常、TUはBYEを送ります。 (特別な場合では、例えば、UAが複数の対話を確立するつもりであるなら、TUはBYEを送らないかもしれません。)
UAC
dialog(A) | INVITE F1
Pre o |----------------------->
| | 100 F2
| |<-----------------------
| | 180(To tag=A) F3
Ear | |<-----------------------
| |
| | 200(A) F4
Mora |..........|<-----------------------
| ^ | ACK(A) F5
Est | | |----------------------->
| | |
dialog(B) | |64*T1 |
forked new DSM | | | 200(To tag=B) F6
Mora o..........|.|........|<-----------------------
| | | | ACK(B) F7
Est |..........|.|........|----------------------->
| | | | BYE(B) F8
Mort |..........|.|........|----------------------->
^ | | | | 200(B) F9
| | | | |<-----------------------
| | | V |
|Timer K | (terminate INVITE transaction)
| | | |
V | | |
Morg o | |
| |
UAC dialog(A)| INVITE F1Pre o|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 100 F2| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 180、(タグ=a)F3耳| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| 200(A) F4モーラ|..........| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| ^ | ACK(A) F5エスト| | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、| 対話(B)| |64*T1| 股状の新しいDSM| | | 200 (=Bにタグ付けをする) F6 Mora o.…|.|........| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| ACK(B) F7エスト|..........|.|........|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| さようなら(B)F8角笛の音|..........|.|........|----------------------->^| | | | 200(B) F9| | | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| V| |タイマK| (INVITE取引を終えます) | | | | V| | | Morg o| | | |
Figure 6: Receiving 2xx responses with different To tags
図6: 異なったToタグで2xx応答を受けます。
Below is an example sequence in which the option tag 100rel (RFC 3262 [5]) is required by a 180.
以下に、オプションが100relにタグ付けをする例の系列があります。(RFC3262[5])は180によって必要とされます。
If a forking proxy supports 100rel, it transparently transmits to the UAC a provisional response that contains a Require header with the value of 100rel. Upon receiving a provisional response with 100rel, the UAC establishes the early dialog (B) and sends PRACK (Provisional Response Acknowledgement). (Here, also, every transaction completes independently of others.)
分岐しているプロキシが100relを支持するなら、それは透明に100relの値でRequireヘッダーを含む暫定的な応答をUACに伝えます。 100relとの暫定的な応答を受けると、UACは早めの対話(B)を確立して、PRACK(暫定的なResponse Acknowledgement)を送ります。 (また、ここに、あらゆる取引が他のものの如何にかかわらず完成します。)
Hasebe, et al. Best Current Practice [Page 58] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[58ページ]RFC5407例の呼び出し流れ
As in Figure 4, the early dialog (B) terminates at the same time the INVITE transaction terminates. In the case where a proxy does not support 100rel, the provisional response will be handled in the usual way (a provisional response with 100rel is discarded by the proxy, not to be transmitted to the UAC).
図4のように、早めの対話(B)は同時に、取引が終えるINVITEを終えます。 プロキシが100relを支持しない場合では、暫定的な応答は不断のとおり扱われるでしょう(100relとの暫定的な応答はUACに伝えられないようにプロキシによって捨てられます)。
UAC
dialog(A) | INVITE F1
Pre o |------------------------->
| | 100 F2
| |<-------------------------
| | 180(To tag=A) F3
Ear | |<-------------------------
| | 200(A) F4
Mora |..........|<-------------------------
| ^ | ACK(A) F5
Est | | |------------------------->
dialog(B) | | |
forked new DSM | | | 180(To tag=B) w/100rel F6
Ear o..........|.|........|<-------------------------
| | | | PRACK(B) F7
| | | |------------------------->
| | | | 200(B,PRACK) F8
| | | |<-------------------------
| | |64*T1 |
| | |(13.2.2.4 of RFC 3261 [1])
| | | |
| | | |
| | | |
| | V |
o..........|.(terminate INVITE transaction)
terminated | |
dialog(B) | |
| |
UAC dialog(A)| INVITE F1Pre o|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、| 100 F2| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 180、(タグ=a)F3耳| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| 200(A) F4モーラ|..........| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| ^ | ACK(A) F5エスト| | |------------------------->対話(B)| | | 股状の新しいDSM| | | 180 (=Bにタグ付けをする) w/100rel F6 Ear o.…|.|........| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、|、| PRACK(B) F7| | | |、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>|、|、|、| 200(B、PRACK)F8| | | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、| |64*T1| | | |(13.2、.2、.4RFC3261[1]) | | | | | | | | | | | | | | V| o..........|終わります(INVITE取引を終えます)。| | 対話(B)| | | |
Figure 7: Receiving 1xx responses with different To tags
when using the mechanism for reliable provisional responses (100rel)
図7: 信頼できる暫定的な応答にメカニズムを使用するとき、異なったToタグで1xx応答を受けます。(100rel)
Hasebe, et al. Best Current Practice [Page 59] RFC 5407 Example Call Flows of Race Conditions December 2008
Hasebe、他 競合条件2008年12月の最も良い現在の習慣[59ページ]RFC5407例の呼び出し流れ
Authors' Addresses
作者のアドレス
Miki Hasebe NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
3丁目の新宿区、三木Hasebe NTT-東の社19-2の西-shinjuku東京163-8019JP
EMail: hasebe.miki@east.ntt.co.jp
メール: hasebe.miki@east.ntt.co.jp
Jun Koshiko NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
3丁目の新宿区、6月のKoshikoのNTT東の社19-2の西-shinjuku東京163-8019JP
EMail: j.koshiko@east.ntt.co.jp
メール: j.koshiko@east.ntt.co.jp
Yasushi Suzuki NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 JP
ヤスシ鈴木NTT社の9-11テロ、美土里町の3丁目の武蔵野市、東京180-8585JP
EMail: suzuki.yasushi@lab.ntt.co.jp
メール: suzuki.yasushi@lab.ntt.co.jp
Tomoyuki Yoshikawa NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
Tomoyuki NTT東の社19-2の西-shinjukuの3丁目の新宿区、東京吉川163-8019JP
EMail: tomoyuki.yoshikawa@east.ntt.co.jp
メール: tomoyuki.yoshikawa@east.ntt.co.jp
Paul H. Kyzivat Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 US
Boxborough、ポールH.KyzivatシスコシステムズInc.1414MA01719米国マサチューセッツ通り
EMail: pkyzivat@cisco.com
メール: pkyzivat@cisco.com
Hasebe, et al. Best Current Practice [Page 60]
Hasebe、他 最も良い現在の習慣[60ページ]
一覧
スポンサーリンク
