üzerindeki malzemenin çoğu WebRTC kod yazmanın uygulama düzeyine odaklanır ve teknolojinin anlaşılmasına katkıda bulunmaz. Daha derine inmeye çalışalım ve bağlantının nasıl oluştuğunu, oturum tanımlayıcısının ve adayların neler olduğunu, neler olduğunu öğrenelim. sersemletmek Ve DÖNÜŞ sunucu.

WebRTC

giriiş

WebRTC, video veri iletimi için iki istemciyi bağlamanıza izin veren tarayıcı tabanlı bir teknolojidir. Ana özellikler, dahili tarayıcı desteğidir (örneğin, üçüncü taraf gömülü teknolojilere gerek yoktur). Adobe Flash) ve istemcileri ek sunucu kullanmadan bağlama yeteneği - bağlantı Eşler arası(Daha öte, p2p).

bağlantı kurmak p2p- oldukça zor bir görev, çünkü bilgisayarlar her zaman halka açık değildir IP adresler, yani internetteki adresler. Küçük miktar nedeniyle IPv4 adresler (ve güvenlik amaçlı) için bir mekanizma geliştirildi NAT, örneğin ev kullanımı için özel ağlar oluşturmanıza olanak tanır. Birçok ev yönlendiricisi artık destekliyor NAT ve bu sayede, İnternet sağlayıcıları genellikle bir tane sağlasa da, tüm ev cihazlarının İnternet erişimi vardır. IP adres. halk IP Adresler İnternette benzersizdir, ancak özel adresler benzersiz değildir. Öyleyse bağlan p2p- zor.

Bunu daha iyi anlamak için üç durumu göz önünde bulundurun: her iki düğüm de aynı ağda (1. Resim), her iki düğüm de farklı ağlarda (biri özel, diğeri genel) (2. Resim) ve her iki düğüm de aynı olan farklı özel ağlardadır. IP adresler (Figür 3).

Şekil 1: Aynı ağdaki her iki düğüm

Şekil 2: Farklı ağlardaki düğümler (biri özel, biri genel)

Şekil 3: Farklı özel ağlardaki, ancak sayısal olarak eşit adreslere sahip düğümler

Yukarıdaki şekillerde, iki karakterli notasyondaki ilk harf düğüm tipini göstermektedir (p = akran, r = yönlendirici). İlk şekilde, durum elverişlidir: ağlarındaki düğümler tamamen ağ tarafından tanımlanır. IP adresler ve bu nedenle doğrudan birbirlerine bağlanabilirler. İkinci şekilde, benzer düğüm numaralarına sahip iki farklı ağımız var. Burada, ağlarının içinde ve ağlarının dışında olmak üzere iki ağ arayüzüne sahip yönlendiriciler (yönlendiriciler) görünür. Bu nedenle iki tane var IP adresler. Düzenli düğümler, yalnızca kendi ağlarında iletişim kurabilecekleri tek bir arayüze sahiptir. Verileri ağlarının dışındaki birine iletirlerse, o zaman yalnızca NAT yönlendiricinin (yönlendirici) içinde ve bu nedenle altında başkaları tarafından görülebilir IP yönlendirici adresi onların harici IP adres. Böylece, düğüm p1 Orada iç mekan IP = 192.168.0.200 Ve harici IP = 10.50.200.5 , son adresi de kendi ağındaki diğer tüm ana bilgisayarların dışında olacak şekilde. Durum düğüm için benzer p2. Bu nedenle, bağlantıları yalnızca dahili (kendi) IP adresler. Harici adresleri, yani yönlendiricilerin adreslerini kullanabilirsiniz, ancak aynı özel ağdaki tüm düğümler aynı harici adrese sahip olduğundan, bu oldukça zordur. Bu sorun mekanizma ile çözülür. NAT

Düğümleri dahili adresleri üzerinden bağlamaya karar verirsek ne olur? Veriler ağdan ayrılmayacaktır. Efekti arttırmak için, son şekilde gösterilen durumu hayal edebilirsiniz - her iki düğüm de aynı dahili adreslere sahiptir. Bunları iletişim kurmak için kullanırlarsa, her düğüm kendisiyle iletişim kuracaktır.

WebRTC protokolü kullanarak bu tür problemlerle başarılı bir şekilde başa çıkıyor BUZ, ancak, ek sunucuların kullanılmasını gerektirir ( sersemletmek, DÖNÜŞ). Bütün bunlar aşağıda.

WebRTC'nin iki aşaması

İki düğümü bir protokol aracılığıyla bağlamak için WebRTC(ya da sadece RTC eğer iki bağlıysa iPhone a) bir bağlantı kurmak için bazı ön adımlar atılmalıdır. Bu ilk aşamadır - bir bağlantı kurmak. İkinci aşama, video verilerinin iletilmesidir.

Hemen söylenmelidir ki, teknoloji olmasına rağmen WebRTCçalışmalarında çeşitli iletişim yöntemleri kullanır ( TCP Ve UDP) ve aralarında esnek geçişe sahip olan bu teknoloji bağlantı verilerini iletmek için bir protokole sahip değil. Şaşırtıcı değil, çünkü iki düğümü birbirine bağlayın p2pçok kolay değil. Bu nedenle, bazı sahip olmak gereklidir ek olarak veri aktarım yöntemi, ilgili değil WebRTC. Bir soket aktarımı, protokol olabilir HTTP, bir protokol bile olabilir SMTP veya Rus Postası. Bu aktarım mekanizması öncelik veri denir sinyal. Çok fazla bilginin aktarılması gerekmez. Tüm veriler metin olarak iletilir ve iki türe ayrılır - SDP Ve Buz Adayı. İlk tip mantıksal bir bağlantı kurmak için, ikincisi ise fiziksel bir bağlantı kurmak için kullanılır. Daha sonra buna daha fazla değineceğiz, ancak şimdilik şunu hatırlamak önemlidir. WebRTC bize başka bir düğüme iletilmesi gereken bazı bilgiler verecek. Gerekli tüm bilgileri ilettiğimizde, düğümler bağlanabilecek ve artık yardımımıza ihtiyaç kalmayacak. Yani uygulamamız gereken sinyal mekanizması ayrı ayrı, kullanılacak sadece bağlandığında, ve video verileri aktarılırken kullanılmayacaktır.

O halde ilk aşama olan bağlantı kurulum aşamasına bakalım. Birkaç öğeden oluşur. Bu aşamayı önce bağlantıyı başlatan düğüm için, ardından bekleyen düğüm için düşünün.

• Başlatıcı (arayan - arayan):
  1. Video veri iletimini başlatmayı teklif edin (createOffer)
  2. Başlarken SDP SDP)
  3. Başlarken buz adayı buz adayı)
• Görüşme beklemede ( aranan):
  1. Yerel (kendi) bir medya akışı alma ve bunu iletim için ayarlama (getUserMediaStream)
  2. Bir video veri aktarımı başlatmak ve bir yanıt oluşturmak için bir teklif alın (createAnswer)
  3. Başlarken SDP nesne ve onu sinyal mekanizmasından geçirmek ( SDP)
  4. Başlarken buz adayı nesneler ve bunların sinyal mekanizması yoluyla iletilmesi ( buz adayı)
  5. Uzak (yabancı) bir medya akışının alınması ve ekranda gösterilmesi (onAddStream)

Tek fark ikinci paragrafta.

Adımların görünürdeki karmaşıklığına rağmen, aslında üç adım vardır: kendi medya akışınızı gönderme (s. 1), bağlantı parametrelerini ayarlama (s. 2-4), başkasının medya akışını alma (s. 5). En zoru ikinci adımdır, çünkü iki bölümden oluşur: fiziksel Ve mantıklı bağlantılar. İlk gösterir yol, bir ağ düğümünden diğerine geçmek için hangi paketlerin gitmesi gerektiği. ikincisi gösterir video/ses parametreleri- hangi kalitenin kullanılacağı, hangi kodeklerin kullanılacağı.

zihinsel aşama teklif oluştur veya cevap oluştur transfer aşamalarına bağlanmalıdır SDP Ve buz adayı nesneler.

Temel varlıklar

Medya akışları (MediaStream)

Ana varlık medya akışıdır, yani video ve ses verisi, resim ve ses akışıdır. İki tür medya akışı vardır - yerel ve uzak. Yerel olan, giriş cihazlarından (kamera, mikrofon) ve uzak olandan ağ üzerinden veri alır. Böylece, her düğümün hem yerel hem de uzak bir iş parçacığı vardır. İÇİNDE WebRTC akışlar için bir arayüz var medya akışı ve ayrıca bir alt arayüz var Yerel Medya Akışıözellikle yerel iş parçacığı için. İÇİNDE JavaScript sadece ilkiyle karşılaşabilirsin ve eğer kullanırsan kitap jingle'ı, o zaman ikincisine de rastlanabilir.

İÇİNDE WebRTC iş parçacığı içinde oldukça kafa karıştırıcı bir hiyerarşi var. Her akış birkaç medya parçasından oluşabilir ( medya izi), bu da birkaç medya kanalından oluşabilir ( Medya Kanalı). Ayrıca birkaç medya akışı da olabilir.

Her şeyi sırayla düşünelim. Bunu yapmak için, bazı örnekleri aklımızda tutalım. Diyelim ki sadece kendi videomuzu değil, aynı zamanda üzerine bir şeyler yazacağımız bir kağıt parçasının bulunduğu masamızın videosunu da iletmek istiyoruz. İki videoya (biz + tablo) ve bir sese (biz) ihtiyacımız olacak. Açıktır ki, biz ve tablo farklı konulara ayrılmalıdır, çünkü bu veriler muhtemelen zayıf bir şekilde birbirine bağlıdır. Bu nedenle ikimiz olacak medya akışı'a - biri bizim için, diğeri masa için. İlki hem video hem de ses verilerini içerecek ve ikincisi yalnızca video içerecektir (Şekil 4).

Şekil 4: İki farklı medya akışı. Biri bize, biri masamıza

Medya akışının en azından farklı türlerdeki verileri - video ve ses - içerme yeteneğini içermesi gerektiği hemen açıktır. Bu, teknolojide dikkate alınır ve bu nedenle her veri türü bir medya izleme aracılığıyla uygulanır. medya izi. Medya izinin özel bir özelliği vardır tür, önümüzde ne olduğunu belirleyen - video veya ses (Şekil 5)

Şekil 5: Medya akışları, medya parçalarından oluşur

Programda her şey nasıl olacak? İki medya akışı oluşturacağız. Ardından iki video parçası ve bir ses parçası oluşturacağız. Kameralara ve mikrofona erişelim. Her parçaya hangi cihazı kullanacağını söyleyelim. İlk medya akışına bir video ve ses parçası ve ikinci medya akışına başka bir kameradan bir video parçası ekleyelim.

Ancak, bağlantının diğer ucundaki medya akışlarını nasıl ayırt ederiz? Bunu yapmak için, her medya akışının bir özelliği vardır. etiket– akış etiketi, adı (Şekil 6). Medya parçaları aynı özelliğe sahiptir. İlk bakışta video sesten başka şekillerde ayırt edilebilir gibi görünse de.

Şekil 6: Medya akışları ve izler etiketlerle tanımlanır

Öyleyse, medya parçaları bir etiket aracılığıyla tanımlanabiliyorsa, örneğimizde neden bir yerine iki medya akışı kullanmamız gerekiyor? Sonuçta, bir medya akışını aktarabilir ve içinde farklı parçalar kullanabilirsiniz. Medya akışlarının önemli bir özelliğine geldik - onlar senkronize etmek medya izleri. Farklı medya akışları birbiriyle senkronize edilmez, ancak her medya akışı içinde tüm izler Aynı anda oynanan.

Bu nedenle, sözlerimizin, yüzdeki duygularımızın ve kağıdımızın aynı anda oynatılmasını istiyorsak, o zaman tek bir medya akışı kullanmaya değer. Bu o kadar önemli değilse, farklı akışları kullanmak daha karlı - resim daha pürüzsüz olacaktır.

İletim sırasında bir parçanın devre dışı bırakılması gerekiyorsa, özelliği kullanabilirsiniz. etkinleştirilmiş medya izleri.

Sonunda, stereo sesi düşünmelisiniz. Bildiğiniz gibi stereo ses iki farklı sestir. Ayrıca ayrı olarak gönderilmeleri gerekir. Bunun için kanallar kullanılır. Medya Kanalı. Bir ses ortamı izinin birçok kanalı olabilir (örneğin, 5+1 sese ihtiyacınız varsa 6). Medya yolunun içinde, kanallar da tabii ki senkronize. Video için genellikle yalnızca bir kanal kullanılır, ancak örneğin reklam yer paylaşımları için birden fazla kanal kullanılabilir.

