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 bazası 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 olmadan birbaşa istifadəçilərin brauzerləri (peerləri) arasında ötürülür əlavə proqramlar. Brauzerlərə əlavə olaraq, p2p video çatları istifadəçiləri qeydiyyata almaq, onlar haqqında məlumat 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ın ötürülməsini, həmçinin IP şəbəkələri üzərindən səs və video rabitəni təmin edir.

Beləliklə, söhbətlər, veb-çatlar, veb-interfeysdə səsli və video çatlar, IMS, VoIP kompozit paket kommutasiyalı şəbəkələr vasitəsilə onlayn rabitəni təmin edən xidmətlərdir. Bir qayda olaraq, rabitə xidmətləri istifadəçi qurğularında (kompüterlər, smartfonlar və s.) müştəri proqramlarının quraşdırılmasını və ya 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 müştəri-server arxitekturasında qurulur.

Rabitə xidmətləri IMS-dən başqa, 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, hər bir rabitə şəbəkəsi üçün ayrıca proqramın quraşdırılmasını tələb edir.

Real vaxt rejimində rabitə xidmətlərinin (chat, telefoniya, video konfrans) inteqrasiyası problemi, i.e. səs, video, məlumat kanallarının inteqrasiyası və onlara bir proqram (brauzer) vasitəsilə daxil olmaq 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ı üçün (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 söhbətlərinin mahiyyəti ondan ibarətdir ki, multimedia və mətn məlumatları server və ya əlavə proqramların iştirakı olmadan birbaşa istifadəçilərin brauzerləri (uzaqdan baxma) 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əçilərin 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ə daxil edin.

Lakin telekommunikasiya xidmətlərinin yeni nəslinə 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, həmçinin ani mətn mesajlarının və faylların ötürülməsini təmin edə 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-yə əsaslanan 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ə internet üzərindən istifadəçilər arasında mətn, səs və video rabitəni 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ə qarşılıqlı əlaqə qurur.

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

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

Brauzerlər media məlumatlarını UDP üzərində 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 web çatları):
1. WebRTC-yə əsaslanan P2P video çat Bistri (bir kliklə video chat, p2p chat), 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ı ötürür. Şəkildə. 1 Bistri p2p video söhbət interfeysinin ekran görüntüsünü göstərir.

düyü. 1. P2P video chat Bistr

2. Twelephone (p2p video chat, p2p chat, SIP Twelephone) - bu müştəri proqramı HTML5 və WebRTC əsasında qurulmuşdur ki, bu da sizə 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 edə bilərsiniz və səsin tanınması proqramı mətni “Mesaj göndər” sətrinə 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 backend 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ə.

Şəkildə. Şəkil 2 Twelephone p2p video söhbət interfeysinin ekran görüntüsünü göstərir.

düyü. 2. P2P Telefon

