چرا Cisco MPP و Webex Calling با DNS SRV وصل نمی‌شوند؟ راهنمای رفع مشکل

در چنین شرایطی عوض‌کردن SIP Password، Factory Reset یا بازکردن تصادفی Portها معمولاً شروع مناسبی نیست. ابتدا باید مشخص کنیم Cisco دقیقاً چه Queryای به DNS می‌فرستد، کدام Resolver را استفاده می‌کند، پاسخ SRV شامل چه Target، Priority، Weight و Portی است و آیا تلفن بعد از دریافت SRV می‌تواند A یا AAAA Record مقصد را هم Resolve کند.

در Webex Calling نیز همین تفکیک اهمیت دارد. ممکن است مرحله Provisioning موفق باشد اما Registration شکست بخورد؛ یا برعکس. DNS مربوط به Provisioning و DNS مربوط به SIP Registration الزاماً یک Query یکسان نیستند. در این مقاله این دو مسیر را جدا می‌کنیم و با nslookup، dig و Packet Capture مشخص می‌کنیم مشکل در DHCP، DNS Server، Voice VLAN، SRV Record، TLS یا خود Registration قرار دارد.

DNS SRV چیست و چرا Cisco MPP از آن استفاده می‌کند؟

رکورد SRV برخلاف A Record فقط نمی‌گوید یک Domain به چه IPای اشاره می‌کند. SRV مشخص می‌کند یک سرویس خاص، روی چه Host و Portی در دسترس است و می‌تواند چند Server با Priority و Weight متفاوت معرفی کند.

ساختار عمومی یک SRV Query شبیه این است:

_service._transport.example.com

مثلاً برای SIP روی UDP:

_sip._udp.example.com

برای SIP روی TCP:

_sip._tcp.example.com

و برای SIP امن روی TLS:

_sips._tcp.example.com

SRV Record چه اطلاعاتی برمی‌گرداند؟

نمونه رکورد:

_sips._tcp.example.com. 300 IN SRV 10 60 5061 sip1.example.com.

بخش‌های مهم:

بعد از دریافت این پاسخ، Cisco هنوز کارش تمام نشده است. باید Target یعنی sip1.example.com را نیز با A یا AAAA Record به IP تبدیل کند.

یعنی SRV سالم ولی Registration خراب ممکن است؟

بله.

برای مثال Query SRV موفق است:

_sips._tcp.example.com
  ↓
sip1.example.com:5061

اما:

sip1.example.com
  ↓
NXDOMAIN

در این حالت SRV Record وجود دارد ولی Target آن قابل Resolve نیست و Cisco نمی‌تواند به SIP Server وصل شود.

اول Provisioning و Registration را از هم جدا کنید

در Cisco MPP دو استفاده متفاوت از DNS SRV وجود دارد که نباید با هم اشتباه شوند.

ممکن است Phone Config را به‌درستی دریافت کند اما بعد نتواند SIP Proxy را Resolve کند.

برعکس، ممکن است SIP Domain از قبل روی Device باشد و Registration کار کند ولی Auto Provisioning به‌دلیل DNS خراب اجرا نشود.

DNS SRV مخصوص SIP Registration در Cisco MPP

در Web Interface وارد:

Admin Login → advanced → Voice → Ext(n) → Proxy and Registration

شوید.

دو گزینه مهم:

Use DNS SRV
DNS SRV Auto Prefix

طبق راهنمای فعلی Cisco، هر دو گزینه به‌صورت پیش‌فرض روی No هستند.

Use DNS SRV چه کاری می‌کند؟

اگر:

Use DNS SRV = Yes

باشد، تلفن برای Proxy و Outbound Proxy امکان SRV Lookup را فعال می‌کند.

نمونه XML:

<Use_DNS_SRV_1_ ua="na">Yes</Use_DNS_SRV_1_>

DNS SRV Auto Prefix چه کاری می‌کند؟

اگر Auto Prefix فعال باشد، Cisco بر اساس SIP Transport پیشوند مناسب را خودش اضافه می‌کند.

نمونه XML:

<DNS_SRV_Auto_Prefix_1_ ua="na">Yes</DNS_SRV_Auto_Prefix_1_>

یک مثال واقعی از ساخت Query

فرض کنید Proxy را این‌طور وارد کرده‌اید:

voice.example.com

و:

SIP Transport = TLS
Use DNS SRV = Yes
DNS SRV Auto Prefix = Yes

Cisco باید چیزی شبیه این را Resolve کند:

_sips._tcp.voice.example.com

اگر Auto Prefix خاموش باشد چه؟

در این حالت باید دقیقاً بدانید Provider یا PBX چه نامی را انتظار دارد.

یکی از خطاهای رایج این است که Administrator تصور می‌کند Cisco خودکار `_sips._tcp` را اضافه می‌کند، در حالی که گزینه Auto Prefix خاموش است.

نتیجه:

Expected:
_sips._tcp.voice.example.com

Actual:
voice.example.com

مرحله اول عیب‌یابی: DNS Server خود Phone را ببینید

قبل از اجرای nslookup روی لپ‌تاپ، ابتدا DNS واقعی خود Cisco را ثبت کنید.

روی Phone وارد:

Applications → Network configuration → IPv4 address settings

شوید و این موارد را ببینید:

IP Address
Subnet Mask
Gateway
DNS1
DNS2

چرا تست DNS از لپ‌تاپ ممکن است گمراه‌کننده باشد؟

فرض کنید لپ‌تاپ شما روی Data VLAN است و DNS زیر را دارد:

10.10.10.10

اما Cisco روی Voice VLAN از DHCP این DNS را گرفته است:

10.20.20.10

موفق‌بودن nslookup روی لپ‌تاپ چیزی درباره Resolver تلفن ثابت نمی‌کند.

Voice VLAN DHCP Scope را بررسی کنید

اگر فقط تلفن‌ها مشکل DNS دارند ولی کامپیوترها سالم‌اند، DHCP Scope شبکه Voice را جدا بررسی کنید.

حداقل:

یک تست درست: از همان Voice VLAN Query بزنید

اگر امکان دارید یک لپ‌تاپ آزمایشی را موقتاً روی همان VLAN و همان DNS Resolver تلفن قرار دهید.

در Windows:

nslookup
server 10.20.20.10
set type=SRV
_sips._tcp.voice.example.com

روش کوتاه nslookup

nslookup -type=SRV _sips._tcp.voice.example.com 10.20.20.10

تست با dig در Linux

dig @10.20.20.10 SRV _sips._tcp.voice.example.com

خروجی کوتاه:

dig @10.20.20.10 SRV _sips._tcp.voice.example.com +short

فقط SRV را تست نکنید؛ Target را هم Resolve کنید

فرض کنید خروجی این است:

10 60 5061 sip1.example.com.
20 40 5061 sip2.example.com.

حالا حتماً:

dig @10.20.20.10 A sip1.example.com +short
dig @10.20.20.10 A sip2.example.com +short

را هم اجرا کنید.

اگر IPv6 فعال است AAAA را هم بررسی کنید

dig @10.20.20.10 AAAA sip1.example.com +short

اگر DNS یک AAAA Record برمی‌گرداند اما شبکه Voice شما IPv6 Connectivity واقعی ندارد، Capture را بررسی کنید تا ببینید Phone تلاش ناموفق روی IPv6 انجام می‌دهد یا به IPv4 برمی‌گردد.

Webex Calling چه Queryای می‌سازد؟

در مستند رسمی عیب‌یابی Cisco برای MPP روی Webex Calling، نمونه Outbound Proxy روی Domainی از زیرساخت Webex قرار دارد و Phone برای Registration یک Query از نوع:

_sips._tcp.<outbound-proxy-domain>

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

Cisco در نمونه خودش چیزی شبیه این را نشان می‌دهد:

_sips._tcp.da02.hosted-us10.bcld.webex.com

این فقط نمونه مستند Cisco است. Domain منطقه یا سازمان دیگری را از روی مقاله کپی نکنید؛ همان Outbound Proxy واقعی Provisionشده روی Phone خودتان را بررسی کنید.

تست Webex Calling با nslookup

طبق روش خود Cisco:

nslookup
set type=SRV
_sips._tcp.YOUR_OUTBOUND_PROXY_DOMAIN

بعد از SRV در Webex چه اتفاقی می‌افتد؟

Phone یک یا چند Target از پاسخ SRV انتخاب می‌کند، Hostname آن‌ها را Resolve می‌کند و سپس برای Webex Calling معمولاً اتصال TLS به مقصد ایجاد می‌کند.

ترتیب منطقی:

SRV Query
   ↓
SRV Response
   ↓
A / AAAA Lookup for Target
   ↓
TCP Connection
   ↓
TLS Handshake
   ↓
SIP REGISTER
   ↓
401 Challenge
   ↓
REGISTER + Authorization
   ↓
200 OK

اگر SRV درست است ولی REGISTER نداریم

مشکل DNS ممکن است حل شده باشد و خرابی در مرحله بعد باشد.

باید ببینید:

فرق NXDOMAIN و Timeout چیست؟

این دو نتیجه معنی کاملاً متفاوتی دارند.

NXDOMAIN یعنی Resolver پاسخ داده ولی نام موردنظر وجود ندارد.

Timeout یعنی Client پاسخ مناسب از DNS Server دریافت نکرده است.

نمونه NXDOMAIN:

status: NXDOMAIN

در این حالت نام Query، Zone DNS و Record را بررسی کنید.

اگر Timeout است، مسیر Phone تا Resolver، UDP/TCP 53، ACL و خود DNS Server را بررسی کنید.

SERVFAIL چه چیزی می‌گوید؟

اگر:

SERVFAIL

دریافت می‌کنید، Resolver نام را پیدا کرده یا تلاش کرده Resolve کند اما نتوانسته پاسخ معتبر تولید کند.

در این حالت Forwarder، DNSSEC، Recursive Resolver و Upstream DNS را بررسی کنید.

آیا DNS فقط UDP 53 است؟

خیر.

DNS معمولاً Query اولیه را روی UDP انجام می‌دهد، اما در شرایطی مانند پاسخ بزرگ یا Truncation می‌تواند به TCP 53 نیاز داشته باشد.

اگر Firewall فقط UDP/53 را اجازه داده و TCP/53 را کامل بسته است، بعضی پاسخ‌های DNS می‌توانند مشکل‌ساز شوند.

با Packet Capture دقیقاً چه چیزی را ببینیم؟

Capture را قبل از Reboot یا Registration Retry شروع کنید.

در Wireshark:

dns

را فیلتر کنید.

فقط SRV Queryها

dns.qry.type == 33

Type 33 مربوط به SRV است.

DNS مربوط به IP تلفن

dns && ip.addr == 192.168.20.45

یک Capture سالم چه شکلی است؟

Cisco → DNS
Query SRV _sips._tcp.voice.example.com

DNS → Cisco
Answer:
10 60 5061 sip1.example.com
20 40 5061 sip2.example.com

Cisco → DNS
Query A sip1.example.com

DNS → Cisco
Answer A 203.0.113.20

Cisco → 203.0.113.20
TCP SYN → 5061

اگر Cisco اصلاً SRV Query نمی‌فرستد

قبل از متهم‌کردن DNS Server بررسی کنید:

Use DNS SRV فعال است؟

Auto Prefix مطابق طراحی فعال است؟

Proxy واقعاً Domain است یا IP؟

SIP Transport چیست؟

Configuration جدید Apply شده؟

Phone بعد از Provisioning مقادیر را Override نکرده؟

Provisioning می‌تواند تنظیم دستی شما را برگرداند

ممکن است روی Web UI این مقدار را دستی فعال کنید:

Use DNS SRV = Yes

اما بعد از Resync یا Reboot، Provisioning Server مقدار را دوباره روی No بگذارد.

اگر تنظیمات بعد از چند دقیقه برمی‌گردند، فایل Config و Profile Rule را بررسی کنید.

نمونه Config برای SIP SRV

<Proxy_1_ ua="na">voice.example.com</Proxy_1_>
<SIP_Transport_1_ ua="na">TLS</SIP_Transport_1_>
<Use_DNS_SRV_1_ ua="na">Yes</Use_DNS_SRV_1_>
<DNS_SRV_Auto_Prefix_1_ ua="na">Yes</DNS_SRV_Auto_Prefix_1_>

Priority در SRV چه معنی دارد؟

Priority مشخص می‌کند کدام گروه Server اولویت بالاتری دارد. عدد کمتر Priority بالاتری دارد.

مثلاً:

10 60 5061 sip1.example.com
20 60 5061 sip2.example.com

Server با Priority 10 قبل از گروه Priority 20 انتخاب می‌شود؛ Server دوم بیشتر نقش Backup دارد.

Weight چه کاربردی دارد؟

وقتی چند Target Priority یکسان دارند، Weight برای توزیع انتخاب میان آن‌ها استفاده می‌شود.

مثلاً:

10 70 5061 sip1.example.com
10 30 5061 sip2.example.com

هر دو در یک Priority هستند اما Weight برای انتخاب نسبی آن‌ها استفاده می‌شود.

چرا فقط بعضی تلفن‌ها رجیستر نمی‌شوند؟

اگر چند Target در یک SRV وجود دارد و فقط یکی از آن‌ها خراب است، بعضی Phoneها ممکن است به Target سالم برسند و بعضی به Target مشکل‌دار.

تمام Targetها را جداگانه تست کنید:

dig A sip1.example.com +short
dig A sip2.example.com +short
dig A sip3.example.com +short

Port داخل SRV را نادیده نگیرید

یکی از مزیت‌های SRV این است که Port را نیز مشخص می‌کند.

مثلاً ممکن است:

_sips._tcp.example.com
→ sip1.example.com:8934

باشد.

اگر Firewall فقط 5061 را Allow کرده باشد، DNS کاملاً سالم است اما Registration شکست می‌خورد.

Webex Calling را با Port ثابت 5061 فرض نکنید

در محیط Webex Calling، مقصد و Port را از Configuration و SRV واقعی خود Device استخراج کنید.

نمونه Cisco در Log رسمی خودش حتی Registration TLS روی Port دیگری را نشان می‌دهد. بنابراین Rule شبکه را بر اساس داده واقعی Organization و مستند Port Reference مربوط به Webex طراحی کنید.

Proxy Fallback در Cisco MPP چگونه به SRV مرتبط است؟

Cisco می‌تواند فهرست Proxyهای برگشتی از DNS SRV را نگه دارد و اگر Server اول در دسترس نباشد به Target با اولویت بعدی Failover کند.

پارامتر مهم:

Proxy Fallback Intvl

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

3600 seconds

Fallback با Failover چه تفاوتی دارد؟

Failover یعنی Phone از Primary به Proxy جایگزین می‌رود.

Fallback یعنی بعداً دوباره تلاش می‌کند به Primary با Priority بالاتر برگردد.

اگر SRV فقط یک Target داشته باشد، عملاً چیزی برای Failover وجود ندارد.

Proxy Redundancy Method چیست؟

Cisco MPP برای Targetهای SRV پارامتر:

Proxy Redundancy Method

را دارد.

مقدار معمول:

Normal

است و Cisco فهرست داخلی Proxyها را بر اساس اطلاعات SRV می‌سازد.

Dual Registration را بی‌دلیل با DNS SRV ترکیب نکنید

Dual Registration و DNS SRV Failover دو مکانیزم Redundancy متفاوت‌اند.

اگر هدف شما Failover استاندارد بر اساس SRV است، قبل از فعال‌کردن Dual Registration بررسی کنید که معماری Provider چه چیزی را پشتیبانی می‌کند.

ترکیب چند مکانیزم Failover بدون طراحی می‌تواند رفتار Registration را پیچیده و غیرقابل پیش‌بینی کند.

DNS Cache و TTL هم مهم‌اند

اگر SRV Record را همین الان تغییر داده‌اید، Phone، Resolver یا Recursive DNS ممکن است پاسخ قبلی را تا پایان TTL نگه دارد.

برای مثال:

TTL = 3600

یعنی Cache می‌تواند تا یک ساعت پاسخ قدیمی را نگه دارد.

با dig TTL را ببینید

dig SRV _sips._tcp.voice.example.com

در Answer Section مقدار TTL را ثبت کنید.

اگر DNS عمومی جواب می‌دهد ولی DNS سازمانی نه

مثلاً:

dig @8.8.8.8 SRV _sips._tcp.voice.example.com
# works

dig @10.20.20.10 SRV _sips._tcp.voice.example.com
# fails

مشکل Cisco نیست؛ DNS Resolver سازمانی، Forwarder یا Policy آن را بررسی کنید.

Split DNS می‌تواند نتیجه متفاوت بسازد

در بعضی شبکه‌ها Domain داخل سازمان پاسخ متفاوتی از اینترنت دارد.

مثلاً:

اگر Cisco روی Voice VLAN به Resolver اشتباه اشاره کند ممکن است Target نامناسب دریافت کند.

DNS Search Domain را با SRV Domain اشتباه نگیرید

Search Domain بیشتر برای تکمیل نام‌های ناقص کاربرد دارد.

اما برای SRV بهتر است Query کامل FQDN را دقیق بررسی کنید.

در Packet Capture نام واقعی Query ارسال‌شده توسط Phone را ببینید و حدس نزنید.

DNS SRV برای HTTP Provisioning در Cisco MPP

Cisco علاوه بر SIP Registration، برای Provisioning هم DNS SRV دارد.

در این مکانیزم Query از Domain ارائه‌شده توسط DHCP ساخته می‌شود.

ساختار:

_<servicename>._<transport>.<domainName>

نمونه Cisco برای Provisioning امن

_ciscoprov-https._tls.example.com

ترتیب Auto Provisioning در راهنمای فعلی Cisco

Cisco در مستند فعلی این ترتیب را برای مکانیزم‌های Auto Provisioning ذکر می‌کند:

Provisioning SRV و Certificate

در DNS SRV Provisioning روی HTTPS، Cisco Hostname Validation را بر اساس Domain ارائه‌شده از DHCP انجام می‌دهد.

بنابراین SRV ممکن است از نظر DNS کاملاً درست باشد اما HTTPS Provisioning به‌دلیل Certificate Name Validation شکست بخورد.

این دو را جدا کنید:

DNS SRV = successful
HTTPS/TLS validation = failed

Profile Rule با SRV در Cisco

برای HTTP/HTTPS Provisioning می‌توان در Profile Rule از SRV Option استفاده کرد.

نمونه:

[--srv] https://example.com/$PSN.xml

در مستند فعلی Cisco این مکانیزم برای HTTP و HTTPS تعریف شده است؛ DNS SRV Provisioning با TFTP پشتیبانی نمی‌شود.

اگر Provisioning کار نمی‌کند ولی Registration سالم است

Queryهای `_ciscoprov-*` را بررسی کنید؛ نه فقط `_sip` یا `_sips`.

این اشتباه رایج است که Administrator فقط SRV مربوط به SIP را تست می‌کند در حالی که مشکل در Discovery سرور Provisioning است.

اگر Registration خراب است ولی Provisioning سالم است

برعکس، دریافت Config ثابت نمی‌کند `_sips._tcp` یا `_sip._udp` سالم است.

SRV مربوط به Outbound Proxy را جدا تست کنید.

DNS Server دوم را فراموش نکنید

Cisco MPP می‌تواند DNS1 و DNS2 داشته باشد.

اگر DNS1 گاهی Timeout دارد ولی DNS2 سالم است، Registration ممکن است با تأخیر یا رفتار ناپایدار همراه شود.

هر دو Resolver را جداگانه تست کنید:

dig @10.20.20.10 SRV _sips._tcp.voice.example.com
dig @10.20.20.11 SRV _sips._tcp.voice.example.com

Packet Capture روی Cisco چه چیزی را ثابت می‌کند؟

اگر PCAP خود Phone نشان دهد Query از Cisco خارج شده ولی Response برنمی‌گردد، مشکل در خود تنظیم SRV روی Phone نیست.

مسیر را به:

Voice VLAN، ACL، Gateway، Firewall، DNS Server یا مسیر برگشت محدود کنید.

اگر Response وارد Phone می‌شود ولی Phone Query بعدی A/AAAA را نمی‌فرستد، Logهای Device و ساختار SRV را بررسی کنید.

یک روش عیب‌یابی بدون حدس

سناریوی اول: Cisco با IP رجیستر می‌شود ولی با Domain نه

DNS را در اولویت قرار دهید.

اول A Record و بعد SRV را مطابق Configuration واقعی بررسی کنید.

اگر TLS استفاده می‌شود، توجه کنید جایگزین‌کردن Domain با IP ممکن است Certificate Validation را تغییر دهد؛ بنابراین IP مستقیم فقط یک تست تشخیصی است، نه لزوماً راه‌حل Production.

سناریوی دوم: A Record کار می‌کند ولی SRV نه

