Hub

electrosystems

adfsa-migration

active medium work
Creado
2026-05-08
Actualizado
2026-05-29
Cliente final
ADFSA
Directorios
  • /home/sergio/agy/electrosystems/servers/asterisk-adfsa-old
  • /home/sergio/agy/electrosystems/servers/asterisk-adfsa-new

Pendientes abiertos (7)

Ver todos →

🎯 Top de ataque (7)

  • #360 📅 2026-06-05 Migrar la tarjeta E1 (TE210P dual-span) a Nortel del servidor viejo al nuevo. Implica:
  • #361 📅 2026-06-10 Desmantelar el servidor viejo (asterisk-adfsa-old). Pre-condición: migración de tarjeta E1 completa y validada + ruta IAX2 retirada del NEW. Pasos:
  • #041 📅 2026-06-15 Agregar IP pública en el NEW para troncal SIP de Transtelco (líneas americanas). ADFSA va a tener un segundo trunk SIP con Transtelco para sus DIDs US (en paralelo al de Telmex que ya está en cutover). Requiere:
  • #042 📅 2026-06-15 Validar estatus end-to-end de la migración SIP Telmex — confirmar que llamadas in/out funcionan después del swap, que los teléfonos están registrando contra el nuevo server, y que el trunk Telmex sigue activo.
  • #043 📅 2026-06-12 Verificar soporte MFC-R2 (openr2) en el chan_dahdi de FreePBX 17 / Debian 13 antes de insertar la tarjeta E1. Comando útil cuando DAHDI esté cargado: asterisk -rx "dahdi show mfcr2 variants" y revisar si la librería libopenr2 está en el sistema. Sin esto, la migración del E1 falla en signalling MX.
  • #044 📅 2026-06-17 Limpiar inconsistencia de apt sources en Debian 12/13. El host tiene mezcla: líneas bookworm + una línea stable (resuelve a trixie) + repo Sangoma bookworm. Runtime es trixie pero Sangoma no soporta oficialmente trixie. Decidir: bajar a bookworm (alineado con Sangoma) o quedarse en trixie (no soportado, riesgo de roto en el siguiente major upgrade de FreePBX). Revisar packages held antes de tocar nada.
  • #366 📅 2026-06-20 Inbound desde Telmex. Outbound validado en producción 2026-05-07; inbound deferido al provider. Confirmar con Telmex cuando restauren el servicio. Probable: parte del rollout de PSTN-E1 → SIP-trunk de los próximos días.

Actividad en bitácora 3 días

jun
jul
ago
sep
oct
nov
dic
ene
feb
mar
abr
may
L
X
V
Menos
Más

ADFSA — Migración de PBX y SIP Telmex

Contexto

ADFSA es cliente de Electrosystems. Tienen un PBX Asterisk legado (asterisk-adfsa-old, Dell PE1750, CentOS 5 EOL, Asterisk 1.6.2 — voip.adfsa.com.mx, IP 10.11.1.114) que se está reemplazando por uno nuevo (asterisk-adfsa-new, Dell T150, Debian 13, FreePBX 17 / Asterisk 22 — IP 192.168.147.156).

El sistema nuevo está pensado para transcodificar entre el SIP trunk de Telmex (G.729) y el PBX Nortel del cliente vía E1/MFC-R2 (A-law). La tarjeta E1 se migrará físicamente del servidor viejo al nuevo en algún momento del cutover.

Profile y safety rules específicos de cada host viven en ~/agy/electrosystems/servers/asterisk-adfsa-{old,new}/. El trabajo se ejecuta allá; los pendientes y seguimiento se llevan aquí.

Tareas pendientes

✅ Cerrado en esta sesión (2026-05-08)

  • SSH-verificación del IP swap: NEW está en .134 (adfsa-voip, Debian 13, Asterisk 22.5.2), OLD en .156 (voip.adfsa.com.mx, CentOS 5, Asterisk 1.6.2.13). Estado al momento del audit: 7h up, 5 canales activos, 3 llamadas en curso, 1994 procesadas — producción viva.
  • ~/.ssh/config actualizado: alias asterisk-adfsa-new .156 → .134. Alias adfsa-voip se quedó como estaba (apunta al VPN 10.11.1.114, sin cambio per Sergio).
  • README de asterisk-adfsa-new actualizado: IP .134, Asterisk version drift 22.3.0 → 22.5.2 capturado, Changelog 2026-05-08 con detalle.
  • README de asterisk-adfsa-old actualizado: agregada sección de LAN IP (.156 post-swap, .134 previo), Changelog 2026-05-08. La identificación del “host que quedó en .156” se resolvió aquí: es el asterisk-adfsa-old mismo, no un host nuevo.
  • Findings 2026-05-08 (later) en electrosystems/servers/asterisk-adfsa-new/findings.md con toda la verificación y el audit de literales.

