Este documento describe los sistemas VOIP con Asterisk, incluyendo detalles sobre protocolos como SIP e IAX2, configuración de troncales digitales e interconexión entre servidores Asterisk. También cubre temas como codificación de voz, señalización analógica y digital, e interfaces para conectarse a la red telefónica conmutada pública.

1. Sistemas de VOIP con Asterisk: MODULO 2 2010 – Guayaquil, Ecuador Instructor: Ing. José Córdova

2. Detalles Adicionales

3. Detalle DTMF

4. Pila de Protocolos

5. Setting Up un Sistema Asterisk Purpose Simultaneous calls Minimum Recommendation Hobby System <5 X86 400Mhz 256MB SoHo System 5 - 10 X86 1Ghz 512Mb SMB System 10 - 15 X86 3Ghz 1GB Large >15 Dual CPU, Clusters

6. Datos de Instalaciones

7. Datos de Instalaciones AMD Sempron 1.5GHz /512 MB RAM Pentium D Dual Core 2.8GHz/1.5GB RAM. Fuente: CPU dimensioning on performance of Asterisk VoIP PBX, ISBN 1-56555-318-7, p139-146. CNS’08

8. Datos de Instalaciones Resultados estudio de TransNexus en 2007: Dell Precision 490 server with two Intel Xeon 5140 dual core, 2.33 GHz, CPUs and 4 GB RAM, $3000. $4,000 G.729 codec royalty ($10 per port * 400 ports). Total $7,000 G.711 to G.729 Transcoding: 400 simultaneous calls at a cost of $17.50 per port. No transcoding: 1500 simultaneous calls at a cost of $2 per port.

9. SIP y Troncal SIP

10. Mensajes SIP Informational • 100 Trying • 180 Ringing • 181 Call forwarded • 182 Queued • 183 Session Progres Success • 200 OK Request Failure • 400 Bad Request • 401 Unauthorised • 403 Forbidden • 404 Not Found • 405 Bad Method • 415 Unsupported Content • 420 Bad Extensions • 486 Busy Here

11. Mensajes SIP Server Failure • 504 Timeout • 503 Unavailable • 501 Not Implemented • 500 Server Error Global Failure • 600 Busy Everwhere • 603 Decline • 604 Doesn’t Exist • 606 Not Acceptable

12. Protocolo SIP SIP Elementos principales: Registrar y SIP Proxy. User Agent . SIP Proxy Server : Elemento que actúa como servidor y cliente. Como cliente genera mensajes en nombre del cliente que originó el requerimiento. Los mensajes recibidos se responden o son re-encaminados. Outbound Proxy. Inbound Proxy.

13. Inbound Proxy El usuario se vuelve independiente del equipo que utiliza y de su localización.

14. Outbound Proxy Se encarga de las tareas administrativas: tarifación, grupos de usuarios, permisos, dominios, etc. Un servidor puede ser entrante y saliente a la vez.

15. Señalización SIP con Proxy

16. Registrar Server Maneja mensajes de tipo REGISTER. REGISTER es un mensaje de ubicación que indica IP y Puerto de un UA. No se implementa en Asterisk, limitación de *. No se implementan posiciones múltiples para un UA. Se puede implementar en el SIP Proxy.

17. El registro SIP El registro vuelve dinamica la localización del UA. La conmutación del SIP Proxy Server dependerá de la localización Se basa en dos enfoques: A traves del registro en el REGISTRAR Server el usuario puede ser localizado en un dispositivo cualquiera. “ Movilidad IP” a través de VPNs. Parallel Forking : es parte de SIP, con un UA registrado en varias ubicaciones. La sesión (llamada) se establece con quien primero responda el INVITE de la señalización. Ventaja: ahorra tener varios UA por diferentes lugares/equipos. Asterisk no implementa Parallel Forking.

18. SIP Proxy y Asterisk servers SIP PROXY SERVER ASTERISK SERVER NO es una PBX. No puede montar aplicaciones terminales. Se enlaza con un GW PSTN Un SIP Proxy maneja el control de la llamada en nombre de los UA y nunca es terminal de una llamada. DEBE implementar SIP. NO es un SIP Proxy Monta aplicaciones como PBX. Es un GATEWAY PSTN. Cuando Asterisk “controla” una llamada actua como B2BUA manteniendose en medio de la llamada como terminal. No habla bien SIP.

19. Arquitectura Avanzada Fuente: SIPdoc, www.sipdoc.net

20. Arquitectura Avanzada Recursos para arquitecturas avanzadas: SIP Proxy y Registrar: OPENSER Balanceo de Carga: OPENSIPS Balanceo de servicios y Alta Disponibilidad en cluster: Heartbeat. Sincronización de datos por red: Csync2, rsync, DRDB . Ejecución paralela entre nodos: UCARP

