Network Working Group M. Garcia-Martin
Request for Comments: 4083 Nokia
Category: Informational May 2005
Network Working Group M. Garcia-Martin
Request for Comments: 4083 Nokia
Category: Informational May 2005
Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP)
输入第三代合作伙伴计划（3GPP）第5版对会话启动协议（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 (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The 3rd-Generation Partnership Project (3GPP) has selected Session Initiation Protocol (SIP) as the session establishment protocol for the 3GPP IP Multimedia Core Network Subsystem (IMS). IMS is part of Release 5 of the 3GPP specifications. Although SIP is a protocol that fulfills most of the requirements for establishing a session in an IP network, SIP has never been evaluated against the specific 3GPP requirements for operation in a cellular network. In this document, we express the requirements identified by 3GPP to support SIP for Release 5 of the 3GPP IMS in cellular networks.
第三代合作伙伴计划（3GPP）已选择会话发起协议（SIP）作为3GPP IP多媒体核心网络子系统（IMS）的会话建立协议。IMS是3GPP规范第5版的一部分。尽管SIP是满足在IP网络中建立会话的大部分要求的协议，但是SIP从未根据蜂窝网络中操作的特定3GPP要求进行评估。在本文档中，我们表达了3GPP确定的在蜂窝网络中支持第5版3GPP IMS的SIP的需求。
Table of Contents
目录
1. Introduction ....................................................4
2. Conventions .....................................................4
3. Overview of the 3GPP IMS ........................................5
4. 3GPP Requirements on SIP ........................................7
4.1. General Requirements .......................................7
4.1.1. Efficient Use of the Radio Interface ................7
4.1.2. Minimum Session Setup Time ..........................7
4.1.3. Minimum Support Required in the Terminal ............8
4.1.4. Roaming and Non-roaming .............................8
4.1.5. Terminal Mobility Management ........................8
4.1.6. IP Version 6 ........................................8
4.2. SIP Outbound Proxy .........................................8
4.2.1. SIP Outbound Proxy ..................................8
4.2.2. Discovery of the SIP Outbound Proxy .................8
4.3. Registration ...............................................9
4.3.1. Registration Required ...............................9
4.3.2. Efficient Registration .............................10
4.3.3. Registration for Roaming and Non-roaming Cases .....10
4.3.4. Visited Domain Name ................................10
4.3.5. De-registration ....................................10
4.4. SIP Compression ...........................................11
4.4.1. Compression Algorithm Independence .................12
4.4.2. Extensibility of the SIP Compression ...............12
4.4.3. Minimal Impact of SIP Compression on the Network ...12
4.4.4. Optionality of SIP Compression .....................12
4.5. QoS Requirements Related to SIP ...........................13
4.5.1. Independence between QoS Signaling and SIP .........13
4.5.2. Coordination between SIP and QoS/Resource
Allocation .........................................13
4.6. Prevention of Theft of Service ............................14
4.7. Radio Resource Authorization ..............................14
4.8. Prevention of Malicious Usage .............................14
4.9. Prevention of Denial of Service ...........................14
4.10. Identification of Users ..................................15
4.10.1. Private User Identity ............................15
4.10.2. Public User Identities ...........................15
4.10.3. Delivery of the Dialed Public User ID ............17
4.11. Identifiers Used for Routing .............................17
4.12. Hiding Requirements ......................................17
4.12.1. Hiding of the Network Structure ..................17
4.12.2. Hiding of IP Addresses ...........................17
4.12.3. SIP Hiding Proxy .................................18
4.13. Cell-ID ..................................................18
4.13.1. Cell-ID in Signaling from the UA to the
Visited and Home .................................18
4.13.2. Format of the Cell-ID ............................18
1. Introduction ....................................................4
2. Conventions .....................................................4
3. Overview of the 3GPP IMS ........................................5
4. 3GPP Requirements on SIP ........................................7
4.1. General Requirements .......................................7
4.1.1. Efficient Use of the Radio Interface ................7
4.1.2. Minimum Session Setup Time ..........................7
4.1.3. Minimum Support Required in the Terminal ............8
4.1.4. Roaming and Non-roaming .............................8
4.1.5. Terminal Mobility Management ........................8
4.1.6. IP Version 6 ........................................8
4.2. SIP Outbound Proxy .........................................8
4.2.1. SIP Outbound Proxy ..................................8
4.2.2. Discovery of the SIP Outbound Proxy .................8
4.3. Registration ...............................................9
4.3.1. Registration Required ...............................9
4.3.2. Efficient Registration .............................10
4.3.3. Registration for Roaming and Non-roaming Cases .....10
4.3.4. Visited Domain Name ................................10
4.3.5. De-registration ....................................10
4.4. SIP Compression ...........................................11
4.4.1. Compression Algorithm Independence .................12
4.4.2. Extensibility of the SIP Compression ...............12
4.4.3. Minimal Impact of SIP Compression on the Network ...12
4.4.4. Optionality of SIP Compression .....................12
4.5. QoS Requirements Related to SIP ...........................13
4.5.1. Independence between QoS Signaling and SIP .........13
4.5.2. Coordination between SIP and QoS/Resource
Allocation .........................................13
4.6. Prevention of Theft of Service ............................14
4.7. Radio Resource Authorization ..............................14
4.8. Prevention of Malicious Usage .............................14
4.9. Prevention of Denial of Service ...........................14
4.10. Identification of Users ..................................15
4.10.1. Private User Identity ............................15
4.10.2. Public User Identities ...........................15
4.10.3. Delivery of the Dialed Public User ID ............17
4.11. Identifiers Used for Routing .............................17
4.12. Hiding Requirements ......................................17
4.12.1. Hiding of the Network Structure ..................17
4.12.2. Hiding of IP Addresses ...........................17
4.12.3. SIP Hiding Proxy .................................18
4.13. Cell-ID ..................................................18
4.13.1. Cell-ID in Signaling from the UA to the
Visited and Home .................................18
4.13.2. Format of the Cell-ID ............................18
4.14. Release of Sessions ......................................18
4.14.1. Ungraceful Session Release .......................19
4.14.2. Graceful Session Release .........................19
4.15. Routing of SIP Messages ..................................20
4.15.1. SIP Outbound Proxy ...............................20
4.15.2. SIP Serving Proxy in the Home Network ............20
4.15.3. INVITE Might Follow a Different Path than
REGISTER .........................................20
4.15.4. SIP Inbound Proxy ................................20
4.15.5. Distribution of the Source Routing Set of
Proxies ..........................................21
4.16. Emergency Sessions .......................................21
4.17. Identities Used for Session Establishment ................21
4.17.1. Remote Party Identification Presentatio ..........21
4.17.2. Remote Party Identification Privacy ..............21
4.17.3. Remote Party Identification Blocking .............21
4.17.4. Anonymity ........................................22
4.17.5. Anonymous Session Establishment ..................22
4.18. Charging .................................................22
4.18.1. Support of Both Prepaid and Postpaid Models ......22
4.18.2. Charging Correlation Levels ......................23
4.18.3. Charging Correlation Principles ..................23
4.18.4. Collection of Session Detailed Information .......24
4.19. General Support of Additional Capabilities ...............24
4.19.1. Additional Capabilities ..........................24
4.19.2. DTMF Signaling ...................................24
4.19.3. Early Media ......................................25
4.20. Exchange of Session Description ..........................25
4.21. Prohibition of Certain SDP Parameters ....................26
4.21.1. Prohibition of Codecs ............................26
4.21.2. Prohibition of Media Types .......................26
4.22. Network-initiated Re-authentication ......................26
4.23. Security Model ...........................................27
4.24. Access Domain Security ...................................28
4.24.1. General Requirements .............................28
4.24.2. Authentication ...................................29
4.24.3. Message Protection ...............................29
4.24.4. Negotiation of Mechanisms ........................31
4.24.5. Verification of Messages .........................31
4.25. Network Domain Security ..................................32
5. Security Considerations ........................................32
6. Contributors ...................................................32
7. References .....................................................32
7.1. Normative References ......................................32
7.2. Informative References ....................................33
4.14. Release of Sessions ......................................18
4.14.1. Ungraceful Session Release .......................19
4.14.2. Graceful Session Release .........................19
4.15. Routing of SIP Messages ..................................20
4.15.1. SIP Outbound Proxy ...............................20
4.15.2. SIP Serving Proxy in the Home Network ............20
4.15.3. INVITE Might Follow a Different Path than
REGISTER .........................................20
4.15.4. SIP Inbound Proxy ................................20
4.15.5. Distribution of the Source Routing Set of
Proxies ..........................................21
4.16. Emergency Sessions .......................................21
4.17. Identities Used for Session Establishment ................21
4.17.1. Remote Party Identification Presentatio ..........21
4.17.2. Remote Party Identification Privacy ..............21
4.17.3. Remote Party Identification Blocking .............21
4.17.4. Anonymity ........................................22
4.17.5. Anonymous Session Establishment ..................22
4.18. Charging .................................................22
4.18.1. Support of Both Prepaid and Postpaid Models ......22
4.18.2. Charging Correlation Levels ......................23
4.18.3. Charging Correlation Principles ..................23
4.18.4. Collection of Session Detailed Information .......24
4.19. General Support of Additional Capabilities ...............24
4.19.1. Additional Capabilities ..........................24
4.19.2. DTMF Signaling ...................................24
4.19.3. Early Media ......................................25
4.20. Exchange of Session Description ..........................25
4.21. Prohibition of Certain SDP Parameters ....................26
4.21.1. Prohibition of Codecs ............................26
4.21.2. Prohibition of Media Types .......................26
4.22. Network-initiated Re-authentication ......................26
4.23. Security Model ...........................................27
4.24. Access Domain Security ...................................28
4.24.1. General Requirements .............................28
4.24.2. Authentication ...................................29
4.24.3. Message Protection ...............................29
4.24.4. Negotiation of Mechanisms ........................31
4.24.5. Verification of Messages .........................31
4.25. Network Domain Security ..................................32
5. Security Considerations ........................................32
6. Contributors ...................................................32
7. References .....................................................32
7.1. Normative References ......................................32
7.2. Informative References ....................................33
3GPP has selected SIP [2] as the protocol to establish and tear down multimedia sessions in the IP Multimedia Subsystem (IMS). 3GPP Technical Specification 23.228 [28] describes the IMS. 3GPP Technical Specification 24.228 [29] contains a comprehensive set of session flows. 3GPP Technical Specification 24.229 [30] describes the usage of SIP by the various IMS nodes.
3GPP已经选择SIP[2]作为在IP多媒体子系统（IMS）中建立和中断多媒体会话的协议。3GPP技术规范23.228[28]描述了IMS。3GPP技术规范24.228[29]包含一组全面的会话流。3GPP技术规范24.229[30]描述了各种IMS节点对SIP的使用。
This document is an effort to define the requirements applicable to the usage of the SIP protocol suite in cellular networks, particularly in the 3GPP IMS for Release 5 of the 3GPP specifications. Further releases of the 3GPP specifications may contain additional SIP requirements. This document focuses on the requirements identified for the 3GPP Release 5 IMS.
本文档旨在定义适用于在蜂窝网络中使用SIP协议套件的要求，特别是在3GPP规范第5版的3GPP IMS中。3GPP规范的进一步发布可能包含额外的SIP要求。本文档重点介绍3GPP第5版IMS的需求。
The rest of this document is structured as follows:
本文件其余部分的结构如下：
o Section 3 offers an overview of the 3GPP IMS. Readers who are not familiar with it should carefully read this section.
o 第3节概述了3GPP IMS。不熟悉本节的读者应仔细阅读本节。
o Section 4 contains the 3GPP requirements to SIP. Requirements are grouped by category. Some requirements include statements on possible solutions that would be able to fulfill them. Note that, as a particular requirement might be fulfilled by different solutions, not all the solutions might have an impact on SIP.
o 第4节包含3GPP对SIP的要求。需求按类别分组。一些要求包括关于能够实现这些要求的可能解决方案的声明。请注意，由于不同的解决方案可能会满足特定的需求，因此并非所有的解决方案都会对SIP产生影响。
This document is advisory in nature. Its primary purpose is to help the IETF understand the IMS environment. Given this better understanding, we expect that the IETF can more effectively evolve the SIP protocol. The IETF will not respond to the requirements given in this document on a point-for-point basis. Some requirements have been and/or will be met by extensions to the SIP protocol. Others may be addressed by effectively using existing capabilities in SIP or other protocols, and we expect that individual members of the SIP community will work with 3GPP to achieve a better understanding of these mechanisms. Some of the requirements in this document may not be addressed at all by the IETF, although we believe that the act of documenting and discussing them is in itself helpful in achieving a better all-around understanding of the task at hand.
本文件具有咨询性质。其主要目的是帮助IETF了解IMS环境。鉴于这种更好的理解，我们期望IETF能够更有效地发展SIP协议。IETF不会逐点响应本文件中给出的要求。SIP协议的扩展已经和/或将满足一些要求。其他问题可以通过有效使用SIP或其他协议中的现有功能来解决，我们期望SIP社区的个人成员将与3GPP合作，以更好地理解这些机制。IETF可能根本无法解决本文件中的一些要求，尽管我们认为记录和讨论这些要求本身有助于更好地全面理解手头的任务。
This document does not specify any protocol of any kind. Therefore, the usage of the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, as described in RFC 2119 [1], does not apply.
本文件未规定任何类型的协议。因此，如RFC 2119[1]所述，本文件中使用的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“建议”、“可”和“可选”不适用。
This section gives the reader an overview of the 3GPP IM CN Subsystem (IMS). It is not intended to be comprehensive, but it provides enough information to understand the basis of the 3GPP IMS. Readers are encouraged to find a more detailed description in the 3GPP Technical Specifications 23.060 [27], 23.228 [28], and 24.228 [29].
本节向读者概述了3GPP IM CN子系统（IMS）。它并不打算全面，但它提供了足够的信息来理解3GPP IMS的基础。鼓励读者在3GPP技术规范23.060[27]、23.228[28]和24.228[29]中找到更详细的说明。
For a particular cellular device, the 3GPP IMS network is further decomposed in a home network and a visited network.
对于特定蜂窝设备，3GPP IMS网络进一步分解为家庭网络和到访网络。
An IMS subscriber belongs to his or her home network. Services are triggered and may be executed in the home network. One or more SIP servers are deployed in the SIP home network to support the IP Multimedia Subsystem. Among those SIP servers, there is a SIP serving proxy, which is also acting as a SIP registrar. Authentication/Authorization servers may be part of the home network as well. Users are authenticated in the home network.
IMS用户属于其家庭网络。服务被触发并且可以在家庭网络中执行。一个或多个SIP服务器部署在SIP家庭网络中，以支持IP多媒体子系统。在这些SIP服务器中，有一个SIP服务代理，它也充当SIP注册器。身份验证/授权服务器也可以是家庭网络的一部分。在家庭网络中对用户进行身份验证。
A SIP outbound proxy is provided to support the User Agent (UA). The SIP outbound proxy is typically located in the visited network, although it may be located in the home network as well. The SIP outbound proxy maintains security associations between itself and the terminals, and interworks with the resource management in the packet network.
提供SIP出站代理以支持用户代理（UA）。SIP出站代理通常位于所访问的网络中，尽管它也可能位于家庭网络中。SIP出站代理维护自身和终端之间的安全关联，并与分组网络中的资源管理进行交互。
The SIP outbound proxy is assigned after the mobile device has connected to the access network. Once this proxy is assigned, it does not change while the mobile remains connected to the access network. Thus the mobile can move freely within the access network without SIP outbound proxy reassignment.
SIP出站代理在移动设备连接到接入网络后分配。一旦分配了此代理，当移动设备保持连接到接入网络时，它不会改变。因此，移动设备可以在接入网络内自由移动，而无需SIP出站代理重新分配。
The home network may also support one or more SIP edge proxies. These nodes may act as the first entry points for SIP signaling to the home network and may determine (with the help of location servers) which SIP registrar server to assign to a particular user. Typically the address of the home network SIP edge proxy is configured in DNS in the form of a DNS Naming Authority Pointer (NAPTR) and Service (SRV) records for SIP.
家庭网络还可以支持一个或多个SIP边缘代理。这些节点可以充当到家庭网络的SIP信令的第一入口点，并且可以（在位置服务器的帮助下）确定要分配给特定用户的SIP注册服务器。通常，家庭网络SIP边缘代理的地址以DNS命名机构指针（NAPTR）和SIP服务（SRV）记录的形式在DNS中配置。
Additionally, home and visited networks may deploy, if required, a SIP-hiding proxy. The main purpose of the SIP-hiding proxy is to hide the network configuration.
此外，如果需要，家庭和到访网络可以部署SIP隐藏代理。SIP隐藏代理的主要目的是隐藏网络配置。
The 3GPP IM CN Subsystem is designed to be access independent. Access is granted from 3GPP cellular terminals or from other terminals that use other accesses out of the scope of 3GPP.
3GPP IM CN子系统设计为独立于接入。从3GPP蜂窝终端或使用3GPP范围之外的其他接入的其他终端授予接入。
3GPP cellular IP Multimedia terminals use the existing General Packet Radio Service (GPRS) [27] as a transport network for IP datagrams. The terminals first connect to the GPRS network to get an IPv6 prefix. In order to do this, the terminals must perform a GPRS Attach procedure followed by a GPRS PDP Context Activation procedure. These GPRS procedures are required to be completed before any IP Multimedia session can be established.
3GPP蜂窝IP多媒体终端使用现有的通用分组无线业务（GPRS）[27]作为IP数据报的传输网络。终端首先连接到GPRS网络以获得IPv6前缀。为此，终端必须先执行GPRS连接程序，然后再执行GPRS PDP上下文激活程序。在建立任何IP多媒体会话之前，需要完成这些GPRS过程。
As a result of the above-mentioned GPRS procedures, the terminal has built an IPv6 address. The IPv6 address belongs to the same network address space as does the SIP outbound proxy. The address does not change, as the mobile terminal moves while still attached to the same network address space.
通过上述GPRS程序，终端建立了IPv6地址。IPv6地址与SIP出站代理属于相同的网络地址空间。地址不会改变，因为移动终端在移动时仍然连接到相同的网络地址空间。
If the terminal moves from a GPRS access to another GPRS access, the above-mentioned GPRS procedures needs to start from the beginning to allocate an IPv6 address to the terminal.
如果终端从一个GPRS接入移动到另一个GPRS接入，则上述GPRS过程需要从头开始为终端分配IPv6地址。
Figure 1 shows an overview of the 3GPP architecture for IM CN Subsystem.
图1显示了IM-CN子系统的3GPP体系结构的概述。
+-------------+ +----------------+ +----------------+
| | | | | +------+ |
| | | | | | SIP | |
| | | | | |server| |
| | | | | | +------+ |
+-|+ | | | | | / |
| | | | | +------+ | | +------+ |
| | | | | | SIP | | | | SIP | |
| | ---|-------------|--|----|server|----|---|-|server| |
+--+ | | | +------+ | | +------+ |
| | | | | |
SIP | GPRS access | | Visited Network| | Home Network |
dev. +-------------+ +----------------+ +----------------+
+-------------+ +----------------+ +----------------+
| | | | | +------+ |
| | | | | | SIP | |
| | | | | |server| |
| | | | | | +------+ |
+-|+ | | | | | / |
| | | | | +------+ | | +------+ |
| | | | | | SIP | | | | SIP | |
| | ---|-------------|--|----|server|----|---|-|server| |
+--+ | | | +------+ | | +------+ |
| | | | | |
SIP | GPRS access | | Visited Network| | Home Network |
dev. +-------------+ +----------------+ +----------------+
Figure 1: Overview of the 3GPP IMS architecture
图1:3GPP IMS体系结构概述
Another possible future configuration is depicted in Figure 2. In that case, a general-purpose computer (e.g., a laptop computer) is connected to a GPRS terminal. The computer hosts the Multimedia application (comprising SIP, SDP, RTP, etc.). The GPRS terminal handles the radio access and the GPRS connectivity. Note that, for the sake of clarity, in this example the home network has not been depicted in the figure.
另一种可能的未来配置如图2所示。在这种情况下，通用计算机（例如笔记本电脑）连接到GPRS终端。计算机承载多媒体应用程序（包括SIP、SDP、RTP等）。GPRS终端处理无线接入和GPRS连接。注意，为了清楚起见，在本示例中，图中未描绘家庭网络。
+-------------+ +----------------+
+-------+ | | | | |
| | +-|+ | | | |
| | | | | | | +------+ |
+-------+ | | | | | | SIP | |
/ / --------| | ---|-------------|-------|server|------
/-------/ +--+ | | | +------+ |
| | | |
SIP GPRS | GPRS access | | Visited Network|
client terminal +-------------+ +----------------+
+-------------+ +----------------+
+-------+ | | | | |
| | +-|+ | | | |
| | | | | | | +------+ |
+-------+ | | | | | | SIP | |
/ / --------| | ---|-------------|-------|server|------
/-------/ +--+ | | | +------+ |
| | | |
SIP GPRS | GPRS access | | Visited Network|
client terminal +-------------+ +----------------+
Figure 2: A computer connected to a GPRS terminal
图2：连接到GPRS终端的计算机
Services are typically executed in an application server. The interface between the SIP server and the application server is based on SIP. However, certain operators may want to reuse the existing technology, and therefore, they may need to interoperate SIP with protocols such as CAMEL/Intelligent-Network or Open Services Architecture (OSA).
服务通常在应用服务器中执行。SIP服务器和应用服务器之间的接口基于SIP。然而，某些运营商可能希望重用现有技术，因此，他们可能需要与诸如CAMEL/智能网络或开放服务体系结构（OSA）等协议互操作SIP。
This section does not specify any particular requirement for SIP. However, it includes a list of general requirements that must be considered when developing solutions to particular requirements.
本节未规定SIP的任何特殊要求。但是，它包含了一个在开发特定需求的解决方案时必须考虑的一般需求列表。
The radio interface is a scarce resource. As such, the exchange of signaling messages between the mobile terminal and the network should be minimized. All the mechanisms developed should make an efficient use of the radio interface.
无线电接口是一种稀缺资源。因此，移动终端和网络之间的信令消息交换应该最小化。开发的所有机制都应有效利用无线电接口。
See also the related requirements in Section 4.4.
另见第4.4节中的相关要求。
All the procedures and mechanisms should have a minimum impact on the session setup time as perceived by the user. When there is a choice between performing tasks at session establishment and prior to session establishment, then tasks should be performed prior to session establishment.
所有的程序和机制都应该对用户感知的会话设置时间产生最小的影响。如果在会话建立时和会话建立之前执行任务之间存在选择，则任务应在会话建立之前执行。
See also the related requirements in Section 4.4.
另见第4.4节中的相关要求。
As terminals could be rather small devices, memory requirements, power consumption, processing power, etc., should be kept to a minimum. Mandating support for additional protocols in the terminal must meet this requirement.
由于终端可能是相当小的设备，内存需求、功耗、处理能力等应保持在最低限度。在终端中强制支持附加协议必须满足此要求。
All the requirements must be met for both roaming and non-roaming scenarios. There should not be a significant change in the signaling procedures between roaming and non-roaming scenarios.
漫游和非漫游场景都必须满足所有要求。漫游和非漫游场景之间的信令过程不应发生重大变化。
As terminal mobility is managed by the access network, there is no need to support terminal mobility management in SIP.
由于终端移动性由接入网络管理，因此在SIP中不需要支持终端移动性管理。
3GPP IMS is solely designed to use IP version 6. As a consequence, all protocols must support IPv6 addresses.
3GPP IMS仅设计为使用IP版本6。因此，所有协议都必须支持IPv6地址。
A SIP outbound proxy is provided to support both roaming and non-roaming scenarios. The SIP outbound proxy may be located either in the home network or in the visited network.
提供SIP出站代理以支持漫游和非漫游场景。SIP出站代理可以位于家庭网络或访问网络中。
There must be a general mechanism whereby the mobile device (UA) learns the SIP outbound proxy address.
必须有一种通用机制，移动设备（UA）通过该机制学习SIP出站代理地址。
The DHCPv6 option for SIP servers in RFC 3319 [19] seems to fulfill the requirement.
RFC 3319[19]中SIP服务器的DHCPv6选项似乎满足了要求。
In addition to the above-expressed requirement, the 3GPP access network may provide the SIP outbound proxy address during access network bearer establishment. This is considered a less general mechanism, though.
除了上述表示的要求之外，3GPP接入网络可以在接入网络承载建立期间提供SIP出站代理地址。不过，这被认为是一种不太普遍的机制。
The home network must maintain one or more SIP registrars. The SIP registrar authenticates the user and registers the IP address where the user can be located.
家庭网络必须维护一个或多个SIP注册器。SIP注册器对用户进行身份验证，并注册用户所在的IP地址。
Once the terminal is switched on, the mobile device UA reads its configuration data. This data may be stored in a SIM card or in any other memory device. The configuration data contains an identification of the home network. The device finds the SIP registrar address from the home network domain name. The terminal sends the registration through the SIP outbound proxy.
一旦终端接通，移动设备UA读取其配置数据。这些数据可以存储在SIM卡或任何其他存储设备中。配置数据包含家庭网络的标识。设备从家庭网络域名中查找SIP注册器地址。终端通过SIP出站代理发送注册。
In order to support the search of the registrar, the home network contains one or more SIP servers that may be configured in DNS with the NAPTR/SRV record of SIP. These are the home network edge proxies. Their mission is to serve as the first points of contact in the home network, and to decide (with the help of location servers) which SIP registrar server to assign to a particular user.
为了支持注册器的搜索，家庭网络包含一个或多个SIP服务器，这些服务器可以在DNS中配置为具有SIP的NAPTR/SRV记录。这些是家庭网络边缘代理。他们的任务是充当家庭网络中的第一个联络点，并决定（在定位服务器的帮助下）将哪个SIP注册服务器分配给特定用户。
The procedures specified in RFC 3263 [10] applied to a REGISTER message seem to be sufficient to meet this requirement.
RFC 3263[10]中规定的应用于寄存器消息的程序似乎足以满足此要求。
A user must register to the IMS before he/she can receive any invitation to any sessions. In addition, it is desirable for the user to register before initiating any sessions. The following factors contribute to the rationale behind this:
用户必须先注册到IMS，然后才能收到任何会话邀请。此外，希望用户在启动任何会话之前进行注册。以下因素促成了这一点背后的基本原理：
1. The SIP serving proxy in the home network needs to know when and from which terminal the user is available, in order to route received SIP requests for sessions and services.
1. 家庭网络中的SIP服务代理需要知道用户何时以及从哪个终端可用，以便为会话和服务路由接收到的SIP请求。
2. The user can be pre-authenticated early so that authentication does not contribute to post-dial delay. The procedure should not have a penalty on the session setup time (see also the requirement stated in Section 4.1.2).
2. 可以提前对用户进行预身份验证，以便身份验证不会导致拨号后延迟。该程序不应对会话设置时间进行处罚（另请参见第4.1.2节中规定的要求）。
3. The user is assigned a particular serving proxy. The serving proxy downloads the service profile for that user to trigger services.
3. 为用户分配了一个特定的服务代理。服务代理下载该用户的服务配置文件以触发服务。
Therefore, 3GPP has mandated the mobile device UA to register before the mobile device UA initiates any session.
因此，3GPP已强制移动设备UA在移动设备UA发起任何会话之前进行注册。
Due to the scarce radio interface resource, a single registration must be sufficient to ensure that the mobile UA is reachable from both the home and the visited networks.
由于无线接口资源稀缺，单个注册必须足以确保移动UA可以从家庭和访问的网络访问。
A single REGISTER message, addressed to the registrar, may traverse the SIP outbound proxy. This can install, if needed, soft registration states in the SIP outbound proxy.
发送给注册器的单个寄存器消息可以遍历SIP出站代理。如果需要，可以在SIP出站代理中安装软注册状态。
Independent of whether the UA is roaming, it is desirable for the registration procedure to be the same.
与UA是否漫游无关，希望注册过程相同。
The home network must be able to validate the existence of a roaming agreement between the home and the visited network. The home network needs to validate that the user is allowed to roam to such a visited network. Therefore, there must be a mechanism whereby the visited network identity is known at registration time at the home network.
家庭网络必须能够验证家庭和访问网络之间是否存在漫游协议。家庭网络需要验证是否允许用户漫游到这样一个访问过的网络。因此，必须存在这样一种机制，即在家庭网络的注册时知道访问的网络身份。
It is acceptable to represent the visited network identity either as a visited network domain name or as a string.
可以将访问的网络标识表示为访问的网络域名或字符串。
There must be a procedure for a user to de-register from the network. This procedure may be used, for example, when the user deactivates the terminal.
必须有一个用户从网络注销的过程。例如，当用户停用终端时，可以使用该过程。
We believe that a REGISTER with an expiration timer of 0 will meet the requirement.
我们相信过期计时器为0的寄存器将满足要求。
In a number of situations a network needs to de-register or trigger a re-registration of a previously registered UA. Examples of usage are described in sections 4.3.6.3, 4.3.6.4, and 4.3.6.5.
在许多情况下，网络需要注销或触发先前注册的UA的重新注册。第4.3.6.3节、第4.3.6.4节和第4.3.6.5节描述了使用示例。
This implies a need for a notification mechanism whereby the UA can be notified of the de-registration, or of a request for re-registration.
这意味着需要一种通知机制，通过该机制可以通知UA取消注册或重新注册的请求。
We believe that this requirement is met by the SIP-specific event notification [12] and a registration event package [14].
我们认为SIP特定事件通知[12]和注册事件包[14]满足了这一要求。
There might be cases in which the SIP serving proxy has to shutdown; e.g., due to maintenance operation. Although this situation is not likely to happen in everyday situations, it is desirable to have a mechanism to inform the UA that his current registration is being cancelled. The UA may initiate another registration process that will lead to the selection of a new SIP serving proxy.
可能存在SIP服务代理必须关闭的情况；e、 例如，由于维护操作。虽然这种情况在日常情况下不太可能发生，但最好有一种机制通知UA其当前注册正在被取消。UA可以发起另一个注册过程，该过程将导致选择新的SIP服务代理。
The system must support a mechanism to avoid inconsistent information storage and to remove any redundant registration information. This case will occur when a subscriber roams to a different network without a prior de-registration. This case occurs in normal mobility procedures when the user roams from one access network to another, or when new service conditions are imposed on roamers.
系统必须支持一种机制，以避免不一致的信息存储和删除任何冗余的注册信息。当订户在未事先取消注册的情况下漫游到不同的网络时，就会发生这种情况。当用户从一个接入网络漫游到另一个接入网络时，或者当对漫游者施加新的服务条件时，在正常的移动过程中发生这种情况。
For different reasons (e.g., subscription termination, stolen terminal, etc.) a home network administrative function may determine a need to clear a user's SIP registration. It is desirable to have a mechanism whereby the SIP serving proxy can inform the UA that its registration is being cancelled.
出于不同的原因（例如，订阅终止、被盗终端等），家庭网络管理功能可以确定是否需要清除用户的SIP注册。希望具有一种机制，使得SIP服务代理能够通知UA其注册正在被取消。
There must be a procedure for the SIP serving proxy to de-register users. The de-registration information must be available at all the proxies that keep registration state and the UA.
SIP服务代理必须有一个过程来注销用户。注销信息必须在保持注册状态的所有代理和UA处可用。
We believe that a procedure based on SIP-specific event notification [12] and a registration event package [14] will meet this requirement.
我们相信，基于SIP特定事件通知[12]和注册事件包[14]的程序将满足这一要求。
The radio interface is a scarce resource, and typically the available bandwidth over the radio interface is limited. These two factors seem to limit the transport of possibly large SIP messages over the air interface. Particularly, the session setup time might be extended due to the time needed to transport SIP messages over a limited bandwidth channel.
无线电接口是一种稀缺资源，并且通常无线电接口上的可用带宽是有限的。这两个因素似乎限制了通过空中接口传输可能较大的SIP消息。特别地，由于在有限带宽信道上传输SIP消息所需的时间，会话设置时间可能会延长。
On the other hand, the number and size of certain SIP header values, such as Via or Record-Route, seems not to be limited. A mobile device UA may present limitations in the available memory to store this kind of information.
另一方面，某些SIP报头值（例如Via或Record Route）的数量和大小似乎没有限制。移动设备UA可在可用存储器中存在限制以存储此类信息。
Therefore, there must be a mechanism to efficiently transport SIP signaling packets over the radio interface, by compressing the SIP messages between the mobile device UA and the SIP outbound proxy, and between the SIP outbound proxy and the mobile device UA. Note that compression of IP and transport layer protocol headers that carry these SIP messages is also a requirement, although we believe that this does not have an impact on SIP.
因此，必须存在通过压缩移动设备UA和SIP出站代理之间以及SIP出站代理和移动设备UA之间的SIP消息，在无线电接口上高效地传输SIP信令分组的机制。请注意，承载这些SIP消息的IP和传输层协议头的压缩也是一项要求，尽管我们认为这对SIP没有影响。
The chosen solution(s) must be able to allow the operation under several different compression algorithms.
选择的解决方案必须能够允许在几种不同的压缩算法下进行操作。
The chosen solution(s) must be extensible to facilitate the incorporation of new and improved compression algorithms in a backward-compatible way, as they become available.
所选择的解决方案必须是可扩展的，以便在新的和改进的压缩算法可用时，以向后兼容的方式合并它们。
Application-specific compression must minimize impacts on existing 3GPP access networks (such as base stations transceivers). On the other hand, the compression mechanism should be independent of the access; e.g., the compression must be defined between the mobile device UA and the outbound SIP proxy.
特定于应用的压缩必须最小化对现有3GPP接入网络（例如基站收发器）的影响。另一方面，压缩机制应独立于访问；e、 例如，必须在移动设备UA和出站SIP代理之间定义压缩。
It must be possible to leave the usage of compression for SIP signaling optional. To facilitate mobile terminal roaming between networks that are using compression, the mobile terminal should always support SIP signaling compression. If compression is not supported, communication may continue without compression, depending on the local policy of the visited network.
对于SIP信令，必须可以选择使用压缩。为了便于移动终端在使用压缩的网络之间漫游，移动终端应始终支持SIP信令压缩。如果不支持压缩，则根据访问网络的本地策略，通信可以在不进行压缩的情况下继续。
The compression mechanism should be reliable and able to recover automatically from errors generated during the decompression.
压缩机制应可靠，并能够从解压缩过程中产生的错误中自动恢复。
The selection of QoS signaling and resource allocation schemes must be independent of the selected session control protocols. This allows for independent evolution of QoS control and SIP.
QoS信令和资源分配方案的选择必须独立于所选的会话控制协议。这允许QoS控制和SIP的独立演进。
In establishing a SIP session, it must be possible for an application to request that the resources needed for bearer establishment are successfully allocated before the destination user is alerted. Note, however, that it must be also possible for an SIP application in a terminal to alert the user before the radio resources are established (e.g., if the user wants to participate in the media negotiation).
在建立SIP会话时，应用程序必须能够在向目标用户发出警报之前请求成功分配承载建立所需的资源。然而，注意，终端中的SIP应用也必须能够在无线资源建立之前（例如，如果用户想要参与媒体协商）向用户发出警报。
We believe that this requirement is met by Integration of Resource Management and SIP [15].
我们认为，通过整合资源管理和SIP[15]，可以满足这一要求。
In establishing a SIP session, it must be possible for a terminating application to allow the destination user to participate in determining which bearers will be established. However, it must be possible to establish the SIP session without user intervention.
在建立SIP会话时，终端应用程序必须允许目标用户参与确定将建立哪些承载。但是，必须能够在没有用户干预的情况下建立SIP会话。
We believe that this requirement is met by the standard SDP negotiation described in SIP [2], the SDP offer/answer model [11] and the extensions described in Integration of Resource Management and SIP
我们相信，SIP[2]中描述的标准SDP协商、SDP提供/应答模型[11]以及资源管理和SIP集成中描述的扩展满足了这一要求
Successful bearer establishment must include the completion of any required end-to-end QoS signaling, negotiation, and resource allocation.
成功的承载建立必须包括完成任何所需的端到端QoS信令、协商和资源分配。
We believe that this requirement is met by the procedures described in the Integration of Resource Management and SIP [15].
我们认为，资源管理和SIP集成[15]中描述的程序满足了这一要求。
Typically, users are allocated QoS resources. There is an admission control mechanism that prevents users exceeding the limits negotiated with the network. The network must prevent unauthorized users to make use of non-authorized resources. For instance, the network must provide a mechanism to prevent a user from using the resources allocated to a second user, and for which this second user may be paying.
通常，为用户分配QoS资源。有一种准入控制机制，防止用户超过与网络协商的限制。网络必须防止未经授权的用户使用未经授权的资源。例如，网络必须提供一种机制来防止用户使用分配给第二用户的资源，并且该第二用户可能为此付费。
We believe that this requirement may be met by the procedures described in the Private SIP extensions for Media Authorization [16].
我们相信，媒体授权专用SIP扩展[16]中描述的程序可以满足这一要求。
As radio resources are very valuable, the network must be able to manage them in a controlled manner. The network must be able to identify who is using these resources and to authorize their usage. For example, a mobile device terminal could execute an unlimited and uncontrolled resource reservation procedure if the network does not supervise the usage of radio resources.
由于无线电资源非常宝贵，网络必须能够以可控的方式管理它们。网络必须能够识别谁在使用这些资源并授权其使用。例如，如果网络不监督无线电资源的使用，则移动设备终端可以执行无限和不受控制的资源保留过程。
We believe that this requirement is met by the procedures described in the Private SIP extensions for Media Authorization [16].
我们认为，媒体授权专用SIP扩展[16]中描述的程序满足了这一要求。
The 3GPP IMS must prevent mobile devices from making malicious use of the network. For instance, a malicious UA could not obey the procedures related to the Record-Route header field: when sending subsequent requests the UA could bypass proxies which inserted a Record-Route header during the initial transaction.
3GPP IMS必须防止移动设备恶意使用网络。例如，恶意UA无法遵守与记录路由头字段相关的过程：在发送后续请求时，UA可以绕过在初始事务期间插入记录路由头的代理。
The risk that a proxy will receive a denial of service attack should be minimized. For instance, a malicious mobile device could learn a SIP proxy IP address and port number (e.g., in a Record-Route header value) and establish an attack upon that proxy.
代理将受到拒绝服务攻击的风险应降至最低。例如，恶意移动设备可以学习SIP代理IP地址和端口号（例如，在记录路由头值中），并对该代理发起攻击。
In order to use the 3GPP IMS, a user is assigned a private user identity. The home network operator assigns the private user identity, which is used to identify the user uniquely from a network perspective. The private user identity is used, for example, for authentication, authorization, administration, and, possibly, accounting purposes. Note that the private user identity is not used for routing of SIP messages.
为了使用3GPP IMS，向用户分配了私有用户标识。家庭网络运营商分配专用用户标识，用于从网络角度唯一标识用户。私人用户标识例如用于身份验证、授权、管理和（可能的）记帐目的。请注意，专用用户标识不用于SIP消息的路由。
The private user identity is a unique global identity defined by the Home Network Operator. The identity takes the form of a Network Access Identifier (NAI) as defined in RFC 2486 [6].
专用用户标识是由家庭网络运营商定义的唯一全局标识。标识采用RFC 2486[6]中定义的网络访问标识符（NAI）的形式。
The end user does not have access to the private user identity. Typically the identity is stored in a Subscriber Identity Module card.
最终用户无权访问专用用户标识。通常，标识存储在用户标识模块卡中。
The private user identity is permanently allocated to a user (it is not a dynamic identity), and is valid for the duration of the user's business subscription with the home network.
专用用户标识永久分配给用户（不是动态标识），并且在用户与家庭网络的业务订阅期间有效。
The mobile UA must deliver the private user identity to the SIP outbound proxy and the registrar at registration time.
移动UA必须在注册时向SIP出站代理和注册器交付私人用户身份。
The private user identity is used as the basis for authentication during registration of the mobile user. The term authentication is used in this document with the same meaning as it is defined in RFC 2828 [7].
在移动用户注册期间，私有用户身份用作认证的基础。本文件中使用的术语身份验证的含义与RFC 2828[7]中定义的含义相同。
We believe that this requirement is met by populating the username field of the Authorization: header value of the REGISTER request with the private user identity.
我们认为，通过使用私有用户标识填充Authorization:REGISTER请求的header值的username字段可以满足这一要求。
In order to use the 3GPP IMS, a user is assigned one or more public user identities. The user will make use of the public user identity/ identities when requesting communication to other users. For example, the public user identity might be included on a business card.
为了使用3GPP IMS，向用户分配一个或多个公共用户身份。当请求与其他用户通信时，用户将使用公共用户标识。例如，公共用户身份可能包含在名片上。
Different public user identities may be grouped into a user profile. A user may have different profiles, each one containing different public user identities. A public user identity can be part of a single user profile.
可以将不同的公共用户标识分组到用户配置文件中。用户可能有不同的配置文件，每个配置文件包含不同的公共用户身份。公共用户标识可以是单个用户配置文件的一部分。
The user may need to register one or more public user identities prior to receiving communications addressed to that public user identity.
用户可能需要在接收发往该公共用户标识的通信之前注册一个或多个公共用户标识。
We believe that this requirement is met by populating the From: and To: header values of a REGISTER message with the public user identity.
我们认为，通过使用公共用户标识填充REGISTER消息的From:和To:头值可以满足这一要求。
The public user identity must take the form of a SIP URI (as defined in RFC 3261 [2] and RFC 2396 [4]) or of a E.164 [34] number.
公共用户标识必须采用SIP URI（如RFC 3261[2]和RFC 2396[4]中所定义）或E.164[34]号的形式。
We believe that this requirement is met by using SIP URLs and telephone numbers represented in SIP URLs as described in SIP [3]. In addition, tel: URLs as specified in RFC 3966 [35] can be used to fulfill the requirement.
我们认为，通过使用SIP URL和SIP URL中表示的电话号码（如SIP[3]中所述），可以满足这一要求。此外，RFC 3966[35]中规定的tel:URL可用于满足要求。
It must be possible to register globally (i.e., through one single UA request) a user that has more than one public identity that belongs to the same user profile, via a mechanism within the IMS. In this case, the user will be registered with all the public identities associated to a user profile.
必须能够通过IMS内的机制全局（即，通过一个UA请求）注册具有属于同一用户简档的多个公共身份的用户。在这种情况下，用户将使用与用户配置文件关联的所有公共标识进行注册。
We believe this requirement may be accomplished by external procedures. For example, the user's profile may contain a list of alias identities that the registrar considers active if the primary identity is registered. The user may get informed of the automatically registered public user IDs by subscribing to its own registration state.
我们相信这一要求可以通过外部程序来实现。例如，如果注册了主标识，则用户的简档可以包含注册器认为是活动的别名标识的列表。用户可以通过订阅其自己的注册状态来获得自动注册的公共用户id的通知。
Public user identities are not authenticated by the 3GPP IMS. However, the network authorizes that the public user identity is associated with the registered private user identity.
公共用户身份未经3GPP IMS认证。然而，网络授权公共用户身份与注册的私有用户身份相关联。
There is a list of public user identities associated with each private user ID within the IMS. IMS will reject attempts to use other public identities with this private user ID.
IMS中有一个与每个私有用户ID相关联的公共用户标识列表。IMS将拒绝使用此私人用户ID的其他公共身份的尝试。
Typically a UA will be registered under a set of different public user IDs. As such, sessions destined to the user can be placed with any of the registered public user IDs. The serving proxy and application server(s) in the termination network may apply certain filtering rules or services based on the public user ID contained in the Request-URI. The UA may also apply certain filtering rules or services based on the called public user ID.
通常，UA将在一组不同的公共用户ID下注册。因此，目的地为用户的会话可以与任何注册的公共用户id一起放置。终端网络中的服务代理和应用服务器可以基于包含在请求URI中的公共用户ID应用某些过滤规则或服务。UA还可以基于被叫公共用户ID应用某些过滤规则或服务。
Therefore, it must be possible for all sessions to deliver the dialed public user ID to the terminating entities, such as the serving proxy, application servers, and terminating UA.
因此，所有会话都必须能够将拨出的公共用户ID传递给终端实体，例如服务代理、应用服务器和终端UA。
Routing of SIP signaling within IMS must use SIP URLs as defined in SIP [2]. E.164 [34] format public user identities must not be used for routing within IMS, and session requests based on E.164 format public user identities will require conversion into SIP URI format for internal IMS usage.
IMS内SIP信令的路由必须使用SIP[2]中定义的SIP URL。E.164[34]格式的公共用户标识不得用于IMS内的路由，基于E.164格式的公共用户标识的会话请求将需要转换为SIP URI格式，以便内部IMS使用。
We believe that this requirement is achieved by translating E.164 numbers into SIP URIs. A database, such as ENUM [9], might do the job.
我们相信，通过将E.164编号转换为SIPURI，可以实现这一要求。数据库（如ENUM[9]）可能会执行此任务。
Although the requirements included in this section are not optional, the hiding feature is optional to use through configuration. This means that a network operator can, at his desire, switch the hiding functionality on or off.
尽管本节中包含的要求不是可选的，但隐藏功能是可选的，可以通过配置使用。这意味着网络运营商可以根据需要打开或关闭隐藏功能。
A network operator need not be required to reveal the internal network structure to another network (in Via, Route, or other headers) that may contain indication of the number of SIP proxies, domain name of the SIP proxies, capabilities of the SIP proxies, or capacity of the network.
网络运营商无需向另一个网络（在Via、Route或其他报头中）透露内部网络结构，该网络可能包含SIP代理的数量、SIP代理的域名、SIP代理的能力或网络的容量的指示。
A network need not be required to expose the explicit IP addresses of the nodes within the network (excluding firewalls and border gateways).
网络无需公开网络内节点的显式IP地址（不包括防火墙和边界网关）。
In order to support the hiding requirements, a SIP hiding proxy may be included in the SIP signaling path. This additional proxy may be used to shield the internal structure of a network from other networks.
为了支持隐藏需求，SIP隐藏代理可以包括在SIP信令路径中。此附加代理可用于屏蔽网络内部结构与其他网络。
The identity of the cell through which the 3GPP UA is accessing the IMS (Cell-ID) may be used by the home network to provide localized services or information on the location of the terminal during an emergency call (when emergency calls are handled in IMS; see also the requirement stated in Section 4.16).
3GPP UA通过其访问IMS的小区标识（小区标识）可由家庭网络用于在紧急呼叫期间（当在IMS中处理紧急呼叫时；另请参见第4.16节中所述的要求）提供关于终端位置的本地化服务或信息。
4.13.1. Cell-ID in Signaling from the UA to the Visited and Home Networks
4.13.1. 从UA到到访网络和家庭网络的信令中的小区ID
Assuming that the Cell-ID is obtained by the UA by other mechanisms outside the scope of SIP, the Cell-ID must be transported at least in the following procedures:
假设UA通过SIP范围之外的其他机制获得小区ID，则必须至少在以下过程中传输小区ID：
o Registration o Session Establishment (Mobile Originated) o Session Establishment (Mobile Terminated) o Session Release
o 注册o会话建立（移动发起）o会话建立（移动终止）o会话释放
The Cell-ID is private information and only of interest in the UA home network. Therefore, the Cell-ID should be removed prior to sending the SIP signaling beyond the originating home network.
小区ID是私人信息，仅在UA家庭网络中有意义。因此，在将SIP信令发送到发起家庭网络之外之前，应当移除小区ID。
The cell-ID must be sent in any of the formats described in the 3GPP Technical Specification 23.003 [26].
小区ID必须以3GPP技术规范23.003[26]中描述的任何格式发送。
In addition to the normal mechanisms for releasing a SIP session (e.g., BYE), two cases are considered in this section: the ungraceful session release (e.g., the terminal moves to an out-of-coverage zone) and the graceful session release ordered by the network (e.g., prepaid caller runs out of credit).
除了用于释放SIP会话（例如，BYE）的正常机制外，本节还考虑了两种情况：不正常的会话释放（例如，终端移动到覆盖区外）和由网络命令的正常会话释放（例如，预付费呼叫方信用耗尽）。
We believe that this requirement is met by a SIP entity acting as a so-called transparent back-to-back UA.
我们认为，SIP实体作为所谓的透明背对背UA满足了这一要求。
If an ungraceful session termination occurs (e.g., a flat battery or a mobile leaves coverage), when a call stateful SIP proxy server (such as the SIP serving proxy at home) is involved in a session, memory leaks and, eventually, server failure can occur due to hanging state machines. To ensure stable server operation and carrier grade service, a mechanism to handle the ungraceful session termination issue must be provided. We assume that there is a mechanism by which the SIP outbound proxy is notified, by a mechanism external to SIP, of the ungraceful session termination. This allows transforming the ungraceful session release into a graceful session release ordered by the network (see the next section). For example, upon reception of the notification of loss of mobile radio coverage, the SIP outbound proxy could send a BYE request on behalf of the terminal, although this BYE cannot be authenticated.
如果发生不正常会话终止（例如，电池耗尽或移动设备离开覆盖范围），则当会话中涉及呼叫状态SIP代理服务器（例如在家中提供SIP服务的代理）时，内存泄漏，并最终由于挂起状态机而发生服务器故障。为了确保稳定的服务器运行和运营商级服务，必须提供一种机制来处理不正常的会话终止问题。我们假设存在一种机制，通过该机制，SIP出站代理可以通过SIP外部的一种机制通知非竞争性会话终止。这允许将不正常的会话释放转换为由网络订购的正常会话释放（请参阅下一节）。例如，在接收到移动无线电覆盖丢失的通知时，SIP出站代理可以代表终端发送BYE请求，尽管该BYE不能被认证。
There must be a mechanism whereby an entity in the network may order the release of resources to other entities. This may be used, for example, in prepaid calls when the user runs out of credit.
必须有一种机制，使网络中的一个实体可以命令向其他实体释放资源。例如，在预付费通话中，当用户用完信用卡时，可以使用此功能。
This release must not involve any request to the UA to send out a release request (BYE), as the UA might not follow this request. The receiving entity needs the guarantee that resources are released when requested by the ordering entity.
此发布不得涉及向UA发出发布请求（BYE）的任何请求，因为UA可能不会遵循此请求。接收实体需要保证在订购实体请求时释放资源。
The following objectives must be met:
必须达到以下目标：
o Accurately report the termination to the charging subsystem.
o 准确地向充电子系统报告终端。
o Release the associated network resources: bearer resources and signaling resources.
o 释放关联的网络资源：承载资源和信令资源。
o Notify other parties to the session, if any, of the session termination.
o 将会议终止通知会议的其他各方（如有）。
When feasible, this mechanism should be at the SIP protocol level in order to guarantee access independence for the system.
在可行的情况下，该机制应处于SIP协议级别，以保证系统的访问独立性。
The 3GPP architecture includes a SIP outbound proxy that is typically located in the visited network (although it may be located in the home network). This outbound proxy provides local services such as compression of SIP messages or security functions. In addition, the outbound proxy may interact with the media reservation mechanism to provide authentication and authorization support for media reservation.
3GPP体系结构包括SIP出站代理，该代理通常位于到访网络中（尽管它可能位于家庭网络中）。此出站代理提供本地服务，如SIP消息压缩或安全功能。此外，出站代理可以与媒体预约机制交互，以提供对媒体预约的认证和授权支持。
All mobile terminal originated session setup attempts must transit the outbound proxy so that the services provided by the outbound proxy can be delivered to the mobile terminal.
所有源自移动终端的会话设置尝试都必须传输出站代理，以便将出站代理提供的服务交付给移动终端。
The serving proxy in the home network allows triggering of user-customized services that are typically executed in an application server.
家庭网络中的服务代理允许触发通常在应用服务器中执行的用户自定义服务。
All mobile terminal originated session setup attempts must transit the serving proxy in the home network so that the proxy can properly trigger the SIP services allocated to the user (e.g., speed dial substitution). This implies a requirement for some sort of source-routing mechanism to ensure these proxies are transited correctly.
所有源自移动终端的会话设置尝试必须在家庭网络中传输服务代理，以便该代理能够正确触发分配给用户的SIP服务（例如，快速拨号替换）。这意味着需要某种源路由机制来确保这些代理正确传输。
The path taken by an INVITE request need not be restricted to the specific path taken by a mobile terminal originated REGISTER request; e.g., the INVITE may traverse just the SIP outbound proxy and the SIP serving proxy, without passing through any other proxies. However, the path taken by the INVITE may follow the same path taken by the REGISTER.
INVITE请求所采用的路径不需要限制为移动终端发起的注册请求所采用的特定路径；e、 例如，INVITE可以只遍历SIP出站代理和SIP服务代理，而不经过任何其他代理。但是，INVITE采用的路径可能与寄存器采用的路径相同。
The visited network may apply certain services and policies to incoming sessions (such as establishment of security services or interaction with the media reservation mechanism). Therefore, the visited network may contain a SIP inbound proxy for terminating sessions. In general, the SIP inbound proxy and the SIP outbound proxy are the same SIP proxy.
所访问的网络可将某些服务和策略应用于传入会话（例如建立安全服务或与媒体预约机制的交互）。因此，所访问的网络可能包含用于终止会话的SIP入站代理。通常，SIP入站代理和SIP出站代理是相同的SIP代理。
Sections 4.15.2 and 4.15.4 assume that a source-routing mechanism is used to effect traversal of the required SIP proxies during session setup.
第4.15.2节和第4.15.4节假设在会话设置期间使用源路由机制来实现所需SIP代理的遍历。
There must be some means of dynamically informing the node that adds the source-routing set of proxies that the INVITE has to traverse (e.g., the outbound proxy or serving proxy) of what that set of proxies should be.
必须有某种方法动态通知添加INVITE必须遍历的源路由代理集（例如，出站代理或服务代理）的节点该代理集应该是什么。
The hiding requirements expressed in Section 4.12 also apply to the said set of proxies.
第4.12节所述的隐藏要求也适用于所述代理集。
3GPP networks already contain alternative procedures for delivering emergency sessions. Release 5 of the 3GPP specifications does not add any requirement for SIP emergency sessions.
3GPP网络已经包含用于提供紧急会话的替代程序。3GPP规范的第5版没有增加SIP紧急会话的任何要求。
It must be possible to present to the caller the identity of the party to which he/she may dial back to return a call.
必须能够向呼叫者提供他/她可以拨回回电话的一方的身份。
We believe that this requirement is met by the procedures described in RFC 3325 [17].
我们认为，RFC 3325[17]中描述的程序满足了这一要求。
In addition to the previous requirement, the called party must be able to request that his/her identity not be revealed to the caller.
除上述要求外，被叫方还必须能够要求不向呼叫者透露其身份。
We believe that this requirement is met by the procedures described in RFC 3323 [18].
我们认为，RFC 3323[18]中描述的程序满足了这一要求。
Regulatory agencies, as well as subscribers, may require the ability of callers to block the display of their caller identification. The destination subscriber's SIP serving proxy may be perform this function. In this way, the destination subscriber is still able to do a session-return, session-trace, transfer, or any other supplementary service.
监管机构以及用户可能要求呼叫者能够阻止显示其呼叫者身份。目标订户的SIP服务代理可以执行此功能。这样，目标订户仍然能够执行会话返回、会话跟踪、传输或任何其他补充服务。
Therefore, it must be possible that the caller request to block the display of his/her identity on the callee's display.
因此，呼叫者必须有可能请求阻止他/她的身份在被呼叫者的显示器上显示。
We believe that this requirement is met by the procedures described in RFC 3323 [18].
我们认为，RFC 3323[18]中描述的程序满足了这一要求。
Procedures are required for anonymous session establishment. However, sessions are not intended to be anonymous to the originating or terminating network operators.
匿名会话的建立需要过程。但是，会话对于发起或终止的网络运营商来说不是匿名的。
We believe that this requirement is met by the procedures described in RFC 3323 [18] and RFC 3325 [17].
我们认为，RFC 3323[18]和RFC 3325[17]中描述的程序满足了这一要求。
If the caller requests that the session be anonymous, the User Agent Client (UAC) must not reveal any identity information to the User Agent Server (UAS).
如果调用方请求会话匿名，则用户代理客户端（UAC）不得向用户代理服务器（UAS）透露任何身份信息。
If the caller requests that the session be anonymous, the terminating network must not reveal any identity or signaling routing information to the destination endpoint. The terminating network should distinguish at least two cases: first, whether the caller intended the session to be anonymous, and second, whether the caller's identity was deleted by a transit network.
如果呼叫者请求会话是匿名的，则终止网络不得向目标端点透露任何身份或信令路由信息。终止网络应至少区分两种情况：第一，呼叫者是否有意匿名会话，第二，呼叫者的身份是否被传输网络删除。
We believe that this requirement is met by the procedures described in RFC 3323 [18] and RFC 3325 [17].
我们认为，RFC 3323[18]和RFC 3325[17]中描述的程序满足了这一要求。
The 3GPP charging implications are described in the 3GPP Technical Specification 32.225 [31].
3GPP技术规范32.225[31]中描述了3GPP收费影响。
Operators may choose to offer prepaid and/or postpaid services. The prepaid model is accomplished with the support of the online charging model. The postpaid model is accomplished with the support of the offline charging model.
运营商可以选择提供预付费和/或后付费服务。预付费模式是在在线收费模式的支持下实现的。后付费模式是在离线收费模式的支持下实现的。
Online charging is the process whereby charging information can affect, in real-time, the service rendered to the user, such as a request for a graceful release of an existing session. Online charging interacts with the SIP signaling.
在线计费是指计费信息可以实时影响向用户提供的服务的过程，例如请求优雅地释放现有会话。在线充电与SIP信令交互。
Offline charging is the process whereby charging information does not affect, in real-time, the service rendered to the user.
离线收费是指收费信息不会实时影响向用户提供的服务的过程。
The following levels of correlation for IMS charging are considered:
考虑了IMS充电的以下相关级别：
o Correlation within a session. A session may comprise a number of media components. It must be possible to correlate the charging data of the different media components belonging to a session.
o 会话中的相关性。会话可以包括多个媒体组件。必须能够关联属于会话的不同媒体组件的计费数据。
o Correlation at media-component level. For a session comprising several media types (such as audio and video), charging data is generated for each media type and needs to be correlated between network elements. For this, a media identifier will be unique and will clearly identify which media type of a session this charging information belongs to. This component identifier is not exchanged between network elements and is based on the ordering of media flows in the SDP. This ordering is the same as that used in the binding information passed to the GPRS network.
o 媒体组件级别的相关性。对于包含多种媒体类型（例如音频和视频）的会话，为每种媒体类型生成计费数据，并且需要在网络元素之间关联。为此，媒体标识符将是唯一的，并将清楚地标识此计费信息所属会话的媒体类型。该组件标识符不在网元之间交换，而是基于SDP中媒体流的顺序。此顺序与传送到GPRS网络的绑定信息中使用的顺序相同。
To support the correlation of charging information, the following principles apply to both offline and online charging:
为支持收费信息的相关性，以下原则适用于离线和在线收费：
o The correlation of charging information for an IMS session is based on the use of IMS Charging Identifiers (ICID).
o IMS会话的计费信息的相关性基于IMS计费标识符（ICID）的使用。
o The first IMS network entity within the SIP signaling path is responsible for assigning an ICID. This ICID will then be passed along the whole session path in an end-to-end manner. However, this will not preclude further elements (other SIP proxies) along the session path from generating additional identifiers to be passed along.
o SIP信令路径内的第一IMS网络实体负责分配ICID。然后，该ICID将以端到端的方式沿整个会话路径传递。但是，这不会阻止会话路径上的其他元素（其他SIP代理）生成要传递的附加标识符。
o The ICID is passed to all IMS network entities in the session signaling path. This is performed using SIP signaling.
o ICID被传递到会话信令路径中的所有IMS网络实体。这是使用SIP信令执行的。
o The addresses of the charging functions are passed by the serving SIP proxy to all IMS network entities in the session signaling path. This is to provide a common destination for all the charging records generated by each IMS network entity with the same ICID.
o 计费功能的地址由服务SIP代理传递给会话信令路径中的所有IMS网络实体。这是为了为具有相同ICID的每个IMS网络实体生成的所有计费记录提供一个公共目的地。
o For the charging correlation between the GPRS network and the IMS, one or more GPRS Charging IDs, which identify the PDP contexts of the session, are passed from the GPRS network to the IMS.
o 对于GPRS网络和IMS之间的计费相关性，一个或多个GPRS计费ID（标识会话的PDP上下文）从GPRS网络传递到IMS。
o The GPRS Charging IDs are passed by the outbound SIP proxy to the serving SIP proxy and the Application Servers using SIP signaling. They are not transferred from one home IMS (e.g., caller's home) to another (e.g., callee's home).
o GPRS计费ID由出站SIP代理通过SIP信令传递给服务SIP代理和应用服务器。它们不会从一个家庭IMS（例如，呼叫者的家庭）传输到另一个家庭IMS（例如，被呼叫者的家庭）。
o Inter Operator Identifiers (IOI) are shared between the caller's home IMS and the callee's home IMS to provide identifiers of the home originating and home terminating networks.
o 在呼叫者的归属IMS和被呼叫者的归属IMS之间共享操作员间标识符（IOI），以提供归属始发网络和归属终接网络的标识符。
The SIP serving proxy or another SIP server in the home network must be able to log details of all sessions, such as the duration, source, and destination of a session, to provide to the charging subsystem.
SIP服务代理或家庭网络中的另一个SIP服务器必须能够记录所有会话的详细信息，例如会话的持续时间、源和目标，以提供给计费子系统。
3GPP is interested in applying and using additional services, such as those described in SIP Call Control - Transfer [20], SIP Basic Call Flow Examples [21], SIP Public Switched Telephone Network (PSTN) Call Flows [22], and SIP service examples [23]. Although 3GPP is not going to standardize additional services, 3GPP may make sure that the capabilities that enable those services are granted in the network.
3GPP对应用和使用附加服务感兴趣，例如SIP呼叫控制-转移[20]、SIP基本呼叫流示例[21]、SIP公共交换电话网（PSTN）呼叫流[22]和SIP服务示例[23]中描述的服务。尽管3GPP不会标准化附加服务，但3GPP可能会确保在网络中授予启用这些服务的能力。
Therefore, we believe that the SIP REFER method [24] and the Replaces header [25] constitute a complement to be used as an enabler in order to meet the above requirement.
因此，我们认为SIP refere方法[24]和Replaces报头[25]构成了一个补充，可以用作启用码，以满足上述要求。
Support for voice calls must provide a level of service similar to that of the existing circuit-based voice service. This includes the ability to use DTMF signaling, for example, for control of interactive voice response systems such as ticket sales lines and timetable information.
对语音呼叫的支持必须提供与现有基于电路的语音服务类似的服务级别。这包括使用DTMF信号的能力，例如，用于控制交互式语音响应系统，如售票线路和时刻表信息。
The transport of DTMF tones from the mobile terminal to target systems that may be in the PSTN, or to SIP-based solutions (i.e., no PSTN connection), must be supported.
必须支持将DTMF音调从移动终端传输到可能位于PSTN中的目标系统，或传输到基于SIP的解决方案（即，无PSTN连接）。
The transport of DTMF signals may be required for the whole call, just for the first part, or from some later point in the call. The start time and duration of such signaling is therefore unpredictable.
整个通话可能需要传输DTMF信号，仅在第一部分，或从通话中的某个稍后点开始。因此，此类信令的开始时间和持续时间是不可预测的。
We believe that the mechanisms specified in RFC 2833 [8] meet the requirement without impacting SIP.
我们认为RFC 2833[8]中规定的机制符合要求，且不影响SIP。
As mobile terminals will frequently interoperate with the PSTN, support for early media is required.
由于移动终端将经常与PSTN进行互操作，因此需要对早期媒体的支持。
Typically a session description protocol such as SDP is used in SIP to describe the media streams and codecs needed to establish the session. SIP uses an offer/answer model of the session description, as described in RFC 3264 [11], in which one of the parties offers his session description and the other answers that offer.
通常，会话描述协议（如SDP）在SIP中用于描述建立会话所需的媒体流和编解码器。SIP使用会话描述的提供/应答模型，如RFC 3264[11]所述，其中一方提供其会话描述，另一方提供该会话描述的应答。
In the 3GPP IMS, the mobile terminals might have restrictions with the memory, DSP capacity, etc. As such, a mechanism is required by which the Session Description negotiation may conclude with one out of many codecs per media stream. Both UAC and UAS must know, prior to any media being sent or received, which codec is used for each media stream.
在3GPP IMS中，移动终端可能对存储器、DSP容量等有限制。因此，需要一种机制，通过该机制，会话描述协商可以以每个媒体流的多个编解码器中的一个来结束。在发送或接收任何媒体之前，UAC和UAS必须知道每个媒体流使用哪个编解码器。
In the 3GPP IMS, efficient use of the network and radio resources is an important requirement. As such, the network should know in advance which codec is used for a particular media stream. The network access control may use this information to grant access to the network and to control the resource utilization.
在3GPP IMS中，有效利用网络和无线电资源是一项重要的要求。因此，网络应该提前知道用于特定媒体流的编解码器。网络访问控制可以使用该信息来授予对网络的访问权并控制资源利用率。
Additionally, it is required that the party who pays for the resource utilization have the opportunity to decide which codecs to use, once both end parties are aware of the capabilities supported at the remote UA.
此外，一旦双方都知道远程UA支持的功能，则要求为资源利用率付费的一方有机会决定使用哪种编解码器。
Therefore, a mechanism is required by which both UAC and UAS have the ability to negotiate and trim down the number of codecs used per media stream, so that at the end of the negotiation there can be a reduced set of agreed codecs per media stream.
因此，需要一种机制，通过该机制，UAC和UAS都能够协商并减少每个媒体流使用的编解码器的数量，以便在协商结束时，可以减少每个媒体流的商定编解码器集。
We believe that the mechanism specified in RFC 3264 [11] meets the requirement.
我们认为RFC 3264[11]中规定的机制符合要求。
The SIP outbound proxy may contain local policy rules with respect the codecs allowed in the network. For instance, certain networks may disallow high-bandwidth-consuming audio codecs. There has to be a mechanism whereby the SIP outbound proxy can reject a session establishment attempt when a codec is prohibited in the network due to local policy.
SIP出站代理可能包含关于网络中允许的编解码器的本地策略规则。例如，某些网络可能不允许使用高带宽的音频编解码器。必须有一种机制，当由于本地策略而在网络中禁止编解码器时，SIP出站代理可以拒绝会话建立尝试。
Certain users' subscriptions may include restrictions on certain media types. For instance, a user may not be allowed to establish a video session. The SIP serving proxy in the home network downloads the user profile, which contains the rules for these kinds of restrictions.
某些用户的订阅可能包括对某些媒体类型的限制。例如，可能不允许用户建立视频会话。家庭网络中的SIP服务代理下载用户配置文件，其中包含此类限制的规则。
As the establishment of sessions traverse the SIP serving proxy in the home network, the proxy can prohibit an attempt to establish a session that includes a non-allowed media type for the user. Therefore, there has to be a mechanism whereby the SIP serving proxy can reject a session establishment attempt when the session includes a forbidden media type.
当会话的建立穿越家庭网络中的SIP服务代理时，代理可以禁止建立包括用户不允许的媒体类型的会话的尝试。因此，必须存在这样一种机制，即当会话包括禁止的媒体类型时，SIP服务代理可以拒绝会话建立尝试。
Network operators need to authenticate users to ensure that they are charged appropriately for the services they use. The re-authentication done when the user initiates a message will not suffice for this purpose, as described below.
网络运营商需要对用户进行身份验证，以确保对用户使用的服务收取适当的费用。如下文所述，当用户发起消息时进行的重新身份验证不足以实现此目的。
If the duration of the authentication period is set to a relatively low value to ensure that the user cannot incur a high amount of charges between two authentications, it may create a lot of unnecessary authentications of users that have remained largely inactive, and therefore it may use unnecessary air interface resources.
如果认证周期的持续时间被设置为相对较低的值以确保用户在两次认证之间不会招致高额费用，则它可能会创建大量不必要的用户认证，这些用户基本上保持不活动，因此它可能会使用不必要的空中接口资源。
If the duration of the authentication period is set to a relatively high value to avoid these unnecessary authentications, the risk is then that some users may incur high charges between authentications.
如果将认证周期的持续时间设置为相对较高的值以避免这些不必要的认证，则风险在于一些用户可能在认证之间产生较高的费用。
A user's authentication is automatically invalidated when a certain threshold for charges (or number, or duration of sessions) is reached without giving the user a chance to re-authenticate, even if a valid registration exists. This would not provide an adequate level of service.
当达到某个费用阈值（或会话数量或持续时间）时，即使存在有效注册，用户的身份验证也会自动失效，而不会给用户重新身份验证的机会。这将无法提供足够的服务水平。
Consequently, it must be possible for the network to initiate a re-authentication process at any time. The triggers must be set within the network and may include charging thresholds, number of events, session duration, etc.
因此，网络必须能够在任何时候发起重新认证过程。触发器必须在网络内设置，可能包括充电阈值、事件数、会话持续时间等。
Sections 4.23, 4.24, and 4.25 have been based on the 3GPP Technical Specifications 33.203 [32], 23.228 [28], and 33.210 [33].
第4.23、4.24和4.25节基于3GPP技术规范33.203[32]、23.228[28]和33.210[33]。
The scope for security of the 3GPP IMS is the SIP signaling between the various SIP entities. Protecting the end-to-end media streams may be a future extension, but it is not considered in the Release 5 version of the IMS specifications.
3GPP IMS的安全范围是各种SIP实体之间的SIP信令。保护端到端媒体流可能是未来的扩展，但在IMS规范的第5版中没有考虑到这一点。
Each operator providing IMS services acts as its own domain of trust and shares a long-term security association with its subscribers (e.g., pre-shared keys). Operators may enter into roaming agreements with other operators, in which case a certain level of trust exists between their respective domains.
Each operator providing IMS services acts as its own domain of trust and shares a long-term security association with its subscribers (e.g., pre-shared keys). Operators may enter into roaming agreements with other operators, in which case a certain level of trust exists between their respective domains.translate error, please retry
SIP UAs must authenticate to their home network before the use of IMS resources is authorized. In Release 5 of the 3GPP IMS specifications, authentication is performed during registration and re-registrations.
SIP UAs必须在授权使用IMS资源之前对其家庭网络进行身份验证。在3GPP IMS规范的版本5中，认证在注册和重新注册期间执行。
Portions of the SIP signaling must be protected hop by hop. Looking at Figure 1 in Section 3, we can distinguish two distinct zones where the required security is unique:
SIP信令的部分必须逐跳保护。查看第3节中的图1，我们可以区分两个不同的区域，其中所需的安全性是唯一的：
o Access Domain: Between the SIP user device and the visited network.
o 访问域：在SIP用户设备和访问的网络之间。
o Network Domain: Between the visited and home networks, or inside the home network.
o 网络域：在访问的网络和家庭网络之间，或家庭网络内部。
Characteristics needed in the Access Domain are quite different from those of the Network Domain because of the terminal's requirements for mobility, computation restriction, battery limit, bandwidth conservation, and radio interface. SIP entities in the access domain should be able to maintain security contexts with a large group of users in parallel. Furthermore, Access Domain provides user-specific
由于终端对移动性、计算限制、电池限制、带宽节约和无线电接口的要求，接入域所需的特性与网络域所需的特性大不相同。接入域中的SIP实体应该能够与大量用户并行维护安全上下文。此外，Access Domain还提供了特定于用户的
security associations, whereas Network Domain provides security associations between network nodes. Therefore, the weight of protocols and algorithms and their compliance with compression mechanisms are very important to Access Domain Security. It is therefore required that the security solutions allow different mechanisms in these two domains.
安全关联，而网络域提供网络节点之间的安全关联。因此，协议和算法的权重以及它们对压缩机制的遵从性对于访问域安全非常重要。因此，要求安全解决方案在这两个域中允许不同的机制。
3GPP IMS is characterized by a large subscriber base of up to a billion users, all of which must be treated in a secure manner.
3GPP IMS的特点是拥有高达10亿用户的庞大用户群，所有这些用户都必须以安全的方式处理。
The security solutions must allow global roaming among a large number of administrative domains.
安全解决方案必须允许在大量管理域之间进行全局漫游。
The wireless interface in 3GPP terminals is an expensive resource both in terms of power consumption and maximum use of scarce spectrum. Furthermore, cellular networks typically have long round-trip time delays, which must be taken in account in the design of the security solutions.
3GPP终端中的无线接口在功耗和稀缺频谱的最大使用方面都是一种昂贵的资源。此外，蜂窝网络通常具有长的往返时间延迟，在设计安全解决方案时必须考虑到这一点。
Any security mechanism that involves 3GPP terminals should not unnecessarily increase the bandwidth needs.
任何涉及3GPP终端的安全机制都不应该不必要地增加带宽需求。
All security mechanisms that involve 3GPP terminals should minimize the number of necessary extra round-trips. In particular, during normal call signaling there should not be any additional security-related messages.
所有涉及3GPP终端的安全机制应尽量减少必要的额外往返次数。特别是，在正常呼叫信令期间，不应存在任何额外的安全相关消息。
It must be possible for mobile device terminals to provide security without requiring public key cryptography and/or certificates. 3GPP IMS may, however, include optional security schemes that employ these techniques.
移动设备终端必须能够在不需要公钥加密和/或证书的情况下提供安全性。然而，3GPP IMS可以包括采用这些技术的可选安全方案。
Current HTTP authentication methods use only symmetric cryptography, as required here. Lower-layer mechanisms (IKE, TLS) require implementation of public-key cryptography e.g., Diffie-Hellman. If these lower-layer mechanisms were used, the mobile terminal would authenticate and negotiate session keys with the visited network using only symmetric methods.
根据此处的要求，当前HTTP身份验证方法仅使用对称加密。低层机制（IKE、TLS）需要实现公钥加密，例如Diffie-Hellman。如果使用这些低层机制，移动终端将仅使用对称方法与访问的网络进行身份验证和协商会话密钥。
The selected security mechanism should work with any transport protocol allowed by SIP (e.g., TCP, UDP).
所选安全机制应与SIP允许的任何传输协议（例如TCP、UDP）配合使用。
Authentication, as used in this context, means entity authentication that enables two entities to verify the identity of the respective peer.
在此上下文中使用的身份验证是指使两个实体能够验证各自对等方的身份的实体身份验证。
A strong, mutual authentication must be provided.
必须提供强有力的相互认证。
The authentication method must be able to work when there are zero or more SIP proxies in the SIP path between the authenticator and the authenticated user.
当认证者和认证用户之间的SIP路径中存在零个或多个SIP代理时，认证方法必须能够工作。
It must be possible to support extensible authentication methods. Therefore, authentication using an extensible authentication framework is strongly recommended.
必须能够支持可扩展的身份验证方法。因此，强烈建议使用可扩展的身份验证框架进行身份验证。
Authentication methods based on the secure storage of long-term keys used for authentication and the secure execution of authentication algorithms must be supported.
必须支持基于用于认证的长期密钥的安全存储和认证算法的安全执行的认证方法。
The SIP client's credentials must not be transferred as plain text.
SIP客户端的凭据不能作为纯文本传输。
3GPP intends to reuse UMTS AKA [13]. UMTS AKA applies a symmetric cryptographic scheme, provides mutual authentication, and is typically implemented on a so-called SIM card that provides secure storage on the user's side.
3GPP打算重用UMTS AKA[13]。UMTS AKA应用对称加密方案，提供相互认证，并且通常在所谓的SIM卡上实现，该SIM卡在用户侧提供安全存储。
Additional requirements related to message protection that apply to the authentication method are stated in Section 4.24.3.
第4.24.3节规定了适用于认证方法的与消息保护相关的附加要求。
SIP entities (typically a SIP client and a SIP proxy) must be able to communicate using integrity. By integrity, we mean the ability for the receiver of a message to verify that the message has not been modified in transit. SIP entities should be able to communicate confidentially. In 3GPP IMS, these protection modes must be based on initial authentication. Integrity protection and confidentiality must be possible using symmetric cryptographic keys.
SIP实体（通常是SIP客户端和SIP代理）必须能够使用完整性进行通信。完整性是指消息接收方验证消息在传输过程中未被修改的能力。SIP实体应该能够进行保密通信。在3GPP IMS中，这些保护模式必须基于初始认证。完整性保护和机密性必须能够使用对称加密密钥。
It must also be possible to handle error conditions in a satisfactory manner as to allow recovery (see also sections 4.3.6.3 and 4.14).
还必须能够以令人满意的方式处理错误条件，以允许恢复（另见第4.3.6.3和4.14节）。
It must be possible to provide this protection between two adjacent SIP entities. In future network scenarios, it may also be necessary to provide this protection through proxies, though the 3GPP Release 5 IMS does not require this.
必须能够在两个相邻的SIP实体之间提供这种保护。在未来的网络场景中，可能还需要通过代理提供这种保护，尽管3GPP Release 5 IMS不需要这种保护。
The security mechanism must be able to protect a complete SIP message.
安全机制必须能够保护完整的SIP消息。
If header compression/removal or SIP compression is applied to SIP messages, it must be compatible with message protection.
如果对SIP消息应用头压缩/删除或SIP压缩，则必须与消息保护兼容。
3GPP IMS implements distributed security functions responsible for authentication and message protection.
3GPP IMS实现了负责身份验证和消息保护的分布式安全功能。
It must be possible to perform an initial authentication based on long-term authentication credentials, followed by subsequent protected signaling that uses short-term authentication credentials, such as session keys created during initial authentication. The authentication mechanism used is able to provide such session keys. It must be possible to apply subsequent message protection as soon as possible, even during the initial authentication period.
必须能够基于长期身份验证凭据执行初始身份验证，然后是使用短期身份验证凭据（例如初始身份验证期间创建的会话密钥）的后续受保护信令。所使用的身份验证机制能够提供这样的会话密钥。必须能够尽快应用后续消息保护，即使在初始身份验证期间也是如此。
Initial authentication is performed between the SIP UA and the authenticating SIP serving proxy in the home network. However, the authentication mechanism must not require access to the long-term authentication credentials in these nodes. In the home network, the authenticating SIP serving proxy must support interaction with a dedicated authentication server in order to accomplish the authentication task. At the client side, a secured (tamper-resistant) device storing the long-term credentials of the user must perform the authentication.
初始认证在SIP UA和家庭网络中的认证SIP服务代理之间执行。但是，身份验证机制不得要求访问这些节点中的长期身份验证凭据。在家庭网络中，身份验证SIP服务代理必须支持与专用身份验证服务器的交互，以便完成身份验证任务。在客户端，存储用户长期凭据的安全（防篡改）设备必须执行身份验证。
Additionally, the SIP serving proxy that performed the initial authentication must be able to delegate subsequent SIP signaling protection (e.g., session keys for integrity or encryption) securely to an authorized SIP proxy further downstream. The tamper-resistant device at the client side must be able to delegate the session keys securely to the SIP UA.
此外，执行初始认证的SIP服务代理必须能够将后续SIP信令保护（例如，完整性或加密的会话密钥）安全地委托给更下游的授权SIP代理。客户端的防篡改设备必须能够将会话密钥安全地委托给SIP UA。
A method must be provided to negotiate the security mechanisms to be used in the access domain securely.
必须提供一种方法来安全地协商要在访问域中使用的安全机制。
This method must at least support the negotiation of different security mechanisms providing integrity protection and encryption, algorithms used within these mechanisms, and additional parameters that they require in order to be exchanged.
此方法必须至少支持提供完整性保护和加密的不同安全机制的协商、这些机制中使用的算法，以及交换所需的其他参数。
The negotiation mechanism must protect against attackers who do not have access to authentication credentials. In particular, the negotiation mechanism must be able to detect a possible man-in-the-middle attacker who could influence the negotiation result so that services with weaker security or with none are negotiated.
协商机制必须防止攻击者无法访问身份验证凭据。特别是，协商机制必须能够检测到可能影响协商结果的中间人攻击者，以便协商安全性较弱或没有安全性的服务。
A negotiation mechanism is generally required in all secure protocols to decide which security services to use and when they should be started. This security mechanism serves algorithm and protocol development as well as interoperability. Often, the negotiation is handled within a security service. For example, the HTTP authentication scheme includes a selection mechanism for choosing among appropriate algorithms. Note that when referring to negotiation we mean just the negotiation, not all functions in protocols such as IKE. For instance, we expect that the session key generation is to be a part of the initial authentication.
所有安全协议通常都需要协商机制来决定使用哪些安全服务以及何时启动这些服务。这种安全机制服务于算法和协议的开发以及互操作性。通常，协商是在安全服务中处理的。例如，HTTP认证方案包括用于在适当算法中进行选择的选择机制。注意，当提到协商时，我们指的只是协商，而不是像IKE这样的协议中的所有功能。例如，我们期望会话密钥生成是初始身份验证的一部分。
SIP entities must be able to use the same security mode parameters to protect several SIP sessions without re-negotiation. For example, security mode parameters may be assumed to be valid within the lifetime of a registration. Note that it is necessary to amortize the cost of security association setup and parameter negotiation over several INVITEs.
SIP实体必须能够使用相同的安全模式参数来保护多个SIP会话，而无需重新协商。例如，可以假设安全模式参数在注册的生存期内有效。请注意，有必要将安全关联设置和参数协商的成本分摊到多个邀请中。
The SIP outbound proxy must be able to guarantee the message origin and to verify that the message has not been changed (e.g., it is integrity protected).
SIP出站代理必须能够保证消息来源，并验证消息未被更改（例如，消息受完整性保护）。
The serving SIP proxy needs to receive an indication if the outbound proxy was able to verify the message origin and, in the case of a REGISTER request, whether or not it was integrity protected.
服务SIP代理需要接收出站代理是否能够验证消息来源的指示，以及在注册请求的情况下，它是否受到完整性保护。
Message authentication, key agreement, integrity and replay protection, and confidentiality must be provided for communications between SIP network entities such as proxy servers.
必须为SIP网络实体（如代理服务器）之间的通信提供消息认证、密钥协议、完整性和重播保护以及机密性。
Network domain security mechanisms must be scalable up to a large number of network elements.
网络域安全机制必须可扩展到大量网络元素。
3GPP intends to make having the protection discussed above mandatory at least between two operators, and optional within an operator's own network. Security gateways exist between operator's networks.
3GPP打算使上述保护至少在两个运营商之间是强制性的，并且在运营商自己的网络中是可选的。运营商网络之间存在安全网关。
We believe that the above requirements are fulfilled by applying security mechanisms as specified in the current IP Security standards in RFC 2401 [5].
我们认为，通过应用RFC 2401[5]中当前IP安全标准中规定的安全机制，可以满足上述要求。
This document does not define a protocol, but still presents some security requirements to protocols. The main security requirements are stated in sections 4.23, 4.24, and 4.25. Additional security-related issues are discussed under sections 4.6, 4.7, 4.8, 4.9, 4.10, and 4.12.
本文档未定义协议，但仍对协议提出了一些安全要求。第4.23、4.24和4.25节规定了主要安全要求。第4.6、4.7、4.8、4.9、4.10和4.12节讨论了其他安全相关问题。
The following people contributed to this document:
以下人员对此文件作出了贡献：
Duncan Mills (Vodafone), Gabor Bajko (Nokia), Georg Mayer (Siemens), Francois-Xerome Derome (Alcatel), Hugh Shieh (AWS), Andrew Allen (dynamicsoft), Sunil Chotai (mmO2), Keith Drage (Lucent), Jayshree Bharatia (Nortel), Kevan Hobbis (Huthison 3G UK), Dean Willis (dynamicsoft), Krisztian Kiss (Nokia), Vesa Torvinen (Ericsson), Jari Arkko (Ericsson), and Sonia Garapaty (Nortel).
Duncan Mills（沃达丰）、Gabor Bajko（诺基亚）、Georg Mayer（西门子）、Francois Xerome Derome（阿尔卡特）、Hugh Shieh（AWS）、Andrew Allen（dynamicsoft）、Sunil Chotai（mmO2）、Keith Drage（朗讯）、Jayshree Bharatia（北电）、Kevan Hobis（Huthison 3G UK）、Dean Willis（dynamicsoft）、Kristian Kiss（诺基亚）、Vesa Torvine（爱立信）、Jari Arkko（爱立信），和索尼娅·加拉帕蒂（北电）。
[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] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[3] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[4] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[5] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[5] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[6] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[6] Aboba，B.和M.Beadles，“网络接入标识符”，RFC 2486，1999年1月。
[7] Shirey, R., "Internet Security Glossary", RFC 2828, May 2000.
[7] Shirey，R.，“互联网安全词汇表”，RFC 2828，2000年5月。
[8] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[8] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[9] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[9] Faltstrom，P.，“E.164号码和域名系统”，RFC 29162000年9月。
[10] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[10] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[11] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[11] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[12] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[12] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[13] Niemi, A., Arkko, J., and V. Torvinen, "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)", RFC 3310, September 2002.
[13] Niemi，A.，Arkko，J.，和V.Torvinen，“使用身份验证和密钥协议（AKA）的超文本传输协议（HTTP）摘要身份验证”，RFC33102002年9月。
[14] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[14] Rosenberg，J.，“用于注册的会话启动协议（SIP）事件包”，RFC 36802004年3月。
[15] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[15] Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[16] Marshall, W., "Private Session Initiation Protocol (SIP) Extensions for Media Authorization", RFC 3313, January 2003.
[16] Marshall，W.，“媒体授权的专用会话发起协议（SIP）扩展”，RFC 3313，2003年1月。
[17] 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.
[17] Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中用于断言身份的会话启动协议（SIP）的私有扩展”，RFC 33252002年11月。
[18] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[18] Peterson，J.，“会话启动协议（SIP）的隐私机制”，RFC3323，2002年11月。
[19] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[19] Schulzrinne，H.和B.Volz，“会话启动协议（SIP）服务器的动态主机配置协议（DHCPv6）选项”，RFC 3319，2003年7月。
[20] Sparks, R., "Session Initiation Protocol Call Control - Transfer", Work in Progress, February 2005.
[20] Sparks，R.，“会话启动协议呼叫控制-传输”，正在进行的工作，2005年2月。
[21] 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.
[21] Johnston，A.，Donovan，S.，Sparks，R.，Cunningham，C.，和K.Summers，“会话发起协议（SIP）基本呼叫流示例”，BCP 75，RFC 3665，2003年12月。
[22] 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.
[22] Johnston，A.，Donovan，S.，Sparks，R.，Cunningham，C.，和K.Summers，“会话发起协议（SIP）公共交换电话网络（PSTN）呼叫流”，BCP 76，RFC 3666，2003年12月。
[23] Johnston, A. and R. Sparks, "Session Initiation Protocol Service Examples", Work in Progress, February 2005.
[23] Johnston，A.和R.Sparks，“会话启动协议服务示例”，正在进行的工作，2005年2月。
[24] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[24] Sparks，R.，“会话启动协议（SIP）引用方法”，RFC 3515，2003年4月。
[25] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) 'Replaces' Header", RFC 3891, September 2004.
[25] Mahy，R.，Biggs，B.，和R.Dean，“会话启动协议（SIP）”取代了“头”，RFC 38912004年9月。
[26] 3GPP, "TS 23.003 Numbering, addressing and identification (Release 5)", September 2002, <ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
[26] 3GPP，“TS 23.003编号、寻址和标识（第5版）”，2002年9月<ftp://ftp.3gpp.org/Specs/archive/23_series/23.003/>.
[27] 3GPP, "TS 23.060:General Packet Radio Service (GRPS); Service Description; Stage 2", September 2002, <ftp://ftp.3gpp.org/Specs/archive/23_series/23.060/>.
[27] 3GPP，“TS 23.060：通用分组无线业务（GRPS）；业务描述；第2阶段”，2002年9月<ftp://ftp.3gpp.org/Specs/archive/23_series/23.060/>.
[28] 3GPP, "TS 23.228: IP Multimedia Subsystem (IMS) (Stage 2) - Release 5", September 2002, <ftp://ftp.3gpp.org/Specs/archive/23_series/23.228/>.
[28] 3GPP，“TS 23.228:IP多媒体子系统（IMS）（第2阶段）-第5版”，2002年9月<ftp://ftp.3gpp.org/Specs/archive/23_series/23.228/>.
[29] 3GPP, "TS 24.228: Signaling flows for the IP Multimedia call control based on SIP and SDP", September 2002, <ftp://ftp.3gpp.org/Specs/archive/24_series/24.228/>.
[29] 3GPP，“TS 24.228：基于SIP和SDP的IP多媒体呼叫控制信令流”，2002年9月<ftp://ftp.3gpp.org/Specs/archive/24_series/24.228/>.
[30] 3GPP, "TS 24.229: IP Multimedia Subsystem (IMS) (Stage 3) - Release 5", September 2002, <ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[30] 3GPP，“TS 24.229:IP多媒体子系统（IMS）（第3阶段）-第5版”，2002年9月<ftp://ftp.3gpp.org/Specs/archive/24_series/24.229/>.
[31] 3GPP, "TS 32.225: Telecommunication Management; Charging Management; Charging Data Description for IP Multimedia Subsystem; (Release 5)", September 2002, <ftp://ftp.3gpp.org/Specs/archive/32_series/32.225/>.
[31] 3GPP，“TS 32.225：电信管理；计费管理；IP多媒体子系统的计费数据描述；（第5版）”，2002年9月<ftp://ftp.3gpp.org/Specs/archive/32_series/32.225/>.
[32] 3GPP, "TS 32.203: 3G Security; Access security for IP based services; (Release 5)", September 2002, <ftp://ftp.3gpp.org/Specs/archive/33_series/33.203/>.
[32] 3GPP，“TS 32.203:3G安全；基于IP的服务的访问安全；（第5版）”，2002年9月<ftp://ftp.3gpp.org/Specs/archive/33_series/33.203/>.
[33] 3GPP, "TS 32.210: 3G Security; Network Domain Security; IP network layer security (Release 5)", September 2002, <ftp://ftp.3gpp.org/Specs/archive/33_series/33.210/>.
[33] 3GPP，“TS 32.210:3G安全；网络域安全；IP网络层安全（第5版）”，2002年9月<ftp://ftp.3gpp.org/Specs/archive/33_series/33.210/>.
[34] ITU-T, "Recommendation E.164 (05/97): The international public telecommunication numbering plan", May 1997, <http://www.itu.int/rec/recommendation.asp? type=folders&lang=e&parent=T-REC-E.164>.
[34] ITU-T，“建议E.164（05/97）：国际公共电信编号计划”，1997年5月<http://www.itu.int/rec/recommendation.asp? type=folders&lang=e&parent=T-REC-e.164>。
[35] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[35] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
Author's Address
作者地址
Miguel A. Garcia-Martin Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
芬兰芬兰芬兰诺基亚集团407号信箱，米格尔A.加西亚·马丁
EMail: miguel.an.garcia@nokia.com
EMail: miguel.an.garcia@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。