WebRTC. Tarayıcıda video konferans. Tarayıcı kamerası. Skype, WebRTC programları oluşturma talimatları - Web sitesi "At the Extreme". BT - Hangi tarayıcıların WebRTC ile çalıştığını bildirin

WebRTC (Web Gerçek Zamanlı İletişim), eklentiler veya diğer uzantılar yüklenmeden ses, video ve içerik akışının tarayıcıdan gerçek zamanlı olarak tarayıcıya iletilmesini tanımlayan bir standarttır. Standart, tarayıcıyı video konferansın uç terminaline geçirmenize ve indirmeyi yazdırmak için web sayfasını açmanıza olanak tanır.

WebRTC nedir?

Bu makale, ortalama bir tüketicinin WebRTC teknolojisi hakkında bilmesi gereken her şeyi kapsayacaktır. Projenin avantajlarına ve dezavantajlarına bakalım, bazı sırları açığa çıkaralım ve WebRTC'nin nerede ve neden geliştirildiğini anlayalım.

WebRTC hakkında bilmeniz gerekenler nelerdir?

Video iletişim standartlarının ve teknolojilerinin gelişimi

Sergiy Yutsaytis, Cisco, Video+Konferans 2016

WebRTC nasıl çalışır?

İstemci tarafında

  • Koristuvach, HTML5 etiketini eklemek için sayfayı açar
  • Tarayıcı, kullanıcının web kamerasına ve mikrofonuna erişim ister.
  • İstemcinin web sitesindeki JavaScript kodu, NAT ve Güvenlik Duvarını atlamak için bağlantı parametrelerini (WebRTC sunucusunun veya diğer WebRTC istemcilerinin IP adresleri ve bağlantı noktaları) kontrol eder.
  • Sunucuda barındırılan konferanstan tarayıcı veya akış hakkındaki bilgileri kaldırdığınızda, tarayıcı seçilen ses ve video codec bileşenlerini kabul etmeye başlar.
  • WebRTC istemcileri arasında (bizim durumumuzda, tarayıcı ile sunucu arasında) akış verilerinin kodlanması ve aktarılması süreci başlar.

WebRTC sunucusu tarafında

İki katılımcı arasında veri alışverişi yapmak için bir video sunucusuna gerek yoktur; birden fazla katılımcıyı bir konferansta birleştirmeniz gerekmediği sürece bir sunucu gerekir.



Video sunucusu, tıpkı WebRTC kullanan bir terminal gibi, çeşitli cihazlardan medya trafiğini alır, dönüştürür ve kullanıcılar için güçlendirir.

WebRTC sunucusu aynı zamanda WebRTC ziyafetlerinden gelen medya trafiğini de yakalar ve bunu vikorist programları gibi konferans katılımcılarına iletir. masaüstü bilgisayarlar ya da başka mobil cihazlar, böyle şeylerin bariz olduğu zamanlar vardır.

Standardın avantajları

  • PZ kurulumuna gerek yoktur.
  • Bağlantının acısı çok yüksek:
    • Güncel videoları (VP8, H.264) ve ses kodeklerini (Opus) arayın.
    • Zihin akışının otomatik olarak ayarlanması.
    • Gürültü azaltma sistemi getirildi.
    • Katılımcıların mikrofonlarının hassasiyet seviyesinin (ARS) otomatik olarak ayarlanması.
  • Yüksek düzeyde güvenlik: Tüm iletişimler TLS ve SRTP protokolleri kullanılarak korunur ve şifrelenir.
  • İçeriği örneğin bir masaüstünde depolamak için bir mekanizma vardır.
  • HTML5 ve JavaScript'e dayalı her türlü çekirdek arayüzünü uygulama imkanı.
  • Arayüzü WebSockets kullanarak herhangi bir arka uç sistemle entegre etme yeteneği.
  • Project iz vikriti çıkış kodu- Ürün veya hizmetinizi tanıtabilirsiniz.
  • Faydalı çapraz platform: tek ve aynı WebRTC eklentisi ne olursa olsun iyi çalışacaktır işletim sistemi, masaüstü ve mobil, çünkü tarayıcı WebRTC'yi destekliyor. Yazılım geliştirmek için kaynaklardan tasarruf etmek önemlidir.

Standart için yeterli değil

  • Grup sesli ve görüntülü konferansları düzenlemek için, katılımcılardan gelen görüntü ve sesi karıştıran bir video konferans sunucusu gereklidir, çünkü Tarayıcı bir dizi giriş akışını birbiriyle senkronize edemiyor.
  • Tüm WebRTC çözümleri kendi aralarında saçmadır çünkü... Standart, yalnızca video ve ses aktarma yöntemlerini değil, aynı zamanda satıcıya kadar abonelere hitap etme, kullanılabilirliklerini artırma, ilgili dosyaların paylaşılması, planlama vb. yöntemlerin uygulanması anlamına da gelir.
  • Yani bir distribütörün WebRTC programlarını başka bir distribütörün WebRTC uygulamalarına aktaramayacaksınız.
  • Grup konferanslarını karıştırmak büyük mali kaynaklar gerektirir, dolayısıyla bu tür görüntülü iletişim satın alma gerektirir ödenen avans Veya her konferansın günlük bir işlemcinin 1 fiziksel çekirdeğini gerektirdiği kendi altyapınıza yatırım yapın.

WebRTC'nin Sırları: Satıcılar yıkıcı web teknolojisinin maliyetini nasıl ortadan kaldırabilir?


Tsachi Levent-Levi, Bloggeek.me, Video+Konferans 2015

Pazar video konferansı için WebRTC

Artan video konferans terminali sayısı

WebRTC teknolojisi video konferans pazarının gelişmesine katkıda bulunmuştur. 2013 yılında WebRTC desteğiyle ilk tarayıcıların ortaya çıkmasından sonra dünya genelinde video konferans terminallerinin sayısı 1 milyar cihaz kadar dramatik bir şekilde arttı. Temelde dış görünüm tarayıcısı, bağlantı kalitesi açısından donanım benzerlerinden ödün vermeyen bir video konferans terminali haline geldi.

Özel çözümler arayın

Çeşitli JavaScript kitaplıklarının ve karanlık hizmet API'lerinin WebRTC desteğiyle birleşimi, herhangi bir web projesine kolayca video desteği eklemenizi sağlar. Daha önce, verileri gerçek zamanlı olarak iletmek için distribütörlerin robotik protokollerin ilkelerini öğrenmesi ve diğer şirketlerin uygulamalarını kullanması gerekiyordu; bu da genellikle ek lisanslama gerektiriyordu ve bu da maliyetleri artırıyordu. WebRTC artık "Siteyi arama", "Çevrimiçi sohbet desteği" vb. hizmetlerde aktif olarak tanıtılıyor.

Eski Koristuvacham Linux için Skype

2014 yılında Microsoft, BT çalışanları arasında büyük hayal kırıklığına neden olan Linux için Skype projesine destek verdiğini duyurdu. WebRTC teknolojisi işletim sistemine bağlı değildir, yalnızca tarayıcı düzeyinde uygulanır. Linux geliştiricileri WebRTC tabanlı ürün ve hizmetlerle Skype'ın tam yerini alabilirsiniz.

Flash ile Rekabet

WebRTC ve HTML5, halihazırda ayakta kalmış olan Flash teknolojisine ölümcül bir darbe oldu. en güzel kayalar. 2017'den bu yana kablolu tarayıcılar resmi olarak Flash'ı desteklemeyi bıraktı ve teknoloji piyasada kaldı. Ancak web konferansı için bir pazar yaratarak ve tarayıcılarda canlı yayın için teknik yetenekleri oluşturarak bile Flash'ı daha verimli bir şekilde tanıtmak gerekiyor.

Video sunumları WebRTC

Dmitro Odintsov, TrueConf, Video+Konferans Zhovten 2017

WebRTC kodekleri

Ses kodekleri

WebRTC ses trafiğini sıkıştırmak için Opus ve G.711 codec'leri kullanılır.

G.711- çoğunlukla sistemlerde sıkışıp kalan, yüksek bit hızına (64 kbps) sahip en eski ses codec'i geleneksel telefon. Başlıca avantajı, hafif sıkıştırma algoritmalarının kullanımı yoluyla minimum hesaplama kazancıdır. Codec değişiyor düşük seviye Ses sinyallerinin sıkıştırılması ve hoparlörler arasında miksaj sırasında sese ilave gürültü getirmemesi.

G.711 çok sayıda cihaz tarafından desteklenmektedir. Bu codec bileşenini kullanan sistemler, diğer ses codec bileşenlerinde (G.723, G.726, G.728 vb.) çalışan sistemlere göre daha kolay kurulur. G.711 kutusu için test edilen MOS'tan 4,2 puan alınması (4-5 arası puan en yüksek puandır ve garna yakist, ses trafiğinin ISDN ve ötesine iletim hızına benzer).

