GSM Gateway stop sending SMS using HTTP SMS

Hi,

I'll help you with your problem. For convenient contact, could you add my skype to your contact list, please? And prepare remote access for checking, please.

Best regards,
Linda Li
skype: linda.li258
email: This email address is being protected from spambots. You need JavaScript enabled to view it.

I stopped using the gateway for now due to this problem. Maybe ill just contact or post here again in case i will use it again.

So sorry for the http2sms issues and delay reply.
We are entering the home stretch of SIM bank project and lack of human resource, pls give us one more time, we will fix it once it is finished.
For now, if possible, pls setup crond job to reboot asterisk to amend the issue as redealujmni mentioned above.
Thanks for your understanding.

Hi Tim, it would be really great if you could fix this ASAP, it reduces greatly the effectiveness and send rate of your SMSs solution.

I am testing the SMS http API on 3 separate VS-GGU-E2M0400 boards now, and it happens on all of them (all on 2.1.3). It happens when you make parallel calls to the SMSs API, eventually the API on the board will hang and only reply with blank responses until the board is rebooted. It happens even with only 2 jobs/queues, with only 2 chips on the same board, and calling the API with a delay of 30s per SMS, the board will hang in a few hours. If I use 4 jobs and the board complete with 4 chips, the board will in less than one hour (with 30 seconds delay between API calls). Just like amieru reported, if you send SMSs sequentially without and delays, the board will hang pretty fast after a few SMSs.

As long as the board replied with "fail" or "busy" when parallel call were made there wouldn't be a problem for me (as my workers will retry latter if it is unable to send an SMS). But having the board 'hang' until it's rebooted is horrible. Since this can happen again in less than a few minutes after it is rebooted, and the board can only be periodically rebooted every hour, each board can be unavailable for more the 80% of the time.

As long as I tested, the issue will not happen if you only make one call at a time per board. I have one board running with one chip only, with only one job/worker sending SMSs sequentially to it, it hasn't hanged in more than 12 hours.

I would really like to use Openvox in production, to send SMSs for our (very large) web site (in Brazil). I would then buy several units full of boards. But if this isn't fixed, I will have to look for another solution.

Thanks! Best, Bernardo

Correcting what I wrote, the issue DOES happen even when you only call the SMS HTTP Api once at a time, as long as you have more than one chip on the board. I changed my code to use only one queue per board, that way I will never make a call to the API on one board before it replied to the last call. My two boards, running with 2 chips each, had the issue after sending SMSs for a few hours (on a slow pace).

It just doesn't happen when you have only one chip on the board. My other board, with only one chip, kept sending for more than 24 hours, without ever locking up. But it obviously doesn't make any sense to have an expensive gateway like that and put only one chip on it (out of the 4 it supports).

Please, fix this issue ASAP so I can buy more of your boards to put the project in production. I really don't want to have the hassle of be looking up at other brands of GSM gateways...

Thanks for your feedback, we will look into it asap.