NO JOY SIP Registrations started timing out

[Bill Green]

Hi Guys,

I've been running PIAF Green for about a year now with no trouble.
This morning I arrived to find my SIP trunks to Vitelity and VOIP.MS unregistered, and timing out on the attempt.
Our Internet service plan changed a few days ago requiring a different Static IP, so I checked the NAT settings in SIP re-entered them, and restarted the server. Still no success. I've been perusing these forums as well as the help sections of the providers with no luck.
I am assuming I'm missing something silly, so please ask any "bonehead questions".

 

[hecatae]

have you informed Vitelity and VOIP.MS that your ip has changed?

 

[atsak]

Do you have a firewall in front of the server? Is it setup for NAT on the new IP?

 

[Trimline2]

Did you check the entry in the /etc/hosts file to make sure that it resolves to the new IP address? I just went through something similar and had to refresh the host name/IP address accordingly.

 

[Bill Green]

have you informed Vitelity and VOIP.MS that your ip has changed?

I didn't think I would need to inform my providers of an IP address change. I have actually changed it to our backup provider with no trouble in the past. That said, I have been in contact with VOIP.MS support. they had me download and setup Zoiper softphone which connected with out a problem. That seems to point to something in the PIAF server.

 

[Bill Green]

The IPV4 entry in my etc/hosts file is just the loopback. the server ip hasn't changed anyway, just the public Firewall IP.
The firewall seems to be allowing the SIP transactions for Zoiper to register.

Is there something to check other than the NAT settings under Asterisk SIP?

 

[Bill Green]

Well, I've found that if I route the did directly to the Zoiper softphone, bypassing the PIAF server, I can complete a call from my cell phone.
The PC running Zoiper is on the same network as the PIAF server, so the answer is in the server somewhere.

 

[hecatae]

have you set "advanced sip settings" to your new public ip?

 

[Bill Green]

Hecate, I'm not finding "Advanced SIP settings". I'm running PIAF Green 2.0.6.2 on FreePBX 2.11.0.37, Asterisk 11.4.0.
Is it somewhere else in my version, or am I just suffering pre-caffeine cognitive failure?

 

[hecatae]

I apologise, I meant Settings, Asterisk SIP Settings

 

[Bill Green]

Ahh, the NAT settings. Yes, I changed that to our new address. I just did an Auto configure for that section just to see. Didn't change anything.

I configured the Log reader for my Firewall to just show VOIP info and got an interesting result. [sanitized]

1 12/08/2014 13:06:38.304 Debug VOIP SIP Response 66.241.99.28, 5060, X1 192.168.x.x, 5060, X0 SIP REGISTER (401 Unauthorized) ([email protected])
2 12/08/2014 13:06:38.256 Debug VOIP SIP Request 192.168.x.x, 5060, X0 66.241.99.28, 5060, X1 SIP REGISTER ([email protected])
3 12/08/2014 13:05:07.880 Debug VOIP SIP Response 66.241.99.28, 5060, X1 192.168.x.x, 5060, X0 SIP REGISTER (401 Unauthorized) ([email protected])
4 12/08/2014 13:05:07.816 Debug VOIP SIP Request 192.168.x.x, 5060, X0 66.241.99.28, 5060, X1 SIP REGISTER ([email protected])
5 12/08/2014 13:03:54.784 Debug VOIP SIP Request 192.168.x.x, 5060, X0 74.54.54.178, 5060, X1 SIP REGISTER ([email protected])
6 12/08/2014 13:03:37.592 Debug VOIP SIP Response 66.241.99.28, 5060, X1 192.168.x.x, 5060, X0 SIP REGISTER (401 Unauthorized) ([email protected])
7 12/08/2014 13:02:52.352 Debug VOIP SIP Request 192.168.x.x, 5060, X0 66.241.99.28, 5060, X1 SIP REGISTER ([email protected])
8 12/08/2014 13:02:07.192 Debug VOIP SIP Response 66.241.99.28, 5060, X1 192.168.x.x, 5060, X0 SIP REGISTER (401 Unauthorized) ([email protected])
9 12/08/2014 13:01:19.544 Debug VOIP SIP Request 192.168.x.x, 5060, X0 66.241.99.28, 5060, X1 SIP REGISTER ([email protected])
10 12/08/2014 13:00:03.880 Debug VOIP SIP Response 74.54.54.178, 5060, X1 192.168.x.x, 5060, X0 SIP REGISTER (401 Unauthorized) ([email protected])
11 12/08/2014 13:00:03.832 Debug VOIP SIP Request 192.168.x.x, 5060, X0 74.54.54.178, 5060, X1 SIP REGISTER ([email protected])
12 12/08/2014 12:59:04.032 Debug VOIP SIP Response 66.241.99.28, 5060, X1 192.168.x.x, 5060, X0 SIP REGISTER (401 Unauthorized) ([email protected])
13 12/08/2014 12:59:03.928 Debug VOIP SIP Request 192.168.x.x, 5060, X0 66.241.99.28, 5060, X1 SIP REGISTER ([email protected])
14 12/08/2014 12:57:24.656 Debug VOIP SIP Response 66.241.99.28, 5060, X1 192.168.x.x, 5060, X0 SIP REGISTER (401 Unauthorized) ([email protected])

