رفع صدای یک‌طرفه در تلفن یالینک؛ تشخیص مشکل RTP با ضبط ترافیک شبکه

در این آموزش به‌جای تغییر تصادفی Codec، NAT، Port و تنظیمات Firewall، مسیر واقعی صدا را پیدا می‌کنیم. ابتدا مشخص می‌کنیم کدام طرف صدا را نمی‌شنود، سپس SDP را می‌خوانیم، IP و Portهای RTP را استخراج می‌کنیم، Packet Capture می‌گیریم و با Wireshark بررسی می‌کنیم آیا RTP در هر دو جهت وجود دارد یا فقط یک Stream دیده می‌شود.

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

فرض کنید دو طرف تماس A و B هستند.

اگر A صدای B را می‌شنود اما B صدای A را نمی‌شنود، RTP از B به A سالم است ولی مسیر RTP از A به B مشکل دارد.

اگر B صدای A را می‌شنود اما A صدای B را نمی‌شنود، جهت عکس خراب است.

بنابراین جمله «صدا یک‌طرفه است» برای عیب‌یابی کافی نیست. باید دقیقاً بگویید:

Yealink صدا را می‌فرستد ولی دریافت نمی‌کند یا Yealink صدا را دریافت می‌کند ولی طرف مقابل صدای Yealink را ندارد.

قبل از RTP، خرابی ساده سخت‌افزاری را حذف کنید

Yealink در مستندات رسمی One-way Audio پیشنهاد می‌کند قبل از ورود به تحلیل شبکه، خروجی صوتی دیگری را امتحان کنید.

اگر صدایی از گوشی دستی شنیده نمی‌شود، تماس را روی Speaker یا Headset امتحان کنید.

اگر Speaker صدا دارد ولی Handset ندارد، مشکل می‌تواند از گوشی یا کابل Handset باشد و نیازی به دست‌کاری NAT و RTP نیست.

اگر Speaker و Headset هم همان مشکل را دارند، سراغ تحلیل شبکه بروید.

RTP چیست و چرا SIP سالم می‌تواند صدای خراب داشته باشد؟

SIP برای ساختن و مدیریت تماس استفاده می‌شود. پیام‌هایی مانند INVITE، 180 Ringing و 200 OK بخشی از Signaling هستند.

اما خود صدای تماس معمولاً با RTP یا Real-time Transport Protocol منتقل می‌شود.

به همین دلیل ممکن است این توالی کاملاً موفق باشد:

INVITE
100 Trying
180 Ringing
200 OK
ACK

اما تماس همچنان یک‌طرفه باشد؛ چون RTP مسیر متفاوتی از SIP دارد.

SDP نقشه مسیر RTP را مشخص می‌کند

داخل INVITE و 200 OK معمولاً بخشی به نام SDP وجود دارد. SDP مشخص می‌کند هر طرف می‌خواهد صدا را روی چه IP، چه Port و با چه Codecهایی دریافت کند.

نمونه ساده:

v=0
o=- 12345 12345 IN IP4 192.168.1.50
s=-
c=IN IP4 192.168.1.50
t=0 0
m=audio 11780 RTP/AVP 0 8 9
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000

دو خط از همه مهم‌تر هستند:

c=IN IP4 192.168.1.50
m=audio 11780 RTP/AVP ...

این SDP می‌گوید فرستنده انتظار دارد RTP صوتی را روی IP زیر دریافت کند:

192.168.1.50

و Port دریافت RTP برابر است با:

11780

اولین خطای بزرگ: IP خصوصی داخل SDP

اگر تلفن Yealink پشت NAT قرار دارد و PBX یا طرف مقابل روی اینترنت است، IP خصوصی مانند موارد زیر از اینترنت قابل مسیریابی نیست:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

فرض کنید Yealink داخل شبکه این IP را دارد:

192.168.1.50

اما Public IP شبکه:

185.10.20.30

اگر PBX برای ارسال RTP از SDP نتیجه بگیرد که باید بسته‌ها را به این مقصد بفرستد:

192.168.1.50:11780

این بسته‌ها از اینترنت به تلفن نمی‌رسند.

پس NAT باید چه کاری انجام دهد؟

در یک معماری درست، یکی از اجزای SIP Server، SBC، Media Proxy یا NAT-aware PBX باید مسیر واقعی Media را مدیریت کند.

مثلاً ممکن است RTP تلفن در عمل از این Mapping دیده شود:

Yealink:
192.168.1.50:11780

Public NAT:
185.10.20.30:43218

سرور باید Media را به مسیری بفرستد که واقعاً به تلفن می‌رسد.

مرحله اول: با Packet Capture بفهمید کدام RTP گم شده است

Yealink امکان گرفتن PCAP از خود تلفن را دارد. در بسیاری از مدل‌ها وارد رابط وب شوید و مسیر زیر را باز کنید:

Settings → Configuration

در بخش Pcap Feature:

Capture را Start کنید.

یک تماس ایجاد کنید.

حداقل ۲۰ تا ۳۰ ثانیه صحبت کنید.

سپس Capture را Stop و فایل PCAP را Export کنید.

بهتر است Capture قبل از شروع تماس فعال باشد تا SIP و SDP نیز همراه RTP ثبت شوند.

PCAP خیلی کوتاه نگیرید

اگر Capture فقط بعد از برقرارشدن تماس شروع شود، ممکن است INVITE و SDP را از دست بدهید.

در آن صورت RTP دارید ولی نمی‌دانید هر Stream بر اساس چه IP و Portی مذاکره شده است.

ترتیب بهتر:

Start Capture
↓
شروع تماس
↓
۲۰ تا ۳۰ ثانیه مکالمه
↓
پایان تماس
↓
Stop Capture

در Wireshark اول SIP را پیدا کنید

فایل PCAP را با Wireshark باز کنید.

فیلتر زیر را وارد کنید:

sip

INVITE و پاسخ 200 OK را پیدا کنید.

در هر کدام بخش SDP را باز کنید و این موارد را یادداشت کنید:

IP Media هر طرف.

Port RTP هر طرف.

Codecهای پیشنهادشده.

Codec نهایی انتخاب‌شده.

یک جدول ساده برای خودتان بسازید

حالا می‌توانید RTP واقعی را با چیزی که در SDP توافق شده مقایسه کنید.

RTP Streamها را در Wireshark ببینید

در Wireshark از مسیر زیر استفاده کنید:

Telephony → RTP → RTP Streams

در یک تماس صوتی دوطرفه معمولاً باید دو جهت RTP مشاهده شود.

مثلاً:

Yealink → PBX
PBX → Yealink

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

سناریو اول: Yealink RTP می‌فرستد ولی هیچ RTP دریافت نمی‌کند

این همان سناریویی است که Yealink در مستندات رسمی One-way Audio توضیح می‌دهد.

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

طرف مقابل اصلاً RTP نمی‌فرستد.

RTP را به IP اشتباه می‌فرستد.

RTP را به Port اشتباه می‌فرستد.

PBX یا SBC Media را Forward نمی‌کند.

Firewall بسته RTP را Drop می‌کند.

NAT Mapping درست نیست.

در این وضعیت چه چیزی را با SDP مقایسه کنیم؟

فرض کنید Yealink در SDP اعلام کرده:

c=IN IP4 10.81.4.173
m=audio 12290 RTP/AVP 0 8

طبق این SDP، طرف مقابل باید Media را به:

10.81.4.173:12290

ارسال کند.

اگر در PCAP سمت Server می‌بینید RTP به Port دیگری ارسال شده، مشکل پیدا شده است.

سناریو دوم: RTP به Firewall می‌رسد اما به Yealink نمی‌رسد

در این حالت Capture سمت WAN و LAN Router بسیار مفید است.

اگر RTP روی WAN وجود دارد:

203.0.113.20 → 185.10.20.30:43218

ولی روی LAN چیزی به Yealink نمی‌رسد:

192.168.1.50:11780

مشکل در NAT، Firewall State، ALG یا Port Mapping قرار دارد.

فایروال باید Range RTP را بشناسد

RTP معمولاً از یک بازه UDP استفاده می‌کند، نه فقط یک Port ثابت.

در مستندات فعلی بعضی مدل‌های Yealink مانند خانواده T31، بازه پیش‌فرض Local RTP Port از:

11780

تا:

12780

ذکر شده است.

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

در مدل‌هایی که این گزینه را دارند مسیر معمولاً:

Network → Advanced → Local RTP Port

است.

چرا بازکردن فقط UDP 5060 مشکل صدا را حل نمی‌کند؟

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

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

ممکن است تماس کاملاً برقرار شود چون SIP 5060 عبور می‌کند، اما Firewall تمام UDPهای RTP را مسدود کند.

نتیجه می‌تواند تماس بدون صدا یا صدای یک‌طرفه باشد.

اگر PBX Asterisk دارید Range RTP را بررسی کنید

در بسیاری از نصب‌های Asterisk، RTP روی Range تعریف‌شده در rtp.conf کار می‌کند.

در نمونه رسمی NAT در مستندات Asterisk بازه زیر استفاده شده است:

UDP 10000-20000

اما تنظیم واقعی سرور خود را بررسی کنید و فقط بر اساس مقدار پیش‌فرض Firewall نسازید.

مرحله دوم: private/public IP را در SDP بررسی کنید

اگر PBX پشت NAT قرار دارد نیز همین مشکل از سمت Server ممکن است رخ دهد.

مثلاً Asterisk روی:

192.168.10.10

است ولی Public IP سرور:

203.0.113.10

اگر Asterisk داخل SDP این را بفرستد:

c=IN IP4 192.168.10.10

یک Yealink خارج از آن شبکه نمی‌تواند RTP را به IP خصوصی Server ارسال کند.

در این حالت تنظیم NAT سمت PBX باید اصلاح شود.

تنظیمات مهم NAT در Asterisk PJSIP

مستندات رسمی Asterisk برای Server پشت NAT به گزینه‌هایی مانند موارد زیر اشاره می‌کند:

local_net=
external_media_address=
external_signaling_address=

برای Endpointهای Remote پشت NAT نیز گزینه‌هایی مانند این‌ها اهمیت دارند:

rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes

اما هر سه گزینه یک کار انجام نمی‌دهند.

rtp_symmetric در Asterisk چیست؟

در Asterisk، گزینه:

rtp_symmetric=yes

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

این قابلیت برای تلفن‌هایی که پشت NAT قرار دارند بسیار مفید است، چون Port واقعی NAT ممکن است با Port اعلام‌شده در SDP متفاوت باشد.

مثال Symmetric RTP

Yealink در SDP اعلام می‌کند:

192.168.1.50:11780

ولی Asterisk RTP را از این آدرس دریافت می‌کند:

185.10.20.30:43218

با Symmetric RTP، Server می‌تواند Media را به همان Source واقعی برگرداند:

185.10.20.30:43218

نه لزوماً آدرسی که داخل SDP اعلام شده است.

Symmetric RTP در خود Yealink با Asterisk یک مفهوم یکسان ندارد

این نکته مهم است. Yealink نیز گزینه‌ای با نام Symmetrical RTP دارد، اما رفتار مستندشده آن در بعضی Firmwareها بیشتر درباره پذیرش یا رد RTP ورودی بر اساس IP و Port مذاکره‌شده است.

برای نمونه مقدارهای آن می‌توانند مشخص کنند RTP از IP یا Port مذاکره‌نشده رد شود.

بنابراین گزینه Symmetric RTP روی Yealink را با rtp_symmetric=yes در Asterisk یکسان فرض نکنید.

اگر Yealink RTP را به دلیل IP یا Port رد کند چه می‌شود؟

فرض کنید SDP می‌گوید RTP باید از:

203.0.113.20:18042

بیاید.

اما به دلیل NAT یا Media Proxy بسته‌های واقعی از:

203.0.113.30:25000

می‌رسند.

اگر Yealink طوری تنظیم شده باشد که RTP از IP یا Port مذاکره‌نشده را رد کند، ممکن است Packet وارد Interface شود ولی برای Audio استفاده نشود.

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

در بعضی PBXها Media می‌تواند مستقیماً بین دو Endpoint منتقل شود.

این قابلیت معمولاً Direct Media نامیده می‌شود.

مثلاً:

Yealink A  ← RTP مستقیم →  Yealink B

به‌جای:

Yealink A → Asterisk → Yealink B

اگر Endpointها پشت NATهای مختلف باشند، Direct Media می‌تواند باعث One-way Audio شود.

برای تست، Media را موقتاً از PBX عبور دهید

در Asterisk PJSIP می‌توانید برای آزمایش Endpoint موردنظر را با:

direct_media=no

بررسی کنید.

مستندات رسمی Asterisk در مثال NAT نیز Direct Media را غیرفعال می‌کند تا Server در مسیر Media باقی بماند.

اگر با direct_media=no صدای یک‌طرفه برطرف شد، مسیر مستقیم RTP بین Endpointها را بررسی کنید.

بعد از تست تغییر را دائمی نکنید مگر علت روشن باشد

Direct Media مزایا و محدودیت‌های خودش را دارد.

اگر آن را فقط برای تشخیص خاموش کرده‌اید، بعد از یافتن علت تصمیم بگیرید معماری نهایی باید Direct Media داشته باشد یا Media Relay از PBX انجام شود.

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

گاهی RTP در هر دو جهت وجود دارد ولی یکی از طرف‌ها همچنان صدا ندارد.

در این حالت Codec اهمیت پیدا می‌کند.

Yealink در راهنمای رسمی خود یکی از علت‌های One-way Audio را این می‌داند که طرف مقابل RTP را با Codec متفاوتی از Codec مذاکره‌شده ارسال می‌کند.

Codec مذاکره‌شده را از SDP پیدا کنید

مثلاً:

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

اگر پاسخ SDP در نهایت PCMA را انتخاب کند، RTP باید با Payload Type مربوط به همان Codec هماهنگ باشد.

Payload Type را در Wireshark بررسی کنید

یکی از Packetهای RTP را باز کنید.

در بخش Real-Time Transport Protocol مقدار:

Payload type

را ببینید.

سپس آن را با rtpmap در SDP مقایسه کنید.

اگر دو طرف درباره Codec توافق کرده‌اند ولی Media با Format دیگری می‌آید، مشکل Server، SBC یا Media Gateway باید بررسی شود.

features.rtp_adapte.enable در Yealink چیست؟

Yealink در راهنمای رسمی One-way Audio برای یک سناریوی خاص Codec Mismatch به پارامتر زیر اشاره می‌کند:

features.rtp_adapte.enable=1

اما این را به‌عنوان اولین راه‌حل فعال نکنید.

خود Yealink نیز توصیه می‌کند علت سمت Server بررسی شود تا همان مشکل روی مدل‌های دیگر هم تکرار نشود.

اول مشخص کنید RTP واقعاً با Codec متفاوت از SDP ارسال شده است؛ سپس سراغ چنین تنظیمی بروید.

مرحله پنجم: Direction در SDP را بررسی کنید

SDP فقط IP، Port و Codec نیست. Direction Media نیز می‌تواند مشخص شود.

مقادیر رایج:

a=sendrecv
a=sendonly
a=recvonly
a=inactive

اگر Media روی:

a=sendonly

قرار گرفته باشد، آن طرف فقط Media می‌فرستد.

اگر:

a=recvonly

باشد، فقط Media دریافت می‌کند.

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

a=sendrecv

است یا این Attribute حذف می‌شود که در مدل Offer/Answer مقدار پیش‌فرض sendrecv محسوب می‌شود.

Hold را با One-way Audio اشتباه نگیرید

هنگام Hold ممکن است SDP عمداً به sendonly یا inactive تغییر کند.

اگر مشکل دقیقاً بعد از Hold/Resume یا Transfer ظاهر می‌شود، Re-INVITE و SDP جدید را بررسی کنید.

ممکن است تماس اولیه سالم باشد اما Re-INVITE بعدی IP، Port یا Direction اشتباه بدهد.

مرحله ششم: RTP Stream Analysis در Wireshark

در Wireshark وارد:

Telephony → RTP → RTP Streams

شوید.

Stream موردنظر را انتخاب کنید و Analyze را بزنید.

Wireshark می‌تواند اطلاعاتی مانند:

Packet Count.

Packet Loss.

Sequence Error.

Jitter.

Maximum Delta.

را نمایش دهد.

چطور یک Stream سالم را تشخیص دهیم؟

برای تشخیص One-way Audio، اولین نکته تعداد Packetها در هر جهت است.

اگر تماس ۳۰ ثانیه‌ای دارید و یک جهت صدها RTP Packet دارد ولی جهت دیگر صفر است، مشکل بسیار روشن است.

اگر هر دو جهت RTP دارند ولی یکی Packet Loss شدید دارد، دیگر مسئله فقط «نبود Stream» نیست و باید کیفیت شبکه را بررسی کنید.

فیلترهای مفید Wireshark

برای تمام RTPهایی که Wireshark تشخیص داده است:

rtp

برای SIP:

sip

برای UDP:

udp

اگر Wireshark RTP را خودکار تشخیص نداد، روی UDP Stream موردنظر:

Decode As → RTP

را امتحان کنید؛ البته ابتدا با SDP مطمئن شوید همان Port مربوط به RTP است.

چطور فقط RTP مربوط به Yealink را ببینیم؟

اگر IP تلفن:

192.168.1.50

است، می‌توانید از این فیلتر استفاده کنید:

ip.addr == 192.168.1.50 && rtp

یا برای UDP:

ip.addr == 192.168.1.50 && udp

سه Capture بهترین نتیجه را می‌دهند

اگر شبکه اجازه می‌دهد، Capture را در سه نقطه بگیرید:

روی خود Yealink.

روی PBX یا SBC.

روی Firewall یا Router.

با این کار می‌توانید Packet را در مسیر دنبال کنید.

مثال عملی: RTP از PBX خارج می‌شود ولی به Yealink نمی‌رسد

در PCAP PBX می‌بینید:

203.0.113.20:18042
→
185.10.20.30:43218

در WAN Firewall همان Packet دیده می‌شود.

اما در LAN Firewall هیچ Packetی به:

192.168.1.50:11780

وجود ندارد.

این نتیجه تقریباً تلفن و Codec را از مظنون اصلی خارج می‌کند.

NAT Rule، Stateful Firewall، ALG و Port Mapping را بررسی کنید.

مثال عملی: RTP به Yealink می‌رسد ولی Audio نداریم

اگر PCAP خود Yealink RTP ورودی را نشان می‌دهد، شبکه تا Interface تلفن کار کرده است.

حالا این موارد را بررسی کنید:

Payload Type.

Codec واقعی.

Source IP.

Source Port.

Symmetrical RTP Policy.

SRTP/RTP.

Audio Channel.

SRTP را هم فراموش نکنید

اگر تماس از SRTP استفاده می‌کند، Media رمزگذاری شده است.

اگر یک طرف RTP معمولی و طرف دیگر SRTP انتظار داشته باشد، تماس می‌تواند بدون Audio یا با شکست Negotiation روبه‌رو شود.

در SDP به Protocol روی خط m=audio و Attributeهای مرتبط با Crypto یا DTLS توجه کنید.

SIP ALG چگونه می‌تواند RTP را خراب کند؟

SIP ALG ممکن است SDP را بازنویسی کند.

اگر ALG IP یا Port داخل:

c=
m=audio

را اشتباه تغییر دهد، طرف مقابل RTP را به مقصد نادرست می‌فرستد.

برای تشخیص، SDP قبل و بعد از Router را مقایسه کنید.

اگر مقدار Media Address بدون انتظار تغییر کرده، ALG یا SIP Helper را بررسی کنید.

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

یکی از تست‌های بسیار مفید این است که دو تلفن داخل همان LAN مستقیماً یا از طریق PBX با هم تماس بگیرند.

اگر تماس داخلی Audio دوطرفه دارد ولی تماس از PSTN یا Trunk یک‌طرفه است، سخت‌افزار تلفن احتمالاً سالم است.

تمرکز را روی:

Trunk.

SBC.

PBX NAT.

Firewall.

Media Gateway.

قرار دهید.

Yealink نیز IP Call را برای تفکیک مشکل پیشنهاد می‌کند

در مستندات رسمی Audio، Yealink پیشنهاد می‌کند IP Call بین تلفن‌ها آزمایش شود.

اگر IP Call سالم است ولی تماس از طریق Server یک‌طرفه می‌شود، مشکل بیشتر در محیط شبکه یا Server قرار دارد.

اگر حتی IP Call هم یک‌طرفه است، تلفن، شبکه محلی یا Hardware را جدی‌تر بررسی کنید.

آیا Codec را تصادفی محدود کنیم؟

خیر.

گاهی پیشنهاد می‌شود تمام Codecها حذف و فقط PCMA یا PCMU فعال شود.

این کار می‌تواند یک Test تشخیصی باشد، اما نباید بدون دیدن SDP به راه‌حل دائمی تبدیل شود.

ابتدا ببینید چه Codecهایی Offer و Answer شده‌اند و RTP واقعاً با چه Payload Typeی ارسال شده است.

Packet Loss با One-way Audio واقعی فرق دارد

اگر RTP در هر دو جهت وجود دارد اما Packet Loss بالاست، ممکن است صدا بریده، رباتی یا ناقص باشد.

در One-way Audio واقعی معمولاً یک Stream کاملاً غایب است یا تلفن آن را به‌دلیل IP، Port، Codec یا Security Policy نمی‌پذیرد.

در Wireshark این دو حالت را از هم جدا کنید.

اگر صدا فقط چند ثانیه اول کار می‌کند چه؟

در این حالت NAT Timeout، Re-INVITE، Session Update و Media Path Change را بررسی کنید.

تماس را از ابتدا تا لحظه قطع Audio Capture کنید.

بررسی کنید قبل از قطع صدا آیا Re-INVITE یا UPDATE جدیدی ارسال شده است.

SDP قبل و بعد از آن را مقایسه کنید.

اگر مشکل فقط بعد از Transfer ایجاد می‌شود چه؟

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

قبل و بعد از Transfer:

IP Media.

RTP Port.

Codec.

Direction.

را مقایسه کنید.

ممکن است تماس اولیه Media را از PBX بگیرد ولی پس از Transfer Direct Media فعال شود و NAT مسیر جدید را مسدود کند.

اگر مشکل فقط تماس ورودی است

اگر تماس خروجی Audio دوطرفه دارد اما تماس ورودی یک‌طرفه است، SDP دو سناریو را کنار هم قرار دهید.

ممکن است Provider در تماس ورودی Media Server متفاوتی استفاده کند.

Firewall ممکن است فقط Range یا IP بعضی Media Serverها را اجازه داده باشد.

Source IP RTP ورودی و خروجی را مقایسه کنید.

اگر مشکل فقط تماس خروجی است

برعکس، اگر تماس ورودی سالم و خروجی یک‌طرفه است، Trunk Route، SDP خروجی PBX و Media Relay مربوط به Outbound Call را بررسی کنید.

باز هم مهم‌ترین اصل این است که با PCAP مشخص کنید RTP دقیقاً در کدام جهت گم شده است.

چک‌لیست عیب‌یابی صدای یک‌طرفه Yealink

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

چرا تماس Yealink برقرار می‌شود ولی یک طرف صدا ندارد؟

معمولاً Signaling سالم است اما RTP در یکی از جهت‌ها نمی‌رسد. IP و Port داخل SDP، NAT، Firewall، RTP Port Range، Codec و Symmetric RTP را بررسی کنید.

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

از Packet Capture و Wireshark استفاده کنید. در Telephony → RTP → RTP Streams باید Streamهای هر دو جهت را ببینید. نبود یکی از Streamها مسیر خراب را مشخص می‌کند.

آیا Port 5060 برای صدا کافی است؟

خیر. 5060 معمولاً برای SIP Signaling است. RTP روی Portهای UDP جداگانه منتقل می‌شود و Firewall باید Range واقعی Media را نیز مدیریت کند.

RTP Port پیش‌فرض Yealink چیست؟

مقدار دقیق به مدل و Firmware بستگی دارد. در مستندات فعلی بعضی مدل‌های Yealink مانند T31 بازه 11780 تا 12780 ذکر شده است. مقدار واقعی دستگاه را در تنظیمات Network بررسی کنید.

چرا private IP داخل SDP مشکل ایجاد می‌کند؟

اگر طرف مقابل خارج از LAN باشد، IP خصوصی قابل Route نیست. PBX، SBC یا NAT-aware Media Server باید Public Media Path صحیح را در اختیار طرف مقابل قرار دهد.

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

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

اگر RTP در هر دو جهت وجود داشته باشد ولی باز هم صدا یک‌طرفه باشد چه کنیم؟

Codec، Payload Type، SRTP، Source IP/Port و Policy مربوط به Symmetrical RTP در تلفن را بررسی کنید. ممکن است Packet برسد ولی قابل استفاده نباشد.

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

بله. اگر ALG مقادیر SDP مانند Media IP یا Port را اشتباه بازنویسی کند، RTP به مقصد غلط می‌رود. SDP قبل و بعد از Router را مقایسه کنید.

جمع‌بندی

برای رفع صدای یک‌طرفه در Yealink، تغییر تصادفی Codec و بازکردن Portهای مختلف معمولاً فقط تشخیص را سخت‌تر می‌کند. ابتدا با SIP و SDP مشخص کنید هر طرف باید RTP را روی چه IP و Portی دریافت کند.

بعد با Packet Capture ببینید RTP واقعاً در هر دو جهت وجود دارد یا نه. اگر Yealink RTP می‌فرستد ولی دریافت نمی‌کند، مسیر Server تا تلفن را بررسی کنید. اگر Server RTP ارسال می‌کند ولی Packet به تلفن نمی‌رسد، NAT و Firewall را بررسی کنید. اگر Packet به تلفن می‌رسد ولی Audio ندارید، Codec، Payload Type، SRTP و سیاست Symmetrical RTP مهم می‌شوند.

وقتی SDP، PCAP تلفن و Capture سمت PBX را کنار هم قرار دهید، صدای یک‌طرفه دیگر یک مشکل مبهم نیست؛ دقیقاً می‌توانید نشان دهید RTP در کدام IP، Port یا مرحله از مسیر از بین رفته است.