How Cisco’s IME Technology Will Change the Way We Communicate
In my last post, I discussed a new Cisco technology called Intercompany Media Engine (IME), a pseudo cloud solution that is run and maintained by Cisco. IME’s sole purpose is to gather and relay information about isolated CUCM platforms in order to create a federation bridge.
Cisco calls this their IME Network; the company envisions this will one day become a global exchange of information between organization’s CUCM platforms. It’s not dissimilar to the PSTN where ANI’s are used to route between the private LEC’s; the difference is that ViPR uses IP routes and the Internet to facilitate cheaper, more enriched collaboration across what used to be company boundaries.
How IME works
Let’s say I’m calling Chad, one of my contacts at ABC Company, from my desk phone at IT service provider SWC. (This could be any of my communications agents, i.e., Video Conferencing (VC) solutions, IM client, mobility client, etc.) If we’re both running CUCM 8.0 with IME servers, when I dial him, my call routes out over the PSTN, he picks up, we have a conversation. No big deal, right?
On the surface, yes. But at the same time our conversation was taking place, another transaction was occurring: a SIP trigger was sent to the IME Network cloud. Because of this trigger, the IME Network recognizes both of us as IME Network participants and works with our IME servers to create a new secure path for us via the Internet. So when Chad calls me back 10 minutes later, his call doesn’t go over the PSTN circuit, it goes out through his company’s data circuit to me; my phone rings and voila! We’re talking securely (encrypted) with QoS over the Internet. It was seamless, transparent and fast—we didn’t have to do a thing.
This is the power of IME.
But let’s say I wanted to escalate the call to video and include my esteemed colleague Adam. He and I go to our meeting room and fire up the VC and call Chad at the same phone number (I forgot to mention Chad’s a big wig with his own camera/VC setup). IME works its magic and just like before, we’re securely running voice and video over the Internet. IME even negotiates the codecs for us. I can include local resources like “share my desktop,” or “pull in files from intranet portals” with no worries.
Now let’s say next week I call Chad, but on this day, Adam is having a VC, or some of Chad’s people are sharing CAD files, and there is some bandwidth saturation. IME recognizes that QoS can’t be maintained, so it routes the call back over the PSTN. IME can re-route an active call over the PSTN if unsuspected congestion should occur as well; this is dynamic and seamless to both Chad and myself.
Let’s change the scenario a little. Let’s say that after Chad and I have peered, Chad calls my colleague Bob. This call would go over the PSTN because Bob and Chad have not made a peer connection in the IME network—just because Chad and I are peers in IME doesn’t mean that Chad and Bob are. After the initial call between them, their next exchange would be routed by IME. Cisco has put in safeguards to protect against both spamming and DoS. One other safeguard worth pointing out is peer associations expire (this is set by company policy).
This is just the cliff-notes version of IME; I’ll be writing more about it in the coming weeks. What do you think of this new technology? How do you envision it working for your Chicago business?