چرا SIP خطای 403 Forbidden می‌دهد؟ مشکل از Trunk است یا سرویس‌دهنده؟

خطای SIP 403 Forbidden یعنی سرور درخواست شما را فهمیده، اما حاضر نیست آن را انجام دهد. در یک SIP Trunk این خطا لزوماً به معنی «خرابی ترانک» یا «مشکل Provider» نیست. 403 می‌تواند از IP مبدأ اشتباه، Credential نادرست، Caller ID غیرمجاز، مقدار From یا P-Asserted-Identity، فرمت شماره، Policy حساب، محدودیت مقصد یا حتی از خود Asterisk ایجاد شود.

برای پیدا کردن علت، مهم‌ترین سؤال این نیست که «403 یعنی چه؟»؛ باید بفهمید چه کسی 403 را ساخته و در کدام مرحله ساخته است. اگر اولین INVITE بدون Challenge فوراً 403 می‌گیرد، مسیر تشخیص با حالتی که بعد از 407 Proxy Authentication Required، INVITE دوم همراه Credential به 403 می‌رسد متفاوت است. همین منطق برای REGISTER نیز صدق می‌کند.

در این راهنما یک روش استاندارد برای عیب‌یابی SIP 403 Forbidden روی Asterisk/PJSIP می‌سازیم و پنج عامل اصلی را جدا بررسی می‌کنیم: Registration و Authentication، IP مبدأ، From/PAI و Caller ID، Credentialها و Trace سمت Provider.

SIP 403 Forbidden دقیقاً چه مفهومی دارد؟

تعریف RFC 3261 روشن است: Server درخواست را فهمیده، اما از انجام آن خودداری می‌کند. RFC همچنین می‌گوید Authorization دوباره قرار نیست این وضعیت را حل کند و Request نباید بدون تغییر تکرار شود.

این نکته مهم است، چون 403 با 401 و 407 یک معنی ندارد:

با این حال، پیاده‌سازی Providerها کاملاً یکسان نیست. بعضی Providerها Credential نامعتبر، Source IP خارج از ACL، Caller ID غیرمجاز یا محدودیت حساب را هم با 403 گزارش می‌کنند. بنابراین خود عدد 403 کافی نیست؛ Trace لازم است.

اول مشخص کنید 403 روی REGISTER است یا INVITE

پیش از هر تغییر، متد SIP را مشخص کنید. دو سناریو معمول داریم:

403 روی REGISTER

REGISTER
   |
   v
401 Unauthorized
   |
   | REGISTER + Authorization
   v
200 OK

اگر به‌جای 200 OK در مرحله دوم 403 Forbidden می‌گیرید، Username/Password، Realm، Account Status، Client URI و Policy Provider را بررسی کنید.

اگر همان REGISTER اول بدون Challenge به 403 می‌رسد، احتمال Source IP، Account Policy، Registrar اشتباه یا محدودیت سمت Provider بیشتر می‌شود.

403 روی INVITE

INVITE
   |
   v
407 Proxy Authentication Required
   |
   | INVITE + Proxy-Authorization
   v
100 / 183 / 200

اگر Provider روی INVITE اول 403 می‌دهد، ابتدا ACL، Source IP، Trunk/Account، Request-URI و Caller ID Policy را بررسی کنید. اگر Challenge می‌دهد ولی INVITE احراز هویت‌شده 403 می‌گیرد، Credential و Policy بعد از Authentication اولویت بیشتری دارند.

مرحله ۱: قبل از تغییر Config یک Trace واقعی بگیرید

روی Asterisk، بهترین نقطه شروع pjsip set logger on است؛ چون Request و Response واقعی SIP را می‌بینید و لازم نیست از روی پیام GUI حدس بزنید.

asterisk -rvvv

core set verbose 4
core set debug 4
pjsip set logger on

یک تماس یا Registration خراب را فقط یک بار تکرار کنید. سپس Logger را خاموش کنید:

pjsip set logger off

در Trace این فیلدها را یادداشت کنید:

مرحله ۲: ببینید 403 را چه کسی ساخته است

اگر پیام زیر از سمت Provider به PBX برمی‌گردد، مشکل در مسیر Outbound Trunk یا Policy Provider است:

SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP ...
From: ...
To: ...
Call-ID: ...
CSeq: ... INVITE

اما اگر Asterisk خودش 403 را برای Device یا Provider می‌سازد، باید Configuration داخلی PBX را بررسی کنید. برای مثال مستند رسمی Asterisk نشان می‌دهد Registration ورودی می‌تواند به‌علت نبودن max_contacts یا عبور از سقف Contactهای AOR با 403 رد شود.

بنابراین اولین تفکیک این است:

مرحله ۳: Source IP را بررسی کنید؛ مخصوصاً بعد از تغییر اینترنت یا Firewall

در بسیاری از SIP Trunkها Provider فقط IPهای ثبت‌شده در ACL را می‌پذیرد. اگر Public IP شما عوض شود، NAT از Gateway دیگری خارج شود یا SBC جدید اضافه کنید، Provider ممکن است Request سالم را صرفاً به‌علت Source IP رد کند.

مسیر خروجی Linux:

ip route get 1.1.1.1

اگر PBX پشت NAT است، IP بالا لزوماً Public IP دیده‌شده توسط Provider را نشان نمی‌دهد. در این حالت Trace سمت Provider ارزش بیشتری دارد.

Twilio در Troubleshooting رسمی خود یک روش بسیار مفید پیشنهاد می‌کند: اگر 403 پاسخ شامل پارامتر received= در Via باشد، آن IP نشان می‌دهد Provider Request شما را از چه Public IP دیده است. همه Providerها چنین اطلاعاتی نمی‌دهند، اما اگر وجود دارد بسیار ارزشمند است.

نمونه:

Via: SIP/2.0/UDP 10.10.10.20:5060;
     received=203.0.113.44;
     rport=5060

اگر Provider انتظار 203.0.113.20 داشته ولی 203.0.113.44 را می‌بیند، قبل از تغییر Password سراغ NAT/ACL بروید.

مرحله ۴: Credential را بر اساس ترتیب Challenge بررسی کنید

در PJSIP، Outbound Registration معمولاً یک type=registration دارد که به یک type=auth اشاره می‌کند.

نمونه پایه:

[provider-reg]
type=registration
server_uri=sip:sip.provider.example
client_uri=sip:ACCOUNT_ID@sip.provider.example
outbound_auth=provider-auth
retry_interval=60

[provider-auth]
type=auth
auth_type=userpass
username=ACCOUNT_ID
password=CHANGE_THIS_PASSWORD

این موارد را با پنل Provider خط‌به‌خط مقایسه کنید:

وضعیت Registration:

asterisk -rx "pjsip show registrations"

اگر Trace نشان می‌دهد Provider ابتدا Challenge صحیح می‌دهد و 403 فقط پس از Request همراه Digest می‌آید، Credential یا Policy حساب را جدی‌تر بررسی کنید.

403 روی اولین INVITE یا دومین INVITE؟ این تفاوت خیلی مهم است

مستند Troubleshooting سرویس Twilio یک نکته بسیار کاربردی دارد که به‌صورت عمومی هم برای تشخیص ذهنی مفید است:

این رفتار یک قانون جهانی همه Providerها نیست، اما برای کوتاه‌کردن مسیر عیب‌یابی بسیار مفید است. همیشه Trace واقعی Provider خودتان را معیار نهایی قرار دهید.

مرحله ۵: From و P-Asserted-Identity را با Caller ID مجاز مقایسه کنید

خیلی از 403هایی که «Credential درست است» در واقع از Caller ID Policy می‌آیند. Provider ممکن است فقط DIDهای متعلق به حساب یا شماره‌های Verify‌شده را اجازه دهد.

در SIP معمولاً هویت تماس‌گیرنده در یکی یا چند Header دیده می‌شود:

From: "Company" <sip:+982100000000@sip.example.com>

P-Asserted-Identity:
<sip:+982100000000@sip.example.com>

RFC 3325، P-Asserted-Identity را برای حمل هویت Assert‌شده داخل یک Trust Domain تعریف می‌کند. در شبکه Provider، این Header می‌تواند برای تشخیص Caller Identity استفاده شود، اما Policy هر Provider متفاوت است.

در Asterisk PJSIP گزینه send_pai=yes برای ارسال P-Asserted-Identity وجود دارد:

[provider-endpoint]
type=endpoint

send_pai=yes
from_domain=sip.provider.example

disallow=all
allow=alaw,ulaw

فقط به وجود PAI اکتفا نکنید. مقدار From و P-Asserted-Identity را با فرمت شماره‌ای که Provider مستند کرده مقایسه کنید.

اگر فقط بعضی Caller IDها 403 می‌گیرند، مشکل تقریباً مشخص است

یک تست ساده انجام دهید: با همان Trunk، مقصد و Credential، فقط Caller ID را عوض کنید.

Twilio نیز در مستند Trunk خود محدودیت Caller ID را صریحاً اعمال می‌کند و شماره From/PAI باید متعلق به حساب یا Verify‌شده باشد. Provider شما ممکن است Policy متفاوتی داشته باشد، اما منطق تست یکسان است.

مرحله ۶: Request-URI و فرمت شماره مقصد را بررسی کنید

گاهی 403 از Authentication نیست؛ Provider Request را از نظر Routing یا Number Policy قبول نمی‌کند.

در INVITE این بخش را بررسی کنید:

INVITE sip:+982100000001@sip.provider.example SIP/2.0

موارد قابل بررسی:

برای مثال Twilio توضیح می‌دهد Termination URI باید در Request-URI درست استفاده شود و Geographic Permission نیز می‌تواند Call را رد کند. این مثال نشان می‌دهد 403 همیشه «Password اشتباه» نیست.

مرحله ۷: اگر 403 فقط بعد از تغییر IP شروع شد، Password را دست نزنید

این سناریو بسیار رایج است:

Old public IP:
198.51.100.10  -> Provider ACL -> Allowed

New public IP:
198.51.100.22  -> Provider ACL -> 403 Forbidden

مواردی که ممکن است Source IP را تغییر دهند:

در این وضعیت ابتدا ACL Provider و Public Source IP واقعی را تطبیق دهید.

مرحله ۸: Asterisk Endpoint و Identify را برای تماس ورودی Provider بررسی کنید

اگر تماس از Provider به PBX می‌آید و Asterisk نمی‌تواند Source را به Endpoint درست Match کند، مشکل سمت Inbound Trunk است.

نمونه Identify بر اساس IP:

[provider-identify]
type=identify
endpoint=provider-endpoint
match=203.0.113.0/24

بررسی Endpoint:

asterisk -rx "pjsip show endpoint provider-endpoint"
asterisk -rx "pjsip show identifies"

مستند Asterisk تأکید می‌کند همه SIP Traffic ورودی باید به یک Endpoint قابل‌شناسایی Match شود. برای Trunkهای Provider، Identify بر اساس IP یکی از الگوهای رایج است.

مرحله ۹: روی Packet Capture مشخص کنید Provider واقعاً چه چیزی دیده است

اگر SIP روی UDP/TCP بدون TLS است، PCAP می‌تواند Evidence بسیار خوبی باشد:

tcpdump -ni any -s0 \
  -w /tmp/sip-403.pcap \
  'udp port 5060 or tcp port 5060 or tcp port 5061'

برای مشاهده زنده SIP بدون TLS، sngrep هم بسیار کاربردی است:

apt install -y sngrep
sngrep -d any port 5060

مرحله ۱۰: Provider Trace را با یک Evidence Pack کامل درخواست کنید

اگر Config سمت شما درست به نظر می‌رسد، به پشتیبانی Provider فقط نگویید «تماس 403 می‌دهد». یک بسته شواهد کوتاه بفرستید:

از Provider بخواهید مشخص کند 403 مربوط به کدام Policy بوده است: ACL، Authentication، Caller ID، Destination Permission، Account Status یا Rule دیگری.

اگر Provider Trace داخلی دارد، آن Trace معمولاً از پیام عمومی 403 Forbidden اطلاعات دقیق‌تری در اختیار پشتیبانی می‌گذارد.

اگر Asterisk روی REGISTER ورودی 403 می‌دهد

همه 403ها از Provider نیستند. در Asterisk PJSIP، Registration ورودی Device می‌تواند در چند حالت 403 بگیرد.

یکی از موارد مستندشده، AOR بدون max_contacts است:

[1001]
type=aor
max_contacts=1
remove_existing=yes

اگر تعداد Contactهای موجود از max_contacts بیشتر شود نیز Registration می‌تواند رد شود.

بررسی:

asterisk -rx "pjsip show endpoint 1001"
asterisk -rx "pjsip show aor 1001"
asterisk -rx "pjsip show contacts"

آیا forbidden_retry_interval مشکل را حل می‌کند؟

