Thursday, September 3, 2020

How Modern Enterprise Communications Work? (Part 1 of 4)

Overview :

This blog uncovers the journey of modern day telecommunications from its very inception. It also discusses how Enterprise Collaboration is playing an integral part during COVID-19 as a technology. Thus, it is perfect for anyone who is planning to start a career in Voice over IP, Telecom, PSTN systems, video conferencing services and other similar industries.

After going through Part 1 of this blog, you will be able to:

• Define Communication – Collaboration from an Enterprise Standpoint.
• Understand the Scope of Enterprise Telecommunications.

Part 2 of this blog will make you understand and appreciate how telecommunications evolved and transited from its inception to Analog Telephony(POTS). The pointers covered are:

• Switching and its evolution.
• Analog Telephony (POTS).

Part 3 of the blog discusses transition of POTS to ISDN and then to VoIP:

• Transition from Analog to Digital Telephony (ISDN).
• Transition from Digital to IP Telephony (VoIP).
• VoIP and Unified Communications.

Part 4 discusses different VoIP protocols and what powers modern day Voice, Video and Conferencing technologies. Pointers covered are:

• Protocols & Concepts (POTS, T1/E1 - CAS & CCS, SIP, H.323, MGCP. H.264, BFCP, RDP, XMPP, WebRTC, STUN, TURN, ICE, STIR and SHAKEN).
• Unified Communications as an Industry and what the Future offers.
• Conclusion.

(NOTE: The terms Telecommunications, Communication and Collaboration have been used interchangeably throughout this blog)

Let us Begin :

We at tcplabs believe that the 3 basic questions that any Engineer should ask before choosing a technology as a career or job Role are:

What
Why
How

Figure 1.a. The 3 Basic Questions from an Engineer’s Perspective

In Part 1 we will focus on the major Whats and Whys that arise around Modern Enterprise Communication.

What is Communication ?

According to Google -

Figure 1.b. Communication Googled

The key words here are “information” and its “exchange”.

Consider an example.

There are several ideas, we can think of, to deliver INFORMATION on this blog and make it interactive, like a YouTube Video, an In class Session, a Zoom Conference Session under a Tree somewhere 😊 etc. However the EXCHANGE of information becomes possible only when there is a dialogue between the Sender and the Receiver in some form, like the comments section under the YouTube Video or Questions posed by students in a classroom setting or even on a Virtual Zoom Classroom. You may want to leave a comment on this blog under the comments section and tell us how you liked this Blog, which is again an example of EXCHANGE of INFORMATION.

Communication is sort of Boring unless it bears some good results for a common cause. Now, to bridge the concept of Communication to Collaboration – Try a fruitful exercise with someone you know to achieve a common goal by Communicating with them… Collaboration achieved.

Modern day Enterprises leverage Collaboration to achieve Common Goals and thus the term Enterprise Collaboration is born.

What is the World Doing with Enterprise Collaboration today ?

With the far reaching affects that COVID-19 had on the world, Governments leveraged Enterprise Communication and Collaboration tools in a recent G20 Virtual World Summit.

Figure 1.c. The G20 Virtual World Summit leveraging Enterprise Collaboration

Why do you think this Summit was organized Virtually ?

How do you think this would have worked ?

The Answer is simple - To achieve common goals for the Betterment of the World Via Enterprise Collaboration Technologies.

Today’s Situation With

COVID-19

Figure 1.d. The Buzz around Enterprise Collaboration

COVID-19 has changed the Enterprise Telecommunications and Collaboration scenario over the past 7 months. With more and more Enterprises adopting and promoting Remote Work, there has been a sharp rise in the Job Marketplace and the overall development of the Collaboration Technologies. In fact, Collaboration today is shaping the world in many ways. Several major organizations like Google, Facebook, Amazon etc. have shifted to remote work where ever possible. India’s National Informatics Center (NIC) and the PMO is utilizing VC as primary mode of communication for Cabinet and Federal Meetings. Another major example is the National Institutes of Health (NIH) in USA, one of the primary places for COVID-19 vaccine drug research utilizes Collaboration Technologies and Tools to share information and spread intelligence and awareness about COVID-19 Vaccine.

Some other use cases include :

• Education and Learning Management Systems
• Broadcasting and Media
• IT
• Software Development
• Industrial Production
• Health Care and Insurance
• National Defense

and the List goes on.

What does Communication/Collaboration in Modern Enterprises look like ?

Figure 1.e. The Modern Enterprise Collaboration Portfolio

Today’s Enterprise Collaboration Portfolio has Devices and Services which meet all kinds of demands and necessities for successful execution of entrepreneurial goals. Ranging from apps running on Hand-Held Devices to those huge Video Conference Room Equipment. From Capex Services to Services with Pay as you go models, there is a plethora of available options from a Procurement Perspective as well.

CapEx vs OpEx :

