Delaying the first voice prompt (Callback or DISA)

General Help
1

— Scenario

We are using both callback and DISA features. We use password and, in some instances, “confirm” options. These options result in a voice prompt being issued. Most typically, the call topology is cell user -> pstn/vsp gateway -> broadband -> asterisk/freepbx. The hardware is a P-IV 1.8GHz supporting 8 light-duty users. The broadband is 10Mbps down/1Mbps up. The VOIP (SIP trunk) jitter measured at 1 ms or less. Call quality is otherwise excellent.

— Problem

The user is not hearing the first word of the voice prompt (e.g. the actual voice prompt is “Please enter your PIN” and the user hears “…enter your PIN.” This is most likely to occur with cell phone users, but isn’t confined to them.

— Question

Is there a way to delay the start of the voice prompt at the call’s establishment (just by like a one second or so)?

Thanks,
/Scott

2

I have the same issue. Sometimes the talk path is not cut through in time to hear all the prompt. I have the worst issue with a cell phone. We need a 1 second delay after answer before the prompt begins. This may require a bug report.

3

This being only my second post into these forums, if it is a “bug report” case, how would one do that appropriately and correctly.

Thanks,
/S

4

On the left hand side, Select development, report a bug.

5

Whenever I’ve had a problem like that, I’ve simply left a short period of silence at the beginning of the message…

Bill/W5WAF

6

But it’s a canned system message.
/S

7

You can try having the caller directed to an announcement playing the system recordings silence/4 (adjust to your needs) and then being transferred over to disa (by setting it in the destination)

8

On which prompts do you need a second of silence? I’ll be glad to edit them to add it and then email to you.

Bill/W5WAF

9

x

10

I’m not sure it’s a bug. It really depends who you’re calling. Rather than a bug, maybe a feature request to allow you to put in some silence before an announcement starts. But thinking about it…that might not work either…if the external service uses voice detection (VOX) to open up a path. …

BF

11

Ok, Moshe! this appears to be a viable work around.

— DISA & CALLBACK

From SYSTEM RECORDINGS > BUILT-IN RECORDINGS, I added silence/1 to my available recordings list. I then made an ANNOUNCEMENT of silence/1 and set its destination to the DISA. And then set the INBOUND ROUTE’s destination to be the ANNOUNCEMENT pointing to the DISA.

Preliminary testing shows that, where the DISA (and callback>disa) voice prompt is actually “Please enter your password,” the cell user now consistently hears “please enter your password” (and not “…enter your password,” as before)."

— FOLLOWME > CONFIRM CALLS

Perhaps I haven’t thought through this new info enough, but, at first blush, I don’t see how the “announcement” approach can be adapted to the FollowMe > Confirm Calls use scenario. The user hears a redacted Confirm Calls voice prompt.

— EXTEN =>

It would seem to me, but then I know not enough to know for sure, that an appropriately placed exten => …,n,sleep/pause, …, if there is one, would seem cleaner.

Thanks Moshe, and everyone
/S

12

Im glad it worked for you. Im not sure that putting in a wait is a good idea as not everyone wants/needs it. The way you did it is much more modular as it allows every to customize things for there own needs

13

Thanks, Bill.

The brain cells have been stimulated and I’m beginning to see into these approaches. It’s within my know-how to make a compound recording silence/1+pls_enter_password from the two available system recordings, and then use the compound recording. I just didn’t see it before.

Again, thanks.
/S

14

Actually, in this eight user facility, “everyone wants/needs” it. On a bigger site/facility you’re absolutely right on the modularity/customization efficacy of your excellent work around. On this box and this user community, one well placed exten => wait (or its like) would be okay too.

Again, thanks Moshe.