21. Interconexión SIP SIP permite crear enlaces con cualquier PBX, Gateway o cualquier dispositivo que hable SIP. La configuración de un enlace de interconexión entre Asterisk usando SIP se basa en: Configuración de un peer/user/friend. Register: register => usuario:password@host La interconexión con IAX2 será muy parecida.

22. Configuración Interconexión sip.conf Server A: [general] register => serverA:welcome@192.168.1.2/serverB [serverB] type=friend secret=welcome context=from_serverB host=dynamic disallow=all allow=ulaw

23. Configuración Interconexión sip.conf Server B: [general] register => serverB:welcome@192.168.1.1/serverA [serverA] type=friend secret=welcome context=from_serverA host=dynamic disallow=all allow=ulaw

24. extensions.conf Server A [internal] exten => _1XXX,1,Dial(SIP/${EXTEN},30) exten => _1XXX,n,Playback(hello) exten => _1XXX,n,Hangup() include => remote [remote] exten => _2XXX,1,Dial(SIP/serverB/${EXTEN}) exten => _2XXX,n,Hangup() [from_serverB] include => internal

25. extensions.conf Server B [internal] exten => _2XXX,1,Dial(SIP/${EXTEN},30) exten => _2XXX,n,Playback(hello) exten => _2XXX,n,Hangup() include => remote [remote] exten => _1XXX,1,Dial(SIP/serverA/${EXTEN}) exten => _1XXX,n,Hangup() [from_serverA] include => internal

26. IAX2 y Troncal IAX Inter Asterisk eXchange v2

27. IAX2 Recordar: RFC 5456. Interconecta Servidores Asterisk. Poco teléfonos implementan IAX: Hardphones ATCOM y Softphone ZOIPER. Señalización y Streaming en el mismo puerto 4569 UDP. Solución al problema del NAT. Incluía seguridad: Texto Plano, Llave RSA, MD5.

28. IAX2 Nuevo: Se puede utilizar para enviar varios payloads de voz en un flujo ya creado. Disminuye la inserción completa de overheads. Se utiliza una configuración parecida a la de la Troncal SIP.

29. Configuración Interconexión IAX2

30. IAX.conf En las nuevas versiones de Asterisk viene incluída una característica adicional de seguridad anti DoS en el protocolo IAX2. http://www.asterisk.org/doxygen/trunk/Config_iax.html [general] jitterbuffer=yes bindport=4569 calltokenoptional = 0.0.0.0/0.0.0.0 requirecalltoken = auto maxcallnumbers = 512

31. Configuración Interconexión IAX2 Server A: [general] autokill=yes ;para evitar lazos register => serverA:welcome@192.168.1.2 ; línea de registro [serverB] type=friend secret=welcome trunk=yes context=from_serverB host=dynamic deny=0.0.0.0/0.0.0.0 permit=192.168.1.2/255.255.255.0

32. Configuración Interconexión IAX2 Server B: [general] autokill=yes register => serverB:welcome@192.168.1.1 [serverA] type=friend secret=welcome trunk=yes context=from_serverA host=dynamic deny=0.0.0.0/0.0.0.0 permit=192.168.1.1/255.255.255.0

33. extensions.conf Server A [internal] exten => _1XXX,1,Dial(SIP/${EXTEN},30) exten => _1XXX,n,Playback(hello) exten => _1XXX,n,Hangup() include => remote [remote] exten => _2XXX,1,Dial(IAX2/serverB/${EXTEN},30,r) exten => _2XXX,n,Hangup() [from_serverB] include => internal

34. extensions.conf Server B [internal] exten => _2XXX,1,Dial(SIP/${EXTEN},30) exten => _2XXX,n,Playback(vm-unavail) exten => _2XXX,n,Hangup() include => remote [remote] exten => _1XXX,1,Dial(IAX2/serverA/${EXTEN}) exten => _1XXX,n,Hangup() [from_serverA] include => internal

35. Señalización Analógica

36. Señalización Analógica Existen 3 tipos de Señalización: Señalización de Supervisión. Señalización de Direccionamiento. Señalización de Información. De los tipos de señalización de Supervisión tenemos: On-hook: cuando el usuario pone el teléfono “on-hook” la PBX lo interrumpe y no permite que la corriente eléctrica pase. En este estado el circuito que se ha creado se denomina “on-hook”, el teléfono solo puede timbrar.

37. Señalización de Supervisión Analógica Off-Hook: “Alzar el teléfono” cierra el lazo con la PBX y le indica que el usuario intenta hacer una llamada, la PBX genera un tono de marcado indicando al usuario que esta lista para aceptar la dirección de marcado. Ringing: cuando un usuario llama a otro genera un voltaje al ringer que advierte al otro usuario de la recepción de una llamada. Señalización varía por pais con diferentes tonos: Para modificar a Asterisk: indications.conf

