WebRTC əsasında həmyaşıd video çat. WebRTC Webrtc quraşdırılmasına əsaslanan P2P video söhbəti

Avropa internet istifadəçiləri iki hissəyə bölünür: Allenbach (Almaniya) İctimai Rəyin Təhlili İnstitutunun sorğusuna əsasən, Skype, chat və ani mesajlaşma sistemləri internetin ayrılmaz hissəsinə çevrilib. Gündəlik həyat 16,5 milyon böyük və uşaq üçün 9 milyonu bu xidmətlərdən vaxtaşırı istifadə edir, 28 milyonu isə onlara toxunmur.

Firefox indi inteqrasiya etdikcə bu dəyişə bilər real vaxt rabitə texnologiyası (WebRTC), həmçinin müştərinin özü. Audio və video söhbətə başlamaq indi vebsayt açmaqdan çətin deyil. Facebook və Skype kimi xidmətlər isə ayrı bir müştəridən istifadə etməklə və hesab yaratmaqla həll yollarına əsaslanır.

WebRTC təkcə istifadə rahatlığı ilə seçilmir. Bu üsul hətta quraşdırmaq imkanı verir iki brauzer arasında birbaşa əlaqə. Bu yolla, audio və video məlumatları həddən artıq yüklənmənin ola biləcəyi və ya administratorun məxfiliyə və ya məlumatların qorunmasına xüsusilə həssas olmadığı serverdən keçmir. Birbaşa əlaqə sayəsində WebRTC nə qeydiyyat, nə də qeydiyyat tələb etmir Hesab istənilən xidmətdə.

Söhbətə başlamaq üçün sadəcə linki izləmək lazımdır. Rabitə özəl olaraq qalır, məlumat axını şifrələndiyi üçün. Google 2011-ci ildə WebRTC tətbiqinin mənbə kodunu dərc edərkən brauzer vasitəsilə real vaxt rejimində əlaqə yaratmağa başladı.

Bundan qısa müddət sonra Chrome və Firefox öz WebRTC mühərriklərini aldılar. Hazırda onların mobil versiyaları həm bu texnologiya, həm də proqramlar tərəfindən istifadə edilən Android 5.0 ilə quraşdırılmış WebView 3.6 mühərriki ilə təchiz edilib.

Real vaxt rejimində ünsiyyət üçün müvafiq JavaScript interfeysləri veb görüntüləyicidə tətbiq edilməlidir. GetUserMedia istifadə edərək proqram təminatı audio və video mənbələrindən, yəni veb-kameradan və mikrofondan çəkilişi aktivləşdirir. RTCPeerConnection əlaqənin qurulmasına, eləcə də rabitənin özü üçün cavabdehdir.

Brauzerə inteqrasiya ilə paralel olaraq Konsorsium işçi qrupu World Wide Web(W3C) WebRTC standartlaşdırma prosesini sürətləndirdi. 2015-ci ildə tamamlanmalıdır.

WebRTC az şeylə kifayətlənir

WebRTC xidmətindən istifadə etmək çoxlu resurs tələb etmir, çünki server yalnız həmsöhbətləri birləşdirir. Bir əlaqə yaratmaq da xüsusilə çətin deyil. Birincisi, brauzer WebRTC serverinə zəng vurmağı planlaşdırdığını bildirir. O, serverdən HTTPS linki alır - rabitə şifrələnir. İstifadəçi bu linki həmsöhbətinə göndərir. Bundan sonra brauzer istifadəçidən veb-kamera və mikrofona daxil olmaq üçün icazə istəyir.

Həmsöhbətlə birbaşa axın əlaqəsi yaratmaq üçün brauzer IP ünvanını və konfiqurasiya məlumatlarını WebRTC xidmətindən alır. Digər şəxsin veb izləyicisi də eyni şeyi edir.

Axın bağlantısının rəvan və keyfiyyətli işləməsi üçün brauzerdə üç mühərrik işləyir. Onlardan ikisi audio və video məlumatlarını optimallaşdırır və sıxışdırır, üçüncüsü onların daşınmasına cavabdehdir. vasitəsilə məlumat göndərir SRTP protokoluŞifrələnmiş real vaxt axınına imkan verən (Secure Real-time Transport Protocol).

Birbaşa əlaqə qurmaq mümkün deyilsə, WebRTC başqa yol axtarır. Məsələn, bu zaman baş verir şəbəkə parametrləri STUN serverinin IP ünvanını bildirməsinə mane olur. WebRTC standartı, bu halda söhbətin TURN serverinin aralıq aktivləşdirilməsi ilə (NAT ətrafında keçiddən istifadə edərək) baş tutacağını nəzərdə tutur. Beləliklə, netscan.co saytında WebRTC-nin kompüterinizdə tətbiq edilib-edilmədiyini və Şəbəkəyə girişinizin olub olmadığını yoxlaya bilərsiniz.

Bağlantı necə qurulur

Əvvəlcə söhbəti qeydiyyatdan keçirməlisiniz (1). WebRTC xidməti həmsöhbətə göndərilməli olan bir keçid təqdim edir. Brauzer, STUN serverindən istifadə edərək, öz IP ünvanını (2) tapır, onu xidmətə göndərir və birbaşa əlaqə yaratmaq üçün tərəfdaşın IP-sini alır (3). STUN uğursuz olarsa, söhbət TURN serverindən istifadə etməklə yönləndirilir (4).

Brauzerdə WebRTC texnologiyasından istifadə edən rabitə JavaScript kodundan istifadə etməklə işə salınır. Bundan sonra rabitə üçün üç mühərrik cavabdehdir: səs və video mühərrikləri veb-kameradan və mikrofondan multimedia məlumatlarını toplayır, nəqliyyat mühərriki isə məlumatları birləşdirir və SRTP (Secure Real-time Protocol) istifadə edərək axını şifrələnmiş formada göndərir.

WebRTC ilə hansı brauzerlər işləyir

Chrome və Firefox-da talky.io kimi xidmətlərdən istifadə edən WebRTC mühərriki var. Mozilla brauzeri birbaşa öz müştərisi ilə işləyə bilər.

Google və Mozilla real vaxt rejimində ünsiyyət ideyasını inkişaf etdirməyə davam edir: Chrome bir çox iştirakçı ilə WebRTC konfranslarına ev sahibliyi edə bilər və Firefox-un yeni Hello müştərisi telekommunikasiya nəhəngi Telefonica-nın törəmə şirkəti ilə əməkdaşlıqda hazırlanıb. Apple hələlik kənarda qalır; Safari-də WebRTC-ni hələ gözləməməlisiniz. Bununla belə, çoxdur alternativ tətbiqlər iOS üçün və Safari üçün plaginlər.

