More on ShoreTel LLDP – follow up to previous blog post!

This is a follow up post to an earlier post on LLDP-MED. VoIP phones on the market today follow the same basic boot and operations process:

1 – Wait for an LLDP packet from the Ethernet switch

2- Send a DHCP discovery packet to find the DHCP Server

3- Send a DHCP request to the DHCP server to get an IP address

4- Send an LLDP-MED packet to the Ethernet switch

5- Wait for an LLDP-MED packet from the Ethernet switch and read the Network Policy TLV to get the VLAN ID, L2 priority and DSCP value

6 – Download applciations and software from the “call manager”

7 – After configuration , voice packets are sent as tagged frames and data packets are sent as untagged frames

The ShoreTel implementation of LLDP seems to follow this process only after step 5, the result of the IP Phone learning LLDP by having its firmware configured. In other words, a phone out of the box is a hung of iron with no inherent ability to define itself as an IP phone to an LLDP enabled ethernet switch. The ShoreTel phone will still require an intial boot in the native VLAN and then reboot in the voice vlan, where it will then download its firmware. The real value here, is that once this process is “learned” by the ShoreTel phone, should the phone restart for any reason in the future, it can start at step one above. LLDP in ShoreTel is a version 9.1 feature enhancement not available in earlier releases of ShoreTel.

update 2/15 see  article at

How to get your iPhone running SIP on your ShoreTel IPBX!

If you are and iPhone aficionado, you absolutely want your iPhone to work  on your ShoreTel IPBX! I recently downloaded VeNetCorps SipPhone fromt the iPhone App store! There are several SIP phone apps at the store, but most have a pre-programmed domain name for the sip registration proxy server. If you want to use your own SIP proxy there was no easy way to change the IP address so you had to hack your DNS to get it to point to the ShoreTel SIP proxy. Also you need at least iPhone firmware 2.2 as previous versions had WiFi connectivity challenges that negatively impacted the potential for using a SIP softphone. After the iPhone WiFi acquired an IP address, if you attempted to ping the address you would see latency in excess of 300ms. With version 2.2 this issue has all but become unnoticeable. As with any SIP extension setup on ShoreTel, you need to assign sip extension proxy resources on a ShoreGear switch. In the sites section of the ShoreWare Director, make sure you assign a virtual IP address. This is the address you will use for your “domain’ when you setup the Iphone SipPhone. Clearly you will need a User setup with a SIP phone password defined in the individual user section of the ShoreWare Director.

Clearly the assumption here is that you have a WAP that your iPhone can connect to. Also that that wireless connection can route to your ShoreTel network! Once the ShoreTel SIP user, virtual IP address and proxy resources are configured it is time to configure your iPhone SipPhone! After you down load the application and tap to activate the application you will get a screen that lists the options: Dialer, Recent, Contacts, Accounts and Settings. Hit the Accounts tab and you will then EDIT a new SIP account. To get this app to work on ShoreTel you need to enter only three values. First you need to enter the domain name, we have previously defined in the ShoreTel Director as the Virtual IP address. The Username and password are also as specified in the individual user setup in ShoreTel. Hit the DONE tab, and the phone should register and you can make and receive calls from your ShoreTel. I put together a video clip that covers this so you can see that it accutaly works! The video suggests that you enter the user name, but if you want to call the iPhone from a ShoreTel extension, enter the user’s extension number instead.  This was just a fun project and latency on the iPhone WiFi is still a challenge for SIP phone usage.  I suspect that Version 3.0 of the iPhone will fix this small issue, but it was a blast trying it out!  Enjoy!

Add your iPhone as a ShoreTel SIP extension!

Fax on VoIP IPBX systems!

When VoIP gateways first started hitting the market back in 98′, the vendors tried to packetize DTMF and quickly learned it did not work well.   For this reason they quickly learned to “regenerate” DTMF at the outbound gateway rather than packetize and truck it across the network.   Moving modem tones is even more challenging and most VoIP solutions discourage attempting to send modem tones over an IP connection.  If you can get it to work at all, the modems will negotiate down to about teletype speed or about 300 baud. (Now there is a device and an term you don’t hear much about anymore).   Given that a fax machine generates modem tones, faxing over an IP connection is equally challenging.  ShoreTel makes it possible, for example, to attach a low end fax server as a couple of analog IPBX ports.   Incoming fax calls to the IPBX system, can reroute these faxes and even regenerate the DID number as DTMF to the fax server enabling fax to email applications.  What we are beginning to see as the SIP market matures, is that the phone companies are bringing PRI circuits to the customer premise disguised as traditional TDM circuits.   Your Telco interface may in fact be a ShoreGear T1, but you are interfacing to an Integrated Access Device that is converting SIP signaling  to SIP and then on to the Telephone companies softswitch.   Currently, this is a big problem for fax machines connected as analog lines to the host IPBX.  True Fax over IP is going to require a T38 interface and fax machines and servers that can support this protocol.  The message here is, make sure you know what you are connecting to!  True TDM or a SIP trunk!  Knowing the difference will enable you to properly handle fax traffic.


To VOIP QOS or not to VOIP QOS?

In telephony, IP QOS is somewhere between a science and an art. Setting up VOIP QOS on your network is essential for toll quality voice from end point to end point, especially across a WAN. Historically, in ShoreTel, IP packets were marked with the DSCP value set in the Call Control Options page. Generally this is generally set as a value of 184 or Precedence Level 5, what CISCO would call Express Forwarding or EF. This value is represented as 184 (10111000 or 46) but as a TOS/Differential Service Control Point marking it is only applied to the IP layer and has no impact on your LAN. Additionally, IP packets were only marked on the media stream between IP phones, not between the switches or between the phones and the switches. Version 9 of ShoreTel, now reports “system wide” TOS/DSCP support, which represents a significant improvement in your ability to control VOIP QOS. At the LAN level, it is important to know that you are working with Ethernet frames and for this reason the only QOS marking available to you is a VLAN tag. Inside the VLAN tag, three bits have been set aside for precedence markings and are named COS for “class of service”. If you are NOT running SIP on your network, you have another QOS tool available to you. ShoreTel media streams in other than SIP environments run on UDP port 5004 enabling you to prioritize voice over data at the transport level. ShoreTel also provides the opportunity for you to establish “admission bandwidth control” per site, to assure that the next phone call does not exceed the limits you have set with this parameter. Beware that this parameter exists only within the ShoreTel architecture and has no real knowledge about the actual bandwidth utilization of your network. Establishing this threshold is left entirely to the engineer designing the network. In large part IP QOS is best determined at the IP level and is heavily dependent on establishing queue in your routers that service latency sensitive traffic, voice and video, over less sensitive best efforts traffic. Knowing about these different QOS markings is the science. Knowing how to pass markings from one level to the next is the art of QOS!