Sangoma Desktop Intermittent 503 Unauthorized response from PBX

I have a large number (50+) Sangoma desktop apps on this deployment. Everything module is up to date from Stable rep and Debian is fully updated. Apps are running the latest version, 4.2.0.

Apps will randomly become unreachable, then reachable again sometimes (other times they have to be manually reconnected). I turned sip debug on and I’m seeing normal looking sip options traffic to and from these apps WHILE asterisk shows they are Unavailable. Here is an example check in from an app that is responded to by the PBX

[2026-01-21 14:45:01] VERBOSE[183725] res_pjsip_logger.c: <— Received SIP request (786 bytes) from WS:127.0.0.1:44348 —>
OPTIONS sip:[email protected]:6443 SIP/2.0^M
Via: SIP/2.0/WSS 5jl9marrq5ig.invalid;branch=z9hG4bK3075457^M
Max-Forwards: 69^M
To: sip:[email protected]:6443^M
From: sip:[email protected]:6443;tag=f3e99pmits^M
Call-ID: jaoii0ubhaj3cd7fgova^M
CSeq: 6838 OPTIONS^M
Authorization: Digest algorithm=MD5, username=“98182”, realm=“asterisk”, nonce=“1769024701/ba2f76dad18ded45aa13a7912d05fb20”, uri=“sip:[email protected]:6443”, response=“5c20bc4db570535ea701ad38f693a54a”, opaque=“2b4fa6216ab47e31”, qop=auth, cnonce=“v87d0ua45rlk”, nc=00000001^M
Content-Type: application/sdp^M
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY^M
Supported: outbound^M
User-Agent: Sangoma Windows Softphone 4.2.0^M
Content-Length: 0^M

[2026-01-21 14:45:01] VERBOSE[183725] res_pjsip_logger.c: <— Transmitting SIP response (826 bytes) to WS:127.0.0.1:44348 —>
SIP/2.0 200 OK^M
Via: SIP/2.0/WSS 5jl9marrq5ig.invalid;rport=44348;received=127.0.0.1;branch=z9hG4bK3075457^M
Call-ID: jaoii0ubhaj3cd7fgova^M
From: sip:[email protected];tag=f3e99pmits^M
To: sip:[email protected];tag=z9hG4bK3075457^M
CSeq: 6838 OPTIONS^M
Accept: application/sdp, application/xpidf+xml, application/cpim-pidf+xml, application/pidf+xml, application/dialog-info+xml, application/simple-message-summary, application/simple-message-summary, application/pidf+xml, application/dialog-info+xml, message/sipfrag;version=2.0^M
Allow: OPTIONS, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INFO, REFER^M
Supported: 100rel, timer, replaces, norefersub^M
Accept-Encoding: identity^M
Accept-Language: en^M
Server: FPBX-17.0.24(22.7.0)^M
Content-Length: 0^M

The Sangoma desktop app logs show a “503 service unavailable” response from the PBX but I don’t see any corresponding errors in the asterisk log or rtapi log:

