We had another developer write our asterisk application and we’re currently trying to figure out why we aren’t hearing the operator intercepts on calls to bad numbers.
We’re currently running 1.8.5 and when an agent attempts an outbound call to a bad number, the system just hangs up without any notice to them. When the agent calls the outbound line and connects to our application, we ask them for the 10 digit number to dial. Once we get it, we attempt the call. On success, we move both channels into a meetme conference room.
Is there a way to open up the audio on the dial out to the second leg so that in case of a busy or a non working number, they can hear this? Or will we have to write our own catches for each types of error code returned from the 2nd leg?
Is there somewhere else I can post that I would get an answer?
In my opinion, I’ll choose your second statement. Handle the response an then bridge the answer to the client, as the same way that you bridge the successful call.
If your trunk receive a busy signal bridge and play a busy message, if the trunk receive invalid bridge and play invalid message and so on.
Thanks for the reply. So we should play our own custom error messages? We started doing that but we unable to get the status codes for the failed call. Every time we attempt to look at the dialstatus or hangupcause, we get back just blank and 0 respectively. I tried to do the hash(sip_cause) piece but we also get a blank on that. I know this is hard not seeing code but if we are getting this data back, could we be looking at a different channel or is it normal for a failed call to move to a different channel (thereby removing all the status codes due to being on a new channel).
Try invoking the Progress() application before making the outbound call; you may have in-band tones, rather than proper call progress indications and, at least in some cases, explicit calls to Progress are needed.
Note that early media, like this is unlikely to work if the caller is coming in over the PSTN, or any other chargeable route.
Otherwise, you are going to have to provide dialplan, etc., before we can debug why you are getting bad values for dialstatus and hangup cause. Note the latter will not be empty, because it is really a function that reads a numeric fieild in the channel data structure, and which, therefore, always has some value.