Even though many businesses (large and small) sell exclusively to other businesses, every business has the consumer at the end of its value chain: it is hard to think of a single product or service that isn’t aimed at the consumer as the ultimate customer.  Every company that sells to the consumer has always sought better ways of engaging with that customer.  When postal ‘junk mail’ outweighs ‘mail of interest’ by 10 to 1, you know that it all goes straight to compost nowadays.  Telemarketing doesn’t work well because consumers unsurprisingly regard cold calls received at dinner time as being invasive.  With the advent of caller-id and ‘do not call’ lists, the call completion rate for telemarketers must surely be unsustainably low.  Over 10 years ago, marketers switched to email, which was quickly addressed by SPAM filters and other mechanisms.  The currently in-vogue B2C marketing technique is social networking: how many times have you read or heard “Follow us on Facebook and Twitter” this week?

As those of us who enjoy the features of UC can attest – the use of presence (i.e. the publication of one’s willingness and ability to communicate), filtered routing rules and session invitations containing call context (i.e. a subject line included in an incoming call indication) are all wonderful ways of staying on task while ensuring that essential communications are completed rapidly, neatly avoiding the dreaded voice-mailbox.  The goal of marketing via social networking is an attempt to gain the consumer’s consent to participate in a dialog: doesn’t this sound like UC?

Internet-based consumer communications, such as instant messaging (IM) services, VoIP and video calling actually preceded UC by nearly a decade.  However, the ‘public cloud’ service providers (including AOL, Yahoo!, MSN, etc.) jealously guarded their ‘namespace’ (i.e. their list of users) and refused to interoperate with the others.  The reasons for this are outside the scope of this blog, but suffice to say that it wasn’t in their business interests.  However, a rapidly-growing number of businesses now have access to UC and would dearly love to engage with their best customers in a consent-based, contextually-driven and time-appropriate way.  This is the promise that B2C federation holds out.

It is very likely that this notion has not gone un-noticed in the executive suites of the UC vendors.  After all, Microsoft did the biggest deal in its 37 year history this year to buy Skype; and no-one believes that they paid $8.5Bn for a free communications service.  At NextPlane, we are pleased to be able to offer our business customers access to consumers via federation with Google Apps/Google Talk and we believe that this is just the start of B2C federation.  The communications industry is evolving rapidly and no one can predict what will happen next – we are just happy to be in the game.

There is another UC ROI model for small and medium businesses (SMB) that suggests that, although teams within smaller companies are more likely to be able to meet face to face, nevertheless they are often involved in large projects that span the company’s boundaries.  Indeed, the probability of any given interaction being with an external business partner is inversely proportional to the size of the company.  The ‘value chain’ scenario that is depicted in an earlier blog (‘Thousands of parts flying in close formation’) is dependent on inter-company federation.

The size and complexity challenge presented by UC deployment has not gone away; a UC system does a lot more than a PBX: not only voice but also multi-party multi-modal conferencing, HD video, instant messaging and presence, email, single directory/single-sign-on, data collaboration, etc.  However, the advent of the cloud computing era has presented an opportunity for smaller companies to gain access to ‘big company’ UC capabilities by buying capacity on multi-tenant hosted systems.  Nevertheless, as described above, the main SMB UC business case is dependent on being able to collaborate with business associates outside the company.

The interdependence in the business case between federation and cloud-based UC for the small to medium business segment means that a UC cloud service that doesn’t offer, at the very least, inter-company communications among the cloud customers will have limited utility.  The best UC cloud services will also have federation capabilities with enterprise UC deployments, providing a collaboration fabric among value chain members of all sizes, as well as between clouds of different vendors.

As described in ‘Inter-company Federation – the Bad News’ the UC systems that currently offer federation do not interoperate.  Therefore, the next service that UC customers, both large and small, will be seeking is one that offers federation between cloud-based systems and enterprise hosted systems from a variety of vendors.  Anyone who is seeking such a service should remember one word: NextPlane.

The term ‘authoritative’ suggests exclusive control – in practice it means that every UC session generated by a UC client is going to be routed to the associated UC server according to some scheme determined by the UC vendor.  These schemes vary, and are not dictated by the SIP spec (i.e. RFC 3261): the options from which UC designers can choose include: directly configuring the UC client with the server’s IP address; making a request to an internal DNS or corporate directory server (e.g. LDAP) or using DHCP services.  As can be seen, vendors’ different implementation choices create opportunities for non-interoperability.

