Struct RtpServer 

pub struct RtpServer;

RTP server that generates/answers media streams under LLM control.

Implementations

impl RtpServer

pub async fn spawn_with_llm_actions( listen_addr: SocketAddr, llm_client: OllamaClient, app_state: Arc<AppState>, status_tx: UnboundedSender<String>, server_id: ServerId, cfg: RtpConfig, ) -> Result<SocketAddr>

Spawn the RTP server. Awaits the socket bind so a failure is reported to server_startup as Err, and registers the accept loop so stop_server can abort it.

pub async fn configured_handler_kind( state: &AppState, server_id: ServerId, event_type_id: &str, ) -> Option<&'static str>

What the configuration says would answer this event. Diagnostics only.

This must never decide whether the budget applies, and it used to. A Script rule reads as “answers in-process, costs no model call” right up until execute_script_handler returns FallbackToLlm — python3 not installed, an unknown language name, or a script that threw — and by then the gate had been skipped on the strength of the rule merely existing. call_llm then dispatched the same handler itself, watched it decline, and consulted the model uncharged. On a 50 pps stream that is 50 uncounted consultations a second with llm_max_per_minute inert, and each one can authorize up to 30 seconds of outbound media.

Self::handle_datagram therefore runs the handler and branches on its answer, the way tuntap::handle_frame does. What is left for this function is the one thing the answer cannot express: that a rule was configured and did not answer, which in the log is otherwise indistinguishable from no rule at all.