I noticed when my customers call each other on the same server, their calls go out the trunks to the gateway per the outbound route of the mask. I thought MT was supposed to be able to figure out what DIDs are loaded in the server and internally switch those DIDs without using outbound routes.
Am I missing something on the config or is it designed this way?
For example...
All of my DIDs are loaded 10 digit NPA/NXX/XXXX. So are you saying they should look like 1NPANXXXXXX? Also, since I am prepending for 7D and stripping for 11D in routes, that is not enough to build the final translation and the switch to route the final outcome internally? I have to use an external box?
+1NXXNXXXXXX is what E.164
+1NXXNXXXXXX is what E.164 looks like
when you say you are prepending 7D do you not have service areas that have 2 area codes as part of its 7 digit dialing area? Example, in louisville 502-315-xxxx is local and so is 812-206-xxxx. If I call 206-xxxx i can reach those members in southern indiana just as easily as calling downtown louisville @ 315-xxxx.
I'm in 512
I'm in 512 and it is old school with 7D dialing. I send local 7D prepended with 512 to my cisco gateway / ISDN CLEC terminator. If someone dials 11D, I strip the 1 and send it 10D. All my DIDs are 10D, so I'm losing why it doesn't match 10d DID to the final translation, which is 10D.
To clarify
To clarify - My customers want to dial 7 digits. The CLEC ISDN switch behind my gateway wants 10 digits. They told me I could send a preceding 1 on all nanpa, if that would help.
if your customers dial 11
if your customers dial 11 digit and you strip the 1 off, how do you specify LD vs local10? Most require 11digit for NA LD, 10D and/or 7D for local calling area. So far I haven't found an area that lets you dial 10D for a long distance call (though it would technically be doable).
regardless that your dialing as 10D and customers are setup 10D, nowhere in your dialplan does your oubound contexts ever cross with your inbound contexts. Your inbound and outbound routes arrive in different contexts and never cross paths. This is essentially the basis of how to keep numbers on net.
First you have to standardize on exact call length. I chose E.164 because 1) its absolute, 2) theres no way a phone can generate a + so you cant arrive there by misdialing 3) its the telecom standard.
Next you need to place all your DIDs in a single context with GoTo routes to send them where they belong.
And lastly your inbound contexts and your outbound contexts should include these as part of their search before arriving at the code that opens up a trunk line.
This summarizes how a routing box keeps calls on network. Since MTE boxes and dialplan-complex PBXs make a mess of CDR, the routing box also serves as a excellent source of CDR for billing since, when configured correctly, each call will have one and only one CDR entry of correct call length.
NPANXX
By NPANXX is how I set up 512 in my switch. I know what 512 NXXs are local, and those get sent to the gateway. I prepend the 7D with 512 unless the customer dials 10D for some reason. Strip the 1 on 1+. Any other 512 gets sent to another domestic carrier, again 10D.
Again, doesn't the E.164 just look like, for an example, 15123456789? I hear what you're saying about the routing box. It does make sense. But I thought MT wasn't going to require such unless I was expanding to multiple MTs. Least that was what I was hoping.
no, E.164 looks like
no, E.164 looks like +15123456789 not 15123456789 the plus is needed to comply. Ireland calls would look like +33123456789 etc.
route an ascii +
To check and summarize all:
The inbound and outbound routes never meet in one server. DIDs are not universal within it.
Requires an extenal server, like another MT or even ST. Build E.164 master translations using 11D nanpa or intl code and ascii + prefix at that box. Strip + and retranslate for legacy / non-E.164 vendor networks there. Pass E.164 untranslated to voip vendors that want it from that box.
right?
don't use a MT or ST as your
don't use a MT or ST as your gateway, you will have rancid CDR of no real use. You can do this fairly easy with 'vi' and extensions.conf type dialplan 4 basic features...
the use of 'include => context' to send inbound and outbound calls through the same list of DID you own.
the use of 'Goto' for translation and/or rewrite
the use of '#include subdirectory/exten_*.conf' to break extensions.conf into multiple files for sanity.
the use of ${GROUP_COUNT} to establish hard limits on concurrent counts
the handoff is clean, drop each vendors inbound into their own context. Do your translations to get it into E.164 and send to your external context .. lets call it from-outside. This context contains a series of 'include => context' statements indicating the search order you want to process; of which would include a context of all your DID. Outbound calls are almost the same. Each customer arrives in their own context where you can reformat E.164, run macros to manage call count, re-force 911 callerid, etc, before handing it off to an internal context ... lets call it from-inside. Again the from-inside context will just use a series of 'include => context' statements for search order, of which would include a context with all your DID, and obviously the last include would be your outbound routing engine or trunk if just 1 vendor.
most voip vendors will accept E.164 formatted calls. Some downright require, at the minimum, the ability to receive it in such format.
Netlogic aka Voxitas requires E.164, which cisco call manager, at least previous versions, could not process. I heard stories of companies running call manager installing asterisk boxes as an arbitrator just to deal with the '+'.
Just use plain asterisk
You are saying just set up a plain asterisk server as the gateway server. I am going to embark on this next month so I'm sure I'll have some lingering questions.
your missing the part that if a customer calls 7 digit or 10 digit or 11 digit ... each of those are different numbers and may or may not match the DID you configured for inbound routes even if they were able to include them in the search patterns.
the only way to get tenant A to route to tenant B is by re-translating every dialed number into E.164 and setting up all your DID as E.164. This is one of the primary functions of setting up a 'gateway' or routing box that specializes in only routing to/from other asterisk boxes (STE, MTE, etc) in E.164 format. It also makes a perfect egress point for your dialtone providers and means to collect detailed and accurate CDR for billing purposes without arbitrary entries about call transfers and 's' extensions etc.
This means that calls from MTE need to leave the box in E.164 format (some exceptions like N11 and international apply). This also means calls delivered to MTE need arrive in E.164, which might have you editing all your existing DID numbers.