Show HN: Bring phone calls into the browser (SIP-to-WebRTC)

https://github.com/pion/example-webrtc-applications/tree/master/sip-to-webrtc

by Sean-Der • 3 years ago

154 56 3 years ago

github.com

hamdouni2• 3 years ago

That is nice. I already use pion for video call in browser. That's an interesting add'on.

Sean-Der12• 3 years ago

Cool! What did you build?

hamdouni2• 3 years ago

A permanent video call for my remote team... No login, no option, just an url to a vm.

codetrotter2• 3 years ago

For a moment I was thinking that perhaps this could be the foundation for something to replace Google Voice for some people. Unfortunately I am not sure that most SIP telephone numbers will be usable for things like account verification.

Sean-Der12• 3 years ago

Why not?

If I get a number via Twillio/$X is the receiver of the call able to tell? I haven't spent a lot of time with SIP and POTS stuff. All my time has been WebRTC and got into SIP for work.

smcf• 3 years ago

Yes, there are many APIs available to look up the carrier that services a phone number. You can sort these carriers into categories (landline, mobile, VOIP...) and many services won't accept the number for SMS OTP use if the carrier isn't a "real" mobile carrier, in a somewhat hamfisted effort to prevent fraud.

codetrotter2• 3 years ago

My impression is that SIP providers are usually not regular telephony companies. So by looking at who the provider is, it is often possible to determine that it is a SIP number and not a regular number. Which in turn might lead to the phone number you are paying for not being usable for account activation. Because websites will think that you are a spammer.

NavinF• 3 years ago

is the receiver of the call able to tell?

Unfortunately, yes. After I ported my number from at&t to google voice, a lot of services refused to accept it. Requiring SMS 2FA with an non-VOIP number seems to be a common anti-spam measure these days. It's often required for new accounts

Mountain_Skies• 3 years ago

I've encountered several services that demand a mobile number for verification. Google Voice numbers are rejected and surprisingly, so are landline numbers. Only numbers for mobile are accepted. It's just another case of how the tech world has outsources identity verification to the mobile telecom companies.

flynumber• 3 years ago

It's really up in the air as far as VoIP/SIP and phone numbers. We have certain "mobile" version(outside US/CA) DID numbers that seem to work well with oAuth SMS. (OpenAI uses them among others).

Sean-Der12• 3 years ago

Really exciting times for WebRTC in general right now!

If you are new to WebRTC and want to learn more about the protocol check out [0] (would love peoples feedback). It is used in lots of unexpected places like streaming (added to OBS)[1] and Embedded [2].

I am especially excited with new implementations popping up like [3] and [4].

[0] http://webrtcforthecurious.com

[1] https://github.com/Glimesh/broadcast-box

[2] https://github.com/sepfy/libpeer

[3] https://github.com/algesten/str0m

[4] https://github.com/elixir-webrtc/ex_webrtc

tamimio3• 3 years ago

[1] https://github.com/Glimesh/broadcast-box

This is really interesting! Any latency benchmarks comparing it to gstreamer UDP, P2P primarily?

Sean-Der12• 3 years ago

I don't! But when adding WebRTC support to OBS I would see 120ms https://github.com/obsproject/obs-studio/pull/7926

This is me (Ohio) going to a Digital Ocean Droplet (NY) and back.

LoveMortuus• 3 years ago

When an Invite has been accepted you will a log message like this.

In the 'Make your phone call' part of the readme, I think you might be missing the word 'see' between 'you will' and 'a log'.

Sean-Der12• 3 years ago

Fixed! Thank you :)

tracerbulletx• 3 years ago

In 2015 I wrote a whole Contact Management app for a business that let their entire sales team of like 50 reps pick up phone calls from the browser or from their desk phone using Twilios SIP trunk service. It was pretty cool, it routed the calls to both our internal Asterisk server, and worked flawlessly with Twilios WebRTC libraries in the web app. It was really cool and surprisingly easy, also all of the call recordings instantly became available in the web app and they could initiate calls from their call calendar in the app.

robertlagrant2• 3 years ago

I really like Twilio's APIs and how simple they make stuff like this. You can clone a repo of theirs and get a video call in your browser / on your phone in about 5 minutes. So smart.

Sean-Der12• 3 years ago

Twilio is shutting down those APIs :(

It's a shame. Lots of people built their first things/got introduced to WebRTC via it.

guru4consulting• 3 years ago

I want to embed phone calls (and store the conversation details) within my custom webapp which is a light CRM. Is there any simpler SaaS plugin for that? or perhaps just Twilio API is good enough?

fellowniusmonk• 3 years ago

In 2015 web browsers/chrome didn't have QoS tagging, how did you get around that?

aftbit• 3 years ago

Does anyone have any ideas on doing the opposite, using something like Asterisk to dial into WebRTC meetings or interact with WebRTC speech recognition services?

Sean-Der12• 3 years ago

Would it make sense to run a bridge for Asterisk to call into? Most WebRTC services will have proprietary signaling, so you will have to write some signaling code.

``` Asterisk -> Bridge -> WebRTC Service ```

You could do it all in Asterisk you will just have to write a fair amount of C code! It's been years since I have done that though. Reach out on https://pion.ly/slack and would love to help :)

mc_2• 3 years ago

I know FreeSWITCH and Kamailio both have WebRTC connections available, so if you use a SIP client in the browser over WebRTC to the server, you can plug into telephony networks on the server side.

We use Kamailio's WebRTC implementation heavily in Kazoo along with our libwebphone client. The transport is abstracted so Kazoo deals with the device and its configs; the Kamailio instance the browser connects to does the TLS termination for WebRTC. FreeSWITCH has the smarts for the SDP DTLS bits. And it all just works real nice together.

wakamoleguy• 3 years ago

This is using sipgo as a back-to-back user agent (B2BUA). There are really two sessions going on: one between the SIP caller and sipgo, and a second between sipgo and the browser. These sessions each have their own signaling and media.

The interesting part is how the signalling is happening between the sipgo server and the browser. You copy your session description from the browser and paste it to the server! In a "real" application, you could send it over a custom API call or something, or you could use a standard protocol for initiating sessions (SIP!).

This is all to say, "bridging" between SIP and WebRTC is not nearly as magical as it is often made out to be. In some cases, the media can even be passed through without modification. (Although many SIP endpoints do not support e2ee and so a B2BUA is still needed to wrap/unwrap the encryption.) We were doing this a decade ago with SIP.js and OverSIP.

Sean-Der12• 3 years ago

This is all to say, "bridging" between SIP and WebRTC is not nearly as magical as it is often made out to be

100% agree. That is what I have been trying to solve with Pion/WebRTC for the Curious. It is portrayed as being harder then it is. Why people do that I don't know. It causes lots of problems though.

* Developers are hesitant to get into WebRTC/VoIP because they think they couldn't figure it out

* Companies are pushing proprietary alternatives and saying 'existing protocols are impossible to use'

I am sure that some wonderful ideas never got built because the education/community just wasn't welcoming enough.

j1elo2• 3 years ago

Hi Sean! I'm guessing this is derives as part of the recent collaboration with LiveKit to add SIP support, right?

I had been looking at https://github.com/livekit/sip the other day, so it hasn't been much of a surprise to now see this here. Cool integration!

Sean-Der12• 3 years ago

Yep! I work at LiveKit full time now. https://github.com/dennwc and I wrote livekit/sip.

This code was the prototype/how I learned SIP+WebRTC.

j1elo2• 3 years ago

Congrats! That I guess is great news for the future continued development of Pion. Also are there big plans for the v4 of pion/webrtc?

cassepipe• 3 years ago

Anyone remembers Firefox Hello ?

abalashov2• 3 years ago

As others have pointed out, this has been a very mainstream, and largely turn-key use of Kamailio, FreeSWITCH, etc. for over a decade.

I am closely involved with Kamailio, and I believe its websocket module, meant to effectuate this functionality, was introduced somewhere in the 2011-13 time frame.

While of course the ecosystem can always stand to be richer, there's nothing new here.

Side note: "WebRTC to SIP" isn't an especially intelligible formulation, as WebRTC does not prescribe a signaling protocol. SIP can be used on the browser side, and often is (for interoperability benefits both real and imagined), but needn't be necessarily.

Sean-Der12• 3 years ago

Pion's approach to the problem is different to the software you have described.

Instead of configuring a server you are given primitives (SIP and WebRTC in this case). I find this powerful when trying to implement use cases that go off the beaten path. I think a lot of the RTC software of this generation is a reaction to that.

----

"WebRTC to SIP" isn't an especially intelligible formulation

This is the language I see most developers and customer use. What do you think a < 10 char name would be?

----

I don't think this attitude is healthy for the space. If I was a new developer looking at different spaces this would make me not want to be in VoIP/RTC. The goal of my example was to get people excited and try to make WebRTC and SIP more accessible. What did you hope to accomplish with saying "others having been doing this for a decade" and "isn't an especially intelligible formulation"?

kelnos2• 3 years ago

What did you hope to accomplish with saying "others having been doing this for a decade"

The charitable interpretation is that the point is to let people know that there are several ways to do something similar, and there are off-the-shelf modules that can be used to accomplish it, if you don't want to use a browser. (The less charitable, but understandable interpretation probably runs along the lines of, "we've been doing this for a decade and it's frustrating that we haven't gotten enough recognition for it, to the point that the subject of this HN post seems to be striking people as quite unlike anything others have done before".)

and "isn't an especially intelligible formulation"?

I think that's just typical nerd pedantry. As someone who has worked in this space (I co-built the WebRTC bits of Twilio's browser voice product back in 2012, including building a server-side implementation of WebRTC when none existed [at least not in a form we could use], and bridged that to our internal SIP-based voice infrastructure), I'm vaguely sympathetic to the desire for precision. It is correct to say that you can't bridge "WebRTC" to "SIP"; as I'm sure you know after the work you've done, WebRTC is a RTP-based media stack mated with STUN/TURN that happens to use SDP to describe voice/video sessions, while SIP is a signaling protocol that doesn't really specify anything about media.

I'm not sure I'd agree that most developers and customers use the language you assert, but admittedly I've been out of that space for a good 7 years at this point. Regardless, I think it's valuable to understand -- for perhaps the hypothetical someone new coming into the space that you bring up -- what WebRTC and SIP actually are, and that you can even use SIP to set up WebRTC sessions without any sort of bridging to other infrastructure.

Uptrenda• 3 years ago

I work on software for p2p networking and I'm always researching strange things because of it. One thing that I've discovered is that SIP has a mechanism to relay a single message to a single IP. I know this might not sound like much but I think that theoretically it might offer a way to reach nodes behind symmetric NATs (which is the most restrictive type of NAT.) The idea is that you would have a list of N SIP servers who you send packets to on sip_ip:sip_port. This creates a stateful rule allowing back packets for the server in the router.

Now anyone is able to use that SIP server to relay messages to you so long as you listen on the right ports. This could be useful for highly restrictive NATs like symmetric NATs that only reuse external mappings if an inbound connection uses the same IP and port (more applicable for UDP.) If you can get one, just ONE message to a peer then you can use it to exchange information on strategies to connect directly to them. E.g. TCP hole punching.

There are a metric crap load of SIP servers out there and any one of them would effectively enable you to exchange information with a symmetric NAT and certain firewalls. I think I did basic tests for this ages ago between multiple Internet connections and it seemed to work. So I think this has potential in p2p networking and decentralized apps.

jimmySixDOF• 3 years ago

Session Border Controllers started out as a way to solve inerop between complex NAT environments and normalize SIP implementations which can and do vary widely across roll-your own Asterisk to vendor B's softswitch so just a friendly word of caution if you are considering any feature out of the SIP "standards" then the more obscure it is then the more you need to be sure you own every part of the chain from the user agent on down.

ianburrell• 3 years ago

It would be nice if we could revive tel: links. It should be possible to have tel: URL handler that popups about how to make the call. Using smartphone would be good option. I was thinking about desktop, but this would be perfect.

Or could add the logic from mobile browsers to recognize phone numbers and make them into links.

Show HN: Bring phone calls into the browser (SIP-to-WebRTC)

Related Stories