başyapıt- Bu codec bileşeni düşük kodlama gecikmesine sahiptir (2,5 ms'den 60 ms'ye kadar), değişken bit hızını destekler ve yüksek seviye Bant genişliğinin değişken olduğu bir zamanda ses akışının iletilmesi için ideal olan sıkıştırma. Opus, şunları birleştiren hibrit bir çözümdür: en iyi özellikler codec bileşenleri SILK (ses sıkıştırma, insan konuşmasını bastırma) ve CELT (ses kodlama). Codec halka açıktır ve bu konuda başarılı olan yayıncıların yasal ücret ödemesine gerek yoktur. Diğer ses codec'leriyle karşılaştırıldığında Opus, performans zenginliğiyle kesinlikle kazanıyor. MP3, Vorbis, AAC LC gibi düşük bit hızına sahip popüler codec bileşenlerini indirebilirsiniz. Opus, ses görüntüsünü orijinaline AMR-WB ve Speex'ten daha yakın hale getirir. Bu codec bileşeni yakında kullanıma sunulacak ve WebRTC teknolojisinin yaratıcıları bunu takip ettikleri kapsamlı ses standartları yelpazesine dahil etti.

Video codec bileşenleri

WebRTC için video kodlayıcı seçimi bir dizi perakendeciden alındı ​​ve sonuç H.264 ve VP8 oldu. Neredeyse her şey mevcut tarayıcılar rahatsız edici codec bileşenlerini destekleyin. Video konferans sunucularının WebRTC ile çalışabilmesi için yalnızca bir tanesini desteklemesi yeterlidir.

VP8- video akışının yüksek hızda kod çözülmesini ve kare israfından önce artırılmış kararlılığı sunan, açık lisansa sahip yüksek kaliteli bir video codec bileşeni. Codec evrenseldir, donanım platformlarında uygulanması kolaydır, bu nedenle video konferans sistemi satıcıları bunu genellikle ürünlerinde kullanır.

Ücretli video codec'i H.264 silah arkadaşıyla çok daha erken evlenmişti. Bu codec bileşeni, kaydederken video akışının yüksek derecede sıkıştırılmasına sahiptir yüksek kuvvet video. Bu codec bileşeninin donanım video konferans sistemleri arasındaki yüksek genişliği, video çağrılarını WebRTC standardı üzerinden iletir.

Google ve Mozilla aktif olarak VP8 codec bileşenini tanıtıyor ve Microsoft, Apple ve Cisco H.264'ü destekliyor (geleneksel video konferans sistemleriyle uyumluluğu sağlamak için). Ve burada karanlık WebRTC çözümünün geliştiricileri için çok büyük bir sorun ortaya çıkıyor ve eğer konferansta tüm katılımcılar bir tarayıcı kullanıyorsa, o zaman konferansın bir kez bir codec bileşeniyle karıştırılması gerekir ve eğer tarayıcılar aralarında farklıysa, Safari / Edge, o zaman konferans iki kez farklı codec'lerle gerçekleşiyor ve bunların iki kez taşınması gerekiyor sistem faydaları medya sunucusuna ve bunun sonucunda WebRTC hizmetine olan aboneliklerin sayısı.

WebRTC API'si

WebRTC teknolojisi üç ana API'ye dayanmaktadır:

  • (bir web tarayıcısının kameralardan veya operatörün masaüstünden ses ve video sinyalleri aldığını gösterir).
  • RTCPeer Bağlantısı(kamera, mikrofon ve masaüstü verilerinin, medya verilerinin "alışverişi" için tarayıcılar arasındaki bağlantıyı belirtir. Ayrıca, bu API'nin "taahhütleri" arasında sinyal işleme (üçüncü taraf gürültüsünün temizlenmesi, mikrofonun ve ses kontrolünün ayarlanması ve vikory araştırmasına tabi olan video codec bileşenleri).
  • RTCVeri Kanalı(kurulu bağlantı üzerinden iki yönlü veri aktarımını sağlar).

Öncelikle kullanıcının mikrofonuna ve kamerasına erişimini reddedersiniz, tarayıcı sizden buna izin vermenizi isteyecektir. sen Google Chrome Erişimi daha sonra "Ayarlar" bölümünden ayarlayabilirsiniz; Opera ve Firefox'ta, listeden erişimi iptal ettiğiniz anda cihaz seçimi hemen yapılabilir. İzin isteği, HTTP protokolünü kullanırken her zaman ve HTTPS kullanıyorsanız bir kez görünecektir:


RTCPeer Bağlantısı. WebRTC konferansına katılan tarayıcı, o nesneye erişiminden sorumludur. RTCPeerConnection ile medya bir tarayıcıdan diğerine NAT ve kenar ekranları aracılığıyla yönlendirilebilir. Medya akışlarının başarılı bir şekilde iletilmesi için katılımcıların bu tür verileri web soketleri gibi ek aktarım kullanarak alışverişi yapması gerekir:

  • başlatan katılımcı başka bir katılımcıya bir Teklif-SDP (iletilen medya akışının özelliklerini içeren veri yapısı) gönderir;
  • başka bir katılımcı bir "onay" - Cevap-SDP oluşturur ve bunu başlatıcıya iletir;
  • Daha sonra, tespit edilmesi halinde (katılımcılar NAT veya sınır ekranlarının arkasındaysa) katılımcılar arasında ICE aday değişimi düzenlenir.

Katılımcılar arasındaki alışverişin başarıyla tamamlanmasının ardından medya akışlarının (ses ve video) anında aktarımı organize edilir.

RTCVeri Kanalı. Son zamanlarda tarayıcılarda Veri Kanalı protokolü desteği ortaya çıktı, bu nedenle bu API, tarayıcılardaki WebRTC wiki'sinde kapsamlı olarak görüntülenebilir Mozilla Firefox 22+ ve Google Chrome 26+. Ek yardım için katılımcılar tarayıcıda metin bildirimleri gönderebilirler.

WebRTC aracılığıyla bağlantılar

Desteklenen masaüstü tarayıcılar

  • Google Chrome (17+) ve Chromium motorunu temel alan tüm tarayıcılar;
  • Mozilla FireFox (18+);
  • Opera (12+);
  • Safari (11+);

Android için desteklenen mobil tarayıcılar

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

WebRTC, Microsoft ve Internet Explorer

Microsoft uzun süredir WebRTC destek sürücüsünden tasarruf ediyor. İnternet Explorer ve yeni Edge tarayıcınızda. Redmondlu çocuklar artık teknolojiyi kontrol edemedikleri için şirket sahiplerinin eline bırakmaktan hoşlanmıyorlar, bu politikanın eksenini oluşturuyor. Ale adım adım sağa doğru tam merkezden yok edildi, çünkü. Artık WebRTC'yi göz ardı etmek mümkün değil ve WebRTC standardına benzer ORTC projesi açıklandı.

ORTC distribütörlerinin ifadesiyle bu, WebRTC standardının azaltılmış API seti ile bir uzantısıdır. JavaScript'in temelleri Ve İngilizceye çevrilen HTML5, her şeyin aynı olacağı, standardı ve geliştirmelerini Google'ın değil yalnızca Microsoft'un kontrol edeceği anlamına geliyor. Codec seti, H.264'ü ve telefon ve donanım video konferans sistemlerinde kullanılan G.7XX serisinin çeşitli ses codec'lerini destekleyecek şekilde genişletildi. RDP desteği (içerik aktarımı için) ve mesaj alışverişi sağlamak mümkündür. Konuşmadan önce, Internet Explorer koristuvach'lara nazik davranmadı, ORTC desteği Edge'den mahrum kalacak. Doğal olarak, böyle bir protokol ve codec kümesinin Skype Kurumsal ile çok az bağlantısı var ve bu da WebRTC için daha da fazla iş durgunluğu yaratıyor.

WebRTC, bir tarayıcı aracılığıyla gerçek zamanlı ses/görüntü iletişimleri uygulamanıza olanak tanır

Bu başlıkta en basit WebRTC eklentisinin nasıl uygulanacağını kullanacağım.

1. getUserMedia - medya aygıtlarına (mikrofon/web kamerası) erişim sağlama

Karmaşık bir şey yok, 10 satırlık javascript kodunun yardımıyla bunu neredeyse tarayıcınızda yapabilirsiniz (demo).

index.html oluştur :

Video öğesine bir css3 filtresi ekleyebilirsiniz.

Burada kafası karışanlar, WebRTC geliştirmenin bu aşamasında tarayıcıya “Hangi siteye güveniyorum, her zaman kamerama ve mikrofonuma erişim izni ver” diyemediğim ve dış görünümü açtıktan/sayfayı yeniledikten sonra İzin Ver tuşuna basmam gerektiği.

PERMISSION_DENIED, "Erişimi reddetmeye çalıştığınızda bir tarayıcıda, diğerinde kameraya erişim verip vermediğinizi size söylemeyeceğiz" diyor.

2. Sinyal sunucusu

Burada, "webrtc'ye başlarken" talimatlarının çoğunun tutarlılığını bozuyorum çünkü bunlar, webRTC'nin bir istemci üzerindeki yeteneklerini başka bir şekilde gösteriyorlar ki, bunu açıklığa kavuşturmak özellikle daha az gerekli.

Sinyal sunucusu, istemciler arasındaki iletişimi, bağlantıların başlatılmasını ve kapatılmasını ve dayaklarla ilgili bildirimleri sağlayan WebRTC'nin koordinasyon merkezidir.

Sinyal sunucumuz Node.js+socket.io+node-static'tir ve 1234 numaralı bağlantı noktasını dinleyecektir.
Ayrıca, düğüm statik olan her şeye index.html ekleyebilirsiniz; bu, ekimizi oluşturmayı mümkün olduğunca basit hale getirecektir.

Babamın programlarının yüklenmesi gerekiyor:

Npm kurulum soketi.io npm kurulum düğümü statik

WebRTC(Web Gerçek Zamanlı İletişim), Web eklentilerinin ve sitelerinin ses ve/veya video medya akışlarını sorunsuz bir şekilde iletmesine ve ayrıca aracılarla uğraşmadan tarayıcılar arasında ek veri alışverişi yapmasına olanak tanıyan bir teknolojidir. WebRTC teknolojisi de dahil olmak üzere bir dizi standart, eklentiler veya diğer üçüncü taraf yazılımları yüklemeye gerek kalmadan veri alışverişinde bulunmanıza ve eşler arası telekonferanslar gerçekleştirmenize olanak tanır.

WebRTC, aynı anda çalışan birçok birbirine bağımlı uygulama programı arayüzünden (API) ve protokolden oluşur. Bulacağınız belgeler WebRTC'nin temellerini, veri aktarımı, medya akışı ve çok daha fazlası için bağlantıları nasıl kurup yapılandıracağınızı anlamanıza yardımcı olacaktır.

Delilik

WebRTC'nin uygulanması geliştirme aşamasında olduğundan ve tarayıcınız WebRTC işlevselliğine sahip olduğundan, kodunuz üzerinde çalışmaya başlamadan önce Google'ın Adapter.js çoklu dosya kitaplığını kullanmanız önerilir.

Adapter.js, WebRTC uygulamalarındaki özelliklerin kendisini destekleyen bağlamlar arasında sorunsuz bir şekilde entegre edilmesi için çeşitli takozlar ve çoklu dolgular sağlar. Adapter.js ayrıca oluşturucu öneklerini ve diğer adlandırma yetkilerini ekleyerek WebRTC'deki geliştirme sürecini basitleştirerek en iyi sonuçları verir. Kütüphane ayrıca bir NPM paketi olarak da mevcuttur.

Adapter.js kütüphanesinin daha da geliştirilmesine hayret ediyoruz.

WebRTC wiki'nin

WebRTC'nin birçok amacı vardır ve aynı zamanda DTMF ton desteği de dahil olmak üzere eski telefon sistemleriyle sesli ve görüntülü konferans desteği, dosya paylaşımı, ekran paylaşımı, kimlik doğrulama ve birlikte çalışabilirlik dahil olmak üzere Web için güçlü multimedya yetenekleri sağlar. Düğümler arasındaki bağlantılar, özel sürücülere veya eklentilere ihtiyaç duyulmadan ve çoğu zaman ara hizmetler olmadan oluşturulabilir.

İki düğüm arasındaki bağlantı, RTCPeerConnection arayüzüne yönelik bir nesne olarak temsil edilir. Bağlantı açık olarak kurulduğu sürece bağlantıya RTCPeerConnection vikory nesnesi, MediaStream s ve/veya veri kanalları (RTCDataChannel s) eklenebilir.

Medya akışları herhangi bir sayıda medya parçasından oluşabilir. Bu parçalar MediaStreamTrack arayüzündeki nesnelerle temsil edilir ve ses, video, metin (altyazılar veya bölüm başlıkları gibi) dahil olmak üzere bir veya daha fazla medya türünü içerebilir. Çoğu akış, en azından yalnızca bir ses parçasından (bir ses parçası) veya video parçalarından oluşturulur ve akışlar (belirli bir zamandaki medya) veya kaydedilmiş u dosyası gibi gönderilebilir ve kaldırılabilir.

Servis bilgilerinin iletilmesi, veri alışverişi ve paketlerin, oyun durumlarının, dosya aktarımının veya kapalı veri aktarım kanallarının iletilmesi için kullanılabilen RTCDataChannel arayüz nesnesini kullanarak iki düğüm arasında veri alışverişi yapmak üzere bir bağlantı oluşturmak da mümkündür.

daha fazla ayrıntı ve gerekli ilgili kılavuzlara ve öğreticilere bağlantılar

WebRTC arayüzleri

WebRTC'nin çeşitli görevlerin yerine getirilmesi için sorunsuz bir şekilde çalışan arayüzler sağlaması sayesinde bunları kategorilere ayırdık. Gezinme çubuğunun alfabetik göstergesine bakın.

Bağlantı ve keruvannya'nın ayarlanması

Bu arayüzler WebRTC bağlantılarıyla yapılandırma, destek ve ağ oluşturma için seçilir. İki yönlü multimedya mükemmel bağlantısını kurarken en iyi yapılandırmayı seçmek için bir dış görünüm düğümünün potansiyeli hakkında bilgi alışverişinde bulunurken kullanılan eşler arası medya bağlantılarını, veri kanallarını ve arayüzleri temsil ederler.

RTCPeerConnection WebRTC bağlantısını temsil eder. yerel bilgisayar ve uzak bir düğümde. Vikoryst, iki düğüm arasında başarılı bir aktarımı gerçekleştirmek için kullanılır. RTSessionDescription Oturum parametrelerini belirtir. RTSessionDescription kodu, anlaşma sürecinin her bir bölümünü (teklif/konuşma) gösteren türün bir açıklamasını içerir ve oturumun SDP tanımlayıcısını açıklar. RTCIceCandidate, RTCPeerConnection bağlantısını kurmaya yönelik İnternet bağlantısı kurulum (ICE) sunucusu adayıdır. RTCIceTransport İnternet bağlantınız (ICE) hakkında bilgi sağlar. RTCPeerConnectionIceEvent RTCPeerConnection adı verilen ICE adayları için seçilen olayları temsil eder. Bu bölme nesnesine bir tür iletilir: icecandidate. RTCRtpSender, RTCPeerConnection türündeki bir nesne için MediaStreamTrack türündeki bir nesne aracılığıyla verilerin dönüştürülmesini ve iletilmesini yönetir. RTCRtpReceiver RTCPeerConnection türündeki bir nesne için MediaStreamTrack türündeki bir nesne aracılığıyla verileri alır ve kodunu çözer. RTCTrackEvent MediaStreamTrack türünde yeni bir giriş nesnesinin oluşturulduğunu ve RTCRtpReceiver türünde bir nesnenin RTCPeerConnection nesnesine eklendiğini belirtir. RTCCertificate RTCPeerConnection nesnesini temsil eden sertifikayı temsil eder. RTCDataChannel İki iletişim düğümü arasındaki çift yönlü bir veri kanalını temsil eder. RTCDataChannelEvent RTCDataChannel türündeki bir nesne RTCPeerConnection datachannel türündeki bir nesneye eklendiğinde ortaya çıkan olayları temsil eder. RTCDTMFSender RTCPeerConnection türündeki bir nesne için çift tonlu çoklu frekans (DTMF) sinyalini kodlar ve iletir. RTCDTMFToneChangeEvent Çift Tonlu Çoklu Frekans (DTMF) ton değiştirme girişini gösterir. Bu ürün boşaltmaz (aksi belirtilmedikçe) veya dokunmaz (aksi belirtilmedikçe). RTCStatsReport Aktarılan nesnenin durumunu eşzamansız olarak MediaStreamTrack türüne bildirir. RTCIdentityProviderRegistrar Bir kimlik sağlayıcıyı (idP) kaydeder. RTCIdentityProvider Tarayıcının, tanımlanmış bir kimliğin oluşturulmasını veya doğrulanmasını isteme yeteneğini etkinleştirir. RTCIdentityAssertion Uzak akış düğümünün tanımlayıcısını belirtir. Eğer üniversite henüz kurulup onaylanmadıysa arayüze gönderilen mesaj null olur. Kurulduktan sonra değiştirilemez. RTCIdentityEvent Bir kimlik sağlayıcı (idP) tanımlayıcı nesnesini temsil eder. RTCPeerConnection nesne türüne benzer. Bu alt kimlik sonucuna bir tür iletilir. RTCIdentityErrorEvent Bir kimlik sağlayıcıyla (idP) ilişkili bir hata olayını temsil eder. RTCPeerConnection nesne türüne benzer. Bu yöntemle iki tür hata iletilir: idpassertionerror ve idpvalidationerror.

Kerivnytstva

WebRTC mimarisine genel bakış Geliştiricilerin WebRTC oluşturmak ve geliştirmek, bir dizi ağ protokolü ve bağlantı standardı geliştirmek için kullanacağı API. Bu görünüm bu standartların bir vitrinidir. WebRTC, tarayıcıda ek veri, ses, video akışları veya bunların herhangi bir kombinasyonunu iletmek için ana bilgisayardan ana bilgisayara modunda bir bağlantı düzenlemenize olanak tanır. Bu yazıda, bir WebRTC oturumunun, bağlantının kurulmasından başlayıp, artık ihtiyaç duyulmadığı tamamlanıncaya kadar tüm süreci ele alacağız. WebRTC API'sine Genel Bakış WebRTC, iki veya daha fazla düğüm arasında veri ve medya akışı alışverişini desteklemek için birlikte çalışan birçok birbirine bağımlı uygulama programı arayüzünden (API) ve protokolden oluşur. Bu makale şunları sunar: kısa bakış kutanöz API ve yaku meta vin yeniden inceleniyor. WebRTC Temelleri Bu makale, tarayıcılar arası RTC programlarının oluşturulmasında size yol gösterecektir. Bu yazının sonuna kadar çalışma tarihi noktadan noktaya modda çalışan medya kanalıdır. WebRTC protokolleri Bu makale, WebRTC API'sinin oluşturulduğu protokollere ek olarak oluşturulmuştur. Bu el kitabı vuzol-vuzol ve örgü birleşimini nasıl vikorist edebileceğinizi anlatıyor

Üzerindeki malzemenin çoğu WebRTC Kod yazımı uygulanan seviye ile sınırlıdır ve modern teknolojiye uygun değildir. Daha derine inmeye çalışalım ve nasıl onay alınacağını, oturumun tanımlayıcısının ne olduğunu ve ihtiyacınız olan adayları öğrenelim. Sersemletmeі DÖNÜŞ sunucu.

WebRTC

Girmek

WebRTC, video veri aktarımı için iki istemciyi birbirine bağlamanıza olanak tanıyan tarayıcı odaklı bir teknolojidir. Ana özellikler tarayıcılar için dahili destektir (üçüncü taraf teknolojileri gerekmez; Adobe Flash ) ek veri sunucularına ihtiyaç duymadan istemcileri bağlama yeteneği – bağlantı Eşler arası(Dali, p2p).

Bağlantıyı yükle p2p- Önemli görevi tamamlamak için bilgisayar parçaları asla halka açıklanmayacak IP adresler veya internetteki adresler. Kısa bir süre sonra IPv4 adres (ve güvenlik amacıyla) bu bölme mekanizması NAT, örneğin ev wiki'leri için özel sınırlar oluşturmanıza olanak tanır. Artık desteklenecek çok sayıda ev yönlendiricisi var NAT Ve bu nedenle, İnternet sağlayıcıları bir tane sağlamakta ısrar etse de, tüm ev cihazları İnternet'e erişebilir. IP adres. Halk IP adresler internette benzersizdir ancak özel değildir. Hadi birlikte olalım p2p- Zor.

Bunu daha net anlayabilmek için üç duruma bakalım: Düğümlerin aynı boyutta olmasından kırgınlık (Malyunok1) suç düğümleri farklı katmanlarda bulunur (biri özel, diğeri genel için) (Malyunok2) kırgınlık vuzley'in çeşitli özel ölçülerde bilindiği ancak IP adresler (Malyunok3).

Malyunok 1: Bir açıdan çok rahatsız edici

Malyunok 2: Farklı seviyelerde Vuzli (biri özel, diğeri halka açık)

Şekil 3: Farklı özel sınırlarda bulunan ancak sayısal olarak eşit adreslere sahip Vuzley

Şekillerde iki karakterli tanımlamanın ilk harfi düğüm tipini göstermektedir (p = akran, r = yönlendirici). İlk bakışta durum olumlu: kenarlarındaki düğümler genellikle kenar olarak tanımlanıyor IP adreslerdir ve bu sayede herhangi bir ortası olmadan birbirlerine bağlanabilirler. Diğer küçükte ise düğümlerin benzer numaralandırıldığını gösteren iki farklı çizgi var. Burada, biri kenarın ortasında, diğeri kenarda olmak üzere iki kenar arayüzüne sahip yönlendiriciler bulunmaktadır. Bu yüzden iki tane var IP adres. Birincil düğümlerin yalnızca tek bir arayüzü vardır ve bu arayüz sayesinde kenarlarında birikebilirler. Eğer birisine kendi yöntemleriyle haraç ulaştırırlarsa yardım isteyin. NAT yönlendiricinin (yönlendiricinin) ortasındadır ve bu nedenle diğer kişiler tarafından görülebilir IP yönlendirici adresi – tse їх harici IP adres. Bu şekilde bilya vuzla p1є dahili IP = 192.168.0.200 і harici IP = 10.50.200.5 ve adres sınırınızdaki diğer tüm düğümler için aynı kalacaktır. Üniversitede de durum benzer p2. Bu nedenle, yalnızca kendi içsel bağlantıları (kendilerinin) galip geleceği için bağlantıları zordur. IP adres. Yönlendiricilerin adresleri veya aynı özel ağdaki tüm düğümlerin aynı harici adrese sahip olması nedeniyle harici adresleri hızlı bir şekilde bulabilirsiniz, ancak bunu başarmak zordur. Bu sorun ek bir mekanizmanın arkasında yatıyor NAT

Düğümlere hala dahili adresleri aracılığıyla bağlanma olasılığımız yüksekse ne olacak? Dani sınırların ötesine geçmeyecek. Efekti geliştirmek için kalan resimde gösterilen durumu görebilirsiniz - her iki düğüm de aynı dahili adreslere sahiptir. Eğer kokular onları iletişim için kullanacaksa, cilt kendiliğinden parçalanacaktır.

WebRTC Vikorist protokolünü kullanarak bu tür sorunlarla başarıyla başa çıkıyor BUZ Ek veri sunucularının vikoristanının önemli olduğu doğrudur ( Sersemletme, DÖNÜŞ). Aşağıdaki her şey hakkında.

WebRTC'nin iki aşaması

İki düğümü bir protokol aracılığıyla bağlamak için WebRTC(ya da sadece RTC ikisi nasıl iletişim kuruyor iPhone a) Bağlantıyı kurmak için önceki adımların uygulanması gereklidir. İlk aşama kurulan bağlantıdır. Diğer aşama ise video verilerinin iletilmesidir.

Teknolojinin ne istediğini söylemek kolay WebRTC robotu bir vikorist kişiliğine sahip çeşitli şekillerde iletişim ( TCPі UDP) ve aralarında çok sayıda dahili telefon var, bu teknoloji Bağlantı veri aktarım protokolü yok. İki wuzley'i birbirine bağlamanız şaşırtıcı değil p2pçok kolay değil. Bu yüzden annelerin yapması gerekenler ek olarak hiçbir şekilde veri aktarım yöntemiyle ilgili değildir. WebRTC. Bu bir soket aktarım protokolü olabilir HTTP, burada bir protokol oluşturabilirsiniz SMTP veya Rus Postası. Bu aktarım mekanizması koçanı veri denir sinyal. Aktarılması gereken çok fazla bilgi yok. Tüm veriler görsel olarak iletilir ve iki türe ayrılır - SDPі Buz Adayı. İlk tür mantıksal bir bağlantının kurulmasına, diğeri ise fiziksel bir bağlantının kurulmasına dayanır. Her şeyi daha sonra rapor edeceğiz, ancak bu arada şunu unutmamak önemlidir: WebRTC Başka bir düğüme aktarılması gereken bilgileri bize verin. Sana her şeyi nasıl anlatabiliriz? Gerekli BilgiÜniversiteler birleşebilir ve artık yardımımıza ihtiyaç kalmaz. Böylece uygulayabileceğimiz sinyalleşme mekanizması okremo, vikoristovvatimetsya yalnızca bağlandığında ve video verilerini iletirken herhangi bir kötüye kullanım olmayacaktır.

Peki, ilk aşamaya yani bağlantı kurma aşamasına bakalım. Kazanılan birçok puandan oluşur. Önce bağlantıyı başlatan düğüm için, sonra sonlandıran düğüm için bu aşamaya bakalım.

  • Başlatıcı (telefon – arayan):
    1. Video veri iletimini yazdırma teklifi (createOffer)
    2. Seninkini al SDP SDP)
    3. Kendininkini çıkar Buz adayı Buz adayı)
  • Göz alıcı bir jingle ( Aranan kişi):
    1. Yerel (kendi) medya akışının alınması ve aktarımının kurulumu (getUserMediaStream)
    2. Yazdırma video veri iletiminden ve video oluşturulmasından önermelerin kaldırılması (createAnswer)
    3. Seninkini al SDP sinyal mekanizması yoluyla nesne ve iletim ( SDP)
    4. Kendininkini çıkar Buz adayı nesneler ve bunların bir sinyal mekanizması aracılığıyla iletilmesi ( Buz adayı)
    5. Uzak (yabancı) medya akışının alınması ve ekranda görüntülenmesi (onAddStream)

Diğer öğenin yetkisi daha azdır.

Adımların karmaşıklığına bakılmaksızın aslında üç tane var: kendi medya akışınızı göndermek (madde 1), bağlantı parametrelerini ayarlamak (madde 2-4), başka birinin medya akışını kaldırmak (madde 5). En katlanabilir olanı farklı bir yapıdır çünkü iki parçadan oluşur: takılı fizikselі mantıklı bağlantı. Persha siparişleri yol Paketlerin sınırın bir düğümünden diğerine gitmesinden sorumludur. Bir arkadaşına sipariş verir video/ses parametreleri- İçerik nasıl vikorize edilir, codecler nasıl vikoristlenir.

Düşünce aşaması teklif oluştur ya da başka cevap oluştur transfer aşamalarını takip edin SDPі Buz adayı nesneler.

Temel hususlar

Medya akışları (MediaStream)

Ana öz, video ve ses verileri akışı, resim ve ses gibi bir medya akışıdır. Yerel ve uzak olmak üzere iki tür medya akışı vardır. Yerel olan, verileri giriş cihazlarından (kamera, mikrofon) ve uzak cihazlardan bir sınır aracılığıyla alır. Böylece deri düğümü hem yerel hem de uzak akışa sahip olur. sen WebRTC akışlar için temel bir arayüz var Medya Akışı ve ayrıca ana arayüz Yerel Medya Akışıözellikle yerel akış için. sen JavaScript Yalnızca ilkine bağlı kalabilirsiniz, aynı zamanda vikorist de olabilirsiniz libjingle, başkalarıyla bağlantı kurabilirsiniz.

