Implementación de un sistema VoIP con Asterisk

ESCUELA TCNICA SUPERIOR DE INGENIERA INFORMTICA
IGNACIO LUENGO NARANJO

TELEFONA DE CDIGO ABIERTO ASTERISK: CASO
PRCTICO DE LA IMPLANTACIN DE UN SISTEMA DE
TELEFONA VOIP EN UNA EMPRESA

Realizado por
IGNACIO LUENGO NARANJO

Dirigido por
ALEJANDRO CARRASCO MOZ

Departamento
TECNOLOGA ELECTRNICA

Sevilla, mayo 2009
NDICE
Telefona de cdigo abierto Asterisk i

NDICE

Introduccin---------------------------------------------------------------------------------------8
Prefacio------------------------------------------------------------------------------------------------- 8
Objetivos--------------------------------------------------------------------------------------------- 11

I. Entorno tecnolgico de la VoIP

1. Protocolos VoIP ---------------------------------------------------------------------------- 14
1.1 Introduccin------------------------------------------------------------------------------------ 14
1.2 Protocolo de inicio de sesin: SIP------------------------------------------------------ 15
1.1.1 Protocolos asociados a SIP ----------------------------------------------------------------------- 15
1.1.1.1 Real Time Protocol (RTP) ------------------------------------------------------------------- 16
1.1.1.2 Real-Time Control Protocol (RTCP)------------------------------------------------------- 16
1.1.1.3 Session Description Protocol (SDP)------------------------------------------------------- 16
1.1.2 Elementos de una red SIP------------------------------------------------------------------------- 17
1.1.2.1 Agente de usuario ----------------------------------------------------------------------------- 17
1.1.2.2 Servidores SIP---------------------------------------------------------------------------------- 18
1.1.3 Tipos de mensajes SIP----------------------------------------------------------------------------- 19
1.1.3.1 Formato y tipo de las peticiones SIP------------------------------------------------------ 20
1.1.3.2 Formato y tipo de las respuestas SIP----------------------------------------------------- 20
1.1.4 Formato y campos de las cabeceras SIP------------------------------------------------------ 21
1.1.5 Direccionamiento en SIP--------------------------------------------------------------------------- 23
1.1.6 Mecanismos de seguridad en SIP--------------------------------------------------------------- 24
1.1.7 Intercambio de mensajes en el establecimento de una sesin SIP --------------------- 27
1.1.8 Problemas de SIP al atravesar dispositivos NAT -------------------------------------------- 32
1.1.8.1 Problemas con la sealizacin SIP-------------------------------------------------------- 33
1.1.8.2 Problemas con el flujo RTP ----------------------------------------------------------------- 35
1.2 Protocolo H.323------------------------------------------------------------------------------- 36
1.2.1 Introduccin ------------------------------------------------------------------------------------------- 36
1.2.2 Protocolos asociados a H.323 -------------------------------------------------------------------- 37
1.2.2.1 Protocolo H.225.0------------------------------------------------------------------------------ 37
1.1.2.2 Protocolo H.245 -------------------------------------------------------------------------------- 37
1.1.2.3 Protocolos RTP y RTCP --------------------------------------------------------------------- 37
1.2.3 Elementos de una red H.323---------------------------------------------------------------------- 38
1.2.3.1 Gatekeeper -------------------------------------------------------------------------------------- 38
1.2.3.2 Terminal ------------------------------------------------------------------------------------------ 40
1.2.3.3 Gateway o pasarela --------------------------------------------------------------------------- 40
1.2.3.4 MCU (Multipoint Control Unit)--------------------------------------------------------------- 40
1.2.4 Direccionamiento en H.323------------------------------------------------------------------------ 40
1.2.5 La sealizacin en H.323 -------------------------------------------------------------------------- 40
1.2.6 Fases de una llamada H.323---------------------------------------------------------------------- 41
1.2.6.1 Fase 1: Establecimiento de la conexin-------------------------------------------------- 42
1.2.6.2 Fase 2: Comunicacin inicial e intercambio de capacidades ----------------------- 43
1.2.6.3 Fase 3: Establecieminto de la comunicacin ------------------------------------------- 44
1.2.6.4 Fase 4: Servicios de llamada --------------------------------------------------------------- 44
1.2.6.5 Fase 5: Terminacin de la llamada-------------------------------------------------------- 44
1.3 Protocolo IAX---------------------------------------------------------------------------------- 45
1.3.1 Introduccin ------------------------------------------------------------------------------------------- 45
1.3.2 Fases de una llamada utilizando el protocolo IAX------------------------------------------- 46
1.3.2.1 Fase 1: Establecimiento de la llamada-------------------------------------------------- 47
1.3.2.2 Fase 2: Flujo de datos o flujo de audio --------------------------------------------------- 47
NDICE
Telefona de cdigo abierto Asterisk ii

1.3.2.3 Fase 3: Liberacin de la llamada o desconexin--------------------------------------- 47
2. Codificadores-Decodificadores: Cdecs------------------------------------------ 48
2.1 Introduccin------------------------------------------------------------------------------------ 48
2.2 Proceso de conversin analgico-digital--------------------------------------------- 48
2.1.1 Fase 1: Muestreo ------------------------------------------------------------------------------------ 48
2.1.2 Fase 2: Cuantificacin ------------------------------------------------------------------------------ 49
2.1.2.1 Tcnica de cuantificacin Uniforme ------------------------------------------------------- 49
2.1.2.2 Tcnica de cuantificacin No uniforme --------------------------------------------------- 50
2.1.2.3 Tcnica de cuantificacin Logartmica---------------------------------------------------- 50
2.1.2.4 Tcnica de cuantificacin Vectorial -------------------------------------------------------- 51
2.1.3 Fase 3: Codificacin--------------------------------------------------------------------------------- 51
2.3 Tipos de codificadores de voz ----------------------------------------------------------- 51
2.3.1 Codificadores de la forma de onda -------------------------------------------------------------- 51
2.3.1.1 Codificadores en el dominio del tiempo -------------------------------------------------- 52
2.3.1.2 Codificadores en el dominio de la frecuencia------------------------------------------- 52
2.3.2 Vocoders ----------------------------------------------------------------------------------------------- 53
2.3.3 Codificadores hbridos ------------------------------------------------------------------------------ 53
2.4 Tabla Resumen de los principales cdecs de audio------------------------------ 53
2.5 Influencias en el Ancho de Banda consumido por una comunicacin ----- 54
2.5.1 Influencia del cdec en el ancho de banda---------------------------------------------------- 54
2.5.2 Influencia de las capas 2 y 3 en el ancho de banda----------------------------------------- 55
3. Calidad de servicio (QoS, Quality of Service)------------------------------------ 57
3.1 Introduccin------------------------------------------------------------------------------------ 57
3.2 Factores que afectan a la calidad de servicio--------------------------------------- 57
3.2.1 Cdec utilizado en la comunicacin------------------------------------------------------------- 57
3.2.2 Retardo o Latencia ---------------------------------------------------------------------------------- 57
3.2.2.1 Retardo por causa del algoritmo ----------------------------------------------------------- 58
3.2.2.2 Retardo por causa de la paquetizacin--------------------------------------------------- 58
3.2.2.3 Retardo por causa de la serializacin----------------------------------------------------- 59
3.2.2.4 Retardo por causa de la propagacin----------------------------------------------------- 60
3.2.2.5 Retardo por causa de los componentes-------------------------------------------------- 60
3.2.2.6 Problemas causados por el Retardo: Eco y Solapamiento-------------------------- 60
3.2.3 Jitter ----------------------------------------------------------------------------------------------------- 62
3.2.4 Prdida de paquetes -------------------------------------------------------------------------------- 63
3.3 Protocolos para mejorar la calidad de servicio------------------------------------- 63
3.3.1 802.1p--------------------------------------------------------------------------------------------------- 63
3.3.2 Diffserv-------------------------------------------------------------------------------------------------- 64
3.3.3 802.1q VLAN------------------------------------------------------------------------------------------ 64
3.3.4 Intserv (Integrated Service) y RSVP ------------------------------------------------------------ 65
3.3.5 MPLS---------------------------------------------------------------------------------------------------- 65

II. Plataforma Asterisk

4. Asterisk---------------------------------------------------------------------------------------- 67
4.1 Qu es un PBX?----------------------------------------------------------------------------- 67
4.2 Qu es Asterisk?---------------------------------------------------------------------------- 68
4.3 Arquitectura de Asterisk ------------------------------------------------------------------- 68
4.4 Concepto de Canales en Asterisk------------------------------------------------------- 70
NDICE
Telefona de cdigo abierto Asterisk iii

4.5 Asterisk en diferentes escenarios ------------------------------------------------------ 71
4.5.1 Llamadas internas en nuestra oficina----------------------------------------------------------- 71
4.5.2 Conectar nuestra oficina con Internet ----------------------------------------------------------- 72
4.5.3 Conectar nuestra oficina con la RTB------------------------------------------------------------ 72
4.6 Tipos de terminales VoIP usados con Asterisk------------------------------------- 73
4.7 Formas de conectar Asterisk con la Red Telefnica Bsica ------------------- 76
4.7.1 Conexin mediante una lnea de telfono bsica-------------------------------------------- 76
4.7.2 Conexin mediante una lnea RDSI ------------------------------------------------------------- 77
4.8 Recorrido por el mercado actual de la telefona de cdigo abierto ---------- 80
4.8.1 Nivel 1: Plataformas de telefona----------------------------------------------------------------- 80
4.8.2 Nivel 2: Soluciones gratuitas configurables---------------------------------------------------- 81
4.8.3 Nivel 3: Soluciones de pago llave en mano --------------------------------------------------- 81

III. Caso Prctico: Implantacin de un sistema de telefona VoIP en una
empresa utilizando Asterisk.

5. Descripcin del Caso Prctico-------------------------------------------------------- 84
5.1 Introduccin------------------------------------------------------------------------------------ 84
5.2 Descripcin del sistema de telefona actual ----------------------------------------- 84
5.3 Requisitos de la empresa al nuevo sistema de telefona ----------------------- 85
5.3.1 Requisito 1: Extensiones y buzones de voz--------------------------------------------------- 85
5.3.2 Requisito 2: Mensajera unificada---------------------------------------------------------------- 86
5.3.3 Requisito 3: Reutilizacin de las lneas analgicas------------------------------------------ 86
5.3.4 Requisito 4: Incorporacin de dos lneas mviles-------------------------------------------- 86
5.3.5 Requisito 5: Men de bienvenida con opciones---------------------------------------------- 86
5.3.6 Requisito 6: Gestin de llamadas del Departamento Tcnico ---------------------------- 87
5.3.7 Requisito 7: Gestin de llamadas para los Departamentos Comercial y de Desarrollo
------------------------------------------------------------------------------------------------------------------- 87
5.3.8 Requisito 8: Servicios comunes de telefona-------------------------------------------------- 88
5.4 Soluciones a los requisitos planteados----------------------------------------------- 88
5.4.1 Solucin al Requisito 1: Extensiones y buzones de voz ----------------------------------- 88
5.4.2 Solucin al Requisito 2: Mensajera unificada ------------------------------------------------ 88
5.4.3 Solucin al Requisito 3: Reutilizacin de las lneas analgicas ------------------------- 88
5.4.4 Solucin al Requisito 4: Incorporacin de dos lneas mviles ---------------------------- 88
5.4.5 Solucin al Requisito 5: Men de bienvenida con opciones ------------------------------ 89
5.4.6 Solucin al Requisito 6: Gestin de llamadas del Departamento Tcnico------------- 89
5.4.7 Solucin al Requisito 7: Gestin de llamadas para los Departamentos Comercial y
de Desarrollo ------------------------------------------------------------------------------------------------- 89
5.4.8 Solucin al Requisito 8: Servicios comunes de telefona ---------------------------------- 89
5.5 Arquitectura del nuevo sistema de telefona ---------------------------------------- 89
6. Instalacin de Asterisk------------------------------------------------------------------- 91
6.1 Introduccin------------------------------------------------------------------------------------ 91
6.2 Consideraciones previas a la instalacin de Asterisk---------------------------- 91
6.3 Instalacin de los componentes hardware, del S.0. y de Asterisk ----------- 92
6.3.1 Instalacin de las tarjetas analgicas TDM400P--------------------------------------------- 92
6.3.2 Instalacin de las interfaces con la red mvil ------------------------------------------------- 93
6.3.3 Instalacin del sistema operativo ---------------------------------------------------------------- 96
6.3.4 Instalacin de Asterisk------------------------------------------------------------------------------ 97
7. Configuracin de Asterisk------------------------------------------------------------ 101
NDICE
Telefona de cdigo abierto Asterisk iv

7.1 Introduccin-----------------------------------------------------------------------------------101
7.2 Cambio de los ficheros de audio del ingls al espaol -------------------------101
7.3 Empezar a configurar el Plan de Marcacin ----------------------------------------103
7.3.1 Contextos -------------------------------------------------------------------------------------------- 103
7.3.2 Extensiones ----------------------------------------------------------------------------------------- 106
7.3.3 Prioridades------------------------------------------------------------------------------------------- 107
7.3.4 Aplicaciones----------------------------------------------------------------------------------------- 108
7.3.5 Ejemplo: Utilidad para grabar sonido --------------------------------------------------------- 109
7.4 Configuracin del canal Dahdi ----------------------------------------------------------110
7.4.1 Verificacin de la instalacin de las tarjetas TDM400P ---------------------------------- 110
7.4.2 Configuracin de los archivos system.conf y chan_dahdi.conf --------------------- 114
7.4.3 Utilizar el canal Dahdi para realizar llamadas----------------------------------------------- 117
7.5 Configuracin del canal SIP -------------------------------------------------------------120
7.5.1 Parmetros generales del canal SIP---------------------------------------------------------- 121
7.5.2 Definicin de clientes SIP------------------------------------------------------------------------ 122
7.6 Configuracin del Buzn de voz -------------------------------------------------------123
7.6.1 El archivo voicemail.conf ------------------------------------------------------------------------- 123
7.6.2 El buzn de voz en el plan de marcacin---------------------------------------------------- 125
7.6.3 Configuracin del servidor de correo exim4------------------------------------------------- 127
7.6.4 Personalizar el mensaje de correo electrnico --------------------------------------------- 129
7.7 Variables y funciones ----------------------------------------------------------------------130
7.7.1 Variables --------------------------------------------------------------------------------------------- 131
7.7.2 Funciones-------------------------------------------------------------------------------------------- 132
7.8 Uso de Expresiones y Macros-----------------------------------------------------------134
7.8.1 Expresiones ----------------------------------------------------------------------------------------- 134
7.8.2 Macros------------------------------------------------------------------------------------------------ 137
7.9 Configuracin de servicios avanzados-----------------------------------------------138
7.9.1 Respuesta de voz interactiva ------------------------------------------------------------------- 139
7.9.1.1 Extensiones estndares-------------------------------------------------------------------- 139
7.9.1.2 Aplicacin Background() ------------------------------------------------------------------- 140
7.9.2 Distribucin automtica de llamadas---------------------------------------------------------- 144
7.9.3 Salas de conferencia------------------------------------------------------------------------------ 150
7.9.4 Estacionamiento, captura y transferencia de llamadas----------------------------------- 153
7.9.4.1 Estacionamiento de llamadas------------------------------------------------------------- 153
7.9.4.2 Captura de llamadas ------------------------------------------------------------------------ 154
7.9.4.3 Transferencia de llamadas ---------------------------------------------------------------- 156
8. Configuracin de los terminales telefnicos----------------------------------- 159
8.1 Introduccin-----------------------------------------------------------------------------------159
8.2 Configuracin del softphone X-Lite ---------------------------------------------------159
8.3 Configuracin de los telfonos IP -----------------------------------------------------161
8.3.1 Asignacin de una direccin IP mediante DHCP ------------------------------------------ 162
8.3.2 Asignacin de una direccin IP esttica------------------------------------------------------ 163
8.3.3 Configurar los datos de la cuenta SIP mediante la interfaz web ----------------------- 164
8.3 Configuracin de los telfonos analgicos-----------------------------------------166
8.3.1 Asignar una direccin IP dinmica mediante DHCP -------------------------------------- 167
8.3.2 Asignar una direccin IP esttica -------------------------------------------------------------- 167
8.3.3 Configurar la cuenta SIP mediante la interfaz web ---------------------------------------- 168
9. Conclusiones------------------------------------------------------------------------------ 170
10. Referencias------------------------------------------------------------------------------- 171

NDICE
Telefona de cdigo abierto Asterisk v

NDICE DE FIGURAS

Figura 1. Crecimiento en billones de minutos del trfico de la telefona tradicional y VoIP de
1998 a 2008. -----------------------------------------------------------------------------------------------------------8
Figura 2. Porcentaje de hogares que usan VoIP en pases europeos. ---------------------------------9
Figura 3. Pila de protocolos de SIP. --------------------------------------------------------------------------- 16
Figura 4. Tipos de servidores SIP.----------------------------------------------------------------------------- 19
Figura 5. Escenario del ejemplo de registro de un usuario en un servidor. ------------------------- 24
Figura 6. Flujo de mensajes al registrarse por primera vez un usuario en un servidor. ---------- 25
Figura 7. Primera peticin de registro. ------------------------------------------------------------------------ 25
Figura 8. Desafo del servidor.---------------------------------------------------------------------------------- 25
Figura 9. Segunda peticin de registro. ---------------------------------------------------------------------- 26
Figura 10. Respuesta de confirmacin. ---------------------------------------------------------------------- 27
Figura 11. Escenario del ejemplo de establecimiento de una sesin SIP.--------------------------- 27
Figura 12. Intercambio de mensajes en una sesin SIP. ------------------------------------------------ 29
Figura 13. Trapecio SIP. ----------------------------------------------------------------------------------------- 29
Figura 14. Invite de Juan a Proxy 1.--------------------------------------------------------------------------- 30
Figura 15. Reenvio de peticin de Proxy 1 a Proxy 2. ---------------------------------------------------- 31
Figura 16. Reenvio de peticin de Proxy 2 a Ana.--------------------------------------------------------- 32
Figura 17. Respuesta bloqueada por el dispositivo NAT.------------------------------------------------ 33
Figura 18. Peticin y respuesta pasan por el mismo puerto.-------------------------------------------- 34
Figura 19. Peticin del Proxy bloqueada por el dispositivo NAT. -------------------------------------- 34
Figura 20. Conexin RTP fallida entre los clientes A y B. ----------------------------------------------- 35
Figura 21. Pila de protocolos de H.323. ---------------------------------------------------------------------- 38
Figura 22. Proceso de registro en H.323. -------------------------------------------------------------------- 39
Figura 23. Gatekeeper H.323 en modo Direct routed. -------------------------------------------------- 39
Figura 24. Gatekeeper H.323 en modo Gatekeeper routed. ------------------------------------------ 39
Figura 25. Escenario de ejemplo de una llamada entre dos terminales. ----------------------------- 42
Figura 26. Secuencia de mensajes en la fase Establecimiento de la conexin con el
Gatekeeper en modo Direct routed.-------------------------------------------------------------------------- 42
Gatekeeper en modo Gatekeeper routed. ------------------------------------------------------------------ 43
Figura 28. Secuencia de mensajes en la fase Comunicacin inicial e intercambio de
capacidades.-------------------------------------------------------------------------------------------------------- 44
Figura 29. Secuencia de mensajes en la fase Establecimiento de la comunicacin. ----------- 44
Figura 30. Secuencia de mensajes en la fase Terminacin de la llamada. ----------------------- 45
Figura 31. Intercambio de mensajes en una llamada IAX2. --------------------------------------------- 47
Figura 32. Proceso de muestreo. ------------------------------------------------------------------------------ 49
Figura 33. Divisin de la amplitud de la seal en ocho intervalos. ------------------------------------ 50
Figura 34. Longitud total en bits de un paquete IP sobre Ethernet utilizando el cdec G.711. - 56
NDICE
Telefona de cdigo abierto Asterisk vi

Figura 35. ndice de satisfaccin de los usuarios con respecto a la latencia.----------------------- 62
Figura 36. Subsistemas de Asterisk. -------------------------------------------------------------------------- 69
Figura 37. Canales en Asterisk. -------------------------------------------------------------------------------- 70
Figura 38. Asterisk en una red interna. ----------------------------------------------------------------------- 71
Figura 39. Asterisk conectado a Internet. -------------------------------------------------------------------- 72
Figura 40. Asterisk conectado a la RTB. --------------------------------------------------------------------- 73
Figura 41. Interfaz del softphone Zoiper.--------------------------------------------------------------------- 74
Figura 42. Interfaz del softphone X-Lite. --------------------------------------------------------------------- 74
Figura 43. Modelo Snom 360. ---------------------------------------------------------------------------------- 74
Figura 44. Modelo SoundPoint IP 501 de Polycom.------------------------------------------------------- 75
Figura 45. Modelo S101I IAXy de Digium. ---------------------------------------------------------------- 75
Figura 46. Modelo Linksys PAP2T.---------------------------------------------------------------------------- 75
Figura 47. Modelo AX800 de Digium con ocho puertos analgicos. ---------------------------------- 76
Figura 48. Interfaces FXS y FXO.------------------------------------------------------------------------------ 77
Figura 49. Modelo Linksys SPA 3102. ------------------------------------------------------------------------ 77
Figura 50. Modelo duoBRI de Junghanns. ------------------------------------------------------------------ 78
Figura 51. Modelo BNS80 de Beronet. ----------------------------------------------------------------------- 79
Figura 52. Modelo B410P de Digium.------------------------------------------------------------------------- 79
Figura 53. Modelo TE120P de Digium. ----------------------------------------------------------------------- 79
Figura 54. Disposicin actual del sistema telefnico de la empresa. --------------------------------- 85
Figura 55. Opciones del men deseadas por la empresa. ---------------------------------------------- 86
Figura 56. Arquitectura del nuevo sistema telefnico de la empresa. -------------------------------- 90
Figura 57. Tarjeta Digium TDM400P. ------------------------------------------------------------------------- 92
Figura 58. Montaje de la tarjeta TDM400P en el bus PCI.----------------------------------------------- 93
Figura 59. Terminal fijo celular Ericsson F250m. ---------------------------------------------------------- 94
Figura 60. Terminal fijo celular Audiotel Celline III. -------------------------------------------------------- 94
Figura 61. Lugar donde insertar la tarjeta SIM en el terminal fijo celular Ericsson F250m. ----- 95
Figura 62. Lugar donde insertar la tarjeta SIM en el terminal fijo celular Audiotel Celline III. --- 95
Figura 63. Pantalla inicial del proceso de instalacin de Debian. -------------------------------------- 96
Figura 64. Resultado de ejecutar lsmod en el sistema. ---------------------------------------------- 111
Figura 65. Resultado de ejecutar la herramienta dahdi_scan.-------------------------------------- 112
Figura 66. Resultado de ejecutar cat /proc/interrupts en el sistema.------------------------------ 113
Figura 67. Resultado de ejecutar la herramienta dahdi_test. --------------------------------------- 113
Figura 68. Atributos rxgain y txgain. --------------------------------------------------------------------- 115
Figura 69. Resultado de ejecutar la herramienta dahdi_cfg vvv. --------------------------------- 117
Figura 70. Correo electrnico enviado por Asterisk. ---------------------------------------------------- 130
Figura 71. Funcionamiento de una distribucin automtica de llamadas. ------------------------- 144
Figura 72. Representacin de una sala de conferencia con tres usuarios.------------------------ 150
Figura 73. El Usuario 2 aparca la llamada pulsando #700.------------------------------------------ 154
NDICE
Telefona de cdigo abierto Asterisk vii

Figura 74. El usuario 2 recupera la llamada aparcada marcando el nmero que la centralita le
ha indicado, es este caso 701. ------------------------------------------------------------------------------ 154
Figura 75. Usuario 1 intenta llamar a un telfono donde no hay nadie. ---------------------------- 155
Figura 76. Usuario 2 marca *8 capturando la llamada y establece comunicacin con Usuario
1.---------------------------------------------------------------------------------------------------------------------- 155
Figura 77. Usuario 2 realiza una transferencia ciega hacia el Usuario 3 con etensin 2100.- 157
Figura 78. La extensin 2100 comienza a sonar, si el Usuario 3 descolgase se establecera
comunicacin con Usuario 1. ---------------------------------------------------------------------------------- 157
Figura 79. Usuario 2 realiza una transferencia atendida hacia el Usuario 3 con etensin 2100.
------------------------------------------------------------------------------------------------------------------------ 157
Figura 80. Usuario 2 entra en comunicacin con Usuario 3 mientras Usuario 1 est en espera.
------------------------------------------------------------------------------------------------------------------------ 158
Figura 81. Al colgar el usuario 2, se establece comunicacin entre los usuarios 1 y 3.-------- 158
Figura 82. Al colgar el usuario 3, el usuario 2 retoma la comunicacin con el usuario 1.------ 158
Figura 83. Interfaz de X-Lite y pantalla SIP Accounts.------------------------------------------------ 160
Figura 84. Pantalla para la configuracin de los datos de un usuario SIP en X-Lite. ----------- 160
Figura 85. Modelo SPA922 de Linksys. -------------------------------------------------------------------- 161
Figura 86. Modelo BudgetTone de Grandstream. ------------------------------------------------------- 161
Figura 87. Interfaz web del modelo Linksys SPA922. -------------------------------------------------- 164
Figura 88. Interfaz web del modelo Grandstream Budgedtone 200. -------------------------------- 166
Figura 89. Conexin de un telfono analgico con el adaptador Linksys PAP2. ---------------- 167
Figura 90. Interfaz web del modelo Linksys PAP2.------------------------------------------------------ 169

NDICE DE TABLAS

Tabla 1. Datos de los participantes en el ejemplo de registro de un usuario en un servidor. .... 24
Tabla 2. Datos de los participantes en el ejemplo de establecimiento de una sesin SIP. ....... 28
Tabla 3. Caractersticas de los cdecs ms utilizados. .............................................................. 53
Tabla 4. Consumo de ancho de banda de los cdecs ms usados. .......................................... 55
Tabla 5. Consumo de ancho da banda total de los cdecs ms habituales. ............................. 56
Tabla 6. Retardo de los principales cdecs. ............................................................................... 58
Tabla 7. Retardo de los principales cdecs para un tiempo de paquetizacin de 20ms. .......... 59
Tabla 8. Retardo dependiendo de la velocidad del enlace......................................................... 60

Introduccin
Telefona de cdigo abierto Asterisk 8

Introduccin
Prefacio
La telefona IP o tambin llamada voz sobre IP (VoIP, Voice over IP), ha
revolucionado el mundo de las telecomunicaciones en los ltimos aos. Un
mercado, el de la telefona, que se encontraba copado por grandes compaas
de origen estatal y que usaba tecnologas que haban evolucionado muy poco a
lo largo de estos ltimos cien aos, ha visto la irrupcin de esta nueva
tecnologa de comunicacion.

Sin embargo, existe todava un gran recelo respecto al uso de esta tecnologa y
mucha gente piensa que esta revolucin es ms un eslogan comercial que una
realidad. Si atendemos a la siguiente figura
1
, podemos ver cual ha sido la
evolucin de la VoIP y de la telefona clsica en billones de minutos a lo largo
de los diez ltimos aos:

Figura 1. Crecimiento en billones de minutos del trfico de la telefona tradicional y VoIP de
1998 a 2008.

Como podemos observar, aunque el volumen de minutos de la telefona clsica
supera claramente al de VoIP actualmente, la tendencia hace apuntar que esta
ltima sobrepasar en unos aos a la telefona tradicional.

1
Datos obtenidos del informe de Telegeography, lo cuales pueden ser consultados en el
siguente enlace: http://www.telegeography.com/products/tg/index.php.
Introduccin

Tomando los datos que aparecen en la Figura 1, en el ao 2007 el crecimiento
que present la telefona clsica fue del 10% mientras que el de la voz sobre IP
fue del 28%.

En Europa, el creciemiento tambien ha ido aumentando significativamente ya
que si al final del ao 2004 el equivalente al 1% de los hogares europeos
estaba suscrito a un servicio de VoIP, al final del ao 2007 esta cifra se situaba
en el 17%.

Estas cifras nos revelan sin duda que la telefona IP no es una promesa sino
una realidad constatable.

Si bien, como podemos apreciar en la Figura 2
2
, en Europa la penetracin de la
VoIP depende mucho de un pas a otro.

Figura 2. Porcentaje de hogares que usan VoIP en pases europeos.

As, mientras en Francia el nmero de hogares que utilizan VoIP es del 43%,
en de paises como Espaa no llega al 2%.

Esta irrupcin de la telefona IP en el mundo de las comunicaciones ha
propiciado la llegada de nuevos operadores (como Skype, Voipbuster, etc) que
en un escenario controlado por grandes compaias de telecomunicaciones
empiezan a ganar terreno.

Sin embargo, los operadores tradicionales siguen siendo los principales
proveedores de VoIP debido entre otras cosas a su posicin dominante en el
mercado.

2
Datos obtenidos del informe de Telegeography lo cuales pueden ser consultados en el
siguente enlace: http://www.telegeography.com/products/euro_voip/index.php.
Introduccin

Adems de la llegada de nuevos operadores, la voz sobre IP ha propiciado
tambin la creacin de plataformas de telefona de cdigo abierto bajo licencia
GPL (General Public Licence), las cuales proporcionan la base para la creacin
de soluciones de telefona a medida y a bajo coste. Cualidades en las que
radica la fuerza de estas plataformas.

Dentro de estas plataformas, la que ha irrumpido con ms fuerza es sin duda
Asterisk, la cual es a su vez el nombre de la centralita telefnica desarrollada
con esta plataforma. Fue creada en 1999 por Mark Spencer como alternativa a
las soluciones de telefona tradicional que dominaban el mercado de esos
aos.

Actualmente Aserisk cuenta con la comunidad de desarrolladores ms
numerosa y activa de todas las plataformas existentes, con ms de 400
contribuidores activos en el ltimo ao y unos 56.000 participando en foros.

Nada ms que en el ao 2008, se han contabilizado un total de 4.000.000 de
descargas de Asterisk, un 50% ms que en el ao 2008 y en el 2009 todo
augura a que la cifra seguir creciendo
3
.

3
Datos obtenidos del informe de Frost & Sullivan para Digium, el cual puede ser consultado en
el enlace: https://www.digium.com/en/supportcenter/documentation/viewdocs/telephony.
Introduccin

Objetivos
Este documento pretende ser una guia de iniciacin a la plataforma de telefona
de cdigo abierto Asterisk. Para ello se han identificado los siguientes
objetivos:

1) Descripcin del entorno tecnolgico de la telefona IP:

En un entorno tecnolgico tan heterogneo como el de las comunicaciones, y
particularmente el de la telefona IP por ser encuentro de dos mundos hasta
ahora independientes: el mundo IP y el de los estndares del mundo de las
telecomunicaciones, es necesario identificar las tecnolgias que en ella
participan y la funcin que desempean.

Este objetivo principal, comprende los siguientes puntos:

Anlisis de los aspectos ms relevantes de los protocolos que
actualmente dominan las comunicaciones de voz sobre IP poniendo
especial nfasis en el protocolo SIP.

Descripcin del proceso de transformacin de una seal analgica en
digital as como de los principales codificadores-decodificadores
(cdecs) que se utilizan en las comunicaiones actuales.

Definicin del concepto de calidad de servicio y descripcin de los
problemas por los que se ve afectada negativamente, as como los
protocolos diseados para solucionar algunos de estos problemas.

2) Descripcin de la plataforma de telefona de cdigo abierto Asterisk:

Dentro de las plataformas de telefona de cdigo abierto, describiremos en qu
consiste Asterisk y en qu situaciones puede emplearse. A su vez, se
comentarn los elementos necesarios de los que debemos disponer
dependiendo de las tecnologas con las que deseemos interactuar.

3) Instalacin y configuracin de Asterisk a travs de un caso prctico:

A travs de un caso prctico, describiremos el proceso completo y detallado de
instalacin y configuracin de Asterisk para dar servicio al nuevo sistema de
telefona de una empresa.

Dentro de este objetivo principal, podemos identificar los siguientes puntos:

Analizar el sistema actual de telefona de una empresa y proponer uno
nuevo basado en la telefnia IP, aportando las funcionalidades que
requieren los requisitos impuestos por la compaa.
Introduccin

Describir el proceso de instalacin partiendo desde cero de la plataforma
Asterisk y de los componentes hardware necesarios para su
funcionamiento.

Explicar el proceso de configuracin de Asterisk paso a paso,
introduciendo a medida que se vayan necesitando los conceptos claves
para su configuracin, haciendo especial hincapi en la sintaxis de su
lenguaje de script.

Describir el proceso de configuracin de los terminales de comunicacin
de los usuarios para el nuevo sistema de telefona de la empresa.

I I. . E En nt to or rn no o T Te ec cn no ol l g gi ic co o d de e l la a V Vo oI IP P

En esta primera parte del documento describiremos el entorno
tecnolgico donde se encuentra inmersa la telefona IP. Para ello,
comentaremos las particularidades de los protocolos que ms se usan
actualmente para realizar comunicaciones VoIP, poniendo un mayor nfasis en
explicar los detalles referentes al protocolo SIP.

As mismo, describiremos el proceso de transformacin que debe sufrir una
seal analgica al convertirse en una digital, proceso que debe seguir la voz
para ser transmitida por un medio digital. Esto nos conducir a hablar de los
diferentes tipos de codificadores que existen y de su influencia en el ancho de
banda utilizado cuando se establece una comunicacin.

Por ltimo, abordaremos el concepto de calidad de servicio en las
comunicaciones IP, comentando primero los problemas por los que se ve
afectada negativamente y los protocolos diseados para combatir algunos de
de estos problemas.

Entorno tecnolgico de la VoIP 1. Protocolos VoIP


1. Protocolos VoIP
1.1 Introduccin
Es realmente necesario utilizar unos protocolos especficos para el transporte
de voz, o basta con los ya existentes para transportar datos?

Hasta hoy en da ha habido una clara divisin entre dos tipos de redes:

Redes de voz. Estn basadas en conmutacin de circuitos. En ellas los
equipos de conmutacin deben establecer un camino fsico entre los
medios de comunicacin previo a la conexin entre los usuarios. Este
camino permanece activo durante la comunicacin entre los usuarios,
liberndose al terminar la comunicacin. El ejemplo ms claro de este
tipo de redes es la Red Telefnica Conmutada.

Redes de datos. Basadas en conmutacin de paquetes, los datos que
se van a transmitir se dividen en paquetes y se envan por separado a
travs de la red. Los nodos de la red determinan libremente la ruta de
cada paquete de manera individual, segn su tabla de enrutamiento. Los
paquetes que se envan de esta manera pueden tomar diferentes rutas y
se vuelven a montar una vez que llegan al nodo receptor. Un ejemplo de
estas redes es Internet.

El problema con la tecnologa de conmutacin de circuitos es que requiere una
significativa cantidad de ancho de banda y el circuito no es empleado
eficientemente ya que emplea un canal durante toda la duracin de la llamada
no teniendo en cuenta por ejemplo los abundantes silencios que se producen
durante una conversacin.

Las redes de datos, por el contrario, slo transmiten informacin cuando es
necesario, aprovechando al mximo el ancho de banda y en la cual el retardo,
la alteracin del orden de llegada o la prdida de paquetes no son un
inconveniente, ya que el sistema final dispone de una serie de procedimientos
de recuperacin de la informacin original. Pero para la voz y el vdeo estos
factores son altamente influyentes. Se considera que la seal transmitida debe
llegar al destino con un retardo no superior a 150 ms para que no haya
degradacin en la comunicacin.

Por lo tanto, para contestar a nuestra pregunta inicial diremos que a la hora de
transmitir voz, s es necesario disponer de unos protocolos especiales que nos
garanticen un servicio confiable.

Voz sobre IP (VoIP) define los sistemas de enrutamiento y los protocolos
necesarios para la transmisin de conversaciones de voz a travs de Internet,


la cual es una red de conmutacin de paquetes basado en el protocolo TCP/IP
para el envo de informacin.

Actualmente existen, principalmente, dos arquitecturas de VoIP para la
transmisin de voz por Internet: H.323 y SIP.

