چطور با Packet Capture مشکل تلفن Cisco را پیدا کنیم؟ از DHCP تا SIP و RTP

DHCP → DNS → TLS → REGISTER → INVITE → SDP → RTP

اگر هر مرحله سالم نباشد، رفتن به مرحله بعد معمولاً وقت تلف‌کردن است. برای مثال اگر DNS نتواند نام SIP Server را Resolve کند، تحلیل REGISTER بی‌معنی است؛ چون ممکن است تلفن اصلاً هیچ REGISTERای نفرستاده باشد. اگر INVITE و SDP سالم‌اند اما RTP فقط در یک جهت دیده می‌شود، دیگر مشکل Registration نیست و باید مسیر Media، NAT و Firewall بررسی شود.

Packet Capture روی Cisco IP Phone چه چیزی به ما می‌دهد؟

یک PCAP خوب می‌تواند نشان دهد:

روی Cisco MPP چطور Packet Capture بگیریم؟

Cisco در راهنمای فعلی MPP قابلیت Packet Capture مستقیم از خود تلفن را ارائه می‌کند.

ابتدا IP تلفن را پیدا کنید و وارد Web Administration شوید.

مسیر معمول:

Admin Login → Advanced → Info → Debug Info

در بخش Problem Report Tool گزینه:

Start Packet Capture

را انتخاب کنید.

سپس مشکل را فقط یک بار بازتولید کنید و Capture را متوقف کنید.

فایل PCAP ساخته‌شده را دانلود و در Wireshark باز کنید.

Capture را قبل از وقوع مشکل شروع کنید

اگر مشکل Registration است، Capture را قبل از Reboot یا Resync شروع کنید.

اگر مشکل تماس است، قبل از شماره‌گیری Capture را Start کنید.

اگر مشکل Transfer است، تماس را برقرار کنید، بعد Capture یا Marker زمانی داشته باشید و سپس Transfer را انجام دهید.

هدف این است که چند ثانیه قبل و بعد از Failure را در اختیار داشته باشید.

Capture کوتاه بهتر از فایل یک‌ساعته است

برای یک خطای Registration معمولاً یک Capture کوتاه که شامل Boot یا Registration Attempt باشد بسیار مفیدتر از صدها مگابایت ترافیک نامرتبط است.

روش مناسب:

Start Capture → بازتولید یک Failure → Stop Capture.

زمان دقیق تست را نیز یادداشت کنید تا بتوانید PCAP را با PRT و PBX Log تطبیق دهید.

هشدار درباره TLS: همیشه محتوای SIP را نمی‌بینید

Packet Capture داخلی تلفن در سطح شبکه گرفته می‌شود.

اگر SIP روی TLS یا Provisioning روی HTTPS باشد، Payload رمزنگاری‌شده است.

در نتیجه ممکن است خود REGISTER یا INVITE را با فیلتر sip نبینید، اما هنوز می‌توانید موارد مهمی مثل IP مقصد، TCP Connection، TLS Handshake، Reset، Retransmission، Alert و زمان‌بندی ارتباط را بررسی کنید.

پس «SIP در Capture دیده نمی‌شود» الزاماً به معنی «SIP ارسال نشده» نیست؛ اول ببینید Transport آن TLS است یا Plain SIP.

فیلتر پایه برای شروع تحلیل

برای یک Capture کامل Boot تا تماس، این فیلتر دید خوبی می‌دهد:

dhcp || dns || tls || sip || sdp || rtp || rtcp

اما برای عیب‌یابی واقعی بهتر است مراحل را یکی‌یکی جدا کنیم.

مرحله ۱: DHCP؛ آیا تلفن اصلاً Network Identity درست گرفته است؟

اولین مرحله بعد از اتصال Phone به Voice VLAN معمولاً DHCP است.

چرخه پایه DHCP را با چهار پیام می‌شناسیم:

Discover → Offer → Request → ACK

که معمولاً با نام DORA شناخته می‌شود.

فیلتر DHCP در Wireshark

dhcp

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

فقط گرفتن IP کافی نیست.

داخل ACK این موارد را بررسی کنید:

اگر Phone IP گرفته اما Gateway یا DNS اشتباه است، Registration بعدی ممکن است Fail شود و خطا ظاهراً SIP به نظر برسد.

Discover می‌بینیم ولی Offer نداریم

این سناریو معمولاً ما را از خود Cisco Phone دور می‌کند.

بررسی کنید:

اگر DHCP Snooping فعال کرده‌اید و Phone دیگر IP نمی‌گیرد، راهنمای مرتبط ایرانیکاسرور درباره رفع مشکل نگرفتن IP بعد از فعال‌سازی DHCP Snooping می‌تواند مرحله بعدی عیب‌یابی باشد.

Offer می‌آید ولی ACK کامل نمی‌شود

در این حالت Transaction ID و MAC Client را دنبال کنید.

ممکن است چند DHCP Server پاسخ دهند یا Client Offer دیگری را انتخاب کند.

همچنین DHCP NAK را بررسی کنید:

dhcp.option.dhcp == 6

مقدار 6 در DHCP Message Type به NAK مربوط است.

مرحله ۲: DNS؛ تلفن اسم Server را به IP درست تبدیل می‌کند؟

بعد از Network Configuration معمولاً Phone باید نام‌های مربوط به SIP Server، Provisioning، Webex، NTP یا سایر سرویس‌ها را Resolve کند.

فیلتر:

dns

هر Query باید Response داشته باشد

مثلاً اگر Phone Query می‌زند:

sip.example.com

باید ببینید Response چه IPی برگردانده است.

سه حالت مهم:

No Response: مسیر DNS یا Firewall مشکل دارد.

NXDOMAIN: Resolver می‌گوید Domain وجود ندارد.

IP اشتباه: DNS کار می‌کند، اما رکورد نادرست است.

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

بعضی SIP Deploymentها به‌جای A Record ساده از SRV استفاده می‌کنند.

برای دیدن Queryهای SRV:

dns.qry.type == 33

اگر Phone SRV Query دارد ولی Resolver آن را درست پاسخ نمی‌دهد، ممکن است A Recordهای معمولی سالم باشند ولی SIP Registration همچنان شکست بخورد.

DNS Failure را با SIP Failure اشتباه نگیرید

اگر Capture چنین الگویی دارد:

DNS Query → Retransmission → Query دوباره → No Answer

و هیچ Connection به SIP Server ساخته نمی‌شود، مشکل هنوز به REGISTER نرسیده است.

در Release فعلی MPP یعنی 12.0(7)SR5 نیز Cisco یک مشکل مربوط به SIP Registration ناشی از DNS Lookup Failure را برطرف کرده است؛ همین موضوع اهمیت بررسی DNS قبل از SIP را نشان می‌دهد.

مرحله ۳: TLS؛ آیا ارتباط امن قبل از SIP برقرار می‌شود؟

اگر SIP Transport روی TLS است، بعد از DNS باید TCP و سپس TLS Session را ببینید.

فیلتر:

tls

قبل از TLS باید TCP برقرار شود

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

SYN → SYN/ACK → ACK

اگر SYN می‌رود ولی SYN/ACK برنمی‌گردد، هنوز Certificate مشکل نیست.

احتمال‌ها:

TCP کامل است اما TLS شکست می‌خورد

حالا Client Hello و پاسخ Server را بررسی کنید.

نشانه‌های مهم:

اگر Server Hello می‌آید و بعد Alert می‌بینید، آن‌وقت Certificate، Hostname، Trust Store، TLS Version و Cipherها بررسی می‌شوند.

ساعت اشتباه تلفن می‌تواند TLS را خراب کند

اگر Certificate از نظر Date معتبر به نظر نمی‌رسد، NTP و ساعت Phone را بررسی کنید.

Certificate Error را با خاموش‌کردن Validation حل نکنید؛ ابتدا:

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

اگر SIP داخل TLS رمز شده، مرحله REGISTER را چطور تحلیل کنیم؟

در Capture خود Phone ممکن است SIP Payload قابل خواندن نباشد.

در این حالت دو راه دارید:

راه اول: Endpoint-side PCAP را برای Network/TLS Timing استفاده کنید و هم‌زمان روی PBX/SBC یک SIP Trace بگیرید.

راه دوم: در محیط آزمایشی و مجاز، در صورت امکان از Capture سمت Server که Signaling بعد از TLS Termination قابل مشاهده است استفاده کنید.

برای Production، TLS را فقط برای اینکه Wireshark SIP را نشان دهد خاموش نکنید.

مرحله ۴: REGISTER؛ تلفن چطور روی SIP Server ثبت می‌شود؟

در SIP بدون TLS یا در Capture سمت Server، فیلتر:

sip.Method == "REGISTER"

یا ساده‌تر:

sip

Flow سالم REGISTER معمولاً چگونه است؟

یکی از Flowهای رایج:

REGISTER
401 Unauthorized
REGISTER + Authorization
200 OK

401 در این Flow خطا نیست؛ Challenge طبیعی Digest Authentication است.

در REGISTER چه Headerهایی را بررسی کنیم؟

این فیلدها مشخص می‌کنند Phone واقعاً با چه Identity و به چه Registrarی درخواست می‌فرستد.

REGISTER می‌رود ولی هیچ Response نمی‌آید

این حالت بیشتر به Network Path نزدیک است:

قبل از تغییر Password، ببینید آیا Server اصلاً Request را دریافت کرده است.

REGISTER پاسخ 403 می‌گیرد

حالا Server Request را دیده و عمداً Reject کرده است.

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

REGISTER روی 503 می‌ماند

503 بیشتر به Availability سمت Server، Registrar یا Upstream نزدیک است.

Source IP پاسخ و Headerهای Retry را بررسی کنید.

Response Codeها را جدا فیلتر کنید

برای مشاهده همه Responseها:

sip.Status-Code

مثلاً 403:

sip.Status-Code == 403

مرحله ۵: INVITE؛ تماس واقعاً چگونه شروع می‌شود؟

وقتی Registration سالم شد، تماس را بررسی کنید.

فیلتر:

sip.Method == "INVITE"

Flow پایه یک تماس SIP

یک Flow ساده می‌تواند این‌گونه باشد:

INVITE
100 Trying
180 Ringing
200 OK
ACK

بعد از ACK تماس Signaling از نظر اولیه برقرار شده است و باید Media را بررسی کنیم.

INVITE به شماره اشتباه می‌رود

Request-URI را ببینید.

مثلاً:

INVITE sip:02191302467@pbx.example.com SIP/2.0

اگر Number Format، Prefix یا Domain اشتباه است، مشکل قبل از RTP و Codec قرار دارد.

INVITE فرستاده می‌شود ولی 404 برمی‌گردد

Route، Request-URI، Extension و Destination را بررسی کنید.

INVITE با 488 رد می‌شود

حالا SDP و Media Negotiation مظنون اصلی هستند.

به همین دلیل مرحله بعدی تحلیل SDP است.

INVITE هیچ Response نمی‌گیرد

قبل از نتیجه‌گیری درباره PBX:

اگر UDP SIP استفاده می‌شود، Retransmissionهای تکراری INVITE بدون Response نشانه خوبی از عدم رسیدن Request یا برگشت Response است.

مرحله ۶: SDP؛ مهم‌ترین بخش برای مشکلات Codec و صدای یک‌طرفه

SDP یا Session Description Protocol داخل SIP Message مشخص می‌کند Media چگونه برقرار شود.

فیلتر:

sdp

در SDP اول c= و m= را پیدا کنید

نمونه:

c=IN IP4 10.20.30.40
m=audio 16420 RTP/AVP 0 8 101

خط c= آدرس Media را مشخص می‌کند.

خط m=audio Port و نوع RTP/Profile و Payload Typeها را نشان می‌دهد.

برای صدای یک‌طرفه اول IP داخل SDP را بررسی کنید

اگر Cisco در SDP این IP را اعلام کند:

c=IN IP4 192.168.10.25

اما طرف مقابل روی اینترنت عمومی قرار دارد و هیچ SBC/NAT Rewrite وجود ندارد، Remote Side نمی‌تواند مستقیم به این Private IP RTP بفرستد.

در این حالت یک‌طرفه شدن صدا کاملاً منطقی است.

Codec را از روی Payload Type بخوانید

مثلاً:

a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000

اگر Offer و Answer هیچ Codec مشترکی نداشته باشند، تماس می‌تواند با 488 شکست بخورد.

SDP Offer و Answer را کنار هم ببینید

فقط SDP داخل INVITE را بررسی نکنید.

SDP سمت مقابل را در 183 Session Progress یا 200 OK نیز ببینید.

مقایسه کنید:

Hold مشکل دارد؟ SDP را قبل و بعد Hold مقایسه کنید

Hold معمولاً با re-INVITE یا UPDATE و تغییر Direction Attribute همراه است.

ممکن است ببینید:

a=sendonly

یا:

a=inactive

اگر Resume انجام می‌شود ولی SDP به وضعیت مناسب برنمی‌گردد، Media ممکن است قطع بماند.

مرحله ۷: RTP؛ آیا صدا واقعاً حرکت می‌کند؟

بعد از اینکه INVITE و SDP موفق بودند، دیگر وقت بررسی Media است.

فیلتر ساده:

rtp

اگر Wireshark RTP را خودکار Decode نکرد:

Telephony → RTP → RTP Streams

یا در صورت نیاز روی UDP Stream از Decode As استفاده کنید.

اولین سؤال RTP: یک Stream داریم یا دو جهت؟

یک تماس دوطرفه معمولاً باید Media دو جهت داشته باشد.

مثلاً:

Cisco → PBX/SBC

و:

PBX/SBC → Cisco

اگر فقط Stream خروجی Cisco دیده می‌شود، مشکل دریافت Media است.

اگر فقط RTP به Cisco می‌آید ولی Cisco چیزی نمی‌فرستد، سمت Phone، SDP یا Audio Path را بررسی کنید.

RTP به IP یا Port دیگری می‌رود

SDP را با خود RTP مقایسه کنید.

اگر SDP گفته:

m=audio 16420 RTP/AVP 0

باید ببینید Remote RTP واقعاً به Port 16420 می‌رسد یا نه.

اگر Media به Port قدیمی یا IP دیگری می‌رود، NAT/SBC/re-INVITE را بررسی کنید.

Sequence Numberهای RTP چه چیزی نشان می‌دهند؟

هر RTP Packet یک Sequence Number دارد.

اگر Sequence به‌جای:

1200
1201
1202
1203

به شکل:

1200
1201
1205
1206

دیده شود، Packetهای 1202 تا 1204 در Capture یا مسیر گم شده‌اند.

Lost Packet داخل Capture همیشه به معنی Network Loss نیست

اگر Capture را فقط در یک نقطه گرفته‌اید، نبود Packet در همان نقطه فقط ثابت می‌کند آن Packet به آن نقطه نرسیده است.

برای پیدا کردن محل واقعی Loss، Capture دو نقطه را مقایسه کنید:

Capture A: نزدیک Phone.

Capture B: نزدیک PBX/SBC.

اگر Packet در A وجود دارد اما در B نیست، Loss بین این دو نقطه رخ داده است.

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

در:

Telephony → RTP → RTP Streams → Analyze

می‌توانید اطلاعاتی مثل:

را ببینید.

