چرا صدای VoIP در Issabel قطع و وصل می‌شود؟

چرا صدای VoIP در Issabel قطع و وصل می‌شود؟ تنظیم MikroTik با VLAN، QoS و اولویت تماس

وقتی کاربر می‌گوید «صدای تلفن VoIP قطع و وصل می‌شود»، اولین مظنون معمولاً Issabel یا SIP Provider است. اما در بسیاری از شبکه‌ها مشکل اصلی نه PBX است و نه تلفن؛ بلکه Packet Loss، Jitter، Congestion، Bufferbloat، Routing، NAT یا پیکربندی اشتباه MikroTik کیفیت تماس را خراب کرده است.

VoIP برخلاف Download فایل، تحمل زیادی در برابر تأخیر و از دست رفتن Packet ندارد. اگر چند Packet مربوط به یک فایل دیر برسند، TCP می‌تواند آن‌ها را دوباره ارسال کند. اما در مکالمه زنده، صدایی که دیر برسد دیگر ارزش چندانی ندارد.

به همین دلیل ممکن است شبکه از دید کاربران «اینترنت داشته باشد»، Speedtest نیز نتیجه خوبی نشان دهد، اما هنگام Upload یک Backup یا دانلود حجیم صدای مکالمه شروع به بریده‌شدن کند.

راه‌حل حرفه‌ای فقط ساخت یک Queue با نام VoIP نیست. ابتدا باید بفهمیم RTP از چه مسیری عبور می‌کند، Bottleneck کجاست، آیا Voice VLAN داریم، DSCP حفظ می‌شود یا نه و FastTrack چه رفتاری با Queueها دارد.

Issabel و MikroTik در یک شبکه VoIP چه نقشی دارند؟

Issabel نقش IP PBX را بر عهده دارد. Extensionها، SIP Trunk، تماس ورودی و خروجی، IVR، Queue، Recording و سایر قابلیت‌های تلفنی در این بخش مدیریت می‌شوند.

MikroTik در مقابل مسئول لایه شبکه است:

• Routing
• NAT
• Firewall
• VLAN
• QoS
• Multi-WAN
• VPN
• Monitoring

معماری ساده یک شبکه سازمانی می‌تواند به شکل زیر باشد:

Internet / SIP Provider
 |
 MikroTik
 |
 Managed Switch
 |
 +------+------+-----------+
 | | |
VLAN 10 VLAN 20 VLAN 30
DATA VOICE SERVERS
 | | |
PC Users IP Phones Issabel

در چنین طراحی‌ای هر بخش Policy مستقل خود را دارد.

برای مشاهده نقش VLAN، Firewall و مدیریت پهنای باند در شبکه شرکت می‌توانید مقاله چرا MikroTik برای شبکه‌های SMB گزینه‌ای جدی است؟ را مطالعه کنید.

SIP و RTP یک چیز نیستند

برای عیب‌یابی VoIP ابتدا باید Signaling و Media را از هم جدا کنیم.

SIP

SIP معمولاً مسئول Signaling تماس است:

• Register
• Invite
• Ringing
• Answer
• Bye

RTP

صدای واقعی مکالمه معمولاً توسط RTP منتقل می‌شود.

SIP:
"می‌خواهم با داخلی 202 تماس بگیرم"

RTP:
صدای واقعی مکالمه

به همین دلیل ممکن است تماس کاملاً برقرار شود ولی صدا وجود نداشته باشد.

در چنین حالتی SIP کار کرده است اما مسیر RTP مشکل دارد.

نوع مشکل صدا سرنخ بسیار مهمی است

سه دشمن اصلی کیفیت VoIP؛ Delay، Jitter و Packet Loss

Latency

Latency مدت زمانی است که Packet برای رسیدن از یک سمت به سمت دیگر نیاز دارد.

در مکالمه تعاملی بهتر است One-Way Delay تا حد امکان پایین بماند و حدود 150 میلی‌ثانیه یک هدف شناخته‌شده برای تجربه مناسب Voice محسوب می‌شود.

Jitter

Jitter یعنی Packetهای RTP با فاصله زمانی یکنواخت به مقصد نمی‌رسند.

برای مثال:

Packet 1 → 20ms
Packet 2 → 21ms
Packet 3 → 85ms
Packet 4 → 25ms

