ពី Skype ទៅ WebRTC៖ របៀបដែលយើងរៀបចំទំនាក់ទំនងតាមវីដេអូតាមរយៈបណ្តាញ

ការប្រាស្រ័យទាក់ទងតាមវីដេអូគឺជាមធ្យោបាយសំខាន់នៃការទំនាក់ទំនងរវាងគ្រូ និងសិស្សនៅលើវេទិកា Vimbox ។ យើងបានបោះបង់ Skype តាំងពីយូរយារណាស់មកហើយ សាកល្បងដំណោះស្រាយភាគីទីបីជាច្រើន ហើយនៅទីបំផុតបានដោះស្រាយលើ WebRTC - Janus-gateway រួមបញ្ចូលគ្នា។ មួយ​រយៈ​ពេល​យើង​សប្បាយ​ចិត្ត​ជាមួយ​នឹង​អ្វី​គ្រប់​យ៉ាង ប៉ុន្តែ​នៅ​តែ​មាន​ទិដ្ឋភាព​អវិជ្ជមាន​មួយ​ចំនួន​បាន​បន្ត​លេច​ឡើង។ ជាលទ្ធផល ទិសដៅវីដេអូដាច់ដោយឡែកមួយត្រូវបានបង្កើតឡើង។

ខ្ញុំបានសួរលោក Kirill Rogovoy ដែលជាប្រធាននៃទិសដៅថ្មី ដើម្បីនិយាយអំពីការវិវត្តនៃការទំនាក់ទំនងតាមវីដេអូនៅ Skyeng បញ្ហាដែលបានរកឃើញ ដំណោះស្រាយ និងឈើច្រត់ដែលយើងបានប្រើនៅទីបំផុត។ យើងសង្ឃឹមថាអត្ថបទនឹងមានប្រយោជន៍សម្រាប់ក្រុមហ៊ុនដែលបង្កើតវីដេអូដោយខ្លួនឯងតាមរយៈកម្មវិធីគេហទំព័រ។

បន្តិចនៃប្រវត្តិសាស្រ្ត

នៅរដូវក្តៅឆ្នាំ 2017 ប្រធានផ្នែកអភិវឌ្ឍន៍ Skyeng លោក Sergey Safonov បាននិយាយនៅ Backend Conf ជាមួយនឹងរឿងរ៉ាវអំពីរបៀបដែលយើង "បោះបង់ចោល Skype និងអនុវត្ត WebRTC" ។ អ្នកដែលចាប់អារម្មណ៍អាចទស្សនាការថតសុន្ទរកថានៅ តំណភ្ជាប់ (~45 នាទី) ហើយនៅទីនេះខ្ញុំនឹងរៀបរាប់ដោយសង្ខេបអំពីខ្លឹមសាររបស់វា។

សម្រាប់សាលាស្កាយអេង ការប្រាស្រ័យទាក់ទងតាមវីដេអូតែងតែជាមធ្យោបាយអាទិភាពនៃការទំនាក់ទំនងគ្រូ-សិស្ស។ ដំបូងឡើយ Skype ត្រូវបានប្រើប្រាស់ ប៉ុន្តែវាមិនពេញចិត្តជាលំដាប់សម្រាប់ហេតុផលមួយចំនួន ជាចម្បងដោយសារតែការខ្វះខាតនៃកំណត់ហេតុ និងលទ្ធភាពនៃការរួមបញ្ចូលដោយផ្ទាល់ទៅក្នុងកម្មវិធីបណ្តាញ។ ដូច្នេះ យើង​បាន​ធ្វើ​ការ​ពិសោធន៍​គ្រប់​ប្រភេទ។

តាមពិត តម្រូវការរបស់យើងសម្រាប់ការទំនាក់ទំនងតាមវីដេអូគឺប្រហែលដូចខាងក្រោម៖
- ស្ថេរភាព;
- តម្លៃទាបក្នុងមួយមេរៀន;
- ការកត់ត្រាមេរៀន;
- តាមដានថាតើអ្នកណានិយាយប៉ុន្មាន (វាមានសារៈសំខាន់សម្រាប់យើងដែលសិស្សនិយាយច្រើនជាងគ្រូអំឡុងពេលមេរៀន);
- ការធ្វើមាត្រដ្ឋានលីនេអ៊ែរ;
- សមត្ថភាពក្នុងការប្រើទាំង UDP និង TCP ។

