GB28181/SIP/SDP 协议简介（下）

3.SIP协议

SIP（Session initialization Protocol， 会话初始协议 ）是由IETF（Internet Engineering Task Force，因特网工程任务组）制定的多媒体通信协议。

它是一个基于文本的应用层控制协议，用于创建、修改和释放一个或多个参与者的会话。SIP 是一种源于互联网的IP 语音会话控制协议，具有灵活、易于实现、便于扩展等特点。SIP（Session Initiation Protocol）是一种类似于http协议的纯文本应用层协议。SIP可以用来控制会话的建立、取消、关闭等操作。主要可以实现以下功能：

• 用户定位： 检查终端用户的位置，用于通信；
• 用户有效性： 检查用户参与会话的意愿程度；
• 用户能力： 检查媒体和媒体参数；
• 建立会话： “振铃”，在呼叫和被叫方同时建立会话的参数；
• 会话管理： 包括会话的传输和终止，修改会话参数以及请求服务

目前相关设备供应商和业务供应商联合成立了一个关于SIP的william hill官网 ：http://www.sipforum.org，为SIP的发展提供一个自由讨论、展现新思维的发展平台

3.1 概念讲述

3.1.1 SIP request

请求是SIP中一个最基本的概念之一，每一次关于SIP的操作都需要发送请求。

3.1.2 SIP response

回复和请求在SIP中一般都是成对出现，回复中的内容是对端关于请求的处理结果。

3.1.3 Transaction

SIP协议是一种事务型协议。transaction的概念建立在请求和回复之上，一个请求和相关的最终回复就组成了一个transaction。（不包括关于ACK的处理）由于在一次通话建立到结束的过程中，会有多个Transaction，所以需要对Transaction进行唯一性标记，在SIP中对Transaction进行唯一标记的是branch参数

3.1.4 TU

在具备Transaction的概念之后，就出现了Transaction user的概念，Transaction架构在Transaction 上，能够对Transaction进行管理。

3.1.5 Client Transaction 和Server Transaction

有了Transaction的概念之后，针对请求和回复的不同就出现了client Transaction和server Transaction。CT指的是请求发起者所具有的Transaction的部分，ST是请求的接受者所具有的部分。

3.1.6 用户代理 UA（User Agent）

UA指的是一个用户实体。

3.1.7 UAC和UAS用户代理服务器端（User Agent Server）

实际发起请求的用户实体就是UAC，实际接收请求进行处理的用户实体就是UAS。

3.1.8 INVITE

特殊请求。SIP协议中最关键的请求。用于发起会话。

3.1.9 session

session，在收到对应的INVITE请求的2xx回复之后，完成建立。在下一次INVITE请求的2xx回复发送或者收到后进行修改，唯一一种结束方式为发送或者收到bye请求。

3.2.0 dialog

dialog的概念和session的概念类似，不同的是dialog是针对信令交互的一种概念，而session是对实际媒体发送和接收流程的描述。dialog的建立时间也是在接收到信令的200 OK回复之后，结束也是在发送或者接收到bye请求之后。

3.2 SIP的结构

在SIP协议中主要包含以下几种逻辑上的角色：UA、Proxy Server、 Register/Location Server、Redirect Server。

• UA： 用户代理（User Agent）类似于http协议中浏览器的角色，是用户操作的终端界面，用户代理需要符合SIP协议的要求，但是结合其他的协议根据不同的应用场景，会有不同的实现逻辑。比如，SIP协议结合H.323VoIP协议可以实现软件电话功能。用户代理分为UAC（UA Client）和UAS（UA Server）两种逻辑实体，UAC发送SIP Request并接受Response，UAS接收SIP Request并返回Response，一个物理设备既可以是UAC同时也可以是UAS。
• Proxy Server： 代理服务器的作用主要是转发Request和Response给其他的Proxy Server或者UA，Proxy Server分为有状态代理服务器（Stateful Proxy）和无状态代理服务器（Stateless Proxy），前者会保留一次通信事务的状态，通过一个有限状态机来控制转发操作，而后者不保存状态，只是实现透明的转发操作。
• Registration/Location Server： 注册和定位服务器用于登记和定位UA，在线的UA会定时的向Registration服务器发送SIP消息来表明UA当前的位置（如IP地址、端口号等），Registration服务器会将该信息存入数据库（或者散列表）中，当其他UA向该UA发送request时就能获得该UA的位置。
• Redirect Server： 用于重定向，在逻辑上相当于一个特殊功能的UA。

3.3 SIP方法

在SIP的REQUEST中，核心的方法（method）定义了6种：INVITE、ACK、BYE、CANCEL、OPTIONS和REGISTER。

• INVITE消息用于发起一个新的会话；
• ACK消息用于完成会话的建立；
• BYE消息用于结束一个会话；
• CANCEL消息用于取消一个请求（一般是针对INVITE）；
• OPTIONS消息用于查询服务器的能力；
• REGISTER消息用于发送注册请求消息。

SIP请求的类型，也称作SIP方法。RFC3261 中定义了六种方法。另外八种方法有独立的RFC扩展描述。如INFO、NOTIFY等等。

各方法含义可参考：SIP请求方法

也可移步SIP开发手册：链接: https://pan.baidu.com/s/1GFCHYqumPrd5ORhyCfJAew?pwd=yxj1 提取码: yxj1

3.4 SIP协议格式

SIP消息采用[ISO 10646]文本方式编码，分为两类：请求消息和响应消息。

请求消息：客户端为了激活按特定操作而发给服务器的SIP消息。

响应消息：用于对请求消息进行响应，指示呼叫的成功或失败状态。

每条SIP消息由以下三部分组成：起始行（ Start Line）/ 状态行（Status-Line），SIP头，消息体；请求消息和响应消息都包括SIP头字段和SIP消息字段。

起始行（ Start Line）/ 状态行（Status-Line）

每个SIP消息由起始行开始。起始行传达消息类型（在请求中是方法类型，在响应中是响应代码）与协议版本。起始行可以是一请求行（请求）或状态行（响应） 。

请求消息

请求消息整体格式如图：

其中：起始行格式：命令名称+目标URI+sip协议版本

请求消息包括以下几种请求命令：

响应消息

响应消息的起始行为状态行（Status-Line），状态行由协议版本、状态码和状态原因短语组成，各个部分之间用一个空格字符进行分隔。下面介绍其中的状态码。

SIP协议中共定义了6类状态码，其中状态码的第1位数字用于指示响应类型，后两位数字表示具体响应。下面用“1xx”标识状态码为“100-199”之间的响应。

• 1xx：临时响应，表示请求消息正在被处理；
• 2xx：成功响应，表示请求已被成功接收，完全理解并被接受；
• 3xx：重定向响应，表示需采取进一步以完成该请求；
• 4xx：客户机错误，表示请求消息中包含语法错误信息或服务器无法完成客户机请求；
• 5xx：服务器错误，表示服务器无法完成合法请求；
• 6xx：全局故障，表示任何服务器无法完成该请求；

响应消息整体格式如图：

其中：起始行格式：sip协议版本+响应返回码+描述性短句

响应消息是从100 - 699的返回码，分别表示不同的意义。

消息返回码可查看：SIP协议格式

SIP 头

SIP头域详情可查阅：https://blog.csdn.net/qui910/article/details/122683453

用来传递消息属性和修改消息意义。它们在语法和语义上与 HTTP 头域相同（实际上有些头就是借自 HTTP ），并且总是保持格式：<名字 >:<值>。

样例：

下表是描述的是SIP头格式中的各种Key值，可以大略分为4类：General通用头域，Request请求头域，Response响应头域，Entity实体域。

具体详细可参考：SIP协议-04 SIP头域

消息体

用于描述被初始的会话（例如，在多媒体会话中包括音频和视频编码类型，采样率等）。消息体能够显示在请求与响应中。