38. Señalización Analógica Señalización de Direccionamiento: DTMF (Dual Tone Multi-Frequency). Pulse Dialing (teléfonos de disco). Señalización de Información: muestra el progreso de la llamada y los eventos relacionados a ella: Dial Tone. Busy Tone. Ringback. Invalid Number. Congestion. Confirmation Tone.

39. Interfaces con PSTN Existen tres maneras de Conectarse a la PSTN (RTPC, RTB): Canal Análogo. Par de cobre regular. Canal Digital. Gran cantidad de lineas. Vienen en CSU/DSU o en MUX de Fibra. Conector terminal RJ45 A veces en conectores BNC. Canal Sip.

40. Interfaces Análogicas FXO – Foreign eXchange Office: Se conecta a la PSTN o a otra extensión de la PBX. Se comunica con una linea telefónica de una PSTN. RECIBE un tono de marcado. OPX (Off Promises Extension) conexión a un FXS de otra central. FXS – Foreign eXchange Station: Alimenta teléfonos análogos, modems, faxes. DA un tono de marcado y energía al teléfono.

41. FXS y FXO con Asterisk

42. Señalización de Interfaz Análoga Señalización de las Interfaces Analógicas: Loop-Start. Es el mas usado. Permite al teléfono indicar “on-hook” y “off-hook”. On Hook, el teléfono esta esperando un tono de timbrado. Off Hook, solicita tono de marcado y permite pasar el audio. Permite al switch indicar “ring” y “no-ring”. La linea regularmente esta en “lazo abierto”. Cuando se pone “lazo cerrado” el switch da tono de marcado. Una llamada entrante es señalizada por un voltaje de timbrado de 100V sobre el par (de cobre) abierto.

43. Señalización de Interfaz Análoga Groundstart: Similar a Loopstart. El que llama pone su linea en corto circuito. El SW identifica ese estado y cambia el voltaje sobre el par abierto y cierra el lazo. La linea primero se “ocupa” antes de ser ofrecida al que desea llamar.

44. Señalización de Interfaz Análoga Kewlstart: Añade inteligencia al circuito. Monitorea el otro lado de la conversación. Se basa en Loopstart. Asterisk usa KS por defecto.

45. Líneas Digitales

46. Líneas Digitales PCM: La señal analógica es muestreada 8000 veces por segundo. Ley u: USA y Japón, resto del mundo: Ley A. Las troncales digitales usan TDM en dos formatos:

47. Líneas Digitales Pocas líneas de la PSTN  se manejan con canales FXO. Muchas líneas de la PSTN  la PSTN debe proveer una troncal digital. TDM (Multiplexación por División de Tiempo) permite montar múltiples canales en una sola trama de datos. En cada SLOT de tiempo se usa 64 Kbps, g711, de BW para transmitir un canal de voz. En USA: T1 con 24 líneas disponibles. En EU y LATAM: E1 con 30 líneas disponibles. T1 regularmente usa un esquema de RBS (Robbed Bit Signaling) un bit es “prestado” para señalización y así no pierde canales para sincronización y señalización como E1. Los canales se transmiten a 56Kbps en cada slot.

48. Líneas Digitales El origen de usar T1s fue el de conectar PBX y transmitir canales de voz. T1 puede usar CAS y CCS. T1: Señalización Asociada al Canal (CAS) es un metodo de señalización comunmente utilizado en interconexión de centrales PBX.

49. Lineas Digitales T1: 193 bits: 8bits x 24slots (DS0) +1 bit de Framing. T1 se repite cada 125us = 8000 muestras/segundo: 1.544Mbps = 193x8000. Para hacer Framing cuenta con: SF/D4 12 Frames en una secuencia. ESF Agrega CRC y Control.

50. T1 y E1 T1: Un canal DS0 usa 64Kbps suficiente para la voz pero no para la señalización. RBS: Usa el LSB para señalización, la pérdida de la calidad es imperceptible. Es señalización CAS en banda E1: 30 canales disponibles de los 32, 1 es usado para framing y el 17 es usado para señalización Es señalización CAS fuera de banda.

51. T1 y E1 E1: El formato de frame tiene 32 timeslots. Timeslot 1 se usa para información de framing. Timeslot 17 lleva la información de el resto de los timeslots y de el inicio de un multi frame. CCS: Utilizan un canal común para señalizar: ISDN Q.931 Q.SIG y SS7. http://www.rhyshaden.com/transm.htm

