[HN Gopher] Show HN: Bring phone calls into the browser (SIP-to-...
___________________________________________________________________
Show HN: Bring phone calls into the browser (SIP-to-WebRTC)
Author : Sean-Der
Score : 76 points
Date : 2024-01-04 17:22 UTC (5 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hamdouni wrote:
| That is nice. I already use pion for video call in browser.
| That's an interesting add'on.
| Sean-Der wrote:
| Cool! What did you build?
| codetrotter wrote:
| 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-Der wrote:
| 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 wrote:
| 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.
| dboreham wrote:
| As a counterexample I long ago ported my landline phone
| number to a SIP provider that supports SMS and due to the
| phone number being baked into various accounts the family
| has, I know it works for verification at least for those
| services (one of which is a bank).
| codetrotter wrote:
| 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.
| bobsmith432 wrote:
| Could you mask the provider, and a VoIP provider appear to
| be like "SimpleTalk Wireless" or something and fake being a
| mobile phone carrier?
| NavinF wrote:
| >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 wrote:
| 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.
| walterbell wrote:
| Companies that mandate use of another company offer a good
| reason to shun both companies, when there are independent
| competitors which prioritize customer relationships over
| "business partner" relationships.
|
| SMS is woefully insecure for multi-factor authentication,
| when we have TOTP and other open standards that work with
| local-only password managers.
| Sean-Der wrote:
| 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
| tamimio wrote:
| > [1] https://github.com/Glimesh/broadcast-box
|
| This is really interesting! Any latency benchmarks comparing it
| to gstreamer UDP, P2P primarily?
| tracerbulletx wrote:
| 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.
| robertlagrant wrote:
| 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.
| aftbit wrote:
| 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-Der wrote:
| 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 :)
| wakamoleguy wrote:
| 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.
| j1elo wrote:
| 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!
___________________________________________________________________
(page generated 2024-01-04 23:00 UTC)