Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
C++ implementation of SIP, ICE, TURN and related protocols (github.com/resiprocate)
72 points by mooreds 3 months ago | hide | past | favorite | 10 comments


Whenever discussions of IPv6 come up on HN, there are some folks who ask "What problem(s) does it solve?" and such. Well, one answer to that is it solves not having to deal with the tomfoolery / rigmarole of this.

Certainly hole punching [1] (via PCP, UPnP IGD) is still needed for P2P clients like home video games and consoles, but most home/CPE routers support that, and there's not much more infrastructure needed.

P.S. / N.B.: And just because you have a globally routable address on your home computer does not mean that the address is globally reachable: stateful firewalls (on D-Link, Asus, Linksys, Netgear, etc) are a thing.

[1] https://en.wikipedia.org/wiki/Hole_punching_(networking)


>just because you have a globally routable address on your home computer does not mean that the address is globally reachable

Those IPv6 addresses would need hole punching, the same as IPv4. IPv6 isn't simplifying this use case. It's more complexity than just IPv4.


> Those IPv6 addresses would need hole punching, the same as IPv4. IPv6 isn't simplifying this use case. It's more complexity than just IPv4.

Yes, IPv6 needs hole punching like IPv4.

But IPv4 needs hole punching and a whole bunch of extra crud. A whole bunch of crud can be thrown out the window if you have globally routable addresses on your machine.

> IPv6 isn't simplifying this use case. It's more complexity than just IPv4

Not needing ICE/TURN/etc seems like simplification to me.


Robust and mature SIP stacks which are still maintained are a rarity these days. I was pleasantly surprised recently to learn just how well this very mature library is being maintained. It seems like a great deal of effort has been invested to keep both the code and feature set relevant and up to date. Kudos to the maintainer.

Most other open source SIP stacks available either don't have the feature depth and breadth required for a serious SIP project: are only usable from a specific programming language, have been long abandoned, or have impermissive licenses.


> Most other open source SIP stacks available [...] are only usable from a specific programming language

Is that not the case for this library? It's written in C++, and didn't find any mention whatsoever about usage from other languages being an expected use case in the README. C++ can be used via FFI from other languages, but it's my understanding that it is difficult and error prone, unlike C which seems the perfect fit for multi-language libraries.


So one thing I've been idly thinking about would be nice would be to set up a SIP server for my domain so that people can call me using handle@domain

But when I looked into it very briefly it seemed most sip stuff is geared calling and receiving calls from phone numbers (which I'm completely uninterested in) and what I had in mind is surprisingly complicated to set up.

Would this project be suitable for my usecase?


SIP doesn't care about numbers/letters. The username is pretty much opaque. You don't need a bare SIP stack implementation to achieve what you want. A simple proxy like opensips https://opensips.org/ that redirects the invites to some POTS gateway will be enough. Or a full server like Asterisk if you want to tunnel the audio as well. You will still have to learn quite a bit about the protocol / how these things work.


Oh huh. In that case is there a protocol like what I'm looking for? Where if I give someone handle@domain, their client will connect to the server at domain and ask for handle and try to initiate a voice call?


That sounds like perfect match for XMPP / Jabber. You can set up a server on your domain (e.g. 'Prosody') and then two XMPP clients that support calls (e.g. 'Conversations' for android) will be able to initiate voice/video calls, just like in telegram/whatsapp/viber/etc. More over, XMPP works like an e-mail, so user1@xmpp.org can message/call user2@yourdomian.com (if you allow your server to federate with other servers). Setting it up is not very simple though, you'd also need to set up STUN/TURN properly for direct calls and file transfers.


SIP is the right protocol. I'm just saying you don't need a SIP library, but a SIP proxy/server. In a similar way that when you want to handle some web requests you want for example Apache and not LibHTTP.

OpenSIPS will do what you need. But configuring it requires a bit of reading. There's no easy way in the VoIP world unfortunately.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: