UDP communication error when deepstream container uses docker network

Please provide complete information as applicable to your setup.

• Hardware Platform (Jetson / GPU) GPU
• DeepStream Version 6.3
• Issue Type( questions, new requirements, bugs) bug
• How to reproduce the issue ? (This is for bugs. Including which sample app is using, the configuration files content, the command line used and other details for reproducing)

Deepstream encounters difficulties reading camera streams when operating within a Docker network rather than the host network. The official deepstream run command, as specified on the official webpage, utilizes the host network with the following syntax:
docker run -it --rm --net=host --gpus all -e DISPLAY=$DISPLAY --device /dev/snd -v /tmp/.X11-unix/:/tmp/.X11-unix <required docker container name>

However, opting for a Docker network (without using --net=host) leads to issues with certain cameras., And for some cameras I get this warning and eventually runs using TCP.

2023-08-24 13:15:51 - INFO - Warning: err:gst-resource-error-quark: Could not read from resource. (9),debug:gstrtspsrc.c(5769): gst_rtspsrc_reconnect (): /GstPipeline:pipeline0/GstURIDecodeBin:source-bin-00/GstRTSPSrc:source: Could not receive any UDP packets for 5.0000 seconds, maybe your firewall is blocking it. Retrying using a tcp connection.

how to enable UDP communication in deepstream?

According to your description, I conducted the following test and it seems there should be no problem.

docker run --gpus all -it --rm -w /opt/nvidia/deepstream/deepstream nvcr.io/nvidia/deepstream:6.3-triton-multiarch

gst-launch-1.0 -e rtspsrc location="rtsp://xxx" ! application/x-rtp, media=video, encoding-name=H264 ! queue ! rtph264depay ! h264parse ! qtmux ! filesink location=received_h264.mp4 

I think this is not a problem with deepstream, but a problem with docker udp port mapping.

In addition, I would like to know whether --net=host has caused any trouble to you.

If you don’t want to trouble yourself with network problems, this option may be the best choice.

Can you share the specific camera model, or share the package captured using wireshark/tcpdump in docker?

everything works fine with --net=host, I have similar problem with kubernetes as well. I don’t want to use the host network for security purposes

  1. while using virtual camera (ffmpeg + happy RTSP server)
    there is no warning message

  2. while using HIKVISION DS-2CD1043-G0-I

2023-08-24 13:15:51 - INFO - Warning: err:gst-resource-error-quark: Could not read from resource. (9),debug:gstrtspsrc.c(5769): gst_rtspsrc_reconnect (): /GstPipeline:pipeline0/GstURIDecodeBin:source-bin-00/GstRTSPSrc:source: Could not receive any UDP packets for 5.0000 seconds, maybe your firewall is blocking it. Retrying using a tcp connection.

  1. while using CAMLEIGH Wireless WiFi 2MP

not getting streams (I guess the camera supports only UDP transmission)

Also, I can stream all these camera using OpenCV

I researched this question, does your IP camera have multiple IP addresses?

I found this link , can you run tcpdump to capture packets?

how should I run the docker run command with or without --net=host

without --net=host, then run the following command line in host.

sudo tcpdump -i docker0(The bridge your container uses, default is docker0) -s 0  -nnn host "your docker ip" -w abc.pcap

Possibly udp packets from eth0 to the bridge are blocked

running it using uridecodebin : no warning message(

)
abc1.zip (3.0 MB)

running the camera using nvurisrcbin : warning message (

)
abc3.zip (1.5 MB)

running using uridecodebin
abc2.zip (2.0 KB)

1.nvurisrcbin should be no different from uridecodebin. They both use rtspsrc to read ip camera data.

  1. From abc3.pcap, there is a reconnection, but it is not caused by supporting udp reading.

I don’t know why there is a reconnection. If the reconnection is caused by the inability of udp to read, it should happen after 5 seconds.

This is still UDP. If udp times out and reconnects, this should be TCP.

gst-launch-1.0 uridecodebin uri="rtsp://xxx" ! fakesink
gst-launch-1.0 nvurisrcbin uri="rtsp://xxx" ! fakesink

You can try using the two commands above, they should be the same

Thank you for looking into the logs

it works for all three camera (1-virtual camera, 2-Hikvision , 3- CAMLEIGH) with net=host

without net=host
2-Hikvision runs without any warning messages
3- CAMLEIGH did not run

 fakesink
Setting pipeline to PAUSED ...
Pipeline is live and does not need PREROLL ...
Progress: (open) Opening Stream
Progress: (connect) Connecting to rtsp://192.168.99.93
Progress: (open) Retrieving server options
Progress: (open) Retrieving media info
Progress: (request) SETUP stream 0
Progress: (open) Opened Stream
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Progress: (request) Sending PLAY request
Progress: (request) Sending PLAY request
Progress: (request) Sent PLAY request
ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstRTSPSrc:source: Could not read from resource.
Additional debug info:
gstrtspsrc.c(6421): gst_rtspsrc_try_send (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstRTSPSrc:source:
Could not receive message. (Received end-of-file)
Execution ended after 0:00:05.124139141
Setting pipeline to NULL ...
Freeing pipeline ...