3. Qrup p2p video çat Conversat.io ən son WebRTC və HTML5 texnologiyaları üzərində qurulub. Conversat video çatı SimpleWebRTC kitabxanası əsasında hazırlanmışdır və bir otaqda 6-a qədər həmyaşıd müştəri arasında ünsiyyət üçün nəzərdə tutulmuşdur (ünsiyyət üçün "Söhbətə ad verin" sətirində həmyaşıd müştərilər üçün ümumi otağın adını göstərin). P2P video çatı Conversat istifadəçilərə əlaqə serverində qeydiyyatdan keçmədən rabitə xidmətləri təqdim edir. Şəkildə. Şə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 əsasında 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 ilə başlayan 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 səviyyəsinə yönəlib və texnologiyanın başa düşülməsinə 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 lazım 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 yönümlü texnologiyadır. Əsas xüsusiyyətlər daxili brauzer dəstəyidir (adobe flash kimi üçüncü tərəf tərəfindən həyata keçirilən texnologiyalara ehtiyac yoxdur) və əlavə serverlərdən istifadə etmədən müştəriləri 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. Bir çox ev marşrutlaşdırıcıları indi NAT-ı dəstəkləyir və bunun sayəsində bütün ev cihazlarının İnternetə çıxışı var, baxmayaraq ki, İnternet provayderləri adətən bir IP ünvanı təqdim edirlər. Ü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çirək: 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 ictimai) (Şəkil 2) və hər iki qovşaq fərqli özəl şəbəkələrdədir. eyni IP ünvanları (Şə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 qovşaq növünü göstərir (p = peer, r = marşrutlaşdırıcı). Birinci şəkildə vəziyyət əlverişlidir: onların şəbəkəsindəki qovşaqlar şəbəkə IP ünvanları ilə tam 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. Bu, ikisi olan marşrutlaşdırıcıların (marşrutlaşdırıcıların) göründüyü yerdir şəbəkə interfeysi– şəbəkəniz 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əri daxilində əlaqə saxlaya bilərlər. Əgər onlar məlumatı öz şəbəkəsindən kənar kiməsə ötürürlərsə, onda yalnız marşrutlaşdırıcının (marşrutlaşdırıcının) daxilində NAT-dan 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ındır. xarici IP ünvanı. Beləliklə, p1 node var daxili IP = 192.168.0.200 Və xarici IP = 10.50.200.5 , və sonuncu ünvan da şəbəkəsindəki bütün digər qovşaqlar üçün xarici olacaqdır. 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ı ünvanlardan 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 problemi NAT mexanizmindən istifadə etməklə həll etmək olar

Düyünləri daxili ünvanları vasitəsilə birləşdirməyi qərara alsaq 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, ICE protokolundan istifadə edərək bu cür problemlərin öhdəsindən uğurla gəlir, lakin bu, əlavə serverlərin (STUN, TURN) istifadəsini tələb edir. Bütün bunlar haqqında daha ətraflı aşağıda.

WebRTC-nin iki mərhələsi

WebRTC protokolu (və ya sadəcə RTC, əgər iki iPhone əlaqə saxlayırsa) vasitəsilə iki nodu birləşdirmək üçün əlaqə yaratmaq üçün bəzi ilkin addımları yerinə yetirməlisiniz. 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ə edir 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 olmalıdır əlavə heç bir şəkildə WebRTC ilə əlaqəli olmayan məlumat ötürmə üsulu. Bu, bir socket transferi, 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 şəklində ö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ə, həyata keçirməli olduğumuz siqnal mexanizmi ayrıca, istifadə olunacaq yalnız qoşulduqda, lakin video məlumatlarını ötürərkən istifadə edilməyəcək.

Beləliklə, birinci mərhələni - əlaqənin qurulması mərhələsini nəzərdən keçirək. Bir neçə nöqtədən ibarətdir. Gəlin əvvəlcə əlaqəni başlatan qovşaq, sonra isə gözləyən qovşaq üçün bu mərhələyə baxaq.

• Təşəbbüskar (zəng edən):
• Video məlumat ötürülməsinə başlamaq təklifi (createOffer)
• SDP SDP-ni əldə edin)
• Buz namizədinizin qəbulu Buz namizədi)
• Zəng gözləyən (zəng edən):
• Yerli (sizin) media axınının qəbulu və ötürülməsi üçün qurulması (getUserMediaStream)
• Video məlumat ötürülməsinə başlamaq üçün təklifin alınması və cavabın yaradılması (Cavab yaratmaq)
• SDP obyektinin qəbulu və siqnal mexanizmindən (SDP) keçməsi
• Buz namizədinin obyektlərini qəbul etmək və onları siqnal mexanizmi vasitəsilə ö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 nöqtədədir.

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 (maddə 1), əlaqə parametrlərini təyin etmək (maddə 2-4), başqasının media axınını qəbul etmək (maddə 5). Ən çətin addım 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, paketlərin bir şəbəkə qovşağından digərinə keçmək üçün 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 mahiyyət media axınıdır, yəni video və audio məlumatların, şəkil və səs axınıdır. Media axınının iki növü var - yerli və uzaqdan. Yerli giriş cihazlarından (kamera, mikrofon), uzaqdan isə şəbəkə vasitəsilə 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ə yalnız birinci ilə qarşılaşa bilərsiniz, lakin libjingle istifadə etsəniz, ikinci ilə də qarşılaşa bilərsiniz.

WebRTC mövzu daxilində olduqca çaşdırıcı bir iyerarxiyaya malikdir. 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 şeyə qaydasında baxaq. Bunun üçün bəzi nümunələri yadda saxlayaq. Deyək ki, biz təkcə özümüzün deyil, həm də ü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-imiz 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ü MediaTrack media track vasitəsilə həyata keçirilir. Media treki onun video və ya audio olduğunu 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 treklə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ə bilərsiniz, ancaq orada müxtəlif yollardan istifadə edin. Biz media axınlarının mühüm bir xüsusiyyətinə çatdıq - 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 olunur.

Beləliklə, sözlərimizin, üz emosiyaları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ürmə zamanı bəzi trekləri söndürmək lazımdırsa, siz media trekinin aktiv xüsusiyyətindən istifadə edə bilərsiniz.

Nəhayət, stereo səs haqqında düşünməyə dəyər. Bildiyiniz kimi, stereo səs iki fərqli səsdir. Və onlar da ayrıca köçürülməlidir. Bunun üçün MediaChannels istifadə olunur. Media audio treki bir çox kanala malik ola bilər (məsələn, 5+1 audio lazımdırsa, 6). Təbii ki, media treklərinin içərisində kanallar da var. sinxronlaşdırılmışdır. Video üçün adətən yalnız bir kanal istifadə olunur, lakin bir neçəsi, məsələn, reklamın üst-üstə düşməsi üçü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ının içərisində iki növ media treki var - video və audio üçün. Adətən ikidən çox yol yoxdur, lakin bir neçə fərqli videonu (həmsöhbətin və onun masasının) ötü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 kamera üçün cavabdehdir, audio trek mikrofon üçün, media axını isə hər ikisi üçün konteynerdir.

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 məlumatların media ö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şağa keçirin və media məlumatları ötürülə bilər. Yalnız başqa bir node ilə əlaqə hələ yoxdur.

Bunun üçün istənilən siqnal mexanizmindən istifadə olunur. SDP ya rozetkalar vasitəsilə, ya da bir şəxs tərəfindən (telefonla başqa bir qovşaqla danışın) və ya Rusiya Postu ilə ötürülə bilər. 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 qəbul edildikdə, onu WebRTC şöbəsinə köçürün. Sessiya deskriptoru mətn kimi saxlanılır və tətbiqlərinizdə dəyişdirilə bilər, lakin bu ümumiyyətlə lazım deyil. 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.

Tipik olaraq, əlaqə qurarkən, URL kimi bir növ ünvan göstərməlisiniz. Burada bu lazım deyil, çünki siqnal mexanizmi vasitəsilə siz özünüz məlumatları 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 funksiyaya zəng etdikdən və xüsusi geri çağırış 'a təyin edildikdə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 məlumatlar digər tərəfə 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 deskriptoru sizin geri zənginizə ötürüləcək və onun siqnal mexanizmi vasitəsilə geri ötürülməsi lazımdır.

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ışı zamanı yaradılacaq yerli SDP obyekti uzaq SDP obyektinə etibar etməlidir. Yalnız bu halda video parametrlərinizi həmsöhbətinizin parametrləri ilə əlaqələndirmək mümkündür. Həmçinin, yerli media axını almadan əvvəl createAnswer və createOffer-ə zəng etməməlisiniz - onların SDP obyektinə yazmaq üçün heç nələri olmayacaq.

WebRTC SDP obyektini redaktə etmək imkanına malik olduğundan, yerli deskriptoru aldıqdan sonra onu quraşdırmaq lazımdır. Bir az qəribə görünə bilər ki, biz WebRTC-yə onun bizə verdiyini köçürməliyik, amma protokol budur. Uzaqdan tutacaq alındıqda, o da quraşdırılmalıdır. Buna görə, bir node üzərində iki deskriptor quraşdırmalısınız - sizin və başqasının (yəni yerli və uzaq).

Bundan sonra əl sıxma qovşaqlar bir-birinin istəklərini bilirlər. Məsələn, əgər qovşaq 1 A və B kodeklərini, 2-ci isə 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ı

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şə edilirdi. 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 hələ də şəbəkə qovşaqlarının məlumat ötürə biləcəyi heç 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ə edilmirsə, bəlkə də başqalarından) istifadə edərək bir-birlərinə asanlıqla qoşula bilərlər.

Bəzi geri çağırışlar vasitəsilə və WebRTC bizə Ice namizəd obyektləri haqqında məlumat verir. Onlar həmçinin mətn formasında gəlirlər və sessiya deskriptorları 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 node-a ötürün və o, fiziki olaraq bizə qoşula biləcək və onun artıq sessiya deskriptoru olduğu üçün məntiqi olaraq qoşula biləcək və məlumatlar “axınacaq”. Əgər o, bizə namizəd obyektini, yəni özünün şəbəkədə harada olması barədə məlumatı göndərməyi xatırlasa, o zaman onunla əlaqə saxlaya biləcəyik. Burada klassik müştəri-server qarşılıqlı əlaqəsindən daha bir fərqi qeyd edək. 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 deskriptorlarından fərq ondan ibarətdir ki, yalnız uzaq namizədlər quraşdırılmalıdır. 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 deskriptorları təyin edildikdən sonra quraşdırılmalıdır.

Niyə yalnız bir sessiya deskriptoru var idi, amma bir çox namizəd ola bilərdi? Çü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ə yalnız 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ə bağlanacağına 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 - İP, 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 obyekt verəcək - . Bu dəqiq format deyil, sadəcə diaqramdır. Əgər p2 qovşağındayıqsa, o zaman namizəd . Siqnal mexanizmi vasitəsilə p1 p2-nin namizədini alacaq (yəni p2 nodeunun yerini, yəni onun IP və PORT-unu). Sonra p1 birbaşa p2-yə qoşula bilər. Daha doğrusu, p1 p2-ə çatacağı ümidi ilə məlumatları 10.50.150.3:531-ə göndərəcək. Bu ünvanın p2 node 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-yə ç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.

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ə) yerləşəcək (Şəkil 9).

Şəkil 9: Bir node NAT-ın arxasındadır, digəri isə yoxdur

Bu işin problemin xüsusi həlli var, indi nəzərdən keçirəcəyik. 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 bir mexanizmdir.

Fərz edək ki, veb-server birbaşa İnternetə qoşulub, yəni ictimai IP * ünvanına malikdir. Bu p2 node olsun. Node p1 (veb müştəri) 10.50.200.10 ünvanına sorğu göndərir. Birincisi, məlumatlar r1 marşrutlaşdırıcısına, daha doğrusu ona gedir 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ə, öz yolumda 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. Qayıdış ünvanında olduğu üçün r1-i marşrutlaşdırıcıya göndərir (marşrutlaşdırıcı ünvanı öz ünvanı ilə əvəz etdi). Router məlumatları qəbul edir, NAT cədvəlinə baxır və məlumatları p1 qovşağına ötürür. Router burada vasitəçi kimi çıxış edir.

Daxili şəbəkədən bir neçə qovşaq eyni vaxtda xarici şəbəkəyə daxil olarsa nə olar? Router cavabı kimə göndərəcəyini necə başa düşəcək? Bu problem istifadə edərək 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ı paketin kimə təyin edildiyini port vasitəsilə başa düşəcəkdir. Aşağıdakı nümunə.

Gəlin WebRTC texnologiyasına, daha dəqiq desək, onun ICE protokolundan istifadə edən hissəsinə (buna görə də Ice namizədləri) qayıdaq. p2 qovşağının bir namizədi var (şəbəkədəki yeri 10.50.200.10), NAT ilə marşrutlaşdırıcının arxasında yerləşən p1 nodunun 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ır, çünki WebRTC hələ uzaq node 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 (NAT-dan keçmək üçün) mühüm rol oynayacaq.

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 növbədə məlumatları ötürməlidir və yalnız bundan sonra p2 qovşağından gələ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 onunla bağlıdır ki, qovşaqlar öz xarici IP ünvanlarını bilmirlər və məlumatların daxili ünvanlara göndərilməsi mənasızdır.

