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 RAM वाला VPS shared uplink पर software को तो ठीक से चला लेगा, लेकिन यह उस बड़े meeting को नहीं संभाल पाएगा जिसकी आप कल्पना कर रहे हैं।

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

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

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

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

पुरानी व्यवस्था MCU (multipoint control unit) कहलाती है। यह प्रत्येक incoming stream को decode करता है, उन्हें एक ही picture में composite करता है और फिर उस 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 का मापन। 'Monthly' 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) पोर्ट की गति से कम होता है, और एक कॉन्फ्रेंस कॉल वास्तव में एक निरंतर लोड है। अधिकांश प्लान में मासिक ट्रांसफर भत्ता भी होता है, जिसके बाद आपकी गति कम (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 उन पतों का विज्ञापन (advertise) करता है जो उसे अपने इंटरफेस पर मिलते हैं। ऐसे प्रदाता (provider) पर जो वर्चुअल मशीन को एक private address देता है और उस पर एक public address मैप करता है, JVB को केवल private address ही मिलता है। इसलिए, प्रत्येक क्लाइंट मीडिया को 10.0.0.5 जैसे पते पर भेजने का प्रयास करता है और पैकेट कहीं नहीं पहुँच पाते।

ब्रिज को दोनों पतों के बारे में जानकारी दें। /etc/jitsi/videobridge/jvb.conf में एक static mapping जोड़ें:

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 से local address लें और अपने प्रदाता के कंट्रोल पैनल से public address लें। पुराने गाइड /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 चलाएं। यदि कोई पैकेट नहीं दिखता है, तो इसका मतलब है कि मशीन तक कुछ भी नहीं पहुँच रहा है, इसलिए ब्लॉक ऑपरेटिंग सिस्टम के अपस्ट्रीम (upstream) पर है। यदि पैकेट आ रहे हैं लेकिन टाइलें काली हैं, तो इसका मतलब है कि ब्रिज ऐसे पते के साथ उत्तर दे रहा है जिसे क्लाइंट एक्सेस नहीं कर सकता, इसलिए यह मैपिंग की समस्या है। यदि आप ufw के बारे में सुनिश्चित नहीं हैं, तो the ufw rules a VPS actually needs उस नियम क्रम (rule ordering) को कवर करता है जो अक्सर लोगों के लिए समस्या पैदा करता है।

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

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

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

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 है। यह एक सिंगल स्टैटिक बाइनरी के रूप में बिल्ड होता है, इसमें अपना वेब क्लाइंट शामिल है, और इसमें एक TURN सर्वर भी है। इसलिए, इसमें न तो किसी XMPP सर्वर की आवश्यकता है, न Java रनटाइम की, और न ही किसी Rails एप्लिकेशन को चालू रखने की। यदि आपकी आवश्यकता एक साधारण सर्वर पर दस लोगों की विश्वसनीय कॉल की है, तो अधिक हार्डवेयर की आवश्यकता का निष्कर्ष निकालने से पहले इसे आजमाएं।

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 यह शिकायत करता है कि मॉड्यूल को नए Go की आवश्यकता है, तो डिस्ट्रीब्यूशन पैकेज से जूझने के बजाय go.dev से एक वर्तमान टूलचेन इंस्टॉल करें।

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

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

https://your.server:8443/group/night-watch/ खोलें और vimes के रूप में लॉग इन करें। ये क्रेडेंशियल्स सीधे प्रोजेक्ट के README से आते हैं, इसलिए पोर्ट के कहीं और से एक्सेस होने से पहले इन्हें बदल दें। वास्तविक डिप्लॉयमेंट के लिए, प्रोजेक्ट एक systemd यूनिट का दस्तावेजीकरण करता है:

[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

वेब इंटरफेस के लिए TCP 8443, इन-बिल्ट TURN सर्वर के लिए TCP और UDP 1194, और मीडिया के लिए उच्च UDP पोर्ट्स की एक रेंज का उपयोग होता है। उस रेंज को पिन करें ताकि आप इसके लिए एक फायरवॉल नियम लिख सकें:

./galene -udp-range 40000-40100

VPS पर -turn विकल्प सबसे महत्वपूर्ण है। -turn ':1194' सभी पब्लिक IPv4 एड्रेस पर लिसन करता है। -turn '203.0.113.1:1194' Galène को वह एड्रेस बताता है जिसे क्लाइंट वास्तव में देखेंगे, जिसकी आवश्यकता तब होती है जब मशीन का अपना एड्रेस प्राइवेट हो। -turn '' इन-बिल्ट सर्वर को डिसेबल करता है ताकि आप data/ice-servers.json के माध्यम से किसी बाहरी सर्वर की ओर पॉइंट कर सकें। डिफ़ॉल्ट auto है, जो ice-servers.json न होने पर :1194 की तरह व्यवहार करता है।

आप data/config.json में proxyURL सेट करके और WebSocket अपग्रेड हेडर के साथ /ws लोकेशन को प्रॉक्सी करके nginx को वेब इंटरफेस के सामने रख सकते हैं। ध्यान रखें कि यह क्या कवर करता है: क्लाइंट अभी भी सीधे UDP फ्लो और TURN पोर्ट के लिए सीधे TCP कनेक्शन खोलते हैं, इसलिए रिवर्स प्रॉक्सी केवल पेज और सिग्नलिंग को संभालता है। मीडिया कभी भी इसके माध्यम से नहीं गुजरता है।

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

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

कई "video conferencing" आवश्यकताओं में वास्तव में एक व्यक्ति दर्शकों के सामने प्रस्तुत कर रहा होता है जो chat में टाइप करते हैं। यदि आपकी आवश्यकता यही है, तो SFU गलत टूल है और economics पूरी तरह बदल जाती है। Owncast, OBS या समान encoder से RTMP stream लेता है और सामान्य HTTPS पर HLS serve करता है। प्रति viewer bandwidth quadratic के बजाय linear होती है, और चूंकि output plain 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 वर्तमान release और यदि आपके पास पहले से नहीं है तो एक ffmpeg binary fetch करता है। Install directory से ./owncast चलाएं और /admin पर port 8080 पर admin panel खोलें। Default login user admin है और default stream key abc123 password के रूप में है। सर्वर पर domain point करने से पहले इसे बदलें।

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

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

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

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

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

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

प्रति प्रतिभागी दो पोर्ट्स सुनने में चिंताजनक लग सकते हैं, लेकिन ऐसा नहीं है। 10,000 पोर्ट्स की रेंज हजारों प्रतिभागियों के लिए पर्याप्त है, और आपकी uplink क्षमता उस रेंज के खत्म होने से बहुत पहले ही समाप्त हो जाएगी। पूरी रेंज को ओपन रखें, क्योंकि आंशिक रूप से खुली रेंज कुछ लोगों के लिए काम करती है और दूसरों के लिए विफल हो जाती है, जो कि डीबग करने के लिए सबसे कठिन प्रकार की समस्या है। इसका 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 पूरी तरह से ब्लॉक होता है। दूसरा एक carrier-grade 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

ये सेटिंग्स /etc/turnserver.conf में जाती हैं। Debian और Ubuntu पर पैकेज इंस्टॉल होते ही coturn को उस फाइल के स्टॉक वर्ज़न पर शुरू कर देता है, इसलिए ऊपर दिया गया enable --now इसे पहले से चल रहा पाता है और कुछ भी नहीं बदलता है। आपकी सेटिंग्स तब प्रभावी होती हैं जब आप sudo systemctl restart coturn चलाते हैं, और फाइल में बाद के हर बदलाव के लिए समान रीस्टार्ट की आवश्यकता होती है। पुराने गाइड आपको /etc/default/coturn में TURNSERVER_ENABLED=1 सेट करने के लिए भी कहते हैं। केवल पुरानी init स्क्रिप्ट ही उस स्विच को पढ़ती है। वर्तमान पैकेज जिस systemd यूनिट को चलाते हैं, वह इसे नहीं पढ़ती, इसलिए वह लाइन कुछ भी नहीं बदलती है, और एक coturn जिसे आपने कभी रीस्टार्ट नहीं किया, वह अभी भी स्टॉक फाइल का ही उपयोग कर रहा है।

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

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

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

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

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

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

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

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

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

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

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

FAQ

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

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

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

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

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

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

BigBlueButton को Jitsi Meet की तुलना में इतना अधिक hardware क्यों चाहिए?

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