Outbound call to an ext. 3cx phone does not ring the phone

[viktora]

Hi,

I do have the 3cx phone system installed here (it is the free version that is going to be updated to paid SBS version soon). I got all extensions working within the network and over our VPN server, two PSTN lines (both controlled by the Linksys SPA 3102 gatweay), everything works great. Now I set my test Linksys SPA901 IP phone to register from my home network through my firewall onto the 3cx phone system within our company network. It registers flawlessly, but when I try to make a call from my 3cx VoIP client (nr. 106, connected over VPN) to that IP phone (nr. 107, no VPN), it is not successful. My client says it is ringing, but the IP phone remains silent. After a minute or so the client switches to "busy" tone and this is what I get on the 3cx server:

01:29:47.821 Call::Terminate [CM503008]: Call(9): Call is terminated
01:29:47.790 Call::RouteFailed [CM503014]: Call(9): Attempt to reach [sip:[email protected]:5060] failed. Reason: No Answer
01:29:47.758 CallLeg:nFailure [CM503003]: Call(9): Call to sip:[email protected] has failed; Cause: 408 Request Timeout; internal
01:29:47.431 CallLeg:nFailure [CM503003]: Call(9): Call to sip:[email protected]:5060 has failed; Cause: 408 Request Timeout; internal
01:29:14.961 CallCtrl:nSelectRouteReq [CM503004]: Call(9): Calling: Shared:107@[Dev:sip:[email protected]:5060, Dev:sip:[email protected]:5060]
01:29:14.930 CallCtrl:nIncomingCall [CM503001]: Call(9): Incoming call from Ext.106 to [sip:[email protected]:5060]

Watching the line status monitor I found that during this time the status "LED" of my client changed to amber (calling), while status of the IP phone remained green (idle). On the contrary, trying to make a call back to my client, the IP phone worked perfectly, including audio. The IP phone as well as my client status "LED" changed both to amber and connection was established.

So the result is that I cannot make calls to the IP phone as it is, but I can call from the IP phone the rest of the internal 3cx numbers. When I set the phone into our company network, reconfigured it and did try to call it, it ringed.

I have set all necessary ports on the company firewall (5090, 5060, 9000 - 9015, 3478). The firewall test on the 3cx server did go well. I also opened and transferred the port 5060 on my home firewall to the IP phone. I was guessing for a while that my ISP might block the SIP ports, but in that case I would have not at all made a call from the IP phone. This must be some matter with either the company firewall, or the home firewall - perhaps some routing mishap? I have no idea as to how to debug this strange behaviour.

Company firewall is Linksys RV042, my home firewall is Linksys RVS4000, IP phone is Linksys SPA901, there is the latest version of the 3cx server installed on the server. All devices were upgraded with latest firmware. I will be grateful for any hint or advice that would help me to solve this issue.

 

[William400]

Hi

Thanks for your post.

From the information provided it would appear to be some kind of routing issue. If you were to close and reopen the IP phone on your home netwrork and attempt a call to it immediately , while port mapping is still fresh in the routers, does the issue still persist?

To solve this issue permanently you would need to ensure static routing between PABX and remote clients, alternatively you should use the Tunnel feature. We shall be uploading the 3CX Soft Phone with tunnel feature enabled together with FAQ shortly.

 

[landfiets]

i found out that those things are the same problem as the other people having problems with their external extensions.
Maybe we cam make one Posting from this all because it is now a widespread problem
I guess that when you try to call from that external extension to someone in the local system he will find its way somehow but from local to external isn't working?

I have the same problem, and with all respect but all the help from others didn't help. I think something is really faulty with external extensions.

 

[landfiets]

one thing to try and I will tell that also in other postings, that when you use a hardwarephone for external try setting it on static IP after he got an IP from DHCP. Some phones work better.

 

[Pentangle]

Viktora,

From the symptoms you mention, it sounds like either the 3CX server doesn't know the external IP address of your handset, and/or the firewall at your house isn't forwarding 5060 properly to your handset.

I would hazard a guess that your first port of call should be to setup the STUN settings within your handset.
The second thing would be to check the port trace on your outbound firewall from the office, as you may find it's not looking for 5060?

See how you go.

Cheers,
Mike.

 

[Pentangle]

one thing to try and I will tell that also in other postings, that when you use a hardwarephone for external try setting it on static IP after he got an IP from DHCP. Some phones work better.

