similar to: Disable connected line updates for dahdi PRI channel

We fairly recently switched service providers for our 4 PRI circuits. Since that time, we started to notice some failed inbound calls. These calls terminate with an ISDN cause code 47 'resource unavailble'. Most of the time I see this error on the first or second channel on the second span in a trunk group (This is the providers trunk group for hunting, not an Asterisk trunk group). All

Hello, I seem to be having an issue with the configuration of my PRI on a new asterisk server I've created to replace an old install that I have. The card is Digium Wildcard TE133. I continually get messages like "Primary D-Channel on span 1 down", rather irregularly: [2013-07-29 17:31:39] VERBOSE[3621] sig_pri.c: == Primary D-Channel on span 1 up [2013-07-29 17:31:39]

Asterisk 1.8.4-rc2 (and 1.8.3) DAHDI Version: 2.4.1.2 libpri version: 1.4.12-beta3 We are having a problem with getting the nationalprefix option of chan_dahdi.conf to work. National calls do not have a "1" added to them when nationalprefix=1. The PRI debug shows the call coming in as a National Call, but the dialplan sees the call without a 1. chan_dahdi.conf: <snip>

I am trying to setup Asterisk to act like a PBX connected via a PRI gateway to a voice netowrk where Asterisk is doing outbound overlap dialing for calls that terminate via that PRI. AFter researching through the archives and online dcocs, I thought I had everyting setup right, dialplan configured for '_X!' and the 'overlapdial=yes' in the chan_dahdi.conf file, but when I try and

Hello everyone, I am facing a strange problem on my asterisk box (using isdn lines with pri card installed on it). Normal incoming/outgoing calls are working perfectly fine. When a user dial a wrong/out-of-service number they don't hear back any such message like "The number is wrong or user is switched off" in some cases, and it's just a silence for the user. Now while

Hello, I am trying to diagnose an intermittent error when a call comes in over our PRI lines. The problem appears random, however I have feeling it has something to do with the call volume, as the frequency increases with more calls on the system. I am not an expert when it comes to reading the PRI Span Debug statements but here is a call that had a problem and I bolded, italicized, and

Hi I have done everything richard told to do ECT . below is my trace, anyone can help ? -- DAHDI/i1/09123278669-4 answered DAHDI/i1/88050048-3 -- Native bridging DAHDI/i1/88050048-3 and DAHDI/i1/09123278669-4 PRI Span: 1 Adding facility ie contents to send in FACILITY message: PRI Span: 1 ASN.1 dump PRI Span: 1 Context Specific/C [1 0x01] <A1> Len:11 <0B> PRI Span: 1

The latest libpri is supposed to handle this properly, but doesn't seem to. Here's the debug info. CALLERID(name) is set to empty. < Protocol Discriminator: Q.931 (8) len=66 < TEI=0 Call Ref: len= 2 (reference 256/0x100) (Sent from originator) < Message Type: SETUP (5) < [04 03 80 90 a2] < Bearer Capability (len= 5) [ Ext: 1 Coding-Std: 0 Info transfer capability:

Hi list! We currently have a PRI gateway composed by a box with two Digium quad-span PRI cards (a TE420 and a ). One of the cards is filled with TELCO1, while the other has first two slots filled with TELCO2, and 3rd slot with TELCO3. I am currently having (timer ?) issues on TELCO3 (span 7) D-Chan (202 as determined by dahdi_genconf ) is constantly failing causing on-going calls to terminate.

Hi all, Last night I went to replace an Asterisk 1.4 + mISDN + b410p box with Asterisk 1.6.2 and DAHDI BRI - to no avail. I had two servers so copied network setting etc from the working one, moved the card across, ran dahdi_genconf etc and it didn't work. Here's the console output with notices disabled: lucas*CLI> pri intense debug span 1 Enabled debugging on span 1 [Dec 16

I just updated libpri 1.4 on my system to the latest from that branch and my QSIG connection to an NEC SV8300 stopped working. The trace showing the problem is below: q931.c:5640 q931_connect: Call 7168 enters state 10 (Active). Hold state: Idle > DL-DATA request > Protocol Discriminator: Q.931 (8) len=21 > TEI=0 Call Ref: len= 2 (reference 7168/0x1C00) (Sent to originator) >

Hello, I'm experiencing some weird problems on my server: - 1) The following messages are filling up my logs: [Sep 29 08:24:59] WARNING[7077]: chan_dahdi.c:2789 pri_find_dchan: No D-channels available! Using Primary channel 140 as D-channel anyway! [Sep 29 08:24:59] WARNING[7078]: chan_dahdi.c:2789 pri_find_dchan: No D-channels available! Using Primary channel 171 as D-channel anyway!

I have some more investigation to do on this, but I wanted to see if anyone here had any insight into the issue I've run into. The hardware is a HP DL360 G6 with a TE420 gen 5 4-port T1 PRI card. It is one of several systems that have been running without issue since 2010/2011. They have all been running CentOS 4 32-bit with Zaptel 1.4.12.1 (with patch for gen 5 card), libpri 1.2.8 and

Hello, I'm reading this in my log files: [Mar 25 12:01:23] WARNING[1593] sig_pri.c: Span 1: Got SETUP with duplicate call ptr (0x8e3b998). Dropping call. [Mar 25 13:21:40] WARNING[1593] sig_pri.c: Span 1: Got SETUP with duplicate call ptr (0x8e3b998). Dropping call. [Mar 26 10:20:54] WARNING[2643] sig_pri.c: Span 1: Got SETUP with duplicate call ptr (0x8e06788). Dropping call. [Mar 26

Hi all, So, we reverted the LibPRI version and tested it, and then tried with the latest version of everything. Still no changes. The BRI line is in PTMP. If we set the configs to PTMP in the genconf_parameters and try it, we get the following: [Jan 21 17:32:20] ERROR[20341]: chan_dahdi.c:12645 dahdi_pri_error: Unable to receive TEI from network! If we set it to PTP (which it is not) we

In article <CAHZ_z=w5DMg93gShtC93kuC+fnmraPgV46BS956U5BQXVgyhxg at mail.gmail.com>, Matt Fredrickson <creslin at digium.com> wrote: > On Tue, Apr 3, 2018 at 5:44 AM, Tony Mountifield <tony at softins.co.uk> wrote: > > I have some more investigation to do on this, but I wanted to see if anyone > > here had any insight into the issue I've run into. > > >

What is this error ? is this harmful ? *CLI>*CLI> dahdi restart [Mar 23 14:01:06] WARNING[4314]: chan_dahdi.c:17422 process_dahdi: Ignoring any changes to 'userbase' (on reload) at line 23. [Mar 23 14:01:06] WARNING[4314]: chan_dahdi.c:17422 process_dahdi: Ignoring any changes to 'vmsecret' (on reload) at line 31. [Mar 23 14:01:06] WARNING[4314]: chan_dahdi.c:17422

On Tue, Apr 3, 2018 at 4:57 PM, Matt Fredrickson <creslin at digium.com> wrote: > On Tue, Apr 3, 2018 at 4:38 PM, Tony Mountifield <tony at softins.co.uk> > wrote: > > In article <CAHZ_z=w5DMg93gShtC93kuC+fnmraPgV46BS956U5BQXVgyhxg@ > mail.gmail.com>, > > Matt Fredrickson <creslin at digium.com> wrote: > >> On Tue, Apr 3, 2018 at 5:44 AM, Tony

Hi I am experiencing Asterisk Crash. Log got stopped when asterisk crashed. Please help me to identify the reason and fix this issue. Asterisk: 1.8.20 I am using AMI and fastAGI to control the call. Some part of dial plan is also defined in extensions.conf I am experiencing this crash when app_meetme conference functionality is used with more than 3 parties. I faced this issue with

Hi List, I have configured TE121PF card in E1 mode. I am using asterisk 1.6 and freepbx 2.7. My card staus turn in to green and looks like sync with the service provider. My service provider is BSNL - India. I have one toll free number for incoming and one land line number for out going calls. Problem : If i am calling to the toll free number, i am getting the ring but that call is