Asterisk برای Outbound Registration گزینه forbidden_retry_interval دارد. اگر مقدار غیرصفر بدهید، بعد از دریافت 403 دوباره Registration را امتحان می‌کند.

مثال:

[provider-reg]
type=registration

forbidden_retry_interval=300
max_retries=10

اما این راه‌حل 403 نیست. خود مستند Asterisk اشاره می‌کند Retry بعد از 403 با توصیه RFC 3261 هم‌راستا نیست و بیشتر برای Registrarهای ناسازگار یا رفتار خاص Provider کاربرد دارد. اگر IP یا Credential غلط است، Retry فقط Log را شلوغ می‌کند.

روش تشخیص سریع در کمتر از پنج دقیقه

مثال اول: IP اشتباه است، نه Password

INVITE sip:+982100000001@provider.example SIP/2.0
Via: SIP/2.0/UDP 10.10.0.5:5060
From: <sip:+982100000000@provider.example>

SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 10.10.0.5:5060;
     received=198.51.100.22

در پنل Provider فقط 198.51.100.10 در ACL است. نتیجه: تغییر Password بی‌فایده است؛ Public Source IP باید اصلاح یا به ACL اضافه شود.

مثال دوم: Source IP درست است، اما Digest اشتباه است

INVITE
  ->
407 Proxy Authentication Required
  ->
INVITE + Proxy-Authorization
  ->
403 Forbidden

در این حالت Username، Password، Realm و Auth Object را بررسی کنید. در Asterisk Outbound Trunk مطمئن شوید outbound_auth به همان Auth Section موردنظر اشاره می‌کند.

مثال سوم: همه‌چیز درست است اما فقط یک Caller ID رد می‌شود

Working:
From: <sip:+982100000000@provider.example>
-> 100 Trying

Failing:
From: <sip:+989120000000@provider.example>
-> 403 Forbidden

وقتی Source IP، Destination و Credential تغییر نکرده ولی فقط From فرق دارد، Caller ID Authorization اولین مظنون است. PAI را هم هم‌زمان بررسی کنید.

اشتباه‌هایی که عیب‌یابی 403 را طولانی می‌کنند

پرسش‌های رایج

SIP 403 Forbidden یعنی چه؟

یعنی SIP Server درخواست را فهمیده اما از انجام آن خودداری کرده است. در Trunkها علت می‌تواند ACL، Source IP، Credential، Caller ID، Account Policy یا Routing باشد.

403 با 401 یا 407 چه فرقی دارد؟

401 و 407 معمولاً Authentication Challenge هستند و Client باید Request را با Credential تکرار کند. 403 یک ردشدن Policy/Authorization است و Blind Retry بدون رفع علت معمولاً کمکی نمی‌کند.

چطور بفهمم Source IP باعث 403 شده است؟

Public IP خروجی را با ACL Provider مقایسه کنید. اگر پاسخ Provider پارامتر received در Via دارد، آن IP می‌تواند نشان دهد Provider Request شما را از کدام آدرس دیده است.

اگر 403 بعد از 407 بیاید، مشکل چیست؟

در بسیاری از Providerها این الگو به Credential یا Policy بعد از Authentication اشاره می‌کند. Username، Password، Realm و Digest را بررسی کنید و Trace Provider را معیار نهایی قرار دهید.

آیا Caller ID می‌تواند باعث 403 شود؟

بله. بعضی Providerها فقط DIDهای متعلق به حساب یا شماره‌های تأییدشده را در From یا P-Asserted-Identity می‌پذیرند.

آیا P-Asserted-Identity همان From است؟

خیر. From هویت ارائه‌شده در SIP Message است، در حالی که P-Asserted-Identity برای حمل هویت Assert‌شده در Trust Domain تعریف شده است. Provider ممکن است برای Caller ID یکی یا هر دو را بررسی کند.

چرا Asterisk خودش 403 می‌فرستد؟

برای Registration ورودی، مواردی مثل AOR بدون max_contacts یا عبور از سقف Contactها می‌توانند باعث 403 شوند. Endpoint/AOR/Identify را از CLI بررسی کنید.

برای Provider چه اطلاعاتی بفرستم؟

Timestamp دقیق، Call-ID، Source Public IP، Destination، From/PAI، شماره مقصد و مشخص‌کردن اینکه 403 قبل یا بعد از Challenge رخ داده است.