Network Working Group G. Camarillo
Request for Comments: 3486 Ericsson
Category: Standards Track February 2003
Network Working Group G. Camarillo
Request for Comments: 3486 Ericsson
Category: Standards Track February 2003
Compressing the Session Initiation Protocol (SIP)
压缩会话启动协议（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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document describes a mechanism to signal that compression is desired for one or more Session Initiation Protocol (SIP) messages. It also states when it is appropriate to send compressed SIP messages to a SIP entity.
本文档描述了一种机制，用于表示一个或多个会话启动协议（SIP）消息需要压缩。它还说明何时适合向SIP实体发送压缩的SIP消息。
Table of Contents
目录
1. Introduction ............................................... 2
2. Overview of operation ...................................... 3
3. SigComp implementations for SIP ............................ 3
4. Sending a Request to a Server .............................. 3
4.1 Obtaining a SIP or SIPS URI with comp=sigcomp ........ 4
5. Sending a Response to a Client ............................. 5
6. Double Record-Routing ...................................... 6
7. Error Situations ........................................... 6
8. Augmented BNF .............................................. 7
9. Example .................................................... 7
10. Security Considerations .................................... 10
11. IANA Considerations ........................................ 10
12. Acknowledgements............................................ 10
13. Normative References ....................................... 10
14. Informative References ..................................... 11
15. Author's Address............................................ 11
16. Full Copyright Statement.................................... 12
1. Introduction ............................................... 2
2. Overview of operation ...................................... 3
3. SigComp implementations for SIP ............................ 3
4. Sending a Request to a Server .............................. 3
4.1 Obtaining a SIP or SIPS URI with comp=sigcomp ........ 4
5. Sending a Response to a Client ............................. 5
6. Double Record-Routing ...................................... 6
7. Error Situations ........................................... 6
8. Augmented BNF .............................................. 7
9. Example .................................................... 7
10. Security Considerations .................................... 10
11. IANA Considerations ........................................ 10
12. Acknowledgements............................................ 10
13. Normative References ....................................... 10
14. Informative References ..................................... 11
15. Author's Address............................................ 11
16. Full Copyright Statement.................................... 12
A SIP [1] client sending a request to a SIP server typically performs a DNS lookup for the domain name of the server. When NAPTR [4] or SRV [5] records are available for the server, the client can specify the type of service it wants. The service in this context is the transport protocol to be used by SIP (e.g., UDP, TCP or SCTP). A SIP server that supports, for instance, three different transport protocols, will have three different DNS entries.
向SIP服务器发送请求的SIP[1]客户端通常会对服务器的域名执行DNS查找。当NAPTR[4]或SRV[5]记录可用于服务器时，客户机可以指定它想要的服务类型。此上下文中的服务是SIP使用的传输协议（例如UDP、TCP或SCTP）。例如，支持三种不同传输协议的SIP服务器将有三个不同的DNS条目。
Since it is foreseen that the number of transport protocols supported by a particular application layer protocol is not going to grow dramatically, having a DNS entry per transport seems like a scalable enough solution.
由于可以预见，特定应用层协议支持的传输协议的数量不会急剧增长，因此每个传输都有一个DNS条目似乎是一个可扩展的解决方案。
However, sometimes it is necessary to include new layers between the transport protocol and the application layer protocol. Examples of these layers are transport layer security and compression. If DNS was used to discover the availability of these layers for a particular server, the number of DNS entries needed for that server would grow dramatically.
然而，有时需要在传输协议和应用层协议之间包括新的层。这些层的示例是传输层安全性和压缩。如果使用DNS来发现特定服务器的这些层的可用性，则该服务器所需的DNS条目数量将急剧增加。
A server that, for example, supported TCP and SCTP as transports, TLS for transport security and SigComp for signaling compression, would need the 8 DNS entries listed below:
例如，支持TCP和SCTP作为传输，TLS用于传输安全，SigComp用于信令压缩的服务器需要下面列出的8个DNS条目：
1. TCP, no security, no compression
1. TCP，没有安全性，没有压缩
2. TCP, no security, SigComp
2. TCP，无安全性，SigComp
3. TCP, TLS, no compression
3. TCP，TLS，无压缩
4. TCP, TLS, SigComp
4. TCP、TLS、SigComp
5. SCTP, no security, no compression
5. SCTP，无安全性，无压缩
6. SCTP, no security, SigComp
6. SCTP，无安全，SigComp
7. SCTP, TLS, no compression
7. SCTP，TLS，无压缩
8. SCTP, TLS, SigComp
8. SCTP、TLS、SigComp
It is clear that this way of using DNS is not scalable. Therefore, an application layer mechanism to express support of signalling compression is needed.
很明显，这种使用DNS的方式是不可伸缩的。因此，需要一种应用层机制来表示对信令压缩的支持。
Note that for historical reasons both HTTP and SIP use a different port for TLS on top of TCP than for TCP alone, although at present, this solution is not considered scalable any longer.
请注意，由于历史原因，HTTP和SIP在TCP之上为TLS使用的端口与单独为TCP使用的端口不同，尽管目前认为此解决方案不再具有可扩展性。
A SIP element that supports compression will need to be prepared to receive compressed and uncompressed messages on the same port. It will perform demultiplexing based on the cookie in the topmost bits of every compressed message.
支持压缩的SIP元素需要准备好在同一端口上接收压缩和未压缩的消息。它将根据每个压缩消息的最高位中的cookie执行解复用。
There are two types of SIP messages; SIP requests and SIP responses. Clients send SIP requests to the host part of a URI and servers send responses to the host in the sent-by parameter of the Via header field.
有两种类型的SIP消息；SIP请求和SIP响应。客户端向URI的主机部分发送SIP请求，服务器在Via标头字段的sent by参数中向主机发送响应。
We define two parameters, one for SIP URIs and the other for the Via header field. The format of both parameters is the same, as shown in the examples below:
我们定义了两个参数，一个用于SIPURI，另一个用于Via头字段。两个参数的格式相同，如下例所示：
sip:alice@atlanta.com;comp=sigcomp
Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp
sip:alice@atlanta.com;comp=sigcomp
Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp
The presence of this parameter (comp=sigcomp) in a URI indicates that the request has to be compressed using SigComp, as defined in [2]. The presence of comp=sigcomp in a Via header field indicates that the response has to be compressed using SigComp.
URI中存在此参数（comp=sigcomp）表示必须使用sigcomp压缩请求，如[2]中所定义。Via标头字段中存在comp=sigcomp表示必须使用sigcomp压缩响应。
Therefore, the presence of comp=sigcomp indicates that the SIP entity identified by the URI or by the Via header field supports SigComp and is willing to receive compressed messages. Having comp=sigcomp mean "willingness" as well as "support" allows the receiver of a SIP message to influence the decision of whether or not to use SigComp at a given time.
因此，comp＝sigcomp的存在表示由URI或Via报头字段标识的SIP实体支持sigcomp并且愿意接收压缩消息。使comp＝sigcomp表示“意愿”以及“支持”允许SIP消息的接收者在给定时间影响是否使用sigcomp的决定。
Every SIP implementation that supports SigComp MUST implement the procedures described in this document.
支持SigComp的每个SIP实现都必须实现本文档中描述的过程。
A request is sent to the host part of a URI. This URI, referred to as the next-hop URI, is the Request-URI of the request or an entry in the Route header field.
请求被发送到URI的主机部分。此URI（称为下一跳URI）是请求的请求URI或路由头字段中的条目。
If the next-hop URI contains the parameter comp=sigcomp, the client SHOULD compress the request using SigComp as defined in [2].
如果下一跳URI包含参数comp=sigcomp，则客户端应使用[2]中定义的sigcomp压缩请求。
If the next-hop URI is a SIPS URI, the request SHOULD be compressed before it is passed to the TLS layer.
如果下一个跃点URI是SIPS URI，则应在将请求传递到TLS层之前对其进行压缩。
A client MUST NOT send a compressed request to a server if it does not know whether or not the server supports SigComp.
如果客户机不知道服务器是否支持SigComp，则不得向服务器发送压缩请求。
Regardless of whether the request is sent compressed or not, if a client would like to receive subsequent requests within the same dialog in the UAS->UAC direction compressed, this client SHOULD add the parameter comp=sigcomp to the URI in the Contact header field if it is a user agent client. If the client is a proxy, it SHOULD add the parameter comp=sigcomp to its URI in the Record-Route header field.
无论请求是否被压缩发送，如果客户端希望在UAS->UAC压缩方向的同一对话框中接收后续请求，则该客户端应将参数comp=sigcomp添加到Contact header字段中的URI（如果它是用户代理客户端）。如果客户端是一个代理，它应该将参数comp=sigcomp添加到记录路由头字段中的URI中。
If a user agent client sends a compressed request, it SHOULD add the parameter comp=sigcomp to the URI in the Contact header field. If a proxy that Record-Routes sends a compressed request, it SHOULD add comp=sigcomp to its URI in the Record-Route header field.
如果用户代理客户端发送压缩请求，则应将参数comp=sigcomp添加到联系人标头字段中的URI中。如果记录路由的代理发送压缩请求，它应该将comp=sigcomp添加到记录路由头字段中的URI中。
If a client sends a compressed request, it SHOULD add the parameter comp=sigcomp to the topmost entry of the Via header field.
如果客户端发送压缩请求，则应将参数comp=sigcomp添加到Via标头字段的最顶端条目。
If a client does not know whether or not the server supports SigComp, but in case the server supported it, it would like to receive compressed responses, this client SHOULD add the parameter comp=sigcomp to the topmost entry of the Via header field. The request, however, as stated above, will not be compressed.
如果客户机不知道服务器是否支持SigComp，但如果服务器支持它，它希望接收压缩响应，则该客户机应将参数comp=SigComp添加到Via标头字段的最顶部条目。但是，如上所述，请求将不会被压缩。
For requests within a dialog, a next-hop URI with the comp=sigcomp parameter is obtained from a Record-Route header field when the dialog is established. A client sending a request outside a dialog can also obtain SIP URIs with comp=sigcomp in a Contact header field in a 3xx or 485 response to the request.
对于对话框内的请求，当对话框建立时，将从记录路由头字段获取带有comp=sigcomp参数的下一跳URI。在对话框外部发送请求的客户端也可以在对请求的3xx或485响应中的联系人标头字段中获得comp=sigcomp的SIP URI。
However, clients establishing a session will not typically be willing to wait until the dialog is established in order to begin compressing messages. One of the biggest gains that SigComp can bring to SIP is the ability to compress the initial INVITE of a dialog, when the user is waiting for the session to be established. Therefore, clients need a means to obtain a comp=sigcomp URI from their outbound proxy before the user decides to establish a session.
但是，建立会话的客户端通常不愿意等到对话框建立后才开始压缩消息。SigComp为SIP带来的最大好处之一是，当用户等待会话建立时，能够压缩对话框的初始邀请。因此，在用户决定建立会话之前，客户端需要一种从其出站代理获取comp=sigcomp URI的方法。
One solution to this problem is manual configuration. However, sometimes it is necessary to have clients configured in an automatic fashion. Unfortunately, current mechanisms for SIP client configuration (e.g., using DHCP [6]) do not allow to provide the
这个问题的一个解决方案是手动配置。但是，有时需要以自动方式配置客户端。不幸的是，当前的SIP客户端配置机制（例如，使用DHCP[6]）不允许提供
client with URI parameters. In this case, the client SHOULD send an uncompressed OPTIONS request to its outbound proxy. The outbound proxy can provide an alternative SIP URI with the comp=sigcomp parameter in a Contact header field in a 200 OK response to the OPTIONS. The client can use this URI for subsequent requests that are sent through the same outbound proxy using compression.
具有URI参数的客户端。在这种情况下，客户端应向其出站代理发送未压缩的选项请求。出站代理可以在对选项的200 OK响应中，在Contact header字段中提供具有comp=sigcomp参数的替代SIP URI。客户端可以将此URI用于使用压缩通过同一出站代理发送的后续请求。
RFC 3261 [1] does not define how a proxy should respond to an OPTIONS request addressed to itself. It only describes how servers respond to OPTIONS addressed to a particular user. Section 11.2 of RFC 3261 says:
RFC 3261[1]未定义代理应如何响应发送给自身的选项请求。它仅描述服务器如何响应针对特定用户的选项。RFC 3261第11.2节规定：
Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user.
联系人标头字段可能出现在200（OK）响应中，并且具有与3xx响应相同的语义。也就是说，他们可以列出一组备选名称和联系用户的方法。
We extend this behavior to proxy servers responding to OPTIONS addressed to them. They MAY list a set of alternative URIs to contact the proxy.
我们将此行为扩展到代理服务器，以响应针对它们的选项。他们可能会列出一组备选URI来联系代理。
Note that receiving incoming requests (even initial INVITEs) compressed is not a problem, since user agents can REGISTER a SIP URI with comp=sigcomp in their registrar. All incoming requests for the user will be sent to this SIP URI using compression.
请注意，接收压缩的传入请求（甚至初始邀请）不是问题，因为用户代理可以在其注册器中使用comp=sigcomp注册SIPURI。用户的所有传入请求都将使用压缩发送到此SIPURI。
A response is sent to the host in the sent-by parameter of the Via header field. If the topmost Via header field contains the parameter comp=sigcomp, the response SHOULD be compressed. Otherwise, the response MUST NOT be compressed.
在Via标头字段的sent by参数中向主机发送响应。如果最顶部的Via标头字段包含参数comp=sigcomp，则应压缩响应。否则，不得压缩响应。
In order to avoid asymmetric compression (i.e., two SIP entities exchanging compressed requests in one direction and uncompressed requests in the other direction) proxies need to rewrite their Record-Route entries in the responses. A proxy performing Record-Route inspects the Record-Route header field in the response and the Contact header field in the request that triggered this response (see example in Section 9). It looks for the URI of the next upstream (closer to the user agent client) hop in the route set. If this URI contains the parameter comp=sigcomp, the proxy SHOULD add comp=sigcomp to its entry in the Record-Route header field. If this URI does not contain the parameter comp=sigcomp, the proxy SHOULD remove comp=sigcomp (if it is present) from its entry in the Record-Route header field.
为了避免不对称压缩（即，两个SIP实体在一个方向交换压缩请求，在另一个方向交换未压缩请求），代理需要在响应中重写它们的记录路由条目。执行记录路由的代理检查响应中的记录路由头字段和触发此响应的请求中的联系人头字段（参见第9节中的示例）。它在路由集中查找下一个上游（更靠近用户代理客户端）跃点的URI。如果此URI包含参数comp=sigcomp，则代理应将comp=sigcomp添加到记录路由头字段中的条目中。如果此URI不包含参数comp=sigcomp，则代理应将comp=sigcomp（如果存在）从其记录路由标头字段的条目中删除。
The same way, a user agent server SHOULD add comp=sigcomp to the Contact header field of the response if the URI of the next upstream hop in the route set contained the parameter comp=sigcomp.
同样，如果路由集中下一个上游跃点的URI包含参数comp=sigcomp，则用户代理服务器应将comp=sigcomp添加到响应的联系人标头字段中。
Although proxies usually add zero or one Record-Route entries to a particular request, some proxies add two of them to avoid Record-Route rewriting. A typical example of double Record-Routing is a SIP proxy that acts as a firewall between two networks. Depending on which network a request comes from, it will be received on a different interface by the proxy. The proxy adds one Record-Route entry for one interface and a second one for the other interface. This way, the proxy does not need to rewrite the Record-Route header field on the response.
虽然代理通常会向特定请求添加零个或一个记录路由条目，但有些代理会添加其中两个条目以避免记录路由重写。双记录路由的一个典型示例是充当两个网络之间防火墙的SIP代理。根据请求来自哪个网络，代理将在不同的接口上接收请求。代理为一个接口添加一个记录路由条目，为另一个接口添加第二个记录路由条目。这样，代理不需要重写响应上的记录路由头字段。
Proxies that receive compressed messages from one side of the dialog (e.g., upstream) and uncompressed messages from the other side (e.g., downstream) MAY use the mechanism described above.
从对话框一侧（例如，上游）接收压缩消息和从另一侧（例如，下游）接收未压缩消息的代理可以使用上述机制。
If a proxy detects that the next-hop proxy for a request is the proxy itself and that the request will not be sent through the network, the proxy MAY choose not to compress the request even if the URI contains the comp=sigcomp parameter.
如果代理检测到请求的下一跳代理是代理本身，并且请求不会通过网络发送，则即使URI包含comp=sigcomp参数，代理也可以选择不压缩请求。
If a compressed SIP request arrives to a SIP server that does not understand SigComp, the server will not have any means to indicate the error to the client. The message will be impossible to parse, and there will be no Via header field indicating an address to send an error response.
如果压缩的SIP请求到达不理解SigComp的SIP服务器，服务器将无法向客户端指示错误。消息将无法解析，并且不会有Via头字段指示发送错误响应的地址。
If a SIP client sends a compressed request and the client transaction times out without having received any response, the client SHOULD retry the same request without using compression. If the compressed request was sent over a TCP connection, the client SHOULD close that connection and open a new one to send the uncompressed request. Otherwise the server would not be able to detect the beginning of the new message.
如果SIP客户端发送压缩请求，并且客户端事务超时而未收到任何响应，则客户端应在不使用压缩的情况下重试相同的请求。如果压缩请求是通过TCP连接发送的，则客户端应关闭该连接并打开一个新连接以发送未压缩的请求。否则，服务器将无法检测到新消息的开头。
This section provides the augmented Backus-Naur Form (BNF) of both parameters described above.
本节提供了上述两个参数的增强巴科斯-诺尔形式（BNF）。
The compression URI parameter is a "uri-parameter", as defined by the SIP ABNF (Section 25.1 of [1]):
压缩URI参数是一个“URI参数”，由SIP ABNF定义（见[1]第25.1节）：
compression-param = "comp=" ("sigcomp" / other-compression)
other-compression = token
compression-param = "comp=" ("sigcomp" / other-compression)
other-compression = token
The Via compression parameter is a "via-extension", as defined by the SIP ABNF (Section 25.1 of [1]):
按照SIP ABNF（第25.1节[1]）的定义，通孔压缩参数为“通孔扩展”：
via-compression = "comp" EQUAL ("sigcomp" / other-compression) other-compression = token
via compression=“comp”EQUAL（“sigcomp”/other compression）other compression=令牌
The following example illustrates the use of the parameters defined above. The call flow of Figure 1 shows an INVITE-200 OK-ACK handshake between a UAC and a UAS through two proxies. Proxy P1 does not Record-Route but proxy P2 does. Both proxies support compression, but they do not use it by default.
下面的示例说明了上面定义的参数的使用。图1的调用流显示了UAC和UAS之间通过两个代理进行的INVITE-200 OK-ACK握手。代理P1不记录路由，但代理P2记录路由。两个代理都支持压缩，但默认情况下不使用压缩。
UAC P1 P2 UAS
无人机P1 P2无人机
|(1)INVITE(c) | | |
|------------>| (2) INVITE | |
| |------------>| (3) INVITE |
| | |------------>|
| | | (4) 200 OK |
| | (5) 200 OK |<------------|
|(6)200 OK(c) |<------------| |
|<------------| | |
| | (7)ACK(c) | |
|-------------------------->| (8) ACK |
| | |------------>|
| | | |
| | | |
|(1)INVITE(c) | | |
|------------>| (2) INVITE | |
| |------------>| (3) INVITE |
| | |------------>|
| | | (4) 200 OK |
| | (5) 200 OK |<------------|
|(6)200 OK(c) |<------------| |
|<------------| | |
| | (7)ACK(c) | |
|-------------------------->| (8) ACK |
| | |------------>|
| | | |
| | | |
Figure 1: INVITE transaction through two proxies
图1：通过两个代理邀请事务
Messages (1), (6) and (7) are compressed (c).
消息（1）、（6）和（7）被压缩（c）。
We provide a partial description of the messages involved in this call flow below. Only some parts of each message are shown, namely the Method name, the Request-URI and the Via, Route, Record-Route and
下面我们将对该调用流中涉及的消息进行部分描述。只显示每条消息的某些部分，即方法名、请求URI和Via、路由、记录路由和路由
Contact header fields. We have not used a correct format for these header fields. We have rather focus on the contents of the header fields and on the presence (or absence) of the "comp=sigcomp" parameter.
联系人标题字段。我们没有为这些标题字段使用正确的格式。我们更关注头字段的内容以及“comp=sigcomp”参数的存在（或不存在）。
(1) INVITE UAS
Via: UAC;comp=sigcomp
Route: P1;comp=sigcomp
Contact: UAC;comp=sigcomp
(1) INVITE UAS
Via: UAC;comp=sigcomp
Route: P1;comp=sigcomp
Contact: UAC;comp=sigcomp
P1 is the outbound proxy of the UAC, and it supports SigComp. The UAC is configured to send compressed traffic to P1, and therefore, it compresses the INVITE (1). In addition, the UAC wants to receive future requests and responses for this dialog compressed. Therefore, it adds the comp=Sigcomp parameter to the Via and to the Contact header fields.
P1是UAC的出站代理，支持SigComp。UAC被配置为向P1发送压缩流量，因此，它压缩INVITE（1）。此外，UAC希望接收此对话框的未来请求和响应。因此，它将comp=Sigcomp参数添加到Via和Contact header字段中。
(2) INVITE UAS
Via: P1
Via: UAC;comp=sigcomp
Route: P2
Contact: UAC;comp=sigcomp
(2) INVITE UAS
Via: P1
Via: UAC;comp=sigcomp
Route: P2
Contact: UAC;comp=sigcomp
P1 forwards the INVITE (2) to P2. P1 does not use compression by default, so it sends the INVITE uncompressed to P2.
P1将邀请（2）转发给P2。P1在默认情况下不使用压缩，因此它会将未压缩的INVITE发送给P2。
(3) INVITE UAS
Via: P2
Via: P1
Via: UAC;comp=sigcomp
Record-Route: P2
Contact: UAC;comp=sigcomp
(3) INVITE UAS
Via: P2
Via: P1
Via: UAC;comp=sigcomp
Record-Route: P2
Contact: UAC;comp=sigcomp
P2 forwards the INVITE (3) to the UAS. P2 supports compression, but it does not use it by default. Therefore, it sends the INVITE uncompressed. P2 wishes to remain in the signalling path and therefore it Record-Routes.
P2将邀请（3）转发给UAS。P2支持压缩，但默认情况下不使用压缩。因此，它以未压缩的方式发送邀请。P2希望保留在信令路径中，因此它记录路由。
(4) 200 OK Via: P2 Via: P1 Via: UAC;comp=sigcomp Record-Route: P2 Contact: UAS
(4) 200正常通过：P2通过：P1通过：UAC；comp=sigcomp记录路由：P2联系人：UAS
The UAS generates a 200 OK response and sends it to the host in the topmost Via, which is P2.
UAS生成一个200 OK响应，并通过最顶端的通道（即P2）将其发送到主机。
(5) 200 OK
Via: P1
Via: UAC;comp=sigcomp
Record-Route: P2;comp=sigcomp
Contact: UAS
(5) 200 OK
Via: P1
Via: UAC;comp=sigcomp
Record-Route: P2;comp=sigcomp
Contact: UAS
P2 receives the 200 OK response. P2 Record-Routed, so it inspects the Route set for this dialog. For requests from the UAS towards the UAC (the opposite direction than the first INVITE), the next hop will be the Contact header field of the INVITE, because P1 did not Record-Route. That Contact identified the UAC:
P2接收200 OK响应。P2记录路由，因此它检查此对话框的路由集。对于从UAS到UAC的请求（与第一个INVITE的方向相反），下一个跃点将是INVITE的联系人标头字段，因为P1没有记录路由。该联系人确认了UAC：
Contact: UAC;comp=sigcomp
Contact: UAC;comp=sigcomp
Since the UAC wants to receive compressed requests (Contact of the INVITE), P2 assumes that the UAC would also like to send compressed requests (Record-Route of the 200 OK). Therefore, P2 modifies its entry in the Record-Route header field of the 200 OK (5). In the INVITE (3), P2 did not used the comp=sigcomp parameter. Now it adds it in the 200 OK (5). This will allow the UAC sending compressed requests within this dialog.
由于UAC希望接收压缩请求（邀请联系人），P2假定UAC也希望发送压缩请求（记录200 OK的路由）。因此，P2修改200 OK（5）的记录路由头字段中的条目。在INVITE（3）中，P2未使用comp=sigcomp参数。现在它将其添加到200 OK（5）中。这将允许UAC在此对话框中发送压缩请求。
(6) 200 OK
Via: UAC;comp=sigcomp
Record-Route: P2;comp=sigcomp
Contact: UAS
(6) 200 OK
Via: UAC;comp=sigcomp
Record-Route: P2;comp=sigcomp
Contact: UAS
P1 sends the 200 OK (6) compressed to the UAC because the Via header field contained the comp=sigcomp parameter.
P1向UAC发送压缩的200 OK（6），因为Via标头字段包含comp=sigcomp参数。
(7) ACK UAS
Via: UAC;comp=sigcomp
Route: P2;comp=sigcomp
Contact: UAC;comp=sigcomp
(7) ACK UAS
Via: UAC;comp=sigcomp
Route: P2;comp=sigcomp
Contact: UAC;comp=sigcomp
The UAC sends the ACK (7) compressed directly to P2 (P1 did not Record-Route).
UAC将压缩的ACK（7）直接发送到P2（P1未记录路由）。
(8) ACK UAS
Via: P2
Via: UAC;comp=sigcomp
Contact: UAC;comp=sigcomp
(8) ACK UAS
Via: P2
Via: UAC;comp=sigcomp
Contact: UAC;comp=sigcomp
P2 sends the ACK (8) uncompressed to the UAS.
P2向UAS发送未压缩的ACK（8）。
A SIP entity receiving a compressed message has to decompress it and to parse it. This requires slightly more processing power than only parsing a message. This implies that a denial of service attack using compressed messages would be slightly worse than an attack with uncompressed messages.
接收压缩消息的SIP实体必须对其进行解压缩和解析。这比仅解析消息需要稍多的处理能力。这意味着使用压缩消息的拒绝服务攻击将比使用未压缩消息的攻击稍差。
An attacker inserting the parameter comp=sigcomp in a SIP message could make a SIP entity send compressed messages to another SIP entity that did not support SigComp. Appropriate integrity mechanisms should be used to avoid this attack.
攻击者在SIP消息中插入参数comp=sigcomp可能会使SIP实体向另一个不支持sigcomp的SIP实体发送压缩消息。应使用适当的完整性机制来避免此攻击。
This document defines the "comp" uri-parameter and via-extension. New values for "comp" are registered by the IANA at http://www.iana.org/assignments/sip-parameters when new signalling compression schemes are published in standards track RFCs. The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication.
本文档定义了“comp”uri参数，并通过扩展名进行了定义。IANA在以下地址注册了“comp”的新值：http://www.iana.org/assignments/sip-parameters 当新的信令压缩方案在标准轨道RFCs中发布时。RFC的IANA注意事项部分必须包括以下信息，这些信息与出版物的RFC编号一起出现在IANA注册表中。
o Name of the compression scheme.
o 压缩方案的名称。
o Token value to be used. The token MAY be of any length, but SHOULD be no more than ten characters long.
o 要使用的令牌值。令牌可以是任意长度，但长度不应超过十个字符。
The only entry in the registry for the time being is:
目前注册表中唯一的条目是：
Compression scheme Token Reference
--------------------- --------- ---------
Signaling Compression sigcomp RFC 3486
Compression scheme Token Reference
--------------------- --------- ---------
Signaling Compression sigcomp RFC 3486
Allison Mankin, Jonathan Rosenberg and Miguel Angel Garcia-Martin provided valuable comments on this memo.
Allison Mankin、Jonathan Rosenberg和Miguel Angel Garcia Martin对此备忘录提出了宝贵意见。
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[2] Price，R.，Bormann，C.，Christofferson，J.，Hannu，H.，Liu，Z.和J.Rosenberg，“信号压缩（SigComp）”，RFC3320，2003年1月。
[3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[4] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[5] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[5] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[6] Schulzrinne, H., "DHCP option for SIP servers", Work in Progress.
[6] Schulzrinne，H.，“SIP服务器的DHCP选项”，正在进行中。
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson高级信号研究实验室FIN-02420 Jorvas芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。