Inter tenant dialing

ive already explained in another post why this wont work the way you think it will, and if you do this for every tenant you will have an exponentially large set of extensions significantly increasing the known current bug regarding reload and deadlocks. Don't be lazy.. build a gateway in front of your MTE box to re-route numbers you own back to the MTE box. There is not shortcut to doing things properly.

Ah, I knew it seemed too easy, I tried to look for a thread regarding this, but didnt see it, can you point me to it. I just wanted to see what it was

With all due respect to eeman, "build a gateway" is hardly what I would call "doing things properly". For every thirdlane install you would actually need two systems just to route calls locally.

There is no reason in the world that you should have to do that. Asterisk can route local calls locally so really it comes down to poorly written outbound dialing code that fails to check it's local DIDs before sending the calls to the trunk.

I'm probably going to end up solving this long standing Thridlane bug by hacking the dial macros myself. But should I really have to do this on a "commercial" product? I think not.

thats why you are a newbie, who doesnt understand CDR, billing, or anything else. You also have no concept of variable call lengths and standardization to E.164 formatting. For the record, even broadsoft uses separate devices. One device is their SIP router. One device is the hosted platform. And yet another device is their SBC. Enswitch has separate devices for routing, and the hosted machines.

If your customer dials a 11 digit number and your inbound routes are all 10 digit, or E.164 then 'checking local dids' as you put it will still fail. Your complete lack of programming skills and your certain desire to put your foot straight in your mouth is overwhelming. Some people put inbound DID as 10 digit, some 11 digit, others are E.164 (+15555551212) and that doesn't even BEGIN to address customers who are not part of NANPA. Those individuals have numbers of varying length even within the same country. So hack away.. moron.

Actually Erik, it is you that are a comparative newbie. I've been running hosted Asterisk on our own custom code since 2003 and administrating an in-house Asterisk system since 1.x days. We have only just recently switch to using Thirdlane so it is easier to delegate some of the day-to-day admin tasks to Jr. techs but it certainly has limitations.

With our code, local dialing all works just fine, even with your "variable digit length" red herring statement above and all the other drivel about CDRs, insults, etc. It clearly demonstrates you've not done much asterisk dialplan writing and prefer to try and make yourself look smarter by making derogatory comments about others. Good luck with that. So far it's having the opposite effect on me but maybe others are fooled?

If the variable length issue was so impossible to solve, then please tell me how passing the call off to another gateway would make any difference? It's impossible right? So the gateway would have no better luck routing local than the Thirdlane box did. It's obvious (to most people anyhow) that this is a solvable problem.

And forget variable length, Thridlane doesn't even match DIDs when they are dialed *exactly* as they appear inside Thirdlane. I could forgive it missing the variable length stuff as long as it did at least the exact matching correctly, but it doesn't. Not even within the same tenant!

Sure you "can" solve the problem with an external gateway, and yes there are commercial products which operate that way, however the big difference is they are sold as one complete solution and designed from the outset to operate this way. You know that when you buy it.

Thirdlane (Asterisk) by contrast is sold as a standalone solution and therefore should operate properly as such and not require you to purchase and operate yet another device to overcome it's limitations.

Anyhow, it's obvious from your tone that you aren't worth the time of day and I'm sure your next response will be just as enlightening and valuable as the first so I'll not continue this waste of time beyond this post.

I'd rather spend time on a solution and If I am able to find one within the confines of Thirdlane's framework I'll provide it to others who need it.

"If the variable length issue was so impossible to solve, then please tell me how passing the call off to another gateway would make any difference? It's impossible right?"

Right there proves without a shadow of a doubt that your knowledge is in fact limited, regardless of how long you've been playing with asterisk. The gateway only processes calls in E.164 format. All calls coming in and going out are converted to E.164 format so that they are handled in absolute format just like BIND.

The gateway also solves issues of billing because end-point PBXs re-write telephone numbers multiple times within a single call and the final source and destination numbers that show up in the CDR are not the actual numbers being called. Sometimes its an 's', sometimes its the users extension. When one tenant calls another tenant you only get a single call record of that event instead of two. When one tenant calls another tenant the concurrent call restrictions are not able to apply to both tenants. A gateway does not have these restrictions.

One gateway is capable of handling hundreds of asterisk machines using your services (5000 concurrent calls or 10,000 call legs). Not only can multiple MTE machines use a single gateway and inter-call between them as well, but all the STE machines that buy sip lines also benefit from on-net routing as well. All from a single location. It is the sole ingress/egress point of your network where all calls converge and its the ideal place for billing and routing. For all practical purposes it IS a session border controller. But I'm sure you think its much simpler to have to collect inadequate and modified CDR from several machines instead of a single machine. I am sure you think its better to comply with CALEA by dealing with hundreds of different asterisk machines instead of simple fulfilling the warrant simply as a matter of a monitor port on your ethernet switch. I am sure you find it better to manage least cost routing with poor outbound scripts on dozens of servers instead of sending calls to a gateway and let it use its own least cost routing to deliver calls in a unified manner.

Either you really like repeating your work hundreds of times over, or you just dont have that big of a network to have run up against any of these issues.

For anyone who stumbles on this thread and is interested in a possible solution, I've posted some preliminary code here:

https://www.thirdlane.com/forum/intertenant-and-local-dialing-solved