SIP 清晰区别了在 SIP 起始行和头中传递的信令信息与在 SIP范围之外的会话描述信息。可能的消息体类型就包括本文将要描述的SDP会话描述协议、还有基于xml的消息体。

4.SDP协议

SDP全称是Session Description Protocol，翻译过来就是 描述会话的协议 。主要用于两个会话实体之间的媒体协商。

SDP描述由许多文本行组成，文本行的格式为<类型>=<值>，表示为key=value;

SIP负责建立和释放会话，一般来说，会话中包含相关的媒体，比如视频和音频。媒体数据是由SDP描述的。SDP一般不单独使用，它与SIP配合使用时会放到SIP协议的body中。会话建立时，需要媒体协商，双方才能确定对方的媒体能力以及交换媒体的数据(这就是sdp的工作)。

那为什么要去发这个描述文本呢，主要是为了解决参与会话的各成员之间能力不对等的问题，如果参加本次通话的成员都支持高质量的通话，但是我们没有去进行协议，为了兼容性，使用的都是普通质量的通话格式，这样就很浪费资源了。所以SDP的作用还是很有必要的。

在SIP协议的包含的内容是SDP时，应该把Content-Type设置成application/sdp。SDP协议于RFC4566中发布。

样例：

4.1 SDP简介

SDP是会话描述协议的缩写，是描述流媒体初始化参数的格式，由IETF作为RFC 4566颁布。流媒体是指在传输过程中看到或听到的内容，SDP包通常包括以下信息：

会话信息

• 会话名和目的。
• 会话活动时间。

由于参与会话的资源是受限制的，因此包括以下附加信息是非常有用的。

• 会话使用的带宽信息。
• 会话负责人的联系信息。

媒体信息

• 媒体类型，例如视频和音频。
• 传输协议，例如RTP/UDP/IP和H.320。
• 媒体格式，例如H.261视频和MPEG视频。
• 多播地址和媒体传输端口（IP多播会话）。
• 用于联系地址的媒体和传输端口的远端地址（IP单播会话）。

SDP描述由许多文本行组成，文本行的格式为<类型>=<值>，<类型>是一个字母，<值>是结构化的文本串，其格式依<类型>而定。“=”两侧不允许有空格，一个值中的多个参数用空格分隔。

4.2 SDP协议格式

SDP会话描述由一个会话级描述（session_level description）和多个媒体级描述（media_level description）组成。会话级（session_level）的作用域是整个会话。其位置是从’v=’行开始到第一个媒体描述为止。媒体级（media_level）描述是对单个的媒体流进行描述（例如传送单个音频或者视频的vlc sdp文件只有短短的几句话，从m=开始，这其实就是个媒体机描述），其位置是从’m=’行开始到下一个媒体描述为止。总之，除非媒体部分重载，会话级的值是各个媒体的缺省默认值（就是说媒体级描述其实也是一个会话级描述，只不过没写出来的会话级描述参数都用的缺省值）。

详细可参考：SDP格式详解

v= （协议版本）
o= （所有者/创建者和会话标识符）
s= （会话名称）
i=* （会话信息）
u=* （URI 描述）
e=* （Email 地址）
p=* （电话号码）
c=* （连接信息 ― 如果包含在所有媒体中，则不需要该字段）
b=* （带宽信息）
一个或更多时间描述（如下所示）：z=* （时间区域调整）
k=* （加密密钥）
a=* （0个或多个会话属性线路）
0个或多个媒体描述（如下所示）
时间描述

t= （会话活动时间）
r=* （0或多次重复次数）
媒体描述

m= （媒体名称和传输地址）
i=* （媒体标题）
c=* （连接信息 — 如果包含在会话层则该字段可选）
b=* （带宽信息）
k=* （加密密钥）
a=* （0个或多个会话属性线路）

4.3 SDP实例

# 请求视频流
INVITE sip:00000000001310018021@192.168.40.66:7100 SIP/2.0
Via: SIP/2.0/UDP 192.168.40.55:7100;rport;branch=z9hG4bK2480933505
From: