Tag Archives: protocols

Essential protocols and services that support VoIP #3: PoE

Jumping to the other end of the protocol stack, we visit Power-over-Ethernet, which specifies how a switch or other power-sourcing device provides DC power to remote devices, alongside the data, over the network cable.

I’ll let the wikipedia writeup explain the technical details. Essentially, it’s an electrical/wiring protocol, not a data protocol.

Devices at PSU that use PoE include Cisco phones and wireless access points, and probably others. Older Cisco phones, such as the 7910, 7940 and 7960, use Cisco’s pre-standard PoE implementation. Newer phones use the standard IEEE 802.3af implementation.

PoE is not dangerous to devices that do not need power through the Ethernet cable. Power is only sent if the correct resistance is detected, and otherwise is switched off for that port.

Desktop VoIP phones today are typically offered “power brick sold separately.” In a deployment of 15,000 IP phones, we could occupy 15,000 power outlets and waste a lot of money on power bricks, or provide power at the switch port and save wiring and money. Moreover, VoIP equipment in the telecom closets is protected by a UPS, meaning that if the phone is drawing power from the network switch (as opposed to the wall outlet) it benefits from the battery backup as well.

Essential protocols and services that support VoIP #2: DHCP, TFTP and NTP

DHCP – Unless you’re deploying only a few IP phones, you won’t want to configure the endpoints individually. And some phones can’t be configured entirely by hand. (For example, to factory reset and apply new firmware to the Cisco 7906, the only method seems to be to use DHCP, as I describe here.) DHCP provides IP and router information to the device, as well as the following useful options:

  • DNS server list
  • Network time protocol (NTP) server(s), where the device will get accurate time
  • TFTP server, where the device will get firmware and, typically, configuration files
  • Vendor-specific options, such as Cisco’s option 150, which can list multiple TFTP servers

Without DHCP, the aforementioned information would all have to be entered by hand, using the phone’s keypad. On some devices, the IP address information is entered through the keypad and then the phone is further configured using a web or telnet interface.

TFTP – Trivial file transfer protocol has a long history of being used for automatic device configuration. It’s a very simple protocol, neither authenticated nor encrypted, and basically provides commands to upload or download a known file (no “browsing” capability) over UDP. Its simplicity allows it to be embedded into the device so that even without firmware, the loader can use TFTP to get a device image and configurations. The Cisco IP phones also use TFTP occasionally during operation to retrieve ringtone files or background images.

NTP – Network time protocol keeps everything on the VoIP network tightly in sync. Devices that use DHCP for address configuration also get a list of NTP servers as one of the options; servers and other core components have to be manually configured with the addresses of NTP servers. For the phones, NTP is mostly a convenience service that sets the clock that is displayed at the top of the screen. Accurate time on call-processing servers and voicemail is an obvious necessity, especially for correct generation of call-detail (billing) records. Also, when maintaining a cluster of servers and other core devices, troubleshooting problems using time-stamped log files is far easier when the logs are in sync.

Essential protocols and services that support VoIP #1: DNS

VoIP isn’t all SIP (or SCCP, H.323, or other signaling protocol) and RTP (realtime transport protocol; the audio/video media). There are a number of other important protocols and services that make up a functional voice-over-IP service. In a short series of posts, I’ll try to clearly define some.

DNS – Beyond the well-understood function of DNS, which is to resolve a name to an IP address, DNS has become essential in defining what services exist at a domain and how to access them. This is done through the “SRV” record. For example, in my last post, I mentioned that you could send a call over the Internet to a University Park phone by using the address sip:number@psu.edu. Without SRV records, the host psu.edu would have to host a SIP service. Instead of trying to connect to psu.edu on port 5060, a SIP user agent will look in DNS for the SRV records and find

_sip._udp.psu.edu. 43200 IN SRV 20 1 5060 sbc2.phone.psu.edu.
_sip._udp.psu.edu. 43200 IN SRV 10 1 5060 sbc1.phone.psu.edu.

which tells the client to first try sending the call to sbc1 (priority 10) and if that fails, try sbc2 (priority 20) on port 5060. If the SRV record doesn’t exist, it would try sending the call to host psu.edu, which, in our case, wouldn’t be listening for SIP calls.

Another role of DNS in VoIP is ENUM. ENUM basically allows a system to do a DNS lookup of a telephone number and find the SIP (or IAX2, or other protocol) address that can be used to reach that phone number over the Internet. Those familiar with DNS would recognize the format of the NAPTR record as something like the combination of a PTR and SRV record. As an example, MIT allows incoming calls over the Internet and publishes their numbers in the e164.org ENUM registry. A DNS query of their main number, +1-617-253-1000 could be performed like this:

dig @na.e164.biz. 0.0.0.1.3.5.2.7.1.6.1.e164.org. naptr

and would result in this:

0.0.0.1.3.5.2.7.1.6.1.e164.org. 60 IN NAPTR 200 10 "u" "E2U+SIP" "!^+16172531(.*)$!sip:161725311@mit.edu!" .

which tells the caller to use SIP over UDP and the regular expression at the end describes how the address should be formatted. If the calling system supports this, the call can be routed over the Internet using a standard SIP URI.

(By the way, as you can guess from earlier in the post, this will result in another DNS lookup for the SRV record for mit.edu, _sip._udp.mit.edu, which returns the single entry

_sip._udp.mit.edu. IN SRV 0 1 5060 SIP-PROXY-1.mit.edu.)