Self-hosted VoIP server: Asterisk ও FreePBX সেটআপ

একটি self-hosted VoIP server কী

একটি self-hosted VoIP server হলো আপনার নিয়ন্ত্রণাধীন VPS-এ চলা একটি SIP server। তাই hosted phone service-এর বদলে আপনার নিজের machine call routing করে। VoIP (voice over IP) কথোপকথনকে UDP packet হিসেবে পাঠায়। SIP (session initiation protocol) হলো যে signalling call শুরু ও শেষ করে। Audio SIP-এর মাধ্যমে যায় না। নিচের বেশিরভাগ সমস্যার মূল কারণ এই একটি বিষয়।

একটি কার্যকর system-এর জন্য 4টি অংশ দরকার।

• PBX (private branch exchange) software। Asterisk সাধারণত ব্যবহার করা হয়। এতে extension এবং dialplan সংরক্ষিত থাকে।
• Endpoint। Desk phone বা softphone username এবং secret দিয়ে PBX-এ register করে।
• SIP trunk। এটি provider-এর একটি paid account। এর মাধ্যমে public telephone network-এ সংযোগ করা যায় এবং আসল phone number ভাড়া নেওয়া যায়।
• Media path। RTP (real-time transport protocol) flow নিজস্ব UDP port ব্যবহার করে audio বহন করে।

PBX self-hosted করার অর্থ phone number self-hosted করা নয়। Number carrier-এর কাছ থেকে আসে, এবং প্রতিটি number ও minute-এর জন্য আপনাকে অর্থ দিতে হয়। আপনার নিয়ন্ত্রণে থাকে call routing, voicemail, recording এবং extension list। অর্থের জন্য আক্রমণকারীরা এমন service-এ হামলা করে। সেই service-এর security-র দায়িত্বও আপনার।

একটি self-hosted VoIP server-এর কোন port প্রয়োজন?

SIP signalling-এর জন্য UDP ও TCP-তে port 5060 এবং SIP over TLS (transport layer security)-এর জন্য port 5061 ব্যবহৃত হয়। এই port-গুলো শুধু call setup-এর জন্য ব্যবহৃত হয়। প্রতিটি call-এর audio একটি পৃথক UDP flow হিসেবে RTP range থেকে নেওয়া একটি port-এ পাঠানো হয়। Asterisk একটি sample rtp.conf সরবরাহ করে, যেখানে rtpstart=10000 এবং rtpend=20000 নির্ধারণ করা আছে। Compiled-in default হলো 5000 এবং 31000। প্রতিটি call এই range থেকে দুটি port ব্যবহার করে: একটি RTP-এর জন্য এবং একটি RTCP (RTP control protocol)-এর জন্য।

প্রথমবারের অধিকাংশ configuration এখানেই ব্যর্থ হয়। Call connect হয়, উভয় phone-এ call-টি answered দেখায়, কিন্তু কোনো পক্ষই audio শুনতে পায় না, কারণ firewall 5060 অনুমোদন করে এবং সব RTP packet বাদ দেয়। Signalling ও media পৃথক flow, তাই তাদের জন্য পৃথক firewall rule প্রয়োজন। এই পার্থক্যটি নতুন হলে, কোনো port খোলার আগে Linux-এ port ও listening socket কীভাবে কাজ করে পড়ে নেওয়া উপকারী।

Port খোলার আগে range ছোট করুন। একটি ছোট system-এর জন্য বিশ হাজার port প্রয়োজনের তুলনায় অনেক বেশি। প্রতিটি call-এ দুটি port লাগে, তাই দুইশো port-এর range একসঙ্গে একশোটি call পরিচালনা করতে পারে।

[general]
rtpstart=10000
rtpend=10200

sudo asterisk -rx "core reload" দিয়ে এটি প্রয়োগ করুন।

Asterisk নাকি FreePBX ইনস্টল করবেন?

