Cisco Support Community
Community Member

Dialtone Stored with Voice Messages

Using a Calista integration and Dialogic PCI boards with Nortel Option 11s (Releases 20, 21 and 25.15), 4 to 6 seconds of dial tone is recorded with each voice message left by a telephone caller (vs. composed within Outlook). What tone/disconnect recognition problem do we have and how do we correct?<br><br>


Re: Dialtone Stored with Voice Messages

Have you run "Learn Tones" on this system? It should pick up dialtone as a disconnect tone and it should tighten things up.

If you've run that already and it's still giving you fits, we'll need to call in and see what's going on. There are some parameters we can adjust for trimming off the end of messages to accomodate this if need be, but tightening up the tone definitions is the right way to solve this problem.

Jeff Lindborg
Unity Product Architect
Active Voice


Re: Dialtone Stored with Voice Messages

Thanks Jeff. Yes, we have run learn tones. As this problem seems to exist only on the Option 11, am suspecting that it may be a disconnect supervision issue with the small switch. I moved the entire integration to an Option 61 and the problem is not present. Do you have other active installations on the Option 11?


Re: Dialtone Stored with Voice Messages

We are having this same issue with an Option 61. We were told 2.4 would fix. Did not happen. We have run lean tones, this has not helped either ...

Just an FYI - Everyone has just gotten used to the dial tone in the message.


Re: Dialtone Stored with Voice Messages

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]

[CO Disconnect Tone]

... 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

CreatePlease to create content