VOIP Tech Blog » voip

VoIP and SRST/AES Encryption!

DrVoIP — Tue, 05 May 2009 23:50:35 +0000

Encryption of VoIP traffic was, for some of us a humorous concept. I remembered as a young development professional how much fun it was to use a packet sniffer to capture the bosses packets and reassemble his email over the LAN. Years before that when I worked at the phone company as a central office test engineer, it was not uncommon to find an interesting phone call and plug it into the over head paging system to provide entertainment for the late night test crew. There are times I still think the concept of encryption on VoIP is humorous, but it is becoming less funny all the time as we move toward end to end VoIP with no TDM at all in a world populated by terrorists and other evil doers. In any VoIP environment today, you can at some point use the usual tapping tools to capture a phone call as it hits the TDM gateway and is converted from VoIP to traditional analog or digital signals. From an induction coil to a line mans butt set, you can still intercept a VoIP call as it crosses the TDM boundary.

Now that VoIP is being used end to end, we do need to have a mechanism for encrypting at least the media stream. Today we generally do that with SRTP and IETF standard in combination with AES. AES or the Advanced Encryption Standard was adopted by the US Government and comprises three block ciphers: AES 128, AES 192 and AES256. Each AES cipher has a 128 bit block size with key sizes of 128, 192,and 256 respectively. This standard has generally replaced the former Data Encryption Standard or DES. It is important to understand the difference between encryption and authentication. Determining that a signal is “authentic” and originated from a source we believe to be authentic, and encrypting the contents of that communication are two very different issues. Media authentication and encryption ensures that the media streams between authenticated devices (i.e. we have validated the devices and identifies at each end) are secure and that only the intended device receives and reads the data. We need to encrypt both the media (i.e. the voice) and the signaling information (i.e. the DTMF). In most VoIP systems today, SRTO or secure RTO is implemented to assure media encryption. Understand that this encryption is not passed through to the TDM network, so once the media stream leaves the VoIP environment it is subject to eavesdropping.

Clearly as we are now able to employ VoIP end to end, SRST/AES encryption has very powerful ramifications for both the good guys and the bad guys!

VoIP and SRST/AES Encryption! is a post from: VOIP Tech Blog

VoIP and Microsoft Outlook Integration?

DrVoIP — Thu, 16 Apr 2009 00:45:19 +0000

Does your Microsoft Outlook Integrate with your phone system? This functionality is getting to be the “minimum daily adult requirement” feature in the VoIP vendor space. We all just expect that our phone system “knows” about our “contacts”. We don’t dial phone numbers anymore! We enter Names and the phones system gets the number out of our contact list and places the call. Often, an incoming phone call to our desktop, will cause our contact information to be displayed. Some integrations enable your phone system to change user profiles and call handling modes based on your Outlook contact. Of late I have been wondering how far this integration can go? I mean, if I have a conference call scheduled in my Microsoft Outlook, shouldn’t the phone system know about that? My thinking is the phone system should just call me and remind me of the conference and then ask me to approve joining the meeting!

VoIP and Microsoft Outlook Integration? is a post from: VOIP Tech Blog

LLDP-MED speeds ShoreTel VoIP installations!

DrVoIP — Mon, 30 Mar 2009 18:16:39 +0000

Using a VoIP phone system and installing one, are two entirely different user experiences! Most product development efforts focus necessarily on end user features and benefits. Anyone who has ever installed a VoIP system knows that if design engineers ever actually installed a system we would have a range of exciting new configuration automation tools! Case in point: LLDP. Until version 9, ShoreTel IP phone deployment was a two step process. First you would install your handsets on the net and they would boot up in the native VLAN. If you were deploying 100 desktops, this meant that the phones would eat up 100 of your native VLAN DHCP leases. The phones would then obtain their VLAN tag and reboot in the correct VLAN. The native VLAN lease damage, however was already done, not to mention waiting for that second boot DHCP broadcast request for service. A number of vendors had previously create proprietary discovery protocols to overcome this behavior. CISCO has always had CDP,( not to be confused with Enterasys Cabletron Discovery Protocol); Nortel had NDP; Extreme Networks had EDP and Foundry had FDP. In 2005 an industry standard, LLDP was adopted and later modified to become LLDP-MED or Link Layer Discovery Protocol for Media Endpoint Devices. ShoreTel, rather than event yet another vendor proprietary protocol has adopted this industry standard greatly simplifying IP phone deployment. LLDP-MED allows network devices to advertise their identify and capability through a multicast. This enables the phones to come up on the network in the correct VLAN, eliminating the multi-boot requirement. Now this is not a feature that an end user will notice or appreciate, but those of us who have to spend hours deploying VoIP desktops say Cheers!

LLDP-MED speeds ShoreTel VoIP installations! is a post from: VOIP Tech Blog