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

بنابراین وقتی روی Asterisk، FreePBX، FusionPBX یا هر سانترال SIP دیگری خطای SIP 403 Forbidden می‌بینید، اولین کار نباید تغییر تصادفی Password، Codec، NAT و Firewall باشد. اول باید مشخص کنید 403 روی کدام SIP Method آمده، چه سیستمی آن را تولید کرده و قبل از آن چه پیام‌هایی ردوبدل شده‌اند.

در این راهنما خطای 403 را برای REGISTER و INVITE جدا می‌کنیم، Source IP واقعی دیده‌شده توسط Provider را پیدا می‌کنیم، Credential و Digest Authentication را بررسی می‌کنیم، From و PAI را تحلیل می‌کنیم و در پایان دقیقاً مشخص می‌کنیم چه Trace و اطلاعاتی باید برای Provider ارسال شود تا مشخص شود ایراد از سانترال است یا سمت سرویس‌دهنده.

خطای SIP 403 Forbidden دقیقاً چه معنی دارد؟

طبق RFC 3261، پاسخ:

SIP/2.0 403 Forbidden

یعنی SIP Server درخواست را فهمیده اما از اجرای آن خودداری کرده است.

در تعریف استاندارد، ارسال دوباره همان درخواست بدون تغییر معمولاً کمکی نمی‌کند.

اما Providerهای واقعی ممکن است 403 را برای Policyهای مختلف استفاده کنند.

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

این تفاوت در عیب‌یابی بسیار مهم است.

401 همیشه خطا نیست

در Digest Authentication، این Flow می‌تواند کاملاً طبیعی باشد:

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

یا برای تماس خروجی:

INVITE
   |
   v
407 Proxy Authentication Required
   |
INVITE + Proxy-Authorization
   |
   v
100 Trying / 180 Ringing / 200 OK

پس چه زمانی 403 مهم می‌شود؟

مثلاً:

REGISTER
401 Unauthorized
REGISTER + Authorization
403 Forbidden

این Flow نشان می‌دهد Authentication Challenge انجام شده ولی درخواست نهایی رد شده است.

اول مشخص کنید 403 مربوط به کدام Method است

اولین قدم: چه کسی 403 را تولید کرده است؟

قبل از تغییر Configuration باید مشخص کنید پاسخ از:

آمده است.

روی Asterisk لاگ SIP را فعال کنید

asterisk -rvvv

سپس:

pjsip set logger on

فقط یک تماس یا Registration آزمایشی انجام دهید.

پس از پایان:

pjsip set logger off

در پاسخ 403 چه چیزهایی را یادداشت کنیم؟

حداقل:

Call-ID را نگه دارید

مثلاً:

Call-ID: 7c3a91fe2a@example-pbx

وقتی با Provider تماس می‌گیرید، Call-ID یکی از بهترین کلیدها برای پیدا کردن Trace سمت آن‌هاست.

سناریوی اول: REGISTER فوراً 403 می‌گیرد

فرض کنید:

REGISTER sip:sip.provider.example SIP/2.0
...
SIP/2.0 403 Forbidden

و هیچ 401 Challenge قبل از آن وجود ندارد.

در این حالت اول به Password شک نکنید

چون Registrar هنوز فرصت Authentication Digest نداده است.

علت‌های محتمل‌تر:

Source IP واقعی بسیار مهم است

ممکن است فکر کنید Provider درخواست را از IP زیر دریافت می‌کند:

203.0.113.10

اما به‌دلیل NAT یا Multi-WAN، Provider در واقع:

198.51.100.27

را می‌بیند.

IPها فقط نمونه مستندسازی هستند.

از Provider بپرسید چه Source IP می‌بیند

این سؤال از جمله:

«IP ما در ACL شما درست است؟»

بهتر است.

بپرسید:

«این INVITE/REGISTER را دقیقاً از چه Source IP دریافت کرده‌اید؟»

Via received می‌تواند سرنخ بدهد

برخی Providerها در پاسخ چیزی شبیه:

Via: SIP/2.0/UDP 10.0.0.10:5060;
received=198.51.100.27;
rport=5060

برمی‌گردانند.

`received` می‌تواند نشان دهد درخواست از دید Server از کدام Public IP آمده است.

یک نمونه واقعی از رفتار Provider

Twilio در مستندات Trunk خود توضیح می‌دهد اگر اولین INVITE بدون Digest مستقیماً 403 بگیرد، یکی از علت‌های اصلی می‌تواند عدم تطابق Source IP با ACL باشد.

این رفتار یک مثال از Provider است و نباید به‌عنوان قانون عمومی تمام سرویس‌دهنده‌های SIP در نظر گرفته شود.

سناریوی دوم: REGISTER اول 401 می‌گیرد و REGISTER دوم 403

Flow:

REGISTER
   |
401 Unauthorized
   |
REGISTER + Authorization
   |
403 Forbidden

در این حالت Authentication مظنون جدی‌تری است.

چه چیزهایی را بررسی کنیم؟

Username ترانک لزوماً شماره تلفن نیست

یکی از خطاهای رایج این است که کاربر تصور می‌کند:

DID = SIP Username

در حالی که Provider ممکن است یک Username کاملاً جدا ارائه کرده باشد.

مثلاً:

DID:
+982100000000

Auth Username:
customer_76482

نمونه Outbound Registration در Asterisk PJSIP

[provider-reg]
type=registration

server_uri=sip:sip.provider.example
client_uri=sip:ACCOUNT_USERNAME@sip.provider.example

outbound_auth=provider-auth

retry_interval=60
max_retries=10

و Authentication:

[provider-auth]
type=auth
auth_type=userpass
username=ACCOUNT_USERNAME
password=CHANGE_TO_PROVIDER_PASSWORD

این فقط Skeleton آموزشی است؛ `client_uri`، `server_uri`، Realm و سایر گزینه‌ها باید دقیقاً مطابق اطلاعات Provider تنظیم شوند.

وضعیت Registration را ببینید

pjsip show registrations

برای یک Registration مشخص:

pjsip show registration provider-reg

Status = Rejected چه می‌گوید؟

یعنی Provider Registration را نپذیرفته است؛ اما خود Status مشخص نمی‌کند Password اشتباه است یا ACL.

باید Trace SIP را در کنار آن ببینید.

Digest Algorithm را هم بررسی کنید

Asterisk PJSIP جدید علاوه بر MD5 می‌تواند Digestهایی مانند:

را نیز در شرایط پشتیبانی‌شده استفاده کند.

برای دیدن قابلیت‌های PJProject:

pjproject show buildopts

Realm چرا مهم است؟

Digest Authentication فقط Password ساده را ارسال نمی‌کند.

Challenge شامل Realm و Nonce است و Client بر اساس Credential خود Response تولید می‌کند.

اگر Provider Realm خاصی انتظار داشته باشد ولی Configuration شما با Auth Object اشتباه Match شود، Authentication نهایی ممکن است رد شود.

سناریوی سوم: Registration سالم است ولی تماس خروجی 403 می‌گیرد

این یکی از مهم‌ترین حالت‌هاست.

وقتی:

REGISTER = Registered

اما:

INVITE = 403

دیگر نباید فوراً Password Registration را مقصر بدانید.

اول ببینید 403 روی کدام INVITE آمده است

حالت A: اولین INVITE مستقیماً 403 می‌گیرد

علت‌های محتمل:

حالت B: ابتدا 407 می‌آید و INVITE دوم 403 می‌شود

مثلاً:

INVITE
407 Proxy Authentication Required

INVITE
Proxy-Authorization: Digest ...

403 Forbidden

در این حالت Username، Password و Digest Authentication بسیار مهم‌تر می‌شوند.

Twilio نیز همین تفاوت را در مستنداتش مطرح می‌کند

در راهنمای رسمی Trunking این Provider توضیح داده شده که اگر INVITE اولیه 403 شود، ACL یکی از دلایل محتمل است؛ اگر INVITE دارای Digest بعد از Challenge 403 بگیرد، Credential اشتباه یکی از مظنون‌های اصلی است.

این روش تشخیص بسیار مفید است، ولی جزئیات Providerهای دیگر می‌تواند متفاوت باشد.

سناریوی چهارم: مشکل From Header

Provider ممکن است اجازه ندهد هر شماره‌ای را به‌عنوان Caller ID ارسال کنید.

مثلاً PBX می‌فرستد:

