This reference lists SIP, SDP, RTP and RTCP indicators that SIP Analyzer detects automatically in PCAP/PCAPNG captures. Search for a familiar symptom: SIP 403 Forbidden, Missing ACK, one-way audio, missing RTP, packet loss, jitter or a media-port negotiation issue.
What a detection means
The service reports an observable fact in the capture and helps locate a suspicious call quickly. It does not replace checking PBX, SBC, firewall, NAT or carrier configuration: the same visible issue can have different root causes. Some cards group warning/critical variants of one signal, so the visible list is shorter than the internal analyzer code list.
01
SIP failures
02
SDP and call setup
03
RTP and one-way audio
04
RTCP reports
These are the phrases engineers commonly use when troubleshooting Asterisk, FreePBX, 3CX, Twilio SIP Trunking and Microsoft Teams Direct Routing. SIP Analyzer does not configure these systems; it identifies capture evidence that makes the next check specific.
When a call connects but audio is one-way or absent, look for a private SDP media address, missing return RTP and a media-port mismatch. In a PJSIP deployment this evidence points the investigation toward external media address, local network, direct media and firewall handling.
If a Twilio call is answered and then ends after roughly 30 seconds, check whether an ACK follows 200 OK and where Contact/Record-Route sends it. For a 403 rejection, separately verify the SIP trunk ACL, credentials and routing.
For silence, choppy voice or one-way RTP on 3CX, a capture distinguishes lost media packets from an incorrect SDP path. An on-premise deployment also warrants checking RTP ports, port preservation, Firewall Checker results and SIP ALG.
When a Microsoft Teams call traverses an SBC but one party cannot hear audio, a PCAP can reveal the advertised SIP/SDP addresses, actual RTP and where media disappears. This is valuable around media bypass, firewalls and complex trunk routes.
Media negotiation failures appear with Asterisk, FreePBX, carrier trunks and SBCs when the sides cannot agree on a codec or SDP parameters. The capture exposes offer/answer details and the exact SIP response.
4xx, 5xx and 6xx responses explain why a request, registration or call was rejected by an endpoint, proxy or gateway.
Analyzer signal: SIP_400
What it means
The server received a SIP message it could not parse, often because a header, URI or SDP body is invalid.
What to check
Compare the request to a successful call and validate required headers and SDP formatting.
Analyzer signal: SIP_401
What it means
The node requires authentication. An initial challenge can be normal, but a final repeated 401 points to credentials or digest handling.
What to check
Check the request following the challenge, username, realm and Authorization header.
Analyzer signal: SIP_403
What it means
The server understood the request but refuses to execute it. Common reasons are ACL rules, destination restrictions, limits or a blocked account/IP.
What to check
Check allowed routes and numbers, IP allowlists, account status and carrier or SBC logs. For Twilio Elastic SIP Trunking, also check ACLs, credentials and the Termination URI.
Analyzer signal: SIP_404
What it means
The requested destination is not known to the responding node, often because of number formatting, routing or registration.
What to check
Check number normalization, dial plan, endpoint registration and selected trunk.
Analyzer signal: SIP_405
What it means
The server is reachable but does not allow the SIP method, such as REGISTER or REFER, at this resource.
What to check
Verify the route target and method support on the PBX, proxy or carrier gateway.
Analyzer signal: SIP_407
What it means
A SIP proxy asks for authentication. The first challenge is often expected; it becomes a problem if the retried request still fails.
What to check
Check the subsequent Proxy-Authorization request and trunk credentials.
Analyzer signal: SIP_408
What it means
The far side failed to answer in time due to routing, firewall, endpoint availability or overloaded infrastructure.
What to check
Look for INVITE retransmissions, network loss and replies from the next hop.
Analyzer signal: SIP_480
What it means
The target cannot currently accept the call, for example because it is unregistered, offline or temporarily unavailable.
What to check
Check endpoint registration, forwarding rules and subscriber status on the PBX or carrier.
Analyzer signal: SIP_481
What it means
A node received a message for a dialog or transaction it no longer recognizes, often because dialog state or routing is out of sync.
What to check
Compare Call-ID, tags and CSeq through the message flow and inspect any SBC/B2BUA.
Analyzer signal: SIP_486
What it means
The called endpoint reports that it is busy. This explains an unsuccessful call but does not by itself indicate a network fault.
What to check
Confirm whether busy status and forwarding or queue behavior were expected.
Analyzer signal: SIP_487 / SIP_487_CANCELLED
What it means
The request ended before call setup completed. When a CANCEL is present, the analyzer marks this as a normal cancellation rather than an independent failure.
What to check
Identify who sent CANCEL and whether it resulted from excessive answer delay.
Analyzer signal: SIP_488
What it means
The remote side cannot accept the offered media parameters, commonly due to codecs, encryption mode or SDP compatibility.
What to check
Compare offer/answer SDP codecs, payload types, encryption and media directions.
Analyzer signal: SIP_491
What it means
Another session modification is already in progress, so a new re-INVITE or UPDATE is temporarily refused.
What to check
Check overlapping re-INVITE/UPDATE requests and the expected retry behavior.
Analyzer signal: SIP_500
What it means
The SIP server could not execute the request because of an internal processing failure.
What to check
Correlate this response with PBX/SBC logs, load and the triggering SIP message.
Analyzer signal: SIP_502
What it means
A proxy or gateway failed while communicating with an upstream SIP node.
What to check
Check the next route segment, trunk health and intermediate SBC logs.
Analyzer signal: SIP_503
What it means
A node temporarily refuses requests because of maintenance, overload, outage or unavailable routing.
What to check
Check Retry-After, provider status, capacity and backup routes.
Analyzer signal: SIP_504
What it means
An intermediary SIP node did not receive a timely response from its next upstream server.
What to check
Find the last responsive hop and check retransmissions and connectivity toward upstream.
Analyzer signal: SIP_603
What it means
The called user or service logic explicitly declined the call rather than merely failing to answer.
What to check
Confirm whether the decline was expected or generated by PBX policy.
Analyzer signal: SIP_606
What it means
The session cannot be accepted with the proposed parameters for any location of the called party.
What to check
Review SDP and media compatibility requirements across both ends of the route.
Analyzer signal: SIP_4xx / SIP_5xx / SIP_6xx
What it means
The analyzer also reports uncommon error codes: 4xx request failures, 5xx server failures and 6xx global failures.
What to check
Use the exact status line and equipment or carrier documentation to interpret a rare code.
These indicators expose incomplete dialogs, failed call establishment and media addressing problems before RTP quality is assessed.
Analyzer signal: MISSING_INVITE
What it means
The collected dialog has no initial INVITE. The capture may have started after the call or include only a session fragment.
What to check
Make sure recording begins before dialing and captures the relevant interface.
Analyzer signal: NO_SDP
What it means
No media description was found in call signaling, so advertised IPs, ports, codecs and RTP streams cannot be matched reliably.
What to check
Check INVITE and 18x/200 OK responses and ensure signaling capture is complete.
Analyzer signal: SDP_PORT_ZERO
What it means
SDP advertises media port zero, normally indicating hold or a temporarily disabled audio direction.
What to check
Review re-INVITE messages before and after hold to distinguish expected silence from stuck media.
Analyzer signal: PRIVATE_IP_IN_SDP
What it means
A side advertised a private address for RTP. Across different NAT networks or the public internet that address may be unreachable and cause no audio.
What to check
Check SBC media anchoring, NAT traversal and actual RTP addresses in the capture. With Asterisk/FreePBX, this is often a reason to check local_net and the external media address.
Analyzer signal: INVITE_RETRANSMISSIONS
What it means
The same INVITE is resent because no timely response arrived, pointing to packet loss, unreachable infrastructure or slow processing.
What to check
Check retransmission direction and timing, firewall behavior and replies for the same CSeq.
Analyzer signal: REINVITE
What it means
Repeated INVITE messages with a new CSeq appear within an existing call. This may be normal hold/resume, but can pinpoint when audio disappeared.
What to check
Compare addresses, ports, codecs and media direction in SDP before and after the re-INVITE.
Analyzer signal: MISSING_ACK
What it means
The caller did not confirm established session setup after 200 OK. A common symptom is a call that never settles or disconnects after roughly 30 seconds.
What to check
Check ACK routing, Contact/Record-Route, NAT and whether 200 OK reaches the caller. With Twilio SIP Trunking, this matches the ACK not received and post-answer call-drop scenario.
Analyzer signal: ELEVATED_SETUP / LONG_SETUP
What it means
INVITE-to-200 OK setup above 5 seconds is marked elevated; above 10 seconds is marked critical.
What to check
Find where signaling stalls: routing, subscriber lookup, carrier processing or endpoint response.
Analyzer signal: NO_INVITE_RESPONSE
What it means
An INVITE exists but no provisional 1xx, successful 2xx or SIP error response appears. Signaling may not arrive, or replies are absent from the capture.
What to check
Check the network route, firewall, SIP transport and the PCAP capture point.
Analyzer signal: NO_BYE
What it means
A call was confirmed, but no BYE termination message was found. The capture may end too early or termination may be abnormal.
What to check
Review recording duration, BYE/CANCEL on both sides and session timers.
Analyzer signal: PRIVATE_IP_IN_SIP_HEADERS
What it means
SIP routing headers contain a private address. Even when SDP is correct, later ACK, BYE or re-INVITE can be routed to an unreachable NAT address.
What to check
Check advertised address, rport, Contact/Via/Record-Route rewriting, SBC topology hiding and SIP ALG.
Analyzer signal: CONTACT_SOURCE_MISMATCH
What it means
An endpoint or PBX advertises a Contact host different from the packet source. This is a common reason for ACK/BYE routing failures.
What to check
Compare Contact with packet source and check external signaling address, NAT mapping, SBC rewriting and SIP ALG.
Analyzer signal: CSEQ_DECREASE / CSEQ_METHOD_MISMATCH
What it means
CSeq decreased or the same CSeq is used by different methods. This points to broken UA/B2BUA behavior, merged dialogs or routing issues.
What to check
Compare CSeq, method, Call-ID and tags in the ladder diagram, then inspect the SBC/B2BUA path.
Analyzer signal: REGISTER_AUTH_LOOP
What it means
The registrar repeatedly challenges REGISTER. The usual causes are wrong credentials, realm, digest/nonce handling or trunk account mismatch.
What to check
Check username, auth username, password, realm, nonce handling, IP ACL and registrar/PBX logs.
Analyzer signal: REGISTER_REJECTED
What it means
Registration receives a final failure such as 403, 404, 423, 500 or 503. The endpoint may not receive inbound calls or the trunk may stay unavailable.
What to check
Check AoR, allowed domain, ACL, Min-Expires for 423, account state and registrar availability.
Analyzer signal: MISSING_PRACK
What it means
A provisional response requires reliable delivery with PRACK, but PRACK is not found. Call setup or early media can stall.
What to check
Verify PRACK/100rel support on the endpoint, Asterisk/FreePBX/3CX, SBC and carrier SIP trunk.
Analyzer signal: PRACK_REJECTED
What it means
PRACK is present but receives an error response, so the reliable provisional response is not acknowledged correctly.
What to check
Check RAck/RSeq, route set, PRACK CSeq and 100rel support on both sides.
Analyzer signal: EARLY_MEDIA_NO_RTP
What it means
The remote side advertises early media with 183 SDP, but RTP does not appear before 200 OK. Ringback, IVR or announcements may be silent.
What to check
Check RTP routing before answer, firewall/NAT handling for early media and carrier/SBC behavior.
Analyzer signal: PROVISIONAL_SDP_CHANGED
What it means
Multiple 180/183 responses contain different media address, port, codec or direction. This helps locate ringback or early audio failures.
What to check
Compare 18x SDP and identify whether a carrier, SBC, announcement server or PBX changes the media path.
Analyzer signal: SDP_CONNECTION_ZERO
What it means
The SDP connection address is zero. This is an old hold/media-disable mechanism and can look like missing audio.
What to check
Check hold/resume re-INVITEs and confirm that a real media address returns after resume.
Analyzer signal: SDP_INACTIVE / SDP_DIRECTION_ONE_WAY
What it means
SDP explicitly restricts media direction. Silence or one-way audio may be expected during hold, mute or announcements.
What to check
Correlate the direction attribute with the user complaint and re-INVITE/UPDATE timing.
Analyzer signal: SDP_NO_COMMON_CODEC
What it means
Offer and answer have no common voice codec. Sometimes this is visible even without 488 Not Acceptable Here: signaling continues but media is incompatible.
What to check
Compare allowed codec lists, transcoding policy and G.729/G.722/Opus settings on PBX/SBC.
Analyzer signal: SDP_DYNAMIC_RTPMAP_MISSING
What it means
Payload types 96-127 require a=rtpmap. Without it the receiver cannot know which codec a dynamic RTP payload type uses.
What to check
Fix SDP normalization on the PBX/SBC or add the correct a=rtpmap for the dynamic PT.
Analyzer signal: DTMF_NOT_NEGOTIATED
What it means
SDP does not include telephone-event. IVR digits, PIN entry and post-dial DTMF may fail across the SIP trunk.
What to check
Check RFC2833/RFC4733 telephone-event in offer/answer and DTMF mode on the PBX, endpoint and trunk.
Analyzer signal: SDP_IP_VERSION_MISMATCH
What it means
The dialog SDP mixes IPv4 and IPv6 media addresses. This can break media when dual-stack support or SBC rewriting is incomplete.
What to check
Check IPv4/IPv6 media reachability, NAT64, DNS/transport policy and SBC rules.
These checks cover no audio, one-way audio and audible speech defects: loss, gaps, jitter and differences between negotiated SDP and actual media.
Analyzer signal: RTP_NOT_FOUND
What it means
The call advertised media ports through SDP, but no matching RTP packets were found. This matches no-audio cases or a SIP-only capture.
What to check
Check NAT/firewall, media IP/ports, the capture point and whether RTP takes another path.
Analyzer signal: ONE_WAY_RTP
What it means
RTP is visible from only one call side. In practice this often appears as one-way audio where one participant cannot hear the other.
What to check
Check the return media path, NAT, ACL/firewall and the SDP address for the silent side. This PCAP is especially useful when diagnosing Asterisk/FreePBX, 3CX and an SBC for Teams Direct Routing.
Analyzer signal: MULTIPLE_RTP_SOURCES
What it means
A call contains RTP from more than two addresses. This can represent conferencing, transfer, a media relay or an unexpected path change.
What to check
Map each address to re-INVITE, conference behavior and SBC/media server nodes.
Analyzer signal: RTP_PAYLOAD_TYPE_MISMATCH
What it means
An RTP stream uses a payload type missing from SDP `m=audio` or `a=rtpmap`; the receiver may decode it incorrectly or discard media.
What to check
Compare each RTP payload type with offer/answer SDP and transcoding configuration.
Analyzer signal: RTP_UNKNOWN_SOURCE
What it means
Media arrives from an address not listed in SDP. NAT or media relay can make this normal, but it matters when tracing the media path.
What to check
Identify whether the address belongs to an SBC/proxy and whether symmetric RTP is expected.
Analyzer signal: SDP_RTP_PORT_MISMATCH
What it means
RTP is sent to a port the endpoint did not advertise in SDP. Such media-port mismatch can produce one-way or entirely missing audio.
What to check
Check SDP rewriting on NAT/SBC devices and actual RTP targets after re-INVITE.
Analyzer signal: RTP_LOSS / RTP_CRITICAL_LOSS
What it means
Loss above 1% is marked as a warning and above 5% as critical. Missing voice packets cause word dropouts, clicks and silence fragments.
What to check
Check congestion, QoS, the affected IP-to-IP direction and loss in each side of the call.
Analyzer signal: RTP_ELEVATED_INTERVAL / RTP_CRITICAL_INTERVAL
What it means
Voice packets usually arrive about every 20 ms. Average interval above 25 ms is flagged and above 40 ms is critical.
What to check
Validate packetization settings, loss and capture completeness before diagnosing network quality.
Analyzer signal: RTP_GAP / RTP_CRITICAL_GAP
What it means
A maximum gap above 100 ms is flagged; above 500 ms is a critical media interruption that may sound like silence.
What to check
Locate the gap in playback and correlate it with network events, transfer or re-INVITE.
Analyzer signal: RTP_JITTER / RTP_CRITICAL_JITTER
What it means
Average jitter above 15 ms is a warning and above 30 ms is critical. Uneven delivery makes jitter buffering harder and degrades speech.
What to check
Review the high-jitter direction, network load, queues and RTP QoS.
Analyzer signal: RTP_PEAK_JITTER / RTP_CRITICAL_PEAK_JITTER
What it means
Peak jitter above 50 ms is high and above 100 ms is critical. A single spike can be heard even when average quality looks healthy.
What to check
Correlate the spike with route changes, burst loss or device congestion.
Analyzer signal: RTP_OUT_OF_ORDER
What it means
A meaningful portion of packets violates stream sequence. A jitter buffer may repair some order, but severe reordering causes artifacts.
What to check
Check multipath routing, load balancing and sequence numbers for the affected SSRC.
Analyzer signal: RTP_DUPLICATES
What it means
The stream contains duplicated RTP packets. This can be a capture artifact or indicate packet duplication in the network.
What to check
Rule out SPAN/mirror duplication and compare with a capture taken at an endpoint.
Analyzer signal: RTP_SSRC_CHANGED
What it means
One media direction uses multiple SSRC values. This can be normal during hold, transfer or transcoding, but often explains artifacts or recording issues.
What to check
Correlate the SSRC change with re-INVITE, transfer, media relay, transcoder or recorder behavior.
Analyzer signal: RTP_TIMESTAMP_JUMP / RTP_TIMESTAMP_REGRESSION
What it means
Timestamp should grow consistently with the codec clock. Sharp jumps or regressions point to sender clock, RTP proxy, transcoder or recorder issues.
What to check
Check the RTP timestamp timeline, gap markers, hold/transfer events and the device changing media.
Analyzer signal: RTP_SEQUENCE_RESET
What it means
Sequence number resets while SSRC remains the same. For continuous RTP this is suspicious and can disrupt jitter buffers or recording.
What to check
Check sender restart, RTP proxy, transcoder and capture stitching.
Analyzer signal: RTP_LATE_START
What it means
The call has answered with 200 OK, but RTP appears after a noticeable delay. The user may hear initial silence.
What to check
Check endpoint media start, NAT pinhole, firewall, SBC anchoring and the first RTP packet after ACK.
Analyzer signal: RTP_AFTER_BYE
What it means
The SIP dialog ended with BYE, but RTP continues. This points to delayed media relay cleanup or an incorrectly closed session.
What to check
Check BYE delivery, RTP timeout, media relay/SBC cleanup and the capture point.
Analyzer signal: RTP_PAYLOAD_TYPE_CHANGED
What it means
One SSRC uses multiple payload types. Without matching re-INVITE/UPDATE the receiver may decode part of the stream incorrectly.
What to check
Compare the PT change with SDP renegotiation and PBX/SBC transcoding policy.
RTCP Receiver Reports reveal the quality observed by a receiver, even when the locally captured RTP stream appears healthy.
Analyzer signal: RTCP_RECEIVER_LOSS / RTCP_RECEIVER_CRITICAL_LOSS
What it means
Receiver Report loss above 1% is flagged and above 5% is critical, confirming degradation on the path toward the receiving endpoint.
What to check
Compare the report to local RTP; the problem can be downstream of the capture point.
Analyzer signal: RTCP_RECEIVER_JITTER / RTCP_RECEIVER_CRITICAL_JITTER
What it means
Receiver jitter above 15 ms is flagged and above 30 ms is critical. The remote user may hear defects not obvious in a local trace.
What to check
Investigate the path toward the receiver, its jitter buffer and differences from local RTP metrics.