Skip to content
Contact us
  • There are no suggestions because the search field is empty.

Known Issue: Brevity Blocked by Corporate Firewall / Web Filter

Summary

Some users are unable to connect to role plays, see live transcription, or have conversations save correctly when Brevity is accessed on a corporate network.

In most cases, this is caused by your firewall or web content filter blocking our real‑time AI service at api.openai.com.

If your organization cannot allowlist OpenAI immediately, you can be unblocked right away by switching your speech‑to‑text (STT) provider to Deepgram. This will:

  • Restore the ability to practice in Brevity

  • Allow you to continue training while your IT team works on allowlisting OpenAI

You will notice a difference in latency and voice realism when using Deepgram, but it will provide a functional workaround.

Impact

When the required services are blocked, you may see:

  • Role play sessions failing to connect or timing out

  • No live transcription appearing during a session

  • Conversations not being saved or appearing incomplete

This is most commonly due to OpenAI real‑time traffic being blocked during role play recording if Open AI Realtime is the selected speech-to-text service provider.

Root Cause

Brevity relies on several third‑party, secure services to:

  • Capture and transcribe trainee speech in real time

  • Upload and save role play video recordings

Many corporate networks require explicit allowlisting for these outbound connections. When these endpoints are blocked, Brevity’s real‑time and/or upload functionality is interrupted.

The most frequent blocker is:

  • api.openai.com (real‑time AI connection)

 

Immediate Workaround: Switch STT Provider to Deepgram

If your IT/security team cannot allowlist OpenAI right away:

  1. Request to change your Brevity STT provider to Deepgram.

  2. Once switched:

    • You should be able to connect to role plays again.

    • Transcription and practice will resume even if OpenAI is still blocked.

    • You may observe:

      • Changes in latency (how quickly responses appear)

      • Changes in voice realism compared to the OpenAI experience

  3. In parallel, your IT team can work on properly allowlisting OpenAI so you can return to the full real‑time experience when ready.

Required Allowlisting for Real‑Time Transcription and Response Generation

To prevent real‑time connectivity and transcription issues, IT teams should allowlist these domains:

Real‑time transcription / AI endpoints:

  • streaming.assemblyai.com

  • *.livekit.cloud

  • wss://*.livekit.cloud

  • *.brevitypitch.com

  • api.openai.com ← most commonly blocked

If any of these are blocked:

  • Role play sessions may fail to connect

  • Speech may not be transcribed

  • Conversations may not be saved correctly

WebRTC Network Requirements

Brevity's role-play feature uses WebRTC to carry real-time audio between the user's browser and our AI voice services (LiveKit Cloud and OpenAI Realtime). WebRTC is a peer-to-peer protocol, which means allowlisting hostnames alone is not enough — your firewall also has to permit the underlying network traffic that WebRTC uses to negotiate and stream audio. This is the most common reason role-play sessions fail silently on managed corporate networks: the domain allowlist looks correct, but the call never establishes because the browser cannot complete its connectivity checks.

To ensure WebRTC works end-to-end, your network team should permit the following outbound traffic from end-user devices:

  • UDP 3478 and UDP 5349 — the standard ports used by STUN and TURN servers. WebRTC clients use STUN to discover their public-facing IP address and port, and TURN to relay media when a direct peer connection is not possible. Blocking these ports prevents the browser from gathering ICE candidates, which causes the session to fail before any audio is exchanged.
  • UDP 19302, outbound to stun.l.google.com and stun1.l.google.com — Google's public STUN servers, used specifically by Brevity's OpenAI Realtime voice path. These are the same STUN servers used by Google Meet and many other WebRTC products, and they are reachable from the open internet by design.
  • UDP 49152–65535, outbound to any destination — the IANA-registered ephemeral port range that carries the actual audio media stream once the WebRTC connection is established. If this range is blocked or heavily restricted, the browser will either fail to establish a media path entirely, or fall back to a high-latency TCP relay that degrades voice quality.
  • TCP 443, outbound to *.livekit.cloud and api.openai.com  — already covered by the domain allowlist above, but worth calling out here because it serves a second purpose: when outbound UDP is unavailable, WebRTC will fall back to TURN-over-TLS on TCP 443, allowing role-play to keep working (with higher latency) on networks that block UDP entirely.

If any of the above are restricted, you will typically see symptoms like role-play sessions that load successfully but never produce audio, sessions that disconnect within seconds of starting, or transcription that appears to work while the AI voice is silent. If you suspect a WebRTC-related block, the fastest diagnostic is to have an affected user open https://test.webrtc.org on the same network — the report will identify exactly which step of WebRTC negotiation is being prevented.

Additional Troubleshooting: Video Uploads

If transcription is working but video uploads are failing, your IT team may also need to allowlist:

  • *.s3.*.amazonaws.com

  • *.s3.amazonaws.com

If blocked:

  • Role play videos may not upload

  • Sessions may not save or may appear without video

Tip for IT: Prioritize the real‑time transcription endpoints first. Only add the video upload endpoints if users report that uploads are failing while transcription is already working.

Guidance for IT / Security Teams

Please:

  • Allowlist the domains above in your firewall and web content filtering tools.

  • Check network logs for blocked or denied outbound requests to:

    • api.openai.com

    • streaming.assemblyai.com

    • The *.s3.*.amazonaws.com endpoints (if upload issues occur)

These services use encrypted, outbound HTTPS traffic and are required for Brevity to function as designed.

Need Help?

If your IT or security team has questions about:

  • Traffic patterns or destinations

  • Encryption and data flow

  • Which endpoints are required for which features

Please contact your Brevity Customer Success Manager. We can coordinate directly with your security team to review requirements and help them safely allowlist the necessary services.