SIP协议详解

Posted Jons伯恩特

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了SIP协议详解相关的知识，希望对你有一定的参考价值。

SIP协议基本介绍

背景介绍

Internet的许多应用都需要建立和管理一个会话，会话在这里的含义是在参与者之间的数据的交换。由于考虑到参与者的实际情况，这些应用的实现往往是很复杂的：参与者可能是在代理间移动，他们可能可以有多个名字，他们中间的通讯可能是基于不同的媒介（比如文本，多媒体，视频，音频等）－有时候是多种媒介一起交互。人们创造了无数种通讯协议应用于实时的多媒体会话数据比如声音，影像，或者文本。SIP（会话初始协议）和这些协议一样，同样允许使用Internet端点（用户代理）来寻找参与者并且允许建立一个可共享的会话描述。为了能够定位精确的会话参与者，并且也为了其他的目的，SIP允许创建基础的network hosts（叫做代理服务器），并且允许终端用户注册上去，发出会话邀请，或者发出其他请求。SIP是一个轻形的，多用途的工具，可以用来创建，修改和终止会话，它独立运作于通讯协议之下，并且不依赖建立的会话类型。

功能介绍

SIP是一个应用层的控制协议，可以用来建立、修改、和终止多媒体会话（或者会议）例如Internet 电话。SIP也可以邀请参与者参加已经存在的会话，比如多方会议。媒体可以在一个已经存在的会话中方便的增加（或者删除）。SIP显示的支持名字映射和重定向服务，这个用于支持个人移动业务－用户可以使用一个唯一的外部标志而不用关系他们的实际网络地点。SIP在建立和维持终止多媒体会话协议上，支持5个方面：
1） 用户定位： 检查终端用户的位置，用于通讯。
2） 用户有效性：检查用户参与会话的意愿程度。
3） 用户能力：检查媒体和媒体的参数。
4） 建立会话：”ringing”,建立会话参数在呼叫方和被叫方。
5） 会话管理：包括发送和终止会话，修改会话参数，激活服务等等。

SIP协议格式介绍

概括-总体

SIP消息体结构与Http协议结构相似，均由三部分组成：

•请求行(request-line) or 状态行(status-line)

•消息头(header)

•正文(body)

  请求行

请求行格式：Method Request-URI SIP-Version CRLF

请求行举例：INVITE sip:bob@zte.com SIP/2.0 /r/n

Method:以下列出了几种消息Method方法

Request-URI：指示请求的用户或者服务的地址信息

SIP-Version：请求和响应消息都需要包含SIP版本

状态行

状态行格式： SIP-Version Status-Code Reason-Phrase CRLF

状态行举例：SIP/2.0 200 OK /r/n

Status-Code状态码：状态代码由3位数字组成，表示请求是否被理解或被满足。

状态代码的第一个数字定义了响应的类别，后面两位没有具体的分类。

消息头

MESSAGE sip:0210011140114@10.192.39.37:17017 SIP/2.0

Via: SIP/2.0/UDP 10.192.39.194:15069;rport;branch=z9hG4bK2000324456

From: <sip:0100012000002@10.192.39.194:15069>;tag=2253307030

To: sip:0210011140114@10.192.39.37:17017

Contact: <sip:0100012000002@10.192.39.194:15069>

Call-ID: 755416301

CSeq: 20 MESSAGE

Content-Type: Application/MANSCDP+xml

Max-Forwards: 70

User-Agent: eXosip/3.3.0

Content-Length:   161

Header

含义说明

举例

Call-ID

由本地设备(Client)生成，全局唯一，每次呼叫这个值唯一不变

Call-ID: 755416301

From

表示请求的发起者

From: <sip:0100012000002@10.192.39.194:15069>;tag=2253307030

To

表示请求的接收者

To: sip:user2@domain.com

Via

Via头域是被服务器插入request中，用来检查路由环的，并且可以使response根据via找到返回的路

To: <sip:0210011140114@10.192.39.37:17017>

Max-Forwards

用于表示这个包最多可以传送多少跳，每经过一跳都会减一当Max-Forwards==0系统会返回483。默认为70

Max-Forwards: 70

Contact

包含源的URI信息，用来给响应方直接和源建立连接用

Contact: <sip:0100012000002@10.192.39.194:15069>

Content-Type

指明消息体的类型 (SDP会话描述协议)

Content-Type: text/plain；Content-Type: application/sdp; Content-Type: application/cpim;

Content-Length

指明消息体的字节大小

Content-Length: 47

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。

                                                                           

重要概念

 

sip协议最重要的是要弄清楚sip协议的3个核心定义：dialog（对话）、session（会话）、transaction（事务）把这3部分梳理清楚就可以清楚的看到sip协议栈的基本架构了。

事务

概述：Transaction事务是指一个请求消息以及这个请求对应的所有响应消息的集合。

理解：                                    

       1. 对于INVITE事务来讲，除包含INVITE请求和对应的响应消息外，在非成功响应的情况下，还包括ACK请求。

       2.Via头中的branch参数能够唯一确定一个事务。branch值相同，代表同一个 transaction(事务)。

       3.事务是由事件（方法）来引起的，一个方法（Method）的建立和到来都将建立新的事务。（实际上当收到新消息时，就是根据branch来查找对应的事务）

       4.根据sip协议描述一个transaction由5个必要部分组成：from、to、Via头中的branch参数、call-id和cseq，这5个部分一起识别某一个transaction， 如果缺少任何一部分，该transaction就会设置失败。

 

对话

概述: Dialog对话是两个UA之间持续一段时间的点对点的SIP连接。

理解:

        1.它使UA之间的消息变得有序，同时给出请求消息的正确的路由。

        2.Call-ID、from-tag以及to-tag三个值的组合能够唯一标识一次对话。

        3.对话一般是由Invite and Subscribe  来创建的。即对话处于确定阶段时，对话已经建立起来。

注意事项：

        1.在一个对话中不同UA之间的 dialog ID 是不同的。

        2.在一个UA中的 local tag 与其对方的 remote tag 是一样的。tag 是透明的标记，这有助于生成独一无二的 dialog ID。

 

会话

概述:会话是一次通信过程中所有参与者之间的关联关系以及他们之间的媒体流的集合。

理解:

根据SDP 的描述：“一个多媒体会话是多媒体的发送者和接收者以及传输与发送者与接收者之间的多媒体流，一个多媒体会议是一个多媒体会话的例子”（在SDP定义下的会话是可以包含一个或者多个RTP会话）。一个被叫方可以被邀请多次，被不同的呼叫方呼叫至同一个会话，如果使用了SDP，一个会话被SDP开头处的一些相关的SDP用户名、会话id、网络类型、地址类型元素定义。

注意事项：

            1.只有当媒体协商成功后，会话才能被建立起来。

 

SDP协议介绍

 

以国标28181协议中SDP信息为例:

v=0                                                                               //版本信息
o=33010602001310019325 0 0 IN IP4 10.64.49.44   // 拥有者信息 （33010602001310019325 监控点编码  / 10.64.49.44 拥有者IP)
s=Play                                                                       // 会话主题  (Play 实时预览 PlayBack 录像回放 DownLoad 录像下载)
c=IN IP4 10.64.49.44                                                // 媒体接收者IP
t=0 0                                                                          // 时间（0 0 标识实时预览  非0 0 标识录像回放或者下载时间段）
m=video 5494 RTP/AVP 96 97 98                           // 媒体信息 (5494 媒体端口  RTP/AVP rtp 负载类型(tcp/udp))
a=rtpmap:96 PS/90000                                          // 视频流编码 PS格式  Pts 单位1/90000
a=rtpmap:97 MPEG4/90000
a=rtpmap:98 H264/90000
a=recvonly
y=0999999999

RTP协议格式

实时传输协议（Real-time Transport Protocol）是一个网络传输协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的。RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |V=2|P|X|  CC   |M|     PT      |       sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           synchronization source (SSRC) identifier            |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |            contributing source (CSRC) identifiers             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
上图引自rfc3550，由上图中可知道RTP报文由两个部分构成--RTP报头和RTP的负载：

RTP报文由两部分组成：报头和有效载荷。RTP报头格式如图所示，其中：

1.V：RTP协议的版本号，占2位，当前协议版本号为2。

2. P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。

3. X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。

4.  CC：CSRC计数器，占4位，指示CSRC 标识符的个数。

5. M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。

6. PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等,在流媒体中大部分是用来区分音频流和视频流的，这样便于客户端进行解析。

7. 序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。这个字段当下层的承载协议用UDP的时候，网络状况不好的时候可以用来检查丢包。同时出现网络抖动的情况可以用来对数据进行重新排序，在helix服务器中这个字段是从0开始的，同时音频包和视频包的sequence是分别记数的。

8. 时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。

9. 同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。

10. 特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。

如果扩展标志被置位则说明紧跟在报头后面是一个头扩展，其格式如下：

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      defined by profile       |           length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        header extension                       |
   |                             ....                              |

PS流格式

节目流（PS）由打包的基本码流（PES）组合而成，即一组视频、音频和数据基本分量，它们具有共同的相对时间关系，其分组长度可变，且相对较长，一般用于传输、存储及本地播放等误码相对较少的环境。

示例

注册-含鉴权

REGISTER sip:130909115229300920@10.64.49.44:7100 SIP/2.0   
Via: SIP/2.0/UDP 10.64.49.218:7100;rport;branch=z9hG4bK4162288924 
From: <sip:130909113319427420@10.64.49.218:7100>;tag=382068091
To: <sip:130909113319427420@10.64.49.218:7100>
Call-ID: 143225205      
CSeq: 1 REGISTER
Contact: <sip:130909113319427420@10.64.49.218:7100>
Max-Forwards: 70
User-Agent: Hikvision
Expires: 7200
Content-Length: 0

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.64.49.218:7100;rport=7100;branch=z9hG4bK4162288924
From: <sip:130909113319427420@10.64.49.218:7100>;tag=382068091
To: <sip:130909113319427420@10.64.49.218:7100>;tag=916944766
Call-ID: 143225205
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="hik", nonce="a8afe6fcbee6331d89d3eb0d3d19ce39", opaque="a853e4f25298413f9bf3a9aa6767857d", algorithm=MD5
User-Agent: Hikvision
Expires: 7200
Content-Length: 0

