2017-06-19

SIP INVITE 会话建立过程

Views: 2118 | Add Comments

运行于 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 本身也有序号,并不是单纯的报文排序之用。

Related posts:

  1. SIP tag 和 Call-ID 的区别
  2. Nginx 安装 HTTPS SSL 证书
  3. 使用dbproxy来处理高并发数据库请求
  4. SSH ProxyCommand及其思想
  5. lighttpd配置HTTPS(SSL)
Posted by ideawu at 2017-06-19 19:05:35 Tags: ,

Leave a Comment