GB28181媒体保活机制探究与实现

简介: GB28181-2016和GB28181-2022关于媒体保活机制这块,并无调整,平台、设备媒体流保活机制规定如下:a)链路建立后,码流经过的各级平台应具备媒体流丢失监测能力,若监测到媒体流丢失,应释放该条媒体链路,并通过会话内Bye消息通知上下级平台;

规范解读

GB28181-2016和GB28181-2022关于媒体保活机制这块,并无调整,平台、设备媒体流保活机制规定如下:


a)链路建立后,码流经过的各级平台应具备媒体流丢失监测能力,若监测到媒体流丢失,应释放该条媒体链路,并通过会话内Bye消息通知上下级平台;


b)上下级平台之间、平台与设备之间、平台与客户端之间应通过注册,状态信息报送等进行状态监测,若监测到媒体流接收方或媒体流发送方故障或离线,应主动释放媒体链路,停止媒体流的发送;


c)通过Subject标识进行已发送流的清理判断。上级平台向下级平台、平台向设备发送呼叫请求时,应携带Subject头域,Subject头域的“媒体流发送者ID:发送方媒体流序列号”用于对媒体源标识,此标识与请求的码流具有对应关系。下级平台,设备在接收到呼叫请求后,应判断是否在发送以此媒体源标识的码流,若已经在发送,则应释放现有媒体流发送链路并按照请求建立新的媒体流发送链路。

技术实现

本文以大牛直播SDK的Android平台GB28181设备接入模块为例,启动GB28181即注册到国标平台侧,并按照周期发送信条信令:

8174f5637959c9c0c3df26bb56f4267c.png

心跳相关的参数设置如下:

private int gb28181_reg_expired_           = 3600; // 注册有效期时间最小3600秒
private int gb28181_heartbeat_interval_    = 20; // 心跳间隔GB28181默认是60, 目前调整到20秒
private int gb28181_heartbeat_count_       = 3; // 心跳间隔3次失败,表示和服务器断开了

InitGB28181Agent()的时候,设置下去:

// GB28181配置
gb28181_agent_.config(gb28181_reg_expired_, gb28181_heartbeat_interval_, gb28181_heartbeat_count_);

心跳异常处理如下:

//Author: daniusdk.com
@Override
public void ntsOnHeartBeatException(int exceptionCount,  String lastExceptionInfo) {
    Log.e(TAG, "ntsOnHeartBeatException heart beat timeout count reached, count:" + exceptionCount+
            ", exception info:" + (lastExceptionInfo!=null?lastExceptionInfo:""));
    // 停止信令, 然后重启
    handler_.postDelayed(new Runnable() {
        @Override
        public void run() {
            Log.i(TAG, "gb28281_heart_beart_timeout");
            stopAudioPlayer();
            destoryRTPReceiver();
            if (gb_broadcast_source_id_ != null && gb_broadcast_target_id_ != null && gb28181_agent_ != null)
                gb28181_agent_.byeAudioBroadcast(gb_broadcast_source_id_, gb_broadcast_target_id_);
            gb_broadcast_source_id_ = null;
            gb_broadcast_target_id_ = null;
            btnGB28181AudioBroadcast.setText("GB28181语音广播");
            btnGB28181AudioBroadcast.setEnabled(false);
            stopGB28181Stream();
            destoryRTPSender();
            if (gb28181_agent_ != null) {
                gb28181_agent_.terminateAllPlays(true);
                Log.i(TAG, "gb28281_heart_beart_timeout sip stop");
                gb28181_agent_.stop();
                String local_ip_addr = IPAddrUtils.getIpAddress(context_);
                if (local_ip_addr != null && !local_ip_addr.isEmpty() ) {
                    Log.i(TAG, "gb28281_heart_beart_timeout get local ip addr: " + local_ip_addr);
                    gb28181_agent_.setLocalAddress(local_ip_addr);
                }
                Log.i(TAG, "gb28281_heart_beart_timeout sip start");
                gb28181_agent_.start();
            }
        }
    },0);
}

总结

GB28181媒体保活机制,相对比较清晰,不会有大的规范解读误区,感兴趣的开发者,可以参考实现。

相关文章
|
8月前
|
监控 前端开发 网络协议
GB/T 28181-2016多响应消息传输探究
我们在实现Android平台GB28181设备接入模块的时候,有遇到发送多条记录的情况,本文主要探讨下GB28181多响应传输。
|
8月前
|
开发工具 Android开发
Android平台GB28181设备接入端语音广播技术探究和填坑指南
GB/T28181-2016官方规范和交互流程,我们不再赘述。
|
6天前
|
Web App开发 编解码 监控
RTSP协议探秘:从原理到C++实践,解锁实时流媒体传输之道
RTSP协议探秘:从原理到C++实践,解锁实时流媒体传输之道
188 0
|
10月前
|
消息中间件 物联网
EMQ支不支持延迟消息, 如何实现
EMQ 是一个基于 Erlang/OTP 架构的开源物联网消息中间件(MQTT Broker)。目前的 EMQ 版本(截至 2023 年 7 月)不直接支持延迟消息。然而,你可以通过以下方法实现延迟消息的功能:
75 0
|
8月前
|
编解码 前端开发 算法
国网B接口语音对讲和广播技术探究及与GB28181差别
在谈国网B接口的语音广播和语音对讲的时候,大家会觉得,国网B接口是不是和GB28181大同小异?实际上确实信令有差别,但是因为要GB28181设备接入测的对接,再次做国网B接口就简单多了。
|
8月前
|
网络协议 前端开发 开发工具
GB28181基于TCP协议的视音频媒体传输探究及实现
我们先看看官方规范针对TCP协议的视音频传输描述: 实时视频点播、历史视频回放与下载的 TCP媒体传输应支持基于RTP封装的视音频PS流,封装格式参照IETFRFC4571。
104 0
|
网络协议 算法 小程序
即时通讯技术文集(第12期):网络保活、心跳机制等文章汇总 [共23篇]
为了更好地分类阅读52im.net 总计1000多篇精编文章,我将在每周三推送新的一期技术文集,本次是第12 期。
111 0
即时通讯技术文集(第12期):网络保活、心跳机制等文章汇总 [共23篇]
|
Web App开发 监控 算法
详解 WebRTC 高音质低延时的背后 — AGC(自动增益控制)
本文将结合实例全面解析 WebRTC AGC 的基本框架,一起探索其基本原理、模式的差异、存在的问题以及优化方向。
详解 WebRTC 高音质低延时的背后 — AGC(自动增益控制)
|
网络协议 算法 5G
万字长文:手把手教你实现一套高效的IM长连接自适应心跳保活机制
今天,我将通过本篇文章,手把手教大家实现一套可自适应的心跳保活机制,从而能高效稳定地维持诸如IM聊天这类需求的长连接。
360 0
万字长文:手把手教你实现一套高效的IM长连接自适应心跳保活机制
|
Web App开发 安全 网络协议
从客户端的角度来谈谈移动端IM的消息可靠性和送达机制
1、前言 IM App 是我做过 App 类型里复杂度最高的一类,里面可供深究探讨的技术难点非常之多。这篇文章和大家聊下从移动端客户端的角度所关注的IM消息可靠性和送达机制(因为我个人对移动客户端的经验积累的比较丰富嘛)。
3542 0