From the Networking Guide description of Cross-Server Logon, I gather that this feature will only work for calls from outside of the CallManager network (PSTN). In my scenario we are using Digital Networking on two Unity 4.05 servers. Each has it's own Pilot Number in a VM Profile assigned to phones. Users can use the live reply feature, subscribers on either Unity server can be accessed using Auto Attendant. I have configured the *xxxx pattern to perform direct transfers into scubscribers VM boxes. I have two patterns in unique partitions for each server. I was trying to use the Cross-Server Logon feature to allow this direct transfer to VM to work for subscribers on either server, but instead I get the default greeting. I assume the Attempt Sign-In on direct calls is what makes Cross-Server Logon work. Can I just create another call routing rule for Forwareded Calls that uses Sign-In to do the same, or is Sign-In different from Attempt Sign-In? Is there a method to make this feature work for this desired function or another way to make it work?
We are using Digital Networking between 3 Unity servers 4.0(5). There are several settings in the Unity SA that you will need, make sure you have the following checked under Dialing Domain for each server:
- Cross-server logon: Subscribers dial the same number to log on to Cisco Unity
- Transfer Options - Cross-server transfer: Pass control to the called subscriber's Cisco Unity server
- Optional, but recommended: Prompt Option for Cross-Server Logon, Transfer, and Live Reply Play prompt during cross-server logon, transfer, and live reply so that callers know something is happening
In the Dial String on each Unity server, you want the pilot number for the other server. It our case we use the 5-digit pilot number; 3 rings; 5000 ms. timeout. We are using 5-digit dialing. It works for external calls using the 7-digit number and internal calls using the 5-digit number. We are not doing anything with call routing rules or CallManager dialing patterns. The caller hears the Unity Opening Greeting and presses the # key to invoke the Signin conversation. From there the subscriber enters his or her 5-digit extension. Unity transfers the subscriber to the home Unity server, where the person hears the prompt for password.
I have all of your suggested settings in place on both servers. The scenario you have given works just fine. I can dial either Unity server from the inside or the outside, press the * key which corresponds to sign-in, and Unity sends the call to the appropriate server for sign-in. What I have done and am trying to make work is a direct transfer into VM form the inside. By creating a VM profile with wildcards and a related route point, you can dial *xxxx (a vm box) directly from a phone and be sent into the persons VM box, without waiting on the phone to ring and the FNA timer to kick in. This works also. What I am trying to do here is take this direct transfer one step further. There is a VM Profile and a route point for each Unity server with it's own *xxxx pattern. What I would like to have happen is if a user dials *1234 and it is not associated with their home Unity server, have the cross-server logon kick in and send the call to the other Unity server. Cross-server logon may not be what I need, as I am not looking for someone to logon to an account, but rather be transfered directly into the vm box of the other Unity server.
This could be solved easily if your subscribers are distrubuted uniformily between the two Unity servers according to DN. For example, suppose Unity1 has subscribers with DNs 1000-1999 and Unity2 has subscribers with DNs 2000-2999. Then you'd simply split up the *xxxx route point into two route points, *1xxx and *2xxx, each pointing to the appropriate Unity server. Of course this only works well with well defined extension ranges between the two Unities. The more scrambled your DNs are, the more route points you'll need and this can quickly become unmanagable.
I did consider this option, but as you state there is a mix of existing extensions between the sites that would result in a large number of route points. If I can't come up with something more "Digital Networking" related, this may be my only choice.
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...
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 discusses the bas...