CapEx refers to a Capital expenditure while OpEx refers to an Operational expenditure. Capital expenditure is incurred when a business acquires assets that could be beneficial beyond the current tax year. For instance, it might buy brand new equipment or buildings. Also, it could upgrade an existing asset to boost its value beyond the current tax year. CapEx is also known as a Capital expense.

Operational expenditure consists of those expenses that a business incurs to run smoothly every single day. They are the costs that a business incurs while in the process of turning its inventory into an end-product. Hence, depreciation of fixed assets that are used in the production process is considered OpEx expenditure. OpEx is also known as an operating expenditure, revenue expenditure or an operating expense.

What Tech is trending ?

Figure 1.f. The Trending World of Collaboration Tools

In today’s era of World Trends, Collaboration Tools clearly emerge as one of the winners if compared with Data Analytics Tools, Programming Tools, Cloud Computing Tools and for that matter Automation Tools which show a downward trend (green line) vs Collaboration Tools (yellow line) which shows an upward trend.

If you have come this far reading this Blog, you may be wondering Why go ahead and read more?

Well, if knowledge is something you want and if you are wishing to work in an industry that will last through a pandemic like COVID-19, you should really do the math. Else the following numbers should get you going:

Figure 1.g. Numbers and Salaries - Courtesy - Global Knowledge

What is the Scope of Engineering in Enabling Communications in Modern Enterprises ?

There are a lot of moving parts in an Enterprise Collaboration environment. This may comprise of Desk phones, Conference Meeting Rooms, Whiteboards, Chat Clients, Paging Systems, Emergency Dialing Systems, Contact Center Systems, ChatBot Automation, PBX and Switches etc. To make all these pieces work in Synch together, it takes Engineering and Project Management Excellence right from Project Inception to Implementation and then to Maintenance and Ops. Today, even Data Analytics is an integral part of taking Business Decisions on what technology to adopt and what to discard in a Unified Collaboration (UC) Environment. Some common Engineering Practices involved are:

• Systems Development Engineering.
• Software Development Engineering.
• Security Engineering.
• Operations and Support.
• Overall Program Engineering Management.

Well, you might be wondering where the term UC came in from… Unified Collaboration or UC is a combination of enterprise collaboration tools assembled into a single interface and integrated into a single management system. UC makes an enterprise more connected, efficient, and productive to achieve their Goals.

A typical set of UC products includes a variety of communications and collaboration tools including:

• Email and voicemail
• Calendars and scheduling
• Voice and telephony
• Real-time communications
• Web, voice, and video conferencing
• Instant messaging

So, really the SCOPE = UNLIMITED.

Before we end Part 1 of this Blog, we want to give you an idea of what is next.

In Part 2 of the Blog, we travel back in time and see how the Switching Technology Evolved the initial generation of Telephonic Devices. We will also understand how Analog Telephony operated. In Part 3 of the blog we will analyze IP Telephony that drives Modern world Collaboration.

Figure 1.h. Mr. Alexander Graham Bell making the first ever Telephone Call

Listen to Mr. Alexander as he makes the first phone call in human history -


*****

For feedback, suggestions, or corrections, please leave us a comment below.

Join the tcplabs’ Collaboration Webex Teams Space here: https://eurl.io/#ByElUITFN

References:
https://www.google.com/
https://www.globalkn … lary-report/#reports
https://www.cnn.com/ … ronavirus/index.html
https://americanhist … itions/hear-my-voice

Friday, March 29, 2019

TCPLABS Collaboration - 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:

50.1.1.10

In case of Polycom phone registering to a Lync2013 or Skype for Business server, this is governed by the SIP Server Configuration which can be setup to Auto for automatic discovery using Skype for Business SRV records. If Skype for Business is not configured for auto discovery, then we can select Specify and then specify the Registrar Server in the form of a DNS name of the Skype for Business Front End or Director.

A typical example of SIP Registration using a Cisco IP Phone is as follows:


SIP REGISTER

Figure 9.a SIP Register


SIP 100 TRYING

Figure 9.b SIP 100 Trying


SIP 200 OK

Figure 9.c SIP 200 OK

NOTE: There are scenarios when SIP may use an Auth Challenge mechanism to ensure that the SIP REGISTER is coming from a trusted Phone:

Figure 9.d SIP Auth Challenge

Skinny Registration (SCCP): As of writing of this text the Cisco Proprietary SCCP still exists and thus the following shows an example of a Cisco SCCP Registration:

Figure 9.e Cisco SCCP based Phone Registration


*****

For feedback, suggestions, or corrections, please leave us a comment below.
Join the tcplabs’ Collaboration Webex Teams Space here: https://eurl.io/#ByElUITFN

References:
https://www.ieee.li/ … _802.3af_802.3at.pdf
https://tools.ietf.org/html/rfc3665
https://documents.po … ce_group_series.html
https://www.cisco.co … -dhcp-multintwk.html
https://learningnetw … co.com/thread/118328
https://community.po … ad-Upgrade/td-p/4203
https://documents.po … pe_for_business.html

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.