Since switching to the latest VarAC, I've not been able to send VMAIL to a target station on a channel OTHER than the CF. If the target station does not respond to a QSY request, and the sender does not touch a key, there the sender is put back on the CF and nothing happens till a timeout occurs. Both stations are using the latest version.
If the sender requests a QSY, and the target does not reply, AND then the sender aborts, the VMAIL will be sent on the CF IF there is enough time remaining (less likely, with the time on the CF reduced to 4 minutes).
It USED to be that the sender could request a QSY, and the target station would QSY even when "AWAY', and the transfer could take place. This appears to no longer be the case.
If a "live" OP is required at both ends of the connection, for a VMAIL to be sent, then this (in my opinion) is a mistake, as it forces VMAIL back onto the CF.
I was not able to replicate this. Vmails going in and out with no problems. Here is the logics :
if you are connecting a person who is AWAY, and they enabled Auto QSY, then the VMAIL will not be forwarded on the CF until you invite him to QSY. once both stations QSYed (you manually and him - auto) the Vmail will be forwarded.
If you are connecting a person who is AWAY and they have NOT enabled the auto-QSY, then you can forward VMails on the CF.
If you are connecting a NON-AWAY station, then it means that both sides are available, and QSY is required for VMAIL trasnfer.
If one of those scenarios is not working - it will help to have a log (VarAC.log) as well as datastream log so I can see the AWAY/AWQ/QSY signals and vmail transfers of both sides...
Irad