V14 Trouble Shooting ShoreTel SIP

ShoreTel SIP is just not that hard to configure! When things go right, and it all works, it is relatively painless and very easy.   When things don’t work however, you will need to sort out the problem and figure out how to make it work.   The good news is that SIP is a clear text, english like “requests” and “response” message exchange that, once understood can be relatively easy to work with.   Using packet capture tools like Wireshark can be a real assist.   ShoreTel has built “remote packet capture”  into the V14 diagnostic portal and makes debugging sip issues even more easy to digest.

The message exchange for SIP “extensions” is not much different than that for SIP “trunks”.   So to learn SIP why not study a successful SIP connection first, before diving into a debug session.  What we have tried to do in this tech tip, is to illustrate the process of a SIP extension registering with a ShoreTel proxy server.   We picked a configuration that is comparatively complex, but not unlike one that you might find in the real world.  SIP extensions can unit remote office workers into a seamless call handling workgroup.  As such your remote worker will traverse a couple of firewalls and routers on its way to the SIP proxy.

In this configuration we register a SIP soft phone, remotely from the ShoreTel HQ site, over a site to site VPN tunnel.    The VPN tunnel is between a CISCO ASA and a SonicWall TZ250.  We note that 90% of the SIP issues we see having nothing to do with the configuration of the ShoreTel equipment and everything to do with the network devices, routers, switches and firewalls that are part of the SIP solution.  Small business solutions, for example,  tend to bring the SIP trunks into the phone system over the same connection they bring in their internet connection.  This means the SIP trunk is passing through the firewall, another most likely candidate for inducing a SIP failure.

This tech tip walks you through a successful SIP registration of a remote soft phone.  In our next tech tip, we will walk you through configuring a SIP trunk through a SonicWall and then look at fixing some broken SIP connections!

A ShoreTel Workgroup is a Contact Center for the rest of us!

We have been working around the call center space for a long time.  Actually, it is our first love! Does everyone need a full blown Contact Center?   If you have a real boiler room operation, with shifts of agents that are heavily manged, counted, recorded, measured complete with staff forecasting and multiple channels of client communication, yes you need an Enterprise Contact Center.   As Arlo Guthrie might say “what about the rest of us”?   The small to medium size business that is really not cracking the whip on customer service agents, but making efficient use of “knowledge workers” who often participate within a group setting.  How do we organize customer calls to this group?

A techncial support group or an order entry group might be a good example.   By grouping these folks into a “workgroup” we can funnel calls to them in a call center like fashion without the call center overhead of application servers and third party middle ware.   ShoreTel has an embedded call center like feature aptly named “WorkGroups” that is an ideal solution for this environment.   You can organize a group, route calls to group members and even queue the call until a group member becomes available.   While callers are in queue, you can organize the messages they hear, the time they wait between care messages and you can also provide “bail out” options at each step of the way.

The workgroup can be reached as a menu selection off of an automated attendant or have a phone number assigned that enables outsiders to call directly to the workgroup!   The workgroup can have an operating schedule applied that routes callers to alternative answer points if the group should be reached after hours.  Group members can Log in and Log out of the workgroup using their ShoreTel Communicator and still maintain their personal extension number and mailbox.  While logged into the workgroup, they can share the group voice mail box and see callers waiting in queue!  Supervisors can monitor the callers in queue and manipulate resources to meet call demand.   Reporting statistics on the group are maintained and easily obtained by the workgroup supervisor or administrator with reporting permissions.

We are now even making it possible for Callers to TEXT into your workgroup!  Group members can even email back a TEXT message!

The ShoreTel Workgroup strategy is a powerful call center like functionality and very cost effective.    The marginal cost of adding agent and supervisors license when you plan to implement a ShoreTel iPBX when compared to adding a complete Enterprise Contact Center is amazingly low!   We would be happy to explain the difference between a Workgroup and the ECC, so just contact us for details!

TEXT the keyword “workgroup” along with your name or email to 702-956-8700 and we will respond immediately!

 

 

