Announcement:Cisco Communities NOT Affected by Heartbleed Vulnerability

Quick-witted Oscar Wilde coined the famous phrase "As soon as a truth becomes a fact, it loses all intellectual value". Philosophers have been discussing the principle of "intuitive certainty" over the ages, and interestingly many of the things at the very core of our knowledge rely on belief and intuition rather than ultimate fact. Collaboration in the enterprise, in my opinion, to this day mostly falls into the realm of things we intuitively feel are beneficial: employees and partners and customers communicating in more effective ways must ultimately be of significant benefit given the changing nature of business, right? But often it is hard to prove the point with strict metrics.

 

I think that may now be changing: Forrester Consulting conducted a study aptly titled "The Right Collaboration Architecture Drives Business Transformation") that analyzed the benefits of collaboration in the enterprise. CIOs and Enterprise Architects got a chance to share their experiences around exisiting, recent investments in collaboration technologies (such as Unified Communications or TelePresence), but they also talked extensively about their expectations around future collaboration technologies (such as Enterprise Social Software or collaborative mashup tools). The study captures the excitement around the immense potential benefits of collaboration technology: Let's face it, when over 70% of IT strategists state that they expect collaboration technology to significantly cut decision making time and improve productivity, we are now moving away from intuitively perceiving the benefit of investing in collaboration: what we have is a metric that shows that companies that are not looking into a strategic collaboration architecture are doing so at their own peril.

 

But we also need be aware of the fact that there are risks in charging ahead and hastily implementing new collaboration technologies in the enterprise. The main risk is that enterprises may regard collaboration as a simple continuation of their voice communication strategy. Voice, while always a strategic business tool, in most cases (call center applications aside) has been implemented as a parallel silo: in essence, enterprise users rely on their computers to interface (and log compliance) with enterprise workflows, and on their phones when it comes to quickly reaching out to and involving other participants. And the latter very seldom is captured by the formal workflow. But as we talk about a far richer set of collaboration tools in the future, there will be 2 critical factors for success: first of all, we can not implement every new collaboration technology as a new communication silo, meaning that we can not leave it to users to reconcile all these new tools, we can not expect users to learn how to put them to the best possible business use. Which leads to the second point: a cohesive collaboration architecture is required, an architecture with the ability to smoothly integrate a wide array of collaboration technologies, to deliver on user and device friendly interfaces, and to also offer key capabilities as reusable services that can be integrated (i.e. "mashed") into other enterprise applications.

 

Forrester Consulting's claim -implied in the title of the study -that only the right collaboration architecture will deliver on the desired busines benefits for enterprises may sound self-serving at first, potentially resulting in monolithic collaboration suites and huge consulting projects. But it is of vital importance that enterprises consider collaboration as a pillar of their enterprise architecture, and thus strategize and deploy accordingly. The right collaboration architecture is nimble, modular, extensible. And the right collaboration architecture must include a critical resource that has often been neglected in enterprise architecture: the network. The network has become the sensory system of the emerging enterprise: among other things, it reaches everywhere, it instantly and reliably detects location, status and can link these to identity information, and the network by its very nature is a perfect mediator that breaks down silos. Our Cisco version of the resulting collaboration architecture is here.

 

It is going to be a fascinating journey indeed as we transform key business processes with emerging collaboration capabilities. What are you seeing in your enterprise?  Do you suffer from collaboration silos? Have you successfully begun to craft a more comprehensive collaboration strategy?  Does the the architectural model that Forrester suggests work for you, or would you suggest changes?

 

** Background on the Collaboration Architecture Blog series.  And link to RSS feed **

 

The above blog post is the first in this Collaboration Architecture Blog series.  View the brief video below to find out what this blog series is, and why you should read, subscribe, and post your feedback.

 

 

Posts to the Collaboration Architecture Blog are made a least once a month.  Subscribe via RSS feed so you don't miss the next one:

https://communities.cisco.com/community/technology/collaboration/business/blog/feeds/tags/collaboration_architecture_blog


 

As we alluded to in the previous blogs that IME combines the PSTN, the Secure Peer to Peer networking concepts and SIP to create a trusted end to end IP based relationship between a phone number in one enterprise and a remote call-agent in a different enterprise. This mechanism can be broken into four basic steps:  storage of phone numbers, PSTN first call, Validation and Caching, and SIP call.

 

Storage of Phone Numbers

