Yealink T41P & T46S provisioning problem

[Lyndon]

Hi! Wonder if you can help, just about to move over to Vodia. Tested with Yealink T48S and everything working. Provisioned Yealink T23G fine also. Trying to provision Yealink T41P and T46S and having issues.

This is what I'm doing:

1. Select extensions in Vodia, enable "Open accounts for MAC based provisioning". (MAC address, make & model have already been assigned to the extensions), 30 minute countdown starts.
2. Factory reset handsets.
3. Login as admin/admin.
4. Enter http://vodia_public_pbx_ip to provisioning URL
5. Click "Confirm" then "Auto Provision Now"
6. Handsets download and then reboot.
7. After reboot, can still log into handset with admin/admin (not password set on Vodia), under account details, username = MAC address, not extension. Other extension details remain blank. Server host is just "pbx" rather than "vodia_public_pbx_ip". Provisioning URL has changed to http://vodia_public_pbx_ip/yealink-MACADDRESS.cfg. No link icon displayed next to extensions in Vodia. Time on handsets is incorrect but handset think they are registered (to their MAC address account).

Vodia = v66.0.6

Yealink T48S = v66.82.0.20 (working)

Yealink T23G = v44.84.0.125 (working)

Yealink T46S = v66.85.0.5 (not working)

Yealink T41P = v36.81.0.61 (not working)

[Lyndon]

So fixed it, but don't understand why I had to do this, so an explanation would be great.

Under System Level, I went to Phones > LAN Devices and there I saw the two devices that were struggling to provision.

I clicked the Setup button corresponding to each extension, changed the domain from localhost to the correct domain, and selected the appropriate extension then clicked Save. The handsets then provisioned. 

When I go to Domain > Extensions, I saw the two extensions listed with duplicate MAC addresses. I have therefore removed one of the duplicates.

My question is, why did I have to do this for two handsets, and not all, and why is this step even neccesary when the MAC addresses are already listed against an extensionin a domain?

[Vodia PBX]

The LAN provisioning set up a temporary registration to make the phone believe that it is provisioned. When the admin assigns the MAC to an extension, the PBX sends a sync request to the phone which will start the provisioning process again from the start with the real config information. If nothing unforeseen happens, this saves a lot of time for doing the manual steps. 

If the registration gets lost for whatever reason, that sync request will obviously fail and the phone will just sit there. 

All in all, the LAN provisioning is more like a time saver, but whoever is installing the phone should still be able to log into the phone web interface and manually set the provisioning URL if anything goes wrong.

[Lyndon]

I think the problem was possibly due to entering the MAC address on an extension, but then pressing 'Save', instead of clicking the plus (+) button, which then asks you for the make and model? I haven't tested this to confirm, but following a conversation with a colleague am wondering if that's what might of happened and why the handsets weren't provisioned correctly until I'd assigned them in LAN devices. If so, I think some error handling could be built in to prevent 'Save' from being pressed if a MAC address is entered  without clicking the + button?

[Vodia PBX]

Yea, when you use the + in the MAC list field, you don't actually have to save it any more. Although it should not hurt either. Its important to make sure that the MAC is ready for pairing, which you can do below in the history tab (or in the extension list with the action dropdown). In the history tab, we have added a count-down timer where you can see how long the pairing is still on.

[Vlad]

Lyndon thanks for your initial post. You saved us a lot of time troubleshooting this issue. We are experiencing exactly same issue as you described in your first post (step 7).

A question to Vodia Team. A scenario:

1. We create all domain settings (General settings, Service flags, Extensions, VoiP phones etc.) via API first.

2. Then, we open account for MAC based provisioning (via GUI) and factory reset the phone.

3. While the phone is rebooting, it's getting the PBX address from the Yealink RPS.

4. After that, the phone requests the config from the Vodia PBX, but it doesn't get provisioned with the account settings, it's exactly at the same state described in step 7 in the first post of this thread. The Vodia log shows that phone config request is reaching the PBX, but the PBX can't match it to any accounts, and the PBX pushes a generic config (not sure how it's called in Vodia). The phone will be sitting with that generic config forever.

5. Finally, if we go to Extensions--> Select the extension in question --> Provisioning ( Bind to MAC address is populated with the phone's MAC. It has been populated via API) and just press Save. The phone immediately gets fully provisioned with the account settings. It looks like pressing Save (without making any changes), makes Vodia push the extension config.

UPD. If we create VoIP phones settings via API, and then (before factory resetting the phone) we just press Save in Extensions--> Select the extension in question --> Provisioning section. Then, we factory reset the phone, and it gets provisioned with the account settings. Looks like the phone doesn't get bound to MAC unless Save is pressed?? 

What are we doing wrong? Can this be fixed as we would like to automate domain provisioning as much as possible?

We are on ver. 66.0.5.

Thank you

[Vodia PBX]

Please make sure that you are using the release Yealink template. We have seen cases where the customized templates did not do the authentication {require-credentials} and then the template is rendered without a user. 

The other thing is that you might have to start the MAC pairing explicitly like you would do from the extensions list web page or the history section in the provisioning tab for the extension.

[Vlad]

6 hours ago, Vodia PBX said:

Please make sure that you are using the release Yealink template. We have seen cases where the customized templates did not do the authentication {require-credentials} and then the template is rendered without a user. 

The other thing is that you might have to start the MAC pairing explicitly like you would do from the extensions list web page or the history section in the provisioning tab for the extension.

Thank you for the prompt response. This is a recently installed Vodia PBX instance. The Yealink templates haven't been touched/changed. The issue has been found while provisioning a first customer on this PBX instance.

Sorry, not sure that I understand the second part of your message. Do you suggest going to the Extensions web page, and then pressing "+" in the MAC column for each extension, and then manually populating "Bind to MAC address" field? If so, then we are trying to automate this to avoid mundane and time-consuming tasks. Imagine doing that for 200-300 extensions   

The script posts extension, mac, vendor and model to the 'rest/system/prov_phones' (VoIP Phones section). Then, if we check Provisioning section "Bind to MAC address" is populated with the phones MAC. 

However, if we don't press "Save" in the provisioning section for each extension before the phone sends a config request, the PBX can't match the request to the extension. It's as if a DB record of MAC-extension binding doesn't get created unless "Save" is pressed.

We are super impressed by the stability, ease of management, and a possibility of automation. If only you guys could help with this automation question, it'd be a life-saver for us   

 

[Vlad]

Solved. The solution is to POST MAC in the Extension-Provisioning settings instead of the VoIP Phones section.