Huawei FCC timeout on Shaoxing Telecom IPTV (real STB works, rtp2httpd falls back to multicast) #387
Description
Environment
- ISP/Region: China Telecom IPTV, Shaoxing, Zhejiang, China
- Router OS: iStoreOS / OpenWrt
- IPTV interface: eth1.43
- rtp2httpd version: 3.10.1
- Installation: upgraded from OpenWrt/iStoreOS package to latest release
What works
- Multicast to HTTP works normally
- All IPTV channels can be watched in LAN through rtp2httpd
- Only FCC fast channel switching does not work
FCC test URL
Configuration
- upstream-interface-multicast = eth1.43
- upstream-interface-fcc = eth1.43
rtp2httpd log
- FCC: Using Huawei FCC protocol
- FCC: Server response timeout (80 ms), falling back to multicast
- Multicast: Successfully joined group
Important evidence from real STB capture
- The FCC server address is confirmed from the IPTV portal/channel metadata:
- ChannelFCCIP = 115.233.42.69
- ChannelFCCPort = 8027
- The real STB does send FCC request packets to 115.233.42.69:8027
- These packets are UDP binary packets, not RTSP
- The FCC server does respond to the real STB
- In the capture, the server returns a unicast stream endpoint, for example:
- 115.233.42.110:3600
What I already tried
- Correct IPTV interface binding
- fcc-type=huawei
- Explicit r2h-ifname-fcc=eth1.43
- Upgrading rtp2httpd from 3.7.0 to 3.10.1
Conclusion
- The FCC server is reachable and working in this region
- rtp2httpd enters Huawei FCC mode correctly
- But the FCC request generated by rtp2httpd seems not compatible with this Shaoxing Telecom implementation / STB variant
- It looks like the real STB request contains some fields that rtp2httpd does not reproduce correctly
If needed, I can provide
- Sanitized packet hex of the real FCC request/response
- Sanitized channel metadata showing ChannelFCCIP / ChannelFCCPort
- Full rtp2httpd logs for the failed FCC attempt
- I can help test patched builds if needed.