VPS-এ ভিডিও কনফারেন্সিং সার্ভার সেটআপ করার নিয়ম

VPS-এ self-hosted ভিডিও কনফারেন্সিং এবং ব্যান্ডউইথ সমস্যা

ছোট সার্ভারে self-hosted ভিডিও কনফারেন্সিং ব্যর্থ হওয়ার মূল কারণ একটিই, এবং এটি প্রায় কখনোই ইনস্টলেশনের সাথে সম্পর্কিত নয়। আধুনিক প্রতিটি টুল যে সার্ভার কম্পোনেন্ট ব্যবহার করে তা হলো SFU (selective forwarding unit)। এটি প্রতিটি অংশগ্রহণকারীর কাছ থেকে একটি ভিডিও স্ট্রিম গ্রহণ করে এবং অন্য সবার কাছে তার একটি কপি পাঠিয়ে দেয়, ফলে সার্ভার থেকে বেরিয়ে যাওয়া ট্রাফিক অংশগ্রহণকারীর সংখ্যার বর্গের অনুপাতে বাড়তে থাকে। 1 GB বা 2 GB RAM-এর একটি VPS শেয়ার্ড আপলিঙ্কে সফটওয়্যারটি ভালোভাবে চালাতে পারবে। কিন্তু এটি আপনার কল্পনার বড় কোনো মিটিং বা all-hands সেশন বহন করতে পারবে না।

তাই এই ক্রমে কাজ করুন। প্রথমে মানুষের সংখ্যা গণনা করুন, প্রয়োজনীয় মেগাবিট হিসাব করুন, তারপর সার্ভার নির্বাচন করুন। ইনস্টলেশনের কাজ মাত্র বিশ মিনিটের কপি-পেস্টের বিষয়। কিন্তু আপনার আপলিঙ্কই নির্ধারণ করবে যে অন্য কেউ আপনাকে শুনতে পাবে কি না।

অংশগ্রহণকারীর সংখ্যা বাড়লে ব্যান্ডউইথ কেন বর্গের হারে বৃদ্ধি পায়?

Mesh দিয়ে শুরু করা যাক। প্রতিটি ব্রাউজার তার ক্যামেরার ভিডিও এনকোড করে এবং সরাসরি অন্য প্রতিটি ব্রাউজারে একটি করে কপি পাঠায়; কোনো মিডিয়া সার্ভার এখানে ভিডিও প্রসেস করে না। দুইজনের Mesh কলের জন্য শুধুমাত্র একটি signalling server প্রয়োজন হয়, যে কারণে ওয়ান-টু-ওয়ান কল হোস্ট করা প্রায় বিনামূল্যে করা সম্ভব। চার বা পাঁচজনের বেশি অংশগ্রহণকারী হলে Mesh আর কাজ করে না, কারণ তখন একটি ল্যাপটপকে তার নিজের ভিডিওর চারটি বা পাঁচটি আলাদা কপি একই সময়ে আপলোড করতে হয়।

একটি SFU ভিন্নভাবে কাজ করে। প্রতিটি ব্রাউজার সার্ভারে একটি মাত্র কপি আপলোড করে। সার্ভার RTP (real-time transport protocol) হেডারগুলো পড়ে এবং ভিডিও ডিকোড না করেই সেই প্যাকেটগুলো অন্য অংশগ্রহণকারীদের কাছে পাঠিয়ে দেয়। এটিই মূল কৌশল, আর এই কারণেই SFU-এর CPU-এর ওপর চাপ কম থাকে কিন্তু নেটওয়ার্কের ওপর চাপ বেশি থাকে।

পুরানো ব্যবস্থাটি হলো MCU (multipoint control unit)। এটি প্রতিটি ইনকামিং স্ট্রিম ডিকোড করে, সেগুলোকে একটি ছবিতে একত্রিত করে এবং পুনরায় এনকোড করে। এতে আউটবাউন্ড ব্যান্ডউইথ খুব কম লাগে, কিন্তু CPU-এর খরচ বিশাল। বর্তমানে ভিডিওর জন্য প্রায় কিছুই MCU ব্যবহার করে না এবং এই গাইডের কোথাও এটি ব্যবহৃত হয়নি।

