Solved Gigaset N870IP - SIP registration failed, status = 408

[adn77]

We're testing 3CX with Gigaset N870 IP base stations (small deployment).

About every 7 days the Dect manager fails to register in 3CX:

GIGASET SYSLOG:
[SIP][W][RegistrationController.cpp:791] Account #02b6870xyz(@PBX): SIP registration of account sip:[email protected] failed, status = 408

We left the Gigasets and 3CX untouched for this period of time in order to further debug. There have been no configuration changes or anything during that time.
Is there any chance to see what's the reason for the 408 in 3CX? Once we reboot 3CX, registration succeeds again.

Any help is highly appreciated!
Alex

 

[JohnS_3CX]

Hi Alex,

Please share some additional information:

1. Firmware version
2. 3CX Version
3. Provisioning method (LAN/SBC/STUN)

 

[adn77]

Hi Alex,

Please share some additional information:

1. Firmware version
2. 3CX Version
3. Provisioning method (LAN/SBC/STUN)

Sorry for being unspecific

1. v2.49.1 on the N870
2. 18.0 (Build 418)
3. LAN (2nd interface on the 3CX serving the voice VLAN 192.168.40.0/24)

The provisioning for the Gigaset DECT/FXS has been set to the correct LAN interface. DHCP sends option 66 with the respective provisioning interface (http://192.168.40.33/provisioning/abcdef012345)
Provisioning generally works on the Gigasets (although I'd wish for that link to be remote controlled from the 3CX one day)

Alex

 

[JohnS_3CX]

Hi Alex,

Ok seems you are up to date with firmware and software.

Before moving on, you mentioned having two interfaces on 3CX - let's first confirm this is set up correctly.
https://www.3cx.com/blog/docs/network-configurations-supported-3cx-phone-system/

If I understood correctly, are you using the "Segregated" type network in your case?
And if so, have you noted the detail regarding the default gateway?

 

[adn77]

If I understood correctly, are you using the "Segregated" type network in your case?
And if so, have you noted the detail regarding the default gateway?

Hi John,

thanks for your help and thanks for being thorough.
I haven't yet mentioned - it's a Linux installation. The default route is set across the "public" interface.

Alex

 

[JohnS_3CX]

Hi Alex,

I'm not sure I understood. After reading my above link first, can you please tell me:

1. Are you using the Segregated network type? (Yes / No)

2. If yes, does NIC2 have a gateway defined? (Yes / No)

 

[adn77]

Hi Alex,

I'm not sure I understood. After reading my above link first, can you please tell me:

1. Are you using the Segregated network type? (Yes / No)

2. If yes, does NIC2 have a gateway defined? (Yes / No)

Please excuse my ignorance, I am really having a hard time figuring out what's the setup we have...

1. We're using a segregated Network (with the exception that the VoIP network is as well connected to the Router/Firewall as that is source for DHCP/NTP/DNS. All traffic outside the network is blocked by the firewall)

2.

The Network adapter interface on 3CX Phone System that connects to Network B must NOT have a default gateway specified. This entry should be blank.

That is the case (192.168.40.0/24 being the voice network):

Target          Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.20.1    0.0.0.0         UG    0      0        0 eth0
192.168.20.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.40.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1

Devices connected to the voice network would use the DHCP server as gateway if no gateway would be specified.

Alex

 

[JohnS_3CX]

That doesn't tell us enough, you will have to ensure the gateway is removed from interface too.

I think you are facing networking issues due to the 408 message you see and the fact that you have 2 interfaces.

 

[adn77]

That doesn't tell us enough, you will have to ensure the gateway is removed from interface too.

What do you mean by that? Remove from which interface? The 3CX Phone System has a single gateway as can be seen in the "route" output.

 

[JohnS_3CX]

Ok if you have confirmed the 2nd NIC does not have a gateway, the next step will be to figure out what happens that causes the timeout.

You said the issue is only fixed when 3CX is rebooted correct?
Does rebooting only the base change anything or does the problem only go away once 3CX is restarted?
We have to be sure on this point to decide what to look for next.

 

[adn77]

Rebooting 3CX brings back the Dect stations.

 

[JohnS_3CX]

In this case, you will have to wait until the problem reoccurs, and then start a capture on 3CX (all interfaces).

Reboot the base, and wait 5 minutes before you stop the capture so the base can attempt multiple times to register.

Stop the capture and see in Wireshark if the registrations reach 3CX, and what 3CX replies back and to which IP it replies.

That's the fastest way to find out what happens during that moment.

 

[adn77]

Hi John,

it's happening again.
While checking how to do the capture I learned to look at the "Activity Log" (sorry!!! I was only looking at the Event Log before...).

21.11.2022 13:17:51 - Got REGISTER for foreign registrar: registrar host <sip:@192.168.40.33:0/UDP> is not mine!

That is the IP of 3CX on the Voice network. All other SIP devices in that network seem to register fine.

Alex

 

[JohnS_3CX]

Hi Alex,

You can capture like so: https://www.3cx.com/docs/capture-network-traffic/

Make sure you select All Interfaces during the capture.

Then, restart the N870 and wait 5 mins before you stop the capture.

Afterwards, you can open the capture in wireshark, and see if any traffic appears from the N870 IP

 

[adn77]

Sorry I never replied
I took your recommendation to revisit the network scenario.
For some reason I wanted to let internal users reach the 3cx server (http) on an internal network interface and still have the VoIP separated.

I now use a single (VoIP) network and have everybody access the 3cx via the external FQDN. All SIP registration problems on the Gigaset N870 are history now.

Thanks for your support!
Alex

 

[JohnS_3CX]

Great news Alex! Happy to hear it's resolved