ممکن است DNS Server شما A Record را Resolve کند اما Zone یا Forwarder موردنیاز برای SRV درست نباشد.

این دو Query را کنار هم اجرا کنید:

dig A voice.example.com
dig SRV _sips._tcp.voice.example.com

سناریوی سوم: nslookup روی PC سالم است ولی Cisco رجیستر نمی‌شود

DNS Server واقعی Phone را با PC مقایسه کنید.

اگر Resolverها متفاوت‌اند، تست PC معیار مناسبی نیست.

همچنین Packet Capture Cisco را بگیرید تا Query واقعی Phone مشخص شود.

سناریوی چهارم: فقط Voice VLAN مشکل دارد

DHCP Scope، DNS Option، ACL بین VLAN و Resolver و Route برگشت DNS Server را بررسی کنید.

اگر Data VLAN سالم است اما Voice VLAN نیست، Public DNS را روی Phone واردکردن فقط صورت‌مسئله را پنهان می‌کند؛ بهتر است DHCP/DNS شبکه Voice اصلاح شود.

سناریوی پنجم: Webex Calling بعد از تغییر DNS رجیستر نمی‌شود

Query SRV مربوط به Outbound Proxy واقعی Device را روی Resolver جدید تست کنید.

بعد Targetهای برگشتی را Resolve و Port واقعی را بررسی کنید.

در مرحله بعد TLS Handshake را در PCAP ببینید.

سناریوی ششم: Webex فقط روی یک اینترنت کار می‌کند

Resolverهای دو اینترنت را مقایسه کنید.

همچنین بررسی کنید ISP یا Router دوم UDP/TCP 53، Port مقصد SIP/TLS یا مسیر IPv6 را مسدود نکرده باشد.

SRV Query سالم ولی TLS Fail یعنی دیگر نباید DNS را مقصر بدانید.

سناریوی هفتم: بعضی روزها Cisco روی Backup Proxy رجیستر می‌شود

Priority، Weight، وضعیت تمام Targetها و Proxy Fallback را بررسی کنید.

ممکن است Primary گهگاه DNS دارد ولی Port آن از شبکه Phone قابل دسترس نیست.

سناریوی هشتم: SRV را تغییر داده‌اید ولی Phone هنوز مقصد قدیمی را می‌گیرد

TTL و Cache را بررسی کنید.

Resolver سازمانی، Phone و بعضی DNS Forwarderها ممکن است تا پایان TTL پاسخ قبلی را نگه دارند.

سناریوی نهم: DNS پاسخ چند Target می‌دهد ولی یکی Certificate خراب دارد

در این حالت Registration ممکن است گاهی سالم و گاهی خراب باشد.

Certificate تمام Targetهای SRV را جداگانه بررسی کنید.

برای TLS:

openssl s_client \
-connect sip1.example.com:5061 \
-servername sip1.example.com

سناریوی دهم: DNS سالم است ولی Cisco می‌گوید Not Registered

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

بعد از Query موفق باید این مراحل را ببینید:

TCP/TLS Connection، REGISTER، 401 Challenge، REGISTER همراه Authorization و در نهایت 200 OK.

چک‌لیست نهایی Cisco MPP DNS SRV

پرسش‌های متداول درباره Cisco MPP DNS SRV

DNS SRV در Cisco MPP برای چه کاری استفاده می‌شود؟

برای پیدا کردن Proxy یا Outbound Proxy بر اساس سرویس، Transport، Priority، Weight، Port و Target. Cisco همچنین در Provisioning از DNS SRV برای پیدا کردن سرور HTTP/HTTPS استفاده می‌کند.

Use DNS SRV در Cisco به‌صورت پیش‌فرض فعال است؟

خیر. در راهنمای فعلی Cisco MPP مقدار پیش‌فرض Use DNS SRV برابر No است و در صورت نیاز باید مطابق طراحی فعال شود.

DNS SRV Auto Prefix چه کاری انجام می‌دهد؟

بر اساس SIP Transport پیشوند مناسب را اضافه می‌کند؛ برای UDP از _sip._udp، برای TCP از _sip._tcp و برای TLS از _sips._tcp استفاده می‌شود.

چطور SRV مربوط به Webex Calling را تست کنیم؟

Outbound Proxy واقعی Device را پیدا کنید و با nslookup یا dig Query نوع SRV برای _sips._tcp همان Domain را بررسی کنید. Domain نمونه Cisco را برای Organization خودتان کپی نکنید.

