Current Location ：
Packet Capture for Voice Troubleshooting: A Practical Method
A capture is the closest thing voice engineering has to ground truth. Logs record what the platform believed; a capture records what crossed the wire. The trouble is that captures are easy to take badly: the wrong interface, the wrong window, or a file so large that the interesting two seconds are buried in four hundred megabytes. This article sets out a method that produces an answer quickly, and describes the placement decisions that determine whether the capture will be useful at all.
Decide the Question Before You Capture
A capture taken because something is wrong will contain mostly evidence that something is not wrong. Starting from a specific question narrows the filter and the window. Is the call reaching the platform at all. Is the audio leaving in both directions. Is the endpoint receiving what was sent. Each question implies a different capture point, and answering them in order usually locates the fault within two captures rather than six.
| Question | Where to capture | What to look for |
|---|---|---|
| Did the call arrive at the platform | Platform-side interface, mirrored span | INVITE with a matching Call-ID |
| Was the call answered | Same point as above | 200 OK and the ACK that follows |
| Is media flowing both ways | Between the two legs | RTP packets in both directions with increasing sequence numbers |
| Is the endpoint receiving audio | Endpoint-side port mirror | Inbound RTP with plausible timestamps |
| Where is delay introduced | Two points, timestamps compared | Gap between send time and arrival time |
Placement Decides Everything
The most common failure is capturing at a point where both the fault and the evidence are absent. Capturing on a server that is not in the media path proves only that the server is not involved. Mirroring the port of a phone shows what that phone received, not what the network dropped before it arrived. Two captures, one on each side of the suspected fault, convert a guess into a measurement: if packets leave one point and do not arrive at the other, the path between them is the problem.
- Capture on a mirror or span port, not by running software on a busy server
- Limit the capture to the endpoints in question using a filter on their addresses
- Include signalling and media in the same capture so they can be correlated
- Record the clock source at each capture point; unsynchronised clocks make comparison meaningless
- Note the time of the call precisely, so the capture can be aligned with platform logs
Reading Signalling and Media Together
Signalling tells you the negotiation: which addresses and ports were agreed, which codec was chosen, and whether the acknowledgement completed. Media tells you whether the agreement was honoured. A capture where the 200 OK advertises a private address, and media never arrives at the far end, is a NAT problem with a signature. A capture where media arrives with sequence numbers jumping indicates loss on the path. Reading one without the other produces theories; reading both produces a diagnosis.
Common Traps
Encrypted signalling hides exactly what you wanted to see, so capture before enabling transport encryption when you expect to troubleshoot, or accept that you will rely on platform-side logging instead. Offloaded checksums and truncated packets make analysis misleading unless the capture tool is configured to handle them. And a capture taken during a quiet period will not reproduce a fault that only appears under load, which is why the timing matters as much as the placement.
Redstone Approach
Redstone support engagements use a structured capture process: define the question, capture at two points, correlate signalling with media, and document the finding. Where encryption prevents inspection, we work from platform-side call detail and endpoint-reported metrics instead, and we say clearly which evidence the conclusion rests on.
Redstone Systems, Inc. founded in Delaware, USA in December 2002, has been the ODM vendor for many well-known communications companies, serving the Southeast Asian market. In 2020, Redstone Systems will begin to return to the North America market with its self-developed brand.
Redstone has a complete product line of intelligent voice gateways, providing IP-PBXs, analog VoIP gateways (FXS/FXO), digital VoIP gateways (E1/T1), border appliances, and session boundary controllers (SBCs).
With advanced technology in digital signal processor (DSP), speech coding and speech processing, as well as efficient operational tools such as cloud remote management, auto provisioning, Redstone gateways are widely used in markets of enterprise communications, cloud communications, call centers, operators’ IMS/SIP trunks, bringing users friendly, efficient and reliable communication experience.
For more information about Redstone, You can follow us on Facebook, Linkedin, and Youtube to be the first to get the latest news.
