{"id":19845466,"url":"https://github.com/opentok/opentok-network-test","last_synced_at":"2025-05-01T21:30:36.209Z","repository":{"id":37819394,"uuid":"38269414","full_name":"opentok/opentok-network-test","owner":"opentok","description":"Sample app to test network connectivity and statistics (bps, packet-lost)","archived":false,"fork":false,"pushed_at":"2023-09-08T09:02:40.000Z","size":854,"stargazers_count":111,"open_issues_count":20,"forks_count":56,"subscribers_count":78,"default_branch":"master","last_synced_at":"2024-04-23T03:37:40.449Z","etag":null,"topics":["android","ios","opentok","tokbox","webrtc"],"latest_commit_sha":null,"homepage":null,"language":"Objective-C","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/opentok.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2015-06-29T20:24:36.000Z","updated_at":"2023-09-18T16:02:22.000Z","dependencies_parsed_at":"2022-08-19T11:20:52.363Z","dependency_job_id":null,"html_url":"https://github.com/opentok/opentok-network-test","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/opentok%2Fopentok-network-test","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/opentok%2Fopentok-network-test/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/opentok%2Fopentok-network-test/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/opentok%2Fopentok-network-test/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/opentok","download_url":"https://codeload.github.com/opentok/opentok-network-test/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":224278479,"owners_count":17285080,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["android","ios","opentok","tokbox","webrtc"],"created_at":"2024-11-12T13:08:00.116Z","updated_at":"2024-11-12T13:08:01.026Z","avatar_url":"https://github.com/opentok.png","language":"Objective-C","funding_links":[],"categories":[],"sub_categories":[],"readme":"OpenTok Network Test\n====================\n\nThis repository contains sample code that shows how to diagnose if the client's call (publishing\na stream to an OpenTok session) will be successful or not, given their network conditions. The\nnetwork test can be implemented as a step the client runs before joining the session. Based on the\ntest results, the app can decide if the client should be allowed to publish a stream to the session\nand whether that stream should publish video or use audio-only mode. The test is intended to be used in a\nsession that connects two clients in a one-to-one call.\n\nThe network test is supported in:\n\n*  [OpenTok Android SDK 2.12 and newer](https://tokbox.com/developer/sdks/android/)\n*  [OpenTok iOS SDK 2.12 and newer](https://tokbox.com/developer/sdks/ios/)\n\nJavaScript clients should use the sample code found here:\nhttps://github.com/opentok/opentok-network-test-js.\n\n## How does it work\n\nThe sample apps each do the following:\n\n1. Connect to an OpenTok session and publish a test stream to a test session.\n\n   Note that the published test stream would be visible to all clients connected to\n   the session. For this reason, you should use a separate test session (with a unique\n   session ID) for the network test.  Do not use the test session for your actual call.\n   Use a separate OpenTok session (and session ID) to share audio-video streams between\n   clients.\n\n2. Subscribe to your own test stream for a test period.\n\n   During the test period, the video quality will stabilize, based on the available network\n   connection quality.\n\n3. Collect the bitrate and packet loss statistics using the Network Stats API (see below).\n\n4. Compare the network stats against thresholds (see below) to determine the outcome of the test.\n\nPlease see the sample code for details.\n\n## Network Stats API\n\nThis API lets you dynamically monitor the following statistics for a subscriber's stream:\n\n* Audio and video bytes received \n\n* Audio and video packets lost\n\n* Audio and video packets received\n\nThis API is only available in sessions that use the OpenTok Media Router.\n\n## Thresholds and interpreting network statistics\n\nYou can use the network statistics to determine the ability to send and receive streams,\nand as a result have a quality experience during the OpenTok call.\n\nPlease keep in mind, every application's use case and every user's perception of the call \nquality is different. Therefore, you should adjust the default thresholds and timeframe in \naccordance with your use case and expectations. For example, the 720p, 30 fps video call \nrequires a much better network connection than 320x480-pixel, 15 fps video. So, in that case,\nyou need to set much higher threshold values in order to qualify a viable end user connection.\nAlso, the longer you run the test, the more accurate the values you will receive will be. \nAt the same time, you might want to switch between publishing video and audio-only, based on\nyour specific use case. \n\nThe OpenTok Network Test is implemented as sample code to make it easier\nfor developers to customize their application logic.\n\nBelow are examples of the thresholds for popular video resolution-frame rate combinations.\nThe following tables interpret results (for audio-video sessions and audio-only sessions),\nwith the following quality designations:\n\n* Excellent - None or imperceptible impairments in media\n\n* Acceptable - Some impairments in media, leading to some momentary disruptions\n\n### Audio-video streams\n\nFor the given qualities and resolutions, all the following conditions must met.\n\n| Quality    | Video resolution @ fps | Video kbps  | Packet loss |\n| ---------- | ---------------------- | ----------- | ----------- |\n| Excellent  | 1280x720 @ 30          | \u003e 1000      | \u003c 0.5%      |\n| Excellent  | 640x480 @ 30           | \u003e 600       | \u003c 0.5%      |\n| Excellent  | 352x288 @ 30           | \u003e 300       | \u003c 0.5%      |\n| Excellent  | 320x240 @ 30           | \u003e 300       | \u003c 0.5%      |\n| Acceptable | 1280x720 @ 30          | \u003e 350       | \u003c 3%        |\n| Acceptable | 640x480 @ 30           | \u003e 250       | \u003c 3%        |\n| Acceptable | 352x288 @ 30           | \u003e 150       | \u003c 3%        |\n| Acceptable | 320x240 @ 30           | \u003e 150       | \u003c 3%        |\n\nNote that the default publish settings for video are 640x480 pixels @ 30 fps in the\nOpenTok iOS SDK. The default is 352x288 @ 30 fps in the OpenTok Android SDK.\n\nYou can calculate the video kbps and packet loss based on the video bytes received and\nvideo packets received statistics provided by the Network Statistics API. See the sample app\nfor code.\n\nThe video resolutions listed are representative of common resolutions. You can determine support for\nother resolutions by interpolating the results with the closest resolutions listed.\n\n### Audio-only streams\n\nFor the given qualities, the following conditions must met.\n\n| Quality    | Audio kbps | Packet loss |\n| ---------- | ---------- | ----------- |\n| Excellent  | \u003e 30       | \u003c 0.5%      |\n| Acceptable | \u003e 25       | \u003c 5%        |\n\nNote that you can calculate the audio kbps and packet loss based on the audio bytes received\nand audio packets received statistics provided by the API. See the sample apps for code.\n\n## Sample code\n\nThis repo includes sample code showing how to build a network test using the\nOpenTok Android and iOS client SDKs. Sample code for the OpenTok JavaScript SDK\ncan be found here: https://github.com/opentok/opentok-network-test-js. Each \nsample shows how to determine the the appropriate audio and video settings to \nuse in publishing a stream to an OpenTok session. To do this, each sample app \npublishes a stream to a test session and then uses the Network Stats API to\ncheck the quality of that stream. Based on the quality, the app determines what \nthe client can successfully publish:\n\n* The client can publish an audio-video stream at the specified resolution.\n\n* The client can publish an audio-only stream.\n\n* The client is unable to publish.\n\nEach sample subdirectory includes a README file that describes how the app uses the network\nstats API.\n\n## Frequently Asked Questions (FAQ)\n\n* Why does the OpenTok Network Stats API values are different from my Speedtest.net results?\n\n  Speedtest.net tests your network connection, while the Network Stats API shows how\n  the WebRTC engine (and OpenTok) will perform on your connection. \n\n* Why are the Network Stats API results inconsistent?\n\n  The WebRTC requires some time to stabilize the quality of the call for the specific\n  connection. If you will allow the network test to run longer, you should receive\n  more consistent results. Also, please, make sure that you're using routed OpenTok session\n  instead of a relayed on. For more information, see [The OpenTok Media Router and media\n  modes](https://tokbox.com/developer/guides/create-session/#media-mode)\n\n* Why the output values are really low even though my user is streaming Netflix movies?\n\n  WebRTC is conservative in choosing the allowed bandwidth. For example, \n  if there is another high-bandwidth consumer on the network, WebRTC will \n  try to set its own usage to the minimum.\n\n* The network test shows the \"Excellent\" (or \"Acceptable\") result, but the video still gets\n  pixilated during the call.\n\n  You can increase the required thresholds to better qualify the end user connection.\n  Please keep in mind, the network connection can change overtime, especially on mobile devices\n  with changing network conditions.\n\n* Why do I get compilation errors on iOS or Android.\n\n  You need to be using a recent and supported version of the OpenTok iOS SDK or OpenTok Android SDK.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopentok%2Fopentok-network-test","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fopentok%2Fopentok-network-test","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fopentok%2Fopentok-network-test/lists"}