ការសាកល្បងដំបូងគឺត្រូវអនុវត្ត Tokbox ក្នុងឆ្នាំ 2013 ។ អ្វីគ្រប់យ៉ាងគឺល្អប៉ុន្តែវាប្រែទៅជាថ្លៃណាស់ - 113 រូប្លិក្នុងមួយមេរៀន - ហើយបានស៊ីប្រាក់ចំណេញ។

បន្ទាប់មកនៅឆ្នាំ 2015 Voximplant ត្រូវបានរួមបញ្ចូល។ នេះគឺជាមុខងារដែលយើងត្រូវតាមដានថាតើអ្នកណានិយាយប៉ុន្មាន ហើយក្នុងពេលតែមួយដំណោះស្រាយគឺថោកជាង៖ ប្រសិនបើមានតែសំឡេងប៉ុណ្ណោះត្រូវបានថត វាមានតម្លៃ 20 រូប្លិក្នុងមួយមេរៀន។ ទោះយ៉ាងណាក៏ដោយ វាដំណើរការតែតាមរយៈ UDP ហើយមិនអាចប្តូរទៅ TCP បានទេ។ ទោះយ៉ាងណាក៏ដោយ សិស្សប្រហែល 40% បានបញ្ចប់ការប្រើប្រាស់វា។

មួយឆ្នាំក្រោយមក យើងបានចាប់ផ្តើមមានអតិថិជនសាជីវកម្មជាមួយនឹងតម្រូវការជាក់លាក់ផ្ទាល់ខ្លួនរបស់ពួកគេ។ ឧទាហរណ៍ អ្វីគ្រប់យ៉ាងគួរតែដំណើរការតាមរយៈកម្មវិធីរុករកមួយ ក្រុមហ៊ុនបើកតែ http និង https ។ ឧ. គ្មាន Skype ឬ UDP ។ អតិថិជនសាជីវកម្ម = លុយ ដូច្នេះពួកគេបានត្រឡប់ទៅ Tokbox វិញ ប៉ុន្តែបញ្ហាតម្លៃមិនបាត់ទៅណាឡើយ។

ដំណោះស្រាយ - WebRTC និង Janus

សម្រេចចិត្តប្រើ វេទិកាកម្មវិធីរុករកតាមអ៊ីនធឺណិតសម្រាប់ការទំនាក់ទំនងវីដេអូពីគ្នាទៅម្នាក់ WebRTC. វាទទួលខុសត្រូវក្នុងការបង្កើតការតភ្ជាប់ ការអ៊ិនកូដ និងការឌិកូដស្ទ្រីម ការធ្វើសមកាលកម្មបទ និងការត្រួតពិនិត្យគុណភាពជាមួយនឹងការគ្រប់គ្រងបញ្ហាបណ្តាញ។ សម្រាប់ផ្នែករបស់យើង យើងត្រូវធានាឱ្យមានការអានស្ទ្រីមពីកាមេរ៉ា និងមីក្រូហ្វូន គូរវីដេអូ គ្រប់គ្រងការតភ្ជាប់ បង្កើតការតភ្ជាប់ WebRTC និងការបញ្ជូនស្ទ្រីមទៅវា ក៏ដូចជាការបញ្ជូនសារជាសញ្ញារវាងអតិថិជនដើម្បីបង្កើតការតភ្ជាប់ (WebRTC ខ្លួនវាពណ៌នាតែ ទ្រង់ទ្រាយទិន្នន័យ ប៉ុន្តែមិនផ្ទេរយន្តការរបស់វាទេ)។ ប្រសិនបើអតិថិជននៅពីក្រោយ NAT នោះ WebRTC ភ្ជាប់ម៉ាស៊ីនមេ STUN ប្រសិនបើវាមិនអាចជួយបានទេ សូមបង្វែរម៉ាស៊ីនមេ។

