WebRTC. Brauzerdə video konfrans. WebRTC Webrtc səsli söhbətindən istifadə edərək çox istifadəçi söhbəti

Preambula. P2P video söhbəti aktivdir WebRTC əsasında Skype və digər ünsiyyət vasitələrinə alternativdir. WebRTC əsasında p2p video söhbətinin əsas elementləri brauzer və əlaqə serveridir. P2P video çatlar, serverin məlumat axınlarının ötürülməsində iştirak etmədiyi həmyaşıd video söhbətlərdir. Məlumat heç bir əlavə proqram olmadan birbaşa istifadəçilərin brauzerləri (peerings) arasında ötürülür. Brauzerlərə əlavə olaraq, p2p video söhbətləri istifadəçiləri qeydiyyata almaq, onlar haqqında məlumatları saxlamaq və istifadəçilər arasında keçidi təmin etmək üçün nəzərdə tutulmuş əlaqə serverlərindən istifadə edir. Ən son WebRTC və HTML5 texnologiyalarını dəstəkləyən brauzerlər ani mətn mesajları və faylları təqdim edir, həmçinin IP şəbəkələri üzərindən səs və video rabitəni təmin edir.

Belə ki, çatlar, veb-çatlar, veb-interfeysdə səsli və video çatlar, IMS, VoIP paket keçidli kompozit şəbəkələr vasitəsilə onlayn ünsiyyəti təmin edən xidmətlərdir. Bir qayda olaraq, rabitə xidmətləri istifadəçi cihazlarında (kompüterlər, smartfonlar və s.) müştəri proqramlarının quraşdırılmasını, ya da brauzerlərdə plaginlərin və genişləndirmələrin quraşdırılmasını tələb edir. Xidmətlərin öz kommunikasiya şəbəkələri var, onların əksəriyyəti “klient-server” arxitekturasında qurulur.

Rabitə xidmətləri IMS istisna olmaqla, səs, video, məlumat və mətn kanallarının inteqrasiya olunmadığı proqramlardır. Hər bir xidmətin şəbəkələrində, . Qeyd etmək lazımdır ki, bu proqramlar eyni vaxtda bir neçə rabitə şəbəkəsində işləyə bilməz, yəni. Tətbiqlər adətən bir-biri ilə əlaqə saxlaya bilmir, nəticədə hər bir rabitə şəbəkəsi üçün ayrıca proqram quraşdırılacaq.

Real vaxt rejimində rabitə xidmətlərinin (chat, telefoniya, videokonfrans) inteqrasiyası problemi, i.e. səs, video, məlumat ötürmə kanallarının inteqrasiyası və bir proqramdan (brauzerdən) istifadə etməklə onlara çıxış WebRTC protokolu əsasında peer-to-peer və ya p2p video çatlarında (peer-to-peer, point-to-point) həll edilə bilər. . Əslində, WebRTC-ni dəstəkləyən brauzer bütün istifadəçi cihazları (kompüterlər, smartfonlar, iPad-lər, IP telefonlar, mobil telefonlar s.) rabitə xidmətləri ilə işləyən.

Real vaxt rejimində rabitəni təmin edən bütün texnologiyaların brauzerdə tətbiqini təmin edən WebRTC-dir. P2p video çatlarının mahiyyəti ondan ibarətdir ki, multimedia və mətn məlumatları serverin və əlavə proqramların iştirakı olmadan birbaşa istifadəçilərin brauzerləri (uzaqdan baxanlar) arasında ötürülür. Beləliklə, brauzerlər yalnız demək olar ki, hamısına girişi təmin etmir informasiya resursları Serverlərdə saxlanılan, eyni zamanda bütün real vaxt rabitə xidmətlərinə və poçt xidmətlərinə (səsli poçt, e-poçt, SMS və s.)

p2p video çatlarının serverləri (əlaqə serverləri) yalnız istifadəçi qeydiyyatı, istifadəçilər haqqında məlumatların saxlanması və istifadəçilərin brauzerləri arasında əlaqə (keçid) yaratmaq üçün nəzərdə tutulub. İlk p2p video söhbətləri flaş texnologiyalarından istifadə etməklə həyata keçirilib. Flash p2p video söhbətləri, məsələn, istifadə olunur sosial şəbəkələrdə. Flash p2p video söhbətləri təmin etmir yüksək keyfiyyət multimedia məlumatlarının ötürülməsi. Bundan əlavə, p2p flash video söhbətlərində mikrofon və video kameradan səs və video axını çıxarmaq üçün quraşdırmanız lazımdır. flash plugin veb brauzerə.

Lakin yeni nəsil telekommunikasiya xidmətlərinə internet üzərindən ünsiyyət üçün yalnız WebRTC protokollarını və HTML5 spesifikasiyasını dəstəkləyən brauzerlər və əlaqə serverlərindən istifadə edən veb kommunikasiyalar daxildir. Belə brauzerlə təchiz edilmiş istənilən istifadəçi cihazı (PC, iPad, smartfonlar və s.) yüksək keyfiyyətli səsli və video zəngləri təmin edə, həmçinin ani mətn mesajları və faylları ötürə bilər.

Beləliklə, yeni veb kommunikasiya texnologiyası (p2p çatlar, video çatlar) WebRTC protokoludur. WebRTC HTML5, CSS3 və JavaScript ilə birlikdə müxtəlif veb proqramlar yaratmağa imkan verir. WebRT, peer-to-peer arxitekturasından istifadə edərək real vaxt rejimində veb kommunikasiyalarını (peer-to-peer şəbəkələri) təşkil etmək üçün nəzərdə tutulmuşdur. WebRTC əsasında P2P çatları faylların ötürülməsini, həmçinin brauzerdə xarici əlavələr və plaginlərdən istifadə etmədən yalnız veb-brauzerlərdən istifadə etməklə istifadəçilərin internet üzərindən mətn, səs və video rabitəsini təmin edir.

P2p söhbətlərində server yalnız iki brauzer arasında p2p əlaqəsi yaratmaq üçün istifadə olunur. WebRTC protokolu əsasında p2p söhbətinin müştəri hissəsini yaratmaq üçün HTML5, CSS3 və JavaScript istifadə olunur. Müştəri proqramı WebRTC API vasitəsilə brauzerlərlə əlaqə saxlayır.

WebRTC üç JavaScript API tərəfindən həyata keçirilir:

• RTCPeerConnection;
• MediaStream (getUserMedia);
• RTCDataChannel.

Brauzerlər multimedia məlumatlarını UDP-nin üstündə işləyən SRTP protokolundan istifadə edərək ötürür. NAT İnternet üzərindən p2p bağlantılarından istifadə edən NAT marşrutlaşdırıcılarının arxasında brauzerlər (müştərilər) üçün problemlər yaratdığından, STUN NAT tərcüməçilərindən yan keçmək üçün istifadə olunur. STUN, UDP nəqliyyat protokolunun üstündə işləyən müştəri/server protokoludur. P2p söhbətlərində, bir qayda olaraq, ictimai STUN serverindən istifadə olunur və ondan alınan məlumat NAT-dan geri qaldıqda, iki brauzer arasında UDP bağlantısı üçün istifadə olunur.

WebRTC proqramlarının həyata keçirilməsinə dair nümunələr (p2p söhbətləri, səsli və video internet çatları):
1. WebRTC-yə əsaslanan Bistri P2P video çatı (bir kliklə video söhbət, p2p söhbəti) Bistri-də açıla bilər. Bistri əlavə proqramlar və plaginlər quraşdırmadan brauzerdə işləyir. İşin mahiyyəti belədir: göstərilən linkdən istifadə edərək p2p video söhbəti açın, açılan interfeysdə qeydiyyatdan keçdikdən sonra tərəfdaşları dəvət edin, sonra həmyaşıd müştərilərin siyahısından onlayn olan tərəfdaşı seçin və "video zəng" düyməsini basın. " düyməsi.

Nəticədə, MediaStream (getUserMedia) mikrofon + veb-kameranı tutacaq və server seçilmiş partnyorla siqnal mesajları mübadiləsi aparacaq. Siqnal mesajları mübadiləsindən sonra PeerConnection API səs və video axınlarının ötürülməsi üçün kanallar yaradır. Bundan əlavə, Bistri ani mətn mesajları və faylların ötürülməsini həyata keçirir. Əncirdə. Şəkil 1 Bistri p2p video chat interfeysinin ekran görüntüsünü göstərir.

düyü. 1. P2P Video Çat Bistr

2. Twelephone (p2p video chat, p2p chat, SIP Twelephone) HTML5 və WebRTC əsaslı müştəri proqramıdır və səsli və video zənglər etməyə, həmçinin ani mətn mesajları göndərməyə imkan verir, i.e. Twelephone test p2p chat, video chat və SIP Twelephone daxildir. Qeyd edək ki, Twelephone SIP protokolunu dəstəkləyir və indi siz Twitter hesabınızdan telefon nömrəsi kimi istifadə edərək SIP telefonlardan səsli və video zənglər edə və qəbul edə bilərsiniz. Bundan başqa, mətn mesajları mikrofon vasitəsilə səslə daxil ola bilərsiniz və səsin tanınması proqramı mətni "Mesaj göndər" xəttinə daxil edir.

Twelephone brauzer əsaslı veb-telefoniyadır Google Chrome, 25-ci versiyadan başlayaraq, əlavə olmadan proqram təminatı. Twelephone Chris Matthieu tərəfindən hazırlanmışdır. Twelephone-un arxa hissəsi Node.js üzərində qurulub. Server (əlaqə serveri) yalnız iki brauzer və ya WebRTC müştəriləri arasında p2p əlaqəsi yaratmaq üçün istifadə olunur. Twelephone tətbiqinin öz avtorizasiya vasitələri yoxdur, lakin hesaba qoşulmağa yönəlib ( hesab) Twitter-də.

Əncirdə. Şəkil 2-də Twelephone p2p video söhbət interfeysinin ekran görüntüsü göstərilir.

düyü. 2.P2P Twinphone

3. Qrup p2p video çatı Conversat.io ən son WebRTC və HTML5 texnologiyalarına əsaslanır. Conversat video çatı SimpleWebRTC kitabxanasına əsaslanır və bir otaqda 6-ya qədər həmyaşıd müştəri ilə ünsiyyət qurmaq üçün nəzərdə tutulub (ünsiyyət üçün “Söhbətə ad verin” sətirində həmyaşıd müştərilər üçün ümumi otağın adını qeyd edin). P2P video çatı Conversat istifadəçilərə əlaqə serverində qeydiyyatdan keçmədən rabitə xidmətləri təqdim edir. Əncirdə. Şəkil 3 Conversat p2p video söhbət interfeysinin ekran görüntüsünü göstərir.

düyü. 3. Qrup P2P video çatı Conversat.io

WebRTC əsaslı P2P video söhbətlərində iştirak etmək üçün istifadəçilər WebRTC protokolunu və HTML5 spesifikasiyasını dəstəkləyən brauzer quraşdırılmalıdır. Hal-hazırda, Google Chrome brauzerləri, versiya 25-dən başlayaraq və Mozilla Firefox Gecə WebRTC protokolunu və HTML5 spesifikasiyasını dəstəkləyir. WebRTC proqramları təsvir və səs ötürmə keyfiyyətinə görə Flash proqramlarından üstündür.

WebRTC-dəki materialların əksəriyyəti kodlaşdırmanın tətbiqi təbəqəsinə yönəlib və texnologiyanı başa düşməyə kömək etmir. Gəlin daha dərinə getməyə çalışaq və əlaqənin necə baş verdiyini, sessiya deskriptorunun və namizədlərin nə olduğunu, STUN və TURN serverlərinin nə üçün olduğunu öyrənək.

WebRTC Giriş

WebRTC video məlumat ötürülməsi üçün iki müştərini birləşdirməyə imkan verən brauzer əsaslı texnologiyadır. Əsas xüsusiyyətlər daxili brauzer dəstəyidir (adobe flash kimi üçüncü tərəfin quraşdırılmış texnologiyalarına ehtiyac yoxdur) və müştəriləri əlavə serverlərdən istifadə etmədən birləşdirmək imkanı - peer-to-peer bağlantısı (bundan sonra p2p).

P2p bağlantısı qurmaq olduqca çətin bir işdir, çünki kompüterlərdə həmişə ictimai IP ünvanları, yəni İnternetdəki ünvanlar olmur. IPv4 ünvanlarının azlığı (və təhlükəsizlik məqsədləri üçün) sayəsində, məsələn, evdə istifadə üçün şəxsi şəbəkələr yaratmağa imkan verən NAT mexanizmi hazırlanmışdır. İndi bir çox ev marşrutlaşdırıcıları NAT-ı dəstəkləyir və bunun sayəsində bütün ev cihazlarının İnternetə çıxışı var, baxmayaraq ki, ISP-lər adətən bir IP ünvanı verir. Ümumi IP ünvanları İnternetdə unikaldır, lakin özəl olanlar deyil. Buna görə də p2p-yə qoşulmaq çətindir.

Bunu daha yaxşı başa düşmək üçün üç vəziyyəti nəzərdən keçirin: hər iki qovşaq eyni şəbəkədədir (Şəkil 1), hər iki qovşaq müxtəlif şəbəkələrdədir (biri özəl, digəri ictimaidir) (Şəkil 2) və hər iki qovşaq fərqli özəldir. eyni IP ünvanları olan şəbəkələr (Şəkil 3) .

Şəkil 1: Eyni şəbəkədəki hər iki qovşaq

Şəkil 2: Müxtəlif şəbəkələrdə qovşaqlar (biri özəl, biri ictimai)

Şəkil 3: Fərqli özəl şəbəkələrdəki qovşaqlar, lakin ədədi bərabər ünvanlarla

Yuxarıdakı rəqəmlərdə, iki simvollu qeyddəki ilk hərf node tipini göstərir (p = peer , r = router ). Birinci şəkildə vəziyyət əlverişlidir: onların şəbəkəsindəki qovşaqlar şəbəkə IP ünvanları ilə kifayət qədər müəyyən edilir və buna görə də bir-birinə birbaşa qoşula bilər. İkinci şəkildə, oxşar node nömrələri olan iki fərqli şəbəkəmiz var. Burada ikisi olan marşrutlaşdırıcılar (marşrutlaşdırıcılar) görünür şəbəkə interfeysi- şəbəkə daxilində və şəbəkənizdən kənarda. Buna görə də, onların iki IP ünvanı var. Adi qovşaqların yalnız bir interfeysi var, onun vasitəsilə yalnız öz şəbəkələrində əlaqə saxlaya bilərlər. Şəbəkələrindən kənarda kiməsə məlumat ötürsələr, onda yalnız marşrutlaşdırıcının (marşrutlaşdırıcının) daxilində NAT istifadə edir və buna görə də marşrutlaşdırıcının IP ünvanı altında başqalarına görünür - bu onların xarici IP ünvanı. Beləliklə, p1 node var daxili IP= 192.168.0.200 Və xarici IP= 10.50.200.5 , sonuncu ünvan onun şəbəkəsindəki bütün digər hostlar üçün də xarici olmaqla. Vəziyyət p2 node üçün də oxşardır. Buna görə də, yalnız daxili (öz) IP ünvanlarından istifadə edildikdə, onların əlaqəsi mümkün deyil. Xarici ünvanlardan, yəni marşrutlaşdırıcıların ünvanlarından istifadə edə bilərsiniz, lakin eyni şəxsi şəbəkədəki bütün qovşaqlar eyni xarici ünvana malik olduğundan, bu olduqca çətindir. Bu problem NAT mexanizmindən istifadə etməklə həll edilir.

Hələ də qovşaqları daxili ünvanları vasitəsilə birləşdirməyə qərar etsək nə olacaq? Məlumatlar şəbəkəni tərk etməyəcək. Təsiri artırmaq üçün son şəkildə göstərilən vəziyyəti təsəvvür edə bilərsiniz - hər iki qovşaq eyni daxili ünvanlara malikdir. Onları ünsiyyət üçün istifadə edərlərsə, onda hər bir qovşaq özü ilə əlaqə quracaqdır.

WebRTC bu cür problemləri ICE protokolundan istifadə edərək uğurla həll edir, lakin bu, əlavə serverlərin istifadəsini tələb edir (STUN , TURN ). Bütün bunlar aşağıda.

WebRTC-nin iki mərhələsi

WebRTC protokolu (və ya iki iPhone əlaqə saxlayırsa, sadəcə RTC) vasitəsilə iki nodu birləşdirmək üçün əlaqə yaratmaq üçün bəzi ilkin addımlar atılmalıdır. Bu, birinci mərhələdir - əlaqə yaratmaq. İkinci mərhələ video məlumatların ötürülməsidir.

Dərhal demək lazımdır ki, WebRTC texnologiyası çox istifadə etsə də müxtəlif yollarla rabitə (TCP və UDP) və onlar arasında çevik keçid var, bu texnologiya əlaqə məlumatlarını ötürmək üçün protokola malik deyil. Təəccüblü deyil, çünki iki p2p qovşağını birləşdirmək o qədər də asan deyil. Buna görə də bir az olması lazımdır əlavə WebRTC ilə heç bir əlaqəsi olmayan məlumat ötürmə üsulu. Bu, soket rabitəsi, HTTP protokolu ola bilər, hətta ola bilər SMTP protokolu və ya rus poçtu. Bu ötürmə mexanizmi ilkin məlumatlar deyilir siqnal. Çox məlumat ötürmək lazım deyil. Bütün məlumatlar mətn kimi ötürülür və iki növə bölünür - SDP və Ice Candidate . Birinci növ məntiqi əlaqə yaratmaq üçün, ikincisi isə fiziki əlaqə yaratmaq üçün istifadə olunur. Bütün bunlar haqqında daha sonra, lakin hələlik xatırlamaq vacibdir ki, WebRTC bizə başqa bir node ötürülməsi lazım olan bəzi məlumatları verəcəkdir. Bütün lazımi məlumatları ötürən kimi qovşaqlar qoşula biləcək və bizim köməyimizə ehtiyac qalmayacaq. Beləliklə, siqnal mexanizmini həyata keçirməliyik ayrıca, istifadə olunacaq yalnız qoşulduqda, və video məlumatlarını ötürərkən istifadə edilməyəcək.

Beləliklə, birinci mərhələyə, əlaqənin qurulması mərhələsinə baxaq. Bir neçə maddədən ibarətdir. Bu mərhələni əvvəlcə əlaqəni başlatan qovşaq üçün, sonra isə gözləyən üçün nəzərdən keçirin.

• Təşəbbüskar (zəng edən - zəng edən):
• Video məlumat ötürülməsinə başlamaq təklifi (createOffer)
• SDP SDP-ni əldə edin)
• Buz namizədinizi əldə edirsiniz)
• Zəng gözləyən (zəng edən):
• Yerli (öz) media axını əldə etmək və onu ötürmə üçün qurmaq (getUserMediaStream)
• Video məlumat ötürülməsinə başlamaq və cavab yaratmaq (createAnswer) təklifi alın
• SDP obyektinizi əldə edin və onu siqnal mexanizmindən (SDP) keçirin
• Buz namizədinin obyektlərini qəbul etmək və onları siqnal mexanizmindən ötürmək (Buz namizədi)
• Uzaqdan (xarici) media axını qəbul etmək və onu ekranda göstərmək (onAddStream)

Yeganə fərq ikinci paraqrafdadır.

Addımların görünən mürəkkəbliyinə baxmayaraq, əslində bunlardan üçü var: öz media axınınızı göndərmək (səh. 1), əlaqə parametrlərini təyin etmək (s. 2-4), başqasının media axınını qəbul etmək (s. 5). Ən çətini ikinci addımdır, çünki o, iki hissədən ibarətdir: qurmaq fiziki Və məntiqiəlaqələri. Birincisi göstərir yol, bir şəbəkə qovşağından digərinə keçmək üçün paketlərin getməsi lazımdır. İkincisi göstərir video/audio parametrləri- hansı keyfiyyətdən istifadə etmək, hansı kodeklərdən istifadə etmək.

Zehni olaraq, createOffer və ya createAnswer mərhələsi SDP və Ice namizəd obyektlərinin keçmə mərhələləri ilə əlaqələndirilməlidir.

Əsas obyektlər Media axınları (MediaStream)

Əsas varlıq media axınıdır, yəni video və audio məlumatların, şəkil və səslərin axınıdır. Media axınının iki növü var - yerli və uzaqdan. Yerli məlumat giriş cihazlarından (kamera, mikrofon), uzaqdan isə şəbəkə üzərindən məlumat alır. Beləliklə, hər bir node həm yerli, həm də uzaq bir ipə malikdir. WebRTC-də axınlar üçün MediaStream interfeysi və yerli axın üçün xüsusi olaraq LocalMediaStream alt interfeysi də mövcuddur. JavaScript-də siz yalnız birinci ilə qarşılaşa bilərsiniz və libjingle istifadə edirsinizsə, ikinci ilə də qarşılaşa bilərsiniz.

WebRTC-də bir axın içərisində olduqca qarışıq bir iyerarxiya var. Hər bir axın bir neçə media trekindən (MediaTrack) ibarət ola bilər, bu da öz növbəsində bir neçə media kanalından (MediaChannel) ibarət ola bilər. Özü də bir neçə media axını ola bilər.

Gəlin hər şeyi qaydasında nəzərdən keçirək. Bunu etmək üçün bəzi nümunələri xatırlayaq. Deyək ki, biz təkcə özümüzün deyil, üzərində nə isə yazacağımız kağız parçasının uzanan süfrəmizin videosunu da ötürmək istəyirik. Bizə iki video (biz + masa) və bir audio (biz) lazımdır. Aydındır ki, biz və cədvəl müxtəlif mövzulara bölünməlidir, çünki bu məlumatlar, ehtimal ki, bir-birindən zəif asılıdır. Buna görə də, iki MediaStream 'a olacaq - biri bizim üçün, biri isə masa üçün. Birincisi həm video, həm də audio məlumatları, ikincisi isə yalnız videodan ibarət olacaq (Şəkil 4).

Şəkil 4: İki fərqli media axını. Biri bizim üçün, biri süfrəmiz üçün

Dərhal aydın olur ki, media axını ən azı məlumatları ehtiva etmə qabiliyyətini ehtiva etməlidir fərqli növlər- video və audio. Bu texnologiyada nəzərə alınır və buna görə də hər bir məlumat növü media track vasitəsilə həyata keçirilir MediaTrack . Media treki qarşımızda video və ya audionun olub olmadığını müəyyən edən xüsusi xüsusiyyət növünə malikdir (Şəkil 5)

Şəkil 5: Media axınları media treklərindən ibarətdir

Proqramda hər şey necə olacaq? İki media axını yaradacağıq. Sonra iki video trek və bir audio trek yaradacağıq. Gəlin kameralara və mikrofona giriş əldə edək. Gəlin hər trekə hansı cihazın istifadə olunacağını söyləyək. Gəlin birinci media axınına video və audio treki, ikinci media axınına isə başqa kameradan video treki əlavə edək.

Bəs əlaqənin digər ucunda media axınlarını necə ayırd edək? Bunun üçün hər bir media axınının etiket xüsusiyyəti var - axının etiketi, onun adı (Şəkil 6). Media trekləri eyni xüsusiyyətə malikdir. Baxmayaraq ki, ilk baxışdan videonu səsdən başqa cəhətlərə görə ayırmaq olar.

Şəkil 6: Media axınları və treklər etiketlərlə müəyyən edilir

Beləliklə, əgər media izləri bir etiket vasitəsilə müəyyən edilə bilərsə, onda niyə nümunəmiz üçün bir əvəzinə iki media axını istifadə etməliyik? Axı, bir media axını ötürə və orada müxtəlif yollardan istifadə edə bilərsiniz. Biz media axınlarının vacib bir xüsusiyyətinə gəldik - onlar sinxronlaşdırın media izləri. Müxtəlif media axınları bir-biri ilə sinxronlaşdırılmır, lakin hər bir media axını daxilində bütün musiqilər eyni vaxtda ifa olunurdu.

Beləliklə, sözümüzün, üzümüzdəki duyğularımızın və kağız parçamızın eyni vaxtda səsləndirilməsini istəyiriksə, bir media axınından istifadə etməyə dəyər. Bu o qədər də vacib deyilsə, o zaman müxtəlif axınlardan istifadə etmək daha sərfəlidir - şəkil daha hamar olacaq.

Əgər ötürülmə zamanı treki deaktiv etmək lazımdırsa, siz aktivləşdirilmiş media treki xüsusiyyətindən istifadə edə bilərsiniz.

Sonda stereo səs haqqında düşünməlisiniz. Bildiyiniz kimi, stereo səs iki fərqli səsdir. Həm də onları ayrıca göndərmək lazımdır. Bunun üçün MediaChannels istifadə olunur. Audio media treki bir çox kanala malik ola bilər (məsələn, 5+1 audio lazımdırsa, 6). Media trekinin içərisində, kanallar da təbii ki sinxronlaşdırılmışdır. Video üçün adətən yalnız bir kanal istifadə olunur, lakin bir neçə, məsələn, reklam örtükləri üçün istifadə edilə bilər.

Xülasə etmək üçün: video və audio məlumatlarını ötürmək üçün media axınından istifadə edirik. Hər bir media axını daxilində məlumatlar sinxronlaşdırılır. Sinxronizasiyaya ehtiyacımız yoxdursa, bir neçə media axınından istifadə edə bilərik. Hər bir media axınında iki növ media treki var - video və audio üçün. Adətən ikidən çox musiqi yoxdur, lakin bir neçə fərqli videonu (həmsöhbətin və onun masasının) köçürmək lazımdırsa, daha çox ola bilər. Hər bir trek adətən yalnız stereo səs üçün istifadə olunan bir neçə kanaldan ibarət ola bilər.

Ən sadə videoçat vəziyyətində iki trekdən ibarət olan bir yerli media axınımız olacaq - hər biri bir əsas kanaldan ibarət olacaq video trek və audio trek. Video trek kameraya, audio treki mikrofona, media axını isə hər ikisinin konteynerinə cavabdehdir.

Sessiya Deskriptoru (SDP)

Fərqli kompüterlərdə həmişə fərqli kameralar, mikrofonlar, video kartlar və digər avadanlıqlar olacaq. Onların çoxlu variantları var. Bütün bunlar iki şəbəkə qovşağı arasında media məlumatlarının ötürülməsi üçün əlaqələndirilməlidir. WebRTC bunu avtomatik edir və yaradır xüsusi obyekt– SDP sessiya deskriptoru. Bu obyekti başqa qovşaqlara ötürün və siz media məlumatlarını göndərə bilərsiniz. Yalnız başqa bir node ilə əlaqə hələ yoxdur.

Bunun üçün istənilən siqnal mexanizmindən istifadə olunur. SDP hətta rozetkalar vasitəsilə, hətta bir şəxs tərəfindən ötürülə bilər (telefonla başqa bir qovşağa deyin), hətta Rusiya Postu ilə. Hər şey çox sadədir - sizə hazır SDP veriləcək və onu göndərməlisiniz. Digər tərəfdən alındıqdan sonra onu WebRTC şöbəsinə köçürün. Sessiya dəstəyi mətn kimi saxlanılır və siz onu tətbiqlərinizdə dəyişə bilərsiniz, lakin adətən buna ehtiyac yoxdur. Məsələn, masa üstü↔telefonu birləşdirərkən bəzən istədiyiniz audio kodek seçimini məcbur etmək lazımdır.

Adətən, əlaqə qurarkən, URL kimi bir növ ünvan göstərməlisiniz. Burada buna ehtiyac yoxdur, çünki siz özünüz məlumatı siqnal mexanizmi vasitəsilə təyinat yerinə göndərəcəksiniz. WebRTC-yə p2p bağlantısı qurmaq istədiyimizi bildirmək üçün createOffer funksiyasını çağırmalıyıq. Bu funksiyanı çağırdıqdan və ona xüsusi geri çağırış 'a verdikdən sonra SDP obyekti yaradılacaq və eyni geri çağırışa ötürüləcək. Sizdən tələb olunan tək şey bu obyekti şəbəkə üzərindən başqa bir node (həmsöhbət) ötürməkdir. Bundan sonra, digər tərəfdən, məlumatlar siqnal mexanizmi, yəni bu SDP obyekti vasitəsilə gələcək. Bu sessiya deskriptoru bu node üçün yaddır və ona görə də faydalı məlumat daşıyır. Bu obyektin qəbulu əlaqəni başlamaq üçün bir siqnaldır. Buna görə də siz bununla razılaşmalı və createAnswer funksiyasını çağırmalısınız. Bu createOffer-in tam analoqudur. Yenə də yerli sessiya idarəsi geri zənginizə ötürüləcək və geri siqnal verilməlidir.

Qeyd etmək lazımdır ki, createAnswer funksiyasını yalnız başqasının SDP obyektini aldıqdan sonra çağıra bilərsiniz. Niyə? Çünki createAnswer çağırıldıqda yaradılacaq yerli SDP obyekti uzaq SDP obyektinə etibar etməlidir. Yalnız bu halda video parametrlərinizi həmsöhbətin parametrləri ilə əlaqələndirmək mümkündür. Həmçinin, yerli media axını əldə etməzdən əvvəl createAnswer və createOffer çağırmayın - onların SDP obyektinə yazmaq üçün heç nələri olmayacaq.

WebRTC bir SDP obyektini redaktə etmək imkanına malik olduğundan, yerli deskriptoru aldıqdan sonra o, quraşdırılmalıdır. WebRTC-nin bizə verdiyini ötürməsi bir az qəribə görünə bilər, amma protokol belədir. Uzaqdan tutacaq aldıqda, onu da təyin etməlisiniz. Buna görə, bir node üzərində iki deskriptor quraşdırmalısınız - öz və başqasının (yəni yerli və uzaq).

Belədən sonra əl sıxma qovşaqlar bir-birinin istəklərini bilirlər. Məsələn, 1 node A və B kodeklərini, 2 node B və C kodeklərini dəstəkləyirsə, hər bir qovşaq özünün və digərinin deskriptorlarını bildiyi üçün hər iki qovşaq B kodekini seçəcək (Şəkil 7). İndi əlaqə məntiqi qurulub və media axınları ötürülə bilər, lakin başqa bir problem var - qovşaqlar hələ də yalnız siqnal mexanizmi ilə bağlıdır.

Şəkil 7: Codec danışıqları

Namizədlər (Buz namizədi)

WebRTC texnologiyası yeni metodologiyası ilə bizi çaşdırmağa çalışır. Bağlantı qurarkən, qoşulmaq istədiyiniz node ünvanı göstərilmir. Əvvəlcə quraşdırılmışdır məntiqiəlaqə, yox fiziki, baxmayaraq ki, bunun əksi həmişə olub. Ancaq üçüncü tərəfin siqnal mexanizmindən istifadə etdiyimizi unutmasaq, bu qəribə görünməyəcək.

Beləliklə, əlaqə artıq qurulmuşdur (məntiqi əlaqə), lakin şəbəkə qovşaqlarının məlumat ötürməsi üçün hələ bir yol yoxdur. Hər şey o qədər də sadə deyil, amma sadədən başlayaq. Qoy qovşaqlar eyni şəxsi şəbəkədə olsun. Artıq bildiyimiz kimi, onlar daxili IP ünvanlarından (və ya TCP/IP istifadə etmirsə, başqaları) istifadə edərək asanlıqla bir-birlərinə qoşula bilərlər.

Bəzi geri çağırışlar və WebRTC vasitəsilə bizə Ice namizəd obyektləri deyir. Onlar həmçinin mətn şəklində gəlirlər və sessiya deskriptorlarında olduğu kimi, sadəcə siqnal mexanizmi vasitəsilə göndərilməlidirlər. Əgər sessiya deskriptorunda kamera və mikrofon səviyyəsində parametrlərimiz haqqında məlumat var idisə, namizədlər şəbəkədəki yerimiz haqqında məlumatı ehtiva edir. Onları başqa bir qovşağa keçirin və o, fiziki olaraq bizimlə əlaqə qura biləcək və onun artıq sessiya deskriptoru olduğu üçün məntiqi olaraq qoşula bilər və məlumatlar "axınacaq". Əgər o, bizə öz namizəd obyektini, yəni şəbəkədə harada olması barədə məlumat göndərməyi unutmasa, o zaman onunla əlaqə saxlaya biləcəyik. Biz burada klassik müştəri-server qarşılıqlı əlaqəsindən daha bir fərqi qeyd edirik. HTTP serveri ilə əlaqə sorğu-cavab sxeminə uyğun olaraq baş verir, müştəri məlumatları onu emal edən və vasitəsilə göndərən serverə göndərir. sorğu paketində göstərilən ünvan. WebRTC-də bilmək lazımdır iki ünvan və onları hər iki tərəfdən birləşdirin.

Sessiya tutacaqlarından fərq ondan ibarətdir ki, yalnız uzaq namizədlər təyin edilməlidir. Burada redaktə etmək qadağandır və heç bir fayda gətirə bilməz. Bəzi WebRTC tətbiqlərində namizədlər yalnız sessiya tutacaqları təyin edildikdən sonra təyin edilməlidir.

Və niyə yalnız bir sessiya deskriptoru var idi, amma bir çox namizəd ola bilər? Çünki şəbəkədəki yer təkcə onun daxili IP ünvanı ilə deyil, həm də marşrutlaşdırıcının xarici ünvanı ilə müəyyən edilə bilər və mütləq bir deyil, həm də TURN serverlərinin ünvanları ilə müəyyən edilə bilər. Paraqrafın qalan hissəsi namizədlərin ətraflı müzakirəsinə və müxtəlif özəl şəbəkələrdən qovşaqların necə birləşdiriləcəyinə həsr olunacaq.

Beləliklə, iki qovşaq eyni şəbəkədədir (Şəkil 8). Onları necə müəyyən etmək olar? IP ünvanlarından istifadə. Başqa yol yoxdur. Düzdür, siz hələ də müxtəlif nəqliyyatlardan (TCP və UDP) və müxtəlif portlardan istifadə edə bilərsiniz. Bu, namizəd obyektində olan məlumatlardır - IP, PORT, TRANSPORT və digərləri. Məsələn, UDP nəqliyyatından və 531 portundan istifadə edək.

Şəkil 8: İki qovşaq eyni şəbəkədədir

Sonra, əgər biz p1 qovşağındayıqsa, onda WebRTC bizə belə bir namizəd obyekti keçir - . Bu dəqiq format deyil, sadəcə diaqramdır. Əgər biz p2 qovşağındayıqsa, o zaman namizəd - olur. Siqnal mexanizmi vasitəsilə p1 namizəd p2 əldə edəcək (yəni p2 nodeunun yeri, yəni onun IP və PORT ). Sonra p1 birbaşa p2-yə qoşula bilər. Daha doğrusu, p1 məlumatı p2-ə çatacağı ümidi ilə 10.50.150.3:531-ə göndərəcək. Bu ünvanın p2 qovşağına və ya hansısa vasitəçiyə aid olmasının fərqi yoxdur. Yeganə vacib olan odur ki, məlumat bu ünvan vasitəsilə göndəriləcək və p2-ə çata bilər.

Nə qədər ki, qovşaqlar eyni şəbəkədədir - hər şey sadə və asandır - hər bir node yalnız bir namizəd obyektinə malikdir (həmişə özünün, yəni şəbəkədəki yerini bildirir). Ancaq qovşaqlar daxil olduqda daha çox namizəd olacaq fərqlişəbəkələr.

Gəlin daha mürəkkəb bir işə keçək. Bir qovşaq marşrutlaşdırıcının arxasında (daha doğrusu, NAT-ın arxasında), ikinci node isə bu marşrutlaşdırıcı ilə eyni şəbəkədə (məsələn, İnternetdə) olacaq (Şəkil 9).

Şəkil 9: NAT-ın arxasında bir host, digəri yox

Bu işin indi nəzərdən keçirdiyimiz problemin xüsusi həlli var. ev marşrutlaşdırıcısı adətən NAT cədvəlini ehtiva edir. Bu, marşrutlaşdırıcının şəxsi şəbəkəsindəki qovşaqlara, məsələn, veb-saytlara daxil olmaq üçün nəzərdə tutulmuş xüsusi mexanizmdir.

Tutaq ki, veb-server birbaşa İnternetə bağlıdır, yəni ictimai IP * ünvanına malikdir. Bu p2 node olsun. Node p1 (veb müştəri) 10.50.200.10-a sorğu göndərir. Birincisi, məlumatlar r1 marşrutlaşdırıcısına, daha doğrusu ona daxil olur daxili interfeys 192.168.0.1. Bundan sonra, marşrutlaşdırıcı mənbə ünvanını (ünvan p1) xatırlayır və onu xüsusi NAT cədvəlinə daxil edir, sonra mənbə ünvanını özünə dəyişir (p1 → r1). Bundan əlavə, görə xarici interfeys, marşrutlaşdırıcı məlumatları birbaşa p2 veb serverinə göndərir. Veb server məlumatları emal edir, cavab yaradır və geri göndərir. R1-i marşrutlaşdırıcıya göndərir, çünki qayıdış ünvanında olan odur (router ünvanı özünə dəyişdirdi). Router məlumatları qəbul edir, NAT cədvəlinə baxır və məlumatları p1-ə yönləndirir. Router burada vasitəçi kimi çıxış edir.

Bəs daxili şəbəkədən bir neçə qovşaq eyni vaxtda xarici şəbəkəyə daxil olarsa necə? Router cavabı kimə göndərəcəyini necə başa düşəcək? Bu problem ilə həll olunur limanlar. Router host ünvanını özününki ilə əvəz etdikdə o, portu da əvəz edir. İki qovşaq İnternetə daxil olarsa, marşrutlaşdırıcı onların mənbə portlarını ilə əvəz edir fərqli. Sonra, veb serverdən gələn paket marşrutlaşdırıcıya qayıtdıqda, marşrutlaşdırıcı bu paketin təyin olunduğu portu başa düşəcəkdir. Bir nümunə aşağıdadır.

Qayıdaq WebRTC texnologiyasına, daha doğrusu onun ICE protokolundan istifadə edən hissəsinə (buna görə də Ice namizədləri). p2 qovşağının bir namizədi var (şəbəkədə yeri 10.50.200.10 ) və NAT marşrutlaşdırıcısının arxasında olan p1 nodeunun iki namizədi olacaq - yerli (192.168.0.200 ) və marşrutlaşdırıcı namizəd (10.50.200.5 ) . Birincisi faydalı deyil, lakin buna baxmayaraq yaradılıb, çünki WebRTC hələ uzaq host haqqında heç nə bilmir - o, eyni şəbəkədə ola bilər və ya olmaya da bilər. İkinci namizəd lazımlı olacaq və artıq bildiyimiz kimi, liman mühüm rol oynayacaq (NAT-dan keçmək üçün ).

NAT cədvəlindəki giriş yalnız verilənlər daxili şəbəkədən çıxdıqda yaradılır. Buna görə də, p1 qovşağı ilk olaraq məlumatları ötürməlidir və yalnız bundan sonra p2 qovşağının məlumatları p1 qovşağına çata bilər.

Təcrübədə hər iki qovşaq NAT-ın arxasında olacaq. Hər bir marşrutlaşdırıcının NAT cədvəlində giriş yaratmaq üçün hostlar uzaq hosta nəsə göndərməlidirlər, lakin bu dəfə nə birincisi sonuncuya çata bilər, nə də əksinə. Bu, qovşaqların öz xarici IP ünvanlarını bilməməsi ilə əlaqədardır və məlumatların daxili ünvanlara göndərilməsi mənasızdır.

Ancaq xarici ünvanlar məlumdursa, o zaman əlaqə asanlıqla qurulacaq. Birinci qovşaq məlumatı ikinci nodun marşrutlaşdırıcısına göndərirsə, NAT cədvəli hələ də boş olduğu üçün marşrutlaşdırıcı onlara məhəl qoymayacaq. Bununla belə, birinci nodun marşrutlaşdırıcısında NAT cədvəlində bir giriş meydana çıxdı. Əgər indi ikinci qovşaq məlumatı birinci qovşağın marşrutlaşdırıcısına göndərirsə, onda marşrutlaşdırıcı onları uğurla birinci qovşağa ötürəcək. İndi ikinci marşrutlaşdırıcının NAT cədvəlində lazımi məlumatlar var.

Problem ondadır ki, xarici IP ünvanınızı tapmaq üçün sizə burada yerləşən host lazımdır ümumi şəbəkə. Bu problemi həll etmək üçün birbaşa İnternetə qoşulmuş əlavə serverlərdən istifadə olunur. Onların köməyi ilə NAT cədvəlində dəyərli qeydlər də yaradılır.

STUN və TURN serverləri

WebRTC-ni işə salarkən, gələcəkdə ICE serverləri adlandıracağımız mövcud STUN və TURN serverlərini göstərməlisiniz. Əgər serverlər göstərilməyibsə, onda yalnız eyni şəbəkədəki qovşaqlar (NAT olmadan ona qoşulmuş) qoşula biləcəklər. Dərhal qeyd etmək lazımdır ki, 3G şəbəkələri üçün TURN serverlərinin istifadəsi məcburidir.

SUN server sadəcə olaraq İnternetdə bir serverdir ki, o, qaytarma ünvanını, yəni göndərənin hostunun ünvanını qaytarır. Routerin arxasındakı host NAT-dan keçmək üçün STUN serveri ilə əlaqə saxlayır. STUN serverinə gələn paketdə mənbə ünvanı - marşrutlaşdırıcının ünvanı, yəni qovşağımızın xarici ünvanı var. STUN serveri bu ünvanı geri göndərir. Beləliklə, qovşaq öz xarici IP ünvanını və şəbəkədən daxil olduğu portu alır. Sonra, WebRTC bu ünvandan əlavə namizəd yaratmaq üçün istifadə edir (routerin xarici ünvanı və port). İndi marşrutlaşdırıcının NAT cədvəlində lazımi portdakı marşrutlaşdırıcıya göndərilən paketləri hostumuza ötürən bir giriş var.

Bu prosesə bir nümunə ilə baxaq.

Nümunə (STUN server əməliyyatı)

STUN serveri s1 ilə işarələnəcək. Router, əvvəlki kimi, r1 vasitəsilə, node isə p1 vasitəsilə. NAT cədvəlinə də nəzarət etmək lazım olacaq - biz onu r1_nat kimi qeyd edəcəyik. Üstəlik, bu cədvəl adətən müxtəlif alt şəbəkə qovşaqlarından çoxlu girişləri ehtiva edir - onlar verilməyəcək.

Beləliklə, başlanğıcda boş bir cədvəlimiz var r1_nat .

Cədvəl 2: Paket başlığı

Host p1 bu paketi r1 marşrutlaşdırıcısına göndərir (necə olursa olsun, müxtəlif alt şəbəkələrdə istifadə edilə bilər müxtəlif texnologiyalar). Router mənbə ünvanını dəyişdirməlidir Src IP , çünki paketdə göstərilən ünvan açıq şəkildə xarici alt şəbəkə üçün uyğun deyil, üstəlik, bu diapazondan ünvanlar qorunur və İnternetdə heç bir ünvanda belə bir ünvan yoxdur. Router paketdə bir əvəz edir və yaradır yeni rekord masanızda r1_nat . Bunun üçün o, port nömrəsi ilə çıxış etməlidir. Xatırladaq ki, alt şəbəkə daxilində bir neçə host xarici şəbəkəyə daxil ola bildiyi üçün NAT cədvəli saxlamalıdır əlavə informasiya beləliklə, marşrutlaşdırıcı serverdən qaytarılan paketin bu bir neçə hostdan hansı üçün nəzərdə tutulduğunu müəyyən edə bilsin. Router 888 portu ilə çıxış etsin.

Paket başlığı dəyişdirildi:

Cədvəl 4: NAT cədvəli yeni girişlə yeniləndi

Burada alt şəbəkə üçün IP ünvanı və port orijinal paketlə tam olaraq eynidir. Həqiqətən, geri göndərmə zamanı onları tamamilə bərpa etmək üçün bir yolumuz olmalıdır. Xarici şəbəkə üçün IP ünvanı marşrutlaşdırıcının ünvanıdır və port marşrutlaşdırıcı tərəfindən icad edilənə dəyişdi.

P1-in əlaqəni qəbul etdiyi real port, əlbəttə ki, 35777-dir, lakin server məlumat göndərir. uydurma marşrutlaşdırıcı tərəfindən real 35777 ilə dəyişdiriləcək port 888.

Beləliklə, marşrutlaşdırıcı paket başlığında mənbə ünvanını və portunu dəyişdirdi və NAT cədvəlinə bir giriş əlavə etdi. İndi paket şəbəkə üzərindən serverə, yəni s1 nodeuna göndərilir. Girişdə s1 bu paketə malikdir:

Src IP Src PORT Hədəf IP Hədəf PORT

10.50.200.5	888	12.62.100.200	6000

Cədvəl 5: STUN serveri paket qəbul etdi

Ümumilikdə STUN serveri 10.50.200.5:888 ünvanından paket qəbul etdiyini bilir. İndi server bu ünvanı geri göndərir. Burada dayanıb indi düşündüklərimizə yenidən nəzər salmağa dəyər. Yuxarıdakı cədvəllər bir hissəsidir başlıq paketi, ümumiyyətlə ondan deyil məzmun. Məzmun haqqında danışmadıq, çünki o qədər də vacib deyil - bu, STUN protokolunda bir şəkildə təsvir edilmişdir. İndi başlığa əlavə olaraq məzmunu da nəzərdən keçirəcəyik. Sadə olacaq və marşrutlaşdırıcının ünvanını ehtiva edəcək - 10.50.200.5:888, baxmayaraq ki, biz onu götürdük. başlıq paket. Bu, tez-tez edilmir, adətən protokollar qovşaqların ünvanları haqqında məlumatlara əhəmiyyət vermir, yalnız paketlərin təyinat yerinə çatdırılması vacibdir. Burada iki qovşaq arasında yol quran protokolu nəzərdən keçiririk.

Beləliklə, indi əks istiqamətdə gedən ikinci partiyamız var:

Cədvəl 7: STUN serveri bu məzmunlu paket göndərir

Sonra, paket r1 marşrutlaşdırıcısının xarici interfeysinə çatana qədər şəbəkədən keçir. Router paketin onun üçün nəzərdə tutulmadığını başa düşür. Bunu necə başa düşür? Bu, yalnız liman tərəfindən tapıla bilər. O, 888 portunu şəxsi məqsədləri üçün istifadə etmir, NAT mexanizmi üçün istifadə edir. Buna görə də, marşrutlaşdırıcı bu cədvələ baxır. Xarici PORT sütununa baxır və gələn paketdən Hədəf PORT-a uyğun gələn xətti axtarır, yəni 888 .

Daxili IP Daxili PORT Xarici IP Xarici PORT

192.168.0.200	35777	10.50.200.5	888

Cədvəl 8: NAT cədvəli

Bəxtim gətirdi ki, belə bir xətt var. Əgər şanslı olmasaydı, paket sadəcə atılacaqdı. İndi alt şəbəkə qovşaqlarından hansının bu paketi göndərməli olduğunu başa düşməlisiniz. Gəlin tələsməyək, bu mexanizmdə limanların əhəmiyyətini təkrarlayaq. Eyni zamanda, alt şəbəkədəki iki qovşaq xarici şəbəkəyə sorğu göndərə bilər. Sonra, əgər birinci node üçün marşrutlaşdırıcı 888 portu ilə gəldisə, ikincisi üçün 889 portu ilə gələcək. Tutaq ki, bu baş verib, yəni r1_nat cədvəli belə görünür:

Cədvəl 10: Marşrutlaşdırıcının aldadıcısının ünvanı

Src IP Src PORT Hədəf IP Hədəf PORT

12.62.100.200	6000	192.168.0.200	35777

Cədvəl 11: Router qəbuledici ünvanını dəyişdi

Paket p1 qovşağına uğurla çatır və paketin məzmununa baxdıqdan sonra qovşaq özünün xarici IP ünvanını, yəni marşrutlaşdırıcının xarici şəbəkədəki ünvanını öyrənir. O, marşrutlaşdırıcının NAT-dan keçdiyi portu da bilir.

Sonra nə var? Bütün bunların nə faydası var? Fayda r1_nat cədvəlindəki girişdir. Əgər indi kimsə 888 portu olan r1 marşrutlaşdırıcısına paket göndərirsə, o zaman marşrutlaşdırıcı bu paketi p1 qovşağına yönləndirəcək. Beləliklə, p1 gizli node üçün kiçik bir dar keçid yaradıldı.

Yuxarıdakı nümunədən NAT-ın necə işlədiyi və STUN serverinin mahiyyəti haqqında bir fikir əldə edə bilərsiniz. Ümumiyyətlə, serverin ICE mexanizmi və STUN / TURN yalnız NAT məhdudiyyətlərini aradan qaldırmağa yönəlmişdir.

Node və server arasında birdən çox marşrutlaşdırıcı ola bilər, lakin bir neçə. Bu halda, node serverlə eyni şəbəkəyə ilk daxil olan marşrutlaşdırıcının ünvanını alacaq. Başqa sözlə, STUN serverinə qoşulmuş marşrutlaşdırıcının ünvanını alacağıq. Hər bir marşrutlaşdırıcıda bizə lazım olan xəttin NAT cədvəlinə əlavə ediləcəyini unutmasaq, p2p rabitəsi üçün məhz bu bizə lazımdır. Beləliklə, geri dönüş yolu yenə hamar olacaq.

TURN server təkmilləşdirilmiş STUN serveridir. Buradan dərhal çıxarılmalıdır ki, istənilən TURN serveri STUN serveri kimi də işləyə bilər. Bununla belə, faydaları da var. Əgər p2p rabitəsi mümkün deyilsə (məsələn, 3g şəbəkələrində olduğu kimi), o zaman server relay rejiminə (relay) keçir, yəni vasitəçi kimi işləyir. Əlbəttə ki, biz o zaman hər hansı p2p-dən danışmırıq, lakin ICE mexanizmindən kənarda qovşaqlar birbaşa əlaqə saxladıqlarını düşünürlər.

TURN serverinə nə vaxt ehtiyac var? STUN server niyə yoxdur? Fakt budur ki, NAT-ın bir neçə növü var. IP ünvanını və portunu eyni şəkildə əvəz edirlər, lakin bəzilərində "saxtalaşmaya" qarşı daxili əlavə qorunma var. Məsələn, in simmetrik NAT cədvəlində daha 2 parametr saxlanılır - IP və uzaq hostun portu. Xarici şəbəkədən gələn paket NAT-dan daxili şəbəkəyə yalnız o halda keçir ki, mənbə ünvanı və port cədvəldə qeyd olunanlara uyğun olsun. Buna görə də, STUN serveri ilə hiylə uğursuz olur - NAT cədvəli STUN serverinin ünvanını və portunu saxlayır və marşrutlaşdırıcı WebRTC həmsöhbətindən paket aldıqda, "saxta" olduğundan onu rədd edir. O, STUN serverindən gəlməyib.

Beləliklə, hər iki həmsöhbət arxada olduqda TURN server lazımdır simmetrik NAT (hər biri özü üçün).

Qısa xülasə

WebRTC qurumları haqqında həmişə yadda saxlamalı olduğunuz bəzi ifadələr bunlardır. Onlar yuxarıda ətraflı təsvir edilmişdir. Əgər ifadələrdən hər hansı biri sizə tam aydın görünmürsə, müvafiq paraqrafları yenidən oxuyun.

• media axını
  • Video və audio məlumatları media axınlarına yığılır
  • Media axınları təşkil edən media yollarını sinxronlaşdırır
  • Müxtəlif media axınları sinxronlaşdırılmayıb
  • Media axınları yerli və uzaq ola bilər, kamera və mikrofon adətən yerli birinə qoşulur, uzaq olanlar şəbəkədən məlumatları şifrələnmiş formada alırlar.
  • İki növ media treki var - video və audio üçün.
  • Media trekləri yandırmaq/söndürmək imkanına malikdir
  • Media trekləri media kanallarından ibarətdir
  • Media trekləri təşkil edən media kanallarını sinxronlaşdırır
  • Media axınları və media trekləri fərqləndirilə bilən etiketlərə malikdir
• Sessiya tutacağı
  • Sessiya deskriptoru iki şəbəkə qovşağını məntiqi birləşdirmək üçün istifadə olunur
  • Sessiya deskriptoru haqqında məlumatları saxlayır mövcud yollar video və audio məlumatların kodlaşdırılması
  • WebRTC xarici siqnal mexanizmindən istifadə edir - sessiya deskriptorlarının (sdp) yönləndirilməsi vəzifəsi tətbiqin üzərinə düşür
  • Məntiqi əlaqə mexanizmi iki mərhələdən ibarətdir - təklif (təklif) və cavab (cavab)
  • Sessiya deskriptorunun yaradılması təklif (təklif) olduqda yerli media axınından istifadə etmədən mümkün deyil və cavab (cavab) olduqda isə uzaqdan sessiya deskriptorundan istifadə etmədən mümkün deyil.
  • Qəbul edilmiş deskriptor WebRTC tətbiqinə verilməlidir və bu deskriptorun eyni WebRTC tətbiqindən uzaqdan və ya yerli olaraq qəbul edilməsinin fərqi yoxdur
  • Sessiya deskriptorunu bir az redaktə etmək mümkündür
• Namizədlər
  • Namizəd (Buz namizədi) şəbəkədəki qovşağın ünvanıdır
  • Düyün ünvanı sizin özünüz ola bilər və ya marşrutlaşdırıcının və ya TURN serverinin ünvanı ola bilər
  • Namizədlər həmişə çox olur
  • Namizəd IP ünvanı, port və nəqliyyat növündən (TCP və ya UDP) ibarətdir
  • Namizədlər şəbəkədəki iki qovşaq arasında fiziki əlaqə yaratmaq üçün istifadə olunur
  • Namizədlər də siqnal mexanizmi vasitəsilə göndərilməlidir
  • Namizədlər WebRTC tətbiqlərini də keçməlidirlər, lakin yalnız uzaqdan
  • Bəzi WebRTC tətbiqlərində namizədlər yalnız sessiya sapı təyin edildikdən sonra keçə bilər.
• SUN/DÖNÜŞ/BUZ/NAT
  • NAT - xarici şəbəkəyə çıxışı təmin edən mexanizm
  • Ev marşrutlaşdırıcıları xüsusi NAT cədvəlini dəstəkləyir
  • Router paketlərdəki ünvanları əvəz edir - paket xarici şəbəkəyə getdiyi təqdirdə mənbə ünvanını özü ilə, paket xarici şəbəkədən gələrsə, qəbuledicinin ünvanını isə daxili şəbəkədəki host ünvanı ilə əvəz edir.
  • Xarici şəbəkəyə çoxkanallı çıxışı təmin etmək üçün NAT portlardan istifadə edir
  • ICE bir NAT keçid mexanizmidir
  • STUN və TURN serverləri NAT-dan yan keçmək üçün köməkçi serverlərdir
  • STUN server NAT cədvəlində lazımi qeydləri yaratmağa imkan verir, həmçinin hostun xarici ünvanını qaytarır.
  • TURN serveri STUN mexanizmini ümumiləşdirir və onun həmişə işləməsini təmin edir
  • Ən pis hallarda TURN serveri vasitəçi (relay) kimi istifadə olunur, yəni p2p müştəri-server-müştəri əlaqəsinə çevrilir.

Bu gün WebRTC brauzerlərdə audio və video axını üçün "qaynar" texnologiyadır. HTTP Streaming və Flash kimi mühafizəkar texnologiyalar qeydə alınmış məzmunun (tələb üzrə video) yayılması üçün daha uyğundur və real vaxt və onlayn yayımlar baxımından WebRTC-dən əhəmiyyətli dərəcədə aşağıdır, yəni. minimal video gecikmə tələb olunduğu yerlərdə, izləyicilərə baş verənləri "canlı" görməyə imkan verir.

Yüksək keyfiyyətli real vaxt rabitəsi imkanı WebRTC arxitekturasının özündən irəli gəlir, burada UDP protokolu video axınlarının nəqli üçün istifadə olunur, bu, videonun minimal gecikmələrlə ötürülməsi üçün standart əsasdır və real vaxt rejimində rabitə sistemlərində geniş istifadə olunur.

Video mənbəyi, son istifadəçilər və həll yolu ilə interaktiv ünsiyyətin tələb olunduğu canlı yayım sistemlərində, vebinarlarda və digər tətbiqlərdə ünsiyyət gecikməsi vacibdir.

WebRTC-ni sınamaq üçün başqa bir yaxşı səbəb mütləq bir tendensiyadır. Bu gün hər Android Chrome brauzeri milyonlarla cihazın heç bir əlavə proqram və konfiqurasiya quraşdırmadan yayımı izləməyə hazır olmasını təmin edən bu texnologiyanı dəstəkləyir.

WebRTC texnologiyasını işlək sınaqdan keçirmək və onun üzərində sadə onlayn yayıma başlamaq üçün biz Flashphoner WebRTC Media və Yayım Server server proqramından istifadə etdik. Xüsusiyyətlər, WebRTC axınlarını birdən çox rejimində yayımlamaq imkanı, həmçinin RTSP protokolu vasitəsilə IP kameralar və video müşahidə sistemləri üçün dəstəyi elan edir; bu icmalda biz web-veb yayımlarına və onların xüsusiyyətlərinə diqqət yetirəcəyik.

WebRTC Media və Yayım Serverinin quraşdırılması

Çünki üçün Windows sistemləri server versiyası yox idi və mən VMWare + Linux kimi virtual maşın quraşdırmaq, evdə onlayn yayımları sınamaq istəmirdim Windows kompüter alınmadı. Vaxta qənaət etmək üçün biz bulud hostinqini belə bir nümunə götürmək qərarına gəldik:

Bu, Amsterdam məlumat mərkəzində əvvəlcədən quraşdırılmış proqram təminatı olmadan Centos x86_64 versiyası 6.5 idi. Beləliklə, bizim ixtiyarımızda olan yalnız bir server və ona ssh girişidir. Bilənlər üçün konsol əmrləri Linux, WebRTC serverinin quraşdırılması asan və ağrısız olacağını vəd edir. Beləliklə, biz nə etdik:

1. Arxivi yükləyin:

$wget https://website/download-wcs5-server.tar.gz

2. Paketdən çıxarın:

$tar -xzf download-wcs5-server.tar.gz

3. Quraşdırın:

$cd FlashphonerWebCallServer

Quraşdırma zamanı serverin IP ünvanını daxil edin: XXX.XXX.XXX.XXX

4. Lisenziyanı aktivləşdirin:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. WCS serverini işə salın:

$service webcallserver start

6. Qeydi yoxlayın:

$quyruq - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. İki prosesin yerində olduğunu yoxlayın:

$ps aux | grep Flashfoner

Quraşdırma prosesi tamamlandı.

WebRTC canlı yayımlarının sınaqdan keçirilməsi

Yayımların sınaqdan keçirilməsi sadə bir məsələ olduğu ortaya çıxdı. Serverə əlavə olaraq, onlarla Javascript, HTML və CSS fayllarından ibarət olan və quraşdırma mərhələsində bizim tərəfimizdən /var/www/html qovluğuna yerləşdirilən veb müştəri var. Edilməli olan yeganə şey serverin IP ünvanını flashphoner.xml konfiqurasiyasına daxil etmək idi ki, veb müştəri HTML5 Websockets vasitəsilə serverlə əlaqə yarada bilsin. Test prosesini təsvir edək.

1. Chrome brauzerində test müştərisinin index.html səhifəsini açın:

2. Yayımı başlamaq üçün ekranın ortasındakı “Start” düyməsini sıxmaq lazımdır.
Bunu etməzdən əvvəl veb-kameranın qoşulduğundan və işə hazır olduğundan əmin olmalısınız. Veb kamera üçün xüsusi tələblər yoxdur, məsələn, biz 1280 × 800 qətnamə ilə standart quraşdırılmış noutbuk kamerasından istifadə etdik.

Chrome brauzeri mütləq kameraya və mikrofona giriş tələb edəcək ki, istifadəçi onun videosunun internet serverinə göndəriləcəyini başa düşsün və ona bunu etməyə icazə verir.

3. İnterfeys video axınının kameradan WebRTC serverinə uğurlu tərcüməsidir. Yuxarı sağ küncdə göstərici axının serverə getdiyini bildirir, aşağı küncdə videonun göndərilməsini dayandırmaq üçün “Stop” düyməsi var.

Aşağıdakı linkə nəzər salın. O, bu yayım üçün unikal identifikatoru ehtiva edir, ona görə də hər kəs görünüşə qoşula bilər. Sadəcə bu linki brauzerdə açın. Onu panoya kopyalamaq üçün "Kopyala" düyməsini sıxmaq lazımdır.

Vebinarlar, mühazirələr, onlayn video yayımlar və ya interaktiv TV kimi real tətbiqlərdə tərtibatçılar bu identifikatorun müəyyən izləyici qruplarına paylanmasını həyata keçirməli olacaqlar ki, onlar istədikləri axınlara qoşula bilsinlər, lakin bu, tətbiqin məntiqidir. WebRTC Media & Broadcasting Server ona təsir etmir, ancaq videonu yayır.

5. Əlaqə qurulur və tamaşaçı ekranda axını görür. İndi o, linki başqasına göndərə, yayımın oxunmasını dayandıra və ya sağ alt küncdəki idarəetmə elementlərindən istifadə edərək tam ekran rejimini aktivləşdirə bilər.

Onlayn yayımlar üçün WebRTC server test nəticələri

Testlər zamanı gecikmə mükəmməl görünürdü. Məlumat mərkəzinə ping təxminən 100 millisaniyə idi və gecikmə gözə görünmürdü. Buradan güman edə bilərik ki, real gecikmə tamponlama vaxtı üçün eyni 100 plus və ya mənfi bir neçə onlarla millisaniyədir. Flash video ilə müqayisədə Flash bu testlərdə WebRTC kimi yaxşı performans göstərmir. Beləliklə, əlinizi oxşar şəbəkədə hərəkət etdirsəniz, ekrandakı hərəkət yalnız bir / iki saniyədən sonra görünə bilər.

Keyfiyyətə gəlincə, qeyd edirik ki, bəzən hərəkətlərdə kubları ayırd edə bilərsiniz. Bu, VP8 kodekinin təbiətinə uyğundur və onun əsas məqsədi məqbul keyfiyyətlə və rabitə gecikmələri olmadan real vaxt rejimində video rabitəni təmin etməkdir.

Serveri quraşdırmaq və konfiqurasiya etmək olduqca asandır, onu idarə etmək üçün heç bir ciddi bacarıq tələb etmir, yalnız ssh vasitəsilə konsoldan əmrləri yerinə yetirə bilən və istifadə edə bilən qabaqcıl istifadəçi səviyyəsində Linux bilikləri istisna olmaqla mətn redaktoru. Nəticədə, biz brauzerlər arasında birdən çox onlayn yayım qura bildik. Əlavə izləyicilərin yayıma qoşulması da problem yaratmadı.

Yayım keyfiyyəti vebinarlar və onlayn yayımlar üçün olduqca məqbul olduğu ortaya çıxdı. Bəzi suallara səbəb olan yeganə şey videonun həlli oldu. Kamera 1280x800-ü dəstəkləyir, lakin sınaq şəklinin təsvir ölçüsü 640x480-ə çox bənzəyir. Görünür, bu məsələni tərtibatçılarla aydınlaşdırmaq lazımdır.

Veb kameradan yayımın sınaqdan keçirilməsi haqqında video
WebRTC server vasitəsilə

Brauzerdən zəng etmək texnologiyaları uzun illərdir mövcuddur: Java, ActiveX, Adobe Flash... Son bir neçə ildə pluginlərin getdiyi aydın oldu virtual maşınlar onlar rahatlıqla parıldamırlar (niyə ümumiyyətlə bir şey quraşdırmalıyam?) və ən əsası təhlükəsizlik. Nə etməli? Çıxış var!

Son vaxtlara qədər IP-telefoniya və ya video üçün IP şəbəkələrində bir neçə protokoldan istifadə olunurdu: SIP, hadisə yerindən çıxan ən çox yayılmış protokol, H.323 və MGCP, Jabber/Jingle (Gtalk-da istifadə olunur), yarı açıq Adobe RTMP* və təbii ki, qapalı Skype. Google-un təşəbbüsü ilə həyata keçirilən WebRTC layihəsi hər şeyi lazımsız hala gətirərək İP və veb-telefoniya dünyasını dəyişməyə çalışır. softfonlar Skype daxil olmaqla. WebRTC indi demək olar ki, hər bir cihazda quraşdırılmış bütün kommunikasiya imkanlarını birbaşa brauzerin daxilində həyata keçirmir, eyni zamanda brauzer istifadəçiləri arasında daha ümumi kommunikasiya vəzifəsini (müxtəlif məlumatların mübadiləsi, ekran yayımı, sənədlərlə əməkdaşlıq və s.) həll etməyə çalışır. daha çox).

Veb tərtibatçısı tərəfindən WebRTC

Veb tərtibatçısı baxımından WebRTC iki əsas hissədən ibarətdir:

• yerli resurslardan (kamera, mikrofon və ya ekran) media axınlarına nəzarət yerli kompüter) MediaStream obyektini qaytaran navigator.getUserMedia metodu ilə həyata keçirilir;
• kommunikasiya üsullarının müəyyən edilməsi və onların birbaşa ötürülməsi daxil olmaqla media axınlarını yaradan qurğular arasında peer-to-peer rabitəsi - RTCPeerConnection obyektləri (audio və video axınlarının göndərilməsi və qəbulu üçün) və RTCDataChannel (brauzerdən məlumatların göndərilməsi və qəbulu üçün).

Biz nə edirik?

Veb rozetkalardan istifadə edərək WebRTC əsasında brauzerlər arasında ən sadə multiplayer video söhbətini necə təşkil edəcəyimizi anlayacağıq. İyunun 24-də buraxılan Firefox 22, demək olar ki, onları tutsa da, WebRTC baxımından ən qabaqcıl brauzerlər kimi Chrome/Chromium-da təcrübə aparmağa başlayaq. Demək lazımdır ki, standart hələ qəbul olunmayıb və API versiyadan versiyaya dəyişə bilər. Bütün nümunələr Chromium 28-də sınaqdan keçirilmişdir. Sadəlik üçün kodun təmizliyinə və brauzerlər arası uyğunluğa nəzarət etməyəcəyik.

media axını

İlk və ən sadə WebRTC komponenti MediaStream-dir. O, brauzerə yerli kompüterin kamerasından və mikrofonundan media axınlarına çıxışı təmin edir. Chrome-da bunun üçün navigator.webkitGetUserMedia() funksiyasının çağırılması tələb olunur (standart hələ yekunlaşmadığı üçün bütün funksiyalar prefikslə gəlir və Firefox-da eyni funksiya navigator.mozGetUserMedia() adlanır). Zəng edildikdə, istifadəçidən kamera və mikrofona giriş icazəsi tələb olunacaq. Zəngi yalnız istifadəçi razılıq verdikdən sonra davam etdirmək mümkün olacaq. Tələb olunan media axınının parametrləri və iki geri çağırış funksiyası bu funksiyaya parametr kimi ötürülür: birincisi kameraya/mikrofona uğurlu giriş zamanı, ikincisi isə xəta baş verdikdə çağırılacaq. Əvvəlcə düymə və elementi olan rtctest1.html HTML faylını yaradaq:

WebRTC - ilk qarşılaşma videosu (hündürlük: 240px; en: 320px; haşiyə: 1px bərk boz; ) getUserMedia

Microsoft CU-RTC-Web

Əgər Google-un təşəbbüsünə cavab olaraq CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web) adlı öz uyğunsuz fərdi variantını dərhal buraxmasaydı, Microsoft Microsoft olmazdı. htm). Onsuz da kiçik olan IE-nin payı azalmaqda davam etsə də, Skype istifadəçilərinin sayı Microsoft-a Google-u itələməyə ümid verir və güman etmək olar ki, bu standart brauzerdə istifadə olunacaq. Skype versiyaları. Google standartı, ilk növbədə, brauzerdən brauzerə kommunikasiyaya diqqət yetirir; eyni zamanda, səs trafikinin əsas hissəsi hələ də adi telefon şəbəkəsində qalır və onunla IP şəbəkələri arasında şlüzlər yalnız istifadənin asanlığı və ya daha sürətli paylanması üçün deyil, həm də daha çox oyunçuya imkan verəcək pul qazanma vasitəsi kimi lazımdır. onları inkişaf etdirin. Başqa bir standartın ortaya çıxması nəinki tərtibatçıların bir anda iki uyğun gəlməyən texnologiyanı dəstəkləməsi üçün xoşagəlməz ehtiyaca səbəb ola bilər, həm də gələcəkdə istifadəçiyə mümkün funksionallıq və mövcud texniki həllərin daha geniş seçimini verə bilər. Gözlə və gör.

Yerli başlığı aktivləşdirin

HTML faylımızın etiketlərində media axını üçün qlobal dəyişən elan edəcəyik:

VarlocalStream = null;

getUserMedia metodunun ilk parametri tələb olunan media axınının parametrlərini təyin etməkdir - məsələn, sadəcə olaraq audio və ya videonu aktivləşdirin:

Var streamConstraints = ( "audio": doğru, "video": doğru ); // Həm audio, həm də videoya giriş tələb edin

Və ya əlavə parametrləri göstərin:

Var streamConstraints = ( "audio": true, "video": ( "məcburi": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" ), "optional": ) );

getUserMedia metodunun ikinci parametri uğurlu olarsa çağırılacaq geri çağırış funksiyasını ötürməkdir:

Funksiya getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Media axınını HTML elementinə birləşdirin localStream = axın; // və saxla sonrakı istifadə üçün qlobal dəyişəndə)

Üçüncü parametr geri çağırış funksiyasıdır, xəta baş verdikdə çağırılacaq səhv idarəedicisidir.

GetUserMedia_error(error) funksiyası ( console.log("getUserMedia_error():", xəta); )

getUserMedia metoduna faktiki zəng - birinci düyməyə basıldıqda mikrofona və kameraya giriş tələbi

GetUserMedia_click() funksiyası ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

Lokal olaraq açılmış fayldan media axınına daxil olmaq mümkün deyil. Bunu etməyə çalışsaq, xəta alırıq:

NavigatorUserMediaError (kod: 1, PERMISSION_DENIED: 1)"

Yaranan faylı serverə yükləyək, onu brauzerdə açaq və görünən sorğuya cavab olaraq kamera və mikrofona girişə icazə verək.

Chrome-un hansı cihazlara daxil olacağını Parametrlər, Qabaqcıl parametrləri göstər linki, Məxfilik bölməsi, Məzmun düyməsində seçə bilərsiniz. Firefox və Opera brauzerlərində giriş icazəsi verildikdə cihazlar birbaşa açılan siyahıdan seçilir.

HTTP protokolundan istifadə edərkən, səhifə yükləndikdən sonra media axınına hər dəfə daxil olduqda icazə tələb olunacaq. HTTPS-ə keçid sizə sorğunu bir dəfə, yalnız media axınına ilk girişdə göstərməyə imkan verəcək.

Nişandakı işarədəki pulsasiya edən dairəyə və ünvan çubuğunun sağ tərəfindəki kamera işarəsinə diqqət yetirin:

RTMediaConnection

RTTCediaConnection - iştirakçılar arasında şəbəkə üzərindən media axınlarının yaradılması və ötürülməsi üçün nəzərdə tutulmuş obyekt. Bundan əlavə, bu obyekt media sessiyasının təsvirini (SDP) yaratmaq, NAT-dan keçmək üçün ICE namizədləri haqqında məlumat almaq və ya təhlükəsizlik divarları(yerli və STUN vasitəsilə) və TURN serveri ilə qarşılıqlı əlaqə. Hər bir iştirakçıda hər bir əlaqə üçün bir RTTCMediaConnection olmalıdır. Media axınları şifrələnmiş SRTP protokolu üzərindən ötürülür.

serverləri TURN

ICE namizədlərinin üç növü var: host, srflx və relay. Host yerli olaraq əldə edilən məlumatları ehtiva edir, srflx hostun xarici serverə (STUN) bənzədiyi şeydir və relay TURN serveri vasitəsilə trafikin proksiləşdirilməsi üçün məlumatdır. Ev sahibimiz NAT-ın arxasındadırsa, o zaman ev sahibi namizədləri ehtiva edəcəkdir yerli ünvanlar və faydasız olacaq, srflx namizədləri yalnız müəyyən növ NAT ilə kömək edəcək və relay trafikin ara serverdən keçməsi üçün son ümid olacaq.

192.168.1.37 ünvanı və udp/34022 portu olan host tipli ICE namizədinə nümunə:

A=namizəd:337499441 2 udp 2113937151 192.168.1.37 34022 tip host nəsil 0

STUN/TURN serverlərini təyin etmək üçün ümumi format:

Var serverlər = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn:user@host:port", "credential": "parol" ) ]);

İnternetdə çoxlu ictimai STUN serverləri var. Böyük bir siyahı, məsələn, . Təəssüf ki, çox az sayda problemləri həll edirlər. STUN-dan fərqli olaraq, praktiki olaraq heç bir ictimai TURN serverləri yoxdur. Bu, TURN serverinin media axınlarını özündən keçirməsi ilə əlaqədardır ki, bu da həm şəbəkə kanalını, həm də serverin özünü əhəmiyyətli dərəcədə yükləyə bilər. Buna görə də, TURN serverlərinə qoşulmağın ən asan yolu onu özünüz quraşdırmaqdır (açıqcası, sizə ictimai IP lazımdır). Bütün serverlərdən, mənim fikrimcə, ən yaxşısı rfc5766-turn-serverdir. Onun altında hətta Amazon EC2 üçün hazır şəkil də var.

TURN ilə hər şey istədiyimiz qədər yaxşı deyil, lakin aktiv inkişaf davam edir və ümid etmək istərdim ki, bir müddət sonra WebRTC, ünvan tərcüməsindən keçmə keyfiyyəti baxımından Skype-ı tutmasa ( NAT) və təhlükəsizlik duvarları, sonra ən azı nəzərəçarpacaq dərəcədə yaxınlaşır.

RTTCMediaConnection əlaqə yaratmaq üçün nəzarət məlumatlarının mübadiləsi üçün əlavə mexanizmə ehtiyac duyur - bu məlumatları yaratsa da, ötürmür və digər iştirakçılar tərəfindən ötürülmə ayrıca həyata keçirilməlidir.

Ötürmə metodunun seçimi tərtibatçının məsuliyyətidir - ən azı əl ilə. Lazımi məlumat mübadiləsi aparıldıqdan sonra RTTCMediaConnection avtomatik olaraq media axınlarını quracaq (əgər mümkünsə, əlbəttə).

təklif-cavab modeli

Media axınlarını qurmaq və dəyişdirmək üçün təklif/cavab modeli (təklif/cavab; RFC3264-də təsvir) və SDP protokolundan (Session Təsvir Protokolu) istifadə olunur. Onlar həmçinin SIP protokolu tərəfindən istifadə olunur. Bu modeldə iki agent fərqləndirilir: Təklif edən - yenisini yaratmaq və ya mövcud olanı dəyişdirmək üçün SDP sessiyasının təsvirini yaradan (Təklif SDP) və Cavab verən - başqa agentdən SDP sessiyasının təsvirini alan və cavab verən. öz sessiya təsviri ilə (Cavab SDP). Eyni zamanda, spesifikasiya agentlər arasında SDP-nin ötürülməsinə cavabdeh olan daha yüksək səviyyəli protokol tələb edir (məsələn, SIP və ya bizim vəziyyətimizdə olduğu kimi özünün veb yuvaları).

Media axınlarını uğurla qura bilməsi üçün iki RTTCMediaConnection arasında hansı məlumatların ötürülməsi lazımdır:

• Qoşulmaya təşəbbüs göstərən birinci tərəf, ötürməyə başlamaq üzrə olduğu media axınının mümkün xüsusiyyətlərini təsvir edən SDP məlumat strukturunu (eyni protokol SIP-də eyni məqsəd üçün istifadə olunur) ötürdüyü Təklif təşkil edir. Bu məlumat bloku ikinci iştirakçıya ötürülməlidir. İkinci iştirakçı öz SDP ilə Cavab yaradır və birinciyə göndərir.
• Həm birinci, həm də ikinci iştirakçılar mümkün ICE namizədlərinin müəyyən edilməsi prosedurunu yerinə yetirirlər, onun köməyi ilə ikinci iştirakçı media axınını onlara ötürə bilər. Namizədlər müəyyən olunduqca onlar haqqında məlumat başqa iştirakçıya ötürülməlidir.

Təklifin formalaşması

Təklif yaratmaq üçün bizə iki funksiya lazımdır. Uğurlu formalaşdığı təqdirdə birincisi çağırılacaq. CreateOffer() metodunun ikinci parametri onun icrası zamanı xəta baş verdikdə (yerli axın artıq mövcud olmaq şərti ilə) çağırılan geri çağırış funksiyasıdır.

Əlavə olaraq, iki hadisə idarəçisinə ehtiyac var: yeni ICE namizədini təyin edərkən onicecandidate və uzaq tərəfdən media axını birləşdirərkən onaddstream. Faylımıza qayıdaq. Elementləri olan sətirlərdən sonra HTML-yə başqa birini əlavə edək:

Təklif yaradın

Və elementi olan sətirdən sonra (gələcək üçün):

Həmçinin, JavaScript kodunun əvvəlində biz RTCPeerConnection üçün qlobal dəyişən elan edəcəyik:

varpc1;

RTCPeerConnection konstruktorunu çağırarkən siz STUN/TURN serverlərini təyin etməlisiniz. Ətraflı məlumat üçün yan panelə baxın; bütün iştirakçılar eyni şəbəkədə olduğu müddətcə onlar tələb olunmur.

var servers = null;

Təminat təklifi üçün seçimlər SDP

var offerConstraints = ();

CreateOffer() metodunun birinci parametri Təklifin uğurlu formalaşdırılmasından sonra çağırılan geri çağırış funksiyasıdır

Funksiya pc1_createOffer_success(az) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"az:", desc); pc1.setLocalDescription(az); // RTCPeerConnection tərəfindən yaradılan parametrləri təyin edin SDP setLocalDescription metodunu təklif edin. // Uzaq tərəf Cavab SDP-ni göndərdikdə, onu setRemoteDescription metodundan istifadə etməklə təyin etmək lazımdır // İkinci tərəf həyata keçirilənə qədər heç nə etməyin // pc2_receivedOffer(az); )

İkinci parametr xəta baş verdikdə çağırılacaq geri çağırış funksiyasıdır

Funksiya pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): xəta:", xəta); )

Və biz müəyyən edildiyi kimi ICE namizədlərinə keçəcək bir geri çağırış funksiyası elan edəcəyik:

Funksiya pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // İkinci tərəf həyata keçirilənə qədər heç nə etməyin // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Həmçinin uzaq tərəfdən media axını əlavə etmək üçün geri çağırış funksiyası (gələcək üçün, çünki bizdə indiyə qədər yalnız bir RTCPeerConnection var):

Funksiya pc1_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )

“CreateOffer” düyməsini kliklədiyiniz zaman RTCPeerConnection yaradın, onicecandidate və onaddstream metodlarını təyin edin və createOffer() metoduna zəng edərək Təklif SDP-nin formalaşmasını tələb edin:

Funksiya createOffer_click() ( console.log("createOffer_click()"); pc1 = yeni webkitRTCPeerConnection(serverlər); // RTCPeerConnection yaradın pc1.onicecandidate = pc1_onicecandidate; // ICE namizədlərini emal etmək üçün geri çağırış funksiyası pc1ddstreonaddstreonam; /pc1.c / Uzaq tərəfdən media axını olduqda çağırılan geri çağırış funksiyası, o, hələ mövcud deyil pc1.addStream(localStream); // Yerli media axınını keçirin (artıq qəbul edildiyini nəzərə alaraq) pc1.createOffer(// Və əslində Təklifin formalaşdırılmasını tələb edin pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )

Faylı rtctest2.html kimi saxlayaq, serverə yerləşdirək, brauzerdə açaq və konsolda onun işləməsi zamanı hansı verilənlərin əmələ gəldiyinə baxaq. Yalnız bir iştirakçı olduğu üçün ikinci video hələ görünməyəcək. Xatırladaq ki, SDP media sessiyası parametrlərinin təsviridir, mövcud kodeklər, media axınları və ICE namizədləri bu iştirakçıya qoşulmaq üçün mümkün variantlardır.

Cavab SDP-nin formalaşdırılması və ICE namizədlərinin mübadiləsi

Həm Təklif SDP, həm də ICE namizədlərinin hər biri digər tərəfə ötürülməlidir və orada onları RTCPeerConnection-dan aldıqdan sonra Təklif SDP üçün setRemoteDescription metodlarını və uzaq tərəfdən alınan hər bir ICE namizədi üçün addIceCandidate çağırın; oxşar şəkildə arxa tərəf Cavab SDP və uzaq ICE namizədləri üçün. Cavab SDP özü Təklifə bənzər şəkildə formalaşır; fərq ondadır ki, createOffer metodu deyil, createAnswer metodu çağırılır və bu RTCPeerConnection-dan əvvəl setRemoteDescription metodu zəng edəndən alınan Təklif SDP-ni keçir.

HTML-ə başqa bir video elementi əlavə edək:

Və birincinin elanı altında ikinci RTCPeerConnection üçün qlobal dəyişən:

Varpc2;

Təklif və Cavab SDP emal olunur

Cavab SDP-nin formalaşdırılması Təklifə çox bənzəyir. Cavabın uğurla formalaşması ilə çağırılan geri çağırış funksiyasında, Təklifə bənzər olaraq, biz yerli təsviri verəcəyik və alınan Cavab SDP-ni birinci iştirakçıya ötürəcəyik:

pc2_createAnswer_success(az) funksiyası ( pc2.setLocalDescription(az); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(az); )

Cavabın yaradılması zamanı xəta baş verdikdə çağırılan geri çağırış funksiyası Təklifə tamamilə bənzəyir:

Funksiya pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", xəta); )

Cavab SDP yaratmaq üçün parametrlər:

Var answerConstraints = ( "məcburi": ( "OfferToReceiveAudio":doğru, "OfferToReceiveVideo":doğru ) );

İkinci iştirakçı Təklif aldıqda, RTCPeerConnection yaradın və Təkliflə eyni şəkildə Cavab yaradın:

Funksiya pc2_receivedOffer(az) ( console.log("pc2_receiveOffer()", desc); // İkinci iştirakçı üçün birinci pc2 ilə oxşar RTCPeerConnection obyekti yaradın = yeni webkitRTCPeerConnection(serverlər); pc2.onicecandidate //;pc2. ICE namizədi pc2.onaddstream = pc_onaddstream olduqda hadisə idarəedicisini təyin edin; // Axın görünəndə onu HTML pc2.addStream(localStream) ilə birləşdirin; // Yerli media axınını keçirin (nümunəmizdə ikinci iştirakçı eynidir. birincisi kimi axın) // İndi, ikinci RTCPeerConnection hazır olduqda, alınan Təklif SDP-ni ona ötürün (biz yerli axını birinciyə keçirdik) pc2.setRemoteDescription(yeni RTCSessionDescription(az)); // Sorğu Cavab mesajı üçün məlumat yaratmaq üçün ikinci əlaqə pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )

Təklif SDP-ni birinci iştirakçıdan ikinci iştirakçıya köçürmək üçün, nümunəmizin bir hissəsi kimi, pc1 funksiyasında şərhi silin. Təklif yaradın müvəffəqiyyət () zəng sətri:

Pc2_receivedOffer(az);

ICE namizədlərinin işlənməsini həyata keçirmək üçün birinci iştirakçı pc1_onicecandidate()-nin ICE namizədinin hazırlığı hadisəsi idarəedicisində onun ikinciyə ötürülməsini şərh edin:

Pc2.addIceCandidate(yeni RTCIceCandidate(event.candidate));

İkinci iştirakçının ICE namizədinin hazırlıq hadisəsi idarəçisi birinciyə güzgü kimidir:

Funksiya pc2_onicecandidate(event) ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(yeni RTCIceCandidate(event.candidate)); ) )

