WebRTC (Web Real Time Communications) არის სტანდარტი, რომელიც აღწერს აუდიოს, ვიდეოს და კონტენტის გადაცემას ბრაუზერიდან რეალურ დროში, დანამატების ან სხვა გაფართოებების დაყენების გარეშე. სტანდარტი საშუალებას გაძლევთ გადართოთ ბრაუზერი ვიდეო კონფერენციის ბოლო ტერმინალზე და უბრალოდ გახსნათ ვებ გვერდი ჩამოტვირთვის დასაბეჭდად.

რა არის WebRTC?

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

რა უნდა იცოდეთ WebRTC-ის შესახებ?

ვიდეო კომუნიკაციის სტანდარტებისა და ტექნოლოგიების ევოლუცია

Sergiy Yutsaytis, Cisco, ვიდეო+კონფერენცია 2016 წ

როგორ მუშაობს WebRTC?

კლიენტის მხარეს

• Koristuvach ხსნის გვერდს HTML5 ტეგის დასამატებლად
• ბრაუზერი ითხოვს წვდომას მომხმარებლის ვებკამერაზე და მიკროფონზე.
• კლიენტის ვებსაიტზე JavaScript კოდი აკონტროლებს კავშირის პარამეტრებს (IP მისამართები და WebRTC სერვერის ან სხვა WebRTC კლიენტების პორტები) NAT და Firewall-ის გვერდის ავლით.
• როდესაც თქვენ წაშლით ინფორმაციას ბრაუზერის ან ნაკადის შესახებ კონფერენციიდან, რომელიც მასპინძლობს სერვერზე, ბრაუზერი იწყებს არჩეული აუდიო და ვიდეო კოდეკების მიღებას.
• იწყება WebRTC კლიენტებს შორის ნაკადის მონაცემების კოდირებისა და გადაცემის პროცესი (ჩვენს შემთხვევაში ბრაუზერსა და სერვერს შორის).

WebRTC სერვერის მხარეს

ორ მონაწილეს შორის მონაცემების გასაცვლისთვის, ვიდეო სერვერი არ არის საჭირო, გარდა იმ შემთხვევისა, როდესაც არ დაგჭირდებათ რამდენიმე მონაწილის გაერთიანება ერთ კონფერენციაში, საჭიროა სერვერი.

ვიდეო სერვერი ამოიღებს მედია ტრაფიკს სხვადასხვა მოწყობილობებიდან, გარდაქმნის მას და აძლიერებს მომხმარებლებს, როგორც ტერმინალი, რომელიც იყენებს WebRTC-ს.

WebRTC სერვერი ასევე წყვეტს მედია ტრაფიკს WebRTC ბანკეტებიდან და გადასცემს მას კონფერენციის მონაწილეებს, როგორიცაა vikorist პროგრამები დესკტოპ კომპიუტერებიან კიდევ მობილური მოწყობილობები, არის შემთხვევები, როცა ასეთი რამ აშკარაა.

უპირატესობები სტანდარტთან მიმართებაში

• არ არის საჭირო PZ-ის დაყენება.
• კავშირის სიმწარე ძალიან მაღალია:
  • მოძებნეთ მიმდინარე ვიდეოები (VP8, H.264) და აუდიო კოდეკები (Opus).
  • გონების ნაკადის ავტომატური რეგულირება.
  • დაინერგა ხმაურის შემცირების სისტემა.
  • მონაწილეთა მიკროფონების (ARS) მგრძნობელობის დონის ავტომატური რეგულირება.
• უსაფრთხოების მაღალი დონე: ყველა კომუნიკაცია დაცული და დაშიფრულია TLS და SRTP პროტოკოლების გამოყენებით.
• არსებობს შინაარსის შენახვის მექანიზმი, მაგალითად, სამუშაო მაგიდაზე.
• ნებისმიერი სახის ბირთვის ინტერფეისის დანერგვის შესაძლებლობა HTML5 და JavaScript-ზე დაფუძნებული.
• ინტერფეისის ინტეგრირების შესაძლებლობა ნებისმიერ back-end სისტემასთან WebSockets-ის გამოყენებით.
• პროექტი ვიკრიტი გამომავალი კოდი- შეგიძლიათ თქვენი პროდუქტის ან სერვისის პოპულარიზაცია.
• გამოსადეგი cross-platform: ერთი და იგივე WebRTC დანამატი კარგად იმუშავებს, რაც არ უნდა მოხდეს ოპერაციული სისტემა, დესკტოპის და მობილურის, რადგან ბრაუზერი მხარს უჭერს WebRTC-ს. მნიშვნელოვანია რესურსების დაზოგვა პროგრამული უზრუნველყოფის შემუშავებისთვის.

არ არის საკმარისი სტანდარტისთვის

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

WebRTC-ის საიდუმლოებები: როგორ შეუძლიათ მოვაჭრეებს ამოიღონ ღირებულება დამარღვეველი ვებ ტექნოლოგიიდან

Tsachi Levent-Levi, Bloggeek.me, ვიდეო+კონფერენცია 2015 წ

WebRTC ბაზრის ვიდეო კონფერენციისთვის

გაიზარდა ვიდეოკონფერენციის ტერმინალების რაოდენობა

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

მოძებნეთ სპეციალიზებული გადაწყვეტილებები

სხვადასხვა JavaScript ბიბლიოთეკებისა და ბნელი სერვისების API-ების კომბინაცია WebRTC-ის მხარდაჭერით საშუალებას გაძლევთ მარტივად დაამატოთ ვიდეო მხარდაჭერა ნებისმიერ ვებ პროექტში. ადრე, მონაცემების რეალურ დროში გადასაცემად, დისტრიბუტორებს უნდა ესწავლათ რობოტული პროტოკოლების პრინციპები და გამოეყენებინათ სხვა კომპანიების პრაქტიკა, რაც ხშირად მოითხოვდა დამატებით ლიცენზირებას, რამაც გაზარდა ხარჯები. WebRTC ახლა აქტიურად რეკლამირებულია ისეთ სერვისებში, როგორიცაა „საიტზე დარეკვა“, „ონლაინ ჩატის მხარდაჭერა“ და ა.შ.

ყოფილი Koristuvacham Skype Linux-ისთვის

2014 წელს Microsoft-მა გამოაცხადა Skype for Linux პროექტის მხარდაჭერა, რამაც დიდი იმედგაცრუება გამოიწვია IT მუშაკებში. WebRTC ტექნოლოგია არ არის მიბმული ოპერაციულ სისტემასთან, მაგრამ დანერგილია მხოლოდ ბრაუზერის დონეზე. Linux-ის დეველოპერები WebRTC-ზე დაფუძნებული პროდუქტებითა და სერვისებით, შეგიძლიათ მიიღოთ Skype-ის სრული ჩანაცვლება.

კონკურენცია Flash-ით

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

ვიდეო პრეზენტაციები WebRTC

დიმიტრო ოდინცოვი, TrueConf, ვიდეო+კონფერენცია ჟოვტენი 2017 წ

WebRTC კოდეკები

აუდიო კოდეკები

WebRTC აუდიო ტრაფიკის შეკუმშვისთვის გამოიყენება Opus და G.711 კოდეკები.

G.711- უძველესი ხმის კოდეკი მაღალი ბიტური სიჩქარით (64 kbps), რომელიც ყველაზე ხშირად ჩერდება სისტემებში ტრადიციული ტელეფონი. მთავარი უპირატესობა არის მინიმალური გამოთვლითი მოგება სინათლის შეკუმშვის ალგორითმების გამოყენებით. კოდეკი იცვლება დაბალი დონეხმოვანი სიგნალების შეკუმშვა და დინამიკებს შორის შერევის დროს ბგერაზე დამატებითი ხმაურის შემოტანა.

G.711 მხარდაჭერილია მოწყობილობების დიდი რაოდენობით. სისტემები, რომლებიც იყენებენ ამ კოდეკს, უფრო ადვილად ინსტალირებულია, ვიდრე სხვა აუდიო კოდეკებზე (G.723, G.726, G.728 და ა.შ.). G.711 ყუთისთვის ტესტირებულ MOS-ს 4.2 ქულა წაართმევს (4-5 ქულა არის ყველაზე მაღალი და ნიშნავს გარნა იაკისტიხმოვანი ტრაფიკის ISDN-ზე და მის ფარგლებს გარეთ გადაცემის სიჩქარის მსგავსი).

