浅析SIP响应消息100 Trying的作用和传输机制

　　SIP协议是目前语音呼叫中最重要的协议之一。所以，在SIP呼叫中我们会看到呼叫流程中多个处理流程的交互。在呼叫请求中，系统技术人员在使用排查根据排查问题时会看到一个服务器端（UAS）响应的消息-100 Trying。大部分VOIP系统用户和技术人员可能没有注意或者忽略了它的作用，也没有真正深究它背后的其他相关要素。如果系统出现了呼叫故障的问题时，一些技术人员也仅仅停留在表面的故障问题，根据非常表面的表象来排查问题，没有从根本上来了解其真正的作用。事实上，100 Trying是请求响应处理中非常重要的核心步骤，它决定了呼叫可靠性传输的结果。那么，很多用户就会问，100 Trying到底在try什么？如果要回答这个问题，我们必须从最底层的OSI网络七层说起，一直到SIP传输定时器来解释100 Trying所扮演的角色和其作用。

　　笔者通过以下各个部分来浅析100 Trying所扮演的角色，作用和相关技术节点处理方式。我们将讨论 100 Trying的背景知识，OSI网络协议的相关话题，TCP/UDP对SIP传输的处理方式，SIP定时器对可靠性的支持机制，SIP 重传和定时器处理流程，以及优化方式讨论，发生SIP重传的几种原因等相关话题进行一个比较初浅的讨论。

　　1、SIP呼叫请求响应中的100 Trying

　　首先，我们针对请求呼叫中的100 Trying做一个简单的背景介绍。在SIP呼叫中，下一跳服务器或UAS收到UAC的请求以后，对客户端UAC发送一个100 Trying，表示对端已经收到请求，正在进行下一步的处理（具体处理什么流程，完全取决于UAS本身）。在RFC3261中有对100 Trying如下定义：

This response indicates that the request has been received by the
next-hop server and that some unspecified action is being taken on
behalf of this call （for example, a database is being consulted）.
This response, like all other provisional responses, stops
retransmissions of an INVITE by a UAC. The 100 （Trying） response is
different from other provisional responses, in that it is never
forwarded upstream by a stateful proxy.

　　具体的SIP呼叫流程图如下：

　　比较详细的100 Trying响应消息如下。这里提醒一下一些基础读者，100 Trying会完全拷贝INVITE中的Call-ID，From，To，CSeg，和VIA头值，这里没有SDP内容长度，因此也没有SDP消息。

　　在RFC3261中，1XX响应消息是Provisional response（临时响应），在上面的100 Trying也说明，UAS回复UAC，UAS正在处理收到的请求，仅返回一个临时响应消息，通知UAC而已，没有说明任何状态。当然，在临时响应消息中，也包括了180，181和183等其他的响应消息。临时响应消息具有以下几个方面的特征：

报告一个处理流程
以1XX为响应回复
无任何结果状态

　　2、网络七层协议OSI

　　基于网络协议的技术讨论都离不开关于OSI模型的讨论。在SIP语音呼叫中，协议协商也同样需要讨论这些问题。

　　对应OSI网络模型的结构，具体到SIP应用环境中，我们可以看到以下网络结构。

　　关于那个网络层的介绍，我们在以前的历史文章中有非常完整的介绍，读者可以查阅历史文档来学习，也可以通过网上的其他资料来学习，这里不做过多解读。现在，我们仅对涉及SIP传输的transport layer 所使用的TCP和UDP进行简单分析来说明如何支持SIP的可靠性传输。使用TCP传输时，SIP通过TCP需要和对方检查，进行握手协商。如果对方确认已经准备好接收数据，那么发送方发送INVITE消息，对端成功接收。如果TCP确认后，接收方在接收过程中没有收到完整的数据，则丢弃，重新传输一次。因此，TCP协议就是人们常说的可靠传输协议，因为它可以保证传输的可靠性，因为需要完整的协商过程，数据丢失需要重新传输，因此可靠性增加，但是和UDP相比，其传输速度相对比较慢。

　　下面，我们再来介绍一下使用UDP传输SIP消息的流程。UDP传输数据时，它本身不会对双方的状态进行检查，直接对对端发送数据。数据丢失也不支持任何重传机制，因此，UDP是一种非可靠传输协议。但是，UDP传输速度相比TCP就会快很多，没有协商时间产生的消耗。既然UDP是不可靠的传输协议，那么，为什么SIP仍然使用UDP作为默认的传输协议？如果不能保证其数据传输的可靠性，SIP怎么保证数据传输的可靠性？事实上，SIP通过定时器的方式来实现可靠性传输机制。接下来，我们将讨论使用定时器来保证SIP传输的可靠性。

　　3、关于SIP呼叫请求中的定时器

　　在SIP协议中，为了保证可靠性传输，SIP支持了三种机制实现可靠性传输，它们包括：重转定时器，递增的CSeq和ACK确认。因为篇幅的关系，我们今天仅讨论定时器的机制，其他两种机制读者可以自己学习。事实上，在定时器机制中，SIP就使用了100 Trying了实现可靠性传输。如果没有100 Trying，双方的协商没有办法继续进行。当然，其他的响应也可以对请求做出一个确认，但是100 Trying是一个非常合理简单的办法对初始时确认进行处理的方式。

