We already did this but it doesnt work when you have IPCC Agents. When a Call comes in to The Gateway which have in his CSS the Partition of the CTI Route Point the call goes to the CTI RP and then through the IPCC script but it doesnt ring the Agent Phone (which Partition is not included in the CSS of the Gateway). As soon as i put the Partition of the Phone on the Gateway it works!!!. Someone told me it maybe because the CTI-RP uses the CSS of the Gateway when using IPCC (not sure if this is really what is causing this issue). This is why we used the Translation Pattern solution but then we got the problem above.

Any other solution?

You need to modify the IPCC Call Searching Space, with IPCC Enterprise this could be done by accessing the registry and modifying some registry keys(open a TAC case if you need help on how to do that), on the IPCC Express side, that is indeed not possible.

It s IPCC Enterprise 6.0. Would be great if you can tell me how to do this.

Thanks

The point is to segregate the PSTN translation patterns from everyone else. You can duplicate the same CSS you have now on the gateways, and then add the translation partition.

@lfulgenzi

i dont understand exactly what you mean. you mean on the Gateway there should be 2 CSS one where only Translation pattern are and the other CSS for the rest? would that work with the IPCC problem i described above?

A calling search space is a combination of partitions. If your users are hitting the 3 digit translation patterns that you want for the PSTN to access, it is because those translations are in a partition that your users can access. The only way around this is to seperate those three digit translation patterns into a different partition that is not included in the css of your regular users.

Create another CSS for your gateway, and inlude all the partitions it needs to complete the calls, i.e. partitions with CTI route points and port, agents, etc PLUS the partition with the three digit translation patterns.

You also have to make sure that the calling search space assigned to the translation patterns is correct as well, but I think it is, because it works already.

You have to seperate this problem into the IPCC enterprise portion (of which I can't help) and the partition/css part, of which the above should help.

@lfulgenzi

I think you didnt understand the problem im facing with the Translation Pattern, maybe i didnt explain it very well:

Lets say a caller Calls 0-xxx-xxx-5540

the gateway forward this number to the Callmanager which will do the Following:

TR_Pattern 540 -> 5540 DN then rings the DN 5540 (For Example a Manager Extension).

Now the Problem: let s say i have another Manager which have a DN 5554, so i create the Following Translation Pattern:

TR_Pattern 554 -> 5554 DN

Now the Same Call 0-xxx-xxx-5540 to the gateway-> Callmanager then do the Following this time:

TR_Pattern 540 -> [554]0 DN->TR_Pattern 554-> 5554 DN then rings the DN 5554 which is BAD.

The Callmanager is intended to give always priority to the Translation rule and not to the DN.

Thats the problem im facing. Would be nice to find a solution to this.

I believe I understand now.

The answer is the same.

Seperate the partition that your 3 digit translations are stored in.

Make sure the calling search space that you assign the translations does NOT include the partition that contains the 3 digit translations.

So, if your enterprise has partition_A, partition_B and partition_C, create a PSTN_translations partition, and put the 3 digit translations in there.

Create a new calling search space, called, say, 3digit_callout_css and have it include partition_A, B and C, but not the PSTN_translations partition.

This way, when the translation attempts to place the call to the transformed called party, it will not hit yet another 3 digit translation.

It all comes down to partitions and calling search spaces in the end.

You can't escape them. You might as well befriend them. ;)

I get it now, ill test it next week.

this solution maybe better than switching completly to CSS and PT.

Ill tell you if it worked.

Thanks again.

lfulgenzi you are indeed a Guru, worked like a charm.

Thankssss

Good to hear!