- 收藏
- 点赞
- 分享
- 举报
想写一个开源的基于onvif协议的C++版本的搜索IPC rtsp地址的工具,希望大家参与
[i=s] 本帖最后由 ngswfx 于 2016-7-10 05:04 编辑 [/i]
主要是嫌弃onvif 使用soap方式搞出来的东西,太大,4.8M,即便压缩后,也占用flash约800K-1M(随压缩方法改变,有些差异),PC上没问题,嵌入式arm上有些紧张了。
准备开源,写好后,大家可以直接使用,但希望大家给点建议。
//////如果采用socket方式,直接建立连接,发送网络探测包,发送获取rtsp url关键步骤的几个数据包。由于仅仅获取得到url,这部分代码onvif协议估计不会变化太大,前端IPC变化也应该不会太快。很适合arm上使用,用于仅仅得到url流地址的场合。
返回的数据包,也只需重点过滤得到需要的信息即可。
把整个功能封装为一个独立的.so库当中,被其他程序调用,发现的结果通过回调送到应用层。能得到IPC的rtsp URL就是本so的主要目标。
/////////////由于代码部分只有linux网络等动作,以及一些提前准备好的string,我感觉产生的so应该可以控制在100K左右。
/////////////[color=Blue]/哪位搞过这个东西,给点建议。我感觉只要协议中是一次发送一个总包过去,就比较容易做,否则每次仅仅发送一个片段,还不停交互信息,就没有这么做的意义了,太繁琐了[/color]
我初步计划这样: 1、首先通过抓包工具,探测onvif一次性发出哪些数据包,然后,把这些包,弄成一个char[4096],我也抛给IPC。通过接收返回的数据包,得到设备的xaddr。也就是得到http://192.168.2.22:8888/onvif这种地址。 2、接下来的几个步骤,还是通过抓包工具,获取每次发出的总数据包,直接保存为文件buff方式,放到代码里面,仿照onvif获取流地址的那几个步骤,也把这些包抛给IPC,直到得到rtsp url地址。
////////////////////////////[color=Red]进展:2016_7_4[/color] [color=Blue]//使用抓包工具,以及onvif manager tools等等,搜索设备以及走了一下几个关键的流程。还不错,虽然有些地方有些难度,但总的来说发送出去的是整体包,返回的也是一个个的整体包。 //应该还是可以做的。 感觉现在的难点主要集中在密码这方面: 1、通过搜索设备时probe的到设备的厂商或者型号信息,需要得到设备的默认用户名密码(有些IPC牌子,这个用户名密码可能必须填写正确,才能得到URL),至于海康这种暂不知道怎么弄,他的密码不是默认的,会比较麻烦(过几天再试试HK IPC)。对于其他厂商的,这个就比较好弄。因为这个用户名密码随后的命令里面要用到。 2、通过很onvif相同的方式,计算发出数据包里面密码相关的部分,进行替换。[/color] //////////////
/////////[color=Red]2016_7_10[/color]
//[color=Blue]编写验证程序,通过广播方式,向"239.255.255.250" 3702 发送2组整体探索包,仿照onvif client tools每种连续发2次,[/color]
[code]
char strFoundCMD_A[]={
"<?xml version=\"1.0\" encoding=\"utf-8\"?><Envelope xmlns:tds=\"http://www.onvif.org/ver10/device/wsdl\" xmlns=\"http://www.w3.org/2003/05/soap-envelope\">
char strFoundCMD_B[]={
"<?xml version=\"1.0\" encoding=\"utf-8\"?><Envelope xmlns:dn=\"http://www.onvif.org/ver10/network/wsdl\" xmlns=\"http://www.w3.org/2003/05/soap-envelope\">
//////////////[color=Blue]已经可以收到类似于:XAddrs:http://192.168.2.65/onvif/device_service的地址。也就是说,设备搜索第一步已经完成,onvif client tools能搜索到的设备,这里也都搜索到了。到这里还比较顺利,接下来的GetServices暂准备先做不带验证的,先把整体结构框架弄出来,先避开带验证的难点 ,不要一开始就把自己吓死了[/color]
[color=Red]第二交互命令GetService:[/color]
目标端口8899,发送479数据 [code]POST /onvif/device_service HTTP/1.1 Host: 192.168.2.127 Content-Type: application/soap+xml; charset=utf-8 Content-Length: 347
<?xml version="1.0" encoding="utf-8"?>
既然这么容易,干脆直接发送最后一个GetStreamUrl得了。[/color] [color=Red]跳过第3交互命令getporfile[/color]
[code]POST /onvif/Media HTTP/1.1 Host: 192.168.2.142 Content-Type: application/soap+xml; charset=utf-8 Content-Length: 289
<?xml version="1.0" encoding="utf-8"?>
//////////////[color=Red]//第4交互命令请求stream url[/color] [code]POST /onvif/Media HTTP/1.1 Host: 192.168.2.127 Content-Type: application/soap+xml; charset=utf-8 Content-Length: 523
<?xml version="1.0" encoding="utf-8"?>
[color=Blue]/////////////////////通过检查返回的数据包,还真有rtsp地址:呵呵,XM的[/color] SendBuff:640 rcv bk nbytes:3086 [color=Blue]GetStreamUrl rtsp:://192.168.2.142:554/user=admin_password=tlJwpbo6channel=1 ......[/color]
/////////////[color=Blue]到此,整个流程基本完毕。看来对于没有强制进行用户验证的设备来说,这种方式,获取rtsp地址,真的很容易。[/color]
//////////XM 端口8899的整个流程已经OK了,由于发送出的的包都是按照XM做的,这当然最容易了。 /////////ZW的端口80,GetServices 以及GetProfiles过程都很正常,GetStreamUrl返回异常,估计是发送出去的包不太一样。
///////HK的端口80,GetServices,在返回数据里面包含了设备型号以及需要认证的信息。看来需要按照提示做摘要认证才行。
///////HB的端口8888,没有返回数据,明显有验证流程
///////DH的端口80,GetServices GetProfiles 都正常,GetStreamUrl只要把profile token设置正确,RTSP地址已经得到。
///////////////其实对于特殊端口号而言,rtsp的URL我们其实是知道的,再把这些流程走一边,主要由于厂商可能会调整这个地址。
[color=Red]//////////经过简单的分析,发现不同厂家在描述profile token是不太一样,XM的是000 ,ZW的是MainStreamToken ,DH的是MediaProfile000,经过简单修改GetStreamUrl里面的实现,然后把组合包扔出去,返回数据包解析rtsp字眼。 目前可以成功获取的IPC的厂家有:DH XM ZW,呵呵,看来方法还可以呀,只需要分析出GetProfiles返回的内容中,关于profile token的值即可 [/color]
[color=Red]做到这里,整个执行程序才30K大小(没有依赖任何onvif的库噢),呵呵,看来值得弄下去,流程思路还比较正确,这种方法应该可行,有完成的必要,这样看来,最后作完兼容性较好的so文件,估计能控制到200K以内。[/color]
///////////////接下来做支持认证的:不过这里有个难题,如果设备密码是默认的,我们可以尝试用默认厂商的密码,进行后面的过程,应该可以得到RTSP URL,但如果对于HK这种,就显的意义不是很大了。通过80端口,以及GetServices 和GetProfiles的返回信息, 已经足够定位这是HK的IPC了,由于密码变化范围太大,获取rtsp就显得没有必要了,说白了,我们已经知道了。对于HB设备而言,密码是固定的,做一下也无妨,最起码可以避免厂家中途改rtsp地址。
HK GetProfiles返回信息,提示需要认证,设备型号作为认证的realm了。做认证不难,难在不知道密码。呵呵。 [code]HTTP/1.1 401 Unauthorized Date: Fri, 08 Jul 2016 01:16:29 GMT Server: App-webs/ Content-Length: 218 Content-Type: text/html Connection: close WWW-Authenticate: Digest qop="auth", realm="DS-2CD2T25D-I5", nonce="4d6b524252"
<!DOCTYPE html>
Access Error: 401 -- Unauthorized
Authentication Error: Access Denied! Authorization required.
[/code] //////////////////附件中是一个nptl100编译的搜索测试程序(应该没啥关联库,启动后,拍一下键盘开始搜索,结果都在控制台,再拍键盘,继续搜索,ctrl+C强制退出)。代码太乱,都是验证代码,还没整理,暂拿不出手。:lol ///////等我把流程再处理一下,放到我的项目里面用一下先。Markdown 语法
- 加粗**内容**
- 斜体*内容*
- 删除线~~内容~~
- 引用> 引用内容
- 代码`代码`
- 代码块```编程语言↵代码```
- 链接[链接标题](url)
- 无序列表- 内容
- 有序列表1. 内容
- 缩进内容
- 图片![alt](url)
-
2016-06-27 14:08:57
-
2019-01-22 11:49:16
-
2017-11-01 10:48:13
-
2014-11-08 11:05:37
-
2018-12-04 16:56:23
-
2020-02-16 20:43:16
-
2015-09-07 18:07:16
-
2023-11-26 11:27:41
-
2020-10-02 12:48:15
-
2015-01-19 22:11:42
-
2023-11-12 12:22:58
-
2015-01-05 21:26:10
-
2013-06-28 22:35:45
-
2018-01-31 22:05:02
-
2016-07-25 07:12:24
-
2020-02-16 12:25:28
-
2019-01-04 16:39:07
-
2015-02-11 14:12:32
-
2016-07-06 08:50:48
-
5Hi3516CV610 如何使用SD卡升级固件
-
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板子运行自己编码的程序
举报类型
- 内容涉黄/赌/毒
- 内容侵权/抄袭
- 政治相关
- 涉嫌广告
- 侮辱谩骂
- 其他
详细说明