在WFD交互过程中,在Source端或者Sink端抓取tcpdump,通过数据包分析软件Wireshark或者Omnipeek即可以直观的分析RTSP协议交互的过程。


目录

  • 0.准备
  • 1.抓包
  • 2.包过滤
  • 3.包分析
    • 3.1 RTSP M1 Message
      • M1 Request
      • M1 Response
    • 3.2 RTSP M2 Message
      • M2 Request
      • M2 Response
    • 3.3 RTSP M3 Message
      • M3 Request
      • M3 Response
    • 3.4 RTSP M4 Message
      • M4 Request
      • M4 Response
    • 3.5 RTSP M5 Message
      • M5 Request
      • M5 Response
    • 3.6 RTSP M6 Message
      • M6 Request
      • M6 Response
    • 3.7 RTSP M7 Message
      • M7 Request
      • M7 Response

关于WFD协议和代码追踪请参考阅读:
Wi-Fi Display协议介绍
WFD连接过程代码分析(Sink端)

0.准备

本次分析过程在Sink端抓取tcpdump,通过Wireshark软件分析RTSP交互M1~M7消息交互

  • Source端设备->Android Phone
  • Sink端设备->Android TV
  • Wireshark包分析软件

1.抓包

在Source端抓取tcpdump

adb shell
tcpdump -i any -s 0 -w /data/vendor/wifi/file.pcap
adb pull /data/vendor/wifi/file.pcap ./
//注:
//-i any 表示抓取所有接口(waln0、p2p0等)
//data/vendor/wifi/file.pcap 为设备端存储的路径

2.包过滤

使用Wireshark打开file.pcap,在Filter(过滤器)输入过滤条件

ip.addr==192.168.49.1 and rtsp
//注:
//ip.addr==192.168.49.1 为WiFi P2P连接GO(Group Owner)的IP地址,此处搜索GC(Group Client)的IP地址192.168.49.141也可以
//rtsp 为协议类型

3.包分析

下列图中

  • Source端IP地址为192.168.49.1(承担P2P GO角色)
  • Sink端IP地址为192.168.49.141(承担P2P GC角色)

3.1 RTSP M1 Message

WFD RTSP交互开始于WFD Source端发送M1,M1 Message属于固定交互模式,Source端发送Request给Sink端,Sink端收到后回复Response。

M1 Request

如下图所示,Source发送给Sink在消息体里面包含

  • Request: OPTIONS * RTSP/1.0\r\n 用于标记此条消息的用途是询问对方options
  • CSeq:1\r\n 由发送者分配,用于计数(标记)Source端发送的Request消息
  • Server: AllShareCast/Galaxy/3.2/NIBC\r\n
  • Require: org.wfa.wfd1.0\r\n 作为tag,用于询问对方支持的WFD options


注:WFD协议规定每一个字段都以“\r\n”结尾

M1 Response

如下图所示,Sink发送给Source在消息体里面包含

  • Response: RTSP/1.0 200 OK\r\n 状态码200用于接收成功
  • Date: Tue, 19 Nov 2019 12:35:04 +0000\r\n 时间信息
  • User-Agent: stagefright/1.1 (Linux;Android 4.1)\r\n
  • CSeq: 1\r\n 回复Request发送过来的CSeq值,用于标明是对CSeq=1这条消息的回复
  • Public: org.wfa.wfd1.0, GET_PARAMETER, SET_PARAMETER\r\n 协议中标明Sink端在接收到Source端Request消息后固定的答复内容

3.2 RTSP M2 Message

当M1交互完成后,开始M2交互,也属于固定交互模式,Sink端发送Request给Source端,Source端收到后回复Response

M2 Request

如下图所示,Sink发送给Source在消息体里面包含

  • Request: OPTIONS * RTSP/1.0\r\n 用于标记此条消息的用途是询问对方options
  • Date: Tue, 19 Nov 2019 12:35:04 +0000\r\n 时间信息
  • User-Agent: stagefright/1.1 (Linux;Android 4.1)\r\n
  • CSeq: 1\r\n 由发送者分配,用于计数(标记)Sink端发送的Request消息
  • Require: org.wfa.wfd1.0\r\n 作为tag,用于询问对方支持的WFD options

M2 Response

