Morning: a phone arrived
The day started with a used Cisco Unified IP Phone CP-9951 that had cost €35. The original plan was reconnaissance: identify the interfaces, understand provisioning and find the cleanest supported way to make the phone useful in the home lab.
It did not require custom firmware, a bootloader modification or a factory reset. Cthulhu provides DHCP and TFTP, the Cisco loads its normal SEP configuration, and Asterisk handles SIP.
One requirement was non-negotiable: the cat background stays.
First useful discovery: the screen can receive H.264
The CP-9951 advertises H.264 video reception over SIP/RTP. Provisioning enabled the existing video capability, and the phone negotiated a 640×480 receive stream using the profile expected by the Cisco firmware.
That changed the question from “what can this old office phone do?” to “what can we make it display?”
Speed dial 111: Werner
The first deliberately unnecessary application was Werner.
A dedicated Baresip endpoint registers with Asterisk as extension 200. Dialling 111 from the Cisco routes to that endpoint, which auto-answers and sends the prepared Werner sequence as real H.264/PCMU media. The video had to be scaled to 640×480, 24 fps, H.264 Baseline/Constrained Baseline Level 3.0 so the Cisco would accept it.
Button 2 became Werner → 111. Video and sound both play on the phone.
Speed dial 666: live DOOM
The second application is not a prerecorded DOOM clip. DOOM Retro is actually running live on Cthulhu under Wayland/Sway, and the Cisco displays the current game output.
A separate Baresip instance registers as endpoint 201. The Cisco's third speed dial is DOOM → 666, Asterisk routes 666 to that endpoint, and the live stream is delivered back to the handset.
The five-second problem
The first working live path used wf-recorder, a NUT FIFO and Baresip's avformat input. It worked, but the picture arrived roughly five seconds late. Y4M reduced that to around two seconds but introduced visual corruption.
The fix was to stop treating the live screen as a buffered media file and present it as a virtual camera instead.
Sway / HDMI-A-1 ↓ wf-recorder ↓ 640×480 · 24 fps · YUV420P v4l2loopback → /dev/video42 (DOOM-Cisco) ↓ Baresip v4l2 → libx264 → H.264 RTP ↓ Asterisk ↓ Cisco CP-9951
With that path, the previous multi-second delay is effectively gone and the phone shows DOOM near realtime.
And the sound really comes from the phone
Video alone would have been cheating.
The DOOM instance captures Cthulhu's real PipeWire/Pulse output monitor and sends it as PCMU audio through SIP/RTP. The result is the actual game sound coming from the Cisco speaker with essentially no noticeable delay.
Workshop recordings
Two original recordings belong with this field note because they show the experiment as it actually happened: the button press, the phone reacting and the audio in the room.
Press the Werner speed dial, extension 111 answers, the Werner sequence starts with video and audio on the Cisco — including the spontaneous laugh when it works.
Original MP4 will be embedded here.
Press the DOOM speed dial, extension 666 answers, live DOOM appears on the display and the game sound is audibly coming from the phone speaker.
Original MP4 will be embedded here.
Current result
Button 2: Werner → 111 → Asterisk → Baresip 200 → Werner video + audio → Cisco Button 3: DOOM → 666 → Asterisk → Baresip 201 → live Cthulhu video + real game audio → Cisco
The phone remains on its normal Cisco firmware. The cat remains on the background. 666 is now a perfectly legitimate speed dial.
Result
Can a Cisco CP-9951 run DOOM?
Yes — as a near-realtime SIP/H.264 thin client. :DD
Next experiment
Displaying DOOM is proven. The next step is to make the phone itself the controller: Cisco keypad / DTMF → Asterisk/Baresip → Cthulhu → DOOM.
2 = forward 8 = backward 4 = turn left 6 = turn right 5 = fire 0 = use / open
If that works, the answer changes from “DOOM is running on the phone display” to “DOOM is being played with an office phone.”