# Reconnections

A live session outlives its WebSocket. If the connection drops (your network, or a server of ours restarting),
reconnect to **the same URL**: the session continues with the same id and the next utterance ids, without lost or
repeated transcripts, and its final result covers everything.

## With the Gladia SDKs

Nothing to do. The SDKs reconnect to the same URL when the connection closes abnormally, keep every audio chunk
until it is acknowledged, and resend the unacknowledged ones.

## With your own client

1. Keep acknowledgments on (`messages_config.receive_acknowledgments`, the default).
2. Keep each audio chunk until an `audio_chunk` message covers it: `data.byte_range[1]` is the number of bytes
   acknowledged since the start of the session. Audio is acknowledged once it is transcribed.
3. When the connection closes with any code other than `1000`, reconnect to the same URL within 60 seconds, send the
   kept chunks first, then continue. Audio already transcribed is recognised and acknowledged again, never
   transcribed twice.
4. A `transcript` message in flight when the connection broke is not sent again; the session's result, its
   `post_final_transcript` and your callbacks have it.

## Close codes

| code | meaning | what to do |
|---|---|---|
| `1000` | the session ended | nothing |
| `1006` | the connection was lost | reconnect, resend the unacknowledged audio |
| `1011` | the session failed | create a new session |
| `1012` | a server is restarting | reconnect at once |
| `4401` | the URL is invalid, expired, or the session ended | create a new session |

While a dropped session may still resume, [`GET /v2/live/{id}`](/api-reference/v2/live/get/) reports it as
`processing`; once the 60 seconds have passed, `done`.