İlk iştirakçıdan media axını əlavə etmək üçün geri çağırış funksiyası:

Funksiya pc2_onaddstream(event) ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )

Bağlantının dayandırılması

HTML-də başqa bir düymə əlavə edək

asmaq

Və əlaqəni bitirmək üçün bir funksiya

Funksiya btnHangupClick() ( // Yerli videonu HTML elementlərindən ayırın, yerli media axınını dayandırın, təyin edin = null localVideo1.src = ""; localStream.stop(); localStream = null; // Hər bir iştirakçı üçün HTML elementlərindən videonu deaktiv edin , əlaqəni bağlayın, göstərici təyin edin = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )

Onu rtctest3.html olaraq qeyd edək, serverə yerləşdirək və brauzerdə açaq. Bu nümunə eyni brauzer nişanı daxilində iki RTCPeerConnections arasında ikitərəfli media axını həyata keçirir. Şəbəkə vasitəsilə iştirakçılar arasında Təklif və Cavab SDP, ICE namizədləri və digər məlumat mübadiləsini təşkil etmək üçün birbaşa zəng əvəzinə bir növ nəqliyyatdan, bizim vəziyyətimizdə veb rozetkalardan istifadə edən iştirakçılar arasında mübadilə həyata keçirmək lazımdır. prosedurlar.

Ekran yayımı

getUserMedia funksiyası ilə siz həmçinin aşağıdakı parametrləri təyin etməklə ekranı çəkə və MediaStream kimi yayımlaya bilərsiniz:

Var mediaStreamConstraints = ( audio: false, video: ( məcburi: ( chromeMediaSource: "screen" ), isteğe bağlı: ) );

Ekrana uğurlu giriş üçün bir neçə şərt yerinə yetirilməlidir:

• chrome://flags/,chrome://flags/-də getUserMedia()-da ekran görüntüsü bayrağını aktivləşdirin;
• mənbə faylı HTTPS (SSL mənşəyi) vasitəsilə yüklənməlidir;
• audio axını tələb edilməməlidir;
• birdən çox sorğu eyni brauzer nişanında edilməməlidir.

WebRTC üçün kitabxanalar

WebRTC hələ tam olmasa da, onun əsasında bir neçə kitabxana artıq yaranıb. JsSIP Asterisk və Camalio kimi SIP açarları ilə işləyən brauzer əsaslı proqram telefonları yaratmaq üçün nəzərdə tutulmuşdur. PeerJS məlumat mübadiləsi üçün P2P şəbəkələrinin yaradılmasını sadələşdirəcək, Holla isə brauzerlərdən P2P rabitəsi üçün tələb olunan inkişafın həcmini azaldacaq.

Node.js və socket.io

Şəbəkə üzərindən iki RTCPeerConnections arasında SDP və ICE namizədlərinin mübadiləsini təşkil etmək üçün biz socket.io modulu ilə Node.js-dən istifadə edirik.

Node.js-in ən son stabil versiyasının quraşdırılması (Debian/Ubuntu üçün) təsvir edilmişdir

$ sudo apt-get quraşdırma python-software-properties python g++ etmək $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get yeniləmə $ sudo apt-get nodejs quraşdırmaq

Başqaları üçün quraşdırma ƏS təsvir edilmişdir

yoxlayaq:

$ echo "sys=require("util"); sys.puts("Test mesajı");" > nodetest1.js $ nodejs nodetest1.js

Npm (Node Package Manager) istifadə edərək socket.io və əlavə ekspress modulu quraşdırın:

$ npm socket.io express quraşdırın

Server tərəfi üçün nodetest2.js faylı yaradaraq bunu yoxlayaq:

$ nano nodetest2.js var app = tələb edir("express")() , server = tələb edir("http").createServer(app) , io = tələb edir("socket.io").dinləyin(server); server.dinlə(80); // Əgər port 80 pulsuzdursa app.get("/", funksiyası (req, res) ( // Kök səhifəyə daxil olduqda res.sendfile(__dirname + "/nodetest2.html"); // HTML faylını verin ) ); io.sockets.on("bağlantı", funksiya (soket) ( // Bağlantıda socket.emit("server hadisəsi", ( salam: "dünya" )); // mesaj göndər socket.on("müştəri hadisəsi", funksiya (data) ( // və müştəri console.log(data); )); ) mesaj gəldikdə hadisə idarəedicisini elan edin);

Və müştəri tərəfi üçün nodetest2.html:

$ nano nodetest2.html var socket = io.connect("/"); // Veb soket serverinin URL-i (səhifənin yükləndiyi serverin kök səhifəsi) socket.on("server hadisəsi", funksiya (data) ( console.log(data); socket.emit("müştəri hadisəsi" , ( "ad": "dəyər" )); ));

Serverə başlayaq:

$ sudo nodejs nodetest2.js

və brauzerdə http://localhost:80 (əgər 80 nömrəli portda yerli işləyirsə) səhifəsini açın. Hər şey uğurlu olarsa, brauzerin JavaScript konsolunda qoşulma zamanı brauzer və server arasında hadisələrin mübadiləsini görəcəyik.

Veb yuvalar vasitəsilə RTCPeerConnection arasında məlumat mübadiləsi Müştəri tərəfi

Əsas nümunəmizi (rtcdemo3.html) yeni rtcdemo4.html adı altında saxlayaq. Socket.io kitabxanasını elementə daxil edin:

JavaScript skriptinin əvvəlində - veb soket bağlantısı:

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

Başqa bir iştirakçının funksiyalarına birbaşa zəngi ona veb rozetkalar vasitəsilə mesaj göndərməklə əvəz edək:

Funksiya createOffer_success(az) ( ... // pc2_receivedOffer(az); socket.emit("təklif", azalma); ... ) funksiya pc2_createAnswer_success(az) ( ... // pc1.setRemoteDescription(az); yuva .emit("cavab", desc); ) funksiyası pc1_onicecandidate(hadisə) ( ... // pc2.addIceCandidate(yeni RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) funksiya pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(yeni RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )

hangup() funksiyasında, ikinci iştirakçının funksiyalarını birbaşa çağırmaq əvəzinə, veb-soketlər vasitəsilə mesaj göndərəcəyik:

Funksiya btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", ()); )

Və mesaj qəbul edən işləyiciləri əlavə edin:

Socket.on("təklif", funksiya (data) ( console.log("socket.on("təklif"):", data); pc2_receivedOffer(data); )); socket.on("cavab", funksiya (data) (e console.log("socket.on("cavab"):", data); pc1.setRemoteDescription(yeni RTCSessionDescription(data)); )); socket.on("ice1", funksiya (data) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(yeni RTCIceCandidate(data)); )); socket.on("ice2", funksiya (data) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(yeni RTCIceCandidate(data)); )); socket.on("hangup", funksiya (data) ( console.log("socket.on("hangup")):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Server hissəsi

Server tərəfində nodetest2 faylını rtctest4.js yeni adı altında və io.sockets.on("bağlantı", funksiya (socket) ( ... ) funksiyası daxilində müştəri mesajlarının qəbulu və göndərilməsini əlavə edin:

Socket.on("təklif", funksiya (data) ( // "Təklif" mesajı alarkən, // bu misalda yalnız bir müştəri bağlantısı olduğundan, // eyni socket socket.emit( ​​vasitəsilə mesajı geri göndərin. "offer" , data); // Əgər mesajı göndərəndən başqa bütün əlaqələrə yönləndirmək lazım olsaydı //: // socket.broadcast.emit("təklif", data); )); socket.on("cavab", funksiya (data) ( socket.emit("cavab", data); )); socket.on("ice1", funksiya (data) ( socket.emit("ice1", data); )); socket.on("ice2", funksiya (data) ( socket.emit("ice2", data); )); socket.on("hangup", funksiya (data) ( socket.emit("hangup", data); ));

Bundan əlavə, HTML faylının adını dəyişdirin:

// res.sendfile(__dirname + "/nodetest2.html"); // HTML faylını verin res.sendfile(__dirname + "/rtctest4.html");

Server başlanğıcı:

$ sudo nodejs nodetest2.js

Hər iki müştərinin kodunun eyni brauzer nişanı daxilində işləməsinə baxmayaraq, nümunəmizdəki iştirakçılar arasında bütün qarşılıqlı əlaqə tamamilə şəbəkə vasitəsilə həyata keçirilir və iştirakçıları "yaymaq" artıq çətin deyil. Bununla belə, bizim gördüyümüz iş də çox sadə idi - bu texnologiyalar onların istifadəsi rahatlığı baxımından yaxşıdır. Bəzən aldadıcı olsa da. Xüsusilə, unutmayaq ki, STUN/TURN serverləri olmadan bizim nümunəmiz ünvan tərcüməsi və firewallların mövcudluğunda işləyə bilməyəcək.

Nəticə

Nəticə nümunəsi çox şərtlidir, lakin hadisə idarəedicilərini bir az universallaşdırsaq ki, onlar zəng edən və çağırılan tərəflər arasında fərqlənməsin, iki pc1 və pc2 obyekti əvəzinə, RTCPeerConnection massivi yaradın və həyata keçirin. dinamik yaradılması və elementləri silməklə, tamamilə istifadə edilə bilən video söhbət əldə edirsiniz. Bu, artıq WebRTC-yə xas deyil və bir neçə iştirakçı üçün ən sadə video söhbət nümunəsi (həmçinin məqalənin bütün nümunələrinin mətnləri) jurnalla birlikdə gələn diskdədir. Ancaq İnternetdə artıq çox şey tapa bilərsiniz yaxşı nümunələr. Xüsusilə, məqaləni hazırlayarkən aşağıdakılardan istifadə edilmişdir: simpl.info getUserMedia , simpl.info RTCPeerConnection , WebRTC Reference App .

Çox yaxında WebRTC sayəsində təkcə səs və video rabitə anlayışımızda deyil, həm də bütövlükdə İnterneti necə qavradığımızda inqilab olacağını güman etmək olar. WebRTC təkcə brauzerdən brauzerə zəng texnologiyası kimi deyil, həm də real vaxt rejimində rabitə texnologiyası kimi yerləşdirilib. Təhlil etdiyimiz video link onun sadəcə kiçik bir hissəsidir. seçimlər onun istifadəsi. Artıq ekran paylaşımı (ekran paylaşma) və əməkdaşlıq nümunələri və hətta RTCDataChannel-dən istifadə edən brauzer əsaslı P2P məzmun çatdırılması şəbəkəsi mövcuddur.