similar to: PRI B-Channel restarting itself continually

On 2016-02-17 15:32, Richard Mudgett wrote: > On Wed, Feb 17, 2016 at 5:15 PM, Ernie Dunbar <maillist at lightspeed.ca> > wrote: > >> Hi everyone. >> >> We have an Asterisk server running Debian Squeeze, with Asterisk >> v1.8.13.1 (basically, the Debian Stable version for Squeeze, but >> with some minor source code changes specific to our site).

This past holiday weekend has resulted in some real groaners when it comes to bugs in our dialplan, making obvious the need for some changes in our procedures. First, our hours of operation for Christmas Eve, Christmas, Boxing Day and New Year's Eve had changed with little to no notice. Okay, fine, whatever, I fix. Our Christmas Eve hours (made worse by being Monday this year) dialplan

Hi All, Hope you all are fine and good, Today i have found that Mine all PRI Channels are restating after every interval of one hour, and i have search and psot on fourms and everyone said that this is a normal behaviour. If this is a normal behaviour is there is any way to stop it { i still don't know what is the reson to restart ever hour } . Because this is listed everywhere that

We have an issue with our Asterisk install where Asterisk produces many Zombie processes (on the order of several hundred per minute) until either the Asterisk server is restarted (and the zombies die a natural death), or the kernel runs out of PID space (happens within hours) and brings the system to a halt. This problem only happens when the server is under some non-trivial load. We were

Okay, so here's the configuration I have for MySQL Realtime (Asterisk version 1.6.2.17): In /etc/asterisk/extconfig.conf: sipusers => mysql,mya2billing,cc_sip_buddies In /etc/asterisk/res_mysql.conf: [mya2billing] dbhost = localhost dbname = mya2billing dbuser = a2billinguser dbpass = REDACTED dbport = 3306 And here's the error messages I get: voip2*CLI> realtime mysql status

Hi everyone. We have an Asterisk server running Debian Squeeze, with Asterisk v1.8.13.1 (basically, the Debian Stable version for Squeeze, but with some minor source code changes specific to our site). We're trying to upgrade to 11.13.1 (The Debian Stable version for Jessie), but I've run into a snag when compiling res_fax_spandsp (and yes, we really need that module). The old

We have two Asterisk servers. One is a live server supporting our customers, and the other is a backup server that's being upgraded and pressed into service. Both servers have a Digium TE405P T1 card in them, and in order to test the T1 service on the backup server, I've created a T1 crossover cable (as per http://www.voip-info.org/wiki/view/crossover+T1+cable) that goes from port 4 on the

You need to ensure that traffic to the SIP box is sent to the correct IP. Also if you use split-tunnel (eg: not redirect-gateway def1) you must make sure NAT and traffic redirection works as is so the Asus router knows it should send the traffic through tunnel and not via WAN. IMPORTANT: Then you must, in the ASUS RT-N66U make a port forward inwards from TUN to the phone client. I would suggest

This *should* be something that's easy to fix, but apparently I'm not doing something right. Our SIP long distance provider is telling us to only use formats G.723 and G.729, so I've set up their trunk configuration in sip.conf as such: [t564] type=friend host=XXX.XX.56.4 context=default disallow=all allow=g723 allow=g729 However, the Dial application gives the following error:

I understand from the archives that * does this occassionally, but I'm trying to figure out why. * didn't do this at all for two days, and then it's gone and done it 3 times in the past hour. It does not seem to be affecting calls, I'm just curious as to the reasoning behind the B channel resets and why they are so erratic. Regards, Andrew

I'm kind of at a loss to diagnose problems like this, yet we get them a lot. - The ATA (Thomson 784 in this particular case) is logged into the Asterisk server. 'sip show peer' shows their IP address, port, and useragent. - The ATA is connected directly to the internet (no NAT, but the sip configuration has nat=always) and logs in to our server, which is also directly connected to the

I have not been able to get two B-channel transfer to work on DMS100 PRI. I consistently get the following errors: [Nov 6 11:12:49] ERROR[2774]: chan_zap.c:8178 zt_pri_error: ROSE RETURN ERROR: [Nov 6 11:12:49] ERROR[2774]: chan_zap.c:8178 zt_pri_error: OPERATION: RLT_OPERATION_IND [Nov 6 11:12:49] ERROR[2774]: chan_zap.c:8178 zt_pri_error: ERROR: RLT Not Allowed I have tried on two

Hello, A client has asked for Two B channel Transfer capability (known as TBCT or 2BCT, similar to other features such as ECT, RTL and Q,SIG Path Replacement) in a new Asterisk system and so I researched the capability and came up with quite a few gaps in documentation.

This is a problem that is completely stumping me, and my understanding of Asterisk dialplans tells me this should never be a problem. Moreover, this scenario works on Asterisk 1.4 but not 1.6. We have a customer with several Aastra 6731 phones. They want incoming calls from the PSTN to work and they also want to be able to call each other "internally" on a special non-DID number (like

after installing asterisk 1.4.23.1 and dahdi-linux-2.1.0.4 and at CLI> module load chan_dahdi.so receive the following: signalling must be specified before any channels are. CLI> Warning [4663]: chan_dahdi.c:11627 process_dahdi: Ignoring signalling Error[4663]: chan_dahdi.c:10946 build_channels: Unable to reconfigure channel '1' Error[4663]:

Hi. I still hace problems getting my line to work. When I start asterisk, I can see: == Parsing '/etc/asterisk/zapata.conf': Found -- Registered channel 1, PRI Signalling signalling ... -- Registered channel 31, PRI Signalling signalling == Starting D-Channel on span 1 == Registered channel type 'Zap' (Zapata Telephony

>> Hi! >> I have an Asterisk Box with one E1. This is connected >> with PSTN. My problem is that periodically the >> Asterisk console shows the following message. >> >> -- B-channel 0/1 succesfully restarted on span 1 >> -- B-channel 0/2 succesfully restarted on span 1 >> [..etc...] >> >> I don't know if this behavior is correct.