You have successfully setup a video call (any combination of browser to browser / iPad to device / iPad to browser etc.) and you are seeing poor video / video freezing.
Video issues in WebRTC are usually caused by poor network conditions such as:
Packet Loss = picture loss / video drops out / skipping
Hight Jitter / poor latency / poor bandwidth = video freezing
As a rough estimate your going to need 1.2 MB bandwidth in each direction for a WebRTC voice & video call. So if your at home with narrow band broadband a WebRTC call could eat up your pipe.
Things to check:
MB & Client resources.
Does the MB have plenty of resources available? E.g. does it have 8GB of RAM (with some free) & how is it's CPU usage looking. Can be checked with top command.
Ditto for the client, how is it's CPU?
Network - Is there poor network conditions.
1. On a call check the app connection callback indicator.
While on a call check the network loss indicator, is it red, yellow or green? In iOS the network indicator is a small WiFi symbol in top right of video pane. On the web sample app (csdk-sample) it's a solid green bar underneath the video window shows a good connection.
Good connection example:
For a poor connection it will show red an in the browser console you can see the the connection quality callback changing down from good (100 / 90) to not so good (60).
Poor connection example:
Please see Connection Quality Indicator for more details on the connection quality indicator.
2. Check webrtc-internals (in-call)
When in a call in Chrome open a new tab and navigate to chrome://webrtc-internals and look for ssrc_<number>_send video.
This is external to CaféX (It's Chome's internal tool).
You're looking for low / no packet loss, a good bitsSentPerScond rate etc..
From a good call:
Also check the ssrc_<number>_recv video graph and look for the same:
From a good call:
Also good to check what Chrome thinks it has as available with bweforvideo:
For Firefox you need to browse to about:webrtc when in an active call and select the session statistics
Then take a look at the ICE stats
Finally we have the RTP stats (look for lost packets and high jitter as a warning sign)
3. Post-call, check the call logging in the WPF (needs to be enabled)
After a call & if enabled check the call log in the WPF:
https://<server-address>:8443/web_plugin_framework/webcontroller --> Call Log.
Here's an example of a call to Cisco CIUS from csdk-sample:
Above you can see nice low levels of Jitter. Very few packets reported as dropped or lost.