A continuacin describiremos estos dos protocolos en profundidad junto con el
protocolo IAX, el cual se encuentra muy ligado a Asterisk y posee unas
caractersticas interesantes.
1.2 Protocolo de inicio de sesin: SIP
El protocolo SIP
4
(Session Initiation Protocol) fue desarrollado por el grupo
MMUSIC (Multimedia Session Control) del IETF (Internet Engineering Task
Force), definiendo una arquitectura de sealizacin y control para la VoIP.

SIP es un protocolo de sealizacin a nivel de aplicacin para establecimiento
y gestin de sesiones con mltiples participantes. Se basa en mensajes de
peticin y respuesta y reutiliza muchos conceptos de estndares anteriores
como HTTP (HyperText Transfer Protocol) y SMTP (Simple Mail Transfer
Protocol).

SIP fue diseado de acuerdo al modelo de Internet. Es un protocolo de
sealizacin de extremo a extremo en el que toda la lgica es almacenada en
los dispositivos finales (salvo el rutado de los mensajes SIP). El estado de la
conexin es tambin almacenado en los dispositivos finales. El precio a pagar
por esta capacidad de distribucin y su gran escalabilidad es una sobrecarga
en la cabecera de los mensajes producto de tener que mandar toda la
informacin entre los dispositivos finales.
1.1.1 Protocolos asociados a SIP
El propsito de SIP es la comunicacin entre dispositivos multimedia. Para
llevar a cabo este cometido, SIP se sirve de otros protocolos para realizar
tareas como la sealizacin o el tranporte. En la Figura 3 a continuacin,
podemos ver la pila de protocolos de SIP.

4
El protocolo SIP est definido en la recomendacin RFC 3261 publicada en junio de 2002.


Figura 3. Pila de protocolos de SIP.
1.1.1.1 Real Time Protocol (RTP)
El protocolo RTP
5
provee servicios para la transmisin y entrega de
informacin en tiempo real como el audio o el vdeo. Es un protocolo situado en
la capa de sesin del modelo OSI y aunque fue diseado para ser
independiente de las capas de transporte y red, en redes IP se usa
mayoritariamente con UDP. Aunque diseado inicialmente como un protocolo
multicast, es usado tanto en aplicaciones de este tipo como en aplicaciones
unicast.

RTP no proporciona ningn mecanismo que garantice la calidad de servicio ni
la entrega en tiempo de los paquetes, confiando estas funciones a capas ms
bajas del modelo OSI. RTP va de la mano de RTCP.
1.1.1.2 Real-Time Control Protocol (RTCP)
Es el protocolo de control de RTP
6
. Su funcin principal es informar de la
calidad de servicio proporcionada por RTP. As, RTCP recoge estadsticas de
la conexin y tambin informacin como por ejemplo bytes enviados, paquetes
enviados, paquetes perdidos o jitter entre otros. Esta informacin puede usarla
una aplicacin para por ejemplo incrementar la calidad de servicio (QoS), ya
sea limitando el flujo de informacin o usando un cdec de compresin ms
baja, etc.
1.1.1.3 Session Description Protocol (SDP)
Cuando se inician videoconferencias, llamadas sobre IP, vdeo en streaming o
cualquier otro tipo de sesiones, existe la necesidad por parte de los
participantes de acordar detalles concernientes a stas como por ejemplo las
direcciones, los puertos el protocolo de transporte a utilizar, etc.

5
Definido en la recomendacin RFC 3550.
6
Definido al igual que RTP en la recomendacin RFC 3550.


El protocolo SDP
7
proporciona el formato para la representacin de dicha
informacin.

Puesto que SDP es slo un protocolo de descripcin no define ningn protocolo
de transporte, los mensajes SDP pueden ser transportados mediante distintos
protocolos tales como SAP (Session Announcement Protocol), SIP, RTSP
(Real Time Streaming Protocol), correo electrnico con aplicaciones MIME
(Multipurpose Internet Mail Extensions) o protocolos como HTTP.

SDP, al igual que SIP, utiliza una codificacin textual. As, un mensaje SDP se
compone de una serie de lneas denominadas campos
8
. Estos tienen la forma
de pares atributo-valor siendo su sintaxis:

tipo = valor

Donde tipo hace referencia al nombre del campo y son representados por una
sola letra distinguiendo entre minscula y mayscula. valor es, como su
propio nombre indica, el valor de ese campo y su formato depende de qu
tipo se trate. Los campos estn en un orden predeterminado para simplificar
el anlisis.
1.1.2 Elementos de una red SIP
SIP soporta funcionalidades para el establecimiento y finalizacin de las
sesiones multimedia: localizacin, disponibilidad, utilizacin de recursos, y
caractersticas de negociacin.

Para implementar estas funcionalidades existen dos elementos fundamentales
en una arquitectura SIP: los agentes de usuario (UA) y los servidores.
1.1.2.1 Agente de usuario
Un agente de usuario (UA, User Agent) consta de dos partes distintas: el
agente de usuario cliente (UAC, User Agent Client) y el agente de usuario
servidor (UAS, User Agent Server). Un UAC es una entidad lgica que genera
peticiones SIP y recibe respuestas a esas peticiones. Un UAS es una entidad
lgica que genera respuestas a las peticiones SIP.

Ambos se encuentran en todos los agentes de usuario, permitendo as la
comunicacin entre diferentes agentes de usuario mediante comunicaciones de
tipo cliente-servidor.

7
El protocolo SDP se encuentra definido en la recomendacin RFC 4566.
8
Los nombres de los campos y sus posibles valores se pueden consultar en el RFC 4566
seccin 5.


1.1.2.2 Servidores SIP
Los servidores SIP pueden ser de tres tipos:

1) Servidor Proxy. Retransmite peticiones y decide a qu otro servidor debe
remitirlas, alterando los campos de la solicitud en caso necesario. Es una
entidad intermedia que acta como cliente y servidor con el propsito de
establecer llamadas entre los usuarios. Este servidor tiene una funcionalidad
semejante a la de un Proxy HTTP el cual tiene la tarea de encaminar las
peticiones que recibe de otras entidades ms prximas al destinatario. Las
funciones que realiza cuando les llega una peticin son las siguientes:

Validar la peticin.
Procesar la informacin de rutado.
Determinar el destino de la peticin.
Reenviar la peticin a cada destino.
Procesar las respuestas a esa peticin.

Existen dos tipos de Servidores Proxy:

Proxy stateful: guarda informacin de cada peticin que recibe as
como de las respuestas que enva como consecuencia de haber
procesado esas peticiones. Esta informacin podr afectar al
procesamiento de futuros mensajes asociados a una peticin.

Proxy stateless: un proxy de este tipo slo reenva los mensajes que
le llegan. No guarda el estado de las transacciones, as una vez que ha
retransmitido un mensaje borra toda informacin sobre l.

2) Servidor de registro. Es un servidor que acepta peticiones de registro de
los usuarios y guarda la informacin de estas peticiones. Por tanto, suministra
un servicio de localizacin y traduccin de direcciones en el dominio que
controla.

Veamos el ejemplo de la Figura 4 para tener ms claro el funcionamiento de
estos servidores.



Servidor de
Registro
UAC
Servidor
Proxy
UAC
1) Registro
2) Almacenamiento
3) Invitacin
4) Consulta
5) Respuesta
6) Invitacin
Juan
Ana

Figura 4. Tipos de servidores SIP.

El ejemplo empieza con el registro de Ana en el Servidor de Registro que
seguidamente es almacenado. A continuacin, Juan manda una invitacin para
iniciar una sesin con Ana. Cuando llega al Servidor Proxy, ste consulta al
Servidor de Registro para ver dnde est localizada Ana. El Servidor de
Registro contesta con su localizacin y finalmente el Servidor Proxy reenva la
peticin de invitacin a Ana.

Servidor de Redireccin. Genera respuestas de redireccin a las peticiones
que recibe. Cuando recibe una peticin no la reenva a otro servidor sino que
genera una respuesta con la direccin de destino de la peticin. Cuando el
cliente la recibe, rehace la peticin con esta informacin y la enva. Se suele
utilizar cuando se quiere disminuir la carga de procesamiento de rutado de los
servidores proxy.

Es muy importante tener en cuenta que la divisin de estos servidores es
conceptual, cualquiera de ellos puede estar fsicamente en una nica mquina.
Esta divisin se suele hacer por motivos de escalabilidad y rendimiento.
1.1.3 Tipos de mensajes SIP
Como ya hemos comentado SIP es un protocolo basado en texto que usa una
semntica semejante a la del protocolo HTTP. Los UAC realizan las peticiones
y los UAS devuelven respuestas a las peticiones de los clientes.

SIP define la comunicacin a travs de dos tipos de mensajes: las solicitudes o
peticiones (requests) y las respuestas (responses). Ambos emplean un formato
de mensaje genrico
9
, el cual consiste en una lnea inicial seguida de uno o

9
El formato est establecido en la recomendacin RFC 2822.


ms campos de cabecera (headers), una lnea vaca que indica el final de las
cabeceras, y por ltimo, el cuerpo del mensaje que es opcional.

Mensaje_Genrico = lnea_inicial
*campo de cabecera
Lnea_vaca
[cuerpo_del_mensaje]

Lnea_inicial = Lnea_de_peticin / Lnea_de_estado
1.1.3.1 Formato y tipo de las peticiones SIP
Las peticiones SIP comparten todas un mismo formato. Este comienza por una
lnea inicial del mensaje, llamada Request-Line, que contiene el nombre del
mtodo, el identificador del destinatario de la peticin (Request-URI) y la
versin del protocolo SIP.

Lnea_de_Peticin = Mtodo Identificacin_del_destinatario
Versin_SIP

Existen seis mtodos bsicos
10
SIP que describen las peticiones de los
clientes:

INVITE: Permite invitar un usuario o servicio para participar en una
sesin o para modificar parmetros en una sesin ya existente.

ACK: Confirma el establecimiento de una sesin.

OPTION: Solicita informacin sobre las capacidades de un servidor.

BYE: Indica la terminacin de una sesin.

CANCEL: Cancela una peticin pendiente.

REGISTER: Registrar al User Agent.
1.1.3.2 Formato y tipo de las respuestas SIP
Despus de la recepcin e interpretacin del mensaje de solicitud SIP, el
receptor del mismo responde con un mensaje. Este mensaje es similar al
anterior difiriendo slo la lnea inicial, llamada Status-Line. sta contiene la
versin de SIP, el cdigo de la respuesta (Status Code) y una pequea
descripcin de ste (Reason Phrase).

Lnea_de_estado = Versin_SIP Cdigo_de_estado Descripcin

10
Existen otros mtodos adicionales publicados en otras recomendaciones como los mtodos
INFO, SUBSCRIBER, etc.


El cdigo de la respuesta est compuesto por tres dgitos que permiten
clasificar los diferentes tipos existentes. El primer dgito define la clase de la
respuesta.

Los diferentes cdigos de respuesta
11
son los siguientes:

1xx - Respuestas provisionales: peticin recibida, continuando con el
procesamiento de la peticin.

2xx - Respuestas de xito: la peticin fue recibida, entendida y
aceptada.

3xx - Respuestas de redireccin: ms acciones son necesarias para
completar la peticin.

4xx - Respuestas de fallo de mtodo: la peticin es sintcticamente
incorrecta o el servidor no puede llevarla a cabo.

5xx - Respuestas de fallos de servidor: el servidor fall al llevar a cabo
una peticin aparentemente vlida.

6xx - Respuestas de fallos globales: la peticin no puede llevarse a cabo
en ningn servidor.
1.1.4 Formato y campos de las cabeceras SIP
Las cabeceras SIP son similares a las de HTTP tanto semnticamente como
sintcticamente. Los campos por los que est compuesta tienen el siguiente
formato:

Nombre_del_campo: Valor_del_campo *(;nombre_del_parmetro:
valor_del_parmetro)

Las cabeceras se utilizan para transportar informacin necesaria a las
entidades SIP. A continuacin, se detallan algunos campos
12
:

Via: Indica el camino que ha seguido la peticin as como el camino que
debera seguir la respuesta. Contiene el protocolo de transporte usado
para el envo de la peticin, la localizacin a dnde debe ser enviada la
respuesta (nombre o direccin del host) y el puerto dnde ste desea
ser contactado. El parmetro branch sirve como identificador de una
transaccin y es usado por los servidores proxy para detectar bucles. El
parmetro received indica la direccin de donde se ha recibido la
peticin.

11
La totalidad de las respuestas as como su significado se puede consultar en la
recomendacin RFC 3261 seccin 21.
12
Todos los posibles campos de la cabecera y su significado pueden verse en el RFC 3261
seccin 20.


Max-Forward: indica el nmero mximo de proxies o gateways que
puede atravesar una peticin. As, cada vez que un proxy o un gateway
reenve una peticin a otro proxy o gateway, el nmero decrecer en
una unidad hasta llegar a cero, momento en el que ya no se podr
reenviar ms.

Route: los proxies insertan este campo en las peticiones para forzar que
futuras peticiones dentro del mismo dilogo sean rutadas a travs del
proxy que se indica.

Record-Route: esta cabecera es usada para forzar que una peticin sea
encaminada a travs del conjunto de proxies que se indica en ella.

From: indica la direccin del que ha originado la peticin. Incluye el
parmetro tag que es una cadena aleatoria generada por el terminal
con propsitos de identificacin.

To: Indica la direccin del destinatario de la peticin. Al igual que From,
tambin contiene el parmetro tag.

Call-Id: es un identificador nico para cada llamada. Es generada por la
combinacin de una cadena aleatoria y el nombre o direccin del host.
La combinacin de los parmetros tag de From y To y Call-Id
definen completamente una transaccin de extremo a extremo.

Cseq: Consta de un nmero aleatorio que identifica de forma secuencial
cada peticin y el nombre de sta.

Contact: Contiene una o varias direcciones que pueden ser usadas para
contactar con el usuario. A diferencia del campo Via que sirve para
decir dnde enviar la respuesta, Contact dice dnde enviar futuras
peticiones.

Authorization: este campo contiene las credenciales de autentificacin
del agente de usuario.

Proxy-Authorization: este campo permite a un cliente autentificarse a si
mismo frente a un Proxy que requiere autentificacin. Contiene las
credencuales de autentificacin del usuario.

WWW-Authenticate: contiene un desafo para la autentificacin. (Ver la
seccin 1.1.6 Mecanismos de seguridad de este documento para ms
informacin).

Content-Type: indica de qu tipo es el contenido del cuerpo del
mensaje.

Content-Length: indica el tamao del cuerpo del mensaje en bytes.


1.1.5 Direccionamiento en SIP
Una de las funciones de los servidores SIP es la localizacin de los usuarios y
resolucin de nombres. Normalmente, el agente de usuario no conoce la
direccin IP del destinatario de la llamada, sino su URI.

Las entidades SIP identifican a un usuario con las SIP URI
13
(Uniform Resource
Identifiers) las cuales tienen un formato similar al del correo electrnico. Consta
de un usuario y un dominio delimitado por una @, como se muestra en los
siguientes casos:

usuario@dominio: donde dominio es un nombre de dominio completo.

usuario@equipo: donde equipo es el nombre de la mquina.

usuario@direccin_ip: donde direccin_ip es la direccin IP del
dispositivo.

nmero_telfono@gateway: donde el gateway permite acceder al
nmero de telfono a travs de la red telefnica pblica.

Una uri SIP no siempre ha de corresponderse con un slo telfono. Si un
usuario est disponible en ms de un telfono, al recibir una llamada se puede
hacer que todos suenen a la vez o en una secuencia determinada segn
hayamos configurado el servidor. Casi todos los SIP registars soportan que un
mismo usuario se registre en diferentes telfonos.

SIP provee tambin una URI SIPS (SIP Secure), la cual es una URI segura.
Una llamada hecha a una SIPS URI nos garantiza que los mensajes que se
intercambiarn lo harn usando un mtodo de transporte seguro y encriptado
llamado TLS (Transport Layer Security).

Con esta forma de direccionar tenemos la ventaja de que la direccin del
usuario no va unida a ningn dispositivo en concreto como en H.323, pudiendo
ser localizados con el mismo identificador en cualquier telfono donde nos
registremos.

La solucin de identificacin de SIP, tambin puede estar basada en
procedimientos DNS
14
utilizados por los clientes para traducir una SIP URI en
una direccin IP, puerta y protocolo de transporte utilizado, o por los servidores
para retornar una respuesta al cliente en caso de que la peticin falle.

13
Se encuentran definidas en la recomendacin RFC 2396.
14
Estos procedimientos se encuentran descritos en la recomendacin RFC 3263.



1.1.6 Mecanismos de seguridad en SIP
SIP dispone de mecanismos que utilizndolos correctamente permiten
garantizar la seguridad en las comunicaciones de una forma bastante alta.
Estos mecanismos se dividen en dos aspectos principales: autentificacin y
encriptacin.

La autentificacin se utiliza en la comunicacin user-to-proxy o proxy-to-user y
est basado en HTTP Digest intentando minimizar el riesgo de que un atacante
se pueda hacer pasar por otro. Para comprender bien este proceso vamos a
ver con detalle el contenido de los mensajes que se originaran en un proceso
de registro de un usuario en un servidor.

El escenario que planteamos para el ejemplo
15
es el de la Figura 5.

Figura 5. Escenario del ejemplo de registro de un usuario en un servidor.

Los datos de los dos elementos que intervienen son los de la Tabla 1 a
continuacin.

Elemento Nombre URI Direccin IP
Agente de usuario Juan juan@dte.us.es 192.0.2.101
Servidor Proxy - ss1.dte.us.es 192.0.2.111
Tabla 1. Datos de los participantes en el ejemplo de registro de un usuario en un servidor.

Cuando el agente de usuario se registra por primera vez en un servidor se
genera el flujo de mensajes que aparece en la Figura 6.

15
El ejemplo original as como otros ejemplos se pueden ver en la recomendacin RFC 3665
secciones 2 y 3.


Juan Proxy 1
REGISTER
401 UNAUTHORIZED
REGISTER
200 OK

Figura 6. Flujo de mensajes al registrarse por primera vez un usuario en un servidor.

El primer mensaje es una peticin de registro por parte del usuario Juan. El
mensaje generado sera el siguiente:

REGISTER sips:ss1.dte.us.es SIP/2.0
Via: SIP/2.0/TLS client.dte.us.es:5061;branch=z9hG4bKnashds7
Max-Forwards: 70
From: Juan <sips:juan@dte.us.es>;tag=a73kszlfl
To: Juan <sips:juan@dte.us.es>
Call-ID: 1j9FpLxk3uxtm8tn@dte.us.es
CSeq: 1 REGISTER
Contact: <sips:juan@client.dte.us.es>
Content-Length: 0
Figura 7. Primera peticin de registro.

Vemos como se utilza una URI SIPS para que el trasporte sea seguro,
utilizando TLS para su encriptacin, y que tanto el campo From y To
contienen ambos le direccin de Juan. Los dems campos no nos interesan por
ahora y ya sern analizados en el siguiente ejemplo.

El servidor contesta enviando una respuesta 401 Unauthorized que no es ms
que un desafo que lanza el servidor para que Juan se identifique. El mensaje
sera tal que as:

SIP/2.0 401 Unauthorized
Via: SIP/2.0/TLS client.dte.us.es:5061;branch=z9hG4bKnashds7
;received=192.0.2.101
From: Juan <sips:juan@dte.us.es>;tag=a73kszlfl
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="dte.us.es", qop="auth",
nonce="ea9c8e88df84f1cec4341ae6cbe5a359",
opaque="", stale=FALSE, algorithm=MD5
Content-Length: 0
Figura 8. Desafo del servidor.


En l vemos la aparicin del campo WWW-Aunthenticate que contiene varios
parmetros. Entre ellos destacamos: Digest Realm que contiene el dominio
del servidor contra el cual hay que identificarse, nonce que es un valor
aleatorio generado por el servidor y que tendr que ser devuelto por el usuario
y algorithm que indica el algoritmo de encriptacin que se ha de utiizar.

A continuacin, Juan enva una nueva peticin de registro tal como esta:

REGISTER sips:ss1.dte.us.es SIP/2.0
Via: SIP/2.0/TLS client.dte.us.es:5061;branch= z9hG4bKnashd92
Max-Forwards: 70
From: Juan <sips:juan@dte.us.es>;tag= ja743ks76zlflH
CSeq: 2 REGISTER
Contact: <sips:juan@client.dte.us.es>
Authorization: Digest username="juan", realm="dte.us.es"
nonce="ea9c8e88df84f1cec4341ae6cbe5a359", opaque="",
uri="sips:ss1.dte.us.es",
response="dfe56131d1958046689d83306477ecc"
Content-Length: 0
Figura 9. Segunda peticin de registro.

Podemos apreciar como hay un nuevo campo Authorization con respecto a la
primera peticin de registro que contiene las credenciales del cliente. Entre sus
parmetros destacamos el nombre de usuario (Digest username), el dominio
contra el cual se autentifica (realm), el mismo nmero aleatorio (nonce) del
mensaje anterior, la direccin (uri) y un atributo response. Este contiene de
forma encriptada todo lo anterior ms la contrasea de Juan.

De esta forma se consigue enviar la autentificacin al servidor sin hacer visible
el password. El servidor tiene entonces que comparar el valor de response
con el resultado de encriptar el los datos por su cuenta con la contrasea que
tiene registrada para Juan.

Si el resultado ha sido satisfactorio el servidor enva una respuesta de
confirmacin tal que as:



SIP/2.0 200 OK
Via: SIP/2.0/TLS client.dte.us.es:5061;branch= z9hG4bKnashd92
;received=192.0.2.101
From: Juan <sips:juan@dte.us.es>;tag= ja743ks76zlflH
CSeq: 2 REGISTER
Contact: <sips:juan@client.dte.us.es>;expires=3600
Content-Length: 0
Figura 10. Respuesta de confirmacin.

En lo que respecta a la encriptacin el objetivo es garantizar la confidencialidad
de la comunicacin, para lo cual se utilizan algoritmos como AES (Advanced
Encryption Standard) o DES (Data Encryption Standard). Por otro lado, la
encriptacin de la informacin puede hacerse de dos formas, hop-by-hop o
end-to-end. En la primera, hop-by-hop, se encriptan los datos entre los
participantes en la comunicacin utilizando tecnologas externas a SIP como
TLS o IPSec (IP Secure).

Con la encriptacin end-to-end se encripta mediante S/MIME toda la
informacin que no es necesario que sea vista por los sistemas intermedios.

Es importante tener en cuenta que incluso una buena implementacin de estos
mecanismos no puede garantizarnos al 100% la seguridad de las
comunicaciones.
1.1.7 Intercambio de mensajes en el establecimento de una sesin
SIP
A continuacin se va a detallar el establecimiento de sesin entre dos usuarios,
proponiendo como escenario de ejemplo el que representa la siguiente figura
16
:

Figura 11. Escenario del ejemplo de establecimiento de una sesin SIP.

Juan intentar establecer una sesin con Ana. Para ello Juan contactar con el
Proxy 1 que es el que tiene determinado para sus llamadas salientes y ste

16
El ejemplo original completo est descrito en la recomendacin RFC 3665 seccin 3.2.


pasar la peticin al Proxy 2 quin finalmente la entregar a Ana. La llamada
quedar establecida entre los dos usuarios hasta que Ana termine la sesin.

En la tabla a continuacin podemos ver los datos de los elementos que
interviene en el ejemplo.

Elemento Nombre URI Direccin IP
Agente de usuario Juan juan@dte.us.es 192.0.2.101
Agente de usuario Ana ana@atc.us.es 192.0.2.201
Servidor Proxy 1 - ss1.dte.us.es 192.0.2.111
Servidor Proxy 2 - ss2.atc.us.es 192.0.2.222
Tabla 2. Datos de los participantes en el ejemplo de establecimiento de una sesin SIP.

A continuacin en la Figura 12 se detallan todos los mensajes que se
producirn es esta sesin suponiendo que tanto Juan como Ana estn ya
registrados en sus respectivos proxies.



Figura 12. Intercambio de mensajes en una sesin SIP.

De este intercambio podemos deducir que la sealizacin pasar por los
servidores pero que la comunicacin RTP es de extremo a extremo. Podemos
ver la situacin en la Figura 13. Esto es conocido como el trapecio SIP.

Figura 13. Trapecio SIP.

El intercambio de mensajes comienza con una peticin de inicio de sesin por
parte del usuario Juan. A sta el servidor le responde con un 407
Authentication Required ya que no ha incluido en su cabecera ningn campo
de autentificacin. Esto como ya hemos visto en el proceso de registro, es un


desafo que el servidor enva al usuario para que se autentifique. El usuario
avisa de su recepcin con un ACK y a continuacin reenva la peticin invite
pero esta vez con sus credenciales en el campo Proxy Authorization.

Cuando el Proxy 1 recibe la peticin enva una respuesta Triying con la que
se ndica que la peticin ha sido recibida pero que es necesario hacer otras
acciones. Como con cualquier respuesta provisional, hace que el cliente deje
de retransmitir peticiones. Al mismo tiempo, Proxy 1 reenva al Proxy 2 la
peticin invite el cual hace lo mismo que antes el Proxy 1: enva un Triying
y reenva la peticin a Ana.

Antes de seguir, vamos a examinar con detalle el reenvo de las peticiones
invite para entender la funcin de algunos campos de la cabecera.

El primer invite de Juan a Proxy 1 sera tal que as:

INVITE sip:ana@dte.us.es SIP/2.0
Via: SIP/2.0/TCP client.dte.us.es:5060;branch=z9hG4bK74bf9
Max-Forwards: 70
Route: <sip:ss1.dte.us.es;lr>
From: Juan <sip:juan@dte.us.es>;tag=9fxced76sl
To: Ana <sip:ana@atc.us.es>
Call-ID: 3848276298220188511@dte.us.es
CSeq: 2 INVITE
Contact: <sip:juan@client.dte.us.es;transport=tcp>
Proxy-Authorization: Digest username="alice",
realm="atlanta.example.com",
nonce="wf84f1ceczx41ae6cbe5aea9c8e88d359", opaque="",
uri="sip:bob@biloxi.example.com",
response="42ce3cef44b22f50c6a6071bc8"
Content-Type: application/sdp
Content-Length: 151
Figura 14. Invite de Juan a Proxy 1.

En l podemos apreciar como en la primera lnea (Lnea de peticin) se
encuentra la peticin de la que se trata (INVITE), el destinatario (Ana) y la
versin de SIP.

A continuacin, aparecen diversos campos de cabecera. En el primero, Via
observamos el protocolo de transporte usado (TCP), la localizacin a donde
debe ser enviada la respuesta y el nmero de puerto (client.dte.us.es:5060).
Por ltimo, aparece el atributo identificador branch.

Atendiendo al valor de Max-Forwards este mensaje slo podr ser reenviado
70 veces. En Route tenemos la direccin del Proxy 1. En From y To
aparecen las direcciones de origen (Juan) y destino (Ana) respectivamente.



En Call-ID est el identificador de la llamada que ser el mismo para todos los
mensajes del ejemplo de la figura n (la completa). En CSeq aparecen el
identificador y el nombre de la peticin.

En Contatc est la direccin de Juan, y en Proxy-Authorization las
credenciales del cliente con los atributos ya comentados en el ejemplo de la
seccin: 1.1.6 Mecanismos de seguridad en SIP.

Por ltimo, si nos fijamos en el campo Content-Type, el cuerpo del mensaje
es un mensaje SDP de una longitud de 151 bytes como deducimos de
Content-Length.

A continuacin el Proxy 1 reenva la peticin al Proxy 2:

Via: SIP/2.0/TCP ss1.dte.us.es:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.101
Max-Forwards: 69
Record-Route: <sip:ss1.dte.us.es;lr>
Call-ID: 3848276298220188511@dte.us.es
CSeq: 2 INVITE
Content-Length: 151
Figura 15. Reenvio de peticin de Proxy 1 a Proxy 2.

En su viaje haca Ana, el mensaje ha pasado por el Proxy 1 quin ha
introducido su direccin y puerto en un segundo campo Via donde queda
reflejado el camino que lleva el paquete. Si nos fijamos, tambin ha introducido
el atributo received con la direccin IP de Juan (192.0.2.101) que es de donde
recibi el mensaje.

Ha aparecido un campo nuevo: Record-Route para indicar que la respuesta
debe ser rutada por l.

Por ltimo podemos apreciar como el campo Max-Forwards ha decrecido en
una unidad al haberse reenviado una vez el mensaje.



Seguidamente, el Proxy 2 reenva el mensaje a Ana:

Via: SIP/2.0/TCP ss2.atc.us.es:5060;branch=z9hG4bK721e4.1
Via: SIP/2.0/TCP ss1.dte.us.es:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
;received=192.0.2.101
Max-Forwards: 68
Record-Route: <sip:ss2.atc.us.es;lr>, <sip:ss1.dte.us.es;lr>
Call-ID: 3848276298220188511@dte.us.es
CSeq: 2 INVITE
Content-Length: 151
Figura 16. Reenvio de peticin de Proxy 2 a Ana.

El Proxy 2 repite lo que hizo antes el Proxy 1: incluye su direccin en el camino
que lleva el paquete insertando un tercer campo Via y anota la direccin de
donde le lleg (received=192.0.2.111). Adems introduce tambin su direccin
en el campo Record-Route con la intencin antes descrita.

Retomemos ahora la descripcin del establecimiento de sesin cuando Ana
recibe el invite. En ese momento el terminal de Ana empieza a sonar. Un
mensaje Ringing es enviado a Juan que al recibirlo escucha el tono de
llamada.

Cuando Ana descuelga, un mensaje de OK es enviado a Juan, quien
responde con un ACK. En ese momento la llamada est establecida y empieza
a actuar el protocolo de transporte RTP con los parmetros (puertos,
direcciones, cdecs, etc.) establecidos en la negociacin mediante el protocolo
SDP.

Por ltimo, cuando Ana cuelga se enva una peticin bye de terminacin de
sesin a Juan. ste al recibirla enva una respuesta de OK para indicar que
se recibi el mensaje final correctamente.
1.1.8 Problemas de SIP al atravesar dispositivos NAT
Uno de los mayores problemas a los que tiene que hacer frente SIP, es cuando
una comunicacin pasa a travs de un dispositivo NAT (Network Address
Translation).

Como ya hemos comentado SIP est pensado para trasportar la sealizacin
de una llamada pero confa el trasporte de audio a RTP. As, mientras la
sealizacin usa unos puertos fijos y estandarizados (el 5060 normalmente),


RTP usa puertos que son elegidos aleatoriamente (entre el 10.000 y el 20.000
usualmente) lo que lleva a muchos firewalls/NAT a no ser capaces de asociar
el enlace establecido en la sealizacin con el flujo de audio dentro de una
llamada.

Veamos un poco ms profundidad los problemas de los que adolece SIP
cuanto atraviesa un dispositivo NAT. Para ello primero nos centraremos en los
problemas asociados a la sealizacin SIP y a continuacin comentaremos los
que se producen en el establecimiento del flujo de audio.
1.1.8.1 Problemas con la sealizacin SIP
Cuando SIP utiliza UDP para enviar una respuesta a una peticin, el puerto al
que enva la respuesta es el indicado en el campo de cabecera VIA de la
peticin. Pero si el cliente que ha enviado la peticin est en una red privada
detrs de un dispositivo NAT, se presenta el problema que podemos ver en la
siguiente figura:

Figura 17. Respuesta bloqueada por el dispositivo NAT.

El proxy ha enviado la respuesta al puerto 5060 del cliente ya que ste es el
que aparece en el campo VIA de la cabecera de la peticin. Sin embargo este
puerto fue cambiado por NAT al puerto 10991 que es el que est abierto para
la conexin. El 5060 puede estar cerrado en el NAT por lo que el paquete sera
descartado.

Para solucionar este problema se necesita un mtodo que reescriba la
direccin del puerto destino de la respuesta. Escribiendo la direccin del puerto
abierto en la peticin como puerto destino en la respuesta, conseguimos que
todo pase por el mismo puerto
17
como nos muestra la figura a continuacin:

17
Este mtodo se conoce como Respuesta Simtrica y est descrito en el RFC 3581.


Figura 18. Peticin y respuesta pasan por el mismo puerto.

Otro problema de sealizacin aparece cuando utilizamos TCP. Con este
protocolo, SIP s que utiliza el puerto abierto en el NAT por la peticin para
enviar la respuesta pero el problema viene cuando es el proxy el que enva una
peticin. La situacin es la que representa la Figura 19.

Figura 19. Peticin del Proxy bloqueada por el dispositivo NAT.

El proxy utiliza para enviarla la direccin IP de contacto que es una direccin
privada y por lo tanto no vlida.

Esto se podra haber evitado como antes utilizando la conexin ya abierta en el
NAT en el registro. Pero esto nos lleva a enfrentarnos con otro problema. Y es
que normalmente los dispositivos NAT cierran las conexiones al cabo de un
tiempo (de segundos a horas) y como en SIP pueden pasar grandes periodos
sin actividad, la conexin que creamos estar abierta puede que ya est
cerrada.

La solucin a este problema la encontramos en el borrador draft-ietf-sip-
outbound-15 el cual propone tcnicas que usan un identificador para cada
conexin. Esta informacin se almacena junto con informacin de la traduccin
que ha hecho NAT y cuando llega una peticin la utiliza para enviarla por la
conexin abierta. Al mismp propone mecanismos para mantener abiertas las
conexiones que pasan por el NAT abiertas.


1.1.8.2 Problemas con el flujo RTP
La negociacin para establecer una conexin RTP se lleva a cabo usando el
protocolo SDP. En ste cada cliente especifica la direccin IP y el puerto donde
quiere recibir el flujo RTP. El problema viene cuando los clientes se encuentran
dentrs de un dispositivo NAT. En la Figura 20 se presenta el caso.

Figura 20. Conexin RTP fallida entre los clientes A y B.

Al estrar en redes privadas, los clientes especifican las direcciones privadas
como destinatarias del flujo RTP siendo estas direcciones no vlidas y no se
podr establecer dicha conexin.

Incluso podra darse el caso de que un cliente al haber recibido una direccin
privada a la que mandar al flujo RTP, y habiendo un host en su red con la
misma direccin, empezase a mandar paquetes RTP a dicho host (recordemos
que RTP va sobre UDP).

Llegar a una solucin general en esta situacin no es fcil, y se complica an
ms debido al gran nmero de topologas de NAT que existen
18
.

En cuanto al protocolo RTCP tambin nos encontramos con un problema ya
que la prctica normal para asignar un puerto para este protocolo es asignarle
el siguiente al definido para RTP. Esto puede hacer que al atravesar algunos
NATs este trfico se bloquee. Para poder controlar esto se debera poder
especificar en el protocolo SDP la direccin y el puerto que queremos usar
especficamente para RTCP
19
.

Por ltimo, existen tres protocolos interrelacionados que contienen una solucin
completa para los flujos de audio y NAT. Estos son: STUN (Simple Transversal
of UDP over NATs), TURN (Traversal Using Relay NAT) e ICE (Interactive
Connectivity Establishment). Pasemos a describer brevemente cada uno de
ellos:

18
Una de las soluciones propuestas se encuentra en el documento RFC 4961.
19
La recomendacin RFC 3605 define un atributo en SDP para definir esto.


STUN
20
. Es un protocolo que permite saber que direccin y puerto est
utilizando un host fuera de NAT. As, esta informacin puede ser utilizada por
SDP para construir el flujo RTP. Sin embargo este protocolo no funciona con
algunas topologas de NAT como el NAT bidireccional (Symmetric NAT). STUN
tambin es usado para mantener una conexin abierta en el NAT.

TURN
21
. Es utilizado en algunos escenarios donde STUN no funciona. Solo es
recomendable si no hay otra solucin posible ya que consume muchos
recursos en una conexin y puede introducir retrasos indeseables en el trfico
de paquetes.

ICE
22
. Es el mtodo apropiado si la tcnica Symmetric RTP no se puede
emplear. Utiliza STUN y TURN y otras tecnologas para proveer una solucin
unificada al problema con NAT.
1.2 Protocolo H.323
1.2.1 Introduccin
El protocolo H.323 fue diseado por la Unin Internacional de
Telecomunicaciones (ITU, Internacional Communication Union) y fue publicado
por primera vez en 1996. La sexta es la versin actual publicada en el ao
2006. Se cre originalmente para proveer un mecanismo de transporte IP para
la videoconferencia en redes de rea local (LAN), pero evolucion rpidamente
para convertirse en un mtodo de transporte de aplicaciones multimedia en
redes de conmutacin de paquetes tanto LAN como WAN.

