As OCS becomes more popular we find more companies deploying it with diverse needs. During a recent deployment I worked with a client that had over 100 speed dial numbers for various partner companies that they regularly dialed. Each speed dial was a 3 digit number starting with a # (pound/hash symbol), some of the numbers translated to 10 digit dials, others only 6 digits with 4 more digits dialed by the user added to the end. As this was in place with the existing PBX it was important to bring this functionality to OCS as well. After discussing the requirements with the client I used my lab to verify the solution was feasible and consistent to their request. A few minutes of tweaking the normalization rules and I had a plan.
I started with the companies “Location Profile” (in the OCS Snap-in Right click Forest>Properties>Voice Properties), for this example it will be HQ.ocsguy.local:
In recent weeks I’ve had two different clients ask about integrating Cisco systems with OCS. After the initial talks about what OCS can do and how they will use it, the next question always seems to be, can I still use my Cisco phones once we move to Enterprise Voice with OCS?
Thanks to a product from NET called SmartSIP (originally created by Evangelyze and acquired by NET) the answer is yes! SmartSIP is a server based app that allows you to register SIP phones to it, and then proxies that registration back to OCS so the SIP phone can act as an OCS endpoint.
This type of functionality is important on many levels. First of all it gives you a low-cost option (less than 6 Tanjays for the server license) for keeping your existing SIP phones around, lowering the cost to implement a UC solution. Secondly, and this one is more and more important to the environment as each day passes, we get to keep thousands of perfectly good phones out of landfills.
Now that we’ve covered the purpose of this article we can jump right into the architecture. The first question we have to cover is how SmartSIP works. SmartSIP is a SIP registrar that allows devices to connect to it, and then connects to OCS on their behalf. Once registered to OCS, the SIP phone acts as any other OCS voice endpoint, taking advantage of the native functionality within OCS to send calls to all active endpoints.
For this article SmartSIP will be installed on my mediation server, this is a supported configuration for up to 250 seats and was the exact installation method I used during the private beta testing I did with the product. For larger scale deployments it is best to have it on its own box. Here is what my lab environment looked like……
Recently I was working on an Exchange UM and Cisco Call Manager integration. The company who already owned Exchange E-CALs wanted to upgrade to Exchange 2010, and as part of the process we discussed having Exchange handle the voicemails instead of Cisco Unity which was not supported with Exchange 2010 at the time. Another big advantage was the customer could stop paying the “Cisco Tax” on Unity just by using what they already had in Exchange server and client licensing (over 15k in savings year one).
After a quick configuration of the UM role and the Call Manager we had Unity and Exchange playing nice (reference config here). Test users were moved and things were going as planned up until we tried to configure the Auto Attendants. We took an existing recording and converted it over to a 16bit 8000 HZ PCM WAV file. We then cut the file into 2 pieces, one for the “Business Hours Greeting” and the other for “Business Hours Main Menu”. There was no need for any key mappings as the default operator extension of 0 was already configured. Here is what our auto attendant configuration looked like:
At a recent deployment I ran into an issue with delays in response groups. This time it was a bit different than before, though. This time the delay was only 4 to 5 seconds from the time the agent picked up the phone until audio started, and the delay was only affecting Tanjays.
I started off with the standard stuff: SAN field on the edge server cert, access list on the router between subnets, CRL not valid or not accessible, checking the cert algorithm, etc…
Now that we’ve talked through some of the theories involved with analog devices (see part 1 here) let’s roll up our sleeves and configure our environment for Scenario #1.
Our first task is unpacking the Tenor AF gateway from NET. This small form factor device will allow us to plug in eight analog devices to our OCS environment.
A recurring question when planning for OCS and a common search I see leading people to this site is “how can I incorporate analog devices I already own?”
If you’ve deployed OCS, you’ve no doubt heard the questions like,
How can I still use my fax machines?
What about my Polycom Sound Station (or other analog conference phone)?
And the most common of them all….
How do you do paging with OCS???
In this series of posts I’m going to offer up a number of suggestions to make analog devices work with OCS environments, and even run through the setup of one such device to make it all come together.
While working with Kevin Re, one of my clients at an OCS shop, he shared a very cool script with me and has agreed to allow me to post it online. Kevin’s script queried for the next 5 available phone numbers in an OCS environment and output them on screen; this helped him streamline new user creation. It also dumped all of the OCS users and their extensions into a TXT/CSV that can be used for other company phone number lists. After seeing this script in action I thought it would be great to take this script and expanded on it just a bit. Continue reading