DHCP or static makes NO difference to the state of the phone. There's nothing "funky" in DHCP that would produce different results than the same set of IP settings given statically. The only thing you would need to ensure is that the firewall rules point to the given IP.

 

[landfiets]

i know what you say, but Siemens itself says that it could be this problem with phones.
I agree its a port thing too, but sooooooooo many people here on the forum have their ports right and still the same problems.
Its not only ports. It must be something else too.

 

[viktora]

Hi there, folks,

thanks for your replies. Now let me tell you more about my struggling here:

"...From the information provided it would appear to be some kind of routing issue. If you were to close and reopen the IP phone on your home netwrork and attempt a call to it immediately , while port mapping is still fresh in the routers, does the issue still persist?"

That was not of any help at all. It behaves all the same. From hardphone to SW phone (and other internal VoIP numbers) it works, in the opposite direction does it not work at all. I am afraid the tunnel feature would not help to solve this issue for this is the hardphone that seems not to be available, and I cannot install the tunnel into the phone. Well, if any of the hardphones supported VPN, I would use it at instant, but I have not heard about any such a device. In that case I would just connect the phone to the nearest switch in my home network, the device would establish its own VPN tunnel automatically and voila - here we go .

I also tried to set a static internal IP address onto the hardphone, but to no avail. Anyway, the phone always gets the same IP address for my home DHCP is set to provide with fixed mapping to the phone. It still registers with the 3cx pbx, it rings and talks with other internal numbers, but still remains invisible for calling back from these other numbers.

What I think could help is Mike's idea of registering with the STUN server. I must admit that this STUN theme is not entirely clear to me - do I have to build my own STUN server? Or is there any public STUN server that would work for me? And so on, but that I must study first on my own. Anyway, I have already downloaded a GNU STUN server for testing purposes and as soon as I find some time, I would like to do some testing.

I personally think that the issue does exist because of my ISP NAT. I do not have public external IP address on my Internet line, I am just behind a NAT gateway. From my side toward Internet the NAT behaves transparently, but in the opposite direction there might be some restrictions and this is probably the reason why the hardphone can dial out, but does not receive calls. I have sent an e-mail to my ISP and now I am waiting for answer. Fortunately I am not in hurry with this case because the 3cx system works flawlessly within our network and for our VPN clients, which was the primary goal of the effort of mine.

I will keep you all informed as to how the case further evolves, I think it would be interesting for others with the same or similar problem...

Wish me good luck .

Dave

 

[Pentangle]

Hi Dave,

Good luck! (and I wish someone would fix the smilies on this site!)

STUN is basically a "what external IP address am I using", similar to http://whatismyipaddress.com

You shouldn't need to build your own STUN server, the publicly available ones should suffice, as it's just a service as shown above.

This should allow your 3CX server to know where the remote site is (from an internet rather than intranet IP perspective), and hence route the packet properly (we hope)....it'd then be the ports at your firewall we'd look at once a wireshark trace showed a successful outbound packet from your 3cx server.

As regards the "tunnel" in v5.1, I don't think it's a VPN tunnel as such, more a "proxy".

Hope that helps.

Cheers,
Mike.

 

[viktora]

Hi again, folks,

here I am with the latest news regarding the case of mine. I found a reason of strange behavior of the phone: the WAN IP address of the firewall installed in my home network. The IP address assigned to the WAN port comes from the 10.x.x.x range, which of course is a private range. I am behind a ISPs central NAT router, but that is not of any help since my WAN address is not accessible from the Internet. Unfortunately my home firewall does not even contain a VPN GW-GW feature (as I have found, even a router with GW-GW VPN can not establish a VPN tunnel with the company VPN router due to IP authentification method the company router uses, a public IP address must be used for authentification). It could work if I could get any public IP address assigned to my WAN port (even a dynamic one, it can be treated with the dyndns service), but that is fat chance here. Well, I must ask for public IP address, make a GW-GW VPN and I believe the phone will work again...

I put hope into the 3cx tunnel feature, but it is unclear to me whether I can use it with the 3cx phone client only or as a tunnelling proxy for all VoIP data from my network to the server (so that I could configure the hardphone to use it as a virtual SIP server). Could anyone tell me more about it, please?

Dave

 

[Pentangle]

Hi again, folks,

