[要約] RFC 4504は、SIPテレフォニーデバイスの要件と設定に関するガイドラインです。このRFCの目的は、SIPベースのテレフォニーデバイスの標準化と互換性の向上を促進することです。
Network Working Group H. Sinnreich, Ed.
Request for Comments: 4504 pulver.com
Category: Informational S. Lass
Verizon
C. Stredicke
snom
May 2006
SIP Telephony Device Requirements and Configuration
SIPテレフォニーデバイスの要件と構成
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document describes the requirements for SIP telephony devices, based on the deployment experience of large numbers of SIP phones and PC clients using different implementations in various networks. The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for PCs, PDAs, analog feature phones or mobile phones.
このドキュメントでは、さまざまなネットワークのさまざまな実装を使用して、多数のSIP電話とPCクライアントの展開エクスペリエンスに基づいて、SIPテレフォニーデバイスの要件について説明します。要件の目的は、PC、PDA、アナログ機能電話、または携帯電話で見られるように、同様の購入、インストール、および操作を容易にするために、明確に定義された相互運用性とマルチベンダーがサポートするコア機能のセットです。
We present a glossary of the most common settings and some of the more widely used values for some settings.
最も一般的な設定の用語集と、一部の設定でより広く使用されている値のいくつかを提示します。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Conventions used in this document ..........................4
2. Generic Requirements ............................................4
2.1. SIP Telephony Devices ......................................4
2.2. DNS and ENUM Support .......................................5
2.3. SIP Device Resident Telephony Features .....................5
2.4. Support for SIP Services ...................................8
2.5. Basic Telephony and Presence Information Support ...........9
2.6. Emergency and Resource Priority Support ....................9
2.7. Multi-Line Requirements ...................................10
2.8. User Mobility .............................................11
2.9. Interactive Text Support ..................................11
2.10. Other Related Protocols ..................................12
2.11. SIP Device Security Requirements .........................13
2.12. Quality of Service .......................................13
2.13. Media Requirements .......................................14
2.14. Voice Codecs .............................................14
2.15. Telephony Sound Requirements .............................15
2.16. International Requirements ...............................15
2.17. Support for Related Applications .........................16
2.18. Web-Based Feature Management .............................16
2.19. Firewall and NAT Traversal ...............................16
2.20. Device Interfaces ........................................17
3. Glossary and Usage for the Configuration Settings ..............18
3.1. Device ID .................................................18
3.2. Signaling Port ............................................19
3.3. RTP Port Range ............................................19
3.4. Quality of Service ........................................19
3.5. Default Call Handling .....................................19
3.5.1. Outbound Proxy .....................................19
3.5.2. Default Outbound Proxy .............................20
3.5.3. SIP Session Timer ..................................20
3.6. Telephone Dialing Functions ...............................20
3.6.1. Phone Number Representations .......................20
3.6.2. Digit Maps and/or the Dial/OK Key ..................20
3.6.3. Default Digit Map ..................................21
3.7. SIP Timer Settings ........................................21
3.8. Audio Codecs ..............................................21
3.9. DTMF Method ...............................................22
3.10. Local and Regional Parameters ............................22
3.11. Time Server ..............................................22
3.12. Language .................................................23
3.13. Inbound Authentication ...................................23
3.14. Voice Message Settings ...................................23
3.15. Phonebook and Call History ...............................24
3.16. User-Related Settings and Mobility .......................24
3.17. AOR-Related Settings .....................................25
3.18. Maximum Connections ......................................25
3.19. Automatic Configuration and Upgrade ......................25
3.20. Security Configurations ..................................26
4. Security Considerations ........................................26
4.1. Threats and Problem Statement .............................26
4.2. SIP Telephony Device Security .............................27
4.3. Privacy ...................................................28
4.4. Support for NAT and Firewall Traversal ....................28
5. Acknowledgements ...............................................29
6. Informative References .........................................31
This document has the objective of focusing the Internet communications community on requirements for telephony devices using SIP.
このドキュメントには、SIPを使用したテレフォニーデバイスの要件にインターネット通信コミュニティを集中させる目的があります。
We base this information from developing and using a large number of SIP telephony devices in carrier and private IP networks and on the Internet. This deployment has shown the need for generic requirements for SIP telephony devices and also the need for some specifics that can be used in SIP interoperability testing.
この情報は、キャリアおよびプライベートIPネットワーク、およびインターネットで多数のSIPテレフォニーデバイスを開発および使用しています。この展開により、SIPテレフォニーデバイスの一般的な要件が必要であり、SIP相互運用性テストで使用できるいくつかの詳細が必要になりました。
SIP telephony devices, also referred to as SIP User Agents (UAs), can be any type of IP networked computing user device enabled for SIP-based IP telephony. SIP telephony user devices can be SIP phones, adaptors for analog phones and for fax machines, conference speakerphones, software packages (soft clients) running on PCs, laptops, wireless connected PDAs, 'Wi-Fi' SIP mobile phones, as well as other mobile and cordless phones that support SIP signaling for real-time communications. SIP-PSTN gateways are not the object of this memo, since they are network elements and not end user devices.
SIPユーザーエージェント（UAS）とも呼ばれるSIPテレフォニーデバイスは、SIPベースのIPテレフォニーに有効になっているあらゆるタイプのIPネットワークコンピューティングユーザーデバイスにすることができます。SIPテレフォニーユーザーデバイスは、SIP携帯電話、アナログ電話、ファックスマシン、会議スピーカー、PCで実行されるソフトウェアパッケージ（ソフトクライアント）、ワイヤレス接続PDA、 'wi-fi' SIP携帯電話、その他リアルタイム通信用のSIPシグナリングをサポートするモバイルおよびコードレス電話。SIP-PSTNゲートウェイは、ネットワーク要素であり、エンドユーザーデバイスではないため、このメモのオブジェクトではありません。
SIP telephony devices can also be instant messaging (IM) applications that have a telephony option.
SIPテレフォニーデバイスは、テレフォニーオプションを持つインスタントメッセージング（IM）アプリケーションにすることもできます。
SIP devices MAY support various other media besides voice, such as text, video, games, and other Internet applications; however, the non-voice requirements are not specified in this document, except when providing enhanced telephony features.
SIPデバイスは、テキスト、ビデオ、ゲーム、その他のインターネットアプリケーションなど、音声以外のさまざまなメディアをサポートする場合があります。ただし、拡張されたテレフォニー機能を提供する場合を除き、このドキュメントでは、非声の要件は指定されていません。
SIP telephony devices are highly complex IP endpoints that speak many Internet protocols, have audio and visual interfaces, and require functionality targeted at several constituencies: (1) end users, (2) service providers and network administrators, (3) manufacturers, and (4) system integrators.
SIPテレフォニーデバイスは、多くのインターネットプロトコルを話す非常に複雑なIPエンドポイントであり、オーディオとビジュアルインターフェイスを備えており、いくつかの選挙区を対象とした機能を必要とします。（1）エンドユーザー、（2）サービスプロバイダーとネットワーク管理者、（3）メーカー、および（4）システムインテグレーター。
The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for standard PCs, analog feature phones, or mobile phones. Given the cost of some feature-rich display phones may approach the cost of PCs and PDAs, similar or even better ease of use as compared to personal computers and networked PDAs is expected by both end users and network administrators.
要件の目的は、標準のPC、アナログ機能電話、または携帯電話で見られるように、同様の購入、インストール、および操作を可能にするために、明確に定義された相互運用性とマルチベンダーがサポートするコア機能のセットです。一部の機能が豊富なディスプレイ電話のコストを考えると、PCとPDAのコストに近づくと、パソコンとネットワーク管理者の両方がネットワーク化されたPDAと比較して、同様またはさらに容易に使いやすい場合があります。
While some of the recommendations of this document go beyond what is currently mandated for SIP implementations within the IETF, this is believed necessary to support the specified operational objectives.
このドキュメントの推奨事項の一部は、IETF内のSIP実装に現在義務付けられているものを超えていますが、これは指定された運用目標をサポートするために必要であると考えられています。
However, it is also important to keep in mind that the SIP specifications are constantly evolving; thus, these recommendations need to be considered in the context of that change and evolution. Due to the evolution of IETF documents in the standards process, and the informational nature of this memo, the references are all informative.
ただし、SIP仕様は常に進化していることに留意することも重要です。したがって、これらの推奨事項は、その変化と進化の文脈で考慮する必要があります。標準プロセスでのIETFドキュメントの進化と、このメモの情報性の性質により、参照はすべて有益です。
This document is informational and therefore the key words "MUST", "SHOULD", "SHOULD NOT", and "MAY", in this document are not to be interpreted as described in RFC 2119 [1], but rather indicate the nature of the suggested requirement.
このドキュメントは情報に基づいているため、キーワードは「必須」、「すべき」、「すべきではない」、および「5月」です。このドキュメントは、RFC 2119 [1]で説明されているように解釈されるのではなく、提案された要件。
We present here a minimal set of requirements that MUST be met by all SIP [2] telephony devices, except where SHOULD or MAY is specified.
ここでは、すべてのSIP [2]テレフォニーデバイスで満たされなければならない最小限の要件を示します。
This memo applies mainly to desktop phones and other special purpose SIP telephony hardware. Some of the requirements in this section are not applicable to PC/laptop or PDA software phones (soft phones) and mobile phones.
このメモは、主にデスクトップ電話やその他の特別な目的のSIPテレフォニーハードウェアに適用されます。このセクションの要件の一部は、PC/ラップトップまたはPDAソフトウェア電話（ソフトフォン）および携帯電話に適用できません。
Req-1: SIP telephony devices MUST be able to acquire IP network settings by automatic configuration using Dynamic Host Configuration Protocol (DHCP) [3].
REQ-1：SIPテレフォニーデバイスは、動的ホスト構成プロトコル（DHCP）[3]を使用して自動構成によりIPネットワーク設定を取得できる必要があります。
Req-2: SIP telephony devices MUST be able to acquire IP network settings by manual entry of settings from the device.
REQ-2：SIPテレフォニーデバイスは、デバイスから設定を手動で入力することにより、IPネットワーク設定を取得できる必要があります。
Req-3: SIP telephony devices SHOULD support IPv6. Some newer wireless networks may mandate support for IPv6 and in such networks SIP telephony devices MUST support IPv6.
REQ-3：SIPテレフォニーデバイスはIPv6をサポートする必要があります。一部の新しいワイヤレスネットワークは、IPv6のサポートを義務付ける場合があり、そのようなネットワークでは、SIPテレフォニーデバイスがIPv6をサポートする必要があります。
Req-4: SIP telephony devices MUST support the Simple Network Time Protocol [4].
REQ-4：SIPテレフォニーデバイスは、単純なネットワークタイムプロトコル[4]をサポートする必要があります。
Req-5: Desktop SIP phones and other special purpose SIP telephony devices MUST be able to upgrade their firmware to support additional features and the functionality.
REQ-5：デスクトップSIP電話およびその他の特別な目的SIPテレフォニーデバイスは、ファームウェアをアップグレードして、追加機能と機能をサポートできる必要があります。
Req-6: Users SHOULD be able to upgrade the devices with no special applications or equipment; or a service provider SHOULD be able to push the upgrade down to the devices remotely.
REQ-6：ユーザーは、特別なアプリケーションや機器なしでデバイスをアップグレードできる必要があります。または、サービスプロバイダーがアップグレードをリモートでデバイスに押し下げることができるはずです。
Req-7: SIP telephony devices MUST support RFC 3263 [5] for locating a SIP server and selecting a transport protocol.
REQ-7：SIPテレフォニーデバイスは、SIPサーバーを見つけてトランスポートプロトコルを選択するためにRFC 3263 [5]をサポートする必要があります。
Req-8: SIP telephony devices MUST incorporate DNS resolvers that are configurable with at least two entries for DNS servers for redundancy. To provide efficient DNS resolution, SIP telephony devices SHOULD query responsive DNS servers and skip DNS servers that have been non-responsive to recent queries.
REQ-8：SIPテレフォニーデバイスには、冗長性のためにDNSサーバーの少なくとも2つのエントリで構成可能なDNSリゾルバーを組み込む必要があります。効率的なDNS解像度を提供するには、SIPテレフォニーデバイスは、最近のクエリに反応しないレスポンシブDNSサーバーとスキップDNSサーバーを照会する必要があります。
Req-9: To provide efficient DNS resolution and to limit post-dial delay, SIP telephony devices MUST cache DNS responses based on the DNS time-to-live.
REQ-9：効率的なDNS解像度を提供し、ダイヤル後の遅延を制限するには、SIPテレフォニーデバイスはDNSまでの時間に基づいてDNS応答をキャッシュする必要があります。
Req-10: For DNS efficiency, SIP telephony devices SHOULD use the additional information section of the DNS response instead of generating additional DNS queries.
REQ-10：DNS効率の場合、SIPテレフォニーデバイスは、追加のDNSクエリを生成する代わりに、DNS応答の追加情報セクションを使用する必要があります。
Req-11: SIP telephony devices MAY support ENUM [6] in case the end users prefer to have control over the ENUM lookup. Note: The ENUM resolver can also be placed in the outgoing SIP proxy to simplify the operation of the SIP telephony device. The Extension Mechanisms for DNS (EDNSO) in RFC 2671 SHOULD also be supported.
REQ-11：SIPテレフォニーデバイスは、エンドユーザーが列挙のルックアップを制御することを好む場合に備えて、Enum [6]をサポートする場合があります。注：Enum Resolverを発信SIPプロキシに配置して、SIPテレフォニーデバイスの操作を簡素化することもできます。RFC 2671のDNS（EDNSO）の拡張メカニズムもサポートする必要があります。
Req-12: SIP telephony devices MUST support RFC 3261 [2].
REQ-12：SIPテレフォニーデバイスはRFC 3261 [2]をサポートする必要があります。
Req-13: SIP telephony devices SHOULD support the SIP Privacy header by populating headers with values that reflect the privacy requirements and preferences as described in "User Agent Behavior", Section 4 of RFC 3323 [7].
REQ-13：SIPテレフォニーデバイスは、RFC 3323のセクション4で説明されている「ユーザーエージェントの動作」で説明されているプライバシー要件と好みを反映する値をヘッダーに入力することにより、SIPプライバシーヘッダーをサポートする必要があります[7]。
Req-14: SIP telephony devices MUST be able to place an existing call on hold, and initiate or receive another call, as specified in RFC 3264 [8] and SHOULD NOT omit the sendrecv attribute.
REQ-14：SIPテレフォニーデバイスは、RFC 3264 [8]で指定されているように、既存の呼び出しを保留にし、別の呼び出しを開始または受信できる必要があり、SendRecv属性を省略しないでください。
Req-15: SIP telephony devices MUST provide a call waiting indicator. When participating in a call, the user MUST be alerted audibly and/or visually of another incoming call. The user MUST be able to enable/disable the call waiting indicator.
REQ-15：SIPテレフォニーデバイスは、コール待機指標を提供する必要があります。通話に参加する場合、ユーザーは別の着信コールの聴覚的および/または視覚的にアラートする必要があります。ユーザーは、コール待機インジケーターを有効/無効にできる必要があります。
Req-16: SIP telephony devices MUST support SIP message waiting [9] and the integration with message store platforms.
REQ-16：SIPテレフォニーデバイスは、SIPメッセージ待機とメッセージストアプラットフォームとの統合をサポートする必要があります。
Req-17: SIP telephony devices MAY support a local dial plan. If a dial plan is supported, it MUST be able to match the user input to one of multiple pattern strings and transform the input to a URI, including an arbitrary scheme and URI parameters.
REQ-17：SIPテレフォニーデバイスは、ローカルダイヤルプランをサポートする場合があります。ダイヤルプランがサポートされている場合、ユーザー入力を複数のパターン文字列のいずれかに一致させ、任意のスキームやURIパラメーターを含むURIに入力を変換できる必要があります。
Example: If a local dial plan is supported, it SHOULD be configurable to generate any of the following URIs when "5551234" is dialed:
例：ローカルダイヤルプランがサポートされている場合、「5551234」がダイヤルされたときに、次のURIのいずれかを生成することを構成できるはずです。
tel:+12125551234
sip:+12125551234@example.net;user=phone
sips:+12125551234@example.net;user=phone
sip:5551234@example.net
sips:5551234@example.net
tel:5551234;phone-context=nyc1.example.net
sip:5551234;phone-
context=nyc1.example.net@example.net;user=phone
sips:5551234;phone-
context=nyc1.example.net@example.net;user=phone
sip:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sips:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
tel:5551234;phone-context=+1212
sip:5551234;phone-context=+1212@example.net;user=phone
sips:5551234;phone-context=+1212@example.net;user=phone
sip:5551234;phone-context=+1212@example.net;user=dialstring
sips:5551234;phone-context=+1212@example.net;user=dialstring
If a local dial plan is not supported, the device SHOULD be configurable to generate any of the following URIs when "5551234" is dialed:
ローカルダイヤルプランがサポートされていない場合、「5551234」がダイヤルされているときに、次のURIのいずれかを生成するようにデバイスを構成可能にする必要があります。
sip:5551234@example.net
sips:5551234@example.net
sip:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sips:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sip:5551234;phone-context=+1212@example.net;user=dialstring
sips:5551234;phone-context=+1212@example.net;user=dialstring"
Req-18: SIP telephony devices MUST support URIs for telephone numbers as per RFC 3966 [10]. This includes the reception as well as the sending of requests. The reception may be denied according to the configurable security policy of the device. It is a reasonable behavior to send a request to a preconfigured outbound proxy.
REQ-18：SIPテレフォニーデバイスは、RFC 3966 [10]に従って、電話番号のURIをサポートする必要があります。これには、レセプションとリクエストの送信が含まれます。レセプションは、デバイスの構成可能なセキュリティポリシーに従って拒否される場合があります。事前に構成されたアウトバウンドプロキシにリクエストを送信することは合理的な動作です。
Req-19: SIP telephony devices MUST support REFER and NOTIFY for call transfer [11], [12]. SIP telephony devices MUST support escaped Replaces-Header (RFC 3891) and SHOULD support other escaped headers in the Refer-To header.
REQ-19：SIPテレフォニーデバイスは、コール転送[11]、[12]の紹介と通知をサポートする必要があります。SIPテレフォニーデバイスは、Escapedの交換ヘッド（RFC 3891）をサポートする必要があり、参照ヘッダーの他の脱出ヘッダーをサポートする必要があります。
Req-20: SIP telephony devices MUST support the unattended call transfer flows as defined in [12].
REQ-20：SIPテレフォニーデバイスは、[12]で定義されているように、無人のコール転送フローをサポートする必要があります。
Req-21: SIP telephony devices MUST support the attended call transfer as defined in [12].
REQ-21：SIPテレフォニーデバイスは、[12]で定義されているように、通話転送をサポートする必要があります。
Req-22: SIP telephony devices MAY support device-based 3-way calling by mixing the audio streams and displaying the interactive text of at least 2 separate calls.
REQ-22：SIPテレフォニーデバイスは、オーディオストリームを混合し、少なくとも2つの個別の呼び出しのインタラクティブテキストを表示することにより、デバイスベースの3ウェイコールをサポートする場合があります。
Req-23: SIP telephony devices MUST be able to send dual-tone multi-frequency (DTMF) named telephone events as specified by RFC 2833 [13].
REQ-23：SIPテレフォニーデバイスは、RFC 2833 [13]で指定されているように、電話イベントという名前のデュアルトーンマルチ周波数（DTMF）を送信できる必要があります。
Req-24: Payload type negotiation MUST comply with RFC 3264 [8] and with the registered MIME types for RTP payload formats in RFC 3555 [14].
REQ-24：ペイロードタイプの交渉は、RFC 3264 [8]およびRFC 3555 [14]のRTPペイロード形式の登録MIMEタイプに準拠する必要があります。
Req-25: The dynamic payload type MUST remain constant throughout the session. For example, if an endpoint decides to renegotiate codecs or put the call on hold, the payload type for the re-invite MUST be the same as the initial payload type. SIP devices MAY support Flow Identification as defined in RFC 3388 [15].
REQ-25：動的なペイロードタイプは、セッション全体で一定のままでなければなりません。たとえば、エンドポイントがコーデックを再交渉するか、コールを保留することを決定した場合、reinviteのペイロードタイプは初期ペイロードタイプと同じでなければなりません。SIPデバイスは、RFC 3388で定義されているフロー識別をサポートする場合があります[15]。
Req-26: When acting as a User Agent Client (UAC), SIP telephony devices SHOULD support the gateway model of RFC 3960 [16]. When acting as a User Agent Server (UAS), SIP telephony devices SHOULD NOT send early media.
REQ-26：ユーザーエージェントクライアント（UAC）として機能する場合、SIPテレフォニーデバイスはRFC 3960のゲートウェイモデルをサポートする必要があります[16]。ユーザーエージェントサーバー（UAS）として機能する場合、SIPテレフォニーデバイスは早期メディアを送信する必要はありません。
Req-27: SIP telephony devices MUST be able to handle multiple early dialogs in the context of request forking. When a confirmed dialog has been established, it is an acceptable behavior to send a BYE request in response to additional 2xx responses that establish additional confirmed dialogs.
REQ-27：SIPテレフォニーデバイスは、リクエストフォーキングのコンテキストで複数の初期ダイアログを処理できる必要があります。確認されたダイアログが確立された場合、追加の確認されたダイアログを確立する追加の2xx応答に応じて、さようならリクエストを送信することは許容可能な動作です。
Req-28: SIP devices with a suitable display SHOULD support the call-info header and depending on the display capabilities MAY, for example, display an icon or the image of the caller.
REQ-28：適切なディスプレイを備えたSIPデバイスは、コールINFOヘッダーをサポートし、ディスプレイ機能に応じて、たとえば、発信者のアイコンまたは画像を表示する場合があります。
Req-29: To provide additional information about call failures, SIP telephony devices with a suitable display MUST render the "Reason Phrase" of the SIP message or map the "Status Code" to custom or default messages. This presumes the language for the reason phrase is the same as the negotiated language. The devices MAY use an internal "Status Code" table if there was a problem with the language negotiation.
REQ-29：通話障害に関する追加情報を提供するには、適切な表示を備えたSIPテレフォニーデバイスは、SIPメッセージの「理由フレーズ」をレンダリングするか、「ステータスコード」をカスタムまたはデフォルトのメッセージにマッピングする必要があります。これは、理由フレーズの言語が交渉された言語と同じであると仮定します。言語交渉に問題があった場合、デバイスは内部「ステータスコード」テーブルを使用する場合があります。
Req-30: SIP telephony devices MAY support music on hold, both in receive mode and locally generated. See also "SIP Service Examples" for a call flow with music on hold [17].
REQ-30：SIPテレフォニーデバイスは、受信モードとローカルで生成される両方で、保留中の音楽をサポートする場合があります。音楽を保留にしたコールフローについては、「SIPサービスの例」も参照してください[17]。
Req-31: SIP telephony devices MAY ring after a call has been on hold for a predetermined period of time, typically 3 minutes.
REQ-31：SIPテレフォニーデバイスは、コールが所定の期間、通常3分間保留された後に鳴ることがあります。
Req-32: SIP telephony devices MUST support the SIP Basic Call Flow Examples as per RFC 3665 [17].
REQ-32：SIPテレフォニーデバイスは、RFC 3665 [17]に従って、SIP基本コールフローの例をサポートする必要があります。
Req-33: SIP telephony devices MUST support the SIP-PSTN Service Examples as per RFC 3666 [18].
REQ-33：SIPテレフォニーデバイスは、RFC 3666 [18]に従って、SIP-PSTNサービスの例をサポートする必要があります。
Req-34: SIP telephony devices MUST support the Third Party Call Control model [19], in the sense that they may be the controlled device.
REQ-34：SIPテレフォニーデバイスは、制御されたデバイスである可能性があるという意味で、サードパーティコールコントロールモデル[19]をサポートする必要があります。
Req-35: SIP telephony devices SHOULD support SIP call control and multi-party usage [20].
REQ-35：SIPテレフォニーデバイスは、SIPコールコントロールとマルチパーティの使用をサポートする必要があります[20]。
Req-36: SIP telephony devices SHOULD support conferencing services for voice [21], [22] and interactive text [23] and if equipped with an adequate display MAY also support instant messaging (IM) and presence [24], [25].
REQ-36：SIPテレフォニーデバイスは、音声[21]、[22]、およびインタラクティブテキスト[23]の会議サービスをサポートする必要があります。。
Req-37: SIP telephony devices SHOULD support the indication of the User Agent capabilities and MUST support the caller capabilities and preferences as per RFC 3840 [26].
REQ-37：SIPテレフォニーデバイスは、ユーザーエージェント機能の表示をサポートし、RFC 3840 [26]に従って発信者の機能と好みをサポートする必要があります。
Req-38: SIP telephony devices MAY support service mobility: Devices MAY allow roaming users to input their identity so as to have access to their services and preferences from the home SIP server. Examples of user data to be available for roaming users are: user service ID, dialing plan, personal directory, and caller preferences.
REQ-38：SIPテレフォニーデバイスはサービスのモビリティをサポートする場合があります。デバイスは、ホームSIPサーバーからサービスや設定にアクセスできるように、ユーザーが身元を入力できるようにすることができます。ローミングユーザーが利用できるユーザーデータの例は、ユーザーサービスID、ダイヤルプラン、パーソナルディレクトリ、発信者の好みです。
The large color displays in some newer models make such SIP phones and applications attractive for a rich communication environment. This document is focused, however, only on telephony-specific features enabled by SIP Presence and SIP Events.
いくつかの新しいモデルに大きな色が表示されるため、このようなSIP電話とアプリケーションは、豊かなコミュニケーション環境にとって魅力的です。ただし、このドキュメントは、SIPのプレゼンスとSIPイベントによって有効になっているテレフォニー固有の機能にのみ焦点を当てています。
SIP telephony devices can also support presence status, such as the traditional Do Not Disturb, new event state-based information, such as being in another call or being in a conference, typing a message, emoticons, etc. Some SIP telephony User Agents can support, for example, a voice session and several IM sessions with different parties.
SIPテレフォニーデバイスは、従来の邪魔をしないなどの存在状態、別の電話や会議に参加するなどの新しいイベント状態ベースの情報、メッセージの入力、絵文字などをサポートすることもできます。たとえば、音声セッションや、さまざまなパーティーでのいくつかのIMセッションをサポートします。
Req-39: SIP telephony devices SHOULD support Presence information [24] and SHOULD support the Rich Presence Information Data Format [27] for the new IP communication services enabled by Presence.
REQ-39：SIPテレフォニーデバイスは、プレゼンス情報[24]をサポートし、存在によって有効になった新しいIP通信サービスのリッチプレゼンス情報データ形式[27]をサポートする必要があります。
Req-40: Users MUST be able to set the state of the SIP telephony device to "Do Not Disturb", and this MAY be manifested as a Presence state across the network if the UA can support Presence information.
REQ-40：ユーザーは、SIPテレフォニーデバイスの状態を「邪魔しない」ように設定できる必要があります。これは、UAが存在情報をサポートできる場合、ネットワーク全体の存在状態として現れる可能性があります。
Req-41: SIP telephony devices with "Do Not Disturb" enabled MUST respond to new sessions with "486 Busy Here".
REQ-41：「Do Do Duster」を備えたSIPテレフォニーデバイスは、「486 Busy Here」で新しいセッションに応答する必要があります。
Req-42: Emergency calling: For emergency numbers (e.g., 911, SOS URL), SIP telephony devices SHOULD support the work of the ECRIT WG [28].
REQ-42：緊急通話：緊急番号（例：911、SOS URL）の場合、SIPテレフォニーデバイスはECRIT WGの作業をサポートする必要があります[28]。
Req-43: Priority header: SIP devices SHOULD support the setting by the user of the Priority header specified in RFC 3261 for such applications as emergency calls or for selective call acceptance.
REQ-43：優先ヘッダー：SIPデバイスは、緊急コールなどのアプリケーションや選択的コールの受け入れのために、RFC 3261で指定された優先ヘッダーのユーザーによる設定をサポートする必要があります。
Req-44: Resource Priority header: SIP telephony devices that are used in environments that support emergency preparedness MUST also support the sending and receiving of the Resource-Priority header as specified in [29]. The Resource Priority header influences the behavior for message routing in SIP proxies and PSTN telephony gateways and is different from the SIP Priority header specified in RFC 3261. Users of SIP telephony devices may want to be interrupted in their lower-priority communications activities if such an emergency communication request arrives.
REQ-44：リソース優先ヘッダー：緊急時の準備をサポートする環境で使用されるSIPテレフォニーデバイス[29]で指定されているように、リソース優先ヘッダーの送信と受信もサポートする必要があります。リソースの優先度ヘッダーは、SIPプロキシおよびPSTNテレフォニーゲートウェイでのメッセージルーティングの動作に影響を与え、RFC 3261で指定されたSIP優先ヘッダーとは異なります。緊急通信リクエストが届きます。
Note: As of this writing, we recommend that implementers follow the work of the Working Group on Emergency Context Resolution with Internet Technologies (ecrit) in the IETF. The complete solution is for further study at this time. There is also work on the requirements for location conveyance in the SIPPING WG, see [30].
注：この執筆時点では、IETFのインターネットテクノロジー（ECRIT）を使用した緊急コンテキスト解決に関するワーキンググループの作業に従うことをお勧めします。完全な解決策は、現時点でさらなる研究のためです。すすりwgの位置搬送の要件に関する作業もあります[30]を参照してください。
A SIP telephony device can have multiple lines: One SIP telephony device can be registered simultaneously with different SIP registrars from different service providers, using different names and credentials for each line. The different sets of names and credentials are also called 'SIP accounts'. The "line" terminology has been borrowed from multi-line PSTN/PBX phones, except that for SIP telephony devices there can be different SIP registrars/proxies for each line, each of which may belong to a different service provider, whereas this would be an exceptional case for the PSTN and certainly not the case for PBX phones. Multi-line SIP telephony devices resemble more closely e-mail clients that can support several e-mail accounts.
SIPテレフォニーデバイスには複数の行を持つことができます。1つのSIPテレフォニーデバイスは、各ラインの異なる名前と資格情報を使用して、異なるサービスプロバイダーのさまざまなSIPレジストラと同時に登録できます。異なる名前と資格情報のセットは、「SIPアカウント」とも呼ばれます。「ライン」の用語は、SIPテレフォニーデバイスの場合、各ラインに異なるSIPレジストラ/プロキシがあることを除いて、マルチラインPSTN/PBX電話から借用されています。PSTNの例外的なケースであり、確かにPBX電話の場合はそうではありません。マルチラインSIPテレフォニーデバイスは、複数の電子メールアカウントをサポートできるクライアントをより密接に電子メールで囲んでいます。
Note: Each SIP account can usually support different Addresses of Record (AORs) with a different list of contact addresses (CAs), as may be convenient, for example, when having different SIP accounts for business and personal use. However, some of the CAs in different SIP accounts may point to the same devices.
注：各SIPアカウントは通常、ビジネスや個人使用のために異なるSIPアカウントを持っている場合、便利な場合があるように、コンタクトアドレス（CA）の異なるリストを持つ異なるレコード（AOR）をサポートできます。ただし、さまざまなSIPアカウントのCAの一部は、同じデバイスを指す場合があります。
Req-45: Multi-line SIP telephony devices MUST support a unique authentication username, authentication password, registrar, and identity to be provisioned for each line. The authentication username MAY be identical with the user name of the AOR and the domain name MAY be identical with the host name of the registrar.
REQ-45：マルチラインSIPテレフォニーデバイスは、各行にプロビジョニングする一意の認証ユーザー名、認証パスワード、レジストラ、およびIDをサポートする必要があります。認証ユーザー名はAORのユーザー名と同一である場合があり、ドメイン名はレジストラのホスト名と同一である場合があります。
Req-46: Multi-line SIP telephony devices MUST be able to support the state of the client to Do Not Disturb on a per line basis.
REQ-46：マルチラインSIPテレフォニーデバイスは、1行ごとに邪魔しないように、クライアントの状態をサポートできる必要があります。
Req-47: Multi-line SIP telephony devices MUST support multi-line call waiting indicators. Devices MUST allow the call waiting indicator to be set on a per line basis.
REQ-47：マルチラインSIPテレフォニーデバイスは、マルチラインコール待機指標をサポートする必要があります。デバイスは、通話待機インジケーターを1行ごとに設定できるようにする必要があります。
Req-48: Multi-line SIP telephony devices MUST be able to support a few different ring tones for different lines. We specify here "a few", since provisioning different tones for all lines may be difficult for phones with many lines.
REQ-48：マルチラインSIPテレフォニーデバイスは、さまざまなラインに対していくつかの異なるリングトーンをサポートできる必要があります。ここでは「いくつか」を指定します。なぜなら、すべてのラインに異なるトーンをプロビジョニングすることは、多くのラインを持つ電話では難しいかもしれないからです。
The following requirements allow users with a set of credentials to use any SIP telephony device that can support personal credentials from several users, distinct from the identity of the device.
以下の要件により、資格情報のセットを持つユーザーは、デバイスのIDとは異なる複数のユーザーからの個人的な資格情報をサポートできるSIPテレフォニーデバイスを使用できます。
Req-49: User-mobility-enabled SIP telephony devices MUST store static credentials associated with the device in non-volatile memory. This static profile is used during the power up sequence.
REQ-49：ユーザーモビリティ対応のSIPテレフォニーデバイスは、不揮発性メモリにデバイスに関連付けられた静的資格情報を保存する必要があります。この静的プロファイルは、電源アップシーケンス中に使用されます。
Req-50: User-mobility-enabled SIP telephony devices SHOULD allow a user to walk up to a device and input their personal credentials. All user features and settings stored in home SIP proxy and the associated policy server SHOULD be available to the user.
REQ-50：ユーザーモビリティ対応のSIPテレフォニーデバイスでは、ユーザーがデバイスまで歩いて個人的な資格情報を入力できるようにする必要があります。ホームSIPプロキシと関連するポリシーサーバーに保存されているすべてのユーザー機能と設定は、ユーザーが利用できるようにする必要があります。
Req-51: User-mobility-enabled SIP telephony devices registered as fixed desktop with network administrator MUST use the local static location data associated with the device for emergency calls.
REQ-51：ネットワーク管理者との固定デスクトップとして登録されているユーザーモビリティ対応のSIPテレフォニーデバイスは、緊急通話のためにデバイスに関連付けられたローカル静的位置データを使用する必要があります。
SIP telephony devices supporting instant messaging based on SIMPLE [24] support text conversation based on blocks of text. However, continuous interactive text conversation may be sometimes preferred as a parallel to voice, due to its interactive and more streaming-like nature, and thus is more appropriate for real-time conversation. It also allows for text captioning of voice in noisy environments and for those who cannot hear well or cannot hear at all.
単純な[24]テキストのブロックに基づいてテキスト会話をサポートするインスタントメッセージングをサポートするSIPテレフォニーデバイス。ただし、インタラクティブでストリーミングのような性質のために、継続的なインタラクティブなテキスト会話が音声よりも並行して好まれる場合があります。したがって、リアルタイムの会話により適しています。また、騒々しい環境や、よく聞こえない、またはまったく聞くことができない人のために、音声のテキストキャプションが可能になります。
Finally, continuous character-by-character text is preferred by emergency and public safety programs (e.g., 112 and 911) because of its immediacy, efficiency, lack of crossed messages problem, better ability to interact with a confused person, and the additional information that can be observed from watching the message as it is composed.
最後に、その即時性、効率性、交差メッセージの問題の欠如、混乱した人と対話する能力の向上、および追加情報のため、緊急および公共安全プログラム（例えば、112および911など）で継続的なキャラクターテキストが好まれます。それは、それが構成されているときにメッセージを見ることから観察することができます。
Req-52: SIP telephony devices such as SIP display phones and IP-analog adapters SHOULD support the accessibility requirements for deaf, hard-of-hearing and speech-impaired individuals as per RFC 3351 [31] and also for interactive text conversation [23], [32].
REQ-52：SIPディスプレイ電話やIP-AnalogアダプターなどのSIPテレフォニーデバイスは、RFC 3351 [31]およびインタラクティブなテキスト会話に従って、聴覚障害、硬化、音声障害のある個人のアクセシビリティ要件をサポートする必要があります[23]、[32]。
Req-53: SIP telephony devices SHOULD provide a way to input text and to display text through any reasonable method. Built-in user interfaces, standard wired or wireless interfaces, and/or support for text through a web interface are all considered reasonable mechanisms.
REQ-53：SIPテレフォニーデバイスは、テキストを入力し、合理的な方法でテキストを表示する方法を提供する必要があります。組み込みのユーザーインターフェイス、標準有線またはワイヤレスインターフェイス、および/またはWebインターフェイスを介したテキストのサポートはすべて、合理的なメカニズムと見なされます。
Req-54: SIP telephony devices SHOULD provide an external standard wired or wireless link to connect external input (keyboard, mouse) and display devices.
REQ-54：SIPテレフォニーデバイスは、外部標準の有線またはワイヤレスリンクを提供して、外部入力（キーボード、マウス）とディスプレイデバイスを接続する必要があります。
Req-55: SIP telephony devices that include a display, or have a facility for connecting an external display, MUST include protocol support as described in RFC 4103 [23] for real-time interactive text.
REQ-55：ディスプレイを含むSIPテレフォニーデバイス、または外部ディスプレイを接続するための機能があるため、リアルタイムインタラクティブテキストのRFC 4103 [23]に記載されているように、プロトコルサポートを含める必要があります。
Req-56: There may be value in having RFC 4103 support in a terminal also without a visual display. A synthetic voice output for the text conversation may be of value for all who can hear, and thereby provides the opportunity to have a text conversation with other users.
REQ-56：視覚的なディスプレイなしでも、端末にRFC 4103サポートを持っていることには価値があるかもしれません。テキスト会話の合成音声出力は、聞くことができるすべての人にとって価値があるかもしれません。それにより、他のユーザーとテキスト会話をする機会を提供します。
Req-57: SIP telephony devices MAY provide analog adaptor functionality through an RJ-11 FXS port to support FXS devices. If an RJ-11 (FXS) port is provided, then it MAY support a gateway function from all text-telephone protocols according to ITU-T Recommendation V.18 to RFC 4103 text conversation (in fact, this is encouraged in the near term during the transition to widespread use of SIP telephony devices). If this gateway function is not included or fails, the device MUST pass through all text-telephone protocols according to ITU-T Recommendation V.18, November 2000, in a transparent fashion.
REQ-57：SIPテレフォニーデバイスは、FXSデバイスをサポートするために、RJ-11 FXSポートを介してアナログアダプター機能を提供する場合があります。RJ-11（FXS）ポートが提供されている場合、ITU-Tの推奨V.18からRFC 4103テキスト会話に従って、すべてのテキストテレホンプロトコルからのゲートウェイ関数をサポートする場合があります（実際、これは近い期間で奨励されていますSIPテレフォニーデバイスの広範な使用への移行中）。このゲートウェイ関数が含まれていないか失敗しない場合、デバイスは2000年11月のITU-T推奨V.18に従って、すべてのテキストテレフンプロトコルを透明に通過する必要があります。
Req-58: SIP telephony devices MAY provide a 2.5 mm audio port, in portable SIP devices, such as PDAs and various wireless SIP phones.
REQ-58：SIPテレフォニーデバイスは、PDAやさまざまなワイヤレスSIP電話などのポータブルSIPデバイスで、2.5 mmのオーディオポートを提供する場合があります。
Req-59: SIP telephony devices MUST support the Real-Time Protocol and the Real-Time Control Protocol, RFC 3550 [33]. SIP devices SHOULD use RTCP Extended Reports for logging and reporting on network support for voice quality, RFC 3611 [34] and MAY also support the RTCP summary report delivery [35].
REQ-59：SIPテレフォニーデバイスは、リアルタイムプロトコルとリアルタイム制御プロトコル、RFC 3550 [33]をサポートする必要があります。SIPデバイスは、音声品質のネットワークサポートに関するロギングとレポートのためにRTCP拡張レポートを使用する必要があります。RFC3611[34]も、RTCPサマリーレポート配信[35]もサポートする場合があります。
Req-60: SIP telephony devices MUST support digest authentication as per RFC 3261. In addition, SIP telephony devices MUST support Transport Layer Security (TLS) for secure transport [36] for scenarios where the SIP registrar is located outside the secure, private IP network in which the SIP UA may reside. Note: TLS need not be used in every call, though.
REQ-60：SIPテレフォニーデバイスは、RFC 3261に従って消化認証をサポートする必要があります。さらに、SIPテレフォニーデバイスは、SIPレジストラが安全なプライベートIPの外側にあるシナリオの安全なトランスポートのためのトランスポートレイヤーセキュリティ（TLS）をサポートする必要があります[36]SIP UAが存在するネットワーク。注：TLSは、すべての通話で使用する必要はありません。
Req-61: SIP telephony devices MUST be able to password protect configuration information and administrative functions.
REQ-61：SIPテレフォニーデバイスは、構成情報と管理機能をパスワード保護できる必要があります。
Req-62: SIP telephony devices MUST NOT display the password to the user or administrator after it has been entered.
REQ-62：SIPテレフォニーデバイスが入力された後、ユーザーまたは管理者にパスワードを表示してはなりません。
Req-63: SIP clients MUST be able to disable remote access, i.e., block incoming Simple Network Management Protocol (SNMP) (where this is supported), HTTP, and other services not necessary for basic operation.
REQ-63：SIPクライアントは、リモートアクセスを無効にすることができなければなりません。つまり、基本的な動作には必要ない、シンプルなネットワーク管理プロトコル（SNMP）、HTTP、およびその他のサービスをブロックする必要があります。
Req-64: SIP telephony devices MUST support the option to reject an incoming INVITE where the user-portion of the SIP request URI is blank or does not match a provisioned contact. This provides protection against war-dialer attacks, unwanted telemarketing, and spam. The setting to reject MUST be configurable.
REQ-64：SIPテレフォニーデバイスは、SIPリクエストのユーザーポーションが空白であるか、プロビジョニングされた連絡先と一致しない場合、着信招待を拒否するオプションをサポートする必要があります。これにより、ウォーダイヤラー攻撃、不要なテレマーケティング、スパムに対する保護が提供されます。拒否する設定は設定可能でなければなりません。
Req-65: When TLS is not used, SIP telephony devices MUST be able to reject an incoming INVITE when the message does not come from the proxy or proxies where the client is registered. This prevents callers from bypassing terminating call features on the proxy. For DNS SRV specified proxy addresses, the client must accept an INVITE from all of the resolved proxy IP addresses.
REQ-65：TLSを使用しない場合、SIPテレフォニーデバイスは、クライアントが登録されているプロキシまたはプロキシからメッセージが送信されない場合、着信の招待状を拒否できる必要があります。これにより、発信者はプロキシで終了コール機能をバイパスすることを防ぎます。DNS SRV指定されたプロキシアドレスの場合、クライアントは解決されたすべてのプロキシIPアドレスから招待を受け入れる必要があります。
Req-66: SIP devices MUST support the IPv4 Differentiated Services Code Point (DSCP) field for RTP streams as per RFC 2597 [37]. The DSCP setting MUST be configurable to conform with the local network policy.
REQ-66：SIPデバイスは、RFC 2597 [37]に従って、RTPストリームのIPv4差別化サービスコードポイント（DSCP）フィールドをサポートする必要があります。DSCP設定は、ローカルネットワークポリシーに準拠するために構成可能でなければなりません。
Req-67: If not specifically provisioned, SIP telephony devices SHOULD mark RTP packets with the recommended DSCP for expedited forwarding (codepoint 101110) and mark SIP packets with DSCP AF31 (codepoint 011010).
REQ-67：特別にプロビジョニングされていない場合、SIPテレフォニーデバイスは、迅速な転送に推奨されるDSCP（CodePoint 101110）とDSCP AF31（CodePoint 011010）を搭載したマークSIPパケットでRTPパケットをマークする必要があります。
Req-68: SIP telephony devices MAY support Resource Reservation Protocol (RSVP) [38].
REQ-68：SIPテレフォニーデバイスは、リソース予約プロトコル（RSVP）[38]をサポートする場合があります。
Req-69: To simplify the interoperability issues, SIP telephony devices MUST use the first matching codec listed by the receiver if the requested codec is available in the called device. See the offer/answer model in RFC 3261.
REQ-69：相互運用性の問題を簡素化するには、SIPテレフォニーデバイスは、要求されたコーデックが呼び出されたデバイスで利用可能である場合、受信機がリストした最初のマッチングコーデックを使用する必要があります。RFC 3261のオファー/回答モデルを参照してください。
Req-70: To reduce overall bandwidth, SIP telephony devices MAY support active voice detection and comfort noise generation.
REQ-70：全体的な帯域幅を減らすために、SIPテレフォニーデバイスは、アクティブな音声検出と快適なノイズの生成をサポートする場合があります。
Internet telephony devices face the problem of supporting multiple codecs due to various historic reasons, on how telecom industry players have approached codec implementations and the serious intellectual property and licensing problems associated with most codec types. For example, RFC 3551 [39] lists 17 registered MIME subtypes for audio codecs.
インターネットテレフォニーデバイスは、さまざまな歴史的な理由により、複数のコーデックをサポートする問題に直面しています。テレコム業界のプレーヤーがコーデックの実装と、ほとんどのコーデックタイプに関連する深刻な知的財産およびライセンスの問題にどのようにアプローチしたかについてです。たとえば、RFC 3551 [39]には、オーディオコーデックの17の登録されたMIMEサブタイプがリストされています。
Ideally, the more codecs can be supported in a SIP telephony device, the better, since it enhances the chances of success during the codec negotiation at call setup and avoids media intermediaries used for codec mediation.
理想的には、SIPテレフォニーデバイスでより多くのコーデックをサポートできるほど、コールセットアップでのコーデック交渉中の成功の可能性を高め、コーデック調停に使用されるメディア仲介者を回避するため、より良いものです。
Implementers interested in a short list MAY, however, support a minimal number of codecs used in wireline Voice over IP (VoIP), and also codecs found in mobile networks for which the SIP UA is targeted. An ordered short list of preferences may look as follows:
ただし、短いリストに関心のある実装者は、Wireline Voice over IP（VOIP）で使用される最小限のコード科目（SIP UAがターゲットにされているモバイルネットワークにあるコーデック）をサポートする場合があります。順序付けられた短い設定リストは、次のように見える場合があります。
Req-71: SIP telephony devices SHOULD support Audio/Video Transport (AVT) payload type 0 (G.711 uLaw) as in [40] and its Annexes 1 and 2.
REQ-71：SIPテレフォニーデバイスは、[40]およびその付録1および2のように、オーディオ/ビデオトランスポート（AVT）ペイロードタイプ0（G.711 ULAW）をサポートする必要があります。
Req-72: SIP telephony devices SHOULD support the Internet Low Bit Rate codec (iLBC) [41], [42].
REQ-72：SIPテレフォニーデバイスは、インターネットの低ビットレートコーデック（ILBC）[41]、[42]をサポートする必要があります。
Req-73: Mobile SIP telephony devices MAY support codecs found in various wireless mobile networks. This can avoid codec conversion in network-based intermediaries.
REQ-73：モバイルSIPテレフォニーデバイスは、さまざまなワイヤレスモバイルネットワークにあるコーデックをサポートする場合があります。これにより、ネットワークベースの仲介者でのコーデック変換を回避できます。
Req-74: SIP telephony devices MAY support a small set of special purpose codecs, such as G.723.1, where low bandwidth usage is needed (for dial-up Internet access), Speex [43], or G.722 for high-quality audio conferences.
REQ-74：SIPテレフォニーデバイスは、G.723.1などの特別な目的コーデックの小さなセットをサポートする場合があります。ここでは、帯域幅の使用量が低い（ダイヤルアップインターネットアクセスの場合）、SPEEX [43]、またはG.722が必要です。質の高いオーディオ会議。
Req-75: SIP telephony devices MAY support G.729 and its annexes. Note: The G.729 codec is included here for backward compatibility only, since the iLBC and the G.723.1 codecs are preferable in bandwidth-constrained environments.
REQ-75：SIPテレフォニーデバイスは、G.729とその付属書をサポートする場合があります。注：G.729コーデックは、ILBCとG.723.1コーデックが帯域幅に制約された環境で好ましいため、後方互換性のみを補完します。
Note: The authors believe the Internet Low Bit Rate codec (iLBC) should be the default codec for Internet telephony.
注：著者は、インターネットの低ビットレートコーデック（ILBC）がインターネットテレフォニーのデフォルトのコーデックであるべきだと考えています。
A summary count reveals up to 25 and more voice codec types currently in use. The authors believe there is also a need for a single multi-rate Internet codec, such as Speex or similar that can effectively be substituted for all of the multiple legacy G.7xx codec types, such as G.711, G.729, G.723.1, G.722, etc., for various data rates, thus avoiding the complexity and cost to implementers and service providers alike who are burdened by supporting so many codec types, besides the licensing costs.
概要カウントにより、現在使用されている最大25の音声コーデックタイプが明らかになりました。著者は、G.711、G.729、gなどの複数のレガシーG.7xxコーデックタイプのすべてに効果的に置き換えることができるSpeexなどの単一のマルチレートインターネットコーデックも必要であると考えています。.723.1、G.722など、さまざまなデータレートの場合、ライセンスコスト以外に、非常に多くのコーデックタイプをサポートすることで負担をかける実装者とサービスプロバイダーの複雑さとコストを回避します。
Req-76: SIP telephony devices SHOULD comply with the handset receive comfort noise requirements outlined in the ANSI standards [44], [45].
REQ-76：SIPテレフォニーデバイスは、ANSI標準[44]、[45]に概説されている快適なノイズ要件を携帯電話に遵守する必要があります。
Req-77: SIP telephony devices SHOULD comply with the stability or minimum loss defined in ITU-T G.177.
REQ-77：SIPテレフォニーデバイスは、ITU-T G.177で定義されている安定性または最小損失に準拠する必要があります。
Req-78: SIP telephony devices MAY support a full-duplex speakerphone function with echo and side tone cancellation. The design of high-quality side tone cancellation for desktop IP phones, laptop computers, and PDAs is outside the scope of this memo.
REQ-78：SIPテレフォニーデバイスは、エコーとサイドトーンキャンセルを備えた全二重スピーカーフォン機能をサポートする場合があります。デスクトップIP電話、ラップトップコンピューター、PDAの高品質のサイドトーンキャンセルの設計は、このメモの範囲外です。
Req-79: SIP telephony device MAY support different ring tones based on the caller identity.
REQ-79：SIPテレフォニーデバイスは、発信者のアイデンティティに基づいてさまざまなリングトーンをサポートする場合があります。
Req-80: SIP telephony devices SHOULD indicate the preferred language [46] using User Agent capabilities [26].
REQ-80：SIPテレフォニーデバイスは、ユーザーエージェント機能[26]を使用して優先言語[46]を示す必要があります。
Req-81: SIP telephony devices intended to be used in various language settings MUST support other languages for menus, help, and labels.
REQ-81：さまざまな言語設定で使用することを目的としたSIPテレフォニーデバイスは、メニュー、ヘルプ、ラベルの他の言語をサポートする必要があります。
The following requirements apply to functions placed in the SIP telephony device.
以下の要件は、SIPテレフォニーデバイスに配置された関数に適用されます。
Req-82: SIP telephony devices that have a large display and support presence SHOULD display a buddy list [24].
REQ-82：大きなディスプレイとサポートの存在感を備えたSIPテレフォニーデバイスは、バディリストを表示する必要があります[24]。
Req-83: SIP telephony devices MAY support Lightweight Directory Access Protocol (LDAP) for client-based directory lookup.
REQ-83：SIPテレフォニーデバイスは、クライアントベースのディレクトリルックアップのLightweight Directory Access Protocol（LDAP）をサポートする場合があります。
Req-84: SIP telephony devices MAY support a phone setup where a URL is automatically dialed when the phone goes off-hook.
REQ-84：SIPテレフォニーデバイスは、電話がオフフックになったときにURLが自動的にダイヤルされる電話セットアップをサポートする場合があります。
Req-85: SIP telephony devices SHOULD support an internal web server to allow users the option to manually configure the phone and to set up personal phone applications such as the address book, speed-dial, ring tones, and, last but not least, the call handling options for the various lines and aliases, in a user-friendly fashion. Web pages to manage the SIP telephony device SHOULD be supported by the individual device, or MAY be supported in managed networks from centralized web servers linked from a URI.
REQ-85：SIPテレフォニーデバイスは内部Webサーバーをサポートして、ユーザーが電話を手動で構成し、アドレス帳、スピードダイアル、リングトーン、最後になりましたが、最後になりましたが、個人の電話アプリケーションを設定するオプションを可能にする必要があります。ユーザーフレンドリーな方法で、さまざまなラインとエイリアスのコール処理オプション。SIPテレフォニーデバイスを管理するWebページは、個々のデバイスでサポートされるか、URIからリンクされた集中Webサーバーの管理ネットワークでサポートされる場合があります。
Managing SIP telephony devices SHOULD NOT require special client software on the PC or require a dedicated management console. SIP telephony devices SHOULD support https transport for this purpose.
SIPテレフォニーデバイスの管理は、PC上の特別なクライアントソフトウェアを必要としないか、専用の管理コンソールを必要としないはずです。SIPテレフォニーデバイスは、この目的のためにHTTPSトランスポートをサポートする必要があります。
In addition to the Web Based Feature Management requirement, the device MAY have an SNMP interface for monitoring and management purposes.
Webベースの機能管理要件に加えて、デバイスには監視および管理目的のためのSNMPインターフェイスがある場合があります。
The following requirements allow SIP clients to properly function behind various firewall architectures.
以下の要件により、SIPクライアントはさまざまなファイアウォールアーキテクチャの背後で適切に機能することができます。
Req-86: SIP telephony devices SHOULD be able to operate behind a static Network Address Translation/Port Address Translation (NAPT) device. This implies the SIP telephony device SHOULD be able to 1) populate SIP messages with the public, external address of the NAPT device; 2) use symmetric UDP or TCP for signaling; and 3) use symmetric RTP [47].
REQ-86：SIPテレフォニーデバイスは、静的ネットワークアドレスの変換/ポートアドレス変換（NAPT）デバイスの背後で動作できるはずです。これは、SIPテレフォニーデバイスが1）SIPメッセージをNAPTデバイスの公開、外部アドレスに入力できることを意味します。2）シグナル伝達に対称UDPまたはTCPを使用します。3）対称RTP [47]を使用します。
Req-87: SIP telephony devices SHOULD support the Simple Traversal of UDP through NATs (STUN) protocol [48] for determining the NAPT public external address. A classification of scenarios and NATs where STUN is effective is reported in [49]. Detailed call flows for interactive connectivity establishment (ICE) [50] are given in [51].
REQ-87：SIPテレフォニーデバイスは、NAPTパブリック外部アドレスを決定するために、NAT（STUN）プロトコル[48]を介したUDPの単純なトラバーサルをサポートする必要があります。STUNが効果的なシナリオとNATの分類は[49]に報告されています。インタラクティブ接続の確立（ICE）[50]の詳細なコールフローは、[51]に示されています。
Note: Developers are strongly advised to follow the document on best current practices for NAT traversal for SIP [51].
注：開発者は、SIPのNAT Traversalの最良の現在のプラクティスに関する文書に従うことを強くお勧めします[51]。
Req-88: SIP telephony devices MAY support UPnP (http://www.upnp.org/) for local NAPT traversal. Note that UPnP does not help if there is NAPT in the network of the service provider.
REQ-88：SIPテレフォニーデバイスは、ローカルNAPTトラバーサルのUPNP（http://www.upnp.org/）をサポートする場合があります。サービスプロバイダーのネットワークにNAPTがある場合、UPNPは役に立たないことに注意してください。
Req-89: SIP telephony devices MUST be able to limit the ports used for RTP to a provisioned range.
REQ-89：SIPテレフォニーデバイスは、RTPに使用されるポートをプロビジョニング範囲に制限できる必要があります。
Req-90: SIP telephony devices MUST support two types of addressing capabilities, to enable end users to "dial" either phone numbers or URIs.
REQ-90：SIPテレフォニーデバイスは、エンドユーザーが電話番号またはURIのいずれかを「ダイヤル」できるようにするために、2種類のアドレス指定機能をサポートする必要があります。
Req-91: SIP telephony devices MUST have a telephony-like dial-pad and MAY have telephony-style buttons such as mute, redial, transfer, conference, hold, etc. The traditional telephony dial-pad interface MAY appear as an option in large-screen telephony devices using other interface models, such as Push-To-Talk in mobile phones and the Presence and IM graphical user interface (GUI) found in PCs, PDAs, mobile phones, and cordless phones.
REQ-91：SIPテレフォニーデバイスにはテレフォニーのようなダイヤルパッドが必要で、ミュート、リダイヤル、転送、会議、ホールドなどのテレフォニースタイルのボタンが必要です。携帯電話でのプッシュトークや、PC、PDA、携帯電話、コードレス電話に見られる存在感とIMグラフィカルユーザーインターフェイス（GUI）など、他のインターフェイスモデルを使用する大画面テレフォニーデバイス。
Req-92: SIP telephony devices MUST have a convenient way for entering SIP URIs and phone numbers. This includes all alphanumeric characters allowed in legal SIP URIs. Possible approaches include using a web page, display and keyboard entry, type-ahead, or graffiti for PDAs.
REQ-92：SIPテレフォニーデバイスには、SIP URIと電話番号を入力するための便利な方法が必要です。これには、合法的なSIP URIで許可されているすべての英数字キャラクターが含まれます。可能なアプローチには、Webページ、ディスプレイとキーボードエントリ、タイプアヘッド、またはPDAのグラフィティの使用が含まれます。
Req-93: SIP telephony devices should allow phone number entry in human-friendly fashion, with the usual separators and brackets between digits and digit groups.
REQ-93：SIPテレフォニーデバイスは、数字と数字グループの間の通常のセパレーターとブラケットを使用して、人間に優しい方法で電話番号を入力できるようにする必要があります。
SIP telephony devices are quite complex, and their configuration is made more difficult by the widely diverse use of technical terms for the settings. We present here a glossary of the most common settings and some of the more widely used values for some settings.
SIPテレフォニーデバイスは非常に複雑であり、設定の技術用語を大きく多様な使用により使用することにより、構成がより困難になります。ここでは、最も一般的な設定の用語集と、一部の設定でより広く使用されている値のいくつかを提示します。
Settings are the information on a SIP UA that it needs so as to be a functional SIP endpoint. The settings defined in this document are not intended to be a complete listing of all possible settings. It MUST be possible to add vendor-specific settings.
設定は、機能的なSIPエンドポイントになるために必要なSIP UAの情報です。このドキュメントで定義されている設定は、すべての可能な設定の完全なリストであることを意図したものではありません。ベンダー固有の設定を追加することは可能である必要があります。
The list of available settings includes settings that MUST, SHOULD, or MAY be used by all devices (when present) and that make up the common denominator that is used and understood by all devices. However, the list is open to vendor-specific extensions that support additional settings, which enable a rich and valuable set of features.
利用可能な設定のリストには、すべてのデバイス（存在する場合）が使用する必要がある、必要、または使用する必要がある、または使用する必要があり、すべてのデバイスで使用および理解される共通分母を構成する設定が含まれます。ただし、このリストは、追加の設定をサポートするベンダー固有の拡張機能に開放されており、リッチで価値のある機能セットを可能にします。
Settings MAY be read-only on the device. This avoids the misconfiguration of important settings by inexperienced users generating service cost for operators. The settings provisioning process SHOULD indicate which settings can be changed by the end user and which settings should be protected.
設定は、デバイスで読み取り専用です。これにより、オペレーターのサービスコストを生成する経験の浅いユーザーによる重要な設定の誤解が回避されます。設定のプロビジョニングプロセスでは、エンドユーザーがどの設定を変更できるか、どの設定を保護するかを示す必要があります。
In order to achieve wide adoption of any settings format, it is important that it should not be excessive in size for modest devices to use it. Any format SHOULD be structured enough to allow flexible extensions to it by vendors. Settings may belong to the device or to a SIP service provider and the Address of Record (AOR) registered there. When the device acts in the context of an AOR, it will first try to look up a setting in the AOR context. If the setting cannot be found in that context, the device will try to find the setting in the device context. If that also fails, the device MAY use a default value for the setting.
あらゆる設定形式の幅広い採用を達成するためには、控えめなデバイスがそれを使用するためのサイズが過度にないようにすることが重要です。任意のフォーマットは、ベンダーが柔軟な拡張機能を許可するのに十分な構造化する必要があります。設定は、デバイスまたはSIPサービスプロバイダーとそこに登録されているレコードの住所（AOR）に属する場合があります。デバイスがAORのコンテキストで動作する場合、最初にAORコンテキストで設定を検索しようとします。そのコンテキストで設定が見つからない場合、デバイスはデバイスのコンテキストで設定を見つけようとします。それも失敗した場合、デバイスは設定にデフォルト値を使用する場合があります。
The examples shown here are just of informational nature. Other documents may specify the syntax and semantics for the respective settings.
ここに示す例は、単なる情報性の性質です。他のドキュメントは、それぞれの設定の構文とセマンティクスを指定する場合があります。
A device setting MAY include some unique identifier for the device it represents. This MAY be an arbitrary device name chosen by the user, the MAC address, some manufacturer serial number, or some other unique piece of data. The Device ID SHOULD also indicate the ID type. Example: DeviceId="000413100A10;type=MAC"
デバイス設定には、それが表すデバイスの一意の識別子が含まれる場合があります。これは、ユーザー、MACアドレス、一部のメーカーのシリアル番号、またはその他の一意のデータによって選択された任意のデバイス名です。デバイスIDは、IDタイプも示す必要があります。例：deviceId = "000413100A10; type = mac"
The port that will be used for a specific transport protocol for SIP MAY be indicated with the SIP ports setting. If this setting is omitted, the device MAY choose any port within a range as specified in 3.3. For UDP, the port may also be used for sending requests so that NAT devices will be able to route the responses back to the UA. Example: SIPPort="5060;transport=UDP"
SIP用の特定の輸送プロトコルに使用されるポートは、SIPポート設定で示される場合があります。この設定が省略されている場合、デバイスは3.3で指定されている範囲内のポートを選択できます。UDPの場合、ポートはリクエストを送信するために使用される場合があり、NATデバイスがResponseをUAに戻すことができるようにします。例：Sipport = "5060; Transport = UDP"
A range of port numbers MUST be used by a device for the consecutive pairs of ports that MUST be used to receive audio and control information (RTP and RTCP) for each concurrent connection. Sometimes this is required to support firewall traversal, and it helps network operators to identify voice packets. Example: RTPPorts="50000-51000"
同時接続ごとにオーディオおよび制御情報（RTPおよびRTCP）を受信するために使用する必要があるポートの連続したペアのデバイスでは、さまざまなポート番号を使用する必要があります。これは、ファイアウォールトラバーサルをサポートするために必要である場合があり、ネットワークオペレーターが音声パケットを識別するのに役立ちます。例：rtpports = "50000-51000"
The Quality of Service (QoS) settings for outbound packets SHOULD be configurable for network packets associated with call signaling (SIP) and media transport (RTP/RTCP). These settings help network operators in identifying voice packets in their network and allow them to transport them with the required QoS. The settings are independently configurable for the different transport layers and signaling, media, or administration. The QoS settings SHOULD also include the QoS mechanism.
アウトバウンドパケットのサービス品質（QOS）設定は、コールシグナル伝達（SIP）およびメディアトランスポート（RTP/RTCP）に関連付けられたネットワークパケットに設定可能である必要があります。これらの設定は、ネットワークオペレーターがネットワーク内の音声パケットを識別し、必要なQOでそれらを輸送できるようにするのに役立ちます。設定は、異なる輸送層と信号、メディア、または管理に対して独立して構成可能です。QoS設定には、QoSメカニズムも含める必要があります。
For both categories of network traffic, the device SHOULD permit
configuration of the type of service settings for both layer 3 (IP
DiffServ) and layer 2 (for example, IEEE 802.1D/Q) of the network
protocol stack.
Example: RTPQoS="0xA0;type=DiffSrv,5;type=802.1DQ;vlan=324"
All of the call handling settings defined below can be defined here as default behaviors.
以下に定義されているすべての通話処理設定は、ここでデフォルトの動作として定義できます。
The outbound proxy for a device MAY be set. The setting MAY require that all signaling packets MUST be sent to the outbound proxy or that only in the case when no route has been received the outbound proxy MUST be used. This ensures that application layer gateways are in the signaling path. The second requirement allows the optimization of the routing by the outbound proxy. Example: OutboundProxy="sip:nat.proxy.com"
デバイスのアウトバウンドプロキシが設定される場合があります。設定では、すべての信号パケットをアウトバウンドプロキシに送信する必要がある場合、またはルートが受信されていない場合にのみ、アウトバウンドプロキシを使用する必要がある場合があります。これにより、アプリケーションレイヤーゲートウェイが信号パスにあることが保証されます。2番目の要件により、アウトバウンドプロキシによるルーティングの最適化が可能になります。例：outboundProxy = "SIP：nat.proxy.com"
The default outbound proxy SHOULD be a global setting (not related to a specific line). Example: DefaultProxy="sip:123@proxy.com"
デフォルトのアウトバウンドプロキシは、グローバルな設定である必要があります（特定の行とは関係ありません）。例：defaultProxy = "SIP：123@proxy.com"
The re-invite timer allows User Agents to detect broken sessions caused by network failures. A value indicating the number of seconds for the next re-invite SHOULD be used if provided. Example: SessionTimer="600;unit=seconds"
Re Inviteタイマーにより、ユーザーエージェントはネットワークの障害によって引き起こされる壊れたセッションを検出できます。次の再インバイトの秒数を示す値を提供する場合は、使用する必要があります。例：sessiontimer = "600; unit =秒"
As most telephone users are used to dialing digits to indicate the address of the destination, there is a need for specifying the rule by which digits are transformed into a URI (usually SIP URI or TEL URI).
ほとんどの電話ユーザーは、宛先のアドレスを示すために数字のダイヤルに使用されるため、数字がURI（通常はURIまたはTel URI）に変換されるルールを指定する必要があります。
SIP phones need to understand entries in the phone book of the most common separators used between dialed digits, such as spaces, angle and round brackets, dashes, and dots. Example: A phonebook entry of "+49(30)398.33-401" should be translated into "+493039833401".
SIP電話は、スペース、角度、丸いブラケット、ダッシュ、ドットなど、ダイヤルされた数字間で使用される最も一般的なセパレーターの電話帳のエントリを理解する必要があります。例：「49（30）398.33-401」の電話帳エントリは、「493039833401」に翻訳する必要があります。
A SIP UA needs to translate user input before it can generate a valid request. Digit maps are settings that describe the parameters of this process. If present, digit maps define patterns that when matched define the following:
SIP UAは、有効なリクエストを生成する前に、ユーザー入力を翻訳する必要があります。数字マップは、このプロセスのパラメーターを説明する設定です。存在する場合、数字マップは、一致するときに次のように定義するパターンを定義します。
1) A rule by which the endpoint can judge that the user has completed dialing, and 2) A rule to construct a URI from the dialed digits, and optionally 3) An outbound proxy to be used in routing the SIP INVITE.
1) エンドポイントは、ユーザーがダイヤルを完了したこと、および2）ダイヤルされた数字からURIを構築するルール、およびオプションで3）SIP招待状のルーティングに使用するアウトバウンドプロキシを判断できるルール。
A critical timer MAY be provided that determines how long the device SHOULD wait before dialing if a dial plan contains a T (Timer) character. It MAY also provide a timer for the maximum elapsed time that SHOULD pass before dialing if the digits entered by the user match no dial plan. If the UA has a Dial or OK key, pressing this key will override the timer setting.
ダイヤルプランにT（タイマー）文字が含まれている場合、ダイヤルする前にデバイスが待機する時間を決定する重要なタイマーが提供される場合があります。また、ユーザーが入力した数字がダイヤルプランを一致させた場合にダイヤルする前に通過する最大経過時間のタイマーを提供する場合があります。UAにダイヤルまたはOKキーがある場合、このキーを押すとタイマー設定がオーバーライドされます。
SIP telephony devices SHOULD have a Dial/OK key. After sending a request, the UA SHOULD be prepared to receive a 484 Address Incomplete response. In this case, the UA should accept more user input and try again to dial the number.
SIPテレフォニーデバイスには、ダイヤル/OKキーが必要です。リクエストを送信した後、UAは484アドレスの不完全な応答を受信する準備をする必要があります。この場合、UAはより多くのユーザー入力を受け入れ、再試行して番号をダイヤルする必要があります。
An example digit map could use regular expressions like in DNS NAPTR (RFC 2915) to translate user input into a SIP URL. Additional replacement patterns like "d" could insert the domain name of the used AOR. Additional parameters could be inserted in the flags portion of the substitution expression. A list of those patterns would make up the dial plan:
数字マップの例では、DNS NAPTR（RFC 2915）のような正規式を使用して、ユーザー入力をSIP URLに変換できます。「D」のような追加の交換パターンは、使用されているAORのドメイン名を挿入できます。追加のパラメーターを、置換式のフラグ部分に挿入できます。これらのパターンのリストは、ダイヤルプランを構成します。
|^([0-9]*)#$|sip:\1@\d;user=phone|outbound=proxy.com
|^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|sip:\1|
|^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+)$|sip:\1@\d|
|^(.*)$|sip:\1@\d|timeout=5
The SIP telephony device SHOULD support the configuration of a default digit map. If the SIP telephony device does not support digit maps, it SHOULD at least support a default digit map rule to construct a URI from digits. If the endpoint does support digit maps, this rule applies if none of the digit maps match.
SIPテレフォニーデバイスは、デフォルトの数字マップの構成をサポートする必要があります。SIPテレフォニーデバイスが数字マップをサポートしていない場合、少なくともデフォルトの数字マップルールをサポートして、桁からURIを構築する必要があります。エンドポイントが数字マップをサポートしている場合、このルールは、桁マップが一致しない場合に適用されます。
For example, when a user enters "12345", the UA might send the request to "sip:12345@proxy.com;user=phone" after the user presses the OK key.
たとえば、ユーザーが「12345」を入力すると、UAはユーザーがOKキーを押した後、「sip：12345@proxy.com; user =電話」にリクエストを送信する可能性があります。
The parameters for SIP (like timer T1) and other related settings MAY be indicated. An example of usage would be the reduction of the DNS SRV failover time. Example: SIPTimer="t1=100;unit=ms"
SIP（タイマーT1など）およびその他の関連設定のパラメーターが示される場合があります。使用の例は、DNS SRVフェールオーバー時間の短縮です。例：siptimer = "t1 = 100; unit = ms"
Note: The timer settings can be included in the digit map.
注：タイマー設定は、桁マップに含めることができます。
In some cases, operators want to control which codecs may be used in their network. The desired subset of codecs supported by the device SHOULD be configurable along with the order of preference. Service providers SHOULD have the possibility of plugging in their own codecs of choice. The codec settings MAY include the packet length and other parameters like silence suppression or comfort noise generation.
場合によっては、オペレーターはネットワークで使用できるコーデックを制御したいと考えています。デバイスでサポートされているコーデックの目的のサブセットは、優先順位とともに構成可能である必要があります。サービスプロバイダーは、自分の選択したコーデックに接続する可能性があるはずです。コーデックの設定には、パケットの長さや、沈黙抑制や快適なノイズの生成などのその他のパラメーターが含まれる場合があります。
The set of available codecs will be used in the codec negotiation
according to RFC 3264.
Example: Codecs="speex/8000;ptime=20;cng=on,gsm;ptime=30"
The settings MUST include hints about privacy for audio using Secure Realtime Transport Protocol (SRTP) that either mandate or encourage the usage of secure RTP. Example: SRTP="mandatory"
設定には、Secure RTPの使用を義務付けるか奨励するSecure Realime Transport Protocol（SRTP）を使用したオーディオのプライバシーに関するヒントを含める必要があります。例：srtp = "必須"
Keyboard interaction can be indicated with in-band tones or preferably with out-of-band RTP packets (RFC 2833 [13]). The method for sending these events SHOULD be configurable with the order of precedence. Settings MAY include additional parameters like the content-type that should be used. Example: DTMFMethod="INFO;type=application/dtmf, RFC2833".
キーボードの相互作用は、バンド内のトーン、またはできれば帯域外のRTPパケットで示されることができます（RFC 2833 [13]）。これらのイベントを送信する方法は、優先順位で構成可能である必要があります。設定には、使用するコンテンツタイプのような追加のパラメーターが含まれる場合があります。例：dtmfmethod = "info; type = application/dtmf、rfc2833"。
Certain settings are dependent upon the regional location for the daylight saving time rules and for the time zone.
特定の設定は、夏時間の時間規則とタイムゾーンの地域の場所に依存します。
Time Zone and UTC Offset: A time zone MAY be specified for the user. Where one is specified; it SHOULD use the schema used by the Olson Time One database [52].
タイムゾーンとUTCオフセット：ユーザーにタイムゾーンが指定される場合があります。1つが指定されている場合。Olson Time Oneデータベース[52]で使用されるスキーマを使用する必要があります。
Examples of the database naming scheme are Asia/Dubai or America/Los Angeles where the first part of the name is the continent or ocean and the second part is normally the largest city in that time zone. Optional parameters like the UTC offset may provide additional information for UAs that are not able to map the time zone information to a internal database. Example: TimeZone="Asia/Dubai;offset=7200"
データベース命名スキームの例は、アジア/ドバイまたはアメリカ/ロサンゼルスです。名前の最初の部分は大陸または海洋であり、2番目の部分は通常、そのタイムゾーンで最大の都市です。UTCオフセットのようなオプションパラメーターは、タイムゾーン情報を内部データベースにマッピングできないUASの追加情報を提供する場合があります。例：timezone = "asia/dubai; offset = 7200"
A time server SHOULD be used. DHCP is the preferred way to provide this setting. Optional parameters may indicate the protocol that SHOULD be used for determining the time. If present, the DHCP time server setting has higher precedence than the time server setting. Example: TimeServer="12.34.5.2;protocol=NTP"
タイムサーバーを使用する必要があります。DHCPは、この設定を提供するための好ましい方法です。オプションのパラメーターは、時間を決定するために使用する必要があるプロトコルを示す場合があります。存在する場合、DHCPタイムサーバーの設定は、タイムサーバー設定よりも優先されます。例：TimesServer = "12.34.5.2; Protocol = ntp"
Setting the correct language is important for simple installation around the globe.
正しい言語を設定することは、世界中に簡単なインストールに重要です。
A language setting SHOULD be specified for the whole device. Where it is specified, it MUST use the codes defined in RFC 3066 to provide some predictability. Example: Language="de"
デバイス全体に言語設定を指定する必要があります。指定されている場合、RFC 3066で定義されているコードを使用して、ある程度の予測可能性を提供する必要があります。例：言語= "de"
It is recommended to set the language as writable, so that the user MAY change this. This setting SHOULD NOT be AOR related.
ユーザーがこれを変更できるように、言語を書くことができるように設定することをお勧めします。この設定はAOR関連ではありません。
A SIP UA MUST be able to parse and accept requests containing international characters encoded as UTF-8 even if it cannot display those characters in the user interface.
SIP UAは、ユーザーインターフェイスにそれらの文字を表示できなくても、UTF-8としてエンコードされた国際文字を含むリクエストを解析して受け入れることができなければなりません。
SIP allows a device to limit incoming signaling to those made by a predefined set of authorized users from a list and/or with valid passwords. Note that the inbound proxy from most service providers may also support the screening of incoming calls, but in some cases users may want to have control in the SIP telephony device for the screening.
SIPを使用すると、デバイスは、リストからの事前定義された認定ユーザーセットによって作成されたセットおよび/または有効なパスワードを使用して、デバイスを制限することができます。ほとんどのサービスプロバイダーからのインバウンドプロキシは、着信コールのスクリーニングもサポートする可能性がありますが、場合によっては、ユーザーがSIPテレフォニーデバイスでスクリーニングを制御することをお勧めします。
A device SHOULD support the setting as to whether authentication (on
the device) is required and what type of authentication is required.
Example: InboundAuthentication="digest;pattern=*"
If inbound authentication is enabled, then a list of allowed users and credentials to call this device MAY be used by the device. The credentials MAY contain the same data as the credentials for an AOR (i.e., URL, user, password digest, and domain). This applies to SIP control signaling as well as call initiation.
インバウンド認証が有効になっている場合、このデバイスを呼び出す許可ユーザーと資格情報のリストをデバイスで使用できます。資格情報には、AORの資格情報と同じデータが含まれている場合があります（つまり、URL、ユーザー、パスワードダイジェスト、およびドメイン）。これは、SIPコントロールシグナリングとコール開始に適用されます。
Various voice message settings require the use of URIs for the service context as specified in RFC 3087 [53].
さまざまな音声メッセージ設定では、RFC 3087で指定されているように、サービスコンテキストにURIを使用する必要があります[53]。
The message waiting indicator (MWI) address setting controls where the client SHOULD SUBSCRIBE to a voice message server and what MWI summaries MAY be displayed [9]. Example: MWISubscribe="sip:mailbox01@media.proxy.com" User Agents SHOULD accept MWI information carried by SIP MESSAGE without prior subscription. This way the setup of voice message settings can be avoided.
メッセージ待機インジケーター（MWI）は、クライアントが音声メッセージサーバーにサブスクライブする場所と、MWIの要約を表示する場所をコントロールします[9]。例：mwisubscribe = "sip：mailbox01@media.proxy.com"ユーザーエージェントは、事前のサブスクリプションなしでSIPメッセージで運ばれるMWI情報を受け入れる必要があります。これにより、音声メッセージ設定のセットアップを回避できます。
The UA SHOULD have a phonebook and keep a history of recent calls. The phonebook SHOULD save the information in permanent memory that keeps the information even after restarting the device or save the information in an external database that permanently stores the information.
UAには電話帳があり、最近の電話の歴史を保持する必要があります。電話帳は、デバイスを再起動した後でも情報を保持する永久メモリに情報を保存するか、情報を永久に保存する外部データベースに情報を保存する必要があります。
A device MAY specify the user that is currently registered on the device. This SHOULD be an address-of-record URL specified in an AOR definition.
デバイスは、現在デバイスに登録されているユーザーを指定できます。これは、AOR定義で指定された録音アドレスURLである必要があります。
The purpose of specifying which user is currently assigned to this device is to provide the device with the identity of the user whose settings are defined in the user section. This is primarily interesting with regards to user roaming. Devices MAY allow users to sign on to them and then request that their particular settings be retrieved. Likewise, a user MAY stop using a device and want to disable their AOR while not present. For the device to understand what to do, it MUST have some way of identifying users and knowing which user is currently using it. By separating the user and device properties, it becomes clear what the user wishes to enable or to disable. Providing an identifier in the configuration for the user gives an explicit handle for the user. For this to work, the device MUST have some way of identifying users and knowing which user is currently assigned to it.
現在このデバイスにどのユーザーが割り当てられているかを指定する目的は、ユーザーセクションで設定が定義されているユーザーのIDをデバイスに提供することです。これは、ユーザーのローミングに関して主に興味深いものです。デバイスでは、ユーザーがサインオンしてから、特定の設定を取得するように要求する場合があります。同様に、ユーザーはデバイスの使用を停止し、存在していない間にAORを無効にしたい場合があります。デバイスが何をすべきかを理解するには、ユーザーを識別し、どのユーザーが現在使用しているかを知る方法が必要です。ユーザーとデバイスのプロパティを分離することにより、ユーザーが何を有効にしたいか、または無効にしたいかが明らかになります。ユーザーの構成内の識別子を提供すると、ユーザーに明示的なハンドルが与えられます。これが機能するためには、デバイスにはユーザーが現在割り当てられているユーザーを識別する何らかの方法が必要です。
One possible scenario for roaming is an agent who has definitions for several AORs (e.g., one or more personal AORs and one for each executive for whom the administrator takes calls) that they are registered for. If the agent goes to the copy room, they would sign on to a device in that room and their user settings including their AOR would roam with them.
ローミングの可能なシナリオの1つは、登録されているいくつかのAOR（たとえば、1つ以上の個人AOR、および管理者が電話をかける各エグゼクティブに対して1つ以上の定義を持つエージェントです。エージェントがコピールームに行くと、彼らはその部屋のデバイスにサインオンし、AORを含むユーザーの設定は彼らと一緒に歩き回ります。
The alternative to this is to require the agent to individually configure each of the AORs (this would be particularly irksome using standard telephone button entry).
これに代わるものは、エージェントが各AORを個別に構成するように要求することです（これは、標準の電話ボタンエントリを使用して特に厄介です）。
The management of user profiles, aggregation of user or device AOR, and profile information from multiple management sources are configuration server concerns that are out of the scope of this document. However, the ability to uniquely identify the device and user within the configuration data enables easier server-based as well as local (i.e., on the device) configuration management of the configuration data.
ユーザープロファイルの管理、ユーザーまたはデバイスAORの集約、および複数の管理ソースからのプロファイル情報は、このドキュメントの範囲外の構成サーバーの懸念です。ただし、構成データ内でデバイスとユーザーをユニークに識別する機能により、構成データのローカル（デバイス上の）構成管理を容易にすることができます。
SIP telephony devices MUST use the AOR-related settings, as specified here.
SIPテレフォニーデバイスは、ここで指定されているように、AOR関連の設定を使用する必要があります。
There are many properties which MAY be associated with or SHOULD be applied to the AOR or signaling addressed to or from the AOR. AORs MAY be defined for a device or a user of the device. At least one AOR MUST be defined in the settings; this MAY pertain to either the device itself or the user. Example: AOR="sip:12345@proxy.com"
AORに関連付けられている、またはAORにアドレス指定されたAORまたはシグナル伝達に適用される可能性のある多くのプロパティがあります。AORは、デバイスまたはデバイスのユーザーに対して定義できます。少なくとも1つのAORを設定で定義する必要があります。これは、デバイス自体またはユーザーのいずれかに関係する場合があります。例：aor = "sip：12345@proxy.com"
It MUST be possible to specify at least one set of domain, user name, and authentication credentials for each AOR. The user name and authentication credentials are used for authentication challenges.
各AORのドメイン、ユーザー名、および認証資格情報の少なくとも1つのセットを指定することが可能である必要があります。ユーザー名と認証資格情報は、認証の課題に使用されます。
A setting defining the maximum number of simultaneous connections that a device can support MUST be used by the device. The endpoint might have some maximum limit, most likely determined by the media handling capability. The number of simultaneous connections may be also limited by the access bandwidth, such as of DSL, cable, and wireless users. Other optional settings MAY include the enabling or disabling of call waiting indication.
デバイスがサポートできる同時接続の最大数を定義する設定をデバイスで使用する必要があります。エンドポイントには、メディア処理機能によって決定される可能性が最も高い最大制限がある場合があります。同時接続の数は、DSL、ケーブル、ワイヤレスユーザーなどのアクセス帯域幅によっても制限される場合があります。その他のオプションの設定には、コール待合の表示の有効化または無効化が含まれる場合があります。
A SIP telephony device MAY support at least two connections for three-way conference calls that are locally hosted. Example: MaximumConnections="2;cwi=false;bw=128".
SIPテレフォニーデバイスは、ローカルでホストされている3方向電話会議の少なくとも2つの接続をサポートできます。例：MaximumConnections = "2; cwi = false; bw = 128"。
See the recent work on connection reuse [54] and the guidelines for connection-oriented transport for SIP [55].
接続再利用に関する最近の研究[54]と、SIPの接続指向輸送のガイドライン[55]を参照してください。
Automatic SIP telephony device configuration SHOULD use the processes and requirements described in [56]. The user name or the realm in the domain name SHOULD be used by the configuration server to automatically configure the device for individual- or group-specific settings, without any configuration by the user. Image and service data upgrades SHOULD also not require any settings by the user.
自動SIPテレフォニーデバイスの構成は、[56]で説明されているプロセスと要件を使用する必要があります。ユーザー名またはドメイン名のレルムを構成サーバーで使用して、ユーザーによる構成なしで、個別またはグループ固有の設定用にデバイスを自動的に構成する必要があります。画像とサービスのデータのアップグレードも、ユーザーによる設定を必要としないはずです。
The device configuration usually contains sensitive information that MUST be protected. Examples include authentication information, private address books, and call history entries. Because of this, it is RECOMMENDED to use an encrypted transport mechanism for configuration data. Where devices use HTTP, this could be TLS.
デバイス構成には、通常、保護する必要がある機密情報が含まれています。例には、認証情報、プライベートアドレス帳、履歴エントリが含まれます。このため、構成データに暗号化されたトランスポートメカニズムを使用することをお勧めします。デバイスがHTTPを使用する場合、これはTLSである可能性があります。
For devices which use FTP or TFTP for content delivery this can be achieved using symmetric key encryption.
コンテンツ配信にFTPまたはTFTPを使用するデバイスの場合、これは対称キー暗号化を使用して実現できます。
Access to retrieving configuration information is also an important issue. A configuration server SHOULD challenge a subscriber before sending configuration information.
構成情報の取得へのアクセスも重要な問題です。構成サーバーは、構成情報を送信する前にサブスクライバーに挑戦する必要があります。
The configuration server SHOULD NOT include passwords through the automatic configuration process. Users SHOULD enter the passwords locally.
構成サーバーは、自動構成プロセスを介してパスワードを含めるべきではありません。ユーザーはローカルにパスワードを入力する必要があります。
While Section 2.11 states the minimal security requirements and NAT/firewall traversal that have to be met respectively by SIP telephony devices, developers and network managers have to be aware of the larger context of security for IP telephony, especially for those scenarios where security may reside in other parts of SIP-enabled networks.
セクション2.11では、SIPテレフォニーデバイスによってそれぞれ満たさなければならない最小限のセキュリティ要件とNAT/ファイアウォールトラバーサルを述べていますが、開発者とネットワークマネージャーは、特にセキュリティが存在するシナリオの場合、IPテレフォニーのセキュリティのより大きなコンテキストに注意する必要があります。SIP対応ネットワークの他の部分。
Users of SIP telephony devices are exposed to many threats [57] that include but are not limited to fake identity of callers, telemarketing, spam in IM, hijacking of calls, eavesdropping, and learning of private information such as the personal phone directory, user accounts and passwords, and the personal calling history. Various denial of service (DoS) attacks are possible, such as hanging up on other people's conversations or contributing to DoS attacks of others.
SIPテレフォニーデバイスのユーザーは、発信者の偽のアイデンティティ、テレマーケティング、IMのスパム、コールのハイジャック、盗聴、個人情報のディレクトリなどの個人情報の学習を含むがこれらに限定されない多くの脅威[57]にさらされています。アカウントとパスワード、および個人的な呼び出し履歴。さまざまなサービス拒否（DOS）攻撃が可能です。たとえば、他の人の会話にぶら下がったり、他の人のDOS攻撃に貢献したりします。
Service providers are also exposed to many types of attacks that include but are not limited to theft of service by users with fake identities, DoS attacks, and the liabilities due to theft of private customer data and eavesdropping in which poorly secured SIP telephony devices or especially intermediaries such as stateful back-to-back user agents with media (B2BUA) may be implicated.
サービスプロバイダーは、偽のアイデンティティ、DOS攻撃、およびプライベートな顧客データの盗難や盗聴による責任を持つユーザーによるサービスの盗難を含むがこれらに限定されない多くのタイプの攻撃にもさらされています。メディア（B2BUA）を持つステートフルな連続したユーザーエージェントなどの仲介者が関係する可能性があります。
SIP security is a hard problem for several reasons:
SIPセキュリティは、いくつかの理由で難しい問題です。
o Peers can communicate across domains without any pre-arranged trust relationship. o There may be many intermediaries in the signaling path. o Multiple endpoints can be involved in such telephony operations as forwarding, forking, transfer, or conferencing. o There are seemingly conflicting service requirements when supporting anonymity, legal intercept, call trace, and privacy. o Complications arise from the need to traverse NATs and firewalls.
o ピアは、事前に配置された信頼関係なしでドメイン間で通信することができます。o信号経路には多くの仲介者がいるかもしれません。o複数のエンドポイントが、転送、フォーキング、転送、または会議などのテレフォニー操作に関与する可能性があります。o匿名性、法的傍受、コールトレース、プライバシーをサポートする際には、矛盾するサービス要件があります。o合併症は、NATとファイアウォールを横断する必要性から生じます。
There are a large number of deployment scenarios in enterprise networks, using residential networks and employees using Virtual Private Network (VPN) access to the corporate network when working from home or while traveling. There are different security scenarios for each. The security expectations are also very different, say, within an enterprise network or when using a laptop in a public wireless hotspot, and it is beyond the scope of this memo to describe all possible scenarios in detail.
エンタープライズネットワークには、住宅ネットワークと従業員を使用して、自宅で作業中または旅行中にコーポレートネットワークにアクセスできるように使用して、多数の展開シナリオがあります。それぞれに異なるセキュリティシナリオがあります。また、セキュリティの期待は、たとえば、エンタープライズネットワーク内で、またはパブリックワイヤレスホットスポットでラップトップを使用する場合、非常に異なり、このメモの範囲を超えて、すべての可能なシナリオを詳細に説明することです。
The authors believe that adequate security for SIP telephony devices can be best implemented within protected networks, be they private IP networks or service provider SIP-enabled networks where a large part of the security threats listed here are dealt with in the protected network. A more general security discussion that includes network-based security features, such as network-based assertion of identity [58] and privacy services [7], is outside the scope of this memo, but must be well understood by developers, network managers, and service providers.
著者は、SIPテレフォニーデバイスの適切なセキュリティは、プライベートIPネットワークであろうとサービスプロバイダーSIP対応ネットワークで、ここにリストされているセキュリティ脅威の大部分が保護されたネットワークで扱われている場合でも、保護されたネットワーク内で最適に実装できると考えています。ネットワークベースのアイデンティティ[58]やプライバシーサービス[7]などのネットワークベースのセキュリティ機能を含む、より一般的なセキュリティディスカッションは、このメモの範囲外ですが、開発者、ネットワークマネージャーによってよく理解される必要があります。およびサービスプロバイダー。
In the following, some basic security considerations as specified in RFC 3261 are discussed as they apply to SIP telephony devices.
以下では、RFC 3261で指定されているいくつかの基本的なセキュリティ上の考慮事項について、SIPテレフォニーデバイスに適用する際に議論されています。
Transport Level Security SIP telephony devices that operate outside the perimeter of secure private IP networks (this includes telecommuters and roaming users) MUST use TLS to the outgoing SIP proxy for protection on the first hop. SIP telephony devices that use TLS must support SIPS in the SIP headers.
安全なプライベートIPネットワークの境界外で動作するトランスポートレベルのセキュリティSIPテレフォニーデバイス（これには、電気在庫とローミングユーザーが含まれます）は、最初のホップでの保護のためにTLSを発信SIPプロキシに使用する必要があります。TLSを使用するSIPテレフォニーデバイスは、SIPヘッダーのSIPをサポートする必要があります。
Supporting large numbers of TLS channels to endpoints is quite a burden for service providers and may therefore constitute a premium service feature.
多数のTLSチャネルをエンドポイントにサポートすることは、サービスプロバイダーにとって非常に負担であるため、プレミアムサービス機能を構成する可能性があります。
Digest Authentication SIP telephony devices MUST support digest authentication to register with the outgoing SIP registrar. This ensures proper identity credentials that can be conveyed by the network to the called party. It is assumed that the service provider operating the outgoing SIP registrar has an adequate trust relationship with its users and knows its customers well enough (identity, address, billing relationship, etc.). The exceptions are users of prepaid service. SIP telephony devices that accept prepaid calls MUST place "unknown" in the "From" header.
DIGEST認証SIPテレフォニーデバイスは、発信SIPレジストラに登録するために消化認証をサポートする必要があります。これにより、ネットワークが呼び出された当事者に伝えることができる適切なアイデンティティ資格情報が保証されます。発信SIPレジストラを操作するサービスプロバイダーは、ユーザーと適切な信頼関係を持ち、顧客を十分に知っている（身元、住所、請求関係など）と想定されています。例外は、プリペイドサービスのユーザーです。プリペイドコールを受け入れるSIPテレフォニーデバイスは、「ヘッダーから「不明」に配置する必要があります。
End User Certificates SIP telephony devices MAY store personal end user certificates that are part of some Public Key Infrastructure (PKI) [59] service for high-security identification to the outgoing SIP registrar as well as for end-to-end authentication. SIP telephony devices equipped for certificate-based authentication MUST also store a key ring of certificates from public certificate authorities (CAs).
エンドユーザー証明書SIPテレフォニーデバイスは、公開キーインフラストラクチャ（PKI）[59]サービスの一部である個人のエンドユーザー証明書を保存することができます。証明書ベースの認証用に装備されたSIPテレフォニーデバイスは、公的証明書当局（CAS）から証明書の重要なリングも保存する必要があります。
Note the recent work in the IETF on certificate services that do not require the telephony devices to store certificates [60].
証明書を保存するためにテレフォニーデバイスを必要としない証明書サービスに関するIETFの最近の作業に注意してください[60]。
End-to-End Security Using S/MIME S/MIME [61] MUST be supported by SIP telephony devices to sign and encrypt portions of the SIP message that are not strictly required for routing by intermediaries. S/MIME protects private information in the SIP bodies and in some SIP headers from intermediaries. The end user certificates required for S/MIME ensure the identity of the parties to each other. Note: S/MIME need not be used, though, in every call.
S/MIME S/MIME [61]を使用したエンドツーエンドのセキュリティは、SIPテレフォニーデバイスによってサポートされて、仲介者によるルーティングに厳密に必要とされないSIPメッセージの一部に署名および暗号化する必要があります。S/MIMEは、SIP団体および仲介者からの一部のSIPヘッダーの個人情報を保護します。S/MIMEに必要なエンドユーザー証明書は、当事者の身元をお互いに保証します。注：すべての呼び出しでは、S/MIMEを使用する必要はありません。
Media Encryption Secure RTP (SRTP) [62] MAY be used for the encryption of media such as audio, text, and video, after the keying information has been passed by SIP signaling. Instant messaging MAY be protected end-to-end using S/MIME.
SIPシグナル伝達によってキーイング情報が渡された後、メディア暗号化セキュアRTP（SRTP）[62]は、オーディオ、テキスト、ビデオなどのメディアの暗号化に使用できます。インスタントメッセージングは、S/MIMEを使用してエンドツーエンドで保護できます。
The various NAT and firewall traversal scenarios require support in telephony SIP devices. The best current practices for NAT traversal for SIP are reviewed in [51]. Most scenarios where there are no SIP-enabled network edge NAT/firewalls or gateways in the enterprise can be managed if there is a STUN client in the SIP telephony device and a STUN server on the Internet, maintained by a service provider. In some exceptional cases (legacy symmetric NAT), an external media relay must also be provided that can support the Traversal Using Relay NAT (TURN) protocol exchange with SIP telephony devices. Media relays such as TURN come at a high bandwidth cost to the service provider, since the bandwidth for many active SIP telephony devices must be supported. Media relays may also introduce longer paths with additional delays for voice.
さまざまなNATおよびファイアウォールトラバーサルシナリオには、テレフォニーSIPデバイスでのサポートが必要です。SIPのNATトラバーサルの最良の現在の慣行は[51]でレビューされています。SIP対応のネットワークエッジNAT/ファイアウォールまたはゲートウェイがない場合のほとんどのシナリオは、SIPテレフォニーデバイスにスタンクライアントとインターネットにスタンサーバーがあり、サービスプロバイダーによって維持されている場合に管理できます。いくつかの例外的なケース（レガシー対称NAT）では、SIPテレフォニーデバイスを使用したリレーNAT（ターン）プロトコル交換を使用してトラバーサルをサポートできる外部メディアリレーも提供する必要があります。ターンなどのメディアリレーは、多くのアクティブなSIPテレフォニーデバイスの帯域幅をサポートする必要があるため、サービスプロバイダーにとって帯域幅の高いコストで高くなります。メディアリレーは、音声の追加の遅延がある長いパスを導入する場合があります。
Due to these disadvantages of media relays, it is preferable to avoid symmetric and non-deterministic NATs in the network, so that only STUN can be used, where required. Reference [63] deals in more detail how NAT has to 'behave'.
メディアリレーのこれらの欠点により、ネットワーク内の対称性および非決定的NATを避けることが望ましいため、必要に応じてスタンのみを使用できます。参照[63]は、NATがどのように「振る舞う」ことができるかをより詳細に扱います。
It is not always obvious to determine the specific NAT and firewall scenario under which a SIP telephony device may operate.
SIPテレフォニーデバイスが動作する可能性のある特定のNATおよびファイアウォールシナリオを決定することは必ずしも明白ではありません。
For this reason, the support for Interactive Connectivity Establishment (ICE) has been defined to be deployed in all devices that required end-to-end connectivity for SIP signaling and RTP media streams, as well as for streaming media using Real Time Streaming Protocol (RTSP). ICE makes use of existing protocols, such as STUN and TURN.
このため、Interactive Connectivity Indecivity Indecivity（ICE）のサポートは、SIPシグナリングとRTPメディアストリームにエンドツーエンド接続を必要とするすべてのデバイスに展開されるように定義されています。また、リアルタイムストリーミングプロトコルを使用したメディアのストリーミング（rtsp）。ICEは、スタンやターンなどの既存のプロトコルを使用します。
Call flows using SIP security mechanisms The high-level security aspects described here are best illustrated by inspecting the detailed call flows using SIP security, such as in [64].
SIPセキュリティメカニズムを使用したコールフローここで説明する高レベルのセキュリティの側面は、[64]などのSIPセキュリティを使用して詳細なコールフローを検査することにより最もよく示されています。
Security enhancements, certificates, and identity management As of this writing, recent work in the IETF deals with the SIP Authenticated Identity Body (AIB) format [65], new S/MIME requirements, enhancements for the authenticated identity, and Certificate Management Services for SIP. We recommend developers and network managers to follow this work as it will develop into IETF standards.
セキュリティの強化、証明書、およびIDの管理この記事の執筆時点での最近のIETFでの作業は、SIP認証IDボディ（AIB）形式[65]、新しいS/MIME要件、認証されたIDの強化、および証明書管理サービスを扱っています。一口。開発者とネットワークマネージャーは、IETF標準に発展するため、この作業に従うことをお勧めします。
Paul Kyzivat and Francois Audet have made useful comments how to support to the dial plan requirements in Req-17. Mary Barnes has kindly made a very detailed review of version 04 that has contributed to significantly improving the document. Useful comments on version 05 have also been made by Ted Hardie, David Kessens, Russ Housley, and Harald Alvestrand that are reflected in this version of the document.
Paul KyzivatとFrancois Audetは、REQ-17のダイヤルプラン要件をサポートする方法を支援する有用なコメントをしました。メアリー・バーンズは、ドキュメントの大幅な改善に貢献したバージョン04の非常に詳細なレビューを親切に行いました。バージョン05に関する有用なコメントは、このバージョンのドキュメントに反映されているTed Hardie、David Kessens、Russ Housley、Harald Alvestrandによっても作成されています。
We would like to thank Jon Peterson for very detailed comments on the previous version 0.3 that has prompted the rewriting of much of this document. John Elwell has contributed with many detailed comments on version 04 of the document. Rohan Mahy has contributed several clarifications to the document and leadership in the discussions on support for the hearing disabled. These discussions have been concluded during the BOF on SIP Devices held during the 57th IETF, and the conclusions are reflected in the section on interactive text support for hearing- or speech-disabled users.
このドキュメントの多くの書き換えを促した以前のバージョン0.3に関する非常に詳細なコメントについて、Jon Petersonに感謝します。John Elwellは、ドキュメントのバージョン04に関する多くの詳細なコメントを提供しています。Rohan Mahyは、聴覚障害者の支援に関する議論において、文書とリーダーシップにいくつかの説明を提供しました。これらの議論は、第57 IETF中に開催されたSIPデバイスのBOFで終了しました。結論は、聴覚または音声障害のあるユーザーのインタラクティブなテキストサポートに関するセクションに反映されています。
Gunnar Hellstrom, Arnoud van Wijk, and Guido Gybels have been instrumental in driving the specification for support of the hearing disabled.
Gunnar Hellstrom、Arnoud Van Wijk、およびGuido Gybelsは、聴覚障害者のサポートの仕様を推進するのに役立ちました。
The authors would also like to thank numerous persons for contributions and comments to this work: Henning Schulzrinne, Jorgen Bjorkner, Jay Batson, Eric Tremblay, David Oran, Denise Caballero McCann, Brian Rosen, Jean Brierre, Kai Miao, Adrian Lewis, and Franz Edler. Jonathan Knight has contributed significantly to earlier versions of the requirements for SIP phones. Peter Baker has also provided valuable pointers to TIA/EIA IS 811 requirements to IP phones that are referenced here.
著者はまた、この作業への貢献とコメントについて多くの人に感謝したいと思います：ヘニング・シュルツリン、ヨルゲン・ビョルクナー、ジェイ・バットソン、エリック・トレンブレイ、デビッド・オラン、デニス・カバレロ・マッカン、ブライアン・ローゼン、ジャン・ブリエール、カイ・ミアオ、エイドリアン・ルイス、フランズエドラー。Jonathan Knightは、SIP電話の要件の以前のバージョンに大きく貢献しています。Peter Bakerはまた、TIA/EIAに貴重なポインターを提供しており、ここで参照されているIP電話に811の要件があります。
Last but not least, the co-authors of the previous versions, Daniel Petrie and Ian Butcher, have provided support and guidance all along in the development of these requirements. Their contributions are now the focus of separate documents.
最後になりましたが、以前のバージョンの共著者であるダニエル・ペトリーとイアン・ブッチャーは、これらの要件の開発においてずっとサポートとガイダンスを提供してきました。彼らの貢献は現在、個別の文書の焦点です。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] 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.
[2] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[3] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[3] Lemon、T。およびS. Cheshire、「動的ホスト構成プロトコル（DHCPV4）の長いオプションをエンコードする」、RFC 3396、2002年11月。
[4] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[4] Mills、D。、「IPv4、IPv6およびOSI用のSimple Network Time Protocol（SNTP）バージョン4」、RFC 4330、2006年1月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[6] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[6] Peterson、J。、「セッション開始プロトコル（SIP）アドレスの録音のためのEnumservice登録」、RFC 3764、2004年4月。
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[7] ピーターソン、J。、「セッション開始プロトコル（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[9] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[9] Mahy、R。、「セッション開始プロトコル（SIP）のメッセージの概要とメッセージ待機表示イベントパッケージ」、RFC 3842、2004年8月。
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[10] Schulzrinne、H。、「電話番号のためのTel URI」、RFC 3966、2004年12月。
[11] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[11] Sparks、R。、「セッション開始プロトコル（SIP）参照メソッド」、RFC 3515、2003年4月。
[12] Johnston, A., "SIP Service Examples", Work in Progress, March 2006.
[12] ジョンストン、A。、「SIPサービスの例」、2006年3月、進行中の作業。
[13] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[13] Schulzrinne、H。およびS. Petrack、「DTMFディジット、テレフォニートーン、テレフォニーシグナルのRTPペイロード」、RFC 2833、2000年5月。
[14] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[14] Casner、S。およびP. Hoschka、「RTPペイロードフォーマットのMIMEタイプ登録」、RFC 3555、2003年7月。
[15] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[15] Camarillo、G.、Eriksson、G.、Holler、J。、およびH. Schulzrinne、「セッション説明プロトコル（SDP）のメディアラインのグループ化」、RFC 3388、2002年12月。
[16] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[16] Camarillo、G。およびH. Schulzrinne、「セッション開始プロトコル（SIP）における初期のメディアとリンギングトーン生成」、RFC 3960、2004年12月。
[17] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[17] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C。、およびK. Summers、「セッション開始プロトコル（SIP）基本的なコールフローの例」、BCP 75、RFC 3665、2003年12月。
[18] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December 2003.
[18] Johnston、A.、Donovan、S.、Sparks、R.、Cunningham、C。、およびK. Summers、「セッション開始プロトコル（SIP）公開電話ネットワーク（PSTN）コールフロー」、BCP 76、RFC 3666、12月2003年。
[19] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[19] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）における第三者コールコントロール（3PCC）の最良の現在のプラクティス」、2004年4月、RFC 3725、RFC 3725。
[20] Mahy, R., et al., "A Call Control and Multi-party usage framework for the Session Initiation Protocol (SIP)", Work in Progress, March 2006.
[20] Mahy、R.、et al。、「セッション開始プロトコル（SIP）のコールコントロールとマルチパーティの使用フレームワーク」、2006年3月、Work in Progress。
[21] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", Work in Progress, October 2005.
[21] Johnston、A。およびO. Levin、「セッション開始プロトコルコールコントロール - ユーザーエージェントの会議」、2005年10月、進行中の作業。
[22] Even, R. and N. Ismail, "Conferencing Scenarios", Work in Progress, September 2005.
[22] さらに、R。およびN. Ismail、「会議シナリオ」、2005年9月、進行中の作業。
[23] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[23] Hellstrom、G。およびP. Jones、「テキスト会話のためのRTPペイロード」、RFC 4103、2005年6月。
[24] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[24] Campbell、B.、Rosenberg、J.、Schulzrinne、H.、Huitema、C。、およびD. Gurle、「インスタントメッセージングのセッション開始プロトコル（SIP）拡張」、RFC 3428、2002年12月。
[25] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[25] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[26] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[26] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[27] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", Work in Progress, September 2005.
[27] Schulzrinne、H.、Gurbani、V.、Kyzivat、P。、およびJ. Rosenberg、「RPID：リッチなプレゼンスが存在情報データ形式（PIDF）を拡張する」、2005年9月の作業。
[28] See the Working Group on Emergency Context Resolution with Internet Technologies at http://www.ietf.org/html.charters/ecrit-charter.html
[28] http://www.ietf.org/html.charters/ecrit-charter.htmlのインターネットテクノロジーに関する緊急コンテキスト解決に関するワーキンググループを参照してください
[29] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[29] Schulzrinne、H。およびJ. Polk、「セッション開始プロトコル（SIP）の通信リソースの優先順位」、RFC 4412、2006年2月。
[30] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", Work in Progress, July 2005.
[30] Polk、J。およびB. Rosen、「セッション開始プロトコルの位置輸送」、2005年7月、進行中の作業。
[31] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002.
[31] Charlton、N.、Gasson、M.、Gybels、G.、Spanner、M。、およびA. Van Wijk、「聴覚障害、聴覚障害、言語障害者をサポートするセッション開始プロトコル（SIP）のユーザー要件"、RFC 3351、2002年8月。
[32] van Wijk, A., "Framework of requirements for real-time text conversation using SIP", Work in Progress, September 2005.
[32] Van Wijk、A。、「SIPを使用したリアルタイムテキスト会話の要件のフレームワーク」、2005年9月、進行中の作業。
[33] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[33] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[34] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[34] Friedman、T.、Caceres、R。、およびA. Clark、「RTP制御プロトコル拡張レポート（RTCP XR）」、RFC 3611、2003年11月。
[35] Pendleton, A., "SIP Package for Quality Reporting Event", Work in Progress, February 2006.
[35] ペンドルトン、A。、「品質報告イベントのためのSIPパッケージ」、2006年2月、進行中の作業。
[36] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[36] Dierks、T。およびC. Allen、「TLSプロトコルバージョン1.0」、RFC 2246、1999年1月。
[37] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[37] Heinanen、J.、Baker、F.、Weiss、W。、およびJ. Wroclawski、「Assured Forwarding PHB Group」、RFC 2597、1999年6月。
[38] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[38] Braden、R.、Zhang、L.、Berson、S.、Herzog、S。、およびS. Jamin、「リソース予約プロトコル（RSVP） - バージョン1機能仕様」、RFC 2205、1997年9月。
[39] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[39] Schulzrinne、H。およびS. Casner、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、2003年7月。
[40] ITU-T Recommendation G.711, available online at http://www.itu.int.
[40] ITU-Tの推奨G.711、http：//www.itu.intでオンラインで入手できます。
[41] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951, December 2004.
[41] Andersen、S.、Duric、A.、Astom、H.、Hagen、R.、Kleijn、W。、およびJ. Linden、「Internet Low Bit Rate Codec（ILBC）」、RFC 3951、2004年12月。
[42] Duric, A. and S. Andersen, "Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech", RFC 3952, December 2004.
[42] Duric、A。and S. Andersen、「インターネットの低ビットレートコーデック（ILBC）スピーチのリアルタイムトランスポートプロトコル（RTP）ペイロード形式」、RFC 3952、2004年12月。
[43] Herlein, G., et al., "RTP Payload Format for the Speex Codec", Work in Progress, October 2005.
[43] Herlein、G.、et al。、「SPEEX CodecのRTPペイロード形式」、2005年10月の作業。
[44] TIA/EIA-810-A, "Transmission Requirements for Narrowband Voice over IP and Voice over PCM Digital Wireline Telephones", July 2000.
[44] TIA/EIA-810-A、「IPおよびVoice over PCM Digital Wireline電話の狭帯域音声の送信要件」、2000年7月。
[45] TIA-EIA-IS-811, "Terminal Equipment - Performance and Interoperability Requirements for Voice-over-IP (VoIP) Feature Telephones", July 2000.
[45] TIA-EIA-IS-811、「ターミナル機器 - ボイスオーバーIP（VOIP）機能電話のパフォーマンスと相互運用性の要件」、2000年7月。
[46] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[46] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[47] Wing, D., "Symmetric RTP and RTCP Considered Helpful", Work in Progress, October 2004.
[47] Wing、D。、「対称RTPとRTCPが役立つと考えられている」、2004年10月の作業。
[48] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[48] Rosenberg、J.、Weinberger、J.、Huitema、C。、およびR. Mahy、「Stun-ネットワークアドレス翻訳者（NAT）を介したユーザーデータグラムプロトコル（UDP）の単純なトラバーサル」、RFC 3489、2003年3月。
[49] Jennings, C., "NAT Classification Test Results", Work in Progress, July 2005.
[49] ジェニングス、C。、「NAT分類テスト結果」、2005年7月、進行中の作業。
[50] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, July 2005.
[50] Rosenberg、J。、「Interactive Connectivity Indecivity（ICE）：ネットワークアドレス翻訳者の方法論（NAT）オファー/回答プロトコルのトラバーサル」、2005年7月、進行中の作業。
[51] Boulton, C. and J. Rosenberg, "Best Current Practices for NAT Traversal for SIP", Work in Progress, October 2005.
[51] Boulton、C。およびJ. Rosenberg、「SIPのNat Traversalの最良の現在のプラクティス」、2005年10月、進行中の作業。
[52] P. Eggert, "Sources for time zone and daylight saving time data." Available at http://www.twinsun.com/tz/tz-link.htm.
[52] P. Eggert、「タイムゾーンと夏時間のデータのソース。」http://www.twinsun.com/tz/tz-link.htmで入手可能。
[53] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[53] Campbell、B。およびR. Sparks、「SIP Request-URIを使用したサービスコンテキストの制御」、RFC 3087、2001年4月。
[54] Mahy, R., "Connection Reuse in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
[54] Mahy、R。、「セッション開始プロトコル（SIP）での接続再利用」、2006年2月、進行中の作業。
[55] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol", Work in Progress, March 2006.
[55] Jennings、C。and R. Mahy、「マネージングクライアントはセッション開始プロトコルで接続を開始しました」、2006年3月、進行中の作業。
[56] Petrie, D., "A Framework for SIP User Agent Profile Delivery", Work in Progress, July 2005.
[56] Petrie、D。、「SIPユーザーエージェントプロファイル配信のフレームワーク」、2005年7月、進行中の作業。
[57] Jennings, C., "SIP Tutorial: SIP Security", presented at the VON Spring 2004 conference, March 29, 2004, Santa Clara, CA.
[57] Jennings、C。、「SIPチュートリアル：SIP Security」、2004年3月29日、カリフォルニア州サンタクララのVon Spring 2004 Conferenceで発表されました。
[58] 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.
[58] Jennings、C.、Peterson、J。、およびM. Watson、「信頼できるネットワーク内の主張されたアイデンティティのセッション開始プロトコル（SIP）へのプライベートエクステンション」、RFC 3325、2002年11月。
[59] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[59] Chokhani、S.、Ford、W.、Sabett、R.、Merrill、C。、およびS. Wu、「インターネットX.509公開キーインフラストラクチャ証明書ポリシーおよび認証慣行フレームワーク」、RFC 3647、2003年11月。
[60] Jennings, C. and J. Peterson, "Certificate Management Service for The Session Initiation Protocol (SIP)", Work in Progress, March 2006.
[60] Jennings、C。and J. Peterson、「セッション開始プロトコル（SIP）の証明書管理サービス」、2006年3月、進行中の作業。
[61] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[61] Ramsdell、B。、「Secure/Multipurpose Internet Mail拡張機能（S/MIME）バージョン3.1メッセージ仕様」、RFC 3851、2004年7月。
[62] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[62] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「セキュアリアルタイム輸送プロトコル（SRTP）」、RFC 3711、2004年3月。
[63] Audet, F. and C. Jennings, "NAT Behavioral Requirements for Unicast UDP", Work in Progress, September 2005.
[63] Audet、F。およびC. Jennings、「Unicast UDPのNAT行動要件」、2005年9月、進行中の作業。
[64] Jennings, C., "Example call flows using SIP security mechanisms", Work in Progress, February 2006.
[64] Jennings、C。、「SIPセキュリティメカニズムを使用したコールフローの例」、2006年2月に進行中の作業。
[65] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[65] Peterson、J。、「セッション開始プロトコル（SIP）認証IDボディ（AIB）形式」、RFC 3893、2004年9月。
Author's Addresses
著者のアドレス
Henry Sinnreich Pulver.com 115 Broadhollow Road Melville, NY 11747, USA
Henry Sinnreich Pulver.com 115 Broadhollow Road Melville、Ny 11747、USA
EMail: henry@pulver.com
Phone: +1-631-961-8950
Steven Lass Verizon 1201 East Arapaho Road Richardson, TX 75081, USA
スティーブンラスベリゾン1201イーストアラパホロードリチャードソン、テキサス75081、米国
EMail: steven.lass@verizonbusiness.com
Phone: +1-972-728-2363
Christian Stredicke snom technology AG Gradestrasse, 46 D-12347 Berlin, Germany
クリスチャンストレディックスノムテクノロジーAGグラデンツェ、46 D-12347ベルリン、ドイツ
EMail: cs@snom.de
Phone: +49(30)39833-0
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。