Problem with PRI trunk, and with one extension

General Help
1

Hi Everyone,

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).

–TODAY–

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 [s@macro-dialout-trunk: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 [s@macro-dialout-trunk: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[3335]: 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[3335]: 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 [s@macro-hangupcall: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[3335]: 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”

Summary

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.

Thanks,
-Whistler42

More info:
FreePBX 2.11.0.42
Asterisk 1.8.11.0
SIP provider: Broadvox
PRI provider: unknown - (Is there a way to look this up?)

2

You seem to have an issue with phone A as it is receiving a “Forbidden” response. Are all your phones on the same network as FreePBX?

1 Like
3

This is usually a problem with NAT or routing. Usually. There are other, harder to find problems, but NAT is, far and away, the most common.

Now, on to your configuration. Note that these are all just suggestions, borne from my experience and my limited knowledge of what I think you are saying.

It sounds like you are trying to test everything at once, and that’s just too big an elephant to eat in one bite. Let’s break up your effort so that you can troubleshoot this and find the root causes.

An important note: if you are only having problems it one phone, messing with your outbound routes and trunks is far too deep. Make sure the phone is working with the PBX (use voicemail to leave yourself a message, or use “*65” to check the extension settings to make sure the phone is operating reasonably correctly. Once you are convinced that the phone is working in the network (with the other phones in the system and can contact the PBX server), you can move on to the outbound routes and trunks.

So, is sounds like you have four trunks, two DAHDI (which are using the same PRI, if I’m reading your description correctly) and two SIP (which are both pointed at your SIP trunk). The test SIP trunk is actually pointed at your DAHDI PRI and the test PRI trunk is pointed at your SIP. No way that could possibly be confusing. :slightly_frowning_face:

Step 1 would be to eliminate the ‘test’ trunks. This will reduce the field of problems and get you away from some inefficient (at best) practices. This will get you down to two trunks that you can troubleshoot individually. On re-reading your problem, these could be outbound routes - if that’s the case, I’d still get rid of them, just to make sure they aren’t getting in the way.

Set up your two trunks so that any number that hits them is rewritten to adhere to the requirements of the provider. For example, if your PRI allows 7-digit local dialing, you can strip the local area code off the number and send seven digits. If your PRI uses universal 10-digit dialing, you can add the local area code to 7-digit numbers that arrive at the trunk. Add a 1 to the number for long distance numbers, etc. as necessary. The idea is that, no matter what the outbound route sends to the trunk, the trunk should manipulate the numbers to meet the trunk’s requirements. The SIP trunk has similar restrictions (requires a ‘1’, can’t have a ‘1’, requires a full country code, etc.), so make sure the trunk is “fixing” whatever shows up from the outbound route to pass the provider’s needs.

Making this change to the trunks will help you eliminate some of the “failing over” problems you might see happening.

Next, we need to look at your outbound routes. Let’s assume, for the sake of discussion, that you have three “classes of service”:

  1. Local calls - these are free over PRI, so route all of the local calls to the PRI with the SIP trunk listed as the “second” trunk.
  2. Toll-free calls - these are free over PRI, so route them to the PRI with the SIP trunk listed second.
  3. Toll calls - these are cheaper over SIP, so set up the route to send these guys to the SIP trunk and, failing that, send them over the relatively hugely expensive toll call lines.
  4. Everything else - this shouldn’t be needed, but it can catch anything that might pop up that needs its own route. Set it up with nothing in the patterns section. It will catch whatever falls through the other routes. I’d send these calls to the SIP connection first, then send it all to the PRI.

Remember, you may also need to route calls to ‘911’, which should probably have it’s own route as well. This one will probably be on your PRI only, unless you have E911 support from your SIP provider.

You were saying that you were using the “failover” destination on your trunks. I don’t recommend that under normal conditions. Setting up your outbound routes to use multiple trunks. They will be used in order, and will only fail over if the first trunk is unavailable.

How is the Conf Room A phone actually connected? If it’s a SIP phone, make sure the Extension Configuration has “NAT” set to “Yes”.

You may also want to look at the “Advanced” settings for your SIP configuration. You need to make sure that the External and Local addresses are all correctly defined.

4

Thanks!!! This was the answer to the problem with Cinference Phone A. Someone (possibly me) plugged it into the wrong VLAN port. Different subnet. So the phone registered fine and call signaling worked, but it stopped short of passing voice traffic.

Once the PRI was back in place, I realized this phone wasn’t on the same sub as the PBX and other phones.

5

Thanks!!! This was a huge help. See my other reply for the results.

There are just minor problems now. Calls out go over PRI as hoped. With the “test sip” outbound route at the top (and changes applied), calls out still use DAHDI. But my client doesn’t care as much about that.

Also, “Conference Room C” phone can place outgoing calls, but for incoming calls to its DID, the PBX plays an “all circuits busy” message.

Since my client is currently satisfied, I may return to these issues later.

This forum rocks!! :slight_smile:

6

You need to watch an inbound call and see what Asterisk says is the problem. What inbound route is getting matched?

7

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