WebRTC'yi kullanmaya başlama

Sam Dutton

WebRTC, açık ve özgür bir web için verilen uzun savaşta yeni bir cephedir.

JavaScript'in mucidi Brendan Eich

Eklenti olmadan gerçek zamanlı iletişim

Telefonunuzun, TV'nizin ve bilgisayarınızın ortak bir platformda iletişim kurabileceği bir dünya hayal edin. Web uygulamanıza görüntülü sohbet ve eşler arası veri paylaşımı eklemenin kolay olduğunu hayal edin. WebRTC'nin vizyonu budur.

Denemek ister misiniz? WebRTC, Google Chrome, Safari, Firefox ve Opera'da masaüstü ve mobil cihazlarda kullanılabilir. Başlangıç için appr.tc adresindeki basit görüntülü sohbet uygulamasını kullanabilirsiniz:

  1. Tarayıcınızda appr.tc adresini açın.
  2. Bir sohbet odasına katılmak ve uygulamanın web kameranızı kullanmasına izin vermek için Katıl'ı tıklayın.
  3. Sayfanın sonunda gösterilen URL'yi yeni bir sekmede veya daha iyisi farklı bir bilgisayarda açın.

Hızlı başlangıç

Bu makaleyi okumaya vaktiniz yok mu veya yalnızca kodu mu istiyorsunuz?

  • WebRTC'ye genel bakış için aşağıdaki Google I/O videosunu izleyin veya bu slaytları inceleyin:
  • getUserMedia API'sini kullanmadıysanız HTML5'te ses ve video yakalama ve simpl.info getUserMedia başlıklı makalelere bakın.
  • RTCPeerConnection API hakkında bilgi edinmek için aşağıdaki örneği ve 'simpl.info RTCPeerConnection' sayfasını inceleyin.
  • WebRTC'nin sinyal, güvenlik duvarı ve NAT geçişi için sunucuları nasıl kullandığını öğrenmek istiyorsanız appr.tc adresindeki kod ve konsol günlüklerine bakın.
  • Beklemeden hemen WebRTC'yi denemek mi istiyorsunuz? WebRTC JavaScript API'lerini kullanan 20'den fazla demodan bazılarını deneyin.
  • Cihazınız ve WebRTC ile ilgili sorun mu yaşıyorsunuz? WebRTC Sorun Giderici'yi ziyaret edin.

Alternatif olarak, basit bir sinyal sunucusuyla birlikte eksiksiz bir görüntülü sohbet uygulamasının nasıl oluşturulacağını açıklayan adım adım açıklamalı bir kılavuz olan WebRTC codelab'e doğrudan gidebilirsiniz.

WebRTC'nin çok kısa bir geçmişi

Web'in son zamanlarda karşılaştığı en büyük zorluklardan biri, ses ve video aracılığıyla insan iletişimini sağlamaktır. Buna gerçek zamanlı iletişim veya kısaca RTC denir. RTC, bir web uygulamasında metin girişine metin girmek kadar doğal olmalıdır. Bu bilgiler olmadan yenilik yapma ve kullanıcıların etkileşim kurabileceği yeni yollar geliştirme konusunda sınırlı kalırsınız.

Geçmişte RTC, kurumsal ve karmaşık bir yapıya sahipti. Pahalı ses ve görüntü teknolojilerinin lisanslanması veya şirket içinde geliştirilmesi gerekiyordu. RTC teknolojisini mevcut içerik, veri ve hizmetlerle entegre etmek, özellikle web'de zor ve zaman alıcı bir işlemdi.

Gmail görüntülü sohbeti 2008'de popüler oldu ve 2011'de Google, Gmail'de olduğu gibi Talk'ı kullanan Hangouts'u kullanıma sundu. Google, codec'ler ve yankı iptali teknikleri gibi RTC için gerekli birçok bileşeni geliştiren GIPS'i satın aldı. Google, GIPS tarafından geliştirilen teknolojileri açık kaynak haline getirdi ve sektörde fikir birliği sağlamak için Internet Mühendisliği Görev Gücü (IETF) ve World Wide Web Konsorsiyumu'ndaki (W3C) ilgili standart kuruluşlarıyla birlikte çalıştı. Ericsson, Mayıs 2011'de WebRTC'nin ilk uygulamasını oluşturdu.

WebRTC, gerçek zamanlı, eklentisiz video, ses ve veri iletişimi için açık standartlar uyguladı. Gerçek bir ihtiyaç vardı:

  • Birçok web hizmeti RTC'yi kullanıyordu ancak indirme, yerel uygulamalar veya eklentiler gerekiyordu. Skype, Facebook ve Hangouts bu uygulamalar arasında yer alıyordu.
  • Eklentileri indirmek, yüklemek ve güncellemek karmaşık, hataya açık ve can sıkıcı bir işlemdir.
  • Eklentilerin dağıtılması, hata ayıklanmaları, sorunlarının giderilmesi, test edilmesi ve bakımı zordur. Ayrıca, karmaşık ve pahalı teknolojilerle lisanslama ve entegrasyon gerektirebilir. Kullanıcıları eklenti yüklemeye ikna etmek genellikle zordur.

