External calls drop out

[svenvil]

Hi,

Having all kinds of issues getting a functioning 3CX PBX running.

Firtly, the install is on a Windows server 2012 R2 VM and 3cx is v12.0.36097.670 SP6
Firewall is a Juniper SSG 140.
I have 10 DID's with Engin (authorised by 3CX).

All i have done so far is create a public IP and map that internally to my VM. The firewall checker is happy with my config and all ports claim to have a successful config. I then ran the install, connected to Engin and created 3 extensions and 1 digital receptionist.
Only other thing i have done is disable the STUN server as i do not have a dynamic IP.

Whats my problem?
1) I have no audio for external calls "sometimes";
- At first i thought it was my firewall config.
- I re-ran the firewall checker which shuts down the bulk of the 3cx services.
- I then restarted ONLY the 3cx Phonesystem service and the 3CX Phone Sytem SIP/RTP Tunneling Proxy and was able to get audio externally. (this rules out the firewall blocking audio)
- When i reboot the server and all services start up again, i get no audio on external calls.
- I can replicate this issue time and time again.

2) I have not had one successful call from an external number to a digital receptionist. NOT ONE. I have created an inbound rule that maps to a digital receptionist, and while it works internally (dialling the DR's extension that is ), i cannot call it externally.

I have tried contacting 3CX support but they seem completely unwilling to provide any pre-sales support other than read the manual (thanks guys). I am currently just in the testing phase, but hoping someone may have seen a similar issue, or at least point me in the direction of some setting that may be required to;
A) get external calls working whilst all 3CX services are running.
B) get external calls to digital receptionists working.

thanks
Steve

 

[jpillow]

Sounds like you possibly have two problems one of which is a firewall issue, because you passed the firewall checker doesnt mean everything is a go. As far as external calls sounds like you need to configure the inbound rules as to whre a call should go to, you can do this in the ports and turnks status.

 

[svenvil]

thanks for the reply. I think i can rule the firewall out. If i stop the 3cx media server service, i get audio externally. not sure what this service does, but its causing issues.

 

[leejor]

You could try re-enabling STUN, even though it should not be needed if you have a static IP.
Are there any error messages in the 3CX server logs?

If possible you could try bypassing the router, connecting the server directly to the modem so that it picks up the public IP. Just as a test, for a very short time. If that worked with no issues then you know that the router is introducing "problems".

 

[lneblett]

Unfortunately, I would not rule out the firewall just yet.

The media server is the internal 3CX engine that drives codecs or audio streams. Turning off the media server is then forcing the RTP streams to be delivered by the endpoints directly without involving the 3CX system. It is also used to accommodate T38 for inbound faxing to the fax server ports and transcoding between different codecs. Your provider is also using media servers at their end to process audio streams. The SIP aspect essentially arranges for the call which includes the various codecs, ports, IPs, etc., that the RTP audio streams will use. A complete explanation of the media server functionality can be found here:
http://www.3cx.com/blog/docs/media-server/

A possible scenario is that with the devices communicating the RTP streams directly, the firewall rule that you have in-place which points to the 3CX system is really no longer in play as the streams are no longer going through the 3CX media server. This is typically why on the trunk connections there is the check box for "PBX delivers audio". As a result, the firewall effectively does not have the right ports open for that particular call and "may" shut down after some time.

On the extensions, the box (PBX delivers audio) is there but more often than not, it is not checked as you are not transiting the firewall facing the internet and the ports being used are in a different range.

The media server is not "causing" the issue, but rather by eliminating its operation, you have by-passed the underlying issue that is causing the media server to appear at fault. You need the media server and there are far too many installations across the world using it to assume that it picked you. Without it, you will not get a IVR; so please turn it back on. You can always dial a IVR directly from an extension to see if the IVR does indeed work.

Here are a couple of things to check:
1. The VoIP provider setup has "PBX provides audio" checked
2. SIP ALG is turned off, NAT is On
3. STUN is turned off within 3CX and the IP is specified as that being your external (PUBLIC) IP.

If that fails, then try Leejor's suggestion of using STUN for testing.

A wireshark capture may be needed to get to the bottom of this.

Let us know.

 

[coertvc]

I can confirm the same behavior,

external IP is fixed, STUN is turned off, and generally the first call of the day results in audio failure , second attempt is always fine untill there is a new day

btw; the firewall is a Draytek 5510 where I have excluded all traffic from and to the provider from scanning etc.

 

[leejor]

Not being familiar with the settings on the Draytek, this is a bit of a guess. It sounds as if the first call of the day "sets up" the routing for any later calls voice packets, then overnight, there is a reset of some sort, and it starts all over again.

 

[lneblett]

On another note -

Is this a new install and the behavior has always been this way? Is this an old install and it only started recently? Any change in providers? SIP ALG is turned off? PBX provides audio on? Who is the provider?

The 5510 is obsolete and its support will be ended whenever the subscription runs-out. I don't know that this changes anything, but if you rely on the threat aspect, then it may give you cause to think about changing devices.

I have not used this particular model, but I have used others and all work very well. Hence; my question about how long has this issue been around.

I assume that in troubleshooting, you could restart the router and emulate the issue almost on demand as the NAT tables should be reset and as far as the router knows, the first call would be the first call. You could then take a wireshark capture of that call and the next and possibly see the issue. If this router model allows for port mirroring of the WAN port, then you could really see if the RTP stream on the first call is coming to you.

Finally, can you elaborate on "audio failure"? Neither side hears the other? The caller can not hear you? You cannot hear the caller?