I am having issues with OpenAI Realtime models during incoming SIP calls. For some reason, the voice is very slow. If I listen to the call recordings, everything sounds fine. It also works normally via the web. But there is a problem via SIP. If we choose any other model, there are no audio issues. Example calls: 019cb369-dfd4-7000-80a4-0c145d0fe6bd 019cb3ca-a40c-7eef-9569-58d1875e20a0 https://cdn.discordapp.com/attachments/1478378443686281350/1478378444319625367/IMG_5368.png?ex=69a82eb8&is=69a6dd38&hm=678b7a760d7db8d9e67e5bbacc948d7689ecd46ea14eee2e862c5bcebaf8a923& https://cdn.discordapp.com/attachments/1478378443686281350/1478378444600512642/019cb3ca-a099-7a76-894a-4195c60d123a.wav?ex=69a82eb8&is=69a6dd38&hm=321c2eea0e8b7fb2041cb1aada14bd8a17ae874905744ee0277f1ec21ee722e9&

I can help with this. It sounds like a SIP codec / sample rate or transcoding mismatch with the Realtime model. I’ve seen slow voice issues before when RTP settings or audio buffering aren’t aligned properly. If you can share your SIP provider, codec (PCMU/PCMA/Opus?), and how you’re streaming audio to OpenAI, I’ll take a look and pinpoint it quickly. @Roman

We are our own provider. From the traffic, we can see that your server responds that it only supports PCMU (ulaw). This codec is then used for RTP. We have other providers with the same codec and have no issues with them. Moreover, if we select a different model (not realtime) for the agent, everything works fine even with ulaw. The only issue is selecting realtime.

Hi, Root cause: The audio pipeline was running at 24kHz (OpenAI Realtime’s native rate) even for SIP phone calls that require 8kHz PCMU, which caused the audio to play at a very slow speed. This happened due to two issues: 1.

sampleRateGet()

returned 24000 for S2S models before checking if the call was a phone call. 2. The S2S pipeline skipped the sample rate converter, so no transcoding occurred. Fix: The sample rate logic has been reordered so phone calls use the correct pipeline rate, and a sample rate converter was added to the S2S audio pipeline. Regression tests were also added. Best regards, Oshi Raghav Customer Support Team | Vapi

Hi Oshi, Having the same problem in our enviroment. CallID: 019cf620-f504-7776-a4be-fb54786f0122 + pcap log attached (testing acc, production will run on different org id) Our Twilio → Vapi SIP trunk setup (IE1/Dublin) is now stable and calls are accepted consistently. However, we still notice different audio behavior when using GPT Realtime assistants compared to non-realtime assistants. - SIP negotiation looks correct (PCMU / 8kHz). - Non-realtime assistants work normally. - Realtime assistants produce slow or distorted audio, similar to the earlier sample-rate mismatch you described. Could you please clarify: 1) Is the 24kHz → 8kHz phone-call sample-rate fix already deployed for our account/workspace, or is it still being rolled out? 2) Does this need to be enabled/configured per user/workspace, or is it planned to work globally for all SIP phone calls? 3) Is there anything we need to configure on our side to ensure realtime models work correctly with SIP/PSTN calls? 4) Is this fix specific to Twilio integrations, or does it apply globally to all SIP trunk providers? Thank you 🙂 https://cdn.discordapp.com/attachments/1478378443686281350/1483050189571752027/019cf620-f504-7776-a4be-fb54786f0122-1773655890416-a3f08354-949e-41d3-b9fc-45fe51b81a98-sip.pcap?ex=69cc4b5e&is=69caf9de&hm=6710818ee6891d785b31cde45928c489ca2d9c118c05f041c3f7b20b902853b8&

Hi, Apologies for the delay. We are still looking into the issue and will share an update with you as soon as possible. Thank you for your patience and cooperation, we truly appreciate it. Warm regards, Oshi Raghav Customer Support Team Vapi

Hi Oshi, thank you for info. We have some clients integrated with basic phone number so there is no problem, but we are now building assistants for bigger clients with SIP integration and the realtime models is crucial in improving our services, as we build the assistants in czech and other eu languages. Do you have any timeline to solve this issue, so we can plan the realtime model for SIP integration? Thank you very much.

Hi, I’ve handled similar setups. This looks like the 24kHz → 8kHz fix not fully applied yet for realtime. • Usually rolled out per workspace (not user) • No major config needed, just keep PCMU (8kHz) end-to-end • Not Twilio-specific — affects all SIP/PSTN Happy to help you test and fix it @honza.r

Hi @Adam Thank you for reaching out. Yes based on logs it seems like thats the issue. If you can help me fix this, I will be glad to connect with you.

Sure I can help you fix Send me a message @honza.r