WebRTC. Браузердегі бейнеконференция. WebRTC Webrtc дауыстық чатын пайдаланатын көп пайдаланушы чаты

Кіріспе. P2P бейне чатынегізде WebRTC Skype және басқа байланыс құралдарына балама болып табылады. p2p бейне чатының негізгі элементтері WebRTC негізіндеболып табылады браузержәне байланыс сервері. P2P бейне чаттары – сервер ақпарат ағындарын жіберуге қатыспайтын тең дәрежелі бейне чаттар. Ақпарат пайдаланушылардың браузерлері (пингтер) арасында ешқандай қосымша бағдарламаларсыз тікелей тасымалданады. Браузерлерден басқа, p2p бейне чаттары пайдаланушыларды тіркеуге, олар туралы деректерді сақтауға және пайдаланушылар арасында ауысуды қамтамасыз етуге арналған байланыс серверлерін пайдаланады. Соңғы WebRTC және HTML5 технологияларын қолдайтын шолғыштар лезде мәтіндік хабарлар мен файлдарды қамтамасыз етеді, сонымен қатар IP желілері арқылы дауыстық және бейне байланысын қамтамасыз етеді.

Сонымен, чаттар, веб чаттар, веб-интерфейстегі дауыстық және бейне чаттар, IMS, VoIP - пакеттік коммутацияланған композиттік желілер арқылы онлайн байланыстарды қамтамасыз ететін қызметтер. Әдетте, байланыс қызметтері пайдаланушы құрылғыларында (ДК, смартфондар және т.б.) клиенттік қосымшаларды орнатуды немесе браузерлерде плагиндер мен кеңейтімдерді орнатуды талап етеді. Қызметтердің өз коммуникациялық желілері бар, олардың көпшілігі «клиент-сервер» архитектурасына салынған.

Байланыс қызметтері IMS-ті қоспағанда, дауыс, бейне, деректер және мәтіндік арналар біріктірілмеген қолданбалар болып табылады. Әрбір қызметтің желілерінде, . Айта кету керек, бұл қолданбалар бір уақытта бірнеше байланыс желілерінде жұмыс істей алмайды, яғни. қолданбалар, әдетте, бір-бірімен өзара әрекеттесе алмайды, нәтижесінде әрбір байланыс желісі үшін жеке қосымшаны орнату қажет.

Нақты уақыттағы байланыс қызметтерін біріктіру мәселесі (чат, телефония, бейнеконференция), т.б. дауыс, бейне, деректерді беру арналарын біріктіру және оларға бір қосымшаны (браузерді) пайдалану арқылы қол жеткізу тең дәрежелі немесе тең дәрежеде шешілуі мүмкін. p2p бейне чаттары(тең-теңімен, нүктеден - нүктеге) негізделген WebRTC протоколы. Шын мәнінде, WebRTC қолдайтын шолғыш барлық пайдаланушы құрылғылары үшін (ДК, смартфондар, iPad, IP телефондары, Ұялы телефондарт.б.) байланыс қызметтерімен жұмыс істейтін.

Бұл нақты уақыттағы байланыстарды қамтамасыз ететін барлық технологияларды браузерде енгізуді қамтамасыз ететін WebRTC. p2p бейне чаттарының мәні - мультимедиялық және мәтіндік деректер сервер мен қосымша бағдарламалардың қатысуынсыз пайдаланушылардың браузерлері (қашықтағы пирингтер) арасында тікелей тасымалданады. Осылайша, браузерлер барлығына дерлік қол жеткізуді қамтамасыз етіп қана қоймайды ақпараттық ресурстарИнтернет серверлерде сақталады, бірақ сонымен бірге нақты уақыттағы барлық байланыс қызметтеріне және пошта қызметтеріне қол жеткізу құралына айналады (дауыс поштасы, электрондық пошта, SMS және т.б.)

p2p бейне чаттарының серверлері (байланыс серверлері) тек пайдаланушыларды тіркеуге, пайдаланушылар туралы деректерді сақтауға және пайдаланушылардың браузерлері арасында байланыс орнатуға (ауысуға) арналған. Алғашқы p2p бейне чаттар флеш технологиялары арқылы жүзеге асырылды. Flash p2p бейне чаттары, мысалы, пайдаланылады әлеуметтік желілерде. Flash p2p бейне чаттары қамтамасыз етілмейді жоғары сапамультимедиялық деректерді беру. Сонымен қатар, p2p флэш бейне чаттарындағы микрофон мен бейне камерадан дауыс және бейне ағынын шығару үшін сізге орнату қажет. флэш плагинівеб-шолғышқа.

Бірақ келесі буынның телекоммуникациялық қызметтері кіреді веб-коммуникациялар, ол тек Интернет арқылы байланыс үшін пайдаланылады браузерлерЖәне байланыс серверлеріқолдау көрсету WebRTC протоколдарыжәне спецификация HTML5. Мұндай браузермен жабдықталған кез келген пайдаланушы құрылғысы (ДК, iPad, смартфондар және т.б.) жоғары сапалы дауыстық және бейне қоңырауларды қамтамасыз ете алады, сондай-ақ жедел мәтіндік хабарламалар мен файлдарды тасымалдай алады.

Сонымен, веб-коммуникацияның жаңа технологиясы (p2p чаттар, бейне чаттар) WebRTC протоколы болып табылады. WebRTC HTML5, CSS3 және JavaScript-пен бірге әртүрлі веб-қосымшаларды жасауға мүмкіндік береді. WebRT веб-коммуникацияларды (тең-теңімен желілер) нақты уақыт режимінде тең дәрежелі архитектураны пайдалана отырып ұйымдастыруға арналған. WebRTC негізіндегі P2P чаттары файлдарды тасымалдауды, сондай-ақ браузерде сыртқы қондырмалар мен плагиндерді пайдаланбай тек веб-браузерлерді пайдалана отырып, интернет арқылы пайдаланушылардың мәтіндік, дауыстық және бейне байланысын қамтамасыз етеді.

P2p чаттарында сервер тек екі шолғыш арасында p2p байланысын орнату үшін пайдаланылады. WebRTC протоколына негізделген p2p чатының клиенттік бөлігін жасау үшін HTML5, CSS3 және JavaScript пайдаланылады. Клиент қолданбасы WebRTC API арқылы браузерлермен байланысады.

WebRTC үш JavaScript API арқылы жүзеге асырылады:

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

Браузерлер мультимедиялық деректерді UDP үстінде жұмыс істейтін SRTP протоколы арқылы жібереді. NAT Интернет арқылы p2p қосылымдарын пайдаланатын NAT маршрутизаторларының артындағы браузерлер (клиенттер) үшін проблемалар туғызатындықтан, STUN NAT аудармашыларын айналып өту үшін пайдаланылады. STUN – UDP тасымалдау протоколының үстінде жұмыс істейтін клиент/сервер протоколы. P2p чаттарында, әдетте, жалпыға ортақ STUN сервері пайдаланылады, ал одан алынған ақпарат, егер олар NAT артында болса, екі браузер арасындағы UDP қосылымы үшін пайдаланылады.

WebRTC қолданбаларын енгізу мысалдары (p2p чаттары, дауыстық және бейне веб чаттар):
1. WebRTC негізіндегі Bistri P2P бейне чатын (бір басу арқылы бейне чат, p2p чат) Bistri сайтында ашуға болады. Bistri браузерде қосымша бағдарламалар мен плагиндерді орнатпай жұмыс істейді. Жұмыстың мәні келесідей: көрсетілген сілтемені пайдаланып p2p бейне чатын ашыңыз, ашылатын интерфейсте тіркелгеннен кейін серіктестерді шақырыңыз, содан кейін серіктес клиенттердің тізімінен желіде тұрған серіктесті таңдап, «бейне қоңырау» түймесін басыңыз. « түймесі.

Нәтижесінде MediaStream (getUserMedia) микрофон + веб-камераны түсіреді, ал сервер таңдалған серіктеспен сигналдық хабарламалармен алмасады. Сигнал беру хабарламаларымен алмасудан кейін PeerConnection API дауыс және бейне ағындарын тасымалдау үшін арналарды жасайды. Сонымен қатар, Bistri жедел мәтіндік хабарламалар мен файлдарды тасымалдауды жүзеге асырады. Суретте. 1-суретте Bistri p2p бейне чат интерфейсінің скриншоты көрсетілген.

Күріш. 1. P2P бейне чат Бистрі

2. Twelephone (p2p видео чат, p2p чат, SIP Twelephone) — HTML5 және WebRTC негізіндегі клиенттік қосымша, ол дауыстық және бейне қоңыраулар жасауға, сондай-ақ лезде мәтіндік хабарламаларды жіберуге мүмкіндік береді, т.б. Twelephone сынақ p2p чатын, бейне чатты және SIP Twelephone телефонын қамтиды. Айта кету керек, Twelephone SIP протоколын қолдайды және енді сіз Twitter тіркелгісін телефон нөмірі ретінде пайдаланып SIP телефондарынан дауыстық және бейне қоңыраулар шалуға және қабылдауға болады. Сонымен қатар, мәтіндік хабарлармикрофон арқылы дауыспен енгізуге болады, ал дауысты тану бағдарламасы мәтінді «Хабар жіберу» жолына енгізеді.

Twelephone — браузерге негізделген веб-телефония Google Chrome, 25 нұсқасынан бастап, қосымшасыз бағдарламалық қамтамасыз ету. Twelephone құрастырған Крис Матье. Twelephone бағдарламасының артқы жағы Node.js үстіне салынған. Сервер (байланыс сервері) тек екі браузер немесе WebRTC клиенттері арасында p2p байланысын орнату үшін пайдаланылады. Twelephone қолданбасының жеке авторизация құралдары жоқ, бірақ есептік жазбаға қосылуға бағытталған ( есептік жазба) Twitter-де.

Суретте. 2-суретте Twelephone p2p бейне чат интерфейсінің скриншоты көрсетілген.

Күріш. 2.P2P Twinphone

3. Топтық p2p бейне чаты Conversat.io соңғы WebRTC және HTML5 технологияларына негізделген. Conversat бейне сұхбаты SimpleWebRTC кітапханасына негізделген және бір бөлмеде 6 тең клиентке дейін байланысуға арналған (байланыс үшін «Сөйлесуге ат қою» жолында серіктес клиенттерге арналған жалпы бөлменің атын көрсетіңіз). P2P бейне чаты Conversat пайдаланушыларға байланыс серверінде тіркелмей байланыс қызметтерін ұсынады. Суретте. 3-суретте Conversat p2p бейне чат интерфейсінің скриншоты көрсетілген.

Күріш. 3. P2P топтық бейне чат Conversat.io

WebRTC негізіндегі P2P бейне чаттарына қатысу үшін пайдаланушыларда WebRTC протоколын және HTML5 спецификациясын қолдайтын браузер орнатылған болуы керек. Қазіргі уақытта Google Chrome браузерлері 25 нұсқасынан бастап және Mozilla FirefoxТүнде WebRTC протоколын және HTML5 спецификациясын қолдайды. WebRTC қолданбалары кескін және дыбысты жіберу сапасы жағынан Flash қолданбаларынан жоғары.

Материалдың көп бөлігі WebRTCкодты жазудың қолданбалы деңгейіне назар аударады және технологияны түсінуге ықпал етпейді. Тереңірек барып, байланыс қалай пайда болатынын, сеанс дескрипторы мен кандидаттары қандай екенін, не екенін білуге ​​тырысайық. ТАҢДАУЖәне БҰРУсервер.

