2.0 KiB
2.0 KiB
name, description, disable-model-invocation
| name | description | disable-model-invocation |
|---|---|---|
| rtp-networking | Guidelines for RTP/UDP transport, signaling, discovery, NAT traversal, and encryption in the screen_cast project. | false |
rtp-networking
Guidelines for RTP/UDP transport, signaling, discovery, NAT traversal, and
encryption in the screen_cast project.
Scope
Use this skill for:
- RTP packetization, depacketization, and sequencing.
- UDP socket I/O and async event loops.
- Peer discovery (mDNS/DNS-SD).
- Session signaling and control channels.
- Optional SRTP/DTLS or ICE-lite/NAT traversal.
Transport
- Default transport is RTP over IPv4/IPv6 UDP.
- Use a small, project-specific RTP header parser/serializer (12-byte base header plus extensions if needed).
- Fragment large NAL units across RTP packets using FU-A fragmentation for H.264.
Resilience
- Start without retransmission; add NACK / PLI once the baseline path works.
- Keep a jitter buffer on the receiver to absorb network jitter without adding excessive latency.
- Sequence numbers drive depacketization; detect loss and request key frames on large gaps.
Discovery
- Use Avahi (
avahi-client) for mDNS/DNS-SD service announcements. - Service name example:
_screencast._tcpfor signaling,_screencast-rtp._udpfor media.
Signaling
- Control channel is JSON over WebSocket or plain TCP.
- Negotiate at least: codec, resolution, frame rate, UDP endpoints, session ID.
- Keep signaling independent of media transport so either can evolve.
Security (future)
- SRTP key exchange via DTLS or pre-shared keys over the signaling channel.
- Do not hardcode keys; rotate per session.
Async I/O
- Prefer an existing event loop library (e.g.
asio,libuv) over raw threads andselect(). - Keep network and capture threads separated with lock-free queues where practical.
References
- RFC 3550 (RTP), RFC 6184 (H.264 RTP payload)
- Avahi client documentation
docs/ARCHITECTURE.mddocs/PHASES.md