here I am with the latest news regarding the case of mine. I found a reason of strange behavior of the phone: the WAN IP address of the firewall installed in my home network. The IP address assigned to the WAN port comes from the 10.x.x.x range, which of course is a private range. I am behind a ISPs central NAT router, but that is not of any help since my WAN address is not accessible from the Internet. Unfortunately my home firewall does not even contain a VPN GW-GW feature (as I have found, even a router with GW-GW VPN can not establish a VPN tunnel with the company VPN router due to IP authentification method the company router uses, a public IP address must be used for authentification). It could work if I could get any public IP address assigned to my WAN port (even a dynamic one, it can be treated with the dyndns service), but that is fat chance here. Well, I must ask for public IP address, make a GW-GW VPN and I believe the phone will work again...

I put hope into the 3cx tunnel feature, but it is unclear to me whether I can use it with the 3cx phone client only or as a tunnelling proxy for all VoIP data from my network to the server (so that I could configure the hardphone to use it as a virtual SIP server). Could anyone tell me more about it, please?

Dave

Dave,

I would threaten your ISP with the trades descriptions act (or whatever similar laws you might have in whatever country you reside), as you are not being given "the internet" as you've paid for. i.e. you expect that when you purchase access to "the internet" they should give you at least one internet-routable IP address. Without it you can't run VoIP, you can't run VPNs, you can't have inbound traffic, basically. Get legal on their asses!!

Oh, and the tunnel isn't going to help you here, but yes I believe it's the latter of your two explanations above.

Cheers,
Mike.

 

[viktora]

Hi Mike,

very fat chance to make my ISP doing what I would like it to do , mainly because this ISP is the only company in my place providing with services for reasonable price (and they know that). Anyway, I have just asked for public IP address (they have already accepted the request and now I am waiting for their admin to configure my speedbox) and then it should be all functional. I forgot to test the system with the old T-Mobile 4G modem of mine which gets public IP address (although dynamically, but never mind, dyndns service is the solution!) and if I am not very much mistaken, I should be able to make calls and receive calls from the hardphone through this modem.

Now - because of the private WAN IP assigned to my firewall - the hardphone can make outbound call to our network and through our gateways back to pstn or voip numbers, because there are SPI firewalls between the hardphone in my network and Internet, that keep the route opened as long as the phone uses them. But as soon as the hardphone closes the VoIP session, all routes are also closed. When someone in our network tries to call the hardphone, the session cannot be established due to absence of any routable public IP address on my home network s side.

Anyway, I will keep you and the rest of interested persons here informed about the final result. For now the conclusion is that you must have a public WAN IP address of any type to get the VoIP service working (which is logical, too).

Dave

 

[viktora]

Another update: I dug out my old T-Mobile 4G modem and set it as Internet gateway. Now I have public IP address on the WAN port of my router, I have set everything and stuff, but the phone behaves just the same as before. So my glorious theory was so ingloriously ruined. But after I made a GW-GW VPN tunnel (with help of the dyndns service) and reconfigured the hardphone to register with internal 3cx server IP address, it works perfect. Now I can make both outbound and inbound calls on the hardphone, it is possible to call the rest of hardphones or 3cx clients in the company network (including VPN clients), call PSTN numbers etc. The only condition is that the external network which the hardphone(s) exists in must be connected to the main 3cx server via the gateway-gateway VPN line. Well, that is not so much of a problem since all our branch offices are connected to our central through hardware-controlled GW-GW VPN lines, hence I am pretty sure the hardphones will work there as well. Well, from what I have written above I guess there must be some issue with routing and I take a look at it as soon as I have more time again.

I am sure it must be functional without the VPN tunnel, but that has not worked for me here yet; after all I am going to find a way of possible solution. I would say I forgot to click some little button or enable a protocol somewhere in the depths of my router - just this little matter usually is behind all gorgeous malfunctions (even Mr. Murphy discovered that ). In some way or other, I will keep this thread actualised along with my progress.

Dave

 

[landfiets]

What kind of a modem do you have ( I don't mean your router RVS4000 )
I had similar problems and found something out about blocking 5060.
I am so happy that I found it out yesterday after weeks and months of being hopeless.
I am just curious what modem you have.

 

[viktora]

Nothing special, it is just a USB/LAN 4G modem that Czech T-Mobile uses to connect to the 4G network. See here (unfortunately it is in Czech only): http://t-mobile.cz/Web/Residential/Telefony/Telefon.aspx/Telefon/305. This modem can even cooperate with any router supporting pppoe authentication. I personally use it as a secondary connection in case the primary line is down.

I would not be at all surprised if TM blocked everything that could have anything in common with SIP application. No provider would be that grand to allow its customers to call for free of charge within the data fixed payment tariff...