much needed feature

New features you'd like see on SIP Sorcery
Post Reply
Posts: 17
Joined: Sun Nov 18, 2012 8:11 pm

much needed feature

Post by shahram » Tue Mar 26, 2013 4:21 am

I have been trying and trying to figure out a way to build a solid, professional framework around sipsorcery to be able to manage and calculate the costs of calls for a small group of accounts correctly, but I don’t think its currently possible.

I would like to ask if it is possible to add this feature that at the end of the call (ie BYE), an action can be triggered (eg specific dial plan execution) with the details of that call that just finished so it can processed.

Here is the situation, lets say a user has 60 min of credit (in reality it would calculating based on destination and costs, but lets make it simple for this argument) on his account, outgoing plan would use the “sys.WebGet” to send the call to my server so it is saved in my database, and checks if the user has credit left to make this call and limit the call with the amount of remaining credit,

after the call is initiated, my script will have to be constantly pulling the CDR list using the REST api, so when the call is finished it can calculate the remaining credit for this user,

beside the extreme strain that it would put on your server, lets say when the users call is disconnected (or dropped, etc), if the user attempts to quickly redial (which I think would happen a lot), and if this happens before my server has a chance to pull the appropriate CDR, then the previously used credit will not be accounted for and the user will be using the credit he doesn’t have,

and working with CDR list, I have noticed some instances that for calls that were successfully connected, the BridgeID of one leg were “00000000-0000-0000-0000-000000000000” (mostly the IN leg) and I can only match it to the other leg “maybe” with the time when the call was initiated, and there were some IN’s that were not matched!

here is what I wrote to analyze the CDRs, I have tried to be thorough, but I know it has the potential to miss something:

so if I can’t get a clean match, and can’t find out the “source of the call” from the IN Leg, besides the fact that I might miss calls, if lets say I had a mechanism to limit other calls until I have the CDR for the current call (that is my server knows the call was initiated so any further requests are denied), then the account could end up in an endless loop of being denied, because the matching CDR was never found, and it probably has to be dealt with manually

so it would just be a system begging for problems!

But here is my argument, if I had a chance to lets say execute a dial plan at the end (sys.Dial can be disabled in it) which has the info about the finished call and the current users involved, the possibilities would be endless,

I could just send the exact call details to my server in one WebGet call (no need to put a strain on your server for an updated CDR), and I would be sure this call details is for this specific user, so no mistakes

I could even use the DBWrite and DBRead to its fullest potential, that is eg outgoing plan sets the “call in progress” in the database, and end plan would clear it after it has updated my server with the call details (and/or it could lets allow unlimited sip/local calls, but not the pstn calls until the current call has ended),

and if by any chance WebGet fails to send the details to my server (network problems, downtime on my server, etc) it could be saved in DB and the next time the outgoing plan runs, it retries the update before the call, and before requesting for the remaining credit

Maybe even the whole thing can be done in your DB (that is for example without the need for call history, one DB entry holds the credit remaining and at the end of the call the entry is just updated), so there would be no need for calls to external servers with WebGet, and if the user wants the CDRs, then it could be retrieved via the REST API

And many more things that I think, the end result of it all would be more possibilities for us and fewer resources used on your side.

User avatar
Site Admin
Posts: 4569
Joined: Thu Jul 12, 2007 12:13 am

Re: much needed feature

Post by Aaron » Tue Mar 26, 2013 9:29 am

I've actually already built a real-time call control feature which is currently being beta tested. It can do billing based on call prefixes, authorise calls based on available credit etc. The feature is only available on Professional level accounts, if you'd like more info email me at

Posts: 17
Joined: Sun Nov 18, 2012 8:11 pm

Re: much needed feature

Post by shahram » Thu Mar 28, 2013 2:18 am

email sent.

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest