چرا Cisco MPP خطای TLS Handshake می‌دهد؟ بررسی Certificate و NTP

در Cisco 7800 و 8800 با Multiplatform Firmware، این خطا معمولاً در یکی از چند نقطه رخ می‌دهد: سرور Certificate اشتباه ارائه می‌کند، Intermediate CA ناقص است، Root CA مورد اعتماد Phone نیست، نام Proxy با SAN گواهی تطبیق ندارد، ساعت Cisco اشتباه است، Server فقط نسخه TLS نامناسبی قبول می‌کند یا یک Load Balancer و TLS Virtual Host بر اساس SNI Certificate دیگری تحویل می‌دهد.

در این راهنما به‌جای خاموش‌کردن Certificate Validation، TLS را از TCP SYN تا ClientHello، ServerHello، Certificate و در نهایت SIP REGISTER دنبال می‌کنیم تا دقیقاً مشخص شود Handshake در کدام مرحله متوقف شده است.

TLS Handshake در Cisco MPP قبل از Registration چه مسیری دارد؟

در یک Registration سالم با TLS، ترتیب کلی تقریباً این است:

DNS / SRV
   ↓
TCP SYN
   ↓
TCP SYN, ACK
   ↓
ClientHello
   ↓
ServerHello
   ↓
Server Certificate
   ↓
Certificate Validation
   ↓
TLS Finished
   ↓
SIP REGISTER
   ↓
401 Unauthorized
   ↓
REGISTER + Authorization
   ↓
200 OK

این زنجیره برای عیب‌یابی بسیار مهم است؛ چون هر مرحله‌ای که متوقف شود، گروه علت‌های احتمالی را کوچک‌تر می‌کند.

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

مرحله اول: مطمئن شوید Cisco واقعاً TLS استفاده می‌کند

در Web Interface تلفن وارد:

Admin Login → advanced → Voice → Ext(n)

شوید.

در بخش SIP Settings باید Transport مطابق طراحی باشد:

SIP Transport = TLS

اگر از Provisioning استفاده می‌کنید، Configuration نیز می‌تواند چیزی شبیه این باشد:

<SIP_Transport_1_ ua="na">TLS</SIP_Transport_1_>

Port TLS را حدس نزنید

برای SIP/TLS مقدار 5061 رایج است، اما SRV Record، Provider یا PBX می‌تواند Port دیگری معرفی کند.

اگر Proxy را به‌شکل زیر تنظیم کرده‌اید:

pbx.example.com:5061

ابتدا مطمئن شوید همان Port واقعاً TLS Listener دارد.

از Linux اتصال TCP را تست کنید

nc -vz pbx.example.com 5061

این تست فقط TCP Reachability را ثابت می‌کند؛ موفقیت آن به معنی سالم بودن TLS نیست.

مرحله دوم: Certificate واقعی سرور را ببینید

یکی از مهم‌ترین ابزارها برای این کار OpenSSL است.

openssl s_client \
-connect pbx.example.com:5061 \
-servername pbx.example.com \
-showcerts

در خروجی، Certificate اصلی و Intermediate Certificateهای ارسال‌شده توسط Server را بررسی کنید.

چه قسمت‌هایی از خروجی OpenSSL مهم‌اند؟

به این موارد توجه کنید:

subject=
issuer=
Certificate chain
Verification error
Verify return code

اگر مثلاً ببینید:

Verify return code: 0 (ok)

از دید Trust Store همان سیستم Linux، Chain معتبر بوده است؛ اما هنوز ثابت نمی‌کند Cisco Phone همان Root CA را Trust می‌کند.

چرا مرورگر Certificate را قبول می‌کند ولی Cisco نه؟

Browser یا سیستم‌عامل کامپیوتر Trust Store خودش را دارد.

Cisco MPP نیز Root Certificateهای خودش و در صورت استفاده Custom CAهای Provisionشده را دارد.

بنابراین این نتیجه:

Chrome = trusted

به‌تنهایی به معنی:

Cisco MPP = trusted

نیست.

CA Chain دقیقاً چگونه باید ساخته شود؟

یک Chain معمولی:

Server Certificate
       ↓
Intermediate CA
       ↓
Root CA

در بسیاری از TLS Deploymentها Server باید Certificate خودش و Intermediateهای لازم را ارائه کند و Client از قبل Root CA را Trust داشته باشد.

یکی از خطاهای رایج: Intermediate Certificate نصب نشده

فرض کنید Certificate سرور توسط این Chain صادر شده است:

pbx.example.com
   ↓
Example Intermediate CA R2
   ↓
Example Root CA

اما Server فقط `pbx.example.com` را ارسال می‌کند.

برخی Clientها می‌توانند Intermediate را از Cache یا AIA پیدا کنند، اما نباید برای Cisco Phone به این رفتار تکیه کنید. Chain را روی Server کامل ارائه کنید.

Certificate Chain را با OpenSSL ذخیره و بررسی کنید

openssl s_client \
-connect pbx.example.com:5061 \
-servername pbx.example.com \
-showcerts </dev/null

تاریخ اعتبار Certificate را مستقیم ببینید

برای یک Certificate ذخیره‌شده:

openssl x509 \
-in server.crt \
-noout \
-subject \
-issuer \
-dates

خروجی مهم:

notBefore=...
notAfter=...

Expired و Not Yet Valid را از هم جدا کنید

Certificate فقط بین دو زمان معتبر است:

notBefore ≤ current time ≤ notAfter

اگر زمان Cisco جلوتر از `notAfter` باشد، Certificate منقضی‌شده به نظر می‌رسد.

اگر زمان Phone عقب‌تر از `notBefore` باشد، Certificate هنوز معتبر نشده به نظر می‌رسد.

پس NTP مستقیماً روی TLS اثر می‌گذارد

Cisco MPP زمان خود را معمولاً از NTP می‌گیرد. اگر NTP Server اشتباه، غیرقابل دسترس یا ساعت Device به‌هم‌ریخته باشد، Certificate سالم نیز می‌تواند در زمان Validation نامعتبر تشخیص داده شود.

NTP Server در Cisco MPP کجاست؟

در Web UI:

Voice → System → Optional Network Configuration

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

Primary NTP Server
Secondary NTP Server

Cisco همچنین دریافت NTP از DHCPv4 Option 42 را پشتیبانی می‌کند؛ NTP دستی Primary/Secondary نسبت به DHCP اولویت بالاتری دارد.

نمونه Provisioning NTP

<Primary_NTP_Server ua="rw">ntp1.example.com</Primary_NTP_Server>
<Secondary_NTP_Server ua="rw">ntp2.example.com</Secondary_NTP_Server>

Timezone اشتباه با ساعت UTC اشتباه یکی نیست

فقط اینکه ساعت روی LCD یک ساعت عقب یا جلو نمایش داده می‌شود لزوماً به معنی خراب بودن Validation نیست.

برای Certificate مهم، زمان واقعی سیستم است.

Timezone بیشتر نحوه نمایش Local Time را تعیین می‌کند؛ اما اگر خود Clock یا NTP اشتباه باشد، آن زمان TLS نیز تحت تأثیر قرار می‌گیرد.

مرحله بعد: Hostname Certificate را بررسی کنید

Cisco MPP در SIP over TLS می‌تواند Hostname سروری را که به آن متصل شده با Certificate مقایسه کند.

در:

Voice → Ext(n) → Proxy and Registration

گزینه:

TLS Name Validate = Yes

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

مقدار پیش‌فرض Cisco برای این گزینه Yes است.

TLS Name Validate دقیقاً چه چیزی را مقایسه می‌کند؟

Cisco در MPP برای Hostname Verification اطلاعات Certificate از جمله:

Subject Alternative Name (SAN)
Common Name (CN)

را برای تشخیص هویت Server بررسی می‌کند.

نمونه Hostname صحیح

Proxy:

pbx.example.com

Certificate:

DNS:pbx.example.com

این حالت منطقی است.

نمونه Hostname Mismatch

Phone به:

sip.example.com

وصل می‌شود اما Certificate فقط:

DNS:pbx.example.net

دارد.

در این حالت با TLS Name Validation فعال، اتصال می‌تواند Fail شود.

SANهای Certificate را با OpenSSL ببینید

openssl x509 \
-in server.crt \
-noout \
-ext subjectAltName

اتصال با IP می‌تواند TLS Validation را خراب کند

اگر Certificate برای:

pbx.example.com

صادر شده، بهتر است Cisco نیز با همان FQDN به Server متصل شود.

