Dialing Plan Logic Sanity Check
-
Before I spend X amount of time tinkering, I want to make sure my understanding is correct regarding dialing plans with FreePBX.
Since the beginning of time, we have dialed 8 to in order to make calls outside the company. With my rollout of FreePBX, I'm going change that behavior and my users are going to learn to just dial 10 digits.
Prepend Prefix Match Pattern Caller ID +1 NXXXXXXXXX This pattern works for Twilio (which requires + and a number in E.164 format), since this is what I think the evaluation process is.
- User dials 7705554321
- Freepbx checks the number against the match pattner, and finds that 7705554321 matches.
- Freepbx then adds +1 to the number and sends +17705554321 out the trunk.
Now, let's say I wanted to allow my users to still dial 8 + 10-digit number as well as 10-digit number. I would configure the dial plan to be this.
Prepend Prefix Match Pattern Caller ID +1 NXXXXXXXXX +1 8 8NXXXXXXXXX The definition for prefix with FreePBX's pattern help is
Prefix to remove on a successful match. The dialed number is compared to this and subsequent columns for a match. Upon a match, this prefix is removed from the dial number before send it to the trunks.
Does the logic still flow the same?
- User dials 87705554321
- Freepbx checks the number against match pattern (and find that it matches)
- Freepbx removes 8 (the prefix)
- Freepbx adds +1, and sends +17705554321 to the trunk.
Here is where I have confusion.
"The dialed number is compared to this and subsequent columns for a match."
Since the context of the instruction is the prefix box, it seems like Freepbx would first check 87705554321 against whatever is in the prefix field, which is just 8, which clearly isn't a match, then check against the match pattern field, which matches. Since you have a false and a true, the result would be false, which in the end will not match the pattern. This seems ridiculous.
For international numbers, I intend for my users to dial 011 + International Number, and use a prefix to strip 011; thus, I want to make sure my understanding is correct regarding how Freepbx evaluates its dialing patterns.
-
Without testing what you have might work, or you might need
Prefix = 8 and match pattern = NXXXXXXXXX because the 8 might already be stripped out by the Prefix column when moving onto the second column of match pattern.
-
I just tested this on FreePBX
This worked
https://i.imgur.com/hkcki40.pngThis failed
https://i.imgur.com/GDFqeEB.pngAs I suspected, the 8 in the match failed because the prefix already stripped that out before sending the remaining digits to the match pattern.
-
When I read the title of this post I read it as "Dating Plan Logic Sanity Check"
-
@dashrender said in Dialing Plan Logic Sanity Check:
I just tested this on FreePBX
This worked
https://i.imgur.com/hkcki40.pngThis failed
https://i.imgur.com/GDFqeEB.pngAs I suspected, the 8 in the match failed because the prefix already stripped that out before sending the remaining digits to the match pattern.
I'll try it out tomorrow. Had zero time to work, test, and learn today.
-
@dashrender said in Dialing Plan Logic Sanity Check:
I just tested this on FreePBX
This worked
https://i.imgur.com/hkcki40.pngThis failed
https://i.imgur.com/GDFqeEB.pngAs I suspected, the 8 in the match failed because the prefix already stripped that out before sending the remaining digits to the match pattern.
I was able to replicate the results.
This means (from the Prefix definition) "The dialed number" must mean the prefix number. So perhaps this is what FreePBX does.- User dials 8777705554321
- FreePBX checks against first dial pattern (NXXXXXXXXX) - false
- FreePBX checks against the second dial pattern.
- Checks to see if the prefix number is at the beginning of the dialed number - true
- Removes the prefix and checks the resultant number against the match pattern field - true
- FreePBX adds the prepend, and sends +17705554321 to the trunk.
-
@eddiejennings said in Dialing Plan Logic Sanity Check:
@dashrender said in Dialing Plan Logic Sanity Check:
I just tested this on FreePBX
This worked
https://i.imgur.com/hkcki40.pngThis failed
https://i.imgur.com/GDFqeEB.pngAs I suspected, the 8 in the match failed because the prefix already stripped that out before sending the remaining digits to the match pattern.
I was able to replicate the results.
This means (from the Prefix definition) "The dialed number" must mean the prefix number. So perhaps this is what FreePBX does.- User dials 8777705554321
- FreePBX checks against first dial pattern (NXXXXXXXXX) - false
- FreePBX checks against the second dial pattern.
- Checks to see if the prefix number is at the beginning of the dialed number - true
- Removes the prefix and checks the resultant number against the match pattern field - true
- FreePBX adds the prepend, and sends +17705554321 to the trunk.
Correct. How was this hard to understand?
-
@eddiejennings said in Dialing Plan Logic Sanity Check:
@dashrender said in Dialing Plan Logic Sanity Check:
I just tested this on FreePBX
This worked
https://i.imgur.com/hkcki40.pngThis failed
https://i.imgur.com/GDFqeEB.pngAs I suspected, the 8 in the match failed because the prefix already stripped that out before sending the remaining digits to the match pattern.
I was able to replicate the results.
This means (from the Prefix definition) "The dialed number" must mean the prefix number. So perhaps this is what FreePBX does.- User dials 8777705554321
- FreePBX checks against first dial pattern (NXXXXXXXXX) - false
- FreePBX checks against the second dial pattern.
- Checks to see if the prefix number is at the beginning of the dialed number - true
- Removes the prefix and checks the resultant number against the match pattern field - true
- FreePBX adds the prepend, and sends +17705554321 to the trunk.
Also NXXXXXXXXX is an invalid dial pattern for NANPA. The valid pattern is NXXNXXXXXX.
-
@jaredbusch said in Dialing Plan Logic Sanity Check:
@eddiejennings said in Dialing Plan Logic Sanity Check:
@dashrender said in Dialing Plan Logic Sanity Check:
I just tested this on FreePBX
This worked
https://i.imgur.com/hkcki40.pngThis failed
https://i.imgur.com/GDFqeEB.pngAs I suspected, the 8 in the match failed because the prefix already stripped that out before sending the remaining digits to the match pattern.
I was able to replicate the results.
This means (from the Prefix definition) "The dialed number" must mean the prefix number. So perhaps this is what FreePBX does.- User dials 8777705554321
- FreePBX checks against first dial pattern (NXXXXXXXXX) - false
- FreePBX checks against the second dial pattern.
- Checks to see if the prefix number is at the beginning of the dialed number - true
- Removes the prefix and checks the resultant number against the match pattern field - true
- FreePBX adds the prepend, and sends +17705554321 to the trunk.
Correct. How was this hard to understand?
It's not, once "dialed number" is defined. First thought was it sees if the match pattern matches, if it does, then it strips the number specified in the prefix, then adds the prepend, but, in fact, it just matches that a number begins with the prefix, strips it, then sees if the number matches the match pattern, then adds the prepend as was discovered.
-
Also NXXXXXXXXX is an invalid dial pattern for NANPA. The valid pattern is NXXNXXXXXX.
You're right. I've fixed my patterns. While the invalid pattern works, it would be best to follow the standard.
-
@eddiejennings said in Dialing Plan Logic Sanity Check:
Also NXXXXXXXXX is an invalid dial pattern for NANPA. The valid pattern is NXXNXXXXXX.
You're right. I've fixed my patterns. While the invalid pattern works, it would be best to follow the standard.
It is too loose, so it would never have stopped a real call from processing.
NXX - NPA (Area Code)
NXX - Exchange (ILEC Central Office)
XXXX - Line (Station within the Exchange)N = 2-9
X = 0-9So this menas that NPA and Exchange 3 digit numbers can never begin with a 0 or 1.