sen WebRTC Akışın ortasındaki hiyerarşinin tamamen karıştığı görülüyor. Cilt akışı çeşitli medya izlerinden oluşturulabilir ( Medya Takip), birçok medya kanalıyla birleştirilebilen ( Medya Kanalı). Aynı medya akışları benzer olabilir.

Her şeye sırayla bakalım. Kimin için aktif popoyu hatırlayalım. Sadece videoyu kendimize değil, üzerine yazacağımız kağıdın bulunduğu masamıza videoyu da aktarmak istememiz kabul edilebilir. İki videoya (mi + stil) ve bir sese (mi) ihtiyacımız var. Bu verilerin aynı tarafta olabilmesi için bizim ve tablonun farklı akışlara bölünmesi gerektiği açıktır. Yani içimizde iki kişi olacak Medya Akışı'a – biri bizim için, biri de masa için. Birincisi hem video hem de ses verilerini içerir, diğeri ise videoyu içerir (Malyunok 4).

Malyunok 4: İki farklı medya akışı. Biri bize biri masamıza

Medya akışının en azından verilerin yanlış beyan olasılığını içerme eğiliminde olduğu açıktır. farklı şekiller- video ve ses. Bu teknolojide garanti edilir ve veri türü medya kanalı aracılığıyla uygulanır Medya Takip. Medya parçaları özel bir güce sahiptir tür, bu da önümüzde olanın video veya ses olduğu anlamına gelir (Malyunok 5)

Malyunok 5: Medya akışları medya parçalarından oluşur

Program her şeyi nasıl ele alıyor? İki medya akışı oluşturabiliriz. Daha sonra iki video parçası ve bir ses parçası oluşturuyoruz. Kameralara ve mikrofonlara erişimi reddediyoruz. Her cilt cihazının galip gelmesi mümkündür. İlk medya akışındaki video ve ses parçasını ve diğer kameradaki video parçasını diğer medya akışına ekleyin.

Bağlantının diğer ucundaki medya akışlarını nasıl işaretleyebiliriz? Medya akışının gücü kimin için? etiket- Akışı, adını işaretleyin (Malyunok 6). Aynı güç ve medya yolları beliriyor. Video ve sesin başka şekillerde oynatılabileceğini düşünmek isterim.

Malyunok 6: Medya akışları ve parçaları etiketlerle tanımlanır

Peki, medya parçaları bir etiket aracılığıyla tanımlanabildiğine göre, uygulamamız için bir yerine iki medya akışı mı kullanmalıyız? Aja tek bir medya akışını iletebilir ve parçalar farklı şekillerde birleştirilebilir. Medya akışlarının önemli gücüne ulaştık: koku senkronize etmek medya izleri. Farklı medya akışları birbiriyle senkronize edilmez, ancak her medya akışının ortasında tüm parçalar bulunur gece boyunca ortaya çıkmak.

Öyle ki, istediğimiz gibi, sözlerimiz, yüzümüzdeki duygularımız ve arkushik gazetemiz aynı anda yayınlansın, o zaman tek bir medya akışını vikorist edebiliriz. Bu o kadar önemli olmadığından farklı akışları ayırt etmek daha iyidir - resim daha düzgün olacaktır.

İletim sırasında herhangi bir kanalın kapatılması gerekiyorsa yetkililerle hızlı bir şekilde iletişime geçebilirsiniz. etkinleştirilmiş medya izleri.

Stereo ses hakkında düşünmek en iyisidir. Gördüğünüz gibi stereo ses iki farklı sestir. Bunları kesinlikle iletmek de gerekiyor. Kanallar kimin adına zafer kazanıyor? Medya Kanalı. Sesin medya kaydı birçok kanalda (örneğin 5+1 ses isteniyorsa 6 kanal) yapılabilmektedir. Medya kanalının ortasında kanallar bulunur, özellikle senkronize. Videolar için yalnızca bir kanala ihtiyacınız vardır ancak bunu örneğin reklamcılık için de kullanabilirsiniz.

Özetlemek: Video ve ses verilerini iletmek için bir medya akışı kullanıyoruz. Cilt ortamının ortasında veri akışı senkronize edilir. Senkronizasyona ihtiyacımız olmadığı için yalnızca birkaç medya akışını seçebiliyoruz. Dış görünüm medya akışının ortasında video ve ses için iki tür medya parçası vardır. İkiden fazla parça olmadığından emin olun ve birden fazla farklı videoyu (tablonuza yayıcı) aktarmanız gerekirse daha fazlası da olabilir. Dış görünüm parçası birden fazla kanaldan oluşabilir; bu da yalnızca stereo ses için idealdir.

En basit görüntülü sohbet durumunda, esas olarak iki parçadan oluşan bir yerel medya akışı vardır; bir ana kanaldan oluşan bir video parçası ve bir ses parçası. Video parçası kamerayı, ses parçası mikrofonu ve medya akışı da aynı kabı temsil eder.

Oturum Tanımlayıcısı (SDP)

sen çeşitli bilgisayarlar Gelecekte farklı kameralar, mikrofonlar, video kartları ve diğer ekipmanlar ortaya çıkacak. Kokuyu belirleyecek hiçbir parametre yoktur. İki ağ düğümü arasındaki medya aktarımı için her şeyin koordine edilmesi gerekir. WebRTC Bu otomatik olarak özel bir nesne (oturum tanımlayıcı) yaratacaktır. SDP. Bu nesneyi başka bir düğüme aktardığınızda medya verileri aktarılabilir. Diğer düğümle hala bağlantı yok.

Hangi amaçla bir çeşit sinyal mekanizması var? SDP soketler aracılığıyla veya şahsen (diğer düğümünüzü telefonla bilgilendirin) veya Rus Posta yoluyla iletilebilir. Her şey çok basit - size hazırlığı verecekler SDP Bunun gönderilmesi gerekiyor. Eğer diğer taraftan koparılırsa vesayete teslim edin. WebRTC. Oturum tanımlayıcısı metne kaydedilir ve uygulamalarınızda değiştirilebilir, aksi takdirde gerekli değildir. Kural olarak, bir masaüstü/telefon veya bilgisayarı bağladığınızda gerekli ses codec bileşenini seçmeniz gerekir.

Bağlantı kurulduğunda herhangi bir adresin belirtilmesi gerekir; örneğin URL'si. Burada itiraf için veriyi sinyal mekanizmasıyla göndermenize gerek yok. Lütfen belirtiniz WebRTC, yüklemek istediğimiz şey p2p Bağlantı, createOffer işlevinin çağrılmasını gerektirir. Bu fonksiyona tıklayıp özel bir değer ekledikten sonra geri çağırmak'bir yaratılacak SDP nesne ve aynı yere aktarıldı geri çağırmak. Tek yapmanız gereken nesneyi ağ üzerinden başka bir düğüme (yayıcıya) aktarmaktır. Daha sonra diğer uçta sinyal mekanizması aracılığıyla veri bulunur ve ardından SDP nesne Bu yabancı düğüm için bu oturum tanımlayıcısı değil kullanışlı bilgi. Nesneyi almak koçanın katılması için bir sinyaldir. Yani buna bakmalı ve createAnswer fonksiyonuna tıklamalısınız. Vona, createOffer'ın yeni bir analogudur. seninkini arıyorum geri çağırmak yerel oturum tanımlayıcısını iletin; bunun sinyalleşme mekanizması aracılığıyla geri iletilmesi gerekecektir.

Warto, createAnswer işlevini ancak başka birinin yanıtını aldıktan sonra arayabileceğinizi unutmayın. SDP nesne Neden? Çünkü yerel SDP CreateAnswer'a tıkladığınızda oluşturulacak nesne, uzakta saklanmaktan suçludur SDP nesne Ancak bu durumda video ayarlamalarını casus yazılımın ayarlamalarıyla koordine edebilirsiniz. Yerel medya akışını yayınlamadan önce createAnswer ve createOffer'a tıklamak da mümkün değildir; yazacak hiçbir şeyleri olmayacaktır. SDP nesne

Bo içeri WebRTCє düzenleme imkanı SDP Yerel tanımlayıcıyı kaldırdıktan sonra onu eklemeniz gerekir. Burada iletilmesi gereken birkaç harika şeyi bulabilirsiniz WebRTC kendisinin bize verdikleri, yani böyle bir protokol. Bir uzak tanımlayıcıyı kaldırdığınızda onu eklemeniz gerekir. Bir düğüme iki tanımlayıcı yüklemeniz gerekir; kendinizin ve bir başkasının (yerel veya uzak).

Bundan sonra el yapımı Woozley birinin takıntısını biliyor. Örneğin yakscho vuzol 1 codec bileşenlerini destekler Aі B ve vuzol 2 codec bileşenlerini destekler Bі C, o zaman üniversitenin cildi kendisinin ve diğer insanların tanımlayıcılarını bilir, ev sahibi bir codec seçmeye gücenir B(Malyunok 7). Bağlantı mantığı artık kuruludur ve medya akışları iletilebilir, ancak başka bir sorun daha vardır - düğümler, daha önce olduğu gibi, yalnızca bir sinyalleşme mekanizmasıyla bağlanır.


Malyunok 7: Kullanılabilir codec'ler

Buz adayı

Teknoloji WebRTC yeni metodolojisiyle kafamızı karıştırmak istiyor. Bağlantı kurulmadan önce bağlanmanız gereken düğümün adresi belirtilmez. Böbrek onarılıyor daha mantıklı bağlantı değil fiziksel olarak daha fazla Her ne kadar ilk etapta çekingen olsam da. Ancak bu şaşırtıcı olmayacak, ancak üçüncü taraf bir sinyalleşme mekanizmamızın olduğunu unutmayın.

Ancak bağlantı zaten kuruludur (mantıksal bağlantı), ancak hala düğümlerin veri iletebilmesinin bir yolu yoktur. Her şey o kadar basit değil ama basitleştirelim. Bırakın pislikler aynı özel alanda olsun. Bildiğimiz gibi kokular kendi iç yapıları sayesinde kolaylıkla birbirleriyle bağlantı kurabilirler. IP adresiniz (ya da herhangi bir nedenle galip gelmediğiniz için olabilir) TCP/IP).

Deyaki aracılığıyla geri çağırmakWebRTC bizi bilgilendirir Buz adayı nesneler. Ayrıca bir metin biçiminden de gelebilirler ve oturum tanımlayıcıları gibi yalnızca bir sinyalleşme mekanizması yoluyla gönderilmeleri gerekir. Oturum tanımlayıcıda aynı kamera ve mikrofondaki kurulumlarımıza ilişkin bilgiler yer alıyorsa adaylar aynı zamanda gelişimimize ilişkin bilgileri de içerecektir. Bunları başka bir düğüme aktarın ve bizimle fiziksel olarak bağlantı kurabilirsiniz ve bu düğümün zaten bir oturum tanımlayıcısı olduğundan, bağlanabilmeleri ve verilerin akması mantıklıdır. Aday adayınızın adaylık aşamasında olanların bilgilerini bize iletmeyi unutmazsanız kendisiyle iletişime geçebiliriz. Elbette burada klasik istemci-sunucu etkileşiminden bir fark daha var. HTTP sunucusuyla bağlantı bir güç kaynağı devresi kullanılarak gerçekleştirilir, istemci verileri sunucuya gönderir, sunucu onu işler ve devam eder Pakette belirtilen adresi isteyeceğim. sen WebRTC bilmem gerek iki adres Ve onları her iki taraftan bağlayın.

Oturum tanımlayıcılarının önemi, daha uzak adayların yerleştirilmesinin gerekli olmasıdır. Buradaki alan çitlerle çevrili ve su kabuğunu içeri alamıyoruz. Mevcut uygulamalarda WebRTC oturum tanımlayıcıları yüklendikten sonra adayların yüklenmesi gerekir.

Oturum için neden tek bir tanımlayıcı var ama çok sayıda aday olabiliyor? Çünkü kenarlarda yeniden şekillenme süreci sadece kendi iç yapısından dolayı görülemez. IP adresin yanı sıra yönlendiricinin harici adresi ve yalnızca bir değil, aynı zamanda adresler DÖNÜŞ sunucular. Paragrafın geri kalanı adayların rapor incelemesine ve üniversitelerin çeşitli özel ağlardan nasıl bağlanacağına ayrılacaktır.

Eh, iki vuzli bir sınırda bulunur (Malyunok 8). Onları nasıl tanımlayabiliriz? Daha fazla yardım için IP adres. Daha fazla yok. Doğru, farklı ulaşım türlerini vikorize etmek hala mümkün ( TCPі UDP) ve katliam. Bu, adayın projesinde yer alan bilgilerdir – IP, LİMAN, ULAŞIM Ve insha olarak. Örneğin vikorist olmaktan çekinmeyin UDP ulaşım ve 531 liman.

Malyunok 8: Bir sınırda iki düğüm bulunur

Todi, üniversiteyi ziyaret ederken p1, O WebRTC bize böyle bir aday nesne verin - . Burada ihtiyaç duyulan tam format değil, sadece bir diyagram. Vuzli'de nasılız? p2, o zaman aday – . Bir sinyal mekanizması aracılığıyla p1 adayı reddeder p2(o zaman roztashuvannya vuzla'ya p2 ve yoganın kendisi IPі LİMAN). Neyden sonra p1 ile bir araya gelebilirsiniz p2 ortası olmadan. Daha doğrusu, p1 Adrese ayrıntıları ekleyeceksiniz 10.50.150.3:531 kokunun gitmesi umuduyla p2. Adresi vuzluya yazmanız önemli değil p2 Arabulucuyla konuşuyorum. Bu adres aracılığıyla güç verilen ve ulaşabilenler için önemlidir. p2.

Düğümler tek bir çizgideyken - her şey basit ve kolaydır - deri düğümünün adayın yalnızca bir nesnesi vardır (her zaman kendi temelinde, böylece gelişimi aynı anda olur). Üniversiteler gelirse daha fazla aday olur çeşitli sınırlar.

Gelelim işin çetrefilli kısmına. Bir ünite yönlendiricinin arkasında (daha doğrusu NAT'ın arkasında) bulunur ve diğer ünite bu yönlendiriciyle aynı anda bulunur (örneğin İnternette) (Malyunok 9).

Malyunok 9: NAT için bir okul, hayır için başka bir okul

Bu olgu, şimdi inceleyeceğimiz gibi, daha ciddi bir sorun teşkil etmektedir. Ev yönlendiricisi Masada intikam alma çağrısı NAT. Bu, yönlendiricinin özel ağının ortasındaki düğümlerin örneğin web sitelerine genişletilebilmesi için tasarlanmış özel bir mekanizmadır.

Web sunucusunun doğrudan internete bağlanması kabul edilebilir, bu durumda halka açıktır IP*adres. Vuzol olsun p2. Vuzol p1(Web istemcisi) adresine gönderildi 10.50.200.10 . Verilerin çoğu yönlendiricide harcanıyor r1, Daha doğrusu yogada dahili arayüz 192.168.0.1 . Bundan sonra yönlendirici cihaz adresini (adres p1) ve özel bir tabloya girin NAT, ardından e-posta adresini kendi adresinizle değiştirin ( p1 r1). Uzakta, kendin için harici Yönlendirici arayüzü verileri doğrudan web sunucusuna iletir p2. Web sunucusu verileri işler, bir yanıt oluşturur ve geri gönderir. Yönlendiriciye gönderir r1 Ek olarak, dönüş adresinde sizin de durmanız gerekir (yönlendirici adresi kendi adresinizle değiştirmiştir). Yönlendirici verileri toplar, tabloya bakın NAT vuzluya olan saygıyı bastırıyor p1. Yönlendirici burada aracı görevi görür.

Neden iç sınırlardan birkaç düğüm aniden dış sınıra doğru patlıyor? Yönlendirici onayı kimin geri alabileceğini nasıl anlıyor? Bu sorunun yardıma ihtiyacı var limanlar. Yönlendirici ana bilgisayar adresini kendi adresiyle değiştirirse bağlantı noktasını da değiştirir. İki düğüm internete bağlanırsa yönlendirici bunların bağlantı noktalarını değiştirir katliam. Daha sonra web sunucusundan gelen paket yönlendiriciye geri gelirse yönlendirici, paketin gönderildiği bağlantı noktasını tanır. Popo daha alçak.

Teknolojiye dönelim WebRTC veya daha doğrusu vikorist olan bu kısma kadar BUZ protokol (zvіdsi ben buz adaylar). Vuzol p2 bir aday olabilir (kendi sınırları dahilinde genişlemesi – 10.50.200.10 ) ve vuzol p1 NAT'lı bir yönlendiricinin arkasında bulunan iki aday vardır - yerel ( 192.168.0.200 ) bu yönlendirici adayı ( 10.50.200.5 ). İlki gelecekte olmayacak ama daha az üretilmeyecek, parçalardan oluşacak. WebRTC hala uzak düğümler hakkında hiçbir şey bilmiyor - aynı bölgede bulunabilirler veya olmayabilirler. Gelecekte başka bir aday olacak ve zaten bildiğimiz gibi limanın önemli rolü (geçmek) NAT).

Tablo girişi NAT Veriler iç ağdan çıkar çıkmaz oluşturulur. Tom vuzol p1 Verilerin ilk aktarımından ve sonraki verilerin üniversiteye aktarılmasından suçlu p2 düğüme ulaşabilir p1.

Uygulamada saldırgan sersem fazla ayakkabı giyilecek NAT. Tabloda kayıt oluşturmak için NAT cilt yönlendiricisi, suçlu düğümün uzaktaki bir düğüme gönderilmesi gerekir, ancak bu sefer ilki diğerine ne şekilde olursa olsun ulaşamaz. Bunun nedeni üniversitelerin dışarıdakileri tanımamasından kaynaklanmaktadır. IP adrestir ve dahili adreslere veri eklemek güvenlidir.

Ancak harici adresler görünüyorsa bağlantı kolaylıkla kurulacaktır. İlk düğüm başka bir düğümün yönlendiricisinde veri bulursa yönlendirici bunları yok sayar, tablosunun parçaları NAT hala boş. Ancak ilk düğümün yönlendiricisinin bir tablosu var NAT Vinil kayıt gerektirir. Başka bir düğüm, ilk düğümün yönlendiricisine veri gönderirse, onların yönlendiricisi, verileri başarıyla ilk düğüme aktaracaktır. Şimdi masa NAT başka bir yönlendiriciden gelen veriler.

Sorun dış görünüşünüzü bilmektir IP adres, uyku alanında bir üniversiteye ihtiyaç var. Bu sorunu çözmek için doğrudan internete bağlanan ek sunucular kullanılır. Ayrıca tabloda ek kayıtlar oluşturmaya da yardımcı olurlar NAT.

STUN ve TURN sunucuları

Başlatma üzerine WebRTC mevcut olduğunu belirtmek gerekir Sersemletmeі DÖNÜŞ verdiğimiz sunucular çağrılıyor BUZ sunucular. Sunucu belirtilmemişse, yalnızca aynı ağdaki düğümler bağlanabilir (ona bağlantılar olmadan) NAT). Ne için olduğu hemen belli 3g-Merezh obov'yazkove vikoristannya DÖNÜŞ sunucular.

