7961
- 收藏
- 点赞
- 分享
- 举报
网络视频监控P2P解决方案
一.摘要
本文分析了日益增长的民用级别家庭和个人网络视频监控市场的需求特点,并给出了一种经济可行易于大规模部署的P2P解决方案。
由于篇幅有限,本文只给出了方案的思路,未对更深入的技术细节做详细的论述,有兴趣的朋友可以继续深入研究。
二.关键词
IPCAM, P2P,NAT, STUN, TURN, ICE, PJSIP, OPENSIPS, UDT, TCP, UDP
三.需求提出
网络视频监控市场持续火爆升温,除了公共安全市场持续高速增长之外,民用市场中家庭和个人视频监控的需求近年也在逐渐增多。这主要得益于以下几点:
1. 网络视频监控产品的价格已经降低到个人很容易接受的程度。
2. 家庭宽带网络的逐步普及。
3. 3G网络的逐步普及。
家庭和个人监控的需求和传统的公共安全监控需求有明显的不同,其特点主要体现在以下几个方面:
1. 规模很小。通常是1台或者几台。
2. 无需专用的监控客户端,无需长时间监控。
3. 监控客户端和网络摄像机多位于不同的网络。比如网络摄像机在家中,用户通过公司的网络或者手机查看视频。
4. 不会多人同时查看一路视频,最多一两人同时看,且概率较小。
5. 无需连续长时间录像,多采用移动侦测或者其他告警触发录像,拍照,同时通过邮件,短信提醒。
四.技术难点
通过以上分析可以看出,家庭以及个人视频监控的需求和传统公共安防市场的需求有很大的不同,决定了其必须采用不同的技术路线和方案:
1. 网络摄像机和监控客户端(PC/手机)位于不同的网络,中间有防火墙隔离,无法像传统安防产品一样采用网络直连通过IP地址直接访问的方式。
2. 网络摄像机数量庞大(至少以万为单位),但分属多个用户。如果采用中央服务器转发的方案,需要互联网上部署相当数量的转发服务器,成本相当高。
3. 必须实现即插即用,不能让用户进行复杂的安装配置。否则售后服务的代价太高。
要实现位于不同网络里的大量网络摄像机和客户端点对点的访问,比较可行而且比较经济的方法是实现防火墙的穿透(NAT),让客户端和网络摄像机之间建立一个直接的数据传输通道,传输视频流和信令。
要实现NAT穿越,需要有一套机制,能够轻松的让客户端和网络摄像机之间能建立起联系,简单的说,就是让客户端能找到自己要访问的摄像机,然后去实现NAT穿越,进而可以访问视频和进行其他操作。
只有解决了上述两个技术难点,大规模部署P2P网络视频监控系统,才有可能实现。
五.解决方案
笔者经过深入的研究和分析,给出以下解决方案。
1. NAT的穿越
NAT的穿越并非安防监控领域的技术,是目前VOIP以及即时通信等产品的基础性技术,目前来讲已经比较成熟,且有完整的技术标准RFC,同时也有众多的实现方案,包括许多已经得到广泛应用的开源项目。
简单来讲,实现NAT的穿越是可能的,成功的概率也比较高。UDP的协议进行数据传输穿透NAT的成功率比较高,接近100%,TCP则存在一些情况无法实现穿越,主要受限路由器的端口映射机制。
要实现NAT穿越,需要有穿越控制服务器部署在互联网(有固定的域名或者IP),由该服务器来协助网络摄像机和客户端来实现NAT穿越。有些服务器还能在TCP不能穿越的情况下,实现RELAY(数据中继转发)的功能,以确保二者之间能实现数据通信。
由于NAT穿越控制服务器不同于安防监控系统中的媒体转发服务器,主要进行信令交互,不转发媒体数据,在协助打通数据通道之后,对应的网络摄像机和客户端就不会再占用服务器带宽和处理能力了,因此一台穿越控制服务器可以接入数量庞大的网络摄像机和客户端。
2. 网络摄像机和客户端之间的访问机制
通常网络摄像机都有唯一ID,并通过该ID注册到穿越控制服务器。客户端要访问对应的网络摄像机时,也需要先注册到穿越控制服务器,并提交对应网络摄像机的ID,由穿越控制服务器查找对应的网络摄像机,并协助网络摄像机和客户端之间进行NAT穿越,最后打通一个点对点的数据传输通道。之后,二者即可进行正常的媒体和信令交互了。
为实现更加有效的管理,服务器可对设备接入进行认证。此外,如果设备ID过长,也可以为设备建立别名,客户端访问时用设备别名作为参数,服务器来查找对应设备。
3. 数据传输机制
网络摄像机和客户端之间的数据传递包括有媒体流,信令流等。信令流数据量较小,媒体流数据量加大,而且需要有较好的实时性。
如果媒体流和信令流分开传输,需要打通多个通道,增加了复杂性和出错可能,同时增加了服务器的负担。
前面也讲过,UDP协议能有比较好的NAT穿透性,也比较适合媒体流的传输,但可靠性较差,不宜传输信令。为减轻服务器负担(避免TCP无法穿透需要转发),提高穿透成功率,笔者建议只打通一个UDP通道,利用该UDP通道封装媒体和信令流,在应用层加以区分,哪些是媒体流,那些是信令流。
由于UDP传输信令可靠性极差,即使是传输媒体数据,在互联网环境下肯定会出现丢包的情况,仍然会出现图像花屏或者解码出错的情况,因此必须要解决此问题。
好在此问题并非我们第一个提出,利用UDP协议进行可靠的数据传输的需求早就存在,并有了比较好的解决方案,那就是通过UDP协议在应用层实现数据的缓冲,序列化,重传,可靠性控制和拥塞控制。
如果上述三个问题都已解决,则网络视频监控的P2P方案已经基本实现,剩下的就是产品化的问题。以下笔者针对PC访问和手机访问分别给出简要的实现说明:
1. PC访问网络摄像机。
PC访问网络摄像机,可以先访问一个网页,传入网络摄像机的序列号。
网页加载一个控件,该控件通过NAT穿越控制服务器和该序列号对应的网络摄像机实现NAT穿透后,通过可靠的UDP传输信令和媒体数据。控件提供视频浏览,对讲,云台控制,参数查询设置等功能。
2. 手机访问网络摄像机。
手机由于平台的不同,需要单独开发对应的客户端或者插件以实现和PC访问类似功能。但原理是一样的,都需要通过NAT穿越控制服务器和该序列号对应的网络摄像机实现NAT穿透后,通过可靠的UDP传输信令和媒体数据。由于开源的NAT穿越库是可以移植的,在LINUX,WINCE,IOS, Android,Sbrian等都可以实现同样的NAT穿越功能。
六.实现建议
最后笔者给出几个技术方案的建议,有兴趣的朋友可以自己再去做深入研究,欢迎探讨。
1. NAT穿越库的选择,笔者推荐PJSIP,网路摄像机以及客户端都可以采用。
2. NAT穿越控制服务器的选择,笔者推荐OPENSIPS。
3. 可靠UDP传输方案的选择,推荐UDT。
本文分析了日益增长的民用级别家庭和个人网络视频监控市场的需求特点,并给出了一种经济可行易于大规模部署的P2P解决方案。
由于篇幅有限,本文只给出了方案的思路,未对更深入的技术细节做详细的论述,有兴趣的朋友可以继续深入研究。
二.关键词
IPCAM, P2P,NAT, STUN, TURN, ICE, PJSIP, OPENSIPS, UDT, TCP, UDP
三.需求提出
网络视频监控市场持续火爆升温,除了公共安全市场持续高速增长之外,民用市场中家庭和个人视频监控的需求近年也在逐渐增多。这主要得益于以下几点:
1. 网络视频监控产品的价格已经降低到个人很容易接受的程度。
2. 家庭宽带网络的逐步普及。
3. 3G网络的逐步普及。
家庭和个人监控的需求和传统的公共安全监控需求有明显的不同,其特点主要体现在以下几个方面:
1. 规模很小。通常是1台或者几台。
2. 无需专用的监控客户端,无需长时间监控。
3. 监控客户端和网络摄像机多位于不同的网络。比如网络摄像机在家中,用户通过公司的网络或者手机查看视频。
4. 不会多人同时查看一路视频,最多一两人同时看,且概率较小。
5. 无需连续长时间录像,多采用移动侦测或者其他告警触发录像,拍照,同时通过邮件,短信提醒。
四.技术难点
通过以上分析可以看出,家庭以及个人视频监控的需求和传统公共安防市场的需求有很大的不同,决定了其必须采用不同的技术路线和方案:
1. 网络摄像机和监控客户端(PC/手机)位于不同的网络,中间有防火墙隔离,无法像传统安防产品一样采用网络直连通过IP地址直接访问的方式。
2. 网络摄像机数量庞大(至少以万为单位),但分属多个用户。如果采用中央服务器转发的方案,需要互联网上部署相当数量的转发服务器,成本相当高。
3. 必须实现即插即用,不能让用户进行复杂的安装配置。否则售后服务的代价太高。
要实现位于不同网络里的大量网络摄像机和客户端点对点的访问,比较可行而且比较经济的方法是实现防火墙的穿透(NAT),让客户端和网络摄像机之间建立一个直接的数据传输通道,传输视频流和信令。
要实现NAT穿越,需要有一套机制,能够轻松的让客户端和网络摄像机之间能建立起联系,简单的说,就是让客户端能找到自己要访问的摄像机,然后去实现NAT穿越,进而可以访问视频和进行其他操作。
只有解决了上述两个技术难点,大规模部署P2P网络视频监控系统,才有可能实现。
五.解决方案
笔者经过深入的研究和分析,给出以下解决方案。
1. NAT的穿越
NAT的穿越并非安防监控领域的技术,是目前VOIP以及即时通信等产品的基础性技术,目前来讲已经比较成熟,且有完整的技术标准RFC,同时也有众多的实现方案,包括许多已经得到广泛应用的开源项目。
简单来讲,实现NAT的穿越是可能的,成功的概率也比较高。UDP的协议进行数据传输穿透NAT的成功率比较高,接近100%,TCP则存在一些情况无法实现穿越,主要受限路由器的端口映射机制。
要实现NAT穿越,需要有穿越控制服务器部署在互联网(有固定的域名或者IP),由该服务器来协助网络摄像机和客户端来实现NAT穿越。有些服务器还能在TCP不能穿越的情况下,实现RELAY(数据中继转发)的功能,以确保二者之间能实现数据通信。
由于NAT穿越控制服务器不同于安防监控系统中的媒体转发服务器,主要进行信令交互,不转发媒体数据,在协助打通数据通道之后,对应的网络摄像机和客户端就不会再占用服务器带宽和处理能力了,因此一台穿越控制服务器可以接入数量庞大的网络摄像机和客户端。
2. 网络摄像机和客户端之间的访问机制
通常网络摄像机都有唯一ID,并通过该ID注册到穿越控制服务器。客户端要访问对应的网络摄像机时,也需要先注册到穿越控制服务器,并提交对应网络摄像机的ID,由穿越控制服务器查找对应的网络摄像机,并协助网络摄像机和客户端之间进行NAT穿越,最后打通一个点对点的数据传输通道。之后,二者即可进行正常的媒体和信令交互了。
为实现更加有效的管理,服务器可对设备接入进行认证。此外,如果设备ID过长,也可以为设备建立别名,客户端访问时用设备别名作为参数,服务器来查找对应设备。
3. 数据传输机制
网络摄像机和客户端之间的数据传递包括有媒体流,信令流等。信令流数据量较小,媒体流数据量加大,而且需要有较好的实时性。
如果媒体流和信令流分开传输,需要打通多个通道,增加了复杂性和出错可能,同时增加了服务器的负担。
前面也讲过,UDP协议能有比较好的NAT穿透性,也比较适合媒体流的传输,但可靠性较差,不宜传输信令。为减轻服务器负担(避免TCP无法穿透需要转发),提高穿透成功率,笔者建议只打通一个UDP通道,利用该UDP通道封装媒体和信令流,在应用层加以区分,哪些是媒体流,那些是信令流。
由于UDP传输信令可靠性极差,即使是传输媒体数据,在互联网环境下肯定会出现丢包的情况,仍然会出现图像花屏或者解码出错的情况,因此必须要解决此问题。
好在此问题并非我们第一个提出,利用UDP协议进行可靠的数据传输的需求早就存在,并有了比较好的解决方案,那就是通过UDP协议在应用层实现数据的缓冲,序列化,重传,可靠性控制和拥塞控制。
如果上述三个问题都已解决,则网络视频监控的P2P方案已经基本实现,剩下的就是产品化的问题。以下笔者针对PC访问和手机访问分别给出简要的实现说明:
1. PC访问网络摄像机。
PC访问网络摄像机,可以先访问一个网页,传入网络摄像机的序列号。
网页加载一个控件,该控件通过NAT穿越控制服务器和该序列号对应的网络摄像机实现NAT穿透后,通过可靠的UDP传输信令和媒体数据。控件提供视频浏览,对讲,云台控制,参数查询设置等功能。
2. 手机访问网络摄像机。
手机由于平台的不同,需要单独开发对应的客户端或者插件以实现和PC访问类似功能。但原理是一样的,都需要通过NAT穿越控制服务器和该序列号对应的网络摄像机实现NAT穿透后,通过可靠的UDP传输信令和媒体数据。由于开源的NAT穿越库是可以移植的,在LINUX,WINCE,IOS, Android,Sbrian等都可以实现同样的NAT穿越功能。
六.实现建议
最后笔者给出几个技术方案的建议,有兴趣的朋友可以自己再去做深入研究,欢迎探讨。
1. NAT穿越库的选择,笔者推荐PJSIP,网路摄像机以及客户端都可以采用。
2. NAT穿越控制服务器的选择,笔者推荐OPENSIPS。
3. 可靠UDP传输方案的选择,推荐UDT。
我来回答
回答6个
时间排序
认可量排序
认可0
认可0
认可0
认可0
认可0
认可0
或将文件直接拖到这里
悬赏:
E币
网盘
* 网盘链接:
* 提取码:
悬赏:
E币
Markdown 语法
- 加粗**内容**
- 斜体*内容*
- 删除线~~内容~~
- 引用> 引用内容
- 代码`代码`
- 代码块```编程语言↵代码```
- 链接[链接标题](url)
- 无序列表- 内容
- 有序列表1. 内容
- 缩进内容
- 图片![alt](url)
相关问答
-
2018-06-01 15:34:24
-
2017-11-29 21:57:36
-
22017-12-30 16:51:28
-
2018-09-17 09:51:08
-
2015-05-10 17:51:08
-
2019-12-02 11:19:04
-
2017-11-29 01:47:40
-
2020-11-21 09:55:11
-
2017-04-03 18:02:22
-
2014-12-23 15:08:49
-
2017-02-09 15:51:56
-
2017-06-14 13:41:43
-
2019-02-12 10:25:13
-
2015-09-05 18:32:24
-
2018-11-30 08:57:03
-
2019-04-11 10:37:41
-
2017-07-14 20:01:42
-
2015-04-16 17:07:39
-
2015-03-14 13:06:32
无更多相似问答 去提问
点击登录
-- 积分
-- E币
提问
—
收益
—
被采纳
—
我要提问
切换马甲
上一页
下一页
悬赏问答
-
5cat /dev/logmpp 报错 <3>[ vi] [func]:vi_send_frame_node [line]:99 [info]:vi pic queue is full!
-
50如何获取vpss chn的图像修改后发送至vo
-
5FPGA通过Bt1120传YUV422数据过来,vi接收不到数据——3516dv500
-
50SS928 运行PQtools 拼接 推到设备里有一半画面会异常
-
53536AV100的sample_vdec输出到CVBS显示
-
10海思板子mpp怎么在vi阶段改变视频数据尺寸
-
10HI3559AV100 多摄像头同步模式
-
9海思ss928单路摄像头vio中加入opencv处理并显示
-
10EB-RV1126-BC-191板子运行自己编码的程序
-
10求HI3519DV500_SDK_V2.0.1.1
举报反馈
举报类型
- 内容涉黄/赌/毒
- 内容侵权/抄袭
- 政治相关
- 涉嫌广告
- 侮辱谩骂
- 其他
详细说明
提醒
你的问题还没有最佳答案,是否结题,结题后将扣除20%的悬赏金
取消
确认
提醒
你的问题还没有最佳答案,是否结题,结题后将根据回答情况扣除相应悬赏金(1回答=1E币)
取消
确认