Audio issues & General advice

[Dhaval]

Hi

We have implemented 3CX for a customer who is all of a sudden having audio issues.

The caller can't hear the speaker but work the other way round.

If a call comes in and works fine, when transferred we have same issues.

On a T49 which is non supported but works fine as SIP extension, all of a sudden (along with other issues), the call ring will drop after 2 rings. Also issues with transfer.

Setup: 3CX server running on Windows server 2012 R2 which is a virtual server hosted with OVH. The phones are T48Gs and T27Ps. We also have 2xT49G, 3 x Algo paging adapters and 1 x 2N Helios IP force door entry system.

Things were all working fine till last Friday but since we are having all kinds of audio issues.

We installed 3CX SBC controller on the data server in the office where the phones are.

The supported phones are configured using the Direct-Remote STUN method of provisioning and unsupported devices configured using SBC. Remember all phones and devices are on the same LAN in the office and 3CX server is remote.

Issue is not related to firewall because firewall test passes fine and also the issues we are having are since last Friday, before that the setup worked fine for 2 weeks.

3CX support is totally out of clue what to do and how to fix it.

I am asking help of members here if they can give me a solution/suggestion.

Here is what I am thinking might be possible solutions.

1. Configure all phones through SBC controller, even the supported ones.
2. Move the 3CX server from remote server to a computer that is on the same LAN as the phones are. Then reconfigure all phones to connect on the LAN and the only traffic that goes on the internet is the SIP trunk.

We have to come up with a solution quickly so any help/comment/suggestion would be great.

 

[sip.bg]

Why don't try registering T49G to 3CX using TCP protocol, instead of default UDP.
It fixed for me other issues mostly related to video calls and also with inbound audio calls.

 

[Dhaval]

Why don't try registering T49G to 3CX using TCP protocol, instead of default UDP.
It fixed for me other issues mostly related to video calls and also with inbound audio calls.

Thanks for the comment but when I registered using TCP, it wouldn't work with the door entry system. The video and audio worked fine but DTMF didn't. Since we need to send DTMF tones to the door entry system, it wouldn't allow us to open the door using the phone.

The comment about the T49 was to help identify the bigger problem.

We need a drastic change in the setup as we can't pin point the cause of audio issues. It isn't just about the T49G anymore.

Dhaval

 

[sip.bg]

You can try eventually changing the method DTMF is transmitted (RFC2833, inbound, etc.).

 

[Dhaval]

Yes, I will definitely need to look at that. which option do u recommend? or should I just try all of them one after the other?

 

[sip.bg]

Generally RFC2833 is the recommended method, but not working always with all systems.

 

[Dhaval]

Ok, I will try all of those one after the other to see which works best.

As for the options I outlined, which one would you prefer to try?

What are your thoughts of bringing the 3CX inhouse instead of hosting it on cloud?

 

[sip.bg]

Regarding cloud, there should not be generally any problems with PBX implementation,
We are operating our own cloud into data-center (under VMware, 2 hosts + common storage) and have over 50 3CX instances running -- different versions -- 12.5, 14, 15.5 (Win and Debian).

Each customer site is connected via IPsec VPN or in some cases via VLAN (or other layer 2 connectivity), so this could eventually make some difference to setup via public internet. Also using 3CX tunnels (softphones and eventually SBC) is improving reliability of a system. IPsec VPN adds greater security, as traffic between PBX and customer's site is encrypted.

Properly implemented cloud solution should be more reliable from hardware failure point of view. Also you have more protection into a data-center against power failures, internet cut-downs, etc.

 

[Dhaval]

So the VPN essentially makes your phone connect over a private network instead of public Internet. Was security the only reason you selected to do it over IPSEC VPN or was traffic flow also in the consideration?

The customer already has desk phones that they are used to so can't ask them to use softphones.

For us it is all over Public Internet.

Do you have any implementation where the server is in the cloud but multiple remote phones in the same office?

It's a small business so we can't afford to spend too much but it may also mean that our implementation is wrong.

 

[sip.bg]

So the VPN essentially makes your phone connect over a private network instead of public Internet. Was security the only reason you selected to do it over IPSEC VPN or was traffic flow also in the consideration?

The customer already has desk phones that they are used to so can't ask them to use softphones.

For us it is all over Public Internet.

Do you have any implementation where the server is in the cloud but multiple remote phones in the same office?

It's a small business so we can't afford to spend too much but it may also mean that our implementation is wrong.

VPN gives maximum security (highest degree of encrypted traffic), also has some advantages compared to SBC, where traffic is not encrypted, only encapsulated and not all devices will work with SBC (or not many devices) -- we have for example implementations with over 500 IP phones in one site using VPN to cloud.

If you can't control customer's site router or router is not supporting VPN, it will be easy to use SBC (or use second router, capable of doing VPN in the local network of the customer). Controlling router at site could allow also to implement QoS policies (voice prioritization).

Using public internet could be the easiest solution, but may suffer from different issues, mostly NAT related ones, like one-way voice. It could be also cost effective for small implementations.

I would prefer cloud implementation connectivity to customer premises in the following priority: (1) IPsec VPN, (2) 3CX tunnel and SBC, (3) direct internet (with STUN). Some IP phones may support secure SIP and RTP.

For small single-site implementations it could be also cheaper to have on-premise solution (for example using Intel NUC mini PC) than cloud.

We are also widely using highly cost-effective and performing MikroTik routers for all our implementations (cloud and on-premise)

 

[YiannisH_3CX]

Hello @Dhaval

Issue is not related to firewall because firewall test passes fine and also the issues we are having are since last Friday, before that the setup worked fine for 2 weeks.

The firewall tester may pass on the server but there are 2 firewalls involved in your setup as there is also the firewall at the remote site.
Have you set the phones using STUN with unique SIP and RTP ports or are all phones using the same ports? If you haven't done already you need to assign different ports to each phone through the management console and re-provision the phones.
You also need to port forward these ports to the local IP of the phones.
https://www.3cx.com/3cxacademy/videos/intermediate/configuring-remote-extensions/

3CX support is totally out of clue what to do and how to fix it.

Do you have a ticket number so i can tale a look?