Phone Home

The basic idea here is that a Raspberry-Jam box could boot up and immediately connect to a server that hands down configuration, peering information, and could perhaps even provide a remote channel in for remote help. This page will flesh out some of these ideas for discussion and development.

Basic Configuration

At the simplest level, this "Phone Home" mechanism could be used to register users with a central clearinghouse for configuration and peering information. At a minimum, the client could download parameters for jack/jacktrip commands that get them connected with their peers.

This is essentially what Jamlink did, your server connected to HQ, and became associated with the user online so that folks could find others with whom to jam. The server-side application could be simple for starters, and a rich ecosystem could be built over time if developers have the interest and motivation to implement that.

Automated Config Tuning

Once the idea of having the client phone home is in place, a variety of other things become possible that could take the burden of managing the technology off of the end users. For example, if the client starts jacktrip in loopback mode at boot time, a server could conceivably connect and take measurements that could then be used to choose an optimal set of config parameters to minimize latency. Once calculated, those parameters could then be handed down to the client along with peering information and the client can tear down the loopback and start one or more point-to-point peering connections.

Updates and Changes

The client could conceivably check in periodically to see whether updates or configuration changes are ready, and could pull them down and apply the changes automatically. It's not hard to imagine a tiny, low-overhead check-in running fairly frequently, so that a new endpoint could be added to a jam session by simply updating a form on the server, and the client picking that change up and implementing it in less than a minute.

This same mechanism could be used for something as complex as software updates, or even cutting off bad actors if abusive or unethical behavior is flagged.

Remote Access

Another possibility, assuming there is sufficient trust/controls, is that the client could open an ssh tunnel to provide a channel back for technical help, or even for development efforts. Suddenly, the non-technical users can still help with testing, even though they may not even have a keyboard or monitor connected -- a remote ssh session could allow a developer to refine the client's configuration "on the fly" in order to quickly get an audio bridge working optimally.

There's no intrinsic reason that any of this need be limited to the Raspberry Pi platform, all of these concepts would apply equally well on any UNIX-like system.