چرا nslookup روی کامپیوتر کار می‌کند ولی Cisco نه؟

ممکن است PC و Phone DNS Resolver متفاوتی داشته باشند یا در VLANهای مختلف باشند. DNS1 و DNS2 خود Phone و DHCP Scope شبکه Voice را بررسی کنید.

اگر SRV پاسخ دارد ولی Cisco رجیستر نمی‌شود چه؟

Targetهای SRV را با A/AAAA Resolve کنید و سپس TCP/TLS، Port مقصد و در نهایت SIP REGISTER را بررسی کنید.

فرق NXDOMAIN و DNS Timeout چیست؟

NXDOMAIN یعنی Resolver پاسخ داده اما نام وجود ندارد؛ Timeout یعنی پاسخ مناسبی از DNS Server دریافت نشده و مشکل شبکه یا Resolver محتمل‌تر است.

Priority در SRV چه کاری می‌کند؟

عدد Priority کمتر، گروه با اولویت بالاتر را مشخص می‌کند. Serverهای Priority پایین‌تر معمولاً برای Failover استفاده می‌شوند.

Weight در SRV چه کاربردی دارد؟

بین Targetهایی که Priority یکسان دارند برای توزیع انتخاب استفاده می‌شود.

چرا بعضی Ciscoها رجیستر می‌شوند و بعضی نه؟

اگر SRV چند Target داشته باشد ممکن است یکی از Targetها از نظر DNS، Firewall، TLS یا SIP خراب باشد. تمام Targetها را جداگانه تست کنید.

DNS SRV Provisioning با SIP SRV یکی است؟

خیر. Provisioning می‌تواند Queryهایی مانند _ciscoprov-https._tls داشته باشد؛ Registration معمولاً بر اساس _sip یا _sips انجام می‌شود.

آیا Cisco MPP برای DNS SRV Provisioning از TFTP پشتیبانی می‌کند؟

در مستند فعلی Cisco، SRV Provisioning برای HTTP و HTTPS تعریف شده و TFTP در SRV Lookup پشتیبانی نمی‌شود.

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

در Packet Capture ترتیب مراحل را ببینید. اگر SRV و A/AAAA پاسخ موفق دارند و TCP Connection ایجاد می‌شود اما TLS Handshake Fail می‌شود، مشکل دیگر DNS نیست.

جمع‌بندی

برای رفع مشکل DNS SRV در Cisco MPP ابتدا مشخص کنید مشکل مربوط به Provisioning است یا SIP Registration. این دو مرحله Queryهای متفاوتی دارند و سالم‌بودن یکی، دیگری را تأیید نمی‌کند.

در Registration، گزینه‌های Use DNS SRV و DNS SRV Auto Prefix را بررسی کنید. Cisco برای UDP از _sip._udp، برای TCP از _sip._tcp و برای TLS از _sips._tcp استفاده می‌کند. سپس با Resolver واقعی خود Phone همان Query را با nslookup یا dig اجرا کنید.

SRV Response فقط نیمی از مسیر است. تمام Targetهای برگشتی باید با A یا AAAA به IP تبدیل شوند و Port اعلام‌شده در SRV نیز از شبکه Voice قابل دسترس باشد. Priority، Weight و Fallback را نیز بررسی کنید؛ مخصوصاً وقتی چند Proxy برای افزونگی وجود دارد.

در Webex Calling، Query واقعی Outbound Proxy را از تنظیمات یا Log خود Device استخراج کنید. مستند Cisco نشان می‌دهد Phone برای Registration روی Webex از SRV امن مانند _sips._tcp استفاده می‌کند و بعد از Resolve شدن Targetها TLS و SIP REGISTER را ادامه می‌دهد.

در نهایت Packet Capture تعیین‌کننده است. اگر DNS Query اصلاً ارسال نمی‌شود، Configuration تلفن را بررسی کنید. اگر Query ارسال می‌شود ولی پاسخ برنمی‌گردد، شبکه و Resolver را بررسی کنید. اگر DNS کامل است ولی TLS یا REGISTER Fail می‌شود، عیب‌یابی را به مرحله بعد منتقل کنید و DNS را بی‌دلیل تغییر ندهید.