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:
| Goal | Filter |
|---|
| All SIP | sip |
| Specific call | sip.Call-ID == "abc123@host" |
| SIP INVITE only | sip.Method == "INVITE" |
| SIP errors | sip.Status-Code >= 400 |
| All RTP | rtp |
| SIP + RTP | sip or rtp |
| RFC 2833 DTMF | rtp.p_type == 101 |
| From specific IP | ip.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:
| Field | What to look for |
|---|
Request-URI | Destination SIP address |
From / To | Caller and callee |
Call-ID | Unique call identifier |
SDP → m=audio | Negotiated RTP port and codec list |
SDP → a=rtpmap | Codec payload type mappings (PCMU=0, PCMA=8, G.722=9) |
Step 3: Common Issues
| Symptom | What to check |
|---|
| One-way audio | RTP flowing in only one direction — check both streams |
| No audio | m=audio port is 0 (on hold), or RTP packets absent |
| DTMF not recognized | Payload type mismatch between INVITE SDP and actual RTP |
| Choppy/robotic audio | High jitter or packet loss in RTP streams |
| Call drops unexpectedly | Look for BYE or CANCEL; check SIP response codes (4xx/5xx) |
| Codec mismatch | SDP 200 OK a=rtpmap differs from INVITE |
| SIP auth failure | 401/407 or 403 in SIP flow |
Common SIP Response Codes
| Code | Meaning |
|---|
| 100 | Trying |
| 180 | Ringing |
| 200 | OK |
| 401 / 407 | Authentication required |
| 403 | Forbidden (auth failure or no permission to dial) |
| 404 | Not found (wrong number or SIP URI) |
| 408 | Request timeout |
| 477 | Send failed (TCP/TLS transport error) |
| 486 | Busy |
| 500 | Server internal error |
| 503 | Service unavailable |
| 603 | Decline |
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