این آمار را با Call Statistics خود Cisco Phone مقایسه کنید تا تشخیص فقط بر اساس یک ابزار نباشد.

RTCP را هم بررسی کنید

اگر RTCP در تماس استفاده می‌شود، می‌تواند اطلاعات کیفیت Media ارائه کند.

فیلتر:

rtcp

اما نبود RTCP در همه Deploymentها الزاماً خطا نیست؛ تنظیم Media Platform و Provider مهم است.

SRTP داریم؛ چرا Wireshark صدا را Decode نمی‌کند؟

اگر Media با SRTP رمز شده باشد، Payload معمول RTP قابل شنیدن یا Decode مستقیم نیست.

اما هنوز می‌توانید:

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

برای عیب‌یابی Network معمولاً همین Metadata نیز بسیار ارزشمند است.

یک روش استاندارد برای خواندن Capture از ابتدا تا انتها

فرض کنید Phone رجیستر می‌شود ولی تماس خروجی صدا ندارد.

این ترتیب را رعایت کنید:

مرحله ۱ — DHCP: IP، Gateway و DNS درست‌اند؟

مرحله ۲ — DNS: نام SIP Server به IP درست Resolve می‌شود؟

مرحله ۳ — TLS: اگر TLS داریم، TCP و Handshake کامل‌اند؟

مرحله ۴ — REGISTER: آیا 200 OK Registration داریم؟

مرحله ۵ — INVITE: آیا تماس با 200 OK و ACK کامل می‌شود؟

مرحله ۶ — SDP: IP و RTP Port هر دو سمت درست‌اند؟

مرحله ۷ — RTP: آیا Media در هر دو جهت دیده می‌شود؟

با همین ترتیب، دامنه مشکل در هر مرحله کوچک‌تر می‌شود.

مثال ۱: تلفن روی Registering گیر کرده است

Capture را باز می‌کنیم.

DHCP DORA کامل است.

DNS Query برای:

sip.example.com

ارسال می‌شود اما هیچ Response دریافت نمی‌شود.

هیچ TCP/TLS یا REGISTER بعدی نداریم.

نتیجه: هنوز مشکل SIP نیست؛ DNS Failure جلوی رسیدن Phone به Registrar را گرفته است.

مثال ۲: DNS سالم است ولی TLS بالا نمی‌آید

DNS IP درست را برمی‌گرداند.

Phone SYN می‌فرستد.

Server SYN/ACK می‌دهد.

Client Hello ارسال می‌شود.

بعد TLS Alert می‌آید.

نتیجه: Network Reachability سالم است و باید Certificate، Trust، Hostname و TLS Policy بررسی شوند.

مثال ۳: REGISTER به 403 می‌رسد

Flow:

REGISTER
401
REGISTER + Authorization
403

نتیجه: Phone و Server با هم ارتباط دارند. حالا Credential Identity، Account Policy، IP Restriction یا Provider Permission بررسی می‌شود.

مثال ۴: تماس برقرار می‌شود ولی هیچ صدا نداریم

INVITE، 180، 200 OK و ACK سالم‌اند.

در SDP سمت Cisco می‌بینیم:

c=IN IP4 192.168.10.25
m=audio 16384 RTP/AVP 0

Remote Server روی اینترنت عمومی است و هیچ SBC Media Relay وجود ندارد.

نتیجه: Private IP داخل SDP یکی از مظنون‌های اصلی One-Way/No Audio است.

مثال ۵: RTP دوطرفه است ولی صدا رباتی است

هر دو RTP Stream وجود دارند.

اما RTP Analysis نشان می‌دهد:

نتیجه: Registration و Signaling را کنار می‌گذاریم و مسیر WAN/QoS/Wi-Fi را بررسی می‌کنیم.

برای Packet Loss از Capture دوطرفه استفاده کنید

یکی از قوی‌ترین روش‌ها این است:

PCAP 1: روی Phone یا Switch Access.

PCAP 2: روی PBX/SBC.