52. Codificación de la Fuente Digital La codificación indica la manera como los bits son interpretados. Estos son llamados “Códigos de Linea”, capa fisica. T1: ESF con B8ZS D4/SF con AMI E1: HDB3 Capa Física. CCS Capa de Enlace de Datos. Esta información debe darla el proveedor para poder configurarla en Asterisk.

53. Señalización de Troncales Digitales Nos pueden entregar T1/E1: T1 con RBS. T1 con ISDN. E1 con MFC/R2 (CAS) E1 con ISDN. ISDN (Integrated Services Digital Network) es muy común en USA, es estándar de ITU desde 1984. Define: Canales Portadores (Bearer Channels): Datos y Voz

54. Señalización de Troncales Digitales Canales de Datos (Data Channels): Señalización fuera de banda. Señalización LAPD (Link Access Protocol Channel D). Q.931 ISDN viene con 2 Interfaces físicas: BRI (basic rate interface). 2B+D: 2 Bearer (64K) y 1 Data (16K). 1 par de cobre a 148Kbps. PRI (primary rate interface). 1 troncal T1/E1. 23B+D para T1 30B +D para E1.

55. Tarjeta Digital

56. Tarjetas de Telefonía Digital Las tarjetas de Telefonía Digital son tarjetas PCI estándar configurables para utilizarse como T1 (24 canales) o como E1/PRI (32 canales) mediante un jumper. De acuerdo al modelo vienen de diferente numero de puertos: TE110P TE205P TE405P En USA suele utilizarse T1 que tiene 23 canales tipo B y un canal D de 64Kbps, alcanzando una velocidad global de 1536Kbps. En Europa se utiliza más E1 que consiste de 30 canales B y un canal D de 64Kbps, alcanzando una velocidad global de 1984Kbps.

57. Tarjetas de Telefonía Digital

58. Cable T1 Crossover

59. Estado de las Alarmas RED ALARM: Problema al recibir la señal del equipo remoto, la trama no se logra sincronizar. YELLOW ALARM: Si el equipo remoto no puede mantener sincronizada nuestra trama (no la entiende) entrará en RED ALARM y nuestro puerto entrará en YELLOW ALARM. BLUE ALARM (Alarm Indication Signal) Problemas de velocidad de transmisión.

60. Configuración system.conf span: se refiere a un grupo de canales que se transmite a través de un cable. La sintaxis para configurar esta opción es la siguiente: span=(spannum),(timing),(LBO),(framing),(coding) spannum: es el número con que se identifica el span. timing: indica de donde se toma la fuente de reloj. Puede tomar los valores 0 (este span no es fuente de reloj), 1 (este span es fuente primaria de reloj), 2 (igual al cero sin propagación de la señal de reloj) En el lado del transmisor se genera la señal de reloj. La PSTN debería proveer el reloj, la PSTN no puede ser esclavo. 0 el puerto no será usado como fuente de reloj. 1 el puerto es usado como fuente de reloj en primera prioridad. 2 el puerto es usado como fuente de reloj en 2da prioridad, si el primero falla este será la nueva fuente.

61. Configuración system.conf LBO: indica el nivel de potencia con el que se trasmite la señal (por default se pone en 0), este valor esta función de la longitud del cable: “0”: 0-133 ft, “1”: 133-266 ft, “2”: 266-399 ft, “3”: 399-533 ft y “4”: 533-655 ft. 0 db (CSU) / 0-133 ft (DSX-1) 1 133-266 ft (DSX-1) 2 266-399 ft (DSX-1) 3 399-533 ft (DSX-1) 4 533-655 ft (DSX-1) 5 -7.5db (CSU) 6 -15db (CSU) 7 -22.5db (CSU) framing: indica cómo comunicarse con el hardware en el otro extremo de la línea. Para T1 puede ser D4 o ESF y para E1 puede ser CAS (Channel Associated Signalling) o CCS (Common-Channel signalling).

62. Configuración system.conf coding: indica como comunicarse con el otro extremo. Para T1 puede ser ami o b8zs y para E1 puede ser ami (Alternate Mark Inversion) o hdb3 (High Density Bipolar of order 3 code). Canales B: bchan: indica los canales que van a ser usados para datos. Transmiten información a 64Kbps, y se emplean para transportar cualquier tipo de información de los usuarios, bien sean datos de voz o datos informáticos. Estos canales no transportan información de control de la RDSI. Canales D:dchan: indica los canales que van a ser usados para control. Los canales tipo D se utilizan principalmente para enviar información de control, como es el caso de los datos necesarios para establecer una llamada o para colgar, por esta razón también se le conoce como canal de señalización.

63. Configuración chan_dahdi.conf switchtype: tipo de switch en la línea PRI que se usa, los más comunes son euroisdn, national y qsig. national: National ISDN 2 (default) dms100: Nortel DMS100 4ess: AT&T 4ESS 5ess: Lucent 5ESS euroisdn: EuroISDN (common in Europe) ni1: Old National ISDN 1 qsig: Q.SIG group: define el numero de grupo al que pertenecen los canales.

64. Configuración chan_dahdi.conf signalling: tipo de señalización pri_cpe (Costumers Premisses Equipment) para indicar que la tarjeta trabajará como esclavo y pri_net (Network) para el maestro. auto: Use the current value from DAHDI. em: E & M em_e1: E & M E1 em_w: E & M Wink featd: Feature Group D (The fake, Adtran style, DTMF) featdmf: Feature Group D (The real thing, MF (domestic, US)) featdmf_ta: Feature Group D (The real thing, MF (domestic, US)) through a Tandem Access point featb: Feature Group B (MF (domestic, US)) fgccama Feature Group C-CAMA (DP DNIS, MF ANI)

65. Configuración chan_dahdi.conf fgccamamf Feature Group C-CAMA MF (MF DNIS, MF ANI) fxs_ls: FXS (Loop Start) fxs_gs: FXS (Ground Start) fxs_ks: FXS (Kewl Start) fxo_ls: FXO (Loop Start) fxo_gs: FXO (Ground Start) fxo_ks: FXO (Kewl Start) pri_cpe: PRI signalling, CPE side pri_net: PRI signalling, Network side gr303fxoks_net: GR-303 Signalling, FXO Loopstart, Network side gr303fxsks_cpe: GR-303 Signalling, FXS Loopstart, CPE side sf: SF (Inband Tone) Signalling

66. Configuración chan_dahdi.conf sf_w: SF Wink sf_featd: SF Feature Group D (The fake, Adtran style, DTMF) sf_featdmf: SF Feature Group D (The real thing, MF (domestic, US)) sf_featb: SF Feature Group B (MF (domestic, US)) e911: E911 (MF) style signalling ss7: Signalling System 7 pri_cpe: CPE (Customer Promises Equipment), cliente, usuario, esclavo. pri_net: Host, Master, Network. context: contexto al que se dirigirán las llamadas entrantes. channel: canales a los cuales se les van a asignar las opciones

67. Asterisk Gateway Interface AGI

68. AGI AGI (Asterisk Gateway Interface) provee una interfaz estándar para que programas externos puedan controlar el plan de marcado. Los mas usados: PHP, Python, Bash, Perl. El intercambio de información del script con Asterisk se realiza vía los canales de comunicación: STDIN, STDOUT y STDERR. Lee desde STDIN para obtener información. Escribe en STDOUT para enviar información. Escribe en STDERR para enviar información de debugging.

69. AGI Desde el punto de vista del Script: Entradas desde Asterisk son STDIN. Salidas hacia Asterisk son STDOUT. El control de la ejecución esta en manos de Asterisk. Hay que cuidar lo que se envía a ejecutar. Buscar un Lenguaje de Programación de rápida ejecución.

70. AGI Comandos El script AGI envía comandos a Asterisk escribiendo en el STDOUT. Seguidamente Asterisk envía una respuesta por cada uno de ellos que es leída por el script. ANSWER: atiende. HANGUP: cuelga. SAY [NUMBER | DIGITS | ALPHA | PHONETICS]: dice un número, dígito, caracter o una cadena fonéticamente. SET [CONTEXT | EXTENSION | PRIORITY]: establece un nuevo contexto, extensión o prioridad luego de finalizada la ejecución de script. VERBOSE: imprime un mensaje en el log. WAIT FOR DIGIT: espera que se presione un dígito. [SET | GET] VARIABLE: asigna u obtiene el valor de una variable del plan de marcación.

71. AGI y Lenguajes

72. Ejecución AGI

73. AGI y PHP Todo script AGI basado en PHP debe tener la siguiente forma: Se debe proveer 2 funciones para hacer “read” y “write” de los flujos correspondientes STDIN y STDOUT. Codigo Operacional y los “comandos” se ejecutarán a partir de esas funciones r/w. Se deben cerrar los flujos para finalizar los scripts.

74. Comunicación Asterisk y AGI ASC: AGI Script, AST: Asterisk

75. AGI con DB y Web

76. AGI Ejemplos El programa debe tener modo de ejecución. Estar en /var/lib/asterisk/agi-bin. Para llamarlo desde el plan de marcado: exten => 123,1,Answer() exten => 123,2,AGI(mi_script.php|argumentos) exten => 123,2,AGI(otro_script.agi,par1,par2,parn) El siguiente script está escrito en PHP y dicta los números que se encuentran en el archivo que se le pasa como parámetro: yum –y install php; chmod 755 mi_script.php

77. AGI Ejemplo: Dicta numeros (1) #!/usr/bin/php -q <?php // Esta línea es para que que haga no mantenga en un buffer el output ob_implicit_flush(true); set_time_limit(6); error_reporting(0); // Se abren los diferentes archivos (STDIN, STDOUT y un archivo de log del AGI) $in = fopen(&quot;php://stdin&quot;,&quot;r&quot;); $out = fopen(&quot;php://stdout&quot;,&quot;w&quot;); $stdlog = fopen(&quot;/var/log/asterisk/my_agi.log&quot;, &quot;w&quot;); // Si debug es true, escribe en el archivo de log definido anteriormente $debug = true;

78. AGI Ejemplo: Dicta numeros (2) // Toma el nombre del archivo con los números a dictar del primer parámetro $archivo = $argv[1]; // Define la funcion read, que lee el input del STDIN function read() { global $in, $debug, $stdlog; $input = str_replace(&quot;\n&quot;, &quot;&quot;, fgets($in, 4096)); if ($debug) fputs($stdlog, &quot;read: $input\n&quot;); return $input; } // Define la funcion write, que escribe el output en el STDOUT function write($line) { global $debug, $stdlog, $out; if ($debug) fputs($stdlog, &quot;write: $line\n&quot;); fputs($out,$line.&quot;\n&quot;); fflush($out); }

79. AGI Ejemplo: Dicta numeros (3) // Lee el archivo que se paso como parametro $lines = file($archivo); // Reproduce los digitos contenidos en cada linea del mismo informando en el log del foreach ($lines as $line) { $line=trim($line); for ($i=0;$i<strlen($line);$i++) { write(&quot;VERBOSE \&quot;REPRODUCIENDO DIGITO $line[$i]\&quot;&quot;); read(); write(&quot;SAY DIGITS $line[$i] \&quot;\&quot;&quot;); read(); sleep(1); } } // Se cierran todos los handlers de archivos fclose($in); fclose($out); fclose($stdlog); exit; ?>

80. AGI Ejemplo: Dicta numeros (3) Se relaciona el programa con una extensión para probarlo: exten => 200,1,Answer(); exten => 200,2,AGI(dicta.php|/tmp/numeros.txt) exten => 200,3,Hangup()

81. CDR Call Detail Record

82. CDR El CDR es un archivo a manera de log que contiene información acerca de las llamadas, entre otros: Origen, Destino, Intercambio de información, duración. A partir del CDR se puede generar facturación. Asterisk trabaja con CDR en algunos “formatos”: Csv – archivos de texto con valores separados por coma Cdr SQLite – logs de CDR en la base de datos de SQLite Pgsql – logs de CDR en las bases de datos de PostgreSQL Odbc – logs de CDR a cualquier base de datos con soporte unixODBC Mysql – logs de CDR en las bases de datos de MySQL Etc.

83. CDR Para trabajar el CDR utilizando un DB en MySQL: yum install mysql* unixODBC-devel -y service mysqld start mysqladmin -u root password labtelecom09 Ingresar al directorio donde se encuentran las fuentes de asterisk add-ons volver al menuselect y seleccionar soporte para MySQL. mysql –p (con password de root)

84. CDR en MySQL DB Creación de la DB Asterisk y la tabla CDR en SQL.

85. CDR en MySQL DB Agregar indices y un identificador para los registros. ALTER TABLE 'cdr' ADD 'uniqueid' VARCHAR(32) NOT NULL default ‘'; ALTER TABLE 'cdr' ADD INDEX ( 'calldate' ); ALTER TABLE 'cdr' ADD INDEX ( 'dst' ); ALTER TABLE 'cdr' ADD INDEX ( 'accountcode' ); En cdr_mysql.conf, nótese el password. [global] hostname=localhost dbname=asterisk password=labtelecom09 user=root

86. CDR en MySQL DB Cargar los addons relacionados: load app_addon_sql_mysql.so load cdr_addon_mysql.so Se pueden agregar en: archivo /etc/asterisk/modules.conf load => cdr_addon_mysql.so Reiniciamos el servicio de Asterisk y verificamos que el cdr para mysql este levantado: CLI> restart now CLI> cdr mysql status Practica 7.

87. Análisis de Tráfico y Dimensionamiento Redes VOIP

88. Consideraciones de BW Asterisk permitia traducción de codecs. Transcoding se reflejaba en el desempeño del sistema. CODECS de buena calidad similar a PSTN:

89. Consideraciones de BW BW, Tamaños de Payload, PPS para algunos codecs: Existen también medidas de BW para redes con VAD (Voice Activity Detection). Implementaciones con VAD aseguran un ahorro de hasta el 35% de ancho de banda.

90. Consideraciones de BW Los silencios también se paquetizan.

91. Consideraciones de BW En la Red IP los protocolos agregan “headers” aumentando el tamaño de la trama con consecuencias en el requerimiento de ancho de banda.

