I set up an AA service for a client where a call comes into a PRI, hits a CTI RP which has CFwAll to the VM pilots. This part works just fine and a custom greeting is played. Users are able to dial to any extension on CUCM if they want to while the greeting is being played.
The customer also has a CME that provides basic telephony services to a set of users (extensions 8xx). These users do need outgoing PSTN connectivity, but they would like to be able to receive calls from callers who hit the AA. These callers should be able to dial the extensions of the CME users when they hit the AA greeting.
I read some previous posts that said I need to do the following to achieve this:
1) Create a contact and check the box titled: "Transfer extension" and enter the extension to which the call should be transferred. I created a test contact with extension 314. In CUCM, this extension 314 has CFwAll set to an 8xx extension. The reason for this is that they do not have a PRI with 8xx DIDs, so I have configured certain 3xx DIDs to forward all calls to 8xx extensions.
2) Under the AA standard greeting, check the box titled: "Allow Transfers to Numbers Not Associated with Users or Call Handlers." I checked this box.
3) Under restriction tables, uncheck "Blocked" next to "*" and any other patter that may match the extension to which the call needs to be transferred. I unchecked this box and added a new rule at the top of the list with the following pattern: "314" (exact match for testing purposes).
Whenever I try to enter "314" at the greeting menu, there is a slight pause and the following message is played "You cannot be transferred to this number. Check the number and try again."
As a side note, extension 314 does not have a partition assigned to it, so it should be accessible by the VM ports. Also, they're using SCCP integration and are running CUCM 9.x and Unity Connection 9.x
Is there something I am missing here? Any help would be greatly appreciated!
Thanks for your response. The CME is added to CUCM as a H.323 gateway and a route pattern for 8xx exists in CUCM. As a matter of fact, if calls come in on the 3xx DID, the CallFwdAll function forwards the call to 867, matches the 8xx extension and further sends the call to CME perfectly. Therefore the forwarding function between CUCM and CME is working fine. I suspect CUC is not able to send the calls out to CUCM for just the users with extensions that do not have a mailbox associated with them because it seems to work for all other users with extensions that do have mailboxes associated with them.
Thanks for your response, Anirudh. I did modify the "Default System Transfer" table and just to be on the safe side, I modified all other tables in a similar fashion except for the "Fax" table. I added exact matches at the top of the table for both, the original extension as well as the translated extension (314 and 867) and yet, I receive the same error message for both.
I was able to resolve the problem with a quick fix and I hope this helps someone else out there. It turns out that the CME was considering calls from Unity Connection as toll fraud. Therefore, I simply had to define Unity Connection as a trusted source by entering the following commands on CME:
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...