家庭树莓派Zero对讲系统：RTP与WebRTC协议选型咨询

Short Answer Up Front #

Given your specific setup (known LAN IPs, identical hardware/codecs, low-power Pi Zeros, multi-device needs), pure RTP is the better choice — it’s lighter on resources, natively supports multicast, and avoids unnecessary WebRTC overhead you don’t need.

Breakdown of Your Questions #

1. WebRTC vs Pure RTP: Are There Any Advantages For Your Use Case?

Your understanding is spot-on: WebRTC’s main value adds are NAT traversal (ICE), session negotiation (SDP), and secure media (SRTP). None of these are useful for your scenario:

• ICE is designed for connecting devices across the internet through firewalls/NATs — irrelevant in a trusted LAN where you already know all IPs.
• SDP handles codec/feature negotiation, but your devices are identical, so you can hardcode the codec (e.g., OPUS) and skip all negotiation overhead.
• SRTP encryption is optional in WebRTC, but even if you disable it, WebRTC still carries extra session management logic that adds CPU load on Pi Zeros.

Pure RTP, on the other hand, is a minimal, lightweight protocol with no extra baggage. It will use significantly less CPU and memory on your Pi Zeros, which is critical for maintaining smooth audio without lag.

2. Multicast Support

You’re correct here too:

• Pure RTP natively supports multicast: You can send a single RTP stream to a multicast IP (e.g., 224.0.0.1), and all Pi Zeros on the LAN can subscribe to that address. No need for multiple peer-to-peer connections — this is perfect for multi-device intercoms where everyone needs to hear everyone else.
• WebRTC does NOT support multicast natively: It’s designed for 1:1 or 1:many via a Selective Forwarding Unit (SFU). Without an SFU, you’d have to establish n*(n-1)/2 P2P connections between every pair of devices, which would cripple the Pi Zeros’ limited resources. Even with an SFU, you’d add another device to manage, which complicates things.

3. Audio Mixing

Neither RTP nor WebRTC natively handle audio mixing — they’re just transport protocols. Mixing is an application-layer task you’ll need to implement yourself:

• For a multi-device intercom, you’d typically have one central device (or let each device handle it) that receives RTP streams from all other devices, decodes the audio samples, mixes them together (combining multiple audio channels into one), re-encodes the mixed audio, and sends it out (either via multicast or to individual devices).
• You can use lightweight audio libraries like portaudio for capturing/playing back audio, and libopus for encoding/decoding (OPUS is ideal for low-power devices due to its efficiency).

Practical Tips for Your Setup #

• Stick to a lightweight RTP library like librtp or even roll your own minimal implementation (since you don’t need negotiation or error correction beyond basic RTP sequencing).
• Use the OPUS codec — it’s optimized for low bitrates, low CPU usage, and excellent speech quality, which is perfect for intercoms.
• Enable multicast on your LAN (most home routers allow this by default, but double-check if you run into issues).

内容的提问来源于stack exchange，提问作者Reese