Solved v18 M400 + M65 SIP Registration Error

Status
Not open for further replies.

EWS

Customer
Joined
Dec 15, 2023
Messages
26
Reaction score
5
Hi everyone,

I am facing a problem with extensions wanting to use snom M65 handsets on M400 base, on a local windows server installation of a v18.9 3CX. The base is provisioned but shows up as red under Trunks in the new UI. The handsets are connected to the M400 base but I am getting SIP Error@RPN00 for both handsets/extensions. So it seems they are unable to register to the 3CX extensions. I have checked the IP Block list, that isn't it.
SIP Log on the M400 shows a bunch of the following log entries:

Received from udp:xxx.xxx.xxx.xxx:5060 at 05/06/2024 09:56:58 (552 bytes)

REGISTER sip:FQDN.my3cx.de:5060 SIP/2.0
Via: SIP/2.0/udp 192.168.20.120;rport;branch=z9hG4bKbq58zgp1
Max-Forwards: 70
From: <sip:[email protected]:5060>;tag=jl8..m2lj0q
To: <sip:[email protected]:5060>
Call-ID: nzrcrmbbylcp.6ob5eupl522mskyp
CSeq: 152086 REGISTER
Contact: <sip:[email protected];line=2>
Allow: INVITE, CANCEL, BYE, ACK, REGISTER, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE, INFO, PRACK, UPDATE
Allow-Events: talk,hold
Expires: 1200
User-Agent: snomM400/07.30.0104 (MAC=000413D12956; SER= 00000; HW=3)
Content-Length: 0
I have no real idea what else to check. Firewall has an ANY rule active at the moment and windows firewall of the server is turned off too.
Any help is appreciated.
 
Tried both 100 and 104 branch for the handsets, same issue. So I doubt it is the firmware that's causing this.
 
Hi there.
In the DECT interface, you also have the logs, and what error do you see there?
 
It keeps trying to re-register the extensions, but fails.
loc0 .Info 2024-06-05T10:50:21.580Z 62 [ UATASK : Re-registering user 306 (ExtIdx#0000) on AppId#02 ]
loc0 .Info 2024-06-05T10:50:23.360Z 80 [ SYNCMGR : [SyncMgrStateData] GettingChained: 0, Unchained: 1 ]
loc0 .Info 2024-06-05T10:50:23.480Z 62 [ UATASK : Re-registering user 307 (ExtIdx#0001) on AppId#03 ]
loc0 .Info 2024-06-05T10:50:26.580Z 62 [ UATASK : SIPW_REGISTER_IND of AppId#02 UA#02 UaState:Registering Result#2 ]
loc0 .Info 2024-06-05T10:50:26.580Z 62 [ SYSTEM STATUS : Registration of user 306 (ExtIdx#0000) on domain fqdn.my3cx.de:5060 failed ]
loc0 .Info 2024-06-05T10:50:28.480Z 62 [ UATASK : SIPW_REGISTER_IND of AppId#03 UA#03 UaState:Registering Result#2 ]
loc0 .Info 2024-06-05T10:50:28.480Z 62 [ SYSTEM STATUS : Registration of user 307 (ExtIdx#0001) on domain fqdn.my3cx.de:5060 failed ]
 
On the 3CX:
Provisioning file /provisioning/rxwg8c0rfn/cfg000413D12956/cfg000413D12956-firmware requested by <public IP> could not be generated
For both phones. The base provisions just fine:
Provisioning file for MAC 000413D12956 of user Snom DECT M400 requested by <public IP> was successfully generated
 
Provisioning file for MAC 000413D12956 of user Snom DECT M400 requested by <public IP> was successfully generated
>> this message here shows, that provisioning is generated for your DECT, so its normal.

When it comes to the logs of the DECT, is it a most advanced logging level there? If its trying to re-register, does it reach the 3CX System or not?
 
The DECT logs are from the Syslog tab, there is Diagnostics with a logging tab but I am unfamiliar with that.
It's not reaching the 3CX System I think, I am only seeing the provisioning fail once when the base reboots and the dect phones try to reach the 3CX System. I do not know how to check for the phones connectivity to the 3CX System.
 
I generated a full debug log:
 

Attachments

So in your case, do you have a local DNS server that will resolve your FQDN to the correct IP of your 3CX System?
 
Yes, it points towards the public IP and we have a DNAT rule in place translating traffic. We can access the 3CX System both internally and externally. Should we point the local DNS to the internal IP of our 3CX?
 
You can give that a try, as normally since your device is in local network, it work be registered with local address and not the full public IP.
 
That fixed the issue. Even though the firewall we have in place (Sophos XGS 107) didn't show anything as blocked, the requests being routed through the internet back to the 3CX System seem to have gotten "lost". Handsets work fine now.
 
  • Like
Reactions: OlegR_3CX
Yes, it points towards the public IP and we have a DNAT rule in place translating traffic. We can access the 3CX System both internally and externally. Should we point the local DNS to the internal IP of our 3CX?
It should ideally point towards the local IP of the PBX if the device is on the same LAN.

We block registration attempts via WAN for security purposes, and local extensions should not be going over WAN.

Just something to keep in mind security-wise.

If you are translating the traffic, you might still have an issue in your call flows in case the SIP messages contain public IPs.
 
  • Like
Reactions: EWS and OlegR_3CX
@EWS Perfect and thank you for the feedback provided here.
 
  • Like
Reactions: EWS
Status
Not open for further replies.

Latest Posts

Forum statistics

Threads
111,951
Messages
589,886
Members
164,843
Latest member
sambannoura