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

WebRTC

შესავალი

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

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

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

სურათი 1: ორივე კვანძი ერთსა და იმავე ქსელში

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

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

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

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

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

WebRTC-ის ორი ფაზა

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

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

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

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

განსხვავება მხოლოდ მეორე პუნქტშია.

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

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

ძირითადი პირები

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

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

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

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

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

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

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

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

მაგრამ როგორ განვასხვავოთ მედია ნაკადები კავშირის მეორე ბოლოზე? ამისათვის თითოეულ მედია ნაკადს აქვს საკუთრება ეტიკეტი– ნაკადის ეტიკეტი, მისი სახელი (სურათი 6). იგივე საკუთრება აქვს მედია ტრეკებს. მიუხედავად იმისა, რომ ერთი შეხედვით ჩანს, რომ ვიდეო შეიძლება განვასხვავოთ ხმისგან სხვა გზით.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

სურათი 7: კოდეკის მოლაპარაკება

კანდიდატები (ყინულის კანდიდატი)

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

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

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

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

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

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

სურათი 8: ორი კვანძი ერთსა და იმავე ქსელშია

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

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

გადავიდეთ უფრო რთულ საქმეზე. ერთი კვანძი იქნება როუტერის უკან (უფრო ზუსტად, NAT-ის უკან), ხოლო მეორე კვანძი იქნება იმავე ქსელში ამ როუტერთან (მაგალითად, ინტერნეტში) (სურათი 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პროტოკოლი (აქედან გამომდინარე ყინულიკანდიდატები). კვანძი p2ჰყავს ერთი კანდიდატი (მისი მდებარეობა ქსელში - 10.50.200.10 ), და კვანძი p1, რომელიც მდებარეობს NAT-ით როუტერის უკან, ეყოლება ორი კანდიდატი - ადგილობრივი ( 192.168.0.200 ) და როუტერის კანდიდატი ( 10.50.200.5 ). პირველი არ არის სასარგებლო, მაგრამ მაინც წარმოიქმნება, ვინაიდან WebRTCჯერ არაფერი იცის დისტანციური ჰოსტის შესახებ - ის შეიძლება იყოს ან არ იყოს იმავე ქსელში. მეორე კანდიდატი გამოდგება და როგორც უკვე ვიცით, პორტი მნიშვნელოვან როლს შეასრულებს (გადავლა NAT).

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

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

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

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

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

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

STUN სერვერიარის უბრალოდ სერვერი ინტერნეტში, რომელიც აბრუნებს დაბრუნების მისამართს, ანუ გამგზავნის ჰოსტის მისამართს. როუტერის უკან არსებული კვანძი წვდება STUNსერვერის გასავლელად NAT. პაკეტი რომ მოვიდა STUNსერვერი შეიცავს წყაროს მისამართს - როუტერის მისამართს, ანუ ჩვენი კვანძის გარე მისამართს. ეს მისამართი 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	DEST PORT
10.50.200.5	888	12.62.100.200	6000

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

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

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

ცხრილი 7: STUN სერვერი აგზავნის პაკეტს ამ შინაარსით

შემდეგი, პაკეტი მოგზაურობს ქსელში, სანამ არ მიაღწევს როუტერის გარე ინტერფეისს r1. როუტერს ესმის, რომ პაკეტი მისთვის არ არის განკუთვნილი. როგორ ესმის ის? ამის პოვნა მხოლოდ პორტშია შესაძლებელი. პორტი 888 ის არ იყენებს პირადი მიზნებისთვის, არამედ იყენებს მექანიზმს NAT. ამიტომ, როუტერი ხედავს ამ ცხრილს. უყურებს სვეტს გარე პორტიდა ეძებს სტრიქონს, რომელიც ემთხვევა DEST PORTშემომავალი პაკეტიდან, ანუ 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	DEST PORT
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გრქსელები), შემდეგ სერვერი გადადის განმეორების რეჟიმში ( რელე), ანუ ის მუშაობს როგორც შუამავალი. რა თქმა უნდა, ნებისმიერის შესახებ p2pმაშინ ეს არ არის საკითხი, მაგრამ მექანიზმის ჩარჩოს მიღმა ICEკვანძები ფიქრობენ, რომ ისინი უშუალოდ ურთიერთობენ.

რა შემთხვევებშია საჭირო ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერი? რატომ არ არის საკმარისი STUNსერვერები? ფაქტია, რომ არსებობს რამდენიმე სახეობა NAT. ისინი იგივეს ცვლიან IPმისამართი და პორტი, მაგრამ ზოგიერთ მათგანს აქვს ჩაშენებული დამატებითი დაცვა "გაყალბებისგან". მაგალითად, in სიმეტრიულიმაგიდა NATშენახულია კიდევ 2 პარამეტრი - IPდა დისტანციური მასპინძლის პორტი. გარე ქსელიდან გადის პაკეტი NATშიდა ქსელში მხოლოდ იმ შემთხვევაში, თუ წყაროს მისამართი და პორტი ემთხვევა ცხრილში ჩაწერილს. ამიტომ, აქცენტი STUNსერვერი ვერ ხერხდება - ცხრილი NATმაღაზიის მისამართი და პორტი STUNსერვერზე და როცა როუტერი იღებს პაკეტს WebRTCთანამოსაუბრეს, ის ტოვებს მას, რადგან ის არის "გაყალბებული". ის არ მოვიდა 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მექანიზმი და ხდის მას ყოველთვის იმუშაოს
  • უარეს შემთხვევაში ᲛᲝᲑᲠᲣᲜᲔᲑᲐსერვერი გამოიყენება როგორც შუამავალი ( რელე), ანუ p2pიქცევა კლიენტ-სერვერ-კლიენტის კავშირად.

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

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

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

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

ცოტა ხნის შემდეგ Chrome-მა და Firefox-მა მიიღეს საკუთარი WebRTC ძრავები. ამჟამად მათი მობილური ვერსიები აღჭურვილია როგორც ამ ტექნოლოგიით, ასევე Android 5.0-ით დაყენებული WebView 3.6 ძრავით, რომელსაც იყენებენ აპლიკაციები.

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

ბრაუზერის ინტეგრაციის პარალელურად, World Wide Web Consortium (W3C) სამუშაო ჯგუფი უბიძგებს WebRTC სტანდარტიზაციის პროცესს. ის 2015 წელს უნდა დასრულდეს.

WebRTC კმაყოფილია ცოტათი

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

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

იმისათვის, რომ სტრიმინგის კავშირი შეუფერხებლად და ხარისხიანად იმუშაოს, ბრაუზერში სამი ძრავა მუშაობს. ორი მათგანი ახდენს აუდიო და ვიდეო მონაცემების ოპტიმიზაციას და შეკუმშვას, მესამე პასუხისმგებელია მათ ტრანსპორტირებაზე. ის აგზავნის მონაცემებს მეშვეობით SRTP პროტოკოლი(Secure Real-time Transport Protocol), რომელიც საშუალებას იძლევა რეალურ დროში დაშიფრული ნაკადი.

თუ პირდაპირი კავშირი ვერ ხერხდება, WebRTC ეძებს სხვა გზას. მაგალითად, ეს ხდება მაშინ, როდესაც ქსელის პარამეტრები ხელს უშლის STUN სერვერს IP მისამართის მოხსენებაში. WebRTC სტანდარტი ითვალისწინებს, რომ ამ შემთხვევაში საუბარი იქნება, მაგრამ TURN სერვერის შუალედური ჩართვით (Traversal Using Relays around NAT). ასე რომ, netscan.co ვებსაიტზე შეგიძლიათ შეამოწმოთ არის თუ არა WebRTC დანერგილი თქვენს კომპიუტერში და ინტერნეტში წვდომით.

როგორ ხდება კავშირი

ჯერ უნდა დაარეგისტრიროთ საუბარი (1). WebRTC სერვისი უზრუნველყოფს ბმულს, რომელიც უნდა გაეგზავნოს თანამოსაუბრეს. ბრაუზერი STUNserver-ის გამოყენებით აღმოაჩენს საკუთარ IP მისამართს (2), აგზავნის მას სერვისში და იღებს პარტნიორის IP-ს პირდაპირი კავშირის დასამყარებლად (3). თუ STUN ვერ მოხერხდა, საუბარი გადამისამართდება TURNსერვერის გამოყენებით (4).

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

რომელი ბრაუზერები მუშაობს WebRTC-თან

Chrome და Firefox აღჭურვილია WebRTC ძრავით, რომელიც იყენებს სერვისებს, როგორიცაა talky.io. Mozilla ბრაუზერს შეუძლია უშუალოდ იმუშაოს საკუთარ კლიენტთან.

Google და Mozilla აგრძელებენ რეალურ დროში კომუნიკაციის იდეის განვითარებას: Chrome-ს შეუძლია უმასპინძლოს WebRTC კონფერენციას რამდენიმე მონაწილესთან ერთად, ხოლო ახალი Hello კლიენტი Firefox-ში შემუშავებულია ტელეკომუნიკაციების გიგანტის Telefonica-ს შვილობილი კომპანიის დახმარებით. Apple ამ დროისთვის გვერდით რჩება, ჯერ არ უნდა ელოდოთ WebRTC-ს Safari-ში. თუმცა, არსებობს უამრავი ალტერნატიული iOS აპლიკაცია და მოდული Safari-სთვის.

Microsoft ოდნავ განსხვავებულ კურსს ატარებს. როგორც Skype-ის კონკურენტუნარიანი სერვისის მფლობელი, ეს კომპანია არ აპირებს WebRTC-თან ასე მარტივად კაპიტულაციას. ამის ნაცვლად, Microsoft ავითარებს ტექნოლოგიას სახელწოდებით ORTC (Object Real-Time Communications) Internet Explorer-ისთვის.

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

Სურათი:მწარმოებელი კომპანიები; goodluz/Photolia.com

ბრაუზერიდან დარეკვის ტექნოლოგიები მრავალი წლისაა: Java, ActiveX, Adobe Flash... ბოლო რამდენიმე წლის განმავლობაში გაირკვა, რომ დანამატები და მარცხენა ვირტუალური მანქანები არ ანათებენ მოხერხებულობით (რატომ უნდა დავაყენო რამე ყველა?) და, რაც მთავარია, უსაფრთხოება. Რა უნდა ვქნა? არის გასასვლელი!

ბოლო დრომდე IP ქსელებში გამოიყენებოდა რამდენიმე პროტოკოლი IP ტელეფონისთვის ან ვიდეოსთვის: SIP, ყველაზე გავრცელებული პროტოკოლი, რომელიც გამოდის სცენაზე, H.323 და MGCP, Jabber/Jingle (გამოიყენება Gtalk-ში), ნახევრად ღია Adobe RTMP* და, რა თქმა უნდა, დახურულია სკაიპი. Google-ის მიერ ინიცირებული WebRTC პროექტი ცდილობს შეცვალოს IP-სა და ვებ-ტელეფონიის სამყარო ყველა პროგრამული ტელეფონის, მათ შორის Skype-ის მოძველებით. WebRTC არა მხოლოდ ახორციელებს კომუნიკაციის ყველა შესაძლებლობას პირდაპირ ბრაუზერის შიგნით, რომელიც ახლა დაინსტალირებულია თითქმის ყველა მოწყობილობაზე, არამედ ერთდროულად ცდილობს გადაჭრას ბრაუზერის მომხმარებლებს შორის კომუნიკაციის უფრო ზოგადი ამოცანის გადაჭრა (სხვადასხვა მონაცემების გაცვლა, ეკრანის თარგმანი, დოკუმენტებთან თანამშრომლობა და გაცილებით მეტი).

WebRTC ვებ დეველოპერის მიერ

ვებ დეველოპერების თვალსაზრისით, WebRTC შედგება ორი ძირითადი ნაწილისგან:

• მედია ნაკადების მართვა ადგილობრივი რესურსებიდან (კამერა, მიკროფონი ან ლოკალური კომპიუტერის ეკრანი) ხორციელდება navigator.getUserMedia მეთოდით, რომელიც აბრუნებს MediaStream ობიექტს;
• მედიის ნაკადების წარმომქმნელ მოწყობილობებს შორის, მათ შორის კომუნიკაციის მეთოდების განსაზღვრა და მათი პირდაპირი გადაცემა - RTCPeerConnection ობიექტები (აუდიო და ვიდეო ნაკადების გაგზავნისა და მიღებისთვის) და RTCDataChannel (ბრაუზერიდან მონაცემების გაგზავნისა და მიღებისთვის).

Რას ვაკეთებთ?

ჩვენ გავარკვევთ, თუ როგორ მოვაწყოთ უმარტივესი მრავალმოთამაშიანი ვიდეო ჩატი ბრაუზერებს შორის WebRTC-ზე დაფუძნებული ვებ სოკეტების გამოყენებით. დავიწყოთ ექსპერიმენტები Chrome/Chromium-ში, როგორც WebRTC-ის მხრივ ყველაზე მოწინავე ბრაუზერებში, თუმცა 24 ივნისს გამოშვებული Firefox 22 თითქმის დაეწია მათ. უნდა ითქვას, რომ სტანდარტი ჯერ არ არის მიღებული და API შეიძლება შეიცვალოს ვერსიიდან ვერსიამდე. ყველა მაგალითი დატესტილია Chromium 28-ში. სიმარტივისთვის, ჩვენ არ დავაკვირდებით კოდის სისუფთავეს და ბრაუზერის თავსებადობას.

მედიასტრიმი

პირველი და უმარტივესი WebRTC კომპონენტია MediaStream. ის უზრუნველყოფს ბრაუზერს წვდომას მედია ნაკადებზე ადგილობრივი კომპიუტერის კამერიდან და მიკროფონიდან. Chrome-ში ამისათვის საჭიროა navigator.webkitGetUserMedia() ფუნქციის გამოძახება (რადგან სტანდარტი ჯერ არ არის დასრულებული, ყველა ფუნქციას აქვს პრეფიქსი, ხოლო Firefox-ში იგივე ფუნქციას ეწოდება navigator.mozGetUserMedia()). როდესაც ის გამოიძახება, მომხმარებელს მოეთხოვება დაუშვას კამერასა და მიკროფონზე წვდომა. ზარის გაგრძელება მხოლოდ მომხმარებლის თანხმობის შემდეგ იქნება შესაძლებელი. ამ ფუნქციას პარამეტრებად გადაეცემა საჭირო მედია ნაკადის პარამეტრები და ორი გამოძახების ფუნქცია: პირველი გამოიძახება კამერაზე/მიკროფონზე წარმატებული წვდომის შემთხვევაში, მეორე - შეცდომის შემთხვევაში. პირველი, მოდით შევქმნათ HTML ფაილი rtctest1.html ღილაკით და ელემენტით

getUserMedia

Microsoft CU-RTC-Web

მაიკროსოფტი არ იქნებოდა მაიკროსოფტი, თუ დაუყოვნებლივ არ გამოუშვებს საკუთარ შეუთავსებელ მორგებულ ვარიანტს სახელწოდებით CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm) Google-ის ინიციატივის საპასუხოდ. . მიუხედავად იმისა, რომ IE-ის, უკვე მცირე, წილი კვლავ კლებულობს, სკაიპის მომხმარებელთა რაოდენობა მაიკროსოფტს აძლევს იმედს, რომ Google-ს უბიძგებს და შეიძლება ვივარაუდოთ, რომ ეს სტანდარტი გამოყენებული იქნება Skype-ის ბრაუზერის ვერსიაში. Google-ის სტანდარტი ძირითადად ფოკუსირებულია ბრაუზერიდან ბრაუზერის კომუნიკაციაზე; ამავდროულად, ხმოვანი ტრაფიკის ძირითადი ნაწილი კვლავ რჩება ჩვეულებრივ სატელეფონო ქსელში და მასა და IP ქსელებს შორის საჭიროა კარიბჭეები არა მხოლოდ მარტივად გამოყენების ან უფრო სწრაფი განაწილებისთვის, არამედ როგორც მონეტიზაციის საშუალება, რომელიც საშუალებას მისცემს მეტ მოთამაშეს განავითარეთ ისინი. სხვა სტანდარტის გამოჩენამ შეიძლება არა მხოლოდ გამოიწვიოს დეველოპერების უსიამოვნო მოთხოვნილება ერთდროულად ორი შეუთავსებელი ტექნოლოგიის მხარდასაჭერად, არამედ მომავალში მომხმარებელს მისცეს შესაძლო ფუნქციონირებისა და ხელმისაწვდომი ტექნიკური გადაწყვეტილებების ფართო არჩევანი. Მოიცადე და ნახავ.

ჩართეთ ადგილობრივი თემა

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

VarlocalStream = null;

getUserMedia მეთოდის პირველი პარამეტრი არის მოთხოვნილი მედიის ნაკადის პარამეტრების მითითება - მაგალითად, უბრალოდ ჩართეთ აუდიო ან ვიდეო:

Var streamConstraints = ("აუდიო": true, "ვიდეო": true); // მოითხოვეთ წვდომა როგორც აუდიოზე, ასევე ვიდეოზე

ან მიუთითეთ დამატებითი პარამეტრები:

