* You are viewing the archive for August, 2010

TELUS British Columbia PRI Settings With Asterisk

I am having some difficulties getting my Asterisk box to find the d-channel from a TELUS PRI and am waiting to hear back from one of their techs. In the meantime I thought I would check with the brilliant people of the mailing list.

As I understand it is a T1 connection, not an E1 and I am using a Digium TE121 with hardware echo cancellation. I have green lights on the back of the card and the PRI connection, which go red when I do a dahdi restart command and come back to green once it is finished.

I know from our other system that the frame and coding are ESF and B8ZS so it must be something in the signaling of the channels. My chan_dadhdi is below, the commented out lines are ones I have tried. I’ve also tried moving the dchannel around, 12 through 24. Does anyone see anything blatantly wrong?

Thanks, Jeremy


trunkgroup => 1,24
spanmap => 1,1,0,esf,b8zs

#include /etc/asterisk/dahdi-channels.conf

;signalling => em
;signalling => pri_net
signalling => pri_cpe
;group = 1
bchannel => 1-12
dchannel => 24

Asterisk DTMF RFC2833 issues

This issue is that when calls are run through Broadvox and Level 3 the in-call rfc2833 dtmf is not reliable. This occured for me on asterisk version, it appears to have been fixed when I went to but broken again in I have tested with Grandstream and SNOM phones and both fail 90% of the time Unidata phones fail 10% of the time Audiocodes and Grandstream ATA’s appear to not suffer from the issue on any version of asterisk.

What happens is when a caller trys to enter DTMF keys durring a call the far end routed through these carriers do not detect all of the digits. We did captures with broadvox and here is what they have said.


Asterisk and Double DTMF Digits Issue

I’ve been getting complaints lately that callers to my IVR are pressing a digit once but the system is responding as if they pressed it twice (once for each of two consecutive menus). I’m using an AGI script and logging all DTMF entries – and to the script, at least, it looks like the digit is being pressed twice. The TN being called is a VOIP number (provided by Flowroute) and being forwarded via SIP to my Astersisk server The dtmfmode is set to rfc28333 in sip.conf.

The first time this happened, I figured the caller pressed the number twice without realizing it. It’s happening to too many people for that to be plausible anymore. I also experienced it once myself, months ago, when I entered my tn as 1234567890 and had it read back to me as 1122334455.

Can anyone give me some pointers where to start troubleshooting? Can overloading a system cause such an error?


Asterisk CDR On Call Transfer

I have searched for some time but I have not found an answer on how to fix the CDR when a call is transferred. The problem is that if someone dials a cell phone and then transfers the call to another extension the CDR for the cell call stops and there is no way to track that the call was transferred so we can bill correctly. Many people have asked this question but there is no answer, only a mention that it should be fixed in 1.6 which it is not (at least on

Any tips oh how to correct this problem? A lot of customers give me grief about this because they cannot properly bill people for their cell calls.


I am setting AGISIGHUP = no before running a Perl script via AGI but it doesn’t seem to be doing anything as the script is still exiting on a hangup and not completing properly. I am using Asterisk 1.4.35 and have tried various combinations. Can anyone shed any light on this?


Asterisk ACK BYE question

We’re running Asterisk for our campus voicemail server and Juniper M120s as our SBC. Unanswered calls, which arrive via the SBC, are diverted to voicemail using a 302 redirect when the called party doesn’t answer. In this case the caller is able to hear the greetings and begin to leave a message only to have Asterisk terminate the call mid-recording.

We’re uncertain why this is happening and this is where we are hoping you can help. In our environment the caller is any set on the PSTN. They call one of our IP phones which no one answers. Our proxy, SER, responds to the SBC with a 302 redirect and the call is diverted to Asterisk. The caller hears the unavailable greeting for 6-4050, begins to leave a message and is cut-off after about 10 seconds. In an ngrep trace we see Asterisk receive an ACK from the SBC and it immediately responds with a BYE message for that call.

Has anyone else experienced this type of issue?