Q: Physical Phone Handset for "Home Office" - best practice / good candidate?

[fortech]

Hi, I have a 'fun' question. Trying to get a handle on this. I just chatted with a client I would like to setup on a 3cx PBX. Basic model will be,

- 3cx cloud-hosted on a VM running in data centre in Montreal, on a dedicated VM. Based on the PBX express deployment which is good/robust/works nicely. Which I have used for various ohter 3cx deployments and it is a 'good easy' solution.
- client has one main physical office, which needs 3 physical handsets for 'heavy users' who require 'classic physical handset phone device'. Clearly I would just deploy a small SBC gateway at this office, to facilitate nice tunnel of voip traffic from these handsets up to the cloud 3cx PBX server.
- then we have 4 x home offices. Each is wanting a physical handset. Only one handset per office. With an assortment of consumer and otherwise poorly or uncharacterized firewall / ISP platform. Generally normal 'good' high speed internet (ie, 100meg down and 10meg up Cable modem, or better). So plenty of bandwidth for Voip. But the concern, is how to make a physical handset work nicely in these 'hostile environments' where I have no control on the firewall, and need the handset to be a 'painless to deploy' and 'smooth operation' solution?

Is there any recommended physical phone handset which gives a seamless experience in this kind of deployment?

Reading at the docs here, for example, https://www.3cx.com/docs/manual/configuring-ip-phones/#h.ul2fzupi6t22/
it seems to be implied that if you are not using an SBC host, then you must do non-trivial amount of firewall config work for port forwarding/config. period. This is definitely pretty disgusting to try to contemplate for this kind of deployment.

Clearly if the client was happy just to use softphone app on smartphone - then all their voip traffic tunnels nealty and there is zero config.

I guess using WebApp on their laptop at home office would also give same 'simple experience'. But is not what they want - if they want a 'home office work phone physical handset'.

I guess I'm wondering if for example - there is a specific device (phone physical handset) which is very well characterized, and runs a particular 3cx firmware that does the tunneling internally on the phone device itself, as cleanly as if it were the softphone app, kind of more or less.

In this 'new era' of work-from-home for so many offices I am kind of wondering if this is a common problem/questoin. Or if simply the answer is, "use the softphone, move on, learn to use it and abandon your obsolete physical handsets, break free from your chains (etc etc)."

Client wants 'full feature' handsets of course - BLF - call availability / easy transfer to other people via BLF buttons. Ideally able to transfer out to self (ie, send call from voip phone to cell phone so you can 'leave the office, leave the internet' and carry on the call by kicking it over to your external cellphone#. etc etc.

So. Curious if anyone has any thoughts/suggestions. (ie, "3cx now partner with grandstream and provide the "Grandstream-3cx phone" which is a grandstream hard-handset-phone that runs special 3cx firmware and does the tunneling all nicely on its own without an SBC server but works just as nicely" ha ha for example). (aka wishful thinking).

Many thanks,

Tim

 

[leejor]

I guess I'm wondering if for example - there is a specific device (phone physical handset) which is very well characterized, and runs a particular 3cx firmware that does the tunnelling internally on the phone device itself, as cleanly as if it were the softphone app, kind of more or less.

I'm not aware of any devices, that are able to use the 3CX tunnel, other than the SBC or a 3CX App, as it is proprietary.. Many small sites are able to make use of STUN if there are not many sets involved
https://www.3cx.com/docs/manual/configuring-ip-phones/#h.ul2fzupi6t22/

 

[magicpbx]

We've had good luck with Yealink Handsets deploying remotely, even on DSL connections running at 12Mbps. There are others we've tried, but Yealinks have always been easy and "it just works" in our experience. Never had to worry about tunneling. You can even purchase models with WiFi built in so all the user has to do is plug it in using power adapter and enter their wifi credentials (we've sometimes sent a dedicated wifi access point with the phone so the user could just plug and play) - or you can get a poe ethernet injector too.

 

[AWS2P]

Clearly if the client was happy just to use softphone app on smartphone - then all their voip traffic tunnels nealty and there is zero config.

Yes this is a way, webclient too. Now if you are sure to have only one phone on each home site then STUN mode should be OK .
In worst case you can always use a PI as SBC and forgot your firewall question.

 

[fortech]

Many thanks for the replies! Greatly appreciated. It sounds like..
-- web client and softphone are safest bet.
-- no custom firmware phone handset device exists which can talk via 3cx tunnel protocol.
-- if I am confident I have just one handset hardphone per home office, then I can deploy handsets in STUN mode config and this will probably work without any firewall config drama being needed
-- or deploying a small SBC unit in parallel with home-office units is also a workaround (ie, using low-cost linux Pi-box or similar).

I think based on the project understanding I've got I will try to push it forward with stun-mode / single handset per home office - as the plan - and we'll see how it goes. I can summarize back to this thread in a few weeks once I have some results to report.

Thanks!

Tim

 

[AWS2P]

I forgot other solution, windows client with headphone or BT .

STUN should be ok if there's no SIP ALG on home router side otherwise you'll need to put your hands inside their home router / box modem settings

 

[fortech]

Little followup to this thread. Just doing some testing today, and so far it is frustrating. I can do a 3cx web-based proper STUN_REMOTE provision of the phone, get the handset to pick up settings assigned from 3CX Cloud PBX and if I adjust SIP and RTP ports, save and 'reprovision' phone; then reboot phone - it picks up new settings after reboot. The phone successfully pulled latest supported 3cx-provided-phone-firmware / has 3cx branding on the LCD etc. This is a grandstream GXP-2135. And. It shows up / registers cleanly in system. But when I make calls, there is no audio delivery - no rings, nothing heard / sent or recieved from the phone it seems. I've made sure I have no other SIP devices alive on my lan. Did not help. Double-checked template/settings for phone - seem good - ie "Deliver Audio" was ticked by default for example from the 3cx template for this phone type. etc.

kind of frustrating. Not sure if anyone has other suggestions I can try to poke on this other than "Deploy with a Pi as a SBC side-by-side the phone for each home office site (sigh).

as a counter point. I have 2 other sip devices in my LAN (both turned off right now). One for home office, registers direct to VoipMS for non-3cx voip phone. Other on different SIP port is 'home phone' also registes to VoipMS / not 3cx. And these both just work 'dandy'. It is ~rather frustrating how easy this is to do for generic phone / generic carrier setup; but with 3cx it is just so fiddley. (ie, really! wants to be deployed with an SBC basically, I guess?!)

anyhow. In case anyone has any hints - they are very much welcome.
Thanks,

Tim

 

[leejor]

My guess, is that your router, assumes that the audio ports, that the 3CX extension is supposed to use, are to be used by one of the other SIP devices. Have you done any port forwarding on your router? Some routers are better than others at "sorting" out SIP ports, some need to be told exactly what to do. You are using 3 SIP devices behind one router. You don't have much control over two of them.

 

[fortech]

Hi, for clarity. I do have a great deal of control over the devices, in the sense that I have powered them off to remove them from the picture.

ie,

I first turned off my 2 'normal' home-office and home phone devices. Then rebooted the firewall. (ie, remove traces of old SIP devices from there). Now I have zero active SIP devices in my home / home office. Then I power on the grandstream unit. It is now the only active, registered and visible SIP device in 3cx "Web Cloud" PBX (and my other devices are offline/cold and powered off). I can change settings here and get them to push / reprovision to the grandstream handset phone (ie, new custom SIP or RTP port setting). The grandstream is only active phone and appears to be registered/active/fully functional. Except that it has no audio (either send or recieve). I can call my cell phone and it rings, and I see the caller ID expected from the 3cx system. Or I can phone from my cell phone to that phone# and the 3cx / grandstream handset rings, I can answer. But. No audio.

Router here is an edgerouter,(ERLite) and I have made sure I have the ALG SIP helper feature turned off. There is no other port forwarding config that should be involved/interfering with the SIP/Phone.

I mentioned the other 2 sip devices just to indicate I have a 'positive control' of "SIP services work fine here' for a non-3cx config, If I have them turned on and working (which I don't right now when testing the Grandstream-3cx config attempt).

I realize the next step I can try is to manually config the inbound port forwarding on my firewall, and I expect that would work. I have done that before at other sites with success. The reason I don't want to do that. Is that I need to setup ~6 handsets, each will be deployed to a different home-office site; each with a different/hostile firewall config; and my hope was to get a handset that could "just light up and work" with DHCP LAN <> Internet access with it being the only SIP device inside each LAN. Plan B is that I just have to prep a bunch of small SBC Boxes, and deploy one of them at each home office site. But that kind of sucks having to deploy all that extra hardware just to light up the phones, ie, one SBC per phone basically.

It almost makes me want to investigate how to configure openVPN on the grandstream, but I am pretty sure that is going to be another rat nest of joy that I probably will be happier to avoid.

Hope this is a bit less unclear.

Thanks for the feedback.

Tim

 

[leejor]

I rarely (can't remember the last one), have any audio issues when I use an ATA, that I frequently travel with. I don't specify which ports to use, I just plug it in, and hope for the best, which is usually the case at hotels, and friends that I have stayed with. So, with out nay other SIP devices on your network, and the router re-booted to clear everything, it should work, with the single 3CX extension. if you have specified which audio ports are being used to the phone, you may very well have to forward those in the router. they are obviously not getting through. So, are they blocked, or trying to route elsewhere? Make sure that the Activity Log "looks" OK (IP and port) for a call attempt.

I'm assuming you read the Notes, at the bottom of this...
https://www.3cx.com/docs/manual/configuring-ip-phones/#h.ul2fzupi6t22/


https://www.3cx.com/community/threads/3cx-remote-stun-ip-phone-all-config.65632/

 

[cobaltit]

And these both just work 'dandy'. It is ~rather frustrating how easy this is to do for generic phone / generic carrier setup; but with 3cx it is just so fiddley. (ie, really! wants to be deployed with an SBC basically, I guess?!)

And do you know what they have on the other end? They have a SBC. SIP is SIP is SIP. All providers have to deal with NAT traversal in some form or fashion. All of the providers of hosted VoIP have SBCs on the far end. 3CX being a PBX that you are 'self-hosting' means you are responsible for dealing with this headache. So whether that's avoiding the problem all together by doing something not SIP based (Webclient using WebRTC), something that uses the 3CX tunnel (softphone apps or desk phone via SBC), or installing your own real SBC on either end of the call (3CX or traditional)

 

[fortech]

Hi, small update on this thread. FIgured I should post update even though it is a face-palm level of solution. At least it is good news

It turns out I setup the grandstream handset (physically) late in the day, rushing and a bit tired. With lights in room not so great. and it turns out under this circumstance, the word 'handset' and 'headset' written in black embossed plastic, black on black, on underside of phone, means that you have to really pay attention and plug in the 'handset' phone cable to the proper socket. And if you get it wrong, then you will experience an absence of (Dialtone, or any audio) on the handset.

So once I noted that detail this morning. I was doing series of other tests.

Fixed the plug to be correct on phone. (FacePalm) So that handset is plugged to handset plug, not headset plug.

Then with ERX Firewall at home office doing SIP and RTP Port Forwarding and custom config on the phone (manual provision) and it worked great. Then flipped phone back to stock 3cx pushed provision config, and it worked great. Then deleted firewall SIP and RTP rules, and it worked.

So my current endgame is that
- using a custom SIP port for this handset
- no custom firewall rules at home office
- phone is deployed properly in 3cx, no drama, works great, inbound and outbound calls are fine
- there is no negatave interaction apparently with my other 2 x SIP phones in the home / home office. All 3 phones currently active have different SIP ports, but no other custom config to try to force them to play nice. Note 2 of the 3 phones are talking directly to non-3cx VOIP (VoipMS, who use an asterisk style voip-in-cloud PBX endpoint of some kind; I am not precisely sure what their back end is but I am sure it is linux boxes running an open-source PBX of some kind). And my 3cx phone is dandy.
- I also tested with softphone latest app on my win10 laptop, it works nicely. And also the chrome browser softphone.

So.

Happy days.

I guess the lesson learned, is that it is good to review a variety of important config details, including mundane ones like "is it plugged in" and "are you sure you plugged it into the correct socket" and stuff like that.

After everyone finishes laughing at me for this I am hopeful that maybe this thread could be useful to others who end up in the same boat. Maybe?


Tim

 

[Alphabetic]

means that you have to really pay attention and plug in the 'handset' phone cable to the proper socket.

٩(͡๏̯͡๏)۶ (╯°□°）╯︵ ┻━┻