bugtracker
bugtracker copied to clipboard
Kurento gets confused when addIceCandidate is called before gatherCandidates
Prerequisites
- [X] I agree to fill this issue template.
- [X] I have read the Troubleshooting Guide and Support Instructions.
(not sure if your bot checks it)
Issue description
When addIceCandidates is called before gatherCandidates (e.g. because of async race conditions), Kurento gets confused.
- Kurento response is returned only after 10-20s, causing timeouts on client side
- First ICE candidates are sent after ~10s (Wireshark'ed, there are literally 10 seconds of silence).
- ICE negotiation slows down too due to lack of candidates. Eventually it succeeds, but takes 20s instead of 2s.
Context
Pipeline that is being run is a simple RTP-to-WebRTC converter, just two blocks attached together. WebRTC is operating in send-only mode.
No logs shows up, so debugging that may be tricky.
How to reproduce?
My tests shows that it's sufficient to send ICE candidates before gatherCandidates call.
Expected & current behavior
Kurento should start sending ICE candidates immediately after gatherCandidates call, but it stucks for ~10-20s instead.
INFO about Kurento Media Server
- Kurento version: 6.14.0, image ID
sha256:c195eb150fced18b05edc1aea963f3d0546fa83961d0d81aa7f12084a094326f - Server OS: Fedora 32
- Installation method: Docker
INFO about your Application Server
- Programming Language: Java, but issue is unrelated to client
- Kurento Client version: 6.14.0, but unrelated
INFO about end-user clients
Any clients, Chrome on Linux to be specific.
INFO about your environment
Docker container uses host networking.
Kurento is configured with a static IP address and has an explicitly specified network interface. Kurento is directly reachable in the network, so no NAT traversal is required. Because of that, no STUN/TURN servers are specified in the config file.
Run these commands
cat: /etc/lsb-release: No such file or directory
Kurento Media Server version: 6.14.0
Found modules:
'core' version 6.14.0
'elements' version 6.14.0
'filters' version 6.14.0
ii gstreamer1.5-alsa:amd64 1.8.1-1kurento2.16.04 amd64 GStreamer plugin for ALSA
ii gstreamer1.5-libav:amd64 1.8.1-1kurento1.16.04 amd64 libav plugin for GStreamer
ii gstreamer1.5-libav-dbg:amd64 1.8.1-1kurento1.16.04 amd64 libav plugin for GStreamer (debug symbols)
ii gstreamer1.5-nice:amd64 0.1.17-0kurento1.16.04 amd64 ICE library (GStreamer 1.5 plugin)
ii gstreamer1.5-nice-dbgsym:amd64 0.1.17-0kurento1.16.04 amd64 debug symbols for package gstreamer1.5-nice
ii gstreamer1.5-plugins-bad:amd64 1.8.1-1kurento4.16.04 amd64 GStreamer plugins from the "bad" set
ii gstreamer1.5-plugins-bad-dbg:amd64 1.8.1-1kurento4.16.04 amd64 GStreamer plugins from the "bad" set (debug symbols)
ii gstreamer1.5-plugins-base:amd64 1.8.1-1kurento2.16.04 amd64 GStreamer plugins from the "base" set
ii gstreamer1.5-plugins-base-dbg:amd64 1.8.1-1kurento2.16.04 amd64 GStreamer plugins from the "base" set
ii gstreamer1.5-plugins-good:amd64 1.8.1-1kurento4.16.04 amd64 GStreamer plugins from the "good" set
ii gstreamer1.5-plugins-good-dbg:amd64 1.8.1-1kurento4.16.04 amd64 GStreamer plugins from the "good" set
ii gstreamer1.5-plugins-ugly:amd64 1.8.1-1kurento1.16.04 amd64 GStreamer plugins from the "ugly" set
ii gstreamer1.5-plugins-ugly-dbg:amd64 1.8.1-1kurento1.16.04 amd64 GStreamer plugins from the "ugly" set (debug symbols)
ii gstreamer1.5-pulseaudio:amd64 1.8.1-1kurento4.16.04 amd64 GStreamer plugin for PulseAudio
ii gstreamer1.5-x:amd64 1.8.1-1kurento2.16.04 amd64 GStreamer plugins for X11 and Pango
ii kms-core 6.14.0-0kurento1.16.04 amd64 Kurento Core module
ii kms-core-dbg 6.14.0-0kurento1.16.04 amd64 Kurento Core module
ii kms-elements 6.14.0-0kurento1.16.04 amd64 Kurento Elements module
ii kms-elements-dbg 6.14.0-0kurento1.16.04 amd64 Kurento Elements module
ii kms-filters 6.14.0-0kurento1.16.04 amd64 Kurento Filters module
ii kms-filters-dbg 6.14.0-0kurento1.16.04 amd64 Kurento Filters module
ii kms-jsonrpc 6.14.0-0kurento1.16.04 amd64 Kurento JSON-RPC library
ii kms-jsonrpc-dbg 6.14.0-0kurento1.16.04 amd64 Kurento JSON-RPC library
ii kmsjsoncpp 1.6.3-1kurento1.16.04 amd64 Kurento jsoncpp library
ii kmsjsoncpp-dbg 1.6.3-1kurento1.16.04 amd64 Kurento jsoncpp library
ii kurento-dbg 6.14.0-0kurento1.16.04 amd64 Meta-package that installs debug symbols
ii kurento-media-server 6.14.0-0kurento1.16.04 amd64 Kurento Media Server
ii kurento-media-server-dbg 6.14.0-0kurento1.16.04 amd64 Kurento Media Server
ii libgstreamer-plugins-bad1.5-0:amd64 1.8.1-1kurento4.16.04 amd64 GStreamer development files for libraries from the "bad" set
ii libgstreamer-plugins-base1.5-0:amd64 1.8.1-1kurento2.16.04 amd64 GStreamer libraries from the "base" set
ii libgstreamer1.5-0:amd64 1.8.1-1kurento2.16.04 amd64 Core GStreamer libraries and elements
ii libgstreamer1.5-0-dbg:amd64 1.8.1-1kurento2.16.04 amd64 Core GStreamer libraries and elements
ii libnice10:amd64 0.1.17-0kurento1.16.04 amd64 ICE library (shared library)
ii libnice10-dbgsym:amd64 0.1.17-0kurento1.16.04 amd64 debug symbols for package libnice10
ii libsrtp0:amd64 1.6.0-0kurento1.16.04 amd64 Secure RTP (SRTP) and UST Reference Implementations - shared library
ii libusrsctp 0.9.2-1kurento1.16.04 amd64 sctp-refimpl library
ii openh264 1.4.0-1kurento1.16.04 amd64 OpenH264 library
ii openh264-gst-plugins-bad-1.5:amd64 1.8.1-1kurento4.16.04 amd64 GStreamer plugins from openh264
ii openwebrtc-gst-plugins 0.10.0-1kurento1.16.04 amd64 OpenWebRTC specific GStreamer plugins
ii openwebrtc-gst-plugins-dbg 0.10.0-1kurento1.16.04 amd64 OpenWebRTC specific GStreamer plugins
Hello @makkarpov! :wave: we're sorry you found a bug... so first of all, thank you very much for reporting it.
To know about progress, check in Triage. All issues are considered Backlog Candidates until work priorities align and the issue is selected for development. It will then become part of our official Backlog.
Sorry for the bot issue. It checks the prerequisites. Otherwise people just write a line like "doesn't work, fix please".
Now about the issue: could it happen due to too many async calls happening at the same time? i.e. does it happen if only one WebRtcEndpoint is operating on the pipeline?
Yes, it happens with just single client and otherwise unoccupied server. When I removed browser-to-server ICE trickling (i.e. it's sendonly anyway) everything started to work flawlessly.