44  IoT Real-Time Protocols

In 60 Seconds

Real-time IoT protocols (RTP, SIP, WebRTC) sacrifice reliability for timing, using UDP to avoid retransmission delays that would cause stuttering video or garbled audio. For IoT devices like smart doorbells and intercoms, the 150ms latency threshold determines whether to use real-time streaming protocols or standard messaging protocols like MQTT and CoAP.

44.1 Learning Objectives

By the end of this chapter, you will be able to:

• Explain VoIP Architecture: Describe the complete protocol stack (SIP, RTP, SRTP, RTCP) for real-time audio/video in IoT devices
• Compare RTP vs Messaging Protocols: Distinguish when to use RTP instead of MQTT/CoAP based on latency, packet-loss tolerance, and data type
• Design Secure Streaming: Configure encryption (SRTP, TLS) and authentication for real-time IoT streams accessible from the internet
• Select Appropriate Protocols: Justify the choice between SIP, RTSP, and WebRTC for specific IoT device types and deployment scenarios
• Calculate Latency Budgets: Apply the 150ms end-to-end threshold to evaluate whether a proposed protocol stack meets real-time conversation requirements
• Analyze Hybrid Architectures: Assess when to combine messaging protocols (MQTT) with real-time protocols (RTP/SIP) in a single IoT system

For Beginners: IoT Real-Time Protocols

Some IoT applications cannot tolerate any delay – a self-driving car needs to react in milliseconds, not seconds. Real-time protocols are designed to guarantee that data arrives on time, every time. Think of them as an express lane on a highway where critical traffic always gets through without waiting.

Most Valuable Understanding (MVU)

Real-time IoT protocols (RTP/SIP/WebRTC) prioritize latency over reliability: they run over UDP, skip lost packets rather than retransmit, and require <150ms end-to-end delay for acceptable human perception. Use them for continuous audio/video streams (doorbells, intercoms), but stick with MQTT/CoAP for discrete sensor data.

This is the fundamental trade-off: messaging protocols (MQTT, CoAP) guarantee delivery but accept latency, while real-time protocols (RTP) guarantee timing but accept packet loss. A video doorbell that retransmits lost packets would have unwatchable, stuttering video. Instead, it skips the lost frame and continues - the human eye interpolates the gap.

The 150ms Rule: Human conversation becomes awkward when one-way end-to-end delay exceeds 150ms (ITU-T G.114). This is why real-time IoT devices use UDP (no TCP handshake overhead) and SIP/RTP (designed for media timing) instead of HTTP/MQTT.

44.2 Prerequisites

Before diving into this chapter, you should be familiar with:

• Application Protocols Overview: Basic understanding of IoT application protocols and when to use lightweight protocols
• Transport Fundamentals: UDP vs TCP characteristics, including why UDP is preferred for latency-sensitive media

---

Sensor Squad: The Video Doorbell Adventure!

Hey there, future IoT engineer! Let’s learn about real-time protocols with the Sensor Squad!

Sammy the Sensor just got a new job: being the brain of a smart video doorbell! But there’s a problem - when someone rings the doorbell, Sammy needs to send live video to your phone SUPER fast!

The Big Difference:

Lila the Light sends temperature readings using MQTT. If a message gets lost, no big deal - another one comes in a minute! It’s like sending postcards: “It’s 72 degrees!” … (lost in mail) … “It’s 73 degrees!” You didn’t miss much!

But Sammy’s video doorbell is different. Imagine if your video call worked like postcards: - “Hi, I’m at your door–” (lost) - “–nd I have a package–” (lost) - “–ease open up!” (arrived)

You’d only hear “ease open up!” That makes no sense!

The Magic of RTP (Real-time Transport Protocol):

Instead of waiting for lost messages like MQTT does, RTP uses a different magic trick:

Protocol	Lost Message Strategy	Why
MQTT	Wait and resend	“I MUST deliver this temperature!”
RTP	Skip it, keep going	“Show the next video frame instead!”

Max the Motor explains: “When you’re watching a video, your eyes are SO fast that if we skip one tiny frame (1/30th of a second), you don’t even notice! But if we WAITED to resend it, you’d see the video freeze - yuck!”

The 150 Millisecond Rule:

Bella the Button discovered something cool: humans get confused if a phone call has more than 150 milliseconds (0.15 seconds) of delay!

• Under 150ms: “Hello!” … “Hi there!” (normal conversation)
• Over 300ms: “Hello!” … … … “Hi there!” (awkward, talking over each other)

That’s why video doorbells use UDP (super fast, no waiting) instead of TCP (reliable, but slow)!

Real-World Doorbell Flow:

Fun Fact: Your favorite video doorbell uses BOTH types of protocols! MQTT for notifications (needs to arrive), RTP for live video (needs to be fast). It’s like having a postcard for important news AND a phone call for live conversations!

Try This: Next time you use a video call, notice how sometimes a face looks “blocky” for a second, then gets clear again. That’s the protocol skipping some lost data and catching up - just like Sammy’s doorbell!

44.3 Real-time Protocols for IoT

While MQTT and CoAP handle most IoT data exchange scenarios, some applications require real-time audio and video streaming with strict latency requirements. Video doorbells, baby monitors, voice assistants, and intercom systems all need protocols designed specifically for continuous media streams.

44.3.1 IoT Protocol Ecosystem: Where Real-Time Fits

This ecosystem view shows that modern IoT devices often use both messaging and real-time protocols - each optimized for its specific purpose.

44.3.2 Real-Time Protocol Decision Flow

44.4 VoIP and SIP Architecture

Voice over IP (VoIP) enables real-time voice and video communication over IP networks. The protocol stack for VoIP consists of several layers working together:

44.4.1 SIP Call Flow for Video Doorbell

VoIP Protocol Stack: SIP Signaling with RTP Media Transport

Figure 44.1: VoIP Protocol Stack: SIP handles session control (call setup/teardown), while RTP carries the actual audio/video data over UDP. Security layers (SRTP, TLS, zRTP) protect both signaling and media streams.

44.5 Key Protocol Components

Protocol	RFC	Purpose	IoT Relevance
SIP	RFC 3261	Session Initiation Protocol - multimedia session control	Call setup for video doorbells, intercoms
RTP	RFC 3550	Real-time Transport Protocol - media stream delivery	Audio/video streaming from cameras
RTCP	RFC 3550	RTP Control Protocol - quality monitoring	Adaptive bitrate for constrained networks
UDP	RFC 768	User Datagram Protocol - connectionless transport	Low-latency delivery (no TCP handshake)
SRTP	RFC 3711	Secure RTP - encrypted media	Privacy for baby monitors, doorbells
zRTP	RFC 6189	Key exchange for SRTP	End-to-end encryption setup
TLS	RFC 8446 (TLS 1.3)	Transport Layer Security - encrypted signaling	Secure SIP (SIPS) on port 5061

44.6 SIP Ports and Security

SIP Port Assignments

Port	Protocol	Security	Use Case
5060	SIP over UDP/TCP	Unencrypted	Internal/trusted networks
5061	SIPS over TLS	Encrypted	Internet-facing devices

For IoT devices accessible from the internet (video doorbells, remote intercoms), always use port 5061 with TLS encryption to prevent eavesdropping and session hijacking.

44.7 Real-time IoT Applications

Real-Time IoT Device Protocol Selection

Figure 44.2: Real-time Protocol Selection for IoT: Two-way communication devices (doorbells, intercoms) use SIP+RTP, while one-way streaming devices (cameras, monitors) often use RTSP+RTP. Voice assistants increasingly use WebRTC for browser compatibility.

Common IoT Use Cases:

Device	Protocol	Why
Video Doorbell	SIP + SRTP	Two-way audio/video with visitor, needs secure encrypted stream
Baby Monitor	RTP (or RTSP)	One-way video stream, low latency critical for responsiveness
Smart Intercom	SIP + RTP	Full duplex audio between rooms, session-based communication
Voice Assistant	WebRTC or proprietary	Browser/app integration, cloud speech processing
Security Camera	RTSP + RTP	Continuous streaming, ONVIF standard interoperability

44.8 WebRTC for Browser-Based IoT

WebRTC (Web Real-Time Communication) has become increasingly important for IoT devices that need browser-based access. It provides peer-to-peer audio/video streaming with built-in NAT traversal and encryption.

44.8.1 WebRTC Connection Architecture

WebRTC Components:

Component	Purpose	IoT Use Case
getUserMedia	Access camera/microphone	Smart display video call
RTCPeerConnection	Establish P2P connection	Direct device-to-browser stream
STUN	Discover public IP/port	NAT traversal for home networks
TURN	Relay when direct fails	Symmetric NAT, firewall scenarios
DTLS-SRTP	Encrypted media	Secure by default