এখন SFU-এর গাণিতিক হিসাব দেখা যাক। ধরুন, প্রতিটি ব্যক্তি 1.2 Mbps গতিতে ভিডিও পাঠাচ্ছে এবং কারো ক্যামেরাই বন্ধ নেই। সার্ভার N গুণ 1.2 Mbps গ্রহণ করে, যা রৈখিক এবং ক্ষতিকর নয়। সার্ভার N গুণ (N বিয়োগ 1) গুণ 1.2 Mbps পাঠায়, কারণ N জন ব্যক্তির প্রত্যেককে অন্য (N বিয়োগ 1) সংখ্যক স্ট্রিম গ্রহণ করতে হয়। এই দ্বিতীয় সংখ্যাটিই প্রজেক্টের জন্য ঝুঁকিপূর্ণ।

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

এই সারিগুলো গাণিতিক হিসাব, কোনো নির্দিষ্ট সার্ভারের পরিমাপ নয়। মাসিক কলামটি মাসে বিশ ঘণ্টা কলের ওপর ভিত্তি করে তৈরি। সবার আগে শেষ সারিটি দেখুন। পঞ্চাশজন ক্যামেরা অন করে থাকলে একটি মেশিন থেকে 2,940 Mbps নিরবচ্ছিন্ন আউটবাউন্ড ট্রাফিক প্রয়োজন। ত্রিশজনের জন্য প্রয়োজন 1,044 Mbps। চারজনের জন্য প্রয়োজন 14.4 Mbps, যা যেকোনো VPS কোনো সমস্যা ছাড়াই সামলাতে পারে। চারজনের সারি এবং ত্রিশজনের সারির মধ্যে অংশগ্রহণকারীর সংখ্যা সাড়ে সাত গুণ বাড়লেও আউটবাউন্ড ট্রাফিক সত্তর গুণেরও বেশি বেড়ে যায়।

বাস্তব ডেপ্লয়মেন্টে এই সংখ্যার চেয়ে কম ট্রাফিক খরচ হয় এবং কেন তা জানা জরুরি। Jitsi এবং LiveKit উভয়ই simulcast ব্যবহার করে: একজন প্রেরক একই সাথে কয়েকটি কোয়ালিটি লেয়ার পাবলিশ করেন এবং SFU শুধুমাত্র তাদের কাছেই লো-কোয়ালিটি লেয়ার পাঠায় যারা স্ক্রিনে নেই। Jitsi-তে last-N সেটিংও রয়েছে যা শুধুমাত্র সাম্প্রতিক বক্তাদের ভিডিও ফরওয়ার্ড করে। উভয়ই প্রচুর ট্রাফিক সাশ্রয় করে। তবে এগুলো ট্রাফিকের বক্ররেখার ধরন পরিবর্তন করে না এবং যখনই সবাই ক্যামেরা অন করে একে অপরকে পিন করে, তখনই এই সুবিধাগুলো আর কার্যকর থাকে না।

একটি VPS uplink আসলে আপনাকে কী দেয়?

একটি প্ল্যান পেজে "1 Gbps port" লেখা থাকে। এটি ভার্চুয়াল নেটওয়ার্ক কার্ডের গতি, পরবর্তী হপ (next hop)-এর কোনো নিশ্চয়তা নয়। এই লিঙ্কটি একই ফিজিক্যাল হোস্টের অন্যান্য গ্রাহকদের সাথে শেয়ার করা থাকে, তাই ব্যস্ত সময়ে দীর্ঘস্থায়ী throughput পোর্ট গতির চেয়ে কম হয় এবং একটি কনফারেন্স কল ঠিক তেমনই একটি দীর্ঘস্থায়ী লোড। বেশিরভাগ প্ল্যানে মাসিক ট্রান্সফার লিমিট থাকে, যা অতিক্রম করলে আপনার গতি কমিয়ে দেওয়া হয় অথবা অতিরিক্ত বিল করা হয়।