بعد RTP Sequence Numberها را مقایسه کنید.

اگر Packet شماره 2005 از Phone خارج شده اما هیچ‌وقت به PBX نرسیده، Loss در Network است.

اگر در PBX دیده می‌شود ولی Application آن را Process نمی‌کند، مشکل بالاتر از Network Layer قرار دارد.

Call-ID ابزار طلایی برای دنبال‌کردن یک تماس است

در محیط شلوغ صدها SIP Message وجود دارد.

Call-ID یک تماس را پیدا کنید و تمام Messageهای همان Dialog را دنبال کنید.

در Wireshark می‌توانید روی Call-ID راست‌کلیک کنید و آن را به‌عنوان Filter اعمال کنید.

این کار INVITE، Responses، ACK، BYE و re-INVITEهای همان تماس را از بقیه جدا می‌کند.

Telephony → VoIP Calls را استفاده کنید

Wireshark ابزار مفیدی دارد:

Telephony → VoIP Calls

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

Flow Sequence

را باز کنید.

این نما برای دیدن سریع:

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

اما Flow Sequence جای خواندن Header را نمی‌گیرد

برای خطاهای واقعی باید Packet را باز کنید و Request-URI، SDP، Via، Contact و Response Source را ببینید.

Flow Sequence برای جهت‌یابی عالی است، اما علت نهایی معمولاً داخل جزئیات Packet قرار دارد.

TCP Retransmissionها را فراموش نکنید

برای TLS یا SIP over TCP این فیلتر مفید است:

tcp.analysis.retransmission

اگر TLS Handshake یا SIP TLS همراه Retransmission شدید است، MTU، Packet Loss و Network Path را بررسی کنید.

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

برای IP Fragment:

ip.flags.mf == 1 || ip.frag_offset > 0

اگر SIP INVITE بزرگ روی VPN Fragment می‌شود و یکی از Fragmentها Drop می‌شود، تماس ممکن است بدون Response بماند.

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

برای TCP Reset:

tcp.flags.reset == 1

وجود RST به‌تنهایی علت را مشخص نمی‌کند، اما مشخص می‌کند کدام سمت Session را ناگهانی بسته است.

فیلتر یک Phone خاص

اگر IP تلفن:

192.0.2.25

است:

ip.addr == 192.0.2.25

IP بالا فقط مثال مستندسازی است.

فیلتر یک SIP Server خاص

ip.addr == 198.51.100.20

PRT و PCAP را با هم استفاده کنید

PCAP می‌گوید روی شبکه چه اتفاقی افتاده است.

PRT نشان می‌دهد خود Endpoint در همان زمان چه وضعیتی داشته است.

برای مشکل‌های سخت این سه منبع را کنار هم داشته باشید:

این ترکیب بسیار قوی‌تر از Screenshot صفحه تلفن است.

قبل از ارسال PCAP برای دیگران، اطلاعات حساس را بررسی کنید

Capture ممکن است شامل موارد حساس باشد:

اگر Signaling رمز نشده باشد حتی اطلاعات بیشتری قابل مشاهده است.

PCAP را عمومی آپلود نکنید و فقط با تیمی که برای عیب‌یابی نیاز دارد به اشتراک بگذارید.

جدول استاندارد تشخیص از Boot تا RTP

از کجا بفهمیم مشکل دقیقاً متعلق به کدام تیم است؟

این روش یک مزیت مهم دارد: مسئول واقعی مشکل را مشخص می‌کند.

DHCP Fail: تیم LAN/VLAN/DHCP.

DNS Fail: DNS/Network.

TLS Fail: PKI/Firewall/SIP Infrastructure.

REGISTER 403: PBX/Provider/Account.

INVITE 404: Dial Plan/Route.

488: Media Negotiation/Codec/Security.

RTP One-Way: NAT/Firewall/SBC.

RTP Loss/Jitter: LAN/WAN/Wi-Fi/QoS.

اشتباه‌های رایج هنگام تحلیل PCAP

