Core Concepts for One-on-One Video

Sessions, tokens, and client-side media flow are the building blocks of everything you'll implement in this path. Here's how they fit together.

Sessions and tokens

  • A session is the room where both participants connect.
  • A token lets a participant join that room with specific permissions.
  • The backend issues session credentials, and the frontend uses them to connect, publish local media, and render the remote participant.

Session types: relayed vs routed

Even in one-on-one apps, session type affects behavior and future extension options.

Use a relayed instead of a routed session, if you have only two participants (or maybe even three) and you are not using archiving.

Using relayed sessions reduces the latency between participants, reduces the points of failure and you can get better quality video and audio in most cases.

Routed sessions are required if you want to archive your session.

They are recommended if you have more than two or three participants in the session.

For more information, see The Media Router and media modes.

For this path, routed mode keeps the exercise flow aligned with how the demo is implemented.

Token roles in practice

You will usually work with a simple split:

  • publisher: can publish local media and subscribe to remote streams,
  • subscriber: receives streams only,
  • moderator: reserved for advanced control scenarios.

If you want the full role model and token parameters, see Create token.

One-on-one lifecycle in plain language

  1. Frontend requests session credentials from backend.
  2. Client connects and publishes local media.
  3. The remote participant joins and is rendered in the subscriber area.
  4. The app handles disconnect and reconnect states cleanly.

Checkpoint

  • You understand the backend/frontend split.
  • You know why routed mode is used in this path.
  • You understand which token roles are needed for common participant behavior.