F5 configuration for OCS R2 Enterprise Edition

This has been somewhat of a trial and error situation for our OCS R2 deployment and at times very tiring trying to coordinate the OCS and F5 teams to be on the same path. Nevertheless, the information below will help other hapless soles on their path in getting this configuration working successfully. The table below should help anyone get the right settings to have all the different working parts of an OCS R2 deployment working when using an F5 to load balance multiple front end servers in a consolidated deployment.



To configure a health monitor for 5061 using the web F5 admin interface (information taken from F5 OCS R1 configuration document):
1. On the Main tab, expand Local Traffic, and then click Monitors. The Monitors screen opens.
2. Click the Create button. The New Monitor screen opens.
3. In the Name box, type a name for the Monitor.
4. From the Type list, select HTTPS.The TCP Monitor configuration options appear.
5. From the Configuration list, select Advanced. The advanced configuration options appear.
6. In the Configuration section, in the Interval and Timeout boxes, type an Interval and Timeout.
7. In the Alias Service Port box, type 5061.
8. Click the Finished button.

From the .conf file it will look something like this:
}
monitor ocs-frontend-sip-5061 {
defaults from https
interval 30
timeout 91
dest *:5061
}

Also, you will need to create a TCP profile with an Idle timeout of1200 seconds and enable TCP resets on idle timeout which will need to be applied to each of the F5 pools created.

Of course all this information is on the internet in various places. The following document is available from MSFT on load balancing requirements for OCS R2 but it’s a general document not specific for F5.

Hopefully this will help someone out there somewhere :-)

CUCiMOC, is it too late?

I had a bit of hectic week last week, so coming up with ideas to write about fell a little to the side but I thought I would talk a little about Cisco’s upcoming integration to Microsoft Communicator. At the CIPTUG national conference last year CUCIMOC was announced during NDA sessions so now that they have released more information on Cisco.com I feel a little more comfortable talking about it on the Blogosphere.

Matt Mcgillen has written a bit about the functionality here in his blog so I am not going to cover all the technical details. I really wanted to talk more about where this may or may not fit into a enterprise and is it too late for some enterprises to take advantage of what CUCiMOC may have to offer. Matt’s blog by the way is an excellent source of information from a guy doing this stuff day in and day out. I highly recommend subscribing to it.

Once an enterprise commits to a deployment path it can be extremely difficult to turn the ship around and head in the other direct. So, I do not believe that Cisco were aiming this product at those that were already committed to OCS Enterprise voice. This product, I feel, is aimed at stopping enterprises from heading in that direction in the first place. There are a couple of things that I think are very beneficial and a few things that may need to be considered if looking at deploying CUCiMOC.

The benefits for an enterprise could be simplifying your environment and maybe, just maybe a reduction in licensing. Simplifying your environment is from a dial plan perspective and the ability to do RCC without CUPS. This is really from an infrastructure standpoint and not the desktop, which I will get to. Having one dial plan is a bit misleading though for a large enterprise that may have multiple clusters but it does mean not learning a new products dial plan. It does however provide a reduction in servers both for CUPS(RCC) and OCS mediation servers (OCS Enterprise voice). It also means not having to purchase the OCS license that includes voice features. Now depending on your current Cisco licensing this really may not amount to much anyway, so it’s all about crunching the numbers to see what comes out the best for your company.

Some things to consider would be a reliance on the desktop to provide the integration and a lack of collaboration between Cisco and Microsoft on development of this product. These two points are really intertwined. Let us just hang on the first point here for a second. This is what I consider a pretty complex integration happening at the desktop which unlike other desktop products like for example outlook where real time information is being exchanged to achieve a task. This is a complex task to achieve at a server level at times and now we are relying on the desktop to provide it. Not that I am questioning the ability of Cisco to provide a reliable integration but more of question of a user’s ability to break things through inadvertent activities, like installing an application they should not. I guess the comeback to this is users have been breaking stuff a long time we are used to that happening. This could be somewhat a of a benefit to, because if it does break it may only be the one user affected, unlike current RCC solutions where many could suffer.

On to my second point. When you look at the history in the UC space of the relationship between Cisco and MSFT it is rather contentious. This really comes through in the fact that MSFT has stated that it will not support this integration , which in essence may mean that when moving from one version of Communicator to the next, parts of or all of this integration may no longer work (RCC ring any bells out there). So, now we have a complex integration on the desktop that one company may refuse to help with should you deploy it and Cisco will have to ensure that they stay current with the latest version of MSFT Communicator to ensure it works. Which means it is quite possible your whole OCS deployment could become dependent on a plug-in being available for the version you want to deploy should your customers become reliant on it. Interesting scenario and a situation you may already be familiar with through other products, so may be not totally new.

I hope this didn’t seem to harsh on Cisco as this is a very innovative way to integrate the two environments and I know from experience, something customers using RCC products have been asking of Cisco for a long time. But at the same time I really feel the development of this is late and the uptake on it may be less than hoped. In the end only time will tell. If you have had experience with deploying CUCiMOC please feel free to post your thoughts, I would be interested to hear them.

For a comprehensive look at third party plugins for VoIP and Microsoft Communicator:
http://voipnorm.blogspot.com/2010/01/microsoft-communicator-native-versus.html

Preserving P-Asserted Identity formats on a Cisco SBC

Not sure if this is really applies to anyone’s deployment out there but this is an issue I recently encountered with a Cisco Session Border Controller and P-Asserted Identity (PAI). When the SBC received a SIP packet from our application it changed the PAI format from tel: to sip:xxxxxx@xx.xx.xx.xx. Not that there is any rule that says this cannot be done, it was slightly annoying and breaking our application. Below is the code that fixed this issue.

!
voice service voip
sip
asserted-id pai
!
voice class sip-profiles 1
request INVITE sip-header P-Asserted-Identity modify "<sip:(.*)@.*>" "tel:\1"
!
dial-peer voice 811 voip
  voice-class sip profiles 1
!
dial-peer voice 8112 voip
  voice-class sip profiles 1

The SIP profile should be applied to your outbound dial peers. Although this shows some flexibility of the CUBE to make this adjustment, it would not have been required if it had not changed the PAI in the first place!

Update: Our application developer informed me that some service providers my require the tel: format. Qwest only supports tel URI but XO supports SIP URI as examples. So having the ability to do either is a good thing.

For more information on PAI check out the IETF website and RFC 3325

Response Group Part 4: Two-level Interactive Template

For the last installment in this series I had to break down the diagram into sections to make it more readable.The two-level interactive template is very similar to the one level but as you would expect, another level is added, duh. I will let the diagrams do the explaining.

Diagram one shows the entry point to the response group for the caller.



Diagram two takes us to the results of the first and second level IVR.



Diagram three represents the agent queues for all levels.

Response Group Part 3: One-level Interactive Template

Third in this series of blog posts, we are really getting to the more complex scenarios. One level interactive RG’s add the IVR style menu options that can be a voice response to set questions. As the diagram shows, this is building on the enhanced hunt group. Sure, this will not cover every requirement you may have for IVR style ACD but then again it is not supposed to either. I know where I work this type of ACD is popular on the more traditional systems and this level of complexity would cover 80% of all our requirements. The more complex IVR and ACD requirements are best left on a specialized platform like OCS 2007 Speech Server or Cisco IPCC Express for example.

What I really like about the Response Group feature is the ease of setup. Too often with simple Hunt Group and ACD requirements the complexity to get things working and needing to know scripting languages can be painful when something with the website interface setup will do.