mc_ currently pulling my hairout.. why might ecall_fs_channel be missing the account_billing variable?

on an offnet-terminated call it's missing, but present on onnet-terminated call ?

both are authz'd as per_minute ?

sup -n ecallmgr ecallmgr_maintenance channel_details is what I am looking at

is there perhaps a delay in authz that misses getting it put in the ets channels table?

should it not update the ets when authz has succeced ?

i would expect it after j5 responds, yeah

but maybe channel_details doesn't include it for unknown reasons?

it does on an incoming call :/

the issue is that balance crawler is filtering ETS channels by per_minute and the outgoing call channels are missing it

gremlins then, only logical explanation

are you fetching details for the a-leg or b-leg?

both.. neither have them

offnet-termination is missing the account/reseller_billing

onnet has it

CDRs show the account_billing in the CCVs

vanguard 1049 vanguard IT etfRIGHT

er.. sorry

mc_ is there a reason why kazoo.log is logging debug consitently.. if make the same call several times in a row, randomly a large chuck of debug is omitted?

*inconsitently

perhaps rsyslog is dropping because volume is too high?

there's settings to control overload like that in rsyslog itself

would be where i look first, anyway

same with journalctl ?

seem to have both

oh, dunno, i disable journalctl for kazoo logs

mc_ how do I do that?

mc_.. it's more like lager:debug is surpressed lager:info works

where a lager:debug directly follows a lager:info.. i see the info and sometimes the debug

weird

mc_ given this github.com/2600hz/kazoo/blob/cd4922…rc/ecallmgr_fs_router_util.erl#L127

i see the 2 info but not the debug.. when setting debug do i have to flush more stuff ?

is there a more full proof way other than sup kazoo_maintenance -necallmgr syslog_level debug

handler {lager_syslog_backend,{"2600hz",local0}} already logging at debug

that is the way

lager has overload protections that you may be hitting, though i wouldn't necessarily think so

when i restart... kazoo_apps stays on debug and ecallmgr resets to info - are there defaults set somewhere?

yeah, in /etc/kazoo/core/config.ini

there's a single log section.. which set to info.. does that not apply to all nodes?

it should

so something's a bit messed up :/

ok setting ini to debug and restarting make debug work as expected

mc_... ok so ecallmgr says "waiting for authz reply" but returns immediately with "received affirmative route response" before j5 does it's stuff

something else must be repying I guess ?

whereas on inbound it waits until j5 has replied

yes, the b-leg (on outbound) is the "resource-consuming" leg that gets authz'd

the a-leg is authz'd by nature of the known device placing the call

mc_.. when I refer to inbound/outbound here.. I'm not talking about a/b channels... I mean incoming to mean an inbound call from external to device and outbound device to external global resource

it's outbound i am having issue with

so are you saying you'd expect to see 2 authz 1 for each channel a/b ?

barney__: authz per-minute on the b-leg of the outbound call

the "resource consuming" leg

where "resource" = carrier

mc_ as far as I can tell.. ecall_fs_router starts an authz worker for the inbound leg and only puts the authz data for the inboud leg in ecallmgr_channels ETS table... Jonny authz both a and b channels and stores the authz data in jonny_channels ETS table

barney__: CCVs for the outbound b-leg should include the data, but ecallmgr may not have it in the channel cache

i don't recall offhand

mc_ I am thinking that as balance_crawler looks for channels that has account_billing = per_minute. in ETS ecallmgr_channels it should be calling j5_channels:get_per_min chans that peeks in jonny_channels instead?

i mean if J5 has it's one ETA channel cache for authz data, then that should be the authoritive not ecall's ?

**its own ETS Channel cache**

mc_ it seems that the whole ecallmgr has been reworked in github main which hasn't made it to 4.3?