BRTC FAQs
1. Why isn't my Endpoint eligible to be connected yet?
An Endpoint isn't eligible to be <Connect>ed to until it has actually started publishing audio. Registering an Endpoint and receiving a token isn't enough on its own — the device using that Endpoint needs to establish its WebRTC connection and begin sending media before Bandwidth considers it available. Attempting to connect to an Endpoint before its client has finished negotiating and publishing audio won't succeed.
Listen for the webhook that indicates the device has negotiated with Bandwidth and is available to be <Connect>ed with, and only attempt to use the Endpoint after that event has fired.
2. Does an Endpoint need to stay connected for the whole session?
Yes. The mechanism for an Endpoint is connect-and-hold: once a device connects using an Endpoint token, it must remain connected for the entire duration of the session. If the underlying WebRTC connection drops, the Endpoint is no longer usable for that session, even if the browser or app appears to still be running. Disconnects and reconnects are not handled as a resumed session — they are a new connection and require a new Endpoint.
3. Can I reuse an Endpoint across multiple browser sessions or calls?
No — each new browser session, app launch, or call should register and use its own Endpoint rather than reusing one across sessions.
Endpoints are free of cost, so there's no cost-based reason to conserve them — create and discard as many as you need. Bandwidth expects a 1:1 relationship between an Endpoint and the session it represents, so reusing a single Endpoint across multiple sessions can lead to unpredictable connection and lifecycle behavior.
4. Are there any network or firewall restrictions I need to plan for?
No. BRTC's gateways sit on the public internet, so there's generally no special firewall configuration needed for standard outbound connectivity. There are two connections to be aware of:
- Signaling: the client opens an outbound WebSocket (WSS) connection over standard HTTPS (port 443) to a Bandwidth-hosted signaling gateway. Since it's a normal outbound HTTPS/WSS connection resolved by DNS, there's no fixed IP to allowlist — if your network does allowlist by hostname, allow outbound access to Bandwidth's gateway domain.
- Media: the actual audio (RTP/SRTP) uses the same IP and port ranges as Bandwidth's Programmable Voice product.
Bandwidth does not provide its own STUN or TURN servers for BRTC — if your network setup requires one, you'll need to supply your own.
5. How do I accept or decline an incoming stream on an Endpoint?
BRTC SDKs support explicitly accepting or declining an incoming media stream rather than having it auto-accepted. To use this, update to the latest minor version of the SDK for your platform — the accept/decline methods (and the sample apps demonstrating them) are only available from that version forward. Older SDK versions will not expose this behavior.
6. Can I connect two WebRTC Endpoints directly to each other?
Yes. <Connect> can target an Endpoint as its destination regardless of whether the other leg of the call is a PSTN call or another Endpoint, so endpoint-to-endpoint connections are supported — you're not limited to connecting an Endpoint only to a PSTN leg.
7. What happens to an in-progress call and recording if the WebRTC connection drops mid-call?
If the Endpoint's underlying WebRTC connection drops while it's actively connected (including while a recording is running), that Endpoint's session ends — it does not automatically pause and resume when the client reconnects. A dropped connection is treated as the end of that session, consistent with the fact that Endpoints must stay connected for the duration of the session and are never reused across sessions. Plan your application to detect the disconnect and start a new session (new Endpoint, new <Connect>) rather than expecting the original call to resume.