IVR Not Answering

Wondering in anyone might be able to help me out. I’m trying to help out a friend who had a system put in by an installer who seems to have disappeared on them. Recently all of their phones stopped working and after some digging I was able to find that somehow all the passwords for the phones had been changed in the system. Updated that and they phones register now and are able to make outbound calls. Inbound calls however were set to go to the IVR, but when you place an inbound call it just keeps ringing. I checked the settings and verified the IVR is still setup and the .wav file is still there, but can’t seem to figure out the call issue. Here’s an example of an inbound call:

=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2014.01.20 23:30:00 =~=~=~=~=~=~=~=~=~=~=~=
localhostCLI> localhostCLI> localhostCLI> localhostCLI>
– Starting simple switch on ‘DAHDI/1-1’

localhost*CLI>
– Executing [s@from-pstn:1] ExecIf(“DAHDI/1-1”, “1?Set(__FROM_DID=s)”) in new stack

localhost*CLI>
– Executing [s@from-pstn:2] Gosub(“DAHDI/1-1”, “app-blacklist-check,s,1()”) in new stack

localhost*CLI>
– Executing [s@app-blacklist-check:1] GotoIf(“DAHDI/1-1”, “0?blacklisted”) in new stack

localhost*CLI>
– Executing [s@app-blacklist-check:2] Set(“DAHDI/1-1”, “CALLED_BLACKLIST=1”) in new stack

localhost*CLI>
– Executing [s@app-blacklist-check:3] Return(“DAHDI/1-1”, “”) in new stack

localhost*CLI>
– Executing [s@from-pstn:3] Set(“DAHDI/1-1”, “CDR(did)=s”) in new stack

localhost*CLI>
– Executing [s@from-pstn:4] ExecIf(“DAHDI/1-1”, “0 ?Set(CALLERID(name)=9991216312)”) in new stack

localhost*CLI>
– Executing [s@from-pstn:5] Set(“DAHDI/1-1”, “__CALLINGPRES_SV=allowed_not_screened”) in new stack

localhost*CLI>
– Executing [s@from-pstn:6] Set(“DAHDI/1-1”, “CALLERPRES()=allowed_not_screened”) in new stack

localhost*CLI>
– Executing [s@from-pstn:7] Goto(“DAHDI/1-1”, “app-blackhole,busy,1”) in new stack

localhost*CLI>
– Goto (app-blackhole,busy,1)

localhost*CLI>
– Executing [busy@app-blackhole:1] NoOp(“DAHDI/1-1”, “Blackhole Dest: Busy”) in new stack

localhost*CLI>
– Executing [busy@app-blackhole:2] Busy(“DAHDI/1-1”, “20”) in new stack

localhost*CLI>
[2014-01-20 23:30:20] WARNING[2317][C-00000004]: sig_analog.c:3105 __analog_handle_event: Ring/Off-hook in strange state 7 on channel 1

localhost*CLI>
== Spawn extension (app-blackhole, busy, 2) exited non-zero on ‘DAHDI/1-1’

localhost*CLI>
– Hanging up on ‘DAHDI/1-1’
– Hungup ‘DAHDI/1-1’

localhost*CLI>
– Starting simple switch on ‘DAHDI/1-1’

localhost*CLI>
– Executing [s@from-pstn:1] ExecIf(“DAHDI/1-1”, “1?Set(__FROM_DID=s)”) in new stack

localhost*CLI>
– Executing [s@from-pstn:2] Gosub(“DAHDI/1-1”, “app-blacklist-check,s,1()”) in new stack

localhost*CLI>
– Executing [s@app-blacklist-check:1] GotoIf(“DAHDI/1-1”, “0?blacklisted”) in new stack

localhost*CLI>
– Executing [s@app-blacklist-check:2] Set(“DAHDI/1-1”, “CALLED_BLACKLIST=1”) in new stack

localhost*CLI>
– Executing [s@app-blacklist-check:3] Return(“DAHDI/1-1”, “”) in new stack
– Executing [s@from-pstn:3] Set(“DAHDI/1-1”, “CDR(did)=s”) in new stack
– Executing [s@from-pstn:4] ExecIf(“DAHDI/1-1”, “1 ?Set(CALLERID(name)=)”) in new stack
– Executing [s@from-pstn:5] Set(“DAHDI/1-1”, “__CALLINGPRES_SV=allowed_not_screened”) in new stack
– Executing [s@from-pstn:6] Set(“DAHDI/1-1”, “CALLERPRES()=allowed_not_screened”) in new stack
– Executing [s@from-pstn:7] Goto(“DAHDI/1-1”, “app-blackhole,busy,1”) in new stack
– Goto (app-blackhole,busy,1)
– Executing [busy@app-blackhole:1] NoOp(“DAHDI/1-1”, “Blackhole Dest: Busy”) in new stack
– Executing [busy@app-blackhole:2] Busy(“DAHDI/1-1”, “20”) in new stack
== Spawn extension (app-blackhole, busy, 2) exited non-zero on ‘DAHDI/1-1’

localhost*CLI>
– Hanging up on ‘DAHDI/1-1’
– Hungup ‘DAHDI/1-1’

localhostCLI> localhostCLI> localhostCLI> localhostCLI> eixilocalhost*CLI>
No such command ‘exi’ (type ‘core show help exi’ for other possible commands)

localhost*CLI> exitAsterisk cleanly ending (0).
Executing last minute cleanups
[root@localhost ~]# exit
logout
[admin@localhost ~]$ exit
logout

Check your inbound routes. Make sure they aren’t messed up too.

BF

You might also want to check your blacklist in the database

database show blacklist

Ok thanks. Will try to poke around and see if I can find these 2 things. They are using pots lines if it makes any difference.

Not to speak ill or anyone, but when something like this happens and the installer “disappears”, you have to wonder if there is a connection. In any case, make sure the admin passwords are changed.

Thanks. Changing passwords was the 2nd thing I did after I figured out how to reset an account to get admin access.

Just thought I’d post cause it seems I was able to figure out the issue. For some reason the default catch all inbound route was set to Terminate/Busy for the destination. Odd since it was working and no one was authorized to change that. Changed it to IVR and the correct greeting and verified call connected. And I correct the SIP settings that were set to static ip even though they have a dhcp and had a host address instead of a network.

Looks as though the other installer left some contact info on some menu’s so I’ll have my friend get in touch w/ them to sort that part out. Thanks for all the help.