این نوسان می‌تواند باعث صدای شکسته، رباتی یا Drop شود.

Packet Loss

RTP Real-Time است و Packet دیررس یا ازدست‌رفته همیشه قابل بازیابی مفید نیست.

بنابراین حتی Packet Loss نسبتاً کم می‌تواند بسته به Codec و شرایط تماس قابل شنیدن باشد.

Bufferbloat؛ وقتی اینترنت سریع است ولی تماس خراب می‌شود

یکی از رایج‌ترین سناریوها چنین است:

• Speedtest خوب است.
• Ping در حالت Idle خوب است.
• تماس برقرار می‌شود.
• اما با شروع Upload یا Backup صدا خراب می‌شود.

در این حالت احتمال Bufferbloat و Congestion بالا است.

فرض کنید Upload اینترنت 20Mbps است.

یک Backup تمام 20Mbps را اشغال می‌کند و Packetهای کوچک RTP نیز مجبور می‌شوند پشت حجم زیادی از Packetهای Data منتظر بمانند.

Backup Packet
Backup Packet
Backup Packet
Backup Packet
RTP Voice Packet
Backup Packet
Backup Packet

اگر Router بتواند Queue را کنترل کند، می‌توان Voice را زودتر ارسال کرد:

RTP Voice
RTP Voice
Data
Data
Data

این همان جایی است که QoS ارزش واقعی ایجاد می‌کند.

چرا برای VoIP از Voice VLAN استفاده کنیم؟

Voice VLAN در درجه اول ابزار Segmentation است.

برای مثال:

VLAN 10 = Users
VLAN 20 = IP Phones
VLAN 30 = Servers / Issabel
VLAN 40 = CCTV
VLAN 99 = Management

مزایای Voice VLAN:

• تفکیک Broadcast Domain
• Firewall Policy مستقل
• عیب‌یابی ساده‌تر
• امکان QoS براساس Subnet
• کاهش دسترسی Phoneها به Data Network
• آدرس‌دهی و DHCP مستقل
• مانیتورینگ ساده‌تر Traffic تلفنی

نمونه ساخت Voice VLAN در MikroTik

فرض کنیم:

• VLAN ID: 20
• Voice Network: 192.168.20.0/24
• MikroTik Gateway: 192.168.20.1
• ether2: Trunk به Managed Switch
• ether3: نمونه Access Port تلفن

/interface bridge
add name=bridge-core vlan-filtering=no

/interface bridge port
add bridge=bridge-core interface=ether2 \
 frame-types=admit-only-vlan-tagged \
 ingress-filtering=yes

add bridge=bridge-core interface=ether3 \
 pvid=20 \
 frame-types=admit-only-untagged-and-priority-tagged \
 ingress-filtering=yes

/interface bridge vlan
add bridge=bridge-core vlan-ids=20 \
 tagged=bridge-core,ether2 \
 untagged=ether3

/interface vlan
add name=vlan20-voice \
 interface=bridge-core \
 vlan-id=20

/ip address
add address=192.168.20.1/24 \
 interface=vlan20-voice

/interface bridge
set bridge-core vlan-filtering=yes

در شبکه واقعی معمولاً Managed Switch پورت‌های Voice را مدیریت می‌کند و MikroTik فقط Trunk را دریافت می‌کند.

اگر IP Phone دارای PC Port باشد، طراحی Tagged Voice و Untagged Data باید روی Switch و خود Phone هماهنگ شود.

QoS برای VoIP دقیقاً چه کاری می‌کند؟

QoS سه مفهوم اصلی دارد:

Classification

تشخیص اینکه Packet متعلق به چه سرویسی است.

Marking

علامت‌گذاری Traffic با DSCP، Packet Mark یا Priority.

Scheduling / Shaping

تصمیم‌گیری درباره اینکه هنگام Congestion کدام Packet زودتر ارسال شود.

اگر فقط Packet را Mark کنیم ولی هیچ Queue یا دستگاه پایین‌دستی به Mark توجه نکند، اولویتی در عمل ایجاد نشده است.

DSCP چیست و چرا برای VoIP مهم است؟

DSCP فیلدی در IP Header است که می‌تواند کلاس Traffic را مشخص کند.

برای Voice دو مقدار بسیار رایج عبارت‌اند از:

