Hi!
Is there a router with DECT (such as TP-Link VR2600v) and easy LEDE Support without soldering or TFTP?
Thanks!
Dave
a) I am not sure there is a DECT -> VoIP "bridge" available. I searched for that previously but could not find.
b) I just flashed a TP-Link 8970B by taping three wires on the reverse side of the board.
No soldering needed, worked like a charm. The pins on that board look very similar to the VR2600v, so maybe that works for you as well ?
See here:
https://forum.openwrt.org/uploads/default/original/2X/c/c4663cf41d2ec9266ad840150a6679f9952e7511.jpg
Why not use Voip on your mobiles instead of DECT ?
In my experience DECT is much more robust to interference and things than wifi, also android wifi is pretty flaky. That being said, I do use Bria on Android and often do get acceptable calls. But if I'm making an important call I usually prefer the DECT.
BTW after my Cisco SPA 112 died a few days ago I just installed a Grandstream HT802 and it seems pretty good. For one thing it fully supports ipv6 which is great for me, and for another it supports opus codec which is also very good for me.
It might be better to simply stick with a well supported router and an HT802 rather than try to use an all-in-one device, as the lack of options will probably result in many compromises in support.
Difficult to say what works best indeed. A bit of trial and error.
If it may help:
I am running SQM / Layer of Cake on my router and use VoIP (SIP server is from my ISP) through Wifi without any problem. It has the added advantage of being able to "roam" by home calls wherever there is Wifi coverage by my ISP. I also paid attention to use a WiFi channel which is unused by others in my area. Without SQM I may have had issues on the phone calls (difficult to prove that it was the only cause, as several other factors changed at the same time).
QoS of some sort, such as SQM is absolutely essential to VOIP performance. So that's definitely a consideration as well when looking for a router that supports VOIP. If your bandwidth is large, CPU becomes an issue for doing proper QoS and that's further reason to custom choose your router separately from your VOIP adapter.
Yes, WiFi using a mobile app is a good thing to have available. If you've got enough stuff set up (Asterisk or FreeSwitch or the like or a sip proxy or some combination of both) you can have both at once like I do, but you may spend a lot of time getting it working 
1 Like
You can get the analogue FXS (phone) ports of most lantiq routers to work with asterisk and chan_lantiq, I don't know of any support for DECT (neither chipset, nor protocol at all) in (mainline'ish) linux.
The only free DECT implementation I know of is OsmocomDECT, which is pretty old (Linux 3.8) and seems to be dead.
As DECT is not available on LEDE: are there any recommended practices for VoiP over WiFi, other than using an unencumbered channel?
For VOIP over wifi there are several things I'd recommend:
- in your router re-write the DSCP for the RTP packets to 48, this will engage the VO queue in WMM and get your audio highest priority.
- make sure you have some kind of QoS set up in your router. SQM with layer_cake is probably your best bet, I use a custom QoS setup using HFSC and it works very well.
- Use a client that gives you control over DSCP in your handset. I use Bria and I can set DSCP=48 on the outgoing RTP packets (the typical standard is 46 = EF but this doesn't engage VO WMM queue on many drivers). I've done a packet sniff and this doesn't result in my Android phone using VO queue, but I suspect that's a problem with my phone. Normally DSCP=48 causes VO queue usage, and yes indeed my wifi access point sending to the handset DOES use VO, so at least I get WMM advantages one way. Unsurprisingly this results in most of the bad audio complaints coming from people on the other end of the line, I hear my callers usually very well.
- In your router rewrite DSCP on other packets so they get appropriate priority. Some gamers might want 48 on their game packets etc, but in general you shouldn't have anything but voice in the VO queue, have your router enforce that.
- Don't try to roam between APs unless you're OK with 2 second drop-outs in your conversation. You can try configuring 802.11r but relatively few devices support it. If you use an iPhone they do support it, so it might be a good idea, some recent Android phones also support it.
- Consider the use of TLS and SRTP on your connection if you have control over that.
- VOIP works a lot better over ipv6 since there's no NAT. If you can set that up, consider it. I found it nontrivial, but once I did set it up I got fewer dropouts.
- If you have switches between your router and your WiFi AP consider installing smart switches and configuring QoS in the switches, otherwise local LAN traffic like file-sharing can swamp your VOIP packets
- Don't expect things to work nearly as well on public WiFi as it does on your tuned home setup.
- VOIP over GSM LTE data connections is usually pretty good. If you want to take calls remotely perhaps consider turning off wifi during the call rather than trying to take a call over an un-managed public WiFi setup like a cafe or etc.
- Don't expect VOIP to work well with less than 3000 kbps both directions on WAN, even though it only takes about 100kbps per stream. This is because at 3000 kbps a 1500 byte MTU packet coming from your web browser etc takes 4ms to send down the wire and so even if a queue management system has to wait for a few of those packets before it can send your voice packet, it will not delay your voice packet more than 8 or 12 ms. A VOIP packet needs to be sent every 20ms. If you have substantially less bandwidth than 3000kbps you can get unmanageable bufferbloat even with many good QoS systems.
Does that mean we can set all devices listed in https://openwrt.org/toh/views/toh_phone_ports?dataflt[Phone+ports_*~]=dect to DECT unsupported?
1 Like
I'd say so, yes.
While I had forgotten about Osmocom (thanks sebastian_de for mentioning it), that project definately isn't active or in a usuable state (although it would cover the same basic chipsets that are sometimes used in common DECT equipped lantiq routers), even before considering it as being supported/ supportable in LEDE.
lantiq analogue FXS ports: supported via chan_lantiq and asterisk (but configuring and maintaining asterisk is not for the faint of heart)
DECT: regardless of the vendor, sadly no (semi-current) drivers, no support at all.
EDIT: this thread might summarize the situation quite well, at least the underlying technical aspects.
Dataentries updated to DECT unsupported.
It is difficult to assess, but I would suppose that most people in my area use DECT.
Which means that in order to use LEDE, they need to keep their "Standard" modem/router, and set up a second router behind.
Which means... that it is creating a difficult situation on several fronts: more complex than needed setup, can I trust the provider firmware/hardware, NATs etc. etc.
If DECT cannot be supported, at least there need to be a very clear "HOWTO" with recommendations for VoIP over WiFi (see above for a start).
I think this is a touchy area which prevents people from using LEDE.
If the "standard" router is the one provided by your ISP then what you're talking about should be standard practice anyway. The ISP completely controls the device they supply, and hence you have no security on your network if you use their device as your firewall. A malicious person at your ISP, or someone with the ability to compromise the firmware of your ISP's device can access anything inside your network unless you have a router you control between your network and the ISP provided device.
Not just wifi but in general I think recommendations about VOIP either wired or wifi are really a good idea.
As long as your ISP provides you with all access credentials (xDSL and VoIP), there is no need to use an ISP branded router at all, but the setup does get a bit more complex and you have to spread functionality over multiple devices.
- a modem (xDSL, cable, for ftth a media converter and a SFP+ port might be sufficient). The lantiq VXR268/ VRX288 chipsets are well supported by LEDE (including VDSL modem support), for mere ADSL the danube generation might be sufficient.
- a router, plenty of options with LEDE (and depending on your needs, lantiq VRX268/ VRX288 might cover both roles, modem and router).
- a pbx, this might be LEDE and asterisk.
- an SIP ATA, with or without DECT features. If all you need is wired analogue FXS ports, lantiq can again fill that role via asterisk and chan_lantiq - but it can't do DECT by itself (many DECT phones however still have their own analogue base station).
A valid, full featured setup could very well be (for VDSL2, including vectoring) - keep in mind, these are just examples, there are more options:
- BT Home Hub 5 type A, running LEDE as VDSL2 modem and router
- some commercial pbx/ SIP ATA/ DECT base station, jailed into its own subnet (think, e.g., port 4 of your router) with no access your LAN; options include some of the afforementioned DECT capable devices running the OEM firmware - or perhaps even your ISP-router (if it can be coaxed into IPoE operations, which is often the case).
or
- an Arcadyan VGV7510KW22 running LEDE and asterisk with chan_lantiq, this covers VDSL2 modem, router, pbx and SIP-ATA with two analogue FXS ports; wlan is a bit of a weak point though (single band, not the most reliable wlan chipset).
- your DECT phone connected, to its own analogue base station.
...
In case of internet via cable you'll have to add a dedicated cable modem to the mix, as there are no LEDE supported DOCSIS modems (and there probably can't be any either, given the certificate based trust chain between ISP and router), obviously you could also use a dedicated xDSL modem just as well, if you have additional requirements for your LEDE router not met by lantiq SOCs.
The fact that there are no LEDE (nor FOSS in general) supported DECT base stations does not imply that you can't keep your LAN secure and trusted (using FOSS software), nor that you have to use crude hacks like double-NAT and using your ISP router in front, but your hard- and software stack gets a tad more complex.