Announcement

Collapse
No announcement yet.
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • VPN Concentrator - looking for the good and bad

    I have already searched and not really found much, but I am looking for both good and bad on the ST VPN Concentrator solution. We might be closing one of our offices and I need to keep a few sales people in that market, so we might put ST phones in their homes or in a rented temp space.

    How are the experiences using the VPN Concentrator? We already have the correct phones for this IP 560G's, so we don't need to purchase any phones, are additional licenses needed, other than the licenses on the Concentrator?

    Please let me know, I have a few months, but want come up with options, softphone might be another option as well as Office Anywhere.

    Thanks,

    Derek

  • #2
    We have deployed the vpn concentrator. We haven't used it a lot but when I took it home it was easy to use and the call quality was great (but that depends on your internet service). The only licenses you need are on the vpn concentrator and then you will need a extension/mb license, but assume you already have that (it is controlled through director). Let me know if you have any other questions.

    Comment


    • #3
      trouble with vpn concentrator

      kjavernick, Did you encounter any problem to setup vpn concentrator? I am having a problem to setup.
      "FTP Server Unreachable" message display on the phone. Any help will be appreciated. Thanks
      Last edited by pcho; 06-09-2009, 03:45 PM.

      Comment


      • #4
        I didn't experience any problems, I am assuming that you are using version 8.1 (vpn will only work with this version)? Are you using DHCP and is it set correctly in the vpn concentrator? Send me a message if you need more info, I have screen shots of our system.

        Comment


        • #5
          The software version of the vpn concentrator is 8.10 and DHCP setup is correct, because the vpn concentror showing the client phone connection with ip address I've setup on the vpn concentrator. [email protected] is my email address. I will be appreciated with any help. Thanks in advance.

          Comment


          • #6
            Originally posted by pcho View Post
            kjavernick, Did you encounter any problem to setup vpn concentrator? I am having a problem to setup.
            "FTP Server Unreachable" message display on the phone. Any help will be appreciated. Thanks
            We just finished a demo of the VPN concentrator and we are not buying it as the voice quality varied greatly during the day. During the setup, there were a couple of issues that are not very well documented. When you assign the IP of the VPN box, it does not ask for a default gateway, meaning you need to add some static routes in there. Also the IP address of the FTP server needs to be your internal IP, if it is on a different network segment than the VPN box, you need to have a static route in there or it will not be able to talk to it.

            Hope that helps.

            Derek

            Comment


            • #7
              Well, it depends

              Summary:
              Don't do it if you have out-of-state users. :no: Use SIP phones or Office Anywhere instead.

              Detail:
              We have deployed the VPN concentrator for two of our larger, multi-site ShoreTel customers with VPN phones deployed across the country to individual users' homes, and it has been nothing short of a HUGE maintenance pain. Although the solution is a fantastic one on paper, the system has some fundamental issues that just don't make it a dependable "business-grade" solution in certain scenarios.

              There are a few minor gotchas like the inability to change the phone's clock time to the time zone the user is in (there are a few "workarounds" involving deploying a local NTP server). There have also been intermittent issues with the VPN dropping connection and requiring the phone to be restarted. In all fairness, I think the latest firmware release has addressed some of those dropping issues. These issues are not deal-breakers either, so long as the phone calls are clear...

              However, the nail in the coffin for this solution lies in the fact that audio quality is a complete hit or miss for user deployments. In our experience, some users can use it without a hitch, whereas others are constantly plagued with audio problems.

              After much research and "QoS-aware" network engineering to try to resolve the issue, including deploying ingress and egress QoS devices on the edge of both the business internet connection (which houses the VPN concentrator) and individual user's phones, we have found the issue has little to nothing to do with bandwidth availability nor packet queuing, but with latency!

              Usually, VoIP calls can be carried out just fine with up to 250ms of latency before it starts to interrupt conversational capability. When using UDP as the data transport protocol, as long as all packets share the same amount of latency (ie low jitter) to the destination, then audio just arrives a little late at the receiver end. Jitter buffers take care of this no problem-o.

              HOWEVER, the VPN phone solution uses a VPN tunnel established over TCP (using the TCP/443, ie https) as the port. Although this makes for a really easy remote phone deployment, there exists a fundamental flaw with using fixed bit-rate codecs encapsulated within a TCP stream. Without getting too detailed into the way TCP works, the essence of the problem is that x TCP packets must be acknowledged by the receiver before the sender can send the next x set of packets to the receiver. Under good to excellent network conditions (latency <85 ms RTT, low jitter) this is fine because the ACK rate can keep up with the flow of packets to keep the audio stream intact and sending without delay, allowing the underlying encapsulated RTP packets can get delivered to the end devices without any problems.

              In cases with medium to high amounts of latency (> 90ms RTT), the TCP packet ACK response rate begins to interrupt the flow of audio because packets containing the encapsulated audio are held back or in some cases resent depending upon the rate of ACKs. If you add jitter to the mix (std devation +/- 35ms of avg latency), the problem is amplified even more. The translates to really bad audio quality because the encapsulated RTP packets are missing or late, which wreaks havoc on jitter buffers.

              In general, it is known that TCP is great for file transfers and "reliable" data transmissions, but it is not very good with real-time audio. In fact, UDP was more or less invented for real-time media transmission because TCP requires nearly perfect network conditions to work properly for streaming media (unless you have a killer algorithm like Skype's with a VBR codecs and adjusting TCP windows and the like to make it work).

              All that being said, ShoreTel seems to have implemented some mechanisms that allow the solution to work under slightly less than perfect network conditions. And if your users can achieve those network conditions back to the VPN concentrator, the phones actually work quite well. Problem is, you need to do your due-diligence ahead of time to determine what the network conditions are to evaluate if the phones will work for you or not.

              In our specific cases, the phones worked great for users that were in surrounding states. In general, the greater the geographic distance the user was from the VPN concentrator, the higher, and more severe, the complaint rate of audio problems. In all cases, we found a direct correlation between network latency from the home user's internet connection to the VPN concentrator and the user's "hate" towards their ShoreTel phone. We found this to remain true even if users had ridiculous Internet connections (ie 30 Mbps down / 5 Mbps up).

              All that is needed to test for suitable network is a ping and/or traceroute from the user's computer to the IP address of the VPN Concentrator (or an IP on the same subnet). In all cases where we had reports of audio problems, a traceroute would show 18+ network hops and latency >100 ms from the user's home network to the corporate VPN concentrator.

              Our customers demanded a fix to this problem (of course), and ShoreTel TAC was of zero help (even though they are usually AWESOME), largely because I think this problem really doesn't have much to do with their hardware or software (besides it's fundamental design "flaw"). What we ended up doing was deploying UDP-based SIP clients (Polycom IP SoundPoints or CounterPath Eye Beam softphones) through a SIParator and it works absolutely fabulously (at the exact same users' location with the same ISP). Fortunately the 230g VPN phones could be redeployed within the office or at other local remote user's homes.

              The bottom line is the VPN phone solution is VERY dependent upon the home user's ISP, and besides having to worry about bandwidth availability, you also very much have to worry about latency. This could equate to some pretty hefty "pre-sales" engineering time just to see if the solution would work. Oh, and don't forget that a user may one day upgrade their home internet to something with more bandwidth, but that new ISP may have a worse backbone network exchange to get to your VPN concentrator's internet connection, which means the phone no longer works well "even though I upgraded!".

              IMHO, ShoreTel should provide some "Recommend Home-to-Office Network Conditions" that are "certified" to support the VPN phone solution, because quite simply this product doesn't work for users that don't have a good internet condition or ISP (again, even though they have plenty of bandwidth) at home. We lost a lot of time and money coming to this conclusion which is why I have made this post so darn long to help other partners avoid such a huge pitfall and understand why this is the case.

              Feel free to contact me with any further questions, and best of luck with your project!

              Comment


              • #8
                Matt

                I'm interested on knowing how you configured the Ingate device to work with SIP clients. Can you share any white papers?

                Comment


                • #9
                  We use 2 VPN concentrators and they work great.

                  The whole key to getting good quality on the calls is having a dedicated internet connection to the VPN Concentrator. I found out that if you share an internet connection with the VPN concentrator its going to affect sound quality if someone is downloading something.

                  Also the key is having good internet on the other end where the phone is being used. If all possible DSL works best, where as I found out that when you use a cable modem through Comcast for example they tend to mess with the voice packets, as they want to sell you their crappy phone service instead.

                  Comment


                  • #10
                    We recently went with a ShoreTel VPN concentrator (before reading this post) and have been having the same exact problem with our out of state users. After reading your post it helped me determine that we too need an InGate replacement but was wondering if you went with an InGate SIParator 19/51 unit offered through ShoreTel or went with a unit direct from InGate? Also, how well do the SIP phones work with the ShoreTel Director?

                    Thanks

                    Comment

                    Working...
                    X