92. Consideraciones de BW Por ejemplo para comparar un paquete en diferentes redes de datos. Codec g.711 (64 Kbps) • Ethernet (Ethernet+IP+UDP+RTP+G.711) = 95.2 Kbps • PPP (PPP+IP+UDP+RTP+G.711) = 82.4 Kbps • Frame-Relay (FR+IP+UDP+RTP+G.711) = 82.8 Kbps Codec G.729 (8 Kbps) • Ethernet (Ethernet+IP+UDP+RTP+G.729) = 31.2 Kbps • PPP (PPP+IP+UDP+RTP+G.729) = 26.4 Kbps • Frame-Relay (FR+IP+UDP+RTP+G.729) = 26.8 Kbps Comprobar el costo del transcoding: CLI>core show translation

93. Consideraciones de BW Packetizer VOIP Bandwidth Calculator permite realizar análisis como el anterior para diferentes tipos de datos. Caracteristicas de la herramienta: De acuerdo al encabezado se van calculando los headers que se agregan en la trama. Los retardos entre paquetes o las tramas por paquetes indican la paquetización. La tasa de paquetes (pps) permite dimensionar a los routers. http://www.bandcalc.com/

94. Dimensionamiento de Tráfico: En tamaño (Bytes) RTP+UDP+IP = 40 Bytes para considerar en tamaño de trama. (G.711, G.728, G.728) generan 50 tramas por segundo. BW/llamada = tamaño de la trama x tramas por segundo BW requerido = BW/llamada x llamadas concurrentes Factores de Dimensionamiento: Número de Líneas. Ancho de banda requerido al ISP. Número de canales simultáneos en Asterisk. Solución: 1. Método basado en Simplificaciones: Estimar el número de llamadas por usuario.

95. Método de Simplificaciones Ejemplo de Dimensionamiento: H B1 B2

96. Método de Simplificaciones Se debe dimensionar: Numero de troncales E1. Ancho de banda requerido para la red Frame Relay. El número de Líneas: 165 = 120+30+15 Asumiendo que se utilizará un canal cada 5 usuarios: 165/5=33 Líneas. Usando este criterio y la herramienta de Cálculo tenemos: Ancho de banda para Ramal 1 (B1): 26.8*6=160.8Kbps Ancho de banda para Ramal 2 (B2): 26.8*3=80.4Kbps

97. Método de Erlang Erlang: Ideó un método para calcular el número de líneas en una troncal. Erlang es una medida de tráfico. Describe el volumen de tráfico en una hora. Ejemplo: En una hora se realizan 20 llamadas a un promedio de 5 minutos por llamada: Número total de minutos: 20x5=100 minutos de tráfico. 100min/60min = 1.66 ERLANGS. Método experimental para dimensionamiento, se puede basar en CDR.

98. Método de Erlang Erlang B: Permite calcular el número de líneas en una troncal. Las llamadas arriban aleatoriamente con distribución Poisson. Las llamadas en bloqueo liberan sus canales inmediatamente. BHT (Busy Hour Traffic) = 17% de minutos por día de llamadas. BHT se calcula experimentalmente con un “call logger” o con el método de simplificaciones. GoS (Grade of Service): probabilidad que las llamadas caigan en bloqueo. GoS se puede reemplazar por 0.05 o 0.01

99. Método de Erlang Datos del método experimental: H  B1: 2000 minutos, BHT aprox 300min 5 Erlangs H  B2: 1000 minutos, BHT aprox 170min 2.83 Erlangs B1  B2: 0 minutos, BHT = 0 min GoS = 0.01 (1% de Pérdidas) Con estos datos usaremos un Erlang B Online Calculator: http://www.erlang.com

100. Método de Erlang Resultados: H  B1 = 11 Líneas H  B2 = 8 Líneas Con los requerimientos de BW ya calculados: BW para B1: 26.8x11 = 294.8 Kbps. BW para B1: 26.8x8 = 214.8 Kbps. BW Simplificado BW Erlang 160.8 Kbps 294.8 Kbps 80.4 Kbps 214.8 Kbps

101. RTP Header Compression Se pueden reducir requerimientos de BW usando: Compresión de la Cabecera RTP (RTP Header Compression): Estandar IETF RFC 2508. Disponible en las calculadoras revisadas. Se aplica a redes PPP y Frame Relay. Routers deben soportar el RFC. Realice los cálculos usando RHC.

102. IAX2 Inter Asterisk eXchange 2: Conecta nativamente Asterisk boxes. No necesita soporte de los Routers. Tiene un Modo Troncal nativo. Reutiliza las mismas cabeceras en la 2da llamada. Ejemplo: Capa de Enlace: PPP. RTP común (RFC 3550) Codificando G.729 a 8kbps  20ms de paquete 20 bytes.