REGISTER sip:130909115229300920@10.64.49.44:7100 SIP/2.0
Via: SIP/2.0/UDP 10.64.49.218:7100;rport;branch=z9hG4bK3997518011
From: <sip:130909113319427420@10.64.49.218:7100>;tag=382068091
To: <sip:130909113319427420@10.64.49.218:7100>
Call-ID: 143225205
CSeq: 2 REGISTER
Contact: <sip:130909113319427420@10.64.49.218:7100>
Authorization: Digest username="admin", realm="hik", nonce="a8afe6fcbee6331d89d3eb0d3d19ce39", uri="sip:130909115229300920@10.64.49.44:7100", response="907ddb1bcc25174d7de4a96c947fb066", algorithm=MD5, opaque="a853e4f25298413f9bf3a9aa6767857d"
Max-Forwards: 70
User-Agent: Hikvision
Expires: 7200
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.64.49.218:7100;rport=7100;branch=z9hG4bK3997518011
From: <sip:130909113319427420@10.64.49.218:7100>;tag=382068091
To: <sip:130909113319427420@10.64.49.218:7100>;tag=705514612
Call-ID: 143225205
CSeq: 2 REGISTER
Contact: <sip:130909113319427420@10.64.49.218:7100>
User-Agent: Hikvision
Date: 2013-09-10T16:01:51
Content-Length: 0

预览-包含结束bye

INVITE sip:33010602001310019325@10.64.49.218:7100 SIP/2.0
Via: SIP/2.0/UDP 10.64.49.44:7100;rport;branch=z9hG4bK1839167633
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>
Call-ID: 2074790969
CSeq: 20 INVITE
Contact: <sip:130909115229300920@10.64.49.44:7100>
Content-Type: Application/SDP
Max-Forwards: 70
User-Agent: Hikvision
Subject: 33010602001310019325:0,130909115229300920:0
Content-Length: 216

v=0
o=33010602001310019325 0 0 IN IP4 10.64.49.44
s=Play
c=IN IP4 10.64.49.44
t=0 0
m=video 5494 RTP/AVP 96 97 98
a=rtpmap:96 PS/90000
a=rtpmap:97 MPEG4/90000
a=rtpmap:98 H264/90000
a=recvonly
y=0999999999

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.64.49.44:7100;rport=7100;branch=z9hG4bK1839167633
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>
Call-ID: 2074790969
CSeq: 20 INVITE
User-Agent: Hikvision
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.64.49.44:7100;rport=7100;branch=z9hG4bK1839167633
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>;tag=3330812776
Call-ID: 2074790969
CSeq: 20 INVITE
Contact: <sip:130909113319427420@10.64.49.218:7100>
Content-Type: Application/SDP
User-Agent: Hikvision
Content-Length: 162

v=0
o=33010602001310019325 0 0 IN IP4 10.64.49.44
s=Play
c=IN IP4 10.64.49.218
t=0 0
m=video 5514 RTP/AVP 96
a=rtpmap:96 PS/90000
a=sendonly
y=0060205514


ACK sip:130909113319427420@10.64.49.218:7100 SIP/2.0
Via: SIP/2.0/UDP 10.64.49.44:7100;rport;branch=z9hG4bK3589109049
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>;tag=3330812776
Call-ID: 2074790969
CSeq: 20 ACK
Contact: <sip:130909115229300920@10.64.49.44:7100>
Max-Forwards: 70
User-Agent: Hikvision
Content-Length: 0

BYE sip:130909113319427420@10.64.49.218:7100 SIP/2.0
Via: SIP/2.0/UDP 10.64.49.44:7100;rport;branch=z9hG4bK2928302365
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>;tag=3330812776
Call-ID: 2074790969
CSeq: 21 BYE
Contact: <sip:130909115229300920@10.64.49.44:7100>
Max-Forwards: 70
User-Agent: Hikvision
Content-Length: 0

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.64.49.44:7100;rport=7100;branch=z9hG4bK2928302365
From: <sip:130909115229300920@10.64.49.44:7100>;tag=868569348
To: <sip:33010602001310019325@10.64.49.218:7100>;tag=3330812776
Call-ID: 2074790969
CSeq: 21 BYE
User-Agent: Hikvision
Content-Length: 0

以上是关于SIP协议详解的主要内容，如果未能解决你的问题，请参考以下文章

sip协议是啥，sip协议的功能及其应用

RTP/RTCP协议详解

P2P通信标准协议之SIP

GB28181之SIP协议

GB28181之SIP协议

GB28181之SIP协议