چرا PJSIP در Asterisk رجیستر نمی‌شود؟ علت و روش رفع خطاهای 401 و 403

بهترین ابزار برای این کار داخل خود Asterisk قرار دارد:

pjsip set logger on

این دستور SIP Messageهایی را که Asterisk دریافت و ارسال می‌کند در CLI نشان می‌دهد و به‌جای حدس می‌توان دقیقاً دید REGISTER چه Username، Domain، Contact، Authorization و Transportی دارد و Asterisk چه Responseی برمی‌گرداند.

در این آموزش یک روش استاندارد برای خطای PJSIP registration failed می‌سازیم: ابتدا Reachability و Transport، بعد Endpoint Identification، سپس 401 و Authentication، بعد AOR و 403 و در آخر NAT و TLS را بررسی می‌کنیم.

اول مشخص کنیم کدام Registration خراب است

در Asterisk دو سناریوی متفاوت با واژه Registration داریم.

سناریوی اول: یک IP Phone، Softphone یا ATA می‌خواهد روی Asterisk Register شود.

در این حالت Asterisk نقش Registrar را دارد.

سناریوی دوم: خود Asterisk می‌خواهد به SIP Provider یا Registrar دیگری Register شود.

در این حالت Asterisk Client یا UAC است.

این مقاله ابتدا حالت اول یعنی رجیستر نشدن داخلی را بررسی می‌کند و در بخش پایانی Outbound Registration به Provider را نیز جدا می‌کنیم.

Flow سالم Registration در PJSIP چگونه است؟

برای یک داخلی دارای Digest Authentication معمولاً Flow شبیه این است:

Phone -> Asterisk
REGISTER

Asterisk -> Phone
401 Unauthorized
WWW-Authenticate: Digest ...

Phone -> Asterisk
REGISTER
Authorization: Digest ...

Asterisk -> Phone
200 OK

بنابراین دیدن یک 401 اول کاملاً طبیعی است.

401 اول خطا نیست

یکی از اشتباه‌های رایج در عیب‌یابی PJSIP این است که Administrator اولین:

SIP/2.0 401 Unauthorized

را می‌بیند و فوراً Password را تغییر می‌دهد.

در SIP Digest Authentication، 401 اولیه Challenge است.

سؤال مهم این است:

بعد از 401 چه اتفاقی می‌افتد؟

روش استاندارد شروع عیب‌یابی

وارد Asterisk CLI شوید:

asterisk -rvvv

سپس:

core set verbose 5
core set debug 5
pjsip set logger on

حالا فقط یک بار Registration را روی Phone تکرار کنید.

بعد از ثبت مشکل Logger را خاموش کنید:

pjsip set logger off
core set debug 0
core set verbose 0

چرا Logger را همیشه روشن نگذاریم؟

SIP Logger می‌تواند اطلاعاتی مثل SIP URI، IP، شماره داخلی، Headerها و Authentication Metadata را ثبت کند.

روی PBX شلوغ حجم Log نیز بسیار سریع افزایش پیدا می‌کند.

Logger را فقط برای مدت کوتاه عیب‌یابی روشن کنید و Log را عمومی منتشر نکنید.

مرحله ۱: آیا REGISTER اصلاً به Asterisk می‌رسد؟

بعد از:

pjsip set logger on

Phone را Register کنید.

اگر هیچ REGISTERای در CLI ظاهر نمی‌شود، Password و AOR فعلاً موضوع اصلی نیستند.

این موارد را بررسی کنید:

🔹 SIP Server تلفن درست است؟

🔹 DNS درست Resolve می‌شود؟

🔹 SIP Port درست است؟

🔹 Phone روی UDP، TCP یا TLS تنظیم شده؟

🔹 Asterisk روی همان Transport گوش می‌دهد؟

🔹 Firewall Packet را قبل از Asterisk Drop نمی‌کند؟

🔹 Route رفت و برگشت سالم است؟

