how to route calls based on number format
Stewart:
Quote from: mish on March 13, 2012, 07:10:54 am
Now I would like 3 and 4 digit numbers (starting with number 1) to be dialed out using SP2.
If the 3 or 4 digits include the initial 1, e.g. 123 and 1345 should be sent to SP2, then your rules should be:
Service Providers -> ITSP Profile A -> General -> DigitMap:
(<**2>1xxx?|<1aaa>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|1xxxxxxxxxx|011xx.)
Service Providers -> ITSP Profile B -> General -> DigitMap:
(1xxx?|<1aaa>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|1xxxxxxxxxx|011xx.|(Mipd)|[^*#]@@.'@'@@.)
where aaa is your local area code for 7-digit dialing.
However, note that when you set up such a dial plan, there is a delay when you dial e.g. 1345, because the OBi has to wait to see whether more digits are coming. Conversely, if you pause too long after dialing an area code, the OBi will mistakenly treat the call as a 4-digit code to SP2. I assume that these short codes are extension numbers or speed dials. If you have control of the overall system, you might choose short codes that don't conflict with the North American numbering plan, e.g. have 3-digit codes 100-109 and 4-digit codes 1100-1199. With appropriate digit maps, there would be no delay on any calls (except 7-digit dialing in the local area). There are lots of other possible ways to design a no-conflict plan, e.g. start short codes with 0 (but not 01).
mish:
Indeed these are extension numbers.
And the extension numbers all start with 10.
They are 10x or 10xx.
Can I make a change such that 10x and 10xx go to SP2 without that much delay?
Stewart:
Well, since both the 3- and 4-digit numbers start with 10, you need to hard-code what range is three digits. For example, if you have 102-109 and 1000-1019, you could use:
Service Providers -> ITSP Profile A -> General -> DigitMap:
(<**2>10[2-9]|<**2>10[01]x|<1aaa>[2-9]xxxxxx|<1>[2-9]xxxxxxxxx|1[2-9]xxxxxxxxx|011xx.)
mish:
@Stewart - thanks for sharing the updated digitplan. By then I had already tried the earlier plan and that appears to work. So thank you!
And thanks to @RonR!
Cheers.
Navigation
[0] Message Index
[*] Previous page