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
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).
著作権（C）インターネット協会（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テレフォニーデバイスの要件について説明します。パソコン、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テレフォニーユーザデバイスは、PC、ラップトップ、無線接続のPDA、「のWi-Fiの」SIPの携帯電話だけでなく、他の上で実行されている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.
（2）サービスプロバイダやネットワーク管理者、（3）メーカー、および（、（1）エンドユーザー：SIPテレフォニーデバイスは、多くのインターネット・プロトコルを話す非常に複雑なIPエンドポイントですオーディオとビジュアルインターフェースを持っている、といくつかの有権者を対象とした機能を必要とします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、アナログ機能携帯電話、または携帯電話に見られるように購入、インストール、および操作の同様の使いやすさを可能にするような要件の目的は、相互運用性およびマルチベンダー・サポートコア機能の明確に定義されたセットです。エンドユーザーおよびネットワーク管理者の両方で期待されているパソコンやネットワーク接続のPDAと比較して類似または使用のより良い容易PCや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.
「べきでない」、および「MAY」、RFC 2119で説明したように、本書では解釈されるべきではなく、[1]のではなく、の性質を示す、この文書は情報提供であるため、キーワードは「MUST」、「SHOULD」提案の要件。
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.
私たちはここかMAYが指定されているべきである場合を除いて、すべての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 /ノート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）を使用して自動設定して、IPネットワーク設定を取得できなければならない[3]。
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検索を管理していることを好みます。注：ENUMリゾルバはまた、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 [7]をSIPプライバシーヘッダをサポートしなければなりません。
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：RFC 3264で指定されたSIP電話デバイスは、保留中の既存のコールを発信することができ、そして開始または別のコールを受信しなければならない[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メッセージをサポートしなければならない[9]とメッセージストアプラットフォームとの統合。
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
TEL：+12125551234 SIP：+12125551234@example.net;ユーザー=電話一口：+12125551234@example.net;ユーザー=電話SIP：すする5551234@example.net：5551234@example.net電話：5551234;電話コンテキスト= nyc1.example.net SIP：5551234; phone-context=nyc1.example.net@example.net;ユーザー=電話一口：5551234; phone-context=nyc1.example.net@example.net;ユーザー=電話SIP：5551234 ; phone-context=nyc1.example.net@example.net;ユーザーは= dialstringと入力をすする：5551234; phone-context=nyc1.example.net@example.net;ユーザー= dialstringと入力TEL：5551234;電話コンテキスト= + 1212 SIP ：5551234; phone-context=+1212@example.net;ユーザー=電話一口：5551234; phone-context=+1212@example.net;ユーザー=電話SIP：5551234; phone-context=+1212@example.net。ユーザー= dialstringと入力では、SIP：5551234; phone-context=+1212@example.net;ユーザー= 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"
SIP：すする5551234@example.net：5551234@example.net SIP：5551234; phone-context=nyc1.example.net@example.net;ユーザー= dialstringと入力一口：5551234; phone-context=nyc1.example.net@example .NET;ユーザー= dialstringと入力SIP：5551234; phone-context=+1212@example.net;ユーザー= dialstringと入力一口：5551234; phone-context=+1212@example.net;ユーザー= 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]のためのNOTIFYサポートしなければならない[12]。 SIP電話デバイスは、エスケープサポートしなければならない置き換え-ヘッダ（RFC 3891）および参照のために、ヘッダ内の他のエスケープヘッダをサポートしなければなりません。
Req-20: SIP telephony devices MUST support the unattended call transfer flows as defined in [12].
REQ-20：[12]で定義されるようにSIPテレフォニーデバイス無人コール転送をサポートしなければならないが流れます。
Req-21: SIP telephony devices MUST support the attended call transfer as defined in [12].
REQ-21：[12]で定義されるようにSIPテレフォニーデバイスが参加コール転送をサポートしなければなりません。
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で指定された電話イベントと命名デュアルトーン多重周波数（DTMF）を送信できなければならない[13]。
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でRTPペイロード形式のための登録されたMIMEタイプを持つ[14]。
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：ダイナミックペイロードタイプは、セッション全体を通じて一定のままでなければなりません。エンドポイントは、コーデックを再交渉するか、保留中の通話を置くことを決定した場合、例えば、再招待のためのペイロードタイプは、最初のペイロードタイプと同じでなければなりません。 RFC 3388 [15]で定義されるようにSIPデバイスは、フロー識別をサポートするかもしれません。
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応答に応じて、BYE要求を送信するために許容可能な動作です。
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デバイスは、呼情報ヘッダをサポートする必要があり、表示能力に応じて、例えば、アイコンまたは発信者の画像を表示してもよいです。
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テレフォニーデバイスは、両方のモードを受信して、ローカルで生成された中で、保留音をサポートするかもしれません。 [17]また、保留中の音楽とコールフローのための「SIPサービスの例」を参照してください。
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：コールは一般的に3分、所定の期間保留にされた後にSIPテレフォニーデバイスが鳴るかもしれません。
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テレフォニーデバイスが[20] SIP呼制御とマルチパーティの使用をサポートする必要があります。
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]と十分な表示を備えている場合はまた、インスタントメッセージング（IM）とプレゼンスをサポートするかもしれません[24]、[25] 。
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テレフォニーデバイスはまた、など、別のコールにいるかの会議であること、メッセージを入力し、顔文字などの伝統的なサイレント、新しいイベント状態ベースの情報として、プレゼンスステータスをサポートすることができますいくつかの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テレフォニーデバイスが存在することによって有効に新しいIP通信サービスのための[24]プレゼンス情報をサポートする必要があり、豊富なプレゼンス情報データ・フォーマットをサポートすべきである[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：ユーザーが「着信拒否」すること、およびUAはプレゼンス情報をサポートできる場合、これは、ネットワークを介してプレゼンス状態として現れるかもしれませSIPテレフォニーデバイスの状態を設定できなければなりません。
Req-41: SIP telephony devices with "Do Not Disturb" enabled MUST respond to new sessions with "486 Busy Here".
REQ-41：「着信拒否」とのSIPテレフォニーデバイスは、「ここでビジー486」を使用して新しいセッションに応答しなければならない可能にしました。
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電話ゲートウェイにメッセージルーティングのための行動に影響を与え、SIPテレフォニーデバイスの3261ユーザーがそのような場合、その優先度の低い通信活動を中断したいできるRFCで指定された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）との緊急コンテキスト決議に関する作業部会の仕事に従うことをお勧めします。完全なソリューションは、現時点では今後の検討課題です。 [30]参照、SIPPING WGに位置搬送するための要件に取り組むもあります。
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テレフォニーデバイスは、行ごとに着信拒否するために、クライアントの状態をサポートすることができなければなりません。
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テレフォニーデバイスが複数行のコールウェイティングをサポートしなければなりません。デバイスは、キャッチホンインジケータが行ごとに設定できるようにしなければなりません。
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.
次の要件は、一連の資格情報を持つユーザーは、デバイスのアイデンティティは異なる複数のユーザーからの個人認証情報をサポートすることができます任意の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.
テキストのブロックに基づいてSIMPLE [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テレフォニーなどのSIPディスプレイ携帯電話などのデバイスとIP-アナログアダプタは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電話装置は、入力されたテキストへの道を提供するべきであり、任意の合理的な方法を介してテキストを表示します。ビルトインユーザインタフェース、標準的な有線または無線インターフェース、および/またはウェブインターフェースを介してテキストのサポートは、すべての合理的なメカニズムであると考えられます。
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：リアルタイムインタラクティブテキストは、RFC 4103 [23]に記載されているようにディスプレイを含む、または外部ディスプレイを接続するための機能を有するSIPテレフォニーデバイスは、プロトコルサポートを含まなければなりません。
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）ポートが設けられている場合、それは（実際には、これは短期的に奨励されているRFC 4103のテキストの会話にITU-T勧告V.18に係るすべてのテキスト電話プロトコルからゲートウェイ機能をサポートするかもしれ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ミリメートルオーディオポートを提供することができます。
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拡張レポートを使用すると、音声品質、RFC 3611 [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テレフォニーデバイスは、SIPレジストラがセキュア、プライベートIP外側に配置されているシナリオのための安全な輸送のための[36]トランスポート層セキュリティ（TLS）をサポートする必要があり、また、RFC 3261に従ってダイジェスト認証をSIPテレフォニーデバイスをサポートしなければなりません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要求URIのユーザ部分が空白であるか、またはプロビジョニング接触と一致しない場合、着信INVITEを拒否するためのオプションをサポートしなければなりません。これは戦争ダイヤラ攻撃、不要なテレマーケティング、およびスパムに対する保護を提供します。拒否する設定が構成可能でなければなりません。
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電話デバイスは、メッセージは、クライアントが登録されているプロキシまたはプロキシから来ていない場合、着信INVITEを拒否することができなければなりません。これは、プロキシ上で終端するコール機能をバイパスから発信者を防ぐことができます。 DNS SRVは、プロキシアドレスを指定するために、クライアントが解決プロキシIPアドレスのすべてからINVITEを受け入れなければなりません。
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デバイスは、[37] RTPは、RFC 2597に従ってストリームの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 AF31（コードポイント011010）とのSIPパケットを優先転送（コードポイント101110）の推奨DSCPを有する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:
短いリストMAYに興味が実装者は、しかし、SIP UAが目標とされたモバイルネットワークで見つかった最小限のオーバーIP（VoIP）有線音声で使用されるコーデックの数、また、コーデックをサポートしています。次のように好みの順序付きのショートリストが見えることがあります。
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]のようなオーディオ/ビデオトランスポート（AVT）ペイロードタイプ0（G.711はuLaw）をサポートし、その附属書1及び2すべきです。
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とその附属書をサポートするかもしれません。注：iLBCのとG.723.1コーデックは、帯域幅に制約の環境では好ましいのでG.729コーデックは、下位互換性のためにのみここに含まれます。
Note: The authors believe the Internet Low Bit Rate codec
(iLBC) should be the default codec for Internet telephony.
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テレフォニーデバイスは、呼び出し元のIDに基づいて、異なる着信音をサポートするかもしれません。
Req-80: SIP telephony devices SHOULD indicate the preferred language [46] using User Agent capabilities [26].
REQ-80：SIPテレフォニーデバイスは、ユーザエージェント機能を使用して、[46]を好みの言語を示すべきである[26]。
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テレフォニーデバイスは、クライアントベースのディレクトリ検索のためのLDAP（Lightweight Directory Access Protocol）をサポートすることができます。
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.
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することができるはず意味）公共、NAPT機器の外部アドレスを持つSIPメッセージを読み込みます。 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を介してUDPの単純トラバーサル（STUN）プロトコル[48]をサポートすべきです。 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].
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テレフォニーデバイスは、アドレス指定機能の2種類をサポートしなければならない電話番号またはURIのいずれかを「ダイヤル」するために、エンドユーザーを有効にします。
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の中で許可されているすべての英数字が含まれています。可能なアプローチは、PDA用のWebページ、ディスプレイやキーボード入力、入力補完、または落書きを使用しています。
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.
すべての設定フォーマットの幅広い採用を達成するためには、ささやかなデバイスがそれを使用することは、サイズが過大であってはならないことが重要です。任意のフォーマットは、ベンダーがそれに柔軟な拡張を可能にするのに十分な構造化されるべきである（SHOULD）。設定は、デバイスまたは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のタイプをも示すべきです。例：デバイスID = "000413100A10;タイプ= 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デバイスが応答バックUAにルーティングすることができるようになりますようにリクエストを送信するために使用することができます。例：SIPPort = "5060;運輸= 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）に関連付けられたネットワークパケットの構成であるべきです。これらの設定は、ネットワーク内の音声パケットを識別するのにネットワークオペレータを支援し、彼らが必要なQoSでそれらを輸送することができます。設定は、異なるトランスポート層及びシグナリング、メディア、または投与のために独立して設定可能です。 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"
ネットワークトラフィックの両方のカテゴリのために、デバイスは、レイヤ3（IPのDiffServ）とネットワーク・プロトコル・スタックの層2（例えば、IEEE 802.1D / Q）の両方のためのサービス設定の種類の構成を可能にするはずです。例：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"
デバイスのためのアウトバウンドプロキシを設定してもよいです。設定は、すべてのシグナリングパケットをアウトバウンドプロキシに送信されなければならないことのみNOルートは、アウトバウンドプロキシを受信していない場合に使用しなければならないことを要求することができます。これは、アプリケーション層ゲートウェイはシグナリングパス内にあることを保証します。第二の要件は、アウトバウンドプロキシによるルーティングの最適化を可能にします。例：OutboundProxy = "一口：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 = "一口：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"
再招待タイマーは、ユーザーエージェントは、ネットワーク障害による壊れたセッションを検出することができます。提供された場合、次の再招待の秒数を示す値を使用すべきです。例：SessionTimer = "600;単位=秒"
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（通常SIP 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）規則は、必要に応じて3をダイヤルされた数字からURIを構築し、そしてするためにどのによってルールSIP INVITEをルーティングに使用されます。
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:
例えば、桁マップは、SIP URLにユーザーの入力を変換するDNS NAPTR（RFC 2915）のように正規表現を使用することができます。 「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
| ^（[0-9] *）の＃$ | SIP：？\ 1 @ \ dは、ユーザー=電話|アウトバウンド= proxy.com | ^（[-ZA-Z0-9＆= + \ $、; \ - 。！。_〜* '（）％] + @ +）|一口：\ 1 | | ^（[-ZA-Z0-9＆= + \ $、; \ -_〜* '（）％？！] +）$ | SIP：\ 1 \ D @ | | ^ $ | SIP（。）：\ dは@ \ 1 |タイムアウト= 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.
ユーザーが[OK]キーを押した後、「ユーザー=電話12345@proxy.com一口」たとえば、ユーザーが「12345」を入力したときに、UAはにリクエストを送信することがあります。
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"
（タイマT1のような）SIPのパラメータおよびその他の関連の設定が指示されてもよいです。使い方の例では、DNS SRVのフェールオーバー時間の短縮になります。例：SIPTimer = "T1 = 100;単位= 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"
利用可能なコーデックのセットは、RFC 3264によれば、コーデックネゴシエーションに使用される。例：コーデック= "Speexに/ 8000; PTIME = 20; CNG =オン、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"
設定は、どちらかの任務や、安全なRTPの使用を奨励するSRTP（Secure Realtime Transport Protocol）を使用して、オーディオのプライバシーに関するヒントを含まなければなりません。例：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]）で表すことができます。これらのイベントを送信するための方法は、優先順位で設定すべきである（SHOULD）。設定を使用する必要があるコンテンツタイプのような追加のパラメータを含むことができます。例：DTMFMethod = "INFO;タイプ=アプリケーション/ 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が指定されています。それはオルソン時間つのデータベース[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"
データベースの命名体系の例としては、アジア/ドバイかアメリカ/ロサンゼルス名前の最初の部分は、大陸や海であり、第二の部分は、通常、その時間帯で最大の都市であるです。 UTCオフセットのようなオプションのパラメータは、内部データベースにタイムゾーン情報をマッピングすることができないのUAのための追加的な情報を提供することができます。例：タイムゾーン= "アジア/ドバイ;オフセット= 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タイムサーバの設定は、タイムサーバの設定よりも優先順位が高いです。例：タイムサーバ= "12.34.5.2;プロトコル= 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で定義されたコードを使用しなければなりません。例：言語=「ド」
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=*"
デバイスは、認証が（装置上）が必要であると認証の種類が必要であるか否かの設定をサポートしなければなりません。例：InboundAuthentication = "ダイジェスト;パターン= *"
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 [53]で指定されるように、様々な音声メッセージの設定は、サービスコンテキストのURIの使用を必要とします。
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"
メッセージは、クライアントが音声メッセージ・サーバと何MWIの概要が表示される場合があり[9]にサブスクライブする必要がありコントロールを設定するインジケータ（MWI）のアドレスを待っています。例：MWISubscribe = "一口：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.
ユーザエージェントは、前のサブスクリプションなしで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.
現在、このデバイスに割り当てられたユーザー指定の目的は、設定ユーザーセクションで定義されたユーザのアイデンティティと装置を提供することです。これは、ユーザーのローミングに関して主として面白いです。デバイスは、ユーザーがそれらにサインオンすることができ、その後、その特定の設定を取得することを要求することができます。同様に、ユーザーがデバイスの使用を停止し、存在していない間、彼らの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.
ローミングのための一つの可能なシナリオは、それらが登録されていることをいくつかのAOR（例えば、一つ以上の個人の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が、設定で定義されなければなりません。これは、デバイス自体またはユーザーのいずれかに関係するかもしれません。例：AOR = "一口：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].
SIP [55]の接続指向の輸送のための接続の再利用[54]とガイドラインに関する最近の研究を参照してください。
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]に記載の方法および要件を使用すべきです。ユーザー名またはドメイン名にレルムはユーザによる設定なしで、自動的にindividual-またはグループ固有の設定のためにデバイスを設定する構成サーバによって使用されるべきです。画像およびサービスデータのアップグレードは、ユーザが任意の設定を必要とすべきではありません。
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攻撃、および民間の顧客データの盗難に起因する負債および盗聴に難セキュアなSIPテレフォニーデバイスとユーザによるサービスの盗難に限定されるものではないか、特にそのようなメディア（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.
自宅で仕事をするときや旅行中に企業ネットワークへの仮想プライベートネットワーク（VPN）アクセスを使用して、住宅ネットワークや従業員を使用して企業ネットワークにおける展開シナリオの多くは、あります。それぞれに異なるセキュリティシナリオがあります。セキュリティの期待は、また非常に異なっている公衆無線ホットスポットにノートパソコンを使用する際に、企業ネットワーク内の、と言うか、このメモの範囲を詳細にすべての可能なシナリオを記述するために超えそうです。
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.
著者は、彼らのプライベートIPネットワークやここに記載されているセキュリティの脅威の大部分は保護されたネットワークで対処されているサービスプロバイダーのSIP対応のネットワークで、SIPテレフォニーデバイスのための十分なセキュリティが最高の保護されたネットワーク内に実装することができると信じています。ネットワークベースのような同一のネットワークベースのアサーションなどのセキュリティ機能、[58]およびプライバシーサービスを含むより一般的なセキュリティの議論は、[7]、このメモの範囲の外であるが、十分に開発者、ネットワーク管理者によって理解されなければなりません、およびサービスプロバイダ。
In the following, some basic security considerations as specified in RFC 3261 are discussed as they apply to SIP telephony devices.
彼らはテレフォニーデバイスをSIPに適用される以下では、RFC 3261で指定されているいくつかの基本的なセキュリティ上の考慮事項が議論されています。
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テレフォニーデバイスは、（これは在宅勤務やローミングユーザーを含みます）、最初のホップ上の保護のために、発信SIPプロキシにTLSを使用しなければなりません。 TLSを使用してSIPテレフォニーデバイスは、SIPヘッダ内SIPSをサポートしている必要があります。
Supporting large numbers of TLS channels to endpoints is quite
a burden for service providers and may therefore constitute a
premium service feature.
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.
ダイジェスト認証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テレフォニーデバイスは、発信SIPレジストラへの高セキュリティの識別のためだけでなく、エンド・ツー・エンドの認証のためのいくつかの公開鍵インフラストラクチャ（PKI）[59]のサービスの一部である個人のエンドユーザ証明書を格納することができます。証明書ベースの認証のために装備SIPテレフォニーデバイスはまた、公共の証明機関（CA）から証明書のキーリングを保存しなければなりません。
Note the recent work in the IETF on certificate services that
do not require the telephony devices to store certificates
[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テレフォニーデバイスにおけるSTUNクライアントとインターネット上のSTUNサーバーがある場合、企業にはSIP対応ネットワークのエッジNAT /ファイアウォールやゲートウェイはありませんほとんどのシナリオを管理することができます。いくつかの例外的な場合（従来の対称型NAT）において、外部メディアリレーはまた、リレーNAT（TURN）SIP電話デバイスとのプロトコル交換を使用したトラバーサルをサポートできることを提供しなければなりません。多くのアクティブなSIPテレフォニーデバイスのための帯域幅をサポートしなければならないので、そのようなTURNなどのメディアリレーは、サービスプロバイダへの高帯域幅のコストで来ます。メディアリレーは、音声のための追加の遅延との長いパスを導入することができます。
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'.
メディアリレーのこれらの欠点のために、必要な場合のみ、STUNは、使用することができるように、ネットワーク内で対称と非決定的NATのを避けることが好ましいです。参考NATは、「振る舞い」に持っているかを詳細に[63]を扱います。
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.
このため、インタラクティブ接続確立（ICE）のサポートは、リアルタイムストリーミングプロトコルを（使用してSIPシグナリングおよびRTPメディアストリームのためだけでなく、ストリーミングメディアのためのエンドツーエンドの接続を必要とするすべてのデバイスに展開されるように定義されていますRTSP）。 ICEは、STUNやTURNなどの既存のプロトコルを利用します。
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].
コールは、[64]のように、ここで説明した高レベルのセキュリティ態様は最良SIPセキュリティを使用して、フローの詳細なコールを検査することによって示されている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.
以下のためのセキュリティの強化、証明書、およびアイデンティティ管理本を書いている時点で、SIP認証済みアイデンティティボディ（AIB）形式でIETF取引における最近の研究[65]、新たにS / MIMEの要件、認証されたアイデンティティのための機能強化、および証明書管理サービスSIP。私たちは、それが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.
ポールKyzivatとフランソワAudetはREQ-17でのダイヤルプランの要件にサポートするために、どのように有益なコメントをしました。メアリー・バーンズは親切に大幅に文書の改善に貢献したバージョン04の非常に詳細な検討を行っています。バージョン05の有益なコメントは、ドキュメントのこのバージョンに反映されているテッドハーディー、デヴィッドKessens、ラスHousley、およびハラルド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の非常に詳細なコメントのためにジョン・ピーターソンに感謝したいと思います。ジョンエルウェルは、ドキュメントのバージョン04の多くの詳細なコメントに貢献してきました。ロハンマーイは無効審理のための支援に関する議論では、文書やリーダーシップには、いくつかの明確化に貢献しています。これらの議論は、SIPデバイス上のBOFの間に締結されている第57回IETFの間に開催された、と結論はhearing-や音声障害を持つユーザーのためのインタラクティブなテキストのサポートのセクションに反映されます。
Gunnar Hellstrom, Arnoud van Wijk, and Guido Gybels have been instrumental in driving the specification for support of the hearing disabled.
グンナー・ヘルストローム、ArnoudバンWijk、グイド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.
ヘニングSchulzrinneと、ヨルゲンBjorkner、ジェイ・バトソン、エリック・トレンブレイ、デビッド・オラン、デニス・キャバレロマッキャン、ブライアン・ローゼン、ジャンBrierre、甲斐ミャオ族、エイドリアン・ルイス、そしてフランツ：著者らはまた、この作品への貢献とコメントのために、多くの人々に感謝したいと思いますEdler。ジョナサン・ナイトは、SIP電話機のための要件の以前のバージョンに大きく貢献してきました。ピーター・ベイカーはまた、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、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]レモン、T.とS.チェシャー、 "動的ホスト構成プロトコル（DHCPv4の）でエンコーディング長いオプション"、RFC 3396、2002年11月。
[4] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
、RFC 4330、2006年1月[4]ミルズ、D.、 "IPv4、IPv6、およびOSIのため簡易ネットワークタイムプロトコル（SNTP）バージョン4"。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5]ローゼンバーグ、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]ピーターソン、J.、 "セッション開始プロトコルのためenumservice登録（SIP）アドレス・オブ・レコード"、RFC 3764、2004年4月。
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[7]ピーターソン、J.、RFC 3323 "セッション開始プロトコル（SIP）のためのプライバシーメカニズム"、2002年11月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8]ローゼンバーグ、J.、およびH. Schulzrinneと、RFC 3264 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル" 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]マーイ、R.、RFC 3842、2004年8月「セッション開始プロトコル（SIP）のためのメッセージサマリとメッセージ待機表示イベントパッケージ」。
[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]スパークス、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. 2000 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]キャマリロ、G.、エリクソン、G.、大声、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]カマリロ、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]ジョンストン、A.、ドノバン、S.、スパークス、R.、カニンガム、C.、およびK.サマーズ、 "セッション開始プロトコル（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]ジョンストン、A.、ドノバン、S.、スパークス、R.、カニンガム、C.、およびK.サマーズ、 "セッション開始プロトコル（SIP）、公衆交換電話網（PSTN）コールフロースイッチ" RFC、BCP 76 3666、2003年12月。
[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]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロを、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、2004年4月。
[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]マーイ、R.、ら、進歩、2006年3月に仕事「セッション開始プロトコル（SIP）のための呼制御とマルチパーティの使用フレームワーク」。
[21] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", Work in Progress, October 2005.
[21]ジョンストン、A.、およびO.レヴィン、「セッション開始プロトコル呼制御 - ユーザエージェントのための会議」、進歩、2005年10月に作業。
[22] Even, R. and N. Ismail, "Conferencing Scenarios", Work in Progress, September 2005.
[22]でも、R.とN.イスマイル、 "会議のシナリオ"、進歩、2005年9月での作業。
[23] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[23]ヘルストローム、G.とP.ジョーンズ、 "テキストの会話のための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]キャンベル、B.、ローゼンバーグ、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]ローゼンバーグ、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]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[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.ローゼンバーグ、 "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.ポーク、 "セッション開始プロトコル（SIP）のための通信リソースプライオリティ"、RFC 4412、2006年2月。
[30] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", Work in Progress, July 2005.
[30]ポーク、J.およびB.ローゼン、「セッション開始プロトコル場所搬送」、進歩、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]チャールトン、N.、Gasson、M.、Gybels、G.、スパナ、M.、およびA.バンWijk、「セッション開始プロトコル（SIP）のためのユーザ要件ろう、難聴や音声のサポートに-impaired個人」、RFC 3351、2002年8月。
[32] van Wijk, A., "Framework of requirements for real-time text conversation using SIP", Work in Progress, September 2005.
[32]バン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.、フレデリック、R.、およびV.ヤコブソン、 "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]フリードマン、T.、カセレス、R.、およびA.クラーク、 "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]ダークス、T.とC.アレン、 "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.、ベーカー、F.、ワイス、W.、及びJ. Wroclawski、 "保証転送PHBグループ"、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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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]アンダーセン、S.、Duric、A.、Astrom、H.、ハーゲン、R.、Kleijn、W.、及びJ.リンデン、 "インターネット低ビットレートコーデック（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.とS.アンデルセン、 "インターネット低ビットレートコーデック（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.、ら。、 "Speexのコーデックのための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、 "PCMデジタル有線電話オーバーIPとボイスオーバー狭帯域音声の伝送要件"、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]翼、D.、進歩、2004年10月に作品、 "対称RTPとRTCPは参考考慮しました"。
[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]ローゼンバーグ、J.、ワインバーガー、J.、のHuitema、C.、およびR.マーイ、 - 2003年3月、RFC 3489 "STUNネットワークを介して、ユーザーデータグラムプロトコル（UDP）の簡単なトラバーサルは、翻訳者（NATのを）アドレス"。
[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]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための方法論」、進歩、2005年7月での作業。
[51] Boulton, C. and J. Rosenberg, "Best Current Practices for NAT Traversal for SIP", Work in Progress, October 2005.
[51]ボールトン、C.とJ.ローゼンバーグ、「SIP用NATトラバーサルのためのベストプラクティスの現在」、進歩、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]キャンベル、B.及びR.スパークス、RFC 3087、2001年4月 "SIP要求URIを使用して、サービス・コンテキストの制御"。
[54] Mahy, R., "Connection Reuse in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
[54]マーイ、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]ジェニングス、C.とR.マーイ、進歩、2006年3月に仕事「セッション開始プロトコルのクライアント開始された接続の管理」を参照してください。
[56] Petrie, D., "A Framework for SIP User Agent Profile Delivery", Work in Progress, July 2005.
[56]ペトリー、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]ジェニングス、C.、 "SIPのチュートリアル：SIPセキュリティ"、VON 2004年春の会議で発表され、2004年3月29日、カリフォルニア州サンタクララ
[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]ジェニングス、C.、ピーターソン、J.、およびM.ワトソン、 "信頼できるネットワーク内のアサート・アイデンティティのためのセッション開始プロトコル（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.、フォード、W.、Sabett、R.、メリル、C.、およびS.ウー、 "インターネット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]ジェニングス、C.とJ.ピーターソン、「セッション開始プロトコル（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.、 "/セキュア多目的インターネットメール拡張（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.、マグリュー、D.、Naslund、M.、カララ、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.ジェニングス、 "ユニキャストUDPのNATの行動の要件"、進歩、2005年9月に作業。
[64] Jennings, C., "Example call flows using SIP security mechanisms", Work in Progress, February 2006.
[64]ジェニングス、C.、進歩、2006年2月に、ワーク「の例コールはSIPのセキュリティメカニズムを使用して流れ」。
[65] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[65]ピーターソン、J.、 "セッション開始プロトコル（SIP）認証済みアイデンティティボディ（AIB）フォーマット"、RFC 3893、2004年9月。
Author's Addresses
著者のアドレス
Henry Sinnreich Pulver.com 115 Broadhollow Road Melville, NY 11747, USA
ヘンリーSinnreich Pulver.com 115 Broadhollow道路メルヴィル、NY 11747、USA
EMail: henry@pulver.com Phone: +1-631-961-8950
メールアドレス：henry@pulver.com電話：+ 1-631-961-8950
Steven Lass Verizon 1201 East Arapaho Road Richardson, TX 75081, USA
スティーブン・ラスベライゾン1201東アラパホー・ロード・リチャードソン、TX 75081、USA
EMail: steven.lass@verizonbusiness.com Phone: +1-972-728-2363
メールアドレス：steven.lass@verizonbusiness.com電話：+ 1-972-728-2363
Christian Stredicke snom technology AG Gradestrasse, 46 D-12347 Berlin, Germany
クリスチャンstředičkaのSNOM技術AG Gradestrasse、46 D-12347ベルリン、ドイツ
EMail: cs@snom.de Phone: +49(30)39833-0
メールアドレス：cs@snom.de電話：+49（30）39833から0
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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）によって提供されます。