ოპუსი- ამ კოდეკს აქვს კოდირების დაბალი შეყოვნება (2,5 ms-დან 60 ms-მდე), მხარს უჭერს ცვლადი ბიტის სიხშირეს და მაღალი დონეშეკუმშვა, რომელიც იდეალურია ნაკადის აუდიოს გადასაცემად იმ დროს, როდესაც გამტარობა ცვალებადია. Opus არის ჰიბრიდული ხსნარი, რომელიც აერთიანებს საუკეთესო მახასიათებლებიკოდეკები SILK (ხმის შეკუმშვა, ადამიანის მეტყველების ჩახშობა) და CELT (აუდიო კოდირება). კოდეკი ხელმისაწვდომია საზოგადოებისთვის და მასში გამარჯვებული გამომცემლები არ საჭიროებენ იურიდიული გადასახადის გადახდას. სხვა აუდიო კოდეკებთან შედარებით, Opus, რა თქმა უნდა, იმარჯვებს შესრულების სიმდიდრით. შეგიძლიათ ჩამოტვირთოთ პოპულარული კოდეკები დაბალი ბიტური სიჩქარით, როგორიცაა MP3, Vorbis, AAC LC. Opus აახლოებს ხმის სურათს ორიგინალთან, ვიდრე AMR-WB და Speex. ეს კოდეკი მალე გამოვა და WebRTC ტექნოლოგიის შემქმნელებმა შეიტანეს ის აუდიო სტანდარტების ყოვლისმომცველ დიაპაზონში, რომელსაც ისინი მიჰყვებიან.

ვიდეო კოდეკები

WebRTC-ისთვის ვიდეო კოდეკის არჩევანი იქნა აღებული რამდენიმე საცალო ვაჭრობისგან, შედეგი იყო H.264 და VP8. Თითქმის ყველაფერი მიმდინარე ბრაუზერებიშეურაცხმყოფელი კოდეკების მხარდაჭერა. იმისთვის, რომ ვიდეო კონფერენციის სერვერებმა იმუშაონ WebRTC-თან, საკმარისია მხოლოდ ერთის მხარდაჭერა.

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

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

Google და Mozilla აქტიურად უწევენ VP8 კოდეკს, ხოლო Microsoft, Apple და Cisco H.264-ს (ტრადიციულ ვიდეოკონფერენციის სისტემებთან თავსებადობის უზრუნველსაყოფად). და აქ ჩნდება ძალიან დიდი პრობლემა მუქი WebRTC გადაწყვეტის დეველოპერებისთვის და თუ კონფერენციაში ყველა მონაწილე იყენებს ერთ ბრაუზერს, მაშინ კონფერენცია უნდა იყოს შერეული ერთხელ ერთ კოდეკთან და თუ ბრაუზერები განსხვავებულია მათ შორის, Safari / Edge, მაშინ კონფერენცია ხდება ორჯერ სხვადასხვა კოდეკებში, რომლებიც ორჯერ უნდა გადავიდეს სისტემის სარგებელიმედია სერვერზე და შედეგად, WebRTC სერვისზე გამოწერების რაოდენობა.

WebRTC API

WebRTC ტექნოლოგია დაფუძნებულია სამ მთავარ API-ზე:

• (მიუთითებს, რომ ვებ ბრაუზერი იღებს აუდიო და ვიდეო სიგნალებს კამერებიდან ან ოპერატორის დესკტოპიდან).
• RTCPeerConnection(მიუთითებს კავშირს ბრაუზერებს შორის კამერის, მიკროფონისა და დესკტოპის მონაცემების, მედია მონაცემების „გაცვლის“ მიზნით. ასევე, ამ API-ს „ვალდებულებები“ მოიცავს სიგნალის დამუშავებას (მესამე მხარის ხმაურის გასუფთავება, მიკროფონის და აუდიო კონტროლის რეგულირება და ვიდეო კოდეკები, რომლებიც ექვემდებარება ვიკორის კვლევას).
• RTCData არხი(უზრუნველჰყოფს მონაცემთა ორმხრივ გადაცემას დაინსტალირებული კავშირის მეშვეობით).

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

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

• ინიციატორი მონაწილე უგზავნის სხვა მონაწილეს Offer-SDP (მონაცემთა სტრუქტურა, გადაცემული მედია ნაკადის მახასიათებლებით);
• სხვა მონაწილე აყალიბებს „დადასტურებას“ - პასუხი-SDP და გადასცემს მას ინიციატორს;
• შემდეგ მონაწილეებს შორის ეწყობა ICE კანდიდატების გაცვლა, თუ ისინი გამოვლინდებიან (თუ მონაწილეები იმყოფებიან NAT ან სასაზღვრო ეკრანების მიღმა).

მონაწილეებს შორის გაცვლის წარმატებით დასრულების შემდეგ, ორგანიზებულია მედია ნაკადების (აუდიო და ვიდეო) დაუყოვნებელი გადაცემა.

RTCData არხი. მონაცემთა არხის პროტოკოლის მხარდაჭერა ახლახან გამოჩნდა ბრაუზერებში, ამიტომ ამ API-ის ნახვა შესაძლებელია ბრაუზერებში WebRTC ვიკიში. Mozilla Firefox 22+ და Google Chrome 26+. დამატებითი დახმარებისთვის მონაწილეებს შეუძლიათ ტექსტური შეტყობინებების გაცვლა ბრაუზერში.

კავშირები WebRTC-ის საშუალებით

მხარდაჭერილი დესკტოპის ბრაუზერები

• Google Chrome (17+) და ყველა ბრაუზერი, რომელიც დაფუძნებულია Chromium ძრავზე;
• Mozilla FireFox (18+);
• ოპერა (12+);
• Safari (11+);

მხარდაჭერილი მობილური ბრაუზერები Android-ისთვის

• Google Chrome (28+);
• Mozilla Firefox (24+);
• Opera Mobile (12+);
• Safari (11+).

WebRTC, Microsoft და Internet Explorer

უკვე დიდი ხანია, Microsoft ზოგავს ფულს WebRTC მხარდაჭერის დისკზე. Internet Explorerდა თქვენს ახალ Edge ბრაუზერში. რედმონდის ბიჭებს აღარ უყვართ ტექნოლოგიების კორპორატიული მფლობელების ხელში ჩაგდება, რადგან ვერ აკონტროლებენ მას, ამ პოლიტიკის ღერძს. ალე ეტაპობრივად მარჯვნივ განადგურდა მკვდარი ცენტრიდან, რადგან. WebRTC-ის იგნორირება აღარ არის შესაძლებელი და გამოცხადდა ORTC პროექტი, WebRTC სტანდარტის მსგავსი.

ORTC დისტრიბუტორების სიტყვებით, ეს არის WebRTC სტანდარტის გაფართოება API-ების შემცირებული ნაკრებით. JavaScript-ის საფუძვლებიხოლო HTML5, რომელიც ინგლისურად ითარგმნება, ნიშნავს, რომ ყველაფერი იგივე იქნება, მხოლოდ Microsoft და არა Google გააკონტროლებს სტანდარტს და მის განვითარებას. კოდეკების ნაკრები გაფართოვდა H.264-ის და G.7XX სერიის სხვადასხვა აუდიო კოდეკების მხარდასაჭერად, რომლებიც გამოიყენება სატელეფონო და აპარატურულ ვიდეოკონფერენციის სისტემებში. შესაძლებელია RDP მხარდაჭერის უზრუნველყოფა (კონტენტის გადაცემისთვის) და შეტყობინებების გაცვლა. სანამ საუბარს იტყოდა, Internet Explorer არ იყო გულახდილი კორისტუვაჩების მიმართ, ORTC მხარდაჭერას ჩამოერთმევა Edge. ბუნებრივია, პროტოკოლებისა და კოდეკების ასეთ კომპლექტს მცირე კავშირი აქვს Skype for Business-თან, რაც კიდევ უფრო მეტ ბიზნეს სტაგნაციას ქმნის WebRTC-სთვის.

WebRTC საშუალებას გაძლევთ განახორციელოთ რეალურ დროში აუდიო/ვიდეო კომუნიკაციები ბრაუზერის საშუალებით

ამ თემაში გამოვიყენებ უმარტივესი WebRTC დანამატის დანერგვას.

1. getUserMedia - მედია მოწყობილობებზე წვდომის მოპოვება (მიკროფონი/ვებკამერა)

არაფერი რთული, ჯავასკრიპტის კოდის 10 რიგის დახმარებით შეგიძლიათ ამის გაკეთება თითქმის თქვენს ბრაუზერში (დემო).

შექმენით index.html :

შეგიძლიათ დაამატოთ css3 ფილტრი ვიდეო ელემენტს.

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

კარგად, ჩვენ არ გეტყვით, მიეცით თუ არა წვდომა კამერაზე ერთ ბრაუზერში, მეორეში, როცა ცდილობთ წვდომის უარყოფას, ამბობს PERMISSION_DENIED.

2. სასიგნალო სერვერი

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

სასიგნალო სერვერი არის WebRTC-ის საკოორდინაციო ცენტრი, რომელიც უზრუნველყოფს კლიენტებს შორის კომუნიკაციას, კავშირების ინიციალიზაციას და დახურვას და შეტყობინებებს ცემის შესახებ.

ჩვენი სასიგნალო სერვერი არის Node.js+socket.io+node-static და მოუსმენს პორტს 1234.
გარდა ამისა, თქვენ შეგიძლიათ დაამატოთ index.html ყველაფერს კვანძის სტატიკური, რაც რაც შეიძლება მარტივს გახდის ჩვენი დანამატის შექმნას.

მამის პროგრამები უნდა იყოს დაინსტალირებული:

Npm install socket.io npm install node-static

WebRTC(Web Real-Time Communications) არის ტექნოლოგია, რომელიც საშუალებას აძლევს ვებ დანამატებს და საიტებს შეუფერხებლად გადასცენ აუდიო და/ან ვიდეო მედია ნაკადები, ასევე გაცვალონ დამატებითი მონაცემები ბრაუზერებს შორის, შუამავლების უსიამოვნების გარეშე. სტანდარტების ნაკრები, მათ შორის WebRTC ტექნოლოგია, გაძლევთ საშუალებას გაცვალოთ მონაცემები და ჩაატაროთ თანატოლებთან ტელეკონფერენციები დანამატების ან სხვა მესამე მხარის პროგრამული უზრუნველყოფის დაყენების საჭიროების გარეშე.

WebRTC შედგება მრავალი ურთიერთდამოკიდებული აპლიკაციის პროგრამის ინტერფეისებისგან (API) და პროტოკოლებისგან, რომლებიც ერთდროულად მოქმედებენ. თქვენ მიერ მოძიებული დოკუმენტაცია დაგეხმარებათ გაიგოთ WebRTC-ის საფუძვლები, როგორ დააყენოთ და დააკონფიგურიროთ კავშირები მონაცემთა გადაცემისთვის, მედიის სტრიმინგისთვის და მრავალი სხვა.

სიგიჟე

ვინაიდან WebRTC-ის დანერგვა განვითარების პროცესშია და თქვენს ბრაუზერს აქვს WebRTC ფუნქციონირება, რეკომენდირებულია გამოიყენოთ Adapter.js პოლიფაილის ბიბლიოთეკა Google-ისგან, სანამ კოდზე მუშაობას დაიწყებთ.

Adapter.js გთავაზობთ მრავალფეროვან სოლებსა და პოლიფილებს WebRTC-ის იმპლემენტაციაში ფუნქციების გლუვი ინტეგრაციისთვის კონტექსტებს შორის, რომლებიც მხარს უჭერენ მას. Adapter.js ასევე ამატებს გენერატორის პრეფიქსებს და სხვა დასახელების უფლებამოსილებებს, რაც ამარტივებს განვითარების პროცესს WebRTC-ზე, უდიდესი შედეგებით. ბიბლიოთეკა ასევე ხელმისაწვდომია NPM პაკეტის სახით.

Adapter.js ბიბლიოთეკის შემდგომი განვითარებისთვის, ჩვენ გაოცებული ვართ.

მე მესმის WebRTC ვიკი

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

ორ კვანძს შორის კავშირი წარმოდგენილია როგორც ობიექტი RTCPeerConnection ინტერფეისისთვის. სანამ კავშირი ღიად არის დაინსტალირებული, RTCPeerConnection vikory ობიექტი, MediaStream s და/ან მონაცემთა არხები (RTCDataChannel s) შეიძლება დაემატოს კავშირს.

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

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

საჭიროა დამატებითი დეტალები და ბმულები შესაბამის სახელმძღვანელოებსა და გაკვეთილებზე

WebRTC ინტერფეისები

მათ მეშვეობით, რომლებიც WebRTC უზრუნველყოფს ინტერფეისებს, რომლებიც შეუფერხებლად მუშაობენ სხვადასხვა ამოცანების შესასრულებლად, ჩვენ დავყავით ისინი კატეგორიებად. შეხედეთ ნავიგაციის ზოლის ანბანურ ინდიკატორს.

რეგულირება კავშირი და keruvannya

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

RTCPeerConnection წარმოადგენს WebRTC კავშირს შორის ლოკალური კომპიუტერი და შორეულ კვანძში. Vikoryst გამოიყენება ორ კვანძს შორის წარმატებული გადაცემის დასამუშავებლად. RTCSessionDescription განსაზღვრავს სესიის პარამეტრებს. RTCSessionDescription კოდი შეიცავს იმ ტიპის აღწერას, რომელიც აჩვენებს მოლაპარაკების პროცესის თითოეულ ნაწილს (წინადადებას/საუბარს) და აღწერს სესიის SDP დესკრიპტორს. RTCIceCandidate არის ინტერნეტ კავშირის ინსტალაციის (ICE) სერვერის კანდიდატი RTCPeerConnection კავშირის დასაყენებლად. RTCIceTransport გთავაზობთ ინფორმაციას თქვენი ინტერნეტ კავშირის შესახებ (ICE). RTCPeerConnectionIceEvent წარმოადგენს მოვლენებს, რომლებიც არჩეულია ICE კანდიდატებისთვის, სახელწოდებით RTCPeerConnection. ამ pod ობიექტს გადაეცემა ერთი ტიპი: icecandidate . RTCRtpSender ამუშავებს მონაცემთა კონვერტაციას და გადაცემას MediaStreamTrack ტიპის ობიექტის მეშვეობით RTCPeerConnection ტიპის ობიექტისთვის. RTCRtpReceiver იღებს და დეკოდირებს მონაცემებს MediaStreamTrack ტიპის ობიექტის მეშვეობით RTCPeerConnection ტიპის ობიექტისთვის. RTCTrackEvent მიუთითებს, რომ შეიქმნა MediaStreamTrack ტიპის ახალი შეყვანის ობიექტი და RTCRtpReceiver ტიპის ობიექტი დაემატება RTCPeerConnection ობიექტს. RTCCertificate წარმოადგენს სერთიფიკატს, რომელიც წარმოადგენს RTCPeerConnection ობიექტს. RTCDataChannel წარმოადგენს ორმხრივ მონაცემთა არხს ორ საკომუნიკაციო კვანძს შორის. RTCDataChannelEvent წარმოადგენს მოვლენებს, რომლებიც ხდება, როდესაც RTCDataChannel ტიპის ობიექტი მიმაგრებულია RTCPeerConnection მონაცემთა არხის ტიპის ობიექტზე. RTCDTMFSender დაშიფვრავს და გადასცემს ორმაგი ტონიანი მრავალ სიხშირის (DTMF) სიგნალს RTCPeerConnection ტიპის ობიექტისთვის. RTCDTMFToneChangeEvent მიუთითებს ორმაგი ბგერის მრავალ სიხშირის (DTMF) ტონის შეცვლის შეყვანა. ეს პროდუქტი არ იშლება (როგორც სხვაგვარად არ არის მითითებული) და არ ეხება (როგორც სხვაგვარად არ არის მითითებული). RTCStatsReport ასინქრონულად აცნობებს გადაცემული ობიექტის სტატუსს MediaStreamTrack-ის ტიპზე. RTCIdentityProviderRegistrar არეგისტრირებს პირადობის პროვაიდერს (idP). RTCIdentityProvider რთავს ბრაუზერის შესაძლებლობას მოითხოვოს იდენტიფიცირებული პირადობის შექმნა ან გადამოწმება. RTCIdentityAssertion განსაზღვრავს დისტანციური ნაკადის კვანძის იდენტიფიკატორს. თუ უნივერსიტეტი ჯერ არ არის დაინსტალირებული და დადასტურებული, ინტერფეისში გაგზავნილი შეტყობინება გახდება null. ინსტალაციის შემდეგ, მისი შეცვლა შეუძლებელია. RTCIdentityEvent წარმოადგენს პირადობის პროვაიდერის (idP) იდენტიფიკატორის ობიექტს. ობიექტის ტიპის RTCPeerConnection მსგავსია. ერთი ტიპი გადაეცემა ამ ქვეიდენტობის შედეგს. RTCIdentityErrorEvent წარმოადგენს შეცდომის მოვლენას, რომელიც დაკავშირებულია პირადობის პროვაიდერთან (idP). ობიექტის ტიპის RTCPeerConnection მსგავსია. ამ მეთოდით ორი ტიპის შეცდომის გადაცემა ხდება: idpassertionerror და idpvalidationerror.

კერივნიცტვა

WebRTC არქიტექტურის მიმოხილვა API, რომელსაც დეველოპერები გამოიყენებენ WebRTC-ის შესაქმნელად და გასავითარებლად, ქსელის პროტოკოლებისა და კავშირის სტანდარტების კომპლექტის შესაქმნელად. ეს სახე ამ სტანდარტების ჩვენებაა. WebRTC საშუალებას გაძლევთ მოაწყოთ კავშირი მასპინძელ-მასპინძელ რეჟიმში, ბრაუზერში დამატებითი მონაცემების, აუდიო, ვიდეო ნაკადების ან მათი ნებისმიერი კომბინაციის გადასაცემად. ამ სტატიაში ჩვენ გადავხედავთ WebRTC სესიის ცხოვრებას, დაწყებული კავშირის დამყარებით და გავივლით მთელ პროცესს მის დასრულებამდე, როდესაც ის აღარ არის საჭირო. WebRTC API-ს მიმოხილვა WebRTC შედგება მრავალი ურთიერთდამოკიდებული აპლიკაციის პროგრამის ინტერფეისებისგან (API) და პროტოკოლებისგან, რომლებიც ერთად მუშაობენ მონაცემთა და მედია ნაკადების გაცვლის მხარდასაჭერად ორ ან მეტ კვანძს შორის. ეს სტატია წარმოგიდგენთ მოკლე სახეკანის API და yaku meta vin ხელახლა განიხილება. WebRTC საფუძვლები ეს სტატია გაგაცნობთ ბრაუზერული RTC პროგრამების შექმნას. ამ სტატიის ბოლომდე სამუშაო თარიღი არის მედია არხი, რომელიც მუშაობს წერტილიდან წერტილამდე რეჟიმში. WebRTC პროტოკოლები ამ სტატიაში შეიქმნა პროტოკოლები, რომელთა გარდა შეიქმნა WebRTC API. ეს სახელმძღვანელო აღწერს, თუ როგორ შეგიძლიათ ვიკორისტით ერთობლივი ვუზოლ-ვუზოლი და ქსოვა

მასალის უმეტესი ნაწილი WebRTCკოდის წერა შემოიფარგლება გამოყენებული დონით და არ შეესაბამება თანამედროვე ტექნოლოგიას. შევეცადოთ ღრმად ჩავუღრმავდეთ და გავარკვიოთ, როგორ მივიღოთ დადასტურება, რა არის სესიის აღმწერი და კანდიდატები, რაც გჭირდებათ STUNі ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერი.

WebRTC

შედი

WebRTC არის ბრაუზერზე ორიენტირებული ტექნოლოგია, რომელიც საშუალებას გაძლევთ დააკავშიროთ ორი კლიენტი ვიდეო მონაცემთა გადაცემისთვის. ძირითადი მახასიათებლებია ბრაუზერების შიდა მხარდაჭერა (არ არის საჭირო მესამე მხარის ტექნოლოგიები, რომელი ტიპის Adobe Flash ) კლიენტების დაკავშირების შესაძლებლობა დამატებითი მონაცემთა სერვერების საჭიროების გარეშე – კავშირი თანატოლები(დალი, p2p).

დააინსტალირეთ კავშირი p2p- მნიშვნელოვანი ამოცანის დასასრულებლად, კომპიუტერული ფრაგმენტები არასოდეს აღმოჩნდება საზოგადოებაში IPმისამართები, ან მისამართები ინტერნეტში. ხანმოკლე პერიოდის შემდეგ IPv4მისამართი (და უსაფრთხოების მიზნით) bu გაყოფის მექანიზმი NAT, რომელიც საშუალებას გაძლევთ შექმნათ პირადი საზღვრები, მაგალითად, სახლის ვიკისთვის. ახლა უამრავი სახლის მარშრუტიზატორია მხარდაჭერისთვის NATდა ამიტომ, სახლის ყველა მოწყობილობას შეუძლია ინტერნეტთან წვდომა, თუმცა ინტერნეტ პროვაიდერები დაჟინებით მოითხოვენ მის უზრუნველყოფას IPმისამართი. საჯარო IPმისამართები უნიკალურია ინტერნეტში, მაგრამ არა პირადი. Მოდი ერთად ვიყოთ p2p- Ძნელია.

ამის უფრო ნათლად გასაგებად, მოდით შევხედოთ სამ სიტუაციას: კვანძების უკმაყოფილება იმავე განზომილებაში ყოფნისას. (მალიუნოკი 1), დამრღვევი კვანძები განლაგებულია სხვადასხვა ფენებში (ერთი კერძოსთვის, მეორე საჯაროსთვის) (მალიუნოკი 2)რომ უკმაყოფილება ვუზლეი ცნობილია სხვადასხვა კერძო ზომებში თუმცა IPმისამართები (მალიუნოკი 3).

მალიუნოკი 1: შეურაცხყოფა ერთი ზომით

მალიუნოკი 2: ვუზლი სხვადასხვა დონეზე (ერთი კერძოზე, მეორე საჯაროზე)

სურათი 3: ვუზლი სხვადასხვა კერძო საზღვრებზე, მაგრამ რიცხობრივად თანაბარი მისამართებით

ფიგურებში, ორსიმბოლოიანი აღნიშვნის პირველი ასო მიუთითებს კვანძის ტიპზე (p = თანატოლი, r = როუტერი). ერთი შეხედვით, სიტუაცია ხელსაყრელია: მათ კიდეზე არსებული კვანძები, როგორც წესი, იდენტიფიცირებულია, როგორც კიდეები. IPმისამართები და, ამრიგად, შეიძლება ერთმანეთთან დაკავშირება ყოველგვარი შუალედურის გარეშე. მეორე პატარაზე არის ორი განსხვავებული ხაზი, რომელიც მიუთითებს კვანძების მსგავს ნუმერაციაზე. აქ არის მარშრუტიზატორები, რომლებსაც აქვთ ორი კიდეის ინტერფეისი - ერთი მისი კიდის შუაში და ერთი კიდეზე. ამიტომაც ჰყავთ ორი IPმისამართი. ძირითად კვანძებს აქვთ მხოლოდ ერთი ინტერფეისი, რომლის მეშვეობითაც მათ შეუძლიათ დაგროვება მათ ზღვარზე. თუ ისინი ვინმეს თავისებურად გადასცემენ ხარკს, მაშინ ითხოვეთ დახმარება NATროუტერის (როუტერის) შუაში და, შესაბამისად, ხილული სხვა ადამიანებისთვის IPროუტერის მისამართი – tse їх გარე IPმისამართი. ამ გზით, bіlya vuzla p1є შიდა IP = 192.168.0.200 і გარე IP = 10.50.200.5 და მისამართი იგივე დარჩება თქვენი საზღვრის ყველა სხვა კვანძისთვის. ანალოგიური ვითარებაა უნივერსიტეტშიც p2. ამიტომ, მათი კავშირები რთულია, რადგან მხოლოდ მათი შინაგანი (საკუთარი) უნდა იყოს გამარჯვებული IPმისამართი. თქვენ შეგიძლიათ სწრაფად იპოვოთ გარე მისამართები, ან მარშრუტიზატორების მისამართები, ან იმიტომ, რომ ერთსა და იმავე კერძო ქსელში ყველა კვანძს აქვს იგივე გარე მისამართი, მაგრამ ამის მიღწევა ძნელია. ეს პრობლემა იმალება დამატებითი მექანიზმის უკან NAT

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

WebRTCწარმატებით უმკლავდება ასეთ პრობლემებს Vikorist პროტოკოლის გამოყენებით ICEმართალია, დამატებითი მონაცემთა სერვერების ვიკორისტანი მნიშვნელოვანია ( STUN, ᲛᲝᲑᲠᲣᲜᲔᲑᲐ). ყველაფრის შესახებ ქვემოთ.

WebRTC-ის ორი ფაზა

პროტოკოლის საშუალებით ორი კვანძის დასაკავშირებლად WebRTC(ან უბრალოდ RTCროგორ ურთიერთობენ ეს ორი iPhoneა) კავშირის დასაყენებლად აუცილებელია წინა ნაბიჯების შესრულება. პირველი ეტაპი არის დამყარებული კავშირი. მეორე ეტაპი არის ვიდეო მონაცემების გადაცემა.

ადვილია იმის თქმა, თუ რა სურს ტექნოლოგიას WebRTCმის რობოტს აქვს ვიკორისტის პიროვნება სხვადასხვა გზითკომუნიკაციები ( TCPі UDP) და მათ შორის ბევრი ინტერკომია, ეს ტექნოლოგია არ არსებობს კავშირის მონაცემთა გადაცემის პროტოკოლი. გასაკვირი არ არის, თუ ორ ვოზლის დააკავშირებთ p2pარც ისე ადვილია. ამიტომ აუცილებელია დედებისთვის დამატებითიმონაცემთა გადაცემის მეთოდი, რომელიც არანაირად არ არის დაკავშირებული WebRTC. ეს შეიძლება იყოს სოკეტის გადაცემის პროტოკოლი HTTP, სადაც შეგიძლიათ შექმნათ პროტოკოლი SMTPან რუსული ფოსტა. ეს გადაცემის მექანიზმი კობმონაცემებს უწოდებენ სიგნალი. არ არის საჭირო ბევრი ინფორმაციის გადაცემა. ყველა მონაცემი გადაიცემა ვიზუალურად და იყოფა ორ ტიპად - სდპі ყინულის კანდიდატი. პირველი ტიპი ემყარება ლოგიკური კავშირის დამყარებას, ხოლო მეორე ფიზიკურს. ჩვენ ყველაფერს მოგვიანებით მოგახსენებთ, მაგრამ ამასობაში მნიშვნელოვანია გვახსოვდეს ეს WebRTCმოგვცეს ნებისმიერი ინფორმაცია, რომელიც საჭირო იქნება სხვა კვანძზე გადაცემაში. როგორ გითხრათ ყველაფერი მოთხოვნილი ინფორმაცია, უნივერსიტეტებს შეუძლიათ გაერთიანება და ჩვენი დახმარება აღარ არის საჭირო. ამრიგად, სასიგნალო მექანიზმი, რომელიც ჩვენ შეგვიძლია განვახორციელოთ ოკრემო, vikoristovvatimetsya მხოლოდ მაშინ, როდესაც დაკავშირებულიადა ვიდეო მონაცემების გადაცემისას ბოროტად გამოყენება არ იქნება.

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

• ინიციატორი (ტელეფონი - გამრეკელი):
  1. ვიდეო მონაცემთა გადაცემის დაბეჭდვის შეთავაზება (შეთავაზების შექმნა)
  2. მიიღეთ თქვენი სდპ სდპ)
  3. ამოიღეთ საკუთარი ყინულის კანდიდატი ყინულის კანდიდატი)
• თვალისმომჭრელი ჟინგლი ( კალეე):
  1. ადგილობრივი (საკუთარი) მედია ნაკადის მოძიება და მისი გადაცემის ინსტალაცია (getUserMediaStream)
  2. წინადადებების ამოღება ვიდეო მონაცემთა გადაცემის ბეჭდვისგან და ვიდეოს შექმნა (createAnswer)
  3. მიიღეთ თქვენი სდპობიექტი და გადაცემა სასიგნალო მექანიზმით ( სდპ)
  4. ამოიღეთ საკუთარი ყინულის კანდიდატიობიექტები და მათი გადაცემა სასიგნალო მექანიზმით ( ყინულის კანდიდატი)
  5. დისტანციური (უცხო) მედიის ნაკადის მოძიება და ეკრანზე ჩვენება (AddStream)

სხვა ნივთს ნაკლები ავტორიტეტი აქვს.

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

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

ძირითადი ასპექტები

მედია ნაკადები (MediaStream)

მთავარი არსი არის მედია ნაკადი, როგორიცაა ვიდეო და აუდიო მონაცემების ნაკადი, სურათი და ხმა. არსებობს ორი სახის მედია ნაკადები - ადგილობრივი და დისტანციური. ადგილობრივი იღებს მონაცემებს შეყვანის მოწყობილობებიდან (კამერა, მიკროფონი) და დისტანციური მოწყობილობებიდან საზღვრის გავლით. ამრიგად, კანის კვანძს აქვს როგორც ადგილობრივი, ასევე შორეული ნაკადი. უ WebRTCნაკადებისთვის არის ძირითადი ინტერფეისი MediaStreamდა ასევე მთავარი ინტერფეისი LocalMediaStreamგანსაკუთრებით ადგილობრივი ნაკადისთვის. უ JavaScriptშეგიძლიათ მხოლოდ პირველს მიჰყვეთ, მაგრამ ასევე შეგიძლიათ ვიკორისტი ლიბჯინგი, შეგიძლიათ სხვებთან დაკავშირება.

უ WebRTCროგორც ჩანს, შუა ნაკადის იერარქია მთლიანად დაბნეულია. კანის ნაკადი შეიძლება ჩამოყალიბდეს რამდენიმე მედია ტრეკიდან ( MediaTrack), რომელიც შეიძლება გაერთიანდეს მრავალ მედია არხთან ( მედია არხი). თავად იგივე მედია ნაკადები შეიძლება იყოს მსგავსი.

მოდით შევხედოთ ყველაფერს თანმიმდევრობით. ვისთვის გავიხსენოთ აქტიური კონდახი. მისაღებია, რომ გვსურს გადავიტანოთ არა მარტო ვიდეო ჩვენთვის, არამედ ვიდეო ჩვენს მაგიდაზე, რომელზეც დევს ქაღალდი, რომელზეც ვაპირებთ წერას. ჩვენ გვჭირდება ორი ვიდეო (mi + stil) და ერთი აუდიო (mi). გასაგებია, რომ ჩვენ და ცხრილი უნდა დავყოთ სხვადასხვა ნაკადად, რათა ეს მონაცემები ერთ მხარეს იყოს. ასე რომ, ჩვენში ორი იქნება MediaStream"ა - ერთი ჩვენთვის და ერთი სუფრისთვის. პირველი შეიცავს როგორც ვიდეო, ასევე აუდიო მონაცემებს, ხოლო მეორე შეიცავს ვიდეოს (Malyunok 4).

მალიუნოკი 4: ორი განსხვავებული მედია ნაკადი. ერთი ჩვენთვის, ერთი ჩვენი სუფრისთვის

ცხადია, რომ მედიის ნაკადი, მინიმუმ, მოიცავს მონაცემთა არასწორი წარმოდგენის შესაძლებლობას განსხვავებული ტიპები- ვიდეო და აუდიო. ეს გარანტირებულია ტექნოლოგიაში და მონაცემთა ტიპი ხორციელდება მედია ტრეკის საშუალებით MediaTrack. მედია ტრეკებს განსაკუთრებული ძალა აქვს კეთილი, რაც ნიშნავს, რომ ის, რაც ჩვენ წინ გვაქვს არის ვიდეო ან აუდიო (Malyunok 5)

მალიუნოკი 5: მედია ნაკადები შედგება მედია ტრეკებისგან

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

როგორ შეგვიძლია აღვნიშნოთ მედია ნაკადები კავშირის მეორე ბოლოში? ვისთვის აქვს ძალა მედიის ნაკადს? ეტიკეტი- მონიშნეთ ნაკადი, მისი სახელი (Malyunok 6). იგივე ძალა და მედიის ბილიკები ჩნდება. მინდა ვიფიქრო, რომ ვიდეოს და ხმის დაკვრა სხვანაირადაც შეიძლება.

Malyunok 6: მედია ნაკადები და ტრეკები იდენტიფიცირებულია ტეგებით

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

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

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

უმჯობესია ვიფიქროთ სტერეო ხმაზე. როგორც ხედავთ, სტერეო ხმა არის ორი განსხვავებული ხმა. ასევე აუცილებელია მათი მკაცრად გადმოცემა. ვისთვის ხდება არხების გაძლიერება? მედია არხი. ხმის მედიის ჩაწერა შესაძლებელია ბევრ არხზე (მაგალითად, 6, თუ საჭიროა 5+1 ხმა). მედია ტრეკის შუაში არის არხები, განსაკუთრებით სინქრონიზებული. ვიდეოებისთვის საჭიროა მხოლოდ ერთი არხი, მაგრამ შეგიძლიათ გამოიყენოთ ის მაგალითად, რეკლამისთვისაც.

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

უმარტივესი ვიდეო ჩატის სიტუაციაში, არსებითად, არსებობს ერთი ადგილობრივი მედია ნაკადი, რომელიც შედგება ორი ტრეკისაგან - ვიდეო ტრეკი და აუდიო ტრეკი, რომელიც შედგება ერთი მთავარი არხისგან. ვიდეო ტრეკი წარმოადგენს კამერას, აუდიო ჩანაწერი წარმოადგენს მიკროფონს და მედია ნაკადი წარმოადგენს იმავე კონტეინერს.

სესიის აღმწერი (SDP)

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

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

როდესაც კავშირი დაინსტალირდება, აუცილებელია მიუთითოთ ნებისმიერი მისამართი, მაგალითად URL. აქ არ არის საჭირო, რომ სიგნალის მექანიზმით გააგზავნოთ მონაცემები აღიარებისთვის. გთხოვთ მიუთითოთ WebRTC, რისი დაყენება გვინდა p2pკავშირი მოითხოვს createOffer ფუნქციის გამოძახებას. ამ ფუნქციის დაჭერისა და სპეციალურის ჩასმის შემდეგ გადმომირეკეშეიქმნება ნება სდპობიექტი და გადატანილია იმავეზე გადმომირეკე. თქვენ უბრალოდ უნდა გადაიტანოთ ობიექტი ქსელის მეშვეობით სხვა კვანძში (სპრედერში). რის შემდეგაც, მეორე ბოლოში, მონაცემების პოვნა ხდება სიგნალის მექანიზმის საშუალებით და შემდეგ სდპობიექტი სესიის ეს აღმწერი ამ უცხოური კვანძისთვის არ არის გამოსადეგი ინფორმაცია. ობიექტის წაღება არის სიგნალი კობისთვის, რომ შეუერთდეს. ასე რომ თქვენ უნდა ნახოთ ეს და დააწკაპუნოთ შექმნა პასუხი ფუნქცია. Vona არის CreOffer-ის ახალი ანალოგი. მე შენსას ვურეკავ გადმომირეკეგაიარეთ ლოკალური სესიის აღმწერი და ეს დაგჭირდებათ სიგნალიზაციის მექანიზმის მეშვეობით.

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

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

ამის შემდეგ ხელნაკეთივუზლიმ იცის ერთის გატაცების შესახებ. მაგალითად, yakscho vuzol 1 მხარს უჭერს კოდეკებს აі ბ, და ვუზოლი 2 მხარს უჭერს კოდეკებს ბі Cმაშ, უნივერსიტეტის კანმა იცის საკუთარი და სხვისი აღწერები, მასპინძელს ეწყინება კოდეკის არჩევა. ბ(მალიუნოკი 7). კავშირის ლოგიკა ახლა დაინსტალირებულია და მედიის ნაკადების გადაცემა შესაძლებელია, მაგრამ არის კიდევ ერთი პრობლემა - კვანძები, როგორც ადრე, დაკავშირებულია მხოლოდ სასიგნალო მექანიზმით.

Malyunok 7: გამოსაყენებელი კოდეკები

ყინულის კანდიდატი

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

