(04-13-2017 03:59 PM)jolouis Wrote: (04-13-2017 01:03 PM)Kevin_Yealink Wrote: For point 1, when the phone send HTTP packet and if you plug EXP, yealink should carry EXP information. PM need to know why we need to carry those information? Such as if the phone send HTTP GET to ask for auto provision file, some provision need to certificate the phone, so it will certificate the Agent information of phone.
But fot EXP information, i need to know why we need the EXP information in HTTP packet. So i need your kindly tell me more usage scenario information.
For your question:
How can I configure something like "if this phone has an expansion module, leave linekeys unconfigured, otherwise configure those linekeys this way ..." ?
Knowing at provisioning time how many expansion module, a phone currently has, would let me tailor its config accordingly.
Do you means that the we don't set BLF key on phone side but on EXP side, right? And when you plug the EXP, the server will know how many EXP in one phone, then it will push all the BLF to displayed on EXP?
Please point out if any misunderstanding.
oliv can clarify further but since I understand the request maybe I can help explain.
Your interpretation is correct in that there needs to be a way to have the Autoprovision server know whether expanders (and how many) are connected when a phone requests its config. Oliv suggested doing this by providing the serial numbers of each expander as part of the user agent. The serial numbers are not strictly important, what matters is that there is a way for the phone to indicate that it has expanders connected to it, and how many.
Oliv's use case (and I have seen this before for our customers too) is that by knowing which phones have expanders, the auto provision can adjust to program BLFs either to the "hidden buttons" (Page 2, Page 3 BLFs), or the expansion modules. The result would be a single auto provision script can handle these two scenarios:
a) Phones with no expander can still get all BLFs by going to page 2/page 3. Less convinient but still possible.
b) Phones with expander get all BLFs on expander, and Page 2/Page 3 is not used which makes phone interface less cluttered/confusing for users.
This seems logical and hopefully would be relatively easy to implement. Even just adding something like "Exp:2" to the user agent to indicate there are 2 expanders on the phone would achieve the goal.
The Action URL and other information is probably more of a long term wish list as it would take much more work to develop I expect.
jolouis perfectly summarized my request ! Thanks you very much for this !
A side note, just in case phones accept different kinds of expanders in the future (one with color screen, one with 60 buttons, ...), maybe a string like "exp20:exp60" should be used to correctly inform provisioning server about the type and order of connected expanders.
(04-14-2017 06:30 AM)Kevin_Yealink Wrote: 1. The server only have cfg file, how does the server recognize Agent information in HTTP packet?
2. For the BLF key configuration, you have to pre-configure it on Yealink cfg file, how many key you add in the cfg, then the phone download the cfg and update.
And we use different provision syntax for the line key and exp key.
So we don't think it is convenience to carry EXP information in the HTTP packet.
Please point out if any misunderstanding.
BR
Kevin
Hello,
All the above reasoning is correct for what I would call, static provisioning server with which config files are hand-edited by sys admins, simply served to requesting HTTP clients.
With today's web development tools, it is quite easy for sys admins (DevOps trend) to develop dynamic provisioning server with which config files do not even exist at the time the provisioning server receives a request.
Upon request reception, dynamic provisioning server would simply:
- reads User-Agent header content to get MAC address (and hopefully expanders presence),
- use pre-configured templates to generate on the fly y00000000xxx.cfg, MAC.cfg or other files (phonebook, vpn certificates, ...) depending on data found in User-Agent header or hundreds of other factors (time of day, IP range, ...), if this ever makes sense.
Dynamic provisioning servers cannot be implemented with TFTP as this protocol is only designed to serve files but dynamic provisioning servers perfectly match with HTTP/HTML: content is customized and build on purpose when requested, not before being requested.
Hope this helps.