Dialer skipping leads with LRERR

[ccabrera]

A client of us asked to have a "manual predictive dialer" (or so we call it). This means that the agent should hear all the ringback for every call, but he shouldn´t dial directly: the system should do it. They want to use their own humans to evaluate whether a call is busy, answering machine, etc.

So, what we did is create a custom trunk which does a loopback and goes into the same SIP trunk as always BUT pre-answering the call.

Each agent has a campaign of their own. They do not want to share accounts and all the leads must come in PERFECT order. Why? Because they still use paper for tracking the accounts so the lead order is important otherwise their archaic process gets messed up and papers cannot be search for with Ctrl-F. So what we did was to set all the campaigns on a 1:1 ratio. Since all the calls get pre-answered the solution should be pretty straightforward: Vici dials 1 call, call gets answered immediately, then the call is sent to the agent.

This has worked very well but there´s a small flaw we run into from here to there. Sometimes, like 1 in every 100 leads, gets skipped. When we go to the call log we see that the lead wasn´t skipped, but rather was disposed as LRERR, so Vicidial goes into the next lead and our client gets angry because the system "skipped" one record.

I´ve looked at the phone numbers for this LRERR and they look alright. I can dial them manually, I can dial them again using the predictive, it´s just that sometimes this happens and sometimes it doesn´t.

Does anyone have any idea what could be happening?

Is there a way to tell VIcidial to follow a very VERY strict order and if a record cannot be dialed then let us know or ask for confirmation before the next lead is dialed?

[mflorell]

LRERR status only happens when an agent session is terminated improperly. As in, the agent closes their web browser before dispositioning a call or their computer loses network connectivity. That's the only way that status happens.

[ccabrera]

So, I guess that if I dig deep enough into the logs, I´ll find that the agent logged out, the record "skips", then logged back in, then they complain?

[mflorell]

How it works is the lead is in INCALL status, then when the agent logs back in it changes the status to LRERR.

[nandotech]

Hello all,
We have several ViciDIAL systems up and running with varying numbers of agents.

Previously, we would only see this error come up for a very few number of calls (80 for 70,000 calls, for instance) where this explanation makes perfect sense.

Suddenly, since last week, across several high volume systems with minimum 30+ agents we started to see around 10% of calls placed on any given day give off LRERR. In many cases, these are bad phone numbers (which makes sense). However, we are seeing an unusually high amount of it and very often to numbers that we KNOW are good phone numbers. Sometimes when the dialer re-attempts, you'll even see an agent spoke with them.

Because at the same time we had added a new dialer, we considered maybe it was a bandwidth issue (as we did seem to be scraping near our maximum). However, we tested again under minimal load conditions (only 1 dialer system up and running with 9 agents) and the percentage of LRERR calls was the same.

We do not NAT any IPs, and every server has their externip set in sip.conf
Any ideas here? Any other thoughts what our issue might be? Everything else seems fine. Agents are fine getting plenty of calls and the call centers are running smoothly. It is clear to us that there is some issue or we could be completing more calls, and nothing has changed in any configuration, we just suddenly noticed an extremely high jump in the number of these dispo's.

Thanks in advance for any help!

[williamconley]

Heavier load systems losing contact with the agents. Or more agents = more agents who "just close their browsers" instead of logging out.

[nandotech]

Heavier load systems losing contact with the agents. Or more agents = more agents who "just close their browsers" instead of logging out.

I'd love to chalk it up to that, William.
When I pull stats, my client with only 5 agents over the last 8 days has seen it go from 1% of calls to 15% of calls.

There's definitely a disconnect happening somewhere, we're just not sure what it is.

For sake of helping provide insight:
The only other variable: we use a WebRTC2SIP-based webphone that has had no issues supporting all our systems.
When we added this client, the CPU load became too much for that server and so we created a couple of separate webphones to split up some CPU load.

My current working theory: if all 3 webphone servers are assigned to use the same range of RTC or RTP or WS ports, could that be causing a conflict where Vici is receiving no sound on these calls?

[williamconley]

You just said "i don't think it's load because there are only 5 agents" followed by "when we added this client the system overloaded so we made some changes to reduce the load".

I'm pretty sure you validated my theory. Vagueness surrounding your changes notwithstanding ... if you have increased server load followed by increased LRERR reports, you likely have not resolved all your server load issues just yet.

Either add more servers or increase the power of your central DB server ... or have someone troubleshoot the load issue directly.

(IMHO)

[nandotech]

....
SO let's say I have 10 clients.

I first noticed this when I added client 10, who has a lot of seats.

But, today symptoms continue and I'm getting LRERR when he only had 9 agents and there were NO OTHER clients online whatsoever.

There's no CENTRAL db server or need for more servers...
Each and every client has their very own DB and separate telephony and web servers.

My point was that even a client with a very small all-in-one server is starting to see an increase in these numbers.

Very helpful, you are. People usually pay you for this kind of help? Lol...I said I experienced increased load ON THE WEB PHONE. We alleviated the issue.

[nandotech]

You just said "i don't think it's load because there are only 5 agents" followed by "when we added this client the system overloaded so we made some changes to reduce the load".

I'm pretty sure you validated my theory. Vagueness surrounding your changes notwithstanding ... if you have increased server load followed by increased LRERR reports, you likely have not resolved all your server load issues just yet.

Either add more servers or increase the power of your central DB server ... or have someone troubleshoot the load issue directly.

(IMHO)

I'm not sure how my saying my client who only has 5 people dialing has seen a tenfold increase in LRERR validated your theory that more ppl = more accidental browser closes.

[williamconley]

When we added this client, the CPU load became too much for that server and so we created a couple of separate webphones to split up some CPU load.

[nandotech]

"That server" being the webphone.

Which is a completely separate server.

So, what you're saying is you have no idea? Thanks bud

[puneet_143]

Hi ccabrera,

" custom trunk which does a loopback and goes into the same SIP trunk as always BUT pre-answering the call"

Can you please share the custom trunk and dialplans to achieve your client requirement.

[puneet_143]

A client of us asked to have a "manual predictive dialer" (or so we call it). This means that the agent should hear all the ringback for every call, but he shouldn´t dial directly: the system should do it. They want to use their own humans to evaluate whether a call is busy, answering machine, etc.

So, what we did is create a custom trunk which does a loopback and goes into the same SIP trunk as always BUT pre-answering the call.

Each agent has a campaign of their own. They do not want to share accounts and all the leads must come in PERFECT order. Why? Because they still use paper for tracking the accounts so the lead order is important otherwise their archaic process gets messed up and papers cannot be search for with Ctrl-F. So what we did was to set all the campaigns on a 1:1 ratio. Since all the calls get pre-answered the solution should be pretty straightforward: Vici dials 1 call, call gets answered immediately, then the call is sent to the agent.

This has worked very well but there´s a small flaw we run into from here to there. Sometimes, like 1 in every 100 leads, gets skipped. When we go to the call log we see that the lead wasn´t skipped, but rather was disposed as LRERR, so Vicidial goes into the next lead and our client gets angry because the system "skipped" one record.

I´ve looked at the phone numbers for this LRERR and they look alright. I can dial them manually, I can dial them again using the predictive, it´s just that sometimes this happens and sometimes it doesn´t.

Does anyone have any idea what could be happening?

Is there a way to tell VIcidial to follow a very VERY strict order and if a record cannot be dialed then let us know or ask for confirmation before the next lead is dialed?

Hi ccabrera,

" custom trunk which does a loopback and goes into the same SIP trunk as always BUT pre-answering the call"

Can you please share the custom trunk and dialplans to achieve your client requirement.

[williamconley]

Carrier Dialplan Entry for outbound autodial and manual dialing:

* Dial Prefix: 9711
* Manual Dial Prefix: 9

Code: Select all

exten => _97111NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _97111NXXNXXXXXX,n,Dial(${TRUNKloop}/9${EXTEN:4},55,o)
exten => _97111NXXNXXXXXX,n,Hangup

exten => _91NXXNXXXXXX,1,AGI(agi://127.0.0.1:4577/call_log)
exten => _91NXXNXXXXXX,n,Dial(SIP/FreeSwitch/${EXTEN:1},,To)
exten => _91NXXNXXXXXX,n,Hangup()


* 3 Way Dialing version already in /etc/asterisk/extensions.conf

Code: Select all

; This is a loopback dialaround to allow for hearing of ringing for 3way calls
exten => _881NXXNXXXXXX,1,Answer()
exten => _881NXXNXXXXXX,n,Dial(${TRUNKloop}/9${EXTEN:2},,To)
exten => _881NXXNXXXXXX,n,Hangup()