თუმცა, კავშირი უკვე დაინსტალირებულია (ლოგიკური კავშირი), მაგრამ ჯერ კიდევ არ არის გზა, რომლითაც კვანძებს შეუძლიათ მონაცემთა გადაცემა. ეს ყველაფერი არც ისე მარტივია, მაგრამ მოდით გავამარტივოთ. ეშხები იყვნენ იმავე პირად სივრცეში. როგორც უკვე ვიცით, სუნი ადვილად აკავშირებს ერთმანეთს შინაგანი გამო IPმისამართი (ან შეიძლება, რატომღაც, იმიტომ, რომ თქვენ არ ხართ გამარჯვებული TCP/IP).

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

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

რატომ არის მხოლოდ ერთი აღმწერი სესიისთვის, მაგრამ შეიძლება იყოს ბევრი კანდიდატი? რადგან მინდვრებში გადაფორმების პროცესი ჩანს არა მხოლოდ მისი შინაგანი ბუნების გამო. IPმისამართი, ასევე როუტერის გარე მისამართი და არა მხოლოდ ერთი, არამედ მისამართებიც ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერები. აბზაცის დანარჩენი ნაწილი დაეთმობა კანდიდატების ანგარიშის მიმოხილვას და როგორ დააკავშიროთ უნივერსიტეტები სხვადასხვა კერძო ქსელებიდან.

ისე, ორი ვუზლი მდებარეობს ერთ საზღვარზე (მალიუნოკი 8). როგორ ამოვიცნოთ ისინი? შემდგომი დახმარებისთვის IPმისამართი. Მეტი აღარ. მართალია, ჯერ კიდევ შესაძლებელია სხვადასხვა ტიპის ტრანსპორტის ვიკორიზაცია ( TCPі UDP) და დაკვლა. ეს არის ინფორმაცია, რომელიც შედის კანდიდატის პროექტში - IP, პორტი, ტრანსპორტიდა როგორც ინშა. მაგალითად, ნუ დააყოვნებთ ვიკორისტი გახდეთ UDPტრანსპორტი და 531 პორტი.

მალიუნოკი 8: ორი კვანძი განლაგებულია ერთ საზღვარზე

თოდი, რადგან ჩვენ ვესტუმრებით უნივერსიტეტს p1, ეს WebRTCმოგვცეს ასეთი კანდიდატის ობიექტი - . ეს არ არის ზუსტი ფორმატი, რაც აქ არის საჭირო, მხოლოდ დიაგრამა. როგორ ვართ ვუზლში p2, მაშინ კანდიდატი არის - . სასიგნალო მექანიზმის მეშვეობით p1უარს ამბობს კანდიდატზე p2(შემდეგ roztashuvannya vuzla p2და თავად იოგო IPі პორტი). Რის შემდეგ p1შეგიძლიათ ერთად p2ყოველგვარი შუალედის გარეშე. უფრო სწორად, p1დეტალებს დაამატებთ მისამართს 10.50.150.3:531 იმ იმედით, რომ სურნელი წავა p2. არ აქვს მნიშვნელობა, მისამართს დადებ თუ არა ვუზლუზე p2მე ვესაუბრები შუამავალს. მნიშვნელოვანია მათთვის, ვისაც ამ მისამართით ეძლევა ძალა და შეუძლია მიაღწიოს p2.

სანამ კვანძები ერთ ხაზზეა - ყველაფერი მარტივი და მარტივია - კანის კვანძს აქვს კანდიდატის მხოლოდ ერთი ობიექტი (ყოველთვის საკუთარი საფუძველზე, რათა მისი განვითარება ერთდროულად იყოს). უფრო მეტი კანდიდატი იქნება, თუ უნივერსიტეტი იქნება სხვადასხვასაზღვრები.

მოდით გადავიდეთ რთულ ნაწილზე. ერთი განყოფილება მდებარეობს როუტერის უკან (უფრო ზუსტად, NAT-ის უკან), ხოლო მეორე განყოფილება მდებარეობს ამ როუტერთან ერთად (მაგალითად, ინტერნეტში) (Malyunok 9).

მალიუნოკი 9: ერთი სკოლა NAT-ისთვის, მეორე კი არა

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

მისაღებია, რომ ვებ სერვერი პირდაპირ დაუკავშირდეს ინტერნეტს, შემდეგ ის საჯაროა IP*მისამართი. ეს იყოს ვუზოლი p2. ვუზოლი p1(ვებ კლიენტი) გაგზავნილია მისამართზე 10.50.200.10 . მონაცემების უმეტესი ნაწილი იხარჯება როუტერზე r1უფრო სწორად იოგოზე შიდაინტერფეისი 192.168.0.1 . ამის შემდეგ, როუტერი იმახსოვრებს მოწყობილობის მისამართს (მისამართი p1) და შეიყვანეთ სპეციალურ ცხრილში NAT, შემდეგ ცვლის ელ.ფოსტის მისამართს საკუთარი ( p1 → r1). შორს, საკუთარი თავისთვის გარეროუტერის ინტერფეისი გადასცემს მონაცემებს პირდაპირ ვებ სერვერზე p2. ვებ სერვერი ამუშავებს მონაცემებს, ქმნის პასუხს და აგზავნის უკან. იგზავნება როუტერზე r1გარდა ამისა, თქვენ თვითონ უნდა დადგეთ დაბრუნების მისამართზე (როუტერმა მისამართი შეცვალა თქვენით). როუტერი აგროვებს მონაცემებს, შეხედეთ ცხრილს NATიგი აჭარბებს ხარკს ვუზლუს p1. როუტერი აქ შუამავლის როლს ასრულებს.

რატომ აფეთქდება რამდენიმე კვანძი შიდა საზღვრებიდან მოულოდნელად გარე საზღვრამდე? როგორ ესმის როუტერი, ვის შეუძლია დადასტურების დაბრუნება? ამ პრობლემას დახმარება სჭირდება პორტები. თუ როუტერი ცვლის ჰოსტის მისამართს, ის ასევე ცვლის პორტს. თუ ორი კვანძი უკავშირდება ინტერნეტს, როუტერი ცვლის მათ პორტებს ხოცვა-ჟლეტა. შემდეგ, თუ ვებ სერვერიდან პაკეტი დაუბრუნდება როუტერს, მაშინ როუტერი ცნობს პორტს, რომელსაც ეს პაკეტი გაუგზავნა. კონდახი ქვედა.

მოდით მივმართოთ ტექნოლოგიას WebRTC, უფრო სწორედ ამ ნაწილამდე, რომელიც არის ვიკორისტი ICEპროტოკოლი (zvіdsi i ყინულიკანდიდატები). ვუზოლი p2შეიძლება იყოს ერთი კანდიდატი (საკუთარი გაფართოება ფარგლებში - 10.50.200.10 ), და ვუზოლი p1, რომელიც მდებარეობს NAT-ით როუტერის უკან, არის ორი კანდიდატი - ადგილობრივი ( 192.168.0.200 ) როუტერის კანდიდატი ( 10.50.200.5 ). პირველი არ იქნება მომავალში, მაგრამ არანაკლებ, გენერირებული, ფრაგმენტები იქნება WebRTCჯერ კიდევ არაფერი იცის შორეული კვანძების შესახებ - ისინი შეიძლება მდებარეობდნენ იმავე მხარეში, ან შეიძლება არა. მომავალში კიდევ ერთი კანდიდატი იქნება და, როგორც უკვე ვიცით, პორტის მნიშვნელოვანი როლი (გაივლის NAT).

მაგიდის შესვლა NATიქმნება როგორც კი მონაცემები შიდა ქსელიდან გამოდის. ტომ ვუზოლი p1დამნაშავეა მონაცემთა პირველ გადაცემაში და ამ უკანასკნელის მონაცემების უნივერსიტეტისთვის p2შეუძლია კვანძში მოხვედრა p1.

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

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

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

STUN და TURN სერვერები

ინიციალიზაციისას WebRTCაუცილებელია მიუთითოთ ხელმისაწვდომი STUNі ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერები, რომლებიც ჩვენ მივეცით, ეწოდება ICEსერვერები. თუ სერვერი არ არის მითითებული, მაშინ იმავე ქსელში მხოლოდ კვანძების დაკავშირება შესაძლებელია (მას გარეშე კავშირები NAT). მაშინვე გასაგებია რისთვის 3გრ-მერეჟ ობოვიაზკოვე ვიკორისტანნია ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერები.

STUN სერვერი– ეს არის უბრალოდ სერვერი ინტერნეტში, რომელიც აბრუნებს დაბრუნების მისამართს გამგზავნის ჰოსტის მისამართს. ვუზოლი, რომელიც როუტერის უკან დგას, აფეთქდება STUNსერვერის გასავლელად NAT. პაკეტი, რა მოგდის STUNსერვერზე, ისე რომ jerel-ის მისამართი მდებარეობს - როუტერის მისამართი, შემდეგ ჩვენი კვანძის გარე მისამართი. Qia მიმართავს STUNსერვერი აგზავნის უკან. ამ გზით უნივერსიტეტი ართმევს მის გარეგანს IPმისამართი და პორტი ნებისმიერი ქსელის საშუალებით, რომელიც ხელმისაწვდომია. დალი, WebRTCამ დამატებითი მისამართისთვის ჩვენ ვქმნით დამატებით კანდიდატს (გარე როუტერის მისამართი და პორტი). ახლა მაგიდასთან NATროუტერი არის ჩანაწერი, რომელიც გადასცემს როუტერზე გაგზავნილ პაკეტებს საჭირო პორტის მეშვეობით ჩვენს კვანძში.