Ancaq xarici ünvanlar məlum olarsa, əlaqə asanlıqla qurulacaq. Əgər birinci qovşaq məlumatı ikinci qovşağın marşrutlaşdırıcısına göndərirsə, onun NAT cədvəli hələ də boş olduğu üçün marşrutlaşdırıcı ona məhəl qoymayacaq. Bununla birlikdə, birinci nodun marşrutlaşdırıcısında NAT cədvəlində zəruri 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ə, o zaman marşrutlaşdırıcı onu uğurla birinci qovşağa ötürəcək. İndi ikinci marşrutlaşdırıcının NAT cədvəlində də lazımi məlumatlar var.

Problem ondadır ki, xarici IP ünvanınızı tapmaq üçün sizə bir node lazımdır paylaşılan şəbəkə. Bu problemi həll etmək üçün birbaşa İnternetə qoşulan əlavə serverlərdən istifadə olunur. Onların köməyi ilə NAT cədvəlində qiymətli qeydlər də yaradılır.

STUN və TURN serverləri

WebRTC-ni işə salarkən, mövcud STUN və TURN serverlərini təyin etməlisiniz, biz bundan sonra ICE serverləri adlandıracağıq. Əgər serverlər göstərilməyibsə, onda yalnız eyni şəbəkədəki (NAT olmadan ona qoşulmuş) qovşaqlar qoşula biləcək. 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 qayıdış ünvanını, yəni göndərənin qovşağının ünvanını qaytaran bir serverdir. Routerin arxasındakı host NAT-ı keçmək üçün STUN serveri ilə əlaqə saxlayır. STUN serverinə gələn paket mənbə ünvanını - marşrutlaşdırıcının ünvanını, yəni qovşağımızın xarici ünvanını ehtiva edir. Bu, serverin geri göndərdiyi STUN ünvanıdır. Beləliklə, qovşaq öz xarici IP ünvanını və şəbəkədən daxil olduğu portu alır. Sonra, WebRTC əlavə namizəd (xarici marşrutlaşdırıcı ünvanı və port) yaratmaq üçün bu ünvandan istifadə edir. İndi marşrutlaşdırıcının NAT cədvəlində tələb olunan portdakı marşrutlaşdırıcıya göndərilən paketlərin qovşağımıza çatmasına imkan verə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-dən, node isə p1-dən keçir. Siz həmçinin NAT cədvəlinə nəzarət etməlisiniz - biz onu r1_nat kimi qeyd edəcəyik. Üstəlik, bu cədvəl adətən alt şəbəkənin müxtəlif qovşaqlarından çoxlu qeydləri ehtiva edir - onlar verilməyəcək.

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

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

Node p1 bu paketi r1 marşrutlaşdırıcısına göndərir (necə olursa olsun, müxtəlif alt şəbəkələr istifadə edə bilər müxtəlif texnologiyalar). Router Src IP mənbə ünvanını dəyişdirməlidir, çünki paketdə göstərilən ünvan açıq şəkildə xarici alt şəbəkə üçün uyğun deyil; üstəlik, belə bir diapazondan ünvanlar qorunur və İnternetdə heç bir ünvanda belə bir ünvan yoxdur. Router paketdə bir əvəz edir və yaradır yeni giriş cədvəlinizdə 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ə ki, marşrutlaşdırıcı bu bir neçə qovşaqdan hansının serverdən qaytarılan paket üçü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. Əslində, postbacking 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 qovşağının ə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-yə dəyişdiriləcək port 888.

Beləliklə, marşrutlaşdırıcı paket başlığında mənbə ünvanı və portu əvəz etdi və NAT cədvəlinə bir giriş əlavə etdi. İndi paket şəbəkə üzərindən serverə, yəni s1 qovşağına göndərilir. Girişdə s1 aşağıdakı 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 server paketi qəbul etdi

Ümumilikdə STUN serveri 10.50.200.5:888 ünvanından paket aldığını bilir. İndi server bu ünvanı geri göndərir. Burada dayanıb indicə baxdıqlarımıza bir daha nəzər salmağa dəyər. Yuxarıdakı cədvəllər bir parçadır 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; protokollar adətən qovşaq ünvanları haqqında məlumatlara əhəmiyyət vermir; yalnız paketlərin nəzərdə tutulmuş təyinat yerinə çatdırılması vacibdir. Burada iki qovşaq arasında yol quran bir protokola baxırıq.

Beləliklə, indi əks istiqamətdə gedən ikinci bir paketimiz 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ə boyunca hərəkət edir. Router paketin bunun üçün nəzərdə tutulmadığını başa düşür. Bunu necə başa düşür? Bu yalnız port tərəfindən müəyyən edilə 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 PORTuna uyğun gələn sətir 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əxtimiz gətirdi, belə bir xətt var. Bəxtimiz gətirməsəydi, paket sadəcə atılacaqdı. İndi bu paketi alt şəbəkənin hansı node göndərməli olduğunu başa düşməlisiniz. Tələsməyə ehtiyac yoxdur, bu mexanizmdə limanların əhəmiyyətini bir daha xatırlayaq. Eyni zamanda, alt şəbəkədəki iki qovşaq xarici şəbəkəyə sorğu göndərə bilər. Sonra, marşrutlaşdırıcı birinci qovşaq üçün 888 portu ilə gəldisə, ikincisi üçün 889 portu ilə çıxacaq. Tutaq ki, bu baş verib, yəni r1_nat cədvəli belə görünür:

Cədvəl 10: Router qəbuledici ünvanını əvəz edir

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 baxmaqla qovşaq özünün xarici IP ünvanını, yəni xarici şəbəkədəki marşrutlaşdırıcının ü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 qeyddir. Əgər indi hər kəs r1 marşrutlaşdırıcısına 888 portu olan paket göndərirsə, o zaman marşrutlaşdırıcı bu paketi p1 qovşağına yönləndirəcək. Bu, p1 gizli node üçün kiçik bir dar keçid yaratdı.

Yuxarıdakı nümunədən NAT-ın necə işləməsi və STUN serverinin mahiyyəti haqqında bir fikir əldə edə bilərsiniz. Ümumiyyətlə, ICE mexanizmi və STUN/TURN serverləri dəqiq olaraq NAT məhdudiyyətlərini aradan qaldırmağa yönəlib.

Düyün və server arasında bir deyil, bir neçə marşrutlaşdırıcı ola bilər. 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. P2p rabitəsi üçün, hər bir marşrutlaşdırıcının NAT cədvəlinə lazım olan xətti əlavə edəcəyini unutmasaq, bizə lazım olan budur. Buna görə də, geri dönüş yolu yenə hamar olacaq.

TURN server təkmilləşdirilmiş STUN serveridir. Buradan hər hansı TURN serverinin STUN serveri kimi də işləyə biləcəyini dərhal götürməlisiniz. Bununla belə, üstünlükləri də 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ə keçir, yəni vasitəçi kimi işləyir. Əlbəttə ki, o zaman hər hansı bir 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.

Hansı hallarda TURN serveri lazımdır? Niyə kifayət qədər STUN server yoxdur? Fakt budur ki, NAT-ın bir neçə növü var. Onlar IP ünvanını və portunu eyni şəkildə əvəz edirlər, lakin bəzilərinin içərisinə quraşdırılmış "saxtalaşdırma" dan ə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, "saxtalaşdırıldığı" üçün onu rədd edir. Bu STUN serverindən gəlməyib.

Beləliklə, hər iki həmsöhbətin arxasında olduğu halda TURN serverinə ehtiyac var simmetrik NAT (hər biri özünə görə).

Qısa xülasə

Burada həmişə yadda saxlamalı olduğunuz WebRTC qurumları haqqında bəzi ifadələr verilmişdir. 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 paketlənir
  • Media axınları təşkil edən media yollarını sinxronlaşdırır
  • Müxtəlif media axınları bir-biri ilə sinxronlaşdırılmır
  • Media axınları yerli və uzaq ola bilər, yerli adətən kamera və mikrofona 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 halında yerli media axınından istifadə etmədən mümkün deyil və cavab olduqda isə uzaqdan seans deskriptorundan istifadə etmədən mümkün deyil.
  • Nəticə 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
  • 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 də WebRTC tətbiqlərinə keçməlidirlər, lakin yalnız uzaq olanlar
  • Bəzi WebRTC tətbiqlərində namizədlər yalnız sessiya deskriptoru təyin edildikdən sonra ötürülə bilər
• SUN/DÖNÜŞ/BUZ/NAT
  • NAT xarici şəbəkəyə çıxışı təmin edən mexanizmdir
  • 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ə gedirsə, mənbə ünvanını özü ilə və paket xarici şəbəkədən gələrsə, qəbuledici ünvanını 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 - NAT Traversal Mühərriki
  • STUN və TURN serverləri – NAT keçidi üçün köməkçi serverlər
  • 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 konservativ texnologiyalar qeydə alınmış məzmunun (tələb üzrə video) yayılması üçün daha münasibdir 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. izləyicilərə baş verənləri “canlı” görməyə imkan vermək üçün minimum video gecikməsi tələb olunur.

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.

Rabitə gecikməsi onlayn yayım sistemlərində, vebinarlarda və video mənbəyi, son istifadəçilərlə interaktiv əlaqə tələb edən və həll tələb edən digər proqramlarda vacibdir.

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

WebRTC texnologiyasını sınamaq və işlətmək üçün sadədir onlayn yayım, biz Flashphoner WebRTC Media & Broadcasting 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 nəzarət sistemləri üçün dəstək; 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 istəmədim, ona görə də evdə onlayn yayımları sınaya bildim 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:

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 yeganə şey server və ona ssh girişidir. Bilənlər üçün konsol əmrləri Linux, WebRTC serverinin quraşdırılması sadə və ağrısız olmağı vəd edir. Beləliklə, biz nə etdik:

1. Arxivi yükləyin:

$wget https://site/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 onlayn 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ə qura bilsin. Test prosesini təsvir edək.

1. Chrome brauzerində index.html test müştəri 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ə istifadəyə hazır olduğundan əmin olmalısınız. Veb-kamera üçün xüsusi tələblər yoxdur, məsələn, biz 1280x800 təsvir ölçülü noutbuka quraşdırılmış standart kameradan istifadə etdik.

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

3. İnterfeys video axınının kameradan WebRTC serverinə uğurlu yayımını təmsil edir. Yuxarı sağ küncdə bir göstərici axının serverə getdiyini göstərir, aşağı küncdə videonun göndərilməsini dayandırmaq üçün "Stop" düyməsi var.

Aşağıdakı qutuda olan linkə diqqət yetirin. O, bu yayım üçün unikal identifikatoru ehtiva edir, beləliklə, hər kəs baxışa qoşula bilər. Sadəcə bu linki brauzerinizdə açın. Onu panoya kopyalamaq üçün “Kopyala” düyməsini sıxın.

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, artıq 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, aşağı sağ küncdəki idarəetmə elementlərindən istifadə edərək başqa birinə keçid göndərə, yayımı dayandıra və ya tam ekran rejimini aktivləşdirə bilər.

WebRTC onlayn yayım serverinin sınaq 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əz idi. 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ə: belə testlərdə Flash özünü WebRTC kimi yaxşı aparmır. Belə ki, əlinizi oxşar şəbəkədə hərəkət etdirsəniz, ekrandakı hərəkət yalnız bir və ya iki saniyədən sonra görünə bilər.

Keyfiyyətə gəlincə, qeyd edirik ki, kublar bəzən hərəkətlərlə fərqlənə bilər. Bu, VP8 kodekinin təbiətinə və onun əsas məqsədinə uyğundur - məqbul keyfiyyətlə və rabitə gecikmələri olmadan real vaxt rejimində video rabitəni təmin etmək.

Serveri quraşdırmaq və konfiqurasiya etmək olduqca asandır; onu idarə etmək ssh vasitəsilə konsoldan əmrləri yerinə yetirə və istifadə edə bilən qabaqcıl istifadəçi səviyyəsində Linux biliklərindən başqa heç bir ciddi bacarıq tələb etmir. 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 heç bir problem yaratmadı.

Yayım keyfiyyəti vebinarlar və onlayn yayımlar üçün olduqca məqbul olduğu ortaya çıxdı. Bəzi suallar doğuran yeganə şey videonun həlli oldu. Kamera 1280x800-ü dəstəkləyir, lakin test şəklindəki 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ə məlum oldu ki, plaginlər və sol virtual maşınlar Onlar rahatlıqla parıldamırlar (niyə ümumiyyətlə bir şey quraşdırmalıyam?) Və ən əsası təhlükəsizliklə. Nə etməli? Çıxış var!

Son vaxtlara qədər İP şəbəkələri İP telefoniya və ya video üçün bir neçə protokoldan istifadə edirdi: SIP, ən çox yayılmış protokol, H.323 və səhnədən çıxan MGCP, Jabber/Jingle (Gtalk-da istifadə olunur), yarı açıq Adobe RTMP* və təbii ki. , Skype-ı bağladı. Google-un təşəbbüsü ilə həyata keçirilən WebRTC layihəsi IP və veb-telefoniya dünyasındakı vəziyyəti dəyişməyə çalışır. softfonlar Skype daxil olmaqla. WebRTC təkcə indi demək olar ki, hər bir cihazda quraşdırılmış brauzerin daxilində bütün kommunikasiya imkanlarını həyata keçirməklə kifayətlənmir, eyni zamanda brauzer istifadəçiləri arasında daha ümumi ünsiyyət problemini həll etməyə çalışır (müxtəlif məlumatların mübadiləsi, ekran yayımı, sənədlərlə əməkdaşlıq və daha çox).

Veb tərtibatçısı baxımından 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 rozetkalarından istifadə edərək WebRTC əsasında brauzerlər arasında sadə çox istifadəçili video söhbəti 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 sınaqlara başlayacağıq. 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.

MediaStream

İlk və ən sadə WebRTC komponenti MediaStream-dir. O, brauzerə yerli kompüterin kamerasından və mikrofonundan media axınlarına giriş imkanı verir. Chrome-da bunun üçün navigator.webkitGetUserMedia() funksiyasına zəng etməlisiniz (standart hələ yekunlaşmadığından bütün funksiyalar prefikslə gəlir və Firefox-da eyni funksiya navigator.mozGetUserMedia() adlanır). Zəng etdiyiniz zaman 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 giriş uğurla əldə edildikdə, ikincisi xəta baş verdikdə çağırılacaq. Əvvəlcə düymə və elementi olan rtctest1.html HTML faylını yaradaq:

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

Microsoft CU-RTC-Web

CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web) adlı öz uyğun olmayan qeyri-standart variantını buraxmaqla Google-un təşəbbüsünə dərhal cavab verməsəydi 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 sıxışdırmağa ümid verir və güman etmək olar ki, bu xüsusi standart brauzerdə istifadə olunacaq. Skype versiyaları. Google standartı ilk növbədə brauzerlər arasında ünsiyyətə yönəlib; 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 bilməz, 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 Yayım aktiv edilir

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

Var localStream = null;

getUserMedia metodunun ilk parametri tələb olunan media axınının parametrlərini müəyyən etməlidir - 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": doğru, "video": ( "məcburi": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "optional": ) );

getUserMedia metodunun ikinci parametri geri çağırış funksiyasına ötürülməlidir, o, uğurlu olarsa, çağırılacaq:

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ə yadda saxlayın 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ş sorğusudur.

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, səhv alacağı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 daxil ola biləcəyi cihazları Parametrlər, Qabaqcıl parametrləri göstər linki, Məxfilik bölməsi, Məzmun düyməsini seçə bilərsiniz. Firefox və Opera brauzerlərində cihazlar girişə icazə verildikdə 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 dəfə daxil olduqda göstərməyə imkan verəcək.

Əlfəcin işarəsindəki pulsasiya edən dairəyə və ünvan çubuğunun sağ tərəfindəki kamera işarəsinə diqqət yetirin:

RTMediaConnection

RTTCMediaConnection iştirakçılar arasında şəbəkə üzərindən media axınlarını qurmaq və ötürmək üçün nəzərdə tutulmuş obyektdir. Bundan əlavə, bu obyekt media sessiyasının təsvirini (SDP) yaratmaq, NAT və ya keçmək üçün ICE namizədləri haqqında məlumat əldə etmək üçün məsuliyyət daşıyır. təhlükəsizlik divarları(yerli və STUN-dan istifadə) 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 protokolundan istifadə etməklə ötürülür.

serverləri TURN

ICE namizədlərinin üç növü var: host, srflx və relay. Host yerli olaraq alınan məlumatları ehtiva edir, srflx - node xarici serverə (STUN) bənzəyir və relay - TURN serveri vasitəsilə trafikin proksiləşdirilməsi üçün məlumat. Əgər qovşağımız NAT-ın arxasındadırsa, o zaman host namizədləri ehtiva edəcək 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 ilə host tipli ICE namizədinin nümunəsi:

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. Məsələn, böyük bir siyahı var. Təəssüf ki, çox az problemi həll edirlər. STUN-dan fərqli olaraq, praktiki olaraq heç bir ictimai TURN serverləri yoxdur. Bu, TURN serverinin həm şəbəkə kanalını, həm də serverin özünü əhəmiyyətli dərəcədə yükləyə bilən media axınlarından keçməsi ilə əlaqədardı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. 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əsi (NAT) və firewall vasitəsilə keçid keyfiyyətinə görə Skype-a bərabər olmasa da. , ən azı nəzərə çarpacaq dərəcədə yaxınlaşacaq.

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

Köçürmə metodunun seçimi tərtibatçıya aiddir - ən azı əl ilə. Lazımi məlumatların mübadiləsi baş verən kimi RTTCMediaConnection avtomatik olaraq media axınlarını quraşdıracaq (əlbəttə ki, mümkünsə).

təklif-cavab modeli

Media axınlarını yaratmaq və dəyişdirmək üçün təklif/cavab modeli (RFC3264-də təsvir edilmişdir) və SDP (Sessiya Təsviri Protokolu) istifadə olunur. Onlar həmçinin SIP protokolu tərəfindən istifadə olunur. Bu modeldə iki agent var: Təklif - yenisini yaratmaq və ya mövcudunu dəyişdirmək üçün sessiyanın SDP təsvirini yaradan (Təklif SDP) və Cavab verən - sessiyanın SDP təsvirini başqa agent və öz sessiya təsviri ilə cavab verir (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-rozetləri).

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şulmanı başlatan ilk iştirakçı, ö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 yaradır. Bu məlumat bloku ikinci iştirakçıya ötürülməlidir. İkinci iştirakçı SDP ilə Cavab yaradır və onu 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çı onlara media axını ö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.

Formasiya Təklifi

Təklif yaratmaq üçün bizə iki funksiya lazımdır. Birincisi uğurla formalaşarsa, çağırılacaqdır. CreateOffer() metodunun ikinci parametri onun icrası zamanı xəta baş verdikdə çağırılan geri çağırış funksiyasıdır (bir şərtlə ki, yerli ip artıq mövcuddur).

Ə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. HTML-ə elementləri olan sətirlərdən sonra 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:

Var pc1;

RTCPeerConnection konstruktorunu çağırarkən siz STUN/TURN serverlərini təyin etməlisiniz. Onlar haqqında ə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 serverləri = null;

Təklif SDP hazırlamaq üçün parametrlər

Var təklif Məhdudiyyətləri = ();

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); // Off RTCPeerConnection DP tərəfindən yaradılıb. setLocalDescription metodundan istifadə etməklə. // 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 biz heç nə etmirik // pc2_receivedOffer(dec); )

İ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); )

Gəlin, ICE namizədlərinin təyin olunduqları kimi keçiləcəkləri geri çağırış funksiyasını elan edək:

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ə etmirik // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Həm də uzaq tərəfdən media axını əlavə etmək üçün geri çağırış funksiyası (gələcək üçün, çünki hələlik bizdə 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 biz RTCPeerConnection yaradacağıq, onicecandidate və onaddstream metodlarını təyin edəcəyik və createOffer() metoduna zəng edərək Təklif SDP-nin formalaşmasını tələb edəcəyik:

Funksiya createOffer_click() ( console.log("createOffer_click()"); pc1 = yeni webkitRTCPeerConnection(serverlər); // RTCPeerConnection yaradın pc1.onicecandidate = pc1_onicecandidate; // ICE namizədlərinin işlənməsi üçün geri çağırış funksiyası //_ddstreona pc1streamc;amc1. Uzaq tərəfdən media axını görünəndə geri çağırış funksiyası çağırılır.Hələ yoxdur pc1.addStream(localStream); // Yerli media axınını ötürək (artıq qəbul olunub) pc1.createOffer(// Və əslində sorğu Təklifin formalaşması pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )

Faylı rtctest2.html kimi saxlayaq, serverə yükləyək, brauzerdə açaq və konsolda onun işləməsi zamanı hansı verilənlərin əmələ gəldiyinə baxaq. İkinci video hələ görünməyəcək, çünki yalnız bir iştirakçı var. Xatırladaq ki, SDP media sessiyasının parametrlərinin təsviridir, mövcud kodeklər, media axınları və ICE namizədləri müəyyən bir 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ə onları aldıqdan sonra RTCPeerConnection uzaq tərəfdən alınan hər bir ICE namizədi üçün Təklif SDP və addIceCandidate üçün setRemoteDescription metodlarını çağırır; 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, çağırılan createOffer metodu deyil, createAnswer metodudur və bundan əvvəl RTCPeerConnection metodu setRemoteDescription zəng edəndən alınan Təklif SDP-yə ötürülür.

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

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

Var pc2;

Təklif və Cavab SDP emal olunur

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

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

Cavab yaratarkən 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-nin formalaşdırılması üçün parametrlər:

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

İkinci iştirakçı Təklifi aldıqda, biz RTCPeerConnection yaradacaq və Təkliflə eyni şəkildə Cavab formalaşdıracağıq:

Funksiya pc2_receivedOffer(az) ( console.log("pc2_receiveOffer()", desc); // Birinci iştirakçı ilə eyni şəkildə ikinci iştirakçı üçün RTCPeerConnection obyekti yaradın pc2 = yeni webkitRTCPeerConnection(serverlər); pc2.onicecandidateec =pc2.onecandidateec ; // ICE namizədi görünəndə hadisə idarəedicisini təyin edin pc2.onaddstream = pc_onaddstream; // Axın görünəndə onu HTML pc2.addStream(localStream) ilə birləşdirin); // Yerli media axınını köçürün (nümunəmizdə, ikinci iştirakçı birinci ilə eynidir) // İndi, ikinci RTCPeerConnection hazır olduqda, biz ona qəbul edilmiş Təklif SDP-ni ötürəcəyik (biz yerli axını birinciyə ötürdük) pc2.setRemoteDescription(yeni RTCSessionDescription(az)); // Cavab mesajı üçün məlumat yaratmaq üçün ikinci əlaqəni tələb edin pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); )

Nümunəmizdə Təklif SDP-ni birinci iştirakçıdan ikinciyə köçürmək üçün onu pc1 funksiyasında şərhdən çıxaraq. Təklif yaradın müvəffəqiyyət () zəng xətti:

Pc2_receivedOffer(az);

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

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

İkinci iştirakçının ICE namizədinə hazırlıq tədbiri idarəedicisi birinciyə bənzəyir:

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-ə başqa bir düymə əlavə edək

Dayan

Və əlaqəni dayandırmaq üçü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-dən videonu deaktiv edin elementlər, əlaqəni bağlayın, göstəricini təyin edin = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )

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

Ekran yayımı

getUserMedia funksiyası həmçinin aşağıdakı parametrləri təyin etməklə ekranı və axını MediaStream kimi çəkə bilər:

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

Ekrana uğurla daxil olmaq üçü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 bir brauzer nişanında icra edilməməlidir.

WebRTC üçün kitabxanalar

WebRTC hələ bitməsə də, 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ı asanlaşdıracaq, 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ə vasitəsilə 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 modulunu quraşdıracağıq:

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

Server tərəfi üçün nodetest2.js faylı yaradaraq onu sınaqdan keçirək:

$ 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ı göndərin ) ); io.sockets.on("bağlantı", funksiya (soket) ( // Qoşularkən 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("/"); // Websocket 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-rozetkalar vasitəsilə RTCPeerConnection arasında məlumat mübadiləsi Müştəri hissəsi

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

JavaScript skriptinin əvvəlində - veb-soketlərə qoşulma:

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-rozetkalar vasitəsilə mesaj ötü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ının daxilində yadda saxlayın, biz müştəri mesajlarının qəbulu və göndərilməsini əlavə edəcəyik:

Socket.on("təklif", funksiya (data) ( // "Təklif" mesajını aldıqda, // bu misalda yalnız bir müştəri bağlantısı olduğundan, // mesajı eyni rozetka vasitəsilə geri göndərəcəyik. .emit("offer" , data); // Əgər mesajı bütün bağlantılar üzərindən yönləndirmək lazım olsa, // göndərəndən başqa: // soket.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şdirək:

// res.sendfile(__dirname + "/nodetest2.html"); // HTML faylını göndər res.sendfile(__dirname + "/rtctest4.html");

Serverin işə salınması:

$ sudo nodejs nodetest2.js

Hər iki müştərinin kodunun eyni brauzer nişanı daxilində yerinə yetirilməsinə baxmayaraq, nümunəmizdəki iştirakçılar arasında bütün qarşılıqlı əlaqə tamamilə şəbəkə üzərindən həyata keçirilir və iştirakçıları "ayırmaq" heç bir xüsusi çətinlik tələb etmir. Bununla belə, bizim gördüyümüz iş də çox sadə idi - bu texnologiyalar yaxşıdır, çünki istifadə etmək asandı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 şərtidir, lakin hadisə idarəçilərini bir az universallaşdırsaq ki, zəng edən və çağırılan tərəf arasında fərq olmasın, 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ə edəcəksiniz. WebRTC ilə əlaqəli heç bir xüsusi xüsusiyyət yoxdur və jurnalla birlikdə gələn diskdə bir neçə iştirakçı üçün sadə video söhbət nümunəsi (həmçinin məqalədəki bütün nümunələrin mətnləri) var. Bununla belə, İnternetdə artıq çox şey tapa bilərsiniz. yaxşı nümunələr. Xüsusilə, məqalənin hazırlanmasında 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ə İnterneti bütövlükdə qavrayış tərzimizdə inqilab olacağını güman etmək olar. WebRTC təkcə brauzerdən brauzerə zənglər üçün texnologiya kimi deyil, həm də real vaxt rejimində rabitə texnologiyası kimi yerləşdirilib. Müzakirə etdiyimiz video rabitə yalnız kiçik bir hissədir mümkün variantlar onun istifadəsi. Artıq skrincasting 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.