The authoritative routing issue is compounded by the mechanism that the UC Server uses for locating the destination client.  Within SIP, the mechanism is a ‘Registrar’ that stores the IP address of all clients currently logged in.  Clearly each vendor’s clients will register with their own servers (i.e. Cisco clients will register with CUCM servers and Microsoft clients will register with Lync servers etc.) and will not have visibility of other vendor’s registration list.  Within SIP-based systems (XMPP is slightly different, but we will leave that for another day) the address mechanism is a uniform resource identifier (URI) which, like email, takes the form of ‘alice@acme.com’.  However the URI format does not indicate whether Alice is a Cisco user or a Microsoft user, so UC systems are incapable of differentiating between a user that does not exist and a user of another vendor’s system of which it is unaware.  Ignoring the fact that UC vendor systems are not interoperable, the unworkable routing and addressing environment created by the assumption of exclusive authority is the reason that multiple UC systems cannot peacefully coexist.

One approach to the domain sharing issue would be to create subdomains, e.g. alice@cucm.acme.com and bob@lync.acme.com.  The UC server is then able to see that the destination domain is not its own and therefore uses DNS to find and forward the message to the ‘other domain’.  However, this is onerous for both the user and IT to maintain and is entirely opaque to external federation contacts.  Furthermore, for Alice to be able to communicate with Bob, there would have to be an intermediating gateway element between the subdomains.  What would be greatly preferable would be a solution that would obviate the need for sub-domains and would intermediate between the UC protocol dialects of different vendor’s UC systems within the domain as well as those of external federation contacts.  Such a solution would look a lot like NextPlane.

Companies with the luxury of being able to implement a ‘clean slate’ UC deployment can immediately enjoy the benefits of a single platform environment within the domain.  However, they are not immune from the challenges of integrating with other UC platforms: business partners with whom they may wish to federate will not necessarily have made the same UC platform choice, as was discussed in ‘Inter-company Federation – the Bad News’.  Having solved the problem of how to facilitate inter-vendor, inter-company federation, there is also the challenge of who should, and who should not, be exposed to the federation interface.

The technologies employed in federation connections, specifically digital certificate-based encryption and authentication, will ensure that a federation connection cannot be hijacked by a malicious 3^rd party. However, those implementing ‘open federation’ (i.e. the acceptance of federation sessions from any domain that can authenticate itself) should consider policies that protect itself and its employees from unapproved communications access.

Most UC aliases are the same as the employee’s email alias.  Once the corporate alias standard has been deduced (e.g. first initial plus last name or first name dot last name, etc.) then unscrupulous callers can start to traverse the organization far more easily than they could ever do with telephone extensions.  Telemarketing and other unsolicited calls can be a distraction to key employees on telephony devices, however unwanted presence-driven UC sessions can be even more intrusive since they are routed to the location (and device) the employee is registered to, with a commensurately higher probability of ‘call completion’.

Many companies will want to manage communications even with approved business partners.  UC modalities such as voice, video, data collaboration, etc. consume large amounts of precious and expensive bandwidth, with the potential for non-value-adding communications blocking out critical business conversations.  Without doubt, certain departments and organizational roles should gain priority access to UC federation; for example senior executives, joint project teams, production management and order fulfillment personnel, or support groups.

Just as many companies control physical movement around their business premises, particularly ones housing confidential business operations, virtual access should also be managed.  UC data collaboration sessions could be a source of intellectual property ‘leakage’, so appropriate departmental federation policies should be implemented.

As was described in ‘Thousands of parts flying in close formation’, UC federation is an extremely powerful tool.  However, with that power, there is the potential to reduce the benefit gained from UC in an unmanaged federation environment.  While there are standards-based and non-standards-based ways to create inter-vendor, inter-domain UC federation connections, there are as yet no standards for inter-company corporate directory federation or the implementation of policies on directory access.  Companies considering the implementation of UC federation should also consider their needs for policy-driven management of federation sessions, as well as the management of the dissemination of users’ presence indications based on context, activity, business process or location.  Such forward thinking companies should consider NextPlane.

In the last blog, we discussed the issue of M&A or other events leaving the IT department with a legacy of multiple unified communications (UC) platforms.  That blog addressed the long-term co-existence approach; this blog will address the alternative approach, which is to migrate users from one system to another.

