[要約] RFC 6141は、SIPにおけるRe-INVITEとTarget-Refreshリクエストの処理に関する仕様です。このRFCの目的は、SIPセッションの再招待やターゲットの更新リクエストの適切な処理方法を定義することです。
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)
セッション開始プロトコル（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.
SIP Re-Invitesを処理する手順は、RFC 3261で説明されています。実装と展開の経験は、元のドキュメントに関する多くの問題を明らかにしており、このドキュメントは、これらの問題に対処するために元の仕様を更新する追加の手順を提供します。特に、このドキュメントでは、UAS（ユーザーエージェントサーバー）が成功応答を生成する状況と、UASが再インバイトに対するエラー応答を生成する状況でどのような状況を定義しています。さらに、このドキュメントでは、ターゲットリフレッシュリクエストに関連する手順の詳細を定義しています。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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で説明したように、既存のダイアログ内で送信された招待状リクエストは、再インバイトとして知られています。Re Inviteは、セッションパラメーター、ダイアログパラメーター、またはその両方を変更するために使用されます。つまり、単一の再インバイトは、関連するセッションのパラメーター（メディアストリームが受信される場所のIPアドレスの変更）と、関連するダイアログのパラメーター（例えば、ダイアログのリモートターゲットを変更する）の両方を変更できます。RFC 3261 [RFC3261]のセクション6で定義されているように、ターゲット更新要求であるため、ダイアログのリモートターゲットを変更できます。
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.
Re-Inviteトランザクションには、それに関連するオファー/回答[RFC3264]交換があります。特定のRe-Inviteを生成するUAC（ユーザーエージェントクライアント）は、オファーとして、または回答者として機能します。オファーとして行動する意思のあるUACには、再インバイトにオファーが含まれています。UAS（ユーザーエージェントサーバー）は、Re Inviteへの応答の回答を提供します。応答者として行動する意思のあるUACには、再インバイトにオファーが含まれていません。その後、UASは、再インバイトになることに対する応答でオファーを提供します。
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.
Re-Invite内の特定のトランザクション（例：更新[RFC3311]トランザクション）には、それらに関連付けられたオファー/回答の交換もあります。UA（ユーザーエージェント）は、UAがUmbrella Re-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が再インバイトをどのように処理すべきかについて、実装者の間でいくつかの混乱がありました。特に、実装者は、さまざまな状況でUAが生成すべき応答のタイプについて明確化を要求しました。このドキュメントでは、これらの問題を明確にします。
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.
さらに、ターゲットの更新要求に関する実装者の間でも混乱がありました。このドキュメントでは、リモートターゲットが更新されるプロセスも明確にします。
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.
UAS：ユーザーエージェントサーバー。
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という用語は、招待または再視力のトランザクションに関して使用されており、招待トランザクション内で発生する更新トランザクションなど、他のトランザクションに関するUAの役割を必ずしも反映しているわけではないことに注意してください。
The following sub-sections discuss how to change the state of the session during a re-INVITE transaction.
次のサブセクションでは、再入札トランザクション中にセッションの状態を変更する方法について説明します。
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.
最終的には、再銀行を受け取るUASは、それに対する応答を生成する必要があります。一部の再インバイトは、ユーザーの対話を必要としないため、すぐに応答できます（たとえば、メディアストリームが受信された場所でIPアドレスを変更する）。他のREインバイトの処理には、ユーザーインタラクションが必要です（たとえば、音声のみのセッションにビデオストリームを追加します）。したがって、これらの再インバイトはすぐに応答することはできません。
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.
Re-Inviteへのエラー応答には、次のセマンティクスがあります。RFC 3261 [RFC3261]のセクション12.2.2で指定されているように、reinviteが拒否された場合、状態の変更は実行されません。これらの状態の変更には、再インバイトトランザクションに関連する状態の変更と、再インバイト内の他のすべてのトランザクションが含まれます（このセクションでは、セッション状態の変更を扱います。ターゲットリフェッシュについては、セクション4.2で説明します）。つまり、セッション状態は、再インバイトが受信された前と同じです。図1の例は、この点を示しています。
UAC UAS
uac uas
| |
|-------------(1) INVITE SDP1--------------->|
| |
|<------------(2) 200 OK SDP2----------------|
| |
|------------------(3) ACK------------------>|
| |
| |
|-------------(4) INVITE SDP3--------------->|
| |
|<-----------------(5) 4xx-------------------|
| |
|------------------(6) ACK------------------>|
| |
Figure 1: Rejection of a re-INVITE
図1：再入力の拒絶
The UAs perform an offer/answer exchange to establish an audio-only session:
UASはオファー/回答の交換を実行して、オーディオのみのセッションを確立します。
SDP1: m=audio 30000 RTP/AVP 0
SDP1：M =オーディオ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はセッションにビデオストリームを追加するために、再インベンタ（4）を送信します。
SDP3: m=audio 30000 RTP/AVP 0 m=video 30002 RTP/AVP 31
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によって説明される初期オファー/回答交換の結果であるものです。つまり、セッション状態は、再インバイトが受信された前と同じです。
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は、エラー応答を返すことにより、再インバイトで要求されたすべての変更を拒否しました。ただし、UASが再インバイトで要求されたすべての変更ではなく、一部を受け入れたい状況があります。これらの場合、UASは、セッション説明プロトコル（SDP）を使用して200（OK）応答を生成します。図2の例は、この点を示しています。
UAC UAS
uac uas
| |
|-------------(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:
UASはオファー/回答の交換を実行して、オーディオのみのセッションを確立します。
SDP1: m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.1
SDP1：M = Audio 30000 RTP/AVP 0 C = IP4 192.0.2.1
SDP2: m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5
SDP2：M =オーディオ31000 RTP/AVP 0 C = IP4 192.0.2.5
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は、Audioストリームを新しいIPアドレスに受信し、セッションにビデオストリームを追加するIPアドレスを変更するために、Re-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
SDP3：M = Audio 30000 RTP/AVP 0 C = IN IP4 192.0.2.2 M =ビデオ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
SDP4：M =オーディオ31000 RTP/AVP 0 C = IP4 192.0.2.5 M =ビデオ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]を使用することを前提としています（プラックトランザクションは明確に表示されません）。
UAC UAS
uac uas
| |
|-------------(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コントロールを交換する必要があるため、ストリームを「非アクティブ」に設定する代わりにnull 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
SDP4：M =オーディオ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は更新リクエスト（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
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
SDP6：M = Audio 30000 RTP/AVP 0 C = 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は、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.
以前のすべての例では、Re-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）と、UASが再視力で要求された変更の一部を実行する方法に関する例が含まれています。それらのいくつかは、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.
実装者間で混乱を引き起こしたシナリオは、再インバイトを受信し、その中で要求された変更の一部を実行し、すでに実行されているすべての変更を拒否し、前後の状態に戻すことを望んでいるUASで構成されています。このようなUASは、再インバイトへのエラー応答を返すことを検討する場合があります（メッセージフローは図1のフローと似ています）、または更新リクエストを使用して前菜以前の状態に戻し、2xx応答を返しますre inviteに（メッセージフローは図3のメッセージに似ています）。このセクションでは、これらの状況でエラー応答を返すことに関連する問題について説明します。これらの問題を回避するために、UASは後者のオプションを使用する必要があります（リクエストと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.
すでに実行された変更を元に戻すためにエラー応答を使用しない理由は、変更が既に実行されているReinviteに対するエラー応答（たとえば、更新トランザクションまたは信頼できる暫定的な応答の結果として）が効果的に変更を要求しているためです。セッション状態。ただし、UACは、それらを実行できない場合、その変更を拒否する手段がありません。つまり、UACがリアバイト以前の状態に戻ることができない場合、この事実を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.
UASSは、再インバイトが受信されてからセッション状態に変更されていない場合にのみ、再インバイトに対するエラー応答を返す必要があります。このようなエラー応答は、再インバイトまたはその中の他のトランザクションの結果として変更が実行されていないことを示しています。
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.
Re-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が新しいパラメーターを使用してメディアを送信または受信した場合、オファー/回答[RFC4032]が実行されたと見なされます。接続確立メッセージ（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は、Calleeが警告を開始するか、Calleeがセッションを受け入れるまで、メディアパラメーターを使用する前に待つことができます。セッションの変更中、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.
Re Invite内ですでに実行されている変更を元に戻すReインベティへのエラー応答を受信するUACは、この仕様をサポートしていないレガシーUASに直面している可能性があります（つまり、セクション3.3のガイドラインに従わないUAS）。また、両方のユーザーエージェントを同期しなくする特定の人種状態の状況もあります。これらの人種状態の状況に対処するために、変更が既に実行されている再視力に対するエラー応答を受信するUACは、両方のUASが共通のものを持っていることを確認するために、新しい再入札または更新要求を生成する必要がありますセッションの状態のビュー（UACは、特定のストリームで変更が実行されたかどうかを決定するために、セクション3.3の基準を使用します）。この新しいオファー/回答交換の目的は、UASが拒否することを選択できる変更を要求するのではなく、両方のUASを同期することです。したがって、オファー/回答の交換のセッションパラメーターは、可能な限り、前後の状態のセッションパラメーターに近いものでなければなりません。
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では、グレア条件を、送信した後にオファーを受け取ったが、回答を受け取る前にオファーを受け取るユーザーエージェントとして定義しています。そのセクションは、ほとんどの場合、まぶしさを回避するためのルールを指定します。これらのルールに従っているにもかかわらず、グレア状態が発生した場合（人種条件の結果として）、RFC 3261 [RFC3261]のセクション14.1および14.2で指定されているように処理されます。UASは491（リクエスト保留中）応答を返し、UACはランダムに選択された時間の後にオファーを取得します。これは、どのユーザーエージェントがダイアログのCall-IDの所有者であるかによって異なります。RFC 3261 [RFC3261]のルールは、オファーを含む再インバイト間の衝突をカバーするだけでなく、オファーが含まれていなくても、一般に2つの再インバイト間の衝突をカバーします。RFC 3311 [RFC3311]のセクション5.2および5.3は、これらのルールを拡張して、オファーを運ぶ更新リクエストと別のメッセージ（更新、プラック、または招待）の間の衝突もカバーします。
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]のルールは、更新リクエストとREインベンタルに対する非2XX最終応答との間の衝突をカバーしていません。更新要求と信頼できる応答の両方がセッション状態の変更を要求する可能性があるため、最初にどの変更を実行する必要があるかは明らかではありません。ただし、セクション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).
このセクションには、更新リクエストを使用してこの仕様を実装するUASの例が含まれています。図4に示す例は、UASがビデオストリームの追加を受け入れるか拒否するためにユーザーの入力を必要とし、信頼できる暫定的な応答[RFC3262]を使用することを前提としています（プラックトランザクションは明確には表示されません）。
UAC UAS
uac uas
| |
|-------------(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:
UASはオファー/回答の交換を実行して、オーディオのみのセッションを確立します。
SDP1: m=audio 30000 RTP/AVP 0 c=IN IP4 192.0.2.1
SDP1：M = Audio 30000 RTP/AVP 0 C = IP4 192.0.2.1
SDP2: m=audio 31000 RTP/AVP 0 c=IN IP4 192.0.2.5
SDP2：M =オーディオ31000 RTP/AVP 0 C = IP4 192.0.2.5
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は再生視聴者（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
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
SDP4：M =オーディオ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はアップデートリクエスト（6）を送信して、オーディオストリームから元のオーディオコーデックを削除します（UACは、この変更を要求するためにプラックを使用して（5）。
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
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：M =オーディオ31000 RTP/AVP 3 C = IN IP4 192.0.2.5 M = Video 31002 RTP/AVP 31 C = IN IP4 0.0.0.0
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は更新リクエスト（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
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は、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
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は、200（OK）応答（10）をRe Inviteに返します。この200（OK）の応答の後のメディア状態は、前後のメディア状態と同じであることに注意してください。
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は、UASがセッションの状態の異なる見解で終わる人種状態の状況の例を示しています。
a:sendrecv a:sendrecv
v:inactive v:inactive
UA1 Proxy 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
A：オーディオストリームのステータスV：ビデオストリームのステータス
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のUASは、図のメッセージが始まる直前に、SendRecvオーディオストリームと非アクティブなビデオストリームを含むセッションに関係しています。ua1は、ビデオストリームのsendrecvを作成するように要求するre invite（1）を送信します。
SDP1: m=audio 20000 RTP/AVP 0 a=sendrecv m=video 20002 RTP/AVP 31 a=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）を返すことにより、ビデオストリームを再登録します。
SDP2: m=audio 30000 RTP/AVP 0 a=sendrecv m=video 30002 RTP/AVP 31 a=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は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.
プロキシは、4xx応答（7）をUA1にリレーします。ただし、4XX応答（7）はUA1に到着するのに時間がかかります（たとえば、UDPを介して応答が送信され、最初の数回の再送信が失われた可能性があります）。それまでの間、UA2のユーザーはオーディオストリームを保留することにしました。ua2は、オーディオストリームを再recvonlyにする更新リクエスト（8）を送信します。非アクティブなビデオストリームは変更されておらず、したがって、非アクティブであり続けます。
SDP3: m=audio 30000 RTP/AVP 0 a=recvonly m=video 30002 RTP/AVP 31 a=inactive
SDP3：M = Audio 30000 RTP/AVP 0 A = RecvonlyM = 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.
プロキシは、更新要求（9）をUA1にリレーします。更新リクエスト（9）は、以前に送信された4xx応答（7）の前にUA1に到着します。UA1は更新要求の変更を受け入れ、200（OK）応答（10）を返します。
SDP4: m=audio 20000 RTP/AVP 0 a=sendonly m=video 30002 RTP/AVP 31 a=inactive
SDP4：M = Audio 20000 RTP/AVP 0 A = SendonlyM = 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に到着します。この応答により、セッションはRE-RE-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.
図5のメッセージフローの後、このセクションの推奨事項に従って、UA1が既に実行された変更が既に変更されたエラー応答（7）を受け取ったとき、UA1は、前後の状態を反映したSDPで更新リクエストを生成します（つまり、RECVオーディオと非アクティブビデオを送信）。UA2は、UA2のユーザーが要求した状態であるオーディオストリームをRecvonlyにする更新リクエストに200（OK）応答を返すことができます。このような更新トランザクションにより、UASが同期に戻ります。
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 [RFC3261]のセクション9.2は、キャンセル要求に応答するUASの動作を指定しています。このようなUASは、レベルで487（リクエスト終了）で招待リクエストに応答します。セクション3.3で指定されたルールに従って、招待リクエストが再インベンタルであり、その要求された変更の一部がすでに実行されていた場合、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またはセッション開始プロトコルセキュア（SIP）URIの記録を保持します。「ダイアログのリモートターゲットURI」は、ピアから受け取るリクエストと応答のコンタクトヘッダーに含まれるURIに等しくなります）。このドキュメントでは、ピアが通信できるSIPまたはSIPS URIのUAの記録として定義された「ダイアログのローカルターゲットURI」の補完的な概念を紹介します（それが送信するリクエストと応答の連絡先ヘッダーに含まれるURIに等しいピアに）。これらの用語は、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.
さらに、Target-Refreshリクエストに対する2XX応答は、ダイアログのリモートターゲットを更新することもできます。RFC 3261 [RFC3261]のセクション12.2で説明したように、Re-Invitesはターゲットリフレッシュリクエストです。
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]は、ターゲットリフレッシュ要求を受信するUASSおよびターゲットリフレッシュリクエストの2XX応答を受信するUASの動作を指定します。
Section 12.2.2 of RFC 3261 [RFC3261] says:
RFC 3261 [RFC3261]のセクション12.2.2は次のように述べています。
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がターゲットの更新要求を受信した場合、その要求の場合、その要求のコンタクトヘッダーフィールドからダイアログのリモートターゲットURIをURIに置き換える必要があります。
Section 12.2.1.2 of RFC 3261 [RFC3261] says:
RFC 3261 [RFC3261]のセクション12.2.1.2は次のように述べています。
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応答を受信する場合、その応答の場合（その応答のコンタクトヘッダーフィールド）ダイアログのリモートターゲット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.
再インバイトは長期的なトランザクションになり、その中に他のトランザクションを持つことができるという事実により、これらの規則を修正する必要があります。セクション4.3は、ターゲットリフレッシュリクエストの処理に関する新しいルールを指定しています。新しいルールは、再インバイトだけでなく、ターゲットリフレッシュリクエストに適用されることに注意してください。
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は、受信したリモートターゲットを使用して、SIPリクエストをリモートUAに送信します。
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がIPアドレスを変更します）、UAは新しいローカルターゲットをリモートUAに単純に伝えます（たとえば、UAは新しいIPアドレスをリモートUAに伝えます。リモートUA）。UASは、セクション4.2で説明されているRFC 3261 [RFC3261]で指定されたものではなく、この仕様のセクション4.4、4.5、4.6、および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がTarget-Refresh要求に対するエラー応答を受信した場合、リモートUAはリモートターゲットを更新していません。
This allows UASs to authenticate target-refresh requests (see Section 26.2 of RFC 3261 [RFC3261]).
これにより、UASSはターゲットリフレッシュリクエストを認証できます（RFC 3261 [RFC3261]のセクション26.2を参照）。
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.
ターゲットリクエストが再インバイトであり、再インバイトへの最終的な応答がエラー応答であったとしても、UASは前後のリモートターゲットに戻りません。
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がセッションの変更を拒否しながらターゲットの更新を受け入れることが不必要に複雑になります。ターゲットの更新要求が再インバイトであり、UASが信頼できる暫定的な応答または更新リクエストをサポートしている場合にのみ、UACは同じリンバイトでピギーバックセッションが変更され、ターゲット更新が変更される場合があります。
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応答を返すことにより、ローカルターゲットを更新できます。応答は、コンタクトヘッダーフィールドに更新されたローカルターゲット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 [RFC3261]のセクション26.2を参照）、UAはターゲットリフレッシュリクエストに対する信頼できる暫定的な応答または2XX応答を生成する必要があります。そのような応答を生成することが不可能である場合（たとえば、UAは信頼できる暫定的な応答をサポートしておらず、最終的な応答を生成する前にユーザー入力を必要とします）、UAは新しいリモートターゲットを使用してリモートUAにダイアログ内リクエストを送信する必要があります（UAは他の理由でリクエストを送信する必要はありません。UASは更新リクエストを送信できます）。信頼できる暫定的な応答またはターゲットリフレッシュリクエストへの2xx応答、または新しいリモートターゲットへのリクエストを送信する際、UAは、ターゲットリフレッシュリクエストでダイアログのリモートターゲット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は、その応答の場合、ダイアログのリモートターゲット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は、どれが新しいかを知ることができます。ただし、SIPは応答とリクエストの間の注文を提供しません。たとえば、UAが更新リクエストに対する200（OK）の応答と、ほぼ同時に更新リクエストを受信した場合、UAは最後に送信されたものを知ることができません。両方のメッセージはリモートターゲットを更新できるため、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がその時点でターゲットリフレッシュリクエストを使用できない場合にローカルターゲットを更新するために、UAが応答のみを使用していることを意味します。（たとえば、更新をサポートすることなく、進行中の再インバイトのUAS）。
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.
このセクションで説明されているルールは、ダイアログのターゲットを更新できるメッセージについて、最初の招待トランザクションによって作成された早期ダイアログにも適用されます。さらに、RFC 3261 [RFC3261]のセクション13.2.2.4 [RFC3261]で指定されているように、最初の招待に対する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では、早期ダイアログを作成するための信頼性の低い暫定的な対応を許可しています。ただし、このセクションに記載されている規則に従って、信頼できない暫定的な回答は、ダイアログのターゲットを更新することはできません。したがって、最初の招待トランザクションのUACは、（すでに確立された）初期のダイアログで更新された連絡先値を使用して、信頼できない暫定的な応答を受信した結果、ターゲット更新を実行しません。また、特定の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が進行中の再入札トランザクション中に輸送アドレスを失う場合について説明します。このようなUAは、ダイアログのローカルターゲットを更新して、新しい輸送住所を反映するようにします。UAの輸送アドレスの変更を伴わないターゲットリフレッシュは、このセクションの範囲外であることに注意してください。また、UASは、非REインバイトのトランザクション中に輸送住所を失うこと（例：UAは、それに対する応答を受け取る直前に更新リクエストを送信した直後に輸送住所を失う）も範囲外です。
The rules given in this section are also applicable to initial INVITE requests that have established early dialogs.
このセクションに記載されているルールは、早期ダイアログを確立した最初の招待リクエストにも適用されます。
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.
Re Invitesは、ダイアログ内で送信されたリクエストによって移動する必要があるすべてのプロキシサーバーを含むダイアログのルートセットを使用してルーティングされます。Re-Inviteへの応答は、Re-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要求は、さまざまな方法で生成されます。RFC 3261 [RFC3261]のセクション14.1および13.2.1で指定されているように、2XX応答のACK要求はUACコアによって生成され、ダイアログのルートセットを使用してルーティングされます。RFC 3261 [RFC3261]のセクション17.1.1.2で指定されているように、2XX以外の最終応答のACK要求は、招待クライアントトランザクションによって生成されます（つまり、パスのプロキシサーバーによってホップバイホップファッションで生成されます。）および再インバイトと同じ輸送アドレスに送られます。
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を参照）、再入札トランザクションが長く生きることができるという事実のために、いくつかの問題が提示されます。セクション5.1で説明されているように、非2XX最終応答のReインバイトとACKへの応答がルーティングされる方法は、再インバイトが送信されると修正されます。このメッセージのルーティングは、ダイアログのルートセットに依存せず、したがって、継続的な再インバイト内のターゲットリフレッシュはルーティングに影響しません。場所を変更する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.
次のセクションでは、UASが再入力中に輸送アドレスを失ったときに直面するエラーについて説明します。これらのエラーの一部を検出すると、RFC 3261 [RFC3261]で指定されたルールに従うUASがダイアログを終了します。ダイアログが終了すると、UASの唯一のオプションは、新しいダイアログを確立することです。次のセクションでは、特定のエラーが発生したときにUASに配置されている要件RFC 3261 [RFC3261]がUASがこれらのエラーから回復できるように変更されます。要するに、UASは両方のUASを同期するために新しいRe-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が、再視力に対する非2XX最終応答を生成すると、ACKリクエストを受信することはできません。応答を受信してACK要求を生成するエンティティは、RFC 3261 [RFC3261]のセクション8.1.3.1で説明されているように、輸送エラーまたはタイムアウトエラーを取得します。応答およびそれぞれ408（リクエストタイムアウト）応答として。ACK要求の送信者がプロキシサーバーである場合、通常、このエラーは無視されます。ACK要求の送信者がUACである場合、RFC 3261 [RFC3261]のセクション12.2.1.2によると、（レベルで）さようならリクエストを送信してダイアログを終了するはずです。ただし、2XX以外の最終応答のACK要求の特別な特性のため、ほとんどの既存のUACは、ACK要求が失敗したときにダイアログを終了しません。これは幸運です。
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.
Re-Invite内のターゲット更新を受け入れるUACは、非2XX最終応答のACK要求を生成する際にトランスポートとタイムアウトエラーを無視する必要があります。さらに、UACは、両方のUAがセッションの状態について共通のビューを持っていることを確認するために、新しい再インバイトを生成する必要があります。
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番目のRe-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が新しい連絡先に移動して古い連絡先を失った場合、再入手に対する応答を受信することはできません。その結果、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 [RFC3261]のセクション16.9で説明されているように、応答を転送するときにエラーを取得するプロキシサーバーでは、測定値は必要ありません。その結果、応答を中継するプロキシサーバーは、エラーを効果的に無視します。
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.
ダイアログのルートセットにプロキシサーバーがない場合、UASは2XX以外の最終応答を送信するときにエラーが発生します。RFC 3261 [RFC3261]のセクション17.2.1で説明されているように、UASコアにはトランザクション障害が通知されます。ほとんどの既存のUASSは、この失敗に遭遇することに関するダイアログを終了しません。これは幸運です。
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.
ダイアログのルートセットにプロキシサーバーが存在するか、不在に関係なく、Re-Inviteに対する2xx応答を生成するUASは、ACKリクエストを受け取ることはありません。RFC 3261 [RFC3261]のセクション14.2によると、そのような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.
Re Invite内のターゲット更新を受け入れ、Re-Inviteに最終的な応答を送信した後にACK要求を受信しないUASは、UAがCSEQシーケンス番号が高い新しいRe-Inviteを受信した場合、ダイアログを終了してはなりません。元のものよりも。
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が新しい連絡先に移動して古い連絡先を失った場合、再入手に対する応答を受信することはできません。その結果、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は、再銀行をキャンセルするキャンセルリクエストを生成し、re inviteに対応する招待クライアントトランザクションを「終了した」状態に入るようにする必要があります。また、UACは、両方の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 [RFC3261]のセクション14.2ごとに、UASは、CSEQシーケンス番号が低い以前の招待要求に対する最終的な応答を生成するとすぐに、新しい着信再インバイトを受け入れます。
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で特定のトランザクションをどのように処理するかを明確にするだけです。REインバイトと更新リクエストに関連するセキュリティの問題は、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.
特に、特定のセッションのセキュリティレベルを下げないために、セッションを作成した最初の招待要求と同等または強力なメカニズムを使用して、再インバイトと更新リクエストを保護する必要があります。たとえば、最初の招待リクエストがエンドツーエンドの整合性の保護または暗号化されていた場合、その後の再インバイトと更新リクエストもそうであるはずです。
Paul Kyzivat provided useful ideas on the topics discussed in this document.
Paul Kyzivatは、このドキュメントで説明したトピックに関する有用なアイデアを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002.
[RFC3262] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における暫定応答の信頼性」、RFC 3262、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002.
[RFC3311] Rosenberg、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] Camarillo、G。およびP. Kyzivat、「セッション開始プロトコル（SIP）Preconditions Frameworkの更新」、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] Sparks、R。、「セッション開始プロトコル（SIP）非インバイトトランザクションで特定された問題に対処するアクション」、RFC 4320、2006年1月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：オファー/回答プロトコルのネットワークアドレス翻訳者（NAT）トラバーサルのプロトコル」、RFC 5245、2010年4月。
Authors' Addresses
著者のアドレス
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
ゴンザロカマリロ（編集者）エリクソンハーサランティ11ジョルバス02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 Finland
Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Christer.Holmberg@ericsson.com
Yang Gao ZTE China
ヤンガオZTEチャイナ
EMail: gao.yang2@zte.com.cn