Skip to main content

Documentation Index

Fetch the complete documentation index at: https://documentation.uponai.com/llms.txt

Use this file to discover all available pages before exploring further.

PCAP (Packet Capture) files record raw network traffic and are invaluable for diagnosing SIP call issues — codec negotiation failures, audio quality problems, one-way audio, and missed DTMF tones.
PCAP files on the UponAI call details dashboard are only available when data retention is set to Everything and SIP transport is UDP/TCP. TLS transport calls will not have a PCAP.

Prerequisites

Install Wireshark (includes tshark CLI):
wireshark --version
tshark --version

Step 1: Open and Filter in Wireshark

wireshark call_capture.pcap
Useful display filters:
GoalFilter
All SIPsip
Specific callsip.Call-ID == "abc123@host"
SIP INVITE onlysip.Method == "INVITE"
SIP errorssip.Status-Code >= 400
All RTPrtp
SIP + RTPsip or rtp
RFC 2833 DTMFrtp.p_type == 101
From specific IPip.src == 192.168.1.10 and (sip or rtp)

Step 2: Reconstruct the SIP Call Flow

Go to Telephony → VoIP Calls, select the call, then click Flow Sequence to view the full SIP ladder diagram (INVITE → 100 Trying → 180 Ringing → 200 OK → ACK → BYE). Key fields in an INVITE packet:
FieldWhat to look for
Request-URIDestination SIP address
From / ToCaller and callee
Call-IDUnique call identifier
SDP → m=audioNegotiated RTP port and codec list
SDP → a=rtpmapCodec payload type mappings (PCMU=0, PCMA=8, G.722=9)

Step 3: Common Issues

SymptomWhat to check
One-way audioRTP flowing in only one direction — check both streams
No audiom=audio port is 0 (on hold), or RTP packets absent
DTMF not recognizedPayload type mismatch between INVITE SDP and actual RTP
Choppy/robotic audioHigh jitter or packet loss in RTP streams
Call drops unexpectedlyLook for BYE or CANCEL; check SIP response codes (4xx/5xx)
Codec mismatchSDP 200 OK a=rtpmap differs from INVITE
SIP auth failure401/407 or 403 in SIP flow

Common SIP Response Codes

CodeMeaning
100Trying
180Ringing
200OK
401 / 407Authentication required
403Forbidden (auth failure or no permission to dial)
404Not found (wrong number or SIP URI)
408Request timeout
477Send failed (TCP/TLS transport error)
486Busy
500Server internal error
503Service unavailable
603Decline

Analyze RTP Streams

Go to Telephony → RTP → RTP Streams to view each stream with payload type, packet count, packet loss, and jitter.
  • Packet loss >3% or jitter >30ms typically causes degraded or choppy audio.
  • Select a stream → Analyze → Play Streams to hear the actual audio.

DTMF Debugging

Check SDP for RFC 2833 negotiation:
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
Filter RFC 2833 DTMF packets: rtp.p_type == 101 In each matching packet, expand Real-Time Transport Protocol → RFC 2833 RTP Event:
  • Event ID — digit pressed (0–9, *=10, #=11)
  • End of event — true on the final packet
  • Duration — tone duration in RTP timestamp units
SIP INFO DTMF: sip.Method == "INFO" — look for body like Signal=5\nDuration=160

Capture a PCAP

Using tcpdump:
sudo tcpdump -i eth0 -w call_capture.pcap \
  'udp port 5060 or (udp portrange 10000-20000)'
Using tshark (CLI analysis):
# Extract all SIP messages
tshark -r call_capture.pcap -Y sip -T fields \
  -e frame.time -e ip.src -e ip.dst \
  -e sip.Method -e sip.Status-Code -e sip.Call-ID

# List RTP streams with stats
tshark -r call_capture.pcap -q -z rtp,streams

# Extract RFC 2833 DTMF events
tshark -r call_capture.pcap \
  -Y "rtp.p_type == 101" \
  -T fields \
  -e frame.time -e ip.src \
  -e rtpevent.event_id -e rtpevent.end_of_event
Using sngrep (quick SIP terminal view):
brew install sngrep       # macOS
sudo apt install sngrep   # Debian/Ubuntu

sngrep -I call_capture.pcap   # Read from PCAP
sudo sngrep -d eth0 port 5060 # Live capture