WebRTC

Кіріспе

WebRTC — бейне деректерін жіберу үшін екі клиентті қосуға мүмкіндік беретін шолғышқа негізделген технология. Негізгі мүмкіндіктер браузердің ішкі қолдауы болып табылады (мысалы, үшінші тарап ендірілген технологиялары қажет емес Adobe Flash) және қосымша серверлерді қолданбай-ақ клиенттерді қосу мүмкіндігі - қосылу пиринг жүйесі(Әрі қарай, p2p).

Байланыс орнату p2p- өте қиын тапсырма, өйткені компьютерлер әрқашан ашық бола бермейді IPмекенжайлар, яғни Интернеттегі мекенжайлар. Аз мөлшерде болғандықтан IPv4мекенжайлар (және қауіпсіздік мақсатында) механизмі әзірленді NAT, бұл, мысалы, үйде пайдалану үшін жеке желілерді жасауға мүмкіндік береді. Көптеген үй маршрутизаторлары қазір қолдайды NATжәне осының арқасында барлық үй құрылғылары Интернетке қол жеткізе алады, дегенмен Интернет-провайдерлер әдетте оны қамтамасыз етеді IPмекенжайы. қоғамдық IPИнтернетте мекенжайлар бірегей, бірақ жеке мекенжайлар жоқ. Сондықтан қосылыңыз p2p- қиын.

Мұны жақсырақ түсіну үшін үш жағдайды қарастырыңыз: екі түйін де бір желіде (1-сурет), екі түйін де әртүрлі желілерде (біреуі жеке, екіншісі жалпыға ортақ) (2-сурет)және екі түйін де бірдей әртүрлі жеке желілерде IPмекенжайлар (3-сурет).

1-сурет: Бір желідегі екі түйін

2-сурет: Әр түрлі желілердегі түйіндер (біреуі жеке, біреуі жалпыға ортақ)

3-сурет: Әртүрлі жеке желілердегі түйіндер, бірақ сандық жағынан бірдей мекенжайлар

Жоғарыдағы суреттерде екі таңбалы белгілердің бірінші әрпі түйін түрін көрсетеді (p = құрдас, r = маршрутизатор). Бірінші суретте жағдай қолайлы: олардың желісіндегі түйіндер желі арқылы толығымен анықталған IPмекенжайлары бар, сондықтан бір-бірімен тікелей қосыла алады. Екінші суретте бізде түйін нөмірлері ұқсас екі түрлі желі бар. Мұнда маршрутизаторлар (маршрутизаторлар) пайда болады, олардың екеуі бар желілік интерфейс- желіңіздің ішінде және желіңізден тыс. Сондықтан олардың екеуі бар IPмекенжайлар. Тұрақты түйіндердің тек бір ғана интерфейсі бар, ол арқылы олар тек өз желісінде байланыса алады. Егер олар деректерді желіден тыс біреуге жіберсе, онда тек көмегімен NATмаршрутизатордың (маршрутизатордың) ішінде, сондықтан оның астындағы басқаларға көрінеді IPмаршрутизатордың мекенжайы олардың сыртқы IPмекенжайы. Осылайша, түйін p1Сонда бар интерьер IP = 192.168.0.200 Және сыртқы IP = 10.50.200.5 , соңғы мекенжай оның желісіндегі барлық басқа хосттарға да сыртқы болып табылады. Түйін үшін де жағдай ұқсас p2. Сондықтан олардың ішкі (өзінің) байланысы ғана мүмкін емес. IPмекенжайлар. Сіз сыртқы мекенжайларды, яғни маршрутизаторлардың мекенжайларын пайдалана аласыз, бірақ бір жеке желідегі барлық түйіндердің сыртқы мекенжайы бірдей болғандықтан, бұл өте қиын. Бұл мәселе механизм арқылы шешіледі NAT

Егер біз әлі де түйіндерді олардың ішкі мекенжайлары арқылы қосуды шешсек, не болады? Деректер желіден шықпайды. Эффектіні күшейту үшін сіз соңғы суретте көрсетілген жағдайды елестете аласыз - екі түйіннің де ішкі мекенжайлары бірдей. Егер олар оларды байланысу үшін пайдаланса, онда әрбір түйін өзімен байланысады.

WebRTCхаттаманы пайдалана отырып, осындай мәселелермен сәтті күреседі ICE, бірақ бұл қосымша серверлерді пайдалануды талап етеді ( ТАҢДАУ, БҰРУ). Мұның бәрі төменде.

WebRTC екі фазасы

Екі түйінді протокол арқылы қосу үшін WebRTC(немесе жай RTCегер екеуі қосылса iPhone‘a) байланыс орнату үшін кейбір алдын ала қадамдар жасалуы керек. Бұл бірінші кезең – байланыс орнату. Екінші кезең - бейне мәліметтерді беру.

Технологияға қарамастан, бірден айту керек WebRTCжұмысында көп қолданады әртүрлі жолдарбайланыс ( TCPЖәне UDP) және олардың арасында икемді ауысу бар, бұл технология қосылым деректерін беру протоколы жоқ. Таңқаларлық емес, өйткені екі түйінді қосыңыз p2pоңай емес. Сондықтан біраз болуы керек қосымшабайланысты емес деректерді беру әдісі WebRTC. Бұл розеткалық трансфер, протокол болуы мүмкін http, ол тіпті хаттама болуы мүмкін SMTPнемесе орыс поштасы. Бұл тасымалдау механизмі бастапқыдеректер деп аталады сигнал. Көп ақпаратты тасымалдаудың қажеті жоқ. Барлық деректер мәтін түрінде беріледі және екі түрге бөлінеді − SDPЖәне Мұз кандидаты. Бірінші түрі логикалық байланыс орнату үшін, ал екіншісі физикалық байланыс үшін қолданылады. Бұл туралы кейінірек, бірақ әзірше бұл туралы есте сақтау маңызды WebRTCбізге басқа түйінге жіберуді қажет ететін кейбір ақпаратты береді. Біз барлық қажетті ақпаратты жібергеннен кейін түйіндер қосыла алады және біздің көмегіміз енді қажет болмайды. Сондықтан сигнал беру механизмін біз іске асыруымыз керек бөлек, пайдаланылады қосылған кезде ғана, және бейне деректерін жіберу кезінде пайдаланылмайды.

Сонымен, бірінші кезеңді, қосылымды орнату кезеңін қарастырайық. Ол бірнеше элементтерден тұрады. Бұл кезеңді алдымен қосылымды бастайтын түйін үшін, содан кейін күту үшін қарастырыңыз.

• Бастамашы (қоңырау шалушы - қоңырау шалушы):
  1. Бейне деректерін жіберуді бастау ұсынысы (createOffer)
  2. Сіздің SDP SDP)
  3. Сіздің Мұз кандидаты Мұз кандидаты)
• Қоңырау күту ( қоңырау шалушы):
  1. Жергілікті (жеке) медиа ағынын алу және оны жіберуге орнату (getUserMediaStream)
  2. Бейне деректерін тасымалдауды бастау және жауап жасау (createAnswer) ұсынысын алыңыз.
  3. Сіздің SDPобъект және оны сигналдық механизм арқылы өткізу ( SDP)
  4. Сіздің Мұз кандидатыобъектілер және олардың сигналдық механизм арқылы берілуі ( Мұз кандидаты)
  5. Қашықтағы (шетелдік) медиа ағынын қабылдау және оны экранда көрсету (onAddStream)

Жалғыз айырмашылық екінші абзацта.

Қадамдардың көрінетін күрделілігіне қарамастан, олардың үшеуі бар: өз медиа ағынын жіберу (1-бет), қосылым параметрлерін орнату (2-4-беттер), басқа біреудің медиа ағынын қабылдау (5-бет). Ең қиыны - екінші қадам, өйткені ол екі бөліктен тұрады: орнату физикалықЖәне логикалықбайланыстар. Біріншісі көрсетеді жол, бір желі түйінінен екіншісіне өту үшін пакеттер сол бойынша жүруі керек. Екіншісі көрсетеді бейне/аудио параметрлері- қандай сапаны, қандай кодектерді қолдану керек.

Психикалық кезең ұсыныс жасаунемесе Жауап жасауберу сатыларына қосылуы керек SDPЖәне Мұз кандидатынысандар.

Негізгі нысандар

Медиа ағындары (MediaStream)

Негізгі нысан – медиа ағыны, яғни бейне және дыбыс деректерінің, сурет пен дыбыстың ағыны. Медиа ағынының екі түрі бар - жергілікті және қашықтағы. Жергілікті құрылғы деректерді енгізу құрылғыларынан (камера, микрофон), ал қашықтан басқару пульті желі арқылы алады. Осылайша, әрбір түйінде жергілікті және қашықтағы ағын бар. IN WebRTCағындарға арналған интерфейс бар медиа ағыныжәне ішкі интерфейсі де бар LocalMediaStreamарнайы жергілікті жіп үшін. IN JavaScriptсіз тек біріншісін кездестіре аласыз және егер сіз пайдалансаңыз lib jingle, онда екіншісін де кездестіруге болады.

IN WebRTCжіп ішінде өте шатастыратын иерархия бар. Әрбір ағын бірнеше медиа тректерден тұруы мүмкін ( медиа трек), ол өз кезегінде бірнеше медиа арналардан тұруы мүмкін ( MediaChannel). Сондай-ақ бірнеше медиа ағындары болуы мүмкін.

Барлығын ретімен қарастырайық. Ол үшін кейбір мысалды еске түсірейік. Біз өзіміздің бейнемізді ғана емес, бірдеңе жазатын қағаз жатқан үстеліміздің видеосын да жібергіміз келеді делік. Бізге екі бейне (біз + кесте) және бір аудио (біз) қажет болады. Біз және кестені әртүрлі ағындарға бөлу керек екені анық, өйткені бұл деректер бір-біріне әлсіз тәуелді болуы мүмкін. Сондықтан бізде екі болады медиа ағыны‘a – біреуі бізге, бірі дастарханға. Біріншісінде бейне және аудио деректер де болады, ал екіншісінде тек бейне болады (4-сурет).

4-сурет: Екі түрлі медиа ағыны. Біреуі бізге, бірі дастарханымызға

Медиа ағыны кем дегенде деректерді қамту мүмкіндігін қамтуы керек екені бірден түсінікті әртүрлі түрлері- бейне және аудио. Бұл технологияда ескеріледі, сондықтан деректердің әрбір түрі медиа трек арқылы жүзеге асырылады. медиа трек. Медиа тректің ерекше қасиеті бар мейірімді, ол біздің алдымызда не екенін анықтайды - бейне немесе аудио (5-сурет)

5-сурет: Медиа ағындары медиа тректерден тұрады

Бағдарламада бәрі қалай болады? Біз екі медиа ағынын жасаймыз. Содан кейін біз екі бейне трек және бір аудио трек жасаймыз. Камералар мен микрофонға қол жеткізейік. Әрбір трекке қандай құрылғыны пайдалану керектігін айтайық. Бірінші медиа ағынына бейне және аудио жолды және екінші медиа ағынына басқа камерадан бейне жолды қосамыз.

Бірақ қосылымның екінші жағындағы медиа ағындарын қалай ажыратамыз? Ол үшін әрбір медиа ағынының қасиеті болады заттаңба– ағын белгісі, оның атауы (6-сурет). Медиа тректер бірдей қасиетке ие. Бір қарағанда, бейнені дыбыстан басқа жолдармен ажыратуға болатын сияқты.

