srs
srs copied to clipboard
SRT http hook call missing `ip` in request data
Note: Please read FAQ before file an issue, see 2716
Note: 提问前,请先看FAQ, 即 2716
As part of the ingest flow we use http hooks to ensure valid incoming stream - for RTMP we currently use the ip part of request data - we need to do the same for SRT but the ip field appears missing in the request data
Please description your issue here(描述你遇到了什么问题)
-
SRS Version(版本):
5.0.33 -
SRS Log(日志):
RTMP connection calling on_publish hook:
[2022-07-11 09:23:04.066][Trace][17][n8w1q032] http: on_publish ok, client_id=n8w1q032, url=http://srs-helper:8089/on_publish/, request={"server_id":"vid-2f42ds2","action":"on_publish","client_id":"n8w1q032","ip":"10.1.20.5","vhost":"__defaultVhost__","app":"broadcast","tcUrl":"rtmp://10.1.20.1:1935/broadcast","stream":"46746746746746746746","param":""}, response=0
SRT connection calling on_publish hook:
[2022-07-11 09:22:29.601][Error][17][y87l7038][11] srt serve error code=4005 : srt: callback on publish : srt on_publish http://srs-helper:8089/on_publish/ : http: on_publish failed, client_id=y87l7038, url=http://srs-helper:8089/srs/on_publish/, request={"server_id":"vid-2f42ds2","action":"on_publish","client_id":"y87l7038","ip":"","vhost":"","app":"broadcast","tcUrl":"","stream":"46746746746746746746\"","param":"vhost=\""}, response=403: Forbidden, code=403 : http: status 403
- SRS Config(配置):
listen 1935;
max_connections 10000;
srs_log_tank console;
srs_log_level trace;
daemon off;
http_api {
enabled on;
listen 1985;
}
http_server {
enabled on;
listen 1995;
dir ./objs/nginx/html;
}
srt_server {
enabled on;
listen 10080;
maxbw 1000000000;
connect_timeout 4000;
# https://github.com/ossrs/srs/wiki/v5_EN_SRTParams#common-live
peerlatency 0;
recvlatency 0;
latency 0;
tlpktdrop off;
tsbpdmode off;
}
vhost __defaultVhost__ {
srt {
enabled on;
srt_to_rtmp off;
}
http_hooks {
# https://github.com/ossrs/srs/wiki/v4_EN_HTTPCallback
enabled on;
on_publish 10.1.20.1/on_publish/;
on_unpublish 10.1.20.1/on_unpublish/;
on_play 10.1.20.1/on_play/;
}
publish {
# 1st packet timeout in ms for encoder.
# default: 20000
firstpkt_timeout 20000;
# normal packet timeout in ms for encoder.
# default: 5000
normal_timeout 5000;
}
}
Replay(重现)
Please describe how to replay the bug? (重现Bug的步骤)
- RTMP tested with:
ffmpeg -re -i live_005.mp4 -c copy -f flv 'rtmp://10.1.20.1:1935/broadcast/46746746746746746746' - SRT tested with:
ffmpeg -re -i live_005.mp4 -c copy -f mpegts 'srt://10.1.20.1:10080?streamid=#!::r="/broadcast/46746746746746746746",m=publish'
Expect(期望行为)
Please describe your expectation(描述你期望发生的事情) I expect the
ipfield in the request data to be populated, regardless of RTMP/SRT protocol being used
I think part of the same issue is the lack of metrics for SRT based streams in the SRS api, here we have an SRT based stream:
{
"code": 0,
"server": "vid-45d790b",
"streams": [
{
"id": "vid-1t26i17",
"name": "6767676767676767676",
"vhost": "vid-4p610s8",
"app": "broadcast",
"live_ms": 1657729474407,
"clients": 0,
"frames": 0,
"send_bytes": 0,
"recv_bytes": 0,
"kbps": {
"recv_30s": 0,
"send_30s": 0
},
"publish": {
"active": true,
"cid": "4187ol33"
},
"video": {
"codec": "H264",
"profile": "Main",
"level": "3.1",
"width": 0,
"height": 0
},
"audio": {
"codec": "AAC",
"sample_rate": 44100,
"channel": 2,
"profile": "LC"
}
}
]
}
You can see that it is active by looking at the publish section, yet there are no bandwidth details, or clients reported to be connected (even though we are able to view the stream), however some of this information is being captured in the Trace level logs, so it is available, eg:
[2022-07-13 16:27:34.168][Trace][17][4187ol33] <- SRT_CPB Transport Stats # pktRecv=1662, pktRcvLoss=0, pktRcvRetrans=0, pktRcvDrop=0
[2022-07-13 16:27:34.168][Trace][17][4187ol33] <- SRT_CPB time=828622904, packets=1678, okbps=0,0,0, ikbps=1308,1704,1359
[2022-07-13 16:27:37.247][Trace][17][9upy7908] -> SRT_PLA Transport Stats # pktSent=3473, pktSndLoss=0, pktRetrans=0, pktSndDrop=0
[2022-07-13 16:27:37.247][Trace][17][9upy7908] -> SRT_PLA time=824197275, packets=3473, okbps=1311,1641,1362, ikbps=0,0,0
[2022-07-13 16:27:44.181][Trace][17][4187ol33] <- SRT_CPB Transport Stats # pktRecv=1573, pktRcvLoss=0, pktRcvRetrans=0, pktRcvDrop=0
[2022-07-13 16:27:44.181][Trace][17][4187ol33] <- SRT_CPB time=838626393, packets=1593, okbps=0,0,0, ikbps=1309,1704,1359
[2022-07-13 16:27:47.254][Trace][17][9upy7908] -> SRT_PLA Transport Stats # pktSent=1534, pktSndLoss=0, pktRetrans=0, pktSndDrop=0
[2022-07-13 16:27:47.254][Trace][17][9upy7908] -> SRT_PLA time=834202428, packets=1534, okbps=1312,1641,1362, ikbps=0,0,0
[2022-07-13 16:27:54.210][Trace][17][4187ol33] <- SRT_CPB Transport Stats # pktRecv=1352, pktRcvLoss=0, pktRcvRetrans=0, pktRcvDrop=0
[2022-07-13 16:27:54.210][Trace][17][4187ol33] <- SRT_CPB time=848664393, packets=1345, okbps=0,0,0, ikbps=1307,1360,1359
[2022-07-13 16:27:57.267][Trace][17][9upy7908] -> SRT_PLA Transport Stats # pktSent=1342, pktSndLoss=0, pktRetrans=0, pktSndDrop=0
[2022-07-13 16:27:57.267][Trace][17][9upy7908] -> SRT_PLA time=844221042, packets=1342, okbps=1310,1641,1362, ikbps=0,0,0
So, I'm wondering if this is something that might get worked on soon, so that the API has some better visibility/stats over SRT based streams?