La Suite Meet Documentation

The transcription process is an asynchronous pipeline triggered after a recording is completed. The flow follows these steps:

1. Trigger: The Backend API sends a POST /api/v1/tasks/ request to the Summary Service. The payload includes owner_id, filename, email, sub, room, recording_date, and recording_time.
2. Queueing: The Summary Service registers a task in the transcribe-queue via Celery.
3. Processing: A Celery worker fetches the audio file from MinIO (Object Storage).
4. Transcription: The worker sends the audio to the WhisperX API, which returns a segmented transcript.
5. Formatting: The worker formats the transcript into text.
6. Delivery: The worker sends a POST /create-for-owner request to LaSuite Docs (containing title, content, email, sub, and api token) to generate the final document for the room owner.

The recording lifecycle follows this sequence:

1. Start: The user clicks 'start recording' in the React frontend, which calls POST /api/v1.0/rooms/{id}/start-recording/ on the Django backend. The backend requests a room composite egress from the LiveKit API.
2. Recording: LiveKit Egress joins the room as a participant to capture audio and video. The frontend updates the recording status and notifies other participants via the LiveKit data channel.
3. Stop: The user clicks 'stop recording', triggering POST /api/v1.0/rooms/{id}/stop-recording/. The backend instructs LiveKit to stop the egress.
4. Upload & Notify: Egress uploads the file to Object Storage. The storage provider sends a webhook notification to the backend. The backend updates the recording status to SAVED and sends an email to the room owner.
5. Download: The owner receives an email and can navigate to /recording/{id} to download the file.

sequenceDiagram
    participant User
    participant Frontend as Frontend (React)
    participant Backend as Django Backend
    participant LiveKit as LiveKit API
    participant Egress as LiveKit Egress
    participant Storage as Object Storage
    participant Room as LiveKit Room
    participant Email as Email Service

    User->>Frontend: Click start recording button
    
    Frontend->>Backend: POST /api/v1.0/rooms/{id}/start-recording/
  
    Backend->>LiveKit: Create egress request
    
    LiveKit->>Egress: Start room composite egress
    Egress->>Room: Join room as recording participant
    Note over Egress,Room: Egress joins room to capture audio/video
    
    LiveKit-->>Backend: Return egress_id
    Backend->>Backend: Update Recording with worker_id
    Backend-->>Frontend: HTTP 201 - Recording started
    
    Frontend->>Frontend: Update recording status
    Frontend->>Frontend: Notify other participants
    Note over Frontend: Via LiveKit data channel
    
    Note over Egress,Room: Recording in progress...
    
    User->>Frontend: Click stop recording button
    Frontend->>Backend: POST /api/v1.0/rooms/{id}/stop-recording/
    
    Backend->>LiveKit: Stop egress request
    LiveKit->>Egress: Stop recording
    Egress->>Storage: Upload recorded file
    
    Storage->>Backend: Storage event notification
    Backend->>Backend: Update Recording status to SAVED
    Backend->>Email: Send notification to room owner
    
    Backend-->>Frontend: HTTP 200 - Recording stopped
    Frontend->>Frontend: Update UI and notify participants
    
    Email->>User: Send email with recording link
    User->>Frontend: Navigate to /recording/{id} to download file
    Frontend->>Frontend: Download recording file

The TokenExchangeService implements a multi-step handshake to securely exchange a temporary session for a JWT access token. The lifecycle follows these stages:

1. Initialization: Call init_session() to create a PENDING session. This returns a transit_token, a session_id, and a csrf_token.
2. Transit Consumption: The client must use the transit_token to call consume_transit_token(transit_token). This marks the token as CONSUMED and returns the session_id. This step prevents replay attacks; if a CONSUMED token is used again, the associated session is immediately evicted from the cache.
3. Authentication: Once the transit token is consumed, the backend calls set_access_token(user, session_id). This transitions the session state from PENDING to AUTHENTICATED and stores the JWT in the cache.
4. Token Retrieval: The client calls get_session(session_id) to retrieve the public session data (including access_token, token_type, expires_in, and scope).

Note: get_session performs a one-time read for AUTHENTICATED sessions; once the token is retrieved, the session is evicted from the cache to ensure the token is only fetched once.