How to detect or manage expansion modules ?

[oliv]

Hello,

The other day, I wondered how I could detect or more generally manage expansion modules (being able to track with module is connected to a given phone) like EXP-20.

1. More specifically, when a phone boots and asks for a config file through HTTP, it is sending in its HTTP request, some details about its hardware config.
If I'm not mistaken, it is not sending anything about the number, serial number or types of expansion modules connected to it.
Including such details would allow a provisioning server to generate a more appropriate config.

2. Looking at Action URL, I can't see anything related to an expansion module being plugged or unplugged from the phone.

3. Within phone config files, there is no conditional statement allowing sysadmins to adapt phone config to the number and types of expansion modules.
I was thinking of something like:

account.1.dtmf.type = 1
{% if expansion_module.count == 0 %}
linekey.5.type = 16
...
{% endif %}
{% if expansion_module.1.type == 'exp-20' %}
expansion_module.1.key.2.type = 16
...
{% endif %}


What do you think ?

Best regards

[jolouis]

Agree that the most convenient way to implement this would be to have it show up as part of the header for auto-provisioning, though I'm not sure if the expanders are initialized at that point in order to make that actually possible.

Since expansion setup is usually tied to specific extensions it usually makes sense to build the logic into your provisioning generation scripts rather than the config itself. i.e. if the mac address matches the extension for reception, then generate the additional config for the reception expanders.

One of the things worth noting is that there is no adverse side effects for configuring expansion modules that don't exist; the phone simply doesn't do anything with the settings. So for example we have a customer who has an expander on every desk phone in their office, but not common area and meeting room phones. The provisioning file generates the expansion_module.x configs for every single request, and the phones that don't have expanders simply ignore it.

As for the type of expander, that's also kind of a mute point since realistically all the Yealink modules are basically the same from a config perspective; not really sure why you would care about an exp-20 vs an exp-40 (and you could easily solve that by checking the model number of the phone itself in the request header).

[oliv]

Yes, thankfully, having expansion keys defined in a phone that doesn't have any expansion module, doesn't hurt but any or all of the 3 features mentioned in my first would ease administration.

It doesn't happen every day but corporate users can unplug and move expansion modules from one phone to another: tracking this is currently impossible.

It would be lying if I said current situation can't last any longer: I like the way I can currently manage Yealink phones but there is always room for improvement.


I was also thinking of WiFi USB modules: it might also be useful to let provisioning server know about their presence, though, it this case, it seems it also doesn't heart to include an unused Wifi section in config files.

Please, note that in this later case, HTTP provisioning server gets phone Ethernet MAC address (which is fine) though phone uses WiFi with a different MAC address but DHCP server, if I'm not mistaken, doesn't get Ethernet MAC at all when a phone connects through WiFi.

Anyway, back to expansion module management, my wishes were expressed from most wanted to least wanted:
1. (most wanted) Upgrade User-Agent field to include types and serial numbers of expansion modules,
2. Action URL
3. Conditionals in config files

[Kevin_Yealink]

(03-30-2017 07:10 AM)oliv Wrote:  Yes, thankfully, having expansion keys defined in a phone that doesn't have any expansion module, doesn't hurt but any or all of the 3 features mentioned in my first would ease administration.

It doesn't happen every day but corporate users can unplug and move expansion modules from one phone to another: tracking this is currently impossible.

It would be lying if I said current situation can't last any longer: I like the way I can currently manage Yealink phones but there is always room for improvement.


I was also thinking of WiFi USB modules: it might also be useful to let provisioning server know about their presence, though, it this case, it seems it also doesn't heart to include an unused Wifi section in config files.

Please, note that in this later case, HTTP provisioning server gets phone Ethernet MAC address (which is fine) though phone uses WiFi with a different MAC address but DHCP server, if I'm not mistaken, doesn't get Ethernet MAC at all when a phone connects through WiFi.

Anyway, back to expansion module management, my wishes were expressed from most wanted to least wanted:
1. (most wanted) Upgrade User-Agent field to include types and serial numbers of expansion modules,
2. Action URL
3. Conditionals in config files

