A400E -- Problems with USA PSTN

Hi,

I'm configuring a A400E in USA, Miami, and I'm having a strange problem here.

Sometimes I try to call a number and it doesn't work, then I try again and it goes just fine.

I've the following configurations here:

zapata.conf

;
; Zapata telephony interface
;
; Configuration file

[trunkgroups]

[channels]

language=us
context=in-pstn
signalling=fxs_ks
rxwink=300 ; Atlas seems to use long (250ms) winks
;
; Whether or not to do distinctive ring detection on FXO lines
;
;usedistinctiveringdetection=yes

usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes
threewaycalling=yes
transfer=yes
cancallforward=yes
callreturn=yes
echocancel=yes
echocancelwhenbridged=no
echotraining=800
rxgain=0.0
txgain=0.0
group=0
callgroup=1
pickupgroup=1
immediate=no
busydetect=yes
busycount=8
;faxdetect=both
faxdetect=incoming
;faxdetect=outgoing
;faxdetect=no

;Include genzaptelconf configs
#include zapata-auto.conf

zapata-auto.conf

; Autogenerated by /usr/local/sbin/genzaptelconf -- do not hand edit
; Zaptel Channels Configurations (zapata.conf)
;
; This is not intended to be a complete zapata.conf. Rather, it is intended
; to be #include-d by /etc/zapata.conf that will include the global settings
;
callerid=asreceived
language=us

; Span 1: ZTDUMMY/1 "ZTDUMMY/1 1"

; Span 2: OPVXA1200/0 "OpenVox A1200P Board 1"
; ??: 2 OPVXA1200/0/1
signalling=fxs_ks
context=in-pstn
group=0
channel => 1
; ??: 3 OPVXA1200/0/2
signalling=fxs_ks
context=in-pstn
group=0
channel => 2
; ??: 4 OPVXA1200/0/3
signalling=fxs_ks
context=in-pstn
group=0
channel => 3
; ??: 5 OPVXA1200/0/4
signalling=fxo_ks
context=internal
group=1
channel => 4

Usually when I call from the FXS it goes OK... But when I use SIP it doesn't work. There is anything different about DTMF or stuff like that for USA configs?

I'm asking this because I'm using a A1200P at Chile that is working great! And two A100, in Brazil and Argentina, working just fine too...

At the begin, with this A400E, I had a problem when making calls, I checked at Digium's forum and people were talking about downgrade the zaptel version (was using 1.4.9.2, now using 1.4.7.1), I did that and now its working.. But still -- sometime goes fine, sometimes I've to try 2 or 3 times..

Well folks... that's all... If you need ANY other information, please let me know and I'll provide it asap!

Thank you! And congratulations for yours great products and support!!!

Regards!

hello, tdurante:
i think your setting should be no problem. it works as A400P. you do not need any extra steps for A400E. maybe the version of zaptel has some problems. i suggest that do not use too new version for that, unless you want to test some particular features in that version.
Regards,
James.zhu

Hi James,

I've downgrade already to zaptel 1.4.7.1 and I still having a lot of error when calling out. Actually I get the message of wrong number dialed, like if the card is dialing wrong or making some noise (can it happen?) that makes the like interprets the number wrong. REALLY STRANGE!

When I call by the FXS, usually, goes fine... That's what is killing me, because if works by the FXS should work fine by the SIP phones, right?

Have you guys ever seen such an error??

Tks a lot! =)

hello, Sir:
could you show the result of proc/interrupt and you logs?
James.zhu

Hi James,

Here is my interrupts:

root@us-miami-pbx:~# cat /proc/interrupts
CPU0 CPU1
0: 208 103 IO-APIC-edge timer
1: 1 1 IO-APIC-edge i8042
6: 2 1 IO-APIC-edge floppy
8: 2 1 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
16: 33909911 33911557 IO-APIC-fasteoi wctdm
17: 387251 387009 IO-APIC-fasteoi libata, libata
19: 273731 272350 IO-APIC-fasteoi eth0
NMI: 0 0
LOC: 805826 563007
ERR: 0
MIS: 0

And here a FULL log of three calls made by an SIP extension. The two first I got a "wrong number" from PSTN and just the 3th one worked.

[Mar 27 14:46] VERBOSE[3013] logger.c: -- Remote UNIX connection
[Mar 27 14:46] VERBOSE[3046] logger.c: -- Executing [018882378289@internal] Dial("SIP/46202-081f4d88", "ZAP/g0/18882378289||rTt") in new stack
[Mar 27 14:46] DEBUG[3046] dsp.c: dsp busy pattern set to 0,0
[Mar 27 14:46] DEBUG[3046] chan_zap.c: Dialing '18882378289'
[Mar 27 14:46] DEBUG[3046] chan_zap.c: Deferring dialing...
[Mar 27 14:46] VERBOSE[3046] logger.c: -- Called g0/18882378289
[Mar 27 14:47] DEBUG[3046] chan_zap.c: Engaged echo training on channel 1
[Mar 27 14:47] DEBUG[3046] chan_zap.c: Echo cancellation already on
[Mar 27 14:47] VERBOSE[3046] logger.c: -- Zap/1-1 answered SIP/46202-081f4d88
[Mar 27 14:47] VERBOSE[3046] logger.c: -- Hungup 'Zap/1-1'
[Mar 27 14:47] VERBOSE[3046] logger.c: == Spawn extension (internal, 018882378289, 1) exited non-zero on 'SIP/46202-081f4d88'
[Mar 27 14:47] VERBOSE[3070] logger.c: -- Executing [018882378289@internal] Dial("SIP/46202-081f3388", "ZAP/g0/18882378289||rTt") in new stack
[Mar 27 14:47] DEBUG[3070] dsp.c: dsp busy pattern set to 0,0
[Mar 27 14:47] DEBUG[3070] chan_zap.c: Dialing '18882378289'
[Mar 27 14:47] DEBUG[3070] chan_zap.c: Deferring dialing...
[Mar 27 14:47] VERBOSE[3070] logger.c: -- Called g0/18882378289
[Mar 27 14:47] DEBUG[3070] chan_zap.c: Engaged echo training on channel 2
[Mar 27 14:47] DEBUG[3070] chan_zap.c: Echo cancellation already on
[Mar 27 14:47] VERBOSE[3070] logger.c: -- Zap/2-1 answered SIP/46202-081f3388
[Mar 27 14:47] VERBOSE[3070] logger.c: -- Hungup 'Zap/2-1'
[Mar 27 14:47] VERBOSE[3070] logger.c: == Spawn extension (internal, 018882378289, 1) exited non-zero on 'SIP/46202-081f3388'
[Mar 27 14:47] VERBOSE[3071] logger.c: -- Executing [018882378289@internal] Dial("SIP/46202-081f4d88", "ZAP/g0/18882378289||rTt") in new stack
[Mar 27 14:47] DEBUG[3071] dsp.c: dsp busy pattern set to 0,0
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Dialing '18882378289'
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Deferring dialing...
[Mar 27 14:47] VERBOSE[3071] logger.c: -- Called g0/18882378289
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Ignore switch to REVERSED Polarity on channel 1, state 3
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Ignoring Polarity switch to IDLE on channel 1, state 3
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Polarity Reversal event occured - DEBUG 2: channel 1, state 3, pol= 0, aonp= 0, honp= 0, pdelay= 600, tv= -242166025
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Ignore switch to REVERSED Polarity on channel 1, state 3
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Ignoring Polarity switch to IDLE on channel 1, state 3
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Polarity Reversal event occured - DEBUG 2: channel 1, state 3, pol= 0, aonp= 0, honp= 0, pdelay= 600, tv= -242165833
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Engaged echo training on channel 1
[Mar 27 14:47] DEBUG[3071] chan_zap.c: Echo cancellation already on
[Mar 27 14:47] VERBOSE[3071] logger.c: -- Zap/1-1 answered SIP/46202-081f4d88
[Mar 27 14:47] VERBOSE[3071] logger.c: -- Hungup 'Zap/1-1'
[Mar 27 14:47] VERBOSE[3071] logger.c: == Spawn extension (internal, 018882378289, 1) exited non-zero on 'SIP/46202-081f4d88'


Anyway I opened an issue with AT&T yesterday and they're coming here today to see what is happening... Maybe it can be some noise in the lines, I don't know...

Thanks a lot!

Hi James,

AT&T guys came here 15 min ago. Tested all lines and said they are all right -- and they REALLY are.

Please, any tip?

Tks,