Struct Registry 

pub struct Registry { /* private fields */ }

Collects interceptors and assembles them into a chain.

Order

Every interceptor is added at a Slot, and build sorts by it. A slot is a distance from the wire: the smallest is closest to the network, the largest closest to the application. Read walks that order, write walks it in reverse, so one list serves both directions and “closest to the wire” means one thing rather than opposite things per direction.

Registry::new()
    .with(Slot::TwccSender, a)     // 2_000: closest to the wire
    .with(Slot::NackGenerator, b)  // 7_000
    .with(Slot::JitterBuffer, c)   // 13_000: closest to the application
    .build()

read:   a → b → c → application
write:  application → c → b → a → wire

Declaring the position rather than relying on call order is what makes the helpers in rtc composable: configure_twcc places interceptors at 2_000 and 8_000, configure_nack at 4_000 and 7_000, and the two interleave correctly however the caller sequences them. With order taken from insertion, calling them in either sequence produced a chain that was wrong in a different way each time, and nothing caught it — the nested registry that preceded this added innermost first, so register_default_interceptors assembled TWCC receiver → RTCP reports → NACK generator, the reverse of what the chain contract documented.

A slot holds one interceptor. Two of your own go at two custom positions — the named slots are spaced a thousand apart so there is room between any two of them.

Example

use rtc_interceptor::{NackGeneratorBuilder, Registry, Slot, TwccSenderBuilder};

let chain = Registry::new()
    .with(Slot::TwccSender, TwccSenderBuilder::new().build())        // closest to the wire
    .with(Slot::NackGenerator, NackGeneratorBuilder::new().build())  // sees arrivals after it
    .build();                                                        // terminus appended here

Implementations

impl Registry

pub fn new() -> Self

An empty registry.

pub fn with<T: Interceptor + 'static>(self, slot: Slot, interceptor: T) -> Self

Add an interceptor at slot.

Call order does not matter: the slot decides the position. A slot holds one interceptor, so adding a second at the same position replaces the first and says so in the log.

pub fn slots(&self) -> Vec<(Slot, String)>

What this registry holds, wire-to-application: each interceptor’s slot and its type name, in the order build will compose them.

Present so a caller assembling a chain from several helpers can assert what it got. Each helper places interceptors at its own landmarks and none of them sees the whole, so the composition is precisely the thing no single helper can check.

pub fn build(self) -> impl Interceptor

Assemble the interceptor chain.

NoopInterceptor is appended last, so every chain ends the inbound RTCP path. That is a property of a chain rather than something a caller opts into: left out, an application would get a stream of control traffic it never asked for, and the omission would look like working code.

What gets past it is decided per packet, by an interceptor attaching Attribute::DeliverToApplication to the ones it vouches for — the component that knows which packets an application can act on is the one that makes the call, rather than a switch here that could only say “all of it or none”.

Trait Implementations

impl Default for Registry

fn default() -> Registry

Returns the “default value” for a type.