RFC3486 SIP协议压缩

以下是偶对RFC 3486主要部分的翻译，初次尝试，能力有限，欢迎指正！

[RFC 3486]                          SIP压缩                                                         ----Translated By MoaKap
摘要：对于一个或多个SIP消息来说，压缩是必要的，也是合理的。

目录
1、引言
2、操作概述
3、SIP信令压缩的实现
4、向服务器端发送SIP请求
  4.1 获取带有comp=sigcomp参数的SIP或SIPS URI
5、向客户端发送SIP应答
6、双重Record-Routing
7、错误处理
8、扩展的BNF
9、实例
10、安全考虑

1.  引言
当一个SIP客户端向服务器端发送一个SIP请求时，客户端扮演了一个典型的DNS查询的
过程，即查询服务器所在域的过程。如果可以获取NAPTR或SRV路径，服务器可以清楚地
获知客户端请求的服务类型。这里的服务类型指的是SIP所使用的传输层协议类型，如
UDP、TCP或SCTP。例如，如果一个SIP服务器支持这三种传输协议，那么它将会有三个不
同的DNS入口。

可以预见，对一个特定的应用层协议来说，由于每增加一种传输协议的支持就要求打开
对应的DNS入口，实现起来似乎是一个并不简单的工作，因此应用协议支持的传输协议数
量在实际中并不能动态增加。

然而，有时候在应用层协议与传输层协议之间添加新的层又是必要的，比如加入传输层
的安全控制和压缩。对一个特定的服务器，如果使用DNS来发现这些特定功能层的可用性，
那么服务器所支持的DNS入口就可以根据需要动态增加了。

例如，一个服务器支持TCP、SCTP传输，使用TLS控制传输安全，使用SigComp实现信令压缩，
那么下面8个DNS入口是必须的：
  1  TCP，无安全控制，无压缩
  2  TCP，无安全控制，使用信令压缩（SigComp）
  3  TCP，TLS安全控制，无压缩
  4  TCP，TLS，SigComp
  5  SCTP，无安全控制，无压缩
  6  TCP，无安全控制，SigComp
  7  TCP，TLS，无压缩
  8  TCP，TLS，SigComp
显然，这种使用DNS的方法并不合理。因此，就需要一种支持信令压缩的应用层机制。

注意，由于以前HTTP和SIP在TCP上实现TLS安全控制以及单独使用TCP时都分别使用不同的端口，
即时现在仍然如此，这种解决方案并不合理。

一个支持压缩的SIP单元需要能够在同一端口既可以接收压缩的消息，也可以接收非压缩的消息。
它必须能根据每个压缩消息的最开始位来执行完成不同的功能。

2.  操作概述
SIP中有两种不同的SIP消息，SIP请求和SIP应答。客户端向特定URI的主机端发送SIP请求，然后
服务器通过VIA头域的sent-by参数向主机发送应答。

我们定义两个参数，一个参数是SIP URI的，另一个参数是Via头域的。两个参数的格式相同，如
下例：
sip:alice@atlanta.com;comp=sigcomp
Via: SIP/2.0/UDP server1.foo.com:5060;branch=z9hG4bK87a7;comp=sigcomp

SIP URI中comp=sigcomp表示这个消息请求必须使用SigComp进行压缩，具体压缩见RFC3320。在Via
头域中则要求对这个SIP请求的应答必须使用SigComp压缩。

因此，参数comp=sigcomp表示URI或Via头域标识的SIP实体支持SigComp压缩并且希望接收到压缩的
SIP消息。这个参数表示SIP实体“愿意”接收SIP压缩，支持SIP压缩，这就使SIP消息的接收者在
特定时刻可以选择是否使用SigComp压缩SIP消息。

3.  SIP信令压缩的实现
每个支持SigComp的SIP消息的实现都必须使用本文描述的过程。
4.  发送请求到服务器
一个请求被发送至某个特定URI主机端。这个URI，也就是下一跳URI，可以是SIP请求的Request-URI，
也可以是Route消息头中的一个入口。

如果下一跳URI中包含参数comp=sigcomp，客户端需要适用SigComp对这个SIP请求进行压缩。

如果下一跳URI是SIPS URI，SIP请求将在其被传送到TLS层之前被压缩。

在不知道服务器是否支持SigComp的情况下，客户端不能向服务器发送压缩的SIP请求。

无论要发送的请求是否被压缩，如果客户端想要在同一对话的后续请求中接收压缩的请求，在SIP请
求的Contact头域中的URI必须添加comp=sigcomp参数，如果客户端是用户代理客户端；如果客户端
是代理客户端，则在Record-Route头域中的URI必须添加comp=sigcomp参数。

如果一个用户代理客户端要发送压缩的SIP请求，在Contact头域中用户代理客户段的URI要添加comp=sigcomp参数；如过代理客户段要发送压缩的SIP请求，在Record-Route头域中

代理客户端的
URI必须包含comp=sigcomp参数。

如果一个客户端发送了压缩的请求，它必须在Via头域的顶级入口URI中添加comp=sigcomp参数。

如果客户端不知道服务器是否支持SigComp，但是为了能在服务器支持SigComp的情况下接收到压缩
的SIP应答，客户端可以在Via头域的顶级入口添加comp=sigcomp参数，对于该SIP请求，如上述所说，
则不能被压缩。

4.1  获取具有comp=sigcomp参数的SIP/SIPS URI
对于在同一个对话中的所有请求，一旦对话被建立，具有comp=sigcomp参数的下一跳URI可以从
Record-Route头域获得。在对话外发送请求的客户端可以在针对该请求的3xx或485应答的Contact头
域获取具有comp=sigcomp的SIP URI。

然而，会话建立客户端一般不愿意等待直到会话建立后才开始压缩消息。SigComp给SIP最大的好处在于，
在等待对话建立的过程中，SigComp能够对对话中初始的INVITE请求进行压缩。因此，在用户决定建立
会话前，客户端需要一个能够从外部代理获取comp=sigcomp URI的途径。

一种解决方法是手工配置。然而，有时客户端的自动配置也是必要的。当前SIP的配置机制不能将URI
参数提供给客户端。在这种情况下，客户端将发送一个未压缩的OPTIONS请求到外部边缘代理。外部
边缘代理能够在回复的200消息的Contact头域中提供一个可选的具有comp=sigcomp参数的SIP URI。在
后续的发送至同一个代理的请求中，客户端可以在这个URI中添加comp=sigcomp参数，同时压缩要发送的
请求。

RFC3261没有定义代理如何应答发送至自身的OPTIONS请求，只是定义了服务器对OPTIONS的应答。

RFC3261的11.2节这样说明：
Contact头域可以出现在200响应中，并且与在3xx响应中的语义相同。也就是说，它们列出了可到达用户
的一系列可选名字和途径。

我们把Contact扩展到代理服务器对到达自身的OPTIONS请求的响应上。它们可以列出该代理的一组可用URI。

注意，收到压缩的请求并不会出现任何问题，用户代理可以注册一个带有comp=sigcomp参数的SIP URI。
所有对用户的请求将以压缩的方式直接发送至相应的SIP URI。

5.  发送响应到客户端
SIP响应会根据Via头域的sent-by参数发送到相应的主机。如果Via头域的顶级URI包含comp=sigcomp参数，
则回复的响应需要被压缩。否则，不能压缩。

为了避免不对称压缩（例如，两个SIP实体在一个方向使用压缩的请求而在相反方向不压缩）代理须要重写
响应中的Record-Route路径。负责Record-Route的代理要检查响应中的Record-Route头域和触发该响应
的SIP请求的Contact头域（见第9节例子）。它在路径设置中寻找下一个上行节点的URI（向用户代理客户
端方向），如果包含comp=sigcomp参数，代理将在Record-Route头域的入口URI添加comp=sigcomp。否则，
代理将删除（如果有的话）Record-Route头域的入口URI的comp=sigcomp参数。

同样，如果下一个上行节点的URI包含comp=sigcomp参数，用户代理服务器也将在应答的Contact头域添加
comp=sigcomp参数。

6.  双重Record-Routing
尽管一般情况下代理对某个特定请求添加0个或1个路由入口，有些代理却添加两个路由入口以防止路经重
写。双重路经的一个典型例子就是扮演两个网络之间防火墙的SIP代理。根据请求来自不同的网络，请求将
通过这个代理在不同的界面被接收。代理为每一个界面添加一个Record-Route头域。这样，代理在应答中就
不须要再重写Record-Route头域。

在一个方向上要接收压缩的SIP消息、在另一个方向接收未压缩得消息的代理可以使用上述双重Record-Route
的机制。

如果代理检测到一个请求的下一跳代理是它本身，并且该请求不会穿越网络，代理可以选择不压缩该消息请求
尽管URI包含comp=sigcomp参数。

7.  错误处理
如果一个压缩的SIP请求到达了一个不支持sigcomp的服务器，服务器将无法向客户端通知错误。此时，服务器
不能解析该消息，因此也就无法获取Via头来向客户端发送错误响应。

如果客户端发送了一个压缩的SIP请求，并且因为没有收到任何应答而超时，客户端应该尝试发送未压缩的同
一消息请求。如果压缩的请求使用的是TCP连接，客户端应该关闭该连接，同时打开一个新的连接来发送未压缩
的消息请求。

8.  扩展的BNF
本节提供上述的两个参数的BNF。

压缩URI参数是"uri-parameter"，格式为：
compression-param  =  "comp=" ("sigcomp" / other-compression)
other-compression  =  token

Via压缩参数是"via-extension"，格式为：
via-compression    =  "comp" EQUAL ("sigcomp" / other-compression)
other-compression  =  token

9.  实例
下面的例子阐述了上述定义的参数的使用。图1的呼叫流为一个UAC与UAS之间INVITE-200 OK-ACK握手的过程。
代理P1并不实现参与路由，P2参与。两个代理都支持压缩，但默认情况下都不使用SIP压缩。

   UAC            P1                     P2                    UAS
    |(1)INVITE(c) |                      |                        |
    |------------>     | (2) INVITE   |                        |
    |                       |------------>     | (3) INVITE    |
    |                       |                       |------------>     |
    |                       |                       | (4) 200 OK   |
    |                       | (5) 200 OK  |<------------      |
    |(6)200 OK(c) |<------------   |                         |
    |      <------------|                      |                         |
    |                        |  (7)ACK(c)   |                        |
    |-------------------------->           |   (8) ACK       |
    |                        |                       |------------>      |
    |                        |                       |                        |
    |                        |                       |                        |
             图1 通过两个代理的INVITE事务流
其中消息（1）（6）（7）被压缩。

我们仅给出图1中涉及到的消息的部分描述。每个消息仅给出了几部分，包括方法名，Request-URI，Via，
Record-Route和Contact。对这些消息头，我们仅给出跟"comp=sigcomp"参数有关的部分，其余省略。

(1) INVITE UAS
    Via: UAC;comp=sigcomp
    Route: P1;comp=sigcomp
    Contact: UAC;comp=sigcomp

P1为UAC的外部边缘代理，支持SigComp。UAC发送压缩的消息流到P1，也就是UAC压缩INVITE(1)。另外，UAC
希望在这个对话中接收到压缩的请求或响应，因此，INVITE的Via和Contact头域都添加了comp=sigcomp参数。

(2) INVITE UAS
    Via: P1
    Via: UAC;comp=sigcomp
    Route: P2
    Contact: UAC;comp=sigcomp

P1将INVITE请求INVITE (2)送至下一跳P2。P1默认情况下不使用压缩，因此，P1将INVITE (2)不压缩发送至P2。

(3) INVITE UAS
    Via: P2
    Via: P1
    Via: UAC;comp=sigcomp
    Record-Route: P2
    Contact: UAC;comp=sigcomp

P1将INVITE请求INVITE (3)送至下一跳UAS。P2也支持压缩，但默认情况下不使用压缩，因此，P2发送未压缩的
INVITE请求。同时，由于P2要留在信令路径，因此将自己加入Record-Route。

(4) 200 OK
    Via: P2
    Via: P1
    Via: UAC;comp=sigcomp
    Record-Route: P2
    Contact: UAS

UAS产生200 OK响应并发送至顶级Via结点，即P2。

(5) 200 OK
    Via: P1
    Via: UAC;comp=sigcomp
    Record-Route: P2;comp=sigcomp
    Contact: UAS

P2接收到200 OK响应。P2检查该对话的路径设置。由于P1不提供路由功能，对于从UAS到UAC的请求，下一跳将直接
到INVITE的Contact头域URI。

另一方面，由于UAC希望接收到压缩的SIP请求，P2假设UAC同时想要发送压缩的SIP请求，因此设置Record-Route
包含comp=sigcomp。这样就允许了UAC在该对话中发送压缩的请求。

(6) 200 OK
    Via: UAC;comp=sigcomp
    Record-Route: P2;comp=sigcomp
    Contact: UAS

由于Via头域包含comp=sigcomp参数，P1发送压缩的200 OK (6)到UAC。

(7) ACK UAS
    Via: UAC;comp=sigcomp
    Route: P2;comp=sigcomp
    Contact: UAC;comp=sigcomp

由于P1不提供路由功能，UAC直接发送压缩的ACK(7)到P2。

(8) ACK UAS
    Via: P2
    Via: UAC;comp=sigcomp
    Contact: UAC;comp=sigcomp

P2发送未压缩ACK(8)到UAS。

10.  安全考虑
SIP实体接收到压缩的SIP消息后必须进行解压缩，然后才能进一步解析消息。这需要比单纯的解析消息更强的处理
能力。这也暗示使用压缩的消息发动拒绝服务攻击将会比使用未压缩消息严重的多。

攻击者在SIP消息中插入comp=sigcomp参数，将使压缩的SIP消息发送至不支持SigComp的SIP实体。合适的完整性机
制可以避免这样的攻击。