　　让我们根据以上图例来了解一下定时器的处理机制。这里，我们假设了3次重复发生INVITE消息，途中可能遇到的两种基本的故障。首先，当UAC对UAS发送INVITE消息时，定时器1同时启动，并且定时器开始计时。如果第一个INVITE请求在定时器1参数设置时间内超时，INVITE请求在中途丢失，说明可能出现了其他问题。接下来，UAC端则马上启动第二个定时器，并且进行超时设置，第二次发送的INVITE抵达UAS服务器端后，UAS马上返回一个100 Trying 临时响应消息，通知UAS收到了INVITE请求，正在进行下一步处理。但是，因为各种网络原因，可能UAS发送的100 Trying在定时器2超时设置的时间内没有返回到UAC端，100 Trying也可能在路径中丢失，UAC没有收到100 Trying。因此，在定时器2超时后，UAS马上又启动了第三个定时器，同时再次发送INVITE消息。这次UAS再次发送100 Trying，UAC也在超时设置范围内收到了100 Trying, 整个请求的可靠性传输成功处理。当然，在实际SIP交互过程中，INVITE请求不仅仅使用了三个定时器来处理可靠性测试，实际上，在INVITE的可靠性传输中使用了七次重传加定时器来控制整个传输过程。下面，我们具体介绍这七个定时器计时的处理流程。

　　4、SIP请求中的重新传输和定时器设置

　　上面，我们讨论了SIP发送INVITE和重传时的定时器和100 Trying的处理机制。实际上，因为各种网络问题，在传输过程中，INVITE丢失是经常发生的事情。因此，需要UAC不断发送INVITE，直到定时器超时。在INVITE传输过程中使用了七次重传来控制整个INVITE重传过程，其定时器共耗费总时长为32秒。这里需要注意的是，每次定时器计时时长是上一个定时器的2倍时长。在SIP 传输的定时器中，主要涉及了三个定时器：

Timer A	initially T1	17.1.1.2	INVITE request retransmission interval, for UDP only
Timer B	64*T1	17.1.1.2	INVITE transaction timeout timer

Timer E

initially T1

17.1.2.2

Non-INVITE request retransmission interval, UDP only

在以上的图例中，介绍了定时器T1和定时器B的关系。以下具体示例中各个INVITE传输所耗费的时长。

　　这里的定时器仅是针对INVITE请求来说的，其他非INVITE method可能需要更多的定时重传数量。例如，呼叫方首先发送Bye消息的传输则最多需要11次传输，也是共耗时32秒（定时器B）。这里读者一定要注意，前面4次传输的定时器时长是以2倍时长增加。从第五次开始，定时器是以4秒的方式递增，它们的计时方式是不一样的。

　　另外需要说明的是，在INVITE重传过程中，消息内容是一样的，任何头都没有发生改变，包括Call-ID， CSeq等。在流程介绍中，笔者没有针对专门的Timer做细节介绍，事实上，T1的处理在RFC3261中有明确的定义（17.1.1.1），T1的预估的RTT默认是500 ms。还有一种情况是涉及到定时器B。一些用户反映为什么系统总是在差不多30秒的时候就自动掉线。很多情况下，因为防火墙或NAT没有正确配置，定时器B在32秒执行了超时挂断。这里，笔者没有讨论RTT时延和相关原因的问题，事实上，RTT时延也会导致传输超时。读者可查阅其他关于RTT的文章。

　　5、Sip Retransmission原因和必要性

　　根据上面章节的介绍，在实际生产环境中，事实上，SIP重传是一个正常的处理流程。那么，为什么会发生重新传输的问题呢？因为网络环境中各种问题导致了重新传输。包括主要的几个原因：

网络原因，可能因为网络拥塞或者其他的数据路由问题导致数据丢失，所以需要重新传输。从呼叫方到被呼叫方的数据可能经过不同的网络和路由环境，导致数据丢失，定时器重新启动，出现重新传输。网络原因包括了很多方面的因素，例如，网络繁忙，路由器问题，带宽问题，硬件故障等问题。

　　网络防火墙过滤了呼叫请求。很多企业用户都设置了防火墙来保障企业内网的安全。如果防火墙没有过滤了SIP端口的话，呼叫方的INVITE会一直被过滤掉，呼叫方也可能一直对被呼叫方发送请求。

　　呼叫了错误的地址。呼叫方可能输入了错误的呼叫地址或者地址格式不支持，导致错误呼叫，因此SIP INVITE会不断重新发送。

　　错误的终端配置选项导致呼叫错误，重新重新传输的可能性。有时，终端配置错误的选项。例如，在配置选项中输入的是192.168.0.22 IP地址，事实上，终端的IP地址是192.168.0.23。

　　呼叫过程中，INVITE就会要求发送响应消息到192.168.0.22的地址，最后仍然是不可达的地址。因此，可能导致INVITE重新传输。

　　6、SIP传输定时器优化讨论

　　我们在前面的章节中，讨论了SIP传输协议使用时带来的问题和定时器的关系等问题讨论。在最后的讨论中，我们针对SIP传输过程中比较重点的问题-SIP定时器做一些说明。根据很多研究机构和学术机构发布的研究论文中，很多研究更多专注于定时器的算法的优化。

　　根据笔者前面介绍的，T1定时器默认设置为500ms是相对比较可靠的设置，B 定时器设置为32ms是符合一般网络环境的。但是，如果设置T1时间相对较小，或者B定时器相对较小的话，整个SIP服务器端或者IPPBX本身对SIP transaction的时间要求就会比较少，对系统内存资源的压力就会减少很多。例如，在关于Asterisk的系统优化解决方案中，官方建议设置B定时器的设置为6400 ms。

　　在网络重传过程中，传输过程中也可能出现很多问题，导致传输的质量问题。几个影响传输的因素包括：网络时延，传输数据损坏，传输数据丢失等问题。为了保障传输的可靠性，研究人员对定时器T1做了算法优化，实现灵活自适应的调整方式。以下是关于使用可调整T1定时器的一些测试数据和SST（Session Start-up Time）之间的关系：

　　吞吐量和可调整定时器T1/默认定时器之间的优化关系测试数据：

　　以上的研究讨论了很多关于一般的IP网络，基本上没有讨论目前最新的无线网络，例如IMS，3G/4G网络部署中。在Hanane Fathi的关于3G研究论文中，作者对在3G无线网络中SIP创建的时延优化做了多种比较测试，使用了TCP/UDP传输方式，对T1定时器的灵活调整，通过SIP/H323协议测试对比，作者的论文结论也说明使用定时器的方式确实提高了传输效率：

Therefore, the adaptive timer is efficient for optimizing
the performance of signaling protocols in general. The
performance of SIP using the adaptive timer could be
improved by using some compression schemes to reduce the
size of the SIP messages.

　　另外，Hanane Fathi也建议使用SIP消息的纠错机制或混合型的ARQ模型来修正SIP消息，提升SIP消息创建的效率，尽量避免SIP消息在无线网络环境中重新发送：

Also, error correction mechanisms or hybrid ARQ
schemes could improve the performance of VoIP session
setup time by correcting the SIP messages and avoiding
retransmissions on the wireless link.

　　Hanane Fathi发表的论文比较早一些，现在很多新的基于互联网，云计算的技术也进入了商业环境中。所以，云计算为SIP消息传输优化提供了更多的方式，因为基于云计算的部署方式可以支持更大的灵活性和网络的弹性，使得传输效率更高。

　　思科在很多产品中支持了Reliable User Data Protocol （RUDP），通过RUDP来保证传输的可靠性。RUDP中也使用了 Forward error correction（FEC）这样的纠错机制来修正SIP消息，提升传输的效率。这里的FEC的机制基本上和Hanane Fathi的论文讨论的纠正机制非常相似。关于RUDP的细节，读者可以查阅ABHILASH THAMMADI的论文。以下是一个RUDP的架构介绍示例：

　　7、总结

　　在本文章的讨论中，笔者介绍了关于100 Trying在SIP传输过程中的重要和其角色。首先，笔者介绍了SIP 初始请求中使用的100 Trying的状态，然后介绍了定时器控制机制来保证UDP传输时100 Trying的协商机制。接下来，笔者介绍了SIP 重传中的定时器和超时的设置和其工作流程，然后介绍了为什么进行SIP消息的重新传输，以及几个主要的原因。最后，笔者讨论了关于SIP传输中优化的建议，特别是对T1定时器的灵活调整带来的效率的提升，RUDP技术架构的介绍。

　　总结，通过在SIP 请求中使用100 Trying，然后T1定时器和B定时器可以保证UDP传输环境下的可靠性传输，100 Trying起到了非常重要的作用。在具体的定时器细节方面，很多研究表明通过优化定时器也可以提升传输效率。当然，目前很多基于云计算的技术也非常成熟，这些技术也可以实现网络的优化，读者本身资源的局限性没有对很多新的技术进行分析讨论，读者可以进行进一步的消息补充这方面的知识。

　　参考资料：

　　https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions

　　Sureshkumar V，Measuring SIP Proxy Server Performance

　　S. M. Chakraborty，Optimization of SIP Session Setup Delay for VoIP in 3G Wireless Networks

　　ABHILASH THAMMADI，https://krex.k-state.edu/dspace/bitstream/handle/2097/11984/AbhilashThammadi2011.pdf?sequence=5

　　http://www.cs.rochester.edu/~kshen/csc257-fall2007/lectures/lecture11-rdt.pdf

　　file:///D:/Documents/Downloads/electronics-07-00295.pdf

　　https://www.sciencedirect.com/science/article/pii/S0022000010001194

　　https://www.smartvox.com/what-are-sip-timers/

　　https://link.springer.com/content/pdf/10.1007%2F978-3-642-40552-5_8.pdf

　　https://blogs.asterisk.org/2016/12/21/sip-timers-t1-and-b-affect-performance/

　　https://tools.ietf.org/id/draft-ietf-sipping-early-disposition-03.txt