Universidad Blas Pascal

Ingeniería en Telecomunicaciones

TRABAJO FINAL DE LA CARRERA

Comunicaciones VoIP mediante Asterisk.

Diseño de una PBX para una PyME

Autores:
Abed Carlos
Salvetti Diego
Sanchez Clariá Francisco

Director:
Ing. Juan Galleguillo
Asesor:
Ing. Hector Riso
2006
Agradecimientos

A mi viejo, por haberme dado siempre todo lo que tenía para facilitar el cumplimiento de mis
sueños. A mi mamá, por las fuerzas que siempre me dio su amor incondicional.
Abed Carlos.

A Dios, que siempre está. A mi familia (Carlos, Cristina, Tía Hilda, Dudo y Ariel) que me dan
todo el afecto que necesito, gracias a ellos soy lo que soy. A Lucas G. A mis amigos de Cañada
(Lepra, Ruso, Fafa, Narí, Pecky, Master, etc), los chicos de Rosario y a TODOS los compañeros
que conocí acá, con los cuales pude contar siempre. A mis amigas (Marce, Karla, Silvia, Tamy,
etc) que siempre me escucharon. A la Sa y su familia. A Franco, Legolas ,Santi y Pablo que
soportaron vivir conmigo.
Salvetti Diego.

A mi familia y verdaderos amigos, a mis compañeros de la facu y a ese puñado de profesores que
generan el interés de aprender con su vocación de enseñar.
Sanchez Clariá Francisco.

También a su vez, quisiéramos agradecer a Raúl y a Charlie, por la motivación que nos dieron
para trabajar sobre este proyecto. Y además, agradecer a nuestro amigo El Lagarto, quien con su
aporte nos brindó claridad y calidad en los primeros pasos de este proceso.
Dedicatorias

A tantas personas...mi familia, mis hermanos del San Jorge y mis amigos, quienes han hecho un
aporte invaluable en mi crecimiento como persona, y lo siguen haciendo día a día. A Marcela,
quien amo con el alma, y a Clarita, quien en pocos meses se robará mi corazón.
Abed Carlos.

A mis abuelos/as (Manuela, Irma, Poroto y Atilio) y mi familia, que siempre están presentes en
mi corazón, a los grandes amigos que coseché en mi paso por la Universidad, al Agus y su familia
y a todas las personas que me brindaron su amistad.
Salvetti Diego.

A mis viejos, que dejaron muchos sueños de lado para permitirme estudiar... entre tantas otras
cosas les debo un viaje en globo y un jeep blanco ; ).
Sanchez Clariá Francisco.
Resumen

3
Resumen

El objetivo general de este Trabajo Final es diseñar comunicaciones de VoIP mediante

una PABX Asterisk en una PyME.
Este proyecto de diseño de la implementación Asterisk, surgió a partir de nuestro tra-
bajo realizado en el marco de la práctica profesional llevada a cabo en una pequeña
empresa de informática que comenzaba a desarrollar soluciones en el ámbito de las
comunicaciones.

A partir de trazar éste objetivo y una vez conseguido el potencial cliente para la im-
plementación, se realizó un relevamiento técnico que permitió acotar la solución.

Queda claro en el siguiente trabajo que Asterisk no es un sistema fácil de diseñar, sin
embargo permite obtener diversas soluciones perfectamente ajustables a las necesidades
de comunicaciones de una empresa.

Desde el punto de vista económico, una solución Asterisk pasa a ser rentable cuando se
explotan sus aplicaciones avanzadas, ya que en cuanto a hardware no puede competir
con la fabricación de equipamiento a gran escala.

Además, del diseño propiamente dicho, este trabajo contiene una introducción general
a VoIP, como así también una explicación detallada de un sistema Asterisk, desde su
instalación hasta su configuración avanzada.

4
Índice

Introducción 12

Metodologías 16
1. Estudio de los principios de funcionamiento de VoIP y protocolos 18
1.1. Telefonía Digital . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2. Redes de paquetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3. Voz sobre IP (VoIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.2. Integración de servicios y unificación de estructura. . . . . . . . . . . . . . . 19
1.3.3. Generalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4. Especificaciones H.323 y SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.1. El Estándar H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4.2. La recomendación SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.4.3. Comparación entre H.323 y SIP . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.5. Especificaciones de IAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.5.1. Descripción del Protocolo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.5.2. Frames IAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.6. SIP Vs. IAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.6.1. Calidad de Servicio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

2. Estudio exploratorio sobre Asterisk como PBX de VoIP. 44

2.1. Introducción a Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.1.1. Los Cambios Masivos requieren una tecnología flexible . . . . . . . . . . . . 45
2.2. ¿Qué es una PBX? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.2.1. ¿Cómo se puede comparar Asterisk a una PBX? . . . . . . . . . . . . . . . 46
2.3. ¿Qué es Asterisk? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.3.1. Escenario A - Una oficina en casa . . . . . . . . . . . . . . . . . . . . . . . . 46
2.3.2. Escenario B - Una oficina pequeña . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.3. Escenario C - Una gran Empresa . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4. La revolución telefónica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.5. El Proyecto de telefonía Zapata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.6. La Comunidad Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.7. Documentación de Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.8. Preparando un sistema para Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.8.1. Selección de hardware para el Servidor . . . . . . . . . . . . . . . . . . . . . 50
2.8.2. Aspectos de Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.8.3. Selección de Procesador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5
 2.8.4. Selección de la Placa Madre . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.8.5. Requerimientos de Suministro de Energía . . . . . . . . . . . . . . . . . . . 54
2.8.6. Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.9. Hardware de Telefonía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.9.1. La unión a la PSTN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.9.2. Conexión a una Red Telefónica de Conmutación de Paquetes . . . . . . . . 62
2.10. Tipos de Teléfono . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.10.1. Teléfonos Físicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.10.2. Teléfonos por Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.10.3. Adaptadores de Telefonía . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.10.4. Terminales de Comunicaciones . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.11. Consideraciones de Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
2.12. Instalando Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.12.1. ¿Qué paquetes necesito? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.12.2. Requerimientos de los paquetes . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.12.3. Obteniendo el código fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.12.4. Extrayendo el código fuente . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.12.5. Obteniendo el código fuente de Asterisk desde CVS . . . . . . . . . . . . . 67
2.12.6. Compilando Zaptel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.12.7. El driver ztdummy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.12.8. Drivers telefónicos Zapata . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.12.9. Usando ztcfg y zttool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.12.10.El archivo zconfig.h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.12.11.Compilando libpri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.12.12.Compilando Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.12.13.Usando binarios precompilados . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.12.14.Instalando adicionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.12.15.Otros plugins de utilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.12.16.Actualizando su código fuente . . . . . . . . . . . . . . . . . . . . . . . . . . 77
2.12.17.Cuestiones comunes cuando se compila . . . . . . . . . . . . . . . . . . . . . 77
2.12.18.Cargando los módulos Zaptel . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.12.19.Sistemas corriendo udevd . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.12.20.Cargando Zaptel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.12.21.Cargando ztdummy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.12.22.Cargando libpri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.12.23.Cargando Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.12.24.Comandos CLI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.12.25.Script de inicialización de Red Hat . . . . . . . . . . . . . . . . . . . . . . . 81
2.12.26.Directorios utilizados por Asterisk . . . . . . . . . . . . . . . . . . . . . . . 81
2.12.27.Usuarios, Pares y Amigos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.12.28.Declaraciones de registro . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.13. Configuración inicial de Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.13.1. ¿Qué es realmente necesario? . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.13.2. Trabajando con archivos de configuración de interfaces . . . . . . . . . . . . 86
2.13.3. Canales FXO y FXS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.13.4. Configurando SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.13.5. Configurando Conexiones entrantes IAX . . . . . . . . . . . . . . . . . . . . 95
2.13.6. Depurando . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
2.13.7. Conectando a la Consola . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

6
 2.13.8. Activando Verbosidad y Depuración . . . . . . . . . . . . . . . . . . . . . . 99
2.14. Fundamentos del dial plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.14.1. Sintaxis del dial plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
2.14.2. Un dial plan simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
2.14.3. Las aplicaciones Answer ( ), Playback( ) y Hangup( ) . . . . . . . . . . . . 103
2.14.4. Primer dial plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
2.15. Adición de Lógica al dial plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
2.15.1. Las aplicaciones Background ( ) y Goto ( ) . . . . . . . . . . . . . . . . . . 104
2.15.2. El Manejo de Entradas Inválidas e Intervalos de espera . . . . . . . . . . . . 105
2.15.3. Usando la aplicación Dial ( ) . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.15.4. Contexto para Llamadas Internas . . . . . . . . . . . . . . . . . . . . . . . . 108
2.15.5. Utilización de Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
2.15.6. Correspondencia de Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . 111
2.15.7. Permitiendo llamadas salientes . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.15.8. Inclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
2.16. Más conceptos acerca del Dial plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
2.16.1. Manipulación de variables y expresiones . . . . . . . . . . . . . . . . . . . . 115
2.16.2. Funciones del dial plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
2.16.3. Ramificaciones condicionales . . . . . . . . . . . . . . . . . . . . . . . . . . 118
2.16.4. Correo de voz (Voicemail) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
2.16.5. Macros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
2.16.6. Usando la base de datos Asterisk (AstDB) . . . . . . . . . . . . . . . . . . . 126
2.16.7. Adelantos prácticos de Asterisk . . . . . . . . . . . . . . . . . . . . . . . . 128
2.17. Codecs y Protocolos de VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
2.18. La Necesidad de Protocolos VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
2.18.1. Protocolos de VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
2.19. Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.19.1. G.711 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
2.19.2. G.726 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
2.19.3. G.723.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
2.19.4. G.729A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
2.19.5. GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
2.19.6. iLBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
2.19.7. Speex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
2.19.8. MP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
2.20. Panorama de Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
2.20.1. Desafíos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
2.20.2. Algunas cosas que son posibles . . . . . . . . . . . . . . . . . . . . . . . . . 139

3. Estudio descriptivo de las caracteristicas de una PyME. 142

3.1. Relevamiento técnico en una PyME . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.2. Cuestionario para Relevamiento Técnico . . . . . . . . . . . . . . . . . . . . . . . . 143
3.2.1. Cuestiones Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
3.2.2. Costos actuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.2.3. Cuestiones Personales o de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.2.4. Necesidades Futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
3.2.5. Cuestiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3.3. Informe Relevamiento Técnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3.3.1. Cuestiones Técnicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
3.3.2. Costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147

7
 3.3.3. Cuestiones Personales o de Uso . . . . . . . . . . . . . . . . . . . . . . . . . 147
3.3.4. Cuestiones generales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
3.4. Diagrama de Estados para el IVR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148

4. Diseño de solución VoIP basada en Asterisk en una PyME. 150

4.1. Diseño de una solución de VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.1.1. Diagrama de la Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.1.2. Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.1.3. Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.2. Interconexión Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.2.1. Potencialidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.2.2. IAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
4.2.3. Conectando los Dial Plans . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.2.4. DUNDi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

5. Conclusión 173

A. Acrónimos y siglas 175

8
Índice de figuras

1.1. Protocolos H.323 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

1.2. Protocolos del gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3. Componentes del gatekeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.4. Multiplexión usando un solo puerto UDP . . . . . . . . . . . . . . . . . . . . . . . 38
1.5. Escenario de establecimiento de llamada típico . . . . . . . . . . . . . . . . . . . . 39
1.6. Escenario de finalización de llamada típico . . . . . . . . . . . . . . . . . . . . . . . 40
1.7. Escenario de flujo de media típico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.1. Tarjeta TDM400P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

2.2. Tarjeta X100P . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.3. Banco de canales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.4. Capas de interacción entre Asterisk y el Kernel Linux . . . . . . . . . . . . . . . . 68
2.5. Niveles del directorio de /var. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
2.6. Flujo del control de autenticación con relación a Asterisk. . . . . . . . . . . . . . . 84
2.7. Trapezoide SIP-RTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.8. Imagen de menú de configuración X-lite V2.0 Lin/Win. . . . . . . . . . . . . . . . 94
2.9. Imagen del X-lite v3.0 Win. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.10. Imagen de menú de configuración del X-lite v3.0 Win. . . . . . . . . . . . . . . . . 96
2.11. Puente Asterisk-PBX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
2.12. Tecnología de DID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
2.13. Asterisk emulando PSTN para función VoIP . . . . . . . . . . . . . . . . . . . . . . 141

3.1. Diagrama de estados llamadas externo a interno . . . . . . . . . . . . . . . . . . . 148

3.2. Diagrama de estados llamadas interno a interno . . . . . . . . . . . . . . . . . . . . 149
3.3. Diagrama de estados llamadas interno a externo . . . . . . . . . . . . . . . . . . . 149

4.1. Diagrama de la Red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150

4.2. Trunking de canales deshabilitado . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.3. Trunking de canales habilitado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

9
Índice de tablas

1.1. Comparación entre H.323 y SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.1. Pautas sobre los requerimientos del sistema. . . . . . . . . . . . . . . . . . . . . . . 49

2.2. Referencia rápida de codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

10
Introducción

11
Introducción

La tecnología de Voice over IP (VoIP), cuyo origen se remonta muchos años atrás
cuando comenzaron los primeros experimentos de transmisión de voz sobre redes de
paquetes, ha cobrado una importancia tremenda en los últimos años, dando lugar a
grandes esfuerzos e inversiones que, sin duda, están revolucionando las redes telefónicas
y, sobre todo, los servicios y aplicaciones que ésta nos ofrece.

VoIP es muy adecuada para dar un servicio de telefonía de larga distancia a bajo precio
ya que todas las llamadas se facturan como locales. Además las llamadas en general
presentan una menor tarifa y si se trata de comunicaciones entre equipos de VoIP las
comunicaciones son directamente sin costo, excepto del propio mantenimiento de la
conexión de banda ancha utilizada para unirse a la red de redes.

Aunque el ahorro no es la única motivación de VoIP: su impulso se centra principal-

mente en la convergencia de datos y voz, lo que posibilita aunar servicios y derivar las
comunicaciones personales a un único servicio de mensajería más potente y con mayores
aplicaciones (Cambronero, 2005).

Además, las funcionalidades que permite la implementación de centrales IP para las

empresas extiende las facilidades que una central normal posee. En este sentido los ser-
vicios de call center se destacan entre las ventajosas características que presenta, junto
con una unificación de los servicios provistos a la empresa (García, 2006).

Una de las formas de efectivizar la reducción de costos que implica el uso de VoIP, su-
mado a la cuestión del ahorro en la tarifación de llamadas, es la posibilidad de utilizar
sistemas abiertos de distribución libre.

La General Public License (GPL) (GNU) comprende una serie de términos en el

contrato que, a diferencia de otras licencias, protege principalmente al usuario final,
otorgándole mayor libertad para su uso, ya que no sólo se puede modificar el progra-
ma sino que también siempre se podrá encontrar otras alternativas -ya sean pagadas
o gratuitas- pero, sin duda, siempre mas económicas que las alternativas de software
propietario.

La licencia GNU se obliga a poner a disposición del usuario el código fuente. El bene-
ficio que el código sea abierto queda a la vista en GNU/LINUX y sus distribuciones.
Este sistema operativo es el que más ha evolucionado en los últimos años, precisamente
gracias a su código, que comunidades de usuarios han corregido y modificado convir-
tiéndolo en un sistema mas accesible, seguro, rápido y confiable (Bezama, 2006).

12
Asterisk es un proyecto Open Source basado en la licencia descripta anteriormente,
que conforma una plataforma Private Branch eXchange (PBX) e Interactive Voice
Response (IVR) híbrida Time Division Multiplexing (TDM) y voz sobre paquetes. Es
probablemente el software de telecomunicaciones mas poderoso, flexible y extensible dis-
ponible. Asterisk está diseñado como interface entre, virtualmente, cualquier hardware
o software de telefonía con aplicaciones telefónicas, de manera robusta y consistente
(Spenser, 2005).

Tradicionalmente, los productos de telefonía se diseñan para satisfacer una necesidad

técnica específica de la red. Sin embargo, muchas aplicaciones en uso en telefonía com-
parten una importante cantidad de tecnologías. Asterisk intenta tomar provecho de
esta sinergia para crear un entorno que pueda ser modelado para ajustarse a cualquier
aplicación, o conjunto de aplicaciones.

Asterisk puede, entre otras cosas, ser usados en cualquiera de estas aplicaciones:
Gateway heterogéneo de VoIP(Haciendo uso de MGCP, SIP, IAX, H.323)
Intercambio de Rama Privada (Private Branch eXchange - PBX)
Servidor adaptable de Respuesta de Voz Interactiva (IVR)
Softswitch
Servidor de conferencias
Traducción de números
Aplicaciones de tarjeta de llamada
Discador predictivo
Llamadas en espera con agentes remotos
Oficinas remotas para PBX existentes
Quizás lo más importante es que puede cumplir con todos estos roles simultáneamente
y entre todas sus interfaces.

Otra ventaja de Asterisk es que fue diseñado para permitir que nuevas interfaces y
tecnologías sean agregadas fácilmente. Su meta suprema es dar soporte a todas las tec-
nologías de telefonía disponibles. En general, las interfaces se dividen en tres categorías:
hardware Zaptel, hardware no-Zaptel y voz en paquetes.

Las interfaces Zaptel pseudo TDM permiten integración con la telefonía tradicional
analógica y digital, incluyendo conexión con la red pública. Además, proveen conmuta-
ción pseudo-TDM entre ellas, para mantener la latencia prácticamente inexistente en
llamadas y conferencias TDM.

Las interfaces de hardware no-Zaptel proveen conectividad a los servicios de telefonía

tradicionales, pero no soportan conmutación pseudo-TDM.

Los protocolos de voz en paquete permiten la comunicación sobre redes de paquetes

(Internet Protocol (IP) y Frame Relay). Son las únicas interfaces que no requieren

13
hardware especializado de ninguna clase.
Los soportados actualmente son:
Protocolo de Inicialización de Sesión, SIP
Intercambio entre Asterisk,IAX versión 1 y 2
MGCP
ITU H.323
VoFR
El presente trabajo trata sobre el diseño de una implementación de una PBX Asterisk
en el entorno de una Pequeña y Mediana Empresa (PyME). Esta implementación está
en función de las características y necesitdades que se analizaron en la empresa, y per-
mite ver la total flexibilidad de esta solución de comunicacions que puede adaptarse a
las necesidades particulares de cada caso.

A partir de un relevamiento técnico, se diseñó dicha solución principalmente para dar

servicios de PBX a una cantidad determinada de internos, con algunas funciones adi-
cionales como IVR, definición de un Dial Plan, Voice Mail, entre otros.

El objetivo general de este Trabajo Final es diseñar comunicaciones de VoIP mediante

una PBX Asterisk en una PyME.

14
Metodologías

15
Metodologías

1. Estudio exploratorio de carácter bibliográfico de los principios de fun-

cionamiento de VoIP y sus protocolos asociados.
Se estudiaron las características de VoIP, los protocolos de inicio de sesión
más difundios (H.323, SIP, IAX2), protocolos de tiempo real (RTP), para
lo cual se indagó en materiales tales como recomendaciones de ITU-T
(2000) e informes del IETF (2001) entre otros.
2. Estudio exploratorio de carácter bibliográfico sobre Asterisk como PBX
de VoIP.
Se analizaron los protocolos de manejo de sesión (IAX2, SIP), interfaces
físicas comerciales, codecs soportados. Se describe también la arquitectura
básica de Asterisk, su configuración y manejo, basando tal estudio en
libros dedicados a la PBX Asterisk(2005) y sitios webs sobres VoIP(2006).
3. Estudio descriptivo de las caracteristicas de una PyME para establecer
parámetros de diseño.
Unidad de analisis: PyME Agente Oficial de Hewllet Packard. Variables:
Cantidad de internos
Lineas entrantes y salientes
Equipamiento necesario
Instalacion existente
Costos de implementación
Necesidades de comunicacion
Caracteristicas de la empresa
Técnica: Se realizaó un relevamiento técnico a través de entrevistas con
el personal de sistemas de la PyME.
4. Diseño de una solución de comunicaciones de VoIP basada en Asterisk
en una PyME.
Se dieñó una central de VoIP, prestando servicios a una determinada
cantidad de internos, soportando funciones de VoiceMail e IVR, entre
otros.

16
Resultado y discusión

17
1. Estudio exploratorio de carácter bibliográfico de los
principios de funcionamiento de VoIP y sus protocolos
asociados.

1.1. Telefonía Digital

La telefonía analógica está prácticamente en desuso.
En la Public Switched Telephone Network (PSTN) la famosa última milla es el tramo
final que resta de la telefonía utilizada desde hace decenas de años.
Uno de los principales retos cuando se transmiten señales analógicas es que todo tipo
delementos pueden interferir o atenuar la señal causando volumen bajo, estática y toda
una gama de efectos indeseados. En lugar de intentar preservar la forma de onda analó-
gica para distancias de cientos de kilómetros resulta mejor medir ciertas características
de la señal original y enviar esta información al extremo lejano. De manera tal que con
la información enviada se pueda reconstruir la información del sonido.
Este es el principio de todo el audio digital, incluyendo la telefonía: se muestrea la onda
sonora, se guarda y transmite la información muestreada y se reconstruye en el extremo
opuesto, esta reconstrucción trata de ser lo mejor posible para que el oído no detecte
diferencias.
Una de las ventajas de este método es que las muestras pueden ser procesadas ma-
temáticamente para chequear errores producidos durante el transporte de manera de
asegurar que los datos lleguen de manera intacta al otro lado. Así, la distancia no afecta
la calidad y la interferencia se puede detectar y eliminar.
De las diversas formas que hay para codificar el audio, el método más usado y el que se
usa en los sistemas de red telefónica es conocido como Pulse Code Modulation (PCM),
y es el formato base a partir del cual otros codecs! (codecs!) manipulan los datos.
A pesar que el oído humano percibe vibraciones en un rango de 20 a 20000Hz, la
mayoría de los sonidos emitidos al hablar caen en el rango de los 250 a los 3000Hz. Ya
que el objeto de la red telefónica es transmitir vibraciones del habla, se diseñó el ancho
de banda en el rango de los 300 a los 3500Hz (lo que implica que cierta calidad se va a
perder especialmente en el rango de las altas frecuencias).
El muestreo PCM de la voz se realiza a 8000 muestras por segundo lo que permite
reconstruir cómodamente la señal de audio del teléfono para el ancho de banda que
ésta utiliza. Además del muestreo, la señal es cuantificada de una manera no lineal
para asegurar una buena resolución a lo largo de todo el rango dinámico de la señal. A
tal efecto es que se utiliza la ley µ en Estados Unidos y la ley A en el resto del mundo.
1.2 Redes de paquetes 19

1.2. Redes de paquetes

Hacia mediados de los 90’s la performance de las redes mejoraron a tal punto que se
hizo posible enviar un flujo de información en tiempo real a través de la red. Dado que
el flujo de datos está separado en segmentos, los que están envueltos en un paquete para
su direccionamiento, es que se conoce a las conexiones como basadas en paquetes. El
reto, claro está, es enviar miles de paquetes entre dos puntos asegurando que llegarán
en el mismo orden en que se los envió y en menos de 300 milisegundos (para que el
delay no sea percibido en la conversación), sin pérdida de paquetes. Éste es el objetivo
de la VoIP.

1.3. Voz sobre IP (VoIP)

1.3.1. Introducción
Hace 30 años Internet no existía, y las comunicaciones se realizaban por medio del telé-
fono a través de la PSTN, pero con el pasar de los años y el avance tecnológico han ido
apareciendo nuevas tecnologías y aparatos bastante útiles que nos han permitido pen-
sar en nuevas tecnologías de comunicación: Personal Communications Service (PCS),
teléfonos celulares y finalmente la popularización de la gran red Internet. Hoy por
hoy podemos ver una gran revolución en las comunicaciones: todas las personas usan
las computadoras e Internet en el trabajo y en su tiempo libre para comunicarse con
otras personas y para intercambiar datos usando en los comienzos aplicaciones como
NetMeeting.
Después de haber constatado que desde una Personal Computer (PC) con elementos
multimedia, es posible realizar llamadas telefónicas a través de Internet, se puede pensar
que la telefonía en IP es algo más que un juguete, pues la calidad de voz que se obtiene
a través de Internet es más que aceptable.
Si en una empresa se dispone de una red de datos que tenga un ancho de banda bastante
grande, también se podría pensar en la utilización de esta red para el tráfico de voz
entre las distintas delegaciones de la empresa. Las ventajas que se obtendrían al utilizar
la red para transmitir tanto la voz como los datos son evidentes: ahorro de costos de
comunicaciones, pues las llamadas entre las distintas delegaciones de la empresa saldrían
gratis.

1.3.2. Integración de servicios y unificación de estructura.

Realmente la integración de la voz y los datos en una misma red es una idea antigua,
pues desde hace tiempo han surgido soluciones desde distintos fabricantes que, median-
te el uso de multiplexores, permiten utilizar las redes Wide Area Network (WAN) de
datos de las empresas (típicamente conexiones punto a punto y Frame-Relay) para la
transmisión del tráfico de voz. Además es importante resaltar que el paquete de voz es
indistinguible del paquete de datos, y por lo tanto puede ser transportado a través de
una red que estaría normalmente reservada para transmisión de datos, donde los costos
son frecuentemente más bajos.
Es innegable la implantación definitiva del IP desde los ámbitos empresariales a los do-
mésticos y la aparición de un estándar, el VoIP, no podía hacerse esperar. La aparición
1.3 Voz sobre IP (VoIP) 20

del VoIP junto con el abaratamiento de los Digital Processor Signal (DSP), los cuales
son claves en la compresión y descompresión de la voz, son los elementos que han hecho
posible el depliegue de estas tecnologías.
Para este auge existen otros factores, tales como la aparición de nuevas aplicaciones o la
apuesta definitiva por VoIP de fabricantes como Cisco Systems o Nortel-bay Networks.
Por otro lado los operadores de telefonía están ofreciendo o piensan ofrecer en un futuro
cercano, servicios IP de calidad a las empresas.

1.3.3. Generalidades
¿Qué es VoIP?

VoIP viene de Voice Over Internet Protocol. Como dice el termino VoIP intenta permitir
que la voz viaje en paquetes IP y obviamente a través de Internet.
La telefonía IP conjuga dos mundos históricamente separados: la transmisión de voz
y la de datos. Se trata de transportar la voz, previamente convertida a datos, entre
dos puntos distantes. Esto posibilitaría utilizar las redes de datos para efectuar las
llamadas telefónicas, y yendo un poco más allá, desarrollar una única red convergente
que se encargue de cursar todo tipo de comunicación, ya sea voz, datos, video o cualquier
tipo de información.
La voz IP, por lo tanto, no es en sí mismo un servicio, sino una tecnología que permite
encapsular la voz en paquetes para poder ser transportados sobre redes de datos sin
necesidad de disponer de los circuitos conmutados convencionales PSTN.
Las redes desarrolladas a lo largo de los años para transmitir las conversaciones vocales,
se basaban en el concepto de conmutación de circuitos, o sea, la realización de una
comunicación que requiere el establecimiento de un circuito físico durante el tiempo
que dura ésta, lo que significa que los recursos que intervienen en la realización de
una llamada no pueden ser utilizados en otra hasta que la primera no finalice, incluso
durante los silencios que se suceden dentro de una conversación típica.
En cambio, la telefonía IP no utiliza circuitos para la conversación, sino que envía
múltiples dellas (conversaciones) a través del mismo canal codificadas en paquetes y
flujos independientes. Cuando se produce un silencio en una conversación, los paquetes
de datos de otras conversaciones pueden ser transmitidos por la red, lo que implica un
uso más eficiente de la misma.
Son evidentes las ventajas que proporciona el segundo tipo de red, ya que con la mis-
ma infraestructura podrían prestar mas servicios y además la calidad de servicio y la
velocidad serian mayores; pero por otro lado también existe la gran desventaja de la
seguridad, ya que no es posible determinar la duración del paquete dentro de la red
hasta que este llegue a su destino y además existe la posibilidad de perdida de paquetes,
ya que el protocolo IP no cuenta con esta herramienta.

¿Cómo funciona VoIP?

Años atrás se descubrió que mandar una señal a un destino remoto podía hacerse
también de manera digital: antes de enviar la señal se debía digitalizar con un ADC
(analog to digital converter), transmitirla y en el extremo de destino transformarla de
nuevo a formato análogo con un DAC (digital to analog converter).
1.3 Voz sobre IP (VoIP) 21

VoIP funciona de esa manera, digitalizando la voz en paquetes de datos, enviándola a

través de la red y reconvirtiéndola a voz en el destino. Básicamente el proceso comienza
con la señal análoga del teléfono que es digitalizada en señales PCM (pulse code modu-
lación) por medio del codificador/decodificador de voz (codec). Las muestras PCM son
pasadas al algoritmo de compresión, el cual comprime la voz y la fracciona en paquetes
que pueden ser transmitidos para este caso a través de una red privada WAN. En el otro
extremo de la nube se realizan exactamente las mismas funciones en un orden inverso.
Dependiendo de la forma en la que la red este configurada, el enrutador o el gateway
puede realizar la labor de codificación, decodificación y/o compresión. Por ejemplo,
si el sistema usado es un sistema análogo de voz, entonces el enrutador o el gateway
realizará todas las funciones mencionadas anteriormente.
Si, por otro lado, el dispositivo utilizado es una PBX digital, es entonces éste el que rea-
liza la función de codificación y decodificación, y el enrutador solo se dedica a procesar
las muestras PCM que le ha enviado el PBX.
Para el caso en el que el transporte de voz se realiza sobre la red pública Internet, se
necesita una interfaz entre la red telefónica y la red IP, el cual se denomina gateway
y es el encargado en el lado del emisor de convertir la señal analógica de voz en pa-
quetes comprimidos IP para ser transportados a través de la red. Del lado del receptor
su labor es inversa, dado que descomprime los paquetes IP que recibe de la red de
datos, y recompone el mensaje a su forma análoga original conduciéndolo de nuevo a
la red telefónica convencional en el sector de la última milla, para ser transportado al
destinatario final y ser reproducido por el parlante del receptor.
Es importante tener en cuenta también que todas las redes deben tener de alguna forma
las características de direccionamiento, enrutamiento y señalización. El direccionamien-
to es requerido para identificar el origen y destino de las llamadas, también es usado
para asociar clases de servicio a cada una de las llamadas dependiendo de la prioridad.
El enrutamiento por su parte encuentra el mejor camino a seguir por el paquete desde
la fuente hasta el destino y transporta la información a través de la red de la mane-
ra más eficiente, la cual ha sido determinada por el diseñador. La señalización alerta
las estaciones terminales y a los elementos de la red su estado y la responsabilidad
inmediata que tienen al establecer una conexión.

Protocolo De Transporte En Tiempo Real RTP

RTP (Real-time Transport Protocol ) o protocolo de transporte en tiempo real, es un

protocolo que como su nombre lo indica, está orientado a la transmisión de información
en tiempo real, como la voz o el video. Este es un protocolo de las capas superiores de
usuario que funciona sobre UDP (Usar Datagram Protocol ) haciendo uso de los servicios
de checksum y multiplexación, para proporcionarle a los programas que generan este
tipo de datos, un manejo de transmisiones en tiempo real a través de difusiones unicast
o multicast. En UDP se cambia confiabilidad por velocidad, lo cual es básico para
manejo de transmisiones en tiempo real como la VoIP.
Aunque RTP no es suficientemente confiable por si solo, este proporciona relaciones con
protocolos y aplicaciones de capas inferiores y recursos proporcionados por los switches
y enrutadores para garantizar confiabilidad. Los paquetes RTP no contienen campo
de longitud, ya que al funcionar sobre UDP, este protocolo es quien encapsula la voz
comprimida en datagramas.
1.4 Especificaciones H.323 y SIP 22

La herramienta de la que se vale RTP para lograr transmisiones en tiempo real es el

RTCP (Real-Time Control Protocol ) que proporciona un feedback acerca de la calidad
de distribución y la congestión. Con esto, la empresa que ofrece el servicio puede moni-
torear la calidad y puede diagnosticar los problemas que pueda presentar la red, además
de esto, RTCP sincroniza el audio y el video, conoce el número de usuarios presentes
en una conferencia y con esto calcula la tasa a la cual deben ser enviados los paquetes.
Todas estas opciones son obligatorias cuando RTP se usa en entornos multicast IP.
Existe otra aplicación opcional y es una administración de sesiones con bajo manejo
de información de control para aquellas aplicaciones donde hay uso masivo de usuarios
entrando y saliendo constantemente.
Para la compresión, RTP usa una aplicación llamada "vocoder"pudiendo reducir de
64 kbps hasta 8 kbps la tasa para digitalización y compresión de voz produciendo un
desmejoramiento en la calidad de la voz poco perceptible.
RTP es capaz de correr sobre protocolos WAN de alta velocidad como ATM sin ningún
problema, también en redes asimétricas como ADSL, cable-modem o por enlace satelital
pero cumpliendo con ciertas características de ancho de banda para ambas direcciones
y uso exclusivo para la aplicación RTP.

1.4. Especificaciones H.323 y SIP

Como vimos la telefonía IP requiere ciertos protocolos para establecer y controlar las
conexiones. En este sentido dos protocolos se destacan: H.323 y SIP. La recomendación
H.323 contiene un conjunto protocolos para comunicaciones multimedia tales como
H.245, H.225.0, H.332, H.450.1, H.450.2, H.450.3, H.235 y H.246. H.323 está basada
en el protocolo de señalización Q.931 de ISDN. SIP, en cambio, utiliza muchos de los
mecanismos usados en HTTP. Ambas tecnologías utilizan RTP para el transporte de
los datos multimedia.

1.4.1. El Estándar H.323

El estándar H.323 posibilita en intercambio de servicios multimedia (audio, video y
datos en tiempo real) sobre redes de paquetes, lo que incluye las redes IP y forma
parte de un conjunto de recomendaciones de la ITU-T llamadas H.32x que proveen
comunicaciones multimedia sobre todo tipo de redes.

Componentes de H.323

H.323 especifica los siguientes componentes que posibilitan la comunicación multimedia:

Terminales
Gateways
Gatekeepers
MCU (Unidades de Control Multipunto)
1.4 Especificaciones H.323 y SIP 23

Terminales

Se utilizan para comunicaciones multimedia bidireccionales de tiempo real. Sirve para

comunicaciones de audio y opcionalmente puede usarse para video y datos. Puede
tratarse tanto de una PC como de un dispositivo corriendo una aplicación multimedia
utilizando H.323. Estos terminales H.323 pueden también ser usados en conferencias
multipunto.

Gateways

Se utilizan para interconectar redes disímiles. Conecta en definitiva, redes H.323 con
redes que no son H.323. Puede conectar, por ejemplo, terminales de una red H.323 y
redes PSTN. Para lograr esta interconexión, se traducen protocolos de una red hacia
la otra usando el gateway. Dentro de una misma red H.323 no es necesario utilizar un
gateway.

Gatekeepers

Se lo puede considerar como un portero en una red H.323. Aquí se efectúan las tareas
de direccionamiento, autenticación tanto de terminales como gateways, gestión de an-
cho de banda y contabilidad. Pueden también proveer servicios de encaminamiento de
llamadas.

MCU o Unidades de Control Multipunto

Éstas proveen soporte para realizar conferencias. A tal efecto los terminales que deseen
participar deberán conectarse al MCU. Así, el MCU gestionará los recursos negociando
entre terminales. Gatekeepers, Gateways y MCU pueden ser componentes que físi-
camente estén integrados en un solo equipo, aunque de manera lógica implementen
funciones totalmente separadas.

Zonas H.323

Se denomina Zona a un conjunto de gateways, MCU y terminales que son gestionados

por solo gatekeeper. Esto debe incluir al menos un terminal y opcionalmente gateways
y MCUs, pero un solo gatekeeper. Las zonas no necesitan pertenecer a una misma topo-
logía de red y pueden esta compuestas por distintos segmentos de red interconectados
usando routers por ejemplo.
1.4 Especificaciones H.323 y SIP 24

Fig. 1.1: Protocolos H.323

Protocolos especificados por H.323

Los protocolos especificados por H.323 son:

Codecs de audio
Codecs de video
Registro, Admisión y Estado H.225 (RAS)
Señalización de llamadas H.225
Señalización de control H.245
Protocolo de transferencia en tiempo real (RTP)
Protocolo de control en tiempo real (RTCP)
H.323 es independiente de la red de paquetes y de los protocolos de transporte sobre
los cuales corre y no establece especificaciones sobre estos.
Codec de audio: permite la codificación de las señales de audio que ingresan al teminal
H.323 para ser transmitidas y decodifica el audio recibido para que sea reproducido por
el parlante.
Todos los terminales H.323 deben soportar al menos un codec de audio como se espe-
cifica en las recomendaciones ITU-T G.711 (i.e., codificación a 64kbps). Puede opcio-
nalmente soportar otros tales como G.722, G.723, G.728 y G.729.
Codec de video: permite codificar la señal de video que ingresa al terminal transmisor y
decodificar los datos de video codificado recibidos para enviarlos al monitor. El soporte
de este codec es opcional dado que también lo es el soporte de video en H.323.
RAS, registro, admisión y estado H.225: se trata de un protocolo usado entre los termi-
nales y gateways (puntos terminales) y el gatekeeper. RAS es usado para las funciones
de registro, control de admisión y gestión de ancho de banda entre puntos terminales y
gatekeeper, entre otras funciones. Para los mensajes RAS se utiliza lo que se denomina
un canal RAS, que es un canal de señalización que está abierto entre una Terminal y
el gatekeeper antes del establecimiento de cualquier otro canal.
Señalización de llamadas H.225: esta señalización se utiliza para el establecimiento de
las conexiones entre dos puntos terminales H.323, mediante el intercambio de mensajes
1.4 Especificaciones H.323 y SIP 25

sobre el canal de señalización. Éste canal existe entre dos puntos terminales H.323 o
entre un terminal y un gatekeeper.
Señalización de Control H.245: esta señalización se usa para manejar la operación de los
puntos extremos H.323 intercambiando mensajes de control que transportan la siguiente
información:
Intercambio de capacidades
Apertura y cerrado de canales lógicos usados para transportar flujos multimedia
Mensajes de control de flujo
Comandos e indicaciones generales
Protocolo de Transporte en Tiempo Real, RTP: es el encargado de aprovisionar la en-
trega de audio y video en tiempo real de extremo a extremo. Es usado, de manera
típica, para transportar datos usando UDP.
RTP provee identificación del tipo de carga, numeración de secuencia, time-stamping
(impresión de tiempo), y monitorización de la entrega. UDP provee multiplexación y
servicios de control de errores (checksum). RTP puede ser además utilizado con otros
protocolos de transporte.
Protocolo de Control de Transporte en Tiempo Real, RTCP: provee los servicios de con-
trol para RTP, brindando principalmente realimentación sobre la calidad de la distribu-
ción de los datos. Además, permite transportar un identificador de capa de transporte
para una fuente RTP que se denomina nombre canónico, el cual se usa en los receptores
para sincronizar el audio y video.

Características de un Terminal H.323

Los terminales H.323 deben implementar los siguientes protocolos:

H.245 para intercambiar capacidades de los terminales y la creación de canales del
medio.
H.225 para establecimiento y señalización de llamadas
RAS para registro y control de admisión contra un gatekeeper
RTP/RTCP para secuenciar paquetes de audio y video
Los terminales H.323 deben soportar codec de audio G.711. Los componentes opcionales
en un terminal H.323 son codec de video, protocolos de conferencia de datos T.120 y
capacidades MCU.

Características de Gateways y Gatekeepers

Como fue mencionado, un gateway posibilita la traslación de protocolos para comunicar

redes H.323 con redes que no lo son. Una aplicación es en telefonía IP, donde un gateway
conecta una red IP con una red de conmutación de circuitos por ejemplo.
Sobre la red H.323 el gateway se vale de la señalización H.245 para intercambiar las
capacidades y señalizar llamadas y usa RAS H.225 (registro, admisión y estado) para
registrarse con un gatekeeper. Del lado de la red de conmutación de circuitos (SCN),
un gateway corre los protocolos específicos de su red (ejemplo, señalización SS7 ).
1.4 Especificaciones H.323 y SIP 26

Fig. 1.2: Protocolos del gateway

Los terminales se comunican con el gateway utilizando el protocolo de señalización de

control H.245 y el protocolo de señalización de llamadas H.225. El gateway traslada
estos protocolos en una manera transparente hacia la contraparte respectiva en la red
que no es H.323 y viceversa.
El gateway también desempeña el establecimiento y liberación de llamadas en ambos
lados de la red. La traslación entre formatos de audio, video y datos también puede ser
realizada por el Gateway.
Los Gatekeepers tienen conocimiento de cual de los puntos terminales son gateways
porque esto es indicado cuando el terminal y el gateway se registran con el gatekeeper.
Ya que un gateway es un componente lógico de H.323, éste puede ser implementado
como parte de un gatekeeper o un MCU.

Características de un Gatekeeper

Los gatekeepers se encargan de proveer servicios para controlar las llamadas tales como
traslación de dirección y gestión de ancho de banda y son opcionales dentro de una red
H.323. Sin embargo cuando un gatekeeper existe en la red, terminales y gateways se
ven obligados a utilizarlos. H.323 define un conjunto de servicios obligatorios y otros
opcionales que deben ser brindados por el gatekeeper.
Una característica opcional del gatekeeper es el encaminamiento de señalización de
llamadas.
Los puntos terminales envían mensajes de señalización de llamadas al gatekeeper, y
estos mensajes son encaminados por los gatekeeper hacia los puntos terminales desti-
natarios.
Alternativamente, los puntos terminales pueden enviar un mensaje de señalización de
llamada directamente hacia el punto terminal par. Esta característica del gatekeeper es
importante ya que el monitoreo de las llamadas por el gatekeeper proveen mejor control
de las llamadas en la red. El encaminamiento de llamadas a través del gatekeeper,
provee mejor desempeño en la red, ya que puede tomar decisiones de encaminamiento
basándose en una variedad de factores, por ejemplo, el balanceo de carga entre gateways.
1.4 Especificaciones H.323 y SIP 27

Fig. 1.3: Componentes del gatekeeper

RAS define los servicios de un gatekeeper entre los que se encuentra la traslación de
direcciones, control de admisión, control de ancho de banda y gestión de zonas.
Las redes H.323 que contienen gateways de telefonía IP deben también contener un
gatekeeper para trasladar las direcciones de telefonía entrante bajo el formato definido
en la norma E.164 a direcciones de transporte.
Un gatekeeper es un componente lógico de H.323 pero puede ser implementado como
parte de un gateway o un MCU. En la figura se muestran los componentes de un
gatekeeper.
Funciones obligatorias del Gatekeeper
Traslación de direcciones: Las llamadas originadas dentro de una red H.323 pueden
utilizar un alias para direccionar el terminal de destino. Las llamadas originadas fuera de
la red H.323 y recibidas por un gateway, pueden usar un número telefónicos E.164 (por
ejemplo: 310-442-9222) para direccionar el terminal destino. El gatekeeper traslada
este número telefónico E.164 o el alias a una dirección de red (ejemplo: 204.252.32:456
para una red basada en IP) para el terminal destinatario. El punto terminal destino
puede ser alcanzado usando la dirección de red en una red H.323.
Control de Admisión: El gatekeeper puede controlar la admisión de los puntos ter-
minales dentro de la red H.323. Utiliza mensajes RAS, Pedido de admisión (ARQ),
Confirmación (ACF) y Rechazo (ARJ) para lograr esto.
La función de control de admisión puede ser anulada, por lo tanto se admiten todos los
puntos terminales a la red H.323.
Control de Ancho de Banda: El gatekeeper provee soporte para el control de ancho de
banda mediante el uso de mensajes RAS, requerimiento de ancho de banda (BRQ),
confirmación (BCF) y rechazo (BRJ).
Por ejemplo, si un gestor de red tiene especificado un umbral para el número de cone-
xiones simultáneas en una red H.323, el gatekeeper puede rechazar el establecimiento
de alguna conexión nueva una vez que se alcanzó el límite. El control de ancho de banda
puede ser también una función anulada y con esto se aceptan todos los requerimientos
para cambios de ancho de banda.
1.4 Especificaciones H.323 y SIP 28

Gestión de Zonas: El gatekeeper provee las funciones anteriores para terminales, gate-
ways, y MCU situadas dentro de sus zonas de control.
Funciones opcionales del Gatekeeper
Señalización del control de llamadas: El gatekeeper puede encaminar los mensajes de
señalización de llamadas entre los puntos terminales H.323. En una conferencia punto
a punto, el gatekeeper puede procesar mensajes de señalización de llamadas H.225.
Alternativamente, el gatekeeper puede permitir a los puntos terminales enviar mensajes
de señalización de llamadas H.225 directamente entre ellos.
Autorización de llamadas: Cuando un punto terminal envía mensajes de señalización
de llamadas a un gatekeeper, el gatekeeper puede aceptar o rechazar la llamada, de
acuerdo a las especificaciones H.225.
La razón para el rechazo puede incluir restricciones basadas en el acceso o basadas en
el tiempo, hacia o desde un terminal o gateway en particular.
Gestión de llamadas: El gatekeeper puede mantener información acerca de todas las
llamadas H.323 activas, de modo que puede controlar su zona mediante la provisión de
información retenida a la función de gestión de ancho de banda o mediante el desborde
de llamadas a diferentes puntos terminales para alcanzar el balanceo de cargas.

Registro, Admisión y Estado H.225

El RAS H.225 es usado entre puntos terminales H.323 (terminales y gateways) y gate-
keepers para lo siguiente:
Descubrimiento del gatekeeper (GRQ)
Registro de puntos terminales
Localización de puntos terminales
Control de admisión
Pruebas de acceso
Los mensajes RAS son transportados sobre un canal RAS que no es confiable. Por
lo tanto, el intercambio de los mensajes RAS puede ser asociado con un time out o
contadores.
Descubrimiento del Gatekeeper: El proceso de descubrimiento del gatekeeper es utiliza-
do por los puntos terminales H.323, para determinar el gatekeeper con el cual el punto
terminal debe registrarse. El descubrimiento del gatekeeper puede ser realizado está-
ticamente o dinámicamente. En el descubrimiento estático, el punto terminal conoce
a priori la dirección de transporte de su gatekeeper. En el método dinámico, el punto
terminal realiza un multicast de mensajes GRQ "¿Cual es mi gatekeeper?" sobre la
dirección de multicast de descubrimiento del gatekeeper.
Registro del Punto Terminal: El registro es un proceso usado por los puntos terminales
para unirse a una zona e informar al gatekeeper de las direcciones de alias y transporte
de la zona.
Todos los puntos terminales se registran con un gatekeeper como parte de sus configu-
raciones.
Localización de puntos terminales: La localización de puntos terminales es un proceso
por el cual la dirección de transporte de un punto terminal es determinada, dado su
nombre de alias o dirección E.164.
1.4 Especificaciones H.323 y SIP 29

Otros Controles: El canal RAS es utilizado para otro tipo de mecanismos de control,
tales como control de admisión, para restringir la entrada de un punto terminal dentro
de una zona, control de ancho de banda, y control de desconexión cuando un punto
terminal es desasociado de un gatekeeper y su zona.

Señalización de llamadas y de Control

Señalización de Llamadas H.225

La señalización H.225 se usa para el establecimiento de las conexiones entre terminales
H.323 (terminales y gateways). Para el transporte de los mensajes H.225 se usa un
canal confiable como ser TCP en una red H.323 basada en IP.
Los mensajes se intercambian entre terminales siempre que no exista un gatekeeper en
la red. De existir un gatekeeper, pueden ser encaminados entre terminales (directo) o
bien, a través del gatekeeper.
Señalización de llamadas encaminadas por el gatekeeper: Los mensajes de admisión
son intercambiados entre los puntos terminales y el gatekeeper sobre canales RAS. El
gatekeeper recibe los mensajes de señalización de llamadas sobre el canal de señalización
proveniente de un punto terminal y los encamina hacia el otro punto terminal, sobre el
canal de señalización de llamadas del otro punto terminal.
Señalización de llamada directa: Durante la confirmación de admisión, el gatekeeper
indica que el punto terminal puede intercambiar mensajes de señalización de llamadas
directamente. Los puntos terminales intercambian la señalización de llamadas sobre el
canal de señalización de llamadas.
Señalización de Control H.245
La señalización de control H.245 consiste en el intercambio de mensajes H.245 extremo
a extremo entre puntos terminales H.323 que están en comunicación. Los mensajes de
control H.245 son transportadas sobre canales de control H.245. El canal de control
H.245 es el canal lógico 0 y está permanentemente abierto, a diferencia de los canales
del medio.
Los mensajes transmitidos incluyen mensajes para intercambiar capacidades de los
terminales y para abrir y cerrar canales lógicos.
Intercambio de capacidades: Un canal lógico transporta información de un punto ter-
minal a otro (en el caso de una conferencia punto a punto) o hacia múltiples puntos
(en el caso de una conferencia punto a multipunto).

1.4.2. La recomendación SIP

SIP tuvo como objetivo inicial de la IETF que se pudieron invitar usuarios en sesiones
Mbone (parte de Internet que soporta multicast). Se desarrolló así el protocolo y en
la actualidad se usa como protocolo de inicio de sesiones de todo tipo, incluyendo
multicast.
Fundado en la experiencia de protocolos anteriores, en 1996 nació SIP, Protocolo de
Invitación de Sesión.
SIPv1 estaba basado en texto y utilizaba SDP (Protocolo de Descripción de Sesión)
para describir sesiones, usaba UDP como transporte. Tenía la particularidad de proveer
cierta movilidad a los usuarios a partir del uso de servidores de direcciones.
1.4 Especificaciones H.323 y SIP 30

Intervenía solo para establecer las sesiones y finalizaba su intervención una vez que la
sesión era establecida.

Protocolo de Invitación de Conferencia Simple: SCIP

En 1996 IETF emitió un draft que describía un mecanismo para invitar usuarios a
sesiones punto a punto y sesiones multicast, llamado Protocolo de Conferencia Simple
(SCIP). Este se basaba en HTTP y por ello utilizaba TCP como protocolo de transpor-
te, y también era basado en texto. SCIP utilizaba direcciones de e-mail para identificar
a los usuarios, con el objetivo de proveer un identificador universal para comunicacio-
nes asincrónicas y sincrónicas. La señalización de CSIP se mantenía después de que la
sesión se establecía.

Protocolo de Iniciación de Sesión: SIPv2

Producto de fusionar SIP y SCIP se produjo el avance a SIPv2. El significado de la

sigla se cambió a Protocolo de Iniciación de Sesión.
SIP está en continuo crecimiento y adaptación. Su funcionamiento tiene ciertos elemen-
tos de http y smtp lo que lo hace muy versátil para funcionar. Sus ventajas principales
residen en las características de simplicidad, escalablildad, funcionalidad distribuida y
versatilidad con los protocolos Internet.
Movilidad del usuario
SIP no puede enviar una descripción de una sesión a un potencial participante hasta que
no haya sido localizado. Frecuentemente un usuario debe ser alcanzado en diferentes
ubicaciones. Por ejemplo, en los laboratorios de la facultad un alumno podría utilizar
diferentes máquinas, y debido a ello se ubicaría en diferentes direcciones IP.
Por ello SIP soporta de forma transparente el mapeo de nombres y la redirección de
servicios, permitiendo la implementación de servicios de redes inteligentes de telefo-
nía. Estas facilidades también permiten movilidad personal, es decir, la habilidad de
los usuarios finales de originar y recibir llamadas y de acceder a servicios de teleco-
municaciones en cualquier lugar. La movilidad personal está basada en el uso de una
identificación personal única.
La movilidad personal complementa a la movilidad del terminal, por ejemplo, roaming.
Los usuarios en un ámbito SIP son identificados por un URL SIP (Localizador Uni-
forme de Recursos). El formato de un URL SIP es similar a una dirección de e-mail.
Generalmente consiste en un nombre de usuario y un nombre de dominio.
Los URL’s SIP son utilizados en los mensajes para indicar: el que llama (From), el
destino (Request-URI) y el que es llamado (To) en una solicitud SIP, y para especificar
la dirección de redirección (Contact).
Un URL SIP sigue la guía del RFC 2396. A continuación se muestran algunos ejemplos:

Sip: usuario@host
Sip: usuario:contraseña@host
Sip: usuario@direccionIP:puerto
Sip: usuario@host;parametros-url
1.4 Especificaciones H.323 y SIP 31

Donde:
usuario: El nombre del usuario.
contraseña: Clave de seguridad del usuario.
host: El host donde se encuentra el usuario. Puede ser un nombre o una dirección IP.
puerto: Numero de puerto para enviar una solicitud.
parámetros URL: Los URL’s SIP pueden definir parámetros específicos de la solicitud.
Son agregados después del componente Host y son separados por punto y coma. Entre
ellos están:
El parámetro de transporte "transport" determina el mecanismo de transporte, TCP o
LTDP (UDP es asumido por defecto).
El parámetro "maddr" provee la dirección del servidor a ser contactado por este usuario.
El parámetro "ttl" determina el valor del tiempo de vida para los paquetes multicast
UDP y solo debe ser usado si "maddr" es una dirección multicast.
Los parámetros transporte, "maddr", y "ttl" no deben ser usados en los campos cabe-
ceras From y To y en las Request-URL. Serán ignorados si están presentes.
Headers: Las cabeceras de las solicitudes SIP pueden ser definidas con el mecanismo ?
dentro de un URL SIP.
Method: El método de una solicitud SIP puede ser especificada con el parámetro "met-
hod" dentro de un LTRL SIP.
Entidades SIP
UAC: Agente del Usuario Cliente, es el que llama: Un UAC es un cliente a nivel apli-
cación que inicia una solicitud SIP.
UAS: Agente del usuario Servidor. Un UAS es un servidor a nivel aplicación que contac-
ta al usuario cuando una solicitad de SIP es recibida y retorna una respuesta en nombre
del usuario. La respuesta a la solicitud es aceptada, rechazada o redireccionada.
UA: El agente del usuario es una aplicación que contiene al UAC y al UAS. Cuando
un usuario desea hablar con otro, ejecuta un programa que contiene un UA. El usuario
interactúa a través de la interfase. Cuando el primer usuario oprime el botón de llamar
al segundo, el UA dispara un mensaje SIP apropiado para establecer la llamada.
Todas las interacciones entre los usuarios y el protocolo SIP son mediante los UA’s.
Sin embargo algunos sistemas que utilizan SIP no están directamente conectados con
el usuario. Por ejemplo se puede redireccionar todas las llamadas recibidas a la hora
de la siesta al contestador automático. El contestador automáticamente establecerá la
sesión para grabar los mensajes.
Cuando la sesión describe una sesión de audio/video, esta no puede ser establecida
sin un UA, una herramienta de audio y una herramienta de video. Estas pueden ir o
no incluidas en una misma aplicación, así como otros tipos de herramientas de sesión,
pero la separación de estos elementos hace que SIP tenga más flexibilidad, y permita
el establecimiento de cualquier tipo de sesión.
Servidores Redireccionadores
Los servidores Redireccionadores ayudan a localizar UA’s SIP proveyendo ubicaciones
alternativas dondel usuario puede ser alcanzado.
1.4 Especificaciones H.323 y SIP 32

Por regla general el servidor redireccionador no siempre retorna la dirección de un UA,

sino que retorna la dirección de otro servidor que posee mayor conocimiento acerca de
la ubicación del usuario.
Los servidores redireccionadores pueden también ser utilizados para implementar gru-
pos de direcciones.
El servidor redireccionador puede retomar diferentes direcciones dependiendo, por ejem-
plo, de la hora del día.
Servidores Proxy
Los servidores Proxy aceptan sesiones hechas por un UA y solicitan la información de
direccionamiento del UA de destino al Servidor de Registro. Luego, redireccionan la
invitación directamente al UA destino, si se localiza en el mismo domino, o se dirigirá
a otro Servidor Proxy en caso que el UA destino resida en otro dominio.
Proxy bifurcador
Cuando un servidor Proxy emite un INVITE de una misma sesión a diferentes puntos,
se dice que está bifurcando la invitación. Los servidores Proxy bifurcadores pueden
ejecutar búsquedas paralelas o secuenciales dependiendo de su configuración. Una bús-
queda paralela consiste en el intento de las posibles ubicaciones al mismo tiempo y una
búsqueda secuencial consiste en la búsqueda de cada ubicación individualmente.
Grupo de direcciones
Los servidores Proxy también pueden crear grupos de direcciones e intentar contactar
a todas las personas del grupo hasta encontrar una persona que esté disponible.
Durante el establecimiento de la sesión, es común que los dos tipos de servidores (Proxy
y redireccionadores) estén juntos. El término servidor SIP se refiere a ambos tipos de
servidores.
Registradores
Los registradores son los servidores SIP que aceptan invitaciones. Un servidor registra-
dor está usualmente ubicado junto a un servidor redireccionador o un servidor Proxy.
Servidores de localización
Los servidores de localización no son entidades SIP, pero son una parte importante
de cualquier arquitectura que use SIP. Un servidor de localización guarda y retorna
posibles localizaciones de usuarios. Este puede utilizar información de otras bases de
datos. La mayoría de los registradores "suben.actualizaciones de localizaciones a un
servidor de localización.
Transacciones Cliente/Servidor
SIP se basa en el protocolo HTTP, es un protocolo de solicitud/respuesta. Un cliente
es una entidad SIP que genera solicitudes. Un servidor es una entidad SIP que recibe
solicitudes y devuelve respuestas.
SIP se basa en los mismos procedimientos. Siguiendo la misma terminología cuando
dos UA’s intercambian mensajes SIP, el UA que envía solicitudes es el UAC y el UA
que retorna respuestas es el UAS. Una solicitud SIP junto con la respuesta que genera,
es referida como una transacción SIP.
1.4 Especificaciones H.323 y SIP 33

1.4.3. Comparación entre H.323 y SIP

En la tabla 1.1 vemos la comparación de SIP y H.323 de manera de poder evaluar los
pro y contra de una manera simple:

H.323 SIP
Arquitectura Cubre casi todos los servi- SSIP es modular porque
cios. Como ser intercam- cubre señalización básica
bio de capacidades, con- de llamadas, localización
trol de conferencia, seña- de usuarios y registración.
lización básica, QoS, re- Otras funcionalidades es-
gitración, descubrimiento tán en protocolos separa-
de servicio (service disco- dos.
very), etc.
Componentes Terminal, Gateway, Gate- UA, Servidores
keeper
Funcionalidad de control de llamada
Transferencia de lla- si si
mada
Redirección de llama- si si
da
Llamada en espera si si
Parking de llamada si si
Indicación de msg en si no
espera
Identificación de si no
nombre
Conclusión de llamda si si
para usuario ocupado
Ofrecimiento de lla- si no
mada
Intrusión de llamadas si, las separa entre H.450, no
RAS, H.245 y Q.931
Funcionalidad Avanzadas
Señalización Multi- Si, pedidos de localiza- Si, ej., a través de INVI-
cast ción(LRQ) y auto des- TES grupales
cubrimiento de gatekee-
per(GRQ)
Control de llamada Si, a través de pausa y re Si, a través de SIP co-
de terceras partes enrutamiento definido en mo se describe en diversos
H.323. Un control mas so- Drafts de Internet
fisticado está definido por
las series de estándares re-
lacionados H.450.x
continua en pagina siguiente
1.4 Especificaciones H.323 y SIP 34

continua de la pagina anterior

H.323 SIP
Conferencia si si
Clic para discar si si
Escalabilidad
Gran número de do- El intento inicial de H.323 SIP soporta de manera in-
minios se planeó para soportar herente el direccionamien-
LANs, de manera que no to en áreas amplias. Cuan-
fue inicialmente pensado do hay múltiples servido-
para grandes redes. El res involucrados en esta-
concepto de zonas se agre- blecer una llamada, SIP
gó para soportarlas. Es- usa un algoritmo detec-
tá definida la comunica- ción de loop similar al
ción entre dominios admi- usado en BGP que per-
nistrativos y se describen mite hacerse sin necesi-
los métodos para resolver dad de mantener máqui-
direcciones, autenticación nas de estado lo que evi-
y reportes de uso entre ta efectos en la escalabi-
dominios administrativos. lidad. El Registrador SIP
En búsquedas multidomi- y los servidores de redirec-
nio no hay una forma fá- cionamiento están diseña-
cil de detectar loops. De- dos para soportar la ubi-
tectar estos loops se puede cación del usuario
hacer pero introduce otros
factores que afectan la es-
calabilidad
Gran número de lla- El control de llamadas de El control de llamadas
madas H.323 puede implementar- puede implementarse de
se de una manera que no una manera que no ne-
necesita mantener maqui- cesita mantener maquinas
nas de estado. Un gateway de estado. SIP soporta es-
puede usar mensajes defi- calado n a n entre UAs
nidos en H.225 para asis- y servidores. SIP necesita
tir al gatekeeper a efectuar menos ciclos de CPU pa-
balanceo de carga a través ra generar mensajes de se-
de los gateways ñalización, por lo que en
teoría, puede manejar más
transacciones. SIP ha es-
pecificado un método para
balanceo de carga basado
en los mecanismos de tra-
ducción de registros DNS
SRV
continua en pagina siguiente
1.4 Especificaciones H.323 y SIP 35

continua de la pagina anterior

H.323 SIP
Internacionalización si, H.323 usa Unicode si, SIP usa Unicode (ISO
10646-1), codificado como
UTF-8, para todas las ca-
denas de textos. SIP con-
templa la indicación de
lenguajes y de preferencias
de lenguajes
Seguridad Define mecanismos de se- SIP soporta autenticación
guridad y negociación a a través de mecanismos de
través de H.235 y puede HTTP. La autenticación
usar SSL como un nivel de asegurada con criptografía
transporte seguro y encriptación es soporta-
da usando SSL/TSL pe-
ro SIP puede usar cual-
quier método de trans-
porte o mecanismos del
estilo HTTP como SSH
o SHTTP. Las llaves de
encriptación se acuerdan
usando SDP. SSL sopor-
ta autenticación simétri-
ca y asimétrica. SIP tam-
bién define autenticación
extremo a extremo y en-
criptación usando PGP o
S/MIME
Interoperabilidad en- H.323 tiene compatibili- En SIP una nueva versión
tre Versiones dad completa con versio- puede que deje fuera algu-
nes anteriores permitiendo nas funcionalidades viejas.
una integración directa Este enfoque optimiza el
sistema y reduce la com-
plejidad pero hace que se
pierda cierta compatibili-
dad entre versiones
Implementación H.323 provee de una guía SIP por el momento no ha
para su implementación provisto de un acuerdo pa-
que clarifica el estándar y ra la implementación
ayuda a la interoperativi-
dad con las diferentes im-
plementaciones
continua en pagina siguiente
1.4 Especificaciones H.323 y SIP 36

continua de la pagina anterior

H.323 SIP
Tasación Aún con el modelo de lla- Si el Proxy SIP necesita
mada directa la capacidad recolectar información de
para hacer una tasación tasación no tiene otra op-
exitosa no se pierde por- ción que quedarse en el
que los puntos extremos camino de la señalización
deben reportar al gatekee- durante toda la llamada
per el inicio y finalización de manera de poder detec-
de la llamada usando el tar el final de la llamada
protocolo RAS
Codecs H.323 soporta cualquier SIP soporta cualquier co-
codec, estandarizado o dec registrado en el IA-
propietario. Cualquier co- NA o cualquier codec cu-
dec puede ser señalizado yo nombre sea mutuamen-
a través de la función de te acordado
capacidad genérica que
fue agregada en H.323v3
Bifurcación de llama- Los gatekeeper pueden Los Proxy SIP pueden
das controlar la señalización controlar la señalización
de las llamadas y puede bi- de la llamada y puede bi-
furcar la llamada a cual- furcar la llamada a cual-
quier número de dispositi- quier número de dispositi-
vos de manera simultánea vos de manera simultánea
Protocolo de Trans- Confiable y no confiable. Confiable y no confiable.
porte Como por ejemplo TCP y Como por ejemplo TCP
UDP. La mayoría de las y UDP. La mayoría de
entidades H.323 usan un las entidades SIP usan un
protocolo confiable protocolo no confiable
Codificación de Men- H.323 codifica los mensa- Los mensajes SIP están
sajes jes en un formato binario codificados en ASCII y
compacto que es adecuado pueden ser leídos directa-
para conexiones de banda mente
ancha y banda angosta
Direccionamiento Mecanismos flexibles de SIP solo entiende direccio-
direccionamiento inclu- nes del estilo URL
yendo URLs y números
E.164
Interconexión PSTN H.323 toma prestado pro- SIP no tiene nada en co-
tocolos de la PSTN tra- mún con la PSTN y por lo
dicional, como ser Q.931 tanto la señalización con
y por lo tanto está bien la PSTN está agregada de
adaptado para su integra- una manera no demasiado
ción nativa
continua en pagina siguiente
1.5 Especificaciones de IAX 37

continua de la pagina anterior

H.323 SIP
Detección de Loops Si, los gatekeeper pueden Si, el encabezado del men-
detectar loops buscando saje "Via"facilita esto. Sin
en el identificador de lla- embargo se ha conversa-
mada y la dirección de do acerca de abandonar
destino en los mensajes de el uso de ese mensaje co-
procesamiento de llama- mo mecanismo de detec-
das, si la combinación de ción de loop debido a la
estos parámetros coincide complejidad. En cambio,
con una llamada ya exis- aparentemente se prefie-
tente entonces hay un loop re usar el encabezado de
Max-Forwards para limi-
tar saltos y por lo tanto
impedir loops
Mínima cantidad de 5 (1 Señalización de llama- 5 (1 señalización de llama-
puertos para una lla- da, 2 RTP y 2 RTCP) da, 2 RTP, y 2 RTCP)
mada VoIP
Conferencia con Vi- H.323 soporta completa- SIP tiene un soporte limi-
deo y Datos mente conferencia con vi- tado para video y no so-
deo y datos. Existen pro- porta protocolos para da-
cedimientos para proveer tos en conferencia como
control para la conferencia ser T.120. SIP no tiene
así como sincronización de protocolos para controlar
audio y video las conferencias y no hay
un mecanismo para la sin-
cronización de audio y vi-
deo

Tabla 1.1: Comparación entre H.323 y SIP

1.5. Especificaciones de IAX

El protocolo de Intercambio Inter Asterisk (IAX) proporciona control y transmisión
de datos multimedia sobre redes IP. IAX puede ser usado con cualquier tipo de datos
multimedia incluso el vídeo, pero apunta principalmente al control de llamadas de VoIP.
Los objetivos de diseño para IAX se derivan de la experiencia con los protocolos de
VoIP existentes como SIP y MGCP para control, y RTP para la transmisión de datos
multimedia.
Los objetivos de diseño primarios para el protocolo IAX son:
1) Minimizar el uso de ancho de banda tanto para control como para datos multime-
dia, con especial énfasis en las llamadas de voz individuales.
2) Proporcionar soporte transparente frente a un NAT.
1.5 Especificaciones de IAX 38

Fig. 1.4: Multiplexión múltiple de datos multimedia usando un solo puerto UDP

1.5.1. Descripción del Protocolo

IAX es un protocolo de datos multimedia y control par a par. Par a par significa que
los puntos extremos mantienen máquinas de estados asociadas con las operaciones del
protocolo. El componente de señalización del protocolo IAX es un protocolo de control
de llamadas Maestro-Esclavo, más análogo al Protocolo de Iniciación de Sesión (SIP)
que al Protocolo de Control de Entrada de Media (MGCP). Con respecto a datos
multimedia, la información de secuencia y cronometraje es incluida en los marcos IAX.
El transporte de multimedia no utiliza el Protocolo de Transporte en Tiempo real
(RTP).
El diseño básico fue realizado para la señalización IAX multiplexada y múltiples co-
rrientes de datos multimedia sobre una única asociación UDP entre dos anfitriones de
Internet. Es realmente dos protocolos en uno: un protocolo para sesiones de señaliza-
ción y un protocolo para transportar las corrientes de datos multimedia. Esto difiere
totalmente con la arquitectura de otros protocolos IETF que separan el control (MGCP
y SIP) de la transmisión de datos (RTP/RTCP). Como la señalización y los datos mul-
timedia comparten el mismo número de puerto UDP, IAX hace que no se sufran los
problemas transversales relacionados con el uso de un NAT.
La figura siguiente ilustra la relación básica entre dos anfitriones de Internet. Cada
anfitrión usa el puerto UDP 4569 para comunicar todos los paquetes de Internet. IAX
entonces usa un número de 15 bits para multiplexar múltiples corrientes de media sobre
el número de puerto UDP.
El valor cero es un número especial reservado en cada anfitrión. Cuando se intenta
establecer una llamada, el número de destino no es todavía conocido. Un número de
destino cero es usado en esta situación.
IAX es un protocolo binario. Esta opción de diseño fue tomada para tener eficiencia de
ancho de banda.

Establecimiento de llamada

La figura siguiente ilustra el flujo de mensajes básicos usados para establecer una lla-
mada. En este ejemplo, el Anfitrión A inicia la llamada enviando un mensaje NEW al
1.5 Especificaciones de IAX 39

Fig. 1.5: Escenario de establecimiento de llamada típico

Anfitrión B. El anfitrión B inmediatamente devuelve un mensaje ACCEPT, indicando

al Anfitrión A que ha recibido su petición y está listo para darle servicio. El anfitrión
A envía un mensaje ACK al Anfitrión B indicando la recepción del mensaje ACCEPT.
Una vez que en el Anfitrión B comienza a sonar el teléfono, este devuelve un mensaje
RINGING al Anfitrión A. Este último devuelve un mensaje ACK al Anfitrión B que
indica la recepción del mensaje RINGING. Finalmente, cuando el teléfono es atendido,
el Anfitrión B envía un mensaje ANSWER al Anfitrión A y el establecimiento de lla-
mada está completo. En este punto una comunicación de voz full dúplex se establece
entre el Anfitrión A y el Anfitrión B.

Finalización de llamada

La figura que sigue ilustra el flujo de mensajes para finalizar una llamada de voz. En este
ejemplo, el Anfitrión A inicia la finalización enviando un mensaje HANGUP al Anfitrión
B. Se espera que el anfitrión B devuelva inmediatamente un mensaje ACK que indica
el recibo de la solicitud de finalización y de esta forma la llamada es terminada en el
lado del Anfitrión B.
1.5 Especificaciones de IAX 40

Fig. 1.6: Escenario de finalización de llamada típico

Fig. 1.7: Escenario de flujo de media típico

Flujo de datos multimedia

La figura a continuación ilustra un Flujo de datos multimedia IAX simple, de dirección

única. Para una llamada de voz nominal, habría dos de estos flujos, una corriente en cada
dirección. Cada flujo está comprendido sobre todo de Mini Marcos IAX que contienen
un encabezado de 4 bytes simples que apuntan a la eficacia de ancho de banda. El
flujo es complementado por marcos llenos periódicos que incluyen la información de
sincronización.

1.5.2. Frames IAX

Los mensajes IAX se llaman frames. Hay varios tipos de frames básicos. Un bit llamado
F en el frame indica si se trata de un Full Frame (frame completo) o de otro tipo.
El número de llamada (Call Number) es un número de 15 bits entero positivo que se usa
para seguir el flujo de datos en un host. El valor cero se usa para indicar que todavía no
se conoce el número de llamada. Una llamada telefónica de hecho posee dos Números
de Llamado asociados a ella, uno para cada dirección del flujo.
Un Timestamp (marca de tiempo) puede ser de 32 o 16 bits. En el caso de usar 16 bits,
lo que se hace es recortar los 16 bits más bajos de la marca de tiempo de 32 bits.

Full Frame

Puede usarse para enviar señalización, audio o video de manera confiable. Los Full
Frames son el único tipo de mensajes que se envían de manera confiable. Esto implica
que el host de destino debe devolver algún tipo de mensaje de regreso para confirmar
la recepción.
1.6 SIP Vs. IAX 41

Hay dos tipos de información de control que se pasa usando Full Frames, Frames de
Control y Frames IAX de Control. Los Frames de Control proveen control de sesión,
i.e. se refieren al control de los dispositivos conectados al punto extremo. Los Frames
de Control IAX proveen administración específica del punto extremo, i.e. se usan para
manejar interacciones del protocolo IAX que son generalmente independientes del tipo
de punto extremo.

Mini Frame

Un Mini Frame se usa para enviar datos multimedia con un mínimo overhead. De esta
manera se optimiza el uso de ancho de banda al enviar solo la información estrictamente
necesaria.

1.6. SIP Vs. IAX

A continuación se resumen algunas diferencias entre SIP y IAX, lo que podría ayudar
a tomar una decisión sobre cuál protocolo es más útil para el sistema que se esté
preparando.
1) IAX es más eficiente que RTP para cualquier número de llamadas y cualquier codec.
La ventaja está en que usa 2.4k para una sola llamada aproximadamente, triplicando
el número de llamadas por megabit para G.729 en modo trunk.
2) IAX es un codificador delemento de información más que codificador ASCII. Esto
hace a las implementaciones considerablemente más simples y más robustas frente a
ataques de congestión en el buffer a partir de que ningún análisis sintáctico o inter-
pretación de texto es requerido. IAX ejecuta su pila IP entera, pila de IAX, interfaz
TDM y cancelador de eco. Claramente esto demuestra la eficacia de su diseño. El ta-
maño de los paquetes de señalización IAX son fenomenalmente pequeños que aquellos
de SIP, pero esto no es generalmente una preocupación excepto con un gran número
de clientes que con frecuencia se registran. Hablando en general, IAX2 es más eficiente
en su codificación, decodificación y verificación de información, y sería muy difícil para
el autor de una implementación IAX que de alguna manera sea incompatible con otra
implementación desde que tan poco ha sido dejado a interpretación.
3) IAX tiene una separación muy clara entre la capa 2 y la capa 3, lo que significa que
la señalización y el audio tienen estados definidos, son robustamente transmitidos de
una manera consistente, y cuando se produce el final de una llamada repentinamente,
la llamada se terminará de una manera oportuna, aun si no se ha recibido más señali-
zación y/o audio. SIP no tiene tal mecanismo, y su fiabilidad desde la perspectiva de
señalización es obviamente muy pobre y torpe, requiriendo estándares adicionales.
4) Los caminos unificados para señalización y audio de IAX permiten que transparen-
temente se navegue utilizando un NAT, proporcionando sólo un puerto a través de un
firewall para permitir su uso. Esto requiere que un cliente IAX sepa absolutamente
nada sobre la red en la cual está funcionando. Mejor dicho, nunca se daría la situación
creada por el firewall en el cual IAX pueda completar una llamada y no ser capaz de
pasar audio (excepto por supuesto si hubiera ancho de banda insuficiente).
5) El sistema de transferencia de autentificación de IAX permite que se trasladel audio
y el control de llamadas a un servidor central de una manera robusta de tal forma que si
1.6 SIP Vs. IAX 42

dos puntos extremos no pueden verse el uno con el otro por ninguna razón, la llamada
siga por el servidor central.
6) IAX claramente separa el Caller ID del mecanismo de autenticación del usuario. SIP
no tiene un método claro para hacer esto a menos que sea usado el Remote-Party-ID.
7) IAX permite que un punto extremo compruebe la validez de un número de teléfono
para saber si está completo. No hay ninguna forma de proveer esto completamente en
SIP.
9) IAX siempre envía DTMF fuera de banda así nunca hay confusión sobre que método
se está usando.
10) IAX provee la transmisión de lenguaje y contexto, que son útiles en un ambiente
Asterisk.

1.6.1. Calidad de Servicio

La calidad del Servicio o QoS (Quality of Service) como es más popularmente llamado,
se refiere al desafío de la entrega de una corriente de datos sensible al tiempo a través
de una red que fue diseñada para entregar datos haciendo el mejor esfuerzo. Aunque
no haya ninguna regla difícil, es generalmente aceptado que si se puede entregar el
sonido producido por el altavoz al oído del oyente dentro de los 300 milisegundos, es
posible transportar un flujo de conversación normal. Cuando la tardanza excede los 500
milisegundos, se hace difícil evitar la interrupción entre los participantes de la llamada.
Más allá de un segundo, una conversación normal se hace muy torpe.
Además de la necesidad de llegar a tiempo, es también esencial asegurar que la infor-
mación transmitida llegue intacta. Demasiados paquetes perdidos impedirán reproducir
de forma completa el audio, y huecos en los datos serán oídos como estática o, en casos
severos, palabras u oraciones enteras perdidas.

TCP, UDP, y SCTP

Si se va a enviar datos a través de una red de IP, estos serán transportados usando uno
de los tres protocolos de transporte descriptos a continuación.
Protocolo de Control de Transmisión
El Protocolo de Control de Transmisión (TCP) casi nunca es usado para VoIP, ya que
mientras posee mecanismos para asegurar la entrega, no tiene intrínsecamente ninguna
prisa en lograr esto. A menos que se tenga una interconexión de sumamente baja
latencia entre los puntos extremos, TCP va a tender a causar más problemas de los que
va a solucionar.
El objetivo de TCP es garantizar la entrega de paquetes. Con el fin de hacer esto,
varios mecanismos son puestos en práctica, como la enumeración de paquetes (para
la reconstrucción de bloques de datos), reconocimiento de entrega y retransmisión de
paquetes perdidos. En el mundo de VoIP, llevar rápidamente los paquetes al punto
extremo es supremo, y 20 años de telefonía celular nos han entrenado para tolerar
algunos paquetes perdidos.
El alto procesamiento de saturación del TCP, la administración por estados y el reco-
nocimiento de llegada de los paquetes, son buenos a la hora de transmitir cantidades
1.6 SIP Vs. IAX 43

grandes de datos, pero simplemente no es bastante eficiente para comunicaciones de

tiempo real.
Protocolo de Datagrama de Usuario
A Diferencia de TCP, el Protocolo de Datagrama de Usuario (UDP) no ofrece ninguna
clase de garantía de entrega. Los paquetes son colocados en el vínculo tan rápidamente
como es posible y liberados en el mundo para encontrar el camino a sus destinos fina-
les, sin comunicar atrás si realmente llegan o no. Ya que UDP en sí mismo no ofrece
ninguna clase de garantías de que los datos llegarán, consigue eficacia gastando muy
poco esfuerzo en lo que está transportando.
Protocolo de Transmisión de Control de Flujo
Aprobado por el IETF como un estándar propuesto en RFC 2960, SCTP es un protocolo
de transporte relativamente nuevo. Fue diseñado para trabajar sobre los defectos tanto
de TCP como de UDP, especialmente los relacionados con los tipos de servicios que se
usan para entregar datos en redes de telefonía de conmutación de circuitos.
Algunos objetivos de SCTP eran:
- Mejores técnicas para evitar la congestión
- Estricta entrega de datos en secuencia
- Baja latencia para transmisiones de tiempo real mejoradas
Venciendo los defectos principales de TCP y UDP, los desarrolladores de SCTP esperan
crear un protocolo robusto para la transmisión de SS7 y otros tipos de señalización
PSTN sobre una red de IP.
2. Estudio exploratorio de carácter bibliográfico sobre
Asterisk como PBX de VoIP.

2.1. Introducción a Asterisk

Asterisk es una PBX y mucho más. Asterisk es revolucionario, rentable, open source,
software libre que transforma una ordinaria y barata PC corriendo Linux en un sistema
telefónico para la empresa muy poderoso. Es una herramienta open source para aplica-
ciones de telefonía y servidores de llamada de alto desarrollo. Posee una arquitectura
open source con plataforma Integrada de telefonía computarizada que puede usarse
para muchas cosas entre las cuales se incluyen:
Private Branch Exchange PBX
Voicemail Services con Directorio
Servidor de conferencias
Servidor de voz paquetizada
Encriptación de llamadas telefónicas o File Analog exchange (FAX)
Gateway heterogéneo de VoIP ( (H.323), Session Initiation Protocol (SIP), Media
Gateway Control Protocol (MGCP), Inter-Asterisk eXchange (IAX))
Custom Interactive Voice Response IVR system
Soft switch
Traslación de números
Calling card server
Marcador predictivo
Encolador de llamadas para Agentes remotos
Gateway y agregados para sistemas legales de PBX
Oficina remota o servicio de teléfono de usuario
Gateway de larga distancia PBX
Bloqueo de telemarketing
Muchas de las más grandes compañías telefónicas han coincidido en reemplazar sus
sistemas de conmutación de circuitos por sistemas de conmutación de paquetes de
VoIP. Las compañías de teléfonos han transportado una porción de su tráfico a IP.
Gran parte de las llamadas hechas con equipos de ciertas compañías se realizan con
equipamiento que transporta Voz sobre IP.
Los sistemas de Voz sobre IP de conmutación de paquetes son en principio tan eficientes
como los son los sistemas de conmutación de circuitos síncronos, pero solo recientemente
2.2 ¿Qué es una PBX? 45

adquirieron el potencial necesario como para tener el mismo nivel de rentabilidad que
una PSTN o un equipo PBX propietario. Con la invención e implementación de Real
Time Protocol (RTP) y SIP, la VoIP tiene su base tecnológica para dejar totalmente
obsoleta la red de telefonía publica de conmutación de circuitos.

2.1.1. Los Cambios Masivos requieren una tecnología flexible

El más exitoso de los sistemas de telefonía en el mundo tiene una limitación de diseño
que ha sobrevivido 15 años: cuando uno determina el numero de veces que va a sonar
el teléfono antes de ser derivado al Buzón de Mensajes de Voz, se puedelegir entre 2,
3, 5, 6 o 10 repiques. Cuando un cliente desea que suene 5 veces el fabricante contesta
que así funciona y los clientes deben acostumbrarse a eso.
El anterior es un simple ejemplo. Otro ejemplo es que el nombre con el que uno programa
su teléfono puede ser de 7 letras como máximo. En los 80s esto tenía sentido dada la
escasez y alto precio de las memorias, pero hoy no tiene excusa.
Todas las centrales tienen su contra, inclusive la central más completa en prestaciones
siempre va a fallar en anticiparse a las creativas necesidades de los clientes.
Si Internet hubiese sido restringida con regulaciones e intereses comerciales, dudosa-
mente tendría el desarrollo y la aceptación que hoy tiene. La apertura de Internet
permitió a cualquiera participar de su desarrollo. Así, los cientos de miles de mentes
que colaboraron en la creación de Internet produjeron algo que ninguna corporación
podría haber hecho.
Así como con muchos otros proyectos Open Source, como Linux e Internet, la explosión
de Asterisk se nutrió de los sueños de personas que sabían que debía haber algo más
de lo que la industria estaba produciendo. La fortaleza de la comunidad es que no está
compuesta por empleados asignados a tareas específicas, sino por gente de todo tipo
de industrias, con todo tipo de experiencias y toda clase de ideas acerca de lo que la
flexibilidad y la apertura representan.

2.2. ¿Qué es una PBX?

Asterisk es una implementación en software de una Private Automatic Branch Exchange
(PABX). Una PABX, usualmente llamada PBX, es una Private Automatic Branch
Exchange.
Originalmente el equipamiento PBX es analógico, los equipos mas recientes son digita-
les. Una PBX es una buena inversión para las empresas ya que es la forma más barata
de tener líneas telefónicas para cada usuario dentro de la empresa y además proveer
más servicios a éstos.
Con una PBX, las líneas que vienen desde la compañía de teléfonos pueden compartirse
en lugar de tener líneas separadas hacia la compañía de teléfonos para cada usuario.
Una PBX es un sistema telefónico que da servicio a una empresa conmutando llamadas
entre usuarios de la empresa en líneas locales y compartiendo líneas externas. La PBX
tiene la inteligencia para conmutar llamadas desde dentro de la empresa hacia afuera.
Una PBX provee características y capacidades no disponibles con conexiones directas
a la PSTN. Tiene funciones adicionales y características como IVR, llamada en espera,
etc.
2.3 ¿Qué es Asterisk? 46

Como la PSTN, los sistemas de telefonía de empresas Enterprise telephony (ET) son de
conmutación de circuitos. Ambos utilizan un modelo de infraestructura común. Todos
los protocolos de control y características son combinadas en un simple modelo. Siste-
mas ET usualmente no pueden manejar el mismo volumen de tráfico que la conmutación
PSTN. Los sistemas ET usualmente usan protocolos propietarios.

2.2.1. ¿Cómo se puede comparar Asterisk a una PBX?

Sistemas ET, y Asterisk, proveen interoperabilidad entre el sistema local y la PSTN.
Muchas de las características en las PBX son raras veces utilizados. Algunas carac-
terísticas pueden haber sido desarrolladas para un usuario que la necesitaba en una
tarea particular. Debido a esto, Asterisk no posee todas las características de todos los
sistemas PBX de todos los vendedores.
Ya que Asterisk es una plataforma abierta las características son fáciles de agregar
y muchas nuevas características se agregan continuamente. Cualquier característica
agregada a Asterisk por un usuario puede estar disponible para otro en su sistema.
Esto es debido a que Asterisk es un producto open source distribuido bajo licencia
GPL.

2.3. ¿Qué es Asterisk?

Asterisk es una PBX open source. Implementa comunicaciones por software en lugar de
hacerlo por hardware. Esto permite que nuevas características se agreguen rápidamente
con el mínimo esfuerzo. Se puede realizar cambios o agregar lo que se quiera de una
manera fácil. Se incluye soporte internacional, un grupo de archivos de configuraciones
extenso, código fuente abierto, cada aspecto de Asterisk puede ser personalizado para
conseguir sus metas. Nuevas interfaces y tecnologías son fácilmente instalables.

2.3.1. Escenario A - Una oficina en casa

Julia es una representante de venta externa de una compañía en Chicago. Ella cubre la
región sudoeste y vive en Phoenix. Julia tiene una línea DSL en su oficina. La oficina
central tiene un servidor Asterisk. La misma tiene una conexión de alta velocidad a
Internet.
Julia tiene un teléfono en su escritorio que conecta su línea (DSL). La persona que
llama contacta la oficina de Chicago marcando la herramienta telefónica gratuita 800 en
Chicago de su oficina central. La persona que llama escucha el directorio de divisiones
en busca del departamento de ventas. El directorio le da opciones por cada una de las
regiones. El usuario selecciona la región sudoeste. Asterisk le dice luego la extensión
para Julia anunciando su nombre, y luego como contactarse con ella.
El servidor Asterisk en Chicago hace sonar el teléfono en el escritorio de Julia. Desde
que esta llamada se origina sobre Internet hasta el escritorio de Julia, no hubo necesidad
de llamadas larga distancia entre Julia y la oficina central. Si Julia no atiende luego
de 6 veces que suena el teléfono, se le da la opción al usuario de dejar un mensaje y
retornar al departamento de ventas o hablar con el operador.
2.3 ¿Qué es Asterisk? 47

Es increíblemente eficiente. Una pequeña PC puede servir a muchos usuarios de te-

léfonos. Se puede construir un sistema telefónico para una pequeña o gran empresa.
Cuando combinamos bajo costo y hardware telefónico Linux, Asterisk crea una PBX
con una fracción del precio tradicional de los sistemas PBX.

2.3.2. Escenario B - Una oficina pequeña

Asterisk puede beneficiar una pequeña oficina. En este escenario, una pequeña oficina
tiene cuatro líneas que vienen de la compañía de teléfonos, cada una de las cuales es
nuestro numero telefónico. La oficina tiene diez usuarios. Hay una maquina de FAX y
un cuarto de conferencias. Cada uno de los diez usuarios tiene un teléfono IP. Hay un
teléfono IP en el cuarto de conferencias. El pequeño negocio puede de una forma fácil
y barata adquirir un servidor Asterisk.
El servidor Asterisk maneja las llamadas de las cuatro líneas y todos los teléfonos en la
oficina incluyendo la maquina de FAX. Una llamada entrante recibe el tono de llamado,
luego una voz le dice el menú qué tiene para elegir y poder comunicarse con algún
departamento (ventas, servicio técnico, etc.) o marcar una extensión (perteneciente a
un departamento o división) si la conoce directamente.
La persona que llama quiere hablar con alguien de la parte de ventas. Consulta el
directorio por el departamento de ventas. Presiona 100 en el teclado del teléfono, la
división ventas tiene tres teléfonos. Los tres suenan. Hay un ring distintivo que le
permite saber a las personas que trabajan en ventas que es una llamada entrante de un
potencial cliente para la empresa.
Si ninguno de los teléfonos se atiende al cuarto ring, la persona que llama tiene la opción
de dejar un mensaje o contactarse con el operador. Si el usuario elige dejar un mensaje,
se almacena en una casilla de correo separada para el departamento de ventas. Cada
uno de los tres responsables de atender el teléfono en la parte de ventas es informado
por medio de un correo electrónico que hay una nueva llamada en su lugar de trabajo.

2.3.3. Escenario C - Una gran Empresa

En este escenario, hay 15.000 empleados. La oficina principal esta en New York. Oficinas
de distrito están en Chicago y Los Ángeles. El soporte se realiza en la oficina de Denver.
Los servidores Asterisk están separados en lugares específicos en Chicago y New York. Se
comunican entre si por medio de una conexión de alta velocidad a Internet. También se
comunican con las ramas de las oficinas por otra conexión de alta velocidad de Internet.
Compartiendo los servidores Asterisk, si uno falla el otro entra en acción. Es mucho
mas seguro para la compañía que tener todo basado en un solo servidor que no puede
tener ninguna falla.
Si llegase a haber un problema en la oficina, los empleados pueden tomar sus teléfonos
fuera de sus escritorios y trasladarlos a sus casas o a otra oficina. Si surge un problema
en la oficina de Chicago, empleados claves pueden reacomodarse en la oficina de New
York. Pueden llevar sus teléfonos o utilizar alguno en la oficina de New York.
Usuarios en busca de soporte pueden llamar a números locales en cualquiera de las
regiones. Estas llamadas son ruteadas al centro de soporte en Denver. Las llamadas se
envían sobre Internet así que aquí no hay cargo de llamada de larga distancia para la
compañía.
2.4 La revolución telefónica 48

2.4. La revolución telefónica

Una revolución increíble se aproxima. Ha tardado mucho en llegar pero ahora que
empezó no habrá forma de detenerla. Está sucediendo en un área de la tecnología que
se ha quedado muy lejos de las tecnologías dignas de llamarse de vanguardia. Ésta
industria es la de las comunicaciones telefónicas, y la revolución que mencionamos está
siendo alimentada por el proyecto de PBX Open Source: Asterisk.
Las telecomunicaciones es una de las últimas grandes industrias que ha quedado fuera
del movimiento Open Source hasta el momento. Los mayores fabricantes de productos
del rubro todavía producen sistemas ridículamente caros, incompatibles, complicados
de manejar o usar, basados en códigos y hardware obsoletos. Además, las posibilidades
de personalizar la configuración de los equipos están totalmente fuera del alcance de
estos productos.
Asterisk cambia totalmente este paradigma. Asterisk permite tener lo que el cliente
desea. Implementa el concepto de conformidad con estándares al mismo tiempo que
posee la libertad para desarrollar innovaciones propias.
Sin embargo, hay un pequeño precio que pagar por tanta flexibilidad y es que Asterisk
no es un sistema simple de configurar al principio. Esto no se debe a que sea ilógico,
confuso o críptico sino que, por el contrario, el sistema es muy sensato y práctico.

2.5. El Proyecto de telefonía Zapata

El proyecto de telefonía Zapata fue concebido por Jim Dixon, un ingeniero consultor
de telecomunicaciones quien se vio inspirado por los grandes avances en las velocidades
de los procesadores.
Dixon pensó que un sistema telefónico más económico sería aquel cuyas placas tuvieran
sólo los componentes necesarios para interfacear con el circuito telefónico, en lugar de
tener componentes caros y complejos en cada placa. Así, todo el procesamiento de la
señal (i.e. las funciones de DSP) serían manejadas en el Central Processor Unit (CPU)
por software.
Dixon confiaba que el costo de los CPUs relativos a su performance y, la manera en la
que estas dos características evolucionan, justificarían su uso en lugar de caros DSPs.
Pensó al principio que era solo cuestión de tiempo hasta que alguien construyera tales
placas basadas en el uso intensivo del CPU. Tras algunos años de esperar en vano por la
construcción de las tarjetas, estaba claro que tenía que encargarse él mismo del asunto,
dando origen de esta manera al Proyecto de Telefonía Zapata (el nombre está basado
en Emiliano Zapata, revolucionario mejicano). El nombre con el que bautizó a la placa
fue Tormenta.

2.6. La Comunidad Asterisk

Una de las fortalezas de asterisk es su comunidad que lo desarrolla y soporta. Esta
comunidad es liderada por Mark Spenser de Digium.
Uno de los efectos de esta comunidad es la cooperación que ha sembrado entre los
profesionales de las telecomunicaciones, redes e Information Technology (IT) quienes
2.7 Documentación de Asterisk 49

comparten el interés por éste fenómeno. Mientras que tradicionalmente estos profesio-
nales se han mantenido reacios unos con otros, en la comunidad de Asterisk todos se
enriquecen a partir de los conocimientos de sus colegas. Siendo así, el significado de
esta cooperación no puede ser subestimado.

2.7. Documentación de Asterisk

Uno de los puntos para informarse sobre VoIP y Asterisk es el sitio

http://www.voip-info.org.

Otro lugar para encontrar información es el sitio del proyecto Asterisk Documentation
Project,

http://www.asteriskdocs.org

iniciado por Leif Madsen y Pared Smith.

2.8. Preparando un sistema para Asterisk

En términos de requerimientos de recursos, Asterisk necesita, tal como los sistemas
embebidos, aplicaciones de tiempo real. Esto es debido en gran parte a su necesidad de
tener acceso prioritario al procesador y los buses del sistema. Es por lo tanto imperativo
que cualquier función en el sistema que no esté directamente relacionada con la tarea de
procesamiento de llamadas de Asterisk sea ejecutado con baja prioridad. En sistemas
pequeños, esto no debería ser un aspecto problemático. Sin embargo, en sistemas de
alta capacidad, una performance defectuosa se manifestará en problemas de calidad de
audio para los usuarios, tales como eco o estática, entre otros. Los síntomas se parecerán
a aquellos experimentados en un teléfono celular cuando se lo utiliza fuera de un área
de cobertura, aunque las causas que los provocan serán diferentes. Mientras la carga
se incrementa, el sistema tendrá mayores dificultades para mantener las conexiones.
Para una PBX, esta situación no está lejos de ser desastrosa, por lo que una cuidadosa
atención a los requerimientos de performance es una consideración crítica durante el
proceso de selección de la plataforma.

Implementación Número de Canales Requerimiento mínimo

Sistema para hogar No mas de 5 400-MHz x86,256 MB RAM
Sistema SOHO1 5 a 10 1-GHz x86, 512 MB RAM
Sistema para PyME hasta 15 3-GHz x86, 1 GB RAM
Sistema para gran empresa mas de 15 CPUs Duales,multi servers

Tabla 2.1: Pautas sobre los requerimientos del sistema.

En grandes instalaciones de Asterisk, es común desplegar funcionalidad a través de

varios servidores. Una o más unidades centrales estarán dedicadas al procesamiento
de llamadas; esto será complementado con uno o más servidores auxiliares manejando
periféricos (como bases de datos, voicemail, conferencias, administración, la interfaz
Web, firewall, entre otros). Como en la mayoría de los ambientes Linux, Asterisk está
2.8 Preparando un sistema para Asterisk 50

preparado para crecer con las necesidades: un pequeño sistema que es usado para poder
manejar todos los procesamientos de llamadas y tareas periféricas puede ser distribuido
entre varios servidores cuando el incremento en la demanda excede sus habilidades.
Flexibilidad es la razón principal por la que Asterisk es extremadamente efectivo en
relación a los costos, frente a negocios que crecen rápidamente. Si bien es posible algún
tipo de escalabilidad en la mayoría de los sistemas telefónicos, todavía no se conoce
alguno que pueda crecer sin generar grandes costos. Habiendo dicho esto, vale aclarar
que sistemas distribuidos con Asterisk no son simples de diseñar, por lo que no sería
una tarea para alguien nuevo en la utilización de este producto.

2.8.1. Selección de hardware para el Servidor

La selección de un servidor es simple y complicado a la vez: simple porque, realmente,
cualquier plataforma basada en x86 será suficiente; pero complicado porque la per-
formance segura del sistema dependerá del cuidado que se tenga en el diseño de la
plataforma. Cuando se seleccione el hardware, se debe considerar cuidadosamente el
diseño global del sistema y que funcionalidad se necesita proveer. Esto ayudará en la
determinación de los requerimientos para el CPU, placa madre y abastecimiento de
energía.

2.8.2. Aspectos de Performance

Entre otras consideraciones, cuando se selecciona el hardware para una instalación
de Asterisk se debe tener en mente la siguiente pregunta crítica: ¿que tan poderoso
debe ser el sistema?. Ésta no es una pregunta fácil de responder, porque la manera en
que el sistema será usado jugará un rol importante en los recursos que consumirá. Se
deberá por lo tanto comprender cómo Asterisk utiliza el sistema para tomar decisiones
inteligentes sobre qué tipo de recursos se necesitarán.
Se deberán considerar varios factores, incluyendo:
El máximo número de conexiones simultáneas que el sistema podrá proveer: Cada
conexión incrementará la carga de trabajo en el sistema.
El porcentaje de tráfico que requerirá un procesamiento intensivo de codecs de
compresión (como el G.729 o GSM) por parte del Procesador de Señal Digital
DSP: el trabajo de procesamiento de señales digitales que Asterisk realiza me-
diante software puede tener un fuerte impacto en el número de llamadas simultá-
neas que proveerá. Un sistema que puede fácilmente manejar 50 llamadas G.711
simultáneas, puede caer de rodillas frente al requerimiento de atender 10 canales
comprimidos mediante G.729.
Si será provisto llamada en conferencia y que nivel de actividad en conferencia
se espera: las llamadas en conferencia requieren que el sistema transcodifique y
mezcle cada corriente de audio individual entrante en múltiples corrientes salientes.
Mezclar múltiples corrientes de audio en tiempo real provoca una carga enorme
en el CPU.
Cancelación de eco: La cancelación de eco puede ser necesaria en cualquier llama-
da donde la PSTN esté involucrada. Desde que la cancelación de eco se realiza
mediante una función matemática, mientras más tenga que trabajar el sistema,
mayor será la carga en el CPU.
2.8 Preparando un sistema para Asterisk 51

Lógica de escritura del dial plan: Cada vez que Asterisk tiene que pasar el control
de las llamadas a un programa externo, existe una penalidad en la performance.
La mayor lógica posible debe ser construida en el dial plan. Si scripts externos son
utilizados, éstos deben ser diseñados teniendo a la performance y eficiencia como
metas importantes.
Si bien estos factores deben tenerse en consideración, el impacto en la performance de los
mismos todavía no es conocido con exactitud. Los efectos de cada uno son conocidos en
términos generales, pero no se ha definido un método de calcular la performance preciso.
Esto es en parte debido a que los efectos de cada componente del sistema dependen de
numerosas variables, como el poder de procesamiento del CPU, la calidad de la placa
madre y el chipset en general, la carga total de tráfico sobre el sistema, la optimización
del kernel de Linux, el tráfico de red, el número y tipo de interfaces PSTN, y el tráfico
PSTN (sin mencionar cualquier servicio no perteneciente a Asterisk que el sistema esté
ejecutando simultáneamente).
Veamos los efectos de varios factores claves:
COder/DECoder (CODEC) y transcodificación: Puesto de una manera simple, un
CODEC (apócope de codificador/decodificador o compresión/descompresión) es
un conjunto de reglas matemáticas que definen cómo una forma de onda analógica
será digitalizada. La diferencia entre los distintos codecs es debido en gran parte
a los niveles de compresión y calidad que ofrecen. Mientras más compresión es
requerida, más será el trabajo del DSP para codificar o decodificar la señal. Codecs
no compresores, por consiguiente, originan mucho menos carga sobre el CPU (pero
requiere mayor ancho de banda en la red). La selección del codec debe realizarse
por lo tanto, estableciendo un equilibrio entre ancho de banda y carga sobre el
procesador.
Unidad de Procesamiento Central (y Unidad de Punto Flotante): el CPU está
compuesto de varios componentes, uno de los cuales es la Float Point Unit (FPU).
La velocidad del CPU, complementada con la eficiencia de su FPU, jugará un rol
significativo en el número de usuarios que el sistema puede atender efectivamente.
Otros procesos corriendo simultáneamente en el sistema: al ser un sistema Unix,
Linux está diseñado para soportar la ejecución de varios procesos diferentes, en
lo que se denomina un sistema multitarea. El problema arriba cuando uno de
estos procesos (como Asterisk) demanda un alto nivel de interés por parte del
sistema. Por defecto, Linux distribuirá equilibradamente los recursos entre todas
las aplicaciones que los requieran. Si se instala un sistema con muchas aplicaciones
de servicios diferentes, esas aplicaciones tendrán permitido un acceso igualitario
al CPU. Como Asterisk requiere frecuentemente acceso de alta prioridad al CPU,
no se lleva bien con otras aplicaciones, y si Asterisk debe coexistir con ellas, el
sistema necesitará optimización especial. Esto en principio incluye la asignación
de prioridades a varias aplicaciones en el sistema, y, durante la instalación, una
cuidadadosa atención sobre qué aplicaciones están instaladas como servicios.
Optimizaciones del Kernel: un kernel optimizado para la performance de una apli-
cación específica es algo que muy pocas distribuciones de Linux ofrecen por de-
fecto, y esto es algo que debe tenerse en cuenta. Por lo tanto, al principio de
la instalación, se deberá actualizar el kernel a través de parches que permitan el
mejoramiento de la performance.
2.8 Preparando un sistema para Asterisk 52

Latencia de la respuesta a interrupciones (IRQ): la latencia de la respuesta a

interrupciones es básicamente el retardo entre el momento en que una tarjeta
periférica (como una tarjeta de interfaz telefónica) requiere que el CPU interrumpa
lo que está haciendo y el momento en que el CPU responde y está preparado para
ejecutar la tarea. Los periféricos de Asterisk (especialmente las tarjetas Zaptel)
son extremadamente intolerantes a la latencia de IRQ.
Debido a que las tarjetas Digium requieren de tanta performance, es que generalmente
se recomienda que solo una corra en un sistema. Si se requiere más conectividad de la
que puede proveer una tarjeta, se deberá reemplazar por otra con mayor densidad o
añadir otro servidor.

2.8.3. Selección de Procesador

Como la demanda de performance de Asterisk generalmente incluirá un gran número
de cálculos matemáticos, es esencial que se seleccione un procesador con una poderosa
FPU. El procesamiento de señal que Asterisk realiza puede fácilmente demandar una
asombrosa cantidad de cómputos matemáticos complejos por parte del CPU. La efi-
ciencia con que estas tareas son llevadas a cabo será determinada por el poder de la
FPU dentro del procesador.
Para establecer actualmente el mejor procesador para Asterisk debemos situarnos en un
contexto en donde la industria de la computación avanza rápidamente. Periódicamente,
quizás cada día, la velocidad de los procesadores es mejorada, sumado al hecho de
que Asterisk corre sobre arquitecturas varias. Obviamente, esto es algo bueno, pero
también hace que este punto sea más que una simple tarea. Naturalmente, mientras
más poderosa sea la FPU, más tareas de DSP Asterisk podrá manejar simultáneamente,
por lo que ésta sería la consideración más importante. Cuando se está seleccionando
un procesador, la velocidad del clock es solo una parte de la ecuación. Qué tan bien
se manejen las operaciones de punto flotante será una clave diferenciadora, ya que las
operaciones de DSP en Asterisk establecerán una gran demanda de ellas.
Tanto los CPU Intel como AMD tienen poderosas FPU. En este momento, los chips de
Intel son comúnmente preferibles para sistemas de 32 bits, mientras que los de AMD lo
son para sistemas de 64 bits. Probablemente mientras se lea este párrafo, esta afirmación
dejará de ser cierta.
La conclusión obvia es que se deberá obtener el CPU más poderoso que el presupuesto
permita. Sin embargo, no hay que apresurarse a comprar el CPU más caro que se
consiga. Se debe tener en mente siempre los requerimientos del sistema, después de
todo, un Ferrari de Fórmula 1 seguramente será inapropiado frente a tráficos de horas
pico.
Con el fin de brindar un punto de referencia para tomar una decisión sobre la platafor-
ma, hemos definido tres tamaños de sistemas Asterisk: pequeño, mediano y grande.

Sistemas Pequeños

Los sistemas pequeños (hasta 10 teléfonos) no están inmunes a los requerimientos de

performance de Asterisk, pero la carga típica que tendrá lugar en estos sistemas gene-
ralmente caerá dentro de las capacidades de un procesador moderno.
2.8 Preparando un sistema para Asterisk 53

Si se está construyendo un sistema pequeño con componentes viejos, hay que estar
avisados de que el sistema resultante no trabajará al mismo nivel que una máquina
más poderosa, y tendrá una degradación en la performance bajo la menor carga.
En la preparación de un sistema Asterisk con el propósito de aprender o utilizarlo
como hobbie, se podrá construir una plataforma con todas las características usando
una CPU con relativa baja potencia. Se han corrido varios sistemas Asterisk de prueba
con procesadores Celeron de 433 Mhz hasta 700 Mhz; la carga de trabajo en estos
sistemas es típicamente mínima.

Sistemas Medianos

En los sistemas de tamaño mediano (de 10 a 50 teléfonos) las consideraciones de perfor-

mance a resolver serán más desafiantes. Generalmente, estos sistemas serán desplegados
sobre uno o dos servidores, y así cada máquina será requerida para manejar más que una
tarea específica. Mientras se produce un aumento de cargas, los límites de la platafor-
ma se harán cada vez más visibles. Los usuarios pueden comenzar a percibir problemas
de calidad sin comprender que el sistema no es defectuoso de ningún modo, sino que
simplemente está excedido en su capacidad. Estos problemas empeorarán cada vez más
mientras mayor sea la carga sobre el sistema, con la degradación en consecuencia de la
calidad de los servicios que el usuario está utilizando. Es crítico que los problemas de
performance sean identificados y tratados antes de que sean notados por usuarios.
Monitoreando el funcionamiento de estos sistemas y rápidamente actuando mediante
un desarrollo de cualquier tendencia es una clave para asegurar la provisión de una
plataforma de telefonía de calidad.

Sistemas Grandes

Los sistemas grandes (más de 50 usuarios) pueden ser distribuidos a través de múltiples
servidores, y así las preocupaciones de performance pueden ser manejadas mediante la
simple adición de máquinas. Los sistemas Asterisk muy grandes - de 500 a más de 1,000
usuarios - han sido creados de este modo.
Construir un sistema grande requiere un nivel avanzado de conocimiento en muchas
disciplinas diferentes. Los problemas que se encontrarán en esta arquitectura serán
similares a aquellos encontrados durante cualquier despliegue de múltiples servidores
que manejan una sola tarea, distribuida.

2.8.4. Selección de la Placa Madre

Las placas madre son como los autos: si bien son todos muy similares en principio, la
diferencia está en los detalles. Y como Asterisk es una aplicación de performance, los
detalles son muy importantes.
Lo que haremos, por lo tanto, es dar una idea de las clases de las placas madre que se
espera que trabajen bien con Asterisk, y las características que harán buena una placa.
La clave es tener tanto estabilidad como alto rendimiento. Aquí se mencionan algunas
directrices a seguir:
- Los buses del sistema deben proporcionar la mínima latencia posible. Si se planea
una conexión PSTN usando interfaces analógicas o Primary Rate Interfase (PRI), las
2.8 Preparando un sistema para Asterisk 54

placas Digium Zaptel generarán 1,000 peticiones de interrupción por segundo. Tener
dispositivos sobre el bus que interfieran con este proceso causará la degradación de la
calidad de llamada. Chipsets de Intel (para CPU de Intel) y nVidia nForce (para CPU
AMD) parecen anotar las mejores marcas en esta área.
- Si se está utilizando una placa Zaptel en el sistema, se deberá asegurar que el (BIOS)
permita el máximo control sobre la asignación de IRQ. Por lo general, las placas ma-
dre de alta calidad ofrecerán mucha mayor flexibilidad en lo que concierne al control
mediante el BIOS; placas más económicas ofrecerán muy poco control.
- Las placas madre para servidores generalmente ponen en práctica un estándar (PCI)
diferente que las placas para terminales de trabajo. Mientras hay muchas diferencias, la
más obvia y conocida es que las dos versiones tienen voltajes diferentes. Dependiendo
de que placa se compre, se deberá conocer si se requiere 3.3V o 5V. La mayor parte
de placas madre para servidores tendrán ambos tipos, pero los terminales de trabajo
típicamente tendrán sólo la versión de 5V.
- Usar múltiples procesadores proporcionará una mejora del sistema en lo referido a su
capacidad de manejar múltiples tareas. Para Asterisk, esto será de especial beneficio
en el área de operaciones de punto flotante.
- Hay que evitar las placas madre que incluyen componentes empotrados de audio y
vídeo. Si se quiere una tarjeta de sonido, se instala una. Para el caso de una tarjeta de
vídeo, no se necesitará en absoluto ya que Asterisk no requiere una.
- Si es posible, se deberá instalar un módem externo. Si se debe tener un módem
interno, deberá asegurarse que no sea un Win-modem. El modem debe ser una unidad
completamente autosuficiente.
- Al trabajar con elementos de networking empotrados, si se tiene una falla sobre
un componente de red, la placa madre entera tendrá que ser substituida. Por otra
parte, si se instala una interfaz de red periférica, puede haber una posibilidad mayor de
fracaso debido a la conexión mecánica complicada que se deberá realizar. Algo podrá
amortizarse si se trabaja con placas primarias como de reserva instaladas en el sistema.
- La estabilidad y la calidad del sistema Asterisk serán dependiente de los componentes
que se seleccionen para la arquitectura. El alto costo no siempre es sinónimo de calidad,
pero se deberán conocer los distintos tipos de componentes para PC.
Habiendo dicho todo esto, debemos volver al punto original: Asterisk puede y felizmente
se instalará sobre casi cualquier plataforma PC.

2.8.5. Requerimientos de Suministro de Energía

Un componente a menudo pasado por alto en una PC es el suministro de energía. En un
sistema de telecomunicaciones, estos componentes pueden jugar un papel significativo
en la calidad de la prestación al usuario.

Suministros de energía para computadoras

El suministro de energía que se seleccione para el sistema, desempeñará un papel vital

en la estabilidad de la plataforma entera. Asterisk no es una aplicación en particular
hambrienta de energía, pero cualquier cosa relacionada con multimedia (sea telefonía,
audio profesional, vídeo, etc.) es generalmente sensible en este aspecto.
2.8 Preparando un sistema para Asterisk 55

Este componente a menudo descuidado puede convertir un sistema de buena calidad en

uno con funcionamiento pobre. Del mismo modo, un suministro de energía de primera
categoría podría permitir que un computador personal barato funcione al máximo.
El poder suministrado a un sistema debe proporcionar no sólo la energía necesaria para
que el sistema realice sus tareas, sino también líneas limpias y estables, para todos los
voltajes esperados por el mismo.

Suministros de energía redundantes

En un grado de portador o ambiente de alta disponibilidad, es común desplegar servido-

res con suministro de energía redundante. Esencialmente, esto implica dos suministros
de energía completamente independientes, tanto uno como ambos capaces de suminis-
trar la energía requerida por el sistema.
Hay que tener presente que las mejores prácticas sugieren que para que el sistema sea
adecuadamente redundante, estos suministros de energía deberían estar conectados a
UPSs completamente independientes, que están por su parte alimentados por circuitos
eléctricos totalmente aislados.

2.8.6. Ambiente
El ambiente del sistema consiste en todos aquellos factores que no son parte del servidor
en sí mismo, pero sin embargo desempeñan un papel crucial en la fiabilidad y calidad que
se espera del sistema. Provisiones eléctricas, temperatura de cuarto y humedad, fuentes
de interferencia y seguridad son todos los factores que deberían ser contemplados.

Acondicionamiento de Energía y Unit Power Supply (UPS)

Seleccionando las fuentes de alimentación para el sistema, se debe considerar no sólo la

cantidad de energía que el sistema usará, sino también la manera en que la misma será
entregada.
La energía no es solo el voltaje que viene de la salida en la pared, y nunca se debería
simplemente enchufar un sistema en cualquier fuente eléctrica que esté a mano. Tener
un mínimo de consideración con respecto al suministro de energía del sistema pue-
de proporcionar un ambiente mucho más estable, conduciendo esto a un sistema más
estable.
Utilizar energía correctamente referida a tierra y acondicionada que alimente un sumi-
nistro de energía de buena calidad, asegurará una referencia de tierra limpia (0-voltios)
para el sistema y fijará el ruido eléctrico en la placa madre al mínimo. Éstas son las
mejores prácticas estándares de la industria para este tipo del equipo, que no deberían
ser descuidadas. Un modo relativamente simple de conseguir esto es mediante el uso de
UPS.
Acondicionador de energía UPS
El UPS es conocido por su papel como reserva de batería, pero las ventajas de acondi-
cionamiento de energía que las unidades UPS de alta calidad también proporcionan no
son tan bien conocidas.
El acondicionamiento de energía puede proporcionar un valioso nivel de protección
del ambiente eléctrico regenerando energía limpia por medio de un transformador de
2.8 Preparando un sistema para Asterisk 56

aislamiento. Un acondicionador de energía de calidad en el UPS eliminará el ruido

eléctrico del alimentador de energía y ayudará para asegurar un suministro estable al
sistema.
Lamentablemente, no todas las unidades UPS son fabricadas iguales; muchas de las
unidades baratas no proporcionan energía limpia. Lo que es peor, los fabricantes de
estos dispositivos a menudo prometen toda clases de protección frente a sobre voltajes,
transitorios, etc. Mientras tales dispositivos pueden proteger el sistema de ser dañado
en una tormenta eléctrica, ellos no limpiarán la energía alimentada al sistema, y así no
harán nada para contribuir a la estabilidad.
Por lo tanto hay que asurarse que el UPS es acondicionador de energía. Si esto no se
explicita exactamente, no tendrá esta propiedad.

Puesta a Tierra

El voltaje es definido como la diferencia de potencial eléctrico entre dos puntos. Cuando
se considera una "tierra"(que no es nada más que un camino eléctrico a tierra), la
asunción común es que ésta representa 0 voltios. Pero si no se definen estos 0V en
relación con algo, se está en peligro de asumir cosas que pueden no ser así. Si se mide
el voltaje entre dos referencias a tierra, a menudo se encuentra un potencial de voltaje
entre ellas. Este potencial de voltaje puede ser lo bastante significativo como para
causar errores lógicos o hasta dañar un sistema donde más de un camino a tierra está
presente.
Considerando regulaciones eléctricas, el objetivo de una referencia a tierra es prin-
cipalmente la seguridad humana. En una computadora, la tierra es usada como una
referencia lógica de 0V. Un sistema eléctrico que proporcione la seguridad apropiada
no siempre proporcionará una referencia lógica apropiada, de hecho, los objetivos de
seguridad y calidad de energía están a veces en desacuerdo. Naturalmente, cuando hay
una opción que tomar, la seguridad tiene que ser una prioridad.
Los suministros de energía para los conmutadores modernos están algo aislados de
cuestiones de calidad de energía, pero cualquier sistema de alto rendimiento siempre se
beneficiará de un ambiente bien diseñado. En ordenadores centrales, PBXs propietarios
y otras plataformas informáticas costosas, la tierra del sistema nunca es referenciada a
la suerte. La electrónica y las consolas de estos sistemas siempre están proveídas de una
tierra dedicada que no depende de las referencias a tierra de seguridad suministradas
por el alimentador eléctrico.
Independientemente de cuanto se quiera invertir en la puesta a tierra, cuando se espe-
cifica el suministro eléctrico para cualquier PBX, hay que asegurarse que el recorrido
eléctrico es completamente dedicado hacia el sistema y que se dispone de conductor de
referencia a tierra aislado. Esto puede ser costoso, pero contribuirá enormemente a un
ambiente de energía de calidad para su sistema.
Es también vital que todos y cada uno de los periféricos que se adicionen al sistema se
conecten al mismo receptáculo eléctrico (o, más expresamente, a la misma referencia
de tierra). Esto reducirá la probabilidad de lazos de tierra, que pueden causar ruidos
que dañen o destruyan el equipo.
2.8 Preparando un sistema para Asterisk 57

Circuitos Eléctricos

Si alguien alguna vez ha visto como las luces se atenúan cuando un aparato eléctrico da
"patadas", entonces ha visto el efecto que un dispositivo de gran energía puede tener
en un circuito eléctrico. Si se vieran los efectos de múltiples dispositivos como aquel
a través de un graficador de señal, se vería perfectamente la armónica de 50 Hz o 60
Hz. El ruido armónico es sumamente común en los circuitos eléctricos y puede causar
estragos en equipamiento electrónico sensible. En una PBX, estos problemas pueden
manifestarse como inconvenientes de audio, errores lógicos e inestabilidad de sistema.
Nunca se deberá instalar un servidor en un circuito eléctrico que es compartido con
cualquier otro dispositivo. Debería haber sólo una salida en el circuito, y se debería
conectar sólo el sistema telefónico (y los periféricos asociados) al mismo. El alambre
(incluso la referencia a tierra) debería estar dirigido directamente al panel eléctrico.

El Cuarto de Equipos

Las condiciones ambientales pueden causar estragos en el sistema, y aún es completa-

mente común ver sistemas críticos desplegados con poca o ninguna atención prestada
a estos asuntos. Si uno mira la estadística, se hace obvio que la atención a factores
ambientales puede desempeñar un papel significativo en la estabilidad y la fiabilidad
del sistema.
Humedad
Dicho de forma simple, la humedad es la cantidad de agua en el aire. El agua es un
desastre para la electrónica, principalmente por dos razones:
1) el agua es un catalizador para la corrosión
2) el agua es conductora y por lo tanto bastante propicia para causar cortocircuitos.
No se deberá instalar ningún equipo electrónico en áreas de humedad alta, sin propor-
cionar un medio para quitar la misma.
Temperatura
El calor es el enemigo de la electrónica. Mientras más refrigerado se mantenga el sis-
tema, más fidedigno funcionará. Si no se puede proporcionar un cuarto correctamente
refrigerado para el sistema, como mínimo se debe asegurar que sea colocado en una posi-
ción donde haya un suministro estable de aire limpio y fresco. Además se debe mantener
la temperatura estable. Los cambios de temperatura pueden conducir a condensación
y otros cambios perjudiciales.
Polvo
Consideremos los efectos del polvo:
- Las concentraciones de polvo dentro del sistema pueden restringir las corrientes de
aire, conduciendo a niveles crecientes de calor.
- El polvo puede contener partículas metálicas, que, en cantidades suficientes, contri-
buyen con la degradación de señal o cortos en los circuitos.
Se deberá colocar los servidores críticos en ambientes filtrados y limpiar el polvo regu-
larmente.
Seguridad
2.9 Hardware de Telefonía 58

La seguridad del servidor naturalmente implica protegerlo contra intrusiones provenidas

de la red, pero el ambiente también juega una parte fundamental en la seguridad de un
sistema. El equipamiento telefónico siempre debería estar bajo llave y sólo las personas
que tienen la necesidad de tener acceso al equipo deberían tener permitido el estar cerca
de él.

2.9. Hardware de Telefonía

Si se va a conectar Asterisk con algún equipo de telecomunicaciones, se necesitará el
hardware correcto. El hardware que se requiera será determinado por lo que se busca
proveer con el sistema.

2.9.1. La unión a la PSTN

Asterisk permite fácilmente tender un puente entre redes de conmutación de circuitos y
redes de conmutación de paquete. A causa de la arquitectura abierta de Asterisk (y códi-
go fuente abierto), es posible interconectar interfaces de hardware de cualquier estándar.
La selección de interfaces de telefonía libres está bastante limitada, pero a medida que
el interés en Asterisk crezca, esto cambiará rápidamente. Hasta el momento, uno de los
modos más populares y rentables de unirse a la PSTN es usar las placas de interfaz que
surgieron del Proyecto de Telefonía Zapata (http://www.zapatatelephony.org).

Placas de interfaz analógicas

A menos que se necesiten muchos canales (o se tenga dinero para gastar en instalaciones
de telecomunicaciones mensualmente), las posibilidades son que la interfaz con la PSTN
consista en uno o varios circuitos análogos, donde cada uno requerirá un puerto Foreign
eXchange Office (FXO).
Digium, la compañía que patrocinó el desarrollo de Asterisk, produce la tarjeta de
interfaz analógica más popular para Asterisk, conocida como TDM400P. La TDM400P
es una placa de cuatro puertos que permite la conexión de hasta cuatro placas hijas
que entregan puertos FXO o Foreign eXchange Station (FXS). El TDM400P puede ser
comprado con estas placas preinstaladas y Digium ha designado números de parte para
describir estas configuraciones. La convención de nombramiento es TDM x y, donde x
e y son números que representan la cantidad de placas FXS y FXO, respectivamente.
Se puede ingresar a http://www.digium.com para más información sobre estas placas.
Una tarjeta más vieja producida por Digium era conocida como X100P. Ya no está
disponible desde Digium, pero se puede encontrar un clon de esta placa en el mercado.
Otra compañía que produce placas analógicas compatibles con Asterisk es Voicetronix.
Ellos tienen tres placas Asterisk: OpenLine4, OpenSwitch6, y OpenSwitch12.
Tarjeta Wildcard TDM400P
La placa Wildcard TDM400P es una tarjeta PCI de media longitud que soporta de una
a 4 interfaces telefónicas para conectar teléfonos o líneas analógicas a la PC. Soporta
teléfonos analógicos estándar y Analog Display Services Interface (ADSI) para aplica-
ciones Small Office Home Office (SOHO). Soporta combinaciones de hasta 4 módulos
FXO/FXS.
2.9 Hardware de Telefonía 59

Fig. 2.1: Tarjeta TDM400P

Tarjeta Wildcard X100P

La tarjeta Wildcard X100P provee un solo puerto FXO a través de una interfaz PCI.
Esta tarjeta permite a Asterisk contestar llamadas de un proveedor de telefonía estándar
a través de una línea analógica o recibir llamadas desde otra PBX sobre TDM si el uso
de hardware T1. La placa X100P es ideal para servicios de Respuesta de Voz interactiva
IVR y para correo de voz (Voicemail).
La placa X100P soporta todas las opciones avanzadas incluyendo identificador de lla-
mada, conferencia y llamada en espera.

Placas de interfaz digitales

Si se requiere más de 10 circuitos o conectividad digital, las posibilidades son placas para
tramas T1 o E1. Hay que tener en cuenta, sin embargo, que mensualmente los gastos
para un circuito PSTN digital varían extensamente. En algunos sitios, solamente cinco
circuitos pueden justificar una trama digital; en otros, la tecnología nunca justificará
los costos.
El Proyecto de Telefonía Zapata al principio produjo una tarjeta T1, la Tormenta, que
es la antepasada de las placas T1 más compatibles con Asterisk. Las placas Tormen-
ta originales son ahora consideradas obsoletas, pero todavía funcionan con Asterisk.
Actualmente, la única compañía conocida que produce estas placas es Varion.
Digium fabrica varias tarjetas de interfaz para circuitos digitales diferentes. Los rasgos
en las placas son los mismos; las diferencias primarias son si ellas proporcionan interfaces
T1 o E1 y cuantas interfaces provee cada tarjeta. Aunque es técnicamente posible, el
consenso general en la comunidad Asterisk es que no más de una placa debería ser
desplegada en un sistema.
2.9 Hardware de Telefonía 60

Fig. 2.2: Tarjeta X100P

Sangoma, quiénes han estado produciendo placas libres durante muchos años, han aña-
dido recientemente soporte para placas T1/E1 de Asterisk. Las placas Sangoma con-
tienen Field-Programmable Gate Arrays (FPGA), que las hacen sumamente flexibles.
En un ambiente Asterisk, por ejemplo, han sido programadas para ser interfaz con el
controlador del canal Zapata.
Tarjeta Wildcard T100P
La placa T100P es una interfaz compacte y poderosa que soporta transmisión de voz y
datos sobre conexiones T1 y PRI. Posibilita la interconexión de teléfonos tradicionales
con las tecnologías de VoIP a través de Asterisk.
Esta placa puede ser usada para una amplia gama de servicios de PBX avanzadas y
funciones de IVR incluyendo voicemail, conferencias, llamada de tres vías y Gateways
VoIP. El equivalente europeo de esta placa es la E100P (provee 30 canales, i.e. una E1).
Soporta los modos de voz y datos simultáneamente. Por ejemplo puede usarse 12 canales
para datos y 12 para voz, dejando a asterisk direccional los canales a sus destinos.
Soporta los protocolos estándares de telefonía y datos incluyendo los protocolos de
señalización Robbed Bit Siggnalling (RBS) y PRI para voz, Cisco HDLS, Point to
Point Protocol (PPP) y Frame Relay para transmisión de datos.
Tarjeta Wildcard E100P
Posee las mismas características que la placa anterior pero para una E1 (32 canales).
Tarjeta Wildcard TE410P/TE405P
La placa TE410P es una placa PCI de 3.3V mientras que la TE405P es de 5V. Posee
4 conexiones separadas. Cada uno puede proveer señalización T1 o E1.

Bancos de canales

Un banco de canales es ligeramente definido como un dispositivo que permite que

un circuito digital sea demultiplexado en varios circuitos análogos (y viceversa). Más
expresamente, un banco de canales permite conectar líneas y teléfonos analógicos en
un sistema a través de una línea T1.
2.9 Hardware de Telefonía 61

Fig. 2.3: Banco de canales

La figura 2.3 muestra como un banco de canales cabe en un sistema telefónico de oficina
típico.
Aunque ellos puedan ser caros de comprar, muchas personas creen que el único modo
apropiado de integrar circuitos y dispositivos análogos en Asterisk es a través de un
banco de canales.
Algunos fabricantes son Adit, Rhino y Adtran. Las características que se buscan en un
banco de canales incluyen soporte para 2 cables, supervisión de desconexión y soporte
para líneas FX. Debe ser capaz, además, de funcionar como un generador de repique,
o sea, debe ser capaz de proveer la tensión para el repique de llamada.
Los equipos modernos pueden transcodificar la señalización de las líneas analógicas al
formato T1. Algunos proveen además impedancia dinámica lo que puede ser muy útil
para ayudar a eliminar el eco.
En asterisk se coloca una conexión T1 entre el banco de canales y el servidor. O sea,
se coloca una placa T1 en Asterisk y se la conecta al banco de canales a través de un
cable T1 usualmente. El banco de canales separará los canales individuales de la T1 en
puertos separados para su conexión.

Otros tipos de interfaces PSTN

Existen muchos gateways VoIP que pueden ser configurados para proporcionar acceso
a la PSTN. En general, éstos serán los más usados en sistemas pequeños (una o dos
líneas). También pueden ser muy complicados para configurar, ya que la interacción
entre varias redes y dispositivos requiere un entendimiento sólido tanto de la telefonía
como de los fundamentos de VoIP.
Otro modo de conectarse a la PSTN es mediante el uso del circuito Integrated Services
Digital Network (ISDN) Basic Rate Interfase (BRI). BRI es un estándar de telecomu-
nicaciones digital que especifica un circuito de dos canales que puede llevar hasta 144
kbps de tráfico. Es muy raramente usado en Norteamérica y la mayor parte del mundo,
pero muy popular en Europa y Latinoamérica.
2.10 Tipos de Teléfono 62

2.9.2. Conexión a una Red Telefónica de Conmutación de Pa-

quetes
Si no se tiene que conectar a la PSTN, Asterisk no requiere más hardware que un
servidor con una placa de red.
Sin embargo, si se va a proporcionar música en espera o llamada en conferencia y no se
dispone de una fuente de cronometraje física, se necesitará el módulo kernel ztdummy
de Linux. El ztdummy es un mecanismo de reloj diseñado para proporcionar una fuente
de cronometraje a un sistema que no posee hardware de cálculo de tiempo. En la Versión
2.4 de kernel Linux, para usar ztdummy se debe tener un controlador UHCI USB en la
placa madre. En Linux 2.6, esta exigencia no existe más.

2.10. Tipos de Teléfono

Sabemos qué es un teléfono, pero ¿serán los mismos de aquí a cinco años? Parte de la
revolución a la cual Asterisk contribuye es la evolución del teléfono, de un dispositivo
de comunicaciones de audio simple en un terminal de comunicaciones multimedia que
proporciona toda clase de funciones aún por ser imaginadas.
Como una introducción a este concepto emocionante, se hablará brevemente de varias
clases de dispositivos actualmente llamamos teléfonos (cualquiera de los cuales pue-
de ser fácilmente integrado con Asterisk). También se hablará de algunas ideas sobre
cómo estos dispositivos pueden evolucionar en el futuro (dispositivos que también se
integrarán fácilmente con Asterisk).

2.10.1. Teléfonos Físicos

Cualquier dispositivo físico cuyo objetivo primario sea terminar una petición de audio
entre dos puntos puede ser clasificado como un teléfono físico. Como mínimo, tal dispo-
sitivo tiene un auricular/micrófono (handset) y un dial; también puede tener algunas
otras características, como una pantalla y varias interfaces de audio.
Esta sección toma una breve mirada sobre varios dispositivos de usuario que podría
podrían conectarse a un sistema Asterisk.

Teléfonos análogos

Los teléfonos análogos han estado en uso desde la invención del teléfono. Hasta hace
aproximadamente 20 años, todos los teléfonos eran analógicos. Aunque los teléfonos
análogos tengan algunas diferencias técnicas en países diferentes, todos ellos funcionan
con principios similares.
Cuando un ser humano habla, las cuerdas vocales, lengua, dientes y los labios crean
una compleja variedad de sonidos. El objetivo del teléfono es capturar estos sonidos y
convertirlos en un formato conveniente para la transmisión por el cable telefónico. En
un teléfono analógico, la señal transmitida es análoga a las ondas sonoras producidas
por la persona que habla. Si se pudiera ver pasar las ondas sonoras de la boca hacia
el micrófono, ellas serían proporcionales a la señal eléctrica que se podría medir en el
alambre.
2.10 Tipos de Teléfono 63

Los teléfonos análogos son la única clase de teléfonos que están comúnmente disponibles
en cualquier tienda de electrónica de venta al público. En los próximos pocos años,
pueden esperarse cambios dramáticos.

Teléfonos digitales propietarios

A medida que los sistemas de conmutación digitales se desarrollaban en los años 1980
y 1990, las compañías de telecomunicaciones desarrollaban PBX digitales y Key Te-
lephone Systems (KTS). Los teléfonos propietarios desarrollados para estos sistemas
eran completamente dependientes de los sistemas a los cuales estuvieran conectados y
no podían ser usados en cualquier otro sistema. Incluso los teléfonos producidos por el
mismo fabricante eran no compatibles (por ejemplo, un set Nortel Norstar no funciona
con una PBX Nortel Meridian 1). La naturaleza propietaria de los teléfonos digitales
limita su futuro. En esta era emergente de comunicaciones a base de estándares, ellos
serán rápidamente relegados al basurero de la historia.
El handset en un teléfono digital es generalmente idéntico en cuanto al funcionamiento
del handset en un teléfono análogo, y ellos son a menudo compatibles el uno con el otro.
Donde el teléfono digital es diferente es por dentro: la señal análoga es muestreada y
convertida en una señal digital, es decir una representación numérica de la forma de
onda análoga. Por ahora, sólo diremos que la ventaja primaria de una señal digital
consiste en que puede ser transmitida a distancias ilimitadas sin pérdida de calidad de
señal.
Las posibilidades de que alguien alguna vez haya fabricado un teléfono digital pro-
pietario directamente compatible con Asterisk son bastante pequeñas, pero compañías
como Citel (http://www.citel.com) han creado gateways que convierten las señales
propietarias a SIP.

Teléfonos de ISDN

Antes de VoIP, la cosa más cercana a un teléfono digital a base de estándares era un
terminal ISDN BRI.
Desarrollado a principios de los años 1980, se esperó que ISDN revolucionara la industria
de telecomunicaciones exactamente del mismo modo en que VoIP promete finalmente
conseguirlo en la actualidad.
Mientras ISDN fue extensamente desplegado por las compañías telefónicas, muchos
consideran que el estándar ha sido un fracaso. El alto gasto de implementación, costos
recurrentes y la poca cooperación entre los principales prestadores contribuyeron a un
ambiente que causó más problemas que soluciones.
El acceso BRI fue pensado para atender a dispositivos terminales y sitios pequeños
(un lazo de BRI provee dos circuitos digitales). Mientras una riqueza de dispositivos
BRI han sido desarrollados, este acceso ha sido desaprobado a favor de tecnologías más
baratas y rápidas, como Asincronic Digital (ADSL), módems de cable y VoIP.
BRI es todavía muy popular para comunicación de vídeo, mientras se proporcione una
conexión de ancho de banda fijo. Sin embargo, BRI no tiene el tipo de calidad en
cuanto a cuestiones de servicio que una conexión de VoIP tendría, ya que es tecnología
de conmutación de circuitos.
2.10 Tipos de Teléfono 64

El acceso BRI todavía es a veces usado en lugar de circuitos análogos para proporcionar
trunking. Esta es una buena idea dependiendo sobre todo de cuales son los precios de
la compañía local de teléfono y que servicios provee.

Teléfonos IP

Los teléfonos IP son los heraldos del cambio más emocionante de la industria de te-
lecomunicaciones. En el futuro próximo, los teléfonos IP a base de estándares estarán
disponibles en negocios minoristas. La riqueza de posibilidades inherentes en estos dis-
positivos causará una explosión de aplicaciones interesantes, desde video teléfonos, a
dispositivos con emisión de alta fidelidad, soluciones de movilidad inalámbricas, sets
construidos a pedido de las industrias particulares y sistemas multimedia flexibles, en-
tre otras.
La revolución que los teléfonos IP engendrarán no tiene nada que ver con los nuevos
tipos de alambre para unir los teléfonos y todo que ver con dar el poder de comunicarse
de la forma que uno quiera.
Los tempranos modelos de teléfonos IP que han estado disponibles durante varios años
no son representantes del futuro de estas aplicaciones emocionantes. Ellos son sim-
plemente un escalón; un paquete familiar para abrigar un nuevo modo fantástico de
pensar.
El futuro es mucho más prometedor.

2.10.2. Teléfonos por Software

Un teléfono por software es un programa que proporciona la funcionalidad telefónica en
un dispositivo no telefónico, como una computadora o un PDA (PDA). Un softphone
debería tener probablemente alguna clase de dial y debería proporcionar una interfaz
que recuerde a los usuarios un teléfono. ¿Pero siempre será este el caso?
Puede esperarse que el término softphone evolucione rápidamente. Como un ejemplo de
esta evolución, considere lo siguiente: ¿podríamos correctamente definir a los progra-
mas de comunicación populares como el Messenger como un softphone? El Microsoft
Network (MSN) Messenger proporciona la capacidad de iniciar y recibir conexiones de
VoIP. ¿No califica esto como un softphone? La contestación a estas preguntas requie-
re un conocimiento del futuro que no poseemos. Basta con decir que si bien hasta el
momento, se espera que los teléfonos por software luzcan y suenen como los teléfonos
tradicionales, esta concepción probablemente cambie en un futuro próximo.
Mientras los estándares evolucionan y nos alejamos del teléfono tradicional hacia la
cultura de comunicaciones multimedia, la línea entre teléfonos por software y los físicos
se hará más delgada. Por ejemplo, podríamos comprar un terminal de comunicaciones
para servir de teléfono, e instalar un programa telefónico por software en él para que
proporcione las funciones que deseamos.
Habiendo enturbiado así las aguas, lo mejor que podemos hacer en este punto es definir
el término softphone: cualquier software que corre en una computadora, que presenta
la sensación visual de un teléfono y provee como su función primaria la capacidad de
hacer y recibir comunicaciones full dúplex de audio.
2.11 Consideraciones de Linux 65

2.10.3. Adaptadores de Telefonía

Un adaptador de telefonía (por lo general referido como un Analog Telephone Adaptor
(ATA)) puede ser descrito como un dispositivo de usuario final que convierte comuni-
caciones de un protocolo al otro. Más comúnmente, estos dispositivos son usados para
convertir señales digitales (IP o Propietarias) a una conexión análoga que se pueda
enchufar en un teléfono estándar.
Estos adaptadores podrían ser descritos como gateways, ya que esta es su función. Sin
embargo, el uso popular del gateway de telefonía describiría probablemente mejor un
multiadaptador de puertos de telefonía, generalmente con funciones de encaminamiento
más complicadas.
Los adaptadores de telefonía estarán entre nosotros mientras haya una necesidad de
unir estándares incompatibles y viejos dispositivos a nuevas redes. Finalmente, nuestra
confianza en estos dispositivos desaparecerá, como nuestra confianza en el módem, caído
en desuso por obsolescencia.

2.10.4. Terminales de Comunicaciones

El terminal de comunicaciones es un viejo término que desapareció durante una década
o dos y es presentado aquí de nuevo.
Cuando los sistemas PBX digitales fueron liberados, fabricantes de estas máquinas se
dieron cuenta que ellos no podían referirse a sus puntos extremos como teléfonos, su na-
turaleza propietaria les impidió unirse a la PSTN. Fueron entonces llamados terminales,
o estaciones. Los usuarios, por supuesto, no entendieron esto. Lucía como un teléfono
y actuaba como un teléfono, y por lo tanto era un teléfono. Todavía se encuentra de
vez en cuando que los sets de PBX se refirieron a terminales, pero en su mayor parte
los llaman teléfonos.
La importancia renovada del término terminal de comunicaciones no tiene nada que
ver con algo propietario, mejor dicho, representa lo contrario. Mientras desarrollamos
modos más creativos de comunicar el uno con el otro, ganamos acceso a muchos dispo-
sitivos diferentes que nos permitirán conectarnos. Considere los siguientes escenarios:
¿Si se usa un PDA para conectarse a un voicemail y recuperar los mensajes de voz
(convertidos a texto), se transforma el PDA en un teléfono?
¿Si se anexa una cámara de vídeo a una computadora, se conecta a un sitio Web
(WEB) y se solicita una charla en vivo con un representante de atención al cliente,
la computadora es ahora un teléfono?
¿Si se usa el teléfono IP en una cocina para navegar en busca de recetas, es eso
una llamada telefónica?
El punto es simplemente este: ¿probablemente nos telefoneemos el uno al otro, pero
vamos siempre a usar teléfonos para hacerlo?

2.11. Consideraciones de Linux

Si se pregunta a alguien en la Fundación de Software Libre, ellos dirán que lo que
conocemos como Linux es de hecho GNU/Linux. Dejando todos los argumentos eti-
mológicos aparte, hay alguna verdad valiosa a esta declaración. Mientras el kernel del
2.12 Instalando Asterisk 66

sistema operativo es en efecto Linux, la gran mayoría de las utilidades instaladas en

un sistema Linux y usadas con regularidad, son de hecho utilidades GNU. Linux es
probablemente sólo 5 % Linux, posiblemente 75 % GNU y quizás 20 % cualquier otra
cosa más.
¿Por qué importa esto? Bien, la flexibilidad de Linux es tanto una bendición como
una maldición. Es una bendición porque con Linux se puede trabajar realmente en un
sistema operativo propio desde el principio. Ya que muy pocas personas alguna vez
hacen esto, la maldición es en gran parte debido a la responsabilidad que se debe llevar
en la determinación de que utilidades GNU instalar y como configurar el sistema.

2.12. Instalando Asterisk

Anteriormente se hizo referencia a como preparar el sistema para instalar Asterisk.
Ahora se obtendrá, extraerá, compilará e instalará éste software.
Aunque un gran numero de distribuciones de Linux y arquitecturas de PC son excelentes
candidatos para instalar Asterisk, se ha decidido hacer foco en una distribución en
particular para mantener la claridad a lo largo del capítulo. Las siguientes instrucciones
fueron hechas lo mas genéricas posibles, pero la inclinación es hacia la estructura y
utilidades de Red Hat. Se eligió ésta distribución por su set de comandos, estructura
de directorios y por ser familiar a la gran mayoría de los usuarios.

2.12.1. ¿Qué paquetes necesito?

Asterisk utiliza tres paquetes principales: el programa principal Asterisk (asterisk ), los
drivers de telefonía Zapata (zaptel ), y las librerías PRI (libpri). Si es necesaria una
red pura de VoIP, el único requerimiento es el paquete asterisk. Los drivers zaptel son
necesarios si se utiliza hardware analógico o digital, o si se utiliza el driver ztdummy (se
explicará mas adelante) como interfaz de temporización. La librería libpri es técnica-
mente opcional a menos que se utilice una interfaz ISDN PRI, pero se recomienda que
sea instalada en conjunto con el paquete zaptel.
Otro paquete que se puede instalar es asterisk-sounds. Aunque Asterisk viene con
muchos sonidos predeterminados en la distribución original, el paquete asterisk-sounds
proporciona muchos más. Si se quiere expandir el número de grabaciones profesionales
para utilizar con su sistema Asterisk, éste paquete es fundamental.

2.12.2. Requerimientos de los paquetes

Para compilar Asterisk, se debe instalar el compilador Compilador de C (GCC) (Versión
3.x o posterior) y sus dependencias. Mientras la versión 2.96 del GCC puede funcionar
por ahora, versiones futuras no lo harán. Asterisk también requiere bison y ncurses
para funcionalidad Command-Line Interface (CLI). La librería de criptografía en As-
terisk requiere OpenSSL y sus paquetes de desarrollo. Si se necesita usar para el tem-
porizador ztdummy, o cualquier driver de hardware provisto por Zaptel, será necesario
instalar el paquete zaptel. Si está instalando libpri, asegurarse de instalarlo antes que
asterisk.
2.12 Instalando Asterisk 67

Zaptel requiere libnewt y sus paquetes de desarrollo para el programa zttool (ver
Usando ztcfg y zttool más abajo) y el módulo usb-uhci para ztdummy. Si se utilizan
interfaces PRI, Zaptel también requiere el paquete libpri.

2.12.3. Obteniendo el código fuente

El código fuente de Asterisk se puede obtener del servidor File Transfer Protocol (FTP)
de Digium, situado en ftp://ftp.digium.com. La manera mas fácil de obtener una
versión estable es a través del programa wget. Se utilizará el directorio /usr/src/
para extraer y compilar el código fuente de Asterisk. Notar que para escribir en dicho
directorio necesitará acceso como root y así poder instalar Asterisk y sus paquetes
asociados.
Para obtener el último código fuente estable vía wget, ingresar los siguientes comandos
en la consola:

# cd /usr/src/
# wget -passive-ftp ftp.digium.com/pub/asterisk/asterisk-1.*.tar.gz
# wget -passive-ftp ftp.digium.com/pub/asterisk/asterisk-sounds-*.tar.gz
# wget -passive-ftp ftp.digium.com/pub/zaptel/zaptel-*.tar.gz
# wget -passive-ftp ftp.digium.com/pub/libpri/libpri-*.tar.gz

Mientras Digium no cambie la manera de poner cosas en el sitio FTP, el comando wget
automáticamente obtiene la ultima versión. Reemplazar el * por la versión de software
disponible.

2.12.4. Extrayendo el código fuente

Si se utilizó wget para obtener el código fuente del servidor FTP, necesitará extraer
éste antes de compilarlo. Si no bajó los paquetes en /usr/src/, puede moverlos a
ese directorio ahora, o especificar el camino completo para su localización. Se usa la
aplicación GNU tar para extraer el código fuente desde los archivos comprimidos. Es
un simple proceso que se logra con los siguientes comandos:

# cd /usr/src/
# tar -zxvf zaptel-*.tar.gz
# tar -zxvf libpri-*.tar.gz
# tar -zxvf asterisk-*.tar.gz
# tar -zxvf asterisk-sounds*.tar.gz

Estos comandos extraerán los paquetes y códigos fuentes a sus respectivos directorios.

2.12.5. Obteniendo el código fuente de Asterisk desde CVS

El Concurrent Versioning System (CVS) es una herramienta que provee un gran reposi-
torio central (y variado) que se puede utilizar para mantener actualizadas aplicaciones
manejando gran cantidad de archivos asociados con proyectos de desarrollo. Cuando un
cambio se realiza, éste es notificado al servidor CVS, donde inmediatamente está dis-
ponible para bajarlo y compilarlo. Otra particularidad de usar CVS es que una versión
2.12 Instalando Asterisk 68

Fig. 2.4: Capas de interacción entre Asterisk y el Kernel Linux

de un archivo en particular puede ser desinstalado si algo llega a funcionar mal, o sea si
algo está funcionando bien hasta cierto punto y luego de realizar un cambio comienza
a fallar, se puede volver a la versión que funcionaba, de una manera muy fácil.
Un desarrollador buscando de obtener las últimas actualizaciones del código fuente,
necesitará bajarlas de los servidores CVS:
1 Exportar el path CVSROOT:
# cd /usr/src/
# export CVSROOT=:pserver:anoncvs:[email protected]:/usr/cvsroot
2 Bajar el HEAD del CVS
# cvs checkout zaptel libpri asterisk
3 Bajar STABLE 1.0 del CVS
# cvs checkout -r v1-0 zaptel libpri asterisk
4 Bajar STABLE 1.2 del CVS
# cvs checkout -r v1-2 zaptel libpri asterisk
5 Bajar módulos opcionales del CVS
# cvs checkout asterisk-sounds asterisk-addons

2.12.6. Compilando Zaptel

La figura siguiente muestra las capas de interacción entre Asterisk y el kernel de Linux
con respecto al hardware de control. En el lado de Asterisk es el módulo de canal
Zapata, chan_zap. Asterisk usa esta interfaz para comunicarse con el kernel de Linux
donde se cargan los drivers para el hardware.
La interfaz Zaptel es un módulo cargable en el kernel que presenta una capa de abs-
tracción entre los drivers de hardware y el módulo Zapata en Asterisk. Es este concepto
2.12 Instalando Asterisk 69

el que permite a los drivers de los dispositivos ser modificados sin ningún cambio en la
fuente de Asterisk.
Los drivers de los dispositivos se utilizan para comunicarse directamente con el hardware
y pasar información entre éste y el Zaptel.
Nota: Antes de compilar los drivers Zaptel en un sistema que corre un kernel de Li-
nux 2.4, se debe verificar que /usr/src/ contiene un link simbólico llamado Linux-2.4
apuntando al fuente del kernel. Si no existe, debe crearlo con el siguiente comando:
# ln -s /usr/src/‘uname -r‘ /usr/src/Linux-2.4
Computadoras corriendo distribuciones de Linux con kernel 2.6 usualmente no requie-
ren este link simbólico.

2.12.7. El driver ztdummy

En Asterisk, ciertas aplicaciones requieren dispositivos de temporización para operar.
Todos los elementos de hardware PCI Digium proveen una interfaz de tiempo a 1kHz.
Si carece del hardware PCI requerido para proveer tiempo, el driver ztdummy se puede
utilizar como dispositivo de tiempo. En las distribuciones basadas en el kernel 2.4,
ztdummy debe usar el reloj provisto por el controlador UHCI USB. El driver busca ver
que el módulo usb-uhci esté cargado y que la versión del kernel sea al menos la 2.4.5.
Versiones viejas del kernel son incompatibles con ztdummy.
En distribuciones basadas en el kernel 2.6, ztdummy no requiere el uso del controlador
USB.
La configuración de MakeFile por defecto no crea ztdummy. Para compilar ztdummy,
debe remover un marcador que comenta una línea en MakeFile.
Con un editor de texto abrir el archivo y encontrar la siguiente línea:

MODULES=zaptel tor2 torisa wcusb wcfxo wctdm \

Ztdynamic ztd-eth wct1xxp wct4xxp wcte11xp # ztdummy

Quitar el símbolo cardinal (#) que está delante de ztdummy guardar el archivo, y
compilar Zaptel como se realiza usualmente.

2.12.8. Drivers telefónicos Zapata

Compilar los drivers telefónicos Zapata para utilizarlos con el hardware Digium es
sencillo. Simplemente correr make para el kernel 2.4 o 2.6 (el MakeFile determinará la
versión del kernel). Usar estos comandos para compilar Zaptel (reemplace version con
la versión de zaptel):

# cd /usr/src/zaptel-version
# make clean
# make
# make install

En servidores corriendo Debian puede suceder que exista un error de compilación

(directory not found) al ejecutar make para construir los drivers zaptel.En este caso
puede intentarse proceder como se detalla a continuación.
2.12 Instalando Asterisk 70

Corroborar que estén instalados los encabezados del kernel (kernel-headers) que
coincidan exactamente con el kernel que se tiene instalado. Se puede comprobar la
version del kernel ejecutando el comando uname -r lo que dará como salida por ejem-
plo 2.6.8-2-386. Luego utilizando la aplicación APT descargar las fuentes de zaptel
(ej. apt-get install zaptel-source). Puede que necesite tener instalada la aplica-
ción dpatch.
Hecho esto, ejecutar los siguientes comandos:

# cd /usr/src
# m-a build zaptel
# m-a a-i zaptel
# modprobe zaptel

Y usando el comando lsmod en combinación con grep puede controlarse si el módulo

zaptel está cargado.
# lsmod | grep z
Si se está utilizando un sistema en donde make usa los directorios /etc./rc.d/init.d/
o /etc./init.d/, se tendrá que correr el comando make config también. Esto insta-
lará los scripts que se cargan al iniciar el sistema, usando el comando chkconfig para
cargar el módulo zaptel automáticamente al iniciar. El equivalente de chkconfig en
Debian es update-rc.d.

2.12.9. Usando ztcfg y zttool

Dos programas instalados junto con Zaptel son ztcfg y zttool. El programa ztcfg se
utiliza para leer la configuración en /etc./zaptel.conf y configurar el hardware. El
otro programa se puede usar para verificar el estado del hardware que ha sido instalado.
Por ejemplo, si se usa una tarjeta T1 y no hay comunicación entre los puntos finales,
deberá ver una alarma roja. Si todo está configurado correctamente y la comunicación
es posible, vera un OK. La aplicación zttool también sirve para tarjetas analógicas,
ya que nos dice el estado actual (configurada, colgada, etc.).
Nota: La librería libnewt debe instalarse para poder compilar zttool.

2.12.10. El archivo zconfig.h

El archivo zconfig.h es donde se encuentran muchas de las opciones compiladas de
Zaptel. No se necesitará editar este archivo siempre, pero ahora nombraremos algunas
opciones que pueden ser interesantes. Para habilitar las opciones, quitar las etiquetas
de comentario (/* */). Si se decide habilitar cualquiera de éstas opciones, asegúrese de
hacer make clean antes de recompilar y reinstalar Zaptel.

Boost ringer

Habilitando la opción BOOST_RINGER, se incrementa la cantidad de voltaje provisto por

el teléfono cuando suena de aproximadamente 70V a 89V. Algunos dispositivos pueden
no detectar que el teléfono suena por debajo de ciertos voltajes, por eso esta opción
puede ser necesaria. Notar que subir el voltaje requiere más energía, y probablemente
2.12 Instalando Asterisk 71

sea necesario en teléfonos conectados a una gran distancia. Básicamente, dejar esta
opción a menos que el extremo lejano no detecte que el teléfono suena correctamente.
Para habilitar ésta opción, descomente la siguiente línea:
/* #define BOOST_RINGER */
La opción BOOST_RINGER puede ser declarada cuando se carga el driver por medio de
modprobe, así que no va a ser necesario compilarlo dentro del driver (recomendado).

Deshabilitar ley µ/ley a

Si define CONFIG_CALC_XLAW le informa a Zaptel que no preprocese la Ley µ/ley a en

tablas y recalcule ésto por cada muestra.
No se ha tomado el tiempo del proceso, pero el código original decía que si se tiene un
número pequeño de canales y/o una caché pequeña de nivel-2, puede ser más rápido
ejecutar el código de cálculo que hacer una búsqueda en la tabla cargada en memoria.
Para habilitar la opción, descomentar la línea siguiente de zconfig.h:
/* #define CONFIG_CALC_XLAW */

Habilitar la optimización MMX

Puede activar la optimización Tecnologia MMX (MMX) (si el procesador lo soporta)

removiendo el comentario de la siguiente línea:
/* #define CONFIG_ZAPTEL_MMX */
Tenga cuidado que CONFIG_ZAPTEL_MMX se considera incompatible con procesadores
AMD y puede causar inestabilidad del sistema.

Seleccionar el método de cancelación de eco

Todos los canceladores de eco en Asterisk usan el algoritmo de respuesta al impulso in-
finito Finit Impulse Response (FIR). Las diferencias entre ellos es mínima. Por defecto,
se usa el cancelador de eco MARK2, éste es considerado el más robusto de todos.
Para cambiar la configuración por defecto, hay que agregar etiquetas de comentario en
la línea #define ECHO_CAN_MARK2 y sacar los comentarios de otras:

/* #define ECHO_CAN_STEVE */
/* #define ECHO_CAN_STEVE2 */
/* #define ECHO_CAN_MARK */
#define ECHO_CAN_MARK2
/* #define ECHO_CAN_MARK3 */

Deshabilitar la cancelación de eco

Cuando la cancelación de eco está activada en Asterisk, es posible desactivarla man-

dando un tono de 2100-Hz en el comienzo de la llamada. Si no se quiere que Asterisk
desactive la cancelación de eco justo cuando se detecta el tono de cancelación de eco,
descomentar la siguiente línea:
2.12 Instalando Asterisk 72

/* #define NO_ECHOCAN_DISABLE */
Maquinas de FAX y módems usan el tono de 2100-Hz durante la negociación, y Asterisk
monitorea por este tono durante el establecimiento de la llamada.

Habilitar HDLC

Cuando se utiliza el driver Zaptel con un hardware T1 o E1, se puede configurar Zaptel
para usar canales TDM para datos en lugar de la voz. Para activar la funcionalidad
HDLC en los drivers, descomentar la siguiente línea:
/* #define CONFIG_ZAPATA_NET */
Para que este cambio tenga sentido, se debe usar la utilidad sethdlc y realizar algunas
configuraciones en zapata.conf.

Habilitar ZapRAS

Se puede usar el programa ZapRAS para transformar Asterisk en una Remote Ac-
cess Server (RAS) para usar con las conexiones ISDN. Activar esto descomentando
en zconfig.h la siguiente línea:
/* #define CONFIG_ZAPATA_PPP */
Se tiene que configurar el demonio PPP: no es tan trivial esta configuración.

Habilitar el watchdog de Zaptel

Se le puede decir a Zaptel que monitoree el estado de las interfaces por medio de
los propios watchdog. Se verificará si las interfaces cesan de tomar interrupciones o
cualquier otra falla. Si esto llegase a pasar, el hardware automáticamente se reiniciará.
Descomentar la siguiente línea para activar el watchdog:
/* #define CONFIG_ZAPTEL_WATCHDOG */

Establecer la zona de tono por defecto

La opción de información de zona de tono se utiliza para seleccionar cual tipo de tonos
(Ej., tono de discado, indicador de ocupado, tono de ring, etc.), es definido en el archivo
zonedata.c, y debe ser usado como por defecto.
El archivo zonedata.c contiene las frecuencias y patrones que Asterisk usa para comu-
nicarse con la red PSTN en varios países y para señalizar teléfonos conectados. La zona
de tono por defecto (0) se utiliza para indicar frecuencias de señalización en Norte Amé-
rica. Otras zonas de tono incluidas son Australia (1), Francia (2), Japón (7), Taiwán
(14), y muchas otras. Se puede cambiar la zona por defecto en la siguiente línea:
#define DEFAULT_TONE_ZONE 0
2.12 Instalando Asterisk 73

Habilitar señalización de comienzo de tierra CAC

Algunos dispositivos, como los puertos FXO en un banco del canal en un Carrier Access
Corporation (CAC), tiene estados de comienzo de señalización de tierra no estándar
(A=bajo, B=bajo). Puede configurar los drivers para usar este estado removiendo la
etiqueta de la siguiente línea:
/* #define CONFIG_CAC_GROUNDSTART */

Pasar parámetros de módulo para configurar Zaptel

Algunas de las opciones Zaptel pueden ser habilitadas cuando el módulo se carga,
pasando parámetros de módulo al driver wctdm. Se puede listar todos estos parámetros
al tiempo de cargar el módulo (de forma opuesta que lo realizado cambiando éstos en
el archivo zconfig.h) con el comando modinfo:

#modinfo -p wctdm
debug int
loopcurrent int
robust int
_opermode int
opermode string
timingonly int
lowpower int
boostringer int
fxshonormode int

Luego pasar los parámetros de módulo al comando modprobe. Por ejemplo, se puede
utilizar lo siguiente para activar el parámetro boostringer cuando el módulo se carga,
a pesar de la definición estática usada en el archivo zconfig.h:
#modprobe wctdm boostringer=1
Otro parámetro común para pasar a un módulo es opermode. Pasando éste al driver
wctdm, se puede configurar la TDM400P para un mejor rendimiento en la impedancia
de las líneas de un país.

2.12.11. Compilando libpri

Compilar e instalar libpri sigue el mismo patrón que lo antes descrito para zaptel. Libpri
es utilizada por varios hardwares TDM, pero aunque no se tenga el hardware instalado
es recomendable compilar e instalar esta librería. Se debe compilar e instalar la librería
libpri antes que Asterisk. Aquí los comandos:

# cd /usr/src/libpri-version
# make clean
# make
# make install
2.12 Instalando Asterisk 74

2.12.12. Compilando Asterisk

Con los paquetes zaptel y libpri compilados e instalados, podemos centrarnos en As-
terisk. Se verá la instalación estándar y algunos argumentos alternativos del make.
También se verá como se puede editar el Makefile para optimizar la compilación de
Asterisk.

Instalación estándar

Asterisk esta compilado con gz a través del programa make. Para comenzar a compilar
Asterisk, hay que ejecutar las siguientes líneas de código:

# cd /usr/src/asterisk-version
# make clean
# make
# make install
# make simples

Se realiza el comando make samples para instalar los archivos de configuración por de-
fecto. Una vez más, si se utiliza un sistema que hace uso de los directorios /etc./rc.d/init.d
o /etc./init.d, deberá correr también el comando make config. Esto instala los
scripts de arranque y configura el sistema para ejecutar Asterisk automáticamente al
iniciar.

Argumentos alternativos de make

Hay muchos otros argumentos de make que se pueden pasar para compilar. Mientras
algunos los veremos a continuación, el resto se utilizan internamente en el archivo y
realmente no tienen utilidad para el usuario final.
Veamos algunos argumentos útiles de make.
Make clean
Se utiliza para borrar los binarios compilados del directorio fuente. Debe correrse este
comando antes de que se recompile o, si no hay espacio.
Make update
Se utiliza para actualizar el código existente del servidor CVS de Digium. Si se bajó el
código fuente de un servidor FTP se recibirá un mensaje de error.
Make upgrade
Si corre el comando make install para instalar Asterisk después de usar make update
para actualizar desde el CVS, el archivo .version no será actualizado. Si no quiere
borrar manualmente el archivo .version antes de correr make y make install, puede
usar el comando make upgrade en su lugar.
Make webvmail
El script de Asterisk WEB Voicemail se utiliza para darle una interfaz gráfica a la cuenta
de correo de voz, permitiéndole administrar y manejar, interactuando remotamente a
través de un navegador WEB, su correo de voz.
2.12 Instalando Asterisk 75

Cuando se corre el comando make webvmail, el script de Asterisk WEB Voicemail será
establecido dentro del directorio cgi-bin/ del demonio HiperText T Protocol (HTTP).
Si tiene políticas de seguridad especificas, tenga cuidado que esto utiliza un script
setuid root en Perl. Este comando instalará solo en distribuciones Red Hat y Fedora,
dado que otras distribuciones tienen diferentes caminos al directorio cgi-bin/. (Esto
por supuesto puede ser cambiado editando el Makefile.)
Make progdocs
Este comando crea documentación utilizando el software doxygen de comentarios pues-
tos junto con el código fuente por los desarrolladores. Debe tener correctamente insta-
lado el software doxygen en su sistema para que esto funcione.
Make mpg123
Asterisk utiliza el programa mpg123 para el stream Moving Picture Experts Group
Audio Layer 3 Encoding Standard (MP3) durante el uso de Music On Hold (MOH).
Debido a que Asterisk solo funciona con mpg123 v0.59r, este comando determina si
hay instalada una correcta versión del mpg123 en el sistema, y si no, intentará bajarla,
extraerla, y compilarla de forma automática. Tener cuidado que nuevas versiones no
funcionan, y muchas distribuciones tienen links simbólicos a mpg321 y mpg123 que
son diferentes programas. Si se ejecuta make install después de correr éste comando,
Asterisk detectará el directorio y lo instalará.
Make config
El comando make config instalará un script de inicialización Red Hat, si los directorios
/etc./rc.d/init.d o /etc./init.d existen. Si no existen, los scripts son instalados
con el permiso igual a 755. Si el script detecta que existe /etc./rc.d/init.d/, el
comando chkconfig -add asterisk debe correrse para que Asterisk se inicie automá-
ticamente cuando se reinicia el sistema.
Este script es realmente útil en sistemas basados en distribuciones Red Hat, aunque
los script de inicialización están disponibles en otras distribuciones en el directorio
./contrib./init.d/ del directorio fuente de Asterisk.

Editando el Makefile

Al principio del Makefile que viene en el directorio fuente de Asterisk hay varias op-
ciones para optimizar la forma de compilar Asterisk. Puede activar la optimización
de codec (GSM) (con el uso de instrucciones MMX), desactivar reescribir archivos
de configuración, agregar información de depuración extra, cambiar los directorios de
instalación y montaje de Asterisk, y modificar el tipo de procesador en donde se com-
pilara Asterisk. A pesar que nunca editará o cambiará cualquiera de estas opciones, se
mencionan para completar la configuración.
Activar optimizaciones GSM
Para activar la optimización GSM, descomentar la siguiente línea en el archivo Makefile
de su Asterisk en una arquitectura x86 CPU que soporte instrucciones MMX:
#K6OPT = -DK6OPT
Esto incluye los nuevos procesadores Pentium, Pentium Pro, y los AMD K6 y K7, sin
embargo, no debe activar el soporte MMX a menos que tenga un procesador INTEL
original, muchos problemas han sido reportados en procesadores no INTEL que utilizan
las instrucciones MMX.
2.12 Instalando Asterisk 76

Desactivando sobre escritura de archivos de configuración

Por defecto, Asterisk sobrescribe los archivos de configuración si corre mas de una ves
make samples. Para cambiar esto, cambie la y en la línea de abajo por una n:
OVERWRITE=y
Activar información de depuración
Los símbolos de depuración permiten hacer depuraciones simbólicas. La bandera de
información de perfil -pg produce un archivo cuando se corre Asterisk que puede ser-
vir para obtener información sobre cuanto (relativamente) dedica Asterisk para cada
función. El uso de la bandera -pg no es recomendable para una aplicación común, pero
puede ser de suma utilidad para desarrolladores. Para activarlo, reemplazar el -g en la
siguiente línea por -pg:
DEBUG=-g
Especificando donde instalar Asterisk después de compilarlo
Puede cambiar el directorio donde instala Asterisk especificando un camino en la si-
guiente línea:
INSTALL_PREFIX=
Cambiando el directorio de staging
El directorio de staging es donde Asterisk copia temporalmente sus archivos durante el
proceso de instalación. Para especificar un directorio, ingresar el mismo en la siguiente
línea:
DESTDIR=

2.12.13. Usando binarios precompilados

Hay distribuciones de Linux (como Debian) que incluyen binarios precompilados. Para
lograr instalar Asterisk puede utilizar el manejador de paquetes que éstas distribuciones
de Linux proveen (como es apt-get de Debian y portage de Gentoo). Sin embargo se
puede encontrar que muchos de estos binarios precompilados están un poco desactua-
lizados y no siguen el ciclo de desarrollo como Asterisk.
El uso de binarios precompilados no ahorra mucho tiempo, y se encuentra que compilar
Asterisk con cada uno de sus instaladores no es mucho mas complicado que con los
binarios precompilados. Creemos que la mejor manera de instalar Asterisk es compilar
del código fuente.

2.12.14. Instalando adicionales

El paquete de asterisk-sounds contiene muchas grabaciones profesionales de gran uti-
lidad. Es altamente recomendado que se instale este paquete, ya que luego se utilizaran
algunos de éstos sonidos. Para hacer esto, ejecutar el siguiente comando:

# cd /usr/src/asterisk-sounds
# make install
2.12 Instalando Asterisk 77

2.12.15. Otros plugins de utilidad

El paquete asterisk-addons contiene código que permite almacenar el detalle de las
llamadas Call Detail Recorder (CDR) dentro de una base de datos My Structured
Query Language (MySQL) y en MP3 nativo, también como un interprete para cargar
código Perl en la memoria para la vida de un proceso Asterisk. Los programas están
en asterisk-addons donde puede encontrar allí permisos de licencia para prevenir que
éstos sean mal implementados directamente en el código fuente de Asterisk.

2.12.16. Actualizando su código fuente

En lugar de borrar las fuentes y bajar nuevamente el árbol entero cada vez que se
desea actualizar Asterisk, se puede actualizar solamente los archivos que han cambiado
desde la última versión. Para hacer esto, situarse dentro del directorio que contiene los
archivos que se desean actualizar y ejecutar make update:

# cd /usr/src/asterisk
# make update
# make clean
# make upgrade

2.12.17. Cuestiones comunes cuando se compila

En esta sección hay una breve reseña de algunos de los muchos problemas que se
presentan a la hora de compilar Asterisk, y como resolverlos.

Asterisk

El compilador de C no crea los archivos ejecutables

Si se recibe el siguiente error mientras se trata de compilar Asterisk, se debe instalar
el compilador gcc y sus dependencias:
Checking whether the C compiler (gcc) Works no
Configure: error: installation or configuration problem:
C compiler cannot create executables.
Make: *** [editline/libedit.a] Error 1
Los siguientes paquetes se requieren para gcc:
Gcc
Glibc-kerheaders
Cpp
Binutils
Glibc-headers
Glibc-devel
2.12 Instalando Asterisk 78

Se puede instalar a mano, copiando los archivos del cd de instalación de la distribución,

o a través del manejador de paquetes yum, con el comando yum install gcc.
Bison: comando no encontrado
El siguiente error se puede encontrar si el analizador de sintaxis bison, que se requiere
para analizar expresiones en el archivo extensions.conf, no se encuentra:

Bison ast_expr.y -name-prefix=ast_yy -o ast_expr.c

Make: bison: Command not found
make: *** [ast_expr.c] Error 127

Para instalar en orden Asterisk se requieren los siguientes archivos; se pueden instalar
con el comando yum install bison:
bison
M4
/usr/bin/ld: cannot find -lssl
El paquete de desarrollo OpenSSL se requiere para Asterisk con el módulo res_crypto.so
para el chequeo de las llaves Rivest, Shamir, Adleman Algorithm (RSA) realizado por
el protocolo Inter-Asterisk eXchange Version 2 (IAX2). Si el paquete de desarrollo
OpenSSL no está instalado, aparece el siguiente error:

/usr/bin/ld: cannot find -lssl

collect2: ld returned 1 exit status
make: *** [asterisk] Error 1

Para instalar la librería de desarrollo OpenSSL, se requieren las siguientes dependencias:

Openssl_devel
E2fsprogs-devel
Zlib-devel
Krb5-devel
Krb5-libs

Puede utilizar el comando yum install openssl-devel para instalar estos archivos.

Zaptel

make: cc: Command not found

Se recibirá el siguiente error si se trata de crear Zaptel sin el compilador gcc instalado:

Make: cc: Command not found

Make: *** [gendigits.o] Error 127

Asegurarse de instalar el gcc y sus dependencias.

FATAL: Module wctdm/fxs/fxo not found
Las tarjetas TDM400P requieren del bus PCI version 2.2. Si se intenta cargar los drivers
telefónicos Zapata con una vieja versión, se encontraran los siguientes errores:
2.12 Instalando Asterisk 79

1) Cuando intente cargar el driver wctdm, se verá con un error como el siguiente:
Fatal: Module wctdm not found
2) Cuando intente cargar el driver wctdm o wcfxo, se verá un error como el siguiente:
ZT_CHANCONFIG failed on channel 1: No Such device or ardes (6)
FATAL: Module wctdm not found
La única forma de resolver este problema es utilizando nuevos motherboards que so-
porten PCI Versión 2.2.

2.12.18. Cargando los módulos Zaptel

Se verá como cargar los módulos zaptel y ztdummy. El módulo zaptel no requiere de
ninguna configuración si éste va a ser utilizado por el módulo ztdummy.

2.12.19. Sistemas corriendo udevd

En los primeros días de Linux, el directorio del sistema /dev/ fue muy popular con su
lista de dispositivos con los cuales el sistema podía interactuar. En la actualidad, cerca
de 18,000 dispositivos se encuentran listados. Todo esto cambió cuando se lanzo devfs,
permitiendo la creación dinámica de dispositivos que se activan con el sistema. Algunas
de las actualizaciones en las recientes distribuciones tienen incorporado el demonio udev
en el sistema para poblar /dev/ con nodos del dispositivo.
Para permitir que Zaptel y otros drivers de los dispositivos puedan acceder al hardware
PCI instalado en el sistema, se deben agregar ciertas reglas. Usando su editor favorito,
abra el archivo de las reglas udevd. En Fedora Core 3, por ejemplo, se encuentra en
/etc./udev/rules.d/50-udev.rules. Agregar las siguientes líneas al final del archivo:

# Section for zaptel device

KERNEL="zapctl",NAME="zap/ct1"
KERNEL="zaptimer",NAME="zap/timer"
KERNEL="zapchannel",NAME="zap/channel"
KERNEL="zappseudo",NAME="zap/pseudo"
KERNEL="zap[0-9]*",NAME="zap/en"

Guardar el archivo y reiniciar el sistema para que los cambios tengan efecto.

2.12.20. Cargando Zaptel

El módulo Zaptel debe cargarse después de que cualquier otro módulo se cargue y se
use.
Notar que si se utilizara el módulo zaptel con hardware PCI, se debe configurar
/etc./zaptel.conf antes de cargarse. (Se discutirá como configurar zaptel.conf para
usarlo con hardware mas adelante). Si se utiliza zaptel solo para acceder a ztdummy, se
puede cargar con el comando modprobe, como sigue:
# modprobe zaptel
No se debería ver ninguna salida, si se ejecutó correctamente. Para verificar que el
módulo zaptel se cargo correctamente, use el comando lsmod. Se debería ver en pantalla
una línea que muestre el módulo zaptel y la cantidad de memoria que éste utiliza:
2.12 Instalando Asterisk 80

# lsmod | Grep zaptel

zaptel 201988 0

2.12.21. Cargando ztdummy

El módulo ztdummy es una interfaz a un dispositivo que provee tiempo, el cual permite
a Asterisk facilitarle tiempos a varias aplicaciones y funciones que lo requieren. Usar el
comando modprobe para cargar ztdummy después de haber cargado zaptel:
# modprobe ztdummy
Si se carga correctamente, no hay salida en pantalla. Una vez más, para verificar si se
cargó correctamente utilizar:

# lsmod | Grep ztdummy

Module Size Used by
Ztdummy 3796 0
Zaptel 201988 1 ztdummy

2.12.22. Cargando libpri

Las librerías libpri no necesitan cargarse como módulos. Asterisk busca libpri cuando
se compila y las configura para usarlas como librerías si las encuentra.

2.12.23. Cargando Asterisk

Se puede cargar Asterisk de muchas maneras. La manera más fácil de ejecutar Aste-
risk es corriendo el archivo binario directamente de la consola de Linux. Si se utiliza
un sistema que usa los scripts de init.d, puede simplificar arrancar y rearrancar As-
terisk. Sin embargo, la forma preferida de ejecutar Asterisk es por medio del script
safe_asterisk.

2.12.24. Comandos CLI

El archivo binario de Asterisk se encuentra por defecto en
/usr/sbin/asterisk. Si se ejecuta /usr/sbin/asterisk, éste se cargara como un
demonio. Hay algunos pocos comandos que se deben tener en cuenta ya que le permiten
conectar/reconectar al CLI de Asterisk, establecer el tipo de salida del CLI, y permitir
verificar cosas si Asterisk colapsa (para depurar con gdb).
Para explorar el rango completo de opciones, ejecutar Asterisk con -h:
# /usr/sbin/asterisk -h
Acá hay algunas de las opciones más comunes:
-c
Console. Le permite conectarse al CLI Asterisk
-v
Verbosity. Se utiliza para establecer la cantidad de salida para depurar CLI.
-r
2.12 Instalando Asterisk 81

Remote. Esto se utiliza para reconectar remotamente a un proceso de Asterisk corriendo

actualmente.
Veamos algunos ejemplos:
Para ejecutar Asterisk y conectarlo al CLI con un verbosity de nivel 3, se utiliza:
#/usr/src/asterisk -cvvv
Si se esta ejecutando actualmente Asterisk, se puede utilizar la opción de reconexión
como sigue:
#/usr/src/asterisk -vvvr

2.12.25. Script de inicialización de Red Hat

Si se corrió el comando make config antes, se puede conectar y reconectar Asterisk con
los siguientes comandos:
# /etc/rc.d/init.d/asterisk start
# /etc/rc.d/init.d/asterisk stop

2.12.26. Directorios utilizados por Asterisk

Asterisk usa muchos de los directorios del sistema Linux para manejar varios aspectos
de sistema, como grabaciones de voicemail, archivos de configuración, etc.
A continuación veremos los directorios necesarios, los cuales se crean durante la insta-
lación y se configuran en el archivo asterisk.conf.
/etc./asterisk/
El directorio /etc./asterisk contiene los archivos de configuración de Asterisk. Un
archivo sin embargo, zaptel.conf, está en el directorio /etc./.
El hardware Zaptel fue originalmente desarrollado por Jim Dixon del Grupo de Tele-
fonía Zapata como una forma de vincular de manera razonable y asequible los equipos
de computación telefónicos al mundo. Asterisk hace uso de este hardware, pero cual-
quier otro software puede también utilizar los drivers y hardware Zaptel. Consecuen-
temente, el archivo de configuración zaptel.conf no está directamente en el directorio
/etc./asterisk/.
/usr/lib/asterisk/modules/
El directorio /usr/lib/asterisk/modules contiene todos los módulos cargables de
Asterisk. En este mismo directorio también hay varias aplicaciones, codecs, formatos
y canales utilizados por Asterisk. Por defecto, Asterisk carga todos estos módulos al
iniciarse. Se puede desactivar cualquier módulo que no se esta utilizando en el archivo
modules.conf, pero tenga cuidado que algunos módulos son requeridos por Asterisk
así como algunas de sus dependencias.
/var/lib/asterisk
El directorio /var/lib/asterisk contiene el archivo astdb y varios subdirectorios. El
archivo astdb contiene la información de la base de datos local de Asterisk, que es algo
así como el Registro de Microsoft Windows. La base de datos Asterisk es una simple
implementación basada en v1 de la base de datos de Berkeley.
Los subdirectorios que /var/lib/asterisk incluye son:
2.12 Instalando Asterisk 82

agi-bin/ : contiene sus scripts customizados, que pueden interactuar con Asterisk a
través de las muchas aplicaciones (AGI).
firmware/ : contiene el firmware de varios dispositivos compatibles con Asterisk.
images/ : las aplicaciones que se comunican con canales que soportan imágenes graficas
buscan en el directorio /images. Muchos de los canales no soportan la transmisión de
imágenes, por lo que raramente se utiliza este directorio. Sin embargo, si se agregan
otros dispositivos que soportan y hacen uso de imágenes graficas, este directorio será
más relevante.
keys/ : asterisk puede utilizar llaves publicas/privadas para autenticar conexiones hacia
adentro por medio de la firma digital RSA. Si se establece una llave pública para una
conexión en el directorio /keys, esa conexión será autenticada por canales que sopor-
ten este método (como los canales IAX2). Las llaves privadas nunca se distribuyen al
público. Lo contrario es verdadero: se puede distribuir su llave pública a sus conexiones
permitiéndole ser autenticado con el uso de su llave privada. Ambas llaves (terminan
con extensiones de archivo .pub y .key para la llave publica y privada respectivamente)
están en el directorio /keys.
mohmp3/ : cuando configura Asterisk para MOH, las aplicaciones utilizan este directorio
para buscar por sus archivos MP3. Asterisk es un poco exigente en cuanto a como están
formateados los archivos MP3, se debe usar una Constant Bit Rate (CBR) codificando
y muestreando los tags ID3 de sus archivos.
sounds/ : todas las voces por defecto para Asterisk están en /sounds. Los contenidos
básicos que vienen con Asterisk por defecto están en sounds.txt.
/var/spool/asterisk
El directorio spool de Asterisk contiene varios subdirectorios, incluyendo outgoing/,
qcall/,tmp/ y voicemail/. Asterisk monitorea los directorios qcall y outgoing
en busca de archivos de texto que contienen pedidos de información. Estos archivos
permiten al usuario generar una simple llamada copiando o moviendo el archivo de
estructura correcto dentro del directorio outgoing/.
El viejo método qcall generaba llamadas utilizando una simple línea de texto con
el archivo de llamada. Los archivos de llamada para usarlos con el directorio qcall
tomaban la siguiente forma:
Dialstring CAller-ID Extensión Maxsecs [Identifier] [Required-response]
Esto limitaba un poco lo que se podía hacer con el archivo de llamada, y que tipo de
información se podía pasar a Asterisk. De este modo, un nuevo método se desarrolló
en Asterisk usando el directorio outgoing. Los archivos de llamada que estén en este
directorio pueden contener mucha mas información, como ser un contexto, extensiones,
y prioridades donde la llamada debe comenzar, o simplemente una aplicación y sus
argumentos.
Todos los voicemail y saludos de usuarios están en el directorio voicemail/. Extensiones
configuradas en voicemail.conf que tiene que haber sido logeadas por lo menos una
vez se crean como subdirectorio de voicemail/.
/var/run/
Este directorio contiene la información de procesos ID (pid) para todos los procesos
activos en el sistema, incluyendo Asterisk.
/var/log/asterisk
2.12 Instalando Asterisk 83

Fig. 2.5: Niveles del directorio de /var.

Acá se guarda la información de logs. Se puede controlar el tipo de información a ser

guardada por los archivos editando logger.conf situada en el directorio /etc./asterisk.

2.12.27. Usuarios, Pares y Amigos

No debería causar ninguna sorpresa que Asterisk ame hablar VoIP. Pero con fin de
hacerlo así, Asterisk tiene que saber que función debe realizar: cliente, servidor, o ambos.
Las conexiones que se autentificarán, o que autentificaremos, están definidas en los
archivos iax.conf y sip.conf como usuarios y pares. Las conexiones que realicen
ambas funciones pueden ser definidas como amigos. Es siempre importante ver desdel
punto de vista de Asterisk la dirección de los canales, ya que las conexiones están siendo
aceptadas y creadas por el servidor de Asterisk.

Usuarios

Una conexión definida como usuario es cualquier sistema/usuario/punto-extremo que

permitimos conectarse a nosotros. Hay que tener presente que una definición de usuario
no provee un método de para llamar a aquel usuario; el tipo user es usado simplemente
para crear un canal para llamadas entrantes. La definición de un usuario requerirá
que sea definido un contexto para indicar donde la llamada entrante certificada será
colocada en el dial plan (en extensions.conf).
2.12 Instalando Asterisk 84

Fig. 2.6: Flujo del control de autenticación con relación a Asterisk.

Pares

Una conexión definida como par (peer) es una conexión saliente. Los usuarios llaman
al sistema, mientras que los pares hacen que el sistema llame. Ya que los pares no nos
llaman, una definición de peer no requiere la configuración típica de un contexto. Sin
embargo, hay una excepción: si las llamadas que provienen del sistema son devueltas
al mismo mediante un bucle de retorno, las llamadas entrantes (que provienen de un
Proxy SIP, no de un usuario agente) serán correspondidas con la definición de par. El
contexto por defecto debería manejar estas llamadas entrantes apropiadamente, aunque
sea preferible para los contextos que sean definidos en base a un peer.
A fin de saber donde enviar una llamada a un anfitrión, debemos saber su posición en
relación con Internet (es decir su dirección de IP). La posición de un par puede ser defini-
da estáticamente o dinámicamente. Un par dinámico es configurado con host=dynamic
bajo el título de definición de par. Como la dirección de IP de un par dinámico puede
cambiar constantemente, este debe registrarse con Asterisk para avisarle su dirección
IP y entonces enrutar las llamadas con éxito. Si el punto remoto es otro Asterisk, el
uso de una declaración de registro es requerido, como se explicará más adelante.

Amigos

Un amigo es un término para definir tanto un usuario como un par. Sin embargo, las
uniones que son tanto usuario como par no siempre son definidas de esta forma, porque
definir cada dirección de llamada individualmente (usando tanto un usuario como par)
permite más granularidad y el control de las conexiones individuales.
2.13 Configuración inicial de Asterisk 85

2.12.28. Declaraciones de registro

Una declaración de registro es un modo de decirle a un par remoto donde está Asterisk
con relación a Internet. Asterisk usa declaraciones de registro para autentificarse con
proveedores remotos cuando se emplea una dirección IP dinámica, o cuando el proveedor
no tiene su dirección IP en el registro. Hay situaciones en que una declaración de registro
no es necesaria, pero para mostrar cuando se requiere una, vamos a ver un ejemplo.
Supongamos que se tiene a un par remoto que nos provee servicios de 0800. Cuando
alguien llama al número +0-800-555-1212, la llamada pasa de la red PSTN física al pro-
veedor de servicio y entra en su servidor Asterisk, posiblemente mediante una conexión
T1. Esta llamada es enrutada entonces a nuestro servidor Asterisk vía Internet.
El proveedor del servicio tendrá en su archivo de configuración sip.conf o iax.conf
una definición para nuestro servidor Asterisk. Si se reciben llamadas sólo de este provee-
dor, el mismo será definido como usuario (si ellos fueran otro sistema Asterisk, nosotros
seríamos definidos en su sistema como un par).
Ahora supongamos que nuestro sistema está conectado a Internet de casa, con una
dirección IP dinámica. El proveedor de servicio tiene una dirección de IP estática, que
colocamos en nuestro archivo de configuración. Ya que se tiene una dirección dinámica,
el proveedor de servicio especifica host=dynamic en su archivo de configuración. A fin
de saber donde rutear la llamada +0-800-555-1212, el proveedor necesita saber donde
estamos localizados con relación a Internet. Aquí es donde la declaración de registro
entra en uso.
La declaración de registro es un modo de certificar y decirle a un par donde se está
ubicado. En la sección [general] de su archivo de configuración, se colocaría una
declaración similar a esta:
register => username:secret@my_remote_peer

2.13. Configuración inicial de Asterisk

El propósito de esta sección es servir de guía inicial en la configuración de 4 canales:
un canal FXO, un FXS, un SIP y un canal IAX.

2.13.1. ¿Qué es realmente necesario?

El asterisco (*) es un símbolo utilizado en muchas aplicaciones y es el nombre perfecto
para esta PBX por varias razones, una de las cuales es la enorme cantidad de interfaces
con las que Asterisk puede conectarse. Entre éstas se incluyen:
Interfaces analógicas, como la de la línea de teléfono
Circuitos digitales, como líneas T1 o E1
Protocolos VoIP, como SIP e IAX
Asterisk no necesita hardware especial (ni siquiera una placa de sonido). Las placas
de canales que conectan Asterisk con teléfonos análogos o líneas de teléfono están
disponibles pero no son imprescindibles. Esto es así, dado que se puede conectar a
Asterisk usando soft-phones (teléfonos basados en software) que están disponibles para
Windows, Linux y otros sistemas operativos sin necesidad de ningún hardware especial.
2.13 Configuración inicial de Asterisk 86

Se puede conectar incluso con cualquier teléfono IP que soporte SIP o IAX2. Por otro
lado, en caso de no conectar la central a una línea telefónica de salida, se pueden cursar
las llamadas por Internet a un proveedor de servicio telefónico.

2.13.2. Trabajando con archivos de configuración de interfaces

Para estas primeras instrucciones se asume que se dispone de un kit Dev-Lite de Digium
(o algún clon similar) con una interfaz FXO y una FXS que permiten conectarse a una
línea telefónica analógica (FXO) o a un teléfono analógico (FXS). En caso de utilizar
solo conexiones IP las anteriores interfaces son innecesarias.
Los archivos sobre los que se trabajará son:

zaptel.conf: aquí se configuran las opciones de bajo nivel de la interfaz de hardware.

Se configuran los canales FXO y FXS.
zapata.conf: en este archivo se configura la interfaz de asterisk con el hardware.
extensions.conf: es donde se arma el dial-plan de Asterisk.
sip.conf: aquí se configura el protocolo SIP.
iax.conf: aquí se configuran los canales de entrada y salida de IAX.

Luego de editar los archivos hay que recargarlos para que los cambios surtan efecto. Lue-
go de editar el archivo zaptel.conf, va a ser necesario ejecutar /sbin/ztcfg -vv (-vv
para salidas de depuración mas completas) para que se actualicen las configuraciones del
hardware. Los cambios hechos en zapata.conf necesitan ejecutar el comando reload
desde la consola de Asterisk, pero si se cambian los métodos de señalización es nece-
sario reiniciar Asterisk (comando restart). Es necesario hacer reload chan_iaz2.so
y reload chan_sip.so luego de editar los archivos iax.conf y sip.conf respectiva-
mente.

2.13.3. Canales FXO y FXS

La diferencia entre un canal FXO y uno FXS es simplemente qué extremo de la conexión
provee el tono de discado. Un puerto FXO no genera tono, acepta uno. Un ejemplo es
el tono provisto por la compañía telefónica. Un puerto FXS provee tanto el tono de
discado como el voltaje necesario para alertar cuando hay una llamada entrante.
Si el servidor Asterisk tiene un puerto compatible FXO, se puede conectar allí la línea
telefónica analógica proveniente de la PSTN (ej. línea que nos da Telecom). Asterisk
puede usar esta línea tanto para recibir como para efectuar llamadas. De la misma
manera, si Asterisk tiene un puerto FXS, se puede conectar un teléfono analógico en
el servidor Asterisk de manera que pueda llamar y conectar llamadas por el teléfono
analógico conectado.
Los puertos están definidos en la configuración por la señalización que usan de manera
opuesta a lo que son físicamente. Por ejemplo, un puerto físico FXO estará definido en
la configuración con señalización FXS y un puerto físico FXS estará con señalización
FXO. Esto que puede parecer confuso tiene sus motivos. Las placas FXO o FXS no
están denominadas por lo que son sino por lo que se les conecta. Una tarjeta FXS va
conectada a una terminal. Siendo así debe comportarse como una Central Office (CO)
y proveer señalización FXO. Similarmente una placa FXO se conecta a una CO, por lo
2.13 Configuración inicial de Asterisk 87

que necesita comportarse como una Terminal y usar señalización FXS. El MODEM en
la computadora es un ejemplo de un componente FXO.

Configurando un canal FXO

Configuración del Hardware Zaptel

El archivo zaptel.conf ubicado en /etc/ es usado para configurar el hardware. La
siguiente configuración mínima define un puerto FXO con señalización FXS:

fxsks=2
loadzone=us
defaultzone=us

La primera línea además de indicar si usamos señalización FXS o FXO especifica uno
de los siguientes protocolos para el canal 2:

Loop Start (ls)

Ground Start (gs)
Kewlstart (ks)

La diferencia entre loop-start y ground-start tiene que ver con la manera en que el
equipo solicita tono de discado: con ground-start, solicita al extremo lejano el tono de
discado llevando momentáneamente a tierra uno de los hilos. El modo loop-start usa
un corto en la línea para pedir tono. Kewlstart es igual que loop-start pero posee
mayor inteligencia y es mejor para detectar desconexión del extremo lejano. El modo
Kewlstart es preferido para señalizar circuitos analógicos en Asterisk.
Para usar otro método que no sea el Kewlstart hay que reemplazar en fxsks la ter-
minación ks por gs o ls, para loop o ground start respectivamente.
loadzone configura el conjunto de indicadores para señalizar el canal. El archivo
zonedata.c contiene información acerca de todas las variaciones de sonido que un
sistema telefónico puede tener para los distintos países: tono de discado, ciclos de lla-
mada, tono de ocupado, etc. Se pueden configurar de manera independiente para cada
canal. defaultzone se usa en caso que no se especifique ninguna zona para un canal
dado.
Luego de configurar zaptel.conf se pueden cargar los drivers para la tarjeta. modprobe
se usa para cargar módulos del kernel de Linux. Por ejemplo para cargar el driver wctdm
se ejecuta:
# modprobe wctdm
Si el comando se ejecuta sin salida entonces se cargó de manera exitosa. Se puede
verificar que el hardware y los puertos se hayan cargado correctamente con el uso de
ztcfg:
#/sbin/ztcfg -vv
Aparecerán los canales que están configurados con sus respectivos métodos de señali-
zación:
2.13 Configuración inicial de Asterisk 88

Zaptel Configuration
======================
Channel map:
Channel 02: FXS Kewlstart (Default) (Slaves: 02)
1 channels configured.

Si en lugar de lo anterior aparece algo como:

ZT_CHANCONFIG failed on channel 2: Invalid argument (22)

Did you forget that FXS interfaces are configured with FXO signalling
and that FXO interfaces use FXS signalling?

Es debido a que se ha configurado el canal con una señalización equivocada.

Para descargar drivers de la memoria se utiliza el comando rmmod de Linux:
#rmmod wctdm
El programa zttool es una aplicación para diagnóstico que determina el estado del
hardware del equipo. Luego de ejecutarlo se presentará un menú con todo el hard ins-
talado. Se puede seleccionar cada elemento y observar el estado en el que se encuentra
en el momento. Si dice OK significa que el hardware está instalado y cargado correc-
tamente, como por ejemplo:

Alarms Span
OK Wildcard TDM400P REV E/F Board 1

Configuración del hardware Zapata

Asterisk usa el archivo zapata.conf para determinar la configuración del hardware
de telefonía instalado en el sistema. El archivo zapata.conf también controla las fun-
ciones asociadas con los canales del hardware, como ser: caller ID, call waiting, echo
cancellation y muchas otras opciones.
Cuando se configura el archivo zaptel.conf y se cargan los módulos, Asterisk no
se entera de nada de lo que se ha configurado. El hardware no necesita ser usado
por Asterisk, puede perfectamente ser usado por otra pieza del software, que hace de
interfaz con los módulos de Zaptel. Se le informa a Asterisk sobre el hardware y sobre
el control de las opciones asociadas a través del archivo zapata.conf:

[trunkgroups]
; define any trunk groups
[channels]
; hardware channels
; default
usecallerid=yes
hidecallerid=no
callwaiting=no
threewaycalling=yes
transfer=yes
echocancel=yes
echotraining=yes
; define channels
2.13 Configuración inicial de Asterisk 89

context=incoming ; Incoming calls go to [incoming] in extensions.conf

signalling=fxs_ks ; Use FXS signalling for an FXO channel
channel => 2 ; PSTN attached to port 2

La sección [trunkgroups] es para conexiones NFAS y GR-303. Si se requiere este tipo

de funcionalidad, en el archivo zapata.conf.sample hay más información.
La sección [channels] determina el método de señalización y sus opciones para los
canales del hardware. Una vez que se define una opción, ésta es heredada hacia el resto
del archivo. Un canal se define usando channel =>, cada definición de canal hereda las
opciones definidas hacia arriba de esa línea. Si se desea configurar diferentes opciones
para diferentes canales, éstas deben ser configuradas antes de colocar channel =>.
Con usecallerid=yes se ha activado la función de caller ID, y se especifica que no se
ocultará para llamadas salientes con hidecallerid=no. En una línea FXO se desactiva
la llamada en espera con callwaiting=no. Si se activa el llamado de tres vías con
threewaycalling=yes una llamada activa puede ponerse en espera con el botón flash.
Puede luego discarse a una tercera persona e incorporarla a la conversación. Por defecto
esta función está deshabilitada.
Para permitir la transferencia de llamada, se usa transfer=yes, lo cuál requiere que el
llamado de tres vías (three-way calling) esté activado. La cancelación de eco de asterisk
se usa para quitar el eco que se puede producir en líneas analógicas. El cancelador
de eco, se activa con echocancel=yes. El cancelador de eco requiere cierto tiempo
para aprender el eco, este proceso se puede acelerar activando el entrenamiento de eco
(echotraining=yes). Esto le dice a Asterisk que envíe un tono por la línea al comienzo
de la llamada para medir el eco, y por lo tanto aprenderlo más rápidamente.
Cuando una llamada ingresa por un interfaz FXO, se puede realizar algún tipo de
acción, la cuál se configura en un bloque de instrucciones llamado context. Las llamadas
entrantes en la interfaz FXO se dirigen al contexto incoming con context=incoming,
y las instrucciones a realizar en el contexto, se definen en extensions.conf.
Finalmente, ya que un canal FXO usa señalización FXS se define signalling=fxs_ks.
Configuración del Dial Plan
El siguiente dial plan hace uso de la aplicación Echo() para verificar comunicación
bidireccional en el canal:

[incoming]
;
;llamadas entrantes por el puerto FXO son dirigidas
;a este contexto desde zapata.conf
;
exten => s,1,Answer( )
exten => s,2,Echo( )

Todo lo que se diga va a ser repetido por la aplicación Echo().

Haciendo una llamada
Si se ejecuta la aplicación zttool y se conecta la línea de la PSTN al puerto FXO se
puede observar como cambia la alarma en rojo.
Si desde un teléfono (externo) se disca un número de la central, Asterisk contestará
la llamada ejecutando la aplicación Echo() lo que demuestra que el canal FXO está
andando correctamente.
2.13 Configuración inicial de Asterisk 90

Configuración de un canal FXS

Se procederá de manera similar a la configuración de un canal FXO.

Configuración del Hardware Zaptel
A continuación se muestra una configuración mínima para un canal en una placa
TDM400P. La configuración es idéntica a la del canal FXO pero con el agregado de
fxoks=1.
Recordando que se utiliza la señalización opuesta para canales FXO y FXS, entonces se
configurará señalización FXO para el canal FXS. En el ejemplo siguiente se configura
el canal 1 para usar señalización FXO con el protocolo de señalización kewlstart:

fxoks=1
fxsks=2
loadzone=us
defaultzone=us

Luego de cargar los drivers del hardware se puede verificar el estado usando /sbin/ztcfg -vv:

Zaptel Configuration
======================
Channel map:
Channel 01: FXO Kewlstart (Default) (Slaves: 01)
Channel 02: FXS Kewlstart (Default) (Slaves: 02)
2 channels configured.

Configuración del Hardware Zapata

La siguiente configuración es idéntica a la del canal FXO pero con una sección para
el puerto FXS y una línea que dice inmediate=no. El contexto para el puerto FXS es
internal, la señalización es fxoks (kewlstart) y el canal es 1.
Los canales FXS pueden ser configurados para hacer una o dos acciones diferentes
cuando a un teléfono se le levanta el tubo. La más común es que Asterisk de tono de
discado y espere a que la persona marque un número. Esta alternativa se configura con
inmediate=no. La otra opción es que Asterisk haga automáticamente un conjunto de
acciones configuradas en el dial plan en lugar de dar tono de discado, lo que se configura
como inmediate=yes. Las instrucciones a ser ejecutadas se encuentran en el contexto
del canal y deben coincidir con la extensión s.
El siguiente es el archivo zapata.conf para el ejemplo:

[trunkgroups]
; define trunk groups
[channels]
; canales de hardware
; default
usecallerid=yes
hidecallerid=no
callwaiting=no
threewaycalling=yes
transfer=yes
2.13 Configuración inicial de Asterisk 91

echocancel=yes
echotraining=yes
immediate=no
; define canales
context=internal ; Usa el contexto [internal] en extensions.conf
signalling=fxo_ks ; Usa señalización FXO para un canal FXS
channel => 1 ; Teléfono colocado en puerto 1
context=incoming ;llamadas entrantes van a [incoming] en extensions.conf
signalling=fxs_ks ; Usa señalización FXS para un canal FXO
channel => 2 ; PSTN conectada al Puerto 2

Configuración del Dial Plan

Para probar la extensión Zap hacé falta crear un dial plan básico. El siguiente Dial
Plan contiene un contexto llamado internal. Éste es el mismo nombre de contexto
que configuramos en el archivo zapata.conf para el canal 1. Cuando configuramos
context=internal en el archivo zapata.conf, le decimos a Asterisk donde buscar las
instrucciones cuando el usuario ingresa dígitos por su teléfono. En este caso, el único
número de interno que funciona es el 611. Cuando es discado el número anterior en el
teléfono, Asterisk ejecutará la aplicación Echo(), permitiendo verificar la comunicación
bidireccional.
El dial plan tiene el siguiente contenido:

[internal]
exten => 611,1,Answer( )
exten => 611,2,Echo( )

2.13.4. Configurando SIP

SIP comúnmente usado en teléfonos VoIP, se encarga del establecimiento y liberación
de llamadas junto con las renegociaciones durante llamadas. Básicamente ayuda a los
puntos extremos a hablarse mutuamente y de ser posible de manera directa. SIP no se
encarga de transportar datos multimedia, para ello hace uso del RTP una vez que la
llamada se ha establecido.

SIP y RTP

SIP es un protocolo de capa de aplicación que usa un puerto bien conocido, 5060, para
las comunicaciones. SIP puede ser transportado por los protocolos por User Datagram
Protocol (UDP) o Transmission Control Protocol (TCP). Asterisk no maneja la im-
plementación de TCP para transportar los mensajes SIP, pero es posible que futuras
versiones lo soporten. SIP se utiliza para establecer, modificar y terminar las sesiones
multimedia tales como llamadas telefónicas. SIP no transporta datos multimedia entre
los puntos finales.
RTP se usa para transportar datos multimedia (ej. voz) entre los puntos finales. RTP
usa números altos para sus puertos que van del 10000 al 20000 por defecto en Asterisk.
Una topología frecuente para ilustrar SIP y RTP, comúnmente conocida como el tra-
pezoide SIP es la que se muestra en la figura 2.7. Cuando un punto quiere comunicarse
con el otro, primero contacta su servidor Proxy y éste último trata de contactar al
2.13 Configuración inicial de Asterisk 92

Fig. 2.7: Trapezoide SIP-RTP

usuario destino. Una vez que los teléfonos comienzan la llamada se comunican de ser
posible de manera directa uno con el otro, de tal forma que los datos no tienen que ser
cursados por los Proxy.
Hay otros protocolos de VoIP tales como H.323, MGCP, IAX y otros, pero SIP parece
ser el que está en apogeo. La ventaja de SIP reside en su amplia aceptación y flexibilidad
(y tradicionalmente en su simpleza).

Configuración de SIP

El siguiente es un archivo básico de configuración sip.conf:

[general]
context=default
srvlookup=yes
[john]
type=friend
secret=welcome
qualify=yes ; par calificado si no está a mas de 2000ms de distancia
nat=no ; Este teléfono no está detrás de un NAT
host=dynamic ; Este dispositivo se registra con nosotros
canreinvite=no ; Asterisk por defecto trata de redireccionar
context=internal ; El contexto internal controla lo que se puede hacer

El archive sip.conf comienza con la sección [general], que contiene las configuracio-
nes de canal y las opciones por defecto para todos los usuarios (users) y pares (peers)
definidos en sip.conf. Se puede redefinir las configuraciones por defecto de manera
individual para cada usuario/par en la sección de definición respectiva.
Los registros del servicio de sistema de nombre de dominio (Domain Name System
Service, DNS SRV records) son una manera de establecer una dirección lógica y reso-
luble del lugar en el que se puede ser alcanzado. Esto permite que las llamadas sean
direccionadas a diferentes ubicaciones sin la necesidad de hacer cambios en direcciones
lógicas.
Usando registros SRV se logra muchas de las ventajas de los DNS, mientras que des-
habilitándose esta opción se quebranta la Request for Comment (RFC) de SIP y se
2.13 Configuración inicial de Asterisk 93

elimina la capacidad de hacer llamadas SIP basadas en nombres de dominio.(Notar que

para el caso que existan múltiples registros Asterisk usará el primero).
Las búsquedas de registro de DNS SRV están deshabilitadas en Asterisk por defecto,
pero es recomendado que se las active. Para esto se usa srvlookup=yes en la sección
[general] de sip.conf.
Cada conexión se define como user, peer o friend (usuario, par o amigo). El tipo user
se usa para autenticar llamadas entrantes, el tipo peer se usa para llamadas salientes y
el friend se usa para ambas. El nombre de la extensión se define con corchetes ([]). En
este caso definimos la extensión john como un friend.
Un secret es una contraseña para la autenticación. En este caso se definió como wel-
come. Se puede monitorear la latencia entre el servidor Asterisk y el teléfono con qua-
lify=yes, de esta manera se determina si el dispositivo remoto es alcanzable. Por defecto,
Asterisk considerará una extensión o interno como alcanzable si tiene una latencia me-
nor a 2 segundos. Reemplazando yes por el número de milisegundo en qualify=yes le
decimos a Asterisk el tiempo para determinar a un dispositivo como inalcanzable.
Si un interno está detrás de un dispositivo haciendo Network Address Translation
(NAT), tal como un router o firewall, hay que configurar nat=yes para forzar a Asterisk
a ignorar la información de contacto y usar la dirección de donde los paquetes están
siendo recibidos.
Establecer host=dynamic va a requerir que el interno se registre de manera que Asterisk
sepa como alcanzar cada teléfono. Para limitar a un punto extremo a una sola dirección
IP o a un nombre de dominio plenamente calificado Fully Qualified Domain Name
(FQDN), reemplazar dynamic con el IP o nombre de dominio. Esto sólo limita a donde
se hacen llamadas, ya que el usuario está permitido a hacer llamadas desde donde
sea (asumiendo que se ha autenticado exitosamente). Si se coloca host=static, el
dispositivo no necesita registrarse.
En SIP, las invites (invitaciones) se usan para establecer llamadas y direccionar los
datos. Cualquier invitación emitida luego de la inicial en el mismo diálogo se la de-
nomina como reinvite (re invitación). Por ejemplo, si se supone que dos partes están
intercambiando tráfico, si uno de los clientes es colocado en espera y Asterisk se con-
figura para reproducir MOH, Asterisk va a emitir una invitación al segundo cliente,
diciéndole que redireccione su flujo de datos hacia la PBX. Asterisk entonces puede
enviar la música o un anuncio al cliente que está en espera. El primer cliente entonces
emite un comando de off-hold (salida de espera) en una reinvitación a la PBX, la que
a su vez, emite una reinvitación a la segunda parte pidiendo que redirija su flujo de
datos hacia la primera parte y por lo tanto finaliza la MOH y reconecta los clientes.
Normalmente, cuando dos puntos extremos establecen una llamada, pasan sus datos
directamente entre ellos. Asterisk, generalmente rompe esta regla quedándose en medio
del camino, para escuchar dígitos que sean discados en el teléfono. Esto hace falta
porque si Asterisk no puede determinar la duración de la llamada puede darse una
tarifación incorrecta. Al configurar canreinvite=no se fuerza a Asterisk a quedarse en
el camino del flujo de datos, impidiendo que los mensajes RTP sean intercambiados de
manera directa entre los puntos extremos.
Asterisk no va a emitir una reinvitación en cualquiera de los siguientes casos:
1) Si alguno de los clientes está configurado con canreinvite=no.
2) Si los clientes no pueden ponerse de acuerdo en el conjunto de CODEC necesarios
para hacer la conversión de codecs.
2.13 Configuración inicial de Asterisk 94

Fig. 2.8: Imagen de menú de configuración X-lite V2.0 Lin/Win.

3) Si alguno de los clientes está configurado con nat=yes.

4) Si Asterisk necesita escuchar tonos Dual Tone Multi-Frequency (DTMF) durante
la llamada, para transferencias u otras funcionalidades.
Finalmente, context=internal especifica la ubicación de las instrucciones usadas para
controlar lo que el teléfono puede hacer y qué hacer si ocurre una llamada entrante para
este interno. El nombre de contexto configurado en sip.conf coincide con el nombre
de contexto en extensions.conf el cual contiene las instrucciones.
Si se están configurando un conjunto de clientes con características similares, se puede
colocar comandos bajo el encabezado [general], Asterisk los va a utilizar como opcio-
nes por defecto a no ser que se especifique en el bloque de configuración de cada cliente
una opción distinta.
Configuración del Cliente
Ya que sería imposible explicar todas las posibles configuraciones para la enorme varie-
dad de clientes existentes, se proveerá la explicación para configurar un soft-phone muy
popular. El cliente X-Lite de X-ten, se puede descargar de su sitio http://www.xten.com.
La configuración del cliente es bastante simple. Las partes más importantes son el
usuario y contraseña para la registración, junto con la dirección del servidor Asterisk
contra el cual se registrará. La figura 2.8 muestra una configuración simple del cliente
X-lite.
El campo indicado como display name es lo que luego aparecerá en el Caller ID (iden-
tificador de llamado) El campo username y authorization user se usan para la autenti-
cación junto con el campo de password. El campo domain/realm debería ser el IP o la
2.13 Configuración inicial de Asterisk 95

Fig. 2.9: Imagen del X-lite v3.0 Win.

FQDN del servidor Asterisk. El campo de SIP Proxy es el mismo que se ingresó para
domain/realm con el agregado de :5060 al final (5060 en este caso se refiere al puerto
SIP usado para señalización y debe coincidir con el que se especifica en sip.conf).
Luego de ingresar la información anterior hay que verificar que el campo de enabled
esté colocado en Yes y luego cerrar el menú de configuración. X-lite se registrará con
Asterisk automáticamente. Si no se registra, habrá que reiniciar el cliente. Ya que X-lite
está minimizado a un icono en la barra de tareas (Tray-icon) para cerrar el programa
habrá que hacer clic derecho en el icono y seleccionar Exit, para poder reiniciar la
aplicación.
Al momento de redacción del presente trabajo se lanzó una nueva versión (3.0) del X-lite
para Windows que se muestra en las figuras 2.9 y 2.10. La configuración del sipphone
sigue basándose en los mismos parámetros, aunque se ha reformado el entorno visual.
Configuración del Dial Plan
Muchos teléfonos SIP, tanto versiones soft como hard, son teléfonos multilíneas. Esto
significa que pueden aceptar múltiples llamadas entrantes al mismo tiempo. Siendo
así, para probar el X-lite se puede hacer una llamada a uno mismo para probar el
funcionamiento. Para esto bastará con discar el interno numero 100 en el siguiente
ejemplo, o bien el interno 610 para utilizar la aplicación Echo():

[internal]
exten => 100,1,Dial(SIP/john)
exten => 611,1,Echo( )

2.13.5. Configurando Conexiones entrantes IAX

El protocolo llamado Inter-asterisk Exchange Protocol (IAX), actualmente en su versión
2, es utilizado para comunicación Server a Server. No son tan frecuentes los soft-phones
que soportan IAX, pero está en progreso la difusión de este protocolo. La principal
diferencia entre SIP e IAX es la manera en que el flujo de datos multimedia se transporta
entre los puntos extremos.
2.13 Configuración inicial de Asterisk 96

Fig. 2.10: Imagen de menú de configuración del X-lite v3.0 Win.

Con SIP, el trafico RTP se pasa utilizando diferentes puertos que los usados para
señalización SIP. Por ejemplo, Asterisk recibe la señalización SIP por el puerto 5060 y
el trafico RTP por los puertos 10000 al 20000 por defecto. El protocolo IAX difiere en
que tanto la señalización como el tráfico pasan por el puerto 4569. Un ventaja de este
sistema es que IAX suele ser mejor soportado en topologías que utilizan NAT.
Un user IAX se utiliza para autenticar y manejar llamadas entrantes a la PBX. Para
llamadas salientes de la PBX, Asterisk utiliza un peer IAX configurado en el archivo
iax.conf para autenticarse contra el extremo remoto.
Nota: es posible probar IAX usando el servicio Free World Dial up (FWD). Este es un
sistema de VoIP donde proveedores del servicio permiten conectarse con otros miem-
bros de la red independientemente de la ubicación física, de manera gratuita. Hay más
información al respecto en http://www.fwdnet.net.

Configuración de iax.conf

En el archivo iax.conf las secciones se definen con un nombre encerrado en corche-

tes ([]). Cada archivo iax.conf necesita tener al menos una sección [general]. En
esta sección se definen las características relacionadas al uso del protocolo IAX, como
ser CODEC y aspectos del jitter. Se pueden especificar otras alternativas de manera
individual dentro de las definiciones de user o peer.
La siguiente sección [general] es la opción por defecto en el archivo de configuración
de ejemplo iax.conf.sample:

[general]
bandwidth=low
disallow=lpc10
jitterbuffer=no
2.13 Configuración inicial de Asterisk 97

forcejitterbuffer=no
tos=lowdelay
autokill=yes
register => fwd_number:[email protected]
[iaxfwd]
type=user
context=incoming
auth=rsa
inkeys=freeworlddialup

Dentro de la sección [general] habrá que agregar la instrucción register. El propósito

del comando register es decirle al servidor IAX del servicio FWD dónde nos encontramos
en Internet (i.e. la dirección IP nuestra). Cuando una llamada es efectuada a nuestro
número FWD, los servidores FWD hacen una búsqueda en sus bases de datos y dirigen
la llamada a la dirección IP asociada con el número FWD.
En la sección [iaxfwd] se define el usuario para llamadas entrantes con type=user.
Luego se define a donde la llamada entrante va a ser manejada dentro del dial plan con
la instrucción context=incoming. Para especificar que la autenticación para la llamada
entrante será hecha con un par de llaves públicas/privadas RSA se usa auth=rsa. La lla-
ve pública se define con inkeys=freeworlddialup. La llave pública freeworlddialup
viene de manera estándar en Asterisk.
Configuración del dial plan
Manejar una llamada entrante en el archivo extension.conf es simple. Primero se
crea un contexto llamado incoming, o sea, el mismo nombre de contexto usado para el
usuario (user) iaxfwd en iax.conf. El contexto se sigue con una instrucción de Dial()
que va a marcar el interno SIP creado previamente en este capítulo. En el siguiente
ejemplo reemplazar 10001 con el número de la cuenta FWD que se esté usando:

[incoming]
exten => 10001,1,Dial(SIP/john)

Configurando Conexiones salientes con IAX

Como se mencionó antes, un user IAX recibe llamadas entrantes, un peer IAX se usa
para hacer llamadas salientes.
Configuración de iax.conf
La siguiente entrada en el archivo iax.conf se puede usar para hacer una llamada a la
red FWD:

[iaxfwd]
type=peer
host=iax2.fwdnet.net
username=<numero de cuenta fwd>
secret=<password de cuenta fwd>
qualify=yes
disallow=all
allow=ulaw
allow=gsm
2.13 Configuración inicial de Asterisk 98

allow=ilbc
allow=g726

Un par se define como type=peer. Se usa la instrucción host para configurar el servidor
a través del cual se harán llamadas (iax2.fwdnet.net para el ejemplo). El número de
cuenta y contraseña se usarán para autenticarse en la red FWD y se definen respecti-
vamente con username y secret.
Se puede usar la instrucción qualify=yes para ocasionalmente chequear que el servi-
dor remoto esté respondiendo. El tiempo de respuesta (latencia) puede ser monitoreado
desde la consola de Asterisk con el comando iax2 show peers. Por defecto un par es
considerado inalcanzable luego de 2 segundos (2000 milisegundos). Se puede persona-
lizar el tiempo reemplazando yes por la cantidad de milisegundos en la instrucción
qualify.
Los CODEC disponibles y el orden de preferencia pueden ser definidos para cada par
(peer). La instrucción disallow=all se usa para resetear cualquier configuración de
CODEC previamente establecido. Se puede luego ir usando la instrucción allow para
permitir los CODEC que se prevé soportar y establecer su orden de preferencia (de
arriba hacia abajo) usando la sintaxis allow=codec.
El comando iax2 show registry de la interfaz de comandos de Asterisk verifica que
se haya registrado de manera correcta.
Configuración del dial plan
Como en las previas configuraciones, se creará un contexto seguido por instrucciones
para efectuar una prueba con la aplicación Echo(). Se puede usar tanto un teléfono
conectado al puerto FXS (si se dispone de uno) o un teléfono SIP (ej. X-lite) y llamar
el interno 613:

[internal]
exten => 613,1,Dial(IAX2/iaxfwd/613)

2.13.6. Depurando
Hay varios modos de depurar en Asterisk. Cuando se ha logrado conectar a la consola
de Asterisk es posible establecer distintos niveles de verbosidad y salidas de depuración.

2.13.7. Conectando a la Consola

Para conectarse a la consola de asterisk se puede arrancar el servidor con la consola
directamente o arrancar el demonio de Asterisk y luego conectar a una consola remota.
Para arrancar asterisk directamente con la consola usar -c:
# /usr/sbin/asterisk -c
Para conectar a una consola remota, iniciar el demonio primero y luego conectarse con
la opción -r:

# /usr/sbin/asterisk
# /usr/sbin/asterisk -r
2.14 Fundamentos del dial plan 99

Si se está teniendo problemas con un módulo que no se está cargando o que provoca que
Asterisk no pueda arrancar, iniciar asterisk con -c para monitorear el estado de carga
de los módulos. Por ejemplo si se intenta cargar el driver de canal OSS (que permite el
uso del canal CONSOLE) y Asterisk no puede abrir /dev/dsp se recibirá el siguiente
error al inicio:

WARNING[32174]: chan_oss.c:470 soundcard_init: Unable to open /dev/dsp:

No such file or directory
== No sound card detected -- console channel will be unavailable
== Turn off OSS support by adding ’noload=chan_oss.so’
in /etc/asterisk/modules.conf

2.13.8. Activando Verbosidad y Depuración

Asterisk puede sacar información de depuración en la forma de mensajes del tipo WA-
RINING, NOTICE o ERROR. Estos mensajes dan información acerca del sistema,
como registración, estado y progreso de llamadas y mucha otra información útil. Los
mensajes WARNING Y NOTICE no son errores, pero los mensajes ERROR si lo son y
deberían ser investigados. Para activar los diferentes niveles de salidas de alarmas usar
el comando set verbose seguido de un valor numérico. Valores útiles van del 3 al 10.
Se puede activar también mensajes de depuración con el comando set debug seguido
de un valor numérico (del 3 al 10). Para habilitar la salida de DEBUG en la consola,
puede ser necesario activarla en el archivo logger.conf agregando debug en la instrucción
console=>como sigue:
console => warning,notice,error,event,debug

2.14. Fundamentos del dial plan

El dial plan es realmente el corazón de cualquier sistema Asterisk, ya que define co-
mo Asterisk maneja las llamadas entrantes y salientes. Esto consiste en una lista de
instrucciones o pasos que Asterisk seguirá. A diferencia de los sistemas telefónicos tradi-
cionales, el dial plan es totalmente personalizable. Para establecer con éxito un sistema
Asterisk propio, se necesitará entender el dial plan.

2.14.1. Sintaxis del dial plan

El dial plan está especificado en el archivo de configuración llamado extensions.conf.
El mismo está ordenado en cuatro partes principales: contextos, extensiones, priori-
dades y aplicaciones. En las siguientes secciones, cubriremos cada una de estas partes
y explicaremos como trabajan juntas para crear un dial plan. Después de explicar el
papel que cada uno de estos elementos juega en el dial plan, entraremos en el proceso
de crear un dial plan básico.
Archivos de Configuración de Muestra
Si se instalara los archivos de configuración de muestra al instalar Asterisk, probable-
mente se tendrá un archivo extensions.conf. En vez de comenzar con el archivo de mues-
tra, sugerimos que se construya el archivo extensions.conf desde cero. Esto será muy
2.14 Fundamentos del dial plan 100

beneficioso, ya que dará un mejor entendimiento de los conceptos y fundamentos del

dial plan. Dicho esto, la muestra extensions.conf significa un recurso fantástico, lleno
de ejemplos e ideas que se pueden usar después de que se ha aprendido los conceptos bá-
sicos. Sugerimos que se renombre el archivo de muestra como extensions.conf.ejemplo.
También se puede encontrar los archivos de configuración de muestra en el directorio
/configs/ de la fuente de Asterisk.

Contextos

Los dialplans están divididos en secciones llamadas contextos. Los contextos son gru-
pos de extensiones. Una extensión que es definida en un contexto está completamente
aislada de extensiones en cualquier otro contexto, a menos que la interacción sea ex-
presamente permitida.
Como un ejemplo simple, imaginemos que tenemos dos compañías que comparten un
servidor Asterisk. Si colocamos el menú de voicemail de cada compañía en su propio
contexto, ellos han sido eficientemente separados del otro. Esto permite que se defina
independientemente lo que pasa cuando, supongamos, la extensión 0 es marcada: las
personas que presionen el 0 en el menú de voicemail de la Compañía A, hablarán con la
recepcionista de la Compañía A, y visitantes que presionen 0 en el menú de voicemail
de la Compañía B, hablarán con la recepcionista de la Compañía B. (Este ejemplo
asume, por supuesto, que se ha configurado Asterisk para transferir las llamadas a los
recepcionistas cuando los visitantes presionan 0).
Los contextos son denotados colocando el nombre del mismo entre corchetes ([]). El
nombre puede ser cualquier cosa, utilizando desde la letra A hasta la Z (minúscula o
mayúscula), los números de 0 a 9 y el guión bajo o alto. Por ejemplo, un contexto para
las llamadas entrantes podría ser:
[incoming]
Todas las instrucciones colocadas después de una definición de contexto son parte de
aquel contexto, hasta que el siguiente contexto es definido. Al principio del dial plan,
hay dos contextos especiales llamados [general] y [globals]. Más adelante en este
trabajo los describiremos.
Uno de los usos más importantes de los contextos es para hacer cumplir la seguridad
establecida en cuanto al uso de las líneas telefónicas. Usando contextos correctamente,
se puede dar cierto acceso a rasgos del sistema a personas que llaman (como llamadas
de larga distancia) que no están a disposición de otras. Si no se diseña el dial plan con
cuidado, se puede permitir por descuido que otros usen fraudulentamente el sistema.

Extensiones

Dentro de cada contexto, definimos una o varias extensiones. Una extensión es una
instrucción que Asterisk seguirá, provocado por una llamada entrante o por dígitos
marcados en un canal. Las extensiones especifican lo que le pasa a las llamadas cuando
ellas recorren su camino por el dial plan. Aunque las extensiones puedan ser usadas para
especificar extensiones telefónicas en el sentido tradicional (es decir, por favor llame a
Juan en la extensión 153), ellas pueden ser usadas para mucho más en Asterisk.
La sintaxis para una extensión es la palabra exten seguida de una flecha formada por
el signo igual y el signo mayor que:
2.14 Fundamentos del dial plan 101

exten =>
Esto es seguido del nombre de la extensión. Tratando con sistemas telefónicos, tendemos
a pensar en extensiones como los números que se marcarían para hacer que el otro
teléfono suene. Sin embargo en Asterisk siempre se podrá utilizar números, letras, o
combinaciones de estos.
Una extensión completa está formada de tres componentes:
El nombre (o número) de la extensión
La prioridad (cada extensión puede incluir pasos múltiples; el número de paso es
llamado "prioridad")
La aplicación (o comando) que ejecuta alguna acción en la llamada
Estos tres componentes son separados por comas, como esto:
exten => nombre, prioridad, aplicación ( )
Aquí se muestra un ejemplo simple de cómo podría lucir una verdadera extensión:
exten => 123,1, Answer ( )
En este ejemplo, el nombre de extensión es 123, la prioridad es 1 y la aplicación es
Answer ().

Prioridades

Cada extensión puede tener pasos múltiples, llamados prioridades. Cada prioridad es
numerada secuencialmente, comenzando con 1. Cada prioridad ejecuta una aplicación
específica. Como ejemplo, la extensión siguiente contestaría el teléfono (en la prioridad
número 1) y luego lo cuelga (en la prioridad número 2):

exten => 123,1, Answer ( )

exten => 123,2, Hangup ( )

Asterisk sigue las prioridades en orden numérico.

Aplicaciones

Las aplicaciones son los burros de carga del dial plan. Cada aplicación realiza una acción
específica en el canal, como reproducir un sonido, aceptar una entrada marcada o la
finalización de una llamada.
Nota: Prioridades sin Numerar No hay nada como establecer que las prioridades tienen
que ser numeradas secuencialmente y entonces contradecirnos nosotros mismos. La
versión 1.2 de Asterisk añade una vuelta de tuerca a la enumeración de prioridades.
Esto introduce el uso de la prioridad n, que significa "siguiente". Cada vez que Asterisk
encuentra una prioridad n, toma el número de la prioridad anterior y añade 1. Este
hace más fácil hacer los cambios en el dial plan, para no tener que volver a numerar
todos los pasos. Por ejemplo, el dial plan podría verse como lo siguiente:
2.14 Fundamentos del dial plan 102

exten => 123,1, Answer ( )

exten => 123, n, hace algo
exten => 123, n, hace algo más
exten => 123, n, hace una última cosa
exten => 123, n, Hangup ( )

La versión 1.2 también permite que se adjudique etiquetas de texto a prioridades. Ad-
judicar una etiqueta a una prioridad, simplemente añade texto dentro de un paréntesis
después de la prioridad, como esto:
exten => 123, n (etiqueta), hace algo
Algunas aplicaciones, como Answer ( ) y Hangup ( ), no necesitan ninguna otra instruc-
ción para hacer su trabajo. Otras aplicaciones requieren información adicional. Estas
informaciones, llamadas argumentos, pueden ser pasadas a las aplicaciones para indicar
como deben ejecutar las acciones. Para pasar argumentos a una aplicación, se los deberá
colocar entre paréntesis seguidos del nombre de la aplicación, separados por comas.

2.14.2. Un dial plan simple

Ahora estamos listos para crear un primer dial plan. Comenzaremos con un ejemplo muy
simple. Diseñaremos este dial plan de modo que cuando una llamada entre, Asterisk
contestará la llamada, reproducirá un sonido y luego colgará la llamada. Usaremos este
ejemplo simple para señalar fundamentos del dial plan muy importantes.
Se asume que al menos un canal Zap ha sido creado y configurado, y que todas las
llamadas entrantes son enviadas al contexto [incoming].

La Extensión s

Antes de comenzar con el dial plan, deberíamos explicar una extensión especial llamada
s. Cuando las llamadas entran en un contexto sin una extensión de destino específica
(por ejemplo, que suene una línea FXO), ellas son manejados automáticamente por la
extensión s. (La s significa start, ya que la mayor parte de las llamadas empiezan en la
extensión s.) Ya que esto es exactamente lo que necesitamos para el dial plan, vamos
a comenzar a unir los pedazos. Ejecutaremos tres acciones en la llamada (contestar,
reproducir sonido y colgar), entonces necesitamos crear una extensión s con tres prio-
ridades. Colocaremos las tres prioridades dentro [entrantes], ya que todas las llamadas
entrantes deberían comenzar en este contexto:

[incoming]

exten => s, 1, aplicación ( )

exten => s, 2, aplicación ( )
exten => s, 3, aplicación ( )

Ahora todo lo que tenemos que hacer es rellenar las aplicaciones y hemos creado nuestro
primer dial plan.
2.14 Fundamentos del dial plan 103

2.14.3. Las aplicaciones Answer ( ), Playback( ) y Hangup( )

Si vamos a contestar la llamada, reproducir un archivo y luego colgar, mejor aprendamos
a hacer justamente esto. La aplicación Answer ( ) es usada para contestar un canal que
está sonando. Como mencionamos antes, Answer ( ) no tiene argumentos.
La aplicación Playback ( ) es usada para reproducir un sonido previamente grabado
en un canal. Usando la aplicación Playback ( ), la entrada digitada por el usuario es
simplemente ignorada.
Para usar Playback ( ), se debe especificar el nombre del archivo (sin una extensión
de archivo) como argumento. Por ejemplo, Playback (nombre) reproducirá el archivo
de sonido llamada nombre.gsm, asumiendo que está ubicado en el directorio de sonidos
por defecto. Se puede incluir el camino completo al archivo si se quiere:
Playback (/home/juan/sounds/nombre)
Este ejemplo reproducirá nombre.gsm desde el directorio /home/juan/sounds/. Se pue-
de usar también caminos relativos del directorio de sonidos de Asterisk:
Playback (custom/nombre)
Este ejemplo reproducirá nombre.gsm desde el subdirectorio de sonidos por defecto
custom/. Si el directorio especificado contiene más de un archivo con aquel nombre pero
con extensiones de archivo diferentes, Asterisk automáticamente reproduce el mejor
archivo (el que utilizará menos el procesador de la computadora para convertirlo a su
formato nativo).
La aplicación Hangup ( ) hace exactamente lo que su nombre implica: cuelga el canal
activo. El visitante recibirá una indicación que la llamada ha sido colgada. Se usará
esta aplicación al final del contexto cuando se quiera terminar la llamada actual, para
asegurar que los visitantes no siguen en el dial plan. Esta aplicación no tiene argumentos.

2.14.4. Primer dial plan

Ahora que hemos creado una extensión, considerando tres prioridades diferentes, y
aprendido sobre las aplicaciones que vamos a usar, reuniremos todos los pedazos para
crear nuestro primer dial plan. Como es típico nuestro primer ejemplo será llamado
Hola Mundo!
En la primera prioridad de nuestra extensión, contestaremos la llamada. En la segunda,
reproduciremos el archivo de sonido llamado hola-mundo.gsm, y en la tercera colgare-
mos la llamada:

[incoming]

exten => s, 1, Answer ( )

exten => s, 2, Playback (hola-mundo)
exten => s, 3, Hangup ( )

A pesar de que este ejemplo sea muy corto y simple, enfatiza los conceptos principales
de contextos, extensiones, prioridades y aplicaciones. Ahora que hemos cubierto éstos
conceptos básicos, vamos a seguir construyendo sobre nuestro ejemplo. Después de todo,
un sistema telefónico que simplemente reproduce un sonido y luego cuelga no es tan
útil!
2.15 Adición de Lógica al dial plan 104

2.15. Adición de Lógica al dial plan

El dial plan que construimos es estático, siempre realiza las mismas acciones en cada
llamada. Ahora comenzaremos a añadir un poco de lógica a nuestro dial plan de modo
que ejecute diferentes acciones basadas en las entradas de los usuarios. Comenzaremos
introduciendo unas aplicaciones más.

2.15.1. Las aplicaciones Background ( ) y Goto ( )

Una clave importante al edificar un sistema Asterisk interactivo es la aplicación Back-
ground ( ). Como Playback ( ), reproduce un archivo de sonido registrado. A diferencia
de Playback ( ) cuando el visitante presiona un dígito (o una serie de dígitos) en su
teclado numérico telefónico, esto interrumpe la reproducción y dirige la llamada a la
extensión que corresponde al dígito/s marcado. Si un visitante aprieta 5, por ejemplo,
Asterisk dejará de reproducir el sonido y enviará el control de la llamada a la primera
prioridad de la extensión 5.
El uso más común de la aplicación Background ( ) es crear menús de voz (a menudo
llamados autoatendedores, preatendedores o árboles telefónicos). Muchas compañías
usan menús de voz para dirigir a los visitantes a las extensiones apropiadas, aliviando
así a sus recepcionistas de contestar cada una de las llamadas.
Background ( ) tiene la misma sintaxis que Playback ( ):
exten => 123,1, Background (hola-mundo)
Otra aplicación útil es Goto ( ). Como su nombre lo indica, es usada para enviar la
llamada a otro contexto, extensión o prioridad. La aplicación Goto ( ) hace fácil mover
mediante configuración una llamada entre partes diferentes del dial plan. La sintaxis
para Goto ( ) pide que se pase el contexto, la extensión o la prioridad de destino como
argumentos a la aplicación:
exten => 123,1, Goto (contexto,extensión,prioridad)
En nuestro siguiente ejemplo, usaremos las aplicaciones Background ( ) y Goto ( )
para crear un dial plan ligeramente más complejo, permitiendo al visitante relacionarse
con el sistema mediante dígitos marcados en el teclado numérico. Comencemos usando
Background () para aceptar la entrada del visitante:

[incoming]

exten => s, 1, Answer ( )

exten => s, 2, Background (marque-el-interno)

En este ejemplo, se reproducirá el archivo de sonido llamado marque-el-interno.gsm

(en inglés enter-ext-of-person.gsm). Si bien esto no es adecuado para un preaten-
dedor, funcionará para este ejemplo. Ahora vamos a añadir dos extensiones que serán
provocadas por las entradas 1 o 2 marcadas por el visitante:

[incoming]

exten => s, 1, Answer ( )

exten => s, 2, Background (marque-el-interno)
2.15 Adición de Lógica al dial plan 105

exten => 1,1, Playback (digits/1)

exten => 2,1, Playback (digits/2)

Examinemos lo que hemos hecho hasta ahora. Cuando los usuarios llaman, ellos oirán
un saludo "Por favor marque el interno que usted desea llamar". Si ellos aprietan 1,
ellos oirán el número uno, y si ellos aprietan 2, ellos oirán el número dos. Mientras esto
es un buen principio, vamos a embellecerlo un poco. Usaremos la aplicación Goto ( )
para repetir el saludo después de poner el número:

[incoming]

exten => s, 1, Answer ( )

exten => s, 2, Background (marque-el-interno)
exten => 1,1, Playback (digits/1)
exten => 1,2, Goto (incoming,s,1)
exten => 2,1, Playback (digits/2)
exten => 2,2, Goto (incoming,s,1)

Estas dos nuevas líneas devolverán el control de llamada a la extensión s después de

poner el número seleccionado.

2.15.2. El Manejo de Entradas Inválidas e Intervalos de espera

Ahora que el primer menú de voz está bastante completo, vamos a añadir algunas
extensiones especiales. Primero, necesitamos una extensión para entradas inválidas,
de modo que cuando un visitante presione una entrada inválida (ej., presionando 3
en el ejemplo anterior), la llamada sea enviada a la extensión i (de inválida). Segundo,
necesitamos una extensión para manejar la situación cuando el visitante no da la entrada
a tiempo (el intervalo de espera por defecto es 10 segundos). Las llamadas serán enviadas
a la extensión t (de timeout) si el visitante toma demasiado tiempo para presionar un
dígito después de que Background ( ) ha terminado de reproducir el archivo de sonido.
Así lucirá el dial plan una vez que hayamos añadido estas dos extensiones:

[incoming]

exten => s, 1, Answer ( )

exten => s, 2, Background (marque-el-interno)
exten => 1,1, Playback (digits/1)
exten => 1,2, Goto (incoming,s,1)
exten => 2,1, Playback (digits/2)
exten => 2,2, Goto (incoming, s, 1)
exten => i, 1, Playback (pbx-invalido)
exten => i, 2, Goto (incoming, s, 1)
exten => t, 1, Playback (vm-adios)
exten => t, 2, Hangup ( )

Usando las extensiones i y t hacemos nuestro dial plan un poco más robusto y fácil de
usar. Dicho esto, todavía es completamente limitado, porque los visitantes exteriores
no tienen acceso para conectarse con alguna persona. Para hacer esto, tendremos que
aprender sobre otra aplicación, llamada Dial( ).
2.15 Adición de Lógica al dial plan 106

2.15.3. Usando la aplicación Dial ( )

Uno de los rasgos más valiosos de Asterisk es su capacidad de conectar a diferentes
usuarios entre ellos. Esto es especialmente útil cuando usan diferentes métodos de co-
municación. Por ejemplo, el usuario A podría comunicarse mediante su teléfono análogo
estándar, mientras el usuario B podría estar sentado en una cafetería alrededor el mun-
do y hablando a través de un teléfono IP. Por suerte, Asterisk toma la mayor parte del
difícil trabajo de conexión y traducción entre redes dispares. Todo lo que se tiene que
aprender es a usar la aplicación Dial ( ).
La sintaxis de la aplicación Dial ( ) es un poco más compleja que las otras aplicaciones
que hemos usado hasta ahora. Dial ( ) tiene hasta cuatro argumentos. El primero es
el destino que se intenta llamar, compuesto por la tecnología (o transporte) que se
utiliza para hacer la llamada, una barra oblicua y el recurso remoto (por lo general
el nombre de un canal o número). Por ejemplo, asumamos que queremos llamar a un
canal Zap llamado Zap/1, que es un canal FXS con un teléfono análogo. La tecnología
es Zap y el recurso es 1. Del mismo modo, una llamada a un dispositivo SIP podría
tener un destino SIP/1234, y una llamada a un dispositivo IAX podría tener un destino
IAX/Pedro. Si queremos que Asterisk haga sonar el canal ZAP/1 cuando la extensión
123 es alcanzada en el dial plan, añadiríamos la siguiente siguiente:
exten => 123,1, Dial (Zap/1)
Cuando esta extensión sea ejecutada, Asterisk hará sonar el teléfono conectado en el
canal ZAP/1. Si aquel teléfono es contestado, Asterisk tenderá un puente sobre la
llamada entrante con el canal Zap/1. También podemos marcar múltiples canales al
mismo tiempo, concatenando los destinos con el signo &, de esta forma:
exten => 123,1, Dial (Zap/1&Zap/2&Zap/3)
La aplicación Dial ( ) tenderá un puente sobre la llamada entrante con cualquier canal
destino que sea contestado primero.
El segundo argumento de la aplicación Dial ( ) es un intervalo de espera, especificado en
segundos. Si un intervalo de espera es dado, Dial ( ) intentará llamar al destino durante
aquel número de segundos antes de dejar la llamada y pasar a la siguiente prioridad en
la extensión. Si no se especifica intervalo de espera, Discar ( ) continuará llamando al
canal hasta que alguien atienda o el visitante cuelgue. Vamos a añadir un intervalo de
espera de 10 segundos a nuestra extensión:
exten => 123,1, Dial (Zap/1,10)
Si la llamada es contestada antes del intervalo de espera, se tiende un puente sobre los
canales y el dial plan está ejecutado. Si el destino simplemente no contesta, Dial ( )
continúa con la siguiente prioridad en la extensión. Si, sin embargo, el canal de destino
está ocupado, Dial ( ) irá a la prioridad n+101, si esta existe (donde n es la prioridad
desde donde la aplicación Dial es llamada). Esto permite que manejemos llamadas sin
contestar de forma diferente a las llamadas cuyos destinos estaban ocupados.
Vamos a poner lo hecho hasta ahora en otro ejemplo:

exten => 123,1, Dial (Zap/1,10)

exten => 123,2, Playback (vm-no-contesta)
exten => 123,3, Hangup ( )
exten => 123,102, Playback (tt-ocupado)
exten => 123,103, Hangup ( )
2.15 Adición de Lógica al dial plan 107

Como se ve, este ejemplo reproducirá el archivo de sonido vm-no-contesta.gsm si no

se contesta la llamada, o el archivo de sonido de tt-ocupado.gsm si el canal Zap/1 está
actualmente ocupado.
El tercer argumento para Dial ( ) es una cadena de opciones. Puede contener uno o
varios caracteres que modifican el comportamiento de la aplicación Dial ( ). Mientras
que la lista de las posibles opciones es demasiado larga para cubrir aquí, la opción más
popular es la letra r. Si se coloca la letra r como el tercer argumento, la persona que
llama oirá un tono de llamada mientras el canal de destino está siendo notificado de
una llamada entrante.
Para añadir la opción r a nuestro último ejemplo, simplemente cambiamos la primera
línea:

exten => 123,1, Dial (Zap/1,10, r)

exten => 123,2, Playback (vm-no-contesta)
exten => 123,3, Hangup ( )
exten => 123,102, Playback (tt-ocupado)
exten => 123,103, Hangup ( )

Ya que las extensiones 1 y 2 en nuestro dial plan son algo inútiles ahora que sabemos
usar la aplicación Dial ( ), vamos a sustituirlas y colocar por ellas las extensiones 101
y 102, que permitirán que los visitantes exteriores llamen a Juan y Julia:

[incoming]

exten => s, 1, Answer ( )

exten => s, 2, Background (marque-el-interno)
exten => 101,1, Dial (Zap/1,10)
exten => 101,2, Playback (vm-no-contesta)
exten => 101,3, Hangup ( )
exten => 101,102, Playback (tt-ocupado)
exten => 101,103, Hangup ( )
exten => 102,1, Dial (SIP/Julia, 10)
exten => 102,2, Playback (vm-no-contesta)
exten => 102,3, Hangup ( )
exten => 102,102, Playback (tt-ocupado)
exten => 102,103, Hangup ( )
exten => i, 1, Playback (pbx-invalido)
exten => i, 2, Goto (incoming, s, 1)
exten => t, 1, Playback (vm-adios)
exten => t, 2, Hangup ( )

El cuarto y último argumento de la aplicación Dial ( ) es una Universal Resource

Location (URL). Si el canal de destino provee la recepción de una URL en el momento
de la llamada, la URL especificada será enviada (por ejemplo, si se tiene un teléfono
IP que provee la recepción de una URL, esta va a aparecer en el visor del teléfono;
igualmente, si se usa un teléfono por software, la URL podría aparecer en la pantalla
de la computadora). Este argumento es muy raramente usado.
Si se hacen llamadas salientes en un canal Zap FXO, se puede usar la siguiente sintaxis
para marcar un número en aquel canal:
2.15 Adición de Lógica al dial plan 108

exten => 123,1, Dial (Zap/4/5551212)

Este ejemplo marcaría el número 555-1212 en el canal Zap/4. Para otros tipos de
canales, como SIP y IAX, simplemente se coloca el destino como la fuente:

exten => 123,1, Dial (SIP/1234)

exten => 124,1, Dial (IAX2/[email protected])

Note que cualquiera de estos argumentos puede ser dejado en blanco. Por ejemplo, si
se quiere especificar una opción pero no un intervalo de espera, simplemente se deja el
argumento de intervalo de espera en blanco:
exten => 123,1, Dial (Zap/1,,r)

2.15.4. Contexto para Llamadas Internas

En nuestros ejemplos hasta ahora nos hemos limitado a un solo contexto, pero es
probablemente justo asumir que casi todas las instalaciones de Asterisk tendrán más de
un contexto en sus dialplans. Como se mencionó anteriormente, una función importante
de los contextos será la de separar los privilegios para las diferentes clases de visitantes.
En nuestro siguiente ejemplo, añadiremos a nuestro dial plan dos extensiones telefónicas
internas y estableceremos su capacidad para llamarse entre ellas. Para llevar a cabo esto,
crearemos un nuevo contexto llamado [internal].

[incoming]

exten => s,1,Answer( )

exten => s,2,Background(marque-el-interno)
exten => 101,1,Dial(Zap/1,10)
exten => 101,2,Playback(vm-nocontesta)
exten => 101,3,Hangup( )
exten => 101,102,Playback(tt- ocupado)
exten => 101,103,Hangup( )
exten => 102,1,Dial(SIP/Jane,10)
exten => 102,2,Playback(vm-nocontesta)
exten => 102,3,Hangup( )
exten => 102,102,Playback(tt-ocupado)
exten => 102,103,Hangup( )
exten => i,1,Playback(pbx-invalida)
exten => i,2,Goto(incoming,s,1)
exten => t,1,Playback(vm-goodbye)
exten => t,2,Hangup( )

[internal]

exten => 101,1,Dial(Zap/1,,r)

exten => 102,1,Dial(SIP/jane,,r)

En este ejemplo, hemos añadido dos nuevas extensiones en el contexto [internal]. De

esta forma, la persona que usa el canal Zap/1 puede recoger el teléfono y llamar a la
persona en el canal SIP/julia marcando 102. De la misma manera, el teléfono registrado
como SIP/julia puede llamar a Zap/1 marcando 101.
2.15 Adición de Lógica al dial plan 109

2.15.5. Utilización de Variables

Las variables pueden ser usadas en un dial plan para ayudar a reducir el tipeado, añadir
claridad o añadir lógica adicional. Si se tiene alguna experiencia de programación,
probablemente se entenderá qué es una variable. Si no, no hay que preocuparse, vamos
a explicar lo que las variables son y cómo son usadas.
Se puede pensar en una variable como un contenedor que puede tener solo un valor
a la vez. De este modo, por ejemplo, podríamos crear una variable llamada JUAN y
adjudicarle el valor Zap/1. De esta forma, cuando escribimos nuestro dial plan, podemos
referirnos al canal de Juan por el nombre, en vez de recordar que Juan usa Zap/1. Para
signar un valor a una variable, simplemente hay que escribir el nombre de la variable,
un signo igual y el valor, como se muestra:
JUAN=Zap/1
Hay dos modos de referirse a una variable. Para referirse al nombre de la variable,
simplemente se escribe el nombre de la variable, como JUAN. Si, por otra parte, se
quiere referir su valor, se debe escribir un signo de dólar, abrir paréntesis, el nombre
de la variable y cerrar paréntesis. Aquí se muestra como nos referiríamos a la variable
dentro de la aplicación Dial ( ):
exten => 555,1, Dial ($ { JUAN },, r)
En nuestro dial plan, siempre que escribamos $ { JUAN }, Asterisk lo sustituirá auto-
máticamente con cualquier valor que haya sido adjudicado a la variable llamada JUAN.
Hay tres tipos de variables que podemos usar en nuestro dial plan: variables globales,
variables de canal y variables de ambiente. Vamos a explicar cada tipo a continuación.

Variables globales

Como su nombre lo indica, las variables globales se aplican a todas las extensiones en
todos los contextos. Las variables globales pueden ser usadas en todas partes dentro
de un dial plan para aumentar legibilidad y manejabilidad. Supongamos que se tiene
un dial plan grande y cientos de referencias al canal Zap/1. Ahora imaginemos que se
tenga que ir a través del dial plan cambiando todas aquellas referencias por Zap/2. Esto
sería un largo proceso predispuesto al error, por no decir más.
Por otra parte, si se había definido una variable global con el valor Zap/1 en el comienzo
del dial plan y luego referencias a esta, sólo se tendría que cambiar una línea.
Las variables globales deberían ser declaradas en el contexto [globals] al principio del
archivo extensions.conf. Sin embargo también pueden ser definidas mediante progra-
mación, usando la aplicación SetGlobalVar ( ). Aquí se muestran ambos métodos:

[globals]

JUAN=Zap/1

[internal]

exten => 123,1, SetGlobalVar (JUAN =Zap/1)

2.15 Adición de Lógica al dial plan 110

Variables de canal

Una variable de canal (como el número de Caller ID) está asociada sólo con una llamada
en particular. A diferencia de las variables globales, las variables de canal son definidas
sólo para la duración de la llamada corriente y está disponible sólo para el canal que
participa en aquella llamada.
Hay muchas variables de canal predefinidas, disponibles para el uso dentro del dial
plan, que son explicadas en el archivo README.variables, en el subdirectorio /doc de
la fuente de Asterisk. Las variables de canal son definidas a través de la aplicación
Set ( ):
exten => 123,1, Set (NUMEROMAGICO=42)

Variables de entorno

Las variables de entorno son un modo de tener acceso a variables de entorno Unix desde
Asterisk. Estas está referidas como $ {ENV (var)}, donde var es la variable entorno
de Unix.

Adición de variables a nuestro dial plan

Ahora que hemos descrito las variables, vamos a ponerlas a trabajar dentro en nuestro
dial plan. Vamos a añadir variables para dos personas, Juan y Julia:

[globals]

JUAN=Zap/1
JULIA=SIP/julia

[incoming]

exten => s, 1, Answer ( )

exten => s, 2, Background (marque-el-interno)
exten => 101,1, Dial ($ { JUAN }, 10)
exten => 101,2, Playback (vm-no-contesta)
exten => 101,3, Hangup ( )
exten => 101,102, Playback (tt-ocupado)
exten => 101,103, Hangup ( )
exten => 102,1, Dial ($ {JULIA}, 10)
exten => 102,2, Playback (vm-no-contesta)
exten => 102,3, Hangup ( )
exten => 102,102, Playback (tt-ocupado)
exten => 102,103, Hangup ( )
exten => i, 1, Playback (pbx-inválido)
exten => i, 2, Goto (incoming, s, 1)
exten => t, 1, Playback (vm-goodbye)
exten => t, 2, Hangup ( )

[internal]
2.15 Adición de Lógica al dial plan 111

exten => 101,1, Dial ($ {JUAN},, r)

exten => 102,1, Dial ($ {JULIA},, r)

2.15.6. Correspondencia de Patrones

A menudo, sería tedioso añadir cada posible extensión a un dial plan. Sobre todo para
el caso de llamadas salientes. Simplemente hay que imaginar un dial plan con una
extensión para cada número posible que se pueda marcar. Por suerte, Asterisk tiene la
correspondencia de patrones para situaciones como esta, que permite usar una sección
de código para extensiones diferentes.

Sintaxis de la correspondencia de patrones

Con la correspondencia de patrones, usamos diferentes letras y símbolos para repre-

sentar los posibles dígitos que queremos corresponder. Los patrones siempre comienzan
con un guión bajo (_). Este le dice a Asterisk que corresponderemos un patrón, y no el
nombre de una extensión. Esto significa, por supuesto, que nunca se deberá comenzar
los nombres de extensión con un guión bajo.
Después del guión bajo, se puede usar uno o varios de los siguientes caracteres:
X Corresponde con cualquier dígito de 0 a 9.
Z Corresponde con cualquier dígito de 1 a 9.
N Corresponde con cualquier dígito de 2 a 9.
[15-7] Corresponde con cualquier dígito o rango de dígitos especificados. En este caso,
corresponde con 1, 5, 6, o 7.
. (punto) Comodín de correspondencia; corresponde con uno o varios caracteres.
Para usar los patrones en el dial plan, simplemente hay que colocar los mismos en el
lugar del nombre de la extensión (o número):
exten => _NXX, 1, Playback (auth-thankyou)
En este ejemplo, el patrón se corresponde con cualquier extensión de 3 dígitos desde
200 hasta 999 (N corresponde con cualquier dígito entre 2 y 9, y cada X corresponde
con dígitos entre 0 y 9). O sea, si un visitante marca alguna extensión de 3 dígitos entre
200 y 999 en este contexto, oirá el archivo de sonido auth- thankyou.gsm.
Otra cosa importante para saber sobre la correspondencia de patrones es que si Asterisk
encuentra más de un patrón en la extensión marcada, usará la más específica. Supo-
niendo que se ha definido los dos patrones siguientes y un visitante marcó 888-555-1212:

exten => _555XXXX, 1, Playback (digits/1)

exten => _55512XX, 1, Playback (digits /2)

En este caso la segunda extensión sería seleccionada, porque es más específica.

2.15 Adición de Lógica al dial plan 112

Ejemplos de correspondencia de patrones

Antes de que continuemos, vamos a examinar unos ejemplos más.

_4XXXXXX
Este patrón correspondería con cualquier número de siete dígitos, mientras el primer
dígito será 4. Según el Plan de Numeración de la ciudad de Córdoba, este patrón se
correspondería con cualquier número local.
Vamos a intentar otro:
_1NXXXXXXXXX
Este ejemplo es ligeramente más difícil. Correspondería el número 0, seguido de un
prefijo local entre 200 y 999, y por último cualquier número de 7 dígitos.
Veamos este ejemplo engañoso:
_011.
¿Se nota el punto final? Este patrón corresponde con cualquier número que comienza
con 011 y tiene al menos uno más dígitos.

Utilizando la variable de canal $ (EXTEN)

Que pasaría si quisiéramos utilizar la correspondencia por patrones, pero no sabemos

que dígitos han sido marcados? Por suerte, Asterisk tiene la respuesta. Siempre que
se marque una extensión, Asterisk pone en la variable de canal $ {EXTEN} los dígitos
marcados. Podemos usar una aplicación llamada SayDigits ( ) para probarlo:
exten => _XXX, 1, SayDigits ($ {EXTEN})
En este ejemplo, la aplicación SayDigits ( ) leerá los tres dígitos de la extensión que
se marcó.
A menudo, es útil manipular la ${EXTEN} para quitar un cierto número de dígitos del
frente de la extensión. Esto es llevado a cabo usando la sintaxis ${EXTEN:x}, donde x es
el número de dígitos que se quitarían. Por ejemplo, si el valor de EXTEN es 95551212,
${EXTEN:1} es igual a 5551212. Vamos a verlo en otro ejemplo:
exten => _XXX, 1, SayDigits (${EXTEN:1})
En este ejemplo, la aplicación SayDigits ( ) leería sólo los dos últimos dígitos de la
extensión marcada.
Si x es negativo, SayDigits ( ) leerá los últimos x dígitos de la extensión marcada. En
este ejemplo que sigue, SayDigits ( ) leerá sólo el último dígito de la extensión marcada:
exten => _XXX, 1, SayDigits (${EXTEN:-1))

2.15.7. Permitiendo llamadas salientes

Ahora que hemos introducido la correspondencia de patrones, podemos avanzar sobre
el proceso de permitir a los usuarios hacer llamadas salientes. Lo primero que haremos
es añadir una variable al contexto [globals] para definir qué canal será usado para
llamadas salientes:
2.15 Adición de Lógica al dial plan 113

[globals]

Juan=Zap/1
Julia=SIP/julia

OUTBOUNDTRUNK=Zap/4

Después, añadiremos contextos a nuestro dial plan para la marcación saliente. Podría-
mos preguntarnos en este punto, por qué tenemos que separar contextos para llamadas
salientes. Este es el modo a través del cual podemos regular y controlar quién tiene
permiso para hacer llamadas, y qué tipos de llamadas salientes se permiten hacer.
Primero, vamos a hacer un contexto para llamadas locales. Para ser consecuente con
los conmutadores telefónicos tradicionales, pondremos un 9 en el frente de nuestros
patrones, de modo que los usuarios tengan que marcar 9 antes de llamar a un número
exterior:

[outbound-local]

exten => _94XXXXXX, 1, Dial (${OUTBOUNDTRUNK}/${EXTEN:1})

exten => _94XXXXXX, 2, Congestion ( )
exten => _94XXXXXX, 102, Congestion ( )

Vamos a examinar lo que acabamos de hacer. Hemos añadido una variable global lla-
mada OUTBOUNDTRUNK, que controlará que canal se usará para llamadas salientes.
Tenemos también añadido un contexto para llamadas locales. En la prioridad 1, toma-
mos la extensión marcada, sacamos el número 9 con la sintaxis ${EXTEN:1}, y luego se
intenta marcar aquel número en el canal designado por la variable OUTBOUNDTRUNK. Si
la llamada es exitosa, se tiende un puente entre quien llama y el canal de salida. Si la
llamada fracasa (porque el canal está ocupado o el número no puede ser marcado por
la razón que sea), la aplicación Congestión ( ) es llamada, que reproduce una señal de
ocupado (tono de congestión) para hacer saber al usuario que la llamada no se puede
realizar.
Antes de ir un poco más lejos, vayamos a asegurarnos que nuestro dial plan permite la
llamada saliente a los números de emergencia:

[outbound-local]

exten => _94XXXXXX, 1, Dial (${OUTBOUNDTRUNK}/${EXTEN:1})

exten => _94XXXXXX, 2, Congestion ( )
exten => _94XXXXXX, 102, Congestion ( )
exten => 107,1, Dial (${OUTBOUNDTRUNK}/107)
exten => 9107,1, Dial (${OUTBOUNDTRUNK}/107)

A continuación, vamos a añadir un contexto para llamadas de larga distancia:

[outbound-long-distance]

exten => _90[123]ZZZNXXXXX, 1, Dial (${OUTBOUNDTRUNK}/${EXTEN:1})

exten => _90[123]ZZZNXXXXX, 2, Congestion ( )
exten => _90[123]ZZZNXXXXX, 102, Congestion ( )
2.15 Adición de Lógica al dial plan 114

Ahora que tenemos estos dos nuevos contextos necesitamos alguna forma para que los
contextos puedan ser capaces de usar otros contextos.

2.15.8. Inclusiones
Asterisk permite usar un contexto dentro de otro a través de la directiva include.
Ésta es usada para conceder el acceso a diferentes secciones del dial plan. Usaremos la
funcionalidad include para permitir a los usuarios en nuestro contexto [internal] la
capacidad de hacer llamadas salientes. Pero primero, vamos a cubrir la sintaxis.
La declaración incluir toma la forma siguiente, donde contexto es el nombre del contexto
remoto queremos incluir en el contexto corriente:
include => contexto
Cuando incluimos contextos dentro de nuestro contexto corriente, tenemos que ser cons-
cientes del orden en el cual los incluimos. Asterisk tratará primero de corresponder la
extensión en el contexto corriente. De no conseguirlo, intentará entonces el primer con-
texto incluido, y continuará con los otros contextos en el orden en que fueron incluidos.
Hasta el momento, nuestro dial plan tiene dos contextos para llamadas salientes, pero
los usuarios en el contexto [internal] no pueden utilizarlos. Vamos a remediar esto con
la inclusión de los dos contextos para llamadas salientes en el contexto [internal],
como se muestra:

[globals]

Juan=Zap/1
Julia=SIP/julia

OUTBOUNDTRUNK=Zap/4

[incoming]

exten => s, 1, Answer ( )

exten => s, 2, Background (marque-el-interno)
exten => 101,1, Dial (${Juan}, 10)
exten => 101,2, Playback (vm-no-contesta)
exten => 101,3, Hangup ( )
exten => 101,102, Playback (tt-ocupado)
exten => 101,103, Hangup ( )
exten => 102,1, Dial (${Julia}, 10)
exten => 102,2, Playback (vm-no-contesta)
exten => 102,3, Hangup ( )
exten => 102,102, Playback (tt-ocupado)
exten => 102,103, Hangup ( )
exten => i, 1, Playback (pbx-inválido)
exten => i, 2, Goto (incoming, s, 1)
exten => t, 1, Playback (vm-adios)
exten => t, 2, Hangup ( )

[internal]
2.16 Más conceptos acerca del Dial plan 115

include => outbound-local

include => outbound-long-distance

exten => 101,1, Dial (${Juan}, r)

exten => 102,1, Dial (${Julia}, r)

[outbound-local]

exten => _94XXXXXX, 1, Dial (${OUTBOUNDTRUNK}/${EXTEN:1})

exten => _94XXXXXX, 2, Congestion ( )
exten => _94XXXXXX, 102, Congestion ( )
exten => 107,1, Dial (${OUTBOUNDTRUNK}/107)
exten => 9107,1, Dial (${OUTBOUNDTRUNK}/107)

[outbound-long-distance]

exten => _90[123]ZZZNXXXXX, 1, Dial (${OUTBOUNDTRUNK}/${EXTEN:1})

exten => _90[123]ZZZNXXXXX, 2, Congestion ( )
exten => _90[123]ZZZNXXXXX, 102, Congestion ( )

Estas dos declaraciones de include hacen posible que los usuarios en el contexto [internal]
puedan hacer llamadas salientes. También deberíamos notar que para el bien de nuestra
seguridad se debería asegurar que el contexto [incoming] nunca permita la marcación
saliente. (Si esto se permitiera, las personas que llaman al sistema podrían hacer lla-
madas salientes que serían cobradas a nosotros!).

2.16. Más conceptos acerca del Dial plan

Ya se han visto muchos conceptos acerca del Dial plan, pero esto no se termina acá.
Para seguir adelante con estos conceptos se necesitará tener bien en claro los puntos
vistos anteriormente.

2.16.1. Manipulación de variables y expresiones

Antes de meternos de lleno en el Dial plan, necesitamos introducir algunos tópicos que
nos permitirán obtener mayor rendimiento a la hora de trabajar con el dial plan. Estos
constructores agregan una inteligencia increíble al dial plan, habilitándolos para tomar
decisiones basándose en muchos diferentes criterios.

Expresiones básicas

La combinación de variables, operadores, y valores que se ponen juntos para obtener

un resultado, son expresiones. Una expresión puede testear valores, alterar cadenas,
o realizar cálculos matemáticos. Digamos que tenemos la variable llamada COUNT.
Dos expresiones usando esta variable podrían ser ÇOUNT mas 1 ÇOUNT dividido
2

2.Çada una de estas expresiones tiene un resultado particular, dependiendo del valor
de la variable utilizada.
2.16 Más conceptos acerca del Dial plan 116

En Asterisk, las expresiones siempre comienzan con el signo pesos y un corchete abierto
terminando con el corchete cerrado, tal como se muestra a continuación:
$[expresión]
Así, se pueden escribir dos ejemplos como sigue:

$[${COUNT} + 1]
$[${COUNT} / 2]

Cuando Asterisk encuentra una expresión en un dial plan, la reemplaza (en su totalidad)
con el valor resultante. Es importante notar que esto se realiza después de la sustitución
de la variable. Para demostrar esto, miremos el siguiente código:

exten => 321,1,Set(COUNT=3)

exten => 321,2,Set(NEWCOUNT= $[${COUNT} + 1])
exten => 321,3,SayNumber(${NEWCOUNT})

En esta primera prioridad, se le asigna el valor de 3 a la variable llamada COUNT.

En la segunda prioridad, solo una aplicación está involucrada, Set(), pero tres cosas
suceden:
1) Asterisk sustituye ${COUNT} con el numero 3 en la expresión. Así la expresión
queda como sigue: Exten => 321,2,Set(NEWCOUNT=$[3 + 1])
2) Luego, Asterisk evalúa la expresión, sumando 1 a 3, y lo reemplaza con el valor
obtenido (4): Exten => 321,2,Set(NEWCOUNT=4)
3) Finalmente, el valor 4 se asigna a la variable NEWCOUNT por medio de la apli-
cación Set().
La tercera prioridad simplemente invoca la aplicación SayNumber(), la cual dice el valor
actual de la variable ${NEWCOUNT}(la que tiene el valor 4 en la prioridad dos).

Operadores

Cuando se crea el dial plan Asterisk, se está escribiendo código en un lenguaje especial.
Esto significa que el dial plan Asterisk, como cualquier lenguaje de programación,
reconoce símbolos llamados operadores que le permiten manipular variables. Listemos
a continuación los tipos de operadores que están disponibles en Asterisk:
Operadores Booleanos
Estos operadores evalúan verdadero en una declaración. Hablando en términos de
computación, esto se refiere a ver si la declaración es algo o nada (no cero, o cero,
verdadero o falso, on o off, y así). Los operadores Booleanos son:
expr1 | expr2
Este operador(llamado operador or ) devuelve el valor de expr1 si esto es verdadero (no
una cadena vacío ni cero). De otra forma, devuelve el valor de expr2.
expr1 & expr2
Este operador (llamado and ) devuelve el valor de expr1 si ambas expresiones son ver-
daderas. Sino, devuelve cero.
expr1 {=, >, >=, <, <=, !=} expr2
2.16 Más conceptos acerca del Dial plan 117

Estos operadores devuelven el resultado de una comparación de enteros si ambos ar-

gumentos son enteros, sino, se devuelve el resultado de una comparación de cadenas.
El resultado de cada comparación es 1 si la relación especificada es verdadera, o 0 si es
falso.
Operadores matemáticos
expr1 {+, -} expr2
Se realiza la suma o resta de las expresiones.
expr1 {*, /, %}expr2
Se devuelve, respectivamente, el resultado de una multiplicación, división o el resto,
realizados entre las expresiones.
Operador de expresión regular
Se puede utilizar en Asterisk en operador de expresión regular:
expr1 : expr2
Este operador compara expr1 con expr2, donde expr2 debe ser una expresión regular.
La expresión regular es presentada al principio de la cadena con un împlícito. Si la
comparación tiene éxito y el patrón contiene al menos una sub expresión de la expresión
regular ¿¿VER KE VA?? se devuelve la cadena correspondiente a 1; de otra forma, el
operador comparador devuelve el número de caracteres que coinciden. Si la comparación
falla y el patrón contiene una sub expresión de la expresión regular, se devuelve una
cadena nula; sino, devuelve 0.
El analizador de Asterisk es bastante simple, solo requiere que se deje al menos un
espacio entre el operador y los otros valores. Consecuentemente, lo siguiente puede que
no funcione:
exten => 123,1,Set(TEST=$[2+1])
Acá se asignaría a la variable TEST la cadena 2+1, en lugar del valor 3. Para evitarlo,
hay que poner espacios entre el operador, como sigue:
exten => 234,1,Set(TEST=$[2 + 1])
Para concatenar texto en el principio o final de una variable, simplemente póngalo junto
en la expresión como se muestra a continuación:
exten => 234,1,Set(NEWTEST=$[blah${TEST}])

2.16.2. Funciones del dial plan

Las funciones del dial plan no son un concepto nuevo. En Asterisk 1.2, se las debe
utilizar donde sea posible. Muchas aplicaciones que realizan la misma operación que
una función dada puede eventualmente ser reemplazada por esta ultima. Las funciones le
permiten adquirir mayor potencialidad para sus expresiones. Por ejemplo, funciones del
dial plan le permiten calcular el largo de una cadena, tiempos y fechas, MD5 checksums,
y muchas cosas más, todo con una expresión dentro del dial plan.

Sintaxis

Las funciones del dial plan tienen la siguiente sintaxis:

FUNCTION_NAME(argument)
2.16 Más conceptos acerca del Dial plan 118

Como muchas variables, se hace referencia al nombre de la función como lo mostrado

arriba, pero se referencia al valor de una función con el agregado del signo pesos, un
corchete abierto, y el correspondiente cerrado:
${FUNCTION_NAME(argument)}
Las funciones pueden encapsular otras funciones:
${FUNCTION_NAME(${FUNCTION_NAME(argument)})}
Se debe tener mucho cuidado con los paréntesis y corchetes (tratando de cerrar todos
los que abrimos).

Ejemplos de funciones del dial plan

Las funciones muchas veces se utilizan junto con la aplicación Set() para obtener o
establecer el valor de una variable. Para mostrar un simple ejemplo de esto, usemos
la función LEN(). Con esta función calculamos el largo de la cadena del argumento.
Calculemos el largo de la cadena de la variable y volvamos a leer el largo:

Exten => 123,1, Set(TEST=example)

Exten => 123,2, SayNumber(${LEN(${TEST})})

En el ejemplo se valúa la cadena example a la variable TEST, esta cadena tiene 7

caracteres, luego esta cantidad de caracteres será calculada por la función LEN, y en
el último paso se le dice el numero al usuario con la aplicación SayNumber().
Las funciones disponibles pueden encontrarse mediante el comando show functions en la
interfaz de consola de Asterisk. Con esto se muestra una lista detallada de las funciones
disponibles.

2.16.3. Ramificaciones condicionales

Una vez que comprendimos un poco mas acerca de expresiones y funciones, es momento
usarlas. Por medio de expresiones y funciones, se puede agregar más lógica al dial plan.
Para permitir que el dial plan tome decisiones, se puede utilizar la división condicional.

La aplicación GotoIf()

La clave de la división condicional es la aplicación GotoIf(). Esta evalúa una expresión

y manda la llamada a un destino especificado basándose en el resultado de valuar la
expresión, verdadero o falso.
GotoIf() utiliza una sintaxis especial, algunas veces llamada sintaxis condicional:
GotoIf(expresion?destino1:destino2)
Si la expresión es verdadera, la llamada se envía al primer destino. Si la expresión es
falsa, la llamada se envía al segundo destino. Entonces, ¿que es verdadero y que es
falso? Una cadena vacía y un numero 0 son falsos. Cualquier otra cosa es verdadera.
Los destinos pueden ser cualquiera de los siguientes:
1) Una prioridad dentro de la misma expresión, como ser 10
2) Una extensión y una prioridad dentro del mismo contexto, como 123,10
2.16 Más conceptos acerca del Dial plan 119

3) Un contexto, extensión, y prioridad, como incoming,123,10

4) Una prioridad nombrada dentro de la misma extensión, como lo es passed
Alguno de los destinos puede ser omitido, pero no ambos. Si el destino omitido debe ser
seguido, Asterisk simplemente se dirige a la próxima prioridad en la extensión actual.
Veamos un ejemplo de uso de GotoIf():

exten => 345,1,Set(TEST=1)

exten => 345,2,GotoIf($[{$TEST} = 1]?10:20)
exten => 345,10,PlayBack(weasels-eaten-phonesys)
exten => 345,20,PlayBack(office-iguanas)

Cambiando el valor asignado a TEST en la primera línea, puede tener su servidor

Asterisk corriendo diferentes saludos.
Acá usamos Goto() y GotoIf() para hacer una cuenta regresiva de 10 y cortar:

exten => 123,1,Set(COUNT=10)

exten => 123,2,GotoIf($[${COUNT} > 0]?:10)
exten => 123,3,SayNumber(${COUNT})
exten => 123,4,Set(COUNT=$[${COUNT} - 1])
exten => 123,5,Goto(2)
exten => 123,10,Hangup()

En la primera prioridad, se pone el valor 10 a la variable COUNT. Luego, si COUNT

es mayor que cero vamos a la siguiente prioridad (no olvidar que si omitimos el destino
en el GotoIf(), se continua con la próxima prioridad). Desde allí se dice el número, se
resta 1 a COUNT, y luego se vuelve a la prioridad dos. Si COUNT es menor o igual
que cero, vamos a la prioridad 10, y se corta la llamada.
El ejemplo clásico de la ramificación condicional es conocido de forma afectiva como
la lógica anti-exnovia. Si el identificador de número de llamada entrante (Caller ID
number) coincide con el numero de teléfono de la ex-novia, Asterisk le da un mensaje
diferente al de cualquier otra llamada. Mientras que es un ejemplo simple y primitivo,
nos acerca un excelente ejemplo de lo que se puede hacer en un dial plan de Asterisk.

Ramificaciones condicionales basadas en el tiempo con GotoIfTime()

Otra aplicación que se puede usar en el dial plan es el GotoIfTime(). Mientras que
GotoIf() evalúa una expresión para decidir que hacer, GotoIfTime() verifica la hora del
sistema actual y usa esto para decidir si debe o no seguir una rama diferente en el dial
plan.
El uso más obvio de esta aplicación es para darle a las llamadas diferentes saludos antes
y después de las horas de trabajo.
La sintaxis para la aplicación GotoIfTime() es así:
GotoIfTime(times,days_of_week,days_of_month,months?label)
Resumiendo, GotoIfTime() envía a la llamada a una etiqueta (label) especifica si el día y
hora actual coincide con el criterio especificado por times,days_of_week,days_of_months.
Describamos cada argumento con un poco más de detalle:
2.16 Más conceptos acerca del Dial plan 120

Times : Es una lista de uno o más rangos de tiempos, en el formato de 24 horas. Como
ejemplo, 9:00 a.m. hasta 5:00 p.m. puede ser especificado como 09:00-17:00. El día
comienza a las 0:00 y termina a las 23:59.
Days_of_week : Es una lista de uno o más días de la semana. Se deben especificar los
días como mon, tue, wed, thu, fri, sat, y/o sun. Lunes a viernes se puede escribir como
mon-fri. Martes y jueves lo expresamos como tue,thu.
Days_of_month : Es una lista numérica de los días del mes. Los días se especifican por
el número desdel 1 al 31. Desdel 7 al 12 se expresaría como 7-12, y el 15 y el 30 como
15,30.
Months : Es una lista de uno o más meses del año. Los meses se escribirán como jan,
feb, mar, apr, y así.
Si lo que se necesita es que halla coincidencia en cualquiera de estos argumentos, sim-
plemente ponga un * dentro del argumento correspondiente.
El argumento label (etiqueta) puede ser alguno de los siguientes:
Una prioridad dentro de la misma expresión, como ser 10
Una extensión y una prioridad dentro del mismo contexto, como 123,10
Un contexto, extensión, y prioridad, como incoming,123,10
Una prioridad nombrada dentro de la misma extensión, como lo es passed
Ahora que vimos la sintaxis, hagamos algunos ejemplos. En este ejemplo se coincide
desde las 9:00 a.m. a las 5:59 p.m., de lunes a viernes, cualquier día del mes, en cualquier
mes del año:
Exten => s,1,GotoIfTime(09:00-17:59,mon-fri,*,*?open,s,1)
Si el usuario llama durante ese horario, la llamada se envía a la primera prioridad de
la extensión s en el contexto llamado open. Si se realiza la llamada fuera del horario
especificado, se envía a la próxima prioridad de la extensión actual. Esto le permite
de una manera fácil dividirse en múltiples horarios, como se muestra en el siguiente
ejemplo:

; Si es cualquier hora del día, en cualquier día de la semana,

; Durante el cuarto día del mes, en el mes de julio, estamos cerrados.
exten => s,1,GotoIfTime(*,*,4,jul?closed,s,1)

; Durante el horario de trabajo, mandar llamadas al contexto open

exten => s,2,GotoIfTIme(09:00-17:59|mon-fri|*|*?open,s,1)
exten => s,3,GotoIfTIme(09:00-11:59|sat|*|*?open,s,1)

; De otra forma, estamos cerrados

exten => s,4,Goto(closed,s,1)

2.16.4. Correo de voz (Voicemail)

El correo de voz es uno de los adelantos más populares de cualquier sistema telefónico
moderno. Naturalmente, Asterisk posee un sistema telefónico muy flexible. Algunos de
los adelantos que incluye el sistema de correo de voz de Asterisk son:
2.16 Más conceptos acerca del Dial plan 121

Casillas de correo de voz protegidas con clave ilimitadas, cada una de las cuales
tienen carpetas que permiten organizar el correo de voz.
Diferentes saludos para distintos estados
Saludos por defecto y personalizados
Habilidad de asociar teléfonos con más de una casilla de correo y casillas de correo
con más de un teléfono
Notificación de correo de voz por mail, con la opción de adjuntar el correo de voz
como un archivo de audio
Redireccionamiento y transmisiones de correo de voz
Indicador de mensaje en espera en muchos tipos de teléfonos
Estas son solo algunas de las cosas que se pueden configurar, mas adelante veremos otras
pero ahora nos introduciremos un poco más en los fundamentos de la configuración
típica de un correo de voz.
La configuración del correo de voz se define en el archivo voicemail.conf. Este archivo
contiene una diversidad de opciones que se pueden utilizar para personalizar el sistema
de correo de voz adaptándolo a las necesidades requeridas. Hacer énfasis en todas las
opciones que nos presenta el archivo voicemail.conf puede estar fuera del alcance de
esta sección, pero el archivo de configuración de muestra esta muy bien documentado
y es bastante fácil de seguir. Los contextos y casillas de correo de voz se definen al final
de todo en el archivo voicemail.conf.
Tal como el dial plan los contextos poseen diferentes partes separadas, los contextos
de correo de voz le permiten definir diferentes opciones de casillas de correo que están
separadas unas de otras. Esto permite guardar correo de voz de varias compañías u
oficinas en el mismo servidor. Los contextos del correo de voz son definidos de la misma
forma que los contextos del dial plan, con corchetes alrededor del nombre del contexto.

Creando casillas de correo

Dentro de cada contexto de correo de voz, se definen casillas de correo. La sintaxis para
definir casillas de correo es:
Mailbox => password,name[,email[,pager_email[,options]]]
Expliquemos que función cumple cada parte de la definición de casilla de correo:
Mailbox : es el número de casilla de correo. Usualmente se corresponde con el número
de la extensión del grupo asociado.
Password : es la clave numérica del propietario de la casilla de correo. El mismo utilizará
esta clave para acceder a su correo de voz.
Name : es el nombre de la casilla de correo del propietario. El directorio de la compañía
utiliza el texto en este campo para permitir a las personas que llaman decir sus nombres
de usuario.
Email : acá se ingresa la dirección de correo electrónico (el mail) del propietario de
la casilla de correo. Asterisk puede enviar notificaciones de correo de voz (incluyendo
el mensaje de voz como un archivo adjunto) hacia una dirección de correo electrónico
especificada.
2.16 Más conceptos acerca del Dial plan 122

Pager_email : es la dirección de correo electrónico o el teléfono celular del propietario

de la casilla de correo. Asterisk puede enviar un mensaje corto de notificación de correo
de voz a una dirección de mail específica.
Options : este campo tiene una lista de opciones que establecen la zona horaria y
muchas otras configuraciones globales de correo de voz del propietario. Existen nueve
opciones válidas: attach, serveremail, tz, saycid, review, operator, callback, dialout, and
exitcontext. Las configuraciones deben ir en pares como opción=valor, separados por el
caracter de tubería (pipe character). La opción tz establece la zona horaria del usuario a
una zona horaria previamente definida en la sección [zonemessages] de voicemail.conf.
Una casilla de correo típica tiene la siguiente definición:
101 => 1234, Joe Public, [email protected],
[email protected], tz=central|attach=yes
Continuando con el dial plan que se venía trabajando, configuremos algunas casillas de
correo de voz para John y Jane. Daremos a John la clave 1234 y a Jane 4444 (recordar
que esto va en voicemail.conf, no en extensions.conf):

[default]
101 => 1234, John Doe,[email protected],[email protected]
102 => 4444, Jane Doe,[email protected],[email protected]

Agregando el correo de voz al dial plan

Una vez creadas las casillas de correo para Jane y John, permitámosle a los usuarios
que llaman dejar un mensaje para ellos si es que no se contesta el teléfono. Para realizar
esto, usaremos la aplicación VoiceMail().
La aplicación VoiceMail() manda al usuario que llama a una casilla especifica, así puede
dejar un mensaje. La casilla de correo debe ser especificada como mailbox@context,
donde context es el nombre del contexto del correo de voz. El numero de casilla de
correo puede tener como prefijo la letra b o la letra u. Si utilizamos la letra b, el
usuario que llama escuchara el mensaje de ocupado del propietario del correo de voz.
Si utilizamos la letra u, se escuchará un mensaje de no disponible del propietario del
correo de voz (si es que existe un mensaje grabado de este tipo).
Veamos esto en un simple dial plan. Previamente, tendremos una línea como la que
sigue en nuestro contexto [internal], la cual nos permite llamar a John:
exten => 101,1,Dial(${JOHN},,r)
Bien, ahora cambiemos esto si es que John está ocupado (o en otra llamada), nos enviará
a su casilla de correo de voz, donde escucharemos su mensaje de ocupado (no olvidar
que la aplicación Dial() manda al usuario que llama a la prioridad n+101 si la línea
marcada esta ocupada):

Exten => 101,1,Dial(${JOHN,,r)

Exten => 101,102,VoiceMail(b101@default)

Luego, agregamos un mensaje de no disponible que el usuario escuchará si es que John

no contesta el teléfono luego de 10 segundos. Recordar, el segundo argumento para la
aplicación Dial() es el tiempo de espera (timeout). Si no se contesta la llamada antes de
2.16 Más conceptos acerca del Dial plan 123

que el tiempo de espera expire, la llamada se envía a la próxima prioridad. permitámosle

10 segundos de tiempo de espera, y si John no contesta a tiempo enviemos la llamada
al correo de voz de John:

exten => 101,1,Dial(${JOHN},10,r)

exten => 101,2,VoiceMail(u101@default)
exten => 101,102,VoiceMail(b101@default)

Si agregamos como argumentos estas dos nuevas prioridades y el tiempo de espera en

la aplicación Dial(), las llamadas entraran al correo de voz de John (con el apropiado
saludo) si John se encuentra ocupado o no disponible. Un pequeño problema queda
pendiente, y es la forma en que John recupera sus mensajes. Solucionemos esto a
continuación.

Accediendo al correo de voz

Los usuarios pueden ingresar al correo de voz para escuchar sus mensajes, cambiar sus
opciones de correo de voz, y grabar sus propios saludos de correo de voz por medio de
la aplicación VoiceMailMain(). De una manera particular, VoiceMailMain() se utiliza
sin ningún argumento. Agreguemos la extensión 500 al contexto [internal] de nuestro
dial plan así los usuarios internos pueden discar este número para tener acceso a sus
mensajes de correo de voz:
Exten => 500,1,VoiceMailMain()

Creando un Directorio de discado por nombre

Una de las posibilidades del voicemail de Asterisl es el directorio de discado por nombre.
Este se crea con la aplicación Directory ( ). Esta aplicación usa los nombres definidos
en las casillas de correo en voicemail.conf para presentar a la persona que llama un
directorio de discado por nombres de los usuarios.
Directoy() usa hasta tres argumentos: el contexto de voicmail desde donde leer los
nombres, el contexto opcional del dial plan al cual discar al usuario y una cadena de
opciones (que también es opcional). Por defecto, la aplicación DIrectory ( ) busca a los
usuarios por el apellido, pero si se pasa como opción la letra f, se fuerza a que busque
por nombres.
Vamos a agregar dos directorios de discado por nombres al contexto [incoming] de
manera que las personas que llamen puedan buscar tanto por nombre como por apellido:

exten => 8,1,Directory(default,incoming,f)

exten => 9,1,Directory(default,incoming)

Si presionan 8, obtendrán un directorio por nombre, si discan 9, en cambio, se les

presentará un directorio por apellidos.
2.16 Más conceptos acerca del Dial plan 124

2.16.5. Macros
Los macros son unos constructores muy útiles designados para evitar repeticiones en
el dial plan. También nos ayudan a realizar cambios en el dial plan. Para ilustrar este
punto, echémosle un vistazo a nuestro simple dial plan nuevamente. Si recordamos
los cambios que realizamos para el correo de voz, habíamos terminado en la siguiente
extensión de John:

exten => 101,1,Dial(${JOHN},10,r)

exten => 101,2,VoiceMail(u101@default)
exten => 101,102,VoiceMail(b101@default)

Ahora imaginemos que se tienen cientos de usuarios en el sistema Asterisk, configurar

todas las extensiones implicaría mucho copiar y pegar. Luego imaginemos que necesita-
mos realizar un cambio en la forma en que las extensiones trabajan. Lo que implicaría,
editar muchas líneas, y se podrían cometer muchos errores sin darnos cuenta.
En lugar de realizar esto, se puede definir un macro que contenga una lista de pasos a
tomar, y así tener todas las extensiones de los teléfonos referidas a este macro. Todo lo
que se necesita cambiar es el macro, y cualquier cosa en el dial plan que se referencia
al macro también cambiará.

Definiendo macros

Para nuestro primer macro, usaremos la lógica del dial plan que veníamos utilizando pa-
ra el correo de voz de John y lo transformaremos en un macro. Luego usaremos el macro
para darle a John y Jane (y el resto de nuestros empleados) la misma funcionalidad.
La definición de un macro se parece a definir un contexto. (En efecto, se puede discu-
tir que son pequeños, contextos limitados). Se define un macro poniendo macro- y el
nombre del macro entre corchetes, como sigue:
[macro-voicemail]
Los comandos dentro del macro son muy similares a cualquier otro en el dial plan, el
único factor limitante es que los macros solo usan la extensión s. Agreguemos la lógica
de nuestro correo de voz al macro, cambiando la extensión a s tal como a continuación:

[macro-voicemail]
exten => s,1,Dial(${JOHN},10,r)
exten => s,2,VoiceMail(u101@default)
exten => s,102,VoiceMail(b101@default)

Esto es un comienzo, pero no es perfecto, ya que sigue especificando a John y su número

de casilla de correo. Para hacer el macro más genérico, lo que no solo serviría para John
sino también para todos los demás empleados, necesitamos hacer uso de otra propiedad
de los macros: los argumentos. Antes de realizar esto, veamos como podemos llamar a
los macros en nuestro dial plan.
2.16 Más conceptos acerca del Dial plan 125

Llamando macros desde el dial plan

Para usar un macro en nuestro dial plan, nos referimos a la aplicación Macro(). Esta
misma llama al macro especificado y le pasa cualquier argumento. Por ejemplo, para
llamar a nuestro macro de correo de voz desde el dial plan, podemos realizar lo siguiente:
exten => 101,1,Macro(voicemail)
La aplicación Macro() también define muchas variables especiales para nuestro uso:

${MACRO_CONTEXT}
El contexto original en donde el macro será llamado.
${MACRO_EXTEN}
La extensión original en donde el macro será llamado.
${MACRO_PRIORITY}
La prioridad original en donde el macro será llamado.
${ARGn}
El argumento n-ésimo es pasado al macro.
Por ejemplo, el primer argumento puede ser ${ARG1}, segundo ${ARG2},etc.

Como se explicó anteriormente, la forma en que definimos inicialmente nuestro macro

para John fue codificación fija, en vez de hacerlo genérico. Cambiemos nuestro macro
para usar ${MACRO_EXTEN} en lugar de 101 como el numero de casilla de correo. De
esta forma, si llamamos al macro desde la extensión 101 los mensajes de correo de voz
irán a la casilla de correo 101, si llamamos desde la extensión 102 irán a la casilla de
correo 102, etc.

[macro-voicemail]
exten => s,1,Dial(${JOHN},10,r)
exten => s,2,VoiceMail(u${MACRO_EXTEN}@default)
exten => s,102,VoiceMail(b${MACRO_EXTEN}@default)

Utilizando argumentos en los macros

Bien, ahora estamos más cerca de tener los macros como queremos, pero aún queda una
cosa para cambiar: necesitamos pasar el canal a llamar, como definimos con codificación
fija para ${JOHN}(recordemos que definimos la variable JOHN como el canal a llamar
cuando queramos contactar a John). Permitamos pasar el canal como un argumento, y
así nuestro primer macro estará completo:

[macro-voicemail]
exten => s,1,Dial(${ARG1},10,r)
exten => s,2,VoiceMail(u${MACRO_EXTEN}@default)
exten => s,102,VoiceMail(b${MACRO_EXTEN}@default)

Ahora que tenemos al macro terminado, utilicémoslo en nuestro dial plan. Aquí es
donde podemos llamar a nuestro macro para darle a John, Jane y Jack correo de voz:

exten => 101,1,Macro(voicemail,${JOHN})

exten => 102,1,Macro(voicemail,${JANE})
exten => 103,1,Macro(voicemail,${JACK})
2.16 Más conceptos acerca del Dial plan 126

Con 50 o más usuarios, este dial plan se verá compacto y organizado. Simplemente
tenemos una línea por usuario, referenciándolo a un macro que puede ser tan complicado
como se requiera. Podemos también tener algunos diferentes macros para varios tipos
de usos, como ser ejecutivos, telefonos_de_cortesia, agentes_call_center,
sets_analogos, dept_ventas, etc.

2.16.6. Usando la base de datos Asterisk (AstDB)

Asterisk provee un poderoso mecanismo para guardar valores, llamado la base de datos
Asterisk (AstDB). AstDB provee una forma simple de guardar datos para utilizar con
nuestro dial plan.
La base de datos Asterisk almacena sus datos agrupándolos en familias, con valores
identificados por llaves. Dentro de una familia, una llave puede usarse solo una vez. Por
ejemplo, si tenemos una familia llamada test, solo podremos almacenar un valor con la
llave llamada count. Cada valor almacenado debe estar asociado a una familia.

Almacenando datos en AstDB

Para almacenar un nuevo valor en la base de datos de Asterisk, usamos la aplicación

Set(), pero en lugar de usar ésta para establecer la variable de canal, la usamos para
establecer una variable AstDB. Por ejemplo, para asignar la llave count en la familia
test con el valor 1:
exten => 456,1,Set(${DB(test/count)=1})
Si una llave llamada count existe en la familia test, su valor será sobrescrito con el
nuevo valor. También puede almacenar datos desde la línea de comandos de Asterisk,
por medio del comando database put family key value. Veámoslo para nuestro ejemplo,
deberá tipear database put test count 1.

Recuperando datos desde la AstDB

Para recuperar un valor desde la base de datos de Asterisk y asignarlo a una variable,
usamos la aplicación Set() nuevamente. Permitamos recibir el valor de count (nueva-
mente, desde la familia test), asignándoselo a la variable COUNT, y luego digámosle el
valor al usuario:

exten => 456,1,Set(DB(test/count)=1)

exten => 456,2,Set(COUNT=${DB(test/count)})
exten => 456,3,SayNumber(${COUNT})

Podrá ver el valor de una llave determinada desde la línea de comando de Asterisk
mediante el comando database get family key. Para ver todos los contenidos de AstDB,
use el comando database show.

Borrando datos desde la AstDB

Existen dos formas de borrar datos de la base de datos Asterisk. Para borrar una llave,
usar DBdel(). La misma toma como argumento la familia y la llave, como sigue:
2.16 Más conceptos acerca del Dial plan 127

exten => 457,1,DBdel(test/count)

También puede borrar una familia entera mediante el uso de la aplicación DBdeltree().
La aplicación DBdeltree() toma un simple argumento: el nombre clave de la familia a
borrar. Para eliminar por completo la familia test, debe realizar lo siguiente:
exten => 457,1,DBdeltree(test)
Para realizar lo mismo pero por línea de comando como interfase, use database del key
y database deltree family respectivamente.

Utilizando AstDB en el dial plan

Existen un número infinito de maneras para usar la base de datos Asterisk en un

dial plan. Para introducirnos mostraremos unos ejemplos muy simples. El primero un
sencillo ejemplo de conteo que muestra que la base de datos Asterisk es persistente
(significando esto que sobrevive a reinicios del sistema). En un segundo ejemplo, usa-
remos la aplicación LookupBlacklist() para evaluar si un número está o no está en la
lista negra y debería ser bloqueado.
Comencemos con el ejemplo de conteo, recuperemos un número (el valor de la llave
count) desde la base de datos y asignémoslo a una variable llamada COUNT. Si la llave
no existe, DBget() nos enviará a la prioridad n+101, donde pondremos el valor en 1.
La próxima prioridad nos enviará de regreso a la prioridad 1. Esto ocurrirá realmente
la primera vez que discamos esa extensión:

exten => 678,1,Set(COUNT=${DB(test/count)})

exten => 678,102,Set(DB(test/count)=1)
exten => 678,103,Goto(1)

Luego, diremos el valor actual de COUNT e incrementaremos COUNT:

exten => 678,1,Set(COUNT=${DB(test/count)})

exten => 678,2,SayNumber(${COUNT})
exten => 678,3,Set(COUNT=$[${COUNT} + 1])
exten => 678,102,Set(DB(test/count)=1)
exten => 678,103,Goto(1)

Ahora que incrementamos COUNT, pongamos nuevamente el nuevo valor en la ba-

se de datos. Recordemos que almacenar un valor para una llave existente implicará
sobrescribir el valor anterior:

exten => 678,1,Set(COUNT=${DB(test/count)})

exten => 678,2,SayNumber(${COUNT})
exten => 678,3,Set(COUNT=$[${COUNT} + 1])
exten => 678,4,Set(DB(test/count)=${COUNT})
exten => 678,102,Set(DB(test/count)=1)
exten => 678,103,Goto(1)

Finalmente, volveremos a la primera prioridad. De esta forma, la aplicación continuará

contando:
2.16 Más conceptos acerca del Dial plan 128

exten => 678,1,Set(COUNT=${DB(test/count)})

exten => 678,2,SayNumber(${COUNT})
exten => 678,3,Set(COUNT=$[${COUNT} + 1])
exten => 678,4,Set(DB(test/count)=${COUNT})
exten => 678,5,Goto(1)
exten => 678,102,Set(DB(test/count)=1)
exten => 678,103,Goto(1)

Continuemos con el próximo ejemplo. Acá creamos una lógica de dial plan en torno a la
aplicación LookBlacklist(), la cual verifica si se encuentra el número del identificador de
llamada (Caller ID) en la lista negra (la lista negra es simplemente una familia llamada
blacklist en la AstDB). Si LookupBlacklist() encuentra el numero en su lista, envía
la llamada a la prioridad n+101. De otra forma, la llamada continúa con la próxima
prioridad:

exten => 124,1,LookupBlacklist()

exten => 124,2,Dial(${JOHN})
exten => 124,102,Playback(privacy-you-are-blacklisted)
exten => 124,103,Playback(vm-goodbye)
exten => 124,104,Hangup()

Para agregar un nuevo número a la lista negra, corra el comando database put blacklist
number 1 desde la interfaz de línea de comando de Asterisk.

2.16.7. Adelantos prácticos de Asterisk

Zapateller()

Zapateller() es una simple aplicación Asterisk que ejecuta un tono especial de informa-
ción al comienzo de una llamada, que causa que los auto-diallers (comúnmente usados
por telemarketers) piensen que la línea ha sido desconectada. No solamente evitará esta
molestia, sino que sus sistemas marcaran su número como si estuviera fuera de servicio,
lo cual ayudará mucho a evitar toda clase de llamadas de telemarketing.
Para usar esta funcionalidad en su dial plan, simplemente llame a la aplicación Zapa-
teller().
También utilizamos la opción nocalerid por esto el tono se ejecutará solo cuando no
halla información de identificador de llamada en la llamada entrante. Por ejemplo,
podría usar Zapateller() en la extensión s de su contexto [incoming] de la siguiente
forma:

[incoming]
exten => s,1,Zapateller(nocallerid)
exten => s,2,Playback(enter-ext-of-person)

Estacionamiento de llamadas

Otro adelanto práctico es llamado estacionamiento de llamada. El estacionamiento de

llamada le permite poner una llamada en espera en un espacio de estacionamiento,
2.16 Más conceptos acerca del Dial plan 129

así de esta forma puede salir de espera por otra extensión. Los parámetros para el
estacionamiento de llamada (como la extensión a usar, el número de espacios, y otras
más) se controlan por medio de la configuración del archivo features.conf. La sección
[general] del archivo features.conf contiene cuatro configuraciones relacionadas con el
estacionamiento de una llamada:
1) Parkext: es la extensión de espacio de estacionamiento. Transfiera una llamada a
esta extensión, y el sistema le dirá cuál posición de estacionamiento le corresponde a
la llamada. Por defecto, la extensión de estacionamiento es 700.
2) Parkpos: esta opción define el número de espacios de estacionamiento. Por ejemplo,
configurándolo desde 701-720 se crean 20 posiciones de estacionamiento, numeradas
desde la 701 a la 720.
3) Context: es el nombre del contexto de estacionamiento. Para poder estacionar lla-
madas, se debe incluir este contexto.
4) Parkingtime: si se activa, esta opción controla cuanto tiempo (en segundos) una
llamada puede permanecer en el espacio de estacionamiento. Si la llamada no es recogida
dentro del tiempo especificado, la extensión que la estacionó será llamada nuevamente.
También note que debido a que el usuario necesita transferir llamadas a la extensión
de espacio de estacionamiento, se debe asegurar que utilice las opciones t y/o T de la
aplicación Dial().
Creemos un simple dial plan para mostrar todo lo anterior:

[incoming]
include => parkedcalls

exten=103,1,Dial(SIP/Bob,,tT)
exten=104,1,Dial(SIP/Charlie,,tT)

Para ilustrar como funciona esto, diremos que Alicia llama dentro del sistema y marca
la extensión 103, para alcanzar a Bob. Luego de un tiempo, Bob transfiere la llamada
a la extensión 700, que le dice a él que la llamada de Alicia ha sido estacionada en la
posición 701. Bob entonces llama a Charlie a la extensión 104, y le dice a él que Alicia
está en la extensión 701. Charlie entonces marca la extensión 701, y comienza a charlar
con Alicia. Este es un modo simple y efectivo de permitir a los usuarios transferirse
llamadas entre ellos.

Conferencias con MeetMe()

Veremos ahora la configuración de una conferencia de audio enlazada por la aplicación

MeetMe(). Esta aplicación le permite a múltiples llamadas converger todas juntas, como
si estuvieran en la misma localidad. Algunas de las principales ventajas son:
La habilidad de crear conferencias protegidas por claves.
Administración de conferencias (sacar participantes, silenciar conferencias, trabar
conferencias)
La opción de silenciar todos o algunos de los participantes
Creación de conferencias estáticas o dinámicas
2.17 Codecs y Protocolos de VoIP 130

Empecemos a ver como configurar un cuarto de conferencias. Las opciones de configu-

ración para el sistema de conferencias Meetme() se encuentran en meetme.conf. Dentro
del archivo de configuración, se definen cuartos de conferencias y opcionalmente cla-
ves numéricas. Si una clave se define aquí, se requerirá de ésta para entrar en todas
las salas de conferencias. Para nuestro ejemplo, configuremos una sala de conferencias
para la extensión 600. Primero, configuremos la sala de conferencia en meetme.conf.
Llamaremos al 600, y no asignaremos clave por ahora:

[rooms]
conf => 600

Ahora que el archivo de configuración esta completo, necesitamos reiniciar Asterisk

para que se pueda leer el archivo meetme.conf. Luego, agregaremos soporte para la
sala de conferencias a nuestro dial plan con la aplicación MeetMe(). La misma toma
tres argumentos: el nombre de la sala de conferencias (como se define en meetme.conf),
algunas opciones, y la clave que el usuario debe ingresar para unirse a la conferencia.
Configuremos una simple sala de conferencias usando 600, la opción 1 (que anuncia
cuando la gente ingresa y se va de la conferencia), y como clave 54321:
Exten => 600,1,MeetMe(600,i,54321)
Eso es todo. Cuando se llame a la extensión 600, se les pedirá la clave. Si ingresan
correctamente 54321, se agregaran a la conferencia.
Otra aplicación muy útil es MeetMeCount(). Como lo dice su nombre, esta aplicación
cuenta el número de usuarios de una sala de conferencias en particular. Toma solo dos
argumentos: la sala de conferencia en donde se contará el número de participantes, y
opcionalmente un nombre variable para asignar la cuenta. Si el nombre no se pasa como
segundo argumento, la cuenta se lee para la persona que llama:

Exten => 601,1,Playback(conf-thereare)

Exten => 601,2,MeetMeCount(600)
Exten => 601,3,Playback(conf.peopleinconf)

Si se le pasa como segundo argumento una variable a MeetMeCount(), el conteo se

le asigna a la variable y la reproducción de ésta se saltea. podría usar esto como un
limitante del número de participantes de una sala como sigue:

; limitar la sala de conferencias a 10 participantes

exten => 600,1,MeetMeCount(600,CONFCOUNT)
exten => 600,2,GotoIf($[${CONFCOUNT} <= 10]?3:100)
exten => 600,3,MeetMe(600,i,54321)
exten => 600,100,Playback(conf-full)

2.17. Codecs y Protocolos de VoIP

La industria de las telecomunicaciones se ha expandido durante los últimos 100 años, y
Asterisk integra las principales tecnologías que se han usado durante este último siglo.
Para aprovechar al máximo Asterisk, no se necesita ser un profesional en todas las áreas,
pero entender que las diferencias entre los distintos CODEC y protocolos brindará una
mayor apreciación y entendimiento del sistema en su conjunto.
2.18 La Necesidad de Protocolos VoIP 131

Se explicará por lo tanto, VoIP y que es lo que hace a las redes de VoIP diferentes de
las redes de voz de conmutación de circuitos tradicionales. Se explorará la necesidad de
protocolos VoIP, describiendo la historia y potencial futuro de cada uno. También se
harán consideraciones sobre la seguridad y capacidad de estos protocolos para trabajar
dentro de topologías que utilizan NAT. Se describirán los siguientes protocolos de VoIP:
IAX
SIP
H.323
MGCP
Skinny/SCCP
UNISTIM
Los CODEC son los medios por los cuales la voz análoga puede ser convertida a una
señal digital y llevada a través de Internet. La amplitud de banda en cualquier posición
es finita, y el número de conversaciones simultáneas que cualquier conexión particular
puede llevar está directamente relacionado con el tipo de codec implementado. Por lo
tanto, exploraremos las diferencias entre los codecs (G.711, G.726, G.723.1, G.729A,
GSM, iLBC, Speex, MP3, etc.) en cuanto a exigencias de amplitud de banda (nivel de
compresión) y calidad.

2.18. La Necesidad de Protocolos VoIP

La premisa básica de VoIP es la paquetización de corrientes de audio para el transporte
a través de las redes basadas en protocolos de Internet. Los desafíos para conseguir esto
están relacionados con la manera en la cual las personas se comunican. No sólo la señal
debe llegar esencialmente de la misma forma que fue transmitida, sino que además lo
tiene que hacer así en menos de 300 milisegundos. Si los paquetes se pierden o retrasan,
habrá una degradación en la calidad de la comunicación.
Los protocolos de transporte que colectivamente son llamados Internet no fueron di-
señados con la transmisión de servicios en tiempo real en mente. Se esperaba que los
puntos extremos resolvieran la pérdida de paquetes esperando un tiempo determinado
para que lleguen, solicitando retransmisión, o, en algunos casos, considerando que la
información se ha ido para siempre y simplemente continuando sin ella. En una con-
versación de voz típica, estos mecanismos no van a servir. Las conversaciones no se
adaptan bien a la pérdida de letras o palabras, ni a ninguna tardanza apreciable entre
transmisión y recepción.
La red PSTN tradicional fue diseñada expresamente para la transmisión de voz y ha
logrado perfectamente la tarea desde un punto de vista técnico. Desde un punto de
vista técnico flexible, sin embargo, sus defectos son obvios hasta para gente con un
muy limitado entendimiento de la tecnología. VoIP sostiene la promesa de incorporar
las comunicaciones de voz en todos los otros protocolos que se utilizan en las redes,
pero debido a las demandas especiales de una conversación de voz, se requiere diseñar,
construir y mantener habilidades especiales en las mismas.
El problema con la transmisión de voz basada en conmutación de paquetes proviene del
hecho de que la forma en que hablamos es totalmente incompatible con la forma en que
IP transporta los datos. Hablar y escuchar consiste en la transmisión de una corriente
2.18 La Necesidad de Protocolos VoIP 132

de audio, mientras que los protocolos de Internet son diseñados para cortar todo en
pedazos, encapsular los trozos de información en miles de paquetes y luego entregar
cada paquete a través de cualquier camino posible al punto lejano. Claramente, se
necesita algún tipo de puente.

2.18.1. Protocolos de VoIP

El mecanismo para establecer una comunicación de VoIP generalmente implica una serie
de transacciones de señalización entre los puntos extremos (y gateways entre medio),
culminando en dos corrientes de servicio persistentes (una para cada dirección) que
llevan la conversación actual. Hay varios protocolos existentes para manejar esto. En
esta sección, hablaremos de aquellos que son importantes para VoIP en general y para
Asterisk expresamente.

IAX (Protocolo de Intercambio Inter - Asterisk)

IAX es un protocolo abierto, lo cual significa que cualquiera puede descargarlo y utili-
zarlo, pero no es todavía un estándar.
En Asterisk, IAX es provisto por el módulo chan_iax2.so.
Historia
El protocolo IAX fue desarrollado por Digium para la comunicación entre servidores
Asterisk (de ahí el Protocolo de Intercambio Inter-Asterisk). IAX es un protocolo de
transporte (como SIP) que usa un solo puerto UDP (4569) para ambos canales, el de
señalización y el de corrientes RTP. Esto hace más fácil trabajar detrás de un firewall
y NAT.
IAX también tiene la capacidad única de establecer (trunking) sesiones múltiples en un
único flujo de datos, que puede ser una ventaja de ancho de banda tremenda cuando se
envían muchos canales simultáneos a una caja remota. El Trunking permite que corrien-
tes de datos múltiples sean representadas con solo un encabezado de datagrama, para
bajar el elevado embotellamiento asociado con estos canales individuales. Esto ayuda a
bajar la latencia y reducir el procesamiento y el ancho de banda requerido, permitien-
do al protocolo escalar más fácilmente con un número grande de canales activos entre
puntos extremos.
Futuro
Ya que IAX fue optimizado para la voz, ha recibido un poco de críticas por no proveer
de la misma forma vídeo (pero de hecho, IAX sostiene el potencial para llevar más o
menos cualquier corriente de datos multimedia deseada). Como es un protocolo abierto,
los futuros tipos de servicios seguramente serán incorporados cuando la comunidad los
requiera.
IAX y NAT
El protocolo IAX2 fue deliberadamente diseñado para trabajar detrás de dispositivos
NAT. El uso de un puerto UDP tanto para señalización como para transmisión de
media también lleva el número de huecos requeridos en el firewall al mínimo. Estas
consideraciones han ayudado a hacer de IAX uno de los protocolos más fáciles (si no el
más fácil) para implementar en redes seguras.
2.18 La Necesidad de Protocolos VoIP 133

SIP

El Protocolo de Iniciación de Sesión (SIP) ha tomado al mundo de VoIP por sorpresa. Al

principio considerado un poco más que una idea interesante, SIP ahora parece decidido
a destronar el fuerte H.323 como el protocolo VoIP elegido (en los puntos extremos
de la red). La premisa de SIP es que cada terminal de una conexión es un par y el
protocolo negocia capacidades entre ellos. Lo que hace a SIP irresistible es que sea un
protocolo relativamente simple, con una sintaxis similar a aquellos protocolos familiares
como HTTP y Simple Mail Transfer Protocol (SMTP).
SIP es proveído en Asterisk con el módulo chan_sip.so.
Historia
SIP fue al principio presentado por el Internet Engineering Task Force (IETF) en febrero
de 1996 como "draft-ietf-mmusic-sip-00". El esbozo inicial no se parece en nada al SIP
que conocemos hoy y contenía sólo una solución para la iniciación de llamadas. En
marzo de 1999, después de 11 revisiones, SIP RFC 2543 nació.
Al principio, SIP fue casi ignorado, cuando H.323 fue considerado el protocolo de op-
ción para la negociación de transporte VoIP. Sin embargo, a medida que .el boca en
bocaçreció, SIP comenzó a ganar popularidad, y mientras pueden haber muchos facto-
res diferentes que aceleraron su crecimiento, nos gustaría pensar que una gran parte de
su éxito es debido a su especificación libremente disponible.
Futuro
SIP ha ganado su lugar como el protocolo que justificó VoIP. Se espera que todo nuevo
producto para usuarios y empresas provea SIP y cualquier producto existente será ahora
difícil de vender a menos que una adaptación a SIP sea ofrecida. Se espera extensamente
que SIP entregue mucho más que capacidades VoIP, incluso la capacidad de transmitir
vídeo, música y cualquier tipo de multimedia de tiempo real. SIP está posicionado para
entregar la mayoría de las nuevas aplicaciones durante los próximos años.
SIP Y NAT
Probablemente la barrera técnica más grande que tiene que vencer SIP es el desafío
de transportar transacciones a través de una capa NAT. Como SIP encapsula la in-
formación de dirección en sus marcos de datos y el NAT funciona en una capa de red
inferior, la información de dirección no es modificada y así las corrientes de datos mul-
timedia no tendrán la información de dirección correcta para completar la conexión
cuando un NAT este configurado. Además de esto, los firewall normalmente integrados
con NAT no considerarán las corrientes de datos multimedia entrantes para ser parte
de la transacción SIP y bloquearán la conexión.

H.323

Este protocolo de la International Telecomunication Union (ITU) fue al principio di-

señado para proporcionar un mecanismo IP para transportar comunicación de vídeo.
Se ha convertido de hecho en el estándar para equipamiento de comunicación de vídeo
basado en IP y disfrutó brevemente de la fama como un protocolo de VoIP. Mientras
hay un debate muy arduo sobre si SIP o H.323 (o IAX) dominará el mundo de los
protocolos VoIP, en Asterisk, H.323 ha sido en gran parte destronado a favor de IAX
y IP. H.323 no ha disfrutado de mucho éxito entre usuarios y empresas, aunque sea
todavía el protocolo VoIP más extensamente usado entre portadoras.
2.18 La Necesidad de Protocolos VoIP 134

Las dos versiones de H.323 proveídas en Asterisk son manejadas por los módulos
chan_h323.so (suministrado en Asterisk) y chan_oh323.so (disponible como un com-
plemento libre).
Historia
H.323 fue desarrollado por la ITU en mayo de 1996 como un medio para transmitir
voz, vídeo, datos y comunicaciones de fax a través de una red IP conectada a la red
PSTN. Desde aquel tiempo,H.323 ha pasado por varias versiones y anexos (que aña-
den funcionalidad al protocolo), permitiendo funcionar en redes IP puras y redes más
extensamente distribuidas.
Futuro
El futuro de H.323 es sujeto de un arduo debate. Si los servicios sirven de medida, el
futuro no luce nada bien para H.323; casi nunca es mencionado (seguramente no con la
regularidad que se menciona a SIP). H.323 es comúnmente considerado técnicamente
superior a SIP, pero, como con tantas otras tecnologías, esto parece no importar. Uno
de los factores que hace a H.323 impopular es su complejidad.
H.323 todavía lleva por mucho la mayoría del tráfico VoIP de portadora, pero mientras
la gente se convierta en menos y menos dependiente de las portadoras tradicionales para
sus necesidades de telecomunicaciones, el futuro de H.323 se hace más difícil de predecir.
Mientras H.323 puede no ser el protocolo de opción para nuevas implementaciones,
seguramente por algún tiempo más vamos a tener que trabajar en la interoperabilidad
con H.323.
H.323 y NAT
El estándar H.323 utiliza el protocolo RTP para transportar media entre puntos ex-
tremos. A causa de esto, H.323 tiene los mismos problemas que SIP al trabajar con
topologías de red que implican un NAT. El método más fácil es simplemente pasar los
puertos apropiados a través del dispositivo NAT al cliente interno.
Para recibir llamadas, siempre se tendrá que pasar el puerto TCP 1720 al cliente.
Además, se tendrá que pasar los puertos UDP para RTP y Real Time Control Protocol
(RTCP) (hay que ver el manual del dispositivo para la variedad de puertos que requiere).
Clientes más viejos, como MSN, también requerirán puertos TCP para túneles (H.245)
(otra vez, ver el manual del cliente para la variedad de números de puerto).
Si se tiene a varios clientes detrás del dispositivo NAT, se tendrá que usar un gatekeeper
corriendo en modo Proxy. El gatekeeper requerirá una interfaz conectada a la subred
IP privada e Internet. El cliente H.323 en la subred IP privada se registrará entonces al
gatekeeper, que va a procesar las llamadas de los clientes. Nótese que cualquier cliente
externo que desee llamar deberá registrarse con el servidor Proxy.
Actualmente, Asterisk no puede actuar como un gatekeeper H.323. Se tendrá que usar
una aplicación aparte, como el Open H323 Gatekeeper de código abierto
http://www.gnugk.org.

MGCP

El Media Gateway Control Protocol (MGCP) también viene del IETF. Mientras el
despliegue MGCP es más extenso de lo que uno podría pensar, está perdiendo rápida-
mente terreno frente a protocolos como SIP y IAX. De todos modos, Asterisk ama los
protocolos, por lo que naturalmente lo provee rudimentariamente.
2.19 Codecs 135

El MGCP es definido en RFC 3435. Fue diseñado para hacer los dispositivos terminales
(como los teléfonos) tan simples como fuera posible y que tengan toda la lógica de
llamada y procesamiento manejado por gateways y agentes de llamada. A diferencia
de SIP, MGCP usa un modelo centralizado. Los teléfonos MGCP no pueden llamar
directamente a otros teléfonos MGCP; ellos siempre deben pasar por algún tipo de
regulador.
Asterisk provee MGCP a través del módulo chan_mgcp.so y los puntos extremos es-
tán definidos en el archivo de configuración mgcp.conf. Ya que Asterisk proporciona
sólo servicio básico de llamada de agente, no puede emular un teléfono MGCP (para
registrarse a otro regulador MGCP como un agente de usuario, por ejemplo).

Protocolos Patentados

Finalmente, vamos a mencionar dos protocolos patentados que son provistos por Aste-
risk.
Skinny/SCCP
El Skinny Client Control Protocol (SCCP) está patentado por Cisco. Es el protocolo
por defecto para puntos extremos en un Gerente de Llamada PBX de Cisco. Skinny es
provisto por Asterisk, pero si se unen teléfonos de Cisco al sistema, se recomienda que
se obtengan imágenes SIP para cualquier teléfono que provea y se conecten vía SIP.
UNISTIM
Como protocolo VoIP patentado por Nortel, UNISTIM, ha sido añadido recientemente
en Asterisk. Esto significa que Asterisk es la primer PBX en la historia en apoyar
nativamente terminales IP patentadas de los dos jugadores más grandes en VoIP, Nortel
y Cisco.

2.19. Codecs
Se entiende generalmente que CODEC son varios modelos matemáticos usados para
codificar digitalmente (y comprimir) la información de audio análoga. Muchos de es-
tos modelos toman en consideración la capacidad del cerebro humano de formar una
impresión a partir de información incompleta. Todos hemos visto ilusiones ópticas;
igualmente, los algoritmos de compresión de voz toman la ventaja de nuestra tendencia
de interpretar lo que creemos que deberíamos oír, más que lo que realmente oímos.
El objetivo de los algoritmos de codificación es balancear el equilibrio entre eficacia y
calidad.
Al principio, el término CODEC se refiere a un COder/DECoder: un dispositivo que
convierte señales entre análogo y digital. Ahora, el término parece estar relacionado
más con la COMPRESIÓN/DESCOMPRESIÓN.
Antes de que ahondemos en los CODEC individuales, en la tabla 2.2 se muestra una
referencia rápida de las características de los CODEC.

2.19.1. G.711
El G.711 es el CODEC fundamental de PSTN. De hecho, si alguien se refiere a PCM con
respecto a una red telefónica, le permiten pensar en G.711. Dos métodos de expansión
2.19 Codecs 136

Codec Data bitrate(kbps) ¿Necesita Licencia?

G.711 64 kbps No
G.726 16,24,or 32 kbps No
G.723.1 5.3 or 6.3 kbps Si(no para atravesarlo)
G.729A 8 kbps Si(no para atravesarlo)
GSM 13 kbps No
iLBC 13.3 kbps(30-ms frames) or 15.2 kbps(20-ms frames) No
Speex Variable (entre 2.15 y 22.4 kbps) No

Tabla 2.2: Referencia rápida de codecs

son usados: Ley µ en Norteamérica y Ley A en el resto del mundo. El uno o el otro
entrega una palabra de 8 bits transmitida a 8.000 ciclos por segundo. Si se hacen las
matemáticas, se verá que este requiere que 64.000 bits sean transmitidos por segundo
(64kbps).
Muchas personas dirán que G.711 es un CODEC no compresor. Esto no es exactamente
verdadero, ya que la expansión es considerada una forma de compresión. Lo que es
verdadero es que G.711 es el CODEC base del cual todos los demás se derivan.

2.19.2. G.726
Este CODEC ha estado alrededor durante algún tiempo (solía ser G.721, que está ob-
soleto ahora), y es uno de los CODEC originales. También es conocido como Adaptable
Diferencial Pulse Code Modulation (APCM), y puede correr a varios bits por segun-
do. Las velocidades más comunes son 16 kbps, 24 kbps y 32 kbps. En este momento,
Asterisk provee sólo APCM-32, que es por mucho la velocidad más popular para este
CODEC.
El G.726 ofrece una calidad casi idéntica a G.711, pero usa sólo la mitad del ancho de
banda. Esto es posible porque lejos de enviar el resultado de la cuantificación, envía
sólo la información necesaria para describir la diferencia entre la corriente de bits actual
y la previa. El G.726 fracasó en los años 1990 debido a su inhabilidad de llevar señales
de módem y FAX, pero debido a su performance de ancho de banda y uso de CPU
hace ahora una reaparición. El G.726 es sobre todo atractivo porque no requiere mucho
trabajo computacional del sistema.

2.19.3. G.723.1
Para no confundirse con G.723 (que es otra versión obsoleta de APCM), este CODEC
fue diseñado para habla de baja tasa de bits. Tiene dos tasas: 5.3 kbps y 6.3 kbps.
G.723.1 es uno de los CODEC requeridos por su compatibilidad con H.323 (aunque otros
Codecs puedan ser empleados por H.323). Es actualmente obstaculizado por patentes
y requiere de licencia para ser usado en aplicaciones comerciales. Lo que significa que si
bien se puede conmutar dos llamadas G.723.1 por Asterisk, no se permiten decodificarlos
sin una licencia.
2.19 Codecs 137

2.19.4. G.729A
Considerando el poco ancho de banda que usa, G.729A entrega una calidad de sonido
impresionante. Esto se logra a partir del uso de Conjugate-Structure Algebraic-Code-
Excited Linear Prediction (CS-ACELP). A causa de las patentes, no se puede usar
G729A sin pagar una licencia; sin embargo, es muy popular y provisto en muchos
teléfonos y sistemas.
Para conseguir su impresionante radio de compresión, este codec requiere un igualmente
impresionante esfuerzo del CPU. En un sistema Asterisk, el uso de codecs pesados
atascará rápidamente el CPU.
El G.729A usa 8 kbps de ancho de banda.

2.19.5. GSM
GSM es el CODEC más querido por Asterisk. Este CODEC no viene estorbado por
una exigencia de licencia como G.723.1 y G.729A, y ofrece una excepcional performance
con respecto a la demanda de trabajo en el CPU. La calidad de sonido es generalmente
considerada de un grado menor que G.729A.
El GSM opera en 13 kbps.

2.19.6. iLBC
El CODEC de Internet Low Bitrate Codec (iLBC) proporciona una mezcla atractiva
de bajo ancho de banda baja y calidad, y brinda una calidad razonable en redes que
presentan vínculos débiles.
Naturalmente, Asterisk lo provee, pero no es tan popular como los CODEC ITU y así
puede no ser compatible con teléfonos IP comunes y sistemas de VoIP comerciales. Los
IETF RFCs 3951 y 3952 han sido publicados en apoyo a iLBC, e iLBC está en la lista
de estándares IETF.
Como iLBC usa algoritmos complejos para conseguir sus niveles altos de compresión,
tiene un uso bastante alto de CPU en Asterisk.
Mientras se permite usar iLBC sin pagar honorarios de derechos, el dueño de la patente
de iLBC, Global IP Sound (GIPS), quiere saber siempre cuando se lo usa en una
aplicación comercial. La forma de hacer esto es descargando e imprimiendo una copia
de la licencia de iLBC, firmando y devolviéndolo.
iLBC funciona en 13.3 kbps y 15.2 kbps.

2.19.7. Speex
Speex es un CODEC Variable BitRate (VBR), lo que significa que es capaz de diná-
micamente modificar su tasa para responder a las condiciones cambiantes de la red. Es
ofrecido en las versiones de banda estrecha y de banda ancha.
Speex puede funcionar en cualquier punto desde 2.15 a 22.4 kbps, debido a su tasa
variable.
2.20 Panorama de Asterisk 138

2.19.8. MP3
MP3 es un CODEC. Expresamente, es el Codificador de Audio 3 del Grupo de Expertos
de Imágenes en Movimiento. En Asterisk, el codec MP3 es típicamente usado para
música en espera MOH. MP3 es una optimización para música, no es un CODEC de
telefonía; sin embargo, es muy popular en sistemas de telefonía VoIP como un método
de entregar música en espera.

2.20. Panorama de Asterisk

El hecho de que un cliente puede necesitar cinco de cien funcionalidades es normalmente
ignorado y el deseo del cliente de tener esas cinco funcionalidades que no están dispo-
nibles se rechaza como si fuese irracional. Hasta que la flexibilidad sea un estándar, las
telecomunicaciones van a quedar estancadas en el siglo pasado.
Asterisk soluciona ese problema de manera directa y lo hace de una manera en la que
muy pocos sistemas de telecomunicaciones pueden. Esta es una tecnología totalmente
disruptiva, en gran parte porque se basa en conceptos que han sido probados una y
otra vez; el mundo del código cerrado no puede ganar una carrera evolutiva contra las
comunidades open-source que pueden poner cantidades de tiempo muy superiores en
un problema.

2.20.1. Desafíos
Como suele suceder con cualquier cosa que valga la pena, Asterisk debe enfrentar ciertos
desafíos, a continuación se discuten algunos de ellos.

Demasiados cambios y pocos estándares.

En la actualidad Internet cambia demasiado rápido y ofrece mucha diversidad de conte-

nido; incluso hasta para los más asiduos fanáticos resulta imposible estar en la cresta de
la ola. En buena hora que esto suceda, pero también implica que exista un gran volumen
de tecnología en permanente cambio para poder mantener los sistemas actualizados.

Spam VoIP

Aunque parezca increíble pero es cierto. Siempre existirán personas que se creen con el
derecho de molestar a los demás en su afán de dinero. Existen fuertes esfuerzos para
evitar esta situación, pero solo el tiempo va a decir cuán eficaces resultan.

Ingeniería de bloqueo

Hay rumores que las mayores empresas de servicio de networking van a comenzar a
limitar artificialmente el trafico VoIP marcando y priorizando el tráfico de sus servicios
Premium VoIP y saboteando el tráfico VoIP de otros servicios no aprobados por ellos.
Algo de esto ya está teniendo lugar, con proveedores bloqueando tráfico de ciertos tipos
en sus redes. En los Estado Unidos, la Federal Communications Commission (FCC) ha
2.20 Panorama de Asterisk 139

puesto multas a compañías que propician dichas prácticas. En el resto del mundo, los
entes reguladores no siempre están tan abiertos a aceptar tráfico VoIP.
De cualquier manera, siempre existe la esperanza que la comunidad y la red van a
encontrar una manera para evitar los bloqueos, tal como sucede siempre.

QoS

Dado el principio de entrega con mayor esfuerzo de la Internet, basada en TCP-IP, aún
no está claro como impactará un tráfico creciente de VoIP en el funcionamiento global
de la red. Actualmente, hay todavía mucha capacidad excedente de ancho de banda en
los backbones de manera que la entrega con mejor esfuerzo funciona muy bien.
De cualquier manera, está probado que tan pronto se nos provee con más ancho de
banda en breve encontramos la manera de usarlo al límite de su capacidad. Hace cinco
años atrás una conexión DSL de un 1MB era algo soñado pero hoy parece apenas
satisfacer las necesidades.

Redes de telecomunicaciones personalizadas

Algunas personas dirán que el precio es la clave, pero la verdadera razón del éxito de
Asterisk es que es posible construir un sistema de telecomunicaciones de igual manera
que se construye un sitio Web: con total y absoluta personalización para cada faceta del
sistema. Los clientes lo han pedido por años y ahora Asterisk al fin provee la solución.

2.20.2. Algunas cosas que son posibles

Algunos esquemas variados que es posible construir con Asterisk se exponen a conti-
nuación.

Puente hacia la evolución

Asterisk puede usarse como un Puente entre una PBX tradicional y el futuro. Se puede
colocar Asterisk en frente de la PBX y usarlo como un portal (Gateway) e ir migrando
los clientes hacia Asterisk a medida que las necesidades lo requieren. También puede
usarse asterisk detrás de la PBX como un servidor periférico de aplicaciones. Es posible
incluso hacer las dos cosas como se muestra en la figura 2.11.
Las siguientes son algunas de las opciones que pueden usarse.
Mantener la vieja PBX pero evolucionar a IP
Las empresas han gastado vastas sumas de dinero comprando PBX y equipamiento y
ahora quieren una salida de esta jaula propietaria pero no quieren deshacerse de toda
esta tecnología. Esto no es un problema ya que Asterisk puede solucionar problemas
que van desde reemplazar el antiguo sistema de voicemail a proveer una manera de
agregar usuarios IP ampliando la capacidad nominal del sistema.
Encontrarme para seguirme
Con solo proveer a la PBX con una lista de números donde puede ser encontrado y se
llamará a todos cada vez que se llame al número de Direct Inward Dialing (DID). La
figura 2.12 ilustra ésta tecnología.
2.20 Panorama de Asterisk 140

Fig. 2.11: Puente Asterisk-PBX

Fig. 2.12: Tecnología de DID

2.20 Panorama de Asterisk 141

Fig. 2.13: Asterisk emulando PSTN para función VoIP

Llamadas VoIP
Si se puede establecer una conexión desde la central Asterisk a la vieja PBX, entonces
Asterisk puede proveer acceso a servicios de VoIP, mientras que la vieja PBX continua
conectándose al mundo exterior como siempre lo hacía.
Asterisk, funcionando como un gateway solo necesita emular las funciones de la PSTN y
la PBX no sabrá distinguir que algo ha cambiado. La figura 2.13 muestra como Asterisk
puede ser usado para este propósito.
IVR
Muchas personas confunden el término de Respuesta Interactiva de Voz (Interactive
Voice Response, IVR) con Recepcionista Automatizado Auto Attendant (AA). Ya que
el sistema de AA fue la una de las primeras cosas para las que el IVR fue usado,
es comprensible que esta confusión persista. De cualquier manera, en la industria de
telecomunicaciones, el término de IVR representa mucho más que un AA. Este último
en general hace apenas algo más que presentar una manera de transferir llamadas hacia
los internos.
Un sistema de IVR es generalmente algo muy caro, no solo de comprar sino también de
configurar. Un sistema personalizado de IVR usualmente requiere conectividad a una
base de datos o una aplicación. Asterisk puede hacer esto perfectamente ya que posee
conectividad con base de datos y aplicaciones en sus más internos niveles.
3. Estudio descriptivo de las caracteristicas de una PyME
para establecer parámetros de diseño.

3.1. Relevamiento técnico en una PyME

Tanto Asterisk como cualquier sistema de comunicaciones no tiene una estructura es-
tática para implementarla como solución. Si esto fuera así, deberíamos adaptar, por
ejemplo, toda la estructura de una empresa, junto con el equipamiento que podamos
reciclar, a los requerimientos y métodos del sistema que pretendemos implementar. Por
supuesto que esto además de incómodo y trabajoso, resulta en una pérdida de dinero
para la empresa. Por lo tanto, todas las soluciones de comunicaciones pretenden adap-
tarse a la estructura del objeto de implementación y sus necesidades, principalmente.
A partir de esta noción, es que para la implementación de Asterisk en una PyME,
comenzamos con la realización de un Relevamiento Técnico para detectar estructura
y elementos de comunicaciones en la empresa, como así también sus necesidades de
comunicación, derivadas muchas veces de las limitaciones tecnológicas del equipamiento
instalado.
El primer paso fue la realización de una entrevista con el encargado de Sistemas en
la propia empresa. En la misma se relevó el equipamiento que daba servicios de PBX,
cuáles eran sus ventajas y desventajas, análisis de costo, cantidad de equipamiento ne-
cesario, y principalmente, se trató de establecer cuáles eran los requerimientos mínimos
de comunicación que se necesitaban.
A partir de esta entrevista, se elaboró un informe, y en su presentación se delinearon
las características de la solución a implementar en la empresa, que se presentan a
continuación:
Que se puedan recibir llamadas desde afuera y efectuar llamadas salientes
IVR (preatendedor)
Llamadas por área y llamadas rotativas
Voicemail (solo para ser usado entre internos)
Transferencia de llamadas
Musica en espera
Llamada en espera
Personalizar los mensajes de espera de cada interno
Acceso remoto al voice mail
Generar registros de llamadas
Restriccion de llamadas por nro. de interno
3.2 Cuestionario para Relevamiento Técnico 143

Una vez establecidos los rasgos de la implementación, pasamos al diseño propiamente

dicho, donde se establecieron las necesidades de hardware, se configuró el dial plan, se
realizaron las pruebas necesarias y finalmente se instaló la solución. Todo este proceso
se describe detalladamente en el capítulo siguiente.
A continuación se muestran el Cuestionario de Relevamiento Técnico y su Informe
Final, como así también una propuesta de IVR que se presentó a los directivos de la
empresa, puesto que el tratamiento de las llamadas fue la necesidad más urgente que
la empresa necesitaba cubrir.

3.2. Cuestionario para Relevamiento Técnico

3.2.1. Cuestiones Técnicas
Cableado Interno (tipo) y hardware

¿Qué tipo de cableado tiene el edificio? Descripción general de la red (Bus, Estrella)
¿Qué antigüedad tiene la instalación?
¿Qué tipo de cable es el que se ha utilizado?
¿Que placas de red poseen las PCs?
¿Qué equipos de red están dando el servicio? Son equipos configurables?
¿Que equipos han sido instalados por el proveedor del servicio de Banda Ancha?
¿Que velocidad a sido contratada para el servicio de Banda Ancha?
¿Cuál es la velocidad promedio a la que trabaja la red?
¿Se trabaja con algún tipo de servidor que brinde servicios específicos?
¿Se ha implementado algún mecanismo de seguridad en la red?
¿Cada puesto de trabajo tiene una PC?

Conexión a PSTN

¿Quién es el proveedor del servicio de telefonía?

¿Cuantas líneas entrantes han sido contratadas?
¿Son líneas generales con distinta numeración?
¿Llegan a la central telefónica mediante par telefónico?
¿Que estimación de crecimiento se prevee a corto plazo con referencia a líneas entrantes?
¿La utilización normal de las líneas provoca un excesivo bloqueo?

Servicios Actuales Central

¿Central propia o alquilada?

¿Que servicios está proveyendo la central telefónica instalada?
¿Estos servicios funcionan correctamente?
¿Cuáles son los principales problemas?
3.2 Cuestionario para Relevamiento Técnico 144

¿A cuántos internos está dando servicio la central?

¿Todos los internos tienen los mismos privilegios de utilización o alguno presenta algu-
nas restricciones configurables?
¿Cuantas comunicaciones simultáneas entre internos es capaz de manejar la central?
¿Que facilidades presenta la central para cambiar o agregar un interno?
¿Que tipos de aparatos telefónicos poseen?
¿Desde todos los teléfonos se puede realizar transferencia de llamadas? ¿Cuantos telé-
fonos con esta función hay?
¿Al llamar desde afuera, contesta la central a través de un IVR o directamente atiende
una operadora?
¿Cuáles son las fortalezas y debilidades del sistema actual?

3.2.2. Costos actuales

¿Cuál es el gasto mensual de telefonía?
¿Se presenta aumentos de gastos temporales? ¿En que momentos?
¿Se realiza mantenimiento de la Central? ¿Que costo tiene este mantenimiento?
¿Cuál es el gasto mensual de Internet?
¿Se realiza mantenimiento de la red de datos? ¿Que costo tiene este mantenimiento?

3.2.3. Cuestiones Personales o de Uso

¿Donde llaman comúnmente? Local - Larga distancia - Internacional - Con las sucur-
sales
¿Que servicios brindados por una central se necesitan? Transferencia de llamadas -
Voice Mail - Llamada en espera - IVR
¿Estos servicios se requieren en todos los internos? ¿Cuantos?
¿Qué tipo de interfaz al teléfono se requiere (hardware)? ¿Depende de la jerarquía y/o
del área de trabajo?
¿Cuánto se usa el teléfono normalmente?
¿Se reciben muchas llamadas externas?
¿Qué áreas utilizan más las líneas?
¿Qué áreas requieren total disponibilidad para comunicarse externamente?
¿Existen restricciones para llamadas salientes?
¿Se permite utilizar programas de Chat como MSN Messenger?
¿Se permite descargar música o películas desde la WEB?

3.2.4. Necesidades Futuras

¿Que nivel de crecimiento se prevee en relación a la cantidad de internos y líneas
salientes?
¿Qué servicios de comunicación se requieren a corto y mediano plazo?
3.3 Informe Relevamiento Técnico 145

3.2.5. Cuestiones generales

¿En otras sucursales tienen la misma problemática?
¿Han discriminado el costo telefónico intersucursales o proveedor particular?
Nivel de conocimiento del encargado de sistema
Disponibilidad financiera
Planos de la instalación de voz y datos
Cantidad de PCs y teléfonos
FAX e impresoras

3.3. Informe Relevamiento Técnico

El día Sábado 18 de Marzo de 2006, se realizó un relevamiento técnico, con el propósito
de obtener conocimientos sobre el servicio de telefonía y datos, como así también el
funcionamiento de la red en su conjunto y la Central Telefónica. Además se hizo hincapié
en establecer las necesidades de los usuarios tanto a corto como mediano plazo, siempre
referidos a los servicios antes descriptos.
El relevamiento se realizó a través de un cuestionario, indexado en cinco módulos:
1) Cuestiones Técnicas
2) Costos Actuales
3) Cuestiones personales o de uso
4) Necesidades Futuras
5) Generales
La información relevada se presenta a continuación.

3.3.1. Cuestiones Técnicas

Cableado Interno y Hardware

El edificio presenta una topología de red tipo estrella, cableado con Unwired twisted
pair (UTP) categoría 5 y la instalación tiene una antigüedad de un año y medio.
Todos los puestos de trabajo poseen conectividad mediante placas de red 10-BaseT
y 100-BaseT de varios fabricantes (aproximadamente Catorce 100-BaseT y Tres 10-
BaseT).
El equipo de networking, es un Switch 3Com de capa dos, de la familia SuperStack 2
Dual Switch - Dual Speed Hub 500.(Se adjuntan especificaciones en apéndice ??).
El proveedor del servicio de banda ancha instaló un MODEM ADSL genérico no confi-
gurable. Para dar servicio a todos los puestos de trabajo se anexó un MODEM Tainet
CA81R, que realiza funciones de Router (NAT, DHCP, PROXY, FIREWALL).
La velocidad promedio a la que funciona la red de datos es 100 Mbps y la velocidad
contratada del servicio de internet es 1 Mega Byte (MB).
Las estaciones de trabajo tienen configuradas direcciones IP fijas.
3.3 Informe Relevamiento Técnico 146

A la red está conectado un Access Point para la gestión de las Notebooks. El mismo
brinda servicio Dinamic Host Configuration Protocol (DHCP) para cinco direcciones
IP.
Cada puesto de trabajo tiene una PC y cada dos puestos de trabajo hay un teléfono
(en promedio).

Conexión a PSTN

El proveedor del servicio de telefonía es Telecom. Al mismo se han contratado CINCO

líneas generales con distinta numeración, que llegan a la central mediante par telefónico
(conexión estándar).
Las líneas están configuradas de la siguiente forma:
- 1 directa al FAX - se puede tomar para llamadas salientes
- 3 para llamadas salientes
- 4 para llamadas entrantes (rotativas)
Con referencia a las necesidades de adquirir más líneas, se planteó que la idea es reducir
las llamadas entrantes. Para esto se implementan otras herramientas de comunicación
con los clientes, como el Electronic Mail (E-mail), chat, confirmación de costos en el
diagnóstico. Sin embargo quizás se realice contratación de más líneas salientes, en virtud
de ampliación del personal de ventas.
En la actualidad se presenta un excesivo bloqueo, provocado por la cantidad de llamadas
entrantes que no son gestionadas de manera correcta por la central. Según un estudio
realizado por Telecom, el problema no es de saturación de las líneas, sino de recursos
(tecnológicos y humanos).

Servicios Actuales Central

La central telefónica instalada es una Panasonic KX TA308 propia, de dos años y

medio de antigüedad, con una capacidad para 4 líneas entrantes y 16 internos. A la
central original de 3x8 se le agregaron módulos para que tenga la capacidad actual. (Se
adjuntan especificaciones en apéndice ??)
Los servicios de la central que están configurados y en uso actualmente son un IVR
básico a través de una placa Dinamic ISA (DISA) y transferencia de llamadas entre
los internos. Si bien los servicios funcionan correctamente, no son de utilidad para la
empresa debido a que al no hacerse un tratamiento de las llamadas, éstas se pierden o
encuentra un excesivo bloqueo.
La principal falencia que presenta en la actualidad la central telefónica, en cuanto a
hardware, es la emisión aleatoria de señal de FAX cuando entra una llamada. Este
problema puede haberse originado como consecuencia de una tormenta en el 2005, que
provocó que la central se quemara.
En cuanto a la utilización de las líneas por parte de los internos, existen algunas res-
tricciones configuradas:
A. 4 internos tienen privilegio total
B. El resto solo salida local y restricción a celulares
3.3 Informe Relevamiento Técnico 147

C. Los 0-800s no están restringidos (se utilizan para los servicios de Hewlett-Packard
(HP))
D. Total restricción para 0-600s.
E. 2 internos con salida internacional.
F. NO HAY INFORMES DE UTILIZACIÓN
La central permite ocho comunicaciones simultáneas entre internos y presenta facilida-
des para la ampliación y mantenimiento. Sin embargo, en este momento está funcio-
nando al límite de capacidad.

3.3.2. Costos
Telefonía: Entre $1300 y $1500 por mes
Internet: $316 (entre Internet y Sitio Web)
Se realiza mantenimiento reactivo de la Central Telefónica y no se realiza mantenimiento
de la red de datos.

3.3.3. Cuestiones Personales o de Uso

Normalmente se realizan llamadas a nivel Local, Corta y Media Distancia.
Las áreas que más utilizan las líneas son Ventas y Consultas de Orden. Las que requieren
total disponibilidad son Gerencias, Ventas y Administración.
En estos momentos sólo se utiliza el MSN Messenger como herramienta de trabajo,
principalmente en Administración, Ventas, Depósitos y para comunicación entre los
Encargados.
Las descargas WEB están en proceso de restricción total.

3.3.4. Cuestiones generales

Cantidad de PCs: 19.
Sucursales en Villa María y Buenos Aires. Comunicación vía NEXTEL.
Las sucursales no presentan problemas en el servicio de telefonía.
Los proveedores de telefonía son distintos en cada sucursal.
No existen planos de la instalación de voz y datos.
El cableado no está realizado bajo norma, si bien está realizado para voz y datos de
forma conjunta.
Las estaciones de trabajo están conectados directamente al Switch (no hay conexión a
través de pachera).
3.4 Diagrama de Estados para el IVR 148

3.4. Diagrama de Estados para el IVR

Fig. 3.1: Diagrama de estados llamadas externo a interno

3.4 Diagrama de Estados para el IVR 149

Fig. 3.2: Diagrama de estados llamadas interno a interno

Fig. 3.3: Diagrama de estados llamadas interno a externo

4. Diseño de una solución de comunicaciones de VoIP
basada en Asterisk en una PyME.

4.1. Diseño de una solución de VoIP

En base al relevamiento técnico realizado y de acuerdo a las necesidades detectadas en la
PyME se propone diseñar una solución Asterisk basada en las siguientes características.

4.1.1. Diagrama de la Red

En la figura 4.1 se tiene el esquema simplificado de la red a implementar.

Fig. 4.1: Diagrama de la Red

4.1.2. Hardware
La instalación del hardware y su ubicación se recomienda que siga los conceptos indi-
cados anteriormente sobre puesta a tierra, ambiente, etc.
A continuación se listan los elementos de hardware para dar soporte al servidor Asterisk:
Placa zaptel TDM400P para dar soporte a las 4 líneas FXO
(www.digium.com/en/products/hardware/tdm400p.php)
Servidor: Procesador Pentium 4 3.0Ghz HT, 1GB RAM, HD 80G, Mot-
her Board ASUS 775 P5V800-MX
4.1 Diseño de una solución de VoIP 151

UPS y estabilizador Atomlux A1000@plus

Para los internos se utilizará:

Cuatro teléfonos IP Siemens OptiPoint 410 Entry para la gerencia y
otros
Cuatro headsets para usar con cuatro softphones X-lite en área ventas
Para los demás internos se usarán módulos adaptadores Cisco ATA 186
Se usará el plantel telefónico y de red ya instalado en la empresa por lo que no es necesa-
rio hacer grandes modificaciones ni cablear elementos adicionales (excepto la colocación
de los ATA). El Switch existente proveerá de conectividad al servidor Asterisk.

4.1.3. Software
La instalación de Asterisk se efectúa como se indicó en la respectiva sección de este
trabajo, utilizando el sistema operativo Linux distribución Debian (kernel 2.6), usando
los archivos de configuración extensions.conf y sip.conf, como se detalla más adelante,
para manejar los internos y el IVR.
La configuración de los clientes ya ha sido consignada previamente y se deberá proceder
acorde a la misma. En la configuración propuesta se han estructurado los internos y
privilegios para los mismos de la siguiente manera:
Cuatro internos de ventas, cuatro de administración y uno de operadora que sólo pueden
efectuar llamadas locales y llamadas al soporte técnico oficial de HP (0800).Los demás
internos pueden recibir llamadas desde las líneas externas sin poder realizarlas, pero si
tienen capacidad de derivar llamadas entre internos.
Cuatro internos de gerencia que tienen acceso directo a la línea de salida presionando
el número 9. Es decir, pueden efectuar cualquier llamada.
Los internos comienzan en 8000 y terminan en 8016.
Todos los internos pueden comunicarse mutuamente simplemente discando el número
correspondiente.
Todos los internos tienen disponibles sus respectivas casillas de voicemail para dejar
mensajes en caso de no estar disponibles. Para poder acceder a las casillas de voicemail
se ha configurado el interno 8080. Se debe ingresar el número de interno y contraseña
(1234 por defecto) para autenticarse.
Por otra parte, de las cuatro líneas externas, sólo se hace uso de tres de ellas para
llamadas interno-externo, de manera tal que siempre quede una línea disponible para
las comunicaciones entrantes a la empresa (externo-interno).
Además se encuentra habilitado el número de llamadas emergencia para que todos los
internos puedan acceder a éste directamente.
A continuación exponemos los archivos, en cada línea se comenta la utilidad de cada
comando.
4.1 Diseño de una solución de VoIP 152

sip.conf
[general]
;
context=default
srvlookup=yes
;
;
;INTERNOS: 1 operadora, 4 de ventas, 4 de administración,
; 4 de gerencia y 4 de servicio técnico
;
[8000]
;
;Interno de operadora
;
type=friend
secret=operadora
context=internal ; El contexto internal controla lo que se puede hacer
nat=no ; Este teléfono no está detrás de un NAT
host=dynamic ; Este dispositivo se registra con nosotros
qualify=yes ; par calificado si no está a mas de 2000ms de distancia
canreinvite=no ; Asterisk por defecto trata de redireccionar
;
;-------------------------> Ventas
;
[8001]
;
type=friend
secret=8001
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8002]
;
type=friend
secret=8002
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8003]
;
type=friend
secret=8003
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8004]
;
type=friend
secret=8004
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
;-------------------------> Administración
;
[8005]
;
type=friend
secret=8005
context=internal
nat=no
host=dynamic
4.1 Diseño de una solución de VoIP 153

qualify=yes
canreinvite=no
;
[8006]
;
type=friend
secret=8006
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8007]
;
type=friend
secret=8007
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8009]
;
type=friend
secret=8009
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
;-------------------------> Gerencia
;
[8008]
;
type=friend
secret=8008
context=internalgerencia ; el contexto de gerencia tiene mayores privilegios
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8010]
;
type=friend
secret=8010
context=internalgerencia
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8011]
;
type=friend
secret=8011
context=internalgerencia
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8012]
;
type=friend
secret=8012
context=internalgerencia
nat=no
host=dynamic
qualify=yes
canreinvite=no
4.1 Diseño de una solución de VoIP 154

;
;-------------------------> Soporte técnico
;
[8013]
;
type=friend
secret=8013
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8014]
;
type=friend
secret=8014
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8015]
;
type=friend
secret=8015
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no
;
[8016]
;
type=friend
secret=8016
context=internal
nat=no
host=dynamic
qualify=yes
canreinvite=no

extensions.conf
[globals]
;variables globales
NUMEROMARCADO=0
NUMVOICEMAIL=8080
OPERADORA=8000
SIPVENTAS=SIP/8001&SIP/8002&SIP/8003&SIP/8004
SIPADMINISTRACION=SIP/8005&SIP/8006&SIP/8007&SIP/8009
SIPTECNICO=SIP/8013&SIP/8014&SIP/8015&SIP/8016
CANALESDESALIDA=ZAP/1&ZAP/2&ZAP/3
;
LOCALACBA=_9[45]XXXXXX
EMERGENCIA=911
SOPORTETECNICO=_90800XXXXXX
;
[default]
;
[internal]
;
;los internos normales usan este contexto
;
include => checkvoicemail ;extension para acceder a los voicemail
include => internoainterno ;extension para manejar llamadas entre internos
;
exten => ${LOCALACBA},1,SetVar(NUMEROMARCADO=${EXTEN});carga variable para usarla en context llamadas ext.
exten => ${LOCALACBA},2,GoTo(internoexternonormal,s,1) ;lo lleva al contexto para manejar llamadas locales
exten => ${EMERGENCIA},1,Dial(${CANALESDESALIDA}/${EMERGENCIA}) ;llamadas de emergencia
exten => ${EMERGENCIA},2,Hangup()
exten => ${EMERGENCIA},102,Playback(personal-nohaylineas)
4.1 Diseño de una solución de VoIP 155

exten => ${EMERGENCIA},103,Hangup()

exten => ${SOPORTETECNICO},1,SetVar(NUMEROMARCADO=${EXTEN});carga variable para usar en context llamadas ext.
exten => ${SOPORTETECNICO},2,GoTo(internoexternonormal,s,1) ;llamadas al soporte tecnico de HP
;
exten => t,1,Playback(pbx-goodbye); time out general, despedida
exten => t,2,Hangup() ;fin de llamada
;
exten => i,1,Background(pbx-invalid);interno invalido, permite ingresar uno nuevo o cortar
exten => i,2,WaitExten(10);espera 10 segs a ver si ingresa un interno válido
exten => i,3,Playback(vm-goobye); despedida
exten => i,4,Hangup();fin de llamada
;
[internalgerencia]
;
;el interno de la gerencia usa este contexto
;
include => checkvoicemail
include => internoainterno
;
exten => 9,1,GoTo(internoexternogerencia,s,1) ;si disca 9 va al contexto de llamada ext. para gerencia
;
exten => t,1,Playback(pbx-goodbye); time out general, despedida
exten => t,2,Hangup() ;fin de llamada
;
exten => i,1,Background(pbx-invalid);interno invalido, permite ingresar uno nuevo o cortar
exten => i,2,WaitExten(10);espera 10 segs a ver si ingresa un interno válido
exten => i,3,Playback(vm-goobye); despedida
exten => i,4,Hangup();fin de llamada
;
[internoainterno]
;
exten => _800[12],1,SetVar(INTERNO=${EXTEN});inicializa la variable de canal INTERNO con el numero marcado
exten => _800[12],2,SetVar(IRVOICEMAIL=0); incializa la variable de canal IRVOICEMAIL a cero
exten => _800[12],3,Dial(SIP/INTERNO,10,r);permite llamar a internos
;
exten => _800[12],4,SetVar(IRVOICEMAIL=1);no atendió el dial despues de 20 segundos, marca IRVOICEMAIL=1
exten => _800[12],5,Background(personal-nopodemosatenderlo); mensaje de internos no disponibles
exten => _800[12],6,WaitExten(3);espera para que ingrese un interno
exten => _800[12],7,WaitMusicOnHold(15);esperar 15 segundos con musica ya que desea intenar llamar de nuevo
exten => _800[12],8,GoTo(3);va a la prioridad 3 donde llama nuevamente al interno INTERNO
;
exten => _800[12],104,SetVar(IRVOICEMAIL=1);no atendió porque esta ocupado o no conectado
exten => _800[12],105,Background(personal-nopodemosatenderlo);mensaje de internos no disponibles
exten => _800[12],106,WaitExten(3);espera para que ingrese un interno nuevo
exten => _800[12],107,WaitMusicOnHold(15);si decide esperar mantiene 15seg con musica antes de llamar de nuevo
exten => _800[12],108,GoTo(3);va a la prioridad 3 donde llama nuevamente al interno INTERNO
;
exten => 1#,1,GoToIf($[${IRVOICEMAIL} = 1]?2:10);ingresó 1# despues de tratar de llamar a interno (IRVOICEMAIL=1).
exten => 1#,2,VoiceMail(${INTERNO}@default)
exten => 1#,3,Hangup();fin de llamada una vez que deja el mensaje
;
exten => 1#,10,Playback(vm-goodbye); ingresó 1# sin haber ingresado un interno previamente, despedida
exten => 1#,11,Hangup();fin de llamada
;
[checkvoicemail]
;
exten => ${NUMVOICEMAIL},1,VoiceMailMain();permite verificar el voicemail llamando al interno NUMVOICEMAIL
;
[externointerno]
;
exten => s,1,Answer();contesta el teléfono
exten => s,2,Background(personal-extintrecepcionista);reproduce opciones disponibles o esperar para operadora
exten => s,3,WaitExten(4);espera 4 segundos para que ingrese un interno
;
exten => s,4,Dial(SIP/${OPERADORA},10,rt);llama a la operadora si no ingresa nada
exten => s,5,Playback(personal-operocupada);mensaje que operadora está ocupada espere o pruebe mas tarde.
exten => s,6,WaitMusicOnHold(10);espera con musica, 10 segs.
exten => s,7,GoTo(4);vuelve a la prioridad 4 para llamar a la operadora
;
exten => s,105,GoTo(5);vuelve a la prioridad 5 en caso de estar ocupada o no disponible la operadora
;
exten => 1,1,Dial(${SIPVENTAS},10,rt); si ingresa la opcion llama al interno(s) correspondiente(s)
exten => 1,2,Playback(personal-todosocupados);si nadie atiende en 10 seg, reproduce internos ocupados
exten => 1,3,WaitMusicOnHold(10);espera 10 segundos con musica en espera
4.1 Diseño de una solución de VoIP 156

exten => 1,4,GoTo(1);vuelve a la prioridad 1 e intenta llamar nuevamente

;
exten => 1,102,GoTo(2);vuelve a la prioridad 2 en caso de estar ocupado o no disponible SIPVENTAS
;
exten => 2,1,Dial(${SIPADMINISTRACION},10,rt);si ingresa la opcion llama al interno(s) correspondiente(s)
exten => 2,2,Playback(personal-todosocupados);si nadie atiende en 10 seg, reproduce internos ocupados
exten => 2,3,WaitMusicOnHold(10);espera 10 segundos con musica en espera
exten => 2,4,GoTo(1);vuelve a la prioridad 1 e intenta llamar nuevamente
;
exten => 2,102,GoTo(2);vuelve a prioridad 2 en caso de estar ocupado o no disponible SIPADMINISTRACION
;
exten => 3,1,GoTo(serviciotecnico,s,1);si ingresa la opcion 3 va al contexto serviciotecnico
;
exten => _800[09],1,Dial(SIP/${EXTEN},10,rt);marca interno del 8000 al 8009, entonces se intenta llamarlo
exten => _800[09],2,Playback(personal-todosocupados);se reproduce un mensaje si no atienden en 10 segs
exten => _800[09],3,WaitMusicOnHold(10);si decide esperar se lo mantiene 10 seg con musica
exten => _800[09],4,GoTo(1);vuelve a intentar llamar llendo a la prioridad 1
exten => _800[09],102,GoTo(2); si estan ocupados o no conectados vuelve a la prioridad 2
;
exten => _801[06],1,Dial(SIP/${EXTEN},10,rt);marca interno del 8010 al 8016, entonces se intenta llamarlo
exten => _801[06],2,Playback(personal-todosocupados);se reproduce un mensaje si no atienden en 10 segs
exten => _801[06],3,WaitMusicOnHold(10);si decide esperar se lo mantiene 10 seg con musica
exten => _801[06],4,GoTo(1);vuelve a intentar llamar llendo a la prioridad 1
exten => _801[06],102,GoTo(2); si estan ocupados o no conectados vuelve a la prioridad 2
;
exten => i,1,Playback(personal-opcioninvalida);en caso de ingresar un interno inválido
exten => i,2,GoTo(s,2);vuelve a la priorodad 2 de la extension s de este contexto
;
[serviciotecnico]
;
exten => s,1,Background(personal-servtecordenes);reproduce las opciones disponibles
exten => s,2,WaitExten(4);espera 4 seg para que ingrese una opcion
;
exten => s,3,Dial(${SIPTECNICO},10,rt);si no ingresa nada llama al interno(s) SIPTECNICO
exten => s,4,Playback(personal-todosocupados);si no atienden en 10 seg reproduce mensaje internos ocupados
exten => s,5,WaitMusicOnHold(10);lo mantiene 10 segundos con musica si decide esperar a ser atendido
exten => s,6,GoTo(3);vuelve a la prioridad 3
;
exten => s,104,GoTo(4);si estan ocupados o no conectados vuelve a la prioridad 4
;
exten => 1,1,Playback(personal-llameal0800x);presiona la opcion 1,reproduce un mensaje del nro. de Sop.Tec.HP
exten => 1,2,Wait(4);espera 4 segundos
exten => 1,3,GoTo(1);vuelve a la prioridad 1 para reproducir nuevamente el mensaje
;
exten => 2,1,GoTo(s,3);si presiona 2, llama al interno(s) SIPTECNICO
;
exten => i,1,Playback(personal-opcioninvalida);si ingresa una opcion inválida se le informa
exten => i,2,GoTo(s,1);se lo lleva a la prioridad 1, de la extension s
;
[internoexternonormal]
;
exten => s,1,Dial(${CANALESDESALIDA}/${NUMEROMARCADO:1});marca no ingresado saca 9 de adelante usa CANALESDESALIDA
exten => s,2,Hangup();fin de la llamada
exten => s,102,Playback(personal-nohaylineas);si no hay lineas disponibles reproduce un mensaje
exten => s,103,Hangup();fin de la llamada
;
exten => i,1,Hangup();maneja entradas inválidas
;
[internoexternogerencia]
;
exten => s,1,Dial(${CANALESDESALIDA}); le da tono de la PSTN, puede efectuar cualquier llamada
exten => s,2,Hangup();fin de la llamada
exten => s,102,Playback(personal-nohaylineas);reproduce mensaje si no hay lineas disponibles de salida
exten => s,103,Hangup();fin de la llamada

voicemail.conf
[general]
; Default formats for writing Voicemail
;format=g723sf|wav49|wav
format=wav49|gsm|wav
; Maximum length of a voicemail message in seconds
;maxmessage=180
4.1 Diseño de una solución de VoIP 157

; Minimum length of a voicemail message in seconds

;minmessage=3
; Maximum length of greetings in seconds
;maxgreet=60
; How many miliseconds to skip forward/back when rew/ff in message playback
skipms=3000
; How many seconds of silence before we end the recording
maxsilence=10
; Silence threshold (what we consider silence, the lower, the more sensitive)
silencethreshold=128
;
[default]
8000 => 8000 ,Interno Operadora
8001 => 8001 ,Interno Ventas
8002 => 8002 ,Interno Ventas
8003 => 8003 ,Interno Ventas
8004 => 8004 ,Interno Ventas
8005 => 8005 ,Interno Administracion
8006 => 8006 ,Interno Administracion
8007 => 8007 ,Interno Administracion
8008 => 8008 ,Interno Gerencia
8009 => 8009 ,Interno Administracion
8010 => 8010 ,Interno Gerencia
8011 => 8011 ,Interno Gerencia
8012 => 8012 ,Interno Gerencia
8013 => 8013 ,Interno Tecnicos
8014 => 8014 ,Interno Tecnicos
8015 => 8015 ,Interno Tecnicos
8016 => 8016 ,Interno Tecnicos

zapata.conf
;
; Zapata telephony interface
;
; Configuration file
[channels]
;
; Default language
;
language=es
;
; Default context
;
context=externointerno
;
; Signalling method (default is fxs). Valid values:
; em: E & M
; em_w: E & M Wink
; featd: Feature Group D (The fake, Adtran style, DTMF)
; featdmf: Feature Group D (The real thing, MF (domestic, US))
; featb: Feature Group B (MF (domestic, US))
; fxs_ls: FXS (Loop Start)
; fxs_gs: FXS (Ground Start)
; fxs_ks: FXS (Kewl Start)
; fxo_ls: FXO (Loop Start)
; fxo_gs: FXO (Ground Start)
; fxo_ks: FXO (Kewl Start)
; pri_cpe: PRI signalling, CPE side
; pri_net: PRI signalling, Network side
; gr303fxoks_net: GR-303 Signalling, FXO Loopstart, Network side
; gr303fxsks_cpe: GR-303 Signalling, FXS Loopstart, CPE side
; sf: SF (Inband Tone) Signalling
; sf_w: SF Wink
; sf_featd: SF Feature Group D (The fake, Adtran style, DTMF)
; sf_featdmf: SF Feature Group D (The real thing, MF (domestic, US))
; sf_featb: SF Feature Group B (MF (domestic, US))
; The following are used for Radio interfaces:
; fxs_rx: Receive audio/COR on an FXS kewlstart interface (FXO at the channel bank)
; fxs_tx: Transmit audio/PTT on an FXS loopstart interface (FXO at the channel bank)
; fxo_rx: Receive audio/COR on an FXO loopstart interface (FXS at the channel bank)
; fxo_tx: Transmit audio/PTT on an FXO groundstart interface (FXS at the channel bank)
; em_rx: Receive audio/COR on an E&M interface (1-way)
4.1 Diseño de una solución de VoIP 158

; em_tx: Transmit audio/PTT on an E&M interface (1-way)

; em_txrx: Receive audio/COR AND Transmit audio/PTT on an E&M interface (2-way)
; em_rxtx: same as em_txrx (for our dyslexic friends)
; sf_rx: Receive audio/COR on an SF interface (1-way)
; sf_tx: Transmit audio/PTT on an SF interface (1-way)
; sf_txrx: Receive audio/COR AND Transmit audio/PTT on an SF interface (2-way)
; sf_rxtx: same as sf_txrx (for our dyslexic friends)
;
signalling=fxs_ks
;
; A variety of timing parameters can be specified as well
; Including:
; prewink: Pre-wink time (default 50ms)
; preflash: Pre-flash time (default 50ms)
; wink: Wink time (default 150ms)
; flash: Flash time (default 750ms)
; start: Start time (default 1500ms)
; rxwink: Receiver wink time (default 300ms)
; rxflash: Receiver flashtime (default 1250ms)
; debounce: Debounce timing (default 600ms)
;
rxwink=300 ; Atlas seems to use long (250ms) winks
;
; Whether or not to use caller ID
;
usecallerid=yes
;
; Whether or not to hide outgoing caller ID (Override with *67 or *82)
;
hidecallerid=no
;
; Whether or not to enable call waiting on FXO lines
;
callwaiting=yes
;
;Whether or not use the caller ID presentation for the outgoing call that the calling switch is sending
;
usecallingpres=yes
;
; Support Caller*ID on Call Waiting
;
callwaitingcallerid=yes
;
; Support three-way calling
;
threewaycalling=yes
;
; Support flash-hook call transfer (requires three way calling)
;
transfer=yes
;
; Support call forward variable
;
cancallforward=yes
;
; Whether or not to support Call Return (*69)
;
callreturn=yes
;
; Enable echo cancellation
; Use either "yes", "no", or a power of two from 32 to 256 if you wish
; to actually set the number of taps of cancellation.
;
echocancel=yes
;
; Generally, it is not necessary (and in fact undesirable) to echo cancel
; when the circuit path is entirely TDM. You may, however, reverse this
; behavior by enabling the echo cancel during pure TDM bridging below.
;
echocancelwhenbridged=yes
;
; If you are having trouble with DTMF detection, you can relax the
; DTMF detection parameters. Relaxing them may make the DTMF detector
; more likely to have "talkoff" where DTMF is detected when it
4.2 Interconexión Asterisk 159

; shouldn’t be.
;
;relaxdtmf=yes
;
; You may also set the default receive and transmit gains (in dB)
;
rxgain=0.0
txgain=0.0
;
; Logical groups can be assigned to allow outgoing rollover. Groups
; range from 0 to 31, and multiple groups can be specified.
;
group=1
;
; Ring groups (a.k.a. call groups) and pickup groups. If a phone is ringing
; and it is a member of a group which is one of your pickup groups, then
; you can answer it by picking up and dialing *8#. For simple offices, just
; make these both the same
;
callgroup=1
pickupgroup=1
;
; Specify whether the channel should be answered immediately or
; if the simple switch should provide dialtone, read digits, etc.
;
immediate=no
;
; On trunk interfaces (FXS) and E&M interfaces (E&M, Wink, Feature Group D
; etc, it can be useful to perform busy detection either in an effort to
; detect hangup or for detecting busies
;
busydetect=yes
;
; If busydetect is enabled, is also possible to specify how many
; busy tones to wait before hanging up. The default is 4, but
; better results can be achieved if set to 6 or even 8. Mind that
; higher the number, more time is needed to hangup a channel, but
; lower is probability to get random hangups
;
busycount=6
;
channel => 1

zaptel.conf
fxsks=1-4
loadzone=ar
defaultzone=us

4.2. Interconexión Asterisk

4.2.1. Potencialidades
Una de las potencialidades más importantes de utilizar Asterisk para manejar las comu-
nicaciones dentro de una empresa, es la posibilidad de interconectar dos PBX utilizando
preferentemente IAX como protocolo de VoIP.
Esta interconexión, entre dos sucursales de una determinada PyME por ejemplo, brinda
la posibilidad no solo de comunicaciones entre todos los internos de forma gratuita,
sino además, la posibilidad de cursar llamadas hacia la PSTN de forma local cuando la
llamada se genere desde otro pueblo, provincia, o por que no, desde otro país. Esto por
supuesto, implica una ventaja de comunicaciones que se ve reflejado en una reducción
de costos, aspecto bastante importante cuando nos relacionamos dentro del ámbito
empresarial.
4.2 Interconexión Asterisk 160

Las llamadas entre internos y las llamadas locales desde una PBX lejana, solo depen-
derán de una conexión a internet con el suficiente ancho de banda para poder cursar
las mismas con una calidad de servicio satisfactoria.
Por supuesto que se puede utilizar SIP o H.323 (no así MGCP) para interconectar dos
servidores Asterisk, sin embargo realizar esto con IAX es, no solo lo más común sino
también lo más correcto y eficiente.
A su vez, para compartir un Dial Plan se puede realizar lo siguiente:
Diseñar inteligentemente el Dial Plan en cada servidor para que quede bien claro
cuando una extensión en el otro servidor está siendo llamada, por ejemplo usando
3xxx para el servidor A, 4xxx para el servidor B y 5xxx para las extensiones en
el servidor C.
Usar el comando switch para hacer que el servidor A realice consultas locales en
el servidor B sobre las extensiones desconocidas (ambos servidores deberán estar
permanentemente conectados).
Utilizar el Distributed Universal Number Discovery (DUNDi).
A continuación, se presenta una descripción general del archivo de configuración iax.conf,
y luego se presentarán algunos ejemplos prácticos de interconexión de servidores Aste-
risk.

4.2.2. IAX
El archivo de configuración iax.conf contiene toda la información de configuración que
necesita Asterisk para crear y manejar canales IAX. Las secciones en el archivo están
separadas por encabezados, que están formados por una palabra entre corchetes. El
nombre entre corchetes será el nombre del canal, con una notable excepción: la sección
[general], que no es un canal, sino el área donde los parámetros de protocolo globales
son definidos.

Ajustes generales de IAX

La primera línea en el archivo iax.conf deberá ser el encabezado [general]. Los pa-
rámetros en esta sección se aplicarán a todas las conexiones que utilicen este protocolo,
a menos que sean definidos de una forma diferente particularmente en la definición de
un canal específico. Si se definen los parámetros de un canal bajo la sección [general],
no se necesitará definirlos en cada canal; su valor pasa a ser el valor por defecto.
Aquí se enlistan los parámetros que se podrán configurar. Como algunos de estos pará-
metros pueden ser redefinidos en cada canal en particular, se identificarán aquellos que
son globales con la marca (global) y aquellos que opcionalmente pueden modificarse
con la marca (channel):
Accountcode(channel)
El código de cuenta puede definirse en un par - usuario básico. Si está definido, este
código de cuenta será asignado a un registro de llamadas siempre que no se especifique
ningún código de cuenta de usuario. El nombre de accountcode configurado será utiliza-
do como nombredelarchivo.csv en el directorio /var/log/Asterisk/cdr-csv/ para
almacenar CDRs para el usuario/par/amigo.
4.2 Interconexión Asterisk 161

accountcode=iax-username
allow y disallow(channel)
Codecs específicos pueden permitirse o rechazarse, limitando los mismos a aquellos
preferidos por el diseñador del sistema. Allow y disallow pueden ser definidos en un
canal par básico. Hay que tener en cuenta que utilizar el comando allow en la sección
[general] afectará a todos los canales que se definan posteriormente, a menos que se
resetee mediante disallow-all. La negociación de los codecs se realizará en el orden
en que han sido definidos. Las mejores prácticas sugieren que se defina disallow-all,
seguido de una declaración allow explícita para cada codec que se desee utilizar. Si no
se define nada, se asume allow-all (todos permitidos).

disallow=all
allow=ulaw
allow=gsm
allow=ilbc

amaflags(channel)
A partir de este parámetro, se podrá especificar que mecanismo estándar de generación
y transmisión de CDRs se utilizará. Para esto, se podrá elegir una de cuatro opciones
aplicables a todas las conexiones IAX.
amaflags=default|omit|billing|documentation
authdebug(global)
Se podrá minimizar la cantidad de depuración de autorización simplemente deshabili-
tándola. Esta estará habilitada si no se realiza la deshabilitación explícitamente.
authdebug=no
autokill (global)
Para minimizar el peligro de parar cuando un host es inalcanzable, se puede setear
autokill a si para especificar que cualquier conexión nueva deberá ser dada de baja
si un mensaje Acknowledge (ACK) no es recibido en 2.000 ms. Alternativamente, se
puede reemplazar si con el número de milisegundos a esperar antes de considerar un
par inalcanzable. autokill configura el tiempo de espera para todos los pares IAX2, pero
se puede configurar para cada par individualmente mediante la utilización del comando
qualify.
autokill=1500
underlinebandwidth (channel)
bandwidth es un atajo que permitirá no tener que usar disallow-all y luego habilitar
cada CODEC específico mediante declaraciones allow. Las opciones son las siguientes:
high: permite todos los codecs (G.723.1, GSM, ulaw, alaw, G.726, ADPCM, sli-
near, LPC10, G.729, Speex, iLBC).
medium: permite todos los codecs excepto slinear, ley µ, y ley A.
low: permite todos los codecs médium excepto G.726 y ADPCM.
bandwidth=low|medium|high
bindport y bindaddr(global)
4.2 Interconexión Asterisk 162

Este parámetro opcional permite controlar la interface IP o puerto en donde se desea

aceptar conexiones IAX. Si se omite, el puerto que se utilizará es el 4569, y todas las
direcciones IP en el sistema Asterisk aceptarán conexiones IAX entrantes. Si múltiples
direcciones están configuradas, solo las interfaces definidas aceptarán conexiones IAX.
La dirección 0.0.0.0 le dirá a Asterisk que escuche en todas las interfaces.
bindport=4569 bindaddr=192.168.0.1
codecpriority(channel)
La opción codecpriority controla que parte de una llamada entrante tendrá priori-
dad en la negociación de los codecs. Si se setea en la sección [general], las opciones
seleccionadas serán heredadas por todas las entradas de usuario en la configuración
de los canales; sin embargo, pueden ser definidos en las entradas individuales de los
usuarios para mayor control granular. Si se setea en ambas secciones, la entrada de
usuario sobrescribirá lo que fue configurado en la sección [general]. Si el parámetro
no se configura, el valor por defecto es host. Las opciones válidas incluyen:
caller: quien realiza la llamada tiene prioridad sobre el host.
host: el host tiene prioridad sobre quien realiza la llamada.
disable: no se consideran preferencias de codecs.
regonly: las preferencias de codecs son ignoradas y las llamadas son aceptadas solo
si el codec requerido está disponible.
codecpriority=caller|host|disabled|reqonly
delayreject(global)
Si una contraseña incorrecta es recibida en un canal IAX, este parámetro retrasará
el envío de los mensajes de rechazo REGREQ o AUTHREP, que ayudará en la seguridad
frente a ataques para forzar la contraseña mediante fuerza bruta. El tiempo de retraso
es 1.000 milisegundos.
delayreject=yes|no
forcejitterbuffer(channel)
Como Asterisk intenta establecer un puente entre los puntos finales de una comuni-
cación, a estos puntos se les permite realizar almacenamiento de jitter. Sin embargo,
si los extremos de la comunicación tiene una implementación pobre para almacenar
jitter, es posible que se desee forzar a Asterisk a realizar este almacenamiento de jitter.
Estableciendo este parámetro en yes, se consigue lo descrito.
forcejitterbuffer=yes
jitterbuffer(channel)
El jitter se refiere la latencia variante entre paquetes. Cuando los paquetes son enviados
desde un punto terminal, estos se envían a una velocidad constante con muy poca
variación de latencia. Sin embargo, mientras los paquetes atraviesan Internet, la latencia
entre los paquetes comienza a variar; de esta forma, los paquetes pueden llegar a destino
en diferentes tiempos y hasta desordenados.
El buffer de jitter es, en cierto modo, un área intermedia donde los paquetes pueden ser
reordenados y entregados al destino en una corriente regular. Sin un buffer de jitter,
el usuario puede percibir anomalías en la corriente de datos, experimentando estática,
efectos de sonido extraños, palabras confusas, o en los casos más severos, palabras o
sílabas perdidas.
4.2 Interconexión Asterisk 163

El buffer de jitter afecta solo los datos recibidos en el extremo final de la comunicación.
Cualquier corriente de datos que se transmita no se verá afectado por el buffer de jitter
del emisor, y el extremo receptor será el responsable de solucionar esta variación de
jitter de sus conexiones entrantes.
El buffer de jitter se habilita seteando el parámetro en yes.
jitterbuffer=yes|no
language(channel)
Este parámetro setea el lenguaje que se desee. El lenguaje global por defecto es el
inglés. El lenguaje seteado es enviado por el canal como un elemento de información.
Es también utilizado por aplicaciones como SayNumber() que tiene diferentes archivos
para cada lenguaje. Hay que tener en cuenta que los demás idiomas no estarán instalados
en el sistema, y quedará en manos de cada diseñador configurar el mismo para utilizar
el lenguaje de preferencia.
language=en
mailboxdetail(global)
Si este parámetro es seteado en yes, una cuenta de mensajes es enviada al usuario, en
vez de una simple declaración de si un nuevo o viejo mensaje existe.
mailboxdetail=yes
maxjitterbuffer(channel)
Este parámetro es utilizado para establecer el máximo tamaño del buffer de jitter, en
milisegundos. Hay que asegurar que el buffer no sea demasiado grande, ya que esto
deriva en una mayor latencia.
maxjitterbuffer=500
regcontext y regexten(channel)
Especificando el contexto que contiene las acciones a ejecutar, se puede configurar las
acciones que Asterisk deberá ejecutar cuando un par se registra con el servidor. Esta
opción trabaja en conjunto con el parámetro regexten, que especifica la extensión a
ejecutar. Si no se configurar regexten, el nombre del par es utilizado como extensión.
regcontext=registered-phones
regexten=myphone
resyncthreshold(channel)
El umbral de resincronización es usado para resincronizar el buffer de jitter si se ha
detectado un cambio significante sobre algunos frames. Este umbral es definido como
el jitter medido más el valor de resincronización, en milisegundos.
resyncthreshold=1000
tos(global)
Asterisk puede establecer los bits de Type of Service (TOS) en el encabezado IP para
ayudar a mejorar la perfonmance en los routers que respetan los bits de TOS en su
cálculo de rutas. Los siguientes valores son los utilizados:
lowdelay: minimiza el retardo.
throughput: minimiza el throughput.
reliability: maximiza la fiabilidad.
4.2 Interconexión Asterisk 164

mincost: minimiza el costo.

none: no se establecen los bits de ToS.
tos=lowdelay|throughput|reliability|mincost|none
trunk(channel)
IAX trunking permite a Asterisk enviar media (como mini-frames) desde múltiples
canales usando un solo encabezado. La reducción de datos no necesarios hace que el
protocolo IAX sea más eficiente cuando se envían múltiples corrientes de datos al mismo
punto receptor (usualmente otro servidor Asterisk).
trunk=yes|no
trunkfreq(channel)
Este parámetro es usado para controlar con que frecuencia se envían mensajes de trun-
king, en milisegundos.
trunkfreq=20

El comando register

Cuando la IP del par es desconocida (ya sea porque tiene asignada su IP automáti-
camente o porque se encuentra detrás de un NAT), el usuario no tiene donde enviar
la llamada. Para compensar esto, el par activamente se registra con el usuario para
proveerle su identidad y ubicación.
En el par, dentro de la sección [general] del archivo iax.conf, se deberá añadir una
línea de registro:
register => user:[email protected]
Esto continuamente actualiza información para el usuario, y de esta forma siempre
podrá alcanzar al par por más que la IP de este último cambie.
El comando register es necesario solo cuando se desea conectar un servidor con una
dirección IP dinámica, a otro con una IP fija. Por lo tanto, en el usuario siempre deberá
estar definido host=dynamic, en la parte del archivo iax.conf correspondiente al par.

Definición de canales IAX

Con los ajustes generales definidos, ahora se podrá definir los canales. Definir un canal
invitado (canal guest ) se recomienda en el caso que se desee recibir llamadas IAX
anónimas. Para esto se deberá configurar lo siguiente:

[guest]
type=user
context=incoming
callerid="Incoming IAX Guest"

Si se desea aceptar llamadas desde la Red Mundial Dialup Libre, Asterisk contiene
una llave de seguridad predefinida que asegura que las conexiones anónimas no podrán
burlar una llamada entrante de esta Red. Para esto se deberá configurar un canal
iax-fwd:
4.2 Interconexión Asterisk 165

[iaxfwd]
type=user
context=incoming
auth=rsa
inkeys=freeworlddialup

Si se anuncian recursos en una red DUNDi, el usuario asociado deberá ser declarado
en el archivo iax.conf:

[dundi]
type=user
dbsecret=dundi/secret
context=dundi-incoming

Si se dispone de un dispositivo basado en IAX (como un IAXy), o un usuario IAX en

un nodo remoto, se deberá proveerles sus propios canales para que puedan conectarse
con el sistema. Si se tiene un usuario en un nodo remoto, se definirá el siguiente canal
IAX:

[user]
type=user
context=local_users
auth=md5,plaintext,rsa
secret=wasabi
notransfer=yes
jitterbuffer=yes
callerid="Happy Tempura" <(800) 555-1234>
accountcode=seaweed
deny=0.0.0.0/0.0.0.0
permit=192.168.1.100/255.255.255.0
language=en

Las llamadas entrantes desde este canal llegarán al contexto local_user y requerirán al
sistema que acepte código de llamador (caller ID)"Happy Tempura"<(800) 555-1234>.
El sistema estará dispuesto a aceptar autentificación MD5, de texto plano o RSA desde
este usuario, mientras que se proporciona la contraseña wasabi y la llamada se recibe
de la dirección IP 192.168.1.100. A todas las llamadas relacionadas con este canal se
le asignará el código de cuenta seaweed. Como se definió notransfer, las corrientes de
datos enviadas siempre pasarán a través de Asterisk; no podrán ser redireccionadas a
otro nodo IAX.
Si se desea configurar el propio sistema como un nodo remoto, y se desea conectarse a
otro nodo remoto que figura como usuario, se deberá definir el nodo propio como un
par:

[peer]
type=peer
username=sushi
secret=wasabi
host=192.168.1.101
qualify=yes
trunk=yes
4.2 Interconexión Asterisk 166

Fig. 4.2: Trunking de canales deshabilitado

Fig. 4.3: Trunking de canales habilitado

Un par puede referenciarse en un Dial Plan con el nombre colocado entre corchetes
pero autentificarse con un nombre de usuario diferente. El host se especifica tanto
por dirección IP o mediante FQDN. Se puede determinar la latencia entre el par y el
host remoto, siempre que el par este activo, mediante qualify=yes. Para minimizar la
cantidad de sobreencabezado por llamadas múltiples a un mismo par, se pueden truncar
las mismas.
El trunking es único de IAX y está diseñado para tomar ventaja del hecho de que dos
sitios pueden tener múltiples conexiones de VoIP entre ellos. El trunking IAX reduce en
sobreencabezado cargando varios canales en un solo paquete de señalización. Se puede
habilitar el mismo colocando trunk=yes en iax.conf.
Se muestra un canal en la figura 4.2 con trunk deshabilitado y luego en la figura 4.3
con esta opción habilitada.
Parámetros específicos de los canales
A continuación se especifican los parámetros específicos de los canales IAX:
callerid
Se puede setear una sugerencia de identificación de llamador tanto para un usuario
como para un par mediante callerid. Si se define el campo Caller ID para un usuario,
cualquier llamada que arribe a ese canal tendrá la identificación asignada a él. Si se
define este campo para un par, se está requiriendo que el extremo lejano que utilice
esa identificación (pero no se tendrá ninguna seguridad de que se aplique). Si se desea
que los usuarios entrantes definan su propia identificación, hay que asegurarse que no
se configure el campo callerid.
callerid=Juan Martín <(800) 555-1234>
defaultip
Este parámetro complementa la acción de especificar host=dynamic. Si un host no está
aún registrado con el servidor, el sistema intentará enviar mensajes a la dirección IP
por defecto configurada aquí.
defaultip=192.168.1.101
inkeys
Se puede utilizar esta opción para autentificar a un usuario mediante el uso de una
clave RSA. Para asociar más de una clave con la definición de un canal de usuario, se
4.2 Interconexión Asterisk 167

deberá separar los nombres claves por dos punto ( : ). Cualquiera de esas claves serán
necesarias para validar una determinada conexión. inkey es la clave pública que podrá
distribuirse entre los diferentes usuarios.
inkeys=server_one:server_two
mailbox
Si se asocia un mailbox con un par dentro de la definición de un canal, un voicemail
enviará un Message Waiting Indication (MWI) a los nodos extremos de ese canal. Si el
número de mailbox de un voicemail se encuentra en otro contexto que el default, se
podrá especificar mediante mailbox@contexto. Para asociar múltiples mailbox con un
par, se deberán utilizar múltiples declaraciones mailbox.
mailbox=1000@internal
outkey
Se puede utilizar esta opción para autentificar un par mediante el uso de una clave
RSA. Solo una clave podrá utilizarse para una autentificación saliente.
outkey=private_key
qualify
Se pude setear este parámetro en yes, no o un tiempo en milisegundos. Si optamos por
la primera opción, mensajes PING serán enviados periódicamente a los pares remotos
para determinar tanto si están activos como la latencia entre las respuestas. Los pares
contestarán con mensajes PONG. Un par se determinará inalcanzable si no se recibe
una respuesta en 2.000 milisegundos (para cambiar este valor por defecto, se deberá
especificar el tiempo de espera de una respuesta).
qualify=yes|no|1500

Detalles de conexión IAX

Una conexión IAX entre dos servidores Asterisk se realiza en varias instancias:
Configurar servidores Asterisk en ambos entremos en el archivo de configuración
iax.conf, uno como par y otro como usuario.
Colocar el Dial Plan del usuario en el archivo extensions.conf, para que de esta
forma se puedan realizar llamadas desde el usuario hacia el par.
Opcionalmente se podrá registrar el par con el usuario, ya que la dirección IP del
par es dinámica y por lo tanto desconocida por el usuario.
Repetir los pasos anteriores en la dirección opuesta, intercambiando par por usua-
rio, y así permitir las llamadas en ambas direcciones.

Declaración de un Usuario IAX2

Un par recibe llamadas. Lo siguiente se necesitará configurar en el archivo iax.conf

de la máquina del par para verificar (autentificar) la identidad del usuario antes de
permitir llamadas desde él.

[username]
type=user
4.2 Interconexión Asterisk 168

auth=md5
secret=contraseña
context=iax2users

El contexto es importante ya que indica el contexto local donde se deberán colocar las
llamadas entrantes de ese usuario.
Esta configuración deja el usuario remoto registrado en el sistema desde cualquier host.
Si se desea restringir con que dirección IP o host el usuario remoto puede comunicarse,
se deberán añadir los comandos permit o deny cuando se describe al usuario en el
archivo iax.conf del par.

Declaración de un Par IAX2

Un usuario realiza llamadas. Lo siguiente se necesitará configurar en el archivo iax.conf

de la máquina del usuario para identificarse (autentificar) con el par antes de que éste
tome la llamada.

[peername]
type=peer
host=hostname.domain.tld
(o "dynamic" que luego requerirá el comando "register" en el par)
auth=md5
secret=contraseña
username=username-at-the-peer

Notesé que:
- type=user es para autentificar una llamada entrante
- type=peer es alguien a quien se llama
- type=friend por supuesto, realiza las dos funciones
Ahora que los dos primeros pasos han sido realizados, lo único que resta hacer es
incluir estas funciones en el Dial Plan. Para esto, se describirán ejemplos prácticos que
mostrarán varias formas de lograrlo.

4.2.3. Conectando los Dial Plans

Ejemplo 1

extensions.conf:

exten => _7XXX,1,Dial(IAX2/myserver:passwordA@IAXserverA/${EXTEN:1},30,r)

exten => _7XXX,2,Dial(SIP/myserver:passwordA@SIPserverA/${EXTEN:1},30,r)
exten => _7XXX,3,Congestion
exten => _8XXX,1,Dial(IAX2/myserver:passwordB@IAXserverB/${EXTEN:1},30,r)
exten => _8XXX,2,Dial(SIP/myserver:passwordB@SIPserverB/${EXTEN:1},30,r)
exten => _8XXX,3,Congestion

Este ejemplo utiliza SIP como reserva, en caso que ocurran problemas con la conexión
IAX.
4.2 Interconexión Asterisk 169

Ejemplo 2

Server A iax.conf

[general]
register => <username>:<password>@<serverB hostname or IP>
[serverB]
type=friend
user=<username>
secret=<password>
host=<serverB hostname or IP>

Server A extensions.conf

exten => _7XXX,1,Dial(IAX2/serverB/${EXTEN:1},30,r)

exten => _7XXX,2,Congestion

Server B iax.conf

[serverA]
type=friend
user=<username>
secret=<password>
host=<dynamic> | <serverA hostname or IP>

Server B extensions.conf

exten => _8XXX,1,Dial(IAX2/serverA/${EXTEN:1},30,r)

exten => _8XXX,2,Congestion

Ejemplo 3

Con el comando switch en extensions.conf se podrá conectar dos servidores Asterisk

como así también dial plans de otros servidores. En este caso, el servidor C podrá
conectarse tanto con el servidor A como con el B.

[default]
exten => _801XXX,1,Goto,srvA|${EXTEN}|1
exten => _802XXX,1,Goto,srvB|${EXTEN}|1
[srvA]
exten => _801XXX,1,StripMSD,3
exten => _XXX,2,Goto,1
switch => IAX/serverA
[srvB]
exten => _802XXX,1,StripMSD,3
exten => _XXX,2,Goto,1
switch => IAX/serverB
4.2 Interconexión Asterisk 170

Ejemplo 4

extensions.conf (en el master)

[outbound]
switch => IAX2/master:[email protected]/outbound

iax.conf (en el master):

[slave]
type=user
auth=plaintext
context=outbound
context=outbound2
secret=secret
host=dynamic
callerid="slave"
trunk=yes
notransfer=yes
[slave]
type=peer
auth=plaintext
context=outbound-nuphone
secret=secret
host=dynamic
trunk=yes
notransfer=yes

iax.conf (en el slave):

register => slave:[email protected]

[master]
type=peer
host=iax-gw1.company.net
secret=secret
context=outbound
trunk=yes
canreinvite=no
[master]
type=user
secret=secret
context=acontext
trunk=yes
canreinvite=no

4.2.4. DUNDi
DUNDi es un sistema peer to peer para localizar puertas de enlaces desde internet
hacia servicios de telefonía. Es un sistema totalmente distribuido sin la presencia de
una autoridad centralizada.
4.2 Interconexión Asterisk 171

DUNDi es como un gran guía de teléfonos que permite que se pregunte a diferentes
pares si conocen una ruta de VoIP alternativa hacia un número de extensión o número
telefónico de la PSTN.
Este sistema ejecuta las consultas dinámicamente, bien mediante el comando switch
en el archivo extension.conf, o mediante el uso de la aplicación DUNDiLookup(). Sin
embargo DUNDi está disponible solo para Asterisk 1.2 o una versión mayor.
Se puede utilizar también el protocolo DUNDi en una red privada, permitiendo que
múltiples servidores Asterisk (ubicados en cada sucursal de una empresa por ejemplo,
e interconectados entre ellos) puedan ejecutar consultas dinámicas sobre la dirección
VoIP de una extensión particular en la red.
Conclusión
5. Conclusión final

Una vez obtenido nuestro potencial cliente y efectuadas las diversas entrevistas para
realizar el relevamiento técnico, se pudo detectar que para los tiempos prácticos de
las empresas, un buen comienzo y una solución real era resolver de manera puntual
los problemas de su sistema de comunicación que representaban pérdida de tiempo y
dinero para la misma.

Con este enfoque la solución de Asterisk quedó acotada y permitió que los plazos
de diseño fueran razonables y útiles. Sin embargo, a partir de aquí se podrán ir
incorporando aplicaciones adicionales, como por ejemplo interconexión entre las
sucursales de la empresa usando el protocolo IAX para interconectar servidores
Asterisk, como se explicó en el presente trabajo.
Durante la instalación y configuración de Asterisk para realizar el presente dise-
ño surgieron algunas apreciaciones en cuanto a este sistema como una solución
de comunicaciones; diseñar una PBX Asterisk no resulta una tarea trivial y lleva
bastante tiempo internalizar los conceptos referentes al funcionamiento, manejo
de los dial plans, archivos de configuración y demás. Aunque una vez que esto se
ha logrado, queda confirmada la versatilidad y el dinamismo que imprime a las
soluciones de comunicación posibles, permitiendo que el desarrollador pueda con-
jugar sus conocimientos y creatividad para atacar los problemas y requerimientos
de una empresa.
Desde el punto de vista de un emprendimiento de telecomunicaciones, los costos
de una implementacion Asterisk respecto de una central tradicional caen en de-
pendencia directa respecto de las aplicaciónes que la empresa requiera: Asterisk
realmente se convierte en una solución rentable cuando la empresa explota sus
diversas posibilidades de base de datos, interconexión de PBX, manejo de CDR,
IVR totalmente personalizable, uso de comunicaciones VoIP, entre otros.
Ofrecer una solución VoIP basada en Asterisk representa un mayor desafío para
el emprendedor debido a que lo convierte a uno en un desarrollador propiamen-
te dicho y no en un simple revendedor de tecnología propietaria. Esto es así ya
que se deberá, no solo proporcionar el equipamiento, sino además generar la im-
plementación que brinde la solución a un conjunto de necesidades específicas del
cliente.

A partir de este diseño, quedaría para una futura investigación analizar los rendimientos
de ancho de banda para manejar comunicaciones multimedia utilizando distintos codecs
para los diversos tipos de canales. También sería de gran utilidad medir la robustez de
una instalación específica, atancando el servidor con conexiones para comprobar su
tolerancia y respuesta frente a múltiples llamadas.
Apéndice
A. Acrónimos y siglas

AA Auto Attendant
ACK Acknowledge
ADSI Analog Display Services Interface
ADSL Asincronic Digital
AGI
APCM Adaptable Diferencial Pulse Code Modulation
ATA Analog Telephone Adaptor
BIOS
BRI Basic Rate Interfase
CAC Carrier Access Corporation
CBR Constant Bit Rate
CDR Call Detail Recorder
CLI Command-Line Interface
CO Central Office
CODEC COder/DECoder
CPU Central Processor Unit
CS-ACELP Conjugate-Structure Algebraic-Code-Excited Linear Prediction

CVS Concurrent Versioning System

DHCP Dinamic Host Configuration Protocol
DID Direct Inward Dialing
DISA Dinamic ISA
DSL
DSP Digital Processor Signal
DTMF Dual Tone Multi-Frequency
 176

DUNDi Distributed Universal Number Discovery

E-mail Electronic Mail

ET Enterprise telephony
FAX File Analog exchange
FCC Federal Communications Commission
FIR Finit Impulse Response
FPGA Field-Programmable Gate Arrays
FPU Float Point Unit
FQDN Fully Qualified Domain Name
FTP File Transfer Protocol
FWD Free World Dial up
FXO Foreign eXchange Office
FXS Foreign eXchange Station
GCC Compilador de C
GIPS Global IP Sound
GNU
GPL General Public License
GSM
H.245
H.323
HP Hewlett-Packard
HTTP HiperText T Protocol
IAX Inter-Asterisk eXchange

IAX2 Inter-Asterisk eXchange Version 2

IETF Internet Engineering Task Force
iLBC Internet Low Bitrate Codec
IP Internet Protocol
ISDN Integrated Services Digital Network
IT Information Technology
ITU International Telecomunication Union
 177

IVR Interactive Voice Response

KTS Key Telephone Systems

MB Mega Byte
MGCP Media Gateway Control Protocol
MMX Tecnologia MMX
MOH Music On Hold
MP3 Moving Picture Experts Group Audio Layer 3 Encoding Standard
MSN Microsoft Network
MWI Message Waiting Indication
MySQL My Structured Query Language
NAT Network Address Translation
PABX Private Automatic Branch Exchange
PBX Private Branch eXchange
PC Personal Computer
PCI
PCM Pulse Code Modulation
PCS Personal Communications Service
PDA PDA
PPP Point to Point Protocol
PRI Primary Rate Interfase
PSTN Public Switched Telephone Network
PyME Pequeña y Mediana Empresa
RAS Remote Access Server

RBS Robbed Bit Siggnalling

RFC Request for Comment
RSA Rivest, Shamir, Adleman Algorithm
RTCP Real Time Control Protocol
RTP Real Time Protocol
SCCP Skinny Client Control Protocol
SIP Session Initiation Protocol
 178

SMTP Simple Mail Transfer Protocol

SOHO Small Office Home Office

TCP Transmission Control Protocol
TDM Time Division Multiplexing
TOS Type of Service
UBP Universidad Blas Pascal
UDP User Datagram Protocol
UPS Unit Power Supply
URL Universal Resource Location
UTP Unwired twisted pair
VBR Variable BitRate
VOFR Voice over Frame Relay
VoIP Voice over IP
WAN Wide Area Network
WEB Web
Bibliografía

[1] Bezama, Eric Báez.2006 -Ventajas del Software GNU frente a otro tipo de sotfware- Software
Libre Chile (www.softwarelibre.cl).
[2] Cambronero,David Fernández, Eberhard Zangger.2005 -Voz sobre IP, la revolución de las
redes telefónicas- Novatika Upgrade.
[3] Gagliardi, Alejo.2006 -Asterisk configuración e implementación- NexIT Specialist no 22.
[4] García, Rafael Achaerandio.2005 -Oportunidades de negocio y nuevos servicios y aplicaciones
en las redes del futuro- IDC España.

[5] Gomillion, David.2005 -Nortel NorStar to Asterisk connection- Nortel rev02.

[6] IETF RFC 1889.2000 -RTP: A transport protocol for real-time applications.
[7] IETF RFC 1890.2000 -RTP: profile for audio and video conferences with minimal control.
[8] IETF RFC 2327.2001 -SDP: Session Description Protocol.
[9] IETF RFC 2974.2001 -SAP: Session Announcement Protocol.
[10] IETF RFC 3261.2001 -SIP: Session Initiaton Protocol.
[11] ITU-T Recommendation H.245.2000 -Control protocol for multimedia communication.
[12] ITU-T Recommendation H.323.2000 -Packet-based multimedia communication systems.
[13] Mata, Iago Soto.2005 -Soluciones VoIP en Linux - Adianta (www.adianta.net).
[14] Meggelen, Jim Van.2004 -Asterisk documentation proyect Volumen One: An introduction to
Asterisk - The Asterisk Documentation Proyect.
[15] Meggelen, Jim Van.2005 -Asterisk The future of Telephony- O´Reilly
[16] Sitio oficial Asterisk.2006 - http://www.asterisk.org.
[17] Sitio oficial The VoIP Wiki - a reference guide to all things VOIP.2006 - http://voip-info.org
[18] Spenser, Marck.2005 -Introduction to the Asterisk Open Source PBX - Digium.
[19] Spenser, Marck.2005 -The Asterisk Handbook Version 2 - Digium.
[20] Tamusiunas, Fabricio.2005 -Asterisk, configuracion y gerenciamiento- Nic.br (www.nic.br).