RFC5373 日本語訳
5373 Requesting Answering Modes for the Session Initiation Protocol(SIP). D. Willis, Ed., A. Allen. November 2008. (Format: TXT=59839 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Willis, Ed.
Request for Comments: 5373 Softarmor Systems
Category: Standards Track A. Allen
Research in Motion (RIM)
November 2008
ワーキンググループのD.ウィリス、エドをネットワークでつないでください。コメントのために以下を要求してください。 5373年のSoftarmorシステムカテゴリ: 規格は2008年11月に動き(縁)におけるA.アレンの研究を追跡します。
Requesting Answering Modes for the Session Initiation Protocol (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)2008IETF Trustと人々はドキュメントとして作者を特定しました。 All rights reserved。
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.
事実上、このドキュメントはこのドキュメントの公表の日付にIETF Documents( http://trustee.ietf.org/ ライセンスインフォメーション)へのBCP78とIETF TrustのLegal Provisions Relatingを受けることがあります。 このドキュメントに関して権利と制限について説明するとき、慎重にこれらのドキュメントを再検討してください。
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を広げています。 目標ノードのユーザーインタフェースが要請を受け入れる前に、ユーザ入力を待つか、または代わりにユーザ入力で待っていなくて要請を受け入れるかに関して「アンサーモード」という最初のヘッダーは優先を言い表します。 「Priv-アンサーモード」という2番目のヘッダーは1日と同様です、管理レベルアクセスを要求して、結果の追加認証と認可要件を持っているのを除いて。 これらの振舞いはプッシュから話などの応用と、そして、ループバックのような病気の特徴に適用性を持っています。 また、要求がどう扱われたかを示す応答におけるそれぞれのヘッダーフィールドの用法は定義されます。
Willis & Allen Standards Track [Page 1] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[1ページ]RFC5373一口
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
1. バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 要件言語. . . . . . . . . . . . . . . . . . 5 2 ヘッダーフィールドとオプションの構文は.5 3にタグ付けをします。 アンサーモードとPriv-アンサーモードヘッダーフィールド. 6 4の用法。 要求. . . . . . . . . . . . . . . . . . . . . . 6 4.1におけるアンサーモードとPriv-アンサーモードヘッダーフィールドの用法。 アンサーモードとPriv-アンサーモード.74.2の違い。 「必要」修飾語. . . . . . . . . . . . . . . . . . 9 4.3。 ユーザエージェントのクライアント(UAC). . . . . . . . . . 9 4.3.1における手順。 すべての要求. . . . . . . . . . . . . . . . . . . . . 9 4.3.2。 取引. . . . . . . . . . . . . . . . 9 4.3.3を登録してください。 取引. . . . . . . . . . . . . . . . . 10 4.4を招待してください。 中間的プロキシ. . . . . . . . . . . . 12 4.4.1における手順。 一般プロキシの振舞い. . . . . . . . . . . . . . . . 12 4.4.2。 自動応答と分岐. . . . . 12 4.5の問題。 ユーザエージェントサーバ(UAS). . . . . . . . . . 13 4.5.1における手順。 取引. . . . . . . . . . . . . . . . . 13 5を招待してください。 応答. . . . . . . . . . . . . . . . . . . . . 14 5.1におけるアンサーモードとPriv-アンサーモードヘッダーフィールドの用法。 UAS. . . . . . . . . . . . . . . . . . 14 5.2の手順。 UAC. . . . . . . . . . . . . . . . . . 15 6の手順。 用法. . . . . . . . . . . . . . . . . . . . . . 15 6.1に関する例。 要求. . . . . . . . . . . . . . . . . . . . . 15 6.2を登録してください。 要求. . . . . . . . . . . . . . . . . . . . . . 16 6.3を招待してください。 200 (OK)応答. . . . . . . . . . . . . . . . . . . . 16 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 16 7.1。 攻撃感度は.177.2にメディアの特性に依存します。 アプリケーション設計は攻撃の機会. . . . . . 19 7.3に影響します。 分析. . . . . . . . . . . . . . . . . . 19 7.4を適用します。 最小量の方針要件. . . . . . . . . . . . . . . . 21 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . 22 8.1。 ヘッダーフィールド. . . . . . . . . . . . . . 22 8.2の登録。 ヘッダーフィールドパラメタ. . . . . . . . . 22 8.3の登録。 一口オプションの登録は.229にタグ付けをします。 承認. . . . . . . . . . . . . . . . . . . . . . . 23 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 23 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 24
Willis & Allen Standards Track [Page 2] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[2ページ]RFC5373一口
1. Background
1. バックグラウンド
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 INVITE)と要求を受け取るユーザに通知するのを求める要求、要求とセッションのそのユーザ、および3の)2)承認にリクエスタへの応答(SIP200OK)の発信を送りながらSession Initiationプロトコル(SIP、[RFC3261)は1を伴う)を使用するセッション設立のための従来機は確立されます。 いくつかの用法シナリオが特に通知と承認フェーズに関してこのモデルから逸れます。 通知と承認フェーズをサボるという要求を受け取るノードに、それはいつも可能ですが、明確に、この種類の処理に関する願望(または、要件)を示すという要求を送るパーティーのためのどんな標準のメカニズムもありませんでした。 このドキュメントは特殊療法が通知と承認フェーズに関連したよう要求するのに使用できる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番目のシナリオはプッシュから話へのアプリケーションのものです(オープンのモバイルAllianceによって指定されました)。 この種類の環境で、SIPは単方向のメディア流動の非同期な配送を支持する対話を証明するのに使用されます、伝統的な送受信兼用の無線機のもののようなユーザー・エクスペリエンスを提供して。 呼ばれたUA(ユーザエージェント)によって自動的に受け入れられるのに使用されるINVITESにおいて、それは従来です、そして、メディアはスピーカの上に一般的に展開されます。 ユーザが応じるために地方の「話」のボタンを押すまで、被呼者の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
3番目のシナリオは兵士の支店Exchange(PBX)付添人です。 伝統的なオフィスPBXシステムはしばしばインターホンの機能性を含んでいます。 インターホン機能の典型的な使用は訪問者を発表するために受付係が卓上電話の上でスピーカを動かすのを許容することです。 すべての訪問者がスピーカと、唯一にアクセスできるというわけではありません。
Willis & Allen Standards Track [Page 3] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[3ページ]RFC5373一口
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.
受付係かオペレータと、それがそうです。これらの訪問者はいつも「インターホン」の機能性が欲しくなるでしょう--彼らが代わりに普通通話をしたがっているかもしれないと予想しませんでした。
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 Modeに答えると、振舞いは、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 Modeを警告すると、振舞いは、セッションを開始するという要求が受け取られたことを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拡大ヘッダーフィールドを定義します: 「アンサーモード」と「Priv-アンサーモード。」 これらの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-モードとPriv答えモードの区別はUserエージェントServer(UAS)によってUserエージェントClient(UAC)によって要求されて、確かめられて、取り締まられた認可のレベルに関連します。 Answer-モードを使用することで通常要求をします。 Priv答えモードを使用することでされた要求はUASから「特権がある」処理を要求します。 以下の、よりすばらしい詳細、セクション4.1でこのメカニズムについて議論します。
Willis & Allen Standards Track [Page 4] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[4ページ]RFC5373一口
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答えモードは特権の主張ではありません。 代わりに、特権がある処理を求めてそれは要求です。 これはUNIXモデルと同様です。そこでは、ユーザは、コマンドのために管理特権を要求するのに通常、コマンドを走らせるか、または"sudo"を使用するかもしれません。 "Priv"が"sudo"とのUNIXコマンドを前に置きながら相当している包含。 言い換えれば、別々の方針テーブル("/etc/sudoers"のような)は、ユーザが要求された処理を受けるかもしれないかどうか決定するために相談されます。
This distinction is discussed in greater detail in Section 4.1.
セクション4.1で詳細によりすばらしいこの区別について議論します。
1.1. Requirements Language
1.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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Syntax of Header Fields and Option Tags
2. ヘッダーフィールドとオプションタグの構文
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)
Priv答えモードは「Priv-アンサーモード」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」)を含んでいます。 この仕様は明らかに上に与えられた値のための振舞いだけを定義します。 下位互換を提供するために、実現は未知の値を無視しなければなりません。
Willis & Allen Standards Track [Page 5] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[5ページ]RFC5373一口
3. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields
3. アンサーモードとPriv-アンサーモードヘッダーフィールドの用法
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 INVITE要求とそれらの要求への200(OK)の応答でAnswer-モードとPriv答えモードヘッダーフィールドの用法を定義します。 このドキュメントはいかなる他の種類の要求か応答でも用法を明確に定義しません、他の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.
この制限はそのような要求に応じながら新しいコミュニケーションセッションといつを要求するかときユーザがコミュニケーション装置と対話する方法に影響することであるこの拡大の意図している用法によります。 この種類の相互作用は再INVITEなどのその後の操作の間、起こるのではなく、対話とその初期の用法の構成だけの間起こります。 しかしながら、記述が再INVITESか同様の要求で導入したメディアでセッション開始のセキュリティ局面を変化に適用しなければなりません。 この問題のさらなる議論に関してセクション7.1を見てください。
4. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in
Requests
4. 要求におけるアンサーモードとPriv-アンサーモードヘッダーフィールドの用法
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-モードかPriv答えモードヘッダーフィールドは特定の取り扱いを呼び出すというINVITE要求で応じているUASによってUACによって使用されます。 この取り扱いはそのINVITE要求から生じるどんな対話のための「自動応答」の機能性にも関連します。 Answer-モードかPriv答えモードヘッダーフィールドが全く要求に含まれていないなら、UASの裁量には振舞いに答えるのがあります、それがこの仕様がないときあるだろうというとき。 必要な取り扱いは以下の通りAnswer-モードかPriv答えモードヘッダーフィールドの値によって示されます:
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.
自動車: UASが自動的に要請を受け入れるように頼まれます、ユーザが、UASが要請を受け入れることを望んでいるのを示すほどUASのユーザがUASのUIとそのような方法で対話するのを待たない。
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
Answer-モードかPriv答えモードヘッダーフィールドの各値は任意のパラメタ、「必要」を含むことができます。 存在しているなら、このパラメタは、UACが、UASが別のモードで答えるよりむしろ要求されたモードで答えたがっていないなら(恐らく方針による)UASが要求を拒絶するのを好むのを示します。 例えば、これ
Willis & Allen Standards Track [Page 6] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[6ページ]RFC5373一口
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.
パラメタは、テスト「ループバック」呼び出しが訪問者が自動着信を要求しても手動で答えるために彼女の電話を構成したユーザの心をかき乱さないのを確実にするのに使用されるかもしれません。
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 Digest Authentication[RFC3261]などの認証機構を使用することで示された認証されたアイデンティティに基づく認可決定をします、SIP Identityメカニズム[RFC4474]、または、中で信じられた断言されたアイデンティティのための(それが適している制限されたネットワークの中の)SIPメカニズムは[RFC3325]をネットワークでつなぎます。 また、認可決定をするとき、UASはUASに利用可能な認可情報か方針を使用するはずです。 この意志決定は要求に対応するメディアセッションのリスクモデル、およびユーザのプライバシーかセキュリティがその結果妥協する場合におけるユーザ入力のないUAS MUST NOT答えを考えなければなりません。 この決断をするのはシステムかアプリケーション設計の問題であり、一般に、1セットのオンかオフに構成可能な機能を持っていることによって、記述できません。 セクション7でメディアセッションと適切な方針の特定の議論について議論します。
4.1. The Difference Between Answer-Mode and Priv-Answer-Mode
4.1. アンサーモードとPriv-アンサーモードの違い
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-モードとPriv答えモードヘッダーフィールドの関数は同様です。 それらの両方が、UASが指定されるとしてのヘッダーフィールドの値(自動であるか手動の)による要求を扱うように頼みます。 違いが要求がUASの方針と対話する方法であります。 典型的なUASには、各ヘッダーフィールドを扱うための異なった方針があるでしょう。 例えば、UASのユーザが「ミーティングモード」にそのUASを置いたと仮定してください、彼女を重要な活動に従事して、偽って中断されたくないのを示して。 UASはAnswer-モード要求のために「ミーティングモード」で禁じている間、自動応答を禁じるかもしれません。 しかしながら、そのUASはPriv答えモードでされた要求のための自動応答を許容するかもしれません。 たぶん、認可方針の違いがあるでしょう。 例えば、UASが構成されるかもしれないので、「友人」リストの上の訪問者はPriv答えモードではなく、Answer-モードを使用することで要求をすることができます。 その同じUASは、「管理者」リストの上の訪問者がPriv答えモードを使用するのを許容するだけであるために構成されるかもしれません。 これはいつも振舞いを起呼側のアイデンティティに基礎づけるのと異なっています。 例えば、訪問者「ボブ」が「友人」リストと「管理者」リストの両方にあると仮定してください。 ボブが通常の方針によると、処理されるという彼の要求が欲しいなら、彼はAnswer-モードを使用します。 ボブが、より制限している「特権がある」方針の下で処理されるという彼の要求が欲しいなら、彼はPriv答えモードを使用します。
Willis & Allen Standards Track [Page 7] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[7ページ]RFC5373一口
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 SHOULDはAnswer-モードとの要求に適用するより厳しい認可方針をPriv答えモードとの要求に適用します。 デフォルト方針SHOULDはリクエスタが認証されて、Priv答えモードを要求にするのは明確に認可されない場合Privモードに答えているヘッダーフィールドを含む要求を拒否することになっています。 そのような方針を実施しない場合、セクション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答えモードのために思い描いた使用は認可された訪問者からの緊急の要求について取り扱いに話します。 例えば、ラリーが船隊の発送者と共に働いているリムジンの運転手であると仮定してください。 ラリーが、静かな環境を彼の車に供給するのが好きであるので、彼の伝達者はプッシュから話(答えモード: 自動車)への呼び出しを含むすべての非特権がある呼び出しのための手動のアンサーモードのために構成されます。 その都度、彼は、呼び出しに彼の注意を喚起するために柔らかく呼び出し、ラリーの伝達者チャイムを手に入れます。 事情がそれを可能にするなら、ラリーは呼び出しを受け入れるために伝達者を押します、そして、伝達者は200(OK)応答を送ります、そして、起呼側の話炸裂は伝達者のスピーカを通して展開されます。 この処理は、「マニュアル」の値を持っているAnswer-モードヘッダーフィールドを持っている入って来る要求に渡されるか「自動である」(または、全くAnswer-モードヘッダーフィールドがありません)、訪問者がだれであっても。
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.
ラリーの船隊の発信オペレータは、この方針になじみ深く、批判的な件に関してラリーに知らせる必要があります。 発信オペレータは何度かプッシュから話への呼び出しラリー(Answerモードを含んでいます: 要求における自動車)に試みますが、ラリーが、寝入って、したがって、呼び出しを受け入れるように彼の伝達者に強要していないので、呼び出しは受け入れられません。
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要求がaを運ぶ、「Priv-アンサーモード:」 「自動である」ヘッダーフィールド。 ラリーの伝達者は訪問者(SIP Identity主張か機能上同等なメカニズムを使用する)、およびユーザーズ・リストに対するオペレータのアイデンティティでPriv答えモードをしたマッチのアイデンティティをチェックします。 オペレータが記載されているので、伝達者はすぐに、呼び出しを受け入れながら、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-モード要求により高い特権を与えるという効果がリクエスタのアイデンティティと対応する認可レベルを基礎づけたより異なっています。 この区別は船隊のオペレータが正常な状況では礼儀正しい(答えモード: 自動車)要求をラリーに出して、重大な緊急要件を持っている要求のために、異なった取り扱い(Priv答えモード: 自動車)を受け取ることです。
Willis & Allen Standards Track [Page 8] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[8ページ]RFC5373一口
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.
通常操作では、どちらかのAnswer-モードかPriv-答えモードの唯一の1つがINVITE要求で使用されるでしょう。 両方が存在していると、まるでPriv答えモードだけが含まれていたかのように、UASは最初に、Priv答えモードがないかどうかリクエスタの認可をテストして、認可されると、要求を処理するでしょう。 リクエスタがPriv答えモードのために認可されないと、まるでAnswer-モードだけが含まれていたかのようにUASは要求を処理するでしょう。
4.2. The "require" Modifier
4.2. 「必要」修飾語
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-モードとPriv答えモードの両方が「必要」の修飾語を許容する、(例:、「Priv-アンサーモード: 自動車;、必要である、」、) 手動的か自動的に答えるかどうかを選ぶ際にこの修飾語はUASの方針に影響を及ぼしません。 UASは、要求の他の局面に基づいて自動的に答えるかどうか決めます。 UASが回答モードを選択した後に「必要」修飾語は評価されるだけです。 UASの方針が要求で指定されたそれと異なった回答モードをもたらしたなら、「必要」修飾語の存在は、呼び出しを拒絶するようにUASに頼みます。 与えられた例、UASに、「特権がある」方針の下における自動応答、訪問者が要求(手動で答えるよりむしろ)を拒絶するのに権限を与えられて、訪問者はこのモードのために権限を与えられないなら自動的に答える尋ねられるのがあります。 セクション4.5で、より多くの深さでこれについて議論します。
4.3. Procedures at User Agent Clients (UAC)
4.3. ユーザエージェントのクライアントにおける手順(UAC)
4.3.1. All Requests
4.3.1. すべての要求
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-モードを支持するUAとPriv答えモードヘッダーフィールドSHOULDは、それが送るすべての要求のSupportedヘッダーフィールドに"answermode"のオプションタグを含んでいることによって、サポートを示します。
4.3.2. REGISTER Transactions
4.3.2. 取引を登録してください。
To indicate that it supports the answer-mode negotiation feature, a UA MAY include an extensions parameter with a value that includes "answermode". Example:
アンサーモード交渉機能、UA MAYを支持するのを示すには、"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]で説明されます。
Willis & Allen Standards Track [Page 9] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[9ページ]RFC5373一口
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要求における値の"pref"があるRequireヘッダーフィールドを含むかもしれません。 これで、記録係が訪問される人能力と訪問者好みを支持しないと、記録係は要求を拒絶するでしょう。 例:
Require: pref
必要です: pref
4.3.3. INVITE Transactions
4.3.3. 取引を招待してください。
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にAnswer-モードかPriv答えモードヘッダーフィールドを含むかもしれません。
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.
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.
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:
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:
Answer-Mode: Manual
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:
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:
Answer-Mode: Manual;require
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:
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:
Answer-Mode: Auto
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:
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:
Answer-Mode: Auto;require
Answer-Mode: Auto;require
Willis & Allen Standards Track [Page 10] RFC 5373 SIP Answering Modes November 2008
Willis & Allen Standards Track [Page 10] RFC 5373 SIP Answering Modes November 2008
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:
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:
Require: answermode
Require: 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:
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:
Require: answermode Accept-Contact:
*;extensions="answermode";methods="INVITE"
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:
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:
Require: answermode Accept-Contact:
*;extensions="answermode"; methods="INVITE";require
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:
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:
Require: answermode Accept-Contact:
*;extensions="answermode";
methods="INVITE";require;explicit
Require: answermode Accept-Contact: *;extensions="answermode"; methods="INVITE";require;explicit
Willis & Allen Standards Track [Page 11] RFC 5373 SIP Answering Modes November 2008
Willis & Allen Standards Track [Page 11] RFC 5373 SIP Answering Modes November 2008
4.4. Procedures at Intermediate Proxies
4.4. Procedures at Intermediate Proxies
4.4.1. General Proxy Behavior
4.4.1. General Proxy Behavior
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.
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.
4.4.2. Issues with Automatic Answering and Forking
4.4.2. Issues with Automatic Answering and Forking
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.
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.
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.
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.
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.
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.
Willis & Allen Standards Track [Page 12] RFC 5373 SIP Answering Modes November 2008
Willis & Allen Standards Track [Page 12] RFC 5373 SIP Answering Modes November 2008
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.
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.
4.5. Procedures at User Agent Servers (UAS)
4.5. Procedures at User Agent Servers (UAS)
4.5.1. INVITE Transactions
4.5.1. INVITE Transactions
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.
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.
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".
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".
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", 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."
Willis & Allen Standards Track [Page 13] RFC 5373 SIP Answering Modes November 2008
Willis & Allen Standards Track [Page 13] RFC 5373 SIP Answering Modes November 2008
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".
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".
Similar behavior applies for Priv-Answer-Mode, except that the policy for authorization may be different (and generally more stringent).
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
5. Usage of the Answer-Mode and Priv-Answer-Mode Header Fields in Responses
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:
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:
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.
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.
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: 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.
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.
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.
5.1. Procedures at the UAS
5.1. Procedures at the UAS
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
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
Willis & Allen Standards Track [Page 14] RFC 5373 SIP Answering Modes November 2008
Willis & Allen Standards Track [Page 14] RFC 5373 SIP Answering Modes November 2008
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.
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.
5.2. Procedures at the UAC
5.2. Procedures at the UAC
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.
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.
6. Examples of Usage
6. Examples of Usage
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.
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.
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.
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.
6.1. REGISTER Request
6.1. REGISTER Request
In the following example, Bob's UA is registering and indicating that it supports the answermode extension.
In the following example, Bob's UA is registering and indicating that it supports the answermode extension.
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"
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"
Willis & Allen Standards Track [Page 15] RFC 5373 SIP Answering Modes November 2008
Willis & Allen Standards Track [Page 15] RFC 5373 SIP Answering Modes November 2008
6.2. INVITE Request
6.2. INVITE Request
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".
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".
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: ...
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: ...
6.3. 200 (OK) Response
6.3. 200 (OK) Response
Here, Bob has accepted the call and his UA has answered automatically, which it indicates in the 200 (OK) response.
Here, Bob has accepted the call and his UA has answered automatically, which it indicates in the 200 (OK) response.
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 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: ...
7. Security Considerations
7. Security Considerations
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).
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).
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
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
Willis & Allen Standards Track [Page 16] RFC 5373 SIP Answering Modes November 2008
Willis & Allen Standards Track [Page 16] RFC 5373 SIP Answering Modes November 2008
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).
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).
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.
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.
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.
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.
Media attacks can be loosely categorized as:
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.
Insertion: Media is inserted into and played out by the victim UA without consent of the UA's user.
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.
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.
7.1. Attack Sensitivity Depends on Media Characteristics
7.1. Attack Sensitivity Depends on Media Characteristics
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
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
Willis & Allen Standards Track [Page 17] RFC 5373 SIP Answering Modes November 2008
Willis & Allen Standards Track [Page 17] RFC 5373 SIP Answering Modes November 2008
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.
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.
The media modalities of interest appear to be:
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-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.
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-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.
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.
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.
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.
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.
Willis & Allen Standards Track [Page 18] RFC 5373 SIP Answering Modes November 2008
Willis & Allen Standards Track [Page 18] RFC 5373 SIP Answering Modes November 2008
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.
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.
7.2. Application Design Affects Attack Opportunity
7.2. Application Design Affects Attack Opportunity
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 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).
プッシュから話へのアプリケーションでは、メディアは発信して、呼ばれたUASからユーザ入力(「プッシュから話」の「プッシュ」)なしでユーザ見落としのないUASにもかかわらず、メディアがないことへのUACを送るということであるかもしれません。 その結果、「私の電話を悩ましてください」という攻撃の機会が全くありません。 さらに、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.
同様のアプローチはほとんどのアプリケーションに適用されます。 簡単な承認方針にアイデンティティメカニズムを結合することによって、挿入を制御できます、そして、(しかし、排泄しません)事実上、攻撃的な承認方針、そして/または、ユーザ相互作用に強いアイデンティティメカニズムを結合することによって、妨害を排除できます。
7.3. Applying the Analysis
7.3. 分析を適用します。
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
本書では説明された拡大はUACが、UASが以下に記載された5つの防衛的なメカニズムのうち2を配布しないよう要求できるメカニズムを提供します--ユーザ警告とユーザ承認。 これが挿入攻撃の過度の危険か妨害攻撃の増強された危険を作り出さないように、したがって、私たちはやむを得ず残っている防衛的なメカニズムを当てにします。このドキュメントは満足できるセキュリティのために最小の敷居を定義します。 確かに以上
Willis & Allen Standards Track [Page 19] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[19ページ]RFC5373一口
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.
引締政策が合理的に使用されているかもしれませんが、どんな方針も以下で説明されたアプローチが重要な安全保障問題を非常にもたらしそうなほど制限していません。
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. Input/出力(入出力)を制限してください--スピーカかマイクロホンをオフにしてください。 双方向のメディアセッションを変換するのにこれを使用できた、(非常に危険で、可能である、「私の電話を悩ましてください」、)、本国行きに唯一(より危険で、それほど可能でない「スパム」や「要約」など)の単方向、ユーザ承認を待っている間のセッション。
5. Policy -- Rules about other factors, such as black- and
whitelisting based on identity, disallowing acceptance without
alerting, etc.
5. 方針--黒や警告などなしで承認を禁じて、アイデンティティに基づくwhitelistingなどの他の要素に関する規則
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と関連する仕事が既に、数個のメカニズム(私設のネットワーク[RFC3325]の中にそれが適しているネットワークでSIP Digest Authentication[RFC3261]、SIP Identityメカニズム[RFC4474]、および断言されたアイデンティティのためのSIPメカニズムを含んでいる)を要求の創始者のアイデンティティを確立するのに提供するので、私たちは、適切に選択されたメカニズムが本書では説明された拡大を実装するUAsに利用可能であると推定します。 要するに、これらの拡大を実装するUAsは備えなければならなくて、要求アイデンティティメカニズムを運動させなければなりません。 以下での分析は、それぞれの要求の送付者のアイデンティティが知られているか、または未知であることが知られているという仮定から生じて、したがって、関連する方針問題で考えることができます。 このアイデンティティ必要条件を満たさない場合、さまざまな攻撃を可能にするか、またはこれらの拡大を役に立たなくするほどきつい運用政策を必要とします。
Willis & Allen Standards Track [Page 20] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[20ページ]RFC5373一口
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の最小量の方針で禁じられます。(書かれるとして、セクションは、「明らかに認可された外国行きのメディア」に関するすべてのケースを除きます)。
7.4. Minimal Policy Requirement
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 .
この仕様がSHOULD NOTであると実装するユーザエージェントが明白なユーザ承認なしで要求しているユーザが未知である、知られていて、またはそのようなセッションのために承認は与えられていないところに本国行きのメディアを提供するセッションを確立します。 予期していなくて求められていないメディアが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,
この仕様を履行するユーザエージェントはユーザエージェントから明白なユーザ承認なしで出典を明示された外国行きの、または、双方向のメディアを提供するセッションを確立してはいけません。 メディアが接続性テストに使用したループバックはこの要件によって抑制されません。 この要件が、ユーザに関する知識なしでUASを遠隔操作のマイクロホン(「急いで去る」)に変えるのにこの拡張子を使用できないことを保証することを意図します。 以来、SIPは外国行きの、または、双方向のセッションに初めは本国行きに唯一のメディアで設立されるべきセッションのために許容して、次に、移行しました(再INVITEかUPDATEを通して)。
Willis & Allen Standards Track [Page 21] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[21ページ]RFC5373一口
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.
この方針を実施するのはSIP UASの対話ステートフルインスペクションを必要とします。 言い換えれば、UASのユーザによる明白な承認なしで外国行きのメディアを送るモードへのUAS MUST NOT変遷セッションが自動応答で開始されたなら。
8. IANA Considerations
8. IANA問題
8.1. Registration of Header Fields
8.1. ヘッダーフィールドの登録
This document defines new SIP header fields named "Answer-Mode" and "Priv-Answer-Mode".
このドキュメントは「アンサーモード」と「Priv-アンサーモード」という新しい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] |
+------------------+--------------+-----------+
+------------------+--------------+-----------+ | ヘッダー名| コンパクト形| 参照| +------------------+--------------+-----------+ | アンサーモード| | [RFC5373]| | Priv-アンサーモード| | [RFC5373]| +------------------+--------------+-----------+
8.2. Registration of Header Field Parameters
8.2. ヘッダーフィールドパラメタの登録
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".
このドキュメントは先行するセクションで定義されたヘッダーフィールドのためのパラメタを定義します。 ヘッダーフィールド「アンサーモード」と「モードにPriv答えること」は値「マニュアル」か「自動車」を取ることができます。
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] | +------------------+----------------+-------------------+-----------+
+------------------+----------------+-------------------+-----------+ | ヘッダーフィールド| パラメタ名| 事前に定義された値| 参照| +------------------+----------------+-------------------+-----------+ | アンサーモード| 必要です。| いいえ| [RFC5373]| | Priv-アンサーモード| 必要です。| いいえ| [RFC5373]| +------------------+----------------+-------------------+-----------+
8.3. Registration of SIP Option Tags
8.3. 一口オプションタグの登録
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 Parameter Registryの「オプションタグ」セクションに以下の行を追加してあります:
Willis & Allen Standards Track [Page 22] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[22ページ]RFC5373一口
+------------+------------------------------------------+-----------+ | 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. | | +------------+------------------------------------------+-----------+
+------------+------------------------------------------+-----------+ | 名前| 記述| 参照| +------------+------------------------------------------+-----------+ | answermode| このオプションタグはサポートのためにあります。| [RFC5373]| | | アンサーモードとPriv-アンサーモード| | | | 拡大は以前はよく自動で交渉されていました。| | | | または、要求の手動応答。 | | +------------+------------------------------------------+-----------+
9. Acknowledgements
9. 承認
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.
このドキュメントはオープンのモバイルAllianceの仕事と、特にアンドリュー・アレン、ジャン・ホルム、およびトム・ハリンによるドキュメントから要件と方法論のかなりの部分を引き出します。
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.
また、エディタはIETF62でSIPPINGメーリングリストの上と、そして、OMA臨時総会で上記のドキュメントの基本的な考えがSIP共同体に広く適切であり、警告と回答の概念が明確に図で表わされるべきであると主張したデヴィッド・オランと他のものの貢献を認識したがっています。 さらに、サンディー・マーフィーによって提供された安全レビューとSureshクリシュナンによる芸術に情報を得ているレビューはこのドキュメントの品質を改良する際に非常に役立っていました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[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、「セッション開始プロトコル(一口)のための訪問者好み」、RFC3841、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.ジョニングス、「セッション開始における認証されたアイデンティティ管理のための増進は(一口)について議定書の中で述べます」、RFC4474、2006年8月。
Willis & Allen Standards Track [Page 23] RFC 5373 SIP Answering Modes November 2008
モード2008年11月に答えるウィリスとアレン標準化過程[23ページ]RFC5373一口
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
10.2. Informative References
10.2. 有益な参照
[LOOPBACK] Hedayat, K., "An Extension to the Session Description
Protocol (SDP) for Media Loopback", Work in Progress,
August 2008.
[ループバック] ヘダーヤト、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.ワトソン、「セッション開始への個人的な拡大は断言されたアイデンティティのために信じられたネットワークの中で(一口)について議定書の中で述べます」、RFC3325、2002年11月。
Authors' Addresses
作者のアドレス
Dean Willis (editor) Softarmor Systems 3100 Independence Pkwy #311-164 Plano, Texas 75075 USA
#311-164プラノ、ディーンウィリス(エディタ)Softarmor Systems3100独立テキサス75075米国Pkwy
EMail: dean.willis@softarmor.com
メール: dean.willis@softarmor.com
Andrew Allen Research in Motion (RIM) 300 Knightsbridge Parkway, Suite 360 Lincolnshire, Illinois 60069 USA
動き(縁)300ナイツブリッジスイート360リンカンシャー、イリノイ60069パークウェイ(米国)のアンドリューアレンResearch
EMail: aallen@rim.com
メール: aallen@rim.com
Willis & Allen Standards Track [Page 24]
ウィリスとアレン標準化過程[24ページ]
一覧
スポンサーリンク