Var streamConstraints = ( "აუდიო": true, "ვიდეო": ( "სავალდებულო": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" ), "სურვილისამებრ": ) );

getUserMedia მეთოდის მეორე პარამეტრი არის გამოძახების ფუნქციის გადაცემა, რომელიც გამოიძახება თუ ის წარმატებულია:

ფუნქცია getUserMedia_success(ნაკადი) ( console.log("getUserMedia_success():", ნაკადი); localVideo1.src = URL.createObjectURL(ნაკადი); // მედია ნაკადის მიმაგრება HTML ელემენტზე

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

ფუნქცია getUserMedia_error(error) ( console.log("getUserMedia_error():", შეცდომა); )

ფაქტობრივი ზარი getUserMedia მეთოდზე - ითხოვს წვდომას მიკროფონზე და კამერაზე პირველი ღილაკის დაჭერისას

ფუნქცია getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

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

NavigatorUserMediaError (კოდი: 1, PERMISSION_DENIED: 1)"

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

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

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

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

RTCMediaConnection

RTCMediaConnection - ობიექტი, რომელიც შექმნილია მედიის ნაკადების დასამყარებლად და ქსელში მონაწილეებს შორის გადასატანად. გარდა ამისა, ეს ობიექტი პასუხისმგებელია მედია სესიის აღწერილობის (SDP) გენერირებაზე, ინფორმაციის მოპოვებაზე ICE კანდიდატების შესახებ NAT-ის ან firewalls-ის გავლით (ლოკალური და STUN-ის გამოყენებით) და TURN სერვერთან ურთიერთობისთვის. თითოეულ მონაწილეს უნდა ჰქონდეს ერთი RTCMediaConnection თითო კავშირზე. მედია ნაკადები გადაიცემა დაშიფრული SRTP პროტოკოლით.

TURN სერვერები

არსებობს სამი ტიპის ICE კანდიდატი: მასპინძელი, srflx და რელე. ჰოსტი შეიცავს ადგილობრივად მიღებულ ინფორმაციას, srflx არის ის, რასაც ჰოსტი ჰგავს გარე სერვერს (STUN), ხოლო რელე არის ინფორმაცია TURN სერვერის მეშვეობით ტრაფიკის პროქსიინგისთვის. თუ ჩვენი კვანძი დგას NAT-ის უკან, მაშინ მასპინძელი კანდიდატები შეიცავენ ლოკალურ მისამართებს და გამოუსადეგარი იქნებიან, srflx კანდიდატები დაეხმარებიან მხოლოდ NAT-ის გარკვეულ ტიპებს და რელე იქნება ბოლო იმედი, რომ გადაიტანოს ტრაფიკი შუალედურ სერვერზე.

ჰოსტის ტიპის ICE კანდიდატის მაგალითი, მისამართი 192.168.1.37 და პორტი udp/34022:

A=კანდიდატი:337499441 2 udp 2113937151 192.168.1.37 34022 ტიპი ჰოსტის თაობა 0

ზოგადი ფორმატი STUN/TURN სერვერების მითითებისთვის:

Var სერვერები = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn: [ელფოსტა დაცულია]:პორტი", "რწმუნებათა სიგელები": "პაროლი" ) ]);

ინტერნეტში ბევრი საჯარო STUN სერვერია. დიდი სია, მაგალითად, არის. სამწუხაროდ, ისინი ძალიან ცოტა პრობლემას აგვარებენ. პრაქტიკულად არ არსებობს საჯარო TURN სერვერები, STUN-ისგან განსხვავებით. ეს გამოწვეულია იმით, რომ TURN სერვერი თავისთავად გადის მედია ნაკადებს, რამაც შეიძლება მნიშვნელოვნად იტვირთოს როგორც ქსელის არხი, ასევე თავად სერვერი. ამიტომ, TURN სერვერებთან დაკავშირების უმარტივესი გზაა მისი დაინსტალირება (ცხადია, დაგჭირდებათ საჯარო IP). ყველა სერვერიდან, ჩემი აზრით, საუკეთესოა rfc5766-turn-server. მის ქვეშ არის Amazon EC2-ის მზა სურათიც კი.

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

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

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

შეთავაზება-პასუხის მოდელი

მედია ნაკადების ჩამოყალიბებისა და შესაცვლელად გამოიყენება შეთავაზება/პასუხის მოდელი (შემოთავაზება/პასუხი; აღწერილია RFC3264) და SDP პროტოკოლი (სესიის აღწერა პროტოკოლი). ისინი ასევე გამოიყენება SIP პროტოკოლით. ამ მოდელში განასხვავებენ ორ აგენტს: Offerer - ის, ვინც გამოიმუშავებს SDP სესიის აღწერას ახლის შესაქმნელად ან არსებულის შესაცვლელად (Offer SDP) და Answerer - ის, ვინც იღებს SDP სესიის აღწერას სხვა აგენტისგან და პასუხობს. მას საკუთარი სესიის აღწერით (პასუხი SDP). ამავდროულად, სპეციფიკაცია მოითხოვს უფრო მაღალი დონის პროტოკოლს (მაგალითად, SIP ან საკუთარი ვებ სოკეტების საშუალებით, როგორც ჩვენს შემთხვევაში), რომელიც პასუხისმგებელია აგენტებს შორის SDP-ის გადაცემაზე.

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

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

შეთავაზების ფორმირება

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

გარდა ამისა, საჭიროა ორი ღონისძიების დამმუშავებელი: onicecandidate, როდესაც ახალი ICE კანდიდატი არის განსაზღვრული და onaddstream, როდესაც მედია ნაკადი დაკავშირებულია შორიდან. დავუბრუნდეთ ჩვენს ფაილს. დაამატეთ HTML-ში ელემენტების ხაზების შემდეგ კიდევ ერთი:

შექმნა შემოთავაზება

და ელემენტთან ხაზის შემდეგ

ასევე, JavaScript კოდის დასაწყისში, ჩვენ გამოვაცხადებთ გლობალურ ცვლადს RTCPeerConnection-ისთვის:

varpc1;

RTCPeerConnection კონსტრუქტორის გამოძახებისას თქვენ უნდა მიუთითოთ STUN/TURN სერვერები. დამატებითი ინფორმაციისთვის იხილეთ გვერდითი ზოლი; სანამ ყველა მონაწილე ერთსა და იმავე ქსელშია, ისინი საჭირო არ არის.

var სერვერები = null;

SDP შეთავაზების უზრუნველყოფის ვარიანტები

var offerConstraints = ();

CreOffer() მეთოდის პირველი პარამეტრი არის გამოძახების ფუნქცია, რომელსაც ეწოდება Offer-ის წარმატებული ფორმირება

ფუნქცია pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // დააყენეთ RTCPeerConnection-ის მიერ გენერირებული შესთავაზეთ SDP setLocalDescription მეთოდი. // როდესაც შორი მხარე აგზავნის პასუხს SDP-ს, მისი დაყენება დასჭირდება setRemoteDescription მეთოდის გამოყენებით // სანამ მეორე მხარე არ განხორციელდება, არაფერი გააკეთოთ // pc2_receivedOffer(desc); )

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

ფუნქცია pc1_createOffer_error(error)(consol.log("pc1_createOffer_success_error(): შეცდომა:", შეცდომა); )

და ჩვენ გამოვაცხადებთ გამოძახების ფუნქციას, რომელიც გადაეცემა ICE კანდიდატებს, როგორც ისინი განსაზღვრულია:

ფუნქცია pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), მოვლენა.კანდიდატი); // არაფერი გააკეთოთ მანამ, სანამ მეორე მხარე არ განხორციელდება // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

ასევე გამოძახების ფუნქცია შორიდან მედიის ნაკადის დასამატებლად (მომავლისთვის, რადგან ჯერჯერობით მხოლოდ ერთი RTCPeerConnection გვაქვს):

ფუნქცია pc1_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )

როდესაც დააწკაპუნებთ ღილაკზე "createOffer", შექმენით RTCPeerConnection, დააყენეთ onicecandidate და onaddstream მეთოდები და მოითხოვეთ Offer SDP-ის ფორმირება createOffer() მეთოდის გამოძახებით:

ფუნქცია createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(სერვერები); // შექმენით RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // გამოძახების ფუნქცია pc1.adad_1 კანდიდატის დასამუშავებლად / გამოძახების ფუნქცია გამოიძახება, როდესაც არის მედია ნაკადი შორიდან, ის ჯერ არ არსებობს pc1.addStream(localStream); // გაიარეთ ლოკალური მედია ნაკადი (დაშვებით, რომ უკვე მიღებულია) pc1.createOffer(// და რეალურად მოითხოვეთ Offer pc1_createOffer_success, pc1_createOffer_error, offerConstraints-ის ფორმირება);

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

პასუხის SDP-ის ფორმირება და ICE კანდიდატების გაცვლა

ორივე Offer SDP და თითოეული ICE კანდიდატი უნდა გადაეცეს მეორე მხარეს და იქ, RTCPeerConnection-დან მათი მიღების შემდეგ, გამოიძახეთ setRemoteDescription მეთოდები Offer SDP-სთვის და addIceCandidate თითოეული ICE კანდიდატისთვის, რომელიც მიღებულია შორიდან; ანალოგიურად საპირისპირო პასუხი SDP და დისტანციური ICE კანდიდატებისთვის. თავად პასუხის SDP ფორმირებულია შეთავაზების მსგავსად; განსხვავება ისაა, რომ გამოიძახება არა createOffer მეთოდი, არამედ createAnswer მეთოდი, მანამდე კი RTCPeerConnection მეთოდი setRemoteDescription გადაეცემა აბონენტისგან მიღებულ Offer SDP-ს.

მოდით დავამატოთ კიდევ ერთი ვიდეო ელემენტი HTML-ში:

და გლობალური ცვლადი მეორე RTCPeerConnection-ისთვის პირველის დეკლარაციის მიხედვით:

Varpc2;

შეთავაზების დამუშავება და პასუხის SDP

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

ფუნქცია pc2_createAnswer_success(desc) ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )

პასუხის გენერირებისას შეცდომის შემთხვევაში გამოძახებული გამოძახების ფუნქცია სრულიად ჰგავს შეთავაზებას:

ფუნქცია pc2_createAnswer_error(error) (consol.log("pc2_createAnswer_error():", შეცდომა); )

პასუხის SDP-ის გენერირების პარამეტრები:

Var answerConstraints = ( "სავალდებულო": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );

როდესაც მეორე მონაწილე მიიღებს შეთავაზებას, ჩვენ შევქმნით RTCPeerConnection-ს და ვქმნით პასუხს ისევე, როგორც შეთავაზება:

ფუნქცია pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // შექმენით RTCPeerConnection ობიექტი მეორე მონაწილისთვის, მსგავსი პირველი pc2 = ახალი webkitRTCPeerConnection(სერვერები); pc2.onicecandidate =pc2.onicecandidate =pc2.onicecandidate =pc2. დააყენეთ მოვლენის დამმუშავებელი, როდესაც ICE კანდიდატი pc2.onaddstream = pc_onaddstream; // როდესაც ნაკადი გამოჩნდება, დააკავშირეთ იგი HTML-თან

იმისათვის, რომ Offer SDP პირველი მონაწილიდან მეორეზე გადავიტანოთ, როგორც ჩვენი მაგალითის ნაწილი, გააუქმეთ კომენტარი pc1 ფუნქციაში შექმნა შემოთავაზება success() ზარის სტრიქონი:

Pc2_receivedOffer(desc);

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

Pc2.addIceCandidate(new RTCIceCandidate(event.კანდიდატი));

მეორე მონაწილის ICE კანდიდატის მზადყოფნის ღონისძიების დამმუშავებელი სარკისებრია პირველის:

ფუნქცია pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(ახალი RTCIceCandidate(event.კანდიდატი)); ) )

გამოძახების ფუნქცია პირველი მონაწილისგან მედია ნაკადის დასამატებლად:

ფუნქცია pc2_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )

კავშირის შეწყვეტა

მოდით დავამატოთ კიდევ ერთი ღილაკი HTML-ში

გათიშეთ

და კავშირის დასრულების ფუნქცია

