Everyone is busy/congested at this time without even trying to make a SIP connection

I seem to be getting random Everyone is busy/congested at this time errors from app_dial.c when Asterisk hasn’t even tried to send an INVITE to the remote party. I am using Asterisk 18.26.0 with PJSIP.

Here’s an example log entry where it randomly fails:

[Dec 17 08:58:08] VERBOSE[3560018][C-00000022] pbx.c: Executing [s@dialvoipms:14] Dial("PJSIP/1011009248-00000061", "PJSIP/1[redacted]@voipms-[redacted]4,120,TW") in new stack       
[Dec 17 08:58:08] VERBOSE[3560018][C-00000022] app_dial.c: Called PJSIP/1[redacted]@voipms-[reacted]4                                                                                
[Dec 17 08:58:08] VERBOSE[3560018][C-00000022] app_dial.c: Everyone is busy/congested at this time (1:0/1/0)                                                                       

Since I have SIP logging enabled I should see the INVITE being sent before Asterisk should be deciding that there is congestion shouldn’t I? Here’s the same call being made a second time successfully, right after the above failure:

[Dec 17 08:58:34] VERBOSE[3560060][C-00000023] pbx.c: Executing [s@dialvoipms:14] Dial("PJSIP/1011009248-0000006a", "PJSIP/1[redacted]@voipms-[redacted]4,120,TW") in new stack
[Dec 17 08:58:34] VERBOSE[3560060][C-00000023] app_dial.c: Called PJSIP/1[redacted]@voipms-[redacted]4
[Dec 17 08:58:34] VERBOSE[3560012] res_pjsip_logger.c: <--- Transmitting SIP request (2409 bytes) to UDP:[redacted]:5060 --->
INVITE sip:1[redacted]@[redacted]4.voip.ms:5060 SIP/2.0^M
Via: SIP/2.0/UDP 10.75.22.8:5060;rport;branch=z9hG4bKPj5f9fd0fe-7eeb-4130-ad1a-6bb902fbdb76^M
From: <sip:[redacted]@10.75.22.8>;tag=e39df122-3cd8-459b-a4da-79d009fb1cc1^M
To: <sip:1[redacted]@[redacted]4.voip.ms>^M
…

So as you can see, the successful call actually sends a SIP INVITE. The congested call doesn’t even do that before deciding on congestion.

Any thoughts on what’s going on/wrong here?

Do you have qualify enabled on the AOR? Is it becoming unreachable due to not getting a response to the SIP OPTIONS?

I vaguely recall mention on DSLReports of some people experiencing some of the voip.ms PoPs not responding to SIP OPTIONS sometimes and moving to a different one resolving the issue.

And are you logging for ALL SIP traffic?

The AOR config is as follows:

[voipms-aor](!)
type=aor
default_expiration = 3600

[voipms-[redacted]4](voipms-aor)
contact=sip:[redacted]@[redacted]4.voip.ms:5060

My SIP logging also does not show any OPTIONS request being sent to that PoP or any other.

And are you logging for ALL SIP traffic?

Can you be selective in which SIP traffic you log? But regardless, it would have been the same SIP INVITE the first time as it was the second time, no? I mean in what situation would the SIP INVITE have been logged in the second instance that it would not have been logged in the first instance?

You can specify a specific IP address to log, yes. I was asking because in some environments a hostname can resolve down to multiple IP addresses so if filter based on a single IP address and do a call, then it can end up not showing up.

The next step would be to get a full log[1].

[1] Collecting Debug Information - Asterisk Documentation

Is there any way to query what the current PJSIP logging is set to?

In any case, I believe with voip.ms, their PoP’s are 1:1 to DNS names, which is why you see foo{1,2,3}.voip.ms, etc.

The next step would be to get a full log[1].

Roger.

There isn’t a CLI command for such.

Pity.

Is notice,warning,error,debug logging enough with:

server*CLI> core set debug 5
Core debug was OFF and is now 5.
server*CLI> module reload logger
Module 'logger' reloaded successfully.
    -- Reloading module 'logger' (Logger)

?

The link gives specific instructions.

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