← All Modules|Media Compression

3 VoIP Client Architecture: Two Case Studies

voip
media-compression
connected-products

3.1 Overview: Read a Calling Product as Component Boundaries

Real-Time Protocol Workflows already names the roles of SIP, RTP, SRTP, RTCP, WebRTC, ICE, STUN, TURN, and WebSocket. This chapter does not re-teach those protocols or their negotiation flows. It asks a different question: when a connected doorbell, intercom, or camera product ships a calling feature, which software component owns each responsibility, and what evidence must cross the component boundary?

Linphone is useful because its architecture exposes those seams. The source-era diagram separates product user interfaces from a reusable core, media engine, signaling library, RTP library, and operating-system services. Belledonne Communications’ current public SDK repository still bundles the four named component families, although the former standalone repositories have moved into the combined linphone-sdk project. Treat the diagram as a responsibility map, not as a promise about today’s source-tree layout or release packaging.

3.1.1 The Linphone Responsibility Stack

This separation prevents a common architecture mistake: treating “the VoIP library” as one opaque box. A call can be registered but have a failed capture device; media can be encoded while signaling has lost authentication; packets can leave the socket while the product UI still shows stale state. Each layer needs its own health signal and a defined hand-off to the next.

Call-control evidence

Account identity, requested peer, state transition, authorization decision, timeout, and termination reason.

Media evidence

Capture/render availability, selected format, processing latency, packet counts, loss/jitter observations, and concealment or mute state.

Product evidence

User-visible status, consent or privacy state, fallback path, retry policy, and a timestamped incident record.

3.2 Practitioner: Trace a Door-Station Call End to End

Consider a mains-powered apartment door station with a camera, microphone, speaker, and mobile companion app. The resident presses “answer” on the app. A useful architecture trace names the owner and evidence at every transition:

The important word is combines, not collapses. A product may present one call screen, but its diagnostic record should preserve two correlated timelines:

  • The control timeline records account readiness, request/response state, authentication, peer identity, timeouts, cancellation, and termination.
  • The media timeline records capture/render readiness, negotiated media configuration, first-packet and first-render times, packet loss, jitter, mute state, and device errors.

Correlation needs a stable session identifier and a monotonic clock. Without them, an incident reviewer cannot tell whether “no audio” preceded the answer, followed a network transition, or began when the operating system revoked microphone access.

3.2.1 Boundary Contracts for a Connected Product

Boundary
Input contract
Output evidence
Safe failure
UI to core
Authenticated user intent plus target session
Accepted state transition or explicit rejection
Keep door locked; show retry or alternate contact path
Core to signaling
Valid account, destination, policy, and session state
Transaction/dialog state and reason code
Bounded retry, then surface unavailable state
Core to media
Approved media direction, devices, and configuration
Capture/render readiness and processing health
Do not claim a usable call; preserve privacy/mute state
Media to packet path
Timestamped encoded frames and session parameters
Packet, sequence, loss, jitter, and receive timing
Conceal within budget, degrade visibly, then end or fall back
SDK to operating system
Permission, device, socket, clock, and lifecycle requests
Concrete resource handles or typed errors
Release partial resources and report the exact unavailable capability

This ledger turns a source-code decomposition into a product review. It also makes tests mutation-sensitive. Revoking microphone permission should fail the media boundary without rewriting the call-control history; dropping the signaling network should produce a different record from exhausting the audio device; suspending the mobile app should exercise lifecycle recovery rather than masquerade as packet loss.

3.3 Under the Hood: Contrast Central Coordination with a Historical Peer Model

The source deck contrasts Linphone with the historical desktop Skype peer-to-peer architecture described at the time: a signed-in client was not merely an endpoint but an active participant in a distributed network that helped locate peers and route traffic. This is a historical case study, not a claim about the current Skype service. The retained idea is architectural: responsibilities that a client-server design places in managed infrastructure can instead be distributed among clients.

The contrast must also stay precise. A SIP-based Linphone client uses server-coordinated signaling, but that does not imply that every media packet must traverse one central server. Conversely, a peer-assisted discovery or routing overlay does not imply that every client relays every call. Compare the ownership boundaries, not slogans such as “centralized” and “peer-to-peer.”

Server-coordinated client

Managed services can centralize account policy, directory state, registration, abuse controls, and audit. Endpoints can remain simpler, but service availability and relay capacity become explicit dependencies.

Peer-assisted client

Discovery or routing work can be spread across participating endpoints. That may reduce reliance on one path, but it spends endpoint CPU, memory, energy, bandwidth, and trust.

IoT product consequence

A mains-powered desktop and a constrained door station are not equivalent peers. The architecture must state whether a device may relay third-party work, how updates revoke unsafe behavior, and what an operator can audit.

3.3.1 Choose by Responsibility, Not Fashion

For an intercom or camera product, compare at least these dimensions:

Decision dimensionServer-coordinated tendencyPeer-assisted tendency
Endpoint resource budgetKeeps directory and policy work off constrained clientsMay consume client compute, memory, battery, and uplink for shared work
OperationsCentral services expose clearer policy and fleet controlsDistributed state can make diagnosis and coordinated change harder
ResilienceNeeds explicit redundant services and relay capacityCan retain alternate participants, but churn and peer quality become inputs
Privacy and trustConcentrates sensitive metadata in managed servicesExpands which endpoints may observe or act on routing/discovery information
AuditEasier to build one authoritative control-plane recordRequires evidence from multiple independently changing participants

Neither column wins universally. The product decision is a responsibility allocation: who locates peers, who enforces policy, who may relay traffic, who pays the resource cost, and who can explain a failed or abusive session after the fact.

3.4 Summary

  • Linphone separates product UI, high-level call control, media processing, signaling, RTP packet handling, and operating-system services.
  • The current combined Linphone SDK still bundles Liblinphone, Mediastreamer2, belle-sip, and oRTP, while the source-era package diagram remains a responsibility map rather than a release manifest.
  • A connected product needs correlated but distinct call-control and media timelines because successful signaling does not prove usable capture, rendering, or packet quality.
  • Historical Skype illustrates a peer-assisted alternative in which clients participate in discovery or routing; it must not be presented as current Skype architecture.
  • Server-coordinated and peer-assisted designs allocate resource, trust, operations, privacy, and audit responsibilities differently.

3.5 Key Takeaway

A VoIP SDK is not one box. Name the component that owns user intent, call state, signaling, media processing, packet timing, and device resources; then define the evidence and safe failure at every boundary. Compare distributed alternatives by the responsibilities they move onto endpoints.

3.6 See Also