Outbound trunk prompt causes issues with some calls

TL;DR

Likely problem: If I’ve Answered an outbound call before sending the call to the trunk, does Asterisk still send a dialtone or does the call have some kind of anomaly? If so, how do I fix it?

The issue

After making changes to my configuration (described below), some outbound calls result in issues like no ringing tone or error messages. One such call resulted in the following audio message:

We are sorry, we have not received any touchtone digit. You may be waiting too long before dialing, or your phone may be set to pulse instead of tone. Please try again.

Changes apparently causing the issue

I’ve implemented a prompt on every outbound call to the trunk which asks the caller to choose which DID number to call with. To be able to do that, I have to Answer() the channel (as you can see here, at line 262) to perform the prompt before doing the outbound call to the trunk (as you can see here, at line 352).

From the error audio message I mentioned earlier, I suppose the changes I made cause my PBX to no longer send a dialtone, or something like that. I suppose that is why some calls result in issues. So how do I ask Asterisk to do a proper call?

I don’t know what you mean by “send a dialtone”. Asterisk doesn’t send a dialtone; dialtones don’t exist per-say in VoIP and are largely just generated by your devices.

I looked over what you’re doing and I mostly understand it…I will have to sit down and actually follow all your sub routines. I can understand having to answer to prompt the user for input…but that should only happen if you have to prompt the user. It seems if you have a single DID configured; then you don’t need to propt the user and should just pass the call back. Is it situations with a single DID causing the problem? As it is it will always execute that second answer. I’ve never misconfigured that to happen myself so I have no clue what impact that might have.

That’s just what I noticed to start off with. I have to sit down later and follow the dialplan and all the sub-routines to determine where the problem might be.

Asterisk does not send dial tone for SIP calls, except, possibly, if there is no user part in the request URI, which would be unusual for an outbound call, as it is not easy to set up on SIP phones.

In a correctly configured SIP system, any dial tone is generated, locally, by the phone, before it has actually started the call.

(I had to look quite deep to be sure this was SIP.)

I think your voice message is coming from downstream of Asterisk, and I suspect you will find that there is something wrong with the dialled digits in Dial call, when you look at the logs.

Asterisk can play a dial tone, but it’s not clear from your config what would be doing so - I don’t see Read, DISA, BackGround, DialTone, or any of the like applications that would generally do that. Please explain where that comes in.

Additionally, a CLI trace with verbose at least 4 would be useful if asking folks (or even yourself) trying to debug the issue.

It almost sounds like something is timing out, but that’s a bit odd when answered vs. unanswered.

I also don’t understand why you have:

; Answer() in case we skipped because of having a single DID configured.
same => n(answer2),Answer()

You should never answer a call manually unless you have a specific, valid reason to do so, and I’m not sure I see the reason here. It’s also redundant since Playback will (annoyingly) auto-answer without the noanswer option.

He’d need early media support on the phone (which he might well have) to do his current interaction flow without answering. On the other hand, he could make the caller ID selection be controlled by prefix digits on the dialled number, which I suspect is what most people would do. (The reference to DIDs I found a bit confusing; he wants to select any of his possibly incoming numbers as caller IDs on outgoing calls.)

I think he is either confusing dial and ring back tone, or the dial tone is coming from downstream, although that seems strange, as I wouldn’t expect voip.ms to interface with the PSTN anywhere that would generate dial tone. That is something that is normally only done in local exchanges, with analogue, or channel associated signalling.

@dewdude

I don’t know what you mean by “send a dialtone”.

Maybe I’m not using the right words. All I know is that I’ve noticed that, since I added my “prompt which DID to call with” feature, somehow I have a number of calls to “real” phone numbers that either 1) do not result in me hearing the ringing tone and which often just hang up after a while, or 2) in particular case, caused the error message I mentioned in the OP.

To be fair, I haven’t actually checked whether using my old configuration fixes the issue or not. I suppose I should have tried calling one of the problematic numbers with my old configuration (that doesn’t have the DID prompt) before asking this question. I’ll try in a few days, with a verbose asterisk log like @InterLinked suggested (duh, I should have thought about that).

I will have to sit down and actually follow all your sub routines.

Let me explain what the prompt is to help you do that. I want my config to be kind of plug and play, so with my current (apparently problematic) config you just initially specify which DIDs you have when installing my configuration, and then you would not have to remember any particular “digit prefix to DID” sort of thing since on every outbound call the dialplan just looks at the smallest prefix of the DIDs that allows disabiguating between them and tells the caller what the possible prefixes are. E.g., with DIDs “123-456-7890” and “129-876-5430”, the smallest prefixes is “123” and “129”, so the Read() prompt would be: “Please specify which number to call with: 123 or 129”.

Is it situations with a single DID causing the problem?

No, basically my config supports having a single DID (in which case yes, I want to skip the prompt) but I myself use three, do get the prompt, but still have the issues I described with some phone numbers.

@david551

He’d need early media support on the phone (which he might well have) to do his current interaction flow without answering.

I’ll have a look at what that is and whether it could help me select the DID to call with while avoiding my current problems.

On the other hand, he could make the caller ID selection be controlled by prefix digits on the dialled number, which I suspect is what most people would do.

Yeah, I thought about doing that initially, but I decided to use a voice prompt instead because that would be easier to use with several DID numbers. As I explained to dewdude above, I want my config to be kind of plug and play, so with my current (apparently problematic) config you just initially specify which DIDs you have when installing my configuration, and then you would not have to remember any particular “digit prefix to DID” sort of thing since on every outbound call the dialplan just looks at the smallest prefix of the DIDs that allows disabiguating between them and tells the caller what the possible prefixes are.

Whether or not this choice was best is debatable I suppose, but either way it doesn’t explain my issue.

@InterLinked

Asterisk can play a dial tone, but it’s not clear from your config what would be doing so - I don’t see Read, DISA, BackGround, DialTone, or any of the like applications that would generally do that. Please explain where that comes in.

Basically what I said to dewdude: I just felt from the one error audio message that that was the problem. I’ll try this out again in a few days, probably comparing a verbose log using my old config with a verbose log using my new config. By the way, my dialplay does invoke Read() here, right after Answer().

I also don’t understand why you have:

; Answer() in case we skipped because of having a single DID configured.
same => n(answer2),Answer()

Basically this subroutine has two cases: 1) If the configuration has a single DID, then we skip the prompt asking which DID to call with (as you can see at line 254)) Otherwise, we Answer() and perform the prompt. I called Answer() here merely because I wanted both cases to make me end up in the same scenario: the channel has been Answer()ed and we know which DID we will call with. I didn’t want to have to handle both cases separately other than skipping the prompt.