Fix ERROR_CTX_MODEM_RESPONSE_BUSY 0X00001B67 on Windows

Quick answer

Check the callback number configured on the server — it's likely missing a prefix (like 9 for an outside line) or has an extra digit. If that's clean, reduce the modem's callback wait time to 5 seconds.

What's going on here

This error pops up on Windows Server 2003, 2008, and even XP when a remote access server tries to call back a client and gets a busy signal. The root cause? The modem dialed a number that's already in use — either because the client's line is still connected from the initial call, the callback number has a wrong area code, or the modem isn't waiting long enough before redialing. I've seen this most often in old-school RAS (Remote Access Service) setups with external modems on Windows Server 2003. It's not common today, but when it hits, it's a headache.

Step-by-step fixes

1. Verify the callback number on the server — Open Routing and Remote Access (RRAS) or the user's Dial-in properties. Look for the callback number under the user account. Make sure it includes any required prefixes (like 9, for an outside line) and has the correct area code. A common mistake: storing the number with a leading 1 when the modem doesn't need it.
2. Adjust modem initialization string — Open the modem's properties in Device Manager, go to the Advanced tab, and add X3 to the extra initialization commands. This tells the modem to ignore busy signals during dial-out and just try the call anyway. On some US Robotics modems, ATX3 does the trick.
3. Increase the callback wait time — In the modem's advanced settings, look for “Callback wait time” or “Wait for dial tone before callback.” Set it to 5 seconds minimum. If it's too short, the modem redials before the client's line drops.
4. Check the phone line — Swap in a known-good phone line. Plug an analog phone into the same jack and listen for a dial tone. If you hear static or no tone, call the telco.
5. Update or roll back the modem driver — Old Conexant or Lucent modems hate Windows 2008. Try the latest driver from the vendor's site. If you just updated, roll back — I've seen driver updates break TAPI callback timing.

When the main fix doesn't work

If the callback number is correct and the modem still hits busy, try these:

• Disable callback entirely — Set the user account to “No callback” in RRAS. This lets the connection use the initial call without redialing. Not ideal security-wise, but it bypasses the issue.
• Switch to a different modem — Some modems (like the old Hayes Accura) handle staggered callbacks poorly. Replace it with a US Robotics 56K external — they're rock solid for RAS.
• Change the dialing rules in the registry — Under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\Parameters, add a DWORD CallbackWaitTime and set it to 5 (seconds). Reboot.
• Test with a direct dial — From a separate phone, manually call the callback number. If you get a busy signal, the number's wrong or the line's dead. If it rings, the modem's timing is off.

Prevention tips for next time

Always test callback with a real modem on the bench before deploying. Simulate a dial-out to the client's number while the client is still connected — that's exactly when this error shows up.

To avoid this in production, set a fixed callback number per user and never use “Set by caller” unless you trust the phone lines. Also, document every modem's initialization string — different modems need different X commands. Stick with one modem model across your RAS pool.