WebRTC projesinin temel ilkeleri, API'lerinin açık kaynaklı, ücretsiz, standartlaştırılmış, web tarayıcılarına yerleştirilmiş ve mevcut teknolojilerden daha verimli olmasıdır.

Şu anda neredeyiz?

WebRTC, Google Meet gibi çeşitli uygulamalarda kullanılır. WebRTC, WebKitGTK+ ve Qt yerel uygulamalarıyla da entegre edilmiştir.

WebRTC şu üç API'yi uygular: - MediaStream (getUserMedia olarak da bilinir) - RTCPeerConnection - RTCDataChannel

API'ler şu iki spesifikasyonda tanımlanır:

Bu üç API'nin tümü mobil cihazlarda ve masaüstünde Chrome, Safari, Firefox, Edge ve Opera tarafından desteklenir.

getUserMedia: Demolar ve kod için WebRTC örnekleri bölümüne bakın veya Chris Wilson'un web sesi için giriş olarak getUserMedia kullanan müthiş örneklerini deneyin.

RTCPeerConnection: Basit bir demo ve tam işlevli bir görüntülü sohbet uygulaması için sırasıyla WebRTC örnekleri Eş bağlantısı ve appr.tc'ye bakın. Bu uygulama, tarayıcı farklılıklarını ve özellik değişikliklerini soyutlamak için Google tarafından WebRTC topluluğunun yardımıyla yönetilen bir JavaScript uyumlulaştırıcısı olan adapter.js'yi kullanır.

RTCDataChannel: Bu özelliğin nasıl çalıştığını görmek için WebRTC örnekleri sayfasına gidip veri kanalı demolarından birine göz atın.

WebRTC codelab'inde, video sohbet ve dosya paylaşımı için basit bir uygulama oluşturmak üzere üç API'nin nasıl kullanılacağı gösterilmektedir.

İlk WebRTC'niz

WebRTC uygulamalarının yapması gereken birkaç şey vardır:

  • Akışta ses, video veya başka veriler alın.
  • NAT ve güvenlik duvarları üzerinden bile bağlantı sağlamak için IP adresleri ve bağlantı noktaları gibi ağ bilgilerini alıp diğer WebRTC istemcileriyle (eşler olarak bilinir) paylaşın.
  • Hataları bildirmek ve oturumları başlatmak ya da kapatmak için sinyal iletişimini koordine edin.
  • Medya ve istemci özelliği hakkında çözünürlük ve codec'ler gibi bilgileri paylaşın.
  • Akış halindeki ses, video veya verileri iletme

WebRTC, akış verilerini almak ve iletmek için aşağıdaki API'leri uygular:

  • MediaStream, kullanıcının kamerası ve mikrofonu gibi veri akışlarına erişir.
  • RTCPeerConnection, şifreleme ve bant genişliği yönetimi olanaklarıyla sesli veya görüntülü görüşmeyi etkinleştirir.
  • RTCDataChannel, genel verilerin eşler arası iletişimini sağlar.