Transportهای فعال را ببینید

pjsip show transports

مثلاً انتظار دارید چیزی شبیه:

transport-udp   udp   0.0.0.0:5060

داشته باشید.

Phone روی TCP است ولی Asterisk فقط UDP دارد

در این حالت ممکن است Phone بارها تلاش کند اما PJSIP Logger هیچ SIP Messageای نشان ندهد.

Transport نمونه UDP:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060

TCP:

[transport-tcp]
type=transport
protocol=tcp
bind=0.0.0.0:5060

تغییر Transport با Reload معمولی همیشه اعمال نمی‌شود

در PJSIP، Transport Configuration به‌طور معمول با Reload ساده تغییر نمی‌کند.

اگر Transport را تغییر داده‌اید، برای اعمال کامل آن ممکن است Restart کنترل‌شده Asterisk لازم باشد.

systemctl restart asterisk

روی Production این دستور تماس‌های فعال را قطع می‌کند. آن را فقط در Maintenance Window اجرا کنید.

مرحله ۲: Endpoint واقعاً Load شده است؟

قبل از بررسی Authentication مطمئن شوید Endpoint وجود دارد.

pjsip show endpoint 1001

اگر:

Unable to find object 1001

می‌بینید، Password تلفن را تغییر ندهید.

Endpoint اصلاً با این نام در PJSIP Load نشده است.

Endpoint سالم چه ارتباط‌هایی باید داشته باشد؟

خروجی:

pjsip show endpoint 1001

را برای این موارد بررسی کنید:

🔹 InAuth

🔹 Aor

🔹 Transport

🔹 Identify در صورت استفاده

🔹 Context

اگر InAuth وجود ندارد، Asterisk آن Endpoint را دارای Authentication ورودی نمی‌بیند.

Configuration پایه صحیح یک داخلی

[1001]
type=endpoint
transport=transport-udp
context=from-internal
disallow=all
allow=alaw,ulaw
auth=1001-auth
aors=1001
direct_media=no

[1001-auth]
type=auth
auth_type=userpass
username=1001
password=REPLACE-WITH-A-LONG-RANDOM-PASSWORD

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

مرحله ۳: Asterisk چگونه Endpoint را شناسایی می‌کند؟

قبل از Authentication، Asterisk باید بفهمد Request متعلق به کدام Endpoint است.

در PJSIP این فرآیند Endpoint Identification نام دارد.

روش‌های مهم شامل:

🔹 username

🔹 auth_username

🔹 ip

🔹 header

🔹 request_uri در Identify Objectهای جدیدتر

هستند.

Identifierهای فعال را ببینید

pjsip show identifiers

ترتیب Identifierها نیز مهم است.

Default فعلی Asterisk در Global Configuration:

endpoint_identifier_order=ip,username,anonymous

است، مگر اینکه Configuration شما آن را تغییر داده باشد.

identify_by برای Registration اهمیت ویژه دارد

در Endpoint می‌توان تعیین کرد Asterisk آن را با چه روش‌هایی شناسایی کند.

مثلاً برای داخلی ساده:

identify_by=username

منطقی است.

در Registration یک نکته ظریف وجود دارد: روش Identification باید بتواند AOR را نیز مشخص کند؛ وگرنه خود Endpoint ممکن است قابل شناسایی باشد ولی REGISTER نتواند به AOR مناسب متصل شود.

Username تلفن با نام Endpoint هماهنگ نیست

فرض کنید Endpoint شما:

[1001]

است، اما Phone REGISTER را با:

From: <sip:2001@pbx.example.com>

می‌فرستد.

اگر روش Identification شما بر Username تکیه دارد، احتمالاً Endpoint 1001 Match نمی‌شود.

نکته مهم: 401 می‌تواند علامت Endpoint اشتباه باشد

Asterisk برای جلوگیری از افشای وجود Endpointها، حتی وقتی Request به هیچ Endpoint واقعی Match نشده باشد می‌تواند یک Challenge ظاهراً معتبر 401 برگرداند.

این یعنی Flow زیر:

REGISTER
401 Unauthorized

به‌تنهایی ثابت نمی‌کند Asterisk داخلی 1001 را پیدا کرده است.

در Log دنبال چه پیام‌هایی بگردیم؟

اگر مفهوم پیام‌هایی شبیه این را می‌بینید:

Could not identify endpoint by username
No matching endpoint found

مشکل Password را فعلاً کنار بگذارید.

Endpoint Identification شکست خورده است.

auth_username چه زمانی مفید است؟

گاهی User داخل From با Authentication Username متفاوت است.

در چنین معماری‌ای می‌توان:

identify_by=username,auth_username

را بررسی کرد.

اما این روش یک نکته امنیتی دارد: Authorization Header در اولین REGISTER وجود ندارد و فقط بعد از 401 ایجاد می‌شود، بنابراین Identification مبتنی بر auth_username دیرتر انجام می‌شود.

بدون نیاز واقعی، Identifierها را پیچیده نکنید.

type=identify بیشتر برای چه چیزی استفاده می‌شود؟

بخش:

type=identify

معمولاً برای نسبت‌دادن ترافیک ورودی از یک SIP Provider یا Gateway به Endpoint مشخص استفاده می‌شود.

مثلاً:

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

برای یک IP Phone که خودش روی Asterisk Register می‌شود، معمولاً Username/Auth-based Identification مهم‌تر از IP ثابت است؛ چون IP Phone ممکن است DHCP یا NAT داشته باشد.

مرحله ۴: حالا Authentication را بررسی کنید

اگر Endpoint درست شناسایی شده، به مرحله Authentication می‌رسیم.

خروجی:

pjsip show endpoint 1001

باید بخش InAuth را نشان دهد.

مثلاً:

InAuth: 1001-auth/1001

اگر InAuth دیده نمی‌شود

Endpoint ممکن است:

🔹 اصلاً `auth=` نداشته باشد.

🔹 نام Auth Object اشتباه باشد.

🔹 Auth Object Load نشده باشد.

🔹 Configuration Syntax Error داشته باشد.

REGISTER دوم باید Authorization داشته باشد

بعد از 401، Phone باید REGISTER دوم را با Header مشابه:

Authorization: Digest username="1001", ...

ارسال کند.

اگر Phone بعد از 401 دیگر REGISTER نفرستد، احتمالاً خود Client Authentication Challenge را قبول نکرده است.

401 پشت سر هم چه معنی دارد؟

اگر این Flow تکرار می‌شود:

REGISTER
401

REGISTER + Authorization
401

REGISTER + Authorization
401

این موارد را بررسی کنید:

🔹 Password تلفن و Asterisk یکسان است؟

🔹 Auth Username دقیقاً درست است؟

🔹 Realm همان چیزی است که Client انتظار دارد؟

🔹 Endpoint واقعاً Match شده یا 401 ساختگی Endpoint ناشناس است؟

🔹 Algorithm احراز هویت در هر دو سمت مشترک است؟

Asterisk 22 فقط MD5 نیست

از Asterisk 22.2 به بعد، در صورت وجود PJProject و OpenSSL مناسب، PJSIP می‌تواند Digestهای:

🔹 MD5

🔹 SHA-256

🔹 SHA-512-256

را پشتیبانی کند.

اما Default همچنان MD5 است مگر Configuration شما تغییر کند.

قابلیت Build فعلی را ببینید:

pjproject show buildopts

اگر Phone قدیمی است، قبل از اجبار SHA-256 مطمئن شوید آن را پشتیبانی می‌کند.

مرحله ۵: AOR را بررسی کنید

حتی Endpoint و Auth صحیح هم بدون AOR قابل‌رجیستر نیستند.

pjsip show aor 1001

max_contacts یکی از علت‌های واقعی 403 است

