[要約] 要約：RFC 5407は、SIP（セッション開始プロトコル）における競合状態の例と呼び出しフローを提供しています。 目的：このRFCの目的は、SIPの競合状態に関する理解を深め、開発者やネットワークエンジニアが問題を特定し、解決するためのガイドラインを提供することです。
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
Example Call Flows of Race Conditions in the Session Initiation Protocol (SIP)
例セッション開始プロトコル（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.
このドキュメントは、インターネットコミュニティのインターネットの最良のプラクティスを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントは、セッション開始プロトコル（SIP）のレース条件のコールフローの例を示します。人種条件は本質的に混乱しており、阻止するのが困難です。このドキュメントは、それらを処理するためのベストプラクティスを示しています。これらの呼び出しフローの要素には、SIPユーザーエージェントとSIPプロキシサーバーが含まれます。コールフロー図とメッセージの詳細が記載されています。
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
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通信ネットワークの設計で開発されました。これらの例は、ダイアログ状態の遷移に起因する人種条件のものです。これは、主に招待状の送信後のセッション施設中の移行です。
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ユーザーエージェント（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実装者、デザイナー、およびプロトコル研究者にとって有用であり、RFC 3261 [1]の標準的な実装の目標を達成するのに役立つことは著者の希望です[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].
これらの呼び出しフローは、RFC 3261 [1]で定義されているSIPのバージョン2.0に基づいており、RFC 3264 [2]で説明されているSDPの使用法があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [3]に記載されているように解釈される。
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などの特定の基礎となる輸送プロトコルを想定していません。SIPの輸送問題の詳細については、RFC 3261 [1]のディスカッションを参照してください。
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 < - ）は、パケットが失われていることを示します。矢印は、メッセージフローの方向を示します。ダブルダッシュライン（===）は、ネットワーク要素間のメディアパスを表します。
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. */
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メソッド、ヘッダー、パラメーターのベストプラクティスの使用（注文、構文、目的のための機能の選択、またはエラーの取り扱い）です。注：このドキュメントのフローは、説明を容易にするために追加の注釈がこのドキュメントに組み込まれているため、実装者によってISによってコピーされてはなりません。要約すると、このドキュメントで説明されている手順は、IETFコンセンサスに従って最良の一般的な実践を例示するSIP使用のよくレビューされた例を表しています。
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で始まり、ヘッダーフィールドは通常同じ順序で表示され、通常は必要な最小ヘッダーフィールドセットのみが表示され、通常は受け入れたような他のヘッダーのみが表示されます。許可などは表示されません。
Actors:
俳優：
Element Display Name URI IP Address
------- ------------ --- ----------
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
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.
「セッション」という用語は、RFC 3261 [1]のセクション13-15で使用されているのと同じ方法で、このドキュメントで使用されています（RFC 3261の用語の定義とは多少異なります）。RFC 5057 [6]は、より正確に定義されている別の用語「ダイアログ使用」を導入します。ここで使用される「セッション」という用語は、「招待ダイアログの使用」という用語とほぼ同じではありませんが、まったく同一ではありません。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.
たとえば、UAC（ユーザーエージェントクライアント）が初期状態でキャンセルを送信すると、UAS（ユーザーエージェントサーバー）が初期の招待状に200 OKを送信することにより、初期状態から確認された状態に移行している場合にレース条件が発生します（ユーザーエージェントサーバー）以下「ini-invite」として示されています）。招待ダイアログの使用に関するDSM（ダイアログステートマシン）は、人種条件でのUAの行動を理解するために次のように表示されます。
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は、RFC 3261 [1]に示されているダイアログ状態をさまざまな内部状態に細分化することにより、UAの行動を明確にします。私たちは、対話の確立前に州を対象状態と呼びます。確認された状態は、一時停止と確立された状態の2つの物質に細分化され、終了状態は致命的および遺体安置所の状態に細分されます。これらの状態間の状態遷移のトリガーであるメッセージは、矢印で示されます。この図では、状態遷移に関連していないメッセージは省略されています。
Below are the DSMs, first for the caller and then for the callee.
以下はDSMSです。最初は発信者、次にCalleeの場合です。
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-+
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
(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：招待ダイアログの使用のためのDSM（発信者）
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は、招待ダイアログの使用に関する発信者のDSMを表しています。この動作は推奨されないにもかかわらず、発信者は初期の状態でさようならを送ることができます。初期の状態で送信されたさようならは、特定のタグを使用して早期ダイアログを終了します。つまり、プロキシがフォーキングを実行している場合、Byeは特定のUAとの初期の対話のみを終了することができます。発信者が特定のUAではその代わりにすべての早期ダイアログを終了したい場合、Byeではなくキャンセルを送信する必要があります。ただし、これが発信者の意図である場合、特定の初期の対話を終了するために初期の状態でさようならを送ることは違法ではありません。さらに、発信者が最終的な応答を受信して招待トランザクションを終了するまで、発信者は、キャンセルまたはさようならを既に送信してダイアログを終了していても、招待に対する新しい応答を受信してダイアログを確立する準備をしなければなりません（付録Aを参照してください。）。
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| |
| | | | | | | |
| +---------------+ | | +-----------+ |
| | | |
+------------------------+ +------------------+
(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：招待ダイアログの使用のためのDSM（Callee）
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 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.
図2は、招待ダイアログの使用に関するCalleeのDSMを表しています。この図は、キャンセル要求に関連する状態遷移を示していません。キャンセル要求は、ダイアログ状態の移行を引き起こしません。ただし、Calleeはダイアログを終了し、キャンセルの受信直後に487を送信することによりダイアログの遷移をトリガーします。キャンセルリクエストを受信したときのこの動作については、付録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.
PRACEATIVE（PRE）：INIインバイトが送信または受信された後、タグに対する暫定的な応答を送信または受信することにより、初期の対話が確立されるまで、準備状態は有効です。ダイアログはまだ準備状態には存在しません。UAが2xxの応答を送信または受信した場合、ダイアログ状態は、検定状態からモラトリアム状態に移行します。さらに、UAが3XX-6XXの応答を送信または受信した場合、ダイアログ状態は、終了状態のサブサンである遺体安置所の状態に移行します。3XX-6XX応答のためにACKを送信し、3XX-6XXの再送信はDSMSには表示されません。これは、Inviteトランザクションによって送信されるためです。
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.
早期（耳）：初期のダイアログは、100の試行を除いて暫定的な応答を送信または受信することにより確立されます。この状態にはダイアログがまだ存在しないにもかかわらず、初期のダイアログは存在します。ダイアログ状態は、2xxの応答を送信または受信することにより、初期状態から確認された状態のサブサン状態に移行します。さらに、ダイアログ状態は、3XX-6XX応答を送信または受信することにより、終了状態の物質である遺体安置所の状態に移行します。3XX-6XX応答のためにACKを送信し、3XX-6XXの再送信は、トランザクションレイヤーで自動的に処理され、ダイアログ状態に影響しないため、このDSMには表示されません。UACは、初期の状態でキャンセルを送信する場合があります。UACはさようならを送信することもあります（推奨されませんが）。UASは1xx-6xx応答を送信する場合があります。キャンセルリクエストの送信または受信は、ダイアログ状態に直接的な影響を与えません。キャンセルリクエストの受信時のUAの動作については、付録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.
確認（CON）：2xxの最終応答の送信または受信は、ダイアログを確立します。ダイアログはこの状態で始まります。確認された状態は、BYE要求を送信または受信することにより、終了状態の物質である致命状態に移行します。確認された状態には、モラトリアムと確立された状態の2つの物質があり、UASが送信することが許可されているメッセージに関しては異なります。
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.
モラトリウム（MORA）：モラトリアム状態は確認された状態のサブジェントであり、その行動を継承しています。Moratorium状態は、ACK要求を送信または受信することにより、確立された状態に移行します。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.
確立された（EST）：確立された状態は、確認された状態の標準であり、その行動を継承しています。CallerとCalleeの両方が、ダイアログに影響を与えるさまざまなメッセージを送信する場合があります。発信者は、INIインバイトへの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）：終了状態は、ダイアログが終了しているときに動作をカバーするために、致命的および遺体安置所状態の2つの物質に細分されます。この状態では、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（MORT）：別紙を送信または受け取ることにより、発信者とCalleeが致命的な状態に入ります。ダイアログがないため、UAはダイアログ内に新しいリクエストを送信してはなりません。（ここでは、新しいリクエストには、以下の付録Dでさらに説明したように、新しいリクエストには2xxのACKと401または407のBYEが含まれていません。）MORTAL状態では、BYEを受け入れることができ、招待ダイアログの使用法の他のメッセージが応答されます。エラーがあります。これは、発信者とCallee Exchangeがセッションが終了しているときに報告する場合に対処します。したがって、UAは内部処理のためのダイアログ情報を所有していますが、ダイアログは外部から見えるべきではありません。UAは、ダイアログ状態の管理を停止し、BYEトランザクションが終了したときに遺体安置所状態に変更します。
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.
Morgue（Morg）：この状態にはダイアログが存在しなくなりました。ダイアログに影響を与える信号の送信または受信は実行されません。（ダイアログは文字通り終了します。）CallerとCalleeは、Byeまたは招待取引の終了を介して遺体安置所に入ります。
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.
このセクションでは、2つのSIP UAS、アリスとボブのレース条件について詳しく説明しています。Alice（sip：alice@atlanta.example.com）とBob（sip：bob@biloxi.example.com）は、SIP電話またはSIP対応デバイスであると想定されています。重要なシグナル伝達のみが示されています。SIPメッセージの送信または受信によって引き起こされるダイアログ状態の移行が表示され、人種条件は「*人種*」で示されます。（ダイアログ状態の遷移の略語については、セクション2を参照してください。） '*人種*'は、人種条件が発生した瞬間を示します。
Examples of race conditions are described below.
人種条件の例を以下に説明します。
This section shows some examples of call flow race conditions when receiving messages from other states while in the Moratorium state.
このセクションでは、モラトリアム状態で他の状態からメッセージを受信したときのコールフローレース条件の例をいくつか示しています。
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
| |
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が準備メッセージを受け取ったときに発生する人種状態を示しています。最初の招待（INIインバイトF1）に対するすべての暫定的な応答は失われ、UACはINIインバイト（F4）を再送信します。この再送信と同時に、UASはRFC 3261 [1]のセクション13.3.1.4に従って、INIインバイトに200 OK（F3）を生成し、招待サーバートランザクションを終了します。
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.
ただし、200 OKを送信するときに招待サーバートランザクションを終了することは、SIPに不可欠な修正であることが報告されています[7]。したがって、Invite ServerトランザクションはF3によって終了することはなく、F4は再送信として適切に処理する必要があります。
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.) Message Details
RFC 3261 [1]では、UASがINIインバイトの再送信に200を再送信するかどうかは指定されていません。RFC 3261 [1]のセクション13.3.1.4に従って、タイマー（トランザクションユーザー（TU）がT1とT2に基づいて200を再送信し続けると、T1とT2に基づいて200を再送信し続けると、200を再送信する必要はないようです。UASがINIインバイトの再送信を受けるとき。（実装のために、200が問題を引き起こさないため、UASが200の再送信を送信するかどうかは関係ありません。）メッセージの詳細
F1 INVITE Alice -> Bob
F1アリスを招待 - >ボブ
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
/* 180 response is lost and does not reach Alice. */
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
/* 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. */
F4 INVITE (retransmission) Alice -> Bob
F4 Invite（再送信）アリス - >ボブ
/* 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. */
F5 ACK Alice -> Bob
f5 ackアリス - >ボブ
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
| |
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].
このシナリオは、Moratorium状態でUASがキャンセルを受けるときにUASがキャンセルしたときに発生するレース条件を示しています。アリスはキャンセルを送信し、ボブは最初の招待メッセージに200 OK応答を同時に送信します。前のセクションで説明したように、RFC 3261 [1]によると、招待サーバートランザクションは200の応答によって終了することになっていますが、これは[7]で修正されています。
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 Serverトランザクションが招待リクエストに対する200の応答によって終了しない場合について説明します。この場合、キャンセル要求が一致する招待トランザクションがあるため、リクエストに対する200の応答が送信されます。この200の応答は、単に次のホップがキャンセル要求を受信することを意味します（成功したキャンセル（200）は、招待が実際にキャンセルされたことを意味しません）。UASが修正[7]を扱っていない場合、UACはキャンセル要求が一致するトランザクションがないため、キャンセルに対する481の応答を受信する場合があります。この481は、一致する招待サーバートランザクションがなく、キャンセルが次のホップに送信されないことを意味します。キャンセルの成功/失敗に関係なく、アリスは招待への最終的な応答をチェックし、招待状のリクエストに200を受け取った場合、すぐにさようならを送信し、ダイアログを終了します。（セクション15、RFC 3261 [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がボブによって送信されるまで、メディアはボブからアリスまでの1つの方法で流れている可能性があります。ボブからアリスが答えを受け取った時から、メディアがアリスからボブにも流れる可能性があります。しかし、アリスが電話をキャンセルすることを決めた後、彼女はおそらくメディアを送信しないので、実際に言えば、メディアのストリームは一つの方法のままです。
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. */
F4 200 OK (INVITE) Bob -> Alice
F4 200 OK（招待）ボブ - >アリス
/* 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. */
F5 200 OK (CANCEL) Bob -> Alice
F5 200 OK（キャンセル）ボブ - >アリス
/* 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. */
F6 ACK Alice -> Bob
F6 Ack Alice-> Bob
/* INVITE is successful, and the CANCEL becomes invalid. Bob
establishes RTP streams. However, the next BYE request
immediately terminates the dialog and session. */
F7 BYE Alice -> Bob
F7バイアリス - >ボブ
F8 200 OK Bob -> Alice
F8 200 OKボブ - >アリス
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
| |
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 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.
このシナリオは、モラトリアム状態でUASが初期のメッセージであるByeを受け取ったときに発生する人種状態を示しています。アリスは初期の州でさようならを送り、ボブは同時に最初の招待リクエストに200 OKを送信します。ボブは確認されたダイアログ状態でさようならを受け取りますが、アリスは初期状態で要求を送信しました（セクション2および付録Aで説明したように、この動作は推奨されません）。プロキシがフォーキングを実行している場合、Byeは特定のUAとの初期のダイアログのみを終了することができます。発信者が特定のUAでのみではなく、すべての初期のダイアログを終了したい場合は、別れではなくキャンセルを送信する必要があります。ただし、それが発信者の意図である場合、特定の初期の対話を終了するために初期の状態でさようならを送ることは違法ではありません。
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は、BYEがキャンセルとは異なり、リクエストではなくダイアログに送信されるため、招待トランザクション終了後に受信された場合でも、通常は機能します。アリスは、さようならリクエストを送信する際に致命的な状態に入り、タイマーKのタイムアウトが発生するまで致命的なままです。致命的な状態では、UACは招待に対する200の応答を受け取ったとしても、セッションを確立しません。それでも、UACは招待取引を完了するためにACKを200に送信します。ACKは常に送信され、招待トランザクションの3方向の握手を完了します（以下の付録Dでさらに説明します）。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1アリスを招待 - >ボブ
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK (ini-INVITE) Bob -> Alice
f3 200 ok（ini -invite）ボブ - >アリス
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. */
F5 ACK Alice -> Bob
f5 ackアリス - >ボブ
F6 200 OK (BYE) Bob -> Alice
F6 200 OK（さようなら）ボブ - >アリス
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
|------------------------------->|
| |
| |
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.
このシナリオは、モラトリアム州のUASが確立された状態でUACから送信された再標識を受け取ったときに発生する人種条件を示しています。
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.)
UASは、INIインバイトのACKを受信する前に（offer2を使用して）re invite（offer2）を受け取ります。UASは、200 ok（and with reass2）を再インンヴィテ（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 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.
以下のセクション3.3.2で見られるように、491の応答は、招待クロスオーバー以外の場合でも、セッションの確立に密接に関連しているようです。この例では、セッションに影響を与えないため、491の代わりに200を送信することを推奨しています。ただし、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を受け取らない場合、別れを送信してダイアログを終了する必要があります。ACK F7のINIインバイトF1と同じCSEQ数を持っていることに注意してください（RFC 3261 [1]のセクション13.2.2.4を参照）。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.
注：実装の問題はこのドキュメントの範囲外ですが、このタイプの人種条件を避けるために、次のヒントが提供されています。発信者は、Re-Invite F6の送信をしばらくの間（おそらく2秒）遅延させることができます。その後、発信者はACKが受信されたことを合理的に想定できます。実装者は、UAがこのように振る舞うことができるように、プロトコルのアクション（Re-Invite F6の送信）からユーザーのアクション（ホールドボタンを押す）を切り離すことができます。この場合、それはどのくらい待つかについての実装者の選択です。ほとんどの場合、このような実装は、このセクションに示されている人種状態の種類を防ぐのに役立つ場合があります。このドキュメントは、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
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
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/8000000000000000000
/* 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
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
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
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
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
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
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-Length: 0
call-id：3848276298220188511@atlanta.example.com CSEQ：1 ACKコンテンツレングス：0
/* The ACK request is lost. */
F5(=F3) 200 OK Bob -> Alice (retransmission)
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
F6 re-INVITE Alice -> Bob
f6 re invite alice-> bob
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
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
V = 0 O = Alice 2890844526 2890844527 in ip4 client.atlanta.example.com s = -c = In ip4 192.0.2.101 t = 0 M = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000 = sendonlyly
F7(=F4) ACK Alice -> Bob (retransmission)
/* "(=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. */
F8 200 OK (re-INVITE) Bob -> Alice
f8 200 ok（re -invite）ボブ - >アリス
SIP/2.0 200 OK
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: 143
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
F9 ACK (re-INVITE) Alice -> Bob
F9 ACK（Re -Invite）Alice-> Bob
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
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
|------------------------------->|
| |
| |
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のシナリオと同じですが、200でオファーを送信し、ACKでの回答を送信することが異なります。前のケースとは対照的に、200（F3）のオファーとRe 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.
ボブは、回答を受け取るまで新しいリクエストを適切に処理できないため、491をRe Invite（F6）に送信します。（注：491応答がリクエストの衝突を示すと理解されている場合、再試行後のヘッダーを備えた500が返される場合があります。ただし、ここでは491が推奨されます。これは、実際の問題が何であるかを判断するのが難しい非常に多くのケースに500が適用されるためです。）F6がオファーの更新である場合、同じ結果に達します。
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秒、おそらく2秒）、再入札F6の送信を遅らせる可能性があります。人種の状態。このドキュメントは、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
/* 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 200 OKボブ - >アリス
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
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
/* An offer is made in 200. */
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
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
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
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/8000000000000000000
/* The request contains an answer, but the request is lost. */
F5(=F3) 200 OK Bob -> Alice (retransmission)
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
F6 re-INVITE Alice -> Bob
f6 re invite alice-> bob
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
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
/* The request contains an offer. */
F7(=F4) ACK Alice -> Bob (retransmission)
/* 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. */
F8 491 (re-INVITE) Bob -> Alice
F8 491（re -invite）ボブ - >アリス
/* Bob sends 491 (Request Pending), since Bob has a pending
offer. */
F9 ACK (re-INVITE) Alice -> Bob
F9 ACK（Re -Invite）Alice-> Bob
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
| |
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.
このシナリオは、Moratorium状態でUASが確立されたメッセージであるByeを受け取ったときに発生する人種条件を示しています。200 OK応答のACKリクエストが失われます（または遅延）。ボブは200 OKをINI Inviteに再送信し、同時にアリスがさようならリクエストを送信し、セッションを終了します。再送信された200 OKを受け取ると、アリスのUAはセッションを再確立する傾向があるかもしれません。しかし、それは間違っています - ダイアログが致命的な状態にあるとき、セッションは再確立されるべきではありません。さらに、UASが200 OKでオファーを送信する場合、UASがさようならを受け取った後に再送信されたACKを受け取った場合、同じ理由でUASが再びセッションを開始するべきではありません。
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で述べたように、実装の問題はこのドキュメントの範囲外ですが、このタイプの人種条件を避けるために次のヒントが提供されています。発信者は、Bye F6の送信をしばらくの間（おそらく2秒）遅延させることができます。その後、発信者はACKが受信されたことを合理的に想定できます。実装者は、UAがこのように振る舞うことができるように、プロトコルのアクション（Bye F6の送信）からユーザーのアクション（たとえば、たとえば吊り上げ）を切り離すことができます。この場合、それはどのくらい待つかについての実装者の選択です。ほとんどの場合、このような実装は、このセクションに示されている人種状態の種類を防ぐのに役立つ場合があります。このドキュメントは、ACKが配信されるのを待つべきかどうかについての好みを表しています。ユーザーエクスペリエンスへの影響を検討した後、実装者は、ユーザーエクスペリエンスが実装に依存し、プロトコルの動作に直接関係していないため、しばらく待つかどうかを決定する必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1アリスを招待 - >ボブ
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
/* ACK request is lost. */
F5(=F3) 200 OK Bob -> Alice
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
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. */
F7(=F4) ACK Alice -> Bob
/* "(=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. */
F8 200 OK (BYE) Bob -> Alice
F8 200 OK（さようなら）ボブ - >アリス
/* Bob sends a 200 OK to the BYE. */
This section shows some examples of call flow race conditions when receiving messages from other states while in the Mortal state.
このセクションでは、致命的な状態で他の状態からメッセージを受信するときのコールフローレース条件の例をいくつか示しています。
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
| |
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が確立されたメッセージであるByeを受け取ったときに発生する人種状態を示しています。アリスとボブは同時にさようならを送ります。ダイアログとセッションは、BYEリクエストがクライアントトランザクションに渡された直後に終了します。セクション2に示すように、UAは致命的な状態にとどまります。
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 StateのUASは、re invite、update、またはreferingなど、ダイアログまたはセッション内で動作するリクエストに対するエラー応答を返します。ただし、UAは、発信者とCallee Exchangeがセッションが終了しているときに報告している場合に、ユースケースを考慮に入れて、200 OKをByeに戻します。（ダイアログとセッションの両方がBYEの送信時に終了するため、致命的な状態にいる間にさようならを受信したときに200またはエラー応答を送信する選択は、結果として生じる終了に影響しません。したがって、この例では200を使用していますが応答、他の応答も使用できます。）
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1アリスを招待 - >ボブ
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
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. */
F6 BYE Bob -> Alice
F6バイボブ - >アリス
/* Bob has also transmitted a BYE simultaneously with Alice. Bob
terminates the session and the dialog. */
F7 200 OK Bob -> Alice
F7 200 OKボブ - >アリス
/* Since the dialog is in the Moratorium state, Bob responds with a
200 to the BYE request. */
F8 200 OK Alice -> Bob
F8 200 OKアリス - >ボブ
/* 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. */
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
| |
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 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).
このシナリオは、致命的な状態で、UASが確立されたメッセージ「Re Invite」を受け取ったときに発生する人種条件を示しています。ボブは再インバイトを送り、アリスは同時にさようならを送ります。AliceのTuがByeを送信することにより、確立された状態からMortal Stateに移行したため、Re-Inviteは481の応答を受け取ります。ボブは、エラー応答のACKがトランザクションレイヤーによって処理され、481を受信した時点で招待クライアントトランザクションがまだ残っているため、481応答のACKを送信します（ダイアログが終了していても）。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1アリスを招待 - >ボブ
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
F5 BYE Alice -> Bob
F5バイアリス - >ボブ
/* Alice sends a BYE and terminates the session, and transitions from
the Established state to the Mortal state. */
F6 re-INVITE Bob -> Alice
f6 re invite bob->アリス
/* 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. */
F7 200 OK (BYE) Bob -> Alice
F7 200 OK（さようなら）ボブ - >アリス
F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob
F8 481コール/トランザクションは存在しません（re invite）アリス - >ボブ
/* Since Alice is in the Mortal state, she responds with a 481 to the
re-INVITE. */
F9 ACK (re-INVITE) Bob -> Alice
F9 ACK（Re -Invite）Bob-> Alice
/* ACK for an error response is handled by Bob's INVITE client
transaction. */
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 | |
| |
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が確立されたメッセージを受け取ったときに発生する人種状態を示しています。ボブは、再ヴァイトを送信した直後にさようならを送ります。（たとえば、電話申請の場合、セッションを更新した直後にユーザーが電話を切る可能性があります。）ボブは、招待状態で招待状に200回の応答のために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. 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は、Re-Invite Transaction F5が完了するまで、Bye F6の送信を遅らせることができます。実装者は、UAがこのように振る舞うことができるように、プロトコルのアクション（Bye F6の送信）からユーザーのアクション（たとえば、たとえば吊り上げ）を切り離すことができます。この場合、それはどのくらい待つかについての実装者の選択です。ほとんどの場合、このような実装は、このセクションで説明されている人種状態のタイプを防ぐのに役立つかもしれません。このドキュメントは、ACKが配信されるのを待つべきかどうかについての好みを表しています。ユーザーエクスペリエンスへの影響を検討した後、実装者は、ユーザーエクスペリエンスが実装に依存し、プロトコルの動作に直接関係していないため、しばらく待つかどうかを決定する必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1アリスを招待 - >ボブ
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
F5 re-INVITE Bob -> Alice
f5 re invite bob->アリス
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
/* Some detailed messages are shown for the sequence to illustrate
that the re-INVITE is handled in the usual manner in the Mortal
state. */
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. */
F7 200 OK (re-INVITE) Alice -> Bob
f7 200 ok（re -invite）アリス - >ボブ
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
/* Bob sends BYE, and Alice responds with a 200 OK to the re-INVITE.
A race condition occurs. */
F8 200 OK (BYE) Alice -> Bob
F8 200 OK（さようなら）アリス - >ボブ
F9 ACK (re-INVITE) Bob -> Alice
F9 ACK（Re -Invite）Bob-> Alice
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
/* Bob sends ACK in the Mortal state to complete the three-way
handshake of the INVITE transaction. */
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 | |
| |
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が致命的な状態で確立されたメッセージ（ACK）を受け取ったときに発生する人種条件を示しています。アリスはACKを送り、ボブは同時にさようならを送ります。オファーが2xxで、答えがACKにある場合、人種状態があります。Bobが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で述べたように、実装の問題はこのドキュメントの範囲外ですが、このタイプの人種条件を避けるために次のヒントが提供されています。実装者は、UAがこのように振る舞うことができるように、プロトコルのアクション（Bye F5の送信）からユーザーのアクション（ハングアップ）を切り離すことができます。この場合、それはどのくらい待つかについての実装者の選択です。ほとんどの場合、このような実装は、このセクションで説明されている人種状態のタイプを防ぐのに役立つかもしれません。このドキュメントは、ACKが配信されるのを待つべきかどうかについての好みを表しています。ユーザーエクスペリエンスへの影響を検討した後、実装者は、ユーザーエクスペリエンスが実装に依存し、プロトコルの動作に直接関係していないため、しばらく待つかどうかを決定する必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1アリスを招待 - >ボブ
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
/* RTP streams are established between Alice and Bob. */
F5 BYE Alice -> Bob
F5バイアリス - >ボブ
F6 200 OK Bob -> Alice
F6 200 OKボブ - >アリス
/* Alice sends a BYE and terminates the session and dialog. */
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つのレイヤーで展開されます。それらは互いに関連していますが、個別に扱わなければなりません。RFC 3261 [1]のセクション17 [1]は、トランザクションの処理について詳しく説明しています。このドキュメントは、ダイアログの処理を明確にするためにこれまでに試みました。このセクションでは、SIPで確立されたセッションに関連する人種条件について説明します。
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| 200 OK F3 |
|<---------------------------|
| ACK F4 |
|--------------------------->|
| Both Way RTP Media |
|<==========================>|
| |
|re-INVITE F5 re-INVITE F6 |
|------------ -------------|
| \ / |
| 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 |
|--------------------------->|
| |
| |
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.
このシナリオでは、アリスとボブは同時に再インバイトを送信します。RFC 3261 [1]のセクション14.1に従って、同じダイアログで2つの再インバイトが交差すると、それぞれ異なる間隔の後に再試行されます。アリスがre inviteを送信し、ボブと交差すると、call-idを所有しているため、2.1-4.0秒後に再インバイトが再試行されます（彼女は生成しました）。ボブは0.0-2.0秒後に再び招待を再試行します。なぜなら、ボブはコールアイドの所有者ではないからです。
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.
したがって、各ユーザーエージェントは、招待状が別の招待状と交差する場合に備えて、ダイアログのコールIDを生成したかどうかを覚えておく必要があります。
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.
この例では、AliceのRe Inviteはセッションの変更のためであり、BobのRe Inviteはセッションの更新です。この場合、491回の回答の後、ボブはアリスよりも早くセッションリフレッシュのために再入力を取得します。アリスが彼女の再入手を再試行する場合（つまり、彼女がCall-IDの所有者ではない場合）、リクエストは同時にセッションを更新して変更します。それからボブは、セッションをリフレッシュするために彼の再入手を再試行する必要がないことを知っているでしょう。
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.)
別の例では、セッション修正のための2つの再インバイトが交差し、コールアイドの所有者による491の後に同じ再インバイトを再び再試行します（他のUAの後に再インバイトを取得するUA）は意図しない動作をもたらす可能性があります、したがって、UAは、再インバイトの再試行が必要かどうかを決定する必要があります。（たとえば、コールホールドとビデオメディアの追加がクロスオーバーすると、タイマーの発射時に再インバイトを再試行すると、オーディオの保持直後にビデオが送信される状況になります。おそらくユーザーが意図していません。）
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1アリスを招待 - >ボブ
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
F5 re-INVITE Alice -> Bob
f5 re invite alice-> bob
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
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
V = 0 O = Alice 2890844526 2890844527 in ip4 client.atlanta.example.com s = -c = In ip4 192.0.2.101 t = 0 M = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000 = sendonlyly
/* Some detailed messages are shown for the sequence to illustrate
what sort of INVITE requests crossed over each other. */
F6 re-INVITE Bob -> Alice
f6 re invite bob->アリス
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
/* A re-INVITE request for a session refresh and another for a call
hold are sent at the same time. */
F7 491 Request Pending Bob -> Alice
F7 491リクエスト保留中のボブ - >アリス
/* Since a re-INVITE is in progress, a 491 response is returned. */
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 Re Invite Bob-> Alice
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
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
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
/* Since Bob is not the owner of the Call-ID, he sends a re-INVITE
again after 0.0-2.0 seconds. */
F12 200 OK Alice -> Bob
F12 200 OKアリス - >ボブ
F13 ACK Bob -> Alice
F13 ACK BOB->アリス
F14 re-INVITE Alice -> Bob
f14 re invite alice-> bob
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
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
V = 0 O = Alice 2890844526 2890844527 in ip4 client.atlanta.example.com s = -c = In ip4 192.0.2.101 t = 0 M = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000 = sendonlyly
/* Since Alice is the owner of the Call-ID, Alice sends a re-INVITE
again after 2.1-4.0 seconds. */
F15 200 OK Bob -> Alice
F15 200 OKボブ - >アリス
F16 ACK Alice -> Bob
F16 ACKアリス - >ボブ
Alice Bob
| |
| INVITE F1 |
|--------------------------->|
| 180 Ringing F2 |
|<---------------------------|
| |
| 200 OK F3 |
|<---------------------------|
| 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 |
|<---------------------------|
| |
| |
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.
このシナリオでは、更新にはSDPオファーが含まれています。したがって、更新とreのヴァイトは、「再入力クロスオーバー」の場合のように、491で両方とも応答されます。セッションの説明が含まれていないセッション更新の更新と再入手が互いに交差する場合、両方のリクエストが200で成功します（491はUAに保留中の要求があることを意味します）。同じことが更新クロスオーバーにも当てはまります。いずれかの更新にセッションの説明が含まれている前者の場合、リクエストは491で失敗します。後者の場合、彼らは200で成功します。
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 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
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
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
V = 0 O = Alice 2890844526 2890844527 in ip4 client.atlanta.example.com s = -c = In ip4 192.0.2.101 t = 0 M = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000 = sendonlyly
/* Some detailed messages are shown for the sequence to illustrate
messages crossing over each other. */
F6 re-INVITE Bob -> Alice
f6 re invite bob->アリス
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-Type: application/sdp
Content-Length: 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
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
/* 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. */
F7 491 Request Pending (UPDATE) Bob -> Alice
F7 491リクエスト保留中（更新）ボブ - >アリス
/* Since a re-INVITE is in process, a 491 response is returned. */
F8 491 Request Pending (re-INVITE) Alice -> Bob
F8 491リクエスト保留中（re -invite）アリス - >ボブ
F9 ACK (re-INVITE) Alice -> Bob
F9 ACK（Re -Invite）Alice-> Bob
F10 re-INVITE Bob -> Alice
f10 re invite bob->アリス
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
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
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
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
/* Since Bob is not the owner of the Call-ID, Bob sends an INVITE
again after 0.0-2.0 seconds. */
F11 200 OK Alice -> Bob
F11 200 OKアリス - >ボブ
F12 ACK Bob -> Alice
F12 ACK BOB->アリス
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
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. */
F14 200 OK Bob -> Alice
F14 200 OKボブ - >アリス
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
| |
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 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].
このシナリオは、致命的な状態でUASが確立されたメッセージを受け取ったときに発生する人種条件を示しています。ボブは紹介を送り、アリスは同時にさようならを送ります。ボブは同じダイアログで紹介を送信します。アリスのダイアログ状態は、さようならを送る時点で致命的な状態に移動します。致命的な状態では、UAは内部プロセスのダイアログ情報を所有していますが、ダイアログは外向きに存在してはなりません。したがって、UAは参照にエラー応答を送信します。これは、ミッドダイアログリクエストとして送信されます。したがって、アリスは、致命的な状態で、紹介にエラー応答を送信します。ただし、Bobは既にfurcribeの使用法を参照してサブスクライブ使用を開始しているため、招待されたダイアログの使用がさようならを受け取ることで終了する場合でも、サブスクライブの使用が終了するまでダイアログが続きます。この場合のボブの行動は、RFC 5057の手順に従う必要があります[6]。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
F1アリスを招待 - >ボブ
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 Ack Alice-> Bob
F5 BYE Alice -> Bob
F5バイアリス - >ボブ
/* Alice sends a BYE request and terminates the session, and
transitions from the Confirmed state to the Terminated state. */
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. */
F7 200 OK (BYE) Bob -> Alice
F7 200 OK（さようなら）ボブ - >アリス
F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob
F8 481コール/トランザクションは存在しません（参照）アリス - >ボブ
/* Alice in the Mortal state sends a 481 to the REFER. */
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.
このドキュメントには、RFC 3261 [1]、RFC 3264 [2]、およびRFC 3515 [4]で指定された行動の明確化が含まれています。これらの文書のセキュリティ上の考慮事項は、これらの説明を適用した後も引き続き適用されます。
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.
著者は、ロバート・スパークス、ディーン・ウィリス、カレン・ジェニングス、ジェームズ・M・ポーク、ゴンザロ・カマリロ、小川、清水秀樹、ムナカタ、田中陽、田中、田中kokoro、hiragi hiragi、viijay、g.この文書に関するコメントについては、Anders Kristensen。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[2] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[4] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[5] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[5] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定的な応答の信頼性」、RFC 3262、2002年6月。
[6] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[6] Sparks、R。、「セッション開始プロトコルでの複数のダイアログ使用」、RFC 5057、2007年11月。
[7] Sparks, R., "Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests", Work in Progress, July 2008.
[7] Sparks、R。、「セッション開始プロトコル招待リクエストに対する200の応答のための正しいトランザクション処理」、2008年7月の作業。
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が推奨されない理由について説明し、初期の対話の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 |<------------------------|
|<---------------| |
| | |
| | |
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
プロキシによるフォーキングが予想される場合、初期の状態でさようならを送信することに注意が払われます。この例では、BYEリクエストは正常に進行し、BOBとのダイアログを正しく終了することに成功します。Bobがさようならを受け取って対話を終了した後、彼は487をINIインバイトに送ります。RFC 3261のセクション15.1.2によると
[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がBYEを受け取った後、保留中のリクエストに487を生成することをお勧めします。この例では、ボブはINIインバイトが保留中の状態にある間にさようならを受け取るため、487をINIインバイトに送信します。
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.
ただし、アリスは、ボブとの対話をうまく終了したにもかかわらず、招待（キャロルから200人）への最終的な応答を受け取ります。これは、初期の州でのさようならの成功/失敗に関係なく、アリスは招待の最終的な応答を受け取り、招待取引を終了するまで、新しいダイアログの確立に備えなければならないことを意味します。
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.
特定の初期の対話を終了するために初期の状態でさようならを送ることは違法ではありません。一部の発信者の意図を満たす可能性があります。ただし、初期の状態での別れまたはキャンセルの選択は慎重に行う必要があります。キャンセルは、目標がコールの試行を完全に放棄することである場合に適切です。別の早期ダイアログを放棄しながら、他の目的地で呼び出しを完了することを目標が目標である場合、さようならが適切です。さようならまたはキャンセルのいずれかを使用する場合、UACは、1つ以上の目的地に呼び出しがまだ確立される可能性について準備する必要があります。
UAC UAS
| |
The session has been already established
==========================
| re-INVITE F1 |
|--------------------->|
| BYE F2 |
|--------------------->|
| 200(BYE) F3 |
|<---------------------|
| INVITE 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のケースに似ている可能性があります。しかし、それは人種の状態ではありません。このケースは、何らかの理由で招待に応答しない場合の動作について説明します。付録は、この場合の行動とその根拠を説明しています。この場合は混乱を引き起こす可能性が高いためです。
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 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.)
まず、トランザクション層の動作とダイアログ層の動作を混同しないことが重要です。RFC 3261 [1]は、トランザクションレイヤーの動作を詳述しています。このドキュメントでは、ダイアログレイヤーの動作について説明します。同じSIPメッセージを送信または受信することにより、両方のレイヤーが状態を変更するようにトリガーされる場合でも、これらの2つの動作は互いに独立していることに注意する必要があります。（トランザクションがまだ残っていても、ダイアログを終了することができ、逆も同様です。）
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への応答はなく、F2（BYE）がF1の直後に送信されます。（F1はミッドダイアログリクエストです。F1がINIインバイトである場合、UACがタグを使用してリクエストに対する暫定的な応答を受け取る前に、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 | |
| |
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の場合、招待クライアントトランザクションはF1が送信されます。UACは、F1の直後にさようなら（F2）を送信します。これは正当な行動です。（通常、各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クライアントトランザクションをトリガーします。同時に、ダイアログ状態は致命的な状態に移行し、次にさようならまたはさようならへの応答のみを処理できます。
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の再送信はトランザクションレイヤーによって処理され、招待取引はまだ終了状態に移行していないため、致命的な状態でF4（招待の再送信）を送信することが許可されています。上記のように、ダイアログとトランザクションは互いに独立して動作します。したがって、ダイアログが終了した状態に移動したにもかかわらず、トランザクション処理を継続する必要があります。
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は、Re-InviteトランザクションF1が完了するまで、Bye F2の送信を遅らせることができます。実装者は、UAがこのように振る舞うことができるように、プロトコルのアクション（Bye F2の送信）からユーザーのアクション（たとえばハングアップ）を切り離すことができます。この場合、それはどのくらい待つかについての実装者の選択です。ほとんどの場合、このような実装は、このケースを防ぐのに役立つかもしれません。このドキュメントは、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
| |
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 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の場合、パケットF1が失われたり遅延したりすると考えることができます（ここでは、UASがF1を招待する前にF2 Byeを受信する場合、動作は説明されています）。したがって、F2はUASのByeトランザクションをトリガーし、同時にダイアログが致命的な状態に移動します。次に、F4を受信すると、Invite Serverトランザクションが開始されます。（致命的な状態で招待サーバートランザクションを開始することは許可されています。InviteServerトランザクションは、ダイアログ状態に関係なく受信したSIP要求の処理を開始します。）UASのTUは、F4 Invite 481の適切なエラー応答を送信します（なぜならTUは、招待と一致するダイアログが終端状態にあることを知っています）または500（再シェントF4には順序外のCSEQがあるため）。（招待されたメッセージF4（およびF1）はミッドダイアログリクエストであることが上記で言及されています。ミッドダイアログリクエストにはタグがあります。UASのTUは、招待状の受信時に新しいダイアログを開始しないことに注意する必要があります。タグに。）
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.
このセクションでは、初期状態のダイアログ状態遷移に間接的に影響するキャンセル動作について説明します。キャンセルは、UACのダイアログ状態に影響を与えません。ただし、リクエストは、INIインバイトに大きな影響を与えるため、ダイアログ状態の遷移に間接的な影響を及ぼします。UASの場合、キャンセル要求は、487の応答を送信するトリガーになる可能性があるため、UACによるキャンセルの送信よりもダイアログに直接的な影響を与えます。図3は、初期状態での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）送信を意味します。キャンセルのダイアログ状態はありませんが、ここでは、キャンセルされた状態は、CANCELを送信および受信したときにUAの動作を容易に理解するためだけに処理されます。
+-------------+
| Preparative |---+
+-------------+ |
: | 1xx(s) |
: V |
: +-------+ | 2xx(s)
: | Early |-----+------+
: +-------+ |
: : V
: : +-----------+
: : | Confirmed |<...
:.....: +-----------+ :
: | : :
: BYE(r)| : :
: CANCEL(r) | :.......:
V | CANCEL(r)
............. |
: Cancelled : |
:...........: |
| 487(s) |
| |
+--------------------+
|
V
+------------+
| Terminated |
+------------+
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が初期状態でキャンセルを受け取るときです。この場合、UASはすぐに招待のために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.)
もう1つは、確認された状態でUASがキャンセルを受け取る場合です。この場合、UASがキャンセルがターゲットにされる招待に最終的な応答をすでに送信しているため、ダイアログ状態の遷移は発生しません。（UACの行動のため、確認された状態でキャンセルを受け取るUASは、すぐにさようならを受け取り、終了状態に移動することを期待できることに注意してください。ただし、UASの状態は実際にさようならを受け取るまで移行しません。）
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].
このセクションでは、致命的な状態でのUAの行動について説明します。すべてのトランザクションは、RFC 3261 [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.)
致命的な状態では、Byeのみを受け入れることができ、Inviteダイアログ使用の他のメッセージはエラーで応答されます。ただし、ACKの送信とBYEの認証手順は、この状態で行われます。（複数のダイアログ使用に関するメッセージの処理は、このドキュメントの範囲外です。詳細については、RFC 5057 [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は、両方とも招待トランザクションの一部ですが、その取り扱いは異なります（セクション17.1.1.1、RFC 3261 [1]）。したがって、招待取引は、致命的な状態であっても、ACKを含む3方向の握手によって完了します。
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は、致命的な状態が終了するまで招待ダイアログの使用を維持する必要があります。そうすれば、致命的な状態で2xx応答のためにACKを送信できます。致命的な状態で招待する2xxが受信された場合、招待ダイアログの使用期間は2xxの受領から64*t1秒に延長され、2xxの再送信に対処します。（2xxの再送信の期間は64*T1なので、UAはこの期間の再送信を処理するために準備する必要があります。）ただし、UAは、致命的な状態での招待ダイアログの使用があるため、他のリクエストにエラー応答を送信するものとします。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認証手順は、致命的な状態で処理されます。401または407の応答によって認証が要求される場合、UACは適切な資格情報を使用してさようならを再送信します。また、UASは、認証を要求したさようならの再送信を処理します。
This section details the behavior of the TU when it receives multiple responses with different To tags to the ini-INVITE.
このセクションでは、INIインバイトのタグとは異なる複数の応答を受け取った場合の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, 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.
招待状がSIPネットワーク内でフォークされると、TUがタグとは異なるINIインバイトに対する複数の応答を受信する可能性があります（RFC 3261のセクション12.1、13.1、13.2.2.4、16.7、19.3などを参照してください。[1]）。TUがタグとは異なる複数の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の応答を受信した場合、自然に確認された状態に移行します。他の初期ダイアログではDSM状態の移行は発生しません。また、セッション（初期メディア）は終了します。UACのTUは、最初の2XX応答を受信する時点から64*T1秒後に招待トランザクションを終了します。さらに、確立された状態に移行しないすべての致命的な初期の対話は終了します（RFC 3261 [1]のセクション13.2.2.4を参照）。「致命的な初期の対話」とは、別の初期ダイアログが確認されたときに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.
以下は、タグとは異なる2つの180の応答が受信される例の例です。その後、初期ダイアログの1つ（ダイアログA）の200の応答が受信されます。シーケンス内の点線（..）は、ダイアログBへの影響を表す補助線です。
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) | |
| |
Figure 4: Receiving 1xx responses with different To tags
図4：タグとは異なる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を示しています。異なるタグ（F4 180（Tag = b））を使用した暫定的な応答の受信によってトリガーされ、DSMフォークと初期ダイアログBが生成されます。64*T1秒後、ダイアログAは200 OK応答を受け取ります。確立された状態に移行しないダイアログBは終了します。
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.) 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.
次に、タグとは異なる複数の2XX応答を受信するTUの動作について説明します。TUが受信した最初の2XX応答と一致しなかった致命的な早期ダイアログが、64*T1がトランザクションタイムアウトを招待する前にタグに一致する別の2XX応答を受け取ると、DSMは確認された状態に遷移します。ただし、TUが最初の2XXを受信してダイアログを確立するときに、Mortalの早期ダイアログに関するセッションは終了するため、Mortalの早期ダイアログのセッションは確立されていません。したがって、致命的な早期ダイアログが2XX応答を受信すると、TUはACKを送信し、すぐにTUはDSMを終了するためにさようならを送信します。（特別な場合、たとえば、UAが複数のダイアログを確立するつもりの場合、TUはさようならを送信できない場合があります。）最初のダイアログの200を受け取った後の2番目の初期ダイアログの処理は、典型的なデバイスに非常に適しています。電話。示されているのは典型的な有用なアクションであり、唯一の有効なアクションではないことに注意することが重要です。一部のデバイスは、物事を違った方法で処理したい場合があります。たとえば、Forksが取得したすべてのダイアログを受け入れて混合したい招待状を送信した会議の焦点。その場合、初期の対話は人間として扱われません。
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.
以下は、タグに対して異なる2つの180の応答を受信し、初期のダイアログのそれぞれに対して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 | |
| |
Figure 5: Receiving 1xx and 2xx responses with different To tags
図5：タグとは異なる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 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.)
以下は、TUが暫定的な応答がない場合に招待トランザクションの64*T1タイムアウトの前にタグとは異なる複数の200の応答を受信する場合の例です。TUは暫定的な応答を受け取っていませんが、TUは2XX応答を処理する必要があります（RFC 3261 [1]のセクション13.2.2.4を参照）。その場合、DSM状態は確認された状態に分岐し、Tuは2XX応答のACKを送信し、すぐにTUがBYEを送信します。（特別な場合、たとえば、UAが複数のダイアログを確立するつもりの場合、TUはさようならを送信しない場合があります。）
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 | |
| |
Figure 6: Receiving 2xx responses with different To tags
図6：タグとは異なる2xx応答を受信する
Below is an example sequence in which the option tag 100rel (RFC 3262 [5]) is required by a 180.
以下は、オプションタグ100REL（RFC 3262 [5]）がA 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.) 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).
フォーキングプロキシが100RELをサポートする場合、100RELの値を持つ必要性ヘッダーを含む暫定的な応答をUACに透過的に送信します。100レルで暫定的な応答を受信すると、UACは初期のダイアログ（b）を確立し、Prack（暫定的な応答承認）を送信します。（ここでも、すべてのトランザクションは他とは独立して完了します。）図4のように、初期のダイアログ（b）は同時に終了します。プロキシが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) | |
| |
Figure 7: Receiving 1xx responses with different To tags when using the mechanism for reliable provisional responses (100rel)
図7：信頼できる暫定応答のメカニズムを使用するときにタグとは異なる1xx応答を受信する（100rel）
Authors' Addresses
著者のアドレス
Miki Hasebe NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
Miki Hasebe ntt-east Corporation 19-2西shinjuku 3-Chome Shinjuku-ku、東京163-8019 JP
EMail: hasebe.miki@east.ntt.co.jp
Jun Koshiko NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
Jun Koshiko NTT-East Corporation 19-2 Nishi-Shinjuku 3-Chome Shinjuku-ku、東京163-8019 JP
EMail: j.koshiko@east.ntt.co.jp
Yasushi Suzuki NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 JP
Yasushi Suzuki NTT Corporation 9-11、Midori-Cho 3-Chome Musashino-Shi、Tokyo 180-8585 JP
EMail: suzuki.yasushi@lab.ntt.co.jp
Tomoyuki Yoshikawa NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
ヨシカワntt-east Corporation 19-2 Nishi-shinjuku 3-Chome Shinjuku-ku、東京163-8019 JP
EMail: tomoyuki.yoshikawa@east.ntt.co.jp
Paul H. Kyzivat Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 US
Paul H. Kyzivat Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA 01719 US
EMail: pkyzivat@cisco.com