Hello,
Does anyone know how can I configure the dial plan for my Sangoma phones to prepend a digit to the dialed number (for outbound routing purposes)?
Say I have this existing dial plan: {[2-9]xx[2-9]xxxxxx|[2-9]xxxxxx} and the user dials “234-1234”, I want the phone to send this to the PBX as 4234-1234 (prepend the 4 in the front).
(4)234-1234
does’n’t match your [2-9]xx[2-9]xxxxxx|[2-9]xxxxxx
you ned to add another “OR” condition “|[2-9]XXXXXX”
Exactly what I was looking for, honestly don’t know why I couldn’t find that! Thank You.
234-1234 does match and should be sent after match as (4)234-1234
Sorry, miscounted your x’s 
So I need to run it as {<=4>[2-9]xx[2-9]xxxxxx|<=4>[2-9]xxxxxx}
Thanks guys!
Do you want to prepend 4 to both NXXNXXXXXX and NXXXXXX or just to NXXXXXX ?
Both. I will actually using this in a few different formats, not necessarily 4. I just need to flag the calls from all phones each of my locations to make sure they get picked up by the right outbound route to go out the right trunks with the right caller id
I would suggest you might look at doing that in the
[macro-dialout-trunk-predial-hook]
context for better control.
Usually, if extensions need to send different caller IDs on outbound calls, you would simply set Outbound CID for each extension accordingly. If a group of extensions needs to use a different trunk, e.g. because they are separately billed or you want to limit the number of concurrent calls they can make, you would use an Outbound Route that matches a range of extensions and delivers the calls to the proper trunk.
It is usually undesirable to rewrite numbers in the phone; for example, returning calls from history or contacts may not work correctly. If you have a special requirement where the phone must rewrite the number, please provide details.
Its not doing this for CallerID purposes, its actually because my provider requires a unique trunk for E911 routing.
I have 3 locations with 3 addresses, so i’m required to have 3 trunks in order to make sure they catch the robber in time! 
Set up three Outbound Routes. They are identical except for the CallerID fields in the Dial Patterns and the trunks that are selected. Each route should match 911, your provider’s emergency test number (often 922 or 933) and your normal permitted external number formats.
For example, suppose that extensions 100-149 are at headquarters, 150-169 are at branch A and 170-189 are at branch B. The first route has 1[5-6]X in the CallerID field (of all patterns) and uses the trunk for branch A. The second has 1[7-8]X in the CallerID field and uses the trunk for branch B. The third has the CallerID field blank and uses the ‘headquarters’ trunk.
I like, but avoid using extensions that start with ‘1’. It conflicts with a bunch of stuff, like queue logins and other fun stuff. It can make direct dialing to voicemail for those extensions a little flaky.
I posted a simple example to show how routing based on extension number can work. I agree that it’s not a good range for a production system.
However, it’s IMO important that extension numbers don’t conflict with the external numbering plan. For example, it’s not a good idea to have an extension 212 and also permit dialing 2125551212. If someone dials 212 (and doesn’t press # or Send), there is a delay of typically four seconds while the phone waits to see if more digits are coming. Also, if he starts to dial a number beginning with 212 and pauses to look up the rest of the number, he’ll be connected to extension 212 instead. On my own system, extension numbers are 1000-1099. The phone dial plans put those calls through immediately, and they don’t conflict with external numbers. I don’t listen for in-call DTMF and have no trouble with conflicting feature codes.
That also is the biggest reason for moving toward 11digit NANP dialing where the 1 is also the countrycode , ,and you might notice that most key systems out there have the operator at 200 and extensions following
Always keep in mind the power of ‘MostSignificantDigits’ in any dialplan.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.