error [2026-01-21T17:34:09.837Z]: Failed to receive the response of SIP OPTIONS heartbeat message from SIP server - CAUSE: SIP Failure Code. Not reloading app, continuing with the process
error [2026-01-21T17:34:09.838Z]: {
originator: ‘remote’,
response: {
data: ‘SIP/2.0 503 Service Unavailable\r\n’ +
‘Via: SIP/2.0/WSS ag689gor6u5h.invalid;rport;received=127.0.0.1;branch=z9hG4bK7038036\r\n’ +
‘Call-ID: 27gjoeqrl2235c1flu1r\r\n’ +
‘From: sip:[email protected];tag=e2k77cbchr\r\n’ +
‘To: sip:[email protected];tag=z9hG4bK7038036\r\n’ +
‘CSeq: 7552 OPTIONS\r\n’ +
‘Server: FPBX-17.0.24(22.5.2)\r\n’ +
‘Content-Length: 0\r\n’ +
‘\r\n’,
headers: {
Via: [
{
raw: ‘SIP/2.0/WSS ag689gor6u5h.invalid;rport;received=127.0.0.1;branch=z9hG4bK7038036’,
parsed: {
protocol: ‘SIP’,
transport: ‘WSS’,
host_type: ‘IPv4’,
host: ‘ag689gor6u5h.invalid’,
received: ‘127.0.0.1’,
branch: ‘z9hG4bK7038036’
}
}
],
‘Call-ID’: [
{ raw: ‘27gjoeqrl2235c1flu1r’, parsed: ‘27gjoeqrl2235c1flu1r’ }
],
From: [
{
raw: ‘sip:[email protected];tag=e2k77cbchr’,
parsed: { _uri: [Object], _parameters: [Object] }
}
],
To: [
{
raw: ‘sip:[email protected];tag=z9hG4bK7038036’,
parsed: { _uri: [Object], _parameters: [Object] }
}
],
CSeq: [
{
raw: ‘7552 OPTIONS’,
parsed: { value: 7552, method: ‘OPTIONS’ }
}
],
Server: [ { raw: ‘FPBX-17.0.24(22.5.2)’ } ],
‘Content-Length’: [ { raw: ‘0’, parsed: 0 } ]
},
method: ‘OPTIONS’,
via_branch: ‘z9hG4bK7038036’,
call_id: ‘27gjoeqrl2235c1flu1r’,
cseq: 7552,
from_tag: ‘e2k77cbchr’,
to_tag: ‘z9hG4bK7038036’,
body: ‘’,
sdp: null,
status_code: 503,
reason_phrase: ‘Service Unavailable’
},
cause: ‘SIP Failure Code’
}

It is happening across multiple locations all with different to no firewalls.

I’m completely lost on this one.

1 Like

I think may be there is a misconfiguration of asterisk on the machine. Some SIP Options responses from the Freepbx deployment respond with 503 Service Unavailable and the Server in this case is FPBX-17.0.24(22.5.2) whereas the server when a 200 Ok is sent is FPBX-17.0.24(22.7.0). Asterisk v22.7.0 is what is installed on the machine.

[2026-01-21 11:02:22] VERBOSE[172111] res_pjsip_logger.c: <— Received SIP request (491 bytes) from WS:127.0.0.1:50548 —> OPTIONS sip:[email protected]:6443 SIP/2.0^M
Via: SIP/2.0/WSS cqa7qosdhkmm.invalid;branch=z9hG4bK50134^M
Max-Forwards: 69^M To:
sip:[email protected]:6443^M
From: sip:[email protected]:6443;tag=b3j44h1kke^M
Call-ID: gtughmdt3t6lcujateqe^M
CSeq: 4020 OPTIONS^M
Content-Type: application/sdp^M
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY^M
Supported: outbound^M
User-Agent: Sangoma Windows Softphone 4.2.0^M
Content-Length: 0^M
^M

[2026-01-21 11:02:22] VERBOSE[172111] res_pjsip_logger.c: <— Transmitting SIP response (342 bytes) to WS:127.0.0.1:50548 —>
SIP/2.0 503 Service Unavailable^M
Via: SIP/2.0/WSS cqa7qosdhkmm.invalid;rport;received=127.0.0.1;branch=z9hG4bK50134^M
Call-ID: gtughmdt3t6lcujateqe^M
From: sip:[email protected];tag=b3j44h1kke^M
To: sip:[email protected];tag=z9hG4bK50134^M
CSeq: 4020 OPTIONS^M
Server: FPBX-17.0.24(22.5.2)^M
Content-Length: 0^M

In case anyone else runs in to this, downgrading from asterisk v22 to v20 fixed the issue. I ran in to a similar issue with FreePBX v16: downgrading from asterisk v20 to v16 fixed that one. I have no idea how this makes sense, but the results are undeniable.

Asterisk will send a 503 Service Unavailable in this scenario if it believes it is overloaded and PJSIP is configured to react accordingly (the option is taskprocessor_overload_trigger in pjsip.conf). An Asterisk log would better show what is happening, and newer versions of Asterisk also reduce/eliminate some of the overloads.

Thank you for the response @jcolp!

What should I be looking for in the logs?

I am seeing apparent errors around the word “task” in the logs, especially “call task pushed”. This machine has a large queue with 15-20 extensions that ring simultaneously for all incoming calls (2-300/day). The log is debug 4 so it’s massive. Below is a grep for 1) “task” and 2) both “Contact” and “is now Unreachable”. The idea was to look for a timestamp correlation between task errors and Contacts becoming Unreachable.

It does appear there are load issues on the machine. Do these logs reflect that in your opinion?

[2026-01-22 11:23:08] DEBUG[343805] taskprocessor.c: Taskprocessor ‘stasis/m:manager:core-0000000d’ cleared the high water alert.
[2026-01-22 11:23:26] DEBUG[556490][C-0000079a] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:27:53] DEBUG[557336][C-000007c2] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:28:46] DEBUG[557561][C-000007ca] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:28:54] DEBUG[557581][C-000007cf] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:30:01] DEBUG[557812][C-000007de] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:30:10] DEBUG[557954][C-000007e1] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:31:02] DEBUG[558144][C-000007e8] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:31:02] DEBUG[558142][C-000007e8] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:33:05] DEBUG[558606][C-000007f7] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:33:15] DEBUG[558624][C-000007fa] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:34:12] DEBUG[558803][C-00000803] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:34:14] DEBUG[558832][C-00000806] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:34:56] WARNING[558886][C-0000080d] taskprocessor.c: The ‘stasis/m:manager:core-0000000d’ task processor queue reached 3000 scheduled tasks again.
[2026-01-22 11:34:56] DEBUG[558886][C-0000080d] taskprocessor.c: Taskprocessor ‘stasis/m:manager:core-0000000d’ triggered the high water alert.
[2026-01-22 11:34:56] DEBUG[558943][C-0000080d] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:35:17] DEBUG[559121][C-00000814] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:37:25] DEBUG[559702][C-00000839] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:37:25] DEBUG[559743][C-00000839] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:37:27] DEBUG[343805] taskprocessor.c: Taskprocessor ‘stasis/m:manager:core-0000000d’ cleared the high water alert.
[2026-01-22 11:38:19] DEBUG[559933][C-00000846] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:40:54] DEBUG[560459][C-0000085f] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:41:11] VERBOSE[549857] res_pjsip/pjsip_options.c: Contact 98173/sip:[email protected]:32856;transport=WS;x-ast-orig-host=p77afie9imvu.invalid:0 is now Unreachable. RTT: 0.000 msec
[2026-01-22 11:42:06] DEBUG[560789][C-0000086e] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:46:24] DEBUG[561876][C-00000887] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:46:24] DEBUG[561897][C-00000887] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:46:37] DEBUG[561938][C-0000088a] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:47:05] DEBUG[562075][C-0000088f] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:49:19] DEBUG[562583][C-0000089e] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:50:28] DEBUG[562880][C-000008ab] chan_pjsip.c: ‘call’ task pushed
[2026-01-22 11:52:25] DEBUG[563293][C-000008be] chan_pjsip.c: ‘call’ task pushed

That would cause the 503 behavior during the time it is in alert. I do believe that behavior is configurable in PJSIP, though I don’t know where.

Newer versions of Asterisk have also improved performance.

@jcolp This was on asterisk 22.5.2, the latest LTS version the asterisk installer on FreePBX supports. Are there performance improvements after this version I can look forward to?

I did some more digging and it appears the task processorstasis/m:manager:core-0000000d
had Max Depth = 22986 since last restart. So it seems AMI is the biggest offender. “Manager Show Connected” show’s multiple “SszaOLcgDCBV” users (which apparently is FreePBX), Freepbx firewall, and 6 Sangoma real-time API users. So unless I’m missing something, which is entirely possible, I am running a clean production system. Does this indicate it is under-resourced?

Newer versions do have improvements, though not in that specific area but I’ve seen the other performance improvements have a knock-on effect and help elsewhere. A max depth of 22986 is huge. It could be under-resourced, I can’t say for certain as FreePBX is not my thing and how fast it handles events impacts that queue, along with what they are. I can just explain the Asterisk side.

@jcolp I appreciate your weighing in!

This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.