خادم VoIP ذاتي الاستضافة: إعداد Asterisk وFreePBX

ما هو خادم VoIP المستضاف ذاتياً

خادم VoIP المستضاف ذاتياً هو خادم SIP يعمل على VPS تتحكم فيه، لذلك يوجّه جهازك مكالماتك بدلاً من خدمة هاتفية مستضافة. ينقل VoIP (الصوت عبر IP) الكلام على شكل حزم UDP. أما SIP (بروتوكول بدء الجلسة) فهو إشارات التحكم التي تنشئ المكالمة وتنهيها. لا ينتقل الصوت عبر SIP. وهذه الحقيقة هي سبب معظم المشكلات الواردة أدناه.

تتكوّن المنظومة العاملة من أربعة أجزاء.

• برنامج PBX (بدالة الفروع الخاصة). يُعد Asterisk الخيار المعتاد. ويحتفظ بالامتدادات وخطة الاتصال.
• نقاط النهاية. وهي هواتف المكتب أو برامج الهاتف التي تسجّل نفسها لدى PBX باستخدام اسم مستخدم وسر.
• SIP trunk. وهو حساب مدفوع لدى مزود يوصلك بشبكة الهاتف العامة ويؤجّر لك أرقام هواتف حقيقية.
• مسار الوسائط. وهي تدفقات RTP (بروتوكول النقل في الوقت الفعلي) التي تنقل الصوت عبر منافذ UDP الخاصة بها.

لا يعني استضافة PBX ذاتياً أنك تستضيف أرقام الهواتف ذاتياً. تأتي الأرقام من شركة اتصالات، وتظل تدفع مقابل كل رقم وكل دقيقة. ما تملكه هو توجيه المكالمات، والبريد الصوتي، والتسجيلات، وقائمة الامتدادات. كما تتحمل مسؤولية أمان خدمة يهاجمها الأشخاص بغرض سرقة المال.

ما المنافذ التي يحتاج إليها خادم VoIP مستضاف ذاتياً؟

يستخدم SIP signalling المنفذ 5060 عبر UDP وTCP، والمنفذ 5061 لبروتوكول SIP عبر TLS (أمان طبقة النقل). تنقل هذه المنافذ إعداد المكالمة فقط. ينتقل الصوت في كل مكالمة عبر تدفق UDP منفصل، ويُرسل إلى منفذ من نطاق RTP. يتضمن Asterisk نموذج rtp.conf يضبط rtpstart=10000 وrtpend=20000، والقيم الافتراضية المضمّنة عند الترجمة هي 5000 و31000. تحتاج كل مكالمة إلى منفذين من هذا النطاق: أحدهما لـRTP والآخر لـRTCP (بروتوكول التحكم في RTP).

هذا الفصل بين التدفقات هو سبب فشل معظم المحاولات الأولى. تتصل المكالمة، ويعرض الهاتفان أنها أُجيبت، لكن لا يسمع أي طرف شيئاً، لأن جدار الحماية يسمح بالمنفذ 5060 ويسقط كل حزم RTP. الإشارات والوسائط تدفقان منفصلان، ولذلك يحتاج كل منهما إلى قواعد جدار حماية مستقلة. إذا كان هذا الفرق جديداً عليك، فاقرأ كيفية عمل المنافذ ومقابس الاستماع على Linux قبل فتح أي منفذ.

قلّص النطاق قبل فتحه. عشرون ألف منفذ أكبر بكثير مما يحتاج إليه نظام صغير. وبما أن كل مكالمة تحتاج إلى منفذين، فإن نطاقاً يتكون من مئتي منفذ يكفي لمئة مكالمة في الوقت نفسه.

[general]
rtpstart=10000
rtpend=10200

طبّق ذلك باستخدام sudo asterisk -rx "core reload".

هل تثبّت Asterisk أم FreePBX؟

Asterisk هو المحرك. تهيّئه باستخدام ملفات نصية في /etc/asterisk وتكتب dialplan بنفسك. أما FreePBX فهو واجهة ويب مكتوبة بلغة PHP وJavaScript، وتعمل فوق Asterisk، وتنشئ هذه الملفات نيابةً عنك، وتضيف وحدات للبريد الصوتي وقوائم انتظار المكالمات.