تبدیل Proxy به:

203.0.113.20

ممکن است DNS را دور بزند اما Hostname Verification را خراب کند.

TLS Name Validate را برای Production خاموش نکنید

برای یک تست بسیار کوتاه ممکن است خاموش‌کردن Validation نشان دهد مشکل از Identity/Certificate Validation است.

اما اگر:

TLS Name Validate = No

تنها راه کارکردن سیستم است، مشکل اصلی هنوز حل نشده است.

Certificate، SAN، CA Chain یا FQDN را اصلاح کنید و Validation را دوباره فعال کنید.

SNI چیست و چرا می‌تواند Certificate اشتباه ایجاد کند؟

SNI یا Server Name Indication بخشی از ClientHello است که به TLS Server می‌گوید Client قصد اتصال به کدام Hostname را دارد.

این قابلیت وقتی چند TLS Virtual Host روی یک IP وجود دارند اهمیت زیادی دارد.

مثلاً:

203.0.113.20
 ├── sip-a.example.com
 ├── sip-b.example.com
 └── sip-c.example.com

Server ممکن است بر اساس SNI تصمیم بگیرد کدام Certificate را ارائه کند.

درباره SNI در Cisco MPP حدس نزنید

در مستند عمومی MPP که برای این مقاله بررسی شده، یک تضمین واحد برای رفتار SNI در همه مدل‌ها و همه Firmwareها ارائه نشده است.

پس اگر TLS Server برای انتخاب Certificate به SNI وابسته است، بهترین روش این است که رفتار خود Device را در ClientHello مشاهده کنید.

SNI را در Wireshark بررسی کنید

ClientHelloها:

tls.handshake.type == 1

برای فیلد SNI:

tls.handshake.extensions_server_name

داخل ClientHello نیز مسیر زیر را باز کنید:

Transport Layer Security → Client Hello → Extension: server_name

با OpenSSL وجود SNI را روی Server مقایسه کنید

با SNI:

openssl s_client \
-connect 203.0.113.20:5061 \
-servername pbx.example.com

و برای مقایسه بدون مشخص‌کردن Server Name:

openssl s_client \
-connect 203.0.113.20:5061

اگر دو تست Certificate متفاوتی برمی‌گردانند، TLS Virtual Hosting یا SNI در Server نقش دارد.

مرحله بعد: TLS Version را بررسی کنید

در مرجع فعلی Cisco MPP پارامتر:

TLS Client Min Version

وجود دارد.

مقدار پیش‌فرض فعلی:

TLS 1.2

نمونه XML

<TLS_Client_Min_Version ua="na">TLS 1.2</TLS_Client_Min_Version>

آیا Cisco 8841 و 8851 را روی TLS 1.3 قرار دهیم؟

فعلاً نباید این موضوع را برای همه MPPها فرض کرد.

مرجع فعلی Cisco صریحاً یادآوری می‌کند که گزینه TLS 1.3 از Release 12.0(7)SR3 برای Cisco IP Conference Phone 7832 و 8832 در دسترس است.

پس برای 8841، 8851 و سایر مدل‌ها Firmware Matrix همان Device را بررسی کنید.

Server با TLS 1.3-only می‌تواند Cisco قدیمی‌تر را قطع کند

اگر Phone فقط TLS 1.2 را Offer کند ولی Server فقط TLS 1.3 قبول کند، Negotiation مشترکی وجود ندارد.

در Capture ممکن است ClientHello ببینید و بلافاصله Alert یا Connection Reset دریافت کنید.

TLS 1.2 سرور را با OpenSSL تست کنید

openssl s_client \
-connect pbx.example.com:5061 \
-servername pbx.example.com \
-tls1_2

اگر این تست Fail می‌شود ولی سرور فقط TLS 1.3 جواب می‌دهد، برای Phoneهایی که TLS 1.3 ندارند Compatibility مشکل خواهد داشت.

Cipher Suite هم می‌تواند Handshake را متوقف کند

دو سمت باید حداقل یک Cipher Suite مشترک داشته باشند.

اگر روی PBX یا Load Balancer Policy بسیار محدود تعریف کرده‌اید، ClientHello Cisco را در PCAP باز کنید و Cipher Suites پیشنهادی را ببینید.

در MPP پارامتر:

TLS Cipher List

نیز وجود دارد، اما Cipherهای ضعیف یا نسخه TLS قدیمی را صرفاً برای رفع موقت خطا فعال نکنید.

Handshake Failure با Unknown CA فرق دارد

TLS Alertها سرنخ بسیار خوبی هستند.

اما همیشه Alert دقیق ارسال نمی‌شود؛ بعضی Serverها فقط TCP Connection را Reset می‌کنند.

Wireshark Filterهای اصلی TLS

تمام TLS:

tls

ClientHello:

tls.handshake.type == 1

ServerHello:

tls.handshake.type == 2

Certificate:

tls.handshake.type == 11

TLS Alert:

tls.alert_message

اگر Wireshark ترافیک را فقط TCP نشان می‌دهد

ممکن است Port غیرمعمول TLS استفاده شده باشد.

روی Stream راست‌کلیک کنید و از:

Decode As → TLS

استفاده کنید.

PCAP سالم چه الگویی دارد؟

Cisco → Server   TCP SYN
Server → Cisco   SYN, ACK
Cisco → Server   ACK

Cisco → Server   TLS ClientHello
Server → Cisco   TLS ServerHello
Server → Cisco   Certificate
...
TLS Handshake Finished

Cisco → Server   SIP REGISTER

سناریوی اول: ClientHello می‌رود ولی هیچ ServerHello نمی‌آید

بررسی کنید:

Port واقعاً TLS است یا نه، Firewall Packet را Drop نکرده، Load Balancer Listener درست است، TLS Version مشترک وجود دارد و Cipher مشترک وجود دارد.

Server Log نیز در این مرحله بسیار مهم است.

سناریوی دوم: ServerHello و Certificate می‌رسد و بعد Cisco اتصال را می‌بندد

در این حالت Certificate Validation یکی از مظنون‌های اصلی است.

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

سناریوی سوم: فقط بعد از تمدید Certificate مشکل شروع شده است

این یکی از قوی‌ترین سرنخ‌هاست.

Certificate قدیمی و جدید را مقایسه کنید:

Issuer عوض شده؟

Intermediate جدید شده؟

SANها تغییر کرده‌اند؟

Key Type یا Signature Algorithm تغییر کرده؟

Full Chain روی Server نصب شده؟

سناریوی چهارم: Certificate جدید در مرورگر درست است ولی Cisco خراب شده

احتمالاً Trust Store کامپیوتر زنجیره جدید را می‌شناسد اما Phone آن را نمی‌شناسد، یا مرورگر Intermediate را Cache کرده است.

Chain را با یک Client تمیز و خود PCAP بررسی کنید.

سناریوی پنجم: فقط بعد از تغییر IP یا Load Balancer مشکل داریم

SNI، Certificate انتخاب‌شده توسط Virtual Host و NAT/LB Listener را بررسی کنید.

ممکن است IP جدید Certificate پیش‌فرض متفاوتی ارائه کند.

سناریوی ششم: با FQDN خراب است ولی با IP وصل می‌شود

این تست را با احتیاط تفسیر کنید.

ممکن است مشکل DNS باشد، اما ممکن است رفتار SNI، Virtual Host یا Certificate Selection نیز تغییر کند.

PCAP هر دو حالت را مقایسه کنید.

سناریوی هفتم: با TLS Name Validate خاموش رجیستر می‌شود

این نتیجه بسیار مهم است.

Credential و مسیر TCP احتمالاً سالم‌اند.

تمرکز را روی:

Hostname، SAN/CN، CA Trust، Chain و Certificate Validation قرار دهید.

سناریوی هشتم: با UDP رجیستر می‌شود ولی TLS نه

در این حالت User ID، Auth ID و Password احتمالاً درست‌اند.

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

UDP:
DNS → SIP REGISTER

TLS:
DNS → TCP → TLS Handshake → SIP REGISTER

مشکل تقریباً در یکی از مراحل اضافه‌شده TLS است.

سناریوی نهم: TLS روی یک Cisco کار می‌کند ولی روی مدل دیگری نه

Firmware Version، Hardware Model، TLS Client Minimum Version، Cipher Support و Root Store را مقایسه کنید.

دو Device با ظاهر مشابه الزاماً TLS Capability کاملاً یکسانی ندارند.

سناریوی دهم: Cisco قدیمی بعد از Hardening سرور از کار افتاده است

اگر اخیراً روی PBX یا SBC:

TLS 1.0/1.1 را حذف کرده‌اید، Cipherها را محدود کرده‌اید، Certificate الگوریتم جدید گرفته یا Server را TLS 1.3-only کرده‌اید، تغییر Security Policy را با ClientHello Phone مقایسه کنید.

سناریوی یازدهم: Webex Calling DNS سالم است ولی Registration انجام نمی‌شود

بعد از DNS SRV، Webex Calling وارد TCP/TLS می‌شود.

در PCAP بررسی کنید آیا:

TCP Connection ساخته می‌شود، ClientHello خارج می‌شود، ServerHello و Certificate می‌آیند و TLS Handshake کامل می‌شود.

اگر Handshake Fail شده، SIP Username را تغییر ندهید.

سناریوی دوازدهم: زمان Phone بعد از هر Reboot اشتباه می‌شود

NTP را اصلاح کنید.

Manual Time راه‌حل پایدار نیست؛ Cisco پس از NTP Synchronization زمان را دوباره جایگزین می‌کند.

DHCP Option 42، Primary/Secondary NTP و دسترسی UDP/123 را بررسی کنید.

Custom CA در Cisco MPP

اگر SIP Server شما Certificate خصوصی دارد، باید Trust Model Phone را بررسی کنید.

در MPPهای پشتیبانی‌شده، وضعیت Custom CA را می‌توان در بخش Status یا Certificate مشاهده کرد.

نمونه وضعیت:

Custom CA Provisioning Status
Custom CA Info
Installed / Not Installed

Private CA را با Self-Signed Server Certificate اشتباه نگیرید

در طراحی بهتر، Server Certificate توسط CA داخلی سازمان صادر می‌شود و Root/Intermediate آن CA به Clientهای مجاز معرفی می‌شود.

استفاده از یک Self-Signed Leaf Certificate بدون Trust Configuration مناسب معمولاً باعث Validation Failure می‌شود.

Certificate واقعی را از PCAP هم می‌توان دید

اگر Server Certificate در TLS Handshake قابل مشاهده باشد، در Wireshark:

Transport Layer Security → Handshake Protocol: Certificate

را باز کنید.

Issuer، Subject، SAN و Chain را با Certificate مورد انتظار مقایسه کنید.

این کار برای Load Balancer بسیار مهم است

ممکن است شما روی PBX Certificate صحیح نصب کرده باشید، ولی TLS در Load Balancer Terminate شود.

Cisco در واقع Certificate Load Balancer را می‌بیند، نه Certificate داخلی PBX.

پس همیشه Certificate‌ای را بررسی کنید که واقعاً روی Wire ارائه می‌شود.

Firewall با TLS Inspection می‌تواند Certificate را عوض کند

در بعضی شبکه‌ها TLS Proxy یا SSL Inspection یک Certificate جدید تولید می‌کند.

در این حالت Cisco ممکن است Issuer داخلی Firewall را Trust نداشته باشد.

PCAP سمت Phone سریعاً نشان می‌دهد Certificate ارائه‌شده متعلق به PBX است یا Security Appliance.

چک‌لیست نهایی TLS Handshake در Cisco MPP

پرسش‌های متداول درباره Cisco TLS Handshake Failed

چرا Cisco MPP روی UDP رجیستر می‌شود ولی روی TLS نه؟

چون TLS قبل از SIP Registration یک لایه اضافی شامل TCP، TLS Negotiation و Certificate Validation دارد. اگر UDP سالم است، Credential احتمالاً درست است و باید TLS Version، CA Chain، Certificate، Hostname و NTP را بررسی کنید.

TLS Name Validate در Cisco MPP چیست؟

گزینه‌ای برای بررسی هویت Hostname در SIP over TLS است. Cisco می‌تواند نام Proxy را با اطلاعات SAN/CN Certificate مقایسه کند و مقدار پیش‌فرض این گزینه Yes است.

آیا خاموش‌کردن TLS Name Validate مشکل را حل می‌کند؟

ممکن است برای تست کوتاه نشان دهد مشکل در Certificate Validation است، اما راه‌حل Production نیست. علت Hostname، SAN، CA یا Chain را اصلاح و Validation را دوباره فعال کنید.

چرا Certificate در مرورگر معتبر است اما Cisco آن را قبول نمی‌کند؟

Browser و Cisco Trust Storeهای متفاوتی دارند. همچنین Browser ممکن است Intermediate Certificate را Cache یا Download کند، در حالی که Phone به Chain ارائه‌شده توسط Server و Rootهای مورد اعتماد خودش وابسته است.

ساعت اشتباه Cisco چطور TLS را خراب می‌کند؟

Certificate فقط بین notBefore و notAfter معتبر است. اگر ساعت Device اشتباه باشد، Certificate می‌تواند Expired یا Not Yet Valid تشخیص داده شود.

SNI چه ارتباطی با Certificate دارد؟

در Serverهایی که چند TLS Virtual Host روی یک IP دارند، SNI می‌تواند تعیین کند Server کدام Certificate را ارائه دهد. رفتار واقعی Cisco و Firmware را باید در ClientHello با Packet Capture بررسی کرد.

چطور SNI را در Wireshark ببینیم؟

ClientHello را باز کنید و Extension server_name را بررسی کنید یا از فیلد tls.handshake.extensions_server_name استفاده کنید.

حداقل TLS Version فعلی Cisco MPP چیست؟

در مرجع فعلی MPP، مقدار پیش‌فرض TLS Client Min Version برابر TLS 1.2 است. پشتیبانی TLS 1.3 به مدل و Firmware وابسته است.

آیا Cisco 8841 و 8851 حتماً TLS 1.3 دارند؟

نباید چنین فرضی کرد. مرجع فعلی Cisco گزینه TLS 1.3 را از Release 12.0(7)SR3 برای مدل‌های کنفرانسی 7832 و 8832 ذکر می‌کند؛ مدل و Firmware دقیق Device را جداگانه بررسی کنید.

Unknown CA در TLS یعنی چه؟

یعنی Certificate Chain ارائه شده است اما Client نتوانسته آن را به یک Trust Anchor یا Root CA مورد اعتماد متصل کند.

Certificate Expired همیشه یعنی Certificate واقعاً منقضی شده است؟

نه لزوماً. ابتدا notAfter و همچنین ساعت واقعی Cisco را بررسی کنید. Clock اشتباه می‌تواند نتیجه Validation را تغییر دهد.

چطور بفهمیم مشکل TLS حل شده است؟

پس از کامل‌شدن Handshake باید SIP REGISTER دیده شود. اگر REGISTER و سپس 401 Challenge ظاهر شدند، TLS عملاً از مرحله اصلی خود عبور کرده و باید SIP Authentication را بررسی کنید.

جمع‌بندی

برای رفع خطای TLS Handshake در Cisco MPP از SIP Password شروع نکنید. ابتدا مشخص کنید TCP Connection ساخته می‌شود یا نه و در PCAP ببینید Handshake تا کدام مرحله جلو می‌رود.

اگر Server Certificate ارائه می‌شود و بعد اتصال بسته می‌شود، CA Chain، Root CA، SAN/CN، Expiry و ساعت Cisco را بررسی کنید. در MPP، TLS Name Validate به‌صورت پیش‌فرض فعال است و Certificate باید با Hostname مورد استفاده برای اتصال سازگار باشد.

اگر ClientHello ارسال می‌شود اما ServerHello ندارید، TLS Version، Cipher، Port و Firewall را بررسی کنید. در مرجع فعلی Cisco حداقل TLS Client Version به‌صورت پیش‌فرض TLS 1.2 است و پشتیبانی TLS 1.3 برای همه مدل‌های 7800/8800 یکسان نیست.

SNI نیز در محیط‌های دارای Load Balancer و چند TLS Virtual Host مهم است. به‌جای فرض‌کردن اینکه Phone SNI را با مقدار موردنظر ارسال می‌کند، ClientHello واقعی Cisco را در Packet Capture باز کنید و Extension server_name را ببینید.

در نهایت، نقطه پایان عیب‌یابی TLS بسیار واضح است: وقتی Handshake کامل شد و اولین SIP REGISTER ظاهر شد، مشکل TLS اصلی پشت سر گذاشته شده است. از آن نقطه به بعد خطاهای 401، 403 یا Registration Policy را به‌عنوان مسئله SIP بررسی کنید.