Microsoft bir az fərqli kurs keçir. Bir rəqabət sahibi kimi Skype xidməti bu şirkət WebRTC-yə o qədər də asanlıqla təslim olmaq fikrində deyil. Bunun əvəzinə Microsoft ORTC (Object Real-Time Communications) adlı texnologiyanı inkişaf etdirir. internet Explorer.

Server ilə əlaqə yaratmaq üçün müxtəlif kodeklər və protokollar kimi WebRTC-dən fərqlər cüzidir və zaman keçdikcə bu fərqləri özündə birləşdirən WebRTC standartına əlavə çevriləcək. Beləliklə, yalnız Apple geridə qalır - həmişəki kimi.

Şəkil: istehsal şirkətləri; goodluz/Fotolia.com

Materialın çoxu üzərində WebRTC kodlaşdırmanın tətbiqi səviyyəsinə diqqət yetirir 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, nə üçün lazım olduğunu öyrənək. SUN Və TURN server.

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əyi (kimi üçüncü tərəfin tətbiq etdiyi texnologiyalara ehtiyac yoxdur adobe flash ) və əlavə serverlərdən istifadə etmədən müştəriləri birləşdirmək imkanı - əlaqə həmyaşıd(Daha, p2p).

Əlaqə qurun p2p- olduqca çətin bir işdir, çünki kompüterlər həmişə ictimai olmur IPünvanlar, yəni internetdəki ünvanlar. Az miqdarda olduğuna görə IPv4ünvanlar (və təhlükəsizlik məqsədləri üçün) mexanizmi işlənib hazırlanmışdır NAT, məsələn, evdə istifadə üçün şəxsi şəbəkələr yaratmağa imkan verir. Bir çox ev marşrutlaşdırıcıları indi dəstəkləyir NAT və bunun sayəsində bütün ev cihazlarının İnternetə çıxışı var, baxmayaraq ki, İnternet provayderləri adətən bunu təmin edirlər IPünvanı. İctimai IPünvanlar İnternetdə unikaldır, lakin şəxsi ünvanlar deyil. Buna görə də əlaqə saxlayın p2p- çətin.

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 şəxsi, digəri ictimaidir) (Şəkil 2) və hər iki qovşaq eyni ilə fərqli özəl şəbəkələrdədir 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 simvoldan ibarət qeyddəki ilk hərf düyünün növünü göstərir (p = həmyaşıd, r = marşrutlaşdırıcı). Birinci şəkildə vəziyyət əlverişlidir: onların şəbəkəsindəki qovşaqlar şəbəkə tərəfindən tam müəyyən edilir IPünvanlar və buna görə də bir-biri ilə birbaşa əlaqə qura 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 ikisi var IPünvanlar. 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. Şəbəkə xaricində kiməsə məlumat ötürsələr, yalnız istifadə edirlər NAT marşrutlaşdırıcının (router) içərisində və buna görə də altındakı başqalarına görünən IP marşrutlaşdırıcının ünvanı onlarındır xarici IPünvanı. Beləliklə, qovşaqda p1 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. Düyün üçün oxşar vəziyyət səh2. Buna görə də, yalnız daxili (öz) istifadə etsəniz, onların əlaqəsi mümkün deyil. IPünvanlar. 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 problem mexanizmdən istifadə etməklə həll edilir NAT

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 protokoldan istifadə edərək bu kimi problemlərin öhdəsindən uğurla gəlir ICE, lakin bu, əlavə serverlərin istifadəsini tələb edir ( SUN, TURN). Bütün bunlar haqqında daha ətraflı aşağıda.

WebRTC-nin iki mərhələsi

Protokol vasitəsilə iki nodu birləşdirmək üçün WebRTC(və ya sadəcə RTC, ikisi ünsiyyət qurarsa iPhone‘a) ə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əyə dəyər ki, texnologiya olsa da WebRTC işində çoxlarından 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 nodu birləşdirin p2p o qədər də asan deyil. Buna görə də bir az olmalıdır əlavə ilə heç bir əlaqəsi olmayan məlumatların ötürülməsi üsulu WebRTC. Bu, soket transferi, protokol ola bilər HTTP, hətta bir protokol ola bilər SMTP 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ə Buz namizədi. 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 bunu xatırlamaq vacibdir 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 - zəng edən):
  1. Video məlumat ötürülməsinə başlamaq təklifi (createOffer)
  2. Sizinkini almaq SDP SDP)
  3. Sizinkini almaq Buz namizədi Buz namizədi)
• Zəng gözləyir ( zəng edən):
  1. Yerli (sizin) media axınının qəbulu və ötürülməsi üçün qurulması (getUserMediaStream)
  2. Video məlumat ötürülməsinə başlamaq üçün təklifin alınması və cavabın yaradılması (Cavab yaratmaq)
  3. Sizinkini almaq SDP obyekt və onun siqnal mexanizmi vasitəsilə ötürülməsi ( SDP)
  4. Sizinkini almaq Buz namizədi obyektlər və onların siqnal mexanizmi vasitəsilə ötürülməsi ( Buz namizədi)
  5. 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 mərhələ Təklif yaradın və ya Cavab yaradınötürmə mərhələlərinə qoşulmalıdır SDP Və Buz namizədi obyektlər.

Əsas Müəssisələ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 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. IN WebRTC iplər üçün interfeys var MediaStream və alt interfeys də var LocalMediaStream xüsusilə yerli ip üçün. IN JavaScript yalnız birincisi ilə qarşılaşa bilərsiniz və istifadə etsəniz küsmək, onda ikincisi ilə qarşılaşa bilərsiniz.

IN WebRTC Mövzu daxilində olduqca qarışıq bir iyerarxiya var. Hər bir axın bir neçə media trekindən ibarət ola bilər ( MediaTrack), bu da öz növbəsində bir neçə media kanalından ibarət ola bilər ( MediaChannel). Ö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ə ikimiz olacaq MediaStream'a - 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 treki vasitəsilə həyata keçirilir MediaTrack. Media treklərinin xüsusi xüsusiyyəti var mehriban, qarşımızda nə olduğunu müəyyən edən - video və ya audio (Şəkil 5)

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

Proqramda hər şey necə olacaq? Biz iki 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 xüsusiyyəti var etiket– axı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 əmlakdan istifadə edə bilərsiniz aktivləşdirildi media izləri.

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 kanallardan istifadə olunur MediaChannel. 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 avtomatik edir və yaradır xüsusi obyekt– sessiya deskriptoru SDP. 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 şəxs tərəfindən (telefonla başqa bir node deyin) və ya Rusiya Postu ilə ötürülə bilər. Çox sadədir - onlar sizə hazır verəcəklər SDP və göndərilməlidir. Digər tərəfdən alındıqdan sonra - şöbəyə köçürün WebRTC. 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.

Adətən, bir əlaqə qurarkən, məsələn, bir növ ünvan göstərməlisiniz URL. Burada bu lazım deyil, çünki siqnal mexanizmi vasitəsilə siz özünüz məlumatları təyinat yerinə göndərəcəksiniz. Göstərmək WebRTC nə quraşdırmaq istəyirik p2pəlaqə yaratmaq üçün createOffer funksiyasını çağırmalısınız. Bu funksiyanı çağırdıqdan və ona xüsusi bir xüsusiyyət verdikdən sonra geri zəng et'a yaradılacaq SDP obyekt və eyni köçürülür geri zəng et. 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əlumat siqnal mexanizmi vasitəsilə digər tərəfə, yəni bu, gələcək SDP bir obyekt. 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. Özünüzə qayıdın geri zəng et yerli sessiya deskriptorunu keçəcək və onu siqnal mexanizmi vasitəsilə geri ötürmək lazımdır.

Qeyd etmək lazımdır ki, createAnswer funksiyasını yalnız başqasının funksiyasını aldıqdan sonra çağıra bilərsiniz SDP obyekt. Niyə? Çünki yerli SDP createAnswer çağırıldıqda yaradılacaq obyekt pultdan istifadə etməlidir SDP bir obyekt. 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 yazmaq üçün heç nələri olmayacaq. SDP bir obyekt.

ildən WebRTC redaktə etmək mümkündür SDP obyekt, sonra yerli tutacaq aldıqdan sonra quraşdırılmalıdır. Bunu çatdırmaq bir az qəribə görünə bilər WebRTCözü bizə nə verdi, 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 node 1 kodekləri dəstəkləyir A Və B, və düyün 2 kodekləri dəstəkləyir B Və C, onda hər bir qovşaq özünün və başqalarının deskriptorlarını bildiyi üçün hər iki qovşaq kodek seçəcək B(Şə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

Texnologiya WebRTC 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, daxili xüsusiyyətlərinə görə bir-biri ilə asanlıqla əlaqə qura bilirlər IPünvanlar (və ya istifadə olunmasa, başqa bir ünvana). TCP/IP).

Bir az sonra geri zəng et'Və WebRTC bizə deyir Buz namizədi obyektlər. 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. IN WebRTC 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 tətbiqlərdə WebRTC 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 yeri təkcə onun daxili deyil, müəyyən etmək olar IPünvan, həm də marşrutlaşdırıcının xarici ünvanı və mütləq yalnız bir deyil, həm də ünvanlar TURN serverlə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? İstifadə etməklə IPünvanlar. Başqa yol yoxdur. Düzdür, hələ də müxtəlif nəqliyyatlardan istifadə edə bilərsiniz ( TCP Və UDP) və müxtəlif portlar. Bu, namizəd obyektində olan məlumatdır - IP, PORT, NƏQLİYYAT və başqa biri. Məsələn, istifadə edək UDP nəqliyyat və 531 liman.

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

Sonra biz qovşağında olsaq p1, Bu WebRTC bizə belə bir namizəd obyekti keçəcək - . Bu dəqiq format deyil, sadəcə diaqramdır. Bir düyün içindəyiksə səh2, onda namizəd - . Siqnal mexanizmi vasitəsilə p1 namizəd qəbul edəcək səh2(yəni node yeri səh2, yəni onun IP Və PORT). Sonra p1 ilə əlaqə saxlaya bilər səh2 birbaşa. Daha doğrusu, p1ünvana məlumat göndərəcək 10.50.150.3:531 çatacaqları ümidi ilə səh2. Ünvan qovşağına aid olub-olmamasının əhəmiyyəti yoxdur səh2 ya da hansısa vasitəçi. Yeganə vacib olan məlumatların bu ünvan vasitəsilə göndərilməsi və çata bilməsidir səh2.

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 cədvəldən ibarətdir NAT. 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.

Tutaq ki, veb-server birbaşa internetə qoşulub, yəni ictimai var IP* ünvan. Qoy bu düyün olsun səh2. Düyün p1(veb müştəri) ünvana sorğu göndərir 10.50.200.10 . Əvvəlcə məlumatlar marşrutlaşdırıcıya gedir r1, daha doğrusu onun üzərində daxili interfeys 192.168.0.1 . Bundan sonra, marşrutlaşdırıcı mənbə ünvanı (ünvan p1) və onu xüsusi cədvələ daxil edir NAT, sonra mənbə ünvanını sizin ünvanınıza dəyişin( p1 → r1). Bundan əlavə, öz yolumda xarici interfeys, marşrutlaşdırıcı məlumatları birbaşa veb serverə göndərir səh2. Veb server məlumatları emal edir, cavab yaradır və geri göndərir. Routerə göndərilir r1, çünki o, qayıdış ünvanındadır (router ünvanı özü ilə əvəz etdi). Router məlumatları qəbul edir və cədvələ baxır NAT və məlumatları qovşağına ötürür p1. 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ə.

Texnologiyaya qayıdaq WebRTC, daha doğrusu, istifadə edən hissəsinə ICE protokol (deməli Buz namizədlər). Düyün səh2 bir namizəd var (şəbəkədəki yeri – 10.50.200.10 ) və düyün p1 NAT ilə marşrutlaşdırıcının arxasında yerləşən , iki namizəd 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 uzaq node haqqında hələ 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 (keçmək üçün NAT).

Cədvəl girişi NAT yalnız məlumatlar daxili şəbəkəni tərk etdikdə yaradılır. Buna görə də node p1əvvəlcə məlumatları və yalnız bundan sonra qovşaq məlumatlarını ötürməlidir səh2 qovşağına çata biləcək p1.

Təcrübədə hər iki qovşaq arxada qalacaq NAT. Cədvəldə qeyd yaratmaq üçün NAT hər bir marşrutlaşdırıcıdan, qovşaqlar uzaq qovşağa bir şey göndərməlidir, lakin bu dəfə nə birincisi ikinciyə çata bilər, nə də əksinə. Bu, qovşaqların xaricilərini bilməməsi ilə əlaqədardır IPünvanlar və məlumatların daxili ünvanlara göndərilməsi mənasızdır.

