SOLVED Raspivo: Inbound calls continue to ring after Answer.

[TKtech]

I have a functional Raspivo 16.05 install on a RasPi 2. Under standard configuration, based on the guide from Ward, I can receive incoming calls and forward them to an end device/user. Everything works beautifully! The issue is, when I try to add an IVR (I first tried to play it by ear, then followed the guide in the XiVO docs) the inbound call is never answered. The dialplan continues to execute as if everything is ok.

A few things I notice:
- If I try to use the "s" extension, the dialplan exits with a loop detection. I think XiVO or Asterisk overwrites or adds a new "s" extension. I have seen where it does this for other contexts that do not have one... but I'm not sure of this. I therefore use "same" instead.
- I have gotten the system to forward a call to an IVR extension by using a round about method. Instead of using the "Destination: Customized, Command: Goto" settings in the incoming calls section, which bypass a lot of XiVO's Gosub stuff, I did... something else (sorry I don't remember) that allowed the call to route through the XiVO gauntlet before getting passed to the IVR context. This worked as expected.

Something I'm just now thinking of is, perhaps the dialplan is reaching the Answer app too soon?
Logs, configs, screenshots on request.
@Sylvain Boily, just tagging you should something you should know about come up.

EDIT: Tried to insert a Wait() before answer, no change.

 

[TKtech]

Solved but not solved. I have to Answer() MULTIPLE TIMES! This can't be the best solution, but it does work...
I forgot to mention I am using Google Voice... in case that affects anything.

EDIT: ... this seems to be hit or miss as well. *throws hands in the air*

 

[TKtech]

OK... So it seems like if you Answer([delay]), where [delay] is any larger than 1700 ms, the inbound call will continue to ring. I have a feeling this has to do with GV, but I'm not sure. The issue is, is that I needed to delay longer than this for the audio channel to fully establish itself before playing audio, otherwise the beginning gets cut off. If the inbound call doesn't get audio within this <2 second window, it will continue to ring, so no combo of Answer()/Wait() will suffice... So I just play 1-2 seconds of silence while everything stabilizes. This is probably an obvious solution but hey...