El estndar fue diseado especficamente con los siguientes objetivos:

Basarse en los estndares existentes, incluyendo H.320, RTP y Q.931.
Incorporar algunas de las ventajas que las redes de conmutacin de
paquetes ofrecen para transportar datos.
Solucionar la problemtica que plantea el envo de datos en tiempo real
sobre redes de conmutacin de paquetes.

Los diseadores de H.323 saban que los requisitos de la comunicacin difieren
de un lugar a otro, entre usuarios y entre compaas y obviamente con el
tiempo los requisitos de la comunicacin tambin cambian. Dados estos
factores, los diseadores de H.323 lo definieron de tal manera que las
empresas constructoras de los equipos pueden agregar sus propias
especificaciones al protocolo y pueden definir otras estructuras de estndares
que permitan a los dispositivos adquirir nuevas caractersticas o capacidades.

20
El procolo STUN se encuentra definido en la RFC 5389.
21
El protocolo TURN puede consultarse en el borrador IETF: draft-ietf-behave-turn-14.
22
El protocolo ICE puede ser consutado en el borrador IETF: draft-ietf-mmusic-ice-19.


1.2.2 Protocolos asociados a H.323
H.323 incluye entre otros, partes de los siguientes protocolos: H.225.0, H.245 y
RTP/RTCP.
1.2.2.1 Protocolo H.225.0
Define los mensajes de sealizacin de llamada (establecimiento, control y
finalizacin) y de sealizacin RAS (Registration, Admission and Status). RAS
lleva a cabo los procedimientos de registro, admisin, cambios de ancho de
banda, estado y desconexin, entre terminales y un Gatekeeper H.323. La
sealizacin H.225.0 est basada en los procedimientos de establecimiento de
llamada de ISDN (Integrated Services Didigal Networks, estndar Q.931).
1.1.2.2 Protocolo H.245
Transmite y proporciona la informacin necesaria para una comunicacin
multimedia, tal como opciones de codificacin, control de flujo, gestin de jitter,
etc. Digamos, que este protocolo asegura que hay una aplicacin y un cdec
compatible entre los terminales implicados en una comunicacin.
1.1.2.3 Protocolos RTP y RTCP
Al igual que SIP, H.323 tambin utiliza RTP como protocolo de transporte. Sus
caractersticas principales ya han sido descritas en la seccin: 1.1.1 Protocolos
asociados a SIP de este documento.

En la figura a continuacin, podemos ver la pila de protocolos de H.323
utilizando el protocolo IP.



Figura 21. Pila de protocolos de H.323.
1.2.3 Elementos de una red H.323
En una red H.323 podemos identificar los siguientes elementos: Gatekeeper,
Terminal, Gateway y MCU. Pasemos a ver en que consiste cada uno.
1.2.3.1 Gatekeeper
Es el dispositivo de la red que provee a los equipos terminales servicios tales
como registro y autentificacin de usuarios, control de ancho de banda,
resolucin de direcciones, etc. Este ltimo quizs sea el ms importante ya que
hace posible que dos terminales se pueden comunicar sin saber ninguno la
direccin IP del otro.

Para ello cada dispositivo dentro de una zona (mbito donde opera un
gatekeeper, el cual puede ser una LAN o un continente entero) debe llevar a
cabo un proceso de registro. Como podemos apreciar en la Figura 22, ste
consiste en el envo de una peticin de registro por parte del terminal donde se
informa de las caractersticas que lo identifican (nmero de telfono, direccin
IP, etc.).

El gatekeeper, despus de haber registrado todos estos datos en memoria,
enva al terminal un mensaje de confirmacin de registro indicndole que tiene
va libre para recibir y efectuar llamadas.



Figura 22. Proceso de registro en H.323.

Un gatekeeper puede ser diseado para operar en dos modos:

Direct routed. Los equipos terminales aprenden comunicndose con el
gatekeeper mediante el protocolo RAS la direccin ip de los otros
terminales y se establece una conexin directa (sin pasar por el
gatekeeper). Este es el modo ms ampliamente utilizado.

Figura 23. Gatekeeper H.323 en modo Direct routed.

Gatekeeper routed. Los mensajes de sealizacin pasan por el
gatekeeper. Esto requiere un gatekeeper de mayor potencia de
procesamiento pero permite tener un control directo sobre la
comunicacin.

Figura 24. Gatekeeper H.323 en modo Gatekeeper routed.


1.2.3.2 Terminal
Un terminal H.323 es un extremo de la red que proporciona comunicaciones
bidireccionales en tiempo real con otro terminal H.323, gateway o unidad de
control multipunto (MCU, Multipoint Control Unit). Esta comunicacin consta de
seales de control, indicaciones, audio, imagen en color en movimiento y/o
datos entre los dos terminales. Conforme a la especificacin, un terminal H.323
puede proporcionar slo voz, voz y datos, voz y vdeo, o voz, datos y vdeo.
1.2.3.3 Gateway o pasarela
Es el dispositivo que hace de interfaz entre una red H323 y otras redes como la
red telefnica bsica (RTB) e ISDN (Integrated Services Digital Network). En el
caso en el que en una conversacin un equipo terminal no sea H.323, la
llamada deber pasar por un gateway para que la comunicacin sea posible.
1.2.3.4 MCU (Multipoint Control Unit)
La unidad de control multipunto (MCU) es un punto extremo de la red que
permite que tres o ms terminales y pasarelas participen en una conferencia
multipunto. Tambin puede conectar dos terminales en una conferencia punto a
punto que puede llegar a convertirse en multipunto.

La MCU consta de dos partes: el MP (Multipoint Processor) que acta como un
DSP (Digital Signal Processor) para manejar varios canales de audio y vdeo, y
el MC (Multipoint Controller) que se encarga de la sealizacin.
1.2.4 Direccionamiento en H.323
H.323 soporta varios tipos de direcciones tales como direcciones alias, URLs,
y nmeros de telfono tradicional (estos siguen la recomendacin de la ITU
E.164).
1.2.5 La sealizacin en H.323
La funcin de sealizacin est basada en la recomendacin H.225, que
especifica el uso y soporte de mensajes de sealizacin Q.931/Q932. Las
llamadas son enviadas sobre TCP por el puerto 1720. Sobre este puerto se
inician los mensajes de control de llamada Q.931 entre dos terminales para la
conexin, mantenimiento y desconexin de llamadas.

Los mensajes ms comunes de Q.931/Q.932 usados como mensajes de
sealizacin H.323 son:

Setup: es enviado para iniciar una llamada H.323 y establecer una
conexin con una entidad H.323. Entre la informacin que contiene el
mensaje se encuentra la direccin IP, puerto y alias del llamante o la
direccin IP y puerto del llamado.


Call Proceeding: es enviado por el Gatekeeper a un terminal
advirtiendo del intento de establecer una llamada una vez analizado el
nmero llamado.

Alerting: indica el inicio de la fase de generacin de tono.

Connect: indica el comienzo de la conexin.

Release Complete: enviado por el terminal para iniciar la desconexin.

Facility: es un mensaje de la norma Q.932 usado como peticin o
reconocimiento de un servicio suplementario.

EL canal de control H.245 es un conjunto de mensajes ASN.1 (Abstract Syntax
Notation One) usados para el establecimiento y control de una llamada. Los
mensajes ms relevantes son:

MasterSlaveDetermination (MSD): este mensaje es usado para
prevenir conflictos entre dos terminales que quieren iniciar la
comunicacin. Decide quin actuar de Master y quin de Slave.

TerminalCapabilitySet (TCS): mensaje de intercambio de capacidades
soportadas por los terminales que intervienen en una llamada.

OpenLogicalChannel (OLC): mensaje para abrir el canal lgico de
informacin contiene informacin para permitir la recepcin y
codificacin de los datos. Contiene la informacin del tipo de datos que
sern transportados.

CloseLogicalChannel (CLC): mensaje para cerrar el canal lgico de
informacin.
1.2.6 Fases de una llamada H.323
Una llamada en H.323 consta de las siguientes fases:

Establecimiento de la comunicacin.
Comunicacin inicial e intercambio de capacidades.
Establecimiento de la comunicacin.
Servicios de llamada.
Terminacin de la llamada.

Tomando como ejemplo el escenario que nos muestra la Figura 25, vamos a
ver los mensajes que se intercambian dos terminales H.323 cuando el
Terminal 1 llama al Terminal 2.



Figura 25. Escenario de ejemplo de una llamada entre dos terminales.
1.2.6.1 Fase 1: Establecimiento de la conexin
Suponiendo que ambos terminales estn registrados en el gatekeeper y que
ste opera en modo directo, la secuencia de mensajes que se produce la
vemos en la siguiente figura.

Gatekeeper en modo Direct routed.

Lo primero que podemos ver es un intercambio de mensajes RAS. Este
consiste en una peticin de acceso a la red mediante el envo de un mensaje
ARQ (Admission Request) y la autorizacin por parte del gatekeeper mediante
el envo de un ACF (Admission Confirm). Si el gatekeeper denegase el acceso,
utilizara un mensaje ARJ (Admission Reject).

El gatekeeper utiliza adems el mensaje ACF para devolver la direccin del
canal de sealizacin del terminal 2.

Haciendo uso de esta informacin, el terminal 1 enva un mensaje de
establecimiento de comunicacin Setup directamente al terminal 2 sin pasar
por el gatekeeper.

A continuacin, el terminal 2 manda un mensaje de llamada en curso (Call
Proceding) con el que indica que se ha iniciado el establecimiento de la
conexin.

Seguidamente, si el terminal 2 desea aceptar la llamada, inicia un intercambio
ARQ/ACF con el gatekeeper como el anteriormente descrito para el terminal 1.



Una vez hecho esto, se enva un mensaje de aviso (Alert) que indica que se ha
iniciado el aviso al usuario, es decir, que la generacin de tono ha comenzado.

Por ltimo, se transmite el mensaje de conexin (Connect) el cual contiene una
direccin de transporte de canal de control H.245 para su utilizacin en la
posterior sealizacin.

Si el gatekeeper hubiera actuado en modo Gatekeeper routed, el intercambio
se mensajes sera el de la Figura 27 que vemos a continuacin.

Terminal 1
RAS ARQ
H.225 Setup
H.225 Call Proceding
RAS ACF
RAS ACF
RAS ARQ
H.225 Alert
H.225 Connect
Gatekeeper Terminal 2
H.225 Setup
H.225 Call Proceding
H.225 Alert
H.225 Connect

Gatekeeper en modo Gatekeeper routed.

Podemos observar como ahora, la sealizacin pasa toda ella por el
gatekeeper. As, en la respuesta ACF del gatekeeper, no se da la direccin del
terminal 2 sino la propia del gatekeeper. Al final, en el mensaje de conexin
connect, el gatekeeper puede optar por incluir la direccin del terminal 2 o la
suya para el canal de control H.245, dependiendo de si el controlador de
acceso decida encaminar o no el canal de control H.245.
1.2.6.2 Fase 2: Comunicacin inicial e intercambio de capacidades
En esta fase se abre una negociacin mediante el protocolo H.245 (control de
conferencia). El intercambio de los mensajes (peticin y respuesta) entre los
dos terminales establece quin ser el dispositivo principal (master) y quin el
subordinado (slave) as como las capacidades de los participantes. En la
Figura 28 vemos la secuencia de mensajes que se generara.



Figura 28. Secuencia de mensajes en la fase Comunicacin inicial e intercambio de
capacidades.
1.2.6.3 Fase 3: Establecieminto de la comunicacin
En esta fase los terminales intercambian mensajes OLC (Open Logical
Channel) para abrir el canal de comunicacin. Estos mensajes contienen entre
otras cosas, informacin relativa a los cdecs de audio y vdeo que se van a
utilizar as como los puertos RTP y RTPC que se van a destinar para la
comunicacin. Al final de esta fase una comunicacin est abierta entre los dos
terminales y pueden empezar a enviar audio o vdeo.

Figura 29. Secuencia de mensajes en la fase Establecimiento de la comunicacin.
1.2.6.4 Fase 4: Servicios de llamada
Dentro de esta fase los terminales pueden intercambiarse mensajes para cosas
como cambio de ancho de banda, en el que nuevos mensajes OCL sera
necesarios, o para ampliar la conferencia a una multipunto entre otras.
1.2.6.5 Fase 5: Terminacin de la llamada
En esta fase cualquiera de los participantes activos en la comunicacin puede
iniciar el proceso de finalizacin de llamada mediante los mensajes CLC (Close
Logical Channel) y ESC (End Session Comand) de H.245.



Posteriormente, utilizando H.225 se cierra la conexin con el mensaje Release
Complete.

Por ltimo se envan los mensajes RAS DRQ (Disengage Request) y DCF
(Disengage Confirm) con los que los terminales se desligan del gatekeeper.

H.245 CLC
H.245 ESC
H.245 CLC ACK
H.245 ESC ACK
H.225 Release Complete
RAS DRQ
RAS DRQ
RAS DCF
RAS DCF
Terminal 1 Gatekeeper Terminal 2

Figura 30. Secuencia de mensajes en la fase Terminacin de la llamada.
1.3 Protocolo IAX
1.3.1 Introduccin
El protocolo IAX se corresponde con Inter-Asterisk eXchange protocol. Como
indica su nombre fue diseado como un protocolo de conexiones VoIP entre
servidores Asterisk aunque hoy en da tambin sirve para conexiones entre
clientes y servidores que soporten el protocolo.

La versin actual es IAX2 ya que la primera versin de IAX ha quedado
obsoleta Es un protocolo diseado y pensado para su uso en conexiones de
VoIP aunque puede soportar otro tipo de conexiones (por ejemplo video).

De ah, que sea un protocolo mucho ms ligero, simple y compacto que H.323
y SIP. Ha sido creado por Mark Spencer, fundador de Digium, y aunque
propietario es de cdigo abierto. Utiliza un mtodo propio para transportar el
trfico VoIP y no el ya mencionado RTP. En ste los mensajes se codifican de
forma binaria mientras que con RTP se utilizan mensajes de texto. IAX2
presenta algunas caractersticas que lo hacen muy interesante para trasportar
trfico VoIP.

As mientras en H.323 y SIP la sealizacin se hace fuera de banda, en IAX2
se hace dentro, requirindose solamente un puerto UDP para sealizacin y
datos (normalmente se utiliza el 4569). Recordemos que para establecer una
llamada mediante SIP necesitamos un puerto para sealizacin (el 5060) y dos


puertos RTP por cada conexin de audio. Por tanto, si tenemos 100 llamadas
simultneas con SIP se utilizarn 200 puertos RTP y el puerto 5060 de
sealizacin mientras que con IAX2 todo se hara con un mismo puerto.

Adems, se utiliza trunking con lo que en una misma conexin se trasportan
todas las conversaciones. Esto disminuye la sobrecarga asociada a las
cabeceras de los paquetes IP y por tanto minimiza el ancho de banda
consumido. Y no menos importante, lo hace ms robusto frente a los firewalls
al tener que pasar solamente por un puerto y evita los problemas de NAT
(Network Address Translation).

Como inconvenientes, el ms importante es que IAX2 no es un estndar con lo
que no est implementado en muchos dispositivos que estn en el mercado.

Otro es que si utilizamos un servidor SIP, la sealizacin de control pasa
siempre por el servidor pero la informacin de audio (flujo RTP) puede viajar
extremo a extremo sin tener que pasar necesariamente ste. En IAX al viajar la
sealizacin y los datos de forma conjunta todo el trfico de audio debe pasar
obligatoriamente por el servidor IAX. Esto produce un aumento en el uso del
ancho de banda que deben soportar los servidores IAX sobretodo cuando hay
muchas llamadas simultneas.
1.3.2 Fases de una llamada utilizando el protocolo IAX
En el protocolo IAX, una llamada se puede dividir en las siguientes fases:
Establecimiento, Audio y Desconexin. La figura a continuacin, nos muestra
los distintos mensajes que se generan en cada uno de las fases.



Terminal 1
Terminal 2
NEW
ACCEPT
ACK
ACK
ACK
RINGING
ANSWER
Tramas
M y F
HANGUP
ACK
ESTABLECIMIENTO
AUDIO
DESCONEXIN

Figura 31. Intercambio de mensajes en una llamada IAX2.
1.3.2.1 Fase 1: Establecimiento de la llamada
El terminal 1 inicia una conexin y manda un mensaje "new". El terminal
llamado responde con un "accept" y el llamante le responde con un "Ack". A
continuacin el terminal llamado da las seales de "ringing" y el llamante
contesta con un "ack" para confirmar la recepcin del mensaje. Por ltimo, el
llamado acepta la llamada con un "answer" y el llamante confirma ese mensaje.
1.3.2.2 Fase 2: Flujo de datos o flujo de audio
Se mandan los frames M y F en ambos sentidos con la informacin vocal. Las
tramas M son mini-tramas que contienen solo una cabecera de 4 bytes para
reducir el uso en el ancho de banda. Las tramas F son tramas completas que
incluyen informacin de sincronizacin. Es importante volver a resaltar que en
IAX este flujo utiliza el mismo protocolo UDP que usan los mensajes de
sealizacin evitando problemas de NAT.
1.3.2.3 Fase 3: Liberacin de la llamada o desconexin
La liberacin de la conexin es tan sencilla como enviar un mensaje de
"hangup" y confirmar dicho mensaje.

Entorno tecnolgico de la VoIP 2. Cdecs

2. Codificadores-Decodificadores: Cdecs
2.1 Introduccin
La comunicacin de voz es analgica, mientras que la informacin que circula
por una red de datos es digital. Por tanto es necesaria una transformacin
analgica-digital de la voz para que esta pueda ser transportada a travs de
una red de datos.

El proceso de convertir ondas analgicas a informacin digital se hace con un
codificador-decodificador, llamado cdec. Hay muchas maneras de transformar
una seal de voz analgica en digital, todas ellas gobernadas por varios
estndares.

Adems de la ejecucin de la conversin de analgico a digital, el cdec
comprime la secuencia de datos. La compresin de la forma de onda
representada puede permitir un ahorro en el ancho de banda. Esto es
especialmente interesante en los enlaces de poca capacidad y permite tener un
mayor nmero de conexiones de VoIP simultneamente. Otra manera de
ahorrar ancho de banda es el uso de la supresin del silencio, que es el
proceso de no enviar los paquetes voz entre silencios en conversaciones
humanas.
2.2 Proceso de conversin analgico-digital
El proceso de conversin de una seal se puede dividir en las siguientes tres
fases:

Muestreo
Cuantificacin
Codificacin

A continuacin pasamos a describirlas.
2.1.1 Fase 1: Muestreo
El proceso de muestreo consiste en tomar valores instantneos de una seal
analgica a intervalos de tiempo iguales. A los valores obtenidos se les llama
muestras.


Este proceso se ilustra en la siguiente figura:

Figura 32. Proceso de muestreo.

El muestreo se efecta siempre a un ritmo uniforme, que viene dado por la
frecuencia de muestreo (sampling rate).

La condicin que debe cumplir la frecuencia de muestreo viene dada por el
teorema de Nyquist: si una seal contiene nicamente frecuencias inferiores a
f, queda completamente determinada por muestras si estas son tomadas a una
velocidad igual o superior a 2f.

De acuerdo con el teorema del muestreo, las seales telefnicas de frecuencia
vocal (que ocupan la banda de 300 a - 3.400 Hz), se han de muestrear a una
frecuencia igual o superior a 6.800 Hz (2 x 3.400).

En la prctica, sin embargo, se suele tomar una frecuencia de muestreo o
sampling rate de fm = 8.000 Hz. Es decir, se toman 8.000 muestras por
segundo, o lo que es lo mismo, se toma una muestra cada 125 s.
2.1.2 Fase 2: Cuantificacin
La cuantificacin es el proceso mediante el cual se asignan valores discretos a
las amplitudes de las muestras obtenidas en el proceso de muestreo. Este
valor es elegido por aproximacin dentro de un margen de niveles previamente
fijado.

El proceso de cuantificacin introduce necesariamente un error ya que se
sustituye la amplitud real de la muestra por un valor aproximado. A este error
se le llama error de cuantificacin.

Las distintas tcnicas de cuantificacin son: Uniforme, No uniforme,
Logartmica y Vectorial. Pasemos a describir cada una de ellas.
2.1.2.1 Tcnica de cuantificacin Uniforme
Es el proceso de cuantificacin ms simple. En ella, toda la gama de
amplitudes que pueden tomar las muestras se divide en intervalos iguales y a

todas las muestras cuya amplitud cae dentro de un intervalo, se les da el
mismo valor.

En la figura a continuacin observamos como se han dividido en 8 intervalos la
amplitud de la seal.

Figura 33. Divisin de la amplitud de la seal en ocho intervalos.

El problema de la cuantificacin uniforme es que conforme aumenta la amplitud
de la seal, tambin aumenta el error. Si la amplitud de la seal es grande, los
intervalos se hacen tambin ms grandes con lo que muestras de muy
diferentes amplitudes podran caer en el mismo intervalo.

La solucin ms simple para resolver este problema sera aumentar los
intervalos de cuantificacin. As, al haber ms intervalos habr menos errores
pero necesitaremos ms nmeros binarios para cuantificar una muestra y por
tanto acabaremos necesitando ms ancho de banda para transmitirla.
2.1.2.2 Tcnica de cuantificacin No uniforme
En este caso lo que se hace es estudiar el comportamiento de la seal y
asignar niveles de cuantificacin no uniforme de manera que asignemos ms
intervalos al rango de amplitudes que mas frecuentemente se dan en la seal
de entrada.
2.1.2.3 Tcnica de cuantificacin Logartmica
Utilizando la cuantificacin logartmica, como paso previo a la propia
cuantificacin se hace pasar la seal por un compresor logartmico. Con esto
se consigue que la distancia entre los niveles de cuantificacin aumente a
medida que crece la amplitud de la seal. As, conseguimos tener ms niveles
para las amplitudes ms pequeas con lo que se proporciona mayor resolucin
en seales dbiles al compararse con una cuantificacin uniforme.

La principal ventaja de esta tcnica de cuantificacin es que es muy fcil de
implementar y funciona razonablemente bien con seales distintas a la de la
voz.

Para llevar a cabo la compresin existen dos funciones muy utilizadas: Ley-A
(utilizada principalmente en Europa) y ley- (utilizada en EEUU).

2.1.2.4 Tcnica de cuantificacin Vectorial
En los mtodos anteriores, cada muestra se cuantificaba independientemente
de las muestras vecinas. Sin embargo, la teora demuestra que sta no es la
mejor forma de cuantificar los datos de entrada. Resulta ms eficiente
cuantificar los datos en bloques de N muestras. El proceso es sencillamente
una extensin de los mtodos escalares anteriormente descritos. En este tipo
de cuantificacin, el bloque de N muestras se trata como un vector N-
dimensional.

La cuantificacin vectorial ofrece mejores resultados que la cuantificacin
escalar, sin embargo, es ms sensible a los errores de transmisin y lleva
consigo una mayor complejidad computacional.
2.1.3 Fase 3: Codificacin
La codificacin es el proceso mediante el cual se representa una muestra
cuantificada, mediante una sucesin de "1's" y "0's", es decir, mediante un
nmero binario.

As, usando la divisin en ocho intervalos de vista en la Figura 33, vemos como
la seal de origen estara codificada por la siguiente secuencia binaria:

000 001 001 000 111 111 000 001 001 000 111 111 000

El dispositivo que realiza la cuantificacin y la codificacin se llama codificador.
2.3 Tipos de codificadores de voz
Los codificadores de voz se clasifican en tres grandes grupos:

Codificadores de la forma de onda
Vocoders
Codificadores hbridos
2.3.1 Codificadores de la forma de onda
En codificadores de forma de onda, se engloban aquellos codificadores que
intentan reproducir la forma de la onda de la seal de entrada sin tener en
cuenta la naturaleza de la misma.

Los codificadores, en funcin de en qu dominio operen, se dividen en:

Codificadores en el dominio del tiempo
Codificadores en el dominio de la frecuencia

2.3.1.1 Codificadores en el dominio del tiempo
Dentro de este grupo tenemos los siguientes codificadores: PCM, DPCM y
ADPCM.

PCM (Pulse Code Modulation)

La modulacin por codificacin de impulsos es la codificacin de forma de onda
ms sencilla. Cada muestra que entra al codificador se cuantifica en un
determinado nivel de entre un conjunto finito de niveles. Cada uno de estos
niveles se hace corresponder con una secuencia de dgitos binarios, y sto es
lo que se enva al receptor. Se pueden usar distintos criterios para llevar a cabo
la cuantificacin, siendo el ms usado el de la cuantificacin logartmica.

DPCM (Differential Pulse-Code Modulation)

En las seales de frecuencia vocal, predominan generalmente las bajas
frecuencias, por ello las amplitudes de dos muestras consecutivas difieren
generalmente en una cantidad muy pequea. Aprovechando esta circunstancia,
se ha ideado la cuantificacin diferencial.

En la cuantificacin diferencial, en lugar de tratar cada muestra
separadamente, se cuantifica y codifica la diferencia entre una muestra y la que
le precede. Como el nmero de intervalos de cuantificacin necesarios para
cuantificar la diferencia entre dos muestras consecutivas es lgicamente
inferior al necesario para cuantificar una muestra aislada.

Con este codificador se reduce en un 25% los bits necesarios para cuantificar
una muestra.

ADPCM (Adaptive Differential Pulse Code Modulation)

Es un tipo de DPCM ms sofisticado, que se basa en ajustar la escala de
cuantificacin de forma dinmica para adaptarse mejor a las diferencias de la
seal de entrada.
2.3.1.2 Codificadores en el dominio de la frecuencia
Este tipo de codificadores dividen la seal en distintas componentes segn la
frecuencia y codifican cada una de stas de forma independiente. El nmero de
bits usados para codificar cada componente en frecuencia puede variar
dinmicamente.

Entre los codificadores de este tipo estn la codificacin en subbandas y la
codificacin por transformada.

2.3.2 Vocoders
En el grupo de vocoders estn aquellos codificadores que s tienen en cuenta
la naturaleza de la seal a codificar, en este caso la voz, y aprovechan las
caractersticas de la misma para ganar en eficiencia. Permiten trabajar con muy
bajos bit rates, pero la seal de voz que producen suena demasiado sinttica.
El ms utilizado es el vocoder por prediccin lineal.
2.3.3 Codificadores hbridos
En la codificacin hbrida se combinan las tcnicas de los codificadores de la
forma de la onda con las de los vocoders con el propsito de obtener una alta
calidad de voz a bajos bit-rates (inferiores a 8 Kb/s). En estos codificadores, las
muestras de la seal de entrada se dividen en bloques de muestras (vectores)
que son procesados como si fueran uno solo. Llevan a cabo una
representacin paramtrica de la seal de voz para tratar que la seal sinttica
se parezca lo ms posible a la original.

Tambin se les conoce como codificadores de anlisis-por-sntesis. En el
emisor se lleva a cabo un anlisis que obtiene los parmetros de la seal para
luego sintetizarla y conseguir el mayor parecido a la original.

Entre este tipo de codificadores se encuentran CELP (Code Excited Linear
Prediction) y RPE-LTP (Regular Pulse Excitation - Long Term Prediction).
2.4 Tabla Resumen de los principales cdecs de audio
En la tabla a continuacin, podemos ver un resumen de los cdecs ms
utilizados actualmente.

Nombre
Organismo
estandarizador
Tipo de
codificacin
Tasa de
bits
(Bit rate)
Frecuencia
de
muestreo
MOS
G.711 ITU-T PCM 64 Kbps 8 kHz 4.1
G.726 ITU-T ADPCM 32 Kbps 8 kHz 3.85
G.728 ITU-T CELP 16 Kbps 8 kHz 3.61
G.729A ITU-T CELP 8 Kbps 8 kHz 3.9
GSM ETSI RPE-LTP 13 Kbps 8 kHz 3.4
Tabla 3. Caractersticas de los cdecs ms utilizados.

El valor MOS
23
(Mean Opinion Score) hace referencia a la calidad de la voz la
cual es calificada con un nmero entre 1 y 5 proporcional a la calidad de la voz.
Un valor de 1 significa muy mala calidad y 5 significa excelente. Los valores se
obtienen mediante el promedio de las opiniones de un gran grupo de usuarios.
2.5 Influencias en el Ancho de Banda consumido por una
comunicacin
Adems de los bits que representan datos, todos los paquetes que circulan por
una red estn formados tambin por bits que son utilizados para cuestiones de
enrutamiento y correccin de errores. Estos bits, introducen en la red una
sobrecarga. As, estos bits aunque necesarios para el correcto funcionamiento
de la red, no aportan en realidad ningn beneficio directo a nuestra aplicacin.

Para aprovechar de forma eficiente el ancho de banda de una red VoIP, es de
suma importancia reducir esta sobrecarga.
2.5.1 Influencia del cdec en el ancho de banda
Lo primero que podemos pensar para reducir esta sobrecarga, es enviar
cuantos menos paquetes mejor para que la proporcin de datos frente a las
cabeceras sea mayor. As cuanto mayor sea la cantidad de sonido que
transmito en un paquete, menos cantidad de paquetes tendremos que enviar.

Ahora bien, al hacer esto estamos aumentado el impacto que tiene la prdida
de un paquete en la red y por tanto en la calidad de la conversacin. Si
enviamos un paquete con cantidades de sonido de 60ms, la prdida de uno de
estos paquetes se notar mucho ms que si por ejemplo enviamos cantidades
de 20ms.

Es por tanto clave llegar a un equilibrio entre una sobrecarga aceptable y una
tambin aceptable resistencia a errores para aprovechar mejor el ancho de
banda disponible.

El administrador, mediante la eleccin de un tiempo de intervalo u otro, tiene la
posibilidad de llegar al ya citado equilibrio.

En la siguiente tabla podemos ver las caractersticas de algunos de los cdecs
ms habituales utilizando el intervalo de paquete por defecto para cada uno de
ellos.

23
Es una representacin numrica de la calidad de la voz creada por la industria de las
telecomunicaciones y estandarizada en la ITU-T P.800.

Cdec
Ancho de
banda
Intervalo
de
paquete
Bits de voz
por
paquete
Procesado
G.711 64 Kbps 20ms 1280 bits Bajo
G.726 32 Kbps 20ms 640 bits Medio
G.728 16 Kbps 10ms 160 bits Alto
G.729A 8 Kbps 10ms 160 bits Alto
GSM 13 Kbps 20ms 160 bits Bajo
Tabla 4. Consumo de ancho de banda de los cdecs ms usados.

Tomando como ejemplo el cdec G.711, considerando que son necesarias
8000 muestras por segundo y teniendo en cuenta que para cada muestra
necesitamos 8 bits de informacin, como 20ms es 1/50s, vemos que la longitud
del campo de datos del paquete sera de 1280 bits.

Generalmente, para llamadas dentro de una LAN Ethernet se recomienda el
uso del cdec G.711 con intervalo de paquete de 20ms, ya que un ancho de
banda de 100Mbps soporta perfectamente cientos de conversaciones
simultneas de 64Kbps y la prdida de un paquete a 20ms es casi
imperceptible. Sin embargo para enlaces ms lentos, podemos optar por otros.

Hasta ahora hemos estado hablando de sobrecarga pero slo la que se refiere
a la cantidad de sonido que transporta un paquete. Ahora bien, la sobrecarga
es algo que tambin se ve afectado por las capas de red y enlace de datos. En
el apartado siguiente discutiremos este aspecto.
2.5.2 Influencia de las capas 2 y 3 en el ancho de banda
Al calcular el ancho de banda que necesitar una comunicacin debemos tener
en cuenta, que adems de los bits de datos, es necesario transportan otros bits
necesarios para que la informacin pueda ser encaminada a su destino.

Tomando como ejemplo una comunicacin SIP en una red Ethernet utilizando
el cdec G.711 con un intervalo de paquete de 20ms, vamos a ver cunto
suponen estos bits de sobrecarga en al clculo del ancho de banda por
paquete.

Primero, consideremos que los 1280 bits de audio calculados en el apartado
anterior se envan utilizando el protocolo RTP. A su vez, este protocolo utiliza
UDP como protocolo de trasporte el cual va contenido en un paquete IP que
por ltimo es encapsulado en una trama Ethernet para ser enviado.


En la figura a contuniacin podemos ver la cantidad de bits que aporta cada
cada protocolo utilizado.

Figura 34. Longitud total en bits de un paquete IP sobre Ethernet utilizando el cdec G.711.

En total, cada paquete Ethernet tiene una longitud de 1904, lo que supone que
un 32% de los bits que se transmiten son de sobrecarga.

Si utilizamos una velocidad de paquete de 20ms, estamos enviando 50
paquetes cada segundo. Por tanto, cada segundo enviamos 50 veces 1904 bits
o lo que es lo mismo, 95200 bits. Eso se traduce en que el ancho de banda real
que necesitaremos para transportar el trafico ser de 95.2 Kbps.

En la Tabla 5
24
observamos el ancho de banda total que necesitan algunos de
los cdecs ms utilizados cuando usando Ethernet como protocolo de capa
dos.

Cdec
Ancho de Banda
del sonido
Ancho de banda de la
sobrecarga de Ethernet
Ancho de banda
total
G.711 64 Kbps 31.2 Kbps 95.2 Kbps
G.726 32 Kbps 31.2 Kbps 63.2 Kbps
G.728 16 Kbps 31.2 Kbps 78.4 Kbps
G.729A 8 Kbps 31.2 Kbps 39.2 Kbps
GSM 13 Kbps 31.2 Kbps 44.2 Kbps
Tabla 5. Consumo de ancho da banda total de los cdecs ms habituales.

Decir que Ethernet no es el nico medio de trnasporte para la VoIP, se utilizan
otros como Frame Relay, ATM, enlaces de punto a punto. Cada uno de ellos
introducir por tanto una sobrecarga acorde con el tamao de bits de cabecera
que use.

24
Tabla obtenida del libro: Wallingford T, (2005), Switching to VoIP, OReilly, Seccin 6.2.3.4.

3. Calidad de servicio (QoS, Quality of Service)
3.1 Introduccin
El auge de la telefona IP es algo evidente y la principal razn es el
reaprovechamiento de los recursos y la disminucin en el coste de llamadas a
travs de Internet.

Sin embargo, si de algo adolece todava la VoIP es de la calidad de los
sistemas telefnicos tradicionales. Los problemas de esta calidad son muchas
veces inherentes a la utilizacin de la red (Internet y su velocidad y ancho de
banda) y podrn irse solventando en el futuro. Mientras tanto, cuanto mejor
conozcamos los problemas que se producen y sus posibles soluciones
podremos disfrutar de una mayor calidad.

Los principales problemas en cuanto a la calidad del servicio (QoS) de una red
de VoIP, son el Retardo, el Jitter y la prdida de paquetes. Adems
comentaremos los protocolos que podemos utilizar para garantizar un ancho de
banda y que nos permitan priorizar el trfico en tiempo real. Estos protocolos
son: 802.1p, 802.1q, Diffserv, RSVP y MLPS.
3.2 Factores que afectan a la calidad de servicio
3.2.1 Cdec utilizado en la comunicacin
El primer factor que influye en la calidad del sonido de la voz es sin duda el
cdec utilizado. As, hay una correlacin general entre la calidad de voz y la
velocidad de datos: cuanto mayor sea el bit rate de un cdec, mejor ser la
calidad de la voz.
3.2.2 Retardo o Latencia
A la latencia tambin se la llama retardo. No es un problema especfico de las
redes no orientadas a conexin y por tanto de la VoIP. Es un problema general
de las redes de telecomunicacin. Por ejemplo, la latencia en los enlaces va
satlite es muy elevada por las distancias que debe recorrer la informacin.

La latencia se define tcnicamente en VoIP como el tiempo que tarda un
paquete en llegar desde la fuente al destino.

La latencia o retardo entre el punto inicial y final de la comunicacin debiera ser
ser inferior a 150 ms. El odo humano es capaz de detectar latencias de unos

