Customer has NEC 2400 with a new Unity 3.1 3.1(2). They have T-1 interface cards to the voice mail. When they set the handler to BLIND transfer, there is a high likelihood that the port will lock up. To correct this, Cisco recommended changing to a SUPERVISED transfer. Now, when the call is transfered from the UNITY, and the intended destination answers, they have 2 or more seconds of dead air before the calls are actually connected.<br><br>Is there a way to have UNITY release the call after a set number of rings?<br><br><br>
The basic problem is that the consulting portion of the transfer (in Dialogic-land) takes a bit long to detect that someone has answered.
The type of T1 this is using just emulates FXS loop start signalling (typical analog stuff), so it really doesn't surprise me that this is happening. Is this happening when transferring to an internal extension (an extension on the same switch as the Unity ports), or to an external extension or number? Or both?
Let's say the "rings to wait" setting for the transfer in the Unity SA is set to 6. Does the connection of the parties speed up if the person waits 3-4 rings to answer the phone (as opposed to answering immediately after hearing their phone ring)?
"Is there a way to have UNITY release the call after a set number of rings?"
Not really. You can fake it by placing a couple of commas in the SA behind the extension to transfer to (which makes a few seconds of a pause), but then you're back into the release transfer situation you were recommended to get out of.
There maybe some tweaking that can be done, we'll just have to see.
The situation is happening on both internal transfers and external transfers to extensions inside the dialing network of the customer.
No, changing the ring count does not speed up the delay. The SUPERVISED transfer ring count is already set at 6 since the PBX handles the FORWARD No Answer timing.
We changed the Main answering handler and a few other transfer out mailboxes to "RELEASE to SWITCH" and added several commas after the dialed number. We went from 2 locked up ports to 11 in the space of a day.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...