[要約] RFC 5373は、SIPにおける応答モードの要求に関する規格であり、SIPセッションの確立と制御において、応答モードの選択と制御を可能にすることを目的としています。
Network Working Group D. Willis, Ed.
Request for Comments: 5373 Softarmor Systems
Category: Standards Track A. Allen
Research in Motion (RIM)
November 2008
Requesting Answering Modes for the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）の回答モードの要求
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD1）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2008 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2008 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/ license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Abstract
概要
This document extends SIP with two header fields and associated option tags that can be used in INVITE requests to convey the requester's preference for user-interface handling related to answering of that request. The first header, "Answer-Mode", expresses a preference as to whether the target node's user interface waits for user input before accepting the request or, instead, accepts the request without waiting on user input. The second header, "Priv-Answer-Mode", is similar to the first, except that it requests administrative-level access and has consequent additional authentication and authorization requirements. These behaviors have applicability to applications such as push-to-talk and to diagnostics like loop-back. Usage of each header field in a response to indicate how the request was handled is also defined.
このドキュメントでは、SIPが2つのヘッダーフィールドと、招待リクエストで使用できる関連するオプションタグを拡張します。そのリクエストへの回答に関連するユーザーインターフェイスの取り扱いに対するリクエスターの好みを伝えるために招待者が使用できます。最初のヘッダー「Answer-Mode」は、ターゲットノードのユーザーインターフェイスがリクエストを受け入れる前にユーザー入力を待機するか、代わりにユーザー入力を待たずにリクエストを受け入れるかについての好みを表します。2番目のヘッダーである「Priv-Answer-Mode」は、最初のヘッダーに似ていますが、管理レベルのアクセスを要求し、その結果、認証と承認の要件が追加されます。これらの動作は、プッシュツートークなどのアプリケーションやループバックなどの診断に適用可能です。各ヘッダーフィールドの使用回答で、リクエストの処理方法も定義されていることを示します。
Table of Contents
目次
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Syntax of Header Fields and Option Tags . . . . . . . . . . . 5
3. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields . 6
4. Usage of the Answer-Mode and Priv-Answer-Mode Header
Fields in Requests . . . . . . . . . . . . . . . . . . . . . . 6
4.1. The Difference Between Answer-Mode and Priv-Answer-Mode . 7
4.2. The "require" Modifier . . . . . . . . . . . . . . . . . . 9
4.3. Procedures at User Agent Clients (UAC) . . . . . . . . . . 9
4.3.1. All Requests . . . . . . . . . . . . . . . . . . . . . 9
4.3.2. REGISTER Transactions . . . . . . . . . . . . . . . . 9
4.3.3. INVITE Transactions . . . . . . . . . . . . . . . . . 10
4.4. Procedures at Intermediate Proxies . . . . . . . . . . . . 12
4.4.1. General Proxy Behavior . . . . . . . . . . . . . . . . 12
4.4.2. Issues with Automatic Answering and Forking . . . . . 12
4.5. Procedures at User Agent Servers (UAS) . . . . . . . . . . 13
4.5.1. INVITE Transactions . . . . . . . . . . . . . . . . . 13
5. Usage of the Answer-Mode and Priv-Answer-Mode Header
Fields in Responses . . . . . . . . . . . . . . . . . . . . . 14
5.1. Procedures at the UAS . . . . . . . . . . . . . . . . . . 14
5.2. Procedures at the UAC . . . . . . . . . . . . . . . . . . 15
6. Examples of Usage . . . . . . . . . . . . . . . . . . . . . . 15
6.1. REGISTER Request . . . . . . . . . . . . . . . . . . . . . 15
6.2. INVITE Request . . . . . . . . . . . . . . . . . . . . . . 16
6.3. 200 (OK) Response . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Attack Sensitivity Depends on Media Characteristics . . . 17
7.2. Application Design Affects Attack Opportunity . . . . . . 19
7.3. Applying the Analysis . . . . . . . . . . . . . . . . . . 19
7.4. Minimal Policy Requirement . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Registration of Header Fields . . . . . . . . . . . . . . 22
8.2. Registration of Header Field Parameters . . . . . . . . . 22
8.3. Registration of SIP Option Tags . . . . . . . . . . . . . 22
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . . 24
The conventional model for session establishment using the Session Initiation Protocol (SIP, [RFC3261]) involves 1) sending a request for a session (a SIP INVITE) and notifying the user receiving the request, 2) acceptance of the request and of the session by that user, and 3) the sending of a response (SIP 200 OK) back to the requester before the session is established. Some usage scenarios deviate from this model, specifically with respect to the notification and acceptance phase. While it has always been possible for the node receiving the request to skip the notification and acceptance phases, there has been no standard mechanism for the party sending the request to specifically indicate a desire (or requirement) for this sort of treatment. This document defines a SIP extension header field that can be used to request specific treatment related to the notification and acceptance phase.
セッション開始プロトコル（SIP、[RFC3261]）を使用したセッション確立の従来のモデルには、1）セッション（SIP招待）のリクエストを送信し、リクエストを受信しているユーザーに通知する、2）リクエストとセッションの受け入れが含まれます。そのユーザーによって、および3）セッションが確立される前に、応答の送信（SIP 200 OK）はリクエスターに戻ります。いくつかの使用シナリオは、特に通知と受け入れ段階に関して、このモデルから逸脱しています。ノードが通知と受け入れ段階をスキップするリクエストを受信することは常に可能でしたが、この種の治療に対する要求（または要件）を具体的に示すために要求を送信する当事者の標準的なメカニズムはありませんでした。このドキュメントでは、通知と受け入れ段階に関連する特定の治療を要求するために使用できるSIP拡張ヘッダーフィールドを定義します。
The first usage scenario is the requirement for diagnostic loopback calls. In this sort of scenario, a testing service sends an INVITE to a node being tested. The tested node accepts and a dialog is established. But rather than establishing a two-way media flow, the tested node loops back or "echoes" media received from the testing service back toward the testing service. The testing service can then analyze the media flow for quality and timing characteristics. Session Description Protocol (SDP) usage for this sort of flow is described in [LOOPBACK]. In this sort of application, it might not be necessary that the human using the tested node interact with the node in any way for the test to be satisfactorily executed. In some cases, it might be appropriate to alert the user to the ongoing test, and in other cases it might not be.
最初の使用シナリオは、診断ループバックコールの要件です。この種のシナリオでは、テストサービスがテスト対象のノードに招待状を送信します。テストされたノードが受け入れ、ダイアログが確立されます。しかし、双方向のメディアフローを確立するのではなく、テスト済みのノードがバックバックまたはテストサービスから受け取った「エコー」メディアがテストサービスに向かって戻ってきました。テストサービスは、品質とタイミングの特性についてメディアフローを分析できます。セッション説明プロトコル（SDP）この種のフローの使用は、[Loopback]で説明されています。この種のアプリケーションでは、テスト済みノードを使用している人間が、テストを十分に実行するためにノードと対話する必要がない場合があります。場合によっては、継続的なテストをユーザーに警告することが適切かもしれませんし、他の場合はそうでない場合があります。
The second scenario is that of push-to-talk applications, which have been specified by the Open Mobile Alliance. In this sort of environment, SIP is used to establish a dialog supporting asynchronous delivery of unidirectional media flow, providing a user experience like that of a traditional two-way radio. It is conventional for the INVITES used to be automatically accepted by the called UA (User Agent), and the media is commonly played out on a loudspeaker. The called party's UA's microphone is not engaged until the user presses the local "talk" button to respond.
2番目のシナリオは、オープンモバイルアライアンスによって指定されているプッシュツートークアプリケーションのシナリオです。この種の環境では、SIPを使用して、単方向のメディアフローの非同期配信をサポートするダイアログを確立し、従来の双方向ラジオのようなユーザーエクスペリエンスを提供します。これは、呼び出されたUA（ユーザーエージェント）によって自動的に受け入れられていた招待状のための従来のものであり、メディアは一般的にスピーカーで再生されます。呼び出されたパーティーのUAのマイクは、ユーザーがローカルの「トーク」ボタンを押して応答するまで従事しません。
A third scenario is the Private Branch Exchange (PBX) attendant. Traditional office PBX systems often include intercom functionality. A typical use for the intercom function is to allow a receptionist to activate a loudspeaker on a desk telephone in order to announce a visitor. Not every caller can access the loudspeaker, only the receptionist or operator, and it is not expected that these callers will always want "intercom" functionality -- they might instead want to make an ordinary call.
3番目のシナリオは、プライベートブランチエクスチェンジ（PBX）アテンダントです。従来のオフィスPBXシステムには、多くの場合、インターコム機能が含まれます。インターコム機能の典型的な用途は、受付係が訪問者を発表するために机の電話でスピーカーをアクティブにすることです。すべての発信者がスピーカーや受付またはオペレーターのみにアクセスできるわけではなく、これらの発信者が常に「インターホン」機能を必要とすることは予想されません。代わりに通常の電話をかけたいと思うかもしれません。
There are presumably many more use cases for the extensions defined in this specification, but this document was developed to specifically meet the requirements of these scenarios, or others with essentially similar properties.
この仕様で定義されている拡張機能には、おそらくさらに多くのユースケースがありますが、このドキュメントは、これらのシナリオの要件または本質的に類似したプロパティを持つ他の人の要件を具体的に満たすために開発されました。
These sorts of mechanisms are not required to provide the functionality of an "answering machine" or "voice mail recorder". Such a device knows that it is expected to answer and does not require a SIP extension to support its behavior.
これらの種類のメカニズムは、「留守番電話」または「ボイスメールレコーダー」の機能を提供するために必要ではありません。このようなデバイスは、回答することが期待されていることを知っており、その動作をサポートするためにSIP拡張機能を必要としません。
Much of the discussion of this topic in working group meetings and on the mailing list dealt with differentiating "answering mode" from "alerting mode". Some early work did not make this distinction. We therefore proceed with the following definitions:
ワーキンググループ会議およびメーリングリストでのこのトピックの議論の多くは、「アラートモード」と「応答モード」の区別を扱っています。いくつかの初期の仕事はこの区別をしませんでした。したがって、次の定義を進めます。
o Answering Mode includes behaviors in a SIP UA relating to acceptance or rejection of a request that are contingent on interaction between the UA and the user of that UA after the UA has received the request. We are principally concerned with the user interaction involved in accepting the request and initiating an active session. An example of this might be pressing the "yes" button on a mobile phone.
o 回答モードには、UAがリクエストを受け取った後、UAとそのUAのユーザーとの相互作用を条件とする要求の受け入れまたは拒否に関連するSIP UAの動作が含まれます。主に、リクエストの受け入れとアクティブなセッションの開始に関与するユーザーの相互作用に関心があります。この例は、携帯電話の「はい」ボタンを押すことです。
o Alerting Mode includes behaviors in a SIP UA relating to informing the user of the UA that a request to initiate a session has been received. An example of this might be activating the ring tone of a mobile phone.
o アラートモードには、セッションの開始リクエストが受信されたことをUAのユーザーに通知することに関連するSIP UAの動作が含まれます。この例は、携帯電話の着信音をアクティブにすることです。
This document deals only with "Answering Mode". Issues relating to "Alerting Mode" are outside its scope.
このドキュメントでは、「応答モード」のみを扱います。「アラートモード」に関連する問題は、その範囲外です。
This document defines two SIP extension header fields: "Answer-Mode" and "Priv-Answer-Mode". These two extensions take the same parameters and operate in the same general way.
このドキュメントは、2つのSIP拡張ヘッダーフィールドを定義します：「Answer-Mode」と「Priv-Answer-Mode」。これらの2つの拡張機能は同じパラメーターを取り、同じ一般的な方法で動作します。
The distinction between Answer-Mode and Priv-Answer-Mode relates to the level of authorization claimed by the User Agent Client (UAC) and verified and policed by the User Agent Server (UAS). Requests are usually made using Answer-Mode. Requests made using Priv-Answer-Mode request "privileged" treatment from the UAS. This mechanism is discussed in greater detail below, in Section 4.1.
Answer-ModeとPriv-Answer-Modeの区別は、ユーザーエージェントクライアント（UAC）が主張し、ユーザーエージェントサーバー（UAS）によって検証および警察された認証のレベルに関連しています。通常、リクエストは回答モードを使用して行われます。UASからの「特権」扱いリクエストを使用して行われたリクエスト。このメカニズムについては、以下のセクション4.1で詳細に説明します。
Priv-Answer-Mode is not an assertion of privilege. Instead, it is a request for privileged treatment. This is similar to the UNIX model, where a user might run a command normally or use "sudo" to request administrative privilege for the command. Including "Priv-" is equivalent to prefixing a UNIX command with "sudo". In other words, a separate policy table (like "/etc/sudoers") is consulted to determine whether the user may receive the requested treatment.
Priv-Answer-Modeは特権の主張ではありません。代わりに、特権的な治療の要求です。これは、ユーザーがコマンドを正常に実行するか、「sudo」を使用してコマンドの管理特権を要求するUNIXモデルに似ています。「priv-」を含むことは、unixコマンドを「sudo」で接頭することと同等です。言い換えれば、ユーザーが要求された治療を受けることができるかどうかを判断するために、別のポリシーテーブル（「/etc/sudoers」など）が相談されます。
This distinction is discussed in greater detail in Section 4.1.
この区別については、セクション4.1で詳しく説明します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following syntax uses ABNF as defined in [RFC5234]. Further, it relies on the syntax for SIP defined in [RFC3261].
次の構文は、[RFC5234]で定義されているようにABNFを使用します。さらに、[RFC3261]で定義されているSIPの構文に依存しています。
The syntax for the header fields defined in this document is:
このドキュメントで定義されているヘッダーフィールドの構文は次のとおりです。
Answer-Mode = "Answer-Mode" HCOLON answer-mode-value *(SEMI answer-mode-param)
Answer-Mode = "Answer-Mode" hcolon Answer-Mode-Value *（Semi Answer-Mode-Param）
Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode-value *(SEMI answer-mode-param)
priv-answer-mode = "priv-answer-mode" hcolon Answer-Mode-Value *（Semi Answer-Mode-Param）
answer-mode-value = "Manual" / "Auto" / token
answer-mode-param= "require" / generic-param
Answer-Mode-Param = "require" / generic-param
The SIP option tag indicating support for this extension is "answermode".
この拡張機能のサポートを示すSIPオプションタグは「exwermode」です。
For implementors: SIP header field names and values are always compared in a case-insensitive manner. The pretty capitalization is just for readability.
実装者の場合：SIPヘッダーフィールド名と値は、常にケースに依存しない方法で比較されます。きれいな大文字は読みやすさのためだけです。
This syntax includes extension hooks ("token" for answer-mode values and "generic-param" for optional parameters) that could be defined in future. This specification defines only the behavior for the values given explicitly above. In order to provide forward compatibility, implementations MUST ignore unknown values.
この構文には、将来定義できる拡張機能（回答モード値の「トークン」とオプションのパラメーターの「一般的なパラム」）が含まれます。この仕様は、上記の値の値の動作のみを定義します。順方向の互換性を提供するために、実装は不明な値を無視する必要があります。
This document defines usage of the Answer-Mode and Priv-Answer-Mode header fields in initial (dialog-forming) SIP INVITE requests and in 200 (OK) responses to those requests. This document specifically does not define usage in any other sort of request or response, including but not limited to ACK, CANCEL, or any mid-dialog usage.
このドキュメントでは、最初の（ダイアログ形成）SIP招待リクエストとそれらのリクエストに対する200（OK）の応答で、回答モードおよびPRIV-Answer-Modeヘッダーフィールドの使用法を定義します。このドキュメントは、ACK、キャンセル、または中間の使用法を含むがこれらに限定されない、他の種類の要求または応答の使用を明確に定義するものではありません。
This limitation stems from the intended usage of this extension, which is to affect the way that users interact with communications devices when requesting new communications sessions and when responding to such requests. This sort of interaction occurs only during the formation of a dialog and its initial usage, not during subsequent operations such as re-INVITE. However, the security aspects of the session initiation must be applied to changes in media description introduced by re-INVITES or similar requests. See Section 7.1 for further discussion of this issue.
この制限は、この拡張機能の意図された使用に起因します。これは、新しい通信セッションを要求し、そのようなリクエストに応答するときに、ユーザーが通信デバイスと対話する方法に影響を与えるためです。この種の相互作用は、ダイアログの形成とその初期使用法の間にのみ発生しますが、その後の操作では、re inviteなどの後続の操作です。ただし、セッション開始のセキュリティの側面は、再インバイトまたは同様のリクエストによって導入されたメディアの説明の変更に適用する必要があります。この問題の詳細については、セクション7.1を参照してください。
The Answer-Mode or Priv-Answer-Mode header field is used by a UAC in an INVITE request to invoke specific handling by the responding UAS; this handling is related to "automatic answering" functionality for any dialog resulting from that INVITE request. If no Answer-Mode or Priv-Answer-Mode header field is included in the request, answering behavior is at the discretion of the UAS, as it would be in the absence of this specification. The desired handling is indicated by the value of the Answer-Mode or Priv-Answer-Mode header field, as follows:
Answer-ModeまたはPriv-Answer-Modeヘッダーフィールドは、UACによって使用され、Responsing UASによる特定の処理を呼び出すための招待リクエストで使用されます。この処理は、その招待リクエストから生じるダイアログの「自動応答」機能に関連しています。応答モードまたはPRIV-Answerヘッダーフィールドがリクエストに含まれていない場合、回答動作は、この仕様がない場合に備えて、UASの裁量で行われます。目的の取り扱いは、次のように、回答モードまたはPRIV-Answer-Modeヘッダーフィールドの値によって示されます。
Manual: The UAS is asked to defer accepting the request until the user of the UAS has interacted with the user interface (UI) of the UAS in such a way as to indicate that the user desires the UAS to accept the request.
マニュアル：UASは、UASのユーザーがUASのユーザーインターフェイス（UI）と対話するまで、リクエストを延期するよう求められます。ユーザーがUASにリクエストを受け入れることを望んでいることを示すように。
Auto: The UAS is asked to accept the request automatically, without waiting for the user of the UAS to interact with the UI of the UAS in such a way as to indicate that the user desires the UAS to accept the request.
AUTO：UASは、UASのユーザーがUAのUIと対話するのを待つことなく、ユーザーがUASがUASにリクエストを受け入れることを望んでいることを示すことなく、リクエストを自動的に受け入れるように求められます。
Each value of the Answer-Mode or Priv-Answer-Mode header field can include an optional parameter, "require". If present, this parameter indicates that the UAC would prefer that the UAS reject the request if the UAS is unwilling (perhaps due to policy) to answer in the mode requested, rather than answering in another mode. For example, this parameter could be used to make sure that a test "loopback" call doesn't disturb a user who has configured her phone to manually answer even if the caller requests an automatic answer.
Answer-ModeまたはPriv-Answer-Modeヘッダーフィールドの各値には、オプションのパラメーター「Require」を含めることができます。存在する場合、このパラメーターは、UASがUASが別のモードで答えるのではなく、要求されたモードで回答することを嫌がらない場合、UASがリクエストを拒否することを好むことを示しています。たとえば、このパラメーターを使用して、テスト「ループバック」コールでは、発信者が自動回答を要求しても、電話を設定したユーザーが手動で回答するように邪魔しないことを確認できます。
The UAS is responsible for deciding how to honor this preference. In general, the UAS makes an authorization decision based on the authenticated identity presented in the request using authentication mechanisms such as SIP Digest Authentication [RFC3261], the SIP Identity mechanism [RFC4474], or (within the restricted networks for which it is suitable) the SIP mechanism for asserted identity within trusted networks [RFC3325]. When making an authorization decision, the UAS should also use authorization information or policy available to the UAS. This decision-making MUST consider the risk model of the media session corresponding to the request, and the UAS MUST NOT answer without user input in cases where the privacy or security of the user would be compromised as a result. Making this determination is a matter of system or application design, and cannot in general be addressed by having a set of functions that are configurable on or off. Specific discussion of media sessions and appropriate policy is discussed in Section 7.
UASは、この好みを尊重する方法を決定する責任があります。一般に、UASは、SIPダイジェスト認証[RFC3261]、SIP IDメカニズム[RFC4474]、または（適切な制限付きネットワーク内）などの認証メカニズムを使用してリクエストに提示された認証されたIDに基づいて認証決定を下します。信頼できるネットワーク内でアサートされたアイデンティティのSIPメカニズム[RFC3325]。許可決定を下す場合、UASはUASが利用できる許可情報またはポリシーも使用する必要があります。この意思決定は、リクエストに対応するメディアセッションのリスクモデルを考慮する必要があり、結果としてユーザーのプライバシーまたはセキュリティが侵害される場合、UASはユーザーの入力なしでは答えてはなりません。この決定を行うことは、システムまたはアプリケーションの設計の問題であり、一般的に、オンまたはオフに設定できる一連の関数を持つことで対処することはできません。メディアセッションと適切なポリシーの具体的な議論については、セクション7で説明します。
The functions of the Answer-Mode and Priv-Answer-Mode header fields are similar; they both ask that the UAS handle the request as specified by the header field's value (automatic or manual). The difference is in the way the requests interact with the UAS's policy. A typical UAS will have different policies for handling each header field. For example, assume that the user of a UAS has placed that UAS into "meeting mode", indicating that she is engaged in an important activity and does not wish to be spuriously interrupted. The UAS might disallow automatic answering for Answer-Mode requests while in "meeting mode". However, that UAS might allow automatic answering for requests made with Priv-Answer-Mode. There will probably be differences in authorization policy. For example, a UAS might be configured such that callers on the "friends" list are allowed to make requests using Answer-Mode but not Priv-Answer-Mode. That same UAS might be configured to only allow callers on the "administrators" list to use Priv-Answer-Mode. This is different from always basing the behavior on the identity of the calling party. For example, assume caller "Bob" is on both the "friends" list and "administrators" list. If Bob wants his request to be processed according to the regular policy, he uses Answer-Mode. If Bob wants his request to be processed under the more restrictive "privileged" policy, he uses Priv-Answer-Mode.
Answer-ModeおよびPriv-Answer-Modeヘッダーフィールドの関数は似ています。どちらも、ヘッダーフィールドの値（自動またはマニュアル）で指定されているように、UASがリクエストを処理することを尋ねます。違いは、リクエストがUASのポリシーと相互作用する方法です。典型的なUASには、各ヘッダーフィールドを処理するためのさまざまなポリシーがあります。たとえば、UASのユーザーがUASを「ミーティングモード」に配置したと仮定して、彼女が重要な活動に従事しており、微妙に中断されることを望んでいないことを示しています。UASは、「会議モード」中に回答モード要求に対する自動応答を禁止する場合があります。ただし、UASは、Priv-Answerモードで行われたリクエストに対する自動応答を許可する場合があります。おそらく、承認ポリシーに違いがあります。たとえば、「Friends」リストの発信者は、Priv-Answer-Modeではなく回答モードを使用してリクエストを行うことが許可されるように、UASを構成する場合があります。その同じUASは、「管理者」リストの発信者のみがPRIV-Answer-Modeを使用できるように構成されている場合があります。これは、呼び出し政党の身元に常に基づいて行動することとは異なります。たとえば、発信者の「Bob」が「Friends」リストと「管理者」リストの両方にあると仮定します。ボブが通常のポリシーに従って彼の要求を処理することを望んでいる場合、彼は回答モードを使用します。ボブが、より制限的な「特権」ポリシーの下で彼の要求を処理することを望んでいる場合、彼はPriv-Answer-Modeを使用します。
A UAS SHOULD apply a stricter authorization policy to a request with Priv-Answer-Mode than it does to requests with Answer-Mode. The default policy SHOULD be to refuse requests containing Priv-Answer-Mode header fields unless the requester is authenticated and specifically authorized to make Priv-Answer-Mode requests. Failure to enforce such a policy leaves the user potentially vulnerable to abuses, as discussed in Section 7.
UASは、Answer-Modeを使用してリクエストよりも、Priv-Answer-Modeを使用して、より厳格な承認ポリシーをリクエストに適用する必要があります。デフォルトのポリシーは、要求者が認証され、特にPRIV-Answer-Modeリクエストを行うことを具体的に許可されていない限り、Priv-Answer-Modeヘッダーフィールドを含むリクエストを拒否することです。セクション7で説明したように、そのようなポリシーを強制しないと、ユーザーは虐待に対して脆弱に脆弱になります。
The use case envisioned for Priv-Answer-Mode relates to handling urgent requests from authorized callers. For example, assume Larry is a limousine driver working with a fleet dispatcher. Larry likes to provide a quiet environment for his car, so his communicator is configured for manual answer mode for all non-privileged calls, including push-to-talk (Answer-Mode: Auto) calls. Each time he gets a call, Larry's communicator chimes softly to alert him to the call. If the circumstances permit it, Larry presses the communicator in order to accept the call, the communicator sends a 200 (OK) response, and the calling party's talk-burst is played out through the communicator's loudspeaker. This treatment is delivered to incoming requests that have an Answer-Mode header field having values of "Manual" or "Auto" (or no Answer-Mode header field at all), no matter who the caller is.
Priv-Answer-Modeについて想定されているユースケースは、承認された発信者からの緊急の要求の処理に関連しています。たとえば、ラリーが艦隊の派遣者と協力するリムジンのドライバーであると仮定します。ラリーは彼の車に静かな環境を提供するのが好きなので、彼のコミュニケーターは、プッシュツートーク（回答 - モード：Auto）コールを含むすべての非具体的な呼び出しに対して手動回答モード用に構成されています。彼が電話を受けるたびに、ラリーのコミュニケーターは柔らかくチャイムして、彼に電話を警告します。状況がそれを許可する場合、ラリーは通話を受け入れるためにコミュニケーターを押します、コミュニケーターは200（OK）応答を送信し、呼び出し政党のトークバーストはコミュニケーターのスピーカーを通して行われます。この処理は、発信者が誰であろうと、「マニュアル」または「自動」（または回答モードヘッダーフィールドはまったくない）の値を持つ回答モードヘッダーフィールドを持つ着信リクエストに配信されます。
Larry's fleet dispatch operator is familiar with this policy, and needs to inform Larry about a critical matter. The dispatch operator tries several times to push-to-talk call Larry (including Answer-Mode: Auto in the requests), but the calls aren't accepted because Larry has fallen asleep, and therefore isn't pressing his communicator to accept the call.
ラリーの艦隊派遣オペレーターはこのポリシーに精通しており、重要な問題についてラリーに知らせる必要があります。ディスパッチオペレーターは数回、プッシュツートークコールラリー（回答モード：リクエストの自動を含む）を試しますが、ラリーが眠りに落ちたため、通話は受け入れられず、したがって、コミュニケーターに受け入れるように彼のコミュニケーターに押し付けられていません。電話。
The operator then presses his "urgent" button and calls Larry again. This time, the INVITE request carries a "Priv-Answer-Mode: Auto" header field. Larry's communicator checks the identity of the caller (using a SIP Identity assertion or functionally equivalent mechanism), and matches the operator's identity against the list of users allowed to do Priv-Answer-Mode. Since the operator is listed, the communicator immediately returns a 200 (OK) response accepting the call. The operator speaks, and the resulting talk-burst is summarily played out the loudspeaker on Larry's communicator, waking him up.
その後、オペレーターは「緊急」ボタンを押して、再びラリーに電話します。今回は、招待リクエストには「Priv-Answer-Mode：Auto」ヘッダーフィールドが搭載されています。Larryのコミュニケーターは、発信者のIDをチェックし（SIP IDアサーションまたは機能的に同等のメカニズムを使用して）、PRIV-Answer-Modeを実行することが許可されたユーザーのリストとオペレーターのIDを一致させます。オペレーターがリストされているため、通信機はすぐに200（OK）応答を返し、コールを受け入れます。オペレーターは話し、結果として得られるトークバーストは、ラリーのコミュニケーターのスピーカーを即座に演じ、彼を目覚めさせます。
The effect of requesting Priv-Answer-Mode is different than the effect of simply granting higher privilege to an Answer-Mode request based on the requester's identity and corresponding authorization level. This distinction is what allows the fleet operator to make polite (Answer-Mode: Auto) requests to Larry under normal conditions, and receive different handling (Priv-Answer-Mode: Auto) for a request having greater urgency.
Priv-Answer-Modeを要求する効果は、要求者のIDと対応する承認レベルに基づいて、回答モード要求に高い特権を単純に付与する効果とは異なります。この区別は、艦隊オペレーターが通常の条件下でラリーに丁寧に（回答モード：自動）リクエストを行い、より大きな緊急性を持つリクエストのために異なるハンドリング（PRIV-Answer-Mode：auto）を受け取ることを可能にするものです。
In normal operations, only one of either Answer-Mode or Priv-Answer-Mode would be used in an INVITE request. If both are present, the UAS will first test the authorization of the requester for Priv-Answer-Mode and, if authorized, process the request as if only Priv-Answer-Mode had been included. If the requester is not authorized for Priv-Answer-Mode, then the UAS will process the request as if only Answer-Mode had been included.
通常の操作では、招待状リクエストで使用される回答モードまたはPRIV-Answerモードのいずれかのうちの1つのみが使用されます。両方が存在する場合、UASは最初にpriv-answer-modeの要求者の承認をテストし、許可されている場合、priv-answer-modeのみが含まれているかのようにリクエストを処理します。要求者がPRIV-Answer-Modeを許可されていない場合、UASは回答モードのみが含まれているかのようにリクエストを処理します。
Both Answer-Mode and Priv-Answer-Mode allow a modifier of "require" (example: "Priv-Answer-Mode: Auto;require"). This modifier does not influence the UAS's policy in choosing whether to answer manually or automatically. The UAS decides whether or not to answer automatically based on other aspects of the request. The "require" modifier is only evaluated after the UAS has selected an answering mode. If the UAS's policy has resulted in an answering mode that is different from that specified in the request, the presence of the "require" modifier asks the UAS to reject the call. In the given example, the UAS is being asked to answer automatically if the caller is authorized for automatic answering under the "privileged" policy, and to reject the call (rather than answering manually) if the caller is not authorized for this mode. This is discussed in more depth in Section 4.5.
Answer-ModeとPriv-Answer-Modeの両方で「必要」の修飾子が許可されます（例： "PRIV-Answer-Mode：auto; require"）。この修飾子は、手動で回答するか自動的に回答するかを選択する際のUASのポリシーに影響を与えません。UASは、リクエストの他の側面に基づいて自動的に回答するかどうかを決定します。「必要」修飾子は、UASが応答モードを選択した後にのみ評価されます。UASのポリシーがリクエストで指定されたものとは異なる応答モードになった場合、「要求」モディファイアの存在がUASに呼び出しを拒否するように依頼します。指定された例では、UASは、「特権」ポリシーに基づく自動応答が発信者が許可されている場合、自動的に回答するように求められています。これについては、セクション4.5でより深く説明します。
A UA supporting the Answer-Mode and Priv-Answer-Mode header fields SHOULD indicate its support by including an option tag of "answermode" in the Supported header field of all requests it sends.
Answer-ModeおよびPriv-Answer-ModeヘッダーフィールドをサポートするUAは、送信するすべてのリクエストのサポートされているヘッダーフィールドに「AsseRmode」のオプションタグを含めることにより、そのサポートを示す必要があります。
To indicate that it supports the answer-mode negotiation feature, a UA MAY include an extensions parameter with a value that includes "answermode". Example:
Answer-Mode Negotiation機能をサポートすることを示すために、UAには「exwerMode」を含む値を持つ拡張機能パラメーターを含めることができます。例：
;extensions="answermode,100rel,gruu"
; extensions = "exwermode、100rel、gruu"
in the Contact header field of its REGISTER requests. This usage of feature tags is described in [RFC3840].
レジスタリクエストの連絡先ヘッダーフィールド。この機能タグの使用法は[RFC3840]で説明されています。
If a UA is dependent on support for callee capabilities in the registrar, it MAY include a Require header field with the value "pref" in its REGISTER request. This will cause the registrar to reject the request if the registrar does not support callee capabilities and caller preferences. Example:
UAがレジストラのCallee機能のサポートに依存している場合、レジスタリクエストに値「Pref」を持つ必要のあるヘッダーフィールドが含まれる場合があります。これにより、レジストラがCallee機能と発信者の好みをサポートしていない場合、レジストラはリクエストを拒否します。例：
Require: pref
要求：pref
A UAC supporting this specification MAY include an Answer-Mode or Priv-Answer-Mode header field in an INVITE where it wishes to influence the answering mode of the responding UAS.
この仕様をサポートするUACには、応答するUASの回答モードに影響を与えたい招待状の回答モードまたはPRIV-Answer-Modeヘッダーフィールドが含まれる場合があります。
Note: This is meaningful only in initial or dialog-forming INVITE requests. Answer-Mode and Priv-Answer-Mode header fields appearing in other requests are ignored. In general, if the request would not normally result in a notification to the user and acceptance by that user (for example, "ringing" and "answering"), then these extensions are not applicable.
注：これは、初期またはダイアログ形成の招待リクエストでのみ意味があります。他のリクエストに表示される回答モードおよびPRIV-Answer-Modeヘッダーフィールドは無視されます。一般に、リクエストが通常ユーザーへの通知とそのユーザーによる受け入れ（たとえば、「リンギング」や「応答」など）が得られない場合、これらの拡張機能は適用されません。
To request that the UAS answer only after having interacted with its user and receiving an affirmative instruction from that user, the UAC includes an Answer-Mode or Priv-Answer-Mode header field having a value of "Manual". Example:
UASは、ユーザーと対話し、そのユーザーから肯定的な指導を受けた後にのみ回答することを要求するために、UACには「マニュアル」の値を持つ回答モードまたはPRIV-Answer-Modeヘッダーフィールドが含まれます。例：
Answer-Mode: Manual
回答モード：マニュアル
To request that the UAS answer manually, and ask that it reject the INVITE request if unable or unwilling to answer manually, the UAC includes an Answer-Mode or Priv-Answer-Mode header field having a value of "Manual" and a parameter of "require". Example:
UASが手動で回答するように要求し、手動で回答できないか、回答したくない場合に招待リクエストを拒否するように依頼するには、UACには「マニュアル」の値とパラメーターを持つ回答モードまたはPriv-Answer-Modeヘッダーフィールドが含まれています。"必須"。例：
Answer-Mode: Manual;require
回答モード：マニュアル;要求
To request that the UAS answer automatically without waiting for input from the user, the UAC includes an Answer-Mode or Priv-Answer-Mode header field having a value of "Auto". Example:
UASがユーザーからの入力を待たずに自動的に回答することを要求するために、UACには「Auto」の値を持つAnswer-ModeまたはPriv-Answer-Modeヘッダーフィールドが含まれています。例：
Answer-Mode: Auto
回答モード：自動
To request that the UAS answer automatically, and ask that it reject the INVITE request if unable or unwilling to answer automatically, the UAC includes an Answer-Mode or Priv-Answer-Mode header field having a value of "Auto" and a parameter of "require". Example:
UASが自動的に回答することを要求し、自動的に回答できないか、回答したくない場合に招待リクエストを拒否するように依頼するには、UACには「Auto」の値とパラメーターを持つAnswer-ModeまたはPriv-Answer-Modeヘッダーフィールドが含まれています。"必須"。例：
Answer-Mode: Auto;require
回答モード：auto; require
To require that the UAS either support this extension or reject the request, the UAC includes a Require header field having the value "answermode". This does not actually force the UAS to automatically answer, it just requires that the UAS either understand this extension or reject the request. We do not have a SIP negotiation technique to force specific behavior. Rather, the desired behavior is indicated in the SIP extension itself. Example:
UASがこの拡張子をサポートするか、リクエストを拒否することを要求するために、UACには値「exwermode」を持つ必要のあるヘッダーフィールドが含まれます。これにより、実際にUASが自動的に回答することはなく、UASがこの拡張機能を理解するか、リクエストを拒否する必要があります。特定の行動を強制するためのSIP交渉手法はありません。むしろ、SIP拡張自体に望ましい動作が示されています。例：
Require: answermode
要求：exwermode
To request that retargeting proxies in the path preferentially select targets that have indicated support for this extension in their registration, a UAC includes an Accept-Contact header field with an extensions parameter having a value of "answermode". This usage of Accept-Contact is described in [RFC3841]. This would normally be used in conjunction with the "Require: answermode" header field as described above. Example:
登録でこの拡張機能のサポートを示しているパスでのリターゲティングプロキシを優先的に選択するターゲットを要求するために、UACには、「exwerRemode」の値を持つ拡張パラメーターを持つ受け入れコンタクトヘッダーフィールドが含まれます。この受け入れコンタクトの使用は[RFC3841]で説明されています。これは通常、上記のように「require：exwermode」ヘッダーフィールドと組み合わせて使用されます。例：
Require: answermode Accept-Contact:
*;extensions="answermode";methods="INVITE"
To request that retargeting proxies in the path do not select targets that have indicated non-support for this extension in their registration, a UAC includes an Accept-Contact header field with an extensions parameter having a value of "answermode" and an option field of "require". This usage of Accept-Contact is described in [RFC3841]. This would normally be used in conjunction with the "Require: answermode" header field as described above. Example:
パスでのリターゲティングプロキシを要求するには、登録でこの拡張機能の非サポートを示すターゲットを選択しないでください。UACには、「exastermode」の値を持つ拡張パラメーターとオプションフィールドを持つextensionsパラメーターを備えたAccept-contactヘッダーフィールドが含まれます。"必須"。この受け入れコンタクトの使用は[RFC3841]で説明されています。これは通常、上記のように「require：exwermode」ヘッダーフィールドと組み合わせて使用されます。例：
Require: answermode Accept-Contact:
*;extensions="answermode"; methods="INVITE";require
To request that retargeting proxies in the path exclusively select targets that have indicated support for this extension in their registration, a UAC includes an Accept-Contact header field extensions parameter having a value of "answermode" and options of "require" and "explicit". This usage of Accept-Contact is described in [RFC3841]. This would normally be used in conjunction with the "Require: answermode" header field as described above. Example:
パスでのリターゲティングプロキシのみを要求するには、登録におけるこの拡張機能のサポートを示すターゲットのみを選択することを要求するために、UACには、「exwerRemode」の値と「要求」と「明示的」のオプションを持つ受け入れコンタクトヘッダーフィールド拡張パラメーターを含みます。。この受け入れコンタクトの使用は[RFC3841]で説明されています。これは通常、上記のように「require：exwermode」ヘッダーフィールドと組み合わせて使用されます。例：
Require: answermode Accept-Contact:
*;extensions="answermode";
methods="INVITE";require;explicit
The general procedure at all intermediate proxies, including the UAC's serving proxy or proxies and the UAS's serving proxy or proxies, is to ignore the Answer-Mode header field. However, the serving proxies (proxies responsible for resolving an address-of-record (AOR) into a registered contact) MAY exercise control over the requested answer mode, either inserting or deleting an Answer-Mode or Priv-Answer-Mode header field or altering the value of an existing header field, in accord with local policy. This could result in behavior that is inconsistent with user expectations (such as having a call that was intended to be a diagnostic loopback answered by a human) and consequently proxies MUST NOT insert, delete, or alter Answer-Mode or Priv-Answer-Mode header fields unless explicitly authorized to do so by an external agreement between the proxy operator and the user of the UA that the proxy is serving. These serving proxies MAY also reject a request according to local policy and, if they do so, SHOULD use the rejection codes as specified below for the UAS.
UACのサービングプロキシまたはプロキシやUASのサービスプロキシまたはプロキシなど、すべての中間プロキシでの一般的な手順は、回答モードヘッダーフィールドを無視することです。ただし、サービングプロキシ（レコードアドレス（AOR）を登録連絡先に解決する責任）は、要求された回答モードを制御することができます。ローカルポリシーと一致して、既存のヘッダーフィールドの価値を変更します。これにより、ユーザーの期待と矛盾する動作が生じる可能性があります（人間が回答する診断ループバックであることを意図したコールを持つなど）。その結果、プロキシは回答モードまたはPRIV-Answer-Modeを挿入、削除、または変更してはなりません。ヘッダーフィールドは、プロキシオペレーターとプロキシが提供しているUAのユーザーとの間の外部契約によって明示的に許可されていない限り。また、これらのサービスを提供するプロキシは、ローカルポリシーに従ってリクエストを拒否する場合があり、そうすれば、UASに以下に指定されているように拒否コードを使用する必要があります。
One of the well-known issues with forking is the problem of multiple acceptance. If an INVITE request is forked to several UASs and more than one replies with a 200 (OK) response, the conventional approach is to continue the dialog with the first respondent and tear down the dialog (using BYE requests) with all other respondents.
フォーキングに関する有名な問題の1つは、複数の受け入れの問題です。招待リクエストがいくつかのUASSにフォークされ、複数の返信が200（OK）応答で返信された場合、従来のアプローチは、最初の回答者とのダイアログを継続し、他のすべての回答者とのダイアログ（BYEリクエストを使用）を取り壊すことです。
While this problem exists without an auto-answer negotiation capability, it is apparent that widespread adoption of UAs that engage in auto-answer behavior will exacerbate the multiple acceptance problem. Consequently, systems designers need to take this aspect into consideration. In general, auto-answer is NOT RECOMMENDED in environments that include parallel forking.
この問題は自動回答能力なしに存在しますが、自動回答に従事するUASの広範な採用が複数の受け入れ問題を悪化させることは明らかです。その結果、システム設計者はこの側面を考慮する必要があります。一般に、並列フォーキングを含む環境では自動回答は推奨されません。
As an alternative, it might be reasonable to use a variation on manual-answer combined with no alerting and early media. In this approach, the initial message or talk-burst is transmitted as early media to all recipients, where it is displayed or played out. Any response utterance (pushing the transmit key and talking) from the user of a UAS following this would serve as an "acceptance", resulting in a 200 (OK) response being transmitted by their UAS. Consequently, the race-condition for acceptance would be limited to the subset of UAs actually responding under user control, rather than the full set of UAs to which the request was forked.
別の方法として、手動回答のバリエーションを使用して、アラートや初期のメディアを組み合わせて使用することが合理的かもしれません。このアプローチでは、最初のメッセージまたはトークバーストがすべての受信者に初期のメディアとして送信され、そこで表示または再生されます。これに続いてUASのユーザーからの応答の発話（送信キーを押し、話す）は「受け入れ」として機能し、UASによって200（OK）応答が送信されます。その結果、受け入れのためのレース条件は、リクエストがフォークされたUASの完全なセットではなく、ユーザー制御下で実際に応答するUASのサブセットに限定されます。
Another alternative would be to use dynamic conferencing instead of forking. In this approach, instead of forking the request, a conference would be initiated and all registered UAs invited into that conference. The mixer attached to the conference would then mediate traffic flows appropriately.
もう1つの選択肢は、フォーキングの代わりに動的な会議を使用することです。このアプローチでは、リクエストを分岐する代わりに、会議が開始され、登録されたすべてのUAがその会議に招待されます。会議に取り付けられたミキサーは、トラフィックフローを適切に媒介します。
For a request having an Answer-Mode value of "Manual" and not having an Answer-Mode parameter of "require", the UAS SHOULD defer accepting the request until the user of the UAS has confirmed willingness to accept the request. This behavior MAY be altered as needed for unattended UASs or other local characteristics or policy. For example, an auto-attendant or Public Switched Telephone Network (PSTN) gateway system that always answers automatically would go ahead and answer, despite the presence of the "Manual" Answer-Mode header field value.
「マニュアル」の回答モード値があり、「要求」の回答モードパラメーターを持たないリクエストの場合、UASは、UASのユーザーがリクエストを受け入れる意欲を確認するまでリクエストを受け入れる必要があります。この動作は、無人のUASSまたは他の局所的な特性またはポリシーに必要に応じて変更される場合があります。たとえば、「手動」の回答モードヘッダーフィールド値が存在しているにもかかわらず、自動的に常に回答する自動アテナントまたはパブリックスイッチ付き電話ネットワーク（PSTN）ゲートウェイシステムが先に進みます。
For a request having an Answer-Mode value of "Manual" and an Answer-Mode parameter of "require", the UAS MUST defer accepting the request until the user of the UAS has confirmed willingness to accept the request. If the UAS is not capable of answering the request in this "Manual" mode or is unwilling to do so, it MUST reject the request, SHOULD do so with a "403 (Forbidden)" response, and MAY include a reason phrase of "manual answer forbidden".
「マニュアル」の回答モード値と「要求」の回答モードパラメーターを持つリクエストの場合、UASは、UASのユーザーがリクエストを受け入れる意欲を確認するまで、リクエストを受け入れる必要があります。UASがこの「マニュアル」モードでリクエストに応答できない場合、またはそうすることを嫌がる場合、リクエストを拒否しなければなりません。「403（禁止）」応答でそれを行う必要があり、理由が含まれる場合があります。禁止されている手動回答」。
For a request having an Answer-Mode value of "Auto", the UAS SHOULD, if the calling party is authenticated and authorized for automatic answering, accept the request without further user input. The UAS MAY, according to local policy or user preferences, treat this request as it would treat a request having an Answer-Mode with a value of "Manual" or having no Answer-Mode header field. If the calling party is not authenticated and authorized for automatic answer, the UAS MAY either handle the request as per "manual", or reject the request. If the UAS rejects the request, it SHOULD do so with a "403 (Forbidden)" response, and MAY include a reason phrase of "automatic answer forbidden". There may be an interaction with [RFC3261] section 23.2, which in some cases requires user validation of certificates used for S/MIME. Since this places the same interrupt burden on the user as would manually answering the request, a UAS experiencing this requirement for user validation of a request that requires automatic answering SHOULD reject the request with a "403 (Forbidden)" response and MAY include a reason phrase of "certificate validation requires user input not compatible with automatic answer." For a request having an Answer-Mode value of "Auto" and an Answer-Mode parameter of "require", the UAS SHOULD, if the calling party is authenticated and authorized for automatic answering, accept the request. The UAS MUST NOT allow "manual" answer of this request, but MAY reject it. If, for whatever reason, the UAS chooses not to accept the request automatically, the UAS MUST reject the request, SHOULD do so with a "403 (Forbidden)" response, and MAY include a reason phrase of "automatic answer forbidden".
「Auto」の回答モード値を持つリクエストの場合、UASは、発信者が自動応答を認証および承認されている場合は、ユーザー入力なしでリクエストを受け入れる必要があります。UASは、ローカルポリシーまたはユーザーの好みによれば、このリクエストを扱い、「マニュアル」の値を持つ応答モードを持つか、回答モードヘッダーフィールドがないリクエストを扱う可能性があります。呼び出し当事者が自動回答に対して認証され、承認されていない場合、UASは「マニュアル」に従ってリクエストを処理するか、リクエストを拒否できます。UASがリクエストを拒否した場合、「403（禁止）」応答でそれを行う必要があり、「禁じられている自動回答」の理由フレーズが含まれる場合があります。[RFC3261]セクション23.2との相互作用がある場合があります。セクション23.2では、S/MIMEに使用される証明書のユーザー検証が必要な場合があります。これは、リクエストに手動で応答するのと同じ割り込み負荷をユーザーに置くため、自動応答が必要なリクエストのユーザー検証のこの要件を経験しているUASは、「403（禁止）」応答でリクエストを拒否し、理由を含めることができます。「証明書の検証には、自動回答と互換性がないユーザー入力が必要です。」「Auto」の回答モード値と「要求」の回答モードパラメーターを持つリクエストの場合、UASは、自動応答のために認証および承認されている場合はUASが必要です。UASは、このリクエストの「手動」の回答を許可してはなりませんが、拒否する場合があります。何らかの理由で、UASがリクエストを自動的に受け入れないことを選択した場合、UASはリクエストを拒否する必要があり、「403（禁止）」応答でそれを行う必要があり、「禁じられた自動回答」の理由フレーズが含まれる場合があります。
Similar behavior applies for Priv-Answer-Mode, except that the policy for authorization may be different (and generally more stringent).
同様の動作は、承認のポリシーが異なる場合がある（そして一般的により厳しい）ことを除いて、PRIV回答モードにも適用されます。
The Answer-Mode or Priv-Answer-Mode header field can be inserted by a UAS into a response in order to indicate how it handled the associated request with respect to automatic answering functionality. The UAC might use this information to inform the user or otherwise adapt the behavior of the user interface. The handling is indicated by the value of the header field, as follows:
Answer-ModeまたはPriv-Answer Headerフィールドは、自動回答機能に関して関連する要求をどのように処理したかを示すために、UASによって応答に挿入できます。UACは、この情報を使用してユーザーに通知するか、ユーザーインターフェイスの動作を適応させる場合があります。ハンドリングは、次のように、ヘッダーフィールドの値によって示されます。
Manual: The UAS responded after the user of the UAS interacted with the user interface (UI) of the UAS in such a way as to indicate that the user desires the UAS to accept the request.
マニュアル：UASのUASは、UASのユーザーがUASのユーザーインターフェイス（UI）と対話し、ユーザーがUASにリクエストを受け入れることを望んでいることを示す後に応答しました。
Auto: The UAS responded automatically, without waiting for the user of the UAS to interact with the UI of the UAS in such a way as to indicate that the user desires the UAS to accept the request.
AUTO：UASは、UASのユーザーがUAのUIと対話するのを待たずに自動的に応答しました。
The Answer-Mode and Priv-Answer-Mode header fields, when used in responses, are only valid in a 200 (OK) response to an INVITE request.
回答で使用される場合、Answer-ModeおよびPriv-Answer-Modeヘッダーフィールドは、招待リクエストに対する200（OK）応答でのみ有効です。
A UAS supporting this specification inserts an Answer-Mode or Priv-Answer-Mode header field into the 200 (OK) response to an INVITE request when it wishes to inform the UAC as to whether the request was answered manually or automatically. It is reasonable for a UAS to assume that if the UAC included an Answer-Mode header field in the request, it would probably like to see an Answer-Mode header field in the response. The full rationale for including or not including this header field in a response is outside of the scope of this specification, and is sensitive to the privacy concerns of the user of the UAS. For example, informing the calling party that a call was answered manually might reveal the presence of an "actual human" at the responding UAS. While in the general case the ensuing conversation would also reveal this same information, there might be cases where this information might need to be protected. Consequently, UASs supporting this specification SHOULD include appropriately configurable policy mechanisms for making this determination, and the default configuration SHOULD be to exclude this header field from responses.
この仕様をサポートするUASは、リクエストが手動または自動的に回答されたかどうかをUACに通知したい場合に、回答モードまたはPRIV回答ヘッダーフィールドを招待リクエストに200（OK）応答に挿入します。UASがRequestにUACにAnswer-Modeヘッダーフィールドが含まれている場合、おそらく応答にAnswer-Modeヘッダーフィールドが表示されることを想定することは合理的です。このヘッダーフィールドを応答に含めるかどうかについての完全な理論的根拠は、この仕様の範囲外であり、UASのユーザーのプライバシーの懸念に敏感です。たとえば、呼び出し政党に手動で応答されたことを通知することは、応答するUASに「実際の人間」の存在を明らかにするかもしれません。一般的なケースでは、次の会話もこの同じ情報を明らかにしますが、この情報を保護する必要がある場合がある場合があります。したがって、この仕様をサポートするUASSには、この決定を行うための適切に構成可能なポリシーメカニズムを含める必要があります。デフォルトの構成は、このヘッダーフィールドを応答から除外することです。
A UAC MAY use the value of the Answer-Mode or Priv-Answer-Mode header field, if present, to adapt the user interface and/or inform the user about the handling of the request. For example, the user of a push-to-talk system might speak differently if she knows that the called party answered "in person" vs. having the call blare out of an unattended speaker phone.
UACは、存在する場合、Answer-ModeまたはPriv-Answer-Modeヘッダーフィールドの値を使用して、ユーザーインターフェイスを適応させたり、ユーザーにリクエストの処理について通知したりできます。たとえば、プッシュツートークシステムのユーザーは、呼び出されたパーティーが「直接」と答えたことを知っている場合、無人のスピーカー電話からコールブレアを出していることを知っていれば、異なって話すことがあります。
The following examples show Bob registering a contact that supports the negotiation of answering mode. Alice then calls Bob with an INVITE request, asking for automatic answering and explicitly asking that the request not be routed to contacts that have not indicated support for this extension. Further, Alice requires that the request be rejected if Bob's UA does not support negotiation of answering mode. Bob replies with a 200 (OK) response indicating that the call was answered automatically.
次の例は、ボブが応答モードの交渉をサポートする連絡先を登録することを示しています。その後、アリスは招待状リクエストでボブに電話をかけ、自動応答を求め、この拡張機能のサポートを示さない連絡先にリクエストがルーティングされないことを明示的に求めます。さらに、アリスは、ボブのUAが応答モードの交渉をサポートしていない場合、リクエストを拒否することを要求しています。ボブは、コールが自動的に回答されたことを示す200（OK）応答で返信します。
The Content-Length header field shown in the examples contains a placeholder "..." instead of a valid Content-Length. Furthermore, the SDP bodies that would be expected in the INVITE requests and 200 (OK) responses are not shown.
例に示されているコンテンツ長ヘッダーフィールドには、有効なコンテンツレングスの代わりにプレースホルダー「...」が含まれています。さらに、招待リクエストで予想されるSDPボディと200（OK）の応答は表示されません。
In the following example, Bob's UA is registering and indicating that it supports the answermode extension.
次の例では、ボブのUAが登録しており、回答拡張機能をサポートしていることを示しています。
REGISTER sip:example.com SIP/2.0
From: Bob<sip:bob@example.com>
To: Bob <sip:bob@example.com>
CallID: hh89as0d-asd88jkk@cell-phone.example.com
CSeq: 1 REGISTER
Contact: sip:cell-phone.example.com;
;audio
;+sip.extensions="answermode"
;methods="INVITE,BYE,OPTIONS,CANCEL,ACK"
;schemes="sip"
In this example, Alice is calling Bob and asking Bob's UA to answer automatically. However, Alice is willing for Bob to answer manually if Bob's policy is to prefer manual answer, so Alice does not include a ";require" modifier on "Answer-Mode: Auto".
この例では、アリスはボブに電話をかけ、ボブのUAに自動的に答えるように頼んでいます。ただし、ボブのポリシーが手動回答を好む場合、アリスはボブに手動で答えることを望んでいるため、アリスは「回答モード：auto」に「;要求」モディファイアを含めません。
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>
Call-ID:3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:alice@client.atlanta.example.com;transport=tcp>
Require: answermode
Accept-contact:*;require;explicit;extensions="answermode"
Answer-Mode: Auto
Content-Type: application/sdp
Content-Length: ...
Here, Bob has accepted the call and his UA has answered automatically, which it indicates in the 200 (OK) response.
ここで、ボブはコールを受け入れ、彼のUAは自動的に回答しました。これは200（OK）応答で示されています。
SIP/2.0 200 OK
Via: SIP/2.0/TCP client-alice.example.com:5060; branch=z9hG4bK74b43
From: Alice <sip:alice@example.com>;tag=9fxced76sl
To: Bob <sip:bob@example.com>;tag=8321234356
Call-ID: 3848276298220188511@client-alice.example.com
CSeq: 1 INVITE
Contact: <sip:bob@client.biloxi.example.com;transport=tcp>
Answer-Mode: Auto
Content-Type: application/sdp
Content-Length: ...
This specification adds the ability for a UAC to request potentially risky user interface behavior relating to the acceptance of an INVITE request by the UAS receiving the request. Specifically, the UAC can request that the UAS accept the request without input to the UAS by the user of the UAS (Answer-Mode: Auto).
この仕様により、UACがリクエストを受信したUASによる招待リクエストの受け入れに関連する潜在的にリスクの高いユーザーインターフェイス動作を要求する機能が追加されます。具体的には、UACは、UASのユーザーによるUASへの入力なしで、UASがRequestを受け入れるように要求できます（Answer-Mode：Auto）。
There are several attacks possible here -- the most obvious being the ability to turn a phone into a remote listening device without its user being aware. Additional potential attacks include reverse charge fraud, unsolicited push-to-talk communications (spam over push-to-talk (SPTT)), playout of obnoxious noises (the "whoopee cushion" attack), battery-rundown denial of service, "forced busy" denial of service, running up the victim's data transport bill, and phishing via session insertion (where an ongoing session is replaced by another without the victim's awareness).
ここにはいくつかの攻撃があります - 最も明白なのは、ユーザーが気づかずに電話をリモートリスニングデバイスに変える能力です。追加の潜在的な攻撃には、逆充電詐欺、未承諾のプッシュツートークコミュニケーション（プッシュトゥトーク（SPTT）のスパム）、不快なノイズの再生（「フーピークッション」攻撃）、バッテリーランドダウンサービスの拒否」が含まれます。忙しい「奉仕の否定、被害者のデータ輸送手形の実行、およびセッション挿入によるフィッシング（継続的なセッションは、被害者の認識なしに他のセッションに置き換えられます）。
Since SIP implementations do not commonly implement end-to-end message protections, this specification is completely dependent on transitive security across SIP proxies. Any misbehaving proxy can insert, delete, and/or alter the contents of the Answer-Mode and Priv-Answer-Mode header fields, and in general can do so without being noticed by either the UAC or UAS. Consequently, it is critical that any proxies in the path be not only trusted, but worthy of that trust. While proxies do not generally intentionally insert, delete, or alter the Answer-Mode and Priv-Answer-Mode header fields, this specification does note a use case for such manipulation by proxies acting on behalf of the user of a UAC or UAS that has limited support for the authentication or policy enforcement needed to securely exercise these extensions. Proxies that perform such extension-sensitive manipulation MUST therefore provide complete policy enforcement, as per the minimal policy discussed in Section 7.4.
SIPの実装は一般にエンドツーエンドのメッセージ保護を実装していないため、この仕様はSIPプロキシ全体の推移的なセキュリティに完全に依存しています。誤動作プロキシは、Answer-ModeおよびPriv-Answer-Modeヘッダーフィールドの内容を挿入、削除、および/または変更できます。一般に、UACまたはUASのいずれにも気付かれることなく、それを行うことができます。その結果、パス内のプロキシは信頼されるだけでなく、その信頼に値することが重要です。プロキシは一般に意図的に挿入、削除、または変更を変更しませんが、この仕様は、UACまたはUASのユーザーに代わって行動するプロキシによるそのような操作のユースケースに注目しています。これらの拡張機能を安全に行使するために必要な認証またはポリシーの執行に対する限られたサポート。したがって、このような拡張に敏感な操作を実行するプロキシは、セクション7.4で説明した最小限のポリシーに従って、完全なポリシー執行を提供する必要があります。
The existing body of SIP work provides strong capabilities for authentication of requests, prevention of man-in-the-middle attacks, protection of the privacy and integrity of media flows, and so on (although as noted above, these capabilities usually rely on transitive trust across proxies). The behaviors added by the extensions in this document raise additional possibilities for attacks against media flows not completely addressed by existing SIP work, and therefore require analysis in this document.
SIP作業の既存の本体は、リクエストの認証、中間の攻撃の防止、メディアフローのプライバシーの保護と整合性などの強力な機能を提供します（ただし、上記のように、これらの機能は通常、推移的に依存していますプロキシ全体で信頼）。このドキュメントの拡張機能によって追加された動作は、既存のSIP作業によって完全に対処されていないメディアフローに対する攻撃の追加の可能性を高めているため、このドキュメントで分析が必要です。
Media attacks can be loosely categorized as:
メディア攻撃は、次のようにゆるく分類できます。
Insertion: Media is inserted into and played out by the victim UA without consent of the UA's user.
挿入：メディアは、UAのユーザーの同意なしに、被害者UAに挿入され、再生されます。
Interception: The victim UA's media acquisition facility (such as a microphone or camera) is activated, producing a media stream, without the consent of the UA's user.
インターセプト：被害者UAのメディア獲得施設（マイクやカメラなど）がアクティブ化されており、UAのユーザーの同意なしにメディアストリームを作成します。
The danger of abuse varies greatly depending on the media characteristics of the session being established. Since the expressive range of media sessions that can be established by SIP is unbounded, we might find it more effective to model loose categories of media modality rather than explicitly describing every possible scenario. Security analysis can then be applied per modality.
虐待の危険性は、確立されているセッションのメディア特性によって大きく異なります。SIPによって確立できるメディアセッションの表現力豊かな範囲は無制限であるため、あらゆる可能なシナリオを明示的に説明するのではなく、メディアモダリティのゆるいカテゴリをモデル化する方が効果的であると感じるかもしれません。セキュリティ分析は、モダリティごとに適用できます。
The media modalities of interest appear to be:
関心のあるメディアのモダリティは次のとおりです。
UAC-sourced (Inbound) Unidirectional Media Insertion: Sensitive media flows from the UAC and is rendered by the UAS, annoying the user of the UAS or disrupting the function of the UAS. We refer to this as the "whoopee-cushion" attack because of its utility in replicating the rude-noise-making seat cushion. The danger of this attack is quite literally amplified by a loudspeaker apparatus attached to the victim UAS. Media that has minimal secondary implication (such as sending a move in a chess game to a computer that isn't running a chess game) is related, but of far less significance. This sort of attack can also have other consequences, such as discharging the victim's battery or increasing charges for data transport to be paid by the victim.
UACソースの（インバウンド）一方向のメディア挿入：UACからの敏感なメディアフローは、UASによってレンダリングされ、UASのユーザーを悩ませたり、UASの機能を混乱させたりします。これは、失礼なノイズ作りのシートクッションを複製する効用のため、「フーピークッション」攻撃と呼びます。この攻撃の危険性は、被害者UASに付属しているスピーカー装置によって文字通り増幅されます。二次的な意味合いを最小限に抑えるメディア（チェスゲームを実行していないコンピューターにチェスゲームの動きを送信するなど）は関連していますが、それほど重要ではありません。この種の攻撃は、被害者のバッテリーを排出したり、被害者によって支払われるデータ輸送の料金の増加など、他の結果をもたらす可能性があります。
UAS-sourced (Outbound) Unidirectional Media Interception: Sensitive media flows from the UAS and is rendered by the UAC, violating the privacy of the user of the UAS. We refer to this as the "bug-my-phone" attack because that would appear to be the primary attack motivator.
UASソース（アウトバウンド）単方向メディア傍受：UASからの敏感なメディアフローは、UACによってレンダリングされ、UASのユーザーのプライバシーに違反します。これを「バグマイフォン」攻撃と呼んでいます。これは、それが主要な攻撃の動機付けのように見えるからです。
Bidirectional Media Insertion or Interception: Bidirectional media is the common case when SIP is used in a voice-over-IP scenario or "traditional phone call". Once a media flow is established, both ends send and receive media without further engagement. The media information is presumed to be sensitive -- that is, if intercepted it damages the victim's privacy, and if inserted, it annoys or interferes with the recipient. Attacks of this sort might produce either the "whoopee-cushion" or "bug-my-phone" scenarios, potentially even simultaneously.
双方向のメディアの挿入または傍受：双方向のメディアは、SIPがボイスオーバーIPシナリオまたは「従来の電話」で使用される場合の一般的なケースです。メディアの流れが確立されると、両端はメディアを送信および受け取り、それ以上の関与なしに受け取ります。メディア情報は敏感であると推定されます。つまり、傍受された場合、被害者のプライバシーに損害を与え、挿入された場合、受信者を悩ませたり妨害したりします。この種の攻撃は、「フーピークッション」または「バグマイフォン」シナリオのいずれかを生成する可能性があります。
It seems reasonable to consider the "bug-my-phone" attack as being in a different class (potentially far more severe) than the "whoopee-cushion" attack. This distinction suggests that security policy could be established in different and presumably less restrictive fashion for inbound media flows than for outbound media flows. The set of callers from which a user would be willing to automatically accept inbound media is reasonably much broader than the set of callers to which a user would be willing to automatically grant outbound media access, although this may not be true in all environments, especially those where reception of unwanted media has unwanted financial consequences.
「バグマイフォン」攻撃を「フーピークッション」攻撃とは異なるクラス（潜在的にはるかに深刻な）にあると考えるのは合理的と思われます。この区別は、セキュリティポリシーが、アウトバウンドメディアフローよりもインバウンドメディアフローの場合、異なるとおそらく制限性の低い方法で確立できることを示唆しています。ユーザーがインバウンドメディアを自動的に受け入れる意思のある発信者のセットは、ユーザーがアウトバウンドメディアアクセスを自動的に許可する意思がある発信者のセットよりもかなり広いですが、これはすべての環境、特にすべての環境では当てはまらない場合があります。望ましくないメディアの受容には不要な財政的結果があります。
For example, assume a UA is designed such that it can be used to receive push-to-talk calls to a loudspeaker, and it can be used as a "baby monitor" (has an open mic and streams received audio to listeners). The policy for activating the push-to-talk loudspeaker would probably need to be reasonably broad (perhaps "all the user's buddies"). However, the policy for the baby monitor would need to be very narrow (perhaps "only the baby's mother") or even completely closed. The minimal policy defined in Section 7.4 explicitly forbids the "baby monitor" functionality.
たとえば、UAがスピーカーへのプッシュツートークコールを受信するために使用できるように設計されていると仮定し、「ベビーモニター」として使用できます（オープンマイクがあり、ストリームはリスナーにオーディオを受け取りました）。プッシュツートークスピーカーをアクティブ化するためのポリシーは、おそらく合理的に広く必要である必要があります（おそらく「すべてのユーザーの仲間」）。ただし、ベビーモニターのポリシーは非常に狭く（おそらく「赤ちゃんの母親だけ」）、または完全に閉じている必要があります。セクション7.4で定義された最小限のポリシーは、「ベビーモニター」機能を明示的に禁止しています。
In the most common use cases, the security aspects are somewhat mitigated by design aspects of the application. For example, in traditional telephony, the called party is alerted to the request (the phone rings), no media session is established without the acceptance of the called party (picking up the phone), and the media path is most commonly delivered to a single-user handset. Consequently, this application (although bidirectional) is relatively secure against both media insertion and media interception attacks of the sort enabled by the extensions in this document. The use of policy-free automatic-answering devices (like answering machines) and amplifiers (speakerphones and call-screening devices) weakens this defense.
最も一般的なユースケースでは、セキュリティの側面は、アプリケーションの設計面によって多少軽減されます。たとえば、従来のテレフォニーでは、呼び出されたパーティーがリクエスト（電話のリング）に警告され、呼び出されたパーティーの受け入れなしにメディアセッションは確立されません（電話を拾う）、メディアパスは最も一般的に配信されます。シングルユーザーハンドセット。したがって、このアプリケーション（双方向）は、このドキュメントの拡張機能によって有効になった種類のメディア挿入とメディア傍受攻撃の両方に対して比較的安全です。ポリシーのない自動回答デバイス（応答機の留置など）およびアンプ（スピーカーホンとコールスクリーニングデバイス）を使用すると、この防御が弱まります。
In push-to-talk applications, media can be sent from UAC to UAS without user oversight, but no media is sent from the called UAS without user input (the "push" of "push-to-talk"). Consequently, there is no "bug-my-phone" attack opportunity. Further, screening of the UAC by eliminating UAC identities not on some sort of "white list" (often, a buddy list) reduces the threat of "whoopee cushion" attacks (except from one's buddies, of course).
プッシュツートークアプリケーションでは、メディアはユーザーの監視なしでUACからUASに送信できますが、ユーザー入力なしで呼ばれるUASからメディアは送信されません（「プッシュトーク」の「プッシュ」）。その結果、「バグマイフォン」攻撃の機会はありません。さらに、何らかの「白いリスト」（多くの場合、相棒リスト）ではないUACのアイデンティティを排除することによりUACのスクリーニングは、「フーピークッション」攻撃の脅威を減らします（もちろん、自分の仲間を除く）。
Similar approaches apply to most applications. Insertion can be controlled (but not eliminated) by combining identity mechanisms with simple authorization policy, and interception can be effectively eliminated by combining strong identity mechanisms with aggressive authorization policy and/or user interaction.
ほとんどのアプリケーションにも同様のアプローチが適用されます。挿入は、アイデンティティメカニズムを単純な認証ポリシーと組み合わせることにより制御できます（排除できません）。強力なアイデンティティメカニズムと積極的な認可ポリシーおよび/またはユーザーの相互作用を組み合わせることで、傍受を効果的に排除できます。
The extensions described in this document provide mechanisms by which a UAC can request that a UAS not deploy two of the five defensive mechanisms listed below -- user alerting and user acceptance. In order for this not to produce undue risk of insertion attacks or increased risk of interception attacks, we are therefore forced to rely on the remaining defensive mechanisms. This document defines a minimum threshold for satisfactory security. Certainly more restrictive policies might reasonably be used, but any policy less restrictive than the approach described below is very likely to result in significant security issues.
このドキュメントで説明されている拡張機能は、UACがUASが以下にリストされている5つの防御メカニズムのうち2つを展開しないことを要求できるメカニズムを提供します - ユーザーの警告とユーザーの受け入れ。したがって、これが挿入攻撃の過度のリスクや傍受攻撃のリスクの増加を引き起こさないために、残りの防御メカニズムに依存することを余儀なくされます。このドキュメントは、満足のいくセキュリティの最小しきい値を定義しています。確かに、より制限的なポリシーが合理的に使用される可能性がありますが、以下で説明するアプローチよりも制限が少ないポリシーは、重大なセキュリティの問題をもたらす可能性が非常に高いです。
From the previous discussion of risks, attacks, and vulnerabilities, we can derive five defensive mechanisms available at the application level:
リスク、攻撃、脆弱性に関する以前の議論から、アプリケーションレベルで利用可能な5つの防御メカニズムを導き出すことができます。
1. Identity -- Know who the request came from.
1. アイデンティティ - リクエストが誰から来たのかを知る。
2. Alerting -- Let the called user know what's happening. Some applications might use inbound media as an alert.
2. アラート - 呼び出されたユーザーに何が起こっているのかを知らせます。一部のアプリケーションは、インバウンドメディアをアラートとして使用する場合があります。
3. Acceptance -- Require called user to make run-time decision. Asking the user to make a run-time decision without alerting the user to the need to make a decision is generally infeasible. This will have implications for possible alerting options that are outside the scope of this document.
3. 受け入れ - ランタイムの決定を下すためにユーザーに呼び出されます。ユーザーに決定を下す必要性を警告することなく、ランタイムの決定をするようにユーザーに求めることは、一般的には実行不可能です。これは、このドキュメントの範囲外のアラートオプションの可能性に影響を与えます。
4. Limit the Input/Output (I/O) -- Turn off loudspeakers or microphone. This could be used to convert a bidirectional media session (very risky, possible "bug my phone") into a unidirectional, inbound-only (less risky, possible "spam" or "rundown", etc.) session while waiting for user acceptance.
4. 入力/出力（I/O）を制限 - スピーカーまたはマイクをオフにします。これは、ユーザーの受け入れを待っている間、双方向メディアセッション（非常に危険な、「バグマイフォン」）を単方向、インバウンドのみ（リスクが低く、「スパム」または「ランダウン」など）セッションを変換するために使用できます。。
5. Policy -- Rules about other factors, such as black- and whitelisting based on identity, disallowing acceptance without alerting, etc.
5. ポリシー - アイデンティティに基づいた黒人やホワイトリストなど、他の要因に関する規則、警告なしの受け入れなど。
Since SIP and related work already provide several mechanisms (including SIP Digest Authentication [RFC3261], the SIP Identity mechanism [RFC4474], and the SIP mechanism for asserted identity within private networks [RFC3325], in networks for which it is suitable) for establishing the identity of the originator of a request, we presume that an appropriately selected mechanism is available for UAs implementing the extensions described in this document. In short, UAs implementing these extensions MUST be equipped with and MUST exercise a request-identity mechanism. The analysis below proceeds from an assumption that the identity of the sender of each request is either known or is known to be unknown, and can therefore be considered in related policy considerations. Failure to meet this identity requirement either opens the door to a wide range of attacks or requires operational policy so tight as to make these extensions useless.
SIPおよび関連する作業はすでにいくつかのメカニズム（SIPダイジェスト認証[RFC3261]、SIP IDメカニズム[RFC4474]、およびプライベートネットワーク内での主張されたアイデンティティ[RFC3325]のSIPメカニズム）を提供しています。リクエストの創始者の身元は、このドキュメントで説明されている拡張機能を実装するUASに適切に選択されたメカニズムが利用可能であると推測します。要するに、これらの拡張機能を実装するUASには装備されている必要があり、リクエストアイデンティティメカニズムを行使する必要があります。以下の分析は、各リクエストの送信者の身元が知られているか、未知であることが知られているため、関連するポリシーの考慮事項で考慮される可能性があるという仮定から進みます。このアイデンティティの要件を満たさないと、広範囲の攻撃への扉が開かれるか、これらの拡張機能を役に立たなくするために運用ポリシーが必要です。
We previously established a class distinction between inbound and outbound media flows, and can model bidirectional flows as "worst case" sums of the risks of the other two classes. Given this distinction, it seems reasonable to provide separate directionality policy classes for:
以前に、インバウンドメディアフローとアウトバウンドメディアフローのクラスの区別を確立し、他の2つのクラスのリスクの「最悪の場合」の合計として双方向フローをモデル化できます。この区別を考えると、次のように別々の方向性ポリシークラスを提供することは合理的と思われます。
1. Inbound media flows.
1. インバウンドメディアフロー。
2. Outbound media flows.
2. アウトバウンドメディアフロー。
For each directionality policy class, we can divide the set of request identities into three classes:
各方向性ポリシークラスについて、リクエストアイデンティティのセットを3つのクラスに分割できます。
1. Identities explicitly authorized for the class.
1. クラスに対して明示的に承認されたアイデンティティ。
2. Identities explicitly denied for the class.
2. クラスのアイデンティティは明示的に拒否されました。
3. Identities for which we have no explicit policy and need the user to make a decision.
3. 明示的なポリシーがなく、ユーザーが決定を下す必要があるアイデンティティ。
Note that not all combinations of policies possible in this decomposition are generally useful. Specifically, a policy of "inbound media denied, outbound media allowed" equates to a "bug my phone" attack, and is disallowed by the minimal policy of Section 7.4, which as written excludes all cases of "Outbound media explicitly authorized".
この分解で可能なポリシーのすべての組み合わせが一般的に有用ではないことに注意してください。具体的には、「拒否されたインバウンドメディアのポリシー」は、「バグマイフォン」攻撃に等しく、「バグマイ携帯」攻撃に等しく、セクション7.4の最小ポリシーによって禁止されています。
User agents implementing this specification SHOULD NOT establish a session providing inbound media without explicit user acceptance where the requesting user is unknown, or is known and has not been granted authorization for such a session. This requirement is intended to prevent "SPAM broadcast" attacks where unexpected and unwanted media is played out at a UAS .
この仕様を実装するユーザーエージェントは、リクエストユーザーが不明であるか、知られており、そのようなセッションの許可が認められていない明示的なユーザーの受け入れなしに、インバウンドメディアを提供するセッションを確立するべきではありません。この要件は、UASで予期しない不要なメディアが行われる「スパム放送」攻撃を防ぐことを目的としています。
User agents implementing this specification MUST NOT establish a session providing outbound or bidirectional media sourced from the user agent without explicit user acceptance. Loopback media used for connectivity testing is not constrained by this requirement. This requirement is intended to assure that this extension can not be used to turn a UAS into a remote-controlled microphone (or "bug") without the knowledge of its user. Since SIP allows for a session to be initially established with inbound-only media and then transitioned (via re-INVITE or UPDATE) to an outbound or bidirectional session, enforcing this policy requires dialog-stateful inspection in the SIP UAS. In other words, if a session was initiated with automatic answering, the UAS MUST NOT transition to a mode that sends outbound media without explicit acceptance by the user of the UAS.
この仕様を実装するユーザーエージェントは、明示的なユーザーの受け入れなしにユーザーエージェントからソースされたアウトバウンドまたは双方向のメディアを提供するセッションを確立してはなりません。接続テストに使用されるループバックメディアは、この要件に制約されていません。この要件は、この拡張機能を使用して、ユーザーの知識なしにUASをリモート制御マイク（または「バグ」）に変えることができないことを保証することを目的としています。SIPは、インバウンドのみのメディアで最初にセッションを確立できるようにし、その後（再入札または更新を介して）アウトバウンドまたは双方向セッションに移行することができるため、このポリシーを実施するには、SIP UASでのダイアログ状態の検査が必要です。言い換えれば、自動応答でセッションが開始された場合、UASは、UASのユーザーによる明示的な受け入れなしに、アウトバウンドメディアを送信するモードに移行してはなりません。
This document defines new SIP header fields named "Answer-Mode" and "Priv-Answer-Mode".
このドキュメントでは、「Answer-Mode」と「Priv-Answer-Mode」という名前の新しいSIPヘッダーフィールドを定義しています。
The following rows have been added to the "Header Fields" section of the SIP parameter registry:
次の行は、SIPパラメーターレジストリの「ヘッダーフィールド」セクションに追加されました。
+------------------+--------------+-----------+
| Header Name | Compact Form | Reference |
+------------------+--------------+-----------+
| Answer-Mode | | [RFC5373] |
| Priv-Answer-Mode | | [RFC5373] |
+------------------+--------------+-----------+
This document defines parameters for the header fields defined in the preceding section. The header fields "Answer-Mode" and "Priv-Answer-Mode" can take the values "Manual" or "Auto".
このドキュメントでは、前のセクションで定義されているヘッダーフィールドのパラメーターを定義します。ヘッダーフィールド「Answer-Mode」および「Priv-Answer-Mode」は、値「マニュアル」または「Auto」を取得できます。
The following rows have been added to the "Header Field Parameters and Parameter Values" section of the SIP parameter registry:
次の行は、SIPパラメーターレジストリの「ヘッダーフィールドパラメーターとパラメーター値」セクションに追加されました。
+------------------+----------------+-------------------+-----------+
| Header Field | Parameter Name | Predefined Values | Reference |
+------------------+----------------+-------------------+-----------+
| Answer-Mode | require | No | [RFC5373] |
| Priv-Answer-Mode | require | No | [RFC5373] |
+------------------+----------------+-------------------+-----------+
This document defines the SIP option tag "answermode".
このドキュメントでは、SIPオプションタグ「exwerermode」を定義します。
The following row has been added to the "Option Tags" section of the SIP Parameter Registry:
次の行は、SIPパラメーターレジストリの「オプションタグ」セクションに追加されました。
+------------+------------------------------------------+-----------+
| Name | Description | Reference |
+------------+------------------------------------------+-----------+
| answermode | This option tag is for support of the | [RFC5373] |
| | Answer-Mode and Priv-Answer-Mode | |
| | extensions used to negotiate automatic | |
| | or manual answering of a request. | |
+------------+------------------------------------------+-----------+
This document draws requirements and a large part of its methodology from the work of the Open Mobile Alliance, and specifically from a document by Andrew Allen, Jan Holm, and Tom Hallin.
このドキュメントは、オープンモバイルアライアンスの作業から、特にアンドリューアレン、ヤンホルム、トムハリンによる文書から要件とその方法論の大部分を導き出します。
The editor would also like to recognize the contributions of David Oran and others who argued on the SIPPING mailing list and at the OMA ad-hoc meeting at IETF 62 that the underlying ideas of the above document were broadly applicable to the SIP community, and that the concepts of alerting and answering should be clearly delineated. Further, the security review provided by Sandy Murphy and the gen-art review by Suresh Krishnan were very helpful in improving the quality of this document.
編集者はまた、David Oranと、上記の文書の基礎となるアイデアがSIPコミュニティに広く適用されていること、およびそれがSIPコミュニティに広く適用されていることをIETF 62でのOMAアドホック会議で議論したDavid Oranや他の人々の貢献を認識したいと考えています。警告と回答の概念は明らかに描写されるべきです。さらに、Sandy Murphyが提供するセキュリティレビューとSuresh KrishnanによるGen-Artレビューは、この文書の品質を改善するのに非常に役立ちました。
[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 Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）の発信者の好み」、RFC 3841、2004年8月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[LOOPBACK] Hedayat, K., "An Extension to the Session Description Protocol (SDP) for Media Loopback", Work in Progress, August 2008.
[Loopback] Hedayat、K。、「メディアループバックのセッション説明プロトコル（SDP）の拡張」、2008年8月の作業。
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[RFC3325] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
Authors' Addresses
著者のアドレス
Dean Willis (editor) Softarmor Systems 3100 Independence Pkwy #311-164 Plano, Texas 75075 USA
Dean Willis（編集者）SoftArmor Systems 3100 Independence PKWY＃311-164 Plano、Texas 75075 USA
EMail: dean.willis@softarmor.com
Andrew Allen Research in Motion (RIM) 300 Knightsbridge Parkway, Suite 360 Lincolnshire, Illinois 60069 USA
アンドリュー・アレン研究中の研究（RIM）300 Knightsbridge Parkway、Suite 360 Lincolnshire、Illinois 60069 USA
EMail: aallen@rim.com