成都电信 IPTV 内网融合方案问题请教

2022-05-26 15:49:47 +08:00
 BetaXO
当前方案:

路由器上一个 WAN 口连互联网,一个 WAN 口连光猫 ITV 口做 IPTV 的 IPOE 认证并成功拿到 IP ,LAN 口接机顶盒和内网其他设备
路由器上 igmpproxy 转发组播到内网,udproxy 组播转单播
mwan3 做策略路由

当前效果:

1. 机顶盒能看**直播**,但换台很慢,大概需要 2~3 秒,如果机顶盒直接接光猫 ITV 口,换台在 1 秒内
2. 内网设备可以使用单播看**直播**
3. 机顶盒**不能**看**回看**( RTSP )机顶盒默认是使用 UDP 来承载 RTP 流的,似乎基于 UDP 的 RTSP 无法穿透内网
4. 内网 PC 可以使用 PotPlayer 看**回看**,默认使用 TCP 来承载 RTP 流
5. 机顶盒能看**点播**,同时路由上可以抓取到资源链接
6. 内网设备可以通过抓取到的资源链接看**点播**

待解决问题:

1. 机顶盒**直播**换台慢
2. 机顶盒**不能**看**回看**

请教各位 V 友,有这方面的经验么?
特别是当前机顶盒**不能**看**回看**的问题,请各位帮忙分析下问题原因

在 WAN 口抓包初步分析了下

1. 机顶盒(客户端)在打开**回看**时,发送完 RTSP 的**SETUP**指令时,会携带`x-NAT_address: 192.168.*.*`信息

```
47 0.382573 10.81.121.127 118.123.56.184 RTSP 1088 SETUP rtsp://118.123.56.184:554/TVOD/88888893/224/3221226889/10000100000000060000000000622347_0.smil?playseek=20220520120000-20220520123600&rrsip=118.123.185.42&zoneoffset=480&recType=1&icpid=HWC1TOOL&accounttype=1&limitflux=-1&limitdur=-1&tenantId=8601&accountinfo=%2C8605058%2C10.81.121.127%2C20220520134801%2CUmai%3ASCHE%2F14673475%40BESTV.SMG.SMG%2C860505820220520105910%2C-1%2C1%2C300%2C-1%2C%2C4%2C100010004671%2C0ee9cbc861ca406e990c%2C%2C5%2CEND&GuardEncType=2&from=200&hms_devid=22724&it=H4sIAAAAAAAAAyspSkxO9XSxzSvNyVErTi30y7c1VktOzMnJzEv3y08BSYUFO8cbWhjpGRpb6JmY6hlbqIWANLnlJKbbGoDV-pXmJqUWQTlAjcGpRWWZyam2KcVpegU5iZWlRTl6xQWZYHZoUQ5UGgDZ1a_MewAAAA RTSP/1.0

Real Time Streaming Protocol
Request [truncated]: SETUP rtsp://118.123.56.184:554/TVOD/88888893/224/3221226889/10000100000000060000000000622347_0.smil?playseek=20220520120000-20220520123600&rrsip=118.123.185.42&zoneoffset=480&recType=1&icpid=HWC1TOOL&accounttype=1&li
CSeq: 5\r\n
Transport [truncated]: MP2T/RTP/UDP;unicast;destination=192.168.2.154;client_port=11590-11591,MP2T/RTP/TCP;unicast;destination=192.168.2.154;interleaved=0-1;mode=PLAY,MP2T/UDP;unicast;destination=192.168.2.154;client_port=11590-11591,MP2T
User-Agent: CTC RTSP 1.0\r\n
x-NAT_Address: 192.168.2.154:60863\r\n
\r\n

```

2. 服务端响应中,可明显看到服务端已经检测出客户端处于内网 `x-NAT:on`

```
48 0.387780 118.123.56.184 10.81.121.127 RTSP 331 Reply: RTSP/1.0 200 OK

Real Time Streaming Protocol
Response: RTSP/1.0 200 OK\r\n
Server: HMS_V1R2\r\n
CSeq: 5\r\n
Date: Fri, 20 May 2022 05:48:02 GMT\r\n
Session: 3656474951
Timeshift-Status: 0\r\n
Transport: MP2T/RTP/UDP;unicast;destination=192.168.2.154;client_port=11590-11591;source=118.123.56.184;server_port=32164-32165;ssrc=5315200
[Expert Info (Warning/Undecoded): Unknown transport type]
x-NAT:on\r\n
\r\n
```

3. 随后客户端向服务端连续发送了两个 8 字节 payload 的 UDP 包,作用应该是用于 UDP 打洞的

```
49 0.394360 10.81.121.127 118.123.56.184 UDP 50 11590 → 32164 Len=8
50 0.394525 10.81.121.127 118.123.56.184 UDP 50 11590 → 32164 Len=8

Data (8 bytes)
Data: 0001000000511a80
[Length: 8]

```

4. 但后面并没有收到任何来自服务端的响应或后续的连接,最后客户端(应该是超时后)发送**TEARDOWN**指令关闭 RTSP 连接

```
56 1.395841 10.81.121.127 118.123.56.184 RTSP 784 TEARDOWN rtsp://118.123.56.184:554/TVOD/88888893/224/3221226889/10000100000000060000000000622347_0.smil?playseek=20220520120000-20220520123600&rrsip=118.123.185.42&zoneoffset=480&recType=1&icpid=HWC1TOOL&accounttype=1&limitflux=-1&limitdur=-1&tenantId=8601&accountinfo=%2C8605058%2C10.81.121.127%2C20220520134801%2CUmai%3ASCHE%2F14673475%40BESTV.SMG.SMG%2C860505820220520105910%2C-1%2C1%2C300%2C-1%2C%2C4%2C100010004671%2C0ee9cbc861ca406e990c%2C%2C5%2CEND&GuardEncType=2&from=200&hms_devid=22724&it=H4sIAAAAAAAAAyspSkxO9XSxzSvNyVErTi30y7c1VktOzMnJzEv3y08BSYUFO8cbWhjpGRpb6JmY6hlbqIWANLnlJKbbGoDV-pXmJqUWQTlAjcGpRWWZyam2KcVpegU5iZWlRTl6xQWZYHZoUQ5UGgDZ1a_MewAAAA RTSP/1.0
```

目前来看似乎是服务端不支持基于 UDP 作为传输协议的内网 RTSP 客户端,但从抓包的协议内容来看,似乎又存在针对 NAT 的处理
对 RTSP 本身不太了解,特别是不清楚电信是否对 RTSP 协议有魔改
V 友有没有这方面的专家或有没有专业的指导意见?
1442 次点击
所在节点    宽带症候群
1 条回复
pierrec
2022-08-24 00:17:10 +08:00
请问最后解决了吗,最近也在找一个用 IPoE 的方案(独享带宽),能用普通电视盒子代替 IPTV 机顶盒的方案。减少遥控器。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/855472

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX