What do you use to access phone GUI behind SBC ?

[AWS2P]

Hello,
I'd like to know what is the best way to follow to be able to access phone GUI for firmware update for example when phones are behind debian SBC ?

Of course i'd like something else than asking hand and disturbing customer with a windows teamviewer session on computer from their LAN. Also sometimes SBCs are behind permanent 4G routers without static public IP (so,one problem more).

As on SBC there is nothing graphical with easy and quick access , so what is the 3CX way to manage phones in that kind of use?

Is there some improvments coming in V18 or for future release on that area ?

Thanks for your lights.

 

[SteveITS]

Do you have access to their router to make a NAT port forward from your IP to the phone IP?

 

[Evolute IT]

Normally, you won't have to go on a phone for a firmware update. The SBC and 3CX should take care of sending it to the phone.

However, when needed, we install the SBC on a Windows machine so that we can remote in easily using ConnectWise Control.

Also, some people install a GUI on the Raspberry Pi so that they can use TeamViewer the same way.

 

[Alphabetic]

On site servers with RMM tool

VPN

You could stick another Pi onsite and install the desktop GUI and stick some remote software on there.

A dedicated PC with some DDNS software on

What about a Raspberry Pi Zero W? They're cheap AF. I've always wanted to get one to test. Stick the GUI on that and set up some remote tool on there.

 

[AWS2P]

Normally, you won't have to go on a phone for a firmware update. The SBC and 3CX should take care of sending it to the phone.

However, when needed, we install the SBC on a Windows machine so that we can remote in easily using ConnectWise Control.

Also, some people install a GUI on the Raspberry Pi so that they can use TeamViewer the same way.

Salut Fred,
In fact this is for DECT base firmware update , these one are not pushed by 3CX.
Some of my SBCs are windows 10 , so no problem with teamviewer, but for all under debian ????

I thought using something else than 3CX ISO wasn't supported so where GUI come from on PI, is this a full raspbian distrib installed instead of 3CX ISO, my linux is poor sorry.

 

[AWS2P]

You could stick another Pi onsite and install the desktop GUI and stick some remote software on there.

A dedicated PC with some DDNS software on

What about a Raspberry Pi Zero W? They're cheap AF. I've always wanted to get one to test. Stick the GUI on that and set up some remote tool on there

Yes, could be a way but the need of a second computer even very small, just to push firmware but for sure that way is 3CX supported.

 

[AWS2P]

Do you have access to their router to make a NAT port forward from your IP to the phone IP?

Probably on small install this could be a workaround, but for extended this is clearly not

 

[Clément Rousseau]

Hi!
I dont have another solution but here is what we do :
- if its only for few DECT base stations, we set up them with static local ip and use NAT forwarding.
- for bigger installs with lot of DECT bases, client always has a firewall then we ask a vpn access to phone lan. We always set up different vlan for voip, and vpn its almost a mandatory prerequisite for this size of customer (restricted in terms of ip and rights ofc, usually not a problem for companies of this size).

 

[bob333]

Here is what Ido: I connect to the remote SBC via SSH, and use SSH port forwarding (SSH tunnel) to access the phone GUI using the browser on my computer. I use Putty on Windows. For each phone, I have set up in Putty forwarding on a different port. Connecting to localhost:[port no.] in my browser brings up the GUI for the phone assigned to that port. Easy, no extra hardware needed, works great.

 

[ChrisKoll]

We use Teamviewer on each PI, remote connect to the PI, off you go

 

[dkdocks]

@OP if your firewall supports it, do OpenVPN or Wireguard on the SBC box or on Edge firewall - it will get you on a segment where from local route you can hit the lan segment the phones are on directly from a remote computer. Setup dyndns our AWS api token route 53 updates to always keep the dns of the moving dynamic external ip refreshed.

 

[JohnS_3CX]

Please avoid using any VPN software on the SBC machine itself, you could end up in a situation where you lose all the phones.

Couple of suggestions:

If the budget allows it, a windows SBC with remote desktop software should generally be OK. You also have the option of running the SBC inside a Debian VM on this pc, hence keeping your SBC supported status, and also having the ability to do remote desktop on that PC to manage both the local phones and the SBC VM if you need to, giving you more flexibility in case you need it.

For low cost tier installations, leave the Pi SBC as is, and remote into a local PC to do what you need (assuming the customer is ok with this interruption). Alternatively a light linux desktop VM running in the background of a user's PC should also allow you to do what you need without intruding into the user's Windows session.

 

[AWS2P]

Here is what Ido: I connect to the remote SBC via SSH, and use SSH port forwarding (SSH tunnel) to access the phone GUI using the browser on my computer. I use Putty on Windows. For each phone, I have set up in Putty forwarding on a different port. Connecting to localhost:[port no.] in my browser brings up the GUI for the phone assigned to that port. Easy, no extra hardware needed, works great.

Hi Bob,
interresting, but can you give me some more details as it's not clear crystal for me what settings i need to do same as you.
Could it be possible to share a detailled example?
Thanks
Christian

 

[Alphabetic]

Hi Bob,
interresting, but can you give me some more details as it's not clear crystal for me what settings i need to do same as you.
Could it be possible to share a detailled example?
Thanks
Christian

The basic to this is probably port porwarding SSH port 22 to the Pi and restricting access to your WAN IP.

 

[AWS2P]

We use Teamviewer on each PI, remote connect to the PI, off you go

Can you share more details on :

1. how do you install TV on pi? From CLI?
2. Do you have link or details on that ?
3. Is it on 3CX SBC iso base or from a complete raspbian distribution including GUI ?

 

[AWS2P]

The basic to this is probably port porwarding SSH port 22 to the Pi and restricting access to your WAN IP.

Yes ,this was clear enough, but what's next step to reach phone GUI ?

 

[ChrisKoll]

I install TV using the GUI on first install, at that point it is shipped out to the client, once in place I setup 3CX SBE and set a statin IP. from this point we can connect anytime needed for the phones or whatever.

 

[AWS2P]

I install TV using the GUI on first install, at that point it is shipped out to the client, once in place I setup 3CX SBE and set a statin IP. from this point we can connect anytime needed for the phones or whatever.

So your SBC is not installed with 3CX ISO but full debian to have gui ? Do you use on PI ?

 

[ChrisKoll]

I install just the PI os, then I install 3cx after using

wget http://downloads.3cx.com/downloads/sbc/3cxsbc.zip

sudo bash 3cxsbc.zip

 

[JohnS_3CX]

Hi guys, just to chime in on what my colleague said above:

We do not recommend or support using the SBC machine in such a way - if you face any issues with it then your first step should be to reinstall the OS+SBC using the supported method and see if the issues are resolved before contacting support.

- The best way to approach it is to remote into the network via a 3rd method, and carry out any tasks without involving the SBC machine.

- For PC based SBC, you can alternatively consider putting the SBC inside of a VM on to keep it isolated and supported, and use the host OS to setup remote access to the customer's network. Just factor in the additional resources on top of the SBC requirements

- For Raspberry based SBC, best to leave it as is because the Pi will have limited valuable resources that would want to keep from being consumed by a heavy desktop OS or 3rd party software - both of which could end up causing more harm vs the convenience they might provide

At the end of the day everyone can use their own solutions, but out primary focus is for your SBC to remain supported, stable, predictable and performant to keep both you and your customers happy. Hope this helps!