and on and on. I'm not seeing any corresponding activity in the asterisk log file.

It looks like incoming activity is being rejected as Unauthorized, but both providers' web portals, show that the DIDs are Registered.

 

[Trimline2]

Double-check Vitelity online - they at one time changed me from inboud25 to inbound30 and didn't notify me. That may be your issue as well.

 

[john p]

As a trial, I think I'd try changing the registration string for one of the trunks from the name to the associated IP & see if this changes things. If you can register with the direct IP but not the name, I think either the firewall of the PBX is failing name lookup. You could also ensure your firewall rules allow the trunks' IPs. Hope this helps.

 

[Bill Green]

Update: I have found that I was not waiting long enough. Anytime my Public IP address changes, SIP services will not register for about 20 minutes. I also found that I can call out immediately.
What was throwing me (and continues to do so) is that Incoming calls fail. at this point, I have registered trunks and outgoing capability, but Incoming calls never seem to reach the PIAF box. If I disable the DID in PIAF and configure it on a Zoiper softphone, It works beautifully.
I have now even built a second PIAF machine with one extension and the DID with the same result. No Incoming.
I am currently working on a PFsense firewall to A/B against my Sonicwall.

 

[hecatae]

Sonicwall?!?

I have had real issues getting Asterisk and Avaya working with Sonicwalls.

 

[Bill Green]

Hmmm. Sounds more and more like I may be posting in the wrong topic.

 

[Bill Green]

For the sake of browsers to follow, I have found that VOIP.MS doesn't seem to care what IP you connect from, and Vitelity has a section under your web login > security settings to enter acceptable IP addresses. That and Asterisk SIP settings > NAT section should normally be all you need to do.
I seem to be having issues unrelated to the Service Providers, so I will continue this in the Help Topic.
Thank You to all who ventured suggestions. I did consider and check every suggestion though I did not reply to all of them.

 

[john p]

Thanks for the update. I'm not certain I understand what you are seeing & have the following questions/thoughts.
1) Does Vitelity show your inbound trunk registered on their site?
2) As I understand it, Vitelity can use an IP address rather than password authentication via their settings. My account does not include my PBX's IP & everything works.
3) Am I correct assuming your outbound trunk register string is blank? If not, this can produce intermittent incoming call or registration failures.
I'm using the firewall integated in my DD-WRT router & it needed no custom settings or open ports. Good luck.

 

[EndeavorPBX]

You didn't tell us if your PIAF was behind a NAT router or not, but that is often the cause of these types of issues. I've found that NAT routers (bad ones especially) sometimes screw up the routing table and route inbound packets to the wrong place, or re-write outbound packets with the wrong source address. Whenever you experience such an issue, do the following:

1. From the command line of PIAF, issue this command:

amportal stop

2. Then power off your router and modem. Wait 5 minutes. Then power on your modem, let it boot fully, then power on your router.

3. From the command line of PIAF, issue this command:

amportal start

 

[Bill Green]

>john p
Yes, my account has now been registered for a couple of weeks straight, and it is using password auth instead of ip address. The Outbound Register string is blank. and outbound calls work well.

>endeavorpbx I will give that a shot this weekend.

I am pretty convinced the trouble is in the SonicWall Firewall, and I am currently moving toward changing to a PFSense Firewall.
In the meantime, I have all incoming calls going over our copper lines.