When a VoIP phone system misbehaves — one-way audio, failed registrations, dropped calls — the instinct is to blame the network or the provider. Sometimes that's right. But before you spend hours going back and forth with support, it's worth knowing that your Yealink handsets have powerful built-in diagnostic tools that can pinpoint the problem in minutes.

This guide covers how to use Yealink's on-phone diagnostics, how to capture packets directly from the handset, and how to open those captures in Wireshark to identify exactly what's going wrong at the SIP signalling and RTP audio level.

Jump to section:

Before you start On-phone diagnostics Web UI diagnostics Packet capture Span to PC port Wireshark: SIP analysis Wireshark: RTP analysis Diagnosing one-way audio Diagnosing dropped calls Diagnosing registration failures Common SIP error codes

Before you start

You'll need:

  • Access to the Yealink phone's web interface (the phone's IP address, plus admin credentials)
  • Wireshark installed on your computer — download it free from wireshark.org
  • The ability to reproduce the problem, or at least a rough idea of when it occurs

These instructions apply to current Yealink T-series (T54W, T53W, T57W, T46U, T43U, T33G) and CP-series (CP925, CP965) handsets running V86 firmware or later. The menu paths are consistent across the range — older firmware may differ slightly.

Find the phone's IP address: Press the OK button (centre of the navigation ring) on most Yealink T-series handsets to display the phone's IP address on screen. You can also find it under Menu > Status > Network on the phone itself.

On-phone diagnostics (no computer needed)

Before reaching for Wireshark, Yealink handsets have built-in network diagnostics accessible directly from the phone's screen. These are useful for quick checks when you're standing next to a phone that's misbehaving.

Ping and traceroute

Navigate to Menu > Features > Diagnostics > Network on the phone. You'll find two tools:

  • Ping — Enter an IP address or hostname (e.g. your SIP server address) and the phone will send ICMP ping packets. This tells you whether the phone can reach the server and how much latency exists. If pings fail, you have a basic network connectivity problem — not a VoIP-specific issue.
  • Traceroute — Enter a destination and the phone traces the network path, hop by hop. Useful for identifying where packets are being dropped or delayed — particularly if you suspect a routing or firewall problem between the phone and the SIP trunk provider.

Phone status screen

The phone's Menu > Status screen shows:

  • Network status — IP address, subnet mask, gateway, DNS servers, VLAN ID
  • Account status — Whether each SIP line is registered, and to which server. If an account shows "Register Failed" here, you know the problem is at the SIP registration level before you even open a packet capture.
  • Firmware version — Important for ruling out known firmware bugs

Web interface diagnostics

The phone's web interface provides more detailed tools. Open a browser and navigate to the phone's IP address (e.g. http://192.168.1.100). Log in with the admin credentials — the default is typically admin / admin, though this should be changed in any production environment.

Syslog configuration

Syslog is the phone's internal event log. For VoIP troubleshooting, you want this set to a useful level before you try to reproduce the problem.

Navigate to Settings > Configuration and configure:

  • Local Log Level — Set to 6 (Informational) for general troubleshooting. This captures SIP signalling summaries, registration events, and call state changes. The default of 3 (Error) only logs failures, which misses the context around them. For full SIP message bodies including SDP and Via headers, set to 7 (Debug) — but be aware this generates significant log volume.
  • Local Log Type — Leave as default unless directed by support
Security note: Syslog level 6 can capture sensitive information including SIP credentials and dialled numbers. Reset the log level to 3 after you've finished troubleshooting.

If you have a syslog server on your network (e.g. a machine running syslog-ng, rsyslog, or a platform like Graylog), you can also send logs remotely:

  • Syslog Server — Enter the IP address of your syslog server
  • Syslog Server Type — UDP (default) or TCP
  • Syslog Level — Set to 6 to match the local log level
  • Syslog Facility — Leave as default (Kernel) unless your server requires a specific value

Capturing packets from the phone

This is the most powerful diagnostic tool built into every Yealink handset. The phone can capture all network traffic passing through it — SIP signalling, RTP audio, DNS, DHCP, everything — and save it as a standard .pcap file that you can open in Wireshark.

Method 1: Capture via the web interface (recommended)

This is the simplest approach. The phone records traffic to its internal memory and you download the file when you're done.

  1. Log in to the phone's web interface
  2. Navigate to Settings > Configuration
  3. Find the Pcap Feature section
  4. Set Pcap Type to Advanced — this captures both signalling and media (RTP). The "Normal" mode captures signalling only, which is insufficient for diagnosing audio problems.
  5. Click Start to begin the capture
  6. Reproduce the problem — make the call, wait for the registration to fail, trigger the one-way audio, whatever the issue is
  7. Click Stop to end the capture
  8. Click Export to download the capture file to your computer

The export produces a file named allconfig.tar which contains the pcap file, the syslog, and a config.bin. Extract the archive — the .pcap file inside is what you'll open in Wireshark.

Keep captures short and focused. The phone has limited memory for packet captures. Start the capture, reproduce the problem once, and stop. A focused 30-second capture of the problem is far more useful than a 10-minute capture of general traffic. If you're diagnosing an intermittent issue that you can't trigger on demand, use the Span to PC method below instead.

Method 2: Span to PC port (for Wireshark live capture)

Yealink phones have two Ethernet ports on the back — Internet (uplink to the network) and PC (passthrough for a computer). The "Span to PC" feature turns the PC port into a mirror port, copying all traffic from the Internet port so you can capture it live in Wireshark on a connected laptop.

This method is better for intermittent issues because you're not limited by the phone's internal memory — Wireshark on your laptop can capture for as long as you need.

  1. Log in to the phone's web interface
  2. Navigate to Network > Advanced
  3. Scroll to the bottom and enable Span to PC Port
  4. Click Confirm
  5. Connect an Ethernet cable from the phone's PC port to your laptop
  6. Open Wireshark on your laptop and select the Ethernet interface connected to the phone
  7. Click Start Capture (the blue shark fin icon)
  8. All traffic passing through the phone's Internet port will now appear in Wireshark in real time
  9. Reproduce the problem, then stop the capture
Remember to disable Span to PC Port when you're finished. Leaving it enabled mirrors all traffic to the PC port, which may have a minor performance impact and is a security consideration — anyone plugging into that port can see the phone's traffic.

Analysing SIP signalling in Wireshark

Once you have a .pcap file (either exported from the phone or captured live via Span to PC), open it in Wireshark. SIP signalling is where you'll find answers to most VoIP problems — registration failures, call setup issues, and the root cause of many audio problems.

Essential SIP display filters

Wireshark's display filter bar (at the top of the window) lets you narrow the view to only the packets you care about:

Filter What it shows
sipAll SIP packets (signalling only, no audio)
sip.Method == "REGISTER"Registration attempts only
sip.Method == "INVITE"Call setup requests
sip.Method == "BYE"Call teardown messages
sip.Status-Code >= 400All SIP error responses
sip.Status-Code == 200All successful responses (200 OK)
sip || rtpBoth signalling and audio streams
ip.addr == 192.168.1.100 && sipSIP traffic to/from a specific phone
sip.Call-ID == "abc123"All messages for a single call (use the Call-ID from any SIP packet)

Using the VoIP Calls view

This is Wireshark's most powerful VoIP feature. Instead of reading individual packets, it reconstructs entire calls and shows them as visual flow diagrams.

  1. Open your pcap file in Wireshark
  2. Go to Telephony > VoIP Calls
  3. Wireshark lists every call it found in the capture — including the caller, callee, start time, and status
  4. Select the call you're interested in
  5. Click Flow Sequence

The flow diagram shows every SIP message exchanged between the phone and the server, in chronological order, drawn as arrows between the two endpoints. This is called a SIP ladder diagram and it's the single most useful view for diagnosing call problems.

What a healthy call looks like

A normal outbound call follows this SIP message sequence:

Phone                          Server
  |                              |
  |------- INVITE ------------->|   Phone initiates the call
  |<------ 100 Trying ----------|   Server acknowledges
  |<------ 180 Ringing ---------|   Remote phone is ringing
  |<------ 200 OK --------------|   Remote phone answered
  |------- ACK ---------------->|   Phone confirms
  |                              |
  |  ~~~ RTP audio flows ~~~    |
  |                              |
  |------- BYE ---------------->|   Phone hangs up
  |<------ 200 OK --------------|   Server confirms

Deviations from this pattern tell you where things broke:

  • INVITE sent but no response at all — Network connectivity issue, firewall blocking UDP 5060, or the server is unreachable
  • INVITE sent, 100 Trying received, but nothing after — The server received the request but can't route the call (check the destination number or trunk configuration)
  • 408 Request Timeout — The server timed out waiting for a response from the next hop
  • INVITE sent, 403 Forbidden — Authentication passed but the server rejected the call (check call permissions, allowed destinations, or toll fraud restrictions)

What a healthy registration looks like

Phone                          Server
  |                              |
  |------- REGISTER ----------->|   Phone requests registration
  |<------ 401 Unauthorized ----|   Server challenges credentials
  |------- REGISTER ----------->|   Phone resends with auth digest
  |<------ 200 OK --------------|   Registered successfully

The initial 401 is normal — it's part of the SIP digest authentication handshake. A problem exists if the second REGISTER also receives a 401 (bad credentials), a 403 (forbidden), or no response at all.

Analysing RTP audio streams in Wireshark

SIP handles the signalling — who's calling whom, ring, answer, hang up. The actual voice audio travels separately as RTP (Real-time Transport Protocol) packets. If calls connect but the audio is bad, missing, or one-directional, RTP analysis is where you'll find the answer.

Finding RTP streams

  1. Open your pcap in Wireshark
  2. Go to Telephony > RTP > RTP Streams
  3. Wireshark lists every RTP stream in the capture, showing:
    • Source / Destination IP and port — Who's sending audio where
    • Payload type — The audio codec (e.g. G.711 = type 0 or 8, G.729 = type 18)
    • Packets — Total packet count
    • Lost — How many packets were lost
    • Max Jitter — The worst jitter measurement in the stream

Analysing stream quality

Select an RTP stream and click Analyze to see detailed per-packet statistics. The key metrics to look at:

Metric Acceptable Problematic
Packet loss< 1%> 3% — audible degradation, gaps in audio
Jitter< 30 ms> 50 ms — choppy audio, robotic voice
Delta (inter-packet gap)~20 ms (for G.711)Spikes above 60 ms indicate network congestion or buffering issues

Playing back captured audio

Wireshark can actually play back the audio from a captured RTP stream:

  1. Go to Telephony > RTP > RTP Streams
  2. Select the stream(s) you want to hear
  3. Click Play Streams
  4. The RTP Player window opens — click the play button to listen

This is extremely useful for confirming what the caller actually heard (or didn't hear). If you can hear audio in the capture but the caller reported silence, the problem is between the capture point and the caller — likely a NAT or firewall issue.

Tip: If Wireshark doesn't recognise the RTP or SIP traffic — sometimes SIP runs on a non-standard port, or RTP traffic isn't automatically decoded. Right-click any packet in the stream and choose Decode As, then select SIP or RTP from the protocol list. Wireshark will re-decode all matching packets on that port.

Diagnosing one-way audio

One-way audio — where one party can hear the other but not vice versa — is the most common VoIP complaint, and packet captures are the definitive way to diagnose it.

Step 1: Check the RTP streams

Go to Telephony > RTP > RTP Streams. For a healthy two-way call, you should see two RTP streams — one in each direction:

  • Stream A: Phone (192.168.1.100:10000) → Server (203.0.113.50:20000)
  • Stream B: Server (203.0.113.50:20000) → Phone (192.168.1.100:10000)

If you only see one stream, RTP is only flowing in one direction. That's your one-way audio confirmed at the packet level.

Step 2: Check the SDP in the INVITE

The root cause of one-way audio is almost always in the SDP (Session Description Protocol) body of the SIP INVITE or 200 OK messages. SDP tells each side where to send its audio.

  1. Filter for sip.Method == "INVITE"
  2. Click on the INVITE packet
  3. In the packet details pane, expand Session Initiation Protocol > Message Body > Session Description Protocol
  4. Look at the Connection Information (c=) line and the Media Description (m=) line

The c= line contains the IP address where this endpoint wants to receive audio. The m= line contains the port number. For example:

c=IN IP4 192.168.1.100
m=audio 10000 RTP/AVP 0 8 18

This tells the remote side: "Send my audio to 192.168.1.100 port 10000."

Step 3: Identify the problem

Private IP in the SDP body — If the c= line shows a private IP (192.168.x.x, 10.x.x.x, 172.16-31.x.x) but the call crosses the internet, the remote side is being told to send audio to an unreachable address. This is the classic SIP ALG or NAT traversal failure. The remote end tries to send audio to a private IP, the packets go nowhere, and you get silence in one direction.

SIP ALG mangling — Compare the SDP in the INVITE as sent by the phone with the SDP in the INVITE as received by the server (if you have captures from both ends). If the IP addresses or ports have been rewritten by something in between, SIP ALG on the router is interfering. The telltale sign is the c= line containing an IP that doesn't belong to either the phone or the server.

Firewall blocking RTP — If the SDP looks correct (public IPs on both sides) but RTP only flows in one direction, a firewall is likely blocking the return traffic. RTP typically uses UDP on high-numbered ports (10000–20000). Check that the firewall allows UDP traffic in both directions on these ports.

Codec mismatch — If the m= lines in the INVITE and 200 OK don't share any common payload types, the endpoints can't agree on an audio format. This usually results in no audio at all rather than one-way audio.

Quick filter to detect SDP with private IPs

If you suspect SIP ALG or NAT traversal is the issue, this Wireshark display filter will find any SIP packet whose SDP body advertises a private address:

sip contains "c=IN IP4 192.168" || sip contains "c=IN IP4 10." || sip contains "c=IN IP4 172.16"

If this filter matches packets captured on the WAN side of your router (or at the SIP server), something has failed to rewrite the private IP to a public one — and one-way audio is virtually guaranteed.

Diagnosing dropped calls

If calls connect and audio works, but calls drop unexpectedly after a fixed time or at random, look at the BYE messages.

  1. Filter for sip.Method == "BYE"
  2. Identify who sent the BYE — was it the phone, the server, or the router?
  3. Check when the BYE was sent relative to the call start. The timing reveals the cause:
    • Exactly 30–60 seconds after call start — Likely a session timer issue. Look for a Session-Expires header in the INVITE or 200 OK. If the phone doesn't support session timers (RFC 4028), the server may terminate the call when the timer expires.
    • Random timing, BYE from the server — The server may have lost contact with the phone. Often caused by a NAT device with a short UDP timeout — if no SIP traffic flows during the call (only RTP on different ports), the NAT mapping for port 5060 expires, and the server can no longer reach the phone.
    • No BYE at all — RTP just stops — A network interruption. Check for ICMP errors around the time audio stopped. Also check whether the phone is sending SIP keepalives (OPTIONS messages) to maintain the NAT pinhole.

Diagnosing registration failures

If a handset shows "Register Failed" on its screen, a packet capture tells you exactly why.

  1. Filter for sip.Method == "REGISTER"
  2. Look at the message sequence:
    • REGISTER → 401 → REGISTER (with auth) → 200 OK — Healthy registration. The 401 is normal (it's the authentication challenge).
    • REGISTER → 401 → REGISTER (with auth) → 401 — Bad credentials. The phone sent a username/password but the server rejected them. Double-check the SIP account credentials on the phone.
    • REGISTER → 401 → REGISTER (with auth) → 403 Forbidden — The credentials may be correct but the account is disabled, locked, or the phone's IP is not whitelisted.
    • REGISTER → (no response) — The server never responded. Either the server is down, the phone can't reach it (DNS failure, firewall, wrong server address), or the packets are being silently dropped.
    • REGISTER → 408 Request Timeout — The server received the request but timed out processing it. Could indicate server overload or a backend routing issue.

If you see no REGISTER packets at all in the capture, the phone isn't even attempting to register. Check that the SIP account is configured (Account > Register Status in the web UI) and that DNS resolution is working (try the ping test from the phone).

Common SIP response codes and what they mean

When you're reading a packet capture, these are the SIP status codes you'll encounter most often:

Code Name What it means
100TryingServer received the request and is processing it. Normal.
180RingingThe destination phone is ringing. Normal.
183Session ProgressEarly media (ringback tone or IVR). Normal.
200OKSuccess — call answered, registration accepted, etc.
401UnauthorizedAuthentication challenge. Normal on first REGISTER — it's how SIP auth works. A problem only if repeated after sending credentials.
403ForbiddenServer understood the request but refuses to fulfill it. Account disabled, IP not allowed, or call destination blocked.
404Not FoundThe destination number or user doesn't exist on the server.
408Request TimeoutNo response from the next hop within the timeout period.
480Temporarily UnavailableThe destination exists but isn't available right now (phone offline, DND enabled).
486Busy HereThe destination phone is busy on another call.
487Request TerminatedThe call was cancelled before it was answered (caller hung up). Normal.
488Not Acceptable HereCodec negotiation failed — no common audio format between the two sides.
500Server Internal ErrorSomething went wrong on the SIP server. Escalate to the provider.
503Service UnavailableThe server is overloaded or in maintenance. Try again later or escalate.

Putting it all together: a troubleshooting workflow

When a VoIP problem is reported, work through these steps in order:

  1. Check the phone's status screen — Is the account registered? What IP does the phone have? Can it ping the SIP server?
  2. Set syslog to level 6 on the phone's web interface
  3. Start a packet capture (Advanced mode) on the phone
  4. Reproduce the problem — make the call, trigger the failure
  5. Stop the capture and export
  6. Open in Wireshark — use Telephony > VoIP Calls to find the relevant call
  7. Read the SIP flow — Does the call set up correctly? Does it fail? At which step?
  8. Check RTP streams — If the call connected but audio was bad, check Telephony > RTP > RTP Streams for loss, jitter, and whether audio flows in both directions
  9. Reset syslog to level 3 when you're done

This process gives you concrete evidence of what's happening on the wire — far more reliable than describing symptoms over email and far faster than waiting for a provider to investigate.

When to send the capture to your provider: If the capture shows that SIP messages are leaving the phone correctly but responses from the server are wrong (5xx errors, missing responses, incorrect SDP), the problem is on the provider's side. Send them the pcap file — any competent VoIP provider can read a Wireshark capture. If you're a Caznet customer, our support team works with packet captures regularly — just send them through.