Network Working Group H. Sinnreich, Ed.
Request for Comments: 4504 pulver.com
Category: Informational S. Lass
Verizon
C. Stredicke
snom
May 2006
Network Working Group H. Sinnreich, Ed.
Request for Comments: 4504 pulver.com
Category: Informational S. Lass
Verizon
C. Stredicke
snom
May 2006
SIP Telephony Device Requirements and Configuration
SIP电话设备要求和配置
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（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电话设备的要求。这些要求的目标是一套定义良好的互操作性和多供应商支持的核心功能，以便实现与PC、PDA、模拟功能电话或移动电话类似的易于购买、安装和操作。
We present a glossary of the most common settings and some of the more widely used values for some settings.
我们提供了最常见设置的词汇表，以及一些设置中更广泛使用的值。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions used in this document ..........................4
2. Generic Requirements ............................................4
2.1. SIP Telephony Devices ......................................4
2.2. DNS and ENUM Support .......................................5
2.3. SIP Device Resident Telephony Features .....................5
2.4. Support for SIP Services ...................................8
2.5. Basic Telephony and Presence Information Support ...........9
2.6. Emergency and Resource Priority Support ....................9
2.7. Multi-Line Requirements ...................................10
2.8. User Mobility .............................................11
2.9. Interactive Text Support ..................................11
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
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电话设备，也称为SIP用户代理（UAs），可以是为基于SIP的IP电话启用的任何类型的IP网络计算用户设备。SIP电话用户设备可以是SIP电话、模拟电话和传真机的适配器、会议扬声器、运行在PC、笔记本电脑、无线连接PDA、“Wi-Fi”SIP移动电话上的软件包（软客户端）、以及支持实时通信SIP信令的其他移动和无绳电话。SIP-PSTN网关不是本备忘录的目标，因为它们是网络元素，而不是最终用户设备。
SIP telephony devices can also be instant messaging (IM) applications that have a telephony option.
SIP电话设备也可以是具有电话选项的即时消息（IM）应用程序。
SIP devices MAY support various other media besides voice, such as text, video, games, and other Internet applications; however, the non-voice requirements are not specified in this document, except when providing enhanced telephony features.
SIP设备可以支持语音以外的各种其他媒体，例如文本、视频、游戏和其他互联网应用；但是，本文件未规定非语音要求，除非提供增强的电话功能。
SIP telephony devices are highly complex IP endpoints that speak many Internet protocols, have audio and visual interfaces, and require functionality targeted at several constituencies: (1) end users, (2) service providers and network administrators, (3) manufacturers, and (4) system integrators.
SIP电话设备是高度复杂的IP端点，使用多种互联网协议，具有音频和视频接口，并且需要针对多个用户群体的功能：（1）最终用户，（2）服务提供商和网络管理员，（3）制造商和（4）系统集成商。
The objectives of the requirements are a well-defined set of interoperability and multi-vendor-supported core features, so as to enable similar ease of purchase, installation, and operation as found for standard PCs, analog feature phones, or mobile phones. Given the cost of some feature-rich display phones may approach the cost of PCs and PDAs, similar or even better ease of use as compared to personal computers and networked PDAs is expected by both end users and network administrators.
这些要求的目标是一套定义良好的互操作性和多供应商支持的核心功能，以便实现与标准PC、模拟功能电话或移动电话类似的易于购买、安装和操作。考虑到某些功能丰富的显示手机的成本可能接近PC和PDA的成本，最终用户和网络管理员都希望与个人电脑和联网PDA相比具有类似甚至更好的易用性。
While some of the recommendations of this document go beyond what is currently mandated for SIP implementations within the IETF, this is believed necessary to support the specified operational objectives.
虽然本文件中的一些建议超出了IETF中目前对SIP实施的要求，但人们认为这对于支持指定的操作目标是必要的。
However, it is also important to keep in mind that the SIP specifications are constantly evolving; thus, these recommendations need to be considered in the context of that change and evolution. Due to the evolution of IETF documents in the standards process, and the informational nature of this memo, the references are all informative.
然而，同样重要的是要记住，SIP规范是不断发展的；因此，这些建议需要在这种变化和演变的背景下加以考虑。由于IETF文件在标准过程中的演变，以及本备忘录的信息性，参考文件均为信息性文件。
This document is informational and therefore the key words "MUST", "SHOULD", "SHOULD NOT", and "MAY", in this document are not to be interpreted as described in RFC 2119 [1], but rather indicate the nature of the suggested requirement.
本文件仅供参考，因此，本文件中的关键词“必须”、“应该”、“不应该”和“可能”不应按照RFC 2119[1]中所述进行解释，而应表明建议要求的性质。
We present here a minimal set of requirements that MUST be met by all SIP [2] telephony devices, except where SHOULD or MAY is specified.
我们在这里提出了所有SIP[2]电话设备必须满足的最低要求集，除非指定了应该或可能。
This memo applies mainly to desktop phones and other special purpose SIP telephony hardware. Some of the requirements in this section are not applicable to PC/laptop or PDA software phones (soft phones) and mobile phones.
本备忘录主要适用于台式电话和其他专用SIP电话硬件。本节中的一些要求不适用于PC/笔记本电脑或PDA软件电话（软电话）和移动电话。
Req-1: SIP telephony devices MUST be able to acquire IP network settings by automatic configuration using Dynamic Host Configuration Protocol (DHCP) [3].
Req-1:SIP电话设备必须能够通过使用动态主机配置协议（DHCP）进行自动配置来获取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电话设备必须支持RFC 3263[5]以定位SIP服务器并选择传输协议。
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解析程序，可配置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电话设备可能支持枚举[6]。注意：枚举解析器也可以放置在传出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电话设备应通过使用反映隐私要求和偏好的值填充报头来支持SIP隐私报头，如RFC 3323[7]第4节“用户代理行为”所述。
Req-14: SIP telephony devices MUST be able to place an existing call on hold, and initiate or receive another call, as specified in RFC 3264 [8] and SHOULD NOT omit the sendrecv attribute.
Req-14:SIP电话设备必须能够按照RFC 3264[8]中的规定，将现有呼叫置于保留状态，并启动或接收另一个呼叫，并且不应忽略sendrecv属性。
Req-15: SIP telephony devices MUST provide a call waiting indicator. When participating in a call, the user MUST be alerted audibly and/or visually of another incoming call. The user MUST be able to enable/disable the call waiting indicator.
Req-15:SIP电话设备必须提供呼叫等待指示器。参与通话时，必须以声音和/或视觉方式提醒用户另一个来电。用户必须能够启用/禁用呼叫等待指示器。
Req-16: SIP telephony devices MUST support SIP message waiting [9] and the integration with message store platforms.
Req-16:SIP电话设备必须支持SIP消息等待[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;user=phone
sips:+12125551234@example.net;user=phone
sip:5551234@example.net
sips:5551234@example.net
tel:5551234;phone-context=nyc1.example.net
sip:5551234;phone-
context=nyc1.example.net@example.net;user=phone
sips:5551234;phone-
context=nyc1.example.net@example.net;user=phone
sip:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sips:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
tel:5551234;phone-context=+1212
sip:5551234;phone-context=+1212@example.net;user=phone
sips:5551234;phone-context=+1212@example.net;user=phone
sip:5551234;phone-context=+1212@example.net;user=dialstring
sips:5551234;phone-context=+1212@example.net;user=dialstring
If a local dial plan is not supported, the device SHOULD be configurable to generate any of the following URIs when "5551234" is dialed:
如果不支持本地拨号计划，则设备应可配置为在拨打“5551234”时生成以下任何URI：
sip:5551234@example.net
sips:5551234@example.net
sip:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sips:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sip:5551234;phone-context=+1212@example.net;user=dialstring
sips:5551234;phone-context=+1212@example.net;user=dialstring"
sip:5551234@example.net
sips:5551234@example.net
sip:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sips:5551234;phone-
context=nyc1.example.net@example.net;user=dialstring
sip:5551234;phone-context=+1212@example.net;user=dialstring
sips:5551234;phone-context=+1212@example.net;user=dialstring"
Req-18: SIP telephony devices MUST support URIs for telephone numbers as per RFC 3966 [10]. This includes the reception as well as the sending of requests. The reception may be denied according to the configurable security policy of the device. It is a reasonable behavior to send a request to a preconfigured outbound proxy.
Req-18:SIP电话设备必须根据RFC 3966[10]支持电话号码的URI。这包括接收和发送请求。根据设备的可配置安全策略，可以拒绝接收。向预配置的出站代理发送请求是合理的行为。
Req-19: SIP telephony devices MUST support REFER and NOTIFY for call transfer [11], [12]. SIP telephony devices MUST support escaped Replaces-Header (RFC 3891) and SHOULD support other escaped headers in the Refer-To header.
Req-19:SIP电话设备必须支持呼叫转移的参考和通知[11]，[12]。SIP电话设备必须支持转义替换报头（RFC 3891），并应支持引用报头中的其他转义报头。
Req-20: SIP telephony devices MUST support the unattended call transfer flows as defined in [12].
Req-20:SIP电话设备必须支持[12]中定义的无人值守呼叫转移流。
Req-21: SIP telephony devices MUST support the attended call transfer as defined in [12].
Req-21:SIP电话设备必须支持[12]中定义的有人值守呼叫转移。
Req-22: SIP telephony devices MAY support device-based 3-way calling by mixing the audio streams and displaying the interactive text of at least 2 separate calls.
Req-22:SIP电话设备可以通过混合音频流和显示至少2个单独呼叫的交互文本来支持基于设备的3路呼叫。
Req-23: SIP telephony devices MUST be able to send dual-tone multi-frequency (DTMF) named telephone events as specified by RFC 2833 [13].
Req-23:SIP电话设备必须能够发送RFC 2833[13]规定的双音多频（DTMF）命名电话事件。
Req-24: Payload type negotiation MUST comply with RFC 3264 [8] and with the registered MIME types for RTP payload formats in RFC 3555 [14].
Req-24：有效负载类型协商必须符合RFC 3264[8]和RFC 3555[14]中RTP有效负载格式的注册MIME类型。
Req-25: The dynamic payload type MUST remain constant throughout the session. For example, if an endpoint decides to renegotiate codecs or put the call on hold, the payload type for the re-invite MUST be the same as the initial payload type. SIP devices MAY support Flow Identification as defined in RFC 3388 [15].
Req-25：动态有效负载类型必须在整个会话期间保持不变。例如，如果端点决定重新协商编解码器或暂停呼叫，则重新邀请的有效负载类型必须与初始有效负载类型相同。SIP设备可支持RFC 3388[15]中定义的流标识。
Req-26: When acting as a User Agent Client (UAC), SIP telephony devices SHOULD support the gateway model of RFC 3960 [16]. When acting as a User Agent Server (UAS), SIP telephony devices SHOULD NOT send early media.
Req-26：当充当用户代理客户端（UAC）时，SIP电话设备应支持RFC 3960的网关模型[16]。当充当用户代理服务器（UAS）时，SIP电话设备不应发送早期媒体。
Req-27: SIP telephony devices MUST be able to handle multiple early dialogs in the context of request forking. When a confirmed dialog has been established, it is an acceptable behavior to send a BYE request in response to additional 2xx responses that establish additional confirmed dialogs.
Req-27:SIP电话设备必须能够在请求分叉的上下文中处理多个早期对话框。建立确认对话框后，发送BYE请求以响应建立额外确认对话框的额外2xx响应是可接受的行为。
Req-28: SIP devices with a suitable display SHOULD support the call-info header and depending on the display capabilities MAY, for example, display an icon or the image of the caller.
Req-28：具有适当显示器的SIP设备应支持call info报头，并且根据显示能力，例如，可显示呼叫者的图标或图像。
Req-29: To provide additional information about call failures, SIP telephony devices with a suitable display MUST render the "Reason Phrase" of the SIP message or map the "Status Code" to custom or default messages. This presumes the language for the reason phrase is the same as the negotiated language. The devices MAY use an internal "Status Code" table if there was a problem with the language negotiation.
Req-29：为了提供关于呼叫失败的附加信息，具有适当显示的SIP电话设备必须呈现SIP消息的“原因短语”，或将“状态代码”映射到自定义或默认消息。这假定原因短语的语言与协商语言相同。如果语言协商出现问题，设备可能会使用内部“状态代码”表。
Req-30: SIP telephony devices MAY support music on hold, both in receive mode and locally generated. See also "SIP Service Examples" for a call flow with music on hold [17].
Req-30:SIP电话设备可以在接收模式和本地生成模式下支持保留音乐。另请参见“SIP服务示例”，了解音乐处于保留状态的呼叫流[17]。
Req-31: SIP telephony devices MAY ring after a call has been on hold for a predetermined period of time, typically 3 minutes.
Req-31：SIP电话设备可能在呼叫被保持预定时间段（通常为3分钟）后响起。
Req-32: SIP telephony devices MUST support the SIP Basic Call Flow Examples as per RFC 3665 [17].
Req-32:SIP电话设备必须支持RFC 3665[17]规定的SIP基本呼叫流示例。
Req-33: SIP telephony devices MUST support the SIP-PSTN Service Examples as per RFC 3666 [18].
Req-33:SIP电话设备必须支持RFC 3666[18]规定的SIP-PSTN服务示例。
Req-34: SIP telephony devices MUST support the Third Party Call Control model [19], in the sense that they may be the controlled device.
Req-34:SIP电话设备必须支持第三方呼叫控制模型[19]，因为它们可能是受控设备。
Req-35: SIP telephony devices SHOULD support SIP call control and multi-party usage [20].
Req-35:SIP电话设备应支持SIP呼叫控制和多方使用[20]。
Req-36: SIP telephony devices SHOULD support conferencing services for voice [21], [22] and interactive text [23] and if equipped with an adequate display MAY also support instant messaging (IM) and presence [24], [25].
Req-36:SIP电话设备应支持语音[21]、[22]和交互式文本[23]的会议服务，如果配备适当的显示器，还可支持即时消息（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电话设备应支持状态信息[24]，并应支持状态信息启用的新IP通信服务的丰富状态信息数据格式[27]。
Req-40: Users MUST be able to set the state of the SIP telephony device to "Do Not Disturb", and this MAY be manifested as a Presence state across the network if the UA can support Presence information.
Req-40：用户必须能够将SIP电话设备的状态设置为“请勿打扰”，如果UA能够支持状态信息，则这可能表现为网络中的状态。
Req-41: SIP telephony devices with "Do Not Disturb" enabled MUST respond to new sessions with "486 Busy Here".
Req-41：启用“请勿打扰”的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工作组的工作[28]。
Req-43: Priority header: SIP devices SHOULD support the setting by the user of the Priority header specified in RFC 3261 for such applications as emergency calls or for selective call acceptance.
Req-43：优先级报头：SIP设备应支持用户设置RFC 3261中指定的优先级报头，用于紧急呼叫或选择性呼叫接受等应用。
Req-44: Resource Priority header: SIP telephony devices that are used in environments that support emergency preparedness MUST also support the sending and receiving of the Resource-Priority header as specified in [29]. The Resource Priority header influences the behavior for message routing in SIP proxies and PSTN telephony gateways and is different from the SIP Priority header specified in RFC 3261. Users of SIP telephony devices may want to be interrupted in their lower-priority communications activities if such an emergency communication request arrives.
Req-44：资源优先级报头：在支持应急准备的环境中使用的SIP电话设备也必须支持[29]中规定的资源优先级报头的发送和接收。资源优先级头影响SIP代理和PSTN电话网关中消息路由的行为，并且不同于RFC 3261中指定的SIP优先级头。如果这种紧急通信请求到达，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]。
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电话设备可以有多条线路：一个SIP电话设备可以与来自不同服务提供商的不同SIP注册器同时注册，为每条线路使用不同的名称和凭证。不同的名称和凭据集也称为“SIP帐户”。“线路”术语借用自多线路PSTN/PBX电话，但对于SIP电话设备，每条线路可以有不同的SIP注册器/代理，其中每一个都可能属于不同的服务提供商，而这对于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帐户通常可以支持不同的记录地址（AOR）和不同的联系人地址列表（CA），这可能是方便的，例如，在业务和个人使用不同的SIP帐户时。然而，不同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电话设备必须支持为每条线路提供的唯一认证用户名、认证密码、注册器和标识。认证用户名可以与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.
支持基于简单[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电话设备应提供通过任何合理方法输入文本和显示文本的方法。内置用户界面、标准有线或无线界面和/或通过web界面支持文本都被认为是合理的机制。
Req-54: SIP telephony devices SHOULD provide an external standard wired or wireless link to connect external input (keyboard, mouse) and display devices.
Req-54:SIP电话设备应提供外部标准有线或无线链路，以连接外部输入（键盘、鼠标）和显示设备。
Req-55: SIP telephony devices that include a display, or have a facility for connecting an external display, MUST include protocol support as described in RFC 4103 [23] for real-time interactive text.
Req-55：包含显示器或具有连接外部显示器的设施的SIP电话设备必须包括RFC 4103[23]中所述的实时交互式文本协议支持。
Req-56: There may be value in having RFC 4103 support in a terminal also without a visual display. A synthetic voice output for the text conversation may be of value for all who can hear, and thereby provides the opportunity to have a text conversation with other users.
Req-56：在没有视觉显示的终端中支持RFC 4103可能有价值。文本对话的合成语音输出可能对所有能听到的人都有价值，从而提供与其他用户进行文本对话的机会。
Req-57: SIP telephony devices MAY provide analog adaptor functionality through an RJ-11 FXS port to support FXS devices. If an RJ-11 (FXS) port is provided, then it MAY support a gateway function from all text-telephone protocols according to ITU-T Recommendation V.18 to RFC 4103 text conversation (in fact, this is encouraged in the near term during the transition to widespread use of SIP telephony devices). If this gateway function is not included or fails, the device MUST pass through all text-telephone protocols according to ITU-T Recommendation V.18, November 2000, in a transparent fashion.
Req-57:SIP电话设备可通过RJ-11 FXS端口提供模拟适配器功能，以支持FXS设备。如果提供了RJ-11（FXS）端口，则根据ITU-T建议V.18至RFC 4103文本对话，它可能支持所有文本电话协议的网关功能（事实上，在向广泛使用SIP电话设备过渡的近期内，鼓励这样做）。如果未包括此网关功能或出现故障，则设备必须按照ITU-T建议V.18（2000年11月）以透明方式通过所有文本电话协议。
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电话设备可在便携式SIP设备（如PDA和各种无线SIP电话）中提供2.5 mm音频端口。
Req-59: SIP telephony devices MUST support the Real-Time Protocol and the Real-Time Control Protocol, RFC 3550 [33]. SIP devices SHOULD use RTCP Extended Reports for logging and reporting on network support for voice quality, RFC 3611 [34] and MAY also support the RTCP summary report delivery [35].
Req-59:SIP电话设备必须支持实时协议和实时控制协议RFC 3550[33]。SIP设备应使用RTCP扩展报告记录和报告语音质量的网络支持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电话设备必须根据RFC 3261支持摘要认证。此外，SIP电话设备必须支持用于安全传输的传输层安全性（TLS）[36]，用于SIP注册器位于SIP UA可能驻留的安全私有IP网络之外的场景。注意：不过，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的用户部分为空或与配置的联系人不匹配时拒绝传入邀请的选项。这可以防止战争拨号攻击、不必要的电话营销和垃圾邮件。拒绝的设置必须是可配置的。
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地址的邀请。
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：根据RFC 2597[37]，SIP设备必须支持RTP流的IPv4区分服务代码点（DSCP）字段。DSCP设置必须可配置，以符合本地网络策略。
Req-67: If not specifically provisioned, SIP telephony devices SHOULD mark RTP packets with the recommended DSCP for expedited forwarding (codepoint 101110) and mark SIP packets with DSCP AF31 (codepoint 011010).
Req-67：如果没有特别规定，SIP电话设备应使用推荐的DSCP标记RTP数据包以进行快速转发（代码点101110），并使用DSCP AF31标记SIP数据包（代码点011010）。
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:
然而，对短列表感兴趣的实现者可以支持在有线IP语音（VoIP）中使用的最少数量的编解码器，以及SIP-UA所针对的移动网络中的编解码器。有序的首选项短列表可能如下所示：
Req-71: SIP telephony devices SHOULD support Audio/Video Transport (AVT) payload type 0 (G.711 uLaw) as in [40] and its Annexes 1 and 2.
Req-71:SIP电话设备应支持[40]及其附件1和2中的音频/视频传输（AVT）有效载荷类型0（G.711 uLaw）。
Req-72: SIP telephony devices SHOULD support the Internet Low Bit Rate codec (iLBC) [41], [42].
Req-72:SIP电话设备应支持互联网低比特率编解码器（iLBC）[41]，[42]。
Req-73: Mobile SIP telephony devices MAY support codecs found in various wireless mobile networks. This can avoid codec conversion in network-based intermediaries.
Req-73：移动SIP电话设备可能支持各种无线移动网络中的编解码器。这可以避免在基于网络的中介中进行编解码器转换。
Req-74: SIP telephony devices MAY support a small set of special purpose codecs, such as G.723.1, where low bandwidth usage is needed (for dial-up Internet access), Speex [43], or G.722 for high-quality audio conferences.
Req-74:SIP电话设备可能支持一小部分专用编解码器，如G.723.1，其中需要低带宽使用（用于拨号互联网接入）、Speex[43]或G.722，用于高质量音频会议。
Req-75: SIP telephony devices MAY support G.729 and its annexes. Note: The G.729 codec is included here for backward compatibility only, since the iLBC and the G.723.1 codecs are preferable in bandwidth-constrained environments.
Req-75:SIP电话设备可支持G.729及其附件。注：此处包含G.729编解码器仅用于向后兼容，因为iLBC和G.723.1编解码器在带宽受限的环境中更可取。
Note: The authors believe the Internet Low Bit Rate codec (iLBC) should be the default codec for Internet telephony.
注：作者认为互联网低比特率编解码器（iLBC）应该是互联网电话的默认编解码器。
A summary count reveals up to 25 and more voice codec types currently in use. The authors believe there is also a need for a single multi-rate Internet codec, such as Speex or similar that can effectively be substituted for all of the multiple legacy G.7xx codec types, such as G.711, G.729, G.723.1, G.722, etc., for various data rates, thus avoiding the complexity and cost to implementers and service providers alike who are burdened by supporting so many codec types, besides the licensing costs.
摘要计数显示当前使用的语音编解码器类型多达25种或更多。作者认为，还需要一个单一的多速率互联网编解码器，如Speex或类似产品，可以有效地替代各种数据速率的所有传统G.7xx编解码器类型，如G.711、G.729、G.723.1、G.722等，这样就避免了实现者和服务提供者的复杂性和成本，他们除了许可成本外，还承受着支持这么多编解码器类型的负担。
Req-76: SIP telephony devices SHOULD comply with the handset receive comfort noise requirements outlined in the ANSI standards [44], [45].
Req-76:SIP电话设备应符合ANSI标准[44]、[45]中概述的手机接收舒适性噪音要求。
Req-77: SIP telephony devices SHOULD comply with the stability or minimum loss defined in ITU-T G.177.
Req-77:SIP电话设备应符合ITU-T G.177中规定的稳定性或最小损耗。
Req-78: SIP telephony devices MAY support a full-duplex speakerphone function with echo and side tone cancellation. The design of high-quality side tone cancellation for desktop IP phones, laptop computers, and PDAs is outside the scope of this memo.
Req-78:SIP电话设备可支持带有回声和侧音消除的全双工扬声器功能。台式IP电话、笔记本电脑和PDA的高质量侧音消除设计不在本备忘录范围内。
Req-79: SIP telephony device MAY support different ring tones based on the caller identity.
Req-79:SIP电话设备可能支持基于呼叫者身份的不同铃声。
Req-80: SIP telephony devices SHOULD indicate the preferred language [46] using User Agent capabilities [26].
Req-80:SIP电话设备应使用用户代理功能[26]指示首选语言[46]。
Req-81: SIP telephony devices intended to be used in various language settings MUST support other languages for menus, help, and labels.
Req-81：用于各种语言设置的SIP电话设备必须支持菜单、帮助和标签的其他语言。
The following requirements apply to functions placed in the SIP telephony device.
以下要求适用于SIP电话设备中的功能。
Req-82: SIP telephony devices that have a large display and support presence SHOULD display a buddy list [24].
Req-82：具有大屏幕和支持状态的SIP电话设备应显示好友列表[24]。
Req-83: SIP telephony devices MAY support Lightweight Directory Access Protocol (LDAP) for client-based directory lookup.
Req-83:SIP电话设备可能支持用于基于客户端的目录查找的轻量级目录访问协议（LDAP）。
Req-84: SIP telephony devices MAY support a phone setup where a URL is automatically dialed when the phone goes off-hook.
Req-84:SIP电话设备可能支持电话设置，当电话挂断时自动拨打URL。
Req-85: SIP telephony devices SHOULD support an internal web server to allow users the option to manually configure the phone and to set up personal phone applications such as the address book, speed-dial, ring tones, and, last but not least, the call handling options for the various lines and aliases, in a user-friendly fashion. Web pages to manage the SIP telephony device SHOULD be supported by the individual device, or MAY be supported in managed networks from centralized web servers linked from a URI.
Req-85:SIP电话设备应支持内部web服务器，以允许用户选择手动配置电话，并以用户友好的方式设置个人电话应用程序，如地址簿、快速拨号、铃声，以及最后但并非最不重要的各种线路和别名的呼叫处理选项。用于管理SIP电话设备的网页应由单个设备支持，或者在由URI链接的集中式Web服务器管理的网络中支持。
Managing SIP telephony devices SHOULD NOT require special client software on the PC or require a dedicated management console. SIP telephony devices SHOULD support https transport for this purpose.
管理SIP电话设备不需要在PC上安装特殊的客户端软件，也不需要专用的管理控制台。为此，SIP电话设备应支持https传输。
In addition to the Web Based Feature Management requirement, the device MAY have an SNMP interface for monitoring and management purposes.
除了基于Web的功能管理要求外，设备还可能具有用于监视和管理目的的SNMP接口。
The following requirements allow SIP clients to properly function behind various firewall architectures.
以下要求允许SIP客户端在各种防火墙体系结构之后正常工作。
Req-86: SIP telephony devices SHOULD be able to operate behind a static Network Address Translation/Port Address Translation (NAPT) device. This implies the SIP telephony device SHOULD be able to 1) populate SIP messages with the public, external address of the NAPT device; 2) use symmetric UDP or TCP for signaling; and 3) use symmetric RTP [47].
Req-86:SIP电话设备应能够在静态网络地址转换/端口地址转换（NAPT）设备后面运行。1）设备的外部SIP地址应能填充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电话设备应支持通过NATs（STUN）协议[48]简单遍历UDP，以确定NAPT公共外部地址。[49]中报告了STUN有效的场景和NAT分类。[51]中给出了交互式连接建立（ICE）[50]的详细呼叫流。
Note: Developers are strongly advised to follow the document on best current practices for NAT traversal for SIP [51].
注意：强烈建议开发人员遵循关于SIP NAT遍历最佳当前实践的文档[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电话设备可支持UPnP(http://www.upnp.org/)用于本地NAPT遍历。请注意，如果服务提供商的网络中存在NAPT，则UPnP没有帮助。
Req-89: SIP telephony devices MUST be able to limit the ports used for RTP to a provisioned range.
Req-89:SIP电话设备必须能够将RTP使用的端口限制在规定的范围内。
Req-90: SIP telephony devices MUST support two types of addressing capabilities, to enable end users to "dial" either phone numbers or URIs.
Req-90:SIP电话设备必须支持两种类型的寻址功能，以使最终用户能够“拨号”电话号码或URI。
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和电话号码的方便方式。这包括合法SIPURI中允许的所有字母数字字符。可能的方法包括为PDA使用网页、显示器和键盘输入、提前键入或涂鸦。
Req-93: SIP telephony devices should allow phone number entry in human-friendly fashion, with the usual separators and brackets between digits and digit groups.
Req-93:SIP电话设备应允许以人性化的方式输入电话号码，在数字和数字组之间使用常用的分隔符和括号。
SIP telephony devices are quite complex, and their configuration is made more difficult by the widely diverse use of technical terms for the settings. We present here a glossary of the most common settings and some of the more widely used values for some settings.
SIP电话设备相当复杂，由于设置中技术术语的广泛使用，使得它们的配置更加困难。我们在这里提供了最常见设置的词汇表，以及一些设置中更广泛使用的值。
Settings are the information on a SIP UA that it needs so as to be a functional SIP endpoint. The settings defined in this document are not intended to be a complete listing of all possible settings. It MUST be possible to add vendor-specific settings.
设置是SIP UA作为功能性SIP端点所需的信息。本文档中定义的设置不是所有可能设置的完整列表。必须能够添加特定于供应商的设置。
The list of available settings includes settings that MUST, SHOULD, or MAY be used by all devices (when present) and that make up the common denominator that is used and understood by all devices. However, the list is open to vendor-specific extensions that support additional settings, which enable a rich and valuable set of features.
可用设置列表包括所有设备（如果存在）必须、应该或可能使用的设置，以及构成所有设备使用和理解的公共分母的设置。但是，该列表对支持其他设置的特定于供应商的扩展开放，这些设置支持丰富而有价值的功能集。
Settings MAY be read-only on the device. This avoids the misconfiguration of important settings by inexperienced users generating service cost for operators. The settings provisioning process SHOULD indicate which settings can be changed by the end user and which settings should be protected.
设备上的设置可能是只读的。这避免了缺乏经验的用户对重要设置的错误配置，从而为运营商带来服务成本。设置设置设置过程应指明最终用户可以更改哪些设置以及应保护哪些设置。
In order to achieve wide adoption of any settings format, it is important that it should not be excessive in size for modest devices to use it. Any format SHOULD be structured enough to allow flexible extensions to it by vendors. Settings may belong to the device or to a SIP service provider and the Address of Record (AOR) registered there. When the device acts in the context of an AOR, it will first try to look up a setting in the AOR context. If the setting cannot be found in that context, the device will try to find the setting in the device context. If that also fails, the device MAY use a default value for the setting.
为了实现任何设置格式的广泛采用，重要的是它的大小不应过大，以便普通设备使用。任何格式的结构都应足以允许供应商对其进行灵活的扩展。设置可能属于设备或SIP服务提供商，并且记录地址（AOR）在其中注册。当设备在AOR上下文中运行时，它将首先尝试在AOR上下文中查找设置。如果在该上下文中找不到该设置，设备将尝试在设备上下文中查找该设置。如果同样失败，设备可能会使用默认值进行设置。
The examples shown here are just of informational nature. Other documents may specify the syntax and semantics for the respective settings.
这里显示的示例只是信息性的。其他文档可能会指定相应设置的语法和语义。
A device setting MAY include some unique identifier for the device it represents. This MAY be an arbitrary device name chosen by the user, the MAC address, some manufacturer serial number, or some other unique piece of data. The Device ID SHOULD also indicate the ID type. Example: DeviceId="000413100A10;type=MAC"
设备设置可以包括它所代表的设备的一些唯一标识符。这可能是用户选择的任意设备名称、MAC地址、某些制造商序列号或某些其他唯一数据段。设备ID还应指示ID类型。示例：DeviceId=“000413100A10；类型=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"
For both categories of network traffic, the device SHOULD permit
configuration of the type of service settings for both layer 3 (IP
DiffServ) and layer 2 (for example, IEEE 802.1D/Q) of the network
protocol stack.
Example: RTPQoS="0xA0;type=DiffSrv,5;type=802.1DQ;vlan=324"
All of the call handling settings defined below can be defined here as default behaviors.
下面定义的所有呼叫处理设置都可以在此处定义为默认行为。
The outbound proxy for a device MAY be set. The setting MAY require that all signaling packets MUST be sent to the outbound proxy or that only in the case when no route has been received the outbound proxy MUST be used. This ensures that application layer gateways are in
可以设置设备的出站代理。该设置可能要求必须将所有信令包发送到出站代理，或者仅在没有收到路由的情况下，必须使用出站代理。这确保了应用层网关处于可用状态
the signaling path. The second requirement allows the optimization of the routing by the outbound proxy. Example: OutboundProxy="sip:nat.proxy.com"
信令路径。第二个要求允许通过出站代理优化路由。示例：OutboundProxy=“sip:nat.proxy.com”
The default outbound proxy SHOULD be a global setting (not related to a specific line). Example: DefaultProxy="sip:123@proxy.com"
默认出站代理应为全局设置（与特定行无关）。示例：DefaultProxy=“sip:123@proxy.com"
The re-invite timer allows User Agents to detect broken sessions caused by network failures. A value indicating the number of seconds for the next re-invite SHOULD be used if provided. Example: SessionTimer="600;unit=seconds"
重新邀请计时器允许用户代理检测由网络故障导致的中断会话。如果提供，则应使用指示下次重新邀请的秒数的值。示例：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）从拨号数字构造URI的规则，以及可选的3）用于路由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
如果拨号计划包含T（计时器）字符，则可提供关键计时器，用于确定设备在拨号前应等待多长时间。如果用户输入的数字不正确，它还可以为拨号前应经过的最长时间提供计时器
match no dial plan. If the UA has a Dial or OK key, pressing this key will override the timer setting.
不匹配拨号计划。如果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电话设备应具有拨号/确认键。发送请求后，UA应准备接收484地址不完整的响应。在这种情况下，UA应该接受更多的用户输入，并再次尝试拨打该号码。
An example digit map could use regular expressions like in DNS NAPTR (RFC 2915) to translate user input into a SIP URL. Additional replacement patterns like "d" could insert the domain name of the used AOR. Additional parameters could be inserted in the flags portion of the substitution expression. A list of those patterns would make up the dial plan:
例如，数字映射可以使用DNS NAPTR（RFC 2915）中的正则表达式将用户输入转换为SIP URL。其他替换模式，如“d”，可以插入所用AOR的域名。可以在替换表达式的标志部分插入其他参数。这些模式的列表将构成拨号计划：
|^([0-9]*)#$|sip:\1@\d;user=phone|outbound=proxy.com
|^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|sip:\1|
|^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+)$|sip:\1@\d|
|^(.*)$|sip:\1@\d|timeout=5
|^([0-9]*)#$|sip:\1@\d;user=phone|outbound=proxy.com
|^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+@.+)|sip:\1|
|^([a-zA-Z0-9&=+\$,;?\-_.!~*'()%]+)$|sip:\1@\d|
|^(.*)$|sip:\1@\d|timeout=5
The SIP telephony device SHOULD support the configuration of a default digit map. If the SIP telephony device does not support digit maps, it SHOULD at least support a default digit map rule to construct a URI from digits. If the endpoint does support digit maps, this rule applies if none of the digit maps match.
SIP电话设备应支持默认数字映射的配置。如果SIP电话设备不支持数字映射，则它至少应支持默认数字映射规则，以从数字构造URI。如果端点不支持数字映射，则如果没有匹配的数字映射，则应用此规则。
For example, when a user enters "12345", the UA might send the request to "sip:12345@proxy.com;user=phone" after the user presses the OK key.
例如，当用户输入“12345”时，UA可能会向“sip:12345@proxy.com；用户=电话“在用户按下OK键后。
The parameters for SIP (like timer T1) and other related settings MAY be indicated. An example of usage would be the reduction of the DNS SRV failover time. Example: SIPTimer="t1=100;unit=ms"
可以指示SIP（如计时器T1）和其他相关设置的参数。使用的一个示例是减少DNS SRV故障切换时间。示例：SIPTimer=“t1=100；单位=ms”
Note: The timer settings can be included in the digit map.
注：计时器设置可包含在数字地图中。
In some cases, operators want to control which codecs may be used in their network. The desired subset of codecs supported by the device SHOULD be configurable along with the order of preference. Service providers SHOULD have the possibility of plugging in their own codecs
在某些情况下，运营商希望控制在其网络中使用哪些编解码器。设备支持的所需编解码器子集应可配置，并带有首选顺序。服务提供商应该有可能插入自己的编解码器
of choice. The codec settings MAY include the packet length and other parameters like silence suppression or comfort noise generation.
当然可以。编解码器设置可以包括分组长度和其他参数，如静音抑制或舒适噪声产生。
The set of available codecs will be used in the codec negotiation
according to RFC 3264.
Example: Codecs="speex/8000;ptime=20;cng=on,gsm;ptime=30"
The set of available codecs will be used in the codec negotiation
according to RFC 3264.
Example: Codecs="speex/8000;ptime=20;cng=on,gsm;ptime=30"
The settings MUST include hints about privacy for audio using Secure Realtime Transport Protocol (SRTP) that either mandate or encourage the usage of secure RTP. Example: SRTP="mandatory"
设置必须包括有关使用安全实时传输协议（SRTP）的音频隐私的提示，该协议要求或鼓励使用安全RTP。示例：SRTP=“必填”
Keyboard interaction can be indicated with in-band tones or preferably with out-of-band RTP packets (RFC 2833 [13]). The method for sending these events SHOULD be configurable with the order of precedence. Settings MAY include additional parameters like the content-type that should be used. Example: DTMFMethod="INFO;type=application/dtmf, RFC2833".
键盘交互可以用带内音调表示，或者最好用带外RTP数据包表示（RFC 2833[13]）。发送这些事件的方法应按优先顺序进行配置。设置可能包括其他参数，如应使用的内容类型。示例：DTMFMethod=“INFO；type=application/dtmf，RFC2833”。
Certain settings are dependent upon the regional location for the daylight saving time rules and for the time zone.
某些设置取决于夏令时规则和时区的区域位置。
Time Zone and UTC Offset: A time zone MAY be specified for the user. Where one is specified; it SHOULD use the schema used by the Olson Time One database [52].
时区和UTC偏移：可以为用户指定时区。凡有指明者；它应该使用Olson Time One数据库使用的模式[52]。
Examples of the database naming scheme are Asia/Dubai or America/Los Angeles where the first part of the name is the continent or ocean and the second part is normally the largest city in that time zone. Optional parameters like the UTC offset may provide additional information for UAs that are not able to map the time zone information to a internal database. Example: TimeZone="Asia/Dubai;offset=7200"
数据库命名方案的示例有亚洲/迪拜或美国/洛杉矶，其中名称的第一部分是大陆或海洋，第二部分通常是该时区最大的城市。UTC偏移量等可选参数可能会为无法将时区信息映射到内部数据库的UAs提供附加信息。示例：时区=“亚洲/迪拜；偏移量=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时间服务器设置的优先级高于时间服务器设置。示例：TimeServer=“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中定义的代码，以提供一定的可预测性。示例：Language=“de”
It is recommended to set the language as writable, so that the user MAY change this. This setting SHOULD NOT be AOR related.
建议将语言设置为可写，以便用户可以更改。此设置不应与AOR相关。
A SIP UA MUST be able to parse and accept requests containing international characters encoded as UTF-8 even if it cannot display those characters in the user interface.
SIP UA必须能够解析和接受包含编码为UTF-8的国际字符的请求，即使它不能在用户界面中显示这些字符。
SIP allows a device to limit incoming signaling to those made by a predefined set of authorized users from a list and/or with valid passwords. Note that the inbound proxy from most service providers may also support the screening of incoming calls, but in some cases users may want to have control in the SIP telephony device for the screening.
SIP允许设备将传入信令限制为预定义的授权用户组从列表和/或使用有效密码发出的信令。请注意，来自大多数服务提供商的入站代理也可能支持对传入呼叫的屏蔽，但在某些情况下，用户可能希望在SIP电话设备中拥有用于屏蔽的控制权。
A device SHOULD support the setting as to whether authentication (on
the device) is required and what type of authentication is required.
Example: InboundAuthentication="digest;pattern=*"
A device SHOULD support the setting as to whether authentication (on
the device) is required and what type of authentication is required.
Example: InboundAuthentication="digest;pattern=*"
If inbound authentication is enabled, then a list of allowed users and credentials to call this device MAY be used by the device. The credentials MAY contain the same data as the credentials for an AOR (i.e., URL, user, password digest, and domain). This applies to SIP control signaling as well as call initiation.
如果启用了入站身份验证，则设备可能会使用允许调用此设备的用户和凭据的列表。凭证可以包含与AOR凭证相同的数据（即URL、用户、密码摘要和域）。这适用于SIP控制信令以及呼叫发起。
Various voice message settings require the use of URIs for the service context as specified in RFC 3087 [53].
根据RFC 3087[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"
message waiting indicator（MWI）地址设置控制客户端应订阅语音消息服务器的位置以及可能显示的MWI摘要[9]。示例：MWISubscribe=“sip:mailbox01@media.proxy.com"
User Agents SHOULD accept MWI information carried by SIP MESSAGE without prior subscription. This way the setup of voice message settings can be avoided.
用户代理应接受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，以及管理员为其接听电话的每个执行人员的定义），这些AOR是为其注册的。如果代理去复印室，他们将登录到复印室中的设备，他们的用户设置（包括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
用户配置文件的管理、用户或设备AOR的聚合以及来自多个管理源的配置文件信息属于配置服务器问题，不属于本文档的范围。但是，能够唯一地识别设备和
user within the configuration data enables easier server-based as well as local (i.e., on the device) configuration management of the configuration data.
配置数据中的用户可以更轻松地对配置数据进行基于服务器和本地（即，在设备上）的配置管理。
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。设置中必须至少定义一个AOR；这可能涉及设备本身或用户。示例：AOR=“sip:12345@proxy.com"
It MUST be possible to specify at least one set of domain, user name, and authentication credentials for each AOR. The user name and authentication credentials are used for authentication challenges.
必须能够为每个AOR指定至少一组域、用户名和身份验证凭据。用户名和身份验证凭据用于身份验证挑战。
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电话设备可以支持本地承载的三方会议呼叫的至少两个连接。示例：MaximumConnections=“2；cwi=false；bw=128”。
See the recent work on connection reuse [54] and the guidelines for connection-oriented transport for SIP [55].
请参阅最近关于连接重用的工作[54]和SIP面向连接传输的指南[55]。
Automatic SIP telephony device configuration SHOULD use the processes and requirements described in [56]. The user name or the realm in the domain name SHOULD be used by the configuration server to automatically configure the device for individual- or group-specific settings, without any configuration by the user. Image and service data upgrades SHOULD also not require any settings by the user.
自动SIP电话设备配置应使用[56]中描述的流程和要求。配置服务器应使用用户名或域名中的域来自动配置设备以进行个人或组特定设置，而无需用户进行任何配置。映像和服务数据升级也不需要用户进行任何设置。
The device configuration usually contains sensitive information that MUST be protected. Examples include authentication information, private address books, and call history entries. Because of this, it is RECOMMENDED to use an encrypted transport mechanism for configuration data. Where devices use HTTP, this could be TLS.
设备配置通常包含必须保护的敏感信息。示例包括身份验证信息、专用地址簿和呼叫历史记录条目。因此，建议对配置数据使用加密传输机制。当设备使用HTTP时，这可能是TLS。
For devices which use FTP or TFTP for content delivery this can be achieved using symmetric key encryption.
对于使用FTP或TFTP进行内容交付的设备，可以使用对称密钥加密来实现这一点。
Access to retrieving configuration information is also an important issue. A configuration server SHOULD challenge a subscriber before sending configuration information.
获取配置信息也是一个重要问题。配置服务器应在发送配置信息之前质询订阅服务器。
The configuration server SHOULD NOT include passwords through the automatic configuration process. Users SHOULD enter the passwords locally.
配置服务器不应在自动配置过程中包含密码。用户应在本地输入密码。
While Section 2.11 states the minimal security requirements and NAT/firewall traversal that have to be met respectively by SIP telephony devices, developers and network managers have to be aware of the larger context of security for IP telephony, especially for those scenarios where security may reside in other parts of SIP-enabled networks.
虽然第2.11节说明了SIP电话设备必须分别满足的最低安全要求和NAT/防火墙穿越，但开发人员和网络管理人员必须了解IP电话的更大安全环境，特别是对于安全性可能位于启用SIP的网络的其他部分的场景。
Users of SIP telephony devices are exposed to many threats [57] that include but are not limited to fake identity of callers, telemarketing, spam in IM, hijacking of calls, eavesdropping, and learning of private information such as the personal phone directory, user accounts and passwords, and the personal calling history. Various denial of service (DoS) attacks are possible, such as hanging up on other people's conversations or contributing to DoS attacks of others.
SIP电话设备的用户面临许多威胁[57]，包括但不限于假呼叫者身份、电话营销、IM中的垃圾邮件、电话劫持、窃听和私人信息的学习，如个人电话目录、用户帐户和密码以及个人通话历史。各种拒绝服务（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.
作者认为，SIP电话设备的充分安全性最好在受保护的网络中实现，无论是专用IP网络还是服务提供商支持SIP的网络，其中此处列出的大部分安全威胁都在受保护的网络中处理。包括基于网络的安全功能（如基于网络的身份声明[58]和隐私服务[7]）的更一般的安全讨论不在本备忘录的范围内，但开发人员、网络经理和服务提供商必须充分理解。
In the following, some basic security considerations as specified in RFC 3261 are discussed as they apply to SIP telephony devices.
在下文中，将讨论RFC 3261中规定的一些基本安全注意事项，因为它们适用于SIP电话设备。
Transport Level Security SIP telephony devices that operate outside the perimeter of secure private IP networks (this includes telecommuters and roaming users) MUST use TLS to the outgoing SIP proxy for protection on the first hop. SIP telephony devices that use TLS must support SIPS in the SIP headers.
在安全专用IP网络（包括远程工作者和漫游用户）外围运行的传输级安全SIP电话设备必须使用TLS到传出SIP代理以在第一跳上进行保护。使用TLS的SIP电话设备必须在SIP头中支持SIP。
Supporting large numbers of TLS channels to endpoints is quite a burden for service providers and may therefore constitute a premium service feature.
支持大量到端点的TLS通道对服务提供商来说是一个相当大的负担，因此可能构成一个高级服务特性。
Digest Authentication SIP telephony devices MUST support digest authentication to register with the outgoing SIP registrar. This ensures proper identity credentials that can be conveyed by the network to the called party. It is assumed that the service provider operating the outgoing SIP registrar has an adequate trust relationship with its users and knows its customers well enough (identity, address, billing relationship, etc.). The exceptions are users of prepaid service. SIP telephony devices that accept prepaid calls MUST place "unknown" in the "From" header.
摘要身份验证SIP电话设备必须支持摘要身份验证才能向传出SIP注册器注册。这确保了网络可以向被叫方传送正确的身份凭证。假设操作传出SIP注册器的服务提供商与其用户具有充分的信任关系，并且充分了解其客户（身份、地址、计费关系等）。预付费服务的用户除外。接受预付费呼叫的SIP电话设备必须在“发件人”报头中放置“未知”。
End User Certificates SIP telephony devices MAY store personal end user certificates that are part of some Public Key Infrastructure (PKI) [59] service for high-security identification to the outgoing SIP registrar as well as for end-to-end authentication. SIP telephony devices equipped for certificate-based authentication MUST also store a key ring of certificates from public certificate authorities (CAs).
最终用户证书SIP电话设备可以存储个人最终用户证书，这些证书是一些公钥基础设施（PKI）[59]服务的一部分，用于向传出SIP注册器进行高安全性标识以及用于端到端认证。用于基于证书的认证的SIP电话设备还必须存储来自公共证书颁发机构（CA）的证书密钥环。
Note the recent work in the IETF on certificate services that do not require the telephony devices to store certificates [60].
请注意IETF最近在证书服务方面的工作，这些服务不需要电话设备存储证书[60]。
End-to-End Security Using S/MIME S/MIME [61] MUST be supported by SIP telephony devices to sign and encrypt portions of the SIP message that are not strictly required for routing by intermediaries. S/MIME protects private information in the SIP bodies and in some SIP headers from intermediaries. The end user certificates required for S/MIME ensure the identity of the parties to each other. Note: S/MIME need not be used, though, in every call.
SIP电话设备必须支持使用S/MIME S/MIME[61]的端到端安全性，以对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.
媒体加密安全RTP（SRTP）[62]可用于在密钥信息通过SIP信令传递之后对诸如音频、文本和视频之类的媒体进行加密。即时消息可以使用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
各种NAT和防火墙穿越场景需要电话SIP设备的支持。[51]回顾了SIP NAT穿越的最佳实践。大多数情况下，企业中没有支持SIP的网络边缘NAT/防火墙或网关
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.
如果SIP电话设备中有一个STUN客户端，而Internet上有一个由服务提供商维护的STUN服务器，则可以对其进行管理。在某些特殊情况下（传统对称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'.
由于媒体中继的这些缺点，最好避免网络中的对称和非确定性NAT，以便在需要时只能使用STUN。参考文献[63]更详细地论述了NAT的“行为”。
It is not always obvious to determine the specific NAT and firewall scenario under which a SIP telephony device may operate.
确定SIP电话设备可能运行的特定NAT和防火墙场景并不总是显而易见的。
For this reason, the support for Interactive Connectivity Establishment (ICE) has been defined to be deployed in all devices that required end-to-end connectivity for SIP signaling and RTP media streams, as well as for streaming media using Real Time Streaming Protocol (RTSP). ICE makes use of existing protocols, such as STUN and TURN.
因此，已将对交互式连接建立（ICE）的支持定义为部署在所有需要SIP信令和RTP媒体流以及使用实时流协议（RTSP）的流媒体的端到端连接的设备中。ICE利用现有的协议，如眩晕和转身。
Call flows using SIP security mechanisms The high-level security aspects described here are best illustrated by inspecting the detailed call flows using SIP security, such as in [64].
使用SIP安全机制的呼叫流通过检查使用SIP安全机制的详细呼叫流，如[64]中所述，这里描述的高级安全方面得到了最好的说明。
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.
安全增强、证书和身份管理在撰写本文时，IETF的最新工作涉及SIP认证身份主体（AIB）格式[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.
Paul Kyzivat和Francois Audet就如何支持Req-17中的拨号计划要求提出了有用的意见。玛丽·巴恩斯（Mary Barnes）对04版进行了非常详细的审查，这有助于显著改进文档。Ted Hardie、David Kessens、Russ Housley和Harald Alvestrand也对版本05提出了有用的意见，这些意见反映在本版本的文件中。
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.
我们要感谢Jon Peterson对先前版本0.3的非常详细的评论，这促使我们重写了本文档的大部分内容。约翰·埃尔维尔（John Elwell）就文件的04版发表了许多详细评论。Rohan Mahy对该文件做出了几项澄清，并在支持听力障碍人士的讨论中发挥了领导作用。这些讨论已经在第57届IETF期间举行的SIP设备BOF期间结束，结论反映在听力或言语障碍用户的交互式文本支持部分。
Gunnar Hellstrom, Arnoud van Wijk, and Guido Gybels have been instrumental in driving the specification for support of the hearing disabled.
Gunnar Hellstrom、Arnoud van Wijk和Guido Gybels在推动支持听力障碍人士的规范方面发挥了重要作用。
The authors would also like to thank numerous persons for contributions and comments to this work: Henning Schulzrinne, Jorgen Bjorkner, Jay Batson, Eric Tremblay, David Oran, Denise Caballero McCann, Brian Rosen, Jean Brierre, Kai Miao, Adrian Lewis, and Franz Edler. Jonathan Knight has contributed significantly to earlier versions of the requirements for SIP phones. Peter Baker has also provided valuable pointers to TIA/EIA IS 811 requirements to IP phones that are referenced here.
作者还想感谢许多人对这项工作的贡献和评论：亨宁·舒尔兹林纳、约根·比约克纳、杰伊·巴特森、埃里克·特雷姆布雷、大卫·奥兰、丹尼斯·卡巴莱罗·麦肯、布赖恩·罗森、让·布里埃、凯·缪、阿德里安·刘易斯和弗兰兹·埃德勒。乔纳森·奈特（Jonathan Knight）对SIP电话要求的早期版本做出了重大贡献。Peter Baker还提供了关于TIA/EIA IS 811对此处所述IP电话的要求的宝贵建议。
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.
最后但并非最不重要的一点是，先前版本的共同作者Daniel Petrie和Ian Butcher一直在这些需求的开发中提供支持和指导。他们的贡献现在是单独文件的重点。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[3] Lemon，T.和S.Cheshire，“动态主机配置协议（DHCPv4）中的长选项编码”，RFC 3396，2002年11月。
[4] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
[4] Mills，D.，“IPv4、IPv6和OSI的简单网络时间协议（SNTP）第4版”，RFC 4330，2006年1月。
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[5] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[6] Peterson, J., "enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record", RFC 3764, April 2004.
[6] Peterson，J.，“会话启动协议（SIP）记录地址的枚举服务注册”，RFC 3764，2004年4月。
[7] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[7] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[8] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[9] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[9] Mahy，R.，“会话启动协议（SIP）的消息摘要和消息等待指示事件包”，RFC 3842，2004年8月。
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[10] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[11] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[11] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[12] Johnston, A., "SIP Service Examples", Work in Progress, March 2006.
[12] Johnston，A.，“SIP服务示例”，正在进行的工作，2006年3月。
[13] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[13] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[14] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload Formats", RFC 3555, July 2003.
[14] Casner，S.和P.Hoschka，“RTP有效载荷格式的MIME类型注册”，RFC 3555，2003年7月。
[15] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, December 2002.
[15] Camarillo，G.，Eriksson，G.，Holler，J.，和H.Schulzrinne，“会话描述协议（SDP）中媒体线路的分组”，RFC 3388，2002年12月。
[16] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[16] Camarillo，G.和H.Schulzrinne，“会话启动协议（SIP）中的早期媒体和铃声生成”，RFC 39602004年12月。
[17] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Basic Call Flow Examples", BCP 75, RFC 3665, December 2003.
[17] Johnston，A.，Donovan，S.，Sparks，R.，Cunningham，C.，和K.Summers，“会话发起协议（SIP）基本呼叫流示例”，BCP 75，RFC 3665，2003年12月。
[18] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., and K. Summers, "Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows", BCP 76, RFC 3666, December 2003.
[18] Johnston，A.，Donovan，S.，Sparks，R.，Cunningham，C.，和K.Summers，“会话发起协议（SIP）公共交换电话网络（PSTN）呼叫流”，BCP 76，RFC 3666，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] Rosenberg，J.，Peterson，J.，Schulzrinne，H.，和G.Camarillo，“会话启动协议（SIP）中第三方呼叫控制（3pcc）的最佳当前实践”，BCP 85，RFC 37252004年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] Mahy，R.，等人，“会话启动协议（SIP）的呼叫控制和多方使用框架”，正在进行的工作，2006年3月。
[21] Johnston, A. and O. Levin, "Session Initiation Protocol Call Control - Conferencing for User Agents", Work in Progress, October 2005.
[21] Johnston，A.和O.Levin，“会话启动协议呼叫控制-用户代理会议”，正在进行的工作，2005年10月。
[22] Even, R. and N. Ismail, "Conferencing Scenarios", Work in Progress, September 2005.
[22] 甚至，R.和N.Ismail，“会议场景”，正在进行的工作，2005年9月。
[23] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[23] Hellstrom，G.和P.Jones，“文本对话的RTP有效载荷”，RFC 4103，2005年6月。
[24] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging", RFC 3428, December 2002.
[24] Campbell，B.，Rosenberg，J.，Schulzrinne，H.，Huitema，C.，和D.Gurle，“即时消息的会话启动协议（SIP）扩展”，RFC 34282002年12月。
[25] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[25] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[26] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[26] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[27] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", Work in Progress, September 2005.
[27] Schulzrinne，H.，Gurbani，V.，Kyzivat，P.，和J.Rosenberg，“RPID：状态信息数据格式（PIDF）的丰富状态扩展”，正在进行的工作，2005年9月。
[28] See the Working Group on Emergency Context Resolution with
Internet Technologies at
http://www.ietf.org/html.charters/ecrit-charter.html
[28] See the Working Group on Emergency Context Resolution with
Internet Technologies at
http://www.ietf.org/html.charters/ecrit-charter.html
[29] Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
[29] Schulzrinne，H.和J.Polk，“会话启动协议（SIP）的通信资源优先级”，RFC 4412，2006年2月。
[30] Polk, J. and B. Rosen, "Session Initiation Protocol Location Conveyance", Work in Progress, July 2005.
[30] Polk，J.和B.Rosen，“会话启动协议位置传输”，正在进行的工作，2005年7月。
[31] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van Wijk, "User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals", RFC 3351, August 2002.
[31] N.查尔顿、M.加森、G.吉贝尔斯、M.斯潘纳和A.范威克，“支持聋人、重听人和言语障碍者的会话启动协议（SIP）的用户需求”，RFC 3351，2002年8月。
[32] van Wijk, A., "Framework of requirements for real-time text conversation using SIP", Work in Progress, September 2005.
[32] van Wijk，A.，“使用SIP的实时文本对话需求框架”，正在进行的工作，2005年9月。
[33] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[33] Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[34] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[34] Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[35] Pendleton, A., "SIP Package for Quality Reporting Event", Work in Progress, February 2006.
[35] 彭德尔顿，A.，“质量报告事件的SIP包”，正在进行的工作，2006年2月。
[36] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[36] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[37] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
[37] Heinanen，J.，Baker，F.，Weiss，W.，和J.Wroclawski，“保证货运PHB集团”，RFC 25971999年6月。
[38] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[38] Braden，R.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[39] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[39] Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，2003年7月。
[40] ITU-T Recommendation G.711, available online at http://www.itu.int.
[40] ITU-T建议G.711，可在线访问http://www.itu.int.
[41] Andersen, S., Duric, A., Astrom, H., Hagen, R., Kleijn, W., and J. Linden, "Internet Low Bit Rate Codec (iLBC)", RFC 3951, December 2004.
[41] Andersen，S.，Duric，A.，Astrom，H.，Hagen，R.，Kleijn，W.，和J.Linden，“互联网低比特率编解码器（iLBC）”，RFC 39512004年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.Andersen，“互联网低比特率编解码器（iLBC）语音的实时传输协议（RTP）有效载荷格式”，RFC 3952，2004年12月。
[43] Herlein, G., et al., "RTP Payload Format for the Speex Codec", Work in Progress, October 2005.
[43] Herlein，G.等人，“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，“窄带IP语音和PCM数字有线电话的传输要求”，2000年7月。
[45] TIA-EIA-IS-811, "Terminal Equipment - Performance and Interoperability Requirements for Voice-over-IP (VoIP) Feature Telephones", July 2000.
[45] TIA-EIA-IS-811，“终端设备-IP语音（VoIP）功能电话的性能和互操作性要求”，2000年7月。
[46] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[46] Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[47] Wing, D., "Symmetric RTP and RTCP Considered Helpful", Work in Progress, October 2004.
[47] Wing，D.，“对称RTP和RTCP被认为是有用的”，正在进行的工作，2004年10月。
[48] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[48] Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[49] Jennings, C., "NAT Classification Test Results", Work in Progress, July 2005.
[49] Jennings，C.，“NAT分类测试结果”，正在进行的工作，2005年7月。
[50] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, July 2005.
[50] Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历方法”，正在进行的工作，2005年7月。
[51] Boulton, C. and J. Rosenberg, "Best Current Practices for NAT Traversal for SIP", Work in Progress, October 2005.
[51] Boulton，C.和J.Rosenberg，“SIP NAT遍历的最佳当前实践”，正在进行的工作，2005年10月。
[52] P. Eggert, "Sources for time zone and daylight saving time data." Available at http://www.twinsun.com/tz/tz-link.htm.
[52] P.Eggert，“时区和夏令时数据源”，可在http://www.twinsun.com/tz/tz-link.htm.
[53] Campbell, B. and R. Sparks, "Control of Service Context using SIP Request-URI", RFC 3087, April 2001.
[53] Campbell，B.和R.Sparks，“使用SIP请求URI控制服务上下文”，RFC3087，2001年4月。
[54] Mahy, R., "Connection Reuse in the Session Initiation Protocol (SIP)", Work in Progress, February 2006.
[54] Mahy，R.，“会话启动协议（SIP）中的连接重用”，正在进行的工作，2006年2月。
[55] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol", Work in Progress, March 2006.
[55] Jennings，C.和R.Mahy，“在会话启动协议中管理客户端启动的连接”，正在进行的工作，2006年3月。
[56] Petrie, D., "A Framework for SIP User Agent Profile Delivery", Work in Progress, July 2005.
[56] Petrie，D.，“SIP用户代理配置文件交付框架”，正在进行的工作，2005年7月。
[57] Jennings, C., "SIP Tutorial: SIP Security", presented at the VON Spring 2004 conference, March 29, 2004, Santa Clara, CA.
[57] Jennings，C.，“SIP教程：SIP安全”，在2004年3月29日于加利福尼亚州圣克拉拉举行的VON Spring 2004会议上发表。
[58] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002.
[58] Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中用于断言身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[59] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. Wu, "Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework", RFC 3647, November 2003.
[59] Chokhani，S.，Ford，W.，Sabett，R.，Merrill，C.，和S.Wu，“互联网X.509公钥基础设施证书政策和认证实践框架”，RFC 3647，2003年11月。
[60] Jennings, C. and J. Peterson, "Certificate Management Service for The Session Initiation Protocol (SIP)", Work in Progress, March 2006.
[60] Jennings，C.和J.Peterson，“会话启动协议（SIP）的证书管理服务”，正在进行的工作，2006年3月。
[61] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[61] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[62] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[62] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[63] Audet, F. and C. Jennings, "NAT Behavioral Requirements for Unicast UDP", Work in Progress, September 2005.
[63] Audet，F.和C.Jennings，“单播UDP的NAT行为要求”，正在进行的工作，2005年9月。
[64] Jennings, C., "Example call flows using SIP security mechanisms", Work in Progress, February 2006.
[64] Jennings，C.，“使用SIP安全机制的示例调用流”，正在进行的工作，2006年2月。
[65] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004.
[65] Peterson，J.，“会话发起协议（SIP）认证身份主体（AIB）格式”，RFC 3893，2004年9月。
Author's Addresses
作者地址
Henry Sinnreich Pulver.com 115 Broadhollow Road Melville, NY 11747, USA
Henry Sinnreich Pulver.com美国纽约州梅尔维尔布罗德空心路115号，邮编：11747
EMail: henry@pulver.com
Phone: +1-631-961-8950
EMail: henry@pulver.com
Phone: +1-631-961-8950
Steven Lass Verizon 1201 East Arapaho Road Richardson, TX 75081, USA
美国德克萨斯州理查森市阿拉帕霍东路1201号史蒂文·拉斯威瑞森75081
EMail: steven.lass@verizonbusiness.com
Phone: +1-972-728-2363
EMail: steven.lass@verizonbusiness.com
Phone: +1-972-728-2363
Christian Stredicke snom technology AG Gradestrasse, 46 D-12347 Berlin, Germany
Christian Stredicke snom technology AG Gradestrasse，46 D-12347柏林，德国
EMail: cs@snom.de
Phone: +49(30)39833-0
EMail: cs@snom.de
Phone: +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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。