[Live-devel] Port 5004 used for all instances of live555proxyserver while using rtp over udp

[Ross Finlayson]

> On Jun 23, 2021, at 9:47 PM, HAN Hao <han.hao at stengg.com> wrote:
> 
> Hi all,
>  
> I have a problem recently while using the live555proxyserver. I currently have 2 UP-Squared that is connected to 2 IP cameras. The UP-Squared behaves like a network gateway since the 2 IP cameras resides in a different subnet mask as my server. The live555proxyserver resides in my server and when I attempt to use the live555proxyserver to rehost both streams from the IP cameras, I realized that both the IP cameras are sending rtp packets to the same port(5004) on my server. This problem only seems to occur while using UDP and when I input –t to force it through TCP, the IP cameras managed to send to different ports on my server. Are there any parameters that I can modify so that the RTP packets over UDP will be sent to different ports on my server?

For unicast streams like this, it is the RTSP client that chooses the destination port number for RTP packets.  In particular, the "LIVE555 Proxy Server” - which acts as a RTSP client for each ‘back-end’ RTSP server (e.g., IP camera) - chooses the destination RTP port number for each stream, and it will always choose a different port number for each stream.  You should be able to see this by looking at the RTSP protocol exchange for each ‘back-end’ stream, which you can see by running “live555ProxyServer” with the -V flag (note the “client_port=“ in each RTSP SETUP request from the proxy server).

It appears that your intermediate “UP-Squared” boxes are likely responsible for your problem; it seems that they are remapping the port number of incoming RTP packets (from the back-end IP camera) to 5004.  You will need to disable this functionality in your “UP-Squared” boxes.   (Or, alternatively, remove your “UP-Squared” boxes entirely, and change your server so that it acts a a gateway, and is aware of both IP subnets.)

In short, this is a problem with your networking setup, not a problem with the LIVE555 software.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/