برای Registration دینامیک، AOR باید اجازه ایجاد Contact داشته باشد.

مثلاً:

[1001]
type=aor
max_contacts=1

اگر `max_contacts` صفر بماند یا برای Registration قابل استفاده نباشد، Asterisk می‌تواند REGISTER را با 403 رد کند.

403 به دلیل پرشدن Contactها

فرض کنید:

max_contacts=1

دارید و یک Contact قدیمی هنوز روی AOR باقی مانده است.

Registration جدید ممکن است ظرفیت AOR را پر کند و 403 بگیرد.

Contactها را ببینید:

pjsip show contacts

رفتار شبیه chan_sip برای یک دستگاه

اگر یک داخلی فقط باید یک Phone داشته باشد، ترکیب رایج:

max_contacts=1
remove_existing=yes

است.

Registration جدید در صورت نیاز Contact قدیمی را جایگزین می‌کند.

rewrite_contact و max_contacts می‌توانند با هم اثر داشته باشند

در NAT ممکن است Source Port تلفن با هر Registration تغییر کند.

وقتی:

rewrite_contact=yes

دارید، Asterisk Source IP/Port واقعی را به‌عنوان Contact در نظر می‌گیرد.

اگر NAT هر بار Source Port جدید بسازد، Contact جدید ممکن است با Contact قبلی متفاوت دیده شود.

در این حالت `remove_existing=yes` می‌تواند برای داخلی تک‌دستگاهی مفید باشد.

مرحله ۶: NAT را درست از Registration جدا کنیم

سه گزینه‌ای که معمولاً برای Remote Endpoint دیده می‌شوند:

force_rport=yes
rewrite_contact=yes
rtp_symmetric=yes

اما هر سه یک کار نمی‌کنند.

force_rport

SIP Response را به IP و Port واقعی‌ای برمی‌گرداند که Request از آن آمده است.

برای Phone پشت NAT اهمیت مستقیم در SIP دارد.

rewrite_contact

به‌جای اعتماد به Contact Header خصوصی یا اشتباه Phone، Source IP و Port واقعی Request را برای درخواست‌های بعدی استفاده می‌کند.

این گزینه نیز مستقیماً به Signaling و Registration مربوط است.

rtp_symmetric

این گزینه مربوط به Media است.

RTP را به همان IP/Portی می‌فرستد که Media از آن دریافت شده است.

اگر مشکل شما فقط REGISTER است، تغییر rtp_symmetric قرار نیست Password یا Endpoint Identification را درست کند.

نمونه Endpoint پشت NAT

[1001]
type=endpoint
transport=transport-udp
context=from-internal

disallow=all
allow=alaw,ulaw

auth=1001-auth
aors=1001

direct_media=no
force_rport=yes
rewrite_contact=yes
rtp_symmetric=yes

[1001-auth]
type=auth
auth_type=userpass
username=1001
password=USE-A-LONG-RANDOM-PASSWORD

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

اگر خود Asterisk پشت NAT است

حالا مسئله Transport نیز مهم می‌شود.

نمونه:

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5060

local_net=10.10.0.0/16
external_signaling_address=203.0.113.20
external_media_address=203.0.113.20

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

این تنظیم بیشتر برای درست‌شدن SIP/SDP آدرس‌های خروجی Asterisk است.

Registration داخلی با IP خصوصی در Contact همیشه مشکل نیست

اگر Phone داخل همان LAN است، Contact خصوصی کاملاً طبیعی است.

حتی برای Phone پشت NAT، اگر `rewrite_contact=yes` دارید، Asterisk می‌تواند Source Address واقعی را ذخیره کند.

فقط به‌خاطر دیدن 192.168.x.x در یک SIP Header NAT Optionها را تصادفی فعال نکنید.

مرحله ۷: TLS Registration را جدا بررسی کنیم

اگر Phone روی TLS است، Transport باید واقعاً TLS Listener داشته باشد.

نمونه:

[transport-tls]
type=transport
protocol=tls
bind=0.0.0.0:5061

cert_file=/etc/asterisk/keys/pbx.crt
priv_key_file=/etc/asterisk/keys/pbx.key
method=tlsv1_2

اگر TLS Handshake اصلاً کامل نشود، هنوز به SIP Authentication نرسیده‌اید.

مزیت pjsip set logger روی TLS

در Packet Capture شبکه، SIP داخل TLS رمز شده و به‌صورت Plaintext دیده نمی‌شود.

اما داخل خود Asterisk، PJSIP Logger در سطح SIP Stack کار می‌کند و بعد از Terminate شدن TLS می‌تواند SIP Messageهایی را که Asterisk پردازش می‌کند نشان دهد.

به همین دلیل برای مشکل Registration روی TLS، ترکیب:

TLS/network diagnostics + pjsip set logger

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

Phone TLS Connection می‌سازد ولی REGISTER نمی‌فرستد

در این حالت Transport و Certificate تا حدی جلو رفته‌اند ولی Client هنوز SIP Registration را شروع نکرده است.

مواردی مثل:

🔹 SIP Account Disabled

🔹 Registrar اشتباه

🔹 Client-side Certificate Policy

🔹 SIP Port اشتباه

🔹 Provisioning ناقص

را بررسی کنید.

ماژول Registrar Load شده است؟

برای دریافت REGISTER داخلی‌ها:

module show like res_pjsip_registrar.so

باید Status فعال نشان داده شود.

اگر Registrar Module وجود ندارد، Asterisk نمی‌تواند Registration دینامیک Endpoint را طبق انتظار پردازش کند.

Identify Module برای IP Matching

برای Trunkها یا Endpointهایی که با IP Identify می‌شوند:

module show like res_pjsip_endpoint_identifier_ip.so

را بررسی کنید.

یک روش سریع برای تشخیص 401

یک روش سریع برای تشخیص 403

403 را با Password اشتباه نگیریم

در Registration داخلی Asterisk، 403 می‌تواند بعد از Authentication و در مرحله Registrar/AOR اتفاق بیفتد.

پس اگر Logger صریحاً می‌گوید:

Registration attempt ... will exceed max contacts

تغییر Password هیچ ارتباطی با علت اصلی ندارد.

qualify_frequency به Registration کمک می‌کند؟

پارامتر:

qualify_frequency=30

باعث می‌شود Asterisk به Contact دوره‌ای OPTIONS بفرستد و Availability را بررسی کند.

اما Qualify مشکل Password یا Endpoint Identification را حل نمی‌کند.

این قابلیت بیشتر برای تشخیص زنده‌بودن Contact پس از Registration مفید است.

Contact وجود دارد ولی Endpoint Unavailable است

این حالت با «Register نشده» یکسان نیست.

اگر:

pjsip show contacts

Contact دارد ولی Status آن Unavailable است، OPTIONS Qualify پاسخ نگرفته است.

حالا Firewall، NAT Mapping یا Offline شدن Phone را بررسی کنید.

Registration سالم است؟ این سه فرمان باید منطقی باشند

pjsip show endpoint 1001
pjsip show aor 1001
pjsip show contacts

انتظار داریم:

Endpoint → Auth و AOR صحیح داشته باشد.

AOR → Contact فعال داشته باشد.

Contact → IP/Port مورد انتظار Phone را نشان دهد.

اگر IP Contact عجیب است

مثلاً Phone پشت NAT است و Asterisk چنین Contactی ذخیره کرده:

sip:1001@192.168.1.50:5060

در حالی که Asterisk روی اینترنت است.

در این حالت `rewrite_contact=yes` را بررسی کنید.

بعد از Registration جدید Contact باید بر اساس Source قابل دسترس Asterisk ساخته شود.

SIP ALG را نیز در Router بررسی کنید

برخی Routerها SIP Headerها را در مسیر دست‌کاری می‌کنند.