By far the cleanest UC strategy is to have all users on a single platform.  Having multiple platforms with disparate feature sets impacts the overall user experience as well as creating all kinds of administrative costs, such as those of dual-management and configuration.  Additionally, depending on the chosen integration strategy, concurrently maintaining 2 (or more) UC systems often requires a separate domain for each system (e.g. lefthand.xyz.com and righthand.xyz.com) to allow each UC system to be ‘authoritative’ for its domain (which is another way of saying to avoid routing and addressing clashes).

However, conducting a ‘flash-cut’ migration has numerous risks, not least of which is ‘leaving some users behind’ in terms of failing to cause them to become invested in the new system via training and other exercises.  Therefore a system migration is not an event, but rather a process that may take many months, depending on the size of the user base to be migrated.  Retaining the option of moving blocks of users back to the previous system is essential, even though it would be a last resort.

One requirement of the migration strategy is to create a temporary bridge between the two systems to allow at least some form of intra-domain collaboration to be conducted between the 2 systems during the migration.  This could be effected through the deployment of a specific purpose gateway, such as a Sametime:SIP gateway.  An ‘any-to-any’ intermediation solution such as a Session Border Controller could also be considered.  The downside of both of these strategies was evaluated in the ‘Co-existence blog’, but for temporary migration usage, an additional consideration is that the expense of these gateways is not justifiable, if it can be avoided.

An ideal migration strategy would be one that did not require the creation and maintenance of multiple ‘authoritative’ domains; one that removed the overhead of managing complex, error-prone intermediation; one that could be implemented for a finite period without large and non-recoverable capital outlays and one that could be closed down when the migration exercise was complete.  Such a migration strategy would probably look a lot like NextPlane.

By the time a company becomes a medium to large sized enterprise, part of its growth will have been as a result of one or more mergers or acquisitions.  While this is quicker than organic growth, M&A events create new challenges, not least of which is the inheritance of disparate IT systems that are not a close match with the systems of the other entities.  With PBX systems, the QSig standard allows these systems to interoperate without any problem.  However, the advent of the unified communications (UC) era has created a new layer of complexity to this situation.

The decision to deploy UC provides an IT department the opportunity to review its communications vendor strategy and to consolidate communications infrastructure on a single vendor platform.  However, with recent acquisitions or prior vendor affiliations, it is likely that there will already be a mix of UC infrastructures, provided by PBX vendors, application vendors as well as network layer vendors.  Before you know it, you have to contend with a mix of systems such as Jabber/XMPP, IBM Sametime, Microsoft OCS/Lync, Cisco UCM and Google Apps.  And none of them interoperate…

Having different parts of the company working on separate UC systems completely undermines the value proposition of UC.  One response to a fragmented infrastructure would be to implement a migration strategy to consolidate onto one platform (migration strategies will be the subject of a future blog).  However, in this scenario, there are good reasons for maintaining a mix of UC technologies: the challenge is to make them co-exist.

There are gateways that will address the co-existence of two systems: for example OCS-Sametime gateways from either Microsoft or IBM.  However, these systems often require the two interoperating systems to be on separate domains, which can be problematic.  Additionally, the interface can be broken when ‘the other’ vendor ships a new version: this will require patches/hotfixes that will lag the vendor upgrade.  Furthermore, when there exists more than 2 systems, the co-existence challenge increases exponentially for every additional system.

Session Border Controller vendors will also claim to provide a solution for “any-to-any” UC system interoperability.  However, unlike the purpose built gateways, these ‘babel fish’ elements implement intermediation via configuration and/or scripts, often placing the onus on the IT department or external consultants for correct configuration or script definition.  Once again, additional costs can be incurred when one or more vendors upgrade their interface.

By far the most optimal and least risky co-existence mechanism would be a service ‘in the cloud’ that would take the onus of responsibility for the intermediation between disparate UC systems, thereby ensuring that two or more mission critical communications infrastructures work seamlessly.  Such a service might look a lot like NextPlane.

The concept of SIP Trunking has been around for 6+ years as a mechanism for connecting a UC system to the PSTN.  The notion back then was that, unless a UC system is connected to the PSTN it (UC) would only ever be an internal communications system, since there was no UC connectivity outside the enterprise (what we now know as ‘Federation’).  And that was true…then.  However, the options for PSTN connectivity now include the SIP to PSTN gateways, such as those offered by NET, Dialogic, AudioCodes, Cisco etc. which provide PSTN connectivity (and much more) with far less hassle.  But what is this hassle that I speak of?

