publish_finished critera -

[Nagendra Kumar1648581702]

Hello Team AntMedia,

   Is there any criteria for event publish_finished? We are trying to handle the bad network scenario and sometimes I see  publish_finished event even though WebSocket is connected. Is there any timeout configured on the server that monitors the incoming data on ice connection and we can configure this?

We want to close the connection when the client stops publishing or WebSocket get disconnected. In the real-world there could be an intermitted network issue and it shouldn't be considered as publish_finished.

 

Thanks

Nagendra

[Enes Kuluk]

Criterias for publish_finished are: If publisher stops publishing, if ice connections drops, if ice connections are not established, If server don't get data(video, audio) server timeouts and sents publish_finished notification. 

Sometimes tcp connection can disconnect and reconnect in this case there is no notifcation. 

For your question, if the WebSocket gets disconnected, how server can send publish_finished notification to the websocket?

You can check auto republish if required in the index.html here: https://github.com/ant-media/StreamApp/blob/master/src/main/webapp/index.html#L346

Regards.

 

[Nagendra Kumar1648581702]

Hi Enes,

   As per the code in this link 

                https://github.com/ant-media/StreamApp/blob/master/src/main/webapp/index.html#L346

var iceState = webRTCAdaptor.signallingState(streamId); if (iceState == null || iceState == "failed" || iceState == "disconnected"){

In this code we are getting signallingState  but signalling state has  not such values. = failed or disconnected https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/signalingState  

I think the above code is incorrect.

Thanks

Nagendra

[Enes Kuluk]

You are correct in that manner. 

var iceState = webRTCAdaptor.signallingState(streamId); 

line should be 

var iceState = webRTCAdaptor.iceConnectionState(streamId);  

Best Regards,

Enes Kuluk.

 

[Nagendra Kumar1648581702]

As per my understanding, there is one more bug in 

var iceState = webRTCAdaptor.iceConnectionState(streamId);  

if (iceState == null || iceState == "failed" || iceState == "disconnected"){

restartTheConnection.}

As per the webrtc article iceState = "disconnected"

Wordings from official documentation ==>

"Checks to ensure that components are still connected failed for at least one component of the RTCPeerConnection. This is a less stringent test than "failed" and may trigger intermittently and resolve just as spontaneously on less reliable networks, or during temporary disconnections. When the problem resolves, the connection may return to the "connected" state."

In fact we practically experienced this. Sometimes connection is disconnected and with this logic reconnection happened and we found weird user experience (of stopping and reconnecting)

So it means we shouldn't do a connection restart in disconnected state. 

Please correct me if I am wrong. We recently got a no of issues on reliability of the connections and we all got this in investigation.

thanks

Nagendra

[Enes Kuluk]

Disconnected has added to the if statement because server shuts down the connections if they become disconnected. So, main reason that is added was server's behaviour. I think you can test it out and report to the community if your findings are worth to try.

Best Regards,

Enes Kuluk.

[Nagendra Kumar1648581702]

Thanks, Enes for this critical information. Now I can connect most of the issues that we see in production with a poor network connection. We found that sometimes we see the iceState changed to disconnected and if this remained disconnected for 5-10 seconds then we receive the  publish_finished from the server. Since most of the connection issues arise from the client-side so the client should rather wait for the server to finish. I was able to repo this behavior with a network simulator and high packet loss. In this case connection switch from connected to disconnected and back to connected. We removed the disconnected state (on retry check) and the experience was much better here.

One more question - where is this time out on server side  (Is it configurable) that checks the disconnected state and shutdown the connections (I believe this finally triggers publishing_finish). You mentioned that If server don't get data(video, audio) server timeouts and sents publish_finished notification. This is exactly what we observed. Is this configurable?

thanks

Nagendra

 

[Anoop Kumar Pandey]

Dear Nagendra,

           I have faced a similar problem. One of the participants in a 1:1 conference room video call based on WebRTC suddenly disconnects. This happens frequently sometimes. I am using older code (2.0 version) which didn't have republish code. Your findings are good. I request you to share the rectified javascript code for this file. I'll update and observe the effect on the poor network connection.

 

Regards,

Anoop

 

[Nagendra Kumar1648581702]

Hello Enes,

    Just following up on the timeout configuration of  published_finished.  Ideally I want the retry to happen when we webocket is down. So if we can increase the published_finish timeout then in bad network experience could be better. As of now the moment (for 5-7 seconds) we see bad network then we get published_finished is received and we have to re setup entire connections.

Thanks

Nagendra

[Enes Kuluk]

Hello Nagendra,

Sorry for the delay, somehow i miss out this topic.

Yes, publish timeout delay can be increased.

In Ant Media Server/webapps/(LiveApp or WebRTCAppEE)/web_inf/red5-web.properties file, you can add settings.webrtc.client.start.timeoutMs with equal to your desired number.

Default value is 5000 which is 5 seconds.

Best Regards,

Enes.

 

[Olga Taqwawi]

It doesn't affect anything enes. The timeout still 5000

 

 

[Enes Kuluk]

Did you restarted Ant Media Server after you made the modification?

Best Regards,

Enes.