Do most browsers really support WebRTC? - as of April 2019

Updated: Aug 12

We are working OvenMediaEngine (OME), an open source project that streaming by a latency of less than 1 second is available using WebRTC protocol. Furthermore, in the OME project, we intend to develop and introduce P2P Delivery function that can save system resources and budget during streaming.

However, we sometimes receive inquiries from our open source users that they cannot stream with WebRTC. The problem of being unable to play with WebRTC in our Ultra-Low Latency Streaming project has a possibility of causing significant issues soon even though there is an alternative protocol right now.

Most web browsers such as Chrome, Safari, Firefox, and Edge have already announced that they support WebRTC, so we have trusted. Nevertheless, we were curious about how browsers in a long distance can exchange data. Also, we analyzed the reasons for differences between cases of streaming smoothly and cases of not. We did for the community and us.


Streaming sent out from Windows 10 Edge (18) cannot be played on the public network.

The Edge browser cannot make a candidate of public IP from STUN.

Safari cannot play a stream of the private network.

Safari does not create a candidate of local IP. That’s why it cannot play the stream from other peers in the same private network.

Safari should secure the authority in a capture device for creating a local candidate in a security reason. Moreover, if you want to test in Safari for desktop, you need to select "Disable ICE Candidate Restrictions." in the menu of [Develop] → [WebRTC] and reload the relevant page.

Safari and Android Chrome (50) are not compatible with each other.

Literally, Safari and Android Chrome(50) can’t play each other’s stream.

Testing Process

WebRTC needs a process of signaling to adjust communication among browsers. In this process, a caller uses Offer Session Description Protocol (SDP), and a callee uses Answer SDP to exchange each other’s media information.

We created each SDP using a lot of codec information that SDP includes and tested to confirm which options certain browsers’ codec Offer, which options they Answer, and whether the stream is normally played.

This picture briefly expresses the process of exchange between Offer SDP and Answer SDP.

Signaling is processed in the following way: When Caller offers by containing various types of the codec in SDP, Callee answers playable codec.

This figure was made to show you the exchange process that we organized for the test.

We tested the following:

  1. Extract all codecs and option information existing internally by dissembling Offer SDP.

  2. Create a new Offer SDP that has each codec. (Test 2 to 6).

  3. Execute WebRTC Signaling by crossing the original Offer SDP (Test 1) and multiple newly created Offer SDPs (Test 2 to 6) on each browser.

  4. Store Offer SDP, Answer SDP, each browser’s user agent, and whether streaming succeeds or fails as data.

Cross test in the browsers of Caller and Callee. And the test result is stored in our database.

This test is a primary step and processed based on the version used by most people. However, we promise to test all OS and browsers possible by investing more time and efforts for our project.

  • Windows: the most used version.

  • MacOS: the most used version, and Safari 11.

  • Ubuntu: the most used version.

  • Android: the most used version, and the minimum version that supports WebRTC.

  • iOS: the most used version, and Safari 11.

  • Reference: StatCounter (the latest: as of 2019-03-25).

When the test is done in the same condition, but the results can be sometimes different. For example, some streams played a few seconds ago, but cannot stream all of a sudden. Certain streams do not play unless it is a specific codec. These phenomena frequently happened at Windows 10 Edge and Safari.

We thought these phenomena are the stability problems of WebRTC that uses UDP, and later the results became stable as we used TURN server. However, not everyone can use stable TURN server in WebRTC service environment, so these results do not indicate 100% stability. Therefore, we decided to analyze the causes further.

#01. STUN issue in Windows Edge browser

We checked STUN problem in Windows Edge browser by accessing The trickle ICE functionality in a WebRTC implementation in Window 10, and we found out Edge browser was the only one that could not create a candidate of public IP through STUN. In other words, if TURN is not enabled, peers located in different networks cannot play WebRTC streams sent from the Edge.

#02. Problems with ICE Candidate Restrictions in Safari

Regarding ICE Candidate Restrictions in Safari, Safari could not generate a candidate of private IP. It is on the contrary to Windows Edge. In other words, if TURN is disabled, Safari cannot play WebRTC streams transmitted by other peers in the private network.

When we first tested on Safari, this problem did not occur. Ironically, this happened as “Disable Safari ICE Candidate Restrictions.” was added to the developer option in Safari for Mojave. We thought this is a chronic problem with previous versions of Safari. However, we noticed that all versions of Safari are blocking the relevant function due to a security problem.

That is, if you want to play stream sent from the private network in Safari, you either need to turn on the relevant option (Disable Safari ICE Candidate Restrictions) in the developer option of Safari, or need to set permissions for the camera and microphone.

Test Result

This record is the cross-codec test result between Caller and Callee that we have done so far. Also, the reason that the number of digits is different in each cell is codecs that each browser supports are different.

The meaning of the numbers in each cell is as follows:

  • 1: Streaming success.

  • 0: Codec option is different, but streaming is successful.

  • -1: Streaming failed.

The meaning of the colors in each cell is as follows:

  • Green: One or more matched the codec type and option between Caller and Callee, and the streaming succeeded.

  • Yellow: No matched the codec option, but the streaming succeeded.

  • Gray: Streaming failed.

We used the TURN server to solve the Edge and Safari problems mentioned above, but Safari for iOS 11 cannot play a stream transmitted from Firefox. Also, we confirmed that Safari and Chrome (50) for Android could not communicate with each other in our test.

Moreover, we will release detailed options and results for our test when the relevant data becomes more solid by repeating tests over and over again. Please wait a little bit longer.

Ending the first test

Lastly, we could find an answer to “When a user using Safari for iPhone becomes a client peer why cannot stream?”. However, there was no discord between codecs of different browsers, unlike our forecast. Rather, the network issues related to STUN/TURN hindered our testing, and we determined that STUN/TURN was a major cause of being unable to play stream usually in service environments with WebRTC utilized.

Therefore, if you build a separate TURN server and develop by considering Edge and Safari browser mentioned above, you will provide the streaming service with WebRTC to your customers very stable.


This is the first result we have tested for WebRTC compatibility on each browser, and it will be updated continuously. Thank you for sparing your time to read this!

1,171 views0 comments