Amir Jabbari
اگر می‌خواهید عیب‌یابی Cisco IP Phone را از حالت «حدس‌زدن» خارج کنید، Packet Capture بهترین نقطه شروع است. یک Capture درست به شما نشان می‌دهد تلفن IP گرفته یا نه، DNS چه نامی را Resolve کرده، TLS Handshake کامل شده یا نه، REGISTER کجا رد شده، INVITE به چه مقصدی رفته، داخل SDP چه Codec و IP/Portی پیشنهاد شده و RTP واقعاً در کدام جهت جریان دارد.
DHCP
↓
DNS
↓
TLS
↓
REGISTER
↓
INVITE
↓
SDP
↓
RTP / RTCPاگر SIP شما روی UDP یا TCP بدون TLS است، مرحله TLS را ندارید؛ اما بقیه روش همان است. نکته اصلی این است که همیشه Capture را از پایین‌ترین لایه شروع کنید و فقط وقتی یک مرحله سالم بود به مرحله بعد بروید.
قانون طلایی: اگر DHCP خراب است، دنبال SIP Error نگردید. اگر DNS خراب است، REGISTER را تحلیل نکنید. اگر REGISTER هنوز کامل نشده، مشکل RTP را بررسی نکنید. هر مرحله باید قبل از مرحله بعدی تأیید شود.
Packet Capture در Cisco IP Phone دقیقاً چه چیزی به ما می‌دهد؟
Packet Capture یا PCAP کپی Packetهایی است که از Interface شبکه رد می‌شوند. وقتی Capture را از خود Cisco MPP بگیرید، دقیقاً می‌بینید Phone چه چیزی فرستاده و چه چیزی دریافت کرده است.
Cisco در مستند رسمی MPP توضیح می‌دهد که PCAP برای تحلیل مشکلات Provisioning، Registration و Network Troubleshooting استفاده می‌شود و فایل خروجی را می‌توان در Wireshark باز کرد. در راهنمای فعلی MPP نیز مسیر Info → Debug Info → Start Packet Capture برای گرفتن Capture از خود Phone مستند شده است.
دو محل اصلی برای گرفتن Capture
۱. از خود Phone: بهترین گزینه برای دیدن چیزی است که Endpoint واقعاً ارسال و دریافت کرده است.
۲. از Switch/PBX/SBC: برای مقایسه دو سمت مسیر مفید است؛ مخصوصاً وقتی NAT، VPN، Firewall یا SBC چیزی را تغییر می‌دهد.
برای یک عیب‌یابی حرفه‌ای، اگر امکان دارید دو Capture هم‌زمان بگیرید: یکی نزدیک Phone و دیگری نزدیک PBX یا SBC.
روش گرفتن PCAP از Cisco MPP
در مدل‌های MPP پشتیبانی‌شده، ابتدا IP تلفن را پیدا کنید. اگر IP را نمی‌دانید، Cisco مسیر Status شبکه را پیشنهاد می‌کند. سپس وارد Web Interface شوید.
مسیر معمول:
https://PHONE-IP/Admin
→ Login as Admin
→ Info
→ Debug Info
→ Start Packet Capture
→ Reproduce the problem
→ Stop Packet Capture
→ Download PCAPدر بعضی Firmwareها مسیر یا ظاهر UI کمی فرق می‌کند، اما منطق همان است. Cisco همچنین امکان Capture همه Packetها یا محدودکردن Capture به Host IP را مستند کرده است.
قبل از شروع Capture: زمان دقیق تست، شماره مبدا و مقصد، نوع تماس و مشکل مشاهده‌شده را یادداشت کنید. اگر چند تماس پشت‌سرهم انجام دهید بدون اینکه Timestamp و شماره‌ها را ثبت کنید، پیدا کردن Call درست در PCAP سخت می‌شود.
مرحله ۱: DHCP؛ Phone واقعاً Network Configuration گرفته است؟
اولین مرحله استاندارد، DHCP است. اگر Phone IP، Gateway، DNS یا Option اشتباه گرفته باشد، همه مراحل بعدی ممکن است ظاهراً شبیه مشکل SIP دیده شوند.
در Capture دنبال DHCP DORA بگردید:
DHCP Discover
DHCP Offer
DHCP Request
DHCP ACKفیلتر Wireshark:
dhcp || bootpدر DHCP ACK چه چیزهایی را بررسی کنیم؟
🔹 IP Address خود Phone.
🔹 Subnet Mask.
🔹 Default Gateway.
🔹 DNS Server.
🔹 Domain Name.
🔹 DHCP Optionهای Provisioning یا TFTP در صورت استفاده.
Cisco در راهنماهای MPP تأکید می‌کند که IP، Subnet، Router و DNS باید در مرحله Network Setup بررسی شوند. در Provisioning جدید نیز Phone می‌تواند از DHCP، DNS SRV، EDOS و Activation برای یافتن Provisioning استفاده کند.
خطاهای رایج در همین مرحله
اگر Discover می‌بینید ولی Offer ندارید، مشکل DHCP Server، VLAN یا Relay است. اگر ACK می‌آید اما Gateway/DNS اشتباه است، Phone IP دارد ولی مراحل بعدی Fail خواهند شد. اگر Option قدیمی TFTP یا Provisioning در DHCP مانده باشد، Phone ممکن است به Server اشتباه برود.
مرحله ۲: DNS؛ Phone دقیقاً چه نامی را Resolve می‌کند؟
بعد از اینکه DHCP سالم بود، به DNS بروید. این مرحله را با یک `ping` به IP جایگزین نکنید؛ SIP و Provisioning معمولاً با FQDN، SRV یا CNAME کار می‌کنند.
فیلتر Wireshark:
dnsدر هر Query سه چیز را ببینید:
🔹 Name Query چیست؟
🔹 Query Type چیست: A، AAAA یا SRV؟
🔹 Response چه IP/Targetی برمی‌گرداند؟
در Webex Calling، Cisco برای Registration نمونه Queryهای SRV مانند `_sips._tcp…` را در راهنمای عیب‌یابی نشان می‌دهد. در Provisioning عمومی MPP نیز DNS SRV با الگوهایی مانند `_ciscoprov-https._tls.example.com` پشتیبانی می‌شود.
فیلتر یک نام مشخص
dns.qry.name contains "example.com"چه چیزی خرابی DNS را ثابت می‌کند؟
Query از Phone خارج می‌شود اما Response نمی‌آید؛ یا Response با `NXDOMAIN` برمی‌گردد؛ یا Targetی Resolve می‌شود که با Design شما هم‌خوانی ندارد. اگر PC روی همان شبکه Resolve می‌کند ولی Phone نه، DNS دریافتی Phone، Voice VLAN و ACL را مقایسه کنید.
مرحله ۳: TLS؛ اتصال امن قبل از REGISTER کامل می‌شود؟
اگر SIP Transport روی TLS است، بعد از DNS باید TLS Handshake را ببینید. Cisco در راهنمای Webex Calling پیشنهاد می‌کند Packet Capture را برای بررسی TLS Handshake Registration تحلیل کنید.
فیلتر Wireshark:
tlsدر یک Handshake سالم معمولاً ClientHello، ServerHello و ادامه Negotiation را می‌بینید. اگر TLS Alert وجود داشته باشد، Wireshark می‌تواند آن را به‌صورت Alert Message نشان دهد.
فیلتر Alert:
tls.alert_messageTLS Fail شد؛ کجا را ببینیم؟
🔹 Server IP همان چیزی است که DNS برگردانده؟
🔹 TCP Connection قبل از TLS ایجاد شده؟
🔹 Certificate معتبر و قابل اعتماد است؟
🔹 Hostname با SAN/CN Certificate هم‌خوانی دارد؟
🔹 ساعت Phone صحیح است؟
🔹 Cipher/TLS Version مشترک وجود دارد؟
اگر SIP روی UDP یا TCP بدون TLS است، این مرحله را رد کنید و مستقیم به REGISTER بروید.
نکته مهم درباره SIP over TLS: وقتی SIP داخل TLS رمز شده است، در PCAP خام ممکن است به‌جای REGISTER و INVITE فقط TLS Application Data ببینید. برای تحلیل جزئی SIP در Production، TLS را صرفاً برای Troubleshooting خاموش نکنید. از PRT/Syslog، Capture سمت PBX/SBC بعد از Termination TLS یا ابزارهای Logging امن استفاده کنید.
مرحله ۴: REGISTER؛ Phone واقعاً رجیستر شده است؟
REGISTER محل ثبت آدرس فعلی Phone نزد Registrar است. RFC 3261 همین Binding بین SIP URI و Contact فعلی Endpoint را تعریف می‌کند.
اگر SIP قابل مشاهده است، فیلتر:
sip.Method == "REGISTER"یک Flow عادی Digest Authentication معمولاً چیزی شبیه این است:
Phone Registrar
| REGISTER |
|------------>|
| 401 |
|<------------| | REGISTER + Authorization |------------>|
| 200 OK |
|<------------|دیدن 401 در این Flow الزاماً خطا نیست؛ اغلب Challenge طبیعی Digest Authentication است. مهم این است که REGISTER دوم Authorization داشته باشد و در نهایت 200 OK دریافت شود.
در REGISTER چه Headerهایی را ببینیم؟
🔹 Request-URI و Registrar Domain.
🔹 From و To.
🔹 Contact؛ IP و Portی که Phone اعلام کرده.
🔹 Authorization بعد از Challenge.
🔹 Expires.
🔹 Via و received/rport در سناریوی NAT.
فیلتر پاسخ‌های SIP
sip.Status-Code >= 300اگر 403، 404، 408، 503 یا کد دیگری می‌بینید، Source IP پاسخ را ثبت کنید. همین IP مشخص می‌کند Failure از PBX، SBC یا Provider آمده است.
مرحله ۵: INVITE؛ تماس کجا و چگونه شروع می‌شود؟
بعد از Registration سالم، یک تماس آزمایشی برقرار کنید. SIP INVITE برای ایجاد Session استفاده می‌شود و معمولاً SDP نیز داخل همان INVITE یا یکی از Responseها قرار می‌گیرد.
فیلتر:
sip.Method == "INVITE"Flow سالم پایه:
INVITE
100 Trying
180 Ringing
200 OK
ACK
RTP
...
BYE
200 OKاین Flow ممکن است با 183 Session Progress، PRACK یا Re-INVITE پیچیده‌تر شود، اما برای شروع همین زنجیره کافی است.
در INVITE چه چیزهایی را بخوانیم؟
🔹 Request-URI؛ شماره/مقصد واقعی.
🔹 From/To.
🔹 Call-ID؛ شناسه‌ای که تمام پیام‌های همان Call را به هم وصل می‌کند.
🔹 Contact.
🔹 Route/Record-Route در صورت وجود.
🔹 Content-Type و وجود SDP.
Call-ID را یادداشت کنید. اگر Trace شلوغ است، با همان Call-ID فقط همان تماس را ببینید.
sip.Call-ID == "CALL-ID-FROM-TRACE"مرحله ۶: SDP؛ IP، Port و Codec واقعی را پیدا کنید
SDP جایی است که دو Endpoint درباره Media صحبت می‌کنند. RFC 8866 ساختار SDP را تعریف می‌کند و در SIP، Offer/Answer برای توافق درباره Media استفاده می‌شود.
نمونه ساده SDP:
c=IN IP4 192.0.2.25
m=audio 16420 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000چه چیزی را از SDP استخراج کنیم؟
`c=` آدرس Media را نشان می‌دهد.
`m=audio` Port و نوع Transport و Payload Typeها را مشخص می‌کند.
`a=rtpmap` Codec یا Payload را به شماره Payload Type وصل می‌کند.
اگر SRTP باشد، Transport Profile می‌تواند Secure باشد؛ RFC 8866 برای مثال `RTP/SAVP` را به‌عنوان Secure RTP Profile معرفی می‌کند.
SDP و One-Way Audio
اگر Phone در SDP یک IP خصوصی اعلام می‌کند ولی PBX/Provider باید به IP دیگری Media بفرستد، NAT/SBC باید این موضوع را مدیریت کند. برای One-Way Audio حتماً IP و Port موجود در Offer و Answer را با RTP واقعی مقایسه کنید.
اگر 488 دریافت می‌کنید، SDP اولین محل بررسی است: Codec مشترک وجود دارد؟ RTP/SRTP هماهنگ است؟ DTMF Payload سازگار است؟
مرحله ۷: RTP؛ آیا صدا واقعاً در هر دو جهت حرکت می‌کند؟
RTP مرحله نهایی تماس است. RFC 3550 برای RTP Sequence Number، Timestamp، Payload Type و SSRC تعریف می‌کند و Wireshark می‌تواند این Streamها را تحلیل کند.
اگر Wireshark RTP را تشخیص داده باشد، فیلتر:
rtpو برای RTCP:
rtcpدر RTP چه چیزی مهم است؟
🔹 Source IP و Destination IP.
🔹 Source Port و Destination Port.
🔹 Payload Type.
🔹 Sequence Number.
🔹 Timestamp.
🔹 SSRC.
🔹 Packet Loss / Sequence Gap.
🔹 Jitter.
در Wireshark از مسیر Telephony → RTP → RTP Streams می‌توانید Streamها را جدا کنید و Analyze را اجرا کنید.
One-Way Audio را با RTP ثابت کنید
اگر فقط یک Stream وجود دارد، یا یک جهت Packet دارد و جهت دیگر صفر است، One-Way Audio در Capture اثبات شده است. حالا باید ببینید RTP در کدام نقطه گم شده: Phone، Firewall/NAT، VPN، SBC یا PBX.
اگر دو سمت Capture دارید، مقایسه بسیار ساده می‌شود:
Phone Capture:
RTP Phone → PBX = YES
RTP PBX → Phone = NO
PBX Capture:
RTP Phone → PBX = YES
RTP PBX → Phone = YES
Conclusion:
Return RTP is lost between PBX and PhoneCall Statistics خود MPP را هم فعال کنید
Cisco MPP قابلیت ارسال Call Statistics در SIP BYE و Re-INVITE را دارد. این Statistics می‌تواند Packet Received، Lost Packet و Late Packet را گزارش کند و برای زمانی که Capture کامل ندارید بسیار مفید است.
در Web UI:
Voice
→ SIP
→ RTP Parameters
→ Call Statistics: Yesدر XML:
<Call_Statistics ua="na">Yes</Call_Statistics>روش استاندارد تشخیص؛ از اولین Packet تا آخرین RTP
| مرحله | نشانه سالم | اگر خراب بود |
|---|---|---|
| DHCP | Offer/ACK با IP، Gateway و DNS درست | VLAN، DHCP Relay، Scope و Optionها |
| DNS | A/AAAA/SRV پاسخ صحیح | DNS Server، ACL، Record و Domain |
| TLS | Handshake بدون Alert | Certificate، Hostname، Time، Cipher، Firewall |
| REGISTER | Challenge/Authorization و 200 OK | Credential، Domain، Registrar، Provider Policy |
| INVITE | 100/180/200/ACK | Dial Plan، Route، SIP Error و Call-ID |
| SDP | Codec و IP/Port سازگار در Offer/Answer | Codec، NAT، SRTP/RTP، DTMF |
| RTP | دو Stream سالم با Loss/Jitter قابل قبول | NAT، Firewall، VPN، QoS و Media Route |
یک Capture خوب چه مشخصاتی دارد؟
Capture باید کمی قبل از شروع مشکل آغاز شود. اگر فقط لحظه بعد از Error را Capture کنید، ممکن است DHCP، DNS، REGISTER یا اولین INVITE را از دست داده باشید.
برای Registration Problem، بهتر است Capture از Reboot یا Resync شروع شود.
برای Call Problem، ابتدا Capture را Start کنید، سپس فقط یک تماس مشخص انجام دهید و بعد Capture را Stop کنید.
نام فایل را هم معنادار نگه دارید:
cisco-8851-ext201-outbound-fail-20261018-1030.pcapقبل از ارسال PCAP برای دیگران، اطلاعات حساس را بشناسید
PCAP می‌تواند IP Address، SIP URI، شماره تماس، Domain، Headerها، SDP و در حالت SIP غیررمزشده اطلاعات قابل‌خواندن زیادی داشته باشد. فایل Capture را عمومی منتشر نکنید.
اگر Capture باید برای Vendor یا Support ارسال شود، فقط بازه لازم را نگه دارید و اطلاعات حساس را طبق Policy سازمان مدیریت کنید. در SIP Digest، Password معمولاً به‌صورت Plaintext ارسال نمی‌شود، اما Authorization Material و Metadata همچنان حساس هستند.
سناریو ۱: Phone IP دارد ولی Register نمی‌شود
روش استاندارد:
DHCP: ACK سالم است؟
DNS: Registrar Resolve می‌شود؟
TLS: Handshake کامل می‌شود؟
REGISTER: چه Response Codeی می‌آید؟
اگر DNS سالم است ولی هیچ TCP/TLS Connectionی به IP Registrar نمی‌بینید، Config Phone یا Firewall را بررسی کنید. اگر TLS کامل است ولی REGISTER با 403 رد می‌شود، مشکل Network پایه نیست؛ Authorization/Policy را بررسی کنید.
سناریو ۲: تماس Outbound با 404 یا 403 Fail می‌شود
REGISTER سالم است، پس از DHCP و DNS عبور کرده‌اید. مستقیم به INVITE بروید. Request-URI، From، To و Source IP Response را بخوانید.
اگر Provider 404 داده، Number Format یا Route را بررسی کنید. اگر 403 داده، Permission، Caller ID یا Policy را بررسی کنید. Reset Phone در این مرحله معمولاً بی‌ربط است.
سناریو ۳: تماس با 488 Fail می‌شود
INVITE و Response را جدا کنید و SDP Offer/Answer را مقایسه کنید. Codec مشترک، RTP/SRTP Profile، DTMF و Media IP/Port را بررسی کنید.
اگر PBX در میانه SDP را تغییر می‌دهد، Capture سمت Phone و سمت Provider را مقایسه کنید. مشکل لزوماً Endpoint نیست.
سناریو ۴: تماس برقرار می‌شود اما صدا ندارید
اگر 200 OK و ACK کامل شده‌اند، Signaling اصلی سالم است. حالا SDP و RTP مهم‌اند.
IP/Port اعلام‌شده در SDP را استخراج کنید و بررسی کنید RTP واقعاً به همان مقصد می‌رود یا نه. اگر Media فقط در یک جهت وجود دارد، NAT/Firewall/SBC را بررسی کنید.
سناریو ۵: کیفیت صدا بد است اما تماس قطع نمی‌شود
این‌جا دیگر SIP Response Code مهم‌ترین چیز نیست. RTP Stream Analysis را باز کنید و Sequence Gap، Loss و Jitter را ببینید. RTCP و Call Statistics Phone نیز می‌توانند سرنخ دهند.
اگر Packet Loss روی Capture Phone وجود دارد، مشکل قبل از رسیدن Packet به Phone است. اگر Capture Phone سالم است ولی User صدا را بد می‌شنود، Codec/Audio Device/Local Path را نیز بررسی کنید.
اگر SIP رمز شده است، چه روشی استاندارد است؟
روی TLS، فقط به این دلیل که Wireshark REGISTER را نمایش نمی‌دهد، TLS را خاموش نکنید. روش حرفه‌ای این است:
🔹 DHCP و DNS را از PCAP Phone بررسی کنید.
🔹 TLS Handshake و Alertها را بررسی کنید.
🔹 از PRT/Syslog برای جزئیات SIP خود Phone استفاده کنید.
🔹 روی SBC/PBX بعد از TLS Termination Trace بگیرید.
🔹 Timestamp و Call-ID را بین Logها تطبیق دهید.
فیلترهای کاربردی که برای هر Cisco Trace ذخیره کنید
فیلتر کلی DHCP:
dhcp || bootpDNS:
dnsTLS:
tlsSIP:
sipSIP Failureها:
sip.Status-Code >= 400RTP و RTCP:
rtp || rtcpWireshark در نسخه‌های فعلی هزاران Protocol Field دارد و Filter Reference رسمی آن بهترین مرجع برای Fieldهای دقیق‌تر است.
PCAP تلفن Cisco دارید ولی نمی‌دانید از کجا شروع کنید؟
برای تحلیل دقیق، فایل PCAP یا PRT، مدل Phone، Firmware، زمان تست، شماره مبدا/مقصد و نوع PBX را آماده کنید. با همین اطلاعات می‌توان مرحله خراب را بین DHCP، DNS، TLS، REGISTER، INVITE، SDP و RTP مشخص کرد.
ایرانیکاسرور می‌تواند در بررسی Cisco MPP، Asterisk/FreePBX، Webex Calling، CUBE، SIP Trunk و Packet Capture کمک کند تا به‌جای تغییرات تصادفی، Root Cause از روی Trace مشخص شود.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
پرسش‌های رایج
از خود Cisco MPP می‌توان Packet Capture گرفت؟
بله. Cisco در مستندات رسمی مسیر Info → Debug Info → Start Packet Capture را برای مدل‌های MPP پشتیبانی‌شده ارائه می‌کند.
برای عیب‌یابی Cisco IP Phone اول SIP را بررسی کنیم یا DHCP؟
DHCP اولویت دارد. اگر Phone IP، Gateway یا DNS درست نگرفته باشد، تحلیل SIP در مرحله بعد ممکن است شما را به نتیجه اشتباه برساند.
چرا در Wireshark REGISTER را نمی‌بینم و فقط TLS می‌بینم؟
اگر SIP over TLS فعال باشد، SIP داخل TLS رمز شده است. در این حالت Handshake را از PCAP بررسی کنید و جزئیات SIP را از PRT/Syslog یا Trace سمت PBX/SBC بعد از TLS Termination بگیرید.
آیا 401 بعد از REGISTER همیشه خطاست؟
خیر. در SIP Digest Authentication، 401 می‌تواند Challenge طبیعی باشد. باید REGISTER بعدی با Authorization و سپس 200 OK را ببینید.
برای One-Way Audio کدام بخش Capture مهم‌تر است؟
SDP و RTP. ابتدا IP و Portهای Media را از SDP استخراج کنید و بعد ببینید RTP در هر دو جهت وجود دارد یا فقط یک Stream دیده می‌شود.
چطور Packet Loss تماس Cisco را در Wireshark ببینیم؟
از Telephony → RTP → RTP Streams استفاده کنید و Stream را Analyze کنید. Sequence Gap، Packet Loss و Jitter از مهم‌ترین شاخص‌ها هستند.
Call-ID چه کاربردی دارد؟
Call-ID شناسه‌ای است که پیام‌های SIP همان تماس را به هم متصل می‌کند. با آن می‌توانید INVITE، Responseها، ACK و BYE یک Call را در Trace شلوغ جدا کنید.
PRT و PCAP چه فرقی دارند؟
PCAP ترافیک Network را ثبت می‌کند. PRT مجموعه‌ای از Logها و اطلاعات داخلی Phone است. برای Troubleshooting حرفه‌ای، استفاده هم‌زمان از هر دو بسیار مفید است.
جمع‌بندی
یک روش استاندارد برای عیب‌یابی Cisco IP Phone همیشه از Network شروع می‌شود و به Media ختم می‌شود: DHCP، DNS، TLS، REGISTER، INVITE، SDP و RTP.
در DHCP بررسی کنید Phone چه IP، Gateway، DNS و Optionهایی گرفته است. در DNS ببینید کدام FQDN یا SRV Resolve شده. اگر TLS دارید، Handshake و Alertها را تأیید کنید. در REGISTER به Challenge، Authorization و 200 OK برسید.
برای تماس، Call-ID را از INVITE بردارید و Flow را تا 200 OK و ACK دنبال کنید. سپس SDP را برای Codec، IP و Port تحلیل کنید و در پایان RTP را از نظر مسیر دوطرفه، Loss، Jitter، Sequence و SSRC بررسی کنید.
وقتی این ترتیب ثابت را رعایت کنید، «تلفن کار نمی‌کند» به یک Failure مشخص تبدیل می‌شود: مثلاً DNS Resolve نمی‌کند، TLS Alert می‌دهد، REGISTER با 403 رد می‌شود، SDP IP اشتباه دارد یا RTP در مسیر برگشت Drop می‌شود. همین تفاوت، عیب‌یابی حرفه‌ای را از آزمون‌وخطا جدا می‌کند.
برای تحلیل Packet Capture تلفن Cisco کمک می‌خواهید؟
فایل PCAP/PRT، مدل و Firmware تلفن، Timestamp مشکل و شماره مبدا/مقصد را آماده کنید. با همین اطلاعات می‌توان مرحله شکست را از DHCP تا RTP مشخص کرد.
تماس با پشتیبانی ایرانیکاسرور: 021-91302467
دیدگاه‌ها (۰)