Showing results for 
Search instead for 
Did you mean: 
Walkthrough Wednesdays

Cisco Intercompany Media Engine for Dummies Section 1: SIP Alone Doesn’t Cut It

Cisco Employee


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, Wade Hamblin and I from the product team will post a “for Dummies” blog every 2 weeks to explain the basics and help you understand what it is, how it works, and why you should care. This particualr series is slightly detailed insight into the working of the IME. We encourage you to ask questions and make this interactive.

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


Session Initiation Protocol (SIP) has seen widespread deployment within individual domains, typically supporting voice and video communications.  Though it was designed from the outset to support  inter-domain federation over the public Internet, such federation has not materialized.  There are many reasons as to why we haven’t seen widespread adoption of inter-domain SIP federation namely:


Phone number routing Problem:

Inter-domain federation requires that the sending domain determine the address of the receiving domain, in the form of a DNS name ( or one or more IP addresses that can be used to reach the domain.  In email and in the web, this is easy.  The identifiers used by those services - the email address and web URL respectively - embed the address of the receiving domain.  A simple DNS lookup is all that is required to route the connection.  SIP was designed to use the same email-style identifiers. However, most SIP deployments utilize phone numbers, and not email-style SIP URI.  This is due to the huge installed base of users that continue to exist solely on the public switched telephone network (PSTN).  In order to be reached by users on the PSTN, and in order to reach them, users in SIP deployments need to be assigned a regular PSTN number.  Finally, a large number of SIP deployments are in domains where the endpoints are not IP.  Rather, they are circuit based devices connected to a SIP network through a gateway.  SIP is used within the core of the network, providing lower cost transit, or providing add-on services.  Clearly, in these deployments, only phone numbers are used.

Consequently, to make inter-domain federation incrementally deployable and widely applicable, it needs to work with PSTN numbers rather than email-style SIP URI.  Telephone numbers, unlike email addresses, do not provide any indication of the address of the domain which "owns" the phone number.  Indeed, the notion of phone number ownership is somewhat cloudy.  Numbers can be ported between carriers. They can be assigned to a user or enterprise, and then later re-assigned to someone else. Therefore, in order to deploy inter-domain federation, domains are required to utilize some kind of mechanism to map phone numbers to the address of the domain to which calls should be routed.  Though several techniques have been developed to address this issue, none have achieved large-scale Internet deployments and none of the techniques validate the ownership of a phone-number.

Open pinhole Problem:

The inter-domain federation mechanism built into SIP borrows heavily from email.  Each domain runs a SIP server on an open port.  When one domain wishes to contact another, it looks up the domain name in the DNS, and connects to that server on the open port.  Here, "open" means that the server is reachable from anywhere on the public Internet, and is not blocked by firewalls.

This simple design worked well in the early days of email.  However, the email system has now become plagued with spam, to the point of becoming useless.  Administrators of SIP domains fear - that if they make a SIP server available for anyone on the Internet to contact, it will open the floodgates for VoIP spam that will create a back-door for denial-of-service and other attacks that can potentially disrupt their voice service. Fears around spam and denial-of-service attacks, when put together, form the "open pinhole problem" - that domains are not willing to enable SIP on an open port facing the Internet.

To fix this, a new model for federation is needed - a model where these problems are addressed as part of the fundamental design, and  not as an after-thought.

Cisco Intercompany Media Engine (IME) is a new technology that is aimed at solving the problems that have prevented large-scale Internet-based SIP federation of voice and video. Cisco IME solves these  problems by creating a hybrid of three technologies - the PSTN  itself, a Secure P2P network, and SIP.  By combining all three, IME enables a unique incrementally deployable solution to federation.


More about how IME overcomes these challenges – watch for it week of December 14.


Maybe this is a basic question, but how does the FCC or other government bodies view this method of communication between companies bypassing the PSTN as much as possible? I realize countries like India can be blocked but are there any legal ramifications within the US of performing B2B communications through the Internet?

Also while I am aware that service providers are working closely with Cisco on this solution if more of the traffic shifts to the Internet away from PSTN, will carriers adopt their pricing models to accordingly increase internet rates thereby nullifying IME advantages much like how cell phone carriers increase data/text plans as traffic shifts from voice to data?

Cisco Employee

In some countries it is regulated while in US and Australia and Europe it is not. The evualtion needs to be done country by country but as the regulations stand today, it is allowed in most of the countries. India being an exception for example.

The hope is that SP's will modify business plans to take advantage of newer business models and serivces that IME enables.

Content for Community-Ad

Spotlight Awards 2021