ការតភ្ជាប់ p2p ធម្មតាគឺមិនគ្រប់គ្រាន់សម្រាប់យើងទេ ពីព្រោះយើងចង់កត់ត្រាមេរៀនសម្រាប់ការវិភាគបន្ថែមក្នុងករណីមានការតវ៉ា។ ដូច្នេះ យើង​ផ្ញើ​ស្ទ្រីម WebRTC តាមរយៈ​ការបញ្ជូនត Janus Gateway ដោយ Metecho. ជាលទ្ធផល អតិថិជនមិនស្គាល់អាសយដ្ឋានរបស់គ្នាទៅវិញទៅមក ដោយឃើញតែអាសយដ្ឋានម៉ាស៊ីនមេ Janus ។ វាក៏ដំណើរការមុខងាររបស់ម៉ាស៊ីនមេសញ្ញាផងដែរ។ Janus មានលក្ខណៈពិសេសជាច្រើនដែលយើងត្រូវការ៖ ប្តូរដោយស្វ័យប្រវត្តិទៅ TCP ប្រសិនបើអតិថិជនបានរារាំង UDP ។ អាចថតបានទាំងស្ទ្រីម UDP និង TCP ។ អាចធ្វើមាត្រដ្ឋានបាន; មានសូម្បីតែកម្មវិធីជំនួយដែលភ្ជាប់មកជាមួយសម្រាប់ការធ្វើតេស្តអេកូ។ បើចាំបាច់ ម៉ាស៊ីនមេ STUN និង TURN ពី Twilio ត្រូវបានភ្ជាប់ដោយស្វ័យប្រវត្តិ។

នៅរដូវក្តៅឆ្នាំ 2017 យើងមានម៉ាស៊ីនមេ Janus ពីរដែលកំពុងដំណើរការ រួមទាំងម៉ាស៊ីនមេបន្ថែមសម្រាប់ដំណើរការឯកសារអូឌីយ៉ូ និងវីដេអូឆៅដែលបានថតទុក ដើម្បីកុំឱ្យកាន់កាប់ប្រព័ន្ធដំណើរការសំខាន់ៗ។ នៅពេលភ្ជាប់ ម៉ាស៊ីនមេ Janus ត្រូវបានជ្រើសរើសដោយផ្អែកលើលេខសេស (លេខភ្ជាប់)។ នៅពេលនោះ វាគ្រប់គ្រាន់ហើយ យោងទៅតាមអារម្មណ៍របស់យើង វាផ្តល់រឹមសុវត្ថិភាពប្រហែល 80 ដង ភាគរយនៃការអនុវត្តគឺប្រហែល 2 ។ ក្នុងពេលជាមួយគ្នានេះ តម្លៃត្រូវបានកាត់បន្ថយមកត្រឹម ~XNUMX rubles ក្នុងមួយមេរៀន បូករួមទាំងការអភិវឌ្ឍន៍ និងការគាំទ្រ។

ត្រឡប់ទៅប្រធានបទនៃការទំនាក់ទំនងវីដេអូ

យើងតាមដានជានិច្ចនូវមតិកែលម្អពីសិស្ស និងគ្រូ ដើម្បីកំណត់ និងកែតម្រូវបញ្ហាឱ្យបានទាន់ពេលវេលា។ ត្រឹមរដូវក្តៅឆ្នាំ 2018 គុណភាពនៃការហៅទូរសព្ទគឺស្ថិតនៅលំដាប់ទីមួយក្នុងចំណោមពាក្យបណ្តឹង។ ម៉្យាងវិញទៀត នេះមានន័យថា យើងបានយកឈ្នះលើចំណុចខ្វះខាតផ្សេងៗដោយជោគជ័យ។ ម៉្យាងវិញទៀត ចាំបាច់ត្រូវធ្វើអ្វីមួយជាបន្ទាន់៖ ប្រសិនបើមេរៀនត្រូវបានរំខាន យើងប្រថុយនឹងការបាត់បង់តម្លៃរបស់វា ជួនកាលរួមជាមួយនឹងការចំណាយលើការទិញកញ្ចប់បន្ទាប់ ហើយប្រសិនបើមេរៀនដំបូងត្រូវបានរំខាន យើងប្រថុយនឹងការបាត់បង់អតិថិជនសក្តានុពល។ ទាំងអស់គ្នា។

