VPS üzerinde self-hosted video konferans kurulumu

VPS üzerinde self-hosted video konferans bir bant genişliği sorunudur

Self-hosted video konferans çözümleri küçük sunucularda tek bir nedenden dolayı başarısız olur ve bu sorun neredeyse hiçbir zaman kurulumla ilgili değildir. Modern araçların tamamının kullandığı sunucu bileşeni SFU (selective forwarding unit) olarak adlandırılır. Bu birim, her katılımcıdan gelen tek bir video akışını alır ve bunun bir kopyasını diğer tüm katılımcılara iletir; bu nedenle sunucudan çıkan trafik, katılımcı sayısının karesiyle doğru orantılı olarak artar. Paylaşımlı bir uplink üzerindeki 1 GB veya 2 GB RAM'e sahip bir VPS, yazılımı sorunsuz çalıştıracaktır. Ancak bu kapasite, hayal ettiğiniz tüm çalışanların katıldığı toplantıları kaldırmayacaktır.

Bu nedenle işlemleri şu sırayla gerçekleştirin: Katılımcı sayısını hesaplayın, megabit değerlerini belirleyin ve ardından sunucunuzu seçin. Kurulum, kopyala-yapıştır ile yirmi dakika süren bir işlemdir. Ancak uplink kapasitesi, sesinizin karşı tarafa ulaşıp ulaşmayacağını belirleyen temel faktördür.

Bant genişliği neden katılımcı sayısının karesiyle orantılı artar?

Mesh yapısıyla başlayalım. Her tarayıcı kendi kamerasından gelen görüntüyü kodlar ve doğrudan diğer her tarayıcıya birer kopya gönderir; hiçbir medya sunucusu videoya müdahale etmez. İki kişilik bir mesh görüşmesi için bir sinyalleşme sunucusu dışında hiçbir şeye ihtiyaç yoktur; bu yüzden bire bir görüşmeleri barındırmak neredeyse ücretsizdir. Mesh yapısı dört veya beş kişiden sonra çalışmaz hale gelir, çünkü ev internetine bağlı bir dizüstü bilgisayarın aynı anda kendi videosundan dört veya beş ayrı kopya yüklemesi gerekir.

SFU farklı çalışır. Her tarayıcı sunucuya tek bir kopya yükler. Sunucu, RTP (real-time transport protocol) başlıklarını okur ve videoyu kod çözme işlemine tabi tutmadan paketleri diğer katılımcılara iletir. Tüm mesele budur; bu yüzden SFU, CPU üzerinde hafif, ağ üzerinde ise yoğun bir yük oluşturur.

Daha eski bir yöntem ise MCU (multipoint control unit) yapısıdır. Bu yapı, gelen her akışın kodunu çözer, bunları tek bir görüntüde birleştirir ve görüntüyü yeniden kodlar. Giden bant genişliği çok düşüktür. CPU maliyeti ise muazzamdır. Günümüzde video için neredeyse hiçbir şey MCU kullanmamaktadır ve bu kılavuzda da hiçbir şey MCU kullanmaz.

Şimdi SFU için aritmetiğe bakalım. Herkesin 1.2 Mbps hızında video gönderdiğini ve kimsenin kamerasının kapalı olmadığını varsayalım. Sunucu, N çarpı 1.2 Mbps veri alır; bu doğrusal bir artıştır ve sorun yaratmaz. Sunucu, N çarpı (N eksi 1) çarpı 1.2 Mbps veri gönderir, çünkü N kişiden her birinin diğer N eksi 1 akışı alması gerekir. Projeleri bitiren rakam işte bu ikinci değerdir.

[
  {
    "label": "4 people",
    "sfu_egress_mbps": 14.4,
    "egress_gb_per_hour": 6.5,
    "monthly_volume_tb": 0.13
  },
  {
    "label": "8 people",
    "sfu_egress_mbps": 67.2,
    "egress_gb_per_hour": 30.2,
    "monthly_volume_tb": 0.6
  },
  {
    "label": "15 people",
    "sfu_egress_mbps": 252,
    "egress_gb_per_hour": 113.4,
    "monthly_volume_tb": 2.3
  },
  {
    "label": "30 people",
    "sfu_egress_mbps": "1,044",
    "egress_gb_per_hour": 469.8,
    "monthly_volume_tb": 9.4
  },
  {
    "label": "50 people",
    "sfu_egress_mbps": "2,940",
    "egress_gb_per_hour": "1,323",
    "monthly_volume_tb": 26.5
  }
]

Bu satırlar aritmetiktir, belirli bir sunucunun ölçümü değildir. Aylık sütunu, ayda yirmi saatlik görüşme yapıldığını varsayar. Önce son satırı okuyun. Kamerası açık elli kişi, tek bir makineden 2,940 Mbps sürekli giden trafik gerektirir. Otuz kişi 1,044 Mbps gerektirir. Dört kişi ise herhangi bir VPS'in fark etmeden karşılayabileceği 14.4 Mbps gerektirir. Dört kişilik satır ile otuz kişilik satır arasında kişi sayısı yedi buçuk kat artarken, giden trafik yetmiş kattan fazla artar.