این رفتار می‌تواند Contact، Via یا Port را تغییر دهد و باعث Registration ناپایدار شود.

اگر Logger نشان می‌دهد Headerهایی که Phone ارسال می‌کند با چیزی که انتظار دارید هماهنگ نیستند، Capture در دو طرف Router می‌تواند مشخص کند آیا SIP ALG در مسیر دخالت کرده است.

اما SIP ALG را بدون مدرک مقصر ندانید

مشکلات زیادی به SIP ALG نسبت داده می‌شوند در حالی که علت واقعی:

🔹 Endpoint اشتباه

🔹 max_contacts

🔹 Firewall

🔹 Transport

🔹 Password

است.

Logger و PCAP باید تغییر Header را ثابت کنند.

اگر خود Asterisk به Provider رجیستر نمی‌شود

این حالت با داخلی متفاوت است.

ابتدا:

pjsip show registrations

را اجرا کنید.

Status می‌تواند مواردی مثل Registered، Unregistered، Rejected یا وضعیت‌های مشابه نشان دهد.

نمونه Outbound Registration

[provider-registration]
type=registration
transport=transport-udp
outbound_auth=provider-auth

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

retry_interval=60

401 در Outbound Registration

برای Provider نیز 401 اول می‌تواند Challenge طبیعی باشد.

Asterisk باید REGISTER دوم را با Authorization بفرستد.

اگر Provider همچنان Authentication را Reject می‌کند، بررسی کنید:

🔹 username

🔹 password

🔹 realm

🔹 client_uri

🔹 server_uri

🔹 Auth Algorithm

403 از Provider رفتار متفاوتی دارد

در Outbound Registration، 403 معمولاً یعنی Registrar درخواست را Forbidden کرده است.

PJSIP برای Outbound Registration گزینه:

forbidden_retry_interval

دارد.

اگر مقدار آن صفر باشد، Asterisk بعد از 403 به‌صورت خودکار Retry نمی‌کند.

قبل از افزایش این مقدار، علت 403 را از Provider پیدا کنید؛ Retry مداوم یک Account واقعاً Forbidden راه‌حل نیست.

یک Test Plan ده‌مرحله‌ای برای PJSIP registration failed

مرحله ۱: `pjsip set logger on` را فعال کنید.

مرحله ۲: Phone را یک بار Register کنید.

مرحله ۳: اگر REGISTER نمی‌آید، Transport/Firewall/DNS را بررسی کنید.

مرحله ۴: `pjsip show endpoint 1001` را بررسی کنید.

مرحله ۵: Endpoint Identification و Usernameهای SIP را مقایسه کنید.

مرحله ۶: 401 اول را طبیعی فرض کنید و REGISTER دوم را ببینید.

مرحله ۷: Authorization Username و Password/Realm را بررسی کنید.

مرحله ۸: `pjsip show aor 1001` و `max_contacts` را بررسی کنید.

مرحله ۹: Contact و NAT Source IP/Port را بررسی کنید.

مرحله ۱۰: بعد از 200 OK، Qualify و تماس واقعی را تست کنید.

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

چه زمانی Packet Capture لازم می‌شود؟

`pjsip set logger` برای SIP فوق‌العاده است، اما اگر شک دارید Packet اصلاً به Asterisk نمی‌رسد یا Router چیزی را در مسیر تغییر می‌دهد، PCAP لازم می‌شود.

برای UDP SIP نمونه:

tcpdump -ni any udp port 5060

برای ذخیره فایل:

tcpdump -ni any udp port 5060 -w /tmp/pjsip-register.pcap

فایل PCAP ممکن است اطلاعات حساس داشته باشد؛ بعد از عیب‌یابی آن را از مسیر موقت رها نکنید.

Factory Reset تلفن لازم است؟

تقریباً هیچ‌کدام از خطاهای رایج بالا در قدم اول به Factory Reset نیاز ندارند.

