LLDP - Link Layer Discovery Protocol

Discovering neighbour devices in a network solves many configuration issues. 

Neighbour discovery protocols define a standard method for Ethernet network devices, such as switches and routers, to receive and/or transmit device-related information to other nodes on the network, and to store the information that is learned about other devices.

Link Layer Discovery Protocol (LLDP) is a Layer 2 protocol defined by the IEEE Standard 802.1AB-2005.

LLDP allows Ethernet network devices to advertise details about themselves, such as device configuration, capabilities and identification, to directly connected devices on the network that are also using LLDP. 

LLDP is a “one hop” protocol; LLDP information can only be sent to and received by devices that are directly connected to each other by the same link. Devices that are directly connected to each other are called neighbours. Advertised information is not forwarded on to other devices on the network

LLDP is designed to be managed with Simple Network Management Protocol (SNMP). We provide a command line interface to manage LLDP, however SNMP is the recommended interface as LLDP is designed to be automatically managed from Network Management Systems (NMS).

Advertisements are sent in packets called LLDP Data Units (LLDPDUs). The data sent and received via LLDPDUs is useful for many reasons. For example, the switch can discover which of the other devices on the network are each other’s neighbours, and through which ports they connect to each other.
You can configure the switch to do the following:

• transmit information about itself to neighbours
• receive device information from neighbours
• store and manage received information in an LLDP MIB

Each device that uses LLDP has its own LLDP agent, which is a software entity that implements LLDP. The LLDP agent is responsible for the reception, transmission, and management of LLDP.

LLDP defines the following:

• A set of common advertisement messages (Type Length Values).
• A protocol for transmitting and receiving advertisements. 
• A method for storing the information that is contained within received advertisements

Type Length Values

The LLDP agent transmits and receives information via LLDPDUs. A single LLDPDU contains multiple advertisement messages, each of which is communicated within a Type Length Value (TLV). TLVs are short information elements which communicate complex data, such as variable length strings, in an organized format. Each TLV advertises a single type of information that identifies the sending device, for example, its device ID, type, or the address or addresses. 

Each LLDPDU contains at least four mandatory TLVs by default. You can also configure the switch to send up to five optional additional TLVs. 

Asterisk Voice Delay

Unlike standard telephony, where there is no perceivable delay between voice transmission and receipt, at least on local calls, VOIP introduces a number of extra layers than can increase this delay.

Here are a few things you can look at to reduce this delay:

 

• Ensure all codecs in use are non compressed. Any compression will add additional delays.
• Use the same codecs on each end. Conversion means extra processing, adding delays.
• Turn off all jitterbuffers. These introduce a small delay to compensate for fluctuations in latency.
• Use the smallest packet size possible. Usually this is 30 or 20ms but it may be possible to reduce it, depending   on the phone hardware.
• Ensure the media is not being passed through the PBX, so the phone is sending audio directly to the other   endpoint. For sip use -+canrevite=no+=.

Source: www.voip-info.org

Asterisk dialplan - An overview


The dialplan is truly the heart of any Asterisk system, as it defines how Asterisk handles inbound and outbound calls. In a nutshell, it consists of a list of instructions or steps that Asterisk will follow. Unlike traditional phone systems, Asterisk’s dialplan is fully customizable. To successfully set up your own Asterisk system, you will need to understand the dialplan.


The Asterisk dialplan is specified in the configuration file named extensions.conf.


The dialplan is made up of four main concepts: contexts, extensions, priorities, and applications.


Contexts


Dialplans are broken into sections called contexts. Contexts are named groups of extensions, which serve several purposes. Contexts keep different parts of the dialplan from interacting with one another. An extension that is defined in one context is completely isolated from extensions in any
other context, unless interaction is specifically allowed.


Extensions

In the world of telecommunications, the word extension usually refers to a numeric identifier given to a line that rings a particular phone. In Asterisk, however, an extension is far more powerful, as it defines a unique series of steps (each step containing an application) that Asterisk will take that call through. Within each context, we can define as many (or few) extensions as required. When a particular extension is triggered (by an incoming call or by digits being dialed on a channel), Asterisk will follow the steps defined for that extension. It is the extensions, therefore, that specify what happens to calls as they make their way through the dialplan. Although extensions can certainly be used to specify phone extensions in the traditional sense cause the SIP telephone set on John’s desk to ring), in an Asterisk dialplan, they can be used for much more. The syntax for an extension is the word exten, followed by an arrow formed by the equals sign and the greater-than sign, like this:

exten =>


Priorities


Each extension can have multiple steps, called priorities. Each priority is numbered sequentially, starting with 1, and executes one specific application. As an example, the following extension would answer the phone (in priority number 1), and then hang it up (in priority number 2):


exten => 123,1,Answer()
exten => 123,2,Hangup()


Unnumbered priorities


In older releases of Asterisk, the numbering of priorities caused a lot of problems. Imagine having an extension that had 15 priorities, and then needing to add something at step 2. All of the subsequent priorities would have to be manually renumbered. Asterisk does not handle missing steps or misnumbered priorities, and debugging these types of errors was pointless and frustrating. Beginning with version 1.2, Asterisk addressed this problem. It introduced the use of the n priority, which stands for “next.” Each time Asterisk encounters a priority named n, it takes the number of the previous priority and adds 1. This makes it easier to make changes to your dialplan, as you don’t have to keep renumbering all your steps. For example, your dialplan might look something like this:


exten => 123,1,Answer()
exten => 123,n,do something
exten => 123,n,do something else
exten => 123,n,do one last thing
exten => 123,n,Hangup()


Priority labels

Starting with Asterisk version 1.2 and higher, common practice is to assign text labels to priorities. This is to ensure that you can refer to a priority by something other than its number, which probably isn’t known, given that dialplans now generally use unnumbered priorities. To assign a text label to a priority, simply add the label inside parentheses after the priority, like this:


exten => 123,n(label),application()


Applications


Applications are the workhorses of the dialplan. Each application performs a specific action on the current channel, such as playing a sound, accepting touch-tone input, dialing a channel, hanging up the call, and so forth. In the previous example, you were introduced to two simple applications: Answer() and Hangup(). You’ll learn more about how these work momentarily.




Ref: Asterisk - The Future of Telephony


We will update with detailed explanation of dialplan with realtime examples in our next post.

Thank you

AsteriskTechs