នៅពេលនោះ ការទំនាក់ទំនងតាមវីដេអូរបស់យើងនៅតែស្ថិតក្នុងទម្រង់ MVP។ និយាយឱ្យសាមញ្ញទៅ គេបើកដំណើរការវា វាដំណើរការ គេធ្វើមាត្រដ្ឋានម្តង យល់ពីរបៀបធ្វើវា ល្អណាស់។ ប្រសិនបើវាដំណើរការ កុំជួសជុលវា។ គ្មាននរណាម្នាក់បានដោះស្រាយបញ្ហាគុណភាពទំនាក់ទំនងដោយចេតនានោះទេ។ នៅខែសីហា វាច្បាស់ណាស់ថាវាមិនអាចបន្តបានទេ ហើយយើងបានចាប់ផ្តើមទិសដៅដាច់ដោយឡែកមួយដើម្បីរកមើលអ្វីដែលខុសជាមួយ WebRTC និង Janus ។

តាមការបញ្ចូល ទិសដៅនេះបានទទួល៖ ដំណោះស្រាយ MVP គ្មានមាត្រដ្ឋាន គ្មានគោលដៅ គ្មានដំណើរការសម្រាប់កែលម្អ ខណៈដែលគ្រូបង្រៀន 7% ត្អូញត្អែរអំពីគុណភាពនៃការទំនាក់ទំនង (មិនមានទិន្នន័យលើសិស្សផងដែរ)។

ទិសដៅថ្មីមួយកំពុងដំណើរការ

ពាក្យបញ្ជាមើលទៅដូចនេះ៖

• ប្រធាននាយកដ្ឋាន ដែលជាអ្នកអភិវឌ្ឍន៍សំខាន់ផងដែរ។
• QA ជួយសាកល្បងការផ្លាស់ប្តូរ រកមើលវិធីថ្មីដើម្បីបង្កើតលក្ខខណ្ឌទំនាក់ទំនងមិនស្ថិតស្ថេរ និងរាយការណ៍បញ្ហាពីជួរមុខ។
• អ្នកវិភាគតែងតែស្វែងរកការជាប់ទាក់ទងគ្នាជាច្រើននៅក្នុងទិន្នន័យបច្ចេកទេស ធ្វើអោយប្រសើរឡើងនូវការវិភាគនៃមតិអ្នកប្រើ និងពិនិត្យមើលលទ្ធផលនៃការពិសោធន៍។
• អ្នកគ្រប់គ្រងផលិតផលជួយក្នុងទិសដៅរួម និងការបែងចែកធនធានសម្រាប់ការពិសោធន៍។
• អ្នកអភិវឌ្ឍន៍ទីពីរតែងតែជួយដល់ការសរសេរកម្មវិធី និងកិច្ចការពាក់ព័ន្ធ។

ដើម្បីចាប់ផ្តើមជាមួយ យើងរៀបចំរង្វាស់ដែលអាចទុកចិត្តបានដែលតាមដានការផ្លាស់ប្តូរក្នុងការវាយតម្លៃគុណភាពទំនាក់ទំនង (ជាមធ្យមក្នុងរយៈពេលជាច្រើនថ្ងៃ សប្តាហ៍ ខែ)។ នៅ​ពេល​នោះ ទាំង​នេះ​គឺ​ជា​ថ្នាក់​ពី​គ្រូ ហើយ​ថ្នាក់​ក្រោយ​មក​ពី​សិស្ស​ត្រូវ​បាន​បន្ថែម​ទៅ​ពួក​គេ។ បន្ទាប់មកពួកគេបានចាប់ផ្តើមបង្កើតសម្មតិកម្មអំពីអ្វីដែលកំពុងដំណើរការខុស កែវា និងមើលការផ្លាស់ប្តូរនៅក្នុងថាមវន្ត។ យើងបានទៅរកផ្លែឈើដែលព្យួរទាប៖ ឧទាហរណ៍ យើងបានជំនួសកូឌិក vp8 ជាមួយ vp9 ដំណើរការបានប្រសើរឡើង។ យើងបានព្យាយាមលេងជាមួយការកំណត់ Janus និងធ្វើការពិសោធន៍ផ្សេងទៀត - ក្នុងករណីភាគច្រើនពួកគេមិននាំទៅរកអ្វីនោះទេ។

