Amir Jabbari
اگر تلفن Cisco هنگام رجیسترشدن یا برقراری تماس با خطاهای SIP 403، 404، 488 یا 503 روبه‌رو می‌شود، فقط معنی لغوی کد را نخوانید و فوراً تنظیمات Phone را تغییر ندهید. مهم‌تر از خود کد این است که بدانید پاسخ روی کدام درخواست آمده، چه دستگاهی آن را فرستاده و داخل Headerها، SDP و Log چه سرنخی وجود دارد.
قاعده این مقاله: برای هر Error Code چهار چیز را مشخص می‌کنیم: معنی استاندارد، علت محتمل در Endpoint/PBX/Provider، چیزی که باید در Log ببینید و تستی که علت را تأیید یا رد می‌کند.
قبل از 403 و 488، اول بفهمید پاسخ را چه کسی فرستاده است
یک SIP Response ممکن است از خود تلفن، PBX، SBC/CUBE یا Provider برگردد. اگر فقط روی صفحه Phone عبارت 403 یا 488 را ببینید، هنوز نمی‌دانید مشکل کجاست.
برای هر تماس یا REGISTER این پنج مورد را ثبت کنید:
🔹 SIP Method که Failure روی آن رخ داده: REGISTER، INVITE، UPDATE یا OPTIONS.
🔹 IP مبدا Response.
🔹 Call-ID.
🔹 Request-URI و From/To.
🔹 Headerهای Reason، Warning، Retry-After و SDP در صورت وجود.
در Wireshark می‌توانید ابتدا کل SIP Signaling را جدا کنید:
sipبرای دیدن همه Failure Responseها:
sip.Status-Code >= 400و برای یک کد مشخص:
sip.Status-Code == 403Cisco در راهنمای عیب‌یابی SIP خود همین روش را پیشنهاد می‌کند: Call Flow را در Wireshark باز کنید، Call-ID و From/To و Error را از Packet Details بخوانید و بعد مشخص کنید Failure در کدام Hop ایجاد شده است.
جدول سریع خطاهای SIP 403، 404، 488 و 503
| کد | معنی پایه | مظنون اصلی | اولین چیزی که بررسی می‌کنیم |
|---|---|---|---|
| 403 Forbidden | درخواست فهمیده شده اما رد شده | Policy / Permission / Provider | Method، Domain، Caller ID، ACL و Server Log |
| 404 Not Found | کاربر یا مقصد در Domain پیدا نشده | Dial Plan / Request-URI | Called Number، Domain و Route |
| 488 Not Acceptable Here | پارامترهای Session برای این مقصد قابل قبول نیستند | SDP / Media | Codec، SRTP/RTP، DTMF و SDP |
| 503 Service Unavailable | Server موقتاً قادر به پردازش نیست | PBX / SBC / Provider | Source IP، Retry-After، Capacity و Failover |
خطای SIP 403 Forbidden روی تلفن Cisco یعنی چه؟
طبق RFC 3261، کد 403 Forbidden یعنی Server درخواست را فهمیده اما از انجام آن خودداری می‌کند. در تعریف استاندارد، تکرار همان Request با همان شرایط قرار نیست مشکل را حل کند.
اما برای عیب‌یابی عملی، باید اول ببینید 403 روی REGISTER آمده یا روی INVITE.
403 روی REGISTER؛ Phone رجیستر نمی‌شود
اگر Response بعد از REGISTER برمی‌گردد، علت‌های رایج می‌توانند این‌ها باشند:
🔹 SIP Domain یا Registrar اشتباه است.
🔹 Provider این User یا Device را مجاز نمی‌داند.
🔹 Source IP در ACL یا IP Whitelist Provider نیست.
🔹 Account غیرفعال، Suspend یا محدود شده است.
🔹 بعضی Providerها Authentication Failure را نیز به‌جای 401/407 با 403 نشان می‌دهند.
نکته آخر رفتار Vendor-specific است؛ خود RFC نمی‌گوید 403 همان «Password اشتباه» است. پس از روی کد به‌تنهایی Credential را مقصر ندانید.
403 روی INVITE؛ تماس خروجی رد می‌شود
اگر Registration سالم است ولی INVITE با 403 برمی‌گردد، بیشتر به Policy تماس شک کنید:
🔹 Dial Permission یا Class of Service اجازه این مقصد را نمی‌دهد.
🔹 Caller ID ارسالی Provision نشده یا Provider آن را قبول نمی‌کند.
🔹 Dialed Number با Policy کشور/مقصد سازگار نیست.
🔹 SIP Domain یا From Identity مورد قبول Provider نیست.
🔹 SBC یا PBX تماس را عمداً Reject کرده است.
راهنمای عیب‌یابی Cisco برای SIP Call Failure نیز برای 403 به Permission، SIP Domain و Policy اشاره می‌کند.
در Log خطای 403 دنبال چه چیزی بگردیم؟
یک نمونه ساده ممکن است چنین شکلی داشته باشد:
INVITE sip:00982112345678@sip.provider.example SIP/2.0
From: <sip:02191302467@sip.provider.example>
To: <sip:00982112345678@sip.provider.example>
Call-ID: 7f9b2a11@192.0.2.20
SIP/2.0 403 Forbidden
Reason: Q.850;cause=21;text="Call Rejected"این مثال آموزشی است. در Trace واقعی، مهم‌ترین سؤال این است که Response را Provider فرستاده، PBX یا SBC داخلی.
روش Verification برای 403
برای REGISTER: Domain، Auth ID، Username، Registrar و Source IP را با Portal یا Configuration رسمی Provider تطبیق دهید.
برای INVITE: همان تماس را با یک Caller ID مجاز و Destination مجاز تست کنید. اگر فقط یک Caller ID یا Prefix خاص 403 می‌گیرد، احتمال Policy بیشتر می‌شود.
روی PBX: Log را با Call-ID همان تماس جست‌وجو کنید. اگر PBX درخواست را Forward کرده و 403 از IP Provider برگشته، Endpoint مقصر نیست.
خطای SIP 404 Not Found؛ شماره نیست یا Route اشتباه است؟
RFC 3261 برای 404 Not Found تعریف روشنی دارد: Server اطلاعات قطعی دارد که User در Domain نوشته‌شده در Request-URI وجود ندارد؛ یا Domain موجود در Request-URI اصلاً متعلق به آن Server نیست.
در محیط Cisco/PBX این معمولاً شما را به سمت Dial Plan، Digit Manipulation، Extension یا SIP Domain می‌برد.
404 از Endpoint چه زمانی محتمل است؟
Endpoint می‌تواند در بعضی Flowها برای Resource ناشناخته Response بدهد، اما در تماس‌های عادی Cisco Phone معمولاً 404 را از Call Control، PBX یا Provider می‌بینید. بنابراین Source IP Response را بررسی کنید.
404 از PBX یا CUCM
اگر PBX خودش 404 می‌دهد، این موارد را بررسی کنید:
🔹 Extension مقصد واقعاً وجود دارد؟
🔹 Called Number بعد از Translation همان چیزی است که انتظار دارید؟
🔹 Route Pattern یا Dial Peer درست Match شده؟
🔹 SIP Domain مقصد در PBX تعریف شده؟
🔹 تماس به Tenant یا Context صحیح وارد شده؟
404 از Provider
اگر Provider پاسخ را فرستاده است، دو علت بسیار رایج‌اند: Number Format اشتباه یا Route نشدن Destination در شبکه Provider. گاهی PBX شماره را با Prefix داخلی یا بدون Country Code مورد انتظار Provider می‌فرستد.
نمونه:
INVITE sip:201@sip.provider.example SIP/2.0
SIP/2.0 404 Not Foundاگر Provider انتظار E.164 دارد اما PBX داخلی `201` را مستقیم به Trunk فرستاده، 404 کاملاً قابل انتظار است.
روش Verification برای 404
در Wireshark یا PRT، Request-URI اولین چیزی است که باید بخوانید. بعد همان شماره را در PBX Trace دنبال کنید و ببینید قبل و بعد از Translation چه تغییری کرده است.
اگر CUBE دارید، Dial Peer و SIP Message را با Debug پایه مقایسه کنید:
debug ccsip messages
debug ccsip error
debug voip ccapi inoutاین Debugها را در محیط Production کنترل‌شده و برای بازه کوتاه اجرا کنید. پس از تست:
undebug allخطای SIP 488 Not Acceptable Here؛ معمولاً مشکل SDP است
488 Not Acceptable Here یعنی مشخصات Session برای همین Resource قابل قبول نیست. Cisco در راهنمای عیب‌یابی ۲۰۲۵ این کد را عمدتاً به Media Negotiation مرتبط می‌داند و سه علت مشخص را مثال می‌زند: Codec mismatch، SRTP در برابر RTP و DTMF ناسازگار.
پس اگر Phone رجیستر است، INVITE ارسال می‌شود و بلافاصله 488 می‌گیرید، قبل از DNS، NAT یا Factory Reset سراغ SDP بروید.
اول SDP Offer را بخوانید
داخل INVITE دنبال بخش `m=audio` و `a=rtpmap` بگردید:
m=audio 16420 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000این Offer می‌گوید Endpoint برای Audio حداقل PCMU و PCMA و برای DTMF payload نوع telephone-event را پیشنهاد داده است.
سناریو ۱: هیچ Codec مشترکی وجود ندارد
اگر Cisco فقط G.711 پیشنهاد دهد ولی Trunk فقط G.729 یا Codec دیگری را قبول کند، Destination ممکن است 488 بدهد. راه‌حل این است که Codec List دو سمت حداقل یک Codec مشترک داشته باشند یا Transcoder مناسب در مسیر وجود داشته باشد.
سناریو ۲: یک سمت SRTP می‌خواهد و سمت دیگر RTP
اگر یک Leg با Secure Media تنظیم شده و سمت مقابل فقط RTP عادی را قبول کند، Negotiation ممکن است Reject شود. در SDP به Profile و خطوط Security دقت کنید.
مثلاً تفاوت این دو مهم است:
RTP/AVP
RTP/SAVPنوع دقیق Secure Media به معماری شما بستگی دارد؛ فقط از روی یک خط Config نتیجه نگیرید و Offer/Answer واقعی را مقایسه کنید.
سناریو ۳: DTMF Method ناسازگار است
اگر PBX یا Provider روی RFC 2833/4733، SIP INFO یا روش خاصی Policy داشته باشد و SDP یا Config دو سمت هماهنگ نباشد، Cisco این مورد را هم در فهرست علت‌های 488 قرار می‌دهد.
در Response 488 چه Headerهایی مهم‌اند؟
RFC اجازه می‌دهد Response حاوی Media Capability باشد و در عمل Headerهایی مانند Warning یا Reason می‌توانند بسیار راهگشا باشند.
نمونه آموزشی:
SIP/2.0 488 Not Acceptable Here
Warning: 304 pbx.example "Media type not available"روش Verification برای 488
دو Trace را کنار هم بگذارید: INVITE ورودی به PBX و INVITE خروجی از PBX/Provider. اگر SDP در میانه تغییر کرده، مسئله می‌تواند از Transcoding، SIP Profile یا SBC باشد.
در Wireshark:
sip.Status-Code == 488 || sip.Method == "INVITE"بعد SDP دو Leg را با هم مقایسه کنید. اگر Codec مشترک وجود دارد و Security هم هماهنگ است، تازه سراغ DTMF، ptime، Fax/Video Media Line یا Policyهای خاص Provider بروید.
خطای SIP 503 Service Unavailable؛ بیشتر Server-side است
طبق RFC 3261، 503 Service Unavailable یعنی Server به‌صورت موقت به‌خاطر Overload یا Maintenance نمی‌تواند Request را پردازش کند. Server می‌تواند Header به نام Retry-After بفرستد تا زمان مناسب برای Retry را مشخص کند.
در عمل 503 معمولاً از PBX، SBC، CUBE یا Provider می‌آید، نه از خود Cisco Phone. Cisco در Mappingهای Voice Gateway نیز وضعیت‌هایی مثل نبود Circuit، Network Failure، Temporary Failure و Congestion را به 503 نگاشت می‌کند.
503 از Provider
اگر Response Source همان Provider SBC است:
🔹 Trunk Provider ممکن است Maintenance یا Overload داشته باشد.
🔹 Route مقصد موقتاً ظرفیت نداشته باشد.
🔹 Provider یک Upstream Carrier ناموجود داشته باشد.
🔹 ممکن است Retry-After مشخص شده باشد.
503 از PBX یا CUBE
اگر پاسخ از داخل شبکه شما آمده، Resource و Route را بررسی کنید:
🔹 SIP Trunk مقصد Down است.
🔹 Dial Peer یا Server Group مقصد قابل استفاده نیست.
🔹 Session Capacity یا Resource داخلی پر شده است.
🔹 PBX سرویس لازم را ندارد یا در Maintenance است.
نمونه:
SIP/2.0 503 Service Unavailable
Retry-After: 60اگر `Retry-After: 60` وجود دارد، تکرار تماس هر دو ثانیه هیچ کمکی نمی‌کند. Server به شما گفته حداقل در این بازه دوباره امتحان نکنید.
روش Verification برای 503
اول Source IP را مشخص کنید. اگر Provider 503 داده، از همان Timestamp، Call-ID، Calling Number و Called Number برای Ticket Provider استفاده کنید.
اگر CUBE در مسیر دارید، Status و Debug را بررسی کنید. برای SIP Message:
debug ccsip messages
debug ccsip errorاگر CUBE خودش Registrar است یا Registration دارد، بسته به معماری می‌توانید Status را هم بررسی کنید:
show sip-ua register statusچطور از خود Cisco Phone Log و Packet Capture بگیریم؟
روی تلفن‌های Cisco MPP سری 8800، Cisco امکان PRT و Packet Capture را از Web Interface فراهم کرده است. این مرحله از حدس‌زدن خیلی مطمئن‌تر است.
برای PRT معمولاً وارد Phone Web Interface شوید و به این مسیر بروید:
Info
→ Debug Info
→ Generate PRTبرای Packet Capture نیز در همان Debug Info می‌توانید Capture را شروع کنید، تماس مشکل‌دار را تکرار کنید و سپس فایل Capture را دریافت کنید.
Cisco در Administration Guide تأکید می‌کند که PRT برای جمع‌آوری Logهای لازم Troubleshooting استفاده می‌شود و Packet Capture را هم می‌توان مستقیماً از Phone گرفت.
یک Workflow ثابت برای هر SIP Error بسازید
به‌جای اینکه برای هر Code از صفر شروع کنید، این ترتیب را ثابت نگه دارید:
مرحله ۱: Timestamp تماس را یادداشت کنید.
مرحله ۲: Calling و Called Number را ثبت کنید.
مرحله ۳: SIP Method شکست‌خورده را مشخص کنید.
مرحله ۴: Source IP پاسخ 4xx/5xx را پیدا کنید.
مرحله ۵: Call-ID را بردارید.
مرحله ۶: Request-URI، From و To را بررسی کنید.
مرحله ۷: اگر 488 است SDP را مقایسه کنید.
مرحله ۸: اگر 503 است Retry-After و وضعیت Server را ببینید.
مرحله ۹: Log سمت PBX/SBC/Provider را با همان Call-ID تطبیق دهید.
مرحله ۱۰: فقط یک متغیر را تغییر دهید و تماس را دوباره تست کنید.
چطور بفهمیم مشکل از Endpoint است، PBX یا Provider؟
| مشاهده | نتیجه محتمل |
|---|---|
| Phone Request را می‌فرستد و PBX خودش Failure می‌دهد | PBX / Dial Plan / Policy را بررسی کنید |
| PBX Request را Forward می‌کند و Provider Failure می‌دهد | Provider یا چیزی که Provider Reject کرده را بررسی کنید |
| Provider INVITE را می‌فرستد و Phone 488 می‌دهد | Media/Security Capability خود Endpoint را بررسی کنید |
| همه Phoneها هم‌زمان 503 می‌گیرند | Server/Trunk/Provider از یک Phone محتمل‌تر است |
| فقط یک Phone با Config مشابه 488 می‌دهد | Config/Firmware/Media Capability همان Endpoint را مقایسه کنید |
برای 488، Offer و Answer را واقعاً با هم مقایسه کنید
فقط اینکه در Config نوشته G.711 کافی نیست. چیزی که روی Wire ارسال شده معیار نهایی است. ممکن است SIP Profile، Region، Device Pool، Trunk یا SBC قبل از خروج SDP را تغییر داده باشد.
در Flow Sequence ببینید:
Cisco Phone
|
| INVITE + SDP A
v
PBX / CUBE
|
| INVITE + SDP B
v
Provider
|
| 488
^اگر SDP A و B فرق دارند، مشکل لزوماً Phone نیست.
چه چیزهایی را بدون دلیل تغییر ندهیم؟
برای این چهار Error، چند اقدام معمولاً زودهنگام‌اند:
🔹 Factory Reset تلفن فقط چون 403 می‌بینید.
🔹 تغییر Firmware فقط چون 404 دریافت شده است.
🔹 بازکردن همه Firewall Portها برای 488.
🔹 تغییر Codecهای تصادفی بدون خواندن SDP.
🔹 تکرار مداوم تماس هنگام 503 دارای Retry-After.
این کارها می‌توانند Evidence را از بین ببرند و Root Cause را پنهان کنند.
403، 404، 488 یا 503 دارید و معلوم نیست Phone مقصر است یا PBX؟
برای تشخیص درست، یک PRT یا Packet Capture به‌همراه Timestamp، Calling/Called Number و نوع PBX بسیار بیشتر از Screenshot خطا کمک می‌کند. با Call-ID می‌توان مشخص کرد Failure در Endpoint، PBX/CUBE یا Provider ایجاد شده است.
ایرانیکاسرور می‌تواند در بررسی Cisco MPP، Asterisk/FreePBX، CUBE، SIP Trunk، SDP و شبکه VoIP کمک کند تا قبل از Reset یا تغییر گسترده Config، نقطه واقعی Failure مشخص شود.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
خطای 403 روی Cisco یعنی Password اشتباه است؟
نه لزوماً. RFC 3261، 403 را ردشدن آگاهانه Request تعریف می‌کند. در عمل ممکن است Policy، Permission، Domain، Source IP یا Caller ID باعث آن شود. بعضی Providerها Authentication Failure را هم با 403 نشان می‌دهند؛ برای نتیجه قطعی Server Log را بررسی کنید.
فرق 403 و 404 در SIP چیست؟
403 یعنی Server Request را می‌شناسد اما آن را مجاز نمی‌داند؛ 404 یعنی User یا Domain مقصد در Request-URI برای آن Server پیدا نشده است.
آیا 488 همیشه مشکل Codec است؟
خیر. Codec mismatch بسیار رایج است، اما Cisco ناسازگاری SRTP/RTP و DTMF را نیز از علت‌های 488 ذکر می‌کند. SDP و Warning/Reason را بررسی کنید.
503 یعنی اینترنت قطع است؟
نه. 503 یعنی Server یا Gateway موقتاً قادر به پردازش Request نیست. Overload، Maintenance، Resource Shortage یا Down بودن یک Upstream Route از علت‌های محتمل‌اند.
برای دیدن SIP Error در Cisco Phone چه Logی بگیریم؟
روی MPP می‌توانید PRT و Packet Capture را از Debug Info بگیرید. در Wireshark، Call-ID، Source IP پاسخ، Request-URI و SIP Status Code را دنبال کنید.
اگر Provider می‌گوید مشکل از PBX است چطور اثبات کنیم؟
INVITE خروجی از PBX را همراه Response Provider و Call-ID ذخیره کنید. اگر Provider همان Request را دریافت کرده و خودش 4xx/5xx برگردانده، Trace دقیقاً مشخص می‌کند چه چیزی Reject شده است.
برای 488 کدام بخش Packet مهم‌تر است؟
SDP داخل INVITE و Response. خطوط m=audio، a=rtpmap، Media Profile، Encryption و DTMF را بین دو Leg مقایسه کنید.
آیا برای 503 باید Phone را Factory Reset کنیم؟
معمولاً خیر. 503 بیشتر Server-side است. Source IP، Retry-After، PBX/SBC Health و Provider Status را بررسی کنید.
جمع‌بندی
در SIP، کد خطا بدون Context کافی نیست. برای 403، 404، 488 و 503 اول Method و Source Response را پیدا کنید و بعد Call-ID را در کل مسیر دنبال کنید.
403 بیشتر به Permission و Policy مربوط است. 404 شما را به Request-URI، Number و Routing می‌برد. 488 تقریباً همیشه نیازمند بررسی دقیق SDP و Media Negotiation است. 503 معمولاً از Server، Gateway یا Provider می‌آید و وضعیت موقت Service را نشان می‌دهد.
برای Cisco Phone، PRT و Packet Capture را قبل از Reset بگیرید. برای CUBE/PBX نیز SIP Debug را با همان Call-ID تطبیق دهید. وقتی مشخص شد کدام Hop Response را ساخته، عیب‌یابی از حدس‌زدن به یک مسیر قابل اثبات تبدیل می‌شود.
PRT یا SIP Trace را با Call-ID بررسی کنید
برای بررسی سریع‌تر، Timestamp تماس، شماره مبدا و مقصد، کد خطا و فایل PRT/PCAP را آماده کنید. این اطلاعات کمک می‌کنند مشخص شود Response را Cisco Phone، PBX/CUBE یا Provider ساخته است.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)