Asterisk হলো মূল engine। আপনি /etc/asterisk-এর text file দিয়ে এটি configure করেন এবং নিজেই dialplan লেখেন। FreePBX হলো PHP ও JavaScript-এ লেখা একটি web interface, যা Asterisk-এর ওপর চলে, আপনার জন্য ওই file তৈরি করে এবং voicemail ও call queue-এর জন্য module যোগ করে।

VPS-এ গুরুত্বপূর্ণ পার্থক্যটি হলো machineটির নিয়ন্ত্রণ কার হাতে। August 2026 অনুযায়ী, official FreePBX 17 installer একটি vanilla Debian 12 system প্রত্যাশা করে। এটি Asterisk, একটি web server, একটি database server এবং PHP ইনস্টল করে। যে machine-এ আগে থেকেই অন্য service চলছে, সেখানে এটি চালালে ফল ভালো হবে না। FreePBX-এর জন্য আলাদা VPS ব্যবহার করুন।

wget https://github.com/FreePBX/sng_freepbx_debian_install/raw/master/sng_freepbx_debian_install.sh -O /tmp/sng_freepbx_debian_install.sh
sudo bash /tmp/sng_freepbx_debian_install.sh

Install log /var/log/pbx/freepbx17-install.log-এ সংরক্ষিত হয়। Script শুরুতেই থেমে গেলে প্রথমে এখানেই দেখুন।

FreePBX নিজে তৈরি করা configuration file-এর নিয়ন্ত্রণ রাখে। FreePBX box-এ pjsip.conf হাতে edit করলে GUI পরবর্তীবার ওই file লিখলে আপনার পরিবর্তন হারিয়ে যাবে। হাতে লেখা configuration-এর জন্য FreePBX নামের মধ্যে _custom থাকা আলাদা file পড়ে এবং সেগুলো পরিবর্তন করে না।

বাস্তব trade-off হলো এই। FreePBX আপনাকে একটি GUI দেয় এবং আপনার phone system-এর login page public internet-এ প্রকাশ করে। Raw Asterisk-এ কোনো web surface নেই। প্রতিটি setting একটি documented directive হিসেবে file-এ পড়া যায় এবং git-এ রাখা যায়। FreePBX ইনস্টল করলে এর web port শুধু আপনার নিজের address-এ সীমাবদ্ধ করুন অথবা VPN-এর মাধ্যমে ব্যবহার করুন। কারণ PBX-এর admin GUI এমন একটি target, যেখান থেকে অর্থের দিকে সরাসরি পৌঁছানো সম্ভব।

Version note, August 2026 অনুযায়ী সঠিক: Asterisk 22 হলো বর্তমান long term support release। এটি October 2024-এ প্রকাশিত হয়েছে এবং October 2028 পর্যন্ত security fix পাবে। Asterisk 23 হলো standard release। Ubuntu 24.04-এর universe repository-তে Asterisk 20.6.0 রয়েছে।

Ubuntu 24.04-এ Asterisk ইনস্টল করুন

ডিস্ট্রিবিউশন প্যাকেজ ব্যবহার করাই দ্রুততম পদ্ধতি। Ubuntu এতে প্যাচ প্রয়োগ করে এবং এটি নিজে থেকেই systemd-এর অধীনে চালু হয়।

sudo apt update
sudo apt install -y asterisk
sudo asterisk -rx "core show version"

সোর্স থেকে build করলে এর পরিবর্তে সর্বশেষ long term support release পাওয়া যায়।

sudo apt update
sudo apt install -y build-essential wget
cd /usr/local/src
sudo wget https://downloads.asterisk.org/pub/telephony/asterisk/asterisk-22-current.tar.gz
sudo tar -xzf asterisk-22-current.tar.gz
cd asterisk-22.*
sudo contrib/scripts/install_prereq install
sudo ./configure
sudo make menuselect
sudo make -j"$(nproc)"
sudo make install
sudo make samples
sudo make config
sudo ldconfig