Sersemletme sunucu– gönderenin ana bilgisayar adresine dönüş adresini döndüren yalnızca İnternet'teki bir sunucudur. Yönlendiricinin arkasında bulunan Vuzol patlayarak Sersemletme geçilecek sunucu NAT. Paket, sana ne geliyor Sersemletme sunucu, böylece jerel'in adresi bulunur - yönlendiricinin adresi, ardından düğümümüzün harici adresi. Qia adresleri Sersemletme sunucu geri gönderir. Bu şekilde üniversite dışsallığını ortadan kaldırır. IP Erişilebilen herhangi bir ağ üzerinden adres ve bağlantı noktası. Dali, WebRTC Bu ek adres için ek bir aday (harici yönlendirici adresi ve bağlantı noktası) oluşturuyoruz. Şimdi masada NAT Yönlendirici, yönlendiriciye gönderilen paketleri gerekli bağlantı noktası üzerinden düğümümüze ileten bir kayıttır.

Bu sürece bir de uçtan bakalım.

Butt (STUN sunucu robotu)

Sersemletme sunucu aracılığıyla belirlenecek s1. Yönlendirici, daha önce olduğu gibi r1, ve vuzol – aracılığıyla p1. Tabloyu takip etmek de gerekli olacak NAT– її şu kadar önemlidir: r1_nat. Üstelik bu tablo, batmanın farklı düğümlerinden çok sayıda kayıt içermelidir - hiçbir koku yaratılmayacaktır.

Tamam, şimdi boş bir masam var r1_nat.

Tablo 2: Paket Başlığı

Vuzol p1 bu paketi yönlendiriciye gönderir r1(Rütbenin ne olduğu önemli değil, çeşitli alt bölümlerin vikorstanları olabilir) farklı teknolojiler). Yönlendiricinin cihaz adresini değiştirmesi gerekiyor Kaynak IP'si, Pakette yer alan adresler açıkça harici alt bölümlere uygun olmadığından, üstelik bu aralıktaki adresler ayrılmıştır ve İnternet'teki başka hiçbir adres bu tür adresleri içermemektedir. Yönlendirici pakette bir değişiklik yapılmasını gerektirir ve Yeni giriş senin masanda r1_nat. Bunun için port numarasını tahmin etmeniz gerekiyor. Sınırın ortasındaki birkaç düğümün parçalarının dış sınıra doğru genişleyebileceği açıktır, ardından tabloda NAT Yönlendiricinin, sunucudan gelen dönüş paketinin birçok düğümden hangisine atandığını belirleyebilmesi için ek bilgilerin kaydedilmesi gerekir. Yönlendiricinin bir bağlantı noktası bulmasına izin verin 888 .

Paket başlığı değiştirildi:

Tablo 4: NAT tablosu yeni bir girişle güncellendi

Burada IP Daldırma için adresler ve bağlantı noktaları, çıktı paketininkilerle tamamen aynıdır. Aslında suçlu anneye dönerken onları yenilemenin de bir yolu vardır. IP harici ağ adresleri yönlendiricinin adresiyle aynıdır ve bağlantı noktası, yönlendirici tarafından oluşturulan bağlantı noktasıyla değişmiştir.

Yakiy vuzol'da Spravzhny limanı p1 bağlantıları kabul eder - bu anlaşılır bir şekilde, 35777 , ancak sunucu verileri hayali liman 888 , yönlendirici tarafından referans olana değiştirilecek 35777 .

Daha sonra yönlendirici, paket başlığındaki adresi ve bağlantı noktasını değiştirdi ve tabloya bir giriş ekledi. NAT. Şimdi paket ağ üzerinden sunucuya, ardından düğüme gönderilir. s1. Girişte, s1 Aşağıdaki pakete sahibim:

Kaynak IP'si Kaynak Bağlantı Noktası Hedef IP Hedef LİMANI
10.50.200.5 888 12.62.100.200 6000

Tablo 5: Paket alan STUN sunucusu

Birlikte, Sersemletme sunucu en iyi paketin adres olduğunu bilir 10.50.200.5:888 . Artık sunucu bu adresi geri gönderir. Burada durup bu kadar sevgiyle baktığımız şeye bir kez daha hayret edebilirsiniz. Yerleştirilen masalar - pek çok şey başlık paket, hiç değil yerine. O kadar önemli olmadığı için bizim yerimize konuşmadılar - bunun protokolde açıklanması gerekiyordu Sersemletme. Artık onun yerine başlığa bakabiliriz. Affedilecek ve yönlendirici adresine saygılı olacaksınız - 10.50.200.5:888 , mi yogo z'yi almak istiyorum başlık naylon poşet. Bu çok sık korkulacak bir şey değil, çünkü protokoller üniversitelerin adres bilgilerine önem vermiyor, paketlerin amaca uygun teslim edilmesi önemli. Burada iki düğüm arasında yol kuran protokolü görebiliriz.

Artık doğrudan ağ geçidine giden başka bir paketimiz var:

Tablo 7: STUN sunucusu bunun yerine paketi geliştirir

Daha sonra paket, yeni yönlendirici arayüzüne ulaşana kadar daha pahalı hale gelecektir. r1. Yönlendirici paketin size atandığını anlar. Bunu nasıl anlıyorsunuz? Sadece limana göre öğrenebilirsiniz. Liman 888 Kendi özel amaçları açısından vikorist değil, mekanizma açısından vikoristtir NAT. Ayrıca bir yönlendirici masam var ve merak ediyorum. Stovpets'e hayret edin Harici PORT Ve ona eşlik eden satırı arıyor Hedef LİMANI paketle birlikte, scho priyshov, tobto 888 .

Dahili IP Dahili PORT Harici IP Harici PORT
192.168.0.200 35777 10.50.200.5 888

Tablo 8: NAT Tablosu

Şanslıydık, böyle bir sıra var. Yakbi bağışlanmasaydı paket atılırdı. Artık hangi alt düğümlerin bu paketi güçlendirmesi gerektiğini anlamanız gerekiyor. Acele etmeye gerek yok, bu mekanizmada limanların önemini bir kez daha anlayalım. Aynı zamanda ortadaki iki düğüm mevcut seviyeye kadar içebilir. Todi, ilk düğüm için yönlendirici bağlantı noktasını seçti 888 , sonra başka bir şarap için, bir porto şarabı bulduktan sonra 889 . Hadi bunun gerçekleştiğini varsayalım, yani tablo r1_nat buna benzer:

Tablo 10: Yönlendirici, alıcı adresinin yerini alır

Kaynak IP'si Kaynak Bağlantı Noktası Hedef IP Hedef LİMANI
12.62.100.200 6000 192.168.0.200 35777

Tablo 11: Yönlendiricinin alıcı adresini taklit etmesi

Paket düğüme başarıyla ulaştı p1 Ve pakete hayret eden üniversite, paketin şu anki görünümünü öğreniyor IP adres, bu yönlendiricinin dış sınırdaki adresidir. Ayrıca yönlendiricinin geçtiği bağlantı noktasını da bilir. NAT.

Sıradaki ne? Ne tür kızamık? Maliyet – bu tablodaki bir giriştir r1_nat. Şimdi yönlendiriciye ne gönderilecek? r1 limandan gelen paket 888 , ardından yönlendirici bu paketi düğüme yönlendirecektir. p1. Böylece kilitli okula giden küçük dar geçidi tamamlamış olduk. p1.

Popoda işle ilgili ifadeleri daha kolay reddedebilirsiniz NAT ve özü Sersemletme sunucu. Mekanizma devreye girdi BUZі Sersemletme/dönüş sunucular doğrudan etek çizgisine yönlendirilir NAT.

Bir düğüm ile sunucu arasında tek bir yönlendirici değil, bir grup yönlendirici olabilir. Bu durumda üniversite, sunucuyla aynı bölgede bulunan ilk yönlendiricinin adresini seçer. Yani bağlı olduğumuz router’ın adresini alıyoruz. Sersemletme sunucu. İçin p2p cilt yönlendiricisinin tabloda gerekli satırlara sahip olacağı gerçeğini unutmamak için iletişim tam da ihtiyacımız olan şeylerdir NAT. Böylece geçit yolu çok düzgün olacak.

DÖNÜŞ sunucu - azaltma yok Sersemletme sunucu. Ne olursa olsun hemen izi takip edin DÖNÜŞ sunucu bu şekilde çalışabilir Sersemletme sunucu. Avantajlarını koruyun. Yakşço p2p iletişim imkansızdır (örneğin, 3g merezh), ardından sunucu tekrarlayıcı moduna geçer ( röle), daha sonra aracı olarak hareket eder. Ne olursa olsun anlıyorum p2p o zaman mekanizmanın çerçevesi dışında hiçbir yol yoktur BUZ Woozley ortada ne yapacağını düşünüyor.

Bazı durumlarda gereklidir DÖNÜŞ sunucu? Neden görünmüyor Sersemletme sunucular? Sağda bir dizi farklı tür var NAT. Ancak koku değişir IP adres o liman, onlardan amelleri koru ek zahist"sahtecilik" olarak. Örneğin, simetrik tablolar NAT 2 parametre daha kaydedildi - IP ve uzak düğümün bağlantı noktası. Dış sınırdan gelen paket geçiyor NAT Dahili önlemde, yalnızca bu durumda cihazın adresleri ve portları tablodaki girişlerden kaçınılır. odak noktası budur Sersemletme sunucu ayrıntıya girmiyor - tablo NAT adresi ve bağlantı noktasını kaydeder Sersemletme yönlendirici paketi kabul ederse sunucular WebRTC“Sahtekarlık” parçalarını fırlatan spіvrozmovnik. Henüz gelmiyor Sersemletme sunucu.

Bu şekilde DÖNÜŞ spivrozmovniklerin rahatsız olması durumunda sunucuya ihtiyaç vardır simetrik NAT(Kendi adına Kozhen).

Kısa arama

İşte esanslarla ilgili bazı iddialar WebRTC, çünkü önce hatırlamak gerekiyor. O şeyin kokusu ayrıntılı olarak anlatılıyor. Eğer onaylamalardan herhangi biri konusunda tamamen aklı başında değilseniz, aşağıdaki paragrafları tekrar okuyun.

  • Medya akışı
    • Video ve ses verileri medya akışları halinde paketlenir
    • Medya akışları, oluşturuldukları medya parçalarını senkronize eder
    • Farklı medya akışları birbiriyle senkronize edilmez
    • Medya akışları, bir kameranın veya mikrofonun yerel olarak bağlı olup olmamasına bağlı olarak yerel veya uzak olabilir; veriler, kodlanmış bir görünümde verilerden alınabilir.
    • Video ve ses için iki tür medya parçası vardır
    • Medya parçaları daha koyu/kötü olma özelliğine sahip olabilir
    • Medya parçaları medya kanallarından oluşur
    • Medya izleri oluşturuldukları medya kanallarını senkronize eder
    • Medya akışları ve medya parçaları, onları ayırmak için kullanılabilecek etiketler içerir
  • Oturum tanımlayıcı
    • Oturum tanımlayıcısı iki ağ düğümünü mantıksal olarak bağlayacak şekilde değiştirildi
    • Oturum tanımlayıcısı aşağıdakilerle ilgili bilgileri saklar: erişilebilir yollar video ve ses verilerinin kodlanması
    • WebRTC Vikorist'in harici sinyal mekanizması – önceden seçilmiş oturum tanımlayıcıları ( SDP) ek üzerine düşüyor
    • Mantıksal akıl yürütme mekanizması iki aşamadan oluşur - önerme ( teklif) ve türleri ( cevap)
    • Farklı zamanlarda yerel medya akışları kullanılmadan oturum tanımlayıcısının oluşturulması imkansızdır ( teklif) ve her tür için uzak oturum tanımlayıcısını değiştirmeden mümkün değildir ( cevap)
    • Kaldırma tanımlayıcısının uygulanması gerekiyor WebRTC ve bu tanımlayıcının aynı uygulamadan kaldırılmış veya yerel olarak kaldırılmış olması önemli değildir WebRTC
    • Oturum tanımlayıcısını biraz değiştirmek mümkündür
  • Adaylar
    • Aday ( Buz adayı) – bu sınırdaki düğümün adresidir
    • Düğüm adresleri size ait olabileceği gibi yönlendiricinin veya yönlendiricinin adresi de olabilir. DÖNÜŞ sunucular
    • Her zaman çok sayıda aday vardır
    • Aday şu şekilde oluşturulur: IP adres, bağlantı noktası ve taşıma türü ( TCP ya da başka UDP)
    • Adaylar kenardaki iki düğüm arasında fiziksel bağlantı kurmayı başarırlar
    • Adayların ayrıca bir sinyalizasyon mekanizması aracılığıyla gönderilmesi gerekmektedir.
    • Adaylar da uygulamaya aktarılıyor WebRTC, yalnızca uzaktakiler hakkında
    • Mevcut uygulamalarda WebRTC adaylar yalnızca bir oturum tanımlayıcısı ayarlandıktan sonra iletilebilir
  • STUN/DÖNÜŞ/BUZ/NAT
    • NAT– dış sınıra erişimin sağlanmasına yönelik bir mekanizma
    • Ev yönlendiricileri özel bir tabloyu destekler NAT
    • Yönlendirici, paketlerdeki adresleri değiştirir; paket dış sınırdan geliyorsa ana bilgisayar adresi kendi adresiyle ve paket dış sınırdan geldiğinde alıcı adresi iç sınırdaki düğüm adresiyle değiştirilir.
    • Dış sınırlara çoklu kanal erişimi sağlamak NAT vikorist ganimeti
    • BUZ– baypas mekanizması NAT
    • Sersemletmeі DÖNÜŞ sunucular – bypass için yardımcı sunucular NAT
    • Sersemletme sunucu tabloda gereksiz kayıtlar oluşturmanıza olanak tanır NAT ve ayrıca harici düğüm adresini döndürür
    • DÖNÜŞ sunucu kaydediliyor Sersemletme mekanizmayı tekrar çalıştırıp çalışmasını sağlayın
    • En kötü bölümlerde DÖNÜŞ vikory sunucusu bir aracı olarak kabul edilir ( röle), Daha sonra p2p istemci-sunucu-istemci bağlantısına dönüşür.

Merhaba arkadaşlar, bildiğiniz gibi sizi düzenli olarak yeni teknolojilerle tanıştırıyoruz, bugün Google tarafından geliştirilen, kullanıcıların doğrudan tarayıcı, video ve ses ile kaybolmadan konuşmasını sağlayan bir teknoloji olan WebRTC'yi tanıtacağım, wiki nedir eklenti - Web sitesi veya program. Bilgisayarlar arasındaki görüntülü ve sesli iletişim doğrudan tarayıcıda gerçekleşir.
WebRTC teknolojisi Mozilla Firefox'ta desteklenmektedir Google tarayıcıları Chrome ve herhangi bir işletim sisteminde Opera da mevcuttur.
WebRTC nedir?
WebRTC, Web Gerçek Zamanlı İletişim'in kısaltmasıdır, bu teknoloji, internetteki diğer eklentilere, programlara veya hizmetlere ihtiyaç duymadan, sesli ve görüntülü sohbetleri doğrudan tarayıcıda gizlemenize olanak tanır. Bağlantılar doğrudan tarayıcınızdan yapılır.
Bazı hizmetler (Skype, Yahoo Messenger, Apple FaceTime, Google Hago vb.), trafiği başlatmak ve yönetmek için istemcileri birbirine bağlayan sunucuları kullanır. Vikorist hizmetleri için kayıt olmamız ve müşterilerin ve kişilerin listesini oluşturmamız gerekiyor.
WebRTC ile şefaatten önce bağlanan sunuculara, programlara veya sunuculara ihtiyacımız yok.
WebRTC'nin avantajları:
1. Hayır daha fazla eklenti Kaynakların ve pillerin kullanımından yararlanır.
2. Sohbetler daha özeldir (iyi).
3. Nasıl iletişime geçilir Yerel bağlantılar için Flos USA sunucuları değil, yerel pazar üzerinde çalışabilirsiniz.
4. Sadelik, kullanışlılık ve basitlik.
5. Başka yönlerde daha fazla gelişme olasılığı.
6. Bağlanma stabildir ve bazen son derece kararsız olan dış bileşiklerle temas halinde değildir.
Google'daki kişilerin geliştirdiği bir demom var, demoyu bitirmek kolaydır, daha fazla güç ve daha fazla bağlantıyla WebRTC'yi destekleyen eklentilerden birini kullanabilirsiniz, vikoristanlılar için daha kolaydır i. Yakında WebRTC programlarıyla ilgili bir rehber üzerinde çalışacağız.
WebRTC demosunu nasıl vikorista yaparsınız?
Aşağıdaki mesaja tıkladığınızda otomatik olarak bir sohbet oluşturulur. Bu odayla iletişime geçin, iletişime geçmek istediğiniz arkadaşınızı/arkadaşınızı göndermelisiniz.
Arkadaşınız/kız arkadaşınız ve sizinki, ancak vikoryizmden yalnızca siz suçlusunuz kalan sürümler Mozilla Firefox veya Google Chrome.

Demo WebRTC(Giriş sohbeti sesli-görüntülü)

Uvaga:
Demo pek stabil değil, sadece demo parçaları titriyor. Uzun süre galip gelebilirsiniz, ancak kısa süreliğine bağlantı kopabilir.
Bağlantı sorunları yaşıyorsanız farklı bir sohbet oluşturmayı deneyin.