VOS3000 SIP Debug: Essential Wireshark and Log Analysis Guide
Diagnosing VoIP call failures without a proper VOS3000 SIP debug workflow is like searching for a needle in a haystack while blindfolded. Most VOS3000 operators rely on guesswork when calls fail, randomly changing gateway settings, firewall rules, and system parameters until something works. This approach wastes hours, creates instability, and often introduces new problems while attempting to fix the original one. The professional method involves systematically capturing and analyzing SIP signaling traffic using Wireshark alongside VOS3000 native debug trace tools, then correlating the results with CDR termination reasons to pinpoint the exact root cause of any call failure.
This guide teaches you the complete VOS3000 SIP debug methodology: from enabling VOS3000’s built-in Debug Trace function, to capturing traffic with tcpdump on CentOS 7, to analyzing SIP call flows in Wireshark, and finally correlating everything with CDR records. Every technique described here is based on real VOS3000 features documented in the official VOS3000 V2.1.9.07 Manual. For professional assistance with VOS3000 troubleshooting, contact us on WhatsApp at +8801911119966.
Table of ContentsVOS3000 SIP Debug: Essential Wireshark and Log Analysis GuideVOS3000 SIP Debug: Built-in Debug Trace ToolEnabling VOS3000 SIP Debug TraceReading VOS3000 Debug Trace OutputCapturing VOS3000 Traffic with tcpdump on CentOS 7Essential tcpdump Commands for VOS3000VOS3000 SIP Debug with Wireshark FiltersEssential Wireshark SIP FiltersAnalyzing SIP Call Flow in WiresharkVOS3000 SIP Debug: Diagnosing One-Way AudioSDP Analysis for One-Way AudioVOS3000 SIP Debug: Diagnosing 32-Second Call DropsAnalyzing Session Timer in WiresharkVOS3000 SIP Debug: Correlating CDR with Packet CapturesCorrelation MethodVOS3000 SIP Debug: DTMF Failure AnalysisDiagnosing DTMF in WiresharkVOS3000 SIP Debug Best PracticesDebug Workflow ChecklistRelated ResourcesFrequently Asked Questions About VOS3000 SIP DebugHow do I enable VOS3000 SIP debug trace?What is the best tcpdump command for VOS3000 SIP debug?How do I diagnose one-way audio in VOS3000 using Wireshark?Why do VOS3000 calls drop exactly at 32 seconds?How do I check DTMF problems in VOS3000?Can I use VOS3000 Debug Trace instead of Wireshark?Get Professional VOS3000 SIP Debug Help Need Professional VOS3000 Setup Support?
VOS3000 SIP Debug: Built-in Debug Trace Tool
Before reaching for Wireshark, you should understand VOS3000’s native Debug Trace functionality, which provides SIP message logging directly from the softswitch without any external tools. This feature is documented in VOS3000 Manual Section 2.5.3 and provides real-time visibility into SIP signaling exchanged between VOS3000 and all connected gateways.
Enabling VOS3000 SIP Debug Trace
To activate the debug trace in VOS3000, navigate to Operation Management > Debug Trace in the VOS3000 client. The Debug Trace interface allows you to capture two types of traces:
SIP Trace: Captures all SIP signaling messages including INVITE, 200 OK, ACK, BYE, CANCEL, REGISTER, and OPTIONS messages with full headers and timestamps
Registration Trace: Captures specifically the SIP REGISTER messages exchanged between mapping gateways and VOS3000, useful for diagnosing registration failures and authentication problems
When you enable SIP Trace, VOS3000 displays every SIP message in real time with precise timestamps, the source and destination IP addresses, and the complete message headers including Via, From, To, Call-ID, Contact, and SDP content. This immediate visibility into signaling flow makes it possible to identify configuration problems such as incorrect Contact headers, mismatched IP addresses in SDP, or missing authentication credentials without needing any packet capture tools.
Reading VOS3000 Debug Trace Output
The debug trace output shows SIP messages in chronological order with millisecond timestamps. Each message is displayed with its direction (sent or received), the remote IP address, and the complete SIP message content. When analyzing the trace, pay close attention to the following elements that commonly reveal the root cause of call failures:
Trace Element What to Look For Common ProblemVia headerCorrect IP and port in received/rportNAT mangling changes real IPContact headerReachable IP and portPrivate IP in Contact (NAT issue)SDP c= lineCorrect media IP addressWrong IP causes one-way audioSDP m= lineCodec and port match expectationsCodec mismatch or blocked portSession-ExpiresTimer values and refresher32-second drop from timer mismatchResponse timeDelay between INVITE and 100/180Slow response indicates network issue
Capturing VOS3000 Traffic with tcpdump on CentOS 7
While VOS3000 Debug Trace shows signaling content, it does not capture RTP media streams or provide the advanced filtering and analysis capabilities of Wireshark. For comprehensive VOS3000 SIP debug, you need to capture raw network packets using tcpdump on your CentOS 7 server, then analyze them in Wireshark on your workstation. This combined approach gives you complete visibility into both signaling and media paths.
Essential tcpdump Commands for VOS3000
The following tcpdump commands capture different aspects of VOS3000 traffic. Run these commands via SSH on your VOS3000 server:
# Capture SIP signaling only (port 5060 UDP and TCP)
tcpdump -i eth0 -w /tmp/sip-capture.pcap port 5060
# Capture SIP + RTP for a specific gateway IP
tcpdump -i eth0 -w /tmp/gateway-debug.pcap host 192.168.1.100
# Capture all traffic on SIP port with full packet size
tcpdump -i eth0 -s 0 -w /tmp/full-sip-capture.pcap udp port 5060 or tcp port 5060
# Capture SIP signaling for a specific phone number (filter in Wireshark later)
tcpdump -i eth0 -s 0 -w /tmp/number-debug.pcap port 5060
# Capture RTP media streams (port range 10000-20000)
tcpdump -i eth0 -w /tmp/rtp-capture.pcap udp portrange 10000-20000
# Combined SIP and RTP capture for complete analysis
tcpdump -i eth0 -s 0 -w /tmp/complete-debug.pcap
port 5060 or udp portrange 10000-20000
# Limit capture duration to 60 seconds
timeout 60 tcpdump -i eth0 -s 0 -w /tmp/timed-capture.pcap port 5060
After capturing, transfer the .pcap file to your workstation using SCP or SFTP, then open it in Wireshark for analysis. For detailed network configuration, refer to our CentOS 7 kernel tuning guide.
Debug Scenario tcpdump Command CapturesSIP signaling onlytcpdump -i eth0 -w file.pcap port 5060INVITE, 200 OK, BYE, REGISTERSingle gatewaytcpdump -i eth0 -w file.pcap host GW_IPAll traffic to/from gatewayRTP media onlytcpdump -i eth0 -w file.pcap udp portrange 10000-20000Audio media packetsComplete analysistcpdump -i eth0 -s 0 -w file.pcap port 5060 or udp portrange 10000-20000Signaling + media
VOS3000 SIP Debug with Wireshark Filters
Wireshark provides powerful display filters that allow you to isolate specific SIP messages, response codes, and call flows from a packet capture. Mastering these filters is essential for efficient VOS3000 SIP debug analysis. The following filters are the most useful for diagnosing VOS3000 call failures.
Essential Wireshark SIP Filters
Open your captured .pcap file in Wireshark and apply these display filters to isolate specific traffic:
# Show only SIP protocol messages
sip
# Show SIP and RTP together
sip || rtp
# Show only SIP INVITE messages
sip.Method == “INVITE”
# Show specific SIP response codes
sip.Status-Code == 503
sip.Status-Code == 408
sip.Status-Code == 403
sip.Status-Code == 480
# Show all SIP error responses (4xx, 5xx, 6xx)
sip.Status-Code >= 400
# Show BYE and CANCEL messages (call termination)
sip.Method == “BYE” || sip.Method == “CANCEL”
# Show REGISTER messages
sip.Method == “REGISTER”
# Filter by specific Call-ID (replace with actual Call-ID)
sip.Call-ID contains “abc123”
# Filter by specific phone number in SIP URI
sip.to contains “8801911119966”
# Show Session Timer related messages
sip.Session-Expires exists
Analyzing SIP Call Flow in Wireshark
A normal VOS3000 SIP call flow follows this sequence: INVITE, 100 Trying, 180 Ringing (or 183 Session Progress), 200 OK, ACK, and eventually BYE and 200 OK. When you analyze a VOS3000 SIP debug capture, the first step is to verify that this complete message flow occurs. Any deviation from this sequence indicates a specific problem.
SIP Message Expected If Missing/AbnormalINVITESent by VOS3000 to gatewayNot sent = routing problem100 TryingReceived from gatewayNot received = firewall or offline180 RingingDestination is alertingSkipped = fast answer or error200 OKCall answered with SDPError code instead = check codeACKConfirms call establishedMissing = call not confirmedBYENormal call terminationUnexpected BYE = check reason
Use Wireshark’s built-in Telephony > VoIP Calls feature to visualize the complete SIP call flow as a diagram. This shows all messages in sequence with timing, making it easy to spot anomalies. For detailed SIP call flow reference, see our VOS3000 SIP call flow guide.
VOS3000 SIP Debug: Diagnosing One-Way Audio
One-way audio is one of the most frustrating VoIP problems because the call connects successfully but only one party can hear the other. The root cause is almost always an incorrect IP address in the SDP (Session Description Protocol) content of the SIP messages, which tells the remote endpoint where to send RTP media packets. When VOS3000 or the gateway advertises a private or incorrect IP in the SDP c= line, media packets are sent to an unreachable address.
SDP Analysis for One-Way Audio
To diagnose one-way audio using VOS3000 SIP debug, capture the SIP signaling during a call and examine the SDP content in both the INVITE and the 200 OK messages. Look specifically at the c= (connection) line and the m= (media) line in the SDP:
# SDP in INVITE from VOS3000 to gateway:
v=0
o=- 123456 1 IN IP4 10.0.0.5 ← Check: Is this the real server IP?
s=-
c=IN IP4 10.0.0.5 ← CRITICAL: RTP goes here
t=0 0
m=audio 12345 RTP/AVP 0 8 18 ← RTP port and codec list
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:18 G729/8000
# If c= shows 10.0.0.5 but real IP is 203.0.113.50,
# RTP media will be sent to 10.0.0.5 (unreachable) = ONE-WAY AUDIO
When the SDP c= line contains a private IP address (10.x.x.x, 172.16-31.x.x, 192.168.x.x) but the VOS3000 server has a public IP, the remote gateway sends RTP to the private IP, which is unreachable from the internet. This results in the gateway hearing audio from VOS3000 (because VOS3000 can reach the gateway’s correct IP), but VOS3000 never receives the return RTP stream. The fix involves configuring the correct Local IP setting in VOS3000 gateway configuration, enabling media proxy mode, or adjusting NAT-related settings in the gateway’s Additional Settings. For more audio troubleshooting, see our VOS3000 echo delay and audio fix guide.
VOS3000 SIP Debug: Diagnosing 32-Second Call Drops
The 32-second call drop is a notorious issue in VOS3000 deployments where calls disconnect exactly 32 seconds after connecting. This problem is caused by Session Timer negotiation failure. When one side proposes a Session-Expires value that the other side does not support or refuses, the session timer expires after the minimum period, causing the call to drop. This is documented in VOS3000 Manual Section 4.3.5.2 with the SS_SESSION_TIMER parameters.
Analyzing Session Timer in Wireshark
To diagnose this issue, filter your Wireshark capture for Session-Expires headers and examine the negotiation between VOS3000 and the gateway:
Parameter Default Purpose FixSS_SESSION_TIMER1800 (30 min)Session timer durationSet to 0 to disableSS_SESSION_TIMER_MIN_SE90Minimum session expiresLower to 32 or disable timerSS_SESSION_TIMER_REFRESHER0 (UAC)Who sends refreshMatch with gateway setting
In Wireshark, search for “Session-Expires” in the SIP messages. If you see the gateway responding with a 422 Interval Too Brief containing a Min-SE value that is larger than VOS3000’s proposed Session-Expires, or if the gateway rejects the session timer entirely, the call will drop at the minimum timer expiry. The quickest fix is to set SS_SESSION_TIMER to 0 in VOS3000 softswitch parameters, which disables the session timer entirely. For detailed session timer troubleshooting, see our session timer 32-second drop guide.
VOS3000 SIP Debug: Correlating CDR with Packet Captures
The most powerful VOS3000 SIP debug technique combines packet capture analysis with CDR record examination. CDR records show you the outcome (termination reason, duration, gateway used), while packet captures show you the signaling path that led to that outcome. By correlating the two, you can trace any call failure from symptom to root cause with complete certainty.
Correlation Method
Follow these steps to correlate VOS3000 CDR records with Wireshark captures for effective debugging:
Start packet capture: Run tcpdump on the VOS3000 server before reproducing the issue
Make test call: Place a call that exhibits the problem
Stop capture: Stop tcpdump after the call fails
Find CDR record: In VOS3000, query the CDR for the test call using Data Query > CDR Query
Note the Call-ID: Record the call timestamp and caller/callee numbers
Filter in Wireshark: Open the capture and filter by the called number or timestamp range
Analyze the flow: Compare the SIP message sequence with the CDR termination reason
CDR Termination Reason What to Find in Wireshark Root CauseNoAvailableRouterNo INVITE sent to any gatewayNo matching prefix configuredInviteTimeout (408)INVITE sent, no response receivedFirewall, wrong IP, or offline gatewayAllGatewayBusy (503)INVITEs sent, 503 or no 200 OK from anyAll gateways at capacity or disabledSession timeoutBYE after exactly 32 secondsSession Timer negotiation failureNormal releaseBYE from caller or calleeNormal hangup (not a problem)No media timeoutNo RTP packets in one directionSDP IP mismatch or blocked RTP
For a complete reference of CDR termination reasons and their meanings, see our VOS3000 call end reasons guide.
VOS3000 SIP Debug: DTMF Failure Analysis
DTMF (Dual-Tone Multi-Frequency) failures occur when keypad presses during a call are not transmitted correctly to the remote end. This causes problems with IVR systems, voicemail navigation, and automated phone menus. VOS3000 supports multiple DTMF transmission methods, and mismatches between the mapping gateway, VOS3000, and routing gateway cause DTMF to fail silently.
Diagnosing DTMF in Wireshark
To debug DTMF issues, capture both SIP signaling and RTP media during a call where DTMF is being sent. Then analyze the capture for DTMF events using these Wireshark filters:
# Show RTP events (RFC 2833 DTMF)
rtp.event
# Show SIP INFO messages containing DTMF
sip.Method == “INFO” && sip contains “Signal”
# Show all RTP streams for codec analysis
rtp.stream
VOS3000 supports three DTMF modes documented in VOS3000 Manual Section 2.5.1.1: RFC 2833 (in-band RTP events), SIP INFO (out-of-band signaling), and Inband (audio tones). When the mapping gateway sends DTMF via RFC 2833 but the routing gateway expects SIP INFO, the DTMF digits are lost during translation. The fix involves ensuring consistent DTMF mode configuration across all gateways, or enabling VOS3000’s DTMF mode conversion feature in the gateway Additional Settings. For complete DTMF configuration, see our VOS3000 transcoding and DTMF guide.
DTMF Mode Wireshark Evidence Common FailureRFC 2833RTP event packets (payload 101)Missing payload type in SDPSIP INFOSIP INFO messages with SignalGateway ignores INFO messagesInbandAudio tones visible in RTP streamG729 compression destroys tones
VOS3000 SIP Debug Best Practices
Following a consistent debug methodology reduces troubleshooting time and improves accuracy. These best practices ensure your VOS3000 SIP debug sessions are productive and efficient.
Debug Workflow Checklist
Every time you need to debug a VOS3000 call issue, follow this structured workflow to avoid missing critical information:
Step 1: Define the problem precisely. Note the exact symptom: one-way audio, 32-second drop, 503 error, no ringback, DTMF not working, or registration failure
Step 2: Start packet capture first. Always begin tcpdump before reproducing the issue so you capture the complete message flow
Step 3: Make a test call. Use a consistent test number and document the exact timestamp
Step 4: Stop capture and find CDR. Stop tcpdump, then locate the exact CDR record for your test call
Step 5: Analyze in Wireshark. Open the capture, filter by your test call, and trace the complete SIP message flow
Step 6: Correlate CDR reason with packet evidence. Match the CDR termination reason to the specific SIP messages that caused it
Step 7: Apply targeted fix. Based on your analysis, make the specific configuration change needed
Step 8: Verify the fix. Repeat the test to confirm the issue is resolved
This systematic approach eliminates guesswork and ensures you fix the actual root cause rather than applying temporary workarounds. For professional VOS3000 troubleshooting assistance, contact us on WhatsApp at +8801911119966.
Problem First Check Wireshark Filter Likely CauseOne-way audioSDP c= line IPsip || rtpNAT/SDP IP mismatch32-second dropSession-Expires headersip.Session-ExpiresTimer negotiation failure503 errorGateway status and prefixsip.Status-Code == 503No available gateway408 timeoutFirewall and IP configsip.Status-Code == 408Network unreachableDTMF not workingDTMF mode on gatewaysrtp.eventDTMF mode mismatchRegistration failureCredentials and IPsip.Method == “REGISTER”Wrong password or NAT
Related Resources
VOS3000 SIP 503/408 Error Fix Guide
VOS3000 Echo Delay and Choppy Audio Fix
VOS3000 SIP Call Flow Reference
VOS3000 Call End Reasons Explained
VOS3000 Session Timer 32-Second Drop Fix
VOS3000 Downloads – Manual and Software
Frequently Asked Questions About VOS3000 SIP Debug
How do I enable VOS3000 SIP debug trace?
Navigate to Operation Management > Debug Trace in the VOS3000 client, then click Enable for SIP Trace or Registration Trace. The trace displays real-time SIP messages with full headers and timestamps. Note that enabling debug trace for extended periods on high-traffic servers may impact performance, so disable it after capturing the needed data.
What is the best tcpdump command for VOS3000 SIP debug?
The most useful command for comprehensive debugging is: tcpdump -i eth0 -s 0 -w /tmp/debug.pcap port 5060 or udp portrange 10000-20000. This captures both SIP signaling and RTP media streams. Use the -s 0 flag to capture full packet size, and always specify the correct network interface with -i. For professional help, contact us on WhatsApp at +8801911119966.
How do I diagnose one-way audio in VOS3000 using Wireshark?
Capture SIP signaling during the call, then examine the SDP content in the INVITE and 200 OK messages. Look at the c=IN IP4 line in the SDP. If this IP address is a private address (10.x, 172.16-31.x, 192.168.x) but the server uses a public IP, RTP media is being sent to the wrong address. Fix by configuring the correct Local IP in VOS3000 gateway settings or enabling media proxy mode.
Why do VOS3000 calls drop exactly at 32 seconds?
This is caused by Session Timer negotiation failure. When VOS3000 and the remote gateway cannot agree on session timer parameters, the call drops at the minimum session timer expiry. Check Wireshark for Session-Expires headers and 422 Interval Too Brief responses. The quickest fix is to set SS_SESSION_TIMER to 0 in VOS3000 softswitch parameters to disable session timer entirely.
How do I check DTMF problems in VOS3000?
Capture both SIP and RTP during a call where DTMF is sent. In Wireshark, filter for rtp.event to see RFC 2833 DTMF events, or sip.Method == “INFO” for SIP INFO DTMF. If you see DTMF in one format but the receiving gateway expects a different format, enable DTMF mode conversion in VOS3000 gateway Additional Settings. The most reliable configuration is RFC 2833 on both mapping and routing gateways.
Can I use VOS3000 Debug Trace instead of Wireshark?
VOS3000 Debug Trace shows SIP signaling content but does not capture RTP media streams, provide advanced filtering, or visualize call flows. It is useful for quick checks of SIP headers and message sequences. For comprehensive analysis including one-way audio diagnosis, DTMF debugging, and media path verification, Wireshark with packet capture is necessary. Use both tools together for the most effective debugging workflow.
Get Professional VOS3000 SIP Debug Help
If you are struggling with persistent call failures, one-way audio, or unexplained errors in your VOS3000 deployment, professional debugging assistance can save you hours of frustration and lost revenue. Our team has extensive experience analyzing VOS3000 packet captures, correlating CDR records, and identifying root causes quickly.
Contact us on WhatsApp: +8801911119966
We offer complete VOS3000 troubleshooting services including remote packet capture analysis, CDR investigation, configuration optimization, and permanent error resolution. Whether you need help with a specific call failure or ongoing monitoring and support, we can help ensure your platform operates reliably.
Need Professional VOS3000 Setup Support?
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
WhatsApp: +8801911119966 Website: www.vos3000.com Blog: multahost.com/blog Downloads: VOS3000 Downloads