چرا تماس تلفن Cisco روی Wi-Fi یا VPN مشکل دارد؟ رفع MTU و NAT

اول Wi‑Fi و VPN را از هم جدا کنید؛ تست چهارحالته

قبل از دست‌زدن به MTU و MSS، همان Phone یا همان Extension را در چهار حالت مقایسه کنید. این تست ساده معمولاً نصف مسیر عیب‌یابی را کوتاه می‌کند.

اگر فقط حالت Wi‑Fi خراب است، اول سراغ MTU VPN نروید. اگر فقط حالت VPN خراب است، تغییر Channel وای‌فای کمکی نمی‌کند. اگر هر دو جداگانه خوب‌اند ولی Wi‑Fi + VPN با هم خراب می‌شود، معمولاً محدودیت کیفیت مسیر، Jitter، Overhead و Queueing ترکیبی را باید بررسی کنید.

چرا VoIP روی Wi‑Fi زودتر از وب خراب می‌شود؟

مرور یک سایت می‌تواند Retransmission و Delay را تا حدی تحمل کند، اما Voice بلادرنگ به Jitter، Delay و Packet Loss حساس است. Cisco در راهنمای Wireless Voice تأکید می‌کند که همین مشکلاتی که ممکن است برای کاربر Data محسوس نباشند، روی تماس Voice اثر جدی دارند.

در WLAN، علاوه بر پهنای باند، رقابت روی Air Time، Retransmission، Roaming و Queueing هم مطرح است. به همین دلیل WMM/QoS باید درست باشد و Voice Traffic نباید در صف Best Effort با Downloadهای سنگین رقابت کند.

Cisco روی Wi‑Fi چه DSCPهایی را استفاده می‌کند؟

برای Cisco Wireless IP Phone 8821، Cisco در راهنمای رسمی مقدار DSCP 24 (CS3) را برای SIP Signaling و DSCP 46 (EF) را برای RTP Voice مستند کرده است. Voice در WMM باید در Access Category مناسب Voice قرار بگیرد. این مقادیر یک مرجع خوب برای بررسی Capture هستند، اما Policy نهایی شبکه شما باید با مدل Phone و Call Control تطبیق داده شود.

در MPP نیز Cisco برای SIP و RTP پارامترهای ToS/DiffServ جدا دارد و در Administration Guide فعلی مقادیر پیش‌فرض زیر دیده می‌شوند:

SIP TOS/DiffServ Value: 0x68
RTP ToS/DiffServ Value: 0xb8

این مقدارها را کورکورانه تغییر ندهید. اول Capture بگیرید و ببینید Phone چه Markingی می‌فرستد و AP، Switch، Firewall و VPN Gateway با آن چه می‌کنند.

MTU چیست و چرا VPN آن را کوچک‌تر می‌کند؟

MTU حداکثر اندازه Packetی است که یک Link بدون Fragmentation می‌تواند حمل کند. روی Ethernet معمولاً عدد ۱۵۰۰ دیده می‌شود، اما وقتی IPsec، GRE، SSL/DTLS یا Encapsulation دیگری اضافه می‌کنید، Headerهای جدید فضای بیشتری مصرف می‌کنند.

Cisco در راهنمای فعلی ASA توضیح می‌دهد که Tunnelهایی مثل Site-to-Site VPN Header اضافی ایجاد می‌کنند و Packet نهایی می‌تواند از MTU مسیر بزرگ‌تر شود. در این شرایط Packet ممکن است Fragment شود یا اگر Fragmentation ممکن نباشد Drop شود.

مسیر ساده را این‌طور تصور کنید:

Original SIP/RTP Packet
        |
        + VPN / IPsec / DTLS overhead
        |
        v
Larger outer packet
        |
        + Path MTU is smaller
        |
        +--> Fragmentation
        |
        +--> Drop / Black-hole

عدد MTU را از اینترنت کپی نکنید

اینکه یک نفر برای VPN خود MTU را ۱۳۰۰ یا ۱۴۰۰ گذاشته به معنی درست‌بودن همان عدد برای شما نیست. Cisco برای AnyConnect در یک سناریوی Troubleshooting نمونه MTU برابر ۱۳۰۰ را ارائه می‌کند، اما این یک نسخه عمومی برای همه VPNها نیست. Overhead به نوع Tunnel، Cipher، IPv4/IPv6 و Encapsulation بستگی دارد.

