广播系统之SIP入门

SIP,全称Seesion Initiation Protocol(会话发起协议),是由IETF制定的一个多媒体通信协议。

它是一个基于文本的应用层控制协议,用于创建、修改和释放一个或多个参与者的会话。

如果把一个多媒体会话分成信令和媒体两部分,那么SIP则处于信令的位置。

SIP协议族由其本体及其扩展组成。其中有不少都经过了版本的更替。

以下内容参考选用的是SIP协议族的现行标准(如SIP本体选用的是RFC3261而不是RFC2543),扩展部分则只选用了部分比较常见的来进行介绍。

SIP协议框架

SIP 可以分为四层,分别为协议层、传输层、事务层和事务用户层。

  • 协议层(Protocol):SIP 协议的基础,规定了 SIP 的语法和编码。
  • 传输层(Transport):这个我们就比较容易顾名思义了,是传输 SIP 消息用的。
  • 事务层(Transaction):一次请求以及其相关回复组成一个事务。
  • 事务用户(Transaction User,简称 TU):协议层面上在事务层之上,UA 核心和代理的核心都属于 TU(见下文「SIP 角色」一节)。

SIP消息

SIP 协议是基于文本的,采用请求-响应式。

SIP 的请求和回复统称为 SIP 消息。

内容有请求方法行、请求头、请求体,响应状态行、响应头、响应体,总之和 HTTP 很像就是了。

基本的请求方法有 OPTIONS、REGISTER、INVITE、ACK、CANCEL、BYE。

值得注意的是,虽然 SIP 是类似于 HTTP 的一种文本传输协议,但是 SIP 中的回复有两类:

  • 临时回复 – 在最终回复前发的回复,和一些中间状态有关
  •  最终回复 – 结束一个请求

一个请求在得到最终回复前是可能会有多个临时回复的(下面会有例子说明)。

传输层

SIP  可以运行在多种转输协议之上,如 UDP、TCP、SCTP 等。

SIP事务模型

SIP 也可以说是一种事务性的协议,一个 SIP 事务由一个请求以及其相关回复组成。

根据处理事务的角色,事务可分为两种:

  • 客户端事务 – 请求方
  •  服务端事务 – 回复方

根据请求的方法,事务也可以分两种:

  • INVITE 事务
  • 非 INVITE 事务

注:因为 INVITE 比较特殊,所以 INVITE 有特殊的事务模型。

标准中对于各种细分的事务都给出了状态机,这里不详细展开。

SIP角色

在逻辑上,SIP有几类角色。

 注册商(Registrar) 接收REGISTER 请求,维护一个目录服务
 终端(UA) 发起和回应请求的角色,可再细分为:UAC请求发起方UAS请求回复方
 代理(Proxy server) 转发消息,可分为两类:有状态代理无状态(仅转发)代理
 重定向服务器(Redirect server) 不转发任何消息,重定向所有请求(CANCEL 除外)到别的地方

这些角色分类只是逻辑上的。物理上,注册商和各类服务器常常是一起的。参与到事务中的服务器也一样是UA。

注册

REGISTER方法,向注册商注册自己的一个或多个别名,以便其他人可以使用这些别名进行沟通。

图片
典型的注册流程示意图

图中的 Register、Location Service、Proxy 它们都是逻辑上的划分,实际上,它们基本都是由一个东西担任,就是被我们称之为 SIP 服务器的东西。

能力查询

OPTIONS 方法,查询对方支持哪些方法,和 HTTP 中的类似。

发起会话

NVITE 方法,发起会话。

近似来讲,就是一个打电话的过程。

和发起会话相关的有这几个请求:

  • 拨号 INVITE – 发起会话
  • 取消 CANCEL – 取消建立中的会话
  • 改变 re-INVITE – 改变参数
  • 再见 BYE – 结果已建立的会话

在发起会话的过程中一般都会包含一个媒体传输协商的过程(详见 RFC3264 Offer/Answer Model),它是借助 INVITE 请求和其回复完成的。

需要注意的是 re-INVITE 请求,实质上它也是一个 INVITE 请求,是在已经建议的会话中再次发起 INVITE 请求的这一个过程,它的用处是改变会话的参数和流媒体的参数,不会直接影响到会话的状态。

例子:

图片

像这里的 1XX 类型的回复就是临时回复,一个事务中,可以有多个临时回复。

代理

中转 SIP 消息,一方面,可以使用别名与其他设备沟通,另一方面,用来跨越逻辑区域。

代理分为有状态和无状态两种。

无状态代理

服务器只工作在传输层,只负责转发消息,对事务层不会产生影响。

有状态代理

代理服务器参与了事务层,对于一个 SIP 请求中的请求方,服务器是 UAS,而对于响应方,服务器是 UAC。

代理服务器对转发一个请求的时候,可以转发给多个目标,SIP 中称为 forking。

典型的示意图如下:

图片

P.S:SIP 的流程上和真实的打电话场景十分拟合。呼叫中、对方已振铃这些状态,和 SIP 发起会话的过程有着惊人的对应关系。

INFO方法

SIP 扩展,用以在会话中来发送不影响会话状态的信息。

RFC2976 定义了十分简单的 INFO 方法,RFC6086 重新定义了 INFO 方法,兼容 RFC2976,并给其增加了一个 Info Package 机制,以便通信双方能知道对方可以接收什么样的信息。

INFO 方法只能在会话中使用。

事件模型

SIP 扩展,提供了一个发布/订阅事件的框架。

事件只能在会话中使用。

基本模型如下:

图片

即时消息模型

SIP 扩展,通过 MESSAGE 方法来传递即时消息。

特点是,消息可以在会话中,也可以在会话外,每个消息之间是独立的。

SIP的部署方式

在开始学习 SIP 之前,SIP 给我的印象是我一定要有一个服务器才可以运行 SIP,实则不尽然。

由上面角色的介绍可以看出来,服务器可以完成注册、代理、转发、重定向这些功能。

要发起一个 SIP 会话,这些都不是必须的。理论上,两个终端可以在没有任何服务器参与的情况下直接建立会话。

当然,SIP 服务器也有它的应用场景,在实际的部署中,没有服务器反倒是用处不大。

总结各类 SIP 服务器在部署上的特点如下:

图片

最后,服务器的部署也不是只能选择一种,多种服务器同处一个系统也是很实用的部署方式。

以上,本文旨在介绍 SIP 中的一些概念和基本流程,没有过多涉及到 SIP 协议消息中的细节。

参考

  • RFC3261 – SIP: Session Initiation Protocol
  • RFC3263 – Session Initiation Protocol (SIP): Locating SIP Servers
  • RFC3264 – An Offer/Answer Model with the Session Description Protocol
  • RFC3265 – Session Initiation Protocol (SIP)-Specific Event Notification
  • RFC3428 – Session Initiation Protocol (SIP) Extension for Instant Messaging
  • RFC6086 – Session Initiation Protocol (SIP) INFO Method and Package Framework

作者:小渊 来源:公众号——好奇de悟空

版权声明:本文内容转自互联网,本文观点仅代表作者本人。本站仅提供信息存储空间服务,所有权归原作者所有。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至1393616908@qq.com 举报,一经查实,本站将立刻删除。

(0)

相关推荐

发表回复

登录后才能评论