vicidial.org

Good Day Vicidial Team,

First thanks for all the help and thoughts, we already set up a working vicidial system both inbound and outbound.

But we noticed that when we do outbound, we get a lot of this status: PDROP - Pre-routing dropped call.

Any thoughts, suggestion, recommendation would be highly appreciated ...

Thanks again and more power ...

These are calls that are dropped very quickly after the Answer signal is received from the carrier, but before the call is processed by the routing AGI script. Previously these would sometimes be left as NEW(or the previous status) or DROP. This standardizes the result.

Thanks matt, we figured out where's the choking point in our setup ...

Matt how can i change the PDROP default status to be NEW without me updating it manually?

couldn't you set up a script to run once a day when the call center is closed to change these?

Thats a great suggestion KDell however my goal is to make the PDROP statuses to be NEW for real time reports purposes ...

Vicidial Team,

Is it possible to make the status to be tagged as its previous status if its a PDROP?

If yes, how and where can i do that?

Thank You ...

The call is dialed and answered, so it is not the previous status. Would you just want to ignore all DROP statuses as well?

Matt,

Just the PDROP Matt, so if a phone is called and its NEW then became PDROP, the NEW status will retain, same goes for all statuses, if it was answering machine eg: ANSMA then i recycled ANSMA and it was Pre Dropped: PDROP, then status should be ANSMA still.

Is it possible?

Why would you want to ignore PDROP and not DROP?

Matt,

Correct me if im wrong but based on my understanding, PDROP did'nt reach the prospect while DROP reached the prospect but there we're no available agents to get the call, so PDROP is recyclable depending on its previous status.

a PDROP is an Answer, the line answered and hung up very quickly.

Oh ok, tnx matt, how do you think i can eliminate the PDROP?

There really is no way to eliminate PDROPs while auto-dialing, although there should not be that many of them. If you want to get rid of all DROPs and PDROPs you would have to switch to manual dial.

Matt in your professional opinion, where do you think im having problem?

Here's my setup:

DB->Telephony/Web->Asterisk Voice Gateway Facing Internet->SIP Trunk Provider

I have 1 Telephony on LAN and it forwards all the outbound calls via IAX2 trunk on the Asterisk acting as Voice Gateway then passes the call to our SIP Provider.

All is well except we have 60% of out entire outbound call ending on PDROP.

I already tried native SIP Trunk between Telephony and Asterisk Voice Gateway but its the same.

What do you think causes the PDROP?

Thanks for the patience Matt ...

That is a huge PDROP percentage. Have you tried not using a gateway and just connecting your trunks directly to your ViciDial server?

mflorell wrote:That is a huge PDROP percentage. Have you tried not using a gateway and just connecting your trunks directly to your ViciDial server?

Yes thats my first setup then i tried to hide the extensions inside LAN by using the Asterisk Voice Gateway. The results are still the same ....

Have you tried a different SIP carrier?

mflorell wrote:Have you tried a different SIP carrier?

Not yet Matt, we only have 1 SIP Carrier. But if its on the SIP Carrier side, then what are the possibilities that may affect the calls thus PDROP?

We have seen carrier issues cause issues like this before.

mflorell wrote:We have seen carrier issues cause issues like this before.

How did you and your carrier resolve the PDROP?

the client moved to another carrier and never had the problem again.

mflorell wrote:the client moved to another carrier and never had the problem again.

Do you have any SIP Carrier recommendation/s so that we could try them both at the same time?

We have had pretty good luck with Vitelity. But it is always good to have more than one carrier.

I generally require clients to have three carriers to begin with paid employees seated (ok: I suggest it strongly enough to scare them into it ...).

Hi Vicidial Team,

Matt/William, as i dig in to this PDROP, do you think this error on the CLI is related?

[Jun 6 12:13:02] WARNING[23613]: file.c:1297 waitstream_core: Unexpected control subclass '-1'

Now we also experience dead air on outbound calls. Like when the call comes to our outbound agents they dont hear anything, next call is good and same scenario repeats.

What do you think about this guys?

Thank You ...

It is possible, but we also see those on campaigns that have very few or no PDROPs, so it is not a certain indicator.

Matt, do you happen to have figured or have a workaround/solution for the said error?

It is not an error, it is a warning, and to date we have not found any negative effects from it.

How about this warning message Matt:

[Jun 6 16:13:10] WARNING[8308] app_dial.c: Unable to forward voice frame

what are your thoughts about this?

That could be an issue, but does it happen at the same time when you get one-way or no audio on a call?

Im not really sure Matt coz the CLI is really fast and im just capturing this messages using grep on the ssh shell.

But waring message happens occasionally as well as the dead air/no voice ...

Matt,

Me and my team researched a bit more on the BTN's that was tagged as PDROP. We manually dialed those numbers and the result was: out of a hundred, 80% of the calls were Operator Intercept / Machines, e.g. Fax, Tritone etc.

Is it safe to say/conclude that BTN's tagged as PDROP are Operator Intercepts / Machines?

That very well could be the case if your carrier handles those calls in that way.

Hi,

I just noticed we had about 60 PDROP leads in our system. My question is how can we dial these records again because PDROP is not in the list of system statuses and i can't add this as a dial status to a campaign because it is not in the drop down list.

I called one of those numbers and i got a person on the phone so not sure if it's answering machines/disconnected numbers in our case. Would be interesting to enable debug and analyze why this is happening.

Have you tried adding PDROP as a system status?

Alright, added. Will check tomorrow to see if they have been called.

Can AMD have an effect on this?

AMD intercepts the call pre-agent and terminates the call ... vicidial's PDROP checker sees it was answered but never made it to an agent ... and sets the status to PDROP?

Alternately, of course, if the inherent AMD delay causes silence ... and the client hangs up ... I would expect this to be a PDROP by design. Yes?

Yes, using the built-in AMD could result in a lot of PDROPs.

can dropped calls to a closer ever become PDROPS ?