3CX, Cisco, Remote Extension, Partially Working?

[DexDeadly]

Hello All,

I come with hopes and prayers you may be able to assist me with this. I currently have a 3CX setup with 1 local and 1 remote extension. Both phones are running 8-5-4S versions of the SIP firmware. After a lot of troubleshooting and testing I was finally able to get the remote extension to register. However the reliability of the connection and what works is very inconsistant. For example when making a call out the remote extension worked with no issues. When we test called a line coming in, local phone worked however the line did not ring on the other end. Looking in the log I do get this.

14/04/2017 03:03:57:706 | Call to T:Extn:101@[Dev:sip:[email protected]:5061;transport=udp] from L:67.1[Extn:100] failed, cause: Cause: 404 Not Found/INVITE from xxx.xxx.xxx.xxx:49389

On the remote end we have forwarded ports 5060, 5061, 9000-9500 as well. When trying to dial the extension of the remote phone I get a fast busy signal and Reorder on the bottom of the screen. It just doesn't connect. Now we did have a few times where the remote extension did in fact dial to the local extension. However when hanging up and trying again it wouldn't connect again.

Using the 3CX log viewer I do not see the actual connected call. Which is odd as I would think it'd be in here. I do see the call in the call log in the dashboard though. We were able to make 3 calls and it now no longer works. So I'm unsure what allowed them to at first but will not do it now. This right here I believe might be the call coming in, however the INVITE I'm not sure is right.

14/04/2017 03:04:49:423 | [CM503003]: Call(C:72): Call to <sip:[email protected]:5060> has failed; Cause: 487 Request Terminated/INVITE from 127.0.0.1:5488

I have tried disabling and enabling the options for:
PBX Delivers Audio is On
Allow Remote Extensions Outside of LAN
Settings for Direct SIP calls - Currently Unchecked.
Send Media to IP and port of REGISTER - checked
Enable Keep Alives 30 - Checked

Firewall check on my end does show all green. On the remote end if I use a port checker I do get port not open for 5060, 5061 and 9000-9500(any random port I choose). Anyone able to offer some insight as to if this is on the 3CX end or is it on the Remote end? We've DMZd the phone IP as well thinking something might of been blocking it on that end but that didn't seem to make a difference. I am running a pfsense firewall in front of the 3CX server if that helps, the remote location just uses there dsl router from the company. I forget the company off hand.

Thanks in advanced!

 

[leejor]

Generally, at the remote end, you should not require any port forwarding if you are only using one extension. Power up the remote extension, then check the 3CX Activity log. What does the registration attempt look like? Does it show the public IP and correct port? Does 3CX show the set to be registered? Does the router at the remote end have any in-built VoIP hardware that could be using (blocking) ports 5060 and 5061?

 

[Nick Galea]

The best way forward for you is to use a supported phone as a remote extension. Then all is configured correctly automatically. Also you have not mentioned which CISCO phones you are using. If its the SPA range you have a fighting chance. The older 7940 range are not suitable for what you want to do.

 

[DexDeadly]

@leejor thanks, I suspected I didn't kneed to port forward but I wanted to make sure. When it got the invite everything looked OK. I'll have the remote extension booted again shortly and take a look to see what it says. I did forget to mention that when looking in extension I do see the line as green. Under the phones tab I do see the phone showing as listed and with the 3 extensions that its configured for. I'm unaware of anything that might be blocking VoIP. If I didn't get it to actually work randomly I wouldn't think thats an issue but then again, I'm open to anything. Possibly we need to call that internet provider to make sure they don't have anything that can interfere.

@Nick Galea I would love to get a new set of Cisco phones to run this. I really do, I just hate to see good phones go to waste. I picked these phones up for next to nothing and as a starting business I wanted to try and keep cost as low as I could. The phone works great locally. It just seems to be this remote extension. Would the SBC possibly be a better solution? Install the SBC onto a pc in that location and have that connect to the server and then the phone to that. I know thats if you have multiple phones at the location. However I thought I'd ask.

Another thing I wanted to toss out there is that if the line is set to do not disturb, which I had run into, I can call the line and leave a voicemail. The line then on the other end shows that they have a voicemail and they can then retrieve it. It was after that the phone decided to work those few random times. Another question would be, would having the windows client running at the same time as the phone have an issue? I would think the 3CX client runs over the Tunnel so it should not interfere but I'm just tossing that out there.

Now one thing I did do last night after posting here was I did find an article with the pfsense firewall for 3cx about mapping the external ports and being static. My original rule did have the static port box checked, however I did see the article mentioning that they still had an issue and so I added a new rule. I'll be giving this a try today to see if that works. These are really nice phones and I wish there was a way to make them work reliably.

If I had the money I'd be getting the Yealink SIP-T46S , maybe if we get successful.

 

[DexDeadly]

@Nick Galea Completely apologize as well. These are the Cisco 7970 Series phones. I know they are not officially supported and all but it just seems like it is something really small that is just not happening.

 

[Nick Galea]

No problem You can get these phones working on the LAN, but not as remote phones. Your best off getting a supported phone to do that.

 

[leejor]

Looking at the registration log will be telling. It may be a STUN issue. Some Cisco sets don't support STUN as they are designed to used "internally".

 

[leejor]

Another question would be, would having the windows client running at the same time as the phone have an issue? I would think the 3CX client runs over the Tunnel so it should not interfere but I'm just tossing that out there.

If it is set to use the tunnel, then it should not interfere with the Cisco set. If it is not, then it MUST be set to use a different local port, if one is using 5061, then the other can use 5060, etc. Even then, some routers can have issues keeping the audio ports "straight", resulting in no audio one way.

 

[DexDeadly]

Hey @leejor do you know where I can see this log. I only know of the one log but I don't see the registration happening. Now one thing we have noticed is right now my remote extension can call my local extension. it even connects to my extension using the android app, however if I try to call the remote extension I get Call Failed. Remote extension also can call out, no issues, it just can't recieve the incoming calls. I'm still getting the following in the log

19/04/2017 20:40:50:124 | Call to T:Extn:101@[Dev:sip:[email protected]:5061;transport=udp] from L:9.1[Extn:100] failed, cause: Cause: 404 Not Found/INVITE from xxx.xxx.xxx.xxx:49251

 

[leejor]

You have hidden the IP's, so I don't know if they are a pubic IP or private. The sets you are using may not support STUN, which may be the cause of your problems. The Activity log is the one that should give you the information. You can set different "levels" (detail), which might be more useful. You might want to consider using an SBC (Raspberry Pi) at that location.

 

[DexDeadly]

@leejor the IP is the public IP of the remote location. The sets I have I don't believe support STUN. I believe I had the log set to the lowest to record all. I have actually just setup SBC at that location and will work to configure the phone to use the SBC. Just looking to see what I need to place within the XML file. Hopefully this may work today.