روش درست این است که Path MTU را اندازه‌گیری کنید.

تست Path MTU در ویندوز

برای IPv4 می‌توانید با DF Bit تست کنید. مثال زیر یک ICMP Payload با اندازه ۱۳۷۲ بایت می‌فرستد:

ping -f -l 1372 203.0.113.10

در IPv4، برای این تست تقریباً ۲۸ بایت Header مربوط به IP و ICMP را به Payload اضافه کنید. پس اگر ۱۳۷۲ بدون Fragmentation عبور کند، اندازه IP Packet حدود ۱۴۰۰ بایت است.

اگر پیام Fragmentation Needed دریافت کردید، عدد را کم کنید. اگر موفق بود، آرام‌آرام بالا ببرید تا بزرگ‌ترین Payload سالم را پیدا کنید.

تست Path MTU در لینوکس

در لینوکس می‌توانید DF را با گزینه `-M do` اعمال کنید:

ping -M do -s 1372 203.0.113.10

اگر مقصد شما PBX داخلی آن طرف VPN است، بهتر است تست را دقیقاً به همان Host یا حداقل همان Subnet انجام دهید تا مسیر تا حد ممکن به مسیر VoIP نزدیک باشد.

MSS چیست و چرا مشکل RTP را مستقیماً حل نمی‌کند؟

MSS مربوط به TCP است و مشخص می‌کند هر TCP Segment چه مقدار Payload داشته باشد. Cisco در راهنمای ASA صریحاً توضیح می‌دهد که TCP MSS روی TCP اثر دارد و UDP تحت تأثیر آن نیست.

این تفاوت برای VoIP بسیار مهم است:

پس اگر با `tcp-mss` فقط Web UI، Provisioning یا SIP-TLS بهتر شد ولی صدا هنوز مشکل دارد، این نتیجه طبیعی است. RTP به MTU واقعی، Fragmentation، NAT و Packet Loss خودش وابسته است.

قاعده تقریبی MSS

در IPv4 و TCP بدون Option اضافی، یک محاسبه ساده این است:

TCP MSS ≈ Path MTU - 40 bytes

اما این فقط یک تقریب برای IPv4/TCP پایه است. IPv6، TCP Options و Tunnel Architecture می‌توانند محاسبه را تغییر دهند.

Fragmentation چه علائمی در تماس Cisco ایجاد می‌کند؟

Fragmentation همیشه به شکل «هیچ چیز کار نمی‌کند» ظاهر نمی‌شود. ممکن است Phone رجیستر شود، تماس ساده برقرار شود ولی یک INVITE بزرگ با SDP، Security Header یا Featureهای بیشتر Fail شود.

RFC 3261 برای SIP یک نکته بسیار مهم دارد: اگر Request به Path MTU نزدیک باشد یا اندازه آن از ۱۳۰۰ بایت بیشتر باشد و Path MTU معلوم نباشد، باید از Transport کنترل‌شده‌ای مثل TCP استفاده شود تا Fragmentation UDP کاهش پیدا کند.

Cisco در راهنمای ASA نیز برای SIP تحت Inspection هشدار می‌دهد که Fragmented SIP ممکن است نیاز به Reassembly داشته باشد و توصیه می‌کند برای پیام‌های بزرگ، اندازه SIP را کم کنید یا به‌جای UDP از TCP/TLS استفاده کنید.

آیا RTP صوتی هم Fragment می‌شود؟

Packetهای صوتی معمولاً بسیار کوچک‌تر از ۱۵۰۰ بایت هستند، بنابراین MTU مشکل‌دار بیشتر اوقات ابتدا روی Signaling بزرگ، Certificateها، Provisioning یا Packetهای Encapsulated پیچیده خودش را نشان می‌دهد. بااین‌حال اگر Tunnel MTU بسیار پایین باشد، Encapsulation چندلایه داشته باشید یا Packetهای Media بزرگ‌تر باشند، UDP Media نیز می‌تواند تحت تأثیر قرار بگیرد.

پس «صدا یک‌طرفه است» را مستقیماً برابر با MTU ندانید؛ NAT و Firewall برای One-Way Audio معمولاً مظنون‌های مهم‌تری هستند.

Fragmentation را در Wireshark چطور ببینیم؟

برای IPv4 Fragmentها از این Filter استفاده کنید:

ip.flags.mf == 1 || ip.frag_offset > 0

برای ICMP Fragmentation Needed:

icmp.type == 3 && icmp.code == 4

اگر روی یک سمت VPN Packet سالم را می‌بینید ولی سمت دیگر Fragment یا Drop شده، نقطه مشکل بسیار محدودتر می‌شود.

NAT و UDP Timeout؛ علت کلاسیک تماس یک‌طرفه و خرابی بعد از Idle

SIP و RTP در بسیاری از Deploymentها از UDP استفاده می‌کنند و NAT/Firewall برای UDP State دائمی نگه نمی‌دارد. اگر Mapping قبل از Packet بعدی Expire شود، تماس ورودی یا Media برگشتی ممکن است دیگر مسیر باز نداشته باشد.

Cisco برای MPP گزینه NAT Keep Alive دارد تا Phone به‌صورت دوره‌ای Packetی بفرستد و NAT Mapping را زنده نگه دارد. در Administration Guide فعلی، Keep Alive Message می‌تواند `$NOTIFY` یا `$REGISTER` باشد و Interval پیش‌فرض پارامتر Keep Alive برابر ۱۵ ثانیه مستند شده است؛ خود Enable به‌صورت پیش‌فرض خاموش است.

نمونه NAT Keep Alive در Cisco MPP

<NAT_Keep_Alive_Enable_1_ ua="na">Yes</NAT_Keep_Alive_Enable_1_>
<NAT_Keep_Alive_Msg_1_ ua="na">$NOTIFY</NAT_Keep_Alive_Msg_1_>
<NAT_Keep_Alive_Dest_1_ ua="na">$PROXY</NAT_Keep_Alive_Dest_1_>
<NAT_Keep_Alive_Intvl ua="na">15</NAT_Keep_Alive_Intvl>

اما Cisco هم تأکید می‌کند که Provider ممکن است Requirement متفاوتی داشته باشد. Keep Alive را با NAT/SBC Architecture خودتان هماهنگ کنید، نه صرفاً چون یک Template این مقدار را دارد.

نشانه‌های UDP Timeout

Cisco در مستند NAT برای VoIP اشاره می‌کند که Expire شدن Registration Pinhole می‌تواند علائم تصادفی و مبهم در Signaling ایجاد کند.

SIP ALG را بدون شواهد روشن روشن یا خاموش نکنید

SIP ALG می‌تواند Header و SDP را برای NAT بازنویسی کند؛ در بعضی معماری‌ها مفید است و در بعضی شبکه‌ها باعث Double Rewrite و مشکل Media می‌شود.

خود Cisco برای MPP چند روش NAT Traversal را مستند می‌کند، از جمله SBC، SIP-ALG و Static NAT Mapping. انتخاب روش باید با Provider و Topology هماهنگ باشد.

اگر SBC یا Provider خودش NAT Traversal را انجام می‌دهد، تغییر هم‌زمان Phone NAT Mapping و Router SIP ALG ممکن است رفتار را پیچیده کند. فقط یک معماری مشخص داشته باشید و با Capture بررسی کنید Header و SDP واقعاً چه IP/Portی را حمل می‌کنند.

VPN Overhead؛ چرا Ping کوچک خوب است ولی تماس خراب می‌شود؟

یک Ping کوچک فقط ثابت می‌کند Connectivity پایه وجود دارد. IPsec، GRE یا SSL/DTLS Header اضافه می‌کنند. Cisco در راهنمای IPsec Pre-Fragmentation توضیح می‌دهد که Packet نزدیک MTU پس از اضافه‌شدن IPsec Header می‌تواند از MTU Egress بزرگ‌تر شود و Fragmentation ایجاد کند.

برای همین این الگو مهم است:

این الگو MTU/Fragmentation را بسیار محتمل‌تر می‌کند.

AnyConnect/SSL VPN و تفاوت DTLS با TLS

در AnyConnect، Cisco برای TLS و DTLS MTU جداگانه محاسبه می‌کند چون Encapsulation Overhead آن‌ها یکسان نیست. اگر DTLS در مسیر Block شود، Client می‌تواند به TLS برگردد و MTU مؤثر تغییر کند.

این نکته برای VoIP مهم است چون UDP Voice روی Tunnelی که ناگهان Transport یا MTU آن تغییر کرده ممکن است رفتار متفاوتی نشان دهد. در Troubleshooting رسمی Cisco یک نمونه تنظیم `anyconnect mtu 1300` وجود دارد، اما همان سند هم این مقدار را برای یک سناریوی خاص ارائه می‌کند.

نمونه Cisco:

group-policy ac_users_group attributes
 webvpn
  anyconnect mtu 1300

این عدد را نسخه عمومی ندانید. اول PMTU واقعی شبکه خودتان را پیدا کنید.

DSCP روی VPN؛ Marking هست، اما آیا واقعاً حفظ می‌شود؟

دیدن `DSCP EF` روی Packet خروجی Phone فقط شروع کار است. ممکن است Switch آن را Trust کند، AP آن را به WMM درست Map کند، اما VPN Gateway آن را Remark کند یا Outer Header رفتار دیگری داشته باشد.

برای بررسی RTP با DSCP 46 در Wireshark:

ip.dsfield.dscp == 46

برای SIP، مقدار مورد انتظار را از Config همان Device بردارید و Capture کنید.

در شبکه Public Internet، DSCP تضمین End-to-End نمی‌دهد. جایی که واقعاً کنترل دارید—WLAN، LAN و Egress VPN—QoS را اعمال کنید.

QoS در Wi‑Fi؛ WMM مهم‌تر از فقط DSCP است

در WLAN، DSCP باید به Access Category درست Map شود. Cisco برای Voice Wireless توصیه می‌کند RTP در Voice Queue قرار گیرد و Signaling نیز Priority مناسب خودش را داشته باشد.

اگر DSCP روی Packet درست است ولی AP همه Traffic را Best Effort می‌فرستد، Marking به‌تنهایی هیچ مزیت عملی ایجاد نمی‌کند.

پس در Capture و Controller هر دو را بررسی کنید:

Capture درست؛ قبل، داخل و بعد از VPN

اگر فقط روی Phone Capture بگیرید، می‌دانید Phone چه چیزی فرستاده اما نمی‌دانید Tunnel با آن چه کرده است. برای تشخیص جدی، حداقل دو نقطه Capture داشته باشید:

Cisco Phone / Voice VLAN
        |
        v
VPN Gateway A
======== Encrypted Tunnel ========
VPN Gateway B
        |
        v
PBX / SBC / Provider

Capture سمت داخل Tunnel نشان می‌دهد SIP/RTP واقعی چه بوده؛ Capture روی WAN ممکن است فقط ESP یا UDP 4500 را نشان دهد. برای مقایسه Signaling و RTP باید در سمت Decrypted/Inside هم Capture داشته باشید.

Packet Capture مستقیم از Cisco MPP

در مدل‌های MPP پشتیبانی‌شده، Cisco امکان Packet Capture را از Web UI می‌دهد:

Info
→ Debug Info
→ Start Packet Capture
→ Reproduce the call
→ Stop Packet Capture

این Capture برای دیدن Packet قبل از VPN بسیار ارزشمند است.

فیلترهای کاربردی Wireshark برای SIP و RTP

برای SIP:

sip

برای یک Call-ID خاص:

sip.Call-ID == "CALL-ID-FROM-TRACE"

برای RTP اگر Wireshark Stream را شناسایی کرده باشد، از مسیر Telephony → RTP → RTP Streams استفاده کنید. Packet Loss، Sequence Gap و Jitter را بررسی کنید.

برای UDP عمومی:

udp

سناریو ۱: تماس برقرار می‌شود اما صدا یک‌طرفه است

اول SDP را ببینید. IP و Port اعلام‌شده در `c=` و `m=audio` را با مسیر NAT/VPN مقایسه کنید. سپس در Capture ببینید RTP در هر دو جهت وجود دارد یا نه.

اگر Phone RTP می‌فرستد ولی هیچ RTP برگشتی دیده نمی‌شود، Provider/PBX/NAT مسیر برگشت را بررسی کنید. اگر RTP تا VPN Gateway می‌رسد ولی بعد Tunnel ناپدید می‌شود، Firewall/VPN Policy مطرح است.

در این سناریو کاهش MSS معمولاً راه‌حل مستقیم نیست، چون Media UDP است.

سناریو ۲: تماس بعد از ۲۰ یا ۳۰ ثانیه قطع می‌شود

این زمان‌بندی می‌تواند دلایل SIP Session/ACK هم داشته باشد؛ بنابراین بدون Trace آن را به NAT Timeout نسبت ندهید.

بررسی کنید آیا `200 OK` و `ACK` کامل ردوبدل شده‌اند. اگر ACK به‌خاطر NAT یا Route برنمی‌گردد، Call می‌تواند با Timer قطع شود. اگر Signaling کامل است ولی Media State بعد از Idle ناپدید می‌شود، UDP Timeout محتمل‌تر می‌شود.

سناریو ۳: REGISTER سالم است اما تماس بزرگ Fail می‌شود

اگر REGISTER کوچک عبور می‌کند ولی INVITE با SDP، Security Header یا Route Headerهای بیشتر Fail می‌شود، MTU و SIP-over-UDP Fragmentation را جدی بررسی کنید.

اندازه SIP Message را در Wireshark ببینید. اگر بزرگ است و UDP استفاده می‌کنید، امکان استفاده از TCP/TLS را با PBX/Provider بررسی کنید. RFC 3261 دقیقاً برای جلوگیری از Fragmentation پیام‌های بزرگ، استفاده از Transport کنترل‌شده را توصیه می‌کند.

سناریو ۴: روی Wi‑Fi صدا تکه‌تکه است ولی VPN خاموش هم همین مشکل وجود دارد

این مورد بیشتر به WLAN مربوط است تا MTU Tunnel. WMM، DSCP، Channel Utilization، Retry و Roaming را بررسی کنید. اگر Packet Capture Sequence Gap و Jitter بالا نشان می‌دهد، اول Air Layer را اصلاح کنید.

سناریو ۵: با روشن‌شدن VPN همه چیز بد می‌شود

این الگو را بررسی کنید:

اشتباه‌های رایج در عیب‌یابی Cisco VoIP روی VPN

پرسش‌های رایج

برای Cisco VoIP روی VPN چه MTUای مناسب است؟

عدد ثابت و عمومی وجود ندارد. MTU مناسب به نوع VPN، Encapsulation و مسیر Underlay بستگی دارد. PMTU را با DF Test و Capture اندازه‌گیری کنید و بعد Tunnel MTU را تنظیم کنید.

آیا TCP MSS مشکل صدای RTP را حل می‌کند؟

مستقیماً خیر. MSS فقط TCP را محدود می‌کند؛ RTP معمولاً UDP است. MSS می‌تواند Provisioning HTTPS یا SIP-TLS را بهتر کند، اما برای Media باید MTU، NAT، Fragmentation و UDP Path را بررسی کنید.

NAT Keep Alive در Cisco MPP چه کاری انجام می‌دهد؟

Phone به‌صورت دوره‌ای پیام Keep Alive به Proxy می‌فرستد تا NAT Mapping زنده بماند. Cisco برای MPP پیام‌های $NOTIFY و $REGISTER را پشتیبانی می‌کند و Provider ممکن است Interval مشخصی بخواهد.

چرا تماس روی Wi‑Fi قطع‌وصلی دارد ولی اینترنت خوب است؟

Voice به Jitter، Delay، Packet Loss و Air-Time Contention حساس‌تر است. WMM/QoS، DSCP Mapping، Retransmission، Channel Utilization و Roaming را بررسی کنید.

Fragmentation در SIP چه مشکلی ایجاد می‌کند؟

پیام بزرگ SIP روی UDP ممکن است Fragment شود و بعضی Firewallها یا NATها Fragmentها را Drop کنند. RFC 3261 برای Requestهای بزرگ یا نزدیک PMTU استفاده از Transportهایی مانند TCP را توصیه می‌کند.

DSCP 46 یعنی تماس حتماً QoS دارد؟

خیر. DSCP فقط Marking است. Switch/AP/VPN Gateway باید آن را Trust و به Queue مناسب Map کنند. روی Public Internet نیز هیچ تضمین End-to-End برای حفظ Priority وجود ندارد.

برای مشکل VPN از کجا Capture بگیریم؟

حداقل از شبکه Phone قبل از Encryption و از سمت داخل Tunnel در مقصد Capture بگیرید. Capture WAN ممکن است فقط ESP یا UDP 4500 را نشان دهد و برای دیدن SIP/RTP کافی نباشد.

آیا تماس یک‌طرفه همیشه از MTU است؟

خیر. One-Way Audio بیشتر اوقات به NAT، Firewall، SDP Address یا Route Media مربوط می‌شود. MTU یکی از احتمالات است و باید با PMTU Test و Capture اثبات شود.