Bad call quality after transfer?

[nicdevlin]

Hi,

I am having an issue with call quality on our vicidial setup and I am attempting to pinpoint where the problem is.

In our setup we have 3 points of contact.

A= Agent in call centre on vicidial in Manila
B = Branch staff in Australia
C = Customer in Australia

C rings into our call centre and speaks with A on the phone.

A then transfers the call to B in Australia to close the deal etc.

When C rings A, there is no problem with voice quality all is fine and everyone can hear each other crystal clear.

However, when A transfers the call to B, there is issues with the quality cutting in and out, being muffled and generally bad quality when B is speaking to C.

I have noticed that B sounds clear as day to C, however C sounds terrible to B.

Things we have tried:

C ringing B direct = This is fine, no issues at all clear as day.

C ringing an A extension for vicidial setup here in Australia, then transferred through to B = This is fine, no issues at all clear as day.

B takes down C's number and calls them back directly after the bad quality call = This is fine, no issues at all clear as day.


The issue seems to rear its head when the calls are transferred to B from Manila.

Once these calls are transferred, is A in anyway still linked to this call?

Is there a possible issue with vicidial performance when having calls transferred that may cause this?

Also, sites A, B have no bandwidth issues and this is confirmed by having no problems with other calls.

Looking forward to anyones input on this matter.

[williamconley]

1) Welcome to the Party!

2) As you are obviously new here, I have some suggestions to help us all help you:

When you post, please post your entire configuration including (but not limited to) your installation method (7.X.X?) and vicidial version with build (VERSION: 2.X-XXXx ... BUILD: #####-####).

This IS a requirement for posting along with reading the stickies (at the top of each forum) and the manager's manual (available on EFLO.net, both free and paid versions)

You should also post: Asterisk version, telephony hardware (model number is helpful here), cluster information if you have one, and whether any other software is installed in the box. If your installation method is "manual/from scratch" you must post your operating system with version (and the .iso version from which you installed your original operating system) plus a link to the installation instructions you used. If your installation is "Hosted" list the site name of the host.

If this is a "Cloud" or "Virtual" server, please note the technology involved along with the version of that techology (ie: VMware Server Version 2.0.2). If it is not, merely stating the Motherboard model # and CPU would be helpful.

Similar to This:

Vicibox X.X from .iso | Vicidial X.X.X-XXX Build XXXXXX-XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation | Intel DG35EC | Core2Quad Q6600

3)

Once these calls are transferred, is A in anyway still linked to this call?

While you did put in a pretty good social description of the issue at hand: You should provide a 'Button For Button' description of the call path. The word "Transfer" can hold many meanings just for technicians, and even more for "social description". So let's try to get down to the nitty gritty.

[nicdevlin]

Thanks for your reply William, I certainly missed a few steps!

Here is some info that I should have included in my original post.

- ViciBox Redux v.6.0.3-141118
Linux vicidial 3.11.10-29-default #1 SMP Thu Mar 5 16:24:00 UTC 2015 (338c513) x86_64 x86_64 x86_64 GNU/Linux


Not sure of method used for install, however it would have been off either of these isos, so I daresay from scratch?

Vicibox_v.6.0.x86_64-6.0.3.iso
Vicibox_v.6.0.x86_64-6.0.3.preload.iso

System Specs/Environment

VM running on xenserver 6.2 70446c
4 vCPUs Intel(R) Xeon(R) CPU 5140 @ 2.33GHz Speed: 2333 MHz
15GB Ram
124GB hdd space


Asterisk 1.8.29.0-vici
No Extra Software After Installation
faktortel sip trunks/no pstn

I think thats everything, let me know if I'm missing anything specific.

This is the exact step by step method the girls in the call centre are using to handle transferring of the calls.

VICIDIAL WARM TRANSFER STEP-BY-STEP GUIDE

1. Click on TRANSFER-CONF button on the left pane of the screen.
2. Type the phone number of the person you want to transfer the call to on the NUMBER TO CALL field by adding the number 8 + phone number if it's an external transfer (meaning from the callcentre to an AU number).
3. Check the box for DIAL OVERRIDE/
4. Click PARK CUSTOMER DIAL to put the customer on hold. Please inform the customer that you will place him or her on hold while trying to contact the person they are looking for.
5. When the person you want to transfer the call to answers and agrees to speak with the person on the other line, click on GRAB PARKED CALL on the left pane of the screen, above the TRANSFER - CONF button.
6. The three of you will be on the line but you may be no longer need to talk since the two parties may already be talking. You may now click on LEAVE 3-WAY CALL to exit the call and leave the two parties talking.

If it's an internal transfer, follow step 1 and 2 but type the extension number of the person you want to transfer the call to on the NUMBER TO CALL field.

Hopefully this sheds some light on the process.

It's at this point when they leave the 3-way call that the call quality is bad.

[williamconley]

1) Your problem is likely that the server is virtual. Vicidial should not be used in production in a virtualized environment.
2) (FYI:) You should never use the "preload" .iso, always use the standard.
3) (FYI:) You should not be using the "dial override", but setting the 3-way dial prefix to 8 (if you want to use the carrier assigned to dial prefix 8, of course). This gives vicidial more information for logging and gives the agent more control over the call. Technically it should not make a difference for call quality, but I'd verify that with personal experience once if I were you.

You should put the Vicidial system on a hardware based server, not virtualized. Virtualization for Vicidial should be limited to Development and Training ONLY.

[nicdevlin]

This VM is the only one on the current host and has resources allocated to it not shared, CPU usage also never goes over 30% and this server has been running for 15 months without this problem before.

I would understand if this call quality issue was there from the start, but I don't believe its the source of this problem.

Could you give me further explanation as to why running this as a virtual server is causing issue?

[williamconley]

There are lots of posts regarding why virtual is not a good idea. Lots of attempts to make it work.

IF you are saying that for Your Implementation "Virtual has been working" but now it stopped, perhaps you should try popping out the HD, reinstalling the virtualization software in a new HD, reinstalling the Vicidial server in the new instance, and perhaps it'll go back to how it worked before.

This could be due to buildup of resource usage from services in Asterisk or mysql or anything else running in the Vicidial server or the Virtual Host. Some implementations of Asterisk, for instance, use sqlite which is actually a "memory resident db" which can begin to overutilize resources eventually. There are quite a few packages installed, however, that could make chasing this down prohibitive. There are also quite a few resources available that will allow you to check system usage (cpu/memory) and perhaps begin to find and kill problem areas. But if you begin by a full reinstall on a fresh HD ... at least you may prove that it's not magically impossible any more.

And as long as you stay below the "very low threshold" (often 2 users or 4 calls), you may get away with it.

However: If Vicidial is the only item on this server, you're wasting a lot of resources by not just installing Vicidial directly on the hardware. Just sayin' ...