运行于 UDP 之上的 SIP，因为 UDP 是不可靠传输的，所以 SIP 协议本身要自己实现可靠传输。对于如何可靠传输，SIP 的 RFC 文档没有要求实现独立的传输层，而是将可靠传输融合进交互过程本身。如果像 TCP/IP 协议那样分层，特点是清晰。而将可靠传输隐含于交互，则可控程度更高，当然也更复杂。
所以，RFC 中创造了一些概念，如 Transaction 等等，对于有经验的程序员来说，这完全没必要，反而造成困扰。对于程序员，用几句简单的过程描述就可以解决。如下。
Client: 定期重复发送 INVITE 直到收到响应。
Server：收到 INVITE 后，定期重复发送响应，直到收到 ACK。
Client：收到响应后回复 ACK，认为会话已经建立。这时如果再次收到响应，回复一个 ACK。
Server：收到 ACK，认为会话已经建立。这时如果再次收到 INVITE 或者 ACK，丢弃。
里面有两个“定期发送”，其实就是超时重传的意思。当然，超时重传有最终次数限制。
程序员看到上面的话，实现起来就简单了。不太明白 RFC 为什么要用 Trasaction 那样奇怪的方式来描述，可能和那个时期或者某个公司的编程习惯有关，作者可能是基于自己的某个代码实现来描述。其他人实现时，未必需要 Transaction 这种东西。
关于可靠传输，我已经在另一篇博客文章（http://www.ideawu.net/blog/archives/782.html ）中介绍了，就是确认，重传，排序(序号)。SIP 把确认隐含于交互过程，例如响应是对 INVITE 的确认，ACK 是对响应的确认。在不同的状态接受不同类型的报文，以及会话建立之后对非期望报文的丢弃就属于排序(序号)。SIP 本身也有序号，并不是单纯的报文排序之用。
Loading ...