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.
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.
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:
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.
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 Problem |
|---|---|---|
| Via header | Correct IP and port in received/rport | NAT mangling changes real IP |
| Contact header | Reachable IP and port | Private IP in Contact (NAT issue) |
| SDP c= line | Correct media IP address | Wrong IP causes one-way audio |
| SDP m= line | Codec and port match expectations | Codec mismatch or blocked port |
| Session-Expires | Timer values and refresher | 32-second drop from timer mismatch |
| Response time | Delay between INVITE and 100/180 | Slow response indicates network issue |
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.
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 | 📝 Captures |
|---|---|---|
| SIP signaling only | tcpdump -i eth0 -w file.pcap port 5060 | INVITE, 200 OK, BYE, REGISTER |
| Single gateway | tcpdump -i eth0 -w file.pcap host GW_IP | All traffic to/from gateway |
| RTP media only | tcpdump -i eth0 -w file.pcap udp portrange 10000-20000 | Audio media packets |
| Complete analysis | tcpdump -i eth0 -s 0 -w file.pcap port 5060 or udp portrange 10000-20000 | Signaling + media |
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.
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
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/Abnormal |
|---|---|---|
| INVITE | Sent by VOS3000 to gateway | Not sent = routing problem |
| 100 Trying | Received from gateway | Not received = firewall or offline |
| 180 Ringing | Destination is alerting | Skipped = fast answer or error |
| 200 OK | Call answered with SDP | Error code instead = check code |
| ACK | Confirms call established | Missing = call not confirmed |
| BYE | Normal call termination | Unexpected 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.
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.
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.
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.
To diagnose this issue, filter your Wireshark capture for Session-Expires headers and examine the negotiation between VOS3000 and the gateway:
| ⚙️ Parameter | 📋 Default | 📝 Purpose | 🛠️ Fix |
|---|---|---|---|
| SS_SESSION_TIMER | 1800 (30 min) | Session timer duration | Set to 0 to disable |
| SS_SESSION_TIMER_MIN_SE | 90 | Minimum session expires | Lower to 32 or disable timer |
| SS_SESSION_TIMER_REFRESHER | 0 (UAC) | Who sends refresh | Match 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.
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.
Follow these steps to correlate VOS3000 CDR records with Wireshark captures for effective debugging:
| 📋 CDR Termination Reason | 🔍 What to Find in Wireshark | 🛠️ Root Cause |
|---|---|---|
| NoAvailableRouter | No INVITE sent to any gateway | No matching prefix configured |
| InviteTimeout (408) | INVITE sent, no response received | Firewall, wrong IP, or offline gateway |
| AllGatewayBusy (503) | INVITEs sent, 503 or no 200 OK from any | All gateways at capacity or disabled |
| Session timeout | BYE after exactly 32 seconds | Session Timer negotiation failure |
| Normal release | BYE from caller or callee | Normal hangup (not a problem) |
| No media timeout | No RTP packets in one direction | SDP IP mismatch or blocked RTP |
For a complete reference of CDR termination reasons and their meanings, see our VOS3000 call end reasons guide.
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.
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 Failure |
|---|---|---|
| RFC 2833 | RTP event packets (payload 101) | Missing payload type in SDP |
| SIP INFO | SIP INFO messages with Signal | Gateway ignores INFO messages |
| Inband | Audio tones visible in RTP stream | G729 compression destroys tones |
Following a consistent debug methodology reduces troubleshooting time and improves accuracy. These best practices ensure your VOS3000 SIP debug sessions are productive and efficient.
Every time you need to debug a VOS3000 call issue, follow this structured workflow to avoid missing critical information:
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 Cause |
|---|---|---|---|
| One-way audio | SDP c= line IP | sip || rtp | NAT/SDP IP mismatch |
| 32-second drop | Session-Expires header | sip.Session-Expires | Timer negotiation failure |
| 503 error | Gateway status and prefix | sip.Status-Code == 503 | No available gateway |
| 408 timeout | Firewall and IP config | sip.Status-Code == 408 | Network unreachable |
| DTMF not working | DTMF mode on gateways | rtp.event | DTMF mode mismatch |
| Registration failure | Credentials and IP | sip.Method == “REGISTER” | Wrong password or NAT |
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.
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.
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.
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.
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.
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.
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.
For professional VOS3000 installations and deployment, VOS3000 Server Rental Solution:
📱 WhatsApp: +8801911119966
🌐 Website: www.vos3000.com
🌐 Blog: multahost.com/blog
📥 Downloads: VOS3000 Downloads
VOS3000 caller number pool configuration for CLI rotation on outbound calls. Setup random and poll…
VOS3000 protect route configuration guide for smart backup gateway activation. Learn how timer-based failover with…
VOS3000 scaling guide for high-traffic VoIP operations. Proven methods for handling thousands of concurrent calls…
VOS3000 outbound registration setup guide for carrier SIP trunk connections. Configure VOS3000 to register outbound…
Evite perdidas por saldo negativo VOS3000: configure Anti Overdraft, limite de descubierto (limitMoney) y bloqueo…
Configuracion inicial VOS3000 despues de instalar: agregar primer proveedor, crear cuenta SIP, tabla de tarifas…