Test request: WebRTC/TCP function has been updated

[getroot]

I updated WebRTC/(TURN)/TCP and committed it to Master. For this, TURN server is built into OvenMediaEngine.

Set <StunServer> and <TcpRelay> in Server.xml as follows: You can play stream using WebRTC over TCP by adding transport=tcp query string to the existing webrtc url.

ws://host:port/app/stream?transport=tcp

<Server version="8">
    <IP>*</IP>
    <!-- 
    To get the public IP address(mapped address of stun) of the local server. 
    This is useful when OME cannot obtain a public IP from an interface, such as AWS or docker environment. 
    If this is successful, you can use ${PublicIP} in your settings.
    -->
    <StunServer>stun.l.google.com:19302</StunServer>

    <!-- Settings for the ports to bind -->
    <Bind>
        <Publishers>
            <WebRTC>
                <Signalling>
                    <Port>${env:OME_SIGNALLING_PORT:3334}</Port>
                </Signalling>
                <IceCandidates>
                    <TcpRelay>*:3478</TcpRelay>
                    <IceCandidate>*:10000-10005/udp</IceCandidate>
                </IceCandidates>
            </WebRTC>

This helps to play very smoothly in environments where the network speed is high but UDP packet loss is abnormally high.

I've noticed that this feature plays very smoothly in my environment where I forced more than 5% packet loss. (Of course, the network speed should be fast.)

I want to test this in a variety of environments. Test this in your environment and tell us the results. Thank you.

[getroot]

This is a manual for WebRTC/TCP.

https://airensoft.gitbook.io/ovenmediaengine/v/0.11.1/streaming/webrtc-publishing#webrtc-over-tcp

[getroot]

Create URL rules for WebRTC/TCP

Requesting OvenPlayer to play ws(s)://host:port/app/stream?transport=tcp allows it to receive media streams over TCP

[getroot]

Since we updated to get public IP through StunServer, you can now use in TcpRelay and IceCandidate. (IceCandidate sometimes did not play when was used in some environments, but it is now resolved.)

<Server version="8">
    <IP>*</IP>
    <!-- 
    To get the public IP address(mapped address of stun) of the local server. 
    This is useful when OME cannot obtain a public IP from an interface, such as AWS or docker environment. 
    If this is successful, you can use ${PublicIP} in your settings.
    -->
    <StunServer>stun.l.google.com:19302</StunServer>

    <!-- Settings for the ports to bind -->
    <Bind>
        <Publishers>
            <WebRTC>
                <Signalling>
                    <Port>${env:OME_SIGNALLING_PORT:3334}</Port>
                </Signalling>
                <IceCandidates>
                    <TcpRelay>*:3478</TcpRelay>
                    <IceCandidate>*:10000-10005/udp</IceCandidate>
                </IceCandidates>
            </WebRTC>

[S3-sim]

Tested in firefox 85.0.2 and found that it would not establish a connection. The player received the candidates, but they stayed stuck on "in-progress" when monitoring the connection in about:webrtc in firefox.

Tested in chrome 88.0.4324.15 and the TcpRelay worked as expected.

In the server config, the public IP of the server was specified for both Ice and Relay, wildcard was not used.

Server version tested was before the fix that allows wildcard to work for Tcp Relay.

[cesarandreslopez]

Just a question here, does this change the required ports to be opened if running via Docker?

[getroot]

@S3-sim Thanks for testing in your environment! I am checking for compatibility with Firefox. I will comment again.

[getroot]

@cesarandreslopez

Yes you need to open port 3478/tcp by default.

If the docker's HOST is a host that cannot be accessed with the public IP extracted by stun (private network), the IP of the host must also be specified in TcpRelay.

[getroot]

@S3-sim I have improved the WebRTC/TCP function to work in Firefox as well. Thank you for reporting.

[S3-sim]

@getroot fantastic, I will start testing again. I had users reporting that there were earlier versions of chrome that was also having problems connecting as well. I will try and get a report of what version was not working.

Is there a failover function that after X amount of time, would bypass the tcprelay for clients that are having problems establishing a connection?

[getroot]

@S3-sim If you register both ws://host/app/stream?transport=tcp (tcp version) and ws://host/app/stream (udp version) in OvenPlayer, it will failover to the other if one connection is disconnected. (OvenPlayer implemented this function before, but I will check with the Player developer to see if it works well)

Problems that don't work in Chrome may have been solved by fixing firefox this time. While fixing the firefox issue, we fixed several bugs together.

[S3-sim]

Looks like the fixes worked. Firefox and older chrome versions do appear to connect without issue.

I have now run into another issue. When streaming to a single client, the server reports the following error:

WebRTC Publisher Application/#default/#app/phoenixhr_webrtc StreamWorker Queue size has exceeded the threshold: queue:500, threshhold: 500, peak:2011

The client will also disconnect from the stream and reconnect almost immedietly. I tried it on a connection i know to be unstable and a second connection that has been stable with UDP based streams and both resulted in the same behaviour.

[getroot]

@S3-sim Thanks for the report.

We are now improving the structure of the Send Socket. As one thread sends multiple sessions in blocking mode, if one session is slow or jammed, it affects other sessions.

It could be an issue related to this. I will continue to test stability.

[S3-sim]

@getroot

I wasn't sure if any of the recent work done was meant to address the send socket issue. I recompiled today and did some further testing and found the issue is persisting. Even without a high packet loss client I found that over time I was receiving queue errors but at a much slower rate.

[getroot]

Currently, if one player network is slow, there is a problem that affects all players. It is still being improved.

As you know, TCP tries to retransmit, so you need a fast network to play smoothly. On slower networks, the server's buffer overflows, which can result in a lower quality than UDP. TCP transmission can perform better than UDP in a "fast but high packet loss" network environment.

[getroot]

@S3-sim Fixed an issue where slow players could affect other players. We would appreciate it if you could check if your issue is resolved.

[S3-sim]

@getroot I am compiling 0.11.1 right now. I will report back in the next few days.

[S3-sim]

@getroot It looks like the issue has been resolved. With 25 players simulating 5% packet loss, and 25 players running under normal conditions the server did not seem to encounter any issues. I'm putting this build into production today so I will report back if I encounter any other issues.

[getroot]

@S3-sim Thank you so much for your testing. We want to test in a variety of environments, so your tests are of great help to us.

We will be urgently releasing 0.11.2 soon.(probably tomorrow) This is because some serious bugs were discovered in 0.11.1. (Origin-Edge issues, etc.) Therefore, it would be better to apply 0.11.2 to production.

[getroot]

Today I applied this feature to the default configuration. If you find another issue, please open a new issue. Thank you for all of your contributions.