250 ms, 200 ms en el caso de personas bastante sensibles. Si se supera ese
umbral la comunicacin se vuelve molesta.

El retardo puede ser provocado por las siguientes causas: retardo del
algoritmo, de paqetizacin, de serializacin, de propagacin y de componente.
3.2.2.1 Retardo por causa del algoritmo
Es el retardo introducido por el codificador al procesar los datos. Los cdecs
vocales actan sobre conjuntos de muestras vocales conocidos como tramas.
Cada bloque de muestras vocales de entrada se procesa para convertirlo en
una trama comprimida. La trama vocal codificada no se genera hasta que todas
las muestras vocales de la trama de entrada hayan sido recogidas por el
codificador.

De este modo, hay un retardo de duracin la longitud de una trama antes de
que pueda comenzar el procesamiento. Adems, muchos codificadores
tambin miran a la trama siguiente para mejorar la eficacia de compresin
introduciendo otro tiempo de retardo llamado tiempo de indagacin.

El tiempo requerido para procesar una trama de entrada se supone que es el
mismo que la longitud de trama. Por tanto, el retardo a travs de un par
codificador/decodificador se supone que es normalmente:

2 tamao de trama + indagacin

Los valores de retardo de los principales estndares los podemos ver en la
siguente tabla
25
:

Cdec
Tamao de
trama (ms)
Tiempo de
indagacin (ms)
Retardo algortmico
total (ms)
G.711 0.125 0 0.250
G.726 0.125 0 0.250
G.728 0.625 0 1.150
G.729A 10 5 30
GSM 20 0 40
Tabla 6. Retardo de los principales cdecs.
3.2.2.2 Retardo por causa de la paquetizacin
Si cada trama codificada la metiramos en un paquete IP y la envisemos,
habra que contar con un retardo introducido por el ensamblado del paquete IP

25
Los valores estn sacados de la recomendacin ITU-T G.114.

y el correspondiente al de la capa de enlace de datos. En el caso de Ethernet,
este tiempo se considera despreciable.

Sin embargo, para evitar problemas de sobrecarga, varias tramas codificadas
son puestas en un mismo paquete para ser enviadas. As habr que esperar un
tiempo hasta que el paquete se llene de tramas para enviarlo
26
. Por ejemplo, si
utilizamos el cdec G.711 y esperamos un tiempo de 20ms para formar un
paquete, cada paquete contendr 160 tramas.

Se considera que el retardo mnimo debido al procesamiento del cdec
(incluyendo el retardo del algoritmo y el de paquetizacin), en los sistemas
basados en IP es:

(N + 1) tamao de trama + indagacin

Donde N es el nmero de tramas.

En la siguiente tabla podemos ver el valor de los retardos de los principales
estndares para un tiempo de paquetizacin de 20ms.

Cdec
Tamao
de
trama
(ms)
Tiempo de
indagacin
(ms)
Tiempo de
paquetizacin
(ms)
N de
tramas por
paquete
Retardo
total (ms)
G.711 0.125 0 20 160 20.125
G.726 0.125 0 20 160 20.125
G.728 0.625 0 20 32 20.625
G.729A 10 5 20 2 35
GSM 20 0 20 1 40
Tabla 7. Retardo de los principales cdecs para un tiempo de paquetizacin de 20ms.
3.2.2.3 Retardo por causa de la serializacin
Es el tiempo requerido para por la colocacin uno a uno de todos los bits a
transmitir en el medio fsico. Depende directamente de la velocidad del enlace y
del tamao del paquete que se quiera transmitir.

Por ejemplo, si usamos el cdec G.711 con un periodo de paquetizacin de 20
ms, habra 160 bytes de datos de voz (ya que cada muestra es de 8 bits). Para
calcular el tamao de una trama completa de Ethernet, tendremos que aadirle
las cabeceras de los diferentes protocolos en los que se va encapsulando la
voz.

26
En la recomendacin RFC 3551 [4.2], se recomienda que para paquetes RTP se utilice un
tiempo de paquetizacin de 20ms aunque ste es un parmetro configurable.

As, sumamos 20 bytes de RTP, 16 bytes de UDP, 20 bytes de IP y 14 bytes de
Ethernet. Esto nos da un total de 70 bytes de cabeceras que sumado a los 160
bytes de voz dan un total de 230 bytes. En la tabla a continuacin vemos
cuanto sera el retardo dependiendo de la velocidad del enlace.

Velocidad del
enlace (Kbps)
56 64 128 512 1024 1544
Retardo de
serializacin (ms)
32.85 28.75 14.375 3.6 1.8 1.2
Tabla 8. Retardo dependiendo de la velocidad del enlace.
3.2.2.4 Retardo por causa de la propagacin
Es el tiempo requerido por la seal ptica o elctrica para viajar a travs de un
medio de transmisin y es proporcional a la distancia que recorre. La velocidad
depende del medio por donde transite la seal. As por ejemplo, la velocidad de
propagacin utilizando un cable es de aproximadamente 4 o 6 s/Km y para
una transmisin por satlite, el retardo es de unos 12 a 260 ms dependiendo de
la altura a la que est.
3.2.2.5 Retardo por causa de los componentes
Los retardos de componente son causados por los equipos intermedios que
debe atravesar una comunicacin. Si el paquete que contiene la trama de
sonido debe atravesar por ejemplo un router
27
, este introducir un retraso
debido al tiempo que tarda en mirar las cabeceras, mover el paquete de
interfaz, etc.
3.2.2.6 Problemas causados por el Retardo: Eco y Solapamiento
Despus de comentar todas las causas por las que puede producirse retardo
en una comunicacin, vamos a ver a continuacin los dos principales
problemas que causa: el eco y el solapamiento.

Eco

El eco se define como una reflexin retardada de la seal acstica original. Se
hace ms molesto cuanto mayor es el retardo y cuanto mayor es su intensidad
con lo cual se convierte en un problema en VoIP puesto que los retardos
suelen ser mayores que en la red de telefona tradicional.

Cuando el retardo en una comunicacin es bajo, el eco que genera un
participante al hablar regresa muy rpido y no se percibe. As, si el enlace de
una comunicacin tiene un retardo menor que 25ms, el eco llegar tan rpido al
participante que ha hablado que no lo percibir. Sin embargo, el retardo de una

27
Para consultar el retardo que introducen otros medios o equipos en una comunicacin
podemos consultar la recomendacin de la ITU G.114 [A.1].


comunicacin VoIP es casi siempre superior a esta cifra con lo que hay que
combatirlo siempre.

Hay dos tcnicas para eliminar el eco:

a) Supresores de eco: consiste en evitar que la seal emitida sea devuelta
convirtiendo por momentos la lnea full-duplex en una lnea half-duplex de tal
manera que si se detecta comunicacin en un sentido se impide la
comunicacin en sentido contrario. El tiempo de conmutacin de los supresores
de eco es muy pequeo pero impide una comunicacin full-duplex plena.

b) Canceladores de eco: es el sistema por el cual el dispositivo emisor guarda
la informacin que enva en memoria y es capaz de detectar en la seal de
vuelta la misma informacin (tal vez atenuada y con ruido). El dispositivo filtra
esa informacin y cancela esas componentes de la voz. Esta tcnica requiere
mayor tiempo de procesamiento que la anterior.

Solapamiento

An con un mtodo de cancelacin de eco perfecto, mantener una
conversacin llega a ser dificultoso cuando el retardo es demasiado grande
debido al solapamiento de las voces de los participantes.

Para terminar y en lneas generales, se debe intentar que el retardo o latencia
de un enlace sea inferior a 150ms. Un valor entre 150ms y 400ms puede ser
tolerable siempre y cuando se vigile el trfico por parte del administrador. Un
valor superior a 400ms es ya inaceptable.

En la Figura 35
28
observamos el grado de satisfaccin de los usuarios con
respecto a la cantidad de latencia.

28
Figura extrada de la recomendacin de la ITU-T G.114.

Figura 35. ndice de satisfaccin de los usuarios con respecto a la latencia.

Decir, que esta grfica est elaborada utilizando el modelo E
29
. Este modelo
fue creado para estimar o predecir la calidad de la voz en redes IP (VoIP)
percibida por un usuario tpico, en base a parmetros medibles de la red.

El resultado del E-Model es un factor escalar, llamado R (Transmission Rating
Factor), que puede tomar valores entre 0 y 100.

Aqu en esta grfica podemos ver R, en funcin del retardo. Tambin se
muestran las categoras de la calidad vocal
30
que transforma los valores de R
en valores de aceptacin de usuario.
3.2.3 Jitter
El jitter se define tcnicamente como la variacin en el tiempo en la llegada de
los paquetes y es algo ligado al hecho de que los paquetes en una red de
conmutacin de paquetes no orientada a la conexin siguen diferentes rutas
para llegar al destino.

La solucin ms ampliamente adoptada para la correccin del jitter es la
utilizacin de un buffer donde almacenar los paquetes para posteriormente
servirlos con un pequeo retraso. Si algn paquete no est en el buffer (porque
se perdi o porque no ha llegado todava) cuando sea necesario, ste se
descarta.

29
Creado por la ITU en la ITU T G.107.
30
Definidas en la recomendacin ITU-T G.109 [5].

Normalmente en los telfonos se pueden modificar el tamao de los buffers.
As, un aumento del buffer implica menos prdida de paquetes pero ms
retraso y una disminucin implica menos retardo pero ms prdida de
paquetes.
3.2.4 Prdida de paquetes
Las comunicaciones en tiempo real estn basadas en el protocolo UDP. Este
es un protocolo no orientado a conexin por lo tanto si se produce la prdida de
algn paquete no se reenviar. Tambin se pueden producir prdidas al
descartarse paquetes que llegan, pero que no lo hacen a tiempo.

Sin embargo la voz es bastante predictiva y si se pierden paquetes aislados se
puede recomponer la voz de una manera bastante ptima. El problema es
mayor cuando se producen prdidas de paquetes en rfagas.

La perdida de paquetes mxima admitida para que no se degrade la
comunicacin deber ser inferior al 1%. Pero es bastante dependiente del cdec
que se utilice
31
. Cuanto mayor sea la compresin del cdec ms pernicioso es
el efecto de la prdida de paquetes. Una prdida del 1% degrada ms la
comunicacin si se usa el cdec G.729 que si utilizamos G.711.
3.3 Protocolos para mejorar la calidad de servicio
Entre los protocolos que vamos a describir a continuacin, podemos hacer la
distincin de protocolos CoS (Class of Service) y QoS (Quality of Service). Los
primeros tienen la capacidad de hacer una distincin del trfico que circula por
una red para despus poder tratarlo en funcin de esta clasificacin pero no
tienen ningn mecanismo para reservar, y por lo tanto garantizar, un
determinado ancho de banda. En este grupo se encuentran 802.1p, Diffserv y
802.1q.

Por otro lado tenemos a los protocolos Intserv y MPLS, los cuales son
considerados protocolos QoS por tener la capacidad de reservar un
determinado ancho de banda a una comunicacin.

Pasemos a describir cada unos de ellos:
3.3.1 802.1p
IEEE 802.1p es un estndar que proporciona priorizacin de trfico y filtrado
multicast dinmico. Esencialmente, proporciona un mecanismo para
implementar calidad de servicio a nivel de MAC (Media Access Control).

31
Para ver las distintas tolerancias a prdidas de paquetes de los codecs aconsejamos mirar la
recomendacin G.113 de la ITU-T.

Utilizando una etiqueta de 3 bits aadida a la trama Ethernet, se asigna a cada
paquete un nivel de prioridad entre 0 y 7. No est definida la manera de cmo
tratar el trfico que tiene asignada una determinada clase o prioridad, dejando
libertad a las implementaciones. IEEE, sin embargo, ha hecho amplias
recomendaciones al respecto.

Aunque es un mtodo de priorizacin bastante utilizado en entornos LAN tiene
como inconveniente que slo puede ser soportada en redes de este tipo, ya
que las etiquetas se eliminan cuando los paquetes pasan a travs de un router.
3.3.2 Diffserv
DiffServ (Differentiated Services) es una arquitectura de red que define un
mtodo simple, escalable y de ajuste grueso para clasificar el trfico de una red
y proveer CoS.

En una arquitectura Diffserv todos los paquetes que pertenezcan a una misma
clase recibirn un mismo tratamiento por parte de la red. As, cuanto mayor sea
la prioridad o el ancho de banda asignado a la clase mejor trato recibir. La
ventaja de DiffServ frente a las otras arquitecturas consiste en la posibilidad de
utilizar la actual infraestructura de red sin necesidad de introducir grandes
cambios, y entre sus inconvenientes que no es capaz de garantizar de forma
determinista una determinada calidad de servicio, garantizando slo un mejor
tratamiento a ciertos flujos (calidad relativa) por parte de la red.

Una red DiffServ consta de dos tipos de nodos, los nodos frontera y los nodos
interiores. Los nodos frontera son los encargados de clasificar el trfico
entrante, asignndolo a algunas de las clases. Cuando llega trfico a un
dominio Diffserv, el nodo frontera asigna cada paquete a una de las clases en
funcin de diversos criterios como puede ser direccin origen/destino, puertos,
protocolo, etc. Una vez asignada a una clase el paquete es introducido en el
dominio DiffServ y no vuelve a ser reexaminado.
3.3.3 802.1q VLAN
El protocolo IEEE 802.1Q fue un proyecto del grupo de trabajo 802 de la IEEE
para desarrollar un mecanismo que permitiera a mltiples redes compartir de
forma transparente el mismo medio fsico, sin problemas de interferencia entre
ellas.

En esta tecnologa, los switches se utlizan para agruprar estaciones de trabajo
y servidores en agrupaciones lgicas. Los dispositivos que pertenecen a una
VLAN estn restringidos a la comunicacin con los dispositivos de su propia
VLAN, de modo que la red conmutada funciona como como varias LAN
individuales sin conectar.

Las cabeceras de las tramas son modificadas para introducir una etiqueta que
identifique a que VLAN pertenece cada trama. Esta etiqueta incluye un campo

de prioridad igual que el de 802.1p con el que igual que antes podemos
proirizar el trfico.

Adems de esto, la divisin de una red en VLANs aporta otras muchas ventajas
entre ellas la de la reduccin de los dominios de broadcast, de seguridad, etc.

Por ltimo decir que muchas empresas separan el trfico de sus redes en dos
VLANs, una para los datos y otra para la VoIP.
3.3.4 Intserv (Integrated Service) y RSVP
Basado en la utilizacin de un protocolo de reserva (RSVP, ReSerVation
Protocol), nos permite realizar una reserva de recursos en todos los routers
implicados en la comunicacin. As, un host solicitar una QoS especfica de la
red para una aplicacin o flujo de datos en particular y los routers enviarn las
solicitudes de QoS a todos los nodos a lo largo de la trayectoria del dato.

El principal inconveniente que se nos presenta ante esta tecnologa, radica en
la necesidad de mantener informacin sobre cada flujo en todos los routers de
la red, lo cual conduce a problemas de escalabilidad.

En comparacin con la arquitectura Diffserv que se considera de ajuste grueso,
Intserv es considerada de ajuste fino.
3.3.5 MPLS
MPLS
32
(siglas de Multiprotocol Label Switching) es un mecanismo de
transporte de datos estndar que opera entre la capa de enlace de datos y la
capa de red del modelo OSI.

MPLS proporciona los beneficios de la ingeniera de trfico del modelo de IP
sobre ATM, pero adems, otras ventajas; como una operacin y diseo de red
ms sencilla y una mayor escalabilidad.

MPLS asigna a las tramas que circulan por la red una identificacin que le
indica a los routers la ruta que deben seguir los datos. Por lo tanto, MPLS sirve
para la administracin de la calidad de servicio al definir cinco clases de
servicios.

En su da dominio exclusivo de grandes corporaciones y operadores de
telecomunicaciones, constituye ya una alternativa de mucho mayor alcance. La
creciente necesidad de reducir costes, aumentar la productividad, soportar ms
aplicaciones y elevar la seguridad est jugando fuerte a favor del cambio
corporativo hacia esta nueva tecnologa WAN.

32
Creado por la IETF y definido en el RFC 3031.

I II I. . P Pl la at ta af fo or rm ma a A As st te er ri is sk k

En esta segunda parte, presentaremos la plataforma de telefona y
centralita telefnica Asterisk, describiendo para ello su arquitectura interna,
algunos escenarios donde puede actuar as como los dispositivos que tiene
que disponer un usuario final para beneficiarse de sus servicios.

A continuacin, se describir cmo Asterisk es capaz de interactuar con la Red
Telefnica Bsica.

Para terminar, haremos un pequeo recorrido por las diferentes tecnologas y
productos que nos ofrece el mercado actual, tanto los que se basan en Asterisk
como los que representan una alternativa a ste.

Plataforma Asterisk 4. Asterisk


4. Asterisk
En este captulo descubriremos qu es exactamente Asterisk y para qu sirve.
Para ello presentaremos brevemente las funcionalidades que ofrece,
comentaremos su arquitectura y describiremos algunos de los escenarios
donde Asterisk puede actuar.
4.1 Qu es un PBX?
Un PBX o PABX (Private Branch Exchange y Private Automatic Branch
Exchange respectivamente) cuya traduccin al espaol sera: central
secundaria privada automtica, es cualquier central telefnica conectada
directamente a la red pblica de telfono por medio de lneas troncales para
gestionar, adems de las llamadas internas, las entrantes y/o salientes con
autonoma sobre cualquier otra central telefnica. Este dispositivo
generalmente pertenece a la empresa que lo tiene instalado y no a la compaa
telefnica, de aqu el adjetivo privado a su denominacin.

Un PBX se refiere al dispositivo que acta como un ramificacin de la red
primaria pblica de telfono, por lo que los usuarios no se comunican con el
exterior mediante lneas telefnicas convencionales, sino que al estar el PBX
directamente conectado a la RTB (Red Telefnica Pblica), ser esta misma la
que enrute la llamada hasta su destino final mediante enlaces unificados de
transporte de voz llamados lneas troncales.

En otras palabras, los usuarios de un PBX no tienen asociada ninguna central
de telfono pblica, ya que es el mismo PBX que acta como tal, anlogo a
una central pblica que da cobertura a todo un sector mientras que un PBX lo
ofrece a las instalaciones de una compaa generalmente.

No tienen lmite en cuanto al nmero de estaciones que pueden servir, pero el
precio aumenta segn el nmero de estaciones. Los sistemas PBX son ms
sofisticados que los equipos multilnea o los sistemas hbridos, pero tambin
son ms costosos. La capacidad de un PBX no se determina por lneas, sino
por puertos, el nmero total de alambres que puede conectar el sistema. Los
sistemas PBX pueden soportar caractersticas especiales de tecnologa
avanzada.



4.2 Qu es Asterisk?
Asterisk es tanto una plataforma de telefona como una centralita software
(PBX) de cdigo abierto. Como cualquier centralita PBX permite interconectar
telfonos y conectar dichos telfonos a la red telefnica pblica. Su nombre
viene del smbolo asterisco (*) en ingls.

El creador original de esta centralita es Mark Spencer de la compaa Digium
que sigue siendo el principal desarrollador de las versiones estables. Pero al
ser de cdigo libre, existen multitud de desarrolladores que han aportado
funciones y nuevas aplicaciones. Originalmente fue creada para sistemas Linux
pero hoy en da funciona tambin en sistemas OpenBSD, FreeBSD, Mac OS X,
Solaris Sun y Windows aunque Linux sigue siendo la que ms soporte
presenta.

El paquete bsico de Asterisk incluye muchas caractersticas que antes slo
estaban disponibles en caros sistemas propietarios como creacin de
extensiones, envo de mensajes de voz a e-mail, llamadas en conferencia,
mens de voz interactivos y distribucin automtica de llamadas. Adems se
pueden crear nuevas funcionalidades mediante el propio lenguaje de Asterisk o
mdulos escritos en C o mediante scripts AGI escritos en Perl o en otros
lenguajes.

Asterisk soporta numerosos protocolos de VoIP como SIP y H.323. Asterisk
puede operar con muchos telfonos SIP, actuando como servidor de registro, o
como "gateway" entre telfonos IP y la red telefnica convencional.

Al soportar una mezcla de la telefona tradicional y los servicios de VoIP,
Asterisk permite a los desarrolladores construir nuevos sistemas telefnicos de
forma eficiente o migrar de forma gradual los sistemas existentes a las nuevas
tecnologas. Algunos sitios usan Asterisk para reemplazar a antiguas centralitas
propietarias, otros para proveer funcionalidades adicionales y algunas otras
para reducir costes en llamadas a larga distancia utilizando Internet.
4.3 Arquitectura de Asterisk
La figura a contuniacin, nos muestra los diferentes subsistemas que forman
Asterisk.



Asterisk Application API
Cdec
Translator
Scheduler and
IO Manager
Application
Launcher
Dynamic Module
Loader
PBX
Switching
Asterisk Channel API

Figura 36. Subsistemas de Asterisk.

Cada uno de ellos realiza una funcin diferente.

Dinamic Module Loader: cuando iniciamos Asterisk, es el encargado
de cargar e inicializar los drivers necesarios.

PBX Switching: es el encargado de aceptar y conectar las llamadas que
recibe por las interfaces. Actua segn lo definido en el plan de
numeracin.

Application Launcher: el PBX Switching utiliza este subsistema para
lanzar las aplicaciones que sean necesarias como por ejemplo hacer
sonar un telfono, hacer saltar el buzn de voz de un usuario, etc.

Codec Translator: codifica y decodifica los formatos de audio en el caso
de que dos canales usen un cdec diferente.

Scheduler and I/O Manager: es el encargado de organizar las tareas de
bajo nivel y de gestionar la entrada/salida para consiguer un ptimo
rendimiento en todo tipo de situaciones de carga de trabajo.

Hay cuatro APIs (Application Programming Interface) definidas para
proporcionar funcionalidad de forma independiente al tipo de hardware y al
protocolo que se usen.

Channel API: esta API provee mecanismos para manejar el tipo de
conexin que se est utilizando en una llamada (VoIP, ISDN, etc.).

Application API: proporciona la funcionalidad para ejecutar aplicaciones
tales como el buzn de voz, directorio de llamadas, etc.



Codec Translator API: contiene los mdulos de diferentes cdecs para
dar soporte a los diferentes formatos de audio y vdeo.

File Format API: proporciona la funcionalidad necesaria para la lectura y
escritura de diferentes formatos de archivo que se almacenan en el
sistema.
4.4 Concepto de Canales en Asterisk
El concepto de canal en Asterisk es de suma importancia. Asterisk utiliza un
canal para comunicarse con los clientes que utilicen un protocolo o una
tecnologa determinada. Los nombres de estos canales coinciden en Asterisk
con los nombre de los protocolos o tecnologas que se emplean para la
comunicacin.

As, podemos identificar entre otros los siguientes canales:

Canal SIP: ser el canal que se utilice para las comunicaiones que se
envien o reciban de clientes SIP.

Canal H.323: es el canal que se usar para las comunicaciones de los
clientes que utilicen el protocolo H.323.

Canal IAX2: lo mismo pero para los clientes que utilicen el protocolo
IAX2.

Canal Dahdi: es el canal que utiliza Asrerisk para comunicarse con las
lneas provenientes de la RTB tanto analgicas como digitales.

A modo de ilustracin podemos observar la Figura 37 a continuacin, donde los
canales estn representados a modo de tuberas que tiene Aterisk por donde
entran y salen las comunicaciones de los clientes pertenecientes a
determinados protocolos o tecnologas.

Figura 37. Canales en Asterisk.


Como norma general, Asterisk tendr un archivo de configuracin por cada
canal. En ellos definiremos aspectos generales del protocolo o tecnologa en
cuestin as como informacin de los clientes que lo utilizarn.
4.5 Asterisk en diferentes escenarios
Atendiendo a su funcin de centralita telefnica, Asterisk pueder usarse en
multitud de escenarios. As, puede proveer servicios de telefona a usuarios
que se encuentran en una LAN y desean poder realizar llamadas entre ellos, o
bien, llendo un poco ms lejos, utilizar internet para realizar llamadas a otros
usuarios conectados e sta o incluso tener la capacidad de llamar a telfonos
convencionales conectados a la RTB. A continuacin describiremos qu
necesita Asterisk para poder dar servicio en cada uno de estos casos.
4.5.1 Llamadas internas en nuestra oficina
El escenario ms simple que podemos imaginar para Asterisk, es proporcionar
llamadas para los usuarios de una red la cual no est conectada con internet.
El ejemplo ms claro de esto sera una red privada dentro de una empresa u
oficina.

Figura 38. Asterisk en una red interna.

Como observamos en la Figura 38, slo es necesario conectar el servidor
Asterisk a la red IP mediante una NIC y con la configuracin pertinente los
usuarios de la red podrn realizar llamadas entre ellos sin coste alguno.



4.5.2 Conectar nuestra oficina con Internet
En este segundo escenario, tenemos la misma red privada que antes pero
conectada a Internet. Con este simple hecho, un empleado de nuestra oficina
podr establecer llamadas con cualquier dispositivo VoIP que este conectado a
Internet sin coste alguno.

Slo habr que tener en cuenta cuestiones tales como el ancho de banda
necesario para soportar el aumento de trfico, la seguridad, pero no habr que
incurrir en ms gastos que la propia conexin a Internet.

Imaginemos que una compaa con dos sedes, una en Sevilla y otra en
Montreal por ejemplo, tienen ambas un sistema Asterisk. Si las dos estn
conectadas a Internet, se podrn realizar llamadas entre ambos sitios a travs
de la red.

SoftPhone
Fax
Telfono analgico
Asterisk
Telfono IP
Adaptador
Analgico - Digital
Nuestra Red
Internet
Telfono IP

Figura 39. Asterisk conectado a Internet.
4.5.3 Conectar nuestra oficina con la RTB
En este ltimo escenario, la red privada ya conectada a Internet se ha unido a
la red telefnica pblica. Para poder recibir llamadas de cualquier telfono
convencional de la RTB necesitaremos disponer de lneas de telfono
proporcionadas por una compaa telefnica.



Figura 40. Asterisk conectado a la RTB.

Las lneas telefnicas debern llegar a Asterisk utilizando para ello una tarjeta
conectada al bus PCI o un dispositivo externo denominado pasarela VoIP.
Ambos mtodos proveen una interfaz entre la red IP de nuestra oficina con la
red telefnica.
4.6 Tipos de terminales VoIP usados con Asterisk
Para realizar y recibir llamadas, los usuarios necesitan de unos dispositivos
terminales que proporcionen la funcionalidad de un telfono. Estos pueden ser
ordenadores, telfonos IP o telfonos convencionales analgicos. En este
ltimo caso ser necesario algn tipo de adaptador que convierta las ondas
analgicas en digitales. Veamos los tres grupos ms en profundidad.

Softphones: para utilizar un ordenador como terminal VoIP es ncesario
utilizar una aplicacin software que simule un telfono llamada
Softphone. Entre los modelos ms usados se encuentran el X-Lite de
CounterPath Corporation o el Zoiper.



Figura 41. Interfaz del softphone Zoiper.

Figura 42. Interfaz del softphone X-Lite.

Telfonos IP: la apariencia es de un telfono convencional pero tiene
una conexin RJ45 para conectarlo a la red. Entre los principales
constructores de telfonos IP estn: Cisco, Polycom, Snom,
Grandstream y Aastra.

Figura 43. Modelo Snom 360.



Figura 44. Modelo SoundPoint IP 501 de Polycom.

Telfonos analgicos o maquins de fax con un adaptador digital. En
la figura n podemos ver el aspecto de un adaptador, concretamente el
S101I IAXy de Digium, el cual permite transformar la seal analgica
de un telfono en paquetes de voz sobre IP utilizando el protocolo IAX.

Figura 45. Modelo S101I IAXy de Digium.

El modelo de la Figura 46 a continuacin es el Linksys PAP2T el cual es
otro adaptador pero utilizando el protocolo SIP y pudiendo conectar dos
telfonos en vez de uno.

Figura 46. Modelo Linksys PAP2T.


Por lo tanto, la infraestuctura creada para la red de datos es aprovechada
completamente, requirindose slo un mnimo de hardware para dar servicio de
telefona a la red.
4.7 Formas de conectar Asterisk con la Red Telefnica Bsica
Las compaas telefnicas nos ofrecen diferentes tecnologas para conectarnos
a la red de telefona bsica. Aqu describiremos las dos formas ms usuales.
4.7.1 Conexin mediante una lnea de telfono bsica
La forma ms simple de conectarnos sera mediante una lnea POTS (Plain Old
Telephone Network) o lnea de telfono bsica. Esto es la lnea de telfono que
todos tenemos en casa. Esta lnea representa un canal de transmisin y slo
se puede transmitir por l una llamada.

Una posible tarjeta para hacer esta conexin la podemos ver en la figura n.
Esta tarjeta es comercializada por Digium, la misma empresa creadora de
Asterisk. Se conecta al ordenador mediante el bus PCI y presenta una serie de
puertos a los que le podemos conectar una combinacin de lneas FXS
(Foreign Exchange Station) y FXO (Foreign Exchange Office), segn el modelo.

Figura 47. Modelo AX800 de Digium con ocho puertos analgicos.

Recordemos que una interfaz FXS es la que maneja al telfono
proporcionndole la batera y el voltaje necesario para que suene. En nuestra
casa, es ni ms ni menos que la roseta en la pared donde conectamos el
telfono. Una interfaz FXO recibe este voltaje y hace sonar al telfono. En este
caso sera la clavija que introducimos en la roseta. En la Figura 48, podemos
ver claramente la colocacin de las estas interfaces en el camino de una
llamada desde la central hasta un telfono.



Figura 48. Interfaces FXS y FXO.

Por lo tanto esta tarjeta nos permite conectar lneas telefnicas que vienen de
la central a las interfaces FXS y telfonos analgicos a las interfaces FXO.

La segunda posibilidad es utilizar un dispositivo externo que haga de interfaz
entre la red telefnica y la red IP. Es como si sacramos la tarjeta antes
comentada y la pusisemos en un dispositivo aparte.

En la Figura 49 podemos ver la pasarela VoIP Linksys SPA 3102, la cual tiene
un puerto FXO RJ11 para conectarlo a la roseta de telfono, un puerto FXS
para conectar un telfono o fax analgico, un puerto Ethernet para conectarlo a
la red y por ltimo ofrece un puerto para conectarnos a internet mediante DSL.

Figura 49. Modelo Linksys SPA 3102.
4.7.2 Conexin mediante una lnea RDSI
Otra forma muy comn de conexin con la RTB es utilizar una lnea RDSI (Red
Digital de Servicios Integrados). Estas lneas utilizan el bucle local para brindar
una comunicacin digital entre el usuario y el operador de telefona.

Este enlace digital est formado por canales de 64 Kbps los cuales pueden
transportar audio o datos y soportan tanto conexiones de conmutacin de
circuitos como de conmutacin de paquetes utilizando para ello otros
protocolos como por ejemplo X.25. Adems de estos canales llamados
canales B, se usa otro canal de 16 o 64 Kpbs llamado canal D para
transportar datos referentes a la sealizacin.



El protocolo RDSI ofrece dos servicios, el bsico y el primario. El servicio
bsico (BRI) consta de dos canales B y un canal D, permitiendo tener sobre un
mismo cable dos lneas telefnicas.

El servicio primario, ofrece un nmero diferente de canales segn estemos en
Europa o Estados Unidos. En la primera, el servicio primario (PRI) ofrece un
total de 32 canales B mientras que en el segundo, el nmero total de canales B
es de 23. En ambos casos existe un canal D que transporta la sealizacin.
Este nmero de canales hace que para Europa el servicio primario se equipare
con una lnea E1 y en el caso de Estados Unidos con una T1.

Para conectar Asterisk a la RTB mediante lneas de este tipo existen tarjetas
que conectadas normalmente al bus PCI hacen de interfaz entre la red
telefnica pblica y nuestro sistema.

Segn el nmero de lneas que queramos utilizar, disponemos de varios
modelos de tarjetas de diferentes fabricantes. Siqueremos usar un servicio BRI,
las ms conocidas son:

Tarjetas Billion: nos permiten conectar una nica lnea RDSI BRI a
cada tarjeta. Es una solucin econmica pero considerada de calidad
medio baja.

Tarjetas Junghanns: con los modelos unoBRI, duoBRI, quadBRI y
octoBRI, podemos conectar una, dos, cuatro y ocho lneas RSDI
respectivamente. Las hay tanto para usar una conexin PCI norma como
una PCI Express. Su calidad es considerada medio alta. Es importante
sealar que para utilizarlas con Asterisk es necesario utilizar el driver
BRIstuff.

Figura 50. Modelo duoBRI de Junghanns.

Tarjetas Beronet: dispone de los modelos BNS20, BNS40 y BNS80
para disponer de dos, cuatro y ocho lneas RDSI respectivamente. Para
utilizarlas con Asterisk es necesario utilizar el driver mISDN. Su calidad
est considerada medio alta.



Figura 51. Modelo BNS80 de Beronet.

Tarjetas Digium: Digium slo dispone de un modelo con cuatro puertos
BRI, el B410P. Es considerado como de calidad alta y no necesita de
drivers externos ya que est integrado con Asterisk.

Figura 52. Modelo B410P de Digium.

Si queremos utilizar el servicio primario (PRI), es Digium el que brinda una
mayor variedad de productos con modelos que permiten cuatro primarios,
como el TE420, dos como el TE220 y uno como el TE120P. A parte de estos
hay ms modelos dependiendo si las tarjetas funcionan a 3.3 o 5 Voltios, el tipo
de cancelador de eco, etc.

Figura 53. Modelo TE120P de Digium.



Estas tarjetas al ser de Digium estn todas integradas en Asterisk y no
necesitan de ningn driver adicional.
4.8 Recorrido por el mercado actual de la telefona de cdigo
abierto
En el mercado actual, Asterisk no es la nica solucin para la telefona de
cdigo abierto. Otros proyectos, cada uno con sus comunidades de
desarrolladores, ofrecen las funcionalidades de un PBX y aunque no son tan
populares como Asterisk son soluciones perfectamente vlidas.

Para hacer un recorrido por las distintas posibilidades que nos ofrece el
mercado, vamos a hacer una divisin de ste en tres niveles: plataformas de
telefona, soluciones configurables y soluciones llave en mano.
4.8.1 Nivel 1: Plataformas de telefona
En este primer nivel tenemos los proyectos que proveen la tecnologa
necesaria para desarrollar soluciones de telefona. Son por tanto plataformas
para desarrollar servicios de telefona utilizados por usuarios con un alto nivel
tcnico como por ejemplo empresas constructores de PBX, de pasarelas VoIP
de softphones, etc. Destacamos plataformas como:

sipXecs
33
: el cual es compatible con Linux, Windows y MAC pero no soporta
tarjetas para conectarse a la RTB, con lo que es obligatorio el uso de pasarelas
adicionales si queremos conectarnos a ella.

Yate
34
(Yet Another Telephony Engine): es una solucin que destaca por su
flexibilidad ya que permite implementar un gran nmero de dispositivos tales
como: clientes o serdivores de VoIP, PBX, H323 Gatekeeper, etc. Escrita en
C++, se puede instalar en Linux o Windows y ofrece la posibilidad de extender
sus funcionalidades usando para ello lenguajes de programacin como PHP,
Pithon y Perl.

FreeSwitch
35
: plataforma de telefona diseada para facilitar el desarrollo de
aplicaciones de voz y chat, desde softphones hasta centralitas telefnicas. Esta
diseado para operar en varios sistemas operativos como Windows, Max OS X,
Linux, BSD y Solaris e interactuar fcilmente con las plataformas aqu
comentadas.

Callweaver
36
: tambin conocido como OpenPBX, es una plataforma para
desarrollar PBX derivada de Asterisk. Puede funcionar en un gran nmero de

33
Para obtener ms informacin podemos consultar su pgina: http://www.sipfoundry.org.
34
Para ms informacin se puede consultar su sitio web: http://yate.null.ro/pmwiki/index.php.
35
Para saber ms podemos consultar: http://www.freeswitch.org/.
36
Para profundizar ms sobre esta plataforma podemos consultar su sitio web:
http://www.callweaver.org/blog.


plataformas tales como: Linux, MacOS X/Darwin, Open/Solaris, FreeBSD,
NetBSD and OpenBSD.
4.8.2 Nivel 2: Soluciones gratuitas configurables
En este segundo nivel, tenemos soluciones que proveen servicios
personalizados aunque permiten la adicin de nuevos mdulos para tener
nuevas funcionalidades. Son ms fciles de configurar e instalar que las
soluciones del nivel uno y vienen normalmente con una interfaz grfica. Son
todas gratuitas y entre ellas destacamos las siguientes:

Trixbox
37
: solucin que implemeta un IP PBX basado en Asterisk pensado
para pequeas y medianas empresa. Se distribuye en un CD con el cual
instalamos en el sistema: Asterisk, Linux, FreePBX GUI, Apache, MySQL, y
Perl/PHP/Piton.

FreePBX
38
: es otro IP PBX basado en Asterisk y da nombre a la interfaz
grfica ms conocida para configurarlo. Est escrita en PHP y se sirve de una
base de datos MySQL.

AsteriskNow: se trata de una distribucin de Asterisk que incluye adems un
sistema operativo Linux adaptado para funcionar con l y la innterfaz
AsteriskGUI para configurarlo. Esta distribucin es compatible con FreePBX.
4.8.3 Nivel 3: Soluciones de pago llave en mano
Por ltimo, en un tercer nivel se encontraran las aplicaciones llave en mano,
las cuales proporcionan una solucin completa a usuarios finales que
simplemente las usan y que a cambio del desembolso econmico obtienen una
serie de ventajas como el soporte y mantenimitno. Aqu no encontramos con la
versin de pago de las soluciones descritas en el nivel 2. Entre ellas cabe
destacar:

TrixboxPro
39
: es la versin de pago de Trixbox y nos ofrece aplicaciones ya
configuradas que nos permite tener generacin de informacin de errores,
actualizaciones automticas, sistemas de copias de seguridad peridicas, etc.
Adems su compra incluye tambin un servicio de soporte y mantenimiento.

Asterisk Business
40
: como la anterior, es la versin de pago de AsteriskNow.
Ofrece diferentes frmulas dependiendo de la cual tendremos ms o menos
funcionalidades, tiempo de monitorizacin del sistema e incluso tiempo de
formacin para los usuarios.

37
Para ms informacin: http://www.trixbox.org.
38
Para ms informacin podemos consultar en: http://www.freepbx.org.
39
Para obtener ms informacin podemos visitar: http://www.trixbox.com/products/trixbox-pro.
40
Para ms informacin: http://www.digium.com/en/products/software/abe.php?tab=overview.


Adems de estas dos, estn soluciones de otros fabricantes con larga tradcin
en el mundo de las telecomunicaciones como Nortel, el cual ofrece el SCS
500
41
, o Aastra con su modelo AastraLink Pro 160.

41
http://www.scs500.co.uk/

I II II I. . C Ca as so o P Pr r c ct ti ic co o: : I In ns st ta al la ac ci i n n d de e u un n s si is st te em ma a d de e
t te el le ef fo on n a a V Vo oI IP P e en n u un na a e em mp pr re es sa a u ut ti il li iz za an nd do o
A As st te er ri is sk k. .

En esta ltima parte del documento, tomaremos un caso prctico en el
que una empresa, llamada EmpresaX, desea hacer una migracin hacia la
telefona IP.

A trevs de este escenario iremos descubriendo paso a paso la manera de
instalar y configurar Asterisk, proporcionando a medida que se necesiten los
conceptos tericos fundamentales.

Al terminar esta parte, habremos sido capaces de proporcionar una solucin a
los requisitos impuestos por la EmpresaX para su sistema de telefona
utilizando Asterisk.

Caso Prctico 5. Descripcin del Caso Prctico

5. Descripcin del Caso Prctico
5.1 Introduccin
En esta seccin haremos primero una descripcin del escenario actual de la
empresa, donde veremos cmo se encuentran organizadas las lneas
telefnicas. Acto seguido, enumeraremos los requisitos que la empresa pide al
nuevo sistema de telefona. Por ltimo, presentaremos, de forma general, la
solucin que se ha escogido para brindar la funcionalidad que demanda cada
requisito.
5.2 Descripcin del sistema de telefona actual
La EmpresaX encargada de realizar proyectos informticos de diversa ndole,
dispone para recibir y efectuar llamadas de seis lneas analgicas contratadas
con un operador de telefona. La empresa tiene dieciseis trabajadores que
trabajan habitualmente en la sede y cuatro trabajadores que lo hacen de
manera ocasional pues normalmente trabajan en el sitio del cliente.

Las lneas telefnicas se reparten entre los departamentos de la empresa de la
siguiente manera:

Departamento de Administracin: lo compone una persona que se
encarga de llevar los asuntos administrativos. Adems, es la persona que
atiende las llamadas cuando un cliente llama al nmero de telfono de la
empresa. Tiene una lnea de telfono a su disposicin.

Departamento Comercial: es el departamento encargado de elaborar
ofertas comerciales a los clientes. Est compuesto por tres personas que
comparten una lnea de telfono.

Departamento Tcnico: es el encargado de solucionar las incidencias
tcnicas que se producen en los sitios del cliente. Est compuesto por
tres personas que realizan tele-asistencia y tres personas que realizan
tareas de mantenimiento en el sitio del cliente. Cada uno de los tres
tcnicos que realizan labores de tele-asistencia, dispone de una lnea de
telfono dedicada.

Departamento de Desarrollo: es el departamento encargado de
elaborar las soluciones software a los clientes. Est formado por un total
de siete personas. Como en el caso anterior, todos ellos comparten una
lnea telefnica.

Departamento de Proyectos: est formado por dos personas que llevan
a cabo diversos proyectos dentro de la empresa. Actualmente no dispone
de ninguna lnea telefnica.

La figura a continuacin ilustra esta disposicin:

Figura 54. Disposicin actual del sistema telefnico de la empresa.
5.3 Requisitos de la empresa al nuevo sistema de telefona
La empresa desea que el nuevo sistema de telefona cumpla los siguientes
requisitos:
5.3.1 Requisito 1: Extensiones y buzones de voz
Se desea que todos los miembros de la empresa tengan una extensin de
telfono desde la cual realizar y recibir llamadas, y en los casos donde se
permita y sea posible, que se puedan efectuar videoconferencias.

As mismo, todos los usuarios del sistema debern tener un buzn de voz
asociado a su extensin para permitir que se pueda dejar un mensaje en l en
caso de que la persona no est disponible o est ocupada.


5.3.2 Requisito 2: Mensajera unificada
Se quiere que todos los empleados, dispongan de mensajera unificada, es
decir, que si alguien dejase un mensaje en el buzn de voz de un miembro de
la empresa, este sea automticamente enviado como un archivo adjunto en un
correo electrnico a su cuenta de correo.
5.3.3 Requisito 3: Reutilizacin de las lneas analgicas
La empresa, quiere seguir teniendo las seis lneas analgicas para poder
comunicarse con la red pblica de telfono pero adems, desea que haya un
nmero principal que agrupe a todas. ste correspondera al Departamento de
Administracin y sera el nmero principal de la empresa.
5.3.4 Requisito 4: Incorporacin de dos lneas mviles
Debido al alto coste que supone hacer llamadas a telfonos mviles desde las
lneas fijas, se quieren contratar dos lneas mviles con una tarifa especial para
llamadas a telfonos mviles.

As, cuando se realice una llamada desde dentro de la empresa, se desea que
la centralita realice dicha llamada utilizando las lneas mviles. De manera que
si llamamos a un mvil, se utilice la primera lnea, si llamamos a un segundo se
utilice la segunda y si hay una tercera, de un tono de ocupado. Es decir, que no
se permita llamar a mviles nada ms que por esas dos lneas.
5.3.5 Requisito 5: Men de bienvenida con opciones
Cuando se marque el nmero de telfono principal de la empresa, se desea
que una voz de operadora presente al usuario una sera de opciones las cuales
se ilustran en la figura a continuacin:

Figura 55. Opciones del men deseadas por la empresa.


Si el usuario elige la opcin 1, ser para introducir l mismo una
extensin de algn empleado de la empresa. Si el usuario introduce una
extensin que nos es vlida, se le presentar un mensaje de error.

Si elige la opcin 2, la llamada ser encaminada a la extensin de la
persona encargada del Departamento de Administracin.

Si elige la opcin 3, la llamada ser encaminada al Departamento
Tcnico. De todos los tcnicos que estn disponibles para atender las
llamadas, se llamar a uno cada vez para repartir la carga de trabajo.

Si elige la opcin 4, la llamada ir al Departamento Comercial haciendo
sonar todas las extensiones de los miembros que lo conforman.

Si se elige la opcin 5, la llamada se encaminar al Departamento de
Desarrollo siguiendo la misma poltica que para la opcin 4.

Si el usuario marcase una opcin que no es vlida, se le indicar y se
volver a reproducir el men de opciones.

Por ltimo, si el usuario no marca ninguna extensin al trmino de
mostrar todas las opciones, la llamada ser atendida por el
Departamento de Administracin.
5.3.6 Requisito 6: Gestin de llamadas del Departamento Tcnico
Cuando pulsando la opcin 4 se encamine la llamada al Departamento
Tcnico o un usuario llame a un nmero asociado a este departamento, se
desea que la centralita pase la llamada al primer tcnico que se encuentre
disponible.

As mismo, se pide que si todos los tcnicos estn ocupados, el usuario entre
en una cola de espera, y que sea atendido cuando un tcnico se quede libre.

Por ltimo, si hay varios tcnicos que estn libres, se quiere que se pase una
llamada a uno distinto cada vez para repartir la carga de trabajo.
5.3.7 Requisito 7: Gestin de llamadas para los Departamentos
Comercial y de Desarrollo
Se desea a su vez que cuando el usuario elija las opciones 4 o 5 del men
de opciones o cuando se realice una llamada a los nmeros de telfono
asociados a los departamentos Comercial y de Desarrollo, suenen los telfonos
de todos los miembros que pertenecen al departamento seleccionado. El
primero que descuelgue, ser el que entre en conversacin con el usuario.

5.3.8 Requisito 8: Servicios comunes de telefona
Se desea que estn disponibles tambin servicios usuales de un PBX como
son el estacionamiento, la captura y la transferencia de llamada y disponer de
la posibilidad de realizar conferencias entre ms de dos participantes.
5.4 Soluciones a los requisitos planteados
Para dar solucin a los requisitos que demanda la empresa, ser necesario
instalar una centralita telefnica para que distribuya y encamine las llamadas
como se requiera en cada momento.

A continuacin, veamos ms en detalle qu vamos a utilizar para satisfacer la
lista de requisitos enumerados en la seccin anterior.
5.4.1 Solucin al Requisito 1: Extensiones y buzones de voz
Se crearn tantos usuarios SIP como empleados tenga la empresa, definiendo
sus caractersticas y la opcin de realizar o no una videoconferencia. As
mismo se crearn para cada uno de ellos un buzn de voz.
5.4.2 Solucin al Requisito 2: Mensajera unificada
Se instalar un servidor de correo para que, utilizando el servidor de correo de
Google, se entregue los mensajes a su correcto destinatario.
5.4.3 Solucin al Requisito 3: Reutilizacin de las lneas analgicas
Se instalarn dos tarjetas de cuatro puertos analgicos (en modo FXS) a la
centralita, a los cuales se les conectarn las seis lneas fijas de que ya dispone
la empresa. Para poder utilizar los dispositivos analgicos, haremos uso de
unos adaptadores analgico/digital.
5.4.4 Solucin al Requisito 4: Incorporacin de dos lneas mviles
Para brindar acceso a la red mvil, se instalarn dos terminales fijos celulares
que irn conectados cada uno a un puerto FXO de una de las tarjetas
instaladas. Adems necesitaremos dos tarjetas SIM para tener un nmero
asociado a cada lnea.

5.4.5 Solucin al Requisito 5: Men de bienvenida con opciones
Se har uso de un IVR (Interactive Voice Response), el cual se encargar de
interactuar con el usuario y encaminar la llamada a la extensin que elija.

Para poder recibir las llamadas por la lnea principal de la empresa y
encaminarlas a las otras, ser necesario pedir al proveedor de servicios que
haga un agrupamiento de lneas. As, si un usuario llama al nmero principal y
elije comunicarse con un departamento y mientras se est produciendo la
comunicacin llama otro usuario a la lnea principal, sta no dar tono de
ocupado.
5.4.6 Solucin al Requisito 6: Gestin de llamadas del Departamento
Tcnico
Para gestionar las llamadas al Departamento Tcnico, se implementar un
sistema de distribucin automtica de llamadas con las caractersticas de
turnos rotativos de atencin de llamadas que requiere la empresa.
5.4.7 Solucin al Requisito 7: Gestin de llamadas para los
Departamentos Comercial y de Desarrollo
Se configurarn los parmetros pertienetes para que la centralita acte de la
forma deseada por la empresa cuando el departamento Comercial y el de
Desarrollo reciban una llamada, no siendo necesario implementar un sistema
de distribucin de llamadas.
5.4.8 Solucin al Requisito 8: Servicios comunes de telefona
Se configurarn los parmetros pertinentes para que la centralita telefnica
instalada brinde estos servicios.
5.5 Arquitectura del nuevo sistema de telefona
La arquitectura que planteamos para llevar a cabo todas las soluciones la
podemos ver en la siguiente figura:


Figura 56. Arquitectura del nuevo sistema telefnico de la empresa.

Como podemos apreciar, instalaremos en una mquina un centralita Asterisk
donde llegar todos las lneas telefnicas llegarn. sta a su vez, tendr una
conexin a la red LAN de la empresa donde se encuentran conectados todos
los empleados. Por ltimo, utilizaremos dos lneas que actuarn como
pasarelas hacia la red mvil.

Caso Prctico 6. Instalacin de Asterisk


6. Instalacin de Asterisk
6.1 Introduccin
En este captulo describiremos el proceso completo para instalar Asterisk en un
ordenador incluyendo la instalacin del sistema operativo y de los componentes
hardware necesarios.
6.2 Consideraciones previas a la instalacin de Asterisk
A la hora de elegir la potencia que necesitar tener el servidor Asterisk, se
deben tener en cuenta varios aspectos.

Primero, y el ms importante, es considerar el nmero de usuarios a los que
vamos a dar servicio. Atendiendo a este factor, podemos hacer una divisin en
tres grupos:

Sistemas pequeos: podemos considerar que estos sistemas tienen un
mximo de diez telfonos con el que basta utilizar un slo servidor
Asterisk.

Sistemas medianos: en estos sistemas podemos tener entre diez y
cincuenta telfonos y si hay mucha carga sobre un Asterisk puede ser
interesante utilizar dos centralitas.

Sistemas grandes: son sistemas de ms de cincuenta telfonos
utilizando varios servidores para atender a todos los usuarios.

Segundo, habra que pensar en el nmero de conversaciones simultneas que
deber soportar Asterisk, es decir, debemos estimar la actividad que tendr
nuestro sistema. Tambin influir el hecho de que parte de esas llamadas se
hagan a telfonos de la RTB ya que har falta utilizar cancelacin de eco y esto
tiene un alto coste computacional.

Por ltimo, habra que tener en cuenta el grado de heterogeneidad de nuestra
red. El hecho de que los terminales usen diferentes protocolos VoIP o
diferentes cdecs, aumenta la carga de trabajo de la CPU pues deber realizar
un proceso de traduccin.



En algunos sitios de Internet
42
, usuarios han hecho pruebas con distintas
configuraciones hardware del equipo y han expuesto sus resultados.

Tomando una de ellas, bastara con un Pentium 1 a 166Mhz con 32Mbytes de
memoria RAM para soportar cuatro llamadas simultneas utilizando el
protocolo SIP y el cdec G.711.

Nuestro sistema funcionar en un sistema de unos quince usuarios, de los
cuales la mitad no usa prcticamente el telfono, con lo que podemos
considerarlo pequeo. La red es muy homognea, utilizando slo el protocolo
SIP para las llamadas dentro de la empresa. El cdec que utilizaremos siempre
ser el G.711 que requiere muy poco procesamiento y tiene una alta calidad.

La exigencia mayor de nuestro sistema sera soportar las interfaces analgicas
(por la cancelacin de eco), pero ocho lneas es un nmero considerado bajo.

Por consiguiente, y ya que haba disponible un AMD Athlon a 2.8 GHz de
velocidad con 512 MBytes de memoria RAM, ser el que utilicemos,
considerndolo ms que suficiente para soportar el sistema telefnico de la
empresa.
6.3 Instalacin de los componentes hardware, del S.0. y de
Asterisk
Una vez elegidas las caractersticas del ordenador que albergar a Asterisk,
pasemos a la instalacin de los componentes hardware y software necesarios.
6.3.1 Instalacin de las tarjetas analgicas TDM400P
Para poder interactuar con la red de telfono pblica instalaremos en nuestro
ordenador dos tarjetas Digium TDM400P, cada una con la posibilidad de tener
hasta cuatro puertos FXO para conectar lneas de telfono convencional.

Figura 57. Tarjeta Digium TDM400P.

42
Como el del siguiente enlace, de donde estn tomados los ejemplos: http://www.voip-
info.org/tiki-index.php?page=Asterisk+dimensioning


Para su instalacin slo deberemos insertar las tarjetas en una ranura libre del
bus PCI como hacemos con una tarjeta de red o una de sonido. Hay que tener
en cuenta sin embargo que si utilizamos los puertos en modo FXS, estos deben
ser provistos de una alimentacin de 12V adicional. Nosotros utilizaremos
todos los puertos en modo FXO. En el proceso de instalacin del driver
veremos si hay algn problema en ser reconocidas por el sistema.

Figura 58. Montaje de la tarjeta TDM400P en el bus PCI.

Una vez instalada en la mquina, conectaremos a ella las lneas telefnicas de
forma que en cada puerto conectemos una lnea. Con esta operacin,
quedarn ocupados seis de los ocho puertos que se encuentran disponibles.
6.3.2 Instalacin de las interfaces con la red mvil
Para poder recibir y realizar llamadas a travs de de la red mvil, es necesario
algn dispositivo que acte como interfaz entre la red de telfono mvil y la red
IP de la empresa.

Para ello utilizaremos dos terminales fijos celulares, un Ericsson F250m y un
Celline III de Audiotel.



Figura 59. Terminal fijo celular Ericsson F250m.

Figura 60. Terminal fijo celular Audiotel Celline III.

La manera de conectarlos a los dos puertos libres de la tarjeta TDM400P es a
travs de un cable convencional de telfono. Es por tanto como si
conectsemos otras dos lneas analgicas a Asterisk. Adems de esta
conexin, estos dispositivos necesitan conectarse a la red elctrica mediante
un cable que viene incorporado.


Para dotarlos de conectividad con la red de telfonos mviles es necesario
insertarles sendas tarjetas SIM. La manera de proceder para ello depende del
modelo.

Para el modelo de Ericsson deberemos retirar la parte delantera, apartar la
antena e introducir la tarjeta. Para ilustrar este proceso podemos consultar la
Figura 61.

Figura 61. Lugar donde insertar la tarjeta SIM en el terminal fijo celular Ericsson F250m.

En el modelo de Audiotel, no tendremos que retirar ninguna tapa ya que la
tarjeta se introduce por una pequea ranura situada en el lateral del dispositivo
como apreciamos en la siguiente figura.

Figura 62. Lugar donde insertar la tarjeta SIM en el terminal fijo celular Audiotel Celline III.

Con esto, ya tenemos instalados todos los componentes fsicos en nuestra
mquina. Pasemos a continuacin a instalar el software necesario.


6.3.3 Instalacin del sistema operativo
Aunque como hemos comentado antes, Asterisk funciona con varios sistemas
operativos, es con Linux con el que tiene una mayor integracin y donde tiene
un mayor soporte ya que fue para el primero que se dise.

Entre las diferentes distribuciones de Linux del mercado, nosotros utilizaremos
Debian ya que, segn algunas encuestas publicadas en internet, es donde
resulta ms estable y adems podemos encontrar ms documentacin. Si
embargo podramos haber instalado cualquiera ya que con todas funciona
perfectamente.

Instalaremos la versin 5 de Debian por ser la versin estable ms reciente
(publicada el 14 de enero de 2009) cuando se elabor este documento.

Utilizaremos para ello un CD con una imagen ISO de tipo netinst. Estas
imgenes contienen lo mnimo para iniciar el proceso de instalacin y a partir
de ah descargarnos de internet los paquetes que nos interesen. Es por tanto
imprescindible disponer de una conexin a internet.

Al arrancar el ordenar con el CD veremos una pantalla tal como muestra la
figura a continuacin:

Figura 63. Pantalla inicial del proceso de instalacin de Debian.

En ella seleccionaremos la opcin Install. El proceso de instalacin es muy
intuitivo y no ser detallado aqu. Adems existen multitud de manuales que
podemos consultar para ello. Comentar slo que una vez elegidas las opciones
de leguaje y haber establecido los nombres de los usuarios y sus respectivas
contraseas, de la lista de programas que nos aparece para instalar, marcamos
slo: Entorno de escritorio y Sistema estndar.


Esto tomar unos minutos dependiendo de la conexin a internet de la que
dispongamos. Una vez finalizado el proceso, estaremos en condiciones de
empezar la instalacin de Asterisk.
6.3.4 Instalacin de Asterisk
Para instalar Asterisk, lo primero que tenemos que hacer, es dotar al sistema
operativo de los paquetes y libreras necesarios para poder compilarlo e
instalarlo.

A la hora de obtener e instalar estos paquetes, utilizaremos la aplicacin apt-
get, la cual se encarga de descargar el paquete que queramos instalar as
como los paquetes de los que dependa.

Para que funcione correctamente es bueno editar el fichero
/etc/apt/sources.list e incluir en l las direcciones de repositorios que creamos
ms fiables. Nosotros nos decantamos por los repositorios franceses que junto
a los alemanes son de los que gozan de ms prestigio. El fichero
/etc/apt/sources.list quedara as:

#Repositorios normales:
deb http://ftp.fr.debian.org/debian lenny main
deb-src http://ftp.fr.debian.org/debian lenny main

#Repositorios de seguridad:
deb http://security.debian.org/ lenny/updates main
deb-src http://security.debian.org/ lenny/updates main

#Repositorios de programas de frecuente actualizacin
deb http://volatile.debian.org/debian-volatile lenny/volatile main
deb-src http://volatile.debian.org/debian-volatile lenny/volatile main

Necesitamos ahora hacer que se actualicen todos los paquetes disponibles en
los repositorios. Para ello abrimos un terminal, y como root ejecutamos:

# apt-get update

Ya con la lista de paquetes actualizados, podemos pasar a instalar aquellos
que necesitamos para la compilacin e instalacin de Asterisk. Sin embargo,
antes es necesario instalar las cabeceras del ncleo. Para ello ejecutamos:

# apt-get install linux-headers-$(uname r)

Donde uname r nos devuelve la versin del ncleo de nuestro sistema.


La instalacin de los paquetes la haremos por ms comodidad en dos bloques,
primero:

# apt-get install bison openssl libssl-dev libasound2-dev
libc6-dev

Y a continuacin:

# apt-get install libnewt-dev libncurses5-dev zlib1g-dev gcc
g++ doxygen

Una vez hecho esto, pasamos a descargar Asterisk y sus libreras
43
. Las
versiones que utilizaremos sern las estables ms recientes cuando se elabor
este documento. Estas son:

Asterisk 1.4.24
DAHDI Linux 2.1.0.4
DAHDI Tools 2.1.0.2
Libpri 1.4.7
Addons 1.4.7

Pasemos a describir brevemente qu utilidad tiene cada una de ellos:

Asterisk: es el paquete que contiene la aplicacin Asterisk en s.

DAHDI Linux: contiene las libreras necesarias para la comunicacin
con la red telefnica bsica mediante interfaces analgicas.

DAHDI Tools: provee varias herramientas para ayudar a configurar la
interfaz con la red telefnica bsica.

Libpri: es una implementacin en c de los servicios PRI y BRI de ISDN.

Addons: aade diversas funcionalidades a Asterisk tales como la
posibilidad de tener un registro de las llamadas en una base de datos
MySQL, utilizar archivos MP3 para la musica en espera, aadir el
protocolo H323. Aunque nosotros no haremos uso de ellas en este
tutorial lo dejaremos instalado en el sistema por si acaso.

Cuando hayamos descargado todos, los descomprimimos en el directorio
/usr/src utilizando el comando tar como vemos a continuacin:

43
Todos los archivos estn disponibles en la pgina de Asterisk para su descarga:
http://www.asterisk.org/downloads.


# tar xvzf asterisk-1.4.24.tar.gz
# tar xvzf dahdi-linux-2.1.0.4.tar.gz
# tar xvzf dahdi-tools-2.1.0.2.tar.gz
# tar xvzf asterisk-addons-1.4.7.tar.gz
# tar xvzf libpri-1.4.7.tar.gz

Slo nos queda instalar la herramienta make de la siguiente manera:

# apt-get install make

Y ya podemos comenzar con la instalacin. Suponiendo que nos encontremos
en el directorio /usr/src, empezamos por Libpri:

# cd libpri-1.4.7
# make
# make install
# cd ..

Seguidamente instalamos los paquetes Dahdi, teniendo en cuenta que Dahdi-
linux va primero que Dahdi-tools:

# cd dahdi-linux-2.1.0.4
# make
# make install
# cd ..

# cd dahdi-tools-2.1.0.2
# ./configure
# make
# make install
# make config
# cd..

Continuamos con Asterisk, instalando tambin los archivos de configuracin de
ayuda y la documentacin con make samples y make docs respectivamente.

# cd asterisk-1.4.24
# ./configure
# make menuselect
# make
# make install
# make samples
# make docs
# cd..

Con la instruccin make menuselect tenemos la posibilidad de instalar slo
los modulos que queramos. Nosotros dejaremos todo por defecto pero nos


aseguraremos que en channels drivers se encuentra seleccionada la opcin
channel_dahdi.

Por ltimo, asterisk addons, siendo necesario instalar antes el servidor mysql:

# apt-get install mysql-server
# cd asterisk-addons-1.4.7
# ./configure
# make
# make install
# cd..

Completada la instalacin, para arrancar Asterisk solo tenemos que hacer:

# cd asterisk-1.4.24
# asterisk vvvvvc

Poniendo tantas v como informacin de depuracin queramos tener. Para
detenerlo, no tendremos ms que introducir el comando:

CLI> stop gracefully

Ahora que Asterisk ya funciona en nuestro sistema, es hora de configurarlo.

Caso Prctico 7. Configuracin de Asterisk


7. Configuracin de Asterisk
7.1 Introduccin
Para la configuracin de Asterisk es necesario editar varios ficheros de
configuracin. Todos ellos se encuentran en el directorio /etc/asterisk y tienen
extensin .conf. Al haber ejecutado la instruccin make samples en el
proceso de instalacin, el directorio se llena de archivos de ejemplo que nos
sern de gran ayuda a la hora de configurarlos.

En ellos viene generalmente una lista de parmetros de configuracin con sus
respectivas descripciones as como diversos ejemplos. De todos los archivos
disponibles, nosotros slo haremos uso de los que son necesarios para nuestro
sistema. As, hemos optado por mover todo los archivos de ejemplo a un
directorio aparte e ir aadiendo al directorio /etc/asterisk los archivos que nos
hagan falta uno a uno.

El nico archivo que dejaremos inicialmente, ser asterisk.conf. En l se
indican las rutas donde Asterisk debe ir a buscar o grabar diferentes archivos:
los de configuracin, los de audio, los de depuracin, etc. Lo incluiremos tal
cual viene en el archivo de ejemplo pues es el comportamiento por defecto. A
medida que vayamos nombrando los archivos a editar, los deberemos ir
incluyendo en el directorio /etc/asterisk.

A continuacin, describiremos el proceso de configuracin paso a paso,
explicando a medida que vayamos necesitndolos los conceptos necesarios
para llevar a cabo dicha tarea.
7.2 Cambio de los ficheros de audio del ingls al espaol
Por defecto, todos los ficheros de audio que vienen con el paquete Asterisk,
estn en ingls. Estos ficheros son reproducidos por la centralita cuando por
ejemplo se nos pide introducir una contrasea para acceder a nuestro buzn de
voz.

As, para que los usuarios disfruten de los mensajes en espaol, lo primero que
haremos ser incluir en nuestro sistema un conjunto de voces en este idioma.
Este conjunto de voces, grabadas con una voz femenina, est disponible en
internet
44
en varios formatos. Nosotros elegimos el formato a-law por ser el
que brinda una mayor calidad de sonido aunque hay que decir que el peso de
los archivos es mayor con respecto a los dems.

44
Concretamente en la direccin: http://www.voipnovatos.es/voces/


El juego completo de voces consta de dos paquetes: core-sounds y extra-
sounds.

Lo primero que haremos ser, descargarnos lo archivos en el directorio
/var/lib/asterisk/sounds/es y a continuacin descomprimirlos:

# cd /var/lib/asterisk/sounds/es
# wget http://www.voipnovatos.es/voces/voipnovatos-core-
sounds-es-alaw-1.4.tar.gz
# wget http://www.voipnovatos.es/voces/voipnovatos-extra-
sounds-es-alaw-1.4.tar.gz
# tar zxvf voipnovatos-extra-sounds-es-alaw-1.4.tar.gz
# tar zxvf voipnovatos-core-sounds-es-alaw-1.4.tar.gz

Hay que tener cuidado ya que los archivos del paquete core-sounds se
descomprimen en los directorios:

/var/lib/asterisk/sounds/es/dictate/es
/var/lib/asterisk/sounds/es/letters/es
/var/lib/asterisk/sounds/es/silence/es
/var/lib/asterisk/sounds/es/followme/es
/var/lib/asterisk/sounds/es/phonetic/es
/var/lib/asterisk/sounds/es/digits/es

Esa no es la forma correcta y Asterisk no los encontrar si lo dejamos as,
siendo necesario modificarlo. Para ello, moveremos para todos los directorios
los archivos de la siguiente manera:

# mv /var/lib/asterisk/sounds/es/dictate/es/*
/var/lib/asterisk/sounds/es/dictate
# mv /var/lib/asterisk/sounds/es/letters/es/*
/var/lib/asterisk/sounds/es/letters
# mv /var/lib/asterisk/sounds/es/silence/es/*
/var/lib/asterisk/sounds/es/silence
# mv /var/lib/asterisk/sounds/es/followme/es/*
/var/lib/asterisk/sounds/es/followme
# mv /var/lib/asterisk/sounds/es/phonetic/es/*
/var/lib/asterisk/sounds/es/phonetic
# mv /var/lib/asterisk/sounds/es/digits/es/*
/var/lib/asterisk/sounds/es/digits

Los archivos del paquete extra-sounds se descomprimen sin necesidad de
hacer ningn cambio.

Por ltimo, hay que decir que para que Asterisk vaya a buscar los archivos de
sonido al directorio es dentro de /var/lib/asterisk/sounds, debemos
asegurarnos que en el archivo asterisk.conf se encuentra la lnea sin
comentar:



languageprefix = yes

Ser as mismo necesario indicarlo en los archivos de configuracin de los
canales, generalmente mediante la opcin:

language = es

Al trmino de este proceso, Asterisk reproducir cualquiera de sus mensajes en
espaol.
7.3 Empezar a configurar el Plan de Marcacin
El plan de marcacin (dialplan en ingls) es sin duda el corazn de Asterisk.
En l se especifica qu hacer con las llamadas que llegan y a dnde dirigir las
que salen.

De forma muy general, podemos decir que ste consiste un una serie de pasos
que Asterisk debe seguir cuando llega una llamada.

Para configurar el plan de marcacin es necesario editar el archivo de
configuracin extension.conf utilizando para ello una sintaxis apropiada.

Por tanto, antes de intentar configurar el plan de marcacin de nuestro
escenario, hay que entender una serie de conceptos clave como son:

Contextos
Extensiones
Prioridades
Aplicaciones.

Pasemos a describir qu son cada uno de ellos.
7.3.1 Contextos
El plan de marcacin esta dividido en contextos (contexts en ingls), los
cuales agrupan un grupo de extensiones. Los contextos definen bloques
independientes dentro de un plan de marcacin aunque puede haber
interaccin entre ellos.

Imaginemos por ejemplo que queremos que cuando se reciban llamadas los
fines de semana, salte el buzn de voz y que cuando se reciban entre semana,
las reciba la secretara. Pues bien, esto se puede hacer empleando dos
contextos, uno para los sbados y domingos y otro para los das entre semana.



Adems, nos permite por ejemplo tener definido para un mismo nmero
diferentes comportamientos segn el contexto donde estn definidos. Si una
compaa A tiene definido un contexto a y otra compaa B tiene uno b,
cuando se marque un nmero definido en ambos, si llamamos desde la
compaa A se seguirn las instrucciones definidas en a y si llamamos desde
B se seguirn las definidas en b.

Un contexto se define escribiendo el nombre del contexto entre corchetes de la
siguiente manera:

[nombre contexto]

El nombre del contexto puede formarse con cualquier combinacin de letras
(tanto maysculas como minsculas), nmeros, guin y guin bajo.

Decir tambin que todas las instrucciones situadas a continuacin de una
definicin de contexto pertenecern a ese contexto hasta que haya una nueva
definicin de contexto.

El plan de marcacin tiene dos contextos especiales llamados general y
globals. En el primero se definen varios parmetros generales y el segundo
se utiliza para definir variables globales. Pero no nos preocupemos de estas
secciones por el momento, basta con que no nombremos ninguno de nuestros
contextos con esos nombres.

En nuestro escenario, hemos identificado los siguientes contextos:

interno: es el contexto donde estarn definidos todos los nmeros
(extensiones) de los empleados de la empresa, as como de los
diferentes servicios de telefona.

salientes-movil: ser el contexto donde estn definidas las extensiones
para hacer llamadas a telfonos mviles.

salientes-fijo: es el contexto para las llamadas a telfonos fijos.

entrantesNumeroLinea: sern los contextos donde estn definidas las
extensiones para las llamadas que vienen del exterior hacia nuestro
sistema. NumeroLinea ser el nmero de lnea de los telfonos
disponibles de la empresa. Por lo tanto, tendremos un total de ocho
contextos de este tipo. Ms adelante explicaremos el por qu de este
diseo para las llamadas entrantes.

Como hemos dicho antes, los contextos son bloques independientes. As por
ejemplo, un usuario del contexto interno no podra utilizar una extensin del
contexto salientes-movil. Es necesario por tanto algn tipo de herramienta
para comunicar contextos entre s.

Esta herramienta es el include, la cual permite incluir un contexto en otro. En
nuestro escenario tendremos lo siguiente:


[interno]
incluye => salientes-fijo
incluye => salientes-movil

[salientes-movil]
[salientes-fijo]
[entrantesNumeroLinea1]


Como podemos apreciar, el contexto interno, tiene acceso a las extensiones
definidas en los contextos salientes-fijo y salientes-movil. Con esto tambin
conseguimos que las llamadas entrantes, no tengan acceso a las llamadas
salientes previniendo de cualquier uso fraudulento de nuestras lneas.

Aunque ahora mismo la divisin en contextos de las llamadas salientes no tiene
ningn efecto, ya que cualquier persona perteneciente al contexto interno
tiene acceso a todas las extensiones salientes, en un futuro puede que se
restrinja el uso a cierto tipo de empleados.

As por ejemplo, si se quiere que los jefes tengan acceso a todo y los
empleados no puedan hacer llamadas a nmeros mviles, habramos hecho lo
siguiente:

[jefe]
incluye => empleado
include => salientes-movil

[empleado]
include => salientes-fijo

[salientes-movil]
[salientes-fijo]
[entrantesNumeroLineaN]

Con esto, el contexto jefe tiene acceso las extensiones definidas en
empleado, lo que supone que tambin tenga acceso a las extensiones de los
contextos que incluye ste (salientes-fijo), y a las definidas en salientes-movil.


7.3.2 Extensiones
La palabra extensin en el mundo de las comunicaciones hace referencia a un
nmero de telfono. En Asterisk es algo ms ya que ms bien define una serie
de pasos que hay que seguir cuando se marca un determinado nmero.

