Card payment machines fails multiple times then connects

Just looking for some advice and possible areas to look at in regards to a number of card payment units on site failing mutliple times to take payment and then eventually doing so.

I am running the following setup not from a distribution the unit sits between an existing PBX and an ISDN trunk,

FreePBX: 2.11.0
Asterisk: 11.8.1
Dahdi: 2.9.10
Centos: 6.5

etc/dahdi/system.conf
span=1,0,0,CCS,HDB3,CRC4
span=2,0,0,CCS,HDB3,CRC4
bchan=1-15,17-31,32-46,48-62
dchan=16,47

I am using a Digium TE220 set for Europe.

/etc/modprobe.d/dahdi.conf
options wct4xxp default_linemode=e1

/etc/asterisk/chan_dahdi.conf
[channels]
language=en
busydetect=no
busycount=10
usecallerid=yes
callwaiting=no
usecallingpres=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=no
echocancelwhenbridged=no
echotraining=0
immediate=no
faxdetect=no
rxgain=0.0
txgain=0.0
switchtype=euroisdn
callerid=asreceived
hidecallerid=no
cidsignalling=v23
cidstart=polarity
overlapdial=yes
prilocaldialplan=unknown
pridialplan=unknown
nationalprefix=0
internationalprefix=00
rxwink=300
callgroup=1
callwaitingcallerid=yes
canpark=yes
context=default
group=1
mohinterpret=passthrough
pickupgroup=1
relaxdtmf=yes

I turned on debug and recorded the following.

http://pastebin.com/9qvedxEK

You might want to set your TON’s (prefixes for TypeOfNumber) in your chan_dahdi.conf and it’s includes, I notice

[2014-10-03 17:05:48] VERBOSE[15131] chan_dahdi.c: PRI Span: 1 > Called Party Number (len=14) [ Ext: 1 TON: Unknown Number Type (0) NPI: Unknown Number Plan (0) ‘08003855201’ ]

For Europe it is often something like:-

internationalprefix = 00
nationalprefix = 0

Also many PRI carriers will reject calls where the calling party is “7006” as you are apparently using, so maybe add also something like where 0711 is your local area code and 345 is your local “exchange”

localprefix = 0711
privateprefix = 0711345

Hey dicko, thanks for coming back to me I will test and let you know.

Unfortunately we are still not able to place the payments. I can see from the below that the call is connected however if then hangs up with out authorising. I have call recording on the unit, listening to the call back it appears that the payment center receives the call send out a response but then the PDQ our side does not respond. I guess that it is struggling to receive the response back in a form it can use. Is there any settings that could effect this?

http://pastebin.com/EhYgMty4

Have been talking on an IRC asterisk channel. It is believed that a change to a broadband codec might help, I have installed the Asterisk SIP settings and am going to try changes. Will let you know how I get on.

I’m pretty sure that won’t do you any good, you made a 20 second connection using “SPEECH” to 08003680754:-

[2014-10-07 17:31:00] VERBOSE[28299][C-000003ae] sig_pri.c: – Requested transfer capability: 0x00 - SPEECH
[2014-10-07 17:31:00] VERBOSE[28299][C-000003ae] app_dial.c: – Called DAHDI/G0/08003680754
[2014-10-07 17:31:00] VERBOSE[28299][C-000003ae] app_dial.c: – DAHDI/i1/08003680754-3b1 is proceeding passing it to DAHDI/i2/7006-3af
[2014-10-07 17:31:02] VERBOSE[28299][C-000003ae] app_dial.c: – DAHDI/i1/08003680754-3b1 is ringing
[2014-10-07 17:31:02] VERBOSE[28299][C-000003ae] app_dial.c: – DAHDI/i1/08003680754-3b1 is making progress passing it to DAHDI/i2/7006-3af
[2014-10-07 17:31:02] VERBOSE[28299][C-000003ae] app_dial.c: – DAHDI/i1/08003680754-3b1 answered DAHDI/i2/7006-3af
[2014-10-07 17:31:23] VERBOSE[28299][C-000003ae] pbx.c: – Executing [h@macro-dialout-trunk:1] Macro(“DAHDI/i2/7006-3af”,

The connection by definition MUST use g711 ALaw, that’s how ISDN works, there are no broadband codecs available, The I in ISDN supports the possibility that maybe your device is X21 ( I doubt it) and your original post suggests you are “In-Line” between a PBX and a TDM trunk, there is thus a possibility that your PBX is “non-compliant” and you might need to add some tweaks from

http://doxygen.asterisk.org/trunk/chan_dahdi.conf.html

to get the B channel working early enough to be useful. You can use dahdi_monitor, recording into separate TX and RX files to see that audio is flowing both ways.

You could turn on intense pri debugging to see what happens between 17:31:02 and 17:31:23 but I think your problem lies at a higher level while your Card Reader negotiates with it’s mother-ship, there are no diagnostics in libpri or dahdi to help you there.

You say little about what the Card Reader is , how it is connected and what protocol it uses if it is over SIP then anything but G711 Alaw will make things worse, if on TDM (dahdi) then as I say it’s not Asterisk/FreePBX, call your vendor.

I know about “modem” type devices and “network” type devices, but the last type does not need a voice channel.

Point taken with the codec it was not the right way to go. I have just been made aware of further back story. This unit replaced an existing system performing the same function running asterisk 1.8.15.0, dahdi 2.6.1 in which their PDQ’s worked successfully.

I am not aware of the protocol used by the PDQ’s or their manufactures however we have an engineer on route to the site with the previous build to carry out testing who maybe able to shed some light on this.

We are going to get the engineer to test the previous build and confirm if the PDQs work, this should confirm that the setup is as previous.

It may then be a case of compare and contrast the two setups, hardware is the same for both units.

Hi Diko.

Think we have resolved the issue now. However two changes were made so am not 100% which resolved.

I noticed at the 11th hour that SPAN1 which is connected to the telco was not configured to receive timing.

dahdi.conf

FROM

span=1,0,0,CCS,HDB3,CRC4

TO

span=1,1,0,CCS,HDB3,CRC4

Before enabling the engineer also receive a complaint regarding echo on the line so the following was undertaken

dahdi.conf

ADDED

echocanceller=mg2,1-15,17-31,32-46,48-62

chan_dahdi.conf

FROM

echocancel=no

TO

echocancel=yes

The PDQs now appear to be working everytime with out issue. We are going to observe for a couple of days and see how things continue.

Yes, you need solid timing for ISDN (or any TDM circuit) , I apologize for missing that earlier, but be careful with echo cancellation on modem calls it will usually be deleterious, I would first off check your TX/RX gains on the span for balance BEFORE enabling echo cancellation, you can do that with dahdi_monitor and milliwatt tests of which there are numerous howtos out there (IMHO, if you still need EC for your voice calls then OSLEC is a better algorithm), such efforts can only improve your users experience and your modem devices performance.