Friday, March 29, 2019

TCPLABS Collaboration - Phone Boot Up and Registration


IP Phone Boot Up and Registration

Overview:
This blog covers the registration sequence of an IP phone, (NOTE: The term IP phone will be used interchangeably with the term phone unless otherwise specified) to its Registrar Server using the different flavors of the Session Initiation Protocol (SIP). There is a discussion later in the blog on the older SCCP protocol (Cisco Proprietary Protocol) based Phone Registration as well.

IP Phone Registration:

An IP Phone in itself, is a dumb device and if on a network, needs to be Registered to a Server. Mostly we call the server a Registrar server. This Registrar Server keeps a track of all the Phones and endpoints registered to it besides other functionalities that the Server may have.

The Phone Registration process (Referred to as the Phone Bootup Process sometimes) follows the classic Client-Server Architecture right from the moment the Phone is powered on. The Best way to memorize this process is :

P – Peacocks
B – Become
C/L – Comfy/Lazy (Depends on whether CDP/LLDP is being used)
D – During
T/F – Tremendous/Frantic (Depends on whether TFTP/FTP is being used)
R – Rains

Here we go Step by Step:

1) P – (Power UP):

Every Phone needs power to perform the various functions it is intended to. A phone can be provided power primarily by the following ways:

PoE: It is a common misconception that Power cannot be forced down a cable. Rather Power over Ethernet is one of the primary modes of delivering power to an IP Phone. Some PoE advantages include time & cost savings, flexibility, safety, reliability, scalability. A typical POE scenario consists of a PSE (Power Sourcing Equipment) and a PD (Powered Device). In the older IEEE802.3af standard, PSE would transmit power over 2 pairs (4 out of 8 wires) on a Cat5/5e/6 cable. IEEE 802.3af-2003 standard version of PoE supplies upto 15.4 W of DC power. Only 12.95W is assured to be available at the PD as some power is dissipated in the cable. While in the newer IEEE 802.3at, at least 24 W power is supplied to the PD. Here are the 3 different options available:

a. PSE End-Span: Power originates from a powered port on an Ethernet Switch and is super-imposed on data transmission wire pairs 1,2,3, and 6

Figure 1.a PSE End-Span

Figure 1.b PSE End-Span (Ckt. Diagram)

Note: The PD presents a load to the cable and draws as much as it needs. This is achieved by using FLPs (Fast Link Pulses) sent from the Tx end of the PSE to the Rx end of the PD. Most PoE powered devices will draw a fixed level of power. This is done using a Relay on the IP Phone which is a Low Pass filter (LPF), the information is relayed on a Data Link Protocol (eg. CDP/LLDP).

b. PSE Mid-Span/Power Injector: Power is added to the non-data wire pairs 4,5,7, and 8 from a patch-panel style hub.

Figure 2.a PSE Mid-Span

Figure 2.b PSE Mid-Span (Ckt. Diagram)

c. Splitters for PoE: Active PoE Splitters allow PoE power on non-PoE devices

Figure 3.a PoE Splitters

Figure 3.b PoE Splitters Powering a Cisco Non-PoE PD

Power Bricks: The other common way to power IP Phones is by using Power Bricks which look something like this:

Figure 4. Power Brick

Use this option only if there are no PoE options are available and avoid cabling hassles.

Example Commands to check power on various switches:
Cisco: show switch power inline
HP: show power-over-ethernet A7 (where A7 is the port#)

2) B – (Bootstrap Loader):

Every IP Phone runs an operating system on its hardware. Mostly it is a customized version of Linux by the IP Phone Vendor. It is like a BIOS which will initialed the basic device drivers and then execute the startup image on the device. Eg. In Cisco IP Phones, the phone runs the bootstrap loader that loads the existing phone firmware image stored in the flash memory which is identified by the Boot Load ID on the phone. Similarly in Polycom IP Phones, the BootROM software initiates the Bootloader.

3) C/L – (CDP/LLDP):

After the phone boots up, depending on the switch type, the switch locks the port to which the Phone is connected to one protocol (CDP or LLDP). The switch locks to the first protocol (Containing the TLV – Threshold Limit Value that the phone transmits). The Cisco IP Phones use CDP to communicate information such as auxiliary VLAN ID, per port power management details, and Quality of Service (QoS) configuration information with a Cisco Catalyst switch.

Polycom phones generally use LLDP/LLDP-MED. If the phone discovers any of the following VLAN types in LLDP data from the network switch, the Polycom Phone automatically configures itself for one of them. The chosen VLAN type is based on the order of precedence, as follows:

  • Video Conferencing VLAN
  • Voice VLAN
  • Voice Signaling VLAN

If none of the above VLAN types are found, the phone configures itself for the default or native LAN of the switch port to which it is connected.

LLDP-MED enables the following information discovery for Polycom phones:

  • Auto discovery of LAN policies enabling plug and play networking.
  • Inventory management, which allows network administrators to track their network devices.