Özetlemek: video ve ses verilerini iletmek için bir medya akışı kullanıyoruz. Her medya akışında, veriler senkronize edilir. Senkronizasyona ihtiyacımız yoksa birden fazla medya akışı kullanabiliriz. Her medya akışında iki tür medya izi vardır - video ve ses için. Genellikle ikiden fazla parça yoktur, ancak birkaç farklı videoyu (muhatabın ve masasının) aktarmanız gerekirse daha fazlası olabilir. Her parça, genellikle yalnızca stereo ses için kullanılan birkaç kanaldan oluşabilir.

En basit görüntülü sohbet durumunda, her biri bir ana kanaldan oluşacak bir video parçası ve bir ses parçası olmak üzere iki parçadan oluşacak bir yerel medya akışımız olacak. Video parçası kameradan, ses parçası mikrofondan ve medya akışı her ikisinin de taşıyıcısıdır.

Oturum Tanımlayıcı (SDP)

Farklı bilgisayarların her zaman farklı kameraları, mikrofonları, video kartları ve diğer ekipmanları olacaktır. Sahip oldukları birçok seçenek var. Tüm bunlar, iki ağ düğümü arasında medya veri aktarımı için koordine edilmelidir. WebRTC bunu otomatik olarak yapar ve özel bir nesne oluşturur - oturum tanıtıcısı SDP. Bu nesneyi başka bir düğüme iletin ve medya verilerini gönderebilirsiniz. Sadece henüz başka bir düğümle bağlantı yok.

Bunun için herhangi bir sinyal mekanizması kullanılır. SDP prizler aracılığıyla, hatta bir kişi tarafından (telefonla başka bir düğüme söyleyin), hatta Russian Post tarafından iletilebilir. Her şey çok basit - size hazır bir ürün verilecek SDP ve gönderilmesi gerekiyor. Ve diğer tarafta alındıktan sonra - departmana transfer WebRTC. Oturum tanıtıcısı metin olarak saklanır ve bunu uygulamalarınızda değiştirebilirsiniz, ancak genellikle buna gerek yoktur. Örnek olarak, masaüstü↔telefonu bağlarken, bazen istenen ses codec bileşeninin seçimini zorlamanız gerekir.

Genellikle, bir bağlantı kurarken, örneğin bir adres belirtmeniz gerekir. URL. Burada buna gerek yok, çünkü verileri sinyal mekanizması aracılığıyla hedefe kendiniz göndereceksiniz. Belirtmek için WebRTC ne yüklemek istiyoruz p2p bağlantınız için createOffer işlevini çağırmanız gerekir. Bu işlevi çağırdıktan ve ona özel bir tanım verdikten sonra geri çağırmak'yaratılacak SDP nesne ve aynısına geçti geri çağırmak. Sizden gereken tek şey, bu nesneyi ağ üzerinden başka bir düğüme (muhatap) aktarmaktır. Bundan sonra, diğer uçta, sinyalleşme mekanizması yani bu aracılığıyla veriler gelecektir. SDP bir obje. Bu oturum tanımlayıcısı bu düğüme yabancıdır ve bu nedenle faydalı bilgiler taşır. Bu nesnenin alınması, bağlantıyı başlatmak için bir sinyaldir. Bu nedenle, bunu kabul etmeli ve createAnswer işlevini çağırmalısınız. Bu, createOffer'ın tam bir benzeridir. seninkine geri dön geri çağırmak yerel bir oturum tanımlayıcısını iletecek ve sinyal mekanizmasından geri geçirilmesi gerekecek.

CreateAnswer işlevini yalnızca başka birinin yanıtını aldıktan sonra çağırabileceğinizi belirtmekte fayda var. SDP nesne. Neden? Çünkü yerel SDP createAnswer çağrıldığında üretilecek nesne uzaktan kumandaya bağlı olmalıdır SDP bir obje. Yalnızca bu durumda video ayarlarınızı muhatabın ayarlarıyla koordine etmek mümkündür. Ayrıca, yerel medya akışı alınana kadar createAnswer ve createOffer'ı çağırmayın - yazacak hiçbir şeyleri olmayacak SDP bir obje .

Beri WebRTC düzenlemek mümkün SDP nesne, yerel tanıtıcı elde edildikten sonra ayarlanmalıdır. Geçmek biraz garip gelebilir WebRTC bize kendisinin verdiği şey, ama protokol bu. Bir uzaktan kumanda aldığınızda, onu da ayarlamanız gerekir. Bu nedenle, bir düğüme iki tanımlayıcı yüklemeniz gerekir - kendinizin ve başkasının (yani, yerel ve uzak).

böyle sonra tokalaşma Düğümler birbirlerinin isteklerini bilirler. Örneğin, eğer düğüm 1 kodekleri destekler A Ve B ve düğüm 2 kodekleri destekler B Ve C, sonra, her düğüm kendisinin ve diğerinin tanımlayıcılarını bildiğinden, her iki düğüm de bir codec bileşeni seçecektir. B(Şekil 7). Bağlantı mantığı artık kurulmuştur ve medya akışları iletilebilir, ancak başka bir sorun daha vardır - düğümler hala yalnızca bir sinyal mekanizmasıyla bağlıdır.

Şekil 7: Codec anlaşması

Adaylar (Buz adayı)

teknoloji WebRTC yeni metodolojisiyle kafamızı karıştırmaya çalışıyor. Bağlantı kurulurken bağlanmak istediğiniz düğümün adresi belirtilmez. İlk yüklenen mantıklı bağlantı, değil fiziksel, her zaman tersi yapılmış olsa da. Ancak, üçüncü taraf bir sinyal mekanizması kullandığımızı unutmazsak, bu garip gelmeyecektir.

Dolayısıyla, bağlantı zaten kurulmuştur (mantıksal bağlantı), ancak ağ düğümlerinin veri iletmesi için henüz bir yol yoktur. O kadar basit değil, ama basit başlayalım. Düğümlerin aynı özel ağda olmasına izin verin. Bildiğimiz gibi, dahili ağları aracılığıyla birbirlerine kolayca bağlanabilirler. IP adresler (veya kullanılmıyorsa belki başkaları) TCP/IP).

Bazıları aracılığıyla geri çağırmak'Ve WebRTC bize söyler buz adayı nesneler. Ayrıca metin biçiminde gelirler ve tıpkı oturum tanımlayıcılarında olduğu gibi, sadece sinyal mekanizması yoluyla gönderilmeleri gerekir. Oturum tanımlayıcısı, kamera ve mikrofon seviyesindeki ayarlarımız hakkında bilgi içeriyorsa, adaylar ağdaki konumumuz hakkında bilgi içerir. Onları başka bir düğüme iletin ve bize fiziksel olarak bağlanabilecek ve zaten bir oturum tanımlayıcısına sahip olduğu için mantıksal olarak bağlanabilecek ve veriler "akacak". Bize aday nesnesini, yani ağda nerede olduğuna dair bilgileri göndermeyi unutmazsa, o zaman onunla bağlantı kurabileceğiz. Burada klasik istemci-sunucu etkileşiminden bir farkı daha not ediyoruz. HTTP sunucusuyla iletişim, istek-yanıt şemasına göre gerçekleşir, istemci verileri sunucuya gönderir, sunucu da onu işler ve aracılığıyla gönderir. istek paketinde belirtilen adres. İÇİNDE WebRTC bilmem gerek iki adres ve bunları her iki taraftan bağlayın.

Oturum tutamaçlarından farkı, yalnızca uzak adayların ayarlanması gerekmesidir. Burada düzenleme yapmak yasaktır ve herhangi bir fayda sağlayamaz. Bazı uygulamalarda WebRTC adayların yalnızca oturum tanıtıcıları ayarlandıktan sonra ayarlanması gerekir.

Ve neden sadece bir oturum tanımlayıcısı varken birçok aday olabilir? Çünkü ağdaki konum yalnızca dahili tarafından belirlenemez. IP adres, aynı zamanda yönlendiricinin harici adresi ve mutlaka bir değil, adreslerin yanı sıra DÖNÜŞ sunucular. Paragrafın geri kalanı, adayların ayrıntılı bir tartışmasına ve farklı özel ağlardan düğümlerin nasıl bağlanacağına ayrılacaktır.

Yani, iki düğüm aynı ağdadır (Şekil 8). Onları nasıl tanımlayabilirim? Kullanarak IP adresler. Başka yol yok. Doğru, yine de farklı aktarımları kullanabilirsiniz ( TCP Ve UDP) ve farklı bağlantı noktaları. Bu, aday nesnede bulunan bilgidir - IP, LİMAN, ULAŞIM ve diğerleri. Örneğin, kullanalım UDP ulaşım ve 531 liman.

Şekil 8: İki düğüm aynı ağda

O zaman eğer bir düğümdeysek p1, O WebRTC bize böyle bir aday nesne verecek - . Bu kesin bir biçim değil, yalnızca bir diyagramdır. Eğer bir düğümdeysek p2, o zaman aday . Sinyal mekanizması aracılığıyla p1 bir aday alacak p2(yani, düğüm konumu p2, yani onun IP Ve LİMAN). Daha sonra p1 ile bağlanabilir p2 direkt olarak. Daha doğru, p1 adrese veri gönderecek 10.50.150.3:531 ulaşacakları ümidiyle p2. Bu adresin bir düğüme ait olup olmadığı önemli değil p2 veya bazı aracılar. Önemli olan tek şey, verilerin bu adres üzerinden gönderileceği ve ulaşılabilecek olmasıdır. p2.

Düğümler aynı ağda olduğu sürece - her şey basit ve kolaydır - her düğümün yalnızca bir aday nesnesi vardır (her zaman kendi anlamına gelir, yani ağdaki konumu). Ancak düğümler devreye girdiğinde çok daha fazla aday olacaktır. farklı ağlar.

