GB28181/SIP/SDP 协议简介(下)

电子说

1.2w人已加入

描述

3.SIP协议

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

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

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

目前相关设备供应商和业务供应商联合成立了一个关于SIP的论坛: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进行管理。

SDP

3.1.5 Client Transaction 和Server Transaction

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

SDP

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消息由起始行开始。起始行传达消息类型(在请求中是方法类型,在响应中是响应代码)与协议版本。起始行可以是一请求行(请求)或状态行(响应) 。

请求消息

请求消息整体格式如图:

SDP

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

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

SDP

响应消息

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

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

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

响应消息整体格式如图:

SDP

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

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

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

SIP 头

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

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

样例:

SDP

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

General Request Response Entity
Accept Authorization Allow Content-encoding
Accept-encoding Contact Proxy-authenticate Content-length
Accept-language Hide Retry-after Content-type
Call-ID Max-forwards Server
Contact Organization Unsupported
Cseq Priority Warning
Date Proxy-authorization WWW-authenticate
Encryption Proxy-require
Expires Route
From Require
Record-route Response-key
Timestamp Subject
To User-agent
Via

具体详细可参考: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中发布。

样例:

SDP

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:
打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分