Phone will receive ext to ext calls, but that's all.

[Starburst]

So this is an odd problem.
PBX is in the cloud.

Programmed a Poly B10 here, and tested it, all was good.
Sent it to Florida.
And it doesn't work, except I can call that extension from mine, and it connects and has audio both ways.

PBX shows the phone is registered.
I whitelisted the IP in the PBX, iptables, and in the edge firewall.

But when he tries to call my extension or outside, it's just dead air.

There are allot of RGEX failures when I searched for 1410, I've attached part of the log.

What I've seen from other posts, they mention a dial plan is setup wrong.
But if that was the case, why is my extension OK?
And that the phone worked here.

Anyone has a suggestion?


Thanks

 

[pbxgeek]

Those failures are not the source of the issue. This is how the dialplan works. Each individual dialplan has conditions. If the condition is true, it executes. If not, you see the word FAIL, and it moves on to the next dialplan. It's desinged that way because not every dialplan needs to be executed for each call to complete. If the phone works fine at one location and not at another, it's much less likely to be the dialplan. The most likely issue is NAT or SIP ALG. Welcome to the worst nightmare of VoIP. Those two keep us all awake at night. (unless you use TLS, then you can sleep well)

 

[Starburst]

If I enable TLS on FS PBX can phones still connect without it, or is it an all or nothing?

Thanks

 

[Voipy]

they can still connect with tcp/udp

 

[Starburst]

Still having the problem where that extension can register to the PBX, receive calls from an extension, and also an external phone number that points directly.

That extension however can't dial an internal extension or external number.
I know it's in the DigitMap somewhere.

Does anyone have a dialmap for Poly phones?

Thanks

 

[kenn10]

Still having the problem where that extension can register to the PBX, receive calls from an extension, and also an external phone number that points directly.

That extension however can't dial an internal extension or external number.
I know it's in the DigitMap somewhere.

Does anyone have a dialmap for Poly phones?

Thanks

AI Says:
To configure a Polycom digit map for FS PBX (a modern FreeSWITCH-based platform), you need a dial plan that properly aligns with your system’s internal extension length and standard North American or regional dialing rules. [1]
Because FS PBX relies on a clean, immediate routing structure, an incorrect digit map will cause your Polycom phones to sit on the line waiting for a timeout or cut off calls mid-dial. [1, 2]

Recommended North American Digit Map for FS PBX​

If your FS PBX system uses 3-digit extensions and standard North American routing, use this complete string:
[2-9]11|1[2-9]xxxxxxxxx|[2-9]xxxxxxxxx|[2-9]xx|*x.T

Breakdown of the Rules

• 
  
• [2-9]11: Instantly dials emergency or community service numbers like 911, 411, or 311. [3]
• 1[2-9]xxxxxxxxx: Instantly matches long-distance North American numbers (1 + 10 digits). [3]
• [2-9]xxxxxxxxx: Instantly matches local 10-digit dialing without a leading 1.
• [2-9]xx: Instantly matches 3-digit internal extensions (e.g., extensions 200 through 999). If your FS PBX system uses 4-digit internal extensions, change this segment to [2-9]xxx.
• *x.T: Matches your FS PBX feature codes (like *72 for call forwarding or *97 for voicemail) and applies a short timeout (T) to allow variable lengths. [4, 5]

---

How to Apply It in FS PBX​

While you can type this directly into the phone's web GUI (under Settings > SIP), it is highly recommended to embed this into your centralized provisioning environment so it pushes out to all devices automatically. [6, 7, 8, 9]

1. Go to your FS PBX Dashboard.
2. Navigate to Advanced > Device Templates (or your active Polycom provisioning template).
3. Locate the variable parameter for dialplan.1.digitmap.
4. Paste the string above into the value field.
5. Set dialplan.1.digitmap.timeout to 3 (seconds) to handle unmatched numbers safely.
6. Save the template and reboot your Polycom phone to pull down the configuration changes. [9, 10, 11, 12]

[1] https://www.fspbx.com
[2] https://docs.coredial.com
[3] https://www.pbxforums.com
[4] https://community.freepbx.org
[5] https://www.smallbusinesstech.net
[6] https://www.fspbx.com
[7] https://community.freepbx.org
[8] https://www.youtube.com
[9] https://www.youtube.com
[10] https://www.3cx.com
[11] https://www.youtube.com
[12] https://www.youtube.com

 

[Starburst]

Tried that at the start of the week.
It also gave me:
xxxx|xxxxx|911|9[2-9]11|*xx|*xxx|9[2-9]xxxxxxxxx|91[2-9]xxxxxxxxx|9011xxx.T

To give internal extensions priority.

Even tried the one from VoIP.ms Wiki for the B10 on their system:
(911S0|[23458]11S0|1[2-9]xx[2-9]xxxxxxS0|[2-9]xx[2-9]xxxxxxS0|822S0|*9[78]S0|7xxs0|00xx.|011xx.|033xx.|044xx.|xx.|*75xxS0|*xx.|***xx|***xxx|4xxx|(Mipd)|[^*]@@.)

The phone just goes crazy with that one, and doesn't even let you finish entering the extension.

I tried another B10 locally, it connects to the Cloud PBX, and I can dial out and receive calls just by entering 4 base entries into the phone.

His setup is like the on here, and Callcentric VoIP works.
So it shouldn't be a firewall or network issue.

 

[pbxgeek]

So the dead air is because the phone is actually not dialing anything? Does it dial when you press the Dial button? Those would be very different issues.

 

[Starburst]

Phone just showing it's trying to call the other extension, and no error message on phone.
Have a screenshot from sngrep.

This is edited, so not to disclosed IP's.

Tried MicroSIP, and all works OK.

It looks to point to the phones DigitMap config somewhere.

 

[pbxgeek]

You cut out the actual INVITE messages, so it's hard to tell what the phone is trying to dial. Digimap would only affect something if you are adding prefixes to dialed numbers.
But you should still get replies even if the number is dialed incorrectly. Instead, you are sending a bunch of INVITES, and the other side doesn't reply.

Those 1s → 2s → 4s retransmissions are classic SIP-over-UDP retransmissions. The sender is essentially saying:

"I sent you an INVITE. I got absolutely nothing back, so I'm sending it again."

Normally, even if the destination ultimately rejects the call, you'd expect something like:

100 Trying → 180 Ringing → 486 Busy Here

or perhaps:

100 Trying → 404/480/503/etc.

Here, there appears to be no SIP response whatsoever from the far side.