Misdirected REGISTER

[Ivon Cullumber]

I have a number of IP Phones that I am trying to connect to a 3CX system hosted on Google's Cloud. Softphones are having no problem registering with the service; however, IP phones (some Linksys, some LG-NORTEL) produce the following error in the 3CX log output and will not register.

09/28/2018 12:18:24 PM - Misdirected REGISTER: RegErr Recv Req REGISTER from [My.Public.IP.Address]:1442 tid=-43-106d6-6b931744 [email protected]: REGISTER
sip:192.168.1.109:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.109:5060;branch=z9hG4bK-43-106d6-6b931744;received=[My.Public.IP.Address] Max-Forwards: 70
Contact: <sip:[email protected]:5060>;+sip.instance="<urn:uuid:36303600-AABB-0000-0000-00405A147ADB>"
To: "Receptionist"<sip:[email protected]:5060>
From: "Receptionist"<sip:[email protected]:5060>;tag=94bee4e8-c0a8016d-13c4-43-6c7d587a-43
Call-ID: [email protected]
CSeq: 1
REGISTER Expires: 0
Supported: replaces User-Agent: LG-Nortel LIP 6830 v1.2.38sp SN/00405A147ADB
Content-Length: 0

The one part that I am unsure about is the port that follows my public IP address. Should that not be 5060?
The gateway for this system is a server running Linux.
I had a 3CX phone server running on site with no problems; however, due to internet outages I decided to try a cloud based server. I had no issues whatsoever with the on site server using the hardware that I can't seem to get running with the cloud server.

 

[DSXVOICE]

Hi Ivon, Yes, unless you changed the default port on the PBX, 5060 is correct. Rather than debug the reasons, I suggest you deploy a 3CX SBC instance onsite using a debian instance or a raspberry pi. There is a good chance this will resolve your issue. If you look at the traffic arriving at the PBX and the SIP header does not look correct, there is a chance you have a SIP ALG turned on in your gateway. Make sure to deactivate any feature that claims to "improve VOIP" - it lies. Also, since you moved the PBX, make sure to undo all of the firewall rules you created on the local gateway to support the internal PBX.

 

[eddv123]

It is worth noting that these phone models are both un-supported for use with the cloud system.

It would be best replacing these with supported versions - you can pick some up at a reasonable price and it would save headaches going forward.

 

[Ivon Cullumber]

Thanks for the replies given, I sure appreciate the help.

Through further investigation of this issue, and through testing the phones at other sites, I have determined that the issue is actually with our gateway router. We use iptables running on an instance of Ubuntu to route internet traffic in and out of the building. It would seem that there is something going on with the NAT of the firewall that is causing this issue. Such issues have also been reported with various other off-the-shelf routers.

While I would not call the LG-NORTEL phones that we have here a hopeless cause, these phones work fine through other internet gateways, they will not work on our system here without fixing the issue in the iptables NAT. The Linksys phones, on the other hand, have a bit of NAT capability themselves and more efficiently use the STUN server. The phones were set up using the information from this article: https://sbkb.cisco.com/CiscoSB/GetA..._SPA3102_Phone_Adapters.xml&pid=2&converted=0. This is working well on some Linksys desk phones that we have here as well as the somewhat popular PAP2 analog to ipPhone converter.

I suspect that I may be able to get the whole thing working by following the PAT setup as outlined here: https://www.3cx.com/blog/voip-howto/firewall-nat-pat-stun/, but at this point it's just cheaper to buy phones that can be configured to work. I may, at some point, look into the 3CX SBC. That seems like the next logical step. Thanks everyone!