6-сурет: Медиа ағындары мен тректер белгілер арқылы анықталады

Сонымен, егер медиа тректерді жапсырма арқылы анықтауға болатын болса, онда неге бір емес, екі медиа ағынын мысалға пайдалануымыз керек? Өйткені, сіз бір медиа ағынын тасымалдай аласыз және онда әртүрлі тректерді пайдалана аласыз. Біз медиа ағындарының маңызды қасиетіне жеттік – олар синхрондаумедиа тректер. Әртүрлі медиа ағындары бір-бірімен синхрондалмайды, бірақ әрбір медиа ағынының ішінде барлық тректер бір уақытта ойнады.

Осылайша, сөзіміз, бетіміздегі эмоцияларымыз және қағаз парағымыз бір уақытта ойналғанын қаласақ, онда бір медиа ағынын қолданған жөн. Егер бұл соншалықты маңызды болмаса, онда әртүрлі ағындарды пайдалану тиімдірек - сурет тегіс болады.

Тасымалдау кезінде жолды өшіру қажет болса, сипатты пайдалануға болады қосылғанмедиа тректер.

Соңында сіз стерео дыбыс туралы ойлануыңыз керек. Өздеріңіз білетіндей, стерео дыбыс екі түрлі дыбыс. Және оларды бөлек жіберу керек. Ол үшін арналар қолданылады. MediaChannel. Аудио медиа трегінде көптеген арналар болуы мүмкін (мысалы, 5+1 аудио қажет болса, 6). Медиа трек ішінде, әрине, арналар синхрондалған. Бейне үшін әдетте бір ғана арна пайдаланылады, бірақ бірнеше, мысалы, жарнама қабаттары үшін пайдалануға болады.

Қорытындылай келе: бейне және аудио деректерді беру үшін медиа ағынын қолданамыз. Әрбір медиа ағынында деректер синхрондалады. Синхрондау қажет болмаса, біз бірнеше медиа ағындарын пайдалана аламыз. Әрбір медиа ағынында медиа тректердің екі түрі бар - бейне және аудио үшін. Әдетте екі жолдан аспайды, бірақ бірнеше түрлі бейнелерді (әңгімелесушінің және оның кестесінің) тасымалдау қажет болса, одан да көп болуы мүмкін. Әрбір трек әдетте тек стерео дыбыс үшін пайдаланылатын бірнеше арнадан тұруы мүмкін.

Ең қарапайым бейне чат жағдайында бізде екі тректен тұратын бір жергілікті медиа ағыны болады - бейне трек және аудио трек, олардың әрқайсысы бір негізгі арнадан тұрады. Бейне трек камераға жауап береді, аудио трек микрофонға арналған, ал медиа ағыны екеуінің де контейнері болып табылады.

Сеанс дескрипторы (SDP)

Әртүрлі компьютерлерде әрқашан әртүрлі камералар, микрофондар, видеокарталар және басқа жабдықтар болады. Оларда көптеген нұсқалар бар. Мұның барлығы екі желі түйіні арасында медиа деректерін тасымалдау үшін үйлестірілуі керек. WebRTCавтоматты түрде жасайды және жасайды арнайы объект- сеанс дескрипторы SDP. Бұл нысанды басқа түйінге өткізіңіз және сіз медиа деректерін жібере аласыз. Тек басқа түйінмен байланыс әлі жоқ.

Ол үшін кез келген сигналдық механизм қолданылады. SDPтіпті розеткалар арқылы да, тіпті адам (оны басқа түйінге телефон арқылы айтыңыз), тіпті орыс поштасы арқылы да жібере алады. Барлығы өте қарапайым - сізге дайын өнім беріледі SDPжәне оны жіберу керек. Ал екінші жағынан алған соң – бөлімге ауысады WebRTC. Сеанс дескрипторы мәтін ретінде сақталады және оны қолданбаларда өзгертуге болады, бірақ әдетте қажет емес. Мысал ретінде, жұмыс үстелін↔телефонды қосқанда, кейде қажетті аудио кодектерді таңдауға мәжбүрлеу керек.

Әдетте, қосылымды орнату кезінде, мысалы, кейбір мекенжайды көрсету керек URL. Бұл жерде мұның қажеті жоқ, өйткені сигнал беру механизмі арқылы деректерді тағайындалған жерге өзіңіз жібересіз. Белгілеу үшін WebRTCне орнатқымыз келеді p2pқосылым үшін createOffer функциясын шақыру керек. Бұл функцияны шақырғаннан кейін және оған арнайы қайта телефон соғу‘а құрылады SDPнысанға және бірдейге өтті қайта телефон соғу. Сізден талап етілетін нәрсе - бұл нысанды желі арқылы басқа түйінге (әңгімелесушіге) беру. Осыдан кейін, екінші жағынан, деректер сигнал беру механизмі арқылы келеді, атап айтқанда бұл SDPобъект. Бұл сеанс дескрипторы осы түйінге бөтен болып табылады, сондықтан пайдалы ақпаратты тасымалдайды. Бұл нысанды алу қосылымды бастау сигналы болып табылады. Сондықтан сіз бұған келісіп, createAnswer функциясын шақыруыңыз керек. Бұл createOffer толық аналогы. Сіздің қайта телефон соғужергілікті сеанс дескрипторынан өтеді және оны сигнал беру механизмі арқылы қайтару қажет болады.

Айта кету керек, createAnswer функциясын басқа біреудің функциясын алғаннан кейін ғана шақыруға болады SDPобъект. Неліктен? Өйткені жергілікті SDP createAnswer шақырылған кезде жасалатын нысан қашықтан басқару құралына сенуі керек SDPобъект. Тек осы жағдайда ғана сіздің бейне параметрлеріңізді әңгімелесушінің параметрлерімен үйлестіруге болады. Сондай-ақ, жергілікті медиа ағыны қабылданбайынша createAnswer және createOffer деп қоңырау шалмаңыз - олардың жазатын ештеңесі болмайды. SDPобъект.

бастап WebRTCөңдеуге болады SDPнысан, содан кейін жергілікті тұтқаны алғаннан кейін оны орнату керек. Бұл өту сәл оғаш көрінуі мүмкін WebRTCол бізге не берді, бірақ бұл протокол. Қашықтағы тұтқаны алған кезде оны орнату керек. Сондықтан бір түйінге екі дескрипторды орнату керек - өзіңіздің және басқа біреудің (яғни, жергілікті және қашықтағы).

Осындайдан кейін қол алысутүйіндер бір-бірінің тілектері туралы біледі. Мысалы, егер түйін 1 кодектерді қолдайды АЖәне Б, және түйін 2 кодектерді қолдайды БЖәне C, содан кейін әрбір түйін өзінің және басқаның дескрипторларын білетіндіктен, екі түйін де кодек таңдайды Б(7-сурет). Қосылу логикасы енді орнатылды және медиа ағындарын жіберуге болады, бірақ тағы бір мәселе бар - түйіндер әлі де сигнал беру механизмі арқылы қосылады.

7-сурет: Codec келіссөздері

Үміткерлер (мұз кандидаты)

Технология WebRTCбізді өзінің жаңа әдістемесімен шатастырғысы келеді. Қосылымды орнату кезінде қосылғыңыз келетін түйіннің мекенжайы көрсетілмейді. Алдымен орнатылды логикалықбайланыс, жоқ физикалық, дегенмен керісінше әрқашан жасалды. Бірақ бұл таңқаларлық болып көрінбейді, егер біз үшінші тараптың сигнал беру механизмін қолданатынымызды ұмытпасақ.

Сонымен, байланыс орнатылып қойған (логикалық байланыс), бірақ желі түйіндері үшін деректерді жіберуге әлі мүмкіндік жоқ. Мұның бәрі қарапайым емес, бірақ қарапайым бастайық. Түйіндер бір жеке желіде болсын. Біз білетіндей, олар бір-бірімен ішкі арқылы оңай қосыла алады IPмекенжайлар (немесе пайдаланылмаса, басқа да болуы мүмкін TCP/IP).

Кейбіреулер арқылы қайта телефон соғу'Және WebRTCбізге айтады Мұз кандидатынысандар. Олар сондай-ақ мәтіндік пішінде келеді және сеанс дескрипторлары сияқты, оларды сигнал беру механизмі арқылы жіберу керек. Сеанс дескрипторында камера мен микрофон деңгейіндегі параметрлеріміз туралы ақпарат болса, үміткерлер желідегі орнымыз туралы ақпаратты қамтиды. Оларды басқа түйінге жіберіңіз, сонда ол бізге физикалық түрде қосыла алады және оның сеанс дескрипторы бар болғандықтан, ол логикалық түрде қосыла алады және деректер «ағылады». Егер ол бізге өзінің кандидаттық нысанын, яғни желіде қай жерде екендігі туралы ақпаратты жіберуді ұмытпаса, біз онымен байланыса аламыз. Бұл жерде біз клиент пен сервердің классикалық әрекеттестігінен тағы бір айырмашылықты атап өтеміз. HTTP серверімен байланыс сұрау-жауап схемасына сәйкес жүзеге асады, клиент деректерді өңдейтін серверге жібереді және оны келесі арқылы жібереді. сұрау пакетінде көрсетілген мекенжай. IN WebRTCбілу керек екі мекенжайжәне оларды екі жағынан қосыңыз.

Сеанс дескрипторларынан айырмашылығы тек қашықтағы кандидаттарды орнату қажет. Мұнда өңдеуге тыйым салынады және ешқандай пайда әкелмейді. Кейбір іске асыруларда WebRTCкандидаттар сеанс дескрипторлары орнатылғаннан кейін ғана орнатылуы керек.

Неліктен бір ғана сеанс дескрипторы болды, бірақ көптеген үміткерлер болуы мүмкін? Өйткені желідегі орналасу оның ішкі жағынан ғана емес анықталуы мүмкін IPмекенжайы, сонымен қатар маршрутизатордың сыртқы мекенжайы, міндетті түрде біреу емес, сонымен қатар мекенжайлар БҰРУсерверлер. Параграфтың қалған бөлігі кандидаттарды егжей-тегжейлі талқылауға және әртүрлі жеке желілердің түйіндерін қосу әдісіне арналады.

Сонымен, екі түйін бір желіде (8-сурет). Оларды қалай анықтауға болады? Көмегімен IPмекенжайлар. Басқа жол жоқ. Рас, сіз әлі де әртүрлі көліктерді пайдалана аласыз ( TCPЖәне UDP) және әртүрлі порттар. Бұл үміткер нысанында қамтылған ақпарат - IP, ПОРТ, КӨЛІКжәне басқалары. Мысалы, қолданайық UDPкөлік және 531 порт.

8-сурет: Екі түйін бір желіде

Сонда біз түйінде болсақ p1, Бұл WebRTCбізге осындай үміткер нысанды береді - . Бұл нақты формат емес, тек диаграмма. Егер біз түйінде болсақ p2, содан кейін кандидат . Сигнал беру механизмі арқылы p1кандидатты қабылдайды p2(яғни түйіннің орналасуы p2, атап айтқанда оның IPЖәне ПОРТ). Содан кейін p1-мен қосыла алады p2тікелей. Дұрысырақ, p1мекенжайына деректерді жібереді 10.50.150.3:531 жетеді деген үмітпен p2. Бұл мекенжай түйінге тиесілі ме, маңызды емес p2немесе кейбір делдал. Жалғыз маңызды нәрсе - деректер осы мекенжай арқылы жіберіледі және қол жеткізуге болады p2.

Түйіндер бір желіде болғанша - барлығы қарапайым және оңай - әрбір түйінде тек бір ғана үміткер объекті болады (әрқашан өзінің, яғни желідегі орнын білдіреді). Бірақ түйіндер болған кезде үміткерлер әлдеқайда көп болады әртүрліжелілер.

Күрделі іске көшейік. Бір түйін маршрутизатордың артында (дәлірек айтқанда, NAT артында), ал екінші түйін осы маршрутизатормен бір желіде болады (мысалы, Интернетте) (9-сурет).

9-сурет: Бір хост NAT артында, екіншісі жоқ

Бұл жағдайда мәселенің нақты шешімі бар, оны қазір қарастырамыз. үй маршрутизаторыәдетте кестені қамтиды NAT. Бұл маршрутизатордың жеке желісіндегі түйіндерге, мысалы, веб-сайттарға кіруге мүмкіндік беретін арнайы механизм.

Веб-сервер тікелей Интернетке қосылған деп есептейік, яғни жалпыға ортақ IP* мекен-жайы. Түйін болсын p2. Түйін p1(веб-клиент) мекенжайға сұраныс жібереді 10.50.200.10 . Біріншіден, деректер маршрутизаторға түседі r1, дәлірек айтқанда, оның интерьеринтерфейс 192.168.0.1 . Осыдан кейін маршрутизатор бастапқы мекенжайды (адрес p1) және оны арнайы кестеге енгізеді NAT, содан кейін бастапқы мекенжайды өзіне өзгертеді( p1 → r1). Әрі қарай, сәйкес сыртқыинтерфейс, маршрутизатор деректерді тікелей веб-серверге жібереді p2. Веб-сервер деректерді өңдейді, жауапты жасайды және оны кері жібереді. Маршрутизаторға жібереді r1, өйткені ол қайтару мекенжайында (маршрутизатор мекенжайды өзіне өзгертті). Маршрутизатор деректерді қабылдайды, кестеге қарайды NATжәне деректерді түйінге жібереді p1. Бұл жерде маршрутизатор делдал ретінде әрекет етеді.

Бірақ ішкі желінің бірнеше түйіндері сыртқы желіге бір уақытта кірсе ше? Маршрутизатор жауапты кімге қайтару керектігін қалай түсінеді? Бұл мәселе көмегімен шешіледі порттар. Маршрутизатор хост мекенжайын өзінің мекен-жайымен ауыстырғанда, ол портты да ауыстырады. Егер екі түйін Интернетке кірсе, маршрутизатор өздерінің бастапқы порттарын ауыстырады әртүрлі. Содан кейін веб-серверден пакет маршрутизаторға қайтып келгенде, маршрутизатор бұл пакет тағайындалған порт арқылы түсінеді. Төменде мысал келтірілген.

Технология дегенге қайта келу WebRTC, дәлірек айтқанда, оның пайдаланатын бөлігіне ICEхаттама (демек Мұзкандидаттар). Түйін p2бір үміткер бар (оның желідегі орны - 10.50.200.10 ) және түйін p1, NAT бар маршрутизатордың артында орналасқан, екі үміткер болады - жергілікті ( 192.168.0.200 ) және маршрутизатор кандидаты ( 10.50.200.5 ). Біріншісі пайдалы емес, бірақ ол соған қарамастан жасалады, өйткені WebRTCқашықтағы хост туралы әлі ештеңе білмейді - ол бір желіде болуы немесе болмауы мүмкін. Екінші үміткер пайдалы болады және біз білетіндей, порт маңызды рөл атқарады (өту үшін NAT).

Кестені енгізу NATдеректер ішкі желіден шыққанда ғана жасалады. Сондықтан түйін p1алдымен деректерді, содан кейін ғана түйіннің деректерін беруі керек p2түйініне жете алады p1.

Іс жүзінде екі түйінартта қалады NAT. Кестеде жазба жасау үшін NATәрбір маршрутизаторда түйіндер қашықтағы түйінге бірдеңе жіберуі керек, бірақ бұл жолы біріншісі де екіншісіне жете алмайды, не керісінше. Бұл түйіндердің сыртқы жағын білмеуіне байланысты IPмекенжайлар және деректерді ішкі мекенжайларға жіберу мағынасыз.

Дегенмен, егер сыртқы мекенжайлар белгілі болса, онда байланыс оңай орнатылады. Егер бірінші түйін деректерді екінші түйіннің маршрутизаторына жіберсе, онда маршрутизатор оларды елемейді, өйткені оның кестесі NATбос кезде. Дегенмен, кестедегі бірінші түйіннің маршрутизаторында NATрекорд қажет болды. Егер қазір екінші түйін деректерді бірінші түйіннің маршрутизаторына жіберсе, онда маршрутизатор оларды бірінші түйінге сәтті жібереді. Енді үстел NATекінші маршрутизаторда қажетті деректер бар.

Мәселе мынада, сіздің сыртқы дүниеңізді білу үшін IPмекенжайы үшін сізге орналасқан түйін қажет ортақ желі. Бұл мәселені шешу үшін Интернетке тікелей қосылған қосымша серверлер пайдаланылады. Олардың көмегімен кестедегі құнды жазбалар да жасалады. NAT.

STUN және TURN серверлері

Баптандыру кезінде WebRTCқолжетімді ТАҢДАУЖәне БҰРУсерверлер, біз оларға сілтеме жасаймыз ICEсерверлер. Егер серверлер көрсетілмесе, онда бір желідегі түйіндер ғана (оған NAT). Бұл үшін бірден атап өту керек 3г- желілерді пайдалану керек БҰРУсерверлер.

ТАҢДАУ сервержай ғана қайтару адресін, яғни жіберушінің хостының мекенжайын қайтаратын Интернеттегі сервер. Маршрутизатордың артындағы түйін қол жеткізеді ТАҢДАУөту үшін сервер NAT. Келген пакет ТАҢДАУсервер, бастапқы мекенжайды қамтиды - маршрутизатордың мекенжайы, яғни біздің түйіннің сыртқы мекенжайы. Бұл мекенжай ТАҢДАУсервер және кері жібереді. Осылайша, түйін өзінің сыртқы түрін алады IPмекенжайы және желіден қол жеткізуге болатын порт. Әрі қарай, WebRTCосы мекенжайды пайдалану қосымша үміткерді жасайды (сыртқы маршрутизатор мекенжайы және порт). Енді кестеде NATмаршрутизаторда қажетті порттағы маршрутизаторға жіберілген пакеттерді біздің түйінге беретін жазба бар.

Бұл процесті мысалмен қарастырайық.

Мысал (STUN серверінің жұмысы)

ТАҢДАУсервер келесімен белгіленеді s1. Маршрутизатор, бұрынғыдай, арқылы r1, және түйін арқылы p1. Сіз сондай-ақ кестені орындауыңыз керек NAT- деп белгілейік r1_nat. Сонымен қатар, бұл кесте әдетте әртүрлі ішкі желі түйіндерінің көптеген жазбаларын қамтиды - олар берілмейді.

Сонымен, басында бізде бос үстел бар r1_nat.

2-кесте: Пакет тақырыбы

Түйін p1бұл пакетті маршрутизаторға жібереді r1(қалай болса да, әртүрлі ішкі желілерде қолданылуы мүмкін әртүрлі технологиялар). Маршрутизатор бастапқы мекенжайды ауыстыруы керек src IP, пакетте көрсетілген мекенжай, әрине, сыртқы ішкі желіге сәйкес келмейтіндіктен, осы ауқымдағы мекенжайлар сақталған және Интернеттегі бірде-бір мекенжайда мұндай мекенжай жоқ. Маршрутизатор пакетте ауыстыруды жасайды және жасайды жаңа рекордсіздің үстеліңізде r1_nat. Ол үшін порт нөмірін ойлап табу керек. Еске салайық, ішкі желідегі бірнеше түйіндер сыртқы желіге кіре алатындықтан, кестеде NATсақталуы керек қосымша ақпаратмаршрутизатор серверден қайтарылатын пакет осы бірнеше хосттардың қайсысына арналғанын анықтай алуы үшін. Маршрутизатор портты ойлап тапсын 888 .

Өзгертілген пакет тақырыбы:

4-кесте: NAT кестесі жаңа жазбамен жаңартылды

Мұнда IPішкі желі мекенжайы мен порты түпнұсқалық пакетпен бірдей. Шынында да, кері қайтару кезінде бізде оларды толығымен қалпына келтірудің жолы болуы керек. IPсыртқы желінің мекенжайы маршрутизатордың мекенжайы болып табылады, ал порт маршрутизатор ойлап тапқанға өзгерді.

Түйін баратын нақты порт p1байланысты қабылдайды - бұл, әрине, 35777 , бірақ сервер деректерді жібереді ойдан шығарылғанпорт 888 , оны маршрутизатор нақтыға өзгертеді 35777 .

Осылайша, маршрутизатор пакет тақырыбындағы бастапқы мекенжай мен портты өзгертіп, кестеге жазба қосты NAT. Енді пакет желі арқылы серверге, яғни түйінге жіберіледі s1. кіре берісте, s1мына пакет бар:

src IP	Src PORT	Мақсатты IP	DEST PORT
10.50.200.5	888	12.62.100.200	6000

5-кесте: STUN сервері пакетті алды

Барлығы ТАҢДАУсервер адрестен пакетті алғанын біледі 10.50.200.5:888 . Енді сервер бұл мекенжайды кері жібереді. Осы жерде тоқтап, жаңа ғана қарастырғанымызға қайта оралған жөн. Жоғарыдағы кестелер бөлігі болып табылады тақырыбыпакет, одан мүлде емес мазмұны. Біз мазмұн туралы айтқан жоқпыз, өйткені ол соншалықты маңызды емес - ол қандай да бір түрде хаттамада сипатталған ТАҢДАУ. Енді тақырыпқа қосымша мазмұнды да қарастырамыз. Бұл қарапайым болады және маршрутизатордың мекенжайын қамтиды - 10.50.200.5:888 біз оны алғанымызға қарамастан тақырыбыпакет. Бұл жиі жасалмайды, әдетте хаттамалар түйіндердің мекенжайлары туралы ақпаратқа мән бермейді, тек пакеттердің тағайындалған жеріне жеткізілуі маңызды. Мұнда біз екі түйін арасындағы жолды орнататын протоколды қарастырамыз.

Енді бізде қарама-қарсы бағытта жүретін екінші партия бар:

7-кесте: STUN сервері осы мазмұнмен пакетті жібереді

Әрі қарай, пакет маршрутизатордың сыртқы интерфейсіне жеткенше желі арқылы жүреді r1. Маршрутизатор пакеттің оған арналмағанын түсінеді. Оны қалай түсінеді? Мұны тек порт арқылы табуға болады. Порт 888 ол өзінің жеке мақсаттары үшін пайдаланбайды, бірақ механизм үшін пайдаланады NAT. Сондықтан маршрутизатор осы кестеге қарайды. Бағанға қарайды Сыртқы портжәне сәйкес келетін жолды іздейді DEST PORTкіріс пакетінен, яғни 888 .

ішкі IP	Ішкі порт	сыртқы IP	Сыртқы порт
192.168.0.200	35777	10.50.200.5	888

8-кесте: NAT кестесі

Біз бақыттымыз, мұндай сызық бар. Егер сәттілік болмаса, пакет жай ғана жойылар еді. Енді сіз ішкі желі түйіндерінің қайсысы осы пакетті жіберу керектігін түсінуіңіз керек. Асықпай, осы механизмдегі порттардың маңыздылығын қайталап көрейік. Бұл ретте ішкі желідегі екі түйін сыртқы желіге сұраныс жібере алады. Содан кейін, егер бірінші түйін үшін маршрутизатор портты ойлап тапса 888 , содан кейін ол екінші портты ойлап табады 889 . Бұл болды делік, яғни кесте r1_natбылай көрінеді:

10-кесте: Маршрутизатордың спуфинг қабылдағышының мекенжайы

src IP	Src PORT	Мақсатты IP	DEST PORT
12.62.100.200	6000	192.168.0.200	35777

11-кесте: Маршрутизатор ресивер мекенжайын өзгертті

Пакет түйінге сәтті келді p1және пакеттің мазмұнына қарап, түйін оның сыртқы туралы біледі IPадресі, яғни сыртқы желідегі маршрутизатордың мекенжайы. Ол сонымен қатар маршрутизатор өтетін портты біледі NAT.

Келесі не? Мұның бәрінен не пайда? Пайда - кестедегі жазба r1_nat. Егер қазір біреу маршрутизаторға жібереді r1порт пакеті 888 , содан кейін маршрутизатор бұл пакетті хостқа жібереді p1. Осылайша, жасырын түйінге шағын тар өткел жасалды p1.

Жоғарыдағы мысалдан сіз оның қалай жұмыс істейтіні туралы түсінік ала аласыз. NATжәне мәні ТАҢДАУсервер. Жалпы, механизм ICEЖәне ТАҢДАУ/БҰРЫЛУсерверлер тек шектеулерді еңсеруге бағытталған NAT.

Түйін мен сервер арасында бірнеше маршрутизатор болуы мүмкін, бірақ бірнеше. Бұл жағдайда түйін сервермен бір желіге бірінші болып кіретін маршрутизатордың мекенжайын алады. Басқаша айтқанда, біз қосылған маршрутизатордың мекенжайын аламыз ТАҢДАУсервер. Үшін p2pбайланыс - бұл бізге қажет нәрсе, егер біз әрбір маршрутизаторда кестеге қажетті сызық қосылатынын ұмытпасақ NAT. Демек, кері қайтар жолы да дәл солай тегіс болады.

БҰРУсервер жетілдірілді ТАҢДАУсервер. Бұдан шығатыны бірден кез келген БҰРУсервер жұмыс істей алады және қалай ТАҢДАУсервер. Дегенмен, пайдасы да бар. Егер p2pбайланыс орнату мүмкін емес (мысалы 3гжелілер), содан кейін сервер қайталау режиміне ауысады ( реле), яғни делдал ретінде жұмыс істейді. Әрине, кез келген туралы p2pонда бұл мәселе емес, механизм шеңберінен тыс ICEтүйіндер тікелей байланысады деп ойлайды.

Қандай жағдайларда қажет БҰРУсервер? Неге жетпейді ТАҢДАУсерверлер? Өйткені, оның бірнеше түрі бар NAT. Олар бірдей ауыстырады IPмекенжайы мен порты, бірақ олардың кейбіреулерінде «жалған жасаудан» қосымша қорғаныс орнатылған. Мысалы, в симметриялыкесте NATТағы 2 параметр сақталады - IPжәне қашықтағы хосттың порты. Сыртқы желіден пакет өтеді NATбастапқы мекенжай мен порт кестеде жазылғандарға сәйкес келсе ғана ішкі желіге. Сондықтан, назар ТАҢДАУсервер сәтсіз аяқталды - кесте NATмекенжай мен портты сақтайды ТАҢДАУсервер және маршрутизатор пакетті қашан қабылдайды WebRTCәңгімелесуші, ол «жалған» болғандықтан, оны тастайды. Ол келген жоқ ТАҢДАУсервер.

Осылайша БҰРУекі сұхбаттасушы артта қалғанда сервер қажет симметриялы NAT(әрқайсысы өзі үшін).

Қысқаша қорытынды

Мұнда нысандар туралы кейбір мәлімдемелер берілген WebRTCәрқашан есте ұстау керек. Олар жоғарыда егжей-тегжейлі сипатталған. Егер мәлімдемелердің кез келгені сізге толық түсініксіз болып көрінсе, тиісті абзацтарды қайта оқып шығыңыз.

• медиа ағыны
  • Бейне және аудио деректері медиа ағындарына жинақталған
  • Медиа ағындары құрайтын медиа тректерді синхрондайды
  • Әртүрлі медиа ағындары синхрондалмаған
  • Медиа ағындары жергілікті және қашықтағы болуы мүмкін, камера мен микрофон әдетте жергіліктіге қосылады, қашықтағылар желіден деректерді шифрланған түрде алады.
  • Медиа тректердің екі түрі бар - бейне және аудио үшін.
  • Медиа тректердің қосу/өшіру мүмкіндігі бар
  • Медиа тректер медиа арналардан тұрады
  • Медиа тректер құрайтын медиа арналарды синхрондайды
  • Медиа ағындары мен медиа тректерінде оларды ажыратуға болатын белгілер бар
• Сеанс дескрипторы
  • Сеанс дескрипторы екі желі түйінін логикалық қосу үшін қолданылады
  • Сеанс дескрипторы туралы ақпаратты сақтайды қолжетімді жолдарбейне және дыбыс деректерін кодтау
  • WebRTCсыртқы сигнал беру механизмін пайдаланады - сеанс дескрипторларын жіберу тапсырмасы ( sdp) қолданбаға түседі
  • Логикалық байланыс механизмі екі кезеңнен тұрады – ұсыныс ( ұсыныс) және жауап ( жауап)
  • Ұсыныс болған жағдайда жергілікті медиа ағынын пайдаланбай сеанс дескрипторын құру мүмкін емес ( ұсыныс) және жауап болған жағдайда қашықтағы сеанс дескрипторын қолданбай мүмкін емес ( жауап)
  • Алынған дескриптор іске асыруға берілуі керек WebRTC, және бұл дескриптор бірдей іске асырудан қашықтан немесе жергілікті түрде алынғаны маңызды емес WebRTC
  • Сеанс дескрипторын сәл өңдеуге болады
• Үміткерлер
  • кандидат ( Мұз кандидаты) – желідегі түйіннің адресі
  • Түйін мекенжайы сіздің жеке болуы мүмкін немесе ол маршрутизатордың немесе мекенжайы болуы мүмкін БҰРУсерверлер
  • Үміткерлер әрқашан көп
  • Кандидат мыналардан тұрады IPмекенжайы, порты және көлік түрі ( TCPнемесе UDP)
  • Үміткерлер желідегі екі түйін арасында физикалық байланыс орнату үшін пайдаланылады
  • Үміткерлерді сигнал беру механизмі арқылы жіберу керек
  • Үміткерлер сонымен қатар енгізулерден өтуі керек WebRTC, бірақ тек қашықтан
  • Кейбір іске асыруларда WebRTCҮміткерлер сеанс дескрипторы орнатылғаннан кейін ғана тапсыра алады
• ТАҢ/БҰРЫЛУ/МҰЗ/НАТ
  • NAT– сыртқы желіге кіруді қамтамасыз ету механизмі
  • Үй маршрутизаторлары арнайы кестені қолдайды NAT
  • Маршрутизатор пакеттердегі адрестерді ауыстырады - бастапқы мекенжайды, егер пакет сыртқы желіге өтсе, өз адресімен, ал десте сыртқы желіден келсе, ішкі желідегі хост мекенжайымен тағайындалған мекенжайды ауыстырады.
  • Сыртқы желіге көп арналы қатынасты қамтамасыз ету NATпорттарды пайдаланады
  • ICE- айналып өту механизмі NAT
  • ТАҢДАУЖәне БҰРУсерверлер – айналып өтуге арналған көмекші серверлер NAT
  • ТАҢДАУсервер кестеде қажетті жазбаларды жасауға мүмкіндік береді NAT, сонымен қатар түйіннің сыртқы мекенжайын қайтарады
  • БҰРУсервер жалпылайды ТАҢДАУмеханизмі және оны үнемі жұмыс істеуге мүмкіндік береді
  • Ең нашар жағдайларда БҰРУсервер делдал ретінде пайдаланылады ( реле), яғни p2pклиент-сервер-клиент байланысына айналады.

Бүгінгі таңда WebRTC – браузерлерде аудио және бейне ағынының «ыстық» технологиясы. HTTP Streaming және Flash сияқты консервативті технологиялар жазылған мазмұнды (сұраныс бойынша бейне) тарату үшін қолайлы және нақты уақыттағы және онлайн-хабарламалар бойынша WebRTC-тен айтарлықтай төмен, яғни. Көрермендерге не болып жатқанын «тікелей» көруге мүмкіндік беретін ең аз бейне кідірісі қажет.

Нақты уақыттағы жоғары сапалы байланыстың мүмкіндігі WebRTC архитектурасының өзінен туындайды, мұнда UDP хаттамасы бейне ағындарын тасымалдау үшін пайдаланылады, ол бейнені минималды кідірістермен берудің стандартты негізі болып табылады және нақты уақыттағы байланыс жүйелерінде кеңінен қолданылады.

Байланыстың кешігуі тікелей ағындық жүйелерде, вебинарларда және бейне көзімен, соңғы пайдаланушылармен және шешіммен интерактивті байланыс қажет болатын басқа қолданбаларда маңызды.

WebRTC-ті сынап көрудің тағы бір жақсы себебі - бұл сөзсіз тренд. Бүгінгі әрбір Android Chrome браузерімиллиондаған құрылғылардың қосымша бағдарламалық құрал мен конфигурацияларды орнатпай-ақ хабар таратуды көруге дайын болуын қамтамасыз ететін осы технологияны қолдайды.

WebRTC технологиясын іс жүзінде сынау және оған қарапайым онлайн хабар таратуды іске қосу үшін біз Flashphoner WebRTC Media & Broadcasting Server сервер бағдарламалық құралын қолдандық. Мүмкіндіктер WebRTC ағындарын бір-көп режимінде тарату мүмкіндігін, сондай-ақ RTSP хаттамасы арқылы IP камералары мен бейнебақылау жүйелерін қолдауды жариялайды; осы шолуда біз веб-веб-таратуларға және олардың мүмкіндіктеріне тоқталамыз.

WebRTC Media & Broadcasting Server орнату

Өйткені үшін Windows жүйелерісервер нұсқасы болған жоқ, мен VMWare + Linux сияқты виртуалды машинаны орнатқым келмеді, үйде онлайн таратылымдарды сынап көргім келмеді Windows компьютеріболмады. Уақытты үнемдеу үшін біз бұлтты хостингтің мысалын алуды шештік:

Бұл Амстердам деректер орталығында алдын ала орнатылған бағдарламалық құралсыз Centos x86_64 6.5 нұсқасы болды. Осылайша, біздің қолымызда тек сервер және оған ssh қолжетімділігі бар. Танысатындар үшін консоль командалары Linux, WebRTC серверін орнату оңай және ауыртпалықсыз болады. Сонымен, біз не істедік:

1. Мұрағатты жүктеп алу:

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

2. Қаптаманы ашу:

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

3. Орнату:

$cd FlashphonerWebCallServer

Орнату кезінде сервердің IP мекенжайын енгізіңіз: XXX.XXX.XXX.XXX

4. Лицензияны белсендіру:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. WCS серверін іске қосыңыз:

$service webcallserver іске қосылады