Dear

This is Kevin from Yealink support team, nice to know you.

Thanks for your information. Before checking with our PM, i need to double check with you:
1. For point 1, so you means that when the phone plug the EXP into the phone, then if the phone send HTTP/SIP packet out, it should carry EXP information, right? If it don't plug the EXP, it will not carry. Rgiht?
For this point, can you tell me why we need to support this feature? I think the provision server can certificate the phone information not EXP information.
2. For point 2, it is easy to understand. But please kindly tell me more usage scenario about this.
3. For point 3, so we need to create new another config files for EXP?

BR
Kevin

[oliv]

(04-01-2017 10:28 AM)Kevin_Yealink Wrote:  

(03-30-2017 07:10 AM)oliv Wrote:  Yes, thankfully, having expansion keys defined in a phone that doesn't have any expansion module, doesn't hurt but any or all of the 3 features mentioned in my first would ease administration.

It doesn't happen every day but corporate users can unplug and move expansion modules from one phone to another: tracking this is currently impossible.

It would be lying if I said current situation can't last any longer: I like the way I can currently manage Yealink phones but there is always room for improvement.


I was also thinking of WiFi USB modules: it might also be useful to let provisioning server know about their presence, though, it this case, it seems it also doesn't heart to include an unused Wifi section in config files.

Please, note that in this later case, HTTP provisioning server gets phone Ethernet MAC address (which is fine) though phone uses WiFi with a different MAC address but DHCP server, if I'm not mistaken, doesn't get Ethernet MAC at all when a phone connects through WiFi.

Anyway, back to expansion module management, my wishes were expressed from most wanted to least wanted:
1. (most wanted) Upgrade User-Agent field to include types and serial numbers of expansion modules,
2. Action URL
3. Conditionals in config files

Dear

This is Kevin from Yealink support team, nice to know you.

Thanks for your information. Before checking with our PM, i need to double check with you:
1. For point 1, so you means that when the phone plug the EXP into the phone, then if the phone send HTTP/SIP packet out, it should carry EXP information, right? If it don't plug the EXP, it will not carry. Rgiht?
For this point, can you tell me why we need to support this feature? I think the provision server can certificate the phone information not EXP information.
2. For point 2, it is easy to understand. But please kindly tell me more usage scenario about this.
3. For point 3, so we need to create new another config files for EXP?

BR
Kevin

Hello Kevin,

Sorry for being away lately and not replying earlier.

1. For point 1, I would expect it to send EXP information with outbound HTTP request. I don't see it necessary in outbound SIP requests.
Currently, outbound HTTP requests include a User-Agent header with a value such as:
Yealink SIP-T27G 69.81.0.70 00:15:65:e0:ad:f9

IMHO, it would perfect to have something like:
Yealink SIP-T27G 69.81.0.70 00:15:65:e0:ad:f9 EXP20 840171510123456789 EXP20 840171510123456999
where:
EXP20 is the type of plugged expansion modules
840171510123456789 and 840171510123456999 are S/N of plugged expansion modules

If a phone have no plugged expansion module, leaving current "Yealink SIP-T27G 69.81.0.70 00:15:65:e0:ad:f9" User-Agent header value is fine.

Quote:For this point, can you tell me why we need to support this feature? I think the provision server can certificate the phone information not EXP information.

Forgive me but I'm not certain I understand the latest part of the above remark, starting with "provision server".
For the question, I would use the following example:

For secretary phones, to monitor other office phones, it is more convenient to use expansion module keys, than it is to page among linekeys (T27P/G have 3 pages of 8 linekeys) around phone's screen.
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.


2. For Action URL, use case is the same: if an expansion module is plugged on or off, give sysadmins a mean to adapt a phone config (ie move a BLF from one key to another) without rebooting it.

3. Many popular templating languages exist.
If a phone could advertise at provisioning time its number of plugged expansion or more generally USB modules, those templating languages could be used by provisioning server to produce custom config files without any change in current config syntax.

[auch]

Ask for suggestions on how to detect or manage expansion modules.













goldclub slot

[Kevin_Yealink]

(04-10-2017 12:21 PM)oliv Wrote:  

(04-01-2017 10:28 AM)Kevin_Yealink Wrote:  

(03-30-2017 07:10 AM)oliv Wrote:  Yes, thankfully, having expansion keys defined in a phone that doesn't have any expansion module, doesn't hurt but any or all of the 3 features mentioned in my first would ease administration.

It doesn't happen every day but corporate users can unplug and move expansion modules from one phone to another: tracking this is currently impossible.

It would be lying if I said current situation can't last any longer: I like the way I can currently manage Yealink phones but there is always room for improvement.


I was also thinking of WiFi USB modules: it might also be useful to let provisioning server know about their presence, though, it this case, it seems it also doesn't heart to include an unused Wifi section in config files.

Please, note that in this later case, HTTP provisioning server gets phone Ethernet MAC address (which is fine) though phone uses WiFi with a different MAC address but DHCP server, if I'm not mistaken, doesn't get Ethernet MAC at all when a phone connects through WiFi.

Anyway, back to expansion module management, my wishes were expressed from most wanted to least wanted:
1. (most wanted) Upgrade User-Agent field to include types and serial numbers of expansion modules,
2. Action URL
3. Conditionals in config files

Dear

This is Kevin from Yealink support team, nice to know you.

Thanks for your information. Before checking with our PM, i need to double check with you:
1. For point 1, so you means that when the phone plug the EXP into the phone, then if the phone send HTTP/SIP packet out, it should carry EXP information, right? If it don't plug the EXP, it will not carry. Rgiht?
For this point, can you tell me why we need to support this feature? I think the provision server can certificate the phone information not EXP information.
2. For point 2, it is easy to understand. But please kindly tell me more usage scenario about this.
3. For point 3, so we need to create new another config files for EXP?

BR
Kevin

Hello Kevin,

Sorry for being away lately and not replying earlier.

1. For point 1, I would expect it to send EXP information with outbound HTTP request. I don't see it necessary in outbound SIP requests.
Currently, outbound HTTP requests include a User-Agent header with a value such as:
Yealink SIP-T27G 69.81.0.70 00:15:65:e0:ad:f9

IMHO, it would perfect to have something like:
Yealink SIP-T27G 69.81.0.70 00:15:65:e0:ad:f9 EXP20 840171510123456789 EXP20 840171510123456999
where:
EXP20 is the type of plugged expansion modules
840171510123456789 and 840171510123456999 are S/N of plugged expansion modules

If a phone have no plugged expansion module, leaving current "Yealink SIP-T27G 69.81.0.70 00:15:65:e0:ad:f9" User-Agent header value is fine.

Quote:For this point, can you tell me why we need to support this feature? I think the provision server can certificate the phone information not EXP information.

Forgive me but I'm not certain I understand the latest part of the above remark, starting with "provision server".
For the question, I would use the following example:

For secretary phones, to monitor other office phones, it is more convenient to use expansion module keys, than it is to page among linekeys (T27P/G have 3 pages of 8 linekeys) around phone's screen.
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.


2. For Action URL, use case is the same: if an expansion module is plugged on or off, give sysadmins a mean to adapt a phone config (ie move a BLF from one key to another) without rebooting it.

3. Many popular templating languages exist.
If a phone could advertise at provisioning time its number of plugged expansion or more generally USB modules, those templating languages could be used by provisioning server to produce custom config files without any change in current config syntax.

Dear,

Thanks for your information.

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.

For point 2, when you plug EXP, it should send signal to server, then the server will put EXP conf to the EXP automatically, right? If yes, it should be also supported by the server, it is difficult to develop.

For point 3, i think we have auto provision syntax, may be you can check it.

Best Regards,

[jolouis]

(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.

[Arish]

Thanks for the advice.




gclub android

[Kevin_Yealink]

(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.

Hi Jolouis

Let us suppose that we add EXP information in the HTTP packet and we plug the EXP.
We push phone to auto provision, phone send HTTP packet to download the cfg file from provision server.
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