Network Working Group C. Bormann
Request for Comments: 5049 Universitaet Bremen TZI
Category: Standards Track Z. Liu
Nokia Research Center
R. Price
EADS Defence and Security Systems Limited
G. Camarillo, Ed.
Ericsson
December 2007
Network Working Group C. Bormann
Request for Comments: 5049 Universitaet Bremen TZI
Category: Standards Track Z. Liu
Nokia Research Center
R. Price
EADS Defence and Security Systems Limited
G. Camarillo, Ed.
Ericsson
December 2007
Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)
将信令压缩（SigComp）应用于会话启动协议（SIP）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
This document describes some specifics that apply when Signaling Compression (SigComp) is applied to the Session Initiation Protocol (SIP), such as default minimum values of SigComp parameters, compartment and state management, and a few issues on SigComp over TCP. Any implementation of SigComp for use with SIP must conform to this document and SigComp, and in addition, support the SIP and Session Description Protocol (SDP) static dictionary.
本文档描述了将信令压缩（SigComp）应用于会话启动协议（SIP）时应用的一些细节，例如SigComp参数的默认最小值、隔室和状态管理，以及TCP上SigComp的一些问题。与SIP一起使用的任何SigComp实现必须符合本文档和SigComp，此外，还支持SIP和会话描述协议（SDP）静态字典。
Table of Contents
目录
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Compliance with This Specification ..............................3
4. Minimum Values of SigComp Parameters for SIP/SigComp ............3
4.1. decompression_memory_size (DMS) for SIP/SigComp ............4
4.2. state_memory_size (SMS) for SIP/SigComp ....................4
4.3. cycles_per_bit (CPB) for SIP/SigComp .......................5
4.4. SigComp_version (SV) for SIP/SigComp .......................5
4.5. locally available state (LAS) for SIP/SigComp ..............5
5. Delimiting SIP Messages and SigComp Messages on the Same Port ...5
6. Continuous Mode over TCP ........................................6
7. Too-Large SIP Messages ..........................................7
8. SIP Retransmissions .............................................7
9. Compartment and State Management for SIP/SigComp ................7
9.1. Remote Application Identification ..........................8
9.2. Identifier Comparison Rules ...............................10
9.3. Compartment Opening and Closure ...........................11
9.4. Lack of a Compartment .....................................13
10. Recommendations for Network Administrators ....................13
11. Private Agreements ............................................14
12. Backwards Compatibility .......................................14
13. Interactions with Transport Layer Security (TLS) ..............14
14. Example .......................................................15
15. Security Considerations .......................................17
16. IANA Considerations ...........................................17
17. Acknowledgements ..............................................17
18. References ....................................................18
18.1. Normative References .....................................18
18.2. Informative References ...................................19
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Compliance with This Specification ..............................3
4. Minimum Values of SigComp Parameters for SIP/SigComp ............3
4.1. decompression_memory_size (DMS) for SIP/SigComp ............4
4.2. state_memory_size (SMS) for SIP/SigComp ....................4
4.3. cycles_per_bit (CPB) for SIP/SigComp .......................5
4.4. SigComp_version (SV) for SIP/SigComp .......................5
4.5. locally available state (LAS) for SIP/SigComp ..............5
5. Delimiting SIP Messages and SigComp Messages on the Same Port ...5
6. Continuous Mode over TCP ........................................6
7. Too-Large SIP Messages ..........................................7
8. SIP Retransmissions .............................................7
9. Compartment and State Management for SIP/SigComp ................7
9.1. Remote Application Identification ..........................8
9.2. Identifier Comparison Rules ...............................10
9.3. Compartment Opening and Closure ...........................11
9.4. Lack of a Compartment .....................................13
10. Recommendations for Network Administrators ....................13
11. Private Agreements ............................................14
12. Backwards Compatibility .......................................14
13. Interactions with Transport Layer Security (TLS) ..............14
14. Example .......................................................15
15. Security Considerations .......................................17
16. IANA Considerations ...........................................17
17. Acknowledgements ..............................................17
18. References ....................................................18
18.1. Normative References .....................................18
18.2. Informative References ...................................19
SigComp [RFC3320] is a solution for compressing messages generated by application protocols. Although its primary driver is to compress SIP [RFC3261] messages, the solution itself has been intentionally designed to be application agnostic so that it can be applied to any application protocol; this is denoted as ANY/SigComp. Consequently, many application-dependent specifics are left out of the base standard. It is intended that a separate specification be used to describe those specifics when SigComp is applied to a particular application protocol.
SigComp[RFC3320]是一种压缩应用程序协议生成的消息的解决方案。尽管其主要驱动程序是压缩SIP[RFC3261]消息，但该解决方案本身被有意设计为不依赖于应用程序，因此它可以应用于任何应用程序协议；这表示为任何/SigComp。因此，许多依赖于应用程序的细节被排除在基本标准之外。当SigComp应用于特定应用协议时，打算使用单独的规范来描述这些规范。
This document binds SigComp and SIP; this is denoted as SIP/SigComp.
本文件对SigComp和SIP具有约束力；这表示为SIP/SigComp。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
Any SigComp implementation that is used for the compression of SIP messages MUST conform to this document, as well as to [RFC3320]. Additionally, it must support the SIP/SDP static dictionary, as specified in [RFC3485], and the mechanism for discovering SigComp support at the SIP layer, as specified in [RFC3486].
用于压缩SIP消息的任何SigComp实现必须符合本文件以及[RFC3320]。此外，它必须支持[RFC3485]中规定的SIP/SDP静态字典，以及[RFC3486]中规定的在SIP层发现SigComp支持的机制。
In order to support a wide range of capabilities among endpoints implementing SigComp, SigComp defines a few parameters to describe SigComp behavior (see Section 3.3 of [RFC3320]). For each parameter, [RFC3320] specifies a minimum value that any SigComp endpoint MUST support for ANY/SigComp. Those minimum values were determined with the consideration of all imaginable devices in which SigComp may be implemented. Scalability was also considered as a key factor.
为了支持实现SigComp的端点之间的广泛功能，SigComp定义了几个参数来描述SigComp行为（参见[RFC3320]第3.3节）。对于每个参数，[RFC3320]指定任何SigComp端点必须为任何/SigComp支持的最小值。这些最小值是在考虑所有可实现SigComp的可想象装置的情况下确定的。可伸缩性也被认为是一个关键因素。
However, some of the minimum values specified in [RFC3320] are too small to allow good performance for SIP message compression. Therefore, they are increased for SIP/SigComp as specified in the following sections. For completeness, those parameters that are the same for SIP/SigComp as they are for ANY/SigComp are also listed.
但是，[RFC3320]中指定的一些最小值太小，无法实现SIP消息压缩的良好性能。因此，根据以下章节的规定，SIP/SigComp的成本增加。为完整起见，还列出了SIP/SigComp与任何/SigComp相同的参数。
The new minimum values are specific to SIP/SigComp and, thus, do not apply to any other application protocols. A SIP/SigComp endpoint MAY offer additional resources over and above the minimum values
新的最小值特定于SIP/SigComp，因此不适用于任何其他应用协议。SIP/SigComp端点可以提供超过最小值的额外资源
specified in this document if available; these resources can be advertised to remote endpoints as described in Section 9.4.9 of [RFC3320].
本文件中规定的（如有）；如[RFC3320]第9.4.9节所述，这些资源可以发布到远程端点。
Minimum value for ANY/SigComp: 2048 bytes, as specified in Section 3.3.1 of [RFC3320].
任何/SigComp的最小值：2048字节，如[RFC3320]第3.3.1节所述。
Minimum value for SIP/SigComp: 8192 bytes.
SIP/SigComp的最小值：8192字节。
Reason: a DMS of 2048 bytes is too small for SIP message compression as it seriously limits the compression ratio and even makes compression impossible for certain messages. For example, the condition set by [RFC3320] for SigComp over UDP means: C + 2*B + R + 2*S + 128 < DMS (each term is described below). Therefore, if DMS is too small, at least one of C, B, R, or S will be severely restricted. On the other hand, DMS is memory that is only temporarily needed during decompression of a SigComp message (the memory can be reclaimed when the message has been decompressed). Therefore, a requirement of 8 KB should not cause any problems for an endpoint that already implements SIP, SigComp, and applications that use SIP.
原因：2048字节的DMS对于SIP消息压缩来说太小，因为它严重限制了压缩比，甚至使某些消息无法压缩。例如，[RFC3320]为通过UDP的SigComp设置的条件意味着：C+2*B+R+2*S+128<DMS（每个术语如下所述）。因此，如果DMS太小，至少C、B、R或S中的一个将受到严格限制。另一方面，DMS是仅在SigComp消息解压缩期间临时需要的内存（当消息解压缩时，可以回收内存）。因此，对于已经实现SIP、SigComp和使用SIP的应用程序的端点而言，8KB的需求不应导致任何问题。
C size of compressed application message, depending on R B size of bytecode. Note: two copies -- one as part of the SigComp message and one in UDVM (Universal Decompressor Virtual Machine) memory. R size of circular buffer in UDVM memory S any additional state uploaded other than that created from the content of the circular buffer at the end of decompression (similar to B, two copies of S are needed) 128 the smallest address in UDVM memory to copy bytecode to
C压缩应用程序消息的大小，取决于字节码的R B大小。注意：两份拷贝——一份作为SigComp消息的一部分，另一份在UDVM（通用解压器虚拟机）内存中。R UDVM内存中循环缓冲区的大小S除了在解压结束时从循环缓冲区的内容创建的状态外，上载的任何其他状态（类似于B，需要两个S副本）128 UDVM内存中要将字节码复制到的最小地址
Minimum value for ANY/SigComp: 0 (zero) bytes, as specified in Section 3.3.1 of [RFC3320].
任何/SigComp的最小值：0（零）字节，如[RFC3320]第3.3.1节所规定。
Minimum value for SIP/SigComp: 2048 bytes.
SIP/SigComp的最小值：2048字节。
Reason: a non-zero SMS allows an endpoint to upload a state in the first SIP message sent to a remote endpoint without the uncertainty of whether the remote endpoint will have enough memory to store such a state. A non-zero SMS obviously requires the SIP/SigComp implementation to keep state. Based on the observation that there is little gain from stateless SigComp compression, the assumption is that purely stateless SIP implementations are unlikely to provide a
原因：非零SMS允许端点上传发送到远程端点的第一条SIP消息中的状态，而不确定远程端点是否有足够的内存来存储这种状态。非零SMS显然需要SIP/SigComp实现保持状态。基于无状态SigComp压缩几乎没有收益的观察，我们假设纯无状态SIP实现不可能提供
SigComp function. Stateful implementations should have little problem to keep 2K additional state for each compartment (see Section 9).
SigComp函数。有状态实现应该不会有什么问题，可以为每个隔间保留2K个额外的状态（参见第9节）。
Note: SMS is a parameter that applies to each individual compartment. An endpoint MAY offer different SMS values for different compartments as long as the SMS value is not less than 2048 bytes.
注意：SMS是一个适用于每个单独隔间的参数。只要SMS值不小于2048字节，端点可以为不同的隔室提供不同的SMS值。
Minimum value for ANY/SigComp: 16, as specified in Section 3.3.1 of [RFC3320].
根据[RFC3320]第3.3.1节的规定，任何/SigComp的最小值为16。
Minimum value for SIP/SigComp: 16 (same as above).
SIP/SigComp的最小值：16（同上）。
For ANY/SigComp: 0x01, as specified in Section 3.3.2 of [RFC3320].
对于任何/SigComp:0x01，如[RFC3320]第3.3.2节所述。
For SIP/SigComp: >= 0x02 (at least SigComp + NACK).
对于SIP/SigComp:>=0x02（至少SigComp+NACK）。
Note that this implies that the provisions of [RFC4077] apply. That is, decompression failures result in SigComp NACK messages sent back to the originating compressor. It also implies that the compressor need not make use of the methods detailed in Section 2.4 of [RFC4077] (Detecting Support for NACK); for example, it can use optimistic compression methods right from the outset.
注意，这意味着[RFC4077]的规定适用。也就是说，解压缩失败会导致SigComp NACK消息发送回原始压缩机。这也意味着压缩机无需使用[RFC4077]（检测NACK支持）第2.4节中详述的方法；例如，它可以从一开始就使用乐观压缩方法。
Minimum LAS for ANY/SigComp: none, see Section 3.3.3 of [RFC3320].
任何/SigComp的最小LAS：无，见[RFC3320]第3.3.3节。
Minimum LAS for SIP/SigComp: the SIP/SDP static dictionary as defined in [RFC3485].
SIP/SigComp的最小LAS：在[RFC3485]中定义的SIP/SDP静态字典。
Note that, since support for the static SIP/SDP dictionary is mandatory, it does not need to be advertised.
注意，由于对静态SIP/SDP字典的支持是强制性的，因此不需要公布它。
In order to limit the number of ports required by a SigComp-aware endpoint, it is possible to allow both SigComp messages and 'vanilla' SIP messages (i.e., uncompressed SIP messages with no SigComp header) to arrive on the same port.
为了限制SigComp感知端点所需的端口数，可以允许SigComp消息和“普通”SIP消息（即没有SigComp头的未压缩SIP消息）到达同一端口。
For a message-based transport such as UDP or Stream Control Transmission Protocol (SCTP), distinguishing between SigComp and non-SigComp messages can be done per message. The receiving endpoint
对于基于消息的传输，如UDP或流控制传输协议（SCTP），可以根据每条消息区分SigComp和非SigComp消息。接收端点
checks the first octet of the UDP/SCTP payload to determine whether the message has been compressed using SigComp. If the MSBs (Most Significant Bits) of the octet are "11111", then the message is considered to be a SigComp message and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the message is assumed to be an uncompressed SIP message, and it is passed directly to the application with no further effect on the SigComp layer.
检查UDP/SCTP有效负载的第一个八位字节，以确定消息是否已使用SigComp压缩。如果八位字节的MSB（最高有效位）为“11111”，则该消息被视为SigComp消息，并按照[RFC3320]进行解析。如果八位字节的MSB采用任何其他值，则假定该消息是未压缩的SIP消息，并将其直接传递给应用程序，对SigComp层没有进一步影响。
For a stream-based transport such as TCP, distinguishing between SigComp and non-SigComp messages has to be done per connection. The receiving endpoint checks the first octet of the TCP data stream to determine whether the stream has been compressed using SigComp. If the MSBs of the octet are "11111", then the stream is considered to contain SigComp messages and is parsed as per [RFC3320]. If the MSBs of the octet take any other value, then the stream is assumed to contain uncompressed SIP messages, and it is passed directly to the application with no further effect on the SigComp layer. Note that SigComp message delimiters MUST NOT be used if the stream contains uncompressed SIP messages.
对于基于流的传输（如TCP），必须在每个连接上区分SigComp和非SigComp消息。接收端点检查TCP数据流的第一个八位字节，以确定该流是否已使用SigComp进行压缩。如果八位字节的MSB为“11111”，则认为该流包含SigComp消息，并按照[RFC3320]进行分析。如果八位字节的MSB采用任何其他值，则假定流包含未压缩的SIP消息，并将其直接传递给应用程序，对SigComp层没有进一步的影响。请注意，如果流包含未压缩的SIP消息，则不得使用SigComp消息分隔符。
Applications MUST NOT mix SIP messages and SigComp messages on a single TCP connection. If the TCP connection is used to carry SigComp messages, then all messages sent over the connection MUST have a SigComp header and be delimited by the use of 0xFFFF, as described in [RFC3320].
应用程序不得在单个TCP连接上混合使用SIP消息和SigComp消息。如果TCP连接用于传输SigComp消息，则通过该连接发送的所有消息必须具有SigComp头，并使用0xFFFF进行分隔，如[RFC3320]中所述。
Section 11 of [RFC4896] details a simple set of bytecodes, intended to be "well-known", that implement a null decompression algorithm. These bytecodes effectively allow SigComp peers to send selected SigComp messages with uncompressed data. If a SIP implementation has reason to send both compressed and uncompressed SIP messages on a single TCP connection, the compressor can be instructed to use these bytecodes to send uncompressed SIP messages that are also valid SigComp messages.
[RFC4896]的第11节详细介绍了一组简单的字节码，这些字节码旨在“众所周知”，用于实现空解压算法。这些字节码有效地允许SigComp对等方发送带有未压缩数据的选定SigComp消息。如果SIP实现有理由在单个TCP连接上发送压缩和未压缩的SIP消息，则可以指示压缩器使用这些字节码发送也是有效的SigComp消息的未压缩SIP消息。
Continuous Mode is a special feature of SigComp, which is designed to improve the overall compression ratio for long-lived connections. Its use requires pre-agreement between the SigComp compressor and decompressor. Continuous mode is not used with SIP/SigComp.
连续模式是SigComp的一项特殊功能，旨在提高长寿命连接的整体压缩比。其使用要求SigComp压缩机和减压器之间事先达成一致。SIP/SigComp不使用连续模式。
Reason: continuous mode requires the transport itself to provide a certain level of protection against denial-of-service attacks. TCP alone is not considered to provide enough protection.
原因：连续模式要求传输本身针对拒绝服务攻击提供一定级别的保护。仅TCP不能提供足够的保护。
SigComp does not support the compression of messages larger than 64k. Therefore, if a SIP application sending compressed SIP messages to another SIP application over a transport connection (e.g., a TCP connection) needs to send a SIP message larger than 64k, the SIP application MUST NOT send the message over the same TCP connection. The SIP application SHOULD send the message over a different transport connection (to do this, the SIP application may need to establish a new transport connection).
SigComp不支持压缩大于64k的消息。因此，如果通过传输连接（例如，TCP连接）向另一个SIP应用发送压缩SIP消息的SIP应用程序需要发送大于64k的SIP消息，则SIP应用程序不得通过相同的TCP连接发送该消息。SIP应用程序应通过不同的传输连接发送消息（为此，SIP应用程序可能需要建立新的传输连接）。
When SIP messages are retransmitted, they need to be re-compressed, taking into account any SigComp states that may have been created or invalidated since the previous transmission. Implementations MUST NOT cache the result of compressing the message and retransmit such a cached result.
重新传输SIP消息时，需要重新压缩这些消息，同时考虑自上次传输以来可能已创建或无效的任何SigComp状态。实现不能缓存压缩消息的结果并重新传输这样的缓存结果。
The reason for this behavior is that it is impossible to know whether the failure causing the retransmission occurred on the message being retransmitted or on the response to that message. If the response was lost, any state changes effected by the first instance of the retransmitted message would already have taken place. If these state changes removed a state that the previously transmitted message relied upon, then retransmission of the same compressed message would lead to a decompression failure.
此行为的原因是无法知道导致重新传输的故障是发生在正在重新传输的消息上还是发生在对该消息的响应上。如果响应丢失，则受重传消息的第一个实例影响的任何状态更改都将已经发生。如果这些状态更改删除了先前传输的消息所依赖的状态，则重新传输相同的压缩消息将导致解压缩失败。
Note that a SIP retransmission may be caused by the original message or its response being lost by a decompression failure. In this case, a NACK will have been sent by the decompressor to the compressor, which may use the information in this NACK message to adjust its compression parameters. Note that, on an unreliable transport, such a NACK message may still be lost, so if a compressor used some form of optimistic compression, it MAY want to switch to a method less likely to cause any form of decompression failure when compressing a SIP retransmission.
注意，SIP重传可能由原始消息或其响应因解压缩失败而丢失引起。在这种情况下，解压缩器将向压缩机发送NACK，压缩机可以使用此NACK消息中的信息来调整其压缩参数。注意，在不可靠传输上，这样的NACK消息仍然可能丢失，因此如果压缩器使用某种形式的乐观压缩，则它可能希望切换到在压缩SIP重传时不太可能导致任何形式的解压缩失败的方法。
An application exchanging compressed traffic with a remote application has a compartment that contains state information needed to compress outgoing messages and to decompress incoming messages. To increase the compression efficiency, the application must assign distinct compartments to distinct remote applications.
与远程应用程序交换压缩流量的应用程序有一个隔间，其中包含压缩传出消息和解压缩传入消息所需的状态信息。为了提高压缩效率，应用程序必须为不同的远程应用程序分配不同的分区。
SIP/SigComp applications identify remote applications by their SIP/ SigComp identifiers. Each SIP/SigComp application MUST have a SIP/ SigComp identifier URN (Uniform Resource Name) that uniquely identifies the application. Usage of a URN provides a persistent and unique name for the SIP/SigComp identifier. It also provides an easy way to guarantee uniqueness. This URN MUST be persistent as long as the application stores compartment state related to other SIP/SigComp applications.
SIP/SigComp应用程序通过其SIP/SigComp标识符识别远程应用程序。每个SIP/SigComp应用程序必须具有唯一标识该应用程序的SIP/SigComp标识符URN（统一资源名称）。URN的使用为SIP/SigComp标识符提供了一个持久且唯一的名称。它还提供了一种保证唯一性的简单方法。只要应用程序存储与其他SIP/SigComp应用程序相关的隔间状态，此URN就必须是持久的。
A SIP/SigComp application SHOULD use a UUID (Universally Unique IDentifier) URN as its SIP/SigComp identifier, due to the difficulties in equality comparisons for other kinds of URNs. The UUID URN [RFC4122] allows for non-centralized computation of a URN based on time, unique names (such as a Media Access Control (MAC) address), or a random number generator. If a URN scheme other than UUID is used, the URN MUST be selected such that the application can be certain that no other SIP/SigComp application would choose the same URN value.
SIP/SigComp应用程序应使用UUID（通用唯一标识符）URN作为其SIP/SigComp标识符，因为其他类型的URN在相等性比较方面存在困难。UUID URN[RFC4122]允许基于时间、唯一名称（例如媒体访问控制（MAC）地址）或随机数生成器对URN进行非集中计算。如果使用UUID以外的URN方案，则必须选择URN，以便应用程序可以确定没有其他SIP/SigComp应用程序会选择相同的URN值。
Note that the definition of SIP/SigComp identifier is similar to the definition of instance identifier in [OUTBOUND]. One difference is that instance identifiers are only required to be unique within their AoR (Address of Record) while SIP/SigComp identifiers are required to be globally unique.
请注意，SIP/SigComp标识符的定义与[OUTBOUND]中实例标识符的定义类似。一个区别是，实例标识符只要求在其AoR（记录地址）内唯一，而SIP/SigComp标识符要求全局唯一。
Even if instance identifiers are only required to be unique within their AoR, devices may choose to generate globally unique instance identifiers. A device with a globally unique instance identifier SHOULD use its instance identifier as its SIP/SigComp identifier.
即使只要求实例标识符在其AoR内是唯一的，设备也可以选择生成全局唯一的实例标识符。具有全局唯一实例标识符的设备应使用其实例标识符作为其SIP/SigComp标识符。
Note: Using the same value for an entity's instance and SIP/SigComp identifiers improves the compression ratio of header fields that carry both identifiers (e.g., a Contact header field in a REGISTER request).
注意：对实体实例和SIP/SigComp标识符使用相同的值可以提高携带这两个标识符的头字段（例如，注册请求中的联系人头字段）的压缩比。
Server farms that share SIP/SigComp state across servers MUST use the same SIP/SigComp identifier for all their servers.
跨服务器共享SIP/SigComp状态的服务器场必须为其所有服务器使用相同的SIP/SigComp标识符。
SIP/SigComp identifiers are carried in the 'sigcomp-id' SIP URI (Uniform Resource Identifier) or Via header field parameter. The 'sigcomp-id' SIP URI parameter is a 'uri-parameter', as defined by the SIP ABNF (Augmented Backus-Naur Form, Section 25.1 of [RFC3261]). The following is its ABNF [RFC4234]:
SIP/SigComp标识符包含在“SigComp id”SIP URI（统一资源标识符）中或通过标头字段参数。“sigcomp id”SIP URI参数是一个“URI参数”，由SIP ABNF（扩充的Backus Naur表格，[RFC3261]第25.1节）定义。以下是其ABNF[RFC4234]：
uri-sip-sigcomp-id = "sigcomp-id=" 1*paramchar
uri-sip-sigcomp-id = "sigcomp-id=" 1*paramchar
The SIP URI 'sigcomp-id' parameter MUST contain a URN [RFC2141].
SIP URI“sigcomp id”参数必须包含URN[RFC2141]。
The Via 'sigcomp-id' parameter is a 'via-extension', as defined by the SIP ABNF (Section 25.1 of [RFC3261]). The following is its ABNF [RFC4234]:
按照SIP ABNF（RFC3261第25.1节）的定义，Via“sigcomp id”参数是一个“Via扩展”。以下是其ABNF[RFC4234]：
via-sip-sigcomp-id = "sigcomp-id" EQUAL LDQUOT *( qdtext / quoted-pair ) RDQUOT
通过sip sigcomp id=“sigcomp id”相等的LDQUOT*（qdtext/引号对）RDQUOT
The Via 'sigcomp-id' parameter MUST contain a URN [RFC2141].
Via“sigcomp id”参数必须包含URN[RFC2141]。
The following is an example of a 'sigcomp-id' SIP URI parameter:
以下是“sigcomp id”SIP URI参数的示例：
sigcomp-id=urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128
sigcomp-id=urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128
The following is an example of a Via header field with a 'sigcomp-id' parameter:
以下是带有“sigcomp id”参数的Via标头字段示例：
Via: SIP/2.0/UDP server1.example.com:5060
;branch=z9hG4bK87a7
;comp=sigcomp
;sigcomp-id="urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128"
Via: SIP/2.0/UDP server1.example.com:5060
;branch=z9hG4bK87a7
;comp=sigcomp
;sigcomp-id="urn:uuid:0C67446E-F1A1-11D9-94D3-000A95A0E128"
The following is an example of a REGISTER request that carries 'sigcomp-id' parameters in a Via entry and in the Contact header field. Additionally, it also carries a '+sip.instance' Contact header field parameter.
以下是一个寄存器请求示例，该请求在过孔条目和联系人标头字段中携带“sigcomp id”参数。此外，它还携带“+sip.instance”联系人标头字段参数。
REGISTER sip:example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav;
rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473"
From: "Joe User" <sip:2145550500@example.net>;tag=6to4gh7t5j
To: "Joe User" <sip:2145550500@example.net>
Call-ID: 3c26700c1adb-lu1lz5ri5orr
CSeq: 215196 REGISTER
Max-Forwards: 70
Contact: <sip:2145550500@192.0.2.247:2078;
sigcomp-id=urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>;
q=1.0; expires=3600;
+sip.instance="<urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>"
Content-Length: 0
REGISTER sip:example.net SIP/2.0
Via: SIP/2.0/UDP 192.0.2.247:2078;branch=z9hG4bK-et736vsjirav;
rport;sigcomp-id="urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473"
From: "Joe User" <sip:2145550500@example.net>;tag=6to4gh7t5j
To: "Joe User" <sip:2145550500@example.net>
Call-ID: 3c26700c1adb-lu1lz5ri5orr
CSeq: 215196 REGISTER
Max-Forwards: 70
Contact: <sip:2145550500@192.0.2.247:2078;
sigcomp-id=urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>;
q=1.0; expires=3600;
+sip.instance="<urn:uuid:2e5fdc76-00be-4314-8202-1116fa82a473>"
Content-Length: 0
SIP messages are matched with remote application identifiers as follows:
SIP消息与远程应用程序标识符匹配，如下所示：
Outgoing requests: the remote application identifier is the SIP/ SigComp identifier of the URI to which the request is sent. If the URI does not contain a SIP/SigComp identifier, the remote
传出请求：远程应用程序标识符是请求发送到的URI的SIP/SigComp标识符。如果URI不包含SIP/SigComp标识符，则远程
application identifier is the IP address plus port of the datagram carrying the request for connectionless transport protocols, and the transport connection (e.g., a TCP connection) carrying the request for connection-oriented transport protocols (this is to support legacy SIP/SigComp applications).
应用程序标识符是承载无连接传输协议请求的数据报的IP地址加端口，以及承载面向连接传输协议请求的传输连接（例如TCP连接）（这是为了支持传统SIP/SigComp应用程序）。
Incoming responses: the remote application identifier is the same as that of the previously sent request that initiated the transaction to which the response belongs.
传入响应：远程应用程序标识符与先前发送的启动响应所属事务的请求的标识符相同。
Incoming requests: the remote application identifier is the SIP/ SigComp identifier of the top-most Via entry. If the Via header field does not contain a SIP/SigComp identifier, the remote application identifier is the source IP address plus port of the datagram carrying the request for connectionless transport protocols, and the transport connection (e.g., a TCP connection) carrying the request for connection-oriented transport protocols (this is to support legacy SIP/SigComp applications).
传入请求：远程应用程序标识符是最顶层Via条目的SIP/SigComp标识符。如果Via标头字段不包含SIP/SigComp标识符，则远程应用程序标识符是源IP地址加上承载无连接传输协议请求的数据报端口，以及承载面向连接的传输协议请求的传输连接（例如TCP连接）（这是为了支持传统SIP/SigComp应用程序）。
Outgoing responses: the remote application identifier is the same as that of the previously received request that initiated the transaction to which the response belongs. Note that, due to standard SIP Via header field processing, this identifier will be present in the top-most Via entry in such responses (as long as it was present in the top-most Via entry of the previously received request).
传出响应：远程应用程序标识符与先前收到的启动响应所属事务的请求的标识符相同。注意，由于标准的SIP Via报头字段处理，该标识符将出现在此类响应中最顶端的Via条目中（只要它出现在先前接收到的请求的最顶端的Via条目中）。
A SIP/SigComp application placing its URI with the 'comp=sigcomp' parameter in a header field MUST add a 'sigcomp-id' parameter with its SIP/SigComp identifier to that URI.
SIP/SigComp应用程序在头字段中放置其URI和'comp=SigComp'参数时，必须向该URI添加带有SIP/SigComp标识符的'SigComp id'参数。
A SIP/SigComp application generating its own Via entry containing the 'comp=sigcomp' parameter MUST add a 'sigcomp-id' parameter with its SIP/SigComp identifier to that Via entry.
生成自己的包含“comp=SigComp”参数的Via条目的SIP/SigComp应用程序必须将带有SIP/SigComp标识符的“SigComp id”参数添加到该Via条目中。
A given remote application identifier is mapped to a particular SigComp compartment ID following the rules given in Section 9.3.
按照第9.3节中给出的规则，将给定的远程应用程序标识符映射到特定的SigComp隔间ID。
Equality comparisons between SIP/SigComp identifiers are performed using the rules for URN equality that are specific to the scheme in the URN. If the element performing the comparisons does not understand the URN scheme, it performs the comparisons using the lexical equality rules defined in RFC 2141 [RFC2141]. Lexical equality may result in two URNs being considered unequal when they are actually equal. In this specific usage of URNs, the only element that provides the URN is the SIP/SigComp application identified by
SIP/SigComp标识符之间的相等比较使用URN相等规则执行，该规则特定于URN中的方案。如果执行比较的元素不理解URN方案，则使用RFC 2141[RFC2141]中定义的词法相等规则执行比较。词法相等可能导致两个URN在实际相等时被视为不相等。在URN的这种特定用法中，提供URN的唯一元素是由标识的SIP/SigComp应用程序
that URN. As a result, the SIP/SigComp application SHOULD provide lexically equivalent URNs in each registration it generates. This is likely to be normal behavior in any case; applications are not likely to modify the value of their SIP/SigComp identifiers so that they remain functionally equivalent yet lexicographically different from previous identifiers.
那个瓮。因此，SIP/SigComp应用程序应在其生成的每个注册中提供词汇等效的URN。这在任何情况下都可能是正常行为；应用程序不太可能修改其SIP/SigComp标识符的值，从而使它们在功能上保持等效，但在词典编纂上与以前的标识符不同。
SIP applications need to know when to open a new compartment and when to close it. The lifetime of SIP/SigComp compartments is linked to registration state. Compartments are opened at SIP registration time and are typically closed when the registration expires or is canceled.
SIP应用程序需要知道何时打开新隔间以及何时关闭它。SIP/SigComp隔室的生存期与注册状态相关联。隔室在SIP注册时打开，通常在注册到期或取消时关闭。
Note: Linking the lifetime of SIP/SigComp compartments to registration state limits the applicability of this specification. In particular, SIP user agents that do not register but, for example, only handle PUBLISH or SUBSCRIBE/NOTIFY transactions are not able create SIP/SigComp compartments following this specification. Previous revisions of this specification also defined compartments valid during a SIP transaction or a SIP dialog. Those compartments covered all possible SIP entities, including those that do not handle REGISTER transactions. However, it was decided to eliminate those types of compartments because the complexity they introduced (e.g., edge proxy servers were required to keep dialog state) was higher than the benefits they brought in most deployment scenarios.
注：将SIP/SigComp隔室的寿命与注册状态联系起来会限制本规范的适用性。特别是，不注册但仅处理发布或订阅/通知事务的SIP用户代理无法按照此规范创建SIP/SigComp分区。本规范以前的版本还定义了在SIP事务或SIP对话期间有效的分区。这些部分涵盖了所有可能的SIP实体，包括那些不处理注册事务的实体。但是，决定取消这些类型的分区，因为它们引入的复杂性（例如，需要边缘代理服务器保持对话状态）高于它们在大多数部署场景中带来的好处。
Usually, any states created during the lifetime of a compartment will be "logically" deleted when the compartment is closed. As described in Section 6.2 of [RFC3320], a logical deletion can become a physical deletion only when no compartment continues to exist that created the (same) state.
通常，当隔室关闭时，在隔室寿命期间创建的任何状态都将被“逻辑”删除。如[RFC3320]第6.2节所述，只有当没有产生（相同）状态的隔室继续存在时，逻辑删除才能成为物理删除。
A SigComp endpoint may offer to keep a state created upon request from a SigComp peer endpoint beyond the default lifetime of a compartment (i.e., beyond the duration of its associated registration). This may be used to improve compression efficiency of subsequent SIP messages generated by the same remote application at the SigComp peer endpoint. To indicate that such state will continue to be available, the SigComp endpoint can inform its peer SigComp endpoint by announcing the (partial) state ID in the returned SigComp parameters at the end of the registration that was supposed to limit the lifetime of the SigComp state. That signals the state will be maintained. The mandatory support for the SigComp Negative
SigComp端点可提供将根据SigComp对等端点的请求创建的状态保持在隔室的默认生存期之外（即，超过其相关注册的持续时间）。这可用于提高由同一远程应用程序在SigComp对等端点处生成的后续SIP消息的压缩效率。为了指示这种状态将继续可用，SigComp端点可以通过在注册结束时在返回的SigComp参数中宣布（部分）状态ID来通知其对等SigComp端点，该状态ID本应限制SigComp状态的生存期。这表明状态将保持不变。对SigComp的强制支持是否定的
Acknowledgement (NACK) Mechanism [RFC4077] in SIP/SigComp ensures that it is possible to recover from synchronization errors regarding compartment lifetimes.
SIP/SigComp中的确认（NACK）机制[RFC4077]确保可以从有关隔间寿命的同步错误中恢复。
As an operational concern, bugs in the compartment management implementation are likely to lead to sporadic, hard-to-diagnose failures. Decompressors may therefore want to cache old state and, if still available, allow access while logging diagnostic information. Both compressors and decompressors use the SigComp Negative Acknowledgement (NACK) Mechanism [RFC4077] to recover from situations where such old state may no longer be available.
作为一个运营问题，隔间管理实施中的缺陷可能会导致零星的、难以诊断的故障。因此，解压缩程序可能希望缓存旧状态，如果仍然可用，则允许在记录诊断信息时进行访问。压缩器和解压缩器都使用SigComp否定确认（NACK）机制[RFC4077]从旧状态可能不再可用的情况中恢复。
A REGISTER transaction causes an application to open a new compartment to be valid for the duration of the registration established by the REGISTER transaction.
注册事务导致应用程序打开一个新分区，使其在注册事务建立的注册期间有效。
A SIP application that needs to send a compressed SIP REGISTER (i.e., a user agent generating a REGISTER or a proxy server relaying one to its next hop) SHOULD open a compartment for the request's remote application identifier. A SIP application that receives a compressed SIP REGISTER (i.e., the registrar or a proxy relaying the REGISTER to its next-hop) SHOULD open a compartment for the request's remote application identifier.
需要发送压缩SIP寄存器的SIP应用程序（即，生成寄存器的用户代理或将寄存器中继到下一跳的代理服务器）应该为请求的远程应用程序标识符打开一个隔间。接收压缩SIP寄存器的SIP应用程序（即，注册器或将寄存器中继到下一跳的代理）应该为请求的远程应用程序标识符打开一个隔间。
These compartments MAY be closed if the REGISTER request is responded with a non-2xx final response, or when the registration expires or is canceled. However, applications MAY also choose to keep these compartments open for a longer period of time, as discussed previously. For a given successful registration, applications SHOULD NOT close their associated compartments until the registration is over.
如果注册请求得到非2xx最终响应，或者注册过期或取消，则这些隔室可能会关闭。但是，如前所述，应用程序也可以选择将这些隔室保持较长时间的打开状态。对于给定的成功注册，在注册结束之前，应用程序不应关闭其相关隔间。
Note: A SIP network can be configured so that regular SIP traffic to and from a user agent traverses a different set of proxies than the initial REGISTER transaction. The path the REGISTER transaction follows is typically determined by configuration data. The path subsequent requests traverse is determined by the Path [RFC3327] and the Service-Route [RFC3308] header fields in the REGISTER transaction and by the Record-Route and the Route header fields in dialog-creating transactions. Previous revisions of this document supported the use of different paths for different types of traffic. However, for simplicity reasons, this document now assumes that networks using compression will be configured so that subsequent requests follow the same path as the initial REGISTER transaction in order to achieve the best possible compression. Section 10 provides network administrators with recommendations so that they can configure the networks properly.
注意：可以对SIP网络进行配置，以使进出用户代理的常规SIP流量通过与初始注册事务不同的一组代理。寄存器事务遵循的路径通常由配置数据确定。后续请求遍历的路径由注册事务中的路径[RFC3327]和服务路由[RFC3308]头字段以及创建事务对话框中的记录路由和路由头字段确定。本文档以前的版本支持对不同类型的流量使用不同的路径。然而，为了简单起见，本文档现在假设将配置使用压缩的网络，以便后续请求遵循与初始寄存器事务相同的路径，以实现最佳压缩。第10节为网络管理员提供了建议，以便他们能够正确配置网络。
If, following the rules above, a SIP application is supposed to open a compartment for a remote application identifier for which it already has a compartment (e.g., the SIP application registers towards a second registrar using the same edge proxy server as for its registration towards its first registrar), the SIP application MUST use the already existing compartment. That is, the SIP application MUST NOT open a new compartment.
如果按照上述规则，SIP应用程序应该为其已具有隔室的远程应用程序标识符打开隔室（例如，SIP应用程序使用与其向其第一注册器注册相同的边缘代理服务器向第二注册器注册），SIP应用程序必须使用已经存在的隔室。也就是说，SIP应用程序不得打开新的隔室。
The use of stateless compression (i.e., compression without a compartment) is not typically worthwhile and may even result in message expansion. Therefore, if a SIP application does not have a compartment for a message it needs to send, it MAY choose not to compress it even in the presence of the 'comp=sigcomp' parameter. Section 5 describes how a SIP application can send compressed and uncompressed messages over the same TCP connection. Note that RFC 3486 [RFC3486] states the following:
使用无状态压缩（即，没有隔室的压缩）通常不值得，甚至可能导致消息扩展。因此，如果SIP应用程序没有用于其需要发送的消息的隔室，则即使存在“comp=sigcomp”参数，它也可以选择不压缩该消息。第5节描述了SIP应用程序如何通过相同的TCP连接发送压缩和未压缩的消息。请注意，RFC 3486[RFC3486]说明了以下内容：
"If the next-hop URI contains the parameter comp=sigcomp, the client SHOULD compress the request using SigComp".
“如果下一个跃点URI包含参数comp=sigcomp，则客户端应使用sigcomp压缩请求”。
Experience since RFC 3486 [RFC3486] was written has shown that stateless compression is, in most cases, not worthwhile. That is why it is not recommended to use it any longer.
自编写RFC33486[RFC3486]以来的经验表明，在大多数情况下，无状态压缩是不值得的。这就是为什么不建议再使用它的原因。
Network administrators can configure their networks so that the compression efficiency achieved is increased. The following recommendations help network administrators perform their task.
网络管理员可以配置他们的网络，从而提高压缩效率。以下建议有助于网络管理员执行其任务。
For a given user agent, the route sets for incoming requests (created by a Path header field) and for outgoing requests (created by a Service-Route header field) are typically the same. However, registrars can, if they wish, insert proxies in the latter route that do not appear in the former route and vice versa. It is RECOMMENDED that registrars are configured so that proxies performing SigComp compression appear in both routes.
对于给定的用户代理，传入请求（由路径头字段创建）和传出请求（由服务路由头字段创建）的路由集通常相同。但是，如果注册人愿意，他们可以在后一条路线中插入在前一条路线中未出现的代理，反之亦然。建议配置注册器，以便执行SigComp压缩的代理出现在两条路由中。
The routes described previously apply to requests sent outside a dialog. Requests inside a dialog follow a route constructed using Record-Route header fields. It is RECOMMENDED that the proxies performing SigComp that are in the route for requests outside a dialog are configured to place themselves (by inserting themselves in the Record-Route header fields) in the routes used for requests inside dialogs.
前面描述的路由适用于在对话框外部发送的请求。对话框中的请求遵循使用记录路由头字段构造的路由。建议将对话框外部请求路由中执行SigComp的代理配置为将其自身（通过将其插入记录路由头字段）放置在对话框内部请求使用的路由中。
When a user agent's registration expires, proxy servers performing compression may close their associated SIP/SigComp compartment. If the user agent is involved in a dialog that was established before the registration expired, subsequent requests within the dialog may not be compressed any longer. In order to avoid this situation, it is RECOMMENDED that user agents are registered as long as they are involved in a dialog.
当用户代理的注册过期时，执行压缩的代理服务器可能会关闭其关联的SIP/SigComp隔室。如果用户代理参与在注册过期之前建立的对话框，则该对话框中的后续请求可能不再被压缩。为了避免这种情况，建议注册用户代理，只要它们参与对话。
SIP/SigComp implementations that are subject to private agreements MAY deviate from this specification, if the private agreements unambiguously specify so. Plausible candidates for such deviations include:
如果专用协议明确规定，受专用协议约束的SIP/SigComp实现可能会偏离本规范。此类偏差的合理备选方案包括：
o Minimum values (Section 4). o Use of continuous mode (Section 6). o Compartment definition (Section 9).
o 最小值（第4节）。o连续模式的使用（第6节）。o隔间定义（第9节）。
SigComp has a number of parameters that can be configured per endpoint. This document specifies a profile for SigComp when used for SIP compression that further constrains the range that some of these parameters may take. Examples of this are Decompressor Memory Size, State Memory Size, and SigComp Version (support for NACK). Additionally, this document specifies how SIP/SigComp applications should perform compartment mapping.
SigComp具有许多参数，可以为每个端点配置这些参数。本文档指定了SigComp用于SIP压缩时的配置文件，该配置文件进一步限制了其中一些参数可能采用的范围。例如解压器内存大小、状态内存大小和SigComp版本（支持NACK）。此外，本文档还规定了SIP/SigComp应用程序应如何执行分区映射。
When this document was written, there were already a few existing SIP/SigComp deployments. The rules in this document have been designed to maximize interoperability with those legacy SIP/SigComp implementations. Nevertheless, implementers should be aware that legacy SIP/SigComp implementations may not conform to this specification. Examples of problems with legacy applications would be smaller DMS than mandated in this document, lack of NACK support, or a different compartment mapping.
在编写本文档时，已有一些现有的SIP/SigComp部署。本文档中的规则旨在最大限度地提高与那些传统SIP/SigComp实现的互操作性。然而，实现者应该知道传统的SIP/SigComp实现可能不符合本规范。遗留应用程序的问题示例包括DMS比本文档中规定的更小、缺少NACK支持或不同的分区映射。
Endpoints exchanging SIP traffic over a TLS [RFC4346] connection can use the compression provided by TLS. Two endpoints exchanging SIP/ SigComp traffic over a TLS connection that provides compression need to first compress the SIP messages using SigComp and then pass them to the TLS layer, which will compress them again. When receiving data, the processing order is reversed.
通过TLS[RFC4346]连接交换SIP流量的端点可以使用TLS提供的压缩。通过提供压缩的TLS连接交换SIP/SigComp流量的两个端点需要首先使用SigComp压缩SIP消息，然后将它们传递给TLS层，TLS层将再次压缩它们。接收数据时，处理顺序颠倒。
However, compressing messages this way twice does not typically bring significant gains. Once a message is compressed using SigComp, TLS is not usually able to compress it further. Therefore, TLS will normally only be able to compress SigComp code sent between compressor and decompressor. Since the gain of having SigComp code compressed should be minimal in most cases, it is NOT RECOMMENDED to use TLS compression when SigComp compression is being used.
然而，以这种方式压缩消息两次通常不会带来显著的收益。一旦使用SigComp对消息进行压缩，TLS通常无法对其进行进一步压缩。因此，TLS通常只能压缩压缩机和解压缩器之间发送的SigComp代码。由于在大多数情况下，压缩SigComp代码的收益应该是最小的，因此在使用SigComp压缩时，不建议使用TLS压缩。
Figure 1 shows an example message flow where the user agent and the outbound proxy exchange compressed SIP traffic. Compressed messages are marked with a (c).
图1显示了一个示例消息流，其中用户代理和出站代理交换压缩的SIP流量。压缩消息用a（c）标记。
User Agent Outbound Proxy Registrar
用户代理出站代理注册器
|(1) REGISTER (c) | |
|---------------->| |
| |(2) REGISTER |
| |---------------->|
| |(3) 200 OK |
| |<----------------|
|(4) 200 OK (c) | |
|<----------------| |
|(5) INVITE (c) | |
|---------------->| |
| |(6) INVITE |
| |------------------------------>
| |(7) 200 OK |
| |<------------------------------
|(8) 200 OK (c) | |
|<----------------| |
|(9) ACK (c) | |
|---------------->| |
| |(10) ACK |
| |------------------------------>
|(11) BYE (c) | |
|---------------->| |
| |(12) BYE |
| |------------------------------>
| |(13) 200 OK |
| |<------------------------------
|(14) 200 OK (c) | |
|<----------------| |
|(1) REGISTER (c) | |
|---------------->| |
| |(2) REGISTER |
| |---------------->|
| |(3) 200 OK |
| |<----------------|
|(4) 200 OK (c) | |
|<----------------| |
|(5) INVITE (c) | |
|---------------->| |
| |(6) INVITE |
| |------------------------------>
| |(7) 200 OK |
| |<------------------------------
|(8) 200 OK (c) | |
|<----------------| |
|(9) ACK (c) | |
|---------------->| |
| |(10) ACK |
| |------------------------------>
|(11) BYE (c) | |
|---------------->| |
| |(12) BYE |
| |------------------------------>
| |(13) 200 OK |
| |<------------------------------
|(14) 200 OK (c) | |
|<----------------| |
Figure 1: Example Message Flow
图1：示例消息流
The user agent in Figure 1 is initially configured (e.g., using the SIP configuration framework [CONFIG]) with the URI of its outbound proxy. That URI contains the outbound proxy's SIP/SigComp identifier, referred to as 'Outbound-id', in a 'sigcomp-id' parameter.
图1中的用户代理最初使用其出站代理的URI进行配置（例如，使用SIP配置框架[CONFIG]）。该URI在“SigComp id”参数中包含出站代理的SIP/SigComp标识符，称为“出站id”。
When the user agent sends an initial REGISTER request (1) to the outbound proxy's URI, the user agent opens a new compartment for 'Outbound-id'. This compartment will be valid for the duration of the registration, at least.
当用户代理向出站代理的URI发送初始注册请求（1）时，用户代理会为“出站id”打开一个新的分区。该隔间至少在注册期间有效。
On receiving this REGISTER request (1), the outbound proxy opens a new compartment for the SIP/SigComp identifier that appears in the 'sigcomp-id' parameter of the top-most Via entry. This identifier, which is the user agent's SIP/SigComp identifier, is referred to as 'UA-id'. The compartment opened by the outbound proxy will be valid for the duration of the registration, at least. The outbound proxy adds a Path header field with its own URI, which contains the 'Outbound-id' SIP/SigComp identifier, to the REGISTER request and relays it to the registrar (2).
收到此注册请求（1）后，出站代理将为SIP/SigComp标识符打开一个新的分区，该标识符出现在最顶端Via条目的“SigComp id”参数中。该标识符是用户代理的SIP/SigComp标识符，称为“UA id”。出站代理打开的分区至少在注册期间有效。出站代理向注册请求添加一个带有自己URI的路径头字段，该URI包含“出站id”SIP/SigComp标识符，并将其转发给注册器（2）。
When the registrar receives the REGISTER request (2), it constructs the route future incoming requests (to the user agent) will follow using the Contact and the Path header fields. Future incoming requests will traverse the outbound proxy before reaching the user agent.
当注册器接收到注册请求（2）时，它使用Contact和Path头字段构造未来传入请求（到用户代理）将遵循的路由。未来的传入请求将在到达用户代理之前遍历出站代理。
The registrar also constructs the route future outgoing requests (from the user agent) will follow and places it in a Service-Route header field in a 200 (OK) response (3). Future outgoing requests will always traverse the outbound proxy. The registrar has ensured that the outbound proxy performing compression handles both incoming and outgoing requests.
注册器还构建未来传出请求（来自用户代理）将遵循的路由，并将其放置在200（确定）响应（3）中的服务路由报头字段中。未来的传出请求将始终遍历出站代理。注册器已确保执行压缩的出站代理处理传入和传出请求。
When the outbound proxy receives a 200 (OK) response (3), it inspects the top-most Via entry. This entry's SIP/SigComp identifier 'UA-id' matches that of the compartment created before. Therefore, the outbound proxy uses that compartment to compress it and relay it to the user agent.
当出站代理收到200（OK）响应（3）时，它将通过条目检查最顶端。此条目的SIP/SigComp标识符“UA id”与之前创建的隔室的标识匹配。因此，出站代理使用该分区对其进行压缩并将其转发给用户代理。
On receiving the 200 (OK) response (4), the user agent stores the Service-Route header field in order to use it to send future outgoing requests. The Service-Route header field contains the outbound proxy's URI, which contains the 'Outbound-id' SIP/SigComp identifier.
在接收到200（确定）响应（4）时，用户代理存储服务路由报头字段，以便使用它发送未来的传出请求。服务路由头字段包含出站代理的URI，其中包含“出站id”SIP/SigComp标识符。
At a later point, the user agent needs to send an INVITE request (5). According to the Service-Route header field received previously, the user agent sends the INVITE request (5) to the outbound proxy's URI.
稍后，用户代理需要发送一个INVITE请求（5）。根据之前接收到的服务路由头字段，用户代理将INVITE请求（5）发送到出站代理的URI。
Since this URI's SIP/SigComp identifier 'Outbound-id' matches that of the compartment created before, this compartment is used to compress the INVITE request.
由于此URI的SIP/SigComp标识符“Outbound id”与之前创建的分区的id匹配，因此此分区用于压缩INVITE请求。
On receiving the INVITE request (5), the outbound proxy Record Routes and relays the INVITE request (6) forward. The outbound proxy Record Routes to ensure that all SIP messages related to this new dialog are routed through the outbound proxy.
在接收到INVITE请求（5）时，出站代理记录路由并转发INVITE请求（6）。出站代理记录路由，以确保与此新对话框相关的所有SIP消息都通过出站代理路由。
Finally, the dialog is terminated by a BYE transaction (11) that also traverses the outbound proxy.
最后，对话框被一个BYE事务（11）终止，该事务也会遍历出站代理。
The same security considerations as described in [RFC3320] apply to this document. Note that keeping SigComp states longer than the duration of a SIP dialog should not pose new security risks because the state has been allowed to be created in the first place.
[RFC3320]中所述的安全注意事项同样适用于本文件。请注意，将SigComp状态保持在SIP对话持续时间之外不应带来新的安全风险，因为该状态首先被允许创建。
The IANA has registered the 'sigcomp-id' Via header field parameter, which is defined in Section 9.1, under the Header Field Parameters and Parameter Values subregistry within the SIP Parameters registry:
IANA已通过第9.1节中定义的标题字段参数在SIP参数注册表的标题字段参数和参数值子区下注册了“sigcomp id”：
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Via sigcomp-id No [RFC5049]
Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Via sigcomp-id No [RFC5049]
The IANA has registered the 'sigcomp-id' SIP URI parameter, which is defined in Section 9.1, under the SIP/SIPS URI Parameters subregistry within the SIP Parameters registry:
IANA已将第9.1节中定义的“sigcomp id”SIP URI参数注册在SIP参数注册表中的SIP/SIPS URI参数子区下：
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
sigcomp-id No [RFC5049]
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
sigcomp-id No [RFC5049]
The authors would like to thank the following people for their comments and suggestions: Jan Christoffersson, Joerg Ott, Mark West, Pekka Pessi, Robert Sugar, Jonathan Rosenberg, Robert Sparks, Juergen Schoenwaelder, and Tuukka Karvonen. Abigail Surtees and Adam Roach performed thorough reviews of this document.
作者要感谢以下人士的评论和建议：Jan Christofferson、Joerg Ott、Mark West、Pekka Pessi、Robert Sugar、Jonathan Rosenberg、Robert Sparks、Juergen Schoenwaeld和Tuukka Karvonen。Abigail Surtees和Adam Roach对本文件进行了全面审查。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]Moats，R.，“瓮语法”，RFC 21411997年5月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3308] Calhoun, P., Luo, W., McPherson, D., and K. Peirce, "Layer Two Tunneling Protocol (L2TP) Differentiated Services Extension", RFC 3308, November 2002.
[RFC3308]Calhoun，P.，Luo，W.，McPherson，D.，和K.Peirce，“第二层隧道协议（L2TP）区分服务扩展”，RFC 33082002年11月。
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[RFC3320]Price，R.，Bormann，C.，Christofferson，J.，Hannu，H.，Liu，Z.，和J.Rosenberg，“信号压缩（SigComp）”，RFC3320，2003年1月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327]Willis，D.和B.Hoeneisen，“用于注册非相邻联系人的会话启动协议（SIP）扩展头字段”，RFC 3327，2002年12月。
[RFC3485] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A. Roach, "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)", RFC 3485, February 2003.
[RFC3485]Garcia Martin，M.，Bormann，C.，Ott，J.，Price，R.，和A.Roach，“会话启动协议（SIP）和会话描述协议（SDP）信令压缩静态字典（SigComp）”，RFC 3485，2003年2月。
[RFC3486] Camarillo, G., "Compressing the Session Initiation Protocol (SIP)", RFC 3486, February 2003.
[RFC3486]Camarillo，G.“压缩会话启动协议（SIP）”，RFC 3486，2003年2月。
[RFC4077] Roach, A., "A Negative Acknowledgement Mechanism for Signaling Compression", RFC 4077, May 2005.
[RFC4077]Roach，A.，“信号压缩的否定确认机制”，RFC4077，2005年5月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[RFC4234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.1", RFC 4346, April 2006.
[RFC4346]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.1”，RFC 4346，2006年4月。
[RFC4896] Surtees, A., West, M., and A. Roach, "Signaling Compression (SigComp) Corrections and Clarifications", RFC 4896, June 2007.
[RFC4896]Surtees，A.，West，M.和A.Roach，“信号压缩（SigComp）纠正和澄清”，RFC 48962007年6月。
[CONFIG] Petrie, D. and S. Channabasappa, "A Framework for Session Initiation Protocol User Agent Profile Delivery", Work in Progress, June 2007.
[CONFIG]Petrie，D.和S.Channabasappa，“会话启动协议用户代理配置文件交付框架”，正在进行的工作，2007年6月。
[OUTBOUND] Jennings, C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, March 2007.
[OUTBOUND]Jennings，C.和R.Mahy，“在会话启动协议（SIP）中管理客户端启动的连接”，正在进行的工作，2007年3月。
Authors' Addresses
作者地址
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28334 Germany
卡斯滕·鲍曼大学不来梅邮政学院330440不来梅D-28334德国
Phone: +49 421 218 63921
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Phone: +49 421 218 63921
Fax: +49 421 218 7000
EMail: cabo@tzi.org
Zhigang Liu Nokia Research Center 955 Page Mill Road Palo Alto, CA 94304 USA
刘志刚诺基亚研究中心美国加利福尼亚州帕洛阿尔托佩奇米尔路955号，邮编94304
Phone: +1 650 796 4578
EMail: zhigang.c.liu@nokia.com
Phone: +1 650 796 4578
EMail: zhigang.c.liu@nokia.com
Richard Price EADS Defence and Security Systems Limited Meadows Road Queensway Meadows Newport, Gwent NP19 4SS
Richard Price EADS国防和安全系统有限公司梅多斯路金钟道梅多斯新港，格温特NP19 4SS
Phone: +44 (0)1633 637874
EMail: richard.price@eads.com
Phone: +44 (0)1633 637874
EMail: richard.price@eads.com
Gonzalo Camarillo (editor) Ericsson Hirsalantie 11 Jorvas 02420 Finland
冈萨洛·卡马里洛（编辑）爱立信·赫萨兰蒂11号乔瓦斯02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.