მოდით შევხედოთ ამ პროცესს კონდახიდან.

კონდახი (STUN სერვერის რობოტი)

STUNსერვერი დაინიშნება მეშვეობით s1. როუტერი, როგორც ადრე, გადის r1, და ვუზოლი – მეშვეობით p1. ასევე საჭირო იქნება ცხრილის დაცვა NAT– її მნიშვნელოვანია როგორც r1_nat. უფრო მეტიც, ეს ცხრილი უნდა შეიცავდეს უამრავ ჩანაწერს წყალქვეშა კვანძებიდან - არ შეიქმნება სუნი.

კარგი, ახლა ცარიელი მაგიდა მაქვს r1_nat.

ცხრილი 2: პაკეტის სათაური

ვუზოლი p1აგზავნის ამ პაკეტს როუტერზე r1(არ აქვს მნიშვნელობა რა წოდება, სხვადასხვა ქვედანაყოფს შეიძლება ჰქონდეს ვიკორსტანები სხვადასხვა ტექნოლოგიები). როუტერს სჭირდება მოწყობილობის მისამართის შეცვლა Src IP, ვინაიდან პაკეტში შეტანილი მისამართები აშკარად არ არის შესაფერისი გარე ქვედანაყოფებისთვის, უფრო მეტიც, ასეთი დიაპაზონის მისამართები დაცულია და არცერთი სხვა მისამართი ინტერნეტში არ შეიცავს ასეთ მისამართებს. როუტერი საჭიროებს ჩანაცვლებას პაკეტში და ქმნის ახალი ჩანაწერითქვენს მაგიდასთან r1_nat. ამისათვის თქვენ უნდა გამოიცნოთ პორტის ნომერი. ნათელია, რომ რამდენიმე კვანძის ფრაგმენტები საზღვრის შუაში შეიძლება გაფართოვდეს გარე საზღვრამდე, შემდეგ ცხრილში. NATაუცილებელია დამატებითი ინფორმაციის შენახვა, რათა როუტერმა განსაზღვროს, თუ რომელ კვანძზეა მინიჭებული სერვერიდან დაბრუნების პაკეტი. ნება მიეცით როუტერს გამოვიდეს პორტი 888 .

შეიცვალა პაკეტის სათაური:

ცხრილი 4: NAT ცხრილი განახლდა ახალი ჩანაწერით

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

სპრავჟნის პორტი, იაკი ვუზოლზე p1იღებს კავშირებს - ეს, გასაგებია, 35777 , მაგრამ სერვერი აიძულებს მონაცემებს ფიქტიურიპორტი 888 , რომელიც შეიცვლება როუტერის მიერ მითითებულზე 35777 .

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

Src IP	Src PORT	დანიშნულების IP	დანიშნულების პორტი
10.50.200.5	888	12.62.100.200	6000

ცხრილი 5: STUN სერვერის მიმღები პაკეტი

ერთად, STUNსერვერმა იცის, რომ საუკეთესო პაკეტი არის მისამართი 10.50.200.5:888 . ახლა სერვერი აგზავნის ამ მისამართს უკან. აქ შეგიძლიათ გაჩერდეთ და კიდევ ერთხელ გაოცდეთ იმით, რასაც ასე სიყვარულით ვუყურებდით. მაგიდები, ადგილზე - ბევრი რამ სათაურიპაკეტი, საერთოდ არა სამაგიეროდ. ისინი ჩვენს ნაცვლად არ საუბრობდნენ, რადგან ეს არც ისე მნიშვნელოვანია - ეს უნდა იყოს აღწერილი პროტოკოლში STUN. ახლა შეგვიძლია სათაურის ნაცვლად შევხედოთ. გაპატიებთ და პატივს გცემთ როუტერის მისამართს - 10.50.200.5:888 , მინდა ავიღო mi yogo z სათაურიპლასტიკური ჩანთა. ამის შიში ხშირად არ არის, რადგან პროტოკოლებს არ აინტერესებთ ინფორმაცია უნივერსიტეტების მისამართების შესახებ, მნიშვნელოვანია, რომ ამანათი მიწოდებული იყოს დანიშნულებით. აქ ჩვენ ვხედავთ პროტოკოლს, რომელიც ადგენს გზას ორ კვანძს შორის.

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

ცხრილი 7: STUN სერვერი ამით აძლიერებს პაკეტს

შემდეგ პაკეტი გაძვირდება მანამ, სანამ არ მიაღწევს როუტერის ახალ ინტერფეისს. r1. როუტერს ესმის, რომ პაკეტი მოგეცემათ. როგორ გესმით ეს? ამის გარკვევა მხოლოდ პორტით შეგიძლიათ. პორტი 888 ის არ არის ვიკორისტი საკუთარი სპეციალური მიზნებისთვის, არამედ ვიკორისტი მექანიზმისთვის NAT. ასევე, მაქვს როუტერის მაგიდა და მაინტერესებს. გაოცება სტოვპეცში გარე პორტიდა ის ეძებს რიგს, რომელიც მიდის დანიშნულების პორტიპაკეტით, scho priyshov, tobto 888 .

შიდა IP	შიდა პორტი	გარე IP	გარე პორტი
192.168.0.200	35777	10.50.200.5	888

ცხრილი 8: NAT ცხრილი

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

ცხრილი 10: როუტერი ცვლის მიმღების მისამართს

Src IP	Src PORT	დანიშნულების IP	დანიშნულების პორტი
12.62.100.200	6000	192.168.0.200	35777

ცხრილი 11: როუტერი აფუჭებს მიმღების მისამართს

პაკეტი წარმატებით მიდის კვანძში p1და, გაოცებული პაკეტით, უნივერსიტეტი გაიგებს მის ამჟამინდელ გარეგნობას IPმისამართი, ეს არის როუტერის მისამართი გარე საზღვარზე. მან ასევე იცის პორტი, რომელზედაც გადის როუტერი NAT.

Რა არის შემდეგი? რა სახის წითელა? ღირებულება - ეს არის ჩანაწერი ცხრილში r1_nat. ახლა რა გადაეგზავნება როუტერს? r1პაკეტი პორტიდან 888 , მაშინ როუტერი გადამისამართებს ამ პაკეტს კვანძში. p1. ამ გზით, დაასრულა პატარა ვიწრო გადასასვლელი ჩაკეტილი სკოლისკენ p1.

კონდახში უფრო მარტივად შეგიძლიათ უარყოთ განცხადებები სამუშაოს შესახებ NATდა არსი STUNსერვერი. მექანიზმი ამოქმედდა ICEі STUN / Turnსერვერები პირდაპირ მიმართულია ჰემლაინზე NAT.

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

ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერი - არანაირი შემცირება STUNსერვერი. დაუყოვნებლივ მიჰყევით ბილიკს, რაც არ უნდა იყოს ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერს შეუძლია ასე იმუშაოს STUNსერვერი. დაიცავით ¢ უპირატესობები. იაკშჩო p2pკომუნიკაცია შეუძლებელია (როგორც, მაგალითად, 3გრ merezh), შემდეგ სერვერი გადადის განმეორების რეჟიმში ( რელე), შემდეგ ის მოქმედებს როგორც შუამავალი. მესმის, რაც არ უნდა იყოს p2pმაშინ გზა არ არის, მაგრამ მექანიზმის ჩარჩოს მიღმა ICEვუზლიმ დაფიქრდი რა უნდა გააკეთოს შუაში.

ზოგიერთ შემთხვევაში აუცილებელია ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერი? რატომ არ ჩანს STUNსერვერები? მარჯვნივ არის ის, რომ არსებობს მრავალი სხვადასხვა სახეობა NAT. თუმცა, სუნი იცვლება IPმისამართი არის ის პორტი, დაიცავით მათგან საქმეები დამატებითი ზახისტიროგორც „ფალსიფიკაცია“. მაგალითად, in სიმეტრიულიმაგიდები NATშენახულია კიდევ 2 პარამეტრი - IPდა დისტანციური კვანძის პორტი. გარე საზღვრიდან ამანათი გადის NATშიდა ზომით, მხოლოდ ამ შემთხვევაში, ხელსაწყოს მისამართები და პორტები აცილებულია ცხრილში ჩანაწერებიდან. ეს არის აქცენტი STUNსერვერი არ აღწერს დეტალებს - ცხრილი NATინახავს მისამართს და პორტს STUNსერვერები, თუ როუტერი იღებს პაკეტს WebRTC spіvrozmovnik, რომელიც აგდებს "გაყალბების" ფრაგმენტებს. ჯერ არ მოდის STUNსერვერი.

