Clarify the pre-call experience and conversation start transition

[littleDogWang]

Background

The current quickstart opens on a standalone page whose only primary action is Start Conversation.

When the user clicks the button, the application immediately:

• generates the RTC and RTM token
• invites the voice agent
• logs in and subscribes to RTM
• joins the RTC channel
• initializes the microphone
• replaces the entire pre-call screen with the active conversation UI

Because the initial page does not provide setup controls, permission context, or a clear explanation of what will happen next, it does not feel like a meaningful pre-call step. At the same time, the immediate transition into a live voice session can surprise users.

Current Behavior

• Start Conversation occupies a separate full-screen page.
• The page does not clearly indicate that clicking the button immediately starts a live voice session.
• There is no microphone preview or permission expectation before the transition.
• Token generation, agent invitation, RTC connection, and microphone initialization happen behind a generic Starting... state.
• The active conversation UI replaces the entire page as soon as bootstrap completes.
• Failures during the transition can make it unclear whether the conversation started, partially started, or failed.

This makes the flow feel like an unnecessary landing page followed by an abrupt transition into a call.

Expected Behavior

The quickstart should provide a clear and predictable transition from pre-call state to active conversation state.

The implementation should choose and consistently apply one of these approaches:

Option A: Make the pre-call page meaningful

Keep a dedicated pre-call screen, but use it to:

• explain that the action starts a live voice conversation
• indicate that microphone permission will be requested
• show microphone readiness or device selection when appropriate
• use a more explicit action such as Join Conversation or Start Voice Session
• show clear connection stages before displaying the active conversation UI

Option B: Remove the standalone pre-call page

If no setup or decision is required before joining, remove the redundant full-screen step and integrate the start action into the main application experience with a clear connection state.

UX Requirements

• Users should understand that the action starts a live voice session.
• The UI should communicate microphone permission requirements before or during the action.
• Bootstrap stages should be distinguishable, for example:
  • Preparing session
  • Connecting to RTC
  • Waiting for agent
  • Connected
• Duplicate start actions should be prevented while the session is being prepared.
• The active conversation UI should appear only when the required client state is ready.
• Startup failures should return the user to a clear recoverable state with an actionable message.
• Ending a conversation should return to a predictable pre-call state.

Acceptance Criteria

• The initial experience clearly communicates what happens when the primary action is clicked.
• The primary action uses wording appropriate for starting a live voice session.
• Microphone permission expectations are visible before or during startup.
• The UI presents meaningful startup progress instead of only a generic loading label.
• The active conversation view does not appear before required session data is available.
• Startup failures identify the failed stage and provide a retry path.
• Users cannot accidentally start multiple sessions through repeated clicks.
• Ending the conversation returns the user to a clear and consistent state.
• The flow works consistently on desktop and mobile viewports.