From: "Office" <sip:+982112345678@pbx.example.com>

ولی Provider فقط شماره‌ای را می‌پذیرد که روی Account شما ثبت شده است.

نتیجه ممکن است 403 باشد

مثلاً بعضی Providerها Reason دقیق‌تری مانند:

403 Invalid Caller ID

برمی‌گردانند.

P-Asserted-Identity چیست؟

`P-Asserted-Identity` یا PAI برای حمل هویت تأییدشده در شبکه‌های SIP مورداعتماد استفاده می‌شود.

نمونه:

P-Asserted-Identity:
<sip:+982112345678@sip.provider.example>

From و PAI لزوماً یک چیز نیستند

Provider ممکن است:

Policy دقیق باید از مستندات همان Provider گرفته شود.

Caller ID جعلی برای تست ارسال نکنید

برای رفع 403 از شماره‌ای استفاده کنید که Provider رسماً برای همان Account یا Trunk مجاز کرده است.

ارسال یک Caller ID تصادفی نه‌تنها تست درستی نیست، بلکه بعضی Providerها آن را به‌عنوان Traffic غیرمجاز رد می‌کنند.

در Asterisk چه چیزی Caller ID را تعیین می‌کند؟

بسته به Dialplan و Endpoint ممکن است Caller ID از چند نقطه بیاید.

در CLI هنگام Call Setup بررسی کنید:

pjsip set logger on

و دقیقاً INVITE خروجی را ببینید.

به حدس‌زدن از روی تنظیم GUI اکتفا نکنید.

سناریوی پنجم: P-Asserted-Identity اشتباه است

مثلاً From درست است:

From:
<sip:+982112345678@sip.provider.example>

اما PAI هنوز شماره داخلی را دارد:

P-Asserted-Identity:
<sip:1001@pbx.local>

Provider ممکن است آن را نپذیرد.

send_pai را کورکورانه روشن نکنید

در PJSIP گزینه‌هایی برای ارسال PAI وجود دارد، ولی باید مطابق Requirement Provider تنظیم شوند.

ابتدا بدانید Provider کدام Header را انتظار دارد.

سناریوی ششم: Source IP بعد از تغییر اینترنت عوض شده است

یکی از رایج‌ترین علت‌های 403 ناگهانی همین است.

مثلاً:

Provider همچنان فقط IP قبلی را در ACL دارد.

Public IP سرور را فقط از Browser حدس نزنید

مهم این است که SIP Packet از چه Interface و NATی خارج می‌شود.

روی Linux Routing را بررسی کنید:

ip route get PROVIDER_IP

`PROVIDER_IP` را با IP واقعی SIP Provider جایگزین کنید.

Packet Capture نیز Source IP را نشان می‌دهد

اگر SIP بدون TLS روی UDP/TCP است:

sudo tcpdump -ni any host PROVIDER_IP and port 5060

برای ذخیره PCAP

sudo tcpdump -ni any \
host PROVIDER_IP \
and \( port 5060 or port 5061 \) \
-w /tmp/sip-403.pcap

اگر SIP روی TLS باشد چه؟

PCAP مسیر Connection را نشان می‌دهد، اما محتوای SIP رمزنگاری‌شده است.

در این حالت Log خود Asterisk یا SBC اهمیت بیشتری دارد.

sngrep برای SIP بدون TLS بسیار مفید است

اگر نصب است:

sudo sngrep -d any port 5060

Flow تماس را به شکل:

PBX                Provider

INVITE     -------->
           <-------- 407

INVITE+AUTH ------->
           <-------- 403

به‌وضوح نشان می‌دهد.

سناریوی هفتم: Provider مقصد را مجاز نمی‌داند

گاهی Authentication کاملاً درست است، اما Account اجازه تماس با مقصد را ندارد.

نمونه‌ها:

یک تست بسیار مفید

با همان:

یک مقصد داخلی یا موبایل دیگری را امتحان کنید.

اگر فقط یک گروه مقصد 403 می‌گیرد، احتمال Policy مقصد بیشتر می‌شود.

سناریوی هشتم: Request-URI اشتباه است

Provider ممکن است انتظار داشته باشد Destination در Request-URI با Format مشخص باشد.

مثلاً:

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

در حالی که PBX چیزی متفاوت ارسال می‌کند.