Para definir una extensin se escribe la palabra exten seguida del smbolo
=>, y a continuacin el nombre de la extensin, la prioridad y la aplicacin que
se quiere ejecutar separados entre comas. Es decir:

exten => nombre, prioridad, aplicacin

El nombre puede estar formado por una combinacin de letras, nmeros y los
caracteres * y #. El nombre es lo que el nmero en la telefona clsica
teniendo en Asterisk un significado ms amplio ya que podramos definir
extensiones formadas por letras.

Un ejemplo real de una extensin sera el siguiente:

exten => 10, 1, Answer()

Para definir una extensin, se pueden utilizar tambin unos caracteres
especiales que nos permiten definir patrones. Estos caracteres son los
siguientes:

_: para definir un patrn, el nombre de la extensin debe comenzar por el
carcter subrayado.

X: el smbolo X significa cualquier nmero entre 0 y 9.

Z: se utiliza para designar a cualquier nmero entre 1 y 9.

N: significa cualquier nmero entre 2 y 9.

[N1N2-NK]: con esto indicamos que son vlidos el nmero N1 y los
nmeros que van de N2 a NK. Por ejemplo si ponemos [13-7], esto
significara cualquier nmero entre el grupo: {1, 3, 4, 5, 6, 7}.

. (punto): un punto significa uno o ms caracteres.

!: el signo de exclamacin hace referencia a cero o ms caracteres.

Veamos a continuacin algunos ejemplos de patrones. Por ejemplo, si
queremos definir una extensin para los nmeros mviles pondramos algo as:

exten => _6XXXXXXXX, prioridad, aplicacin


Esto quiere decir que esa extensin se disparar si marcamos cualquier
nmero que empiece por 6 seguido de 8 cifras las cuales pueden ser
cualquiera entre 0 y 9.

Si sabemos que los usuarios dentro de la empresa tendrn nmeros de
extensin que van entre 2100 y 2500, pondremos:

exten => _2[1-5]00, prioridad, aplicacin

Si queremos tener una extensin para los nmeros geogrficos dentro de
Espaa, los cuales empiezan por 8 o por 9 y la segunda cifra no puede ser 0
teniendo una longitud total de 9 cifras, pondramos:

exten => _[89]ZXXXXXXX

Por ltimo, imaginemos que queremos tener una extensin para los nmeros
que empiecen por 0034 y despus tengan 1 o ms cifras. Para ello
pondramos:

exten => _0034.

Los patrones que siguen los nmeros de telfono estn regulados normalmente
por el gobierno de cada pas mediante un documento
45
. Nosotros hemos
tomado dicho documento como base para realizar la parte del plan de
marcacin referente a las llamadas salientes.
7.3.3 Prioridades
Una extensin puede tener varias instrucciones o pasos. La prioridad indica el
orden que se va a seguir Asterisk al ejecutar todos los pasos. Las instrucciones
se numeran secuencialmente empezando por 1.

En el siguiente ejemplo:

exten => 10, 2, Hangup()

Asterisk ejecutar la aplicacin Answer() y a continuacin la Hangup().

Existe la incomodidad de que si tenemos una extensin con muchos pasos y
queremos introducir uno nuevo al principio habra que volver a numerar todos

45
Para ver el plan nacional de numeracin de Espaa, podemos consultar la siguiente pgina
del ministerio de industria: http://www.mityc.es/telecomunicaciones/es-
ES/Servicios/Numeracion/PlanNacional/Paginas/PlanNacionalNumeracion.aspx


los pasos por debajo de la lnea de insercin del nuevo paso. Para evitar esto,
se utilizan las prioridades no numeradas.

En vez de utilizar una secuencia de nmeros empezando por 1, utilizamos la
letra n (que indica next). Por ejemplo:

exten => 10, 1, Aplicacin 1
exten => 10, n, Apliccin 2
exten => 10, n, Aplicacin 3

Asterisk empezar por la prioridad 1 (la cual s es necesaria ponerla), y cuando
llegue al paso 2 y se encuentre una n, sumar uno a la prioridad anterior. Esto
hace mucho ms fcil el introducir cambios en las extensiones.
7.3.4 Aplicaciones
Una aplicacin es una determinada accin que se realiza en un canal de
comunicacin. Por ejemplo, marcar una determinada extensin, hacer sonar
una msica de espera, colgar la llamada, son todas tipos de aplicaciones.

Algunas aplicaciones como Answer() o Hangup() no necesitan argumentos
para funcionar, otras sin embargo s los necesitan. La manera de pasar
argumentos a una aplicacin es hacerlo entre parntesis y separados por
comas , o por el smbolo |. Un ejemplo sera
Playback(nombre_del_archivo). Algunas de las aplicaciones ms bsicas de
Asterisk se describen a continuacin.

Answer(): si un canal est sonando, esta aplicacin nos sirve para
responder. En la telefona tradicional, es la accin de descolgar el
telfono cuando ste est sonando. Como se ha comentado antes esta
aplicacin no recibe argumentos.

Hangup(): con esta aplicacin, hacemos terminar la conversacin. En la
telefona tradicional correspondera con la accin de colgar el telfono.
Como la anterior, tampoco tiene argumentos.

Playback(): sirve para reproducir por el canal de comunicacin un
fichero de audio que se encuentra almacenado en el sistema. Recibe
como argumento el nombre del fichero que queremos reproducir sin
extensin (si el fichero es ejemplo.gsm, slo escribimos ejemplo). Si slo
ponemos el nombre, Aserisk da por hecho que se encuentra en el
directorio /var/lib/asterisk/sounds. Para indicar otro, debemos poner la
ruta del archivo en el sistema. Mientras se reproduce el fichero cualquier
pulsacin de teclas por parte del usuario es ignorada.

Wait(): nos sirve para esperar un determinado nmero de segundos, que
recibe como argumento, antes de realizar la siguiente accin. As, en el
siguiente ejemplo:


exten => 70, 1, Wait(30)
exten => 70, n, Answer()

Esperamos 30 segundos (equivalente a unos 6 tonos) antes de
contestar a la llamada.
7.3.5 Ejemplo: Utilidad para grabar sonido
A continuacin vamos a realizar un ejemplo para ilustrar los conceptos que
hemos visto hasta ahora. ste consiste en hacer una pequea utilidad que nos
servir para grabar en un fichero un mensaje de voz.

El funcionamiento sera el siguiente: cuando queramos grabar un mensaje de
audio, marcaremos una determinada extensin y al cabo de dos segundos de
espera y tras escuchar una seal, diremos el mensaje. Cuando terminemos
colgamos y el mensaje se habr grabado en el sistema.

Pero antes de ver como sera, necesitamos de algn tipo de aplicacin que nos
permita grabar audio. Dicha aplicacin es Record() la cual tiene la siguiente
estructura:

Record(filename.format[|silence][|maxduration][|option])

El nico parmetro obligatorio es el nombre del fichero con su extensin. El
cual, si no se especifica la ruta, ser almacenado por defecto en el directorio
/var/lib/asterisk/sounds de Asterisk. Si existe un fichero con el mismo nombre
se sobrescribe.

Los otros 3 atributos opcionales tienen el siguiente significado:

silence: con l indicamos el nmero de segundos de silencio permitidos
antes de parar la grabacin. Si no se indica, la deteccin de silencio est
desactivada.

maxduration: indica en segundos la duracin mxima de la grabacin.
Si no se pone nada, un 0, no hay lmite de duracin.

option: puede tener los siguientes valores: a, n, q, s, t, x
46
.

46
El significado de cada uno de ellos pueden consultarse en: Van Meggelen J, Madsen L,
Smith J, (2007), Asterisk: The Future of Telephony, (2
nd
Edition), 0Reilly, Appendix B: pp. 425 y
426.


La extensin completa sera la siguiente:

[grabar]
exten => 10, n, Wait(2)
exten => 10, n, Record(ejemplo.alaw, ,20)
exten => 10, n, Wait(2)
exten => 10, n, Hangup()

Segn esto, al llamar a la extensin 10, Asterisk responder a la llamada
(descolgar el telfono), y al cabo de dos segundos comenzar a grabar lo que
digamos, en el fichero ejemplo.gsm. Cuando hayamos terminado colgamos y
el mensaje se habr grabado en el directorio /var/lib/asterisk/sounds. Si han
pasado ms de veinte segundos, Asterisk terminar la llamada por nosotros.
7.4 Configuracin del canal Dahdi
Dahdi (Digium Asterisk Hardware Device Interface) es, a partir de la versin
1.4.22 de Asterisk, el nuevo nombre para el canal Zaptel. ste nos permite la
comunicacin con usuarios que estn en redes que utilizan tecnologas
analgicas o digitales como la RDSI o PPP.

En nuestro escenario concretamente, la configuracin de este canal nos
permitir comunicarnos con los usuarios conectados a la red pblica de
telfono mediante las seis lneas fijas, y a la red telefnica mvil mediante las
dos mviles.

Primero explicaremos como verificar la correcta instalacin de las tarjetas PCI y
acto seguido se darn las instrucciones precisas para configurar los archivos
/etc/dahdi/system.conf y /etc/asterisk/chan_dahdi.conf necesarios para el
funcionamiento del canal Dahdi.
7.4.1 Verificacin de la instalacin de las tarjetas TDM400P
Como ya tenemos instalado Dahdi en nuestro sistema, lo primero que tenemos
que hacer es hacerlo funcionar. Para ello debemos lanzar un script que cargar
los mdulos necesarios para soportar nuestra tarjeta. Para lanzarlo haremos:

# /etc/init.d/dahdi start

Para asegurarnos que los controladores de las tarjetas han sido instalados con
xito, ejecutamos:

# lsmod


El cual nos lista todos los mdulos instalados en nuestro sistema. Debemos
buscar los mdulos: wct4xxp, wcte12xp, wct1xxp, wcte11xp, wctdm24xxp,
wcfxo, wctdm, wcb4xxp, wctc4xxp y xpp_usb.

Si estn presentes, dependern del mdulo dahdi que a su vez depender del
mdulo crc_ccitt.

Estos mdulos se cargarn cada vez que se inicie el sistema. Para slo cargar
el que nos hace falta para nuestra tarjeta podemos editar el fichero
/etc/dahdi/modules comentando las lneas de los mdulos que no queramos
cargar. En nuestro caso, dejamos sin comentar slo la siguiente lnea:

wctdm

Lo que al ejecutar lsmod nos dar un resultado como el siguiente:

Figura 64. Resultado de ejecutar lsmod en el sistema.

A continuacin, utilizando la utilidad dahdi_scan, podemos ver informacin
valiosa a cerca de las tarjetas que tenemos instaladas en nuestro sistema. Para
ejecutarla hacemos:

# dahdi_scan

La salida que proporciona esta herramienta en nuestro sistema podemos verla
en la siguiente figura:



Figura 65. Resultado de ejecutar la herramienta dahdi_scan.

Podemos saber el modelo y fabricante de las tarjetas, el nmero de puertos de
cada una y el tipo de estos entre otras cosas.

Una vez que sabemos que las tarjetas son reconocidas por el sistema, vamos a
comprobar que no hay problemas con las interrupciones. Conflictos y prdidas
de interrupciones pueden afectar notablemente a la calidad del audio.

Es muy aconsejable, que las tarjetas no compartan interrupciones con otros
dispositivos. Para ver informacin acerca de qu interrupcin est usando cada
dispositivo ejecutamos:

# cat /proc/interrupts

En nuestro caso obtenemos la siguiente salida:



Figura 66. Resultado de ejecutar cat /proc/interrupts en el sistema.

En la cual vemos que los mdulos asociados a nuestras tarjetas (wctdm) estn
una en la 16 y la otra en la 19.

En el caso de que una misma interrupcin fuese usada por ms de una tarjeta,
podemos pensar en desactivar en la BIOS los controladores de los dispositivos
que no utilicemos. Para una mquina con Asterisk, quizs no necesitemos los
controladores del puerto serie, el del disquete, etc.

El paquete dahdi-tools nos ofrece una herramienta para poder realizar un test
para comprobar la calidad del enlace. Para lanzarlo hacemos:

# dahdi_test

La salida en nuestro caso ha sido la siguiente:

Figura 67. Resultado de ejecutar la herramienta dahdi_test.


Cuando paramos su ejecucin con Ctrl - c nos da informacin sobre la media
de las pruebas as como el mejor y el peor resultado. Ningn resultado debera
ser menor que 99.98%
47
.

Una vez puesto en marcha el servicio y comprobado que funciona
correctamente, pasemos a configurarlo.
7.4.2 Configuracin de los archivos system.conf y
chan_dahdi.conf
Con respecto a las versiones anteriores a la 1.4.22 de Asterisk, la configuracin
pasa de hacerse en un solo archivo zaptel.conf a hacerse en dos:
/etc/dahdi/system.conf y /etc/asterisk/chan_dahdi.conf.

En el primero de ellos, /etc/dahdi/system.conf, se configuran los datos
relativos a las interfaces fsicas entre Asterisk y el mundo exterior. Consta de
muchos parmetros ya que contempla numerosas formas o tecnologas de
conexin: analgicas, digitales, de radio, etc. Ya que todas nuestras interfaces
son puertos FXO, basta con configurar lo siguiente:

1) Sealizacin del canal: como todos los puertos de las dos tarjetas estn en
modo FXO, necesitamos sealizacin FXS para ellos. Por lo tanto incluiremos
la lnea:

fxsks=1-8

2) Zonas de carga de tonos: cada zona tiene peculiaridades en los tipos de
tonos que se utilizan y en su cadencia. Debemos poner la zona donde nos
encontramos. Para ello escribimos:

loadzone = es
defaultzone=es

2) Por ltimo y muy importante, debemos indicar el tipo de cancelador de eco
que utilizaremos en cada canal. Nosotros usaremos el mg2 en todos los
canales. Por tanto aadimos la lnea:

echocanceller=mg2,1-8

Con esto terminamos la edicin del fichero /etc/dahdi/system.conf. Pasemos
ahora a configurar el archivo: /etc/asterisk/chan_dahdi.conf.

47
Dato obtenido del libro: Goncalves F, (2007), Configuration Guide for Asterisk PBX,
Booksurge Llc, Captulo 4: pp. 91.


En este archivo, se encuentran numerosos parmetros relativos a la
configuracin del canal lgico Dahdi. As, a parte de indicar otra vez la
sealizacin que usaremos en nuestros puertos, podremos configurar aspectos
como el contexto en el que entrar la llamada, su nmero de buzn de voz, si
acepta o no transferencia de llamadas, etc.

Adems existen parmetros que nos permitirn configurar el mtodo usado
para la deteccin de colgado de un canal. En el caso de que nuestras lneas
analgicas tengan inversin de polaridad
48
, sera necesario establecer los
siguientes valores a los parmetros answeronpolarity y hanguponpolarity:

answeronpolarity = yes
hanguponpolarity = yes

Si este no es el caso, habr que utilizar los parmetros busydetec y
busycount con los siguientes valores:

busydetec = yes
busycount = 4

Donde 4 es el valor por defecto el cual habr que ajustar segn la lnea que
utilicemos.

Otros parmetros interesantes son rxgain y txgain los cuales nos permiten
aumentar o dismuniur la ganancia en el audio recibido o transmitido por
Asterisk.

Figura 68. Atributos rxgain y txgain.

Los valores por defecto para ambos son de 0.0 y podremos poner tanto
valores positivos como negativos de ganancia. Decir que el ajuste de estos dos
parmetros hay que realizarlo con cuidado pues puede producir fenmenos de
eco no deseados.

Otro aspecto que se puede configurar en este archivo es el agrupamiento de
canales. Esto consiste en agrupar un nmero de lneas para que a la hora de
de utilizarlas para una comunicacin podamos referirnos al grupo y no a una
sola lnea. As, si queremos llamar al exterior a una lnea mvil y queremos que

48
El voltaje entre los dos cables de una lnea de telfono (TIP y RING) pasa de tener un voltaje
positivo cuando la lnea est descolgada a un voltaje negativo cuando la llamada es
contestada. El ofecer o no esta caracterstica depende del proveedor de telefona.


salga por la primera lnea que est libre, deberemos llamar al grupo en vez de
hacerlo a una sola lnea.

Nuestra configuracin ser la siguiente:

answeronpolarity = yes
hanguponpolarity = yes
signalling = fxs_ks
;Lneas fijas:
group = 1
context = entrantesNumeroLinea1
channel => 1

channel => 2

channel => 3

channel => 4

channel => 5

channel => 6

;Lneas mviles:
group = 2
channel => 7

channel => 8

Hay que aclarar que lo que se define antes del primer channel, afecta a todos
los dems a no ser que se vuelvan a definir. As por ejemplo, signalling =
fxs_ks afecta a todos los canales y group = 1 slo a los seis primeros pues
redefinimos group con group = 2 lo cual afectar a los canales 7 y 8.

Como podemos apreciar, hemos hecho dos agrupaciones, una para las seis
lneas fijas y otra para las mviles llamndolas 1 y 2 respectivamente.


La agrupacin nos permitir tratar a las lneas que componen un grupo como
una sola. As cuando realicemos una llamada a travs de un grupo se escoger
la primera lnea de ste que se encuentre libre.

Para los dems parmetros dejaremos el valor por defecto.

Una vez configurado los archivos, es necesario ejecutar una aplicacin para
completar la configuracin. Esta es:

# dahdi_cfg vvv

En nuestro caso la salida ha sido la siguiente:

Figura 69. Resultado de ejecutar la herramienta dahdi_cfg vvv.

Donde apreciamos la sealizacin que tiene cada puerto/canal y el tipo de
cancelador de eco que tiene cada uno.
7.4.3 Utilizar el canal Dahdi para realizar llamadas
Aunque todava no tenemos configurado el canal SIP, con lo que no
disponemos de clientes para realizar llamadas, vamos a ver cmo haramos
para realizar llamadas a mviles desde la empresa.



Lo primero de todo, es disponer de una aplicacin que nos permita efectuar
una llamada por un canal. Dicha aplicacin es Dial(), la cual tiene el siguiente
formato:

Dial(canal/identificador, tiempo_limite, opciones)

Veamos el significado de cada uno de los parmetros de esta aplicacin tan
importante:

canal: especifica el tipo de canal que se usa para realizar la llamada.
Debe ser uno de los existentes en Asterisk. Nombre de canales vlidos
son SIP, Dahdi, IAX2, etc.

identificador: se refiere al identificador del usuario o grupo de usuarios
al que queremos llamar. Este identificador puede variar su formato
segn al canal que estemos utilizando. En Dahdi por ejemplo, siempre
ser un nmero de telfono o un identificador de grupo, mientras que en
SIP puede ser una cadena cuyo formato veremos en el captulo
siguiente.

tiempo_lmite: es el tiempo mximo que se esperar hasta que en el
canal responda alguien antes de colgar. Es opcional y si no se
especifica, se esperar indefinidamente.

opciones
49
: el comando Dial() tiene muchas opciones de las cuales
slo veremos las que nos interesan para nuestra aplicacin. Se pueden
consultar todas en.

T: permite que la persona que realiza la llamada tenga la posibilidad
de transferirla.

t: igual que la anterior pero referido a la persona que recibe la
llamada.

K: habilita a la persona que realiza la llamada a estacionar la
llamada.

k: igual que la anterior pero referido a la persona que recibe la
llamada.

Para tener como antes habamos dicho una extensin a travs de la cual
llamemos a los telfonos mviles, debemos editar el fichero extensions.conf
aadiendo lo siguiente:

