Category: Voip Service & Solutions

A typical trouble ticket might sound like “when another extension calls me, I can hear them, but they can not hear me”!  Actually, one of my personal faviroites.  Over the years I have come to learn that this is usually the result of one of two issues: someone has the wrong default gateway; or port 5004 is being blocked by some firewall in one direction.  As we move more and more toward SIP and media streams move away from a dedicated port, this issue is almost always a network configuration error.

So which device has the wrong default gateway?   That takes some dedective work.   Generally you will telnet into the ShoreTel SG media gateways and check the configurations.   Media stream between phones generally do not need an SG switch beyound call setup.  The media stream, once the call is setup, is between the two phones.   For this reason, you will want to tenet into the phone and “see” the network from the phone’s percepective!   To do this, you will need to know the ShoreTel methodology and process.

Security on the SG switches and phone, requires that you start the process from the ShoreTel HQ server.   There is a specific subdirectory that you need to be in to launch the various utilities.  This silent viedo walks you through the process of using one utility, phoneCTL, to telenet into a phone and look around.

This is one of those trouble tickets that keeps an engineer awake at night. A V switch was installed at a remote site to provide Automated Attendant and Voice Mail services for that site.   The V switch was one of three switches at that site and each switch had analog CO lines connected.   For reasons that nobody could explain, the observed behavior was that the AA would not change from On Hours to Off Hours as scheduled. An observed behavior, does not really state the problem!  (read: lesson learned) What we learned is that the AA did in fact actually change per the schedule, but only the lines connected to the two other non V switches received the correct prompt per the schedule.   The CO lines connected to the V switch, (which included the main number and next three lines in hunt, but of course) ,  did not get the correct AA greeting.    Now, as nightmares go, this was about as difficult as they get when you are attempting to distill a problem statement.   As everyone called the main line,  everyone thought the AA was not changing per schedule.   Only by calling lines not terminated on the V switch did the real problem statement emerge.

ShoreTel has now assigned a known defect number to this behavior. “The issue you are experiencing has been addressed in defect 1-34192469.  The defect has been corrected and is pending a patch release.   Once the patch release hits our QA group for testing and validation, we will be able to provide a rough estimate on a release date”.

I could have listened to my mother and finished law school, but no.  I wanted to be a telecom entrepreneur ……

Getting old is a pain in the neck!   Literally and figuratively!  I am trying to figure out the benefits of getting older and I am not coming up with a very long list.    You built a library of experience, I guess that must count for something.   There is new generation of telecom professionals that have no idea what a cross bar switch is, but so what.   Nobody is really missing buggy wips either.   In the old “Bell System”  (I have really dated myself now, as google demographics tell me my readers were born post breakup) there was a specific regulation against the interconnection of analog telephone lines on an PBX.  Now part of that restriction was the Bell System being a bunch of anti-competitive jerks, but there were also real technical issues for not doing so.   Analog lines are most useful in man to man communication.   The issue here is the concept of “answer supervision” and “calling or callED party disconnect”.   

When you answer the ringing phone in your house, the answer supervision is actually your ear.   You can “hear” the other party.  yes, there is a line reversal or voltage change but being a two wire loop is nothing like being a trunk line.   For that reason we use trunks to interconnect machines to machines.   Every go to make an outside phone call, and find someone on the line?   Great example of “glare” the concept of a call ringing in just as you where grabbing it to make an outside call.   Analog lines are good for key systems with winking and blinking line keys that show everyone who is on what line, but they are a real annoyance on a PBX system.

Answer supervision is poor if it exists at all and glare can be a real issue.   Throw a couple of Centrex lines in the mix and you will get some real extra fun features.  Nothing like having analog lines connected to your PBX that have feature treatments you did not know about.   It is always phone when the phone companies VM picks up before your ShoreTel VM system does!  As a rule you might like to have one analog line at a site for 911 and power failure, but the idea of running a ShoreTel PBX with a rack full of analog lines, actually makes me ill.   Judas Grunt,  it is the 21st century already!   Can you spell SIP?

ShoreTel does a reasonably good job with analog lines given the real disadvantage they have in the area of answer supervision, etc.   ShoreTel actually goes off hook on these lines at timed intervals.  If it does not “hear” dial tone, it marks the line out of service.  If you are really cleaver, there is a trick to recording the sound made when the line goes “off-hook” so you can retrieve the wav file and play it back locally.  A great life saver when you are in Portland and your trouble shooting a local loop in a remote site, just outside Minute, ND and nobody is in the office.

It amazes me that we still have analog lines on PBX systems, but as long as we do, we might as well learn how to deal with them.

You have dutifully enable Differential Service Control Points on you WAN network, to enable EF for voice traffic!  This is the minimum daily adult requirement for QOS on a WAN connection.   Prior to Version 9+ ShoreTel did not mark all traffic with a DSCP value, only media traffic between end points.   If you think this through, what happens to the media stream played out by the ShoreTel server during Automated Attendant of Voice Mail use?  Would this media stream across the WAN using the inter-site codec setting, typically a G.729 vocoder?  Or would it stream at G.711?   Given that there is no DSCP value on this media stream, that might be a QOS problem across a WAN connection.   Would it be possible to set up a  MATC H for the source IP address of the ShoreTel Server and through these IP packets into the EF queue?

To improve this situation, ShoreTel enabled “media proxy” on the Fuji or full size 19” switches that have been shipping prior to Version 7.    In this configuration, if a caller across the WAN reached an extension at another site, and that extension RNA forwarded to the VM system, the media stream would be have different end points.  At first you would think that the media stream would be between the originating extension and the Voice Mail server, but it is not.  It is in fact, between the originating extension and a switch at the HQ site (one of the reasons you always need a switch at the HQ site).  A switch at the HQ site would then proxy the media stream to the VM server, transcoding G.711 and G.729 to assure the correct vocoder across the WAN.   In this way the, the source IP address of the server is irrelavent for QOS purposes!

Now with the introduction of the ½ size switches, this is no longer the case.  Apparently with the release of 7+ the server is capable of streaming G.729.   So we need to be aware that an installation using the new switches, will no longer proxy for the VM media stream.    Additionally, there is a requirement that you set the number of media streams that can be transcoded at any one time.   This setting is in the registry of the ShoreTel Server and should look something like this:

Path: HKEY_LOCAL_MACHINE\SOFTWARE\Shoreline Teleworks\TDIMedia

Key: MaxNoOfG729Channels

Type: DWORD

Default Value: 40

This setting is suppose to be enabled on versions 7+, but if you are upgrading you may have to create and set it manually.    Clearly, optimizing your WAN for QOS is an essential element of providing toll quality voice on any VoIP solution.   Knowing what is class marked with DSCP and what is not, is an important element of achieving the desired result.   Check this issue carefully!