It sounds like you want to write a program that takes your microphone input and flings it across the net to your friends, while doing the converse for you? Sure, this is possible, but it will be a lot of work. The examples you listed are complex and their value lies mostly in their handling of the innumerable edge cases involved in this sort of thing.

You could start by finding a microphone capture library and sending it over a socket to a receiving client. Then look at tying in Net::SIP (and you'll probably want AnyEvent::SIP).

This will keep you busy for a while, it's not for nothing that VoIP is a big business

By the way, you don't need to even write any code for this! There are many FOSS packages like Jitsi and others that have already done all the hard work and you can self host them.

Pardon my ignorance, but it appears Jitsi is a link embedder, and I haven't grasped at all how embedding a link, or links (into what, exactly?), could help accomplish this. If there are some FOSS options, what, besides Jitsi, might you have been alluding to?

Blessings,

~Polyglot~

it appears Jitsi is a link embedder

It isn't clear at all how you came to that conclusion. Jitsi is a VoIP + IM solution.

If there are some FOSS options

There are loads of them. I would be using Asterisk for VoIP and probably Prosody for IM. If you are looking for a Perl answer then DJabberd is still available but (unfortunately) it has had no active development for a long time.

Update: although DJabberd hasn't seen a release in a decade there actually has been some more recent activity over on the github repo so it might not be quite such bad news on that front as it first appeared.

---

🦛

It would make for a clunky video conference system, but you could have each user open VLC to stream their own camera, and then open one VLC player for each user you wanted to see video from. So for 2 people, 2 copies of vlc, one outgoing and one incoming. Beware of feedback loops.

If that works, you could try scripting it into a more cohesive experience. As it happens, I'm the author of VideoLAN::LibVLC which would allow you to start multiple copies of libvlc from within a perl script. I designed that library for being able to dissect the individual video frames though, which won't be useful to you, but there might be enough API available to make a video conference app. There is also Vlc::Engine and VideoLan::Client.

This sounds intriguing. I have VLC, but no idea how to access its API with Perl. Is there something published about this, such as a how-to guide or other documentation for the API?

As you might imagine, video quality is not my first concern. I would even be content at this point with an audio-only connection, though I do think we should have sufficient bandwidth at the server for a couple of video streams. The internet in the LDC (Least Developed Country) is paid by bandwidth usage, so video costs considerably more than audio. I think it's about a dollar per gigabyte of usage--which adds up, especially on the local economy in which the average income is under $100 a month. Internet saturation is not high--with only about 20% of the population estimated to be online.

I've been attempting to install Jitsi but have run into some snags. I have yet to find any solution that will work with the older platforms.

Blessings,

~Polyglot~

"I've been attempting to install Jitsi but have run into some snags. I have yet to find any solution that will work with the older platforms."

I had problems until I started using the nightlies/unstable releases. After that it worked fine. I don't believe Jitsi will be performant on older platforms/hardware. As mentioned previously something with low hardware and bandwidth requirements like mumble sounds like a sensible solution.

I have VLC, but no idea how to access its API with Perl. Is there something published about this ...?

I have absolutely no experience with the VLC API, but my impression from NERDVANA's post was that the modules mentioned therein were designed to do just that. Good luck with a how-to guide, though.

---

Give a man a fish:  <%-{-{-{-<

I have not ever used or developed VOIP software, but I will try to help you get passed the initial obstacles of starting your project with general advice.

As others said, there are numerous open-source packages for what you want to do. Start with installing their "server" on your computer. Most likely, using Linux will make these installations easier. I had very hard time keeping old Mac hardware, which limits OS version, up-to-date with new applications. Can you afford a Raspberry? Or, I had success installing modern linux on 15-year old laptops. There are strip-down versions of Linux specifically for running on old hardware. There are resources on how to install voip servers (mumble for example) on rapsberry (https://pimylifeup.com/raspberry-pi-mumble-server/) or Linux (https://wiki.mumble.info/wiki/Installing_Mumble).

Once you are successful with the server, experiment with connecting a ready-made, open-source voip client to it. Each voip software will offer some kind of C/C++/Java API for creating your own client. So, if you are successful with connecting with 3rd-party client, it is now time to create your own client. Nothing fancy, avoid GUI. Make a CLI program, following tutorials, on how to place a call, for example. All 3 languages C/C++/Java are supported by the fabulous Inline module and this will be the easiest way to "bind" your client with Perl.

There is also linphone, which is what it's called a softphone, a very good idea. Linphone offers a SIP server (installation).

If you have your own SIP server then you can use Net::SIP as has already been suggested to contact it. Linphone also offers an API for writing apps for it.

You have quite a few options, it seems.

If I may suggest: use linux whenever possible, it will make your life easier and will empower you and your compatriots. And btw I can think of something worse than a "3rd-world country": a developed country with people of "3rd-world" mentality.

bw, bliako

If all you want is an audio conference call, my telephone provider can do that. No computer programming or even computer required!

At one time, I had a Win XP laptop that just couldn't run Skype.

If your current machine is not capable of having a Zoom meeting, then I would just forget it.

We could get into details about how much bandwidth and latency requirements there are for this stuff. But I believe that is pointless.

If your machine cannot run a commercial conferencing app, the probability that you can re-create the functionality of said commercial app, is close to zero.

If all you want is a telephone conference call, use your telephone.

With all due respect, you sound like someone from a privileged first-world country which has more-or-less a "free" telephone call program. Such is hardly the case for my intended use.

In my case, one of the callers would be based in a country listed by the United Nations as a "Least Developed Country." Not only would the calls be expensive, but there would be insufficient ability to earn the amount required to cover those costs within that country. Furthermore, the government of that country severely limits the infusion of funds from other nations to private individuals within the country, and it is extremely difficult, if not impossible, to get any funding through, especially to a local (foreigners may be able to use their own foreign bank accounts to withdraw funds at an ATM).

I am not specifying the name of the country for multiple reasons, not merely for my own privacy here. This is a country in which non-profit organizations are not recognized, foreign (and even local) foundations are near impossible to establish, and the government opposes any form of grass-roots community action that is not led out by the government itself. Books of many types cannot be sold within the country, or imported, including Bibles--such is the nature of its government. The full extent to which the government monitors internet communications within the country or across its borders is unknown. A secure encryption of all communications would be advisable.

The circumstances are what they are. I would certainly not be considering going this route without reason. Honestly, this task is daunting to me and having looked into Djabberd and Jitsi and Asterisk, I have yet to find any plausible path to success.

Djabberd did not install correctly on my machine, and seems to be requiring one missing library which is no longer available. Asterisk seems more for first-world countries with good telephony systems. And I just haven't figured out yet what Jitsi is or can do. The task may be beyond my skills, which I knew was a possibility when I asked the question--but one can never get an answer to that which one has not first asked.

Without this form of communication, the international public-interest project it stood to benefit will be greatly hampered. I'm considering hiring some help, having found freelancer.com, but don't know yet how that works.


Blessings,

~Polyglot~

You may want to check out mumble, cross platform clients, uses opus codec and provides low latency comms, even on low end hardware.

Thank you for providing more details about your application situation. This matters!

Yes, I am in a "first-world" country where telephone calls are cheap and the menu of included features are many. I did not intend to sound "snarky" - often the e-mail type communication can sound more aggressive than what is intended.

In the type of country which you are describing, even getting a basic "land line" can be difficult. Sometimes you have to bribe the telephone guy. He disconnects a line from some other guy and gives it to you. Then that other guy with "dead air" instead of "dial tone" has to come up with a bribe to get the telephone guy to steal a line from somebody else! And so it goes...

Surprisingly, the cell phone networks in some of these under-developed countries are quite good.

Instead of some app that can run on some ancient computer, I would focus upon using an app that the guy in this 3rd world country can run on his cell phone. The available "computer power" in the cell phone is likely to exceed the power of an ancient computer.

It is unclear to me why one of the many commercial apps won't work?

Even if you have some basic encryption (and many of these apps do), the government of this country will know who that person is talking to!

As a reference, my internet connection can support about 3 simultaneous video and audio connections. Whatever site you decide to host this applicaion will need more bandwidth than that. This typically means that your home computer cannot do it.