CSS Design Question

[James Hawkins]

Hi,

I have an existing customer running CUCM 8.0(3) who have recently been upgraded from 6.1.

In the original implementation there were two MGCP PSTN gateways (Each with an E1) and outbound calls were sent to the first gateway with the second being used if all channels on the first were busy.

I used the Line/Device CSS model to control phone calling privileges and this worked fine up until now.

Things have now changed and the customer now wants to split the internal users into two groups. Outbound PSTN calls from group 1 should use gateway 1 and those from group 2 should use gateway 2.

If the phones did not use Extension Mobility this would be simple to do. I would create a devices pool for each group and set Local Route Groups containing the appropriate gateway port and then just modify the existing route list to contain only Local Route Group.

Unfortunately using Extension Mobility breaks this as they want any user to login to any phone and have their calls routed out of the appropriate gateway. As EM does not change the Device Pool of the phone then the Device CSS will not change when a user logs in and with the Line/Device approach it is effectively the Device CSS that controls which outbound gateway is selected.

Before I completely redo the existing dial plan to use Line CSS based permits does anyone have any suggestions on how I can easily modify the setup to work as required?

[William Bell]

James,

I can't think of a solution to the problem other than pushing all CSS decisions to the line. I don't like that any more than you do. CUCM has several ways you can accomodate call path selection based on device location. But that won't help you. Unless, you can convince the customer that their approach is problematic.

I am sure they have their reasons, but have you talked to them about this requirement so that you understand the drivers behind it? It may be that you may get a better understanding of the problem and be able to provide a better solution. As it stands now (based on the wee bit of info we have now) I think the customer is possibly misguided. What they are asking for sounds problematic to me, especially in the long term. I am curious as to what benefit they hope to gain from this approach. If you don't know then I would definitely recommend you meet with the customer so you can understand the ins and outs of this request. This is one of the design areas where it is best to slow down, ask questions, and guide your customer to the correct conclusion.

HTH.

Regards,
Bill

[James Hawkins]

Hi Bill,

Thanks for your response. The customer is actually a sales outsourcing organisation. They take calls on behalf of other companies and their staff answer as if they worked for that company.

Their largest customer uses a hosted contact center system to forward calls to DID numbers on agent phones. Up until now the agents have just used DID numbers from the range owned by my customer which hunt over the two E1 circuits connected to the two gateways.

As part of contract negotiations with their customer it has been agreed that calls should come into a new DID block used only by agents working on that account. They also wanted assurances that 30 channels would be available at any time and agreed that they would pay all telephony circuit and call costs for agents working on their account.

The solution they have agreed is that my customers customer will take ownership of the second E1 line and the DID setup modified so that the existing ones hit the first E1 and the new ones hit the second one (They are aware that they lose the resilience they currently have in the event of a circuit or router problem but are willing to accept it).

My customer has a group of agents dedicated to the account but others that float between customers according to demand. To allow these floating agents to work on the account in future their DID will need to change to one from the new range (and change back when they are working on other accounts). The obvious way to do this seems to be EM but that does not solve the outbound CSS issue.

One thought I had was to configure Device Mobility and then move the phones between VLANs thus forcing them to use a different Device CSS but I do not think that this would be a practical solution.

Any comments or suggestions most welcome!

[William Bell]

James,

Understood. Sounds like they have already worked themselves into a corner, which puts you in the same corner.

As you have already ascertained, using Device Mobility is not a viable option.

One approach could be to build a custom XML application that dynamically reconfigures the CSS on the device. You wouldn't need EM for this. The idea is a simple XML application that allows the user to press a button that tells the app "I am working on customer A right now". The app can then use AXL/Soap to update the device's CSS. You could tie a menu to the app if needed. I won't go too far down this road because I doubt the opportunity/desire exists. But it is surely possible.

Another approach is to ask the customer to change dialing behaviors. If they use "9" for off net calling today, maybe "8" (example) can be relegated to identifying an offnet call for Customer A. Your line level restrictions would need to be updated to allow for 8 or 9 in the leading digit. You can reuse the same patterns (most likely, anyway).

A third approach is to push all CSS configs up to the line. That is cumbersome and not very desirable for all the reasons you, myself, and other posters have eluded to.

You could consider the option of building a translation that is visible from line CSS configs (a new partition is needed as well). This has already been suggested as an option. This may not be as clean as previously suggested. That depends on what your current dial plan looks like. For instance, you still may have to duplicate your core route patterns. You may be able to get away with two (one generic off net for Customer A, one for everyone else). So the translation would prefix and that prefix would pick the pattern. The pattern would dictate call path via Route List, Route Group, etc. In this scenario, keep in mind that the effective CSS for a call placed from a line is the line CSS + device CSS. Also, if the device CSS sees a more specific pattern than your "new" translation (if you go this route) then that pattern will be used (bypassing your method, more or less).

I pondered the merits of dial-peers, translations, and answer-address on a H.323 gateway (for example). I don't like how that plays out either, especially since there are two gateways.

So, if it were me I would consider if a custom app would fit the need. If that doesn't jive, then I would look at socializing a change in dialing behavior. Finally, look at using a line level route solution that minimizes redesign as much as possible.

HTH.

Regards,
Bill

[James Hawkins]

Thanks Bill,

Some great suggestions. The XML application is interesting but I think coding it would be beyond me. Ideally they also want the DN to change so the app would need to do that as well.

Using different PSTN access codes has potential but, as it requires users to think, then I doubt whether they will go for this.

I think that we have established that there is no simple solution so I feel better about changing the dial plan to work based upon the Line CSS (I did not want to do it only to find out that I had missed something obvious).

Thanks again to everyone for taking the time to respond

[Rob Huffman]

Hey James,

I'm with my friend Bill here! +5 Bill

This design would be contrary to most efficient "Best practice" type deployments. I'd

also be worried about whether or not these E1's are also used for Incoming calls. This

is where the Bottom-up and Top-Down design for Incoming and Outgoing calls could

be disrupted. I'm curious as to what the "end game" is here just like Bill

Cheers!

Rob

[rbays@angelo.edu]

I think you could do this by adding some translation patterns into the line level CSS.  Say for instance your model was device CSS allowed all calling to the PSTN and various line level CSS restricted calling to International, LD, Local, and others. You could add translation patterns into the line level CSS that caught the specific PSTN destinations and translated them as is, but applied a new CSS that would include whichever gateway the user of the line was supposed to prefer.   If I remember correctly, the line level CSS should supercede the device level CSS so it would take the translation pattern.

This really goes against the design idea of the device then line CSS model though because you have your line CSS allowing calls rather than restricting them (at least that is how I understand it).  On the positive side, you would have a minimal number of patterns to remove from the line CSS if you have to roll back.  I say that because I am with the other posters in that I think the reason they are requesting this might be better served by some other technique.

[James Hawkins]

Hi Ryan,

Thanks for the suggestion. I understand what you are getting at but think that it might add too much complexity.

I guess that I will have to bite the bullet and redo the dial plan from scratch - at least I can setup E.164 route patterns which should set them up for some cellphone integration suggestions I am trying to pitch to them.

Thanks for the responses guys.

[iptuser55]

Don`t know if ithelps but have you looked at logical partitioing? Yes I know it was designed for certain PSTN/ VOIP requirements for India. I`ve not touch logical partition but it may help in your case????