VoIP Symptom
RTP Timeout Mid-Call
7 min read · Updated April 2026
RTP timeout mid-call is when audio stops flowing during an established call — SIP signaling is healthy, the dialog is up, but no RTP packets are arriving for some configurable threshold (often 30 or 60 seconds). The PBX or SBC tears down the call. The user hears silence, then a hangup.
1. RTP timeout vs SIP timeout
SIP and RTP are independent. SIP carries signaling (call setup, modifications, teardown) over UDP 5060 or TCP 5060/5061. RTP carries the audio over UDP, usually on dynamically negotiated ports above 10000. Either path can fail without the other.
A SIP timeout means signaling messages are not getting through. The dialog goes stale, OPTIONS keepalives fail, the PBX may attempt to refresh registration. A SIP timeout typically tears down the call after Timer F (32 seconds for INVITE responses) or via session refresh failure.
An RTP timeout means SIP is healthy but audio is gone. The call appears active in the PBX call detail records, but no audio is flowing. Most PBXes and SBCs implement an RTP timeout watchdog that tears down the dialog if no RTP arrives within a threshold — otherwise the call would stay up indefinitely consuming resources after audio failure.
The user experience differs:
- SIP timeout: Call may continue with audio fine, then suddenly drop with no warning. SIP messages were lost, neither side knows the call is broken until the next signaling event.
- RTP timeout: Audio cuts out mid-conversation. The user hears silence for 30 seconds, then the line goes dead. SIP teardown follows the watchdog timer expiry.
2. How RTP timeout is detected
Most VoIP infrastructure watches RTP arrival continuously and triggers teardown when no packets arrive for a configured interval. Defaults vary:
| Platform | Default RTP timeout | Setting |
|---|
| Asterisk | 30 seconds | rtptimeout in pjsip.conf or sip.conf |
| FreeSWITCH | 180 seconds | rtp_timeout_sec in switch.conf.xml |
| Kamailio with RTPEngine | 60 seconds | rtpengine timeout flag |
| AudioCodes SBC | 30 seconds | NoOpEnable / RTPTimeout in ini |
| Cisco CUBE | 60 seconds | ip rtcp report interval / media monitoring |
Some platforms also monitor RTCP, which is the control channel for RTP statistics. RTCP is sparser than RTP (usually one packet every 5 seconds) so RTCP-based timeouts are slower to fire. Most platforms use RTP arrival as the primary signal.
3. Common causes of mid-call RTP loss
Cause 01
NAT pinhole expiry
UDP NAT pinholes expire after a period of inactivity (typically 30 to 300 seconds depending on the firewall). If RTP traffic stops briefly — for example during a hold — the NAT pinhole on the return path may close. When audio resumes, the return packets cannot reach the original endpoint. RTP appears in one direction only, then the watchdog fires.
Cause 02
Path change mid-call
Routing changes during the call (link failover, BGP convergence, ECMP rehash) can change the path RTP takes. If the new path has a different NAT, firewall, or QoS policy, packets may be dropped silently.
Cause 03
Codec change without re-INVITE
If one side changes codec without proper SDP renegotiation, the receiver decodes garbage and may stop processing the stream. Some platforms detect this and tear down the call as if RTP stopped, even though packets are still arriving.
Cause 04
Asymmetric RTP path
If endpoint A sends RTP to one IP/port pair but receives from a different one (because of an SBC or back-to-back media anchor in the middle), and one side of the path fails, RTP timeout fires on the broken direction. The other side may still appear to be sending fine.
Cause 05
SIP ALG mishandling re-INVITEs during hold/unhold
SIP ALG on consumer firewalls often mangles SDP during hold/unhold transitions, leaving the post-unhold media path pointing somewhere invalid. RTP appears to resume but lands on the wrong port, fails to reach the listening socket, and the watchdog fires.
Cause 06
Network congestion
Severe congestion or QoS policy changes can drop RTP completely for a window long enough to trigger timeout. Less common as a cause for sudden total loss; more common as a cause for quality degradation that ends in timeout.
4. NAT pinhole expiry
NAT pinhole expiry is the most common cause of mid-call RTP timeout in real-world deployments. The mechanism:
- Endpoint behind NAT initiates the call and starts sending RTP outbound
- The firewall creates a NAT mapping for the outbound flow with an idle timeout (often 30 seconds for UDP)
- The remote side sends RTP back through the mapping, which keeps it alive
- Either side puts the call on hold, RTP stops
- The NAT mapping idle timer expires
- Call is unheld, RTP resumes outbound from the endpoint, but the return path mapping is gone
- Return RTP is dropped at the firewall, the endpoint times out
The fix is one of three options:
- Send RTP keepalives during hold. Most modern endpoints support this — sending silence or comfort noise packets at low rate keeps the NAT mapping alive. PJSIP exposes
send_keep_alive for this purpose.
- Send a SIP OPTIONS or session refresh before unhold. Useful if the endpoint cannot send RTP keepalives but can refresh signaling.
- Increase the firewall's UDP idle timeout. Set it to 5 minutes or more on the trust boundary handling RTP. This is the cleanest fix when you control the firewall.
5. Asymmetric routing and one-way RTP
Asymmetric RTP is when packets in one direction follow a different network path from packets in the other. This is common with SBCs that anchor media on different IPs for inbound vs outbound, or in multi-hop carrier networks where ingress and egress are separated.
Asymmetric paths are not inherently broken — they work fine as long as both directions stay open. The risk is when one direction fails for a reason that does not affect the other:
- Firewall rule changes only on the inbound path
- BGP convergence affecting only one direction
- NAT mapping expiry on the outbound side while the inbound side is still open
- QoS policy applied only on egress, dropping packets only on the way back
The trace will show RTP arriving in one direction but stopping in the other. The RTP timeout fires on the side that stops receiving. Look for the missing direction first — that is the broken path. The direction still working is the diagnostic clue.
6. Diagnosing RTP timeout from a trace
To diagnose RTP timeout, you need both SIP and RTP visibility. SIP alone tells you the call ended; SIP plus RTP tells you why.
- Was SIP signaling healthy? If SIP messages flowed normally up until BYE, the issue is media-only. If SIP also went silent, the path lost both signaling and media (more likely a network event than RTP-specific).
- Was the BYE preceded by silence? Look at RTP packet timing in the seconds before BYE. A clean call has continuous RTP at the codec's packetization interval (usually 20ms). A timeout has continuous RTP, then nothing for the timeout window, then BYE.
- Was loss symmetric or one-way? If A stops receiving from B but B is still receiving from A, the failure is on the A-direction return path. This narrows the search to the network between B's egress and A's ingress.
- Did the timeout coincide with hold/unhold? Check for re-INVITEs with sendonly/inactive/sendrecv changes near the silence window. NAT pinhole expiry during hold is a frequent cause.
- Were there codec changes? Look for re-INVITEs with different SDP codec lists. Codec mismatch after renegotiation can produce silent decode failures.
- Where did RTP last arrive? If the trace is captured at multiple points (endpoint, SBC, far-end), find the last point where RTP was arriving normally. The break is downstream of that point.
Frequently asked questions
What is RTP timeout in VoIP?
RTP timeout is when audio packets stop arriving for a configured interval (usually 30 to 60 seconds) during an established call, even though SIP signaling is still healthy. The PBX or SBC monitors RTP arrival and tears down the call when no packets are received within the threshold. The user experiences this as audio cutting out mid-conversation, followed by the call dropping.
What is the difference between RTP timeout and SIP timeout?
SIP timeout is when signaling messages fail to get through — the call setup, modification, or teardown messages do not reach the other side. RTP timeout is when audio packets fail to arrive during an active call, even though SIP signaling is healthy. SIP and RTP run on different ports and often through different network paths, so either can fail without the other.
Why does my call drop after putting it on hold?
The most common cause is NAT pinhole expiry. UDP NAT mappings expire after 30 to 300 seconds of inactivity. When the call is on hold, RTP stops flowing, the firewall closes the mapping, and when the call is taken off hold the return RTP path is gone. The fix is to enable RTP keepalive during hold (most modern endpoints support this) or increase the firewall UDP timeout to 5 minutes or more.
Calls dropping silently mid-conversation?
Paste your SIP trace into SIPSymposium. The analyzer identifies RTP timeout patterns, NAT pinhole expiry signatures, and the SIP signaling around media failure events.