Call return and block caller id per call script support

blocking callerid is not standard, you must contact your provider to find out how they want to do it and then write your own code. If they use remote party id it is MUCH easier than other methods.

the database storage of every inbound call reduced concurrent call counts significantly due to excessive disk i/o and putting it in tl-userexten-base was putting an undue burden on all of us even those that did not want to use it. The same thing can be achieved by storing the data in the pre-script. By default the tl-userexten and tl-stdexten are rather light and easy to clone. Put your storage in your cloned script if thats what you want to do. Be warned that this is putting quite a load on your MTE platform. My professional advice is that if the customers want to be cheap and not buy a sip device that supports callbacks (even an ATA supports this) then they can just go without the feature. Why should it cost you thousands because they want to save $20?

Hi Eric:

When we last communicated I explained that I had a customer using a pbx hooked up to a Linksys SPA2102. I told you that the DTMF tones were not being recognized properly when they call in to check VM. This is an issue we are having with some pbx's and these devices. Linksys engineers can't even get it going. You told me that this happens with some pbx's and the sip devices they connect to and said I should buy a better device. We have been using Audio Codes high end MP-118 and MP-114 devices as well as Audio Codes PRI devices. I want to move this customer onto one of these devices. They cost $400-$1200 and the SPA2102 only costs $75. Linksys has call return and AC devices do not! I also called Adtran and 2 other high end device manufacturers and none of them support call return or have the ability to remember the last inbound call number! I am so pissed. On top of that AC only supports call id blocking on or off per FXS and not on a per call basis! This customer insists on having both features and I am not happy. Their pbx has no last call memory or redial function either. Even trixbox free pbx supports *69.

The person you helped at https://www.thirdlane.com/forum/star-code-69-support seemed to get *69 going. Can you expand on that thread so I can get this going? Would using *69 for 1 tenant that hardly ever uses it drag my system down? I have no intention of supporting this in the future but this guy is killing me with this nonsense.

As far as per call blocking of caller id, the SPA2102 devices works fine with my pbx and provider using the feature. What method do they use and is it the one that can easily be configured as a *67 feature code in MTE?

Thanks as always for the help,

Larry

first of all, trixbox is NOT a MTE solution.. trixbox cannot support 10000 handsets and 1000 concurrent calls. Please do not compare MTE to that over-bloated, non QoS, piece of shit. :-) Recording inbound calls to a database might work fine when your concurrent call count is 5-10 like MANY shitbox installations are. It does NOT scale to 1000 concurrent calls. Are you even aware of the disk I/O requirements of 1000 cuncurrent writes?

the problem with https://www.thirdlane.com/forum/star-code-69-support was where the feature was included. By sticking it in tl-userexten-base I was being punished, everyone else was being punished for this feature request. The same code can still exist, but it must exist in the macro that calls tl-userexten-base so that it can be optional, not required. You can create a script that the extensions include, the only requirement is:

** Note that only scripts with phone and mailbox as 2 first arguments can be used here and that the first 2 arguments are not shown.

just close tl-userexten and add some variant of

exten => s,n,Set(DB(${THISEXT}/lastcallerid)=${CALLERID(num)})

that stores every inbound number into the database

as far as your equipment, linksys 2102's are best servicing equipment like analog phones and fax machines. The Audio Codes device, Adtran TotalAccess 900 series, Carrier Access Adit 3102 are all designed to provide analog business line service to a customer PBX. Features like *69, call-waiting and other crap like that are disabled on 1FB trunk lines mainly because they interfere with the normal operation of the PBX (especially call waiting). This is why they dont have any phone-like features on them. It sounds like you have a customer wanting you to provide phone-like services but doesnt want to buy phones? *69 is rather trite compared to the missed/received calls lists of a phone and the call log in the user portal that shows not just the last call but all calls. Hell even those home 4 handset cordless phones for homes even have a callerid 20 number history so you can call back someone 3 calls go not just the very last caller.

*69 is also never going to work correctly for hunt lists, you have no way of knowing which line's last number to dial do you? Each line is going to store a different value (this holds true for using 3 SPA2102s connected to a PBX as well).

as far as your *67 question you'd have to capture the sip invite from your ATA to find out which values are being set. My provider trusts remote-party-ID so in sip.conf I have under [general]

sendrpid=yes

trustrpid=yes

blocking callerid is as easy as this extra insertion into the channel

exten => s,1,SetCallerPres(prohib_passed_screen)

This makes the call go out as Private or Unknown (i see both from the same device to the same cellphone its 50/50 whether its marked one or the other). This method also works for PRI connected PBXes. It is _much_ easier than trying to get the P-Asserted-ID method working.

with regards to your DTMF problem is it in any way related to this bug I submitted? https://issues.asterisk.org/view.php?id=15741

If it is, create another one for the most recent version of asterisk as I cannot seem to get my bug assigned. I also think the scenario where by dialing too fast on some sip phones also creates this issue.

Hi Erik:

First, yes I am very aware of the disk I/O requirements of 1000 cuncurrent writes! My point is the CDR is already logging all the calls and writing the caller id to a mysql db. So, why is a simple DB query not able to be done saying show me the last caller to my extension and then call it back? What is the big deal? It's one extra DB query a few times a day. Looking at myCDR in the web interface does the same thing!

As far as the DTMF issue, we had it with another customer as well. Replacing the SPA2102 with an MP-114FXS fixed it perfectly. But... perhaps the reason is that with that set-up we bypassed this pbx entirely and have the device going directly to our provider. We only have the DTMF issues with the SPA2102 sometimes and not always. When we see the issue we dial at all speeds and have tested many configurations.

Thanks again for the help,

Larry

writing to a mysql database via the cdr engine is handled differently than setting an astdb key using berkleydb. writing is entirely different than reading. A putc() write application puts a lot more strain on a drive than a sequential read application. Writing to astdb with concurrent calls under a sip stress caused the PBX to crash in as few as 200 concurrent calls. Writing to astdb is an immediate transaction in the dialplan. CDR does not write till call completion, it doesn't write to the filesystem it writes to the mysql API which handles when to write to the filesystem (if its even on the same server, with mysql you can choose to offload this, there is no such option for ASTDB). I even run my CDR engine in batch mode so that a failure to connect to the mysql database does not prevent calls from routing, this further reduces read/write transactions to a further minimum.

The point is that this feature does not belong in tl-userexten-base it belongs in a customized script so that its optional. No one is saying it cant be done, its that it shouldn't be done in tl-userexten-base. It should be up to each installation if they want to do this and how they want to do it. Tl-userexten-base is used by everyone, STE, MTE, tiny machines with flash memory for storage. It needed to be implemented in a way that respects all installations, the canned scripts are used by all versions of TL not just the ISO version of MTE.