Vimbox ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಶಿಕ್ಷಕ ಮತ್ತು ವಿದ್ಯಾರ್ಥಿಗಳ ನಡುವಿನ ಸಂವಹನದ ಮುಖ್ಯ ಮಾರ್ಗವೆಂದರೆ ವೀಡಿಯೊ ಸಂವಹನ. ನಾವು ಬಹಳ ಹಿಂದೆಯೇ ಸ್ಕೈಪ್ ಅನ್ನು ತ್ಯಜಿಸಿದ್ದೇವೆ, ಹಲವಾರು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಪರಿಹಾರಗಳನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ ಮತ್ತು ಅಂತಿಮವಾಗಿ WebRTC - ಜಾನಸ್-ಗೇಟ್‌ವೇ ಸಂಯೋಜನೆಯಲ್ಲಿ ನೆಲೆಸಿದ್ದೇವೆ. ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ನಾವು ಎಲ್ಲದರಲ್ಲೂ ಸಂತೋಷವಾಗಿದ್ದೇವೆ, ಆದರೆ ಇನ್ನೂ ಕೆಲವು ನಕಾರಾತ್ಮಕ ಅಂಶಗಳು ಹೊರಹೊಮ್ಮುತ್ತಲೇ ಇದ್ದವು. ಪರಿಣಾಮವಾಗಿ, ಪ್ರತ್ಯೇಕ ವೀಡಿಯೊ ನಿರ್ದೇಶನವನ್ನು ರಚಿಸಲಾಗಿದೆ.
ಸ್ಕೈಂಗ್‌ನಲ್ಲಿ ವೀಡಿಯೊ ಸಂವಹನದ ವಿಕಾಸ, ಪತ್ತೆಯಾದ ಸಮಸ್ಯೆಗಳು, ನಾವು ಅಂತಿಮವಾಗಿ ಬಳಸಿದ ಪರಿಹಾರಗಳು ಮತ್ತು ಊರುಗೋಲುಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ನಾನು ಹೊಸ ದಿಕ್ಕಿನ ಮುಖ್ಯಸ್ಥ ಕಿರಿಲ್ ರೋಗೊವೊಯ್ ಅವರನ್ನು ಕೇಳಿದೆ. ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್ ಮೂಲಕ ಸ್ವಂತವಾಗಿ ವೀಡಿಯೊವನ್ನು ರಚಿಸುವ ಕಂಪನಿಗಳಿಗೆ ಲೇಖನವು ಉಪಯುಕ್ತವಾಗಿದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ.
ಇತಿಹಾಸದ ಸ್ವಲ್ಪ
2017 ರ ಬೇಸಿಗೆಯಲ್ಲಿ, ಸ್ಕೈಂಗ್ ಅಭಿವೃದ್ಧಿಯ ಮುಖ್ಯಸ್ಥ ಸೆರ್ಗೆಯ್ ಸಫೊನೊವ್ ಅವರು ಬ್ಯಾಕೆಂಡ್ ಕಾನ್ಫ್‌ನಲ್ಲಿ ನಾವು "ಸ್ಕೈಪ್ ಅನ್ನು ಹೇಗೆ ತ್ಯಜಿಸಿದ್ದೇವೆ ಮತ್ತು ವೆಬ್‌ಆರ್‌ಟಿಸಿಯನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಿದ್ದೇವೆ" ಎಂಬ ಕಥೆಯೊಂದಿಗೆ ಮಾತನಾಡಿದರು. ಆಸಕ್ತರು ಭಾಷಣದ ಧ್ವನಿಮುದ್ರಣವನ್ನು ವೀಕ್ಷಿಸಬಹುದು (~45 ನಿಮಿಷ), ಮತ್ತು ಇಲ್ಲಿ ನಾನು ಅದರ ಸಾರವನ್ನು ಸಂಕ್ಷಿಪ್ತವಾಗಿ ವಿವರಿಸುತ್ತೇನೆ.
ಸ್ಕೈಂಗ್ ಶಾಲೆಗೆ, ವೀಡಿಯೊ ಸಂವಹನವು ಯಾವಾಗಲೂ ಶಿಕ್ಷಕ-ವಿದ್ಯಾರ್ಥಿ ಸಂವಹನದ ಆದ್ಯತೆಯ ಮಾರ್ಗವಾಗಿದೆ. ಮೊದಲಿಗೆ, ಸ್ಕೈಪ್ ಅನ್ನು ಬಳಸಲಾಯಿತು, ಆದರೆ ಇದು ಹಲವಾರು ಕಾರಣಗಳಿಗಾಗಿ ವರ್ಗೀಯವಾಗಿ ತೃಪ್ತಿಕರವಾಗಿಲ್ಲ, ಪ್ರಾಥಮಿಕವಾಗಿ ಲಾಗ್‌ಗಳ ಕೊರತೆ ಮತ್ತು ವೆಬ್ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನೇರವಾಗಿ ಏಕೀಕರಣದ ಅಸಾಧ್ಯತೆಯಿಂದಾಗಿ. ಆದ್ದರಿಂದ, ನಾವು ಎಲ್ಲಾ ರೀತಿಯ ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸಿದ್ದೇವೆ.
ವಾಸ್ತವವಾಗಿ, ವೀಡಿಯೊ ಸಂವಹನಕ್ಕಾಗಿ ನಮ್ಮ ಅವಶ್ಯಕತೆಗಳು ಸರಿಸುಮಾರು ಈ ಕೆಳಗಿನವುಗಳಾಗಿವೆ:
- ಸ್ಥಿರತೆ;
- ಪ್ರತಿ ಪಾಠಕ್ಕೆ ಕಡಿಮೆ ಬೆಲೆ;
- ರೆಕಾರ್ಡಿಂಗ್ ಪಾಠಗಳು;
- ಯಾರು ಎಷ್ಟು ಮಾತನಾಡುತ್ತಾರೆ ಎಂಬುದನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡುವುದು (ಪಾಠದ ಸಮಯದಲ್ಲಿ ವಿದ್ಯಾರ್ಥಿಗಳು ಶಿಕ್ಷಕರಿಗಿಂತ ಹೆಚ್ಚು ಮಾತನಾಡುತ್ತಾರೆ ಎಂಬುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ);
- ರೇಖೀಯ ಸ್ಕೇಲಿಂಗ್;
- ಯುಡಿಪಿ ಮತ್ತು ಟಿಸಿಪಿ ಎರಡನ್ನೂ ಬಳಸುವ ಸಾಮರ್ಥ್ಯ.
2013 ರಲ್ಲಿ ಟೋಕ್‌ಬಾಕ್ಸ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಮೊದಲು ಪ್ರಯತ್ನಿಸಲಾಯಿತು. ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿತ್ತು, ಆದರೆ ಅದು ತುಂಬಾ ದುಬಾರಿಯಾಗಿದೆ - ಪ್ರತಿ ಪಾಠಕ್ಕೆ 113 ರೂಬಲ್ಸ್ಗಳು - ಮತ್ತು ಲಾಭವನ್ನು ತಿನ್ನುತ್ತವೆ.
ನಂತರ 2015 ರಲ್ಲಿ, ವೊಕ್ಸಿಂಪ್ಲ್ಯಾಂಟ್ ಅನ್ನು ಸಂಯೋಜಿಸಲಾಯಿತು. ಯಾರು ಎಷ್ಟು ಮಾತನಾಡಿದ್ದಾರೆ ಎಂಬುದನ್ನು ಪತ್ತೆಹಚ್ಚಲು ನಮಗೆ ಅಗತ್ಯವಿರುವ ಕಾರ್ಯ ಇಲ್ಲಿದೆ, ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಪರಿಹಾರವು ಹೆಚ್ಚು ಅಗ್ಗವಾಗಿದೆ: ಆಡಿಯೊವನ್ನು ಮಾತ್ರ ರೆಕಾರ್ಡ್ ಮಾಡಿದರೆ, ಪ್ರತಿ ಪಾಠಕ್ಕೆ 20 ರೂಬಲ್ಸ್ ವೆಚ್ಚವಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ಇದು UDP ಮೂಲಕ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು TCP ಗೆ ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಸುಮಾರು 40% ವಿದ್ಯಾರ್ಥಿಗಳು ಇದನ್ನು ಬಳಸುವುದನ್ನು ಕೊನೆಗೊಳಿಸಿದರು.
ಒಂದು ವರ್ಷದ ನಂತರ, ನಾವು ಕಾರ್ಪೊರೇಟ್ ಕ್ಲೈಂಟ್‌ಗಳನ್ನು ಅವರದೇ ಆದ ನಿರ್ದಿಷ್ಟ ಅವಶ್ಯಕತೆಗಳೊಂದಿಗೆ ಹೊಂದಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಉದಾಹರಣೆಗೆ, ಎಲ್ಲವೂ ಬ್ರೌಸರ್ ಮೂಲಕ ಕೆಲಸ ಮಾಡಬೇಕು; ಕಂಪನಿಯು http ಮತ್ತು https ಅನ್ನು ಮಾತ್ರ ತೆರೆಯುತ್ತದೆ; ಅಂದರೆ ಸ್ಕೈಪ್ ಅಥವಾ UDP ಇಲ್ಲ. ಕಾರ್ಪೊರೇಟ್ ಕ್ಲೈಂಟ್‌ಗಳು = ಹಣ, ಆದ್ದರಿಂದ ಅವರು ಟೋಕ್‌ಬಾಕ್ಸ್‌ಗೆ ಮರಳಿದರು, ಆದರೆ ಬೆಲೆಯ ಸಮಸ್ಯೆ ದೂರವಾಗಲಿಲ್ಲ.
ಪರಿಹಾರ - WebRTC ಮತ್ತು ಜಾನಸ್
ಬಳಸಲು ನಿರ್ಧರಿಸಲಾಗಿದೆ . ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವುದು, ಎನ್‌ಕೋಡಿಂಗ್ ಮತ್ತು ಡೀಕೋಡಿಂಗ್ ಸ್ಟ್ರೀಮ್‌ಗಳು, ಟ್ರ್ಯಾಕ್‌ಗಳನ್ನು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡುವುದು ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ತೊಂದರೆಗಳನ್ನು ನಿರ್ವಹಿಸುವುದರೊಂದಿಗೆ ಗುಣಮಟ್ಟದ ನಿಯಂತ್ರಣವನ್ನು ಇದು ಜವಾಬ್ದಾರರನ್ನಾಗಿ ಮಾಡುತ್ತದೆ. ನಮ್ಮ ಪಾಲಿಗೆ, ನಾವು ಕ್ಯಾಮರಾ ಮತ್ತು ಮೈಕ್ರೊಫೋನ್‌ನಿಂದ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಓದುವುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು, ವೀಡಿಯೊವನ್ನು ಸೆಳೆಯುವುದು, ಸಂಪರ್ಕವನ್ನು ನಿರ್ವಹಿಸುವುದು, WebRTC ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವುದು ಮತ್ತು ಅದಕ್ಕೆ ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ರವಾನಿಸುವುದು, ಹಾಗೆಯೇ ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸಲು ಕ್ಲೈಂಟ್‌ಗಳ ನಡುವೆ ಸಂಕೇತ ಸಂದೇಶಗಳನ್ನು ರವಾನಿಸುವುದು (WebRTC ಸ್ವತಃ ವಿವರಿಸುತ್ತದೆ ಡೇಟಾ ಸ್ವರೂಪ, ಆದರೆ ಅದರ ಯಾಂತ್ರಿಕ ವರ್ಗಾವಣೆ ಅಲ್ಲ). ಕ್ಲೈಂಟ್‌ಗಳು NAT ಹಿಂದೆ ಇದ್ದರೆ, WebRTC STUN ಸರ್ವರ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುತ್ತದೆ; ಇದು ಸಹಾಯ ಮಾಡದಿದ್ದರೆ, ಸರ್ವರ್‌ಗಳನ್ನು ತಿರುಗಿಸಿ.
ನಿಯಮಿತ p2p ಸಂಪರ್ಕವು ನಮಗೆ ಸಾಕಾಗುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ದೂರುಗಳ ಸಂದರ್ಭದಲ್ಲಿ ಹೆಚ್ಚಿನ ವಿಶ್ಲೇಷಣೆಗಾಗಿ ನಾವು ಪಾಠಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ ನಾವು ರಿಲೇ ಮೂಲಕ WebRTC ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತೇವೆ . ಪರಿಣಾಮವಾಗಿ, ಕ್ಲೈಂಟ್‌ಗಳು ಪರಸ್ಪರರ ವಿಳಾಸಗಳನ್ನು ತಿಳಿದಿರುವುದಿಲ್ಲ, ಜಾನಸ್ ಸರ್ವರ್ ವಿಳಾಸವನ್ನು ಮಾತ್ರ ನೋಡುತ್ತಾರೆ; ಇದು ಸಿಗ್ನಲ್ ಸರ್ವರ್‌ನ ಕಾರ್ಯಗಳನ್ನು ಸಹ ನಿರ್ವಹಿಸುತ್ತದೆ. ಜಾನಸ್ ನಮಗೆ ಅಗತ್ಯವಿರುವ ಹಲವು ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದೆ: ಕ್ಲೈಂಟ್ UDP ಅನ್ನು ನಿರ್ಬಂಧಿಸಿದರೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ TCP ಗೆ ಬದಲಾಗುತ್ತದೆ; UDP ಮತ್ತು TCP ಸ್ಟ್ರೀಮ್‌ಗಳನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಬಹುದು; ಸ್ಕೇಲೆಬಲ್; ಪ್ರತಿಧ್ವನಿ ಪರೀಕ್ಷೆಗಳಿಗಾಗಿ ಅಂತರ್ನಿರ್ಮಿತ ಪ್ಲಗಿನ್ ಕೂಡ ಇದೆ. ಅಗತ್ಯವಿದ್ದರೆ, Twilio ನಿಂದ STUN ಮತ್ತು TURN ಸರ್ವರ್‌ಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸಂಪರ್ಕಗೊಂಡಿವೆ.
2017 ರ ಬೇಸಿಗೆಯಲ್ಲಿ, ನಾವು ಎರಡು ಜಾನಸ್ ಸರ್ವರ್‌ಗಳನ್ನು ಚಾಲನೆ ಮಾಡಿದ್ದೇವೆ, ಜೊತೆಗೆ ರೆಕಾರ್ಡ್ ಮಾಡಿದ ಕಚ್ಚಾ ಆಡಿಯೊ ಮತ್ತು ವೀಡಿಯೊ ಫೈಲ್‌ಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಹೆಚ್ಚುವರಿ ಸರ್ವರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಮುಖ್ಯವಾದವುಗಳ ಪ್ರೊಸೆಸರ್‌ಗಳನ್ನು ಆಕ್ರಮಿಸುವುದಿಲ್ಲ. ಸಂಪರ್ಕಿಸುವಾಗ, ಜಾನಸ್ ಸರ್ವರ್‌ಗಳನ್ನು ಬೆಸ-ಸಮ ಆಧಾರದ ಮೇಲೆ ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ (ಸಂಪರ್ಕ ಸಂಖ್ಯೆ). ಆ ಸಮಯದಲ್ಲಿ, ಇದು ಸಾಕಾಗಿತ್ತು, ನಮ್ಮ ಭಾವನೆಗಳ ಪ್ರಕಾರ, ಇದು ಸರಿಸುಮಾರು ನಾಲ್ಕು ಪಟ್ಟು ಸುರಕ್ಷತೆಯ ಅಂಚು ನೀಡಿತು, ಅನುಷ್ಠಾನದ ಶೇಕಡಾವಾರು ಸುಮಾರು 80 ಆಗಿತ್ತು. ಅದೇ ಸಮಯದಲ್ಲಿ, ಬೆಲೆ ಪ್ರತಿ ಪಾಠಕ್ಕೆ ~ 2 ರೂಬಲ್ಸ್ಗೆ ಕಡಿಮೆಯಾಯಿತು, ಜೊತೆಗೆ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಬೆಂಬಲ.
ವೀಡಿಯೊ ಸಂವಹನದ ವಿಷಯಕ್ಕೆ ಹಿಂತಿರುಗಿ
ಸಮಸ್ಯೆಗಳನ್ನು ಸಮಯೋಚಿತವಾಗಿ ಗುರುತಿಸಲು ಮತ್ತು ಸರಿಪಡಿಸಲು ನಾವು ವಿದ್ಯಾರ್ಥಿಗಳು ಮತ್ತು ಶಿಕ್ಷಕರ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರಂತರವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ. 2018 ರ ಬೇಸಿಗೆಯ ಹೊತ್ತಿಗೆ, ಕರೆ ಗುಣಮಟ್ಟವು ದೂರುಗಳಲ್ಲಿ ಮೊದಲ ಸ್ಥಾನದಲ್ಲಿದೆ. ಒಂದೆಡೆ, ಇದರರ್ಥ ನಾವು ಇತರ ನ್ಯೂನತೆಗಳನ್ನು ಯಶಸ್ವಿಯಾಗಿ ನಿವಾರಿಸಿದ್ದೇವೆ. ಮತ್ತೊಂದೆಡೆ, ತುರ್ತಾಗಿ ಏನನ್ನಾದರೂ ಮಾಡುವುದು ಅಗತ್ಯವಾಗಿತ್ತು: ಪಾಠವು ಅಡ್ಡಿಪಡಿಸಿದರೆ, ಅದರ ಮೌಲ್ಯವನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಅಪಾಯವಿದೆ, ಕೆಲವೊಮ್ಮೆ ಮುಂದಿನ ಪ್ಯಾಕೇಜ್ ಅನ್ನು ಖರೀದಿಸುವ ವೆಚ್ಚದೊಂದಿಗೆ, ಮತ್ತು ಪರಿಚಯಾತ್ಮಕ ಪಾಠವು ಅಡ್ಡಿಪಡಿಸಿದರೆ, ನಾವು ಸಂಭಾವ್ಯ ಕ್ಲೈಂಟ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಅಪಾಯವಿದೆ. ಒಟ್ಟಾರೆ.
ಆ ಸಮಯದಲ್ಲಿ, ನಮ್ಮ ವೀಡಿಯೊ ಸಂವಹನವು ಇನ್ನೂ MVP ಮೋಡ್‌ನಲ್ಲಿತ್ತು. ಸರಳವಾಗಿ ಹೇಳುವುದಾದರೆ, ಅವರು ಅದನ್ನು ಪ್ರಾರಂಭಿಸಿದರು, ಅದು ಕೆಲಸ ಮಾಡಿದೆ, ಅವರು ಅದನ್ನು ಒಮ್ಮೆ ಅಳೆಯುತ್ತಾರೆ, ಅದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ಅವರು ಅರ್ಥಮಾಡಿಕೊಂಡರು - ಚೆನ್ನಾಗಿ, ಅದ್ಭುತವಾಗಿದೆ. ಅದು ಕೆಲಸ ಮಾಡಿದರೆ, ಅದನ್ನು ಸರಿಪಡಿಸಬೇಡಿ. ಸಂವಹನ ಗುಣಮಟ್ಟದ ಸಮಸ್ಯೆಯನ್ನು ಯಾರೂ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ತಿಳಿಸಲಿಲ್ಲ. ಆಗಸ್ಟ್ ವೇಳೆಗೆ, ಇದು ಮುಂದುವರೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು ಮತ್ತು WebRTC ಮತ್ತು Janus ನಲ್ಲಿ ಏನು ತಪ್ಪಾಗಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾವು ಪ್ರತ್ಯೇಕ ನಿರ್ದೇಶನವನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ.
ಇನ್‌ಪುಟ್‌ನಲ್ಲಿ, ಈ ನಿರ್ದೇಶನವನ್ನು ಸ್ವೀಕರಿಸಲಾಗಿದೆ: MVP ಪರಿಹಾರ, ಯಾವುದೇ ಮೆಟ್ರಿಕ್‌ಗಳಿಲ್ಲ, ಯಾವುದೇ ಗುರಿಗಳಿಲ್ಲ, ಸುಧಾರಣೆಗೆ ಯಾವುದೇ ಪ್ರಕ್ರಿಯೆಗಳಿಲ್ಲ, ಆದರೆ 7% ಶಿಕ್ಷಕರು ಸಂವಹನದ ಗುಣಮಟ್ಟದ ಬಗ್ಗೆ ದೂರು ನೀಡುತ್ತಾರೆ (ವಿದ್ಯಾರ್ಥಿಗಳ ಬಗ್ಗೆ ಯಾವುದೇ ಡೇಟಾ ಇರಲಿಲ್ಲ).
ಹೊಸ ನಿರ್ದೇಶನ ನಡೆಯುತ್ತಿದೆ
ಆಜ್ಞೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:
- ಮುಖ್ಯ ಡೆವಲಪರ್ ಆಗಿರುವ ವಿಭಾಗದ ಮುಖ್ಯಸ್ಥರು.
- QA ಪರೀಕ್ಷಾ ಬದಲಾವಣೆಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಅಸ್ಥಿರ ಸಂವಹನ ಪರಿಸ್ಥಿತಿಗಳನ್ನು ರಚಿಸಲು ಹೊಸ ಮಾರ್ಗಗಳನ್ನು ಹುಡುಕುತ್ತದೆ ಮತ್ತು ಮುಂಚೂಣಿಯಿಂದ ಸಮಸ್ಯೆಗಳನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ.
- ವಿಶ್ಲೇಷಕರು ನಿರಂತರವಾಗಿ ತಾಂತ್ರಿಕ ಡೇಟಾದಲ್ಲಿ ವಿವಿಧ ಪರಸ್ಪರ ಸಂಬಂಧಗಳನ್ನು ಹುಡುಕುತ್ತಾರೆ, ಬಳಕೆದಾರರ ಪ್ರತಿಕ್ರಿಯೆಯ ವಿಶ್ಲೇಷಣೆಯನ್ನು ಸುಧಾರಿಸುತ್ತಾರೆ ಮತ್ತು ಪ್ರಯೋಗಗಳ ಫಲಿತಾಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತಾರೆ.
- ಉತ್ಪನ್ನ ನಿರ್ವಾಹಕರು ಒಟ್ಟಾರೆ ನಿರ್ದೇಶನ ಮತ್ತು ಪ್ರಯೋಗಗಳಿಗೆ ಸಂಪನ್ಮೂಲಗಳ ಹಂಚಿಕೆಗೆ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ.
- ಎರಡನೆಯ ಡೆವಲಪರ್ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಮತ್ತು ಸಂಬಂಧಿತ ಕಾರ್ಯಗಳಿಗೆ ಸಹಾಯ ಮಾಡುತ್ತಾರೆ.
ಮೊದಲಿಗೆ, ಸಂವಹನ ಗುಣಮಟ್ಟದ ಮೌಲ್ಯಮಾಪನಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು (ದಿನಗಳು, ವಾರಗಳು, ತಿಂಗಳುಗಳಲ್ಲಿ ಸರಾಸರಿ) ಟ್ರ್ಯಾಕ್ ಮಾಡುವ ತುಲನಾತ್ಮಕವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹ ಮೆಟ್ರಿಕ್ ಅನ್ನು ನಾವು ಹೊಂದಿಸಿದ್ದೇವೆ. ಆ ಸಮಯದಲ್ಲಿ, ಇವುಗಳು ಶಿಕ್ಷಕರಿಂದ ಶ್ರೇಣಿಗಳನ್ನು ಹೊಂದಿದ್ದವು; ನಂತರದ ವಿದ್ಯಾರ್ಥಿಗಳಿಂದ ಶ್ರೇಣಿಗಳನ್ನು ಅವರಿಗೆ ಸೇರಿಸಲಾಯಿತು. ನಂತರ ಅವರು ಏನು ತಪ್ಪು ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂಬುದರ ಕುರಿತು ಊಹೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ಪ್ರಾರಂಭಿಸಿದರು, ಅದನ್ನು ಸರಿಪಡಿಸಿ ಮತ್ತು ಡೈನಾಮಿಕ್ಸ್ನಲ್ಲಿನ ಬದಲಾವಣೆಗಳನ್ನು ನೋಡಿದರು. ನಾವು ಕಡಿಮೆ ನೇತಾಡುವ ಹಣ್ಣಿಗೆ ಹೋಗಿದ್ದೇವೆ: ಉದಾಹರಣೆಗೆ, ನಾವು vp8 ಕೊಡೆಕ್ ಅನ್ನು vp9 ನೊಂದಿಗೆ ಬದಲಾಯಿಸಿದ್ದೇವೆ, ಕಾರ್ಯಕ್ಷಮತೆ ಸುಧಾರಿಸಿದೆ. ನಾವು ಜಾನಸ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಆಡಲು ಮತ್ತು ಇತರ ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ - ಹೆಚ್ಚಿನ ಸಂದರ್ಭಗಳಲ್ಲಿ ಅವು ಯಾವುದಕ್ಕೂ ಕಾರಣವಾಗಲಿಲ್ಲ.
ಎರಡನೇ ಹಂತದಲ್ಲಿ, ಒಂದು ಊಹೆ ಹೊರಹೊಮ್ಮಿತು: WebRTC ಒಂದು ಪೀರ್-ಟು-ಪೀರ್ ಪರಿಹಾರವಾಗಿದೆ, ಮತ್ತು ನಾವು ಮಧ್ಯದಲ್ಲಿ ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. ಬಹುಶಃ ಸಮಸ್ಯೆ ಇಲ್ಲಿಯೇ ಇದೆಯೇ? ನಾವು ಅಗೆಯಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಇಲ್ಲಿಯವರೆಗೆ ಅತ್ಯಂತ ಮಹತ್ವದ ಸುಧಾರಣೆಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೇವೆ.
ಆ ಕ್ಷಣದಲ್ಲಿ, ಸ್ಟುಪಿಡ್ ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಪೂಲ್‌ನಿಂದ ಸರ್ವರ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ: ಪ್ರತಿಯೊಂದೂ ತನ್ನದೇ ಆದ "ತೂಕ" ವನ್ನು ಹೊಂದಿದ್ದು, ಚಾನಲ್ ಮತ್ತು ಶಕ್ತಿಯನ್ನು ಅವಲಂಬಿಸಿ, ಮತ್ತು ನಾವು ಬಳಕೆದಾರರನ್ನು ದೊಡ್ಡ "ತೂಕ" ಹೊಂದಿರುವ ಒಂದಕ್ಕೆ ಕಳುಹಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ಬಳಕೆದಾರನು ಭೌಗೋಳಿಕವಾಗಿ ಎಲ್ಲಿ ನೆಲೆಸಿದ್ದಾನೆ ಎಂಬುದರ ಬಗ್ಗೆ ಗಮನ ಹರಿಸುವುದು. ಪರಿಣಾಮವಾಗಿ, ಸೇಂಟ್ ಪೀಟರ್ಸ್‌ಬರ್ಗ್‌ನ ಶಿಕ್ಷಕರು ಸೈಬೀರಿಯಾದ ವಿದ್ಯಾರ್ಥಿಯೊಂದಿಗೆ ಮಾಸ್ಕೋ ಮೂಲಕ ಸಂವಹನ ನಡೆಸಬಹುದು ಮತ್ತು ಸೇಂಟ್ ಪೀಟರ್ಸ್‌ಬರ್ಗ್‌ನಲ್ಲಿರುವ ನಮ್ಮ ಜಾನಸ್ ಸರ್ವರ್ ಮೂಲಕ ಅಲ್ಲ.
ಅಲ್ಗಾರಿದಮ್ ಅನ್ನು ಪುನಃ ಮಾಡಲಾಗಿದೆ: ಈಗ, ಬಳಕೆದಾರರು ನಮ್ಮ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ತೆರೆದಾಗ, ನಾವು ಅವನಿಂದ ಅಜಾಕ್ಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಎಲ್ಲಾ ಸರ್ವರ್‌ಗಳಿಗೆ ಪಿಂಗ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವಾಗ, ನಾವು ಚಿಕ್ಕ ಮೊತ್ತದೊಂದಿಗೆ ಜೋಡಿ ಪಿಂಗ್ಗಳನ್ನು (ಶಿಕ್ಷಕ-ಸರ್ವರ್ ಮತ್ತು ವಿದ್ಯಾರ್ಥಿ-ಸರ್ವರ್) ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ. ಕಡಿಮೆ ಪಿಂಗ್ ಎಂದರೆ ಸರ್ವರ್‌ಗೆ ಕಡಿಮೆ ನೆಟ್‌ವರ್ಕ್ ಅಂತರ; ಕಡಿಮೆ ಅಂತರ ಎಂದರೆ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುವ ಕಡಿಮೆ ಸಂಭವನೀಯತೆ; ವೀಡಿಯೊ ಸಂವಹನದಲ್ಲಿ ಪ್ಯಾಕೆಟ್ ನಷ್ಟವು ಅತಿದೊಡ್ಡ ನಕಾರಾತ್ಮಕ ಅಂಶವಾಗಿದೆ. ನಕಾರಾತ್ಮಕತೆಯ ಪಾಲು ಮೂರು ತಿಂಗಳಲ್ಲಿ ಅರ್ಧದಷ್ಟು ಕುಸಿಯಿತು (ನ್ಯಾಯವಾಗಿ ಹೇಳಬೇಕೆಂದರೆ, ಈ ಸಮಯದಲ್ಲಿ ಇತರ ಪ್ರಯೋಗಗಳನ್ನು ನಡೆಸಲಾಯಿತು, ಆದರೆ ಇದು ಖಂಡಿತವಾಗಿಯೂ ಹೆಚ್ಚು ಪ್ರಭಾವ ಬೀರಿತು).
ನಾವು ಇತ್ತೀಚೆಗೆ ಮತ್ತೊಂದು ಸ್ಪಷ್ಟವಲ್ಲದ, ಆದರೆ ಸ್ಪಷ್ಟವಾಗಿ ಮುಖ್ಯವಾದ ವಿಷಯವನ್ನು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ: ದಪ್ಪ ಚಾನಲ್‌ನಲ್ಲಿ ಒಂದು ಶಕ್ತಿಯುತ ಜಾನಸ್ ಸರ್ವರ್ ಬದಲಿಗೆ, ತೆಳುವಾದ ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನೊಂದಿಗೆ ಎರಡು ಸರಳವಾದವುಗಳನ್ನು ಹೊಂದುವುದು ಉತ್ತಮ. ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹಲವಾರು ಕೊಠಡಿಗಳನ್ನು (ಸಂವಹನ ಅವಧಿಗಳು) ತುಂಬಿಸುವ ಭರವಸೆಯಲ್ಲಿ ನಾವು ಶಕ್ತಿಯುತ ಯಂತ್ರಗಳನ್ನು ಖರೀದಿಸಿದ ನಂತರ ಇದು ಸ್ಪಷ್ಟವಾಯಿತು. ಸರ್ವರ್‌ಗಳು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮಿತಿಯನ್ನು ಹೊಂದಿವೆ, ಅದನ್ನು ನಾವು ಕೊಠಡಿಗಳ ಸಂಖ್ಯೆಗೆ ನಿಖರವಾಗಿ ಭಾಷಾಂತರಿಸಬಹುದು - ಎಷ್ಟು ತೆರೆಯಬಹುದು ಎಂದು ನಮಗೆ ತಿಳಿದಿದೆ, ಉದಾಹರಣೆಗೆ, 300 Mbit/s ನಲ್ಲಿ. ಸರ್ವರ್‌ನಲ್ಲಿ ಹಲವಾರು ಕೊಠಡಿಗಳು ತೆರೆದ ತಕ್ಷಣ, ಲೋಡ್ ಕಡಿಮೆಯಾಗುವವರೆಗೆ ನಾವು ಅದನ್ನು ಹೊಸ ಚಟುವಟಿಕೆಗಳಿಗೆ ಆಯ್ಕೆ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೇವೆ. ಶಕ್ತಿಯುತ ಯಂತ್ರವನ್ನು ಖರೀದಿಸಿದ ನಂತರ, ನಾವು ಚಾನಲ್ ಅನ್ನು ಗರಿಷ್ಠವಾಗಿ ಲೋಡ್ ಮಾಡುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ಅದು ಪ್ರೊಸೆಸರ್ ಮತ್ತು ಮೆಮೊರಿಯಿಂದ ಸೀಮಿತವಾಗಿರುತ್ತದೆ ಮತ್ತು ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್‌ನಿಂದ ಅಲ್ಲ. ಆದರೆ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ತೆರೆದ ಕೋಣೆಗಳ ನಂತರ (420), ಪ್ರೊಸೆಸರ್, ಮೆಮೊರಿ ಮತ್ತು ಡಿಸ್ಕ್ ಮೇಲಿನ ಲೋಡ್ ಇನ್ನೂ ಮಿತಿಯಿಂದ ಬಹಳ ದೂರದಲ್ಲಿದೆ ಎಂಬ ಅಂಶದ ಹೊರತಾಗಿಯೂ, ನಕಾರಾತ್ಮಕತೆಯು ತಾಂತ್ರಿಕ ಬೆಂಬಲಕ್ಕೆ ಬರಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಸ್ಪಷ್ಟವಾಗಿ, ಜಾನಸ್‌ನಲ್ಲಿ ಏನಾದರೂ ಕೆಟ್ಟದಾಗಿದೆ, ಬಹುಶಃ ಅಲ್ಲಿಯೂ ಕೆಲವು ನಿರ್ಬಂಧಗಳಿವೆ. ನಾವು ಪ್ರಯೋಗವನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಬ್ಯಾಂಡ್‌ವಿಡ್ತ್ ಮಿತಿಯನ್ನು 300 ರಿಂದ 200 Mbit/s ಗೆ ಇಳಿಸಿದ್ದೇವೆ ಮತ್ತು ಸಮಸ್ಯೆಗಳು ದೂರವಾದವು. ಈಗ ನಾವು ಕಡಿಮೆ ಮಿತಿಗಳು ಮತ್ತು ಗುಣಲಕ್ಷಣಗಳೊಂದಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಮೂರು ಹೊಸ ಸರ್ವರ್‌ಗಳನ್ನು ಖರೀದಿಸಿದ್ದೇವೆ, ಇದು ಸಂವಹನದ ಗುಣಮಟ್ಟದಲ್ಲಿ ಸ್ಥಿರ ಸುಧಾರಣೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ. ಸಹಜವಾಗಿ, ಅಲ್ಲಿ ಏನು ನಡೆಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯಲು ನಾವು ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ; ನಮ್ಮ ಊರುಗೋಲು ಎಲ್ಲವೂ. ನಮ್ಮ ರಕ್ಷಣೆಯಲ್ಲಿ, ಆ ಕ್ಷಣದಲ್ಲಿ ಒತ್ತುವ ಸಮಸ್ಯೆಯನ್ನು ಸಾಧ್ಯವಾದಷ್ಟು ಬೇಗ ಪರಿಹರಿಸುವುದು ಅಗತ್ಯವಾಗಿತ್ತು ಮತ್ತು ಅದನ್ನು ಸುಂದರವಾಗಿ ಮಾಡಬಾರದು ಎಂದು ಹೇಳೋಣ; ಅದಲ್ಲದೆ, Janus for us ಎಂಬುದು C ಯಲ್ಲಿ ಬರೆದ ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಯಾಗಿದೆ, ಅದರೊಂದಿಗೆ ಟಿಂಕರ್ ಮಾಡುವುದು ತುಂಬಾ ದುಬಾರಿಯಾಗಿದೆ.
ಸರಿ, ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನಾವು:
- ಸರ್ವರ್‌ನಲ್ಲಿ ಮತ್ತು ಕ್ಲೈಂಟ್‌ನಲ್ಲಿ ನವೀಕರಿಸಬಹುದಾದ ಎಲ್ಲಾ ಅವಲಂಬನೆಗಳನ್ನು ನವೀಕರಿಸಲಾಗಿದೆ (ಇವುಗಳು ಸಹ ಪ್ರಯೋಗಗಳಾಗಿವೆ, ನಾವು ಫಲಿತಾಂಶಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಿದ್ದೇವೆ);
- ನಿರ್ದಿಷ್ಟ ಪ್ರಕರಣಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಎಲ್ಲಾ ಗುರುತಿಸಲಾದ ದೋಷಗಳನ್ನು ಸರಿಪಡಿಸಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, ಸಂಪರ್ಕವು ಕೈಬಿಟ್ಟಾಗ ಮತ್ತು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮರುಸ್ಥಾಪಿಸದಿದ್ದಾಗ;
- ವೀಡಿಯೊ ಸಂವಹನ ಕ್ಷೇತ್ರದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಕಂಪನಿಗಳೊಂದಿಗೆ ನಾವು ಸಾಕಷ್ಟು ಸಭೆಗಳನ್ನು ನಡೆಸಿದ್ದೇವೆ ಮತ್ತು ನಮ್ಮ ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಪರಿಚಿತರಾಗಿದ್ದೇವೆ: ಸ್ಟ್ರೀಮಿಂಗ್ ಆಟಗಳು, ವೆಬ್‌ನಾರ್‌ಗಳನ್ನು ಆಯೋಜಿಸುವುದು; ನಮಗೆ ಉಪಯುಕ್ತವೆಂದು ತೋರುವ ಎಲ್ಲವನ್ನೂ ನಾವು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ;
- ಶಿಕ್ಷಕರ ಹಾರ್ಡ್ ವೇರ್ ಮತ್ತು ಸಂವಹನ ಗುಣಮಟ್ಟದ ತಾಂತ್ರಿಕ ಪರಿಶೀಲನೆ ನಡೆಸಿದ್ದು, ಇವರಿಂದ ಹೆಚ್ಚು ದೂರುಗಳು ಬಂದಿವೆ.
ಪ್ರಯೋಗಗಳು ಮತ್ತು ನಂತರದ ಬದಲಾವಣೆಗಳು ಶಿಕ್ಷಕರ ನಡುವಿನ ಸಂವಹನದ ಅಸಮಾಧಾನವನ್ನು ಜನವರಿ 7,1 ರಲ್ಲಿ 2018% ರಿಂದ ಜನವರಿ 2,5 ರಲ್ಲಿ 2019% ಕ್ಕೆ ತಗ್ಗಿಸಲು ಸಾಧ್ಯವಾಗಿಸಿತು.
ಮುಂದೆ ಏನು
ನಮ್ಮ Vimbox ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಸ್ಥಿರಗೊಳಿಸುವುದು 2019 ರ ಕಂಪನಿಯ ಮುಖ್ಯ ಯೋಜನೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಾವು ಆವೇಗವನ್ನು ಕಾಯ್ದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಮತ್ತು ಇನ್ನು ಮುಂದೆ ಉನ್ನತ ದೂರುಗಳಲ್ಲಿ ವೀಡಿಯೊ ಸಂವಹನವನ್ನು ನೋಡುವುದಿಲ್ಲ ಎಂದು ನಾವು ಹೆಚ್ಚಿನ ಭರವಸೆ ಹೊಂದಿದ್ದೇವೆ. ಈ ದೂರುಗಳ ಗಮನಾರ್ಹ ಭಾಗವು ಬಳಕೆದಾರರ ಕಂಪ್ಯೂಟರ್‌ಗಳು ಮತ್ತು ಇಂಟರ್ನೆಟ್‌ನಲ್ಲಿನ ವಿಳಂಬಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆ ಎಂದು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ, ಆದರೆ ನಾವು ಈ ಭಾಗವನ್ನು ನಿರ್ಧರಿಸಬೇಕು ಮತ್ತು ಉಳಿದವುಗಳನ್ನು ಪರಿಹರಿಸಬೇಕು. ಉಳಿದಂತೆ ತಾಂತ್ರಿಕ ಸಮಸ್ಯೆ, ನಾವು ಅದನ್ನು ನಿಭಾಯಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ ಎಂದು ತೋರುತ್ತದೆ.
ಗುಣಮಟ್ಟವನ್ನು ಸುಧಾರಿಸಲು ಯಾವ ಮಟ್ಟಕ್ಕೆ ನಿಜವಾಗಿ ಸಾಧ್ಯ ಎಂದು ನಮಗೆ ತಿಳಿದಿಲ್ಲ ಎಂಬುದು ಮುಖ್ಯ ತೊಂದರೆ. ಈ ಸೀಲಿಂಗ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿದೆ. ಆದ್ದರಿಂದ, ಎರಡು ಪ್ರಯೋಗಗಳನ್ನು ಯೋಜಿಸಲಾಗಿದೆ:
- ಯುದ್ಧ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ p2p ನೊಂದಿಗೆ Janus ಮೂಲಕ ವೀಡಿಯೊವನ್ನು ಹೋಲಿಕೆ ಮಾಡಿ. ಈ ಪ್ರಯೋಗವನ್ನು ಈಗಾಗಲೇ ನಡೆಸಲಾಗಿದೆ, ನಮ್ಮ ಪರಿಹಾರ ಮತ್ತು p2p ನಡುವೆ ಯಾವುದೇ ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯವಾಗಿ ಮಹತ್ವದ ವ್ಯತ್ಯಾಸ ಕಂಡುಬಂದಿಲ್ಲ;
- ವೀಡಿಯೊ ಸಂವಹನ ಪರಿಹಾರಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಹಣವನ್ನು ಗಳಿಸುವ ಕಂಪನಿಗಳಿಂದ (ದುಬಾರಿ) ಸೇವೆಗಳನ್ನು ಪೂರೈಸೋಣ ಮತ್ತು ಅವುಗಳಿಂದ ಋಣಾತ್ಮಕತೆಯ ಪ್ರಮಾಣವನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಒಂದರೊಂದಿಗೆ ಹೋಲಿಸೋಣ.
ಈ ಎರಡು ಪ್ರಯೋಗಗಳು ನಮಗೆ ಸಾಧಿಸಬಹುದಾದ ಗುರಿಯನ್ನು ಗುರುತಿಸಲು ಮತ್ತು ಅದರ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ವಾಡಿಕೆಯಂತೆ ಪರಿಹರಿಸಬಹುದಾದ ಹಲವಾರು ಕಾರ್ಯಗಳಿವೆ:
- ವ್ಯಕ್ತಿನಿಷ್ಠ ವಿಮರ್ಶೆಗಳ ಬದಲಿಗೆ ನಾವು ಸಂವಹನ ಗುಣಮಟ್ಟದ ತಾಂತ್ರಿಕ ಮೆಟ್ರಿಕ್ ಅನ್ನು ರಚಿಸುತ್ತೇವೆ;
- ಸಂಭವಿಸುವ ವೈಫಲ್ಯಗಳನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ವಿಶ್ಲೇಷಿಸಲು, ಅವು ಯಾವಾಗ ಮತ್ತು ಎಲ್ಲಿ ಸಂಭವಿಸಿದವು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಮತ್ತು ಆ ಕ್ಷಣದಲ್ಲಿ ಯಾವ ಸಂಬಂಧವಿಲ್ಲದ ಘಟನೆಗಳು ನಡೆದಿವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ನಾವು ಹೆಚ್ಚು ವಿವರವಾದ ಸೆಷನ್ ಲಾಗ್‌ಗಳನ್ನು ಮಾಡುತ್ತೇವೆ;
- ಪಾಠದ ಮೊದಲು ನಾವು ಸ್ವಯಂಚಾಲಿತ ಸಂಪರ್ಕ ಗುಣಮಟ್ಟ ಪರೀಕ್ಷೆಯನ್ನು ಸಿದ್ಧಪಡಿಸುತ್ತೇವೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗೆ ತನ್ನ ಹಾರ್ಡ್‌ವೇರ್ ಮತ್ತು ಚಾನಲ್‌ನಿಂದ ಉಂಟಾಗುವ ನಕಾರಾತ್ಮಕತೆಯ ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಂಪರ್ಕವನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ಪರೀಕ್ಷಿಸಲು ಅವಕಾಶವನ್ನು ನೀಡುತ್ತೇವೆ;
- ಕಳಪೆ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ, ವೇರಿಯಬಲ್ ಪ್ಯಾಕೆಟ್ ನಷ್ಟ, ಇತ್ಯಾದಿಗಳೊಂದಿಗೆ ನಾವು ಹೆಚ್ಚು ವೀಡಿಯೊ ಸಂವಹನ ಲೋಡ್ ಪರೀಕ್ಷೆಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇವೆ ಮತ್ತು ನಡೆಸುತ್ತೇವೆ.
- ದೋಷ ಸಹಿಷ್ಣುತೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಸಮಸ್ಯೆಗಳ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಸರ್ವರ್‌ಗಳ ನಡವಳಿಕೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ;
- ಸ್ಕೈಪ್ ಮಾಡುವಂತೆ, ಅವರ ಸಂಪರ್ಕದಲ್ಲಿ ಏನಾದರೂ ತಪ್ಪಾಗಿದ್ದರೆ ನಾವು ಬಳಕೆದಾರರಿಗೆ ಎಚ್ಚರಿಕೆ ನೀಡುತ್ತೇವೆ, ಇದರಿಂದಾಗಿ ಸಮಸ್ಯೆ ಅವನ ಕಡೆ ಇದೆ ಎಂದು ಅವನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾನೆ.
ಏಪ್ರಿಲ್‌ನಿಂದ, ವೀಡಿಯೊ ಸಂವಹನ ನಿರ್ದೇಶನವು ಸ್ಕೈಂಗ್‌ನಲ್ಲಿ ಪೂರ್ಣ ಪ್ರಮಾಣದ ಪ್ರತ್ಯೇಕ ಯೋಜನೆಯಾಗಿ ಮಾರ್ಪಟ್ಟಿದೆ, ಇದು ವಿಮ್‌ಬಾಕ್ಸ್‌ನ ಒಂದು ಭಾಗವಾಗಿರದೆ ತನ್ನದೇ ಆದ ಉತ್ಪನ್ನದೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತದೆ. ಇದರರ್ಥ ನಾವು ಜನರನ್ನು ಹುಡುಕಲು ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದೇವೆ . ಒಳ್ಳೆಯದು, ಎಂದಿನಂತೆ .
ಮತ್ತು, ಸಹಜವಾಗಿ, ನಾವು ವೀಡಿಯೊ ಸಂವಹನಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಜನರು ಮತ್ತು ಕಂಪನಿಗಳೊಂದಿಗೆ ಸಕ್ರಿಯವಾಗಿ ಸಂವಹನ ನಡೆಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ನೀವು ನಮ್ಮೊಂದಿಗೆ ಅನುಭವವನ್ನು ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ! ಕಾಮೆಂಟ್ ಮಾಡಿ, ಸಂಪರ್ಕದಲ್ಲಿರಿ - ನಾವು ಎಲ್ಲರಿಗೂ ಉತ್ತರಿಸುತ್ತೇವೆ.
ಮೂಲ: www.habr.com