search

sippy / rtpproxy

The RTPproxy is a high-performance software proxy for RTP streams that can work together with Sippy B2BUA, Kamailio, OpenSIPS and SER.
http://rtpproxy.org
BSD 2-Clause "Simplified" License
417 stars 114 forks source link

rtpproxy command protocol - stats - UDP stream timeout? #133

Closed solarmon closed 1 year ago

solarmon commented 1 year ago

Hi,

I am using rtpproxy v2.2.0 and would like to get stats from it using the rtpproxy command protocol - as per https://github.com/sippy/rtpproxy/wiki/RTPProxy-Command-Protocol#stat-names.

I'm trying to use PHP to create a UDP stream socket client, using stream_socket_client(), to send and receive from the rtpproxy management port.

On the whole it is working I can get the stats. However, intermittently, when using fread() to read from the UDP stream, it doesn't read anything and it eventually times out - I've set a stream timeout of 2 seconds (but I tested with much higher timeout values). I have set a read length of 256 bytes, but it doesn't really seem to matter what this is set to.

What could be the cause of this read issue and the timeout and how can I go about troubleshooting it better?

Thank you.

sobomax commented 1 year ago

Hi, I suspect there is something peculiar going on with the stream_socket_client() in PHP causing this to happen. Few things you could do to debug it further:

  1. Run packet capture on the client side, make sure the response is actually arriving.
  2. Try with tcp control socket and see if that works better.
  3. Run rtpproxy with debug logging level ("-d dbug") see if requests is received and replied to correctly.

Feel free to update this ticket once you have more data available so it can be debugged further.

Thanks!

solarmon commented 1 year ago

Hi @sobomax

The issue was only occurring on our live/production rtpproxy nodes, and I could not replicate the issue in our test environment.

Turning on debug on the live/production rtpproxy nodes is not an option. So I had to add extra debugging to my script.

Our rtpproxy nodes had multiple rtpproxy instances running, each with a different management port. My script was trying to automatically determine how many rtpproxy instances and what management port each one had, so that it could query each rtpproxy instance individually.

However, my script logic was not good enough and it was sometimes not matching on the correct management port of the rtpproxy instance - it was actually matching on a similar looking port of an actual RTP session, hence why it was so random/intermittent. Thus, the script was sometimes using the wrong port to communicate with the rtpproxy instance!

I have fixed the script logic, so the management port detection is correct/better, and this has now resolved the issue.

Thank you for your support and suggestions, but ultimately the issue was with my script!

Thank you!