I’m troubleshooting an Asterisk / FreePBX box with Polycom phones at a customer. The PBX has 2 trunks: a SIP service (Broadvox), and a PRI (dahdi).
- The “default” outbound route’s sequence is: dahdi first, then broadvox.
- There’s a 2nd outbound route, “testpri”, which just has the dahdi trunk.
- And a 3rd, “testsip”, which just uses the Broadvox trunk. All other settings in these routes appear to be the defaults.
When I was brought in yesterday, conference phone A couldn’t dial out or in.
- The “default” route was in the top position.
- Calls out from this phone triggered the “all circuits are busy” message on the PBX.
I looked at the Asterisk logs while attempting calls. Outbound calls to the PSTN referenced congestion as the reason for failure. Calling the IVR also failed; for that, the errors mentioned SIP timeouts.
Before I made any changes, suddenly no phones could dial out. Congestion or SIP timeouts were the reasons reported in the Asterisk logs.
Changes I tried yesterday:
- Rebooted the PBX box
- Tried the other outbound routes in top position: “testpri”, then “testsip”
- On “testpri” (dahdi), I changed the “Optional destination on congestion” to the DAHDI trunk
Calls were intermittently successful on some phones. From the conference room A phone, I was able to make it ring my cell phone, but there was no voice traffic and the call died quickly.
The last thing I did yesterday was put everything back the way it was, the best I could: The top outbound route is “default” (dahdi, then SIP).
Conference room A phone still can’t dial anything. Many phones can. Currently, for conference room A phone:
Calls to PSTN numbers fail. In the Asterisk logs, the call tries the DAHDI trunk:
-- Executing [[email protected]:22] Dial("SIP/1871-000000d6", "DAHDI/i1/18002662278,300,tTwW
") in new stack
…is passed to the SIP trunk:
-- Called DAHDI/i1/18002662278 -- DAHDI/i1/18002662278-4d is proceeding passing it to SIP/1871-000000d6 -- Span 1: Channel 0/1 got hangup request, cause 41 -- DAHDI/i1/18002662278-4d is circuit-busy -- Hungup 'DAHDI/i1/18002662278-4d' == Everyone is busy/congested at this time (1:0/1/0)
-- Executing [[email protected]:22] Dial("SIP/1871-000000d6", "SIP/broadvox/18002662278,300,tTwW
") in new stack
…dies because of timeouts and hangs up:
[2019-03-21 15:22:33] WARNING: chan_sip.c:3641 retrans_pkt: Retransmission timeout reached on transmission [email protected] for seqno 2 (Critical Response) -- See https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
Packet timed out after 6400ms with no response
[2019-03-21 15:22:33] WARNING: chan_sip.c:3670 retrans_pkt: Hanging up call [email protected] - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
-- Executing [[email protected]:34] Hangup("SIP/1871-000000d6", "") in new stack
There’s also this message, which I don’t see with other phones:
[2019-03-21 16:02:17] WARNING: chan_sip.c:20269 handle_response_invite: Received response: "Forbidden" from '"Room-1871" <sip:[email protected]>;tag=as0aac2fce'
Calling the IVR extension still fails from conf. room A phone, with the same messages about timeouts.
Calls out from (now) working phones fail similarly to the SIP provider, as in the example about – they just connect successfully. “Test phone B” can dial out and I can ring it by calling its DID from my cell phone. “Test phone B” can call the IVR with no problem.
From Test phone B:
- With the “default” route, calls fail dahdi then go out through the SIP provider successfully
- With the “testpri” route, calls fail completely and the PBX plays the “all circuits busy” message
- With “testsip” – for some reason – the same behaviour as “testpri”
I put the default route back in place, so some phones can work. My interpretation now is there are two problems:
- One preventing the PRI or dahdi interface from working
- Perhaps a separate problem for “Conference room phone A”
Next, I’ll try ruling out switching/routing by moving Conf Room Phone A to the port being used by Test Phone B. If it works there, it’s the network infrastructure. If not, perhaps that phone/extension configuration is messed up.
If it looks like the PRI, I’ll call that provider.
SIP provider: Broadvox
PRI provider: unknown - (Is there a way to look this up?)