The first step is that the IME Servers (also called Nodes) form a single, worldwide peer-to-peer (P2P) network, using the RELOAD protocol with the Chord ( http://en.wikipedia.org/wiki/Chord_(peer-to-peer)) algorithm.  This P2P network forms a distributed hash table (DHT) running amongst all participating domains.  A distributed hash table is like a simple database, allowing storage of key-value pairs, (Key being the phone number and value being an identifier for server that intends to store that number) and lookup of objects by key. Unlike a normal hash table, which resides in the memory of a single computer, a distributed hash table is spread across all of the servers which make up the P2P network.  In this case, it is spread across all of the domains participating in the IME Community. In this community all enterprises publish their phone numbers to the IME network, which stores them in the DHT in a distributed and a redundant fashion.

 

Chord provides a clever algorithm to read or write an object with key K (phone Number) to determine which IME Server in the DHT is the box that currently stores (for read) or should store (for write) the object with that key?  With Chord, this will take no more than log2N hops, where N is the number of nodes in the DHT.  Consequently, for a DHT with 1024 nodes or servers, 10 hops are required in the worst case and for 2048 nodes; worst case lookup takes 11 hops and so on.  The logarithmic factor allows DHTs to achieve incredible scale and to provide enormous storage summed across all of the nodes that make up the DHT. In DHTs, each participating entity is identified by a node-ID.  The node-ID is a 128 bit number, assigned randomly to each entity.   It is important to note that the DHT does not contain phone numbers (it contains hashes of them), nor does it contain IP addresses or domain names.  Instead, it is a mapping from the hash of a phone number (in E.164 format) to a node-ID.

 

PSTN First Call

At some point, a user (Alice) in a.com makes a call to +1 (408) 952-5432, which is her colleague Bob. Even though both sides have IME, the call takes place over the plain old PSTN.  Alice talks to Bob for a bit, and they hang up. At a random point of time after the call has completed, the call agent in a.com "wakes up" and says to itself, "that's interesting, someone in my domain called +1 (408) 952-5432, and it went over the PSTN. I wonder if that number is reachable over IP instead?”.  To make this determination, it hashes the called phone number, and looks it up in the DHT (IME Network).  It is important to note that this lookup is not at the time of an actual phone call - this lookup process happens outside of any phone call, and is a background process.

 

The query for +1 (408) 952-5432 will traverse the DHT, and eventually arrive at the node that is responsible for storing the mapping for that number. Typically, that node will not be b.com, but rather one of the other nodes in the network (for example. c.com).  In many cases, the called number will not find a matching mapping in the DHT. This happens when the number that was dialed is not owned by a domain participating in IME.  When that happens, a.com takes no further action.  Next time there is another call to the same number, it will repeat the process and check once more whether the dialed number is in the DHT.

 

In this case, there is a match in the DHT, and a.com learns the node-ID of b.com.  It then proceeds to the validation step.  It is also possible that there are multiple matches in the DHT.  This can happen if another domain - d.com for example - also claims ownership of that number.  When there are multiple matching results, a.com learns all of them, and performs the validation step with each.

 

Validation of Ownership of Phone numbers

To address this critical problem of ensuring that a domain that claims the ownership of a number, by virtue of publishing it, actually owns the phone number, IME utilizes a technique called phone number validation.  Phone number validation is the key concept in IME.  The essential idea is that a.com will connect to the b.com server, by asking the DHT to form a connection to b.com's IME Server. Once connected, a.com demands proof of ownership of the phone number. This proof comes in the form of demonstrated knowledge of the previous PSTN call.  When a call was placed from a.com to +1 (408) 952-5432, the details of that call - including its caller ID, start time, and stop time, create a form of shared secret – information that is only known to entities that participated in the call.  Thus, to obtain proof that b.com really owns the number in question, a.com will demand a knowledge proof - that b.com is aware of the details of the call.  The only way that b.com could know these details, is if it had received the call, and the only way it could have received the call is if it owned the phone number.

 

At the end of the validation process, both a.com and b.com have been able to ascertain that the other side did in fact participate in the previous PSTN call.  At that point, a.com sends its domain name to  b.com (this is described in more detail below), and b.com sends to a.com - all over a secured channel - a SIP URL to use for routing calls to this number, and a ticket.  The ticket is a cryptographic object, opaque to a.com, but used by b.com to allow incoming SIP calls. The a.com call agent receives the SIP URI and ticket, and stores both of them in an internal cache.  This cache builds up slowly over time, containing the phone number, SIP URI, and ticket, for those numbers which are called by a.com and validated using IME.

 

SIP Call

At some point in the future, another call is made to +1 (408) 952-5432  The caller could be Alice, or it could be any other user attached to the same call agent.  This time, the call agent notes that it has a cached route for the number in question, along with a SIP URI that can be used to reach that route.  It also has a ticket. The a.com call agent attempts to contact the SIP URI by establishing a TCP/TLS connection to the SIP URI it learned.  If this connection cannot be made, it proceeds with the call over the PSTN.  This ensures that, in the event of an Internet failure or server failure, the call can still proceed. Assuming the connection is established, the a.com call agent sends a traditional SIP INVITE to the terminating call agent, over this newly formed secure connection.

 

The SIP call setup request also contains the ticket, placed into a new SIP header in the message. When this call setup request arrives at the b.com call agent, it extracts the ticket from the new SIP header.  This ticket object is opaque to a.com; that was previously generated by the b.com. Remember that the b.com agent is the one that generated the ticket in the first place; as such, it is in possession of the key required to validate the signature.  Once b.com validates the signature, it allows the call and if validation fails the call is dropped as spam. This property is critical in fighting spam and denial-of-service attacks.

 

** Background on this blog  **

 

There has been a lot of excitement and interest in the Cisco Intercompany Media Engine since it was announced on November 9, 2009.  To help address the many questions about this product and the topic of intercompany collaboration in general, Wade Hamblin and I from the product team are continuing the Intercompany Collaboration Blog.  Every 2 weeks we post a new blog to the series. View previous blog postings.

We encourage you to ask questions and make this interactive.  Let us know if you want us to dive into any specifics in more detail.

Also, since this is a series we encourage you to subscribe to the RSS feed:

 

 

tap_9s.jpg

I was going to write a lengthy piece to promote the importance of of both Telephony API's and the reinforce the growing trends toward both cloud computing, Web-oriented architectures, VoIP and community-building, but Alex Williams at Read-Write Enterprise did a great job of it here, as a sequel to this. That's why I'd like to launch another theme in support of Recombinant Communications by talking about a concept that should be left behind - if it hasn't been totally abandoned already. That is the "ideal" of "Five 9's".

 

For those of you too caught up in the world of "six sigmas" to remember Five 9's, here's a refresher. It is the bugaboo of every equipment vendor or service trying to win business built on "telco-grade" service level agreements "SLA's". In the bad old days, when all computers and switching systems had to go into those windowless "lights out" central office buildings, prospective purchasers (meaning incumbent carriers) added a little something called "NEBS-compliance" to the mix. Here's a link to the 30-page "quality assurance" document still in use by Verizon to support "NEBS testing". You literally have to set your product on fire and drop it out of a building to provide data on its heat dissipation, fire resistance and seismic tolerances. [It's telling that while the document has a glossary of abbreviations and acronyms covering things like CO, FTTP and the like. NEBS is never defined. FYI: it is an old Bellcore term for "Network equipment-building system" specifications.]

 

