Hi everyone,
We’re encountering an intermittent issue where Asterisk tries to connect a call to an agent using JsSIP (WebSocket client), but the JsSIP side responds with “405 Method Not Allowed”.
This happens only after short network interruptions — when the socket disconnects and reconnects. It does not reproduce in our local setup.
Here’s a typical pattern from our logs:
- Call started - 08:48:14
- our internal socket disconnect on - 08:49:14
- socket enter on - 08:49:33 (19s gap)
- Encountered 405 on - 08:49:35 (Asterisk attempted to call agent)
- “Internet Connectivity is back” logged at - 08:49:39
- ua.stop() performed, JsSIP UA tries reconnect (every 10s for 30s)
- Reconnected to SIP - 08:49:46
- New call at - 08:49:46 → Works fine
Similar behavior repeats at other times — every time the JsSIP UA reconnects after a socket drop, the first inbound INVITE from Asterisk gets rejected with 405 from the browser side.
Key points:
-
JsSIP version: 3.8.0
-
Connection: WSS → Asterisk (using SIP over WebSocket)
-
UA logic: when network disconnects, when we get a registration failed / unregister, we check for the internet on intervals of 10seconds and If got connected perform ua.stop and invoke a fresh ua.
It seems JsSIP may be in an invalid or partially reinitialized state during reconnect — possibly still cleaning up the previous session — so it responds 405 to inbound INVITEs until it’s fully ready.
Questions:
-
Under what conditions does JsSIP respond with 405 Method Not Allowed to an incoming INVITE?
-
Could calling
ua.stop()followed quickly byua.start()lead to a race where the UA is not yet ready to accept calls? -
Is there a recommended sequence or delay between UA stop/reconnect to ensure it properly re-registers before Asterisk sends new calls?
-
Any best practices for handling JsSIP recovery after short WebSocket disconnects to avoid transient 405s?
Appreciate any insights or examples from others who’ve faced similar JsSIP reconnect issues.