Poor Quality Transferred Calls

[olivermsubadra]

Hi,

We're having trouble with transferring calls from both internal and external sources. When the call is first picked up by person A, the quality is crystal clear with no latency; however, once it is transferred to person B, the call becomes very choppy and fuzzy. There is also a 5+ second delay from person B's end. i.e.:

Caller (internal or external) calls -> person A who receives high quality call, and transfers it to -> person B who receives choppy call with latency at their end.

We're using unsupported Ozeki softphones, a Southern Comms SIP trunk, and are on v15 of the PBX.

Things I've tired so far:

- Switched codecs around to make sure they match up with the codes being used by the phones (tried lots of different kinds/variations)
- Selected 'PBX delivers audio' in both the trunk and extensions setup
- Made VOIP traffic the network's top priority

 

[leejor]

You might have a look through the 3CX logs, perhaps using the verbose option, for greater detail. I assume that all of the sets are local. Have you tried transfers to sets that are on different physical location on the network i.e. nearer to the server and not having to pass through switches. There might be a hardware issue on your network.

 

[olivermsubadra]

Hi leejor,

I did have a look at the logs, and I THINK this is the right call (I'm finding the v15 log a bit difficult to use):

08/11/2016 10:34:19 AM - NAT/ALG check:L:17.2[Extn] REQUEST 'INVITE' - some of SIP/SDP headers may contain inconsistent information or modified by intermediate hop
Media session IP ('c=' attribute) is not equal to the IP specified in contact header:
Media session IP:0.0.0.0
Contact IP:10.195.194.249
Media session IP ('c=' attribute) is not equal to the SIP packet source(IPort):
Media session IP: 0.0.0.0
Received from: 10.195.194.249

I'm not sure whether or not this would cause jitter. What does it mean when there is no media session IP?

I also took a snapshot of transferred call with Wireshark, which is attached. I'm pretty sure it's a hardware issue as it's exclusively internal (calls transferred to softphones off the network seem to be ok) but I can't see what's going wrong where.

 

[olivermsubadra]

I've noticed something in the call log (attached). When a call is transferred from one extension to another, the transferring call between those extensions doesn't seem to end once the call has been transferred. I had to end this call manually via the PBX.

Call 1: 07xxxx -> Ext 406
Call 2: Ext 406 -> Ext 401 [Keeps on going after transfer/transferer has put their receiver down]
Call 3: 07xxxx -> Ext 401

The problem is with Call 2. It looks as though the 'call' (which is just the process of 406 transferring to 401) hangs on, even after the entire conversation has ended and the two participating parties in Call 3 have hung up. What would this most likely be caused by? The phones? I should mention that most of the staff are using Ozeki-based softphones, but the operator (who transfers the most calls, and transferred the call in the log entry) is using a Panasonic IP phone.

 

[leejor]

Are these an attended, or blind transfer? Or...is there any difference between they types? Is there the same issue if someone other than the attendant transfers a call?

I'm wondering if they are an attended transfer that is turning into a 3-way call for some reason.

Could it be that with the changes in port numbers, some of the SIP messages (disconnect?) are not getting to the proper destinations?

 

[olivermsubadra]

Good question. They're attended transfers. Blind transfers appear to work fine.

If that is indeed the case, how can I keep the messages directed towards the right ports? Is this more likely to be a phone/hardware issue, or is it the PBX or firewall I ought to look at?

 

[leejor]

If I had to guess, which at this point, I do...I would say that there is either something on your network, or, it is a set issue. There are routers that do port substitution but that will generally affect devices outside the local LAN passing through the router, not internal devices.

Has this always been like this, from day one? Were you using a previous version of 3CX where this wasn't an issue?

Have you tried using a device, for the transfer, other than the Ozeki softphone? A Wireshark comparison of an attended transfer, by a different make phone, and one by the Ozeki, might provide some insight into the problem.

 

[olivermsubadra]

Hi leejor,

Thanks for the advice. I'll let you know how it goes.

I don't think this was an issue when were were on v14. Unfortunately we timed everything rather badly and changed a lot of our network setup/switched off our ISDN lines just before we upgraded to v15, and ought to have tested it before we made any changes. I daresay that would have made the issue way more traceable.