I've just published something unusual: a complete philosophy course for VoIP engineers. Yes, you read that right. Philosophy. And no, I haven't lost my mind.

After years designing VoIP systems, I realized something uncomfortable: the most important decisions we make as engineers aren't technical. They're philosophical. When you choose between centralized vs distributed architecture, you're not choosing between technologies. You're choosing between visions of power and autonomy. When you configure timeouts, you're not just optimizing performance. You're defining what it means to wait and when it's ethical to stop. When you design your observability stack, you're not just "monitoring." You're deciding what counts as knowledge and what remains invisible.

And nobody prepared us for these questions.

Why philosophy?

Because the conceptual tools we need to think about complex systems already exist—they're just in philosophy books, not RFCs.

Concrete example:

# Your dashboard shows:
active_calls = 347

# Is it true there are 347 calls?

This apparently simple question leads you directly to:

• Ontology: What does it mean for a call to "exist"?
• Epistemology: How do we know the counter is correct?
• Time: Is the data "current" or stale?
• Power: Who defines what counts as "active call"?

And you discover that Leslie Lamport already thought about this (logical clocks), that Foucault has much to say about surveillance embedded in your architecture, and that Bergson understood the difference between measured and lived time better than your Grafana dashboard.

What this course is NOT

• Not abstract philosophy disconnected from practice
• Not a Kamailio tutorial with decorative philosophical quotes
• Not academic in the bad sense (pedantic, inaccessible)
• Doesn't assume prior knowledge of philosophy

What this course IS

A rigorous but applied philosophical framework for thinking about VoIP.

Four modules:

Module 1: Ontology of VoIP Infrastructure

What exists and how does it exist?

• The nature of protocols (SIP, Ship of Theseus, and the identity problem)
• RTPEngine: relay vs transcode as ontological transformations
• CAP theorem as philosophical problem (Parmenides vs Heraclitus in distributed systems)
• Docker: images as Platonic Forms, containers as instances
• Persistence: databases, RAM, CDRs and different modes of existence

Key question: Where does a VoIP call "exist"?

Module 2: Epistemology of Networked Systems

How do we know what we claim to know?

• Direct vs indirect observation (all VoIP knowledge is mediated)
• The time problem in distributed systems (Lamport, vector clocks, NTP)
• Logs, metrics and traces as "technical testimony"
• The uncertainty principle in observability (measuring alters the system)
• Cognitive biases in debugging
• Laboratory: Complete epistemological audit of your system

Key question: When is it rational to trust a log?

Module 3: Ethics and Politics of Architecture

Who benefits from each technical decision?

• The Sophists and the rhetoric of technology (selling architectures)
• Plato: Are there objectively superior design principles?
• Habermas: Communicative rationality as ideal (conferences that facilitate genuine dialogue)
• Foucault: Power inscribed in architecture (Panopticon, surveillance, GDPR)
• Lawful intercept: analysis from four philosophical perspectives
• Laboratory: Ethical-political analysis of your architecture

Key question: Is architecture neutral?

Module 4: Temporality and Processuality

Lived time vs measured time

• Bergson: Duration vs spatialized time (CDR vs experience)
• Husserl: The "living present" and jitter buffer as artificial retention
• Whitehead: There are no "calls," there's "calling" (reality as process)
• Heidegger: Vulgar time vs authentic temporality, timeouts as finitude
• Synchrony, asynchrony and conversational rhythm
• Laboratory: Complete temporal audit

Key question: Did that call last "247 seconds"?

Who this course is for

Yes, it's for you if:

• You design or maintain VoIP systems
• You make architectural decisions (not just implement)
• You've asked yourself "why do we do things this way?"
• You have intellectual curiosity beyond "works/doesn't work"
• You want conceptual tools to think better

No, it's not for you if:

• You're looking for a step-by-step Kamailio tutorial
• You just want "best practices" without questioning them
• The word "philosophy" seems like a waste of time to you
• You need immediate results without reflection

Format and pricing

Format: 4 modules in Markdown, ready for Moodle or self-study

• ~80-100 pages of content
• 20+ integrated reflective exercises
• 4 comprehensive practical laboratories
• Extensive bibliography per module
• Available in Spanish and English

Price: Free

Access: https://campus.mesaproyectos.com/course/view.php?id=53

Why I made it free

Because philosophical knowledge should be accessible. Because the VoIP industry needs engineers who think critically, not just implement RFCs. Because someone taught me for free and I want to pay it forward.

A concrete example of what you'll learn

Take the CAP theorem. You know it: in distributed systems, you can only have 2 of 3: Consistency, Availability, Partition tolerance.

It's typically taught as a technical limitation.

In the course, you discover it's a fundamental ontological problem:

• Consistency = Platonic position (there's ONE truth, centralized in DB)
• Availability = Nominalist position (multiple local "truths" in each node)
• Impossibility of both = not a bug, it's the nature of distributed reality

And you connect with Parmenides (being is one and immutable) vs Heraclitus (everything flows, nothing remains).

The CAP debate is the same debate the Greeks had 2500 years ago about the nature of reality.

Understanding this won't give you the technical solution, but it gives you conceptual clarity to communicate trade-offs, evaluate proposals, and design consciously.

Honest warning

This course will not make your Kamailio process more CPS.

It will make you understand why optimizing only for CPS falls short.

It won't give you easy answers. It will give you better questions.

It won't tell you which architecture to choose. It will give you criteria to decide consciously.

How to start

1. Enroll if you decide to continue
2. Complete one module per week (or at your own pace)
3. Do the laboratories — that's where real transformation happens
4. Apply what you learned immediately to your real systems

Final question

Why a course on philosophy of VoIP instead of simply better engineering of VoIP?

Because the hard problems aren't technical. They're conceptual.

You can learn Kamailio by reading the documentation.

But to understand why your centralized architecture generates certain power problems, why your metrics don't capture what really matters, why some timeouts feel "fair" and others "cruel"...

...for that you need philosophy.

And once you see these dimensions, you can't unsee them.

Your work won't be easier. It will be more conscious. And that makes all the difference.

Course access: https://campus.mesaproyectos.com/course/view.php?id=53

Questions: campus at mesaproyectos.com

Discussion: https://campus.mesaproyectos.com/mod/forum/view.php?id=2252

P.S.: If you think "I don't have time for philosophy," I understand. I thought the same. But it turns out that dedicating 20 hours to conceptually understanding what you do saves you hundreds of hours making wrong decisions. It's investment, not expense.

P.P.S.: If after Module 1 you think "this is a waste of time," I accept honest criticism. I only ask that you try it in good faith.