اپنے VPS پر Asterisk یا FreePBX کیسے چلائیں

خود میزبانی شدہ VoIP server کیا ہوتا ہے

خود میزبانی شدہ VoIP server وہ SIP server ہے جو آپ کے زیر انتظام VPS پر چلتا ہے۔ اس طرح calls کسی hosted phone service کے بجائے آپ کی اپنی machine کے ذریعے route ہوتی ہیں۔ VoIP (voice over IP) آواز کو UDP packets کے طور پر منتقل کرتا ہے۔ SIP (session initiation protocol) وہ signalling ہے جو call شروع اور ختم کرتی ہے۔ Audio، SIP کے ذریعے منتقل نہیں ہوتا۔ ذیل میں بیان کردہ زیادہ تر مسائل کی بنیادی وجہ یہی حقیقت ہے۔

ایک فعال system کے لیے چار حصے ضروری ہیں۔

• PBX (private branch exchange) software۔ Asterisk عام انتخاب ہے۔ اس میں extensions اور dialplan محفوظ ہوتے ہیں۔
• Endpoints۔ Desk phones یا softphones، جو username اور secret کے ذریعے PBX کے ساتھ register ہوتے ہیں۔
• SIP trunk۔ Provider کے ساتھ paid account، جو آپ کو public telephone network سے connect کرتا ہے اور حقیقی phone numbers کرائے پر فراہم کرتا ہے۔
• Media path۔ RTP (real-time transport protocol) flows، جو اپنے الگ UDP ports پر audio منتقل کرتے ہیں۔

PBX کی self-hosting کا مطلب phone numbers کی self-hosting نہیں ہے۔ Numbers carrier سے حاصل ہوتے ہیں، اور آپ کو ہر number اور ہر minute کے حساب سے ادائیگی کرنی ہوتی ہے۔ آپ کے اختیار میں call routing، voicemail، recordings اور extension list ہوتے ہیں۔ اس کے علاوہ ایسے service کی security بھی آپ کی ذمہ داری ہوتی ہے جسے لوگ پیسے چرانے کے لیے target کرتے ہیں۔

خود میزبانی والے VoIP server کو کون سے ports درکار ہوتے ہیں؟

SIP signalling کے لیے UDP اور TCP پر port 5060، جبکہ SIP over TLS (transport layer security) کے لیے port 5061 استعمال ہوتا ہے۔ یہ ports صرف call setup کے لیے ہوتے ہیں۔ ہر call کی audio ایک الگ UDP flow کے ذریعے بھیجی جاتی ہے، جس کے لیے RTP range سے ایک port لیا جاتا ہے۔ Asterisk کے ساتھ ایک sample rtp.conf شامل ہوتا ہے جو rtpstart=10000 اور rtpend=20000 مقرر کرتا ہے، جبکہ compile کے وقت شامل کیے گئے default values 5000 اور 31000 ہیں۔ ہر call اس range سے دو ports لیتی ہے: ایک RTP کے لیے اور ایک RTCP (RTP control protocol) کے لیے۔

زیادہ تر ابتدائی کوششیں اسی تقسیم کی وجہ سے ناکام ہوتی ہیں۔ Call connect ہو جاتی ہے، دونوں phones اسے answered دکھاتے ہیں، لیکن کسی جانب audio سنائی نہیں دیتی، کیونکہ firewall 5060 کی اجازت دیتی ہے اور ہر RTP packet کو drop کر دیتی ہے۔ Signalling اور media الگ الگ flows ہیں، اس لیے ان کے لیے الگ firewall rules درکار ہوتے ہیں۔ اگر یہ فرق نیا ہے تو کوئی بھی port کھولنے سے پہلے Linux پر ports اور listening sockets کیسے کام کرتے ہیں پڑھنا مفید ہوگا۔

Port range کھولنے سے پہلے اسے محدود کریں۔ بیس ہزار ports ایک چھوٹے system کی ضرورت سے کہیں زیادہ ہیں۔ ہر call کے لیے دو ports درکار ہوتے ہیں، اس لیے دو سو ports کی range بیک وقت ایک سو calls کے لیے کافی ہے۔

[general]
rtpstart=10000
rtpend=10200

اسے sudo asterisk -rx "core reload" کے ذریعے نافذ کریں۔

کیا آپ کو Asterisk یا FreePBX انسٹال کرنا چاہیے؟

Asterisk بنیادی انجن ہے۔ آپ اسے /etc/asterisk میں موجود ٹیکسٹ فائلوں کے ذریعے configure کرتے ہیں اور dialplan خود لکھتے ہیں۔ FreePBX ایک web interface ہے جو PHP اور JavaScript میں لکھی گئی ہے۔ یہ Asterisk کے اوپر چلتی ہے، یہ فائلیں آپ کے لیے generate کرتی ہے، اور voicemail اور call queues کے لیے modules شامل کرتی ہے۔

VPS پر اہم فرق مشین کی ملکیت کا ہے۔ August 2026 تک official FreePBX 17 installer ایک vanilla Debian 12 system کی توقع کرتا ہے۔ یہ Asterisk، ایک web server، ایک database server اور PHP انسٹال کرتا ہے۔ اگر آپ اسے ایسے box پر چلائیں جس پر پہلے ہی دوسری services چل رہی ہوں تو نتیجہ اچھا نہیں ہوگا۔ 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 اپنی generate کردہ configuration files کی ownership رکھتا ہے۔ FreePBX box پر pjsip.conf کو ہاتھ سے edit کریں گے تو اگلی بار GUI کے اس file کو write کرنے پر آپ کی تبدیلی ختم ہو جائے گی۔ FreePBX ہاتھ سے لکھی گئی configuration کے لیے نام میں _custom والی الگ files پڑھتا ہے، اور انہیں تبدیل نہیں کرتا۔

حقیقی 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 ہے جس کا money systems تک براہِ راست راستہ ہوتا ہے۔

Version note، جو August 2026 تک درست ہے: Asterisk 22 موجودہ long term support release ہے۔ یہ October 2024 میں published ہوئی تھی اور اسے October 2028 تک security fixes ملیں گی۔ Asterisk 23 standard release ہے۔ Ubuntu 24.04 کے universe repository میں Asterisk 20.6.0 شامل ہے۔

Ubuntu 24.04 پر Asterisk انسٹال کریں

Distribution package فوری طریقہ ہے۔ Ubuntu اس میں patches شامل کرتا ہے، اور یہ خود systemd کے تحت شروع ہو جاتا ہے۔

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

Source سے 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 dependencies انسٹال کرتا ہے، جبکہ install_prereq test وہ commands دکھاتا ہے جو یہ چلائے گا، مگر کسی چیز میں تبدیلی نہیں کرتا۔ make menuselect module picker کھولتا ہے۔ یہی وہ جگہ ہے جہاں Codec Translators کے تحت codec_opus فعال کیا جاتا ہے۔ make samples صرف نئی install پر چلائیں، کیونکہ یہ 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 چلانے سے معلوم ہوتا ہے کہ حقیقت میں کون سا software انسٹال ہوا ہے۔

ایک SIP trunk اور ایک extension configure کریں

موجودہ Asterisk میں PJSIP، SIP channel driver ہے۔ اس کی configuration /etc/asterisk/pjsip.conf میں موجود ہوتی ہے اور چھوٹے typed sections سے بنتی ہے، جو نام کے ذریعے ایک دوسرے کا حوالہ دیتے ہیں۔ مختلف اقسام کے sections کا نام ایک جیسا ہو سکتا ہے، اسی لیے نیچے موجود ہر 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 وہ REGISTER بھیجتا ہے جو provider کو بتاتا ہے کہ آپ کی calls کہاں deliver کرنی ہیں۔ identify object کے ذریعے provider سے آنے والی call کو source address کی بنیاد پر اس endpoint سے match کیا جاتا ہے، اور provider عموماً کئی addresses فراہم کرتا ہے جنہیں یہاں درج کرنا ہوتا ہے۔ Outbound registration اور endpoint جان بوجھ کر الگ objects ہیں: ایک provider کو بتاتا ہے کہ آپ کہاں موجود ہیں، جبکہ دوسرا طے کرتا ہے کہ آنے والی calls کے ساتھ کیا کرنا ہے۔

Desk phone کے لیے مزید تین objects درکار ہیں۔

[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 کوشش کرے گا کہ دونوں endpoints RTP براہ راست ایک دوسرے کو بھیجیں۔ Home router کے پیچھے NAT (network address translation) پر موجود phone کے ساتھ یہ ناکام ہو جاتا ہے۔ Secret کو extension number کے برابر کبھی نہ رکھیں۔ Upstream sample extension 6001 کے لیے password=6001 استعمال کرتا ہے تاکہ مثال پڑھنے میں آسان رہے، اور scanners سب سے پہلے عموماً اسی 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()

یہ دونوں contexts ایک security boundary ہیں۔ from-trunk provider سے آنے والی calls سنبھالتا ہے اور صرف extension 6001 کو ring کر سکتا ہے۔ یہ _9X. pattern تک نہیں پہنچ سکتا، اس لیے باہر سے آنے والی call آپ کے trunk کے ذریعے دوبارہ باہر dial نہیں کر سکتی۔ اگر آپ contexts کو merge کر دیں تو toll fraud کا معروف راستہ بن جائے گا: کوئی اجنبی آپ کے number پر call کرے گا، آپ کا dialplan آپ کے account سے باہر call کرے گا، اور اس کا خرچ آپ کو ادا کرنا پڑے گا۔

Configuration apply کریں اور اسے check کریں۔

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 check کریں۔

SIP اور RTP کے لیے firewall rules

Signalling اور media کے ساتھ الگ طریقے سے معاملہ کریں، کیونکہ دونوں مختلف خطرات رکھتے ہیں۔ 5060 کو صرف ان addresses تک محدود کریں جو آپ کا provider حقیقت میں استعمال کرتا ہے، اور ان networks تک بھی جہاں آپ کے phones موجود ہیں۔

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 subnets معلوم کریں، اور اگر وہ انہیں شائع کرتا ہے تو traffic کو انہی تک محدود کریں۔ Range کو صرف اتنا بڑا رکھیں جتنی آپ کے مصروف ترین گھنٹے کی ضرورت ہو۔ Default policies، rule order اور ufw model کے دیگر حصے VPS کے لیے ufw firewall basics guide میں بیان کیے گئے ہیں۔

IPv6 بھی check کریں۔ اگر IPV6=no، /etc/default/ufw میں set ہے تو ufw IPv6 کو بالکل filter نہیں کرتا۔ اس صورت میں :: پر bound daemon، اوپر دیے گئے کسی rule کے اطلاق کے بغیر، IPv6 کے ذریعے reachable ہوتا ہے۔ ufw کے ساتھ IPv6 کے لیے ports کھولنا میں بتایا گیا ہے کہ دونوں families میں کیا فرق ہے۔ زیادہ تر providers control panel میں الگ network firewall بھی دیتے ہیں۔ یہ firewall آپ کے packets کے VPS تک پہنچنے سے پہلے enforce ہوتا ہے، اس لیے port کو دونوں جگہ open ہونا چاہیے۔

SIP brute force اور toll fraud اختیاری مسائل نہیں ہیں

5060 کو public address پر رکھیں تو scans شروع ہو جاتے ہیں۔ pattern مستقل رہتا ہے: متعدد source addresses سے REGISTER اور INVITE requests آتی ہیں، جو عام extension numbers کے ساتھ عام secrets آزما رہی ہوتی ہیں۔ Asterisk ہر failure کو log کرتا ہے، اور اس کا format یہ ہوتا ہے۔

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

اس معاملے میں حقیقی کوشش کی ضرورت کی وجہ رقم ہے۔ چوری شدہ extension سے مہنگی international calls کی جاتی ہیں، اکثر ایسے premium rate numbers پر جو attacker کو آمدنی کا حصہ دیتے ہیں۔ چونکہ calls آپ کی credentials استعمال کرتی ہیں، اس لیے bill آپ کو ادا کرنا پڑتا ہے۔ یہ عمل machine speed پر چلتا ہے اور عموماً رات بھر جاری رہتا ہے۔

چھ controls لازمی ہیں، optional hardening نہیں۔

• کبھی ایسی extension نہ بنائیں جس کا secret خود اس کا number یا کوئی مختصر لفظ ہو۔ openssl rand -base64 24 سے ایک secret generate کریں اور اسے paste کریں۔
• anonymous inbound calls بند رکھیں۔ PJSIP unidentified calls کو default طور پر مسترد کرتا ہے اور صرف اس وقت قبول کرتا ہے جب آپ anonymous نام کا endpoint بنائیں۔ ایسا endpoint نہ بنائیں۔
• trunk context کو ہر ایسے context سے الگ رکھیں جو outbound calls dial کر سکتا ہو، جیسا کہ اوپر دکھایا گیا ہے۔
• ufw اور اپنے provider کے network firewall، دونوں میں source address کے ذریعے signalling محدود کریں۔
• اپنے SIP trunk provider کے ساتھ spending cap مقرر کریں اور وہ international destinations disable کریں جن پر آپ کبھی call نہیں کرتے۔ جب باقی controls ناکام ہو جائیں تو نقصان محدود کرنے والا واحد control یہی ہے۔
• Asterisk log پر fail2ban چلائیں۔

Asterisk ایک ہی address سے بار بار آنے والی unmatched requests کے بعد security event بھی پیدا کر سکتا ہے۔ pjsip.conf کا [global] section unidentified_request_count لیتا ہے، جس کی default قدر 5 ہے، اور unidentified_request_period بھی لیتا ہے، جس کی default قدر 5 seconds ہے۔ دونوں کو ملا کر مطلب یہ ہے کہ ایک address سے پانچ seconds کے اندر پانچ unmatched requests آنے پر security event پیدا ہوتا ہے، جس پر fail2ban کارروائی کر سکتا ہے۔

fail2ban کے ذریعے scanners کو روکیں

fail2ban میں asterisk jail پہلے سے موجود ہوتی ہے۔ یہ ports 5060 اور 5061 کو cover کرتی ہے، /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 اور اس وقت banned addresses کی تعداد دکھائی دیتی ہے۔ public 5060 پر یہ تعداد ایک دن کے اندر zero سے بڑھ جاتی ہے۔ پہلے فراہم کیا گیا filter اوپر دیے گئے No matching endpoint found notices سے match کرتا ہے۔ یہ Asterisk کی structured SecurityEvent lines سے بھی match کرتا ہے۔ یہ events ایک الگ log channel میں جاتے ہیں، جو /etc/asterisk/logger.conf میں commented out ہے۔ اگر آپ انہیں شامل کرنا چاہتے ہیں تو اسے وہیں enable کریں اور file کو jail کے logpath میں شامل کریں۔

[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 files برقرار نہیں رکھنا چاہتے تو journal backend استعمال کیا جا سکتا ہے۔ Installation، jail.local structure، اور جس address کو آپ نے خود lock out کر دیا ہو اسے unban کرنے کا طریقہ Ubuntu 24.04 کے لیے fail2ban guide میں بیان کیا گیا ہے۔

دور دراز VPS پر تاخیر اور codec کا انتخاب

تاخیر جغرافیہ سے متعین ہوتی ہے، اسے configuration کے ذریعے ختم نہیں کیا جا سکتا۔ ITU-T G.114 عام گفتگو کے لیے یک طرفہ تاخیر 150 ms سے کم رکھنے کی سفارش کرتا ہے اور تقریباً 400 ms تک تاخیر کو اب بھی قابل استعمال سمجھتا ہے۔ فون سے audio آپ کے VPS تک جاتی ہے اور پھر وہاں سے trunk provider تک پہنچتی ہے، اس لیے غلط region میں موجود VPS یہ فاصلہ دو مرتبہ طے کرتا ہے۔ VPS کو فونز یا provider کے قریب رکھیں۔ اگر دونوں سمتیں مختلف ہوں تو فونز کے قریب والا مقام ترجیح دیں، کیونکہ یہ راستہ عموماً consumer internet سے گزرتا ہے جہاں jitter زیادہ ہوتا ہے۔

Codec کا انتخاب ہر call کے لیے bandwidth طے کرتا ہے۔ یہاں ہر codec ہر 20 ms بعد ایک packet بھیجتا ہے، یعنی 50 packets per second، اور ہر packet میں audio payload کے علاوہ IP، UDP اور RTP headers کے 40 bytes شامل ہوتے ہیں۔

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

G.711 ulaw زیادہ تر trunks میں default ہوتا ہے۔ اس کا payload 64 kbps ہے، اور headers سمیت جاری call ہر سمت میں 80 kbps استعمال کرتی ہے۔ Opus at 24 kbps کی شرح 40 kbps بنتی ہے، جبکہ G.729 audio quality اور CPU time کی قیمت پر 24 kbps تک کم ہو جاتا ہے۔ یہ اعداد measurements کے بجائے headers کے حساب پر مبنی ہیں: 50 packets per second پر payload rate میں ہر packet کے 40 bytes شامل کیے گئے ہیں۔ Ethernet یا VLAN framing wire پر تھوڑا مزید data شامل کرتی ہے۔

Transcoding کے لیے CPU درکار ہوتا ہے۔ اگر آپ کے فونز اور trunk دونوں ulaw استعمال کرتے ہیں تو صرف ulaw کی اجازت دیں، اور Asterisk audio کو بغیر تبدیلی کے منتقل کرے گا۔ Opus lossy links پر اچھی کارکردگی دکھاتا ہے، لیکن Opus اور G.711 کے درمیان transcoding کے لیے بیرونی codec_opus module درکار ہوتا ہے۔ اسے make menuselect میں منتخب کیا جاتا ہے، اور یہ default طور پر build نہیں ہوتا۔

کیا خراب ہوتا ہے، اور آپ کو کون سا متن نظر آئے گا

کال connect ہو جاتی ہے لیکن کسی کو آواز سنائی نہیں دیتی۔ RTP موصول نہیں ہو رہا۔ تصدیق کریں کہ rtp.conf میں موجود range وہی ہے جسے آپ نے firewall میں کھولا ہے۔ پھر کال کرتے وقت sudo tcpdump -ni any udp portrange 10000-10200 سے packets monitor کریں۔ اگر ایک بھی packet نہ آئے تو firewall یا آپ کے provider کا network firewall انہیں drop کر رہا ہے۔

آڈیو صرف ایک سمت میں ہے۔ ایک فریق RTP ایسے address پر بھیج رہا ہے جہاں اسے موصول نہیں کیا جا سکتا۔ یہ port کا نہیں بلکہ address کا مسئلہ ہے۔ اگر آپ کے VPS کے interface پر public address براہ راست موجود ہے تو NAT handling درکار نہیں۔ اگر provider VPS کو private address دے کر one to one public mapping فراہم کرتا ہے تو transport میں public address set کریں اور اپنی private range کو local_net میں درج کریں۔

[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

لاگ میں No matching endpoint found۔ درخواست IP address یا username کے ذریعے کسی endpoint سے match نہیں ہوئی۔ Scanner کی طرف سے آنے والی درخواست کے لیے یہ معمول کی بات ہے، اور fail2ban اسے handle کرے گا۔ اگر درخواست آپ کے اپنے provider کی طرف سے ہو تو اس کا مطلب ہے کہ identify section میں وہ address درج نہیں جس سے provider آپ کو call کرتا ہے۔

registration status Rejected ہے۔ Provider نے آپ کے auth section میں موجود credentials مسترد کر دیے۔ CLI پر pjsip set logger on چلائیں، ایک REGISTER اور اس کے response کو monitor کریں، پھر client_uri اور username کا provider کی جانب سے جاری کردہ معلومات سے موازنہ کریں۔

لاگ میں کوئی مفید معلومات موجود نہیں۔ Asterisk بطور default notice level اور اس سے اوپر کے messages کو messages.log میں لکھتا ہے۔ مسئلہ دوبارہ پیدا کرتے وقت core set verbose 4 اور pjsip set logger on سے logging level بڑھائیں۔ اس کے بعد دونوں کو بند کر دیں، کیونکہ SIP logger ہر packet لکھتا ہے۔

اسے public کرنے سے پہلے

PBX ان چیزوں جیسا نہیں ہے جنہیں آپ خود host کرتے ہیں۔ خراب web app سے ایک صفحہ دستیاب نہیں رہتا۔ خراب PBX چند گھنٹوں میں phone bill بنا دیتا ہے، جبکہ آپ سو رہے ہوتے ہیں۔ اسے ایسے VPS پر چلائیں جس پر کوئی اور کام نہ ہو، 5060 کو صرف معلوم addresses تک محدود رکھیں، ہر extension کو random secret دیں، اور trunk account پر spending cap مقرر کریں۔ باقی server کے لیے بھی وہی بنیادی security configuration درکار ہے جو ہر exposed server کے لیے ہوتی ہے؛ یہ جائزہ دیکھیں کہ VPS hosting حقیقت میں کتنی محفوظ ہے۔

FAQ

خود host کردہ VoIP سرور کے لیے مجھے کون سے ports کھولنے ہوں گے؟

UDP اور TCP پر SIP signalling کے لیے port 5060 کھولیں۔ اگر آپ SIP over TLS استعمال کرتے ہیں تو port 5061 بھی کھولیں۔ RTP media کے لیے UDP ports کی ایک range درکار ہوتی ہے۔ Asterisk کی sample rtp.conf میں 10000 سے 20000 تک ports استعمال ہوتے ہیں، جبکہ compiled-in defaults 5000 سے 31000 تک ہیں۔ ہر call اس range سے دو ports استعمال کرتی ہے، اس لیے 200 ports کی range 100 بیک وقت calls سنبھال سکتی ہے۔ RTP range کو UDP کے طور پر کھولیں۔ port 5060 کو سب کے لیے کھلا چھوڑنے کے بجائے اسے اپنے provider کے addresses اور اپنے networks تک محدود رکھیں۔

کیا مجھے Asterisk الگ install کرنا چاہیے یا FreePBX استعمال کرنا چاہیے؟

جب آپ کم attack surface چاہتے ہوں، configuration files کو git میں رکھنا چاہتے ہوں، اور dialplan خود لکھ سکتے ہوں تو raw Asterisk install کریں۔ جب آپ extensions، voicemail اور call queues کے لیے GUI چاہتے ہوں تو FreePBX install کریں۔ August 2026 تک FreePBX 17 installer ایک vanilla Debian 12 machine کی توقع کرتا ہے اور Asterisk، web server، database server اور PHP install کرتا ہے، اس لیے اسے اپنا الگ VPS دیں۔ FreePBX ان configuration files کو دوبارہ بناتا ہے جنہیں وہ manage کرتا ہے، اس لیے دستی تبدیلیاں اس کی _custom files میں کی جانی چاہییں۔

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 چلائیں۔ اگر کوئی packets نہیں ملتے تو وہ پہنچنے سے پہلے ہی block ہو رہے ہیں۔

SIP brute force حملوں اور toll fraud کو کیسے روکوں؟

ہر extension کے لیے لمبا اور random secret رکھیں۔ ایسا secret کبھی استعمال نہ کریں جو extension number سے مطابقت رکھتا ہو۔ اپنے trunk کے لیے استعمال ہونے والا context ایسے کسی context سے الگ رکھیں جو باہر call کر سکتا ہو، تاکہ inbound call آپ کے account سے دوبارہ باہر call نہ کر سکے۔ port 5060 کو اپنے provider کے addresses تک محدود رکھیں۔ fail2ban میں asterisk jail enable کریں۔ یہ /var/log/asterisk/messages کو پڑھتا ہے اور ان addresses کو ban کرتا ہے جو No matching endpoint found failures پیدا کرتے ہیں۔ اس کے بعد اپنے provider کے ذریعے spending cap مقرر کریں اور غیر استعمال شدہ international destinations block کریں، کیونکہ باقی controls ناکام ہونے کی صورت میں نقصان کی حد مقرر کرنے والا واحد control یہی ہے۔

کیا دور دراز region میں موجود VPS call quality کو متاثر کرتا ہے؟

ہاں، کیونکہ audio دو حصوں سے گزرتی ہے: phone سے VPS تک، پھر VPS سے trunk provider تک۔ ITU-T G.114 یک طرفہ delay کو 150 ms سے کم رکھنے کی سفارش کرتا ہے۔ غلط جگہ پر موجود VPS اس budget کا بیشتر حصہ صرف فاصلے میں خرچ کر سکتا ہے۔ phones کے قریب region منتخب کریں، کیونکہ یہ حصہ عموماً consumer internet پر چلتا ہے جہاں jitter سب سے زیادہ ہوتا ہے۔ Codec کا انتخاب delay کو درست نہیں کرتا، صرف bandwidth تبدیل کرتا ہے۔ اس لیے G.729 bytes بچاتا ہے، لیکن 200 ms path کو بہتر نہیں بنا سکتا۔