We have developed an own OpenVidu frontend using openvidu-browser. The frontend works great, but sometimes, especially when more than five publishers are in the session, it happens that one of the publishers can’t hear one of the others. So let’s say we have publishers A, B and C - then sometimes e.g. A can’t hear publisher B, but he can hear C. At the same time, everyone can hear A.
When opening the developer toolbar, the following error message can be seen:
Request: method:onIceCandidate params:{“endpointName”:“con_Vzn1NODfJr”,“candidate”:“candidate:55 2 UDP 7806974 91.196.146.28 54406 typ relay raddr 91.196.146.28 rport 54406”,“sdpMid”:“0”,“sdpMLineIndex”:0} openvidu-browser-2.16.1.js:1:156333
ERROR:java.lang.IllegalStateException:[KurentoClient] JsonRpcClient is disconnected from WebSocket server at ‘ws://172.21.12.51:8888/kurento’ in Request: method:receiveVideoFrom params:{“sdpOffer”:“v=0\r\no=mozilla…THIS_IS_SDPARTA-87.0 7725925211308533230 0 IN IP4 0.0.0.0\r\ns=-\r\nt=0 0\r\na=sendrecv\r\na=fingerprint:sha-256 51:09:3E:4B:A4:DE:FA:30:42:EB:3E:A2:37:EA:97:16:8D:58:3C:AC:C3:D2:C8:33:D4:6C:24:52:2F:AF:F4:1B\r\na=group:BUNDLE 0 1\r\na=ice-options:trickle\r\na=msid-semantic:WMS *\r\nm=audio 9 UDP/TLS/RTP/SAVPF 109 9 0 8 101\r\nc=IN IP4 0.0.0.0\r\na=recvonly\r\na=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level\r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1\r\na=fmtp:101 0-15\r\na=ice-pwd:4c47427685db92c9418cd2c7e55db4cc\r\na=ice-ufrag:34d6aff1\r\na=mid:0\r\na=rtcp-mux\r\na=rtpmap:109 opus/48000/2\r\na=rtpmap:9 G722/8000/1\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:101 telephone-event/8000\r\na=setup:actpass\r\na=ssrc:558105091 cname:{58afd4fa-0a59-4bce-a1c3-bc60ef3d804e}\r\nm=video 9 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98\r\nc=IN IP4 0.0.0.0\r\na=recvonly\r\na=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid\r\na=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time\r\na=extmap:5 urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay\r\na=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01\r\na=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1\r\na=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1\r\na=fmtp:120 max-fs=12288;max-fr=60\r\na=fmtp:124 apt=120\r\na=fmtp:121 max-fs=12288;max-fr=60\r\na=fmtp:125 apt=121\r\na=fmtp:127 apt=126\r\na=fmtp:98 apt=97\r\na=ice-pwd:4c47427685db92c9418cd2c7e55db4cc\r\na=ice-ufrag:34d6aff1\r\na=mid:1\r\na=rtcp-fb:120 nack\r\na=rtcp-fb:120 nack pli\r\na=rtcp-fb:120 ccm fir\r\na=rtcp-fb:120 goog-remb\r\na=rtcp-fb:120 transport-cc\r\na=rtcp-fb:121 nack\r\na=rtcp-fb:121 nack pli\r\na=rtcp-fb:121 ccm fir\r\na=rtcp-fb:121 goog-remb\r\na=rtcp-fb:121 transport-cc\r\na=rtcp-fb:126 nack\r\na=rtcp-fb:126 nack pli\r\na=rtcp-fb:126 ccm fir\r\na=rtcp-fb:126 goog-remb\r\na=rtcp-fb:126 transport-cc\r\na=rtcp-fb:97 nack\r\na=rtcp-fb:97 nack pli\r\na=rtcp-fb:97 ccm fir\r\na=rtcp-fb:97 goog-remb\r\na=rtcp-fb:97 transport-cc\r\na=rtcp-mux\r\na=rtcp-rsize\r\na=rtpmap:120 VP8/90000\r\na=rtpmap:124 rtx/90000\r\na=rtpmap:121 VP9/90000\r\na=rtpmap:125 rtx/90000\r\na=rtpmap:126 H264/90000\r\na=rtpmap:127 rtx/90000\r\na=rtpmap:97 H264/90000\r\na=rtpmap:98 rtx/90000\r\na=setup:actpass\r\na=ssrc:3103311413 cname:{58afd4fa-0a59-4bce-a1c3-bc60ef3d804e}\r\n”,“sender”:“str_CUS_IiEh_con_Vzn1NODfJr”} request:undefined openvidu-browser-2.16.1.js:1:156447
The error can’t be reproduced reliably, which makes debugging quite hard.
Would you say this is rather a frontend, backend, connection or browser issue? Basically it says that the Websocket to KMS is broken - but I don’t know how to solve this issue.