403 همیشه مشکل Codec نیست

اگر Provider SIP Request را به‌دلیل Media Offer قبول نکند، کدهایی مانند:

معمولاً معنای مستقیم‌تری دارند.

پس وقتی 403 می‌بینید، قبل از Codec روی:

Authentication، Identity، ACL و Policy

تمرکز کنید؛ مگر Trace Provider خلاف آن را ثابت کند.

سناریوی نهم: مشکل از خود Asterisk است، نه Provider

گاهی Asterisk خودش به REGISTER ورودی 403 می‌دهد.

مثلاً اگر:

max_contacts

برای AOR درست تنظیم نشده باشد.

نمونه AOR

[1001]
type=aor
max_contacts=1

اگر Contact قبلی هنوز وجود داشته باشد

و Device جدید Register شود، ممکن است محدودیت Contacts باعث Reject شدن Registration شود.

بررسی کنید:

pjsip show aor 1001

و:

pjsip show contacts

remove_existing چه زمانی کاربرد دارد؟

اگر می‌خواهید Contact جدید جای Contact قبلی را بگیرد:

remove_existing=yes

قابل بررسی است.

اما این گزینه را فقط وقتی فعال کنید که واقعاً رفتار موردنظر شما همین باشد.

برای Trunk ورودی Identify را بررسی کنید

اگر Provider تماس ورودی می‌فرستد، Asterisk باید Source را به Endpoint درست Match کند.

نمونه:

[provider-identify]
type=identify
endpoint=provider-endpoint
match=PROVIDER_SIGNALING_IP

فقط IPهای رسمی اعلام‌شده توسط Provider را وارد کنید.

تمام اینترنت را Trusted Peer نکنید

برای رفع سریع 403 یا 401 هرگز چیزی شبیه:

Allow Any Source

را روی Trunk اینترنتی فعال نکنید.

این کار مشکل Authentication را به یک مشکل امنیتی بزرگ‌تر تبدیل می‌کند.

Retry مداوم 403 کار درستی نیست

طبق معنای استاندارد 403، تکرار همان Request بدون تغییر معمولاً نباید انجام شود.

Asterisk نیز برای Outbound Registration گزینه خاص:

forbidden_retry_interval

دارد.

مقدار پیش‌فرض آن صفر است.

یعنی Asterisk معمولاً بعد از 403 متوقف می‌شود

این رفتار منطقی است؛ چون اگر Password یا ACL اشتباه باشد، فرستادن صدها REGISTER مشکل را حل نمی‌کند.

چه زمانی forbidden_retry_interval تنظیم کنیم؟

فقط وقتی می‌دانید Registrar موردنظر ممکن است 403 موقت برگرداند یا خود Provider چنین توصیه‌ای کرده باشد.

مثال:

forbidden_retry_interval=300

این مقدار نمونه است، نه توصیه عمومی.

بعد از اصلاح Config چطور Registration را دوباره تست کنیم؟

می‌توانید Registration مشخص را دوباره آغاز کنید:

pjsip send register provider-reg

قبل از تماس با Provider چه اطلاعاتی جمع کنیم؟

اگر می‌خواهید Ticket شما سریع نتیجه بدهد، فقط ننویسید:

«ترانک 403 می‌دهد.»

این اطلاعات را بفرستید:

Password و Authorization کامل را برای Ticket عمومی ارسال نکنید

Headerهای Digest شامل اطلاعات حساس Session هستند.

اگر Provider Trace کامل می‌خواهد، از Channel امن پشتیبانی خودش استفاده کنید و Credential اصلی را در Forum یا Screenshot عمومی منتشر نکنید.

از Provider دقیقاً چه سؤال‌هایی بپرسیم؟

سؤال‌های مفید:

Provider Trace از PCAP شما مهم‌تر است؟

در بسیاری از 403ها بله.

PCAP شما نشان می‌دهد چه چیزی فرستاده‌اید و چه پاسخی گرفته‌اید.

اما Provider می‌تواند ببیند:

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

مرحله ۱: `pjsip set logger on`.

مرحله ۲: فقط یک REGISTER یا تماس آزمایشی.

مرحله ۳: Method مربوط به 403 را پیدا کنید.

مرحله ۴: ببینید 403 قبل یا بعد از 401/407 آمده است.

مرحله ۵: Source IP واقعی را مشخص کنید.

مرحله ۶: From و PAI را بررسی کنید.

مرحله ۷: Call-ID را ذخیره کنید.

مرحله ۸: Provider Log را با همان Call-ID درخواست کنید.

Decision Tree خطای SIP 403

403 روی REGISTER است؟

🔹 بله → آیا قبلش 401 آمده؟

اگر نه → ACL، Source IP، Registrar Domain و Account Policy.

اگر بله → Username، Password، Realm و Digest.

403 روی INVITE است؟

🔹 آیا قبلش 407 آمده؟

اگر بله → Credential خروجی.

اگر نه → ACL، Route، Request-URI و Provider Policy.

Authentication درست است ولی هنوز 403 دارید؟

🔹 From، PAI، Caller ID، Destination Permission و Account Status را بررسی کنید.

جدول تشخیص سریع

یک INVITE سالم و خراب را Diff کنید

اگر یک تماس کار می‌کند و دیگری 403 می‌گیرد، این روش بسیار مؤثر است.

مقایسه کنید:

معمولاً تفاوت واقعی سریع‌تر پیدا می‌شود.

چه کارهایی را برای رفع 403 انجام ندهیم؟

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

خطای SIP 403 Forbidden یعنی چه؟

یعنی SIP Server درخواست را فهمیده اما آن را نپذیرفته است. علت دقیق می‌تواند Authentication، Source IP، Caller ID، Route یا Policy Provider باشد.

آیا SIP 403 همیشه یعنی Password اشتباه است؟

خیر. Password فقط یکی از علت‌هاست. اگر اولین Request بدون Challenge مستقیماً 403 شده باشد، Source IP، ACL یا Policy نیز باید بررسی شود.

فرق 401 با 403 چیست؟

401 معمولاً بخشی از Digest Authentication و درخواست Credential است، در حالی که 403 یعنی درخواست نهایی پذیرفته نشده است.

چرا Trunk Registered است ولی تماس خروجی 403 می‌دهد؟

Registration و مجوز تماس دو موضوع جدا هستند. Caller ID، From، PAI، Source IP، Destination Permission و Route خروجی را بررسی کنید.

چرا بعد از تغییر IP اینترنت Trunk 403 می‌دهد؟

اگر Provider از IP ACL استفاده کند، Public IP جدید شما در لیست مجاز قرار ندارد و باید Source IP جدید با Provider هماهنگ شود.

P-Asserted-Identity می‌تواند باعث 403 شود؟

بله. بعضی Providerها هویت تماس را از PAI کنترل می‌کنند و اگر شماره داخل آن متعلق به Account یا Trunk نباشد ممکن است تماس را Reject کنند.

از کجا بفهمم 403 را Provider داده یا Asterisk؟

با PJSIP Logger یا Packet Capture IP فرستنده Response، Call-ID و SIP Flow را بررسی کنید. اگر پاسخ از IP Provider وارد شده باشد، Reject در سمت آن مسیر رخ داده است.

آیا Codec اشتباه باعث 403 می‌شود؟

ممکن است یک Provider رفتار اختصاصی داشته باشد، اما برای مشکل Media معمولاً کدهایی مثل 415 یا 488 معنای مستقیم‌تری دارند. در 403 ابتدا Authentication و Policy را بررسی کنید.

چرا Asterisk به Registration داخلی 403 می‌دهد؟

یکی از علت‌ها تنظیم نبودن `max_contacts` یا پرشدن ظرفیت Contactهای AOR است. Log Asterisk معمولاً علت را مشخص می‌کند.

برای ارسال مشکل به Provider چه چیزی لازم است؟

Timestamp دقیق، Call-ID، Source IP، Destination، Caller ID، SIP Method، Sequence مربوط به 401/407/403 و در صورت نیاز PCAP یا SIP Trace را ارسال کنید.

آیا باید forbidden_retry_interval را فعال کنم؟

نه به‌صورت عمومی. مقدار پیش‌فرض صفر منطقی است. فقط اگر Provider اعلام کرده 403 ممکن است موقت باشد یا Registrar رفتار خاصی دارد، Retry کنترل‌شده را در نظر بگیرید.