如下图所示,Source发送给Sink在消息体里面包含

  • Respose: RTSP/1.0 200 OK\r\n 状态码200用于接收成功
  • CSeq: 1\r\n 回复Request发送过来的CSeq值,用于标明是对CSeq=1这条消息的回复
  • Public: org.wfa.wfd1.0, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER\r\n 协议中标明Source端在接收到Sink端Request消息后固定的答复内容

3.3 RTSP M3 Message

M1和M2交互类似日常见面的打招呼,你Hi一句,我点个头回复一句Hello。接下来进行的M3交互,询问Sink端的能力和支持的功能。

M3 Request

如下图所示,Source发送给Sink在消息体里面包含

  • Request: GET_PARAMETER rtsp://localhost/wfd1.0 RTSP/1.0\r\n 用于标明获取Sink端的参数
  • CSeq: 2\r\n 用于标注Source发出的第二条Request
  • Content-type: text/parameters 用于标明消息体中包含parameters
  • Content-length: 338 表示parameters长度
  • Line-based text data: text/parameters (15 lines) 下面列出具体的参数
    • wfd_video_formats\r\n 视频格式
    • wfd_audio_codecs\r\n 音频格式
    • … …

M3 Response

如下图所示,Sink发送给Source在消息体里面包含

  • Response: RTSP/1.0 200 OK\r\n 状态码200用于接收成功
  • Date: Tue, 19 Nov 2019 12:35:04 +0000\r\n 时间信息
  • User-Agent: stagefright/1.1 (Linux;Android 4.1)\r\n
  • CSeq: 2\r\n 回复Request发送过来的CSeq值,用于标明是对CSeq=2这条消息的回复
  • Content-type: text/parameters
  • Content-length: 327
  • Line-based text data: text/parameters (8 lines)
    • wfd_video_formats: 48 00 02 02 0001DEFF 157C7FFF 00000FFF 00 0000 0000 00 none none\r\n 视频编码格式
    • wfd_audio_codecs: LPCM 00000003 00\r\n 音频编码格式
    • wfd_content_protection: none\r\n 不支持HDCP加密
    • wfd_coupled_sink: 00 none\r\n 不支持有主Sink和次Sink耦合
    • wfd_uibc_capability: none\r\n 不支持UIBC
    • wfd_standby_resume_capability: none\r\n 不支持standby
    • wfd_lg_dlna_uuid: none\r\n
    • wfd_client_rtp_ports: RTP/AVP/UDP;unicast 15550 0 mode=play\r\n Sink端RTP交互端口为15550

3.4 RTSP M4 Message

M3交互Source端了解到Sink端的编解码能力后,Source依据自身的能力和Sink端的能力决定使用编解码格式等,通过M4发送给Sink端,Sink端如果验证后支持,则回复ok,如不支持,则M3继续协商。

M4 Request

如下图所示,Source发送给Sink在消息体里面包含

  • Request: SET_PARAMETER rtsp://localhost/wfd1.0 RTSP/1.0\r\n 用于设置使用的音视频格式等
  • CSeq: 3\r\n 用于标注Source发出的第三条Request
  • Content-type: text/parameters
  • Content-length: 248
  • Line-based text data: text/parameters (4 lines)
    • wfd_video_formats: 00 00 02 02 00000080 00000000 00000000 00 0000 0000 00 none none\r\n 使用这个视频格式
    • wfd_audio_codecs: LPCM 00000002 00\r\n 使用这个音频格式
    • wfd_presentation_URL: rtsp://192.168.49.1/wfd1.0/streamid=0 none\r\n 用于设置WFD会话
    • wfd_client_rtp_ports: RTP/AVP/UDP;unicast 15550 0 mode=play\r\n

M4 Response

如下图所示,Sink发送给Source在消息体里面包含

  • Response: RTSP/1.0 200 OK\r\n 状态码200用于接收成功
  • Date: Tue, 19 Nov 2019 12:35:04 +0000\r\n
  • User-Agent: stagefright/1.1 (Linux;Android 4.1)\r\n
  • CSeq: 3\r\n 回复Request发送过来的CSeq值,用于标明是对CSeq=3这条消息的回复

3.5 RTSP M5 Message

M4交互完毕后,开始建立WFD会话,即M5的交互

M5 Request