install_prereq install আপনার distribution-এর build dependency ইনস্টল করে, আর install_prereq test কোনো পরিবর্তন না করে যে command-গুলো চালাত, সেগুলো দেখায়। make menuselect module picker খোলে। এখানে Codec Translators-এর অধীনে codec_opus সক্রিয় করুন। শুধুমাত্র নতুন installation-এ make samples চালান, কারণ এটি sample configuration /etc/asterisk-এ লেখে। make config init script /etc/init.d/asterisk-এ ইনস্টল করে। systemd তার SysV compatibility layer-এর মাধ্যমে এটি চালায়। তাই এরপর sudo systemctl enable --now asterisk কাজ করে।

আপনি যে পদ্ধতিই ব্যবহার করুন, sudo asterisk -rvvv চলমান daemon-এর সঙ্গে সংযুক্ত হয়ে CLI দেয়। সেখানে core show version চালালে আপনি আসলে কোন version ইনস্টল করেছেন তা দেখা যায়।

SIP trunk এবং একটি extension কনফিগার করুন

বর্তমান Asterisk-এ PJSIP হলো SIP channel driver। এর configuration থাকে /etc/asterisk/pjsip.conf-এ এবং এটি একে অপরকে name দিয়ে reference করা ছোট typed section দিয়ে তৈরি। ভিন্ন type-এর section একই name ব্যবহার করতে পারে। তাই নিচের প্রতিটি block-এর নাম mytrunk।

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0

[mytrunk]
type=registration
outbound_auth=mytrunk
server_uri=sip:sip.example.com
client_uri=sip:1234567890@sip.example.com
retry_interval=60

[mytrunk]
type=auth
auth_type=userpass
username=1234567890
password=REPLACE_WITH_A_LONG_RANDOM_SECRET

[mytrunk]
type=aor
contact=sip:sip.example.com:5060

[mytrunk]
type=endpoint
context=from-trunk
disallow=all
allow=ulaw
outbound_auth=mytrunk
aors=mytrunk

[mytrunk]
type=identify
endpoint=mytrunk
match=sip.example.com

registration object আপনার provider-এর কাছে REGISTER পাঠায়। এর মাধ্যমে provider জানতে পারে আপনার call কোথায় পাঠাতে হবে। Provider থেকে আসা call-কে source address দিয়ে এই endpoint-এর সঙ্গে match করতে identify object ব্যবহৃত হয়। Provider সাধারণত তালিকায় দেওয়ার জন্য একাধিক address প্রকাশ করে। Outbound registration এবং endpoint ইচ্ছাকৃতভাবে আলাদা object: একটি provider-কে জানায় আপনি কোথায় আছেন, অন্যটি নির্ধারণ করে আসা call-এর সঙ্গে কী করা হবে।

একটি desk phone-এর জন্য আরও তিনটি object প্রয়োজন।

[6001]
type=endpoint
context=internal
disallow=all
allow=ulaw
auth=auth6001
aors=6001
direct_media=no

[auth6001]
type=auth
auth_type=userpass
username=6001
password=REPLACE_WITH_A_LONG_RANDOM_SECRET

[6001]
type=aor
max_contacts=1

direct_media=no Asterisk-কে media path-এর মধ্যে রাখে। এটি বাদ দিলে Asterisk দুই endpoint-কে সরাসরি একে অপরের কাছে RTP পাঠাতে বলবে। Home router-এ কোনো phone NAT (network address translation)-এর পেছনে থাকলে এটি ব্যর্থ হয়। Secret কখনো extension number-এর সঙ্গে মিলিয়ে রাখবেন না। উদাহরণটি সহজে বোঝার জন্য upstream sample-এ extension 6001-এর ক্ষেত্রে password=6001 ব্যবহার করা হয়েছে। Scanner-গুলো প্রথমেই ঠিক এই pattern চেষ্টা করে।

/etc/asterisk/extensions.conf-এর dialplan নির্ধারণ করে প্রতিটি context কী করতে পারবে।

[internal]
exten => 6001,1,Dial(PJSIP/6001,20)
exten => _9X.,1,Dial(PJSIP/${EXTEN:1}@mytrunk,60)

[from-trunk]
exten => 1234567890,1,Dial(PJSIP/6001,20)
same => n,Hangup()

