Strange issue with incoming calls over PSTN

We’ve had an asterisk server running for years now, without any issues. It has a TDM400P card with four 3 incoming PSTN lines connected. Channel 1 is used for incoming calls, and Channels 2 and 3 are reserved for outbound calls in case internet is down (otherwise we use Flowroute for outbound calls)

For a few days now, we’ve had a strange issue. Calls made from Verizon cell phones into Asterisk on the landline numbers get disconnected after 1 ring (caller hears a “beep”, then dead). Calls placed using T-Mobile, Sprint etc work just fine.

At around the same time, the callerid stopped working. Now all phones display “asterisk” instead of the callerid number. Not sure if these two issues are related.

From zapata.conf:

; ------------------------------------------------------
; set up 1 line to be exclusively for incoming calls and the rest for outgoing calls

; outbound lines (channels 2, 3 on zaptel card)

context=incoming
signalling=fxs_ks
language=en
rxwink=800
usecallerid=yes

;callerid=asreceived
;cidsignalling=bell
;cidstart=ring
;sendcalleridafter=1
;cid_rxgain=0
;busydetect=no
;callprogress=no

echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
rxgain=12.0
txgain=0.0
musiconhold=default
callid => “xxxxxxxxx”
group=1
channel => 2-3

; incoming line (channel 1 on zaptel card)

context=incoming
signalling=fxs_ks
language=en
rxwink=800
usecallerid=yes

;callerid=asreceived
;cidsignalling=bell
;cidstart=ring
;sendcalleridafter=1
;cid_rxgain=0
;busydetect=no
;callprogress=no

echocancel=yes
echocancelwhenbridged=yes
echotraining=yes
rxgain=12.0
txgain=0.0
musiconhold=default
group=2
channel => 1

Output when a call is placed:

Jul 14 22:11:29 WARNING1089: chan_dahdi.c:7352 ss_thread: CallerID returned with error on channel ‘Zap/1-1’
— Executing s@incoming:1 Wait(“Zap/1-1”, “0”) in new stack
— Executing s@incoming:2 Answer(“Zap/1-1”, “”) in new stack
— Executing s@incoming:3 Set(“Zap/1-1”, “TIMEOUT(digit)=5”) in new stack
— Digit timeout set to 5
— Executing s@incoming:4 Set(“Zap/1-1”, “TIMEOUT(response)=10”) in new stack
— Response timeout set to 10
— Executing s@incoming:5 BackGround(“Zap/1-1”, “greeting-short”) in new stack
— <Zap/1-1> Playing ‘everest-greeting-short’ (language ‘en’)
— Executing s@incoming:6 BackGround(“Zap/1-1”, “more-sounds/to-dial-by-name-press”) in new stack
— <Zap/1-1> Playing ‘more-sounds/to-dial-by-name-press’ (language ‘en’)
— Executing s@incoming:7 Playback(“Zap/1-1”, “digits/4”) in new stack
— <Zap/1-1> Playing ‘digits/4’ (language ‘en’)
— Executing s@incoming:8 Playback(“Zap/1-1”, “digits/1”) in new stack
— <Zap/1-1> Playing ‘digits/1’ (language ‘en’)
— Executing s@incoming:9 Playback(“Zap/1-1”, “digits/1”) in new stack
— <Zap/1-1> Playing ‘digits/1’ (language ‘en’)
— Executing s@incoming:10 WaitExten(“Zap/1-1”, “”) in new stack
— Timeout on Zap/1-1, going to ‘t’
— Executing t@incoming:1 Playback(“Zap/1-1”, “more-sounds/im-sorry”) in new stack
— <Zap/1-1> Playing ‘more-sounds/im-sorry’ (language ‘en’)
— Executing t@incoming:2 Playback(“Zap/1-1”, “more-sounds/pls-try-again”) in new stack
— <Zap/1-1> Playing ‘more-sounds/pls-try-again’ (language ‘en’)
— Executing t@incoming:3 Playback(“Zap/1-1”, “vm-goodbye”) in new stack
— <Zap/1-1> Playing ‘vm-goodbye’ (language ‘en’)
— Executing t@incoming:4 Hangup(“Zap/1-1”, “”) in new stack
== Spawn extension (incoming, t, 4) exited non-zero on ‘Zap/1-1’
— Hungup ‘Zap/1-1’

Note that the log keeps going even after the call is disconnected right after the first ring. It’s as if the hangup is not detected by Asterisk.

All incoming calls from non-Verizon phones seem to be working just fine. This seems to have started occurring recently and we have not changed any Asterisk configurations for a long time now.

I should add that we have a hunt-group set up for the 3 PSTN lines.

Any help would be greatly appreciated.

Remove the line from the card and connect an analog phone. Make the same tests. It seems that there is a problem with the providers configuration. The analog card is a dumb interface, it cannot recognize from where the call is coming (Verizon or T-Mobile) so if the card or your config was bad it wouldn’t work for all calls and not some…