Third-party API: RTC integration

RTC uses two credentials with different jobs. Your backend uses ak_pat_ to manage rooms and issue one-time join tickets. Each participant device uses an RTC token to join, publish, subscribe, and play. The browser does not need an AKStream.Next username or password.

sequenceDiagram
    participant Backend as Business backend
    participant API as AKStream.Next
    participant Client as RTC browser or app
    participant Media as MediaServer
    Backend->>API: Create room with API Token
    Backend->>API: Issue one-time ticket for business subject
    API-->>Backend: accessTicket
    Backend-->>Client: Send only accessTicket
    Client->>API: v2 admission consumes one-use ticket
    API-->>Client: RTC Token + device session + capabilities
    Client->>API: X-AK-RTC-Token + WHIP/WHEP
    API->>Media: Proxy SDP and media session

Issue a one-time join ticket from the backend

Your backend creates or selects a room, then issues a ticket for its own user identity:

POST /api/v2/rtc/rooms/{roomId}/access-tickets
Authorization: Bearer ak_pat_<TOKEN>
Content-Type: application/json

{
  "subjectIssuer": "dispatch-system",
  "subjectId": "user-1001",
  "displayName": "Dispatcher One",
  "role": "speaker",
  "capabilities": ["camera.publish", "microphone.publish", "publications.subscribe", "chat.send"],
  "expiresInMinutes": 10,
  "bypassWaitingRoom": false
}

subjectIssuer + subjectId is the stable identity owned by your application. The complete accessTicket is returned once, can be consumed once, and cannot call platform management APIs. Never send the API token to the participant device.

Join and refresh from the participant device

The client consumes the one-time ticket:

POST /api/v2/rtc/session/rooms/{roomId}/join
Content-Type: application/json

{
  "accessTicket": "<one-time-ticket>",
  "displayName": "Dispatcher One",
  "platform": "pc-web",
  "clientVersion": "2.4.0",
  "micEnabled": true,
  "cameraEnabled": true
}

The response contains participantToken, expiresAt, participant, device session, final capabilities, and admission state. Send this header on later calls:

X-AK-RTC-Token: <participantToken>

Call POST /api/v2/rtc/session/rooms/{roomId}/token/refresh before expiry. Refresh rotates tokenVersion, so the old RTC token stops working immediately. Send heartbeats regularly and call /leave; closing a browser tab is not a complete leave workflow.

Publish, subscribe, and play active media

RTC is an SFU. Every Publication is published independently and every Subscription is selected independently; the server does not automatically mix the room into one video.

An RTC token works only for its room and device. An active playback ticket works only for active Publications in that room and cannot replace an RTC token, publishing ticket, or platform API token.

Meeting recording and archives

1.0.0.157 mainly exposed legacy per-publication recording. 1.0.0.158 adds a continuous whole-meeting run. The old recording/targets, recording/start, and recording/stop still have per-publication semantics and do not replace a run's recordingId.

After the meeting, query:

GET /api/v2/rtc/session/rooms/{roomId}/playback/manifest
X-AK-RTC-Token: <participantToken>

1.0.0.158 provides continuous archives keyed by roomId + recordingId. Your backend calls POST /api/v2/rtc/rooms/{roomId}/recordings/access for a short-lived view/play/download ticket, then GET /api/v2/rtc/recordings?roomId=... to find runs, manifests, and authorized media. A run can include member/screen copies, chat, whiteboard, speaking and host events, plus an on-demand full MP4. Admission tokens do not authorize archives, and missing old events cannot be invented. See RTC archive HTTP fields and errors and SDK recording.

Failure handling

Production RTC acceptance needs real Chrome, Edge, Safari, Firefox, cameras, and microphones. Test weak networks, reconnect, TURN, screen sharing, and long-running sessions. Automated SDP checks do not replace human audio/video acceptance.