103. IAX2

104. IAX2 De la Primera Trama: 20 Bytes de Payload (Voz codificada). 58 Bytes de Cabeceras. 20+58=78 Bytes de la trama completa a 31.2Kbps. 20 Bytes  8 Kbps, 78 Bytes  31.2 Kbps. Para la Segunda Trama: No se agregan nuevas “cabeceras”. Se agregan mini tramas IAX2. 40 Bytes de Voz codificada.

105. IAX2 58 Bytes de Cabeceras, 12 son IAX2 Header. 8 bytes Miniframes, 4 bytes para cada Payload. 58+8+40 = 106 Bytes de la trama completa a 42.4 Kbps. 20 Bytes  8 Kbps, 106 Bytes  42.4 Kbps. 42.2 Kbps carga dos llamadas: 21.1kbps por llamada. Agregando 1 Miniframe (4 bytes) a una llamada dan: 82Bytes  32.8 Kbps. 42.4-32.8 = 9.6Kbps por llamada adicional a partir de la 2da.

106. IAX2 Re cálculo de BW para las troncales luego de reducción IAX2: La primera llamada usa el BW completo 31.2Kbps. La segunda usa el incremento 9.6Kbps, etc. B1 (11 Lineas): 31.2 + (11-1) *9.6Kbps = 127.2 Kbps B2 (8 Lineas): 31.2 + (8-1) *9.6Kbps = 98.4 Kbps

107. Aumento del Voice Payload La solución a simple vista debería ser aumentar el tamaño del Payload de Voz: Evita que se agreguen cabeceras. Transmite en una misma trama mayor información. Aumenta considerablemente la vulnerabilidad a la latencia. Reduce el consumo de BW: Siguiendo los cálculos realizados anteriormente: Payload de Voz con 60Bytes. BW: 16.05 Kbps con 138 Bytes(Payload+Headers)

108. Aumento del Voice Payload

109. Aumento del Voice Payload En Asterisk se puede cambiar el tamaño usando la variable de canal ALLOW. allow = ulaw:30

110. DUNDi Distributed Universal Number Discovery

111. DUNDi Sistema P2P que permite localizar gateways para servicios telefónicos. No hay autoridad central que se encargue de la administración. Es completamente distribuido por su naturaleza P2P. Se puede considerar como un directorio telefónico.

112. DUNDi en Asterisk: dundi.conf [general] port=4520 ; puerto mediante el cual se comunica el protocolo dundi entityid=00:0C:29:0C:AB:C2 ; identificador de mi Asterisk en la nube dundi, MAC ; de la tarjeta de red eth0 cachetime=5 ; Tiempo que permanece en cache la ruta para ir a las extensiones ; aprendidas mediante dundi ttl=12 ; Máx. No. de saltos que se harán buscando el destino autokill=yes ; si al preguntar a un par, el ACK tarda más de 2 segundos, se cancela la búsqueda ; a través de ese peer; es útil cuando no está activo el peer o cuando hay una conexión mala hacia el peer

113. Contextos DUNDi Definen que contextos de extensions.conf serán accesados por DUNDi. nombre_contexto => contexto_extensions,peso,proto,destino[,opciones]] nombre_contexto: Nombre del contexto al que se hace referencia en una petición dundi. contexto_extensions: Nombre del contexto en el extensions.conf, donde se buscarán los números que son solicitados en la nube dundi. peso: Deberá ser 0 en caso de que nuestro conmutador publique directamente los números, en caso contrario, deberá tener el valor del número de saltos que necesita para llevar al destino. proto: Cualquiera de los protocolos IP (sip, iax,323) con el cual el peer remoto se debe comunicar con nosotros. destino: Es la información que se entrega al peer para que pueda llegar al número que está marcando.

114. Contextos DUNDi opciones: Pueden ser varios argumentos los cuales indican el comportamiento que se tendrá cuando no tengamos nosotros el número que se está solicitando. nounsolicited . No se permiten llamadas que no sean solicitadas. nocomunsolicited . No se permiten llamadas comerciales que no sean solicitadas. nopartial . No se permiten búsquedas para patrones parciales. residential, comercial, mobile . Le indica a los pares qué tipo de números son los que se están publicando a través de este contexto.

115. Autenticación en DUNDi Los peers se autentican mediante llave pública/privada. cd /var/lib/asterisk/keys astgenkey -n dundi_ext_44xx yum -y install php cp dundi_ext_44xx.pub /var/www/html service httpd start wget -c http://132.248.175.90/dundi_principal.pub CLI>reload res_crypto.so CLI>reload pbx_dundi.so CLI>dundi lookup 4400@priv