In both ShoreTel Release 8 and 9 there is a very interesting behavior that will ultimately bring a client call to your support center.   The behavior is most obvious in a multi-site deployment in which there is only one HQ server providing voice mail services.    A call to a user at a remote site is RNA (i.e. ring no answer) transferred to the voice mail system.   The call entered the system on a PRI at the remote site and is then transferred across an MPLS WAN to the HQ server.   The caller hears the greeting: “I am not here, at the beep please leave a message”.   The caller dutifully waits for the “beep”, but it never comes.  What happens to it? The fact of the matter is the “beep” was in fact played, but the caller did not hear it.   This has to do with the use of the G729 Codec on Inter site calls in this scenario.   The G729 is distorted to the point that the caller can not hear the beep.   The distortion appears to only be related to the implementation of the G.729 codec on the virtual soft switch.  As a troubleshooting step, I used a different phone system and an IP phone that was set to only use G.729.  When we called the HQ virtual soft switch over a local PRI trunk where ULAW was being used from the PRI switch to the HQ server, we heard the voicemail beep without distortion (through the G.729 codec as implemented on a different PBX).  It is only distorted when the virtual soft switch is trying to do G.729. Outlined below are two WAV files of the normal beep (ULAW) and the distorted beep (Softswitch G.729).  We have also attached a visual representation of the audio files.  The distortion is audibly and visibly clear.  Our thinking is the "beep" is to short and to high a frequency, but we are not developers!  Currently, the only known fix for this is to change the Codec to G711.  That fixes the issue, but it may have a negative impact on your WAN plan!  I am sure there is a fix in the works back at the ShoreTel Mother ship, but we have not seen it yet.