Jump to content

Limits and Billing for accounts


Recommended Posts

Hello,

I'm evaluating Kazoo for replacing my current kamailio+asterisk+custom routing supporting about a thousand end points. The billing/fraud prevention seems to raise some questions in my mind.

Is there a way in kazoo to support prepaid and postpaid customers ?

Can calls be interrupted at specified max duration, credit exhaustion, daily/weekly/monthly spending limits ? Also, can duration for the calls be determined in real-time by the dialed destination number ?

And last but not least, what is the best place for documentation and getting some paid support from the developers ?

Thank you.

Link to comment
Share on other sites

 

Hi Kazte, 

I am also in the same process at the moment , therefore I would like to know the answer for this question.   

So far, I have managed to get service plans working in Kazoo 4.3 using the new services API documentation posted in  github/2600hz.. kazoo/core/kazoo_services 

I also managed to add a couple of rate documents in ratedeck database and I can see the rate to be applied using SUP command. However, cdrs still don't show the call being rated.   For this part, I used https://docs.2600hz.com/sysadmin/doc/kazoo/call-rating

 

Finally , Jonny5, after setting limits document for my test tenancy, installing kazoo-application-jonny5 and loading the application Jonny5, I still can't find the way to limit calls by balance run out, or any other type of limit.  For this bit, I am using this https://docs.2600hz.com/sysadmin/doc/whapp/jonny5/

I hope we could share information and figure it out

 

 

Link to comment
Share on other sites

  • 2600Hz Employees

For support, free options include this forum and IRC; you can email sales@2600hz.com to see about dedicated support plans.

For open-source builds you are probably best served with the 'dev' docs site: https://docs.2600hz.com/dev/

Also the 'sysadmin' docs site: https://docs.2600hz.com/sysadmin/

Both are great places to contribute to the project if Erlang code isn't something you want to take on at the moment.

Link to comment
Share on other sites

Thanks jes_tovar and mc_. I'm getting my feet wet in the whole kazoo thing. It's been a quite a bite for the last few days: erlang, couchdb but mostly I'm struggling with the docs and getting to know what is what and how things fit together, like why johnny5 is called so, and what does it do ? Hot-or-not: hilarious.

I'm trying to see if I'm able to configure kazoo more into a europe-based way of doing things (numbering, translations, taxes) and it does not seem to be achievable without learning a little (most, who am I kidding?) of how it works internally. I'll probably have to ask more than a couple of questions in the process, so please bear with me.

Link to comment
Share on other sites

  • 2600Hz Employees

jonny5 is a reference to the movie Short Circuit; the kazoo app tracks limits and balances for accounts and does authorization for resource-consuming calls. In other words, it short-circuits calls that are not authorized :p

For numbers, check out https://docs.2600hz.com/dev/doc/internationalization/numbers/

You'll probably want alternative prompt languages too: https://docs.2600hz.com/dev/doc/internationalization/prompts/

While most of the 2600Hz team is US-based we do have a number of devs outside the US as well as a group of community members outside the US too. We all want KAZOO to be a proper platform for any region of the world. That said, we also know we have blind spots of how telecom is done everywhere so any feedback you have which can be incorporated into the project for everyone to take advantage of, is greatly appreciated.

Also, when you feel you need to look at code or the docs aren't sufficient, ask here in the forums - that's usually a good trigger for someone to take a stab at improving the documentation. You are always welcome to submit PRs for improved docs as well.

Link to comment
Share on other sites

  • 1 year later...

It's been 18 months but I haven't dropped my hopes for putting kazoo in production ;) Hopefully I can understand erlang a little better this time and ask not so simple questions.

I'm based in Europe in a non English speaking country with a different currency than the dollar and different market expectations, so I'm facing somewhat of a steep ride. My major concern is fraud prevention and spending control for all accounts.

TL;DR: I'd like to understand if it's possible to terminate all calls for an account when some condition occurs (tipically low-credit event), in the middle of a call or multiple calls.

Here's my current handling of limits, fraud prevention and rating:.