এই লিমিট বা অ্যালাউন্স থেকেই ইনভয়েসে খরচের হিসাব আসে। এক মাসে ত্রিশ জনের কনফারেন্স কলের বিশ ঘণ্টা সার্ভার থেকে 9.4 TB ডেটা আউটপুট করে, যার হার প্রতি ঘণ্টায় 469.8 GB। পঞ্চাশ জনের কনফারেন্স কলের বিশ ঘণ্টা 26.5 TB ডেটা খরচ করে। RAM-এর হিসাব দেখার আগে ট্রান্সফার লিমিট পরীক্ষা করুন, এবং যদি প্ল্যান পেজে এ বিষয়ে অস্পষ্টতা থাকে, তবে সেই অস্পষ্টতাই আপনার উত্তর। একটি সস্তা VPS অফার সঠিকভাবে বোঝা এই ধরনের কাজের জন্য অন্য যেকোনো কিছুর চেয়ে বেশি গুরুত্বপূর্ণ।

Jitsi Meet: ডিফল্ট সমাধান এবং এর প্রয়োজনীয়তা

অধিকাংশ ব্যবহারকারীর জন্য Jitsi Meet দিয়ে শুরু করা সবচেয়ে ভালো। এটি প্রজেক্টের নিজস্ব Debian repository থেকে ইনস্টল হয়, ইনস্টলেশনের সময় এটি স্বয়ংক্রিয়ভাবে nginx এবং certificate কনফিগার করে। এর videobridge (JVB) একটি মাত্র UDP port ব্যবহার করে, ফলে firewall rule ছোট রাখা সম্ভব। এর জন্য 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

ইনস্টলারটি একটি hostname জানতে চাইবে এবং এরপর certificate-এর জন্য কিছু বিকল্প দেবে। Let's Encrypt অপশনটি বেছে নিন এবং এমন একটি domain name দিন যা ইতিমধ্যে এই সার্ভারের public address-এর দিকে নির্দেশ করছে। certificate-টি HTTP challenge-এর মাধ্যমে ইস্যু করা হয়, তাই অন্য কোথাও নির্দেশ করা কোনো domain name ব্যবহার করলে এই ধাপে কাজ ব্যর্থ হবে।

এরপর port-গুলো খুলে দিন। নিচে হ্যান্ডবুকে উল্লেখিত port-গুলো দেওয়া হলো, যেখানে 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 পোর্ট ওয়েব অ্যাপ পরিবেশন করে এবং certificate রিনিউ করতে সাহায্য করে। UDP 10000 পোর্টটি সমস্ত অডিও এবং ভিডিও ট্রাফিক বহন করে, যা সাধারণত মানুষ ভুলে যায়। UDP 3478 এবং TCP 5349 পোর্টগুলো coturn সার্ভারের জন্য, যা Jitsi প্যাকেজের সাথে bridge-এর পাশাপাশি ইনস্টল হয়। যাদের নেটওয়ার্কে UDP ব্লক করা থাকে, তাদের জন্য এটি বিকল্প পথ হিসেবে কাজ করে।

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

প্রথম কমান্ডটি সার্ভিসটি active কি না তা জানাবে। দ্বিতীয় কমান্ডটি দেখাবে যে bridge-টি UDP 10000 পোর্টে listen করছে কি না। যদি কোনো আউটপুট না আসে, তবে বুঝতে হবে bridge-টি চালু হয়নি এবং /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 টি dedicated core ব্যবহারের পরামর্শ দেয়। সাধারণত 1,000 Mbps নেটওয়ার্ক ব্যান্ডউইথই যথেষ্ট। এতে আরও উল্লেখ আছে যে ছোট সেটআপগুলো 4 GB বা 2 GB RAM-এও চলতে পারে। এই পৃষ্ঠার একটি গুরুত্বপূর্ণ তথ্য মনে রাখা প্রয়োজন: Prosody, যা signalling হ্যান্ডেল করা XMPP সার্ভার, সেটি কেবল একটি core ব্যবহার করতে পারে। অতিরিক্ত core bridge-এর জন্য সহায়ক হলেও signalling-এর ক্ষেত্রে কোনো প্রভাব ফেলে না।

