Plan9’s filesystem protocol is interesting. What would it look like to implement VOIP on top of it? A first draft.
The man-page does a better job of providing a technical description of 9P, but I’ll give a low-tech explanation for completeness.
9P is: - A protocol used by clients and servers to expose and make use of a filesystem hierarchy on a remote machine. - In the simplest case, it allows a client to navigate a filesystem on a remote host. - For example, WSL2 (Linux-on-Windows) has each Linux subsystem start a 9P server to expose the Linux filesystem. - The filesystem hierarchy exposed may be /virtual/. As in a server responding to a read request with generated data. - For example, the server may construct a filesystem-structure representating known-paths of a website. When clients read a ‘file’ in that path, the data returned comes not from a file, but from a process (i.e. python, nodejs, ruby).
I have some interest in how VOIP could be implemented with 9P. SIP isn’t hierarchical, so representing calls in a hierarchy isn’t immediately obvious. The properties of a tree-structure representing a typical commercial VOIP service (with UACs, calls, and perhaps call recordings), would (I think) look a little like this:
voip |_<account> |_cdr | |_2025_01_01 | |_1735689600_1000123456_033443443434.cdr |_call_recordings | |_2025_01_01 | |_1735689600_1000123456_0787878787.opus |_<extension> |_credential |_ongoing | |_1000123456_0787878787 | |_metadata | |_hep.sock | |_rtp_src.sock | |_rtp_dest.sock |_uacs |_<registration_a> |_sip.sock |_<registration_b> |_sip.sock
A few notes on this:
This directory structure would be managed by a SIP/RTP-aware 9P-implementing server.
The directories <account> and <extension>, alongside the file credentials would be created by the admin. Clients would be matched to their account and extenion by SIP registration against <account>/<extension>/credentials. Access to paths above extension would be disallowed.
Registrations would persist for the lifetime of the sockets in <account>/<extension>/uacs/<registration>/sip.sock
Calls would be a child of extension, but CDRs and and call recordings would be a child of account. This is based on the presumption businesses do not want their staff accessing account-wide cdrs, recordings, or sockets.
This does pose problems for BLF, as clients can’t fetch a list of on-call extensions on their account. At least insofar as implementing BLF in a filesystem-oriented way.
It also restricts an extensions access to its own recordings.
NAT, as always, is a problem. SIP is fine, as I’m tying registrations to their sockets. RTP is (generally speaking) not. The rtp_src.sock above would be created using SDP from the client, and is certainly wrong. Symmetric RTP helps, as does STUN. But creates more work in the server implentation.