Ever been on a VoIP call that suddenly goes silent when you put someone on hold? Or worse - the call drops entirely after a few seconds? You’re not alone. These aren’t random glitches. They’re caused by broken Re-INVITE messages and faulty SDP renegotiation - two of the most misunderstood but critical parts of SIP-based VoIP systems.
What Exactly Is a Re-INVITE?
A Re-INVITE is how VoIP systems change a call’s settings while it’s already active. Think of it like adjusting the volume or switching from speakerphone to headphones mid-conversation - except it’s happening at the protocol level. When you press "Hold," your phone doesn’t just pause the audio. It sends a new SIP INVITE message - a Re-INVITE - to tell the other side: "Stop sending media. I’m putting you on hold." This message carries a new Session Description Protocol (SDP) block that describes the media state. For hold, that’s usuallya=inactive. For unhold, it switches back to a=sendrecv. The other side must respond with a matching SDP to keep the call alive. If it doesn’t? The call dies.
Why Does Call Hold Break So Often?
The problem isn’t that Re-INVITEs are complicated - it’s that vendors implement them differently. Cisco, Avaya, Mitel, and open-source tools like SIP.js all follow RFC 3261, but they add their own twists. And those twists break when systems talk to each other. Here’s the classic failure case: Your Cisco CUCM sends a Re-INVITE witha=inactive to put the call on hold. The third-party device - maybe a legacy PBX or a foreign SIP trunk - responds with its own a=inactive in the 200 OK. That’s wrong. It should respond with a=sendrecv because it’s still receiving media (like hold music). But instead, it says, "I’m not sending anything either." Now both sides think the media path is dead. Result? Call drops after 15-22 seconds.
This wasn’t theoretical. Cisco documented this exact issue in 2011 with CUCM versions before 8.5. The fix? A configuration flag: "Send send-receive SDP in mid-call INVITE." Turn that on, and CUCM forces the correct response. But if you’re connecting to a system that doesn’t do this? You’re stuck.
SDP Isn’t Just a Text Block - It’s a Contract
SDP looks like plain text, but it’s a tightly structured agreement between endpoints. Every line matters.a=inactive means "stop all media." a=sendonly means "I’m sending, but not listening." a=recvonly means "I’m listening, but not sending." And a=sendrecv means full duplex - normal call mode.
The problem? Many devices ignore these rules. Some send empty SDP in Re-INVITEs. Others change the port numbers unexpectedly. Others send a=inactive but still send RTP packets - causing one-way audio.
Mozilla ran into this hard with Firefox. In 2015, their WebRTC stack couldn’t handle remote a=inactive properly. Enterprise users couldn’t use hold, transfer, or multi-call features. The fix? Firefox 91, released in September 2021, finally got it right. But until then, businesses had to lock users into Chrome or Opera just to make VoIP work.
Music On Hold? It’s Worse Than You Think
Music On Hold (MOH) is one of the most broken features in VoIP. RFC 7088 was published in 2013 to fix it. It says: when a user is on hold, the system should send a Re-INVITE without any SDP at all. That tells the other side: "Keep sending media - I just can’t receive it right now." But most systems don’t do that. They senda=inactive - which kills the audio stream entirely. So instead of hearing "Your call is important to us," the person on hold hears silence. Then, when they’re unheld, the system sends a new Re-INVITE with a=sendrecv. But if the other side didn’t keep the media path alive? The call drops.
SIP.js, the popular WebRTC library, didn’t support sending Re-INVITEs without SDP until version 0.9.1 in 2015. Even then, it couldn’t receive them. That meant any system using SIP.js couldn’t play MOH properly - unless the other end was Cisco or Avaya. And even then, only if configured right.
Why Your VoIP Provider Keeps Dropping Calls
The 3CX Community forum has dozens of posts from users with the same problem: calls drop during transfers. The fix? Bypass 3CX’s media server. That solves the delay. But then transfers fail with a 481 "Call Transaction Does Not Exist" error. Why? Because when media bypasses the server, the Re-INVITE messages sent during transfer use different contact addresses than what the SIP provider expects. The provider sees a Re-INVITE with a Call-ID that matches the original call - but a From/To tag or Contact header that doesn’t match its internal session map. So it says: "That call doesn’t exist anymore." Cisco CUBE routers have a similar issue. If you’re using a SIP trunk and get one-way audio during hold/unhold, the fix is often simple:midcall-signaling passthru media-change. That tells the router to let Re-INVITEs pass through untouched. If you block them? Media renegotiation fails. If you alter them? Same result.
What You Can Do: A Practical Checklist
You don’t need to be a SIP expert to fix this. Here’s what works in real deployments:- Check your PBX’s Re-INVITE settings. In Cisco CUCM, go to Service Parameters > SIP Profile. Enable "Send send-receive SDP in mid-call INVITE." Restart the CCM service.
- Verify your SIP trunk provider supports RFC 7088. Ask them: "Do you send Re-INVITEs without SDP for Music On Hold?" If they say no, you’ll have silence on hold.
- Test with a SIP analyzer. Use Wireshark or sngrep to capture a Re-INVITE during hold. Look at the SDP. Is it empty? Is it
a=inactive? Is the port number changing unexpectedly? - Update your endpoints. Older phones, softphones, or gateways may not handle Re-INVITEs correctly. Upgrade firmware. Use devices certified for your platform.
- Disable proprietary extensions. Avaya and others use non-standard "Reason" headers in Re-INVITEs. Turn those off. They’re not in RFC 3261. They break interoperability.
- Test with multiple endpoints. Try holding a call between a Cisco phone, a Polycom device, and a WebRTC browser. If one breaks, the issue is SDP mismatch - not the network.
Why This Still Matters in 2026
Even today, 32% of enterprise VoIP outages are tied to mid-call signaling - mostly Re-INVITE and SDP failures, according to Nemertes Research (2022). And with more companies moving to hybrid cloud systems, legacy PBXs talking to cloud SIP trunks, and WebRTC browsers joining the mix, these problems aren’t going away. The good news? Major vendors have improved. Cisco, Mitel, and Oracle now document Re-INVITE configurations clearly. Firefox and Edge support modern SDP handling. WebRTC libraries are catching up. But the bad news? Most IT teams still treat VoIP like a black box. They don’t test hold/unhold during migrations. They don’t check SDP logs. They assume "it works on my desk phone" means it works everywhere. It doesn’t.What’s Next for VoIP Signaling?
The industry is slowly moving toward the UPDATE method - a lighter SIP message designed just for mid-call changes. It’s simpler, faster, and doesn’t require full session renegotiation. Chrome and Edge already support it for WebRTC. But Re-INVITE isn’t going away. Not yet. Every legacy PBX, every SIP trunk, every enterprise phone system still relies on it. And until every endpoint supports UPDATE - and supports it consistently - Re-INVITE remains the most fragile link in the VoIP chain. Your job? Don’t ignore it. Test it. Monitor it. Fix the SDP.Why does my VoIP call drop exactly 22 seconds after I put someone on hold?
This is a classic sign of a failed Re-INVITE renegotiation. When the hold signal is sent with a=inactive SDP, the other side doesn’t respond with the correct media state. The system waits for a media packet or an ACK, and after about 22 seconds - the default SIP timer for session timeout - it gives up and drops the call. This is common with mismatched PBXs or SIP trunks that don’t follow RFC 3261 properly.
Can I use Re-INVITE without SDP for Music On Hold?
Yes - and you should. RFC 7088 recommends sending a Re-INVITE with no SDP at all to indicate "I’m on hold, but keep sending media." This keeps the audio stream alive so hold music plays. Many older systems send a=inactive instead, which kills the media path. Check your PBX or SIP trunk settings for "Music On Hold mode" or "SDP in hold" options and switch to "No SDP" if available.
Why does my call work on Chrome but not Firefox?
Firefox had a bug until version 91 (September 2021) where it didn’t properly handle remote SDP with a=inactive. This blocked hold, unhold, and transfer features in WebRTC apps. If your system relies on Firefox and still has issues, upgrade to version 91 or later. Older versions won’t work with enterprise VoIP systems that use standard Re-INVITE hold signaling.
What’s the difference between a=inactive and a=sendonly in SDP?
a=inactive means both sides stop sending and receiving media - the call is paused. a=sendonly means one side sends media, but doesn’t receive - like a broadcast. In call hold, you want the held party to receive hold music, so the correct state is a=recvonly on their side, or no SDP at all. Sending a=sendonly on the held side is wrong - it would mean they’re sending audio while on hold, which isn’t normal behavior.
Do I need to restart my PBX after changing Re-INVITE settings?
Yes, often. In Cisco CUCM, changing SIP profile settings like "Send send-receive SDP in mid-call INVITE" requires a restart of the Cisco CallManager service. Other systems like Mitel or Avaya may require a reboot or SIP service reload. Always check your vendor’s documentation - some changes are live, but many aren’t.
Can a firewall cause Re-INVITE failures?
Yes, indirectly. Firewalls don’t block Re-INVITEs directly, but they can block the new RTP ports that are negotiated in the SDP. If the Re-INVITE changes the media port from 5004 to 5012, and your firewall doesn’t open that new port, media won’t flow. Make sure your firewall supports SIP ALG (Application Layer Gateway) or, better yet, disable it and use proper port forwarding or a Session Border Controller.
Are there tools to test Re-INVITE behavior?
Yes. Wireshark with SIP filters is the gold standard - you can see every Re-INVITE and SDP change in real time. For quick checks, sngrep (on Linux) gives a clean text view of SIP messages. Some VoIP test platforms like TestRTC or SIPp can simulate Re-INVITE flows and validate responses. Don’t rely on user reports - capture the actual SIP traffic.
Why do transfers sometimes fail with 481 error?
The 481 error means the SIP server can’t find the original call transaction. This often happens during blind transfers when the Re-INVITE used to move the call has mismatched headers - like a different Contact address or From tag - even if the Call-ID is correct. The server sees a Re-INVITE for a call it thinks is gone. Fix it by ensuring your PBX or SBC preserves all session headers during transfer, or by using attended transfer instead.
Vishal Gaur
31 Jan 2026 at 05:33man i swear every time i try to put someone on hold my voip system just ghosts them after 22 seconds. i thought it was my internet till i read this. turns out its the stupid a=inactive mess. my cisco box sends it, some cheap sip trunk replies with the same nonsense, and boom - dead call. i fixed it by flipping that "send send-receive" toggle in the sip profile, restarted ccm, and suddenly hold music actually plays. why is this not default? why does every vendor think they know better than rfc 3261? i hate voip sometimes.