VPN’s and VoIP – Getting Connected!

We see a lot of VoIP deployments that come to us for trouble shooting.  A common problem statement is that our HQ site can call both Chicago and Dallas, but Dallas and Chicago can’t call each other.  Savvy network administrator will have figured out that there is a routing issue, but how so?  Clearly HQ knows how to reach each remote site and the remote sites know how to reach HQ, so where is the break down!   At about this time, we learn they have VPN’s that provide tunnel connections to each location and we go clear!

The standard “tunnel” solutions include IP Security (IPSec), GRE, Easy VPN and the new “tunneless” Group Encrypted Transport VPN  (GET-VPN) VPN’s are the connectivity options we currently have available.  Most folks make the mistake of picking IPSec for connectivity and being an inherently point-to-point technology, they end up with the problem statement summarized above.   Even a “hub and spoke” solution is not ideal unless we make it possible for “spoke to spoke” connectivity.   Ideally, we need to configure our VPN so Dallas can communicate with Chicago, without passing through HQ!

IPsec is really an encryption and authentication technology that enable secure communications through a public internet.  It is generally used in a multiple vendor deployments.   IPsec does not support any protocol other than IP, so it can not be used with the routing protocols that might otherwise be used to solve our issue.   For this reason, many deployments will use GRE over IPsec.   GRE to address the routing protocol issues and the  IPsec to provide the security of authentication and encryption.  We are still however, in a point to point mode, or in heavy manual administration mode to configure a simple mesh!

The smart money is on “next hop resolution protocol or NHRP” used in strategies like FlexVPN, GETVPN or DMVPN.  These solutions provide a full mesh option while providing for encryption and data integrity.  In the problem statement above, had we installed GET-VPN, a tunneless solution, the Chicago and Dallas sites could communicate directly without having to route through HQ at all

VPN’s and VoIP – Getting economical “full mesh” Connectivity without MPLS!

We see a lot of VoIP deployments that come to us for trouble shooting.  A common problem statement is that our HQ site can call both Chicago and Dallas, but Dallas and Chicago can’t call each other.  Savvy network administrator will have figured out that there is a routing issue, but how so?  Clearly HQ knows how to reach each remote site and the remote sites know how to reach HQ, so where is the break down!   At about this time, we learn they have VPN’s that provide tunnel connections to each location and we go clear!

The standard “tunnel” solutions include IP Security (IPSec), GRE, Easy VPN and the new “tunneless” Group Encrypted Transport VPN or  GET-VPN. Most folks make the mistake of picking IPSec for connectivity and being an inherently point-to-point technology, they end up with the problem statement summarized above.   Even a “hub and spoke” solution is not ideal unless we make it possible for “spoke to spoke” connectivity.   Ideally, we need to configure our VPN so Dallas can communicate with Chicago, without passing through HQ!

IPsec is really an encryption and authentication technology that enable secure communications through a public internet.  It is generally used in a multiple vendor deployments.   IPsec does not support any protocol other than IP,  so it can not be used with the routing protocols that might otherwise be used to solve our issue.   For this reason, many deployments will use GRE over IPsec.   GRE to address the routing protocol issues and the  IPsec to provide the security of authentication and encryption.  We are still however, in a point to point mode, or in heavy manual administration mode to configure a simple mesh!

The smart money is on “next hop resolution protocol or NHRP” used in strategies like FlexVPN, GETVPN or DMVPN.  These solutions provide a full mesh option while providing for encryption and data integrity.   In the problem statement above, had we installed FlexVPN, the Chicago and Dallas sites could communicate directly without having to route through HQ or hub.   We would have “spoke to spoke”  to communications!  As broadband becomes more widely accepted and bandwidth becomes less of an issue, we should see more VPN technology deployed in place or in concert with private network technologies like MPLS (GetVPN over MPLS is really kool).

Give us a call and we can noodle out what “full mesh” technology makes the most sense for your organization, both technically and economically!  We are here to help make the network!