The Communicator

comms-ram holds the room’s presence, chat, invitations, call offers and media state. comms-media carries audio/video and applies per-viewer handling. These are actual server processes. They can run on a node inside the user’s network; a commercial cloud media service is not required.

The node publishes a where cell with identity-based endpoints for the RAM and media services. The member resolves those into the proper scoped address or alias. Android’s Communicator is opened by the membership app with those resolved endpoints.

The media path prioritizes audio and adapts video. Framing, segmentation and abort behavior limit how a slow viewer affects other work. Per-viewer rates let one constrained receiver see a smaller picture while another receives the upload. The bottom-rung walk shrinks through 640×360, 480×360, 320×240 and 160×120 before audio-only behavior.

The C++ status record includes tests against the earlier fnav implementation’s own vectors, audio interoperability and measured link tests. Those tests do not replace a device’s camera, microphone and real bearer qualification.

Desktop r3 rings only while the caller still offers the session and the invitation remains fresh; hang-up withdraws the offer. Desktop video stamps frame number and capture time. The viewer’s “here” clock lets the operator inspect delay.

Android r5 combines the current pond-driven launch with the full-screen call interface, movable inset, camera switch, fill/fit and Stats. The phone’s sender does not stamp its picture in the same way as the desktop.

The October 12 demonstration reports a live Windows–Android call at 1280×720 and 20 fps. The displayed receive-side rate is roughly 1.2–1.5 Mb/s. The earlier roughly 121 Kbps bidirectional call is a separate 160×120 at 24 fps experiment over the broker/radio path.

The emulator’s startup lag remains an open root-cause investigation. The clock stamp makes a recurrence measurable. Read the evidence without combining the two calls.