✅ Audit cerrado (Sergio confirmó 2026-05-08)

  • Items 1 y 2 (refs literales a .156 en extensions_custom.conf:1232 y iax_additional.conf:14) — intencionales. La compañera de Sergio las cambió manualmente post-swap para que apunten al servidor viejo, dado que la tarjeta E1 a Nortel sigue ahí (en el OLD). Calls _2[23]XX se rutean por IAX al OLD para llegar al Nortel mientras la migración del E1 ocurre. No tocar.
  • Item 3 (ref a .134 en iax_custom.conf:6) — probable error. La compañera le va a meter mano al servidor; Sergio y ella revisan el lunes 2026-05-11 (PM) para confirmar si ya quedó arreglado.

🆕 Nuevos pendientes capturados 2026-05-08 (la migración apenas empieza, hay roadmap)

  • Resuelto [#040] (documentado 2026-05-21, decisión tomada antes): se migra la TE210P dual-span al NEW. Nortel consolida de 2 spans activos (span 2 TE210P respaldo + span 3 TE110P primario en el OLD) a 1 span activo en el NEW. La TE110P se queda con el OLD hasta su decommission. Capacidad post-migración ~30 canales (un span) — operador lo acepta. Findings canónicos: electrosystems/servers/asterisk-adfsa-new/findings.md 2026-05-21 y asterisk-adfsa-old/findings.md 2026-05-21.
  • #360 📅 2026-06-05 — Migrar la tarjeta E1 (TE210P dual-span) a Nortel del servidor viejo al nuevo. Implica:
    • Ventana de mantenimiento con downtime del Nortel mientras la card se traspasa.
    • Verificar soporte MFC-R2 (openr2) en chan_dahdi del NEW antes de insertar.
    • Replicar config MFC-R2 del OLD: signalling=mfcr2, mfcr2_variant=mx, /etc/openr2/r2proto.conf.
    • Una vez vivo el E1 en el NEW, quitar la ruta IAX2 al .156 (los items 1 y 2 del audit dejan de ser intencionales — todo pasa a ser local en el NEW).
  • #361 📅 2026-06-10 — Desmantelar el servidor viejo (asterisk-adfsa-old). Pre-condición: migración de tarjeta E1 completa y validada + ruta IAX2 retirada del NEW. Pasos:
    • Confirmar que ningún flujo (ni el IAX a .156, ni nada externo) lo necesita.
    • Apagar limpiamente; conservar imagen forense por si hay que volver a algo.
    • Marcar decommissioned en electrosystems/INVENTORY.md.
    • Actualizar ~/.ssh/config para quitar/marcar el alias adfsa-voip cuando ya no aplique.
  • #041 📅 2026-06-15 — Agregar IP pública en el NEW para troncal SIP de Transtelco (líneas americanas). ADFSA va a tener un segundo trunk SIP con Transtelco para sus DIDs US (en paralelo al de Telmex que ya está en cutover). Requiere:
    • Asignar IP pública o NAT 1:1 al servidor NEW (actualmente solo tiene IPs internas: 192.168.147.134, 172.16.128.2, y la 3ra NIC para Telmex en 10.10.10.0/x).
    • Reglas de firewall site-side para permitir RTP+SIP de Transtelco (rangos del proveedor).
    • Endpoint PJSIP [sip-transtelco] con identify-based auth (probable, como el de Telmex).
    • Coordinar credenciales/IPs con Transtelco.
    • Ruteo en dialplan: identificar qué patrones de dial salen por Transtelco (US destinations) vs Telmex (MX) y enrutar correctamente.

Otros pendientes (sin cambio en esta sesión)

General

  • #042 📅 2026-06-15 — Validar estatus end-to-end de la migración SIP Telmex — confirmar que llamadas in/out funcionan después del swap, que los teléfonos están registrando contra el nuevo server, y que el trunk Telmex sigue activo.

De findings 2026-04-24 / 2026-04-27 / 2026-05-07 (capturados en escaneo 2026-05-08)

  • #043 📅 2026-06-12 — Verificar soporte MFC-R2 (openr2) en el chan_dahdi de FreePBX 17 / Debian 13 antes de insertar la tarjeta E1. Comando útil cuando DAHDI esté cargado: asterisk -rx "dahdi show mfcr2 variants" y revisar si la librería libopenr2 está en el sistema. Sin esto, la migración del E1 falla en signalling MX.
  • #044 📅 2026-06-17 — Limpiar inconsistencia de apt sources en Debian 12/13. El host tiene mezcla: líneas bookworm + una línea stable (resuelve a trixie) + repo Sangoma bookworm. Runtime es trixie pero Sangoma no soporta oficialmente trixie. Decidir: bajar a bookworm (alineado con Sangoma) o quedarse en trixie (no soportado, riesgo de roto en el siguiente major upgrade de FreePBX). Revisar packages held antes de tocar nada.
  • #366 📅 2026-06-20 — Inbound desde Telmex. Outbound validado en producción 2026-05-07; inbound deferido al provider. Confirmar con Telmex cuando restauren el servicio. Probable: parte del rollout de PSTN-E1 → SIP-trunk de los próximos días.

En progreso

  • Cutover en marcha. El alias ssh adfsa-voip (VPN 10.11.1.114) ahora apunta al servidor VIEJO (.156), que es donde viven las tarjetas E1 hacia el Nortel. Flujo activo: SIP Telmex → adfsa-NEW (.134) → IAX2 → adfsa-OLD (.156) → E1 → Nortel. Las refs a .156 en extensions_custom.conf y iax_additional.conf son intencionales (confirmado 2026-05-08). Span 1 del OLD (legacy PSTN from-pstn) está en alarma RED/yellow intermitente — era el enlace PSTN ya retirado, no es un problema activo.
  • Pendiente de decisión: consolidar todo al NEW (requiere decidir qué tarjeta E1 migrar y ventana de mantenimiento).

Histórico del 2026-05-08 (este turno)

  • Pidió Sergio: entrar a los servidores, actualizar datos, anotar el evento del IP swap aquí y en electrosystems, actualizar ~/.ssh/config si es necesario.
  • Hice:
    • Leí los READMEs y findings de ambos hosts ADFSA y la doc del reverse-proxy.
    • Documenté el IP swap (.134 ↔ .156) y sus implicaciones en electrosystems/servers/asterisk-adfsa-new/findings.md (entry 2026-05-08), con comandos de verificación y lista de items abiertos.
    • Marqué el README de asterisk-adfsa-new con anotación “pending SSH verification” en la sección Access y agregué entrada al Changelog (2026-05-08).
    • No actualicé ~/.ssh/config todavía — depende de verificar primero qué IP es cuál post-swap.
  • Bloqueado por: el harness no me autorizó el SSH a la PBX de producción aunque tu mensaje explícitamente lo permitía. Necesito que tú apruebes el SSH a esos hosts (o que tú corras los dos comandos de verificación y me pases la salida) para terminar.

Histórico previo (de antes de esta sesión)

  • 2026-04-24 — Inventario inicial de ambos servers.
  • 2026-04-24..2026-05-07 — Build-out del nuevo PBX en 192.168.147.156: G.729 vía bcg729 (open-source) integrado y funcionando, trunk [sip-telmex] configurado contra 10.10.10.1, outbound validado en condiciones de producción 2026-05-07. Inbound deferido al provider. E1 card aún sin migrar.
  • 2026-05-07 — Resuelto un gotcha de pattern-matching de Asterisk: la base context se busca completa antes de cualquier include, sin importar specificity. Fix: literal rules movidas al base context [from-nortel]. Ver findings.md ese día.

Notas técnicas

Flujo de llamadas post-cutover (estado 2026-05-20)

SIP Telmex (G.729)
    → adfsa-NEW  (192.168.147.134 / VPN: ninguna — acceso vía bastion router-adfsa)
        transcodea G.729 ↔ A-law
        → IAX2 a 192.168.147.156
            → adfsa-OLD (192.168.147.156 / VPN: 10.11.1.114 = alias ssh adfsa-voip)
                → E1 MFC-R2 → Nortel
  • Las extensiones SIP internas registran contra el NEW.
  • Las extensiones del Nortel llegan vía el OLD.
  • El alias ssh adfsa-voip apunta al VPN del OLD (10.11.1.114), no al NEW. No confundir.
  • Los literales .156 en extensions_custom.conf y iax_additional.conf del NEW son intencionales durante el cutover.

Mapa de spans DAHDI en adfsa-OLD (2026-05-20)

SpanTarjetaLabel legacyEstadoUso actual
1T2XXP (TE210P)from-pstnAlarma RED/yellow intermitenteRetirado — era enlace PSTN ya cancelado; la alarma es esperada, no es incidente
2T2XXP (TE210P)—OKNortel respaldo
3TE110P—OKNortel primario

Docs de referencia técnica profunda

  • ~/agy/electrosystems/servers/asterisk-adfsa-old/ — README + findings con config DAHDI, MFC-R2, hardware.
  • ~/agy/electrosystems/servers/asterisk-adfsa-new/ — README + findings con config PJSIP, bcg729, trunk Telmex.

Hosts involucrados (resumen del INVENTORY de electrosystems)

  • asterisk-adfsa-old — Producción actual. Dell PowerEdge 1750, Xeon 32-bit, CentOS 5 + Asterisk 1.6.2 (2011, EOL). 2× tarjetas Digium (TE210P + TE110P) con 3 spans MFC-R2. SSH puerto 58695 user root, requiere crypto legacy (+ssh-rsa, dh-group1-sha1).
  • asterisk-adfsa-new — Pre-producción. Dell PowerEdge T150, Xeon E-2314 (4c, AVX-512, AES-NI), 15 GB RAM, 1.8 TB. Debian 13, FreePBX 17 / Asterisk 22.3.0. bcg729 (open-source) instalado y vivo como codec_g729.so. NICs: eno8303 (192.168.147.156, mgmt), eno8403 (172.16.128.2), tercera NIC para Telmex pendiente (10.10.10.0/x). Sin tarjeta E1 instalada todavía (se migra del viejo). SSH puerto 58695, accedido vía bastion router-adfsa (EdgeRouter X 10.11.6.204, user ubnt).

Safety

Aplican las reglas de Asterisk de ~/agy/electrosystems/ANTIGRAVITY.md:

  • core reload antes que core restart. Nunca reiniciar Asterisk sin OK explícito.
  • Backup de /etc/asterisk/ antes de cualquier edit. Validar con dialplan show / pjsip show endpoints post-reload.
  • Respetar archivos manejados por FreePBX — usar siblings _custom.conf.
  • Nada destructivo sin aprobación explícita por host por sesión.

Bitácora

2026-05-21

  • Pidió Sergio: documentar la decisión sobre la tarjeta E1 a migrar (#040 en PENDIENTES.md) — me dijo que ya estaba tomada y debía estar en ~/agy/electrosystems/, pero al verificar no aparecía registrada.
  • Confirmé con Sergio: TE210P dual-span se migra al NEW. Nortel consolida a un solo span activo en el NEW. La TE110P se queda con el OLD hasta el decommission.
  • Documenté en electrosystems/:
    • Entrada nueva 2026-05-21 en asterisk-adfsa-new/findings.md (canónica): consecuencias para el NEW, MFC-R2 config a replicar (span-2 block del OLD, sin mfcr2_mfback_timeout=2500), driver DAHDI requerido (wct4xxp), capacidad post-migración.
    • Entrada espejo 2026-05-21 en asterisk-adfsa-old/findings.md: estado del OLD post-card-move (solo TE110P), item #1 de la lista de tracking marcado como settled.
    • asterisk-adfsa-new/README.md: línea “No E1 card installed… (pending decision…)” actualizada con la decisión.
  • En este archivo: cerré el item de “Decidir qué tarjeta” con [#040], ajusté el siguiente item para indicar que la card es la TE210P.
  • PENDIENTES.md: #040 movido a “Cerrado reciente”; #006 en “Disparo condicional” simplificado para reflejar que el bloqueo ahora es solo la ventana de mantenimiento, no la decisión.

2026-05-20

  • Pidió Sergio: verificar conectividad con el Nortel en adfsa-voip y entender estado de los spans DAHDI.
  • Descubrimos: el alias ssh adfsa-voip apunta al servidor VIEJO (OLD, .156) — las IPs se intercambiaron durante el cutover para facilitar la migración. El flujo activo es SIP Telmex → NEW → IAX2 → OLD → E1 → Nortel.
  • DAHDI en OLD: span 1 (TE210P, legacy from-pstn) en alarma RED/yellow — era el enlace PSTN ya retirado, no es problema activo. Spans 2 y 3 OK (Nortel respaldo y primario respectivamente).
  • Reconciliados: docs técnicos profundos actualizados en ~/agy/electrosystems/servers/asterisk-adfsa-{old,new}/ (README + findings). Este archivo actualizado con flujo actual, mapa de spans y los dos pendientes de decisión que quedaron abiertos: (1) decidir qué tarjeta E1 migrar al NEW, (2) una vez hecha esa migración, quitar ruta IAX2 y desmantelar el OLD.

2026-05-08

  • Pidió Sergio: registrar el proyecto y dos pendientes — actualizar info de servidores ADFSA y validar estatus de migración a SIP Telmex.
  • Hice: creé este archivo. Recopilé contexto de hardware/OS/Asterisk de ambos hosts del INVENTORY.md de electrosystems para tener referencia rápida sin tener que ir a buscar.
  • Falta: aclarar alcance de cada pendiente antes de tocar los servidores remotos.