Friday, September 4, 2020

The Verkada-X-perience - Welcome to Modern Physical Security

Overview :

Physical Security (PhySec) is a technology that provides security measures that allow or deny access, to a facility, equipment, or resource, depending upon different authorization levels. Although PhySec is an integral part of the CIA TRIAD, as a technology, has seen significant changes in how we perceive and engineer it.

So we at tcplabs finally gave Verkada (https://www.verkada.com/) a try.

Call it the new “God Mode” in the world of Video Surveillance-as-a-Service. This best in class solution with beautifully coupled IP Cameras, totally removes the need for a DVR/NVR type setup for customers.

TESTING 1…2…3… :

We tested two of Verkada’s Dome Type Cameras and were amazed to see what they can do:

• D40 – The Indoor Dome Camera.

Figure 1.1 Specs - D40 Mini Dome Camera

• D50 – The Outdoor Dome Camera.

Figure 1.2 Specs - D50 Outdoor Dome Camera

Lets begin with the login to the Command Control:

Login:

https://command.verkada.com

Create an account and Sign in -

Figure 1.3. Create Account and Sign in

Configure Settings :

Account Basics -

Figure 1.4. X-perience Simplest UI for Account Creation

NOTE: We have chosen to not enable Two-factor Auth but you can enable it using any two factor authentication application like Google Authenticator.

Notifications -

• You can configure notifications via SMS/Email for Tampering Detection, Camera going offline and for Camera Motion events.

Figure 1.5. X-perience Notifications

Role Based Access & Control -

• Users can be managed in Admin and Viewer modes with the flexible controls over various Sites or the entire organization.

Figure 1.6. X-perience RBAC

Audit Logs -

Figure 1.7. X-perience Auditing

More Settings -

Figure 1.8. More Settings = More Control

Offline Mode -

Figure 1.9. X-perience Control Offline

Manage Additional Organizations -

Figure 1.10. X-perience Easy Org. Management

Add a Device:

Hello Verkada

… Say Goodbye to hours to Configuring and Deleting Cameras to a DVR/NVR.
… Say Goodbye to old Physical Security tech.
… Say Goodbye to pain.

User QR or Serial Number to add Cameras.

Figure 1.11. X-perience Easy Device Provisioning

Easy to Un-Provision -

Figure 1.12. X-perience Easy Device Un-Provisioning

Site Configuration:

• Create and Manage Sites with ease:

Figure 1.13. X-perience Site Management (HQ Site)

Figure 1.14. X-perience Site Management (Branch Site)

Grid Configuration

• Create and Manage Grids per your requirements:

Figure 1.15. X-perience Grid Management

Cameras :

Figure 1.16. X-perience Camera Views like never before

On the Cameras View page here are the options you have:

Modify Camera Name -

Figure 1.17. Modify Camera Name

Modify Camera Site -

Figure 1.18. Modify Camera Site

View Camera Details -

Figure 1.19. View Camera Details

Advanced Settings -

Figure 1.20. Advanced Settings for the Cameras - 1

Figure 1.21. Advanced Settings for the Cameras - 2

Auto Focus -

Figure 1.22. X-perience the power of Auto Focus

Motion Alerts -

• One of the most noticeable features is the Motion Alerts Feature which lets you filter by People and Vehicles.

Figure 1.23. X-perience Safety with Motion Alerts

Motion Alert Emails -

Figure 1.24. Motion Alert Email Format

Enable Person History:

Figure 1.25. Person History Feature Configuration

People Analytics:

Bring Intelligence and Efficiency to Investigations. With the Verkada People Analytics you can:

• Match People
• Face Search
• People Detection
• Heat maps

People Analytics is a powerful set of tools built to proactively inform users about people detected in frame. Using powerful computer vision technology, footage is instantly analyzed to detect and match individuals based on a range of factors including clothing color and facial traits.

Figure 1.26. X-perience People Analytics

How People Analytics Works -

Figure 1.27. How People Analytics Works

See Who is in Frame
From the Command Platform, instantly see a breakdown of unique individuals found in frame on supported cameras*.

Search People
Use pre-built filters to quickly find matches across cameras by searching time, date, and unique traits like clothing color and faces.

Mobile Search
Directly from a mobile device, users can search for matches by using existing photos in their library or by taking a photo with a phone’s camera.

Modify Camera Location

Figure 1.28. X-perience of Location Management for Cameras

Maps -

• Powered by Google Maps, Verkada uses Map and Satellite Imagery.

Figure 1.29. X-perience The Power of Google Maps in Physical Security

Upload Floor Plans for your Buildings as needed -

Figure 1.30. X-perience The Power of Google Maps in Physical Security

Archive

Figure 1.31. X-perience Easy Archival

Want to know More about Verkada :

Further Details about Verkada’s Security Cameras can be found:

https://www.verkada. … om/security-cameras/

Further Details about Verkada’s Access Control Solutions can be found:

https://www.verkada.com/access-control/


*****

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

Have a query. Ask tcplabs’ Support Team here: https://eurl.io/#77byI9mXw

References:

https://www.verkada.com/

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

Saturday, March 30, 2019

TCPLABS G Cloud - GCP Start with Cloud Marketplace

Overview:

This blog provides an introductory overview of Google Cloud Platform(GCP) products and services. In future blogs, you will learn the value of GCP and how to incorporate cloud-based solutions into business strategies. The sections have been divided into different quests which have screenshots describing the look and feel of Google Cloud Platform and all the fun stuff one can do with it.

GCP Fundamentals: Getting Started with G-Cloud Marketplace:

In this blog you will learn how to use the Google Cloud Marketplace to quickly and easily deploy a LAMP stack on a Compute Engine instance. The Bitnami LAMP Stack provides a complete web development environment for Linux that can be launched in one click.

Figure 1. Bitnami Components and Roles

For more information on the Bitnami LAMP stack, see: https://docs.bitnami.com/google/infrastructure/lamp/

Quest 1: Sign in to the Google Cloud Platform (GCP) Console

  • Click here: https://cloud.google.com/
  • Click on Go To Console:

    Figure 2. GCP Console - The Gateway

  • You WILL need a free tier Google Cloud Platform account or project.

Quest 2: Use cloud marketplace to deploy a LAMP stack:

· In the GCP console, on the navigation menu click Marketplace:

· In the search box type “LAMP”:

· Click on LAMP Certified by Bitnami:

· You can choose other LAMP stacks like Google Click etc.

· On the following page, click on Launch on Compute Engine:

NOTE: If this is your first time using Compute Engine, the Compute Engine API must be initialized before you can continue.

· Clicking on the Launch on Compute Engine asks you for Enabling a free trial if you do not have one:

· Step 2 will consist of details which you will need to fill in for Account Type, Name and Address and the Payment Method so that Google can verify you. Note that Google does not auto-charge you after the free trial ends.

· Ensure to have created a GCP Project since in GCP everything happens within the Project:

· This is how the Project dashboard looks:

Note: You can have upto 24 Projects in the Free Tier.

· If Everything goes well until now, you should be able to choose your project for this LAMP deployment on the Project that you created:

· Once you Click on Open after choosing the project, in this case Tcplabs-gcp-1-test, GCP takes some time to configure the requisite APIs:

· Once the APIs are configured, you should get something similar:

· Choose the Deployment name and Zone of your choice and leave the remaining settings as their default. In case you are prompted to accept the GCP Marketplace Terms of Service, do so.

· Finally Click Deploy:

· The Deployment Manager runs for the while as follows:

Note: If a Welcome to Deployment Manager message appears, click Close to dismiss it. The status of the deployment will appear in the console window: tcplabs-webserver-1 is being deployed. When the deployment of the infrastructure is complete, the status changes to tcplabs-webserver-1 has been deployed:

· After the software is installed, a summary of the details for the instance, including the site address, is displayed.

Quest 3: How to ensure that the Deployment has been Successful?

· Post completion of the deployment, click Site address link in the right pane. You may also click on in the Get started with LAMP Certified by Bitnami section of the page and should get the following Congratulations Message:

· Close the Congratulations Browser tab and on the GCP Console click the just created SSH:

After some wait:

You should be able to get to the following section:

· Change the directory to /opt/bitnami as under:

Cmdlet: cd /opt/bitnami

· Copy the phpinfo.php script from the install directory to a publicly accessible location under the web server document toot and execute the following:

Cmdlet: sudo cp docs/phpinfo.php apache2/htdocs

This script displays the PHP configuration and is often used to verify a new PHP install.

· Type Cmdlet: exit to close the SSH window.

· Open a Browser and type the following URL while replacing SITE_ADDRESS with the URL in the Site address field in the right pane of the lampstack page:

· In this case we will type: http://35.229.80.208/phpinfo.php to get the following page:

· Close the phpinfo tab.

Congratulations!
You just learnt how to deploy a LAMP stack to a GCP Compute Engine instance.

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

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.