WebRTC vs SIP for IoT

Choose WebRTC when:

• Browser access required (no app installation)
• NAT traversal is complex (STUN/TURN built-in)
• You want encryption by default

Choose SIP + RTP when:

• Integrating with existing VoIP infrastructure
• Need PSTN gateway (phone network)
• SIP-based intercom systems

44.9 Comparison: Real-time vs Messaging Protocols

When should you use VoIP/RTP instead of MQTT/CoAP?

44.9.1 Protocol Architecture Comparison

Requirement	MQTT/CoAP	VoIP/RTP
Data Type	Sensor readings, commands, telemetry	Continuous audio/video streams
Latency Tolerance	100ms - seconds acceptable	<150ms required (human perception)
Packet Loss	Retransmit (reliability critical)	Skip/interpolate (continuity critical)
Bandwidth	Low (bytes to KB per message)	High (64kbps - 2Mbps continuous)
Connection Model	Message-based (discrete)	Session-based (continuous stream)
Typical Payload	JSON, CBOR, binary sensor data	PCM audio, H.264/H.265 video

When to Use RTP vs MQTT for IoT Audio

Use RTP/SRTP when:

• Streaming continuous audio/video (doorbell live view)
• Two-way voice communication (intercom, doorbell talk)
• Latency under 150ms is critical
• You need synchronized audio/video playback

Use MQTT when:

• Sending audio clips/recordings (doorbell motion event)
• Push notifications with audio alert
• Speech-to-text results from cloud processing
• Audio metadata (noise level, voice detection events)

Hybrid approach (common in smart doorbells):

Motion detected → MQTT notification to phone app
User opens app → SIP session established
Live video/audio → RTP/SRTP stream
User speaks → RTP audio to doorbell speaker
Call ends → SIP session terminated
Event recorded → Video clip stored, MQTT notification

44.10 Security for Real-time IoT

Real-time audio and video streams require strong security to prevent eavesdropping:

44.10.1 Security Layer Architecture

Security Layer	Protocol	Protects
Signaling Encryption	TLS (SIPS on port 5061)	Call setup, session details
Media Encryption	SRTP	Audio/video content
Key Exchange	zRTP, DTLS-SRTP	Secure key negotiation
Authentication	Digest auth, certificates	Caller/device identity

Security Best Practice for IoT Doorbells

Many consumer IoT devices have been compromised due to unencrypted streams. Always ensure:

1. SRTP enabled - Not just RTP (encrypted vs plaintext audio/video)
2. TLS for SIP - Port 5061, not 5060
3. Strong authentication - Not default credentials
4. End-to-end encryption - zRTP prevents cloud provider access to content

44.11 RTP Packet Structure

Understanding RTP helps diagnose audio/video issues in IoT deployments:

44.11.1 RTP Header Format

Field	Bits	Purpose
V	2	Version (always 2)
P	1	Padding flag
X	1	Extension header present
CC	4	CSRC count
M	1	Marker (frame boundary)
PT	7	Payload type (codec identifier)
Sequence	16	Packet ordering/loss detection
Timestamp	32	Media timing (audio sample count)
SSRC	32	Stream identifier

RTP Header Overhead: 12 bytes minimum (vs CoAP’s 4 bytes, MQTT’s 2 bytes)

The larger header is justified for streaming media because: - Sequence numbers detect packet loss and reordering - Timestamps enable jitter buffering and synchronization - SSRC allows multiple streams in one session

viewof cameraFps = Inputs.range([15, 60], {value: 30, step: 5, label: "Camera frame rate (fps)"})
viewof encodeMs = Inputs.range([5, 50], {value: 20, step: 5, label: "H.264 encode time (ms)"})
viewof networkRttMs = Inputs.range([10, 200], {value: 100, step: 10, label: "Network RTT (ms)"})

{
  const captureMs = Math.round(1000 / cameraFps);
  const networkOneWay = Math.round(networkRttMs / 2);
  const decodeMs = 15;
  const displayMs = Math.round(1000 / 60);
  const total = captureMs + encodeMs + networkOneWay + decodeMs + displayMs;
  const threshold = 150;
  const ok = total <= threshold;
  return html`<div style="background: var(--bs-light, #f8f9fa); padding: 1rem; border-radius: 8px; border-left: 4px solid ${ok ? '#16A085' : '#E74C3C'}; margin: 1rem 0;">
    <strong>Doorbell Latency Budget:</strong>
    <ul style="margin: 0.5rem 0 0 0; font-size: 0.95em;">
      <li>Camera capture (1/${cameraFps}s frame): <strong>${captureMs} ms</strong></li>
      <li>H.264 encode: <strong>${encodeMs} ms</strong></li>
      <li>Network one-way (RTT/2): <strong>${networkOneWay} ms</strong></li>
      <li>Client decode: <strong>${decodeMs} ms</strong></li>
      <li>Display render (60 Hz): <strong>${displayMs} ms</strong></li>
    </ul>
    <p style="margin: 0.5rem 0 0 0; font-weight: bold; color: ${ok ? '#16A085' : '#E74C3C'}">
      Total: ${total} ms — ${ok ? `within 150 ms threshold (conversation feasible)` : `exceeds 150 ms threshold (conversation awkward)`}
    </p>
  </div>`;
}

Putting Numbers to It

Let’s calculate the latency budget for a smart doorbell and understand why the 150ms threshold matters.

Human perception threshold (ITU-T G.114): Interactive speech requires \(L < 150\) ms end-to-end for natural conversation.

Doorbell latency breakdown: \[L_{\text{total}} = L_{\text{camera}} + L_{\text{encode}} + L_{\text{network}} + L_{\text{decode}} + L_{\text{display}}\]

Component latencies:

• Camera capture: \(L_c = 33\) ms (30 fps frame time)
• H.264 encode: \(L_e = 20\) ms (hardware encoder)
• Network (Wi-Fi + Internet): \(L_n = 50\) ms (RTT/2)
• Client decode: \(L_d = 15\) ms (phone hardware)
• Display render: \(L_r = 16\) ms (60 Hz display)

Total: \[L_{\text{total}} = 33 + 20 + 50 + 15 + 16 = 134 \text{ ms}\]

With \(134\) ms \(< 150\) ms, two-way conversation is feasible using RTP/SIP. If we used MQTT (TCP handshake \(\approx 1.5 \times \text{RTT}\)), network latency would be \(75\) ms, pushing total to \(159\) ms, exceeding the threshold and creating awkward conversation delays.

Common Pitfalls

1. Conflating Real-Time with Low-Latency

Real-time means meeting a deadline consistently, not necessarily having the lowest average latency. A system with 50ms latency that always meets its deadline is more ‘real-time’ than one with 10ms average but occasional 500ms spikes.

2. Using MQTT for Hard Real-Time Control

MQTT does not provide timing guarantees — broker processing delays and network jitter make it unsuitable for hard real-time control (motor control, safety systems). Use deterministic protocols like EtherCAT or TSN for hard real-time IoT.

3. Not Testing Protocol Performance Under Full Load

Real-time application protocols perform differently under low vs high message rates. Test protocol latency and jitter at maximum expected message throughput, not just at low load.

Label the Diagram

💻 Code Challenge

Order the Steps

:

44.12 Visual Reference Gallery

Visual: Application Protocols Landscape

IoT Application Protocols showing MQTT, CoAP, HTTP, and AMQP

This comprehensive overview shows how the major IoT application protocols relate to each other, helping guide protocol selection based on device constraints and communication patterns.

Visual: CoAP vs MQTT Comparison

Comparison between CoAP and MQTT protocols

Understanding the fundamental differences between CoAP (RESTful, UDP-based) and MQTT (pub/sub, TCP-based) is essential for selecting the right protocol for specific IoT scenarios.

44.13 Worked Example: Smart Doorbell — Protocol Stack Design with Latency Budget

Scenario: RingView, a video doorbell manufacturer, designs the communication stack for a new 1080p doorbell with two-way audio. When a visitor presses the button, the homeowner’s phone (anywhere on the internet) must show live video and enable conversation within 2 seconds of the button press.

44.13.1 Latency Budget Breakdown

The 2-second end-to-end target must be allocated across every component:

Component	Budget	Protocol	Notes
Button press detection	20 ms	GPIO interrupt	Hardware latency
Push notification to phone	800 ms	MQTT QoS 1 over TCP/TLS	Firebase/APNs cloud routing
Phone app wake + UI render	400 ms	Local	iOS/Android cold start
SIP session setup	200 ms	SIP over TLS (port 5061)	INVITE → 200 OK → ACK
ICE/STUN NAT traversal	300 ms	WebRTC ICE	Worst case with TURN relay
First video frame render	280 ms	RTP/H.264 over UDP	IDR frame + decode
Total	2,000 ms		Meets 2-second target

