Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Building a Personal VoIP System

sacredheartsc.com

Post reply on HN
Print view View original

141–150 of 150 posts

Re: Building a Personal VoIP System

#141

Post by davchana »

rsync wrote: post #124
mindslight wrote: post #87

Earlier quoted context omitted.

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…

"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." 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 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.

Re: Building a Personal VoIP System

#142

Post by xboxnolifes »

astrobe_ wrote: post #132
remram wrote: post #117

Earlier quoted context omitted.

If you don't have any evidence, guessing that routers/modems prioritize IP packets based on the next protocol sounds like a conspiracy theory.

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.

Re: Building a Personal VoIP System

#143

Post by 6ak74rfy »

jonpurdy wrote: post #39
gamedna wrote: post #9

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.

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 t…

What app do you use on iOS with voip.ms?

Re: Building a Personal VoIP System

#144

Post by astrobe_ »

xboxnolifes wrote: post #142
astrobe_ wrote: post #132

Earlier quoted context omitted.

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.

[1] https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...

Re: Building a Personal VoIP System

#145

Post by fulafel »

astrobe_ wrote: post #106
remram wrote: post #78

Earlier quoted context omitted.

Why would that be more reliable than TURN? If your router "forgets" about established streams half-way, your VPN will not stay connected either.

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.

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.

Re: Building a Personal VoIP System

#146

Post by NerdUno »

windexh8er wrote: post #98
TacticalCoder wrote: post #15

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 p…

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. [0] https://nerdvittles.com/ [1] https://wiki.incre…

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.

Re: Building a Personal VoIP System

#147

Post by remram »

astrobe_ wrote: post #144
xboxnolifes wrote: post #142

Earlier quoted context omitted.

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 ca…

That some be lost is expected, that all of them be blocked is not.

Re: Building a Personal VoIP System

#148

Post by KaiserPro »

NoZebra120vClip wrote: post #140
KaiserPro wrote: post #8

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 h…

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.

We are shared earth, but also ethernet has around 600v of isolation (from what I can recall.)

Re: Building a Personal VoIP System

#149

Post by jonpurdy »

6ak74rfy wrote: post #143
jonpurdy wrote: post #39

Earlier quoted context omitted.

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 t…

What app do you use on iOS with voip.ms?

Bria ($1/mo subscription). Works as well as a voip client could work on iOS.

Re: Building a Personal VoIP System

#150

Post by EVa5I7bHFq9mnYK »

Spooky23 wrote: post #110
mindslight wrote: post #87

Earlier quoted context omitted.

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…

Some services can definitely detect Google Voice. Chase bank won’t send SMS to voice.

I have a Chase account, they send 2fa texts to my voip number ok, but it's not Google Voice, it's another service.
Post reply on HN