This is what a CDP Wireshark capture looks like for Power Requested and Power Consumed along with a VoIP VLAN query being fulfilled:

Figure 5. CDP Wire Capture showing Power Consumption and VoIP VLAN Query

4) D – (DHCP - Dynamic Host Configuration Protocol):

The DHCP allows process allows the IP phone to receive an IP address from a DHCP server configured in the network based on the use of a Relay Agent. A DHCP server is able to provide addresses from the appropriate scope based on the use of the Relay Agent field in the DHCP packets.
A Relay Agent is the agent that is in charge of the conversion of the broadcast DHCP packets sent by the telephone into unicast packets that are sent to the DHCP server. This agent also converts the unicast DHCP packets sent from the DHCP server into broadcast packets that are sent on the telephone network.

When the DHCP server receives the DHCP discover message with a current IP address in the Relay Agent field, it uses that address to match the proper scope and assigns the IP address from it.

The DHCP packets that are exchanged in a typical (DORA process) would be as shown:

Figure 6.a DHCP DORA using Relay Agent

The blue lines show the DHCP packets that are sent to and from the IP telephone. These are the only packets that appear if the DHCP server is in the same Ethernet network as the telephones. The black lines represent the DHCP unicast packets that the Relay Agent transmits to and from the DHCP server.

This table shows the details of the packets for this example:

Figure 6.b DHCP Discover

Figure 6.c DHCP Offer

Figure 6.d DHCP Request

Figure 6.e DHCP Ack

Typical DHCP & Relay configuration on Cisco Switch:

router(config)# ip dhcp pool VOIP
Network 10.10.10.2 255.255.255.0
Default-router 10.1.1.1
Option 150 ip 10.1.1.1 – (Discussed in Step 5)

router(config)#interface FastEthernet0/0
router(config-if)#ip address 10.10.10.19 255.255.255.0
router(config-if)#
router(config)#interface FastEthernet0/1
router(config-if)#IP address 11.1.1.19 255.255.255.0
router(config-if)#IP helper-address 10.10.10.2
router(config-if)#

Typical DHCP Relay configuration on an HP Switch:

interface Vlan-interface13
ip address 192.20.5.246 255.255.254.0
dhcp select relay
dhcp relay server-address 192.20.2.19
dhcp relay server-address 192.20.2.20

NOTE: It is not always true that the DHCPOFFER and DHCPACK will be broadcast packets. A unicast mode can be used by the DHCP Server to send out DHCPOFFER and DHCPACK. If the DHCP Server can clearly see the client’s MAC address from the DHCPDISCOVER and the broadcast flag is set to 1, then DHCP Server will use a Broadcast mode. If the flag is set to 0, then it uses Unicast Mode. It is important to mention here that Unicast mode is not recommended when DHCP relay is in use. But if the DHCP Client and Server are on the same network segment then it is perfectly okay to use Unicast mode.


Broadcast Mode (Discover)


Broadcast Mode (Offer)


Unicast Mode (Discover)


Unicast Mode (Offer)

Common Debug commands on Cisco platform:

Debug ip dhcp server packets/events

5) T/F – (TFTP/FTP):

We by now have realized that an IP Phone is a dumb device and we have been making the Phone become intelligent by letting it have an

1) Providing it power
2) Booting it up
3) Getting it on a VLAN
4) Getting it an IP address
to communicate on the network.

Once the phone receives an IP address, it needs a mechanism which can make it perform its functions in a certain way using certain information. For example, how would a Phone know that it has a 10-digit phone number assigned to it, or it is being controlled by a Certain Registrar Server (we discussed earlier), or it has certain softkeys on it.

This intelligence is provided to an IP Phone using a configuration file which is generally of the form .xml (sometimes this file can be .xml.sgn or .cfg, unsigned or signed by a Certificate Authority). The question comes now, how would the phone know where to request its .xml from. The answer to this lies in Step 4. Aka DHCP. There are certain options which are configured on the DHCP Server like OPTION 150, OPTION 66 etc. which tell the phone the IP address where they can request their configuration files from. In other words these options provide IP addresses of their TFTP/FTP servers.

Figure 7. TFTP Read Request followed by Block based .cnf.xml file transfer

NOTE: Polycom Phones delivered from factory are pre-configured to be using DHCP Custom DHCP OPTION 160/161 (If ordered as LYNC SKU) and then Option 66 to inform themselves of a potential Provisioning Server.

This is what a typical IP Phone configuration file for Cisco Phones look like:

Figure 8. Cisco Phone Configuration File Example

6) R – (Registration):

Now we come to the most critical part of this topic. This is where the actual Application Layer Protocol based registration completes. Since we are discussing the Standards SIP protocol, we will begin with what happens after the Phone receives the configuration file.

In the configuration file example in Figure 8, the following attribute dictates where the SIP REGISTER messages, initiated by the phone will be directed to:

This blog is proudly powered by FlatPress.