Fetch blocks from a conference call subchain »; handle the returned updateGroupCallChainBlocks as specified here ».If the number of blocks returned by any call to this method is equal to limit, this method must be re-invoked immediately after processing the returned updateGroupCallChainBlocks, with the newly committed offset (usually equal to the returned next_offset).
API section: Working with E2E conference calls »
phone.getGroupCallChainBlocks#ee9f88a6 call:InputGroupCall sub_chain_id:int offset:int limit:int = Updates;
| Name | Type | Description |
|---|---|---|
| call | InputGroupCall | The call the request is about. |
| sub_chain_id | int | |
| offset | int | How many records to skip from the start of the selection. |
| limit | int | Maximum number of records to return. |
Read out of the handler itself — this is what the server actually returns for this method.
| Code | Type | What it means |
|---|---|---|
| 400 | GROUPCALL_INVALID |
No group call with this identifier exists. |
| Code | Type | What it means |
|---|---|---|
| 401 | AUTH_KEY_UNREGISTERED |
The server does not know this session: the key was revoked, expired, or the call was made before authorisation. |
| 401 | API_ID_INVALID |
This api_id was never issued or has been blocked. Keys come from my.ansible.su. |
| 400 | CONNECTION_LAYER_INVALID |
The client did not declare a layer, or declared one the server does not know. |
| 420 | FLOOD_WAIT_X |
Too often. Do not retry for X seconds — the number arrives in the error text. |
| 500 | INTERNAL |
A failure on our side. The request may be retried; if it keeps failing, it is a bug of ours. |