Cisco IME vs. SBC – The SBC strikes back

While Cisco’s Intercompany Media Engine (IME) has received a lot of coverage, it also has detractors who believe the device has “a number of drawbacks” for enterprises looking to federate services.

Objections against the Cisco IME include–

1. IME only works with Cisco CUCM or Session Manager Express (SME) and ASA firewalls – even though Cisco has introduced IME as an IETF spec (ViPR), it will be years before anyone else supports any part of of the IETF specs.

2. Hardly anyone is using IME yet, so there is little to no one to automatically connect to.

3. While federation to other organizations can be automated, in reality most IT managers do not trust these connections and will end up doing lots of manual provisioning anyway.

4. IME security has yet to be proven – a firewall cannot perform all the security tasks needed for an UC service that traverses the internet. Cisco uses the CUBE (their SBC), not the ASA firewall for all of its SIP trunking deployments so it is unclear how much security they provide.

5. Extra licenses and hardware are needed;more CAPEX for Cisco products and OPEX to support them.

Of course, the summary argument provided by the SBC camp is–

“Enterprises looking to federate can peer with each other today using their existing SBCs to avoid all of the issues above… SBCs are also used for hosted UC services, remote workers, and even for internal security borders so they will exist even if there was no PSTN and everyone was federating.”

The argument presented above doesn’t address the issues that makes the IME so compelling: Enterprises aren’t federating and the process to federate is not automated or seamless.  When federation is not automated, it does not scale on a 1 to N basis, where N gets big quickly.

Be Sociable, Share!

Comments are closed.