چرا صدای تلفن سیسکو یک‌طرفه است؟ علت و روش رفع مشکل RTP، SDP و NAT

برای پیدا کردن علت واقعی باید سه چیز را هم‌زمان بررسی کنیم: آدرس و Portهایی که داخل SDP اعلام شده‌اند، Packetهای RTP که واقعاً روی شبکه حرکت می‌کنند و تجهیزاتی مانند NAT، Firewall یا SIP ALG که ممکن است بین این دو اطلاعات تغییر ایجاد کنند.

در این راهنما یک تماس Cisco را از INVITE تا RTP دنبال می‌کنیم، خط c= و m=audio در SDP را می‌خوانیم، محدوده RTP خود تلفن را بررسی می‌کنیم و بعد با Packet Capture مشخص می‌کنیم صدا دقیقاً در کدام نقطه شبکه ناپدید می‌شود.

صدای یک‌طرفه دقیقاً یعنی چه؟

فرض کنید Cisco 8841 داخلی 201 با داخلی 202 تماس گرفته است.

اگر کاربر 201 صدای 202 را می‌شنود اما کاربر 202 هیچ صدایی از 201 دریافت نمی‌کند، تماس یک‌طرفه است.

از نظر RTP باید انتظار داشته باشیم دو جریان مستقل وجود داشته باشند:

Cisco 201  ===== RTP =====>  Cisco 202
Cisco 201  <==== RTP =====  Cisco 202

اگر فقط یکی از این دو Stream به مقصد برسد، صدا فقط در یک جهت شنیده می‌شود.

اول Signaling را از Media جدا کنید

این تماس می‌تواند از نظر SIP کاملاً سالم باشد:

INVITE  -------->
        <-------- 100 Trying
        <-------- 180 Ringing
        <-------- 200 OK
ACK     -------->

RTP     ========>
RTP     <========

پس اینکه تلفن زنگ می‌خورد و تماس Connected می‌شود ثابت نمی‌کند مسیر Audio سالم است.

چه چیزهایی بیشتر باعث صدای یک‌طرفه Cisco می‌شوند؟

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

عبارت «صدا یک‌طرفه است» برای عیب‌یابی کافی نیست.

باید دقیقاً بنویسید:

Caller: Cisco 201
Callee: 202

201 hears 202: YES
202 hears 201: NO

این یعنی باید ابتدا Stream زیر را دنبال کنیم:

201  ===== RTP =====>  202

مرحله دوم: مسیر واقعی RTP را رسم کنید

فرض نکنید همیشه Audio از PBX عبور می‌کند.

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

Phone A  <====== RTP ======>  Phone B

یا:

Phone A  <== RTP ==>  PBX/SBC  <== RTP ==>  Phone B

اگر Asterisk روی Direct Media باشد، ممکن است بعد از برقراری تماس Endpointها مستقیماً Media را به یکدیگر ارسال کنند.

اگر بین آن‌ها NAT یا Firewall وجود دارد، همین Direct Media می‌تواند دلیل صدای یک‌طرفه باشد.

مرحله سوم: SDP را بخوانید

مهم‌ترین قسمت برای پیدا کردن مقصد RTP، SDP داخل INVITE و 200 OK است.

یک SDP ساده می‌تواند چنین باشد:

v=0
o=- 98234 98234 IN IP4 192.168.20.45
s=-
c=IN IP4 192.168.20.45
t=0 0
m=audio 16426 RTP/AVP 0 8 101
a=sendrecv

خط c= در SDP چیست؟

خط:

c=IN IP4 192.168.20.45

آدرس Connection مربوط به Media را مشخص می‌کند.

اگر Cisco پشت NAT باشد ولی سمت مقابل خارج از شبکه قرار داشته باشد و همچنان یک IP خصوصی غیرقابل Route مثل 192.168.20.45 داخل SDP دیده شود، این یک سرنخ بسیار مهم است.

خط m=audio چه چیزی را مشخص می‌کند؟

مثلاً:

m=audio 16426 RTP/AVP 0 8 101

یعنی Endpoint انتظار دارد Audio روی Port 16426 دریافت شود.

Payload Typeهای بعدی نیز Codecها و Eventهای قابل استفاده را نشان می‌دهند.

c= و m= را با هم بخوانید

از ترکیب:

