We have a multi-office setup where we have 4 offices all with their own Asterisk + Thirdlane install, and each office has one or more trunks defined which connect directly to other offices. The extension numbers are unique across the company, and routes are set up so that certain extension ranges will route to certain offices. I also have inter-office routes set up where each office is assigned a 2-digit code (using the letters on the phone pads - easier to remember an abbreviation than each office having an arbitrary number) so you can dial 7 + office code + number and it will dial to that office and do whatever it would have done if you had dialed it from there.
However, with the route capabilities that ship with Thirdlane, it seems to assume that any outbound route you have defined is going to be making an outside call, and so it overrides the CallerID with the External Caller ID value. For the inter-office connections, since the extension numbers are global anyway (and even if they weren't there's already provisions for prefixing the callerid on a route anyway so I could stick the return interoffice code on the front of it), I'd just as soon leave the CallerID intact instead of replacing it with the outside phone number.
I've already accomplished this internally by cloning the tl-dialout-base script to create an interoffice-base and entirely commenting out the section that deals with the CallerID, then cloning the tl-dialout-1-trunk and tl-dialout-2-trunks scripts to make versions that call the interoffice version. (I usually use the 2-trunks version, since the offices all have connections to each other, I can sometimes route around network outages that way by prefixing a call with the inter-office code for the destination office and sending it to a different office). But what I did feels like a hack and in order to pick up changes to the trunking code that come with thirdlane upgrades, I would have to re-do that clone and remove code every time we upgrade.
It seems like something that could be in a checkbox on the route "use internal callerID" or something.
Thanks!
Dave Miller
Mozilla Corporation
could swear I replied to
could swear I replied to this already but I don't see it here now...
What you're suggesting still means cloning and customizing a script though. I was just suggesting that it seems like it would be a commonly-enough used option to be worth handling it automatically in the shipped scripts. It already gives you a choice of "from-inside" or "from-outside" for the trunk context, so it would make sense to me, anyway, to just key off that and if you're sending the call through a trunk that's designated as from-inside, don't mess with the CID.
But I'm not really using the
But I'm not really using the routing for my interoffice stuff anyway. Managed to set up DUNDi between the offices, and that just feeds it a direct channel to connect to. (And I can feed it weighted results that include a dial path through alternate servers if the direct route isn't available)
nah, you just need to look at the dialout 1 trunk script and write something similar that you can use as a feature extension, even something as simple as
exten => s,1,Dial(${ARG2}/${ARG3}${MACRO_EXTEN:${ARG4}},${ARG1},${ARG5})
would work since it doesnt re-set the callerid