20 Years of SIP – A Retrospective | Hacker News Reader

20 Years of SIP – A Retrospective

jdrosen.net

89 pointspsim157 comments

On the other hand, there are now many proprietary voice/video communications platforms NOT based on SIP, with some of them adding SIP support only as an afterthought/additional-cost feature. I don't think the authors of SIP envisioned this, and it's unfortunate. It was intended to be as widespread as email, with a similar diversity of implementations of varying interoperability.

It would have required much forethought to predict, in 2002, that realtime communications would be happening in the browser. Thus WebRTC was born. But a tragedy of WebRTC is that it is not by-default compatible with SIP. WebRTC authors could have specified SIP as the signaling protocol over websocket, but they left the spec open ended. I feel two ways about this: glad for choice, but disappointed that the choice most often made does not allow for interop with the "legacy" realtime communications protocol, SIP.

There are libraries to do SIP signaling over WS/WSS with WebRTC from a browser (or whatever) that theoretically allow for interop with other SIP devices.

In practice the fundamentals of WebRTC rely on things like ICE, STUN, and TURN for media so they're not going to be compatible with almost all existing SIP implementations - many of which can't even do interop with bog-standard vanilla SIP over UDP with standard codecs properly.

As is often the case with SIP you're back to using some Session Border Controller or equivalent architectural component to make interop actually work reliably.

It is a shame. I don't see any easy answer. I am working on sfu-to-sfu[0] and hope it can make some traction. If we can get all the Open Source WebRTC servers working together, maybe there is hope? I believe WebRTC did the right thing. It was as flexible as possible to make it more palatable. You can standardized/codify things, but you can't undo it :)

I am also really excited about WHIP[1]

[0] https://github.com/matrix-org/sfu-to-sfu

[1] https://datatracker.ietf.org/doc/draft-ietf-wish-whip/

I think issue with SIP is that it is and was driven by the industry. And I wouldn't call it exactly simple or easy protocol to follow and implemented. Thus many alternatives or self-made solutions are more likely to be chosen. It does a lot, but at the same time it is increasingly complex protocol. At least compared to others.

Why is industry-driven an issue? And compared to what others? On the contrary, SIP is as readable and understandable as HTTP. Someone who understands HTTP can learn SIP-based VoIP quite easily using their software/web background without needing a telecoms background.

To me the fundamental issue with SIP is the recognition by vendors that a standard protocol is "here" while still being incentivized (of course) to implement vendor lock-in. It was also clear that SIP for trunking (with very basic call setup/teardown) was the path forward to replace PRI, POTS, etc.

Consider government, large corp, etc purchase requirements. "Oh SIP is the standard. Cisco do you support SIP?" Cisco says "Of course!". Check the box and buy.

Meanwhile at the time their ecosystem is 99% Skinny (their proprietary protocol) and SIP is an afterthought for anything other than extremely basic call functionality, trunking, etc. Even when pushed to release SIP firmware for their (at the time) $500 hardware phones the SIP firmware was so feature crippled you're literally throwing money away by using it.

So everyone installs Call Manager to be done with it and have something that actually works. Even when Cisco got around to essentially being SIP native getting 30 year old features like hold, transfer, busy lamp fields, provisioning, etc working between vendors was nearly impossible.

Repeat for just about every implementation in existence.

I do believe that Cisco SIP implementation in 7000 series phones is non-interoperable by design. One major issue is that they are sending SIP messages from different port than the port they are receiving on. Because of this they practically do not work with any kind of NAT and I haven't heard of any consumer service provider that would work with this (the standard behavior is to assume that port passed in Contact line might be incorrect). Some of phones from that line have "NAT" true/false setting, but some don't - when tracing changelog I saw that this setting was removed in later firmware version, but for many phones this earlier firmware version was never available.

To the extent SIP was industry driven, it was due to the fuzzy standards themselves which left a lot of room for vendor specific handling especially used to max out their own device to device performance often supported by proprietary enhancements. The biggest trade show was called Interop for a reason. At this point SIP might have served its purpose, but the basic approach of separating a control signaling plane from media paths has stood the test of time.