এই দুটি context একটি security boundary হিসেবে কাজ করে। from-trunk provider থেকে আসা call পরিচালনা করে এবং শুধু extension 6001-এ ring করতে পারে। এটি _9X. pattern-এ পৌঁছাতে পারে না। তাই বাইরে থেকে আসা কোনো call আপনার trunk ব্যবহার করে আবার বাইরে dial করতে পারে না। Context দুটিকে একত্র করলে classic toll fraud path তৈরি হবে: কোনো অপরিচিত ব্যক্তি আপনার number-এ call করবে, আপনার dialplan আপনার account ব্যবহার করে বাইরে call করবে, এবং সেই খরচ আপনাকেই দিতে হবে।

Configuration প্রয়োগ করে এটি পরীক্ষা করুন।

sudo asterisk -rx "pjsip reload"
sudo asterisk -rx "pjsip show registrations"
sudo asterisk -rx "pjsip show endpoints"

pjsip show registrations-এ mytrunk-কে Registered status-সহ তালিকাভুক্ত হওয়া উচিত। Rejected-এর অর্থ provider আপনার credentials প্রত্যাখ্যান করেছে। Unregistered-এর অর্থ আপনার REGISTER-এর কোনো উত্তর আসছে না। তাই এরপর firewall পরীক্ষা করুন।

SIP এবং RTP-এর জন্য firewall rule

Signalling এবং media-কে আলাদাভাবে পরিচালনা করতে হবে, কারণ এগুলো ভিন্ন ধরনের ঝুঁকি বহন করে। 5060 কেবল আপনার provider বাস্তবে যে address ব্যবহার করে এবং আপনার phone যে network-এ রয়েছে, সেগুলোর জন্য সীমাবদ্ধ রাখুন।

sudo ufw allow proto udp from 203.0.113.10 to any port 5060
sudo ufw allow proto tcp from 203.0.113.10 to any port 5060
sudo ufw allow 10000:10200/udp
sudo ufw status verbose

RTP range-কে একই মাত্রায় সংকুচিত করা যায় না, কারণ media প্রায়ই signalling-এর চেয়ে ভিন্ন address থেকে আসে। আপনার provider-এর কাছে তাদের media subnet সম্পর্কে জিজ্ঞাসা করুন। তারা subnet প্রকাশ করলে শুধু সেগুলোতেই অনুমতি সীমাবদ্ধ রাখুন। আপনার busiest hour-এর জন্য যতটুকু range দরকার, range ঠিক ততটুকুই রাখুন। Default policy, rule order এবং ufw model-এর অন্যান্য অংশ VPS-এর জন্য ufw firewall-এর মৌলিক নির্দেশিকায় ব্যাখ্যা করা হয়েছে।

IPv6-ও পরীক্ষা করুন। /etc/default/ufw-এ IPV6=no সেট থাকলে ufw মোটেও IPv6 filter করে না। তাই ::-এ bind করা daemon উপরের কোনো rule প্রয়োগ না হয়েই IPv6-এর মাধ্যমে reachable থাকে। ufw দিয়ে IPv6-এর জন্য port খোলার নির্দেশিকা-তে দুই address family-এর পার্থক্য ব্যাখ্যা করা হয়েছে। অধিকাংশ provider control panel-এ আলাদা network firewall-ও দেয়। আপনার packet VPS-এ পৌঁছানোর আগেই সেই firewall প্রয়োগ হয়। তাই port-টি দুই জায়গাতেই open থাকতে হবে।

SIP brute force এবং toll fraud ঐচ্ছিক সমস্যা নয়

5060 একটি public address-এ রাখলেই scan শুরু হয়। ধরণটি নিয়মিত: বিভিন্ন source address থেকে REGISTER এবং INVITE request আসে। এগুলো সাধারণ extension number-এর সঙ্গে প্রচলিত secret ব্যবহার করে চেষ্টা চালায়। Asterisk প্রতিটি ব্যর্থতা log করে। সেই log-এর গঠন এমন।

Request 'REGISTER' from '<sip:1000@198.51.100.20>' failed for '198.51.100.20:5060' (callid: 5f1a5c0d) - No matching endpoint found

