ERR: rtcp: packet too short

[sgjava]

Which version are you using?

v0.19.3_linux_arm64v8

Which operating system are you using?

Armbian on Rock64

• [ ] Linux amd64 standard
• [ ] Linux amd64 Docker
• [X] Linux arm64 standard
• [ ] Linux arm64 Docker
• [ ] Linux arm7 standard
• [ ] Linux arm7 Docker
• [ ] Linux arm6 standard
• [ ] Linux arm6 Docker
• [ ] Windows amd64 standard
• [ ] Windows amd64 Docker (WSL backend)
• [ ] macOS amd64 standard
• [ ] macOS amd64 Docker
• [ ] Other (please describe)

Describe the issue

2022/08/12 15:50:42 INF [path sub1] [rtsp source] ready 2022/08/12 15:50:42 INF [path sub1] [rtsp source] ERR: rtcp: packet too short

Displays over and over

Describe how to replicate the issue

Edimax 3100P MPEG4 stream using

paths: sub1: sourceProtocol: tcp source: rtsp://192.168.1.8:554/ipcam.sdp

Just start with that camera.

Did you attach the server logs?

no

Did you attach a network dump?

no

[aler9]

Hello, please attach a network dump, that can be generated in this way:

1. Download wireshark (https://www.wireshark.org/)
2. Start capturing on the interface used for exchanging RTSP (if the server and the target software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card)
3. Start the server and replicate the issue
4. Stop capturing, save the result in .pcap format
5. Attach

[sgjava]

Here you go:

edimax.zip

[aler9]

fixed in v0.20.1

[arkanoid87]

I'm having same problem with commit 4c96a6873e38ae92b58bbc38545fefa48bdba205 (HEAD, tag: v0.20.2, origin/main)

I've been using old version from 2020 before upgrading to 0.20.2 with same pipeline without problems.

[arkanoid87]

I've captured some packages between client and rtsp-simple-server via wireshark It seems the client is sending (receiver-report) malfomed RTCP packages back to server:

Frame 1003: 104 bytes on wire (832 bits), 104 bytes captured (832 bits) on interface -, id 0
Raw packet data
Internet Protocol Version 4, Src: X.X.X.X, Dst: X.X.X.X
Transmission Control Protocol, Src Port: 52783, Dst Port: 554, Seq: 1159, Ack: 49991, Len: 64
RTSP Interleaved Frame, Channel: 0x03, 60 bytes
Real-time Transport Control Protocol (Receiver Report)
Real-time Transport Control Protocol (Source description)
    10.. .... = Version: RFC 1889 Version (2)
    ..0. .... = Padding: False
    ...0 0001 = Source count: 1
    Packet type: Source description (202)
    Length: 6 (28 bytes)
    Chunk 1, SSRC/CSRC 0x4A043F7D
    [RTCP frame length check: Wrong (expected 60 bytes, found 56)]
        [Expert Info (Warning/Malformed): Incorrect RTCP packet length information (expected 60 bytes, found 56)]

is it possible that rtsp-simple-server from 2020 was accepting this malformed package from client without complaining? It was working actually.

[arkanoid87]

I've reverted back rtsp-simple-server to 4c96a6873e38ae92b58bbc38545fefa48bdba205 and I can confirm that it does work (it doesn't drop RTSP/TPC connection) even when receiving a malformed ([RTCP frame length check: Wrong (expected 60 bytes, found 56)]) Receiver Report

@aler9: I'm not sure if I'd call this a regression or not. Clearly rtsp-simple-server 0.20.2 is complaining about a real-problem, but old version was able to keep going even with malformed RR without having to change anything on the client.

[kklem0]

3 out of my 8 camera's stream is complaining about [rtsp source] rtcp: packet too short, is a way to find out where the problem is?

[sgjava]

@kklem0 I had the issue on an older camera Edimax IC-3100P circa 2013. My 4K Annke cameras work fine. Are all your cameras the same?

[kklem0]

@kklem0 I had the issue on an older camera Edimax IC-3100P circa 2013. My 4K Annke cameras work fine. Are all your cameras the same?

No, 4 brands, 6 models. All the ones that have issues are Hanwha Techwin cameras. Bosch, Hikvision, Samsung work fine. I'm using rtsp-simple-server purely as a proxy because the cameras cannot handle too many rtsp connections.

paths:
  cam1:
    source: rtsp://[user]:[password]@[ip]/profile8/media.smp
    readUser: test
    readPass: test

[sgjava]

Maybe follow @aler9 instructions above:

1. Download wireshark (https://www.wireshark.org/)
2. Start capturing on the interface used for exchanging RTSP (if the server and the target software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card)
3. Start the server and replicate the issue
4. Stop capturing, save the result in .pcap format
5. Attach

You'll see where I did that above. Maybe create a new issue since this is technically closed @aler9?

[kklem0]

Maybe follow @aler9 instructions above:

1. Download wireshark (https://www.wireshark.org/)
2. Start capturing on the interface used for exchanging RTSP (if the server and the target software are both installed on your pc, the interface is probably "loopback", otherwise it's the one of your network card)
3. Start the server and replicate the issue
4. Stop capturing, save the result in .pcap format
5. Attach

You'll see where I did that above. Maybe create a new issue since this is technically closed @aler9?

Thanks, will take a look tomorrow. The RTSP proxy works and it seems like it's throwing error on purpose per this commit https://github.com/aler9/gortsplib/commit/30e029011b530a6227f72f1799c6d0d9de6b671e

[sgjava]

@kklem0 it was "fixed" here https://github.com/aler9/gortsplib/commit/25199d8e16f281e3ab077c81daa1859f9c2f0236

[arkanoid87]

@kklem0 it was "fixed" here aler9/gortsplib@25199d8

The comment in code says "some cameras send invalid RTCP packets ..." but the problem that I've been reporting here is not about this, but about the client that sends invalid RR (receiver report) back to rtsp-simple-server.

I've yet to test this commit if it fixes also this situation

[kklem0]

@kklem0 it was "fixed" here aler9/gortsplib@25199d8

The comment in code says "some cameras send invalid RTCP packets ..." but the problem that I've been reporting here is not about this, but about the client that sends invalid RR (receiver report) back to rtsp-simple-server.

I've yet to test this commit if it fixes also this situation

No it's still the cameras that are the problem, the client (homebridge) connects to a bunch of cameras through rtsp-simple-server and only one brand complains about this. I'll probably be in touch with the manufacturer if I can find out the exact problem, but it would be cool to turn off the warning from rtsp-simple-server as well.

[aler9]

Hello everyone, i've checked the code again and this is what happens:

• when a camera is proxied from the server (i.e. source: rtsp://camera-url), RTCP decoding errors are ignored and a warning message is printed. Most media software print warning messages in case of malformed packets, so there's no reason to remove it.

• when a camera publishes its stream to the server (i.e. source: publisher), RTCP decoding errors are fatal

• when a client reads a stream from the server and sends invalid received reports, RTCP decoding errors are fatal

Which case are you referring to? i'm willing to transform fatal errors into warnings if we clearly identify the issue.

[sgjava]

@aler9 I think the warnings are fine if it doesn't impact the stream. Obviously you want to know fatal errors. Is there a way to do log levels like debug, warn, error, fatal, etc.? From my perspective I'd just turn off warnings, so the log doesn't get filled up with nonsense you are handling.

[arkanoid87]

Hello everyone, i've checked the code again and this is what happens:

* when a camera is proxied from the server (i.e. `source: rtsp://camera-url`), RTCP decoding errors are ignored and a warning message is printed. Most media software print warning messages in case of malformed packets, so there's no reason to remove it.

* when a camera publishes its stream to the server (i.e. `source: publisher`), RTCP decoding errors are fatal

* when a client reads a stream from the server and sends invalid received reports, RTCP decoding errors are fatal

Which case are you referring to? i'm willing to transform fatal errors into warnings if we clearly identify the issue.

Thanks for reopening this.

My case is the third one: the client video decoder connects to rtsp-simple-server via RTSP/TCP but client causes rtsp-simple-server to kill TCP connection by sending invalid Receiver Report (please check my previous comments for Wireshark frame capture)

This behavior changed recently as it was working correctly with old version of rtsp-simple-server (checksum in previous comment), that I am still using at current date until this problem is fixed (actually downgraded to a warning and not an error)

[kklem0]

Hello everyone, i've checked the code again and this is what happens:

• when a camera is proxied from the server (i.e. source: rtsp://camera-url), RTCP decoding errors are ignored and a warning message is printed. Most media software print warning messages in case of malformed packets, so there's no reason to remove it.
• when a camera publishes its stream to the server (i.e. source: publisher), RTCP decoding errors are fatal
• when a client reads a stream from the server and sends invalid received reports, RTCP decoding errors are fatal

Which case are you referring to? i'm willing to transform fatal errors into warnings if we clearly identify the issue.

So for me it's use case 1, and potentially 3. Apart from trying to make it work, I wonder if this is something that should even be a warning or not, because if this is common practice and there is nothing rtsp-simple-server can fix, then it should be even lower level of logging, like maybe info level, because I want to see the "real" warnings that I need to fix, and right now my log is just spammed with this that I don't see anything else, and there's nothing I could do to fix this. If it has to be a warning, it could probably shows up 1 time instead of all the packages.

[aler9]

Invalid RTCP packets are now allowed in all cases.

[aler9]

the fix is included in v0.20.4

[github-actions[bot]]

This issue is being locked automatically because it has been closed for more than 6 months. Please open a new issue in case you encounter a similar problem.