NEBS is an artifact of the monolithic communications industry. It was a time when the dominant, incumbent carriers had total control over the pace of innovation and introduction of new services. NEBS testing (and testing in general) often extended the time it takes to deploy new services by a factor of ten. High levels of reliability and availability took precedent over rapid and responsive introduction of new services and applications. The notion of Five 9's comes out of this same school of thought. It refers to the number of significant digits in the measure of computer system and network uptime. Five 9's is 99.999% availability. In any given year (which equates to 525,600 minutes) Five 9's equates to a little more than 5 minutes).

 

Think of that the next time Facebook freezes, Gmail is unavailable, or the "Fail Whale" appears as you try to take a Tweet break. Heck, think of it as you make sense of a slightly mangled transcription of a recently received voicemail message. My point is not to defend such failures, but to point out that we end-users (well, at least my "sample of one") would rather live with these minor mishaps than do without new services altogether. The speed at which new applications and services are introduced and how they evolve over-the-top of IP-based networks is both dazzling and beneficial to end users.

 

Today's world of telco mashups and telephony API's is built on "Four 9's" at best and, in the case of speech-to-text transcription, something on the order of 85% recognition rates (with human intervention as a frequent fallback). On smartphones, mobile apps fail routinely. People are accustomed to dropped calls and the occasional need to "reboot" their mobile devices. In spite of such shortcomings, or perhaps because of them, mobile subscribers feel more attached to their devices than ever before. Going mobile has a more daring, game-like quality to it because of a certain amount of risk-taking and improvisation.

 

As we enter the second decade of the new millennium, mobile mashups are more popular than ever and the world is on the threshold of high adoption rates for voice command, voice search and message dictation. The fun is just beginning. And, in no small way, we owe it all to the End of Five 9's.

Filter Blog

By date:
By tag: