I'm currently configuring an opening greeting call handler to receive external calls, but on the call viewer I've checked that all calls that the ccm send to the unity are defined as internals. On the admin guide it appears that internal calls are from untiy subscribers, but in this case all calls (including that came from the
pstn) appears as internals. There is a configuration missed?
All calls coming in from CM will be considered "internal" - CM doesn't have a designation for external.
Unity uses the forwarding number/calling number to determine if a call is internal (i.e. if the forwarding number is the extension of a known subscriber we consider it internal for purposes of playing the internal greeting for call handlers and subscribers).
This isn't done by routing rules using internal and external designation.
By default the routing rules should already be setup to do this. The "attempt sign in" conversation that's in the list of direct call rule looks up the calling number and if it's a subscriber they are automatically signed into their mailbox, not routed to the opening greeting.
If you're subscribers are calling in directly and still getting the opening greeting then the routing rules have been changed or the calling number we're getting isn't matching up to a subscriber in our database.
- External calls are directed to an opening greeting and then managed by call handlers
- Internal calls access direct their message box
The problem is that on Unity ALL calls are treated as Internal calls, even if the calling number is not a Unity's subscriber. In our office's installation works this way, external calls go the opening greeting and internals to the message boxs. I've no access to that servers, that's a pity...
again, Unity can do just exactly what you want here and it doesn't matter what the origin of the call is (internal vs. external) - that does not bear on this functionality at all.
If the calling number reported to Unity on a direct call matches a subscriber we will log them into their mailbox automatically. It does not matter if the call is reported as internal or external (Call manager ALWAYS reports ALL calls as internal) - this will still work.
So if this isn't working on your system we either aren't getting the correct calling number or someone has fiddled with the routing rules and fouled things up.
I had similar issues, but wasn't able to assign a DID to the VoiceMail ports on CM. So I created a CTI point and assigned FWA to the unity ports, then built a routing rule for forwarded calls but which specified the called DN of the CTI point. This solved our problen and didn't effect the normal subscriber log in.
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...