এতে যথেষ্ট গুরুত্ব দেওয়ার কারণ হলো অর্থের ক্ষতি। চুরি হওয়া extension ব্যবহার করে ব্যয়বহুল international call করা হয়। অনেক সময় premium rate number-এ call করা হয়, যেখান থেকে আক্রমণকারী একটি অংশ পায়। Call আপনার credential ব্যবহার করে হওয়ায় বিল আপনাকেই দিতে হয়। এই প্রক্রিয়া machine speed-এ চলে এবং সাধারণত রাতভর চলতে থাকে।

ছয়টি নিয়ন্ত্রণ ব্যবস্থা বাধ্যতামূলক। এগুলো ঐচ্ছিক hardening নয়।

• কখনো এমন extension তৈরি করবেন না যার secret নিজস্ব number বা ছোট কোনো শব্দ। openssl rand -base64 24 ব্যবহার করে একটি secret তৈরি করুন এবং সেটি paste করুন।
• anonymous inbound call বন্ধ রাখুন। PJSIP default হিসেবে unidentified call প্রত্যাখ্যান করে। শুধু anonymous নামের একটি endpoint তৈরি করলে এটি গ্রহণ করে। এমন endpoint তৈরি করবেন না।
• উপরে দেখানো অনুযায়ী trunk context-কে এমন যেকোনো context থেকে আলাদা রাখুন, যেখান থেকে বাইরে call করা যায়।
• ufw এবং আপনার provider-এর network firewall—উভয় জায়গায় source address অনুযায়ী signalling সীমাবদ্ধ করুন।
• আপনার SIP trunk provider-এর সঙ্গে spending cap নির্ধারণ করুন এবং যেসব international destination-এ কখনো call করেন না, সেগুলো বন্ধ করুন। অন্য নিয়ন্ত্রণ ব্যবস্থা ব্যর্থ হলে ক্ষতির পরিমাণ সীমিত করার একমাত্র নিয়ন্ত্রণ এটি।
• Asterisk log-এর ওপর fail2ban চালান।

একটি address থেকে বারবার মেলেনি এমন request এলে Asterisk একটি security event-ও তৈরি করতে পারে। pjsip.conf-এর [global] section-এ unidentified_request_count নির্ধারণ করা যায়, যার default মান 5, এবং unidentified_request_period নির্ধারণ করা যায়, যার default মান 5 seconds। দুটির অর্থ হলো, পাঁচ seconds-এর মধ্যে একটি address থেকে পাঁচটি মেলেনি এমন request এলে একটি security event তৈরি হবে, যার ওপর fail2ban ব্যবস্থা নিতে পারবে।

স্ক্যানারগুলোকে fail2ban দিয়ে নিষিদ্ধ করুন

fail2ban-এ একটি asterisk jail আগে থেকেই দেওয়া থাকে। এটি 5060 এবং 5061 port কভার করে, /var/log/asterisk/messages পড়ে এবং ডিফল্টভাবে maxretry = 10 ব্যবহার করে। /etc/fail2ban/jail.local-এ এটি enable না করা পর্যন্ত jail-টি বন্ধ থাকে।

[asterisk]
enabled = true
maxretry = 5
findtime = 600
bantime = 86400

sudo systemctl restart fail2ban
sudo fail2ban-client status asterisk

সঠিক ফলাফলে jail-এর log file এবং বর্তমানে নিষিদ্ধ address-এর সংখ্যা দেখা যায়। Public 5060 থাকলে এক দিনের মধ্যেই এই সংখ্যা শূন্য থেকে বেড়ে যায়। সরবরাহ করা filter উপরের No matching endpoint found notice-গুলোর সঙ্গে মিলে যায় এবং Asterisk-এর structured SecurityEvent line-ও শনাক্ত করে। ওই event-গুলো একটি আলাদা log channel-এ যায়, যা /etc/asterisk/logger.conf-এ comment করা থাকে। সেগুলোও ধরতে চাইলে সেখানে channel-টি enable করুন এবং jail-এর logpath-এ file-টি যোগ করুন।

[logfiles]
console => notice,warning,error
messages.log => notice,warning,error
security.log => security

sudo asterisk -rx "logger reload" দিয়ে logger reload করুন। Filter-এ asterisk.service-এর জন্য একটি journalmatch-ও আছে। তাই log file সংরক্ষণ না করতে চাইলে journal backend ব্যবহার করা যায়। Installation, jail.local structure এবং ভুল করে নিজের address lock out করলে সেটি unban করার পদ্ধতি Ubuntu 24.04-এর fail2ban guide-এ দেখানো হয়েছে।

দূরবর্তী VPS-এ latency এবং codec নির্বাচন

ভৌগোলিক অবস্থান latency নির্ধারণ করে; configuration দিয়ে এটি দূর করা যায় না। ITU-T G.114 স্বাভাবিক কথোপকথনের জন্য one-way delay 150 ms-এর নিচে রাখার পরামর্শ দেয় এবং প্রায় 400 ms পর্যন্ত delay-কে এখনও ব্যবহারযোগ্য হিসেবে বিবেচনা করে। একটি phone-এর audio আপনার VPS-এ যায় এবং সেখান থেকে trunk provider-এর দিকে যায়। তাই ভুল region-এ থাকা VPS-এ এই পথ দুইবার অতিক্রম করতে হয়। VPS-কে phone অথবা provider-এর কাছাকাছি রাখুন। দুটির অবস্থান পরস্পরবিরোধী হলে phone-এর কাছাকাছি রাখুন, কারণ ওই leg সাধারণত consumer internet-এর ওপর চলে এবং সেখানে jitter বেশি হয়।

Codec নির্বাচন প্রতিটি call-এর bandwidth নির্ধারণ করে। এখানে প্রতিটি codec প্রতি 20 ms-এ একটি packet পাঠায়। অর্থাৎ প্রতি সেকেন্ডে 50টি packet পাঠানো হয়। প্রতিটি packet-এ audio payload-এর অতিরিক্ত 40 bytes IP, UDP এবং RTP header থাকে।

[
  {
    "label": "G.711 ulaw",
    "payload_kbps": 64,
    "ip_kbps": 80
  },
  {
    "label": "G.722",
    "payload_kbps": 64,
    "ip_kbps": 80
  },
  {
    "label": "Opus at 24 kbps",
    "payload_kbps": 24,
    "ip_kbps": 40
  },
  {
    "label": "G.729",
    "payload_kbps": 8,
    "ip_kbps": 24
  }
]

বেশিরভাগ trunk-এ G.711 ulaw default হিসেবে ব্যবহৃত হয়। এর payload হল 64 kbps। Header-সহ একটি চলমান call-এ প্রতিটি direction-এ 80 kbps bandwidth লাগে। Opus at 24 kbps ব্যবহার করলে bandwidth হয় 40 kbps। G.729 ব্যবহার করলে audio quality এবং CPU time-এর বিনিময়ে bandwidth কমে 24 kbps হয়। এই হিসাব measurement নয়; এটি header arithmetic: payload rate-এর সঙ্গে প্রতি সেকেন্ডে 50টি packet-এর জন্য প্রতি packet-এ 40 bytes যোগ করা হয়েছে। Ethernet বা VLAN framing wire-এ আরও সামান্য bandwidth যোগ করে।

Transcoding-এর জন্য CPU লাগে। আপনার phone এবং trunk উভয়ই ulaw সমর্থন করলে শুধু ulaw অনুমোদন করুন। তাহলে Asterisk audio অপরিবর্তিতভাবে pass through করবে। Lossy link-এ Opus ভালো কাজ করে। তবে Opus এবং G.711-এর মধ্যে transcoding করতে external codec_opus module প্রয়োজন। এটি make menuselect-এ নির্বাচন করতে হয় এবং এটি default হিসেবে build করা থাকে না।

কী নষ্ট হচ্ছে এবং আপনি যে বার্তাটি দেখবেন