اشتباه ۱: مستقیم جست‌وجوی RTP در تلفنی که هنوز Register نشده است.

اشتباه ۲: دیدن 401 و تصور اینکه Authentication خراب است.

اشتباه ۳: دیدن TLS و تصور اینکه حتماً Session سالم است.

اشتباه ۴: بررسی فقط INVITE و ندیدن SDP داخل 200 OK.

اشتباه ۵: نتیجه‌گیری درباره Packet Loss از فقط یک Capture Point.

اشتباه ۶: خاموش‌کردن TLS برای دیدن SIP بدون حفظ Security Baseline.

اشتباه ۷: Factory Reset قبل از ذخیره PCAP و PRT.

یک چک‌لیست سریع برای هر Capture

هر بار PCAP باز می‌کنید این ترتیب را اجرا کنید:

۱. IP Phone چیست؟

۲. DHCP کامل شده؟

۳. DNS Server و DNS Responses درست‌اند؟

۴. مقصد SIP/Provisioning چه IPی است؟

۵. TCP/TLS کامل می‌شود؟

۶. REGISTER چه Responseی دارد؟

۷. INVITE به چه URIای می‌رود؟

۸. SDP چه IP و Portی اعلام کرده؟

۹. RTP در هر دو جهت هست؟

۱۰. Loss/Jitter/Fragmentation وجود دارد؟

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

چطور روی Cisco MPP Packet Capture بگیریم؟

از Web Administration وارد Info → Debug Info شوید و Start Packet Capture را بزنید. مشکل را یک بار بازتولید کنید، Capture را متوقف و فایل PCAP را دانلود کنید.

برای عیب‌یابی Cisco Phone از کدام Protocol شروع کنیم؟

اگر مشکل از Boot یا Registration است، از DHCP و DNS شروع کنید؛ سپس TCP/TLS و REGISTER را بررسی کنید. برای مشکل تماس بعد از Registration، INVITE، SDP و RTP را دنبال کنید.

چرا در PCAP هیچ SIP Messageای نمی‌بینم؟

اگر SIP over TLS فعال باشد، Payload SIP رمز شده است. TCP/TLS Session را بررسی کنید و برای دیدن SIP Plaintext از Log یا Capture مجاز سمت PBX/SBC بعد از TLS Termination استفاده کنید.

آیا 401 Unauthorized هنگام REGISTER یعنی Password اشتباه است؟

نه لزوماً. 401 معمولاً Challenge طبیعی Digest Authentication است. مهم است ببینید REGISTER بعدی با Authorization ارسال می‌شود و در نهایت 200 OK می‌گیرد یا نه.

برای صدای یک‌طرفه در PCAP اول چه چیزی را ببینیم؟

ابتدا IP و Portهای اعلام‌شده در SDP را بررسی کنید، سپس ببینید RTP در هر دو جهت وجود دارد یا فقط یک Stream دیده می‌شود.

برای Codec مشکل‌دار چه چیزی را بررسی کنیم؟

Payload Typeها و a=rtpmap در SDP Offer و Answer را مقایسه کنید. اگر Codec مشترک وجود نداشته باشد، تماس می‌تواند با 488 رد شود.

Wireshark می‌تواند Jitter و Packet Loss را اندازه بگیرد؟

بله. از Telephony → RTP → RTP Streams → Analyze می‌توانید Sequence Error، Jitter، Delta و Packet Loss را بررسی کنید.

آیا PCAP برای TLS و SRTP بی‌فایده است؟

خیر. حتی اگر Payload رمز شده باشد، IP، Port، Direction، Timing، TCP/TLS Failure و جریان Media همچنان قابل بررسی هستند.

قبل از Factory Reset چه کار کنیم؟

PRT و PCAP را قبل از Reset ذخیره کنید. Factory Reset می‌تواند وضعیت خطادار و Logهای ارزشمند قبل از خرابی را از بین ببرد.