2 DIDs – Inbound calls to one fails except from one area code

I have a strange problem…

I work with both US and Canadian customers and decided that I want to set up both a US and Canadian DID on my PBX to accommodate for any restrictions or extra charges the customer may have to deal with.

First off, I am using FreePBX with Asterisk 18.20.2 through a static IP. Calls come in and are routed to a ring group which rings a few IP phones in my office.

I have an account with Skyetel and created the two DIDs, the Canadian number’s area code is 514 and the US, 321. I’ve set up an inbound and outbound trunk based on Skyetel’s instructions here: Trunk. I then created an outbound route for each number and based on dialing plans, I just need to dial 999 ahead of any number and the party I’m calling will see a 321 number… otherwise if I only dial the number, the party will see a 514 caller. This works flawlessly… so far so good.

The inbound… not so good. As I am based in Canada, inbound calls to the 514 number have been working well since I set this PBX up several years ago. Now that I added the 321 number, it seems that I can’t configure FreePBX so that anyone in North America can call the 321 number… BUT anyone with a 514 area code can call my 321 number!!! No US (including 321) or Canadian numbers will get through, even other area codes that are assigned to the same city as 514 don’t work. When I call from a 514 number, my call group rings and the call goes through, but when a call is placed to the 321 number from any other area code, there is a voice that answers indicating “technical difficulties with this number”. I think this voice comes from a Skyetel service, but I can’t confirm… yet.

I have tried creating a different IP group at Skyetel for the 321 number, no joy. I even tried sending the second IP group to a different WAN IP but my PBX got confused. I tried creating a different trunk… no joy.

If I watch at the packet level (tcpdump) at my router’s interface and FreePBX when dialing the 321 from a 514 number, I see 5060 traffic communicating between Skyetel/my router and the PBX happily back and forth. When I watch for the same traffic when dialing from any other area code, I see the traffic coming in from Skyetel/my router to FreePBX but the PBX appears to not respond…???

Even stranger or perhaps expected, if I look at the logs in FreePBX, calling from 514 will add some 300+ lines of logs but from another area code not a single entry in the logs and the CDR report will show that no one called which in part leads me to believe that the voice message comes from Skyetel.

This makes no sense to me. I’m no guru with FreePBX but I did get this far on my own… what can be causing this issue? Is there some kind of filtering going on in FreePBX or at Skyetel? I have searched high and low in both areas and come up with nothing. I’ve gone through all the rules in my router but I don’t believe my router could create a rule that can segregate traffic at that level. Quite simply, all I have is a rule for 5060 UDP/TCP pfwd to FreePBX.

Any guidance would be very much appreciated… I need to sleep! :slight_smile:


I am guessing that the STIR/SHAKEN stuff causes some incoming INVITEs to be large enough to need fragmentation and your router/firewall or another network element is not handling that correctly. See

But if those solutions are not feasible and you still want to troubleshoot this:

Which interface, WAN or LAN? If the WAN side shows two fragments coming in, but the LAN side shows only one going out, that’s a router issue. Post make/model, relevant settings.

If the WAN side shows only an incomplete INVITE, what’s between router and internet? Does the router have your public IP address on its WAN interface? If not, why?

If the LAN side shows a complete INVITE going out (fragmented or not): At the Asterisk command prompt, type
pjsip set logger on
Make a failing incoming call and report what, if anything, appears in the Asterisk log for the attempt.

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