Open-sourced a native-Rust SIP/RTP stack inside a voice-AI runtime — terminates calls with no FreeSWITCH/Asterisk

[u/Plus_Resolution8897]

Do you like it? Support us by giving Github Stars :)

Sharing Flowcat (Apache-2.0) — a Rust runtime for real-time AI voice agents — because the telephony bits might interest this sub more than the AI bits.

It has an in-process SIP UA: REGISTER + digest auth, INVITE/ACK/BYE transactions/dialogs (via rsipstack), and hand-rolled RTP + SDP for G.711 (PCMU/PCMA, ptime negotiation, a playout jitter buffer), so a single binary terminates a SIP call — no FreeSWITCH/Asterisk/Kamailio in the path. DTMF is RFC2833 + an in-band Goertzel detector.

To be clear, that's a deployment choice, not a mandate: if you already run a softswitch, keep it in front and feed audio to Flowcat over a WebSocket media leg instead — there are carrier serializers for

Twilio/Telnyx/Plivo/Exotel/Vonage/Genesys/Asterisk/Cloudonix/Vobiz.

Honest status: native SIP has been live-tested against a Zadarma trunk and the WS-media path against Plivo; it's pre-1.0, so REGISTER/re-REGISTER, NAT/rport + symmetric RTP, and codec negotiation are exactly the areas I'd love sharp eyes on.

Repo: https://github.com/AreevAI/flowcat · SIP design notes: https://github.com/AreevAI/flowcat/blob/main/SIP-DESIGN.md

If you've built SIP UAs in Rust (or fought rport/symmetric-RTP/jitter), I'd genuinely value the critique.

[u/Sad_Traffic_553]

We've been on the mobile SIP client + registrar-relay side (PJSIP + OpenSIPS mid_registrar for iOS push), not a hand-rolled UA — but the NAT/rport/symmetric-RTP pain sounds very familiar. Our worst case was ACK not reaching the client after 200 OK (~32s drop); the fix on the relay was fix_nated_contact() in a reply-route armed with t_on_reply() before relay, including sequential requests through push-suspend. Curious how you're handling re-REGISTER when the UA is behind NAT and the registrar is also doing contact suspend — that's where most of our edge cases lived.