Excellent article, and sections "NAT Problems" and "NAT Solutions" are a good starter on that topic.
Except even third-choice solution is not always feasible. Reserving fixed RTP/UDP port range is not possible with carrier-grade NAT, which is quite common with residential ISPs and nearly-universal with cell ISPs.
Fourth-choice would be to reserve port range on a personal server (which would run B2BUA, asterisk in OP's case; or an RTP proxy), and force calls, including media, from/to SIP handsets to go via that.
Yes, Asterisk can poke holes in NAT on its own just fine. I was surprised how pessimistic the article is on this. I have systems running for months and years behind NAT with no issue. You might have to disable direct media (endpoint/disable_direct_media_on_nat).
Also, this is just uptime related tip not NAT, you must explicitly set registration/max_retries to a huge number otherwise Asterisk just gives up permanently at some point. It’s a really weird default.
Trunk and internal, and I usually put all the phones in their own VLAN w/o direct Internet access. I don’t really see a use for dialing arbitrary SIP URIs. If I need to add a remote phone I’ll just connect it directly with a network tunnel.
The idea is if you send UDP packets to destination so arranged by middleman(STUN) or to a proxy so arranged by middleman(TURN) as an outgoing traffic, your Wi-Fi should be smart enough to set up a temporary NAT entry to allow responses to reach your $LOCAL_IP:$PORT. In reality, the Wi-Fi may have short memory or may be dying behind a refrigerator covered in dust and not able to handle all necessary combinations and ranges of addresses and ports, resulting in various partial failures such as one-way audio or missing participant in a group call.
Fifth-choice option is to just encapsulate everything into a VPN, preferably L2 VPN over HTTPS to a server on a global IP. If it isn't working, there must be no Internet.
UDP is unreliable transport by specification, so I guess that if a network equipment such as a router cannot cope with the general workload, it would probably sacrifice UDP first without a second thought.
Huh? It's an obvious thing to do. If you have to drop a packet because your queues are full, any engineer with an IQ over 50 will pick the victim from the UDP packets, because the sender expects it might happen, and also because it won't necessary cause a retransmission - e.g. an RTP packet.
Why is that the obvious choice? TCP can recover through retransmission, UDP can not. Sounds just as logical of a choice to prioritize UDP and allow TCP connections to have a slowdown rather than allow UDP connections to have data loss.
As I said, application programmers expect and accept that their UDP packets might be lost or duplicated. This is sort of part of the contract. Even datagram integrity is in theory not guaranteed, as the checksum field of UDP is optional.
Sometimes people don't see a point at first in UDP because you eventually have to implement sequence numbers, CRCs, time-outs, retries, etc. that are similar to what TCP does. One can finds the reasons why one wants to do this anyway in [1]. In a nutshell, reliability is often insured by the application layer anyway so you don't need the transport protocol to do extra stuff you have no control over and might even get in the way (see the numerous esoteric ioctl and sysctl settings under Linux).
It is an obvious choice because, as I said again, a router dropping a packet does not necessary triggers a resend, e.g. RTP or syslog (over UDP). In TCP, this is guaranteed. If you are overloaded, you'd rather take the action you can get away with than probably just buy time.
This is not how congestion control works on the internet.
Indeed TCP depends on packets getting dropped as the feedback mechanism for knowing when to slow down.
It's important that packets are dropped fairly, as otherwise on a loaded network only the preferred protocol(s) would keep working and the others would get starved. You don't want DNS to stop working when a HTTP flow is running at capacity on your link for example.
Makes it boolean. It's connected, or it's not. "One of RTP media transports to one of destinations is failing to establish DTLS ciphering and I think it has to do with either RTC issue or Chrome bug" is a self inflicted pain.
All of the NAT problems would instantly to away with IPv6, but with adoption still at a meager 50% I suppose you'll need a PBX of some kind to receive at least half the calls.
For those stuck behind CGNAT, there are guides online for how to set up a VPN to a cheap VPS and forward all network traffic to your network so you can have almost-real connectivity at home. If you're content with 50mbps, you can even use Oracle's Always Free tier.
Would be interesting to hear why they use v4+nat and face the described problem. First thought was maybe they bought some very old phones without v6 support - but the models he recommends don't seem to have this problem based on a googled datasheet.
For what it's worth, and if you're willing to tinker, you can get IPv6 for free through a tunnel as long as your router responds to ICMP: https://tunnelbroker.net/
You can get a bunch of /64s and a /48 for free because HE really wants everyone to have IPv6 available already. Picking the right internet exchange to route from and making Netflix not throw a fit requires some minor experimentation but I've found it to work quite well.
As an added bonus, because of the way IPv6 route advertisements work, you don't have to have a router with tunneling support. You can set up advertisements from any Raspberry Pi or other computer as long as it has outbound connectivity.
That's rather silly. Getting IPv6 connectivity is usually the difficult part, and servers are the easiest things to get IPv6 for. I wonder what part of their tech stack is still incompatible after all these years.
You use one of the /64 tunnels provided for you to route the /48 tunnel to the rest of your network. You advertise a subnet from your /48 to your local network and if you've got SLAAC enabled on your hosts that's all there is to it.
You may need to mess with the default DNS server to get IPv6 results, though, that depends on whether or not your standard DNS server will respond to AAAA requests. It usually should, but some ISPs don't.
This only works for a flat network, of course. If you've got different routers, you'll need to set up a more complicated setup.
This was sort of a thing in the mid-2000s, and I’m actually surprised to see it again. At the time I expected home routers to become SIP endpoints (and that came to pass with fiber), but they all expose FXO interfaces (jacks) rather than act as proxies for soft phones, so there’s a missed opportunity there. But the truth of the matter is that just shipping a DECT phone in a bundle is much easier for the carrier to troubleshoot.
We could have easily been calling eachother by our email (SIP URIs) addresses. It is a shame that instead we got a dozen walled gardens when it comes to making voice/video calls over the internet.
Cool to read someone indulge in this. For others interested with no prior context, also consider FreeSWITCH.
Personal experience:
I spent about 15 months working for a local telecom company, supporting their asterisk servers and developing interactive voice response applications. I was given the opportunity to build their residential voip service (in 2010?) from scratch and despite asterisk being so dominant I prototyped and eventually completed the project using freeSWITCH. I found it to be so much more developer friendly to configure and extend. Being able to build dial plans and implement logic with JavaScript or Lua rather than asterisk's config files was worth it. I suspect this system is still running.
I took a look at freeSWITCH's site and it looks like they got bought out. Their documentation is a total mess because the acquiring company has imported lots of wiki pages without much care for how they fit together.
my wife had a requirement: be able to have an intercom for the house and shed. We used to have a baby monitor, but that was one way, for one room. Now we need many more rooms to talk to each other.
I looked at some intercoms on amazon/ebay, they are all RF and a bit shit. I saw some wifi ones, but nothing cheap enough to take a punt on. I did think about trying to make something with an ESP32, but that would be too hard for me in the time.
So I bought 6 cisco 7962 sip phones for £35 in total, and installed freepbx.
It took a bit of effort to bring the tftp server online, and make sure all the dhcp info was being passed on correctly. Once that was complete, freepbx makes most things pretty simple.
Now, I have ethernet is most rooms, and a switch that can do PoE, so this solution is for a niche of a niche
I remember playing with an old device as a child at my grandparents' place, it was similar to a walkie-talkie but transmitting using the mains power instead of RF. It was supposed to plugged to a socket and hanged on the wall. It was made exactly for the use case you describe, as an intercom between rooms. It even had a button to ring a bell in another room.
I actually run 7962g + FreePBX too, using sccp_manager and phone-integrated SSL-VPN. It took more hair pulling and shady patching than the SIP route, but now I can make intercom calls over the Internet! That way I don't need a direct L1/L2 link between "offices". Solves NAT problems too, because it's all in-band signaling and media transport over single TCP connection.
I hope you ran optical between the house and the shed. The difference in ground potential among buildings can cause a lot of trouble for copper/electrical connections.
Having gone down this road many times with freepbx, asterisk, etc.. I ultimately settled on just using voip.ms and connecting phones/sip clients directly to their internal sub-accounts with voicemail. They have enough features for most users so you don't need to worry about running your own PBX.
Yeah, I would second this. In SIP a UA is a UA. So long as your softphone is good and your microphone is as well, there shouldn't be any difference. Although I would suspect the general experience may be that people with softphones more often will have terrible microphones for their PC...
I disagree. Yes, in theory, an agent is an agent, but in practice I have never in my life at any point seen computer hardware that comes anywhere close to the usability of a Polycom device.
I have been using voip.ms since 2015 for my phone service. Multiple numbers (DIDs) pointing to an IVR where callers must press 1 to connect to me (totally avoids robocalls). Plus voicemail (transcribed and emailed to me).
One issue with voip on mobile (iOS in my case) is that I would often miss calls due to late push notifications and timing out. So recently I set up a calling queue that rings/pushes my phone a few times instead of just once (queue timeout to 30 seconds before hitting voicemail).
Basically, if you want the control FreeSwitch and Asterisk offer but don't want to self-host, voip.ms is the best way to go.
Yep, if I set 'Allow Incoming SIP Messages from SIP Proxy Only' to 'no' (allows direct SIP-SIP calls) on my home VoIP service, I'll get a silent call from '500' about every minute or so.
I've written about it elsewhere in this thread but I've found that a simple vopice menu that has a message (that might sound like a voicemail to a spammer's dial computer) and that requires people dialing in to press one key stops 99% of spammers
I run a public SIP server, and it gets constantly attacked just like any other public service. Mostly trying to use it to call expensive routes hoping it's unsecured though, not trying to spam local extensions.
I'm eagerly awaiting jmp.chat to branch out into Europe (they have plans, but no concrete timeline).
I'm curious why not sipgate, which I currently use, or Twilio which I half-use (it mostly forwarded to my own Asterisk server, which needs some attention).
Do you have any specific issues with Sipgate? I only have a couple of numbers with them and don't use them much but am curious what their reputation is like.
I can't say anything about sipgate's reputation, as i haven't used their service. It just has been an issue with limited service availability in my country (BE)..
Ah good memories! Even though I knew nothing about VoIP I installed, years ago, one at my wife's little SME using "RasPBX" (a distro made of Raspbian + FreePBX + Asterisk) running on a... Raspberry Pi 1 (maybe a Pi 2 but I'm pretty sure it was a 1). The Pi was booting from the SD card but everything was running on an external HDD.
I did put six Cisco VoIP phones and all was working fine as long as no more than four phones were used simultaneously (which never happened). It worked for years like that and wife ended up selling her SME with these VoIP phones still hooked to the RPi 1. We warned them that that thing was kinda a hack ; )
For anyone hesitating: it's not hard to set up. Find a provider to get a SIP trunk, configure the thing, backup the config (I just imaged the entire drive), and you're good to go for a very long time.
It's simple, reliable, stuff that usually won't move under your feet.
I have a tangentially related problem I have been battling with that you may be able to help me with. I'm moving overseas (Australia to Denmark) and would like to keep my current mobile phone number working for calls and SMS , but use it from afar. I would be able to leave a raspberry pi at a friend's house. Can you use this setup without a SIP provider? Would you need to buy a modem for the raspberry pi?what would you do?
I've never done it, but look into chan_mobile and a bluetooth dongle to connect a mobile (with your SIM) to asterisk running on a Pi at your friend's place.
I would just port my number to twilio and use/write a really basic twilio mobile app. It's a bit risky to rely on a slightly cobbled hardware/software setup that is sitting across the world with no physical access.
Note that one problem with voip providers is the numbers/lines often won't be recognized as valid by snake oil 2FA and the like. So porting to a voip provider only works if your goal is receiving SMS/calls from actual humans or just parking the number for later. But if you're doing it to avoid having to change your number for every service that has an SMS nagwall, it likely won't work.
You can get a modem that will do SMS (eg a Sierra Wireless card), but I don't know if/how they do voice.
Also, I'd shy away from the RPi based on the unreliability of SD cards. It would/will be pretty annoying for your host to go down and you have to travel back to fix it. I suppose if your friend is halfway handy you could keep an image of the machine as installed. Or even take new images remotely (rsync from the raw device a few times in a row?). If the root filesytem goes wonky, have your friend pull the SD card and reimage it.
I've been using a voip number for all my sms 2fa needs for the last 5 years while living abroad. I have a dozen banks and other financial institutions plus the irs happily accepting it. Some companies, like openai, wont accept it, for those I just buy single use SMS numbers.
I've had problems with a bunch of places, so it's at least YMMV then. And I'd be wary of transferring an existing number in (as opposed to getting a new voip number and then setting it up).
I'm sure specific services are hit or miss - there really shouldn't be a problem sending SMS to whatever number a user enters, but paternalistic snake oil salesmen gonna be paternalistic.
I've had the least difficulty with Google Voice (I believe it's impossible to tell "Google Voice" usage from bona fide Fi usage where it's really the users' only phone number). Voip.ms has worked very little for me, to the point of that I don't even try it. Heck I even used a voip.ms number for some online classifieds, and another person using Comcast/Xfinity mobile couldn't text me. I'm not saying this as a slight against Voip.ms itself, from what I've gathered most voip providers will be treated similarly.
One of these days when I get around to it I plan on setting up a wireless modem on a $3/mo paygo plan for my SMS nag needs. With a script that automatically brings the number as close to my paste buffer as possible.
What single use SMS service do you use? I haven't really investigated those.
> I believe it's impossible to tell "Google Voice" usage from bona fide Fi usage where it's really the users' only phone number
These are definitely distinguishable, and some auth service treat them differently. Google Voice numbers come from a different carrier (the one named Bandwidth) than most Fi numbers.
"One of these days when I get around to it I plan on setting up a wireless modem on a $3/mo paygo plan for my SMS nag needs. With a script that automatically brings the number as close to my paste buffer as possible."
I use something similar. A dedicated app makes a POST request to my Google Apps Script as soon as any sms arrives at my second phone. That script sends it in a Telegram Bot Chat to all of my devices.
I use a RedPocket (GSMA Flavor) $60/year for my resume and 2FA number as an eSIM.
I turn it on when needed, which is almost never. When not job searching, the voicemail plays the classic "this line has been disconnected" tones and message on repeat for two minutes. WiFi calling means I can use it anywhere I have WiFi.
I get incredibly few spam calls using this strategy.
There are two different reasons companies ask for your phone number, and it's worth distinguishing between them:
The first is for sending a verification code during signup to prevent spammy/abusive signups. In my experience, this is the least likely to work with VoIP numbers because companies often intentionally block VoIP numbers.
The second is for sending 2FA codes during login. My experience with this has been much better. AFAICT, companies do not intentionally block VoIP numbers for this use case. When SMS does fail, there is almost always an option to send the code by voice call, and this is always 100% reliable.
I also have some experience with using a modem with a SIM card to receive SMS. I've used two different models of modem (not Sierra Wireless) and both have been very flaky, often locking up and requiring a power cycle, or having hours-long delays when receiving SMS. I would not call this approach a panacea.
Unfortunately, Twilio is no longer a viable option for sending SMS for personal use. If you want to send SMS you have to register a "campaign" and jump through a bunch of hoops that assume you're a company sending a large volume of application-generated messages (e.g. you must disclose samples of the types of messages you intend to send, and get explicit opt-in from recipients). Up until now, I've managed to avoid registering a campaign by instead paying a slightly higher per-message cost, but this is being phased out on July 5. I've been trying out https://jmp.chat (their founder is commenting elsewhere in this thread) and will likely port my number to them.
Hmmm ... I think the July 5 deadline is specifically for UK recipients ?
Regardless, your overall impression is correct: Twilio is no longer a hacker/hobbyist/enthusiast option as you cannot (by the letter of the law, at least) send SMS without registering your business entity:
This is very troublesome to me because I have built my own personal telco out of twilio functions and twiml bins, etc., and am heavily reliant on all manner of SMS workflows.
As of this writing (2023-05-27) everything - even SMS delivery to T-Mobile numbers - continues to "just work" but it sounds like I will just wake up one morning to have it all broken ...
> • Effective July 5, 2023, all 10DLC phone numbers used to send SMS and MMS messages to U.S. phone numbers must be fully registered to an approved campaign under your brand. Messages sent using unregistered phone numbers will be subject to a gradual increase of message blocking by Twilio, beginning on July 5, 2023, ultimately leading to a full block of all unregistered U.S.-bound messages sent after August 31, 2023.
This is pretty much exactly the problem that we originally created https://jmp.chat to solve, no sip or complex setup needed these days for that use case.
I heard about you ages ago and wanted to use your service ever since. The only problem I don't need it for anything. But I'm glad you you are still there.
I use Callcentric for this. Ported a land line over years ago. It now has SMS which I can do using the Callcentric app. And it forwards voicemails to me with email. Otherwise I don’t use that line for actual calls anymore.
I've been working with bespoke VOIP/asterisk systems for a decade, I have one bit of advice to add - consider toll fraud. Especially for a system accessible from the internet. If an attacker can figure out how to make calls through your PBX, they can rack up tens of thousands of dollars in tolls over the course of a night.
Most of the integrated FOSS solutions come with fail2ban already configured, it is essential. If you want more peace of mind, a prepaid trunk helps. That means you charge up your sip trunk account, and if someone drains it, it just stops working instead of continuing to drain your bank account.
You can also limit international calling on your trunks, which effectively nullifies the financial drain of this kind of attack (though it's still obviously bad if an attacker can access your system in any way)
Well I basically used a a Linux distribution made precisely for this: it was called "RasPBX" back then, IIRC. The hardware was simple: a Pi 1, an external HDD hooked through USB to the Pi and Cisco VoIP phones. That Linux distro already took care of picking software components/versions all working fine together and it was tailor made for the Pi. It was pretty plug and play from what I remember.
I'm a software dev, not a sysadmin, but I can find my way around configure Linux machines.
I don't remember it as being particularly complicated. What I do remember for sure though is that once it worked, it worked flawlessly for years.
I believe they're still related but the guys at Nerd Vittles [0] are still doing a PBX in a Box style deployment. Looks like it's called Incredible PBX [1] now. But the last time I ran it it took a lot of considerations around running SIP securely and brought a few of the pieces together. Probably worth a look if you're interested in self-hosting at home or for SMB.
Nerd Vittles is alive and well. And Incredible PBX now offers dozens of free, turnkey platforms. Have a look at wiki.incrediblepbx.com for suggestions.
I’ve used to live in an inter generational big house (Italians am I right… even if we are not actually born there we still have spaghetti dna). Anyway I’ve setup one very lightweight asterix instance of statically defined accounts. A few cheap voip phones were installed through the house plus soft phones on personal smartphones.
It was supposed to make things more convenient. Supposed to, because we just kept yelling to convey messages. When I’ve moved out I’ve dismantled the system since I wouldn’t be there to keep it maintained.
I put in an asterix system 20 years ago, it still runs great, all I've done has been to replace a couple of dying (RAIDed) drives. I live in NZ used to live in the Bay Area, NZ trunks come in from a local SIP provider and use an Ooma box for our old US phone number, in home we had 5 FXSs and a sip phone in my office - everyone had a phone in their bedroom, and a couple on public spaces.
It's set up so that all incoming calls hit a voice prompt saying which 1-digit extension you should enter to get who (this stops 99% of phone spam) - everyone gets a voicemail on their extension which rings in their bedroom and rolls over to the common spaces - and everyone gets a unique ring cadence, my daughter who at one point got 80% of the phone calls got the 2 short rings.
The kids have gone, we've moved to a smaller house, only 2 extensions, but that same hardware soldiers on (and still stops 99% of the spam - I've had 1 call in the past year)
VoIP used to be standard on phones, even mobile smartphones. So I setup Asterisk so that family members could call each others as long as they where on WIfi. Unfortunately VoIP is no longer a built in standard so you need to download an app to use it. Before you could just dail 1 and my phone would ring, dail 2 and you would reach my wife.
> Use a SIP Application Layer Gateway. This is a horrible feature offered by some routers. Basically, it deep-packet-inspects your SIP traffic, rewrites the headers, and creates port forwards on-the-fly to make sure the inbound audio stream makes its way to your device. SIP ALGs are a total hack and notoriously buggy.
Yes, these hacky ALG features also allowed internet users to access internal IPs on arbitrary services (!); named “remote arbitrary firewall pinhole control”. The attack was published in 2020 and named NAT slipstreaming [1].
This was on by default on a consumer router that was used at a small office. Their VoIP phones would get phantom calls until I discovered this and disabled it.
It would have been 2-3 years ago. I was getting reports of phones ringing, but no audio, no calls record from the VoIP server CDR (which all phones were configured to proxy through) and when looking @ the system logs from the phones, they were reporting nonsensical IP addresses, which pointed to something at the edge of the network.
I'm pretty sure you've solved a mystery I was confused by years ago, back when I was doing tech support.
It wouldn't have mattered much because the router/modem combos in use didn't have a switch for SIP ALG anyway, bit it's good router finally know what could've caused the phantom phone ringing.
You can install Acrobits Groundwire or Bria. Those support PUSH notification for incoming calls. Push is better than missing calls because the app got killed, or forcing the app to run 24/7 and severely shortening battery runtime.
But the call quality will never be as good as the native phone app as that gets QCI prioritization.
One of my first job, in 201, was to create a spam faxing machine based on Asterisk.
Once the initial setup was completed (T38 is a bit tricky to tune), it was very effective, it sent more than one milion of faxes every year.
There is SIP and XMPP, but they may be overconvoluted for what I am trying to achieve. Namely, I am not aiming at internet universality (no IPv4 sharing abomination built into the protocols).
I am looking at a modular set of protocols built mainly for IPv6.
The base: the "telephone number" would be ipv6:port. "Ringing" and video/audio streams setup would be done here. End to end encrytion right from the start (only manual key exchange, zero automatic, even before ringing).
On top, a "comfort protocol"(one level of indirection) for those changing ipv6, but not "accutely roaming", namely changing ipv6 while in a video/audio call: a "DynDNS" but simpler, more a "current IPv6:port of 'name' kind of thing", "address book with a drop of dynamic", "name@server" and you get the current ipv6:port. Unfortunately, it means "accounts" and real time updates. Of course, "server" could be a local/dns/ipv6. I am thinking zero password, only a public key.
For video/audio streams, I may not bother and go TCP. The main constraint would be the timing information shared among video/audio streams. No "internet weather" dynamic reconfiguration.
I even consider going "horribly horrible" for internet: idiotic binary based instead of text based protocols.
People still actually make phone calls? I mean its neat that you can run your own voip, but I struggle to imagine it getting used much or being worth even $5/month
I want to set something like this up myself, probably less for external calling than as an in-home intercom. Public dialing might be handy just so it can easily include cell phones.
I'm just about to ask for my landline to be disconnected, no sense in paying for something I hardly ever use, won't bother porting the number to VoIP. Will either just keep the copper pair for VDSL or switch to FTTP.
The only person that I did call using the landline is my father, but his VoIP system is unreliable.
When I'm conversing with family or friends by phone using my VoIP, and the connection starts getting bad, I always volunteer that the problem is not on my end, since my connection is wired.
You get some statistics for queues but also for example you might want to only take one call at a time even if you can answer from multiple. Also Asterisk queues make it very easy to do things like 'there’s N callers waiting' etc.
A queue shines when it can distribute incoming calls based on it knowing agent availability. (Shameless plug: the company I work for does cloud reporting [1] for Asterisk and FreeSwitch queues - that is then whitelabelled and sold by a lot of big name telcos worldwide. Not sexy but effective!)
Acrobits Groundwire. Counterpath’s Bria Mobile. These use push notifications for incoming calls. That way there’s no missed calls because the operating system killed the app or battery drain caused by keeping the app running.
It's worth noting that Asterisk will run on very low-end hardware: for the last 7 or so years, I've been running a small Asterisk box on a VIA C3 Mini-ITX system. System idle power is around 10W. The only reason I chose the VIA C3 system over something newer was that a) I already had it and b) it had a PCI slot (specifically PCI, not PCIe).
The PCI slot let me plug in a Digium TDM800P and add eight POTS lines, either FSX or FXO, for pretty cheap.
Today you could have the same average power consumption with an Odroid H3, and probably juggle more quality codecs too. (Well, sans the Digium card; but it’s just mindboggling how far we went with power consumption these days.)
I’m wondering how necessary POTS lines actually are these days (and how many connect to VoIP on the telco side). Should depend on the country.
The H3 has an M.2 slot and a separate emmc slot. So if you really wanted to use that card perhaps you could use an M.2 to PCIe connector and then connect that in turn to a PCIe to PCI adapter/riser. Power might be an issue though.
These days POTS lines are usually only used for last mile communications so the calls get converted to VoIP on the telco side. Basically it's for backwards compatibility — the phone lines are already there, a lot of people have phone wiring in their houses and no configuration is required on the consumer's end.
In general the days of having direct electrical connections between two distant telephones are long gone. The telco companies scrapped it when they realized that they could trunk the phone calls from a local branch to the central office using PCM streams over a single cable.
Metallic path between two stations that weren't terminated in the same CO has been dead for a long time! I suspect nowadays you're unlikely to have metallic path outside the frame you land on, if that, unless you're paying for dry pairs.
The POTS lines were largely for goofing around, though I did use a FXO port to bring in the local POTS line. Mostly I used the FXS ports to interface a 1A2 KSU to Asterisk to run my old WE 2500 series key station.
90% of the traffic was handled over SIP or IAX to desk sets or ATAs.
I am one of the few people from my generation to maintain a "land line" (VoIP) and I, too, run it with Asterisk and the FreePBX configuration GUI. FreePBX provides a ton of macros out-of-the-box so that adding unwanted callers to a blacklist or doing phone number lookups is simple, for example. Why bother? Well, I find it interesting and fun, but most of the stuff I like can also be done with Google Voice. So I don't recommend self-hosting a phone system unless you are really into the idea and want to spend a decent amount of time learning telecom domain knowledge.
So, maybe one of the VoIP experts that showed up on this thread can help me with one doubt...
Let's say that I have a LDAP server where I manage user accounts, and I want people to be able to call each other with any SIP-enabled phone. I am not interested in voicemail/IVRs/any type of "voice application" on top of that. Do I really need Asterisk/FreeSWITCH or can I just go buy by setting up something like Kamailio?
Kamailio is what is called a Session Border Controller. Its primary purpose is to provide protection and some lightweight filtering for the media servers/PBXs behind it. Once you want "advanced" features like voicemail, parking, hunt groups, three-way calling, etc, you will need to use a PBX like FreeSWITCH (recommended) or Asterisk (not) behind it anyway. If you're only running a single machine, an SBC isn't really worth the trouble.
> Once you want "advanced" features like voicemail, parking, hunt groups, three-way calling.
Right, but what I am saying is that I don't want any of those features. At least not yet.
I just want to give my customers a sip address (username@communick.com) where they can call other SIP addresses. In that case, is that a PBX still needed?
Jitsi has something built in, I havent used it but I expect it's similar to big blue button which I have done, it runs a freepbx so setting up some extra dialplan rules to get interconnect is possible.
148 comments
[ 4.3 ms ] story [ 223 ms ] threadExcept even third-choice solution is not always feasible. Reserving fixed RTP/UDP port range is not possible with carrier-grade NAT, which is quite common with residential ISPs and nearly-universal with cell ISPs.
Fourth-choice would be to reserve port range on a personal server (which would run B2BUA, asterisk in OP's case; or an RTP proxy), and force calls, including media, from/to SIP handsets to go via that.
Also, this is just uptime related tip not NAT, you must explicitly set registration/max_retries to a huge number otherwise Asterisk just gives up permanently at some point. It’s a really weird default.
The idea is if you send UDP packets to destination so arranged by middleman(STUN) or to a proxy so arranged by middleman(TURN) as an outgoing traffic, your Wi-Fi should be smart enough to set up a temporary NAT entry to allow responses to reach your $LOCAL_IP:$PORT. In reality, the Wi-Fi may have short memory or may be dying behind a refrigerator covered in dust and not able to handle all necessary combinations and ranges of addresses and ports, resulting in various partial failures such as one-way audio or missing participant in a group call.
Fifth-choice option is to just encapsulate everything into a VPN, preferably L2 VPN over HTTPS to a server on a global IP. If it isn't working, there must be no Internet.
Sometimes people don't see a point at first in UDP because you eventually have to implement sequence numbers, CRCs, time-outs, retries, etc. that are similar to what TCP does. One can finds the reasons why one wants to do this anyway in [1]. In a nutshell, reliability is often insured by the application layer anyway so you don't need the transport protocol to do extra stuff you have no control over and might even get in the way (see the numerous esoteric ioctl and sysctl settings under Linux).
It is an obvious choice because, as I said again, a router dropping a packet does not necessary triggers a resend, e.g. RTP or syslog (over UDP). In TCP, this is guaranteed. If you are overloaded, you'd rather take the action you can get away with than probably just buy time.
[1] https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...
Indeed TCP depends on packets getting dropped as the feedback mechanism for knowing when to slow down.
It's important that packets are dropped fairly, as otherwise on a loaded network only the preferred protocol(s) would keep working and the others would get starved. You don't want DNS to stop working when a HTTP flow is running at capacity on your link for example.
For those stuck behind CGNAT, there are guides online for how to set up a VPN to a cheap VPS and forward all network traffic to your network so you can have almost-real connectivity at home. If you're content with 50mbps, you can even use Oracle's Always Free tier.
You can get a bunch of /64s and a /48 for free because HE really wants everyone to have IPv6 available already. Picking the right internet exchange to route from and making Netflix not throw a fit requires some minor experimentation but I've found it to work quite well.
As an added bonus, because of the way IPv6 route advertisements work, you don't have to have a router with tunneling support. You can set up advertisements from any Raspberry Pi or other computer as long as it has outbound connectivity.
None of the 4 VoIP providers I've worked with support IPv6 :-/
You mean send the advertisement and do the SIT tunneling on that machine?
You use one of the /64 tunnels provided for you to route the /48 tunnel to the rest of your network. You advertise a subnet from your /48 to your local network and if you've got SLAAC enabled on your hosts that's all there is to it.
You may need to mess with the default DNS server to get IPv6 results, though, that depends on whether or not your standard DNS server will respond to AAAA requests. It usually should, but some ISPs don't.
This only works for a flat network, of course. If you've got different routers, you'll need to set up a more complicated setup.
Personal experience:
I spent about 15 months working for a local telecom company, supporting their asterisk servers and developing interactive voice response applications. I was given the opportunity to build their residential voip service (in 2010?) from scratch and despite asterisk being so dominant I prototyped and eventually completed the project using freeSWITCH. I found it to be so much more developer friendly to configure and extend. Being able to build dial plans and implement logic with JavaScript or Lua rather than asterisk's config files was worth it. I suspect this system is still running.
I looked at some intercoms on amazon/ebay, they are all RF and a bit shit. I saw some wifi ones, but nothing cheap enough to take a punt on. I did think about trying to make something with an ESP32, but that would be too hard for me in the time.
So I bought 6 cisco 7962 sip phones for £35 in total, and installed freepbx.
It took a bit of effort to bring the tftp server online, and make sure all the dhcp info was being passed on correctly. Once that was complete, freepbx makes most things pretty simple.
Now, I have ethernet is most rooms, and a switch that can do PoE, so this solution is for a niche of a niche
[1]: https://a.co/d/31rKR02
The only thing I have to add: if you need to make telephone calls, the call quality using a SIP phone is much better than using a softphone.
One issue with voip on mobile (iOS in my case) is that I would often miss calls due to late push notifications and timing out. So recently I set up a calling queue that rings/pushes my phone a few times instead of just once (queue timeout to 30 seconds before hitting voicemail).
Basically, if you want the control FreeSwitch and Asterisk offer but don't want to self-host, voip.ms is the best way to go.
I'm curious why not sipgate, which I currently use, or Twilio which I half-use (it mostly forwarded to my own Asterisk server, which needs some attention).
[0] https://help.sipgate.de/hc/de/articles/4407798852113-sipgate...
We offer a virtual PBX based on Asterisk, Kamailio and Matrix/Element in Germany.
I did put six Cisco VoIP phones and all was working fine as long as no more than four phones were used simultaneously (which never happened). It worked for years like that and wife ended up selling her SME with these VoIP phones still hooked to the RPi 1. We warned them that that thing was kinda a hack ; )
For anyone hesitating: it's not hard to set up. Find a provider to get a SIP trunk, configure the thing, backup the config (I just imaged the entire drive), and you're good to go for a very long time.
It's simple, reliable, stuff that usually won't move under your feet.
You can get a modem that will do SMS (eg a Sierra Wireless card), but I don't know if/how they do voice.
Also, I'd shy away from the RPi based on the unreliability of SD cards. It would/will be pretty annoying for your host to go down and you have to travel back to fix it. I suppose if your friend is halfway handy you could keep an image of the machine as installed. Or even take new images remotely (rsync from the raw device a few times in a row?). If the root filesytem goes wonky, have your friend pull the SD card and reimage it.
I'm sure specific services are hit or miss - there really shouldn't be a problem sending SMS to whatever number a user enters, but paternalistic snake oil salesmen gonna be paternalistic.
I've had the least difficulty with Google Voice (I believe it's impossible to tell "Google Voice" usage from bona fide Fi usage where it's really the users' only phone number). Voip.ms has worked very little for me, to the point of that I don't even try it. Heck I even used a voip.ms number for some online classifieds, and another person using Comcast/Xfinity mobile couldn't text me. I'm not saying this as a slight against Voip.ms itself, from what I've gathered most voip providers will be treated similarly.
One of these days when I get around to it I plan on setting up a wireless modem on a $3/mo paygo plan for my SMS nag needs. With a script that automatically brings the number as close to my paste buffer as possible.
What single use SMS service do you use? I haven't really investigated those.
These are definitely distinguishable, and some auth service treat them differently. Google Voice numbers come from a different carrier (the one named Bandwidth) than most Fi numbers.
This is called a "2FA Mule":
https://kozubik.com/items/2famule/
"A 2FA Mule is a mobile phone configured to forward SMS 2FA codes via email."
I turn it on when needed, which is almost never. When not job searching, the voicemail plays the classic "this line has been disconnected" tones and message on repeat for two minutes. WiFi calling means I can use it anywhere I have WiFi.
I get incredibly few spam calls using this strategy.
The first is for sending a verification code during signup to prevent spammy/abusive signups. In my experience, this is the least likely to work with VoIP numbers because companies often intentionally block VoIP numbers.
The second is for sending 2FA codes during login. My experience with this has been much better. AFAICT, companies do not intentionally block VoIP numbers for this use case. When SMS does fail, there is almost always an option to send the code by voice call, and this is always 100% reliable.
I also have some experience with using a modem with a SIM card to receive SMS. I've used two different models of modem (not Sierra Wireless) and both have been very flaky, often locking up and requiring a power cycle, or having hours-long delays when receiving SMS. I would not call this approach a panacea.
Regardless, your overall impression is correct: Twilio is no longer a hacker/hobbyist/enthusiast option as you cannot (by the letter of the law, at least) send SMS without registering your business entity:
https://twitter.com/rsyncnet/status/1593384850073214976?lang...
This is very troublesome to me because I have built my own personal telco out of twilio functions and twiml bins, etc., and am heavily reliant on all manner of SMS workflows.
As of this writing (2023-05-27) everything - even SMS delivery to T-Mobile numbers - continues to "just work" but it sounds like I will just wake up one morning to have it all broken ...
> • Effective July 5, 2023, all 10DLC phone numbers used to send SMS and MMS messages to U.S. phone numbers must be fully registered to an approved campaign under your brand. Messages sent using unregistered phone numbers will be subject to a gradual increase of message blocking by Twilio, beginning on July 5, 2023, ultimately leading to a full block of all unregistered U.S.-bound messages sent after August 31, 2023.
Source: https://support.twilio.com/hc/en-us/articles/1260800720410-W...
Most of the integrated FOSS solutions come with fail2ban already configured, it is essential. If you want more peace of mind, a prepaid trunk helps. That means you charge up your sip trunk account, and if someone drains it, it just stops working instead of continuing to drain your bank account.
You can also limit international calling on your trunks, which effectively nullifies the financial drain of this kind of attack (though it's still obviously bad if an attacker can access your system in any way)
I'm a software dev, not a sysadmin, but I can find my way around configure Linux machines.
I don't remember it as being particularly complicated. What I do remember for sure though is that once it worked, it worked flawlessly for years.
[0] https://nerdvittles.com/ [1] https://wiki.incrediblepbx.com/
I use WebRTC with Asterisk, and Browser Phone for the client (https://github.com/InnovateAsterisk/Browser-Phone). I don't use it much, but good enough for the rare times I have to use the phone.
It was supposed to make things more convenient. Supposed to, because we just kept yelling to convey messages. When I’ve moved out I’ve dismantled the system since I wouldn’t be there to keep it maintained.
It's set up so that all incoming calls hit a voice prompt saying which 1-digit extension you should enter to get who (this stops 99% of phone spam) - everyone gets a voicemail on their extension which rings in their bedroom and rolls over to the common spaces - and everyone gets a unique ring cadence, my daughter who at one point got 80% of the phone calls got the 2 short rings.
The kids have gone, we've moved to a smaller house, only 2 extensions, but that same hardware soldiers on (and still stops 99% of the spam - I've had 1 call in the past year)
Yes, these hacky ALG features also allowed internet users to access internal IPs on arbitrary services (!); named “remote arbitrary firewall pinhole control”. The attack was published in 2020 and named NAT slipstreaming [1].
[1] https://samy.pl/slipstream/
When was this approximately? I’m wondering how widespread this (still) is.
It wouldn't have mattered much because the router/modem combos in use didn't have a switch for SIP ALG anyway, bit it's good router finally know what could've caused the phantom phone ringing.
I am looking at a modular set of protocols built mainly for IPv6.
The base: the "telephone number" would be ipv6:port. "Ringing" and video/audio streams setup would be done here. End to end encrytion right from the start (only manual key exchange, zero automatic, even before ringing).
On top, a "comfort protocol"(one level of indirection) for those changing ipv6, but not "accutely roaming", namely changing ipv6 while in a video/audio call: a "DynDNS" but simpler, more a "current IPv6:port of 'name' kind of thing", "address book with a drop of dynamic", "name@server" and you get the current ipv6:port. Unfortunately, it means "accounts" and real time updates. Of course, "server" could be a local/dns/ipv6. I am thinking zero password, only a public key.
For video/audio streams, I may not bother and go TCP. The main constraint would be the timing information shared among video/audio streams. No "internet weather" dynamic reconfiguration.
I even consider going "horribly horrible" for internet: idiotic binary based instead of text based protocols.
The only person that I did call using the landline is my father, but his VoIP system is unreliable.
[1] https://www.queuemetrics.com
The PCI slot let me plug in a Digium TDM800P and add eight POTS lines, either FSX or FXO, for pretty cheap.
I’m wondering how necessary POTS lines actually are these days (and how many connect to VoIP on the telco side). Should depend on the country.
In general the days of having direct electrical connections between two distant telephones are long gone. The telco companies scrapped it when they realized that they could trunk the phone calls from a local branch to the central office using PCM streams over a single cable.
90% of the traffic was handled over SIP or IAX to desk sets or ATAs.
Let's say that I have a LDAP server where I manage user accounts, and I want people to be able to call each other with any SIP-enabled phone. I am not interested in voicemail/IVRs/any type of "voice application" on top of that. Do I really need Asterisk/FreeSWITCH or can I just go buy by setting up something like Kamailio?
Right, but what I am saying is that I don't want any of those features. At least not yet.
I just want to give my customers a sip address (username@communick.com) where they can call other SIP addresses. In that case, is that a PBX still needed?
You don't need to run any of the advanced features in Asterisk (and can completely unload the modules if you want).