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 supportinter-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 (example.com) 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, andnot 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 theseproblems by creating a hybrid of three technologies - the PSTNitself, 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.
Ive been asked to start morning checks. I'm looking to use rttest on the router to see the process and opctest status on the PG to sync as well as normal cpu, memory etc. Is there anything else people monitor, recommend? Thanks
I have an agent that goes into the queue, answers a phone call but then will get another call while still on the phone. I can find these instances in agent state details and it shows then as Ready>(Agent gets call)>Reserved>(Agent begins the conv...
Hi all: Have recently deployed CER 12.5.1, and all was working fine until we added a new site. This site has multiple onsite alerts (about 9) that they all state are mandatory to receive telephone and email notifications. We just tested 911 toda...
We are meeting as a group we encounter issues with video with audio when sharing recorded calls. Only one side of the conversation is played by the webex application the calls can be viewed individually and are fine. the host of the meeting can hear both ...