(WebRTC'nin ağ ve sinyalleme özellikleri daha sonra ayrıntılı olarak ele alınacaktır.)

MediaStream API (getUserMedia API olarak da bilinir)

MediaStream API, senkronize medya akışlarını temsil eder. Örneğin, kamera ve mikrofon girişinden alınan bir yayında senkronize video ve ses parçaları bulunur. (MediaStreamTrack öğesini, tamamen farklı bir öğe olan <track> öğesiyle karıştırmayın.)

MediaStream API'yi anlamanın en kolay yolu, gerçek hayatta nasıl kullanıldığını incelemek olacaktır:

  1. Tarayıcınızda WebRTC örnekleri getUserMedia bölümüne gidin.
  2. Konsolu açın.
  3. Genel kapsamda olan stream değişkenini inceleyin.

Her MediaStream öğesinin bir girişi (getUserMedia() tarafından oluşturulan bir MediaStream olabilir) ve bir çıkışı (bir video öğesine veya RTCPeerConnection öğesine iletilebilir) vardır.

getUserMedia() yöntemi, bir MediaStreamConstraints nesne parametresi alır ve MediaStream nesnesine çözümlenen bir Promise döndürür.

Her MediaStream öğesinin bir label öğesi (ör. 'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ') vardır. getAudioTracks() ve getVideoTracks() yöntemleri bir MediaStreamTrack dizisi döndürür.

getUserMedia örneğinde stream.getAudioTracks(), ses olmadığı için boş bir dizi döndürür ve çalışan bir web kamerasının bağlı olduğu varsayıldığında stream.getVideoTracks(), web kamerasından gelen yayını temsil eden bir MediaStreamTrack dizisi döndürür. Her MediaStreamTrack'nin bir türü ('video' veya 'audio') ve label'ı ('FaceTime HD Camera (Built-in)' gibi) vardır. MediaStreamTrack, bir veya daha fazla ses ya da video kanalını temsil eder. Bu örnekte yalnızca bir video kanalı ve ses yoktur ancak ön kamera, arka kamera ve mikrofondan yayın alan bir sohbet uygulaması veya ekranını paylaşan bir uygulama gibi daha fazla kanalın olduğu kullanım alanlarını hayal etmek kolaydır.

srcObject özelliği ayarlanarak bir MediaStream, video öğesine eklenebilir. Daha önce bu işlem, src özelliği URL.createObjectURL() ile oluşturulan bir nesne URL'sine ayarlanarak yapılıyordu ancak bu yöntemin desteği sonlandırıldı.

getUserMedia, Web Audio API için giriş düğümü olarak da kullanılabilir:

// Cope with browser differences.
let audioContext;
if (typeof AudioContext === 'function') {
  audioContext = new AudioContext();
} else if (typeof webkitAudioContext === 'function') {
  audioContext = new webkitAudioContext(); // eslint-disable-line new-cap
} else {
  console.log('Sorry! Web Audio not supported.');
}

// Create a filter node.
var filterNode = audioContext.createBiquadFilter();
// See https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#BiquadFilterNode-section
filterNode.type = 'highpass';
// Cutoff frequency. For highpass, audio is attenuated below this frequency.
filterNode.frequency.value = 10000;

// Create a gain node to change audio volume.
var gainNode = audioContext.createGain();
// Default is 1 (no change). Less than 1 means audio is attenuated
// and vice versa.
gainNode.gain.value = 0.5;

navigator.mediaDevices.getUserMedia({audio: true}, (stream) => {
  // Create an AudioNode from the stream.
  const mediaStreamSource =
    audioContext.createMediaStreamSource(stream);
  mediaStreamSource.connect(filterNode);
  filterNode.connect(gainNode);
  // Connect the gain node to the destination. For example, play the sound.
  gainNode.connect(audioContext.destination);
});

Chromium tabanlı uygulamalar ve uzantılar da getUserMedia içerebilir. Manifest dosyasına audioCapture ve/veya videoCapture izinleri eklemek, iznin yalnızca yükleme sırasında istenmesini ve verilmesini sağlar. Bundan sonra kullanıcıdan kamera veya mikrofon erişimi için izin istenmez.

getUserMedia() için izin yalnızca bir kez verilmelidir. İlk kez izin verirken tarayıcı infobar İzin ver düğmesi gösterilir. getUserMedia() için HTTP erişimi, güçlü özellik olarak sınıflandırıldığı için 2015'in sonunda Chrome tarafından kullanımdan kaldırıldı.

Amaç, yalnızca kamera veya mikrofon değil, herhangi bir akış veri kaynağı için MediaStream etkinleştirmek olabilir. Bu sayede, depolanan verilerden veya sensörler ya da diğer girişler gibi rastgele veri kaynaklarından akış yapılabilir.

getUserMedia(), diğer JavaScript API'leri ve kitaplıklarıyla birlikte kullanıldığında gerçek gücünü gösterir:

  • Webcam Toy, yerel olarak paylaşılabilen veya kaydedilebilen fotoğraflara tuhaf ve harika efektler eklemek için WebGL kullanan bir fotoğraf kabini uygulamasıdır.
  • FaceKat, headtrackr.js ile geliştirilmiş bir yüz izleme oyunudur.
  • ASCII Kamera, ASCII resimleri oluşturmak için Canvas API'yi kullanır.
idevelop.ro/ascii-camera tarafından oluşturulan ASCII resmi
gUM ASCII resmi

Sınırlamalar

getUserMedia() için video çözünürlüğünün değerlerini ayarlamak üzere kısıtlamalar kullanılabilir. Bu, en boy oranı, yönü (ön veya arka kamera), kare hızı, yükseklik ve genişlik gibi diğer kısıtlamaların desteklenmesine de olanak tanır. Ayrıca applyConstraints() yöntemi de desteklenir.

Örnek için WebRTC örnekleri getUserMedia: çözünürlüğü seçme bölümüne bakın.

İzin verilmeyen bir kısıtlama değeri ayarlanırsa (ör. istenen çözünürlük kullanılamıyorsa) DOMException veya OverconstrainedError değeri döndürülür. Bu özelliğin işleyiş şeklini görmek için demo için WebRTC örnekleri getUserMedia: çözünürlüğü seçin başlıklı makaleyi inceleyin.

Ekran ve sekme yakalama

Chrome uygulamaları, chrome.tabCapture ve chrome.desktopCapture API'leri aracılığıyla tek bir tarayıcı sekmesinin veya masaüstünün tamamını canlı olarak paylaşmayı da mümkün kılar. (Demo ve daha fazla bilgi için WebRTC ile ekran paylaşımı başlıklı makaleyi inceleyin. Bu makale birkaç yıl öncesine ait olsa da hâlâ ilgi çekici.)

Deneysel chromeMediaSource kısıtlamasını kullanarak Chrome'da ekran yakalamayı MediaStream kaynağı olarak kullanmak da mümkündür. Ekran yakalamanın HTTPS gerektirdiğini ve bu yayında açıklandığı gibi bir komut satırı işaretiyle etkinleştirildiği için yalnızca geliştirme için kullanılabileceğini unutmayın.

İşaretleme: Oturum kontrolü, ağ ve medya bilgileri

WebRTC, akış verilerini tarayıcılar (eşler olarak da bilinir) arasında iletmek için RTCPeerConnection'ü kullanır ancak iletişimi koordine etmek ve kontrol mesajları göndermek için de bir mekanizmaya (sinyal olarak bilinen bir işlem) ihtiyaç duyar. İşaretleme yöntemleri ve protokolleri WebRTC tarafından belirtilmez. İşaretleme, RTCPeerConnection API'sinin bir parçası değildir.

Bunun yerine, WebRTC uygulama geliştiricileri SIP veya XMPP gibi tercih ettikleri mesajlaşma protokolünü ve uygun çift yönlü (iki yönlü) iletişim kanalını seçebilir. appr.tc örneğinde, sinyal mekanizması olarak XHR ve Channel API kullanılır. Codelab, düğüm sunucusunda çalışan Socket.io'yu kullanır.

İşaretleme, üç tür bilgi alışverişinde bulunmak için kullanılır:

  • Oturum denetimi mesajları: İletişimi başlatmak veya kapatmak ve hataları bildirmek için kullanılır.
  • Ağ yapılandırması: Dış dünyaya göre bilgisayarınızın IP adresi ve bağlantı noktası nedir?
  • Medya özellikleri: Tarayıcınız ve iletişim kurmak istediği tarayıcı hangi codec'leri ve çözünürlükleri işleyebilir?

Eşler arası aktarımın başlatılabilmesi için sinyal verme yoluyla bilgi alışverişi başarıyla tamamlanmış olmalıdır.

Örneğin, Aylin'in Bora ile iletişime geçmek istediğini varsayalım. W3C WebRTC spesifikasyonundan, sinyal verme sürecinin işleyişini gösteren bir kod örneği aşağıda verilmiştir. Kod, createSignalingChannel() yönteminde oluşturulmuş bir sinyal mekanizmasının varlığını varsayar. Ayrıca Chrome ve Opera'da RTCPeerConnection ön ek olarak kullanıldığını unutmayın.

// handles JSON.stringify/parse
const signaling = new SignalingChannel();
const constraints = {audio: true, video: true};
const configuration = {iceServers: [{urls: 'stun:stun.example.org'}]};
const pc = new RTCPeerConnection(configuration);

// Send any ice candidates to the other peer.
pc.onicecandidate = ({candidate}) => signaling.send({candidate});

// Let the "negotiationneeded" event trigger offer generation.
pc.onnegotiationneeded = async () => {
  try {
    await pc.setLocalDescription(await pc.createOffer());
    // Send the offer to the other peer.
    signaling.send({desc: pc.localDescription});
  } catch (err) {
    console.error(err);
  }
};

// Once remote track media arrives, show it in remote video element.
pc.ontrack = (event) => {
  // Don't set srcObject again if it is already set.
  if (remoteView.srcObject) return;
  remoteView.srcObject = event.streams[0];
};

// Call start() to initiate.
async function start() {
  try {
    // Get local stream, show it in self-view, and add it to be sent.
    const stream =
      await navigator.mediaDevices.getUserMedia(constraints);
    stream.getTracks().forEach((track) =>
      pc.addTrack(track, stream));
    selfView.srcObject = stream;
  } catch (err) {
    console.error(err);
  }
}

signaling.onmessage = async ({desc, candidate}) => {
  try {
    if (desc) {
      // If you get an offer, you need to reply with an answer.
      if (desc.type === 'offer') {
        await pc.setRemoteDescription(desc);
        const stream =
          await navigator.mediaDevices.getUserMedia(constraints);
        stream.getTracks().forEach((track) =>
          pc.addTrack(track, stream));
        await pc.setLocalDescription(await pc.createAnswer());
        signaling.send({desc: pc.localDescription});
      } else if (desc.type === 'answer') {
        await pc.setRemoteDescription(desc);
      } else {
        console.log('Unsupported SDP type.');
      }
    } else if (candidate) {
      await pc.addIceCandidate(candidate);
    }
  } catch (err) {
    console.error(err);
  }
};

İlk olarak Aylin ve Bora ağ bilgilerini paylaşır. (Aday bulma ifadesi, ICE çerçevesini kullanarak ağ arayüzlerini ve bağlantı noktalarını bulma işlemini ifade eder.)

  1. Alice, ağ adayları kullanılabilir hale geldiğinde çalışan bir onicecandidate işleyicisi içeren bir RTCPeerConnection nesnesi oluşturur.
  2. Alice, serileştirilmiş aday verileri, kullandıkları sinyal kanalıyla (ör. WebSocket veya başka bir mekanizma) Bora'ya gönderir.
  3. Bob, Alice'ten bir aday mesajı aldığında, adayı uzak eş tanımına eklemek için addIceCandidate işlevini çağırır.

WebRTC istemcilerinin (eşler veya bu örnekte Ayla ve Bora olarak da bilinir) çözünürlük ve codec özellikleri gibi yerel ve uzak ses ve video medya bilgilerini de belirlemesi ve paylaşması gerekir. Medya yapılandırma bilgilerini değiştirmek için sinyal verme işlemi, Oturum Açıklama Protokolü (SDP) kullanılarak bir teklif ve yanıt alışverişi yapılarak devam eder:

  1. Ayşe, RTCPeerConnection createOffer() yöntemini çalıştırır. Bu işlemden döndürülen değer, RTCSessionDescription (Aliye'nin yerel oturum açıklaması) olarak iletilir.
  2. Geri çağırma sırasında Alice, setLocalDescription() kullanarak yerel açıklamayı ayarlar ve ardından bu oturum açıklamasını sinyal kanalıyla Bob'a gönderir. RTCPeerConnection, setLocalDescription() çağrılana kadar aday toplamaya başlamaz. Bu, JSEP IETF taslağında kodlanmıştır.
  3. Ali, setRemoteDescription() kullanarak kendisine gönderilen açıklamayı uzak açıklama olarak ayarlar.
  4. Bora, Alice'ten aldığı uzak açıklamayı ileterek RTCPeerConnection createAnswer() yöntemini çalıştırır. Böylece, Alice'in oturumuyla uyumlu bir yerel oturum oluşturulabilir. createAnswer() geri çağırma işlevine bir RTCSessionDescription iletilir. Bob bunu yerel açıklama olarak ayarlar ve Alice'e gönderir.
  5. Ayşe, Ali'nin oturum açıklamasını aldığında bunu setRemoteDescription ile uzak açıklama olarak ayarlar.
  6. Ping!

RTCSessionDescription nesneleri, Oturum Açıklama Protokolü'ne (SDP) uygun olan blob'lardır. Serileştirilmiş bir SDP nesnesi şu şekilde görünür:

v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126

// ...

a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810

Ağ ve medya bilgilerinin edinilmesi ve paylaşılması aynı anda yapılabilir ancak eşler arasında ses ve video aktarımı başlatılmadan önce her iki işlem de tamamlanmış olmalıdır.

Daha önce açıklanan teklif/yanıt mimarisine JavaScript Oturum Kurma Protokolü veya JSEP adı verilir. (İlk WebRTC uygulaması için Ericsson'un demo videosunda sinyal verme ve akış sürecini açıklayan mükemmel bir animasyon bulunmaktadır.)

JSEP mimari şeması
JSEP mimarisi

Sinyal verme işlemi başarıyla tamamlandıktan sonra veriler doğrudan eşler arası olarak arayan ile aranan arasında veya bu işlem başarısız olursa bir aracı aktarıcı sunucusu üzerinden (bu konu hakkında daha fazla bilgiyi aşağıda bulabilirsiniz) aktarılabilir. Akış, RTCPeerConnection'ün işidir.

RTCPeerConnection

RTCPeerConnection, eşler arasında akış verilerinin kararlı ve verimli bir şekilde iletişimini sağlayan WebRTC bileşenidir.

Aşağıda, RTCPeerConnection rolünü gösteren bir WebRTC mimarisi şeması verilmiştir. Yeşil kısımların karmaşık olduğunu fark edeceksiniz.

WebRTC mimari şeması
WebRTC mimarisi (webrtc.org'dan)

JavaScript açısından bu şemadan anlanması gereken en önemli nokta, RTCPeerConnection'ün web geliştiricilerini altında yatan sayısız karmaşıklıktan korumasıdır. WebRTC tarafından kullanılan codec'ler ve protokoller, güvenilir olmayan ağlarda bile anlık iletişimi mümkün kılmak için çok fazla iş yapar:

  • Paket kaybı gizleme
  • Yankı giderme
  • Bant genişliği uyumluluğu
  • Dinamik ses dalgalanması arabelleğe alma
  • Otomatik kazanç kontrolü
  • Gürültü azaltma ve engelleme
  • Resim temizleme

Önceki W3C kodunda, sinyalleme açısından basitleştirilmiş bir WebRTC örneği gösterilmektedir. Aşağıda, çalışan iki WebRTC uygulamasının adım adım açıklamalı kılavuzları verilmiştir. İlki, RTCPeerConnection'ü gösteren basit bir örnektir ve ikincisi, tamamen çalışır durumdaki bir görüntülü sohbet istemcisidir.

Sunucusuz RTCPeerConnection

Aşağıdaki kod, tek bir web sayfasında yerel ve uzak RTCPeerConnection (ve yerel ve uzak video) içeren WebRTC örnekleri Eş bağlantısı'ndan alınmıştır. Bu, çok yararlı bir şey değildir (çağrıyı yapan ve alan aynı sayfadadır) ancak sayfadaki RTCPeerConnection nesneleri, aracı sinyal mekanizmaları kullanmak zorunda kalmadan doğrudan veri ve mesaj alışverişi yapabildiğinden RTCPeerConnection API'nin işleyişini biraz daha netleştirir.

Bu örnekte pc1 yerel eşlemeyi (arayanı) ve pc2 uzak eşlemeyi (arananı) temsil etmektedir.

Arayan

  1. Yeni bir RTCPeerConnection oluşturun ve getUserMedia()'dan yayını ekleyin: ```js // Servers isteğe bağlı bir yapılandırma dosyasıdır. (TURN ve STUN ile ilgili tartışmayı aşağıda bulabilirsiniz.) pc1 = new RTCPeerConnection(sunucu); // ... localStream.getTracks().forEach((track) => { pc1.addTrack(track, localStream); });
  1. Bir fırsat oluşturun ve bunu pc1 için yerel açıklama, pc2 için uzak açıklama olarak ayarlayın. Hem arayan hem de aranan aynı sayfada olduğu için bu işlem, sinyal vermeden doğrudan kodda yapılabilir: js pc1.setLocalDescription(desc).then(() => { onSetLocalSuccess(pc1); }, onSetSessionDescriptionError ); trace('pc2 setRemoteDescription start'); pc2.setRemoteDescription(desc).then(() => { onSetRemoteSuccess(pc2); }, onSetSessionDescriptionError );

Çağrılan

  1. pc2 öğesini oluşturun ve pc1'dan gelen yayın eklendiğinde bunu bir video öğesinde gösterin: js pc2 = new RTCPeerConnection(servers); pc2.ontrack = gotRemoteStream; //... function gotRemoteStream(e){ vid2.srcObject = e.stream; }

RTCPeerConnection API plus sunucuları

Gerçek dünyada, WebRTC'nin basit de olsa sunuculara ihtiyacı vardır. Bu nedenle aşağıdakiler olabilir:

  • Kullanıcılar birbirlerini keşfeder ve adlar gibi gerçek dünyadaki ayrıntıları paylaşır.
  • WebRTC istemci uygulamaları (eşler), ağ bilgilerini paylaşır.
  • Eşler, medyayla ilgili verileri (ör. video biçimi ve çözünürlüğü) paylaşır.
  • WebRTC istemci uygulamaları NAT ağ geçitlerini ve güvenlik duvarlarını geçer.

Diğer bir deyişle, WebRTC'nin dört tür sunucu tarafı işlevine ihtiyacı vardır:

  • Kullanıcı bulma ve iletişim
  • Sinyal
  • NAT/güvenlik duvarı geçişi
  • Eşler arası iletişimin başarısız olması durumunda sunucuları aktarma

NAT geçişi, eşler arası ağ oluşturma ve kullanıcı bulma ve sinyal verme için sunucu uygulaması oluşturma şartları bu makalenin kapsamı dışındadır. STUN protokolünün ve uzantısı TURN'ın, RTCPeerConnection'in NAT geçişi ve diğer ağ belirsizlikleriyle başa çıkmasını sağlamak için ICE çerçevesi tarafından kullanıldığını belirtmek yeterlidir.

ICE, iki görüntülü sohbet istemcisi gibi eşler arasında bağlantı kurmak için kullanılan bir çerçevedir. ICE başlangıçta, UDP üzerinden mümkün olan en düşük gecikmeye sahip doğrudan eşleri bağlamaya çalışır. Bu süreçte STUN sunucularının tek bir görevi vardır: NAT arkasındaki bir eşin herkese açık adresini ve bağlantı noktasını bulmasını sağlamak. (STUN ve TURN hakkında daha fazla bilgi için WebRTC uygulaması için gereken arka uç hizmetlerini oluşturma başlıklı makaleyi inceleyin.)

Bağlantı adayları bulma
Bağlantı adayı bulma

UDP başarısız olursa ICE, TCP'yi dener. Doğrudan bağlantı, özellikle kurumsal NAT geçişi ve güvenlik duvarları nedeniyle başarısız olursa ICE bir aracı (geçiş) TURN sunucusu kullanır. Diğer bir deyişle, ICE ilk olarak eşleri doğrudan bağlamak için UDP ile STUN'u kullanır ve bu başarısız olursa TURN aktarıcı sunucusuna geçer. Aday bulma ifadesi, ağ arayüzlerini ve bağlantı noktalarını bulma işlemini ifade eder.

WebRTC veri yolları
WebRTC veri yolları

WebRTC mühendisi Justin Uberti, 2013 Google I/O WebRTC sunumunda ICE, STUN ve TURN hakkında daha fazla bilgi vermektedir. (Sunum slaytlarında TURN ve STUN sunucu uygulama örnekleri verilmiştir.)

Basit bir görüntülü sohbet istemcisi

STUN sunucusu kullanarak sinyal ve NAT/güvenlik duvarı geçişi ile birlikte WebRTC'yi denemek için appr.tc adresindeki görüntülü sohbet demosunu kullanabilirsiniz. Bu uygulama, uygulamaları spesifikasyon değişikliklerine ve önek farklılıklarına karşı korumak için bir dolgu olan adapter.js'yi kullanır.

Kod, günlük kaydında kasıtlı olarak ayrıntılı bilgi verir. Olayların sırasını anlamak için konsolu kontrol edin. Aşağıda, koda dair ayrıntılı bir açıklama verilmiştir.

Ağ topolojileri

WebRTC, şu anda uygulandığı şekliyle yalnızca bire bir iletişimi destekler ancak daha karmaşık ağ senaryolarında da kullanılabilir. Örneğin, her biri doğrudan veya çok sayıda katılımcıyı işleyebilen ve seçmeli akış yönlendirme, ses ve videonun karıştırılması ya da kaydedilmesi gibi işlemleri yapabilen bir sunucu olan çok noktalı kontrol birimi (MCU) aracılığıyla birbirleriyle iletişim kuran birden fazla eş.

Çoklu Nokta Kontrol Ünitesi topoloji şeması
Çoklu Noktalı Kontrol Ünitesi topoloji örneği

Mevcut birçok WebRTC uygulaması yalnızca web tarayıcıları arasındaki iletişimi gösterir ancak ağ geçidi sunucuları, tarayıcıda çalışan bir WebRTC uygulamasının telefonlar (PSTN olarak da bilinir) gibi cihazlarla ve VOIP sistemleriyle etkileşim kurmasını sağlayabilir. Mayıs 2012'de Doubango Telecom, WebRTC ve WebSocket ile oluşturulan sipml5 SIP istemcisini açık kaynak olarak kullanıma sundu. Bu istemci, iOS ve Android'de çalışan tarayıcılar ile uygulamalar arasında video görüşmeleri yapılmasına olanak tanır. Google I/O'da Tethr ve Tropo, WebRTC aracılığıyla özellikli telefonlar ile bilgisayarlar arasında iletişimi sağlamak için OpenBTS hücresi kullanarak bir evrak çantasında afet iletişimi için bir çerçeve gösterdi. Operatör olmadan telefon iletişimi

Google I/O 2012&#39;de Tethr/Tropo demosu
Tethr/Tropo: Acil durum iletişimi için evrak çantası

RTCDataChannel API<

WebRTC, ses ve videonun yanı sıra diğer veri türleri için gerçek zamanlı iletişimi destekler.

RTCDataChannel API, düşük gecikme ve yüksek veri işleme hızıyla rastgele verilerin eşler arası değişimini sağlar. Tek sayfalık demolar için ve basit bir dosya aktarma uygulamasının nasıl oluşturulacağını öğrenmek için sırasıyla WebRTC örnekleri ve WebRTC codelab'e bakın.

API'nin birçok potansiyel kullanım alanı vardır. Örneğin:

  • Oyun
  • Uzaktan masaüstü uygulamaları
  • Gerçek zamanlı yazılı sohbet
  • Dosya aktarımı
  • Merkezi olmayan ağlar

API, RTCPeerConnection'ten en iyi şekilde yararlanmanıza ve güçlü ve esnek eşler arası iletişimi etkinleştirmenize olanak tanıyan çeşitli özelliklere sahiptir:

  • RTCPeerConnection oturum kurulumundan yararlanma
  • Önceliklendirme ile birden fazla eşzamanlı kanal
  • Güvenilir ve güvenilir olmayan yayın semantikleri
  • Yerleşik güvenlik (DTLS) ve tıkanıklık kontrolü
  • Ses veya video ile ya da sessiz veya videosuz kullanılabilme

Söz dizimi, send() yöntemi ve message etkinliğiyle WebSocket'e kasıtlı olarak benzer:

const localConnection = new RTCPeerConnection(servers);
const remoteConnection = new RTCPeerConnection(servers);
const sendChannel =
  localConnection.createDataChannel('sendDataChannel');

// ...

remoteConnection.ondatachannel = (event) => {
  receiveChannel = event.channel;
  receiveChannel.onmessage = onReceiveMessage;
  receiveChannel.onopen = onReceiveChannelStateChange;
  receiveChannel.onclose = onReceiveChannelStateChange;
};

function onReceiveMessage(event) {
  document.querySelector("textarea#send").value = event.data;
}

document.querySelector("button#send").onclick = () => {
  var data = document.querySelector("textarea#send").value;
  sendChannel.send(data);
};

İletişim doğrudan tarayıcılar arasında gerçekleşir. Bu nedenle, güvenlik duvarları ve NAT'lerle başa çıkmak için delik açma işlemi başarısız olduğunda bir geçiş (TURN) sunucusu gerekse bile RTCDataChannel, WebSocket'ten çok daha hızlı olabilir.

RTCDataChannel; Chrome, Safari, Firefox, Opera ve Samsung Internet'te kullanılabilir. Cube Slam oyunu, oyun durumunu bildirmek için API'yi kullanır. Arkadaşınızı veya ayıyı oynayın. Yenilikçi Sharefest platformu, RTCDataChannel üzerinden dosya paylaşımına olanak tanıdı ve peerCDN, WebRTC'nin eşler arası içerik dağıtımını nasıl sağlayabileceğine dair bir fikir sundu.

RTCDataChannel hakkında daha fazla bilgi için IETF'nin taslak protokol spesifikasyonuna göz atın.

Güvenlik

Gerçek zamanlı iletişim uygulamalarının veya eklentilerinin güvenliği ihlal etmesinin birkaç yolu vardır. Örneğin:

  • Şifrelenmemiş medya veya veriler, tarayıcılar arasında ya da tarayıcı ile sunucu arasında ele geçirilebilir.
  • Uygulamalar, kullanıcının bilgisi olmadan video veya ses kaydedip dağıtabilir.
  • Kötü amaçlı yazılımlar veya virüsler, zararsız görünen bir eklenti ya da uygulamayla birlikte yüklenebilir.

WebRTC'nin bu sorunları önlemek için çeşitli özellikleri vardır:

  • WebRTC uygulamaları, DTLS ve SRTP gibi güvenli protokoller kullanır.
  • Şifreleme, sinyal mekanizmaları dahil tüm WebRTC bileşenleri için zorunludur.
  • WebRTC bir eklenti değildir. Bileşenleri ayrı bir işlemde değil, tarayıcı korumalı alanında çalışır. Bileşenler ayrı olarak yüklenmez ve tarayıcı her güncellendiğinde güncellenir.
  • Kamera ve mikrofon erişimi açıkça verilmelidir. Kamera veya mikrofon çalışırken bu durum kullanıcı arayüzünde açıkça gösterilmelidir.

Akış medyasının güvenliğiyle ilgili ayrıntılı bir tartışma bu makalenin kapsamı dışındadır. Daha fazla bilgi için IETF tarafından önerilen Önerilen WebRTC Güvenlik Mimarisi'ne bakın.

Sonuç

WebRTC'nin API'leri ve standartları; telefon, oyun, video prodüksiyonu, müzik yapımı ve haber toplama gibi içerik oluşturma ve iletişim araçlarını demokratikleştirip merkezi olmayan hale getirebilir.

Teknolojinin değişime yol açma etkisi bundan daha fazla olamaz.

Blog yazarı Phil Edholm'un ifadesiyle, "WebRTC ve HTML5, gerçek zamanlı iletişimde orijinal tarayıcının bilgiler için yaptığı dönüşümü sağlayabilir."

Geliştirici araçları

Daha fazla bilgi

Standartlar ve protokoller

WebRTC destek özeti

MediaStream ve getUserMedia API'leri

  • Chrome masaüstü 18.0.1008 ve sonraki sürümler; Android için Chrome 29 ve sonraki sürümler
  • Opera 18 ve sonraki sürümler; Android için Opera 20 ve sonraki sürümler
  • Opera 12, Opera Mobile 12 (Presto motoruna dayalı)
  • Firefox 17 ve sonraki sürümler
  • Microsoft Edge 16 ve sonraki sürümler
  • iOS'te Safari 11.2 ve sonraki sürümler, macOS'te 11.1 ve sonraki sürümler
  • Android'de UC 11.8 ve sonraki sürümler
  • Samsung Internet 4 ve sonraki sürümler

RTCPeerConnection API

  • Chrome masaüstü 20 ve sonraki sürümler; Android için Chrome 29 ve sonraki sürümler (bayraksız)
  • Opera 18 ve sonraki sürümler (varsayılan olarak açık); Android için Opera 20 ve sonraki sürümler (varsayılan olarak açık)
  • Firefox 22 ve sonraki sürümler (varsayılan olarak açıktır)
  • Microsoft Edge 16 ve sonraki sürümler
  • iOS'te Safari 11.2 ve sonraki sürümler, macOS'te 11.1 ve sonraki sürümler
  • Samsung Internet 4 ve sonraki sürümler

RTCDataChannel API

  • Chrome 25'te deneysel sürüm olarak sunulur ancak Chrome 26 ve sonraki sürümlerde daha kararlıdır (ve Firefox ile birlikte çalışabilir). Android için Chrome 29 ve sonraki sürümlerde kullanılabilir.
  • Opera 18 ve sonraki sürümlerde kararlı sürüm (ve Firefox birlikte çalışabilirliği ile); Android için Opera 20 ve sonraki sürümler
  • Firefox 22 ve sonraki sürümler (varsayılan olarak açıktır)

getUserMedia ve RTCPeerConnection gibi API'ler için platformlar arası destek hakkında daha ayrıntılı bilgi için caniuse.com ve Chrome Platform Durumu'na bakın.

RTCPeerConnection için yerel API'leri webrtc.org'daki belgelerde de bulabilirsiniz.