OK… I’m going to post a rather long section from the 2.4.5 release notes that discusses this. The big item to check is to see if the “TrimDisconnectTonesOnRecordings” in the registry is set to “1”. If it’s not, set it, restart Unity and test to see if the problem is cleared.
If not, you can delve further into the tone template adjustments talked about here… It kind of hurts your head a little, but it’s not as complicated as it seems at first. There’s a lot of information you need to take into account so it’s rather long.
==========================================
Simply changing the value for "TrimDisconnectTonesOnRecordings" from "0" to "1" in the registry at HKLM>Software>ActiveVoice>Miu>1.0>Initialization should take care of this behavior. But depending on the disconnect tones defined in the switch .ini file, a little more tweaking may be required.
The amount of disconnect tone trimmed is determined by the [Switch Disconnect Tone] settings in the switch .ini file. If there is no [Switch Disconnect Tone] defined in the switch file, no trimming of either disconnect tone will be done on recorded messages. When Unity gets a disconnect event during recording from the voice board .tsp, there is no indication whether Switch or CO disconnect tone was detected. Therefore, in situations where the [Switch Disconnect Tone] is a cadence tone and the [CO Disconnect Tone] is a continuous tone, the Cycles= value in the [Switch Disconnect Tone] may need to be increased.
For example, if the disconnect tones in the switch .ini files are...
[Switch Disconnect Tone]
Frequency1=333
FrequencyDeviation1=21
Frequency2=462
FrequencyDeviation2=27
TimeOn1=250
TimeOnDeviation1=30
TimeOff1=250
TimeOffDeviation1=20
Cycles=3
[CO Disconnect Tone]
Frequency1=331
FrequencyDeviation1=25
Frequency2=454
FrequencyDeviation2=36
TimeOn1=4000
TimeOnDeviation1=0
TimeOff1=0
TimeOffDeviation1=0
Cycles=0
... we will trim the value defined for [Switch Disconnect Tone] which is Cycles=3 x (250msOn + 250msOff) = 1500ms. Since all continuous tones are defined as TimeOn1=4000, if we were to hear dialtone during a recording we would record 4 seconds of it before getting a disconnect. Then we would only trim 1500ms resulting in 2500ms of dialtone being present in the message. At sites where this becomes a problem, the Cycles= value in the [Switch Disconnect Tone] should be increased so that we are waiting to disconnect, and therefore trimming, approximately the same amount of time regardless of which tone is detected. In the example above, if we edit [Switch Disconnect Tone] to have Cycles=8, we would always trim Cycles=8 x (250msOn + 250msOff) = 4000ms so no matter which tone is detected, it takes us 4 seconds of recording to detect it and we trim 4 seconds of disconnect tone from the message.
Note: Cycles=0 must ALWAYS be the setting for a continuous tone!
…This is something else to look out for...If a continuous tone is defined as [Switch Disconnect Tone], we will not trim any disconnect tones from the message. Therefore, for sites where dialtone tones are present at the end of recordings, simply defining [Switch Disconnect Tone] as dialtone will not be sufficient. We will need to define dialtone as the [CO Disconnect Tone]. Also, we must define a cadence tone of reorder with Cycles=8 (preferably with broader deviations than the definition above) so that we will trim 4000ms off of the message, whether we get dialtone or reorder as a disconnect tone. (See explanation above)
This is expected behavior with our current implementation. If we only defined [Switch Disconnect Tone] as a continuous tone and did not define a [CO Disconnect Tone] and we did trim accordingly, we would trim 4000ms. But then if we disconnected on re-order it would be because of the DefaultCustom DiscTone1 that was not overwritten in TAPI config which has a default Repetition count (Cycles) of 4. Therefore, Dialogic would disconnect after 4 cycles of reorder tone (which is 2000ms) and we would trim 4000ms and chop off the last 2 seconds of the message. Our trimming intelligence is somewhat limited because there is no way for us to tell which tone Dialogic heard when they give us a disconnected call state.
Final note: If Unity does not need to rely on a disconnect tone (i.e. the switch always sends positive disconnect in the form of a loop current drop), "TrimDisconnectTonesOnRecordings” should definitely remain at the default setting of “0.” This is because of the same reason that we don’t know which tone was detected by Dialogic. Whether Dialogic detects [Switch Disconnect Tone], [CO Disconnect Tone] or a loop current drop, in all cases all Unity sees from TAPI is a disconnected linecallstate.
Therefore, if "TrimDisconnectTonesOnRecordings” is set to 1 and we disconnect from a loop current drop, there is no tone at the end of the message, but we will still trim it, resulting in the end of the message being chopped off.
Jeff Lindborg
Unity Product Architect
Active Voice
jlindborg@activevoice.com
http://members.home.net/jlindborg
