Video but no audio from one participant

Issues developing apps
1

Hi all!

We can reproduce the following situation with OpenVidu 2.16 deployed on premises.

Participant 1

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.67 Safari/537.36
or
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0.1 Safari/605.1.15

Participant 2

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:83.0) Gecko/20100101 Firefox/83.0

Problem:

Participant 1 can see and hear Participant 2
Participant 2 can see but not hear Participant 1

The OpenVidu log files do not show any special lines, but we found something in the KMS log files.

What does the line “Cannot handle media” mean? Can this be the problem? What else can we check to find the reason?

Thanks!

info KurentoWebRtcEndpointImpl WebRtcEndpointImpl.cpp:108 remove_not_supported_codecs_from_array() <kmswebrtcendpoint3408>  Removing not supported codec 'AMR/8000'
info KurentoWebRtcEndpointImpl WebRtcEndpointImpl.cpp:566 WebRtcEndpointImpl()  STUN port not found in config; using default value: 3478
info KurentoWebRtcEndpointImpl WebRtcEndpointImpl.cpp:574 WebRtcEndpointImpl()  STUN server not found in config; remember that NAT traversal requires STUN or TURN
info KurentoWebRtcEndpointImpl WebRtcEndpointImpl.cpp:597 WebRtcEndpointImpl()  TURN server not found in config; remember that NAT traversal requires STUN or TURN
info kmsutils                  kmsutils.c:515 kms_utils_pad_monitor_gaps() <'':sink_video_default>  Add probe: DISCONT buffers and GAP events
warning sdpagent                  kmssdpagent.c:1557 create_media_answer() <KmsSdpAgent@0x560d8ef78c40>  Cannot handle media 'audio UDP/TLS/RTP/SAVPF' (multiple m= lines?)
warning sdpagent                  kmssdpagent.c:1557 create_media_answer() <KmsSdpAgent@0x560d8ef78c40>  Cannot handle media 'video UDP/TLS/RTP/SAVPF' (multiple m= lines?)
fixme basesink                  gstbasesink.c:3125 gst_base_sink_default_event() <nicesink3408>  stream-start event without group-id. Consider implementing group-id handling in the upstream elements
fixme default                   gstutils.c:3766 gst_pad_create_stream_id_internal() <nicesrc3408:src>  Creating random stream-id, consider implementing a deterministic way of creating a stream-id
2

Has anyone else ever had this problem? We can see this behaviour regularly in a few sessions, also with other devices and also with more than 2 participants. If there are more than 2 participants sometimes only one participant can not hear one person but others do hear the person. We don’t know how to trace down this issue.

3

I could find a corresponding SDP Offer. Does this help?
There are two m=audio and two m=video lines in the SDP. Can this be a problem?

v=0
o=- 4647614945874249172 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1 2 3
a=msid-semantic: WMS 19da626e-1364-4e8a-93e3-6a28779e19ca
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 127 125 104
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:msmH
a=ice-pwd:xTxn3ZaVUbqJcK5fzKl802Uy
a=ice-options:trickle
a=fingerprint:sha-256 EB:86:54:48:A8:36:F2:DA:08:64:52:A1:63:E5:0C:E2:44:26:76:6F:A2:A9:03:11:11:43:29:EF:C3:AC:9C:87
a=setup:actpass
a=mid:0
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:10 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:19da626e-1364-4e8a-93e3-6a28779e19ca f5477aaf-b466-452e-8c51-59803e516d78
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 H264/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640c1f
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 H264/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 red/90000
a=rtpmap:125 rtx/90000
a=fmtp:125 apt=127
a=rtpmap:104 ulpfec/90000
a=ssrc-group:FID 2979794906 323080228
a=ssrc:2979794906 cname:ly6zEZN7bJYHgC+c
a=ssrc:2979794906 msid:19da626e-1364-4e8a-93e3-6a28779e19ca f5477aaf-b466-452e-8c51-59803e516d78
a=ssrc:2979794906 mslabel:19da626e-1364-4e8a-93e3-6a28779e19ca
a=ssrc:2979794906 label:f5477aaf-b466-452e-8c51-59803e516d78
a=ssrc:323080228 cname:ly6zEZN7bJYHgC+c
a=ssrc:323080228 msid:19da626e-1364-4e8a-93e3-6a28779e19ca f5477aaf-b466-452e-8c51-59803e516d78
a=ssrc:323080228 mslabel:19da626e-1364-4e8a-93e3-6a28779e19ca
a=ssrc:323080228 label:f5477aaf-b466-452e-8c51-59803e516d78
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 105 13 110 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:msmH
a=ice-pwd:xTxn3ZaVUbqJcK5fzKl802Uy
a=ice-options:trickle
a=fingerprint:sha-256 EB:86:54:48:A8:36:F2:DA:08:64:52:A1:63:E5:0C:E2:44:26:76:6F:A2:A9:03:11:11:43:29:EF:C3:AC:9C:87
a=setup:actpass
a=mid:1
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendrecv
a=msid:19da626e-1364-4e8a-93e3-6a28779e19ca b044ed41-1c0e-4836-803f-4c411ce1e55b
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:848548128 cname:ly6zEZN7bJYHgC+c
a=ssrc:848548128 msid:19da626e-1364-4e8a-93e3-6a28779e19ca b044ed41-1c0e-4836-803f-4c411ce1e55b
a=ssrc:848548128 mslabel:19da626e-1364-4e8a-93e3-6a28779e19ca
a=ssrc:848548128 label:b044ed41-1c0e-4836-803f-4c411ce1e55b
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 105 13 110 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:msmH
a=ice-pwd:xTxn3ZaVUbqJcK5fzKl802Uy
a=ice-options:trickle
a=fingerprint:sha-256 EB:86:54:48:A8:36:F2:DA:08:64:52:A1:63:E5:0C:E2:44:26:76:6F:A2:A9:03:11:11:43:29:EF:C3:AC:9C:87
a=setup:actpass
a=mid:2
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendonly
a=msid:- dc27641e-ebc0-4679-b170-3823461bc5b7
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:4105635747 cname:ly6zEZN7bJYHgC+c
a=ssrc:4105635747 msid:- dc27641e-ebc0-4679-b170-3823461bc5b7
a=ssrc:4105635747 mslabel:-
a=ssrc:4105635747 label:dc27641e-ebc0-4679-b170-3823461bc5b7
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 127 125 104
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:msmH
a=ice-pwd:xTxn3ZaVUbqJcK5fzKl802Uy
a=ice-options:trickle
a=fingerprint:sha-256 EB:86:54:48:A8:36:F2:DA:08:64:52:A1:63:E5:0C:E2:44:26:76:6F:A2:A9:03:11:11:43:29:EF:C3:AC:9C:87
a=setup:actpass
a=mid:3
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:10 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 urn:ietf:params:rtp-hdrext:sdes:mid
a=sendonly
a=msid:- 618bc877-fad5-40cf-a3f4-66089208fcb5
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 H264/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640c1f
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 H264/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 red/90000
a=rtpmap:125 rtx/90000
a=fmtp:125 apt=127
a=rtpmap:104 ulpfec/90000
a=ssrc-group:FID 2413429766 2145277141
a=ssrc:2413429766 cname:ly6zEZN7bJYHgC+c
a=ssrc:2413429766 msid:- 618bc877-fad5-40cf-a3f4-66089208fcb5
a=ssrc:2413429766 mslabel:-
a=ssrc:2413429766 label:618bc877-fad5-40cf-a3f4-66089208fcb5
a=ssrc:2145277141 cname:ly6zEZN7bJYHgC+c
a=ssrc:2145277141 msid:- 618bc877-fad5-40cf-a3f4-66089208fcb5
a=ssrc:2145277141 mslabel:-
a=ssrc:2145277141 label:618bc877-fad5-40cf-a3f4-66089208fcb5

Thanks again!

4

Hi @adad,

I’m also facing the same issue that you have been facing, could you let me know if your issue is solved? If yes, please let me know the solution that you have used to solve the issue.

Here is a description of the issue.

Issue:
We are working on a remote collaborative application that is deployed both as an APK using the Cordova app on the client side (sender) and as a web application on the receiver’s end. In an active open vidu one-on-one call, A being the sender and B being the receiver, the audio of B(Receiver) is not audible to A(Sender). Whereas the video of both A(Sender) & B(Receiver) is visible to each other. When tested on OpenVidu by creating a custom room, both the audio and video of A & B are audible and visible.

Solutions tried and failed:
All these changes were made to the client-side javascript files.

1)Tried changing the audio source from true to undefined.
2)Tried printing the value of the publishAudio, while printing the value, it shows as true
3)Tried changing the OpenVidu Browser version from 2.18.0 to 2.20.0

Packages used:

  1. OpenVidu: 2.20.0

Browsers tested: Chrome (106.0.5249.121), MS Edge (107.0.1418.26)

Thanks in advance :slight_smile: