WebRTC Play sometimes has missing audio in BUNDLE

Wowza Streaming Engine
1

I have been using WebRTC-trial since it first came out last October, I am using it for a video chat application running on Chrome, using Publish/Play demo code. The code was working well last month.

Recently I have encountered the problem that sometimes audio does not play on side of the chat (although video frames still show up). It started happneindg when I was using Wowza 4.6.0.3, and still happens even after I have upgraded to 4.7.0. I am also using the latest Publish/Play demo code (with support for video framerate), using websocket (wss://) connection.

My test setup uses two MacBook laptops side-by-side as clients, running Chrome 57 and 58.

After further investigation, I discover that sometimes the SDP package that the Play code receives from the server might not contain audio BUNDLE (e.g.: a=group:BUNDLE video). Only when the SDP package contains both video and audio then I can hear the audio from the other side (i.e. a=group:BUNDLE video audio). This happens somewhat randomly, as I can start Publish the video on one side, then start Play on the other side, then sometimes the SDP returned from the server for the Play side contains audio BUNDLE, sometimes it does not, even on the same Publish stream.

Right now the work-around I am using is to keep retrying Play until I receive a SDP with audio bundle, otherwise I will just disconnect and reset the connection. It works, but I guess this should be resolved on the server side, why do I not always receive BUNDLE audio+video?

Example of the returned SDP that does not contain audio bundle:

“type”:“offer”,“sdp”:"v=0

o=WowzaStreamingEngine-next 881639558 2 IN IP4 127.0.0.1

s=-

t=0 0

a=fingerprint:sha-256 10:4A:D1:05:E3:9F:18:9E:82:A4:AF:46:8C:2C:57:4F:8D:CC:94:F1:B1:57:9F:44:31:F0:18:DE:BD:94:63:BF

a=group:BUNDLE video

a=ice-options:trickle

a=msid-semantic:WMS *

m=video 9 RTP/SAVPF 97

a=rtpmap:97 VP8/90000

a=framesize:97 640-480

a=control:trackID=1

c=IN IP4 0.0.0.0

a=sendrecv

a=ice-pwd:25612477f44890c3ea8ef6d869863c7d

a=ice-ufrag:29f30a8a

a=mid:video

a=msid:{c804aeb0-63c6-4f13-9b7f-bf057c06b0d9} {99aca8f9-89ff-45ef-9819-1403fe6c6bea}

a=rtcp-fb:97 nack

a=rtcp-fb:97 nack pli

a=rtcp-fb:97 ccm fir

a=rtcp-mux

a=setup:actpass

a=ssrc:1265994212 cname:{60bd5c79-3da5-449a-a2a0-0c2172e8aae3}

2

Hey Anthony did you get this resolved? we have the same issue and we keep retrying as well however the speed of the first watch time has increased signaficantly.

1 Like
3

I have the same problem. Anyone has solved this problem

4

Anyone? Same issue here

5

Bruce, what version of Wowza Streaming Engine are you running?

6

Version 4.8.

Just updated to 4.8.5 today and still no audio.

Audio works in Wowaz Player though, but really want to move to WebRTC ASAP.In terms of the testing…

  1. Audio works in stream direct from camera on URL rtsp://203.190.214.223:554/s0
  2. Incoming stream is rtsp://203.190.214.223:554/s0 and is Active.
  3. Audio works in stream from Wowza on :1935 using Wowza Player
  4. No audio if using WebRTC despite hours and hours of trying many JS configurations.

The BUNDLE just never has “audio” in it.

7

I missed your comment here, my apologies. Have you created a ticket for this issue?

You are not ingesting WebRTC, but you are looking for WebRTC playback? The audio codec should be Opus for WebRTC playback, can you confirm? Are you running this with our WebRTC example repo? https://github.com/WowzaMediaSystems/webrtc-examples What browser?

We would need to take a look at your SDP offer to see if there are any other configurations that might need to be tweaked. That’s probably easier to do over a support ticket.

8

I missed your comment here, my apologies. Have you created a ticket for this issue?

You are not ingesting WebRTC, but you are looking for WebRTC playback? The audio codec should be Opus for WebRTC playback, can you confirm? Are you running this with our WebRTC example repo? https://github.com/WowzaMediaSystems/webrtc-examples What browser?

We would need to take a look at your SDP offer to see if there are any other configurations that might need to be tweaked. That’s probably easier to do over a support ticket. @Bruce Trevarthen

9

I'm experiencing the same issue. For me it happens when the same browser tab is switching streams. 

The scenario is something like this:

1. Publisher A is publishing WebRTC stream.

2. Consumer A is connecting to that stream via WebRTC -- initially it works as expected, both video and audio are present.

3. From the same respective open tabs, both Publisher and Consumer are redirected to a new stream (the Publisher starts a new stream on click and the Consumer is redirected to this new stream) -- now the Consumer doesn't receive audio of this new stream. However if another Consumer B connects freshly to this stream, audio works for them.

Like @Anthony_Lee1 I also noticed that initially there are both audio and video present in the SDP, but after the explained issue, the audio segment is missing from SDP.

Here is the printed SDP data when everything works fine:

SDP Data: v=0
o=WowzaStreamingEngine-next 1813942930 2 IN IP4 127.0.0.1
s=-
t=0 0
a=fingerprint:sha-256 07:77:5B:86:B2:E9:1F:55:92:21:D9:B8:CC:6F:75:2E:80:5F:D3:78:59:EE:25:D4:F5:75:67:B1:3E:A4:5E:5F
a=group:BUNDLE video audio
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 9 RTP/SAVPF 97
a=rtpmap:97 VP9/90000
a=framesize:97 400-300
a=control:trackID=2
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:02d484ca0f0092d9f9007d877fa430b4
a=ice-ufrag:aa30463f
a=mid:video
a=msid:{6e65eb36-7683-4df1-b9a6-8cfb21078ac4} {c8786d00-80d9-4ce8-9239-02fd627a80ea}
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-mux
a=setup:actpass
a=ssrc:1195269614 cname:{6775451f-fbcd-4277-a361-12446dca1122}
m=audio 9 RTP/SAVPF 96
a=rtpmap:96 OPUS/48000/2
a=control:trackID=1
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:02d484ca0f0092d9f9007d877fa430b4
a=ice-ufrag:aa30463f
a=mid:audio
a=msid:{6e65eb36-7683-4df1-b9a6-8cfb21078ac4} {15f4b287-c6fc-4739-a14d-c0b3eeb030e8}
a=rtcp-mux
a=setup:actpass
a=ssrc:1150413031 cname:{6775451f-fbcd-4277-a361-12446dca1122}

And here it is with missing audio:

SDP Data: v=0
o=WowzaStreamingEngine-next 607585388 2 IN IP4 127.0.0.1
s=-
t=0 0
a=fingerprint:sha-256 07:77:5B:86:B2:E9:1F:55:92:21:D9:B8:CC:6F:75:2E:80:5F:D3:78:59:EE:25:D4:F5:75:67:B1:3E:A4:5E:5F
a=group:BUNDLE video
a=ice-options:trickle
a=msid-semantic:WMS *
m=video 9 RTP/SAVPF 97
a=rtpmap:97 VP9/90000
a=framesize:97 400-300
a=control:trackID=1
c=IN IP4 0.0.0.0
a=sendrecv
a=ice-pwd:a57f28b9962bb7b7e0a020b6f193549b
a=ice-ufrag:b5bf0c44
a=mid:video
a=msid:{5914c072-94aa-45d8-a2ac-99c4271badc8} {d6364d7c-f0bc-46fc-b823-07c33c414d7e}
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-mux
a=setup:actpass
a=ssrc:519094035 cname:{438d925a-0add-49db-b40d-6efe2698a83a}

I am using Wowza Streaming Engine 4.8.5 [build20200616153358]

I've also updated javascript files used for playback, as found here: https://github.com/WowzaMediaSystems/webrtc-examples

I am testing on macOS Catalina version 10.15 and Chrome Version 85. I've also tested on other systems such as Linux + Brave, Chromium and the same issue persists.

Is there a solution to this?

10

Hi @Ana_B, are you using the same audio source for both streams and are they both Opus?
Our engineers would like to have a better understanding of your workflow to see if the session destroy path is not working correctly, if the reconnect is causing a change in the codecs or if this is an issue with your audio codec config.

We can only debug in a support ticket where you upload all your Engine files and logs.
https://www.wowza.com/support/open-ticket