“The Check is in the Mail”;
“I gave at the office”;
“The software if fully tested and bug free”;
“We are working on the documentation”;
“Go ahead tell me, I promise I won’t get mad”;
“Yes we backup our data every day, off site”.
These are just a few of our favorite white lies. That last one, however, is a real resume creation event. Today I took my late model SL convertible in for a smog inspection. You could have knocked me over when the technician informed me that the car failed the certification! Just the day before I had the car into the dealership to get the “consumer electronics” battery changed and have the normal scheduled maintenance. Apparently, at least here in the peoples republic of California, if you have On Board Diagnostics (OBD) in you automobile, that data is submitted or evaluated as a part of your smog inspection. Having just had the battery changed, my dealer had failed to backup or protect this data and as a result the OBD had no history. I failed the smog check , wasted several hours of my life and can now retest when I get 100 miles of driving history back into the on board automotive computer. Clearly my dealer had no data plan or process in place to protect the data during routine maintenance.
Now imagine if that had been your VoIP phone system or call center? Simple server upgrade? New Version of the iPBX being installed? The question is, does your dealer have a process in place to protect your data during routine maintenance? More importantly do you have a plan and process in place for backing up your iPBX configuration database, system prompts, voice messages, call detail records and even your maintenance history (e.g. Logs)? Want to play, “bet your company’? Chances are that you have this on your list of “things to do” but you just have not had the time to execute. You may even be trusting that your dealer is taking care of this as part of that expensive maintenance contract you entered into.
If you are really feeling secure about your iPBX failover plan why not just pull the power plug and test things out? There is nothing like a crashed phone system to bring out the facts about database backup, recovery and the business continuity preparedness of you and your vendors! The facts are that having an active emergency back up and restoration plan in place is absolutely essential in this day and age. Cloud backup automation services abound and there is not acceptable reason for not having this process in place. Just as important, is a restoration plan that is periodically exercised. You can have all the data available on backup, but if you can not restore that data, it is useless to you and your business. Yes, it may be just another “fire drill”, but it will save your company if you include this process in your maintenance activities on a regularly scheduled basis.
Very recently we have had an opportunity to experience cloud based, on demand, iPBX redundancy and disaster recovery strategies. We have explored some of the current cloud options for both day to day redundant operations and disaster recovery. In one case we were able to bring up a complete PBX in the cloud in a matter of minutes, on demand using predefined Amazon Machine Instances. The results were remarkable, dramatic and redefined operational readiness. Hit the AskDrVoIP button for details!
This is not a SIP tutorial, only an overview on the issues that impact remote SIP phones on any iPBX. When you set up a SIP call between two end points, there are upwards of four “holes” that might need to be punched in your firewall for the phone call to work properly. Clearly, there is the entire process of registering a remote phone and the process of setting up a phone. Once these events have been negotiated, we then have the issue of the media stream between the two phones. Generally the registration and call setup are taking place through TCP/UDP port 5060 on a public IP address that terminates on your firewall. Generally, your Firewall will have these ports forwarded to your SIP Proxy or iPBX which lives on your internal private network. (Take note: Public and Private IP, we will talk more about that later).
Once the call is setup, there is a “mouth to ear” path setup for each leg of the call. These “dial peers” are really just media streams. These media streams take place over UDP ports using RTP protocol, one for each “mouth to ear” stream, so that is two more ports open on the firewall. Each of the RTP streams has a UDP cRTP protocol port requirement as well, so we need to open two more ports your firewall. So to summarize, you will have TCP/UDP port 5060 open on your Firewall all the time, and four UDP ports open for each active phone call. Your firewall is starting to look like a sponge?
You don’t have to be a network security guru to figure out this strategy has some obvious challenges! 12 year old Elementary school kids run port scanners looking for open 5060 and then run Sipvicious in hopes of registering a rouge phone. Through in the fact that your ISP may or may not block 5060, and or refuse to use the same ports and you have the making of a SIP nightmare! SIP was never expected to traverse from public to private IP addresses either! So we have SIP savvy firewalls and border controllers to help us out. These devices, among other features they provide, can police ports, opening and closing them as required when a legitimate connection is required between an inside phone and an outside phone. They also translate between the public IP address and the internal private address keeping an internal scratch list of who is using what, closing ports when done to increase security.
Is there a better way? What if we could create a secure “tunneling strategy”? Not a VPN, but a strategy for getting the SIP call control and Media Stream to move through a single firewall port? Sound like a winner? This SIP Proxy Tunnel can combine all SIP (signaling) and RTP (media) VoIP Packets from one location (typically a remote office) and deliver them to and from another location (typically the PBX Server) using a custom TCP protocol. This simple concept allows us to exploit the SIP Proxy Tunnel to overcome difficult situations, or to simplify a network scenario.
The SIP Proxy Tunnel can be used for the following reasons:
Resolve issues of NAT Traversal at both the remote and the PBX location
Simplify Firewall configuration at both the remote and the PBX location
Overcome difficulties with ISPs that block VoIP Traffic based on port numbers
Allows VoIP-over-WiFi in some restricted locations, such as Hotel rooms
“Fixes” Firewalls that cannot handle VoIP traffic correctly or which are very difficult or problematic to configure correctly, such as:
Microsoft ISA Server
SonicWall
What if “remote” also means a mobile phone? When you have a user who is roaming around with a SIP soft phone extension on their cell phone, we have no idea what IP address they will be connecting from! The answer (excuse the pun) is an android or iPhone application that enables you to create the tunnel from you mobile phone, bring up your iPBX extension and move your desk outside, down the hall or across the globe. At the end of the day this would be a true Mobility router. Last year ShoreTel acquired Agito Networks and obtained this very same technology and it is an outstanding solution. The ShoreTel Mobility Router and Roam Anywhere cell phone client can do all this SIP magic and even move your call seamlessly between WiFI and Cellular while your walking out to the parking lot. How great is that?
On more than one occasion I have actually had to telnet into a clients router or switch using nothing more than a mobile phone! Now, that is either an example of superior customer service or an indication of creeping insanity. When you have to, you have to! Sometime ago I moved to an Iphone and that actually makes RDP, VNC or Telnet actually usable on a mobile phone in a pinch.
To say I think the Ipad is a game changer is an understatement. If you analyze your computing habits you will find that you have two basic modalities: work and play. At work, you are bent over and leaning in to your computer using a keyboard. At play, if you could, you would be sitting in your favorite armchair surfing the web, watching yourtube and reading electronic books while updating your Facebook status. This last mode, does not really require a lot of keyboard. In fact the user interface that makes the Ipad so exciting is beginning to make you want to touch your Windows screen before you reach for you mouse.
It is the 21st Century and we are still keyboarding and mousing around? The Ipad is redefining how the man machine interface will work. Human gestures are much more effective than highlighting, dragging and dropping. Ever consider how people use a phone? They really want to poke buttons and lift handsets. Mousing around is OK and many of us gravitate to all the features available to us when we integrate our phone system to our desktop computer. The issue is, that word “desktop”. The level of mobility that exists in business today, especially among knowledge workers and dispersed work groups is phenomenal! Thus a growing dependency on Mobile devices.
Enter the Ipad. I admit it, I am a fanatical fan of the Apple family of computing devices, but I love this Ipad! I finally took delivery on my Ipad 3G and am trying to figure out what I can and can not do with it. I am able to do PowerPoint presentations on my Ipad using the Keynote App. I am telling you, if you have to do a one on one presentation and you do it on an Ipad, you are going to get the order!
I found a great application named iTapRDP which I had on my iphone and it is now available on my Ipad. This is a full blown RDP client that takes advantage of the “big screen” and additional real estate of the Ipad. Now if i have to log into someones ShoreTel on the fly, I can do it with only the pain of a 3G connection, but with a full screen. The next step was to just RDP into my own desktop and make use of my own ShoreTel Call Manager! Now using the “external assignment” feature, I have full ShoreTell Call Manager control from wherever I am, using my Ipad through and RDP session.
Come on, it is impressive to say the least! No application required other than iTapRDP and I was running both ShoreTel 10.1 and an the Integrated ShoreTel Call Manager with ECC Version 6! Sorry for the really bad video, but I am VoIP engineer not Oliver Stone (if anyone has a good Ipad Screen capture app, let me know)!
Recently a client discoverd that at terminated employee, gone for almost a month, was still answering his office extension from his cell phone! We have so many technology options for mobility today that the HR deparment most be going nuts trying to keep the “exit interview” check list up to date! Without commenting on the HR ramifications, IT system administrators have long had to contend with terminated employees and how to handle remote access, email and the other regular components of an advanced Information Technology. With the advent of VoIP, most IT organizations have now had to add the telephone system to the growing list of security access concerens.
This blog and video clip was created to knock off a couple of concepts simultaneously. First, adminstrators want to know how to configure permissions for different user types. Clearly the folks who work in the call center are supervised by managers that require a set of features that might enable monitoring, barge in and call recording. The Kitchen and Lobby phone do not need voice mail boxes and should only be enabled for extension to extension calling and 911 service. Do we need to set up Account Codes for International dialing? Who must enter an Accout code to make a phone call and who has Supreme being features? The list goes on. Do you allow your Users to reassign there extensions to external numbers, like the home office or cell phone? If that employee leaves the company, do you have a plan in place as to how to manage that employees incoming phone calls? This is where the concept of a ShoreTel Use Group can be exploited to rapidly nail down departing employees call flow.
The concept of a “containeer” as a mechnism for treating a class of users has been utilized as a programming convention since the first bit stream. Microsoft System administrators will be immediatley comfortable with the concept, as will any IT professional who has system administration responsibility. The concept is simple: rather than create a each individual and then list out their permissions, previldeges and class of service; lets “contain” them in a “group” and apply the permissions against the group. This makes it easy to administer large populations of users who may share similar system facilities. In ShoreTel, the concept of class of service, is defined and applied to a container named “User Group”.
Out of the box, ShoreTel has a predefined family of User Groups arbitraily but apptly named Exeucitve, Manager, Staff and so on. Each user group contains a set of permissions defined as a Class of Service. These services include permissions regarding the telephony features available to this user, the users dialing restrictions and also define key attributes about the users Voice Mail box. In ShoreTel, certain features like “call forwarding” and “find me/follow me” require the user to have a Voice Mailbox, so understanding how these permissions are configured is essential to the creation of a secruity policy for your phone system. If you allow the use of “find me follow me” or the ShoreTel “Personal Operator” funtion you might want to limit the range that those calling permission might include. (If you want to talk to Mom in Italy, call my extension after hours and press zero when you here my greeting” is one of my personal favorites).
The video clip walks you through the process of creating a new User Group aptly named “Terminated Employee”. This User Group then encompasses a body of restrictions that can be applied to a User, in this case a departing employee, with just a couple of key strokes. The goal here is to nail down the employees call flow while you are working out the details of transitioning the employees work flow. Clearly, you can just delete the user and be done with it, but normally business is not that simple. Employees are part of Work Groups or Hunt Groups that define a work flow and sometimes it takes a transition plan to get the details worked out. In the mean time, we need to secure the phone!
Recently a client discovered that at terminated employee, gone for almost a month, was still answering his office extension from his cell phone! We have so many technology options for mobility today that the HR department most be going nuts trying to keep the “exit interview” check list up to date! Without commenting on the HR ramifications, IT system administrators have long had to contend with terminated employees and how to handle remote access, email and the other regular components of an advanced Information Technology. With the advent of VoIP, most IT organizations have now had to add the telephone system to the growing list of security access concerns.
This blog and video clip was created to knock off a couple of concepts simultaneously. First, administrator want to know how to configure permissions for different user types. Clearly the folks who work in the call center are supervised by managers that require a set of features that might enable monitoring, barge in and call recording. The Kitchen and Lobby phone do not need voice mail boxes and should only be enabled for extension to extension calling and 911 service. Do we need to set up Account Codes for International dialing? Who must enter an Account code to make a phone call and who has Supreme being features? The list goes on. Do you allow your Users to reassign there extensions to external numbers, like the home office or cell phone? If that employee leaves the company, do you have a plan in place as to how to manage that employees incoming phone calls? This is where the concept of a ShoreTel Use Group can be exploited to rapidly nail down departing employees call flow.
The concept of a “container” as a mechanism for treating a class of users has been utilized as a programming convention since the first bit stream. Microsoft System administrators will be immediately comfortable with the concept, as will any IT professional who has system administration responsibility. The concept is simple: rather than create a each individual and then list out their permissions, privileges and class of service; lets “contain” them in a “group” and apply the permissions against the group. This makes it easy to administer large populations of users who may share similar system facilities. In ShoreTel, the concept of class of service, is defined and applied to a container named “User Group”.
Out of the box, ShoreTel has a predefined family of User Groups arbitrarily but apply named Executive, Manager, Staff and so on. Each user group contains a set of permissions defined as a Class of Service. These services include permissions regarding the telephony features available to this user, the users dialing restrictions and also define key attributes about the users Voice Mail box. In ShoreTel, certain features like “call forwarding” and “find me/follow me” require the user to have a Voice Mailbox, so understanding how these permissions are configured is essential to the creation of a security policy for your phone system. If you allow the use of “find me follow me” or the ShoreTel “Personal Operator” function you might want to limit the range that those calling permission might include. (If you want to talk to Mom in Italy, call my extension after hours and press zero when you here my greeting” is one of my personal favorites).
The video clip walks you through the process of creating a new User Group aptly named “Terminated Employee”. This User Group then encompasses a body of restrictions that can be applied to a User, in this case a departing employee, with just a couple of key strokes. The goal here is to nail down the employees call flow while you are working out the details of transitioning the employees work flow. Clearly, you can just delete the user and be done with it, but normally business is not that simple. Employees are part of Work Groups or Hunt Groups that define a work flow and sometimes it takes a transition plan to get the details worked out. In the mean time, we need to secure the phone!
Historically, there were three services in the ShoreTel architecture that were no distributed to other servers. To oversimplify, this meant that if the HQ server (read primary server) was unavailable, the services that were not distributed would not function. The three services were Route Points, Account Codes, and Workgroups. For example, if a user group was set to “forced” account code verification and the server was unavailable, that service would fail and the affected user would not be able to place a call. Likewise, if the HQ server were unavailable, Workgroup services would fail. ( The “best practice’ deployment strategy was to backup a Workgroup with a “hunt group” given that the HG ran on a switch and not a server, it would continue to function in this scenario. Calls targeting agents in a Workgroup would fail over to a hunt group that would target the same list of agents).
ShoreTel has steadily progressed the distribution of these services out from the HQ server to either SG switches or Distributed servers. With the latest release of ShoreTel, they have migrated critical services to include Workgroup services. This is a major enhancement and any organization that makes use of the Workgroup functionality, especially in a multi-site environment, will realize a benefit by these enhancements.
Through the ShoreTel administration portal, we now find a drop down window that enables us to select which server should be utilized to run the Workgroup we are defining. For example, in a multi-site environment, I might want to have the Workgroups organized by Site and run the workgroup service on the DVM at that site. This would keep the Workgroup local and a failure of the HQ server would not dramatically affect the workgroup at the remote site. We note that, in the absence of the HQ server, we are still unable to make database changes. For example, Logging In/Out of a Workgroup would not be possible, but the remote Workgroup would still function.
Additionally, we note that you can continue to name a Hunt Group as a backup extension. The key difference here is that the Hunt Group can contain extensions that are Workgroups on other servers! This offers a degree of flexibility not previously available and is a viable alternative to a straight Hunt Group solution. A failure of the HQ server will only effect the Workgroups that are on that server and distributed Workgroups on other servers will continue to run. A failure of a DVM with an operating Workgroup can fail to a Hunt Group that can be used to route calls to other Workgroups.
The vocabulary might be a bit confusing, but the strategy represents a significant step forward in assuring the operation of a distributed call processing application as powerful as ShoreTel Workgroups!
One of the benefits of a successful blog, is the talented people you meet and the ideas that you exchange with other industry professionals. Through an earlier blog on the subject of connecting an Apple Iphone to a ShoreTel System as a SiP extension, I met such a creative talent: Matt Vlasach of Pacificswell! Matt was both an excited ShoreTel user and a Iphone aficionado. Thought Matt was happy to play with SIP his real interest was in creating a ShoreTel App for the Iphone!
As a result of Matts talented development team at Pacificswell, I have had the pleasure of playing with a beta version of StreamLine, a mobile call manager for the Iphone! If you have always wished that ShoreTel could work on your Iphone, your wish has been granted! Pacificswell’s first release of the App is a useful, easy to master, technically brilliant mobile call manager! Using Streamline you can remotely connect to your ShoreTel server and setup your call handling modes and activate your Office Anywhere feature. The App is intuitive and graphically obvious!
Even using the Apple developers platform to obtain the beta version ( an Apple strategy for enabling developers to offer the App before it appears in the App store), the download and install was remarkably simple. It downloads and installs using the already familiar App Store process! Configuration was a breeze and I had the App up and running in under five minutes.
Clearly there are some server side issues that need to be addressed and license compliance issues for the ShoreTel Mobile Call Manager, but technically, the App is brillant. More importantly it just works! I was able to select either my Office desk phone or my Iphone as the primary answer point. Each of the Call Handling modes can be accessed in a visual graphic that is experentially compatible with the ShoreTel user interface for setting up Call Handling Options.
Product Development is a process, not an event! Matt assures me that he will continue the development and enhancement of this App adding more features in future releases. The product can be explored in detail on his site at Pacificswell and I have included some screen shots below!
Keep the cards and letter coming! The App will be available at the Apple App Store on January 4th!
Find Me Locations
Call Handling Modes
Select your Desktop or Iphone as prmary answering point!
Trouble Shooting VoIP issues in a multi-site deployment is a challenge to even the most talented network engineer. It is often difficult to determine what is a voice equipment issue and what is an issue aggravated by a network conditions. As network engineer troubleshooting an issue, having access to network monitoring tools is essential. Sometimes we have to use the basic ICMP tool sets and ping our way through a trace route, but network connectivity is only one element of QOS related areas in a VoIP deployment. (Actually, it would be great if clients invested in putting network monitoring tools in place, but they only seem to appreciate their networks when something goes wrong)!
What is that we need to monitor anyway? We split the monitoring world into two basic camps: Flow based accounting and Health checking software. Flow based monitoring enables us to check the source/destination IP address; source/destination port; IP protocol; TOS and Ingress interface. This is helpful when you are trying to figure out what applications are running on your network and who is streaming real time media. Clearly important stuff, but at the end of the day, when it comes to logging into someone’s network remotely and trying to figure out why some remote user has garbled phone calls, there is nothing like an in place Health check!
When we talk about the “health” of the network we are interested in knowing about Bandwidth capacity, Loss, Jitter, Mean Opinion Score (MOS), latency and tagging.These are the words that make a VoIP engineer smile!Would it not be wonderful to log into your clients network and have this kind of history available between key end points of a multi-site deployment?Rarely, do I ever publically endorse a product but the folks Apparent Networks have gone out of their way to make their product available, useable and free!You need to stop what you are doing and download Path View Cloud, a host based network monitoring solution from Apparent Networks.
Not only is this software as useful as a button hole, but you can download a fully functional 5 node solution for absolutely no money! In previous posts, I have discussed the fact that, despite best practice, clients continue to attempt VoIP phone deployment over DSL through VPN tunnels! Path View Cloud enables you to collect real-time network health information about key endpoints in your network. Typically, it is the remote user or the WAN points that you are going to want to study. Path View Cloud enables you to create monitoring solutions that regularly report on health checks and trigger alerts when “violations” have been detected. Yes, Virginia, there is a Santa Claus and you can see packets!
Clearly Apparent Networks believes that offering 5 free nodes will get you to order more!The offer is, however, compelling and I can tell all you cheap, penny-pinching, tight wads that will not invest in network monitoring software, that you will sleep better at night with this Path View Cloud solution in place.Network and VoIP engineers and technicians, you need this arrow in your quiver to make troubleshooting more visual!
To the sales team, I sound like a broken record as I repeated the engineering driven mantra: “A VoIP solution is only as good as the network it is build on”. No matter how many times we tell clients that you can not obtain reliable, predictable toll quality voice communications over the public Internet, they insist on having us implement it. The old marketing adage “you do not give customers what they need, you give them what they want” clearly applies and despite our best arguments to do otherwise; we find ourselves implementing VoIP solutions using VPN over DSL or Cable. The good news is that when it works, it is often useable for inter-office communications. When it does not work, it sounds like the worst cell phone call and would not be something that you would use to support business communications with a client.
In the VoIP world in general and the ShoreTel world in particular, there is a measurable performance difference between an MPLS deployment and a VPN tunnel through the public internet. An appropriately designed MPLS circuit with carrier Service Level Agreements in place will out perform the best VPN tunnel through the public internet. Yet clients continue to believe they can put a VoIP handset at the bosses house and run it over a DSL based VPN back to the “puzzle palace” and that it will perform as well as the phone on his office desk. The reality of the deployment is that this implementation seldom meets customer expectations.
A ShoreTel deployment of a remote handset for a home based work force can be accomplished under two basic models. In the more desirable, albeit more costly model, we create a “site” which involves the placement of a ShoreTel media gateway (read SG switch) at the remote location. VoIP handsets interact with the SG media gateway or call manager at the remote location for all call setup, addressing, signaling and control. In the ShoreTel world the call setup between a VoIP handset and an SG media gateway will use the MGCP protocol. This protocol is a client/server or master/slave model and when compared with other protocols can generally be summarized as complex and “chatty”. ShoreTel implements SIP for SG-SG communication, but uses MGCP for SG witch to handset call control. Once a phone call is setup up, only the RTP media stream needs to traverse the VPN tunnel, however.
The other less expensive model s the placement of a remote VoIP handset only. In this model, the handset is part of the “headquarters” site. Unfortunately this is the deployment model we see the most when clients attempt to interconnect a single home worker with the corporate network with out the benefit of a carrier SLA. A DSL, hopefully with a static IP address, and a device that can support a “point-to-point” VPN tunnel are the “minimum daily adult” requirement for VoIP connectivity. In this model, the VoIP handset is communicating MGCP over the VPN tunnel with a call manager at the headquarters location. Every handset action, from off-hook to digit key depress, is communicated over the VPN tunnel back to a media gateway at the home office. Very “chatty”.
As engineers we can talk ourselves into a coma when discussing QOS options, DSCP markings, router queuing strategies and bandwidth reservation parameters. At the end of the day, however, the only QOS “opinion” that really matters is what the users thinks! Mean Opinion Score or MOS is the measure of what users rate the quality of a phone call. Here is what we have learned after supporting hundreds of remote users on none SLA based circuits, typically VPN over DSL and Cable. Rule one: use only symetrical circuits (same up and down load speeds). Rule two: Hard phones beat soft phones; and Rule three: SIP phones beat MGCP phones. It is that simple. If we put a SIP based phone at a remote location, they will out perform an MGCP based handsets on the same circuit as measured by user MOS! The SIP phone will perform with a higher level of reliability, be more resilient to latency and jitter, and will experience significantly less call disconnects than an MGCP based VoIP handset.
If you study the hosted VoIP service provider market, you will find that the predominant VoIP handset deployment strategy is SIP based. Why is that? We could go completely geek on you and illustrate the complexity of call setup comparing MGCP with SIP setup messages, but why bother. MOS rocks. In this environment SIP deployments will yield higher customer satisfaction scores than MGCP deployments. We are sincerely hoping and praying that ShoreTel has a “SIP firmware load” on the product road map to support their family of outstanding desktop handsets as they do not have a SIP handset solution. Currently, when we have to support remote workers who insist on running VPN tunnels over DSL and Cable, we deploy Polycom and Aastra handsets to achieve maximum customer satisfaction in the wild west of internet telephony and home based workers!
Caller ID is an interesting area and we see a variety of client request regarding this functionality.On analog lines, there is not much room for configuration.Generally this information is transmitted as FSK (i.e. modem tones) in either the SDMF or MDMF format, in the silent portion of the phone company “ring cycle”.For this reason, if you answer an incoming call before the ShoreTel has an opportunity to capture the CID information, you may not see it displayed. Unlike a PRI, outbound caller ID is controlled entirely by the phone company on analog lines and ShoreTel can do nothing to change what is displayed when you call out of the system.Sometimes, if you have a number of analog lines, the phone company displays a different Caller ID on each line!If you ask nicely, and the moon and starts are in perfect alignment with Mars, the carrier might agree to have all of your analog lines display the main Billing Telephone Number or BTN of the client account.At the end of the day, outbound caller id, is what it is on analog lines.
On PRI lines, we have more control over what is displayed when you place a call to an outside party.Generally, in ShoreTel you can display either the main PRI number of your personal DID number.We have been able to spoof the PRI D channel and display any phone number you may want on an outbound call, by configuration of the Caller ID field in the Shoreware Director administration portal under Individual Users.
We are often asked if it is possible to display a different outbound caller ID on a call per call basis.Unfortunately, unless you are willing to reconfigure the Caller ID field this is difficult, but not impossible to do.( I know at least one police department and a half dozen credit and collection agencies that do this when the called on suspects might not answer the phone unless they know that Mom is calling)!Sometimes a company has multiple Brand names or company names that they are using when they place phone calls.To enable call by call, outbound CID change, we create Bridged Line Appearances or BLA’s.These BLA’s can be configured with a different called ID and the client can select the appropriate line (read Brand) to generate the correct CID on a particular outbound call.As an aside, we note that the carriers are getting more particular about D channel spoofing of CID on PRI calls.On SIP trunks it is all but impossible.The Carriers now insist that the displayed number must be a number that is within your BTN range.This limits spoofing.
Trouble shooting inbound (or outbound, for that matter) Caller ID calls on a ShoreTel PRI is fairly straight forward.Minimally, you can use the Trunk Test tool to witness the caller ID of an inbound call.To tap the actual D channel messages sent by the carrier to your ShoreTel SGT1, you will need to setup a capture.To do this, you will need to take the following steps (see video below):
(a)Turn off the Telnet Security Shell via the ipbxctl command
(b)Telenet into the ShoreTel SGT1 switch;
(c)For Analog & T1 turn on the mpm_debug_mask=-1 command
(d)For PRI use mpm_debug_mask=0X40 for called ID and Name.
Unlike the early versions of ShoreTel debug routines, the CID and call setup information is reasonably intuitive to decipher.Traces can also be used to figure out who hung up on who and other carrier CPE shoot out questions.These are useful trouble shooting tools.
Lastly, we need to make sure we understand the difference between ANI (automatic number identification) and Caller ID.ANIS is tariff differently and is not subject to the same blocking restrictions as caller ID number.Generally, if you are paying for “toll free” numbers, you want to know who is calling!The carrier delivers the information in a format that looks like <DID> <DNIS> * <ANI> * <DID/DNIS> and the SGT1 can note the *delimiter and sort this out.You should also be aware that ShoreTel will attempt to route the call based on a selection priority that starts with DNIS, DID, Extension and finally Tandem Trouncing.If no match is found, the inbound call will be routed to the “destinations” specified for the trunk group, with the automated attendant being the default.
One of the most common make/break/fix support tickets that come into the TAC center, have to do with “one way media”.In this scenario, a ShoreTel VoIP phone user calls another phone user, or places an outside phone call and the called party can hear the user, but the user can not hear the called party.We typically refer to this condition as “one way media”.We have look at hundreds of these situations, and though some were more difficult to resolve than others, they are generally attributable to a configuration error that defines the default gateway or a missing route.
Conceptually, your IP phone sits in a specific network.For example, your IP phone might have an IP address of 192.168.150.55 which is in the 192.168.150.0 network.When that device setupsup a phone conversation to another phone, media(read voice) flows between the two devices.It is important to know that the “call manager” that provides the MGCP call setup and tear down information is the ShoreTel switch that the calling phone registered with, but the actual media stream, is between the twoend points only.You can use the phonectl command to see which Shoregear gateway is managing the phone.
Generally, we experience the condition known as “one way media” when a phone in one subnet calls a phone in another subnet.In a multi-site deployment your phone may be in the 192.168.150.0 network, but the phone you are calling might be in the 172.16.10.0 network.The ability of these two end devices to set up a media stream requires that there be some routing device in the network.This routing device may be an actual router, or it might be an Ethernet switch that has “L3” (read routing ) capability.
When a device on the 192.168.150.0 network wants to exchange packets with a device on another network, it sends those packets to the “default gateway”.The default gateway is an interface on a device that knows how to “route” to the other networks.Each device knows about the devices on the network itis resident in.It also knows that if it needs to communicate witha device in another network, it needs to send that request to the default gateway.The default gateway, will then forward it on to the target device, or to its own default gateway, until it reaches a device that knows the target device.
There are a few questions you need to ask when troubleshooting one way media:
(a)Can I make a call between phones in the same network?
(b)Can I ping the ShoreTel HQ server:
(c)Can I ping the ip address of the device (phone or gateway) that reports the one way media;
There are a couple of ShoreTel related exe files that are useful in trouble shooting one way media.You are going to want to see the network from inside the network device, regardless if it is a switch or a phone. ShoreTel has a security shell that runs on phones and switches.You will need to disable this shell, to enable the ability to telnet into the switch or phone.First, you will need to enable telenet with the ShoreTel ipbxctl command.You will also use this command to telenet into a phone (see previous blog “how to telenet into a ShoreTel phone).You will then telenet into the phone and test for network connectivity by use of the PING utility.
Invariably one way media can be traced to a network configuration error.Either a device somewhere in the network has the wrong default gateway; or the default gateway does have route to the destination network.As an aside, there was a time in whichthe standard ShoreTel media stream,always used transport level port 5004.A one way media condition, generally across a WAN, might be the result of having port 5004 blocked in one direction on a firewall.From a QOS perspective, advantage to ShoreTel as we could not only prioritize Voice over Data at the IP level but also at the TCP or transport layer.With the move to SIP, the RPT media stream is moving on ports all over the map so this is no longer high on the check list.