如下图所示,Source发送给Sink在消息体里面包含

  • Request: SET_PARAMETER rtsp://localhost/wfd1.0 RTSP/1.0\r\n
  • CSeq: 4\r\n 用于标注Source发出的第四条Request
  • Content-type: text/parameters
  • Content-length: 27
  • Line-based text data: text/parameters (1 lines)
    • wfd_trigger_method: SETUP\r\n 开始WFD会话建立

M5 Response

如下图所示,Sink发送给Source在消息体里面包含

  • Response: RTSP/1.0 200 OK\r\n 状态码200用于接收成功
  • Date: Tue, 19 Nov 2019 12:35:04 +0000\r\n 时间信息
  • User-Agent: stagefright/1.1 (Linux;Android 4.1)\r\n
  • CSeq: 4\r\n 回复Request发送过来的CSeq值,用于标明是对CSeq=4这条消息的回复

3.6 RTSP M6 Message

M5后,Sink端给Source端发送M6 Request

M6 Request

如下图所示,Sink发送给Source在消息体里面包含

  • Request: SETUP rtsp://192.168.49.1/wfd1.0/streamid=0 RTSP/1.0\r\n
  • Date: Tue, 19 Nov 2019 12:35:04 +0000\r\n 时间信息
  • User-Agent: stagefright/1.1 (Linux;Android 4.1)\r\n
  • CSeq: 2\r\n 用于标注Sink发出的第二条Request
  • Transport: RTP/AVP/UDP;unicast;client_port=15550-15551 Sink端RTP交互端口为15550,RTCP交互端口为15551

M6 Response

如下图所示,Source发送给Sink在消息体里面包含

  • Response: RTSP/1.0 200 OK\r\n 状态码200用于接收成功
  • CSeq: 2\r\n 回复Request发送过来的CSeq值,用于标明是对CSeq=2这条消息的回复
  • Session: 1957747793;timeout=30 标明会话ID为1957747793和超时
  • Transport: RTP/AVP/UDP;unicast;client_port=15550-15551;server_port=19000-19001 //重述Client(Sink)端的端口,并标明Source(Server)RTP交互端口为19000,RTCP交互端口为19001

3.7 RTSP M7 Message

M6交互完毕后,M7告知Source端一切准备就绪,开始发送数据

M7 Request

如下图所示,Sink发送给Source在消息体里面包含

  • Request: PLAY rtsp://192.168.49.1/wfd1.0/streamid=0 RTSP/1.0\r\n
  • Date: Tue, 19 Nov 2019 12:35:06 +0000\r\n
  • User-Agent: stagefright/1.1 (Linux;Android 4.1)\r\n
  • CSeq: 3\r\n 用于标注Sink发出的第三条Request
  • Session: 1957747793

M7 Response

如下图所示,Source发送给Sink在消息体里面包含

  • Response: RTSP/1.0 200 OK\r\n 状态码200用于接收成功
  • CSeq: 3\r\n 回复Request发送过来的CSeq值,用于标明是对CSeq=3这条消息的回复
  • Session: 1957747793;timeout=30
  • Range: npt=now-\r\n

综上所述

Message Method Direct 简述 重点
M1 OPTIONS Source -> Sink 打招呼
M2 OPTIONS Source <- Sink 打招呼
M3 GET_PARAMETER Source -> Sink 你支持什么音视频格式 wfd_video_formats/wfd_audio_codecs
M4 SET_PARAMETER Source -> Sink 我们使用这个格式吧
M5 SETUP Source -> Sink 建立连接吧
M6 SETUP Source <- Sink 建立连接吧 client_port/server_port/Session ID
M7 PLAY Source <- Sink 开始发送数据吧

在M1-M7交互完毕,开始传输音视频数据过程中,由于一些外部原因(信号强弱)或者内部原因双方会动态调整使用的音视频格式,所以还有可能会交互GET_PARAMETER如下图所示,这里不再敖述。

参考:
【1】《Wi-Fi_Display_Technical_Specification_v2.1_0》

