VPS üzerinde self-hosted video konferans kurulumu

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

Self-hosted video konferans uygulamaları küçük sunucularda tek bir nedenden dolayı başarısız olur ve bu 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 bir video akışını alır ve diğer tüm katılımcılara bir kopyasını iletir; bu nedenle sunucudan çıkan trafik, katılımcı sayısının karesiyle orantılı olarak artar. Paylaşımlı bir uplink üzerindeki 1 GB veya 2 GB kapasiteli bir VPS, yazılımı sorunsuz çalıştıracaktır. Ancak hayal ettiğiniz tüm katılımcıların dahil olduğu toplantıları taşıyamayacaktır.

Bu nedenle işlemleri şu sırayla gerçekleştirin. Kişi sayısını hesaplayın, megabit değerlerini belirleyin ve ardından sunucuyu seçin. Kurulum, kopyala-yapıştır ile yirmi dakikalık bir işlemdir. Uplink kapasitesi ise insanların sizi duyup duyamayacağını belirleyen temel faktördür.

Bant genişliği neden katılımcı sayısının karesiyle 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, bir sinyalleşme sunucusu dışında hiçbir şeye ihtiyaç duymaz; bire bir görüşmelerin barındırma maliyetinin neredeyse sıfır olmasının nedeni budur. Mesh yapısı dört veya beş kişiden sonra çalışmaz hale gelir; çünkü ev bağlantısı kullanan bir dizüstü bilgisayarın, kendi videosunun dört veya beş ayrı kopyasını aynı anda 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 bu paketleri diğer katılımcılara iletir. Tüm mesele budur; SFU'nun CPU üzerinde hafif, ağ üzerinde ise yoğun olmasının nedeni de budur.

Daha eski bir düzenleme ise MCU (multipoint control unit) yapısıdır. MCU, gelen her akışın kodunu çözer, bunları tek bir görüntüde birleştirir ve bu görüntüyü yeniden kodlar. Giden bant genişliği çok düşüktür. CPU maliyeti ise devasadır. Günümüzde video için neredeyse hiçbir sistem MCU kullanmamaktadır ve bu rehberde de 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 rakamdır.

[
  {
    "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üşmeyi 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 katılımcı 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 gerçekleştiğini 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 hiçbiri eğrinin şeklini değiştirmez ve herkes kamerasını açıp birbirini sabitlediği anda her iki yöntem de faydasını yitirir.

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

Bir plan sayfasında "1 Gbps port" ifadesi yer alabilir. Bu, bir sonraki ağ geçidi için bir taahhüt değil, sanal ağ kartının hızıdır. 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, faturanızda beklenmedik maliyetlerin ortaya çıktığı noktadı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 trafiği oluşturur. RAM miktarına bakmadan önce veri aktarım kotasını kontrol edin; eğer plan sayfasında bu konuda net bir bilgi yoksa, bu belirsizlik aslında size cevabı vermektedir. Ucuz bir VPS teklifini doğru okumak, bu iş yükü için neredeyse diğer tüm iş yüklerinden 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 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 işaret eden alan adları bu adımda başarısız olur.

Ardından portları açın. Aşağıdakiler el kitabında belgelenen portlardır; ufw enable komutu 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 servisi 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: Sinyalleşmeyi yöneten XMPP sunucusu Prosody, yalnızca tek bir çekirdek kullanabilir. Ekstra çekirdekler bridge servisine yardımcı olur ancak sinyalleşme üzerinde bir etkisi yoktur.

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

Bu, bir VPS üzerinde karşılaşılan standart Jitsi başarısızlığıdır. 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 adres atayıp bunu genel bir adresle 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, aynı ayarı 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 içinde yapmaktadır. Bunlar hala çalışır durumdadı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. Paketlerin hangi katmanda düştüğünü bulmak için, dışarıdan biri 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. ufw'nin kendisinden emin değilseniz, 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 en ağır seçenektir ve mevcut bir sunucuya paket olarak kurulamaz.

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ırakacaksanız 50 GB) disk alanıdır. Kullanılan portlar TCP 80 ve 443 ile 16384 ila 32768 arasındaki 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çine 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 ana makine adını (hostname) sahiplenir. Bu bir hata değil, tasarım tercihidir: BigBlueButton makinenin kontrolünün kendisinde olmasını bekler. -w bayrağı güvenlik duvarını yapılandırır, -s ana makine adını belirler, -e Let's Encrypt'in kaydedeceği adresi tanımlar ve -g Greenlight ön yü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 ya da 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 iki katı çekirdek talep ederken, bant genişliği ihtiyacı dörtte bir kadardır. Bu iki rakam aynı yöntemle ölçülmemiştir ve farklı oda boyutlarını varsayarlar; bu nedenle her birini doğrudan karşılaştırmak 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 çalışma zamanı 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 belgelendirmiş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 bunun 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çekten göreceği adresi bildirir; makinenin kendi adresi özel (private) olduğunda ihtiyaç duyulan ş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 belgeleri ç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ı tamamen geçerlidir. Tasarruf ettiğiniz şey, SFU olmayan her şeyin bellek kullanımı ve hareketli parçalarıdır.

Owncast: bant genişliğinin doğrusal kaldığı bire çok yayıncılık

Birçok "video konferans" gereksinimi aslında bir kişinin, sohbet kısmına yazan 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 standart 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 veriyi nesne depolama (object storage) veya bir CDN arkasına taşıyabilir ve kaynak sunucudaki maliyeti sıfırlayabilirsiniz.

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

Projenin dokümantasyonu, bu yazılımın root yetkileriyle çalıştırılmamasını ve herhangi bir uzak betiği çalıştırmadan önce incelenmesini önerir; bu nedenle indirme işlemi yukarıda ayrı bir adım olarak belirtilmiştir. Yükleyici, güncel sürümü ve sisteminizde yoksa bir ffmpeg ikili dosyasını çeker. Kurulum dizininden ./owncast komutunu çalıştırın ve /admin adresindeki 8080 numaralı port üzerinden yönetim paneline erişin. Varsayılan giriş bilgileri admin kullanıcısı ve parola olarak varsayılan yayın anahtarı abc123 şeklindedir. Sunucuya bir alan adı yönlendirmeden önce bu bilgileri mutlaka değiştirin.

HLS tasarımının iki sonucu vardır. HLS bütün segmentleri gönderdiği için izleyiciler canlı yayından birkaç saniye veya dakika geridedir; bu nedenle karşılıklı bir konuşma mümkün değildir. Ayrıca yol üzerinde UDP veya TURN kullanılmadığı için WebRTC çağrılarının bağlanamadığı ağlara dahi ulaşabilir.

Owncast, bu listede kod dönüştürme (transcoding) işlemini bilinçli olarak 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 devam eder. 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

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 şeye ihtiyaç duyar. Birincisi, medya yönlendirmesini yapan bir 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'in dokümante edilmiş portları şunlardır:

• API ve istemci WebSocket için TCP 7880 (TLS termination yapan bir proxy arkasında)
• İstemcinin UDP üzerinden çıkış yapamadığı durumlarda kullanılan ICE over TCP için TCP 7881
• Medya için UDP 50000 ile 60000 arası (odadaki her katılımcı iki port kullanır)
• Gömülü 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 çalışmayacaktır 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 kendi genel adresinin dışarıdan nasıl 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 gereklidir. Bunlardan biri, giden UDP trafiğinin tamamen engellendiği bir kurumsal veya kampüs ağındadır. Diğeri ise her hedef için farklı bir kaynak portu atayan, simetrik NAT olarak adlandırılan ve STUN tarafından bildirilen adresi geçersiz kılan bir taşıyıcı sınıfı NAT (carrier-grade NAT) arkasındadır.

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ıları adayları toplamıştır, ancak hiçbir çift çalışmamış ve ICE başarısız bir durumda sonlanmıştır. Chrome'da, deneme sırasında chrome://webrtc-internals açıldığında aday çiftleri ve bu başarısızlık görülebilir. 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, neredeyse her yerde çalışan yedek bir yöntemdir; çünkü 443 portunda TLS trafiğini engelleyen bir ağ, web erişimini de engellemiş demektir. Jitsi paketi coturn'ü sizin için kurar ve yapılandırır; 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 bir TURN sunucusuna sahiptir. LiveKit'in ise yapılandırma dosyasından açabileceğiniz gömülü bir TURN sunucusu vardır. 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

Debian ve Ubuntu üzerinde paketlenmiş servis, /etc/default/coturn içindeki TURNSERVER_ENABLED=1 ayarını yapana kadar başlamayacaktır. Kurulmuş ancak etkinleştirilmemiş bir coturn, dışarıdan bakıldığında hiç TURN yokmuş gibi görünür; bu tek satırlık ayarın insanlara tüm akşamlarına mal olmasının nedeni budur.

Şimdi de 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'nin üzerine her paketi ikinci kez şifreler. TURN'ü kendi makinesine taşıdığınızda, o makinenin SFU ile aynı şekilde boyutlandırılmış kendi 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 bir hat üzerindeki aktarılan katılımcı, kısa bir takılma yerine gecikme biriktirir. Aktarım, doğrudan yolun sağlayacağı kaliteden daha düşük bir kalitede de olsa bağlantı sağlayan bir yedekleme yöntemidir.

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

Bir SFU, paketleri iletir ve video kod çözme işlemi yapmaz; bu sayede 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.

Birincisi kayıttır. 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 sürekli çalışan bir video kodlayıcıdı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.

İkincisi ise telefonla arama özelliğidir. Bir telefon hattını konferansa köprülemek, 48 kHz hızındaki Opus ses verisini telefon ağının kabul ettiği formata, genellikle 8 kHz hızındaki G.711 formatına, her iki yönde ve tüm 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ı istiyorsanız, bu işi yapan bileşen kendi sunucunuzda barındırdığınız bir VoIP sunucusudur ve Jibri ile aynı nedenden dolayı bu bileşen de kendi özel sunucusunda çalışmalıdır.

Gerçekten 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 eşler arası (peer to peer) moda geçer; 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ü moduna döndürür. Bu nedenle, Jitsi çalıştıran 1 GB RAM'li bir VPS, bire bir görüşmeler için gayet yeterliyken dört kişilik bir görüşme için yetersiz kalır; "test ettiğimde çalışıyordu" raporlarının bu kadar yaygın olmasının sebebi budur.

Kameralar açıkken yaklaşık on kişiye kadar olan kullanımlarda, sekiz katılımcıda 67.2 Mbps değerindeki trafik, standart bir VPS uplink kapasitesinin içindedir. Kayıt almadığı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ü senaryoda 1,044 Mbps sürekli trafik oluşur ve bunun yirmi saatlik karşılığı 9.4 TB'tır. 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 Owncast ve bir CDN kullanmak bunun maliyetinin çok küçük bir kısmına denk gelir; 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 boyuttur.

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üzen budur.

FAQ

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

Sohbet ve katılımcı listesi, 443 numaralı port üzerinden TCP ile iletilen sinyal kanalı üzerinden taşınırken, ses ve görüntü verileri videobridge için 10000 numaralı UDP portunu kullanır. Katılımcı listesi doluyor ancak tüm ekranlar 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, videobridge'in kendi genel IP adresini bildiğinden emin olun: Özel bir IP adresine sahip olan ve genel bir IP adresine yönlendirilen bir sanal makinede, ice4j.harvest.mapping altında statik bir eşleme ekleyin ve /etc/jitsi/videobridge/jvb.conf dosyasını düzenleyerek 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, yani 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ü aktardığı 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, N çarpı (N eksi 1) adet akışın her birinin 1.2 Mbps olduğu varsayımına dayanan teorik bir değerdir, 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 değeri 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ığı toplantılar gerçekleşebilir.

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ışabilir; 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. Ancak 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ındaki öneri ciddi bir kurulum için 8 GB RAM'dir ve bant genişliği kısıtlamaları bellek sorunundan önce karşınıza çıkacaktır. Eğer elinizde sadece 1 GB RAM'li bir sunucu varsa, Jitsi yerine Galène bu boyut için daha uygun bir tercihtir.

VPS'imin genel bir IP adresi varsa yine de 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 veya hedef başına farklı bir kaynak portu atayan bir carrier-grade NAT arkasında bulunan bir 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, güvenlik duvarları için sıradan bir web trafiği gibi görünen bir aktarım sağlar. Jitsi paket kurulumu, coturn servisini 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ç duyuyor?

Çünkü sadece görüntü aktarmaktan çok daha fazlasını yapar. Yayınlanan üretim gereksinimleri 16 GB RAM ve 8 çekirdek iken, Jitsi el kitabında bu değerler 8 GB RAM ve 4 çekirdektir. BigBlueButton; tam bir sesli konferans yığını, paylaşımlı beyaz tahta ve sunum katmanı, kayıt ve işlem sonrası 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ı gereksinimleri vardır: Ağustos 2026 itibarıyla desteklenen kurulum, Ubuntu 22.04 üzerinde sürüm 3.0'dır. Her iki projenin verileri de kendi belgelerinden alınmıştır ve iş yükünüzün gerçek ölçümü değil, başlangıç noktalarıdır.