Announcement

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

  • Shoretel 485 phones

    I recently up graded one of our locations from 14.2 to Connect Build 21.84.5543.0. I'm having issues with multiple 485s not connecting to VM, when VM button is pushed. They get an error saying "Failed to connect to server" the phone works ok just an issue connecting to VM. They were working before the upgrade.
    Anyone run into this issue?

  • #2
    I would make sure the fully qualified name matches the site generated certificates. You may need to just delete the certs and re save the name of the site. You can also look at the phone from info view and confirm the directory field value matches what you expect to see (Mute 4636#)
    Lance Paddock
    BTX | Business Telephone eXchange
    1(800) 289-0299

    Comment


    • #3
      Thanks for the advice, I'll take a look.

      Comment


      • #4
        I checked the certs and all 18 systems that I upgraded match the cert format as the site in question, FQDN is correct and matches. Not sure what I expect to see in the phone directory field.

        Comment


        • #5
          The fully qualified name of your server should be in the phone directory field. If DNS is not playing well you can add the ip as the fully qualified domain name. I know updating from pre connect to connect puts the common name but that does not play well and from scratch it won't let use just a common name.
          Lance Paddock
          BTX | Business Telephone eXchange
          1(800) 289-0299

          Comment


          • #6
            Further more, I find that uploading the phone logs gives additional information into CAS errors. I have had the same thing happen when upgrading to Connect, and going through the process of re-creating the CA certificate on HQ to use SHA256 per migration guide. In those cases I've had to delete the certificate like Lance suggested - but be careful if you use Contact Center, as you can break the communication between the two, and prevent agents from being logged in. I would take snapshots of both servers before doing the above if that was your case.

            Edit: as a workaround to just get things going, depending if it is a certificate problem, you can use a registry hack to allow untrusted certificates so CAS works on the phone:

            1. Open regedit
            2. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Contro l\SecurityProviders\SCHANNEL
            3. Create a new 32 bit D-Word entry named ClientAuthTrustMode
            4. Put 2 in the data field
            5. Reboot server

            You would make this change on the controlling server for the switch that the phone is connected to (should also be where the CAS URL is pointing to)

            There's a guide I reference quite a bit when running into these issues you can find here:

            400 Series Phone Fail To Connect CAS

            I'd print this thing out to PDF but it's got my name on the top and I can't remove it. BTX has a link but it's not the latest one:

            http://customers.btxchange.com/Manua...20TO%20CAS.pdf
            Last edited by Lance; 06-22-2018, 10:05 AM.

            Comment


            • #7
              Thanks Lance, I'll have them check that field. Its weird because they also reported that a few times a day the phone will black out and say No service for a few seconds and come back on-line. This doesn't happen with the 230s but obly the 485s

              Comment


              • #8
                Are the phones having the problem isolated to a site/sites managed by one particular DVS? We had a similar problem after upgrading to Connect. I verified everything was correct with our certs first, but all was well. I simply rebooted the DVS managing the problem phones and it resolved the issue for us.

                Comment


                • #9
                  I just created this post here ---> " IP400 Series Phones Fail to Connect to CAS" to reference Augie's link to an area that you may not have been able to reach.
                  Lance Paddock
                  BTX | Business Telephone eXchange
                  1(800) 289-0299

                  Comment


                  • #10
                    I found that when that happens they hit voicemail and it says connecting - they just have to then hit CallVm and they can proceed. For some reason the upgrade insists they hit both of them, but not for everyone.

                    Comment


                    • #11
                      I was told by our support partner that ShoreTel said that its a known issue and not to move from 14.2 to Connect, fix will be out in mid-August

                      Comment


                      • #12
                        So we are starting to see even the 230G phone are experiencing issues with randomly going to No Service and after a couple of minutes they will connect again. Is anyone experiencing this too, we are running Build 21.84.5543.0 at all of our affected sites

                        Comment


                        • #13
                          I had that issue on 14.2 and the cause was that some of our pbx switches were in a different vlan. Although inter vlan routing was enabled so we could ping the pbxs at all times. For some reason we would get disconnects for a few minutes, then the phones would automatically reconnect. In the director diagnostic connectivity screen we would see the switches all green and then after a few minutes they would all go red or yellow (can't remember the colour right now). But while they were disconnected, ping was STILL WORKING.

                          So basically your issue could be a disconnect between the phones and pbx switches, which may not necessarily be network issue. It could be certificates, routing or anything that is causing the pbx to lose connectivity with the phones.Also recall that there are certain ports Shoretel uses for connectivity so while icmp and port 80 are fine the issue may be somewhere else.

                          I had another customer with a CAS issue and the issue there was that they had an illegal character in their domain name. So although the FQDN was correct in the certificates and matched the server. It still caused CAS errors and the phones would not connect to the server for VM, directory, State etc. The 200 series phones however were not affected.

                          Comment


                          • #14
                            First of all do the 400 series phones need a certificate?? What if we don't want to use certificates.
                            Yesterday 09/27/18 we had a 485 phone start to acting weird (Service NOT Available) 3 or 4 months after upgrading from 14.2 to Connect (21.84.5543). I looked at the phone under the Telephones section, which showed the expiration of 09/27/15:09 which is when the phone started to act up. Now the phone 2 or 3 times a day will display Service Unavailable and the expiration date changed to today.

                            Comment


                            • #15
                              Hi,the shoretel system has always used certificates. It is a part of the way that the phones register to the server and encrypt all of the conversations.

                              The certs are stored in the keystore folder and this is why you have to delete that folder if you change the IP address, mac address or fqdn. It is removed from the phones using the MUTE CLEAR command. 400 series phones are particularly sensitive to certificate issues.

                              I believe that you do have a certificate issue. The problem is finding where the holdup is.

                              Comment

                              Working...
                              X