Workflow: Managing an Oracle Radio WebSocket Session

Construct the WebSocket URL from the active Public Safety and Security instance's returned endpoint. Your client must represent an enabled Radio user and must have the permissions required for the operations that it sends.

Choose the authentication path for your client before opening the connection. See Authenticating with Oracle Radio APIs.

1. Obtain the supported browser session or Identity Domain bearer credential. A browser authenticates through the gateway during the HTTP upgrade. A registered Radio mobile application sends its Radio device ID in the X-Oracle-Radio-Device-Id header during the upgrade, but sends its bearer token after the connection opens.

2. Open the secure WebSocket connection with wss, the same hostname and any explicitly supplied port as the returned serviceEndpoint, and the root path /ws/radio. Replace the REST /api/ path. A registered mobile application can use the origin from its registration descriptor's radioBaseUrl. Follow the connection example for the upgrade header and first messages.

3. For a bearer-token connection, send AUTH and wait for AUTH_SUCCESS. For a gateway-authenticated browser connection, don't send AUTH.

4. Follow Getting Oracle Radio WebSocket Session Information to send WHO_AM_I. Verify that the WHO_AM_I response reports the expected authenticated user, and record the returned connection-local channels and talk-token state.

5. Follow Checking an Oracle Radio WebSocket Connection to send the JSON PING message. Confirm that the connection returns PONG.

For a registered mobile connection, maintain audio readiness separately from authentication renewal, device heartbeat, and PING. Readiness uses the timing values returned in AUTH_SUCCESS.

Process JSON responses, asynchronous events, and binary audio without blocking the WebSocket receive path. Use Checking an Oracle Radio WebSocket Connection when the client needs to verify application-message exchange. Before the current bearer access token expires, obtain a supported replacement for the same principal and send another AUTH. Wait for AUTH_SUCCESS before treating renewal as complete. Choose the check and renewal intervals according to the supported client and service configuration; this guide doesn't define fixed intervals.

Completing re-enrollment closes sessions for the replaced registration. When a different user authenticates a new connection for the same registered installation, older sessions for the prior user are closed. Confirm the intended user and current registration before reconnecting; don't repeatedly reconnect with replaced state.

1. Before a planned close, complete any active transmission. If the client is transmitting, follow Ending an Oracle Radio WebSocket Audio Transmission to send END. If it holds a talk token, then follow Releasing the Oracle Radio WebSocket Talk Floor to send RELEASE_TALK.

2. Close the WebSocket after the client has completed its active work. Discard connection-local subscriptions, talk tokens, audio decoder state, and other pending connection-local requests. Exception: retain the unchanged TEXT_MESSAGE payload and its original clientMessageId when the result is indeterminate. If you retry that same logical message after reconnecting, reuse its identifier; this is not a guarantee against duplicates after the cached result is lost.

3. After an unplanned close, stop sending immediately. Reconnect with backoff, repeat the authentication path, and do not reuse a talk token from the closed connection. This guide does not define a fixed retry interval or retry limit.

4. After reconnecting, repeat Getting Oracle Radio WebSocket Session Information and confirm the new connection state.

5. Follow Subscribing to an Oracle Radio WebSocket Channel to send SUBSCRIBE and rebuild each required live channel subscription. Follow Listing Oracle Radio WebSocket Channel Subscriptions to send LIST_CHANNELS and verify the resulting channel list.

6. If the client monitors presence, repeat Subscribing to Oracle Radio WebSocket Presence Updates by sending SUBSCRIBE_PRESENCE, and wait for PRESENCE_SUBSCRIBED before relying on new updates.