Recording location with *010*010...

[Vince-0]

Hi,

I have 2.10 build from 2014 (I know...) install that gets this format in the recording location:
http://10.10.10.10/RECORDINGS/MP3/20160 ... 66-all.mp3

The campaign call recording format is set to FULLDATE_CUSTPHONE.

Anyone else seen this?
I've turned off load balancing in case it has something to do with that.

Is the 010*010*... extension because the call is being transferred?
Can I change it to the actual customer number?

[mflorell]

That's usually an issue with the wrong Asterisk version being set in "servers" so the call is using the wrong dialplan variables when the recording filename is set.

[Vince-0]

Thanks Matt,

It is set correctly to the Asterisk version 1.8.23.0-vici.
After trying OS update I see this server is still running on OpenSuse 12, I'm going to make a plan to migrate it to a new OS and see if there is any progress with this problem.

Vin.

[williamconley]

Thanks Matt,

It is set correctly to the Asterisk version 1.8.23.0-vici.
After trying OS update I see this server is still running on OpenSuse 12, I'm going to make a plan to migrate it to a new OS and see if there is any progress with this problem.

Vin.

Given the odds you would do much better with an upgrade of Vicidial than the OS. The OS is not making the decision to name the file, the Vicidial scripts are. And (as you observed), you are using an old version of Vicidial. In fact, you're using what I consider to be an intermediate version. We have no clients on it. Clients have all jumped from 2.4 to 2.8 to 2.12. No one is on 2.6 or 2.10 because they appeared to be a bit buggy. Simpler to skip 'em. In your case, if you jump to 2.12 you may be suddenly fixed.

And be careful with the OS update silliness. Whitelist lockdown your server and stop with the updates. Updates risk breaking the Vicidial system by altering underlying packages while offering no likelihood of improvement other than possible security updates. (Thus the whitelist lockdown, reducing your security exposure dramatically.)

[Vince-0]

I upgraded to latest 2.12 with no change.

From the user stats page,
I noticed that it seems to be only manual dial calls with call type PHONE_DIAL that result in the file name pattern for the phone number 010*010*010*010*8600.
Other call type MANUAL_DIALNOW doesn't result in that file name pattern.

I have disabled keypad dialling by setting all the phones' phone_context to "agent-nodial".
So, what's PHONE_DIAL call type?

[mflorell]

PHONE_DIAL is only used by the agi-NVA_recording.agi script.

[Vince-0]

Matt!

So how could that script be getting executed if all the phones' phone contexts are set to agent-nodial?

I see calls coming through the defaultlog context with that format.
[Aug 8 13:38:54] VERBOSE[30360] pbx.c: [Aug 8 13:38:54] -- Executing [010*010*010*010*8600056@defaultlog:1] AGI("IAX2/92324911-12412", "agi-NVA_recording.agi,BOTH------Y---Y---Y") in new stack

[mflorell]

No clue, you'd have to look and see where those calls are coming from in the Asterisk CLI and possibly the action log files in /var/log/astguiclient/ directory.

[williamconley]

Matt!

So how could that script be getting executed if all the phones' phone contexts are set to agent-nodial?

I see calls coming through the defaultlog context with that format.
[Aug 8 13:38:54] VERBOSE[30360] pbx.c: [Aug 8 13:38:54] -- Executing [010*010*010*010*8600056@defaultlog:1] AGI("IAX2/92324911-12412", "agi-NVA_recording.agi,BOTH------Y---Y---Y") in new stack

Perhaps those calls are not connecting? (But the agents are still trying ...)

Or perhaps you "thought" you changed them all but overlooked a couple. The asterisk logs should tell the tale.

[Vince-0]

William!

It could be that those calls aren't connecting. The agent stats page with those recording items in it shows 0 call durations.

I'm sure I changed all phone_context records, via a database update statement so it's impossible to have missed any.
Asterisk 'sip show peer x' shows Context = agent-nodial.

I will investigate further today.

[Vince-0]

I found the same problem on a different server, running SVN
VERSION: 2.12-560a
BUILD: 160617-1427 from Vicibox 6.0.4.

From an example modify lead page, RECORDINGS FOR THIS LEAD.
Campaign recording format is FULLDATE_AGENT_CUSTPHONE_LEADID.
The first record is fine. The second one has call duration and the _010*010*000*110* and the third is just 8369, 0 call duration.

SECONDS:
114
FILENAME:
20160811-091532_22781_#########_55096
LOCATION:
http://10.10.0.110/RECORDINGS/MP3/20160 ... 32_22781_#########_55096-all.mp3
..

SECONDS:
76
FILENAME:
20160811091526_22781_010*010*000*110*8600052
LOCATION:
http://10.10.0.110/RECORDINGS/MP3/20160 ... 52-all.mp3
..

SECONDS:
0
FILENAME:
20160811091522__8369
LOCATION:
20160811091522__8369


Here's a screenie of another example - calls to this lead don't match recordings for this lead:

[img]
https://ibin.co/2rAyNRDB0HW5.png
[/img]


I will investigate further. I wonder if anyone else has seen this before.

[Vince-0]

These are actually duplicate calls (from the screenie)

The ones with the broken file name EG ...010-010-010-010-8600052.wav start a bit earlier in the call and include the beep sound on the agent connect.
The normal format ones do not include the beep sound and are slightly shorter.

So! Not a massive issue but it is very strange that it is inconsistent, I just can't figure out why.
It seems to only happen with auto dial calls and not manual dial calls.

I will investigate further and try to reproduce the problem.

[Vince-0]

Turns out I have defaultlog set as Default context in the server config page. This should be "default".
The 010-010-010-010.. part is in fact the server IP address translated into a dialplan.

Then, there's this in the extensions-vicidial.conf defaultlog context:
<code>
; custom dialplan entries
exten => _X.,1,AGI(agi-NVA_recording.agi,BOTH------Y---Y---Y)
exten => _X.,n,Goto(default,${EXTEN},1)
</code>

Even though I have custom dialplans turned off.
Obvious! But that's why it looks like the call recordings are duplicated.

So the fix is server config page "Default Context: default"
I guess some other nab made a mistake

[williamconley]

Good postback. Showed the entire process, too.