6. Журналды тексеру:

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

7. Екі процестің бар-жоғын тексеріңіз:

$ps aux | grep Flashphoneer

Орнату процесі аяқталды.

WebRTC тікелей ағындарын сынау

Трансляцияларды тестілеу қарапайым мәселе болып шықты. Серверден басқа, ондаған Javascript, HTML және CSS файлдарынан тұратын веб-клиент бар және біз орнату кезеңінде /var/www/html қалтасына орналастырдық. Веб-клиент HTML5 Websockets арқылы серверге қосылым орнатуы үшін сервердің IP мекенжайын flashphoner.xml конфигурациясына енгізу керек болды. Тестілеу процесін сипаттайық.

1. Chrome браузерінде сынақ клиентінің index.html бетін ашыңыз:

2. Трансляцияны бастау үшін экранның ортасындағы «Бастау» түймесін басу керек.
Мұны жасамас бұрын, веб-камера қосылғанына және жұмысқа дайын екеніне көз жеткізу керек. Веб-камера үшін арнайы талаптар жоқ, мысалы, біз 1280 × 800 рұқсаты бар стандартты кірістірілген ноутбук камерасын қолдандық.

Chrome браузері міндетті түрде камера мен микрофонға қол жеткізуді сұрайды, осылайша пайдаланушы өз бейнесінің интернет серверіне жіберілетінін түсінеді және оған рұқсат береді.

3. Интерфейс бейне ағынының камерадан WebRTC серверіне сәтті таратылуын білдіреді. Жоғарғы оң жақ бұрышта индикатор ағынның серверге өтіп жатқанын көрсетеді, төменгі бұрышта бейнені жіберуді тоқтату үшін «Тоқтату» түймесі бар.

Төмендегі сілтемені қараңыз. Онда осы ағын үшін бірегей идентификатор бар, сондықтан кез келген адам көрініске қосыла алады. Бұл сілтемені браузерде ашыңыз. Оны алмасу буферіне көшіру үшін «Көшіру» түймесін басу керек.

Вебинарлар, лекциялар, онлайн бейне хабарлар немесе интерактивті теледидар сияқты нақты қолданбаларда әзірлеушілер бұл идентификаторды көрермендердің белгілі топтарына таратуды жүзеге асыруы керек, сонда олар қалаған ағындарға қосыла алады, бірақ бұл қолданбаның логикасы. WebRTC медиа және хабар тарату сервері ол әсер етпейді, тек бейнені таратумен айналысады.

5. Байланыс орнатылып, көрермен экрандағы ағынды көреді. Енді ол төменгі оң жақ бұрыштағы басқару элементтерін пайдаланып сілтемені басқа біреуге жібере алады, ағынмен ойнатуды тоқтата алады немесе толық экран режимін қоса алады.

Онлайн таратылымдар үшін WebRTC серверінің сынақ нәтижелері

Сынақтар кезінде кідіріс мінсіз болып көрінді. Деректер орталығына пинг шамамен 100 миллисекунд болды және кідіріс көзге көрінбеді. Осы жерден біз нақты кідіріс буферлеу уақыты үшін бірдей 100 плюс немесе минус бірнеше ондаған миллисекундтар деп болжауға болады. Flash бейнесімен салыстырғанда, Flash бұл сынақтарда WebRTC сияқты жақсы жұмыс істемейді. Сонымен, егер сіз қолыңызды ұқсас желіде жылжытсаңыз, экрандағы қозғалысты тек бір/екі секундтан кейін ғана көруге болады.

Сапаға келетін болсақ, кейде қозғалыстар бойынша текшелерді ажыратуға болатынын ескереміз. Бұл VP8 кодекінің табиғатына сәйкес келеді және оның негізгі мақсаты қолайлы сапамен және байланыс кідірістерінсіз нақты уақыттағы бейне байланысты қамтамасыз ету болып табылады.

Серверді орнату және конфигурациялау өте оңай, оны іске қосу үшін ешқандай күрделі дағдылар қажет емес, тек ssh арқылы консольден пәрмендерді орындай алатын және қолдана алатын озық пайдаланушы деңгейіндегі Linux білімін қоспағанда мәтіндік редактор. Нәтижесінде біз браузерлер арасында бір-көп онлайн-трансляциясын орната алдық. Қосымша көрушілерді ағынға қосу да қиындық тудырмады.

Трансляция сапасы вебинарлар мен онлайн-хабарламалар үшін өте қолайлы болып шықты. Кейбір сұрақтарды тудырған жалғыз нәрсе - бейненің шешімі. Камера 1280x800-ді қолдайды, бірақ сынақ суретіндегі ажыратымдылық 640x480-ге өте ұқсас. Бұл мәселені әзірлеушілермен түсіндіру керек сияқты.

Веб-камерадан тестілеу туралы бейне
WebRTC сервері арқылы

Браузерден қоңырау шалу технологиялары көптеген жылдар бойы бар: Java, ActiveX, Adobe Flash... Соңғы бірнеше жылда плагиндер және кетіп қалғаны белгілі болды виртуалды машиналаролар ыңғайлы түрде жарқырамайды (неге мен ештеңені орнатуым керек?) және, ең бастысы, қауіпсіздік. Енді не істеу керек? Шығу бар!

Соңғы уақытқа дейін IP желілерінде IP телефония немесе бейне үшін бірнеше протоколдар қолданылды: SIP, оқиға орнынан шығатын ең көп таралған протокол, H.323 және MGCP, Jabber/Jingle (Gtalk-те пайдаланылады), жартылай ашық Adobe RTMP* және, әрине, жабық Skype. Google бастаған WebRTC жобасы IP және веб-телефония әлемін өзгертуге тырысуда. бағдарламалық телефондарсоның ішінде Skype. WebRTC қазір барлық дерлік құрылғыларда орнатылған шолғыштың ішінде тікелей барлық байланыс мүмкіндіктерін жүзеге асырып қана қоймайды, сонымен бірге браузер пайдаланушылары арасындағы байланыстың жалпылама міндетін шешуге тырысады (әртүрлі деректермен алмасу, экрандық хабар тарату, құжаттармен жұмыс істеу және әлдеқайда көп).

WebRTC веб-әзірлеушісі

Веб-әзірлеушінің көзқарасы бойынша WebRTC екі негізгі бөліктен тұрады:

• жергілікті ресурстардан (камера, микрофон немесе экран) медиа ағындарын басқару жергілікті компьютер) MediaStream нысанын қайтаратын navigator.getUserMedia әдісі арқылы жүзеге асырылады;
• байланыс әдістерін анықтауды және олардың тікелей берілуін қоса алғанда, медиа ағындарын генерациялайтын құрылғылар арасындағы тең дәрежелі байланыстар – RTCPeerConnection объектілері (дыбыс және бейне ағындарын жіберу және қабылдау үшін) және RTCDataChannel (браузерден деректерді жіберу және қабылдау үшін).

Не істейміз?

Біз веб-розеткалар арқылы WebRTC негізіндегі браузерлер арасында ең қарапайым мультиплеерлі бейне чатты қалай ұйымдастыру керектігін анықтаймыз. Chrome/Chromium-да тәжірибені бастайық, өйткені WebRTC тұрғысынан ең озық браузерлер, дегенмен 24 маусымда шығарылған Firefox 22 оларды қуып жетті. Айта кету керек, стандарт әлі қабылданбаған және API нұсқадан нұсқаға өзгеруі мүмкін. Барлық мысалдар Chromium 28 жүйесінде сыналған. Қарапайымдылық үшін біз кодтың тазалығын және браузерлер арасындағы үйлесімділікті бақыламаймыз.

медиа ағыны

Бірінші және қарапайым WebRTC компоненті MediaStream болып табылады. Ол шолғышқа жергілікті компьютердің камерасы мен микрофонынан медиа ағындарына қол жеткізуді қамтамасыз етеді. Chrome браузерінде бұл үшін navigator.webkitGetUserMedia() функциясын шақыру қажет (стандарт әлі аяқталмағандықтан, барлық функциялар префикспен келеді және Firefox-та бірдей функция navigator.mozGetUserMedia() деп аталады). Ол шақырылған кезде пайдаланушыдан камера мен микрофонға кіруге рұқсат беру сұралады. Пайдаланушы келісімін бергеннен кейін ғана қоңырауды жалғастыру мүмкін болады. Қажетті медиа ағынының параметрлері және екі кері шақыру функциясы осы функцияға параметрлер ретінде беріледі: біріншісі камераға/микрофонға сәтті қол жеткізген жағдайда шақырылады, екіншісі - қате болған жағдайда. Алдымен түймесі мен элементі бар rtctest1.html HTML файлын жасайық

getUserMedia

Microsoft CU-RTC-Web

Егер Google бастамасына жауап ретінде CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web) деп аталатын өзінің үйлеспейтін теңшелетін нұсқасын бірден шығармаса, Microsoft корпорациясы Microsoft болмас еді. htm). IE үлесі қазірдің өзінде аз болса да, азайып келе жатқанымен, Skype пайдаланушыларының саны Microsoft-қа Google-ді итермелеуге үміт береді және бұл стандарт браузерде қолданылады деп болжауға болады. Skype нұсқалары. Google стандарты ең алдымен браузерден шолғышқа қатынасуға бағытталған; сонымен бірге дауыстық трафиктің негізгі бөлігі бұрынғысынша кәдімгі телефон желісінде қалады және онымен IP желілері арасындағы шлюздер пайдаланудың қарапайымдылығы немесе жылдамырақ тарату үшін ғана емес, сонымен қатар көбірек ойыншыларға мүмкіндік беретін монетизация құралы ретінде қажет. оларды дамыту. Басқа стандарттың пайда болуы әзірлеушілерге бірден екі үйлесімсіз технологияны қолдаудың жағымсыз қажеттілігіне әкеліп қана қоймайды, сонымен қатар болашақта пайдаланушыға мүмкін болатын функционалдылық пен қол жетімді техникалық шешімдердің кең таңдауын береді. Күте тұрыңыз және көріңіз.

Жергілікті ағынды қосыңыз

Ішкі тегтерБіздің HTML файлымызда медиа ағыны үшін жаһандық айнымалыны жариялайық:

VarlocalStream = null;

getUserMedia әдісінің бірінші параметрі сұралған медиа ағынының параметрлерін көрсету болып табылады - мысалы, жай ғана аудио немесе бейнені қосыңыз:

Var streamConstraints = («аудио»: шын, «бейне»: шын ); // Аудиоға да, бейнеге де рұқсат сұрау

Немесе қосымша параметрлерді көрсетіңіз:

Var streamConstraints = ( "аудио": шын, "бейне": ( "міндетті": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" ), "қосымша": ) );

getUserMedia әдісінің екінші параметрі сәтті болған жағдайда шақырылатын кері шақыру функциясын беру болып табылады:

Функция getUserMedia_success(stream) ( console.log("getUserMedia_success():", ағын); localVideo1.src = URL.createObjectURL(ағын); // HTML элементіне мультимедиа ағынын тіркеу

Үшінші параметр - кері шақыру функциясы, қате болған жағдайда шақырылатын қате өңдегіш.

getUserMedia_error(қате) функциясы ( console.log("getUserMedia_error():", қате); )

getUserMedia әдісіне нақты қоңырау - бірінші түйме басылған кезде микрофон мен камераға кіруді сұрау

getUserMedia_click() функциясы ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

Жергілікті түрде ашылған файлдан медиа ағынына қол жеткізу мүмкін емес. Егер біз мұны істеуге тырыссақ, біз қатені аламыз:

NavigatorUserMediaError (код: 1, PERMISSION_DENIED: 1)"

Алынған файлды серверге жүктеп, оны браузерде ашып, пайда болған сұрауға жауап ретінде камера мен микрофонға кіруге рұқсат етейік.

Chrome қай құрылғыларға кіретінін "Параметрлер", "Қосымша параметрлерді көрсету" сілтемесі, Құпиялылық бөлімі, Мазмұн түймесі арқылы таңдауға болады. Firefox және Opera браузерлерінде кіру рұқсаты берілгенде құрылғылар ашылмалы тізімнен тікелей таңдалады.

HTTP протоколын пайдаланған кезде, бет жүктелгеннен кейін медиа ағынына қатынасқан сайын рұқсат сұралады. HTTPS жүйесіне ауысу сұрауды бір рет, тек медиа ағынына бірінші рет қол жеткізгенде ғана көрсетуге мүмкіндік береді.

Қойындыдағы белгішедегі пульсирленген шеңберге және мекенжай жолағының оң жағындағы камера белгішесіне назар аударыңыз:

RTCMediaConnection

RTTCMediaConnection – қатысушылар арасында желі арқылы медиа ағындарын орнатуға және тасымалдауға арналған нысан. Сонымен қатар, бұл нысан медиа сеансының сипаттамасын (SDP) жасауға, NAT немесе NAT арқылы өту үшін ICE кандидаттары туралы ақпаратты алуға жауап береді. брандмауэрлер(жергілікті және STUN арқылы) және TURN серверімен әрекеттесу. Әрбір қатысушыда бір қосылымда бір RTTCMediaConnection болуы керек. Медиа ағындары шифрланған SRTP протоколы арқылы беріледі.

TURN серверлері

ICE үміткерлерінің үш түрі бар: хост, srflx және реле. Хост жергілікті түрде алынған ақпаратты қамтиды, srflx сыртқы серверге (STUN) сыртқы серверге ұқсайды және реле TURN сервері арқылы трафикті проксиге жіберуге арналған ақпарат болып табылады. Егер біздің хостымыз NAT-тың артында болса, онда хост кандидаттары болады жергілікті мекенжайларжәне пайдасыз болады, srflx кандидаттары тек белгілі бір NAT түрлеріне көмектеседі және реле аралық сервер арқылы трафикті өткізудің соңғы үміті болады.

192.168.1.37 мекенжайы және udp/34022 порты бар хост түріндегі ICE кандидатының мысалы:

A=кандидат:337499441 2 udp 2113937151 192.168.1.37 34022 типті хост буыны 0

STUN/TURN серверлерін көрсетудің жалпы пішімі:

Var servers = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn: [электрондық пошта қорғалған]:порт», «тіркелгі деректері»: «пароль» ) ]);

Интернетте көптеген қоғамдық STUN серверлері бар. Үлкен тізім, мысалы, . Өкінішке орай, олар тым аз мәселелерді шешеді. STUN-тан айырмашылығы, жалпыға қолжетімді TURN серверлері іс жүзінде жоқ. Бұл TURN сервері медиа ағындарын өзі арқылы өткізетініне байланысты, ол желі арнасын да, сервердің өзін де айтарлықтай жүктей алады. Сондықтан TURN серверлеріне қосылудың ең оңай жолы - оны өзіңіз орнату (сізге жалпыға қолжетімді IP қажет болатыны анық). Барлық серверлердің ішінде, менің ойымша, ең жақсысы rfc5766-turn-server . Оның астында тіпті Amazon EC2 үшін дайын сурет бар.

TURN көмегімен бәрі біз қалағандай жақсы емес, бірақ белсенді даму жүріп жатыр, және мен WebRTC біраз уақыттан кейін мекенжай аудармасынан өту сапасы бойынша Skype-ты қуып жетпесе деп үміттенгім келеді ( NAT) және брандмауэр, содан кейін кем дегенде айтарлықтай жақындайды.

RTTCMediaConnection байланыс орнату үшін басқару ақпаратымен алмасудың қосымша механизмін қажет етеді - ол бұл деректерді жасағанымен, оны жібермейді, ал басқа қатысушылардың беруі бөлек жүзеге асырылуы керек.

Тасымалдау әдісін таңдау әзірлеушінің жауапкершілігі болып табылады - кем дегенде қолмен. Қажетті деректер алмасылғаннан кейін RTTCMediaConnection медиа ағындарын автоматты түрде орнатады (мүмкіндігінше, әрине).

ұсыныс-жауап үлгісі

Мультимедиа ағындарын орнату және өзгерту үшін ұсыныс/жауап үлгісі (ұсыныс/жауап; RFC3264-те сипатталған) және SDP протоколы (Session Description Protocol) пайдаланылады. Оларды SIP протоколы да пайдаланады. Бұл модельде екі агент бөлінеді: Ұсынушы – жаңасын жасау немесе барын өзгерту үшін SDP сеансының сипаттамасын жасайтын адам (Offer SDP) және жауап беруші – басқа агенттен SDP сеансының сипаттамасын алатын және жауап беретін адам. оны өзінің сеанс сипаттамасымен (SDP жауабы). Сонымен бірге, спецификация агенттер арасында SDP тасымалдауға жауап беретін жоғары деңгейлі протоколды (мысалы, SIP немесе біздің жағдайдағыдай өзіндік веб-розеткалар) қажет етеді.

Екі RTTCMediaConnection арасында медиа ағындарын сәтті орнату үшін қандай деректерді беру керек:

• Қосылымды бастайтын бірінші тарап ол жіберуді бастағалы тұрған медиа ағынының ықтимал сипаттамаларын сипаттайтын SDP деректер құрылымын (SIP жүйесінде бірдей хаттама қолданылады) жіберетін Ұсынысты қалыптастырады. Бұл деректер блогы екінші қатысушыға берілуі керек. Екінші қатысушы өзінің SDP көмегімен Жауапты жасайды және оны біріншісіне жібереді.
• Бірінші және екінші қатысушылар ICE ықтимал кандидаттарын анықтау процедурасын орындайды, оның көмегімен екінші қатысушы оларға медиа ағынын тасымалдай алады. Үміткерлер анықталғандықтан, олар туралы ақпарат басқа қатысушыға берілуі керек.

Ұсынысты қалыптастыру

Ұсынысты қалыптастыру үшін бізге екі функция қажет. Біріншісі сәтті қалыптасқан жағдайда шақырылады. CreateOffer() әдісінің екінші параметрі оны орындау кезінде қате пайда болған жағдайда шақырылатын кері шақыру функциясы болып табылады (жергілікті ағын қол жетімді болған жағдайда).

Оған қоса, екі оқиға өңдегіші қажет: жаңа ICE кандидатын анықтау кезінде onicecandidate және алыс жақтан медиа ағынын қосу кезінде onaddstream. Файлымызға қайта оралайық. Элементтері бар жолдардан кейін HTML-ге қосыңыз тағы бір:

ұсыныс жасау

Және элементі бар жолдан кейін

Сондай-ақ, JavaScript кодының басында RTCPeerConnection үшін жаһандық айнымалыны жариялаймыз:

varpc1;

RTCPeerConnection конструкторын шақырған кезде STUN/TURN серверлерін көрсету керек. Қосымша мәліметтер алу үшін бүйірлік тақтаны қараңыз; барлық қатысушылар бір желіде болса, олар талап етілмейді.

var servers = null;

SDP ұсынысын қамтамасыз ету опциялары

var offerConstraints = ();

createOffer() әдісінің бірінші параметрі Ұсынысты сәтті қалыптастыру кезінде шақырылатын кері шақыру функциясы болып табылады

pc1_createOffer_success(төмендеу) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", азайту); pc1.setLocalDescription(төмен); // RTCPeerConnection арқылы жасалған параметрді орнатыңыз SDP setLocalDescription әдісін ұсыныңыз. // Алыс жақ жауап SDP жіберген кезде, оны setRemoteDescription әдісі арқылы орнату қажет болады // Екінші жағы іске асырылмайынша, ештеңе жасамаңыз // pc2_receivedOffer(desc); )

Екінші параметр - қате болған жағдайда шақырылатын кері шақыру функциясы

Функция pc1_createOffer_error(қате)( console.log("pc1_createOffer_success_error(): қате:", қате); )

Біз ICE кандидаттары анықталғандай өтетін кері шақыру функциясын жариялаймыз:

Функция pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Екінші жағы орындалмайынша ештеңе жасамаңыз // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Сондай-ақ алыс жақтан медиа ағынын қосуға арналған кері шақыру функциясы (болашақ үшін, өйткені бізде әзірге тек бір RTCPeerConnection бар):

pc1_onaddstream(оқиға) функциясы ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )

«CreateOffer» түймесін басқан кезде, RTCPeerConnection жасаңыз, onicecandidate және onaddstream әдістерін орнатыңыз және createOffer() әдісіне қоңырау шалу арқылы ұсыныс SDP құруды сұраңыз:

Функция createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // RTCPeerConnection жасау pc1.onicecandidate = pc1_onicecandidate; // ICE кандидаттарын өңдеу үшін кері шақыру функциясы pc1ddstreonaddstreona; /pc1.am; /pc1.am / Кері шақыру функциясы алыс жақтан медиа ағыны болған кезде шақырылады, ол әлі жоқ pc1.addStream(localStream); // Жергілікті медиа ағынын өткізіңіз (ол әлдеқашан қабылданған болса) pc1.createOffer(// Және шын мәнінде Ұсыныстың қалыптасуын сұраңыз pc1_createOffer_success , pc1_createOffer_error, offerConstraints); )

Файлды rtctest2.html деп сақтап, оны серверге қойып, оны браузерде ашып, оның жұмыс істеуі кезінде қандай деректер жасалатынын консольде көрейік. Бір ғана қатысушы болғандықтан екінші бейне әлі шықпайды. Еске сала кетейік, SDP медиа сеансы параметрлерінің сипаттамасы, қолжетімді кодектер, медиа ағындары және ICE кандидаттары осы қатысушыға қосылудың ықтимал нұсқалары болып табылады.

Жауап SDP қалыптастыру және ICE кандидаттарын алмасу

Ұсыныстың SDP және ICE үміткерлерінің әрқайсысы басқа тарапқа берілуі керек және оларды RTCPeerConnection қызметінен алғаннан кейін, Ұсыныстың SDP үшін setRemoteDescription әдістерін және алыс жақтан алынған әрбір ICE кандидаты үшін addIceCandidate әдістерін шақырыңыз; сол сияқты кері жағы Answer SDP және қашықтағы ICE кандидаттары үшін. Жауаптың SDP өзі Ұсынысқа ұқсас құрылады; айырмашылығы, createOffer әдісі емес, createAnswer әдісі шақырылады және осы RTCPeerConnection алдында setRemoteDescription әдісі қоңырау шалушыдан алынған Ұсыныс SDP жібереді.

HTML-ге тағы бір бейне элементін қосамыз:

Біріншісінің мәлімдемесі бойынша екінші RTCPeerConnection үшін жаһандық айнымалы:

Varpc2;

Ұсыныс және жауап SDP өңделуде

Жауап SDP қалыптастыру Ұсынысқа өте ұқсас. Жауап сәтті құрылған кезде шақырылатын кері шақыру функциясында Ұсыныс сияқты біз жергілікті сипаттаманы береміз және алынған SDP Жауабын бірінші қатысушыға береміз:

pc2_createAnswer_success(төмендеу) функциясы ( pc2.setLocalDescription(төмен); console.log("pc2_createAnswer_success()", түсіндірме.sdp); pc1.setRemoteDescription(төмендету); )

Жауапты жасау кезінде қате болған жағдайда шақырылатын кері шақыру функциясы Ұсынысқа толығымен ұқсас:

pc2_createAnswer_error(қате) функциясы ( console.log("pc2_createAnswer_error():", қате); )

Жауап SDP құру параметрлері:

Var answerConstraints = ( "міндетті": ( "OfferToReceiveAudio":шын, "OfferToReceiveVideo":шын ) );

Екінші қатысушы Ұсынысты алған кезде, RTCPeerConnection жасаңыз және Ұсыныс сияқты Жауапты жасаңыз:

pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", жою); // Бірінші pc2 сияқты екінші қатысушы үшін RTCPeerConnection нысанын жасаңыз = жаңа webkitRTCPeerConnection(серверлер); pc2.onicecandidate = //pc2; Setec2; оқиға өңдегіші ICE кандидаты pc2.onaddstream = pc_onaddstream; // Ағын пайда болғанда, оны HTML-ге қосыңыз

Ұсыныс SDP бірінші қатысушыдан екіншісіне көшіру үшін, мысалдың бір бөлігі ретінде pc1 функциясында түсініктемені алып тастаңыз. ұсыныс жасаутабысты() шақыру жолы:

Pc2_receivedOffer(төмендету);

ICE кандидаттарын өңдеуді жүзеге асыру үшін бірінші қатысушының pc1_onicecandidate() екінші қатысушысының ICE кандидатының дайындығы оқиғасының өңдеушісіне түсініктеме қалдырыңыз:

Pc2.addIceCandidate(жаңа RTCIceCandidate(event.candidate));

Екінші қатысушының ICE кандидатының дайындығы оқиғасын өңдеушісі біріншіге ұқсайды:

pc2_onicecandidate(оқиға) функциясы ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(жаңа RTCIceCandidate(event.candidate)); ) )

Бірінші қатысушыдан медиа ағынын қосуға арналған кері шақыру функциясы:

pc2_onaddstream(оқиға) функциясы ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )

Байланысты тоқтату

HTML тіліндегі тағы бір түймені қосамыз

трубканы қою

Және қосылымды аяқтайтын функция

btnHangupClick() функциясы ( // HTML элементтерінен жергілікті бейнені өшіру

Оны rtctest3.html деп сақтап, серверге қойып, браузерде ашайық. Бұл мысал бір шолғыш қойындысындағы екі RTCPeerConnections арасындағы екі жақты медиа ағынын жүзеге асырады. Қатысушылар арасында Ұсыныс және Жауап SDP, ICE кандидаттарымен және желі арқылы басқа ақпараттармен алмасуды ұйымдастыру үшін тікелей қоңырау шалудың орнына қандай да бір көлік түрін, біздің жағдайда веб-розеткаларды пайдалана отырып, қатысушылар арасында алмасуды жүзеге асыру қажет болады. процедуралар.

Экрандық хабар тарату

getUserMedia функциясымен экранды және келесі параметрлерді көрсету арқылы MediaStream ретінде ағынды түсіруге де болады:

Var mediaStreamConstraints = ( аудио: жалған, бейне: ( міндетті: ( chromeMediaSource: "экран" ), қосымша: ) );

Экранға сәтті қол жеткізу үшін бірнеше шарттар орындалуы керек:

• chrome://flags/,chrome://flags/ ішіндегі getUserMedia() ішіндегі скриншот жалауын қосу;
• бастапқы файлды HTTPS (SSL бастауы) арқылы жүктеп алу керек;
• аудио ағынды сұрауға болмайды;
• бір шолғыш қойындысында бірнеше сұраулар жасалмауы керек.

WebRTC кітапханалары

WebRTC әлі аяқталмағанымен, оған негізделген бірнеше кітапхана пайда болды. JsSIP Asterisk және Camalio сияқты SIP қосқыштарымен жұмыс істейтін браузерге негізделген бағдарламалық телефондарды жасауға арналған. PeerJS деректер алмасу үшін P2P желілерін құруды жеңілдетеді, ал Holla браузерлерден P2P байланысы үшін қажетті әзірлеу көлемін азайтады.

Node.js және socket.io

Желі арқылы екі RTCPeerConnections арасында SDP және ICE үміткерлерінің алмасуын ұйымдастыру үшін біз Node.js файлын socket.io модулімен пайдаланамыз.

Node.js соңғы тұрақты нұсқасын орнату (Debian/Ubuntu үшін) сипатталған

$ sudo apt-get орнату python-software-properties python g++ жасау $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get жаңарту $ sudo apt-get орнату nodejs

Басқалар үшін орнату ОЖсипатталған

Тексерейік:

$ echo "sys=require("util"); sys.puts("Сынақ хабары");" > nodetest1.js $ nodejs nodetest1.js

Npm (Node Package Manager) көмегімен socket.io және қосымша экспресс модулін орнатыңыз:

$ npm socket.io Express орнатыңыз

Сервер жағы үшін nodetest2.js файлын жасау арқылы оны тексерейік:

$ nano nodetest2.js var app = require("express")() , server = require("http").createServer(app) , io = require("socket.io").listen(server); server.listen(80); // 80 порты тегін болса app.get("/", функция (req, res) ( // Түбір бетіне қатынасу кезінде res.sendfile(__dirname + "/nodetest2.html"); // HTML файлын беріңіз ) ); io.sockets.on("қосылу", функция (розетка) ( // Қосылымда socket.emit("сервер оқиғасы", ( сәлем: "әлем" )); // хабарлама жіберу socket.on("клиент оқиғасы", функция (деректер) ( // және клиент console.log(data); )); ));

Клиент жағы үшін nodetest2.html:

$nano nodetest2.html

Серверді бастайық:

$ sudo nodejs nodetest2.js

және браузерде http://localhost:80 бетін ашыңыз (егер 80-ші портта жергілікті түрде жұмыс істейтін болса). Егер бәрі сәтті болса, браузердің JavaScript консолінде қосылу кезінде браузер мен сервер арасындағы оқиғалардың алмасуын көреміз.

RTCPeerConnection арасында веб-розеткалар арқылы ақпарат алмасу

Клиент жағы

Негізгі мысалды (rtcdemo3.html) rtcdemo4.html жаңа атауымен сақтайық. Элементке socket.io кітапханасын қосыңыз:

Ал JavaScript сценарийінің басында - веб-розетка қосылымы:

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

Басқа қатысушының функцияларына тікелей қоңырауды оған веб-розеткалар арқылы хабарлама жіберу арқылы ауыстырайық:

CreateOffer_success(төмендеу) функциясы ( ... // pc2_receivedOffer(төмен); socket.emit("ұсыныс", азайту); ... ) функциясы pc2_createAnswer_success(төмендету) ( ... // pc1.setRemoteDescription(төмен); socket .emit("жауап", түсіндіру); ) функциясы pc1_onicecandidate(оқиға) ( ... // pc2.addIceCandidate(жаңа RTCIceCandidate(оқиға.кандидат)); socket.emit("ice1", оқиға.кандидат); .. . ) функциясы pc2_onicecandidate(оқиға) ( ... // pc1.addIceCandidate(жаңа RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )

hangup() функциясында екінші қатысушының функцияларын тікелей шақырудың орнына веб-розеткалар арқылы хабарлама жібереміз:

btnHangupClick() функциясы ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", ()); )

Хабарламаларды қабылдау өңдеушілерін қосыңыз:

Socket.on("ұсыныс", функция (деректер) ( console.log("socket.on("ұсыныс"):", деректер); pc2_receivedOffer(деректер); )); socket.on("жауап", функция (деректер) (e console.log("socket.on("жауап"):", деректер); pc1.setRemoteDescription(жаңа RTCSessionDescription(деректер)); )); socket.on("ice1", функция (деректер) ( console.log("socket.on("ice1"):", деректер); pc2.addIceCandidate(жаңа RTCIceCandidate(деректер)); )); socket.on("ice2", функция (деректер) ( console.log("socket.on("ice2"):", деректер); pc1.addIceCandidate(жаңа RTCIceCandidate(деректер)); )); socket.on("қосу", функция (деректер) ( console.log("socket.on("hangup")):", деректер); remoteVideo2.src = ""; pc2.close(); pc2 = null; ));

Сервер бөлігі

Сервер жағында nodetest2 файлын rtctest4.js жаңа атауымен және io.sockets.on("қосылу", функция (сокет) ( ... ) функциясының ішінде клиенттік хабарламаларды қабылдау және жіберуді қосыңыз:

Socket.on("ұсыныс", функция (деректер) ( // "Ұсыныс" хабарын алған кезде, // бұл мысалда бір ғана клиент қосылымы болғандықтан, // хабарламаны сол socket.emit( ​​арқылы қайта жіберіңіз. "offer" , data); // Егер хабарды жіберушіден басқа барлық қосылымдарға жіберу қажет болса //: // socket.broadcast.emit("ұсыныс", деректер); )); socket.on("жауап", функция (деректер) ( socket.emit("жауап", деректер); )); socket.on("ice1", функция (деректер) ( socket.emit("ice1", деректер); )); socket.on("ice2", функция (деректер) ( socket.emit("ice2", деректер); )); socket.on("қосу", функция (деректер) ( socket.emit("қосу", деректер); ));

Сонымен қатар, HTML файлының атын өзгертіңіз:

// res.sendfile(__dirname + "/nodetest2.html"); // HTML файлын жіберу res.sendfile(__dirname + "/rtctest4.html");

Сервердің іске қосылуы:

$ sudo nodejs nodetest2.js

Екі клиенттің коды бір шолғыш қойындысында жұмыс істейтініне қарамастан, біздің мысалдағы қатысушылар арасындағы барлық өзара әрекеттесу толығымен желі арқылы жүзеге асырылады және енді қатысушыларды «тарату» қиын емес. Дегенмен, біз жасаған нәрсе де өте қарапайым болды - бұл технологиялар оларды пайдаланудың қарапайымдылығы үшін жақсы. Кейде алдамшы болса да. Атап айтқанда, STUN/TURN серверлері болмаса, мекенжай аудармасы мен брандмауэр болған жағдайда біздің мысал жұмыс істей алмайтынын ұмытпайық.

Қорытынды

Алынған мысал өте шартты, бірақ егер оқиға өңдегіштерін шақырушы және шақырылатын тараптар арасында айырмашылығы болмайтындай етіп сәл әмбебаптандырсақ, екі нысанның орнына pc1 және pc2, RTCPeerConnection массивін жасаңыз және іске қосыңыз. динамикалық құружәне элементтерді жою

Жақында WebRTC арқасында дауыстық және бейне коммуникациялар туралы түсінігімізде ғана емес, сонымен бірге Интернетті тұтастай қабылдауда да революция болады деп болжауға болады. WebRTC браузерден шолғышқа қоңырау шалу технологиясы ретінде ғана емес, сонымен қатар нақты уақыттағы байланыс технологиясы ретінде де орналастырылған. Біз талдаған бейне сілтемесі оның кішкене бөлігі ғана. опциялароның қолданылуы. Экранды ортақ пайдалану (экранды ортақ пайдалану) және бірлесіп жұмыс істеу мысалдары, тіпті RTCDataChannel арқылы браузерге негізделген P2P мазмұнды жеткізу желісі қазірдің өзінде бар.