Daha karmaşık bir duruma geçelim. Bir düğüm yönlendiricinin arkasında (daha doğrusu NAT'ın arkasında) olacak ve ikinci düğüm bu yönlendiriciyle aynı ağda (örneğin internette) olacaktır (Şekil 9).

Şekil 9: Bir ana bilgisayar NAT'ın arkasında, diğeri değil

Bu davanın, şimdi ele aldığımız soruna özel bir çözümü var. Bir ev yönlendiricisi genellikle bir tablo içerir. NAT. Bu, yönlendiricinin özel ağındaki düğümlerin, örneğin web sitelerine erişmesine izin vermek için tasarlanmış özel bir mekanizmadır.

Diyelim ki web sunucusu direkt olarak internete bağlı yani public bir erişime sahip. IP* adres. Düğüm olsun p2. Düğüm p1(web istemcisi) adrese bir istek gönderir 10.50.200.10 . İlk olarak, veriler yönlendiriciye gider r1 daha doğrusu onun üzerine iç mekan arayüz 192.168.0.1 . Bundan sonra, yönlendirici kaynak adresini hatırlar (adres p1) ve özel bir tabloya girer NAT, ardından kaynak adresi kendi adresiyle değiştirir( p1 → r1). Ayrıca, göre harici arayüz, yönlendirici verileri doğrudan web sunucusuna gönderir p2. Web sunucusu verileri işler, bir yanıt oluşturur ve geri gönderir. Yönlendiriciye gönderir r1, dönüş adresinde olduğu için (yönlendirici adresi kendi adresi olarak değiştirdi). Yönlendirici veri alır, tabloya bakar NAT ve verileri düğüme gönderir p1. Yönlendirici burada bir aracı görevi görür.

Peki ya iç ağdaki birkaç düğüm aynı anda dış ağa erişirse? Yönlendirici, yanıtı kime geri göndereceğini nasıl anlayacak? ile bu sorun çözülür bağlantı noktaları. Yönlendirici, ana bilgisayar adresini kendi adresiyle değiştirdiğinde, bağlantı noktasını da değiştirir. İki düğüm İnternet'e erişirse, yönlendirici kaynak bağlantı noktalarını farklı. Ardından, web sunucusundan gelen paket yönlendiriciye geri geldiğinde, yönlendirici bu paketin atandığı bağlantı noktası tarafından anlayacaktır. Bir örnek aşağıdadır.

Teknolojiye Geri Dön WebRTC veya daha doğrusu, kullanan kısmına BUZ protokol (dolayısıyla buz adaylar). Düğüm p2 bir adayı vardır (ağdaki konumu - 10.50.200.10 ) ve düğüm p1 NAT'lı bir yönlendiricinin arkasında bulunan iki aday olacaktır - yerel ( 192.168.0.200 ) ve yönlendirici adayı ( 10.50.200.5 ). İlki yararlı değildir, ancak yine de oluşturulur, çünkü WebRTC henüz uzaktaki ana bilgisayar hakkında hiçbir şey bilmiyor - aynı ağda olabilir veya olmayabilir. İkinci aday işe yarayacak ve zaten bildiğimiz gibi liman önemli bir rol oynayacak (geçmek için) NAT).

Tablo girişi NAT yalnızca veriler dahili ağdan çıktığında üretilir. Bu nedenle, düğüm p1önce verileri iletmeli ve yalnızca bundan sonra düğümün verilerini iletmelidir p2 düğüme ulaşabilir p1.

pratikte her iki düğüm geride olacak NAT. Tabloda bir giriş oluşturmak için NAT her yönlendirici, düğümlerin uzaktaki düğüme bir şeyler göndermesi gerekir, ancak bu sefer ne birinci ikinciye ulaşabilir ne de tam tersi. Bunun nedeni, düğümlerin dışsal özelliklerini bilmemesidir. IP adresler ve dahili adreslere veri göndermek anlamsızdır.

Ancak harici adresler biliniyorsa bağlantı kolayca kurulacaktır. İlk düğüm, ikinci düğümün yönlendiricisine veri gönderirse, tablosundan bu yana yönlendirici bunları yok sayacaktır. NAT boşken. Ancak, tablodaki ilk düğümün yönlendiricisinde NAT bir kayda ihtiyaç vardı. Şimdi ikinci düğüm, birinci düğümün yönlendiricisine veri gönderirse, yönlendirici bunları başarılı bir şekilde ilk düğüme iletecektir. Şimdi tablo NAT ikinci yönlendirici ihtiyacınız olan verilere sahiptir.

Sorun şu ki, dış görünüşünüzü bilmek için IP adresi, ortak bir ağda bulunan bir düğüme ihtiyacınız var. Bu sorunu çözmek için doğrudan İnternete bağlı ek sunucular kullanılır. Onların yardımıyla tablodaki değerli kayıtlar da oluşturulur. NAT.

STUN ve TURN sunucuları

başlatma sırasında WebRTC mevcut sersemletmek Ve DÖNÜŞ olarak adlandıracağımız sunucular BUZ sunucular. Sunucular belirtilmemişse, o zaman yalnızca aynı ağdaki düğümler (ona bağlı olmadan NAT). Hemen belirtmek gerekir ki, 3g-ağlar kullanılmalıdır DÖNÜŞ sunucular.

sersemletmek sunucu basitçe, bir dönüş adresi, yani gönderenin ana bilgisayarının adresini döndüren İnternet'teki bir sunucudur. Yönlendiricinin arkasındaki düğüm erişir sersemletmek geçmek için sunucu NAT. gelen paket sersemletmek sunucu, kaynak adresi içerir - yönlendiricinin adresi, yani düğümümüzün harici adresi. Bu adres sersemletmek sunucu ve geri gönderir. Böylece, düğüm dışsallığını alır. IP ağdan erişilebildiği adres ve bağlantı noktası. Daha öte, WebRTC bu adresin kullanılması ek bir aday (harici yönlendirici adresi ve bağlantı noktası) oluşturur. Şimdi tabloda NAT yönlendirici, gerekli bağlantı noktasında yönlendiriciye gönderilen paketleri düğümümüze ileten bir girişe sahiptir.

Bu süreci bir örnekle inceleyelim.

Örnek (STUN sunucu işlemi)

sersemletmek sunucu şu şekilde gösterilir: s1. Yönlendirici, daha önce olduğu gibi, aracılığıyla r1 ve aracılığıyla düğüm p1. Ayrıca tabloyu takip etmeniz gerekecek NAT- olarak gösterelim r1_nat. Ayrıca, bu tablo genellikle farklı alt ağ düğümlerinden birçok giriş içerir - bunlar verilmeyecektir.

Yani, başlangıçta boş bir masamız var. r1_nat.

Tablo 2: Paket başlığı

Düğüm p1 bu paketi yönlendiriciye gönderir r1(nasıl olursa olsun, farklı alt ağlarda farklı teknolojiler kullanılabilir). Yönlendiricinin kaynak adresin yerine geçmesi gerekir kaynak IP, çünkü pakette belirtilen adres kesinlikle harici alt ağ için uygun değildir, üstelik bu aralıktaki adresler ayrılmıştır ve İnternette tek bir adres böyle bir adrese sahip değildir. Yönlendirici pakette bir ikame yapar ve tablosunda yeni bir giriş oluşturur. r1_nat. Bunu yapmak için bir port numarası bulması gerekiyor. Hatırlayın, bir alt ağdaki birkaç düğüm harici bir ağa erişebildiğinden, o zaman tabloda NAT yönlendiricinin sunucudan dönüş paketinin bu birkaç ana bilgisayardan hangisine gönderileceğini belirleyebilmesi için ek bilgilerin saklanması gerekir. Yönlendiricinin bir bağlantı noktası bulmasına izin verin 888 .

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

Tablo 4: Yeni bir girişle güncellenen NAT tablosu

Burada IP alt ağın adresi ve bağlantı noktası orijinal paketle tamamen aynıdır. Aslında, geri göndermede, onları tamamen geri yüklemenin bir yolunu bulmalıyız. IP harici ağın adresi, yönlendiricinin adresidir ve bağlantı noktası, yönlendirici tarafından icat edilenle değiştirilmiştir.

Düğümün bağlandığı gerçek bağlantı noktası p1 bir bağlantıyı kabul eder - bu, elbette, 35777 , ancak sunucu şuraya veri gönderir: hayali liman 888 , yönlendirici tarafından gerçek olarak değiştirilecek 35777 .

Böylece yönlendirici, paket başlığındaki kaynak adresi ve bağlantı noktasını değiştirmiş ve tabloya bir giriş eklemiştir. NAT. Artık paket ağ üzerinden sunucuya, yani düğüme gönderilir. s1. girişte, s1 bu pakete sahiptir:

kaynak IP	kaynak bağlantı noktası	Hedef IP	HEDEF LİMANI
10.50.200.5	888	12.62.100.200	6000

Tablo 5: STUN sunucusu bir paket aldı

Toplam sersemletmek sunucu, adresten bir paket aldığını bilir 10.50.200.5:888 . Şimdi sunucu bu adresi geri gönderir. Burada durup biraz önce ele aldığımız konuyu tekrar gözden geçirmeye değer. Yukarıdaki tablolar, başlık paket, hiç ondan değil içerik. İçerik hakkında konuşmadık, çünkü çok önemli değil - bir şekilde protokolde açıklanıyor sersemletmek. Şimdi başlığa ek olarak içeriği de ele alacağız. Basit olacak ve yönlendiricinin adresini içerecek - 10.50.200.5:888 ondan almış olmamıza rağmen başlık paket. Bu genellikle yapılmaz, genellikle protokoller düğümlerin adresleriyle ilgili bilgileri umursamaz, sadece paketlerin hedeflerine teslim edilmesi önemlidir. Burada iki düğüm arasında bir yol oluşturan bir protokolü ele alıyoruz.

Şimdi ters yönde giden ikinci bir grubumuz var:

Tablo 7: STUN sunucusu bu içeriğe sahip bir paket gönderir

Daha sonra paket, yönlendiricinin harici arayüzüne ulaşana kadar ağda dolaşır. r1. Yönlendirici, paketin kendisine yönelik olmadığını anlar. Bunu nasıl anlıyor? Bu sadece bağlantı noktası tarafından bulunabilir. Liman 888 kişisel amaçları için kullanmaz, mekanizma için kullanır NAT. Bu nedenle, yönlendirici bu tabloya bakar. sütuna bakar Harici PORT ve eşleşen bir dize arar HEDEF LİMANI gelen paketten, yani 888 .

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

Tablo 8: NAT tablosu

Böyle bir hat olduğu için şanslıyız. Şanslı olmasaydı, paket basitçe atılırdı. Şimdi, alt ağ düğümlerinden hangisinin bu paketi göndermesi gerektiğini anlamanız gerekiyor. Acele etmeyelim, portların bu mekanizmadaki önemini tekrar hatırlayalım. Aynı anda, alt ağdaki iki düğüm, dış ağa istek gönderebilir. Ardından, ilk düğüm için yönlendirici bir bağlantı noktası bulduysa 888 , sonra saniye için bir bağlantı noktası bulurdu 889 . Diyelim ki bu oldu, yani tablo r1_natöyle görünüyor:

Tablo 10: Yönlendirici sahtekarlığı alıcı adresi

kaynak IP	kaynak bağlantı noktası	Hedef IP	HEDEF LİMANI
12.62.100.200	6000	192.168.0.200	35777

Tablo 11: Yönlendirici, alıcı adresini değiştirdi

Paket başarıyla düğüme ulaşır p1 Düğüm, paketin içeriğine bakarak harici paketini öğrenir. IP adres, yani harici ağdaki yönlendiricinin adresi. Yönlendiricinin geçtiği bağlantı noktasını da bilir. NAT.

Sıradaki ne? Tüm bunların ne yararı var? Fayda tablodaki bir giriştir r1_nat. Şimdi herhangi biri yönlendiriciye gönderecekse r1 liman paketi 888 , ardından yönlendirici bu paketi ana bilgisayara iletir p1. Böylece gizli düğüme küçük dar bir geçit oluşturulmuştur. p1.

Yukarıdaki örnekten, nasıl çalıştığı hakkında bir fikir edinebilirsiniz. NAT ve öz sersemletmek sunucu. Genel olarak, mekanizma BUZ Ve ŞAŞIRMA/DÖNÜŞ sunucular sadece kısıtlamaların üstesinden gelmeyi amaçlamaktadır NAT.

Düğüm ile sunucu arasında birden fazla yönlendirici olabilir, ancak birkaç tane olabilir. Bu durumda düğüm, sunucuyla aynı ağa ilk giren yönlendiricinin adresini alacaktır. Başka bir deyişle, bağlı olduğumuz yönlendiricinin adresini alıyoruz. sersemletmek sunucu. İçin p2p iletişim tam ihtiyacımız olan şey, unutmazsak her yönlendiricide ihtiyacımız olan hattın tabloya ekleneceği NAT. Böylece dönüş yolu yine aynı pürüzsüzlükte olacak.

DÖNÜŞ sunucu geliştirildi sersemletmek sunucu. Bundan hemen şu sonuç çıkar ki, herhangi bir DÖNÜŞ sunucu çalışabilir ve nasıl sersemletmek sunucu. Bununla birlikte, faydaları da vardır. Eğer p2p iletişim mümkün değil (olduğu gibi 3g ağlar), ardından sunucu tekrarlayıcı moduna geçer ( röle), yani aracı olarak çalışır. Tabii ki, herhangi bir konuda p2p o zaman bu bir soru değil, mekanizma çerçevesinin dışında BUZ düğümler doğrudan iletişim kurduklarını düşünürler.

hangi durumlarda gerekli DÖNÜŞ sunucu? neden yeterli değil sersemletmek sunucular? Gerçek şu ki, birkaç tür var NAT. Aynısını değiştirirler IP adres ve bağlantı noktası, ancak bazılarının "sahteciliğe" karşı yerleşik ek koruması vardır. Örneğin, içinde simetrik masa NAT 2 parametre daha kaydedilir - IP ve uzak ana bilgisayarın bağlantı noktası. Harici ağdan bir paket geçer NAT yalnızca kaynak adresi ve bağlantı noktası tabloda kayıtlı olanlarla eşleşirse dahili ağa bağlanır. Bu nedenle odak sersemletmek sunucu başarısız - tablo NAT adresi ve bağlantı noktasını saklar sersemletmek sunucu ve yönlendirici bir paket aldığında WebRTC muhatap, "tahrif edilmiş" olduğu için onu atar. O gelmedi sersemletmek sunucu.

Böylece DÖNÜŞ her iki muhatap da gerideyken bir sunucuya ihtiyaç vardır simetrik NAT(her biri kendi başına).

Kısa özet

İşte varlıklar hakkında bazı ifadeler WebRTC ki bu her zaman akılda tutulmalıdır. Yukarıda ayrıntılı olarak açıklanmıştır. İfadelerden herhangi biri size tamamen açık gelmiyorsa, ilgili paragrafları tekrar okuyun.

• medya akışı
  • Video ve ses verileri medya akışlarına paketlenir
  • Medya akışları, oluşturan medya parçalarını senkronize eder.
  • Farklı medya akışları senkronize değil
  • Medya akışları yerel ve uzak olabilir, genellikle yerel olana bir kamera ve bir mikrofon bağlanır, uzak olanlar ağdan şifreli biçimde veri alır
  • İki tür medya izi vardır - video ve ses için.
  • Medya parçaları açma/kapama özelliğine sahiptir
  • Medya parçaları, medya kanallarından oluşur
  • Medya parçaları, oluşturan medya kanallarını senkronize eder
  • Medya akışları ve medya parçaları, ayırt edilebilecekleri etiketlere sahiptir.
• oturum tanıtıcısı
  • Oturum tanımlayıcısı, iki ağ düğümünü mantıksal olarak bağlamak için kullanılır.
  • Oturum tanımlayıcı, video ve ses verileri için mevcut kodlama yöntemleri hakkında bilgi depolar.
  • WebRTC harici bir sinyal mekanizması kullanır - oturum tanımlayıcılarını iletme görevi ( sdp) uygulamaya düşer
  • Mantıksal bağlantı mekanizması iki aşamadan oluşur - bir teklif ( teklif) ve yanıt ( cevap)
  • Bir teklif durumunda yerel bir medya akışı kullanılmadan oturum tanımlayıcısı oluşturmak mümkün değildir ( teklif) ve bir yanıt durumunda uzak oturum tanımlayıcısı kullanılmadan mümkün değildir ( cevap)
  • Ortaya çıkan tanımlayıcı uygulamaya verilmelidir. WebRTC ve bu tanıtıcının aynı uygulamadan uzaktan mı yoksa yerel olarak mı alındığı önemli değil WebRTC
  • Oturum tanımlayıcısını biraz düzenlemek mümkündür
• Adaylar
  • Aday ( buz adayı) ağdaki düğümün adresidir
  • Düğüm adresi size ait olabileceği gibi bir yönlendiricinin veya DÖNÜŞ sunucular
  • Her zaman birçok aday vardır
  • Aday oluşur IP adres, liman ve ulaşım türü ( TCP veya UDP)
  • Adaylar, bir ağdaki iki düğüm arasında fiziksel bir bağlantı kurmak için kullanılır.
  • Adayların ayrıca sinyalizasyon mekanizması aracılığıyla gönderilmesi gerekir.
  • Adayların ayrıca uygulamaları geçmesi gerekir WebRTC, ancak yalnızca uzak
  • Bazı uygulamalarda WebRTC Adaylar yalnızca oturum tanımlayıcısı ayarlandıktan sonra geçebilir
• SERBESTLEŞTİRME/DÖNÜŞ/BUZ/NAT
  • NAT– harici bir ağa erişim sağlamak için bir mekanizma
  • Ev yönlendiricileri özel bir tabloyu destekler NAT
  • Yönlendirici, paketlerdeki adresleri değiştirir - paket harici ağa gidiyorsa kaynak adres kendi adresiyle ve paket harici ağdan geliyorsa hedef adres dahili ağdaki ana bilgisayar adresiyle değiştirir
  • Harici bir ağa çok kanallı erişim sağlamak için NAT bağlantı noktalarını kullanır
  • BUZ- baypas mekanizması NAT
  • sersemletmek Ve DÖNÜŞ sunucular - atlamak için yardımcı sunucular NAT
  • sersemletmek sunucu, tabloda gerekli girişleri oluşturmanıza izin verir NAT ve ayrıca düğümün harici adresini döndürür
  • DÖNÜŞ sunucu genelleştirir sersemletmek mekanizma ve her zaman çalışmasını sağlar
  • En kötü durumlarda DÖNÜŞ sunucu bir aracı olarak kullanılır ( röle), yani p2p istemci-sunucu-istemci bağlantısına dönüşür.

Avrupalı ​​İnternet kullanıcıları ikiye ayrılıyor: Allenbach'taki (Almanya) Kamuoyu Analizi Enstitüsü tarafından yapılan bir ankete göre, Skype, sohbet ve anlık mesajlaşma sistemleri 16,5 milyon yetişkin ve çocuk, 9 milyon bu hizmetleri tek tek kullanın ve 28 milyon kişi bunlara dokunmayın.

Durum değişebilir, çünkü artık Firefox entegre edilmiştir gerçek zamanlı iletişim teknolojisi (WebRTC), hem de müşterinin kendisi. Sesli ve görüntülü sohbet başlatmak artık bir web sitesi açmaktan daha zor değil. Facebook ve Skype gibi hizmetler ise ayrı bir müşteri kullanarak ve bir hesap oluşturarak çözümlere dayanır.

WebRTC'nin kullanımı sadece kolay değildir. Bu yöntem, ayarlamanıza bile izin verir. iki tarayıcı arasında doğrudan bağlantı. Bu şekilde, ses ve video verileri, tıkanıklığın oluşabileceği veya yöneticinin gizlilik veya veri koruması konusunda özellikle hassas olmadığı bir sunucudan geçmez. Doğrudan bağlantı ile WebRTC, herhangi bir hizmette kayıt veya hesap gerektirmez.

Sohbet başlatmak için sadece bağlantıyı takip etmeniz yeterlidir. İletişim gizli kalırçünkü veri akışı şifrelenmiştir. Tarayıcı üzerinden gerçek zamanlı iletişim, Google, WebRTC uygulamasının kaynak kodunu yayınladığı 2011 yılında aktif olarak devreye girmeye başladı.

Kısa bir süre sonra, Chrome ve Firefox kendi WebRTC motorlarını aldı. Şu anda, mobil versiyonları hem bu teknoloji hem de uygulamalar tarafından kullanılan Android 5.0 yüklü WebView 3.6 motoru ile donatılmıştır.

Gerçek zamanlı iletişim için, web görüntüleyicide uygun JavaScript arayüzleri uygulanmalıdır. GetUserMedia ile yazılım, ses ve video kaynaklarından, yani web kamerası ve mikrofondan yakalama sağlar. RTCPeerConnection, iletişimin kendisinin yanı sıra bağlantının kurulmasından da sorumludur.

Tarayıcı entegrasyonuna paralel olarak, World Wide Web Konsorsiyumu (W3C) çalışma grubu, WebRTC standardizasyon sürecini zorlamaktadır. 2015 yılında tamamlanması gerekmektedir.

WebRTC çok az şeyle yetiniyor

Sunucu yalnızca arkadaşları birbirine bağladığından, WebRTC hizmetini kullanmak çok fazla kaynak gerektirmez. Bir bağlantı kurmak da özellikle zor değil. İlk olarak, tarayıcı WebRTC sunucusuna bir çağrı başlatmayı planladığını bildirir. Sunucudan bir HTTPS bağlantısı alır - bağlantı şifrelenir. Kullanıcı bu bağlantıyı muhatabına gönderir. Tarayıcı daha sonra kullanıcıdan web kamerasına ve mikrofona erişim izni ister.

Karşı tarafla doğrudan akış bağlantısı kurmak için tarayıcı, IP adresini ve yapılandırma verilerini WebRTC hizmetinden alır. Arkadaşın web tarayıcısı da aynısını yapar.

Akış bağlantısının sorunsuz ve kaliteli çalışması için tarayıcıda üç motor çalışır. İkisi ses ve video verilerini optimize eder ve sıkıştırır, üçüncüsü bunların taşınmasından sorumludur. aracılığıyla veri gönderir SRTP protokolü(Güvenli Gerçek Zamanlı Aktarım Protokolü), gerçek zamanlı şifrelenmiş akışa izin verir.

Doğrudan bağlantı başarısız olursa, WebRTC başka bir yol arar. Örneğin bu, ağ ayarları STUN sunucusunun IP adresini bildirmesini engellediğinde olur. WebRTC standardı, bu durumda konuşmanın gerçekleşeceğini, ancak TURN sunucusunun ara dahil edilmesiyle (NAT Etrafında Aktarma Kullanarak Geçiş) yapılmasını şart koşar. Böylece, netscan.co web sitesinde, WebRTC'nin bilgisayarınızda uygulanıp uygulanmadığını ve Web'e erişiminizle kontrol edebilirsiniz.

bağlantı nasıl yapılır

Öncelikle bir görüşme kaydetmeniz gerekir (1). WebRTC hizmeti, muhataplara gönderilmesi gereken bir bağlantı sağlar. Tarayıcı, STUNserver'ı kullanarak kendi IP adresini bulur (2), bunu hizmete gönderir ve doğrudan bağlantı kurmak için ortağın IP'sini alır (3). STUN başarısız olursa, görüşme TURNserver (4) kullanılarak yeniden yönlendirilir.

Tarayıcıda WebRTC teknolojisini kullanan iletişim, JavaScript kodu kullanılarak başlatılır. Bundan sonra, iletişimden üç motor sorumludur: ses ve video motorları, web kamerası ve mikrofondan multimedya verilerini toplar ve aktarım motoru, bilgileri birleştirir ve Güvenli Gerçek Zamanlı Protokolü (SRTP) kullanarak akışı şifrelenmiş biçimde gönderir.

Hangi tarayıcılar WebRTC ile çalışır?

Chrome ve Firefox, talky.io gibi hizmetleri kullanan bir WebRTC motoruyla donatılmıştır. Mozilla tarayıcısı doğrudan kendi istemcisiyle çalışabilir.

Google ve Mozilla, gerçek zamanlı iletişim fikrini geliştirmeye devam ediyor: Chrome, birden fazla katılımcının yer aldığı bir WebRTC konferansına ev sahipliği yapabilir ve Firefox'taki yeni Hello istemcisi, telekomünikasyon devi Telefonica'nın bir yan kuruluşunun yardımıyla geliştirildi. Apple şimdilik kenarda kalıyor, henüz WebRTC'yi Safari'de beklememelisiniz. Ancak, Safari için pek çok alternatif iOS uygulaması ve eklentisi var.

Microsoft biraz farklı bir yol izliyor. Rekabetçi Skype hizmetinin sahibi olarak bu şirket, WebRTC'ye o kadar kolay teslim olmayacak. Bunun yerine Microsoft, Internet Explorer için ORTC (Object Real-Time Communications) adlı bir teknoloji geliştiriyor.

Sunucuyla bağlantı kurmak için farklı codec'ler ve protokoller gibi WebRTC'den farklılıklar küçüktür ve zaman içinde büyük olasılıkla bu farklılıkları içerecek olan WebRTC standardına ek olacaktır. Böylece, her zamanki gibi sadece Apple geride kalır.

Fotoğraf:Üretim şirketleri; goodluz/Photolia.com

Tarayıcıdan arama yapmak için kullanılan teknolojiler çok eskidir: Java, ActiveX, Adobe Flash... Son birkaç yılda, eklentilerin ve sol sanal makinelerin rahatlıkla parlamadığı ortaya çıktı (neden tümü?) ve en önemlisi güvenlik . Ne yapalım? Bir çıkış var!

Yakın zamana kadar, IP telefon veya video için IP ağlarında birkaç protokol kullanılmıştır: Sahneden çıkan en yaygın protokol olan SIP, H.323 ve MGCP, Jabber/Jingle (Gtalk'ta kullanılır), yarı açık Adobe RTMP* ve tabii ki kapalı Skype. Google tarafından başlatılan WebRTC projesi, Skype dahil tüm yazılım telefonlarını eski hale getirerek IP ve web telefonu dünyasını değiştirmeye çalışıyor. WebRTC, artık hemen hemen her cihazda yüklü olan tarayıcının tüm iletişim yeteneklerini doğrudan uygulamakla kalmıyor, aynı zamanda tarayıcı kullanıcıları arasındaki daha genel bir iletişim görevini de çözmeye çalışıyor (çeşitli verilerin alışverişi, ekran yayını, belgelerle işbirliği ve daha fazla).

Bir web geliştiricisi tarafından WebRTC

Bir web geliştiricisinin bakış açısından, WebRTC iki ana bölümden oluşur:

• yerel kaynaklardan (kamera, mikrofon veya yerel bilgisayar ekranı) medya akışlarının yönetimi, bir MediaStream nesnesi döndüren navigator.getUserMedia yöntemi tarafından gerçekleştirilir;
• iletişim yöntemlerinin tanımı ve bunların doğrudan iletimi dahil olmak üzere medya akışları oluşturan cihazlar arasında eşler arası iletişim - RTCPeerConnection nesneleri (ses ve video akışları göndermek ve almak için) ve RTCDataChannel (tarayıcıdan veri göndermek ve almak için).

Biz ne yaptık?

Web soketlerini kullanarak WebRTC'ye dayalı tarayıcılar arasında en basit çok oyunculu görüntülü sohbeti nasıl organize edeceğimizi bulacağız. WebRTC açısından en gelişmiş tarayıcılar olan Chrome/Chromium'da denemelere başlayalım, ancak 24 Haziran'da yayınlanan Firefox 22 onları neredeyse yakaladı. Standardın henüz benimsenmediği ve API'nin sürümden sürüme değişebileceği söylenmelidir. Tüm örnekler Chromium 28'de test edilmiştir. Basitlik açısından kodun temizliğini ve tarayıcılar arası uyumluluğu izlemeyeceğiz.

medya akışı

İlk ve en basit WebRTC bileşeni MediaStream'dir. Tarayıcıya, yerel bilgisayarın kamera ve mikrofonundan medya akışlarına erişim sağlar. Chrome'da bu, navigator.webkitGetUserMedia() işlevinin çağrılmasını gerektirir (çünkü standart henüz sonlandırılmamıştır, tüm işlevler bir önekle gelir ve Firefox'ta aynı işlev navigator.mozGetUserMedia() olarak adlandırılır). Çağrıldığında, kullanıcıdan kamera ve mikrofona erişime izin vermesi istenecektir. Aramaya ancak kullanıcı onay verdikten sonra devam etmek mümkün olacaktır. Gerekli ortam akışının parametreleri ve iki geri arama işlevi, bu işleve parametre olarak iletilir: birincisi, kameraya/mikrofona başarılı erişim durumunda, ikincisi ise bir hata durumunda çağrılır. İlk olarak, bir düğme ve bir öğe içeren bir HTML dosyası rtctest1.html oluşturalım.

getUserMedia

Microsoft CU-RTC-Web

Microsoft, Google'ın girişimine yanıt olarak CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Zaten küçük olan IE'nin payı düşmeye devam etse de Skype kullanıcılarının sayısı Microsoft'a Google'ı zorlama umudu veriyor ve bu standardın Skype'ın tarayıcı versiyonunda kullanılacağı varsayılabilir. Google standardı öncelikle tarayıcıdan tarayıcıya iletişime odaklanır; aynı zamanda, ses trafiğinin büyük kısmı hala geleneksel telefon ağında kalıyor ve onunla IP ağları arasındaki ağ geçitlerine yalnızca kullanım kolaylığı veya daha hızlı dağıtım için değil, aynı zamanda daha fazla oyuncunun izin verecek bir para kazanma aracı olarak da ihtiyaç duyuluyor. onları geliştir Başka bir standardın ortaya çıkması, geliştiricilerin aynı anda iki uyumsuz teknolojiyi desteklemesi için hoş olmayan bir ihtiyaca yol açmaz, aynı zamanda gelecekte kullanıcıya daha geniş bir olası işlevsellik seçeneği ve mevcut teknik çözümler sunar. Bekle ve gör.

Yerel iş parçacığını etkinleştir

İç etiketler HTML dosyamızda medya akışı için global bir değişken tanımlayalım:

VarlocalStream = boş;

getUserMedia yönteminin ilk parametresi, istenen medya akışının parametrelerini belirtmektir - örneğin, sadece ses veya videoyu etkinleştirin:

Var streamConstraints = ("ses": doğru, "video": doğru); // Hem sese hem de videoya erişim iste

Veya ek seçenekler belirtin:

Var streamConstraints = ("audio": true, "video": ("zorunlu": ("maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" ), "opsiyonel": ) );

getUserMedia yönteminin ikinci parametresi, başarılı olursa çağrılacak bir geri çağırma işlevini iletmektir:

function getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Medya akışını HTML öğesine ekle

Üçüncü parametre, bir hata durumunda çağrılacak bir hata işleyici olan bir geri arama işlevidir.

getUserMedia_error(error) işlevi ( console.log("getUserMedia_error():", error); )

GetUserMedia yöntemine gerçek çağrı - ilk düğmeye basıldığında mikrofona ve kameraya erişim talep ediyor

getUserMedia_click() işlevi ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); )

Yerel olarak açılan bir dosyadan medya akışına erişmek mümkün değildir. Bunu yapmaya çalışırsak, bir hata alırız:

NavigatorUserMediaError (kod: 1, PERMISSION_DENIED: 1)"

Ortaya çıkan dosyayı sunucuya yükleyelim, tarayıcıda açalım ve gelen talebe cevaben kamera ve mikrofona erişime izin verelim.

Chrome'un hangi cihazlara erişeceğini Ayarlar, Gelişmiş ayarları göster bağlantısı, Gizlilik bölümü, İçerik düğmesinden seçebilirsiniz. Firefox ve Opera tarayıcılarında, erişim verildiğinde cihazlar doğrudan açılır listeden seçilir.

HTTP protokolünü kullanırken, sayfa yüklendikten sonra bir medya akışına her erişildiğinde izin istenir. HTTPS'ye geçmek, isteği yalnızca medya akışına ilk erişimde bir kez görüntülemenize olanak tanır.

Sekmedeki simgedeki titreşimli daireye ve adres çubuğunun sağ tarafındaki kamera simgesine dikkat edin:

RTCMedya Bağlantısı

RTCMediaConnection - katılımcılar arasında ağ üzerinden medya akışları oluşturmak ve aktarmak için tasarlanmış bir nesne. Ek olarak, bu nesne bir medya oturum açıklaması (SDP) oluşturmaktan, NAT veya güvenlik duvarlarından (yerel ve STUN kullanarak) geçmek için ICE adayları hakkında bilgi edinmekten ve TURN sunucusuyla etkileşim kurmaktan sorumludur. Her katılımcı, bağlantı başına bir RTCMediaConnection'a sahip olmalıdır. Medya akışları, şifrelenmiş SRTP protokolü üzerinden iletilir.

TURN sunucuları

Üç tür ICE adayı vardır: ana bilgisayar, srflx ve geçiş. Ana bilgisayar, yerel olarak elde edilen bilgileri içerir, srflx, ana bilgisayarın harici bir sunucuya (STUN) nasıl göründüğüdür ve röle, TURN sunucusu üzerinden proxy trafiği için bilgidir. Düğümümüz bir NAT'ın arkasındaysa, ana bilgisayar adayları yerel adresler içerecek ve işe yaramaz olacak, srflx adayları yalnızca belirli NAT türlerinde yardımcı olacak ve geçiş, trafiği bir ara sunucudan geçirmek için son umut olacaktır.

192.168.1.37 adresine ve udp/34022 bağlantı noktasına sahip ana bilgisayar türünde bir ICE adayı örneği:

A=candidate:337499441 2 udp 2113937151 192.168.1.37 34022 tipik ana bilgisayar üretimi 0

STUN/TURN sunucularını belirtmek için genel format:

Var sunucuları = ("iceServers": [ ("url": "stun:stun.stunprotocol.org:3478" ), ("url": "turn: [e-posta korumalı]:bağlantı noktası", "kimlik bilgisi": "şifre" ) ​​]);

İnternette birçok genel STUN sunucusu vardır. Örneğin, büyük bir liste . Ne yazık ki, sorunların çok azını çözüyorlar. STUN'dan farklı olarak, neredeyse hiç halka açık TURN sunucusu yoktur. Bunun nedeni, TURN sunucusunun hem ağ kanalını hem de sunucunun kendisini önemli ölçüde yükleyebilen medya akışlarını kendi içinden geçirmesidir. Bu nedenle, TURN sunucularına bağlanmanın en kolay yolu, onu kendiniz kurmaktır (belli ki, genel bir IP'ye ihtiyacınız olacak). Tüm sunucular arasında bence en iyisi rfc5766-turn-server . Altında Amazon EC2 için hazırlanmış bir görsel bile var.

TURN ile her şey istediğimiz kadar iyi değil, ancak aktif geliştirme devam ediyor ve bir süre sonra WebRTC'nin adres çevirisinden geçme kalitesi açısından Skype'a yetişemezse ( NAT) ve güvenlik duvarları, o zaman en azından fark edilir şekilde yaklaşır.

RTCMediaConnection, bir bağlantı kurmak için kontrol bilgilerinin değiş tokuşu için ek bir mekanizmaya ihtiyaç duyar - bu verileri oluşturmasına rağmen iletmez ve diğer katılımcılar tarafından iletilmesi ayrıca gerçekleştirilmelidir.

İletim yönteminin seçimi geliştiricinin sorumluluğundadır - en azından manuel olarak. Gerekli veriler değiş tokuş edilir edilmez, RTCMediaConnection medya akışlarını otomatik olarak kuracaktır (elbette mümkünse).

teklif-cevap modeli

Medya akışlarını oluşturmak ve değiştirmek için teklif / yanıt modeli (teklif / yanıt; RFC3264'te açıklanmıştır) ve SDP protokolü (Oturum Açıklama Protokolü) kullanılır. SIP protokolü tarafından da kullanılırlar. Bu modelde, iki aracı ayırt edilir: Teklif Veren - yeni bir tane oluşturmak veya mevcut olanı değiştirmek için bir SDP oturum açıklaması oluşturan kişi (SDP Teklif Edin) ve Yanıtlayan - başka bir aracıdan bir SDP oturum açıklaması alan ve yanıt veren kişi kendi oturum açıklamasıyla (Cevap SDP). Aynı zamanda, spesifikasyon, ajanlar arasında SDP aktarımından sorumlu olan daha yüksek seviyeli bir protokol (örneğin, SIP veya bizim durumumuzda olduğu gibi kendi web soketleri) gerektirir.

Başarılı bir şekilde medya akışları oluşturabilmeleri için iki RTCMediaConnection arasında hangi verilerin iletilmesi gerekir:

• Bağlantıyı başlatan birinci taraf, iletmeye başlamak üzere olduğu medya akışının olası özelliklerini açıklayan bir SDP veri yapısını (SIP'de aynı amaç için aynı protokol kullanılır) ilettiği bir Teklif oluşturur. Bu veri bloğu ikinci katılımcıya aktarılmalıdır. İkinci katılımcı, SDP'si ile bir Yanıt oluşturur ve bunu birinciye gönderir.
• Hem birinci hem de ikinci katılımcılar, ikinci katılımcının medya akışını kendilerine aktarabileceği olası ICE adaylarını belirleme prosedürünü gerçekleştirir. Adaylar belirlendikçe, onlar hakkındaki bilgiler başka bir katılımcıya aktarılmalıdır.

Teklif Oluşturma

Teklif oluşturmak için iki fonksiyona ihtiyacımız var. Başarılı oluşumu durumunda ilki çağrılacaktır. createOffer() yönteminin ikinci parametresi, yürütme sırasında bir hata olması durumunda çağrılan bir geri arama işlevidir (yerel akışın zaten mevcut olması koşuluyla).

Ek olarak, iki olay işleyiciye ihtiyaç vardır: yeni bir ICE adayı tanımlarken onicecandidate ve uzak taraftan bir medya akışını bağlarken onaddstream. Dosyamıza geri dönelim. Öğeleri olan satırlardan sonra HTML'ye ekle bir tane daha:

teklif oluştur

Ve elemanın bulunduğu satırdan sonra

Ayrıca, JavaScript kodunun başında, RTCPeerConnection için global bir değişken bildireceğiz:

varpc1;

RTCPeerConnection yapıcısını çağırırken, STUN/TURN sunucularını belirtmeniz gerekir. Daha fazla ayrıntı için kenar çubuğuna bakın; tüm katılımcılar aynı ağda olduğu sürece gerekli değildir.

var sunucular = null;

SDP Teklifi Hazırlama Seçenekleri

var teklifKısıtlamalar = ();

createOffer() yönteminin ilk parametresi, bir Teklifin başarılı bir şekilde oluşturulması üzerine çağrılan bir geri arama işlevidir.

function pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // SDP setLocalDescription yöntemini sunun. // Uzak taraf Cevap SDP'sini gönderdiğinde, setRemoteDescription yöntemi kullanılarak ayarlanması gerekir // İkinci taraf uygulanana kadar hiçbir şey yapmayın // pc2_requiredOffer(desc); )

İkinci parametre, bir hata durumunda çağrılacak bir geri arama işlevidir.

işlev pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): error:", error); )

Ve tanımlandıkları gibi ICE adaylarına iletilecek bir geri arama işlevi ilan edeceğiz:

işlev pc1_onicecandidate(event)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // İkinci taraf uygulanana kadar hiçbir şey yapmayın // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

Uzak taraftan bir medya akışı eklemek için bir geri arama işlevinin yanı sıra (şimdiye kadar yalnızca bir RTCPeerConnection'a sahip olduğumuz için gelecek için):

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

“createOffer” butonuna tıkladığınızda bir RTCPeerConnection oluşturun, onicecandidate ve onaddstream metotlarını ayarlayın ve createOffer() metodunu çağırarak Offer SDP oluşturulmasını isteyin:

function createOffer_click() ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // Bir RTCPeerConnection oluşturun pc1.onicecandidate = pc1_onicecandidate; // ICE adaylarını işlemek için geri çağırma işlevi pc1.onaddstream = pc1_onaddstream; / / Geri arama işlevi, uzak taraftan bir medya akışı olduğunda çağrılır, henüz mevcut değildir pc1.addStream(localStream); // Yerel medya akışını geçirin (önceden alındığını varsayarak) pc1.createOffer(// Ve aslında Teklifin oluşturulmasını isteyin pc1_createOffer_success , pc1_createOffer_error, OfferConstraints); )

Dosyayı rtctest2.html olarak kaydedelim, sunucuya koyalım, bir tarayıcıda açalım ve çalışması sırasında hangi verilerin üretildiğini konsolda görelim. Sadece bir katılımcı olduğu için ikinci video henüz görünmeyecek. SDP'nin medya oturum parametrelerinin bir açıklaması olduğunu, mevcut codec'lerin, medya akışlarının ve ICE adaylarının bu katılımcıya bağlanmak için olası seçenekler olduğunu hatırlayın.

Cevap SDP'nin oluşturulması ve ICE adaylarının değişimi

Hem Offer SDP'si hem de ICE adaylarının her biri diğer tarafa geçirilmelidir ve orada, RTCPeerConnection'dan bunları aldıktan sonra, uzak taraftan alınan her ICE adayı için Offer SDP ve addIceCandidate için setRemoteDescription yöntemlerini çağırın; Yanıt SDP ve uzak ICE adayları için benzer şekilde tersi. Yanıt SDP'sinin kendisi Teklife benzer şekilde oluşturulmuştur; fark, createOffer yönteminin değil, createAnswer yönteminin çağrılmasıdır ve bu RTCPeerConnection'dan önce setRemoteDescription yöntemi, arayandan alınan Offer SDP'yi iletir.

HTML'ye başka bir video öğesi ekleyelim:

Ve birincisinin bildirimi altında ikinci RTCPeerConnection için genel bir değişken:

Varpc2;

Teklif ve Cevap SDP'si İşleniyor

Bir Yanıt Oluşturma SDP, bir Teklife çok benzer. Yanıtın başarılı bir şekilde oluşturulması üzerine çağrılan geri arama işlevinde, Teklife benzer şekilde, yerel bir açıklama vereceğiz ve alınan Yanıt SDP'sini ilk katılımcıya ileteceğiz:

pc2_createAnswer_success(desc) işlevi ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )

Cevap oluşturulurken bir hata olması durumunda çağrılan geri arama fonksiyonu Teklif ile tamamen benzerdir:

pc2_createAnswer_error(error) işlevi ( console.log("pc2_createAnswer_error():", error); )

Yanıt SDP'si oluşturmak için parametreler:

Var answerConstraints = ("zorunlu": ("OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );

İkinci katılımcı bir Teklif aldığında, bir RTCPeerConnection oluşturun ve Teklifle aynı şekilde bir Yanıt oluşturun:

function pc2_requiredOffer(desc) ( console.log("pc2_receiveOffer()", desc); // İkinci katılımcı için birinciye benzer bir RTCPeerConnection nesnesi oluşturun pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onicecandidate; // Set ICE adayı olduğunda olay işleyicisi pc2.onaddstream = pc_onaddstream; // Bir akış göründüğünde, onu HTML'ye bağlayın

İlk katılımcıdan ikinci katılımcıya Offer SDP'sini aktarmak için örneğimizin bir parçası olarak pc1 işlevinde açıklamayı kaldırın. teklif oluştur başarı() çağrı dizesi:

Pc2_requiredOffer(azalan);

ICE adaylarının işlenmesini uygulamak için, birinci katılımcı pc1_onicecandidate()'in ICE aday hazır olma olay işleyicisindeki yorumunu ikinciye iletimini kaldırın:

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

İkinci katılımcının ICE adayı hazırlık olay işleyicisi, birinci katılımcının aynası gibidir:

pc2_onicecandidate(event) işlevi ( if (event.candidate) ( console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

İlk katılımcıdan bir medya akışı eklemek için geri arama işlevi:

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

bir bağlantıyı sonlandırmak

HTML'de başka bir düğme ekleyelim

telefonu kapatmak

Ve bağlantıyı sonlandırmak için bir işlev

btnHangupClick() işlevi ( // Yerel videoyu HTML öğelerinden devre dışı bırak

rtctest3.html olarak kaydedip sunucuya atalım ve tarayıcıda açalım. Bu örnek, aynı tarayıcı sekmesinde iki RTCPeerConnection arasında iki yönlü medya akışını uygular. Katılımcılar arasında Teklif ve Cevap SDP, ICE adayları ve ağ aracılığıyla diğer bilgiler alışverişini organize etmek için, doğrudan arama yapmak yerine, bizim durumumuzda web soketleri gibi bir tür aktarım kullanarak katılımcılar arasındaki alışverişi gerçekleştirmek gerekli olacaktır. prosedürler.

Ekran Yayını

getUserMedia işleviyle, aşağıdaki parametreleri belirterek ekranı yakalayabilir ve bir MediaStream olarak yayınlayabilirsiniz:

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

Ekrana başarılı erişim için birkaç koşulun karşılanması gerekir:

• chrome://flags/,chrome://flags/ içinde getUserMedia() içinde ekran görüntüsü işaretini etkinleştir;
• kaynak dosya HTTPS (SSL kaynağı) aracılığıyla indirilmelidir;
• ses akışı talep edilmemelidir;
• aynı tarayıcı sekmesinde birden fazla istek yapılmamalıdır.

WebRTC için kitaplıklar

WebRTC henüz tamamlanmamış olsa da, buna dayalı birkaç kitaplık zaten ortaya çıktı. JsSIP, Asterisk ve Camalio gibi SIP anahtarlarıyla çalışan tarayıcı tabanlı yazılım telefonları oluşturmak için tasarlanmıştır. PeerJS, veri alışverişi için P2P ağlarının oluşturulmasını basitleştirecek ve Holla, tarayıcılardan P2P iletişimi için gereken geliştirme miktarını azaltacaktır.

Node.js ve socket.io

Ağ üzerinden iki RTCPeerConnection arasında SDP ve ICE adaylarının değişimini organize etmek için socket.io modülü ile Node.js kullanıyoruz.

Node.js'nin (Debian/Ubuntu için) en son kararlı sürümünün yüklenmesi anlatılmaktadır.

$ sudo apt-get install python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get update $ sudo apt-get install nodejs

Diğer işletim sistemleri için kurulum açıklanmıştır

Hadi kontrol edelim:

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

npm (Düğüm Paket Yöneticisi) kullanarak socket.io'yu ve ek ekspres modülü kurun:

$ npm install socket.io ekspres

Sunucu tarafı için bir nodetest2.js dosyası oluşturarak kontrol edelim:

$ nano nodetest2.js var uygulama = gerekli("express")() , sunucu = gerekli("http").createServer(uygulama) , io = gerekli("socket.io").listen(sunucu); server.listen(80); // Port 80 ücretsiz ise app.get("/", function (req, res) ( // Kök sayfaya erişirken res.sendfile(__dirname + "/nodetest2.html"); // HTML dosyasını ver ) ) ; io.sockets.on("connection", function (socket) ( // Bağlantıda socket.emit("server event", ( merhaba: "world" )); // mesaj gönder socket.on("client event", function (data) ( // ve istemciden bir mesaj geldiğinde bir olay işleyici bildirir console.log(data); )); ));

Ve müşteri tarafı için nodetest2.html:

$nano nodetest2.html

Sunucuyu başlatalım:

$ sudo nodejs nodetest2.js

ve bir tarayıcıda http://localhost:80 sayfasını açın (yerel olarak 80 numaralı bağlantı noktasında çalışıyorsa). Her şey başarılıysa, tarayıcının JavaScript konsolunda, bağlantı kurulduğunda tarayıcı ile sunucu arasındaki olay alışverişini göreceğiz.

Web soketleri aracılığıyla RTCPeerConnection arasında bilgi alışverişi

İstemci tarafı

Ana örneğimizi (rtcdemo3.html) rtcdemo4.html yeni adı altında kaydedelim. Socket.io kitaplığını öğeye dahil edin:

Ve JavaScript betiğinin başında - web soket bağlantısı:

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

Başka bir katılımcının işlevlerine yapılan doğrudan aramayı, ona web soketleri aracılığıyla bir mesaj göndererek değiştirelim:

function createOffer_success(desc) ( ... // pc2_requiredOffer(desc); socket.emit("offer", desc); ... ) function pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); soket .emit("cevap", açıklama); ) function pc1_onicecandidate(event) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); .. . ) function pc2_onicecandidate(event) ( ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... )

Hangup() işlevinde, ikinci katılımcının işlevlerini doğrudan çağırmak yerine, web soketleri aracılığıyla bir mesaj göndereceğiz:

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

Ve mesaj alma işleyicileri ekleyin:

Socket.on("teklif", işlev (veri) ( console.log("socket.on("teklif"):", veri); pc2_requiredOffer(veri); )); socket.on("cevap", işlev (veri) (e console.log("socket.on("answer"):", veri); pc1.setRemoteDescription(new RTCSessionDescription(data)); )); socket.on("ice1", function (veri) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(veri)); )); socket.on("ice2", function (veri) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(veri)); )); socket.on("kapatma", işlev (veri) ( console.log("socket.on("kapatma")):", veri); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Sunucu bölümü

Sunucu tarafında, nodetest2 dosyasını rtctest4.js yeni adı altında kaydedin ve io.sockets.on("connection", function (socket) ( ... ) işlevinin içine istemci mesajlarının alınmasını ve gönderilmesini ekleyin:

Socket.on("offer", function (data) ( // Bir "teklif" mesajı alındığında, // bu örnekte sadece bir istemci bağlantısı olduğu için, // mesajı aynı soket üzerinden geri gönderin socket.emit( "teklif" , veri); // Mesajı gönderen hariç tüm bağlantılarda iletmek gerekirse //: // socket.broadcast.emit("teklif", veri); )); socket.on("cevap", işlev (veri) ( socket.emit("cevap", veri); )); socket.on("ice1", function (veri) ( socket.emit("ice1", data); )); socket.on("ice2", function (veri) ( socket.emit("ice2", data); )); socket.on("kapatma", işlev (veri) ( socket.emit("kapatma", veri); ));

Ek olarak, HTML dosyasının adını değiştirin:

// res.sendfile(__dirname + "/nodetest2.html"); // HTML dosyasını gönder res.sendfile(__dirname + "/rtctest4.html");

Sunucu başlangıcı:

$ sudo nodejs nodetest2.js

Her iki istemcinin kodu aynı tarayıcı sekmesinde çalışmasına rağmen, örneğimizde katılımcılar arasındaki tüm etkileşim tamamen ağ üzerinden gerçekleştirilir ve katılımcıları "yaymak" artık zor değildir. Ancak bizim yaptığımız da çok basitti - bu teknolojiler kullanım kolaylığı açısından iyidir. Bazen aldatıcı olsa da. Özellikle, STUN/TURN sunucuları olmadan örneğimizin adres çevirisi ve güvenlik duvarları varlığında çalışamayacağını unutmayalım.

Çözüm

Ortaya çıkan örnek çok koşulludur, ancak olay işleyicilerini pc1 ve pc2 olmak üzere iki nesne yerine çağıran ve aranan taraflar arasında farklılık göstermeyecek şekilde biraz evrenselleştirirsek, bir RTCPeerConnection dizisi oluşturun ve öğelerin dinamik olarak oluşturulmasını ve silinmesini gerçekleştirin

WebRTC sayesinde çok yakında sadece sesli ve görüntülü iletişim anlayışımızda değil, interneti bir bütün olarak algılama şeklimizde de bir devrim olacağı varsayılabilir. WebRTC, yalnızca tarayıcıdan tarayıcıya çağrı teknolojisi olarak değil, aynı zamanda gerçek zamanlı bir iletişim teknolojisi olarak da konumlandırılmıştır. Analiz ettiğimiz görüntülü iletişim, kullanımı için olası seçeneklerin yalnızca küçük bir kısmıdır. Halihazırda ekran paylaşımı (ekran paylaşımı) ve işbirliği örnekleri ve hatta RTCDataChannel kullanan tarayıcı tabanlı bir P2P içerik dağıtım ağı var.

WebRTC (Web Gerçek Zamanlı İletişim), akışlı ses verilerinin, video verilerinin ve içeriğin tarayıcıdan ve tarayıcıya eklentiler veya başka uzantılar kurulmadan gerçek zamanlı olarak aktarılmasını açıklayan bir standarttır. Standart, tarayıcıyı bir video konferans terminaline dönüştürmenize izin verir, iletişimi başlatmak için bir web sayfası açmanız yeterlidir.

WebRTC nedir?

Bu yazıda, ortalama bir kullanıcı için WebRTC teknolojisi hakkında bilinmesi gereken her şeyi ele alacağız. Projenin avantaj ve dezavantajlarını ele alalım, bazı sırları açığa çıkaralım, nasıl çalıştığını, WebRTC'nin nerede ve ne için kullanıldığını anlatalım.

WebRTC hakkında bilmeniz gerekenler nelerdir?

Video standartlarının ve teknolojilerinin gelişimi

Sergey Yutsaitis, Cisco, Video+Konferans 2016

WebRTC nasıl çalışır?

İstemci tarafında

• Kullanıcı, HTML5 etiketi içeren bir sayfa açar
• Tarayıcı, kullanıcının web kamerasına ve mikrofonuna erişim talep eder.
• Kullanıcı sayfasındaki 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.
• Muhatap hakkında veya sunucuda karıştırılan konferansla akış hakkında bilgi alırken, tarayıcı kullanılan ses ve video codec bileşenlerini görüşmeye başlar.
• WebRTC istemcileri arasında (bizim durumumuzda, tarayıcı ve sunucu arasında) kodlama ve veri akışı süreci başlar.

WebRTC sunucu tarafında

İki katılımcı arasındaki veri alışverişi için bir video sunucusu gerekli değildir, ancak birkaç katılımcıyı bir konferansta birleştirmek istiyorsanız, bir sunucu gereklidir.

Video sunucusu, çeşitli kaynaklardan medya trafiğini alacak, dönüştürecek ve WebRTC'yi terminal olarak kullanan kullanıcılara gönderecektir.

WebRTC sunucusu ayrıca WebRTC eşlerinden medya trafiği alacak ve varsa masaüstü veya mobil uygulamaları kullanarak konferans katılımcılarına iletecektir.

standardın faydaları

• Yazılım yüklemesi gerekmez.
• Şunlar sayesinde çok yüksek iletişim kalitesi:
  • Modern video (VP8, H.264) ve ses codec'lerinin (Opus) kullanımı.
  • Akış kalitesinin bağlantı koşullarına göre otomatik olarak ayarlanması.
  • Dahili yankı ve gürültü giderme.
  • Katılımcıların mikrofonlarının (AGC) otomatik seviye kontrolü.
• Yüksek düzeyde güvenlik: tüm bağlantılar güvenlidir ve TLS ve SRTP protokollerine göre şifrelenir.
• İçeriği yakalamak için masaüstü gibi yerleşik bir mekanizma vardır.
• HTML5 ve JavaScript tabanlı herhangi bir kontrol arayüzünü uygulayabilme.
• Arabirimi WebSockets kullanarak herhangi bir arka uç sistemle entegre etme yeteneği.
• Açık kaynaklı bir proje - onu ürününüze veya hizmetinize yerleştirebilirsiniz.
• Gerçek çapraz platform: Aynı WebRTC uygulaması, tarayıcının WebRTC'yi desteklemesi koşuluyla, masaüstü veya mobil herhangi bir işletim sisteminde eşit derecede iyi çalışacaktır. Bu, yazılım geliştirme için çok fazla kaynak tasarrufu sağlar.

standardın dezavantajları

• Grup sesli ve görüntülü konferansları düzenlemek için, video ve sesi katılımcılardan karıştıracak bir video konferans sunucusu gereklidir, çünkü tarayıcı birden fazla gelen akışı birbiriyle nasıl senkronize edeceğini bilmiyor.
• Tüm WebRTC çözümleri birbiriyle uyumsuzdur, çünkü standart, yalnızca video ve ses iletme yöntemlerini açıklayarak, abonelere hitap etme, uygunluklarını izleme, mesaj ve dosya alışverişi, programlama ve diğer şeyleri satıcıya bırakma yöntemlerinin uygulanmasını bırakır.
• Yani bir geliştiricinin WebRTC uygulamasından başka bir geliştiricinin WebRTC uygulamasına çağrı yapamayacaksınız.
• Karma grup konferansları çok fazla bilgi işlem kaynağı gerektirir, bu nedenle bu tür görüntülü iletişim, ücretli bir abonelik satın almayı veya altyapısına yatırım yapmayı gerektirir; burada her konferans, modern bir işlemcinin 1 fiziksel çekirdeğini gerektirir.

WebRTC Sırları: Satıcılar Yıkıcı Web Teknolojisinden Nasıl Yarar Sağlar?

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

Video konferans pazarı için WebRTC

Video konferans terminallerinin sayısında artış

WebRTC teknolojisi, video konferans pazarının gelişimi üzerinde güçlü bir etkiye sahip olmuştur. 2013 yılında WebRTC destekli ilk tarayıcıların piyasaya sürülmesinden sonra, dünya çapındaki potansiyel video konferans terminali sayısı hemen 1 milyar cihaz arttı. Aslında her tarayıcı, iletişim kalitesi açısından donanım muadillerinden aşağı olmayan bir video konferans terminali haline geldi.

Özel çözümlerde kullanın

Çeşitli JavaScript kitaplıklarının ve bulut hizmeti API'lerinin WebRTC desteğiyle kullanılması, herhangi bir web projesine video desteği eklemeyi kolaylaştırır. Geçmişte, gerçek zamanlı veri iletimi, geliştiricilerin protokollerin nasıl çalıştığını öğrenmelerini ve diğer şirketlerin çalışmalarını kullanmalarını gerektiriyordu, bu da çoğu zaman ek lisanslama gerektiriyor ve bu da maliyetleri artırıyordu. WebRTC zaten “Siteden arama”, “Çevrimiçi destek sohbeti” vb. servislerde aktif olarak kullanılmaktadır.

Linux için Skype'ın eski kullanıcıları

2014 yılında Microsoft, BT uzmanları arasında büyük sıkıntıya neden olan Linux için Skype projesine desteğin sona erdiğini duyurdu. WebRTC teknolojisi işletim sistemine bağlı değildir, ancak tarayıcı düzeyinde uygulanır, yani. Linux kullanıcıları, WebRTC tabanlı ürün ve hizmetleri tam teşekküllü bir Skype ikamesi olarak görebilecekler.

Flash ile Yarışma

WebRTC ve HTML5, zaten en iyi yıllarından çok uzakta olan Flash teknolojisi için ölümcül bir darbe oldu. 2017'den bu yana, önde gelen tarayıcılar Flash'ı desteklemeyi resmen durdurdu ve teknoloji sonunda piyasadan kayboldu. Ancak Flash'a kredi vermelisiniz, çünkü web konferans pazarını yaratan ve tarayıcılarda canlı iletişim için teknik yetenekler sunan oydu.

WebRTC video sunumları

Dmitry Odintsov, TrueConf, Video+Konferans Ekim 2017

WebRTC'deki kodekler

Ses codec'leri

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

G.711- geleneksel telefon sistemlerinde en sık kullanılan, yüksek bit hızına (64 kbps) sahip en eski ses codec'i. Ana avantaj, hafif sıkıştırma algoritmalarının kullanılması nedeniyle minimum hesaplama yüküdür. Codec, ses sinyallerinin düşük düzeyde sıkıştırılmasına sahiptir ve kullanıcılar arasındaki iletişim sırasında ek ses gecikmesi sağlamaz.

G.711, çok sayıda cihaz tarafından desteklenir. Bu codec bileşenini kullanan sistemlerin kullanımı, diğer ses codec bileşenlerine (G.723, G.726, G.728, vb.) dayalı olanlardan daha kolaydır. Kalite açısından G.711, MOS testinde 4,2 puan aldı (4-5 puan en yüksek puandır ve iyi kalite anlamına gelir, ISDN'deki ses trafiğinin kalitesine benzer ve hatta daha yüksek).

başyapıt düşük kodlama gecikme süresine (2,5 ms'den 60 ms'ye), değişken bit hızı desteğine ve değişken bant genişliğine sahip ağlar üzerinden ses akışı için ideal olan yüksek sıkıştırmaya sahip bir codec bileşenidir. Opus, SILK (Voice Compression, Human Speech Distortion Elimination) ve CELT (Audio Data Encoding) kodeklerinin en iyi özelliklerini birleştiren hibrit bir çözümdür. Codec ücretsiz olarak mevcuttur, onu kullanan geliştiricilerin telif hakkı sahiplerine telif ödemesi gerekmez. Diğer ses codec'leriyle karşılaştırıldığında, Opus kesinlikle birçok yönden kazanır. MP3, Vorbis, AAC LC gibi oldukça popüler düşük bit hızlı codec'leri gölgede bıraktı. Opus, sesin "resmini" orijinaline AMR-WB ve Speex'ten daha yakın olarak geri yükler. Bu codec bileşeni gelecek, bu nedenle WebRTC teknolojisinin yaratıcıları onu zorunlu desteklenen ses standartları aralığına dahil ettiler.

Video codec'leri

WebRTC için bir video codec bileşeni seçme sorunları, geliştiricilerin birkaç yılını aldı ve sonunda H.264 ve VP8 kullanmaya karar verdiler. Hemen hemen tüm modern tarayıcılar her iki codec bileşenini de destekler. Video konferans sunucularının WebRTC ile çalışması için yalnızca birini desteklemesi gerekir.

VP8 yüksek video akışı kod çözme hızına ve çerçeve kaybına karşı artırılmış dirence sahip, açık lisanslı ücretsiz bir video codec bileşenidir. Codec evrenseldir, donanım platformlarına uygulanması kolaydır, bu nedenle video konferans sistemi geliştiricileri onu ürünlerinde sıklıkla kullanır.

Ücretli video codec'i H.264 kardeşinden çok daha erken tanındı. Bu, yüksek video kalitesini korurken video akışının yüksek derecede sıkıştırılmasına sahip bir codec bileşenidir. Donanım video konferans sistemleri arasında bu codec bileşeninin yüksek yaygınlığı, WebRTC standardında kullanıldığını düşündürmektedir.

Google ve Mozilla, VP8 codec bileşenini aktif olarak tanıtırken, Microsoft, Apple ve Cisco, H.264'ü (geleneksel video konferans sistemleriyle uyumluluğu sağlamak için) aktif olarak tanıtmaktadır. Ve burada bulut tabanlı WebRTC çözümlerinin geliştiricileri için çok büyük bir sorun ortaya çıkıyor, çünkü konferanstaki tüm katılımcılar bir tarayıcı kullanıyorsa, o zaman konferansı bir codec ile bir kez karıştırmak yeterlidir ve tarayıcılar farklıysa ve aralarında Safari / Edge ise, konferansın iki kez farklı codec bileşenleriyle kodlanması gerekecektir, bu da medya sunucusu için sistem gereksinimlerini ve sonuç olarak WebRTC hizmetlerine abonelik maliyetini ikiye katlayacaktır.

WebRTC API'si

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

• (web tarayıcısının kameralardan veya kullanıcının masaüstünden ses ve video sinyallerini almasından sorumludur).
• RTCPeerConnection(kameradan, mikrofondan ve masaüstünden alınan medya verilerini "alışverişi" için tarayıcılar arasındaki bağlantıdan sorumludur. Ayrıca, bu API'nin "görevleri" arasında sinyal işleme (onu dış gürültüden temizleme, mikrofon sesini ayarlama) ve üzerinde kontrol yer alır. kullanılan ses ve video codec'leri).
• RTC Veri Kanalı(kurulan bir bağlantı üzerinden iki yönlü veri aktarımı sağlar).

Tarayıcı, kullanıcının mikrofonuna ve kamerasına erişmeden önce bu izni ister. Google Chrome'da, "Ayarlar" bölümünde erişimi önceden yapılandırabilirsiniz, Opera ve Firefox'ta, cihaz seçimi doğrudan açılır listeden erişim sırasında gerçekleştirilir. İzin isteği, HTTP protokolü kullanılırken her zaman ve HTTPS kullanılıyorsa bir kez görünür:

RTCPeerConnection. Bir WebRTC konferansına katılan her tarayıcının bu nesneye erişimi olmalıdır. RTCPeerConnection kullanımı sayesinde, bir tarayıcıdan diğerine medya verileri NAT ve güvenlik duvarlarından bile geçebilir. Medya akışlarını başarılı bir şekilde iletmek için, katılımcıların web soketleri gibi bir aktarım kullanarak aşağıdaki verileri değiş tokuş etmesi gerekir:

• başlatan katılımcı, ikinci katılımcıya bir Offer-SDP (ileteceği medya akışının özelliklerine sahip veri yapısı) gönderir;
• ikinci katılımcı bir "yanıt" - Cevap-SDP oluşturur ve bunu başlatana gönderir;
• ardından, varsa (katılımcılar NAT veya güvenlik duvarlarının arkasındaysa) katılımcılar arasında bir ICE aday değişimi düzenlenir.

Katılımcılar arasındaki bu alışverişin başarıyla tamamlanmasının ardından doğrudan medya akışlarının (ses ve görüntü) aktarımı organize edilir.

RTC Veri Kanalı. Veri Kanalı protokolü desteği nispeten yakın zamanda tarayıcılarda ortaya çıktı, bu nedenle bu API yalnızca WebRTC'nin Mozilla Firefox 22+ ve Google Chrome 26+ tarayıcılarda kullanıldığı durumlarda düşünülebilir. Bununla, katılımcılar tarayıcıda kısa mesaj alışverişinde bulunabilirler.

WebRTC bağlantısı

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, çok uzun bir süre Internet Explorer'da ve yeni Edge tarayıcısında WebRTC desteği konusunda sessiz kaldı. Redmond'daki adamlar, teknolojiyi kontrol etmedikleri kullanıcıların eline vermekten gerçekten hoşlanmıyorlar, bu tür bir politika. Ama yavaş yavaş işler yerden kalktı, çünkü. Artık WebRTC'yi görmezden gelmek mümkün olmadı ve WebRTC standardından türetilen ORTC projesi duyuruldu.

Geliştiricilere göre ORTC, WebRTC standardının, JavaScript ve HTML5'e dayalı geliştirilmiş bir API kümesine sahip bir uzantısıdır; bu, sıradan dile çevrildiğinde her şeyin aynı olacağı anlamına gelir, standardı Google değil yalnızca Microsoft kontrol eder. ve gelişimi. Kodek seti, telefon ve donanım video konferans sistemlerinde kullanılan H.264 ve bazı G.7XX serisi ses kodlayıcı desteği ile genişletildi. Belki de yerleşik RDP (içerik aktarımı için) ve mesajlaşma desteği olacaktır. Bu arada, Internet Explorer kullanıcılarının şansı kalmadı, ORTC desteği yalnızca Edge'de olacak. Ve elbette, böyle bir protokol ve codec seti Skype Kurumsal'a çok az kanla uyar ve bu da WebRTC için daha da fazla iş uygulaması açar.

WebRTC, bir P2P bağlantısı düzenlemenize ve tarayıcılar arasında doğrudan veri aktarmanıza izin veren, tarayıcı tarafından sağlanan bir API'dir. İnternette WebRTC kullanarak kendi görüntülü sohbetinizi nasıl yazacağınıza dair epeyce eğitim var. Mesela burada Habré ile ilgili bir yazı var. Ancak, hepsi iki istemciyi bağlamakla sınırlıdır. Bu yazıda, WebRTC kullanarak üç veya daha fazla kullanıcı arasında bağlantı ve mesaj alışverişinin nasıl organize edileceğinden bahsetmeye çalışacağım.

RTCPeerConnection arabirimi, iki tarayıcı arasında eşler arası bir bağlantıdır. Üç veya daha fazla kullanıcıyı birbirine bağlamak için bir ağ ağı düzenlememiz gerekecek (her düğümün diğer tüm düğümlere bağlı olduğu bir ağ).
Aşağıdaki şemayı kullanacağız:

1. Sayfayı açarken, oda kimliğinin varlığını kontrol ediyoruz. konum.karma
2. Oda kimliği belirtilmemişse, yeni bir tane oluşturun
3. Bir sinyal sunucusuna "belirtilen odaya katılmak istediğimize dair bir mesaj gönderiyoruz.
4. Sinyal sunucusu, bu odadaki diğer istemcilere yeni bir kullanıcı bildirimi gönderir.
5. Halihazırda odada bulunan müşteriler, yeni gelen kişiye bir SDP teklifi gönderir.
6. Yeni gelen teklife cevap verir

0. Sinyal sunucusu

Bildiğiniz gibi WebRTC, tarayıcılar arasında P2P bağlantısı imkanı sağlasa da, servis mesajlarının değiş tokuşu için ek bir taşıma gerektirir. Bu örnekte aktarım, socket.io kullanılarak Node.JS'de yazılmış bir WebSocket sunucusudur:

var socket_io = gerekli ("socket.io"); module.exports = function (server) ( var users = (); var io = socket_io(server); io.on("connection", function(socket) ( // Yeni bir kullanıcının odaya katılmasını istiyorum socket.on( "room ", function(message) ( var json = JSON.parse(message); // Soketi kullanıcı listesine ekle users = socket; if (socket.room !== undefined) ( // Eğer soket zaten bir odada, bırakın socket.leave(socket.room); ) // İstenen odaya girin socket.room = json.room; socket.join(socket.room); socket.user_id = json.id; // Bu odanın diğer istemcilere yeni bir katılımcıya katılma hakkında bir mesajı olduğunu gönder socket.broadcast.to(socket.room).emit("new", json.id); )); // WebRTC ile ilgili mesaj (SDP teklifi, SDP yanıtı veya ICE adayı) socket.on("webrtc", function(message) ( var json = JSON.parse(message); if (json.to !== undefined && users !== undefined) ( // Mesaj varsa bir alıcı ve sunucu tarafından bilinen bu alıcı, sadece ona bir mesaj göndeririz... users.emit("webrtc", mesaj); ) else ( // ...aksi takdirde mesajı bir yayın olarak kabul edin socket.broadcast.to(socket.room).emit("webrtc", mesaj); ) )); // Biri bağlantıyı kesti socket.on("disconnect", function() ( // Bir istemcinin bağlantısı kesildiğinde, diğerlerine haber ver socket.broadcast.to(socket.room).emit("leave", socket.user_id); kullanıcıları sil; )); )); );

1. index.html

Sayfanın kendisinin kaynak kodu oldukça basittir. Bu makale bununla ilgili olmadığı için kasıtlı olarak düzene ve diğer güzel şeylere dikkat etmedim. Birisi onu güzelleştirmek isterse, bu zor olmayacak.

2.main.js

2.0. Sayfa öğelerine ve WebRTC arayüzlerine bağlantılar alma

var sohbet günlüğü = document.getElementById("sohbet günlüğü"); var mesaj = document.getElementById("mesaj"); var bağlantı_sayısı = belge.getElementById("bağlantı_sayısı"); var room_link = document.getElementById("room_link");

WebRTC arayüzlerine erişmek için hala tarayıcı ön eklerini kullanmak zorundayız.

Var PeerConnection = window.mozRTCPeerConnection || window.webkitRTCPeerConnection; var SessionDescription = window.mozRTCSessionDescription || pencere.RTCSessionDescription; var IceCandidate = pencere.mozRTCIceCandidate || pencere.RTCIceCandidate;

2.1. Oda kimliğinin belirlenmesi

Burada benzersiz bir oda ve kullanıcı kimliği oluşturmak için bir işleve ihtiyacımız var. UUID'yi bu amaçla kullanacağız.

uuid işlevi () ( var s4 = function() ( dönüş Math.floor(Math.random() * 0x10000).toString(16); ); dönüş s4() + s4() + "-" + s4() + "-" + s4() + "-" + s4() + "-" + s4() + s4() + s4(); )

Şimdi oda kimliğini adresten çıkarmaya çalışalım. Bu ayarlanmazsa, yeni bir tane oluşturacağız. Sayfada mevcut odaya bir bağlantı göstereceğiz ve aynı zamanda mevcut kullanıcı için bir tanımlayıcı oluşturacağız.

VarROOM = konum.hash.substr(1); if (!ROOM) ( ROOM = uuid(); ) room_link.innerHTML = "Odaya bağlantı"; varME = uuid();

2.2. web soketi

Sayfayı açar açmaz, sinyal sunucumuza bağlanacağız, odaya girmek için bir istek göndereceğiz ve mesaj işleyicileri belirleyeceğiz.

// Mesaj kapatıldığında sunucuya bu var ile ilgili bir bildirim göndermemiz gerektiğini belirtiyoruz socket = io.connect("", ("sync bağlantı kesme on unload": true)); socket.on("webrtc", socketRequired); socket.on("yeni", socketNewPeer); // Hemen odaya girmek için bir istek gönderin socket.emit("room", JSON.stringify((id: ME, room: ROOM))); // WebRTC işlevi sendViaSocket(type, message, to) ( socket.emit("webrtc", JSON.stringify((id: ME, to: to, type: type, data: message ) ile ilgili adres mesajlarını göndermek için yardımcı işlev )); )

2.3. Eş Bağlantı Ayarları

Çoğu ISP, NAT üzerinden İnternet bağlantısı sağlar. Bu nedenle, doğrudan bir bağlantı o kadar önemsiz hale gelmez. Bir bağlantı oluştururken, tarayıcının NAT'ı atlamak için kullanmaya çalışacağı STUN ve TURN sunucularının bir listesini belirtmemiz gerekir. Bağlantı için birkaç ek seçenek de belirteceğiz.

Var sunucusu = ( iceServers: [ (url: "stun:23.21.150.121"), (url: "stun:stun.l.google.com:19302"), (url: "turn:numb.viagenie.ca", kimlik bilgisi: "şifreniz buraya gelecek", kullanıcı adı: " [e-posta korumalı]") ] ); var options = ( isteğe bağlı: [ (DtlsSrtpKeyAgreement: true), // Chrome ile Firefox arasındaki bağlantı için gerekli (RtpDataChannels: true) // DataChannels API'sini kullanmak için Firefox'ta gerekli ] )

2.4. Yeni bir kullanıcı bağlama

Odaya yeni bir eş eklendiğinde, sunucu bize bir mesaj gönderir. yeni. Yukarıdaki mesaj işleyicilerine göre işlev çağrılacak soketNewPeer.

var eşler = (); function socketNewPeer(data) ( peers = (candidateCache: ); // Yeni bir bağlantı oluştur var pc = new PeerConnection(sunucu, seçenekler); // Başlat initConnection(pc, data, "offer"); // Eşi sakla) listede peers.connection = pc; // İleti alışverişinin yapılacağı bir DataChannel oluşturun var channel = pc.createDataChannel("kanalım", ()); channel.owner = data; peers.channel = channel; // Olay işleyicileri kurun bindEvents(channel); // Bir SDP teklifi oluşturun pc.createOffer(function(offer) ( pc.setLocalDescription(offer); )); ) function initConnection(pc, id, sdpType) ( pc.onicecandidate = function ( event) ( if (event.candidate) ( // Yeni bir ICE adayı bulunduğunda, onu daha fazla göndermek için pes.candidateCache.push(event.candidate); ) else ( // Adaylar keşfedildiğinde tamamlandı, işleyici tekrar çağrılacak, ancak aday olmadan // Bu durumda, eşe önce bir SDP teklifi veya bir SDP yanıtı göndeririz (işlev parametresine bağlı olarak)... sendViaSocket(sdpType, pc.localDescription, id) ; // ...ve daha sonra (var i = 0; i) için önceden bulunan tüm ICE adayları< peers.candidateCache.length; i++) { sendViaSocket("candidate", peers.candidateCache[i], id); } } } pc.oniceconnectionstatechange = function (event) { if (pc.iceConnectionState == "disconnected") { connection_num.innerText = parseInt(connection_num.innerText) - 1; delete peers; } } } function bindEvents (channel) { channel.onopen = function () { connection_num.innerText = parseInt(connection_num.innerText) + 1; }; channel.onmessage = function (e) { chatlog.innerHTML += "

"; }; }

2.5. SDP teklifi, SDP cevabı, ICE adayı

Bu mesajlardan biri alındığında, ilgili mesaj işleyicisini ararız.

function socketRequired(veri) ( var json = JSON.parse(data); switch (json.type) ( case "candidate": remoteCandidateRequired(json.id, json.data); break; case "teklif": remoteOfferRequired(json. id, json.data); mola; durum "cevap": remoteAnswerRequired(json.id, json.data); mola; ) )

2.5.0 SDP teklifi

function remoteOfferRequired(id, data) ( createConnection(id); var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); pc.createAnswer(function(answer) ( pc.setLocalDescription(answer); )); ) function createConnection(id) ( if (peers === undefined) ( peers = (candidateCache: ); var pc = new PeerConnection(sunucu, seçenekler); initConnection(pc, id, "answer"); peers.connection = pc ; pc.ondatachannel = function(e) ( peers.channel = e.channel; peers.channel.owner = id; bindEvents(peers.channel); ) ) )

2.5.1 SDP yanıtı

function remoteAnswerRequired(id, data) ( var pc = peers.connection; pc.setRemoteDescription(new SessionDescription(data)); )

2.5.2 ICE adayı

function remoteCandidateRequired(id, data) ( createConnection(id); var pc = peers.connection; pc.addIceCandidate(new IceCandidate(data)); )

2.6. mesaj gönderme

Düğmeye basarak Göndermek işlev denir mesaj gönder. Tek yaptığı, eşler listesini gözden geçirmek ve belirtilen mesajı herkese göndermeye çalışmaktır.