Amir Jabbari
اگر تماس VoIP برقرار می‌شود، طرف مقابل زنگ می‌خورد، تماس Answer می‌شود و Timer هم جلو می‌رود اما هیچ صدایی ندارید، مشکل معمولاً دیگر در SIP Signaling نیست؛ باید مسیر RTP را پیدا کنید. در VoIP، SIP تماس را برقرار می‌کند اما صدای واقعی معمولاً با RTP جابه‌جا می‌شود. به همین دلیل ممکن است پیام‌های INVITE و 200 OK کاملاً سالم باشند ولی Media به‌دلیل NAT، Firewall، آدرس اشتباه داخل SDP، Direct Media یا Media Proxy به مقصد نرسد.
این مقاله یک روش استاندارد برای عیب‌یابی RTP no audio VoIP ارائه می‌کند؛ از خود PBX و Endpoint شروع می‌کنیم، سپس NAT و Firewall را بررسی می‌کنیم، اگر RTPengine یا Media Proxy در مسیر باشد آن را کنترل می‌کنیم و در پایان با PCAP و Wireshark دقیقاً ثابت می‌کنیم Packet صدا کجا قطع می‌شود.
هدف این نیست که ده گزینه NAT را تصادفی تغییر دهید. هدف این است که برای هر Call بتوانید چهار سؤال را پاسخ دهید: RTP از کدام IP/Port باید خارج شود؟ واقعاً از کجا خارج می‌شود؟ در نقطه بعدی دیده می‌شود یا نه؟ و در جهت برگشت چه اتفاقی می‌افتد؟
قاعده اصلی: «تماس Connected است» فقط ثابت می‌کند Signaling تا حد زیادی کار کرده است. برای اثبات صدای سالم باید RTP را جداگانه بررسی کنید. در One-way Audio نیز هر جهت RTP را یک مسیر مستقل در نظر بگیرید.
RTP چیست و چرا تماس بدون آن صدا ندارد؟
RTP مخفف Real-time Transport Protocol است. RFC 3550 آن را پروتکلی برای انتقال بلادرنگ داده‌هایی مثل Audio و Video روی شبکه تعریف می‌کند. RTP معمولاً روی UDP اجرا می‌شود و Payload صوتی، Sequence Number، Timestamp و SSRC را حمل می‌کند.
در یک تماس ساده SIP، دو مسیر مستقل داریم:
Signaling:
Phone A ---- SIP ---- PBX ---- SIP ---- Phone B
Media:
Phone A ==== RTP ==== PBX ==== RTP ==== Phone Bممکن است مسیر اول سالم و مسیر دوم خراب باشد. همین موضوع توضیح می‌دهد چرا کاربر می‌گوید «تماس وصل می‌شود ولی صدا نداریم».
اول نوع خرابی صدا را مشخص کنید
قبل از دست‌زدن به Config مشخص کنید مشکل دقیقاً کدام است:
| نشانه | برداشت اولیه |
|---|---|
| هیچ‌کدام صدای هم را ندارند | RTP در یکی از نقاط مرکزی، Firewall یا Media Proxy قطع است |
| A صدای B را دارد ولی B صدای A را ندارد | One-way Audio؛ فقط مسیر A → B را دنبال کنید |
| صدا چند ثانیه اول هست و بعد قطع می‌شود | NAT Binding، RTP Timeout یا Policy Firewall |
| فقط کاربران بیرون از شرکت صدا ندارند | NAT، SDP Private IP یا Firewall |
| داخلی‌های LAN با هم سالم‌اند ولی Trunk صدا ندارد | PBX ↔ Provider Media Path |
| فقط تماس‌های عبوری از SBC خراب‌اند | Media Proxy، Interface Direction یا Advertised Address |
مرحله ۱: SDP را بخوانید؛ RTP باید به کجا برود؟
SIP پیام‌های Signaling را حمل می‌کند، اما داخل SDP آدرس و Port مربوط به Media اعلام می‌شود. بنابراین برای عیب‌یابی RTP، اولین Evidence شما SDP است.
روی Asterisk/PJSIP:
asterisk -rvvv
pjsip set logger onدر INVITE یا 200 OK بخش SDP را پیدا کنید:
c=IN IP4 203.0.113.20
m=audio 18462 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000در این مثال، طرف مقابل می‌گوید Audio را روی IP زیر و Port زیر دریافت می‌کند:
Destination RTP:
203.0.113.20:18462اگر در SDP یک IP خصوصی مثل 192.168.x.x به سمت اینترنت Advertise شده باشد، همان‌جا یک مشکل جدی پیدا کرده‌اید.
نشانه کلاسیک خطای NAT: Private IP داخل SDP
فرض کنید Asterisk پشت NAT است اما به Provider این SDP را می‌فرستد:
c=IN IP4 192.168.10.20
m=audio 12438 RTP/AVP 0Provider روی اینترنت نمی‌تواند RTP را به 192.168.10.20 Route کند. مستند رسمی Asterisk برای PJSIP در سناریوی NAT روی سه تنظیم اصلی تأکید می‌کند: local_net، external_media_address و external_signaling_address.
نمونه Transport:
[transport-udp-nat]
type=transport
protocol=udp
bind=0.0.0.0
local_net=192.168.10.0/24
external_media_address=203.0.113.50
external_signaling_address=203.0.113.50IP نمونه را با Public IP واقعی خودتان جایگزین کنید.
مرحله ۲: PBX باید داخل Media Path بماند یا Direct Media داشته باشید؟
در Asterisk گزینه direct_media مشخص می‌کند Media می‌تواند مستقیماً بین Endpointها عبور کند یا Asterisk در وسط مسیر بماند.
برای عیب‌یابی NAT، معمولاً ساده‌تر است موقتاً Media را از Asterisk عبور دهید:
[remote-phone]
type=endpoint
direct_media=noمستند Asterisk نیز در مثال NAT توضیح می‌دهد که direct_media=no باعث می‌شود Asterisk در Media Path بماند؛ موضوعی که برای PBX با Private IP پشت NAT اهمیت دارد.
تست تشخیصی: اگر با direct_media=no صدا درست می‌شود ولی با Direct Media خراب است، مشکل اصلی احتمالاً در مسیر مستقیم Endpoint ↔ Endpoint، NAT یا Firewall است؛ نه در Codec.
مرحله ۳: برای Endpoint پشت NAT تنظیم‌های Symmetric RTP را بررسی کنید
Endpointی که پشت NAT است ممکن است در SDP Port یا IPای اعلام کند که با Source واقعی Packet فرق دارد. Asterisk برای این سناریو گزینه‌های مشخصی دارد.
[remote-phone]
type=endpoint
rtp_symmetric=yes
force_rport=yes
rewrite_contact=yes
direct_media=nortp_symmetric=yes یعنی Asterisk RTP را به همان IP/Portی برگرداند که RTP از آن دریافت کرده است؛ حتی اگر SDP چیز دیگری گفته باشد. این روش برای بسیاری از Endpointهای پشت NAT کاربردی است.
force_rport و rewrite_contact بیشتر به SIP Signaling کمک می‌کنند، اما در عمل کنار rtp_symmetric در Endpointهای NATشده استفاده می‌شوند.
مرحله ۴: RTP Port Range واقعی Asterisk را با Firewall تطبیق دهید
RTP معمولاً روی یک Port ثابت مثل 5060 کار نمی‌کند. Asterisk از یک Range برای Media استفاده می‌کند که در rtp.conf تعیین می‌شود.
نمونه رایج:
[general]
rtpstart=10000
rtpend=20000اگر Firewall فقط SIP را باز کرده باشد:
5060/UDP -> OPEN
10000:20000/UDP -> CLOSEDنتیجه طبیعی می‌تواند این باشد: تماس برقرار می‌شود، اما صدا ندارید.
نمونه UFW برای Rangeای که خودتان در Asterisk تنظیم کرده‌اید:
ufw allow 10000:20000/udpRange را کورکورانه کپی نکنید؛ فایل rtp.conf خود سرور را معیار قرار دهید.
مرحله ۵: SIP ALG را به‌عنوان عامل خراب‌کننده بررسی کنید
بعضی Routerها و Firewallها SIP ALG دارند و سعی می‌کنند SIP/SDP را خودکار Rewrite کنند. در برخی شبکه‌ها این قابلیت باعث می‌شود IP یا Port داخل SDP با چیزی که PBX تنظیم کرده ناسازگار شود.
نشانه‌های محتمل:
🔹 SDPای که از PBX خارج می‌شود با چیزی که Provider دریافت می‌کند فرق دارد.
🔹 One-way Audio فقط از یک Router خاص رخ می‌دهد.
🔹 تماس داخلی سالم است ولی تماس Trunk مشکل دارد.
🔹 بعد از تغییر Firewall مشکل شروع شده است.
اگر Edge Device قابلیت Capture در WAN و LAN دارد، SDP و RTP را در هر دو سمت مقایسه کنید.
مرحله ۶: با RTP Debug ببینید Asterisk واقعاً Packet دریافت می‌کند یا نه
برای تست کوتاه روی یک تماس کنترل‌شده:
asterisk -rvvv
rtp set debug onبعد از تست حتماً خاموش کنید:
rtp set debug offدر سرور پرترافیک این خروجی بسیار زیاد می‌شود؛ برای مدت کوتاه و ترجیحاً روی تماس مشخص استفاده کنید.
یک جدول چهارطرفه برای One-way Audio بسازید
بهترین روش برای One-way Audio این است که هر Leg را جدا ببینید.
| نقطه | RTP ورودی | RTP خروجی | برداشت |
|---|---|---|---|
| Endpoint A | دارد/ندارد | دارد/ندارد | Microphone یا مسیر شبکه A |
| PBX Leg A | دارد/ندارد | دارد/ندارد | رسیدن Media از A به PBX |
| PBX Leg B | دارد/ندارد | دارد/ندارد | ارسال Media از PBX به B |
| Endpoint B | دارد/ندارد | دارد/ندارد | رسیدن/پخش Media سمت B |
مثلاً اگر PBX از A Packet دریافت می‌کند و به B هم ارسال می‌کند، اما روی شبکه B هیچ RTP دیده نمی‌شود، بین PBX و B دنبال Firewall/NAT/Route بگردید.
مرحله ۷: Endpoint را هم متهم کنید؛ همیشه مشکل از PBX نیست
اگر RTP تا Endpoint می‌رسد ولی صدا شنیده نمی‌شود، شبکه احتمالاً کار خودش را انجام داده است. در این نقطه موارد زیر را بررسی کنید:
🔹 Microphone یا Handset Mute نیست.
🔹 Output Device درست انتخاب شده است.
🔹 Endpoint Codec دریافت‌شده را Decode می‌کند.
🔹 RTP Port محلی توسط Firewall سیستم‌عامل Block نشده است.
🔹 Firmware/Softphone مشکل Audio Device ندارد.
🔹 اگر WebRTC است، Browser Permission و Audio Track سالم است.
اگر PCAP روی خود Endpoint نشان می‌دهد RTP Packetها با Payload درست وارد می‌شوند اما صدا ندارید، تغییر NAT روی PBX احتمالاً مسیر اشتباهی برای عیب‌یابی است.
مرحله ۸: اگر Media Proxy دارید، مسیر را دو Leg ببینید
در معماری Kamailio/OpenSIPS + RTPengine، RTP بین Endpointها مستقیم عبور نمی‌کند. RTPengine آدرس و Port Media را در SDP Rewrite می‌کند و در وسط مسیر قرار می‌گیرد.
RTPengine یک Media Proxy برای RTP و دیگر UDP-based Mediaهاست و می‌تواند بین Interfaceهای مختلف Bridge انجام دهد.
یک معماری ساده:
Provider
|
| RTP
v
RTPengine
|
| RTP
v
Asterisk / Endpointدر این حالت دو سؤال جدا دارید:
🔹 آیا Provider → RTPengine Media می‌رسد؟
🔹 آیا RTPengine → Backend Media را به IP/Port درست می‌فرستد؟
خطای رایج RTPengine: Interface یا Advertised Address اشتباه
RTPengine اجازه می‌دهد Address واقعی Local با Addressی که در SDP Advertise می‌شود متفاوت باشد؛ مثلاً وقتی Media Proxy پشت NAT است.
نمونه مفهومی:
Actual local IP:
10.20.0.15
Advertised public IP:
203.0.113.70در RTPengine، اگر Interfaceهای internal/external اشتباه انتخاب شوند، ممکن است SDP ظاهراً Rewrite شود اما Packet به Interface غلط ارسال شود. مستند رسمی RTPengine برای همین سناریو Logical Interface و Advertised Address جداگانه ارائه می‌کند.
مرحله ۹: PCAP بگیرید؛ اینجا حدس تمام می‌شود
وقتی Log کافی نیست، Packet Capture بهترین Evidence است. روی PBX:
tcpdump -ni any -s0 \
-w /tmp/voip-no-audio.pcap \
'udp portrange 10000-20000 or port 5060 or port 5061'اگر RTP Range شما متفاوت است، Filter را تغییر دهید.
برای یک مقصد مشخص:
tcpdump -ni any -s0 \
host 203.0.113.20 \
-w /tmp/provider-media.pcapیک تماس کوتاه ایجاد کنید، Capture را متوقف کنید و فایل را در Wireshark باز کنید.
در Wireshark از کجا RTP را ببینیم؟
Wireshark ابزارهای اختصاصی Telephony برای RTP دارد. از مسیر زیر می‌توانید Streamهای RTP را ببینید:
Telephony
-> RTP
-> RTP StreamsWireshark در RTP Streams می‌تواند Streamهای Forward و Reverse را نشان دهد و RTP Player نیز امکان مشاهده Waveform و در Codecهای پشتیبانی‌شده پخش Audio را فراهم می‌کند.
این اطلاعات را بررسی کنید:
🔹 Source IP و Destination IP هر Stream.
🔹 Source/Destination Port.
🔹 SSRC.
🔹 Packet Count.
🔹 Lost Packets.
🔹 Jitter.
🔹 Payload Type.
🔹 وجود Reverse Stream.
اگر فقط یک RTP Stream در Wireshark می‌بینید چه معنی دارد؟
برای یک تماس صوتی دوطرفه، معمولاً انتظار دارید Media در هر دو جهت وجود داشته باشد. اگر فقط یک Stream دارید، همان جهت گمشده را دنبال کنید.
Seen:
A -> B RTP
Missing:
B -> A RTP
Result:
One-way audioWireshark حتی قابلیت پیدا کردن Reverse Streamهای مرتبط را در RTP Streams دارد؛ این ویژگی برای One-way Audio بسیار کاربردی است.
Jitter و Packet Loss باعث «بی‌صدایی کامل» می‌شوند؟
معمولاً Packet Loss کم یا Jitter متوسط بیشتر کیفیت را خراب می‌کند تا اینکه Audio را کاملاً صفر کند. اما Loss شدید، Route ناپایدار یا Burst Loss می‌تواند Audio را عملاً غیرقابل‌شنیدن کند.
RFC 3550 در Header RTP از Sequence Number و Timestamp برای تشخیص ترتیب و Timing Stream استفاده می‌کند و RTCP نیز اطلاعات کنترلی و کیفیت را منتقل می‌کند.
در Troubleshooting این تفکیک را رعایت کنید:
| نشانه | تمرکز |
|---|---|
| هیچ RTP Packet وجود ندارد | NAT، Firewall، Route، SDP |
| RTP وجود دارد ولی Loss بسیار زیاد است | Network Quality |
| RTP در هر دو جهت سالم است ولی صدا شنیده نمی‌شود | Endpoint/Codec/Audio Device |
RTP و RTCP؛ یک Port یا دو Port؟
RTP معمولاً همراه RTCP استفاده می‌شود. RFC 5761 امکان Multiplex کردن RTP و RTCP روی یک UDP Port را تعریف می‌کند و این قابلیت می‌تواند NAT Traversal و Firewall Administration را ساده‌تر کند.
در Asterisk PJSIP گزینه rtcp_mux برای این رفتار وجود دارد:
rtcp_mux=yesاین گزینه را فقط زمانی فعال کنید که Endpoint یا پروفایل Media طرف مقابل از RTCP Multiplexing پشتیبانی کند.
اگر SRTP دارید، PCAP صدا را مثل RTP معمولی پخش نمی‌کند
اگر Media با SRTP رمزنگاری شده باشد، Packet Capture هنوز نشان می‌دهد Packetها وجود دارند و Source/Destination قابل‌بررسی است، اما Payload صوتی بدون کلیدهای لازم قابل Decode نیست.
پس در SRTP روی این‌ها تمرکز کنید:
🔹 آیا Packet در هر دو جهت وجود دارد؟
🔹 آیا Port و IP با SDP هماهنگ است؟
🔹 آیا DTLS/SDES Negotiation موفق شده است؟
🔹 آیا SSRC/Packet Counter حرکت می‌کند؟
نبود امکان پخش Audio در Wireshark به‌تنهایی ثابت نمی‌کند Media خراب است.
چرا صدا فقط بعد از چند ثانیه قطع می‌شود؟
این حالت با «از ابتدا هیچ صدا نداریم» فرق دارد. موارد زیر را بررسی کنید:
🔹 NAT Mapping یا UDP Timeout روی Firewall.
🔹 RTP Timeout روی PBX.
🔹 Session Timer یا re-INVITE که Media Path را تغییر داده است.
🔹 Direct Media که بعد از Answer فعال می‌شود.
🔹 Failover یا Route Change در Media Proxy.
در Asterisk گزینه‌هایی مثل rtp_timeout نیز وجود دارند. این گزینه مشخص می‌کند Endpoint در نبود RTP چه زمانی Call را Terminate کند؛ اما افزایش آن مشکل Route RTP را حل نمی‌کند.
یک روش استاندارد برای پیدا کردن محل قطع RTP
به‌جای تغییر Config، Media را Hop-by-Hop دنبال کنید:
1. Endpoint A
RTP leaves?
2. LAN side of firewall
RTP seen?
3. WAN side of firewall
RTP seen?
4. PBX / RTPengine
RTP received?
5. Outbound leg
RTP sent?
6. Endpoint B
RTP received?اولین نقطه‌ای که Packet در ورودی دیده می‌شود ولی در خروجی دیده نمی‌شود، محل اصلی بررسی است.
جدول تشخیص سریع RTP no audio
| نتیجه | مظنون اصلی |
|---|---|
| SIP سالم، هیچ RTP در PBX نیست | Endpoint/NAT/Firewall ورودی |
| RTP وارد PBX می‌شود ولی خارج نمی‌شود | Bridge/Codec/Media Policy/PBX |
| RTP از PBX خارج می‌شود ولی Provider نمی‌بیند | Firewall/NAT/Route |
| Provider RTP می‌فرستد ولی PBX نمی‌بیند | Inbound NAT/Firewall |
| هر دو Stream در PCAP هستند ولی صدا نیست | Endpoint/Audio Device/Codec Decode |
| با direct_media=no صدا درست می‌شود | مسیر مستقیم Endpointها |
| فقط با RTPengine خراب است | Interface/Direction/Advertised Address |
| فقط یک جهت Stream وجود دارد | One-way NAT/Firewall/Endpoint |
چه اطلاعاتی برای Provider یا تیم شبکه ارسال کنیم؟
برای اینکه Ticket شما رفت‌وبرگشت طولانی نداشته باشد، این Evidenceها را آماده کنید:
🔹 Timestamp دقیق تماس.
🔹 Call-ID.
🔹 SDP Offer و Answer.
🔹 IP/Port RTP هر دو Leg.
🔹 مشخص‌کردن اینکه No Audio است یا One-way Audio.
🔹 PCAP کوتاه از زمان Call Setup تا چند ثانیه بعد از Answer.
🔹 Public IP واقعی PBX/SBC.
🔹 RTP Range Firewall.
🔹 وجود یا عدم وجود Media Proxy.
اشتباه‌هایی که عیب‌یابی RTP را طولانی می‌کنند
🔹 تغییر Codec وقتی اصلاً هیچ RTP Packet وجود ندارد.
🔹 بازکردن Port 5060 و تصور اینکه Media هم باز شده است.
🔹 اعتماد به IP داخل SDP بدون مقایسه با Source واقعی Packet.
🔹 روشن گذاشتن RTP Debug روی سرور پرترافیک.
🔹 فعال‌کردن Direct Media قبل از اینکه NAT Path ثابت شده باشد.
🔹 تغییر هم‌زمان Firewall، NAT و PJSIP Config.
🔹 گرفتن PCAP فقط در یک نقطه و نداشتن مقایسه Hop-by-Hop.
🔹 مقصر دانستن Provider بدون Call-ID و Trace Media.
برای عیب‌یابی RTP و One-way Audio کمک می‌خواهید؟
اگر SIP Trace و یک PCAP کوتاه از تماس داشته باشید، می‌توان مشخص کرد RTP در Endpoint، PBX، NAT، Firewall، Provider یا Media Proxy قطع می‌شود و بدون آزمون‌وخطای گسترده همان بخش را اصلاح کرد.
ایرانیکاسرور می‌تواند برای تهیه VPS، نصب Asterisk، تنظیم NAT و Firewall، RTPengine و بررسی Packet Captureهای VoIP کمک کند.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
چرا تماس VoIP برقرار می‌شود ولی صدا نداریم؟
چون SIP Signaling و RTP Media مسیرهای جدا هستند. تماس ممکن است با SIP کامل شود ولی RTP به‌دلیل NAT، Firewall، SDP اشتباه یا Media Proxy به مقصد نرسد.
RTP معمولاً از چه Portهایی استفاده می‌کند؟
بسته به PBX و Config متفاوت است. در Asterisk Range در rtp.conf با rtpstart و rtpend مشخص می‌شود و Firewall باید همان Range واقعی را اجازه دهد.
One-way Audio معمولاً از چیست؟
اغلب یکی از دو جهت RTP به‌دلیل NAT، Firewall، SDP اشتباه یا Endpoint مشکل دارد. هر جهت RTP را جدا Capture و مقایسه کنید.
rtp_symmetric در Asterisk چه می‌کند؟
باعث می‌شود Asterisk RTP را به همان IP و Portی بفرستد که RTP از آن دریافت شده است؛ این رفتار برای بسیاری از Endpointهای پشت NAT مفید است.
آیا direct_media می‌تواند باعث قطع صدا شود؟
بله. اگر Endpointها پشت NAT یا Firewall ناسازگار باشند، مسیر مستقیم Media ممکن است برقرار نشود. برای تشخیص، موقتاً direct_media=no را آزمایش کنید.
چطور در Wireshark RTP را پیدا کنیم؟
از Telephony → RTP → RTP Streams استفاده کنید. Wireshark Streamهای RTP را فهرست می‌کند و می‌تواند Reverse Stream، Packet Loss، Jitter و در Codecهای پشتیبانی‌شده Audio را بررسی کند.
اگر PCAP RTP دارد ولی صدا نداریم چه کنیم؟
Endpoint، Audio Device، Codec Decode و در تماس‌های امن SRTP/DTLS را بررسی کنید. رسیدن Packet به Endpoint یعنی بخش مهمی از مسیر شبکه سالم است.
RTPengine چه زمانی وارد عیب‌یابی می‌شود؟
وقتی Media Proxy در مسیر دارید. در آن حالت مسیر Provider تا RTPengine و مسیر RTPengine تا Backend باید جداگانه بررسی شوند؛ Interface Direction و Advertised Address اشتباه می‌توانند No Audio بسازند.
جمع‌بندی
وقتی تماس وصل می‌شود ولی صدا ندارید، SIP را با RTP قاطی نکنید. اولین کار این است که از SDP بفهمید Media باید به کدام IP و Port برود و بعد با Capture ثابت کنید واقعاً به همان مقصد می‌رود یا نه.
در Asterisk پشت NAT، تنظیم‌های local_net، external_media_address و در Endpointهای Remote گزینه‌هایی مثل rtp_symmetric و direct_media اهمیت زیادی دارند. Firewall نیز باید RTP Range واقعی را باز کند، نه فقط Port مربوط به SIP.
اگر Media Proxy مثل RTPengine دارید، آن را یک Hop مستقل در مسیر ببینید. اگر One-way Audio دارید، فقط جهتی را دنبال کنید که Packet آن گم شده است.
در نهایت PCAP و Wireshark بهترین نقطه پایان حدس‌زدن هستند: Source/Destination، Stream Forward/Reverse، SSRC، Packet Count، Jitter و Loss به شما نشان می‌دهند RTP دقیقاً تا کجا رسیده و در کجا قطع شده است.
برای بررسی تماس بدون صدا کمک می‌خواهید؟
یک Call-ID، SIP Trace و PCAP کوتاه معمولاً کافی است تا مشخص شود RTP در کدام Hop قطع شده و آیا مشکل از PBX، Endpoint، NAT، Firewall یا Media Proxy است.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)