mirror of
https://github.com/suitenumerique/meet.git
synced 2026-07-28 04:39:16 +00:00
lebaudantoine
988e5aa256
Implemented a service that automatically creates a SIP dispatch rule when the first WebRTC participant joins a room and removes it when the room becomes empty. Why? I don’t want a SIP participant to join an empty room. The PIN code could be easily leaked, and there is currently no lobby mechanism available for SIP participants. A WebRTC participant is still required to create a room. This behavior is inspired by a proprietary tool. The service uses LiveKit’s webhook notification system to react to room lifecycle events. This is a naive implementation that currently supports only a single SIP trunk and will require refactoring to support multiple trunks. When no trunk is specified, rules are created by default on a fallback trunk. @rouja wrote a minimal Helm chart for LiveKit SIP with Asterisk, which couldn’t be versioned yet due to embedded credentials. I deployed it locally and successfully tested the integration with a remote OVH SIP trunk. One point to note: LiveKit lacks advanced filtering capabilities when listing dispatch rules. Their recommendation is to fetch all rules and filter them within your backend logic. I’ve opened a feature request asking for at least the ability to filter dispatch rules by room, since filtering by trunk is already supported, room-based filtering feels like a natural addition. Until there's an update, I prefer to keep the implementation simple. It works well at our current scale, and can be refactored when higher load or multi-trunk support becomes necessary. While caching dispatch rule IDs could be a performance optimization, I feel it would be premature and potentially error-prone due to the complexity of invalidation. If performance becomes an issue, I’ll consider introducing caching at that point. To handle the edge case where multiple dispatch rules with different PIN codes are present, the service performs an extensive cleanup during room creation to ensure SIP routing remains clean and predictable. This edge case should not happen. In the 'delete_dispatch_rule' if deleting one rule fails, method would exit without deleting the other rules. It's okay IMO for a first iteration. If multiple dispatch rules are often found for room, I would enhance this part.