RTP Audio از SIP Signaling حساس‌تر است و به همین دلیل معمولاً کلاس بالاتری دریافت می‌کند.

تنظیم QoS در Issabel / Asterisk

Asterisk قابلیت تنظیم ToS/DSCP و CoS برای Signaling و Media را دارد.

در PJSIP منطق Configuration به‌صورت کلی چنین است:

; SIP transport
tos=cs3
cos=3

; RTP Audio endpoint
tos_audio=ef
cos_audio=5

هدف این است که RTP خروجی از PBX با EF و SIP Signaling با CS3 وارد شبکه شود.

بررسی DSCP روی MikroTik

RouterOS می‌تواند DSCP را Match کند.

برای نمونه می‌توان Packetهای EF را Mark کرد:

/ip firewall mangle
add chain=forward \
 dscp=46 \
 action=mark-packet \
 new-packet-mark=voip-rtp \
 passthrough=no \
 comment="VoIP RTP - DSCP EF"

برای SIP با CS3:

/ip firewall mangle
add chain=forward \
 dscp=24 \
 action=mark-packet \
 new-packet-mark=voip-signaling \
 passthrough=no \
 comment="SIP Signaling - DSCP CS3"

اگر Phone یا Issabel DSCP ارسال نمی‌کند چه کنیم؟

می‌توان Traffic را براساس:

• PBX IP
• Voice VLAN
• SIP Port
• RTP Port Range

شناسایی و سپس DSCP را در MikroTik تنظیم کرد.

اما ابتدا باید Port Range واقعی سیستم را پیدا کنید.

RTP Range را از تنظیمات Asterisk/Issabel بررسی کنید و به عددی که در یک آموزش اینترنتی نوشته شده اعتماد نکنید.

قبل از QoS مسیر واقعی RTP را پیدا کنید

این مرحله بسیار مهم است.

در یک تماس ممکن است Media چنین باشد:

Phone
 |
Issabel
 |
SIP Provider

اما در سناریوی دیگر با Direct Media:

Phone A
 |
Direct RTP
 |
Phone B

یا بین شعب:

Phone
 |
Branch Router
 |
VPN
 |
PBX / Remote Phone

اگر QoS را فقط برای IP سرور Issabel ساخته باشید ولی RTP مستقیماً میان Endpointها عبور کند، Queue شما Voice واقعی را Match نخواهد کرد.

FastTrack؛ چرا Queue ساخته‌ایم ولی VoIP از آن عبور نمی‌کند؟

FastTrack برای افزایش Performance RouterOS بسیار مفید است، اما Traffic FastTracked می‌تواند بعضی Facilityهای RouterOS را دور بزند.

یکی از مهم‌ترین موارد:

• Simple Queue
• Queue Tree با Parent سراسری
• بخشی از Mangle Processing
• IP Accounting

FastTrackهای موجود را بررسی کنید:

/ip firewall filter
print detail where action=fasttrack-connection

تست تشخیصی

در یک Maintenance Window می‌توانید FastTrack را موقتاً غیرفعال کنید:

/ip firewall filter
disable [find action=fasttrack-connection]

سپس:

• تماس برقرار کنید.
• WAN را تحت Load قرار دهید.
• Queue Counter را بررسی کنید.
• کیفیت Audio را مقایسه کنید.

اگر رفتار QoS اصلاح شد، راه‌حل نهایی لزوماً حذف همیشگی FastTrack نیست.

بهتر است Traffic حساس VoIP از FastTrack مستثنا شود و Traffic عادی همچنان بتواند از مزیت آن استفاده کند.

این موضوع در مقاله اشتباهات خطرناک در تنظیمات MikroTik نیز اهمیت زیادی دارد.

نمونه طراحی Simple Queue برای VoIP

فرض کنیم:

• Internet Download واقعی: 100Mbps
• Internet Upload واقعی: 20Mbps
• Voice VLAN: 192.168.20.0/24
• Issabel: 192.168.30.10

بهتر است Shaper کمی پایین‌تر از ظرفیت واقعی پایدار لینک تنظیم شود تا Queue در MikroTik ایجاد شود، نه در مودم یا ISP.

برای مثال:

Actual:
Download = 100M
Upload = 20M

Example Shaping:
Download = 95M
Upload = 18M

نمونه مفهومی Parent Queue:

/queue simple
add name=WAN-TOTAL \
 target=192.168.0.0/16 \
 max-limit=18M/95M

سپس Voice را Child با Priority بالا قرار می‌دهیم:

/queue simple
add name=VOICE-PHONES \
 parent=WAN-TOTAL \
 target=192.168.20.0/24 \
 priority=1/1 \
 limit-at=<VOICE-CIR-UP>/<VOICE-CIR-DOWN> \
 max-limit=18M/95M

اگر Media از Issabel عبور می‌کند:

/queue simple
add name=ISSABEL \
 parent=WAN-TOTAL \
 target=192.168.30.10/32 \
 priority=1/1 \
 limit-at=<VOICE-CIR-UP>/<VOICE-CIR-DOWN> \
 max-limit=18M/95M

همچنین اگر Traffic موردنظر FastTracked باشد Simple Queue نمی‌تواند مطابق انتظار عمل کند.

CAKE و DiffServ؛ روش مدرن‌تر برای مدیریت لینک

RouterOS از Queue Type نوع CAKE نیز پشتیبانی می‌کند.

CAKE علاوه بر Shaping و مدیریت Bufferbloat می‌تواند براساس DiffServ Traffic را در کلاس‌های مختلف قرار دهد.

در حالت‌های DiffServ، Packet دارای EF در کلاس Voice قرار می‌گیرد.

بنابراین اگر:

1. Issabel و Phoneها DSCP صحیح ایجاد کنند،
2. Marking در مسیر حفظ شود،
3. CAKE روی Bottleneck صحیح اعمال شود،

می‌توان طراحی QoS را در بعضی شبکه‌ها ساده‌تر کرد.

SIP ALG یا SIP Helper در MikroTik؛ خاموش کنیم یا نه؟

RouterOS دارای SIP NAT Helper است.

وضعیت آن را می‌توانید بررسی کنید:

/ip firewall service-port
print where name=sip

SIP Helper می‌تواند در بعضی NAT Scenarioها اطلاعات SIP را بررسی و برای Media Mapping کمک کند.

اما در برخی معماری‌ها، مخصوصاً زمانی که:

• PBX خودش NAT را مدیریت می‌کند،
• SBC وجود دارد،
• SIP TLS استفاده می‌شود،
• Provider رفتار NAT خاصی دارد،

ممکن است نیاز باشد رفتار Helper در عیب‌یابی بررسی شود.

برای تست

/ip firewall service-port
disable sip

چرا صدای VoIP یک‌طرفه می‌شود؟

One-Way Audio را نباید با Jitter اشتباه گرفت.

اگر یک طرف صدای طرف مقابل را می‌شنود ولی مسیر عکس صدا ندارد، اولین بخش‌هایی که باید بررسی شوند عبارت‌اند از:

• SDP
• Advertised IP
• NAT
• RTP Port Range
• Firewall
• Route برگشت
• SIP Helper
• Multi-WAN

مثلاً Issabel ممکن است در SDP آدرس Private را به Provider اعلام کند:

192.168.30.10

در حالی که Provider باید Public IP یا NAT Mapping صحیح را ببیند.

در این شرایط تماس ممکن است Ring شود ولی Media یک‌طرفه باشد.

VoIP در شبکه Multi-WAN؛ Session Symmetry را فراموش نکنید

اگر شرکت دو ISP دارد، طراحی VoIP حساس‌تر می‌شود.

سناریوی مشکل:

SIP Request
Issabel → ISP1 → Provider

RTP Reply
Provider → ISP1 → MikroTik

ولی پاسخ Router:
MikroTik → ISP2

Asymmetric Routing می‌تواند باعث:

• One-Way Audio
• Registration Failure
• قطع تماس
• NAT Mapping ناپایدار

شود.

برای SIP Trunk معمولاً بهتر است Session مربوط به Provider مسیر WAN قابل پیش‌بینی داشته باشد.

Failover نیز باید آزمایش شود

اگر ISP اصلی قطع شود، فقط Ping گرفتن از اینترنت Backup کافی نیست.

باید بررسی کنید:

• SIP Trunk دوباره Register می‌شود؟
• Provider Public IP جدید را قبول می‌کند؟
• Inbound Route همچنان کار می‌کند؟
• DNS به‌روز می‌شود؟
• Firewall روی WAN دوم صحیح است؟

VoIP روی Wi-Fi؛ QoS روتر همه مشکلات را حل نمی‌کند

اگر IP Phone یا Softphone از Wi-Fi استفاده می‌کند، مشکلات RF نیز وارد معادله می‌شوند.

• Interference
• ضعف Signal
• Roaming
• Channel Utilization
• Hidden Node
• Retransmission

اگر Packet قبل از رسیدن به Router روی Wi-Fi از دست برود، بهترین Queue MikroTik هم نمی‌تواند آن را بازیابی کند.

VoIP میان شعب روی VPN

یکی از کاربردهای متداول Issabel، استفاده از Extensionهای شعب مختلف است.

Branch A Phones
 |
 MikroTik A
 |
 VPN Tunnel
 |
 MikroTik HQ
 |
 Issabel

در این حالت علاوه بر QoS باید موارد زیر بررسی شوند:

• WAN هر دو شعبه
• Latency Tunnel
• Packet Loss
• MTU
• Encryption Load
• CPU Router
• Routing

اگر Voice VLAN از طریق VPN منتقل می‌شود، Policy QoS باید در هر Bottleneck مرتبط بررسی شود.

برای طراحی ارتباط شعب می‌توانید مقاله اتصال امن شعب با WireGuard را مطالعه کنید.

اگر Issabel مجازی است، Hypervisor را هم بررسی کنید

در بسیاری از شرکت‌ها Issabel داخل VMware، Proxmox، KVM یا Hyper-V اجرا می‌شود.

در این حالت مشکل Audio ممکن است از Network خارج نباشد.

موارد زیر را بررسی کنید:

• CPU Ready / CPU Steal
• کمبود RAM
• Storage Latency
• Oversubscription Hypervisor
• Virtual NIC
• vSwitch Configuration
• VLAN Trunk

برای آشنایی با این معماری مقاله مجازی‌سازی سخت‌افزاری چیست؟ را مطالعه کنید.

فرایند درست عیب‌یابی صدای VoIP

مرحله اول: یک تماس داخلی برقرار کنید

بین دو Extension در همان LAN تماس بگیرید.

اگر تماس داخلی نیز مشکل دارد، هنوز سراغ ISP نروید.

بررسی کنید:

• Switch
• VLAN
• PBX
• Phone
• کابل
• Wi-Fi

مرحله دوم: تماس خارجی را بدون Load تست کنید

اگر تماس خارجی در حالت Idle خوب است، احتمال NAT پایه کمتر می‌شود.

مرحله سوم: WAN را تحت Load قرار دهید

در هنگام تماس یک Upload یا Download سنگین ایجاد کنید.

هم‌زمان Ping بگیرید.

اگر Latency ناگهان چند برابر می‌شود و صدا خراب می‌شود، Bottleneck و Bufferbloat مظنون جدی هستند.

مرحله چهارم: مسیر RTP را پیدا کنید

مشخص کنید RTP:

• از PBX عبور می‌کند؟
• بین Endpointها Direct است؟
• از VPN عبور می‌کند؟
• از کدام WAN خارج می‌شود؟

مرحله پنجم: Packet Loss را محلی‌سازی کنید

به ترتیب:

Phone → Switch
Switch → MikroTik
MikroTik → ISP Gateway
ISP → SIP Provider

را بررسی کنید.

ابزارهای MikroTik برای عیب‌یابی VoIP

Ping

/ping 1.1.1.1 interval=100ms count=200

Ping به SIP Provider

/ping <SIP-PROVIDER-IP> \
 interval=100ms \
 count=200

Torch

/tool torch interface=<WAN-INTERFACE>

Torch برای مشاهده Traffic، IP، Protocol و Port بسیار مفید است.

Interface Errors

/interface ethernet print stats

به مواردی مانند:

• FCS Error
• Drop
• Link Down

توجه کنید.

CPU

/system resource print
/tool profile

Queue Statistics

/queue simple print stats
/queue tree print stats

اگر Queue Voice صفر Packet دارد، Classification شما احتمالاً اشتباه است یا Traffic آن مسیر را طی نمی‌کند.

FastTrack

/ip firewall filter
print stats where action=fasttrack-connection

ابزارهای مفید Issabel / Asterisk

روی سرور Issabel وارد Asterisk CLI شوید:

asterisk -rvvv

در محیط PJSIP

pjsip show endpoints
pjsip show contacts
pjsip set logger on

برای مشاهده RTP در زمان Troubleshooting:

rtp set debug on

یک Test Matrix ساده برای پیدا کردن مشکل

اشتباهات رایج MikroTik در شبکه Issabel

۱. ایجاد Voice VLAN ولی نداشتن QoS

Segmentation انجام شده اما Congestion همچنان وجود دارد.

۲. QoS روی سرعت اسمی اینترنت

ISP قرارداد 100Mbps داده ولی لینک واقعی در Peak فقط 82Mbps ظرفیت دارد. اگر Queue روی 100Mbps باشد، Bottleneck قبل از Router ایجاد می‌شود.

۳. Priority دادن به SIP ولی فراموش‌کردن RTP

SIP فقط Signaling است. Audio اصلی RTP است.

۴. اولویت‌دادن به تمام UDP

DNS، VPN، Gaming، QUIC و بسیاری از Protocolها نیز UDP هستند.

UDP مساوی VoIP نیست.

۵. Queue صحیح ولی FastTrack فعال

Traffic از Queue موردنظر عبور نمی‌کند.

۶. بازکردن تمام RTP روی اینترنت

Firewall باید فقط Traffic موردنیاز را براساس معماری و Provider مجاز کند.

۷. تصور اینکه QoS مشکل ISP را حل می‌کند

اگر Packet Loss داخل شبکه Provider اتفاق می‌افتد، Queue داخلی شرکت نمی‌تواند Packet ازدست‌رفته را بازیابی کند.

۸. نادیده‌گرفتن Switch

Port Error، Loop، Duplex Problem یا VLAN اشتباه قبل از رسیدن Packet به MikroTik کیفیت تماس را خراب می‌کند.

۹. اجرای Issabel روی VM Overloaded

اگر PBX CPU Scheduling مناسبی نداشته باشد مشکل در خود Virtualization Layer ایجاد می‌شود.

۱۰. ایجاد QoS بدون Baseline

اگر قبل از تغییر مقدار Packet Loss، Ping و Queue Stats ثبت نشده باشد، بعداً نمی‌توان اثربخشی تغییر را اندازه گرفت.

چک‌لیست طراحی MikroTik برای Issabel و VoIP

1. شبکه Voice VLAN مستقل دارد.
2. Voice VLAN از Data VLAN تفکیک شده است.
3. Issabel IP ثابت دارد.
4. Gateway و DNS تلفن‌ها صحیح هستند.
5. Managed Switch VLANها را درست عبور می‌دهد.
6. Trunk و Access Portها مستند شده‌اند.
7. SIP Signaling و RTP از هم تفکیک شده‌اند.
8. RTP Port Range واقعی Issabel مشخص است.
9. مسیر واقعی RTP مشخص شده است.
10. DSCP روی RTP بررسی شده است.
11. RTP در صورت امکان EF دریافت می‌کند.
12. SIP Signaling در صورت نیاز CS3 دریافت می‌کند.
13. Queue روی Bottleneck واقعی اجرا می‌شود.
14. سرعت Shaper براساس ظرفیت واقعی لینک تنظیم شده است.
15. Voice دارای CIR مناسب است.
16. Voice Priority بالاتر از Bulk Traffic است.
17. FastTrack با طراحی QoS سازگار است.
18. SIP Helper بررسی شده است.
19. NAT و Public IP Issabel صحیح هستند.
20. Multi-WAN دارای Session Symmetry است.
21. Failover SIP Trunk آزمایش شده است.
22. Firewall RTP بیش از حد باز نیست.
23. Packet Loss داخل LAN وجود ندارد.
24. Interface Error صفر یا قابل قبول است.
25. Router CPU در Peak ظرفیت آزاد دارد.
26. Issabel CPU و RAM بررسی شده‌اند.
27. اگر Issabel VM است Hypervisor بررسی شده است.
28. اگر Phone روی Wi-Fi است RF بررسی شده است.
29. Ping Under Load اندازه‌گیری شده است.
30. Quality قبل و بعد از QoS مقایسه شده است.

طراحی شبکه Issabel و VoIP با MikroTik

کیفیت VoIP فقط با تنظیم Issabel یا خرید یک Router قوی‌تر تضمین نمی‌شود. Phone، Switch، VLAN، Router، WAN، SIP Provider و خود PBX بخشی از یک زنجیره واحد هستند.

گروه فناوری ارتباطات پندار بیستون در حوزه MikroTik، زیرساخت شبکه و طراحی شبکه‌های سازمانی فعالیت می‌کند و برای انتخاب تجهیزات یا بررسی سناریوی VoIP می‌توان مشخصات شبکه را در اختیار کارشناسان قرار داد.

برای تحلیل دقیق‌تر بهتر است اطلاعات زیر آماده باشند:

• مدل MikroTik
• نسخه RouterOS
• مدل Switchها
• تعداد IP Phoneها
• تعداد تماس هم‌زمان
• نسخه Issabel/Asterisk
• نوع SIP Trunk
• سرعت Download و Upload
• تعداد WANها
• Voice VLAN
• RTP Range
• QoS فعلی
• وضعیت FastTrack
• نحوه استقرار Issabel؛ فیزیکی یا VM

سؤالات متداول درباره MikroTik، Issabel و VoIP

چرا صدای VoIP قطع و وصل می‌شود؟

Packet Loss، Jitter، Congestion، Bufferbloat، مشکلات Wi-Fi، Interface Error، CPU بالا و مسیر ناپایدار WAN از دلایل مهم هستند.

آیا MikroTik برای Issabel مناسب است؟

بله. RouterOS قابلیت‌های موردنیاز شبکه VoIP مانند VLAN، Routing، Firewall، QoS، DSCP، Queue، VPN و Multi-WAN را ارائه می‌کند؛ اما Configuration صحیح اهمیت زیادی دارد.

Voice VLAN چیست؟

VLAN مستقلی است که IP Phoneها و Traffic تلفنی را از شبکه Data جدا می‌کند و امکان اعمال Policy و QoS مستقل را فراهم می‌سازد.

آیا Voice VLAN کیفیت صدا را بهتر می‌کند؟

VLAN به‌تنهایی اولویت پهنای باند ایجاد نمی‌کند. مزیت اصلی آن Segmentation و امکان اعمال Policy مستقل است. برای Congestion همچنان QoS لازم است.

QoS در MikroTik چه کاری برای VoIP انجام می‌دهد؟

هنگام رقابت Voice و Data بر سر یک Bottleneck، QoS می‌تواند Traffic Voice را شناسایی کرده و ارسال آن را نسبت به Traffic کم‌اهمیت‌تر در اولویت قرار دهد.

DSCP مناسب RTP چیست؟

EF با DSCP 46 یکی از Markingهای استاندارد و پیشنهادی برای Audio Real-Time است.

DSCP مناسب SIP چیست؟

CS3 با DSCP 24 برای Signaling قابل استفاده است.

آیا SIP از RTP مهم‌تر است؟

هر دو لازم هستند، اما کیفیت Audio مستقیماً به RTP وابسته است. اولویت‌دادن فقط به SIP مشکل Jitter و Packet Loss صوت را حل نمی‌کند.

چرا Queue MikroTik کار نمی‌کند؟

FastTrack، Packet Mark اشتباه، Target نادرست، Parent اشتباه یا این واقعیت که RTP از مسیر دیگری عبور می‌کند از دلایل رایج هستند.

آیا FastTrack برای VoIP بد است؟

FastTrack ذاتاً بد نیست، اما می‌تواند بعضی Queueها و مراحل پردازش را دور بزند. طراحی QoS باید با FastTrack هماهنگ شود.

آیا برای تست FastTrack را خاموش کنیم؟

در یک Maintenance Window می‌توان موقتاً FastTrack را غیرفعال و رفتار Queue و تماس را مقایسه کرد. در طراحی نهایی معمولاً Exception دقیق بهتر از حذف غیرضروری است.

SIP ALG را خاموش کنیم؟

به‌صورت مطلق نمی‌توان چنین توصیه‌ای کرد. MikroTik دارای SIP Helper است. در مشکلات NAT و One-Way Audio باید رفتار آن بررسی و در صورت نیاز آزمایشی غیرفعال شود.

One-Way Audio چرا اتفاق می‌افتد؟

معمولاً NAT، Firewall، RTP Port، SDP Address یا Route برگشت از مهم‌ترین مواردی هستند که باید بررسی شوند.

چرا تماس فقط هنگام Upload خراب می‌شود؟

این رفتار معمولاً نشانه Congestion یا Bufferbloat در Upload است و Shaping/QoS روی Uplink باید بررسی شود.

آیا سرعت اینترنت بیشتر مشکل را حل می‌کند؟

ممکن است احتمال Congestion را کاهش دهد، اما اگر Queue، Packet Loss، WAN یا LAN مشکل داشته باشند افزایش Bandwidth به‌تنهایی تضمین‌کننده کیفیت نیست.

آیا Ping خوب یعنی VoIP خوب است؟

خیر. Average Latency تنها یک معیار است. Jitter، Packet Loss و رفتار Latency در زمان Load نیز باید بررسی شوند.

Latency مناسب VoIP چقدر است؟

در طراحی Voice Interactive بهتر است One-Way Delay تا حد امکان پایین بماند و حدود 150 میلی‌ثانیه یا کمتر هدف مناسبی برای بسیاری از مکالمات محسوب می‌شود.

آیا تلفن‌های VoIP را روی Wi-Fi قرار دهیم؟

ممکن است، اما کیفیت RF، Roaming و Interference اهمیت زیادی پیدا می‌کنند. برای تلفن ثابت، Ethernet معمولاً رفتار قابل پیش‌بینی‌تری دارد.

برای Issabel مجازی چه چیزی را بررسی کنیم؟

CPU، RAM، Storage Latency، Hypervisor Load، Virtual NIC و VLAN/vSwitch باید در کنار شبکه فیزیکی بررسی شوند.

آیا QoS می‌تواند Packet Loss ISP را حل کند؟

خیر. QoS می‌تواند Congestion روی Bottleneck تحت کنترل شما را مدیریت کند، اما Packetی را که در شبکه Provider از دست رفته است بازسازی نمی‌کند.

چگونه بفهمیم مشکل از MikroTik است یا Issabel؟

با Test Matrix شروع کنید: تماس داخلی، تماس خارجی Idle، تماس خارجی Under Load، مشاهده RTP، Interface Stats و سپس بررسی SIP/RTP در Asterisk. تغییر چند بخش به‌صورت هم‌زمان عیب‌یابی را دشوار می‌کند.

جمع‌بندی؛ کیفیت VoIP با یک Queue جادویی حل نمی‌شود

قطع و وصل شدن صدای VoIP یک علامت است، نه یک Diagnosis.

اگر تماس هنگام اشباع WAN خراب می‌شود، Queue و QoS باید بررسی شوند. اگر فقط یک سمت صدا وجود دارد، NAT و RTP در اولویت عیب‌یابی هستند. اگر تماس داخلی نیز مشکل دارد، ISP تقریباً از معادله خارج می‌شود و باید LAN، Phone و Issabel بررسی شوند.

یک طراحی مناسب MikroTik برای Issabel معمولاً چند اصل دارد:

1. Phoneها در Voice VLAN مشخص قرار می‌گیرند.
2. Issabel و Server Network از کاربران تفکیک می‌شوند.
3. RTP و SIP به‌درستی شناسایی می‌شوند.
4. RTP Audio در صورت امکان EF Marking دارد.
5. Bottleneck اینترنت تحت کنترل Queue Router قرار می‌گیرد.
6. Voice هنگام Congestion Priority بالاتری دریافت می‌کند.
7. FastTrack با Policy QoS تداخل ندارد.
8. NAT و Multi-WAN مسیر Session را قابل پیش‌بینی نگه می‌دارند.
9. کیفیت شبکه قبل و بعد از تغییر اندازه‌گیری می‌شود.

مهم‌تر از همه، QoS نباید برای پنهان‌کردن مشکل بنیادی شبکه استفاده شود. کابل معیوب، Wi-Fi شلوغ، Packet Loss ISP، CPU اشباع‌شده یا SIP Trunk ناپایدار با Priority 1 درمان نمی‌شوند.

QoS زمانی مؤثر است که شبکه سالم باشد و هدف ما مدیریت رقابت Trafficها هنگام Congestion باشد.