WebRTC Kavramları ve Altyapısı


Bir önceki yazımda
WebRTC’nin ne olduğundan bahsetmiş, genel olarak tanımını yapmıştım. Bu yazımda ise WebRTC dünyasında girdiğiniz anda bol bol duyacağınız bazı konseptlerden bahsedeceğim. WebRTC ilk anlatıldığında, eşler arasında peer-to-peer medya iletişimi yapıyor, sadece API’sini kullanarak harikalar yaratıyorsunuz gibi bir izlenim bırakıyor ama işin içine girince aslında kullanmanız gereken sunucular, protokoller olduğunu ve bazı durumlarda peer-to-peer durumunun olamadığını öğreniyorsunuz.

Bir WebRTC uygulaması yazarken sinyalleşme, offer/answer mekanizması, SDP, STUN, TURN, ICE gibi belki daha önce duymadığınız ama WebRTC ile uğraşırken öğrenmeniz gereken kavramlarla başlayalım.

Sinyalleşme

Sinyalleşmeyi WebRTC çözümünüzün en temel parçası ve basit bir telefon aramasını düşündüğünüzde kimin kiminle nasıl konuşacağı probleminin çözüldüğü kısmı olarak düşünebilirsiniz. Karşılıklı iki eş arasındaki medya iletimini WebRTC’nin gerçekleştirdiğinden bahsetmiştik ama medya iletiminin başlaması için WebRTC’ye medyayı nasıl ve nereye göndereceğini haber vermeniz gerekir. Bu kısım sinyalleşme olarak adlandırılır ve tamamen kullanılacak olan yöntem ve protokoller size bırakılmıştır.

WebRTC hem var olan tüm teknolojiler ile uyumlu olma adına hem de sinyalleşme işlemlerini de bünyesinde barındırıp karmaşıklığı arttırmamak ve kullanıcıyı belirli bir teknolojiye zorlamamak için herhangi bir protokol tanımlamıyor. Yani sinyalleşme sunucusunu kendinizin geliştirmesi ya da bunun için geliştirilmiş herhangi bir açık kaynaklı projeyi kullanmanız gerekiyor. Sinyalleşme için

  • WebSockets
  • WebRTC DataChannel
  • XMPP
  • SIP over WebSockets gibi yöntemleri kullanabilirsiniz. Kendi çözümünüzün gerekliliklerini göz önünde bulundurup herhangi bir yöntemle devam edebilirsiniz.

Sinyalleşmeyi medya iletimi yapılacak kullanıcılar arasında koordinasyonu sağladığımız, bir aramanın gerçekleşmesi için gerekli bilgilerin karşılıklı olarak alınmasını sağlayan süreç olarak düşünebiliriz. Bu süreçte aramanın gerçekleşeceği iki kullanıcı arasında; hangi IP ve port üzerinden haberleşileceği, hangi ses ve görüntü kodeklerin kullanılacağı gibi verileri içeren SDP (session description protocol) objelerinin alışverişi sağlanır.

WebRTC sinyalleşmesi JSEP (Javascript Session Establishment Protocol)’nin getirdiği offer/answer mekanizmasına dayanır ve sizin sinyalleşme sunucunuzun da bu mantığı baz alarak çalışması gerekir. Offer/Answer mekanizması dediğimiz, iki eş arasında arama ile ilgili herhangi bir işlem (arama başlatılması, beklemeye alma, sessize alma ya da aramanın sonlandırılması gibi işlemlerden bahsediyoruz) gerçekleştirileceğinde WebRTC kütüphanesi tarafından üretilen offer ve bu offer’a karşı üretilen answer SDP paketlerinin alışverişidir.

Örnek olarak, bir arama başlama işleminde gerçekleşecek olan offer/answer sürecini ele alalım :

  1. Aramayı başlatacak olan tarafta WebRTC kütüphanesi arama başlatacak olan offer SDP paketini üretip uygulama katmanına verir. Uygulama katmanı bu SDP’yi sinyalleşme sunucusuna iletmekle yükümlüdür.
  2. Sinyalleşme sunucusu “arayan” tarafından gönderilen SDP paketini ilgili diğer istemciye (“aranan”) iletir.
  3. Offer SDP’sini alan aranan taraf bu SDP’yi WebRTC kütüphanesine verir ve karşılığı olan answer SDP’sini sinyalleşme sunucusuna gönderir.
  4. Sinyalleşme sunucusu answer SDP’yi “arayan” tarafa iletir ve “arayan” tarafta gelen SDP WebRTC kütüphanesine bildirir.
  5. Offer/answer süreci başarıyla tamamlandıktan ve eşler arasındaki uzlaşma (negotiation) sağlandıktan sonra iki eş arasında medya iletimi peer-to-peer olarak başlar.

Görüldüğü gibi medya iletiminden ve medya ile ilgili kısımlardan WebRTC sorumlu, uygulama katmanında yapılması gereken işlem ise yine WebRTC tarafından üretilen SDP paketlerinin karşı tarafa gönderilmesi ve alınmasını sağlamak.

SDP

Sinyalleşmeden bahsederken SDP objelerinin alışverişinden bahsettik, peki ama SDP nedir? SDP (Session Description Protocol) bir oturumu tanımlamak için kullanılan bir formattır. Özellikle multi-medya iletişimi için kullanılır ve medyayı kendi iletmez, sadece JSON, XML gibi bir format olarak düşünebilirsiniz. SIP, RTSP, HTTP gibi farklı iletişim protokolleri ile çalışabilir.

