|
|
# Echo (reproducción)
|
|
|
|
|
|
## Qué es
|
|
|
|
|
|
**Echo** graba voz de **grupo** entrante y la reproduce en el TG **9990**. Corre como **PEER** conectado al master **ECHO** del peer server principal (bridge TG 9990).
|
|
|
|
|
|
El runtime de playback forma parte de **`adn-server`**; ejecútalo con **`adn-server.py --echo`** y un **`adn-echo.yaml`** mínimo.
|
|
|
|
|
|
## Configuración
|
|
|
|
|
|
Usa un **YAML aparte y mínimo** — solo lo que el PEER necesita para unirse a **ECHO** en `adn-server.yaml`:
|
|
|
|
|
|
| Campo | Rol |
|
|
|
|-------|------|
|
|
|
| `GLOBAL.SERVER_ID` | Identidad de red del echo (suele ser `9990`) |
|
|
|
| `LOGGER` | Archivo de log (opcional pero recomendado) |
|
|
|
| `SYSTEMS.ECHO` | `MODE: PEER`, `IP`/`PORT` local, `MASTER_IP`/`MASTER_PORT`, `PASSPHRASE`, `RADIO_ID`, `CALLSIGN`, `OPTIONS` |
|
|
|
|
|
|
No hace falta `PROXY`, `ALIASES` ni `REPORTS`. **`MASTER_PORT`** y **`PASSPHRASE`** deben coincidir con **`ECHO`** en el servidor principal.
|
|
|
|
|
|
- Copia **`adn-echo.example.yaml`** → **`adn-echo.yaml`** (no se commitea).
|
|
|
- Ejecuta:
|
|
|
|
|
|
```bash
|
|
|
python adn-server.py --echo -c adn-echo.yaml
|
|
|
```
|
|
|
|
|
|
En producción suele ir en una unidad **systemd** aparte (ver `examples/systemd/adn-echo.service` en el repo), mismo binario:
|
|
|
|
|
|
```bash
|
|
|
sudo cp examples/systemd/adn-echo.service /etc/systemd/system/
|
|
|
sudo systemctl daemon-reload
|
|
|
sudo systemctl enable --now adn-echo
|
|
|
```
|
|
|
|
|
|
## Relación con TG 9990
|
|
|
|
|
|
El servidor principal expone un master **ECHO** en **TG 9990** para el bridge de eco. El servicio **echo** independiente es un proceso aparte con su propia config que se conecta a ese master.
|
|
|
|
|
|
## Comportamiento con varios hotspots (proxy inject-only)
|
|
|
|
|
|
Cuando los hotspots se conectan a través del **proxy integrado** (`PROXY`),
|
|
|
varios radios pueden compartir el mismo MASTER como peers. En el legado
|
|
|
`adn-dmr-server` cada MASTER tenía un solo peer, así que el eco volvía
|
|
|
naturalmente sólo al llamante. El proxy inject-only multi-peer lo impone
|
|
|
explícitamente:
|
|
|
|
|
|
- **Entrega punto-a-punto.** La reproducción del eco (TG 9990) y los TG de
|
|
|
servicio bajo demanda (**9991–9999**) se entregan **sólo** al peer exacto
|
|
|
que originó la llamada (`RX_PEER` en el slot activo), **nunca** a otros
|
|
|
hotspots del mismo usuario. No hay matching difuso del ID DMR de origen.
|
|
|
- **Fallback a peer único.** Cuando sólo hay un peer conectado, el paquete se
|
|
|
le entrega (comportamiento legado de peer único).
|
|
|
- Esto aplica tanto al **plano de datos** (enrutado de audio) como al **plano
|
|
|
de reportes** (`BRDG_EVENT` enviado al monitor): el monitor muestra el chip
|
|
|
de eco en el hotspot originador, no en un hermano.
|
|
|
|
|
|
Ver [Enrutado de voz y contención — Gate de downlink](../development/routing-and-contention.md#gate-de-downlink-un-peer-recibe-el-paquete)
|
|
|
y [Proxy hotspot — Comportamiento con varios hotspots](hotspot-proxy.md#comportamiento-con-varios-hotspots).
|
|
|
|
|
|
## Documentación
|
|
|
|
|
|
Esta página es el resumen incluido en el repositorio; amplía las notas de despliegue localmente según necesites.
|