সবাই কলে যোগ দিলেও কেন কারো ভিডিও দেখা যায় না?

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 কি (key) ব্যবহার করে একই কাজ করা হতো। সেগুলো এখনও কাজ করে, তবে নতুন ইনস্টলেশনের ক্ষেত্রে উপরের ম্যাপিং ব্লকটি ব্যবহার করা উচিত।

অন্য কারণটি হলো ফায়ারওয়াল, যা আপনি কনফিগার করেননি। বেশিরভাগ প্রোভাইডার কন্ট্রোল প্যানেলে একটি নেটওয়ার্ক ফায়ারওয়াল চালায় যা সার্ভারের 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 termination করা থাকে, তবে হয় 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-এর নথিপত্র প্রদান করে:

[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 পোর্টের একটি রেঞ্জ। সেই রেঞ্জটি নির্দিষ্ট (pin) করে দিন যাতে আপনি এর জন্য একটি ফায়ারওয়াল রুল লিখতে পারেন:

./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 upgrade হেডারসহ /ws লোকেশনটিকে প্রক্সি করে ওয়েব ইন্টারফেসের সামনে nginx বসাতে পারেন। জেনে রাখুন এটি কী কভার করে: ক্লায়েন্টরা এখনও সরাসরি UDP ফ্লো এবং TURN পোর্টে সরাসরি TCP কানেকশন খোলে, তাই রিভার্স প্রক্সি শুধুমাত্র পেজ এবং সিগন্যালিং হ্যান্ডেল করে। মিডিয়া কখনোই এর মধ্য দিয়ে যায় না।

Galène-এর ডকুমেন্টেশন অনুযায়ী এটি খুব সামান্য সার্ভার রিসোর্স ব্যবহার করে এবং কোনো নির্দিষ্ট সংখ্যা প্রকাশ করে না, তাই কোনো নির্দিষ্ট ফিগারের আশা করবেন না। উপরের ব্যান্ডউইথ হিসাব এখানেও পুরোপুরি প্রযোজ্য। আপনি যা সাশ্রয় করছেন তা হলো মেমোরি এবং SFU ছাড়া অন্য সবকিছুর চলমান অংশগুলো।

Owncast: এক থেকে অনেকের জন্য, যেখানে ব্যান্ডউইথ লিনিয়ার থাকে

অনেক "ভিডিও কনফারেন্সিং" প্রয়োজনের ক্ষেত্রে আসলে একজন ব্যক্তি দর্শকদের সামনে উপস্থাপন করেন এবং দর্শকরা চ্যাটে টাইপ করেন। যদি আপনার ক্ষেত্রেও এমনটি হয়, তবে SFU একটি ভুল টুল এবং এর অর্থনৈতিক দিকটি সম্পূর্ণ আলাদা। Owncast OBS বা অনুরূপ কোনো এনকোডার থেকে একটি RTMP স্ট্রিম গ্রহণ করে এবং সাধারণ HTTPS-এর মাধ্যমে HLS পরিবেশন করে। প্রতি দর্শকের জন্য ব্যান্ডউইথ কোয়াড্রাটিক (quadratic) হওয়ার পরিবর্তে লিনিয়ার থাকে এবং আউটপুট সাধারণ HTTP সেগমেন্ট হওয়ায় আপনি এটিকে অবজেক্ট স্টোরেজ বা CDN-এর পেছনে সরিয়ে নিতে পারেন, ফলে অরিজিন সার্ভারে আর খরচ করতে হয় না।

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

প্রজেক্টের ডকুমেন্টেশনে বলা হয়েছে এটিকে root হিসেবে না চালাতে এবং যেকোনো রিমোট স্ক্রিপ্ট চালানোর আগে তা পরীক্ষা করে নিতে, যে কারণে ডাউনলোড প্রক্রিয়াটি উপরে আলাদা ধাপে রাখা হয়েছে। ইনস্টলারটি বর্তমান রিলিজ এবং একটি ffmpeg বাইনারি সংগ্রহ করে, যদি আপনার কাছে আগে থেকে না থাকে। ইনস্টল ডিরেক্টরি থেকে ./owncast চালান এবং পোর্ট 8080-এ /admin ঠিকানায় অ্যাডমিন প্যানেলটি খুলুন। ডিফল্ট লগইন ইউজার হলো admin এবং ডিফল্ট স্ট্রিম কি abc123 হলো পাসওয়ার্ড। সার্ভারে ডোমেইন পয়েন্ট করার আগেই এটি পরিবর্তন করে নিন।

HLS ডিজাইনের কারণে দুটি ফলাফল পাওয়া যায়। দর্শকরা লাইভ থেকে কয়েক সেকেন্ড বা মিনিট পিছিয়ে থাকেন, কারণ HLS পুরো সেগমেন্ট পাঠায়, তাই এখানে কোনো দ্বিমুখী কথোপকথন সম্ভব নয়। এছাড়া এই পথে কোনো UDP বা TURN নেই, তাই এটি এমন সব নেটওয়ার্কেও পৌঁছাতে পারে যেখানে WebRTC কল কোনোভাবেই কানেক্ট হতে পারে না।

Owncast হলো এই তালিকার একমাত্র টুল যা ইচ্ছাকৃতভাবে ট্রান্সকোড করে। আপনি যে কয়টি আউটপুট কোয়ালিটি চালু করবেন, প্রতিটি ইনকামিং স্ট্রিমের জন্য আলাদাভাবে ffmpeg এনকোড চলবে এবং ব্রডকাস্ট চলাকালীন তা অব্যাহত থাকবে। ছোট VPS-এর ক্ষেত্রে, এক বা দুটি কোয়ালিটি অফার করুন। পাঁচটি কোয়ালিটি চালু করলে নেটওয়ার্ক অলস বসে থাকলেও CPU-এর ওপর অতিরিক্ত চাপ পড়বে।

আপনার চলমান 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 টার্মিনেট করে
• TCP 7881: ICE over TCP-এর জন্য, যা তখন ব্যবহৃত হয় যখন কোনো ক্লায়েন্ট UDP-এর মাধ্যমে সংযোগ করতে পারে না
• UDP 50000 থেকে 60000: মিডিয়ার জন্য, যেখানে একটি রুমের প্রতিটি অংশগ্রহণকারী দুটি করে পোর্ট ব্যবহার করে
• UDP 3478 এবং TCP 5349: যদি আপনি এমবেডেড TURN সার্ভার চালু করেন; তবে 5349 পোর্টটিকে 443 পোর্টে স্থানান্তর করতে হবে, যদি না এর সামনে কোনো load balancer থাকে

প্রতি অংশগ্রহণকারীর জন্য দুটি পোর্ট শোনার বিষয়টি উদ্বেগজনক মনে হতে পারে, কিন্তু আসলে তা নয়। 10,000 পোর্টের একটি রেঞ্জ হাজার হাজার অংশগ্রহণকারীর জন্য যথেষ্ট এবং আপনার আপলিংক ব্যান্ডউইথ এই রেঞ্জ শেষ হওয়ার অনেক আগেই ফুরিয়ে যাবে। তবুও পুরো রেঞ্জটি ওপেন রাখুন, কারণ আংশিক ওপেন রেঞ্জ কিছু ব্যবহারকারীর জন্য কাজ করবে এবং অন্যদের জন্য করবে না, যা ডিবাগ করার জন্য সবচেয়ে জটিল ধরনের সমস্যা। এই প্রক্রিয়ার homeserver অংশটি একটি আলাদা কাজ, যা running a Synapse homeserver on a VPS-এ বিস্তারিত আলোচনা করা হয়েছে।

কেন একজন ব্যক্তি কখনোই সংযোগ করতে পারেন না? 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 খরচ বাড়ায়, uplink-এর ওপর চাপ ফেলে না, এবং TLS লিসেনার মিডিয়াতে আগে থেকেই থাকা DTLS-এর ওপর প্রতিটি প্যাকেট দ্বিতীয়বার এনক্রিপ্ট করে। যখন আপনি TURN-কে নিজস্ব মেশিনে সরিয়ে নেন, তখন সেই মেশিনের নিজস্ব ব্যান্ডউইথ প্ল্যান প্রয়োজন যা SFU-এর মতোই হতে হবে। এবং TCP-এর মাধ্যমে TURN রিয়েল-টাইম মিডিয়াকে একটি নির্ভরযোগ্য স্ট্রিমে পরিণত করে, তাই একটি হারিয়ে যাওয়া প্যাকেট এড়িয়ে যাওয়ার পরিবর্তে পুনরায় পাঠানো হয়, এবং একটি লসি লিঙ্কে থাকা রিলে করা অংশগ্রহণকারী সংক্ষিপ্ত গ্লিচের পরিবর্তে বিলম্বের সম্মুখীন হয়। রিলে হলো একটি ফলব্যাক যা সংযোগ স্থাপন করে, তবে এমন গুণমানে যা সরাসরি পথ হলে আরও ভালো হতো।

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 RAM-এর একটি VPS একজন থেকে অন্যজনের কলের জন্য চমৎকার, কিন্তু চারজনের কলের জন্য এটি দুর্বল। এই কারণেই "আমি যখন পরীক্ষা করেছিলাম তখন এটি কাজ করছিল" এমন মন্তব্য খুব সাধারণ।

ক্যামেরা চালু থাকা অবস্থায় দশজন পর্যন্ত অংশগ্রহণকারীর জন্য, আটজন অংশগ্রহণকারীর ক্ষেত্রে 67.2 Mbps ব্যান্ডউইথ একটি সাধারণ VPS-এর আপলিংক দিয়ে অনায়াসেই চালানো সম্ভব। আপনি যদি রেকর্ড না করেন, তবে এই আকারের কনফারেন্সের জন্য দুটি virtual CPU এবং 4 GB RAM-এর সার্ভারে Jitsi বা Galène অনায়াসে চলবে। CPU গ্রাফের চেয়ে বরং transfer counter-এর দিকে নজর রাখুন।

ত্রিশজন অংশগ্রহণকারীর ক্ষেত্রে, সবচেয়ে খারাপ পরিস্থিতিতে 1,044 Mbps ব্যান্ডউইথ প্রয়োজন হতে পারে এবং বিশ ঘণ্টা চললে এটি 9.4 TB ডেটা খরচ করবে। এই পর্যায়ে সার্ভারের দামের চেয়ে ব্যান্ডউইথের দাম আগে হিসাব করা উচিত। last-N ফিচারটি চালু করুন যাতে bridge শুধুমাত্র সাম্প্রতিক বক্তাদের ভিডিও পাঠায়, অংশগ্রহণকারীদের জন্য ডিফল্টভাবে ক্যামেরা বন্ধ রাখুন, এবং SFU-টিকে এমন জায়গায় হোস্ট করুন যেখানে আপনার হিসাব অনুযায়ী পর্যাপ্ত transfer allowance আছে।

এর চেয়ে বেশি ব্যবহারকারীর জন্য একটি VPS সঠিক সমাধান নয়। যদি ইভেন্টটি মূলত ব্রডকাস্টিং হয়, তবে Owncast এবং একটি CDN ব্যবহার করা অনেক সাশ্রয়ী। অথবা, একটি signalling layer-এর পেছনে একাধিক videobridge ব্যবহার করতে হবে, যা আপনার বর্তমান প্রজেক্টের চেয়ে ভিন্ন একটি কাজ।

রাউটিংয়ের বিষয়ে শেষ একটি পরামর্শ। বেশিরভাগ টিমের সারাদিনের কাজের জন্য ভিডিওর চেয়ে চ্যাটের প্রয়োজন অনেক বেশি হয়। চ্যাট সার্ভার হোস্ট করা সস্তা এবং এটি সচল রাখা সহজ। প্রতিদিনের যোগাযোগের জন্য একটি self-hosted Slack বিকল্প তৈরি করুন এবং শুধুমাত্র নির্ধারিত কলের জন্য কনফারেন্সিং সার্ভার ব্যবহার করুন। এই পদ্ধতিটি একটি ছোট VPS বাজেটের মধ্যেও কার্যকর থাকে।

FAQ

কেন মানুষ আমার Jitsi মিটিংয়ে যোগ দিতে পারে কিন্তু একে অপরকে দেখতে বা শুনতে পায় না?

চ্যাট এবং অংশগ্রহণকারীদের তালিকা signalling channel-এর মাধ্যমে আদান-প্রদান হয়, যা TCP 443 পোর্টে চলে, অন্যদিকে অডিও এবং ভিডিও videobridge-এর জন্য UDP 10000 পোর্ট ব্যবহার করে। যদি অংশগ্রহণকারীদের তালিকা দেখা যায় কিন্তু ভিডিওর ঘরগুলো কালো হয়ে থাকে, তবে বুঝতে হবে signalling path ঠিক আছে কিন্তু media path-এ সমস্যা আছে। আপনার সার্ভারের firewall এবং আপনার প্রোভাইডারের কন্ট্রোল প্যানেলের নেটওয়ার্ক firewall—উভয় জায়গাতেই UDP 10000 পোর্ট খোলা আছে কি না তা পরীক্ষা করুন। এরপর নিশ্চিত করুন যে bridge তার public address চিনতে পারছে কি না: যদি ভার্চুয়াল মেশিনের private address-এর সাথে public address ম্যাপ করা থাকে, তবে /etc/jitsi/videobridge/jvb.conf ফাইলে ice4j.harvest.mapping-এর অধীনে একটি static mapping যোগ করুন এবং jitsi-videobridge2 রিস্টার্ট করুন। কেউ মিটিংয়ে যোগ দেওয়ার সময় sudo tcpdump -ni any udp port 10000 কমান্ডটি চালালে আপনি বুঝতে পারবেন সমস্যাটি কোথায়, কারণ কোনো প্যাকেট না আসা মানে হলো অপারেটিং সিস্টেমের আগেই কোথাও ব্লক করা হয়েছে।

30 জনের ভিডিও কলে কতটুকু ব্যান্ডউইথ খরচ হয়?

সবচেয়ে খারাপ পরিস্থিতিতে, যেখানে সবার ক্যামেরা অন থাকে এবং SFU সবাইকে পূর্ণ মানের ভিডিও পাঠায়, সার্ভার থেকে প্রায় 1,044 Mbps ব্যান্ডউইথ বের হয়, যা প্রতি ঘণ্টায় 469.8 GB। এটি N গুণ (N বিয়োগ 1) স্ট্রিমের গাণিতিক হিসাব, যেখানে প্রতিটি স্ট্রিম 1.2 Mbps, এটি আপনার সেটআপের প্রকৃত পরিমাপ নয়। Simulcast এবং last-N সেটিং ব্যবহারের ফলে সাধারণ ব্যবহারে ব্যান্ডউইথ অনেক কমে যায়, কারণ বেশিরভাগ সময় সব অংশগ্রহণকারী স্ক্রিনে থাকে না। তবুও worst-case বা সবথেকে বেশি ব্যবহারের কথা মাথায় রেখেই সার্ভারের সক্ষমতা নির্ধারণ করুন, কারণ সবাই একসাথে ক্যামেরা অন করলে এই পরিস্থিতি তৈরি হতে পারে।

আমি কি 1 GB RAM-এর VPS-এ Jitsi Meet চালাতে পারি?

এটি ইনস্টল হবে এবং দুইজন অংশগ্রহণকারীর কল কাজ করবে, কারণ Jitsi দুইজন অংশগ্রহণকারীর ক্ষেত্রে peer to peer মোড ব্যবহার করে এবং videobridge-কে পুরোপুরি এড়িয়ে যায়। তবে এটি গ্রুপ কলের জন্য কার্যকর সার্ভার নয়। Prosody, videobridge এবং Java runtime—সবগুলোর জন্যই মেমোরি প্রয়োজন। হ্যান্ডবুক অনুযায়ী একটি সিরিয়াস ডেপ্লয়মেন্টের জন্য 8 GB RAM প্রয়োজন, এবং মেমোরির আগেই ব্যান্ডউইথের সীমাবদ্ধতা দেখা দেবে। যদি আপনার কাছে 1 GB-এর সার্ভার থাকে, তবে Jitsi-এর চেয়ে Galène ব্যবহার করা বেশি যুক্তিযুক্ত।

আমার VPS-এর public IP address থাকলে কি আমার এখনো TURN সার্ভারের প্রয়োজন আছে?

হ্যাঁ। TURN যে সমস্যার সমাধান করে তা কলের অপর প্রান্তে থাকে। কোনো কর্পোরেট নেটওয়ার্কের অংশগ্রহণকারী যদি outbound UDP ব্লক করে রাখে, অথবা carrier-grade NAT-এর পেছনে থাকে যা গন্তব্য অনুযায়ী ভিন্ন source port বরাদ্দ করে, তবে আপনার সার্ভারের address যতই public হোক না কেন, তারা সরাসরি media path তৈরি করতে পারবে না। TCP 443 বা 5349 পোর্টে TURN ব্যবহার করলে তারা একটি relay পায়, যা তাদের firewall-এর কাছে সাধারণ ওয়েব ট্র্যাফিকের মতো মনে হয়। Jitsi-এর প্যাকেজ ইনস্টলেশন ডিফল্টভাবে coturn সেটআপ করে দেয়, যে কারণে এর ফায়ারওয়াল নির্দেশিকায় UDP 3478 এবং TCP 5349 পোর্ট খোলার কথা বলা হয়েছে।

BigBlueButton-এর কেন Jitsi Meet-এর চেয়ে অনেক বেশি হার্ডওয়্যার প্রয়োজন?

কারণ এটি শুধু ভিডিও ফরওয়ার্ড করার চেয়ে অনেক বেশি কাজ করে। এর প্রকাশিত প্রোডাকশন রিকোয়ারমেন্ট হলো 16 GB RAM এবং 8 টি CPU কোর, যেখানে Jitsi-এর হ্যান্ডবুকে 8 GB RAM এবং 4 টি CPU কোরের কথা বলা হয়েছে। BigBlueButton একই মেশিনে একটি পূর্ণাঙ্গ অডিও কনফারেন্সিং স্ট্যাক, শেয়ারড হোয়াইটবোর্ড এবং প্রেজেন্টেশন লেয়ার, রেকর্ডিং ও পোস্ট-প্রসেসিং পাইপলাইন এবং ইউজার অ্যাকাউন্টসহ একটি ওয়েব ফ্রন্ট-এন্ড চালায়। এটি তার প্ল্যাটফর্মের ব্যাপারেও নির্দিষ্ট: আগস্ট 2026 অনুযায়ী, সমর্থিত ইনস্টলেশন হলো Ubuntu 22.04-এ ভার্সন 3.0। এই পরিসংখ্যানগুলো প্রতিটি প্রজেক্টের নিজস্ব ডকুমেন্টেশন থেকে নেওয়া এবং এগুলো আপনার কাজের চাপের প্রকৃত পরিমাপের পরিবর্তে একটি প্রাথমিক ধারণা মাত্র।