First of all, there are no standards for SIP Trunking.  There is the SIPconnect v 1.1 document from the SIP Forum, but those familiar with that document will know that only 2 service providers (Skype and CableLabs) participated in the creation of that document: most of the contributors were UC vendors.  Telephony Service Providers declined to participate in SIPconnect because they had no interest in creating a SIP Trunking standard.  To this day, they all implement SIP Trunking in a different way, clearly creating an impediment to adoption.  This is because Service Providers view SIP Trunking as cannibalizing their PRI revenues and adding to their costs: in effect, they are providing a PRI discount while providing the SIP-PSTN gateway at their network edge.  Furthermore, any company that is looking for a SIP Trunk service has the option of connecting to any of a range of new service providers over the Internet.  Since the Internet obviates the need for geographic proximity and ownership of the ‘last mile’ network, these services are instant commodities.  The net result is that your traditional telephony service provider may grudgingly provide you with a SIP Trunk, but it will likely be unencrypted and insecure; and the proprietary implementation will require you to deploy a SIP-SIP gateway in any case to intermediate the signaling and media.  That is the hassle I speak of.

If you just wanted to make a traditional phone call (which is what you are doing over a SIP Trunk) then you wouldn’t have deployed UC, you would have stuck with your PBX.  However, you were excited by the vision of presence driven communications; of instant collaboration; of desktop video conferencing; all of these things from the location of your choice.  That experience works ‘out of the box’ among your UC enabled colleagues on your corporate LAN – and you eagerly anticipate the day when it will work with your business associates in other companies over the WAN.  However, if you are expecting that service to be provided by your traditional PSTN carrier, you are going to have a long wait. They tried, 10 years ago, to define an infrastructure for SIP-based multi-media communications in an architecture called IMS (IP Multi-media Sub-system) but it has failed and the telephony carriers are investing all their capital in mobile networks.  The best they are willing to do to enable inter-enterprise UC is to convert SIP and RTP to a standard telephone experience and, per above, they are often unwilling to do that.

So, if you are interested in inter-company UC communications (and why wouldn’t you be after reading ‘How did we ever get by without Federated Presence’ or ‘Thousands of parts flying in close formation’) then you are probably seeking a different kind of service provider.  Maybe you should take a look at NextPlane.

To understand this problem, let’s first take a look at a federation network topology. A federation connection is a 1-to-1 link in each direction for each member of the network. The simple case is if company A federates with company B, then there would be a network administrator at each end that would have to set up and manage the connection; so far, so good. Now add company C to A and B in a triangle, and now there are 6 connections to manage – 1 in each direction for each of the 3 companies. The number of connections (assuming all companies connect to each other, i.e. a ‘full mesh network’) is expressed mathematically as n * (n – 1). So with the latter example: 3 * 2 = 6. Now think about a full-mesh network of 100 nodes: 100 * 99 = 9,900 federation connections and you start to build a picture of a significant network administration burden.

It is probably fair to argue that there are few complete full mesh networks in reality, and that the burden of managing this network would be spread between (at least) 100 network administrators. Some firms may have only 1 or 2 major business partners that merit a federation connection: a component supplier to Boeing is probably a good example. For these firms, the cost of administration of the single federation link is very low. However, for Boeing the cost is very high, because they are at the center of a very large ‘hub and spoke’ network. They have thousands of business partners and each federation connection has to be managed. It is still early days in the UC federation era, but there are already companies that have a large ecosystem of partners and manage over 500 federation connections.

Whether your firm’s value chain looks like a ‘hub and spoke network’ or a ‘full mesh network’, there is a simple resolution. All full mesh networks can be converted to hub and spoke networks by placing a single routing node in the middle to which every firm maintains a single connection. A hub and spoke network is a tried and tested optimization of a full mesh network in everything from logistics and distribution networks (e.g. Fedex), all forms of transportation (bus routes, highway placement, airports, etc.) and even computer data networks at layer 2/3. If your company happens to be the hub in a hub and spoke network, the management of the hub can be outsourced.

To implement this in a UC federation network, there would have to be a network service provider that took a single federation connection from a company network and appropriately routed all traffic from that company to its value chain partners. That service provider would take care of the administration of the network connections, the security aspect (i.e. excluding undesirable elements like spammers) and would even intermediate between non-interoperable systems. A service provider that did all this would probably be a lot like NextPlane.

Every company is part of a ‘value chain’: the combination of upstream suppliers and service providers and downstream customers. Each firm depends on its partners for day-to-day or even, hour-to-hour, operations. On a good day things operate like a well-oiled machine, but on a bad day, as we all know, ‘stuff happens’. Mishaps and outages aside, the business environment is dynamic: customer requirements change and there is constant volatility in things like costs, demand rates, supply rates and even adherence to quality standards.

In a recent article on MSNBC (‘Hundreds of suppliers, one Boeing 737 airplane‘), the Chief Engineer for the Boeing 737 stated: “We kind of pride ourselves on being a large-scale systems integrator.” Boeing ships 737s at a rate of 372 per year, each one comprising 367,000 parts, and each customer wants different parts in their order. Staying on schedule in any given day must require Boeing’s production managers to be highly adaptable and be in constant communication with their value chain partners. Of course this is an extreme case, but every business person can relate to this example.

So one might wonder why anyone would need federation if Boeing can get by without it. The answer is that before UC came along, they had to get by without federation; but now that federation is available, a quick Google inquiry* reveals that in fact they do use it, as described in a recent Microsoft case study. In that document, a Boeing IT product manager said:  “We will often federate with a supplier so they can easily interact with our engineering teams. Our teams can see their presence information and out of office notifications just as if they were part of our deployment. This has helped to speed development of parts and reduce costs.”

Clearly, Boeing has the purchasing power to dictate to its partners which UC system they are going to use; not every company is in that fortunate position. Furthermore, in a ‘greenfield’ scenario where business partners have yet to make a UC investment, it may be possible to influence a partner’s choice of UC vendor so that both firms can benefit from same-vendor federation. However, if any given partner has already made a UC investment, or if they have prior vendor affiliations, there is no guarantee that same-vendor federation will be an option (see ‘Inter-company Federation – the Bad News‘). Any attempt to establish UC federation across the range of all your value chain partners will reveal that there is only one option: NextPlane.

*Google: ‘Boeing communications federation supply chain’

First of all, at the time of writing (September 2011) there are only two unified communications (UC) vendors that natively support inter-company federation: Microsoft (which has supported it since 2006) and Cisco (who shipped it in 2010). However, these implementations are not interoperable – a Cisco customer cannot federate with a Microsoft customer, and that isn’t going to change any time soon. Quite apart from anything else, the technologies used for this feature by each vendor are similar at the conceptual level, but really quite different at the detailed level.

Since federation is such a good thing, why have the other UC vendors not implemented it?  You should probably have that conversation with your UC vendor.  However, many UC vendors that emerged from the PBX/telephony space are still quite voice-centric, so they have typically focused on implementing ‘SIP Trunking’ as a mechanism for communicating outside the company.  Using the PSTN as the inter-company communications network:

1. Eliminates a lot of technical challenges that would have to be dealt with in a federation implementation.
2. Provides communications access to non-UC users as well as users of other vendors’ UC systems.

However, SIP Trunking is just ‘plain old telephony’ implemented on a different protocol: it doesn’t support presence exchange; it doesn’t support instant messaging or any other UC modality; you are still going to be playing ‘voicemail tag’ with your business partners.

Let’s fast-forward to a day when all UC vendors support federation: would all the implementations be interoperable? Unlikely: various vendors implement their products on non-interoperable technologies (see the SIP/XMPP posting), but even if they did, the imperative for interoperability does not exist.

So does this cloud have a silver lining? Here is your decision tree:

1. If you have deployed Cisco UC prior to UCM 8.0, then you can upgrade and go to 2. below.
2. If you have deployed Cisco UCM 8+ or Microsoft OCS/Lync then you can:
• Federate only with other companies that have deployed the same vendor’s technology
• Be happy with PRI Trunking or SIP Trunking
• Go to 4. below.
3. If you have deployed a UC system that doesn’t support federation, you can:
• Wait for them to do so and then upgrade to that version
• Be happy with PRI Trunking or SIP Trunking
• Go to 4. below.
4. Investigate NextPlane for inter-vendor, inter-company federation.