sip协议详解_SIP拓展协议RFC3262概述和100rel/PRACK详解

随着基于SIP协议应用场景的增加，目前企业融合通信和语音呼叫中几乎绝大部分的场景中都使用了SIP协议。但是，和传统的PSTN相比，因为一些其他因素的影响，很多人对于基于SIP协议所提供的终端，接入设备和软交换仍然缺乏信心。客户可能仍然对SIP呼叫中出现的问题有着非常大的担心。这些担心也是正常的。事实上，为了进一步提升SIP呼叫的稳定性，SIP协议本身针对传输响应处理方面也做了一些拓展，使用这些拓展用来进一步保证SIP协议传输响应的稳定性。另外，为了保证更新的网络(IMS)正常工作以及和传统PSTN的兼容性，在SIP拓展中，使用了100rel/PRACK的拓展功能，可选标签100rel是SIP响应消息中一个比较常用的拓展功能，这个拓展是通过PRACK method来进行定义的。关于100rel拓展的定义，SIP拓展协议专门针对其属性做了规范说明，此说明在RFC3262中定义。今天，我们针对RFC3262结合相关SIP拓展的相关技术话题做一个完整概述，并且针对实际业务场景中的一些问题进行讨论，希望对读者有所帮助。

1

背景介绍

如果熟悉SIP响应的读者都一定知道，请求和响应是信令协商的基本手段。在RFC3261中规定了响应的定义，响应主要分为最终响应和临时响应。根据其概念名称，读者也大致理解了最终响应和临时响应的基本含义。简单来说，最终响应是可靠的，而临时响应是临时的，不可靠的响应。根据RFC3261-7.2的说明，其定义是：

1xx: Provisional -- request received, continuing to process the request;

https://tools.ietf.org/html/rfc3261#section-7.2

在针对临时响应的定义中，读者可以非常明确地知道，对端已经收到请求，对端正在处理其请求。以下示例说明了启用PRACK的和使用最终响应处理的呼叫：

在当前的呼叫环境中，包括现代的IMS网络中，呼叫需要经过多个网络环境和处理路径，需要更多的协商和资源支持。因此，在实际呼叫流程中可能发生更多的问题，对端需要耗费一定的时间来处理请求，具体需要处理的内容很多，包括：编码协商，对端服务器资源不足，会话时间太长，编码能力匹配问题，QoS，承载服务，和PSTN接续时间太长都会导致响应丢失的问题。因此，为了保证对端有充足的时间处理请求，UAS先返回一个临时响应通知对端本地正在处理这个请求，现在仅发一个临时性的响应。

2

UAS工作方式说明

根据RFC3262的说明，只要初始的请求包含了一个Supported，它的可选项是100rel，UAS可以对INVITE发送任何非100的响应。这里的初始请求的响应是一个临时的可靠性响应。此规范除了支持INVITE以外，不支持其他的可靠性临时响应的method。如果初始请求包含了Require头域，其包含了100rel可选项的话，UAS必须发送一个非100临时可靠响应。如果UAS不愿意那样处理的话，它必须拒绝此初始请求，返回一个420响应(Bad Extension)，并且在响应消息中包含一个Unsupported 头域，可选项是100rel。具体示例，参考后续介绍。

根据RFC3262说明，UAS一定不能通过100(Trying)发送可靠的响应。UAS只能通过101到109中间的响应码发送临时可靠响应。如果请求中既不包含Supported 头域也不包含Require头来表示临时可靠响应功能的话，UAS一定不能发送临时可靠响应。

100(Trying)响应只能支持hop-by-hop之间的响应。因为此原因，这里讨论的可靠性机制是介于end-to-end的响应，因此不能使用100(Trying)。这里，关于end-to-end 和hop-by-hop的使用方式，读者一定要小心理解，因为各种method涉及了代理之间的通信和用户身份安全的问题。例如，BYE method是end-to-end之间的处理，而CANCEL是hop-by-hop的请求处理。

在一些场景中，一个网络要素可以当作proxy来使用，此proxy也可以可靠临时响应。其工作方式类似于一个UAS，它的作用就是作为一个事务功能。但是，它不能尝试发送携带To头标签的请求。这里，一个proxy不能对已经在一个dialog内容中发送过的请求生成可靠临时响应。简单来说，就是已在一个dialog中发送过请求内容的，就不能对其请求生成临时可靠响应。当然，不像UAS一样，当proxy的一个网络要素收到一个PRACK时