SDP içerisinde temel olarak sırayla genel oturum bilgileri, oturum zamanı ve medya bilgilerini içerir. Haberleşilecek IP, port, medya türü (video, ses ya da ikisi birden olabilir), her medya satırı için gerekli özellikler gibi daha detaylı bilgileri içeren bir SDP’nin aşağıdaki gibi bir görünümü vardır.

SDP formatının daha ayrıntılı bilgisini, hangi etiketin ne anlama geldiği ve sıralamasını burdaki sunumumdan edinebilirsiniz.

STUN

Şimdiye kadarki üzerinde konuştuğumuz senaryo; arayan taraf kendi bilgilerini aranan tarafa iletir, aranan tarafta kendi bilgilerini aranan tarafa iletir ve medya peer-to-peer olarak gönderilir. Ama burda dikkat edilmesi gereken nokta peer-to-peer için eşlerin kendi public IP’lerini biliyor olması ve SDP’nin bu IP yi içeriyor olmasıdır ve gerçek dünyayı göz önünde bulundurup NAT’lar arkasında olduğumuzu düşündüğümüzde eşlerin kendi public IP’lerini bilmeme gibi bir sorunları olduğunu fark ediyoruz. Bu problemin çözümü olarak WebRTC STUN (Session Traversal Utilities for NAT) sunucuları kullanılıyor.

Kendisine istek gönderen tarafın public IP ve port bilgisini göndererek istemci tarafın bu bilgilere sahip olmasını sağlar. İstemci kendi public IP sini öğrenmek için STUN ile iletişime geçer ve aldığı IP bilgisiyle birlikte sinyalleşmeye normal olarak devam eder.Burdaki önemli noktalardan bir tanesi medyanın hala peer-to-peer olmasıdır. Bu nedenle STUN basit ve ucuz bir çözümdür, Google’ın ücretsiz sağlamış olduğu STUN sunucularını ya da açık kaynak olarak yayınlanmış STUN çözümlerini kendi sunucunuzda kurarak kullanabilirsiniz.

Yine WebRTC akışını düşündüğümüzde STUN ile iletişimden WebRTC sorumlu, uygulama tarafı olarak sizin, kullanılacak olan STUN sunucu bilgilerini WebRTC kütüphanesine vermeniz gerekir.

TURN

STUN çözümünden sonra yapacağımız aramaların çok büyük bir kısmının başarılı olmasını sağlayabildik ama hala problem oluşturan durumların mevcut olduğunu fark edeceksiniz. Mesela, firewall ya da traversal NAT arkasındaki istemciler arasındaki aramalar başarısız olacaktır. STUN bu tip durumlarda problemi çözemeyecek ve TURN (Traversal Using Relays around NAT) çözümüne başvurmanız gerekecektir.

TURN kullanımıyla birlikte peer-to-peer iletişimi kırıyor ve medyayı turn sunucuları üzerinden göndermeye başlıyoruz. Medya iletiminin bir sunucu üzerinden olması ve kullanıcıların sunucunun bandwidth ini kullanması nedeniyle STUN a göre daha pahalı bir çözümdür ama TURN sunucusunun bulunduğu bir WebRTC çözümünde tüm durumlarda aramalarınızın başarılı olmasını sağlanır. Google’ın tavsiye ettiği TURN sunucusunu kendi ortamınıza deploy edip, kullanabilirsiniz.

ICE

WebRTC bu karmaşıklığı aşmak ve hangi durumda nasıl davranacağına kullandığı ICE framework ile karar veriyor. ICE birbiriyle konuşacak iki eş arasındaki en iyi yolu bulup WebRTC’nin kullanmasını sağlıyor. ICE çalışma mantığında; eğer çiftler peer-to-peer olarak konuşabiliyorsa ilk tercih her zaman bu seçenek oluyor. Eğer peer-to-peer seçeneği olumsuz ise STUN çözümünü, o da olmazsa TURN çözümünü seçerek aramanın gerçekleşmesini sağlıyor. Bu kontrolleri paralel olarak yapıp, iki eş arasındaki en iyi yolu bulmaya çalışır.

Peki uygulama tarafı olarak bize düşen nedir? Uygulama tarafında kullanılacak ICE sunucularının (STUN ve TURN sunucularının) bilgilerini WebRTC’ye belirterek arama sırasında bu seçimi yapabilmesini sağlamamız gerekiyor.

TURN durumunun olabileceğinden bahsettikten sonra akıllara WebRTC’nin peer-to-peer olması ile ilgili sorular gelebilir. En başta da dediğimiz gibi hala WebRTC’nin en büyük söylemlerinden biri peer-to-peer iletişim. Bunu da büyük bir oranda başardığını Google ve Bistri’nin yayınladığı istatistiklerden görebiliyoruz.

Son

En basit haliyle WebRTC’nin beraberinde getirdiği protokollere ve teknolojilere değinmeye çalıştım. Tabiki, ciddi anlamda kaliteli bir gerçek zamanlı haberleşme uygulaması yazmak istediğinizde her bileşen kritik rol oynuyor ve her biri hakkında çok daha derin bilgi edinmek zorunda kalıyorsunuz 🙂

Leave a reply:

Your email address will not be published.

Site Footer