Simple OCS and CUCM/CUP integration

We have a sample company running Cisco for call control accross the company. However some users prefer to use cisco for presence and some other users prefer OCS.

The expectations are that each set of users can see each others’ presence, can I’m to each other and can share some files.

Users in the Cisco realm are part of a subdomain to the main domain of which the OCS users are part of.

Cisco users have sip uri of the form userA@sub.domain.local and OCS users have sip uri of the form userB@domain.local.

We have elected to use simple static routes to achieve the results, following Cisco papers on the subject, to no avail so far.

It is amazing though tiny details and steps that seem to be identical turn out to be fundamentally different.

So in the end we got this bad boy working. We will be doing some more tests in the new week.

Starting to blog again

It has been 9 months since I last posted here.

I have got to say I miss it and I am very excited to start again.

I have been busy doing other interesting things such as moving into a new job.

The new job is now starting to develop into some uc integration between Cisco and OCS.

I have already setup a lab including exchange 2007 and ocs 2007R2. I am now waiting for my colleague to setup the Cisco gear. Once that is done we will sart working on the integration.

I propose to relate technical findings as well as business findings in future posts.

See you soon I hope.

Beware of pitfalls in UC deployments

I have been overseeing the deployment of certain ip telephony technology over the past year. There are many things out there that are very dependant on using either analog gateways (FXS/ATA) or might talk sip natively, but are capable of encrypting the sip and rtp communications, or they are not able to authenticate against a kerberos realm.

I think I just gave it up, many devices out there will not interoperate too well with OCS. In my experience, many manufacturing sites still have the following type of requirements which are not addressed by the MS OCS platform:
– intercom, door openers
– Personnel Address systems (PA, loudspeakers)
– factory bells
– DECT or other cordless phones
– and perhaps others

These devices all typically interface with an FXS gateway, which must be able to convert rtp protocols to the rta used by OCS, and they must be able to do sip over TCP and encrypt using TLS. Another sticky point is which Active Directory user should these devices be logged in as and what mechanisms should be put in place to ensure their ‘presence’ information is always ‘available’. This also means that each of these devices need a UC CAL but it should a ‘restricted’ CAL to ensure the pricing is fair.

I trust that gateway manufacturers are collaborating with Microsoft to produce this type of interface.

Snom releases ip phones for the OCS R2 platform

I started trialling the ip phones made by snom about 6 weeks ago, and found that these devices integrate natively into my OCS pilot. There are a number of reasons why one would consider using ip phones in conjunction with the MOC, these are:
– users are still used to the physical handset and out of habit/culture continue to resist software-only telephony; this is probably the greatest reason certain UC deployments fail
– an office cannot remain devoid of any phones; the main reason for that would be 000 (911 in other countries) emergency calls

The fact that Snom has manufactured this family of OCS compatible devices brings new blood to the competition and keeps the pricing realistic.

Snom have declared that their devices allow to do the following:

* have incoming calls announced simultaneously on your desktop AND your snom phone;
* search for names or phone numbers on the Microsoft® Office Communication Server via snom ActiveDirectory Search (snom LDAP);
* see the current status of your contacts (free, not logged on, busy);
* place secure calls both from your computer via Microsoft® OCS OR from your snom phone.

An additional benefit to these phones is the ability to integrate with another sip deployment (other ip pabx) by using multiple identities that exiting within separate systems.

When telepresence becomes a must

Executives just like throwing spanners in the wheels! Whatever the motivation is, a demo they just saw, an excellent sales pitch they just heard touting fewer than 6 months ROI or even just a simple new business requirement…

So when you discover that all of a sudden you might need to cater for telepresence as part of your communications strategy, it is back to the drawing board.

Obviously, the levels of excitement increase, but ultimately the questions are the same:
– what must I do to my network to cater for this?
– which brand/model?
– will I purchased a managed service instead of ‘owning/managing’ the stuff?
– will it be compatible with the other UC pieces in the puzzle?

Fortunately the main driver for this one is the need to have weekly executive meetings between 2 groups on different continents. This should be straight forward as far as cost justification is concerned, but the technical challenges remain there.

What business value could be expected out of a Unified Communications deployment?

There are a number of questions that come from business managers when you present any technology to them. Those are:
– do we need this technology?
– what is the business value?
– do we have a problem we must solve?
– what is this technology replacing? In other words, where can I find savings?
– how hard is it to get working? or in other terms, what effort must I give in order to make it work? In money terms, this means, how much must I invest?

Starting from these few questions one can develop a strong business case to present to managers. Small modifications can be made depending on the audience.

Typically these questions are not technical questions, but a strong technical grounding is required in order to understand what it is you are presenting (UC in this case).

Let’s see what might come from UC. In this example I will use the scenario where an enterprise has many geographically dispersed sites (say 50) with a few thousand staff (say 2000) distributed in those sites. Each site has its own pabx and its own block of 100 indial numbers (DID). Eighty percent of these pabx are more than 10 years old and a good number is 20 years old.

So, answering the question “do we need this technology?” is straight forward:
– a UC deployment could allow the enterprise to “consolidate” telephony and start hosting it at the datacenter or in the cloud
– This would allow the company to save on the number of number blocks used and ISDN channels used and on not having to purchase new pabx systems

The question “what is the business value?”
– we do not know that the business wants IM or presence, but we can foresee that it will bring strength to the users who have got it. In any case this will be of strong appeal to gen-y workers
– we understand that doing free calls internally will allow teams to communicate more freely and more efficiently using desktop sharing
– the web conferencing and federation will allow multiple businesses to work more closely and tightly together, which is important in a recession

Does the business have a problem to solve? And where can I find savings?
Yes they do!
– The aging pabx systems will start falling apart rather soon, which will increase cost of maintenance and in certain cases even force a costly replacement of the system.
– Replacing these systems at $1,000 per user (approx., the figure was stated by PABX vendors) will cost $2,000,000 for the whole business!
– Many companies have banned travelling so UC can help people to collaborate from different locations. If this company wishes to save $2,500 worth of travelling for each site, each month, this represents a total travel saving effort of $1,500,000 per annum.
– That company has 50 blocks of 100 numbers which are not all used and each site has 10 ISDN channels. This could be consolidated to 3 blocks of 1000 numbers ($6,000 worth of saving per month). The channels can be consolidated to 250, which is a saving of $7,500 per month)
– Companies use audio conferencing providers (the likes of verizon), which are made obsolete by this technology. All that is now required is internet access and the conference is free.
We have already found $6,986,000 worth of savings over 3 years that represent that much less on the bottom line if nothing is done.

How much should be invested?
This is where the knowledge of technology comes in place. We will need the following items for a MS OCS deployment:
– user licenses (2000) @ $200 ea = $400,000
– user devices (2000) @ $300 ea = $600,000
– mediation servers (2 for high availability) 2 x $35,0000 = $70,000
– front end servers (5000 users per server, 2 are required for high availability) 2 x $35,0000 = $70,000
– edge servers 2 x $35,0000 = $70,000
– load balancers 2 @ $100,000 ea = $200,000
– gateways 9 PRI’s required on 2 “16 PRI” gateways @ 50,000 ea = $100,000

This represents a total investment of $1,510,000, with an ROI of less than 8 months.

All above costing may not represent true cost to business as prices may vary upon volume, negotiation-ability, the existence of agreements… in other words, please do the maths for yourself and your own scenario.

This is a compelling case.

Building blocks of a Unified Communications deployment – part 5

So, we should now have a bunch of systems (see Building blocks of a Unified Communications deployment parts 1-4) available that the UC infrastructure will hinge upon to provide its own deliverables.

And this actually boils down to the question everyone has about UC, i.e. “what is UC?”.

The definition varies from vendor to vendor and from customer to customer. My working definition of UC is:
– presence
– instant messaging
– unified messaging (fax and voicemail delivered by email)
– audio and video conferencing from the desktop/laptop
– mobility and roaming
– web conferencing
– presenting one number to the caller (abstraction of the device)

Because this platform is so hot, and is slated to replace traditional voice services, it is necessary to think of UC in terms of a service, not just in terms of functionality. This is how ITIL defines a service: it must address utility (functionality) and warranty (reliability, continuity, performance and capacity).

In order to deliver the ‘warranty’ aspect of the service, the architecture must cater for load-balancing, fail-over and scalability and service management processes.

Typically, load-balancing will be provided by load-balancers (F5, Radware and others) and correct DNS and LDAP configuration. These devices also help with fail-over, as does the application itself. However, one must ensure that at least 2 load-balancing devices are deployed in the solution.

DNS must be configured to point traffic to a virtual IP for the service.

As far as capacity and performance is concerned, the service must be configured to serve today’s loadworks and a bit more; it must also be able to grow and scale to cater for tomorrow’s growth.

Comments are welcome, and thanks for reading.

Peter Hernandez

Building blocks of a Unified Communications deployment – part 4

It has been a while since my last post; I have been quite busy with the MS voice pilot at work together with a number of related and not so related jobs.

I promised to talk about databases, and archiving and monitoring and reporting. We must also introduce provisioning of end-user devices.

We have previously discussed the necessity to store information about the users and their UC identity within a directory. There are a number of other items that will need to be stored for several different purposes.

The type of information that we might want to store is going to be around the call, typically:
– time of call
– number of caller
– called number, and id of person called
– call duration (for payback)
– quality of call
– monitoring information

This type of information must be stored in a database, which can be MS SQL Server, Oracle, Sybase or even MySQL, to name a few. The one you will choose must be able to integrate with the UC platform chosen.

In order to provide feedback and store information about the quality of a call, there must be some active monitoring of calls occuring within the environment. Some platforms offer this as a feature (such as within the MS OCS platform and Interactive Intelligence’s EIC/CIC platforms) and some others rely on other means.

To be able to relate this information with calls, it is important to link it with the relevant records in the database, and tight integration is required, thus making platforms that include the feature standout compared to others.

Reporting on the archived information is then simply a matter of presenting the data stored in the database in a readable manner. Many tools provide the functionality. Many UC platforms provide integrated reporting.

The next big item is the provisioning of end-user items such as ip phones, video phones and other similar devices. It becomes necessary to securely update the firmware of these devices and it is clear that secure methods such as https should be preferred over ftp or tftp methods.

Said provisioning server should be capable of fetching updated firmware and distributing it to the end points in an automated way.

I hope to soon discuss UC, as a tight integration of many different items.

Building blocks of a Unified Communications deployment – part 3

In part 2 of “Building blocks of a Unified Communications deployment”, I talked about the demands that would made on the WAN and on the need for a corporate directory. In this post we will discuss the email/messaging platforms and gateways.

Email platforms come in many flavours, but the types that we will need to consider have the following characteristics:
– obtain the users’ information from a corporate directory so that there is no redundant information stored on the network and so that we have one authoritative source of information
– a calendaring function should be available as a source of free/busy information about a user, which can be used to feed into the ‘presence’ engine of a UC platform
– the mailbox of the user will be used to store his voicemails and faxes as they are sent to him. This is generally called Unified Messaging (UM).

The most common messaging platforms are Microsoft’s Exchange Server platform and IBM’s Lotus Domino. We should also consider Cisco’s attempt to provide UM through the purchasing of an email platform called . Cisco’s attempt to provide UC to its customers looks more like un-unified communications, because its components do not typically integrate well together.

On the other hand, gateways -voip gateways- will be a necessary ingredient of your communication strategy. As discussed in my 1st post and 2nd post, gateways will interface with the PSTN cloud, help you integrate with the PABX and provide you with an interface into the h323 world of video conferencing.

In other words, they will accomplish the task of converting the session control protocols from sip to h323 (and viceversa) as well as from g711 or g729 to rta for audio realtime codecs and from h264 to rtv.

Conversion to rta and rtv is only necessary if a Microsoft OCS deployment is performed. The rta conversion can be done on a OCS mediation server role, or on a gateway if the manufacturer has obtained a license from Microsoft to implement the rta protocol.

The rtv conversion is only necessary to implement when interfacing with a video infrastructure that does not understand it – typically all solutions bar the OCS platform.

In a next post, I will talk about databases and other related matters, such as monitoring and archiving and reporting.

Building blocks of a Unified Communications deployment – part 2

My last post I attempted to show which elements of a network are necessary building blocks for the creation of a Unified Communications (UC) environment.

We must consider that the medium used to communicate is no longer the Public Switched Telephone Network (PSTN) cloud but rather, the data network is used to interconnect the different sites of the corporation. This is called the WAN. Certain ingredients are necessary within the WAN in order to deliver UC.

The WAN cloud must be able to provide connectivity between each site; in other words it must be fully meshed. It must be fully routable as well as highly scalable so that sites can be added at will. It should also cater for QoS needs should this be a necessary requirement.

The MPLS technology provides the necessary ingredients. It is readily available from most data vendors around the globe.

Further to this the WAN may utilise WAN optimisation devices in order to take the full advantage of available bandwidth and to counter the effects of latency and application chattiness. This technology also helps organise the flow of data.

Once the connectivity, network and transport layers are taken care of, we need to organise information about the staff in the corporation. A corporate directory is the perfect repository for this type of information. The type of information stored should include, at the very least the name, surname, account, email address, phone numbers, sip uri, location.

In many cases this directory also store authentication information and authentication mechanisms are used to identify users against the directory.

Technologies that deliver this type of information and authentication  generally take advantage of the LDAP protocol. The most utilised LDAP directories are Microsoft’s Active Directory and Novell’s NDS/e-directory.

In my next post I will talk about email platforms and gateways.