SIP trunk not registering or attempting too

[WebMediafields]

The SIP trunk is not showing register sent or failed register. Looking at the system logs it seems to get stuck at resolving the host name. I have tried multiple setting different DNS servers on the host machine as well as updating the router but it's still doing the same thing.

 

[Saqqara]

For a test, instead of using hostname , try IP address.

At the operating system level, can run ping / nslook commands to a fqdn and get an ip address back. If this does not work, then you have a network issue and not a 3CX issue.

If this does not work please provider info on your setup - https://www.3cx.com/community/threads/information-to-provide-when-requesting-help.67558/

 

[WebMediafields]

I've tried connecting directly with the IP and it does attempt to connect but then fails. I don't think my sip provider allows connecting this way.

My setup is:

• 3CX Version: Professional Annual 16.0.641
• Server OS: Windows 10 Pro
• Trunk Provider: Orbtalk
• Has the Firewall Checker passed: YES
• Are custom Phone Templates being used: NO

 

[Saqqara]

Have you done ping / nslookup commands at operating system level, and does it resolve.

for example - windows nslookup

 

[Saqqara]

Have a look at this post - https://www.3cx.com/community/threads/sip-trunk-not-registering-or-attempting-registration.75763/

try disabling IPv6 - https://www.3cx.com/community/threa...empting-registration.75763/page-2#post-344657

 

[WebMediafields]

I've done nslookup on the host machine and it's resolving the dns correctly. I've tried disabling IPv6 but am still having the same problem.

 

[YiannisH_3CX]

Hello @WebMediafields

Are you on Debian or Windows? Also are you using the default 3CX template for Orbtalk or did you manually add them?

 

[WebMediafields]

Hello @WebMediafields

Are you on Debian or Windows? Also are you using the default 3CX template for Orbtalk or did you manually add them?

It's on Windows 10 Pro and this is using the template for Orbtalk

 

[AWS2P]

Posted above , windows 10

 

[AWS2P]

Are you using 8.8.8.8 as first DNS on your pbx nic?
Force IPv4 in trunk options
Change Sip domain to IP
refresh register, should be ok

 

[AWS2P]

Hi ,@YiannisH_3CX
As we are several from everywhere with same behavior (trunk goes down alone and never reconnect) we got this in previous SP5 release 3CX fixed for windows PBxs in .612
Is it something coming back to surface ?

 

[WebMediafields]

Are you using 8.8.8.8 as first DNS on your pbx nic?
Force IPv4 in trunk options
Change Sip domain to IP
refresh register, should be ok

Have tried 8.8.8.8 and 1.1.1.1 and it makes not difference. Doesn't let me add the trunk on ip, rejects for a different reason but does actually send the request. Have already set it to IPv4

 

[cybersur1]

Is your edge router/firewall/switch configured correctly creating a path to the PBX Server?
Can you ping the Sip Trunk server from within the PBX Server?
Have you done a trace-route from the 3cxPBX to your Sip provider?
Have you asked your sip provider to run a trace back to you? (this on is specially great!)

Here is how I resolved the issue

It happened to me also, make sure that your edge router/firewall is allowing ports 5060/5061... and so on through. I have to create a path thru our edge security to the internal switches and hit the 3cx PBX. Once I did that I had to contact my trunk provider to run a trace, to their server and it showed 3cx refuting connection due to credential disparate between the sip provider and 3cx.

My Environment:
Server-2019 (all service packs)
Cisco Edge
Cisco Switches/Routers
Isolated Virtual Net

 

[YiannisH_3CX]

Hi ,@YiannisH_3CX
As we are several from everywhere with same behavior (trunk goes down alone and never reconnect) we got this in previous SP5 release 3CX fixed for windows PBxs in .612
Is it something coming back to surface ?

Currently i cannot answer that as we are still investigating. Once we have more information i will let you know.

 

[FCGScott]

Just an FYI we are seeing this issue on 3 of our client installations on Debian. Most of the threads I've found refer to Windows installations. We're running version 16.0.6.641 Professional and Enterprise.

 

[AWS2P]

@FCGScott Hello,

we are seeing this issue on 3 of our client installations on Debian

never heard here on forum or seen on mine on Debian pbxs, do you use supported sip providers? is it the same provider on the 3PBXs? is it SIP trunk registration based ?

 

[FCGScott]

We're using Skyswitch SIP trunk on all 3 PBXs, registration based. This has been happening about once or twice a day at seemingly random times:

• Trunk L:10003(SkySwitch) has changed status to registered.
  
  SIP Server ID: 4100 09/11/2020 12:07:20 PM
• Trunk L:10003(SkySwitch) has changed status to unregistered. This means that no more calls will pass via this trunk. Please check your network connection and the voip provider or other SIP PBX
  
  SIP Server ID: 4100 09/11/2020 12:07:16 PM

We've had calls drop when it happens, have to hang up and redial - then it works fine until the next time. Skyswitch advised that it may be an IP blacklist issue, we whitelisted all the IPs that Skyswitch recommends in our Sophos and in 3CX but the issue keeps happening.

 

[AWS2P]

Really strange you got this on Debian for now problem was only affecting Windows on premise PBXs, are yours on premise or cloud PBXs?
If not set like that,
Force IPV4
Use 8.8.8.8 as first DNS resolver
Change in trunk settings sip domain and replace with provider IP

 

[FCGScott]

These are all on-prem installs using URL for registration. I should clarify that when this herons, is shown in the log snip above, the trunk re-registers within a few seconds and service is restored without our intervention. I’m going to follow up with Skyswitch on Monday and see if this is just normal behavior in the event that skyswitch routes us to a new switch (failover) on their end.

 

[AWS2P]

so do you mean you get trunks to re-register alone seaming to occur randomly, if this is what you get and each registration succeed then it's just normal trunk behavior, this like it works.