VOIP - fuck you it's 2016 just call me on my cellphone

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > VOIP - fuck you it's 2016 just call me on my cellphone

wolrah: May 8, 2006; what?

I haven't done it yet but that is near the top of my to-do list to play with. I have OpenVPN set up at my house and a few examples of both the T2x and T4x lines so I might tinker with it this weekend if I get bored. Any specific questions or just looking for an example config to follow?

edit: Unrelated FYI, if you have a Polycom phone with a MAC that doesn't start in 64167F rather than 0004F2 make sure you're running 4.0.10revD or newer.

# ¿ Mar 3, 2017 00:04

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 20:11

wolrah: May 8, 2006; what?

adorai posted:

I just recycled a bunch of yealink phones. One of our tenants bailed and left behind about 10. Guess I should have kept them.

If they were T2x phones they're not worth all that much, though they're still decent if ugly phones. T4x are my current favorite line of VoIP phones on the market, especially the new T4xS models.

# ¿ Mar 6, 2017 03:49

wolrah: May 8, 2006; what?

CrazyLittle posted:

Yeah their audio quality is on par with polycom minus the brain dead provisioning syntax.

Audio is about 97% the same on headset or handset, but Polycom's speakerphones are still worlds better than the competition. My Yealink T46S is my favorite day-to-day phone right now but if I know I'm going to be using speakerphone for something I switch over to my Polycom VVX400.

Which one are you calling brain dead? Yealink's is a pretty straightforward plaintext config file and Polycom's is XML Polycom's parser is a bit weird and the format of their example configs takes advantage of that weirdness, but they are valid XML that you can both generate and parse with standard XML libraries.

# ¿ Mar 6, 2017 06:09

wolrah: May 8, 2006; what?

CrazyLittle posted:

Polycom's XML format is bad. They made it with the intent of having a singular config that applies to all poly soundpoint phones, but it doesn't work that way. I still end up with a ton of tiny fixes here and there for models and firmwares where the customers BYOD.

Weird. I use literally the same config template for everything on 4.0 or later, and the old 3.x phones will still take those configs but they take longer to process and throw a ton of warnings while doing it.

quote:

Also the VVX series is kind of a joke, their android fork is kneecapped, and their companion software is barely functional if you can keep it connected to the deskset at all.

Are you trying to say the VVX series uses Android? They run Linux for sure but I haven't seen any evidence that Android is hiding in there anywhere. It's been a while since I used a VVX1500 but the UI elements on the touchscreen models made me think Qt more than any of the Android variants. The non-touch models don't really expose any UI elements that haven't been Polycom themed so there's not much to judge there. I'm not saying they don't run Android, just that if it does they did a really good job hiding it.

Agreed about the companion software, I've literally never had it work.

quote:

... and then there's Cisco.

Who for years rebranded Polycom's conference room phones as their own. Cisco's desktop phone speakers are pretty drat good though, at least on their flagship line. The SPA series, not so much. Back when the 7940/60 were still relevant those were our go-to standard for companies that weren't willing to spend the money for a proper conference phone, until the Polycom SPIP550 came out.

# ¿ Mar 6, 2017 16:02

wolrah: May 8, 2006; what?

Thanks Ants posted:

The Trio 8800 runs Android, that's about it as far as I know.

Ah, yea that definitely is Android underneath based on the screenshots, no way they accidentally copied Google's look and feel that well.

# ¿ Mar 6, 2017 22:31

wolrah: May 8, 2006; what?

Most of the successful attacks I've seen on my customers have tried to pass international calls through our system. One of the times where my boss redirected the calls to his phone it turned out to be some calling card thing. The attackers had hacked some west coast dentist's PBX fully and were routing calls through one of his unused numbers out a trunk they had pointed at my customer's insecure system, where they were then having it dial a number in some Pacific island country I don't recall where they could then dial through to their actual destination.

Our best guess is it was a fully automated attack, because our system plays an audio error message rather than just rejecting the call so it would have looked like the international call succeeded.

# ¿ Mar 7, 2017 23:34

wolrah: May 8, 2006; what?

Ur Getting Fatter posted:

I know it's not at the same scale as you guys, and also I imagine US IPs get hit more often, but switching to a non-default port (ie: not 5060) basically drove down bruteforcing attempts on my PBX down to 0.

If it's a small operation I'd definitely recommend that + strong passwords + fail2ban.

So much this. Almost every SIP device or client supports SRV records and most of them are autoconfigured from templates anyways, so using a nonstandard port is nearly painless compared to how annoying it can be with most other protocols.

My Asterisk systems are mostly listening on port 5060 and we've had days where the fail2ban logs grew so fast we had disk space alerts getting issued (they were set to 24 hour rotation rather than size-based rotation). My new Freeswitch deployment does listen on 5060, but only to a whitelisted set of IP addresses that basically come down to trunk providers where it's easier to just whitelist their IP than to get them to use a different port. The only port exposed to the public is not used for any common services and in the month the system's been online we haven't seen a single attack.

# ¿ Mar 15, 2017 17:12

wolrah: May 8, 2006; what?

sip2ncid appears to be entirely passive, as in it doesn't register with the system itself but it sniffs the traffic as it passes by headed to your actual VoIP device.

This means it needs to be running somewhere that can actually see the traffic destined for the phone, and on a switched network that's not very many places.

The easiest solution would be to run it on the router, but that only works if you're using something like OpenWRT or pfSense where running random *nix applications is an option. If you can't do that, the next best choice would be a managed switch with a "span" or mirror port option to copy the traffic on the phone's port over to the port where your sniffer lives. If you can't do that, some phones like Yealinks have an option to mirror their call traffic out their PC ports, but that definitely won't apply to a SPA-series ATA. That leaves you with the ghetto span port, an ethernet hub. Not a switch, but an actual hub.

Another potential option if you can do it would be to set up an additional extension that rings simultaneously with the one you care about, then statically map that to send traffic at the sip2ncid box.

edit: I guess you can use ettercap too, but I would not consider anything that depended on that a proper long-term solution. It's a very useful tool in security analysis but not really for this. You're adding an additional hop that's not necessarily stable to your VoIP calls as well.

wolrah fucked around with this message at 20:56 on Mar 18, 2017

# ¿ Mar 18, 2017 20:53

wolrah: May 8, 2006; what?

So, if any of you use VoIP Innovations you may want to sanity check your CDRs with them and what they've billed you for this year.

code:

wolrah@titan:~$ cat 2016-09-compiled.cdr | sort | uniq -D | wc -l
0
wolrah@titan:~$ cat 2016-10-compiled.cdr | sort | uniq -D | wc -l
0
wolrah@titan:~$ cat 2016-11-compiled.cdr | sort | uniq -D | wc -l
0
wolrah@titan:~$ cat 2016-12-compiled.cdr | sort | uniq -D | wc -l
0
wolrah@titan:~$ cat 201701-compiled.CDR | sort | uniq -D | wc -l
2246
wolrah@titan:~$ cat 201702-compiled.CDR | sort | uniq -D | wc -l
6956
wolrah@titan:~$ cat 201703-compiled.CDR | sort | uniq -D | wc -l
32395

CDRs generally shouldn't have duplicate lines...

# ¿ Apr 7, 2017 23:54

wolrah: May 8, 2006; what?

MrBond posted:

Any consumer VOIP providers worth recommending? My parents have some super cheap one that's been steadily getting worse, so they're looking to jump ship.

Consumer VoIP is a tricky business. lovely internet connections and random garbage modem/router combo devices provided by the ISP, plus whatever silly poo poo the person has added to their network themselves, make for a high support load compared to the prices you can charge while still being competitive.

You can get good service for cheap but you'll be pretty much on your own for support, or you can get support but the company's going to be cutting corners elsewhere to afford it. There will also be problems that the provider can not solve and are between you and the ISP.

ISP-provided VoIP services are the exception here obviously, because they control the last mile and theoretically the entire path between the box at your house and their PSTN connections.

I'd recommend sticking to those sorts of things if you want home VoIP service as a primary line for non-technical users.

# ¿ Apr 12, 2017 20:12

wolrah: May 8, 2006; what?

Hahahaha....

They decided to use an infrared proximity sensor as the hook switch.

As if the fact that they get it wrong so regularly on cell phones wasn't enough of a hint that maybe these sensors shouldn't be used to replace a long-standing simple mechanical switch.

The justification they give is sanitary reasons, presumably junk ending up in the switch slot. A magnetic switch would allow a slotless design without this problem.

# ¿ May 24, 2017 22:27

wolrah: May 8, 2006; what?

Beefstorm posted:

Has anyone tried the Ubiquiti phones? Thoughts?

CrazyLittle posted:

I have one of each UVP-Pro and UVP-Executive. I am not impressed. Touch screens without any tactile feedback suck rear end for dialing phone numbers. Basic phone features you'd expect on face-buttons (hold, transfer) for an enterprise phone system or PBX are missing from the UVP's dialer app.* Audio volume was abnormally low but they say that's since been fixed through software updates.

But you can play Angry Birds and Youtube.

*- the shortcomings of an android-tablet-as-desk-phone also applies to the Meraki desk phones, which I played around with for a month before shipping back to Meraki.

I have had a base UVP since launch and I agree entirely with this assessment. The software sucked rear end upon release, now it sucks less but still isn't amazing. The config file format is terrible, though at least it exists now (at launch you could only configure it through Ubiquiti's controller software). Touch screens in desktop applications will always be horrible, it needs physical buttons. Of course the Android OS is out of date and it's running on hardware roughly in the same class as a 2010 smartphone.

Unless you have a really good reason to put Android apps on your VoIP phone I'd recommend avoiding anything of the sort. I haven't used the Grandstream or Yealink options yet but on paper they look to be pretty much the same sort of mess.

Super Slash posted:

- Install business grade routers, questionable if ISPs are compatible

This is what we do. Our system is very NAT-friendly and will generally work with whatever they have, but we consider that "Best Effort" level service and warn them that we will neither guarantee quality nor security. Many lovely NAT implementations open UDP pinholes for all sources and will happily allow in all the probes that find their way to port 5060, resulting in a lot of annoying phantom rings for home users with said lovely NATs.

If they want full business grade support, they put in a router we support and give us access to it. At this point we officially support pfSense and Edgewater Networks with unofficial support for OpenWRT. I keep meaning to buy some Ubiquiti routers and test them out. Our critical feature is the ability to stream packet captures live in to Wireshark. I can generally get that working on anything that sits on top of a *nix, which fortunately is most of this segment of the market. If a device offers that and does decent QoS we'll generally try to support it.

wolrah fucked around with this message at 23:58 on May 25, 2017

# ¿ May 25, 2017 23:55

Adbot: ADBOT LOVES YOU

# ¿ Apr 30, 2024 20:11

wolrah: May 8, 2006; what?

Thanks Ants posted:

Also Ubiquiti have given up on them. I think you'd have to be slightly crazy to put a bunch of devices on your network running outdated versions of Android.

Ubiquiti hasn't given up on them, they received a software update as recently as January. They are unfortunately as out of date as most other Android-powered appliances though. I don't believe the Grandstream or Yealink options are much better, I think those are both on Android 5.x.

I agree you'd have to be crazy to put them in to production though for many reasons.

# ¿ May 29, 2017 23:09

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > VOIP - fuck you it's 2016 just call me on my cellphone