QUESTION DIDs losing registration

[geopeterwc]

I have two PIAF boxes installed on the same LAN (different IP addresses assigned to each box) and for the most part, they are functioning as designed/intended.

Occasionally on checking the SIP Information (Reports), I find all of my DIDs reporting in the "State" column: "Request Sent". Obviously, the DIDs are not registered at this point but restarting the box from the Linux CLI: "shutdown -r now". When the box restarts, all is restored, and the DIDs are properly registered. This problem often does not resurface but after several days of normal operation. Quick fix, but I'm not always nearby to restart the box.

PIAF1
-----
PIAF Installed Version  = 2.0.6.3 under *HARDWARE*
FreePBX Version          = 2.10.1.15 2.10
Running Asterisk Version = 1.8.20.1
Asterisk Source Version  = 1.8.20.1
Dahdi Source Version    = 2.6.1+2.6.1
Libpri Source Version    = 1.4.12
IP Address              = 192.168.0.NN1 on eth0
Operating System        = CentOS release 6.3 (Final)
Kernel Version          = 2.6.32-279.19.1.el6.x86_64 - 64 Bit
 
PIAF2
-----
PIAF Installed Version  = 3.0.6.6 under *HARDWARE*
FreePBX Version          = 2.11.0.42
Running Asterisk Version = 11.15.0
Asterisk Source Version  = 11.15.0
Dahdi Source Version    = 2.10.0.1
Libpri Source Version    = 1.4.15
IP Address              = 192.168.0.NN2 on eth0
Operating System        = CentOS release 6.6 (Final) ><
Kernel Version          = 2.6.32-504.3.3.el6.x86_64 - 64 Bit

I have tried just "Asterisk Restart" from the Linux and the Asterisk CLI, but only get "command not found" or similar error messages.

All of my DIDs are from Vitelity - Vitelity has suggested that my ISP (Comcast) is blocking my SIP traffic periodically(?).

The Cable Modem is a Motorola SB6141; the Firewall/Router is PFSense, 64-bit, version 2.1.5.

I would appreciate any insight as to the cause of the DIDs effectively going off-line and suggestions for resolving the issue.

/Pete./

 

[hecatae]

hi geopeterwc,

amportal reload

reloads your asterisk and freepbx configuration

amportal restart

restarts all important stuff, asterisk, fop server, etc

to restart asterisk as a service, run

service asterisk restart

 

[geopeterwc]

hi geopeterwc,

amportal reload

reloads your asterisk and freepbx configuration

amportal restart

restarts all important stuff, asterisk, fop server, etc
to restart asterisk as a service, run

service asterisk restart

Thanks for the feedback hecatae ... I am aware of those options (I misstated them in my original posting), but I don't expect that I should have to restart anything. This is frustrating because all of my DIDs are effectively shut down when this happens ... sometimes as often as a couple of times a week! There's got to be some cause for this happening that can resolve the frequency of having to "touch" the PIAF boxes.

 

[john p]

A few questions come to mind.
1. Does it affect both boxes at once or only 1?
2. What do the logs show (e.g., asterisk -vvvvvvvr) when a registration attempt occurs or when you execute "sip show registry"?
3. Presume you are NOT attempting to register outgoing trunks with Vitelity - that used to be OK but then is caused what you report for the incoming trunks?
4. When not registered, does Vitelity show your devices on their status panel?
Not an expert but I've been using Vitelity with PIAF for a couple of years & this is what comes to mind.

 

[kenn10]

If you have two boxes on the same LAN behind a router and both PBX's try to register the same account (Vitelity for example) it will confuse the vendor's registration server and Asterisk. Behind a NAT router, the PBX's will appear as the same IP address to the SIP provider. The timing of registration retries will likely cause a reject on one of the registration attempts because the other box has an active registration.

I resolved a similar issue by having two sub-accounts with the same vendor so each box could register to a different account. If you are using different vendors or accounts on your boxes and still have this issue, I'd look to the router for issues.

One other thing to look at is the Registration Timers in the Settings >> Asterisk Sip Settings. I keep my Minexpiry set to 60 seconds.

 

[jroper]

Hi

I've seen similar to kenn10

I solved the issue by simply passing all calls via one box, and bouncing the DID to the second box.

To restart Asterisk, / FreePBX it's important to use the amportal command, e.g. amportal restart or amportal kill && amportal start

Joe

 

[Trimline2]

Don't know if this will assist you, but there is a write up similar http://www.dslreports.com/forum/r29478349-CallCentric-lost-registration~start=30

I do have register_retry_403 = yes on my installations.

 

[geopeterwc]

If you have two boxes on the same LAN behind a router and both PBX's try to register the same account (Vitelity for example) it will confuse the vendor's registration server and Asterisk. Behind a NAT router, the PBX's will appear as the same IP address to the SIP provider. The timing of registration retries will likely cause a reject on one of the registration attempts because the other box has an active registration.

The PBXs are utilizing different LAN IP addresses; and different Vitelity accounts. #2 has two Vitelity accounts (nxxnxx4912 and nxxnxx4913). #1 has several other Vitelity accounts including nxxnxx4911, nxxnxx4910, nxxnxx4919 and nxxnxx5119.

So even though they're on the same LAN, they are operating independently.

 

[MGD4me]

So even though they're on the same LAN, they are operating independently.

Yes, but...

Is it possible that Vitelity is seeing only your single WAN IP address, not the two internal LAN address?? Just a shot...

 

[geopeterwc]

Yes, but...
Is it possible that Vitelity is seeing only your single WAN IP address, not the two internal LAN address?? Just a shot...

Could be, but the failed registration has been occurring prior to PBX2 being brought on line (ultimately to replace PBX1). The failed registrations was the impetus for a rebuild to a new box, since the 2063 box is getting on in age.

MOST of the time, the DIDs in both boxes are registering properly and functioning as designed. They can operate without losing registration for a couple of weeks without problems. Then, when the Sip Info reports "Request Sent" for all of the DIDs, rebooting the server fixes it.

 

[texy]

I wonder if there is a firewall state table in a weird state. I've seen that happen with IAX trunks and had to either restart asterisk or have netops clear the firewall state tables.