Recieve "goodbye.wav" message when dialing into trunk and into ivr. Look over my configuration

General Help
1

Hi everyone,

Busy tearing my hair out on this one. This is a new install and the phones are configured to dial out on the trunk and each other, which is no issue. My main problem is I want all incomming calls that come in on the trunk to a x100p card to enter into the main IVR. I want the caller to select either of the options to ring either extention. I have included a link of the freepbx snapshots of all the congigurations to eleminate any guess work between us. Also, will include cli output when a call is recived to show what it is doing.

Thanks

http://www.picupine.com/bbc17dfx-7 <–configuration

Verbosity is at least 8
– Starting simple switch on ‘DAHDI/1-1’
== Starting DAHDI/1-1 at telus-trunk,s,1 failed so falling back to exten ‘s’
== Starting DAHDI/1-1 at telus-trunk,s,1 still failed so falling back to context ‘default’
– Executing [s@default:1] Playback(“DAHDI/1-1”, “vm-goodbye”) in new stack
– <DAHDI/1-1> Playing ‘vm-goodbye.ulaw’ (language ‘en’)
– Executing [s@default:2] Macro(“DAHDI/1-1”, “hangupcall”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“DAHDI/1-1”, “1?skiprg”) in new stack
– Goto (macro-hangupcall,s,4)
– Executing [s@macro-hangupcall:4] GotoIf(“DAHDI/1-1”, “1?skipblkvm”) in new stack
– Goto (macro-hangupcall,s,7)
– Executing [s@macro-hangupcall:7] GotoIf(“DAHDI/1-1”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,9)
– Executing [s@macro-hangupcall:9] Hangup(“DAHDI/1-1”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 9) exited non-zero on ‘DAHDI/1-1’ in macro ‘hangupcall’
== Spawn extension (default, s, 2) exited non-zero on ‘DAHDI/1-1’
– Executing [h@default:1] Macro(“DAHDI/1-1”, “hangupcall,”) in new stack
– Executing [s@macro-hangupcall:1] GotoIf(“DAHDI/1-1”, “1?skiprg”) in new stack
– Goto (macro-hangupcall,s,4)
– Executing [s@macro-hangupcall:4] GotoIf(“DAHDI/1-1”, “1?skipblkvm”) in new stack
– Goto (macro-hangupcall,s,7)
– Executing [s@macro-hangupcall:7] GotoIf(“DAHDI/1-1”, “1?theend”) in new stack
– Goto (macro-hangupcall,s,9)
– Executing [s@macro-hangupcall:9] Hangup(“DAHDI/1-1”, “”) in new stack
== Spawn extension (macro-hangupcall, s, 9) exited non-zero on ‘DAHDI/1-1’ in macro ‘hangupcall’
== Spawn extension (default, h, 1) exited non-zero on ‘DAHDI/1-1’
– Hungup ‘DAHDI/1-1’

2

What I find a little odd

anyway, I made the corrected changes to BASIC > DAHDI from-pstn to from-dahdi and saved it.

Also, the freepbx system status was helpfull pointing to me of a orphan route “did not know what that was trying to describe” and looked in the inbound route section of the gui. I had a inbound ANd did AND CID in addition to my inbound route. Honestly, I thought that was something that was something built into freepbx. I opened it up, and there was no description in the description field. So deleting this orphan inbound route corrected my issue and now the pbx is working properly. I think in the near future, there should be some php code that checks to see if this field is left empty by accident “for new people like me” and forget about it.

Now, another question, is there a way to allow any callers who are confused “seniors including” that press the wrong option ie, 1 or 2 for either of our extentions, to be dumped into a general vm box?

In inbound call control > IVR, I have options 1 going to extention 200 and option 2 going to extention 201. If a person mistakly dials the wrong extention twice with the ivr message looping twice, can it dump the call into my extention 200 voicemail on the third try? Seniors seems to have a problem with extentions at times.

Thanks :wink:

3

lorel,

I’m pretty sure there is no issue wrt to writing the IVR contexts.

The IVR does have a tendency to create an ‘unnamed’ IVR if you navigate to it but if you go and create a proper IVR it gets created. The id associated with it auto-increments so if you delete an IVR and create a new one, it will continue to get a higher ID, it will not reused a lower number. (It will retain the same ID if you are just editing it though).

As far as you configuration routing calls, if you configure the dahdi configuration files to go to a specific context, that is where they will go, that part is not in direct control of FreePBX. You can use from-dahdi, from-zaptel or from-analog (they should all affectively work) if you are trying to route based on a channel where you assign a ‘fictitious DID’ to a channel so that you can then use normal inbound routes based on that ‘DID’ to route the call.

4

Seems IVR-3 does not exist! I see IVR-4 and IVR-5 which I did not create since there was only one custom made IVR that I created. I added one more from the IVR dropdown list so technically, there should be two IVR-? in the list.

Well, I took context [IVR-4] which is where the second IVR is located in extentions_additional.conf and switched it to [IVR-3] and heard the message stating which extention to press “in this case option 1” and it was routed to my polycom phone.

So, Seems there is a write issue bug going from freepbx 2.8.4.0 to the asterisk database in mysql but that is not my specialty. Perhaps some time, I can learn how to program in php and learn the mysql db “I can read mysql tables and contents” and fix this my self unless some one else cares to?

5

There seems to be a issue with the php amportal interface and the mysql db in a sence, that if I created a custom destination for my inbound pstn calls to be sent to the inbound start context it does not! It will only go to the from-pstn destination.

Now, I have setup the from-pstn in dahdi and the calls are being processed by the from-pstn context. A new issue arises when I deleted my old inbound IVR message and created a new one. I updated the IVR and Inbound routed to reflect the new IVR message that is stated in IVR option 1 for extention 200 and option 2 for extention 201.

I saved these settings and did a test run. Cli outputs this information when dialing in. It almost looks like the dialplan is looping. I did not hear the outgoing message:

– Starting simple switch on ‘DAHDI/1-1’
– Executing [s@from-pstn:1] Set(“DAHDI/1-1”, “__FROM_DID=s”) in new stack
– Executing [s@from-pstn:2] ExecIf(“DAHDI/1-1”, “0 ?Set(CALLERID(name)=604xxxxxxx)”) in new stack
– Executing [s@from-pstn:3] Set(“DAHDI/1-1”, “__CALLINGPRES_SV=allowed_not_screened”) in new stack
– Executing [s@from-pstn:4] Set(“DAHDI/1-1”, “CALLERPRES()=allowed_not_screened”) in new stack
– Executing [s@from-pstn:5] Goto(“DAHDI/1-1”, “ivr-3,s,1”) in new stack
– Goto (ivr-3,s,1)
– Hungup ‘DAHDI/1-1’
– Starting simple switch on ‘DAHDI/1-1’
– Executing [s@from-pstn:1] Set(“DAHDI/1-1”, “__FROM_DID=s”) in new stack
– Executing [s@from-pstn:2] ExecIf(“DAHDI/1-1”, “1 ?Set(CALLERID(name)=)”) in new stack
– Executing [s@from-pstn:3] Set(“DAHDI/1-1”, “__CALLINGPRES_SV=allowed_not_screened”) in new stack
– Executing [s@from-pstn:4] Set(“DAHDI/1-1”, “CALLERPRES()=allowed_not_screened”) in new stack
– Executing [s@from-pstn:5] Goto(“DAHDI/1-1”, “ivr-3,s,1”) in new stack
– Goto (ivr-3,s,1)
– Hungup ‘DAHDI/1-1’

6

looks like you don’t have not set a context in your dahdi configuration, should be from-zaptel usually or at least from-pstn.