Skip to main content

SIP on RTOS and bare-metal targets

Running SIP on an RTOS or an OS-less embedded target is possible, but the difficult part is rarely SIP message syntax. The real work is replacing the services that a desktop or Linux-oriented library may assume are always available.

A portable SIP implementation should make those assumptions explicit so that the target can provide them through a small platform layer.

What SIP actually needs from the platform​

At a minimum, a practical SIP endpoint generally needs:

  • a source of monotonic time for protocol timers;
  • UDP and/or TCP transport;
  • DNS if hostnames must be resolved;
  • memory management;
  • a way to schedule protocol work;
  • random values for identifiers and, for secure transports, cryptographic entropy;
  • persistent configuration for account/server settings in many products.

TLS adds certificate, time-validation and cryptographic-library requirements. RTP adds a real-time media path with tighter timing than SIP signaling itself.

RTOS integration​

An RTOS usually provides enough infrastructure, but every RTOS has different APIs and concurrency rules.

Typical mapping work includes:

  • socket or network-stack wrappers;
  • mutex/event primitives if the SIP component is multi-context;
  • timer services;
  • task creation or integration into an existing task;
  • heap allocation hooks;
  • logging hooks;
  • DNS resolver integration;
  • TLS-library integration.

A good port keeps these mappings concentrated in one place rather than scattering RTOS-specific #ifdef blocks through the signaling code.

Bare-metal or cooperative operation​

An OS-less system must provide the scheduling behavior itself. A common model is a cooperative main loop:

initialize hardware
initialize network
initialize SIP subsystem

loop forever:
    poll network input
    process SIP timers/events
    service media
    service device/application state

That can work well for a small endpoint if no component blocks for long periods. The product must be designed so that media I/O, network processing and protocol timers all receive service within their required timing budgets.

SK400VOP supports an OS-less integration model when paired with its supported cooperative-kernel approach and required platform mappings. See the SK400VOP product page for the commercial product positioning.

Timer accuracy and clock sources​

SIP transactions use retransmission and timeout timers. The target therefore needs a monotonic clock that does not jump when wall-clock time changes.

Media has a separate timing problem: RTP timestamps describe media sampling time, while actual packet scheduling has to follow the codec's packetization interval. Do not use one vague "system tick" abstraction without checking whether it is precise enough for both signaling and media.

Socket ownership​

On embedded systems, the network stack may have strict ownership or zero-copy rules. Before porting, define:

  • who allocates the transmit buffer;
  • whether send calls copy data immediately;
  • who releases receive buffers;
  • whether callbacks execute in an IP-stack task;
  • whether application code may block in that context;
  • how TCP reconnects and TLS sessions are represented.

These rules should be part of the porting contract, not discovered through intermittent crashes.

DNS and provisioning​

Many devices are tested using an IP address and later fail in deployment because the actual SIP server is configured as a hostname.

If the product accepts SIP domains or hostnames, decide how it handles:

  • A and AAAA records;
  • IPv4/IPv6 preference;
  • DNS timeouts;
  • multiple returned addresses;
  • DNS server changes;
  • SIP-specific DNS behavior if required by the deployment.

A highly constrained product may intentionally support only a subset, but the limitation should be explicit.

TLS on constrained systems​

SIP over TLS is substantially more demanding than plain UDP signaling. The target needs:

  • a TLS implementation;
  • adequate RAM for handshake and record buffers;
  • trusted certificate storage;
  • entropy;
  • certificate validation policy;
  • a method to obtain or validate time;
  • a secure update strategy for roots and cryptographic code.

A design that simply disables certificate verification because the board has no real-time clock is not a safe production solution. If the target lacks time at boot, provisioning or trusted-time bootstrapping must be designed deliberately.

Media and DMA​

Audio capture/playback is often driven by DMA or an interrupt-driven codec interface. The RTP path should adapt to that hardware timing instead of making the hardware fit a generic desktop audio API.

A common embedded split is:

  • ISR/DMA fills or drains fixed audio buffers;
  • a media task performs codec processing;
  • RTP send/receive runs in the media context;
  • SIP signaling remains in a separate lower-frequency context.

This keeps real-time audio work away from the signaling state machine.

Memory strategy​

A small target should decide early whether the SIP component may use a general-purpose heap.

Alternatives include:

  • fixed-size pools;
  • region/arena allocation per call;
  • static transaction objects;
  • bounded message buffers;
  • platform allocator callbacks.

The right model depends on the stack API. The important requirement is bounded behavior under worst-case signaling load.

Porting checklist​

Before committing to an RTOS or bare-metal port, verify:

  • network API mapping;
  • timer resolution and monotonic clock;
  • scheduler/reentrancy model;
  • memory allocator behavior;
  • DNS requirements;
  • TLS entropy and certificate handling;
  • logging/diagnostics path;
  • media timing and buffer ownership;
  • shutdown/restart behavior;
  • watchdog interaction;
  • firmware update implications.