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.
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.
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?
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].
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.
> 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.
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.
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"?
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.
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.
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).
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?
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 :)
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.
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.
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.
[+] [-] tracerbulletx|2 years ago|reply
[+] [-] robertlagrant|2 years ago|reply
[+] [-] guru4consulting|2 years ago|reply
[+] [-] fellowniusmonk|2 years ago|reply
[+] [-] Sean-Der|2 years ago|reply
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|2 years ago|reply
This is really interesting! Any latency benchmarks comparing it to gstreamer UDP, P2P primarily?
[+] [-] LoveMortuus|2 years ago|reply
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'.
[+] [-] j1elo|2 years ago|reply
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-Der|2 years ago|reply
This code was the prototype/how I learned SIP+WebRTC.
[+] [-] wakamoleguy|2 years ago|reply
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-Der|2 years ago|reply
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.
[+] [-] abalashov|2 years ago|reply
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-Der|2 years ago|reply
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"?
[+] [-] hamdouni|2 years ago|reply
[+] [-] Sean-Der|2 years ago|reply
[+] [-] codetrotter|2 years ago|reply
[+] [-] Sean-Der|2 years ago|reply
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.
[+] [-] flynumber|2 years ago|reply
[+] [-] aftbit|2 years ago|reply
[+] [-] Sean-Der|2 years ago|reply
``` 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 :)
[+] [-] ianburrell|2 years ago|reply
Or could add the logic from mobile browsers to recognize phone numbers and make them into links.
[+] [-] Uptrenda|2 years ago|reply
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|2 years ago|reply
[+] [-] cassepipe|2 years ago|reply