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)
Status of This Memo
このメモのステータス
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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通信ネットワークの設計に開発されました。これらの例は、ダイアログの状態の遷移に由来競合状態のものである - 主にINVITEを送信した後、セッション確立中に遷移します。
When implementing SIP, various complex situations may arise. Therefore, it is helpful to provide implementors of the protocol with examples of recommended terminal and server behavior.
SIPを実装する場合、様々な複雑な状況が生じる可能性があります。したがって、推奨端末とサーバの動作の一例と、プロトコルの実装を提供するために有用です。
This document clarifies SIP User Agent (UA) behaviors when messages cross each other as race conditions. By clarifying the operation under race conditions, inconsistent interpretations between implementations are avoided and interoperability is expected to be promoted.
この文書では、メッセージは競合状態として互いに交差するSIPユーザエージェント（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]。
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].
これらのコールフローは、[1]、SDPを使用して、RFC 3264に記載されているように、RFC 3261で定義され、SIPのバージョン2.0に基づいている[2]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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のための輸送の問題の詳細については、[1] RFC 3261での議論を参照してください。
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.
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メソッド、ヘッダーおよびパラメータのベストプラクティスの使用法（順序、構文、目的のための機能の選択、またはエラーの扱い）です。注意：-であるように、追加の注釈は、説明を簡単にするため、この文書に組み込まれているので、この文書の流れが実装によってコピーされてはなりません。要約すると、このドキュメントで説明する手順は、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メッセージのいくつかの違いがいくつかあります。例えば、コール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
ユーザエージェントアリスのSIP：alice@atlanta.example.com 192.0.2.101ユーザエージェントボブのSIP：bob@biloxi.example.com 192.0.2.201ユーザエージェントキャロルのSIP：carol@chicago.example.com 192.0.2.202プロキシサーバー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の13-15 [1]（RFC 3261における用語の定義から多少異なっています）。 RFC 5057 [6]より正確に定義され、「ダイアログ使用を招待する」、別の用語を導入します。本明細書中で使用される用語「セッション」、「ダイアログの使用を招待する」という用語と同じほとんどではなく、かなり。 BYEが送信または受信されたときに、セッションは、以前に終了 - 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（ユーザエージェントサーバ）は、最初のINVITEに200 OKを送信することによって、確認状態に初期状態から遷移している間に（初期状態でキャンセル送信するときにたとえば、競合状態が発生します"INI-INVITE" 以下）として示されています。レースコンディションにUAの動作の理解を助けるために、以下のように、INVITEダイアログの使用のためのDSM（対話ステートマシン）が提示されます。
The DSM clarifies the UA's behavior by subdividing the dialog state shown in RFC 3261 [1] into various internal states. We call the state before the establishment of a dialog the Preparative state. The Confirmed state is subdivided into two substates, the Moratorium and the Established states, and the Terminated state is subdivided into the Mortal and Morgue states. Messages that are the triggers for the state transitions between these states are indicated with arrows. In this figure, messages that are not related to state transition are omitted.
DSMは、様々な内部状態にRFC [1] 3261に示すダイアログの状態を細分化することによってUAの動作を明確にしています。私たちは、ダイアログ取状態の確立前の状態を呼び出します。確認済みの状態は、二つのサブ状態、モラトリアムと設立された状態に細分化され、および終端状態は致命的と死体安置所の状態に分割されています。これらの状態間の状態遷移のトリガされたメッセージは、矢印で示されています。この図では、状態遷移に関連していないメッセージが省略されています。
Below are the DSMs, first for the caller and then for the callee.
以下は、最初の発信者のために、その後、呼び出し先のために、DSMをしています。
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：INVITEダイアログの使用（呼び出し側）のための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は、INVITEダイアログの使用のために、発信者のDSMを表します。呼び出し側は、この動作が推奨されていない場合でも、初期状態でBYEを送信することができます。初期状態で送信されたBYEは、タグ付けするには、特定のを使用して、早期ダイアログを終了します。これは、プロキシがフォークを行っているとき、BYEは特定のUAとの早期の対話を終了することができるだけである、です。呼び出し側が特定のUAでその代わりに、すべてのearlyダイアログを終了したい場合は、CANCELを送信する必要がなく、BYE。しかし、呼び出し側の意図であれば、特定の早期ダイアログを終了するために初期の状態でBYEを送信することは違法ではありません。呼び出し側が最終的な応答を受信して、INVITEトランザクションを終了するまで、また、呼び出し側は、それがすでにCANCELまたはBYE送信され、ダイアログを終了した場合でも、INVITEへの新たな応答を受信してダイアログを確立するために準備しなければなりません（付録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：INVITEダイアログの使用（呼び出し先）のためのDSM
Figure 2 represents the callee's DSM for the INVITE dialog usage. The figure does not illustrate the state transition related to CANCEL requests. A CANCEL request does not cause a dialog state transition. However, the callee terminates the dialog and triggers the dialog 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は、INVITEダイアログの使用のための呼び出し先のDSMを表します。図は、リクエストをキャンセルする関連状態遷移を示していません。 CANCELリクエストは、ダイアログの状態遷移が発生することはありません。ただし、呼び出し先は、ダイアログを終了し、CANCELを受信した直後に487を送信することにより、ダイアログの移行をトリガします。 CANCELリクエストを受信すると、この動作は、さらに、付録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.
取（PRE）：初期ダイアログがINI-INVITEが送信または受信された後にタグ付けすると、暫定応答を送信または受信することによって確立されるまで取状態が有効です。ダイアログには、まだ準備状態では存在しません。 UAは、準備状態から確認済み状態の準状態のあるモラトリアム状態に対話状態遷移、2xx応答を送信したり受信した場合。また、UAが送信または終了状態の副ある3XX-の6xxレスポンス、死体安置所の状態にダイアログ状態遷移を受信した場合。彼らはINVITEトランザクションによって送信されるための3xx-6xxの応答との3xx-6xxの再送信のためのACKを送信するのDSMには表示されません。
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の応答との3xx-6xxの再送信のためのACKを送信することは、このDSMには表示されません。 UACは初期状態でCANCELを送信することができます。 （それが推奨されていませんが）UACもBYEを送ることができます。 UASはの1xx-の6xx応答を送信することができます。送信またはCANCEL要求を受信すると、ダイアログの状態に直接影響を持っていません。 CANCELリクエストを受信すると、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要求を送信又は受信することによって。確認済みの状態は、二つのサブ状態、モラトリアムと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.
モラトリアム（モーラ）：猶予状態を確認状態のサブ状態であり、その動作を継承します。 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）設立：確立された状態を確認状態のサブ状態であり、その動作を継承します。呼び出し元と呼び出し先の両方がダイアログに影響を与える様々なメッセージを送ることができます。発信者は、INI-INVITEに対する2xx応答の再送にACKの送信をサポートします。
Terminated (Ter): The Terminated state is subdivided into two substates, the Mortal and Morgue states, to cover the behavior when a dialog is being terminated. In this state, the UA holds information about the dialog that is being terminated.
（テル）終了：終了状態は、ダイアログが終了しているときの動作をカバーするために、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.
致命（モート）：呼び出し元と呼び出し先は、BYEを送信または受信することによって、致命的状態に入ります。何のダイアログはありませんので、UAは、ダイアログ内の任意の新しい要求を送ってはいけません。 （ここでは、新しい要求はさらに以下の付録Dで説明した、401または407のために2xxのためのACKとBYEは含まれておりません。）モータル状態では、BYEを受け入れることができ、かつ、INVITEダイアログの使用の他のメッセージはに対応していますエラーと。これは、それが終了しているセッションに関する呼び出し元と呼び出し先交換レポートケースに対応しています。したがって、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.
遺体安置所（MORG）：ダイアログは、もはやこの状態で存在します。送信または実行されないダイアログに影響を与えるシグナリングの受信。 （ダイアログは文字通り終了します。）呼び出し元と呼び出し先が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 UAは、アリスとボブの間の競合状態を詳しく説明します。アリス（SIP：alice@atlanta.example.com）とボブ（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.
このセクションでは、しばらくモラトリアム状態で他州からのメッセージを受信したコールフローの競合条件のいくつかの例を示します。
3.1.1. Callee Receives Initial INVITE Retransmission (Preparative State) While in the Moratorium State
3.1.1. 呼び出し先は、初期INVITEの再送信（準備状態）モラトリアム状態の間を受け取ります
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].
このシナリオでは、UASが猶予状態にある間取メッセージを受信したときに発生する競合状態を示す図です。初期のすべての暫定応答は（F1をINI-INVITE）INVITE失われ、UACは、INI-INVITE（F4）を再送信します。この再送信と同時に、UASは、INI-INVITEに対する200 OK（F3）を生成し、INVITEサーバートランザクションを終了し、RFC 3261のセクション13.3.1.4によれば、[1]。
However, it is reported that terminating an INVITE server transaction when sending a 200 OK is an essential correction to SIP [7]. Therefore, the INVITE server transaction is not terminated by F3, and F4 MUST be handled properly as a retransmission.
しかし、[7] 200 OKを送信するときに、INVITEサーバートランザクションを終了すると、SIPに不可欠な補正であることが報告されています。したがって、INVITEサーバートランザクションは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.)
RFC 3261 [1]には、UASは、INI-INVITEの再送信200を再送信するか否かを指定されていません。 RFC 3261のセクション13.3.1.4によれば、タイマーによってトリガー200の再送（トランザクションユーザー（TU）は、それがACKを受信するまでT1およびT2に基づいて、200を再送し続ける）を考慮し[1]、200を再送信する必要と思われますUASは、INI-INVITEの再送信を受信したとき。 （200は問題にならないので、UASは、200の再送信を送信した場合、実装のために、それは問題ではありません。）
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
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アリス - >ボブ
3.1.2. Callee Receives CANCEL (Early State) While in the Moratorium State
3.1.2. 呼び出し先は、モラトリアム状態の間（初期状態）をキャンセル受け取ります
State Alice Bob State
| |
| INVITE F1 |
|----------------------------->|
Pre | 180 Ringing F2 | Pre
|<-----------------------------|
Ear | | Ear
|CANCEL F3 200(INVITE) F4|
|------------ -------------|
| \ / | Mora
| X |
| / \ |
|<----------- ------------>| *race*
Mora | |
| ACK F6 200(CANCEL) F5|
|------------ -------------|
Est | \ / |
| X |
| / \ |
|<----------- ------------>|
| | Est
| One Way RTP Media |
| (Two Way RTP Media possible) |
|<=============================|
| BYE F7 |
|----------------------------->|
Mort | 200 F8 | Mort
|<-----------------------------|
| ^ ^ |
| | Timer K | |
| V | |
Morg | Timer J | |
| V |
| | Morg
| |
This scenario illustrates the race condition that occurs when the UAS receives an Early message, CANCEL, while in the Moratorium state. Alice sends a CANCEL, and Bob sends a 200 OK response to the initial INVITE message at the same time. As described in the previous section, according to RFC 3261 [1], an INVITE server transaction is supposed to be terminated by a 200 response, but this has been corrected in [7].
このシナリオでは、猶予状態にある間UASは、初期メッセージ、CANCELを受信したときに発生する競合状態を示す図です。アリスは、CANCELを送信し、ボブは同時に初期INVITEメッセージに対する200 OK応答を送信します。前のセクションで説明したように、RFC 3261によれば、[1]、INVITEサーバートランザクションが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サーバートランザクションがINVITE要求に200応答によって終了されていない場合を説明します。この場合、INVITEトランザクションがCANCEL要求が一致するので、要求に200応答が送信されます。この200応答は、単にネクストホップがCANCEL要求（成功したが、（200）INVITEが実際にキャンセルされたという意味ではありませんCANCEL）を受け取ることを意味します。 UASは、補正に対処していない場合、[7]、UACは、リクエストマッチキャンセルトランザクションがないのでキャンセルする481応答を受信することができます。この481は、単にサーバートランザクションを招待キャンセルは次のホップに送信されていない一致が存在しないことを意味します。かかわらずキャンセルの成功/失敗の、アリスは、INVITEに対する最終応答をチェックし、彼女はすぐにBYEを送信し、ダイアログを終了INVITEリクエストに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がボブによって送信されるまで、ボブによって受信された時点から、メディアがボブからアリスへ一方向に流すことができます。答えは、ボブからアリスによって受信された時から、メディアが同様にアリスからボブに流すことができる可能性があります。アリスは呼び出しを中止することを決定しましたしかし、一度、彼女はおそらくので、実質的に一方通行のままになりますメディアストリームを言えば、メディアを送信しません。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
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（INVITE）ボブ - >アリス
/* 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（CANCEL）ボブ - >アリス
/* 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アリス - >ボブ
/* 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 BYEアリス - >ボブ
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、初期のメッセージを受信したときに発生する競合状態を示す図です。アリスは、初期状態でBYEを送信し、ボブは同時に初期INVITEリクエストに200 OKを送信します。アリスが初期状態に要求を送信したが、ボブが確認ダイアログ状態でBYEを受信する（第2節および付録Aで説明したように、この動作は推奨されません）。プロキシがフォークを実行している場合は、BYEは、特定のUAとの早期の対話を終了することができます。呼び出し側は、すべてのearlyダイアログの代わりに、それだけで特定のUAとを終了したい場合、それはBYE、CANCEL送信する必要がありません。しかし、それは、発信者の意図であれば、特定の早期ダイアログを終了するために初期の状態でBYEを送信することは違法ではありません。
The BYE functions normally even if it is received after the INVITE transaction termination because BYE differs from CANCEL, and is sent not to the request but to the dialog. Alice enters the Mortal state on sending the BYE request, and remains Mortal until the Timer K timeout occurs. In the Mortal state, the UAC does not establish a session even though it receives a 200 response to the INVITE. Even so, the UAC sends an ACK to 200 in order to complete the INVITE transaction. The ACK is always sent to complete the three-way handshake of the INVITE transaction (further explained in Appendix D below).
BYEは、CANCELと異なり、ない要求ではなく、ダイアログに送信されるため、通常、それはINVITEトランザクション終了後に受信されている場合でもBYE機能。アリスは、BYE要求を送信する上で致命的状態となり、タイマKタイムアウトが発生するまで遺骸。モータル状態では、UACは、それがINVITEへの200応答を受信したにもかかわらず、セッションを確立していません。そうであっても、UACは、INVITEトランザクションを完了するために200にACKを送信します。 ACKは常に（さらに下の付録Dで説明）INVITEトランザクションの3ウェイハンドシェイクを完了するために送信されます。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK (ini-INVITE) Bob -> Alice
F3 200 OK（この-INVITE）ボブ - >アリス
F4 BYE Alice -> Bob
F4 BYEアリス - >ボブ
/* 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（BYE）ボブ - >アリス
3.1.4. Callee Receives re-INVITE (Established State) While in the Moratorium State (Case 1)
3.1.4. 呼び出し先受け取り、再INVITE（ESTABLISHED状態）モラトリアム状態（ケース1）にいる間
State Alice Bob State
| |
| ini-INVITE w/offer1 F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| 200(ini-INV) w/answer1 F3 |
|<-------------------------------|
Mora | ACK F4(packet loss) | Mora
|-------------------->x |
Est | |
| re-INVITE F6 200 F5(=F3) |
| w/offer2 w/answer1 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->| *race*
| 200(re-INV) F8|
| ACK F7(=F4) w/answer2 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK (re-INV) F9 | Est
|------------------------------->|
| |
| |
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によって送ら-INVITE再を受信したときに発生する競合状態を示す図です。
The UAS receives a re-INVITE (with offer2) before receiving an ACK for the ini-INVITE (with offer1). The UAS sends a 200 OK (with answer2) to the re-INVITE (F8) because it has sent a 200 OK (with answer1) to the ini-INVITE (F3, F5) and the dialog has already been established. (Because F5 is a retransmission of F3, SDP negotiation is not performed here.)
UASは（offer1で）INIは、INVITEに対するACKを受信する前（offer2で）再INVITEを受信します。 UASは、INI-INVITE（F3、F5）に、それは（ANSWER1で）200 OKを送信したため、再INVITE（F8）に（ANSWER2付き）200 OKを送信し、ダイアログが既に確立されています。 （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応答でもクロスオーバーINVITE以外の場合には、密接にセッション確立に関係しているようです。この例では、セッションに影響を与えないので、200の代わりに491の送られることをお勧めします。応答のいずれかを使用することができますので、しかし、491応答も、同じ結果につながることができます。
Moreover, if the UAS doesn't receive an ACK for a long time, it should send a BYE and terminate the dialog. Note that ACK F7 has the same CSeq number as ini-INVITE F1 (see Section 13.2.2.4 of RFC 3261 [1]). The UA should not reject or drop the ACK on grounds of the CSeq number.
UASは、長い時間のためのACKを受信しない場合はさらに、それはBYEを送信し、ダイアログを終了する必要があります。 ACK F7は、INI-INVITE F1と同様のCSeq番号を持っていることに注意してください（[1] RFC 3261のセクション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.
注：実装上の問題は、この文書の範囲外であるが、以下のチップは、このタイプの競合状態を回避するために設けられています。発信者は、発信者が合理的にそのACKが受信されたと仮定することができ、その後、（おそらく、2秒）しばらくの間、再INVITE F6を送信遅延させることができます。 UAがこのように振る舞うことができるように、実装者は、プロトコルの動作から、ユーザ（例えば、保留ボタンを押す）（RE-INVITE F6の送信）の動作を切り離すことができます。この場合、実装者の選択が待機する時間のようです。ほとんどの場合、そのような実装は、このセクションに示す競合状態の種類を防止するために有用であり得ます。この文書では、彼らが配信されるACKを待つべきかどうかについての好みを表現していません。ユーザーエクスペリエンスへの影響を検討した後、実装者は、ユーザーエクスペリエンスが実装に依存しており、プロトコルの動作には直接関係がないので、しばらく待つかどうかを決定する必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
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
SIP INVITE：bob@biloxi.example.comをSIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9マックス・フォワード：アリス<SIP：alice@atlanta.exampleから70。コム>;、タグ= 9fxced76sl：ボブ<SIP：bob@biloxi.example.com>コールID：3848276298220188511@atlanta.example.comのCSeq：連絡先を1 INVITE：<SIP：alice@client.atlanta.example.com。輸送= UDP>のContent-Type：アプリケーション/ SDPコンテンツの長さ：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 0 =アリス2890844526 2890844526 IN IP4 client.atlanta.example.com S = - C = IP4 IN 192.0.2.101 T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000
/* 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
SIP / 2.0 180リンギングのVia：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9;から= 192.0.2.101を受信：アリス<SIP：alice@atlanta.example.com>;タグ= 9fxced76slに：ボブ<SIP：bob@biloxi.example.com>;タグは= 8321234356コールID：3848276298220188511@atlanta.example.comのCSeq：1連絡先をINVITE：<SIP：bob@client.biloxi.example.com;輸送= udpの>コンテンツの長さ：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
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9;から= 192.0.2.101を受け取っ：アリス<SIP：alice@atlanta.example.com>;タグ= 9fxced76slへ：ボブ<SIP：bob@biloxi.example.com>;タグは= 8321234356コールID：3848276298220188511@atlanta.example.comのCSeq：1連絡先をINVITE：<SIP：bob@client.biloxi.example.com;輸送= udpの>のContent-Type：アプリケーション/ SDPコンテンツの長さ：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 0 =ボブ2890844527 2890844527 IN IP4 client.biloxi.example.com S = - C = IP4 IN 192.0.2.201 T = 0、M =オーディオ3456 RTP / AVP 0 A = rtpmap：0 PCMU / 8000
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356
ACKのSIP：bob@client.biloxi.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8マックス転送しますから70：アリス<SIP：アリス@アトランタ。 example.com>;、タグ= 9fxced76sl：ボブ<SIP：bob@biloxi.example.com>;タグ= 8321234356
Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Length: 0
コールID：3848276298220188511@atlanta.example.comのCSeq：1個のACKのコンテンツの長さ：0
/* The ACK request is lost. */
F5(=F3) 200 OK Bob -> Alice (retransmission)
F5（= F3）200 OKボブ - >アリス（再送）
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
F6 re-INVITE Alice -> Bob
F6再INVITEアリス - >ボブ
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
70：アリス<SIP：SIP：bob@client.biloxi.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91マックス転送し、SIPのINVITEアリス@ atlanta.example.com>;タグ= 9fxced76slへ：ボブ<SIP：bob@biloxi.example.com>;タグは= 8321234356のCall-ID：3848276298220188511@atlanta.example.comのCSeq：147：コンテンツ長をINVITE 2
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 0 =アリス2890844526 2890844527 IN IP4 client.atlanta.example.com S = - C = IP4 IN 192.0.2.101 T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000 = sendonlyの
F7(=F4) ACK Alice -> Bob (retransmission)
F7（= F4）ACKアリス - >ボブ（再送）
/* "(=F4)" of ACK F7 shows that it is equivalent to F4 in that it is
an ACK for F3. This doesn't mean that F4 and F7 must be equal in
Via-branch value. Although it is ambiguous in RFC 3261 whether
the Via-branch of ACK F7 differs from that of F4, it doesn't
affect the UAS's behavior. */
F8 200 OK (re-INVITE) Bob -> Alice
F8 200 OK（再INVITE）ボブ - >アリス
SIP/2.0 200 OK Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Max-Forwards: 70
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91マックス・フォワード：70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Length: 143 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
投稿者：アリス<SIP：alice@atlanta.example.com>;タグ= 9fxced76slへ：ボブ<SIP：bob@biloxi.example.com>;タグ= 8321234356のCall-ID：3848276298220188511@atlanta.example.comのCSeq：2コンテンツ長をINVITE：143 V = 0 0 =ボブ2890844527 2890844528 IN IP4 client.biloxi.example.com S = - C = IP4 IN 192.0.2.201 T = 0、M =オーディオ3456 RTP / AVP 0 A = rtpmap：0 PCMU / 8000、A =がrecvonly
F9 ACK (re-INVITE) Alice -> Bob
F9 ACK（再INVITE）アリス - >ボブ
ACK sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 ACK Content-Length: 0
ACKのSIP：SIP：bob@client.biloxi.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK230f21マックス・フォワード：70から：アリス<SIP：アリス@ atlanta.example.com>;、タグ= 9fxced76sl：ボブ<SIP：bob@biloxi.example.com>;タグは= 8321234356のCall-ID：3848276298220188511@atlanta.example.comのCSeq：2 ACKのContent-Length：0
3.1.5. Callee Receives re-INVITE (Established State) While in the Moratorium State (Case 2)
3.1.5. 呼び出し先受け取り、再INVITE（ESTABLISHED状態）モラトリアム状態（ケース2）にいる間
State Alice Bob State
| |
| ini-INVITE (no offer) F1 |
|------------------------------->|
Pre | 180 F2 | Pre
|<-------------------------------|
Ear | | Ear
| 200(ini-INV) w/offer1 F3 |
|<-------------------------------|
Mora | ACK w/answer1 F4(packet loss) | Mora
|-------------------->x |
Est | |
| re-INVITE F6 200 F5(=F3) |
| w/offer2 w/offer1 |
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK F7(=F4) 491(re-INV) F8|
|------------- --------------|
| \ / |
| X |
| / \ |
|<------------ ------------->|
| ACK (re-INV) F9 | Est
|------------------------------->|
| |
| |
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）で提供し、再INVITE（F6）でオファーは互いに衝突します。
Bob sends a 491 to the re-INVITE (F6) since he is not able to properly handle a new request until he receives an answer. (Note: 500 with a Retry-After header may be returned if the 491 response is understood to indicate request collision. However, 491 is recommended here because 500 applies to so many cases that it is difficult to determine what the real problem was.) The same result will be reached if F6 is an UPDATE with offer.
彼は答えを受け取るまで適切に新しい要求を処理することができないので、ボブは再INVITE（F6）に491を送信します。 （注：491応答は、要求の衝突を示すものと理解されている場合に再試行後、ヘッダを返すことができると500は、本当の問題が何であったかを判断することが困難であるということなので、多くの場合に適用されるので、500ただし、491は、ここで推奨されています。） F6は、オファーをUPDATEであれば、同じ結果が到達されます。
Note: As noted in Section 3.1.4, the caller may delay sending a re-INVITE F6 for some period of time (2 seconds, perhaps), after which the caller may reasonably assume that its ACK has been received, to prevent this type of race condition. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
注：セクション3.1.4で述べたように、発信者が（おそらく、2秒）しばらくの間、再INVITE F6を送信遅らせることができ、発信者が合理的にこのタイプのを防ぐために、そのACKが受信されたと仮定することができる、その後競合状態の。この文書では、彼らが配信されるACKを待つべきかどうかについての好みを表現していません。ユーザーエクスペリエンスへの影響を検討した後、実装者は、ユーザーエクスペリエンスが実装に依存しており、プロトコルの動作には直接関係がないので、しばらく待つかどうかを決定する必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
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
SIP INVITE：bob@biloxi.example.comをSIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9マックス・フォワード：アリス<SIP：alice@atlanta.exampleから70。コム>;、タグ= 9fxced76sl：ボブ<SIP：bob@biloxi.example.com>コールID：3848276298220188511@atlanta.example.comのCSeq：連絡先を1 INVITE：<SIP：alice@client.atlanta.example.com。輸送= 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
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9;から= 192.0.2.101を受け取っ：アリス<SIP：alice@atlanta.example.com>;タグ= 9fxced76slへ：ボブ<SIP：bob@biloxi.example.com>;タグは= 8321234356コールID：3848276298220188511@atlanta.example.comのCSeq：1連絡先をINVITE：<SIP：bob@client.biloxi.example.com;輸送= udpの>のContent-Type：アプリケーション/ SDPコンテンツの長さ：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 0 =ボブ2890844527 2890844527 IN IP4 client.biloxi.example.com S = - C = IP4 IN 192.0.2.201 T = 0、M =オーディオ3456 RTP / AVP 0 A = rtpmap：0 PCMU / 8000
/* An offer is made in 200. */
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
ACK sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 ACK Content-Type: application/sdp Content-Length: 137
ACKのSIP：bob@client.biloxi.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd8マックス転送しますから70：アリス<SIP：アリス@アトランタ。 example.com>;、タグ= 9fxced76sl：ボブ<SIP：bob@biloxi.example.com>;タグ= 8321234356のCall-ID：3848276298220188511@atlanta.example.comのCSeq：1個のACKのContent-Type：アプリケーション/ SDPのContent長さ：137
v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 0 =アリス2890844526 2890844526 IN IP4 client.atlanta.example.com S = - C = IP4 IN 192.0.2.101 T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000
/* The request contains an answer, but the request is lost. */
F5(=F3) 200 OK Bob -> Alice (retransmission)
F5（= F3）200 OKボブ - >アリス（再送）
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
F6 re-INVITE Alice -> Bob
F6再INVITEアリス - >ボブ
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
70：アリス<SIP：SIP：bob@client.biloxi.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91マックス転送し、SIPのINVITEアリス@ atlanta.example.com>;タグ= 9fxced76slへ：ボブ<SIP：bob@biloxi.example.com>;タグは= 8321234356のCall-ID：3848276298220188511@atlanta.example.comのCSeq：147：コンテンツ長をINVITE 2
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 0 =アリス2890844526 2890844527 IN IP4 client.atlanta.example.com S = - C = IP4 IN 192.0.2.101 T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000 = sendonlyの
/* The request contains an offer. */
F7(=F4) ACK Alice -> Bob (retransmission)
F7（= F4）ACKアリス - >ボブ（再送）
/* A retransmission triggered by the reception of a retransmitted
200. "(=F4)" of ACK F7 shows that it is equivalent to the F4 in
that it is an ACK for F3. This doesn't mean that F4 and F7 are
necessarily equal in Via-branch value. Although it is ambiguous
in RFC 3261 whether the Via-branch of ACK F7 differs from that of
F4, it doesn't affect the UAS's behavior. */
F8 491 (re-INVITE) Bob -> Alice
F8 491（再INVITE）ボブ - >アリス
/* Bob sends 491 (Request Pending), since Bob has a pending
offer. */
F9 ACK (re-INVITE) Alice -> Bob
F9 ACK（再INVITE）アリス - >ボブ
3.1.6. Callee Receives BYE (Established State) While in the Moratorium State
3.1.6. 呼び出し先は、モラトリアム状態の間にBYE（国家を設立）を受信します
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.
このシナリオでは、UASが猶予状態にある間、BYE、設立メッセージを受信したときに発生する競合状態を示す図です。 200 OK応答のためのACK要求が失われた（または遅延）されます。ボブは、INI-INVITEに対するOK 200を再送信すると同時に、アリスは、BYE要求を送信し、セッションを終了します。再送された200 OKを受信すると、アリスのUAは、セッションを再確立するために傾斜させることがあります。しかし、それは間違っている - ダイアログがモータル状態にあるときに、セッションを再確立するべきではありません。 UASがBYEを受け取った後に再送されたACKを受信した場合また、UASが200 OKで提供を送信した場合に、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で述べたように、実装上の問題は、この文書の範囲外であるが、以下のチップは、このタイプの競合状態を回避するために設けられています。発信者は、発信者が合理的にそのACKが受信されたと仮定することができ、その後、（おそらく、2秒）ある期間BYE F6を送信遅延させることができます。 UAがこのように振る舞うことができるように、実装は、プロトコル（BYE F6の送信）の行動からユーザのアクション（例えば、ハングアップ）を切り離すことができます。この場合、実装者の選択が待機する時間のようです。ほとんどの場合、そのような実装は、このセクションに示す競合状態の種類を防止するために有用であり得ます。この文書では、彼らが配信されるACKを待つべきかどうかについての好みを表現していません。ユーザーエクスペリエンスへの影響を検討した後、実装者は、ユーザーエクスペリエンスが実装に依存しており、プロトコルの動作には直接関係がないので、しばらく待つかどうかを決定する必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
/* ACK request is lost. */
F5(=F3) 200 OK Bob -> Alice
F5（= F3）200 OKボブ - >アリス
/* The UAS retransmits a 200 OK to the ini-INVITE since it has not
received an ACK. */
F6 BYE Alice -> Bob
F6 BYEアリス - >ボブ
/* 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
F7（= F4）ACKアリス - >ボブ
/* "(=F4)" of ACK F7 shows that it is equivalent to the F4 in that it
is an ACK for F3. This doesn't mean that F4 and F7 must be equal
in Via-branch value. Although it is ambiguous in RFC 3261 whether
the Via-branch of ACK F7 differs from that of F4, it doesn't
affect the UAS's behavior. */
F8 200 OK (BYE) Bob -> Alice
F8 200 OK（BYE）ボブ - >アリス
/* 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を送ります。 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.)
ダイアログまたはセッション内で動作要求にモータル状態リターンエラー応答でのUA、このような再INVITEなど、UPDATE、または参照してください。しかし、UAは、それが終了しているときにBYEがセッションについての呼び出し元と呼び出し先交換レポート考慮ユースケースを取りにOK 200を返還しなければなりません。 （ダイアログ及びセッションの両方BYEが送信されるときに終了するので、200またはモルタル状態が得られた終端に影響を及ぼさないでいるので、この例では200を使用していてもしながら、BYEを受信すると、エラー応答を送信するの選択応答、他の応答も使用することができます。）
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
F5 BYE Alice -> Bob
F5 BYEアリス - >ボブ
/* 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 BYEボブ - >アリス
/* 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. */
3.2.2. UA Receives re-INVITE (Established State) While in the Mortal State
3.2.2. UAはモータル状態の間に、再INVITE（国家を設立）を受信します
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は、設立されたメッセージ、再INVITEを受信したときに発生する競合状態を示す図です。ボブは再INVITEを送信し、アリスは同時にBYEを送信します。再INVITEアリスのTUは、BYEを送信することによって設立された状態から致命的状態に移行したので、481応答を受信します。エラー応答のためのACKは、トランザクション層によって処理されると、481を受信した時点で、INVITEクライアントトランザクションがまだ（ダイアログが終了しているにもかかわらず）残っているので、ボブは481応答に対するACKを送信します。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
F5 BYE Alice -> Bob
F5 BYEアリス - >ボブ
/* Alice sends a BYE and terminates the session, and transitions from
the Established state to the Mortal state. */
F6 re-INVITE Bob -> Alice
F6再INVITEボブ - >アリス
/* 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（BYE）ボブ - >アリス
F8 481 Call/Transaction Does Not Exist (re-INVITE) Alice -> Bob
F8 481コール/トランザクションが存在しない（再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（再INVITE）ボブ - >アリス
/* ACK for an error response is handled by Bob's INVITE client
transaction. */
3.2.3. UA Receives 200 OK for re-INVITE (Established State) While in the Mortal State
3.2.3. UAはモータル状態の間に（国家を設立）再INVITE 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
|<======================>|
| |
| 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は致命的な状態にある間、再INVITEに設立メッセージ200を受信したときに発生する競合状態を示す図です。ボブは再INVITEを送信した直後にBYEを送信します。 （例えば、電話アプリケーションの場合には、それはユーザーがすぐにセッションをリフレッシュした後、電話をハングアップすることも可能です。）ボブは、INVITEトランザクションを完了し、モータル状態にある一方で、INVITE 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は再INVITEトランザクションF5が完了するまでBYE F6の送信を遅らせることができます。 UAがこのように振る舞うことができるように、実装は、プロトコル（BYE F6の送信）の行動からユーザのアクション（例えば、ハングアップ）を切り離すことができます。この場合、実装者の選択が待機する時間のようです。ほとんどの場合、そのような実装は、このセクションで説明競合状態の種類を防止するのに有用であり得ます。この文書では、彼らが配信されるACKを待つべきかどうかについての好みを表現していません。ユーザーエクスペリエンスへの影響を検討した後、実装者は、ユーザーエクスペリエンスが実装に依存しており、プロトコルの動作には直接関係がないので、しばらく待つかどうかを決定する必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
F5 re-INVITE Bob -> Alice
F5再INVITEボブ - >アリス
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
SIPのINVITE：alice@client.atlanta.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7セッションは、有効期限：300;補習= UACサポート：タイマーマックス・フォワードタグ= 8321234356へ：アリス<SIP：alice@atlanta.example.com>;;：ボブ<bob@biloxi.example.com SIP：>：70からタグ= 9fxced76slのCall-ID：3848276298220188511@atlanta.example.comのCSeq ：1のContent-LengthをINVITE：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 BYEボブ - >アリス
/* 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（再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
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bKnashd7; = 192.0.2.201が必要受け取っ：;：ボブ<SIP：ボブ：タイマーセッションは、有効期限から補習= UAC 300 @ biloxi.example.com>;タグ= 8321234356へ：アリス<SIP：alice@atlanta.example.com>;タグ= 9fxced76slコールID：3848276298220188511@atlanta.example.comのCSeq：コンテンツ長をINVITE 1：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（BYE）アリス - >ボブ
F9 ACK (re-INVITE) Bob -> Alice
F9 ACK（再INVITE）ボブ - >アリス
ACK sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44 Max-Forwards: 70 From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 ACK Content-Length: 0
ACKのSIP：alice@client.atlanta.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.biloxi.example.com:5060;branch=z9hG4bK74b44マックス・フォワード：70から：ボブ<SIP：ビロクシー@ボブ。 example.com>;、タグ= 8321234356：アリス<SIP：alice@atlanta.example.com>;タグ=コールIDを9fxced76sl：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は、200に設立されたメッセージ、ACKを受信したときに発生する競合状態を示す図です。アリスはACKを送信し、ボブは同時にBYEを送信します。オファーが2XXである、と答えがACKである場合には、競合状態があります。ボブはすでにBYEを送信することで、セッションを終了したので、ACKを受信したときにセッションが開始されません。 ACK要求で答えが単に無視されます。
Note: As noted in Section 3.1.4, implementation issues are outside the scope of this document, but the following tip is provided for avoiding race conditions of this type. Implementors can decouple the actions of the user (e.g., hanging up) from the actions of the protocol (the sending of BYE F5), so that the UA can behave like this. In this case, it is the implementor's choice as to how long to wait. In most cases, such an implementation may be useful in preventing the type of race condition described in this section. This document expresses no preference about whether or not they should wait for an ACK to be delivered. After considering the impact on user experience, implementors should decide whether or not to wait for a while, because the user experience depends on the implementation and has no direct bearing on protocol behavior.
注意：3.1.4で述べたように、実装上の問題は、この文書の範囲外であるが、以下のチップは、このタイプの競合状態を回避するために設けられています。 UAがこのように振る舞うことができるように、実装は、プロトコル（BYE F5の送信）の行動からユーザのアクション（例えば、ハングアップ）を切り離すことができます。この場合、実装者の選択が待機する時間のようです。ほとんどの場合、そのような実装は、このセクションで説明競合状態の種類を防止するのに有用であり得ます。この文書では、彼らが配信されるACKを待つべきかどうかについての好みを表現していません。ユーザーエクスペリエンスへの影響を検討した後、実装者は、ユーザーエクスペリエンスが実装に依存しており、プロトコルの動作には直接関係がないので、しばらく待つかどうかを決定する必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
/* RTP streams are established between Alice and Bob. */
F5 BYE Alice -> Bob
F5 BYEアリス - >ボブ
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のセクション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.
このシナリオでは、アリスとボブは同時に再のINVITEを送信します。 2再のINVITEは、同じダイアログで交差する場合、それらはRFC 3261のセクション14.1によると、異なる間隔の後にそれぞれ、再試行している[1]。アリスは再INVITEを送信すると、それはボブのと交差する場合、再INVITE彼女はコールIDを所有しているので、（彼女はそれを生成した）2.1から4.0秒後に再試行されます。ボブはボブがコール-IDの所有者ではないため、彼の、0.0から2.0秒後に再びINVITEを再試行します。
Therefore, each User Agent must remember whether or not it has generated the Call-ID of the dialog, in case an INVITE may cross with another INVITE.
そのため、各ユーザエージェントは、それが場合、ダイアログのコールIDを生成したかどうか覚えてAN別のINVITEと交差するINVITEをしなければなりません。
In this example, Alice's re-INVITE is for session modification and Bob's re-INVITE is for session refresh. In this case, after the 491 responses, Bob retries the re-INVITE for session refresh earlier than Alice. If Alice was to retry her re-INVITE (that is, if she was not the owner of Call-ID), the request would refresh and modify the session at the same time. Then Bob would know that he does not need to retry his re-INVITE to refresh the session.
この例では、アリスの再INVITEセッションの修正のためのものであり、ボブの再INVITEセッションリフレッシュのためです。この場合、491の応答の後、ボブはアリスより前のセッションのリフレッシュのために再INVITEを再試行します。アリスは（彼女がコール-IDの所有者ではなかった場合には、ある）彼女は再INVITEを再試行した場合、要求はリフレッシュと同時にセッションを変更します。その後、ボブは彼が彼のセッションをリフレッシュするために再INVITEを再試行する必要がないことを知っているだろう。
In another instance, where two re-INVITEs for session modification cross over, retrying the same re-INVITE again after a 491 by the Call-ID owner (the UA that retries its re-INVITE after the other UA) may result in unintended behavior, so the UA must decide if the retry of the re-INVITE is necessary. (For example, when a call hold and an addition of video media cross over, mere retry of the re-INVITE at the firing of the timer may result in the situation where the video is transmitted immediately after the holding of the audio. This behavior is probably not intended by the users.)
セッション変更のための2つの再のINVITEが交差別の例では、コールID所有者491（その他のUA後の再INVITEを再試行UA）が意図しない挙動をもたらすことができる後再試行が同じ再び再INVITE再INVITEの再試行が必要な場合は、そのUAが決定する必要があります。 （例えば、時にコール保留と映像メディアの添加が交差し、タイマーの焼成時の再INVITEの単なる再試行がビデオはすぐにオーディオの保持後に送信される状況になることがあります。この動作は、おそらく、ユーザーが意図していません。）
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
F5 re-INVITE Alice -> Bob
F5再INVITEアリス - >ボブ
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
70：アリス<SIP：SIP：bob@client.biloxi.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9マックス転送し、SIPのINVITEアリス@ atlanta.example.com>;タグ= 9fxced76slへ：ボブ<SIP：bob@biloxi.example.com>;タグは= 8321234356のCall-ID：3848276298220188511@atlanta.example.comのCSeq：147：コンテンツ長をINVITE 2
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 0 =アリス2890844526 2890844527 IN IP4 client.atlanta.example.com S = - C = IP4 IN 192.0.2.101 T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000 = sendonlyの
/* 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再INVITEボブ - >アリス
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
SIPのINVITE：alice@client.atlanta.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7セッションは、有効期限：300;補習= UACサポート：タイマーマックス・フォワードタグ= 8321234356へ：アリス<SIP：alice@atlanta.example.com>;;：ボブ<bob@biloxi.example.com SIP：>：70からタグ= 9fxced76slのCall-ID：3848276298220188511@atlanta.example.comのCSeq ：1のContent-LengthをINVITE：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（INVITE）アリス - >ボブ
F10 ACK (INVITE) Bob -> Alice
F10のACK（INVITE）ボブ - >アリス
F11 re-INVITE Bob -> Alice
F11再INVITEボブ - >アリス
INVITE sip:alice@client.atlanta.example.com SIP/2.0 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71
INVITE SIP：alice@client.atlanta.example.com SIP / 2.0経由：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
セッションは、有効期限：300;補習= UACサポート：タイマーマックス・フォワード：70から：ボブ<SIP：bob@biloxi.example.com>;タグ= 8321234356へ：アリス<SIP：alice@atlanta.example.com>。タグ= 9fxced76slコールID：3848276298220188511@atlanta.example.comのCSeq：アプリケーション/ SDPのContent-Length：コンテンツタイプをINVITE 2 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 0 =ボブ2890844527 2890844527 IN IP4 client.biloxi.example.com S = - C = IP4 IN 192.0.2.201 T = 0、M =オーディオ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ボブ - >アリス
F14 re-INVITE Alice -> Bob
F14再INVITEアリス - >ボブ
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
70：アリス<SIP：SIP：bob@client.biloxi.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91マックス転送し、SIPのINVITEアリス@ atlanta.example.com>;、タグ= 9fxced76sl：ボブ<SIP：bob@biloxi.example.com>;タグ= 8321234356のCall-ID：3848276298220188511@atlanta.example.comのCSeq：コンテンツ長をINVITE 3：147
v=0 o=alice 2890844526 2890844527 IN IP4 client.atlanta.example.com s=- c=IN IP4 192.0.2.101 t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 a=sendonly
V = 0 0 =アリス2890844526 2890844527 IN IP4 client.atlanta.example.com S = - C = IP4 IN 192.0.2.101 T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000 = sendonlyの
/* 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.
このシナリオでは、UPDATEは、SDPのオファーが含まれています。したがって、UPDATE、再INVITEは、両方の「再INVITEクロスオーバー」の場合のように491で応答しています。セッション記述を含み、互いに交差再INVITEないセッションリフレッシュ用UPDATEは、両方の要求は200で成功した場合（491 UAは、保留中の要求を有することを意味します）。同じことがUPDATEクロスオーバーのために真です。いずれかUPDATEがセッション記述を含む前者の場合、要求は、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はアリスをINVITE
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
F5 UPDATE Alice -> Bob
F5 UPDATEアリス - >ボブ
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 UPDATE Content-Length: 147
UPDATEのSIP：SIP：bob@client.biloxi.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf9マックス・フォワード：70から：アリス<SIP：アリス@ atlanta.example.com>;、タグ= 9fxced76sl：ボブ<SIP：bob@biloxi.example.com>;タグは= 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 0 =アリス2890844526 2890844527 IN IP4 client.atlanta.example.com S = - C = IP4 IN 192.0.2.101 T = 0、M =オーディオ49172 RTP / AVP 0 A = rtpmap：0 PCMU / 8000 = sendonlyの
/* Some detailed messages are shown for the sequence to illustrate
messages crossing over each other. */
F6 re-INVITE Bob -> Alice
F6再INVITEボブ - >アリス
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
SIPのINVITE：alice@client.atlanta.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd7セッションは、有効期限：300;補習= UACサポート：タイマーマックス・フォワードタグ= 8321234356へ：アリス<SIP：alice@atlanta.example.com>;;：ボブ<bob@biloxi.example.com SIP：>：70からタグ= 9fxced76slのCall-ID：3848276298220188511@atlanta.example.comのCSeq ：1 INVITE
Content-Type: application/sdp Content-Length: 133
コンテンツタイプ：アプリケーション/ SDPコンテンツの長さ：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 0 =ボブ2890844527 2890844527 IN IP4 client.biloxi.example.com S = - C = IP4 IN 192.0.2.201 T = 0、M =オーディオ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要求保留中（UPDATE）ボブ - >アリス
/* Since a re-INVITE is in process, a 491 response is returned. */
F8 491 Request Pending (re-INVITE) Alice -> Bob
保留F8 491要求（再INVITE）アリス - >ボブ
F9 ACK (re-INVITE) Alice -> Bob
F9 ACK（再INVITE）アリス - >ボブ
F10 re-INVITE Bob -> Alice
F10再INVITEボブ - >アリス
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
SIPのINVITE：alice@client.atlanta.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.biloxi.example.com:5060;branch=z9hG4bKnashd71セッションは、有効期限：300;補習= UACサポート：タイマーマックス・フォワード：70
From: Bob <sip:bob@biloxi.example.com>;tag=8321234356 To: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com CSeq: 2 INVITE Content-Type: application/sdp Content-Length: 133
タグ= 8321234356：アリス<SIP：alice@atlanta.example.com>;;：ボブ<bob@biloxi.example.com SIP：>からタグ=コールIDを9fxced76sl：3848276298220188511@atlanta.example.comのCSeq：2コンテンツタイプをINVITE：アプリケーション/ SDPコンテンツの長さ：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 0 =ボブ2890844527 2890844527 IN IP4 client.biloxi.example.com S = - C = IP4 IN 192.0.2.201 T = 0、M =オーディオ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ボブ - >アリス
F13 UPDATE Alice -> Bob
F13のUPDATEアリス - >ボブ
UPDATE sip:sip:bob@client.biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Bob <sip:bob@biloxi.example.com>;tag=8321234356 Call-ID: 3848276298220188511@atlanta.example.com CSeq: 3 UPDATE Content-Length: 147
UPDATEのSIP：SIP：bob@client.biloxi.example.com SIP / 2.0経由：SIP / 2.0 / UDP client.atlanta.example.com:5060;branch=z9hG4bK74bf91マックス・フォワード：70から：アリス<SIP：アリス@ atlanta.example.com>;、タグ= 9fxced76sl：ボブ<SIP：bob@biloxi.example.com>;タグは= 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が設立メッセージを受信したときに発生する競合状態、REFERを示します。ボブは、REFERを送信し、アリスは同時にBYEを送信します。ボブは同じダイアログでREFERを送信します。アリスの対話状態がBYE送信の時点で致命的な状態に移動します。致命的な状態では、UAは、内部処理のためのダイアログ情報を保有するが、ダイアログは外側に存在してはなりません。したがって、UAは、中間ダイアログ要求として送信される参照するためにエラー応答を送信します。だから、アリスは、モータル状態で、参照するためにエラー応答を送信します。しかし、ボブはすでにダイアログがINVITEダイアログ使用率がBYEを受信することにより終了していても、SUBSCRIBEの使用が終了するまで継続して、REFERと使用状況をSUBSCRIBE開始しました。この場合、ボブの行動は、[6] RFC 5057の手順に従ってくださいする必要があります。
Message Details
メッセージの詳細
F1 INVITE Alice -> Bob
>ボブ - F1はアリスをINVITE
F2 180 Ringing Bob -> Alice
F2 180リンギングボブ - >アリス
F3 200 OK Bob -> Alice
F3 200 OKボブ - >アリス
F4 ACK Alice -> Bob
F4 ACKアリス - >ボブ
F5 BYE Alice -> Bob
F5 BYEアリス - >ボブ
/* Alice sends a BYE request and terminates the session, and
transitions from the Confirmed state to the Terminated state. */
F6 REFER Bob -> Alice
>アリス - F6はボブをREFER
/* 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（BYE）ボブ - >アリス
F8 481 Call/Transaction Does Not Exist (REFER) Alice -> Bob
>ボブ - F8 481コール/トランザクション（REFER）アリス存在しません
/* 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.ポーク、ゴンサロ・カマリロ、健一大神、清水明宏、真由美宗像、保則稲垣、Tadaatsu城所、健一柊、デイル・ウォーリー、ビジェイK. Gurbani、とに感謝したいと思いますこのドキュメントの彼らのコメントのためのアンダース・クリステンセン。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[2]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 2002年6月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[4] 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]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[6] Sparks, R., "Multiple Dialog Usages in the Session Initiation Protocol", RFC 5057, November 2007.
[6]、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]、R.、「INVITE要求セッション開始プロトコルへの200の応答のため取り扱い正しい取引」、進歩、2008年7月に作業をスパークス。
Appendix A. BYE in the Early Dialog
初期ダイアログで付録A BYE
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.
BYEが早期ダイアログのBYEが混乱をトリガーした場合を示し、初期状態では推奨されない理由は、セクション3.1.3に関連するこのセクションでは、説明しています。
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送信にお勧めします。この例では、BYE要求が正常に進行し、それが正しくボブとの対話を終了することに成功しました。ボブがBYEを受信して、ダイアログを終了した後、彼はINI-INVITEに487を送信します。 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.
UASは、BYEを受信した後に保留中の要求に487を生成するための[1]、それをお勧めします。 INI-INVITEが保留状態にある間、彼はBYEを受けるので、この例では、ボブは、INI-INVITEに487を送信します。
However, Alice receives a final response to the INVITE (a 200 from Carol) even though she has successfully terminated the dialog with Bob. This means that, regardless of the success/failure of the BYE in the Early state, Alice MUST be prepared for the establishment of a new dialog until receiving the final response for the INVITE and terminating the INVITE transaction.
しかし、アリスはボブとの対話を終了し成功しているにもかかわらず、INVITEに対する最終応答（キャロルから200）を受信します。これは関係なく、初期状態ではBYEの成功/失敗の、アリスはINVITEのための最終的な応答を受信すると、INVITEトランザクションを終了するまで、新しいダイアログの確立のために準備しなければなりません、ということを意味します。
It is not illegal to send a BYE in the Early state to terminate a specific early dialog -- it may satisfy the intent of some callers. However, the choice of BYE or CANCEL in the Early state must be made carefully. CANCEL is appropriate when the goal is to abandon the call attempt entirely. BYE is appropriate when the goal is to abandon a particular early dialog while allowing the call to be completed with other destinations. When using either BYE or CANCEL, the UAC must be prepared for the possibility that a call may still be established to one or more destinations.
特定の早期ダイアログを終了するために初期の状態でBYEを送信することは違法ではありません - それはいくつかの発信者の意図を満たすようにしてもよいです。しかし、もしくはBYEの選択は慎重に行わなければならない初期の状態でキャンセル。 CANCEL目標は完全にコール試行を放棄するときに適しています。目標は、他の目的地で完了するために呼び出しを可能にしながら、特定の早期ダイアログを放棄するときBYEが適当です。 BYEまたはCANCELのいずれかを使用している場合、UACは、コールがまだ1つの以上の宛先に設定することができるという可能性のために準備する必要があります。
Appendix B. BYE Request Overlapping with re-INVITE
再INVITEと付録B. BYE要求重複
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のものと似て見ることができます。しかし、それは競合状態ではありません。何らかの理由で、INVITEに対する応答がない場合は、このケースでは動作について説明します。この場合は、混乱を引き起こす可能性があるので、付録には、このような場合、その根拠での動作を説明します。
First of all, it is important not to confuse the behavior of the transaction layer and that of the dialog layer. RFC 3261 [1] details the transaction layer behavior. The dialog layer behavior is 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-INVITEた場合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のために、INVITEクライアントトランザクションは、F1が送信された時点で開始されます。 UACは、すぐにF1の後にBYE（F2）を送信します。これは合法的な動作です。 （通常、各SIPメソッドの使用は、BYEなどのために、独立している。しかし、以前のオファーが進行している間SDPオファーとの要求を送信することが禁止されていることに留意すべきです。）
After that, F2 triggers the BYE client transaction. At the same time, the dialog state transitions to the Mortal state and then only a BYE or a response to a BYE can be handled.
その後、F2はBYEクライアントのトランザクションを開始します。そして、それと同時に、対話の状態遷移モータル状態にのみBYE 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の再送がトランザクション層によって処理され、そしてINVITEトランザクションがまだ終了状態に遷移していないので、致命的な状態でF4（INVITEの再送信）を送信することを許可されます。以上述べたように、ダイアログとトランザクションは互いに独立して動作します。そのため、トランザクション処理は、ダイアログが終了状態に移動しているにもかかわらず継続される必要があります。
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は再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がF2 BYEがF1 INVITEを前に受信した場合について説明します）。したがって、F2は、UASのためのBYEトランザクションをトリガし、致命的状態に同時にダイアログ移動します。その後、F4を受信すると、INVITEサーバートランザクションが開始されます。 （致命的な状態にINVITEサーバートランザクションを開始することが許可されています。サーバートランザクションをINVITEは、ダイアログ状態にかかわらず、受信したSIPリクエストを処理するために開始されます。）UASのTUは、F4のための適切なエラー応答がINVITEを送信、481（ので、どちらか再送信されたF4は、アウトオブオーダーのCSeqを持っているので、TU）は、（INVITEに一致する対話が終了した状態にあることを知っている）、または500。 （これは、そのINVITEメッセージF4（およびF1）の上に記載されては、ダイアログ中のリクエストです。ミッドダイアログ要求はタグ付けする必要があります。UASのTUがでINVITEを受信すると、新しいダイアログを開始していないことに留意すべきですタグを付けるには。）
Appendix C. UA's Behavior for CANCEL
CANCEL付録C. UAの挙動
This section explains the CANCEL behaviors that indirectly impact the dialog state transition in the Early state. CANCEL does not have any influence on the UAC's dialog state. However, the request has an indirect influence on the dialog state transition because it has a significant effect on ini-INVITE. For the UAS, the CANCEL request has more direct effects on the dialog than on the sending of a CANCEL by the UAC, because it can be a trigger to send the 487 response. Figure 3 explains the UAS's behavior in the Early state. This flow diagram is only an explanatory figure, and the actual dialog state transition is as illustrated in Figures 1 and 2.
このセクションでは、間接的に初期状態での対話状態遷移に影響を与えるCANCEL行動を説明しています。 UACのダイアログ状態に影響を与えないCANCEL。それはINI-INVITEに大きな影響を持っているのでしかし、要求が対話状態遷移に間接的な影響を与えています。 UASのために、CANCELリクエストは、487応答を送信するためのトリガできるため、UACによってCANCELを送るよりも、ダイアログ上のより直接的な効果を持っています。図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.
フローでは、実線は、ダイアログの状態遷移に関連し、そして点線はCANCELに関与しています。 （r）は、シグナリングの受信を表し、及び（S）の送信を意味します。そこCANCELのための対話状態はありませんが、ここでは、送信すると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のフロー図をCANCEL
There are two behaviors for the UAS depending on the state when it receives a CANCEL.
それは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が初期状態でCANCELを受信したときに最初の動作です。この場合、UASはすぐにINVITEのために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.)
他のUASが確認状態にCANCEL一方を受信する場合です。 UASが既にターゲティングされてキャンセルしたINVITEに対する最終応答を送信したため、この場合には、対話状態遷移は発生しません。 （理由はUACの動作、すぐにBYEを受信して終端状態に移行することを期待することができます確認済みの状態でCANCELを受信UASの、あることに注意してください。しかし、それは実際にBYEを受信するまでUASの状態が遷移しません。）
Appendix D. Notes on the Request in the Mortal State
モータル州の要求に付録D.の注意事項
This section describes the UA's behavior in the Mortal state, which needs careful attention. Note that every transaction completes independently of others, following the principle of RFC 3261 [1].
このセクションでは、細心の注意を必要とモータル状態の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のための認証手続きの送信はこの状態で行われています。 （複数ダイアログ用法に関するメッセージの処理は、この文書の範囲外である。[6]の詳細については、RFC 5057を参照します）。
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は、トランザクション層によって処理されるので、取り扱いには、ダイアログの状態とは関係ありません。 2XX応答のためのエラー応答のためのACK、ACKとは異なり、新たにTUによって生成された要求です。しかし、2XXのためのACK及びエラー応答のためのACKは、INVITEトランザクションの両方の一部であっても、その処理が異なる（セクション17.1.1.1、RFC 3261 [1]）。したがって、INVITEトランザクションがあっても致命的な状態で、ACKを含むスリーウェイハンドシェイクによって完成します。
Considering actual implementation, the UA needs to keep the INVITE dialog usage until the Mortal state finishes, so that it is able to send ACK for a 2xx response in the Mortal state. If a 2xx to INVITE is received in the Mortal state, the duration of the INVITE dialog usage will be extended to 64*T1 seconds after the receipt of the 2xx, to cope with the possible 2xx retransmission. (The duration of the 2xx retransmission is 64*T1, so the UA needs to be prepared to handle the retransmission for this duration.) However, the UA shall send an error response to other requests, since the INVITE dialog usage in the Mortal state is kept only for the sending of ACK for 2xx.
実際の実装を考慮すると、UAは、致命的な状態での2xx応答のためのACKを送信することができるように、モータル状態が終了するまで、INVITEダイアログの使用を維持する必要があります。 INVITEに対する2xxのはモータル状態で受信された場合、INVITEダイアログの使用の継続は可能なの2xx再送信に対応するため、2XXの受領後64 * T1秒に延長されます。 （2XX再送の持続時間は64 * T1であるので、UAは、この期間の再送を処理するために準備する必要がある。）モルタルの状態でダイアログ使用をINVITEしかしながら、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は、適切な資格情報でBYEを再送します。また、UASはそれが認証を要求したBYEの再送信を処理します。
Appendix E. Forking and Receiving New To Tags
付録E.フォークとタグへの新規の受信
This section details the behavior of the TU when it receives multiple responses with different To tags to the ini-INVITE.
このセクションでは、それは、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,
INVITEは、SIPネットワーク内部二股された場合、TUは、INI-INVITEタグに異なるとに複数の応答を受信する可能性がある（セクション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.
等、RFC 3261 [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.
複数の早期ダイアログの一つが、2xx応答を受信した場合、それが自然に確認ステートに移行します。いいえDSM状態遷移は、他の初期ダイアログ、およびそれらのセッション（初期メディア）終了のために発生しません。 UACのTUは、最初の2xx応答を受信した時点で開始し、64 * T1秒後にINVITEトランザクションを終了します。また、設立された状態に遷移していないすべての致命初期ダイアログを終了する（RFC 3261のセクション13.2.2.4 [1]を参照）。 「致命的な早めの対話」によって、我々は別の初期のダイアログが確認された場合にUAが終了することを任意の初期のダイアログを意味します。
Below is an example sequence in which two 180 responses with different To tags are received, and then a 200 response for one of the early dialogs (dialog A) is received. Dotted lines (..) in the sequences are auxiliary lines to represent the influence on dialog B.
以下のタグに異なる有する2つの180応答が受信されたシーケンス例であり、次いで、初期ダイアログ（ダイアログ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（= Bをタグに））、DSMフォークと初期ダイアログBが生成されます。 64 * T1秒後に、ダイアログAは200 OK応答を受け取ります。 ESTABLISHED状態に遷移しないダイアログ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.)
次に、タグに異なると、複数の2xx応答を受け取るTUの動作について説明します。 TUが受信した最初の2xx応答と一致しませんでした致命的な早めの対話が64 * T1は、トランザクションタイムアウトをINVITE前にタグ付けするにはそのと一致する別の2xx応答を受信すると、そのDSMが確認状態に移行します。しかし、TUがダイアログを確立するための最初の2xxを受信したときに致命的な早めのダイアログ上のセッションが終了したので、何のセッションは、致命的な早めの対話のために確立されていません。そのため、致命的な早めのダイアログが2xx応答を受信したとき、TUは直後に、TUは通常、DSMを終了するBYEを送信し、ACKを送信します。 （UAが複数のダイアログを確立しようとする場合、特殊なケースでは、例えば、TUは、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.
最初のダイアログ200を受信した後に第二の早期ダイアログの処理は、電話のように、典型的なデバイスのために非常に適切です。どのような表示されていることは、典型的な便利なアクションだけでなく、有効なものであることに注意することが重要です。一部のデバイスは違っを処理したい場合があります。例えば、フォークを受け入れ、それを取得すべてのダイアログをミックスしたいことがINVITEを送出した会議の焦点。その場合には、何の早期ダイアログは死ぬべきものとして扱われていません。
Below is an example sequence in which two 180 responses with a different To tag are received and then a 200 response for each of the early dialogs is received.
以下のタグに異なる有する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は暫定応答の非存在下で、INVITEトランザクションの64 * T1がタイムアウトする前にタグとは異なると複数の200の応答を受信した場合、例えば配列です。 TUは、暫定的な応答を受信しない場合でも、TUは2xx応答を処理する必要がある（RFC 3261のセクション13.2.2.4を参照[1]）。その場合には、DSMの状態を確認した状態でフォークされ、その後、TUは2xx応答のためにACKを送信し、直後、TUは通常BYEを送信します。 （UAが複数のダイアログを確立しようとする場合、特殊なケースでは、例えば、TUは、BYEを送信しなくてもよいです。）
UAC
dialog(A) | INVITE F1
Pre o |----------------------->
| | 100 F2
| |<-----------------------
| | 180(To tag=A) F3
Ear | |<-----------------------
| |
| | 200(A) F4
Mora |..........|<-----------------------
| ^ | ACK(A) F5
Est | | |----------------------->
| | |
dialog(B) | |64*T1 |
forked new DSM | | | 200(To tag=B) F6
Mora o..........|.|........|<-----------------------
| | | | ACK(B) F7
Est |..........|.|........|----------------------->
| | | | BYE(B) F8
Mort |..........|.|........|----------------------->
^ | | | | 200(B) F9
| | | | |<-----------------------
| | | V |
|Timer K | (terminate INVITE transaction)
| | | |
V | | |
Morg o | |
| |
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]）180によって必要とされている例のシーケンスです。
If a forking proxy supports 100rel, it transparently transmits to the UAC a provisional response that contains a Require header with the value of 100rel. Upon receiving a provisional response with 100rel, the UAC establishes the early dialog (B) and sends PRACK (Provisional Response Acknowledgement). (Here, also, every transaction completes independently of others.)
フォーキングプロキシが100relをサポートしている場合、それは透過UACに100relの値を持つRequireヘッダーが含まれている暫定的な応答を送信します。 100relとの暫定的な応答を受信すると、UACは、初期ダイアログ（B）を確立し、PRACK（暫定応答確認）を送信します。 （ここで、また、すべてのトランザクションは独立して、他の完了します。）
As in Figure 4, the early dialog (B) terminates at the same time the INVITE transaction terminates. In the case where a proxy does not support 100rel, the provisional response will be handled in the usual way (a provisional response with 100rel is discarded by the proxy, not to be transmitted to the UAC).
図4のように、早期のダイアログ（B）は、INVITEトランザクションが終了すると同時に終了します。プロキシが100relをサポートしていない場合には、暫定的な応答は、（100relとの暫定的な応答はUACに送信されるべきではない、プロキシによって破棄される）通常の方法で処理されます。
UAC
dialog(A) | INVITE F1
Pre o |------------------------->
| | 100 F2
| |<-------------------------
| | 180(To tag=A) F3
Ear | |<-------------------------
| | 200(A) F4
Mora |..........|<-------------------------
| ^ | ACK(A) F5
Est | | |------------------------->
dialog(B) | | |
forked new DSM | | | 180(To tag=B) w/100rel F6
Ear o..........|.|........|<-------------------------
| | | | PRACK(B) F7
| | | |------------------------->
| | | | 200(B,PRACK) F8
| | | |<-------------------------
| | |64*T1 |
| | |(13.2.2.4 of RFC 3261 [1])
| | | |
| | | |
| | | |
| | V |
o..........|.(terminate INVITE transaction)
terminated | |
dialog(B) | |
| |
Figure 7: Receiving 1xx responses with different To tags when using the mechanism for reliable provisional responses (100rel)
図7：信頼性の高い暫定応答（100rel）するためのメカニズムを使用するときにタグに異なるとの1xx応答を受信
Authors' Addresses
著者のアドレス
Miki Hasebe NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
みき はせべ んっｔーえあｓｔ こｒぽらちおん １９ー２ にしーしんじゅく ３ーちょめ しんじゅくーく、 ときょ １６３ー８０１９ ＪＰ
EMail: hasebe.miki@east.ntt.co.jp
メールアドレス：hasebe.miki@east.ntt.co.jp
Jun Koshiko NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
じゅん こしこ んっｔーえあｓｔ こｒぽらちおん １９ー２ にしーしんじゅく ３ーちょめ しんじゅくーく、 ときょ １６３ー８０１９ ＪＰ
EMail: j.koshiko@east.ntt.co.jp
メールアドレス：j.koshiko@east.ntt.co.jp
Yasushi Suzuki NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 JP
やすし すずき んっｔ こｒぽらちおん ９ー１１、 みどりーちょ ３ーちょめ むさしのーし、 ときょ １８０ー８５８５ ＪＰ
EMail: suzuki.yasushi@lab.ntt.co.jp
メールアドレス：suzuki.yasushi@lab.ntt.co.jp
Tomoyuki Yoshikawa NTT-east Corporation 19-2 Nishi-shinjuku 3-chome Shinjuku-ku, Tokyo 163-8019 JP
ともゆき よしかわ んっｔーえあｓｔ こｒぽらちおん １９ー２ にしーしんじゅく ３ーちょめ しんじゅくーく、 ときょ １６３ー８０１９ ＪＰ
EMail: tomoyuki.yoshikawa@east.ntt.co.jp
メールアドレス：tomoyuki.yoshikawa@east.ntt.co.jp
Paul H. Kyzivat Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 US
ポールH. Kyzivatシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719米国
EMail: pkyzivat@cisco.com
メールアドレス：pkyzivat@cisco.com