Gerçek kurulumlar bu rakamların altında kalır ve bunun tam olarak nasıl olduğunu bilmek önemlidir. Hem Jitsi hem de LiveKit simulcast kullanır: gönderici aynı anda birkaç kalite katmanı yayınlar ve SFU, ekranda olmayan kişilere düşük kaliteli katmanı iletir. Jitsi ayrıca, yalnızca en son konuşanların videosunu ileten bir last-N ayarına sahiptir. Her ikisi de ciddi miktarda trafik tasarrufu sağlar. Ancak ikisi de eğrinin şeklini değiştirmez ve herkes kamerasını açıp birbirini sabitlediği anda sağladıkları fayda sona erer.

Bir VPS uplink size gerçekte ne sağlar?

Bir plan sayfasında "1 Gbps port" ibaresi yer alabilir. Bu, sanal ağ kartının hızıdır; bir sonraki sıçrama noktası (next hop) için bir garanti değildir. Bağlantı, aynı fiziksel sunucudaki diğer kiracılarla paylaşıldığı için yoğun saatlerdeki sürekli veri aktarım hızı, port hızından daha düşüktür; bir konferans görüşmesi ise tam olarak sürekli bir yük oluşturur. Çoğu plan ayrıca aylık bir veri aktarım kotası içerir; bu kota aşıldığında hızınız kısıtlanır veya ek ücret yansıtılır.

Bu kota, faturadaki sürprizlerin kaynağıdır. Otuz kişilik bir görüşmenin ayda yirmi saati, sunucudan saatte 469.8 GB hızla toplam 9.4 TB veri çıkışına neden olur. Elli kişilik bir görüşmenin yirmi saati ise 26.5 TB veri taşır. RAM miktarına bakmadan önce veri aktarım kotasını kontrol edin; eğer plan sayfası bu konuda belirsizse, bu belirsizlik aradığınız cevaptır. Ucuz bir VPS teklifini doğru okumak, bu iş yükü için neredeyse diğer tüm faktörlerden daha önemlidir.

Jitsi Meet: varsayılan çözüm ve gereksinimleri

Jitsi Meet, çoğu kullanıcının başlangıç noktası olarak tercih etmesi gereken çözümdür. Projenin kendi Debian deposundan kurulur, kurulum sırasında nginx ve sertifika yapılandırmasını otomatik gerçekleştirir. Videobridge (JVB) tek bir UDP portu kullandığı için güvenlik duvarı kuralları oldukça basittir. Debian 11 veya üzeri ya da Ubuntu 22.04 veya üzeri bir işletim sistemi gerektirir.

sudo apt update
sudo apt install -y apt-transport-https curl gnupg
sudo add-apt-repository universe
sudo apt update
sudo curl -sL https://prosody.im/files/prosody-debian-packages.key -o /usr/share/keyrings/prosody-debian-packages.key
echo "deb [signed-by=/usr/share/keyrings/prosody-debian-packages.key] http://packages.prosody.im/debian $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/prosody-debian-packages.list
sudo apt install -y lua5.2
curl -sL https://download.jitsi.org/jitsi-key.gpg.key | sudo sh -c 'gpg --dearmor > /usr/share/keyrings/jitsi-keyring.gpg'
echo "deb [signed-by=/usr/share/keyrings/jitsi-keyring.gpg] https://download.jitsi.org stable/" | sudo tee /etc/apt/sources.list.d/jitsi-stable.list
sudo apt update
sudo apt install -y jitsi-meet

Kurulum aracı bir ana makine adı (hostname) ister ve ardından bir sertifika seçeneği sunar. Let's Encrypt seçeneğini tercih edin ve bu sunucunun genel IP adresine yönlendirilmiş bir alan adı girin. Sertifika, HTTP doğrulaması (challenge) üzerinden düzenlendiği için başka bir yere yönlenen alan adları bu adımda başarısız olur.

Ardından portları açın. El kitabında belgelenen portlar aşağıdadır; ufw enable ile bağlantınızın kesilmemesi için önce SSH portunu açtığınızdan emin olun:

sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow 10000/udp
sudo ufw allow 3478/udp
sudo ufw allow 5349/tcp
sudo ufw enable

TCP 80 ve 443 portları web uygulamasını sunar ve sertifika yenileme işlemlerini sağlar. UDP 10000 portu tüm ses ve görüntü trafiğini taşır; genellikle unutulan port budur. UDP 3478 ve TCP 5349 portları, Jitsi paketiyle birlikte kurulan ve ağları UDP trafiğini engelleyen kullanıcılar için yedek yol görevi gören coturn sunucusuna aittir.

sudo systemctl status jitsi-videobridge2
sudo ss -ulnp | grep 10000

İlk komut servisin aktif olduğunu bildirmelidir. İkinci komut ise bridge servisinin UDP 10000 portunda dinleme yaptığını göstermelidir. Eğer çıktı boşsa bridge başlamamıştır; /var/log/jitsi/jvb.log komutu bunun nedenini açıklayacaktır.

Boyutlandırma konusunda Jitsi el kitabı kendi başlangıç değerlerini, BigBlueButton ise çok daha yüksek değerleri önermektedir:

[
  {
    "label": "Jitsi Meet",
    "ram_gb": 8,
    "cpu_cores": 4,
    "uplink_mbps": "1,000"
  },
  {
    "label": "BigBlueButton 3.0",
    "ram_gb": 16,
    "cpu_cores": 8,
    "uplink_mbps": 250
  }
]

Jitsi el kitabı, ciddi bir sunucu için 8 GB RAM ve 4 adet ayrılmış CPU çekirdeği önermekte, 1,000 Mbps ağ hızının genellikle yeterli olduğunu belirtmektedir. Ayrıca daha küçük kurulumların 4 GB veya 2 GB RAM ile çalışabildiğine dikkat çeker. İlgili sayfadaki önemli bir detay şudur: Sinyalizasyonu yöneten XMPP sunucusu Prosody, yalnızca tek bir çekirdek kullanabilir. Ekstra çekirdekler bridge servisine yardımcı olur ancak sinyalizasyon üzerinde bir etkisi yoktur.

Neden herkes görüşmeye katılıyor ancak kimse videoyu göremiyor?

Bu, bir VPS üzerinde karşılaşılan standart Jitsi hata durumudur. Katılımcı listesi dolar, sohbet çalışır ancak tüm video kutucukları siyah kalır. Videobridge, kendi arayüzlerinde bulduğu adresleri duyurur. Sanal makineye özel bir IP adresi atayan ve bu adresi genel bir IP adresine eşleyen sağlayıcılarda, JVB'nin bulduğu tek adres özel adres olur. Bu nedenle her istemci, medyayı 10.0.0.5 gibi bir adrese göndermeye çalışır ve paketler hiçbir yere ulaşmaz.

Köprüye her iki adresi de bildirin. /etc/jitsi/videobridge/jvb.conf dosyasına statik bir eşleme ekleyin:

ice4j {
  harvest {
    mapping {
      static-mappings = [
        {
          local-address = "10.0.0.5"
          public-address = "203.0.113.10"
        }
      ]
    }
  }
}

sudo systemctl restart jitsi-videobridge2 ile yeniden başlatın. Yerel adresi ip -4 addr show üzerinden, genel adresi ise sağlayıcınızın kontrol panelinden alın. Daha eski kılavuzlar, org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS ve org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS anahtarlarıyla /etc/jitsi/videobridge/sip-communicator.properties dosyasında aynı ayarı yapılandırır. Bunlar hala çalışmaktadır ancak yeni kurulumlarda yukarıdaki eşleme bloğu kullanılmalıdır.

Diğer bir neden ise yapılandırmadığınız bir güvenlik duvarıdır. Çoğu sağlayıcı, sunucu üzerindeki ufw'den bağımsız olarak kontrol panelinde bir ağ güvenlik duvarı çalıştırır ve UDP 10000 portunun her ikisinde de açık olması gerekir. Paketleri hangi katmanın düşürdüğünü bulmak için, dışarıdan biri görüşmeye katılırken sunucuda sudo tcpdump -ni any udp port 10000 komutunu çalıştırın. Hiç paket gelmiyorsa, makineye hiçbir şey ulaşmıyor demektir; bu durumda engel işletim sisteminin dışındadır. Paketler ulaşıyor ancak kutucuklar siyah kalıyorsa, köprü istemcinin erişemeyeceği bir adresle yanıt veriyor demektir; bu durumda sorun eşlemedir. Eğer ufw'nin kendisiyle ilgili emin olamadığınız bir durum varsa, bir VPS'in gerçekten ihtiyaç duyduğu ufw kuralları bölümü, kullanıcıları hataya düşüren kural sıralamasını açıklamaktadır.

BigBlueButton: ağır, katı kurallı ve tüm sunucuyu talep eden bir yapı

BigBlueButton eğitim odaklı tasarlanmıştır. Beyaz tahta, grup odaları, anketler ve sunum alanı gibi özelliklere sahiptir; kayıt hattı ise bir eklenti değil, sistemin temel bir parçasıdır. Bu listedeki açık ara en ağır seçenektir ve mevcut bir sunucuya kurulacak bir paket değildir.

Ağustos 2026 itibarıyla desteklenen sürüm, jammy-300 sürüm bayrağı ile seçilen Ubuntu 22.04 üzerindeki BigBlueButton 3.0'dır. Projenin belirtilen üretim gereksinimleri; swap alanı etkinleştirilmiş 16 GB bellek, yüksek tek çekirdek performansına sahip 8 CPU çekirdeği, 250 Mbps simetrik bant genişliği ve kayıtları tutacaksanız 500 GB (devre dışı bırakırsanız 50 GB) disk alanıdır. Kullanılan portlar TCP 80 ve 443 ile 16384-32768 arası UDP aralığıdır.

wget -q https://raw.githubusercontent.com/bigbluebutton/bbb-install/v3.0.x-release/bbb-install.sh
less bbb-install.sh
bash bbb-install.sh -w -v jammy-300 -s bbb.example.com -e info@example.com -g

Projenin kendi örnekleri, betiği doğrudan bash içerisine yönlendirir. Ancak önce betiği indirip okuyun; çünkü bu betik nginx yapılandırmanızı yeniden yazar, kendi medya ve ses yığınını kurar, paket sürümlerini sabitler ve sunucu adını (hostname) sahiplenir. Bu bir hata değil, tasarımın bir parçasıdır: BigBlueButton makinenin kontrolünün kendisinde olmasını bekler. -w bayrağı güvenlik duvarını yapılandırır, -s sunucu adını belirler, -e Let's Encrypt'in kaydedeceği adresi tanımlar ve -g Greenlight arayüzünü ekler. Eğer aynı sunucu diğer servisler için de TLS termination yapıyorsa, BigBlueButton'ı başka bir yere taşıyın veya betik düzenleme yapmadan önce nginx reverse proxy yapılandırmanızın ne yaptığını tam olarak anladığınızdan emin olun.

Tablodaki iki satırı dikkatle karşılaştırın. BigBlueButton, Jitsi'nin önerdiğinin iki katı bellek ve çekirdek talep ederken, bant genişliği ihtiyacı dörtte biridir. Bu iki rakam aynı yöntemle ölçülmemiştir ve farklı oda boyutlarını varsayarlar; bu nedenle her birini doğrudan kıyaslamak yerine, ilgili projenin kendi başlangıç noktası olarak değerlendirin. CPU farkı gerçektir ve BigBlueButton'ın video iletimi dışında yaptığı tüm işlemlerden kaynaklanır.

Galène: küçük seçenek

Galène, Go ile yazılmış kompakt bir SFU'dur. Tek bir statik binary olarak derlenir, kendi web istemcisini barındırır ve bir TURN sunucusu içerir; bu sayede ayakta tutulması gereken bir XMPP sunucusu, Java runtime veya Rails uygulaması yoktur. Eğer gereksiniminiz mütevazı bir sunucuda on kişilik güvenilir bir görüşme ise, daha fazla donanıma ihtiyacınız olduğuna karar vermeden önce bunu deneyin.

sudo apt update && sudo apt install -y git golang-go
git clone https://github.com/jech/galene
cd galene
CGO_ENABLED=0 go build -ldflags='-s -w'
mkdir groups

Ubuntu 24.04 üzerindeki golang-go paketi Go 1.22 sürümüdür. Eğer go build modülün daha yeni bir Go sürümü gerektirdiğine dair hata verirse, dağıtım paketiyle uğraşmak yerine go.dev adresinden güncel bir araç zinciri kurun.

Grup, Galène'in oda için kullandığı terimdir ve bir grup bir JSON dosyasıdır:

echo '{"users": {"vimes": {"password":"sybil", "permissions":"op"}}}' > groups/night-watch.json
./galene &

https://your.server:8443/group/night-watch/ dosyasını açın ve vimes olarak giriş yapın. Bu kimlik bilgileri doğrudan projenin README dosyasından gelir, bu nedenle port başka bir yerden erişilebilir hale gelmeden önce bunları değiştirin. Gerçek bir dağıtım için proje bir systemd birimi belgelemiştir:

[Unit]
Description=Galene
After=network.target

[Service]
Type=simple
WorkingDirectory=/home/galene
User=galene
Group=galene
ExecStart=/home/galene/galene
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target

Portlar, web arayüzü için TCP 8443, yerleşik TURN sunucusu için TCP ve UDP 1194 ve medya için yüksek UDP port aralığıdır. Bu aralığı sabitleyin, böylece onun için tek bir güvenlik duvarı kuralı yazabilirsiniz:

./galene -udp-range 40000-40100

-turn seçeneği, bir VPS üzerinde önemli olan seçenektir. -turn ':1194' tüm genel IPv4 adreslerini dinler. -turn '203.0.113.1:1194', Galène'e istemcilerin gerçekte göreceği adresi bildirir; makinenin kendi adresi özel (private) olduğunda ihtiyaç duyduğunuz şey budur. -turn '', yerleşik sunucuyu devre dışı bırakır, böylece data/ice-servers.json aracılığıyla harici bir sunucuya yönlendirme yapabilirsiniz. Varsayılan değer auto'dir ve ice-servers.json mevcut olmadığında :1194 gibi davranır.

data/config.json içerisinde proxyURL ayarını yaparak ve /ws konumunu WebSocket yükseltme başlıklarıyla proxy ederek nginx'i web arayüzünün önüne koyabilirsiniz. Bunun neleri kapsadığını bilin: istemciler hala doğrudan UDP akışları ve TURN portuna doğrudan TCP bağlantıları açar, bu nedenle reverse proxy yalnızca sayfayı ve sinyalleşmeyi yönetir. Medya asla içinden geçmez.

Galène'in dokümantasyonu çok mütevazı sunucu kaynaklarına ihtiyaç duyduğunu belirtir ve belirli bir rakam yayınlamaz, bu yüzden bir rakam beklemeyin. Yukarıdaki bant genişliği hesaplaması hala tamamen geçerlidir. Tasarruf ettiğiniz şey, SFU olmayan her şeyin bellek kullanımı ve hareketli parçalarıdır.

Owncast: Bire çok yayın, bant genişliği doğrusal kalır

Birçok "video konferans" gereksinimi aslında bir kişinin, sohbete yazarak katılan bir kitleye sunum yapmasından ibarettir. İhtiyacınız buysa, SFU yanlış bir araçtır ve ekonomik dengeler tamamen değişir. Owncast, OBS veya benzeri bir kodlayıcıdan gelen RTMP akışını alır ve sıradan HTTPS üzerinden HLS olarak sunar. İzleyici başına düşen bant genişliği karesel değil doğrusaldır; çıktı düz HTTP segmentlerinden oluştuğu için bu içeriği bir nesne depolama (object storage) veya CDN arkasına taşıyabilir ve kaynak sunucuda maliyet oluşturmasını durdurabilirsiniz.

curl -sL https://owncast.online/install.sh -o install-owncast.sh
less install-owncast.sh
bash install-owncast.sh

Projenin belgeleri, bu yazılımın root kullanıcısı ile çalıştırılmamasını ve herhangi bir uzak betiği çalıştırmadan önce incelenmesini tavsiye eder; bu nedenle indirme işlemi yukarıda ayrı bir adım olarak belirtilmiştir. Yükleyici, güncel sürümü ve eğer sisteminizde yoksa bir ffmpeg ikili dosyasını çeker. Yükleme dizininden ./owncast komutunu çalıştırın ve 8080 numaralı port üzerinden /admin adresindeki yönetim panelini açın. Varsayılan giriş bilgileri admin kullanıcısı ve parola olarak varsayılan yayın anahtarı abc123 şeklindedir. Sunucuyu bir alan adına yönlendirmeden önce bu bilgileri değiştirin.

HLS tasarımından kaynaklanan iki sonuç vardır. HLS tüm segmentleri gönderdiği için izleyiciler canlı yayının birkaç saniye veya dakika gerisinden gelir; bu nedenle karşılıklı bir konuşma mümkün değildir. Ayrıca yol üzerinde UDP veya TURN bulunmaz; bu sayede WebRTC çağrısının hiç bağlanamadığı ağlara bile ulaşabilir.

Owncast, burada yer alan ve özellikle transkod işlemi yapan tek araçtır. Etkinleştirdiğiniz her çıktı kalitesi, gelen akışın ffmpeg ile yeniden kodlanması anlamına gelir ve yayın boyunca çalışır. Küçük bir VPS üzerinde bir veya iki kalite seçeneği sunun. Beş seçenek, ağ boşta beklerken CPU'yu tamamen doyuracaktır.

Hâlihazırda çalıştırdığınız bir Matrix sunucusunda Element Call kullanımı

Hâlihazırda Matrix çalıştırıyorsanız, video özelliği ikinci bir ürün olarak değil, mevcut yapınıza bir ek olarak gelir. Yine de birden fazla paketten oluşur. Element Call, homeserver'ınızın arkasında iki bileşene ihtiyaç duyar. Birincisi, medya yönlendirmesini yapan LiveKit SFU'dur. İkincisi ise, istemciye LiveKit WebSocket URL'sini ve bağlanması için imzalı bir JWT (JSON web token) sağlayan MatrixRTC yetkilendirme servisi olan element-hq/lk-jwt-service'dir. Bu servis, Matrix federation API'sini kullandığı için önünde bir TLS reverse proxy'ye ve federation'ın erişebileceği bir alan adına ihtiyaç duyar.

LiveKit için belgelenen portlar şunlardır:

• TLS termination yapan bir proxy arkasında, API ve istemci WebSocket için TCP 7880
• İstemcinin UDP üzerinden çıkış yapamadığı durumlarda kullanılan ICE over TCP için TCP 7881
• Her katılımcının iki port kullandığı medya trafiği için UDP 50000 ile 60000 arası
• Dahili TURN sunucusunu etkinleştirirseniz UDP 3478 ve TCP 5349; önünde bir load balancer yoksa 5349 portunun 443'e taşınması gerekir

Katılımcı başına iki port kulağa endişe verici gelse de aslında değildir. 10.000 portluk bir aralık binlerce katılımcıyı kapsar ve uplink kapasiteniz bu aralık dolmadan çok önce tükenir. Yine de tüm aralığı açın; çünkü kısmen açık bir aralık bazı kullanıcılar için çalışıp bazıları için hata verecektir ve bu, hata ayıklaması en zor olan sorun türüdür. Bu işin homeserver tarafı başlı başına bir konudur ve bir VPS üzerinde Synapse homeserver çalıştırma rehberinde ele alınmıştır.

Neden bir kişi asla bağlanamıyor? TURN ve UDP engelleyen ağlar

Önce birer kez kullanılan bazı terimler. ICE (interactive connectivity establishment), iki WebRTC uç noktasının aralarında çalışan bir yol bulmak için kullandığı süreçtir. STUN (session traversal utilities for NAT), bir istemciye dışarıdan bakıldığında kendi genel adresinin ne göründüğünü söyleyen küçük bir servistir. TURN (traversal using relays around NAT) bir aktarıcıdır: doğrudan bir yol bulunamadığında, her iki taraf da medyalarını TURN sunucusuna gönderir ve sunucu bunu iletir.

Ağlarını göremediğiniz katılımcılar için TURN kullanmanız gerekir. Bu kişilerden biri, giden UDP trafiğinin tamamen engellendiği bir kurumsal ağda veya kampüs ağında olabilir. Bir diğeri ise her hedef için farklı bir kaynak portu atayan, simetrik NAT olarak adlandırılan ve STUN tarafından bildirilen adresi işlevsiz kılan bir carrier-grade NAT arkasında olabilir.

Belirti spesifiktir. Çoğu kişi katılır ve her şey çalışır. Bir kişi katılımcı listesini ve sohbeti görür, ancak siyah bir kutu ve dönen bir simge ile karşılaşır. Tarayıcısı adayları topladı, ancak hiçbir çift çalışmadı ve ICE başarısız bir durumda sonlandı. Chrome'da deneme sırasında açık olan chrome://webrtc-internals, aday çiftlerini ve bu başarısızlığı gösterir. O kişiden mobil veri üzerinden bir telefonla tekrar denemesini isteyin. Eğer orada çalışıyorsa, sorun ağ kaynaklıdır ve çözümü TURN'dür.

443 veya 5349 portları üzerinden TCP tabanlı TURN, hemen hemen her yerde çalışan bir yedek yöntemdir; çünkü 443 portunda TLS trafiğini engelleyen bir ağ, web erişimini de engellemiş demektir. Jitsi paketi sizin için coturn kurulumunu ve yapılandırmasını yapar; belgelenen güvenlik duvarı kurallarının UDP 3478 ve TCP 5349 portlarını içermesinin nedeni tam olarak budur. Galène, 1194 portunda yerleşik TURN özelliğine sahiptir. LiveKit, yapılandırma dosyasından açabileceğiniz gömülü bir TURN sunucusu ile gelir. Eğer coturn'ü kendiniz çalıştırıyorsanız:

sudo apt install -y coturn
sudo systemctl enable --now coturn

listening-port=3478
tls-listening-port=5349
fingerprint
use-auth-secret
static-auth-secret=REPLACE_WITH_A_LONG_RANDOM_STRING
realm=turn.example.com
cert=/etc/letsencrypt/live/turn.example.com/fullchain.pem
pkey=/etc/letsencrypt/live/turn.example.com/privkey.pem
min-port=49152
max-port=65535
no-multicast-peers

Bu ayarlar /etc/turnserver.conf dosyasına eklenir. Debian ve Ubuntu üzerinde paket, kurulduğu anda coturn'ü varsayılan dosya ile başlatır; bu nedenle yukarıdaki enable --now komutu servisi zaten çalışır halde bulur ve hiçbir şeyi değiştirmez. Ayarlarınız sudo systemctl restart coturn komutunu çalıştırdığınızda devreye girer ve dosyada yapılan her sonraki değişiklik için aynı yeniden başlatma işlemi gereklidir. Eski kılavuzlar ayrıca /etc/default/coturn içinde TURNSERVER_ENABLED=1 ayarını yapmanızı söyler. Bu anahtarı yalnızca eski init betiği okur. Mevcut paketlerin çalıştırdığı systemd birimi bunu okumaz, bu yüzden bu satır hiçbir şeyi değiştirmez ve yeniden başlatmadığınız bir coturn hala varsayılan dosyayı kullanmaya devam eder.

Şimdi kimsenin yazmadığı maliyetten bahsedelim. Bir aktarıcı, aktarılan her katılımcının tüm medyasını her iki yönde de taşır. coturn, SFU ile aynı sunucuda olduğunda, bu trafiğin çoğu loopback üzerinden geçer ve uplink yerine CPU maliyeti oluşturur; ayrıca TLS dinleyicisi, medyanın halihazırda taşıdığı DTLS'in üzerine her paketi ikinci kez şifreler. TURN'ü kendi makinesine taşıdığınızda, o makinenin de SFU ile aynı ölçekte bir bant genişliği planına ihtiyacı olur. Ayrıca TCP üzerinden TURN, gerçek zamanlı medyayı güvenilir bir akışa dönüştürür; bu nedenle kaybolan bir paket atlanmak yerine yeniden iletilir ve bağlantısı zayıf olan bir aktarılan katılımcıda, kısa bir takılma yerine gecikme birikir. Aktarma, doğrudan yolun sağlayacağı kaliteden daha düşük bir kalitede de olsa bağlantı sağlayan bir yedek yöntemdir.

