Feature Requests

Hi Team, Thank you for the guide. I have reviewed the documentation, but the issue persists. As requested, here are the specific details regarding the outbound call failures: Call IDs: 019cd28e-ee73-7dc0-8774-4b33fce4c815 019cd271-dbe2-7580-b7e7-1e0cc8f879d5 019cd241-38ca-7140-abfc-db2dd09afb6d Error Details: Error: call.in -progress.error-providerfault-outbound-sip-403-forbidden Direction: Outbound only Behavior: Every outbound call results in a SIP 403 Forbidden error. This is generated by Vapi's SBC before any SIP INVITE reaches Twilio; there is zero SIP traffic in the Twilio logs, notifications, or Monitor events. Vapi Resources: Credential: 713f5ca1-f791-43bb-8a8b-030d3c75909b BYO Phone: 1f47d073-a346-406e-96d0-b27974c8aaa1 Twilio Trunk: TKe6276e2bb66438f3f3c2d82e554397d4 Configurations Tested (All failed with the same 403 error): IP ACL authentication only (Vapi SBC IPs: 44.229.228.186, 44.238.177.138) Credential List authentication only (digest auth) Combined IP ACL and Credential List Wide-open IP ACL (0.0.0.0/1 + 128.0.0.0/1) No authentication Direct IP gateway instead of trunk URI Exact format from Vapi documentation (no auth plan) New credentials and phone numbers Recent Changes: None. This setup has not worked since the initial configuration. Please let me know if you need any further information to resolve this. Best regards, Evan

Right now when I go on the vapi website and I try to sign up on my phone and I sign in with my google account I cannot get past the first question asking me how I heard about vapi.

I would love the ability to define custom variables in my squads which are then available to my assistants. This would give me the ability to define an assistant once and reuse it in multiple squads with different purposes, such as creating a customer service agent that can handle calls for different websites.

Hi, could we please have the option to send traces to PostHog's LLM Analytics: https://posthog.com/docs/llm-analytics/start-here

Like how the webhook url can be connected to the tool, can connect to the structured data would helpful and easier to extract the data

EXECUTIVE SUMMARY: Vapi's current platform architecture presents two fundamental barriers preventing production use with Brazilian SIP carriers: (1) inflexible SBC codec management and (2) unacceptable latency profiles for real-time voice applications in Brazil. ORG ID: f6c41da6-9df8-429c-bbae-18f0e815ca54 CREDENTIAL ID: 7ae953f8-158b-47b0-a071-4f8fa40365ce TARGET CARRIER: DirectCall (189.84.133.111) - Representative of Brazilian market ================================================================================ PROBLEM 1: SBC CODEC INFLEXIBILITY - PLATFORM DESIGN GAP ================================================================================ CURRENT STATE: • No API-exposed codec filtering for BYO SIP trunks • SBC layer enforces hardcoded SDP offers including Opus/G722 • Requires manual engineering intervention per trunk WHY THIS BREAKS IN BRAZIL: • Brazilian carriers (DirectCall, Algar, Vivo, Claro, Oi) DO NOT implement RFC-compliant codec negotiation • Market standard: Hard reject (SIP 603) on any unsupported codec in SDP • Result: 100% call failure rate with zero fallback mechanism ARCHITECTURAL GAP: US/EU Approach: Offer multiple codecs → Carrier selects → Negotiation succeeds Brazil Reality: Offer wrong codec → Immediate reject → Call fails PLATFORM IMPACT: Vapi's "unified global API" promise fails in Brazil. Each carrier requires manual SBC configuration, making the platform non-viable for: • Multi-carrier deployments • Rapid carrier switching • Self-service trunk management ================================================================================ PROBLEM 2: LATENCY - REAL-TIME VOICE QUALITY COMPROMISED ================================================================================ OBSERVED METRICS: [Insira aqui suas medições específicas, ex:] • Vapi SBC → DirectCall: ~180-220ms RTT • Media path sub-optimal routing through US/EU POPs • Jitter buffer underruns during peak hours REQUIREMENT BREACH: • ITU-T G.114 recommends <150ms one-way for toll-quality voice • Brazilian regulatory framework (Anatel) emphasizes local infrastructure • Customer experience degradation: perceptible delay, talk-over issues ROOT CAUSE: Absence of Brazil-based SBC/media POPs forces hairpinning through North American or European infrastructure before reaching local carriers. ================================================================================ BUSINESS IMPACT ASSESSMENT ================================================================================ CURRENT STATE: Platform UNUSABLE for Brazilian production workloads BLOCKING FACTORS: □ Cannot complete basic SIP registration with major carriers without manual engineering escalation □ No self-service path to resolve codec mismatches □ Voice quality below acceptable thresholds for B2B/B2C applications □ No timeline provided for Brazil-local infrastructure COMPETITIVE DISADVANTAGE: Local providers (TotalVoice, DirectCall, Nvoip) and regional cloud communications platforms (Twilio with local POPs) offer: • Native G711/G729-only SDP handling • <50ms latency to local carriers • Anatel-compliant infrastructure ================================================================================ REQUIRED SOLUTIONS ================================================================================ IMMEDIATE (30 days): Expose codec filtering in Credential API (sbcConfiguration.codecs) Provide Brazil-based SBC POPs or direct carrier interconnections Document Brazilian carrier compatibility matrix STRATEGIC (90 days): Anatel-compliant infrastructure deployment in São Paulo Pre-certified carrier integrations (DirectCall, Algar, Vivo Empresas) Latency SLAs for Brazilian territory ================================================================================ ALTERNATIVE RECOMMENDATION ================================================================================ If above timeline not feasible, we request: • Formal acknowledgment of Brazil market limitations • Roadmap disclosure for LATAM infrastructure • Early access program for local POP beta testing Without concrete commitment to Brazil-specific architecture investments, we will be forced to migrate to alternative platforms with local presence. ================================================================================ CONTACT: netoxp70@gmail.com AVAILABILITY: Available for technical architecture discussion with Product/Engineering leadership. ATTACHMENTS: [PCAP files, latency logs, carrier rejection logs]

When an assistant has tools attached, Chat Test Suites fail to capture the assistant’s reply in the transcript. Removing the tool immediately restores normal behavior - (User and AI both showed in the transcript).

I'd love to have the option for a transfer tool like the TwiML warm handoff but with an LLM-generated summary available as a variable like the other warm handoff options. My use case is my transfer number has an IVR that speaks while it finds someone available to pick up the phone, so the "wait and then say" options don't work; they get triggered by the IVR. I'd love to be able to wait for someone on the other end to hit a DTMF key (looping a Say prompt) and then say the summary after that.