GB28181协议中基于数字摘要的挑战应答式安全技术进行注册流程如下图2所示: 图2 基本注册流程示意图 注册流程描述如下: (a) SIP代理向SIP服务器发送Register请求; (b) SIP 第4行为To头,To头在SIP协议中是为了标明请求接收方的逻辑标识的,在GB28181协议中填写的是发送请求的设备国标ID和域国标ID信息。 具体命令流程如图3: 图3 保活命令流程 命令流程描述如下: (a) 源设备向SIP服务器发送设备状态信息报送命令。 客户端主动发起的实时视音频点播流程见图4: 图4 客户端主动发起的实时视音频点播流程图 其中,信令1、8、9、10、11、12为SIP服务器接收到客户端的呼叫请求后通过B2BUA代理方式建立媒体流接收者与媒体服务器之间的媒体流信令过程 命令流程描述如下: (a) 媒体流接收者向SIP服务器发送INVITE消息, 消息头域中携带Subject字段, 表明点播的视频源ID、发送方媒体流序列号、媒体流接收者ID、接收端媒体流序列号等参数,SDP
前面三篇blog分别介绍国网B接口注册、资源上报和资源信息获取,今天过一下国网B接口调阅实时视频相关的接口描述和消息示例,做过GB28181设备接入的都知道,国网B接口调阅实时视频流程和GB28181的基本一致的 接口描述国网B接口调阅实时视频,相关规范写的比较粗略:调阅实时视频包括信令接口和媒体流接口,采用标准的SIP INVITE+SDP流程,媒体传输使用RTP/RTCP。 调阅实时视频的接口流程图片主要功能流程如下: a) F1:用户发送 INVITE 消息,携带 SDP 内容通过平台转发到前端设备。 再看看GB28181客户端主动发起的实时视音频点播流程:具体流程不再赘述,看看大牛直播SDK针对GB28181 invite的处理吧:图片收到Invite后,除了正常信令交互回复外,初始化Sender )接口描述和消息示例,然后就GB28181的invite做了简单的对比,感兴趣的开发者,可以仔细研读两份规范,看看还有哪些不一致的地方。
首先,介绍了设备目录查询、设备信息查询和设备状态查询三个重要的信息查询功能,并详细解释了它们在协议中的信令交互流程。随后,深入讨论了实时视频的实现方式,包括数据传输协议和传输规范要求。 设备目录查询的信令交互流程如下: 设备端发送查询请求信令(Query Catalog)到设备管理平台; 设备管理平台接收到请求后,返回设备目录信息(Catalog)给设备端。 下面是一个完整的实时视频信令交互过程: 图片 GB28181平台需要查看实时画面的时候,向目标设备发送实时视频邀请信令(Invite)。 GB28181平台 -> 设备端, INVITE INVITE sip:34020000001310000001@3402000000 SIP/2.0 Call-ID: helloVideo CSeq: :96 PS/90000 a=rtpmap:98 H264/90000 a=rtpmap:97 MPEG4/90000 y=0100000001 f= 设备端 -> GB28181平台,200OK SIP
接受和处理GB28181接入服务器的推流请求(如有推流权限验证则调用验证服务器接口);2. 接受和处理GB28181设备的推流;3. 实时流媒体处理,PS(TS)转ES;4. 接受和处理GB28181接入服务器的断开推流请求;6. 对外提供服务器获取状态、信息,控制等http API接口;GB28181流媒体服务器对接SkeyeSMS云平台整体框架图片流媒体点播详细流程1 接入服务器发送Invite请求接入服务器向流媒体服务器发送 Invite请求,请求流媒体服务返回携带SDP 消息体,消息体中描述了媒体服务器接收媒体流的IP、端口、媒体格式等内容;Invite请求代码如下: const options = 4 Invite设备正常返回200应答并传递给流媒体服务器代码在第3点中有所体现。
接口描述 国网B接口调阅实时视频,相关规范写的比较粗略: 调阅实时视频包括信令接口和媒体流接口,采用标准的SIP INVITE+SDP流程,媒体传输使用RTP/RTCP。 调阅实时视频的接口流程 图片 主要功能流程如下: a) F1:用户发送 INVITE 消息,携带 SDP 内容通过平台转发到前端设备。 d) F4:用户发送 ACK 通过平台转发到前端设备。 e) 视频流从前端系统传输经平台转发到用户。 f) F5:用户结束会话,发送 BYE 消息到通过平台转发到前端系统。 技术实现 由于国网B接口的invite实现和GB28181的差异不大,之前我们GB28181这块,已经有非常好的积累了。 GB28181流程基本一致,感兴趣的开发者,可以参考相关的规范实现,B接口相对GB28181来说,面更窄,资料也更少,如果产品化,有测试平台的话,还是不难实现的。
技术背景 在我们研发Android平台GB28181前端音视频接入模块之前,业内听到最多的是,如何用Android或者Windows端,在没有国标IPC设备的前提下,模拟GB28181的信令和媒体流交互流程 ,实现GB28181整体方案的测试? 设计思路 信令设计和媒体数据传输分离,上层实现国标GB28181的注册、注销、CATALOG、INVITE、ACK、BYE、SUBSCRIBE等交互处理,如注册成功后,返回注册时间,并检测传输或心跳等异常状态 ,服务端发送catalog请求后,组织本地catalog信息,并以message的形式发送到服务端,服务端收到相关信息后,开始发送invite请求,客户端解析INVITE返回的SDP信息,组织相关的response 为Android平台赋能,像支持GB28181协议的IPC一样,方便的把摄像头、屏幕、麦克风或外部RTSP、RTMP流,顺利接入到GB28181平台。
相关SPEC解读关于语音广播和对讲,感兴趣的开发者可直接参阅GBT 28181-2016.pdf相关技术规范里面的9.12章节,以下是部分精选介绍:图片命令交互流程图片命令描述流程a) 1:SIP服务器向语音流接收者发送语音广播通知消息 INVITE sip:34020000002000000001@3402000000 SIP/2.0Call-ID: 2b4f0f0512aa1a49ffc645618d0e8bae@192.168.2.212CSeq 向媒体服务器发送Invite消息,此消息不携带SDP消息体。 注:语音广播通知消息除上述流程中通过SIP服务器发出外,也可由语音流发送者发出,消息中通过 To头域标明 作为目的地址的语音流接收者ID,经SIP服务器中转后发往语音流接收者;语音流接收者处理后发送应答消 后续呼叫流程与上述流程相同。语音对讲语音对讲功能实现中心用户与前端用户之间的一对一语音对讲功能。
GB28181信令交互流程GB28181 规范中的信令交互流程主要包括注册、保活、设备信息查询、实时视频预览等环节,具体如下:注册流程下级设备发起注册请求:下级监控设备(如摄像头、编码器等)向上级监控平台 保活流程下级设备发送保活请求:注册成功后,下级设备需要定期向上级平台发送保活请求,以维持连接的有效性。 实时视频预览流程GB28181 规范中的实时视频预览流程主要包括以下步骤:发起预览请求34: 上级平台(客户端)动作:上级监控平台或有权限的客户端想要预览下级设备的实时视频时,会向下级设备发送INVITE 媒体服务器和下级设备响应:媒体服务器和下级设备收到BYE请求后,分别回复200 OK响应,会话断开,整个实时视频预览流程结束。 1:IPV6, 默认是IPV4, 当前仅支持IPV4 * * @return {0} if successful */public native int SetRTPSenderIPAddressType
GB28181历史视音频文件回放基本要求:需采用 SIP 协议中的 Invite 方法实现会话连接;采用SIP扩展协议Info方法的消息体携带视音频回放控制命令;采用 RTP/RTCP 协议实现媒体传输 基本流程如下:本文结合Android平台GB28181设备接入侧和GB28181国标平台侧,理下基本流程:1、GB28181平台侧向Android平台GB28181设备接入侧发送Invite消息,消息头域携带 Android国标设备侧发送ACK请求,请求中不携带消息体,完成与Android国标设备侧的Invite会话建立过程;4、Android GB28181设备侧按Invite SDP中给出的IP地址和端口等信息 设备侧收到国标平台侧的Invite: v=0 o=34020000001380000001 0 0 IN IP4 192.168.0.108 s=Playback u=34020000001380000001 y=1200000006Android平台GB28181设备侧回复国标平台侧: v=0 o=34020000011310000039 0 0 IN IP4 192.168.0.104
好多开发者对GB28181规范里面,broadcast和talk模式区分不清,今天借此机会,针对GB28181标准中的Broadcast(广播)和Talk(对讲)是两种不同的通信模式,它们在视频监控系统中扮演着不同的角色 Talk(对讲): 流程简述:通常涉及多个SIP信令交互,如设备侧发起INVITE请求建立通话,平台侧回复200 OK确认,然后双方开始传输语音数据,通话结束后发送BYE请求终止通话。4. 技术实现两者都基于GB28181标准实现,但具体的技术细节和信令流程有所不同。 Broadcast通常通过SIP MESSAGE方法实现,而Talk则通过SIP INVITE、ACK、BYE等信令方法实现双向通话。 综上所述,GB28181标准中的Broadcast和Talk在功能、通信方式、交互流程、应用场景和技术实现等方面都存在明显的区别。这些区别使得它们能够适用于不同的视频监控和通信需求场景。
GB28181标准规定了公共安全视频监控联网系统(以下简称联网系统) 的互联结构, 传输、 交换、 控制的基本要求和安全性要求, 以及控制、 传输流程和协议接口等技术要求。 2、GB28181框架: SIP 监控域互联结构示意图如下图所示: GB28181的联网方式分为级联和互联方式,级联方式可以详细分为信令级联和媒体级联,下图分别为信令级联和媒体级联方式: 信令级联: 媒体级联 4、GB28181具体功能: GB28181协议规定支持的功能有如下几项: (1)注册和注销 应支持设备或系统进入联网系统时向SIP 服务器进行注册登记的工作模式。 命令流程描述如下: (a) 媒体流接收者向SIP 服务器发送Invite 消息, 消息头域中携带 Subject 字段, 表明点播的视频源ID、 发送方媒体流序列号、 媒体流接收者ID、 接收端媒体流序列号等参数 (s)SIP 服务器向媒体流发送者发送 BYE 消息, 断开消息4、5、7 建立的同媒体流发送者的Invite 会话。 (t) 媒体流发送者收到 BYE 消息后回复200 OK 响应, 会话断开。
技术背景 对接Android平台GB28181设备接入端语音广播的时候,我们有遇到过INVITE SDP需要PCMA格式的audio,对方同时回了PS和PCMA两种,然后,发数据的时候,直接发了PS的。 INVITE sip:31010400001360000001@3101040000 SIP/2.0 Call-ID: 33a3b4d751e1bf831f9d7ddd03218fcaf CSeq: 796255 规范回顾 说了这么多废话,还是回顾下语音广播的交互流程,因为之前的blog做过几次说明,这里不再赘述: 图片 技术实现 本文以大牛直播SDK的Android平台基于Camera2的采集demo为例,如果需要注册到 GB28181平台,点击页面的“启动GB28181”即可,有语音广播过来后,使能“GB28181语音广播”按钮,用于主动关闭语音广播之用。 总结 GB28181设备接入这块,遇到的国标平台侧的问题真的是五花八门,真是印证了那句话:GB28181相关的模块,做demo容易,做产品,真的太难了,怪不得这么多公司懒得搞这块。
我在之前的blog,有提到过Android端GB28181接入端的语音广播和语音对讲,今天主要从GB/T28181-2016官方规范和交互流程,大概介绍下Android平GB28181接入端的语音广播和语音对讲 关于交互流程,本文不再赘述,一张图足矣:图片接下来,我们主要来看看规范里面提到的协议接口。 平台,点击页面的“启动GB28181”即可,有语音广播过来后,使能“GB28181语音广播”按钮,用于主动关闭语音广播之用。 */ void ntsOnInviteAudioBroadcastTimeout(String sourceID, String targetID); /* *音频广播, 收到Invite 消息, rtp ssrc暂时由sdk生成 *@param addressType: ipv4:"IP4", ipv6:"IP6", 其他不支持, 填充SDP用 *@param localAddress
规范解读GB28181 中的 “INVITE” 是会话初始协议(SIP)中的一种请求方法,主要用于邀请一个或多个参与者加入特定的会话。 在 GB28181 标准中,“INVITE” 请求通常用于发起媒体流的传输请求。 以下是 GB28181 中 “INVITE” 请求的一些关键特点和作用:一、发起会话触发媒体流传输:“INVITE” 请求是启动媒体流传输的关键步骤。 二、协商媒体参数媒体能力协商:在 GB28181 中,不同的设备可能具有不同的媒体处理能力。通过 “INVITE” 请求和响应的交互过程,可以进行媒体能力的协商。 0:1);libPublisher.SetRTPSenderIPAddressType(rtp_sender_handle, video_des.isIPv4()?
命令流程图片其中,信令 1,8,9、10,11,12 为 SIP 服务器接收到客户端的呼叫请求后通过 B2BUA 代理方式建立媒体流接受者与媒体服务器之间的媒体链接信令过程。 命令流程描述如下:媒体流接收者向 SIP 服务器发送Invite 消息,消息头域中携带 Subject 字段,表明点播的视频源 ID、发送方媒体流序列号、媒体流接收者 ID、接收端媒体流序列号标识等参数 SIP 服务器向媒体流发送者发送 BYE 消息,断开消息 4,5,7 建立的同媒体流发送者的Invite 会话。媒体流发送者收到 BYE 消息后回复 200 OK响应,会话断开。 技术实现本文以大牛直播SDK开发的Android平台GB28181设备接入侧视音频历史文件检索和下载为例(本文侧重于下载),介绍下相关设计思路:图片 Android设备接入端收到国标平台侧发过来的INVITE =rtpmap:98 H264/90000a=downloadspeed:4y=1200000001上述SDP里面,s=Download表示系下载,a=downloadspeed:4 表示4倍速下载,SSRC
模块对大牛直播SDK来说,只要数据源有了,任督二脉也就打通了,数据可以实时录制到MP4文件,可以推送到RTMP,可以对接到轻量级RTSP服务,当然也可以对接到GB28181设备接入模块。 支持对接数据类型如下:编码前数据(目前支持的有YV12/NV21/NV12/I420/RGB24/RGBA32/RGB565等数据类型);编码后数据(如无人机等264/HEVC数据,或者本地解析的MP4音视频数据 );拉取RTSP或RTMP流并接入至GB28181平台(比如其他IPC的RTSP流,可通过Android平台GB28181接入到国标平台)。 的Invite、Ack、Bye等处理:public interface GBSIPAgentPlayListener { /* *收到s=Play的实时视音频点播 */ void 都非常方便,以上是大概的流程,感兴趣的开发者,可以单独跟我沟通探讨。
本文旨在讲如何实现无人机(如大疆无人机)数据到GB28181平台(如海康、大华、宇视等国标平台)。 当国标平台端,需要查看无人机的实时画面时,可以发送Invite,请求无人机画面,Android平台GB28181接入模块,这时启动拉取无人机回调数据,并完成数据投递,和H.264到PS到RTP的打包上传即可 int size, int is_key_frame, long timestamp,ByteBuffer parameter_info, int parameter_info_size);其他信令交互流程前面提到很多次了 ,本文不再赘述,这里主要看看Invite和Ack的处理:先看Invite处理:@Override public void ntsOnInvitePlay(String deviceId, PlaySessionDescription 0:1); libPublisher.SetRTPSenderIPAddressType(rtp_sender_handle, video_des.isIPv4()?
通常工业级的IPC一般支持onvif,GB28181以及各厂家私有协议。上篇文章我们讲解如何通过onvif协议对接IPC,本文接下来介绍如何接入通过国内最主流的GB28181协议对接IPC。 目前城市街道,公共场所,社区等各个安防设备基本都是通过GB28181在协议互通。如IPC,NVR,媒体网关等。本文以大华IPC为例子,直接上代码,演示如何通过GB28181协议将视频流拉下来。 通道编码:跟设备编号一致即可 其他选项暂时默认即可 二 接入方案 因为GB28181信令是基于SIP协议的一个应用,本文采用eXosip开源方案作为GB28181的协议栈完成接入。 %s\r\n" "s=Play\r\n" "c=IN IP4 %s\r\n" "t=0 0\r\n" "m=video %d RTP "a=rtpmap:96 PS/90000\r\n" "a=rtpmap:98 H264/90000\r\n" "a=rtpmap:97 MPEG4/
收到用户反馈,技术人员立即开展排查,以下为解决步骤:1)首先登录到上级平台,将EasyCVR推送的通道进行播放,可以看出海康平台无法显示画面;2)随后通过GB28181协议级联,以抓包的方式来排查问题; 3)在下级抓包的同时在上级点击播放,展开报文查看整个流程信息,可以看到从上级请求invite消息到ack信令流程正常;4)然后再通过invite信息展开查看请求的流端口下级未发流,继续排查信令消息的数据是否有异常 ,可以看到invite请求的设备编号和上级ack确认的通道编号不一致,随后联系上级平台进行修改;5)最后在上级平台进行对ack信息的通道编号改正和invite一致时,下级EasyCVR正常发流,上级平台也播放正常了 平台可支持1、4、9、16个画面窗口播放,可同时播放多路视频流,也能支持视频定时轮播。感兴趣的用户可以前往演示平台进行体验或部署测试。
点播域内设备、点播外域设备媒体流SSRC的处理方式分别说明如下:a) 点播域内设备媒体流SSRC处理方式点播域内设备媒体流时,SSRC值由本域监控系统产生并通过Invite请求发送给设备使用,设备在回复的 流程图见图 F.1。 流程图见图 F.2。 图片注5:错误响应补充说明当设备收到无法满足的SDP时,向发送的Invite请求方发送488错误响应消息;当设备不能满足更多的呼叫请求时,向发送的Invite请求方发送486错误响应消息。 command_from_user_name_at_domain_, source_id_, target_id_, "IP4"