CSS and Partitions

[j.huizinga]

Hi,

Here is something:

The CSS from a gateway contains a PAR that has a RP with DN 600

This points to an IVR

Within the IVR you have the option dial the extension.

There is also a phone with extension 600, but this PAR is only in the CSS from the RP.

When I configure this it causes problems because I can not connect to phone with DN 600.

When I include the phone PAR in the CSS of the gateway I connect again to the RP.

How does this cascading from CSS work?

It seems that the final PAR has to be included in the CSS from the gateway.

Is this how it must work?

Thanks,

JH

[Jaime Valencia]

The final CSS from a device is line CSS + device CSS.

If a partition is in both CSSs, it's added from the line CSS.

In your case since there is overlapping that means that if you have both partitions (in same CSS line/device or different CSS doesn't matter) you will only ever reach the 600 DN from the partition that is in first place when the final CSS clause is constructed.

ie

CSS=par1:par2

and both partitions have a 600 DN then that means that you will ever only reach DN 600 in par1.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[j.huizinga]

Thanks Java for your reply.

In this case where there is a CSS on a gateway and a CSS on a Route-point and a CSS on a translation pattern, how is the final CSS contructed?

And the call flow is from gateway -> RP -> Translation Pattern -> DN

Thanks,

Jan

[Jaime Valencia]

At each part of the call you use the CSS for that call leg, inbound CSS from GW to CTI RP, then CTI RP I assume you have a CFA or something like that, so you use the CSS for CFA  based on the config for it or whatever you have.

Once you reach the TP it will also use whatever CSS you have configured there.

There is no final CSS for that call flow, each call leg creates the CSS as configured in each device.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[j.huizinga]

So I have phones in partition PHONES

I have RP in partition ROUTE-POINT (also the CTI ports)

The CSS from the gateway contains only the partition ROUTE-POINT

The CSS from the RP contains the partion PHONES (and the CSS from the CTI ports)

Inside the IVR I can enter an extension, and extension is in partition PHONES.

Will this call be successfull? So can their be a connection between GW and phone?

Thanks,

Jan

[nitsinha]

The CSS from the gateway contains only the partition ROUTE-POINT>>>> This is fine. The gateway can reach the RP.

I dont understand why a translation pattern is being used in the call flow.

If the call reaches the IVR and the person dials in the number, the call comes in to the CUCM via the CTI ports. Hence make sure the CTI ports CSS have access to the end user phone's partition.

Hope that helps

Regards

Nitesh

PS:Please rate helpful posts

[j.huizinga]

Hello Nitesh,

OK let me tell the complete story.

I am using CUE for IVR, and I have two independent IVR's for two departments in one script.

On CM I have crreated two dummy directory numbers with a CFA to the RP.

In the script I am using LastRedirectredNumber to check which IVR to use.

Inside the script there are transfers to hunt pilots (press 1, 2, 3 etc) or extensions.

The partition from the hunt pilots are not in the CSS from the gateway but in the CSS from the route-point / CTI ports.

This has worked for months.

Then customer calls me one time and says that they have problems with IVR. I call the main number and indeed, I don't hear anything. After some checking I see some CTI ports unregistred and I decide to do a reload of the ISM module.

After reloading I make a test and I hear the welcome prompt, so I say to customer all is OK.

Customer calls me 20 minutes later and says that the press 1,2,3 don't work, they go back to the main prompt.

I checked it and indeed, these options don't go to the broadcast line group, but hit back to the main prompt.

I solved it by including the Hunt-Pilot partitions in the CSS from the gateway.

I can not transfer to an extension that has the same DN as the dummy DN, I could transfer before.

The dummy DN is visible from  gateway CSS and the phone DN is vissible from RP CSS.

Dummy DN and phone DN have the same number.

Now I am a week later, tried almost everything (reboot CM, gateway, ISM module) but still I have this problem.

So I wanted to be sure how these CSS from gateway/route points work together (if they work together)

Maybe the ISM module is defect?

Thanks,

Jan

[nitsinha]

Ok. So it works like this.

1. Inbound call is made to the dummy DN. Since the incoming Gateway's CSS has the dummy DN's partition, call succeeds.

2. The dummy DN has access to the RP in its Call Forwarding CSS. Hence call to RP succeeds.

3. The route point sends the call to the IVR through the CTI ports. IVR plays the prompt.

4. Now when user dials 1,2,3 for transfer to hunt pilots, the call comes into CUCM via the CTI ports and hence now it is the CTI ports CSS which should have access to the partition containing the hunt pilot numbers. I believe this wasnt there and when you added the partition to the CSS, it worked. I believe the incoming gateway and the CTI ports have the same CSS because you say that "I solved it by including the Hunt-Pilot partitions in the CSS from the gateway"

5. So now i believe the only issue that you are facing is the call transfer to a user phone from inside the IVR script. Correct? If i got it right, the i think i know why the problem is occuring. Since you have the same CSS applied to the incoming gateway and the CTI ports and since that CSS has access to the dummy DN(say 6000) which is also the end user phone number, hence when other callers dial 6000 from inside the IVR script, the CTI port sends the call with called number=6000 to the CUCM. Since now the CTI port's CSS has 6000 as the dummy DN as well as the end user phone,(and i believe the dummy DN is on top in its CSS), hence the call to the DN which shares the same no. as the dummy DN never succeeds.

If so, assign the CTI port a CSS which has access to partition containing all the hunt pilot numbers and the end user extension only. It should not have access to the dummy DN.

Let me know how it goes.

HTH

Regards

Nitesh

PS:Pl rate helpful posts

[j.huizinga]

Hello Nitesh,

Original the CSS from the gateway had access to the dummy and phone  and CTI ports/RP partitions.

So in the CSS from the gateway was not the partitions from the hunt pilots.

The dummy DN was before the phone partition so in case 6000 came inside the gateway, the dummy DN was selected.

I needed the phone partition in the gateway CSS for DID.

The Route point CSS has only the phone, hunt-pilot and CTI ports/RP partitions, no dummy DN.

So when in the IVR you would select option 1 the call would connect to a hunt-pilot.

When you selected extension 6000 it would connect to the phone, because the CSS from the route-point did not have the dummy DN partition.

All this was working for at least 5 months.

Then one day it stopped working, no changes of configuration were made, and it started with a complete not functioning of the IVR. The provider sended a message to the caller that the "number does not exist" After a reload of the ISM module it seemed to work, but I faced problems that I still have till now.

When I put the partition from the hunt-pilot (which was only in the route-point CSS) in the gateway CSS, the option 1,2,3 (connection to hunt-pilot) started to work again.

But I can not connect to extension 6000 because I connect to the IVR again.

When I do a debug (reactive script) form the CUE, I can see that when I enter a non-existing extension, the "call-redirect step" hits the invalid branch and I send it back to the main prompt. When I enter 6000 the successful branch is hit.

I configured an IP communicator with the same CSS as the gateway and I can see that when I enter a non-existing extension I stay in the program (CTI-port does not change)

When I enter 6000 I can see that I reconnect to the IVR using a different CTI port. I can not explain this since the CSS from the route-point and CTI ports do not have any reference to the dummy DN (which has a CFA to the RP from the IVR)

I have to find out why this happening because this customer will have multiple remote sites with multiple IVR systems.

Next week I am going to open a TAC case,

Thank you for your support,

Jan