WFD_RTSP交互包分析相关推荐

  1. C++/Qt音视频通话开发MetaRTC源码解读,dtls交互流程,dtls抓包分析

    目录 dtls抓包分析 dtls流程,主叫发送Client Hello dtls流程,Application Data dtls流程,Encrypted Alert 本章内容解读MetaRTC开源代码 ...

  2. DNS抓包分析--wireshark

    DNS抓包分析–wireshark DNS-(Domain Name System,域名系统),是因特网上作为余名和IP地址相互映射的一个分布式数据库,能够使用户更加方便地访问互联网,而不是去记住能够 ...

  3. Wireshark 抓包分析 RTSP/RTP/RTCP 基本工作过程

    整体而言,RTSP 通常工作于可靠的传输协议 TCP 之上,就像 HTTP 那样,用于发起/结束流媒体传输,交换流媒体元信息.RTP 通常工作于 UDP 之上,用于传输实际的流媒体数据,其中的载荷格式 ...

  4. Wireshark数据包分析(一)——使用入门

    Wireshark简介: Wireshark是一款最流行和强大的开源数据包抓包与分析工具,没有之一.在SecTools安全社区里颇受欢迎,曾一度超越Metasploit.Nessus.Aircrack ...

  5. MQTT服务质量等级及抓包分析

    什么是服务质量? 服务质量(QualityofService,QoS)等级是消息发送方与消息接收方之间的协议,对应着消息传递时不同的可靠程度. MQTT有三种QoS等级: 至多一次(QoS 0) 至少 ...

  6. 《Wireshark数据包分析实战(第2版)》目录—导读

    版权声明 Wireshark数据包分析实战(第2版) Copyright © 2011 by Chris Sanders. Title of English-language original:Pra ...

  7. wireshark Fiddler抓包分析与解密https Fiddler修改https请求和响应

    Https理论 在说HTTPS之前先说说什么是HTTP,HTTP就是我们平时浏览网页时候使用的一种协议.HTTP协议传输的数据都是未加密的,也就是明文的,因此使用HTTP协议传输隐私信息非常不安全.为 ...

  8. 如何抓包分析BLE 空口报文(GAP + GATT + LESC procedure)?

    文章目录 一.如何抓取BLE 空口报文? 二.BLE 通信报文是如何交互的? 2.1 GAP Discovery and Connection establishment procedures 2.2 ...

  9. linux服务器抓包分析,抓包分析SSL/TLS连接建立过程总结

    1.前言 最近在倒腾SSL方面的项目,之前只是虽然对SSL了解过,但是不够深入,正好有机会,认真学习一下.开始了解SSL的是从https开始的,自从百度支持https以后,如今全站https的趋势越来 ...

最新文章

  1. 26 页高清大数据开发代码速查表,提升效率必备!【可下载】
  2. 微服务架构的优势与不足(二)
  3. Linux解压rar、zip、war、tar文件
  4. PostgreSQL 10.1 手册_部分 II. SQL 语言_第 5 章 数据定义_5.5. 修改表
  5. textview加载html glide,TextView加载HTML,文字和图片
  6. 整型与布尔型的转换(信息学奥赛一本通-T1022)
  7. html的标签位置属性(学习笔记)
  8. 龙将加速浏览器_《使命召唤16》及战区迎来万圣节限时活动,迅游加速器助力流畅体验 18183手机游戏网...
  9. 如何修改Window系统下PATH路径
  10. 关于property grid下拉框的定制
  11. 基于51单片机的循迹小车(初学者必备!!!)
  12. roboware下载链接
  13. 直连路由、主机路由以及选择顺序
  14. P3855 [TJOI2008]Binary Land
  15. ubuntu20.04安装向日葵
  16. matlab解决阻尼牛顿,matlab阻尼牛顿法例题
  17. Nginx如何跳转到非443端口的https
  18. 如何用mac自带软件录屏且录制屏内屏外声音
  19. 关于videojs视频加载重试
  20. WiFi 射频测试指标学习之路

热门文章

  1. WiFi功耗管理(一)(概述)
  2. 关于文件内搜索的软件
  3. 中小企业常遇到这些问题,看APS系统是如何解决的
  4. [1]深入浅出工作开源框架Camunda: 安装和使用
  5. python+tkinter+threading制作多线程简易音乐播放器(自动播放,上一曲,下一曲,播放,暂停,实时显示歌曲名并能自动切换歌曲的功能)
  6. 微信公众号开发系统入门教程之公众号与小程序、APP的区别
  7. 栈的push,pop序列
  8. 华为有望解决5G射频芯片问题,5G手机或将回归
  9. Android 上面实现红外解析(NEC编码)
  10. AppScan渗透测试