Skype-დან WebRTC-მდე: როგორ მოვაწყვეთ ვიდეო კომუნიკაცია ინტერნეტის საშუალებით

ვიდეო კომუნიკაცია არის მასწავლებელსა და სტუდენტს შორის კომუნიკაციის მთავარი გზა Vimbox პლატფორმაზე. ჩვენ დიდი ხნის წინ მივატოვეთ Skype, ვცადეთ რამდენიმე მესამე მხარის გადაწყვეტა და საბოლოოდ დავსახლდით WebRTC - Janus-gateway კომბინაციაზე. გარკვეული პერიოდის განმავლობაში ჩვენ კმაყოფილი ვიყავით ყველაფრით, მაგრამ მაინც ჩნდებოდა გარკვეული უარყოფითი ასპექტები. შედეგად, შეიქმნა ცალკე ვიდეო მიმართულება.

მე ვთხოვე კირილ როგოვოის, ახალი მიმართულების ხელმძღვანელს, ისაუბრა Skyeng-ში ვიდეო კომუნიკაციის ევოლუციაზე, აღმოჩენილ პრობლემებზე, გადაწყვეტილებებზე და ყავარჯნებზე, რომლებიც ჩვენ საბოლოოდ გამოვიყენეთ. ვიმედოვნებთ, რომ სტატია სასარგებლო იქნება კომპანიებისთვის, რომლებიც ასევე ქმნიან ვიდეოს დამოუკიდებლად ვებ აპლიკაციის საშუალებით.

პატარა ისტორიის

2017 წლის ზაფხულში Skyeng-ის განვითარების ხელმძღვანელმა, სერგეი საფონოვმა ისაუბრა Backend Conf-ზე, სადაც მოთხრობილია იმის შესახებ, თუ როგორ „მივატოვეთ Skype და განვახორციელეთ WebRTC“. მსურველებს გამოსვლის ჩანაწერის ყურება შეუძლიათ მისამართზე ლინკები (~45 წთ) და აქ მოკლედ გამოვყოფ მის არსს.

Skyeng სკოლისთვის ვიდეო კომუნიკაცია ყოველთვის იყო მასწავლებელ-მოსწავლე კომუნიკაციის პრიორიტეტული გზა. თავიდან გამოიყენებოდა სკაიპი, მაგრამ ის კატეგორიულად არ იყო დამაკმაყოფილებელი რიგი მიზეზების გამო, უპირველეს ყოვლისა, ჟურნალების ნაკლებობისა და უშუალოდ ვებ აპლიკაციაში ინტეგრაციის შეუძლებლობის გამო. ამიტომ, ჩვენ ჩავატარეთ ყველა სახის ექსპერიმენტი.

სინამდვილეში, ჩვენი მოთხოვნები ვიდეო კომუნიკაციისთვის იყო დაახლოებით შემდეგი:
- სტაბილურობა;
- დაბალი ფასი გაკვეთილზე;
— გაკვეთილების ჩაწერა;
— თვალყური ადევნოთ ვინ რამდენს ლაპარაკობს (ჩვენთვის მნიშვნელოვანია, რომ გაკვეთილებზე მოსწავლეებმა მასწავლებელზე მეტი ისაუბრონ);
- ხაზოვანი მასშტაბირება;
- ორივე UDP და TCP გამოყენების შესაძლებლობა.

პირველი, ვინც სცადა იყო Tokbox-ის დანერგვა 2013 წელს. ყველაფერი კარგი იყო, მაგრამ ძალიან ძვირი აღმოჩნდა - გაკვეთილზე 113 მანეთი - და მოგება შეჭამა.

შემდეგ 2015 წელს Voximplant ინტეგრირებული იყო. ეს იყო ფუნქცია, რომელიც გვჭირდებოდა თვალყური ადევნეთ ვინ რამდენს ლაპარაკობდა და ამავდროულად გამოსავალი გაცილებით იაფი ღირდა: თუ მხოლოდ აუდიო ჩაიწერებოდა, გაკვეთილზე 20 მანეთი ღირდა. თუმცა, ის მხოლოდ UDP-ის საშუალებით მუშაობდა და TCP-ზე გადასვლა ვერ მოხერხდა. თუმცა, სტუდენტების დაახლოებით 40%-მა დაასრულა მისი გამოყენება.

ერთი წლის შემდეგ დავიწყეთ კორპორატიული კლიენტების გაჩენა საკუთარი სპეციფიკური მოთხოვნებით. მაგალითად, ყველაფერი ბრაუზერის საშუალებით უნდა მუშაობდეს, კომპანია ხსნის მხოლოდ http და https; ანუ არ არის სკაიპი ან UDP. კორპორატიული კლიენტები = ფული, ამიტომ ისინი დაბრუნდნენ Tokbox-ში, მაგრამ ფასის პრობლემა არ გაქრა.

გამოსავალი - WebRTC და Janus

გამოყენება გადაწყვიტა ბრაუზერის პლატფორმა peer-to-peer ვიდეო კომუნიკაციისთვის WebRTC. ის პასუხისმგებელია კავშირის დამყარებაზე, ნაკადების კოდირებასა და დეკოდირებაზე, ტრეკების სინქრონიზაციასა და ხარისხის კონტროლზე ქსელის ხარვეზების დამუშავებაზე. ჩვენი მხრივ, ჩვენ უნდა უზრუნველვყოთ ნაკადების წაკითხვა კამერიდან და მიკროფონიდან, ვიდეოს დახატვა, კავშირის მართვა, WebRTC კავშირის დამყარება და მასზე ნაკადების გადაცემა, ასევე კლიენტებს შორის სასიგნალო შეტყობინებების გადაცემა კავშირის დასამყარებლად (თავად WebRTC აღწერს მხოლოდ მონაცემთა ფორმატი, მაგრამ არა მისი მექანიზმის გადაცემა). თუ კლიენტები დგანან NAT-ის უკან, WebRTC აკავშირებს STUN სერვერებს; თუ ეს არ დაეხმარება, გადააქციეთ სერვერები.

რეგულარული p2p კავშირი ჩვენთვის საკმარისი არ არის, რადგან გვსურს ჩავწეროთ გაკვეთილები შემდგომი ანალიზისთვის საჩივრების შემთხვევაში. ამიტომ ჩვენ ვგზავნით WebRTC ნაკადებს რელეს საშუალებით იანუსის კარიბჭე Meetecho-ს მიერ. შედეგად, კლიენტებმა არ იციან ერთმანეთის მისამართები, ხედავენ მხოლოდ Janus სერვერის მისამართს; ის ასევე ასრულებს სიგნალის სერვერის ფუნქციებს. Janus-ს აქვს ბევრი ფუნქცია, რომელიც ჩვენ გვჭირდება: ავტომატურად გადადის TCP-ზე, თუ კლიენტს აქვს UDP დაბლოკილი; შეუძლია ორივე UDP და TCP ნაკადების ჩაწერა; მასშტაბირებადი; ექო ტესტებისთვის ჩაშენებული მოდულიც კი არის. საჭიროების შემთხვევაში, STUN და TURN სერვერები Twilio-დან ავტომატურად არის დაკავშირებული.

2017 წლის ზაფხულში ჩვენ გვქონდა გაშვებული ორი Janus სერვერი, პლუს დამატებითი სერვერი ჩაწერილი ნედლეული აუდიო და ვიდეო ფაილების დასამუშავებლად, რათა არ დაგვეჭირა ძირითადი პროცესორები. დაკავშირებისას იანუსის სერვერები შეირჩა კენტი-ლუწი პრინციპით (კავშირის ნომერი). იმ დროს ეს საკმარისი იყო, ჩვენი გრძნობების მიხედვით, უსაფრთხოების დაახლოებით ოთხმაგი ზღვარი მისცა, განხორციელების პროცენტი იყო დაახლოებით 80. ამავდროულად, ფასი შემცირდა ~2 რუბლამდე გაკვეთილზე, პლუს განვითარება და მხარდაჭერა.

ვუბრუნდებით ვიდეო კომუნიკაციის თემას

ჩვენ მუდმივად ვაკვირდებით სტუდენტებისა და მასწავლებლების უკუკავშირს, რათა დროულად გამოვავლინოთ და გამოვასწოროთ პრობლემები. 2018 წლის ზაფხულისთვის ზარის ხარისხი მტკიცედ იყო პირველ ადგილზე საჩივრებს შორის. ეს, ერთი მხრივ, იმას ნიშნავდა, რომ ჩვენ წარმატებით დავძლიეთ სხვა ნაკლოვანებები. მეორეს მხრივ, სასწრაფოდ იყო საჭირო რაღაცის გაკეთება: თუ გაკვეთილი ჩაიშალა, რისკავს მისი ღირებულების დაკარგვა, ზოგჯერ შემდეგი პაკეტის შეძენის ღირებულებასთან ერთად, ხოლო თუ შესავალი გაკვეთილი ჩაიშალა, რისკის ქვეშ დავკარგეთ პოტენციური კლიენტი. საერთოდ.

იმ დროს ჩვენი ვიდეო კომუნიკაცია ჯერ კიდევ MVP რეჟიმში იყო. მარტივად რომ ვთქვათ, გაუშვეს, იმუშავა, ერთხელ გააფართოვეს, მიხვდნენ, როგორ გაეკეთებინათ - კარგი, მშვენივრად. თუ მუშაობს, არ გაასწოროთ. არავინ შეგნებულად არ შეეხო კომუნიკაციის ხარისხის საკითხს. აგვისტოსთვის გაირკვა, რომ ასე ვეღარ გაგრძელდებოდა და ჩვენ დავიწყეთ ცალკე მიმართულება იმის გასარკვევად, თუ რა ჭირს WebRTC-სა და Janus-ს.

შეყვანისას ამ მიმართულებამ მიიღო: MVP გადაწყვეტა, არა მეტრიკა, არც მიზნები, არც გაუმჯობესების პროცესები, ხოლო მასწავლებელთა 7% უჩივის კომუნიკაციის ხარისხს (არც იყო მონაცემები მოსწავლეებზე).

ახალი მიმართულება მიმდინარეობს

ბრძანება ასე გამოიყურება:

• დეპარტამენტის უფროსი, რომელიც ასევე არის მთავარი დეველოპერი.
• QA ეხმარება ცვლილებების ტესტირებას, ეძებს ახალ გზებს არასტაბილური კომუნიკაციის პირობების შესაქმნელად და აცნობებს პრობლემებს წინა ხაზიდან.
• ანალიტიკოსი მუდმივად ეძებს სხვადასხვა კორელაციას ტექნიკურ მონაცემებში, აუმჯობესებს მომხმარებლის უკუკავშირის ანალიზს და ამოწმებს ექსპერიმენტების შედეგებს.
• პროდუქტის მენეჯერი ეხმარება ექსპერიმენტებისთვის რესურსების საერთო მიმართულებასა და განაწილებაში.
• მეორე დეველოპერი ხშირად ეხმარება პროგრამირებასა და მასთან დაკავშირებულ ამოცანებს.

დასაწყისისთვის, ჩვენ დავაყენეთ შედარებით საიმედო მეტრიკა, რომელიც თვალყურს ადევნებდა ცვლილებებს კომუნიკაციის ხარისხის შეფასებებში (საშუალოდ დღეებში, კვირებში, თვეებში). იმ დროს ეს იყო მასწავლებლების შეფასებები, მათ მოგვიანებით დაემატა სტუდენტების შეფასებები. შემდეგ მათ დაიწყეს ჰიპოთეზების აგება იმის შესახებ, თუ რა არასწორად მუშაობდა, გამოასწორეს და დაათვალიერეს ცვლილებები დინამიკაში. ჩვენ წავედით დაბალ დაკიდებულ ხილზე: მაგალითად, vp8 კოდეკი შევცვალეთ vp9-ით, გაუმჯობესდა შესრულება. ჩვენ ვცადეთ იანუსის პარამეტრებით თამაში და სხვა ექსპერიმენტების ჩატარება - უმეტეს შემთხვევაში მათ არაფრამდე არ მიგვიყვანდნენ.

მეორე ეტაპზე გაჩნდა ჰიპოთეზა: WebRTC არის peer-to-peer გადაწყვეტა და ჩვენ ვიყენებთ სერვერს შუაში. იქნებ პრობლემა აქ მდგომარეობს? ჩვენ დავიწყეთ გათხრა და აღმოვაჩინეთ აქამდე ყველაზე მნიშვნელოვანი გაუმჯობესება.

იმ მომენტში, აუზიდან სერვერი შეირჩა საკმაოდ სულელური ალგორითმის გამოყენებით: თითოეულს ჰქონდა თავისი „წონა“, არხისა და სიმძლავრის მიხედვით და ჩვენ ვცდილობდით მომხმარებლის გაგზავნას ყველაზე დიდი „წონის“ გარეშე. ყურადღება მიაქციეთ იმას, თუ სად იყო მომხმარებელი გეოგრაფიულად. შედეგად, პეტერბურგელ მასწავლებელს შეეძლო ციმბირიდან ჩამოსულ სტუდენტთან ურთიერთობა მოსკოვის გავლით და არა სანკტ-პეტერბურგის ჩვენი Janus სერვერის მეშვეობით.

ალგორითმი გადაკეთებულია: ახლა, როდესაც მომხმარებელი ხსნის ჩვენს პლატფორმას, ჩვენ ვაგროვებთ პინგებს მისგან ყველა სერვერზე Ajax-ის გამოყენებით. კავშირის დამყარებისას ვირჩევთ პინგების წყვილს (მასწავლებელი-სერვერი და მოსწავლე-სერვერი) ყველაზე მცირე რაოდენობით. ნაკლები პინგი ნიშნავს ქსელის ნაკლებ მანძილს სერვერამდე; მოკლე მანძილი ნიშნავს პაკეტების დაკარგვის ნაკლებ ალბათობას; პაკეტის დაკარგვა ყველაზე დიდი უარყოფითი ფაქტორია ვიდეო კომუნიკაციაში. ნეგატიურობის წილი სამ თვეში განახევრდა (სამართლიანი რომ ვიყოთ, ამ დროს სხვა ექსპერიმენტებიც ჩატარდა, მაგრამ ამ ექსპერიმენტმა თითქმის ყველაზე დიდი გავლენა მოახდინა).

ჩვენ ახლახან აღმოვაჩინეთ კიდევ ერთი არა აშკარა, მაგრამ აშკარად მნიშვნელოვანი რამ: ერთი ძლიერი Janus სერვერის ნაცვლად სქელ არხზე, უმჯობესია გქონდეთ ორი მარტივი უფრო თხელი გამტარობით. ეს ცხადი გახდა მას შემდეგ, რაც ჩვენ ვიყიდეთ მძლავრი მანქანები იმ იმედით, რომ მათში იმდენი ოთახი (საკომუნიკაციო სესიები) ერთდროულად ჩავსვათ. სერვერებს აქვთ გამტარუნარიანობის ლიმიტი, რომელიც შეგვიძლია ზუსტად გადავთარგმნოთ ოთახების რაოდენობაში - ვიცით რამდენის გახსნა შეიძლება, მაგალითად, 300 მბიტ/წმ სიჩქარით. როგორც კი სერვერზე ძალიან ბევრი ოთახია გახსნილი, ჩვენ ვწყვეტთ მის არჩევას ახალი აქტივობებისთვის, სანამ დატვირთვა არ შემცირდება. იდეა იყო, რომ მძლავრი აპარატის შეძენის შემდეგ, არხს მასზე მაქსიმალურად ჩავტვირთავდით, რათა საბოლოოდ იგი შემოიფარგლებოდეს პროცესორით და მეხსიერებით და არა გამტარუნარიანობით. მაგრამ აღმოჩნდა, რომ გარკვეული რაოდენობის ღია ოთახების შემდეგ (420), მიუხედავად იმისა, რომ პროცესორზე, მეხსიერებასა და დისკზე დატვირთვა ჯერ კიდევ ძალიან შორს არის საზღვრებისგან, ნეგატივი იწყებს ტექნიკურ მხარდაჭერას. როგორც ჩანს, იანუსის შიგნით რაღაც უარესდება, ალბათ იქაც არის გარკვეული შეზღუდვები. დავიწყეთ ექსპერიმენტები, შევამცირეთ გამტარუნარიანობის ლიმიტი 300-დან 200 მბიტ/წმ-მდე და პრობლემები გაქრა. ახლა ჩვენ ვიყიდეთ ერთდროულად სამი ახალი სერვერი დაბალი ლიმიტებითა და მახასიათებლებით, ვფიქრობთ, რომ ეს გამოიწვევს კომუნიკაციის ხარისხის სტაბილურ გაუმჯობესებას. რა თქმა უნდა, ჩვენ არ ვცდილობდით გაგვერკვია, რა ხდებოდა იქ, ჩვენი ხელჯოხები ყველაფერია. ჩვენი დასაცავად, ვთქვათ, რომ იმ მომენტში აუცილებელი იყო დაძაბული პრობლემის რაც შეიძლება სწრაფად გადაჭრა და არა ლამაზად გაკეთება; გარდა ამისა, იანუსი ჩვენთვის არის შავი ყუთი, რომელიც დაწერილია C-ზე, ძალიან ძვირი ღირს მისი დალაგება.

ისე, ამ პროცესში ჩვენ:

• განაახლეს ყველა დამოკიდებულება, რომლის განახლებაც შესაძლებელი იყო, როგორც სერვერზე, ასევე კლიენტზე (ესეც ექსპერიმენტები იყო, ჩვენ ვაკვირდებოდით შედეგებს);
• დააფიქსირა ყველა იდენტიფიცირებული ხარვეზი, რომელიც დაკავშირებულია კონკრეტულ შემთხვევებთან, მაგალითად, როდესაც კავშირი შეწყდა და ავტომატურად არ აღდგა;
• ჩვენ გავმართეთ უამრავი შეხვედრა ვიდეო კომუნიკაციების სფეროში მომუშავე კომპანიებთან და გაეცანით ჩვენს პრობლემებს: თამაშების სტრიმინგი, ვებინარების ორგანიზება; ჩვენ ვცადეთ ყველაფერი, რაც სასარგებლო გვეჩვენებოდა;
• ჩაატარა ტექნიკური მიმოხილვა მასწავლებელთა ტექნიკისა და კომუნიკაციის ხარისხის შესახებ, რომელთაგან ყველაზე მეტი პრეტენზია მოვიდა.

ექსპერიმენტებმა და შემდგომმა ცვლილებებმა შესაძლებელი გახადა 7,1 წლის იანვარში 2018%-დან 2,5 წლის იანვარში 2019%-მდე შემცირებულიყო მასწავლებელთა კომუნიკაციით უკმაყოფილება.

რა არის შემდეგი

ჩვენი Vimbox პლატფორმის სტაბილიზაცია კომპანიის ერთ-ერთი მთავარი პროექტია 2019 წლისთვის. ჩვენ დიდი იმედი გვაქვს, რომ შევძლებთ შევინარჩუნოთ იმპულსი და აღარ დავინახოთ ვიდეო კომუნიკაცია მთავარ საჩივრებში. ჩვენ გვესმის, რომ ამ საჩივრების მნიშვნელოვანი ნაწილი დაკავშირებულია მომხმარებლის კომპიუტერებსა და ინტერნეტში ჩამორჩენებთან, მაგრამ ეს ნაწილი უნდა განვსაზღვროთ და დანარჩენი გადავწყვიტოთ. ყველაფერი დანარჩენი ტექნიკური პრობლემაა, როგორც ჩანს, ჩვენ უნდა გავუმკლავდეთ მას.

მთავარი სირთულე ის არის, რომ ჩვენ არ ვიცით რეალურად რა დონეზეა შესაძლებელი ხარისხის გაუმჯობესება. ამ ჭერის გარკვევა მთავარი ამოცანაა. ამიტომ დაიგეგმა ორი ექსპერიმენტი:

1. შეადარეთ ვიდეო Janus-ის მეშვეობით ჩვეულებრივი p2p საბრძოლო პირობებში. ეს ექსპერიმენტი უკვე ჩატარდა, ჩვენს ხსნარსა და p2p-ს შორის სტატისტიკურად მნიშვნელოვანი განსხვავება არ აღმოჩნდა;
2. მოდით მივაწოდოთ (ძვირადღირებული) სერვისები კომპანიებისგან, რომლებიც ფულს შოულობენ ექსკლუზიურად ვიდეო საკომუნიკაციო გადაწყვეტილებებზე და შევადაროთ მათგან ნეგატივის რაოდენობა არსებულს.

ეს ორი ექსპერიმენტი საშუალებას მოგვცემს განვსაზღვროთ მიღწევადი მიზანი და ფოკუსირება მოახდინოთ მასზე.

გარდა ამისა, არსებობს მთელი რიგი ამოცანები, რომლებიც შეიძლება გადაწყდეს რუტინულად:

• სუბიექტური მიმოხილვის ნაცვლად ვქმნით კომუნიკაციის ხარისხის ტექნიკურ მეტრიკას;
• ჩვენ ვაკეთებთ სესიების უფრო დეტალურ ჩანაწერებს, რათა უფრო ზუსტად გავაანალიზოთ წარმოქმნილი წარუმატებლობები, გავიგოთ ზუსტად როდის და სად მოხდა ისინი და რა ერთი შეხედვით დაუკავშირებელი მოვლენები მოხდა იმ მომენტში;
• გაკვეთილის წინ ვამზადებთ კავშირის ხარისხის ავტომატურ ტესტს, ასევე ვაძლევთ კლიენტს შესაძლებლობას ხელით შეამოწმოს კავშირი, რათა შევამციროთ მისი აპარატურით და არხით გამოწვეული ნეგატივის რაოდენობა;
• ჩვენ შევიმუშავებთ და ჩავატარებთ უფრო მეტ ვიდეო კომუნიკაციის დატვირთვის ტესტებს ცუდ პირობებში, ცვლადი პაკეტის დაკარგვით და ა.შ.;
• პრობლემების შემთხვევაში ვცვლით სერვერების ქცევას შეცდომების ტოლერანტობის გაზრდის მიზნით;
• ჩვენ გავაფრთხილებთ მომხმარებელს, თუ მის კავშირში რაიმე პრობლემაა, როგორც ამას Skype აკეთებს, რათა მან გაიგოს, რომ პრობლემა მის მხარეზეა.

აპრილიდან ვიდეო კომუნიკაციის მიმართულება გახდა Skyeng-ის სრულფასოვანი ცალკეული პროექტი, რომელიც ეხება საკუთარ პროდუქტს და არა მხოლოდ Vimbox-ის ნაწილს. ეს ნიშნავს, რომ ჩვენ ვიწყებთ ხალხის ძებნას ვიდეოსთან მუშაობა სრული განაკვეთის რეჟიმში. ისე, როგორც ყოველთვის ჩვენ ვეძებთ ბევრ კარგ ადამიანს.

და, რა თქმა უნდა, ჩვენ ვაგრძელებთ აქტიურ კომუნიკაციას ადამიანებთან და კომპანიებთან, რომლებიც მუშაობენ ვიდეო კომუნიკაციებით. თუ გსურთ გამოცდილების გაცვლა ჩვენთან, მოხარული ვიქნებით! დააკომენტარეთ, დაგვიკავშირდით - ყველას გიპასუხებთ.

წყარო: www.habr.com