El desafío silencioso detrás de cada llamada VoIP
Cuando una empresa decide migrar su telefonía tradicional a VoIP, la conversación suele girar en torno a costos, escalabilidad o integración con CRM. Pocas veces se habla de lo que realmente hace posible que una llamada se establezca, se mantenga estable y termine sin cortes: el módulo que gestiona el protocolo SIP dentro de la central telefónica Asterisk.
Para quienes administran infraestructura de telecomunicaciones sobre Asterisk —el motor open source detrás de una enorme cantidad de centrales telefónicas virtuales en el mundo, incluida buena parte de las implementadas en Perú y Latinoamérica— esta decisión técnica tiene nombre propio: chan_sip, el canal driver histórico para el protocolo SIP (Session Initiation Protocol).
Entender qué es, cómo funciona la configuración SIP en Asterisk, cuáles son sus limitaciones y por qué la comunidad técnica lo está reemplazando progresivamente por PJSIP no es un ejercicio académico. Es información que impacta directamente en la estabilidad, seguridad y capacidad de crecimiento de la infraestructura de telefonía IP empresarial de cualquier organización.
¿Qué es chan_sip y qué rol cumple dentro de Asterisk?
Asterisk es un framework de telefonía open source que permite construir centrales telefónicas (PBX), sistemas de call center, pasarelas SIP y aplicaciones de comunicación unificada. Su arquitectura modular funciona mediante “canales” (channels): componentes que traducen un protocolo de comunicación específico al lenguaje interno que Asterisk usa para procesar llamadas.
chan_sip es, precisamente, el módulo SIP de Asterisk diseñado originalmente para implementar el protocolo SIP dentro del sistema. Su función es traducir la señalización SIP —el estándar que gestiona el inicio, modificación y finalización de sesiones de comunicación en tiempo real, como llamadas de voz, video o mensajería— al formato interno que el núcleo de Asterisk puede interpretar y enrutar.
Una breve base sobre SIP
SIP (Session Initiation Protocol) es un protocolo de señalización, no de transporte de medios. Esto significa que SIP se encarga de negociar cómo, cuándo y entre quién se establece una comunicación (registro de extensiones, invitación a llamada, autenticación, terminación de sesión), mientras que el audio en sí viaja mediante otro protocolo, típicamente RTP (Real-time Transport Protocol).
En términos simples: SIP es quien “marca el número y descuelga el teléfono”; RTP es quien transporta la voz una vez que la llamada está en curso. chan_sip es el componente de la central telefónica Asterisk responsable de gestionar toda esa negociación SIP.
Funciones clave que cumple chan_sip
1. Registro de terminales SIP (SIP Registration)
Cada teléfono IP, softphone o gateway que se conecta a la central necesita “registrarse” para que el sistema sepa dónde y cómo enviarle llamadas. chan_sip gestiona este proceso de autenticación y registro, validando credenciales y manteniendo activa la asociación entre extensión y dispositivo.
2. Establecimiento y control de sesiones
A través de mensajes estandarizados como INVITE, ACK, BYE o CANCEL, chan_sip interpreta las solicitudes de inicio, confirmación y cierre de llamadas, coordinando con el dialplan de Asterisk para decidir cómo enrutar cada comunicación.
3. Negociación de códecs mediante SDP
Dentro de la señalización SIP viaja el protocolo SDP (Session Description Protocol), que define qué códecs de audio o video usará la llamada (G.711, G.729, GSM, Opus, entre otros). chan_sip participa en esta negociación para asegurar que ambos extremos de la comunicación “hablen el mismo idioma” técnico, lo cual influye directamente en calidad de voz, consumo de ancho de banda y compatibilidad entre equipos.
4. Gestión de troncales SIP (SIP Trunk en Asterisk)
Las empresas que conectan su central con operadores para salida y entrada de llamadas públicas lo hacen mediante un SIP Trunk. chan_sip históricamente ha sido el componente que gestiona esas conexiones con proveedores de telefonía, incluyendo autenticación, formatos de numeración y parámetros de calidad de servicio.
5. Manejo de NAT
Un desafío constante en VoIP es la traversal de NAT (Network Address Translation), especialmente cuando dispositivos están detrás de routers domésticos o redes corporativas con IP privadas. chan_sip incluye parámetros específicos (como nat=force_rport,comedia) para intentar resolver estos escenarios, aunque con resultados variables según la complejidad de la red.
Configuración típica: una mirada técnica
Tradicionalmente, la configuración SIP en Asterisk mediante chan_sip se realizaba en el archivo sip.conf, donde se definían tanto los parámetros generales del sistema como cada “peer” (extensión, troncal o dispositivo) en un único bloque:
[1001]
type=friend
host=dynamic
secret=ClaveSegura123
context=internos
disallow=all
allow=ulaw
allow=alaw
Esta estructura mezcla en una misma sección tres cosas distintas: credenciales de autenticación, comportamiento de la sesión y datos de ubicación del dispositivo. Funciona bien en implementaciones pequeñas, pero es precisamente esta mezcla la que empieza a mostrar límites cuando la plataforma crece, como veremos a continuación.
Por qué chan_sip está siendo reemplazado por PJSIP
La respuesta de la comunidad: PJSIP
Digium (la empresa detrás de Asterisk, hoy parte de Sangoma) impulsó la adopción de PJSIP, una librería SIP de propósito general, mantenida de forma independiente y con un desarrollo mucho más activo que el de chan_sip. La diferencia no es solo de “modernidad”: es de arquitectura de datos, y ahí está la clave técnica que muchas comparaciones superficiales pasan por alto.
Qué cambia realmente por dentro: la separación Endpoint / AOR / Auth
En chan_sip, cada dispositivo se define como un único bloque monolítico (type=friend o type=peer) donde credenciales, comportamiento de sesión y ubicación de contacto conviven en la misma sección. Cualquier cambio en cómo se autentica un dispositivo obliga a tocar la misma sección que define su comportamiento de llamada.
PJSIP rompe esa configuración en tres objetos independientes que se relacionan entre sí:
- Endpoint: define el comportamiento SIP del dispositivo o troncal —códecs permitidos, contexto de dialplan, políticas de transporte—, pero no contiene credenciales ni información de contacto.
- AOR (Address of Record): le indica a Asterisk dónde está el dispositivo. Puede resolverse de forma estática (una URI fija) o dinámica (vía REGISTER), y admite múltiples contactos simultáneos bajo una misma AOR mediante el parámetro max_contacts —algo que chan_sip no soporta de forma nativa, y que resulta clave cuando un mismo usuario tiene teléfono de escritorio, softphone y app móvil registrados a la vez.
- Auth: aísla exclusivamente las credenciales (usuario/contraseña o MD5), separadas del comportamiento y la ubicación del dispositivo.
Esta separación no es solo prolijidad de configuración: permite reutilizar un mismo objeto Auth o AOR entre múltiples endpoints, facilita la administración vía realtime (bases de datos) en entornos con cientos o miles de extensiones, y reduce el riesgo de errores de configuración cruzada en plataformas de gran escala, como un contact center con múltiples campañas.
Un ejemplo simplificado de cómo se ve esta separación en pjsip.conf:
[6001]
type=endpoint
context=internal
disallow=all
allow=ulaw
aors=6001
auth=auth6001
[6001]
type=aor
max_contacts=1
[auth6001]
type=auth
auth_type=userpass
password=ClaveSegura123
username=6001
Identificación flexible de tráfico entrante
Otra limitación estructural de chan_sip es cómo identifica de qué endpoint proviene una solicitud SIP entrante: depende casi exclusivamente del usuario en el header From. PJSIP, mediante el parámetro identify_by, permite reconocer un endpoint por IP de origen, por usuario, o por credenciales de autenticación en el header, lo cual resuelve escenarios comunes con proveedores SIP que no envían un From predecible —un problema recurrente al conectar un SIP Trunk con operadores locales.
Otras ventajas técnicas de PJSIP frente a chan_sip
- Soporta múltiples transportes simultáneos (UDP, TCP, TLS, WebSocket) en una misma configuración, algo que chan_sip no puede hacer de forma nativa.
- Tiene soporte robusto para WebRTC, clave para integraciones con navegadores y aplicaciones de click-to-call.
- Recibe actualizaciones de seguridad más frecuentes, al depender de una librería externa con desarrollo activo fuera del núcleo de Asterisk.
- Es el canal recomendado oficialmente por el proyecto Asterisk desde hace varias versiones, mientras que chan_sip se mantiene únicamente por compatibilidad retroactiva.
¿Qué implica esto para una empresa?
Si una organización opera hoy una central telefónica Asterisk configurada sobre chan_sip, no significa que su sistema sea inseguro o esté a punto de fallar. Muchas implementaciones estables siguen funcionando sobre este módulo. Pero sí implica una exposición creciente a tres riesgos concretos:
- Menor soporte a futuro: los desarrolladores del núcleo de Asterisk han priorizado PJSIP en nuevas funcionalidades, por lo que chan_sip queda cada vez más rezagado.
- Limitaciones para escalar hacia WebRTC y omnicanalidad, dos tendencias centrales en la evolución de los call centers y centrales telefónicas virtuales.
- Brechas de seguridad potenciales frente a ataques comunes en telefonía IP empresarial, como escaneo de extensiones, fuerza bruta sobre registros SIP o fraude telefónico (toll fraud), áreas donde PJSIP incorpora mecanismos de mitigación más modernos.
Seguridad en chan_sip: puntos que todo responsable de TI debería revisar
Independientemente del canal utilizado, la seguridad en entornos SIP requiere atención constante. Algunas prácticas recomendadas aplicables a infraestructuras que aún operan sobre chan_sip incluyen:
Restricción de acceso por IP: Limitar qué direcciones IP pueden intentar registrarse o enviar tráfico SIP hacia la central reduce drásticamente la superficie de ataque frente a bots que escanean puertos 5060 de forma masiva.
Uso de contraseñas robustas en extensiones: Las credenciales débiles en peers SIP son una de las causas más comunes de fraude telefónico, donde terceros no autorizados generan llamadas internacionales de alto costo a través de una central comprometida.
Segmentación de red: Aislar el tráfico de voz en VLANs dedicadas limita el impacto de una eventual brecha en otros sistemas corporativos.
Monitoreo activo de registros fallidos: Un volumen inusual de intentos de registro fallidos suele ser la primera señal de un intento de intrusión, y debería generar alertas automáticas.
¿Migrar de chan_sip a PJSIP es siempre necesario?
No en todos los casos, y aquí es donde entra el criterio técnico por encima de la tendencia. La decisión de una migración de chan_sip a PJSIP depende de factores como:
- Nivel de exposición de la central a redes públicas o troncales externas.
- Necesidad de integrar WebRTC, aplicaciones móviles o canales de comunicación modernos.
- Complejidad de la red actual (múltiples sedes, NAT complejo, IPv6).
- Antigüedad y estabilidad del sistema actual, evaluando el costo-beneficio de una migración frente a los riesgos de mantener una arquitectura en proceso de deprecación.
Una migración mal planificada puede generar interrupciones de servicio, pérdida de configuraciones de dialplan o incompatibilidades con hardware legado. Por eso, este tipo de decisiones requiere un diagnóstico técnico previo, no solo una actualización reactiva.
Lo que esto significa para la continuidad operativa de tu empresa
La central telefónica de una empresa no es un componente aislado: sostiene la atención al cliente, las ventas, la coordinación interna y, en muchos casos, la operación completa de un call center. Un módulo de señalización SIP mal configurado, desactualizado o vulnerable no solo representa un riesgo técnico abstracto: se traduce en llamadas caídas, fraude telefónico con impacto económico directo, o incapacidad de escalar hacia canales digitales que hoy los clientes esperan.
Comprender la diferencia entre chan_sip y PJSIP, y saber en qué estado se encuentra la infraestructura propia, es el primer paso para tomar decisiones de telecomunicaciones basadas en criterio técnico y no en supuestos.
En NUBENEXO ayudamos a empresas y equipos de TI a evaluar, optimizar y modernizar sus plataformas Asterisk, SIP Trunk y Call Center sin afectar la continuidad operativa. Desde auditorías técnicas de la configuración SIP actual hasta migraciones planificadas de chan_sip a PJSIP, nuestro equipo acompaña cada etapa con soporte especializado y experiencia práctica en entornos empresariales de misión crítica, incluyendo implementaciones sobre ViciDial para call centers de alto volumen.