vicidial_carrier_log table remains empty

[sqlerror]

VERSION: 2.8-417a
BUILD: 131019-0849
Revision: 2039

With this new install we encounter that the MySQL table vicidial_carrier_log remains empty.
Carrier logging is set to 'Y'.

Do I forget a setting or is this table only used by ViCiDial when doing automated outbound calls?

Any help is much appreciated,

Geert

[DomeDan]

In your carrier dialplan entry, did you add "AGI(agi://127.0.0.1:4577/call_log)" like in the example carriers?

[sqlerror]

In your carrier dialplan entry, did you add "AGI(agi://127.0.0.1:4577/call_log)" like in the example carriers?

Yep ...

[williamconley]

only used by ViCiDial when doing automated outbound calls?

Yep.

Inbound calls have other tables.

[sqlerror]

only used by ViCiDial when doing automated outbound calls?

Yep.

Inbound calls have other tables.

Hi Wiiliam,
Yes, I am aware of that inbound calls have other tables.
The situation is that I need to be able to report duration and status of outbound calls that are placed manually using 3way tranfers on inbound calls to external destinations.

So how would I identify the call details of the third call leg in a 3way consultative transfer if manual outgoing calls are not logged in the carrier_log table even if these transfers are placed via our outbound SIP carrier ?

[williamconley]

I believe 3-way calls are treated as manual dial calls. different logs. each type of call has at least one log table.

make one, and see which logs it appears in. note that after the call terminates, the "hangup" command will initiate a cleanup script that puts the appropriate length of call on the record so all your data should be available in the log when you do find it.

[sqlerror]

Hello William,
I can find the outbound call in that is part of a 3way-call but I guess I need some custom destination in the dialplan to be able to link the outbound call to the inbound call from where the 3th party has been called.
The situation is that the customer has an online reception service and both the incoming call and the external transfered calls must be reported for usage and billing.
The most useable data I now can use are in the recording_log, but that will need no delay with recording what might effect perfomance.

[williamconley]

all calls involved SHOULD be linked to the lead_id for that lead. And since that lead should be connected to your client (based on DID from which it arrived?) you should be able to assemble what you need with mysql using the lead as the common thread.

[sqlerror]

I was trying to follow channels and contexts, your lead id(ea) is the track I will now follow. Thanks for the hint!