About once a day phones go "no service" until restarting server.

[ghurty]

About once a day the server stops working.

THe phones display "no service" and no incoming calls come in.

All that is displayed on the server log is:

[2011-02-23 12:40:07] VERBOSE[3655] asterisk.c: -- Remote UNIX connection
[2011-02-23 12:40:07] VERBOSE[15899] asterisk.c: -- Remote UNIX connection disconnected
[2011-02-23 12:40:11] VERBOSE[3655] asterisk.c: -- Remote UNIX connection
[2011-02-23 12:40:11] VERBOSE[15906] asterisk.c: -- Remote UNIX connection disconnected
[2011-02-23 12:40:15] VERBOSE[3655] asterisk.c: -- Remote UNIX connection
[2011-02-23 12:40:15] VERBOSE[15913] asterisk.c: -- Remote UNIX connection disconnected

Again and again. Hundreds of lines of it. It only stops when I restart the server.


Those lines start appear though before the server goes dead.
It is Asterisk 1.6.2.13

Any suggestions?

 

[drmurdoch]

I get this as well.
I think it occurs when the PBX can't access the internet.
I seem to get it alot less now that I updated my PIAF install.

 

[sinderlied]

No Service

The phones display "no service" and the system does not pickup calls into the fxo. I have to do an amportal restart nearly every morning around 1000. The log is quite large and takes some time to go through. A pointer on what to look for would be helpful.

Rhino Ceros with 8 fxo
PIAF 1.7.5.5
FreePBX 2.9.0rc1.3
Asterisk 1.6.2.17
Dahdi 2.4.0
Aastra 55i and 57i
Astra XML 2.3

 

[sinderlied]

ntp server

Thanks for the response. I did have time server1 set as pool.ntp.org. I changed it to my local PDC. I also set sip use basic codecs: 1. I have also disabled ipv6 on the pbx. I'd like to have a cron script to automatically restart all the phones nightly. I'll restart everything and see what happens.

 

[sinderlied]

ongoing

I still have the issue, random outages with no service on the phones and no incoming calls. I have directed all phones + the pbx to the local PDC for DNS and NTP. I have prog'd a couple phones to send syslog logs to the pbx. An amportal restart usually fixes it, though sometimes asterisk won't stop so a reboot is req'd.

 

[drmurdoch]

http://pbxinaflash.com/community/threads/57i-goes-no-service-randomly.6496/?t=6496

This thread might help ...

No service, could be your internet is "offline" for a brief period.

http://pbxinaflash.com/forum/showpost.php?p=62185&postcount=86

 

[blanchae]

Have you run any of the online VoIP tests? Maybe test at different times of the day?

 

[dswartz]

It might be nice to install icinga. It's a fork of nagios for monitoring hosts and services. I use it to monitor whether servers are up, the internet too, etc...

 

[sinderlied]

I don't have any sip trunks yet, everything is through fxo/dahdi. I have configured the phones and pbx to get dns and ntp from a local server.

 

[sinderlied]

We don't have any sip extensions, just dahdi for now. The phones and pbx are directed to a local source for dns and ntp. The pbx is local of course. I don't see how the internet would cause this.

It happened again today. I set the phones to syslog to the pbx and these are the last few lines:

May 4 12:05:11 172.16.1.232 06:03:19.690000 UpdateRegistrationStateOnFailure: (SIP) FUNC: CSipEngine::UpdateRegistrationStateOnFailure Enter mac:00-08-5D-29-59-2C
May 4 12:05:11 172.16.1.232 06:03:19.690000 ReceiveState: (SIP) FUNC: idindex is 0, new state is 1 mac:00-08-5D-29-59-2C
May 4 12:05:11 172.16.1.232 06:03:19.690000 EvFailure: (SIP) FUNC: CSipEngine::EvFailure Leave mac:00-08-5D-29-59-2C
May 4 12:07:08 172.16.1.48 06:04:13.220000 RegisterA: (SIP) FUNC: RegisterA: rid: 0 mac:00-08-5D-27-36-4D
May 4 12:07:08 172.16.1.48 06:04:13.220000 InternalRegisterA: (SIP) FUNC: InternalRegisterA: rid: 0 mac:00-08-5D-27-36-4D
May 4 12:07:10 172.16.1.232 06:05:18.690000 RegisterA: (SIP) FUNC: RegisterA: rid: 0 mac:00-08-5D-29-59-2C
May 4 12:07:10 172.16.1.232 06:05:18.690000 InternalRegisterA: (SIP) FUNC: InternalRegisterA: rid: 0 mac:00-08-5D-29-59-2C
May 4 12:07:12 172.16.1.48 06:04:17.230000 EvFailure: (SIP) FUNC: CSipEngine::EvFailure 1 Enter mac:00-08-5D-27-36-4D
May 4 12:07:12 172.16.1.48 06:04:17.230000 UpdateRegistrationStateOnFailure: (SIP) FUNC: CSipEngine::UpdateRegistrationStateOnFailure Enter mac:00-08-5D-27-36-4D
May 4 12:07:12 172.16.1.48 06:04:17.230000 ReceiveState: (SIP) FUNC: idindex is 0, new state is 1 mac:00-08-5D-27-36-4D
May 4 12:07:12 172.16.1.48 06:04:17.230000 EvFailure: (SIP) FUNC: CSipEngine::EvFailure Leave mac:00-08-5D-27-36-4D
May 4 12:07:14 172.16.1.232 06:05:22.690000 EvFailure: (SIP) FUNC: CSipEngine::EvFailure 1 Enter mac:00-08-5D-29-59-2C
May 4 12:07:14 172.16.1.232 06:05:22.690000 UpdateRegistrationStateOnFailure: (SIP) FUNC: CSipEngine::UpdateRegistrationStateOnFailure Enter mac:00-08-5D-29-59-2C
May 4 12:07:14 172.16.1.232 06:05:22.690000 ReceiveState: (SIP) FUNC: idindex is 0, new state is 1 mac:00-08-5D-29-59-2C
May 4 12:07:14 172.16.1.232 06:05:22.690000 EvFailure: (SIP) FUNC: CSipEngine::EvFailure Leave mac:00-08-5D-29-59-2C
May 4 12:09:11 172.16.1.48 06:06:17.220000 RegisterA: (SIP) FUNC: RegisterA: rid: 0 mac:00-08-5D-27-36-4D
May 4 12:09:11 172.16.1.48 06:06:17.220000 InternalRegisterA: (SIP) FUNC: InternalRegisterA: rid: 0 mac:00-08-5D-27-36-4D
May 4 12:09:14 172.16.1.232 06:07:22.690000 RegisterA: (SIP) FUNC: RegisterA: rid: 0 mac:00-08-5D-29-59-2C
May 4 12:09:14 172.16.1.232 06:07:22.690000 InternalRegisterA: (SIP) FUNC: InternalRegisterA: rid: 0 mac:00-08-5D-29-59-2C
May 4 12:09:15 172.16.1.48 06:06:21.230000 EvFailure: (SIP) FUNC: CSipEngine::EvFailure 1 Enter mac:00-08-5D-27-36-4D
May 4 12:09:15 172.16.1.48 06:06:21.230000 UpdateRegistrationStateOnFailure: (SIP) FUNC: CSipEngine::UpdateRegistrationStateOnFailure Enter mac:00-08-5D-27-36-4D
May 4 12:09:15 172.16.1.48 06:06:21.230000 ReceiveState: (SIP) FUNC: idindex is 0, new state is 1 mac:00-08-5D-27-36-4D
May 4 12:09:15 172.16.1.48 06:06:21.230000 EvFailure: (SIP) FUNC: CSipEngine::EvFailure Leave mac:00-08-5D-27-36-4D

It appears that a call into DAHDI/4-1 was the last thing that happened before the crash

[2011-05-04 11:07:01] VERBOSE[506] manager.c: == Manager 'admin' logged on from 127.0.0.1
[2011-05-04 11:07:02] VERBOSE[506] manager.c: == Manager 'admin' logged off from 127.0.0.1
[2011-05-04 11:09:01] VERBOSE[844] manager.c: == Manager 'admin' logged on from 127.0.0.1
[2011-05-04 11:09:02] VERBOSE[844] manager.c: == Manager 'admin' logged off from 127.0.0.1
[2011-05-04 11:09:29] VERBOSE[922] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:09:29] VERBOSE[922] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1
[2011-05-04 11:11:11] VERBOSE[1193] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:11:11] VERBOSE[1193] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1
[2011-05-04 11:11:12] VERBOSE[1195] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:11:12] VERBOSE[1195] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1
[2011-05-04 11:11:12] VERBOSE[1196] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:15:59] VERBOSE[2018] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:15:59] VERBOSE[2018] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1
[2011-05-04 11:42:20] VERBOSE[6243] chan_dahdi.c: -- Starting simple switch on 'DAHDI/4-1'
[2011-05-04 11:43:10] VERBOSE[6377] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:43:10] VERBOSE[6377] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1
[2011-05-04 11:43:42] VERBOSE[6484] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:43:42] VERBOSE[6484] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1
[2011-05-04 11:43:43] VERBOSE[6488] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:43:43] VERBOSE[6488] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1
[2011-05-04 11:43:49] VERBOSE[6523] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:43:49] VERBOSE[6523] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1
[2011-05-04 11:44:29] VERBOSE[6645] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1
[2011-05-04 11:44:29] VERBOSE[6645] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1
[2011-05-04 11:44:29] VERBOSE[6649] manager.c: == Manager 'aastra-xml' logged on from 127.0.0.1

 

[blanchae]

What device are you using for the Dahdi channels?

[2011-02-23 12:40:07] VERBOSE[3655] asterisk.c: -- Remote UNIX connection
[2011-02-23 12:40:07] VERBOSE[15899] asterisk.c: -- Remote UNIX connection disconnected

These usually occur when you are ssh'ing in or if you have FreePBX on the status page and it updates about every 3 second. Nothing to worry about.

 

[blanchae]

Are you running the Endpoint Manager? I wonder what this is?

[2011-05-04 11:43:42] VERBOSE[6484] manager.c: == Manager 'aastra-xml' logged off from 127.0.0.1

 

[sinderlied]

I think that is the aastra-xml service accessing asterisk. The following are the hardware specs:

CerosDT-160GB
R24FXX-EC-0004

 

[sinderlied]

I got this from Rhino support:

My thoughts is whatever the Aastra is doing is effectively causing a denial of service. Asterisk is the one who answers calls. If it is too bussy with other tasks it will not answer calls or hold a sip registration which are the two things you report as issues. If it was a hardware level issue restarting the software would not fix it you would have to reset the hardware through a cold or warm boot.

I wonder if Aastra1 is around?