if i want to have 2 different numbers using telnyx, should i create 2 different sip trunks?

Thanks for reaching out, fernando. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

what are the pros and cons of having two different sip trunks?

Thanks — I’m responding to your question about the pros and cons of creating two separate SIP trunks for two different Telnyx numbers. Summary answer • You do not have to create two trunks: LiveKit supports multiple phone numbers on a single inbound SIP trunk. • Create separate trunks when you need different behavior, security, or processing per number. Keep one trunk when both numbers share the same routing, access, and audio settings. Pros of using two separate SIP trunks • Independent routing: Each trunk can have its own dispatch rules, so you can route Number A differently than Number B (different IVRs, rooms, webhooks, etc.). • Per-trunk audio/processing settings: You can enable or disable things like Krisp noise cancellation per trunk, so each number can have different audio handling. • Separate access controls: Each trunk can have its own

allowed_addresses

or credentials, letting you lock down which IPs or credentials can use each number. • Isolation/resilience for configuration changes: Misconfiguring one trunk won’t affect the other, which is useful during testing or staged rollouts. • Clear separation for monitoring or billing: Easier to track usage, logs, and metrics per trunk (helpful for analytics or chargeback). Cons of using two separate SIP trunks • More management overhead: You’ll need to create, maintain, and monitor two trunks (credentials, whitelists, settings). • Potential duplication of configuration: If both numbers should behave the same, you’ll repeat rules and settings across trunks. • Slightly more API/workflow steps: Creating and updating two trunks requires additional API calls and operational tasks. • Inconsistent settings risk: Different trunks can drift in configuration (e.g., one has Krisp on and the other off), which may complicate troubleshooting. When to use a single trunk instead • Both numbers share the same routing and processing needs. • You prefer simpler management and a single place to update settings. • You don’t need distinct IP restrictions or per-number isolation. Quick checklist to decide • Do the numbers need different dispatch/routing? If yes → consider separate trunks. • Do they need different audio processing (Krisp) or security settings? If yes → separate trunks. • Do you want minimal operational overhead and the same behavior for both numbers? If yes → single trunk. If you want, I can: • Show the API/SDK snippet for adding multiple numbers to one

SIPInboundTrunkInfo

. • Outline how to set up separate dispatch rules for two trunks. • Suggest checks to perform in Telnyx (if you control that account) to confirm whether they require any per-number trunking on their side. Which of those would help you next? Sources: sip | livekit/livekit_composite | DeepWiki | Creating SIP Inbound Trunks and Dispatch Rules with Python SDK | Agents telephony integration | LiveKit Documentation, with interactive elements

one number is to make MX calls and the other is to make calls to CO

Thanks — you mentioned one number will make calls to Mexico (MX) and the other to Colorado (CO). I’ll explain the practical tradeoffs and give a recommendation based on that use case, plus next steps you can take. Short recommendation • Use two separate SIP trunks if you want strict separation of routing, security, or audio settings per destination (MX vs CO). • Use one SIP trunk with per-number routing rules if both numbers share the same security and audio needs and you prefer simpler management. Why you’d choose two trunks (recommended when destinations differ) • Clear routing separation: Each trunk can have its own dispatch rules so calls from the MX number always follow MX-specific routes (SIP gateway, PSTN provider settings, or dialplans) while the CO number follows CO routes. This is the simplest way to guarantee per-number destination behavior. • Per-trunk audio/processing: If calls to MX require different audio processing (e.g., codec preferences or Krisp on/off), separate trunks let you set that independently. • Distinct access control: You can restrict different IPs or credentials to each trunk (useful if different teams or gateways handle MX vs CO). • Simpler troubleshooting & monitoring: Logs, metrics, and billing are isolated by trunk, making it easier to attribute issues or costs to MX vs CO traffic. • Configuration safety: Changes to one trunk won’t accidentally impact the other—useful for staged rollouts or provider testing. Why you might use one trunk with multiple numbers • Simpler management: One trunk to manage credentials, whitelists, and global settings. • Less duplication: If routing logic is simple and both numbers largely behave the same, one trunk reduces setup overhead. • Works well if the provider handles per-number routing: If Telnyx already routes based on number and you don’t need LiveKit-level dispatch differences, a single trunk is fine. Practical considerations specific to MX vs CO • Regulatory/compliance or provider routing differences sometimes apply between international (MX) and domestic (CO) calls. If your telco or Telnyx requires different origination/termination setups, separate trunks avoid conflicts. • Latency, codec choices, or carrier availability to MX destinations might differ—separate trunks let you optimize per-destination. • If you expect differing volumes (e.g., many more MX calls), separate trunks let you allocate capacity or scale independently. Next steps I can help with • Show an example API/SDK snippet to configure two trunks in LiveKit and set dispatch rules for each trunk. • Show how to add both numbers to one inbound trunk and create per-number dispatch rules (if you prefer one trunk). • Suggest what to check in Telnyx (e.g., whether they require separate trunks per country or per DID) to confirm provider-side constraints. Which approach do you prefer—strict separation (two trunks) or simpler management (single trunk)? I can then give the exact setup steps for that option. , with interactive elements