-
Notifications
You must be signed in to change notification settings - Fork 126
Existing KITE Tests
This is the test in the sample test that you see in the repo's README.
Implementation class: org.webrtc.kite.IceConnectionTest.
This test does for each browser, sequentially these steps:
- Open appr.tc, and connect to the same room.
- Execute JavaScript code to get verifies the ICE Connection state of the peer connection object.
- The verification goes on every 1s in 60s or until the state changes to "connected".
- Once the state had changed to "connected", verifies the video display (avoid white/black screen) in the same manner.
- Once the verification is done, calls peer connection object's getStats() every 1s for 10s to get the stats overtime.
- The test is SUCCESSFUL if the ICE connection state is "connected" and video is playing.
- Return the result to the Engine.
Since this is a very basic test, the same principle will be called in various tests, as a first verification before calling any more complicated logic.
These tests work on the same principle, only difference is the parameter that each test verifies.
This package includes: Audio received bitrate: org.webrtc.kite.BitRateTest.ARBitRateTest Audio sending bitrate: org.webrtc.kite.BitRateTest.ASBitRateTest Video received bitrate: org.webrtc.kite.BitRateTest.VRBitRateTest Video sending bitrate: org.webrtc.kite.BitRateTest.VSBitRateTest
This test does for each browser, sequentially these steps:
- Same 3 first steps as ICE Connection test.
- Once the state had changed to "connected", retrieves the stats by calling getStats function of the peer connection object to get the corresponding stats (audio/video's bytesSent, bytesReceived).
- Waits 1s, call getStats again to get the new stats. The difference will be converted to bitrate and compared to the predefined bitrate.
- The test is SUCCESSFUL if the bitrate is correct (with a slight tolerance).
- Return the result to the Engine.
These tests work on the same principle, only difference is the parameter that each test verifies.
This package includes: Opus48K test: org.webrtc.kite.CodecTest.Opus48kTest. OpusDTX test: org.webrtc.kite.CodecTest.OpusDTXTest. OpusFEC test: org.webrtc.kite.CodecTest.OpusFECTest. VideoFEC test: org.webrtc.kite.CodecTest.VideoFECTest. ReceivingVideoCodec test: org.webrtc.kite.CodecTest.ReceivingVideoCodecTest. (tuple size = 2) SendingVideoCodec test: org.webrtc.kite.CodecTest.SendingVideoCodecTest. (tuple size = 2)
This test does for each browser, sequentially these steps:
- Same 3 first steps as ICE Connection test.
- Once the state had changed to "connected", retrieves the sdp offer from the peer connection's local description.
- Verifies whether the corresponding values are included in the right place.
- The test is SUCCESSFUL if the corresponding values are included in the right place.
- Return the result to the Engine.
This package includes: HD test: org.webrtc.kite.MediaTest.HDTest Resolution test: org.webrtc.kite.MediaTest.ResolutionTest NoAudio test: org.webrtc.kite.MediaTest.NoAudioTest NoVideo test: org.webrtc.kite.MediaTest.NoVideoTest MediaFlowing test: org.webrtc.kite.MediaTest.MediaFlowingTest (Checking video display, merged to IceConnection test)
For the NoAudio and NoVideo tests, same as ICE connection test, without the video display check. For the HD and Resolution tests, the test does for each browser, sequentially these steps:
- Same 3 first steps as ICE Connection test.
- Once the state had changed to "connected", retrieves the stats by calling getStats function of the peer connection object to get the corresponding stats (resolution of the sending video stream).
- Verifies whether the resolution is HD (or corresponds to the predefined resolution).
- The test is SUCCESSFUL if the resolution is correct.
- Return the result to the Engine.
This package includes: LoopBack test: org.webrtc.kite.NetworkTest.LoopBackTest
This test is basically the ICE connection test, with the browser sending the streams in loop back.
This test verifies the ICE connection state between 2 browser communicating using WebRTC but without adapter.js
The signaling server is a simple one using nodejs, inspired by the basic peer connection sample.
This test verifies the browsers' capability of sending and receiving multiple stream from multiple sources using webRTC.
This test does for each browser, sequentially these steps:
- Call getUserMedia function of the peer connection object twice with different sets constraints to get 2 different stream sources.
- Verifies the display of local media streams obtained with getUserMedia.
- Verifies the display of remote media stream received from the other peer.
- The test is SUCCESSFUL all four stream are being displayed correctly.
- Return the result to the Engine.
This test verifies the browsers' capability of sending and receiving multiple streams from the same source with different encodes. This test is in mode loopback using a special SFU which will send back the streams it receives.
This test does for each browser, sequentially these steps:
- Call getUserMedia function of the peer connection object to get the media stream.
- Encodes the stream 3 different ways (original resolution, 1/2 resolution, and 1/4 resolution) and sends to the SFU.
- Verifies the display of local media stream obtained with getUserMedia.
- Verifies the display of the stream echoed from the peer connection.
- Verifies the display of the original resolution stream received from the SFU.
- Verifies the display of the 1/2 resolution stream received from the SFU.
- Verifies the display of the 1/4 resolution stream received from the SFU.
- The test is SUCCESSFUL all five stream are being displayed correctly.
- Return the result to the Engine.
This test is done with Jitsi Meet application. This application allows more than 2 participants to do video conferencing.
This test does for each browser, sequentially these steps:
- Open Jitsi Meet website, join the same room.
- Verifies the ICE connection state of every participant.
- Verifies the number of participants, perceived by each participant.
- The test is SUCCESSFUL the connection state is "connected" and the number of participant are correct for all of the participants.
- Return the result to the Engine.