Ამ გზით ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერი საჭიროა სპივროზმოვნიკების განაწყენების შემთხვევაში სიმეტრიული NAT(კოჟენი თავისთვის).

მოკლე ზარი

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

• მედია ნაკადი
  • ვიდეო და აუდიო მონაცემები შეფუთულია მედია ნაკადებში
  • მედია ნაკადები სინქრონიზებს მედია ტრეკებს, საიდანაც ისინი იქმნება
  • სხვადასხვა მედია ნაკადები არ არის სინქრონიზებული ერთმანეთთან
  • მედია ნაკადები შეიძლება იყოს ლოკალური ან დისტანციური, იმისდა მიხედვით, არის თუ არა კამერა ან მიკროფონი ლოკალურად დაკავშირებული, მონაცემების მოძიება შესაძლებელია მონაცემთა კოდირებული ხედით.
  • არსებობს ორი ტიპის მედია ტრეკი - ვიდეო და აუდიო
  • მედია ტრეკებს შეიძლება ჰქონდეს ბნელი/უარესი გახდეს
  • მედია ტრეკები შედგება მედია არხებისგან
  • მედია ტრეკები სინქრონიზებს მედია არხებს, საიდანაც ისინი იქმნება
  • მედია ნაკადები და მედია ტრეკები შეიცავს ეტიკეტებს, რომლებიც შეიძლება გამოყენებულ იქნას მათი განცალკევებისთვის
• სესიის აღმწერი
  • სესიის აღმწერი შეცვლილია ორი ქსელის კვანძის ლოგიკურად დასაკავშირებლად
  • სესიის აღმწერი ინახავს ინფორმაციას ამის შესახებ ხელმისაწვდომი გზებივიდეო და აუდიო მონაცემების კოდირება
  • WebRTCვიკორისტის გარე სასიგნალო მექანიზმი – წინასწარ შერჩეული სესიის აღწერები ( სდპ) ეცემა დანამატზე
  • ლოგიკური მსჯელობის მექანიზმი შედგება ორი ეტაპისგან - წინადადება ( შეთავაზება) და ტიპები ( პასუხი)
  • სესიის აღწერის გენერირება შეუძლებელია სხვადასხვა დროს ადგილობრივი მედიის ნაკადების გამოყენების გარეშე ( შეთავაზება) და შეუძლებელია თითოეული ტიპის დისტანციური სესიის აღწერის შეცვლის გარეშე ( პასუხი)
  • ამოღების აღმწერი დანერგვას მოითხოვს WebRTC, და არ აქვს მნიშვნელობა ეს აღმწერი წაშლილია თუ ლოკალურად იგივე განხორციელებიდან WebRTC
  • შესაძლებელია სესიის აღწერის ოდნავ შეცვლა
• კანდიდატები
  • კანდიდატი ( ყინულის კანდიდატი) – ეს არის საზღვრის კვანძის მისამართი
  • კვანძის მისამართები შეიძლება იყოს თქვენი საკუთარი, ან შეიძლება იყოს როუტერის მისამართი ან ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერები
  • ყოველთვის ბევრი კანდიდატია
  • კანდიდატი ყალიბდება IPმისამართი, პორტი და ტრანსპორტის ტიპი ( TCPან კიდევ UDP)
  • კანდიდატები გამარჯვებულები არიან ზღვარზე ორი კვანძის ფიზიკური კავშირის დასამყარებლად
  • კანდიდატები ასევე უნდა გაიგზავნონ სასიგნალო მექანიზმით
  • კანდიდატებიც გადადიან განხორციელებაზე WebRTC, მხოლოდ შორს მყოფთა შესახებ
  • მიმდინარე განხორციელებებში WebRTCკანდიდატების გადაცემა შესაძლებელია მხოლოდ სესიის აღწერის დაყენების შემდეგ
• STUN/TURN/ICE/NAT
  • NAT– მექანიზმი გარე საზღვარზე წვდომის უზრუნველსაყოფად
  • სახლის მარშრუტიზატორები მხარს უჭერენ სპეციალურ ცხრილს NAT
  • როუტერი ცვლის მისამართებს პაკეტებში - ჰოსტის მისამართს თავისთვის, თუ პაკეტი მოდის გარე საზღვრიდან, და მიმღების მისამართს კვანძის მისამართის შიდა საზღვარზე, როგორც ეს პაკეტი ჩამოვიდა გარე საზღვრიდან.
  • მრავალი არხის გარე საზღვრებზე წვდომის უზრუნველსაყოფად NATვიკორისტი გაფუჭება
  • ICE- შემოვლითი მექანიზმი NAT
  • STUNі ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერები – დამხმარე სერვერები გვერდის ავლით NAT
  • STUNსერვერი საშუალებას გაძლევთ შექმნათ არასაჭირო ჩანაწერები ცხრილში NATდა ასევე აბრუნებს გარე კვანძის მისამართს
  • ᲛᲝᲑᲠᲣᲜᲔᲑᲐმიმდინარეობს სერვერის რეგისტრაცია STUNმექანიზმი და ისევ იმუშაოს
  • ყველაზე ცუდ ეპიზოდებში ᲛᲝᲑᲠᲣᲜᲔᲑᲐ vikory სერვერი ითვლება შუამავლად ( რელე), შემდეგ p2pგარდაიქმნება კლიენტ-სერვერ-კლიენტის კავშირად.

გამარჯობა მეგობრებო, როგორც უკვე იცით, რეგულარულად გაგაცნობთ ახალ ტექნოლოგიებს, დღეს გაგაცნობთ Google-ის მიერ შემუშავებულ ტექნოლოგიას WebRTC, რომელიც მომხმარებლებს საშუალებას აძლევს პირდაპირ ისაუბრონ ბრაუზერზე, ვიდეო და აუდიო, დაუკარგავად, რა არის ვიკი მოდული - საიტი ან პროგრამა. ვიდეო და აუდიო კომუნიკაცია უშუალოდ კომპიუტერებს შორის ხდება უშუალოდ ბრაუზერში.
WebRTC ტექნოლოგია მხარდაჭერილია Mozilla Firefox-ში Google ბრაუზერები Chrome და ნებისმიერ ოპერაციულ სისტემაზე მოყვება Opera.
რა არის WebRTC?
WebRTC არის მოკლე Web Real Time Communication, ეს ტექნოლოგია საშუალებას გაძლევთ დამალოთ აუდიო და ვიდეო ჩეთები პირდაპირ ბრაუზერში, ინტერნეტში სხვა დანამატების, პროგრამების ან სერვისების გარეშე. კავშირები ხდება პირდაპირ თქვენი ბრაუზერიდან.
ზოგიერთი სერვისი (Skype, Yahoo Messenger, Apple FaceTime, Google Hago და ა.შ.) იყენებს სერვერებს, რომლებიც აკავშირებენ კლიენტებს ტრაფიკის დასაწყებად და სამართავად. Vikorist სერვისებისთვის ჩვენ უნდა დავრეგისტრირდეთ და დავაყენოთ კლიენტებისა და კონტაქტების სია.
WebRTC-ით ჩვენ არ გვჭირდება სერვერები, პროგრამები ან სერვერები, რომლებიც დაკავშირებულია შუამავლამდე.
WebRTC უპირატესობები:
1. არა მეტი დანამატები, რომელიც სარგებლობს რესურსებისა და ბატარეების გამოყენებით.
2. ჩეთები უფრო პირადია (კარგი).
3. როგორ დაგიკავშირდეთ თქვენ შეგიძლიათ იმუშაოთ ადგილობრივ ბაზარზე და არა Flos USA სერვერებზე ლოკალური კავშირებისთვის.
4. სიმარტივე, მოხერხებულობა და უბრალოება.
5. შემდგომი განვითარების შესაძლებლობა და სხვა მიმართულებით.
6. შეკვრა მდგრადია და არ შედის კონტაქტში გარე ნაერთებთან, რომლებიც ზოგჯერ უკიდურესად არასტაბილურია.
მე მაქვს დემო ვერსია, რომელიც გუგლის ხალხმა შეიმუშავა, დემოს დასრულება მარტივია, მეტი სიმძლავრით და მეტი კავშირებით შეგიძლიათ გამოიყენოთ ერთ-ერთი დანამატი, რომელიც მხარს უჭერს WebRTC-ს, ეს უფრო ადვილია vikoristans i. მალე ჩვენ ვიმუშავებთ სახელმძღვანელოზე WebRTC პროგრამების შესახებ.
როგორ ხედავთ WebRTC დემო ვერსიას?
უბრალოდ დააწკაპუნეთ ქვემოთ მოცემულ შეტყობინებაზე და ის ავტომატურად წარმოქმნის ჩატს. დაუკავშირდით ამ ოთახს, უნდა გამოაგზავნოთ მეგობარი/მეგობარი, რომელთანაც გსურთ დაკავშირება.
მეგობარი/შეყვარებული და შენი, მაგრამ ვიკორიზმში მხოლოდ შენ ხარ დამნაშავე დარჩენილი ვერსიები Mozilla Firefox ან Google Chrome.

დემო WebRTC(გაცნობითი ჩატი აუდიო-ვიდეო)

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