kazte

Spot on @godril . It's sunday here but I could not resist to look at the trunkstore code and it does exactly this. Thank you!

The token restrictions for an account could be a checkbox in the accounts app when creating a subaccount (I.e. a reseller account could be able to just forbid new device creation, or even device updates). Regarding CLID control, In my current home-made module for asterisk, I do this during the call authorization phase. My module will query all available DID for an account. If the CLID presented by the device is not within them, I override the CLID with the first available DID and place and upstream the call. This allows the call to progress and the customer will probably understand. My guess is that in kazoo this would be a ecallmgr task. Would it be possible to modify the CLID on the fly? If not, perhaps jonny5 could just not authorize the call when CLID != DID ? Perhaps the numbers application (which I'll look at later) has a document with all assigned DID for an account ?

Hello, I have the need to limit the number of devices created by an account in their call flow app or their smartpbx. I understand I can bill them "by device", but I would like that only resellers be able to add devices, while end users shall only "use" them. I would also need to control the CLID that is placed in the device parameters. Ideally only CLID that are "mapped" as DID for an account shall be accepted. I think this is a common compliance requirement, to avoid one device impersonating an arbitrary number. Alternatively, when a device uses a CLID that is not "owned" by the account, it should be overridden by kazoo with a "random" number from their DID pool, or the call should be dropped all together. Any hints on how to achieve the above?

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?

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: 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). 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. 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: 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). 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. 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

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.

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.