I have Upstream providers (telco) and downstream Resellers and End users. I understand kazoo can accommodate hierarchies of accounts, but I'm not sure how they're checked on a live call and what happens exactly when a limit is breached.

Here's the description of the credit based part of the fraud control: 

  1. The main account can only consume X amount of credit (euro) per day/week/month, using it's own Rates (tied to the variable upstream provider).
  2. The reseller can only consume X amount of money, (euro, pounds, other) per day/week/month using transfer rates from the main account. There's a new "ratedeck?" for each reseller.
  3. In turn, the end user can only consume X amount of money as the reseller, but based on their own ratedeck.

The fraud control at the moment works like this:

  1. Each time interval (one or few seconds) we calculate the current total due for all running calls for each account (main, reseller, end user) and compare that to their allowance (per total credit or day/week/month). 
  2. When we determine that the account is over it's allowance, *ALL* calls for the account are terminated in an instant. Usually this means the credit for the account is 0 or below it's threshold. 
  3. New calls will usually not be allowed as the credit is 0.

I see jonny5 has some provisions for credit checking, for prepaid/postpaid accounts but I'm not sure how often it is called and if it's called for all accounts involved (or at least for all reseller/end user accounts) on each call. 

Also how does hotornot fit in the whole picture?

I hope I'm not overcomplicating things here.

Thank you

Link to comment
Share on other sites

@kazte, yes, what you are after is possible. You can have pre-paid or post-paid accounts. You can apply a limit to post-paid accounts too. In the event an account exceeds its limit, it will terminate calls. You simply need to set an account to be pre-post paid and set the limit. You also need to ensure the Jonny5 app is running.

By default, limits are per-month (though you could use the API to "top up" an account or change its limit on a more frequent interval).

Limits apply to resellers also. When an account underneath a reseller account makes a call, the reseller account is also charged for that call. Likewise the root/superadmin account by default is also charged for the resellers calls (charges all the way up the chain). Each account may be charged a different rate (based on their ratedeck). You can choose NOT to charge a specific account (useful for the root/superadmin account) by using "flat rate trunks".

Ratedecks can be at the system, reseller or account level.

Hotornot is the app in charge of figuring out how much to charge for a call (it does the call rating)

Jonny5 enforces the limits (it does limiting). I personally do not know how often Jonny5 checks limits/credit.

Link to comment
Share on other sites

Thank you. 

It's good to know jonny5 can terminate calls in progress rather than wait for them to finish. 

The balance check seems to be "by request". Jonny5 has a responder to "j5_balance_check_req". It answers to some request on a higher api for "balance_check_req".

This request seems to come from worker in ecallmgr (ecallmgr_balance_crawler_worker) that issues the balance_check_req via an internal "send_req" function. There's a disconnect_accounts function called in case of a need to disconnect.

Here's an extract from the worker. 

-define(INTERACCOUNT_DELAY_MS, kapps_config:get_integer(?APP_NAME, <<"balance_crawler_interaccount_delay_ms">>, 10)).
-define(FETCH_TIMEOUT_MS, kapps_config:get_integer(?APP_NAME, <<"balance_crawler_fetch_timeout_ms">>, 10000)).

-spec start() -> no_return().
start() ->
    case ecallmgr_fs_channels:per_minute_accounts() of
        [] -> exit('no_accounts');
        Accounts ->
            lager:debug("get balance for ~p account(s)", [length(Accounts)]),
            DisconnectAccounts = send_req(Accounts),
            'ok' = disconnect_accounts(DisconnectAccounts),
            exit('work_done')
    end.

If I read this correctly, all accounts are checked continuously, with a 10ms delay between accounts and a 10 seconds timeout on each request for the balance.

Do I understand correctly, or am I missing something ?

PS: It seems interaccount delay and timeout are read from the ecallmgr config. However the 10ms delay seems to apply to the disconnect function of calls and not to the cheking of balance which seems continuous (without delays). Anyone can confirm this?

Edited by kazte (see edit history)
Link to comment
Share on other sites

×
×
  • Create New...