We're toying with the idea of writing a new script for outbound calls to keep tenant-to-tenant calls on our network. I know eeman advocates having a sip router in front of the Thirdlane server to do this, and I understand his reasoning. But, I would like to come up with a decent solution until I can get the sip router idea in place.
Our idea is a new outbound dialing script that uses awk to parse /etc/asterisk/dids.txt for an outbound call. If the called number is in dids.txt the call should be another tenant on the same server. In that case we pull the tenant ID from dids.txt and put the call back into the correct context to keep it local.
Thoughts?
We're not matching E.164 at
We're not matching E.164 at all right now. I'm setting up the DIDs however the upstream providers require. For the most part all of our outbound routes are for 10-digit and international. The local calling area requires 10-digits. Some of the DIDs that are through a local Atlanta provider are 1+ten-digits, but I'm not as concerned about those right now.
The reason this came up is because of our new Commpartners/Broadsoft trunks. If we place an outbound call from a Commpartner's DID to a Commpartner's DID for some reason they aren't sending it back to us.
We don't yet have a plan for our 2nd MTE server, but will need to sooner or later.
1) I'm probably ok with that since I'm not paying for minutes or trunks for these calls. There won't be that many right now. Once we've taken over all of Georgia it will be important. ;-> I suspect we will have something like a sip call router in place before then.
2) Not sure I'm comfortable with this one. I will have to think on it more.
3) Same as 1.
Thanks for your thoughts! As usual they are very helpful.
We're testing an idea for
We're testing an idea for this script. Originally, we were going to parse the dids.txt file to determine if a dialed number is an on-net number. But, we decided to use mysql instead. One of the requirements was to have it check to see if mySQL is running and to process the call as an off-net call if it can't make a mySQL connection. So far (in less than one day of testing) it seems to be fast enough. We set it up to work with 9 as a dialout digit. The DIDs that are loaded into the table are 10-digit.
Basically, it attempts a database connection. If it connects it compares the dialed number (minus the dialout digit) to a mySQL table. If it finds the number in the table it sends the call to from-outside-redir. Otherwise, (and if the database connection fails) it sends it uses tl-dialout-base to send it outside.
exten => s,1,MYSQL(Connect connid localhost dbuser dbpass dbname)
exten => s,2,GotoIf($[${connid} = 0]?9)
exten => s,3,MYSQL(Query resultid ${connid} SELECT\ 'did'\ from\ 'did'\ where\ 'did'=\'${MACRO_EXTEN:1}\')
exten => s,4,MYSQL(Fetch fetchid ${resultid} varDID)
exten => s,5,GotoIf($[${fetchid} = 0]?9:6)
exten => s,6,MYSQL(Clear ${resultid})
exten => s,7,MYSQL(Disconnect ${connid})
exten => s,8,Goto(from-outside-redir,${MACRO_EXTEN:1},1)
exten => s,9,MYSQL(Clear ${resultid})
exten => s,n,MYSQL(Disconnect ${connid})
exten => s,n,GotoIf($["${MACRO_EXTEN}" = "s"]?dial)
exten => s,n,Set(__DIALED_NUMBER=${MACRO_EXTEN})
exten => s,n(dial),Macro(tl-dialout-base,${ARG1},${ARG2},${ARG3},${ARG4},${ARG5})
exten => h,n,MYSQL(Clear ${resultid})
exten => h,n,MYSQL(Disconnect ${connid})
I haven't addressed any of Eric's issues in this. Just thought I would throw it out in case anyone wants to try it.
We're playing around with the idea of a script to load the database table with info from dids.txt. We may do that and put it in a nightly cron job.
what if you, nightly, ran a
what if you, nightly, ran a script that did this...
#!/bin/bash
echo "[on-net-numbers]" > /etc/asterisk/onnet.include
cat inbound.include >> /etc/asterisk/onnet.include
asterisk -rx "dialplan reload"
in /etc/asterisk/user_extensions.include add
#include /etc/asterisk/onnet.include
in your tenant's [from-inside-redir-tenant] add your on-net-numbers before outgoing-tenant
include => local-extensions-thirdlane
include => feature-extensions-thirdlane
include => on-net-numbers
include => outgoing-thirdlane
that would eliminate the need for a mysql lookup. Doesn't address any of the other things i mentioned, but would re-route your traffic. Once the context is included in the from-inside-redir, then they clone over on new builds if they are on the cloned tenant.
actually you dont even need
actually you dont even need the cron job...
in /etc/asterisk/user_extensions.include add
[on-net-numbers]
#include /etc/asterisk/inbound.include
and then use the include
include => local-extensions-thirdlane
include => feature-extensions-thirdlane
include => on-net-numbers
include => outgoing-thirdlane
that should make new adds immediate
Makes sense. Looks like a
Makes sense. Looks like a much easier solution. I put it in quickly, and it didn't seem to be working. Before I could diagnose it I had to back it out an move on to something else. The mySQL solution is working, so we're going to go with it for right now, and I will take another look at it when I have a chance.
Thanks!
thoughts:
do you have a plan when they dial 7 digit? 11 digit? If your national, how are you going to ensure that nxx-xxxx is in the same match in dids.txt just because the last 7 matches?
converting everything into E.164 format is the only way to make sure nxx-xxxx reaches a DID nxx-nxx-nxxx or +1-nxx-nxx-xxxx and that the matches are absolute. However, its likely you did not setup dids.txt in E.164 format.
Do you have a plan for do when you have 2 MTE servers?
If you connect both ends of the call inside MTE a few concerns:
1) CDR will obviously be non billable
2) Who gets to view CDR? There can be only 1 tenant recorded in the CDR so are you OK with only 1 tenant getting to see the record?
3) concurrent call limits will probably ignore these calls