IPCC cannot route calls to external number (answering service)

Unanswered Question
Sep 24th, 2010

Hi there -

Our environment:

IPCC Enterprise - Rls. 7.5

CUCM - Rls 7.1.3

CUC - Rls 7.1.3

Connectivity to the PSTN is through our Nortel PBX using 2 QSIG PRI

We an application that is using a DID number routed via the Nortel to the CUCM and then CVP (CTI route point in CUCM).  The application is working right and the callers are able to flow through all options and get routed to agents as expected.  We have a menu selection to leave a voice mail which is working (translation pattern on CUCM is working and calls end up in the correct mailbox).  We have a request to route calls during stat holidays to an answering service as follows:

Call would come into IPCC but the application is closed.

IPCC routes call to CUCM -- 105918002345678

Translation pattern in CUCM -- 105#10591[2-9]XX[2-9]XXXXXX

When we set the application to be a holiday date (closed) we see that the application is dialing the 1800 number but the caller hears a busy signal

Not sure how to trouble shoot this.  I can see that the call is not trying the PRI to the PSTN and there is no activity.  My guess is that something needs to be configured in IPCC to allow this to happen that was not set up during the installation as this was not in scope.  The Call Manager looks right and so does the voice gateway.

Any guidance would be most helpful.



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)

So you return a label on the CVP routing client of "105918002345678" ?

You have a SIP proxy static route or a H.323 gatekeeper config to send that to a CUCM subscriber?

Then Call Manager takes over. This should work, and does work under "normal" CVP deployments. You hairpin, of course.

Also possible in "normal" CVP deployments is you use the "DTMF" label and return to the gateway (not CUCM) and outpulse the digits - useful if you have take back and transfer from the carrier. No hairpin.

In your case, calls come into a Nortel switch, and then via line side QSIG trunks to a voice gateway, then to the CUCM. That's a route point which does a CUCM generated call to find CVP. Why do you do it that way? Can't you go into CVP directly? Are there limitations on the support of QSIG trunks in CVP?

Why can't you do this in your Nortel switch and stay away from the QSIG trunks, CVP etc?



Les Pruden Mon, 09/27/2010 - 13:49

Hi Geoff -

QSIG uses MGCP at the gateway so when a call comes into the gateway it is routed to the Call Manager directly (using H.323 you would have a dial peer that sends the call to CVP).  You are right that QSIG has limitiations.  We are doing it this way because the Call Manager does not yet have any PSTN trunks.  Calls come into the Nortel and then to CUCM using QSIG PRI (not line side) to route point to CVP.

I did get this to work however I'm not sure what the difference is between this CUCM configuration and another CUCM installation that we have in Indiana.  Here the CUCM has to have a translation pattern of --> 10591[2-9]XX[2-9]XXXXXX  <-- and in Indiana the translation pattern is

--> 110#11091[2-9]XX[2-9]XXXXXX  <--  so for some reason we do not need to add the 105# at this site.  It might be a QSIG thing and the way that CUCM passes the call back through the gateway - not sure.

Appreciate your input.  Solved this with a lot of trial and error.

Of course - soon we will be installing PSTN trunks on this cluster so we will have to start our testing all over again - good times!




This Discussion