El comando Dial() tiene muchas opciones las cuales se pueden consultar en: Van Meggelen
J, Madsen L, Smith J, (2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly,
Appendix B: pp. 382 - 388.


[salientes_movil]
exten => _6XXXXXXXX, 1, Dial(Dahdi/g2/Nmero)

Como podemos apreciar, utilizamos Dial() sin opciones y sin tiempo lmite. La
llamada la realizamos a travs del canal Dahdi y utilizamos el identificador g2
para referirnos la agrupacin de canales que definimos para las lneas mviles.
Nmero ser la extensin a la que queramos llamar. Ms adelante
cambiaremos esto por la expresin: ${EXTEN}, pero para ello necesitaremos
saber como utilizar variables en Asterisk.

En las dems comunicaciones con el exterior, utilizaremos las lneas fijas.
Como las hemos agrupado en el grupo 1, cada vez que queramos realizar
una llamada pondremos:

exten => nmero_extensin, 1, Dial(Dahdi/g1/Nmero)

Donde numero_extensin es cualquier extensin que queramos definir y
Nmero ya lo hemos definido antes.

Es importante sealar que cuando una llamada entra por el canal Dahdi por
una lnea, esta lo har al contexto que hayamos definido para ella y siempre
con la extensin s (del ingls start), la cual es la extensin por la que se
empieza cuando entramos en un contexto sin que tengamos informacin sobre
el identificador de llamada.

Es decir, si recibimos una llamada por el canal 1 esta entrar en el contexto
entrantesNumero1 y Asterisk buscar en ste la extensin s. Como este
comportamiento no se puede cambiar necesitamos definir una extensin s en
cada contexto entrantesNumeroN.

Una vez que la llamada est en la extensin s hemos optado por enviarla a
una extensin con el nmero de la lnea en cuestin. Este diseo nos permite
realizar diferentes acciones dependiendo de por qu lnea nos llamen. As, en
el archivo extensions.conf definiremos lo siguiente:



exten => s,1,Goto(Numero1, 1)

exten => Numero1, 1, Aplicacin

exten => s,1,Goto(Numero2, 1)

exten => Numero2, 1, Aplicacin

exten => s, 1, Goto(NumeroN,1)

exten => Numero8,1,Aplicacin

Para enviar una llamada de la extensin s a la extensin NumeroN hemos
utilizado la aplicacin Goto(), la cual nos permite saltar a una determinada
extensin, prioridad o contexto. Su formato es el siguiente:

Goto([[contexto|]extensin|]prioridad)

Donde contexto y extensin son opcionales mientras que la prioridad es
obligatorio indicarla.
7.5 Configuracin del canal SIP
Para poder recibir llamadas por el canal SIP, es necesario configurarlo. Esta
tarea se hace editando el archivo de configuracin sip.conf.

El fichero se divide en secciones las cuales empiezan con el nombre de la
seccin escrito entre corchetes:

[nombre seccin]

La primera seccin se llama general y en ella se definen las opciones
generales del canal as como las opciones por defecto de todos lo clientes
contenidos en el fichero. Esta informacin por defecto podr ser reescrita en las
secciones siguientes donde definiremos parmetros de cada cliente.

Las secciones siguientes comienzan con el nombre del cliente entre corchetes
seguido de sus opciones.


7.5.1 Parmetros generales del canal SIP
Esta seccin contiene un gran nmero de parmetros
50
, de los que usaremos
solamente unos pocos. Estos son:

port: es el puerto que Asterik utilizar para escuchar conexiones SIP
entrantes. Port toma como argumento un nmero de puerto que no est
siendo usado por otra aplicacin. El valor por defecto establecido por los
estndares es 5060.

bindaddr: es la direccin IP que Asterisk utiliza para atender (o
escuchar) conexiones SIP entrantes. El valor por defecto es 0.0.0.0, es
decir, por defecto SIP escucha en todas las interfaces de red
disponibles.

context: es el contexto por defecto para las llamadas entrantes y se
aplica cuando un cliente no tiene definido un contexto especfico.

videosupport: la opcin videosupport nos permite, o no, habilitar el
soporte de vdeo en SIP. Puede tomar los valores no o yes. Siendo el
no, el valor por defecto. Es posible deshabilitar la opcin de soporte de
vdeo pera determinados clientes pero solo puede ser activada en la
seccin general.

language: nos permite establecer el idioma por defecto para todos los
clientes. Despus es posible definir una lengua para cada uno de ellos.

allow: aqu especificamos los cdecs que queremos utilizar, y el orden
de preferencia en el caso de que haya ms de uno. Algunos de los
valores posibles son: all, alaw, ulaw, g729, gsm, etc. Si piensa
poner un valor distinto de all, lo normal es poner antes la lnea disallow
= all y a continuacin todos los allow que queramos.

Nuestro archivo sip.conf tendr el siguiente aspecto:

[general]
port=5060
bindaddr=10.1.15.175
context=interno
videosupport = yes
language=es
disallow = all
allow = all

50
Todos los parmetros y su significado pueden consultarse en: Van Meggelen J, Madsen L,
Smith J, (2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly, Appendix A: pp. 350
- 358.


7.5.2 Definicin de clientes SIP
Los clientes SIP deben ser declarados y configurados en el fichero antes de
poder realizar o recibir llamadas a travs del servidor Asterisk.

Dentro de los mltiples parmetros que se pueden configurar, vamos a
comentar slo los ms bsicos
51
. Si ms adelante es necesario incluir alguno
ms para dar soporte a alguna funcionalidad, lo incluiremos. Por ahora estos
son los que nos interesan:

type: la opcin type define la clase de conexin que tendr el cliente.
Hay tres tipos de clientes SIP:

1. peer: es un tipo de cliente que solo puede recibir llamadas.
2. user: es un tipo de cliente que solo puede hacer llamadas.
3. friend: es un tipo de cliente que es un peer y un user a la vez. Por
lo tanto puede recibir y realizar llamadas.

secret: con este parmetro establecemos la contrasea que el cliente
usar para su autentificacin.

host: establece la direccin IP o el nombre de host del cliente. Puede
tener el valor dynamic para cuando es un servidor DHCP quien asigna
las direcciones IP a los clientes.

context: es el contexto asociado al cliente.

callerid: es el identificador del cliente. El formato para este campo es,
primero el nombre entre comillas y tras dejar un espacio en blanco el
nmero del usuario entre los smbolos: <>. Un ejemplo sera: Lola
Torres <954123456>.

Para los clientes de nuestro escenario utilizaremos valores similares para todos
los campos exceptuando el nombre. Estableceremos una contrasea igual para
todos de cuatro ceros, y utilizaremos DHCP para asignar direcciones.

As para un cliente llamado Jos Garca con extensin 2400, definiremos en
el fichero sip.conf lo siguiente:

51
Smith J, (2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly, Appendix A: pp. 358
366.


[2400]
type=friend
secret=0000
host=dynamic
context=interno
callerid = Jose Garca <2400>

Los otros clientes se declararn por tanto de igual forma, cambiando solo los
valores que sean propios de cada uno.
7.6 Configuracin del Buzn de voz
El buzn de voz, servicio costoso en la telefona tradicional, es en Asterisk un
servicio estndar y fcilmente utilizable. Nos permite dejar un mensaje de voz
en caso de que la persona a la que llamamos est ocupada o no quiera atender
la llamada. Los mensajes sern almacenados en el sistema en el directorio
/var/spool/asterisk/asterisk.

El archivo dnde se configura este servicio se llama voicemail.conf. ste
contiene un amplio conjunto de parmetros que nos permiten personalizar el
servicio de mensajera a nuestro gusto.

Primero, analizaremos los parmetros ms interesantes de este archivo, para
ver despus las aplicaciones que nos permitirn utilizar el buzn de voz en el
plan de marcacin. Por ltimo veremos como instalar y configurar un servidor
de correo que reenve los mensajes dejados en un buzn de voz como archivo
adjunto de un correo electrnico.
7.6.1 El archivo voicemail.conf
El archivo contiene una seccin general, otra llamada timezone y una o
varias secciones donde se definen los contextos para grupos de usuarios, pues
al igual que en extensions.conf se permite el uso de varios contextos.

Entre los muchos parmetros que podemos configurar en la seccin general
se encuentran los siguientes
52
:

attach: con la opcin attach=yes, indicamos que queremos que
Asterisk envie el mensaje de audio como dato adjunto en un correo
electrnico. El valor por defecto es no.

52
Smith J, (2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly, Appendix D: pp. 484
- 486.


delete: si ponemos delete = yes, el mensaje ser borrado del sistema
una vez que haya sido enviado por correo electrnico.

format: nos permite especificar el formato en el que se grabar el
archivo de audio. Puede tener los siguientes valores correspondientes a
diferentes formatos: wav49, gsm, wav.

maxmessage, minmessage: el primero nos permite definir el tiempo
mximo de un mensaje de entrada en segundos. Su valor por defecto es
0 lo que significa que es ilimitado. El segundo hace referencia al tiempo
mnimo de un mensaje en segundos. Los mensajes que no lleguen a
este nmero sern eliminados.

maxlogins: indica el nmero de intentos permitidos para introducir la
contrasea del buzn de voz antes de que Asterisk termine la
comunicacin.

A continuacin, la seccin tiemezone se utiliza para definir distintas zonas
horarias ya que puede haber usuarios que no se encuentren en la misma zona.
La manera de declarar una nueva zona es la siguiente
53
:

nueva_zona=Pas/Ciudad|Opciones

Por ltimo, en la parte final del fichero, tenemos uno o varios contextos donde
se definen los buzones de voz. La forma de declarar un buzn de voz es la
siguiente:

extensin => contrasea, nombre, e-mail, email del busca, opciones

Pasemos a definir cada una de las partes:

extensin: es el nmero de extensin asignado al buzn de voz.

contrasea: es la contrasea para acceder al buzn de voz.

nombre: campo con el nombre y apellidos del usuario.

e-mail: direccin de correo electrnico para la notificacin de los
mensajes.

e-mail del busca (pager): correo electrnico para la notificacin de los
mensajes a este dispositivo.

opciones
54
: las opciones se utilizan para sobrescribir valores definidos
en la seccin general. Son de la forma atributo=valor y si hay ms de
una, estas deben ir separadas por el smbolo |.

53
Para saber cuales son todas las opciones posibles y ver algunos ejemplos, podemos
consultar: Van Meggelen J, Madsen L, Smith J, (2007), Asterisk: The Future of Telephony, (2nd
Edition), 0Reilly, Appendix D: pp. 486 y 487.


Veamos un ejemplo de definicin de un buzn de voz:

2400 => 0000, Jos Garcia,jgarcia@gmail.com,,saycid=no|attach=yes|delete=no

En l, el nmero de buzn de voz es el 2400. Tiene la contrasea 0000 y el
nombre es Jos Garca. La direccin de correo electrnico es
jgarcia@gmail.com y en este caso no hemos puesto direccin del busca. A
continuacin hemos incluido tres opciones cuyos valores sobrescribirn lo
establecido en la seccin general para ese usuario.

Por defecto los buzones de voz se definen en el contexto default y ser el que
nosotros utilizaremos.

Por ltimo es importante decir que a parte de definir el buzn de voz en el
archivo voicemail.conf, es necesario incluir el nmero de ste en la definicin
del cliente en el archivo sip.conf de la siguiente manera:

[2400]
type=friend
secret=0000
host=dynamic
context=interno
callerid = Jose Garca <2400>
voicemail = 2400

Como podemos observar, hemos incluido la lnea voicemail = 2400.
Normalmente, se suele utilizar el mismo nmero para la extensin que para el
buzn de voz y as lo haremos nosotros. Aunque se podra utilizar cualquiera.
7.6.2 El buzn de voz en el plan de marcacin
Una vez que hemos definido un buzn de voz para un usuario, vamos a hacer
que una persona que llame pueda dejar un mensaje en l. Para ello
utilizaremos la aplicacin Voicemail cuya sintaxis es la siguiente:

VoiceMail(buzn1[@contexto][&buzn2[@contexto]][&buzn3]|[opciones])

Como podemos ver, podemos indicar hasta tres buzones de voz donde ser
guardado el mensaje. El campo opciones nos permite seleccionar el mensaje
que se escuchar cuando salte el buzn de voz. Utilizando las letras s, u y b
podemos tener las siguientes seis combinaciones:

54
Para consultar todas las opciones posibles a la hora de definir un buzn de voz, podemos
consultar: Van Meggelen J, Madsen L, Smith J, (2007), Asterisk: The Future of Telephony, (2nd
Edition), 0Reilly, Appendix D: pp. 488 y 490.


Ninguna: si no indicamos nada, escucharemos un mensaje de
instrucciones a seguir para dejar un mensaje que dice as: Por favor,
deje su mensaje despus de la seal. Cuando termine pulse almohadilla
o cuelgue.

s: con esta opcin hacemos que no se escuche ningn mensaje.

u: el mensaje reproducido ser el de no disponible que dice as: La
persona en la extensin X no est disponible.

su: se reproducir el mensaje de no disponible y a continuacin el
mensaje de instrucciones.

b: el mensaje que se reproducir ser el de ocupado el cual es: La
persona en la extensin X est al telfono. Deje por favor su mensaje
despus de la seal.

bs: con esta combinacin, se reproducir el mensaje de ocupado y
despus las instrucciones.

En el siguiente ejemplo definiremos una extensin 2400, la cual si nadie
contesta en diez segundos (unos 2 tonos), saltar el contestador del buzn
nmero 30 con el mensaje de no disponible ms el de las instrucciones. Este
sera as:

exten => 2400, n, Dial(SIP/2400, 10)
exten => 2400, n, Voicemail(2400|u)

Adems de poder dejar un mensaje en un buzn de voz, debe existir la
posibilidad por parte de un usuario de consultar los mensajes guardados y
manipularlos de alguna forma, ya sea eliminndolos o movindolos a diferentes
directorios. Estas funciones y otras, nos la brinda la aplicacin
VoiceMailMain(), la cual tiene la siguiente sintaxis:

VoiceMailMain(buzn@contexto[|opciones])

Como vemos, slo debemos pasarle el nmero de buzn de voz y el contexto
donde se encuentra ste (teniendo en cuenta que si no penemos contexto, se
sobreentiende que es default). Antes de acceder a nuestro buzn, se nos
pedir la contrasea.

Entre las opciones posibles destacamos la opcin s, la cual hace que se
omita el requerimiento de la contrasea
55
.

55
Todas las opciones disponibles y su significado se encuentran en: Van Meggelen J, Madsen
L, Smith J, (2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly, Appendix B: pp.
444.


7.6.3 Configuracin del servidor de correo exim4
Vamos a configurar ahora Asterisk para que cuando un usuario deje un
mensaje en un buzn de voz, ste sea enviado como un archivo adjunto al
correo electrnico de la persona que ha sido llamada.

Para ello instalaremos junto a Asterisk un servidor de correo que
configuraremos como smarthost y utilizaremos el servidor de Gmail para
enviarlos a los destinatarios finales. Lo primero que deberemos hacer por tanto,
ser crearnos una cuenta de Gmail para utilizarla como direccin de origen.

Dentro de los posibles servidores de correo, nosotros nos hemos decantado
por exim4 debido a su fcil configuracin. Pasemos a describirla paso a paso.

En primer lugar instalamos el paquete exim4 asegurndonos antes que los
repositorios estn actualizados.

# apt-get update
# apt-get install exim4

Una vez instalado utilizaremos el siguiente comando para configurarlo:

# dpkg-reconfigure exim4-config

Al ejecutarlo se nos presentan una seria de pantallas dnde tendremos que
seleccionar alguna opcin o introducir algn dato. La secuencia de pantallas es
esta:

1. Configuracin general del correo: sealamos la opcin: el correo se
enva mediante un <<smarthost>>; se recibe a travs de SMTP o
fetchmail.

2. Nombre del sistema de correo: aqu escribimos el dominio: en nuestro
caso ser gmail.com.

3. Direcciones IP en las que recibir correo SMTP entrantes: dejamos la
direccin que aparece: 127.0.0.1.

4. Otros destinos para los que se acepta el correo: dejamos esto en blanco.

5. Mquinas para las cuales reenviar correo: lo dejamos tambin en
blanco.

6. Direccin IP o nombre del equipo para el smarthost saliente: ponemos el
fqdn (Fully Qualified Domain Name) del servidor. Para utilizar Gmail
debemos porner: smtp.gmail.com::587.

7. Desea ocultar el nombre de correo local en los mensajes salientes?:
seleccionamos la opcin No.


8. Nombre de domino visible para usuarios locales: aqu ponemos el
mismo que en la pantalla 3.

9. Limitar el nmero de consultas de DNS?: seleccionamos la opcin
No.

10. Mecanismo de entrega para el correo local: elegimos la opcin formato
mbox en /var/mail.

11. Dividir la configuracin en pequeos ficheros?: marcamos No.

Una vez hecho esto, el servidor se reinicia automticamente para que la
configuracin surta efecto.

Ahora, editamos el fichero /etc/exim4/passwd.client y aadimos las siguientes
lneas:

gmail-smtp.l.google.com:UsuarioGmail@gmail.com:ContraseaGmail
*.google.com:UsuarioGmail@gmail.com:ContraseaGmail
smtp.gmail.com:UsuarioGmail@gmail.com:ContraseaGmail

Seguidamente, introducimos la lnea port = 587 en el fichero
/etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost tal
como mostramos a continuacin:

remote_smtp_smarthost:
debug_print = "T: remote_smtp_smarthost for $local_part@$domain"
driver = smtp
hosts_try_auth = <; ${if exists{CONFDIR/passwd.client} \
{\
${lookup{$host}nwildlsearch{CONFDIR/passwd.client}{$host_address}}\
}\
{} \
}
port=587
#Aqui viene lo que sigue en el archivo

Debemos reiniciar exim4 para que los cambios surtan efecto. Ejecutamos:

/etc/init.d/exim4 restart

Con esto, y el parmetro attach con el valor yes en el fichero
voicemail.conf, los mensajes dejados en un buzn de voz se enviarn al
servidor de correo de Gmail que se encargar de entregarlos.


7.6.4 Personalizar el mensaje de correo electrnico
Por ltimo, vamos a modificar algunos parmetros para personalizar el
contenido del mensaje de los correos electrnicos. Estos parmetros sn:

servermail: es la direccin de origen que aparecer en el correo
electrnico.

fromstring: con este parmetro definimos lo que aparecer en el campo
De del correo.

pbxskip: por defecto Asterisk, inserta la cadena [PBX]: al principio del
campo asunto de un correo. Si tiene un valor igual yes forzamos a que
no ponga nada.

emailsubject: aqu definimos lo que aparecer en el campo asunto del
correo.

emailbody: aqu personalizamos el cuerpo del mensaje del correo
electrnico.

Tanto en emailsubject como en emailbody podemos utilizar ciertas variables
con las que podemos hacer referencia a cosas como la duracin total del
mensaje, en qu buzn de voz ha sido dejado, etc. Entre las variables que
podemos usar estn:

VM_DUR: con ella podemos indicar la duracin total del mensaje.

VM_MSGNUM: Asterisk enumera los mensajes que nos van dejando en
el buzn de voz desde cero. Esta variable contiene dicho nmero.

VM_MAILBOX: es el nmero de buzn de vos donde se ha guardado el
mensaje.

VM_NAME: es el nombre del usuario al que pertenece el buzn de voz
donde se ha dejado el mensaje.

VM_CIDNUM: es el nmero de extensin que ha dejado el mensaje.
Corresponde a la variable CALLERID(num).

VM_CIDNAME: es el nombre de la persona que ha dejado el mensaje.
Obtenido de la variable CALLERID(name).

VM_CALLERID: es tanto el nmero como el nmero de la perdona que
ha dejado el mensaje. Correspondera a la variable CALLERID.

VM_DATE: es la fecha y hora en la que ha sido dejado el mensaje. El
formato de de sta puede establecerse con el parmetro
emaildateformat.


Nosotros lo configuraremos de esta manera:

servermail: asterisk@empresax.com

fromstring: Centralita Asterisk

pbxskip: yes

emailsubject: Nuevo mensaje de ${VM_CIDNUM} en el buzn ${VM_MAILBOX}.

emailbody: ${VM_NAME}: \n\n\n Ha recibido un mensaje de ${VM_CIDNAME} con
extensin ${VM_CIDNUM} de ${VM_DUR} de duracin en el buzn de voz
${VM_MAILBOX}. Para escucharlo abra el archivo adjunto. \n Gracias. \n\n\t Centralita
Asterisk.

En la siguiente figura, podemos ver como sera el formato del correo enviado a
una cuenta de Gmail utilizando los valores antes comentados.

Figura 70. Correo electrnico enviado por Asterisk.

En este caso, el usuario Cliente 1 con extensin 2100 (definido en sip.conf
con el atributo callerid igual a Clliente 1 <2100>) ha dejado un mensaje en el
buzn de voz 2101.
7.7 Variables y funciones
En esta seccin describiremos cmo podemos hacer uso de variables, y
funciones en el plan de marcacin. Esto nos permitir dar al plan de marcacin
un tratamiento ms profundo, aumentado la complejidad de los servicios que
puede desempear.


7.7.1 Variables
Como en cualquier lenguaje de programacin, Asterisk permite el uso de
variables. Podemos pensar que estas son como contenedores que guardan
valores. De una variable por tanto, podemos referenciar dos cosas: su nombre
y su valor o contenido. As, para una variable llamada Cliente1 con valor
2500, podremos hacer referencia a su nombre utilizando Cliente1 o a su
contenido utilizando la sintaxis: ${Cliente1}.

En Asterisk existen tres tipos de variables: globales, de canal y de entorno.

Las primeras, como su nombre indica, son variables que pueden ser
referenciadas en cualquier parte del plan de marcacin. Se declaran en la
seccin globals o dentro de un contexto mediante la aplicacin Set en el
archivo extensions.conf. Si por ejemplo queremos declarar la variable global
Cliente1 con el valor 2500 haramos:

[globals]
Cliente1 = 2500

O tambin:

[interno]
exten => 10, 1, Set(GLOBAL(Cliente1)=2500)

Las variables de canal sin embargo, son variables que existen slo el tiempo
que dura una llamada. Existen un gran nmero de variables predefinidas de
este tipo, entre las que ms usaremos se encuentran
56
:

CALLERID(name): contiene el nombre del participante que ha iniciado la
llamada en una conversacin.

CALLERID(num): contiene la extensin del participante que ha iniciado
la llamada en una conversacin.

EXTEN: contiene la extensin actual.

Por ejemplo, para definir la extensin que nos permitir hacer llamadas a
mviles desde el contexto salientes-movil podremos:

exten => _6XXXXXXXX, 1, Dial(Dahdi/g2/${EXTEN})

56
La lista de todas las variables de canal y su significado, la podemos ver en el archivo
channelvariables.txt dentro del directorio doc de la ayuda generada por Asterrisk o en la
pgina: http://www.voip-info.org/wiki/view/Asterisk+variables#PredefinedChannelVariables.


Esto nos permitir usar un patrn, y a la hora de llamar por el canal Dahdi,
utilizaremos la variable ${EXTEN} para recuperar el nmero exacto que hemos
marcado.

Hay que decir tambin que determinadas aplicaciones tienen variables
especficas. As, la aplicacin Dial() cuenta con la variable DIALSTATUS.

sta, al ejecutarse Dial() en una extensin, puede tomar entre otros los
siguientes valores segn el estado de la persona llamada:

ANSWER: la llamada se ha establecido con xito.

BUSY: este valor indica que el llamada esta ocupado.

NOANSWER: significa que el telfono son durante un tiempo superior al
Timeout establecido para la llamada.

CANCEL: indica que aunque el telfono ha sonado varias veces, el
llamante ha colgado antes de que el llamado pudiese descolgar.

Por ltimo, las variables de entorno hacen referencia a variables de entorno de
Unix. Para acceder a ellas usamos la sintaxis: ${ENV(variable)}.

Antes de pasar a describir las funciones, es de mucha utilidad conocer una
aplicacin que nos permita ver el valor de una variable en el momento en el
que se ejecuta una extensin, sobre todo para labores de depuracin.

Esta aplicacin se llama NoOp(), y como su nombre indica no hace nada, slo
muestra por la consola (si tenemos un nivel de depuracin igual o mayor que
3), el contenido de la variable que recibe como parmetro.

En el ejemplo siguiente:

exten => 100, 1, NoOp(${CALLERID})
exten => 100, n, Dial(SIP/2500)

Al entrar en la extensin 100, se ejecuta la aplicacin NoOp(), apareciendo
en la consola el contenido de la variable CALLERID. A continuacin se
ejecutar Dial().
7.7.2 Funciones
Las funciones en Asterisk se usan en la elaboracin del plan de marcacin,
pero a diferencia de las aplicaciones, las funciones no pueden usarse de forma
independiente. Su trabajo es devolver un valor que podr ser usado por otra
funcin o por una aplicacin.

Las funciones tienen la siguiente sintaxis:


Nombre_Funcin(argumento)

Ahora bien, si lo que queremos es hacer uso del valor devuelto por una funcin
en el plan de marcacin usaremos la sintaxis:

${Nombre_Funcin(argumento)}

La lista completa de las funciones de las que dispone Asterisk la podemos ver
introduciendo lo siguiente en la lnea de comandos
57
:

CLI> show functions

Veamos algunas de las funciones que con ms frecuencia utilizaremos:

Len: la funcin Len, devuelve la longitud de la cadena que se le pasa
como argumento.

Timeout: permite obtener el tiempo lmite de un canal o establecerlo. En
este ltimo caso en colaboracin con la aplicacin Set. La funcin
Timeout, acepta un parmetro que puede tomar tres valores:

1. absolute: es el tiempo total permitido para una llamada. Por
defecto es 0, es decir, no hay tiempo lmite.

2. digit: nos permite establecer el tiempo mximo entre pulsaciones
cuando el usuario est marcando una extensin. Si entre
pulsacin y pulsacin, se sobrepasa dicho tiempo, los dgitos que
hayamos marcado hasta entonces sern interpretados como la
extensin a la que se quiere llamar. El tiempo or defecto es cinco
segundos.

3. response: si en un momento dentro de una extensin el usuario
debe marcar una extensin, y se supera el tiempo definido en
response sin marcar nada, el control pasar a la extensin t
(veremos su significado en la seccin 9.7.1).

En el siguiente ejemplo:

exten => 100, 1, Set(Color = rojo)
exten => 100, n, NoOp(${LEN(Color)})
exten => 100, n, NoOp(${LEN(${Color})})

El primer NoOp nos mostrara un valor igual a 5, mientras que el segundo nos
dara un resultado igual a 4.

57
Tambin disponemos de todas la funciones disponibles en: Van Meggelen J, Madsen L,
Smith J, (2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly, Appendix E: pp. 493
- 514.


En este otro, queremos establecer un tiempo mximo de treinta segundos para
la duracin de una llama:

exten => 200, 1, Set(Timeout(absolute) = 30)
exten => 200, n, Dial(SIP/2500)

A la hora de manipular variables, es muy interesante saber como obtener una
subcadena de la cadena almacenada en una variable. Para realizar esto,
utilizamos la siguiente sintaxis:

${string:desplazamiento:longitud}

La cual retorna una subcadena que empieza en la posicin desplazamiento y
termina en la posicin desplazamiento + longitud. Si desplazamiento es
negativo, se devuelve una subcadena de derecha a izquierda de tamao
desplazamiento y si no existe longitud, se toma la cadena que comienza el
la posicin desplazamiento hasta el final de la cadena.

Veamos unos cuantos ejemplos:

${123456789:1} : devuelve la cadena 23456789
${123456789:-4}: devuelve la cadena 6789
${123456789:0:3}: devuelve la cadena 123
${123456789:2:3}: devuelve la cadena 345
${123456789:-4:3}: devuelve la cadena 678

As por ejemplo, si queremos que para llamar a un nmero mvil se marque
primero un 0, si utilizamos ${EXTEN} tal cual, estaremos llamando a un
nmero no vlido. Para no tener en cuenta al 0, la extensin quedara as:

[salientes-mvil]
exten => _06XXXXXXXX, 1, Dial(Dahdi/g2/${EXTEN:1})
7.8 Uso de Expresiones y Macros
En este captulo veremos como podemos usar expresiones y macros en
nuestro plan de marcacin lo que nos dar la posibilidad de poder tomar
decisiones en base a mltiples criterios y a reutilizar el cdigo.
7.8.1 Expresiones
Una expresin es una combinacin de de variables, operadores y valores que
devuelven un resultado.


Las expresiones tienen la siguiente sintaxis:

$[expresin]

Si tenemos por ejemplo una variable SUMA y le queremos restar 10,
pondramos:

$[${SUMA} - 10]

Existen tres tipos de operadores para construir expresiones: los lgicos, los
matemticos y el de expresiones regulares.

El primer grupo lo forman los siguientes operadores:

Operador Y lgico: &
Operador O lgico: |
Operadores de comparaciones: =, >, >=, <, <= y !=.

El segundo est compuesto por:

Suma: +
Resta: -
Multiplicacin: *
Divisin: /
Porcentaje: %

Por ltimo, en el tercer grupo tenemos un slo operador, el de las expresiones
regulares: :.

Hay que tener cuidado pues el parser de Asterisk slo reconoce las
expresiones cuando hay un espacio entre el operador y las partes izquierda y
derecha. As, si ponemos:

exten => 100, 1, Set(PRUEBA=$[3*5])

Estaremos asignando a la variable PRUEBA, la cadena 3*5. Para que en
PRUEBA se almacene el valor 15 resultado de la multiplicacin de 3 y 5, es
necesario escribir:

exten => 100, 1, Set(PRUEBA=$[3 * 5])

Una de las aplicaciones ms tiles para evaluar el resultado de una expresin y
actuar de una u otra manera dependiendo de su resultado es la aplicacin de
salto condicional, el GotoIf(). Su sintaxis es la siguiente:

GotoIf(expresin?destino1:destino2)



Si el resultado de expresin es verdadero, la ejecucin salta a destino1, si
por el contrario es falso, ira a destino2. Ambos destinos tienen a su vez la
forma: [[contexto|]extensin|]prioridad.

Pongamos por ejemplo que tenemos una extensin (100) en la cual queremos
que si el nmero que llama es el 954101010, colguemos inmediatamente la
llamada. Si la llamada proviene de otro nmero cualquiera llamaremos a al
nmero 2500. Para hacer esto podramos hacer:

exten => 100, 1, GotoIf($[${CALLERID(num)} = 954101010]?noresp:resp)
exten => 100, n(noresp), Hangup()
exten => 100, n(resp), Dial(SIP/2500)

En la extensin 100 de ejemplo, si llama un usuario con el nmero
954101010 saltamos a la prioridad norespr y colgamos la llamada. En caso
de que sea otro nmero, llamamos al usuario con extensin 2500 del canal
SIP. Notar tambin como se utilizan las prioridades que hemos definido en la
aplicacin en conjuncin con la prioridad n.

Otra aplicacin de salto condicional, pero esta referida a condiciones de tiempo
es GotoIfTime(). Su sintaxis es:

GotoIfTime(hora, dias_de_la_semana, dias_del_mes, meses?destino)

Donde el significado de cada parmetro es:

hora: es uno o ms rangos horarios de la forma 09:00-17:00 por
ejemplo.

dias_de_la_semana: es una lista de uno o ms das de la semana. Los
valores que puede tomar son: mon, tue, wed, thu, fri, sat y sun. Para
indicar de lunes a viernes basta con poner: mon-fri.

dias_del_mes: es una lista de uno o ms das del mes, en formato
numrico.

meses: es una lista de uno o ms meses. Los valores pueden ser: jan,
feb, mar, apr, etc.

destino: como en la aplicacin GotoIf(), es de la forma
[[contexto|]extensin|]prioridad.

Con esta aplicacin seremos capaces de crear extensiones como la siguiente:

exten => 100, 1, GotoIfTime(09:00-18:00,mon-fri,*,*?abierto|20|1)
exten => 100, n, Playback(cerrado)


Cuando un usuario marca la extensin 100, la aplicacin GotoIfTime()
comprueba si es una hora entre las 9 de la maana y las 6 de la tarde, y si es
un da distinto de sbado o domingo para cualquier da del mes y para
cualquier mes. Si es as, vamos al contexto abierto, a la extensin 20 a la
prioridad 1, donde tendremos definido como tratar la llamada.

En caso contrario la ejecucin sigue al siguiente paso, donde reproducimos un
mensaje cerrado y colgamos.
7.8.2 Macros
La utilizacin de macros en el plan de marcacin nos permite reutilizar cdigo.
Imaginemos que para un usuario tenemos la siguiente extensin creada:

exten => 2100, 1, Dial(SIP/2100|20| TtKk)
exten => 2100, 1, Voicemail(2100|u)

En ella, cuando marcamos la extensin 2100, se llama al usuario SIP 2100 y
si al cabo de 20 segundos no responde, salta el buzn de voz.

Ahora imaginemos que queremos hacer lo mismo para la extensin 54000,
tendramos que copiar lo mismo. Si esto ocurre para cientos de extensiones,
est claro que podramos agrupar las partes comunes en una subrutina y que
sea utilizada o llamada por todas las extensiones. Esto es lo que conseguimos
utilizando macros.

Para definir una macro, es necesario poner el nombre de sta entre corchetes
precedido de la palabra macro:

[macro-nombre_macro]

Y a continuacin las instrucciones que la forman.

Para llamar a una macro desde el plan de marcacin es necesario utilizar la
aplicacin Macro() la cual tiene la siguiente sintaxis:

Macro(nombre_macro, argumento1, argumento2,.....,argumentoN)

Como vemos, es necesario pasarle como parmetros, el nombre de la macro y
un nmero de argumentos variables.
Dentro de una macro, tenemos acceso a unas variables especiales que son:

${MACRO_CONTEXT}: contiene el contexto original desde donde la
macro fue llamada.

${MACRO_EXTEN}: contiene la extensin original desde donde la macro
fue llamada.


${MACRO_PRIORITY}: contiene la prioridad original desde donde la
macro fue llamada.

${ARGN}: donde N va desde 1 hasta el nmero total de argumentos que
hayamos pasado a la aplicacin. Cada uno contiene un argumento.

Una vez visto esto, ya somos capaces de crear una macro. Concretamente, en
el plan de marcacin de nuestro escenario, utilizaremos una macro para todas
las extensiones de los usuarios SIP del contexto interno. Veamos como la
hemos definido:

[interno]
exten => _2[1-5]XX, 1, Macro(marcador,SIP/${EXTEN})

[macro-marcador]
exten => s, 1, Dial(${ARG1}|30|TtKk)
exten => s, n, VoiceMail(${MACRO_EXTEN}|u)
exten => s, n, Hangup()

La macro que hemos definido la hemos llamado marcador y se encarga de
llamar a la extensin que el usuario ha marcado. Vemos como en la aplicacin
Dial() hacemos uso de la variable ${ARG1} la cual contiene el valor
SIP/${EXTEN} donde ${EXTEN} claro est, se sustituira por el valor de la
extensin marcada.

Si no contesta nadie al cabo de treinta segundos, hacemos saltar el buzn de
voz. Para que el usuario deje el mensaje en el buzn de voz correcto, hacemos
uso de la variable ${MACRO_EXTEN}, la cual contiene como hemos dicho
antes, la extensin original desde la que fue llamada (no olvidemos que el
nmero de buzn de voz coincide con el nmero de extensin de un usuario).

Cuando desde otra parte del plan de marcacin necesitemos hacer lo mismo,
queramos realizar la misma funcin (llamar y si no responde nadie, que salte el
buzn de voz), slo tendremos que hacer una llamada a esta macro mediante
Macro().
7.9 Configuracin de servicios avanzados
A continuacin vamos a dotar a nuestro plan de marcacin de algunas
funcionalidades interesantes como son el men vocal, las salas de conferencia,
la posibilidad de transferir llamadas y las colas de espera.


7.9.1 Respuesta de voz interactiva
La respuesta de de voz interactiva (IVR, Interactive Voice Response), nos
permite interactuar con un usuario sin la necesidad de que su llamada sea
atendida por una persona.

Cuando un usuario llama a una extensin, se le presentan diversas acciones a
realizar mediante la reproduccin de archivos de audio previamente grabados
en el sistema. Esto no es ms que un men de opciones donde el usuario
selecciona una u otra opcin marcando los nmeros que se le han indicado
para acceder a ellas.

En nuestro escenario concretamente, queremos que cuando se reciba una
llamada por la lnea elegida por la empresa como la principal, la voz grabada
de una seorita indique las opciones ya expuestas en la seccin 5.3.5
Requisito 5: Men de bienvenida con opciones de este documento.

Pero antes de crear esta nueva extensin en nuestro plan de marcacin
veamos una serie de conceptos que nos son necesarios.
7.9.1.1 Extensiones estndares
Asterisk tiene algunos nombres de extensin para propsitos especiales los
cuales son:

i (Invalid): es la extensin que se usa cuando dentro de un contexto, se
marca una extensin que no se encuentra en el plan de marcacin o
cuando se pulsa una opcin desconocida en un IVR.

s (Start): como ya dijimos antes, es la extensin de inicio. Siendo la
extensin por la que se empieza cuando entramos en un contexto sin que
tengamos informacin sobre el identificador de llamada.

h (Hangup): es la extensin que se ejecuta cuando una llamada termina
dentro de un contexto. Por ejemplo podemos emplearla para reproducir
un mensaje de despedida cuando se termina una llamada.

t (Timeout): esta extensin se ejecuta cuando despus de haber indicado
al usuario que marque una extensin o una opcin, est no lo hace en un
tiempo inferior a Timeout. So no se establece ningn timeout mediante
Set(TIMEOUT(response)=nmero_de_segundos) el sistema esperar
por defecto quince segundos.

fax: es la extensin que se ejecutar cuando es una comunicacin de fax
la que llega al contexto.


7.9.1.2 Aplicacin Background()
La aplicacin Background() nos permite reproducir un fichero de audio pero a
diferencia de Playback(), donde la ejecucin de la extensin se para hasta que
el archivo se termine de reproducir, con Background() la ejecucin sigue
mientras de fondo se reproduce el archivo.

Esto nos permite en un IVR reproducir un archivo de audio con las diferentes
opciones del men y esperar al mismo tiempo las teclas pulsadas por el
usuario. La sintaxis de esta aplicacin es la siguiente:

Background(archivo1[&archivo2...][|opciones[|contexto]])

Donde archivo1, archivo2, etc, son los archivos de audio que queremos
reproducir
58
.

Vamos entonces sin ms dilacin a definir el IVR de nuestro escenario. Lo
primero de todo es definir la extensin en el contexto entrantesNumeroN que
har que se despliegue el men. Para ello debemos tener en cuenta qu
nmero es el principal de la empresa, y por que canal llega. Supongamos que
elegimos el canal 1 para conectar a l la lnea principal de la empresa, en
este caso pondramos:

[entrantesNumero1]
exten => s,1, Goto(menu-empresax,s,1)

Con esto, cuando alguien llama al nmero de la EmpresaX, lo redirigimos a la
prioridad 1 de la extensin s del contexto menu-empresax.

58
Los dems parmetros no los utilizaremos pero pueden ser consultados en: Van Meggelen J,
Madsen L, Smith J, (2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly, Appendix
B: pp. 375 - 376.


El contexto menu-empresax queda definido as:

[menu-empresax]
exten => s,1,Answer()
exten => s,2,Set(TIMEOUT(digit) = 5)
exten => s,3,Set(TIMEOUT(response) = 10)
exten => s,4,Background(menu_base)
exten => s,5,Wait(3)
exten => s,6,Goto(s,2)

exten => 1,1,Goto(introducir-extension,s,1)

exten => 2,1,Macro(marcador,SIP/2100)

exten => 3,1,Playback(inicioCola)
exten => 3,n,Queue(colaTecnicos|t)

exten => 4,1,Dial(SIP/Extensin1 & SIP/Extensin2 & SIP/Extensin3|30|tk)
exten => 4,n,Voicemail(Buzn1|u)

exten => 5,1,Dial(SIP/Extensin1 & SIP/Extensin2 & SIP/Extensin3|30|tk)
exten => 5,n,Voicemail(Buzn1&Buzn2|u)

exten => i,1,Playback(entrada_no_valida)
exten => i,2,Goto(s,1)
exten => t,1,Macro(marcador,SIP/2104)

Lo primero que hacemos cuando una llamada llega a este contexto, es
contestarla con la aplicacin Answer(). A continuacin establecemos los
valores de Timeout para digit y response, reproduciendo a continuacin el
archivo de audio donde se presentan las diferentes opciones que tendr el
usuario.

Este archivo tendr el siguiente contenido:

Bienvenidos al men de EmpresaX. Pulse uno para marcar una extensin,
pulse dos para hablar con el departamento de administracin, pulse tres para
hablar con el departamento tcnico, pulse cuatro para hablar con el
departamento comercial o pulse cinco para hablar con el departamento de
desarrollo.

Si durante la reproduccin de este archivo, pulsamos una las cinco posibles
opciones, Asterisk ejecutar la extensin asociada a dicha opcin. Por lo tanto,


si pulsamos 1, saltaremos mediante la aplicacin Goto() al contexto
introducir-extension.

Si pulsamos 2, llamaremos a la nica extensin que compone el Departamento
de Administracin, que hemos elegido como la 2100.

Si elegimos la opcin 3, ejecutaremos la aplicacin Queue() que veremos en
la seccin: 7.9.2 Distribucin automtica de llamadas. Por ahora nos basta con
saber que las llamadas sern enviadas a una especie de colas, donde
miembros registrados en cada una de ellas (que sern los miembros de cada
departamento) atendern las llamadas. Antes reproducimos el mensaje
inicioCola el cual dice: Su llamada ser atendida lo antes posible.

Para las opciones 4 y 5, llamaremos a varias extensiones a la vez (las elegidas
por la empresa) utilizando el comando Dial() con el siguiente formato:

Dial(SIP/Extensin1 & SIP/Extensin2 &.& SIP/ExtensinN|30|tk)

A continuacin, si nadie respondiese al cabo de 30 segundos, saltara el buzn
de voz de las personas seleccionadas por la empresa:

Voicemail(Buzn 1&Buzn2 &|u)

Si pulsamos una opcin distinta de 1 a 5, la ejecucin ir a la extensin i
donde reproduciremos mediante Playback() el mensaje No existe tal opcin.
Por favor introduzca una opcin vlida. A continuacin mediante Goto()
volvemos a la prioridad 2 y ejecutamos todo de nuevo.

Si el tiempo mximo se ha agotado, y no se ha introducido ninguna opcin, la
llamada, la ejecucin ir a la extensin t, donde pasaremos la llamada al
Departamento de Administracin.

Decir, que si un usuario llama por una lnea diferente a la principal, se
realizarn dos tipos de acciones:

1. Si la lnea corresponde al departamento tcnico, se ejecutar la misma
aplicacin que al pulsar la opcin 3 del men, es decir, Queue().

[entrantesNumeroN]
exten => s,1,Goto(NumeroN, 1)

exten => NumeroN, 1, Answer()
exten => NumeroN,n,Playback(inicioCola)
exten => NumeroN,n,Queue(colaTecnicos|t)



2. Si la lnea no pertenece a este departamento, se llamar a varias
extensiones a la vez y si no contestase nadie al cabo de treinta
segundos, saltara el buzn de voz.

[entrantesNumeroN]
exten => s,1,Goto(NumeroN, 1)

exten => NumeroN, 1, Answer()
exten => NumeroN,n,Dial(SIP/Extensin1 & SIP/Extensin2 & SIP/Extensin3|30|tk)
exten => NumeroN,n,Voicemail(Buzn1&Buzn2|u)

Veamos a continuacin la definicin del contexto introducir-extension:

[introducir-extension]
exten => s, 1, Read(NUMERO|introducir_extension|4)
exten => s, n, GotoIf($[(${NUMERO} >= 2100) & (${NUMERO} <=
2500)]?dentrorango)

exten => s, n, Set(TIMEOUT(digit) = 5)
exten => s, n, Set(TIMEOUT(response) = 10)
exten => s, n(menu), Background(menu_extension)
exten => s, n, Wait(2)
exten => s, n, Goto(s,menu)
exten => s, n(dentrorango), Dial(SIP/${NUMERO}|20|tk)
exten => s, n, Voicemail(${NUMERO}|u)
exten => s, n, Hangup()

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

exten => 2, 1, Goto(menu-aristec, s, 1)

exten => i,1,Playback(entrada_no_valida)
exten => i,2,Goto(s,menu)
exten => t,1,Macro(marcador,SIP/2104)

Recordemos que en este contexto entramos despus de haber pulsado 1 para
introducir una extensin que se supone que el usuario conoce para llamar
directamente a un empleado.

Lo primero que hacemos es leer la extensin con la aplicacin Read(), la cual
reproduce el mensaje Introduzca la extensin. quedando a la espera de que
el usuario introduzca el nmero. ste es guardado en la variable NUMERO y


con el valor 4 que le pasamos como parmetro limitamos que el nmero
tenga como mximo cuatro cifras.

Como las extensiones de los empleados de la EmpresaX van de 2100 a 2500,
a continuacin hacemos una comprobacin de que el nmero ledo se
encuentre en dicho rango. Si no es as, desplegamos un pequeo men en el
que damos las siguientes opciones: Para volver a marcar la extensin pulse 1.
Pulse 2 para volver al men principal..

Si pulsamos 1, vamos de nuevo al principio de la extensin se nos volver a
pedir que introduzcamos la estensin. Si elegimos la opcin 2, iremos al men
principal menu-empresax. Como antes, si el usuario no ha marcado nada, se
vueve a repetir el men y si pulsa una opcin distinta de 1 o 2 tambin. Si el
tiempo se cumple, la llamada ser atendida por el Departamento Comercial.

Si la extensin es correcta, la llamaremos utilizando la aplicacin Dial().
7.9.2 Distribucin automtica de llamadas
En una distribucin automtica de llamadas, las llamadas son conducidas a
una fila o cola de atencin donde agentes o miembros registrados van
atendiendo las llamadas en orden de llegada. Para ilustrar esta idea veamos la
siguiente figura:

Figura 71. Funcionamiento de una distribucin automtica de llamadas.

Si todos los agentes estn ocupados, la llamada permanecer en espera hasta
que el primer agente se quede libre.

En nuestro escenario, configuraremos la distribucin automtica de llamadas
para que cuando un usuario llame al departamento Tcnico en el men
principal, la llamada pase a una fila de atencin de llamadas.



La configuracin de este servicio se hace editando el archivo de configuracin
queues.conf. ste est dividido en una primera seccin general donde se
configuran parmetros generales y a continuacin las secciones donde se
definen las diferentes colas de espera, las cuales empiezan por su nombre
entre corchetes.

Algunos de los parmetros que podemos establecer para cada cola de espera
son los siguientes
59
:

musicclass: es el tipo de msica que escuchar un usuario mientras
espera a ser atendido por un agente.

strategy: es la estrategia que se siguir para llevar a una llamada a ser
atendida por un agente. Las estrategias pueden ser una de las
siguientes:

1. ringall: hace sonar todos los canales que estn libres a la vez
hasta que uno contesta.

2. roundrobin: las llamadas se pasan a los agentes de forma
rotativa empezando siempre por el mismo.

3. leastrecent: con esta opcin, se pasa la llamada al agente que
hace ms tiempo que recibi una llamada.

4. fewestcalls: la llamada se pasa al agente que ha contestado a
menos llamadas.

5. random: la llamada se pasar a un agente elegido
aleatoriamente.

6. rrmemory: emplea la estrategia roundrobin pero recuerda que
agente contesto la ltima llamada.

weight: sirve para establecer el peso de una fila de espera. Si un agente
atiende a ms de una fila, cuando se quede libre atender primero las
llamadas de la cola de mayor peso.

wrapuptime: con esta opcin especificamos el tiempo que transcurre
desde que un agente termina una llamada hasta que se le enva otra. El
valor por defecto es 0, lo que significa que se hace de forma inmediata.

maxlen: aqu definimos el nmero mximo de usuarios que pueden
estar esperando en una lista de espera. Por defecto tiene el valor 0
que significa ilimitados.

59
Para consultar todos los posibles parmetros tanto generales como especficas de cada cola,
podemos consultar: Van Meggelen J, Madsen L, Smith J, (2007), Asterisk: The Future of
Telephony, (2nd Edition), 0Reilly, Appendix D: pp. 478 - 481.


Para ver todos los posibles parmetros recomendamos ver el archivo de
configuracin de ejemplo queues.conf.

Despus de definir estos parmetros, definimos los miembros que formarn
parte de una cola utilizando la siguiente sintxis:

member => Canal/Extensin

Los miembros aqu definidos, se cargan cuando se arranca Asterisk y siempre
estn activos para recibir llamadas. Otra posibilidad, es cargar miembros de
manera dinmica, es decir, no definiendo ningn miembro en la cola y
permitiendo el registro de miembros sobre la marcha.

Para ello disponemos de las siguientes aplicaciones: AddQueueMember(),
RemoveQueueMember(), PauseQueueMember() y UnpauseQueueMember().
Veamos la sintaxis de cada una y su modo de operacin.

AddQueueMember(nom_cola[|interfaz[|costo[|opciones[|nom_miembro]]]])

Aade dinmicamente un miembro a una cola existente. Entre todos los
parmetros que acepta la aplicacin, nosotros slo utilizaremos nom_cola e
interfaz
60
.

La aplicacin modifica el valor de la variable ${AQMSTATUS} segn el
resultado de su ejecucin, pudiedo tomar los valores:

ADDED: el agente ha sido aadido con xito.
MEMBERALREADY: significa que el agente ya se encontraba como
miembro de la cola.
NOSUCHQUEUE: indica que la cola a la que estamos intentanto aadir
un agente, no existe.

RemoveQueueMember(nombre_cola[|interfaz])

Elimina un miembro de una cola existente. El significado de sus dos
parmetros es el mismo que para la aplicacin anterior. Al ejecutarse modifica
la variable ${RQMSTATUS} la cual puede tener los siguientes valores:

REMOVED: este valor significa que el agente ha sido borrado con xito
de la cola.
NOTINQUEUE: indica que el agente no estaba registrado en la cola, por
lo tanto no se ha podido borrar.
NOSUCHQUEUE: tiene el mismo significado que en la aplicacin
anterior.

60
El resto de parmetros pueden ser consultados en: Van Meggelen J, Madsen L, Smith J,
(2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly, Appendix B: pp. 367 - 368.


PauseQueueMember([nombre_cola]|interfaz[|opciones])

Pone en estado de pausa a un miembro dentro de una cola, de manera que no
reciba llamadas. Como en la primera, slo utilizaremos los dos primeros
argumentos
61
. Esta aplicacin modifica la variable ${PQMSTATUS} que
puede tener los valores:

PAUSED: el agente se ha pausado con xito.
NOTFOUND: indica que el agente no se ha encontrado por que nos
estaba registrado.

UnpauseQueueMember([nombre_cola]|interfaz[|opciones])

Por ltimo, esta aplicacin hace pasar a un miembro del estado pausado a
disponible para recibir llamadas
62
. La variable que se modifica al ejecutarse es
${UPQMSTATUS} la cual puede tomar los valores:

UNPAUSED: la operacin de volver al agente a un estado activo ha
terminado con xito.
NOTFOUND: indica que el agente no se ha encontrado por que nos
estaba registrado.

Una vez vistas las aplicaciones que nos servirn para manejar el estado de los
agentes de forma dinmica, podemos pasar a editar los archivos de
configuracin.

Para nuestro escenario, hemos pensado que los agentes del Departamento
Tcnico, deben tener la posibilidad de registrarse y borrarse dinmicamante por
su forma de trabajo.

Definiremos para ellos las una cola que llamaremos colaTecnicos. La
estrategia de atencin de una llamada ser roundrobin con memoria. Para
registrarse y salir de esta cola ser necesario introducir una contrasea
establecida por el administrador.

61
El resto los podemos consultar en: Van Meggelen J, Madsen L, Smith J, (2007), Asterisk:
The Future of Telephony, (2nd Edition), 0Reilly, Appendix B: pp. 418.
62
El significado de sus parmetros podemos verlo en: Van Meggelen J, Madsen L, Smith J,
(2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly, Appendix B: pp. 441 y 442.


La configuracin del fichero queues.conf quedara as:

[general]
persistentmebers = yes
autofill = yes

[colaTecnicos]
musicclass = default
strategy = rrmemory
wrapuptime = 5
maxlen = 0

Usando para los dems parmetros su comportamiento por defecto.

Para acceder a las colas desde el plan de marcacin, es necesario utilizar la
aplicacin Queue() la cual tiene la siguiente sintaxis:

Queue(nom_cola[|opciones][|URL][|sobreescribiranuncio][|timeout][|AGI])

Donde nosotros slo utilizaremos los siguientes parmetros
63
:

nombre_cola: es el nombre de la cola.

opciones: es una lista de caracteres indicando cada uno una opcin.
Nosotros slo utilizaremos la opcin t, lo que nos permitir transferir la
llamada a otra extensin.
El fragmento del plan de marcacin donde utilizamos esta aplicacin, lo hemos
mostrado ya en la seccin 7.9.1 Respuesta de voz interactiva, as que
pasaremos directamente a presentar la parte con la que gestionamos los
registros dinmicos de los agentes en la cola de tcnicos.

Hemos definido las siguientes extensiones:

1400: llamando a esta extensin, nos podremos registrar en
colaTcnicos.

1401: en esta extensin podremos salir de la cola.

1402: marcando 1402, podremos hacer una pausa y no recibir
llamadas.

1403: esta extensin nos permite volver a poder recibir llamadas.

63
El significado de todos los parmetros los podemos consultar en: Van Meggelen J, Madsen
L, Smith J, (2007), Asterisk: The Future of Telephony, (2nd Edition), 0Reilly, Appendix B: pp.
421 y 422.


La primera de ellas quedara as:

exten => 1400, n, Authenticate(1234)
exten => 1400, n, AddQueueMember(colaTecnicos|SIP/${CALLERID(num)})
exten => 1400, n, GotoIf($[${AQMSTATUS} = ADDED]?exito)
exten => 1400, n, GotoIf($[${AQMSTATUS} = MEMBERALREADY]?yalogueado)
exten => 1400, n, Playback(problema)
exten => 1400, n(exito),Playback(miembroLogueadoExito)
exten => 1400, n(yalogueado),Playback(miembroYaLogueado)

Al llamar a esta extensin, una voz grabada nos invitar a introducir una
contrasea (que como vemos deber ser 1234). Si la introducimos
correctamente pasaremos a ejecutar la aplicacin AddQueueMember()
registrando nuestro usuario en la cola.

Para hacer ms interactivo el proceso, nos preguntamos por el valor de la
variable AQMSTATUS para reproducir los mensajes: Se ha registrado con
xito. si tiene un valor ADDED y Ya se encontraba registrado., si su valor es
MEMBERALREADY.

La extensin para salir de la cola, la hemos definido como sigue:

exten => 1401, n, Authenticate(1234)
exten => 1401, n, RemoveQueueMember(colaTecnicos|SIP/${CALLERID(num)})
exten => 1401, n, GotoIf($[${RQMSTATUS} = REMOVED]?exito)
exten => 1401, n, GotoIf($[${RQMSTATUS} = NOTINQUEUE]?nologueado)
exten => 1401, n(exito),Playback(miembroDeslogueadoExito)
exten => 1401, n(nologueado),Playback(noLogueado)

Como podemos apreciar, es muy parecida a la anterior. Si la variable
RQMSTATUS tiene un valor REMOVED, reproduciremos el mensaje: Ha
salido con xito.. Si el valor es NOTINQUEUE, el mensaje ser No se
encuentra registrado. Debe registrarse para realizar esta accin.



En las extensiones 1402 y 1403 tendremos la posibilidad de pausar y no
recibir llamadas, y de volver a estar en estado activo respectivamente. A
continuacin pondremos slo la primera ya que la segunda es muy similar.

exten => 1402, n, PauseQueueMember(colaTecnicos|SIP/${CALLERID(num)})
exten => 1402, n, GotoIf($[${PQMSTATUS} = PAUSED]?exito)
exten => 1402, n, GotoIf($[${PQMSTATUS} = NOTFOUND]?nologueado)
exten => 1402, n(exito),Playback(miembroPausado)
exten => 1402, n(nologueado),Playback(noLogueado)

Como podemos notar, en esta extensin no hace falta que nos introduzcamos
una contrasea. Si la variable PQMSTATUS tiene un valor igual a PAUSED
reproduciremos el mensaje: Agente pausado con xito. Si por el contrario el
valor es NOTFOUND el mensaje ser: No se encuentra registrado. Debe
registrarse para realizar esta accin.

Para la extensin 1403, slo cambiaremos la aplicacin
PauseQueueMember() por la aplicacin UnpauseQueueMember() y la
variable que consultaremos ser UPQMSTATUS. Si esta tiene el valor
UNPAUSED reproduciremos: Ya puede volver a recibir llamadas.
7.9.3 Salas de conferencia
Con las salas de conferencia, podemos hacer que ms de dos usuarios
interacten en una misma conferencia.

Figura 72. Representacin de una sala de conferencia con tres usuarios.


En Asterisk es muy fcil definir una sala de conferencia, y aunque algunos
telfonos ofrecen sus propios mecanismos para crearlas, nosotros
expondremos aqu el mtodo estndar de Asterisk. Para ello necesitaremos
usar la aplicacin MeetMe(). Esta tiene la siguiente sintaxis:

MeetMe([nmero_conferencia][|[opciones][|contrasea]])

Como vemos todos sus parmetros son opcionales, utilizando uno u otro
dependiendo del tipo de sala de conferencia que queramos crear. El
nmero_de_conferencia hace referencia al nmero identificador de la
conferencia y la contrasea es la contrasea (si definida) para acceder a ella.
Las opciones son muchas y nosotros nada ms que sealaremos aqu algunas
de ellas
64
.

c: esta opcin hace que antes de entrar en una sala conferencia, se nos
anuncie cuantos usuarios se encuentran ya en ella.

D: con esta opcin la conferencia ser creada dinmicamente,
estableciendo previamente su contrasea. La opcin d (minscula)
hace lo mismo pero no es necesario establecer una contrasea para la
sala.

M: con ella habilitamos la msica en espera cuando slo hay un
participante en la conferencia.

s: esta opcin permite que si durante una conferencia pulsamos la tecla
*, se nos presente un men con distintas opciones segn seamos un
usuario cualquiera o el administrador de la conferencia.

Para las salas de conferencia que no son creadas dinmicamente, es
necesario declararlas en el archivo meetme.conf. Este archivo slo presenta
una seccin general con un slo parmetro audiobuffers que dejaremos por
defecto.

En la siguiente seccin llamada rooms es donde declaramos las salas de
conferencia de la siguiente forma:

conf => nm_conf[[,contrasea_usuario][,contrasea_administrador]]

El nm_conf es como antes, el nmero identificador de la sala. A continuacin
tenemos la opcin de establecer las contraseas de usuario y administrador.

Para nuestro escenario de la EmpresaX crearemos tres tipos de salas de
conferencia, pblicas (sin necesidad de contrasea), privadas estticas y
privadas dinmicas.

64
Para consultarlas todas, podemos ver: Van Meggelen J, Madsen L, Smith J, (2007), Asterisk:
The Future of Telephony, (2nd Edition), 0Reilly, Appendix B: pp. 407 - 408.


Empezamos por declarar en el archivo meetme.conf en la seccin rooms las
salas de conferencia estticas. Crearemos 10 de cada tipo:

conf => 1100
conf => 1102

conf => 1109

conf => 1150,0000,1111
conf => 1151,0000,1111

conf => 1159,0000,1111

Las primeras diez no tienen contraseas, mientras que las segundas diez,
tienen como contrasea de usuario la 0000 y como contrasea de
administrador la 1111.

Ahora en el plan de marcacin debemos hacer accesible las salas ya creadas.
Para ello creamos las siguientes extensiones:

exten => _110X, 1, MeetMe(${EXTEN:3}|cMs)
exten => _115X, 1, MeetMe(1${EXTEN:3}|cMs)
exten => 1200, 1, MeetMe(|cDMs)

Como resultado tendremos que, al marcar una extensin entre 1100 y 1109,
accederemos a una sala de conferencia sin la necesidad de introducir ninguna
contrasea. Con la opcin c se nos comunicar justo antes de acceder el
nmero de participantes que hay actualmente en la sala, con M
escucharemos una msica en espera si somos el nico participante y con s
tendremos la opcin de ir al men antes comentado.

Marcando una extensin en el rango 1150 - 1159, seremos invitados primero a
introducir la contrasea de la sala. Podremos acceder a la sala como un
usuario normal introduciendo 0000 o como administrador introduciendo en
este caso 1111. Las caractersticas de la sala son iguales que la anterior al
tener las mismas opciones.

Por ltimo, en la extensin 1200 hemos definido la sala de conferencia
dinmica. Al marcar este nmero deberemos introducir el nmero de la sala
que queramos crear y a continuacin su contrasea. Una vez hecho esto,
accederemos a la sala que acabamos de crear, siendo el creador el usuario
administrador. Si otro usuario marca 1200 e introduce el mismo nmero de
conferencia y la contrasea antes definida, acceder a la sala.



7.9.4 Estacionamiento, captura y transferencia de llamadas
En esta seccin vamos a configurar tres servicios de telefona como son el
estacionamiento, la captura y la transferencia de llamadas. Como ocurra en las
salas de conferencia, los telfonos pueden estar configurados para ofrecer
algunos de estos servicios. Nosotros describiremos la forma de configurarlos
en Asterisk.

Para proveer de estos servicios slo necesitaremos editar el archivo de
configuracin features.conf
65
.
7.9.4.1 Estacionamiento de llamadas
Comencemos por el estacionamiento de llamadas. ste nos permite poner en
espera a un usuario marcando una extensin durante una llamada, colgar e ir a
otro telfono y marcando la extensin que se nos ha indicado recuperar la
llamada.

Para su configuracin, debemos ir a la seccin general del fichero y editar
algunas opciones. Estas son:

parkext: es la extensin que debemos marcar para estacionar una
llamada.
parkpos: es el rango de extensiones donde sern estacionadas las
llamadas.
context: es el contexto de las llamadas estacionadas. Deberemos incluir
este contexto en el archivo extensions.conf para hacer accesible estas
extensiones.

Utilizando los valores que vienen por defecto, la configuracin en el archivo
features.conf sera la siguiente:

parkext: 700
parkpos:701-720
context: parkedcalls

Y en el archivo extensions.conf debemos incluir en el contexto parkedcalls:

include => parkedcalls

65
Todos los parmetros de este archivo pueden ser consultados en el archivo de ejemplo
features.txt o en: Van Meggelen J, Madsen L, Smith J, (2007), Asterisk: The Future of
Telephony, (2nd Edition), 0Reilly, Appendix D: pp. 471.


Con esto, cuando estemos realizando un llamada podemos marcar # para
iniciar una transferencia y a continuacin marcamos la extensin 700. En la
figura a continuacin, es Usuario 1 el que inicia la llamada y Usuario 2 quien
la aparca:

Figura 73. El Usuario 2 aparca la llamada pulsando #700.

El usuario 1 se quedar a la espera y el usuario 2 escuchar una voz que nos
dir el nmero donde ha sido estacionada la llamada, por ejemplo el 701.
Solo tendremos que marcar dicha extensin en nuestro telfono o en otro
cualquiera y retomaremos la llamada. En la siguiene figura es el mismo usuario
2 quien se mueve y desde otro terminal, retoma la llamada:

Usuario 1
Usuario 2
701

Figura 74. El usuario 2 recupera la llamada aparcada marcando el nmero que la centralita le
ha indicado, es este caso 701.

Decir, que en la seccin general hay otros parmetros que podemos configurar,
entre los cuales destacamos parkingtime, el cual nos permite establecer el
tiempo que un usuario puede permanecer en espera. Una vez transcurrido ese
tiempo el telfono donde iniciamos la transferencia vuelve a sonar.
7.9.4.2 Captura de llamadas
Pasemos ahora a configurar la captura de llamadas. El parmetro que nos sirve
para indicar la extensin de este servicio es pickupexten en la seccin
general. Nosotros le daremos el valor por defecto que es:

pickexten = *8



As, si un telfono esta sonando, podremos capturar la llamada desde el
nuestro marcando la extensin *8. Tomando como ejemplo el escenario de la
Figura 75, el usuario 1 llama a una extensin donde no hay nadie.

Figura 75. Usuario 1 intenta llamar a un telfono donde no hay nadie.

A continuacin, como apreciamos en la Figura 76, el usuario 2 decide
interceptar la lamada marcando *8 establecindose en ese momento
comunicacin entre l y usuario 1.

Figura 76. Usuario 2 marca *8 capturando la llamada y establece comunicacin con Usuario
1.
Ahora bien, no podemos hacer esto sobre cualquier telfono. Es necesario
definir los grupos sobre los que tenemos el derecho de capturar sus llamadas.
Para ello, en el archivo sip.conf debemos aadir los parmetros callgroup y
pickupgroup en la seccin de cada cliente donde queramos configurar este
servicio. El significado de los dos parmetros es el siguiente:

callgroup: define a qu grupos pertenece el cliente.

pickupgroup: define sobre qu grupos podemos capturar llamadas.



Si por ejemplo tenemos dos clientes configurados de la siguiente manera:

[Cliente1]
callgroup = 1
pickupgroup = 1, 2

[Cliente2]
callgroup = 2
pickupgroup = 2

El cliente Cliente1 pertenece al grupo 1 y puede capturar las llamadas de los
clientes que pertenezcan a los grupos 1 y 2. Por lo tanto puede capturar las
llamadas de Cliente2. Cliente2 pertenece al grupo 2 y puede capturar las
llamadas de los clientes que pertenezcan a su mismo grupo. Por lo que no
podr capturar las llamadas de Cliente2.

En nuestro escenario, configuraremos los grupos de capturas de llamadas
atendiendo a qu departamento pertenecen. As, cada miembro de un
departamento slo podr capturar la llamada de otro miembro del mismo
departamento. Esto ser as excepto para los miembros que pertenezcan al
departamento comercial, los cuales podrn capturar las llamadas de cualquier
empleado.
7.9.4.3 Transferencia de llamadas
Por ltimo vamos a configurar la transferencia de llamadas. Las extensiones de
este servicio se definen en la seccin featuremap con los parmetros
blindxfer para la transferencia a ciegas y atxfer para la transferencia
atendida. Los valores que hemos elegido para este servicio son los siguientes:

blindxfer = #1
atxfer = *2

Con esta configuracin, si durante una llamda marcamos #1, pondremos al
cliente en espera. Tomando el escenario de la Figura 77, usuario 2 inicia una
transferencia lo cual pone a usuario 1 en espera. El usuario 2 escuchar una
voz diciendo transferencia. A continuacin el usuario 2 marca la extensin a la
que quiere transferir la llamada (en el ejemplo la 2100) y cuelga.



Usuario 1 Usuario 2
#1; 2100
Usuario 3
Ext: 2100

Figura 77. Usuario 2 realiza una transferencia ciega hacia el Usuario 3 con etensin 2100.

Dicha extensin se pondr a sonar y si el usuario 3 descuelga el usuario 1 deja
el estado de espera y se retoma la comunicacin. En la siguente figura
podemos ver dicha situacin:

Usuario 1 Usuario 2
Usuario 3
Ext: 2100

Figura 78. La extensin 2100 comienza a sonar, si el Usuario 3 descolgase se establecera
comunicacin con Usuario 1.

En la transferencia atendida, si marcamos *2 durante una llamada, el cliente
se pondr en espera, escucharemos la voz que dice transferencia, pero ahora
cuando marquemos la extensin para hacer la trasferencia, entraremos en
comunicacin con ella. Es decir, ahora el usuario 2 entra en comunicacin con
el usuario 3 (ver Figura 80) y decide si quiere o no aceptar la llamada.

Usuario 1 Usuario 2
*2; 2100
Usuario 3
Ext: 2100

Figura 79. Usuario 2 realiza una transferencia atendida hacia el Usuario 3 con etensin 2100.



Usuario 1 Usuario 2
Usuario 3
Ext: 2100
En espera

Figura 80. Usuario 2 entra en comunicacin con Usuario 3 mientras Usuario 1 est en espera.

Si la la persona en la nueva extensin acepta la transferencia, el usuario 2
cuelga y la comunicacin se establece entre el usuario 1 y el usuario 3.

Usuario 1 Usuario 2
Usuario 3
Ext: 2100

Figura 81. Al colgar el usuario 2, se establece comunicacin entre los usuarios 1 y 3.

Si no acepta y cuelga, es el usuario 2 el que se vuelve a poner en contacto con
el usuario 1.

Usuario 1 Usuario 2
Usuario 3
Ext: 2100

Figura 82. Al colgar el usuario 3, el usuario 2 retoma la comunicacin con el usuario 1.

Es importante sealar, que para que estos servicios funcionen el parmetro
canreinvite tiene que tener el valor no. A su vez, la aplicacin Dial() y la
aplicacin Queue() en la extensin llamada tienen que tener la opcin T o t
para que se permita la transferencia.

Caso Prctico 8. Configuracin de Terminales


8. Configuracin de los terminales telefnicos
8.1 Introduccin
En este captulo describiremos cmo configurar los equipos terminales que
utilizarn los empleados de EmpresaX para realizar y recibir llamadas. La
configuracin ser de tipo bsico, proporcionando slo los valores necesarios
para que los usuarios se puedan comunicar. Para una configuracin ms en
profundidad sugerimos ver el manual de usuario de cada modelo de telfono en
cuestin.
8.2 Configuracin del softphone X-Lite
El softphone que utilizaremos en nuestro escenario ser la versin 3.0 del
modelo X-Lite de CounterPath Corporation. Su descarga es gratuita y
proporciona toda la funcionalidad que requiere un usuario normal para
comunicarse. Ofrecindonos la posibiliad incluso de realizar videoconferencias.

Para su configuracin es necesario introducir los datos de usuario SIP y
verificar una serie de parmetros. Pasemos a describir el proceso de
configuracin paso a paso.

Lo primero que debemos hacer es introducir los datos de la cuenta SIP del
usuario. Para ello, una vez abierto el programa, debemos pinchar en la pestaa
cuyo smbolo es un tringulo invertido. Esto har que se nos desplieque un
men con distintas opciones. Elegiremos la opcin Sip Account Settings lo
que har que se nos abra una pantalla llamada Sip Accounts.



Figura 83. Interfaz de X-Lite y pantalla SIP Accounts.

Una vez aqu, le daremos al botn de la izquierda Add para aadir una nueva
cuenta. Esto hace que se abra una nueva pantalla Properties of account N
donde N es el nmero de la cuenta.

Figura 84. Pantalla para la configuracin de los datos de un usuario SIP en X-Lite.

Los datos que debemos completar son:

User Name: pondremos la extensin del cliente. Es el identificador entre
corchetes del archivo sip.conf

Password: aqu ponemos la contasea del cliente SIP, es decir, el valor
de secret en el archivo sip.conf.

Domain: deberemos introducir el contexto del cliente. Es el valor del
parmetro context en el archivo sip.conf.



Send outbound via: debemos marcar la opcin proxy, poniendo en
Address la direccin del servidor Asterisk.

Una vez completado estos campos y pulsemos Aceptar, deberemos esperar
unos segundos para que el cliente se registre. A partir de este momento,
seremos capaces de llamar y ser llamados.
8.3 Configuracin de los telfonos IP
La EmpresaX dispone de tres telfonos IP, dos de ellos son el modelo SPA922
de Linksys
66
y el tercero es el modelo Budgetone 200 de Grandstream
67
.

Figura 85. Modelo SPA922 de Linksys.

Figura 86. Modelo BudgetTone de Grandstream.

Utilizaremos para ambos modelos la interfaz web de configuracin, siendo
necesario para ello, disponer de una conexin a la red y un terminal con
navegador web.

A la hora de asignar una direccin IP al equipo para tener una conexin a la
red, podemos proceder de dos maneras:

66
La documentacin del fabricante para este modelo la podemos encontrar en: http://www-
es.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=ES%2FLayout&cid=1175238
414056&pagename=Linksys%2FCommon%2FVisitorWrapper&lid=1405641153B07.
67
El manual de usuario proporcionado por el fabricante, se encuantra disponible en:
www.grandstream.com/user_manuals/BT200_User_Manual.pdf.


Utilizar una direccin IP dinmica.

Asignar una direccin IP esttica.
8.3.1 Asignacin de una direccin IP mediante DHCP
En el primer procedimiento, es necesario activar el protocolo DHCP, el cual nos
proporcionar una direccin IP dentro del rango de nuestra red.

Para el modelo Linksys SPA 2020 es necesario seguir los siguientes pasos:

1. Ingresamos en el men del telfono pulsando la tecla que tiene el dibujo
de una hoja con un pico doblado.

2. Una vez en l, elegimos la novena opcin: Network. En este apartado
podemos ver si el protocolo DHCP est habilitado o no mirando primera
opcin: WAN Connection Type. Si est deshabilitado, debemos pulsar
la tecla 1 y a continuacin seleccionar la opcin edit hasta que en la
pantalla veamos . En ese momento seleccionamos ok y a
continuacin save.

3. Por ltimo, para que se lleven a cabo las modificaciones, debemos
reiniciar el telfono. Para ello dentro del men seleccionamos la
duodcima opcin reboot.

4. Una vez reiniciado el telfono, podremos ver los valores que ha obtenido
dinmicamente yendo de nuevo a la opcin Network y consultando las
entradas 2 Current IP, 5 Current Netmask y 6 Current Gateway.

En el caso del modelo Grandstream Budget Tone 200, los pasos que debemos
dar son los siguientes:

1. Ingresamos en el men pulsando el botn al lado de la palabra menu.
La primera opcin es la referente al DHCP.

2. Mediante las teclas de desplazamiento, hacemos que en la pantalla
aparezca dhcp ON.

3. Volvemos a pulsar la tecla de men, y reiniciamos el telfono
seleccionando la opcin reset.

4. Para ver los parmetros que le ha proporcionado el servidor DHCP,
volvemos a ingresar en el men y mediante las teclas de
desplazamiento vamos pasando por las opciones: [2] IP Addr, [3]
Subnet y [4] router para ver la direccin IP, la mscara de subred y la
direccin de la puerta de enlace respectivamente.


8.3.2 Asignacin de una direccin IP esttica
Si queremos proporcionar una direccin IP esttica a los telfonos, es
necesario desactivar DHCP. Para hacerlo, debemos acceder a la entrada del
men donde se nos permite habilitarlo o deshabilitarlo como se explic en la
seccin 8.3.1 Asignar una direccin IP dinmica mediante DHCP de este
documento.

A continuacin deberemos proporcionar los siguientes datos en ambos
telfonos:

Direccin IP
Mscara de subred
Puerta de enlace

En el modelo de Linksys esto lo hacemos siguiendo los siguientes pasos:

1. En el men, seleccionamos la novena opcin Network.

2. En l, editamos las opciones:

Non DHCP IP Address, donde pondremos la direccin IP.
Non DHCP Subnetmask, para la mscara de subred.
Non DHCP Default-Router, para la direccin de la puerta de enlace.

Para ello, seleccionaremos la opcin que deseemos editar, pulsaremos
edit y a continuacin introducimos el valor. Al terminar pulsamos ok y
save.

3. Por ltimo, debemos reiniciar para que se apliquen los cambios que
hemos introducido.

Como antes, para ver los valores de los parmetros que hemos editado,
seleccionamos la entrada Network del men y consultamos las opciones: 2,
5 y 6.

Para el modelo de Grandstream, la configuracin se hace del siguiente modo:

1. Ingresamos al men, mediante la tecla

2. Editamos las opciones:

IP address
Netmask
Gateway

3. Por ltimo, reiniciamos el telfono para que los cambios surtan efecto.

Para consultar los datos que hemos introducido, slo tenemos que entrar de
nuevo en el men y seleccionar las opciones del paso 3.


8.3.3 Configurar los datos de la cuenta SIP mediante la interfaz web
Una vez que sabemos la direccin IP de los telfonos y comprobar que son
accesibles desde otro equipo de la red (utilizando el comando ping desde otro
equipo), podremos acceder a su interfaz web.

Para ello deberemos escribir en la barra de direcciones del navegador la
direccin IP del telfono que queramos configurar. As, si un equipo tiene
asignada la direccin IP 192.168.1.200, en la barra de direcciones del
navegador escribiremos: http://192.168.1.200.

Al hacer esto, la pgina de inicio de la configuracin a travs de la web
aparecer en la pantalla. Una vez ms, dependiendo del modelo procederemos
de una u otra forma.

Para el modelo de Linksys, lo primero que haremos ser pinchar en
AdminLogin para as tener disponibles todas las opciones de configuracin. A
continuacin, pincharemos en la pestaa Ext 1 donde configuraremos los
datos del cliente SIP. El aspecto de est pgina es el que nos muestra la
Figura 87 a continuacin.

Figura 87. Interfaz web del modelo Linksys SPA922.


En ella es necesario introducir los siguientes valores:

Proxy: pondremos la direccin IP de servidor proxy SIP.

User ID: aqu escribiremos el usuario SIP correspondiente. Recordemos
que este valor es el nombre entre corchetes que hemos utilizado al definir
el cliente en el archivo sip.conf.

Password: en este campo indicaremos la contrasea del usuario.

Cuando hayamos terminado, pincharemos en el botn Submit All Changes lo
que har que el dispositivo se reinicie para que se apliquen los nuevos valores.

Para el modelo Grandstream, debemos seguir un preceso parecido. Sin
embargo, a diferencia del modelo de Lynksys, este nos pide nada ms entrar
una contrasea para acceder a la configuracin, siendo la contrasea por
defecto para el administrador: admin.

Una vez introducida, deberemos pinchar en el enlace ACCOUNT y editar
como los siguientes campos:

SIP Server: aqu debemos poner la direccin IP del servidor proxy SIP.

SIP user ID: en este campo debe ir el nombre del usuario SIP.

Authenticate ID: aqu pondremos la contrasea del usuario.

El aspecto de la pgina de de configuracin de este modelo de Grandstream la
podemos apreciar en la figura siguiente:



Figura 88. Interfaz web del modelo Grandstream Budgedtone 200.
8.3 Configuracin de los telfonos analgicos
La EmpresaX dispone de un total de N telfonos analgicos. Para poderlos
usar como clientes SIP, ser necesario usar un adaptador de analgico a
digital.

Nosotros usaremos el modelo de Linksys PAP2
68
, el cual permite conectar dos
terminales analgicos utilizando una sola conexin a internet. Para ello
dispones de dos conectores RJ11 y uno RJ45. En la figura n a continuacin, se
aprecia como sera la conexin a la red de un telfono analgico.

68
La documentacin del fabricante para este modelo la podemos encontrar en: http://www-
es.linksys.com/servlet/Satellite?c=L_Product_C2&childpagename=ES%2FLayout&cid=1174608
803333&pagename=Linksys%2FCommon%2FVisitorWrapper&lid=0333392950B01.


Figura 89. Conexin de un telfono analgico con el adaptador Linksys PAP2.

Para su configuracin utilizaremos, al igual que con los telfonos IP, la interfaz
web que nos ofrece este modelo de Linksys.

Como antes, es posible configurar la direccin IP del tlefono de forma esttica
o dinmica segn queramos utilizar DHCP o no. Para la configuracin, es
necesario que el terminal analgico se encuentre conectado al adaptador, y el
adaptador a la red IP.
8.3.1 Asignar una direccin IP dinmica mediante DHCP
Para que el telfono analgico reciba una direccin IP de forma dinmica,
procederemos de la siguiente manera:

1. Pulsamos la secuencia de teclas ****. Esto har que despus de un
mensaje de bienvenida entremos en el men de configuracin.
2. Para activar DHCP, marcamos 101# y a continuacin 1#.

3. Para salvar la configuracin pulsamos 1.

Si queremos comprobar la direccin IP que ha sido asignada, deberemos
entrar de nuevo en el men de configuracin marcando ****. A continuacin
pulsamos 101# y una voz nos dir la direccin IP del telfono.
8.3.2 Asignar una direccin IP esttica
Si no disponemos de servicio DHCP y deseamos asignar una direccin IP
dinmicamente, debemos seguir los pasos siguientes:



1. Deshabilitamos DHCP. Para ello, entramos en el men marcando **** y
a continuacin pulsamos 110# seguido de la tecla 0#. Guardamos el
cambio pulsando 1.

2. Accedemos al men de configuracin de una direccin IP esttica
marcando #111.

3. Introducimos la direccin IP seguida de la tecla #. Por ejemplo, si
deseamos poner la direccin 192.168.1.200, deberemos teclear:
192*168*1*200#. Pulsamos 1 para guardar los cambios.

4. Para configurar la mscara de subred marcamos 131#. Utilizamos el
mismo formato que en el paso anterior. As, para 255.255.255.0,
deberemos teclear 255*255*255.0#. Pulsamos 1 par guardar.

5. Por ltimo, para configurar la puerta de enlace, marcamos 121# e
introducimos su direccin con el mismo formato que antes. A
continuacin pulsamos 1 para guardar.

Al terminar, tendremos todos los valores necesarios para tener una conexin a
la red.
8.3.3 Configurar la cuenta SIP mediante la interfaz web
Una vez que disponemos de una direccin IP, podremos acceder a la interfaz
web del dispositivo para configurar los datos de la cuenta SIP.

Lo primero que haremos ser introducir la direccin IP en la barra de
direcciones del navegador. Esto nos permite acceder a la pgina de inicio de
de la interfaz web.

Para disponer de todas las opciones de configuracin, pulsamos la opcin
Admin Login. A continuacin pinchamos en la pestaa Line1 o Line2 segn
en qu lnea est conectado el telfono analgico.

En la Figura 90 a continuacin vemos como es el aspecto de la pgina de
configuracin de Line 1.



Figura 90. Interfaz web del modelo Linksys PAP2.

Los valores que tenemos que editar son los siguientes:

Proxy: aqu pondremos la direccin IP del servidor Asterisk.

User ID: es el identificador de usuario. Deberemos poner lo que aparece
entre corchetes en el archivo sip.conf para el usuario en cuestin.

Password: en este campo debemos introducir el valor de secret en la
definicin del cleinte en el archivo sip.conf.

9. Conclusiones

9. Conclusiones
El entorno tecnolgico en el que se encuentra inmersa la telefona IP es muy
amplio y necesita de la compresin de un gran nmero de tecnolgias para
poder desenvolverse en ella. Al ser la unin del mundo IP y el de la telefona
clsica, es necesario disponer de conociemientos sobre muy diversas reas.

Entre ellos podemos destacar:

La compresin de los protocolos que se utilizan para transmitir la voz a
travs de la red IP y los destinados a complementarlos en aspectos
relacionados con la seguridad, sealizacin y calidad de servicio.

El funcionamiento de las redes de telefona clsica y la forma de
interactuar con ellas.

El dominio de sistemas informticos para el correcto funcionamiento de
las aplicaciones.

Todo esto hace que en muchas ocasiones el iniciarse en la VoIP sea una tarea
ms que ardua.

A travs de este documento se propociona una gua para que una persona con
unos conocimeintos medios en las tecnologas de la informacin se pueda
iniciar en la telefona IP. As, mediante la sntexis de las principales tecnologas
implicadas en la VoIP y la inclusin de numerosos ejemplos, el proceso de
aprendizaje resulta mucho ms liviano.

El hecho de incluir un caso prctico, explicando con todo detalle y de forma
didctica la implatancin de un sistema de comunicaciones VoIP en una
empresa, brinda la posibilidad de descubir en un conexto real las bondades que
ofrece la telefona de cdigo abierto as como los problemas a los que hay que
enfrentarse al utilizarla.

Abordando funcionalidades tan demandas por las empresas de hoy en da
como la mensajera unificada, el rutado inteligente de llamadas para disminuir
costes, la videoconferencia y otros muchos ms, hemos implantado un sistema
de telefona moderno y ajustado a las necesidades de una empresa.

De esta manera, al trmino de este documento seremos capaces de instalar,
configurar y aprender la sintaxis del lenguaje de la plataforma de telefona
Asterisk, en un caso que cumple con las dos premisas sobre las que
descansan las plataformas de telefona de cdigo abierto: a medida de las
necesidades del usuario y de bajo coste econmico.

10. Referencias

10. Referencias
Para la elaboracin del presente documento se han consultado las siguientes
referencias:

Estndares y borradores:

RFC 2396 Uniform Resource Identifiers: Generis Syntax. The Internet
Engineering Task Force (IETF). 1998. (www.ietf.org/rfc/rfc2396.txt)

RFC 2822 Internet Message Format. The Internet Engineering Task
Force (IETF). 2001. (www.ietf.org/rfc/rfc2822.txt)

RFC 3261 SIP: Session Initiation Protocol. The Internet Engineering
Task Force (IETF). 2002. (www.ietf.org/rfc/rfc3261.txt)

RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers. The
Internet Engineering Task Force (IETF). 2002.
(www.ietf.org/rfc/rfc3263.txt)

RFC 3550 RTP: A Transport Protocol for Real-Time Applications. The
Internet Engineering Task Force (IETF). 2003.

RFC 3581 An Extension to the Session Initiation Protocol (SIP) for
Simmetric Response Routing. The Internet Engineering Task Force
(IETF). 2003. (www.ietf.org/rfc/rfc3581.txt)

RFC 3605 Real Time Control Protocol (RTCP) attribute in Session
Description Protocol (SDP). The Internet Engineering Task Force (IETF).
2003. (www.ietf.org/rfc/rfc3605.txt)

RFC 3665 Session Initiation Protocol (SIP) Basic Call Flow Examples.
The Internet Engineering Task Force (IETF). 2003.

RFC 4566 SDP: Session Description Protocol. The Internet
Engineering Task Force (IETF). 2006. (www.ietf.org/rfc/rfc4566.txt)

RFC 4961 Symmetric RTP / RTP Control Protocol (RTCP). The
Internet Engineering Task Force (IETF). (www.rfc-
editor.org/rfc/rfc4961.txt)

RFC 5389 Session Traversal Utilities for NAT (STUN). The Internet
Engineering Task Force (IETF). 2008. (http://tools.ietf.org/html/rfc5389)
10. Referencias

draft-ietf-behave-turn-14 Traversal Using Relays around NAT (TURN):
Relay Extensions to Session Traversal Utilities for NAT (STUN). The
Internet Engineering Task Force (IETF). 2009. (www.ietf.org/internet-
drafts/draft-ietf-behave-turn-14.txt)

draft-ietf-sip-outbound-15 Managing Client Initiated Connections in The
Session Initiation Protocol (SIP). 2008. (http://tools.ietf.org/html/draft-ietf-
sip-outbound-15)

draft-ietf-mmusic-ice-19 Interactive Connectivity Establishment (ICE): A
Protocol for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols. The Internet Engineering Task Force (IETF).
2007. (http://tools.ietf.org/html/draft-ietf-mmusic-ice-19)

ITU-T G.107 The E-model: a computational model for use in
transmission planning. International Telecommunication Union (ITU).
2009. (www.itu.int/rec/T-REC-G.107/en)

ITU-T G.109 Definition of categories of speech transmission quality.
International Telecommunication Union (ITU). 1999. (www.itu.int/rec/T-
REC-G.109/en)

ITU-T G.113 Transmission impairments due to speech processing.
REC-G.113/en).

ITU-T G.114 One-way transmission time. International
Telecommunication Union (ITU). 2003. (www.itu.int/rec/T-REC-G.114/en)

ITU-T H.225.0 Call signalling protocols and media stream packetization
for packet-based multimedia communication systems. International
Telecommunication Union (ITU). 2006. (www.itu.int/rec/T-REC-
H.225.0/en)

ITU-T H.245 Control protocol for multimedia communication.
REC-H.245/en)

ITU-T H.323 Packet-based multimedia communications systems.
REC-H.323/en)

UIT-T P.800 Methods for subjective determination of transmission
quality. International Telecommunication Union (ITU). 1996.

10. Referencias

Libros:

Gomillion D, Dempster B, (2005), Building Telephony Systems with
Asterisk, Pack Publishing.

Goncalves F, (2007), Configuration Guide for Asterisk PBX, Booksurge
Llc.

Mahler P, (2004), VoIP Telephony with Asterisk, Signate.

Van Meggelen J, Madsen L, Smith J, (2007), Asterisk: The Future of
Telephony, (2nd Edition), OReilly.

Wallingford T, (2005), Switching to VoIP, OReilly.

Sitios web:

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

o http://www.voipforo.com

Foros:

http://groups.google.es/group/asterisk-es

Implementación de un sistema VoIP con Asterisk

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Implementación de un sistema VoIP con Asterisk

Uploaded by

Copyright:

Available Formats

ESCUELA TCNICA SUPERIOR DE INGENIERA INFORMTICA

IGNACIO LUENGO NARANJO

You might also like