Connect+

Frame onboarding around the contract-backed foundation.

Provision

Provision presents Realtek Connect+ onboarding as a layered path from registry entry to activated cloud device. The current foundation is the account registry, cross-service provisioning command flow, WebRTC Video over TURN activation boundary, service-scoped provisioning credentials, and transport readiness contract; local Wi-Fi/BLE setup, QR/SoftAP UX, ownership transfer, factory reset policy, and aggregate product readiness are not presented as generally available implementation until those owner repositories land them.

Product onboarding interface contract

Discuss Provision All Features
Enterprise platform surface showing device registry, onboarding status, dashboard panels, and a mobile companion view.

Highlights

What this service covers

  • Contract-backed cloud registry, activation, service credential, and transport readiness boundaries
  • Integration-ready claim material concepts for QR, serial, activation code, and future factory identity
  • Roadmap treatment for local Wi-Fi/BLE setup, SoftAP UX, transfer/reset policy, and aggregate readiness

Capabilities

Platform building blocks

  • Use account-side registry APIs plus cross-service DeviceProvisionRequested and DeviceProvisionSucceeded or DeviceProvisionFailed events for the cloud activation foundation
  • Keep SDK claim parsing separate from account-side ownership and binding decisions
  • Describe local onboarding and product readiness as planned owner-repository work instead of broadly available website functionality

Outcomes

Why product teams use it

  • Preserve the product onboarding vision without overclaiming implementation status
  • Give firmware, app, SDK, account, and WebRTC Video over TURN teams one shared availability vocabulary
  • Make evaluation conversations explicit about what is available now, integration-ready, or roadmap

Availability

Separate what is available, integration-ready, and roadmap

Realtek Connect+ provisioning is presented as a layered product path. The cloud-side foundation is contract-backed now; local onboarding UX and final ownership policy stay clearly marked until implementation lands.

Layer Public status Customer-facing boundary
Cloud registry and activation foundation Available foundation Account registry, cross-service provisioning commands and events, WebRTC Video over TURN activation, scoped credentials, and transport readiness define the current cloud-side path.
Claim material parsing Integration-ready QR, serial, activation code, MAC, and future factory identity inputs have shared interface vocabulary, but ownership policy is account-side follow-up work.
Local Wi-Fi/BLE and SoftAP onboarding Roadmap Local discovery, credential handoff, QR onboarding UX, and mobile setup sessions are not described as generally available implementation in this website.
Transfer, reset, and product readiness Roadmap Already-claimed handling, ownership transfer, factory reset, delete/deactivate separation, and aggregate readiness projection require follow-up policy and service work.

Available foundation

Cloud-side provisioning is the implemented contract boundary

The stable story starts with account registry records and the cross-service activation flow rather than a single all-in-one provisioning endpoint.

  • Account-side device registration, cross-service provisioning requests, WebRTC Video over TURN activation results, service-scoped credential issuance, and owner transport readiness are the public cloud-side behaviors to discuss today.
  • Service-scoped provisioning credentials are integration credentials, not human product roles or a product ACL policy.
  • Provisioning remains multi-service orchestration across account manager, the cross-service channel, WebRTC Video over TURN service, device credentials, and transport state.
  • WebRTC Video over TURN activation alone is not full product readiness; the product state must distinguish registry, claim, local setup, activation, online, failure, and deactivation stages.

Integration-ready

Claim material has a defined interface, not final ownership policy

The product onboarding contract gives SDK and app teams common vocabulary for claim input while leaving authorization decisions with account-side policy.

  • Claim material may represent QR payloads, serial numbers, activation codes, MAC addresses, or future factory identity inputs.
  • SDK parsers should normalize supported claim material and return stable errors for malformed or unsupported inputs.
  • Account-side follow-up work still owns reuse rules, already-claimed rejection, transfer behavior, factory reset semantics, and delete-versus-deactivate policy.

Roadmap

Local onboarding remains owner-repository implementation work

The public page keeps the product vision visible while avoiding a general-availability claim for local setup UX.

  • BLE provisioning, SoftAP provisioning, local Wi-Fi credential transport, QR onboarding UX, ECDH or challenge-response handshakes, and manufacturing CA policy are not yet stable website-available implementation claims.
  • Android and iOS are the primary targets for real local onboarding implementations; native and JavaScript/TypeScript packages should report explicit unsupported capability where needed.
  • Full product readiness should wait for local setup results, claim/bind policy, cloud activation, and transport online state to be joined by an owner repository or integration service.

Next step

Evaluate Provision for your product roadmap.

Share your product category, target deployment, and cloud requirements with the Realtek Connect+ team.

Talk to sales