Asterisk

One Way Sound

Given: 3CX works (possibly due to built-in Stun service) whereas X-Lite and Bria do not transmit sound from the Customer to the Agent.

Serious indicator that the problem is firewall related to the location that sound disappears based on direction of travel. In this case, the sound disappears between the Vicidial server and the Agent Phone (possibly because Stun is not used). While stun service is only supposed to be necessary if the Server and Phone are both behind firewalls, there are exceptional circumstances where a subtle change occurs as a result of Stun that can appear to fix a problem, but in a way just worked around it by accident (of course, since the result is that it worked ... it DID fix the problem!).

In SIP the channel is built on UDP port 5060 with a handshake between the asterisk server and the phone (this is the control circuit, as it were). Then sound is generated on a completely different port (usually from UDP 10000-25000) and that port is opened by the phone through the firewall and then the server sends audio traffic to that same port which results in the sound getting to the phone by virtue of the Router/Firewall knowing that (since the phone opened the port), that port belongs to that phone's IP address, so any traffic sent to that port is routed to that IP address.

There can be several challenges to this, each must be hunted down and eliminated.

1. Easy fix: sip.conf has a setting for "externip". This must be set to the public IP address of the asterisk server if the asterisk server is on a private network (ie: "192.168.x.x" or "10.x.x.x").
2. Double NAT: If your local router is actually inside another router with another private network, this can wreak havoc with VOIP calls in general and cause all sorts of headaches. If you have access to your router, check its external(public) IP address by logging in to the router directly. If the public IP is "192.168.x.x" or "10.x.x.x", this is your problem. If, however, the external IP of the router is actually THE public IP, then you're good here. This often happens when sub-leasing an office with a network connection or when a "building" requires you purchase internet from them or from their "internet reseller" whoever that may be instead of getting internet directly from an ISP.
3. Reserved ports or a port range: If you have ANY network routing set up, it may be worthwhile to get a generic spare router and hook it up (don't throw the present one away, this is just a test ...). It is preferable to have the new router (or old extra/spare that was laying around?) factory reset before the test to clean out any customizations that may interfere with the test. It is even more preferable to just grab one from Best Buy/Walmart/CompUSA that states it has a "sip algorithm".
4. In some newer servers there is also an option for "port triggering" or a similar name. This is when a request on on port (5060) may result in a reply from the same IP on a different port range (10000-25000).
5. It is also possible in many cases to check the router configuration and turn ON or OFF the SIP Algorithm if there is one. Note that in some cases this extra feature helps with SIP Phones, and in some cases it breaks functionality. So changing the setting in either direction may result in success. It may also not be called a SIP algorithm as every manufacturer calls it something different to avoid the appearance of stealing someone else's possibly registered intellectual property. So look for anything that may be a vague reference to telephony, VOIP, SIP, etc. and change the setting if you can (do make note of it and put it back if the result isn't a winner).
6. Stun service: If all else fails, most phones do have a stun setting option. It would be a worthy exercise to borrow the stun setting from the 3CX phone and put it in Bria or XLite. I'm not sure I'd "run" with that, but the experiment could be useful. At the very least, it would confirm stun solving the issue aside from everything else.
7. Asterisk server firewall combined with enterprise SIP service: Often the carrier is sending audio from the wrong IP address (from the viewpoint of the firewall on the asterisk server). If the IP from which they send audio changes and is NOT the same IP address as port 5060 is communicating ... the firewall may have no idea it should be allowing these packets. This can occur if the Carrier has "audio-only" servers separate from the control servers. Happens often with OpenSIPs servers, as they are normally expected NOT to pass sound, just control. In this situation, you'll need the entire range of IPs from which the carrier will possibly send traffic to allow all of them into the future.