We cannot dial any extensions that are starting with 711+ (7112, 7113, 7114, 7115), when we dial those extensions it won’t let us pass the 711 and it will dial right away and we will get circuits are busy. We have Soundpoint IP550
988|0T|011xxx.T|[0-1][2-9]xxxxxxxxx|[2-9]xxxxxxxxx|[1-8]xxxT|[1-8]xxT|*xxT|*xxxT|*xxxxT|**T
From the Aterisk CLI
CLI> dialplan show 711*@
pastebin it all
Sorry, I’m getting an error sending the pastebin link. I think I’m not allowed to send link yet
now a log file of a failed call
I suspect that the phone is sending the call early.
With the phone on hook, dial (for example) 7112 then pick up the receiver. If that works, you need to fix the dial plan in the phone. If it fails, report what the phone’s display shows while playing the circuits busy message.
Hi @Stewart1, that is the exact scenario, when the phone is on hook, we will be able to dial any extension. Here’s our current dial plan
1[0-1]x|*xx|[2-9]11|0T|011xxx.T|[0-1][2-9]xxxxxxxxx|[2-9]xxxxxxxxx|[2-9]xxxT
The [2-9]11 section will match 211, 311, … 911 and dial immediately. Assuming that you are in the US (or another country using 911 for emergency calling), you could replace that with just 911, unless you have other x11 numbers that you want to support. I hope you don’t have any extensions beginning with 911.
Hi @stewart1, I modified our dial plan and we are still having the same issue.
1[0-1]x|*xx|911|0T|011xxx.T|[0-1][2-9]xxxxxxxxx|[2-9]xxxxxxxxx|[2-9]xxxT
I see nothing wrong with the new dial plan. Possibly, it didn’t get loaded or got overwritten by a config reload.
Also, Polycom has a hierarchy of rules for conflicting settings from different sources. I don’t know what they are for the 550.
You might try factory reset of one phone, then confirming from its log or packet capture that the correct dial plan got loaded.
@isaac070517 Did you get it resolved? If not, I believe that you need to remove the *xx| from the Digitmap, or add a T to the end of that sequence so that it waits for the timeout instead of dialing immediately.
You should also be able to add [7][1][1][xT| to the beginning of your Digitmap to explicitly define the problem sequence.
If you take out the *xx|, make sure to also remove the respective timeout in the next section. Likewise, if you add the explicit 7+ sequence to the beginning, then you also need to add a corresponding timeout to the next section. The default timeout is 3| for each sequence, but sometimes people adjust it for certain circumstances.
[7][1][1]xT|1[0-1]x|911|0T|011xxx.T|[0-1][2-9]xxxxxxxxx|[2-9]xxxxxxxxx|[2-9]xxxT
3|3|3|3|3|3|3|3
Hi @MSchub, is this how you wanted the Digitmap to be set up?
@isaac070517 Yes, that should work correctly. Does it?
Polycom works from first to last (they call it “top to bottom”), so the phone checks if a dialed number matches the digitplan in that order. With your scenario above, it checks for 4-digit extensions that begin with 7-1-1 first, then for a 3-digit extension beginning with 1-0 or 1-1, then checks for 9-1-1, and so on.
The ‘T’ tells the endpoint to wait until the timeout (3 seconds, in your scenario) to see if the user dials additional digits. If not, it places the call as dialed. You never want 9-1-1 to have a timeout, but you probably want a timeout for numbers shorter than 10 or 11 digits in North America because those are typically local PBX extensions. You don’t want to have a user dial 1-202-xxx-xxxx (Washington DC) but end up dialing Patty at extension “120” because the digitplan didn’t have a timeout specified.
Hi @MSchub, thank you so much for sharing that information. We did try that dial plan but the issue is still the same. We can’t still pass the 711 as it dials right away.
Ok, sorry, a few more things to try:
#1 shouldn’t make a difference, but it might
#2 should theoretically have x7115 match [2-9]xxxT before 711xT, but who knows?
#3 once in a great while, using a 3rd-party utility to update something passes the wrong ASCII character, and entering it directly into the endpoint should verify this isn’t the case
#4 the digitplan is correct, and the problem is definitely in the phone - not the PBX - because it works using on-hook dialing, and that’s the way to verify that. Maybe there’s a bit hung in the memory on the phone?? Just a guess
#5 Maybe there’s a bug that developed over time in the firmware.
#5 may also be tough to locate, but I can see if I have the link somewhere for the current FW downloads. The Soundpoints were EOL a long time ago, if I remember correctly, so it’s not easy to locate the official FW binary for each model.
