Trunk list suddenly gone

... and the "database show" is not much use because in putty its too long to display all the results. Even in the API manager - output to PHP it stops (just ends, and writes what it has got so far +/- 300 lines.)

"database show TL" does help - but it like poking around in the dark.

I take it the trunk information that i need is not in the astdb?

I have been able to fix similar problems like this before with the txt files, but im just not seeing the entire picture of how the trunks are assembled.

Just to be clear... when i navigate to: /asterisk/trunks.cgi it shows no trunks only the paging links. Although the trunks (+/- 40, that's 1 per tenant) are all working perfectly.

Any ideas, Alex? Eric?

Please... getting quite desperate here ;)

Ah ha... Ok, if i remove the last trunk i created, then the list comes back!!

This is strange, put it back and it fails again... Is there some limitation to the trunks.include?

Hmmm its seems like a bit of a "bug", but there are ways to work around it...

Ok, So i discovered that removing the last trunk from the trunks.include shows the list again. So then if you set the display to "Available to current tenant" You can see the trunks again!!! woo hoo! (obviously filtered to the tenant you are working on).

Workaround: If you land up in the same situation. click the Trunks link on the left (it will not show all the trunks, only the pager). How ever if you add ?state=this_tenant to the url so its:
/asterisk/trunks.cgi?state=this_tenant
You can carry on working.

[I'm on 6.0.1.72 - if that makes any difference]

P.S. I'm still curious as to where the passwords etc for the trunks are stored?

if you are doing tenant specific trunks (which i dont) then you have to have selected that particular tenant before his trunks show up in your list.

Ya thanks i see that.
Ok, then how would you use MTE with say a single trunk to a VoIP provider... when there is no "tenant identifier" like P-Asserted-Identity or fromuser. Basically the VoIP provider would have to bill us for all our tenants and then we would have to split the bill up manually!!! Crazy!

We create a trunk per tenant and include unique credentials including from user and P-Asserted-Identity so the each tenant gets heir own bill.

Since we are also the VoIP billing provider - this comes as a single bill to our clients.

I welcome any alternate to this?

PS. We have already altered the trunk macro to include various additional headers so we can track thinks like actual extension that dialled etc. This allows clients to do per-extension cost analysis. This is why i ask about the storage of the trunk information.... where are they?

apparently you arent reading any of my posts.. I would never connect MTE directly to your upstream provider, I would route them through a routing/gateway pbx that has cleaner CDR. Then you use that CDR to bill your tenants. You should not be relying on a upstream provider to do your customer billing for you.

trunks.include is nothing more than a bunch of global variables.. see where the include for it is in extensions.conf

That's exactly what we are doing:
MTE PBX => Asterisk Billing => VoIP wholesaler / Terminator / Upstream provider

Erik, you're a great help and I do read your posts, with great enthusiasm, the question still remains, with one trunk from MTE to Billing Server, how do you identify an outbound call from TenantA or TenantB if they are both using the same trunk. CallerID is not sufficient as MTE allows you to modify this even to an extension level.

(Currently we use a trunk for each tenant with specific information in each trunk so that the billing server can pick up the call and bill according to that tenant.... and hence the listing problem)

Im happy to change the way the trunks are set up (to a single trunk) but i now have the problem in that i cant actually see the way the trunks are made up (in the dial plan), as you said the trunks.include don't have the information - only the global variables. From my understanding of Asterisk, there would have to be a dial plan entry something like:
[TrunkToBillingServer]
host = billing.server.com
username = something
secret = something
etc...
I just cant find it tho... .or am i going totally mad ;)

i use outbound routes prepend field..

so if the customer dialed +15025551212 then I send a 10 digit account code in front of my dial string..

6065551234+15025551212 .. then at my gateway I assign the first 10 digits to the account code and the remaining string as the new destination extension.

Oooooh.... Okay.

Cool, thanks for the tip. Will let you know if i come up with anything else on this.

Cheers :)

now that they have a custom tag at the tenant level you could also use that DB entry as a customized P-Asserted-ID if you wanted to.

True, what i was thinking about is altering the macro-tl-dialout-base to include say a fromuser header (not sure if this is possible).
Im already adding the P-Asserted-Identity like this:
exten => dial-SIP,1,SipAddHeader(P-Asserted-Identity: )
same with extension number.

The problem is that the billing server is identifying the tenant based on the fromuser header.

I guess ill just have to try it.... something like
exten => dial-SIP,1,SipAddHeader(fromuser: ...this is where im stuck...)
You see i would need a variable or something to put in there.

have you never messed with custom tags? its an astdb entry so your variable would be

${DB(family/key)}

but for good error checking you would want to use

${DB_EXISTS(TL/TENANT/${tenant}/tag)} as part of your guarantee that the tag is set

assign it to a variable

Set(SOMEVARIABLE=${DB(TL/TENANT/${tenant}/tag)})

use more code to make sure its not an empty set

and then use your sipaddheader

I have been poking around in the AST DB for the last few days looking mainly for the rest of the trunk information... but to no avail.

I do see its quite substantial but very difficult to work with. The box im working on at the moment has more then 200 SIP extension and +/- 50 tenants. so the list commands like 'database show' or even 'database show TL', just time out (or full up the buffer) so don't show all information.

Tho i do think we are onto something here... a combination of the ASTDB values, the Global Values in the trunks.include and SipAddHeader and i think it will be complete.

Thanks for the help Erik, will publish my findings, for those following.