c=IN IP4 192.168.20.45
m=audio 16426 RTP/AVP 0 8 101

طرف مقابل نتیجه می‌گیرد RTP را به این مقصد بفرستد:

192.168.20.45:16426/UDP

یک SDP اشتباه چگونه صدا را یک‌طرفه می‌کند؟

فرض کنید Cisco پشت Router است:

Cisco LAN IP:
192.168.20.45

Public NAT IP:
203.0.113.25

اما PBX خارجی این SDP را دریافت می‌کند:

c=IN IP4 192.168.20.45

PBX خارج از شبکه نمی‌تواند RTP را مستقیماً به این Private IP بفرستد.

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

مرحله چهارم: RTP Portهای Cisco را بررسی کنید

در Cisco MPP مسیر:

Voice → SIP → RTP Parameters

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

در راهنمای فعلی MPP، مقادیر پیش‌فرض این نسل به‌صورت زیر مستند شده‌اند:

RTP Port Min = 16384
RTP Port Max = 16482

اما Firmwareهای قدیمی‌تر ممکن است Range متفاوتی داشته باشند؛ مقدار واقعی Phone را ملاک قرار دهید.

نمونه Provisioning برای RTP Range

<RTP_Port_Min ua="na">16384</RTP_Port_Min>
<RTP_Port_Max ua="na">16482</RTP_Port_Max>

چرا نباید فقط UDP 5060 را در Firewall باز کنیم؟

Port 5060 معمولاً مربوط به SIP Signaling است.

Audio روی RTP Portهای جداگانه منتقل می‌شود.

بنابراین این Policy:

ALLOW UDP 5060

می‌تواند Registration و Call Setup را سالم کند اما RTP همچنان Block شود.

Firewall باید کدام RTP Range را Allow کند؟

پاسخ به معماری شما بستگی دارد.

باید Range واقعی:

تلفن Cisco،

PBX،

SBC،

و Provider

را بدانید.

یک Range تصادفی بزرگ را فقط برای رفع موقت مشکل باز نکنید.

Firewall داخلی خود Cisco MPP

در مدل‌های MPP، Firewall داخلی تلفن نیز RTP/RTCP را بر اساس Range تنظیم‌شده باز می‌کند.

Cisco در مستند فعلی توضیح می‌دهد Range مربوط به UDP از RTP Port Min تا RTP Port Max به‌علاوه RTCP مدیریت می‌شود.

مرحله پنجم: Packet Capture بگیرید

برای صدای یک‌طرفه، Packet Capture بسیار مهم‌تر از حدس‌زدن تنظیمات است.

Capture باید قبل از تماس شروع شود.

سناریو را دقیق ثبت کنید:

Caller: 201
Callee: 202

201 hears 202: YES
202 hears 201: NO

Call time:
10:42:15

Capture را در کجا بگیریم؟

اصل طلایی: Capture را در دو سمت مقایسه کنید

فرض کنید Cisco این RTP را می‌فرستد:

192.168.20.45:16426
        ↓
203.0.113.50:18234

اگر این Packet در Capture تلفن دیده می‌شود اما در Interface خارجی Firewall دیده نمی‌شود، Phone سالم است و Drop بین Phone و Firewall رخ داده است.

اگر در Interface خارجی دیده می‌شود ولی PBX آن را دریافت نمی‌کند، مسیر WAN یا Firewall سمت Server را بررسی کنید.

Filterهای Wireshark برای این مقاله

ابتدا SIP:

sip

بعد RTP:

rtp

برای IP تلفن:

ip.addr == 192.168.20.45

و برای یک Port خاص:

udp.port == 16426

از RTP Streams در Wireshark استفاده کنید

مسیر:

Telephony → RTP → RTP Streams

را باز کنید.

در تماس عادی باید حداقل دو جهت Media را ببینید.

اگر فقط یک Stream وجود دارد، سؤال بعدی این است که آیا Endpoint دوم اصلاً RTP تولید نکرده یا Packet قبل از نقطه Capture حذف شده است.

وقتی هر دو RTP Stream دیده می‌شوند ولی صدا یک‌طرفه است

این حالت نیز ممکن است.

بررسی کنید:

Stream صحیح به IP و Port صحیح می‌رود،

Codec دو طرف هماهنگ است،

Payload Type درست Decode می‌شود،

و Packetها فقط Keepalive یا Comfort Noise نیستند.

RTP Player را برای تست استفاده کنید

اگر Media رمزگذاری نشده باشد:

Telephony → RTP → RTP Player

می‌تواند کمک کند مشخص شود Audio واقعاً داخل Packetها وجود دارد یا خیر.

اگر صدای کاربر داخل Capture سمت Phone وجود دارد اما سمت PBX وجود ندارد، محل خرابی بین این دو Capture قرار دارد.

مرحله ششم: NAT را بررسی کنید

NAT یکی از رایج‌ترین علت‌های One-Way Audio است.

مشکل معمولاً وقتی رخ می‌دهد که آدرس واقعی Packet با آدرسی که داخل SDP Advertise شده متفاوت باشد.

مثال NAT مشکل‌دار

Packet از این Public IP به PBX می‌رسد:

203.0.113.25

اما SDP می‌گوید RTP را به:

192.168.20.45

بفرستید.

اگر PBX به SDP اعتماد کند، Media برگشتی به مقصدی غیرقابل Route ارسال می‌شود.

Asterisk PJSIP برای Endpoint پشت NAT

در Asterisk، برای Endpointهای پشت NAT گزینه‌های مرتبطی وجود دارند.

نمونه:

rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

`rtp_symmetric` باعث می‌شود Asterisk RTP را به همان IP و Portی برگرداند که Media را از آن دریافت کرده است.

این گزینه برای بسیاری از Endpointهای NAT شده مفید است، اما نباید بدون شناخت معماری روی تمام Endpointها کپی شود.

اگر خود Asterisk پشت NAT باشد

در Transport باید Local Network و External Addressها مطابق شبکه واقعی تنظیم شوند.

نمونه مفهومی:

local_net=192.168.20.0/24
external_signaling_address=203.0.113.50
external_media_address=203.0.113.50

این IPها فقط مثال‌اند.

external_media_address چرا مهم است؟

اگر PBX پشت NAT باشد و داخل SDP آدرس خصوصی خودش را Advertise کند، Remote Phone ممکن است RTP را به Private IP غیرقابل دسترس بفرستد.

Asterisk از تنظیمات Transport برای تشخیص شبکه Local و جایگزین‌کردن آدرس مناسب در Media استفاده می‌کند.

مرحله هفتم: Direct Media را بررسی کنید

در PJSIP گزینه:

direct_media=yes

می‌تواند باعث شود بعد از Negotiation، Media مستقیماً بین Endpointها حرکت کند.

این در LAN می‌تواند بسیار خوب باشد، اما اگر یکی از Phoneها پشت NAT یا شبکه دیگری باشد ممکن است Reachability مستقیم وجود نداشته باشد.

برای تست Direct Media را موقتاً حذف کنید

یک آزمایش کنترل‌شده:

direct_media=no

اگر با عبور Media از Asterisk صدای دوطرفه برگردد، Reachability مستقیم Endpointها یکی از مظنون‌های اصلی است.

مرحله هشتم: SIP ALG را بررسی کنید

بعضی Routerها و Firewallها SIP ALG دارند و سعی می‌کنند SIP Header و SDP را خودکار Rewrite کنند.

این قابلیت در بعضی طراحی‌ها لازم است، اما در بعضی شبکه‌ها نیز می‌تواند:

IP داخل c= را تغییر دهد،

Port داخل m=audio را Rewrite کند،

Contact یا Via را تغییر دهد،

یا با NAT Handling خود PBX تداخل ایجاد کند.

چطور بفهمیم SIP ALG مقصر است؟

به‌جای اینکه فقط گزینه ALG را خاموش و روشن کنید، Capture دو طرف Router بگیرید.

مثلاً قبل از Router:

c=IN IP4 192.168.20.45
m=audio 16426 RTP/AVP 0 8

و بعد از Router:

c=IN IP4 203.0.113.25
m=audio 42018 RTP/AVP 0 8

اگر ALG اطلاعات را تغییر داده، حالا باید مشخص کنید Rewrite صحیح است یا باعث ارسال Media به مقصد اشتباه می‌شود.

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

قاعده بهتر این است:

اگر PBX یا SBC خودش NAT را مدیریت می‌کند و ALG Router همان اطلاعات را دوباره دست‌کاری می‌کند، ALG معمولاً باید از مسیر حذف شود.

اما تصمیم را با Packet Comparison بگیرید، نه فقط توصیه عمومی اینترنت.

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

برای One-Way Audio، فقط اینکه Firewall Session دارد کافی نیست.

باید RTP رفت و برگشت بررسی شود.

از دید Firewall چهار مشاهده مهم داریم:

Caller → Firewall Inside
Firewall Outside → Callee

Callee → Firewall Outside
Firewall Inside → Caller

اگر Stream روی یک Interface وارد می‌شود ولی روی Interface دیگر خارج نمی‌شود، محل خرابی تقریباً مشخص شده است.

Ping سالم، RTP سالم را ثابت نمی‌کند

ممکن است Ping بین دو Subnet کاملاً کار کند ولی UDP Range مربوط به RTP توسط ACL مسدود باشد.

پس نتیجه:

ping = OK

به معنی:

RTP = OK

نیست.

مرحله دهم: SDP Direction Attribute را ببینید

SDP می‌تواند Direction Media را نیز مشخص کند.

حالت معمول تماس دوطرفه:

a=sendrecv

حالت‌های دیگر:

a=sendonly
a=recvonly
a=inactive

در Hold و بعضی Featureها این حالت‌ها طبیعی هستند، اما اگر در تماس عادی Direction غیرمنتظره دیده شود باید Signaling را هم بررسی کنید.

Codec مشکل را از RTP Missing جدا کنید

اگر هیچ RTP Packetی از یک سمت نمی‌رسد، عوض‌کردن Codec اولین اقدام نیست.

اما اگر RTP در هر دو جهت وجود دارد و یکی از Streamها Audio قابل استفاده ندارد، Codec Negotiation و Payload Type را بررسی کنید.

در SDP ممکن است ببینید:

m=audio 16426 RTP/AVP 0 8 9 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000

سناریوی اول: Cisco صدا می‌فرستد ولی طرف مقابل نمی‌شنود

در Capture خود Cisco RTP خروجی دیده می‌شود.

مرحله بعد Capture روی Switch یا Firewall است.

اگر Packet از Phone خارج شده ولی بعد از Firewall وجود ندارد، مشکل Phone نیست.

سناریوی دوم: Cisco هیچ RTP خروجی ندارد

اگر تماس Connected است ولی از Phone هیچ RTP خارج نمی‌شود، این موارد را بررسی کنید:

SDP Negotiation،

Codec،

Audio Direction،

Firmware،

Headset/Handset در صورت وجود مشکل محلی،

و Log خود Phone.

در این حالت NAT سمت شبکه هنوز ممکن است مطرح باشد، اما ابتدا باید ثابت کنیم Cisco واقعاً Stream ساخته است.

سناریوی سوم: RTP به Cisco می‌رسد اما کاربر صدا ندارد

اگر Packet روی Interface تلفن مشاهده می‌شود اما Audio شنیده نمی‌شود، مسیر شبکه تا Phone سالم‌تر به نظر می‌رسد.

حالا Codec، Payload، Audio Device، Volume و Firmware را بررسی کنید.

سناریوی چهارم: تماس داخلی سالم است، تماس خارجی یک‌طرفه است

این الگو معمولاً توجه را به:

NAT،

Firewall،

SBC،

Provider،

و SDP سمت Trunk

می‌برد.

Capture یک تماس داخلی سالم و یک تماس خارجی خراب را کنار هم مقایسه کنید.

سناریوی پنجم: فقط تماس ورودی یک‌طرفه است

جهت Invite و SDP Offer/Answer را با تماس خروجی مقایسه کنید.

ممکن است Trunk در Incoming Leg آدرس یا Port متفاوتی Advertise کند یا Firewall فقط برای Sessionهای خروجی State مناسب ایجاد کند.

سناریوی ششم: فقط تلفن‌های Remote مشکل دارند

اگر Ciscoهای داخل LAN سالم هستند ولی Phoneهای Remote یک‌طرفه‌اند، NAT Handling را در اولویت قرار دهید.

در Asterisk/PJSIP معمولاً موارد زیر بررسی می‌شوند:

rtp_symmetric
force_rport
rewrite_contact
direct_media
local_net
external_media_address

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

Transfer می‌تواند Media Path را تغییر دهد.

Capture قبل و بعد از REFER یا Re-INVITE را مقایسه کنید.

به‌خصوص SDP جدید بعد از Transfer را بررسی کنید؛ ممکن است c= یا m=audio عوض شده باشد.

سناریوی هشتم: بعد از چند ثانیه صدا قطع می‌شود

این موضوع را از تماس کاملاً یک‌طرفه از ابتدا جدا کنید.

اگر Audio ابتدا دوطرفه است و بعد قطع می‌شود، مواردی مثل:

NAT Timeout،

Firewall Session،

RTP Timeout،

Re-INVITE،

و Session Change

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

سناریوی نهم: فقط وقتی SIP ALG روشن است مشکل داریم

Capture قبل و بعد Router را مقایسه کنید.

اگر ALG آدرس یا Port صحیح را با مقدار اشتباه جایگزین کرده است، آن را از مسیر خارج کنید و NAT Handling را به PBX/SBC بسپارید.

سناریوی دهم: فقط بعضی تماس‌ها مشکل دارند

RTP Portهای سالم و خراب را مقایسه کنید.

ممکن است Firewall فقط بخشی از Range را Allow کرده باشد.

مثلاً تماس سالم از:

UDP 16388

استفاده کند ولی تماس خراب از:

UDP 16470

استفاده کند که در ACL باز نشده است.

چطور با Asterisk RTP Debug بگیریم؟

برای تست کوتاه در محیط کنترل‌شده می‌توانید وارد CLI شوید:

asterisk -rvvv

و RTP Debug را برای مدت کوتاه فعال کنید:

rtp set debug on

بعد از تست آن را خاموش کنید:

rtp set debug off

روی سیستم پرترافیک Debug گسترده را برای مدت طولانی فعال نگذارید.

SIP Logger را هم کنار RTP بررسی کنید

pjsip set logger on

SDP Offer و Answer را از INVITE و 200 OK استخراج کنید و IP/Port اعلام‌شده را با RTP واقعی مقایسه کنید.

یک روش بسیار سریع برای پیدا کردن علت

ترتیب حرفه‌ای عیب‌یابی

آیا بازکردن تمام UDPها راه‌حل مناسبی است؟

برای تشخیص کوتاه‌مدت در یک محیط کاملاً کنترل‌شده ممکن است Rule موقت به شما در اثبات نقش Firewall کمک کند، اما بازکردن دائمی تمام UDPها راه‌حل نیست.

بعد از پیدا کردن Range واقعی RTP باید ACL دقیق بر اساس:

Source،

Destination،

Protocol،

و Port Range

تعریف شود.

اگر PBX روی سرور مجازی است

اگر Asterisk یا FreePBX روی سرور مجازی ایران اجرا می‌شود، فقط Firewall سیستم‌عامل را بررسی نکنید.

ممکن است چند لایه وجود داشته باشند:

Firewall سیستم‌عامل،

Cloud Firewall،

NAT،

Router سمت دفتر،

و Firewall شبکه Voice.

Capture سمت Server و سمت Office سریع‌ترین روش برای تشخیص این است که RTP در کدام لایه ناپدید می‌شود.

PCAP را یک فایل حساس در نظر بگیرید

اگر SRTP فعال نباشد، Packet Capture می‌تواند RTP خام و در بعضی شرایط محتوای قابل بازسازی مکالمه را در خود داشته باشد.

قبل از ارسال PCAP برای پشتیبانی، شماره‌ها، IPها، SIP Headerها و محتوای Audio احتمالی را در نظر بگیرید و فایل را فقط از مسیر امن ارسال کنید.

پرسش‌های متداول درباره صدای یک‌طرفه Cisco VoIP

چرا Cisco IP Phone تماس برقرار می‌کند ولی فقط یک طرف صدا دارد؟

معمولاً Signaling سالم است اما RTP در یک جهت به مقصد نمی‌رسد. NAT، Firewall، SDP اشتباه، RTP Port Range، Direct Media و SIP ALG از مهم‌ترین مواردی هستند که باید بررسی شوند.

خط c= در SDP چه چیزی را نشان می‌دهد؟

خط c= آدرس Connection مربوط به Media را مشخص می‌کند. اگر این IP از دید سمت مقابل قابل Route نباشد، RTP ممکن است به مقصد اشتباه ارسال شود.

m=audio در SDP چیست؟

m=audio نوع Media، Port دریافت Audio، Transport Profile و Payload Typeهای قابل استفاده را مشخص می‌کند.

RTP Port پیش‌فرض Cisco 8800 MPP چیست؟

در راهنمای فعلی Cisco MPP مقادیر پیش‌فرض RTP Port Min برابر 16384 و RTP Port Max برابر 16482 ذکر شده‌اند. Firmwareهای قدیمی ممکن است Range متفاوتی داشته باشند، بنابراین مقدار واقعی تلفن را بررسی کنید.

چرا باز بودن SIP 5060 برای Audio کافی نیست؟

5060 معمولاً برای SIP Signaling است، در حالی که صدای تماس روی UDP Portهای RTP جداگانه منتقل می‌شود.

آیا SIP ALG باعث صدای یک‌طرفه می‌شود؟

ممکن است. اگر ALG آدرس یا Port داخل SDP را اشتباه Rewrite کند یا با NAT Handling PBX تداخل داشته باشد، One-Way Audio ایجاد می‌شود. Capture قبل و بعد Router بهترین روش برای اثبات آن است.

rtp_symmetric در Asterisk چه کاری انجام می‌دهد؟

در PJSIP باعث می‌شود Asterisk RTP را به همان IP و Portی ارسال کند که Media را از آن دریافت کرده است؛ این قابلیت برای بعضی Endpointهای پشت NAT مفید است.

Direct Media چگونه باعث مشکل می‌شود؟

اگر Asterisk Media را مستقیماً بین Endpointها قرار دهد ولی دو تلفن Reachability مستقیم نداشته باشند، یکی از جریان‌های RTP می‌تواند شکست بخورد.

چطور بفهمیم Firewall RTP را Drop کرده است؟

Packet Capture روی Interfaceهای قبل و بعد Firewall بگیرید. اگر RTP وارد Firewall می‌شود ولی از Interface دیگر خارج نمی‌شود، Rule، NAT یا Inspection همان دستگاه را بررسی کنید.

آیا Ping سالم یعنی مسیر صدا سالم است؟

خیر. ICMP می‌تواند مجاز باشد در حالی که UDP Range مربوط به RTP توسط Firewall یا ACL مسدود شده باشد.

چطور RTP یک تماس را در Wireshark بررسی کنیم؟

از Telephony → RTP → RTP Streams استفاده کنید و دو جهت Stream را از نظر Source، Destination، Port و Packet Count مقایسه کنید.

اگر هر دو RTP Stream وجود داشته باشند ولی صدا نداریم چه؟

Codec، Payload Type، Audio Direction و وجود واقعی Audio در Stream را بررسی کنید. در Media رمزگذاری‌نشده RTP Player نیز می‌تواند کمک کند.

جمع‌بندی

برای رفع صدای یک‌طرفه Cisco IP Phone از تغییر تصادفی NAT، Codec یا Firewall شروع نکنید. ابتدا دقیقاً مشخص کنید کدام سمت صدا را نمی‌شنود و RTP خراب در چه جهتی باید حرکت کند.

بعد SDP را بخوانید. خط c= نشان می‌دهد Media به چه IPای ارسال شود و m=audio Port دریافت RTP را مشخص می‌کند. اگر IP یا Port داخل SDP با مسیر واقعی NAT هم‌خوانی ندارد، تقریباً به علت اصلی نزدیک شده‌اید.

مرحله بعد Packet Capture است. RTP را از Cisco تا Switch، Firewall و PBX دنبال کنید. نقطه‌ای که Stream وارد می‌شود اما دیگر از آن خارج نمی‌شود، محل واقعی خرابی را مشخص می‌کند.

در شبکه‌های NAT شده، تنظیمات rtp_symmetric، external_media_address، local_net و Direct Media در Asterisk اهمیت پیدا می‌کنند. SIP ALG نیز باید با مقایسه Packetهای قبل و بعد Router بررسی شود، نه با حدس.

در نهایت به‌خاطر داشته باشید تماس Connected فقط به معنی سالم بودن Signaling است. تا زمانی که RTP دوطرفه به IP و Port صحیح نرسد، تماس VoIP سالم نیست.