Amir Jabbari
در ارتباط‌های VPN یک Packet قبل از خروج دوباره Encapsulate و گاهی Encrypt می‌شود. همین Headerهای اضافه می‌توانند MTU مؤثر مسیر را کوچک‌تر کنند. اگر Packet بزرگ‌تر از ظرفیت واقعی Tunnel باشد، Fragment می‌شود یا در حالتی که Fragmentation ممکن نیست Drop می‌شود. از طرف دیگر، NAT و Firewall نیز برای SIP و RTP Stateهای UDP موقت ایجاد می‌کنند که در صورت Timeout می‌توانند باعث از دست‌رفتن Registration یا صدای یک‌طرفه شوند.
در Wi-Fi مسئله کمی متفاوت است. حتی با Signal خوب، اگر WMM/QoS درست نباشد، RTP Voice با Download، Backup و سایر Dataها برای دسترسی به Radio رقابت می‌کند و نتیجه می‌تواند Jitter و Packet Loss باشد.
در این راهنما MTU، MSS، Fragmentation، NAT، UDP Timeout، DSCP، VPN Overhead و Packet Capture را مرحله‌به‌مرحله بررسی می‌کنیم تا مشخص شود مشکل واقعاً از Cisco Phone است یا از Wireless، VPN Gateway، Router، Firewall یا مسیر PBX.
تشخیص سریع: اگر Registration یا HTTPS Provisioning هنگ می‌کند ولی Packetهای کوچک عبور می‌کنند، MTU/PMTUD را جدی بررسی کنید. اگر تماس وصل است اما یک‌طرفه صدا دارید، NAT، Route و RTP را قبل از MTU بررسی کنید. اگر فقط هنگام شلوغی Wi-Fi صدا خراب می‌شود، WMM، DSCP، Channel Utilization و Jitter مهم‌ترند.
اول مشخص کنید Cisco از کدام نوع اتصال استفاده می‌کند
عبارت «Cisco روی VPN» می‌تواند سه معماری کاملاً متفاوت باشد.
| سناریو | VPN کجا ساخته می‌شود؟ | نقطه اصلی عیب‌یابی |
|---|---|---|
| VPN داخلی خود Cisco MPP | خود تلفن | VPN Status، Tunnel، Gateway، MTU مسیر |
| Site-to-Site VPN | Router/Firewall شعبه | IPsec/VTI/GRE، MTU، Route، QoS |
| Wi-Fi و اینترنت بدون VPN داخلی | ندارد یا روی Router است | WMM، NAT، SIP/RTP، ISP |
تا زمانی که معماری مشخص نشده، تغییر NAT Mapping یا MTU روی Phone ممکن است کاملاً بی‌اثر باشد.
Cisco MPP خودش VPN Client دارد؟
بله. راهنمای فعلی Cisco MPP امکان ساخت VPN Connection مستقیم از خود Phone را مستند کرده است.
در تلفن:
Applications → Network configuration → VPN settings
و در Web Administration:
Voice → System → VPN Settings
بعد از اتصال می‌توانید از:
Applications → Status → VPN status
وضعیت Tunnel را ببینید.
موارد مهم عبارت‌اند از:
🔹 VPN connection: Connected یا Disconnected
🔹 VPN IP address
🔹 VPN subnet mask
🔹 Sent bytes
🔹 Received bytes
اگر VPN Connected است ولی Sent Bytes افزایش می‌یابد و Received Bytes تقریباً ثابت می‌ماند، Route، ACL یا Gateway سمت مقابل را بررسی کنید.
Wi-Fi در کدام Cisco 8800ها وجود دارد؟
در MPP سری 8800، Cisco طبق راهنمای فعلی Wi-Fi را روی مدل‌های 8861 و 8865 ارائه می‌کند.
پس اگر 8851 یا 8841 دارید و Phone از یک Wireless Bridge خارجی استفاده می‌کند، مشکل Wireless مربوط به Bridge/AP است و نه Radio داخلی Phone.
MTU چیست و چرا VPN آن را خراب می‌کند؟
MTU حداکثر اندازه Packetی است که یک Interface می‌تواند بدون Fragmentation عبور دهد.
روی Ethernet معمولی مقدار رایج:
MTU = 1500 bytesاست.
اما وقتی Packet وارد IPsec، SSL VPN، GRE یا Tunnel دیگری می‌شود، Headerهای جدید به آن اضافه می‌شوند.
در نتیجه Payload اصلی دیگر نمی‌تواند همیشه 1500 Byte باقی بماند.
MTU مؤثر ممکن است مثلاً به محدوده 1400، 1380 یا حتی کمتر برسد؛ اما یک عدد ثابت برای همه VPNها وجود ندارد.
نوع Tunnel، Encryption، IPv4/IPv6، NAT-T و Provider همگی روی مقدار واقعی اثر دارند.
VPN Overhead چه مشکلی ایجاد می‌کند؟
فرض کنید Packet اصلی نزدیک 1500 Byte است.
VPN چند ده Byte Header اضافه می‌کند.
حالا Packet Encapsulated از MTU مسیر بزرگ‌تر است.
سه اتفاق ممکن است بیفتد:
۱. Packet Fragment شود.
۲. Sender از طریق PMTUD اندازه Packet را کاهش دهد.
۳. Packet Drop شود و یک MTU Black Hole ایجاد شود.
MTU Black Hole چه علائمی دارد؟
یکی از گیج‌کننده‌ترین مشکلات VPN همین حالت است.
ممکن است:
🔹 Ping کوچک سالم باشد.
🔹 Registration اولیه گاهی انجام شود.
🔹 HTTPS باز شود ولی Download کامل نشود.
🔹 TLS Handshake در مرحله خاصی Hang کند.
🔹 SIP Messageهای کوچک عبور کنند اما INVITE بزرگ Fail شود.
🔹 تماس معمولی سالم باشد ولی Transfer یا Conference شکست بخورد.
در چنین وضعیتی «شبکه وصل است» ولی Packetهای بزرگ‌تر از یک Threshold مشخص عبور نمی‌کنند.
PMTUD چیست؟
Path MTU Discovery یا PMTUD برای پیدا کردن کوچک‌ترین MTU موجود در مسیر استفاده می‌شود.
اگر Packet دارای DF یا Don’t Fragment باشد و Router نتواند آن را از لینک کوچک‌تر عبور دهد، Packet را Drop می‌کند و باید ICMP مناسب با مفهوم:
Fragmentation Neededبه Sender برگرداند.
اگر Firewall این ICMP را Block کند، Sender نمی‌فهمد MTU مسیر کوچک‌تر است و Packetهای بزرگ پشت سر هم Drop می‌شوند.
پس ICMP را کورکورانه Block نکنید
بستن کامل ICMP در Tunnel یا WAN می‌تواند PMTUD را خراب کند.
این به معنی بازکردن همه ICMPها برای همه مقصدها نیست؛ Rule را بر اساس معماری و پیام‌های موردنیاز PMTUD طراحی کنید.
MTU را چطور تست کنیم؟
از سیستمی که مسیر شبکه مشابه Phone تا PBX یا VPN Gateway دارد، می‌توانید تست اولیه انجام دهید.
در Windows برای IPv4 و یک مسیر Ethernet معمولی:
ping -f -l 1472 192.0.2.20عدد 1472 به این دلیل استفاده می‌شود که با Headerهای IPv4 و ICMP جمعاً تقریباً 1500 Byte می‌شود.
اگر پیام Fragmentation دریافت کردید، اندازه را پایین بیاورید:
ping -f -l 1400 192.0.2.20
ping -f -l 1360 192.0.2.20
ping -f -l 1320 192.0.2.20IP بالا فقط نمونه مستندسازی است.
تست MTU روی Linux
ping -M do -s 1472 192.0.2.20اگر عبور نکرد، Payload را مرحله‌ای کاهش دهید تا بزرگ‌ترین Packet سالم را پیدا کنید.
این آزمایش جای Capture خود Cisco را نمی‌گیرد، اما برای یافتن Path MTU مشکل‌دار بسیار مفید است.
MSS چیست و چه فرقی با MTU دارد؟
MSS یا Maximum Segment Size به TCP مربوط است.
یعنی مشخص می‌کند هر TCP Segment چه مقدار Payload داشته باشد.
این برای مواردی مثل:
🔹 SIP over TCP
🔹 SIP over TLS
🔹 HTTPS Provisioning
🔹 Firmware Download
اهمیت دارد.
اما RTP Voice معمولاً UDP است.
نکته بسیار مهم: MSS مشکل RTP را مستقیماً حل نمی‌کند
فرمانی مثل:
ip tcp adjust-mss 1360فقط TCP را تحت‌تأثیر قرار می‌دهد.
اگر RTP/UDP Drop می‌شود، کاهش MSS آن Packetها را کوچک‌تر نمی‌کند.
این اشتباه در عیب‌یابی VoIP over VPN بسیار رایج است.
پس چه زمانی MSS مفید است؟
اگر روی VPN این علائم را دارید:
SIP TLS Register نمی‌شود، HTTPS Provisioning Hang می‌کند یا TCP Session با Packetهای بزرگ Fail می‌شود، MSS می‌تواند بخشی از راه‌حل باشد.
اما مقدار MSS باید از Path MTU واقعی و Tunnel Overhead محاسبه شود.
عددهای 1360 و 1400 که در بسیاری از مثال‌ها دیده می‌شوند فقط نمونه‌اند، نه مقدار استاندارد همه VPNها.
نمونه برای Tunnelهای IOS؛ فقط بعد از محاسبه
برای یک VTI/GRE/IPsec مشخص ممکن است ساختاری شبیه این استفاده شود:
interface Tunnel10
ip mtu 1400
ip tcp adjust-mss 1360
tunnel path-mtu-discoveryاعداد بالا نمونه‌اند. مقدار درست باید برای Tunnel واقعی شما محاسبه یا اندازه‌گیری شود.
چرا RTP معمولاً کمتر دچار Fragmentation می‌شود؟
Packetهای صوتی RTP معمولاً خیلی کوچک‌تر از 1500 Byte هستند.
مثلاً با Packetization رایج 20ms، حتی Codecهایی مثل G.711 نیز معمولاً Packetهایی بسیار کوچک‌تر از MTU Ethernet تولید می‌کنند.
به همین دلیل اگر فقط صدای یک‌طرفه دارید، MTU اولین مظنون نیست.
اول بررسی کنید:
🔹 RTP IP داخل SDP
🔹 NAT
🔹 Firewall ACL
🔹 UDP Timeout
🔹 Asymmetric Routing
چه زمانی RTP هم می‌تواند به MTU نزدیک شود؟
در چند سناریو احتمال بیشتر می‌شود:
🔹 Video RTP
🔹 Packetization غیرمعمول
🔹 چند لایه Tunnel و Encapsulation
🔹 SRTP همراه با Tunnelهای متعدد
🔹 IPv6 و Tunnel ترکیبی
در این موارد PCAP بهترین راه برای دیدن اندازه واقعی Packet است.
SIP روی UDP بیشتر از MTU آسیب می‌بیند
یک SIP INVITE می‌تواند Headerها و SDP زیادی داشته باشد.
با فعال‌شدن مواردی مثل:
🔹 SRTP
🔹 ICE
🔹 Diversion/History-Info
🔹 Identity Headers
🔹 Codecهای متعدد
اندازه SIP Message افزایش پیدا می‌کند.
اگر SIP روی UDP باشد و Message از MTU مؤثر VPN بزرگ‌تر شود، IP Fragmentation اتفاق می‌افتد.
بعضی Firewallها یا NATها Fragment دوم و سوم را Drop می‌کنند و تماس Fail می‌شود.
نشانه کلاسیک SIP Fragmentation
REGISTER ساده کار می‌کند.
تماس ساده شاید کار کند.
اما INVITE خاص، Transfer یا تماس دارای SDP بزرگ Fail می‌شود.
در PCAP می‌بینید SIP Message به IP Fragment تقسیم شده است و همه Fragmentها به مقصد نمی‌رسند.
مرحله بعد: NAT را از MTU جدا کنید
یک تماس می‌تواند MTU کاملاً سالم داشته باشد ولی به دلیل NAT خراب شود.
در Cisco MPP گزینه‌های مهم عبارت‌اند از:
🔹 NAT Mapping Enable
🔹 NAT Keep Alive Enable
🔹 NAT Keep Alive Intvl
🔹 VIA rport
🔹 Send Response To Source Port
NAT Keep Alive در Cisco MPP
Cisco می‌تواند به‌صورت دوره‌ای پیام Keep Alive بفرستد تا NAT Mapping مربوط به SIP از بین نرود.
در راهنمای فعلی Cisco مقدار پیش‌فرض:
NAT Keep Alive Intvl = 15 secondsاست.
اما NAT Keep Alive Enable به‌صورت پیش‌فرض No است.
نمونه تنظیم NAT Keep Alive
<NAT_Keep_Alive_Enable_1_ ua="na">Yes</NAT_Keep_Alive_Enable_1_>
<NAT_Keep_Alive_Intvl ua="na">15</NAT_Keep_Alive_Intvl>قبل از فعال‌کردن، نیازمندی PBX یا Provider را بررسی کنید.
NAT Keep Alive تلفن، RTP Timeout را تضمین نمی‌کند
این تفاوت بسیار مهم است.
Keep Alive فوق عمدتاً برای حفظ Mapping مربوط به SIP/NAT استفاده می‌شود.
این به معنی زنده‌ماندن تمام UDP Stateهای RTP نیست.
اگر Firewall برای RTP Timeout بسیار کوتاهی دارد، ممکن است Media Flow در Hold یا سناریوهای خاص بسته شود.
RTP Timeout خود Firewall، SBC و VPN Gateway را جداگانه بررسی کنید.
نشانه UDP Timeout چیست؟
تماس در ابتدا کاملاً سالم است، اما بعد از مدت تقریباً ثابتی:
🔹 صدا یک‌طرفه می‌شود.
🔹 BLF یا Registration از دست می‌رود.
🔹 تماس بعد از Hold برنمی‌گردد.
🔹 اولین تماس بعد از چند دقیقه Idle Fail می‌شود.
اگر زمان خرابی تقریباً همیشه یکسان است، Session Timeoutهای NAT/Firewall را بررسی کنید.
NAT Mapping را کورکورانه فعال نکنید
اگر Cisco داخل VPN است و PBX آدرس VPN داخلی Phone را مستقیماً می‌بیند، ممکن است اصلاً نیازی به Public NAT Mapping روی خود Phone نباشد.
فعال‌کردن NAT Mapping اشتباه می‌تواند IP یا Port نامناسب را داخل SIP/SDP قرار دهد.
ابتدا معماری را مشخص کنید:
Phone → VPN Tunnel → PBX
با:
Phone → NAT Router → Internet → SIP Provider
یکسان نیست.
یک‌طرفه شدن صدا روی VPN؛ این چهار چیز را ببینید
در SIP INVITE/200 OK آدرس Media را پیدا کنید.
مثلاً:
c=IN IP4 10.20.30.40
m=audio 16420 RTP/AVP 0 101سپس بررسی کنید:
۱. IP داخل SDP از سمت مقابل Route دارد؟
۲. RTP Port داخل ACL مجاز است؟
۳. NAT/SBC آن IP را درست Rewrite کرده؟
۴. Return Route از همان Tunnel برمی‌گردد؟
Asymmetric Routing روی VPN
گاهی SIP از VPN عبور می‌کند اما RTP از Default Internet Route خارج می‌شود.
یا مسیر رفت از Tunnel و مسیر برگشت از WAN معمولی است.
Stateful Firewall ممکن است چنین Trafficی را Drop کند.
برای Phone، PBX، SBC و VPN Gateway مسیر رفت و برگشت را جداگانه بررسی کنید.
Wi-Fi: Signal خوب مساوی VoIP خوب نیست
ممکن است Phone پنج خط Signal داشته باشد اما تماس همچنان Jitter داشته باشد.
علت می‌تواند Channel Utilization، Interference یا نبود WMM باشد.
برای Voice over Wi-Fi، Cisco توصیه می‌کند WMM فعال باشد و RTP Voice در Queue مناسب قرار گیرد.
DSCP مناسب Voice روی Wi-Fi
در راهنمای WLAN فعلی Cisco برای 8861 و 8865:
Voice RTP:
DSCP EF = 46
WMM UP = 6است.
و Call Control در طراحی CUCM/Webex روی Queue جداگانه قرار می‌گیرد.
MPP و Signaling DSCP یک نکته متفاوت دارند
در Cisco MPP، مقدار پیش‌فرض RTP ToS/DiffServ برابر:
0xb8است که DSCP آن EF/46 است.
اما Marking Signaling می‌تواند با CUCM/Webex Design متفاوت باشد. برای همین Policy را کورکورانه از یک Platform به Platform دیگر کپی نکنید.
DSCP داخل VPN ممکن است کافی نباشد
فرض کنید RTP داخل Tunnel برابر EF=46 است.
وقتی VPN Packet آن را Encapsulate می‌کند، Router باید مشخص کند Outer Packet چه DSCPی داشته باشد.
این رفتار به VPN Platform و QoS Policy بستگی دارد.
ممکن است Inner RTP صحیح باشد ولی Outer VPN Packet روی WAN به Best Effort تبدیل شود.
در زمان Congestion، Voice دیگر اولویت ندارد.
DSCP را در دو سمت Tunnel Capture کنید
برای تشخیص واقعی:
یک Capture قبل از Encryption و یک Capture روی سمت خروجی/مقابل Tunnel بگیرید.
در Wireshark برای RTP EF:
ip.dsfield.dscp == 46را بررسی کنید.
QoS داخل Tunnel بدون QoS روی Underlay کافی نیست
اگر WAN Link پر است، Encrypt شدن Packetها نباید باعث شود همه Trafficها از دید WAN یکسان شوند.
QoS باید روی Tunnel و Underlay با طراحی VPN شما هماهنگ باشد.
در غیر این صورت Voice و Backup داخل یک Queue قرار می‌گیرند.
Wi-Fi را روی 5GHz تست کنید
8861 و 8865 از 2.4GHz و 5GHz پشتیبانی می‌کنند.
در محیط‌های پرتراکم، 5GHz معمولاً Channelهای بیشتری در اختیار دارد و می‌تواند Interference کمتری نسبت به 2.4GHz داشته باشد.
اما «همیشه 5GHz بهتر است» قانون مطلق نیست؛ Coverage و طراحی AP مهم‌اند.
تلفن را در محل واقعی کاربر با هر دو Band آزمایش کنید.
Roaming را هم تست کنید
اگر تماس فقط هنگام حرکت کاربر بین APها قطع می‌شود، مشکل MTU نیست.
Fast Roaming، Authentication، RF Coverage و Handoff را بررسی کنید.
Cisco برای VoWLAN از قابلیت‌هایی مثل 802.11r و روش‌های Fast Secure Roaming پشتیبانی می‌کند.
چطور بفهمیم مشکل Wi-Fi است یا VPN؟
یک ماتریس تست ساده بسازید:
| آزمایش | نتیجه | برداشت |
|---|---|---|
| Ethernet بدون VPN | سالم | Phone/PBX احتمالاً سالم‌اند |
| Wi-Fi بدون VPN | خراب | WLAN/RF/QoS مظنون است |
| Ethernet با VPN | خراب | VPN/MTU/NAT/Route مظنون است |
| Wi-Fi با VPN | فقط این حالت خراب | ترکیب VPN Overhead و WLAN Quality را بررسی کنید |
Packet Capture روی Cisco MPP
در MPP می‌توانید مستقیم از Phone Capture بگیرید.
مسیر:
Admin Login → Advanced → Info → Debug Info
و سپس:
Start Packet Capture
Capture را قبل از Registration یا تماس شروع کنید، مشکل را یک بار تکرار کنید و سپس فایل PCAP را بررسی کنید.
برای این مشکل چه Filterهایی مفیدند؟
برای SIP و SDP:
sip || sdpبرای RTP:
rtpبرای Fragmentها:
ip.flags.mf == 1 || ip.frag_offset > 0برای ICMPهای مرتبط با MTU:
icmpبه IP Fragmentation در Wireshark چه دقتی کنیم؟
فقط دیدن Fragment لزوماً به معنی مشکل نیست.
باید ببینید:
🔹 همه Fragmentها به مقصد می‌رسند یا نه.
🔹 Reassembly کامل می‌شود یا نه.
🔹 Fragment فقط در یک جهت رخ می‌دهد یا هر دو.
🔹 هنگام Failure اندازه Packetها چقدر است.
اگر دقیقاً Packetهای بالاتر از یک Size خاص ناپدید می‌شوند، MTU/PMTUD مظنون جدی است.
Capture قبل و بعد VPN طلایی‌ترین تست است
اگر امکان دارید یک Capture سمت LAN و یک Capture سمت VPN Headend/PBX بگیرید.
مثلاً:
Phone → Branch Router → IPsec → HQ Router → PBX
اگر Packet در Branch LAN دیده می‌شود اما بعد از Tunnel وجود ندارد، محدوده مشکل مشخص شده است.
اگر Packet در هر دو سمت وجود دارد ولی PBX پاسخ نمی‌دهد، Server/Application را بررسی کنید.
علائم و علت‌های محتمل
| نشانه | مظنون اول | بررسی بعدی |
|---|---|---|
| Ping کوچک سالم، بزرگ Fail | MTU/PMTUD | DF Ping و ICMP |
| SIP TLS Hang می‌کند | MTU/MSS یا TLS | TCP Retransmission و Packet Size |
| تماس یک‌طرفه | NAT/Route/ACL | SDP و RTP Capture |
| بعد از زمان ثابت صدا قطع می‌شود | UDP Timeout | Firewall/NAT Timer |
| فقط هنگام Download صدا خراب است | QoS/Congestion | DSCP و Queue |
| فقط روی Wi-Fi خراب است | WMM/RF | Channel و AP QoS |
| فقط روی VPN خراب است | MTU/Route/NAT | Tunnel Capture |
| Transfer Fail ولی تماس عادی سالم است | SIP Fragmentation/SDP | re-INVITE Size |
| VPN Connected ولی Registration نداریم | Route/ACL/DNS | VPN IP و PBX Reachability |
مسیر پیشنهادی عیب‌یابی مرحله‌به‌مرحله
مرحله ۱: مشخص کنید Phone روی Ethernet، Wi-Fi یا VPN داخلی است.
مرحله ۲: یک تماس سالم و یک تماس خراب را مقایسه کنید.
مرحله ۳: در VPN، VPN IP و Sent/Received Bytes را بررسی کنید.
مرحله ۴: Route رفت و برگشت Phone ↔ PBX را بررسی کنید.
مرحله ۵: با DF Ping، Path MTU را تخمین بزنید.
مرحله ۶: ICMP موردنیاز PMTUD را بررسی کنید.
مرحله ۷: اگر مشکل TCP/TLS است، MSS را بررسی کنید.
مرحله ۸: اگر مشکل RTP است، MSS را کنار بگذارید و NAT/ACL/UDP Timeout را بررسی کنید.
مرحله ۹: NAT Keep Alive و SIP Mapping را با نیاز PBX/Provider تطبیق دهید.
مرحله ۱۰: روی Wi-Fi، WMM و DSCP Voice را Verify کنید.
مرحله ۱۱: DSCP را قبل و بعد از VPN مقایسه کنید.
مرحله ۱۲: PCAP را در دو طرف Tunnel بررسی کنید.
مرحله ۱۳: فقط بعد از پیدا کردن Fail Point، MTU، MSS، NAT Timer یا QoS را تغییر دهید.
پرسش‌های رایج
MTU مناسب برای Cisco VoIP روی VPN چند است؟
عدد ثابتی وجود ندارد. مقدار درست به VPN Protocol، Encryption، IPsec/GRE/NAT-T و Underlay بستگی دارد. Path MTU را اندازه‌گیری کنید و بر همان اساس Tunnel را تنظیم کنید.
آیا ip tcp adjust-mss مشکل صدای RTP را حل می‌کند؟
مستقیم خیر. MSS فقط TCP را تغییر می‌دهد. RTP معمولاً UDP است؛ برای RTP باید MTU، Fragmentation، NAT، UDP Timeout و Route بررسی شوند.
چرا Ping کار می‌کند ولی Cisco Register نمی‌شود؟
Ping کوچک ممکن است عبور کند ولی SIP TLS، HTTPS یا SIP Message بزرگ‌تر در MTU Black Hole گیر کند. DNS، TCP Retransmission و Path MTU را بررسی کنید.
چرا تماس روی VPN یک‌طرفه می‌شود؟
رایج‌ترین علت‌ها NAT، آدرس اشتباه داخل SDP، ACL مربوط به RTP یا Route نامتقارن هستند. MTU هم ممکن است اثر داشته باشد، اما برای One-Way Audio اولین مظنون نیست.
NAT Keep Alive Interval در Cisco MPP چقدر است؟
راهنمای فعلی MPP مقدار پیش‌فرض ۱۵ ثانیه را برای NAT Keep Alive Intvl مستند کرده است. خود NAT Keep Alive Enable به‌صورت پیش‌فرض غیرفعال است و باید بر اساس نیاز Provider/PBX استفاده شود.
آیا NAT Keep Alive باعث می‌شود RTP هرگز Timeout نشود؟
خیر. NAT Keep Alive تلفن عمدتاً Mapping مربوط به SIP را نگه می‌دارد. RTP State و Timeoutهای Firewall/SBC باید جداگانه بررسی شوند.
DSCP مناسب RTP Voice چیست؟
برای Voice معمولاً DSCP EF یا 46 استفاده می‌شود. Cisco نیز برای RTP Voice روی WLAN همین مقدار را مستند کرده است.
چرا DSCP 46 داریم ولی روی VPN هنوز صدا بد است؟
ممکن است DSCP داخل Tunnel صحیح باشد اما Outer VPN Packet در WAN به Best Effort تبدیل شود یا WAN Queue اصلاً EF را Prioritize نکند. DSCP را در چند نقطه مسیر Capture کنید.
چرا Cisco روی Wi-Fi فقط هنگام شلوغی شبکه بد کار می‌کند؟
این الگو بیشتر به WMM، Channel Utilization، Congestion و QoS مربوط است. Signal قوی به‌تنهایی کیفیت VoIP را تضمین نمی‌کند.
جمع‌بندی
برای رفع مشکل Cisco VoIP روی Wi-Fi یا VPN باید MTU، NAT و QoS را از هم جدا کنید.
VPN Overhead می‌تواند Path MTU را کاهش دهد و باعث Fragmentation یا MTU Black Hole شود. در این حالت Packetهای کوچک سالم‌اند اما SIP TLS، HTTPS یا پیام‌های بزرگ‌تر مشکل پیدا می‌کنند.
MSS فقط TCP را کنترل می‌کند و نباید به‌عنوان راه‌حل مستقیم RTP استفاده شود. اگر تماس یک‌طرفه یا Media قطع است، NAT، RTP Port، UDP Timeout، SDP و Route را بررسی کنید.
در Wi-Fi نیز WMM و DSCP EF=46 برای RTP اهمیت زیادی دارند. اگر DSCP داخل Phone درست است ولی روی VPN یا WAN از بین می‌رود، QoS End-to-End وجود ندارد.
بهترین تشخیص از مقایسه PCAP قبل و بعد VPN به دست می‌آید. ابتدا Fail Point را پیدا کنید و فقط بعد MTU، MSS، NAT Timer یا QoS را تغییر دهید.
VPN وصل است اما هنوز Registration، RTP یا کیفیت تماس پایدار نیست؟
اگر Cisco Phone در شعبه راه‌دور فقط روی VPN دچار صدای یک‌طرفه، Jitter، قطع Registration یا خطای Transfer می‌شود، تغییر یک عدد MTU به‌تنهایی کافی نیست. باید مسیر Phone تا PBX، Tunnel MTU، NAT، UDP Timeout، DSCP و RTP Capture کنار هم بررسی شوند.
ایرانیکاسرور می‌تواند تنظیم Cisco MPP، VPN Gateway، Firewall و PBXهایی مثل Asterisk، FreePBX و 3CX را بررسی کند تا مشخص شود مشکل در Endpoint، Tunnel یا مسیر SIP/RTP قرار دارد.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)