Solved Yealink phones - preconfigured extensions not provisioning when reset

Discussion in '3CX Phone System - General' started by boldtech, May 4, 2017.

Thread Status:
Not open for further replies.
  1. boldtech

    Joined:
    Nov 19, 2009
    Messages:
    15
    Likes Received:
    0
    I've searched everywhere and am not finding an answer so I thought I would break down and ask for some guidance.

    So, we've had several new 3cx projects the past month after not doing any rollouts for 5-6 months. One was an existing 3CX we had rolled out 1 year ago with existing Polycom phones, and when they recently moved into new offices we replaced all the phones with Yealinks. The other project is a new 3cx in a 60 unit condo. We currently have that one stood up in our office with all the new switch gear and firewalls, so what we have is what will be onsite. We are running the latest 3CX V15 and all Yealinks, a mix of T42/46 G and S models.

    So, the issue. PnP is working fine when we throw the phones on the network. We can see them immediately, and we can assign them to an extension no problem. However, if you do a factory reset of a phone, it will come back up as a new phone, even though the extension still has the phone attached with the correct template and MAC address. Not until we go in and assign the phone to the extension again will it then provision and download the config.

    It used to be we could do a factory reset of the Yealinks if there was any issue and know that they would automatically reprovision correctly, but we can't seem to get that to work now. We always have to manually reattach the phone to the extension in the gui. For the life of me I can't figure out what has changed, and this is happening across several clients now.

    I don't want to have to manually assign 70+ phones to extensions, or have to worry about going in to the gui every time we need to reset a phone for some reason. My plan was to get the MAC addresses scanned and input on the extension spreadsheet to import and then just label the boxes prior to going onsite, but if I can't get these to automatically provision when plugged in it's a moot point. =)

    What are we doing wrong? Has something changed in the way 3CX provisions now?
     
  2. Panayiotis_3CX

    Panayiotis_3CX Support Team
    Staff Member 3CX Support

    Joined:
    Apr 26, 2017
    Messages:
    165
    Likes Received:
    7
    Hello @boldtech,

    When a phone is reset to factory defaults, you will have to manually provision it again, this is normal. The only way that this is done automatically is with Option 66. This is done from your DHCP server. Please see the link for more information.

    https://www.3cx.com/sip-phones/dhcp-option-66/
     
  3. JasonNadeau

    JasonNadeau Member

    Joined:
    Oct 14, 2015
    Messages:
    262
    Likes Received:
    46
    Alternatively, use the yealink rps to redirect to your 3cx provisioning URL. If you don't have a yealink rps account ask your yealink distributor for one.
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  4. boldtech

    Joined:
    Nov 19, 2009
    Messages:
    15
    Likes Received:
    0
    Sorry, forgot to mention that. We do have Option 66 set using the provisioning link, but it doesn't seem to matter. After the factory reset and reboot the phone sits at No Service and never grabs the config. I'll do some more testing today and grab some packets so I can see what's going on.
     
  5. boldtech

    Joined:
    Nov 19, 2009
    Messages:
    15
    Likes Received:
    0
    We've never messed with the RPS before, perhaps it's time to look into that.
     
  6. giwm

    giwm New Member

    Joined:
    Sep 27, 2016
    Messages:
    217
    Likes Received:
    36
    @boldtech: Are you provisioning VLANs and not putting the phone on the correct VLAN after doing a factory reset?
     
  7. boldtech

    Joined:
    Nov 19, 2009
    Messages:
    15
    Likes Received:
    0
    Geez, figured it out, it was Option66. I went back and really looked at the setup and in one case, we had new servers and subnets after the move and option66 was not configured on the new scope. On the other one, new firewalls doing DHCP and option 66 was also set on the wrong subnet. Sometimes it's the obvious stuff that gets you. =)

    Thanks for pointing me in the right direction. =)
     
Thread Status:
Not open for further replies.