Session Lifecycle (Client Side)

The client-side session lifecycle is managed by StreamingManagerService and StreamingService in 298_beautified.js, while the lower-level WebRTC session state machine lives in vendor_beautified.js.

Session States

The client tracks sessions through these states:

IDLE
  │ ← User clicks "Play"
  ▼
QUEUED              ← Waiting for rig availability
  │  (queuePosition, eta available)
  ▼
ALLOCATING          ← Rig being prepared
  │
  ▼
READY_FOR_CONNECTION ← Stream ready, client connecting
  │
  ▼
AD_PLAYING          ← Video ad (if applicable)
  │
  ▼
LOADING             ← Game loading screen
  │
  ▼
STREAMING           ← Active gaming session
  │
  ├── PAUSED        ← Session paused (user/system)
  │
  ▼
TERMINATING         ← Session ending
  │
  ▼
POST_SESSION        ← Stats/feedback shown

Session Identifiers

Every session is tracked by multiple IDs:

ID	Description
sessionId	Primary session identifier
subSessionId	Sub-session within a session (resume creates new subSession)
cmsId	Content Management System game ID
networkTestSessionId	ID of the pre-session network test
streamingProfile	GUID for streaming configuration
systemInfoGuid	Client system identifier

Queue Management

When all rigs are busy, the client enters queue mode:

// From vendor_beautified.js
{
  queuePosition: <number>,   // Position in queue
  eta: <seconds>,            // Estimated wait time
  ads: [...],                // Video ads to show during wait
}

Session Context

The client persists session context across operations:

streamingService.streamingProperties.sessionId
streamingService.streamingProperties.subSessionId
gameSessionDistributedTracingService  // for distributed tracing

Resume Sessions

Sessions support reconnection/resume:

resumeType: <type>   // tracked in session context
isResume: true/false // in telemetry events

Reconnect timeout: 180 seconds (server-side).

Platform Selection

PlatformSelectionUIService manages which streaming backend is used:

streamingManagerService.register(pt.H.PlatformSelection, {
  // Platform selection configuration
})

Session Termination Listeners

The client subscribes to session termination events:

// From 298_beautified.js lines 304-349
sessionTerminationListener.setup({
  onTerminated: (reason) => {
    // Handle different termination reasons
    // Map to user-facing error messages
  }
})

Session Progress Tracking

// Lines 6019-6046 of 298_beautified.js
streamingService.statusMonitor.subscribe(status => {
  // Track: connecting, loading, streaming, paused, ending
})

Error Handling

Exit error codes are tracked in telemetry:

// From vendor_beautified.js
exitErrorCode: <code>   // Maps to NVST_ error codes

Client-side error mapping via Re() function converts platform codes to user-facing messages.

Retry logic for server-side errors:

if ([429, 502, 503, 504].includes(statusCode)) {
  retryWithExponentialBackoff()
}

if (501 == status || 502 == status || 408 == status) {
  retryWithBackoff()
} else {
  failImmediately()
}

App Launch Timeouts

Timeout	Duration	Description
maxAppLaunchTimeoutMinutes	10 min	Max wait for app launch
launchAppTimeoutSec	180s	Server-side app launch
readyToStreamTimeoutSec	30s	Stream ready after launch
clientConnectTimeoutSec	180s	Client connection window

SSI (Session Setup Interface)

The SSI connector sends session setup data to the rig:

{
  "SsiConnector": {
    "enable": true,
    "sessionSetupDataSendTimeoutMs": 1000
  }
}

Streaming Stats

At session end, the client reports:

{
  streamDuration: <ms>,
  frameCount: <n>,
  codec: "H264|HEVC|AV1",
  sessionId: <id>,
  subSessionId: <id>,
  zoneAddress: <zone>,
  connectivityInfo: {...},
  streamInfo: {...}
}