នៅដំណាក់កាលទីពីរ សម្មតិកម្មមួយបានលេចចេញមក៖ WebRTC គឺជាដំណោះស្រាយពីមិត្តភ័ក្តិ ហើយយើងប្រើម៉ាស៊ីនមេនៅកណ្តាល។ ប្រហែលជាបញ្ហានៅទីនេះ? យើង​បាន​ចាប់​ផ្តើម​ជីក​កកាយ ហើយ​បាន​រក​ឃើញ​ការ​កែ​លម្អ​ដ៏​សំខាន់​បំផុត​រហូត​មក​ដល់​ពេល​នេះ។

នៅពេលនោះ ម៉ាស៊ីនមេពីអាងត្រូវបានជ្រើសរើសដោយប្រើក្បួនដោះស្រាយដ៏ឆោតល្ងង់៖ នីមួយៗមាន "ទម្ងន់" ផ្ទាល់ខ្លួន អាស្រ័យលើឆានែល និងថាមពល ហើយយើងបានព្យាយាមបញ្ជូនអ្នកប្រើប្រាស់ទៅកាន់ឧបករណ៍ដែលមាន "ទម្ងន់" ធំបំផុត ដោយគ្មាន យកចិត្តទុកដាក់ចំពោះកន្លែងដែលអ្នកប្រើប្រាស់ស្ថិតនៅភូមិសាស្ត្រ។ ជាលទ្ធផល គ្រូបង្រៀនមកពីទីក្រុង St. Petersburg អាចទំនាក់ទំនងជាមួយសិស្សមកពីស៊ីបេរី តាមរយៈទីក្រុងម៉ូស្គូ ហើយមិនមែនតាមរយៈម៉ាស៊ីនមេ Janus របស់យើងនៅ St.

ក្បួនដោះស្រាយត្រូវបានធ្វើឡើងវិញ៖ ឥឡូវនេះ នៅពេលដែលអ្នកប្រើប្រាស់បើកវេទិការបស់យើង យើងប្រមូល pings ពីគាត់ទៅគ្រប់ម៉ាស៊ីនមេដោយប្រើ Ajax ។ នៅពេលបង្កើតការតភ្ជាប់ យើងជ្រើសរើស pings មួយគូ (teacher-server និង student-server) ជាមួយនឹងចំនួនតិចបំផុត។ តិច ping មានន័យថាចម្ងាយបណ្តាញតិចទៅម៉ាស៊ីនមេ។ ចម្ងាយខ្លីមានន័យថាប្រូបាប៊ីលីតេទាបនៃការបាត់បង់កញ្ចប់ព័ត៌មាន។ ការបាត់បង់កញ្ចប់ព័ត៌មានគឺជាកត្តាអវិជ្ជមានដ៏ធំបំផុតក្នុងការទំនាក់ទំនងតាមវីដេអូ។ ចំណែកនៃភាពអវិជ្ជមានបានធ្លាក់ចុះពាក់កណ្តាលក្នុងរយៈពេលបីខែ (ដើម្បីឱ្យមានភាពយុត្តិធម៌ ការពិសោធន៍ផ្សេងទៀតត្រូវបានអនុវត្តនៅពេលនេះ ប៉ុន្តែរឿងនេះស្ទើរតែពិតជាមានផលប៉ះពាល់បំផុត)។

ថ្មីៗនេះ យើងបានរកឃើញរឿងមិនច្បាស់មួយផ្សេងទៀត ប៉ុន្តែជាក់ស្តែងមានសារៈសំខាន់៖ ជំនួសឱ្យម៉ាស៊ីនមេ Janus ដែលមានអនុភាពមួយនៅលើឆានែលក្រាស់ វាជាការប្រសើរជាងដែលមានពីរសាមញ្ញជាងជាមួយនឹងកម្រិតបញ្ជូនស្តើងជាង។ នេះ​បាន​ក្លាយ​ជា​ច្បាស់​បន្ទាប់​ពី​យើង​បាន​ទិញ​ម៉ាស៊ីន​ដ៏​មាន​ឥទ្ធិពល​ដោយ​សង្ឃឹម​ថា​នឹង​មាន​បន្ទប់​ជាច្រើន (វគ្គ​ទំនាក់ទំនង) ចូល​ក្នុង​ពេល​តែ​មួយ។ ម៉ាស៊ីនមេមានដែនកំណត់កម្រិតបញ្ជូន ដែលយើងអាចបកប្រែបានយ៉ាងត្រឹមត្រូវទៅក្នុងចំនួនបន្ទប់ - យើងដឹងថាប៉ុន្មានអាចបើកបាន ឧទាហរណ៍នៅ 300 Mbit/s ។ នៅពេលដែលមានបន្ទប់ច្រើនពេកបើកនៅលើម៉ាស៊ីនមេ យើងឈប់ជ្រើសរើសវាសម្រាប់សកម្មភាពថ្មីរហូតដល់ការផ្ទុកថយចុះ។ គំនិតនេះគឺថាដោយបានទិញម៉ាស៊ីនដ៏ខ្លាំងមួយ យើងនឹងផ្ទុកឆានែលទៅវាដល់អតិបរមា ដូច្នេះនៅទីបញ្ចប់វានឹងត្រូវបានកំណត់ដោយខួរក្បាល និងអង្គចងចាំ ហើយមិនមែនដោយកម្រិតបញ្ជូននោះទេ។ ប៉ុន្តែវាបានប្រែក្លាយថាបន្ទាប់ពីចំនួនជាក់លាក់នៃបន្ទប់បើកចំហ (420) ទោះបីជាការពិតដែលថាការផ្ទុកនៅលើខួរក្បាលអង្គចងចាំនិងថាសនៅតែឆ្ងាយពីដែនកំណត់ក៏ដោយភាពអវិជ្ជមានចាប់ផ្តើមមកដល់ជំនួយបច្ចេកទេស។ ជាក់ស្តែង មានអ្វីមួយកាន់តែអាក្រក់នៅក្នុង Janus ប្រហែលជាមានការរឹតបន្តឹងមួយចំនួននៅទីនោះផងដែរ។ យើងចាប់ផ្តើមពិសោធន៍ បន្ថយកម្រិតបញ្ជូនពី 300 ទៅ 200 Mbit/s ហើយបញ្ហាបានបាត់ទៅវិញ។ ឥឡូវនេះ យើងបានទិញម៉ាស៊ីនមេថ្មីចំនួន XNUMX ក្នុងពេលតែមួយជាមួយនឹងកម្រិតទាប និងលក្ខណៈ យើងគិតថាវានឹងនាំទៅរកការកែលម្អប្រកបដោយស្ថេរភាពនៅក្នុងគុណភាពនៃការទំនាក់ទំនង។ ជា​ការ​ពិត​ណាស់ យើង​មិន​បាន​ព្យាយាម​ស្វែង​យល់​ពី​អ្វី​ដែល​កំពុង​កើត​ឡើង​នៅ​ទី​នោះ​ទេ ឈើ​ច្រត់​របស់​យើង​គឺ​ជា​អ្វី​គ្រប់​យ៉ាង។ នៅក្នុងការការពាររបស់យើង ចូរនិយាយថានៅពេលនោះ វាចាំបាច់ក្នុងការដោះស្រាយបញ្ហាសង្កត់ឱ្យលឿនតាមដែលអាចធ្វើទៅបាន ហើយមិនត្រូវធ្វើវាឱ្យស្អាតនោះទេ។ ក្រៅពីនេះ Janus សម្រាប់ពួកយើងគឺជាប្រអប់ខ្មៅដែលសរសេរជាអក្សរ C វាមានតម្លៃថ្លៃណាស់ក្នុងការប្រើវា។

ជាការប្រសើរណាស់, នៅក្នុងដំណើរការយើង:

• បានធ្វើបច្ចុប្បន្នភាពភាពអាស្រ័យទាំងអស់ដែលអាចត្រូវបានធ្វើបច្ចុប្បន្នភាពទាំងនៅលើម៉ាស៊ីនមេ និងនៅលើម៉ាស៊ីនភ្ញៀវ (ទាំងនេះក៏ជាការពិសោធន៍ផងដែរ យើងបានត្រួតពិនិត្យលទ្ធផល);
• ជួសជុលកំហុសដែលបានកំណត់អត្តសញ្ញាណទាំងអស់ដែលទាក់ទងនឹងករណីជាក់លាក់ ឧទាហរណ៍ នៅពេលដែលការតភ្ជាប់បានធ្លាក់ចុះ និងមិនត្រូវបានស្ដារឡើងវិញដោយស្វ័យប្រវត្តិ។
• យើងបានរៀបចំកិច្ចប្រជុំជាច្រើនជាមួយក្រុមហ៊ុនដែលធ្វើការក្នុងវិស័យទំនាក់ទំនងតាមវីដេអូ និងដឹងពីបញ្ហារបស់យើង៖ ការផ្សាយហ្គេម ការរៀបចំសិក្ខាសាលាតាមអ៊ីនធឺណិត។ យើងបានព្យាយាមអ្វីគ្រប់យ៉ាងដែលហាក់ដូចជាមានប្រយោជន៍សម្រាប់យើង។
• បានធ្វើការត្រួតពិនិត្យបច្ចេកទេសលើគុណភាពផ្នែករឹង និងទំនាក់ទំនងរបស់គ្រូបង្រៀន ដែលពាក្យបណ្តឹងភាគច្រើនបានមក។

ការពិសោធន៍ និងការផ្លាស់ប្តូរជាបន្តបន្ទាប់បានធ្វើឱ្យវាអាចកាត់បន្ថយការមិនពេញចិត្តជាមួយនឹងការប្រាស្រ័យទាក់ទងរវាងគ្រូបង្រៀនពី 7,1% ក្នុងខែមករា ឆ្នាំ 2018 មកត្រឹម 2,5% ក្នុងខែមករា ឆ្នាំ 2019។

មាន​អ្វី​បន្ទាប់

ស្ថេរភាពវេទិកា Vimbox របស់យើងគឺជាគម្រោងចម្បងមួយរបស់ក្រុមហ៊ុនសម្រាប់ឆ្នាំ 2019 ។ យើង​មាន​សង្ឃឹម​ខ្ពស់​ថា​យើង​នឹង​អាច​រក្សា​សន្ទុះ ហើយ​លែង​ឃើញ​ការ​ទំនាក់ទំនង​តាម​វីដេអូ​ក្នុង​បណ្តឹង​កំពូល​ទៀត​ហើយ។ យើងយល់ថាផ្នែកសំខាន់មួយនៃពាក្យបណ្តឹងទាំងនេះគឺទាក់ទងទៅនឹងភាពយឺតយ៉ាវនៃកុំព្យូទ័រ និងអ៊ីនធឺណិតរបស់អ្នកប្រើប្រាស់ ប៉ុន្តែយើងត្រូវកំណត់ផ្នែកនេះ និងដោះស្រាយនៅសល់។ អ្វីផ្សេងទៀតគឺជាបញ្ហាបច្ចេកទេស វាហាក់ដូចជាយើងគួរតែអាចដោះស្រាយវាបាន។

ការលំបាកចម្បងគឺថាយើងមិនដឹងថាកម្រិតណាដែលវាពិតជាអាចធ្វើទៅបានដើម្បីកែលម្អគុណភាព។ ការស្វែងរកពិដាននេះគឺជាកិច្ចការចម្បង។ ដូច្នេះការពិសោធន៍ចំនួនពីរត្រូវបានគ្រោងទុក៖

1. ប្រៀបធៀបវីដេអូតាមរយៈ Janus ជាមួយ p2p ធម្មតានៅក្នុងលក្ខខណ្ឌប្រយុទ្ធ។ ការពិសោធន៍នេះត្រូវបានអនុវត្តរួចហើយ គ្មានភាពខុសប្លែកគ្នាជាស្ថិតិត្រូវបានរកឃើញរវាងដំណោះស្រាយរបស់យើង និង p2p;
2. តោះផ្គត់ផ្គង់សេវាកម្ម (ថ្លៃ) ពីក្រុមហ៊ុនដែលរកលុយបានទាំងស្រុងលើដំណោះស្រាយទំនាក់ទំនងតាមវីដេអូ ហើយប្រៀបធៀបចំនួនអវិជ្ជមានពីពួកគេជាមួយនឹងសេវាកម្មដែលមានស្រាប់។

ការពិសោធន៍ទាំងពីរនេះនឹងអនុញ្ញាតឱ្យយើងកំណត់គោលដៅដែលអាចសម្រេចបាន ហើយផ្តោតលើវា។

លើសពីនេះទៀត មានកិច្ចការមួយចំនួនដែលអាចដោះស្រាយបានជាប្រចាំ៖

• យើងបង្កើតរង្វាស់បច្ចេកទេសនៃគុណភាពទំនាក់ទំនងជំនួសឱ្យការពិនិត្យមើលប្រធានបទ។
• យើងបង្កើតកំណត់ហេតុវគ្គលម្អិតបន្ថែមទៀត ដើម្បីវិភាគឲ្យបានកាន់តែច្បាស់អំពីភាពបរាជ័យដែលកើតឡើង ស្វែងយល់ពីពេលណា និងទីកន្លែងដែលវាកើតឡើង និងអ្វីដែលហាក់ដូចជាព្រឹត្តិការណ៍ដែលមិនទាក់ទងគ្នាបានកើតឡើងនៅពេលនោះ។
• យើងរៀបចំការធ្វើតេស្តគុណភាពនៃការតភ្ជាប់ដោយស្វ័យប្រវត្តិមុនពេលមេរៀន ហើយថែមទាំងផ្តល់ឱ្យអតិថិជននូវឱកាសដើម្បីសាកល្បងការតភ្ជាប់ដោយដៃ ដើម្បីកាត់បន្ថយចំនួនអវិជ្ជមានដែលបណ្តាលមកពីផ្នែករឹង និងឆានែលរបស់គាត់។
• យើងនឹងអភិវឌ្ឍ និងធ្វើតេស្ដផ្ទុកទំនាក់ទំនងវីដេអូបន្ថែមទៀតក្នុងស្ថានភាពមិនល្អ ជាមួយនឹងការបាត់បង់កញ្ចប់ព័ត៌មានអថេរ។ល។
• យើងផ្លាស់ប្តូរឥរិយាបថរបស់ម៉ាស៊ីនមេ ក្នុងករណីមានបញ្ហា ដើម្បីបង្កើនការអត់ធ្មត់កំហុស។
• យើង​នឹង​ព្រមាន​អ្នក​ប្រើ​ប្រសិន​បើ​មាន​អ្វី​ខុស​ជាមួយ​ការ​តភ្ជាប់​របស់​គាត់​ដូច​ដែល Skype ធ្វើ ដូច្នេះ​គាត់​យល់​ថា​បញ្ហា​គឺ​នៅ​ខាង​គាត់។

ចាប់តាំងពីខែមេសា ទិសដៅទំនាក់ទំនងតាមវីដេអូបានក្លាយទៅជាគម្រោងដាច់ដោយឡែកពេញលេញមួយនៅក្នុង Skyeng ដែលទាក់ទងនឹងផលិតផលរបស់ខ្លួន មិនត្រឹមតែជាផ្នែកមួយនៃ Vimbox ប៉ុណ្ណោះទេ។ នេះមានន័យថាយើងកំពុងចាប់ផ្តើមស្វែងរកមនុស្សនៅលើ ធ្វើការជាមួយវីដេអូក្នុងរបៀបពេញម៉ោង. ដូចសព្វដង យើងកំពុងស្វែងរកមនុស្សល្អជាច្រើន។.

ហើយជាការពិតណាស់ យើងបន្តទំនាក់ទំនងយ៉ាងសកម្មជាមួយមនុស្ស និងក្រុមហ៊ុនដែលធ្វើការជាមួយទំនាក់ទំនងតាមវីដេអូ។ ប្រសិនបើអ្នកចង់ផ្លាស់ប្តូរបទពិសោធន៍ជាមួយយើង យើងនឹងរីករាយ! Comment ទំនាក់ទំនងមកយើងខ្ញុំនឹងឆ្លើយទាំងអស់គ្នា។

ប្រភព: www.habr.com