কল সংযুক্ত হয়, কিন্তু কেউ কোনো শব্দ শুনতে পায় না। RTP আসছে না। rtp.conf-এর পরিসরটি firewall-এ খোলা পরিসরের সঙ্গে মিলিয়ে দেখুন। কল করার সময় sudo tcpdump -ni any udp portrange 10000-10200 দিয়ে packet পর্যবেক্ষণ করুন। একটিও packet না থাকলে আপনার firewall অথবা provider-এর network firewall সেগুলো drop করছে।

শুধু একদিকে audio শোনা যায়। একটি দিক এমন address-এ RTP পাঠাচ্ছে, যেটি তা গ্রহণ করতে পারে না। এটি port-এর সমস্যা নয়, address-এর সমস্যা। VPS-এর interface-এ public address সরাসরি থাকলে NAT handling প্রয়োজন নেই। Provider যদি VPS-কে one-to-one public mapping-সহ একটি private address দেয়, transport-এ public address নির্ধারণ করুন এবং local_net-এ আপনার private range তালিকাভুক্ত করুন।

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0
local_net=10.0.0.0/8
external_media_address=198.51.100.5
external_signaling_address=198.51.100.5

Log-এ No matching endpoint found। IP address অথবা username অনুযায়ী request-টি কোনো endpoint-এর সঙ্গে মেলেনি। এটি কোনো scanner থেকে এলে স্বাভাবিক, এবং fail2ban এটি সামলাবে। আপনার নিজের provider থেকে এলে এর অর্থ হলো identify section-এ তারা যে address থেকে আপনাকে call করে, সেটি তালিকাভুক্ত নেই।

Registration status হলো Rejected। Provider আপনার auth section-এর credentials প্রত্যাখ্যান করেছে। CLI-তে pjsip set logger on চালান। একটি REGISTER এবং তার response পর্যবেক্ষণ করুন। এরপর client_uri ও username provider আপনাকে যে তথ্য দিয়েছে, তার সঙ্গে তুলনা করুন।

Log-এ কোনো কার্যকর তথ্যই নেই। Asterisk ডিফল্টভাবে messages.log এবং তার উপরের notice level লিখে। সমস্যাটি পুনরায় ঘটানোর সময় core set verbose 4 এবং pjsip set logger on দিয়ে level বাড়ান। কাজ শেষ হলে দুটিই বন্ধ করুন, কারণ SIP logger প্রতিটি packet লেখে।

এটি Internet-এ উন্মুক্ত করার আগে

PBX নিজে host করা অন্য পরিষেবাগুলোর মতো নয়। একটি web app নষ্ট হলে একটি page কাজ করে না। কিন্তু একটি PBX নষ্ট হলে আপনি ঘুমিয়ে থাকা অবস্থায় কয়েক ঘণ্টার মধ্যে বড় phone bill তৈরি হতে পারে। এটি এমন একটি VPS-এ চালান, যেখানে অন্য কোনো কাজ চলছে না। 5060 কেবল পরিচিত address-গুলোর জন্য সীমাবদ্ধ রাখুন। প্রতিটি extension-এর জন্য একটি random secret ব্যবহার করুন। Trunk account-এ spending cap নির্ধারণ করুন। সার্ভারের বাকি অংশেও Internet-এ উন্মুক্ত যেকোনো server-এর মতো একই baseline security প্রয়োগ করুন। VPS hosting আসলে কতটা নিরাপদ, এই আলোচনায় সেটি ব্যাখ্যা করা হয়েছে।

FAQ

একটি self-hosted VoIP server-এর জন্য কোন port খুলতে হবে?

UDP ও TCP-এর মাধ্যমে SIP signalling-এর জন্য port 5060 খুলুন। SIP over TLS ব্যবহার করলে port 5061 খুলুন। RTP media-এর জন্য UDP port-এর একটি range খুলুন। Asterisk-এর নমুনা rtp.conf-এ 10000 থেকে 20000 ব্যবহার করা হয়, আর compiled-in default হলো 5000 থেকে 31000। প্রতিটি call-এ এই range থেকে দুইটি port ব্যবহৃত হয়। তাই 200টি port-এর range একসঙ্গে 100টি call পরিচালনা করতে পারে। RTP range-টি UDP হিসেবে খুলুন। 5060 সবার জন্য উন্মুক্ত না রেখে আপনার provider-এর address এবং আপনার নিজস্ব network-এ সীমাবদ্ধ রাখুন।

