WebRTC. Tarayıcıda video konferans. WebRTC Webrtc sesli sohbeti kullanarak çok kullanıcılı sohbet

Önsöz. WebRTC tabanlı P2P görüntülü sohbet, Skype ve diğer iletişim araçlarına bir alternatiftir. WebRTC tabanlı p2p görüntülü sohbetin ana unsurları bir tarayıcı ve bir iletişim sunucusudur. P2P görüntülü sohbetler, sunucunun bilgi akışlarının aktarımında yer almadığı eşler arası görüntülü sohbetlerdir. Bilgiler, kullanıcıların tarayıcıları (eşleri) arasında herhangi bir işlem yapılmaksızın doğrudan aktarılır. ek programlar

. P2p görüntülü sohbetler, tarayıcıların yanı sıra kullanıcıları kaydetmek, onlar hakkındaki verileri depolamak ve kullanıcılar arasında geçiş yapılmasını sağlamak için tasarlanmış iletişim sunucularını kullanır. En yeni WebRTC ve HTML5 teknolojilerini destekleyen tarayıcılar, IP ağları üzerinden anında metin mesajlaşma ve dosya aktarımının yanı sıra ses ve video iletişimi de sağlar.

Yani, bir web arayüzündeki sohbetler, web sohbetleri, sesli ve görüntülü sohbetler, IMS, VoIP, bileşik paket anahtarlamalı ağlar üzerinden çevrimiçi iletişim sağlayan hizmetlerdir. Kural olarak, iletişim hizmetleri ya istemci uygulamalarının kullanıcı cihazlarına (PC'ler, akıllı telefonlar vb.) kurulmasını ya da tarayıcılara eklentilerin ve uzantıların kurulmasını gerektirir. Hizmetlerin çoğu istemci-sunucu mimarisi üzerine kurulu kendi iletişim ağları vardır.

Gerçek zamanlı iletişim hizmetlerini (sohbet, telefon, video konferans) entegre etme sorunu, ör. ses, video, veri kanallarının entegrasyonu ve bunlara tek bir uygulama (tarayıcı) kullanılarak erişim, WebRTC protokolüne dayalı eşler arası veya p2p görüntülü sohbetlerde (eşler arası, noktadan noktaya) çözülebilir. Temel olarak, WebRTC'yi destekleyen bir tarayıcı, tüm kullanıcı cihazları (PC'ler, akıllı telefonlar, iPad'ler, IP telefonlar, cep telefonları vb.) iletişim hizmetleriyle çalışan.

Gerçek zamanlı iletişim sağlayan tüm teknolojilerin tarayıcıda uygulanmasını sağlayan WebRTC'dir. P2p görüntülü sohbetlerin özü, multimedya ve metin verilerinin, bir sunucunun veya ek programların katılımı olmadan doğrudan kullanıcıların tarayıcıları (uzaktan eşleme) arasında aktarılmasıdır. Böylece, tarayıcılar yalnızca hemen hemen tüm bilgilere erişim sağlamakla kalmaz, bilgi kaynakları Sunucularda depolanan ancak aynı zamanda tüm gerçek zamanlı iletişim hizmetlerine ve posta hizmetlerine (sesli posta, e-posta, SMS vb.)

P2p görüntülü sohbet sunucuları (iletişim sunucuları) yalnızca kullanıcıları kaydetmek, kullanıcılar hakkındaki verileri depolamak ve kullanıcı tarayıcıları arasında bağlantı kurmak (geçiş yapmak) için tasarlanmıştır. İlk p2p görüntülü sohbetler flash teknolojileri kullanılarak uygulandı. Flash p2p görüntülü sohbetler örneğin şuralarda kullanılır: sosyal ağlarda. Flash p2p görüntülü sohbetler sağlamaz yüksek kalite multimedya verilerinin iletimi. Ayrıca, p2p flash görüntülü sohbetlerde mikrofondan ve video kameradan ses ve video akışı çıkışı sağlamak için yüklemeniz gerekir. flaş eklentisi bir web tarayıcısına.

Ancak yeni nesil telekomünikasyon hizmetleri, İnternet üzerinden iletişim kurmak için yalnızca WebRTC protokollerini ve HTML5 spesifikasyonunu destekleyen tarayıcıları ve iletişim sunucularını kullanan web iletişimlerini içerir. Böyle bir tarayıcıyla donatılmış herhangi bir kullanıcı cihazı (PC, iPad, akıllı telefonlar vb.), yüksek kaliteli sesli ve görüntülü aramaların yanı sıra anlık metin mesajları ve dosyaların aktarımını da sağlayabilir.

Yani, web iletişiminin yeni teknolojisi (p2p sohbetleri, görüntülü sohbetler) WebRTC protokolüdür. WebRTC, HTML5, CSS3 ve JavaScript ile birlikte çeşitli web uygulamaları oluşturmanıza olanak tanır. WebRT, eşler arası mimariyi kullanarak web iletişimlerini (eşler arası ağlar) gerçek zamanlı olarak düzenlemek için tasarlanmıştır. WebRTC tabanlı P2P sohbetler, tarayıcıda harici eklenti ve eklentiler kullanılmadan, yalnızca web tarayıcılarını kullanarak İnternet üzerinden kullanıcılar arasında dosya aktarımının yanı sıra metin, ses ve görüntü iletişimini sağlar.

P2p sohbetlerde sunucu yalnızca iki tarayıcı arasında p2p bağlantısı kurmak için kullanılır. WebRTC protokolünü temel alan bir p2p sohbetinin istemci kısmını oluşturmak için HTML5, CSS3 ve JavaScript kullanılır. İstemci uygulaması, WebRTC API aracılığıyla tarayıcılarla etkileşime girer.

WebRTC üç JavaScript API'si tarafından uygulanır:

• RTCPeer Bağlantısı;
• MediaStream(getUserMedia);
• RTCDataChannel.

Tarayıcılar medya verilerini UDP üzerinde çalışan SRTP protokolünü kullanarak aktarır. NAT, İnternet üzerinden p2p bağlantılarını kullanan NAT yönlendiricilerinin arkasındaki tarayıcılar (istemciler) için sorun yarattığından, NAT çeviricilerini atlamak için STUN kullanılır. STUN, UDP aktarım protokolünün üzerinde çalışan bir istemci-sunucu protokolüdür. P2p sohbetlerinde kural olarak halka açık bir STUN sunucusu kullanılır ve ondan alınan bilgiler, NAT'ın arkasındaysa iki tarayıcı arasındaki UDP bağlantısı için kullanılır.

WebRTC uygulamalarının uygulanmasına örnekler (p2p sohbetleri, sesli ve görüntülü web sohbetleri):
1. WebRTC tabanlı P2P görüntülü sohbet Bistri (tek tıklamayla görüntülü sohbet, p2p sohbet) Bistri'de açılabilir. Bistri, ek programlar ve eklentiler yüklemeden tarayıcıda çalışır. İşin özü şu şekildedir: Belirtilen bağlantıyı kullanarak p2p görüntülü sohbeti açın, açılan arayüze kaydolduktan sonra ortakları davet edin, ardından eş istemciler listesinden çevrimiçi olan ortağı seçin ve "görüntülü görüşme"ye tıklayın. " düğme.

Sonuç olarak, MediaStream (getUserMedia) mikrofonu + web kamerasını yakalayacak ve sunucu, seçilen ortakla sinyal mesajları alışverişinde bulunacaktır. Sinyal mesajları alışverişi yapıldıktan sonra PeerConnection API, ses ve video akışlarının iletilmesi için kanallar oluşturur. Ayrıca Bistri anlık metin mesajları ve dosyaları da aktarır. İncirde. Şekil 1, Bistri p2p görüntülü sohbet arayüzünün ekran görüntüsünü göstermektedir.

Pirinç. 1. P2P görüntülü sohbet Bistri

2. Twelephone (p2p görüntülü sohbet, p2p sohbet, SIP Twelephone) - bu istemci uygulaması, sesli ve görüntülü aramalar yapmanızın yanı sıra anlık metin mesajları göndermenize olanak tanıyan HTML5 ve WebRTC temelinde oluşturulmuştur. Twelephone test p2p sohbeti, görüntülü sohbet ve SIP Twelephone'u içerir. Twelephone'un SIP protokolünü desteklediğini ve artık Twitter hesabınızı telefon numarası olarak kullanarak SIP telefonlarından sesli ve görüntülü arama yapabileceğinizi ve alabileceğinizi belirtelim. Ayrıca, Metin mesajları mikrofon aracılığıyla sesli giriş yapabilirsiniz ve ses tanıma programı metni “Mesaj gönder” satırına girer.

Twelephone tarayıcı tabanlı bir web telefonudur Google Chrome 25. versiyondan başlayarak, ilavesiz yazılım. Twelephone, Chris Matthieu tarafından geliştirildi. Twelephone arka ucu Node.js üzerine kurulmuştur. Sunucu (iletişim sunucusu) yalnızca iki tarayıcı veya WebRTC istemcisi arasında p2p bağlantısı kurmak için kullanılır. Twelephone uygulamasının kendi yetkilendirme araçları yoktur, ancak bir hesaba bağlanmaya odaklanmıştır ( hesap) Twitter'dan.

İncirde. Şekil 2, Twelephone p2p görüntülü sohbet arayüzünün ekran görüntüsünü göstermektedir.

Pirinç. 2. P2P Telefon

3. Grup p2p görüntülü sohbet Conversat.io, en yeni WebRTC ve HTML5 teknolojileri üzerine kurulmuştur. Conversat görüntülü sohbet, SimpleWebRTC kitaplığı temel alınarak geliştirilmiştir ve bir odadaki en fazla 6 eş istemci arasındaki iletişim için tasarlanmıştır (iletişim için, "Konuşmayı adlandırın" satırında eş istemciler için ortak odanın adını belirtin). P2P görüntülü sohbet Conversat, kullanıcılara iletişim sunucusuna kaydolmadan iletişim hizmetleri sağlar. İncirde. Şekil 3, Conversat p2p görüntülü sohbet arayüzünün ekran görüntüsünü göstermektedir.

Pirinç. 3. Grup P2P görüntülü sohbet Conversat.io

WebRTC tabanlı P2P görüntülü sohbetlere katılmak için kullanıcıların WebRTC protokolünü ve HTML5 spesifikasyonunu destekleyen bir tarayıcının yüklü olması gerekir. Şu anda sürüm 25'ten itibaren Google Chrome tarayıcıları ve Mozilla Firefox Nightly, WebRTC protokolünü ve HTML5 spesifikasyonunu destekler. WebRTC uygulamaları görüntü ve ses aktarım kalitesi açısından Flash uygulamalarından üstündür.

WebRTC'deki materyallerin çoğu kodlamanın uygulama düzeyine odaklanmıştı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 ne olduğunu, STUN ve TURN sunucularına neden ihtiyaç duyulduğunu öğrenelim.

WebRTC'ye Giriş

WebRTC, video veri aktarımı için iki istemciyi birbirine bağlamanıza olanak tanıyan tarayıcı odaklı bir teknolojidir. Ana özellikler dahili tarayıcı desteği (adobe flash gibi üçüncü tarafların uyguladığı teknolojilere gerek yoktur) ve istemcileri ek sunucular kullanmadan bağlama yeteneğidir - eşler arası bağlantı (bundan sonra p2p olarak anılacaktır).

Bilgisayarlarda her zaman genel IP adresleri, yani İnternet'teki adresler bulunmadığından, p2p bağlantısı kurmak oldukça zor bir iştir. Az sayıda IPv4 adresi nedeniyle (ve güvenlik amacıyla), örneğin ev kullanımı için özel ağlar oluşturmanıza olanak tanıyan NAT mekanizması geliştirilmiştir. Birçok ev yönlendiricisi artık NAT'ı desteklemektedir ve bu sayede tüm ev cihazlarının İnternet'e erişimi vardır, ancak İnternet sağlayıcıları genellikle tek bir IP adresi sağlar. Genel IP adresleri internette benzersizdir, ancak özel olanlar değildir. Bu nedenle p2p'yi bağlamak zordur.

Bunu daha iyi anlamak için üç durumu göz önünde bulundurun: her iki düğüm de aynı ağdadır (Şekil 1), her iki düğüm de farklı ağlardadır (biri özel, diğeri genel olarak) (Şekil 2) ve her iki düğüm de farklı özel ağlardadır. aynı IP adresleri (Şekil 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 gösterimdeki ilk harf düğüm tipini belirtmektedir (p = eş, r = yönlendirici). İlk resimde durum olumlu: ağlarındaki düğümler tamamen ağ IP adresleriyle tanımlanıyor ve bu nedenle birbirlerine doğrudan bağlanabiliyorlar. İkinci şekilde benzer düğüm numaralarına sahip iki farklı ağımız var. Burası iki yönlendiriciye sahip yönlendiricilerin (yönlendiricilerin) göründüğü yerdir. ağ Arayüzü– ağınızın içinde ve ağınızın dışında. Bu yüzden iki IP adresi var. Normal düğümlerin yalnızca kendi ağları içinde iletişim kurabilecekleri tek bir arayüzü vardır. Verileri ağları dışındaki birine aktarırlarsa, yalnızca yönlendiricinin (yönlendiricinin) içindeki NAT'ı kullanırlar ve bu nedenle yönlendiricinin IP adresi altında başkaları tarafından görülebilirler - bu onların IP adresidir harici IP adresi. Yani p1 düğümü iç mekan IP = 192.168.0.200 Ve harici IP = 10.50.200.5 ve son adres aynı zamanda ağındaki tüm diğer düğümlerin dışında olacaktır. Durum p2 düğümü için de benzerdir. Bu nedenle, yalnızca dahili (kendi) IP adresleri kullanılırsa iletişimleri imkansızdır. Harici adresleri yani yönlendirici adreslerini kullanabilirsiniz ancak aynı özel ağdaki tüm düğümler aynı harici adrese sahip olduğundan bu oldukça zordur. Bu sorun NAT mekanizması kullanılarak çözülebilir

Düğümleri iç adresleri aracılığıyla bağlamaya karar verirsek ne olur? Veriler ağdan ayrılmayacak. 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, ek sunucuların (STUN, TURN) kullanılmasını gerektiren ICE protokolünü kullanarak bu tür sorunlarla başarılı bir şekilde başa çıkıyor. Tüm bunlar hakkında daha fazla bilgiyi aşağıda bulabilirsiniz.

WebRTC'nin iki aşaması

İki düğümü WebRTC protokolü (veya iki iPhone iletişim kuruyorsa yalnızca RTC) aracılığıyla bağlamak için, bağlantıyı kurmak için bazı ön adımları uygulamanız gerekir. Bu ilk aşamadır; bağlantı kurma. İkinci aşama video veri iletimidir.

WebRTC teknolojisinin pek çok şey kullanmasına rağmen hemen şunu söylemekte fayda var: çeşitli şekillerde iletişim (TCP ve UDP) ve bunlar arasında esnek geçiş olanağına sahip olan bu teknoloji bağlantı verilerini iletmek için bir protokol yok. İki p2p düğümünü bağlamak o kadar kolay olmadığı için şaşırtıcı değil. Bu nedenle biraz sahip olmak gerekir ek olarak WebRTC ile hiçbir şekilde ilgisi olmayan bir veri aktarım yöntemi. Bu bir soket aktarımı olabilir, HTTP protokolü olabilir, hatta olabilir SMTP protokolü veya Rus Postası. Bu aktarım mekanizması ilk veri denir sinyal. Çok fazla bilginin aktarılmasına gerek yoktur. Tüm veriler metin biçiminde iletilir ve iki türe ayrılır - SDP ve Ice Candidate. İlk tür mantıksal bir bağlantı kurmak için, ikincisi ise fiziksel bir bağlantı kurmak için kullanılır. Bunlar hakkında daha sonra daha fazla bilgi vereceğiz, ancak şimdilik WebRTC'nin bize başka bir düğüme iletilmesi gereken bazı bilgiler vereceğini hatırlamak önemli. Gerekli tüm bilgileri ilettiğimiz anda düğümler bağlanabilecek ve artık yardımımıza ihtiyaç kalmayacak. Yani uygulamamız gereken sinyalleşme mekanizması: ayrı ayrı, kullanılacak yalnızca bağlandığında ancak video verileri aktarılırken kullanılmayacaktır.

Öyleyse ilk aşamayı, yani bağlantı kurma aşamasını ele alalım. Birkaç noktadan oluşur. Önce bağlantıyı başlatan düğüm için, sonra da bekleyen düğüm için bu aşamaya bakalım.

• Başlatıcı (arayan):
• Video veri aktarımını başlatmayı teklif et (createOffer)
• SDP SDP'nizi alma)
• Ice adayınızın kabulü Ice adayınız)
• Çağrı Bekletme (aranan):
• Yerel (sizin) medya akışınızı alma ve aktarım için ayarlama (getUserMediaStream)
• Video veri aktarımını başlatmak için teklif alma ve yanıt oluşturma (createAnswer)
• SDP nesnesini alma ve sinyalleşme mekanizmasından (SDP) geçirme
• Ice adayı nesnelerinizi alıp bir sinyal mekanizmasından geçirmek (Ice adayı)
• Uzak (yabancı) bir medya akışının alınması ve ekranda görüntülenmesi (onAddStream)

Tek fark ikinci noktadadır.

Adımların görünürdeki karmaşıklığına rağmen aslında üç tane var: kendi medya akışınızı göndermek (madde 1), bağlantı parametrelerini ayarlamak (maddeler 2-4), başka birinin medya akışını almak (madde 5). En zor adım ikinci adımdır çünkü iki bölümden oluşur: fiziksel Ve mantıklı bağlantılar. İlki şunu belirtir yol Paketlerin bir ağ düğümünden diğerine geçmek için bu yol boyunca seyahat etmesi gerekir. İkincisi şunu belirtir video/ses parametreleri– hangi kalitenin kullanılacağı, hangi kodeklerin kullanılacağı.

Zihinsel olarak createOffer veya createAnswer aşaması, SDP ve Ice aday nesnelerinin geçiş aşamalarına bağlanmalıdır.

Temel varlıklar Medya akışları (MediaStream)

Esas olan medya akışıdır, yani video ve ses verilerinin, resim ve sesin akışıdır. Yerel ve uzak olmak üzere iki tür medya akışı vardır. 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 iş parçacığı bulunur. WebRTC'de akışlar için bir MediaStream arayüzü vardır ve ayrıca yerel akışa özel bir LocalMediaStream alt arayüzü de vardır. JavaScript'te yalnızca ilkiyle karşılaşabilirsiniz, ancak libjingle kullanırsanız ikinciyle de karşılaşabilirsiniz.

WebRTC'nin bir iş parçacığı içinde oldukça kafa karıştırıcı bir hiyerarşisi var. Her akış, çeşitli medya kanallarından (MediaChannel) oluşabilen birçok medya parçasından (MediaTrack) oluşabilir. Ayrıca birkaç medya akışının kendisi de olabilir.

Her şeye sırayla bakalım. Bunu yapmak için bazı örnekleri aklımızda tutalım. Diyelim ki sadece kendimizin bir videosunu 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 + masa) ve bir sese (biz) ihtiyacımız olacak. Bizim ve tablonun farklı konulara bölünmesi gerektiği açıktır, çünkü bu veriler muhtemelen zayıf bir şekilde birbirine bağlıdır. Bu nedenle, biri bizim için, diğeri tablo için olmak üzere iki MediaStream'imiz olacak. Birincisi hem video hem de ses verilerini içerecek, ikincisi ise yalnızca videoyu içerecektir (Şekil 4).

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

Bir medya akışının en azından veri içerme özelliğini içermesi gerektiği hemen anlaşılıyor. farklı şekiller- video ve ses. Bu, teknolojide dikkate alınır ve bu nedenle her veri türü, MediaTrack medya kanalı aracılığıyla uygulanır. Medya parçasının, video mu yoksa ses mi olduğunu belirleyen özel bir özellik türü vardır (Ş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. Daha sonra iki video parçası ve bir ses parçası oluşturacağız. Kameralara ve mikrofona erişelim. Her parçaya hangi cihazın kullanılacağını söyleyelim. İlk medya akışına bir video ve ses parçası, ikinci medya akışına ise başka bir kameradan bir video parçası ekleyelim.

Peki bağlantının diğer ucundaki medya akışlarını nasıl ayırt edeceğiz? Bunu yapmak için her medya akışının bir label özelliği vardır - akışın etiketi, adı (Şekil 6). Medya parçaları aynı özelliğe sahiptir. Her ne kadar ilk bakışta videonun sesten başka şekillerde ayırt edilebileceği görülüyor.

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

Peki, eğer medya parçaları bir etiket aracılığıyla tanımlanabiliyorsa, örneğimiz için neden bir yerine iki medya akışı kullanmamız gerekiyor? Sonuçta, bir medya akışını aktarabilirsiniz ancak içinde farklı parçalar kullanabilirsiniz. Medya akışlarının önemli bir özelliğine ulaştık; onlar senkronize etmek medya izleri. Farklı medya akışları birbiriyle senkronize edilmez ancak her medya akışındaki tüm parçalar senkronize edilir aynı anda oynanır.

Bu nedenle, sözlerimizin, yüz ifadelerimizin ve kağıt parçamızın aynı anda oynatılmasını istiyorsak, o zaman tek bir medya akışını kullanmaya değer. Bu o kadar önemli değilse, farklı akışları kullanmak daha karlı olur - resim daha düzgün olacaktır.

İletim sırasında bazı parçaların devre dışı bırakılması gerekiyorsa medya parçasının etkin özelliğini kullanabilirsiniz.

Son olarak stereo ses hakkında düşünmeye değer. Bildiğiniz gibi stereo ses iki farklı sestir. Ayrıca ayrı olarak aktarılmaları gerekir. Bunun için MediaChannel'lar kullanılır. Bir medya ses parçasının birçok kanalı olabilir (örneğin, 5+1 sese ihtiyacınız varsa 6). Medya kanallarının içinde de kanallar var elbette. senkronize. Video için genellikle yalnızca bir kanal kullanılır, ancak örneğin reklamların üst üste bindirilmesi için birkaç kanal da 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ışının içinde video ve ses için olmak üzere iki tür medya parçası bulunur. Genellikle ikiden fazla parça yoktur, ancak birkaç farklı videoyu (muhatap ve masasının) iletmeniz gerekiyorsa daha fazla parça 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ışı ise her ikisinin de taşıyıcısıdır.

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

Farklı bilgisayarlarda her zaman farklı kameralar, mikrofonlar, video kartları ve diğer ekipmanlar bulunur. Sahip oldukları birçok seçenek var. İki ağ düğümü arasındaki verilerin medya aktarımı için tüm bunların koordine edilmesi gerekir. WebRTC bunu otomatik olarak yapar ve özel nesne– SDP oturum tanımlayıcısı. Bu nesneyi başka bir düğüme aktardığınızda medya verileri aktarılabilir. Ancak henüz başka bir düğümle bağlantı yok.

Bunun için her türlü sinyal mekanizması kullanılır. SDP, soketler aracılığıyla veya bir kişi tarafından (bunu telefonla başka bir düğüme söyleyin) veya Russian Post aracılığıyla iletilebilir. Her şey çok basit - size hazır bir SDP verilecek ve onu göndermeniz gerekiyor. Ve diğer taraftan alındığında WebRTC departmanına aktarın. Oturum tanımlayıcı metin olarak saklanır ve uygulamalarınızda değiştirilebilir ancak bu genellikle gerekli değildir. Örnek olarak, masaüstü ↔ telefonu bağlarken bazen istediğiniz ses codec bileşeninin seçimini zorlamanız gerekir.

Genellikle bir bağlantı kurarken URL gibi bir tür adres belirtmeniz gerekir. Burada bu gerekli değildir, çünkü sinyal mekanizması aracılığıyla verileri hedefine kendiniz göndereceksiniz. WebRTC'ye p2p bağlantısı kurmak istediğimizi belirtmek için createOffer fonksiyonunu çağırmamız gerekiyor. Bu işlevi çağırdıktan ve özel bir geri çağırma 'a belirledikten sonra, bir SDP nesnesi oluşturulacak ve aynı geri aramaya aktarılacaktır. Sizden gereken tek şey bu nesneyi ağ üzerinden başka bir düğüme (muhatap) aktarmaktır. Bundan sonra veriler diğer uca sinyalleşme mekanizması yani bu SDP nesnesi aracılığıyla ulaşacaktır. Bu oturum tanımlayıcısı bu düğüme yabancıdır ve bu nedenle yararlı 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. CreateOffer'ın tam bir benzeridir. Yine, yerel oturum tanımlayıcısı geri aramanıza iletilecek ve sinyalleşme mekanizması yoluyla geri iletilmesi gerekecektir.

createAnswer işlevini ancak başka birinin SDP nesnesini aldıktan sonra arayabileceğinizi belirtmekte fayda var. Neden? Çünkü createAnswer çağrılırken oluşturulacak yerel SDP nesnesinin uzak SDP nesnesine bağlı olması gerekir. Ancak bu durumda video ayarlarınızı muhatabınızın ayarlarıyla koordine etmek mümkündür. Ayrıca, yerel medya akışını almadan createAnswer ve createOffer'ı çağırmamalısınız; bunların SDP nesnesine yazacak hiçbir şeyleri olmayacaktır.

WebRTC bir SDP nesnesini düzenleme yeteneğine sahip olduğundan, yerel bir tanımlayıcı aldıktan sonra yüklenmesi gerekir. WebRTC'nin bize verdiklerini aktarmamız gerekmesi biraz tuhaf görünebilir, ancak protokol budur. Bir uzaktan tanıtıcı alındığında, bunun da kurulması gerekir. Bu nedenle, bir düğüme iki tanımlayıcı yüklemeniz gerekir - sizin ve bir başkasının (yani yerel ve uzak).

Bundan sonra el sıkışmalar Düğümler birbirlerinin isteklerini bilir. Örneğin, eğer düğüm 1 codec bileşeni A ve B'yi destekliyorsa ve düğüm 2 codec bileşeni B ve C'yi destekliyorsa, her düğüm kendisinin ve diğerinin tanımlayıcılarını bildiğinden, her iki düğüm de codec bileşeni B'yi seçecektir (Şekil 7). Bağlantı mantığı artık kurulmuştur ve medya akışları aktarılabilmektedir, ancak başka bir sorun daha vardır; düğümler hâlâ yalnızca bir sinyalleşme mekanizmasıyla birbirine bağlıdır.

Şekil 7: Codec anlaşması

Buz adayı

WebRTC teknolojisi yeni metodolojisiyle kafamızı karıştırmaya çalışıyor. Bağlantı kurarken bağlanmak istediğiniz düğümün adresi belirtilmez. İlk önce yüklendi mantıklı bağlantı değil fiziksel, her zaman tam tersi yapılmasına rağmen. Ancak üçüncü taraf bir sinyalleşme mekanizması kullandığımızı unutmazsak bu durum garip görünmeyecektir.

Yani bağlantı zaten kuruldu (mantıksal bağlantı), ancak ağ düğümlerinin veri iletebileceği bir yol henüz yok. Her şey o kadar basit değil ama basit bir şekilde başlayalım. Düğümlerin aynı özel ağda olmasına izin verin. Zaten bildiğimiz gibi, dahili IP adreslerini (veya TCP/IP kullanılmıyorsa belki başkalarını) kullanarak birbirlerine kolayca bağlanabilirler.

Bazı geri aramalar ve WebRTC aracılığıyla bizi Ice aday nesneleri hakkında bilgilendirir. Ayrıca metin biçiminde gelirler ve oturum tanımlayıcıları gibi, yalnızca bir sinyalleşme mekanizması yoluyla gönderilmeleri gerekir. Oturum tanımlayıcı, kamera ve mikrofon düzeyindeki ayarlarımız hakkında bilgi içeriyorsa, adaylar da ağdaki konumumuz hakkında bilgi içerir. Bunları başka bir düğüme aktardığınızda bize fiziksel olarak bağlanabilecek ve zaten bir oturum tanımlayıcısına sahip olduğundan mantıksal olarak bağlanabilecek ve veriler "akacak". Aday nesnesini, yani kendisinin ağda nerede olduğuna ilişkin bilgileri bize göndermeyi hatırlarsa, o zaman onunla bağlantı kurabileceğiz. Burada klasik istemci-sunucu etkileşiminden bir farklılığa daha değinelim. 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. WebRTC'de bilmeniz gerekenler iki adres ve onları her iki tarafa bağlayın.

Oturum tanımlayıcılarından farkı, yalnızca uzak adayların yüklenmesinin gerekmesidir. Burada düzenleme yapmak yasaktır ve herhangi bir fayda sağlamaz. Bazı WebRTC uygulamalarında adayların yalnızca oturum tanımlayıcıları ayarlandıktan sonra yüklenmesi gerekir.

Neden tek bir oturum tanımlayıcısı vardı ama çok sayıda aday olabiliyordu? Çünkü ağdaki konum yalnızca dahili IP adresiyle değil, aynı zamanda yönlendiricinin harici adresiyle ve yalnızca bir tane olması gerekmediği gibi TURN sunucularının adresleriyle de belirlenebilir. 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ğ üzerindedir (Şekil 8). Onları nasıl tanımlayabiliriz? IP adreslerini kullanma. Başka yol yok. Doğru, yine de farklı aktarımları (TCP ve UDP) ve farklı bağlantı noktalarını kullanabilirsiniz. Bu, aday nesnede bulunan bilgilerdir - IP, PORT, TRANSPORT ve diğerleri. Örneğin UDP aktarımını ve 531 numaralı bağlantı noktasını kullanalım.

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

Daha sonra p1 düğümündeysek WebRTC bize böyle bir aday nesne verecektir - . Bu kesin bir format değil, sadece bir diyagram. Eğer p2 düğümündeysek, aday . Sinyalleşme mekanizması aracılığıyla p1, p2'nin adayını (yani p2 düğümünün konumunu, yani IP'sini ve PORT'unu) alacaktır. Daha sonra p1 doğrudan p2'ye bağlanabilir. Daha doğrusu p1, p2'ye ulaşması umuduyla veriyi 10.50.150.3:531'e gönderecektir. Bu adresin p2 düğümüne mi yoksa bir aracıya mı ait olduğu önemli değildir. Önemli olan tek şey verilerin bu adres üzerinden gönderilip p2'ye ulaşabilmesidir.

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

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

Şekil 9: Bir düğüm NAT'ın arkasında, diğeri değil

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

Web sunucusunun doğrudan internete bağlı olduğunu, yani genel bir IP* adresine sahip olduğunu varsayalım. Bu düğüm p2 olsun. p1 düğümü (web istemcisi) 10.50.200.10 adresine bir istek gönderir. İlk olarak, veriler r1 yönlendiricisine veya daha doğrusu ona gider. iç mekan arayüz 192.168.0.1. Bundan sonra yönlendirici kaynak adresini (adres p1) hatırlar ve bunu özel bir NAT tablosuna girer, ardından kaynak adresini kendi adresiyle değiştirir (p1 → r1). Üstelik kendi yöntemimle harici arayüz, yönlendirici verileri doğrudan p2 web sunucusuna gönderir. Web sunucusu verileri işler, bir yanıt oluşturur ve geri gönderir. Dönüş adresinde olduğundan r1'i yönlendiriciye gönderir (yönlendirici adresi kendi adresiyle değiştirir). Yönlendirici verileri alır, NAT tablosuna bakar ve verileri p1 düğümüne iletir. Yönlendirici burada aracı görevi görür.

Peki ya iç ağdaki birden fazla düğüm aynı anda dış ağa erişirse? Yönlendirici yanıtı kime geri göndereceğini nasıl anlayacak? Bu sorun kullanılarak çözüldü limanlar. Bir yönlendirici, ana bilgisayar adresini kendi adresiyle değiştirdiğinde, bağlantı noktasının da yerini alır. Eğer iki düğüm İnternet'e erişiyorsa, yönlendirici bunların kaynak bağlantı noktalarını farklı. Daha sonra web sunucusundan gelen paket yönlendiriciye geri geldiğinde yönlendirici paketin kime atandığını porttan anlayacaktır. Aşağıdaki örnek.

WebRTC teknolojisine veya daha doğrusu onun ICE protokolünü kullanan kısmına (dolayısıyla Ice adaylarına) dönelim. P2 düğümünün bir adayı vardır (ağdaki konumu 10.50.200.10'dur) ve NAT'lı yönlendiricinin arkasında bulunan p1 düğümünün iki adayı olacaktır - yerel (192.168.0.200) ve yönlendirici adayı (10.50.200.5). İlki kullanışlı değildir, ancak WebRTC henüz uzak düğüm hakkında hiçbir şey bilmediğinden yine de oluşturulmuştur; aynı ağda olabilir veya olmayabilir. İkinci aday işe yarayacak ve zaten bildiğimiz gibi liman (NAT'tan geçmek için) önemli bir rol oynayacak.

NAT tablosundaki bir giriş yalnızca veriler dahili ağdan çıktığında oluşturulur. Bu nedenle, p1 düğümü verileri ilk önce iletmelidir ve ancak bundan sonra p2 düğümünden gelen veriler p1 düğümüne ulaşabilir.

Pratikte her iki düğüm NAT'ın arkasında olacak. Her yönlendiricinin NAT tablosunda bir giriş oluşturmak için, ana bilgisayarların uzaktaki ana bilgisayara bir şeyler göndermesi gerekir, ancak bu sefer ne birincisi ikincisine ne de tam tersi erişemez. Bunun nedeni, düğümlerin dış IP adreslerini bilmemeleri ve iç adreslere veri göndermenin anlamsız olmasıdır.

Ancak dış adreslerin bilinmesi durumunda bağlantı kolaylıkla kurulacaktır. İlk düğüm ikinci düğümün yönlendiricisine veri gönderirse, NAT tablosu hala boş olduğundan yönlendirici bunu görmezden gelecektir. Ancak ilk düğümün yönlendiricisinde NAT tablosunda gerekli bir giriş belirdi. Şimdi ikinci düğüm, ilk düğümün yönlendiricisine veri gönderirse, yönlendirici bunu başarıyla ilk düğüme aktaracaktır. Artık ikinci yönlendiricinin NAT tablosu da gerekli verilere sahiptir.

Sorun şu ki, harici IP adresinizi bulmak için, paylaşılan ağ. Bu sorunu çözmek için doğrudan internete bağlı ek sunucular kullanılır. Onların yardımıyla NAT tablosunda da değerli girişler oluşturulur.

STUN ve TURN sunucuları

WebRTC'yi başlatırken, bundan sonra ICE sunucuları olarak adlandıracağımız mevcut STUN ve TURN sunucularını belirtmeniz gerekir. Sunucular belirtilmezse, yalnızca aynı ağdaki (NAT olmadan bağlanan) düğümler bağlanabilecektir. 3g ağları için TURN sunucularının kullanımının zorunlu olduğunu hemen belirtmekte fayda var.

Sersemletme sunucu Basitçe İnternet üzerindeki bir dönüş adresini, yani gönderenin düğümünün adresini döndüren bir sunucudur. Yönlendiricinin arkasındaki ana bilgisayar, NAT'ı geçmek için STUN sunucusuyla iletişim kurar. STUN sunucusuna gelen paket, kaynak adresini - yönlendirici adresini, yani düğümümüzün harici adresini içerir. Bu, sunucunun geri gönderdiği STUN adresidir. Böylece düğüm, harici IP adresini ve ağdan erişilebildiği bağlantı noktasını alır. Daha sonra WebRTC, ek bir aday (harici yönlendirici adresi ve bağlantı noktası) oluşturmak için bu adresi kullanır. Artık yönlendiricinin NAT tablosunda, gerekli bağlantı noktasında yönlendiriciye gönderilen paketlerin düğümümüze ulaşmasını sağlayan bir giriş var.

Bu sürece bir örnekle bakalım.

Örnek (STUN sunucu işlemi)

STUN sunucusu s1 ile gösterilecektir. Yönlendirici, daha önce olduğu gibi, r1'den ve düğüm p1'den geçer. Ayrıca NAT tablosunu da izlemeniz gerekecek - bunu r1_nat olarak göstereceğiz. Ayrıca, bu tablo genellikle farklı alt ağ düğümlerinden birçok kayıt içerir - bunlar verilmeyecektir.

Yani başlangıçta boş bir r1_nat tablomuz var.

Tablo 2: Paket Başlığı

p1 düğümü bu paketi r1 yönlendiricisine gönderir (nasıl olursa olsun, farklı alt ağlar kullanabilir) farklı teknolojiler). Pakette belirtilen adres açıkça harici bir alt ağ için uygun olmadığından, yönlendiricinin Src IP kaynak adresini değiştirmesi gerekir; üstelik, böyle bir aralıktaki adresler ayrılmıştır ve İnternetteki tek bir adres böyle bir adrese sahip değildir. Yönlendirici pakette bir değişiklik yapar ve Yeni giriş tablonuzda r1_nat. Bunu yapmak için bir port numarası bulması gerekiyor. Bir alt ağdaki birden fazla ana bilgisayarın harici bir ağa erişebilmesi nedeniyle NAT tablosunun şunları kaydetmesi gerektiğini hatırlayın: Ek Bilgiler böylece yönlendirici bu birkaç düğümden hangisinin sunucudan dönüş paketi için yönlendirildiğini belirleyebilir. Yönlendiricinin 888 numaralı bağlantı noktasını bulmasına izin verin.

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

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

Burada alt ağın IP adresi ve bağlantı noktası orijinal paketle tamamen aynıdır. Aslında geri gönderme yaparken bunları tamamen geri yüklemenin bir yolunu bulmamız gerekir. Harici ağın IP adresi yönlendiricinin adresidir ve bağlantı noktası, yönlendirici tarafından icat edilen bağlantı noktasıyla değiştirilmiştir.

p1 düğümünün bağlantıyı kabul ettiği gerçek bağlantı noktası elbette 35777'dir, ancak sunucu veriyi hayali yönlendirici tarafından gerçek 35777 olarak değiştirilecek olan bağlantı noktası 888.

Böylece yönlendirici, paket başlığındaki kaynak adresini ve bağlantı noktasını değiştirdi ve NAT tablosuna bir giriş ekledi. Artık paket ağ üzerinden sunucuya yani s1 düğümüne gönderilir. Girişte s1 aşağıdaki pakete sahiptir:

Src IP Src PORT Hedef IP Hedef PORT

10.50.200.5	888	12.62.100.200	6000

Tablo 5: STUN sunucusu alınan paket

Toplamda STUN sunucusu 10.50.200.5:888 adresinden bir paket aldığını biliyor. Artık sunucu bu adresi geri gönderir. Burada durup az önce baktığımız şeye bir kez daha bakmakta fayda var. Yukarıdaki tablolar bir kesittir başlık paket, ondan hiç değil içerik. İçerik hakkında çok önemli olmadığı için konuşmadık - bir şekilde STUN protokolünde anlatılıyor. Şimdi başlığın yanı sıra içeriği de ele alacağız. Basit olacak ve yönlendirici adresini içerecektir - 10.50.200.5:888, ancak bunu şuradan aldık: başlık paket. Bu pek sık yapılmaz; protokoller genellikle düğüm adresleriyle ilgili bilgileri umursamaz; yalnızca paketlerin amaçlanan varış noktasına teslim edilmesi önemlidir. Burada iki düğüm arasında yol kuran bir protokole bakıyoruz.

Artık ters yöne giden ikinci bir paketimiz var:

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

Daha sonra paket, r1 yönlendiricisinin harici arayüzüne ulaşana kadar ağ boyunca dolaşır. Yönlendirici, paketin kendisine yönelik olmadığını anlar. Bunu nasıl anlıyor? Bu yalnızca bağlantı noktası tarafından belirlenebilir. 888 numaralı bağlantı noktasını kişisel amaçları için kullanmaz, ancak NAT mekanizması için kullanır. Bu nedenle yönlendirici bu tabloya bakar. Harici PORT sütununa bakar ve gelen paketteki Hedef PORT'la (888) eşleşen bir satır arar.

Dahili IP Dahili PORT Harici IP Harici PORT

192.168.0.200	35777	10.50.200.5	888

Tablo 8: NAT Tablosu

Şanslıyız ki böyle bir çizgi var. Eğer şanssız olsaydık, paket basitçe atılırdı. Şimdi bu paketi alt ağdaki hangi düğümün göndermesi gerektiğini anlamanız gerekiyor. Acele etmeye gerek yok, bu mekanizmada limanların önemini bir kez daha hatırlayalım. Aynı anda alt ağdaki iki düğüm, dış ağa istek gönderebilir. Ardından, yönlendirici ilk düğüm için 888 numaralı bağlantı noktasını bulursa, ikinci düğüm için 889 numaralı bağlantı noktasını bulur. Bunun gerçekleştiğini varsayalım, yani r1_nat tablosu şöyle görünür:

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

Src IP Src PORT Hedef IP Hedef PORT

12.62.100.200	6000	192.168.0.200	35777

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

Paket p1 düğümüne başarılı bir şekilde ulaşır ve paketin içeriğine bakarak düğüm kendi harici IP adresini, yani yönlendiricinin harici ağdaki adresini öğrenir. Ayrıca yönlendiricinin NAT üzerinden geçtiği bağlantı noktasını da biliyor.

Sıradaki ne? Bütün bunların ne faydası var? Avantaj, r1_nat tablosundaki bir giriştir. Şimdi herhangi biri 888 numaralı bağlantı noktasına sahip bir paketi r1 yönlendiricisine gönderirse, yönlendirici bu paketi p1 düğümüne iletecektir. Bu, gizli düğüm p1'e küçük, dar bir geçit yarattı.

Yukarıdaki örnekten NAT'ın nasıl çalıştığı ve STUN sunucusunun özü hakkında bir fikir edinebilirsiniz. Genel olarak ICE mekanizması ve STUN/TURN sunucuları tam olarak NAT kısıtlamalarının üstesinden gelmeyi amaçlamaktadır.

Düğüm ile sunucu arasında bir değil birkaç yönlendirici olabilir. Bu durumda düğüm, sunucuyla aynı ağa ilk erişen yönlendiricinin adresini alacaktır. Yani STUN sunucusuna bağlı yönlendiricinin adresini alacağız. P2p iletişimi için her yönlendiricinin ihtiyacımız olan satırı NAT tablosuna ekleyeceği gerçeğini unutmazsak tam olarak ihtiyacımız olan şey budur. Bu nedenle dönüş yolu yine sorunsuz olacak.

TURN sunucusu geliştirilmiş bir STUN sunucusudur. Buradan herhangi bir TURN sunucusunun aynı zamanda STUN sunucusu olarak da çalışabileceğini hemen anlamalısınız. Ancak avantajları da var. P2p iletişimi imkansızsa (örneğin 3g ağlarında olduğu gibi), sunucu aktarma moduna geçer, yani aracı olarak çalışır. Tabii o zaman herhangi bir p2p'den bahsetmiyoruz ama ICE mekanizması dışında node'lar doğrudan iletişim kurduklarını düşünüyor.

Hangi durumlarda TURN sunucusu gereklidir? Neden yeterli STUN sunucusu yok? Gerçek şu ki, birkaç tür NAT vardır. IP adresini ve bağlantı noktasını aynı şekilde değiştirirler, ancak bazılarında "sahtekarlığa" karşı ek koruma yerleşiktir. Örneğin, simetrik NAT tablosu 2 parametreyi daha saklar - uzak düğümün IP'si ve bağlantı noktası. Harici ağdan gelen bir paket, yalnızca kaynak adresi ve bağlantı noktası tabloda kaydedilenlerle eşleştiğinde NAT üzerinden dahili ağa geçer. Bu nedenle, STUN sunucusundaki numara başarısız olur - NAT tablosu, STUN sunucusunun adresini ve bağlantı noktasını saklar ve yönlendirici, WebRTC muhatabından bir paket aldığında, "sahte" olduğu için onu atar. STUN sunucusundan gelmedi.

Bu nedenle, her iki muhatabın da geride olması durumunda bir TURN sunucusuna ihtiyaç vardır. simetrik NAT (her biri kendine ait).

Kısa özet

WebRTC varlıkları hakkında her zaman aklınızda bulundurmanız gereken bazı ifadeleri burada bulabilirsiniz. Bunlar yukarıda ayrıntılı olarak açıklanmıştır. İfadelerden herhangi biri size tam olarak açık gelmiyorsa ilgili paragrafları tekrar okuyun.

• Medya akışı
  • Video ve ses verileri medya akışları halinde paketlenir
  • Medya akışları, oluşan medya parçalarını senkronize eder
  • Farklı medya akışları birbiriyle senkronize edilmez
  • Medya akışları yerel ve uzak olabilir, yerel olan genellikle bir kamera ve mikrofona bağlanır, uzak olanlar ağdan şifrelenmiş biçimde veri alır
  • Video ve ses için olmak üzere iki tür medya parçası vardır.
  • Medya parçaları açma/kapama özelliğine sahiptir
  • Medya parçaları medya kanallarından oluşur
  • Medya parçaları, onları 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ısı aşağıdakilerle ilgili bilgileri saklar: mevcut yollar video ve ses verilerini kodlama
  • WebRTC harici bir sinyalleşme mekanizması kullanır; oturum tanımlayıcılarını (sdp) iletme görevi uygulamaya düşer
  • Mantıksal bağlantı mekanizması iki aşamadan oluşur - teklif (teklif) ve yanıt (cevap)
  • Bir teklif durumunda yerel medya akışı kullanılmadan oturum tanımlayıcısının oluşturulması, yanıt durumunda ise uzak oturum tanımlayıcısı kullanılmadan mümkün değildir.
  • Ortaya çıkan tanımlayıcının WebRTC uygulamasına verilmesi gerekir ve bu tanımlayıcının aynı WebRTC uygulamasından uzaktan mı yoksa yerel olarak mı alındığı önemli değildir.
  • Oturum tanımlayıcısını biraz düzenlemek mümkündür
• Adaylar
  • Ice adayı ağdaki bir düğümün adresidir
  • Düğüm adresi size ait olabileceği gibi bir yönlendiricinin veya TURN sunucusunun adresi de olabilir.
  • Her zaman birçok aday vardır
  • Aday bir IP adresi, bağlantı noktası ve aktarım türünden (TCP veya UDP) oluşur
  • Adaylar bir ağdaki iki düğüm arasında fiziksel bir bağlantı kurmak için kullanılır
  • Adayların ayrıca bir sinyalizasyon mekanizması aracılığıyla gönderilmesi gerekmektedir.
  • Adayların ayrıca WebRTC uygulamalarına da geçmesi gerekiyor, ancak yalnızca uzak uygulamalara
  • Bazı WebRTC uygulamalarında adaylar yalnızca bir oturum tanımlayıcısı ayarlandıktan sonra iletilebilir.
• STUN/DÖNÜŞ/BUZ/NAT
  • NAT, harici bir ağa erişim sağlamaya yönelik bir mekanizmadır
  • Ev yönlendiricileri özel bir NAT tablosunu destekler
  • Yönlendirici, paketlerdeki adresleri değiştirir - paket harici bir ağa gidiyorsa kaynak adresi kendi adresiyle ve paket harici bir ağdan geldiyse alıcı adresi dahili ağdaki ana bilgisayar adresiyle değiştirilir.
  • NAT, harici bir ağa çok kanallı erişim sağlamak için bağlantı noktalarını kullanır
  • ICE - NAT Çapraz Motor
  • STUN ve TURN sunucuları – NAT geçişi için yardımcı sunucular
  • STUN sunucusu, NAT tablosunda gerekli girişleri oluşturmanıza olanak tanır ve ayrıca ana bilgisayarın harici adresini de döndürür
  • TURN sunucusu STUN mekanizmasını genelleştirir ve her zaman çalışmasını sağlar
  • En kötü durumlarda TURN sunucusu aracı (röle) olarak kullanılır, yani p2p istemci-sunucu-istemci bağlantısına dönüşür.

Bugün WebRTC, tarayıcılarda ses ve video akışı için en popüler teknolojidir. HTTP Akışı ve Flash gibi muhafazakar teknolojiler, kayıtlı içeriğin (talep üzerine video) dağıtımı için daha uygundur ve gerçek zamanlı ve çevrimiçi yayınlar açısından WebRTC'den önemli ölçüde daha düşüktür; İzleyicilerin olup biteni "canlı" olarak görebilmesi için minimum video gecikmesinin gerekli olduğu yer.

Yüksek kaliteli gerçek zamanlı iletişim olasılığı, video akışlarını taşımak için UDP protokolünün kullanıldığı WebRTC mimarisinden gelir; bu, minimum gecikmeyle video aktarımı için standart temeldir ve gerçek zamanlı iletişim sistemlerinde yaygın olarak kullanılır.

Çevrimiçi yayın sistemlerinde, web seminerlerinde ve video kaynağıyla, son kullanıcılarla etkileşimli iletişim gerektiren ve çözüm gerektiren diğer uygulamalarda iletişim gecikmesi önemlidir.

WebRTC'yi denemenin bir başka iyi nedeni de bunun kesinlikle bir trend olmasıdır. Bugün her Android Chrome tarayıcı milyonlarca cihazın herhangi bir ek yazılım veya konfigürasyon kurmadan yayını izlemeye hazır olmasını garanti eden bu teknolojiyi desteklemektedir.

WebRTC teknolojisini çalışırken test etmek ve basit bir işlemi çalıştırmak için çevrimiçi yayın Flashphoner WebRTC Media & Broadcasting Server sunucu yazılımını kullandık. Özellikler, WebRTC akışlarını bire çok modunda yayınlama yeteneğinin yanı sıra RTSP protokolü aracılığıyla IP kameralar ve video gözetim sistemlerine yönelik desteği belirtir; Bu incelememizde web-web yayınları ve özellikleri üzerinde duracağız.

WebRTC Medyasını ve Yayın Sunucusunu Kurma

Çünkü için Windows sistemleri sunucu sürümü yoktu ve çevrimiçi yayınları evde test edebilmek için VMWare+Linux gibi bir sanal makine kurmak istemedim Windows bilgisayarıİşe yaramadı. Zamandan tasarruf etmek için bulut barındırmada şu şekilde bir örnek almaya karar verdik:

Amsterdam veri merkezinde önceden yüklenmiş herhangi bir yazılım bulunmayan Centos x86_64 sürüm 6.5'ti. Dolayısıyla elimizde olan tek şey sunucu ve ona ssh erişimidir. Bilenler için konsol komutları Linux WebRTC'yi yükleme Sunucu basit ve ağrısız olmayı vaat ediyor. Peki ne yaptık:

1. Arşivi indirin:

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

2. Paketi açın:

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

3. Yükleyin:

$cd FlashphonerWebCallServer

Kurulum sırasında sunucunun IP adresini girin: XXX.XXX.XXX.XXX

4. Lisansı etkinleştirin:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. WCS sunucusunu başlatın:

$service web çağrısı sunucusu başlangıcı

6. Günlüğü kontrol edin:

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

7. İki sürecin yürürlükte olup olmadığını kontrol edin:

$ps yardımcı | grep Flashphoner

Kurulum işlemi tamamlandı.

WebRTC çevrimiçi yayınlarını test etme

Yayınları test etmenin basit bir mesele olduğu ortaya çıktı. Sunucuya ek olarak, bir düzine Javascript, HTML ve CSS dosyasından oluşan ve kurulum aşamasında /var/www/html klasörüne tarafımızdan konuşlandırılan bir web istemcisi bulunmaktadır. Yapılması gereken tek şey, web istemcisinin HTML5 Websockets aracılığıyla sunucuyla bağlantı kurabilmesi için sunucunun IP adresini flashphoner.xml yapılandırmasına girmekti. Test sürecini anlatalım.

1. Chrome tarayıcısında index.html test istemcisi sayfasını açın:

2. Yayına başlamak için ekranın ortasında yer alan “Başlat” butonuna tıklamanız gerekmektedir.
Bunu yapmadan önce web kamerasının bağlı ve kullanıma hazır olduğundan emin olmanız gerekir. Web kamerası için özel bir gereklilik yok; örneğin, 1280x800 çözünürlüklü bir dizüstü bilgisayara yerleşik standart bir kamera kullandık.

Kullanıcının videosunun İnternet sunucusuna gönderileceğini anlaması ve buna izin vermesi için Chrome tarayıcısı kesinlikle kamera ve mikrofona erişim isteyecektir.

3. Arayüz, video akışının kameradan WebRTC sunucusuna başarılı bir şekilde yayınlandığını temsil eder. Sağ üst köşede, akışın sunucuya gittiğini belirten bir gösterge; alt köşede ise videonun gönderilmesini durdurmak için bir “Durdur” düğmesi bulunmaktadır.

Lütfen aşağıdaki kutudaki bağlantıya dikkat edin. Bu akış için benzersiz bir tanımlayıcı içerir, böylece herkes görüntülemeye katılabilir. Bu bağlantıyı tarayıcınızda açmanız yeterli. Panoya kopyalamak için “Kopyala” düğmesine tıklayın.

Web seminerleri, dersler, çevrimiçi video yayınları veya etkileşimli TV gibi gerçek uygulamalarda, geliştiricilerin, istenen akışlara bağlanabilmeleri için bu tanımlayıcının belirli izleyici gruplarına dağıtımını uygulaması gerekecektir, ancak bu zaten uygulamanın mantığıdır. . WebRTC Medya ve Yayın Sunucusu bunu etkilemez, yalnızca videoyu dağıtır.

5. Bağlantı kurulur ve izleyici akışı ekranda görür. Artık sağ alt köşedeki kontrolleri kullanarak başka birine bağlantı gönderebilir, akışın oynatılmasını durdurabilir veya tam ekran modunu etkinleştirebilir.

WebRTC çevrimiçi yayın sunucusunu test etme sonuçları

Testler sırasında gecikme mükemmel görünüyordu. Veri merkezine gönderilen ping yaklaşık 100 milisaniyeydi ve gecikme gözle görülemezdi. Buradan, gerçek gecikmenin ara belleğe alma süresi için aynı 100 artı veya eksi birkaç on milisaniye olduğunu varsayabiliriz. Flash videoyla karşılaştırıldığında: Bu tür testlerde Flash, WebRTC kadar iyi davranmıyor. Yani benzer bir ağ üzerinde elinizi hareket ettirdiğinizde ekrandaki hareket ancak bir veya iki saniye sonra görülebiliyor.

Kaliteye gelince, küplerin bazen hareketlerle ayırt edilebildiğini görüyoruz. Bu, VP8 kodlayıcının doğası ve ana amacı olan kabul edilebilir kalitede ve iletişim gecikmeleri olmadan gerçek zamanlı video iletişimi sağlamak ile tutarlıdır.

Sunucunun kurulumu ve yapılandırılması oldukça kolaydır; çalıştırılması, ssh aracılığıyla konsoldan komutları çalıştırabilen ve kullanabilen ileri düzey bir kullanıcı düzeyinde Linux bilgisi dışında ciddi bir beceri gerektirmez. Metin düzeltici. Sonuç olarak tarayıcılar arasında birebir çevrimiçi yayın kurmayı başardık. Yayına başka izleyicilerin bağlanması da herhangi bir sorun yaratmadı.

Yayın kalitesinin web seminerleri ve çevrimiçi yayınlar için oldukça kabul edilebilir olduğu ortaya çıktı. Bazı soruları gündeme getiren tek şey video çözünürlüğüydü. Kamera 1280x800'ü destekliyor ancak test görüntüsündeki çözünürlük 640x480'e çok benziyor. Görünüşe göre bu sorunun geliştiricilerle açıklığa kavuşturulması gerekiyor.

Bir web kamerasından yapılan test yayınını gösteren video
WebRTC sunucusu aracılığıyla

Tarayıcıdan arama yapmaya yönelik teknolojiler uzun yıllardan beri kullanılmaktadır: Java, ActiveX, Adobe Flash...Son birkaç yılda eklentilerin ve sol Sanal makineler Kolaylıkla parlamıyorlar (neden herhangi bir şey kurmalıyım?) ve en önemlisi güvenlik açısından parlamıyorlar. Ne yapalım? Bir çıkış var!

Yakın zamana kadar IP ağları, IP telefon veya video için çeşitli protokoller kullanıyordu: SIP, en yaygın protokol, H.323 ve MGCP sahneye çıkıyor, Jabber/Jingle (Gtalk'ta kullanılıyor), yarı açık Adobe RTMP* ve tabii ki , Skype'ı kapattı. Google tarafından başlatılan WebRTC projesi, IP ve web telefonu dünyasındaki durumu değiştirmeye çalışıyor; yazılım telefonları Skype dahil. WebRTC yalnızca tüm iletişim yeteneklerini doğrudan tarayıcının içinde uygulamakla kalmıyor, bu artık hemen hemen her cihazda kuruludur, aynı zamanda tarayıcı kullanıcıları arasındaki daha genel bir iletişim sorununu (çeşitli veri alışverişi, ekran yayını, belgelerle işbirliği ve vb.) eş zamanlı olarak çözmeye çalışır. daha fazla).

Web geliştiricisinin bakış açısından WebRTC

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

• Yerel kaynaklardan (kamera, mikrofon veya ekran) medya akışlarının kontrolü yerel bilgisayar) bir MediaStream nesnesi döndüren navigator.getUserMedia yöntemi tarafından uygulanır;
• Medya akışları üreten cihazlar arasında, iletişim yöntemlerinin tanımlanması ve bunların doğrudan iletilmesi de dahil olmak üzere eşler arası iletişim - RTCPeerConnection nesneleri (ses ve video akışlarını 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 tabanlı tarayıcılar arasında basit, çok kullanıcılı bir görüntülü sohbetin nasıl düzenleneceğini bulacağız. Her ne kadar 24 Haziran'da yayınlanan Firefox 22 neredeyse onları yakalamış olsa da, WebRTC açısından en gelişmiş tarayıcılar olan Chrome/Chromium'da denemelere başlayacağız. Standardın henüz benimsenmediğini ve API'nin versiyondan versiyona değişebileceğini söylemek gerekir. 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ının yerel bilgisayarın kamera ve mikrofonundan medya akışlarına erişmesini sağlar. Chrome'da bunun için navigator.webkitGetUserMedia() işlevini çağırmanız gerekir (standart henüz kesinleşmediğinden, tüm işlevler bir önekle birlikte gelir ve Firefox'ta aynı işlev navigator.mozGetUserMedia() olarak adlandırılır). Aradığınızda kullanıcıdan kamera ve mikrofona erişime izin vermesi istenecektir. Görüşmeye ancak kullanıcı onay verdikten sonra devam etmek mümkün olacaktır. Gerekli medya akışının parametreleri ve iki geri çağırma işlevi, bu işleve parametre olarak aktarılır: birincisi, kameraya/mikrofona erişim başarılı bir şekilde elde edilirse, ikincisi ise bir hata durumunda çağrılacaktır. İlk olarak, bir düğme ve bir öğe içeren bir rtctest1.html HTML dosyası oluşturalım:

WebRTC - ilk tanıtım videosu ( yükseklik: 240 piksel; genişlik: 320 piksel; kenarlık: 1 piksel düz gri; ) getUserMedia

Microsoft CU-RTC-Web

Microsoft, Google'ın girişimine CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web) adı verilen kendi uyumsuz, standart dışı seçeneğini yayınlayarak hemen yanıt vermeseydi, Microsoft olmazdı. htm). IE'nin zaten küçük olan payı düşmeye devam etse de, Skype kullanıcılarının sayısı Microsoft'a Google'ın yerini alma umudu veriyor ve bu özel standardın tarayıcıda kullanılacağı varsayılabilir. Skype sürümleri. Google standardı öncelikle tarayıcılar arasındaki iletişime odaklanmıştır; Aynı zamanda, ses trafiğinin büyük bir kısmı hala normal telefon ağında kalıyor ve bu ağ ile 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 telefonla iletişim kurmasını sağlayacak bir para kazanma aracı olarak da ihtiyaç duyuluyor. onları geliştirin. Başka bir standardın ortaya çıkması, geliştiricilerin iki uyumsuz teknolojiyi aynı anda desteklemesi yönündeki hoş olmayan ihtiyaca yol açmakla kalmayacak, aynı zamanda gelecekte kullanıcıya daha geniş bir olası işlevsellik ve mevcut teknik çözümler seçeneği sunacaktır. Bekle ve gör.

Yerel Akışı Etkinleştirme

HTML dosyamızın etiketlerinin içinde medya akışı için global bir değişken tanımlayalım:

Var localStream = null;

getUserMedia yönteminin ilk parametresi, istenen medya akışının parametrelerini belirtmelidir; örneğin, ses veya videoyu etkinleştirmeniz yeterlidir:

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

Veya ek parametreler belirtin:

Var StreamConstraints = ( "audio": true, "video": ( "zorunlu": ( "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5"), "isteğe bağlı": ) );

getUserMedia yönteminin ikinci parametresi, başarılı olması durumunda çağrılacak olan geri çağırma işlevine iletilmelidir:

Function getUserMedia_success(stream) ( console.log("getUserMedia_success():",stream); localVideo1.src = URL.createObjectURL(stream); // Medya akışını HTML öğesine localStream = flow; // bağlayın ve kaydedin daha fazla kullanım için global bir değişkende)

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

Function getUserMedia_error(error) ( console.log("getUserMedia_error():", error); )

getUserMedia yöntemine yapılan asıl çağrı, ilk düğmeye basıldığında mikrofona ve kameraya erişim isteğidir

İşlev getUserMedia_click() ( 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 beliren isteğe yanıt olarak kamera ve mikrofona erişime izin verelim.

Chrome'un erişebileceği cihazları 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şime izin verildiğinde cihazlar doğrudan açılır listeden seçilir.

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

Yer imi simgesindeki titreşen 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 iletmek için tasarlanmış bir nesnedir. Ek olarak, bu nesne bir medya oturumu açıklaması (SDP) oluşturmaktan, NAT'ı geçmek için ICE adayları hakkında bilgi edinmekten veya güvenlik duvarları(yerel ve STUN kullanarak) ve TURN sunucusuyla etkileşim. Her katılımcının bağlantı başına bir RTCMediaConnection'ı olması gerekir. Medya akışları şifrelenmiş SRTP protokolü kullanılarak iletilir.

TURN sunucuları

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

192.168.1.37 adresi ve udp/34022 bağlantı noktasıyla ana bilgisayar türündeki bir ICE adayı örneği:

A=aday:337499441 2 udp 2113937151 192.168.1.37 34022 tipik ana bilgisayar oluşturma 0

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

Var sunucuları = ( "iceServers": [ ( "url": "stun:stun.stunprotocol.org:3478" ), ( "url": "turn:user@host:port", "credential": "password" ) ]);

İnternette çok sayıda halka açık STUN sunucusu vardır. Mesela geniş bir liste var. Ne yazık ki çok az sorunu çözüyorlar. STUN'un aksine neredeyse hiç halka açık TURN sunucusu yok. Bunun nedeni, TURN sunucusunun hem ağ kanalını hem de sunucunun kendisini önemli ölçüde yükleyebilen medya akışlarından geçmesidir. Bu nedenle, TURN sunucularına bağlanmanın en kolay yolu, onu kendiniz kurmaktır (tabii ki, genel bir IP'ye ihtiyacınız olacaktır). Bana göre tüm sunucular arasında en iyisi rfc5766-turn-server'dır. Amazon EC2 için hazır bir görüntü bile var.

TURN ile her şey istediğimiz kadar iyi değil, ancak aktif bir gelişme sürüyor ve bir süre sonra WebRTC'nin, adres çevirisi (NAT) ve güvenlik duvarları aracılığıyla geçiş kalitesi açısından Skype'a eşit olmasa da olacağını umuyorum. , en azından farkedilir şekilde yaklaşacaktır.

RTCMediaConnection, bir bağlantı kurmak için kontrol bilgilerinin alışverişi için ek bir mekanizma gerektirir; bu verileri oluştursa da iletmez ve diğer katılımcılara iletimin ayrı olarak uygulanması gerekir.

Aktarım yönteminin seçimi geliştiriciye aittir - en azından manuel olarak. Gerekli veri alışverişi gerçekleşir gerçekleşmez, RTCMediaConnection medya akışlarını otomatik olarak kuracaktır (tabii ki mümkünse).

teklif-cevap modeli

Medya akışlarını oluşturmak ve değiştirmek için teklif/cevap modeli (RFC3264'te açıklanmıştır) ve SDP (Oturum Açıklama Protokolü) kullanılır. Ayrıca SIP protokolü tarafından da kullanılırlar. Bu modelde iki aracı vardır: Teklif Veren - yeni bir tane oluşturmak veya mevcut olanı değiştirmek için oturumun SDP açıklamasını oluşturan kişi (SDP Teklifi) ve Yanıtlayıcı - oturumun SDP açıklamasını alan kişi başka bir temsilci ve kendi oturum açıklamasıyla yanıt verir (Answer SDP). Aynı zamanda, spesifikasyon, SDP'nin aracılar arasında iletilmesinden sorumlu olan daha yüksek düzeyde bir protokol (örneğin, SIP veya bizim durumumuzda olduğu gibi kendi web soketleri üzerinden) 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 ilk katılımcı, iletmeye başlamak üzere olduğu medya akışının olası özelliklerini açıklayan bir SDP veri yapısını (SIP'de aynı protokol aynı amaç için 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 kendilerine bir medya akışı iletebilmesinin yardımıyla olası ICE adaylarını belirleme prosedürünü gerçekleştirir. Adaylar belirlendikçe onlarla ilgili bilgiler başka bir katılımcıya aktarılmalıdır.

Formasyon Teklifi

Teklif oluşturmak için iki fonksiyona ihtiyacımız var. Başarılı bir şekilde oluşturulmuşsa ilki çağrılacaktır. createOffer() yönteminin ikinci parametresi, yürütülmesi sırasında bir hata olması durumunda çağrılan bir geri çağırma işlevidir (yerel iş parçacığının zaten mevcut olması şartıyla).

Ek olarak iki olay işleyiciye ihtiyaç vardır: yeni bir ICE adayı tanımlarken onicecandidate ve uzak taraftan bir medya akışına bağlanırken onaddstream. Dosyamıza geri dönelim. Öğelerin bulunduğu satırlardan sonra HTML'ye bir tane daha ekleyelim:

teklif oluştur

Ve öğenin bulunduğu satırdan sonra (gelecek için):

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

Var pc1;

RTCPeerConnection yapıcısını çağırırken STUN/TURN sunucularını belirtmeniz gerekir. Bunlar hakkında daha fazla bilgi için kenar çubuğuna bakın; tüm katılımcılar aynı ağda olduğu sürece bunlara gerek yoktur.

Var sunucuları = null;

Teklif SDP'sinin hazırlanmasına ilişkin parametreler

Var OfferConstraints = ();

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

Function pc1_createOffer_success(desc) ( console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Offer SDP tarafından oluşturulan RTCPeerConnection'ı ayarlayın setLocalDescription yöntemini kullanarak // Uzak taraf Yanıt SDP'sini gönderdiğinde, setRemoteDescription yöntemini kullanarak ayarlanması gerekecektir. // İkinci taraf uygulanana kadar hiçbir şey yapmayız // pc2_receivedOffer(desc);

İkinci parametre ise hata durumunda çağrılacak olan geri çağırma fonksiyonudur.

Function pc1_createOffer_error(error)( console.log("pc1_createOffer_success_error(): error:", error); )

Ve ICE adaylarının belirlendikçe aktarılacağı bir geri çağırma fonksiyonu ilan edelim:

Function 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 yapmıyoruz // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)) ))

Ayrıca uzak taraftan bir medya akışı eklemek için bir geri çağırma işlevi (gelecek için, çünkü şimdilik yalnızca bir RTCPeerConnection'ımız var):

Function pc1_onaddstream(event) ( console.log("pc_onaddstream()"); RemoteVideo1.src = URL.createObjectURL(event.stream); )

“createOffer” butonuna tıkladığınızda, bir RTCPeerConnection oluşturacağız, onicecandidate ve onaddstream yöntemlerini ayarlayacağız ve createOffer() yöntemini çağırarak bir Offer SDP oluşturulmasını talep edeceğiz:

CreateOffer_click() işlevi ( console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(sunucular); // RTCPeerConnection oluştur pc1.onicecandidate = pc1_onicecandidate; // ICE adaylarını işlemek için geri çağırma işlevi pc1.onaddstream = pc1_onaddstream; // Uzak taraftan bir medya akışı göründüğünde çağrılan geri çağırma işlevi Henüz yok pc1.addStream(localStream); // Yerel medya akışını aktaracağız (zaten alındığını varsayarak) pc1.createOffer(// Ve aslında. Offer pc1_createOffer_success, pc1_createOffer_error, OfferConstraints oluşumunu talep edin)

Dosyayı rtctest2.html olarak kaydedelim, sunucuya yükleyelim, bir tarayıcıda açalım ve işlemi sırasında hangi verilerin oluşturulduğunu konsolda görelim. Yalnızca bir katılımcı olduğu için ikinci video henüz görünmeyecek. SDP'nin bir medya oturumunun parametrelerinin bir açıklaması olduğunu, mevcut codec bileşenlerinin, medya akışlarının ve ICE adaylarının belirli bir katılımcıya bağlanmak için olası seçenekler olduğunu hatırlayalım.

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

Hem Offer SDP'nin hem de ICE adaylarının her birinin diğer tarafa aktarılması gerekir ve orada, bunları aldıktan sonra RTCPeerConnection, Offer SDP için setRemoteDescription yöntemlerini ve uzak taraftan alınan her ICE adayı için addIceCandidate yöntemlerini çağırır; benzer şekilde ters taraf Answer SDP ve uzak ICE adayları için. Cevap SDP'sinin kendisi Teklife benzer şekilde oluşturulmuştur; Aradaki fark, çağrılanın createOffer yöntemi değil, createAnswer yöntemi olması ve bundan önce RTCPeerConnection yöntemi setRemoteDescription'ın arayan kişiden alınan Offer SDP'ye iletilmesidir.

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

Ve birincinin bildirimi kapsamında ikinci RTCPeerConnection için global bir değişken:

Var pc2;

Teklif ve Cevap SDP işleme

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

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

Yanıt oluşturulurken bir hata olması durumunda çağrılan geri arama işlevi, Teklif işlevine tamamen benzer:

Function pc2_createAnswer_error(error) ( console.log("pc2_createAnswer_error():", error); )

Cevap SDP'sini oluşturmaya yönelik parametreler:

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

İkinci katılımcı Teklifi aldığında, bir RTCPeerConnection oluşturacağız ve Teklifle aynı şekilde bir Cevap oluşturacağız:

Function pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // İkinci katılımcı için ilk katılımcıyla aynı şekilde bir RTCPeerConnection nesnesi oluşturun pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onicecandidate ; // ICE adayı göründüğünde olay işleyicisini ayarlayın pc2.onaddstream = pc_onaddstream; // Bir akış göründüğünde, onu HTML'ye bağlayın pc2.addStream(localStream); // Yerel medya akışını aktarın (örneğimizde, ikinci); katılımcı birincinin aynısına sahip) // Şimdi ikinci RTCPeerConnection hazır olduğunda, ona alınan Teklif SDP'sini ileteceğiz (yerel akışı ilkine aktardık) pc2.setRemoteDescription(new RTSessionDescription(desc)); // Yanıt mesajı için veri oluşturmak üzere ikinci bağlantıyı talep edin pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints);

Örneğimizde Teklif SDP'sini ilk katılımcıdan ikinciye aktarmak için pc1 fonksiyonunda açıklamayı kaldıralım. teklif oluştur başarı() çağrı hattı:

Pc2_receivedOffer(desc);

ICE adaylarının işlenmesini uygulamak için, ilk katılımcı pc1_onicecandidate()'in ICE aday hazırlığı olay işleyicisinde bunun ikinciye aktarılmasını kaldıralım:

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

İkinci katılımcının ICE adayı hazırlık olayı işleyicisi birincinin aynasına benzer:

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

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

Function pc2_onaddstream(event) ( console.log("pc_onaddstream()"); RemoteVideo2.src = URL.createObjectURL(event.stream); )

Bağlantıyı sonlandırma

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

Telefonu kapatmak

Ve bağlantıyı sonlandıracak bir işlev

Function btnHangupClick() ( // Yerel videonun HTML öğeleriyle bağlantısını kesin, yerel medya akışını durdurun, set = null localVideo1.src = ""; localStream.stop(); localStream = null; // Her katılımcı için HTML'den videoyu devre dışı bırakın öğeleri, bağlantıyı kapatın, işaretçiyi ayarlayın = null uzakVideo1.src = ""; pc1 = uzakVideo2.src = "";

Rtctest3.html olarak kaydedip sunucuya yükleyelim ve tarayıcıda açalım. Bu örnek, aynı tarayıcı sekmesindeki iki RTCPeerConnection arasında medya akışlarının iki yönlü aktarımını gerçekleştirir. Teklif ve Cevap SDP'sinin, ICE adaylarının katılımcılar arasında ve diğer bilgilerin ağ üzerinden değişimini organize etmek için, doğrudan arama prosedürleri yerine, katılımcılar arasındaki alışverişi bizim durumumuzda web soketleri gibi bir tür taşıma kullanarak uygulamak gerekli olacaktır.

Ekran yayını

getUserMedia işlevi ayrıca aşağıdaki parametreleri belirterek ekranı yakalayabilir ve MediaStream olarak akışı gerçekleştirebilir:

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

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

• chrome://flags/,chrome://flags/'de getUserMedia()'da ekran görüntüsü işaretini etkinleştirin;
• kaynak dosyanın HTTPS (SSL kaynağı) aracılığıyla indirilmesi gerekir;
• ses akışı talep edilmemelidir;
• Bir tarayıcı sekmesinde birden fazla istek yürütülmemelidir.

WebRTC için kütüphaneler

WebRTC henüz bitmemiş olsa da, onu temel alan çeşitli kütüphaneler halihazırda ortaya çıkmıştır. 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ı oluşturmayı kolaylaştıracak ve Holla, tarayıcılardan P2P iletişimleri için gereken geliştirme miktarını azaltacak.

Node.js ve Socket.io

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

Node.js'nin en son kararlı sürümünün (Debian/Ubuntu için) nasıl kurulacağı anlatılıyor

$ sudo apt-get install python-yazılım-özellikleri python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get güncelleme $ sudo apt-get install nodejs

Diğerleri için kurulum işletim sistemi tarif edildi

Hadi kontrol edelim:

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

Npm'yi (Düğüm Paketi Yöneticisi) kullanarak Socket.io'yu ve ek express modülünü kuracağız:

$ npm soket.io express'i yükleyin

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

$ nano nodetest2.js var app = require("express")() , sunucu = require("http").createServer(app) , io = require("socket.io").listen(server); sunucu.listen(80); // 80 numaralı bağlantı noktası boşsa app.get("/", function (req, res) ( // Kök sayfaya erişirken res.sendfile(__dirname + "/nodetest2.html"); // HTML dosyasını gönder ) ) ); io.sockets.on("bağlantı", fonksiyon (soket) ( // Socket.emit("sunucu olayı", (merhaba: "dünya" )); // mesaj gönder soket.on("istemci olayı" , function (data) ( // ve istemciden bir mesaj geldiğinde bir olay işleyicisi bildirin console.log(data); ));

Ve istemci tarafı için nodetest2.html:

$ nano nodetest2.html var soket = io.connect("/"); // Websocket sunucu URL'si (sayfanın yüklendiği sunucunun kök sayfası) Socket.on("sunucu olayı", fonksiyon (veri) ( console.log(veri); soket.emit("istemci olayı", ( " isim": "değer" ));

Sunucuyu başlatalım:

$ sudo nodejs nodetest2.js

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

RTCPeerConnection arasında web soketleri aracılığıyla bilgi alışverişi İstemci kısmı

Ana örneğimizi (rtcdemo3.html) rtcdemo4.html yeni adı altında kaydedelim. Elemente Socket.io kütüphanesini ekleyelim:

Ve JavaScript betiğinin başında - websocket'lere bağlanma:

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

Başka bir katılımcının işlevlerine doğrudan çağrıyı, ona web soketleri aracılığıyla bir mesaj göndererek değiştirelim:

Function createOffer_success(desc) ( ... // pc2_receivedOffer(desc); soket.emit("offer", desc); ... ) function pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); soket .emit("cevap", desc); ) 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() fonksiyonunda, ikinci katılımcının fonksiyonlarını doğrudan çağırmak yerine, web soketleri aracılığıyla bir mesaj ileteceğiz:

İşlev btnHangupClick() ( ... // RemoteVideo2.src = ""; pc2.close(); pc2 = null; soket.emit("kapat", ()); )

Ve mesaj alma işleyicilerini ekleyin:

Socket.on("teklif", fonksiyon (veri) ( console.log("socket.on("teklif"):", veri); pc2_receivedOffer(veri); )); Socket.on("answer", function (data) (е console.log("socket.on("answer"):", data); pc1.setRemoteDescription(new RTSessionDescription(data)); )); Socket.on("ice1", function (data) ( console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); )); Socket.on("ice2", function (data) ( console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); )); Socket.on("hangup", function (data) ( console.log("socket.on("hangup"):", data); RemoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Sunucu kısmı

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 ekleyeceğiz:

Socket.on("offer", function (data) ( // "offer" mesajını aldığımızda, // bu örnekte tek client bağlantısı olduğundan, // mesajı aynı soket soketi üzerinden geri göndereceğiz .emit("offer" , data); // Mesajın gönderen hariç tüm bağlantılar üzerinden // iletilmesi gerekiyorsa: // soket.broadcast.emit("offer", data )); soket.on("cevap", fonksiyon (veri) ( soket.emit("cevap", veri); )); soket.on("buz1", fonksiyon (veri) ( soket.emit("buz1", veri); )); soket.on("buz2", fonksiyon (veri) ( soket.emit("buz2", veri); )); soket.on("kapat", fonksiyon (veri) ( soket.emit("kapat", veri); ));

Ayrıca HTML dosyasının adını da değiştirelim:

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

Sunucuyu başlatma:

$ sudo nodejs nodetest2.js

Her iki istemcinin kodunun aynı tarayıcı sekmesinde yürütülmesine rağmen, örneğimizdeki katılımcılar arasındaki tüm etkileşim tamamen ağ üzerinden gerçekleştirilir ve katılımcıların "ayrılması" herhangi bir özel zorluk gerektirmez. Ancak yaptığımız da çok basitti; bu teknolojiler iyi çünkü kullanımları kolay. Bazen aldatıcı olsa bile. Özellikle şunu unutmayalım ki STUN/TURN sunucuları olmadan örneğimiz adres çevirisi ve güvenlik duvarları varlığında çalışamaz.

Çözüm

Ortaya çıkan örnek çok gelenekseldir, ancak arayan ve aranan taraf arasında farklılık göstermeyecek şekilde olay işleyicilerini biraz evrenselleştirirsek, pc1 ve pc2 olmak üzere iki nesne yerine bir RTCPeerConnection dizisi yapın ve uygulayın. dinamik yaratım ve öğeleri kaldırarak tamamen kullanışlı bir görüntülü sohbet elde edeceksiniz. WebRTC ile ilgili özel bir özellik yoktur ve birkaç katılımcı için basit bir görüntülü sohbet örneği (aynı zamanda makaledeki tüm örneklerin metinleri) dergiyle birlikte gelen diskte bulunmaktadır. Ancak internette zaten pek çok şey bulabilirsiniz. iyi örnekler. Makalenin hazırlanmasında özellikle aşağıdakiler kullanıldı: simpl.info getUserMedia, simpl.info RTCPeerConnection, WebRTC Referans Uygulaması.

WebRTC sayesinde çok yakında sadece sesli ve görüntülü iletişim anlayışımızda değil, İnternet'i bir bütün olarak algılama şeklimizde de bir devrim yaşanacağı varsayılabilir. WebRTC, yalnızca tarayıcıdan tarayıcıya çağrı teknolojisi olarak değil, aynı zamanda gerçek zamanlı iletişim teknolojisi olarak da konumlandırılmıştır. Bahsettiğimiz görüntülü iletişim sadece küçük bir kısımdır olası seçenekler kullanımı. Halihazırda ekran yayıncılığı ve işbirliği örnekleri, hatta RTCDataChannel'ı kullanan tarayıcı tabanlı P2P içerik dağıtım ağı bile mevcut.