Possibility of using our own RPS with T53 router phone

Status
Not open for further replies.

Rick-Arcus-IT

Platinum Partner
Advanced Certified
Joined
Jun 25, 2020
Messages
153
Reaction score
64
Hello,

We are using our own Yealink RPS environment to monitor and control our Yealink phones. I tried to install a T53 router phone, but that didn't work because the phone was added to our own RPS server. After deleting the phone in our RPS, I could create the routerphone. but it still didn't register. Our phones run the Dutch Lydis firmware (.188) to have the Dutch language on the phones. In the web interface, I could see the correct provisioning URL of our PBX, but the phone would not register. So after manually installing the 3CX firmware (https://www.3cx.com/docs/phone-firmwares/), the phone did register as a router phone.
But now our phone was stuck in somebody else's RPS, so we could not monitor the phone anymore and the amount of deployed phones in the RPS did not match up with what we have in the field.

So after removing the router phone from the 3CX RPS using the Yealink RPS removal tool, and adding it to our RPS, the remaining question was; what happens when the phone factory resets? After I factory reset the phone, it still registers as a router phone, and everything still works.

So now my main question is, why do we need to use the 3CX RPS? The provisioning URL for a router phone is not any different from the provisioning URL for a normal phone. There is no firmware pushed from the 3CX RPS. Is there a possibility of using our own RPS?
 
Last edited:
Hello,

3CX RPS provides unified registration/deregistration interface to the actual RPS servers of supported vendors which have some protocol difference handled under the hood. It also has UI needed to check the status and manually unregister the phones by 3CX staff.

After factory reset the phone will try to contact the RPS server of the vendor to get the provisioning link of the PBX.
If your own RPS server also acts as a proxy to Yealink, in theory it can "implement" the internal protocol between PBX and 3CX RPS, do its own thing and forward the requests to the Yealink RPS. To do so, your server will also have to implement a subset of RPS protocol.
 
Last edited:
Hello,

3CX RPS provides unified registration/deregistration interface to the actual RPS servers of supported vendors which have some protocol difference handled under the hood. It also has UI needed to check the status and manually unregister the phones by 3CX staff.

After factory reset the phone will try to contact the RPS server of the vendor to get the provisioning link of the PBX.
If your own RPS server also acts as a proxy to Yealink, in theory it can "implement" the internal protocol between PBX and 3CX RPS, do its own thing and forward the requests to the Yealink RPS.
Hi Ivank,

Thanks for your reply. We don't have an RPS proxy server, but we have our own Yealink YDMS+RPS server hosted at Yealink. How would I set the 3CX to use our RPS environment (we only have Yealinks), and not use the RPS servers from 3CX? This way we don't need to remove the phone from the 3CX RPS after setting up the router phone.

Kind regards,

Rick
 
If you disable 3CX RPS, how will the device know its provisioning URL? OK, suppose you are able and wish to assign it manually via YMCS.

In this case you might try disabling RPS support in the 3CX phone template for your model.
The relevant parameter is located under root <header> element and called "rps", you just need to create a custom template and set it to 0 to switch off RPS support: <rps>0</rps>
Now when adding such phone, the PBX will not try reaching 3CX RPS at all.
Most likely your system will become unsupported though.

Hope it helps.
 
  • Like
Reactions: Rick-Arcus-IT
Before any 3CX project, we add all the phones to the YMCS, so they already have the provisioning URL we take from the 3CX pbx.

When disabling the RPS in the template, does it still work to create router phones?
 
It has never been tested like this nor officially supported. I'm afraid you'll have to try it yourself.
 
Alright. Then we will just remove the phone from the 3CX after provisioning and add it to our own RPS. This way we stay supported by 3CX and can monitor our own phones.

Thanks for your replies!

Rick
 
  • Like
Reactions: ivank
Also note that V20 has the option to switch off 3CX RPS usage completely:
 

Attachments

  • RPS.PNG
    RPS.PNG
    26.7 KB · Views: 27
Also note that V20 has the option to switch off 3CX RPS usage completely:
Alright, that might be what I'm looking for! I'll look into this.
 
With V20 it's possible to use your own RPS to provision a router phone :cool:
 
  • Love
Reactions: ivank
Yes, I have just learned all about this the hard away as well. I use only Yealink Telephones so that is what I'm going to be talk about here with my testing from outside looking in. I have no internal knowledge of exactly how this is implemented in 3CX.

This ONLY a key issue when using Router Phones with RPS as 3CX effectively requires us to use 3CX's Yealink RPS Account that is baked into their software behind the scenes. Also, a little birdie told me that 3CX RPS entries might expire registrations after some time but that is not confirmed. Of DCHP Option 66 and manual one time setting of the provision URL works just fine regardless. It presently appears to me, based upon my limited testing, once the provision URL is set the RPS process may not be invoked.

Yealink needs to fully document their RPS workflow for Partners so we can fully understand the management edge cases.

This is going to be a bigger issue for Yealink and 3CX as Telephone handsets get moved around from 3CX system to 3CX system over time. I don't know if Yealink RPS has some kind of keep alive, heartbeat or notification that informs the RPS the phone is still connected to the same 3CX System over time. This could be another idea that if a phone does not keep alive after 30 days, then the registration is removed from the RPS. Of course, we know that phones can be programmed to be automatically rebooted in the middle of the night which could accomplish what we need.

Further, some Distributors like ABP, have their own public Interface to Yealink's RPS but ABP uses their Yealink assigned RPS Account by default. This of course means that ABP has to help me manage, but again this is a conflict with the 3CX RPS requirements for Router Phones as well.

HOWEVER, ABP has a brilliant feature to allow the partner to add my Yealink RPS Credentials to my Partner Account with ABP then their ZTP Service (Zero Touch Provision Service) used by creds and we are good to go with their ZTP! Brilliant!

What we need is to have 3CX, do the same, allow us to config the Creds of my Yealink RPS into each 3CX Phone System that I deploy as a partner. Of course, this begs the question on how to revoke these Creds later if the relationship with the customer ends or the phone moves on to someone else to another 3CX install.

We need a more fulsome RPS Management Interface.

A better option would be to manage the RPS Creds from 3CX System Admin for the License. Of course, you would need multiple entries for creds for each telephone vendor. These details would not be stored in the 3CX Admin Control Panel but pushed down the Licensed 3CX Instance itself along with options to revoke the creds.

If the relationship with the Partner and License ends the License is moved to the next Partner's account. I would bet this happens all the time. This also has another benefit that nobody at the 3CX instance can see the Yealink RPS Creds including the next 3CX Partner.

If we implemented most of this idea, then ultimately, in your Yealink RPS Account I can easily delete MACs and we are good to GO! In this way it reduces the support overhead for 3CX and Yealink. What do folks think?

PS: As of today (this posting), 3CX Hosted does not allow modification of Templates to make changes mentioned herein. This should be allowed by Partners somehow BTW.
 
Last edited:
Also, a little birdie told me that 3CX RPS entries might expire registrations after some time but that is not confirmed.
2 weeks. No birdie needed here. They expire and are removed from RPS (not 3CX software) after 2 weeks.

It presently appears to me, based upon my limited testing, once the provision URL is set the RPS process may not be invoked.
It still gets checked every book, but it isn't needed as long as you don't factory reset the phone and remove the already saved provisioning URL..

This is going to be a bigger issue for Yealink and 3CX as Telephone handsets get moved around from 3CX system to 3CX system over time. I don't know if Yealink RPS has some kind of keep alive, heartbeat or notification that informs the RPS the phone is still connected to the same 3CX System over time. This could be another idea that if a phone does not keep alive after 30 days, then the registration is removed from the RPS. Of course, we know that phones can be programmed to be automatically rebooted in the middle of the night which could accomplish what we need.

Further, some Distributors like ABP, have their own public Interface to Yealink's RPS but ABP uses their Yealink assigned RPS Account by default. This of course means that ABP has to help me manage, but again this is a conflict with the 3CX RPS requirements for Router Phones as well.

HOWEVER, ABP has a brilliant feature to allow the partner to add my Yealink RPS Credentials to my Partner Account with ABP then their ZTP Service (Zero Touch Provision Service) used by creds and we are good to go with their ZTP! Brilliant!

What we need is to have 3CX, do the same, allow us to config the Creds of my Yealink RPS into each 3CX Phone System that I deploy as a partner. Of course, this begs the question on how to revoke these Creds later if the relationship with the customer ends or the phone moves on to someone else to another 3CX install.

We need a more fulsome RPS Management Interface.

A better option would be to manage the RPS Creds from 3CX System Admin for the License. Of course, you would need multiple entries for creds for each telephone vendor. These details would not be stored in the 3CX Admin Control Panel but pushed down the Licensed 3CX Instance itself along with options to revoke the creds.

If the relationship with the Partner and License ends the License is moved to the next Partner's account. I would bet this happens all the time. This also has another benefit that nobody at the 3CX instance can see the Yealink RPS Creds including the next 3CX Partner.

If we implemented most of this idea, then ultimately, in your Yealink RPS Account I can easily delete MACs and we are good to GO! In this way it reduces the support overhead for 3CX and Yealink. What do folks think?
This is exactly why 3CX uses their own and expires after 2 weeks. The chance of a telephone moving around in the 2 weeks after you add it are slim to none. Also 3CX can save dev time trying to build a RPS management interface for partners by just using theirs. Lastly, not everyone has access to RPS for all the vendors (even Yealink doesn't give it all away to everyone who asks).
 
  • Like
Reactions: Evolute IT
OKAY. I got my Yealink RPS from my distributor who can create sub accounts. I highly recommend ABP.

Good to get confirm on 2 Week release. RPS is still important because customer think they know better and try making changes to phone and then get stuck. The only to fix this is factory reset then RPS is important assuming you are not doing DHCP Option 66.
 
It still gets checked every book, but it isn't needed as long as you don't factory reset the phone and remove the already saved provisioning URL..

What do you mean by "checked every book"?
 
What do you mean by "checked every book"?
Every BOOT, typo.

When the phone boots up, it checks RPS every single time it boots up.

OKAY. I got my Yealink RPS from my distributor who can create sub accounts. I highly recommend ABP.
I used ABP back in 2016 or so. For many reasons I stopped using them. But I'm happy to hear they are working well for you.
 
  • Like
Reactions: Evolute IT
That is what I had assumed but was not sure... Unless, automatic reboot is ON then the update won't happen that often. I will have to check the default settings for latest v18.
 
Status
Not open for further replies.

Members Online Now

Forum statistics

Threads
111,832
Messages
589,283
Members
164,662
Latest member
DejanMDS