* You are viewing Posts Tagged ‘PRI’

Recieve Fax From PRI Using Spandsp 65% Failure Rate


On one of our servers, we’re having problems with incoming faxes. The connections come in through a PRI into a Digium TE820 card. ‘fax show stats’ yields the following:

FAX Statistics:

Dahdi Configuration Issue

Hello List,

I have configure 2 sangoma card each with 8 PRI lines with dahdi 2.6

the problem is i can see all channels configured in dahdi_cfg 480 channels configured but when I see /dev/dahdi i can only see 240 channels.

what could be problem I am using it wanrouter and when I put PRI in new card i only got calls on new line that means one of the card is inactive at same time all the lines and alarms are okay only suspected thing is

is there nany setting in linux or kernel level which need to be set for solve this issue.

any help appreciated.

Thanking You


What Would Cause A Drop Between Two Asterisk Systems?

We have an asterisk frontend terminating all our SIP phones to, and an asterisk backend with a wildcard PRI card in it connecting to the PTSN. The frontend handles 99% of dialplan logic and just hands off anything outgoing to the backend via IAX2, which dials out on one of the open channels.

Lately we’ve been getting a disconnected calls. Keeping the consoles running it doesn’t seem to be the PRI initiating the hangups, as I’ll when I see hangups intiiated on the backend / PRI side:

— Span 2: Channel 0/21 got hangup request, cause 16

Instead, I’m seeing

== Spawn extension (outbound, (dialed #), 3) exited non-zero on ‘IAX2/asterisk-frontend2-603′
— Hungup ‘IAX2/asterisk-frontend2-603′

Which indicates the frontend initiated a hangup. But on the frontend I’m seeing auto fallthroughs to the h extension, which only happens if the hangup is initiated from the backend:

— Auto fallthrough, channel ‘SIP/phone1-00000167′ status is ‘ANSWER’
(h extension stuff follows)

If that side was initiating the hangup, I’d just see a jump to the h extension, with no auto fallthrough. So it looks like there may be a communication interruption between the front and backends.

The problem is this happens intermittently, so I can’t reproduce it reliably. I’ve held open a call for 30+ minutes and not run into the problem, while someone’s been on a call for 7 minutes and this happens. It doesn’t seem feasible to constantly run IAX2 debugs from the console on any open call – does anyone have suggestions on how to troubleshoot this? Weirdly enough, this only seems to happen when users dial into conference bridges (not local) such as WebEx and GoToMeeting, but that might just be because of the length of those calls.

Will tweaking things like the IAX2 jitter buffer help? The two systems are barely four hops apart with an average of .2 ms ping times between them on a very resilient network (two of those hops are through core transports). I’ve never seen ping loss between them, even when running ping tests for hours during heavy call volume periods. The loads on the machines are minimal – never seen the load go above .10 during normal operation. But it does seem like something between them is making them drop calls.


Asterisk 11 – No “pri Set Debug Off”


In a machine I’ve got :
CLI> pri set debug off No such command ‘pri set debug off’ (type ‘core show help pri set’ for other possible commands)

CLI> core show help pri
pri intense debug span
pri service disable channel Remove a channel from service
pri service enable channel Return a channel to service pri set debug {on|off|hex|inte Enables PRI debugging on a span
pri set debug file Sends PRI debug output to the specified file
pri show channels Displays PRI channel information
pri show debug Displays current PRI debug settings
pri show spans Displays PRI span information
pri show span Displays PRI span information
pri show version Displays libpri version

My setup is :
asterisk 11.2.1
libpri 1.4.14
dahdi 2.6.1

So inline CLI tells “pri set debug off” exists but I can’t run it.

Did I miss something ?


Congestion() Forcing PRI Channels To Be Not Available

Hi, I have a PSTN Asterisk box that’s connected to other dialplan PBXes through IAX2.

Recently this box was upgraded to 1.4.44 with the latest DAHDI version. I’ve noticed that if one of the dialplan PBXes calls Congestion(), the PRI
will return ISDN code 34 (as its supposed to do). However, the issue is that subsequent calls into that PRI channel are immediately responded by a Code 44 (channel not available) even though there is no live call on the channel.

Has anyone else experienced this behavior? Its a pretty crippling behavior since all of our channels eventually become unresponsive until a ‘dahdi restart’ is issued.


– James

23B + D Asterisk TDMoE (packetized PRI) Link Question.

Can anyone help me find a specification for the 23B + D Asterisk TDMoE
(packetized PRI) link?

I am having occasional packets arrive from the Asterisk Server that do not have the standard four leading characters in front of the MAC addresses, and am not sure what this implies. For now, I discard such packets.

Also, I’m getting HDLC abort messages from the Server that occur almost exclusively in heavy call set-up traffic, despite that the PRI-style messages in both directions appear to have correct indices, Call Reference Numbers, etc.

If you can answer the question or if you know where to go to get the answer that information would be appreciated.

Thank you,

Aaron Bailey