Are You Using AppRTC as Your WebRTC Baseline Reference?

If you aren’t using AppRTC yet then you should start.

I had a few customers last month who had quality issues with their service. They were trying to understand the root cause of these issues, and at times, the question raised was “is WebRTC up for the task?”

• Does the poor audio quality we experience in our service derive from the codec, the browser’s implementation or something in our own backend?
• Are the video stutters stem from heavy packet loss and that’s just life – or are we adding some of our own issues into the mix?
• The average bitrate we reach in a call. Is it because the browser is limiting us? Is it because the connection is bad? Is it…

The list goes on.

The fact that now you get a fully implemented media engine in the browser for free is great. The problem is, it gives you (or your developers) the opportunity to blame the browser: It isn’t us. Google’s engineers did such a crap job with X that we just can’t fix it.

More often than not – this won’t be the problem.

When in doubt – check AppRTC

Google launched AppRTC quite some time ago.

AppRTC is Google’s way of showcasing WebRTC in their simplest version of the “Hello World” program. This being WebRTC, there are many moving parts, but to some extent, AppRTC is rather baseline – especially in its dealings with media.

This makes AppRTC a great baseline reference when you have issues with the media paths of your own service or just want something to compare it with.

Got an issue? Test what happens when you run AppRTC and compare it with your own service. If you see that your service isn’t performing in the same manner, chances are the problem is on your end – and now you can start diverting focus and resources towards searching the problem instead of blaming the browser.

Where to look for the problems?

• Your NAT traversal servers, if they are being used
• Are you doing any backend processing for the media? Map your pipeline there. Check each step of that pipeline to see if it is to blame
• Transcoding never fails to fail you – check there if you use it
• Jitter buffers are notoriously… jittery. Make sure the implementation fits your use case
• Network routes and handling dynamic bitrates and packet losses might be handled nicely by the browser, but is your backend up for the task as well?

Don’t forget test.webrtc.org either

Google has another great analysis tool – test.webrtc.org

You open the settings, insert your own STUN and TURN server configuration – and start the test.

It will then check the system and network connections to give you a nice view of what the browser is experiencing – something you can later use to understand the environment you operate in.

Why is this important?

With WebRTC, it is easy for developers to blame the browser. This isn’t productive.

Your first task should be to create a baseline reference you can trust. One that enables isolating the issues you are experiencing systematically.

AppRTC is a good place to start.