Asterisk কি আলাদাভাবে install করব, নাকি FreePBX ব্যবহার করব?

ছোট attack surface এবং git-এ রাখা যায় এমন configuration file চাইলে raw Asterisk install করুন। তবে dialplan নিজে লিখতে হবে। Extension, voicemail এবং call queue পরিচালনার জন্য GUI চাইলে FreePBX install করুন। August 2026 অনুযায়ী FreePBX 17 installer একটি vanilla Debian 12 machine প্রত্যাশা করে এবং Asterisk, একটি web server, একটি database server ও PHP install করে। তাই এর জন্য আলাদা VPS ব্যবহার করুন। FreePBX তার নিয়ন্ত্রিত configuration file-গুলো পুনরায় তৈরি করে। তাই হাতে করা edit _custom file-এ রাখতে হবে।

Call connect হওয়ার পরে audio শোনা যায় না কেন?

Signalling কাজ করেছে, কিন্তু media কাজ করেনি। SIP port 5060-এ call স্থাপন করেছে। Audio আলাদা একটি UDP flow হিসেবে RTP range-এর কোনো port-এ যায়, কিন্তু কোনো স্তর সেটি drop করছে। rtp.conf-এ নির্ধারিত range আপনার firewall-এ খোলা range-এর সঙ্গে মেলে কি না পরীক্ষা করুন। Provider-এর network firewall এবং server-এর firewall—দুটিই পরীক্ষা করুন। Call চলাকালে sudo tcpdump -ni any udp portrange 10000-10200 চালান। কোনো packet না দেখা গেলে বুঝতে হবে, packet server-এ পৌঁছানোর আগেই blocked হচ্ছে।

SIP brute force attack এবং toll fraud কীভাবে বন্ধ করব?

প্রতিটি extension-এর জন্য দীর্ঘ random secret দিন। Secret কখনো extension number-এর সঙ্গে মিলবে না। আপনার trunk যে context ব্যবহার করে, সেটিকে এমন context থেকে আলাদা রাখুন যেখান থেকে বাইরে call করা যায়। এতে inbound call আপনার account ব্যবহার করে আবার বাইরে call করতে পারবে না। Port 5060 আপনার provider-এর address-এ সীমাবদ্ধ রাখুন। fail2ban-এ asterisk jail সক্রিয় করুন। এটি /var/log/asterisk/messages পড়ে এবং No matching endpoint found failure তৈরি করা address ban করে। এরপর provider-এর মাধ্যমে spending cap নির্ধারণ করুন এবং ব্যবহার না করা international destination block করুন। বাকি নিয়ন্ত্রণ ব্যর্থ হলে ক্ষতির পরিমাণ সীমাবদ্ধ করার একমাত্র কার্যকর ব্যবস্থা এটিই।

দূরের region-এ থাকা VPS কি call quality খারাপ করে?

হ্যাঁ। কারণ audio দুটি ধাপে যায়: phone থেকে VPS, তারপর VPS থেকে trunk provider। ITU-T G.114 একমুখী delay 150 ms-এর নিচে রাখার পরামর্শ দেয়। ভুল region-এ থাকা VPS দূরত্বের কারণেই এই budget-এর বেশিরভাগ ব্যবহার করতে পারে। Phone-এর কাছাকাছি region বেছে নিন। কারণ এই leg সাধারণত consumer internet-এর ওপর চলে, যেখানে jitter সবচেয়ে বেশি হয়। Codec বেছে নিলে delay কমে না। শুধু bandwidth-এর ব্যবহার বদলায়। তাই G.729 কম byte ব্যবহার করলেও 200 ms path ঠিক করতে পারবে না।