GB28181之实时点播

1实时点播信令流程

平台点播实时视频到关闭视频这个过程,上下级平台信令交互分为五个步骤,点播请求视频信令由上级平台发起。通过wireshark抓包发现信令如下:
GB28181之实时点播
信令包为SIP包(Session Initiation Protoocal),传输层使用UDP协议。
点播流程:
①上级平台向下级发送INVITE请求,请求实时视频
②下级平台回复200OK
③上级平台回复ACK确认
④关闭视频,上级向下级平台发送BYE请求,请求关闭视频
⑤下级平台回复200OK

2点播信令流程详解

2.1上级发送INVITE请求
上级平台(192.168.2.2为平台对接网关)向下级(192.168.1.1为平台对接网关)发送invite请求,请求国标编码为44140302001310131077的这路摄像机视频。
①Call-ID:唯一标识这次的点播流程,即这次点播的五条信令中的Call-ID都是相同的。
②s=Play:说明请求的是实时视频。
③c= IN IP4:此字段的IP地址为自己平台的流媒体服务器,通过此字段告知对方流媒体的地址(192.168.2.30)。
GB28181之实时点播
2.2下级回复200OK
下级平台收到invite点播请求后,回复200OK允许请求,并在提供流媒体服务器信息,即通过c=IN IP4字段通知上级平台自己的流媒体服务器地址是多少(192.168.1.1)。
GB28181之实时点播
2.3上级回复ACK确认
上级平台收到200OK信息后,会发送ACK进行确认,然后双方的流媒体服务器就会进行码流传输。码流包传输分为基于TCP和UDP协议这两种方式。
①码流基于UDP传输
下级平台收到ACK包后,流媒体服务器(即192.168.1.1)主动向上级流媒体(即192.168.2.30)发送视频流。
②码流基于TCP传输
由于TCP协议是可靠传输,需要先通过三次握手建立连接,作为TCP客户端的流媒体向TCP服务端流媒体发起TCP请求建立连接,连接建立后下级平台流媒体继而开始发送视频流。
GB28181之实时点播
2.4上级发送BYE请求关闭视频
上级平台关闭视频,上级网关主动向下级网关发送BYE信令,请求关闭视频。
①码流基于UDP
GB28181之实时点播
2.5下级回复200OK同意关闭视频
下级网关收到BYE请求后,回复200OK同意关闭视频,然后流媒体服务器开始停止发送视频流,停止发送视频流又分为基于TCP和UDP这两种情况。
①码流基于UDP传输
下级网关回复200OK后,下级流媒体主动停止发送视频流。
②码流基于TCP传输
下级网关回复200OK后,流媒体服务器之间通过四次挥手断开连接,此过程由作为TCP客户端的流媒体服务器主动发起断开TCP连接请求。
GB28181之实时点播

3实时点播总结

平常在排查实时视频点播失败的问题时,可通过查看对接网关日志或者抓包来分析整个点播流程,定位出哪个信令步骤出错。如果信令回复都正常,则在流媒体之间抓码流包分析码流包是否正常。例如在实际环境中就遇到信令回复正常但是视频点播无图像的情况,通过抓码流包发现下级平台实际发送视频流的流媒体服务器IP与网关信令中回复的流媒体服务器IP不一致,导致视频点播无图像。

猜你喜欢

转载自blog.51cto.com/chihualee/2136839