ფუნქცია btnHangupClick() ( // გამორთეთ ლოკალური ვიდეო HTML ელემენტებიდან

შევინახოთ როგორც rtctest3.html, დავაყენოთ სერვერზე და გავხსნათ ბრაუზერში. ეს მაგალითი ახორციელებს ორმხრივ მედიის ნაკადს ორ RTCPeerConnection-ს შორის იმავე ბრაუზერის ჩანართში. შეთავაზება და პასუხის SDP, ICE კანდიდატების გაცვლის ორგანიზება მონაწილეებს შორის და სხვა ინფორმაცია ქსელის საშუალებით, საჭირო იქნება მონაწილეებს შორის გაცვლის განხორციელება რაიმე სახის ტრანსპორტის გამოყენებით, ჩვენს შემთხვევაში, ვებ სოკეტების ნაცვლად, პირდაპირი ზარის ნაცვლად. პროცედურები.

ეკრანის მაუწყებლობა

getUserMedia ფუნქციით, თქვენ ასევე შეგიძლიათ გადაიღოთ ეკრანი და გადაიტანოთ როგორც MediaStream შემდეგი პარამეტრების მითითებით:

Var mediaStreamConstraints = ( აუდიო: false, ვიდეო: ( სავალდებულო: ( chromeMediaSource: "ეკრანი" ), სურვილისამებრ: ) );

ეკრანზე წარმატებული წვდომისთვის რამდენიმე პირობა უნდა დაკმაყოფილდეს:

• ჩართეთ ეკრანის დროშა getUserMedia()-ში chrome://flags/,chrome://flags/-ში;
• წყაროს ფაილი უნდა იყოს გადმოწერილი HTTPS (SSL წარმოშობის) საშუალებით;
• აუდიო ნაკადი არ უნდა იყოს მოთხოვნილი;
• მრავალჯერადი მოთხოვნა არ უნდა გაკეთდეს ბრაუზერის იმავე ჩანართში.

ბიბლიოთეკები WebRTC-სთვის

მიუხედავად იმისა, რომ WebRTC ჯერ არ არის დასრულებული, მასზე დაფუძნებული რამდენიმე ბიბლიოთეკა უკვე გამოჩნდა. JsSIP შექმნილია ბრაუზერზე დაფუძნებული რბილი ტელეფონების შესაქმნელად, რომლებიც მუშაობენ SIP გადამრთველებთან, როგორიცაა Asterisk და Camalio. PeerJS გაამარტივებს P2P ქსელების შექმნას მონაცემთა გაცვლისთვის, ხოლო Holla შეამცირებს ბრაუზერებიდან P2P კომუნიკაციისთვის საჭირო განვითარების რაოდენობას.

Node.js და socket.io

იმისათვის, რომ მოვაწყოთ SDP და ICE კანდიდატების გაცვლა ორ RTCPeerConnection-ს შორის ქსელში, ჩვენ ვიყენებთ Node.js-ს socket.io მოდულთან ერთად.

აღწერილია Node.js-ის უახლესი სტაბილური ვერსიის ინსტალაცია (Debian/Ubuntu-სთვის).

$ sudo apt-get დააინსტალირე python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get განახლება $ sudo apt-get install nodejs

აღწერილია სხვა ოპერაციული სისტემების ინსტალაცია

მოდით შევამოწმოთ:

$ echo "sys=require("util"); sys.puts("სატესტო შეტყობინება");" > nodetest1.js $ nodejs nodetest1.js

npm (Node Package Manager) გამოყენებით დააინსტალირეთ socket.io და დამატებითი ექსპრეს მოდული:

$ npm დააინსტალირეთ socket.io express

მოდით შევამოწმოთ ის სერვერის მხრიდან nodetest2.js ფაილის შექმნით:

$ nano nodetest2.js var app = მოითხოვს("express")() , server = მოითხოვს("http").createServer(app) , io = მოითხოვს("socket.io").listen(server); server.listen(80); // თუ პორტი 80 უფასოა app.get("/", ფუნქცია (req, res) ( // root გვერდზე წვდომისას res.sendfile(__dirname + "/nodetest2.html"); // მიეცით HTML ფაილი) ) ; io.sockets.on("კავშირი", ფუნქცია (სოკეტი) ( // დაკავშირებისას socket.emit("სერვერის მოვლენა", ( გამარჯობა: "მსოფლიო" )); // შეტყობინების გაგზავნა socket.on("კლიენტის მოვლენა", ფუნქცია (მონაცემები) ( // და გამოაცხადეთ მოვლენის დამმუშავებელი, როდესაც შეტყობინება მოვა კლიენტის კონსოლიდან.log(data); )); ));

და nodetest2.html კლიენტის მხარისთვის:

$nano nodetest2.html

მოდით დავიწყოთ სერვერი:

$ sudo nodejs nodetest2.js

და გახსენით გვერდი http://localhost:80 (თუ მუშაობს ლოკალურად 80-ე პორტზე) ბრაუზერში. თუ ყველაფერი წარმატებულია, ბრაუზერის JavaScript კონსოლში ჩვენ დავინახავთ მოვლენების გაცვლას ბრაუზერსა და სერვერს შორის კავშირის დროს.

ინფორმაციის გაცვლა RTCPeerConnection-ს შორის ვებ სოკეტების საშუალებით

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

შევინახოთ ჩვენი მთავარი მაგალითი (rtcdemo3.html) ახალი სახელით rtcdemo4.html. ჩართეთ socket.io ბიბლიოთეკა ელემენტში:

და JavaScript სკრიპტის დასაწყისში - ვებ სოკეტის კავშირი:

var socket = io.connect ("http://localhost");

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

ფუნქცია createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit ("შემოთავაზება", desc); ... ) ფუნქცია pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); სოკეტი .emit("პასუხი", desc); ) ფუნქცია pc1_onicecandidate(event) (... // pc2.addIceCandidate(new RTCIceCandidate(event.კანდიდატი)); socket.emit("ice1", მოვლენა.კანდიდატი); .. . ) ფუნქცია pc2_onicecandidate(event) (... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ...)

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

ფუნქცია btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", ()); )

და დაამატეთ შეტყობინებების მიღების დამმუშავებლები:

Socket.on("შემოთავაზება", ფუნქცია (მონაცემები) ( console.log("socket.on("შემოთავაზება"):", მონაცემები); pc2_receivedOffer(data); )); socket.on("პასუხი", ფუნქცია (მონაცემები) (e console.log("socket.on("პასუხი"):", მონაცემები); pc1.setRemoteDescription(ახალი RTCSessionDescription(მონაცემები)); )); socket.on("ice1", ფუნქცია (მონაცემები) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("ice2", ფუნქცია (მონაცემები) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); socket.on("hangup", ფუნქცია (მონაცემები) ( console.log("socket.on("hangup")):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

სერვერის ნაწილი

სერვერის მხარეს შეინახეთ nodetest2 ფაილი ახალი სახელით rtctest4.js და io.sockets.on("კავშირი", ფუნქცია (სოკეტი) (...) ფუნქციის შიგნით დაამატეთ კლიენტის შეტყობინებების მიღება და გაგზავნა:

Socket.on("შემოთავაზება", ფუნქცია (მონაცემები) ( // შეტყობინების "შემოთავაზების" მიღებისას, // ვინაიდან ამ მაგალითში მხოლოდ ერთი კლიენტის კავშირია, // გაგზავნეთ ისევ იმავე სოკეტის მეშვეობით socket.emit( "შემოთავაზება" , მონაცემები); // თუ საჭირო იყო შეტყობინების გადაგზავნა ყველა კავშირზე // გამომგზავნის გარდა: // socket.broadcast.emit("შემოთავაზება", მონაცემები); )); socket.on("პასუხი", ფუნქცია (მონაცემები) ( socket.emit("პასუხი", მონაცემები); )); socket.on("ice1", ფუნქცია (მონაცემები) ( socket.emit("ice1", data); )); socket.on("ice2", ფუნქცია (მონაცემები) ( socket.emit("ice2", data); )); socket.on("Hangup", ფუნქცია (მონაცემები) ( socket.emit("Hangup", data); ));

გარდა ამისა, შეცვალეთ HTML ფაილის სახელი:

// res.sendfile(__dirname + "/nodetest2.html"); // HTML ფაილის გაგზავნა res.sendfile(__dirname + "/rtctest4.html");

სერვერის დაწყება:

$ sudo nodejs nodetest2.js

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

დასკვნა

შედეგად მიღებული მაგალითი ძალიან პირობითია, მაგრამ თუ ჩვენ ოდნავ გავუნივერსალებთ მოვლენის დამმუშავებლებს ისე, რომ ისინი არ განსხვავდებოდეს გამოძახებულ და გამოძახებულ მხარეებს შორის, ორი ობიექტის ნაცვლად pc1 და pc2, შექმენით RTCPeerConnection მასივი და განახორციელეთ ელემენტების დინამიური შექმნა და წაშლა.

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

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

რა არის WebRTC?

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

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

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

სერგეი იუცაიტისი, Cisco, ვიდეო+კონფერენცია 2016 წ

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

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

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

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

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

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

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

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

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

სტანდარტის ნაკლოვანებები

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

WebRTC საიდუმლოებები: როგორ სარგებლობენ გამყიდველები დამღუპველი ვებ ტექნოლოგიით

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

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

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

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

გამოიყენეთ სპეციალიზებულ ხსნარებში

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

სკაიპის ყოფილი მომხმარებლები 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-მა მიიღო 4.2 ქულა MOS ტესტირებაში (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-ს „მოვალეობები“ მოიცავს სიგნალის დამუშავებას (გარეგანი ხმაურისგან გაწმენდას, მიკროფონის ხმის რეგულირებას) და კონტროლს. გამოყენებული აუდიო და ვიდეო კოდეკებზე).
• RTC მონაცემთა არხი(უზრუნველყოფს მონაცემთა ორმხრივ გადაცემას დამყარებულ კავშირზე).

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

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

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

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

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

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

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

1. გვერდის გახსნისას ვამოწმებთ ოთახის ID-ს არსებობას მდებარეობა.ჰაში
2. თუ ოთახის ID არ არის მითითებული, შექმენით ახალი
3. ჩვენ ვუგზავნით სასიგნალო სერვერს "შეტყობინებას, რომ გვინდა შევუერთდეთ მითითებულ ოთახს
4. სასიგნალო სერვერი უგზავნის მომხმარებლის ახალ შეტყობინებას ამ ოთახში სხვა კლიენტებს
5. კლიენტები, რომლებიც უკვე ოთახში არიან, ახალმოსულს უგზავნიან SDP შეთავაზებას
6. ახალმოსული პასუხობს შეთავაზებას „ს

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

მოგეხსენებათ, მიუხედავად იმისა, რომ WebRTC უზრუნველყოფს P2P კავშირის შესაძლებლობას ბრაუზერებს შორის, ის მაინც მოითხოვს დამატებით ტრანსპორტს სერვისული შეტყობინებების გაცვლისთვის. ამ მაგალითში ტრანსპორტი არის WebSocket სერვერი დაწერილი Node.JS-ში socket.io-ს გამოყენებით:

var socket_io = მოითხოვს ("socket.io"); module.exports = ფუნქცია (სერვერი) ( var users = (); var io = socket_io(server); io.on("კავშირი", ფუნქცია(სოკეტი) ( // მინდა ახალი მომხმარებელი შეუერთდეს ოთახის სოკეტს.on( "room ", function(message) ( var json = JSON. parse(message); // სოკეტის დამატება მომხმარებელთა სიაში = სოკეტი; თუ (socket.room !== განუსაზღვრელია) ( // თუ სოკეტი არის უკვე ზოგიერთ ოთახში დატოვეთ ის socket.leave(socket.room); ) // შეიყვანეთ მოთხოვნილი ოთახი socket.room = json.room; socket.join(socket.room); socket.user_id = json.id; // გაუგზავნეთ სხვა კლიენტებს ამ ოთახს აქვს შეტყობინება ახალი მონაწილე socket.broadcast.to(socket.room).emit("new", json.id); )); // WebRTC დაკავშირებული შეტყობინება (SDP შეთავაზება, SDP პასუხი ან ICE კანდიდატი) socket.on("webrtc", ფუნქცია(გზავნილი) ( var json = JSON.parse(message); if (json.to !== განუსაზღვრელი && მომხმარებლებს !== განუსაზღვრელი) ( // თუ შეტყობინებას აქვს მიმღები და სერვერისთვის ცნობილი ეს მიმღები, გაგზავნეთ შეტყობინება მხოლოდ მას... users.emit("webrtc", message); ) else ( // ...სხვაგვარად განიხილეთ შეტყობინება, როგორც სამაუწყებლო socket.broadcast.to(socket.room).emit("webrtc", message); ) )); // Someone disconnected socket.on("disconnect", function() ( // როდესაც კლიენტი გათიშავს, შეატყობინეთ სხვებს socket.broadcast.to(socket.room).emit("leave", socket.user_id); წაშალე მომხმარებლები; )); )); );

1. index.html

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

2.მთავარი.js

2.0. გვერდის ელემენტებთან და WebRTC ინტერფეისებთან ბმულების მიღება

var chatlog = document.getElementById("chatlog"); var message = document.getElementById("მესიჯი"); var connection_num = document.getElementById("connection_num"); var room_link = document.getElementById("room_link");

ჩვენ კვლავ უნდა გამოვიყენოთ ბრაუზერის პრეფიქსები WebRTC ინტერფეისებზე წვდომისთვის.

Var PeerConnection = window.mozRTCPeerConnection || window.webkitRTCPeerConnection; var SessionDescription = window.mozRTCSessionDescription || window.RTCSessionDescription; var IceCandidate = window.mozRTCIceCandidate || ფანჯარა.RTCIceCandidate;

2.1. ოთახის პირადობის განსაზღვრა

აქ ჩვენ გვჭირდება ფუნქცია უნიკალური ოთახისა და მომხმარებლის ID-ის გენერირებისთვის. ჩვენ გამოვიყენებთ UUID ამ მიზნით.

ფუნქცია uuid () ( var s4 = ფუნქცია() ( return Math.floor(Math.random() * 0x10000).toString(16); ); დაბრუნება s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )

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

VarROOM = location.hash.substr(1); if (!ROOM) ( ROOM = uuid(); ) room_link.innerHTML = "ბმული ოთახთან"; varME = uuid();

2.2. ვებ სოკეტი

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

// ვაკონკრეტებთ, რომ როდესაც შეტყობინება დახურულია, სერვერს უნდა გავუგზავნოთ შეტყობინება ამ var socket = io.connect("", ("სინქრონიზაციის გათიშვა განტვირთვისას": true)); socket.on("webrtc", socketReceived); socket.on ("ახალი", socketNewPeer); // დაუყოვნებლივ გაგზავნეთ მოთხოვნა ოთახში შესვლისთვის socket.emit("room", JSON.stringify((id: ME, room: ROOM))); // დამხმარე ფუნქცია WebRTC ფუნქციასთან დაკავშირებული მისამართის შეტყობინებების გაგზავნისთვის sendViaSocket(type, message, to) ( socket.emit("webrtc", JSON.stringify((id: ME, to: to, type: type, data: message ) ))))

2.3. თანატოლთა კავშირის პარამეტრები

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

Var სერვერი = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun:stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", სერთიფიკატი: "თქვენი პაროლი მიდის აქ", მომხმარებლის სახელი: " [ელფოსტა დაცულია]") ]); var პარამეტრები = ( სურვილისამებრ: [ (DtlsSrtpKeyAgreement: true), // საჭიროა Chrome-სა და Firefox-ს შორის კავშირისთვის (RtpDataChannels: true) // საჭიროა Firefox-ში DataChannels API-ის გამოსაყენებლად ] )

2.4. ახალი მომხმარებლის დაკავშირება

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

var თანატოლები = (); ფუნქცია socketNewPeer(data) ( peers = (candidateCache: ); // შექმენით ახალი კავშირი var pc = new PeerConnection(სერვერი, პარამეტრები); // დააინსტალირეთ იგი initConnection (კომპიუტერი, მონაცემები, "შემოთავაზება"); // შეინახეთ თანატოლები სიაში peers peers.connection = pc; // შექმენით DataChannel, რომლის მეშვეობითაც მოხდება შეტყობინებების გაცვლა var channel = pc.createDataChannel("mychannel", ()); channel.owner = მონაცემები; peers.channel = არხი; // მოვლენის დამმუშავებლების დაყენება bindEvents(არხი); // SDP შეთავაზების შექმნა pc.createOffer(function(offer) ( pc.setLocalDescription(offer); )); ) ფუნქცია initConnection(pc, id, sdpType) ( pc.onicecandidate = ფუნქცია ( მოვლენა) ( if (event.კანდიდატი) ( // როდესაც ახალი ICE კანდიდატი იპოვება, დაამატეთ იგი სიაში peers.candidateCache.push(event.candidate); ) else ( // როდესაც კანდიდატების აღმოჩენა მოხდება დასრულებულია, დამმუშავებელი ხელახლა გამოიძახება, მაგრამ კანდიდატის გარეშე // ამ შემთხვევაში, ჩვენ პირველ რიგში ვუგზავნით თანატოლს SDP შეთავაზებას, ან SDP-ის პასუხი (ფუნქციის პარამეტრიდან გამომდინარე)... sendViaSocket(sdpType, pc.localDescription, id); // ...და შემდეგ ყველა ადრე ნაპოვნი ICE კანდიდატი (var i = 0; i< peers.candidateCache.length; i++) { sendViaSocket("candidate", peers.candidateCache[i], id); } } } pc.oniceconnectionstatechange = function (event) { if (pc.iceConnectionState == "disconnected") { connection_num.innerText = parseInt(connection_num.innerText) - 1; delete peers; } } } function bindEvents (channel) { channel.onopen = function () { connection_num.innerText = parseInt(connection_num.innerText) + 1; }; channel.onmessage = function (e) { chatlog.innerHTML += "

"; }; }

2.5. SDP შეთავაზება, SDP პასუხი, ICE კანდიდატი

როდესაც ერთ-ერთი ასეთი შეტყობინება მიიღება, ჩვენ მოვუწოდებთ შესაბამის შეტყობინებების დამმუშავებელს.

ფუნქცია socketReceived(data) ( var json = JSON.parse(data); switch (json.type) ( case "candidate": remoteCandidateReceived(json.id, json.data); შესვენება; შემთხვევა "offer": remoteOfferReceived(json. id, json.data); შესვენება; შემთხვევა "პასუხი": remoteAnswerReceived(json.id, json.data); შესვენება; ) )

2.5.0 SDP შეთავაზება

ფუნქცია remoteOfferReceived(id, data) (createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(პასუხი) (pc.setLocalDescription(პასუხი); )); ) ფუნქცია createConnection(id) ( if (peers === განუსაზღვრელია) ( peers = (candidateCache: ); var pc = new PeerConnection(სერვერი, პარამეტრები); initConnection(pc, id, "პასუხი"); peers.connection = pc ; pc.ondatachannel = ფუნქცია(ე) ( peers.channel = e.channel; peers.channel.owner = id; bindEvents(peers.channel); )) )

2.5.1 SDP პასუხი

ფუნქცია remoteAnswerReceived(id, მონაცემები) ( var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); )

2.5.2 ICE კანდიდატი

ფუნქცია remoteCandidateReceived(id, data) (createConnection(id); var pc = peers.connection; pc.addIceCandidate(new IceCandidate(data)); )

2.6. შეტყობინების გაგზავნა

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