Internet Engineering Task Force (IETF) G. Camarillo, Ed.
Request for Comments: 6141 C. Holmberg
Updates: 3261 Ericsson
Category: Standards Track Y. Gao
ISSN: 2070-1721 ZTE
March 2011
Re-INVITE and Target-Refresh Request Handling
in the Session Initiation Protocol (SIP)
Abstract
抽象
The procedures for handling SIP re-INVITEs are described in RFC 3261. Implementation and deployment experience has uncovered a number of issues with the original documentation, and this document provides additional procedures that update the original specification to address those issues. In particular, this document defines in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, this document defines further details of procedures related to target-refresh requests.
再のINVITEがRFC 3261の実装と展開の経験で説明されているSIPを処理するための手順は、元の文書と多くの問題を明らかにした、そしてこの文書では、これらの問題に対処するために元の仕様を更新し、追加の手順を提供します。具体的には、この文書がどのような状況にUAS（ユーザエージェントサーバ）は成功応答を生成する必要がありますし、どのような状況にUASが再INVITEへのエラー応答を生成する必要が定義されています。また、この文書は要求リフレッシュをターゲットに関連する手順の詳細を定義します。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6141.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6141で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Changing the Session State during a Re-INVITE ...................5
3.1. Background on Re-INVITE Handling by UASs ...................5
3.2. Problems with Error Responses and Already Executed Changes .9
3.3. UAS Behavior ..............................................10
3.4. UAC Behavior ..............................................11
3.5. Glare Situations ..........................................11
3.6. Example of UAS Behavior ...................................12
3.7. Example of UAC Behavior ...................................14
3.8. Clarifications on Canceling Re-INVITEs ....................17
4. Refreshing a Dialog's Targets ..................................17
4.1. Background and Terminology on a Dialog's Targets ..........17
4.2. Background on Target-Refresh Requests .....................17
4.3. Clarification on the Atomicity of Target-Refresh Requests .18
4.4. UA Updating the Dialog's Local Target in a Request ........19
4.5. UA Updating the Dialog's Local Target in a Response .......19
4.6. A Request Updating the Dialog's Remote Target .............19
4.7. A Response Updating the Dialog's Remote Target ............20
4.8. Race Conditions and Target Refreshes ......................20
4.9. Early Dialogs .............................................21
5. A UA Losing Its Contact ........................................21
5.1. Background on Re-INVITE Transaction Routing ...............22
5.2. Problems with UAs Losing Their Contact ....................22
5.3. UAS Losing Its Contact: UAC Behavior ......................22
5.4. UAC Losing Its Contact: UAS Behavior ......................23
5.5. UAC Losing Its Contact: UAC Behavior ......................24
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................25
As discussed in Section 14 of RFC 3261 [RFC3261], an INVITE request sent within an existing dialog is known as a re-INVITE. A re-INVITE is used to modify session parameters, dialog parameters, or both. That is, a single re-INVITE can change both the parameters of its associated session (e.g., changing the IP address where a media stream is received) and the parameters of its associated dialog (e.g., changing the remote target of the dialog). A re-INVITE can change the remote target of a dialog because it is a target refresh request, as defined in Section 6 of RFC 3261 [RFC3261].
RFC 3261 [RFC3261]のセクション14で説明したように、既存のダイアログ内で送信されたINVITE要求は、再INVITEとして知られています。再INVITEセッションパラメータ、ダイアログのパラメータ、またはその両方を変更するために使用されます。すなわち、単一の再INVITEその関連するセッションのパラメータの両方を変更することができる（例えば、メディア・ストリームが受信されたIPアドレスの変更）とその関連するダイアログのパラメータ（例えば、ダイアログのリモートターゲットを変更します）。再INVITE RFC 3261のセクション6 [RFC3261]で定義されるように、それは、ターゲットリフレッシュ要求であるため、ダイアログのリモートターゲットを変更することができます。
A re-INVITE transaction has an offer/answer [RFC3264] exchange associated with it. The UAC (User Agent Client) generating a given re-INVITE can act as the offerer or as the answerer. A UAC willing to act as the offerer includes an offer in the re-INVITE. The UAS (User Agent Server) then provides an answer in a response to the re-INVITE. A UAC willing to act as answerer does not include an offer in the re-INVITE. The UAS then provides an offer in a response to the re-INVITE becoming, thus, the offerer.
再INVITEトランザクションは、それに関連付けられたオファー/アンサー[RFC3264]交流を持っています。 UAC（ユーザエージェントクライアント）を生成与えられた再INVITEオファー側として、または回答として機能することができます。オファー側は再INVITEで提供が含まれて行動するUAC喜んで。 UAS（ユーザエージェントサーバ）を再INVITEへの応答で答えを提供します。回答として機能して喜んでUACは再INVITEで提供が含まれていません。 UASは、その後、再INVITEなって、従って、オファーに応答してオファーを提供します。
Certain transactions within a re-INVITE (e.g., UPDATE [RFC3311] transactions) can also have offer/answer exchanges associated to them. A UA (User Agent) can act as the offerer or the answerer in any of these transactions regardless of whether the UA was the offerer or the answerer in the umbrella re-INVITE transaction.
再INVITE（例えば、UPDATE [RFC3311]トランザクション）内の特定の取引はまた、それらに関連したオファー/アンサー交換を有することができます。 UA（ユーザーエージェント）は、オファーかにかかわらず、UAは、オファーや傘の再INVITEトランザクションで回答したかどうかのこれらの取引のいずれかで回答として機能することができます。
There has been some confusion among implementors regarding how a UAS should handle re-INVITEs. In particular, implementors requested clarification on which type of response a UAS should generate in different situations. In this document, we clarify these issues.
UASが再招待処理する方法に関する実装の中でいくつかの混乱がありました。具体的には、実装は、UASは、様々な状況で発生するべき応答のタイプに明確化を要求しました。この文書では、我々は、これらの問題を明らかにする。
Additionally, there has also been some confusion among implementors regarding target refresh requests, which include but are not limited to re-INVITEs. In this document, we also clarify the process by which remote targets are refreshed.
また、も含むが、再のINVITEに限定されるものではなく、ターゲットリフレッシュ要求を、に関する実装の中でいくつかの混乱がありました。この文書では、我々はまた、リモートターゲットが更新される過程を明らかにする。
Indented passages such as this one are used in this document to provide additional information and clarifying text. They do not contain normative protocol behavior.
例えばこの一つとしてインデント通路は、付加情報と明確にテキストを提供するために、本書で使用されています。彼らは、規範的なプロトコルの動作を含んでいません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
UA: User Agent.
UA：ユーザエージェント。
UAC: User Agent Client.
UAC：ユーザエージェントクライアント。
UAS: User Agent Server.
WHO：ユーザエージェントサーバ。
Note that the terms UAC and UAS are used with respect to an INVITE or re-INVITE transaction and do not necessarily reflect the role of the UA concerned with respect to any other transaction, such as an UPDATE transaction occurring within the INVITE transaction.
用語はUACとUASは、INVITEまたは再INVITEトランザクションに関して使用されることに注意してください、必ずしもそのようなINVITEトランザクション内で発生する更新トランザクションのような任意の他のトランザクションに対する関係UAの役割を反映していません。
The following sub-sections discuss how to change the state of the session during a re-INVITE transaction.
以下のサブセクションでは、再INVITEトランザクション中のセッションの状態を変更する方法について説明します。
Eventually, a UAS receiving a re-INVITE will need to generate a response to it. Some re-INVITEs can be responded to immediately because their handling does not require user interaction (e.g., changing the IP address where a media stream is received). The handling of other re-INVITEs requires user interaction (e.g., adding a video stream to an audio-only session). Therefore, these re-INVITEs cannot be responded to immediately.
結局、再INVITEを受信UASはそれに対する応答を生成する必要があります。その取扱い（例えば、メディア・ストリームを受信したIPアドレスの変更）ユーザーの操作を必要としないため、一部の再のINVITEはすぐに対応することができます。他の再のINVITEの処理は、ユーザとの対話を必要とする（例えば、オーディオのみのセッションにビデオストリームを追加します）。したがって、これらの再のINVITEはすぐに対応することができません。
An error response to a re-INVITE has the following semantics. As specified in Section 12.2.2 of RFC 3261 [RFC3261], if a re-INVITE is rejected, no state changes are performed. These state changes include state changes associated to the re-INVITE transaction and all other transactions within the re-INVITE (this section deals with changes to the session state; target refreshes are discussed in Section 4.2). That is, the session state is the same as before the re-INVITE was received. The example in Figure 1 illustrates this point.
再INVITEに対するエラー応答は以下の意味があります。 -INVITE再が拒否された場合、RFC 3261のセクション12.2.2 [RFC3261]で指定されるように、いかなる状態の変更は行われません。これらの状態の変化は、状態の再INVITEトランザクションに関連する変更、再INVITE内の他のすべてのトランザクションを（;ターゲットリフレッシュは、セクション4.2に記載されているこのセクションでは、セッション状態への変更を扱う）が挙げられます。つまり、セッション状態を再INVITEが受信された前と同じです。図1の例では、この点を示しています。
UAC UAS
UAC
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<-----------------(5) 4xx-------------------|
| |
|------------------(6) ACK------------------>|
| |
Figure 1: Rejection of a re-INVITE
図1の除去再INVITE
The UAs perform an offer/answer exchange to establish an audio-only session:
UAは音声のみのセッションを確立するためにオファー/アンサー交換を実行します。
SDP1:
m=audio 30000 RTP/AVP 0
SDP2: m=audio 31000 RTP/AVP 0
SDP2：M =オーディオ31000 RTP / AVP 0
At a later point, the UAC sends a re-INVITE (4) in order to add a video stream to the session.
後の時点で、UACはセッションにビデオストリームを追加するために再INVITE（4）を送信します。
SDP3:
m=audio 30000 RTP/AVP 0
m=video 30002 RTP/AVP 31
The UAS is configured to automatically reject video streams. Consequently, the UAS returns an error response (5). At that point, the session parameters in use are still those resulting from the initial offer/answer exchange, which are described by SDP1 and SDP2. That is, the session state is the same as before the re-INVITE was received.
UASは、自動的にビデオストリームを拒否するように構成されています。したがって、UASは、エラー応答（5）を返します。その時点で、使用中のセッションパラメータは、まだSDP1とSDP2によって記述されている最初のオファー/アンサー交換、から生じるものです。つまり、セッション状態を再INVITEが受信された前と同じです。
In the previous example, the UAS rejected all the changes requested in the re-INVITE by returning an error response. However, there are situations where a UAS wants to accept some but not all the changes requested in a re-INVITE. In these cases, the UAS generates a 200 (OK) response with a Session Description Protocol (SDP) indicating which changes were accepted and which were not. The example in Figure 2 illustrates this point.
前の例では、UASは、エラー応答を返すことにより再INVITEに要求されたすべての変更を拒否しました。しかし、UASは、INVITEの再に要求されたすべての変更一部を受け入れなくしたい状況があります。これらの場合において、UASは、変更が受け入れられなかったどのたかを示すセッション記述プロトコル（SDP）と200（OK）レスポンスを生成します。図2の例では、この点を示しています。
UAC UAS
UAC
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<------------(5) 200 OK SDP4----------------|
| |
|------------------(6) ACK------------------>|
| |
Figure 2: Automatic rejection of a video stream
図2：ビデオストリームの自動拒否
The UAs perform an offer/answer exchange to establish an audio-only session:
UAは音声のみのセッションを確立するためにオファー/アンサー交換を実行します。
SDP1:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1
SDP2: m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5
SDP2：M =オーディオIP4 192.0.2.5 IN 31000 RTP / AVP 0のC =
At a later point, the UAC moves to an access that provides a higher bandwidth. Therefore, the UAC sends a re-INVITE (4) in order to change the IP address where it receives the audio stream to its new IP address and add a video stream to the session.
後の時点で、UACは、より高い帯域幅を提供するアクセスに移動します。したがって、UACは、その新しいIPアドレスにオーディオストリームを受信して、セッションにビデオストリームを追加IPアドレスを変更するために再INVITE（4）を送信します。
SDP3:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.2
The UAS is automatically configured to reject video streams. However, the UAS needs to accept the change of the audio stream's remote IP address. Consequently, the UAS returns a 200 (OK) response and sets the port of the video stream to zero in its SDP.
UASは、自動的にビデオストリームを拒否するように構成されています。しかし、UASは、オーディオストリームのリモートIPアドレスの変更を受け入れる必要があります。したがって、UASは、200（OK）レスポンスを返し、そのSDPゼロにビデオストリームのポートを設定します。
SDP4:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
In the previous example, the UAS was configured to automatically reject the addition of video streams. The example in Figure 3 assumes that the UAS requires its user's input in order to accept or reject the addition of a video stream and uses reliable provisional responses [RFC3262] (PRACK transactions are not shown for clarity).
前の例では、UASは、自動的にビデオストリームの追加を拒否するように構成しました。図3の例では、UASは、ビデオストリームの追加を承認または拒否するために、そのユーザーの入力を必要とし、信頼性のある暫定応答[RFC3262]（PRACK取引を明確にするために図示されていない）を使用することを想定しています。
UAC UAS
UAC
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<----(5) 183 Session Progress SDP4----------|
| |
| |
|<------------(6) UPDATE SDP5----------------|
| |
|-------------(7) 200 OK SDP6--------------->|
| |
|<---------------(8) 200 OK------------------|
| |
|------------------(9) ACK------------------>|
| |
Figure 3: Manual rejection of a video stream by the user
図3：ユーザーによるビデオストリームのマニュアル拒否
Everything up to (4) is identical to the previous example. In (5), the UAS accepts the change of the audio stream's remote IP address but does not accept the video stream yet (it provides a null IP address instead of setting the stream to 'inactive' because inactive streams still need to exchange RTP Control Protocol (RTCP) traffic).
（4）までのすべては前の例と同じです。 （5）では、UASは、オーディオストリームのリモートIPアドレスの変更を受け入れますが、非アクティブストリームはまだRTPコントロールを交換する必要があるので、それは代わりに「非アクティブ」にストリームを設定するのヌルIPアドレスを提供します（まだビデオストリームを受け入れませんプロトコル（RTCP）トラフィック）。
SDP4:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
At a later point, the UAS's user rejects the addition of the video stream. Consequently, the UAS sends an UPDATE request (6) setting the port of the video stream to zero in its offer.
後の時点では、UASのユーザーは、ビデオストリームの追加を拒否します。したがって、UASは、そのオファーにゼロにビデオストリームのポートを設定するUPDATE要求（6）を送信します。
SDP5:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0
The UAC returns a 200 (OK) response (7) to the UPDATE with the following answer:
UACは、次の答えを更新するために、200（OK）応答（7）を返します：
SDP6:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.2
m=video 0 RTP/AVP 31
The UAS now returns a 200 (OK) response (8) to the re-INVITE.
UASは、現在再INVITEに対する200（OK）応答（8）を返します。
In all the previous examples, the UAC of the re-INVITE transaction was the offerer. Examples with UACs acting as the answerers would be similar.
以前のすべての例では、再INVITEトランザクションのUACは、オファーしました。回答として働く求めるUACとの例としては同様であろう。
Section 3.1 contains examples on how a UAS rejects all the changes requested in a re-INVITE without executing any of them by returning an error response (Figure 1), and how a UAS executes some of the changes requested in a re-INVITE and rejects some of them by returning a 2xx response (Figures 2 and 3). A UAS can accept and reject different sets of changes simultaneously (Figure 2) or at different times (Figure 3).
セクション3.1は、UASは、エラー応答（図1）を返すことによって、それらのいずれかを実行することなく、再INVITEに要求されたすべての変更を拒否し、そしてどのようにUASは、INVITE再で要求された変更の一部を実行し、拒否方法の例が含まれています2xx応答（図2及び3）を返すことによって、それらの一部。 UASは受け入れ、同時に変化（図2）の、または異なる時間（図3）での異なるセットを拒否することができます。
The scenario that created confusion among implementors consists of a UAS that receives a re-INVITE, executes some of the changes requested in it, and then wants to reject all those already executed changes and revert to the pre-re-INVITE state. Such a UAS may consider returning an error response to the re-INVITE (the message flow would be similar to the one in Figure 1), or using an UPDATE request to revert to the pre-re-INVITE state and then returning a 2xx response to the re-INVITE (the message flow would be similar to the one in Figure 3). This section explains the problems associated with returning an error response in these circumstances. In order to avoid these problems, the UAS should use the latter option (UPDATE request plus a 2xx response). Sections 3.3 and 3.4 contain the normative statements needed to avoid these problems.
実装者の間で混乱を作成したシナリオは、再INVITEを受信、それに要求された変更のいくつかを実行して、すべてのものをすでに実行して変更を拒否し、事前に再INVITE状態に戻したいUASで構成されています。そのようなUASは、再INVITE（メッセージ・フローは、図1のものと同様であろう）にエラー応答を返す、または事前の再INVITE状態に戻すために更新要求を使用し、その後2xx応答を返すことを検討してもよいです（メッセージ・フローは、図3のものと同様であろう）再INVITEへ。このセクションでは、これらの状況でエラー応答を返すことに関連する問題について説明します。これらの問題を回避するために、UASは、後者のオプション（UPDATE要求プラス2xx応答）を使用する必要があります。セクション3.3と3.4は、これらの問題を回避するために必要な規範的な文が含まれています。
The reason for not using an error response to undo already executed changes is that an error response to a re-INVITE for which changes have already been executed (e.g., as a result of UPDATE transactions or reliable provisional responses) is effectively requesting a change in the session state. However, the UAC has no means to reject that change if it is unable to execute them. That is, if the UAC is unable to revert to the pre-re-INVITE state, it will not be able to communicate this fact to the UAS.
既に実行された変更を元に戻すためにエラー応答を使用しない理由は、にエラー応答変更が既に（例えば、更新トランザクションまたは信頼できる暫定的な応答の結果として）効果的に変化を要求して実行されたために再INVITEことですセッション状態。しかし、UACはそれらを実行することができない場合は、その変更を拒絶する手段を持ちません。 UACは、事前に再INVITE状態に戻すことができない場合には、ある、UASにこの事実を通信することができません。
UASs should only return an error response to a re-INVITE if no changes to the session state have been executed since the re-INVITE was received. Such an error response indicates that no changes have been executed as a result of the re-INVITE or any other transaction within it.
セッション状態への変更は再INVITEを受信してから実行されていない場合のUASにのみ再INVITEへのエラー応答を返す必要があります。そのようなエラー応答には変化がその中に-INVITE再または任意の他のトランザクションの結果として実行されていないことを示しています。
If any of the changes requested in a re-INVITE or in any transaction within it have already been executed, the UAS SHOULD return a 2xx response.
再INVITEまたはその中の任意のトランザクションで要求された変更のいずれかが既に実行されている場合、UASは2xx応答を返すべきです。
A change to the session state is considered to have been executed if an offer/answer without preconditions [RFC4032] for the stream has completed successfully or the UA has sent or received media using the new parameters. Connection establishment messages (e.g., TCP SYN), connectivity checks (e.g., when using Interactive Connectivity Establishment (ICE) [RFC5245]), and any other messages used in the process of meeting the preconditions for a stream are not considered media.
セッション状態への変更は、ストリームのための前提条件[RFC4032]なしオファー/アンサーが正常に完了した場合に実行されたと考えられているか、UAは、新しいパラメータを使用してメディアを送信または受信しています。接続確立メッセージ（例えば、TCP SYN）、接続性チェック（例えば、インタラクティブ接続確立（ICE）[RFC5245]を使用して）、およびストリームのための前提条件を満たすの方法において使用される他の任意のメッセージをメディア考慮されません。
Normally, a UA receiving media can easily detect when the new parameters for the media stream are used (e.g., media is received on a new port). However, in some scenarios, the UA will have to process incoming media packets in order to detect whether they use the old or new parameters.
メディアストリームのための新たなパラメータが使用される場合、通常、UA受信メディアを容易に検出することができる（例えば、メディアが新しいポートで受信されます）。しかし、いくつかのシナリオでは、UAは、彼らが古いか新しいパラメータを使用するかどうかを検出するためには、着信メディアパケットを処理する必要があります。
The successful completion of an offer/answer exchange without preconditions indicates that the new parameters for the media stream are already considered to be in use. The successful completion of an offer/answer exchange with preconditions means something different. The fact that all mandatory preconditions for the stream are met indicates that the new parameters for the media stream are ready to be used. However, they will not actually be used until the UAS decides to use them. During a session establishment, the UAS can wait before using the media parameters until the callee starts being alerted or until the callee accepts the session. During a session modification, the UAS can wait until its user accepts the changes to the session. When dealing with streams where the UAS sends media more or less continuously, the UAC notices that the new parameters are in use because the UAC receives media that uses the new parameters. However, this mechanism does not work with other types of streams. Therefore, it is RECOMMENDED that when a UAS decides to start using the new parameters for a stream for which all mandatory preconditions have been met, the UAS either sends media using the new parameters or sends a new offer where the precondition-related attributes for the stream have been removed. As indicated above, the successful completion of an offer/answer exchange without preconditions indicates that the new parameters for the media stream are already considered to be in use.
前提条件なしのオファー/アンサー交換が正常に完了は、メディアストリームのための新しいパラメータがすでに使用中であると考えられていることを示しています。前提条件とオファー/アンサー交換が正常に完了は別の何かを意味します。ストリームのすべての必須の前提条件が満たされているという事実は、メディアストリームのための新しいパラメータを使用する準備ができていることを示しています。 UASはそれらを使用することを決定したまでしかし、彼らは実際には使用されません。呼び出し先が警告されて開始されるまでまたは呼び出し先がセッションを受け入れるまで、セッション確立中に、UASはメディアパラメータを使用する前に待つことができます。そのユーザーがセッションへの変更を受け入れるまでのセッションの変更時には、UASは待つことができます。多かれ少なかれ連続UASはメディアを送信ストリームを扱う場合、UACは、UACは、新しいパラメータを使用してメディアを受け取るので、新しいパラメータが使用されていることに気づきます。しかし、このメカニズムは、ストリームの他のタイプでは動作しません。したがって、UASは、すべての必須の前提条件が満たされているため、ストリームのためのUASを新しいパラメータの使用を開始することを決定したいずれかの場合に、新しいパラメータを使用してメディアを送信したり、新しいプランを送信することを推奨された場合の前提条件関連の属性ストリームは削除されました。上記に示したように、前提条件なしのオファー/アンサー交換が正常に完了は、メディアストリームのための新しいパラメータがすでに使用中であると考えられていることを示しています。
A UAC that receives an error response to a re-INVITE that undoes already executed changes within the re-INVITE may be facing a legacy UAS that does not support this specification (i.e., a UAS that does not follow the guidelines in Section 3.3). There are also certain race condition situations that get both user agents out of synchronization. In order to cope with these race condition situations, a UAC that receives an error response to a re-INVITE for which changes have been already executed SHOULD generate a new re-INVITE or UPDATE request in order to make sure that both UAs have a common view of the state of the session (the UAC uses the criteria in Section 3.3 in order to decide whether or not changes have been executed for a particular stream). The purpose of this new offer/ answer exchange is to synchronize both UAs, not to request changes that the UAS may choose to reject. Therefore, session parameters in the offer/answer exchange SHOULD be as close to those in the pre-re-INVITE state as possible.
それが既に再INVITE内の変更は、本明細書（セクション3.3のガイドラインに従わない、すなわち、UAS）をサポートしないレガシーUASに対向することができる実行取り消し再INVITEに対するエラー応答を受信UAC。同期のうち、両方のユーザーエージェントを取得し、特定の競合状態の状況もあります。これらの競合状態の状況に対応するために、変更がすでに実行されているために再INVITEへのエラー応答を受け取るUACは、必ず両方のUAが共通に持っていることを確認するために、新たに再INVITEまたはUPDATE要求を生成する必要がありますセッションの状態を示す図（UACに変更が特定のストリームについて実行されたか否かを決定するために、セクション3.3で基準を使用します）。この新しいオファー/アンサー交換の目的は、両方のUAを同期させるためにUASが拒否することを選択する可能性のある変更を要求することはありません。したがって、オファー/アンサー交換でのセッションパラメータは、可能な限り事前に再INVITE状態のものの近くに配置してください。
Section 4 of RFC 3264 [RFC3264] defines glare conditions as a user agent receiving an offer after having sent one but before having received an answer to it. That section specifies rules to avoid glare situations in most cases. When, despite following those rules, a glare condition occurs (as a result of a race condition), it is handled as specified in Sections 14.1 and 14.2 of RFC 3261 [RFC3261]. The UAS returns a 491 (Request Pending) response and the UAC retries the offer after a randomly selected time, which depends on which user agent is the owner of the Call-ID of the dialog. The rules in RFC 3261 [RFC3261] not only cover collisions between re-INVITEs that contain offers, they cover collisions between two re-INVITEs in general, even if they do not contain offers. Sections 5.2 and 5.3 of RFC 3311 [RFC3311] extend those rules to also cover collisions between an UPDATE request carrying an offer and another message (UPDATE, PRACK, or INVITE) also carrying an offer.
RFC 3264 [RFC3264]のセクション4は、一を送信した後、それに対する回答を受信した前のオファーを受信するユーザエージェントとしてグレア条件を定義します。その節は、ほとんどの場合、グレア状況を回避するためのルールを指定します。 、それらの規則を以下にもかかわらず、グレア条件（競合状態の結果として）が発生したとき、セクション14.1及びRFCの14.2 3261 [RFC3261]で指定されるように、それが処理されます。 UASは491（リクエスト保留）応答を返し、UACダイアログのコールIDの所有者であるユーザエージェントに依存して、ランダムに選択された時間後に提供し、再試行します。彼らはオファーを含まない場合でも、RFC 3261 [RFC3261]の規則のみの提供が含まれている再のINVITE間の衝突をカバーしていないが、彼らは、一般的に2再のINVITE間の衝突をカバーしています。またオファーを運ぶセクション5.2およびRFC 3311の5.3 [RFC3311]もオファーを運ぶUPDATE要求と他のメッセージとの間の衝突をカバーするために、これらのルールを拡張（UPDATE、PRACK、またはINVITE）。
The rules in RFC 3261 [RFC3261] do not cover collisions between an UPDATE request and a non-2xx final response to a re-INVITE. Since both the UPDATE request and the reliable response could be requesting changes to the session state, it would not be clear which changes would need to be executed first. However, the procedures discussed in Section 3.4 already cover this type of situation. Therefore, there is no need to specify further rules here.
RFC 3261 [RFC3261]のルールはUPDATE要求と再INVITEに対する非2xxの最終的な応答の間の衝突をカバーしていません。 UPDATE要求と信頼性の高い応答の両方が、セッション状態への変更を要求することができますので、最初に実行する必要があると思われる変化は明らかではないでしょう。しかし、3.4節で説明した手順は、すでにこの種の状況をカバーしています。したがって、ここではさらにルールを指定する必要はありません。
This section contains an example of a UAS that implements this specification using an UPDATE request and a 2xx response to a re-INVITE in order to revert to the pre-re-INVITE state. The example shown in Figure 4 assumes that the UAS requires its user's input in order to accept or reject the addition of a video stream and uses reliable provisional responses [RFC3262] (PRACK transactions are not shown for clarity).
このセクションでは、UPDATE要求と前の再INVITE状態に戻すために、INVITE再への2xx応答を使用して、この仕様を実装UASの例を含んでいます。図4に示す例では、UASは、ビデオストリームの追加を承認または拒否するために、そのユーザーの入力を必要とし、信頼性のある暫定応答[RFC3262]（PRACK取引を明確にするために図示されていない）を使用することを想定しています。
UAC UAS
UAC
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<----(5) 183 Session Progress SDP4----------|
| |
|-------------(6) UPDATE SDP5--------------->|
| |
|<------------(7) 200 OK SDP6----------------|
| |
| |
|<------------(8) UPDATE SDP7----------------|
| |
|-------------(9) 200 OK SDP8--------------->|
| |
|<--------------(10) 200 OK------------------|
| |
|-----------------(11) ACK------------------>|
| |
Figure 4: Rejection of a video stream by the user
図4：ユーザによるビデオストリームの拒否
The UAs perform an offer/answer exchange to establish an audio-only session:
UAは音声のみのセッションを確立するためにオファー/アンサー交換を実行します。
SDP1:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1
SDP2: m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5
SDP2：M =オーディオIP4 192.0.2.5 IN 31000 RTP / AVP 0のC =
At a later point, the UAC sends a re-INVITE (4) in order to add a new codec to the audio stream and to add a video stream to the session.
後の時点で、UACは、オーディオストリームに新しいコーデックを追加すると、セッションにビデオストリームを追加するために再INVITE（4）を送信します。
SDP3:
m=audio 30000 RTP/AVP 0 3
c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1
In (5), the UAS accepts the addition of the audio codec but does not accept the video stream yet (it provides a null IP address instead of setting the stream to 'inactive' because inactive streams still need to exchange RTCP traffic).
（5）では、UASは、オーディオコーデックの追加を受け入れますが（非アクティブストリームはまだRTCPトラフィックを交換する必要があるので、それは代わりに「非アクティブ」にストリームを設定するのヌルIPアドレスを提供）まだビデオストリームを受け入れません。
SDP4:
m=audio 31000 RTP/AVP 0 3
c=IN IP4 192.0.2.5
m=video 31002 RTP/AVP 31
c=IN IP4 0.0.0.0
At a later point, the UAC sends an UPDATE request (6) to remove the original audio codec from the audio stream (the UAC could have also used the PRACK to (5) to request this change).
後の時点で、UACは、オーディオストリーム（UACこの変更を要求する（5）にPRACKをも使用していることができる）からオリジナルのオーディオコーデックを削除するUPDATE要求（6）を送信します。
SDP5:
m=audio 30000 RTP/AVP 3
c=IN IP4 192.0.2.1
m=video 30002 RTP/AVP 31
c=IN IP4 192.0.2.1
SDP6: m=audio 31000 RTP/AVP 3 c=IN IP4 192.0.2.5 m=video 31002 RTP/AVP 31 c=IN IP4 0.0.0.0
SDP6：IP4 0.0.0.0 IN M = IP4 192.0.2.5のmのオーディオ31000 RTP / AVP 3のC = =ビデオ31002 RTP / AVP 31のC =
Yet, at a later point, the UAS's user rejects the addition of the video stream. Additionally, the UAS decides to revert to the original audio codec. Consequently, the UAS sends an UPDATE request (8) setting the port of the video stream to zero and offering the original audio codec in its SDP.
しかし、後の時点で、UASのユーザーは、ビデオストリームの追加を拒否します。また、UASはオリジナルのオーディオコーデックに戻すことにしました。したがって、UASはUPDATE要求（8）がゼロにビデオストリームのポートを設定し、そのSDPにおける元のオーディオコーデックを提供して送信します。
SDP7:
m=audio 31000 RTP/AVP 0
c=IN IP4 192.0.2.5
m=video 0 RTP/AVP 31
c=IN IP4 0.0.0.0
The UAC accepts the change in the audio codec in its 200 (OK) response (9) to the UPDATE request.
UACはUPDATE要求への200（OK）応答（9）における音声コーデックの変更を受け付けます。
SDP8:
m=audio 30000 RTP/AVP 0
c=IN IP4 192.0.2.1
m=video 0 RTP/AVP 31
c=IN IP4 192.0.2.1
The UAS now returns a 200 (OK) response (10) to the re-INVITE. Note that the media state after this 200 (OK) response is the same as the pre-re-INVITE media state.
UASは、現在再INVITEに対する200（OK）応答（10）を返します。この200（OK）応答後のメディアの状態が予め再INVITEメディア状態と同じであることに留意されたいです。
Figure 5 shows an example of a race condition situation in which the UAs end up with different views of the state of the session.
図5は、UAは、セッションの状態の異なるビューで終わるた競合状態状況の一例を示しています。
a:sendrecv a:sendrecv v:inactive v:inactive
A：SENDRECV A：SENDRECV V：不活性なV：非アクティブ
UA1 Proxy UA2
UA1 UA2プロキシ
| | |
|----(1) INVITE SDP1-->| |
| |----(2) INVITE SDP1-->|
| | |
| |<----(3) 183 SDP2-----| a:sendrecv
a:sendrecv |<----(4) 183 SDP2-----| | v:recvonly
v:sendonly | | |
| |<------(5) 4xx -------|
| |-------(6) ACK ------>| a:sendrecv
| +-(7) 4xx -| | v:inactive
| | |<---(8) UPDATE SDP3---|
|<---(9) UPDATE SDP3---| |
| | | |
a:sendonly |---(10) 200 OK SDP4-->| |
v:inactive | | |---(11) 200 OK SDP4-->| a:recvonly
|<-(7) 4xx -+ | | v:inactive
a:sendrecv |------(12) ACK ------>| |
v:inactive | | |
a: status of the audio stream
v: status of the video stream
Figure 5: Message flow with race condition
図5：競合状態とメッセージフロー
The UAs in Figure 5 are involved in a session that, just before the message flows in the figures starts, includes a sendrecv audio stream and an inactive video stream. UA1 sends a re-INVITE (1) requesting to make the video stream sendrecv.
図5でのUAは、メッセージが図開始に流れる直前に、SENDRECV音声ストリームとインアクティブビデオストリームを含む、ことをセッションに関与しています。 UA1は、送信再INVITE（1）ビデオストリームのsendrecvを作るために要求します。
SDP1:
m=audio 20000 RTP/AVP 0
a=sendrecv
m=video 20002 RTP/AVP 31
a=sendrecv
UA2 is configured to automatically accept incoming video streams but to ask for user input before generating an outgoing video stream. Therefore, UAS2 makes the video stream recvonly by returning a 183 (Session Progress) response (2).
UA2は自動的に入ってくるビデオストリームを受け入れることが、送信ビデオストリームを生成する前にユーザーの入力を求めるように構成されています。したがって、UAS2 183（セッションプログレス）応答（2）を返すことによってビデオストリームがrecvonlyを行います。
SDP2:
m=audio 30000 RTP/AVP 0
a=sendrecv
m=video 30002 RTP/AVP 31
a=recvonly
When asked for input, UA2's user chooses not to have either incoming or outgoing video. In order to make the video stream inactive, UA2 returns a 4xx error response (5) to the re-INVITE. The ACK request (6) for this error response is generated by the proxy between both user agents. Note that this error response undoes already executed changes. So, UA2 is a legacy UA that does not support this specification.
入力を求められたら、UA2のユーザーは、着信または発信のいずれかのビデオを持ってしないことを選択しました。ビデオストリームを非アクティブにするために、UA2は再INVITEへの4xxエラー応答（5）を返します。このエラー応答に対するACK要求（6）は、両方のユーザエージェントとの間のプロキシによって生成されます。このエラー応答は、すでに変更を実行元に戻すことに注意してください。だから、UA2は、この仕様をサポートしていないレガシーUAです。
The proxy relays the 4xx response (7) towards UA1. However, the 4xx response (7) takes time to arrive to UA1 (e.g., the response may have been sent over UDP and the first few retransmissions were lost). In the meantime, UA2's user decides to put the audio stream on hold. UA2 sends an UPDATE request (8) making the audio stream recvonly. The video stream, which is inactive, is not modified and, thus, continues being inactive.
プロキシは、UA1に向けての4xx応答（7）を中継します。しかし、4XX応答（7）UA1（例えば、応答は、UDPを介して送信された可能性があり、最初のいくつかの再送信が失われた）に到達する時間を要します。一方で、UA2のユーザーは保留にオーディオストリームを置くことにしました。 UA2は（8）オーディオストリームがrecvonlyを作るUPDATE要求を送信します。不活性であるビデオストリームは、従って、不活性である続け、修正されず。
SDP3:
m=audio 30000 RTP/AVP 0
a=recvonly
m=video 30002 RTP/AVP 31
a=inactive
The proxy relays the UPDATE request (9) to UA1. The UPDATE request (9) arrives at UA1 before the 4xx response (7) that had been previously sent. UA1 accepts the changes in the UPDATE request and returns a 200 (OK) response (10) to it.
プロキシがUA1にUPDATE要求（9）を中継します。 UPDATE要求（9）は、以前に送られたの4xx応答（7）前UA1に到着します。 UA1はUPDATE要求の変化を受け入れ、それに200（OK）応答（10）を返します。
SDP4:
m=audio 20000 RTP/AVP 0
a=sendonly
m=video 30002 RTP/AVP 31
a=inactive
At a later point, the 4xx response (7) finally arrives at UA1. This response makes the session return to its pre-re-INVITE state. Therefore, for UA1, the audio stream is sendrecv and the video stream is inactive. However, for UA2, the audio stream is recvonly (the video stream is also inactive).
後の時点では、4xxの応答は、（7）最後にUA1に到着します。この応答は、その前の再INVITE状態にセッションリターンします。そのため、UA1のために、オーディオストリームはSENDRECVで、ビデオストリームは非アクティブです。しかし、UA2のために、オーディオストリームがあるがrecvonly（ビデオストリームは、非アクティブです）。
After the message flow in Figure 5, following the recommendations in this section, when UA1 received an error response (7) that undid already executed changes, UA1 would generate an UPDATE request with an SDP reflecting the pre-re-INVITE state (i.e., sendrecv audio and inactive video). UA2 could then return a 200 (OK) response to the UPDATE request making the audio stream recvonly, which is the state UA2's user had requested. Such an UPDATE transaction would get the UAs back into synchronization.
UA1は既に実行変更を元に戻したエラー応答（7）を受信すると、このセクションの推奨事項次の図5におけるメッセージフロー、後、UA1は、予め再INVITE状態（すなわち、反射SDPと更新要求を生成しますSENDRECVオーディオおよび非アクティブビデオ）。 UA2は、UA2のユーザーが要求していた状態であるがrecvonlyオーディオストリームを作るUPDATE要求、200（OK）応答を返すことができます。このような更新トランザクションは、同期に戻すのUAになるだろう。
Section 9.2 of RFC 3261 [RFC3261] specifies the behavior of a UAS responding to a CANCEL request. Such a UAS responds to the INVITE request with a 487 (Request Terminated) at the SHOULD level. Per the rules specified in Section 3.3, if the INVITE request was a re-INVITE and some of its requested changes had already been executed, the UAS would return a 2xx response instead.
RFC 3261のセクション9.2 [RFC3261]はCANCEL要求に応答UASの動作を指定します。そのようなUASはSHOULDレベル487（終端要求）でINVITE要求に応答します。 3.3節で指定されたルールに従って、INVITE要求が再INVITEであり、その要求された変更の一部が既に実行された場合、UASは、代わりに2xx応答を返します。
The following sections discuss how to refresh the targets of a dialog.
次のセクションでは、ダイアログのターゲットを更新する方法について説明します。
As described in Section 12 of RFC 3261 [RFC3261], a UA involved in a dialog keeps a record of the SIP or Session Initiation Protocol Secure (SIPS) URI at which it can communicate with a specific instance of its peer (this is called the "dialog's remote target URI" and is equal to the URI contained in the Contact header of requests and responses it receives from the peer). This document introduces the complementary concept of the "dialog's local target URI", defined as a UA's record of the SIP or SIPS URI at which the peer can communicate with it (equal to the URI contained in the Contact header of requests and responses it sends to the peer). These terms are complementary because the "dialog's remote target URI" according to one UA is the "dialog's local target URI" according to the other UA, and vice versa.
RFC 3261 [RFC3261]のセクション12に記載されているように、ダイアログに関与するUAは、SIPまたはセッション開始プロトコルセキュア（SIPS）URIがどのに、そのピアの特定のインスタンスと通信することができる（これは呼ばれるの記録を保持します「ダイアログのリモートターゲットURI」と要求し、それがピアから受信した応答）のContactヘッダに含まれるURIに等しいです。この文書では、ピアがそれと通信可能なSIPのUAの記録として定義された「ダイアログのローカルターゲットURI」の補完的な概念を導入またはURIをSIPS（URIに等しいが、要求と応答のContactヘッダに含まれる、送信しますピアへ）。これらの用語は、1 UAによる「ダイアログのリモートターゲットURI」ために相補的であることは、他のUAによる「ダイアログのローカルターゲットURI」であり、その逆。
A target-refresh request is defined as follows in Section 6 of RFC 3261 [RFC3261]:
RFC 3261 [RFC3261]のセクション6で次のようにターゲットリフレッシュ要求が定義されています。
A target-refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog.
ダイアログ内で送信ターゲットリフレッシュリクエストはダイアログのリモートターゲットを変更することができ、要求として定義されます。
Additionally, 2xx responses to target-refresh requests can also update the remote target of the dialog. As discussed in Section 12.2 of RFC 3261 [RFC3261], re-INVITEs are target-refresh requests.
また、2XX応答がターゲットリフレッシュする要求はまた、ダイアログのリモートターゲットを更新することができます。 RFC 3261 [RFC3261]のセクション12.2で説明したように、再度のINVITEは、ターゲットリフレッシュ要求です。
RFC 3261 [RFC3261] specifies the behavior of UASs receiving target-refresh requests and of UACs receiving a 2xx response for a target-refresh request.
RFC 3261 [RFC3261]は、ターゲットリフレッシュリクエスト受信し、求めるUACのターゲットリフレッシュ要求に対する2xx応答を受け取るのUASの動作を指定します。
Section 12.2.2 of RFC 3261 [RFC3261] says:
RFC 3261のセクション12.2.2 [RFC3261]は言います：
When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that request, if present.
UASがターゲットリフレッシュ要求を受信した場合に存在する場合、それは、その要求にContactヘッダーフィールドからURIを持つダイアログのリモートターゲットURIを交換する必要があります。
Section 12.2.1.2 of RFC 3261 [RFC3261] says:
RFC 3261のセクション12.2.1.2 [RFC3261]は言います：
When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present.
UACは、ターゲットリフレッシュリクエストに対する2xx応答を受信した場合に存在する場合、それは、その応答のContactヘッダーフィールドからURIをダイアログのリモートターゲットURIを交換する必要があります。
The fact that re-INVITEs can be long-lived transactions and can have other transactions within them makes it necessary to revise these rules. Section 4.3 specifies new rules for the handling of target-refresh requests. Note that the new rules apply to any target-refresh request, not only to re-INVITEs.
再のINVITEが長寿命取引することができ、その中に他のトランザクションを持つことができるという事実は、これらのルールを改訂することが必要になります。 4.3節では、ターゲットリフレッシュ要求の処理のための新しいルールを指定します。再のINVITEだけでなく、新しいルールは任意のターゲットリフレッシュ要求に適用されることに注意してください。
The local and remote targets of a dialog are special types of state information because of their essential role in the exchange of SIP messages between UAs in a dialog. A UA involved in a dialog receives the remote target of the dialog from the remote UA. The UA uses the received remote target to send SIP requests to the remote UA.
ダイアログのローカルおよびリモートのターゲットがあるため、ダイアログ内のUA間のSIPメッセージの交換で彼らの重要な役割の状態情報の特殊なタイプです。ダイアログに関与UAは、リモートUAからのダイアログのリモートターゲットを受け取ります。 UAは、リモートUAにSIPリクエストを送信するために受信したリモートターゲットを使用しています。
The dialog's local target is a piece of state information that is not meant to be negotiated. When a UA changes its local target (i.e., the UA changes its IP address), the UA simply communicates its new local target to the remote UA (e.g., the UA communicates its new IP address to the remote UA in order to remain reachable by the remote UA). UAs need to follow the behavior specified in Sections 4.4, 4.5, 4.6, and 4.7 of this specification instead of that specified in RFC 3261 [RFC3261], which was discussed in Section 4.2. The new behavior regarding target-refresh requests implies that a target-refresh request can, in some cases, update the remote target even if the request is responded to with a final error response. This means that target-refresh requests are not atomic.
ダイアログのローカルターゲットが交渉されることを意図していない状態情報の一部です。 UAは、そのローカルターゲットを変更した場合、UAは、単にリモートUAへの新しいローカルターゲットを（例えば、UAがで到達可能なままにするために、リモートUAへの新しいIPアドレスを伝達する通信（すなわち、UAは、そのIPアドレスを変更します）リモートUA）。 UAは、セクション4.4、4.5、4.6で指定された行動、その代わりにセクション4.2で議論されたRFC 3261 [RFC3261]で指定され、この明細書の4.7に従う必要があります。ターゲットリフレッシュリクエストに関する新行動は、ターゲットリフレッシュリクエストは、いくつかのケースでは、要求は、最終的なエラー応答を返信された場合でも、リモートターゲットを更新できることを意味します。これは、ターゲットリフレッシュ要求がアトミックではないことを意味します。
In order to update its local target, a UA can send a target-refresh request. If the UA receives an error response to the target-refresh request, the remote UA has not updated its remote target.
そのローカルターゲットを更新するためには、UAは、ターゲットリフレッシュリクエストを送信することができます。 UAがターゲットリフレッシュ要求に対するエラー応答を受信した場合、遠隔UAは、そのリモートターゲットを更新されていません。
This allows UASs to authenticate target-refresh requests (see Section 26.2 of RFC 3261 [RFC3261]).
これは、のUASは（RFC 3261のセクション26.2 [RFC3261]を参照）ターゲットリフレッシュ要求を認証することができます。
If the UA receives a reliable provisional response or a 2xx response to the target-refresh request, or the UA receives an in-dialog request on the new local target, the remote UA has updated its remote target. The UA can consider the target refresh operation completed.
UAは、信頼性のある暫定応答またはターゲットリフレッシュ要求に対する2xx応答を受け取るか、UAが新しいローカルターゲット上で、対話要求を受信した場合、遠隔UAは、そのリモート・ターゲットを更新しました。 UAが完了し、ターゲットリフレッシュ動作を考慮することができます。
Even if the target request was a re-INVITE and the final response to the re-INVITE was an error response, the UAS would not revert to the pre-re-INVITE remote target.
ターゲット要求があった場合でも、再INVITE、再INVITEたエラー応答に最終応答、UASは、予め-INVITE再リモートターゲットに戻すしないであろう。
A UA SHOULD NOT use the same target refresh request to refresh the target and to make session changes unless the session changes can be trivially accepted by the remote UA (e.g., an IP address change). Piggybacking a target refresh with more complicated session changes would make it unnecessarily complicated for the remote UA to accept the target refresh while rejecting the session changes. Only in case the target refresh request is a re-INVITE and the UAS supports reliable provisional response or UPDATE requests, the UAC MAY piggyback session changes and a target refresh in the same re-INVITE.
UAは、ターゲットを更新する、セッション変更が自明遠隔UA（例えば、IPアドレスの変更）によって受け入れできなければ、セッションを変更するために、同じターゲットリフレッシュ要求を使用しないでください。セッションの変更を排除しながら、リモートUAがターゲットリフレッシュを受け入れるようにするために、より複雑なセッションの変更とターゲットリフレッシュをピギーバックすることは、不必要に複雑になるだろう。のみの場合には、ターゲットリフレッシュ要求は再INVITEで、UASは、UACはセッションの変更と同じ再INVITEでターゲットリフレッシュを背負うかもしれない信頼性のある暫定応答またはUPDATE要求をサポートしています。
A UA processing an incoming target refresh request can update its local target by returning a reliable provisional response or a 2xx response to the target-refresh request. The response needs to contain the updated local target URI in its Contact header field. On sending the response, the UA can consider the target refresh operation completed.
UAは、信頼できる暫定的な応答またはターゲットリフレッシュ要求への2xx応答を返すことによって、そのローカルのターゲットを更新することができ、着信ターゲットリフレッシュ要求を処理します。応答は、そのContactヘッダーフィールドに更新されたローカルターゲットURIを含める必要があります。応答を送信するには、UAが完成し、ターゲットリフレッシュ動作を考慮することができます。
Behavior of a UA after having received a target-refresh request updating the remote target:
リモートターゲットを更新し、ターゲット・リフレッシュ要求を受けた後のUAの挙動：
If the UA receives a target-refresh request that has been properly authenticated (see Section 26.2 of RFC 3261 [RFC3261]), the UA SHOULD generate a reliable provisional response or a 2xx response to the target-refresh request. If generating such responses is not possible (e.g., the UA does not support reliable provisional responses and needs user input before generating a final response), the UA SHOULD send an in-dialog request to the remote UA using the new remote target (if the UA does not need to send a request for other reasons, the UAS can send an UPDATE request). On sending a reliable provisional response or a 2xx response to the target-refresh request, or a request to the new remote target, the UA MUST replace the dialog's remote target URI with the URI from the Contact header field in the target-refresh request.
UAは、（RFC 3261のセクション26.2 [RFC3261]を参照）が正しく認証されたターゲットリフレッシュ要求を受信した場合、UAは、信頼できる暫定的な応答またはターゲットリフレッシュ要求への2xx応答を生成する必要があります。そのような応答を生成する（例えば、UAが信頼できる暫定応答をサポートし、最終的な応答を生成する前にユーザー入力を必要としない）ことができない場合場合、UAは（新しいリモートターゲットを使用してリモートUAに-対話要求を送信すべきですUAは、UAS）はUPDATEリクエストを送信することができ、他の理由のために要求を送信する必要はありません。信頼性のある暫定応答またはターゲットリフレッシュ要求、または新規リモートターゲットへの要求に対する2xx応答を送信するには、UAは、ターゲットリフレッシュ要求にContactヘッダーフィールドからURIを持つダイアログのリモートターゲットURIを交換する必要があります。
Reliable provisional responses in SIP are specified in RFC 3262 [RFC3262]. In this document, reliable provisional responses are those that use the mechanism defined in RFC 3262 [RFC3262]. Other specifications may define ways to send provisional responses reliably using non-SIP mechanisms (e.g., using media-level messages to acknowledge the reception of the SIP response). For the purposes of this document, provisional responses using those non-SIP mechanisms are considered unreliable responses. Note that non-100 provisional responses are only applicable to INVITE transactions [RFC4320].
SIPにおける信頼性のある暫定応答は、RFC 3262 [RFC3262]で指定されています。この文書では、信頼できる暫定的な応答は、RFC 3262 [RFC3262]で定義されたメカニズムを使用するものです。他の仕様を確実に（例えば、SIP応答の受信を確認するために、メディア・レベル・メッセージを使用して）非SIPメカニズムを使用して、暫定応答を送信する方法を定義してもよいです。このドキュメントの目的のために、これらの非SIPメカニズムを使用して、暫定応答を信頼できない応答と考えられています。非100暫定応答トランザクション[RFC4320]を招待するにのみ適用可能であることに留意されたいです。
If instead of sending a reliable provisional response or a 2xx response to the target-refresh request, or a request to the new target, the UA generates an error response to the target-refresh request, the UA MUST NOT update its dialog's remote target.
代わりに、信頼性のある暫定応答またはターゲットリフレッシュ要求に対する2xx応答、または新しいターゲットに要求を送信するのでは、UAは、ターゲットリフレッシュ要求に対するエラー応答を生成する場合、UAは、そのダイアログのリモートターゲットをアップデートしてはいけません。
If a UA receives a reliable provisional response or a 2xx response to a target-refresh request, the UA MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present.
UAは、信頼性のある暫定応答またはターゲットリフレッシュ要求に対する2xx応答を受信した場合に存在する場合、UAは、その応答にContactヘッダーフィールドからURIを持つダイアログのリモートターゲットURIを交換する必要があります。
If a UA receives an unreliable provisional response to a target-refresh request, the UA MUST NOT refresh the dialog's remote target.
UAは、ターゲット・リフレッシュ要求に信頼性のない暫定応答を受信した場合、UAはダイアログのリモートターゲットをリフレッシュしてはなりません。
SIP provides request ordering by using the Cseq header field. That is, a UA that receives two requests at roughly the same time can know which one is newer. However, SIP does not provide ordering between responses and requests. For example, if a UA receives a 200 (OK) response to an UPDATE request and an UPDATE request at roughly the same time, the UA cannot know which one was sent last. Since both messages can refresh the remote target, the UA needs to know which message was sent last in order to know which remote target needs to be used.
SIPはCSeqヘッダーフィールドを使用して、リクエストの順序を提供します。つまり、ほぼ同じ時刻に2つの要求を受け取るUAは新しいである1を知ることができます。しかし、SIPは、応答と要求の間の順序を提供していません。 UAはUPDATE要求とUPDATE要求でほぼ同じ時間に200（OK）レスポンスを受信した場合、例えば、UAは、最後に送信された1知ることができません。両方のメッセージがリモートターゲットをリフレッシュすることができますので、UAが使用する必要のあるリモート・ターゲットを知るために、最後に送信されたメッセージを知っている必要があります。
This document specifies the following rule to avoid the situation just described. If the protocol allows a UA to use a target-refresh request at the point in time that the UA wishes to refresh its local target, the UA MUST use a target-refresh request instead of a response to refresh its local target. This rule implies that a UA only uses a response (i.e., a reliable provisional response or a 2xx response to a target-refresh request) to refresh its local target if the UA is unable to use a target-refresh request at that point in time (e.g., the UAS of an ongoing re-INVITE without support for UPDATE).
この文書では、今述べたような状況を回避するには、次のルールを指定します。プロトコルは、UAは、UAがそのローカルターゲットを更新したい時点でターゲットリフレッシュ要求を使用することを可能にする場合、UAは、そのローカルターゲットをリフレッシュするために応答するのではなく、ターゲットリフレッシュ要求を使用しなければなりません。この規則は、UAが唯一のUAは、その時点でターゲット・リフレッシュ要求を使用することができない場合（つまり、信頼性のある暫定応答またはターゲットリフレッシュ要求に対する2xx応答）がそのローカルターゲットをリフレッシュするために応答を使用していることを意味します（例えば、現在進行中のUASはUPDATEのためのサポートなしに再INVITE）。
The rules given in this section about which messages can refresh the target of a dialog also apply to early dialogs created by an initial INVITE transaction. Additionally, as specified in Section 13.2.2.4 of RFC 3261 [RFC3261], on receiving a 2xx response to the initial INVITE, the UAC recomputes the whole route set of the dialog, which transitions from the "early" state to the "confirmed" state.
メッセージダイアログのターゲットをリフレッシュできるかについて、このセクションで与えられた規則はまた、最初のINVITEトランザクションによって作成された初期のダイアログに適用されます。また、RFC 3261のセクション13.2.2.4 [RFC3261]で指定されているように、最初のINVITEに対する2xx応答を受信すると、UACは、「確認」に「早期」状態からの遷移ダイアログの全体のルートセットを、再計算します状態。
Section 12.1 of RFC 3261 allows unreliable provisional responses to create early dialogs. However, per the rules given in this section, unreliable provisional responses cannot refresh the target of a dialog. Therefore, the UAC of an initial INVITE transaction will not perform any target refresh as a result of the reception of an unreliable provisional response with an updated Contact value on an (already established) early dialog. Note also that a given UAS can establish additional early dialogs, which can have different targets, by returning additional unreliable provisional responses with different To tags.
RFC 3261のセクション12.1は、信頼性のない暫定応答はearlyダイアログを作成することができます。ただし、この節で与えられた規則に従って、信頼性のない暫定応答は、ダイアログのターゲットを更新することはできません。したがって、初期のUACは、トランザクションが（すでに確立された）初期のダイアログの更新連絡先の値を持つ信頼性のない暫定応答の受信の結果として、任意のターゲット・リフレッシュを実行しませんINVITE。与えられたUASは、タグに異なると、追加の信頼性のない暫定応答を返すことによって、異なる目標を持つことができ、追加の早期ダイアログを確立できることにも注意してください。
The following sections discuss the case where a UA loses its transport address during an ongoing re-INVITE transaction. Such a UA will refresh the dialog's local target so that it reflects its new transport address. Note that target refreshes that do not involve changes in the UA's transport address are outside of the scope of this section. Also, UAs losing their transport address during a non-re-INVITE transaction (e.g., a UA losing its transport address right after having sent an UPDATE request before having received a response to it) are out of scope as well.
次のセクションでは、UAは、現在進行中の再INVITEトランザクション中にそのトランスポートアドレスを失うケースを議論します。それは、新しいトランスポートアドレスを反映するようなUAは、ダイアログのローカルターゲットを更新します。 UAのトランスポートアドレスの変更を伴わないそのターゲットの更新は、このセクションの範囲外であることに注意してください。また、非再INVITEトランザクション中にそのトランスポート・アドレスを失うのUA（例えば、UAは、右のそれに対する応答を受信する前に更新要求を送信した後、そのトランスポート・アドレスを失う）も範囲外です。
The rules given in this section are also applicable to initial INVITE requests that have established early dialogs.
このセクションで与えられた規則はまた、早期ダイアログを確立したINVITE要求初期に適用可能です。
Re-INVITEs are routed using the dialog's route set, which contains all the proxy servers that need to be traversed by requests sent within the dialog. Responses to the re-INVITE are routed using the Via entries in the re-INVITE.
再のINVITEダイアログ内で送信要求によって横断する必要のあるすべてのプロキシ・サーバを含むダイアログのルートセットを、使用してルーティングされます。再INVITEへの応答は、INVITEの再のViaエントリを使用してルーティングされます。
ACK requests for 2xx responses and for non-2xx final responses are generated in different ways. As specified in Sections 14.1 and 13.2.1 of RFC 3261 [RFC3261], ACK requests for 2xx responses are generated by the UAC core and are routed using the dialog's route set. As specified in Section 17.1.1.2 of RFC 3261 [RFC3261], ACK requests for non-2xx final responses are generated by the INVITE client transaction (i.e., they are generated in a hop-by-hop fashion by the proxy servers in the path) and are sent to the same transport address as the re-INVITE.
2XX応答のための非2xxの最終応答に対するACKリクエストは、さまざまな方法で生成されます。セクション14.1およびRFC 3261の13.2.1 [RFC3261]で指定されているように、2xxの応答に対するACKリクエストは、UACコアによって生成され、ダイアログのルートセットを使用してルーティングされます。 RFC 3261のセクション17.1.1.2 [RFC3261]で指定されているように、非2xxの最終応答に対するACK要求は（すなわち、それらはパスでプロキシサーバによりホップバイホップファッションに生成されたINVITEクライアントトランザクションによって生成され、 ）再INVITEと同じ輸送アドレスに送信されます。
Refreshing the dialog's remote target during a re-INVITE transaction (see Section 4.3) presents some issues because of the fact that re-INVITE transactions can be long lived. As described in Section 5.1, the way responses to the re-INVITE and ACKs for non-2xx final responses are routed is fixed once the re-INVITE is sent. The routing of this messages does not depend on the dialog's route set and, thus, target refreshes within an ongoing re-INVITE do not affect their routing. A UA that changes its location (i.e., performs a target refresh) but is still reachable at its old location will be able to receive those messages (which will be sent to the old location). However, a UA that cannot be reachable at its old location any longer will not be able to receive them.
（4.3節を参照）再INVITEトランザクション中にダイアログのリモートターゲットをリフレッシュするために再INVITEトランザクションが長く住んでいたことができるという事実をいくつかの問題を提示します。 5.1節で述べたように、への道応答再INVITEおよびREは、INVITEが送信されたら、2xx以外の最終応答に対するACKは固定されてルーティングされます。このメッセージのルーティングは、このように、ダイアログのルートセットに依存していない、ターゲットが範囲内にリフレッシュの進行中の再INVITE自分のルーティングには影響を与えません。 （すなわち、ターゲット・リフレッシュを実行する）その位置を変化させるが、その古い位置が（古い場所に送信される）これらのメッセージを受信することができるであろうに依然として到達可能であるUA。しかし、もはやその古い場所に到達することはできませんUAはそれらを受け取ることができません。
The following sections describe the errors UAs face when they lose their transport address during a re-INVITE. On detecting some of these errors, UAs following the rules specified in RFC 3261 [RFC3261] will terminate the dialog. When the dialog is terminated, the only option for the UAs is to establish a new dialog. The following sections change the requirements RFC 3261 [RFC3261] places on UAs when certain errors occur so that the UAs can recover from those errors. In short, the UAs generate a new re-INVITE transaction to synchronize both UAs. Note that there are existing UA implementations deployed that already implement this behavior.
彼らは再INVITE中にそれらの輸送アドレスを失う場合は、次のセクションでは、UAが直面するエラーについて説明します。これらのエラーの一部を検出すると、RFC 3261 [RFC3261]で指定されたルールを以下UAは、ダイアログを終了します。ダイアログが終了すると、UAのための唯一のオプションは、新しいダイアログを確立することです。 UAはこれらのエラーから回復できるように、特定のエラーが発生した場合、次のセクションでは、UAの上の要件のRFCに3261 [RFC3261]の場所を変更します。要するに、UAは両方のUAを同期させるために、新たな再INVITEトランザクションを発生させます。すでにこの動作を実装展開し、既存のUAの実装があることに注意してください。
When a UAS that moves to a new contact and loses its old contact generates a non-2xx final response to the re-INVITE, it will not be able to receive the ACK request. The entity receiving the response and, thus, generating the ACK request will either get a transport error or a timeout error, which, as described in Section 8.1.3.1 of RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable) response and as a 408 (Request Timeout) response, respectively. If the sender of the ACK request is a proxy server, it will typically ignore this error. If the sender of the ACK request is the UAC, according to Section 12.2.1.2 of RFC 3261 [RFC3261], it is supposed to (at the SHOULD level) terminate the dialog by sending a BYE request. However, because of the special properties of ACK requests for non-2xx final responses, most existing UACs do not terminate the dialog when ACK request fails, which is fortunate.
新しい連絡先に移動し、その古い接触を失うUASが再INVITEに対する非2xxの最終的な応答を生成するとき、ACK要求を受信することができません。エンティティ、RFC 3261 [RFC3261]のセクション8.1.3.1に記載されているように、トランスポートエラーまたはタイムアウトエラーを取得するかACK要求を生成、従って、応答を受信し、503（サービス利用不可）として扱われます応答は、それぞれ408（要求タイムアウト）応答、など。 ACK要求の送信者がプロキシサーバである場合、それは通常、このエラーを無視します。 ACK要求の送信者がRFC 3261 [RFC3261]のセクション12.2.1.2によれば、UACである場合には、BYE要求を送信することによって、ダイアログを終了する（SHOULDレベル）になっています。 ACK要求が失敗した場合しかし、非2xxの最終応答に対するACKリクエストの特殊な性質のため、ほとんどの既存求めるUACは幸運である、ダイアログを終了しません。
A UAC that accepts a target refresh within a re-INVITE MUST ignore transport and timeout errors when generating an ACK request for a non-2xx final response. Additionally, UAC SHOULD generate a new re-INVITE in order to make sure that both UAs have a common view of the state of the session.
非2XX最終応答に対するACKリクエストを生成するときに再INVITE内のターゲットリフレッシュを受け付けるUACは、輸送及びタイムアウトエラーを無視しなければなりません。また、UACは、両方のUAがセッションの状態の一般的な見解を持っていることを確認するために再INVITE新しいを生成する必要があります。
It is possible that the errors ignored by the UAC were not related to the target refresh operation. If that was the case, the second re-INVITE would fail and the UAC would terminate the dialog because, per the rules above, UACs only ignore errors when they accept a target refresh within the re-INVITE.
UACによって無視されたエラーは、ターゲットリフレッシュ動作に関連していなかった可能性があります。それが事実だった場合は、第2の再INVITE失敗し、彼らは再INVITE内のターゲットリフレッシュを受け入れる時には、上記のルールごとに、求めるUACが唯一のエラーを無視し、ため、UACはダイアログを終了します。
When a UAC moves to a new contact and loses its old contact, it will not be able to receive responses to the re-INVITE. Consequently, it will never generate an ACK request.
UACは、新しい連絡先に移動し、その昔の接触を失ったとき、再INVITEへの応答を受信することができません。したがって、ACK要求を生成することはありません。
As described in Section 16.9 of RFC 3261 [RFC3261], a proxy server that gets an error when forwarding a response does not take any measures. Consequently, proxy servers relaying responses will effectively ignore the error.
RFC 3261のセクション16.9 [RFC3261]で説明したように、応答を転送するときにエラーを取得し、プロキシサーバは、どんな対策を取ることはありません。その結果、応答を中継するプロキシサーバは、効果的にエラーを無視します。
If there are no proxy servers in the dialog's route set, the UAS will get an error when sending a non-2xx final response. The UAS core will be notified of the transaction failure, as described in Section 17.2.1 of RFC 3261 [RFC3261]. Most existing UASs do not terminate the dialog on encountering this failure, which is fortunate.
ダイアログのルートセットにはプロキシサーバが存在しない場合は非2xxの最終的な応答を送信するとき、UASはエラーになります。 RFC 3261 [RFC3261]のセクション17.2.1に記載されているようにUASコアは、トランザクションの失敗を通知します。ほとんどの既存のUASは幸運である、この障害が発生した上で、ダイアログを終了しません。
Regardless of the presence or absence of proxy servers in the dialog's route set, a UAS generating a 2xx response to the re-INVITE will never receive an ACK request for it. According to Section 14.2 of RFC 3261 [RFC3261], such a UAS is supposed to (at the "should" level) terminate the dialog by sending a BYE request.
かかわらず、ダイアログのルートセット、UASでのプロキシサーバの有無-INVITE再に対する2xx応答を生成すると、そのためのACK要求を受信することはありません。 RFC 3261のセクション14.2 [RFC3261]によれば、そのようなUASは（「べき」レベル）になっているBYE要求を送信することによって、ダイアログを終了します。
A UAS that accepts a target refresh within a re-INVITE and never receives an ACK request after having sent a final response to the re-INVITE SHOULD NOT terminate the dialog if the UA has received a new re-INVITE with a higher CSeq sequence number than the original one.
UAが高いのCSeqシーケンス番号を持つ新しい再INVITEを受信した場合は再INVITE内のターゲットリフレッシュを受け入れ、決して再INVITEへの最終応答を送信した後にACK要求を受信するUASは、ダイアログを終了しない（SHOULD NOT）オリジナルのものより。
When a UAC moves to a new contact and loses its old contact, it will not be able to receive responses to the re-INVITE. Consequently, it will never generate an ACK request.
UACは、新しい連絡先に移動し、その昔の接触を失ったとき、再INVITEへの応答を受信することができません。したがって、ACK要求を生成することはありません。
Such a UAC SHOULD generate a CANCEL request to cancel the re-INVITE and cause the INVITE client transaction corresponding to the re-INVITE to enter the "Terminated" state. The UAC SHOULD also send a new re-INVITE in order to make sure that both UAs have a common view of the state of the session.
このようなUACは「終端」状態に入るために、INVITEの再に対応する再INVITEと原因INVITEクライアントトランザクションをキャンセルするCANCELリクエストを生成する必要があります。 UACはまた、送るべき新しい再INVITE両方のUAは、セッションの状態の一般的な見解を持っていることを確実にするために。
Per Section 14.2 of RFC 3261 [RFC3261], the UAS will accept new incoming re-INVITEs as soon as it has generated a final response to the previous INVITE request, which had a lower CSeq sequence number.
RFC 3261のセクション14.2 [RFC3261]あたりに、UASはすぐにそれが下のCSeqシーケンス番号を持っていた以前のINVITE要求に対する最終応答を生成したとして、新たに着信再招待受け入れます。
This document does not introduce any new security issue. It just clarifies how certain transactions should be handled in SIP. Security issues related to re-INVITEs and UPDATE requests are discussed in RFC 3261 [RFC3261] and RFC 3311 [RFC3311].
このドキュメントは、新しいセキュリティ上の問題を導入しません。それはちょうど、特定の取引がSIPに扱うべきかを明確にしています。再招き、UPDATE要求に関連するセキュリティ上の問題は、RFC 3261 [RFC3261]およびRFC 3311 [RFC3311]で議論されています。
In particular, in order not to reduce the security level for a given session, re-INVITEs and UPDATE requests SHOULD be secured using a mechanism equivalent to or stronger than the initial INVITE request that created the session. For example, if the initial INVITE request was end-to-end integrity protected or encrypted, subsequent re-INVITEs and UPDATE requests should also be so.
特に、所与のセッションのセキュリティレベルを低下させないために、再招き、更新要求は、機構と同等またはセッションを作成し、初期INVITE要求よりも強いを使用して保護されるべきです。最初の要求は、エンドツーエンドの完全性を保護または暗号化されたINVITEた場合、その後の再招き、UPDATEリクエストもそうでなければなりません。
Paul Kyzivat provided useful ideas on the topics discussed in this document.
ポールKyzivatは、この文書で説明する内容に有益なアイデアを提供します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3262、2002年6月 "セッション開始プロトコル（SIP）における暫定的な応答の信頼性"。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311]ローゼンバーグ、J.、 "セッション開始プロトコル（SIP）更新方法"、RFC 3311、2002年10月。
[RFC4032] Camarillo, G. and P. Kyzivat, "Update to the Session Initiation Protocol (SIP) Preconditions Framework", RFC 4032, March 2005.
[RFC4032]キャマリロ、G.とP. Kyzivat、 "セッション開始プロトコル（SIP）前提条件フレームワークへの更新"、RFC 4032、2005年3月。
[RFC4320] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
[RFC4320]スパークス、R.、RFC 4320、2006年1月 "セッション開始プロトコル（SIP）非INVITEトランザクションと特定された問題への対処アクション"。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245]ローゼンバーグ、J.、 "インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための議定書"、RFC 5245、2010年4月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンサロ・カマリロ（エディタ）エリクソンHirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
クリステルHolmbergのエリクソンHirsalantie 11 02420 Jorvasフィンランド
EMail: Christer.Holmberg@ericsson.com
メールアドレス：Christer.Holmberg@ericsson.com
Yang Gao ZTE China
ZTEは中国のガオです
EMail: gao.yang2@zte.com.cn
メールアドレス：gao.yang2@zte.com.cn