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.
著作権（C）2008 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/ライセンス情報）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Abstract
抽象
This document 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.
この文書では、その要求の応答に関連する処理のユーザインタフェースのための要求者の好みを伝えるために、INVITE要求に使用することができる2つのヘッダフィールドと関連したオプションタグとSIPを拡張します。最初のヘッダは、「モード回答」、代わりに、ユーザ入力に待つことなく要求を受け付け、ターゲットノードのユーザインターフェースは要求を受け入れる前に、ユーザ入力を待つか否かの嗜好を表現または。第二のヘッダ、「プライベート・応答モード」は、それが管理者レベルのアクセスを要求し、その結果として、追加の認証および認可要件を持っていることを除いて、最初のと同様です。これらの行動は、このようなループバックのようなプッシュトークにとの診断などのアプリケーションへの適用可能性を有します。要求が処理されたかを示すために応じて、各ヘッダフィールドの使用も定義されています。
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 INVITEを送信する）、要求を受信し、ユーザに通知する、要求とセッション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.
最初の使用シナリオは、診断ループバック・コールのための要件です。シナリオのこの種では、テストサービスは、試験されているノードにINVITEを送信します。テストしたノードが受け入れ、ダイアログが確立されています。むしろ双方向メディアフローを確立するよりも、試験されたノードは、ループバック又は「エコー」メディアは、バックテスティングサービスに向けてテストサービスから受け取りました。テストサービスは、品質とタイミング特性のためにメディアフローを分析することができます。セッション記述プロトコル（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は、従来の双方向無線のようなユーザー体験を提供する、一方向のメディアフローの非同期配信をサポートするダイアログを確立するために使用されます。使用INVITESが自動的に呼び出さ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拡張ヘッダーフィールドを定義：「モード回答」と「プライベート・応答モード」。これらの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.
応答モードおよびpriv-応答モードとの間の区別は、ユーザエージェントクライアント（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.
プライベート・応答モードは、特権の表明ではありません。その代わりに、特権的治療のための要求です。これは、ユーザーが通常のコマンドを実行したり、コマンドのための管理者権限を要求するために、「sudoを」使用することがありますUNIXモデルに似ています。 「Priv-」を含めると、「sudoを」でUNIXコマンドを接頭辞と同じです。換言すれば、別々のポリシーテーブルは（等の「/ 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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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)
回答モード= "回答-モード" HCOLON答えモード値*（SEMI答えモード-PARAM）
Priv-Answer-Mode = "Priv-Answer-Mode" HCOLON answer-mode-value *(SEMI answer-mode-param)
プライベート・応答モード= "プライベート・応答モード" HCOLON答えモード値*（SEMI答えモード-PARAM）
answer-mode-value = "Manual" / "Auto" / token
答えモード値=「手動」/「オート」/トークン
answer-mode-param= "require" / generic-param
答え-モードのparam = "必要" /ジェネリック-PARAM
The SIP option tag indicating support for this extension is "answermode".
この拡張機能のサポートを示すSIPオプションタグが「answermode」です。
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.
この構文は、将来的に定義することができ、拡張フック（解答モードの値については、「トークン」とオプションのパラメータについて、「一般的な-PARAM」）を含みます。この仕様は、上記で明示的に指定した値に対してのみ動作を定義します。前方互換性を提供するために、実装は未知の値を無視しなければなりません。
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.
このドキュメントは、要求を最初のINVITE（ダイアログ形成）SIPおよびそれらの要求への200（OK）応答で応答モードおよびpriv-応答モードのヘッダフィールドの使用を定義します。この文書では、具体的には、要求または応答のいずれかの他の並べ替えに使用方法を定義含むがACKに限定されるものではなく、CANCEL、または任意の半ばダイアログの使用しません。
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.
この制限は、新しい通信セッションを要求したときに、このような要求に応答するときに、ユーザーが通信装置と対話する方法に影響を与えることで、この拡張機能の使用目的に由来します。相互作用のこの種は、ダイアログとその初期の使用を形成する際、いないような再INVITEとしてその後の動作中に発生します。しかし、セッション開始のセキュリティの側面は、再INVITESまたは同様の要求によって導入されたメディア記述の変更に適用されなければなりません。この問題のさらなる議論については、セクション7.1を参照してください。
4. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in Requests
要求で応答モードとプライベート・応答モードヘッダフィールドの4使い方
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:
応答モードまたはプライベート・アンサーモードヘッダフィールドは、応答UASによって特定の処理を起動するために、INVITE要求にUACによって使用されます。この処理は、そのINVITEリクエストに起因するいかなるダイアログの「自動応答」機能に関連しています。無応答モードまたはプライベート・アンサーモードヘッダフィールドは要求に含まれていない場合、動作に応答することは、本明細書の非存在下であろうように、UASの裁量です。次のように所望の処理は、応答モードまたはプライベート・応答モードのヘッダフィールドの値によって示されます。
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を希望することを指示するようにUASのユーザーインターフェース（UI）と相互作用するまで要求を受け付け延期するように求められます。
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.
オート：UASは、ユーザーが要求を受け入れるようにUASを望んでいることを示すような方法でUASのUIと対話する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.
応答モードまたはプライベート・アンサーモードヘッダフィールドの各値は、オプションのパラメータを含むことができ、「必要とします」。存在する場合、このパラメータは、UACが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アイデンティティ機構[RFC4474]などの認証メカニズムを使用して要求に提示認証IDに基づいて許可決定を行う、または（それが適当であるために制限ネットワーク内）信頼できるネットワーク[RFC3325]内でアサートアイデンティティのためのSIPメカニズム。承認決定をするとき、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.
応答モードおよびpriv-応答モードヘッダフィールドの機能は類似しています。それらの両方は、ヘッダフィールドの値（自動または手動）によって指定されるようにUASが要求を処理することを尋ねます。違いは、リクエストがUASの方針と対話する方法です。典型的なUASは、各ヘッダフィールドを処理するための異なるポリシーを持っています。例えば、彼女は重要な活動に従事していると誤って中断されることを望んでいないことを示す、UASのユーザーは「会議モード」にUASように配置していることを前提としています。 UASはしばらくの間、「会議モード」で応答モード要求のための自動応答を許可しない場合があります。しかし、UASは、プライベート・応答モードで作られたリクエストの自動応答を許可するかもしれないこと。おそらく、認可ポリシーの違いがあります。例えば、UASは、「友人」リストに発信者が応答モードではなく、プライベート・応答モードを使用して要求を行うことが許可されているように構成されることがあります。その同じUASは唯一のプライベート・応答モードを使用するように「管理者」リストに発信者を許可するように設定される可能性があります。これは、常に発信者の身元に行動を基づか異なっています。たとえば、呼び出し側「ボブ」は「友人」リストと「管理者」リストの両方にあると仮定します。ボブは彼の要求は、定期的なポリシーに従って処理されることを希望する場合は、彼は答えモードを使用しています。ボブは彼の要求はより限定的な「特権」ポリシーの下で処理されることを希望する場合は、彼はプライベート・応答モードを使用しています。
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は、応答モードでの要求によりもプライベート-応答モードで要求に厳しい許可ポリシーを適用する必要があります。デフォルトポリシーは、要求が認証され、具体的にはプライベート・アンサー・モード要求を行うことを許可されていない限り、プライベート・応答モードヘッダフィールドを含むリクエストを拒否することべきです。セクション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.
プライベート・応答モードが想定されるユースケースは、許可発信者からの緊急の要求を処理することに関する。例えば、ラリーは艦隊ディスパッチャでの作業リムジンドライバーであると仮定します。呼び出し：ラリーは彼のコミュニケータは、プッシュ・ツー・トーク（自動応答モード）を含むすべての非特権呼び出し、ための手動応答モード用に設定されているので、彼の車のための静かな環境を提供するのが好き。彼はコールを取得するたびに、ラリーのコミュニケータは、コールに彼に警告するためにそっとチャイム。事情がそれを許可した場合は、ラリーはコールを受け入れるためにコミュニケータは、コミュニケータは、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.
次に、オペレータは、彼の「緊急」ボタンを押すと、再びラリーを呼び出します。ヘッダフィールド：この時間は、INVITE要求は、「自動プライベート・応答モード」を運びます。ラリーのコミュニケータは、発信者の身元（SIP 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.
プライベート・応答モードを要求する効果は、単に依頼者のIDと対応する認証レベルに基づいて、応答モード要求に高い権限を付与する効果は異なります。通常の条件下ラリーへの要求、および異なる取扱い（プライベート・応答モード：オート）を受信大きい緊急性を持つ要求について：この区別は、フリートオペレーターが丁寧（自動応答モードを）を行うことができますものです。
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.
通常の操作では、いずれかの応答モードまたはプライベート・応答モードの一つのみがINVITE要求に使用されるであろう。両方が存在する場合にのみプライベート・応答モードが含まれていたかのように、UASは最初のプライベート・応答モードと、許可された場合、処理要求の要求元の認可をテストします。依頼者は、プライベート・応答モードのために認可されていない場合のみ回答モードが含まれていたかのように、その後、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.
応答モードおよびpriv-応答モードの両方が「必要」の修飾語可能（例：「プライベート・応答モード：オート;必要」）。この修飾子は、手動または自動で答えるようにするかどうかを選択する際に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.
UAは、応答モードをサポートし、プライベート・応答モードのヘッダフィールドは、送信するすべての要求のSupportedヘッダーフィールドに「answermode」のオプションタグを含むことによって、そのサポートを示すべきです。
To indicate that it supports the answer-mode negotiation feature, a UA MAY include an extensions parameter with a value that includes "answermode". Example:
それはanswermodeネゴシエーション機能をサポートしていることを示すために、UAは「answermode」を含む値を持つ拡張パラメータを含むかもしれません。例：
;extensions="answermode,100rel,gruu"
;拡張子= "answermode、100rel、GRUU"
in the Contact header field of its REGISTER requests. This usage of feature tags is described in [RFC3840].
そのREGISTER要求のContactヘッダーフィールドに入力します。フィーチャータグのこの用法は[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がレジストラで呼び出し先機能のサポートに依存している場合、それはそのREGISTERリクエストに値「県」とRequireヘッダーフィールドを含んでいてもよいです。レジストラは、呼び出し先の機能と、発信者の好みをサポートしていない場合、これはレジストラが要求を拒否するようになります。例：
Require: 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応答の応答モードに影響を与えることを望む場合、INVITEに応答モードまたはプライベート・アンサーモードヘッダフィールドを含んでいてもよい、この仕様をサポートします。
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.
注意：これは初期またはダイアログ形成INVITEリクエストに有意義です。他の要求に現れる応答モードおよびpriv-応答モードのヘッダフィールドは無視されます。要求は、通常、そのユーザ（例えば、「リンギング」と「答え」）により、利用者と受け入れへの通知をもたらさない場合は一般的に、これらの拡張機能は適用されません。
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は、応答モードまたは「手動」の値を有するプライベート・応答モードのヘッダフィールドを含みます。例：
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は、「手動」の値とのパラメータを有する応答モードまたはプライベート・アンサーモードヘッダフィールドを含む場合、それは、INVITE要求を拒絶することを頼むことを要求します「必要」。例：
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は、「自動」の値を有する応答モードまたはプライベート・アンサーモードヘッダフィールドを含みます。例：
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が「自動」の値とのパラメータを有する応答モードまたはプライベート・アンサーモードヘッダフィールドを含む場合、それは、INVITE要求を拒絶することを頼むことを要求します「必要」。例：
Answer-Mode: 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は、ヘッダフィールド値を有する必要「answermode」を含みます。これは実際にそれだけでUASは、この拡張を理解したり、要求を拒否いずれかのことを要求し、自動的に答えるためにUASを強制するものではありません。私たちは、特定の動作を強制的にSIPネゴシエーション技術を持っていません。むしろ、所望の行動は、SIPの拡張自体に示されています。例：
Require: answermode
必要：answermodeを
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は「answermode」の値を持つ拡張パラメータとのAccept-Contactヘッダーフィールドを含んでいます。 Accept-連絡先のこの用法は[RFC3841]に記述されています。上記のようにヘッダフィールド：これは、通常、「answermode要求」に関連して使用されるであろう。例：
Require: answermode Accept-Contact: *;extensions="answermode";methods="INVITE"
必要：answermodeは、連絡先を受け入れる：*;拡張子= "answermode";メソッドは、= "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は「answermode」の値とのオプションフィールドを持つ拡張パラメータとのAccept-Contactヘッダーフィールドが含まれていることを要求するには「必要」。 Accept-連絡先のこの用法は[RFC3841]に記述されています。上記のようにヘッダフィールド：これは、通常、「answermode要求」に関連して使用されるであろう。例：
Require: answermode Accept-Contact: *;extensions="answermode"; methods="INVITE";require
必要：answermodeのAccept-お問い合わせ：*;拡張子= "answermodeを"。メソッド= "INVITE";必要
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は「answermode」の値と「必要」のオプションと「明示」を有するのAccept-Contactヘッダーフィールドの拡張パラメータが含まれていることを要求するには。 Accept-連絡先のこの用法は[RFC3841]に記述されています。上記のようにヘッダフィールド：これは、通常、「answermode要求」に関連して使用されるであろう。例：
Require: answermode Accept-Contact: *;extensions="answermode"; methods="INVITE";require;explicit
必要：answermodeのAccept-お問い合わせ：*;拡張子= "answermodeを"。メソッド= "INVITE";必要とします。明示的な
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）を解決するための責任プロキシ）またはローカルポリシーと一致して、既存のヘッダフィールドの値を変更します。これは、その結果プロキシは、挿入、削除、またはアンサーモードまたはプライベート・応答モードを変更してはいけません（例えば、ヒトによって診断ループバックが応答されることを意図されたコールを有するような）ユーザの期待と矛盾する動作を引き起こす可能性がヘッダフィールドは、明示的プロキシオペレータとプロキシが配信されることをUAのユーザとの間の外部の契約によりそうすることを許可されない限り。これらのサービス提供のプロキシはまた、彼らがそうするならばUASについては、以下を指定したとして、拒否コードを使用すべきである、ローカルポリシーに従って、要求を拒否してもよい（MAY）。
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.
フォークでよく知られている問題の一つは、複数の受け入れの問題です。 INVITE要求は、200（OK）応答でいくつかのUASと複数の返信に二股されている場合、従来のアプローチは、最初の回答者との対話を継続し、他のすべての回答と（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.
この問題は、自動応答ネゴシエーション機能を持たない存在するが、自動応答行動に従事するUAの普及は、複数の受け入れの問題を悪化させることは明らかです。そのため、システム設計者は考慮にこの点を取る必要があります。一般的には、自動応答は、並列フォークを含む環境では推奨されません。
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）応答を生じる、「受け入れ」として役立ちます。従って、受け入れのためのレース条件は、実際のUAのフルセットは、その要求がフォークされたのではなく、ユーザの制御下で、応答のUAのサブセットに制限されます。
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.
別の代替ではなく、フォークの動的な会議を使用することです。このアプローチでは、代わりに要求をフォークで、会議が開始されるだろうと、すべての登録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は要求を受け付ける延期すべきです。無人のUASまたはその他の地域の特性や政策のために、必要に応じてこの動作を変更することができます。例えば、自動受付または公開には、常に自動的に答える電話網（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（禁止）」応答でそうすべきである、と "の理由句を含んでもよい（MAY）マニュアル答えは」禁じられました。
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."
発呼者が認証され、自動応答のために認可されている場合、「自動」の応答モード値を有する要求に対して、UASは、更に別のユーザ入力なしで要求を受け入れる必要があります。それは「手動」または有する無回答モードのヘッダフィールドの値で応答モードを有する要求を扱うことになるようにUAS MAYは、ローカルポリシーまたはユーザの好みに応じて、この要求を扱います。発信者が自動応答のための認証および承認されていない場合、UASは、「マニュアル」に従って、要求を処理するか、または要求を拒否するかもしれいずれか。 UASが要求を拒否した場合、それは「403（禁止）」応答でそうする必要があり、「禁じられた自動応答」の理由フレーズを含むかもしれません。いくつかの場合にはS / MIMEのために使用される証明書のユーザの検証を必要とする[RFC3261]セクション23.2、との相互作用があるかもしれません。これは手動でリクエストに答えると同じようにユーザーに同じ割り込み負担となっているので、自動応答を必要とする要求のユーザー確認のために、この要件を経験UASは、「403（禁止）」応答でリクエストを拒否すべきであるとの理由を含んでもよい（MAY）句「証明書の検証が自動応答に対応していないユーザー入力を必要とします。」
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".
発呼者が認証され、自動応答のために許可されている場合は、「自動」と「必要」の回答-modeパラメータの応答モード値を持つ要求の場合、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).
同様の動作は、認可のためのポリシーが異なる（一般的により厳しい）であってもよいことを除いて、プライベート・応答モードに適用されます。
5. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in Responses
応答で応答モードおよびpriv-応答モードヘッダフィールドの使用5.
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:
応答モードまたはプライベート・アンサーモードヘッダフィールドは、自動応答機能に関して関連する要求を扱う方法を示すために応答に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のユーザーインターフェース（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.
オート：UASは、ユーザーが要求を受け入れるようにUASを望んでいることを示すような方法でUASのUIと対話するUASのユーザーを待たずに、自動的に答えました。
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.
応答モードおよびpriv-応答モードヘッダフィールドは、応答に使用される場合、INVITEリクエストに対する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.
その要求は、手動または自動で応答されたか否かのUACに通知したい場合、この仕様をサポートするUASは、INVITEリクエストに対する200（OK）応答に応答モードまたはプライベート・アンサーモードヘッダフィールドを挿入します。 UASは、UACがリクエストに応答モードのヘッダフィールドが含まれている場合、それはおそらく応答で応答モードのヘッダフィールドを見たいと仮定することは合理的です。応答でこのヘッダーフィールドを含むを含むかどうかの完全な理論的根拠は、本明細書の範囲外であり、UASのユーザのプライバシー問題に敏感です。たとえば、コールが応答UASで「実際の人間」の存在を明らかにするかもしれません手動で答えた発呼者に知らせます。一般的な場合にはその後の会話も、この同じ情報を明らかにするだろうが、この情報を保護する必要があるかもしれない例があるかもしれません。したがって、この仕様をサポートするのUASは、この決意を行うために適切に設定ポリシーメカニズムを含むべきであり、デフォルトの設定が応答からこのヘッダフィールドを除外することべきです。
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は、ユーザインタフェースを適応させる、および/または要求の取り扱いについてユーザに通知するために、応答モードまたはプライベート・応答モードのヘッダフィールドの値を使用することができます。彼女は着信側が無人のスピーカーフォンのうち噪音コールを持つ対「人に」答えを知っている場合たとえば、プッシュ・トゥ・トークシステムのユーザは、異なる話すかもしれません。
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.
次の例では、ボブがモードに答えるのネゴシエーションをサポートしている連絡先を登録する示しています。アリスはその後、自動応答を尋ねると、明示的に要求は、この拡張機能のサポートを示していない連絡先にルーティングされないことを求めて、INVITEリクエストでボブを呼び出します。さらに、アリスはボブのUAは、モードに答えるのネゴシエーションをサポートしていない場合、要求が拒否されている必要があります。 Bobは、呼が自動的に応答されたことを示す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.
例に示すContent-Lengthヘッダフィールドはプレースホルダー「...」の代わりに、有効なContent-Lengthが含まれています。また、INVITE要求200（OK）応答に予想されるSDP本体は示されていません。
In the following example, Bob's UA is registering and indicating that it supports the answermode extension.
次の例では、ボブのUAが登録し、それがanswermode拡張をサポートすることを示すされます。
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"
example.com SIP / 2.0：ボブSIPレジスタ<SIP：bob@example.com>に：ボブ<SIP：bob@example.com> CallID：hh89as0d-asd88jkk@cell-phone.example.comのCSeq：1レジスタ連絡先：SIP：cell-phone.example.com。 ;オーディオ; + sip.extensions = "answermode";メソッド= "BYE、OPTIONSは、ACKをキャンセルINVITE";スキーム= "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を求めています。 「：自動応答モード」で、「必要」修飾子ボブの政策は、アリスが含まれていませんので、手動で答えを好むのであれば、ボブは手動で答えるのが、アリスは喜んでいます。
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: ...
SIPのINVITE：bob@example.com SIP / 2.0経由：SIP / 2.0 / TCP client-alice.example.com:5060。ブランチ= z9hG4bK74b43マックス・フォワード：70から：アリス<SIP：alice@atlanta.example.com>;タグ= 9fxced76slへ：ボブ<SIP：bob@example.com>コールID：3848276298220188511@client-alice.exampleを。 COMのCSeqは：連絡先を1 INVITE：<SIP：alice@client.atlanta.example.com;運輸= TCP>必須：answermodeのAccept-接触を：*;必要;明示;拡張子= "answermode" 回答モード：自動のContent-Type ：アプリケーション/ SDPコンテンツの長さ：...
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: ...
SIP / 2.0 200 OK経由：SIP / 2.0 / TCP client-alice.example.com:5060。ブランチ= z9hG4bK74b43から：アリス<SIP：alice@example.com>;、タグ= 9fxced76sl：ボブ<SIP：bob@example.com>;タグ= 8321234356のCall-ID：3848276298220188511@client-alice.example.comのCSeq： 1連絡先をINVITE：<一口：bob@client.biloxi.example.comを、輸送= TCP>応答モード：自動のContent-Type：アプリケーション/ SDPコンテンツの長さ：...
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によってINVITEリクエストの受け付けに係る潜在的に危険なユーザインタフェースの動作を要求するための機能を追加します。 （：自動回答モード）、具体的に、UACがUASは、UASのユーザによるUASへの入力なしで要求を受け入れることを要求することができます。
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プロキシ横切る推移セキュリティに完全に依存しています。任意の不正動作するプロキシは、挿入、削除、および/または応答モードおよびpriv-応答モードのヘッダフィールドの内容を変更し、一般的にUACまたはUASのいずれかに気付かれることなくこれを行うことができます。したがって、パス内のすべてのプロキシが信頼されていないだけという重要な、しかし、その信頼に値するです。プロキシは、一般的に、意図的に応答モードおよびpriv-応答モードヘッダフィールドを挿入、削除、または変更されることはありませんが、この仕様はあり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の仕事の既存の体は（ように要求の認証、man-in-the-middle攻撃の防止、メディアフローのプライバシーと整合性の保護のための強力な機能を提供し、プロキシ間の信頼）。このドキュメントの拡張によって追加の行動は完全に既存の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つの防御メカニズムを導き出すことができます。
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アイデンティティ機構[RFC4474]を含む、およびプライベートネットワーク内のアサートされたアイデンティティのためのSIPメカニズム[RFC3325]）いくつかのメカニズムを提供するため要求の発信元のアイデンティティは、我々は適切に選択された機構は、このドキュメントで説明する機能拡張を実装するUAのために利用可能であることを推測します。要するに、これらの拡張機能を実装するUAは装備されなければならないと要求アイデンティティメカニズムを行使しなければなりません。各リクエストの送信者の身元が知られているいずれかまたは未知であることが知られており、したがって、関連するポリシーの考慮に考慮することができるという仮定から進行以下分析。攻撃の広い範囲への扉を開くか、これらの拡張機能は無用になるようにタイトな運用ポリシーを必要とどちらかこのアイデンティティの要件を満たすために失敗しました。
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つのクラスのリスクの「最悪の場合」の合計として双方向の流れをモデル化することができます。この区別を考えると、ために別々の方向性ポリシーのクラスを提供するために、合理的なようです。
For each directionality policy class, we can divide the set of request identities into three classes:
各方向性ポリシークラスのために、我々は3つのクラスに要求アイデンティティのセットを分割することができます。
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で再生される「SPAM放送」攻撃を防ぐことを目的としています。
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は、アウトバウンドまたは双方向セッションに（RE-INVITEまたはUPDATEを介して）最初に受信専用メディアとの間で確立し、次に移行するセッションを可能にするので、このポリシーを適用すると、SIP UASにおけるダイアログステートフルインスペクションを必要とします。セッションは、自動応答で開始した場合は、他の言葉では、UASはUASのユーザーが明示的な承諾なしに発信メディアを送信モードに移行してはなりません。
This document defines new SIP header fields named "Answer-Mode" and "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".
この文書は、前のセクションで定義されたヘッダフィールドのパラメータを定義します。ヘッダフィールドおよび「プライベート・応答モード」「モード回答」「手動」又は「自動」の値をとることができます。
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オプションタグ「answermode」を定義します。
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.
この文書では、アンドリュー・アレン、ヤン・ホルム、そしてトム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.
エディタはまた、上記の文書の基礎となる考え方は、SIPコミュニティに広く適用可能であったことがSIPPINGメーリングリスト上およびOMA IETF 62でのアドホック会議で主張デビッド・オランなどの貢献を認識するために好きで、そのう警告と答えるの概念が明確に線引きする必要があります。さらに、スレシュクリシュナンによってサンディマーフィーと世代技術の審査が提供するセキュリティレビューは、この文書の品質を向上させる上で非常に有用でした。
[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月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[RFC3841]ローゼンバーグ、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]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、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]ヘダーヤト、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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（SIP）のプライベート拡張"、RFC 3325、2002年11月。
Authors' Addresses
著者のアドレス
Dean Willis (editor) Softarmor Systems 3100 Independence Pkwy #311-164 Plano, Texas 75075 USA
ディーン・ウィリス（エディタ）Softarmorシステム3100独立パークウェイ＃311から164プラノ、テキサス75075 USA
EMail: dean.willis@softarmor.com
メールアドレス：dean.willis@softarmor.com
Andrew Allen Research in Motion (RIM) 300 Knightsbridge Parkway, Suite 360 Lincolnshire, Illinois 60069 USA
アンドリュー・アレン研究モーション（RIM）300ナイツブリッジパークウェイでは、スイート360リンカンシャー、イリノイ州60069米国
EMail: aallen@rim.com
メールアドレス：aallen@rim.com