SFU ne zaman kod dönüştürme (transcoding) yapar ve maliyeti nedir?

Bir SFU paketleri iletir ve video kodunu asla çözmez; bu nedenle dört çekirdekli bir işlemci, kağıt üzerinde imkansız görünen bir odayı yönetebilir. İki özellik bu çalışma prensibini bozar ve her ikisi de bunları bir onay kutusuyla etkinleştiren kullanıcıları şaşırtır.

Kayıt özelliği bunlardan ilkidir. Jitsi, kayıt işlemini Jibri ile gerçekleştirir ve Jibri'nin kendi belgeleri tam olarak ne yaptığını açıklar: Sanal bir framebuffer içinde oluşturulan bir Chrome örneğini başlatır ve çıktıyı ffmpeg ile yakalayıp kodlar. Bu, tüm toplantınızı oluşturan tam bir tarayıcı ve buna ek olarak bir video kodlayıcıdır; görüşme süresince sürekli çalışır. Aynı belgeler, tek bir Jibri üzerinde aynı anda yalnızca bir kaydın desteklendiğini ve Jibri'nin ekran veya ses aygıtlarını kullanan başka hiçbir uygulamanın bulunmadığı ayrı bir makinede veya sanal makinede çalıştırılması gerektiğini belirtir. Kayıt işlemi bir onay kutusu değil, ikinci bir sunucudur.

Telefonla arama özelliği ise ikincisidir. Bir telefon hattını konferansa köprülemek, 48 kHz hızındaki Opus sesini telefon ağının kabul ettiği formata, genellikle 8 kHz hızındaki G.711 formatına, her iki yönde ve görüşme boyunca sürekli olarak dönüştürmek anlamına gelir. Ses kod dönüştürme işlemi, video kod dönüştürmeye göre çok daha ucuzdur ancak her arama bacağı için çalışır ve asla durmaz; bu nedenle maliyet, arayan kişi sayısıyla doğru orantılı olarak artar. Eğer bir arama numarasına ihtiyacınız varsa, bu işi yapan bileşen kendi kendine barındırılan bir VoIP sunucusudur ve Jibri ile aynı nedenden dolayı kendi sunucusunda çalışmalıdır.

Gerçekte ne kadar büyük bir sunucuya ihtiyacınız var?

İki kişi için neredeyse hiçbir şeye gerek yoktur. Jitsi, tam olarak iki katılımcı olduğunda varsayılan olarak peer-to-peer modunu etkinleştirir; bu modda konferans, veriyi videobridge üzerinden göndermeyi durdurur ve doğrudan bağlantıyı kullanır. Üçüncü bir kişinin katılması, sistemi tekrar köprüye döndürür. Bu nedenle, Jitsi çalıştıran 1 GB RAM'li bir VPS, bire bir görüşmeler için gayet yeterli ancak dört kişilik bir görüşme için yetersizdir; "test ettiğimde çalışıyordu" raporunun bu kadar yaygın olmasının nedeni budur.

Kameralar açıkken yaklaşık on kişiye kadar olan görüşmelerde, sekiz katılımcıda 67.2 Mbps hız, standart bir VPS uplink kapasitesinin içindedir. Kayıt yapmadığınız sürece, iki sanal CPU ve 4 GB RAM, Jitsi veya Galène'i bu ölçekte çalıştıracaktır. CPU grafiğinden ziyade transfer sayacını izleyin.

Otuz kişi için en kötü senaryo 1,044 Mbps sürekli veri akışıdır ve bunun yirmi saati 9.4 TB eder. Bu, sunucunun fiyatından önce bant genişliğinin fiyatını hesaplamanız gereken ölçek seviyesidir. Köprünün yalnızca son konuşmacıları iletmesi için last-N özelliğini açın, katılımcılar için varsayılanı kamera kapalı olarak ayarlayın ve SFU'yu, bu aritmetiği kaldırabilecek bir transfer kotasına sahip bir yere kurun.

Bunun üzerindeki ölçeklerde, tek bir VPS yanlış bir tercihtir. Etkinlik aslında bir yayın ise, bu durumda Owncast ve bir CDN kullanmak, bu maliyetin çok küçük bir kısmına mal olur; ya da tek bir sinyal katmanının arkasında birden fazla videobridge kullanmanız gerekir ki bu, başladığınız projeden farklı bir projedir.

Son bir yönlendirme tavsiyesi. Çoğu ekip, gün içinde videoya ihtiyaç duyduklarından çok daha fazla saat boyunca sohbete ihtiyaç duyar ve sohbeti barındırmak ucuzdur, çalışır durumda tutmak ise kolaydır. Günlük trafik için kendi kendine barındırılan bir Slack alternatifi kurmak ve konferans sunucusunu yalnızca planlanmış görüşmeler için tutmak, küçük bir VPS bütçesiyle sürdürülebilir olan düzenlemedir.

FAQ

İnsanlar Jitsi toplantıma katılabiliyor ancak neden birbirlerini göremiyor veya duyamıyorlar?