Ancaq xarici ünvanlar məlum olarsa, əlaqə asanlıqla qurulacaq. Birinci qovşaq məlumatı ikinci qovşağın marşrutlaşdırıcısına göndərirsə, marşrutlaşdırıcı ona məhəl qoymayacaq, çünki onun cədvəli NAT hələlik boş. Bununla belə, cədvəldəki ilk node marşrutlaşdırıcısında NAT Mənə səsyazma lazımdır. Ə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 masa NAT ikinci marşrutlaşdırıcıya məlumat lazımdır.

Problem ondadır ki, xaricinizi tanımaq üçün IPünvanında yerləşən 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ə cədvəldəki qiymətli qeydlər də yaradılır NAT.

STUN və TURN serverləri

Başlanğıcda WebRTC mövcud olduğunu göstərməlisiniz SUN Və TURN daha sonra zəng edəcəyimiz serverlər ICE serverlər. Əgər serverlər göstərilməyibsə, o zaman yalnız eyni şəbəkədəki qovşaqlar (ona qoşulmadan NAT). Bunun üçün dərhal qeyd etmək lazımdır 3g-şəbəkələrdən istifadə edilməlidir TURN serverlər.

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ında yerləşən node daxil olur SUN keçmək üçün server NAT. Paket çatdı SUN server, 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 ünvan SUN serverə göndərir və onu geri göndərir. Beləliklə, düyün xaricini alır IP onun şəbəkədən daxil olduğu ünvan və port. Daha, WebRTC bu ünvandan istifadə etməklə əlavə namizəd (xarici marşrutlaşdırıcı ünvanı və port) yaradır. İndi cədvəldə NAT Routerdə tələb olunan portda marşrutlaşdırıcıya göndərilən paketlərin qovşağımıza keçməsinə imkan verən bir giriş var.

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

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

SUN serveri ilə işarə edəcəyik s1. Router, əvvəlki kimi, vasitəsilə r1, və node – vasitəsilə p1. Siz də cədvələ əməl etməlisiniz NAT– kimi işarə edək r1_nat. Ü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 boş bir masamız var r1_nat.

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

Düyün p1 bu paketi marşrutlaşdırıcıya göndərir r1(necə olursa olsun, onlar müxtəlif alt şəbəkələrdə istifadə edilə bilər müxtəlif texnologiyalar). Router mənbə ünvanını dəyişməlidir Src IP, çü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ş sizin masanızda r1_nat. Bunun üçün o, port nömrəsi ilə çıxış etməlidir. Yada salaq ki, alt şəbəkə daxilində bir neçə qovşaq xarici şəbəkəyə daxil ola bildiyi üçün cədvəldə NAT saxlanmalı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ə bir port tapmağa icazə verin 888 .

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

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

Burada IP alt şəbəkə üçün ünvan və port orijinal paketlə tam olaraq eynidir. Əslində, postbacking zamanı onları tamamilə bərpa etmək üçün bir yolumuz olmalıdır. IP xarici şəbəkə üçün ü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.

Node olan real port p1əlaqəni qəbul edir - bu, əlbəttə ki, 35777 , lakin server məlumat göndərir uydurma liman 888 , marşrutlaşdırıcı tərəfindən həqiqi birinə dəyişdiriləcək 35777 .

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

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

Ümumi SUN server ünvandan bir paket aldığını bilir 10.50.200.5:888 . İ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, heç də ondan deyil məzmun. Biz məzmunu haqqında danışmadıq, çünki o qədər də vacib deyil - bu, bir şəkildə protokolda təsvir edilmişdir SUN. İndi başlığa əlavə olaraq məzmunu da nəzərdən keçirəcəyik. Bu sadə olacaq və marşrutlaşdırıcının ünvanını ehtiva edir - 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ə tutulan 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 marşrutlaşdırıcının xarici interfeysinə çatana qədər şəbəkə boyunca hərəkət edir r1. 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. Liman 888 şəxsi məqsədləri üçün istifadə etmir, mexanizm üçün istifadə edir NAT. Buna görə də, marşrutlaşdırıcı bu cədvələ baxır. Sütununa baxır Xarici PORT və uyğun gələn sətir axtarır Hədəf PORT gələn paketdən, 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, əgər ilk node üçün marşrutlaşdırıcı bir port ilə gəldi 888 , sonra ikinci o, bir liman ilə gələcək 889 . Tutaq ki, bu baş verib, yəni masa r1_nat 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 qovşağına uğurla çatır p1 və paketin məzmununa baxaraq, qovşaq onun xarici haqqında öyrənir IPünvanı, yəni marşrutlaşdırıcının xarici şəbəkədəki ünvanı. O, marşrutlaşdırıcının keçdiyi portu da bilir NAT.

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

Yuxarıdakı nümunədən onun necə işlədiyi barədə bir fikir əldə edə bilərsiniz NAT və mahiyyət SUN server. Ümumiyyətlə, mexanizm ICE Və SUN/DÖNÜŞ serverlər dəqiq olaraq məhdudiyyətləri aradan qaldırmağa yönəlib NAT.

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ə, biz qoşulmuş marşrutlaşdırıcının ünvanını alırıq SUN server. üçün p2p kommunikasiya tam olaraq ehtiyac duyduğumuz şeydir, əgər hər bir marşrutlaşdırıcının cədvələ lazım olan sıranı əlavə edəcəyini unutmasaq NAT. Buna görə də, geri dönüş yolu yenə hamar olacaq.

TURN server təkmilləşdirilmişdir SUN server. Buradan dərhal öyrənmək lazımdır ki, hər hansı bir TURN server işləyə bilər və necə SUN server. Bununla belə, üstünlükləri də var. Əgər p2pünsiyyət mümkün deyil (məsələn, 3gşəbəkələr), sonra server təkrarlayıcı rejiminə keçir ( rele), yəni vasitəçi kimi fəaliyyət göstərir. Əlbəttə ki, heç bir şey haqqında p2p onda sual yoxdur, amma mexanizm çərçivəsindən kənarda ICE qovşaqlar birbaşa əlaqə saxladıqlarını düşünürlər.

Hansı hallarda lazımdır TURN server? Niyə çatmır SUN serverlər? Fakt budur ki, bir neçə növ var NAT. Onlar bərabər şəkildə əvəz edirlər IPünvan və port, lakin onların bəzilərində "saxtalaşdırmaya" qarşı əlavə qorunma var. Məsələn, in simmetrik masa NAT Daha 2 parametr saxlanılır - IP və uzaq qovşağın portu. Xarici şəbəkədən bir paket keçir NAT daxili şəbəkəyə yalnız mənbə ünvanı və port cədvəldə qeyd olunanlara uyğun gələrsə. Buna görə də diqqət SUN server uğursuz oldu - cədvəl NATünvanı və portu saxlayır SUN server və marşrutlaşdırıcı paketi qəbul etdikdə WebRTC həmsöhbət, o, "saxtalaşdırıldığı" üçün onu rədd edir. O, gəlmədi SUN server.

Beləliklə TURN hər iki həmsöhbət yerləşdikdə server lazımdır simmetrik NAT(hər biri özünə görə).

Qısa xülasə

Burada qurumlar haqqında bəzi ifadələr var WebRTC hər zaman yadda saxlamaq lazımdı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 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 kameraya 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 yönləndirilməsi vəzifəsi ( sdp) ərizəyə düşür
  • Məntiqi əlaqə mexanizmi iki mərhələdən ibarətdir - cümlələr ( təklif) və cavab ( cavab)
  • Təklif olduqda yerli media axınından istifadə etmədən sessiya deskriptorunun yaradılması mümkün deyil ( təklif) və cavab halında uzaqdan seans dəstəyi istifadə etmədən mümkün deyil ( cavab)
  • Nəticə təsviri icraya verilməlidir WebRTC, və bu deskriptorun eyni icradan uzaqdan və ya lokal olaraq əldə edilməsinin fərqi yoxdur WebRTC
  • 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 ünvanı ola bilər və ya TURN serverlər
  • Namizədlər həmişə çox olur
  • Namizəddən ibarətdir IPünvanı, limanı və nəqliyyat növü ( TCP və ya UDP)
  • 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ərin də tətbiqlərə köçürülməsi lazımdır WebRTC, lakin yalnız uzaqdan
  • Bəzi tətbiqlərdə WebRTC 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ışın təmin edilməsi mexanizmi
  • Ev marşrutlaşdırıcıları xüsusi bir masa dəstəkləyir NAT
  • 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ə çox kanallı çıxışı təmin etmək NAT portlardan istifadə edir
  • ICE- bypass mexanizmi NAT
  • SUN Və TURN serverlər – yan keçmək üçün köməkçi serverlər NAT
  • SUN server cədvəldə lazımi qeydləri yaratmağa imkan verir NAT, və həmçinin qovşağın xarici ünvanını qaytarır
  • TURN server ümumiləşdirir SUN mexanizmdir və onu daim işlək vəziyyətə gətirir
  • Ən pis hallarda TURN server vasitəçi kimi istifadə olunur ( rele), yəni p2p müştəri-server-müştəri əlaqəsinə çevrilir.

WebRTC (Web Real Time Communications), plaginlər və ya digər uzantılar quraşdırmadan axın audio məlumatların, video məlumatların və məzmunun real vaxt rejimində brauzerdən və brauzerə ötürülməsini təsvir edən standartdır. Standart brauzerinizi videokonfrans terminalına çevirməyə imkan verir, ünsiyyətə başlamaq üçün sadəcə veb səhifəni açmaq lazımdır.

WebRTC nədir?

Bu yazıda WebRTC texnologiyası haqqında bilməli olduğunuz hər şeyi nəzərdən keçirəcəyik daimi istifadəçi. Layihənin üstünlükləri və mənfi cəhətlərinə baxaq, bəzi sirləri açaq, onun necə işlədiyini, WebRTC-nin harada və nə üçün istifadə edildiyini söyləyək.

WebRTC haqqında nə bilmək lazımdır?

Video kommunikasiya standartları və texnologiyalarının təkamülü

Sergey Yutsaitis, Cisco, Video+Konfrans 2016

WebRTC necə işləyir

Müştəri tərəfi

• İstifadəçi HTML5 teqi olan səhifəni açır
• Brauzer istifadəçinin veb-kamerasına və mikrofonuna giriş tələb edir.
• İstifadəçi səhifəsindəki JavaScript kodu NAT və Firewall-dan yan keçmək üçün əlaqə parametrlərinə (WebRTC serverinin və ya digər WebRTC müştərilərinin IP ünvanları və portları) nəzarət edir.
• Serverdə qarışıq olan konfransdan həmsöhbət və ya axın haqqında məlumat alarkən, brauzer istifadə olunan audio və video kodekləri müzakirə etməyə başlayır.
• Kodlaşdırma prosesi başlayır və axın məlumatlarının WebRTC müştəriləri arasında ötürülməsi (bizim halda, brauzer və server arasında).

WebRTC server tərəfində

İki iştirakçı arasında məlumat mübadiləsi üçün video server tələb olunmur, lakin bir konfransda bir neçə iştirakçını birləşdirmək lazımdırsa, server tələb olunur.

Video server müxtəlif mənbələrdən media trafikini qəbul edəcək, onu çevirəcək və WebRTC-dən terminal kimi istifadə edən istifadəçilərə göndərəcək.

Həmçinin, WebRTC serveri WebRTC həmyaşıdlarından media trafikini qəbul edəcək və onu proqramlardan istifadə edən konfrans iştirakçılarına ötürəcək. stolüstü kompüterlər və ya mobil cihazlar, əgər varsa.

Standartın üstünlükləri

• Proqram təminatının quraşdırılması tələb olunmur.
• Çox yüksək rabitə keyfiyyəti sayəsində:
  • Müasir video (VP8, H.264) və audio kodeklərdən (Opus) istifadə.
  • Axın keyfiyyətinin qoşulma şərtlərinə avtomatik tənzimlənməsi.
  • Quraşdırılmış əks-səda və səs-küyün azaldılması sistemi.
  • İştirakçı mikrofonlarının (AGC) həssaslıq səviyyəsinin avtomatik tənzimlənməsi.
• Yüksək səviyyəli təhlükəsizlik: bütün əlaqələr TLS və SRTP protokollarından istifadə etməklə qorunur və şifrələnir.
• Məzmunu ələ keçirmək üçün daxili mexanizm var, məsələn, iş masası.
• HTML5 və JavaScript əsasında istənilən idarəetmə interfeysini həyata keçirmək imkanı.
• WebSockets-dən istifadə edərək interfeysi istənilən arxa sistemlərlə inteqrasiya etmək imkanı.
• Açıq layihə mənbə kodu— məhsul və ya xidmətinizə tətbiq oluna bilər.
• Həqiqi çarpaz platforma: eyni WebRTC tətbiqi istənilən proqramda eyni dərəcədə yaxşı işləyəcək əməliyyat sistemi brauzerin WebRTC-ni dəstəkləməsi şərti ilə, masaüstü və ya mobil. Bu, proqram təminatının hazırlanmasında resurslara əhəmiyyətli dərəcədə qənaət edir.

Standartın çatışmazlıqları

• Qrup audio və video konfranslarını təşkil etmək üçün iştirakçıların video və səsini qarışdıracaq video konfrans serveri tələb olunur, çünki Brauzer çoxlu daxil olan axını bir-biri ilə necə sinxronlaşdıracağını bilmir.
• Bütün WebRTC həlləri bir-biri ilə uyğun gəlmir, çünki... standart yalnız video və audio ötürmə üsullarını təsvir edir, abunəçilərə müraciət etmək, onların mövcudluğunu izləmək, mesajlar və fayllar mübadiləsi, iş qrafiki və digər şeylərin icrasını satıcıya buraxır.
• Başqa sözlə, bir tərtibatçının WebRTC tətbiqindən başqa bir tərtibatçının WebRTC tətbiqinə zəng edə bilməyəcəksiniz.
• Qrup konfranslarını qarışdırmaq böyük hesablama resursları tələb edir, ona görə də bu növ video rabitə pullu abunə satın almağı və ya infrastrukturunuza investisiya etməyi tələb edir, burada hər konfrans müasir prosessorun 1 fiziki nüvəsini tələb edir.

WebRTC sirləri: Satıcılar sıçrayış veb texnologiyasından necə faydalanırlar

Tzachi Levent-Levi, Bloggeek.me, Video+Konfrans 2015

Video konfrans bazarı üçün WebRTC

Videokonfrans terminallarının sayının artırılması

WebRTC texnologiyası videokonfrans bazarının inkişafına güclü təsir göstərmişdir. 2013-cü ildə WebRTC dəstəyi ilə ilk brauzerlərin buraxılmasından sonra bütün dünyada videokonfrans terminallarının potensial sayı dərhal 1 milyard cihaz artdı. Əslində, hər bir brauzer videokonfrans terminalına çevrilib, rabitə keyfiyyətinə görə aparat analoqlarından geri qalmır.

Xüsusi həllərdə istifadə edin

WebRTC dəstəyi ilə müxtəlif JavaScript kitabxanaları və bulud xidməti API-lərindən istifadə istənilən veb layihəyə video rabitə dəstəyi əlavə etməyi asanlaşdırır. Əvvəllər məlumatları real vaxt rejimində ötürmək üçün tərtibatçılar protokolun işləmə prinsiplərini öyrənməli və digər şirkətlərin işlərindən istifadə etməli idilər ki, bu da əksər hallarda əlavə lisenziyalaşdırma tələb edirdi ki, bu da xərcləri artırırdı. WebRTC artıq “Saytdan zəng”, “Onlayn söhbət dəstəyi” və s. kimi xidmətlərdə fəal şəkildə istifadə olunur.

Linux üçün Skype-ın keçmiş istifadəçiləri

2014-cü ildə Microsoft İT mütəxəssisləri arasında böyük qıcıq yaradan Skype for Linux layihəsinə dəstəyin dayandırıldığını elan etdi. WebRTC texnologiyası əməliyyat sisteminə bağlı deyil, brauzer səviyyəsində həyata keçirilir, yəni. Linux istifadəçiləri Skype-ın tam hüquqlu əvəzedicisi kimi WebRTC əsasında məhsul və xidmətləri görə biləcək.

Flash ilə rəqabət

WebRTC və HTML5, artıq ən pis illərini yaşayan Flash texnologiyasına ölümcül zərbə oldu. 2017-ci ildən bəri aparıcı brauzerlər Flash-ı dəstəkləməyi rəsmən dayandırdılar və texnologiya bazardan tamamilə yox oldu. Ancaq biz Flash-a haqqını verməliyik, çünki veb konfrans bazarını yaradan və təklif edən o idi texniki imkanlar brauzerlərdə canlı ünsiyyət üçün.

WebRTC video təqdimatları

Dmitri Odintsov, TrueConf, Video+Konfrans oktyabr 2017

WebRTC-də kodeklər

Audio kodeklər

WebRTC audio trafiki sıxışdırmaq üçün Opus və G.711 kodeklərindən istifadə edir.

G.711- ənənəvi telefoniya sistemlərində ən çox istifadə olunan yüksək bit sürəti (64 kbps) olan ən qədim səs kodek. Əsas üstünlük yüngül sıxılma alqoritmlərinin istifadəsi səbəbindən minimal hesablama yüküdür. Kodek səs siqnallarının aşağı sıxılma səviyyəsinə malikdir və istifadəçilər arasında ünsiyyət zamanı əlavə səs gecikməsi təqdim etmir.

G.711 çox sayda cihaz tərəfindən dəstəklənir. Bu kodekdən istifadə edən sistemlərdən istifadə etmək digər audio kodeklərə (G.723, G.726, G.728 və s.) əsaslanan sistemlərdən daha asandır. Keyfiyyət baxımından G.711 MOS testində 4,2 bal aldı (4-5 arasındakı xal ən yüksəkdir və deməkdir yaxşı keyfiyyət, ISDN-də səs trafikinin ötürülməsi keyfiyyətinə oxşar və daha yüksək).

Opus aşağı kodlaşdırma gecikməsinə (2,5 ms-dən 60 ms-ə qədər), dəyişən bit sürətlərinə və yüksək sıxılma səviyyələrinə dəstək olan, dəyişənli şəbəkələrdə axın səs siqnallarını ötürmək üçün ideal olan kodekdir. ötürmə qabiliyyəti. Opus, SILK (səsin sıxılması, insan nitqinin təhrifinin aradan qaldırılması) və CELT (audio məlumatların kodlaşdırılması) kodeklərinin ən yaxşı xüsusiyyətlərini birləşdirən hibrid həlldir. Kodek sərbəst mövcuddur; ondan istifadə edən tərtibatçılar müəllif hüquqları sahiblərinə qonorar ödəməli deyillər. Digər audio kodeklərlə müqayisədə Opus, şübhəsiz ki, bir çox cəhətdən qalib gəlir. O, MP3, Vorbis, AAC LC kimi olduqca populyar aşağı bit sürəti kodeklərini geridə qoyub. Opus AMR-WB və Speex-dən daha orijinal səs "şəkilini" bərpa edir. Bu kodek gələcəkdir, buna görə də WebRTC texnologiyasının yaradıcıları onu dəstəklənən audio standartlarının məcburi sırasına daxil ediblər.

Video kodeklər

WebRTC üçün video kodek seçmək məsələləri tərtibatçıları bir neçə il çəkdi və sonda H.264 və VP8-dən istifadə etmək qərarına gəldilər. Demək olar ki, bütün müasir brauzerlər hər iki kodekləri dəstəkləyir. WebRTC ilə işləmək üçün video konfrans serverləri yalnız birini dəstəkləməlidir.

VP8- yüksək video axını dekodlaşdırma sürəti və çərçivə itkisinə artan müqavimət ilə xarakterizə olunan açıq lisenziyalı pulsuz video kodek. Kodek universaldır və hardware platformalarına tətbiq etmək asandır, buna görə də video konfrans sistemlərinin tərtibatçıları ondan tez-tez öz məhsullarında istifadə edirlər.

Ödənişli video kodek H.264 qardaşından xeyli əvvəl məşhurlaşdı. Bu, qənaət edərkən video axınının yüksək sıxılma dərəcəsinə malik bir kodekdir Yüksək keyfiyyət video. Bu kodekin aparat video konfrans sistemləri arasında yüksək yayılması onun WebRTC standartında istifadəsini təklif edir.

Google və Mozilla VP8 kodekini, Microsoft, Apple və Cisco isə H.264-ü fəal şəkildə təşviq edirlər (ənənəvi video konfrans sistemləri ilə uyğunluğu təmin etmək üçün). Və burada WebRTC bulud həllərini tərtib edənlər üçün çox böyük problem yaranır, çünki konfransın bütün iştirakçıları eyni brauzerdən istifadə edirlərsə, konfransı bir dəfə bir kodek ilə qarışdırmaq kifayətdir və brauzerlər fərqlidirsə və Safari / Edge Onların arasında, daha sonra konfrans iki dəfə fərqli kodekləri kodlaşdırmaq məcburiyyətində qalacaq ki, bu da ikiqat olacaq sistem tələbləri media serverinə və nəticədə WebRTC xidmətlərinə abunəliklərin dəyəri.

WebRTC API

WebRTC texnologiyası üç əsas API-yə əsaslanır:

• (kameralardan və ya istifadəçinin iş masasından audio və video siqnalları qəbul edən veb-brauzerdən məsuldur).
• RTCPeerConnection(kameradan, mikrofondan və iş masasından alınan media məlumatlarının "mübadiləsi" üçün brauzerlər arasında əlaqəyə cavabdehdir. Həmçinin, bu API-nin "məsuliyyətlərinə" siqnalın işlənməsi (onun kənar səs-küydən təmizlənməsi, mikrofonun səs səviyyəsinin tənzimlənməsi) və nəzarət daxildir. audio və video kodeklərdən istifadə olunur).
• RTCData Kanalı(müəyyən edilmiş əlaqə vasitəsilə ikitərəfli məlumat ötürülməsini təmin edir).

İstifadəçinin mikrofonuna və kamerasına daxil olmamışdan əvvəl brauzer bunun üçün icazə tələb edir. IN Google Chrome Girişi əvvəlcədən "Parametrlər" bölməsində konfiqurasiya edə bilərsiniz, Opera və Firefox-da cihazlar birbaşa açılan siyahıdan giriş əldə edərkən seçilir. İcazə sorğusu həmişə HTTP protokolundan istifadə edərkən və HTTPS istifadə edildikdə bir dəfə görünəcək:

RTCPeerConnection. WebRTC konfransında iştirak edən hər bir brauzerin girişi olmalıdır bu obyekt. RTCPeerConnection-ın istifadəsi sayəsində bir brauzerdən digərinə media məlumatları hətta NAT və təhlükəsizlik divarları. Media axınlarını uğurla ötürmək üçün iştirakçılar veb rozetkalar kimi nəqliyyat vasitəsi ilə aşağıdakı məlumatları mübadilə etməlidirlər:

• təşəbbüskar iştirakçı ikinci iştirakçıya Təklif-SDP (ötürəcəyi media axınının xüsusiyyətləri ilə məlumat strukturu) göndərir;
• ikinci iştirakçı "cavab" yaradır - Cavab-SDP və onu təşəbbüskara göndərir;
• sonra iştirakçılar arasında ICE namizədlərinin mübadiləsi təşkil edilir, əgər hər hansı aşkar edilərsə (iştirakçılar NAT və ya firewall arxasındadırsa).

Bu mübadilə uğurla başa çatdıqdan sonra iştirakçılar arasında media axınlarının (audio və video) birbaşa ötürülməsi təşkil edilir.

RTCData Kanalı. Məlumat Kanalı protokolu üçün dəstək brauzerlərdə nisbətən yaxınlarda ortaya çıxdı, buna görə də bu API yalnız brauzerlərdə WebRTC istifadə edildiyi hallarda nəzərdən keçirilə bilər. Mozilla Firefox 22+ və Google Chrome 26+. Onun köməyi ilə iştirakçılar mübadilə edə bilərlər mətn mesajları brauzerdə.

WebRTC vasitəsilə əlaqə

Dəstəklənən masaüstü brauzerlər

• Google Chrome (17+) və Chromium mühərrikinə əsaslanan bütün brauzerlər;
• Mozilla FireFox (18+);
• Opera (12+);
• Safari (11+);

Android üçün dəstəklənən mobil brauzerlər

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

WebRTC, Microsoft və Internet Explorer

Çox uzun müddətdir ki, Microsoft Internet Explorer və onun yeni Edge brauzerində WebRTC dəstəyi haqqında səssiz qaldı. Redmonddan olan uşaqlar, idarə etmədikləri texnologiyaları istifadəçilərin əlinə verməyi həqiqətən sevmirlər, siyasət belədir. Amma tədricən məsələ ölü nöqtədən getdi, çünki... Artıq WebRTC-yə məhəl qoymamaq mümkün deyildi və WebRTC standartının törəməsi olan ORTC layihəsi elan edildi.

Tərtibatçıların fikrincə, ORTC JavaScript və HTML5-ə əsaslanan təkmilləşdirilmiş API dəsti ilə WebRTC standartının uzantısıdır ki, bu da adi dilə tərcümədə hər şeyin eyni olacağını, standarta Google deyil, yalnız Microsoft tərəfindən nəzarət edəcəyini bildirir. və onun inkişafı. Kodeklər dəsti H.264 və telefoniya və aparat videokonfrans sistemlərində istifadə edilən G.7ХХ seriyasının bəzi audio kodeklərinin dəstəyi ilə genişləndirilmişdir. RDP (məzmun ötürülməsi üçün) və mesajlaşma üçün daxili dəstək ola bilər. Yeri gəlmişkən, Internet Explorer istifadəçilərinin bəxti gətirmir, ORTC dəstəyi yalnız Edge-də olacaq. Və əlbəttə ki, bu protokollar və kodeklər dəsti WebRTC üçün daha çox biznes proqramları açan Skype for Business ilə asanlıqla interfeys yaradır.

Bu məqalənin məqsədi onun strukturu və iş prinsipi ilə tanış olmaq üçün peer-to-peer video chat (p2p video chat) demo nümunəsindən istifadə etməkdir. Bu məqsədlə biz çox istifadəçili peer-to-peer video çat demo webrtc.io-demo istifadə edəcəyik. Onu linkdən yükləmək olar: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Qeyd edək ki, GitHub Veb layihələrin birgə inkişafı üçün sayt və ya veb servisdir. Bunun üzərində tərtibatçılar öz inkişaflarının kodlarını yerləşdirə, müzakirə edə və bir-biri ilə əlaqə saxlaya bilərlər. Bundan əlavə, bəzi böyük İT şirkətləri öz rəsmi repozitoriyalarını bu saytda yerləşdirirlər. Xidmət açıq mənbəli layihələr üçün pulsuzdur. GitHub açıq, pulsuz mənbə kodu kitabxanaları üçün depodur.

Beləliklə, biz GitHub-dan yüklənmiş peer-to-peer video söhbətinin demo nümunəsini C diskinə yerləşdirəcəyik. Şəxsi kompüter"webrtc_demo" tətbiqimiz üçün yaradılmış kataloqda.

düyü. 1

Strukturdan (Şəkil 1) göründüyü kimi, peer-to-peer video çatı JavaScript proqramlaşdırma dilində həyata keçirilən müştəri script.js və server server.js skriptlərindən ibarətdir. Skript (kitabxana) webrtc.io.js (CLIENT) - peer-to-peer sxemindən istifadə edərək brauzerlər arasında real vaxt rabitəsinin təşkilini təmin edir: "müştəri-müştəri", və webrtc.io.js (CLIENT) və webrtc. io.js (SERVER), WebSocket protokolundan istifadə edərək, müştəri-server arxitekturasından istifadə edərək brauzer və veb server arasında dupleks əlaqəni təmin edirlər.

webrtc.io.js (SERVER) skripti webrtc.io kitabxanasına daxildir və node_modules\webrtc.io\lib kataloqunda yerləşir. index.html video çat interfeysi HTML5 və CSS3-də həyata keçirilir. webrtc_demo proqram fayllarının məzmununa html redaktorlarından biri ilə baxmaq olar, məsələn, "Notepad++".

Video söhbətin iş prinsipini yoxlayacağıq fayl sistemi PC. Serveri (server.js) kompüterdə işə salmaq üçün siz node.js iş vaxtı mühitini quraşdırmalısınız. Node.js JavaScript kodunu brauzerdən kənarda işə salmağa imkan verir. Siz node.js-ni linkdən yükləyə bilərsiniz: http://nodejs.org/ (versiya v0.10.13 07/15/13). node.org veb-saytının əsas səhifəsində yükləmə düyməsini klikləyin və http://nodejs.org/download/ ünvanına keçin. Windows istifadəçiləri üçün əvvəlcə win.installer (.msi) proqramını yükləyin, sonra kompüterdə win.installer (.msi) proqramını işə salın və Proqram Faylları kataloqunda nodejs və "npm paket meneceri" quraşdırın.

düyü. 2

Beləliklə, node.js JavaScript kodunu hazırlamaq və işə salmaq üçün mühitdən, həmçinin menecer və ya npm paket menecerindən istifadə etməklə quraşdırıla bilən daxili modullar toplusundan ibarətdir.

Modulları quraşdırmaq üçün lazımdır komanda xətti Tətbiq kataloqundan (məsələn, "webrtc_demo") əmri işlədin: npm quraşdırma modulu_adı. Modulların quraşdırılması zamanı npm meneceri quraşdırmanın aparıldığı qovluqda node_modules qovluğunu yaradır. Əməliyyat zamanı nodejs avtomatik olaraq node_modules kataloqundan modulları birləşdirir.

Beləliklə, node.js-i quraşdırdıqdan sonra komanda xəttini açın və npm paket menecerindən istifadə edərək webrtc_demo kataloqunun node_modules qovluğunda ekspress modulu yeniləyin:

C:\webrtc_demo>npm install express

Ekspress modul node.js üçün veb çərçivə və ya proqramların inkişafı üçün veb platformadır. Ekspresə qlobal giriş əldə etmək üçün onu belə quraşdıra bilərsiniz: npm install -g express.

Sonra webrtc.io modulunu yeniləyin:

C:\webrtc_demo>npm webrtc.io-nu quraşdırın

Sonra komanda xəttində serveri işə salırıq: server.js:

C:\webrtc_demo>node server.js

düyü. 3

Budur, server uğurla işləyir (Şəkil 3). İndi veb-brauzerdən istifadə edərək, IP ünvanı ilə serverlə əlaqə saxlaya və index.html veb səhifəsini yükləyə bilərsiniz, veb-brauzer ondan müştəri skript kodunu - script.js və webrtc.io.js skript kodunu çıxaracaq və onları icra edin. Peer-to-peer video çatını idarə etmək üçün (iki brauzer arasında əlaqə yaratmaq üçün) webrtc-ni dəstəkləyən iki brauzerdən node.js üzərində işləyən siqnal serveri ilə əlaqə saxlamalısınız.

Nəticədə rabitə proqramının müştəri hissəsinin interfeysi (videoçat) kamera və mikrofona daxil olmaq üçün icazə sorğusu ilə açılacaq (şək. 4).

düyü. 4

"İcazə ver" düyməsini basdıqdan sonra kamera və mikrofon multimedia rabitəsi üçün birləşdirilir. Bundan əlavə, video chat interfeysi vasitəsilə mətn məlumatları vasitəsilə əlaqə saxlaya bilərsiniz (şək. 5).

düyü. 5

Qeyd etmək lazımdır ki. Server siqnal serveridir və əsasən istifadəçi brauzerləri arasında əlaqə yaratmaq üçün nəzərdə tutulub. Node.js WebRTC siqnalını təmin edən server.js server skriptini idarə etmək üçün istifadə olunur.