44.13.2 Protocol Selection: Why Not Just MQTT?

RingView’s first prototype used MQTT for everything — including video streaming. Here is why that failed:

Metric	MQTT (TCP) for Video	RTP (UDP) for Video
Transport	TCP (reliable, ordered)	UDP (best-effort)
Lost packet handling	TCP retransmits — video freezes for 50-200 ms waiting	RTP skips — next frame arrives in 33 ms (30 fps)
Jitter buffer	Not designed for media timing	60 ms adaptive jitter buffer smooths network variation
Measured latency (p95)	380 ms (TCP retransmissions on cellular)	85 ms (UDP with FEC)
Video freeze events/hour	12-18 (each TCP retransmission = freeze)	0-1 (occasional artifact, no freeze)
Audio round-trip (2-way)	420 ms (above 150 ms threshold — conversation awkward)	110 ms (natural conversation)

44.13.3 Bandwidth and Power Analysis

The doorbell runs on a rechargeable 6,800 mAh battery with a 5V solar trickle charger:

Stream	Codec	Bitrate	Daily Usage	Daily Energy
Video (1080p, 30 fps)	H.264 High Profile	2.5 Mbps	45 min/day (avg 15 events x 3 min)	112 mAh
Audio (two-way)	Opus, 16 kHz	32 kbps (up) + 32 kbps (down)	20 min/day	8 mAh
MQTT (notifications + telemetry)	N/A	0.5 kbps average	24 hr keep-alive	15 mAh
Idle (PIR wake, Wi-Fi sleep)	N/A	0	23 hr	48 mAh
Daily total				183 mAh
Battery life				6,800 / 183 = 37 days (without solar)

44.13.4 Security Stack

Every real-time stream must be encrypted — a doorbell transmitting unencrypted video is a surveillance vulnerability:

Layer	Protocol	Key Exchange	Cipher
Signaling	SIP over TLS 1.3 (port 5061)	ECDHE P-256	AES-128-GCM
Media (video + audio)	SRTP (not RTP)	DTLS-SRTP key derivation	AES-128-CTR with HMAC-SHA1
Notifications	MQTT over TLS 1.3 (port 8883)	Certificate pinning	AES-256-GCM

The Hybrid Architecture Lesson

RingView’s production doorbell uses three protocols simultaneously:

1. MQTT (TCP): Push notifications (“Someone is at your door”), device telemetry (battery level, Wi-Fi RSSI), configuration commands. TCP’s reliability is essential — a missed notification means a missed visitor.

2. SIP/SRTP (UDP): Live video and two-way audio. UDP’s “skip lost packets” behavior is essential — a 33 ms video frame arriving 200 ms late is worse than not arriving at all (it causes stutter). The next frame is already more relevant.

3. HTTPS (TCP): Recorded clip upload to cloud storage (30-second pre-roll + event). Reliability matters for recordings — every frame must arrive. TCP’s retransmission overhead is acceptable because recording upload happens in the background after the live session.

The mistake is choosing one protocol for everything. MQTT cannot deliver acceptable live video. RTP cannot guarantee notification delivery. Each protocol serves the task it was designed for.

44.14 Concept Relationships

Understanding how real-time protocols connect to the broader IoT ecosystem helps contextualize their unique role:

Protocol Stack Dependencies:

• Transport Layer: RTP runs over UDP (not TCP), while SIP can use TCP or UDP for signaling. See Transport Fundamentals for UDP vs TCP characteristics.
• Application Layer: Real-time protocols are application-layer protocols, but with fundamentally different design goals than REST/HTTP. See Application Protocols Overview for the full landscape.

Architectural Integration:

• Edge Computing: Real-time stream processing often happens at the edge to meet latency requirements. See Edge-Fog Computing for deployment patterns.
• IoT Reference Models: Real-time protocols typically operate in the communication and data ingestion layers. See IoT Reference Models for architectural context.

Security Integration:

• Encryption: SRTP provides media encryption while TLS/DTLS secures signaling. See Cryptography Fundamentals for encryption principles.
• Authentication: SIP digest authentication and certificate-based auth protect session establishment. See Authentication & Access.

Technology Trade-offs:

• vs MQTT/CoAP: These messaging protocols optimize for reliability and power efficiency, while RTP/SIP optimize for latency and continuity. Neither is “better”—they solve different problems.
• vs WebRTC: WebRTC bundles signaling, NAT traversal, and media in one framework; SIP+RTP separates concerns for flexibility.

Complementary Technologies:

• Codecs: RTP carries encoded media (H.264, H.265, Opus, PCM). Codec choice dramatically affects bandwidth and quality.
• NAT Traversal: STUN/TURN servers enable WebRTC connections across firewalls and symmetric NATs—critical for IoT devices behind home routers.

44.15 See Also

Protocol Deep Dives:

• MQTT Fundamentals - Compare pub/sub messaging with real-time streaming
• CoAP Fundamentals - RESTful IoT protocol for sensor data (not streaming)
• HTTP/REST for IoT - Request-response patterns vs streaming

Network Foundations:

• Transport Layer Protocols - UDP characteristics essential for RTP
• Network Performance Metrics - Latency, jitter, and packet loss analysis

Architecture Patterns:

• M2M Communication - Device-to-device streaming scenarios
• Protocol Selection Framework - Decision trees for choosing between protocols

Security Considerations:

• IoT Security Fundamentals - Threat models for video/audio streams
• End-to-End Encryption - zRTP and DTLS-SRTP key exchange

Industrial Applications:

• OPC-UA - Industrial real-time data exchange (different use case)
• WirelessHART - Industrial wireless with timing guarantees

Research and Standards:

• RFC 3550 (RTP/RTCP) - Core real-time transport protocol specification
• RFC 3261 (SIP) - Session Initiation Protocol specification
• RFC 3711 (SRTP) - Secure Real-time Transport Protocol
• WebRTC Working Group - IETF standards for browser-based real-time communication

🔗 Match the Concepts

44.16 Summary

This chapter covered real-time protocols for IoT audio and video applications - the protocols that power video doorbells, baby monitors, smart intercoms, and voice assistants:

44.16.1 Key Concepts Covered

1. The Fundamental Trade-off: Real-time protocols prioritize latency over reliability. They run over UDP, skip lost packets rather than retransmit, and target <150ms end-to-end delay for acceptable human interaction.

2. Protocol Stack for Real-Time IoT:

   • SIP (Session Initiation Protocol) - Session control (call setup/teardown)
   • RTP (Real-time Transport Protocol) - Media stream delivery over UDP
   • SRTP - Encrypted media for privacy (ALWAYS use for internet-facing devices)
   • WebRTC - Browser-native real-time communication

3. When to Use Real-Time vs Messaging Protocols:

   Use RTP/SIP/WebRTC	Use MQTT/CoAP
   Continuous audio/video streams	Discrete sensor readings
   Two-way voice/video calls	Commands and telemetry
   Latency-critical (<150ms)	Latency-tolerant (seconds OK)
   High bandwidth (64kbps-2Mbps)	Low bandwidth (bytes-KB)

4. Security Requirements:

   • Always use SRTP (not plain RTP) for media encryption
   • Use TLS/port 5061 for SIP signaling (not port 5060)
   • Implement zRTP for end-to-end encryption
   • Never use default credentials

5. Hybrid Architectures Are Common: Smart doorbells use MQTT for notifications AND RTP for live streaming - the best protocol for each task.

44.16.2 The 150ms Rule

Human conversation becomes awkward when one-way end-to-end delay exceeds 150 milliseconds (ITU-T G.114). This is why real-time IoT devices use UDP-based protocols (no TCP handshake overhead) and specialized media protocols designed for timing, not guaranteed delivery.

44.17 What’s Next?

Chapter	Focus	Why Read It
Application Protocols Overview	Full landscape of IoT application protocols	Understand where RTP/SIP fits among MQTT, CoAP, HTTP, and AMQP in a complete protocol taxonomy
MQTT Fundamentals	Publish-subscribe messaging for sensor data	Compare guaranteed-delivery MQTT with the latency-first RTP approach used in this chapter
CoAP Fundamentals	Lightweight RESTful protocol over UDP	Explore the other major UDP-based IoT protocol, optimised for constrained devices rather than streaming
Transport Layer Protocols	UDP vs TCP characteristics in depth	Build the network-layer understanding needed to diagnose RTP jitter and packet-loss problems
IoT Security Fundamentals	Threat models for connected devices	Apply security thinking to video doorbells and baby monitors after learning SRTP/zRTP in this chapter
Edge-Fog Computing	Processing at the network edge	Learn how to place media transcoding and jitter-buffer logic at the edge to reduce end-to-end latency