Sohbet ve katılımcı listesi, 443 numaralı port üzerinden TCP kullanan sinyal kanalı üzerinden iletilirken, ses ve görüntü verileri videobridge için 10000 numaralı UDP portunu kullanır. Katılımcı listesi doluyor ancak tüm kutucuklar siyah kalıyorsa, sinyal yolu düzgün çalışıyor ancak medya yolu kopuk demektir. Hem sunucu üzerindeki güvenlik duvarında hem de servis sağlayıcınızın kontrol panelindeki ağ güvenlik duvarında 10000 numaralı UDP portunu kontrol edin. Ardından, bridge'in kendi genel IP adresini bildiğinden emin olun: Özel bir IP adresine sahip olan ve genel bir IP'ye yönlendirilen bir sanal makinede, ice4j.harvest.mapping altında statik bir eşleme ekleyin, bunu /etc/jitsi/videobridge/jvb.conf dosyasında yapın ve jitsi-videobridge2 servisini yeniden başlatın. Birisi toplantıya katılırken sudo tcpdump -ni any udp port 10000 komutunu çalıştırmak, sorunun hangisinden kaynaklandığını anlamanızı sağlar; hiç paket akışı olmaması, engelin işletim sisteminin dışında, ağın üst katmanlarında olduğunu gösterir.

30 kişilik bir görüntülü görüşme ne kadar bant genişliği kullanır?

Herkesin kamerasının açık olduğu ve SFU'nun herkese tam kaliteli görüntü katmanı gönderdiği en kötü senaryoda, sunucudan saniyede yaklaşık 1,044 Mbps veri çıkar; bu da saatte 469.8 GB veri trafiği demektir. Bu hesaplama, her biri 1.2 Mbps olan N çarpı (N eksi 1) akış üzerinden yapılan teorik bir aritmetiktir, kurulumunuzun gerçek ölçümü değildir. Simulcast ve last-N ayarları, çoğu katılımcı o an ekranda görünmediği için normal kullanımda bu trafiği ciddi oranda düşürür. Yine de kapasite planlamasını en kötü senaryoya göre yapın, çünkü herkesin kamerasını aynı anda açtığı genel toplantılar yaşanabilir.

Jitsi Meet'i 1 GB RAM'li bir VPS üzerinde çalıştırabilir miyim?

Kurulum gerçekleşir ve iki kişilik bir görüşme çalışır; bunun nedeni Jitsi'nin tam olarak iki katılımcı için peer-to-peer modunu kullanması ve videobridge'i tamamen devre dışı bırakmasıdır. Bu, grup görüşmeleri için kullanışlı bir sunucu değildir. Prosody, videobridge ve Java çalışma zamanı ortamı bellek tüketir; el kitabının ciddi bir kurulum için önerisi 8 GB RAM'dir ve bant genişliği kısıtlamaları bellek sorunlarından önce ortaya çıkacaktır. Elinizde yalnızca 1 GB'lık bir sunucu varsa, Jitsi yerine Galène bu boyut için daha uygun bir tercihtir.

VPS'imin genel bir IP adresi varsa yine de bir TURN sunucusuna ihtiyacım var mı?

Evet. TURN'ün çözdüğü sorun görüşmenin diğer ucundadır. Giden UDP trafiğini engelleyen bir kurumsal ağda bulunan veya her hedef için farklı bir kaynak portu atayan bir NAT arkasındaki katılımcı, sunucunuzun adresi ne kadar genel olursa olsun doğrudan bir medya yolu kuramaz. 443 veya 5349 numaralı portlar üzerinden TCP ile çalışan TURN, bu kullanıcılara güvenlik duvarları tarafından sıradan web trafiği gibi görünen bir aktarım noktası sağlar. Jitsi paket kurulumu, coturn'ü varsayılan olarak bu amaçla yapılandırır; belgelenen güvenlik duvarı kurallarının 3478 numaralı UDP ve 5349 numaralı TCP portlarını açmasının nedeni budur.

BigBlueButton neden Jitsi Meet'ten çok daha fazla donanım kaynağına ihtiyaç duyar?

Çünkü sadece video iletmekten çok daha fazlasını yapar. Yayınlanan üretim gereksinimi 16 GB RAM ve 8 çekirdek iken, Jitsi el kitabında bu değerler 8 GB ve 4 çekirdektir. BigBlueButton; tam bir sesli konferans yığını, paylaşımlı beyaz tahta ve sunum katmanı, kayıt ve işlem sonrası işleme hattı ve kullanıcı hesaplarını içeren bir web arayüzünü aynı makine üzerinde çalıştırır. Ayrıca platform konusunda katı kuralları vardır: Ağustos 2026 itibarıyla desteklenen kurulum, Ubuntu 22.04 üzerinde sürüm 3.0'dır. Her iki rakam seti de ilgili projelerin kendi belgelerinden alınmıştır ve iş yükünüzün gerçek ölçümleri değil, başlangıç noktalarıdır.