GB28181协议中基于数字摘要的挑战应答式安全技术进行注册流程如下图2所示: 图2 基本注册流程示意图 注册流程描述如下: (a) SIP代理向SIP服务器发送Register请求; (b) SIP 具体命令流程如图3: 图3 保活命令流程 命令流程描述如下: (a) 源设备向SIP服务器发送设备状态信息报送命令。 命令流程描述如下: (a) 媒体流接收者向SIP服务器发送INVITE消息, 消息头域中携带Subject字段, 表明点播的视频源ID、发送方媒体流序列号、媒体流接收者ID、接收端媒体流序列号等参数,SDP (f) SIP服务器收到媒体流发送者返回的200 OK响应后,向媒体服务器发送ACK请求,请求中携带消息5中媒体流发送者回复的200 OK响应消息体, 完成与媒体服务器的INVITE会话建立过程。 (s) SIP服务器向媒体流发送者发送BYE消息,断开消息4、5、7建立的同媒体流发送者的INVITE会话。 (t) 媒体流发送者收到BYE消息后回复200 OK响应, 会话断开。
首先,介绍了设备目录查询、设备信息查询和设备状态查询三个重要的信息查询功能,并详细解释了它们在协议中的信令交互流程。随后,深入讨论了实时视频的实现方式,包括数据传输协议和传输规范要求。 设备目录查询的信令交互流程如下: 设备端发送查询请求信令(Query Catalog)到设备管理平台; 设备管理平台接收到请求后,返回设备目录信息(Catalog)给设备端。 其信令交互流程如下: 设备端发送查询请求信令(Query Device)到设备管理平台,携带要查询设备的ID; 设备管理平台接收到请求后,返回设备详细信息(Device Info)给设备端。 下面是一个完整的实时视频信令交互过程: 图片 GB28181平台需要查看实时画面的时候,向目标设备发送实时视频邀请信令(Invite)。 GB28181平台 -> 设备端, INVITE INVITE sip:34020000001310000001@3402000000 SIP/2.0 Call-ID: helloVideo CSeq:
前面三篇blog分别介绍国网B接口注册、资源上报和资源信息获取,今天过一下国网B接口调阅实时视频相关的接口描述和消息示例,做过GB28181设备接入的都知道,国网B接口调阅实时视频流程和GB28181的基本一致的 接口描述国网B接口调阅实时视频,相关规范写的比较粗略:调阅实时视频包括信令接口和媒体流接口,采用标准的SIP INVITE+SDP流程,媒体传输使用RTP/RTCP。 调阅实时视频的接口流程图片主要功能流程如下: a) F1:用户发送 INVITE 消息,携带 SDP 内容通过平台转发到前端设备。 再看看GB28181客户端主动发起的实时视音频点播流程:具体流程不再赘述,看看大牛直播SDK针对GB28181 invite的处理吧:图片收到Invite后,除了正常信令交互回复外,初始化Sender )接口描述和消息示例,然后就GB28181的invite做了简单的对比,感兴趣的开发者,可以仔细研读两份规范,看看还有哪些不一致的地方。
接受和处理GB28181接入服务器的推流请求(如有推流权限验证则调用验证服务器接口);2. 接受和处理GB28181设备的推流;3. 实时流媒体处理,PS(TS)转ES;4. 推送ES流到SkeyeSMS流媒体服务器;5. 接受和处理GB28181接入服务器的断开推流请求;6. 对外提供服务器获取状态、信息,控制等http API接口;GB28181流媒体服务器对接SkeyeSMS云平台整体框架图片流媒体点播详细流程1 接入服务器发送Invite请求接入服务器向流媒体服务器发送 Invite请求,请求流媒体服务返回携带SDP 消息体,消息体中描述了媒体服务器接收媒体流的IP、端口、媒体格式等内容;Invite请求代码如下: const options = 5 流媒体服务接受拉流请求成功应答 uas.on('ack', async ctx => { const request = ctx.request;
技术背景 在我们研发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平台。
GB28181标准规定了公共安全视频监控联网系统(以下简称联网系统) 的互联结构, 传输、 交换、 控制的基本要求和安全性要求, 以及控制、 传输流程和协议接口等技术要求。 4、GB28181具体功能: GB28181协议规定支持的功能有如下几项: (1)注册和注销 应支持设备或系统进入联网系统时向SIP 服务器进行注册登记的工作模式。 命令流程描述如下: (a) 媒体流接收者向SIP 服务器发送Invite 消息, 消息头域中携带 Subject 字段, 表明点播的视频源ID、 发送方媒体流序列号、 媒体流接收者ID、 接收端媒体流序列号等参数 (f)SIP 服务器收到媒体流发送者返回的200 OK 响应后, 向媒体服务器发送 ACK 请求, 请求中携带消息5 中媒体流发送者回复的200 OK 响应消息体, 完成与媒体服务器的Invite 会话建立过程 (s)SIP 服务器向媒体流发送者发送 BYE 消息, 断开消息4、5、7 建立的同媒体流发送者的Invite 会话。 (t) 媒体流发送者收到 BYE 消息后回复200 OK 响应, 会话断开。
好多开发者对GB28181规范里面,broadcast和talk模式区分不清,今天借此机会,针对GB28181标准中的Broadcast(广播)和Talk(对讲)是两种不同的通信模式,它们在视频监控系统中扮演着不同的角色 Talk(对讲): 流程简述:通常涉及多个SIP信令交互,如设备侧发起INVITE请求建立通话,平台侧回复200 OK确认,然后双方开始传输语音数据,通话结束后发送BYE请求终止通话。4. 5. 技术实现两者都基于GB28181标准实现,但具体的技术细节和信令流程有所不同。 Broadcast通常通过SIP MESSAGE方法实现,而Talk则通过SIP INVITE、ACK、BYE等信令方法实现双向通话。 综上所述,GB28181标准中的Broadcast和Talk在功能、通信方式、交互流程、应用场景和技术实现等方面都存在明显的区别。这些区别使得它们能够适用于不同的视频监控和通信需求场景。
接口描述 国网B接口调阅实时视频,相关规范写的比较粗略: 调阅实时视频包括信令接口和媒体流接口,采用标准的SIP INVITE+SDP流程,媒体传输使用RTP/RTCP。 调阅实时视频的接口流程 图片 主要功能流程如下: a) F1:用户发送 INVITE 消息,携带 SDP 内容通过平台转发到前端设备。 f) F5:用户结束会话,发送 BYE 消息到通过平台转发到前端系统。 g)F6:前端系统发送确认,将媒体通道拆线。 技术实现 由于国网B接口的invite实现和GB28181的差异不大,之前我们GB28181这块,已经有非常好的积累了。 GB28181流程基本一致,感兴趣的开发者,可以参考相关的规范实现,B接口相对GB28181来说,面更窄,资料也更少,如果产品化,有测试平台的话,还是不难实现的。
相关SPEC解读关于语音广播和对讲,感兴趣的开发者可直接参阅GBT 28181-2016.pdf相关技术规范里面的9.12章节,以下是部分精选介绍:图片命令交互流程图片命令描述流程a) 1:SIP服务器向语音流接收者发送语音广播通知消息 向媒体服务器发送Invite消息,此消息不携带SDP消息体。 在消息5中增加SSRC值,转发给媒体服务器。 q) 17:SIP服务器向语音流接收者发送 BYE消息,断开消息5、14、15建立的Invite会话。 r) 18:语音流接收者收到 BYE消息后回复200OK 响应,会话断开。 后续呼叫流程与上述流程相同。语音对讲语音对讲功能实现中心用户与前端用户之间的一对一语音对讲功能。
GB28181信令交互流程GB28181 规范中的信令交互流程主要包括注册、保活、设备信息查询、实时视频预览等环节,具体如下:注册流程下级设备发起注册请求:下级监控设备(如摄像头、编码器等)向上级监控平台 保活流程下级设备发送保活请求:注册成功后,下级设备需要定期向上级平台发送保活请求,以维持连接的有效性。 实时视频预览流程GB28181 规范中的实时视频预览流程主要包括以下步骤:发起预览请求34: 上级平台(客户端)动作:上级监控平台或有权限的客户端想要预览下级设备的实时视频时,会向下级设备发送INVITE 媒体服务器和下级设备响应:媒体服务器和下级设备收到BYE请求后,分别回复200 OK响应,会话断开,整个实时视频预览流程结束。 同时,也会适应网络技术的发展,更好地支持 5G、IPv6 等新的网络环境,以满足大规模、高并发的视频传输需求。安全性增强:视频监控涉及到公共安全和个人隐私等重要信息,因此安全性将是未来发展的重点。
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地址和端口等信息 ,发送音视频RTP包(推荐PS RTP包)到媒体服务器;5、回放过程中,播放端通过向SIP服务器发送会话内Info+MANSRTSP消息(SIP服务器再转发给安卓设备端)进行回放控制,包括视频暂停、播放 应答命令:客户端、服务器端应支持应答命令的状态码200、4xx以及5xx。见IETFRFC2326。Scale和 Range头域取值范围 Scale头应支持的基本取值为0.25、0.5、1、2、4。
技术背景 对接Android平台GB28181设备接入端语音广播的时候,我们有遇到过INVITE SDP需要PCMA格式的audio,对方同时回了PS和PCMA两种,然后,发数据的时候,直接发了PS的。 MESSAGE sip:34020000002000000001@192.168.2.120:15060 SIP/2.0 Call-ID: 5ae7cfcd8b6696b02a512e32c38bbe35 规范回顾 说了这么多废话,还是回顾下语音广播的交互流程,因为之前的blog做过几次说明,这里不再赘述: 图片 技术实现 本文以大牛直播SDK的Android平台基于Camera2的采集demo为例,如果需要注册到 GB28181平台,点击页面的“启动GB28181”即可,有语音广播过来后,使能“GB28181语音广播”按钮,用于主动关闭语音广播之用。 总结 GB28181设备接入这块,遇到的国标平台侧的问题真的是五花八门,真是印证了那句话:GB28181相关的模块,做demo容易,做产品,真的太难了,怪不得这么多公司懒得搞这块。
我在之前的blog,有提到过Android端GB28181接入端的语音广播和语音对讲,今天主要从GB/T28181-2016官方规范和交互流程,大概介绍下Android平GB28181接入端的语音广播和语音对讲 关于交互流程,本文不再赘述,一张图足矣:图片接下来,我们主要来看看规范里面提到的协议接口。 31010400002000000001@3101040000SIP/2.0From:<sip:31010403001370002272@3101040300>;tag=b55b4cf8-c700a8c0-1587-a3-1ba9ac5- a3To:<sip:31010400002000000000@3101040000>Call-ID:b55b4cf8-c700a8c0-1587-a3-5eacf182-a3@3101040300CSeq 平台,点击页面的“启动GB28181”即可,有语音广播过来后,使能“GB28181语音广播”按钮,用于主动关闭语音广播之用。
命令流程图片其中,信令 1,8,9、10,11,12 为 SIP 服务器接收到客户端的呼叫请求后通过 B2BUA 代理方式建立媒体流接受者与媒体服务器之间的媒体链接信令过程。 命令流程描述如下:媒体流接收者向 SIP 服务器发送Invite 消息,消息头域中携带 Subject 字段,表明点播的视频源 ID、发送方媒体流序列号、媒体流接收者 ID、接收端媒体流序列号标识等参数 SIP 服务器收到媒体流发送者返回的 200 OK响应后,向媒体服务器发送 ACK 请求,请求中携带消息 5 中媒体流发送者回复的 200 OK响应消息体,完成与媒体服务器的 Invite 会话建立过程 SIP 服务器向媒体流发送者发送 BYE 消息,断开消息 4,5,7 建立的同媒体流发送者的Invite 会话。媒体流发送者收到 BYE 消息后回复 200 OK响应,会话断开。 技术实现本文以大牛直播SDK开发的Android平台GB28181设备接入侧视音频历史文件检索和下载为例(本文侧重于下载),介绍下相关设计思路:图片 Android设备接入端收到国标平台侧发过来的INVITE
规范解读GB28181 中的 “INVITE” 是会话初始协议(SIP)中的一种请求方法,主要用于邀请一个或多个参与者加入特定的会话。 在 GB28181 标准中,“INVITE” 请求通常用于发起媒体流的传输请求。 以下是 GB28181 中 “INVITE” 请求的一些关键特点和作用:一、发起会话触发媒体流传输:“INVITE” 请求是启动媒体流传输的关键步骤。 二、协商媒体参数媒体能力协商:在 GB28181 中,不同的设备可能具有不同的媒体处理能力。通过 “INVITE” 请求和响应的交互过程,可以进行媒体能力的协商。 ");}}}} GBSIPAgentPlayListener主要系GB28181的Invite、Ack、Bye等处理:public interface GBSIPAgentPlayListener {
收到用户反馈,技术人员立即开展排查,以下为解决步骤:1)首先登录到上级平台,将EasyCVR推送的通道进行播放,可以看出海康平台无法显示画面;2)随后通过GB28181协议级联,以抓包的方式来排查问题; 3)在下级抓包的同时在上级点击播放,展开报文查看整个流程信息,可以看到从上级请求invite消息到ack信令流程正常;4)然后再通过invite信息展开查看请求的流端口下级未发流,继续排查信令消息的数据是否有异常 ,可以看到invite请求的设备编号和上级ack确认的通道编号不一致,随后联系上级平台进行修改;5)最后在上级平台进行对ack信息的通道编号改正和invite一致时,下级EasyCVR正常发流,上级平台也播放正常了
点播域内设备、点播外域设备媒体流SSRC的处理方式分别说明如下:a) 点播域内设备媒体流SSRC处理方式点播域内设备媒体流时,SSRC值由本域监控系统产生并通过Invite请求发送给设备使用,设备在回复的 流程图见图 F.1。 流程图见图 F.2。 图片注5:错误响应补充说明当设备收到无法满足的SDP时,向发送的Invite请求方发送488错误响应消息;当设备不能满足更多的呼叫请求时,向发送的Invite请求方发送486错误响应消息。 以下就以Android平台GB28181设备接入模块,语音广播这块为例:当收到GB28181平台端的语音广播请求后,客户端做出响应,并在ntsOnNotifyBroadcastCommand()回调做出相应的处理
、心跳保活、设备状态通知、流媒体会话协商(INVITE/ACK/BYE)等完整流程; 可与主流国标平台(天网、雪亮、星火、融媒体中心等)实现无缝对接; 接入后可被平台像普通摄像头一样调用、录像、回放 ✅ 5. ✅ 模块能力概览表:能力模块支持情况补充说明SIP 信令流程✅ 注册 / 心跳 / 目录 / INVITE / BYE兼容国标流程视频源接入✅ RTSP / RTMP / H.264 / H.265支持软硬解码及码率调节音频支持 INVITE → 建立媒体流通道 → 回 ACK,开始视频推送流程BYE 回收支持平台挂断后终止推送,回收资源、释放内存该流程已在全国各类雪亮工程、公安指挥平台、NVR系统中完成过大量兼容测试,稳定可靠 ✅ 5.
通常工业级的IPC一般支持onvif,GB28181以及各厂家私有协议。上篇文章我们讲解如何通过onvif协议对接IPC,本文接下来介绍如何接入通过国内最主流的GB28181协议对接IPC。 对于GB28181协议内容细节不多介绍,他是国家公安部定义的安防设备互通的协议,细节详见《GBT28181-2016 公共安全视频监控联网系统信息传输、交换、控制技术要求.pdf》。 目前城市街道,公共场所,社区等各个安防设备基本都是通过GB28181在协议互通。如IPC,NVR,媒体网关等。本文以大华IPC为例子,直接上代码,演示如何通过GB28181协议将视频流拉下来。 通道编码:跟设备编号一致即可 其他选项暂时默认即可 二 接入方案 因为GB28181信令是基于SIP协议的一个应用,本文采用eXosip开源方案作为GB28181的协议栈完成接入。 \n" "a=control:trackID=1\r\n" "a=mpeg4-esid:3\r\n" "a=fmtp:97 streamtype=5;
本文旨在讲如何实现无人机(如大疆无人机)数据到GB28181平台(如海康、大华、宇视等国标平台)。 当国标平台端,需要查看无人机的实时画面时,可以发送Invite,请求无人机画面,Android平台GB28181接入模块,这时启动拉取无人机回调数据,并完成数据投递,和H.264到PS到RTP的打包上传即可 GB28181 媒体流private void stopGB28181Stream() { if(! 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