الفرق المهم عند استخدام VPS هو ملكية الخادم. اعتباراً من August 2026، يتوقع المثبّت الرسمي لـFreePBX 17 نظام Debian 12 أساسياً، ويثبّت Asterisk وخادم ويب وخادم قاعدة بيانات وPHP. إذا وجّهته إلى خادم يشغّل خدمات أخرى مسبقاً، فلن تحصل على نتيجة جيدة. خصّص لـ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

يُحفظ سجل التثبيت في /var/log/pbx/freepbx17-install.log، وهو أول مكان ينبغي التحقق منه عندما يتوقف البرنامج النصي مبكراً.

يتولى FreePBX إدارة ملفات الإعداد التي ينشئها. إذا عدّلت pjsip.conf يدوياً على خادم FreePBX، فسيختفي التعديل في المرة التالية التي تكتب فيها واجهة GUI ذلك الملف. يقرأ FreePBX ملفات منفصلة تحتوي على _custom في أسمائها للإعدادات المكتوبة يدوياً، ويترك هذه الملفات دون تعديل.

المقايضة الفعلية هي التالية. يمنحك FreePBX واجهة GUI، ويضع صفحة تسجيل دخول لنظام الهاتف على الإنترنت العام. لا يوفّر Asterisk الخام أي واجهة ويب، وكل إعداد فيه عبارة عن توجيه موثّق يمكنك قراءته في ملف والاحتفاظ به في git. إذا ثبّت FreePBX، فقيّد منفذ الويب على عنوانك الخاص أو صِل إليه عبر VPN، لأن واجهة إدارة PBX هدف يمكن الوصول منه مباشرةً إلى الأموال.

ملاحظة الإصدار، صحيحة اعتباراً من August 2026: الإصدار Asterisk 22 هو إصدار الدعم طويل الأمد الحالي، وقد نُشر في October 2024 ويتلقى إصلاحات أمنية حتى October 2028. الإصدار Asterisk 23 هو الإصدار القياسي. يتضمن Ubuntu 24.04 الإصدار Asterisk 20.6.0 في مستودع universe.

تثبيت Asterisk على Ubuntu 24.04

حزمة التوزيعة هي المسار الأسرع. تصححها Ubuntu، وتبدأ تلقائياً عبر systemd.

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

يتيح البناء من المصدر استخدام إصدار الدعم طويل الأمد الحالي بدلاً من ذلك.

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 تبعيات البناء اللازمة لتوزيعتك، بينما يطبع install_prereq test الأوامر التي سينفذها من دون إجراء أي تغييرات. يفتح make menuselect منتقي الوحدات، حيث يمكنك تفعيل codec_opus ضمن Codec Translators. شغّل make samples على تثبيت جديد فقط، لأنه يكتب إعدادات العينة في /etc/asterisk. يثبّت make config برنامج التهيئة في /etc/init.d/asterisk، ويتولى systemd تشغيله عبر طبقة التوافق مع SysV، لذلك يعمل sudo systemctl enable --now asterisk بعد ذلك.

بغض النظر عن المسار الذي اخترته، يربط sudo asterisk -rvvv بالـdaemon قيد التشغيل ويوفّر لك CLI. يؤدي تشغيل core show version هناك إلى طباعة ما ثبّتَه فعلياً.

إعداد SIP trunk وامتداد واحد

PJSIP هو مشغّل قناة SIP في Asterisk حالياً. يوجد إعدادُه في /etc/asterisk/pjsip.conf، وهو مبني من أقسام صغيرة محددة النوع تشير إلى بعضها بعضاً بالاسم. يمكن لأقسام من أنواع مختلفة أن تشترك في الاسم نفسه، ولذلك يُسمّى كل بلوك أدناه 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 رسالة REGISTER التي تُبلغ مزوّد الخدمة بمكان تسليم مكالماتك. ويُستخدم الكائن identify لمطابقة المكالمة الواردة من المزوّد مع نقطة النهاية هذه وفق عنوان المصدر. وعادةً ما ينشر المزوّد عدة عناوين لإدراجها هناك. تسجيل الخروج ونقطة النهاية كائنان منفصلان عمداً: الأول يُبلغ المزوّد بمكانك، والثاني يحدد ما يحدث للمكالمات.

يحتاج هاتف المكتب إلى ثلاثة كائنات إضافية.

[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 ضمن مسار الوسائط. إذا حذفته، فسيحاول Asterisk جعل نقطتي النهاية ترسلان RTP مباشرةً إلى بعضهما، ويفشل ذلك عندما يكون الهاتف خلف NAT (ترجمة عناوين الشبكة) على موجه منزلي. لا تجعل السر يطابق رقم الامتداد. يستخدم المثال الأساسي password=6001 للامتداد 6001 للحفاظ على وضوح المثال، وتجرّب أدوات الفحص هذا النمط تحديداً أولاً.

يحدد dialplan في /etc/asterisk/extensions.conf ما يُسمح لكل سياق بتنفيذه.

[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()

يشكل هذان السياقان حدّاً أمنياً. يتعامل from-trunk مع المكالمات الواردة من المزوّد، ولا يمكنه إلا رنين الامتداد 6001. ولا يمكنه الوصول إلى نمط _9X.، لذلك لا تستطيع مكالمة واردة من الخارج الاتصال مجدداً عبر trunk الخاص بك. إذا دمجت السياقين، فقد أنشأت مساراً نموذجياً للاحتيال على رسوم الاتصال: يتصل شخص غريب برقمك، ويجري dialplan اتصالاً خارجياً باستخدام حسابك، وتدفع أنت التكلفة.

طبّق الإعداد وتحقق منه.

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

يجب أن يعرض pjsip show registrations mytrunk بالحالة Registered. وتعني Rejected أن المزوّد رفض بيانات الاعتماد الخاصة بك. وتعني Unregistered أن طلب REGISTER لا يتلقى رداً، لذا افحص جدار الحماية بعد ذلك.

قواعد الجدار الناري لـSIP وRTP

تحتاج إشارات الاتصال والوسائط إلى معاملتين مختلفتين لأن مستوى المخاطر يختلف بينهما. قيّد المنفذ 5060 بالعناوين التي يستخدمها مزودك فعلياً وبالشبكات التي تتصل بها هواتفك.

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 بالقدر نفسه، لأن الوسائط تصل غالباً من عنوان مختلف عن عنوان الإشارات. اطلب من مزودك شبكات الوسائط الفرعية، وقيّد الوصول بها إذا كان ينشرها. اجعل النطاق كبيراً بالقدر الذي تحتاج إليه أكثر ساعاتك ازدحاماً فقط. تتناول دليل أساسيات جدار ufw الناري لـVPS السياسات الافتراضية وترتيب القواعد وبقية نموذج ufw.

تحقق من IPv6 أيضاً. إذا كانت IPV6=no مضبوطة في /etc/default/ufw، فلن يرشّح ufw حركة IPv6 إطلاقاً، ولذلك يمكن الوصول إلى daemon المرتبط بـ:: عبر IPv6 من دون تطبيق أي من القواعد السابقة. يشرح فتح المنافذ لـIPv6 باستخدام ufw أوجه الاختلاف بين عائلتي العناوين. يوفّر معظم المزودين أيضاً جداراً نارياً منفصلاً للشبكة في لوحة التحكم، ويُطبَّق ذلك الجدار قبل وصول الحزم إلى VPS، لذلك يجب فتح المنفذ في الموضعين.

هجمات التخمين على SIP والاحتيال على المكالمات ليست مشكلات اختيارية

بمجرد وضع المنفذ 5060 على عنوان عام، تبدأ عمليات الفحص. النمط ثابت: طلبات REGISTER وINVITE من عناوين مصدر متعددة، تحاول استخدام أرقام تحويلات شائعة مع أسرار شائعة. يسجّل Asterisk كل فشل، ويكون السطر بهذا الشكل.

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

السبب الذي يستدعي بذل جهد فعلي هو المال. يُستخدم التحويل المسروق لإجراء مكالمات دولية مرتفعة التكلفة، وغالباً إلى أرقام ذات تعرفة مرتفعة تدفع للمهاجم حصة من الإيراد. وتتحمل أنت الفاتورة لأن المكالمات استخدمت بيانات اعتمادك. تعمل هذه الهجمات بسرعة الآلة، وعادةً تستمر طوال الليل.

هناك ستة ضوابط إلزامية، وليست تحسينات أمنية اختيارية.

• لا تنشئ تحويلاً يكون سره رقمه نفسه أو كلمة قصيرة. أنشئ سراً باستخدام openssl rand -base64 24 والصقه.
• اترك المكالمات الواردة المجهولة معطّلة. يرفض PJSIP المكالمات غير المعرّفة افتراضياً، ولا يقبلها إلا إذا أنشأت نقطة نهاية باسم anonymous. لا تنشئ هذه النقطة.
• أبقِ سياق الـtrunk منفصلاً عن أي سياق يمكنه إجراء مكالمات صادرة، كما هو موضح أعلاه.
• قيّد إشارات الاتصال حسب عنوان المصدر، في ufw وكذلك في جدار الشبكة الناري لدى مزود الخدمة.
• عيّن سقفاً للإنفاق لدى مزود SIP trunk، وعطّل الوجهات الدولية التي لا تتصل بها مطلقاً. هذا هو الضابط الوحيد الذي يحدّ من الخسارة عندما تفشل الضوابط الأخرى.
• شغّل fail2ban لمراقبة سجل Asterisk.

يمكن لـAsterisk أيضاً إنشاء حدث أمني بعد تكرار الطلبات غير المطابقة من عنوان واحد. يأخذ قسم [global] من pjsip.conf القيمتين unidentified_request_count، وتكون قيمتها الافتراضية 5، وunidentified_request_period، وتكون قيمتها الافتراضية 5 ثوانٍ. معاً، تعنيان أن وصول خمسة طلبات غير مطابقة من عنوان واحد خلال خمس ثوانٍ ينشئ حدثاً أمنياً يمكن لـfail2ban التصرف بناءً عليه.

حظر أدوات الفحص باستخدام fail2ban

يأتي fail2ban مع سجن asterisk مكتوباً مسبقاً. يغطي المنفذين 5060 و5061، ويقرأ /var/log/asterisk/messages، والقيمة الافتراضية هي maxretry = 10. يظل السجن متوقفاً إلى أن تفعّله في /etc/fail2ban/jail.local.

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

sudo systemctl restart fail2ban
sudo fail2ban-client status asterisk

تعرض النتيجة السليمة ملف سجل السجن وعدد العناوين المحظورة حالياً. عند تعريض المنفذ 5060 للإنترنت، يتوقف هذا العدد عن كونه صفراً خلال يوم واحد. يطابق المرشح المرفق إشعارات No matching endpoint found المذكورة أعلاه، كما يطابق أسطر SecurityEvent المهيكلة في Asterisk. تُرسَل هذه الأحداث إلى قناة سجل منفصلة تكون معلّقة في /etc/asterisk/logger.conf، لذا فعّلها هناك وأضف الملف إلى logpath الخاص بالسجن إذا أردت تضمينها.

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

أعد تحميل مسجل الأحداث باستخدام sudo asterisk -rx "logger reload". يحتوي المرشح أيضاً على journalmatch لـ asterisk.service، لذلك يعمل backend الخاص بـjournal إذا كنت تفضّل عدم الاحتفاظ بملفات السجل. يتناول دليل fail2ban الخاص بـUbuntu 24.04 التثبيت، وبنية jail.local، وإلغاء حظر عنوان حظرته عن طريق الخطأ.

زمن الاستجابة واختيار برنامج الترميز على VPS بعيد

يحدّد الموقع الجغرافي زمن الاستجابة، ولا يمكنك إلغاءه بالإعدادات. توصي ITU-T G.114 بالحفاظ على زمن الاستجابة في اتجاه واحد دون 150 ms للمحادثات العادية، وتعدّ ما يصل إلى نحو 400 ms قابلاً للاستخدام. ينتقل الصوت من الهاتف إلى VPS ثم إلى مزوّد trunk، لذلك يضيف VPS الموجود في منطقة غير مناسبة زمن الرحلة ذهاباً وإياباً. ضع VPS بالقرب من الهواتف أو بالقرب من المزوّد. وعندما يتعارض الخياران، فضّل وضعه بالقرب من الهواتف، لأن هذا المسار يعمل عادةً عبر إنترنت المستهلكين حيث يكون jitter أسوأ.

يحدّد اختيار برنامج الترميز عرض النطاق لكل مكالمة. يرسل كل برنامج ترميز هنا حزمة كل 20 ms، أي 50 حزمة في الثانية. وتحمل كل حزمة 40 bytes من ترويسات IP وUDP وRTP إضافةً إلى حمولة الصوت.

[
  {
    "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 الإعداد الافتراضي في معظم trunk. تبلغ حمولته 64 kbps. ومع الترويسات، تستهلك المكالمة الجارية 80 kbps في كل اتجاه. يعمل Opus بمعدل 24 kbps عند 40 kbps، بينما يخفض G.729 المعدل إلى 24 kbps مقابل انخفاض جودة الصوت واستهلاك وقت CPU. هذه الأرقام ناتجة عن حساب الترويسات، وليست قياسات: معدل الحمولة مضافاً إليه 40 bytes لكل حزمة بمعدل 50 حزمة في الثانية. وتضيف تأطيرات Ethernet أو VLAN زيادةً صغيرة أخرى على السلك.

تستهلك عملية Transcoding موارد CPU. إذا كانت الهواتف وtrunk يستخدمان ulaw، فلا تسمح إلا بـulaw، وسيُمرّر Asterisk الصوت دون تعديل. يتحمل Opus الروابط الفاقدة جيداً، لكن إجراء Transcoding بين Opus وG.711 يحتاج إلى الوحدة الخارجية codec_opus، التي تختارها في make menuselect، وهي غير مبنية افتراضياً.

ما الذي يتعطل، والرسالة التي ستراها

تتصل المكالمة ولا يسمع أحد شيئاً. لا تصل حزم RTP. تحقّق من أن النطاق في rtp.conf هو النطاق الذي فتحته في جدار الحماية، ثم راقب الحزم باستخدام sudo tcpdump -ni any udp portrange 10000-10200 أثناء إجراء مكالمة. عدم وصول أي حزم يعني أن جدار الحماية لديك أو جدار الحماية الشبكي لدى مزود الخدمة يحجبها.

الصوت في اتجاه واحد فقط. يرسل أحد الطرفين حزم RTP إلى عنوان لا يمكنه استقبالها. هذه مشكلة عنوان وليست مشكلة منفذ. إذا كان عنوانك العام موجوداً مباشرة على واجهة VPS، فلا تحتاج إلى معالجة NAT. إذا منحك المزود عنواناً خاصاً لـVPS مع ربط عام واحد إلى واحد، فعيّن العنوان العام في transport وأدرج نطاقك الخاص في 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 في السجل. لم يطابق الطلب أي endpoint وفق عنوان IP أو اسم المستخدم. هذا أمر طبيعي إذا كان الطلب من أداة فحص، وسيتعامل معه fail2ban. أما إذا جاء من مزود الخدمة لديك، فهذا يعني أن قسم identify لا يتضمن العنوان الذي يتصل منه المزود بك.

حالة التسجيل هي Rejected. رفض مزود الخدمة بيانات الاعتماد الموجودة في قسم auth. شغّل pjsip set logger on في CLI، وراقب طلب REGISTER واحداً والاستجابة المقابلة له، ثم قارن client_uri وusername بالقيم التي أصدرها لك المزود.

لا يظهر شيء مفيد في السجل إطلاقاً. يكتب Asterisk مستوى notice وما فوقه في messages.log افتراضياً. ارفع مستوى التسجيل باستخدام core set verbose 4 وpjsip set logger on أثناء إعادة إنتاج المشكلة، ثم عطّل كليهما، لأن SIP logger يكتب كل حزمة.

قبل تعريضه للإنترنت

لا يشبه PBX بقية الخدمات التي تستضيفها بنفسك. تعطل تطبيق ويب يحرمك من صفحة. أما تعطل PBX فقد يراكم فاتورة هاتف خلال ساعات، بينما تكون نائماً. شغّله على VPS لا يستضيف أي شيء آخر، وقيّد المنفذ 5060 على عناوين معروفة، وأنشئ secret عشوائياً لكل extension، وضع حداً للإنفاق على حساب trunk. ويحتاج باقي الخادم إلى خط أساس الأمان نفسه المطلوب لأي خادم مكشوف، كما يوضّح هذا الاستعراض لمدى أمان استضافة VPS فعلياً.

FAQ

ما المنافذ التي أحتاج إلى فتحها لخادم VoIP مستضاف ذاتياً؟

المنفذ 5060 لإشارات SIP عبر UDP وTCP، والمنفذ 5061 إذا كنت تستخدم SIP عبر TLS، بالإضافة إلى نطاق من منافذ UDP لوسائط RTP. يستخدم نموذج Asterisk rtp.conf النطاق من 10000 إلى 20000، بينما النطاقات الافتراضية المضمّنة في البرنامج هي من 5000 إلى 31000. تستهلك كل مكالمة منفذين من النطاق، لذلك يتعامل نطاق مكوّن من مئتي منفذ مع مئة مكالمة متزامنة. افتح نطاق RTP عبر UDP، وقيّد المنفذ 5060 بعناوين مزوّد الخدمة وشبكاتك، بدلاً من تركه مفتوحاً للجميع.

هل أُثبّت Asterisk وحده أم أستخدم FreePBX؟

ثبّت Asterisk الخام عندما تريد تقليل سطح الهجوم والاحتفاظ بملفات إعداد يمكنك حفظها في git، وتكون مستعداً لكتابة dialplan. ثبّت FreePBX عندما تريد واجهة GUI لإدارة الامتدادات والبريد الصوتي وقوائم انتظار المكالمات. اعتباراً من August 2026، يتوقع مُثبّت FreePBX 17 جهاز Debian 12 قياسياً، ويثبّت Asterisk وخادم ويب وخادم قاعدة بيانات وPHP، لذلك خصّص له VPS مستقلاً. يعيد FreePBX إنشاء ملفات الإعداد التي يديرها، لذلك يجب وضع التعديلات اليدوية في ملفات _custom الخاصة به.

لماذا لا يوجد صوت بعد اتصال المكالمة؟

عملت الإشارات، لكن الوسائط لم تعمل. أنشأ SIP المكالمة على المنفذ 5060، بينما يمر الصوت عبر تدفق UDP منفصل إلى منفذ ضمن نطاق RTP، وتقوم جهة ما بحظره. تحقّق من أن النطاق في rtp.conf يطابق النطاق المفتوح في جدارك الناري، وتحقّق أيضاً من جدار الشبكة الناري لدى مزوّد الخدمة ومن الجدار الموجود على الخادم. شغّل sudo tcpdump -ni any udp portrange 10000-10200 أثناء المكالمة؛ فإذا لم تظهر أي حزم، فهذا يعني أنها تُحظر قبل وصولها.

كيف أوقف هجمات التخمين بالقوة الغاشمة على SIP والاحتيال في رسوم الاتصالات؟

امنح كل امتداد سراً عشوائياً طويلاً، ولا تستخدم سراً يطابق رقم الامتداد. افصل السياق المستخدم بواسطة trunk عن أي سياق يمكنه إجراء مكالمات صادرة، حتى لا تتمكن مكالمة واردة من إجراء مكالمة صادرة على حسابك. قيّد المنفذ 5060 بعناوين مزوّد الخدمة. فعّل jail ‏asterisk في fail2ban؛ إذ يقرأ /var/log/asterisk/messages ويحظر العناوين التي تنتج No matching endpoint found من حالات الفشل. بعد ذلك، عيّن حداً أقصى للإنفاق واحظر الوجهات الدولية غير المستخدمة لدى مزوّد الخدمة، لأن هذا هو الإجراء الوحيد الذي يحدّ من الخسارة إذا فشلت بقية الضوابط.

هل يؤثر وجود VPS في منطقة بعيدة سلباً في جودة المكالمات؟

نعم، لأن الصوت يمر في مسارين: من الهاتف إلى VPS، ثم من VPS إلى مزوّد trunk. توصي ITU-T G.114 بزمن تأخير أحادي الاتجاه يقل عن 150 ms، وقد يستهلك VPS في موقع سيئ معظم هذا الحد بسبب المسافة وحدها. اختر منطقة قريبة من الهواتف، لأن هذا المسار يمر عادةً عبر إنترنت المستهلكين حيث يكون التذبذب أعلى. لا يعالج اختيار برنامج الترميز التأخير، بل يغيّر عرض النطاق فقط؛ لذلك يوفّر G.729 البايتات، لكنه لن ينقذ مساراً بزمن تأخير يبلغ 200 ms.