- 10 ways the Chinese Internet is different
- Hacker writes rootkit for Cisco's routers
- Verizon snares $678 million federal network deal
- Cisco loses $2 million order to Nortel
- HP buys EDS for $13.9 billion
Most companies have a solid disaster recovery plan in place to handle a "complete failure" of its Active Directory, which is really quite rare. What most recovery plans are missing, and the most common scenario, is a means to efficiently restore single directory objects. In this paper, we'll explore what most disaster recovery plans already address, highlight potential weak points, and suggest solutions that help fill those gaps-without requiring you to completely re-do your existing plan.
Get the latest on storage technologies that allow IT professionals to better cope with new IT demands. Learn how storage technologies can help you successfully tackle e-Discover, regulatory compliance, green data center initiatives and the data explosion. Get all the details now.
Watch Raven Zachary, Research Director for Open Source at the 451 Group, an independent IT analyst firm, discuss the emergence of enterprise Linux and the role of Oracle Unbreakable Linux support.
We didn't just take a sip. We took a good long drink of SIP technology in this round of iLabs testing.
We gathered more than 50 devices from five SIP server vendors and 13 SIP endpoint vendors to prove that multi-vendor SIP telephony deployments are possible. Our results show that while basic SIP interoperability is outstanding, advanced features such as call forwarding and conferencing might not work so smoothly between all SIP devices.
Protocol simplicity is an argument in favor of SIP over the more complicated H.323 VoIP standard. This simplicity minimized interoperability problems and made device configuration easy. Compared with previous iLabs tests involving H.323, SIP let us connect more devices to more servers more quickly. With the exception of an older device an engineer brought from his own network, all SIP endpoints passed our basic call tests.
We defined our telephony environment in the context of a midsize company wanting to build a SIP-based VoIP system from the ground up. Designing a VoIP network is much like designing a LAN : You have to plan all aspects, from numbering of phones and IP addresses, to setting up services such as voice mail and call conferencing, to enabling voice encoders, to naming devices.
One of the first VoIP planning steps is setting up the dial plan (see "Dialing for VoIP dollars" ) that defines how long phone numbers are, how gateways to the public switched telephone network (PSTN) are addressed and how the internal network is divided between SIP servers.
In a traditional telephony environment, the dial plan is built into the PBX. In a SIP network, the dial plan has to be configured on all phones individually. If you don't program the dial plan into the phones, end users will either wait for the phone to "time out" when dialing or hit a terminator character (the pound sign is common) when they're done to get the phone to dial (like hitting "send" on a cell phone).
Because of the expanse of our SIP test bed, we had a fairly complex dialing plan and found that not every phone could support that. On our network, users could dial phone-to-phone with a four-digit extension. But to dial through to the PSTN, Interop's eNet or Free World Dialup SIP service, they'd use single-digit prefixes, such as "9," followed by a number on the other network. A number of SIP endpoints couldn't handle that much flexibility. With those phones, we put in a maximum number of digits - 19, to be exact - and use timeouts or terminators when dialing. It's hard to say whether this is an interoperability problem or just poor design.
With dialing plan in hand, we installed the five SIP proxy servers, open source Asterisk (from Digium) and SIP Express Router (SER, from iptel.org), and commercial products from Avaya, Cisco and Nortel. Each SIP server had to support a number of phones and be able to send calls to the other SIP servers. We took the 40-plus phones and assigned each to one of the SIP servers (see graphic ) so that each phone registered with only one SIP server and that server was responsible for routing any SIP calls for that phone.
When we achieved 100% interoperability between SIP servers using direct dialing, we threw a monkey wrench into the works by adding an Enum dialing test. An international proposal on how to link the Internet VoIP and PSTN worlds together using DNS Enum currently is mired in political infighting in the U.S. However, the concept of Enum can be applied at the enterprise level in a private DNS tree. For the SIP servers that supported Enum - Asterisk and SER - it worked well.
Once we had basic connectivity working, we dumped all the phones on the different SIP servers to test interoperability within each SIP server. We had a few problems getting the phones installed as the number of them stressed our team from an installation and a testing standpoint.
Most of the phones we tested were SIP "hard phones," generally managed using a Web-based interface. We installed phones from Avaya, Cisco, Grandstream Networks, ipDialog, Pingtel, Polycom, Pulver Innovations, Siemens and Snom Technology. We also tested soft phones from Xten on Windows and Mac OS X platforms, and FXS gateways (see "SIP terms" ) from AudioCodes, Cisco, D-Link Systems, MIP Telecom and Multi-Tech Systems.
When it came to simply calling from phone to phone through the same SIP proxy server, we achieved nearly 100% interoperability. Of the 230 test cases, only seven were not resolved by some reconfiguration in our testing, coming down to two very specific combinations of phone plus SIP proxy (ipDialog phone on SER SIP proxy and Polycom phone on Avaya SIP proxy). The most common problem we saw was phones that connected to each other, but didn't have audio reception.