I'd love in SIP was more normalized for most people, so you just bought a data sim (and mostly used wifi) and didn't have to port a number around. I guess wireless market is so competitive the carriers really want to avoid this.

Absolutely, I remember owning a nokia n85 12 years ago which had native SIP support. I wish ios and android had this.

Early Android had it - wouldn't be surprised if it still exists now but has been hidden from the UI. For VoWiFI/VoLTE it's already using SIP anyway so there definitely is a SIP client.

The only reason you're not given access to it is because carriers are doing their best to protect their obsolete business model, and despite the appearances, Apple is fully complicit as well.

> Early Android had it - wouldn't be surprised if it still exists now but has been hidden from the UI.

It's buried in the settings for the Phone app (the dialer) and AFAIK is often removed from OEM ROMs because of course it is.

As a VoIP engineer, it's a terrible soft client. It works, barely, and has basically no features beyond bare minimum calling. I've tried to use it repeatedly over the years but always ended up on commercial softphones like Bria or GS Wave.

SIP was actually removed from the ASOP dialer very recently. It was removed in Android 12 (released late 2021). The support was never great (it would reset to defaulting to SIM calls every reboot) but it worked and was reliable.

SIP is the basis for VoLTE and VoNR. So in some sense iOS and Android still support SIP.

Although Google stopped supporting the OS integrated SIP client and eventually removed it, 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.

I remember these phones had some interoperability issue: https://answers.microsoft.com/en-us/mobiledevices/forum/all/... (technically all according to specification, but often not working for incoming calls). At the time Symbian was supported by pjsip though.

In the US market average customers can barely handle SIMs. Letting customers handle their SIP credentials would amplify number hijacking and customer side telecom fraud.

I don't see any cases where customers are misusing SIMs that would expose them to fraud at a large-scale. What I see instead is customer service being staffed by monkeys that are too stupid to realize they're being social-engineered, don't care or are outright complicit in the fraud.

Having worked in customer service decades ago, I wouldn't call them stupid monkeys. Designing your 2F authentication around SIM-based telcom is perhaps more appropriate to obtain the title of "stupid".

I'm sure there are good ones in the mix but that doesn't match my experience with any mainstream consumer-grade carrier or ISP. It doesn't have to be that way but obviously until carriers are held accountable and/or their oligopoly is broken they have no incentive to improve things.

While it's true that SMS 2FA is flawed, that still isn't an excuse for letting customers' phone numbers being taken over by very unsophisticated attacks, sometimes even if notes are added to the account (or a PIN) that explicitly warn against such attacks.

Also, I'm not sure how much of "decades ago" is hyperbole but back in the day ISP/telco support was a great career path and would allow you to learn and move up the ranks towards a more technical position. Nowadays "support" in any customer-grade ISP/telco is a dead-end position that's there to be exploited as much as possible (in fact it's often outsourced to a boiler room abroad, probably right next to the tech-support scammers) and replaced by a new sucker as soon as you burn out. Obviously this kind of treatment doesn't attract the right talent nor inspire goodwill in said talent.

Customer side as in whoever controls the SIM/credentials/handset. It would also need an inordinate amount of support. Customers are used to SIMs being preinstalled. Just imagine customers forgetting their SIP password or being phished for them. Or using Password1!

It's been well over a decade since I've ported my number, but even way back then it was a fairly simple and straightforward process. I doubt it's gotten more complex since then.

At least in Canada, the process is simple but still not instantaneous, unless you are porting between the big incumbent carriers (Rogers, Bell, Telus, and their subsidiaries—often referred to as Robelus).

I ported my number out to VoIP.ms, and it included a four day waiting period... for no particular reason except to probably allow for some human to check a box.

SIP has been an amazing standard that untethered me from the triopoly of cellular providers in Canada.

For the cost of a data-only SIM ($15/mo), I can call, text, and surf. I only need to be wary of the 3gb cap.

For those in EU/Asia, can you believe that here, that is considered an amazing deal? It's still unfathomable outside of North America, but imagine that everybody else pays at least 4-5x more than I do.

One sad thing about SIP that despite being pretty common here in Czechia, it is only used as a last hop to PSTN instead of as an independent federated network.

It makes economic sense - it is hard to monetize running SIP servers for independent network (and one cannot use ads like with e-mail as SIP clients are not web apps), but you can monetize selling access to PSTN.

Today, with WebRTC, one can build web client for SIP, but WebRTC VoIP services are still just silos.

and one cannot use ads like with e-mail as SIP clients are not web apps

Don't broadcast radio and TV have ads too, despite being independent of any client implementation?

(I hate ads as much as anyone, but it's possible to run pre/inter-call ads on a free call too.)

Happy SIP user for nearly twenty years, which allows me to bridge three countries. Currently using baresip [1] and finding it to be remarkably reliable, but is there any hardware phone out there that I can put on my desk? Or is the sane thing to do to get a handset and hook it up to a computer via say USB? I have tried at least twice over the years to gain some clarity on these questions, but maybe I am using the wrong search terms?

[1]: https://github.com/baresip/baresip

If I understand what you're asking, I use an Obihai VoIP adapter so I can use any old phone, but there are also a variety of IP phones from Cisco, Obihai, etc.

Most business-grade desk phones support SIP.

This is true. I will give the caveat, though, that some of these are vendor-locked. Meaning: you can't easily use them with 3rd party SIP providers.

So, just be aware of this and do your homework on specific brands/models before purchasing to ensure you'll get something that will work for you.

There are tons of SIP-compatible phones out there. If all you need is access to a single SIP account, the Grandstream GXP1610 is very inexpensive (~$40 US) and will do the trick. They also have more expensive models that support SIP accounts.

Polycom phones are really great... I deployed VOIP for my employer some years ago and put in about 40 Polycom devices in 4 states. They're not cheap, but full featured and very well made.

You could also get an ATA (https://www.amazon.com/Grandstream-HT801-Single-Port-Telepho...) and plug a traditional phone into it. I used one of these at home for a long time. Just realized it's still plugged in an running and I threw out my last analog phone over a year ago!!!

And ATA's are an excellent backdoor into computer networks because the caller ID uses an old dialup modem protocol...

A big thank you to everyone responding with information, apologies for responding only here. It looks like there is indeed still a lot for me to learn, but now I have some pointers. I have been meaning to get my hands dirty with SIP for some time, dreaming of a setup with multiple accounts and control over things like when each account allows incoming calls, etc. But, as Terry_Roll indicated, there seems to be plenty of security considerations as well which makes me somewhat uncomfortable.

Also found the /r/VOIP subreddit [1] which has plenty of reading.

[1]: https://teddit.net/r/VOIP

Could you elaborate? What's the attack vector here?

You have a device that is capable of handling the caller ID standard which passes data using the v23 dial up protocol. https://en.wikipedia.org/wiki/Caller_ID#Regional_differences

Can you remotely update firmware on modems?

Some devices can be updated remotely as these helpful guides explain. https://www.draytek.co.uk/support/guides/fw-remote https://www.ewon.biz/technical-support/pages/firmware/modem-...

So can a specially crafted string from the phone line be used to update firmware on ATA's? If they can handle v23 protocols for Caller ID, this indicates some modem capabilities does it not? So can the device differentiate which interfaces the commands are coming in on?

Why do people implicitly trust the telco's? Here in the UK, if you can get fast broadband, basically anything above ADSL2+, you'll be connected to a Broadcom cabinet. Broadcom have their bugs as well, you can find them on their website, but its a less common attack vector because its not public facing as such, unlike calling a business on their freephone number and then getting a second dial tone like in the old days of phone phreaking.

TLDR is just look at these devices as circuit boards, convention can be used to hide attack vectors and whilst the circuit design can help make a device secure, the easier or more convenient it is to update a device, the easier it is to hack, its not like taking a EEPROM out to blank under UV light and re flash it, is it?

V.23 FSK is just the name of modulation. You can have CLIP receiver as separate IC (https://www.microsemi.com/product-directory/caller-id/4305-m...) or as some DFT code with Goertzel algorithm with maybe 0.1 MIPS DSP budget allowed. No sane person would add full modem capabilities to this.

That said, PABXs I worked with have built-in software modems (both POTS and ISDN, needs to be explicitely enabled) with remote management capability and there is also dedicated web portal for management even if device is behind NAT (paid feature). Whether you want to trust hardware/software you have no control of - that's another story. For "big" PABXs partnership between manufacturer and installers usually lasts for years.

If you dont care about warranty you can pick up cisco voip phones dirt cheap on ebay.

A cisco 7940 is rock solid and go for around 10 dollars, the only caveat is you will need a poe switch for 48 volt power and a custom cable as they use nonstandard voltage pinout.

The other caveat is that time spent configuring, troubleshooting and later maintaining them would be worth much more than 10 dollars. Their use is discouraged by many SIP providers (https://teamhelp.sipgate.co.uk/hc/en-gb/articles/204210961-C...) and they have multiple issues not obvious at first glance, like limited character set for Display Name. This might be worth though for 100+ phones in a single location.

There are some USB "phones" - basically composite USB devices with audio and HID, where HID is used to handle keypad and display (if present). I'm using very cheap EX-03 "Skype" phone: https://tomeko.net/software/SIPclient/EX03.php but similar devices are also made by big brands, they are just more expensive (Polycom CX300, Plantronics Calisto, Yealink MP50 maybe?) and probably undocumented.

The number of publicly-accessible SIP services has decreased significantly over the past few years:

https://imgur.com/a/tqXclNi

Well, consumer SIP is mostly dead. 20 years ago mobile calls were quite expensive, now they are basically free. Also the marked matured, people are more educated in general and using default port was never a good idea.

Can anyone recommend a good quality US-based SIP provider? (twilio is OK, but I need to connect physical Cisco phones)

I'd like to port my phone numbers from google, as I'm afraid the migration of the free domain may cost me my phone number in case of shenanigans (like google voice being considered separate of google mail etc)

twilio has a few competitors--telnyx, bandwidth, plivo, vonage just name a few that you can port a number to for SIP.

I've been happy with Anveo for years now.

10-year business customer of https://voip.ms/ here. I have nothing but great things to say about their service itself, its reliability, and their support. It's also very inexpensive for what you get.

Technically, voip.ms is CA based, not US based. But they've got a lot of US infrastructure.

You’re absolutely right. Thanks for the correction!

Callcentric provides a bunch of features for a great price. I ported over my two landlines over 10 years ago and love it. When my mom moved to a new state, I ported her number first so she could keep that number in her new place.

If you're actively managing a large number of users and devices, I had great luck with OnSIP. They're not the cheapest game in town, but their management interface is top notch. They were always innovating and the architecture they disclosed was impressive; very focused on HA and performance.

I've had success with anveo.com, using softphone zoiper.

I hate to be that guy, but if you don't mind being a Linux sysadmin you might consider running your own Asterisk server. I do that for my SMB with about a dozen physical sets, and use Twilio for SIP trunking.

I followed the first 10 chapters or so of the O'Reilly Asterisk book making a few changes here and there to suit my preferences (different Linux flavor, different DB). I run a $10/month Digital Ocean droplet that hosts the Asterisk server. If you can deal with config files, you can have a rock-solid PBX with Enterprise-grade features for the cost of the server + Twilio's SIP trunking features. It ends up costing about $25 every 1.5 months or so. I barely ever think about it, except when I need to tweak a greeting for holiday hours or something.

Asterisk is a huge pile of C code with lots of legacy crap. I wouldn't trust having it exposed to the Internet.

Linux kernel, apache, nginx, redis... better get off the internet.

FYI Twilio has a few guides on how to connect their SIP trunking product to Cisco SBCs:

CUCM: https://twilio-cms-prod.s3.amazonaws.com/documents/InteropGu...

ISR: https://www.twilio.com/docs/sip-trunking/sample-configuratio...

They also have a porting process you can use to migrate your numbers from GV/Bandwidth (or you can just buy a Twilio number for $1).

Very interesting, thanks a lot!

I run an asterisk server trunking out to the outside world via a unitel trunk and I am pretty happy with the setup. unitel has so far provided a no nonsense straight forward service(it is ~ 3 dollars a month for regulatory fees and fractional cents per minute for calls), I just needed to figure out how to set up asterisk(and I enjoy that sort of thing)

https://www.unitelvoice.com/sip-trunking

Reply on news.ycombinator.com