Internet Engineering Task Force (IETF) S. Okumura
Request for Comments: 6337 Softfront
Category: Informational T. Sawada
ISSN: 2070-1721 KDDI Corporation
P. Kyzivat
August 2011
Session Initiation Protocol (SIP) Usage of the Offer/Answer Model
セッション開始プロトコル（SIP）オファー/アンサーモデルの使用方法
Abstract
抽象
The Session Initiation Protocol (SIP) utilizes the offer/answer model to establish and update multimedia sessions using the Session Description Protocol (SDP). The description of the offer/answer model in SIP is dispersed across multiple RFCs. This document summarizes all the current usages of the offer/answer model in SIP communication.
セッション開始プロトコル（SIP）はセッション記述プロトコル（SDP）を使用して、マルチメディアセッションを確立し、更新するためのオファー/アンサーモデルを利用しています。 SIPでのオファー/アンサーモデルの説明は、複数のRFCに分散されます。この文書では、SIP通信におけるオファー/アンサーモデルのすべての現在の使用状況をまとめました。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc6337.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6337で取得することができます。
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. Summary of SIP Usage of the Offer/Answer Model ..................3
2.1. Terminology ................................................3
2.2. Offer/Answer Exchange Pairs in SIP Messages ................4
2.3. Rejection of an Offer ......................................5
2.4. Session Description That Is Not an Offer or an Answer ......7
3. Detailed Discussion of the Offer/Answer Model for SIP ...........8
3.1. Offer/Answer for the INVITE method with 100rel Extension ...8
3.1.1. INVITE Request with SDP .............................8
3.1.2. INVITE Request without SDP .........................11
3.2. Offer/Answer Exchange in Early Dialog .....................12
3.3. Offer/Answer Exchange in an Established Dialog ............12
3.4. Recovering from a Failed Re-INVITE ........................13
4. Exceptional Case Handling ......................................13
4.1. Message Crossing Case Handling ............................13
4.2. Glare Case Handling .......................................18
4.3. Interworking of UPDATE and Re-INVITE ......................21
5. Content of Offers and Answers ..................................25
5.1. General Principle for Constructing Offers and Answers .....26
5.2. Choice of Media Types and Formats to Include and Exclude ..26
5.2.1. Sending an Initial INVITE with Offer ...............26
5.2.2. Responding with an Offer When the Initial
INVITE Has No Offer ................................27
5.2.3. Answering an Initial INVITE with Offer .............27
5.2.4. Answering When the Initial INVITE Had No Offer .....28
5.2.5. Subsequent Offers and Answers ......................28
5.3. Hold and Resume of Media ..................................29
5.4. Behavior on Receiving SDP with c=0.0.0.0 ..................31
6. Security Considerations ........................................31
7. Acknowledgements ...............................................31
8. References .....................................................32
8.1. Normative References ......................................32
8.2. Informative References ....................................33
SIP utilizes the offer/answer model to establish and update sessions. The rules that govern the offer/answer behaviors in SIP are described in several RFCs: [RFC3261], [RFC3262], [RFC3264], [RFC3311], and [RFC6141].
SIPは、セッションを確立し、更新するために、オファー/アンサーモデルを利用しています。 [RFC3261]、[RFC3262]、[RFC3264]、[RFC3311]、および[RFC6141]：SIPにオファー/アンサー行動を制御するルールは、いくつかのRFCに記述されています。
The primary purpose of this document is to describe all forms of SIP usage of the offer/answer model in one document to help the readers to fully understand it. Also, this document tries to incorporate the results of the discussions on the controversial issues to avoid repeating the same discussions later.
このドキュメントの主な目的は、完全にそれを理解するために読者を助けるために一つの文書でオファー/アンサーモデルのSIP利用のすべてのフォームを記述することです。また、このドキュメントは、後で同じ議論を繰り返すことを避けるために論争の問題についての議論の結果を組み込むしようとします。
This document describes ambiguities in the current specifications and the authors' understanding of the correct interpretation of these specifications. This document is not intended to make any changes to those specifications, but rather is intended to provide a reference for future standards development work on the SIP offer/answer model and to developers looking for advice on how to implement in compliance with the standards.
この文書では、現在の仕様とこれらの仕様の正しい解釈の著者の理解があいまいさを説明しています。この文書では、これらの仕様を変更することを意図していないのではなく、SIPのオファー/アンサーモデル上および基準に準拠して実装する方法についてのアドバイスを探し、開発者への将来の規格開発作業のための参照を提供することを意図しています。
The offer/answer model itself is independent from the higher layer application protocols that utilize it. SIP is one of the applications using the offer/answer model. [RFC3264] defines the offer/answer model, but does not specify which SIP messages should convey an offer or an answer. This should be defined in the SIP core and extension RFCs.
オファー/アンサーモデル自体は、それを利用上位層のアプリケーションプロトコルから独立しています。 SIPは、オファー/アンサーモデルを使用してアプリケーションの一つです。 [RFC3264]は、オファー/アンサーモデルを定義しますが、SIPメッセージを申し出たり、答えを伝えるべきかを指定しません。これは、SIPコアと拡張RFCで規定されなければなりません。
In theory, any SIP message can include a session description in its body. But a session description in a SIP message is not necessarily an offer or an answer. Only certain session description usages that conform to the rules described in Standards-Track RFCs can be interpreted as an offer or an answer. The rules for how to handle the offer/answer model are defined in several RFCs.
理論的には、任意のSIPメッセージは、その本体でのセッション記述を含めることができます。しかし、SIPメッセージ内のセッション記述は必ずしも申し出か答えではありません。標準化過程のRFCで説明したルールに準拠してのみ、特定のセッション記述の用法は、申し出または回答として解釈することができます。オファー/アンサーモデルを処理する方法のためのルールは、いくつかのRFCで定義されています。
The offer/answer model defines a mechanism for update of sessions. In SIP, a dialog is used to associate an offer/answer exchange with the session that it is to update. In other words, only the offer/ answer exchange in the SIP dialog can update the session that is managed by that dialog.
オファー/アンサーモデルは、セッションの更新のためのメカニズムを定義します。 SIPでは、ダイアログは、それが更新することであるセッションとオファー/アンサー交換を関連付けるために使用されます。言い換えれば、SIPダイアログで唯一のオファー/アンサー交換は、そのダイアログで管理されているセッションを更新することができます。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following abbreviations are used in this document.
以下の略語が本文書で使用されています。
UA: User Agent.
UA：ユーザエージェント。
UAC: User Agent Client.
UAC：ユーザエージェントクライアント。
UAS: User Agent Server.
WHO：ユーザエージェントサーバ。
SDP: Session Description Protocol [RFC4566].
SDP：セッション記述プロトコル[RFC4566]。
Currently, the rules on the offer/answer model are defined in [RFC3261], [RFC3262], [RFC3264], [RFC3311], and [RFC6141]. In these RFCs, only the six patterns shown in Table 1 are defined for exchanging an offer and an answer with SIP messages.
現在、オファー/アンサーモデル上のルールは、[RFC3261]、[RFC3262]、[RFC3264]、[RFC3311]、および[RFC6141]で定義されています。これらのRFCで、表1に示した唯一6つのパターンは、オファーとSIPメッセージとの回答を交換するために定義されています。
Note that an offer/answer exchange initiated by an INVITE request must follow exactly one of the Patterns 1, 2, 3, 4. When an initial INVITE causes multiple dialogs due to forking, an offer/answer exchange is carried out independently in each distinct dialog. When an INVITE request contains no offer, only Pattern 2 or Pattern 4 apply. According to Section 13.2.1 of [RFC3261], 'The first reliable non-failure message' must have an offer if there is no offer in the INVITE request. This means that the User Agent (UA) that receives the INVITE request without an offer must include an offer in the first reliable response with 100rel extension. If no reliable provisional response has been sent, the User Agent Server (UAS) must include an offer when sending 2xx response.
オファー/アンサー交換が初期起因分岐させる複数のダイアログをINVITE場合、INVITEリクエストが正確にパターン1の、2、3、4に従わなければならない、オファー/アンサー交換がそれぞれ別個に独立して行われることにより開始されることに注意してくださいダイアログ。 INVITEリクエストは何のオファーが含まれていない場合は、唯一のパターン2やパターン4が適用されます。 INVITEリクエストにはオファーが存在しない場合は、[RFC3261]のセクション13.2.1によると、「最初の信頼性の高い非失敗メッセージは」プランを持っている必要があります。これは提供せずに、INVITEリクエストを受信するユーザーエージェント（UA）が100rel拡張子を持つ最初の信頼性の応答における申し出を含まなければならないことを意味します。信頼できる暫定応答が送信されていない場合の2xx応答を送信するときに、ユーザエージェントサーバ（UAS）が提供を含める必要があります。
In Pattern 3, the first reliable provisional response may or may not have an answer. When a reliable provisional response contains a session description, and is the first to do so, then that session description is the answer to the offer in the INVITE request. The answer cannot be updated, and a new offer cannot be sent in a subsequent reliable response for the same INVITE transaction.
パターン3では、最初の信頼性のある暫定応答は、または答えを持っていない可能性があります。信頼性のある暫定応答は、セッション記述が含まれており、そうすることが第一である場合には、そのセッション記述は、INVITEリクエストで提供への答えです。答えは、更新することができない、との新しいオファーが同じINVITEトランザクションに対する後続の信頼性の高い応答して送信することはできません。
In Pattern 5, a Provisional Response ACKnowledgement (PRACK) request can contain an offer only if the reliable response that it acknowledges contains an answer to the previous offer/answer exchange.
それは認めていることを確実なレスポンスが前のオファー/アンサー交換への回答が含まれている場合のみ、パターン5では、暫定応答確認（PRACK）要求が提供を含めることができます。
NOTE: It is legal to have UPDATE/2xx exchanges without offer/ answer exchanges (Pattern 6). However, when re-INVITEs are sent for non-offer/answer purposes, an offer/answer exchange is required. In that case, the prior SDP will typically be repeated.
注：これは、オファー/アンサー交換（パターン6）せずにUPDATE / 2XXの交流を持つことが合法です。再のINVITEが非オファー/アンサーの目的のために送られたときしかし、オファー/アンサー交換が必要です。その場合、前SDPは、典型的に繰り返されます。
There may be ONLY ONE offer/answer negotiation in progress for a single dialog at any point in time. Section 4 explains how to ensure this. When an INVITE results in multiple dialogs, each has a separate offer/answer negotiation.
任意の時点で単一ダイアログの進行中のONLY ONEオファー/アンサーネゴシエーションがあるかもしれません。第4章では、これを保証する方法について説明します。複数のダイアログで結果をINVITEすると、それぞれが別々のオファー/アンサーネゴシエーションを持っています。
NOTE: This is when using a Content-Disposition of "session". There may be a second offer/answer negotiation in progress using a Content-Disposition of "early-session" [RFC3959]. That is not addressed by this document.
注：「セッション」のコンテンツ処分を使用する場合にこれがあります。 「早期セッション」[RFC3959]の内容-処分を使用して進行中の第二オファー/アンサーネゴシエーションがあるかもしれません。それは、このドキュメントによって対処されていません。
Offer Answer RFC Ini Est Early
-------------------------------------------------------------------
1. INVITE Req. 2xx INVITE Resp. RFC 3261 Y Y N
2. 2xx INVITE Resp. ACK Req. RFC 3261 Y Y N
3. INVITE Req. 1xx-rel INVITE Resp. RFC 3262 Y Y N
4. 1xx-rel INVITE Resp. PRACK Req. RFC 3262 Y Y N
5. PRACK Req. 200 PRACK Resp. RFC 3262 N Y Y
6. UPDATE Req. 2xx UPDATE Resp. RFC 3311 N Y Y
Table 1: Summary of SIP Usage of the Offer/Answer Model
表1：オファー/アンサーモデルのSIPの使用法の概要
In Table 1, '1xx-rel' corresponds to the reliable provisional response that contains the 100rel option defined in [RFC3262].
表1において、「1XX-REL」は[RFC3262]で定義され100relオプションが含まれている信頼できる暫定的な応答に相当します。
The 'Ini' column shows the ability to exchange the offer/answer to initiate the session. 'Y' indicates that the pattern can be used in the initial offer/answer exchange, while 'N' indicates that it cannot. Only the initial INVITE transaction can be used to exchange the offer/answer to establish a multimedia session.
「iniファイル」列には、セッションを開始するために、オファー/アンサーを交換する能力を示しています。 「N」のそれができないことを示しながら、「Y」は、パターンが最初のオファー/アンサー交換で使用することができることを示しています。唯一の初期INVITEトランザクションは、マルチメディアセッションを確立するために、オファー/アンサーを交換するために使用することができます。
The 'Est' column shows the ability to update the established session.
「エスト」列には、確立されたセッションを更新する機能を示しています。
The 'Early' column indicates which patterns may be used to modify the established session in an early dialog. There are two ways to exchange a subsequent offer/answer in an early dialog.
「早期」列は、初期のダイアログで確立されたセッションを修正するために使用することができるパターンを示しています。初期のダイアログで、その後のオファー/アンサーを交換するには、2つの方法があります。
It is not always clear how to reject an offer when it is unacceptable, and some methods do not allow explicit rejection of an offer. For each of the patterns in Table 1, Table 2 shows how to reject an offer.
受け入れられないときの申し出を拒否するか必ずしも明確ではない、といくつかの方法が提供を明示的に拒否することはできません。表1のパターンのそれぞれについて、表2は、オファーを拒否する方法を示しています。
When a UA receives an INVITE request with an unacceptable offer, it should respond with a 488 response, preferably with Warning header field indicating the reason of the rejection, unless another response code is more appropriate to reject it (Pattern 1 and Pattern 3).
UAは、許容できないオファーをINVITEリクエストを受信した場合、他のレスポンスコードが（パターン1およびパターン3）を拒否する方が適切でなければ、それは、好ましくは、拒絶の理由を示すヘッダフィールドを警告、488応答で応答すべきです。
If this is a re-INVITE, extra care must be taken, as detailed in [RFC6141]. Specifically, if the offer contains any changes or additions to media stream properties, and those have already been used to transmit/receive media before the final response is sent, then a 2xx response should be sent, with a syntactically correct session description. This may optionally be followed by an UPDATE request to rearrange the session parameters if both ends support the UPDATE method. Alternatively, the UA may send an error response to the (re-)INVITE request to terminate the dialog or to roll back the offer/answer status before sending re-INVITE request. In this case, the UAS should not continue to retransmit the unacknowledged reliable provisional response; the User Agent Client (UAC) should not continue to retransmit a PRACK request.
これがある場合は、[RFC6141]で説明するように特別な注意は、注意する必要があり、再INVITE。具体的には、オファーが、メディアストリームのプロパティを変更または追加が含まれている場合、それらが既に/送信するために使用されてきた受信最終応答が送信される前に、その後、2xx応答が構文的に正しいセッション記述と、送信されるべき媒体。これは、必要に応じて両端がUPDATEメソッドをサポートしている場合、セッション・パラメータを再配置するUPDATE要求が続いてもよいです。また、UAは（再）ダイアログを終了させるか、再INVITEリクエストを送信する前にオファー/アンサーの状態をロールバックするINVITEリクエストに対するエラー応答を送信することができます。この場合、UASは未確認の信頼性のある暫定応答を再送し続けるべきではありません。ユーザエージェントクライアント（UAC）は、PRACK要求を再送信し続けるべきではありません。
When a UA receives an UPDATE request with an offer that it cannot accept, it should respond with a 488 response, preferably with Warning header field indicating the reason of the rejection, unless another response code is more appropriate to reject it (Pattern 6).
UAは、それが受け入れることができないオファーを更新要求を受信した場合、他のレスポンスコードが（パターン6）を拒否することがより適切である場合を除き、それは、好ましくは、拒絶の理由を示すヘッダフィールドを警告、488応答で応答すべきです。
When a UA receives a PRACK request with an offer that it cannot accept, it may respond with a 200 response with a syntactically correct session description. Optionally, this may be followed by an UPDATE request to rearrange the session parameters if both ends support the UPDATE method. Alternatively, the UA may terminate the dialog and send an error response to the INVITE request (Pattern 5).
UAはそれが受け入れられないことを提供してPRACK要求を受信すると、それは構文的に正しいセッション記述と200応答で応答することができます。必要に応じて、これは両端がUPDATEメソッドをサポートしている場合、セッション・パラメータを再配置するUPDATE要求が続いてもよいです。代替的に、UAは、ダイアログを終了し、INVITEリクエスト（パターン5）にエラー応答を送信することができます。
In addition, there is a possibility for UAC to receive a 488 response for an PRACK request. In that case, UAC may send again a PRACK request without an offer or send a CANCEL request to terminate the INVITE transaction.
また、UACは、PRACK要求に対する488応答を受信するための可能性があります。その場合、UACは提供せずに再PRACK要求を送信したり、INVITEトランザクションを終了するにはCANCEL要求を送信することができます。
NOTE: In [RFC3262], the following restriction is defined with regard to responding to a PRACK request.
注：[RFC3262]は、以下の制限は、PRACK要求に応答に関して定義されます。
"If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response."
「PRACKが認められていない信頼できる暫定応答と一致しない場合、それは2xx応答で応答しなければなりません。」
This restriction is not clear. There are cases where it is unacceptable to send a 2xx response. For example, the UAS may need to send an authentication challenge in a 401 response. This is an open issue and out of scope for this document.
この制限は明らかではありません。 2xx応答を送信することは許容されない場合があります。例えば、UASは401応答で認証チャレンジを送信する必要があるかもしれません。これは、未解決の問題であり、この文書の範囲外。
When a UA receives a response with an offer that it cannot accept, the UA does not have a way to reject it explicitly. Therefore, a UA should respond to the offer with the correct session description and rearrange the session parameters by initiating a new offer/answer exchange, or alternatively terminate the session (Pattern 2 and Pattern 4). When initiating a new offer/answer, a UA should take care not to cause an infinite offer/answer loop.
UAが、それは受け入れることができないというオファーを含む応答を受信すると、UAは、明示的に拒否する方法がありません。したがって、UAは正しいセッション記述とオファーに応答して、新しいオファー/アンサー交換を開始することによってセッションパラメータを再配置、あるいはセッション（パターン2およびパターン4）を終了すべきです。新しいオファー/アンサーを開始するとき、UAは無限のオファー/アンサーループが発生しないように注意する必要があります。
Section 14.2 of [RFC3261], "UAS Behavior", states:
[RFC3261]、 "UAS行動" の14.2項、状態：
The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description.
UASは、セッション記述は、メディア形式、トランスポート、またはピアからのサポートを必要とする他のパラメータの以前のセッション記述と重なっていることを確認しなければなりません。これは、セッション記述を拒絶するピアの必要性を回避することです。
This is a rule for an offer within 2xx response to a re-INVITE. This rule should be applied to an offer within a reliable provisional response and a PRACK request.
これは、再INVITEへの2xx応答中のオファーのためのルールです。この規則は、信頼性のある暫定応答とPRACK要求の中に提供するために適用されるべきです。
Offer Rejection
------------------------------------------------------------------
1. INVITE Req. (*) 488 INVITE Response
2. 2xx INVITE Resp. Answer in ACK Req. followed by new offer
OR termination of dialog
3. INVITE Req. 488 INVITE Response (same as Pattern 1)
4. 1xx-rel INVITE Resp. Answer in PRACK Req. followed by new offer
5. PRACK Req. (**) 200 PRACK Resp. followed by new offer
OR termination of dialog
6. UPDATE Req. 488 UPDATE Response
(*) If this was a re-INVITE, a failure response should not be sent if media has already been exchanged using the new offer.
これは、INVITEを再した場合は、メディアがすでに新しいプランを使用して交換された場合（*）、失敗応答を送るべきではありません。
(**) A UA should only use PRACK to send an offer when it has strong reasons to expect the receiver will accept the offer.
（**）A UAは、それが受信機が申し出を受け入れることを期待する強い理由がある場合のオファーを送信するためにPRACKを使用する必要があります。
Table 2: Rejection of an Offer
表2：オファーの拒否
As previously stated, a session description in a SIP message is not necessarily an offer or an answer. For example, SIP can use a session description to describe capabilities apart from offer/answer exchange. Examples of this are a 200 OK response for OPTIONS and a 488 response for INVITE.
先に述べたように、SIPメッセージ内のセッション記述は、必ずしもオファーまたは答えではありません。例えば、SIPは、オファー/アンサー交換から離れて機能を記述するためにセッション記述を使用することができます。この例としては、OPTIONSとINVITEのための488応答200 OK応答です。
The INVITE method provides the basic procedure for offer/answer exchange in SIP. Without the 100rel option, the rules are simple as described in [RFC3261]. If an INVITE request includes a session description, Pattern 1 is applied and if an INVITE request does not include a session description, Pattern 2 is applied.
INVITEメソッドは、SIPにおけるオファー/アンサー交換のための基本的な手順を提供します。 [RFC3261]で説明したように100relのオプションを指定しないと、ルールは単純です。 INVITE要求は、セッション記述が含まれている場合、パターン1が適用され、セッション記述を含まないINVITE要求場合、パターン2が適用されます。
With 100rel, Patterns 3, 4, and 5 are added and this complicates the rules. An INVITE request may cause multiple responses. Note that even if both UAs support the 100rel extension, not all the provisional responses may be sent reliably.
100rel、パターン3、4、及び5を加え、これは、ルールを複雑にしています。 INVITE要求は、複数の応答を引き起こす可能性があります。両方のUAが100rel拡張をサポートしていても、すべての暫定応答が確実に送信されるとは限らないことに注意してください。
When a UAC includes an SDP body in the INVITE request as an offer, only the first SDP in a reliable non-failure response to the INVITE request is the real answer. No other offer/answer exchanges can occur within the messages (other responses and ACK) of the INVITE transaction.
UACがオファーとINVITE要求におけるSDP本体を含む場合には、INVITEリクエストに対する信頼性の高い非失敗応答でのみ最初のSDPは本当の答えです。他のオファー/アンサー交換はINVITEトランザクションのメッセージ（他の応答およびACK）内で発生することはできません。
In [RFC3261] there are some descriptions about an offer/answer exchange, but those cause a little confusion. We interpret those descriptions as follows,
[RFC3261]であっオファー/アンサー交換に関するいくつかの説明がありますが、それらは少し混乱を引き起こします。次のように我々はこれらの記述を解釈し、
UAC behavior:
UACの動作：
1. If the first SDP that the UAC received is included in an unreliable provisional response to the INVITE request, [RFC3261] (Section 13.2.1, second bullet) requires that this be treated as an answer. However, because that same section states that the answer has to be in a reliable non-failure message, this SDP is not the true answer and therefore the offer/answer exchange is not yet completed.
UACは、受信した最初のSDPをINVITEリクエストに信頼できない暫定応答に含まれている場合1は、[RFC3261]（セクション13.2.1、第二弾）がこの答えとして扱われることを必要とします。同じセクションでは、答えは信頼できる非失敗メッセージでなければならないと述べているのでしかし、このSDPは、真の答えではありませんので、オファー/アンサー交換がまだ完了していません。
2. After the UAC has received the answer in a reliable provisional response to the INVITE, [RFC3261] requires that any SDP in subsequent responses be ignored.
UACは、INVITEに信頼できる暫定的な応答で回答を受信した後2、[RFC3261]は、後続の応答における任意のSDPを無視することを必要とします。
3. If the second and subsequent SDP (including a real answer) is different from the first SDP, the UAC should consider that the SDP is equal to the first SDP. Therefore, the UAC should not switch to the new SDP.
3.（実際の回答を含む）第二及びその後のSDPは、最初のSDPと異なる場合、UACは、SDPは、SDP最初に等しいことを考慮すべきです。したがって、UACは、新しいSDPに切り替えるべきではありません。
UAS behavior:
WHOの行動：
1. [RFC3261] requires all SDP in the responses to the INVITE request to be identical.
1. [RFC3261]は同一であることがINVITE要求への応答のすべてのSDPを必要とします。
2. After the UAS has sent the answer in a reliable provisional response to the INVITE, the UAS should not include any SDPs in subsequent responses to the INVITE.
2. UASがINVITEに信頼性のある暫定応答で答えを送信した後、UASは、INVITE以降の応答でどんなのSDPを含めるべきではありません。
3. [RFC3261] permits the UAS to send any provisional response without SDP regardless of the transmission of the answer.
3. [RFC3261]は関係なく、答えの送信のSDPなし暫定応答を送信するUASを可能にします。
A session description in an unreliable response that precedes a reliable response can be considered a "preview" of the answer that will be coming.
信頼性の高い応答の前に、信頼性の低い応答のセッション記述が来るということだ答えの「プレビュー」とみなすことができます。
NOTE: This "preview" session description rule applies to a single offer/answer exchange. In parallel offer/answer exchanges (caused by forking), a UA may obviously receive a different "preview" of an answer in each dialog. UAs are expected to deal with this.
注：この「プレビュー」セッション記述ルールは、単一のオファー/アンサー交換に適用されます。 （分岐によって引き起こされる）平行オファー/アンサー交換では、UAは、明らかに、各ダイアログの回答の異なる「プレビュー」を受信してもよいです。ユーザーエージェントは、これに対処することが期待されています。
Although [RFC3261] says a UA should accept media once an INVITE with an offer has been sent, in many cases, an answer (or, at least a preview of it) is required in order for media to be accepted. Two examples of why this might be required are as follows:
[RFC3261]の申し出でINVITEを一度UAは、メディアを受け入れるべきと言うが送られてきたが、多くの場合、答え（または、それの少なくともプレビューが）受け入れられるためのメディアのために必要とされます。次のようにこれが必要になる場合があります理由の2つの例は以下のとおりです。
o To avoid receiving media from undesired sources, some User Agents assume symmetric RTP will be used, ignore all incoming media packets until an address/port has been received from the other end, and then use that address/port to filter incoming media packets.
望ましくないソースからのメディアの受信を回避するために、Oは、いくつかのユーザエージェントは、着信メディアパケットをフィルタリングするために、そのアドレス/ポートを使用して、アドレス/ポートは、もう一方の端から受信されるまで、すべての着信メディアパケットを無視し、そして、対称RTPが使用されると仮定する。
o In some networks, an intermediate node must authorize a media stream before it can flow and requires a confirming answer to the offer before doing so.
それはそうする前に提供することを確認した答えを流れ、必要とする前に、O一部のネットワークでは、中間ノードは、メディアストリームを許可する必要があります。
Therefore, a UAS should send an SDP answer reliably (if possible) before it starts sending media. And, if neither the UAC nor the UAS support 100rel, the UAS should send a preview of the answer before it starts sending media.
それがメディアの送信を開始する前に、したがって、UASは（可能ならば）確実にSDP回答を送信する必要があります。それがメディアの送信を開始する前に、UACやUASのサポート100relもない場合、UASは、答えのプレビューを送信する必要があります。
UAC UAS
| F1 INVITE (SDP) | <- The offer in the offer/answer model.
|-------------------->|
| F2 1xx (SDP) | <- The offer/answer exchange is not
|<--------------------| closed yet, but UAC acts as if it
| | ^ receives the answer.
| F3 1xx-rel (no SDP) | |<- a 1xx-rel may be sent without answer
|<--------------------| | SDP.
| F4 PRACK (no SDP) | |
|-------------------->| | The UAC must not send a new offer.
| F5 2xx PRA (no SDP) | |
|<--------------------| v
| |
| F6 1xx-rel (SDP) | <- The answer in the offer/ answer model.
|<--------------------| -
| F7 PRACK | | The UAC can send a new offer in a PRACK
|-------------------->| | request to acknowledge F6.
| F8 2xx PRA | | After F7, the UAC and UAS can send a new
|<--------------------| v offer in an UPDATE request.
| |
| F9 1xx-rel | <- SDP should not be included in the
|<--------------------| subsequent 1xx-rel once offer/answer
| F10 PRACK | has been completed.
|-------------------->|
| F11 2xx PRA |
|<--------------------|
| |
| F12 2xx INV | <- SDP should not be included in the
|<--------------------| final response once offer/answer has
| F13 ACK | been completed.
|-------------------->|
Figure 1: Example of Offer/Answer with 100rel Extension (1)
図1：100rel拡張子のオファー/アンサーの実施例（1）
For example, in Figure 1, only the SDP in F6 is the answer. The SDP in the non-reliable response (F2) is the preview of the answer and must be the same as the answer in F6. Receiving F2, the UAC should act as if it receives the answer. However, offer/answer exchange is not completed yet and the UAC must not send a new offer until it receives the same SDP in a reliable non-failure response, which is the real answer. After sending the SDP in F6, the UAS must prepare to receive a new offer from the UAC in a PRACK request or in an UPDATE request if the UAS supports UPDATE.
例えば、図1において、F6にのみSDPは答えです。非信頼性の応答におけるSDP（F2）は、答えのプレビューであり、F6で回答と同じでなければなりません。それが答えを受け取るかのようにF2を受け、UACは行動しなければなりません。しかし、オファー/アンサー交換がまだ完了していないと、それは本当の答えである信頼性の高い非失敗応答、同じSDPを受信するまでUACは、新しいプランを送信してはなりません。 F6でSDPを送信した後、UASは、UASはUPDATEをサポートしている場合PRACK要求または更新要求にUACからの新しい提供を受けるために準備する必要があります。
The UAS does not include SDP in responses F9 and F12. However, the UAC should prepare to receive SDP bodies in F9 and/or F12, and just ignore them, to handle a peer that does not conform to the recommended implementation.
UASは応答F9とF12にSDPが含まれていません。しかし、UACは、F9および/またはF12にSDP体を受け取るために準備しなければならない、とだけ推奨実装に準拠していないピアを処理するために、それらを無視します。
When a UAC does not include an SDP body in the INVITE request, [RFC3261] (Section 13.2.1, first bullet) requires that the UAS include an offer in the first reliable non-failure response. However, a UAC might not expect an SDP in the other responses to the INVITE request because RFC 3261 simply does not anticipate the possibility. Therefore, the UAS ought not include any SDP in the other responses to the INVITE request.
UACは、INVITE要求にSDP本体が含まれていない場合、[RFC3261]（セクション13.2.1、第一弾）は、UASが最初の信頼できる非失敗応答してオファーを含めることを必要とします。 RFC 3261は、単に可能性を予想していないので、しかし、UACは、INVITEリクエストに対する他の応答にSDPを期待していない可能性があります。したがって、UASは、INVITEリクエストに対する他の応答の任意のSDPを含んでいないはずです。
NOTE: In Figure 2, the UAS should not include SDP in the responses F6 and F9. However, the UAC should prepare to receive SDP bodies in F6 and/or F9, and just ignore them to handle a peer that does not conform to the recommended implementation.
注：図2では、UASは応答F6とF9にSDPを含めるべきではありません。しかし、UACはF6および/またはF9でSDP体を受け取るために準備しなければならない、とだけ推奨実装に準拠していないピアを処理するためにそれらを無視します。
UAC UAS
| F1 INVITE (no SDP) |
|-------------------->|
| F2 1xx |
|<--------------------|
| |
| F3 1xx-rel (SDP) | <- The first 1xx-rel must contain SDP
|<--------------------| as the offer.
| F4 PRACK (SDP) | <- A PRACK request to the first 1xx-rel
|-------------------->| must contain SDP as the answer.
| F5 2xx PRA (no SDP) | -
|<--------------------| |
| | |
| F6 1xx-rel (no SDP) | <- The subsequent 1xx-rel should not
|<--------------------| | contain SDP.
| F7 PRACK | |
|-------------------->| | The UAC can send a new offer in an UPDATE
| F8 2xx PRA | | request after F4.
|<--------------------| v
| |
| F9 2xx INV (no SDP) | <- The final response should not
|<--------------------| contain SDP.
| F10 ACK |
|-------------------->|
Figure 2: Example of Offer/Answer with 100rel Extension (2)
図2：100rel拡張子のオファー/アンサーの実施例（2）
Note that in the case that the UAC needs to prompt the user to accept or reject the offer, the reliable provisional response with SDP as an offer (Pattern 4) can result in the retransmission until the PRACK request can be sent. The UAC should take care to avoid this situation when it sends the INVITE request without SDP.
PRACK要求を送ることができるまで、UACが申し出を受け入れるか拒否するようにユーザに促す必要がある場合に、特典（パターン4）のようなSDPとの信頼できる暫定的な応答は再送をもたらすことができることに留意されたいです。それはSDPのないINVITEリクエストを送信するときにUACは、このような状況を回避するために世話をする必要があります。
When both UAs support the 100rel extension, they can update the session in the early dialog once the first offer/answer exchange has been completed.
両方のUAが100rel拡張をサポートする場合は最初のオファー/アンサー交換が完了した後、彼らは初期のダイアログでセッションを更新することができます。
From a UA sending an INVITE request:
UAからのINVITEリクエストを送信します：
A UA can send an UPDATE request with a new offer if both ends support the UPDATE method. Note that if the UAS needs to prompt the user to accept or reject the offer, the delay can result in retransmission of the UPDATE request.
両端がUPDATEメソッドをサポートしている場合、UAは、新しい提供してUPDATEリクエストを送信することができます。 UASは申し出を受け入れるか拒否するように促す必要がある場合、遅延はUPDATE要求の再送信につながることに注意してください。
A UA can send a PRACK request with a new offer only when acknowledging the reliable provisional response carrying the answer to an offer in the INVITE request. Compared to using the UPDATE method, using PRACK can reduce the number of messages exchanged between the UAs. However, to avoid problems or delays caused by PRACK offer rejection, the UA is recommended to send a PRACK request only when it has strong reasons to expect the receiver will accept it. For example, the procedure used in precondition extension [RFC3312] is a case where a PRACK request should be used for updating the session status in an early dialog. Note also that if a UAS needs to prompt the user to accept or reject the offer, the delay can result in retransmission of the PRACK request.
INVITEリクエストに提供するために答えを運んで信頼性のある暫定応答を認めた場合にのみUAは、新たなオファーをPRACK要求を送ることができます。 UPDATEメソッドを使用する場合に比べ、PRACKを使用することのUA間で交換されるメッセージの数を減らすことができます。しかし、PRACKオファー拒否に起因する問題や遅延を回避するために、UAは、受信機がそれを受け入れることを期待する強い理由がある場合のみPRACK要求を送信することをお勧めします。例えば、前提条件拡張[RFC3312]で使用される手順は、PRACK要求が初期ダイアログのセッション状態を更新するために使用されなければならない場合です。 UASが受け入れるかのオファーを拒否するようユーザーに促すために必要がある場合、遅延はPRACK要求の再送信につながることができることにも注意してください。
From a UA receiving an INVITE request:
UAからのINVITEリクエストを受信：
A UA can send an UPDATE request with a new offer if both ends support the UPDATE method. A UAS cannot send a new offer in the reliable provisional response, so the UPDATE method is the only method for a UAS to update an early session.
両端がUPDATEメソッドをサポートしている場合、UAは、新しい提供してUPDATEリクエストを送信することができます。 UPDATEメソッドは、早期セッションを更新するUASのための唯一の方法であるので、UASは、信頼性のある暫定応答で新しいプランを送信することはできません。
Both the re-INVITE and UPDATE methods can be used in an established dialog to update the session.
再INVITEおよびUPDATEメソッドの両方のセッションを更新するために確立されたダイアログで使用することができます。
The UPDATE method is simpler and can save at least one message compared with the INVITE method. But both ends must support the UPDATE method for it to be used.
UPDATEメソッドは簡単であり、INVITEメソッドと比較して、少なくとも1つのメッセージを保存することができます。しかし、両端は、それが使用されるためにUPDATEメソッドをサポートしている必要があります。
The INVITE method needs at least three messages to complete but no extensions are needed. Additionally, the INVITE method allows the peer to take time to decide whether or not it will accept a session update by sending provisional responses. That is, re-INVITE allows the UAS to interact with the user at the peer, while UPDATE needs to be answered automatically by the UAS. It is noted that re-INVITE should be answered immediately unless such a user interaction is needed. Otherwise, some Third Party Call Control (3PCC) [RFC3725] flows will break.
INVITEメソッドは、完了するまでに、少なくとも3つのメッセージを必要としますが、何の拡張は必要ありません。また、INVITEメソッドは、ピアは、それが暫定応答を送信することで、セッション更新を受け入れるかどうかを決定するために時間を取ることができます。それは再INVITE、あるUPDATEがUASによって自動的に応答する必要がありながら、UASは、ピアでユーザーと対話することができます。このようなユーザーとの対話が必要とされない限り、再INVITEはすぐに答えられる必要があることに留意されたいです。そうしないと、一部のサードパーティの呼制御（3PCC）[RFC3725]は解除されます流れています。
Section 14.1 of [RFC3261] requires that the session parameters in effect prior to a re-INVITE remain unchanged if the re-INVITE fails, as if no re-INVITE had been issued. This remains the case even if multiple offer/answer exchanges have occurred between the sending of the re-INVITE and its failure, and even if media has been exchanged using the proposed changes in the session. Because this can be difficult to achieve in practice, a newer specification [RFC6141] recommends the UAS to send a 2xx response to a re-INVITE in cases where rolling back changes would be problematic.
[RFC3261]のセクション14.1には、再INVITE失敗した場合に発行されたいかなる再INVITEないかのように有効なセッションパラメータは、前の再INVITEには、変わらないままであることが必要です。これは、複数のオファー/アンサー交換は再INVITEとその失敗の送信、およびメディアセッションで提案された変更を使用して交換された場合でも間で発生した場合でも、ケースのまま。これは実際に達成するのが難しい可能性があるため、新しい仕様[RFC6141]は、変更をロールバックすることは問題となる場合には、INVITEの再に2xx応答を送信するためにUASを推奨しています。
Nevertheless, a UAC may receive a failure response to a re-INVITE after proposed changes that must be rolled back have already been used. In such a case, the UAC should send an UPDATE offering the SDP that has been reinstated. (See [RFC6141] for details.)
それにもかかわらず、UACはロールバックされなければならない提案された変更が既に使用された後の再INVITEに失敗応答を受け取ることができます。このような場合には、UACは、回復されたSDPを提供UPDATEを送信しなければなりません。 （詳細については[RFC6141]を参照）。
In [RFC3264], the following restrictions are defined with regard to sending a new offer.
[RFC3264]で、次のような制限は、新しいプランをご送付に関して定義されています。
At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or rejected. Furthermore, it MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection.
任意の時点で、いずれかの薬剤は、セッションを更新し、新たなプランを生成してもよいです。それはそれはまだ答えまたは拒否していないのオファーを受けている場合しかし、それは新しいプランを生成してはなりません。それはそれはまだ答えまたは拒否を受けなかったため前のオファーを生成した場合はさらに、それは新しいプランを生成してはなりません。
Assuming that the above rules are guaranteed, there seem to be two possible 'exceptional' cases to be considered in SIP offer/answer usage: the 'message crossing' case and the 'glare' case. One of the reasons why the usage of SIP methods to exchange offer/answer needs to be carefully restricted in the RFCs is to ensure that the UA can detect and handle appropriately the 'exceptional' cases to avoid incompatible behavior.
「メッセージの交差点」ケースと「グレア」の場合：上記のルールが保証されていると仮定すると、SIPオファー/アンサーの使用で考慮される2つの可能性「例外」例があるように思われます。オファー/アンサーを交換するSIPメソッドの使用は慎重にRFCで制限する必要がある理由の一つは、UAは、互換性のない動作を回避するために、適切に「例外」ケースを検出して処理できるようにすることです。
When message packets cross in the transport network, an offer may be received before the answer for the previous offer/answer exchange, as shown in Figure 3. In such a case, UA A must detect that the session description SDP-2 is not the answer to offer1.
メッセージ・パケットは、トランスポートネットワーク内で交差するとき、このような場合には、図3に示すように、オファーは、以前のオファー/アンサー交換に回答する前に受信されてもよい、UA Aは、セッション記述SDP-2ではないことを検出しなければなりませんoffer1に答えます。
A B
|SDP-1 (offer1)|
M1 |----------------->|
|SDP-2 (answer1)|
M2 |<------\ /-------|
| \/ |
|SDP-3 /\(offer2)|
M3 |<------/ \-------|
Figure 3: Message Crossing Case
図3：メッセージクロッシングケース
Because of the restrictions on placement of offers and answers (summarized in Table 1), there are a limited number of valid exchanges of messages that may lead to this message crossing case. These are enumerated in Table 3. (This table only shows messages containing offers or answers. There could be other messages, without session descriptions, which are not shown.)
そのため（表1にまとめた）オファーとアンサーの配置上の制約により、このメッセージの交差点ケースにつながる可能性のあるメッセージの有効な交換の数は限られています。これらは、表3に列挙されている（この表は唯一オファーや解答を含むメッセージが表示されます。示されていないセッション記述、なしで、他のメッセージがあるかもしれません。）
When a response to an UPDATE request crosses a reliable response to an INVITE request, there are variants shown in Figures 4 and 5, which are dependent on an INVITE (Mx) that contains no offer. These are also included in Table 3.
UPDATE要求への応答は、INVITE要求に信頼性の高い応答を横切るときに、何のオファーを含まないことINVITE（MX）に依存している。図4及び5に示されている変異体、があります。これらはまた、表3に含まれています。
A B
| |
|UPDATE(offer1) |
M1 |==============================>|
|re-INVITE(no offer) |
Mx |------------------------------>| --+
| 2xx-UPD(answer1)| |
M2 |<===========\ /===============| | first reliable
| \/ 1xx-rel/2xx-INV| | response
| /\ (offer2)| |
M3 |<===========/ \===============| <-+
|PRACK/ACK(answer2) |
My |------------------------------>|
| |
Figure 4: Avoidable Message Crossing Cases
図4：回避可能なメッセージクロッシングケース
To avoid the message crossing condition shown in Figure 4, UA A should not send this re-INVITE request until an UPDATE transaction has been completed. If UA B encounters this message crossing condition, it should reject this re-INVITE request with a 500 response.
UPDATEトランザクションが完了するまで、図4に示すメッセージ交差条件を回避するために、UA Aは、この再INVITEリクエストを送るべきではありません。 UA Bは、このメッセージの交差条件が発生した場合、それは500応答とこの再INVITE要求を拒絶すべきです。
A B
| |
|re-INVITE(no offer) |
Mx |------------------------------>| --+
|UPDATE(offer1) | |
M1 |==============================>| |
| 2xx-UPD(answer1)| |
M2 |<===========\ /===============| | first reliable
| \/ 1xx-rel/2xx-INV| | response
| /\ (offer2)| |
M3 |<===========/ \===============| <-+
|PRACK/ACK(answer2) |
My |------------------------------>|
| |
Figure 5: Avoidable Message Crossing Cases
図5：回避可能なメッセージクロッシングケース
To avoid the message crossing condition shown in Figure 5, UA A should not send this UPDATE request until an ACK or a PRACK transaction associated with an offer/answer has been completed. If UA B encounters this message crossing condition, it should reject this UPDATE request with a 500 response.
オファー/アンサーに関連付けられたACKまたはPRACKトランザクションが完了するまで、図5に示すメッセージ交差条件を回避するために、UA Aは、このUPDATE要求を送信するべきではありません。 UA Bは、このメッセージの交差条件が発生した場合、それは500応答と、このUPDATE要求を拒否すべきです。
The situation when a PRACK request crosses UPDATE request is shown in Figure 6.
PRACK要求が更新要求を横切る状況が図6に示されています。
A B
| |
| re-INVITE (no offer)|
1st reliable+-- |<------------------------------|
response | M1|1xx-rel(offer1) |
+-> |==============================>| --+
| PRACK(answer1)| M3| Acknowledge
|<===========\ /===============| <-+
| \/ |
| /\ UPDATE(offer2)|
|<===========/ \===============| M2
|500-UPD |
|------------------------------>|
|2xx-PRA |
|------------------------------>|
| |
Figure 6: Avoidable Message Crossing Cases
図6：回避可能なメッセージクロッシングケース
To avoid the message crossing condition shown in Figure 6, UA B should not send this UPDATE request until a PRACK transaction associated with an offer/answer has been completed. If UA A encounters this message crossing condition, it should reject this UPDATE request with a 500 response.
オファー/アンサーに関連付けられているPRACKトランザクションが完了するまで、図6に示すメッセージ交差条件を回避するために、UA Bは、このUPDATE要求を送信するべきではありません。 UA Aは、このメッセージの交差条件が発生した場合、それは500応答と、このUPDATE要求を拒否すべきです。
The situation when a reliable provisional response to an INVITE request crosses UPDATE request is shown in Figure 7.
INVITE要求への信頼できる暫定的な応答はUPDATE要求を横切る状況が図7に示されています。
A B
| |
|re-INVITE(offer1) |
M1 |==============================>|
| 1xx-rel(answer1)|
|<===========\ /===============| M3
| \/ |
| /\ UPDATE(offer2)|
+-- |<===========/ \===============| M2
| |491-UPD |
Acknowledge | |------------------------------>|
| |PRACK |
+-> |------------------------------>|
| |
Figure 7: Avoidable Message Crossing Cases
図7：回避可能なメッセージクロッシングケース
To avoid the message crossing condition shown in Figure 7, UA B should not send this UPDATE request until a PRACK transaction associated with an offer/answer has been completed. If UA A encounters this message crossing condition, it should reject this UPDATE request with a 491 response.
オファー/アンサーに関連付けられているPRACKトランザクションが完了するまで、図7に示すメッセージ交差条件を回避するために、UA Bは、このUPDATE要求を送信するべきではありません。 UA Aは、このメッセージの交差条件が発生した場合、それは491応答で、このUPDATE要求を拒否しなければなりません。
The situation when a 2xx response to an INVITE request crosses UPDATE request is shown in Figure 8.
INVITEリクエストに対する2xx応答は、更新要求を横切る状況が図8に示されています。
A B
| |
|re-INVITE(offer1) |
|==============================>|
| 2xx-INV(answer1)|
|<===========\ /===============|
| \/ |
| /\ UPDATE(offer2)|
+-- |<===========/ \===============|
| |491-UPD |
Acknowledge | |------------------------------>|
| |ACK |
+-> |------------------------------>|
| |
Figure 8: Avoidable Message Crossing Cases
図8：回避可能なメッセージクロッシングケース
This is a true glare. To avoid the message crossing condition shown in Figure 8, UA B should not send the UPDATE request until it has received an ACK request. But there is no problem even if UA B sends it. If UA A encounters this message crossing condition, it should reject this UPDATE request with a 491 response.
これが本当のグレアです。それはACK要求を受信するまで、図8に示すメッセージ交差条件を回避するために、UA Bは、更新要求を送信してはなりません。しかし、UA Bがそれを送信しても問題はありません。 UA Aは、このメッセージの交差条件が発生した場合、それは491応答で、このUPDATE要求を拒否しなければなりません。
The situation when a response to an UPDATE request crosses a PRACK request is shown in Figure 9.
UPDATE要求への応答は、PRACK要求を横切る状況が図9に示されています。
A B
| |
| re-INVITE(offer0)|
|<------------------------------|
|1xx-rel(answer0) |
|------------------------------>| --+
|UPDATE(offer1) | |
M1 |==============================>| |
| 2xx-UPD(answer1)| | Acknowledge
|<===========\ /===============| M3|
| \/ | |
| /\ PRACK(offer2)| M2|
|<===========/ \===============| <-+
| |
Figure 9: Avoidable Message Crossing Case
図9：回避可能なメッセージクロッシングケース
To avoid the message crossing condition shown in Figure 9, UA A should not send this UPDATE request until a PRACK transaction associated with an offer/answer has been completed. If UA B encounters this message crossing condition, it should reject this UPDATE request with a 491 response.
オファー/アンサーに関連付けられているPRACKトランザクションが完了するまで、図9に示すメッセージ交差条件を回避するために、UA Aは、このUPDATE要求を送信するべきではありません。 UA Bは、このメッセージの交差条件が発生した場合、それは491応答と、このUPDATE要求を拒否すべきです。
Table 3 summarizes this section. Each action is described in Section 4.3.
表3は、このセクションをまとめたものです。各アクションは、セクション4.3に記載されています。
| M1 | M3 | M2 |Action |Action |Figure|
|(offer1)|(answer1) |(offer2) | of A | of B | |
+--------+----------+-----------+-------+-------+------+
| UPDATE | 2xx-UPD | UPDATE |UAS-UcU| | |
| | +-----------+-------+ - | |
| | | INVITE |UAS-UcI| | |
| | +-----------+-------+-------+------+
| | | 1xx-INV | | | |
| | +-----------+UAC-UI,|UAS-UsI| 4,5 |
| | | 2xx-INV |UAC-IU |UAS-IsU| |
| | +-----------+-------+-------+------+
| | | PRACK (*)|UAC-IU |UAS-IcU| 9 |
+--------+----------+-----------+-------+-------+------+
| PRACK | 2xx-PRA | UPDATE |UAS-IcU| | |
+--------+----------+-----------+-------+ | |
| 2xx-INV| ACK | UPDATE |UAS-IsU| - | |
| | +-----------+-------+ | |
| | | INVITE |UAS-IsI| | |
+--------+----------+-----------+-------+-------+------+
| 1xx-rel| PRACK | UPDATE |UAS-IsU| | 6 |
+--------+----------+-----------+-------+UAC-IU +------+
| INVITE | 1xx-rel | UPDATE (*)| | | 7 |
| +----------+-----------+UAS-IcU+-------+------+
| | 2xx-INV | UPDATE (*)| | - | 8 |
+--------+----------+-----------+-------+-------+------+
(*) invalid sequences if INVITE request is an initial one
Table 3: Offer/Answer Crossing Message Sequences
表3：オファー/クロッシングメッセージシーケンス回答
When both ends in a dialog send a new offer at nearly the same time, as described in Figure 10, a UA may receive a new offer before it receives the answer to the offer it sent. This case is usually called a 'glare' case.
ダイアログの両端がほぼ同時に新しいプランを送信すると、それが送られたの申し出に対する回答を受け取る前に、図10で説明したように、UAは、新たな提供を受けることがあります。この場合は通常、「グレア」ケースと呼ばれています。
A B
|offer1 offer2|
M1 |-------\ /-------| M2
| \/ |
| /\ |
|<------/ \------>|
Figure 10: Glare Case
図10：グレアケース
When offer2 is in an UPDATE request or (re-)INVITE request, it must be rejected with a 491 or 500 response.
offer2はUPDATE要求または（再）INVITEリクエストである場合には、491または500応答で拒否されなければなりません。
There is a variant of Figure 7. When offer2 is in a PRACK request (within the current rules, only possible if offer1 is in an UPDATE request), as shown in Figure 11, UA A has a dilemma.
図7の変形offer2がPRACK要求である（唯一の可能な現在のルール、内offer1はUPDATE要求である場合）がある。図11に示すように、UA Aはジレンマを有しています。
A B
| |
| re-INVITE(offer0)|
|<------------------------------|
|1xx-rel(answer0) |
|------------------------------>| --+
|UPDATE(offer1) PRACK(offer2)| M2| Acknowledge
M1 |============\ /===============| <-+
| \/ |
| /\ |
|<===========/ \==============>|
| 491-UPD|
|<------------------------------|
| |
Figure 11: Avoidable Glare Case
図11：回避可能グレアケース
All PRACKs are supposed to be accepted with a 200 response, yet there is no way to indicate the problem with a 200 response. At best, it could proceed on the assumption that the UPDATE will be rejected with a 491. To avoid the glare condition shown in Figure 11, UA A should not send this UPDATE request until a PRACK transaction associated with an offer/answer has been completed. If UA B encounters this glare condition, it should reject this UPDATE request with a 491 response.
すべてのPRACKsは200応答で受け入れられるようになって、まだ200応答に問題があることを示す方法はありませんされています。せいぜい、それはUPDATEが、図11に示すグレア状態を回避するために491で拒否されることを前提に進めることができオファー/アンサーに関連付けられているPRACKトランザクションが完了するまで、UA Aは、このUPDATE要求を送信するべきではありません。 UA Bはこのグレア状態が発生した場合、それは491応答で、このUPDATE要求を拒否しなければなりません。
Glare can also occur when offer2 is in a 1xx or 2xx response. This is a variant of Figure 5, as shown in Figure 12.
offer2が1XXまたは2XX応答のときにグレアが発生することもあります。図12に示すように、これは、図5の変異体です。
A B
| |
|re-INVITE(no offer) |
|------------------------------>| --+
| 1xx-rel/2xx-INV| | 1st reliable
|UPDATE(offer1) (offer2)| M2| response
M1 |============\ /===============| <-+
| \/ |
| /\ |
|<===========/ \==============>|
| 500-UPD|
|<------------------------------|
| |
Figure 12: Avoidable Glare Case
図12：回避可能グレアケース
To avoid the glare condition shown in Figure 12, UA A should not send this UPDATE request until an ACK or a PRACK transaction associated with an offer/answer has been completed. If UA B encounters this glare condition, it should reject this UPDATE request with a 500 response.
オファー/アンサーに関連付けられたACKまたはPRACKトランザクションが完了するまで、図12に示すグレア状態を回避するために、UA Aは、このUPDATE要求を送信するべきではありません。 UA Bこのグレア状態に遭遇した場合、それは500応答と、このUPDATE要求を拒否すべきです。
There is a variant of Figure 4, as shown in Figure 13.
図13に示すように、図4の変形例があります。
A B
| |
|UPDATE(offer1) |
|==========\ |
|re-INVITE \ (no offer) |
|------------\----------------->| --+
| \ 1xx-rel/2xx-INV| | 1st reliable
| \ (offer2)| | response
|<==============\===============| <-+
| \ |
| \============>|
| 500-UPD|
|<------------------------------|
| |
Figure 13: Avoidable Glare Case
図13：回避可能グレアケース
To avoid the glare condition shown in Figure 13, UA A should not send this re-INVITE request until an UPDATE transaction has been completed. If UA B encounters this glare condition, it should reject this UPDATE request with a 500 response.
UPDATEトランザクションが完了するまで、図13に示すグレア状態を回避するために、UA Aは、この再INVITEリクエストを送るべきではありません。 UA Bこのグレア状態に遭遇した場合、それは500応答と、このUPDATE要求を拒否すべきです。
Table 4 summarizes this section. Each action is described in Section 4.3.
表4は、このセクションをまとめたものです。各アクションは、セクション4.3に記載されています。
| offer1 | offer2 |Action |Action |Figure|
| M1 | M2 | of A | of B | |
+-----------+-----------+-------+-------+------+
| | re-INVITE |UAS-IcI|UAS-IcI| |
| re-INVITE +-----------+-------+-------+ |
| | UPDATE |UAS-IcU|UAS-UcI| |
+-----------+-----------+-------+-------+ |
| | UPDATE |UAS-UcU|UAS-UcU| |
| +-----------+-------+-------+------+
| | 1xx-rel | | | |
| UPDATE +-----------+UAC-IU,|UAS-IsU|12,13 |
| | 2xx-INV |UAC-UI | | |
| +-----------+-------+-------+------+
| | PRACK (*) |UAC-IU |UAS-IcU| 11 |
+-----------+-----------+-------+-------+------+
(*) invalid sequences if INVITE request is an initial one
Table 4: Offer/Answer Glare Message Sequences
表4：オファー/回答グレアのメッセージシーケンス
Almost all exceptional cases are caused by an interworking of UPDATE and re-INVITE. The interworking is described in Section 5 of [RFC3311]. And UAC behavior sending an UPDATE is described in Section 5.1 of [RFC3311]. There are two concerns in this section:
ほとんどすべての例外的なケースは、UPDATEとのインターワーキングによって引き起こされる再INVITE。インターワーキングは、[RFC3311]のセクション5に記載されています。そしてUPDATEを送信してUACの動作は、[RFC3311]のセクション5.1に記載されています。このセクションの2つの懸念があります。
1. It seems to describe different rules for each of initial INVITE and re-INVITE. But there is no particular reason why the rules are separated. The lack of restrictions for sending a re-INVITE request cause a lot of problems shown in Section 4.1.
1.これは、初期のそれぞれに異なるルールを記述しているようだINVITEと再INVITE。しかし、ルールが分離されている理由は、特に理由はありません。再INVITE要求の原因に4.1節で示した問題の多くを送信するための制約の欠如。
2. It seems to describe that a UA may send an UPDATE request after sending or receiving a PRACK request. But it should be "after PRACK transaction is completed by 2xx response", because it causes the message-crossing case shown in Figure 6.
2. UAがPRACK要求を送信または受信した後にUPDATE要求を送信することを説明しているようです。それは、図6に示すメッセージクロッシングケースが発生するため、「PRACKトランザクションが2XX応答によって完成された後、」しかし、それはする必要があります。
Since it is assumed that the language in this section itself is non-normative and is justified as a corollary of [RFC3261], we interpret it as follows:
このセクション自体で言語は非規範的であると[RFC3261]の当然の帰結として正当化されることが想定されているので、以下のように、我々はそれを解釈します：
UAC-II: While an INVITE transaction is incomplete or ACK transaction associated with an offer/answer is incomplete, a UA must not send another INVITE request.
UAC-II：オファー/アンサーに関連した不完全またはACKトランザクションが不完全なさINVITEトランザクションが、UAは別のINVITEリクエストを送信してはなりません。
UAC-UU: While an UPDATE transaction is incomplete, a UA must not send another UPDATE request.
UAC-UU：UPDATEトランザクションが不完全ですが、UAは、別の更新要求を送信してはなりません。
UAC-UI: While an UPDATE transaction is incomplete, a UA should not send a re-INVITE request.
UAC-UI：UPDATEトランザクションが不完全ですが、UAは再INVITEリクエストを送るべきではありません。
UAC-IU: While an INVITE transaction is incomplete, and an ACK or a PRACK transaction associated with an offer/answer is incomplete, a UA should not send an UPDATE request.
UAC-IU：INVITEトランザクションが不完全である、とオファー/アンサーに関連付けられたACKまたはPRACKトランザクションが不完全ですが、UAは、UPDATEリクエストを送るべきではありません。
When a 2xx response to an INVITE includes an offer, the ACK transaction is considered to be associated with an offer/answer.
INVITEに対する2xx応答を提示申し出を含む場合、ACKトランザクションは、オファー/アンサーに関連していると考えられています。
When a reliable provisional response to an INVITE includes an offer or an answer, the PRACK transaction is considered to be associated with an offer/answer.
INVITEに信頼性のある暫定応答を提供または回答が含まれている場合、PRACKトランザクションは、オファー/アンサーに関連していると考えられています。
UAS behavior receiving an UPDATE is described in Section 5.2 of [RFC3311]. There are two concerns in this section:
UPDATEを受信するUASの動作は、[RFC3311]のセクション5.2に記載されています。このセクションの2つの懸念があります。
1. There is no description about the interworking of an UPDATE request and an INVITE request without an offer.
1. UPDATE要求と提供せずにINVITE要求のインターワーキングについての記載はありません。
2. There is no description about the interworking of an UPDATE request and reliable response to an INVITE with an offer.
2. UPDATE要求と提供してINVITEに信頼性の高い応答のインターワーキングについての記載はありません。
We interpret this section as follows:
次のように私たちは、このセクションを解釈します：
UAS-IcI: While an INVITE client transaction is incomplete or ACK transaction associated with an offer/answer is incomplete, a UA must reject another INVITE request with a 491 response.
UAS-ICI：INVITEクライアントトランザクションは、オファー/アンサーに関連した不完全またはACKトランザクションが不完全なされている間、UAは、別の491応答でINVITEリクエストを拒否しなければなりません。
UAS-IsI: While an INVITE server transaction is incomplete or ACK transaction associated with an offer/answer is incomplete, a UA must reject another INVITE request with a 500 response.
UAS-ISI：オファー/アンサーに関連付けられているサーバーのトランザクションがあるINVITE不完全またはACKトランザクションが不完全ですが、UAは、別の500応答でINVITEリクエストを拒否しなければなりません。
UAS-UcU: While an UPDATE client transaction is incomplete, a UA must reject another UPDATE request with a 491 response.
UAS-UCU：UPDATEクライアントトランザクションが不完全ですが、UAは491応答で別の更新要求を拒否しなければなりません。
UAS-UsU: While an UPDATE server transaction is incomplete, a UA must reject another UPDATE request with a 500 response.
UAS-USU：UPDATEサーバーのトランザクションが不完全ですが、UAは500応答で別の更新要求を拒否しなければなりません。
UAS-UcI: While an UPDATE client transaction is incomplete, a UA should reject a re-INVITE request with a 491 response.
UAS-UCI：UPDATEクライアントトランザクションが不完全ですが、UAは491応答で再INVITEリクエストを拒否すべきです。
UAS-UsI: While an UPDATE server transaction is incomplete, a UA should reject a re-INVITE request with a 500 response.
UAS-USI：UPDATEサーバーのトランザクションが不完全ですが、UAは500応答で再INVITEリクエストを拒否すべきです。
UAS-IcU: While an INVITE client transaction is incomplete, and an ACK or a PRACK transaction associated with an offer/answer is incomplete, a UA should reject an UPDATE request with a 491 response.
UAS-ICU：INVITEクライアントトランザクションが不完全である、とオファー/アンサーに関連付けられたACKまたはPRACKトランザクションが不完全ですが、UAは491応答でUPDATE要求を拒否しなければなりません。
UAS-IsU: While an INVITE server transaction is incomplete, and an ACK or a PRACK transaction associated with an offer/answer is incomplete, a UA should reject an UPDATE request with a 500 response.
UAS-ISU：INVITEサーバートランザクションが不完全である、とオファー/アンサーに関連付けられたACKまたはPRACKトランザクションが不完全ですが、UAは500応答でUPDATE要求を拒否しなければなりません。
These rules are shown in following figures.
これらのルールは、図を以下に示します。
A B
| |
| UPDATE|
|<------------------------------|
|UPDATE |
|==============================>|
| 491|
|<==============================|
| |
Figure 14: Example of UAC-UU and UAS-UcU
図14：UAC-UUとUAS-UCUの例
A B
| |
|UPDATE CSeq:m |
|------------------------------>|
|UPDATE CSeq:n(>m) |
|==============================>|
| 500 (UPDATE CSeq:n)|
|<==============================|
| |
Figure 15: Example of UAC-UU and UAS-UsU
図15：UAC-UUとUAS-USUの例
A B
| |
| UPDATE(offer1)|
|<------------------------------|
|reINVITE(no offer) |
|==============================>|
| 491 (INVITE)|
|<==============================|
| |
Figure 16: Example of UAC-UI and UAS-UcI
図16：UAC-UIとUAS-UCIの例
A B
| |
|UPDATE(offer1) |
|------------------------------>|
|reINVITE(no offer) |
|==============================>|
| 500 (INVITE)|
|<==============================|
| |
Figure 17: Example of UAC-UU and UAS-UsI
図17：UAC-UUとUAS-USIの例
A B
| |
| reINVITE(no offer)|
|<------------------------------|
|1xx-rel(offer0) |
|------------------------------>|
|UPDATE(offer1) |
|==============================>|
| 491 (UPDATE)|
|<==============================|
| |
Figure 18: Example of UAC-IU and UAS-IcU
図18：UAC-IUとUAS-ICUの例
A B
| |
|reINVITE(no offer) |
|------------------------------>|
| 1xx-rel(offer0)|
|<------------------------------|
|UPDATE(offer1) |
|==============================>|
| 500 (UPDATE)|
|<==============================|
| |
Figure 19: Example of UAC-IU and UAS-IsU
図19：UAC-IUとUAS-ISUの例
In addition, it is assumed that the UPDATE request in this section includes an offer. The interworking of a re-INVITE and an UPDATE without an offer is out of scope for this document.
加えて、このセクションでUPDATE要求がオファーを含むものとします。再INVITEのインターワーキングおよび提供せずにUPDATEはこの文書の範囲外です。
While [RFC3264] and [RFC3312] give some guidance, questions remain about exactly what should be included in an offer or answer. This is especially a problem when the common "hold" feature has been activated, and when there is the potential for a multimedia call.
[RFC3264]と[RFC3312]はいくつかのガイダンスを与える一方で、質問は申し出または回答に含まれるべき正確に何についてのまま。これは一般的な「ホールド」機能が起動されている場合には特に問題であり、マルチメディア呼の可能性がある場合もございます。
Details of behavior depend on the capabilities and state of the User Agent. The kinds of recommendations that can be made are limited by the model of device capabilities and state that is presumed to exist.
動作の詳細については、ユーザエージェントの能力や状態によって異なります。することができるお薦めの種類が存在することが推定されるデバイスの能力及び状態のモデルによって制限されます。
This section focuses on a few key aspects of offers and answers that have been identified as troublesome, and will consider other aspects to be out of scope. This section considers:
このセクションでは、面倒なものとして同定されているオファーとアンサーのいくつかの重要な側面に焦点を当て、およびスコープの外であることを他の側面を検討します。このセクションでは、考慮します。
o choice of supported media types and formats to include and exclude
Oサポートされているメディアの種類とフォーマットの選択が含まれ、除外する
o hold and resume of media
O保持し、メディアの履歴書
The following are out of scope for this document:
以下はこの文書の範囲外です。
o NAT traversal and Interactive Connectivity Establishment (ICE)
O NATトラバーサルとインタラクティブ接続確立（ICE）
o specific codecs and their parameters
O特定のコーデックとそのパラメータ
o the negotiation of secure media streams
安全なメディアストリームの交渉O
o grouping of media streams
メディアストリームのOグルーピング
o preconditions
ああprikandisans
A UA should send an offer that indicates what it, and its user, are interested in using/doing at that time, without regard for what the other party in the call may have indicated previously. This is the case even when the offer is sent in response to an INVITE or re-INVITE that contains no offer. (However, in the case of re-INVITE, the constraints of [RFC3261] and [RFC3264] must be observed.)
UAは、どのようなことを示して提供し、そのユーザーを送信する必要があり、通話中に相手が先に示されているかもしれないものに関係なく、その時にやって/使用することに興味を持っています。これは、オファーは、INVITEまたはそれは何の申し出を含まない再INVITEに応答して送信された場合でもです。 （但し、RE-INVITEの場合には、[RFC3261]及び[RFC3264]の制約が観察されなければなりません。）
A UA should send an answer that includes as close an approximation to what the UA and its user are interested in doing at that time, while remaining consistent with the offer/answer rules of [RFC3264] and other RFCs.
[RFC3264]やその他のRFCのオファー/アンサールールと一致ままUAは、UAとそのユーザーがその時にやってに興味があるものに限り近い近似値を含む応答を送信する必要があります。
NOTE: "at that time" is important. The device may permit the user to configure which supported media are to be used by default.
注：「その時」が重要です。デバイスは、メディアがデフォルトで使用されるサポートされている設定をユーザーに許可することができます。
In some cases, a UA may not have direct knowledge of what it is interested in doing at a particular time. If it is an intermediary, it may be able to delegate the decision. In the worst case, it may apply a default, such as assuming it wants to use all of its capabilities.
いくつかのケースでは、UAは、それが特定の時間にやってに興味があるものの直接的な知識を持っていないかもしれません。それは仲介者であれば、意思決定を委任することができるかもしれません。最悪の場合には、そのようなことはその機能のすべてを使用したいと仮定して、デフォルトを適用することができます。
When a UAC sends an initial INVITE with an offer, it has complete freedom to choose which media type(s) and media format(s) (payload types in the case of RTP) it should include in the offer.
UACが申し出て最初のINVITEを送信すると、それは提供に含めるべきメディアタイプ（S）およびメディアフォーマット（S）（RTPの場合のペイロードタイプ）を選択するための完全な自由を持っています。
The media types may be all or a subset of the media the UAC is capable of supporting, with the particular subset being determined by the design and configuration (e.g., via [RFC6080]) of the UAC combined with input from the user interface of the UAC.
メディアタイプは、UACのすべてまたはUACは、特定のサブセットは、（[RFC6080]を介して、例えば、）設計と構成によって決定された状態で、サポートすることができるメディアのサブセットは、ユーザインターフェースからの入力と組み合わせてもよいですUAC。
The media formats may be all or a subset of the media formats the UAC is capable of supporting for the corresponding media type, with the particular subset being determined by the design and configuration of the UAC combined with input from the user interface of the UAC.
メディア形式は、すべてまたはメディアのサブセットが特定のサブセットは、UACの設計と構成によって決定されると、UACは、対応するメディアタイプについてサポート可能なフォーマットUACのユーザインターフェースからの入力と組み合わせてもよいです。
Including all supported media formats will maximize the possibility that the other party will have a supported format in common. But including many can result in an unacceptably large SDP body.
サポートされているすべてのメディアフォーマットを含めると、他の当事者が共通でサポートされている形式を持っているだろうという可能性を最大化します。しかし、多くは容認できないほど大規模なSDPボディにつながることができますを含みます。
When a UAS has received an initial INVITE without an offer, it must include an offer in the first reliable response to the INVITE. It has largely the same options as when sending an initial INVITE with an offer, but there are some differences. The choice may be governed by both static (default) selections of media types as well as dynamic selections made by a user via interaction with the device while it is alerting.
UASは提供せずに最初のINVITEを受信したとき、それはINVITEへの最初の信頼性の高い対応してプランを含める必要があります。それは初期の申し出にINVITEを送信するときとほぼ同じオプションを持っていますが、いくつかの違いがあります。選択は、メディアタイプの静的（デフォルト）の選択、ならびにそれが警告されている間、デバイスとの相互作用を介してユーザによって行われた動的選択の両方によって支配されてもよいです。
NOTE: The offer may be sent in a reliable provisional response, before the user of the device has been alerted and had an opportunity to select media options for the call. In this case, the UAS cannot include any call-specific options from the user of the device. If there is a possibility that the user of the device will wish to change what is offered before answering the call, then special care should be taken. If PRACK and UPDATE are supported by caller and callee then an initial offer can be sent reliably, and changed with an UPDATE if the user desires a change. If PRACK and UPDATE are not supported, then the initial offer cannot be changed until the call is fully established. In that case, the offer in a 200 response for the initial INVITE should include only the media types and formats believed to be acceptable to the user.
注：デバイスのユーザーは警告を受け、コールのためのメディアオプションを選択する機会を持ってきた前にオファーは、信頼性のある暫定応答して送信することができます。この場合、UASは、デバイスのユーザからのコール固有のオプションを含めることができません。デバイスのユーザがコールに応答する前に提供されるものに変更したくなる可能性がある場合には、特別な注意が必要です。 PRACKとUPDATEが、その後呼び出し元と呼び出し先によってサポートされている場合は、ユーザが変更を希望する場合は最初のオファーはUPDATEで確実に送信され、変更することができます。 PRACKとUPDATEがサポートされていない場合は通話が完全に確立されるまで、その後、最初のオファーを変更することはできません。その場合、最初の200応答で提供INVITEは、ユーザにとって許容できると考えられてのみメディアタイプと形式を含むべきです。
When a UAS receives an initial INVITE with an offer, what media lines the answer may contain is constrained by [RFC3264]. The answer must contain the same number of "m=" lines as the offer, and they must contain the same media types. Each media line may be accepted, by including a non-zero port number, or rejected by including a zero port number in the answer. The media lines that are accepted should typically be those with types and formats the UAS would have included if it were the offerer.
UASは、初期の申し出にINVITEを受信すると、答えが含まれていてもよいものをメディアラインは、[RFC3264]によって制約されます。答えはオファーと「M =」行の同じ番号が含まれている必要があり、そしてそれらは同じメディアタイプを含める必要があります。各メディア・ラインは、非ゼロのポート番号を含めることによって、受け入れられた、又は回答ゼロポート番号を含めることによって拒否されてもよいです。それは、オファーした場合、一般的なタイプのものでなければならない受け入れ、UASをフォーマットされたメディアラインが含まれているだろう。
The media formats the answer may contain are constrained by [RFC3264]. For each accepted "m=" line in the answer, there must be at least one media format in common with the corresponding "m=" line of the offer. The UAS may also include other media formats it is able to support at this time. Doing so establishes an asymmetric media format situation, where these "other" media formats may only be sent from the offerer to the answerer. This asymmetric media situation is also limited because it cannot be sustained if there is a subsequent offer/answer exchange in the opposite direction. Also, there is limited value in including these other media formats because there is no assurance that the offerer will be able to use them.
答えは含まれていてもよいメディアフォーマットは、[RFC3264]によって制約されています。回答の各受け入れ「M =」行のため、オファーの対応する「M =」ラインと共通の少なくとも1つのメディア形式が存在しなければなりません。 UASはまた、この時点でサポートすることができ、他のメディアフォーマットを含むこともできます。そうすることで、これらの「他の」メディア形式のみ回答に申出から送信されてもよい非対称メディアフォーマット状況を確立します。逆方向に、後続のオファー/アンサー交換がある場合、それは持続することができないため、この非対称のメディア状況も限られています。また、オファー側がそれらを使用することができるという保証がないため、これらの他のメディアフォーマットを含むで制限された値が存在します。
If the UAS does not wish to indicate support for any of the media types in a particular media line of the offer it must reject the corresponding media line, by setting the port number to zero.
UASは、オファーの特定のメディアラインにメディアタイプのいずれかのサポートを示すために希望していない場合、それはゼロにポート番号を設定することにより、対応するメディア・ラインを拒否しなければなりません。
When the UAS wishes to reject all of the media lines in the offer, it may send a 488 failure response. Alternatively, it may send a reliable non-failure response including all media lines with port numbers set to zero.
UASは、提供中のメディアラインのすべてを拒否したい場合は、488失敗応答を送信することができます。また、それがゼロに設定されたポート番号を持つすべてのメディアのラインを含む信頼性の高い非失敗応答を送信することができます。
When a UAC has sent an initial INVITE without an offer, and then receives a response with the first offer, it should answer in the same way as a UAS receiving an initial INVITE with an offer.
UACは、初期には提供せずにINVITEを送信し、その後、最初のオファーで応答を受信したとき、それはUASが提供して最初のINVITEを受け取ると同じように答える必要があります。
Because the offer arrives in a response to the INVITE, the UAC cannot reject the message containing the offer. If the UAC wishes to reject the entire offer, it must send a PRACK or ACK request including all the media lines with ports set to zero. Then, if it does not wish to continue the session, it may send a CANCEL or BYE request to terminate the dialog.
オファーがINVITEに応じて到着したので、UACは申し出を含むメッセージを拒否することはできません。 UACは、全体の申し出を拒否したい場合、それはゼロに設定されたポートを持つすべてのメディアのラインを含むPRACKやACKリクエストを送信する必要があります。それはセッションを継続したくない場合はその後、それはダイアログを終了するCANCELまたはBYE要求を送信することができます。
The guidelines above (Sections 5.1 and 5.2.1 through Section 5.2.4) apply, but constraints in [RFC3264] must also be followed. The following are of particular note because they have proven troublesome:
（セクション5.2.4を介して5.1および5.2.1）上記ガイドラインが適用されますが、[RFC3264]での制約も従わなければなりません。彼らは面倒であることが判明したので、次は、特に注目すべきです：
o The number of "m=" lines may not be reduced in a subsequent offer. Previously rejected media streams must remain, or be reused to offer the same or a different stream. (Section 6 of [RFC3264].)
多くのO「はm =」行は、後続の提供に低減されなくてもよいです。以前に拒否されたメディアストリームが残っている必要があり、同じまたは別のストリームを提供するために再利用されます。 （[RFC3264]のセクション6）。
o In the "o=" line, only the version number may change, and if it changes, it must increment by one from the one previously sent as an offer or answer. (Section 8 of [RFC3264].) If it doesn't change, then the entire SDP body must be identical to what was previously sent as an offer or answer. Changing the "o=" line, except version number value, during the session is an error case. The behavior when receiving such a non-compliant offer/answer SDP body is implementation dependent. If a UA needs to negotiate a 'new' SDP session, it should use the INVITE/Replaces method.
O「O =」行では、唯一のバージョン番号が変更される可能性があり、それが変更された場合、それが以前に提供または回答として送ら1から1ずつ増加しなければなりません。 （[RFC3264]のセクション8。）それは変更されない場合は、全体のSDP本体は、以前のオファーまたは回答として送信されたものと同一である必要があります。セッション中に、バージョン番号の値を除いて、「O =」行を変更すると、エラーの場合です。このような非準拠のオファーを受けたときに/ SDP本体に答える動作は実装依存です。 UAが「新しい」SDPセッションを交渉する必要がある場合、それはINVITEを使用する必要があります/メソッドを置き換えます。
o In the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream ("m=" line) must not change for the duration of the session. (Section 8.3.2 of [RFC3264].)
O RTPの場合には、そのメディアストリーム内の特定のコーデックに特定のダイナミックペイロードタイプ番号からマッピング（「M =」の行）は、セッションの期間中変化してはなりません。 （[RFC3264]のセクション8.3.2）。
NOTE: This may be impossible for a back-to-back user agent
(B2BUA) to follow in some cases (e.g., 3PCC transfer) if it
does not terminate media.
When the new offer is sent in response to an offerless (re-)INVITE, it should be constructed according to the General Principle for Constructing Offers and Answers (Section 5.1 ): all codecs the UA is currently willing and able to use should be included, not just the ones that were negotiated by previous offer/answer exchanges. The same is true for media types -- so if UA A initially offered audio and video to UA B, and they end up with only audio, and UA B sends an offerless (re-)INVITE to UA A, A's resulting offer should most likely re-attempt video, by reusing the zeroed "m=" line used previously.
新しいオファーがofferless（再）INVITEに応答して送信されると、それはオファーと回答（5.1節）を構築するための一般原則に従って構築されなければならない：UAは現在、喜んでと使用することができ、すべてのコーデックが含まれなければなりません、前回のオファー/アンサー交換で交渉されたものだけでなく。同じことは、メディアタイプのために真である - ので、UA Aは当初、UA Bにオーディオとビデオを提供している場合、彼らは音声だけで終わる、とUA Bは（再）、Aの結果の提供がすべき最もUA AにINVITE offerless送信します以前に使用ゼロに「M =」の行を再利用することで、再試行動画ありそう。
NOTE: The behavior above is recommended, but it is not always achievable, for example, in some interworking scenarios. Or, the offerer may simply not have enough resources to offer "everything" at that point. Even if the UAS is not able to offer any other SDP that the one currently being used, it should not reject the re-INVITE. Instead, it should generate an offer with the currently used SDP with "o=" line unchanged.
注：上記の動作が推奨されますが、それは例えば、いくつかのインターワーキングのシナリオでは、常に達成できません。または、オファー側は、単にその時点で「すべて」を提供するのに十分なリソースを持っていないかもしれません。 UASは1つが現在使用している、それは再INVITEを拒否してはならないこと、他のSDPを提供することができない場合でも。代わりに、それは変わらず、「O =」行で現在使用されてSDPとの申し出を生成する必要があります。
[RFC3264] specifies (using non-normative language) that "hold" should be indicated in an established session by sending a new offer containing "a=sendonly" attribute for each media stream to be held. An answerer is then to respond with "a=recvonly" attribute to acknowledge that the hold request has been understood.
「ホールド」が保持される各メディアストリームのための「a = sendonlyの」属性を含む新しいオファーを送信することによって確立されたセッションに示されるべきであること[RFC3264]（非規範的な言語を使用して）を指定。回答は保留要求が理解されていることを確認するために、「A =がrecvonly」属性で応答した後です。
Note that the use of sendonly/recvonly is not limited to hold. These may be used for other reasons, such as devices that are only capable of sending or receiving. So receiving an offer with "a=sendonly" attribute must not be treated as a certain indication that the offerer has placed the media stream on hold.
sendonlyで/がrecvonlyの使用を保持するために限定されるものではないことに注意してください。これらは、送信または受信の唯一の可能な装置のような他の理由のために使用することができます。だから、「A = sendonlyで」属性を持つオファーはオファー側が保留にメディアストリームを置いていることは確か指標として扱われてはならない受け取ります。
This model is based on an assumption that the UA initiating the hold will want to play Music on Hold, which is not always the case. A UA may, if desired, initiate hold by offering "a=inactive" attribute if it does not intend to transmit any media while in hold status.
このモデルは、ホールドを開始するUAは、必ずしもそうではありませんホールド、上の音楽を再生することになるでしょう仮定に基づいています。それはホールド状態にある間に任意のメディアを送信する意思がない場合、UAは、必要に応じて、「A =非アクティブ」属性を提供することで、ホールドを開始することができます。
The rules of [RFC3264] constrain what may be in an answer when the offer contains "sendonly", "recvonly", or "inactive" in an "a=" line. But they do not constrain what must be in a subsequent offer. The "General Principle for Constructing Offers and Answers" (Section 5.1) is important here. The initiation of "hold" is a local action. It should reflect the desired state of the UA. It then affects what the UA includes in offers and answers until the local state is reset.
[RFC3264]の規則は、オファーが「sendonlyの」、「recvonlyで」が含まれ、または「A =」行で「非アクティブ」の答えであるかもしれないものに制約。しかし、彼らは、その後の申し出である必要がありますどのような制約はありません。 「オファーと回答を構築するための一般的な原則」（5.1節）はここでは重要です。 「ホールド」の開始はローカルアクションです。これは、UAの所望の状態を反映する必要があります。その後、地元の状態がリセットされるまでUAは、オファーとアンサーに含まれるどのような影響を与えます。
The receipt of an offer containing "a=sendonly" attribute or "a=inactive" attribute and the sending of a compatible answer should not change the desired state of the recipient. However, a UA that has been "placed on hold" may itself desire to initiate its own hold status, based on local input.
「= sendonlyで」属性または「A =非アクティブ」属性を含むオファーの領収書と互換性のある解答の送信は、受信者の所望の状態を変更しないでください。しかし、「保留に」されているUAは、それ自体はローカル入力に基づいて、独自のホールド状態を開始することを望むかもしれません。
If UA2 has previously been "placed on hold" by UA1, via receipt of "a=sendonly" attribute, then it may initiate its own hold by sending a new offer containing "a=sendonly" attribute to UA1. Upon receipt of that, UA1 will answer with "a=inactive" attribute because that is the only valid answer that reflects its desire not to receive media.
UA2は、以前に「A = sendonlyで」属性の受領を経て、UA1で「保留に」されている場合、それはUA1に「A = sendonlyの」属性を含む新しいプランを送信することにより、独自のホールドを開始することができます。それがメディアを受信しないようにその願望を反映している唯一の有効な回答であるため、その受信すると、UA1は「A =非アクティブ」属性でお答えします。
NOTE: Section 8.4 of [RFC3264] contains a conflicting recommendation that the offer contain "a=inactive" attribute in this case. We interpret that recommendation to be non-normative. The use of "a=sendonly" attribute in this case will never produce a worse outcome, and can produce a better outcome in useful cases.
注：[RFC3264]の8.4節にはオファーが、この場合、「A =非アクティブ」属性が含まれている競合勧告が含まれています。私たちは、その勧告は非規範的であることを解釈します。この場合の「A = sendonlyで」属性の使用は悪い結果をもたらすことはありません、と便利な場合は、より良い結果を生み出すことができます。
Once in this state, to resume a two-way exchange of media, each side must reset its local hold status. If UA1 is first to go off hold, it will then send an offer with "a=sendrecv" attribute. The UA2 will respond with its desired state of "a=sendonly" attribute because that is a permitted response. When UA2 desires to also resume, it will send an offer with "a=sendrecv" attribute. In this case, because UA1 has the same desire it will respond with "a=sendrecv" attribute. In the same case, when UA2 receives the offer with "a=sendrecv" attribute, if it has decided it wants to reset its local hold but has not yet signaled the intent, it may send "a=sendrecv" attribute in the answer.
この状態では、メディアの双方向の交流を再開したら、それぞれの側は、その地域のホールド状態をリセットする必要があります。 UA1はホールドをオフに行くために最初のものである場合、それは、「= SENDRECV」属性でのオファーを送ります。それが許可応答であるため、UA2は、「A = sendonlyで」属性のその所望の状態で応答します。 UA2はまた再開したいとき、それは「= SENDRECV」属性でのオファーを送ります。 UA1は同じ願望を持っているので、このような場合には、「= SENDRECV」属性で応答します。それはそれはそのローカルホールドをリセットしたいが、まだ意図を合図していないことを決定した場合UA2は、「= SENDRECV」属性との申し出を受けた同じケースでは、それが答えに「=のsendrecv」属性を送信することができます。
If UA2 has been "placed on hold" by UA1 via receipt of "a=inactive" attribute, and subsequently wants to initiate its own hold, also using "a=inactive" attribute, it need not send a new offer, since the only valid response is "a=inactive" attribute and that is already in effect. However, its local desired state will now be either "inactive" or "a=sendonly" attribute. This affects what it will send in future offers and answers.
UA2は「A =非アクティブ」属性の領収書を経由してUA1で「保留にした」、その後、独自のホールドを開始することを望んでいるされている場合は、また、「A =非アクティブ」属性を使用して、それだけであるため、新しいプランを送信する必要はありません有効な応答は「A =非アクティブ」属性であり、それが有効に既にあります。しかし、そのローカル望ましい状態は今、どちらかの「非アクティブ」または「A = sendonlyで」属性になります。これは、将来のオファーとアンサーに送信されますどのような影響を与えます。
If a UA has occasion to send another offer in the session, without any desire to change the hold status (e.g., in response to a re-INVITE without an offer, or when sending a re-INVITE to refresh the session timer), it should follow the "General Principle for Constructing Offers and Answers" (Section 5.1). If it previously initiated a "hold" by sending "a=sendonly" attribute or "a=inactive" attribute, then it should offer that again. If it had not previously initiated "hold", then it should offer "a=sendrecv" attribute, even if it had previously been forced to answer something else. Without this behavior it is possible to get "stuck on hold" in some cases, especially when a 3pcc is involved.
UAは、（再INVITEのオファーなし、または送信するときにセッションタイマーをリフレッシュするために再INVITEに応じて、例えば）ホールド状態を変更するための任意の願望なしに、セッションでそれを別のオファーを送信する機会を持っている場合（5.1節）、「オファーと回答を構築するための一般的な原則」に従ってください。それは以前に「A = sendonlyで」属性または「A =非アクティブ」属性を送信することによって、「ホールド」を開始した場合は、それはそれを再度提供する必要があります。それは以前に「保留」を開始していなかった場合は、それは以前に他の何かを答えることを余儀なくされていた場合でも、「A =のsendrecv」属性を提供する必要があります。この動作がなければ、3PCCが含まれている場合は特に、いくつかのケースでは、「保留スタック」を取得することが可能です。
[RFC3264] requires that an agent be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer.
[RFC3264]は、エージェントは、それがRTPもRTCPもピアに送信されなければならないことを意味する場合には0.0.0.0の接続アドレスとSDPを受信することが可能であることを必要とします。
If a UA generates an answer to the offer received with "c=IN IP4 0.0.0.0", the direction attribute of the accepted media stream in the answer must still be based on direction attribute of the offered stream and rules specified in [RFC3264] to form the direction "a=" line in the answer. There is no clear rule about the use of "c=IN IP4 0.0.0.0" in the answer; it may be used or "c=" line with a valid IP address may be used. RTP/RTCP will not be sent toward an address of 0.0.0.0 because it is an invalid address.
UAが「IP4 0.0.0.0 IN = C」で受信申し出に対する答えを生成した場合は、その答えで受け入れられたメディアストリームの方向属性がまだ方向提供ストリームの属性として指定されたルールに基づいていなければならない[RFC3264]答えに方向「A =」ラインを形成します。答えの「IP4 0.0.0.0は、C =」の使用について明確なルールはありません。それを使用することができるか、有効なIPアドレスを持つ「C =」行を使用することができます。それは無効なアドレスであるため、RTP / RTCPは0.0.0.0のアドレスに向かって送信されません。
This document clarifies ambiguities in the intended behavior of the two SIP User Agents engaged in a dialog. The primary specification of offer/answer behavior that is being clarified resides in [RFC3261] and [RFC3264], with extensions in [RFC3311], [RFC3312], and [RFC6141]. The focus of this document is on cases where ambiguities can result failed or degraded calls when there is no attacker. The clarifications exclude call flows that lead to difficulties, without legitimizing any formerly invalid call flows. Thus, the security considerations of the above mentioned documents continue to apply and need not be extended to handle any additional cases.
この文書では、ダイアログに従事して2つのSIPユーザーエージェントの意図した動作であいまいさを明確にしています。 [RFC3311]、[RFC3312]及び[RFC6141]での拡張と、[RFC3261]及び[RFC3264]に存在を明らかにしているオファー/アンサー挙動の主要仕様。このドキュメントの焦点は何の攻撃者が存在しない場合にあいまいさが故障または劣化のコールを引き起こすことができます例です。明確化は、任意の以前の無効なコールフローを正当化せず、困難につながるコールフローを除外する。したがって、上記の文書のセキュリティ上の考慮事項が引き続き適用され、任意の追加のケースを処理するために拡張する必要はありません。
The offer/answer process can be disrupted in numerous ways by an attacker. SIP provides mechanisms to protect the offer/answer exchange from tampering by third parties. Of note is "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)" [RFC4474], as well as Section 26.3.2, "Security Solutions", of [RFC3261].
オファー/アンサープロセスは、攻撃者によってさまざまな方法で破壊することができます。 SIPは、第三者による改ざんからオファー/アンサー交換を保護するためのメカニズムを提供します。注目すべきは、[RFC4474]と同様に、[RFC3261]のセクション26.3.2、「セキュリティソリューション」、「セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化」です。
The authors would like to thank Christer Holmberg, Rajeev Seth, Nataraju A B, Byron Campen, Jonathan Rosenberg, Gonzalo Camarillo, and Gao Yang for their thorough reviews and comments. Many of their suggestions and ideas have been incorporated in this document.
著者は、彼らの徹底的なレビューやコメントのためクリステルHolmbergの、ラジーブセス、Nataraju A B、バイロンCampen、ジョナサン・ローゼンバーグ、ゴンサロ・カマリロ、及びガオヤンに感謝したいと思います。彼らの提案やアイデアの多くは、本文書に組み込まれています。
[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月。
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[RFC3312]キャマリロ、G.、マーシャル、W.、およびJ.ローゼンバーグ、RFC 3312、2002年10月 "資源管理とセッション開始プロトコル（SIP）の統合"。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "SDP：セッション記述プロトコル"、RFC 4566、2006年7月。
[RFC6141] Camarillo, G., Holmberg, C., and Y. Gao, "Re-INVITE and Target-Refresh Request Handling in the Session Initiation Protocol (SIP)", RFC 6141, March 2011.
[RFC6141]キャマリロ、G.、Holmbergの、C.、およびY.ガオ、 "再INVITEおよびセッション開始プロトコル（SIP）での取り扱いターゲット・リフレッシュ要求"、RFC 6141、2011年3月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[RFC3959] Camarillo, G., "The Early Session Disposition Type for the Session Initiation Protocol (SIP)", RFC 3959, December 2004.
[RFC3959]キャマリロ、G.、RFC 3959 "セッション開始プロトコル（SIP）のための初期セッション処分タイプ"、2004年12月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC6080] Petrie, D. and S. Channabasappa, "A Framework for Session Initiation Protocol User Agent Profile Delivery", RFC 6080, March 2011.
[RFC6080]ペトリー、D.とS. Channabasappa、RFC 6080 "セッション開始プロトコルユーザエージェントプロファイル配信のためのフレームワーク"、2011年3月。
Authors' Addresses
著者のアドレス
OKUMURA Shinji Softfront 28-196, Noth9, West15, Chuo-ku Sapporo, Hokkaido 060-0009 Japan
おくむら しんじ そｆｔｆろんｔ ２８ー１９６、 のｔｈ９、 うぇｓｔ１５、 ちゅおーく さっぽろ、 ほっかいど ０６０ー０００９ じゃぱん
EMail: shinji.okumura@softfront.jp
メールアドレス：shinji.okumura@softfront.jp
Takuya Sawada KDDI Corporation 3-10-10, Iidabashi, Chiyoda-ku Tokyo Japan
たくや さわだ Ｋっぢ こｒぽらちおん ３ー１０ー１０、 いいだばし、 ちよだーく ときょ じゃぱん
EMail: tu-sawada@kddi.com
メールアドレス：tu-sawada@kddi.com
Paul H. Kyzivat Hudson, MA 01749 USA
ポールH. Kyzivatハドソン、MA 01749 USA
EMail: pkyzivat@alum.mit.edu
メールアドレス：pkyzivat@alum.mit.edu