Wowza Community

WebRTC javascript reconnect due network issues


We are updating Wowza for the last builds, since we need more compatibility as possible, and seems wowza last releases have improvements for webrtc.

On old versions, we had make our javascript manually to handle the webrtc connection and streaming.

For this new release, we found a SDK kind, with wowza examples for webrtc in Javascript.

Our company have a lot of clients, which will publish streams in places with poor connections, so we made a manual logic to reconnect, just listening the peer connection oniceconnectionstatechange event, trigering a connect again when receives bad status at this handler, like ‘closed’ or ‘failed’.

But on this code example of Wowza, we found a issue to make this reconnects, since websocket and peer connection are set to variables, and are overwriten at all connect events. And the close event for websocket and peer connection are asynchronous.

When we close a previous connect, and connect again, the websocket and peer connection are not completely closed yet, so we get a lot of websocket connections stucked in browser. And the close statement could not be completed after the same variable is already with a new connection. May be this could bring problems to the new connection, since some status listener can handle an old disconnection, and assign it to the new connection, causing a kind of infinite loop, and unpredictable bugs.

I put some logs on the WowzaPeerConnectionPublish.js to get a example:

wsConnection.onclose = function () {
    console.log("PeerConnectionPublish.wsConnection.onclose at " + new Date().getTime());}

function wsConnect(url) {
  		console.log("Creating a websocket at " + new Date().getTime());
    	wsConnection = new WebSocket(url);

function stop ()
  	if (wsConnection != null)

If I call WebRTCPublish.stop() and after call WebRTCPublish.start(), I get this info at browser console:
Creating a websocket at 1604004046072
PeerConnectionPublish.wsConnection.onclose at 1604004046085

The code is creating a new websocket, assign to a variable before the connection is effective closed.

On the old code that we make manually for older versions, we create like a factory of websocket and peerconnections to avoid this issue. For example
let websocket = [];
let pc = [];
let current = 0;

function get_websocket()
	if (typeof websocket[current] != 'undefined' && websocket[current] != null)
		return websocket[current];

	return null;

function get_peer_connection()
	if (typeof pc[current] != 'undefined' && pc[current] != null)
		return pc[current];

	return null;

//on connect
close_websocket(); // close previous connections
websocket[current] = new WebSocket(publish_url);
get_websocket().binaryType = 'arraybuffer';		
get_websocket().onopen = function(){}
// continue
pc[current] = new RTCPeerConnection(pc_config); 					
get_peer_connection().onicecandidate = function(){}
// continue

function close_websocket()
		var socket = get_websocket();
		if (socket && socket.readyState != socket.CLOSED)
			websocket[current] = null;			

Exist a better way to make a reconnect without get a lot of wbesocket and peer connections stuck on browser? A way when a previous disconnect do not influence at the new connection, using the wowza javascript example?
May be the best approach would be using promises, and waiting socket and peer connections real closed event before create a new connection.

If I can already leave a suggestion, it would be very interesting if the wowza made a real SDK, compiled, accompanying the back end version, and with new releases and patches.
Is hard to get the updates by wowza currently javascript examples.


Hello @Michael_G welcome to the wowza forums.

Thank you for sharing your information, but I will need to tell you that at this time, a webrtc workflow in poor network conditions will require that you manually restart each SDP session/connection and we don’t have a way for you to automatically connect as far as peer to peer. You will have to do this manually.

At this time we do not have any plans to offer a WebRTC SDK. You may want to consider LL-HLS as another option for very low latency if you do not require live interaction.

Our WebRTC workflow is better suited for one to many or few to many, but it will be difficult with poor network conditions. Hope that gives you some direction as far as what Wowza can and cannot offer as far as your workflow needs.

We are already using HLS for subscribers to play the live streaming.

Our business is a live broadcast one to many.

Do you have any WebRTC alternative to publish in a browser? (I know you have Flash, but it will be deprecated soon).