اگر Asterisk صریحاً 403 به دلیل max_contacts می‌دهد، Reset Phone چیزی را در AOR اصلاح نمی‌کند.

اگر Endpoint Match نمی‌شود، Reset نیز نام Endpoint را عوض نمی‌کند.

اگر Firewall UDP/5060 را Drop می‌کند، Reset تأثیری ندارد.

ابتدا SIP Flow را ذخیره کنید و علت را ثابت کنید.

Configuration پیشنهادی ساده برای داخلی Remote

برای یک داخلی معمولی پشت NAT که فقط یک Device دارد:

[1001]
type=endpoint
transport=transport-udp
context=from-internal

disallow=all
allow=alaw,ulaw

auth=1001-auth
aors=1001
identify_by=username

direct_media=no
force_rport=yes
rewrite_contact=yes
rtp_symmetric=yes

[1001-auth]
type=auth
auth_type=userpass
username=1001
password=REPLACE-WITH-A-UNIQUE-RANDOM-PASSWORD

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

این Config یک Baseline آموزشی است، نه نسخه مناسب برای همه شبکه‌ها.

اگر Endpoint روی LAN است، SBC دارید، چند Device روی یک داخلی دارید یا TLS استفاده می‌کنید، Configuration باید متناسب با همان معماری تغییر کند.

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

آیا 401 Unauthorized در PJSIP یعنی Password اشتباه است؟

خیر. اولین 401 معمولاً Challenge طبیعی Digest Authentication است. همچنین Asterisk ممکن است وقتی Endpoint اصلاً Match نشده یک Challenge ساختگی بفرستد تا اطلاعات Endpointها افشا نشود.

چرا بعد از 401 دوباره 401 می‌گیرم؟

Auth Username، Password، Realm و Digest Algorithm را بررسی کنید؛ هم‌زمان Log را ببینید تا مطمئن شوید Endpoint واقعی شناسایی شده و با یک 401 Dummy روبه‌رو نیستید.

403 هنگام REGISTER در Asterisk چه معنی دارد؟

یکی از علت‌های مهم در PJSIP این است که AOR مقدار مناسب max_contacts ندارد یا Registration جدید از ظرفیت Contactهای مجاز عبور می‌کند.

چطور بفهمم داخلی واقعاً Register شده است؟

`pjsip show aor 1001` و `pjsip show contacts` را بررسی کنید. وجود Contact معتبر و دریافت 200 OK برای REGISTER مهم‌ترین نشانه‌های موفقیت‌اند.

فرق Endpoint و AOR در خطای Registration چیست؟

Endpoint رفتار SIP و Auth را به هم متصل می‌کند؛ AOR محل ثبت Contact دستگاه است. ممکن است Endpoint صحیح باشد ولی AOR اجازه ثبت Contact ندهد و Registration با 403 شکست بخورد.

برای Phone پشت NAT چه گزینه‌هایی مهم‌اند؟

برای Signaling معمولاً `force_rport` و `rewrite_contact` مهم‌اند. `rtp_symmetric` مربوط به Media است و مشکل Authentication REGISTER را حل نمی‌کند.

چرا Phone اصلاً در pjsip set logger دیده نمی‌شود؟

Transport، IP/Hostname سرور، SIP Port، DNS، Firewall و Route را بررسی کنید. اگر Packet قبل از رسیدن به Asterisk Drop شود، PJSIP Logger چیزی برای نمایش ندارد.

آیا تغییر Transport با pjsip reload کافی است؟

Transport Configuration معمولاً با Reload کامل اعمال نمی‌شود و برای تغییر Transport ممکن است Restart کنترل‌شده Asterisk لازم باشد.

اگر خود Asterisk به Provider رجیستر نمی‌شود چه فرمانی بزنیم؟

از `pjsip show registrations` برای مشاهده Outbound Registrationها استفاده کنید و هم‌زمان `pjsip set logger on` را برای مشاهده REGISTER و Response Provider فعال کنید.