I have a customer who is currently running Call Manager VoIP solution. They have another vendor handling their IPCC implementation and they are planning to deploy IPCC to remote locations.
Our problem showed up when we took all of the Agent Lines, Route Points, and CTI Ports and initially created them all in their own partition, allowing them access to the gateways where their calls/DN's would ring in from. The gateways live in a generic partition where all of the first lines of a nonagent phone reside, with appropriate translation patterns to get the incoming DN's to the IPCC partition to allow the IPCC to route appropriately.
Our intent was to restrict general users from directly dialing the Agent extensions but what actually happened was that inbound calls from the gateway rang fast busy, even though we allowed the translation of the DN to be routed we could not get an external call to a queues DN to ring into a queue, internal worked just fine from phones with the same CSS and partition.
We received a tip from an IPCC guy that we needed to have the gateway, route points, ports and agent lines, all in the same partition, so we moved all of them into that generic partition, and the problem of dialing externally went away, obviously.
Now we are in a similar scenario of deploying another site off the same cluster which has its own set of partitions, but will use the IPCC resources homed at the site local to the cluster.
This seems to me to duplicate the config problem we ran into the first time around. Where points, ports, gateways and agent lines are not in the same partition.
Does anyone have a clear understanding of the restrictions/requirements of IPCC from a Callmanager standpoint? I have read through all the IPCC docs I could locate on CCO and all are great at defining what needs to be configured from an IPCC standpoint, but nothing addresses partition/Calling Search Space issues.
Also, there is no document that I could locate that gives any clear description of how call processing works between CCM and ICM/IPIVR/IPCC. It was told to us by the IPCC vendor that our initial problem was caused because there was no "return path" to complete the call setup, and that doesn't makes sense to me since we were not restricting Gateway to IPCC calls.
We verified EVERYTHING. We even created a phone in the same partition/CSS as the gateway to verify that the phone would operate properly. It is not a partition/CSS issue. The gateway has in its CSS all the partitions available to that site. The points, ports, and agent lines all had a CSS which gave them access to the gateway, and the non-agent devices. The non-agent devices only had access to the gateways and other non-agent devices/lines.
Checked, double checked and triple checked.
Also, we had the situation where the phone in the gateway partition/CSS COULD dial into the queue, but the external caller, coming in DID through the gateway, could not via THE SAME translation parrtern that the phone used.
Therein lies the dilemma, if the phone can, why can't the gateway, when other DID calls ring in just fine. When we translated that particular DID number to another line (non-IPCC) it rang in just fine.
It IS something to do with IPCC and partitioning/translations, but like I said, my knowledge of call processing on IPCC is expanding, but still limited.
ok, what versions of Call Manager, IVR and ICM are you using and what type of gateway are you using
When you use translation patterns you force the call processing to do digit analysis a second time after it has matched a translation pattern.
Another thing to check is are the calls coming into the gateway from the public network or are they coming in as VoIP calls ?? If they are VoIP calls check the codec you are using, the IVR only supports G.711
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...