VPS पर self-hosted video conferencing कैसे सेटअप करें

VPS पर self-hosted video conferencing एक bandwidth समस्या है

छोटे servers पर self-hosted video conferencing एक कारण से विफल होती है, और यह लगभग कभी भी installation की समस्या नहीं होती। हर आधुनिक tool जिस server component का उपयोग करता है, वह SFU (selective forwarding unit) है। यह प्रत्येक participant से एक video stream लेता है और उसकी एक copy हर दूसरे participant को forward करता है, इसलिए server से बाहर जाने वाला traffic participants की संख्या के वर्ग (square) के अनुपात में बढ़ता है। 1 GB या 2 GB का VPS, shared uplink पर software को तो ठीक से चला लेगा, लेकिन यह उस बड़ी meeting को नहीं संभाल पाएगा जिसकी आप कल्पना कर रहे हैं।

इसलिए काम को इस क्रम में करें। लोगों की संख्या गिनें, megabits का हिसाब लगाएं, और फिर server चुनें। Installation तो केवल बीस मिनट का copy और paste का काम है। Uplink ही यह तय करता है कि कोई आपको सुन पाएगा या नहीं।

सहभागियों की संख्या बढ़ने के साथ bandwidth वर्ग (square) के अनुपात में क्यों बढ़ती है?

Mesh से शुरुआत करते हैं। प्रत्येक browser अपने camera का feed encode करता है और उसकी एक प्रति सीधे दूसरे browser को भेजता है, और कोई भी media server video को process नहीं करता। दो लोगों की mesh call के लिए केवल एक signalling server की आवश्यकता होती है, इसीलिए one-to-one calls को host करना लगभग मुफ्त होता है। चार या पांच लोगों के बाद mesh काम करना बंद कर देता है, क्योंकि home connection पर चल रहे laptop को एक ही समय में अपने video की चार या पांच अलग-अलग प्रतियां upload करनी पड़ती हैं।

SFU अलग तरह से काम करता है। प्रत्येक browser server पर एक प्रति upload करता है। Server RTP (real-time transport protocol) headers को पढ़ता है और video को decode किए बिना उन packets को अन्य सहभागियों को forward कर देता है। यही इसका मुख्य तरीका है, और इसीलिए SFU पर CPU का भार कम और network का भार अधिक होता है।

पुरानी व्यवस्था MCU (multipoint control unit) है। यह हर incoming stream को decode करता है, उन्हें एक ही picture में मिलाता है, और फिर उस picture को re-encode करता है। इसमें outbound bandwidth बहुत कम होती है, लेकिन CPU की लागत बहुत अधिक होती है। आजकल video के लिए लगभग कोई भी MCU का उपयोग नहीं करता है, और इस guide में भी इसका उपयोग नहीं किया गया है।

अब SFU के लिए गणित को समझते हैं। मान लें कि हर व्यक्ति 1.2 Mbps पर video भेज रहा है और किसी का भी camera बंद नहीं है। Server N गुना 1.2 Mbps प्राप्त करता है, जो कि linear है और कोई समस्या नहीं है। Server N गुना (N minus 1) गुना 1.2 Mbps भेजता है, क्योंकि N लोगों में से प्रत्येक को अन्य N minus 1 streams प्राप्त करनी होती हैं। यह दूसरा आंकड़ा ही है जो projects को विफल कर देता है।

[
  {
    "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
  }
]

ये पंक्तियाँ गणितीय हैं, किसी विशेष server का मापन नहीं। मासिक column एक महीने में बीस घंटे की calls का अनुमान लगाता है। सबसे पहले आखिरी पंक्ति पढ़ें। camera पर पचास लोगों के लिए एक ही machine से 2,940 Mbps के निरंतर outbound traffic की आवश्यकता होती है। तीस लोगों के लिए 1,044 Mbps की आवश्यकता होती है। चार लोगों के लिए 14.4 Mbps की आवश्यकता होती है, जिसे कोई भी VPS बिना किसी समस्या के संभाल लेता है। चार लोगों वाली पंक्ति और तीस लोगों वाली पंक्ति के बीच, लोगों की संख्या साढ़े सात गुना बढ़ती है जबकि outbound traffic सत्तर गुना से अधिक बढ़ जाता है।

वास्तविक deployments इन आंकड़ों से कम पर काम करती हैं, और यह जानना महत्वपूर्ण है कि कैसे। Jitsi और LiveKit दोनों simulcast का उपयोग करते हैं: एक sender एक साथ कई quality layers publish करता है, और SFU उस व्यक्ति को low layer forward करता है जो screen पर नहीं है। Jitsi में last-N setting भी होती है जो केवल हाल ही में बोलने वाले लोगों का video ही forward करती है। दोनों ही बहुत सारा traffic बचाते हैं। इनमें से कोई भी curve के आकार को नहीं बदलता है, और जैसे ही हर कोई अपना camera चालू करता है और एक-दूसरे को pin करता है, ये दोनों ही मदद करना बंद कर देते हैं।

VPS uplink वास्तव में आपको क्या प्रदान करता है?

एक प्लान पेज पर "1 Gbps port" लिखा होता है। यह वर्चुअल नेटवर्क कार्ड की गति है, न कि अगले हॉप (next hop) के बारे में कोई वादा। यह लिंक उसी फिजिकल होस्ट पर मौजूद अन्य किरायेदारों के साथ साझा किया जाता है, इसलिए व्यस्त घंटों के दौरान निरंतर थ्रूपुट (sustained throughput) पोर्ट की गति से कम होता है, और एक कॉन्फ्रेंस कॉल बिल्कुल निरंतर लोड (sustained load) जैसा ही है। अधिकांश प्लान में मासिक ट्रांसफर लिमिट भी होती है, जिसके बाद आपकी गति कम (throttle) कर दी जाती है या आपसे अतिरिक्त शुल्क लिया जाता है।

वह लिमिट ही वह बिंदु है जहाँ इनवॉइस पर खर्च बढ़ जाता है। एक महीने में तीस लोगों की कॉल के बीस घंटे सर्वर से 9.4 TB डेटा बाहर भेजते हैं, जो 469.8 GB प्रति घंटे की दर से होता है। पचास लोगों की कॉल के बीस घंटे 26.5 TB डेटा खर्च करते हैं। RAM के आंकड़े देखने से पहले ट्रांसफर लिमिट की जाँच करें, और यदि प्लान पेज पर इसके बारे में स्पष्ट जानकारी नहीं है, तो वह अस्पष्टता ही आपका उत्तर है। सस्ते VPS ऑफर को सही ढंग से पढ़ना इस वर्कलोड के लिए लगभग किसी भी अन्य कार्य की तुलना में अधिक महत्वपूर्ण है।

Jitsi Meet: डिफ़ॉल्ट विकल्प और इसकी आवश्यकताएं

Jitsi Meet वह विकल्प है जिससे अधिकांश लोगों को शुरुआत करनी चाहिए। यह प्रोजेक्ट के अपने Debian रिपॉजिटरी से इंस्टॉल होता है, इंस्टॉलेशन के दौरान यह nginx और एक सर्टिफिकेट को कॉन्फ़िगर करता है, और videobridge (JVB) एक ही UDP पोर्ट का उपयोग करता है, जिससे फ़ायरवॉल नियम संक्षिप्त रहते हैं। इसके लिए Debian 11 या नया, या Ubuntu 22.04 या नया वर्ज़न आवश्यक है।

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

इंस्टॉलर होस्टनेम पूछता है और फिर सर्टिफिकेट का विकल्प देता है। Let's Encrypt विकल्प चुनें, और इसे एक ऐसा डोमेन नाम दें जो पहले से ही इस सर्वर के पब्लिक एड्रेस पर रिज़ॉल्व होता हो। सर्टिफिकेट HTTP चैलेंज के माध्यम से जारी किया जाता है, इसलिए यदि नाम कहीं और पॉइंट कर रहा है, तो वह चरण विफल हो जाएगा।

इसके बाद पोर्ट्स खोलें। ये वे पोर्ट्स हैं जिन्हें हैंडबुक में प्रलेखित किया गया है, SSH को सबसे पहले रखें ताकि ufw enable आपको लॉक आउट न कर दे:

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 और 443 वेब ऐप को सर्व करते हैं और सर्टिफिकेट को रिन्यू होने देते हैं। UDP 10000 सभी ऑडियो और वीडियो को कैरी करता है, और यही वह पोर्ट है जिसे लोग अक्सर भूल जाते हैं। UDP 3478 और TCP 5349 उस coturn सर्वर के लिए हैं जिसे Jitsi पैकेज ब्रिज के साथ इंस्टॉल करता है, जो उन लोगों के लिए फॉलबैक पाथ है जिनका नेटवर्क UDP को ब्लॉक करता है।

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

पहली कमांड को सर्विस को active रिपोर्ट करना चाहिए। दूसरी कमांड को ब्रिज को UDP 10000 पर listening दिखाना चाहिए। यदि यह कुछ भी प्रिंट नहीं करता है, तो ब्रिज स्टार्ट नहीं हुआ है, और /var/log/jitsi/jvb.log बताएगा कि क्यों।

साइजिंग के लिए, Jitsi की हैंडबुक अपना शुरुआती बिंदु प्रकाशित करती है और BigBlueButton एक बहुत बड़ा बिंदु प्रकाशित करता है:

[
  {
    "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 की हैंडबुक एक गंभीर सर्वर के लिए 8 GB RAM और 4 डेडिकेटेड कोर का सुझाव देती है, जिसमें 1,000 Mbps नेटवर्क अक्सर पर्याप्त होता है, और यह नोट करती है कि छोटे सेटअप 4 GB या 2 GB पर भी चल सकते हैं। उस पेज पर एक विवरण ध्यान देने योग्य है: Prosody, जो XMPP सर्वर है और सिग्नलिंग को हैंडल करता है, केवल एक कोर का उपयोग कर सकता है। अतिरिक्त कोर ब्रिज की मदद करते हैं लेकिन सिग्नलिंग के लिए कुछ नहीं करते।

सभी लोग कॉल में क्यों जुड़ जाते हैं लेकिन किसी को वीडियो क्यों नहीं दिखता?

VPS पर Jitsi में यह एक सामान्य विफलता है। प्रतिभागियों की सूची भर जाती है, चैट काम करती है, लेकिन हर वीडियो टाइल काली रहती है। Videobridge अपने स्वयं के इंटरफेस पर मिलने वाले पतों का विज्ञापन करती है। ऐसे प्रदाता पर जो वर्चुअल मशीन को एक निजी पता देता है और उस पर एक सार्वजनिक पता मैप करता है, JVB को केवल निजी पता ही मिलता है। इसलिए, प्रत्येक क्लाइंट 10.0.0.5 जैसे पते पर मीडिया भेजने का प्रयास करता है और पैकेट कहीं नहीं पहुँच पाते।

ब्रिज को दोनों पतों के बारे में सूचित करें। /etc/jitsi/videobridge/jvb.conf में एक स्टेटिक मैपिंग जोड़ें:

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

sudo systemctl restart jitsi-videobridge2 के साथ रीस्टार्ट करें। ip -4 addr show से स्थानीय पता और अपने प्रदाता के कंट्रोल पैनल से सार्वजनिक पता लें। पुराने गाइड /etc/jitsi/videobridge/sip-communicator.properties में org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS और org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS कुंजियों के साथ यही सेटिंग करते थे। वे अभी भी काम करते हैं, और नए इंस्टॉलेशन में ऊपर दिए गए मैपिंग ब्लॉक का उपयोग करना चाहिए।

दूसरा कारण वह फायरवॉल है जिसे आपने कॉन्फ़िगर नहीं किया है। अधिकांश प्रदाता कंट्रोल पैनल में एक नेटवर्क फायरवॉल चलाते हैं जो सर्वर पर मौजूद ufw से अलग होता है, और UDP 10000 को दोनों में खुला होना चाहिए। यह पता लगाने के लिए कि कौन सी परत पैकेट को ड्रॉप कर रही है, सर्वर पर sudo tcpdump -ni any udp port 10000 चलाएं जबकि कोई बाहर से जुड़ रहा हो। यदि कोई पैकेट नहीं दिखता है, तो इसका मतलब है कि मशीन तक कुछ भी नहीं पहुँच रहा है, इसलिए ब्लॉक ऑपरेटिंग सिस्टम के अपस्ट्रीम में है। यदि पैकेट आ रहे हैं लेकिन टाइलें काली हैं, तो इसका मतलब है कि ब्रिज ऐसे पते के साथ उत्तर दे रहा है जिसे क्लाइंट एक्सेस नहीं कर सकता, इसलिए यह मैपिंग की समस्या है। यदि आप ufw को लेकर अनिश्चित हैं, तो VPS के लिए आवश्यक ufw नियम उन नियमों के क्रम को कवर करता है जो अक्सर लोगों को भ्रमित करते हैं।

BigBlueButton: भारी, विशिष्ट, और इसे पूरा सर्वर चाहिए

BigBlueButton को शिक्षण के लिए तैयार किया गया है। इसमें व्हाइटबोर्ड, ब्रेकआउट रूम, पोल और प्रेजेंटेशन एरिया की सुविधा है, और इसकी रिकॉर्डिंग पाइपलाइन एक अतिरिक्त फीचर के बजाय मुख्य विशेषता है। यह यहाँ दिए गए विकल्पों में सबसे भारी है, और यह ऐसा पैकेज नहीं है जिसे आप किसी मौजूदा सर्वर पर इंस्टॉल कर सकें।

अगस्त 2026 तक, समर्थित पाथ Ubuntu 22.04 पर BigBlueButton 3.0 है, जिसे jammy-300 वर्ज़न फ्लैग के साथ चुना जाता है। प्रोजेक्ट की आधिकारिक प्रोडक्शन आवश्यकताओं में 16 GB मेमोरी (swap इनेबल्ड के साथ), 8 CPU कोर (उच्च सिंगल-थ्रेड परफॉरमेंस के साथ), 250 Mbps सिमेट्रिक बैंडविड्थ, और यदि आप रिकॉर्डिंग रखते हैं तो 500 GB डिस्क (यदि आप उन्हें डिसेबल करते हैं तो 50 GB) शामिल हैं। इसके लिए TCP पोर्ट 80 और 443, तथा UDP रेंज 16384 से 32768 की आवश्यकता होती है।

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

प्रोजेक्ट के अपने उदाहरण उस स्क्रिप्ट को सीधे bash में पाइप करते हैं। इसके बजाय इसे पहले डाउनलोड करें और पढ़ें, क्योंकि यह आपके nginx कॉन्फ़िगरेशन को फिर से लिखता है, अपना मीडिया और ऑडियो स्टैक इंस्टॉल करता है, पैकेज वर्ज़न को पिन करता है, और होस्टनेम पर अपना अधिकार जमाता है। यह एक खामी नहीं बल्कि इसका डिज़ाइन है: BigBlueButton मशीन का पूर्ण स्वामित्व चाहता है। -w फ्लैग फायरवॉल को कॉन्फ़िगर करता है, -s होस्टनेम है, -e वह पता है जिसे Let's Encrypt रजिस्टर करता है, और -g Greenlight फ्रंट एंड को जोड़ता है। यदि उसी मशीन पर अन्य सेवाओं के लिए भी TLS टर्मिनेशन हो रहा है, तो या तो BigBlueButton को कहीं और ले जाएँ या स्क्रिप्ट द्वारा संपादन करने से पहले यह सुनिश्चित करें कि आप आपका nginx reverse proxy कॉन्फ़िगरेशन क्या कर रहा है इसे समझते हैं।

उस चार्ट में दी गई दो पंक्तियों की सावधानीपूर्वक तुलना करें। BigBlueButton, Jitsi के सुझाव की तुलना में दोगुनी मेमोरी और दोगुने कोर की मांग करता है, जबकि बैंडविड्थ की आवश्यकता एक-चौथाई है। इन दोनों आंकड़ों को एक ही तरीके से नहीं मापा गया है और वे अलग-अलग रूम साइज़ मानकर चलते हैं, इसलिए प्रत्येक को समान तुलना के बजाय संबंधित प्रोजेक्ट का शुरुआती बिंदु मानें। CPU का अंतर वास्तविक है, और यह उन सभी कार्यों से आता है जो BigBlueButton वीडियो फॉरवर्ड करने के अलावा करता है।

Galène: छोटा विकल्प

Galène Go में लिखा गया एक कॉम्पैक्ट SFU है। यह एक एकल static binary के रूप में build होता है, इसमें अपना स्वयं का web client शामिल है, और इसमें एक TURN server भी है। इसलिए, इसमें न तो किसी XMPP server की आवश्यकता है, न ही Java runtime या किसी Rails application को चालू रखने की। यदि आपकी आवश्यकता एक साधारण सर्वर पर दस लोगों की विश्वसनीय कॉल की है, तो अधिक hardware की आवश्यकता पर विचार करने से पहले इसे आजमाएं।

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 पर golang-go पैकेज Go 1.22 है। यदि go build यह शिकायत करता है कि module को नए Go संस्करण की आवश्यकता है, तो distribution पैकेज के साथ संघर्ष करने के बजाय go.dev से वर्तमान toolchain इंस्टॉल करें।

Galène में group का अर्थ एक room है, और एक group एक JSON फ़ाइल होती है:

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

https://your.server:8443/group/night-watch/ खोलें और vimes के रूप में log in करें। ये credentials सीधे project के README से आते हैं, इसलिए port के कहीं और से सुलभ होने से पहले इन्हें बदल दें। वास्तविक deployment के लिए project एक systemd unit का दस्तावेजीकरण करता है:

[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

web interface के लिए TCP 8443, built-in TURN server के लिए TCP और UDP 1194, और media के लिए उच्च UDP ports की एक range का उपयोग होता है। उस range को pin करें ताकि आप इसके लिए एक firewall rule लिख सकें:

./galene -udp-range 40000-40100

VPS पर -turn विकल्प सबसे महत्वपूर्ण है। -turn ':1194' सभी public IPv4 addresses पर listen करता है। -turn '203.0.113.1:1194' Galène को वह address बताता है जिसे clients वास्तव में देखेंगे, जिसकी आवश्यकता तब होती है जब machine का अपना address private हो। -turn '' built-in server को disable करता है ताकि आप data/ice-servers.json के माध्यम से किसी external server की ओर संकेत कर सकें। default मान auto है, जो ice-servers.json न होने पर :1194 की तरह व्यवहार करता है।

आप data/config.json में proxyURL सेट करके और WebSocket upgrade headers के साथ /ws location को proxy करके web interface के सामने nginx लगा सकते हैं। यह समझें कि यह क्या कवर करता है: clients अभी भी सीधे UDP flows और TURN port पर सीधे TCP connections खोलते हैं, इसलिए reverse proxy केवल page और signalling को संभालता है। Media कभी भी इसके माध्यम से नहीं गुजरता है।

Galène का दस्तावेजीकरण कहता है कि इसे बहुत कम server resources की आवश्यकता होती है और यह कोई विशिष्ट आंकड़ा प्रकाशित नहीं करता है, इसलिए किसी आंकड़े की अपेक्षा न करें। ऊपर दी गई bandwidth गणना पूरी तरह से लागू होती है। आप जो बचाते हैं वह SFU के अलावा अन्य सभी चीजों की memory और moving parts हैं।

Owncast: one-to-many, जहाँ bandwidth linear रहती है

कई "video conferencing" आवश्यकताओं में वास्तव में एक व्यक्ति दर्शकों के सामने प्रस्तुत कर रहा होता है जो chat में टाइप करते हैं। यदि आपकी आवश्यकता यही है, तो SFU गलत टूल है और इसके आर्थिक पहलू पूरी तरह से अलग हैं। Owncast, OBS या समान encoder से RTMP stream लेता है और सामान्य HTTPS पर HLS सर्व करता है। प्रति viewer bandwidth quadratic के बजाय linear होती है, और चूंकि output साधारण HTTP segments होते हैं, आप इसे object storage या CDN के पीछे ले जा सकते हैं और origin पर इसके लिए भुगतान करना बंद कर सकते हैं।

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

प्रोजेक्ट का documentation कहता है कि इसे root के रूप में न चलाएं, और किसी भी remote script को execute करने से पहले उसकी जांच करें, इसीलिए download ऊपर एक अलग चरण है। Installer current release और यदि आपके पास पहले से नहीं है तो एक ffmpeg binary fetch करता है। Install directory से ./owncast चलाएं और port 8080 पर /admin पर admin panel खोलें। Default login यूजर admin है और default stream key abc123 पासवर्ड के रूप में है। सर्वर पर domain point करने से पहले इसे बदलें।

HLS डिज़ाइन के दो परिणाम होते हैं। Viewers live से कुछ सेकंड या मिनट पीछे होते हैं, क्योंकि HLS पूरे segments भेजता है, इसलिए कोई back-and-forth बातचीत नहीं होती है। और रास्ते में कहीं भी UDP और TURN नहीं होता है, इसलिए यह उन networks तक पहुँच जाता है जहाँ WebRTC call connect ही नहीं हो पाती।

Owncast यहाँ एकमात्र ऐसा टूल भी है जो जानबूझकर transcoding करता है। आपके द्वारा enable की गई प्रत्येक output quality आने वाली stream का एक और ffmpeg encode होती है, जो broadcast की पूरी अवधि तक चलती है। एक छोटे VPS पर, एक या दो qualities ही प्रदान करें। पांच qualities CPU को saturate कर देंगी जबकि network खाली बैठा रहेगा।

अपने मौजूदा Matrix सर्वर पर Element Call का उपयोग

यदि आप पहले से ही Matrix चला रहे हैं, तो वीडियो एक अतिरिक्त सुविधा है, न कि कोई दूसरा उत्पाद जिसे अलग से संचालित करना हो। यह एक से अधिक पैकेज का संयोजन है। Element Call को आपके homeserver के पीछे दो चीजों की आवश्यकता होती है। पहली है LiveKit SFU, जो मीडिया फॉरवर्डिंग का कार्य करती है। दूसरी है MatrixRTC ऑथराइजेशन सर्विस, element-hq/lk-jwt-service, जो क्लाइंट को LiveKit WebSocket URL और कनेक्ट करने के लिए एक साइन्ड JWT (JSON web token) प्रदान करती है। वह सर्विस Matrix फेडरेशन API का उपयोग करती है, इसलिए इसके सामने एक TLS reverse proxy और एक ऐसा नाम होना आवश्यक है जिसे फेडरेशन एक्सेस कर सके।

LiveKit के लिए निर्धारित पोर्ट्स:

• API और क्लाइंट WebSocket के लिए TCP 7880, एक ऐसे प्रॉक्सी के पीछे जो TLS टर्मिनेट करता हो
• ICE over TCP के लिए TCP 7881, जिसका उपयोग तब होता है जब क्लाइंट UDP के माध्यम से बाहर नहीं निकल पाता
• मीडिया के लिए UDP 50000 से 60000, जहाँ एक रूम में प्रत्येक प्रतिभागी दो पोर्ट्स का उपयोग करता है
• यदि आप एम्बेडेड TURN सर्वर सक्षम करते हैं तो UDP 3478 और TCP 5349, और 5349 को 443 पर ले जाना होगा जब तक कि इसके सामने कोई लोड बैलेंसर न हो

प्रति प्रतिभागी दो पोर्ट्स सुनने में चिंताजनक लग सकते हैं, लेकिन ऐसा नहीं है। 10,000 पोर्ट्स की रेंज हजारों प्रतिभागियों के लिए पर्याप्त है, और रेंज समाप्त होने से बहुत पहले ही आपका अपलिंक बैंडविड्थ खत्म हो जाएगा। पूरी रेंज को ओपन रखें, क्योंकि आंशिक रूप से खुली रेंज कुछ लोगों के लिए काम करती है और दूसरों के लिए नहीं, जो कि डिबग करने के लिए सबसे कठिन प्रकार की समस्या है। इसका homeserver वाला हिस्सा एक अलग कार्य है, जिसे VPS पर Synapse homeserver चलाना में कवर किया गया है।

एक व्यक्ति कभी कनेक्ट क्यों नहीं हो पाता? TURN और UDP को ब्लॉक करने वाले नेटवर्क

सबसे पहले कुछ शब्दावली, जिनका उपयोग एक-एक बार किया गया है। ICE (interactive connectivity establishment) वह प्रक्रिया है जिसका उपयोग दो WebRTC एंडपॉइंट्स अपने बीच एक कार्यशील रास्ता खोजने के लिए करते हैं। STUN (session traversal utilities for NAT) एक छोटी सेवा है जो क्लाइंट को बताती है कि बाहर से उसका अपना सार्वजनिक पता कैसा दिखता है। TURN (traversal using relays around NAT) एक रिले है: जब कोई सीधा रास्ता मौजूद नहीं होता, तो दोनों पक्ष अपना मीडिया TURN सर्वर को भेजते हैं और वह उसे आगे फॉरवर्ड करता है।

आपको उन प्रतिभागियों के लिए TURN की आवश्यकता होती है जिनके नेटवर्क आप देख नहीं सकते। उनमें से एक किसी कॉर्पोरेट या कैंपस नेटवर्क पर है जहाँ आउटबाउंड UDP पूरी तरह से ब्लॉक है। दूसरा एक कैरियर-ग्रेड NAT के पीछे है जो हर डेस्टिनेशन के लिए एक अलग सोर्स पोर्ट देता है, जिसे symmetric NAT कहा जाता है और जो STUN द्वारा रिपोर्ट किए गए पते को बेकार बना देता है।

इसके लक्षण विशिष्ट हैं। अधिकांश लोग जुड़ जाते हैं और सब कुछ काम करता है। एक व्यक्ति प्रतिभागी सूची देखता है, चैट देखता है, और उसे एक काली टाइल और एक स्पिनर दिखाई देता है। उनके ब्राउज़र ने कैंडिडेट्स एकत्र किए, कोई भी पेयर काम नहीं किया, और ICE एक विफल स्थिति में समाप्त हो गया। Chrome में, प्रयास के दौरान chrome://webrtc-internals खोलने पर कैंडिडेट पेयर्स और वह विफलता दिखाई देती है। उस व्यक्ति से मोबाइल डेटा पर फोन से पुनः प्रयास करने के लिए कहें। यदि यह वहां काम करता है, तो उनका नेटवर्क ही कारण है और TURN इसका समाधान है।

443 या 5349 पर TCP के माध्यम से TURN वह फॉलबैक है जो लगभग हर जगह काम करता है, क्योंकि 443 पर TLS को ब्लॉक करने वाले नेटवर्क ने वेब को ही ब्लॉक कर दिया है। Jitsi का पैकेज आपके लिए coturn को इंस्टॉल और कॉन्फ़िगर करता है, यही कारण है कि इसके प्रलेखित फायरवॉल नियमों में UDP 3478 और TCP 5349 शामिल हैं। Galène में 1194 पर TURN इन-बिल्ट है। LiveKit में एक एम्बेडेड TURN सर्वर है जिसे आप कॉन्फ़िगरेशन में चालू करते हैं। यदि आप स्वयं coturn चलाते हैं:

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 और Ubuntu पर पैकेज़्ड सर्विस तब तक शुरू नहीं होगी जब तक आप /etc/default/coturn में TURNSERVER_ENABLED=1 सेट नहीं करते। एक coturn जो इंस्टॉल तो है लेकिन इनेबल नहीं है, बाहर से बिल्कुल वैसा ही दिखता है जैसे कि कोई TURN ही न हो, यही कारण है कि यह एक लाइन लोगों की पूरी शाम बर्बाद कर देती है।

अब वह लागत जिसके बारे में कोई नहीं लिखता। एक रिले हर रिले किए गए प्रतिभागी के पूर्ण मीडिया को दोनों दिशाओं में ले जाता है। जब coturn SFU के साथ एक ही बॉक्स साझा करता है, तो अधिकांश ट्रैफ़िक लूपबैक को पार करता है और आपकी अपलिंक के बजाय CPU की खपत करता है, और TLS लिसनर मीडिया द्वारा पहले से ही ले जाए जा रहे DTLS के ऊपर हर पैकेट को दूसरी बार एन्क्रिप्ट करता है। जब आप TURN को अपनी मशीन पर ले जाते हैं, तो उस मशीन को अपनी बैंडविड्थ योजना की आवश्यकता होती है जिसे SFU के समान ही आकार दिया गया हो। और TCP पर TURN रीयल-टाइम मीडिया को एक विश्वसनीय स्ट्रीम में बदल देता है, इसलिए एक खोया हुआ पैकेट छोड़े जाने के बजाय पुनः प्रेषित किया जाता है, और एक लॉस लिंक पर रिले किया गया प्रतिभागी एक संक्षिप्त गड़बड़ी के बजाय देरी जमा करता है। रिले एक फॉलबैक है जो कनेक्ट तो करता है, लेकिन उस गुणवत्ता पर जिसे सीधा रास्ता मात दे देता।

SFU कब ट्रांसकोड करता है और इसकी लागत क्या है?

SFU केवल पैकेट फॉरवर्ड करता है और कभी भी वीडियो को डिकोड नहीं करता है, यही कारण है कि चार कोर ऐसे रूम को संभाल सकते हैं जो कागजों पर असंभव लगता है। दो फीचर्स इस विशेषता को खत्म कर देते हैं, और दोनों ही उन लोगों को हैरान करते हैं जिन्होंने चेकबॉक्स से उन्हें इनेबल किया है।

रिकॉर्डिंग पहला फीचर है। Jitsi, Jibri के साथ रिकॉर्डिंग करता है, और Jibri का अपना डॉक्यूमेंटेशन स्पष्ट रूप से बताता है कि यह क्या करता है: यह एक वर्चुअल फ्रेमबफर में रेंडर किए गए Chrome इंस्टेंस को लॉन्च करता है और ffmpeg के साथ आउटपुट को कैप्चर और एनकोड करता है। यह एक पूरा ब्राउज़र है जो आपकी पूरी मीटिंग को रेंडर कर रहा है, साथ ही एक वीडियो एनकोडर भी है, जो कॉल की पूरी अवधि के दौरान लगातार चलता रहता है। वही डॉक्यूमेंटेशन बताता है कि एक समय में केवल एक ही रिकॉर्डिंग एक Jibri पर समर्थित है, और Jibri को एक अलग मशीन या वर्चुअल मशीन पर चलाने का इरादा है, जिसमें कोई अन्य एप्लिकेशन डिस्प्ले या ऑडियो डिवाइस का उपयोग न कर रही हो। रिकॉर्डिंग एक दूसरा सर्वर है, न कि केवल एक चेकबॉक्स।

टेलीफोन डायल-इन दूसरा फीचर है। फोन लाइन को कॉन्फ्रेंस से जोड़ने का मतलब है Opus को 48 kHz पर उस फॉर्मेट में बदलना जिसे टेलीफोन नेटवर्क स्वीकार करता है, आमतौर पर 8 kHz पर G.711, दोनों दिशाओं में और पूरी कॉल के दौरान लगातार। ऑडियो ट्रांसकोडिंग, वीडियो ट्रांसकोडिंग की तुलना में बहुत सस्ती है, लेकिन यह प्रति कॉल लेग चलती है और कभी रुकती नहीं है, इसलिए लागत कॉल करने वालों की संख्या के साथ बढ़ती है। यदि आप डायल-इन नंबर चाहते हैं, तो a self-hosted VoIP server वह घटक है जो यह काम करता है, और यह उसी कारण से अपनी अलग मशीन पर होना चाहिए जिस कारण से Jibri होता है।

आपको वास्तव में कितने बड़े सर्वर की आवश्यकता है?

दो लोगों के लिए, लगभग कुछ भी नहीं। जब ठीक दो प्रतिभागी होते हैं तो Jitsi डिफ़ॉल्ट रूप से peer to peer मोड को सक्षम कर देता है, और उस मोड में कॉन्फ्रेंस videobridge के माध्यम से डेटा भेजना बंद कर देती है और सीधे कनेक्शन का उपयोग करती है। तीसरा व्यक्ति जुड़ने पर यह वापस bridge पर स्विच हो जाता है। इसलिए 1 GB का VPS एक-से-एक कॉल सर्वर के रूप में तो ठीक है, लेकिन चार लोगों के लिए यह कमजोर है, यही कारण है कि "जब मैंने इसका परीक्षण किया तो यह काम कर रहा था" जैसी रिपोर्ट इतनी आम है।

कैमरे चालू होने पर लगभग दस लोगों तक के लिए, आठ प्रतिभागियों पर 67.2 Mbps की गति एक सामान्य VPS अपलिंक की क्षमता के भीतर रहती है। यदि आप रिकॉर्डिंग नहीं कर रहे हैं, तो दो वर्चुअल CPU और 4 GB RAM इस आकार पर Jitsi या Galène को चला लेंगे। CPU ग्राफ के बजाय ट्रांसफर काउंटर पर नज़र रखें।

तीस लोगों के लिए, सबसे खराब स्थिति में 1,044 Mbps की निरंतर गति होती है, और बीस घंटे का उपयोग 9.4 TB होता है। यह वह स्तर है जहाँ आप सर्वर की कीमत तय करने से पहले बैंडविड्थ की कीमत तय करते हैं। last-N को चालू करें ताकि bridge केवल हाल के वक्ताओं का डेटा ही आगे भेजे, उपस्थित लोगों के लिए कैमरे को डिफ़ॉल्ट रूप से बंद रखें, और SFU को ऐसी जगह रखें जहाँ ट्रांसफर की सीमा इस गणना को सहन कर सके।

इससे ऊपर, एक VPS सही विकल्प नहीं है। या तो इवेंट वास्तव में एक प्रसारण है, जिस स्थिति में Owncast और एक CDN का उपयोग करना इसकी तुलना में बहुत सस्ता पड़ता है, या फिर आपको एक सिंगल सिग्नलिंग लेयर के पीछे एक से अधिक videobridge की आवश्यकता होगी, जो आपके द्वारा शुरू किए गए प्रोजेक्ट से एक अलग स्तर का काम है।

राउटिंग के बारे में एक अंतिम बात। अधिकांश टीमों को वीडियो की तुलना में दिन के अधिक घंटों के लिए चैट की आवश्यकता होती है, और चैट को होस्ट करना सस्ता है और इसे चालू रखना आसान है। रोज़मर्रा के ट्रैफिक के लिए एक self-hosted Slack विकल्प तैयार करना और कॉन्फ्रेंसिंग सर्वर को केवल निर्धारित कॉल के लिए रखना, वह व्यवस्था है जो छोटे VPS बजट के साथ भी काम करती है।

FAQ

लोग मेरी Jitsi meeting में शामिल तो हो सकते हैं, लेकिन एक-दूसरे को देख या सुन क्यों नहीं पाते?

Chat और participant list signalling channel के माध्यम से चलते हैं, जो 443 port पर TCP का उपयोग करता है, जबकि audio और video videobridge के लिए UDP 10000 का उपयोग करते हैं। यदि roster भर जाता है और हर tile काली रहती है, तो इसका मतलब है कि media path टूटा हुआ है जबकि signalling path ठीक है। दोनों firewalls में UDP 10000 की जाँच करें: एक जो server पर है और दूसरी आपके provider के control panel में मौजूद network firewall। फिर सुनिश्चित करें कि bridge को अपना public address पता है: यदि virtual machine का address private है और उसे public address पर map किया गया है, तो ice4j.harvest.mapping में एक static mapping जोड़ें, जो /etc/jitsi/videobridge/jvb.conf में स्थित है, और फिर jitsi-videobridge2 को restart करें। जब कोई meeting में शामिल हो रहा हो, तब sudo tcpdump -ni any udp port 10000 चलाने से आपको पता चल जाएगा कि समस्या कहाँ है, क्योंकि यदि कोई packet नहीं मिल रहा है, तो इसका मतलब है कि block operating system के upstream पर है।

30 लोगों की video call में कितनी bandwidth खर्च होती है?

सबसे खराब स्थिति में, जहाँ हर किसी का camera चालू हो और SFU हर किसी को full quality layer भेज रहा हो, server से लगभग 1,044 Mbps data बाहर जाता है, जो 469.8 GB प्रति घंटा है। यह N गुना (N घटा 1) streams का गणित है, जिसमें प्रत्येक 1.2 Mbps की है, न कि आपके setup का वास्तविक मापन। सामान्य उपयोग में Simulcast और last-N setting इसे काफी कम कर देते हैं, क्योंकि अधिकांश participants हर समय screen पर नहीं होते हैं। फिर भी, सबसे खराब स्थिति के अनुसार ही capacity रखें, क्योंकि वही वह समय होता है जब सभी लोग एक साथ अपना camera चालू कर देते हैं।

क्या मैं 1 GB VPS पर Jitsi Meet चला सकता हूँ?

यह install हो जाएगा और दो लोगों की call काम करेगी, आंशिक रूप से इसलिए क्योंकि Jitsi दो participants के लिए peer-to-peer mode का उपयोग करता है और videobridge को पूरी तरह छोड़ देता है। यह group call server के रूप में उपयोगी नहीं है। Prosody, videobridge और Java runtime सभी को memory की आवश्यकता होती है। handbook का सुझाव है कि एक गंभीर deployment के लिए 8 GB RAM होनी चाहिए, और memory से पहले bandwidth का गणित समस्या पैदा करेगा। यदि आपके पास केवल 1 GB का box है, तो Jitsi के बजाय Galène उस size के लिए बेहतर विकल्प है।

क्या मुझे अभी भी TURN server की आवश्यकता है यदि मेरे VPS का IP address public है?

हाँ। TURN जिस समस्या का समाधान करता है, वह call के दूसरे छोर पर होती है। corporate network पर मौजूद participant जो outbound UDP को block करता है, या carrier-grade NAT के पीछे बैठा व्यक्ति जिसे हर destination के लिए अलग source port मिलता है, वह direct media path नहीं बना सकता, चाहे आपके server का address कितना भी public क्यों न हो। 443 या 5349 port पर TCP के माध्यम से TURN उन्हें एक relay देता है जो उनके firewall को सामान्य web traffic जैसा दिखता है। Jitsi का package install डिफ़ॉल्ट रूप से इसके लिए coturn set up करता है, यही कारण है कि इसके documented firewall rules में UDP 3478 और TCP 5349 को open रखने के लिए कहा गया है।

BigBlueButton को Jitsi Meet की तुलना में इतनी अधिक hardware की आवश्यकता क्यों होती है?

क्योंकि यह केवल video forward करने से कहीं अधिक काम करता है। इसके प्रकाशित production requirement 16 GB RAM और 8 cores हैं, जबकि Jitsi के handbook में 8 GB और 4 cores का उल्लेख है। BigBlueButton एक ही machine पर पूर्ण audio conferencing stack, shared whiteboard और presentation layer, recording और post-processing pipeline, और user accounts के साथ web front end चलाता है। यह अपने platform को लेकर भी सख्त है: अगस्त 2026 तक, समर्थित install Ubuntu 22.04 पर version 3.0 है। ये दोनों आंकड़े प्रत्येक project के अपने documentation से लिए गए हैं और ये केवल शुरुआती बिंदु हैं, न कि आपके workload का सटीक मापन।