Yealink W52P config files
-
Tagging:
@art_of_shred, @Mike-Ralston and @JaredBusch -
Well, after hours of troubleshooting, pizza, and analyzing Wireshark packet captures, I've come to the conclusion that something with our local provisioning server is causing the Yealink phones not to get their entire configuration files, and of course, can not properly apply any parameters to the phone. Our Developer who wrote the website code is reviewing it now. The strange thing is that the provisioning server works perfect with Grandstream phones, and Polycom phones...Yealink seems to dislike it however.
-
@fuznutz04 said in Yealink W52P config files:
Well, after hours of troubleshooting, pizza, and analyzing Wireshark packet captures, I've come to the conclusion that something with our local provisioning server is causing the Yealink phones not to get their entire configuration files, and of course, can not properly apply any parameters to the phone. Our Developer who wrote the website code is reviewing it now. The strange thing is that the provisioning server works perfect with Grandstream phones, and Polycom phones...Yealink seems to dislike it however.
Why would your provisioning server be a webserver? Most of the time this is a TFTP server. I mean HTTP and HTTPS are supported, as well as FTP and TFTP, but TFTP is standard.
The Yealink admin guide shoes the examples in the appendix. Are you sure you put the URL correctly into the phone in the first place?
-
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
Well, after hours of troubleshooting, pizza, and analyzing Wireshark packet captures, I've come to the conclusion that something with our local provisioning server is causing the Yealink phones not to get their entire configuration files, and of course, can not properly apply any parameters to the phone. Our Developer who wrote the website code is reviewing it now. The strange thing is that the provisioning server works perfect with Grandstream phones, and Polycom phones...Yealink seems to dislike it however.
Why would your provisioning server be a webserver? Most of the time this is a TFTP server. I mean HTTP and HTTPS are supported, as well as FTP and TFTP, but TFTP is standard.
The Yealink admin guide shoes the examples in the appendix. Are you sure you put the URL correctly into the phone in the first place?
Since we have cloud VPS servers, I wanted a secure way to send provisioning information to the phones. We achieve this by using HTTPS. We tried to use the build in EndPoint manager for provisiining via HTTPS, but it was lacking some features that we wanted. Plus, with a centralized provisioning server, we have a central point for the files and if we ever choose to move VPS providers, making changes to all config files and pointing to a new server would be quick and almost transparent to the client.
Yes, the URL was correct. We direct every client to the central server, and then based on thier individual login, we direct them to their specific files. The code that does this operation on the web server does not play well with the Yealink phones for some reason. We cleaned it up and think we are almost out of the woods. Probably a good thing...eyes getting heavy.
-
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
Well, after hours of troubleshooting, pizza, and analyzing Wireshark packet captures, I've come to the conclusion that something with our local provisioning server is causing the Yealink phones not to get their entire configuration files, and of course, can not properly apply any parameters to the phone. Our Developer who wrote the website code is reviewing it now. The strange thing is that the provisioning server works perfect with Grandstream phones, and Polycom phones...Yealink seems to dislike it however.
Why would your provisioning server be a webserver? Most of the time this is a TFTP server. I mean HTTP and HTTPS are supported, as well as FTP and TFTP, but TFTP is standard.
The Yealink admin guide shoes the examples in the appendix. Are you sure you put the URL correctly into the phone in the first place?
Since we have cloud VPS servers, I wanted a secure way to send provisioning information to the phones. We achieve this by using HTTPS. We tried to use the build in EndPoint manager for provisiining via HTTPS, but it was lacking some features that we wanted. Plus, with a centralized provisioning server, we have a central point for the files and if we ever choose to move VPS providers, making changes to all config files and pointing to a new server would be quick and almost transparent to the client.
Yes, the URL was correct. We direct every client to the central server, and then based on thier individual login, we direct them to their specific files. The code that does this operation on the web server does not play well with the Yealink phones for some reason. We cleaned it up and think we are almost out of the woods. Probably a good thing...eyes getting heavy.
You left out some serious information in your initial post then. Notably HTTPS != "web server" as well as you are authenticating to the webserver somehow?
That is all horribly complicating things and leads me to question the over all goal that led to this design. But you apparently have the developers working around the issues already.
-
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
Well, after hours of troubleshooting, pizza, and analyzing Wireshark packet captures, I've come to the conclusion that something with our local provisioning server is causing the Yealink phones not to get their entire configuration files, and of course, can not properly apply any parameters to the phone. Our Developer who wrote the website code is reviewing it now. The strange thing is that the provisioning server works perfect with Grandstream phones, and Polycom phones...Yealink seems to dislike it however.
Why would your provisioning server be a webserver? Most of the time this is a TFTP server. I mean HTTP and HTTPS are supported, as well as FTP and TFTP, but TFTP is standard.
The Yealink admin guide shoes the examples in the appendix. Are you sure you put the URL correctly into the phone in the first place?
Since we have cloud VPS servers, I wanted a secure way to send provisioning information to the phones. We achieve this by using HTTPS. We tried to use the build in EndPoint manager for provisiining via HTTPS, but it was lacking some features that we wanted. Plus, with a centralized provisioning server, we have a central point for the files and if we ever choose to move VPS providers, making changes to all config files and pointing to a new server would be quick and almost transparent to the client.
Yes, the URL was correct. We direct every client to the central server, and then based on thier individual login, we direct them to their specific files. The code that does this operation on the web server does not play well with the Yealink phones for some reason. We cleaned it up and think we are almost out of the woods. Probably a good thing...eyes getting heavy.
You left out some serious information in your initial post then. Notably HTTPS != "web server" as well as you are authenticating to the webserver somehow?
That is all horribly complicating things and leads me to question the over all goal that led to this design. But you apparently have the developers working around the issues already.
In the original post, I was convinced it was the configuration files. It's only after I did some packet captures that I realized that the phone wasn't getting the configuration file completely.
This was the most secure way that we could think of to securely provision remote phones. (aside from VPN that is.) I'd be interested to hear how you or others securely provision remote extensions. Is there a better way?
-
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
Well, after hours of troubleshooting, pizza, and analyzing Wireshark packet captures, I've come to the conclusion that something with our local provisioning server is causing the Yealink phones not to get their entire configuration files, and of course, can not properly apply any parameters to the phone. Our Developer who wrote the website code is reviewing it now. The strange thing is that the provisioning server works perfect with Grandstream phones, and Polycom phones...Yealink seems to dislike it however.
Why would your provisioning server be a webserver? Most of the time this is a TFTP server. I mean HTTP and HTTPS are supported, as well as FTP and TFTP, but TFTP is standard.
The Yealink admin guide shoes the examples in the appendix. Are you sure you put the URL correctly into the phone in the first place?
Since we have cloud VPS servers, I wanted a secure way to send provisioning information to the phones. We achieve this by using HTTPS. We tried to use the build in EndPoint manager for provisiining via HTTPS, but it was lacking some features that we wanted. Plus, with a centralized provisioning server, we have a central point for the files and if we ever choose to move VPS providers, making changes to all config files and pointing to a new server would be quick and almost transparent to the client.
Yes, the URL was correct. We direct every client to the central server, and then based on thier individual login, we direct them to their specific files. The code that does this operation on the web server does not play well with the Yealink phones for some reason. We cleaned it up and think we are almost out of the woods. Probably a good thing...eyes getting heavy.
You left out some serious information in your initial post then. Notably HTTPS != "web server" as well as you are authenticating to the webserver somehow?
That is all horribly complicating things and leads me to question the over all goal that led to this design. But you apparently have the developers working around the issues already.
In the original post, I was convinced it was the configuration files. It's only after I did some packet captures that I realized that the phone wasn't getting the configuration file completely.
This was the most secure way that we could think of to securely provision remote phones. (aside from VPN that is.) I'd be interested to hear how you or others securely provision remote extensions. Is there a better way?
I'd be getting them on a VPN anyway. HTTPS is known to be broken at this point. Symantec just bought BlueCoat, if you're not sure why that's relevant, you should go read some tech news.
-
@travisdh1 said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
Well, after hours of troubleshooting, pizza, and analyzing Wireshark packet captures, I've come to the conclusion that something with our local provisioning server is causing the Yealink phones not to get their entire configuration files, and of course, can not properly apply any parameters to the phone. Our Developer who wrote the website code is reviewing it now. The strange thing is that the provisioning server works perfect with Grandstream phones, and Polycom phones...Yealink seems to dislike it however.
Why would your provisioning server be a webserver? Most of the time this is a TFTP server. I mean HTTP and HTTPS are supported, as well as FTP and TFTP, but TFTP is standard.
The Yealink admin guide shoes the examples in the appendix. Are you sure you put the URL correctly into the phone in the first place?
Since we have cloud VPS servers, I wanted a secure way to send provisioning information to the phones. We achieve this by using HTTPS. We tried to use the build in EndPoint manager for provisiining via HTTPS, but it was lacking some features that we wanted. Plus, with a centralized provisioning server, we have a central point for the files and if we ever choose to move VPS providers, making changes to all config files and pointing to a new server would be quick and almost transparent to the client.
Yes, the URL was correct. We direct every client to the central server, and then based on thier individual login, we direct them to their specific files. The code that does this operation on the web server does not play well with the Yealink phones for some reason. We cleaned it up and think we are almost out of the woods. Probably a good thing...eyes getting heavy.
You left out some serious information in your initial post then. Notably HTTPS != "web server" as well as you are authenticating to the webserver somehow?
That is all horribly complicating things and leads me to question the over all goal that led to this design. But you apparently have the developers working around the issues already.
In the original post, I was convinced it was the configuration files. It's only after I did some packet captures that I realized that the phone wasn't getting the configuration file completely.
This was the most secure way that we could think of to securely provision remote phones. (aside from VPN that is.) I'd be interested to hear how you or others securely provision remote extensions. Is there a better way?
I'd be getting them on a VPN anyway. HTTPS is known to be broken at this point. Symantec just bought BlueCoat, if you're not sure why that's relevant, you should go read some tech news.
HTTPS is not broken. Older ciphers used for HTTPS are broken. Setting your webserver to only accept modern ciphers is just as encrytped and unbroken as always.
-
@fuznutz04 said in Yealink W52P config files:
This was the most secure way that we could think of to securely provision remote phones. (aside from VPN that is.) I'd be interested to hear how you or others securely provision remote extensions. Is there a better way?
The answer there varies.
For most companies, I would used raw HTTP(S) with IP based whitelist as a first choice. Why? Because they have fixed IP blocks.
If you are dealing with roving users, then yeah, it is harder to decide what to do. -
@JaredBusch said in Yealink W52P config files:
@travisdh1 said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
Well, after hours of troubleshooting, pizza, and analyzing Wireshark packet captures, I've come to the conclusion that something with our local provisioning server is causing the Yealink phones not to get their entire configuration files, and of course, can not properly apply any parameters to the phone. Our Developer who wrote the website code is reviewing it now. The strange thing is that the provisioning server works perfect with Grandstream phones, and Polycom phones...Yealink seems to dislike it however.
Why would your provisioning server be a webserver? Most of the time this is a TFTP server. I mean HTTP and HTTPS are supported, as well as FTP and TFTP, but TFTP is standard.
The Yealink admin guide shoes the examples in the appendix. Are you sure you put the URL correctly into the phone in the first place?
Since we have cloud VPS servers, I wanted a secure way to send provisioning information to the phones. We achieve this by using HTTPS. We tried to use the build in EndPoint manager for provisiining via HTTPS, but it was lacking some features that we wanted. Plus, with a centralized provisioning server, we have a central point for the files and if we ever choose to move VPS providers, making changes to all config files and pointing to a new server would be quick and almost transparent to the client.
Yes, the URL was correct. We direct every client to the central server, and then based on thier individual login, we direct them to their specific files. The code that does this operation on the web server does not play well with the Yealink phones for some reason. We cleaned it up and think we are almost out of the woods. Probably a good thing...eyes getting heavy.
You left out some serious information in your initial post then. Notably HTTPS != "web server" as well as you are authenticating to the webserver somehow?
That is all horribly complicating things and leads me to question the over all goal that led to this design. But you apparently have the developers working around the issues already.
In the original post, I was convinced it was the configuration files. It's only after I did some packet captures that I realized that the phone wasn't getting the configuration file completely.
This was the most secure way that we could think of to securely provision remote phones. (aside from VPN that is.) I'd be interested to hear how you or others securely provision remote extensions. Is there a better way?
I'd be getting them on a VPN anyway. HTTPS is known to be broken at this point. Symantec just bought BlueCoat, if you're not sure why that's relevant, you should go read some tech news.
HTTPS is not broken. Older ciphers used for HTTPS are broken. Setting your webserver to only accept modern ciphers is just as encrytped and unbroken as always.
Ok, here goes. Symantec already owns VeriSign, and is buying BlueCoat. VeriSign was once the most prolific provider of SSL certificates. It turns out that BlueCoat already had an intermediate certificate from VeriSign. Which means that BlueCoat can produce totally valid certificates from VeriSign on the fly. Thus my assertion that HTTPS is known to be broken. Doesn't matter how good the ciphers are if someone is breaking the encryption mid-stream, which is what BlueCoat does.
-
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
This was the most secure way that we could think of to securely provision remote phones. (aside from VPN that is.) I'd be interested to hear how you or others securely provision remote extensions. Is there a better way?
The answer there varies.
For most companies, I would used raw HTTP(S) with IP based whitelist as a first choice. Why? Because they have fixed IP blocks.
If you are dealing with roving users, then yeah, it is harder to decide what to do.Yep, we use HTTPS with username/password, but not a whitelist currently. Once the phones are provisioned, the chances of them needing re-provisioned is fairly low, unless their is a configuration change that we want to push out. As of now, everyone would automatically get the new info. If I implement a whitelist, then it would become more difficult to push an update to roaming users, but certainly not a deal breaker, seeing as we could just update the whitelist as needed.
How often do you have your phones checking the provisioning server for changes?
-
@travisdh1 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@travisdh1 said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
Well, after hours of troubleshooting, pizza, and analyzing Wireshark packet captures, I've come to the conclusion that something with our local provisioning server is causing the Yealink phones not to get their entire configuration files, and of course, can not properly apply any parameters to the phone. Our Developer who wrote the website code is reviewing it now. The strange thing is that the provisioning server works perfect with Grandstream phones, and Polycom phones...Yealink seems to dislike it however.
Why would your provisioning server be a webserver? Most of the time this is a TFTP server. I mean HTTP and HTTPS are supported, as well as FTP and TFTP, but TFTP is standard.
The Yealink admin guide shoes the examples in the appendix. Are you sure you put the URL correctly into the phone in the first place?
Since we have cloud VPS servers, I wanted a secure way to send provisioning information to the phones. We achieve this by using HTTPS. We tried to use the build in EndPoint manager for provisiining via HTTPS, but it was lacking some features that we wanted. Plus, with a centralized provisioning server, we have a central point for the files and if we ever choose to move VPS providers, making changes to all config files and pointing to a new server would be quick and almost transparent to the client.
Yes, the URL was correct. We direct every client to the central server, and then based on thier individual login, we direct them to their specific files. The code that does this operation on the web server does not play well with the Yealink phones for some reason. We cleaned it up and think we are almost out of the woods. Probably a good thing...eyes getting heavy.
You left out some serious information in your initial post then. Notably HTTPS != "web server" as well as you are authenticating to the webserver somehow?
That is all horribly complicating things and leads me to question the over all goal that led to this design. But you apparently have the developers working around the issues already.
In the original post, I was convinced it was the configuration files. It's only after I did some packet captures that I realized that the phone wasn't getting the configuration file completely.
This was the most secure way that we could think of to securely provision remote phones. (aside from VPN that is.) I'd be interested to hear how you or others securely provision remote extensions. Is there a better way?
I'd be getting them on a VPN anyway. HTTPS is known to be broken at this point. Symantec just bought BlueCoat, if you're not sure why that's relevant, you should go read some tech news.
HTTPS is not broken. Older ciphers used for HTTPS are broken. Setting your webserver to only accept modern ciphers is just as encrytped and unbroken as always.
Ok, here goes. Symantec already owns VeriSign, and is buying BlueCoat. VeriSign was once the most prolific provider of SSL certificates. It turns out that BlueCoat already had an intermediate certificate from VeriSign. Which means that BlueCoat can produce totally valid certificates from VeriSign on the fly. Thus my assertion that HTTPS is known to be broken. Doesn't matter how good the ciphers are if someone is breaking the encryption mid-stream, which is what BlueCoat does.
VPN is of course an option, but haven't gone down that route yet, as I see HTTPS being the best middle of the road option, and an easy experience for the client. Just look at some of the big players in the VoIP world. They certainly do not require their customer base to setup a VPN to provision their phones. I've typically seen HTTP or less often, HTTPS provisioning with those guys.
-
Sometimes our watchguard firewall will block the ports on our voip phones when they download the config, thinking it is a port scan attack since all the phones go out at once. This generally only happens after isp/power outage. Our phones get the config from a 3rd party during dhcp. The config file is hosted on an apache2 webserver run by our phone provider(I'd have probably done it differently if i was here when they transitioned from the awesome Mitel pbx powerhouse to this voip solution.
We only have 1 of the phones youre talking about, for the receptionist. All the others are T42G phones. -
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
This was the most secure way that we could think of to securely provision remote phones. (aside from VPN that is.) I'd be interested to hear how you or others securely provision remote extensions. Is there a better way?
The answer there varies.
For most companies, I would used raw HTTP(S) with IP based whitelist as a first choice. Why? Because they have fixed IP blocks.
If you are dealing with roving users, then yeah, it is harder to decide what to do.Yep, we use HTTPS with username/password, but not a whitelist currently. Once the phones are provisioned, the chances of them needing re-provisioned is fairly low, unless their is a configuration change that we want to push out. As of now, everyone would automatically get the new info. If I implement a whitelist, then it would become more difficult to push an update to roaming users, but certainly not a deal breaker, seeing as we could just update the whitelist as needed.
How often do you have your phones checking the provisioning server for changes?
My phones check in on whatever default schedule they use. I think weekly.
How are you sending username and password? To my knowledge the phone has no way to set a username and password for that?
-
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
@JaredBusch said in Yealink W52P config files:
@fuznutz04 said in Yealink W52P config files:
This was the most secure way that we could think of to securely provision remote phones. (aside from VPN that is.) I'd be interested to hear how you or others securely provision remote extensions. Is there a better way?
The answer there varies.
For most companies, I would used raw HTTP(S) with IP based whitelist as a first choice. Why? Because they have fixed IP blocks.
If you are dealing with roving users, then yeah, it is harder to decide what to do.Yep, we use HTTPS with username/password, but not a whitelist currently. Once the phones are provisioned, the chances of them needing re-provisioned is fairly low, unless their is a configuration change that we want to push out. As of now, everyone would automatically get the new info. If I implement a whitelist, then it would become more difficult to push an update to roaming users, but certainly not a deal breaker, seeing as we could just update the whitelist as needed.
How often do you have your phones checking the provisioning server for changes?
My phones check in on whatever default schedule they use. I think weekly.
How are you sending username and password? To my knowledge the phone has no way to set a username and password for that?
On the Autoprovision page (on the W52P model), you set your provision server as well as a username and password.
-
In the config files, I set it here:
auto_provision.server.url =
auto_provision.server.username =
auto_provision.server.password = -
This post is deleted!
