Amir Jabbari
برای مثال، 403 Forbidden هنگام REGISTER می‌تواند به سیاست رجیستر، حساب غیرفعال یا محدودیت Provider مربوط باشد؛ همان 403 در یک INVITE ممکن است به مجوز تماس، Caller ID یا Destination Policy مربوط شود. 488 Not Acceptable Here نیز معمولاً به مذاکره Media نزدیک است و فقط «Codec خراب» معنی نمی‌دهد؛ SRTP، SDP و حتی روش DTMF هم می‌توانند وارد ماجرا شوند.
در این آموزش هر چهار خطا را از سه دید بررسی می‌کنیم: خود Cisco Phone، PBX/SBC و SIP Provider. سپس مشخص می‌کنیم چه لاگی بگیرید و چطور با Packet Capture ثابت کنید خطا دقیقاً در کدام بخش تولید شده است.
قاعده اصلی: قبل از تغییر تنظیمات، در SIP Trace ابتدا Request را پیدا کنید و بعد Response را. یک 403 بدون دانستن اینکه پاسخ REGISTER، INVITE، REFER یا SUBSCRIBE بوده، برای تشخیص کافی نیست.
اول مطمئن شوید خطا واقعاً SIP است، نه HTTP
در Cisco MPP کدهای 403، 404 و 503 می‌توانند در دو زمینه کاملاً متفاوت دیده شوند:
SIP: هنگام REGISTER، INVITE، REFER، SUBSCRIBE یا سایر پیام‌های VoIP.
HTTP/HTTPS: هنگام دانلود فایل Provisioning، Resync یا Firmware Upgrade.
مثلاً اگر تلفن هنگام دریافت فایل Config با HTTP 404 مواجه شود، معنی آن این است که Resource مورد درخواست روی Web Server پیدا نشده است. اما SIP 404 معمولاً به User/Domain موجود در Request-URI مربوط می‌شود.
پس در PCAP به Protocol و Request قبلی نگاه کنید.
چه کسی Response را فرستاده است؟
یکی از مهم‌ترین مراحل عیب‌یابی همین است.
در Wireshark روی Response کلیک کنید و این موارد را بررسی کنید:
🔹 Source IP
🔹 Via
🔹 Server Header در صورت وجود
🔹 User-Agent در پیام‌های مرتبط
🔹 Call-ID
🔹 CSeq
اگر Source IP متعلق به PBX شماست، ممکن است اصلاً Provider آن کد را تولید نکرده باشد.
اگر Source IP متعلق به SBC یا Provider است، آن‌وقت Provider Policy و Trunk مهم‌تر می‌شوند.
جدول سریع معنی 403، 404، 488 و 503
| کد | معنی استاندارد | مظنون اصلی |
|---|---|---|
| 403 Forbidden | درخواست فهمیده شده اما رد شده است | Policy، مجوز، Provider، Account |
| 404 Not Found | User یا Domain موردنظر پیدا نشده | Dial Plan، Request-URI، Route |
| 488 Not Acceptable Here | Session برای این مقصد قابل قبول نیست | SDP، Codec، SRTP، Media |
| 503 Service Unavailable | سرویس موقتاً قادر به پردازش درخواست نیست | Server، Upstream، Overload، Maintenance |
خطای 403 Forbidden در Cisco SIP Phone یعنی چه؟
طبق RFC 3261، سرور درخواست را فهمیده اما از انجام آن خودداری می‌کند.
نکته مهم این است که 403 با 401 Unauthorized یکی نیست.
401 یا 407 معمولاً بخشی از Challenge Authentication هستند و Endpoint می‌تواند درخواست را با Credential مناسب دوباره بفرستد.
اما 403 معمولاً یعنی Server پس از بررسی درخواست، آن را مجاز نمی‌داند.
403 هنگام REGISTER
اگر Cisco Phone در زمان Registration این Flow را دارد:
REGISTER
401 Unauthorized
REGISTER + Authorization
403 Forbiddenاین Flow معمولاً نشان می‌دهد Authentication Challenge انجام شده ولی Server درخواست نهایی را قبول نکرده است.
موارد محتمل:
🔹 Account غیرفعال یا Suspend شده است.
🔹 Auth ID با SIP URI یا Extension مورد انتظار Provider هماهنگ نیست.
🔹 Provider اجازه Registration از IP یا Region فعلی را نمی‌دهد.
🔹 هم‌زمانی Registration بیشتر از Policy سرویس است.
🔹 Device یا Account در ACL/Policy سرور مجاز نیست.
🔹 Provider از Credential صحیح هم درخواست را به دلیل Policy رد می‌کند.
اشتباه رایج: هر 403 را «پسورد اشتباه» ندانید
Wrong Password ممکن است باعث Authentication Failure شود، اما 403 از نظر استاندارد به معنی «Request فهمیده شد ولی اجازه انجام آن داده نشد» است.
Providerها می‌توانند Policyهای متفاوتی داشته باشند، بنابراین برای 403 باید هم SIP Trace و هم Log Server را ببینید.
403 هنگام تماس خروجی یا INVITE
اگر Phone Registered است اما هنگام Dial کردن این Flow را دارید:
INVITE sip:DESTINATION@provider.example
SIP/2.0 403 Forbiddenعلت‌ها فرق می‌کنند.
🔹 Destination برای این Account مجاز نیست.
🔹 International/Premium Calling در Provider بسته است.
🔹 Caller ID یا From Header مورد قبول نیست.
🔹 Dial Plan PBX تماس را به Route ممنوع می‌فرستد.
🔹 Provider Account اعتبار یا مجوز لازم ندارد.
🔹 SBC بر اساس Policy تماس را Reject می‌کند.
برای 403 چه چیزی را Verify کنیم؟
این موارد را کنار هم بگذارید:
🔹 Request-URI
🔹 From
🔹 To
🔹 Contact
🔹 Authorization Username
🔹 Source IP
🔹 Provider/PBX Log در همان Timestamp
اگر فقط یک Destination خطای 403 می‌دهد ولی سایر شماره‌ها سالم‌اند، مشکل کلی Registration کمتر محتمل است و باید Route/Permission همان Destination را بررسی کنید.
خطای 404 Not Found در Cisco SIP یعنی چه؟
در SIP، 404 معمولاً یعنی سرور اطلاعات قطعی دارد که User موجود در Request-URI در آن Domain وجود ندارد، یا آن Domain جزو Domainهایی نیست که Server برای آن‌ها سرویس می‌دهد.
در عمل این خطا بیشتر به Dial Plan، URI یا Route مربوط می‌شود.
404 هنگام تماس خروجی
مثلاً Cisco این INVITE را می‌فرستد:
INVITE sip:205@pbx.example.net SIP/2.0و PBX پاسخ می‌دهد:
SIP/2.0 404 Not Foundاین موارد را بررسی کنید:
🔹 آیا داخلی 205 واقعاً وجود دارد؟
🔹 آیا Dial String روی Phone درست است؟
🔹 آیا PBX آن Destination را در Context فعلی می‌بیند؟
🔹 آیا Domain داخل Request-URI درست است؟
🔹 آیا SBC شماره را Rewrite کرده است؟
🔹 آیا Route Pattern مقصد را به Trunk درست می‌فرستد؟
404 از Provider چه معنی عملی دارد؟
اگر PBX تماس را به Provider می‌فرستد و Provider 404 می‌دهد، ممکن است شماره مقصد از نظر Provider نامعتبر یا Unallocated باشد.
اما قبل از نتیجه‌گیری، Request-URI خروجی PBX را ببینید.
گاهی مشکل فقط Format شماره است:
مثلاً Provider انتظار E.164 دارد ولی PBX Prefix یا Country Code را اشتباه فرستاده است.
404 در Registration
404 روی REGISTER نیز ممکن است دیده شود، مخصوصاً اگر Registrar یا Domain اشتباه باشد.
در این حالت این موارد را بررسی کنید:
🔹 SIP Server / Registrar
🔹 Register Address
🔹 Auth ID
🔹 User ID
🔹 Domain داخل To/Request-URI
اگر Phone به Registrar اشتباه وصل شده باشد، Credential صحیح هم مشکل را حل نمی‌کند.
404 SIP را با HTTP 404 Provisioning اشتباه نگیرید
اگر در Log عبارت HTTP دیده می‌شود و URL فایل Config درخواست شده، مسئله کاملاً متفاوت است.
مثلاً:
GET /cfg/SEP001122334455.xml
HTTP/1.1 404 Not Foundاینجا باید Path فایل، Filename، Web Root و Provisioning URL را بررسی کنید؛ Dial Plan هیچ نقشی ندارد.
خطای 488 Not Acceptable Here یعنی چه؟
این کد معمولاً مهم‌ترین خطای Media در این چهار مورد است.
طبق RFC 3261، 488 یعنی Session پیشنهادی برای همین Resource قابل قبول نیست و ممکن است Request مشابه در مقصد دیگری موفق شود.
Cisco نیز در راهنمای عیب‌یابی SIP خود، 488 را به شکست Media Negotiation مرتبط می‌کند.
رایج‌ترین علت 488: هیچ Codec مشترکی وجود ندارد
مثلاً Cisco در SDP فقط این Codecها را پیشنهاد می‌دهد:
m=audio 16420 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000اما Endpoint مقصد فقط Codec دیگری را قبول می‌کند و Transcoding هم در PBX وجود ندارد.
نتیجه می‌تواند 488 باشد.
در Asterisk خالی‌شدن Codec Topology می‌تواند 488 تولید کند
در مستندات فعلی PJSIP، Asterisk صریحاً توضیح می‌دهد اگر بعد از Codec Negotiation هیچ Stream/Codec سازگاری باقی نماند، تماس می‌تواند فوراً با:
488 Not Acceptable Hereتمام شود.
اما 488 فقط Codec نیست
این موارد نیز می‌توانند باعث 488 شوند:
🔹 SRTP اجباری در یک سمت و RTP معمولی در سمت دیگر
🔹 Crypto/DTLS-SRTP Policy ناسازگار
🔹 SDP ناقص یا پارامتر Media غیرقابل قبول
🔹 DTMF Method ناسازگار در بعضی پیاده‌سازی‌ها
🔹 Video Stream یا Media Type پشتیبانی‌نشده
🔹 re-INVITE بعد از Hold/Transfer که Media جدید قابل قبول نیست
488 فقط در تماس Transfer یا Hold دیده می‌شود
این یک سرنخ بسیار خوب است.
اگر تماس اولیه با 200 OK برقرار می‌شود ولی بعد از Hold، Resume یا Transfer یک re-INVITE با 488 رد می‌شود، Codec اولیه احتمالاً به‌تنهایی مسئله نیست.
SDP قبل و بعد از re-INVITE را مقایسه کنید.
مواردی که باید مقایسه شوند:
🔹 m=audio
🔹 RTP Profile
🔹 Codec Payload Types
🔹 a=sendrecv / sendonly / inactive
🔹 Crypto/SRTP Attributes
🔹 DTMF telephone-event
برای 488 چه Log و Capture لازم است؟
فقط خود Response 488 کافی نیست.
باید INVITE یا re-INVITE قبل از آن و SDP داخل هر دو سمت را ذخیره کنید.
در Wireshark:
sip || sdpبرای خود کد:
sip.Status-Code == 488خطای 503 Service Unavailable یعنی چه؟
503 برخلاف 403 معمولاً یک Failure موقت سمت Server یا Service است.
RFC 3261 می‌گوید Server ممکن است به دلیل Overload یا Maintenance موقتاً نتواند Request را پردازش کند.
Server می‌تواند Header زیر را نیز برگرداند:
Retry-After: 60که به Client می‌گوید چه زمانی دوباره تلاش کند.
503 هنگام REGISTER
اگر Cisco برای Registration پاسخ 503 می‌گیرد، این موارد محتمل‌اند:
🔹 Registrar موقتاً Down است.
🔹 SIP Cluster در Maintenance قرار دارد.
🔹 Server Overload شده است.
🔹 Load Balancer Backend سالم ندارد.
🔹 PBX درخواست را به Upstream می‌فرستد و Upstream در دسترس نیست.
در Asterisk نیز 503 در Outbound Registration به‌عنوان Failure موقت شناخته می‌شود و سیستم می‌تواند بر اساس Retry Interval دوباره Register کند.
503 هنگام تماس خروجی
اگر Phone Registered است اما INVITE با 503 برمی‌گردد، علت‌ها می‌توانند این‌ها باشند:
🔹 SIP Trunk Provider موقتاً سرویس ندارد.
🔹 PBX Route سالمی برای Destination ندارد و خطا را به 503 Map کرده است.
🔹 همه Gatewayها یا Trunk Memberها Out of Service هستند.
🔹 Provider ظرفیت تماس هم‌زمان را پر کرده است.
🔹 Maintenance Mode روی PBX یا Endpoint فعال است.
503 همیشه مستقیماً از Provider نمی‌آید
این نکته بسیار مهم است.
Proxy یا PBX می‌تواند خطای Upstream را تبدیل یا Aggregate کند.
RFC 3261 حتی برای Forward کردن 503 توسط Proxy رفتار خاص تعریف کرده است.
بنابراین اگر Cisco 503 می‌بیند، از روی Display تلفن نتیجه نگیرید «اپراتور قطع است».
Source IP و Log PBX را ببینید.
Retry-After را نادیده نگیرید
اگر 503 دارای Retry-After است، Server عملاً اطلاعات مفیدی درباره Retry داده است.
Retry سریع و بی‌وقفه صدها Endpoint می‌تواند Load را بیشتر کند.
به همین دلیل تنظیم Retry Interval سمت PBX/Registrar باید منطقی باشد.
فرق 403 و 503 در Registration
| 403 | 503 |
|---|---|
| Request عمداً رد شده است | Service موقتاً در دسترس نیست |
| بیشتر به Policy/Account نزدیک است | بیشتر به Availability/Capacity نزدیک است |
| Retry بدون تغییر معمولاً منطقی نیست | Retry بعدی می‌تواند موفق شود |
| Credential/Permission/Provider Policy را بررسی کنید | Server Health/Upstream/Retry-After را بررسی کنید |
چطور روی خود Cisco MPP Packet Capture بگیریم؟
در MPP جدید، Cisco Packet Capture داخلی را در Web Administration مستند کرده است.
مسیر:
Admin Login → Advanced → Info → Debug Info
سپس در بخش Problem Report Tool:
Start Packet Capture
را بزنید.
سناریوی خطا را یک بار تکرار کنید، Capture را Stop و فایل PCAP را دانلود کنید.
این روش برای فهمیدن اینکه Response دقیقاً از کدام IP آمده بسیار مفید است.
PRT چه کمکی می‌کند؟
برای Cisco 78xx/88xx، PRT علاوه بر Status و Logهای Endpoint می‌تواند Timestamp دقیق رویداد را برای تطبیق با PBX Log فراهم کند.
برای یک مشکل تکرارشونده، این سه مورد را با هم نگه دارید:
🔹 PRT تلفن
🔹 PCAP تلفن یا SPAN Port
🔹 Log PBX/SBC در همان Timestamp
این مجموعه بسیار دقیق‌تر از Screenshot خطا روی Display است.
فعال‌کردن SIP Debug در Cisco MPP
اگر Syslog Server دارید، در MPP می‌توانید برای Line موردنظر SIP Debug Option را روی Full قرار دهید تا Signaling بیشتری ثبت شود.
این کار را فقط هنگام عیب‌یابی انجام دهید و بعد Debug Verbosity را به سطح معمول برگردانید؛ Log کامل SIP می‌تواند حجم زیادی تولید کند و اطلاعات حساس Signaling داشته باشد.
در Asterisk چه Logهایی بگیریم؟
برای PJSIP ابتدا Verbose و Debug را موقتاً بالا ببرید:
core set verbose 4
core set debug 4
pjsip set logger onسپس فقط یک تماس یا Registration خراب را تکرار کنید.
بعد Logger را خاموش کنید:
pjsip set logger off
core set debug 0برای Registration وضعیت Trunk را هم بررسی کنید
در Asterisk/PJSIP:
pjsip show registrations
pjsip show endpointsاگر Provider Registration خودش 503 دارد، مشکل Cisco Phone ممکن است فقط نتیجه Down بودن Upstream Trunk باشد.
چطور بفهمیم مشکل Cisco Phone است یا PBX؟
یک مقایسه ساده انجام دهید.
اگر چند Cisco Phone مختلف هنگام تماس به یک Destination همان کد را می‌گیرند، احتمال خرابی یک Endpoint خاص کمتر می‌شود.
اگر فقط یک Phone خطا دارد، Configuration آن را با Phone سالم مقایسه کنید.
موارد مقایسه:
🔹 SIP Proxy
🔹 User ID
🔹 Auth ID
🔹 Codec List
🔹 Encryption
🔹 Dial Plan
🔹 Transport
چطور بفهمیم مشکل PBX است یا Provider؟
دو SIP Leg را ببینید.
مثلاً:
Cisco Phone → PBX
PBX → Providerاگر Provider به PBX 404 می‌دهد و PBX همان 404 را به Cisco برمی‌گرداند، Provider/Number Format را بررسی کنید.
اگر Provider 200 یا 183 می‌دهد ولی PBX به Cisco 488 می‌دهد، مشکل داخل PBX/Media Negotiation است.
اگر PBX اصلاً INVITE را به Provider نفرستاده و مستقیم 403 داده، Provider در آن تماس نقشی نداشته است.
Response Code را با Reason Phrase تنها تحلیل نکنید
Reason Phrase بعد از کد می‌تواند توسط Vendor تغییر داده شود.
مثلاً ممکن است ببینید:
403 Forbidden
403 Call Rejected
403 Not Allowedبرای تشخیص، کد + Flow + Headerها + Server Log اهمیت دارند.
Reason Header و Q.850 Cause را بررسی کنید
Provider یا Gateway ممکن است علاوه بر SIP Response یک Reason Header نیز ارسال کند.
مثلاً:
Reason: Q.850;cause=...این Cause می‌تواند اطلاعات بیشتری درباره Mapping بین شبکه SIP و PSTN بدهد.
اما Mapping بین SIP و Q.850 Vendor-dependent است و باید با Log همان Gateway/Provider تطبیق داده شود.
Factory Reset برای این خطاها معمولاً اولین راه نیست
اگر PBX صریحاً 403 می‌دهد، Factory Reset Policy سرور را عوض نمی‌کند.
اگر Destination 404 است، Reset شماره مقصد را ایجاد نمی‌کند.
اگر Codec Negotiation به 488 می‌رسد، Reset شاید موقتاً Codec List را عوض کند اما علت واقعی را پنهان می‌کند.
اگر Provider 503 دارد، Reset Endpoint Server Provider را Online نمی‌کند.
قبل از هر Reset حداقل یک SIP Trace ذخیره کنید.
جدول عیب‌یابی عملی چهار خطا
| خطا | Endpoint | PBX/SBC | Provider | Verification |
|---|---|---|---|---|
| 403 | Auth ID، URI، Registration Profile | ACL، Permission، Context، Caller ID | Account Policy، IP Restriction، Destination Permission | REGISTER/INVITE و Log Server |
| 404 | Dial String، SIP Domain | Extension، Route، Dial Plan | Number Format یا Unallocated Number | Request-URI و Outbound Leg |
| 488 | Codec، SRTP، SDP | Codec Negotiation، Transcoding، Media Policy | Supported Codec/Encryption | SDP Offer/Answer |
| 503 | معمولاً اثر خطای Server | Maintenance، Overload، Upstream Failure | Outage، Capacity، Maintenance | Source IP، Retry-After و Server Health |
مسیر پیشنهادی برای خطای 403
مرحله ۱: مشخص کنید Response برای REGISTER است یا INVITE.
مرحله ۲: Source IP پاسخ را ثبت کنید.
مرحله ۳: Auth ID، From و Request-URI را مقایسه کنید.
مرحله ۴: PBX/Provider Log را در همان Timestamp ببینید.
مرحله ۵: Policy و Permission را اصلاح کنید؛ نه اینکه فقط Password را عوض کنید.
مسیر پیشنهادی برای خطای 404
مرحله ۱: Request-URI را بخوانید.
مرحله ۲: User و Domain را Verify کنید.
مرحله ۳: Dial Plan/Context/Route را بررسی کنید.
مرحله ۴: اگر Provider پاسخ داده، Number Format خروجی را بررسی کنید.
مرحله ۵: مطمئن شوید خطا HTTP Provisioning نیست.
مسیر پیشنهادی برای خطای 488
مرحله ۱: INVITE و SDP را ذخیره کنید.
مرحله ۲: Codecهای Offer و Allowed Codecهای مقصد را مقایسه کنید.
مرحله ۳: RTP/SRTP Policy را بررسی کنید.
مرحله ۴: DTMF و Media Type را بررسی کنید.
مرحله ۵: اگر روی re-INVITE رخ می‌دهد، SDP قبل و بعد Hold/Transfer را مقایسه کنید.
مسیر پیشنهادی برای خطای 503
مرحله ۱: Source IP پاسخ را پیدا کنید.
مرحله ۲: Retry-After را بررسی کنید.
مرحله ۳: Server Health و Maintenance را بررسی کنید.
مرحله ۴: Trunk/Upstream Registration را بررسی کنید.
مرحله ۵: اگر Alternative Route دارید، Failover را بررسی کنید.
پرسش‌های رایج
خطای 403 در Cisco Phone یعنی پسورد اشتباه است؟
نه لزوماً. 403 یعنی Server درخواست را فهمیده ولی آن را رد کرده است. Account Policy، Auth ID، IP Restriction، Caller ID و مجوز Destination نیز می‌توانند علت باشند.
فرق 401 با 403 چیست؟
401 معمولاً Authentication Challenge است و Client باید درخواست را با Credential مناسب دوباره ارسال کند. 403 معمولاً یعنی درخواست پس از بررسی مجاز شناخته نشده است.
خطای 404 در Cisco SIP یعنی داخلی وجود ندارد؟
این یکی از علت‌هاست، اما Domain اشتباه، Dial Plan، Route و Number Format نیز می‌توانند باعث 404 شوند. Request-URI را بررسی کنید.
خطای 488 همیشه مشکل Codec است؟
خیر. Codec mismatch رایج است، اما SRTP/RTP mismatch، SDP ناسازگار، DTMF Method و Media Type نیز می‌توانند باعث 488 شوند.
چرا تماس اول وصل می‌شود ولی Transfer با 488 شکست می‌خورد؟
در Transfer یا Hold ممکن است re-INVITE و SDP جدید ایجاد شود. اگر Media Negotiation جدید قابل قبول نباشد، مقصد می‌تواند 488 برگرداند.
503 یعنی SIP Provider قطع است؟
نه حتماً. 503 ممکن است توسط PBX، SBC، Registrar یا Provider ساخته شده باشد. Source IP و Log مسیر را بررسی کنید.
Retry-After در 503 چیست؟
Server می‌تواند با Retry-After اعلام کند Client چه مدت برای تلاش مجدد صبر کند. وجود این Header نشانه مهمی برای Failure موقت است.
برای این خطاها بهترین لاگ Cisco چیست؟
برای MPP، PCAP داخلی تلفن به همراه PRT بسیار مفید است. PCAP مشخص می‌کند Response از کدام IP آمده و PRT وضعیت Endpoint را با Timestamp در اختیار شما می‌گذارد.
آیا Factory Reset خطاهای 403، 404، 488 و 503 را حل می‌کند؟
معمولاً نه به‌عنوان اولین اقدام. ابتدا باید مشخص شود خطا از Endpoint، PBX، Provider یا Media Negotiation است و یک SIP Trace قبل از Reset ذخیره شود.
جمع‌بندی
کد SIP به‌تنهایی علت مشکل را مشخص نمی‌کند. برای Cisco Phone باید Response را همراه Request قبل از آن و سیستمی که Response را ساخته بررسی کنید.
403 بیشتر به Refusal و Policy نزدیک است، 404 به User/Domain/Route، 488 به Media Negotiation و 503 به Availability موقت Server یا Upstream.
مهم‌ترین ابزار شما PCAP است. اگر Source IP، Request-URI، SDP و Timestamp را در اختیار داشته باشید، معمولاً می‌توان خیلی سریع مشخص کرد مشکل در Cisco Endpoint است، PBX آن را ایجاد کرده یا Provider پاسخ را برگردانده است.
قبل از Factory Reset یا تغییر گسترده Codec و Dial Plan، یک Call Flow خراب را کامل ذخیره کنید. این کار از آزمون‌وخطای طولانی و تغییرهایی که علت اصلی را پنهان می‌کنند جلوگیری می‌کند.
کد خطا را دارید اما معلوم نیست Cisco، PBX یا Provider آن را ساخته است؟
در خطاهای 403، 404، 488 و 503 تغییر تصادفی Dial Plan، Codec یا Firmware می‌تواند تشخیص را سخت‌تر کند. بهترین مسیر این است که یک تماس خراب با PCAP ثبت شود و SIP Flow تلفن، PBX و Trunk کنار هم بررسی شوند.
ایرانیکاسرور می‌تواند تنظیم Cisco MPP، Asterisk/FreePBX/3CX، SIP Trunk، Codec و Route را بررسی کند تا مشخص شود Response در کدام نقطه تولید شده و تغییر فقط روی همان بخش انجام شود.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)