Missing Part: Route Pattern + FAC + IVR App on CUE??

[daniel.ferianzzi]

Hi guys,

Please, I need some light here... hehe

I´m working on a migration from a Siemens PBX to a CUCM 7.1 solution and I need to address some points from the "older world" to the "new world".

The biggest issue is related with the long distance and international calls, because the users are accostumed to dial a huge string to get the external dial-tone. Here is an example:

4 + AAAA + 6 + BBBBBBBBBBB + XXXXXXXXXXXXX

AAAA = User personal code (known as FAC)

BBBBBBBBBBB = Client Code (known as CMC, but this will need to be validated with an external SQL database)

XXXXXXXXXXXXX = Destination phone number

Because we will need to validate the Client Code with an external SQL DB, we had the idea to create an IVR application stored in a Unity Express server, and for that I´ve created the CTI route point and ports.

To address the need for FAC, I´ve created a Route Pattern like this:

"4."

GW: <gw where the CUE lives>

Called Transformation Mask: 9100 (IVR Pilot)

On the gateway, I´ve created a voip dial-peer pointing to the destination 9100, returning to the CUCM to be routed to the CTI Route Point that connects to the IVR application. So the call comes into the gateway throught the Route Pattern, and when it matches 9100 it has to return to the CUCM.

This is the dial-peer:

dial-peer voice 9100 voip

description IVR DialCode

destination-pattern 9100

voice-class codec 100

voice-class h323 100

session target ipv4:10.20.0.5

incoming called-number .

dtmf-relay h245-alphanumeric

no vad

From my phone, when I call "4", I get the FAC prompt, then I enter my 4 digits, the translation runs OK, but I get an busy tone from 9100.

I entered the "debug voice ccapi inout" comand in the gateway and the call is getting there, but nothing appears to happen.

Again from my phone, when I call "9100" directlly I get the IVR application prompts, I enter the sequence 6 + BBBBBBBBBBB + XXXXXXXXXXXXX and the call is completed successfully.

My problem is the "bridge" between the Route Pattern and the CTI Route Point.

I´m sorry for this HUGE topic...

Please, if any of you already tried to do something similar to this or have an idea for what is missing, please, let me know.

Thanks for your patience and for your responses.

If you need further information, let me know.

Rgds,

Daniel Ferianzzi Andriolo

[Aaron Harrison]

Hi

It sounds like you are having 'fun'.

First point would be that typically on a CCM (not CME) install with CUE; you would register the CUE module to the CCM directly via CTI Route Points and CTI Ports. From your description of how it works when you dial 9100, you have a call sent to the GW, then it routes BACK to CCM via the dial-peer you listed and gets to 9100.

So to send a call to CUE; you would not create a route pattern and send it to the GW that contains the CUE; you would create a translation pattern for '4' and set the called party mask to the CTI Route Point number. No dial-peer on the GW, no route pattern.

So unless the GW is doing something else which isn't clear from your post, you don't need to send the call to the GW at all.

Regards

Aaron

[daniel.ferianzzi]

Hi Aaron,

Thanks for your reply.

The reason why I´ve created a route pattern with "4" pointing to the GW is because I need to identify the users with the FAC feature.

Inside this route pattern I have done some tests usind the Called Party Transformation Mask, one time using the 9100 directly + dial-peer 9100 on the gateway pointing back to CCM.

The other test I´ve done is to transform the called number to another number (i.e: 9999), point to GW, create a dial-peer 9999 and point back to CCM, but this time use a Translation Pattern to transform 9999 to 9100 and gets routed throught CTI Route Point.

This didn´t work too...

I think that my problem is with this "loop" between CCM and GW.

I even thought that this would require the CUBE feature on my GW, but I´m not sure if it should work too...

Just to inform you, this is the image running on my GW: c2800nm-adventerprisek9_ivs-mz.124-24.T3.bin

This image already have this CUBE (a.k.a. IPIPGW) feature...

If we get at a point that this should not work EVER, then I´ll need to think in another option (i.e: Create an external DB to authenticate FAC).

But this is my last option... I want to make this work!! heheheh

Thanks again...

Rgds!

Daniel Ferianzzi Andriolo

[daniel.ferianzzi]

Hi Again...

Just another important information...

The digits entered by the users when dialing need to be inserted in the CDR file for billing...

Any ideas, please let me know!

Thanks!

Rgds,

Daniel Ferianzzi Andriolo

[daniel.ferianzzi]

Hi Guys...

I have found what was missing!!

I´ve forgot to configure the h323 interworking inside the voice service voip and I didn´t have setup the h323 voip interface...

So the call was comming from the CCM throught h323, the gateway accepts this call, but when the gateway starts the other leg to return the call to the CCM, it can´t identify what interface it should use. That´s what the h323 voip interface have fixed...

Thanks Aaron for your help...

See you later.

Rgds,

Daniel Ferianzzi Andriolo