DTMF recognition is acting goofy. The problem exists is the subscribers account conversation. DTMF always works fine when you have to enter your id and password, the issue is during playback of voicemail, Unity can not pick up DTMF tones over the voicemail playback. Basically once you are authenticated DTMF no longer works.
Unity 4.03. CM is 3.3.2. The gateway is a 3745 running MGCP.
It only happens with external calls - and cell phones at that. Before you murder me for failing to realize it is bad cell quality (might still be that) - here are more details:
1) From the same cell phone I can call Octel and have no problems with DTMF
2) As stated previously, entering in Mailbox # and password works fine every time from cell phones. If it were bad cell quality these tones would be goofed up too.
3) It happens consistently from cell phones. It's not like it works once in a while and doesn't other times.
4) During playback, I can press "3" and it skips up and "1" and it skips back. But "33" to go to the end and "11" to go to the beginning don't work. But, it's not just double digits alone - again if I enter mailbox number 4419... no problem. Only during play back does it get goofed.
Since it is obvious that it works in general, and its only from cell phones that it fails, and only during message playback, I am wondering if there is something that I can do to maybe "relax" the DTMF tone requirements in Unity. Dunno. Any help would be cool.
In this case Unity does not do any digit detection at all. That is handled by the gateway and digits are then passed as descrete events to Unity. You can use the Port Status Monitor tool from Unity's Tool Depot to see what digits arrive at Unity. If you're entirely missing some keypresses then you'll need to look toward the gateway to figure out why the digits are not being relayed.
Now, the double keypress is a different story. For Unity to treat "33" as a double keypress the digits arrive within a specific time of each other. For Unity 4.0(3) that time is 900ms. Some cell phone providers send "long" DTMF tones (~600ms) and that together will slow keypresses could prevent Unity from getting the digits within 900ms of each other. A couple things to try... First, cell phones/providers often let users choose between short or long DTMF. Try having your users select short whenever possible. Next, the double digit time within Unity can be bumped up through the Advanced Settings Tool (again in Tool's Depot). Some folks have reported good behavior at 1025ms. I recommend not pushing beyond that however as it may cause the Unity conversation to appear slower while Unity waits for that second digit.
Ok. This is getting a little frustrating. We have been playing around the with the double keypress timings. Still having issues with certain cell phones. Take my sprint phone for example. If I go to settings, and change my DTMF Tones to short I can hit "33" to forward to the end of a message every time. If I change it to Long, "33" does not take me to the end. We have changed the double keypress timing from 250 - 1000 ms with the same results. Any thoughts?
Well, this probably doesn't have anything to do with Unity at this point - we're only acting on digits we're being told about.
Either the phone service itself is sending the tones further than 1 second apart (really kinda doubt that) or something is getting lost in the translation along the way to us.
You can verify if Unity is even getting the 2nd digit at all by turning on the "MIU General" trace #14 "Digit Generation/Detection" and then reproducing the problem. Go to the commserver\logs directory and open the most recent "diag_AvCsMgr_xxx" file and find your call - go to the part of the conversation where you hit "33" and pull the time stamps off them - if you only see a single 3 then that's all we're getting and the problem is up stream from Unity. If you see two 3's but they're farther apart than the inter digit timeout then we will treat them as seperate digit events instead of a single "jump to the end" event as you want.
If you _do_ see two 3's and they _are_ close enough to be considered a double key event, then there's a problem on our side of the fence we'll need to take a look at.
We have had this same issue since we installed Unity. Octel, always works.. does not matter which cell phone you use. With all things equal, I could call Octel with a suspect cell phone and everythig worked. When I called Unity, double key presses failed consistantly. We have adjusted the double key press time and "most" cell phones now work. Unfortunatly "most" isn't a good answer. If anyone has resolved this please let me know.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...