asterisk

UNIVERSIDAD SIMÓN BOLÍVAR

Decanato de Estudios Profesionales

Coordinación de Electrónica

Propuesta de Implementación de un Servidor “Proxy”

SIP para el Enrutamiento de Voz sobre IP.

Por

BENITEZ DAZA, Jessica

GONZÁLEZ CLAREMBAUX, Valentina Sofía

Sartenejas, febrero 2007

- ii -




Propuesta de Implementación de un Servidor “Proxy”

SIP para el Enrutamiento de Voz sobre IP.

Por



Realizado en la empresa CANTV con la Asesoría de:

Tutor Académico: BADRA, Renny

Tutor industrial: PADRÓN, Ivan

INFORME FINAL DE

CURSOS EN COOPERACIÓN TÉCNICA Y DESARROLLO SOCIAL

Presentado ante la Ilustre Universidad Simón Bolívar

como requisito parcial para optar al título de

Ingeniero Electrónico


- iii -




Propuesta de Implementación de un Servidor Proxy SIP

para el Enrutamiento de Voz sobre IP. INFORME FINAL DE CURSOS EN COOPERACIÓN TÉCNICA Y DESARROLLO SOCIAL

presentado por



RESUMEN

El objetivo principal de esta pasantía fue la elaboración de una propuesta de implementación

de un Servidor “Proxy” SIP, para el Enrutamiento de Voz sobre IP, incorporando una ejemplificación en

la cual se representaron las funcionalidades básicas de un “Proxy”, escalable y editable. Para

alcanzarlo, se necesitó de una investigación teórica, la elección de las herramientas adecuadas para la

misma, la configuración de cada una de forma independiente para darle una estructura adecuada, al

igual que la realización de las pruebas pertinentes para asegurar así su correcto funcionamiento. El

servidor SIP está desarrollado sobre el software libre OpenSER, permitiendo la manejabilidad del

mismo. Además se desarrolló una herramienta Web para poder administrar el servicio de una manera

fácil y rápida sin tener que acceder a la consola para modificar la configuración del servicio, así como

también dos manuales uno técnico y otro para usuario donde se mostró cómo manejar de una manera

más rápida y eficiente las herramientas desarrolladas.

PALABRAS CLAVES:

VoIP, Proxy, SIP, enrutamiento, OpenSER, software, softphone, servidor, petición.

Aprobado con mención:_______

Postulado para el premio:_______


- iv -

DEDICATORIA

A mis padres, por ser mi soporte y por su amor incondicional,

a mis hermano Jonathan, por todo el apoyo brindado,

a mi hermana Jacqueline, por ser la alegría de mis días,

a mis abuelos, por apoyarme siempre.

Gracias a todos. Los quiero mucho.

Jessica

A mis abuelos, ejemplo de orgullo, constancia y rectitud,

a mis padres por su amor y apoyo incondicional,

a mi hermano Daniel, por ser mi ejemplo a seguir,

a mi hermano Leopoldo por estar conmigo en todo momento.

Los quiero.

Valentina

- v -

AGRADECIMIENTOS

A Dios por ser nuestro guía y estar presente con nosotras.

A nuestros padres, de quienes siempre estaremos orgullosos, gracias por brindarnos todo su

amor, por estar cuando más los necesitamos, por su paciencia y todo su cariño. Gracias por existir.

A nuestros hermanos. Gracias por siempre estar allí y compartir los buenos y los malos

momentos con nosotras.

A nuestros tutores, Ing. Iván Padrón e Ing. Renny Badra, por su apoyo y seguimiento durante

el desarrollo del proyecto.

Al Ing. Jesús Tovar, por su ayuda y comprensión en el desenvolvimiento del proyecto.

A los ingenieros Carlos Camacho, Jesús Tovar, Iván Padrón, Pedro Peña y Maurizio Trombetta

por habernos recibido con cariño y haber estado en todo momento.

A nuestros amigos, Gervasio Briceño, Miguelangel Faria, Idania Gorrochategui, Verónica

Jaraba, Arquímedes López, Silvia Mendez y Keith Vergara, por los momentos compartidos a pesar de

encontrarnos en una nueva etapa.

A nuestros profesores, que con su labor del día a día nos ayudaron a enfrentar los retos que se

nos presentaron en este proyecto y los que nos surgirán más adelante.

A todas aquellas personas que de una u otra forma nos ayudaron a realizar este proyecto.

Muchas Gracias.

- vi -

ÍNDICE

RESUMEN .................................................................................................................................... iii PALABRAS CLAVES ..................................................................................................................... iii DEDICATORIA ............................................................................................................................ iv AGRADECIMIENTOS....................................................................................................................v ÍNDICE ........................................................................................................................................ vi ÍNDICE DE FIGURAS .................................................................................................................viii ÍNDICE DE TABLAS .....................................................................................................................x GLOSARIO DE TÉRMINOS Y ABREVIATURAS ........................................................................... xi GLOSARIO DE TÉRMINOS Y ABREVIATURAS ........................................................................... xi CAPÍTULO I: INTRODUCCIÓN ....................................................................................................1

1.1. Justificación....................................................................................................................1 1.2. Objetivos........................................................................................................................1

1.2.1.Objetivo General.........................................................................................................1 1.2.2.Objetivos Específicos...................................................................................................2

CAPITULO II MARCO ORGANIZACIONAL ..................................................................................3 2.1. Misión ............................................................................................................................3 2.2. Visión.............................................................................................................................3 2.3. Reseña histórica .............................................................................................................3 2.4. Empresas filiales de CANTV .............................................................................................4 2.5. Estructura Organizativa ...................................................................................................4

CAPÍTULO III: MARCO TEÓRICO ...............................................................................................7 3.1. Evolución de los Sistemas Telefónicos ..............................................................................7 3.2. Redes Telefónicas ...........................................................................................................8 3.3. Señalización telefónica ....................................................................................................9 3.4. Funciones de señalización telefónica ................................................................................9

3.4.1 Estructura de señalización .........................................................................................10 3.4.2.Evolución de las Redes Telefónicas ............................................................................11

3.4.2.1.POTS.........................................................................................................11 3.4.2.2.PSTN.........................................................................................................12 3.4.2.3.NGN..........................................................................................................12

3.5. Sistema de Señalización R2 ...........................................................................................13 3.6. Sistema de Señalización Nº 7.........................................................................................13

3.6.1 Puntos de Señalización..............................................................................................14 3.6.2 Protocolo SS7 ...........................................................................................................15

3.7. Redes de Computadora .................................................................................................16 3.7.1 Topologías de Red (Física y lógica) ............................................................................16 3.7.2.Modelos de Redes.....................................................................................................18 3.7.3.El protocolo IP..........................................................................................................20 3.7.4.El protocolo TCP .......................................................................................................21 3.7.5.El protocolo UDP ......................................................................................................22

3.8. Elementos de redes.......................................................................................................22 3.8.1.“Hubs” .....................................................................................................................22 3.8.2.“Switches”................................................................................................................22 3.8.3.“Routers” .................................................................................................................23 3.8.4.“Gateways” ..............................................................................................................23 3.8.5.Ordenadores y Servidores .........................................................................................23 3.8.6.VPN .........................................................................................................................23

3.9. Sistema operativo Linux. Fedora Core 4..........................................................................24 3.10. Señalización Telefónica en NGN y VoIP.......................................................................24

3.10.1.VoIP ......................................................................................................................25 3.10.2.Protocolos VoIP ......................................................................................................26 3.10.3.Tráfico Telefónico ...................................................................................................31

- vii -

3.10.4.Calidad de Servicio en las redes VoIP .......................................................................32 3.11. Resumen entre sistema de telefonía tradicional o básico y paquetizado (VoIP). ............33 3.12. Herramientas para VoIP ............................................................................................34

CAPÍTULO IV: METODOLOGÍA..................................................................................................38 4.1. Revisión Técnica ...........................................................................................................38 4.2. Investigación y selección de las herramientas .................................................................38

4.2.1.Aplicaciones .............................................................................................................38 4.2.2.Sistema Operativo ....................................................................................................39 4.2.3.Servidor ...................................................................................................................39 4.2.4.Herramientas complementarias .................................................................................39

4.3. Evaluación de la aplicación ............................................................................................40 4.4. Instalación de las herramientas y configuración de la Aplicación ......................................40

4.4.1.Software ..................................................................................................................40 4.4.2.Aplicación Web .........................................................................................................43 4.4.3.Manuales Técnico y Web...........................................................................................43

4.5. Verificación y Pruebas. ..................................................................................................43 4.5.1.Funcionamiento de la aplicación ................................................................................44 4.5.2.Página Web..............................................................................................................44 4.5.3.Pruebas de tráfico.....................................................................................................44

CAPÍTULO V: RESULTADOS ......................................................................................................45 5.1. Selección de las herramientas........................................................................................45

5.1.1.OpenSER..................................................................................................................47 5.1.2.Dreamweaver...........................................................................................................48 5.1.3.Ngrep ......................................................................................................................49 5.1.4.MySQL Front y Putty:................................................................................................49 5.1.5.SIPp ........................................................................................................................49

5.2. Archivo de Configuración...............................................................................................49 5.2.1.Diseño .....................................................................................................................50 5.2.2.Posibles Escenarios para la Ubicación del OpenSER dentro de la Red de CANTV. ..........55 5.2.3.Pruebas de Configuración..........................................................................................57

5.3. Página Web ..................................................................................................................80 5.3.1.Diseño .....................................................................................................................80 5.3.2.Modificación del archivo de configuración de OpenSER ...............................................82

CAPÍTULO VI: CONCLUSIONES Y RECOMENDACIONES .........................................................86 REFERENCIAS ............................................................................................................................88 ANEXO 1: Manual de OpenSER .................................................................................................91 ANEXO 2. Manual SERWeb Administrador ............................................................................ 170 ANEXO 3. Trazas de una llamada desde un teléfono IP hacia un teléfono en la PSTN conlgando éste. ....................................................................................................................... 199 ANEXO 4. Trazas de una llamada desde un teléfono IP, colgando éste, hacia un teléfono en la PSTN..................................................................................................................................... 205 ANEXO 5. Trazas de una llamada desde un teléfono IP hacia un teléfono celular, colgando éste. ......................................................................................................................................... 210 ANEXO 6. Trazas de una llamada desde un teléfono IP, colgando éste, hacia un teléfono celular. ..................................................................................................................................... 215

- viii -

ÍNDICE DE FIGURAS

Figura 1. Organigrama Primario .......................................................................................................5 Figura 2. Organigrama Secundario ...................................................................................................5 Figura 3. Organigrama Terciario.......................................................................................................6 Figura 4. Red con topología de malla. ..............................................................................................7 Figura 5. Red con topología Jerárquica.............................................................................................8 Figura 6. Red Telefónica..................................................................................................................8 Figura 7. Modo de operación asociado............................................................................................10 Figura 8. Modo de operación cuasi-asociado ...................................................................................11 Figura 9. Generación PSTN ............................................................................................................12 Figura 10. Generación NGN ...........................................................................................................13 Figura 11. Puntos de Señalización en SS7 [16] ..............................................................................14 Figura 12. Modelo OSI y Modelo del Protocolo SS7..........................................................................15 Figura 13. Topología de Red en BUS ..............................................................................................16 Figura 14. Topología de Red en ANILLO .........................................................................................17 Figura 15. Topología de Red en ESTRELLA .....................................................................................17 Figura 16. Capas del modelo OSI. ..................................................................................................18 Figura 17. Capas del modelo TCP/IP ..............................................................................................19 Figura 18. Clases de Direcciones IP................................................................................................21 Figura 19. Campos del Protocolo TCP .............................................................................................21 Figura 20. Campos del Protocolo UDP ............................................................................................22 Figura 21. Elementos y Protocolos de una Red VoIP........................................................................25 Figura 22. Protocolos de una red VoIP ...........................................................................................26 Figura 23. Estructura de una red de señalización H.323...................................................................28 Figura 24. Estructura de una red de señalización SIP ......................................................................29 Figura 25. Lógica de envío de los mensajes SIP para las pruebas de tráfico......................................47 Figura 26. Error de compilación del archivo de configuración ...........................................................50 Figura 27. Diagrama General del Archivo de configuración...............................................................50 Figura 28. Estructura general del Archivo de Configuración de OpenSER ..........................................51 Figura 29. Proceso de revisión y enrutamiento por reglas. ...............................................................52 Figura 30. Enrutamiento por URI ...................................................................................................53 Figura 31. Enrutamiento por FROM ................................................................................................53 Figura 32. Enrutamiento por FROM ................................................................................................53 Figura 33. Enrutamiento por FROM ................................................................................................54 Figura 34. Enrutamiento por FROM ................................................................................................54 Figura 35. Posible escenario de Ubicación del OpenSER dentro de la Red de CANTV .........................55 Figura 36. Posible escenario de Ubicación del OpenSER dentro de la Red de CANTV .........................56 Figura 37. Posible escenario de Ubicación del OpenSER dentro de la Red de CANTV .........................57 Figura 38. Esquema general de Pruebas.........................................................................................58 Figura 39. Diagrama de conexión para la prueba de llamadas salientes. ...........................................59 Figura 40. Flujo de Mensajes entre teléfono IP y número en la PSTN (éste cuelga) ...........................60 Figura 41. Flujo de Mensajes entre teléfono IP (éste cuelga) y número en la PSTN ...........................60 Figura 42. Flujo de Mensajes entre teléfono IP y número celular (éste cuelga) .................................61 Figura 43. Flujo de Mensajes entre teléfono IP (éste cuelga) y celular..............................................61 Figura 44. Partes de pantalla de pruebas........................................................................................63 Figura 45. Resultados UAC Prueba 1 ..............................................................................................64 Figura 46. Resultados UAC Prueba 2 ..............................................................................................65 Figura 47. Consumo de memoria del Servidor .................................................................................66 Figura 48. Resultados UAC Prueba 3 ..............................................................................................67 Figura 49. Consumo de memoria del Servidor .................................................................................68 Figura 50. Resultados UAC Prueba 4 ..............................................................................................69 Figura 51. Consumo de memoria del Servidor .................................................................................70 Figura 52. Resultados UAC Prueba 5 ..............................................................................................71

- ix -

Figura 53. Consumo de memoria del Servidor .................................................................................72 Figura 54. Resultados UAC Prueba 6 ..............................................................................................73 Figura 55. Consumo de memoria del Servidor .................................................................................74 Figura 56. Resultados UAC Prueba 7 ..............................................................................................75 Figura 57. Resultados UAC Prueba 8 ..............................................................................................76 Figura 58. Resultados UAC Prueba 9 ..............................................................................................77 Figura 59. Consumo de Memoria del Servidor. ................................................................................78 Figura 60. Resultados UAC Prueba 10 ............................................................................................79 Figura 61. Consumo de Memoria del Servidor. ................................................................................80 Figura 62. Diagrama de las funciones de la página Web. .................................................................81 Figura 63. Opciones para el administrador en la página web............................................................82 Figura 64. Página para la modificación del archivo de configuración .................................................83 Figura 65. Página Principal de Enrutamiento ...................................................................................84 Figura 66. Opciones para un enrutamiento en específico .................................................................85

- x -

ÍNDICE DE TABLAS

Tabla 1. Comparación entre sistemas telefónicos. .................................................................34 Tabla 2. Comparación entre SER, OpenSER y Asterisk ...........................................................37 Tabla 3. Plataformas soportadas por Ngrep [39] ...................................................................49 Tabla 4. Tabla deresultados obtenidos de llamadas realizadas ...............................................59 Tabla 5. Pruebas con SIPp...................................................................................................62

- xi -

GLOSARIO DE TÉRMINOS Y ABREVIATURAS

ABA: Acceso a Banda Ancha.

AbaVoz: Servicios de Voz a través de conexión de Banda Ancha Aba de CANTV.

ADSL: “Asymmetric Digital Subscriber Line”, Línea de Subscriptor Digital Asimétrica.

ATA: “Access Terminal Adapter”, Adaptador Terminal de Acceso.

ATM: “Asynchronous Transfer Mode”, Modo de Transferencia Asíncrono de frames o marcos de datos.

Frame Relay: forma simplificada de tecnología de conmutación de paquetes que transmite una

variedad de tamaños de marcos (“frames”) para datos

B2BUA: “Back-To-Back User Agent”, agente de usuario encargado de establecer y terminar una

llamada entre dos usuarios SIP.

CANTV: Compañía Anónima Nacional de Teléfonos de Venezuela.

CDR: “Call Detail Record”, Record Detallado de Llamadas.

Codec: Código usado en la codificación y en la decodificación.

CSMA: “Carrier Sense Multiple Access”, Acceso Múltiple por Detección de Portadora.

DHCP: “Dynamic Host Control Protocol”, Protocolo de Configuración Dinámica de Servidores.

DNS: “Domain Name Server”, Servidor de Nombres de Dominio.

DSL: “Digital Subscriber Line”, Línea de Abonado Digital.

DTMF: “Dual Tone MultiFrecuency”, Protocolo de Señalización multifrecuencial en tonos duales.

E1 Carrier: Portadora E1.

H.323: es una recomendación del ITU-T (International Telecommunication Union), que define los

protocolos para proveer sesiones de comunicación audiovisual sobre paquetes de redes una parte de

la serie de protocolos H.32x, los cuales también dirigen las comunicaciones sobre RDSI, RTC o SS7 [1].

HTML: “Hypertext Markup Language”, Lenguaje de formato de Hipertexto.

HTTP: “Hypertext Transfer Protocol”, Procotolo de Transferencia de Hipertexto.

IP: “Internet Protocol”, Protocolo Internet.

IPv6: “Internet Protocol version 6”, Protocolo de Internet versión 6.

ISDN: “Integrated Services Digital Network”, Red Digital de Servicios Integrados.

ISDN-UP: “Integrated Services Digital Network - User Part”, Red Digital de Servicios Integrados, parte

de Usuario.

ISP: “Internet Service Provider”, Proveedor de Servicios de Internet

ITU: “International Telecommunications Union”, Unión Internacional de Telecomunicaciones.

IVR: “Interactive Voice response”, Respuesta de Voz Interactiva.

“Jitter”: en VoIP, “jitter” es la variación en el tiempo de llegada entre paquetes, causado por la

congestión en la red, sincronismo o cambio de rutas [2].

LAN: “Local Area Network”, Red de Área Local.

- xii -

“Login”: es el identificador de usuario, requerido al acceder a un sistema operativo. También es

conocido como nombre o identificador del usuario [3].

MAC: “Media Access Control”, Control de Accesos al Medio.

MAN: “Metropolitan Area Network”, Red de Área Metropolitana.

MGC: “Media Gateway Controler”, Controlador de puerta de enlace de media.

MTP: “Message Transfer Part”, Protocolo de Transferencia de Mensajes.

MySQL: sistema de gestión de base de datos.

NGN: “Next Generation Networks”, Redes de Próxima Generación.

OSI: “Open Systems Interconnections”, Interconexión de Sistemas Abiertos.

PABX: “Private Automatic Branch eXchange”, servicio de un numero virtual que administra las llamadas

entrantes a dos o más líneas telefónicas [4].

PBX: “Private Branch Exchange”, servicio de un numero virtual que administra las llamadas entrantes a

dos o más líneas telefónicas [4].

PCM: “Pulse Code Modulation”, Modulación por impulsos codificados.

PHP: “Personal Home Page”, actualmente “Hypertext Pre-procesor”.

POTS: “Plain Old Telephone System”, Sistema de telefonía simple y antiguo.

“Proxy”: sirve para permitir el acceso a Internet a todos los equipos de una organización cuando sólo

se puede disponer de un único equipo conectado (una única dirección IP).

PSTN: “Public Switched Telephone Network”, Red de Telefonía Pública Conmutada.

RAS: “Registration Administration and Status”, Protocolo de Registro, Administración y Estatus.

RFI: “Request For Information”, Documento para Demanda de Información.

RTCP: “Real Time Control Protocol”, Protocolo de Control a Tiempo Real.

SBC: “Session Border Controller”, Controlador de Sesiones de Borde.

SCC: Señalización por Canal Común.

SCCP: “Signaling Connection Control Part”, Protocolo de Control de Conexión y Señalización.

SCTP: “Simple Control Transfer Protocol”, Protocolo Simple para Control de Transporte.

SDP: “Session Description Protocol”, Protocolo de Descripción de Sesiones.

Servicios TriplePlay: es la comercialización de los servicios telefónicos de voz junto al acceso de banda

ancha, añadiendo además los servicios audiovisuales.

SIP: “Session Initiation Protocol”, Protocolo de Inicialización de Sesiones

“Socket”: punto de fin en el protocolo de red IP.

SS7: “Signaling System 7”, Sistema de Señalización Número 7.

SSH: “Secure SHell”, permite el acceso a máquinas remotas a través de una red.

STP: “Signaling Transference Points”, nodos de transferencia de señalización.

TCAP: “Transaction Capabilities Application Part”, Protocolo de Aplicación para Capacidades de

Transacción.

- xiii -

TCP: “Transmition Control Protocol”, Protocolo de Control de Transmisión.

TDM: “Time Division Multiplexing”, Multiplexación por División de Tiempo.

TDMA: “Time Division Multiple Access”, Acceso Múltiple por Division de Tiempo.

UA: “User Agent”, Agente de Usuario.

UAC: “User Agent Client”, Cliente de Agente de Usuario.

UAS: “User Agent Server”, Servidor de Agente de Usuario.

UDP: “User Datagram Protocol”, Protocolo orientado a Datagramas, usado para la transmisión de

paquetes de datos sobre alguna red.

VLAN: “Virtual Local Area Network”, Red Virtual de Área Local.

VoIP: “Voice over IP”, Voz sobre IP.

VPN: “Virtual Private Network”, Red Privada Virtual.

WAN: “Wide Area Network”, Red de Área Amplia.

XMPP: “Extensible Messaging and Presence Protocol”, Protocolo abierto y extensible basado en XML

ideado para mensajería instantánea.

CAPÍTULO I: INTRODUCCIÓN

El presente informe tiene como finalidad exponer las actividades realizadas durante el periodo

de pasantía en la Empresa Compañía Anónima Nacional Teléfonos de Venezuela (CANTV), las cuales

nos permitieron poder aplicar muchos de los conocimientos adquiridos a lo largo de la carrera.

En el Primer Capítulo se describe la Justificación de la realización del proyecto. Además, se

expone el Objetivo General, que como en todo proyecto es fundamental ya que es el que dicta los

lineamientos del mismo, junto con los Objetivos Específicos. En el Segundo Capítulo se hace una breve

Reseña Histórica de la empresa, y se da una explicación sobre la estructura Organizativa de la Misma.

En el Tercer Capítulo se hace una descripción de los fundamentos teóricos referentes a los

Sistemas Telefónicos Tradicionales, la Evolución de los Sistemas Telefónicos, así como la señalización

telefónica en VoIP, destacándose el Protocolo de Señalización SIP que fue el que se utilizó. Todos

estos conocimientos resultaron primordiales para el desarrollo de la pasantía.

El Cuarto Capítulo explica de forma detallada la metodología utilizada en el desarrollo del

proyecto. Se presentan las fases del mismo, conformadas cada una por un conjunto de actividades.

Por último, en el Capítulo Cinco se muestran los resultados obtenidos, así como el conjunto de pruebas

realizadas a cada una de las aplicaciones.

1.1. Justificación

La tecnología de las redes de paquetes representa una evolución en las telecomunicaciones.

En un sistema de Voz sobre IP se pueden unificar servicios de comunicaciones de voz, datos y video a

través de un sola red; esto junto a una serie de beneficios económicos sustentan la actual migración

que está llevando a cabo la Compañía Anónima Nacional Teléfonos de Venezuela (CANTV) de sus

redes conmutadas (TDM) a redes de paquetes (VoIP).

Debido a esto, CANTV necesita tener el completo dominio de una herramienta que le permita

realizar el enrutamiento de llamadas. Aunque en el mercado existen soluciones de este tipo, sus

desarrollos son cerrados por lo que limitan la configuración, escalabilidad y mejoras a las ofrecidas por

el proveedor. Es por ello que CANTV ha decidido emprender el desarrollo de una herramienta propia

que sirva para el enrutamiento de VoIP, garantizando así que su personal interno pueda reconfigurar

el sistema sin necesidad de depender de proveedores.

1.2. Objetivos

1.2.1. Objetivo General

El objetivo general de este trabajo es elaborar una propuesta de implementación de un

Servidor Proxy SIP, para el Enrutamiento de Voz sobre IP, que incorpore una ejemplificación

representando las funcionalidades básicas de un Proxy, la cual pueda ser escalada o modificada.

- 2 -

1.2.2. Objetivos Específicos Los objetivos específicos de este trabajo son:

• Describir los fundamentos teóricos de los sistemas telefónicos y el Protocolo de

Señalización SIP.

• Analizar las necesidades de CANTV referentes al enrutamiento de VoIP.

• Identificar las distintas soluciones existentes en el mercado y de software libre que se

encuentren disponibles y establecer una comparación entre ellas.

• Definir la ejemplificación a desarrollar a fin de garantizar que la misma represente

adecuadamente las funcionalidades básicas de un Servidor Proxy.

• Definir las funcionalidades a incluir en la Aplicación Web.

• Elaborar las pruebas de funcionamiento tanto del Servidor Proxy, como de la

Aplicación Web.

• Elaborar el manual de configuración y operación del servidor Proxy, así como el de la

aplicación Web.

CAPITULO II MARCO ORGANIZACIONAL

2.1. Misión

La misión de la empresa es mejorar la calidad de vida de la gente en Venezuela al proveer

soluciones de comunicaciones que exceden las expectativas de sus clientes.

2.2. Visión La visión de la empresa es ser el proveedor preferido de servicios integrales de

telecomunicaciones de Venezuela, y satisfacer plenamente las necesidades específicas de sus clientes,

siempre bajo exigentes patrones de ética y rentabilidad.

2.3. Reseña histórica

Cantv es la empresa pionera en proveer servicios de telecomunicaciones en Venezuela.

Actualmente, la gama de productos y servicios abarcan desde interconexión hasta comunicaciones de

larga distancia nacional e internacional.

Fue fundada en 1930 por Félix A. Guerrero, comerciante de profesión, el cuál obtiene una

concesión (por un período inicial de 35 años con miras a una extensión de 20 años más) del Ministerio

de Fomento para construir y explotar una red telefónica en el Distrito Federal y los estados del país.

Los términos de la Concesión establecen que Cantv es el proveedor exclusivo de servicios de

comunicación locales, de larga distancia nacional e internacional hasta noviembre del año 2000.

En 1950, el Estado compra la totalidad de las acciones de las empresas particulares e inicia el

proceso de nacionalización que culmina en 1973 adquiriendo la última de las empresas ubicada en San

Fernando de Apure.

En consecuencia a los problemas económicos y de atraso tecnológico, en 1991 se efectúa la

licitación internacional de 40% de las acciones de la empresa, en el marco de su privatización. Como

resultado, en diciembre de ese año, el Consorcio Venworld Telecom (incluye a la empresa

estadounidense GTE, Telefónica Internacional de España, La Electricidad de Caracas, Banco Mercantil y

AT&T; también de Estados Unidos), adquiere el control esas acciones.

Como parte de su programa de expansión y mejoramiento de la red de telecomunicaciones,

Cantv ha incrementado sus líneas de acceso de aproximadamente 1,6 millones en 1991 a 2,9 millones

al cierre del segundo trimestre de 2005. El porcentaje de líneas digitales en servicio ha aumentado de

15,2% en 1991, a 83% en la actualidad.

Además de su expansión por toda Venezuela, CANTV establece conexiones a través de cables

submarinos de forma de ofrecer todos los medios de transmisión con estándares internacionales de

calidad.

- 4 -

2.4. Empresas filiales de CANTV En 1992 nace Movilnet como empresa filial de Cantv, dedicada a prestar servicios de telefonía

móvil en Venezuela, logrando un crecimiento importante gracias al lanzamiento de productos

innovadores.

Cantv Servicios es creada en 1996 como filial de Cantv, con la finalidad de ofrecer servicios de

valor agregado para el mercado venezolano, específicamente, acceso a Internet con tecnología

avanzada y la confiabilidad de la infraestructura de telecomunicaciones más completa del país. En

1999 Cantv Servicios pasa a ser Cantv.net. En Venezuela fue la primera compañía que presta servicio

basado en tecnología ADSL es CANTV, a través del servicio ABA (Acceso a Banda Ancha). El cual surge

para satisfacer la necesidad de muchos clientes naturales y jurídicos, cuyos requerimientos van más

allá de lo que un dial-up puede ofrecer.

En 1953 se crea la empresa Guía, C.A. de Publicidad que se encargaría de publicar el directorio

telefónico oficial de Venezuela. El 13 de octubre de 1975 se registra una nueva empresa bajo el

nombre de C.A. Venezolana de Guías, Caveguías. En septiembre 1992 se privatiza Caveguías y se

produce el relanzamiento del producto, con reforma estatutaria y composición accionaria (80% Cantv y

20% Grabados Nacionales), lo que generó una nueva imagen y conllevó a la reorganización de la

empresa.

En el 2001 Cantv inicia el proceso de integración corporativa con Movilnet, Cantv.net y

Caveguías, consolidando las unidades de apoyo para prestar servicios corporativos y unificando los

conceptos de imagen gráfica de Cantv, Movilnet y Cantv.net, pudiendo así ampliar su visión, unir sus

fortalezas y seguir prestando excelentes servicios a nivel nacional e internacional de una forma mas

comprometida con el país [5].

2.5. Estructura Organizativa En el organigrama primario, Figura 1, se pueden apreciar las gerencias generales dependientes

de la Gerencia de Relaciones e Inversiones Venezolanas y Servicios como la Gerencia General de

Consultoría Jurídica, Organización y Recursos Humanos, Asuntos Regulatorios, Planificación y Finanzas,

Mercadeo Corporativo y Comunicaciones y Asuntos Públicos.

- 5 -

Figura 1. Organigrama Primario

El resto de las gerencias incluyendo la Gerencia General de Tecnología y Operaciones de

Telecomunicaciones Fijas, se encuentran por debajo de la Vicepresidencia Ejecutiva como se muestra

en el organigrama secundario de la Figura 2.

Figura 2. Organigrama Secundario

En el organigrama terciario, Figura 3, se puede observar el organigrama de la Gerencia

General de Tecnología y Operaciones de Telecomunicaciones Fijas donde se encuentra la Gerencia de

Presidencia

Vicepresidencia Ejecutiva

Gerencia General, Aseguramiento de

Ingresos

Gerencia General, Operadores de

Telecomunicaciones

Gerencia General, CANTV Empresas e

Instituciones

Gerencia General, del Centro de Servicio

Gerencia General, Tecnología y Operaciones

Telecomunicaciones Fijas

Gerencia General, Proyectos Mayores

Gerencia General, CANTV Mercados

Masivos

Presidencia

Gerencia General, Planificación y

Finanzas

Gerencia General, Organización y

Recursos Humanos

Gerencia General, Comunicaciones y Asuntos Públicos

Gerencia General, Mercadeo Corporativo

Gerencia General, Consultoría Jurídica

Gerencia General, Asuntos Regulatorios

Gerencia de Relaciones e Inversiones Venezolanas

y Servicios

Vicepresidencia Ejecutiva

- 6 -

Ingeniería y Construcción de Redes y a su vez se encuentra la Gerencia de Plataforma de Gestión de

Redes y Servicios, gerencia en la cual se desarrolló el proyecto planteado en este Libro.

Figura 3. Organigrama Terciario

Gerencia Ingeniería y Construcción de Redes

Gerencia, Nodos de Acceso

Gerencia, Proyectos de Ingeniería y

Construcción de Redes

Gerencia, Medios de Acceso e

Interconexión

Gerencia, Plataformas de Gestión de Redes y

Servicios

Gerencia, Nodos de Transporte

Gerencia General, Tecnología y Operaciones Telecomunicaciones Fijas

CAPÍTULO III: MARCO TEÓRICO

En este capítulo se expondrán una serie de fundamentos teóricos relacionados con los

sistemas telefónicos necesarios para comprender el desarrollo del proyecto. Se explica la evolución de

los sistemas telefónicos desde sus inicios, la señalización telefónica, así como el Sistema de

Señalización Número 7 (SS7) usado en la red PSTN, “Public Switched Telephone Network” o Red

Pública de Telefonía Conmutada de CANTV, terminando con las redes de nueva generación VoIP.

3.1. Evolución de los Sistemas Telefónicos En sus inicios la red telefónica se creó para lograr comunicaciones de voz a larga distancia. Las

primeras conexiones se establecieron directamente entre los usuarios pertenecientes a una misma red

(conexiones punto a punto), este tipo de interconexión hizo que el sistema telefónico se convirtiera en

una red completamente mallada. En un principio el número de abonados era muy pequeño, pero con

el paso del tiempo la evolución, mejoras hizo que el número de usuarios se incrementará, con lo cual

mantener ese tipo de topología de interconexión era insostenible debido a que el coste de un nuevo

usuario era proporcional al número de usuarios registrados en esos momentos a la red. En concreto, el

número de enlaces necesarios para N usuarios es N*(N-1)/2. En la Figura 4 se muestra una red con

topología de malla.

Figura 4. Red con topología de malla.

Esta problemática llevó a la red telefónica hacia un cambio a la topología de interconexión tipo

estrella entre los usuarios, que es la usada en la actualidad, y que consiste en que cada usuario se

conecta a una central urbana mediante un cable de cobre. Todos los usuarios que se encuentren

ubicados en la misma zona se conectan a la misma central urbana, logrando a través de la misma la

interconexión entre ellos. Para permitir a su vez la interconexión de estos usuarios con otros ubicados

en otra central, es necesario conectarse con una central regional. Estas centrales se conectan con

otras, hasta que toda central tiene acceso con cualquier otra, ya sea mediante una conexión directa

entre centrales, o a través de otra central usada como puente [6]. En la Figura 5 se muestra un

ejemplo de esta topología de sistema telefónico.

Usuario 2

Usuario 5

Usuario 4

Usuario 3

Usuario 1

Usuario 6

- 8 -

En las últimas décadas y hasta hace no más de unos cinco años, la red telefónica dominante a

nivel mundial estaba representada por la PSTN. Sin embargo, en estos últimos años han surgido

diversas alternativas que permiten la transmisión de voz a través de las redes de información, entre

ellas redes móviles, ISDN, Internet.

Figura 5. Red con topología Jerárquica

3.2. Redes Telefónicas Para poder formar la red PSTN de CANTV y lograr una conexión entre los abonados, todos los

teléfonos deben estar conectados a una Central Telefónica o conmutador de categoría 5, usando para

ello el tradicional cable par telefónico de cobre, también conocido como última milla.

Las conexiones entre centrales telefónicas se llaman rutas, las mismas disponen de numerosos

troncales los cuales determinan el número de llamadas simultáneas que pueden transitar por la misma.

Las centrales Tandem (Conmutadores Tandem de categoría 4) son aquellas que se utilizan como punto

alternativo de conexión, o que desvían el tráfico entre dos centrales telefónicas de la red [7]. En la

Figura 6 se muestra un ejemplo de red telefónica.

Figura 6. Red Telefónica

Central 1 Red de

interconexión Central 2

Usuario 1

Usuario 2

Usuario 3

Usuario 4

Usuario 5

Usuario 6 Usuario 12

Usuario 7

Usuario 8

Usuario 9

Usuario 10

Usuario 11 CSA de la

Central 1 CSA de la Central 2

Central Tandem

Central Telefónica

Abonados

Última milla

- 9 -

3.3. Señalización telefónica

Toda llamada telefónica requiere de un modelo de señalización para que ésta sea establecida y

mantenida. Desde que se descuelga el auricular para hacer una llamada, hasta que se cuelga, ocurren

ciertos eventos de señalización: el envío del número telefónico, el tono de ocupado de una llamada, la

información del número del que se llama, son algunos ejemplos de señalización.

Por señalización telefónica se entiende el conjunto de informaciones intercambiadas entre dos

puntos de la red telefónica que permiten efectuar operaciones de supervisión, direccionamiento,

gestión y mantenimiento de la red [8]. La señalización, por lo tanto, permite el intercambio de

información entre los componentes de una red telefónica para permitir la provisión y mantenimiento

del servicio.

Para poder completar una llamada, cada elemento involucrado en la red telefónica debe

cumplir la primera etapa de transmisión de señalización, una vez que las conexiones son completadas

exitosamente, los circuitos de voz permiten el intercambio de media entre los usuarios involucrados en

la llamada, por último la llamada se cerrará cuando alguna de las partes cuelgue el auricular.

3.4. Funciones de señalización telefónica

En la actualidad las redes de comunicaciones emplean sistemas de señalización sofisticados

para establecer, terminar llamadas, controlar y mantener la red. En la medida en que las redes se

vuelven más complejas crece el número de funciones que debe realizar el sistema de señalización. Las

siguientes funciones listadas por Martín [9] se encuentran entre las más importantes:

• Información audible por el suscriptor (tono de invitación a discar, tono de repique y tono de

ocupado) y para el usuario llamado (señal de repique).

• Transmisión del número marcado a las centrales que intentarán completar la conexión.

• Transmisión de información entre conmutadores indicando que una llamada ha terminado y

que el camino se puede desconectar.

• Una señal que realiza un ring del teléfono.

• Transmisión de información utilizada para la facturación.

• Información sobre el estado de los enlaces y equipos, a ser utilizada en el enrutamiento,

gestión y mantenimiento de la red.

En resumen, las funciones de señalización se pueden clasificar en supervisión,

direccionamiento, información de alerta, progreso de la llamada y gestión, constituyendo el soporte

básico para las funciones de mando y control de la red.

La señalización supervisoria o de línea se encarga de detectar la condición o cambio de estado

de las líneas telefónicas, tiene como función la asignación y liberación de recursos. Las señales de

direccionamiento representan un mecanismo para identificar a los usuarios que intentan comunicarse,

transmitiendo información como números telefónicos, y códigos de área. Los mensajes de alerta y

- 10 -

progreso proporcionan información del estado en que se encuentra la llamada como por ejemplo: tono

de congestión, tono de progreso, fuera de servicio, fuera del área de cobertura, tono de invitación a

marcar. Por último, los mensajes de gestión sirven para el mantenimiento y control de la red.

3.4.1. Estructura de señalización

Cuando se habla de señalización es importante destacar que la misma debe ser considerada en

dos contextos: la señalización entre un suscriptor y una central, y la señalización entre dos centrales.

La señalización entre un teléfono u otro dispositivo de suscriptor y la central final a la que éste

se vincula, es en un sentido amplio determinada por las características del dispositivo del suscriptor. La

señalización entre centrales se da por completo central-a-central; este tipo de señalización no sólo

tiene que ver con la gestión de llamadas del suscriptor, sino también con la gestión de la red misma;

es por ello que se requiere un repertorio más complejo de comandos, respuestas y parámetros.

La señalización entre centrales, puede dividirse entonces en Señalización por Canal Asociado

(SAC) en la cual la señalización y la voz viajan por un mismo canal y Señalización por Canal Común

(SCC), donde la señalización es enviada por un canal diferente a los canales por donde se transmite la

voz. En la red de señalización por canal común se pueden emplear a su vez, dos modos de operación.

En el modo de operación asociado, el canal de señalización está asociado con los canales que llevan la

información, en el sentido de que viajan por la misma ruta física, es decir, utilizando los mismos

troncales. Para el modo de operación cuasi-asociado se instalan los nodos adicionales de transferencia

(STP), creando así una red de señalización prácticamente independiente de la red de voz. Los

mensajes de señalización se envían entre dos o más enlaces (nodos de señalización, SP), haciendo

tránsito sobre uno o más puntos de transferencia de señalización. [10]. En las Figuras 7 y 8 se pueden

observar estos tipos de señalización por canal común.

Figura 7. Modo de operación asociado

Señalización

Conversación

SP SP

- 11 -

Figura 8. Modo de operación cuasi-asociado

3.4.2. Evolución de las Redes Telefónicas En los últimos años la arquitectura de las redes públicas de telecomunicaciones han ido

cambiando a pasos acelerados, trayendo consigo nuevos protocolos y tecnologías. Las razones de

estos nuevos cambios en la arquitectura de redes públicas son la aparición de nuevos servicios tales

como Internet, videoconferencia, Voz sobre IP, telefonía celular de banda ancha, entre otras [11].

La evolución de las redes telefónicas ha mejorado la forma como es transmitida la voz a través

de los troncales y la forma como son enviados los mensajes de señalización entre las centrales

telefónicas a pesar de que la infraestructura de última milla se ha mantenido básicamente igual.

3.4.2.1. POTS El viejo servicio telefónico POTS, “Plain Old Telephone System” se refiere al servicio de

telefonía estándar, ofrecido en los inicios de las redes telefónicas. La red te telefonía básica tenía como

premisa la transmisión de voz entre los usuarios. En los inicios, los sistemas realizaban la conmutación

mediante centrales telefónicas manuales, por lo que los operadores eran los que establecían un enlace

físico entre los dos teléfonos de los abonados.

Posteriormente, con los avances tecnológicos se implementaron los sistemas de marcado por

pulsos, éstos eran generados por el abonado que llamaba y descifrados por las centrales de

conmutación las cuales habían sustituido sus operadores por unos componentes electromecánicos

llamados relés [12].

Con el paso de los años, los avances permitieron digitalizar las líneas telefónicas, y gracias al

sistema de Multiplexación por División de Tiempo TDM, “Time Division Multiplexing”, y la Modulación

por Pulsos PCM, “Pulse Code Modulation”, la señal que llegaba a las centrales por parte del abonado

era transformada de analógica a digital, y posteriormente se volvía a transformar a analógica cuando

se iba a enviar al receptor. La razón de transformar la señal a digital era que este tipo de formato

permitía una transmisión más rápida entre las centrales. Esta nueva era de comunicación digital dejó

atrás muchas limitaciones existentes en las primeras redes analógicas y nos llevó a la conmutación de

circuitos. Mediante la modulación de pulsos, se muestrea a una tasa de 125µS, 8000

muestras/segundo lo que implica que las señales digitales se transmiten a 64 Kbps (DS0).

SP SP

STP STP

Señalización

Conversación

- 12 -

Para agrupar las señales se emplea la técnica TDM, este esquema presenta dos estándares. El

estándar Europeo, conocido como E1 presenta 32 ranuras de tiempo de las cuales 30 son usadas para

canales de voz, y 2 para sincronización y señalización. Por su parte, el estándar Americano T1 presenta

24 canales de voz y utiliza un bit para señalización.

3.4.2.2. PSTN

La Red Telefónica Pública Conmutada PSTN, “Public Switched Telephone Network”, es una red

con conmutación de circuitos tradicional, optimizada para comunicaciones de voz. La PSTN garantiza la

calidad de servicio QoS al dedicar el circuito a la llamada hasta que ésta culmina, independientemente

de si los participantes en la llamada hablan o están en silencio.

En esta generación de red de telefonía, los paquetes son transportados en un solo canal DS0,

mientras que la señalización se transmite por medio de unos paquetes separados en la red conmutada.

La señalización más usada es la SS7 basada en el Sistema de Señalización Nº7, y la carga útil es

transportada por la red digital TDM, de esta manera, la red PSTN es conformada por la red TDM para

voz y la red SS7 para señalización [13]. En la Figura 9 se muestra un ejemplo de la Red Telefónica

Pública Conmutada.

Figura 9. Generación PSTN

3.4.2.3. NGN

El término Redes de Nueva Generación NGN, “New Generation Networks”, se usa para definir

redes las cuales debido a su separación formal en diversas capas, y el uso de interfaces abiertas,

ofrece a los proveedores y abastecedores de servicios una plataforma que pueda desarrollarse paso a

paso, para desplegar y manejar servicios innovadores [14].

A diferencia de la red PSTN, este tipo de redes permite el transporte de voz, datos, video y fax

usando la tecnología de conmutación de paquetes IP. Tanto la señalización como la voz se transmiten

Router

Internet

PSTN

TDM

Central A Central B

Teléfono

Modem

Host

Conmutación de Circuitos

SS7 SS7 Tramas T1, E1

Tramas T1, E1

Fax Fax

Teléfono

- 13 -

en la misma red de conmutación de paquetes, adoptando para ello el concepto de VoIP. En la Figura

10 se puede observar la arquitectura de una red NGN.

Figura 10. Generación NGN

3.5. Sistema de Señalización R2

El sistema de señalización MFC/R2 fue usado originalmente para proveer señalización sobre el

cable de cobre tradicional a una velocidad mayor a la de marcación por pulso. Para hacer esto, se

continúa con el uso de voltaje DC como indicador de estado del teléfono, sin embargo, luego se

remplazó el marcado por pulsos digitales con el sistema de señalización por tonos duales. El generador

de pulsos y decodificador se necesita solamente durante el inicio de la llamada, y tal vez relocalizado al

establecimiento de la misma. El monitoreo del fin de la llamada es manejado simplemente por las

señales de línea.

Con el paso del tiempo se necesitó el uso de este sistema sobre circuitos análogos, por lo que

se introdujo el uso de un tono de 3825Hz donde su presencia o ausencia indicaba el estado de la línea.

Cuando se incluyeron los E1 también se necesitaron modificaciones usando rara vez la versión

análoga.

Los canales R2 pueden ser configurados para sólo permitir la entrada o la salida de llamadas,

sin embargo algunas variaciones permiten a cada canal manejar ambos casos. Este protocolo no evita

colisiones pero si las detecta y puede colocar la llamada por otro canal.

3.6. Sistema de Señalización Nº 7 El estándar Internacional SS7, “Signalling System Number 7”, de la ITU-T, “Internacional

Telecommunications Union Standarization Sector”, define los procedimientos y protocolos por los

cuales los elementos de las redes públicas de telefonía intercambian información sobre una red para

permitir la gestión, enrutamiento y control de las llamadas telefónicas, proporcionando una estructura

universal para la señalización de la red telefónica, mensajería, interconexión y mantenimiento de la

red.

Fax Fax

Teléfono Teléfono

Gateway Gateway

Internet

Red IP

Señales sobre IP

Señalización y Control de Llamadas

Host Host

- 14 -

En este estándar se definen las tres topologías de una red de señalización modo asociado,

cuasi-asociado y por canal común.

Actualmente, éste es el Sistema de Señalización más usado en las redes de Telefonía Pública.

Aunque todavía en muchas redes de telefonía todavía se usa el estándar de señalización R2, los

beneficios de la SS7 han impulsado a las redes telefónicas a usar dicho estándar.

3.6.1. Puntos de Señalización En una red SS7, cada nodo se conoce como Punto de Señalización (SP), éstos son los puntos

orígenes y destinos del tráfico de señalización. La arquitectura SS7 distingue tres diferentes puntos de

señalización: Puntos de Conmutación de Señal (SSP), Puntos de Transferencia de Señal (STP) y Puntos

de Control de Señal (SCP).

Los Puntos de Conmutación de Señal son conmutadores que originan, terminan o son un paso

intermedio en las llamadas. Son capaces de enviar mensajes de señalización a otros SSP para

establecer o liberar conexiones o realizan consultas a una base de datos (SCP) para determinar cómo

encaminar una llamada. Los Puntos de Transferencia de Señal son los encargados de recibir y dirigir

los mensajes de señalización hacia el destinatario correcto, por lo que desempeñan funciones de ruteo.

Los Puntos de Control de Señalización son entidades de la red que ofrecen una lógica complementaria,

utilizada para ofrecer servicios adicionales. Básicamente se trata de bases de datos que proveen

características avanzadas como por ejemplo, servicios a números gratuitos 800. [15]. En la Figura 11

se muestran los diferentes puntos de señalización en una red SS7, así como las relaciones entre ellos.

Figura 11. Puntos de Señalización en SS7 [16]

- 15 -

3.6.2. Protocolo SS7

El protocolo SS7 fue diseñado para facilitar las funciones de señalización así como mantener la

red sobre la cual se ofrecen los servicios. Se encuentra dividido en cuatro niveles y presenta

similitudes con el modelo OSI. En la Figura 12 se muestran los niveles que conforman el modelo SS7.

Figura 12. Modelo OSI y Modelo del Protocolo SS7

Los tres niveles más bajos lo ocupan el nivel de la transferencia de mensajes MTP “Message

Transfer Part”, la cual está compuesta por tres partes, que juntas son responsables de llevar un

mensaje desde su origen hasta su destino. La capa MTP-1 es equivalente al nivel Físico del Modelo

OSI. Define las características funcionales, eléctricas y físicas del enlace de señalización digital. Las

interfaces físicas definidas incluyen: E1 (2048 Kb/s, 32 canales de 64 Kb/s), DS-1 (1544 Kbps, 24

canales de 64Kbps), V.35 (64 Kbps), DS-0 (64 Kbps) y DS-0A (56 Kbps).

El nivel 2 de MTP es equivalente a la capa de Enlace del Modelo OSI. Tiene como función

asegurar la transmisión sin errores extremo a extremo de un mensaje a través del enlace de

señalización. Implementa control de flujo, validación de la secuencia de los mensajes y control de

errores. Cuando se produce un error en un enlace de señalización, el mensaje (o el conjunto de

mensajes) es retransmitido [17].

El nivel 3 de MTP es equivalente a la capa de Red del Modelo OSI. Proporciona enrutamiento

entre dos puntos de señalización de la red SS7. Tiene como función controlar el tráfico cuando ocurren

congestiones en la red, así como de re-enrutar tráfico para evitar enlaces y puntos de señalización

dañados.

En un nivel superior se presentan dos opciones: la Parte de Usuario ISUP, que es un protocolo

de señalización que provee servicios a aplicaciones ISUP, sin embargo también puede usarse en

aplicaciones que no sean de este tipo, y básicamente se ocupa de la iniciación y terminación de

llamadas telefónicas entre SSPs. Este protocolo es orientado a conexión. La segunda opción es el

Aplicación

Enlace de datos

Red

Presentación Sesión

Transporte

Nivel físico

Modelo OSI

MTP Nivel 1

MTP Nivel 2

MTP Nivel 3

S C C P

I S P

T C A P

O M A A S E

I S D N – U P

Modelo del Protocolo SS7

- 16 -

Protocolo de Control de Conexión de Señalización, SCCP que normalmente es un protocolo orientado

a no conexión, aunque puede usarse también en servicios orientados a conexión. Además tiene un

mecanismo de direccionamiento que le permite llevar a cabo la señalización entre dos puntos aún

cuando no conozcan la dirección del otro. Esto se conoce como Direccionamiento de Título Global.

El protocolo de Aplicación de Capacidades de Transacción, TCAP define el intercambio de

mensajes y protocolos empleados en los nodos para comunicarse entre aplicaciones. El envío de

peticiones y respuestas entre los distintos SSP y SCP son enviados sobre TCAP.

La parte de Operación, Mantenimiento y Administración, OMAP, suministra los protocolos de

aplicación para monitorear, coordinar y controlar todos los recursos de la red que hacen posibles las

comunicaciones basadas en SS7.

3.7. Redes de Computadora

Están formadas por un conjunto de computadoras y/o dispositivos acoplados mediante enlaces

físicos o inalámbricos que tienen como una de sus finalidades permitir a usuarios y/o procesos

(residentes en los equipos), compartir recursos e información lo más rápido posible de manera sencilla

y transparente para el usuario.

3.7.1. Topologías de Red (Física y lógica)

La topología de una red de computadoras especifica la forma en que están conectados los

elementos así como también la forma en que se encuentran configurados los equipos para permitirles

o no el acceso a ciertos recursos. Es posible tener conectadas computadoras en una misma red sin

tener acceso la una con la otra además también se pueden conectar remotamente dos computadoras

haciendo parecer que estuvieran una al lado de la otra, conectadas en una misma red.

• Topologías Físicas

La topología física de una red se refiere al patrón que forman los nodos conectados a la red,

sin tomar en cuenta los tipos de dispositivos, los métodos de conectividad o las direcciones en dicha

red [18].

Las topologías de red más comunes son: red en bus, donde cada computadora está conectada

a un segmento de cable lineal que recorre la red de un extremo al otro (ver Figura 13), red en anillo,

donde los nodos están unidos formando un círculo lógico (ver Figura 14) y red en estrella, siendo esta

la más antigua, donde las computadoras son conectadas a través de un dispositivo concentrador que

regula el paso de información entre las mismas (ver Figura 15) [19].

Figura 13. Topología de Red en BUS

- 17 -

Figura 14. Topología de Red en ANILLO

Figura 15. Topología de Red en ESTRELLA

• Topologías Lógicas

La topología lógica de una red define el comportamiento de los equipos para acceder al medio

compartido que los interconecta además de especificar el método que usan para comunicarse con el

resto de los nodos y la ruta que toman los datos de la red entre los diferentes nodos de la misma [19].

Hay dos formas principales de acceder a los medios, una de ellas es haciendo un uso ordenado del

medio dando un turno a cada equipo para transmitir por un tiempo determinado y luego éste pasa el

turno al próximo equipo. La otra forma de acceso es la que ha demostrado mayor rapidez y efectividad

donde los equipos antes de transmitir escuchan el medio para evitar transmitir mientras otro equipo lo

está haciendo, en caso de que ocurra una colisión, es decir, que dos equipos traten de transmitir al

mismo tiempo ambos equipos dejan de transmitir y luego de un tiempo de espera (aleatorio para cada

equipo, el cual depende de la jerarquía que tenga dentro de la red) intentan retransmitir el mensaje.

- 18 -

3.7.2. Modelos de Redes

Para poder proporcionar a los fabricantes un conjunto de estándares para asegurar una mayor

compatibilidad e interoperabilidad entre distintos tipos de tecnología de red se creó el modelo de red

descriptivo: Interconexión de Sistemas Abiertos OSI, “Open System Interconection”.

Tomando como patrón al modelo OSI, se crearon diversos protocolos, entre ellos el TCP/IP, en

el cual no se diferencian tanto las capas pero es uno de los más usados en la interconexión de redes.

• Modelo OSI

Este modelo, mostrado en la Figura 16, proporciona el marco de referencia para poder

entender cómo los productos de las comunicaciones pueden ser construidos y comunicarse entre si.

Figura 16. Capas del modelo OSI.

• Capa 1: cubre la compatibilidad de velocidad. La transmisión eléctrica puede ser regida por

dos parámetros, velocidad y distancia; la mayor velocidad de transmisión y la mayor

distancia posible. La capa 1 es el hardware de las comunicaciones, el cableado [20]. Esta

capa define los cables y conectores a usar para la conexión así como también la

transmisión a realizar incluyendo los niveles de voltaje y la velocidad de la misma.

• Capa 2: la capa de enlace de datos maneja la compatibilidad del protocolo, como su

nombre lo indica, de enlace de datos donde se transfiere información del punto A al punto

B, sin errores [20].

• Capa 3: la capa de red se encarga de la compatibilidad de rutas enviando datos desde la

fuente hasta el destino. La capa 3 es el software de las comunicaciones [20]. Ésta permite

la selección de la mejor ruta para la transmisión de paquetes de manera confiable.

• Capa 4: la capa de transporte proporciona la compatibilidad de la integridad del mensaje

de un extremo al otro. Esto asegura que el mensaje completo se mueva a través de la red

desde la fuente al destino [20]. Esta capa busca que el transporte sea confiable, establece

circuitos virtuales y mediante mecanismos de control permite la recuperación de datos

perdidos en la transmisión.

7 APLICACIÓN

6 PRESENTACIÓN

5 SESIÓN

4 TRANSPORTE

3 RED

2 ENLACE DE DATOS

1 FISICA

PROCESOS DE RED CORRESPONDIENTES A LAS APLICACIONES

PREPRESNTACION DE DATOS

COMUNICACIÓN ENTRE HOSTS

CONEXIONES DE EXTREMO A EXTREMO

DIRECCIÓN Y MEJOR RUTA

ACCESO A LOS MEDIOS

TRANSMISIÓN BINARIA

- 19 -

• Capa 5: la capa de sesión provee la conexión lógica uno a uno o extremo a extremo [20].

Establece, inicia y termina las sesiones de comunicación entre los equipos.

• Capa 6: la capa de presentación provee la compatibilidad de características, es el software

que usan las PC’s para su operación, un ejemplo podría ser el programa de interfaz gráfica

del usuario de Windows [20]. Garantiza que los datos sean legibles para el receptor.

• Capa 7: la capa de aplicación cubre la compatibilidad operacional. Hoy en día, muchos

programas aceptan archivos en distintos formatos operacionales [20].

• Modelo TCP/IP

El modelo TCP/IP es el más común utilizado por todos los ordenadores conectados a Internet,

de manera que éstos puedan comunicarse entre sí, sin importar que hardware o que software

contengan [21]. Fue creado por el departamento de defensa de EE.UU. convirtiéndose luego en el

modelo de red mas usado y en el cual se basa la Internet. Está compuesto por cuatro capas:

Aplicación, Transporte, Internet y Acceso a la Red; éstas pueden apreciarse en la Figura 17.

Figura 17. Capas del modelo TCP/IP

La Capa de Aplicación engloba las funciones de las capas de Aplicación, Presentación y Sesión

del modelo OSI. Se incluyen protocolos destinados a proporcionar servicios tales como correo

electrónico (SMTP), transferencia de ficheros (FTP), conexión remota (TELNET) y otros como el

protocolo HTTP (“Hypertext Transfer Protocol”) [21].

La Capa de Transporte equivale a la capa de Transporte del modelo OSI. Los protocolos de

este nivel, tales como TCP y UDP, se encargan de manejar los datos y proporcionar la fiabilidad

necesaria en el transporte de los mismos [21].

La Capa de Internet equivale a la capa de Red del modelo OSI. Incluye al protocolo IP, que se

encarga de enviar los paquetes de información a sus destinos correspondientes. Es utilizado con esta

finalidad por los protocolos del nivel de transporte.

Aplicación

Transporte

Red

Enlace de Datos

Física

- 20 -

La capa de Enlace de Datos especifica el método de transporte de los paquetes sobre la capa

física.

La capa Física describe las características físicas de la comunicación, como las convenciones

sobre la naturaleza del medio usado para la comunicación ya sea por cable, fibra óptica o radio, y todo

lo relativo a los detalles como los conectores, códigos de canales, modulación, potencias de señal, etc,

3.7.3. El protocolo IP El protocolo de IP, “Internet Protocol”, es la base fundamental de la Internet. Las principales

características de este protocolo son:

• Protocolo orientado a no conexión.

• Fragmenta paquetes si es necesario.

• Direccionamiento mediante direcciones lógicas IP de 32 bits.

• Si un paquete no es recibido, éste permanecerá en la red durante un tiempo finito.

• Realiza el "mejor esfuerzo" para la distribución de paquetes.

• Tamaño máximo del paquete de 65635 bytes.

• Sólo se realiza verificación por suma al encabezado del paquete, no a los datos que éste

contiene.

El Protocolo IP proporciona un servicio de distribución de paquetes de información orientado a

no conexión de manera no fiable. Orientado a no conexión significa que los paquetes de información,

que serán emitidos a la red, son tratados independientemente, pudiendo viajar por diferentes

trayectorias para llegar a su destino. El término no fiable significa básicamente que no se garantiza la

recepción del paquete.

La unidad de información intercambiada por IP es denominada datagrama. Tomando como

analogía los marcos intercambiados por una red física los datagramas contienen un encabezado y un

área de datos. IP no especifica el contenido del área de datos, ésta será utilizada arbitrariamente por

el protocolo de transporte [22].

Cualquier equipo que se conecte a una red TCP/IP debe tener una dirección IP, de 32 bits, única

para el equipo.

Para poder determinar cómo está definida una dirección IP se crearon las “Clases de

Direcciones IP” (ver Figura 18) donde una red con dirección clase A queda precisamente definida con

el primer octeto de la dirección, la clase B con los dos primeros y la C con los tres primeros octetos.

Los octetos restantes definen los nodos en la red específica [22].

- 21 -

Figura 18. Clases de Direcciones IP

3.7.4. El protocolo TCP

El propósito del TCP es proveer un flujo de bytes confiable de extremo a extremo sobre la

Internet no confiable. La entidad de transporte de TCP puede estar en un proceso de usuario o en el

kernel. Parte un flujo de bytes en trozos y los manda como datagramas de IP. Para poder usar las

ventajas del TCP, el emisor y el receptor tienen que crear puntos terminales de la conexión, llamados

“sockets”.

Las conexiones de TCP son punto a punto y “full duplex”. Cuando una aplicación manda datos

a TCP, éste puede mandarlos inmediatamente o almacenarlos (para acumular más) o usar el flag de

PUSH (empujar) que solicita que los datos se manden o enviarlos con el “flag” de URGENT (ver Figura

19) donde hace que se manden inmediatamente sin importar los datos que se estén enviando en el

momento [23].

Figura 19. Campos del Protocolo TCP

32 bits

PUERTO ORIGEN

CONFIRMACIÓN PIGGY BACK (ACK)

NÚMERO DE SECUENCIA

PUERTO DESTINO

TAMAÑO DE VENTANA Long. C U A P R S F

PUNTERO URGENTE

OPCIONES (O MAS PALABRAS DE 32 BITS)

DATOS

≈

≈

≈

≈

CHECKSUM

32 bits

0

1 0

1 1 0

1 1 1 0

1 1 1 1 0

RED

HOST

RED

RED

HOST

HOST

Reservado para uso futuro

Dirección multitransmisión

A B C D E

DIRECCIONES IP

1.0.0.0 a

127.255.255.255

240.0.0.0.0 a 247.255.255.255

224.0.0.0 a 239.255.255.255

128.0.0.0 a

191.255.255.255

192.0.0.0 a 223.255.255.255

- 22 -

3.7.5. El protocolo UDP

Es un protocolo de transporte basado en el intercambio de datagramas sin conexión alguna,

debido a que el mismo datagrama contiene toda la información necesaria para su envío. No controla el

flujo de los mismos, no existe confirmación de llegada ni tampoco realiza chequeo de errores, por lo

que no otorga garantías para la entrega correcta de los paquetes. Cualquier chequeo o garantía que se

quiera ofrecer debe ser implementado en capas superiores [24].

El paquete consta de 4 campos (ver Figura 20), siendo dos de éstos opcionales. Están primero

los campos de fuente y destino (siendo este último opcional ya que no se espera respuesta) con 16

bits cada uno, luego el campo de longitud, donde se coloca el tamaño del mensaje (datos + el tamaño

del campo longitud) también de 16 bits y por último el checksum de 16 bits, que de la misma forma es

opcional.

Figura 20. Campos del Protocolo UDP

Además de no realizar chequeo de errores y no enviar respuesta de que llegó

satisfactoriamente, el protocolo no permite numeración de los datagramas con lo que disminuye la

garantía de que el paquete llegue a su destino. Lo que origina a su vez la retransmisión de paquetes

conllevando a duplicación de paquetes y/o desorden en el destino [25].

3.8. Elementos de redes

3.8.1. “Hubs” Un hub o concentrador es un dispositivo que permite conectar una red de computadoras.

Repite, los paquetes que una de las computadoras envía, al resto de la red conectada a él además

envía un mensaje si existe colisión de algún paquete para invitar a la retransmisión.

3.8.2. “Switches”

Un switch es un dispositivo electrónico de interconexión de redes de computadoras que

mantiene un conocimiento de las direcciones MAC de las computadoras de la red para así poder enviar

los paquetes de una forma eficiente sin tener que hacer broadcasting y enviar información que para el

resto de las computadoras no es útil.

32 bits

PUERTO ORIGEN PUERTO DESTINO

LONGITUD UDP

DATOS

≈ ≈

CHECKSUM

- 23 -

3.8.3. “Routers”

Los routers son equipos que reenvían los paquetes de datos entre las redes. Un router está

conectado, como mínimo, entre dos redes, comúnmente entre dos LANs o dos WANs.

Los routers usan los encabezados y las tablas de enrutamiento para determinar el mejor

camino para reenviar los paquetes, y usan protocolos como el ICMP para comunicarse con cada uno y

configurar la mejor ruta entre dos “hosts” [26].

3.8.4. “Gateways”

El termino gateway se refiere a un dispositivo que permite la conversión de protocolos (en

especial los de la capa de aplicación) entre distintos tipos de redes o aplicaciones. Puede además

trabajar como enrutador de una red local hacia una red exterior.

Una puerta de enlace o gateway es normalmente un equipo informático configurado para

dotar a las máquinas de una red local (LAN) conectadas a él de un acceso hacia una red exterior,

generalmente realizando para ello operaciones de traducción de direcciones IP (NAT: “Network

Address Translation”). Esta capacidad de traducción de direcciones permite aplicar una técnica llamada

IP Masquerading (enmascaramiento de IP), usada muy a menudo para dar acceso a Internet a los

equipos de una red de área local compartiendo una única conexión a Internet, y por tanto, una única

dirección IP externa. Se podría decir que un gateway, o puerta de enlace, es un router que conecta

dos redes [27].

3.8.5. Ordenadores y Servidores Los ordenadores al igual que los servidores son equipos que permiten realizar algunas tareas

en beneficio de otras aplicaciones llamadas clientes. Algunos servicios habituales son los servicios de

archivos, que permiten a los usuarios almacenar y acceder a los archivos de un ordenador y los

servicios de aplicaciones, que realizan tareas en beneficio directo del usuario final. Es posible que un

ordenador cumpla simultáneamente las funciones de cliente y de servidor [28]. Estos servidores se

encuentran ya en la capa 7, ya que manejan los paquetes hasta el nivel de aplicación para mostrarlos

al usuario de una forma apropiada y con el programa adecuado.

3.8.6. VPN

Una VPN es una red privada virtual que usa la red pública, usualmente el Internet, para

conectar lugares o usuarios remotos [29]. Se extiende, mediante un proceso de encapsulación y

encriptación, desde los paquetes de datos a distintos puntos remotos mediante el uso de unas

infraestructuras públicas de transporte. Los paquetes de datos de la red privada viajan por medio de

un "túnel" definido en la red pública.

- 24 -

Para poder implantar una VPN se debe tener:

• Identificación de usuario: se debe verificar la identidad de los usuarios y restringir el

acceso a la VPN a aquellos que no estén autorizados. Al igual que se debe mostrar

registros de quién y por cuanto tiempo estuvo conectado a la red.

• Administración de direcciones: debe establecer una dirección del cliente en la red en la red

privada y debe cerciorarse que las direcciones privadas se conserven así.

• Codificación de datos: los datos a transmitir deben ser previamente encriptados para que

no puedan ser leídos por clientes no autorizados de la red.

• Administración de claves: la VPN debe generar y renovar las claves de codificación para el

cliente y el servidor.

• Soporte a protocolos múltiples: debe manejar los protocolos comunes que se utilizan en la

red pública [30].

Las VPN conservan la seguridad de la red privada de una forma económica ya que no se

requiere de un medio físico para asegurar la conexión.

3.9. Sistema operativo Linux. Fedora Core 4 Un sistema operativo es un conjunto de programas de computadoras que permiten la

comunicación entre un computador y su usuario además de administrar y utilizar los recursos del

mismo de la manera más eficiente posible. El sistema operativo de un equipo puede ser visto como

una capa intermediaria entre el Hardware y el usuario, que facilita al mismo la realización de tareas sin

tener que llegar a un gran nivel de detalle para el manejo del hardware.

El sistema Fedora Core 4 es un software libre, patrocinado por Red Hat, de uso sencillo y

plataforma de propósito general basada en Linux.

Fedora Core 4 es una de las últimas versiones (ya existe la versión 5 y la versión 6) de la

popular plataforma Fedora Core con una cantidad de nuevas características sobre las versiones

anteriores; mejoras en la presentación del escritorio, nuevas herramientas, soporte para arquitectura

de PowerPC (PPC), mejoras en la seguridad y plataforma más sólida, entre otras [31].

3.10. Señalización Telefónica en NGN y VoIP Tradicionalmente, la transmisión de voz y de datos se ha realizado a través de redes

diferenciadas. En la actualidad se estima que el tráfico de datos crece a una velocidad diez veces

superior al tráfico de voz, al tiempo que se observa un proceso de convergencia para que sea una

única red la que soporte la transmisión de voz, datos y video. La conversión de la voz en paquetes de

datos es lo que se ha dado en llamar VoIP. Hasta el momento la transmisión de voz se ha venido

realizando mediante la conmutación de circuitos; gracias al protocolo de Internet se puede transformar

la voz en paquetes de datos y transmitirla como si de datos se tratara a través de una única red,

- 25 -

dando lugar a lo que se denomina “red multi-servicio”. La convergencia de distintas redes en una sola

representa un gran ahorro tanto en mantenimiento como en su gestión y uso [32].

De acuerdo a lo mencionado anteriormente, las Redes de Nueva Generación NGN (“Next

Generation Networks”) tienen como objetivo esencial lograr la convergencia de las redes telefónicas y

de datos enviando la información vía paquetes IP. Estos paquetes enviados son diferenciados por

protocolos de acuerdo al tipo y gracias a ello pueden manejarse de distinta manera para poder

garantizar la Calidad de Servicio QoS (“Quality of Service”).

3.10.1. VoIP Como se explicó en la sección anterior, se entiende por Voz sobre IP VoIP (“Voice over

Internet Protocol”) a la digitalización de la voz y su transmisión a través de la red, usando para ello la

conmutación de paquetes, en la cual la información se transfiere fragmentada. De esta forma, cada

paquete se transmite a la dirección de destino de forma independiente, y es allí donde vuelve a

reagruparse y se recupera la información.

Debido a que en VoIP el tratamiento de voz es idéntico al de datos, se permite la utilización de

una única red lo cual representa un importante ahorro, eso junto con la capacidad de reducir el ancho

de banda para la transmisión de la voz, la movilidad ofrecida por la red IP, y la posibilidad de ofrecer

nuevos servicios son algunas de las razones que han impulsado el desarrollo de la transmisión de Voz

sobre IP.

• Topología de una red de VoIP Como se muestra en la Figura 21, una red VoIP está compuesta por una serie de elementos

que se describen a continuación.

Figura 21. Elementos y Protocolos de una Red VoIP

- 26 -

El “softswitch” contiene al “Media Gateway Controller” MGC es uno de los principales

elementos en una red VoIP. Es el elemento de red que se encarga del control del manejo de

señalización y sesiones durante una llamada o conferencia multimedia. El control de la llamada está

relacionado con el inicio y finalización de la misma, incluyendo la selección de los servicios que deben

aplicarse a la llamada, enrutamiento de la llamada. Además el “softswitch” debe proporcionar

autentificación y autorización de llamadas.

El “Signaling Gateway” (Puerta de acceso para la señalización) es la unidad del “softswitch”

que provee una red transparente de señalización entre las redes conmutadas por circuitos y las redes

IP, es decir, permite el paso de mensajes de una red SS7 a una red IP y viceversa. Este elemento

requiere conexión física con la red SS7 y debe tener conocimiento del grupo de protocolos requeridos.

El “Media Gateway”, es un dispositivo o elemento de la red que proporciona el transporte de

voz, datos y video entre la red IP y la PSTN. Su función más importante es convertir las señales de voz

(o, cualquier otro tipo de fuente de información) sobre circuitos TDM a streams de datos RTP la

traslación de la voz en paquetes para que ésta pueda ser comprendida por la red IP.

El “Media Server” (Servidor de Media) es utilizado para mejorar las características funcionales

del “softswitch”. Ofrece funcionalidades básicas de transferencia de llamadas, contestadota, así como

también funcionalidades de IVR (“Interactive Voice Response”).

El “Feature Server” (Servidor para Capacidades Especiales) se encarga de controlar los datos

para generar la facturación, así como servicios relacionados con bases de datos como los números

800, 900, servicios prepago, llamada en espera, transferencia e identificador de llamada.

3.10.2. Protocolos VoIP

Las redes VoIP están formadas por un conjunto de elementos. En la Figura 22 se muestran los

componentes principales y los protocolos que usan para comunicarse entre ellos.

Figura 22. Protocolos de una red VoIP

IP

TCP UDP SCTP UDP UDP TCP

SIP

H.225.0 H.24H.225 RAS

H.450 H.235

H.323

MGC H.248 MEGACO

M2U M3U SUA

M T P 3

I S U P

S C C P

TCAP

RTCP RTP

R T S P

AUDIO codec

encoding Not

Video codec protocol

T.123

T . 1 2 0

T.124 T.122/ T.125

T.125 T.127

H.225

VoIP Signaling Signaling Gateway Control Media Gtwy Media DATA

T . 1 2 0

- 27 -

IP es un protocolo basado en paquetes y orientado a no conexión, por ello se presentan

problemas como pérdidas de paquetes, entrega fuera de secuencia, fluctuaciones, y demoras, por lo

que no existe una calidad de servicio garantizada. En este sentido el protocolo de Control de

Transmisión TCP (“Transmission Control Protocol”) complementa al protocolo IP ya que al ser

orientado a conexión se encarga del control de flujo, entrega completa, sin daños y en secuencia de

los paquetes. Este protocolo fue diseñado para el transporte de datos más no de voz. Por su parte, el

Protocolo de Datagrama de Usuario UDP (“User Datagram Protocol”) es un protocolo de la capa de

transporte orientado a no conexión que se encarga del envío de paquetes sin importar si llegan

desordenados, duplicados o con errores.

En la Figura 22 se puede observar que se usan los protocolos H.323 junto con su familia de

protocolos de capas menores y SIP para la señalización de VoIP.

Los protocolos MGCP (“Media Gateway Control Protocol”) y MEGACO (“Media Gateway

Control”) son similares. MEGACO es un protocolo esclavo-maestro en el cual las aplicaciones de

software también conocidas como Agentes de llamada controlan la operación de los “Media Gateway”.

“El Media Gateway” se encarga de transportar Media (voz, data, video) entre la red IP y la red PSTN.

En el lado de la red IP los “streams” de media son paquetizados dentro del marco RTP. Del lado de la

Red PSTN, cada stream de audio corresponde al canal DS0. El “Media Gateway Controller” genera

comandos al “Media Gateway” para que éste sepa como asignar la sesión RTP correspondiente al

canal DS0 [33].

Los protocolos RTP (“Real-Time Transport Protocol”) y RTCP (“Real-Time Control Protocol”)

funcionan sobre el protocolo UDP y se usan para el transporte de la voz. RTP se encarga de

proporcionar información adecuada a la capa de aplicación superior para tomar decisiones adecuadas

sobre cómo debe ser manejado el nivel de calidad de la data. Por su parte, los mensajes RTCP son

intercambiados entre las sesiones de usuarios para proporcionar una respuesta acerca de la calidad de

la sesión, siendo esto tratado en la sección 3.9.4.

Los protocolos ISUP, SCCP, TCAP y MTP3 son protocolos utilizados para la señalización de

control y el manejo de los gateway de señalización sobre los protocolos M2UA, M3UA y SUA. M2UA

soporta el control de la congestión y se encarga del transporte de los mensajes MTP3 [33]. Por su

parte, el protocolo SCTP es responsable de un transporte confiable de señalización, y de evitar

congestión.

• El Protocolo H.323

El estándar H.323 es una recomendación de la Unión Internacional de Telecomunicaciones

(ITU) basada en los estándares de la familia H.320. La primera versión del protocolo fue diseñada para

proveer señalización en conferencias de sistemas multimedia en ambientes LAN, sin provisiones de

calidad de servicio.

- 28 -

H.323 especifica los componentes, protocolos y procedimientos que proveen servicios de

comunicación multimedia sobre redes de paquetes, tanto para sesiones multipunto como punto a

punto. La tecnología de red más común en la que se está implementando H.323 es IP.

Un sistema H.323 define la señalización necesaria de comunicaciones multimedia sobre una

red basada esencialmente en paquetes la cual no garantiza una calidad de servicio.

En la Figura 23 se puede observar la estructura de una Red de Señalización H.323 y las

entidades que la conforman.

Figura 23. Estructura de una red de señalización H.323

“Gatekeepers”: actúan como punto central de todas las llamadas dentro de una zona, y

suministran servicios a los terminales registrados y realizan control de llamadas.

Proporcionan dos funciones importantes de control de llamada.

• Se encargan de realizar la traducción de direcciones desde el alias de la red H.323 a

direcciones IP o IPX.

• Gestión del ancho de banda, especificado en RAS.

Gateways: son los sistemas encargados de permitir que los equipos H.323 puedan operar con

redes que utilicen otros protocolos de señalización, como terminales PSTN, ISDN, SIP, entre otros.

Terminales: son los puntos finales en la comunicación. Proporcionan una comunicación de voz,

datos y video en tiempo real. H.323 especifica los modos de operación requeridos para que los

terminales de audio, video y datos trabajen conjuntamente. Para permitir que los terminales puedan

interoperar entre sí, es necesario que puedan soportar voz, por ejemplo con el codec G.711. de esta

forma, el soporte para videos y datos es opcional para un Terminal H.323.

Todos los terminales deben soportar el protocolo H.245, el cual es usado para negociar el uso

del canal y las capacidades. Otros tres componentes requeridos son: Q.931 para la señalización y

Gatekeeper

Red IP

Red PSTN

Gateway

MCU

Terminales

- 29 -

configuración de la llamada, RAS (Registro/Admisión/Estado) que es un protocolo usado para

comunicarse con el “Gatekeeper”; y soporte para RTP/RTCP para secuenciar paquetes de audio y

video.

Controladores, Procesadores y Unidades de Control Multipunto MCU: proporcionan soporte

para conferencias multipunto.

• Protocolo SIP

En este trabajo se usó SIP como protocolo de señalización ya que el mismo es utilizado por la

aplicación desarrollada. Este es el modelo de señalización propuesto por la IETF en el RFC 2543 para

las redes de VoIP, el cual establece al Protocolo de Inicio de Sesión SIP (“Session Initiation Protocol”)

como un protocolo de la capa de aplicación cuya función es crear, modificar y terminar sesiones

multimedia y llamadas telefónicas vía Internet, con uno o más participantes [34]. SIP define dos

entidades de red básicas: clientes y servidores. Estrictamente hablando, un cliente (también conocido

como agente usuario cliente) es un programa de aplicación que envía peticiones SIP. Por su parte, un

servidor es una entidad que responde las peticiones. De esta forma, SIP es un protocolo cliente-

servidor. Las llamadas de VoIP que usan el protocolo SIP son originadas por el cliente y terminadas

por el servidor.

Un cliente podría ser encontrado dentro de un dispositivo de usuarios, el cual puede ser una

PC o un teléfono SIP, pero también podrían ser encontrados dentro de la misma plataforma como

servidor. Por ejemplo, SIP habilita el uso de Proxies, los cuales actúan como clientes y servidores [2].

Un sistema SIP está basado en un modelo cliente/servidor y esencialmente se encuentra

formado por las entidades que se muestran en la Figura 24.

Figura 24. Estructura de una red de señalización SIP

Los Agentes de Usuario UA (“User Agent”) son las entidades lógicas terminales de VoIP

encargadas del intercambio de mensajes SIP. Un dispositivo SIP puede funcionar tanto como Agente

de Usuario Cliente UAC (“User Agent Client”) y Agente de Usuario Servidor UAS (“User Agent Server”).

Un Agente de Usuario Cliente inicia peticiones SIP y recibe respuestas, un Agente de Usuario Servidor,

recibe y procesa las peticiones SIP y luego reenvía las respuestas correspondientes [35].

Red PSTN

Gateway

Location Redirect Registrar Server

Proxy Server Proxy Server

User Agents

- 30 -

Típicamente los Agentes de Usuario, residen en computadoras de usuarios en forma de

aplicación (éste es actualmente el uso más común), pero los Agentes de Usuario también pueden ser

teléfonos celulares, Gateways PSTN, PDAs, entre otros [36].

El Servidor de Registro (“Registrar Server”) es un servidor que acepta peticiones SIP de

registro de los usuarios, extrae la información acerca de su localización actual (dirección IP, puerto,

nombre de usuario) y almacena la información en una base de datos [36].

El Servidor de Redireccionamiento (“Redirect Server”) es un servidor que acepta peticiones

SIP, y proporciona el mapeo de las direcciones en otras nuevas. Es decir, le entrega la nueva dirección

al que originó la petición. Luego de ello, el autor de la petición puede enviar peticiones directamente a

la dirección (o direcciones) devueltas por el servidor de redireccionamiento. Este tipo de servidores no

pueden aceptar ni terminar llamadas.

El Servidor Proxy (“Proxy Server”) es una entidad SIP que actúa como intermediario. Su

función principal es enrutar o redireccionar métodos SIP, pudiendo interpretar, modificar o traducir

campos de los métodos SIP antes de enviarlos a su destino. Dado a que un Proxy puede recibir y

enviar peticiones, incorpora funcionalidades de cliente y servidor [35].

El desarrollo de una llamada telefónica usando el protocolo SIP puede describirse en una serie

de etapas:

• Registro, iniciación y localización del usuario.

• Determinación del medio a usar, según la descripción de la sesión a la que se invitó al usuario.

• Solicitud de establecimiento de conexión y espera de respuesta.

• Inicio de la llamada.

• Modificación de la llamada, por ejemplo: transferencia (opcional).

• Finalización de la llamada.

Las peticiones SIP son caracterizadas por la línea inicial del mensaje, llamada Request-Line,

que contiene el nombre del método, el identificador del destinatario de la petición (Request-URI) y la

versión del protocolo SIP.

La RFC 3261 define seis métodos diferentes básicos SIP que describen las peticiones de los

clientes:

• INVITE: es usado para iniciar sesión. Para una simple llamada entre dos partes, el mensaje

INVITE es usado para iniciar la llamada, este mensaje incluye información referente a la parte

que llama, la parte llamada, así como el tipo de medios intercambiados.

• ACK: este método es usado como confirmación de que la repuesta final ha sido recibida.

• OPTIONS: Solicita información sobre las capacidades de un servidor.

• BYE: Indica la terminación de una sesión.

• CANCEL: Cancela una petición pendiente.

- 31 -

• REGISTER: es utilizado por un cliente del Agente de Usuario para abrir una sesión y registrar

su dirección con un servidor SIP.

Los códigos de estado definidos en SIP presentan valores entre 100 y 699, siendo el primer

dígito del código el que indica la clase de respuesta. Entonces, todos los códigos de estado entre 100 y

199 pertenecen a una misma clase. Las diferentes clases existentes se muestran a continuación:

1XX: Mensaje provisional.

2XX: respuesta satisfactoria (solamente el código 200 está definido, lo cual significa que se ha

entendido la petición y se ha realizado. En el caso de un mensaje INVITE, la respuesta 200 es usada

para indicar que la parte llamada ha aceptado la llamada).

3XX: mensaje de redireccionamiento.

4XX: Respuesta fallida

5XX: Falla de servidor

6XX: Falla Global

3.10.3. Tráfico Telefónico

El concepto de tráfico telefónico está asociado al de ocupación. Se dice que un circuito

telefónico está cursando tráfico cuando está ocupado, no si está libre.

Cuando se produce una comunicación telefónica entre 2 abonados, además de ellos se ocupan

una serie de elementos intermedios como las centrales telefónicas y los dispositivos usados para

interconectarlas.

El tráfico telefónico es medible en términos de tiempo y depende del número de

comunicaciones y de la duración de las mismas [37].

En una red de telecomunicaciones, tráfico se refiere al volumen de información transportado o

procesado por la red. La información puede consistir en data relacionada con el intercambio de

información entre los usuarios como voz, imágenes, archivos, así como también el intercambio de

información entre los elementos de la red como la data de señalización en las redes de circuitos,

información de enrutamiento en las redes IP, data de operación, entre otros [38].

El promedio de número de llamadas simultáneas N en progreso se conoce como “intensidad de

tráfico” y su unidad de medida es el Erlang, que representa la ocupación de una llamada por el espacio

de una hora. Este concepto es fundamental y define la base para medir el tamaño de una red.

Entonces si un recurso (circuito digital, virtual, entre otros) se asocia con sus correspondientes

llamadas N, una red con la capacidad de manejar al menos N recursos será requerida para manejar

ese tráfico.

- 32 -

3.10.4. Calidad de Servicio en las redes VoIP

En los últimos años, la importancia de la calidad de servicio QoS para redes de paquetes ha

incrementado rápidamente. Es por ello que la calidad de servicio es uno de los puntos más

importantes en las tecnologías de redes paquetizadas.

Las primeras redes IP eran completamente diferentes a las redes telefónicas, ya que fueron

diseñadas para transportar data. A diferencia de la voz, la data es un servicio que no es de tiempo

real. Por ello la data puede ser almacenada en la red y entregada luego. Si la data fue entregada con

error, puede ser retransmitida, pero esto no es posible con la voz.

La calidad de servicio puede definirse desde dos puntos de vista: La calidad de servicio

experimentada por el usuario final y la calidad de servicio desde el punto de vista de la red. Para la

perspectiva del usuario, la QoS es la percepción del usuario de la calidad que recibe del proveedor de

la red para un servicio o aplicación en particular como voz, video, data. Para la perspectiva de la red,

QoS se refiere a las capacidades de la red de proporcionar esa calidad de servicio que percibe el

usuario [39].

Para proporcionar QoS, una red paquetizada debe poder diferenciar entre las clases de tráfico

de modo que los dispositivos finales puedan tratar una o más clases del tráfico de manera diferente a

las otras. En segundo lugar, luego de que la red distingue entre las clases de tráfico, debe entonces

poder tratar de forma distinta esas clases de tráfico, proporcionando aseguramiento y diferenciación

del recurso dentro de la red. La percepción del usuario final de la calidad es determinada por pruebas

subjetivas en función de las debilidades que la red presenta como por ejemplo los retardos en la

llegada de paquetes a su destino, el jitter o variación en los retardos de paquetes, pérdidas de

paquetes. En particular, la debilidad de una red paquetizada depende del mecanismo de calidad de

servicio implementado en la misma [39].

Existen varias métricas para medir la calidad de servicio de una red, entre ellas se pueden

mencionar EModel, y MOS.

MOS (“Mean Opinión Score”): la percepción del usuario final de la calidad de servicio es

determinada por análisis subjetivos de las debilidades de la red. Los factores representativos para

analizar son presentados a los usuarios como simples preguntas. Para cada condición de análisis, los

usuarios encuestados clasifican los temas en una escala de cinco puntos: “excelente”, “bien”,

“regular”, “pobre” e “insatisfactorio”, siendo éste el método usado por CANTV.

EModel: es definido por la recomendación G.107 de la ITU-T. Consiste en un modelo

computacional diseñado para producir el MOS sin conducir a una prueba subjetiva. Para usar esta

métrica, los efectos de retardo, “jitter”, pérdida de paquetes y otras debilidades importantes se

combinan en un simple parámetro llamado Factor R el cual tiene un rango de 0 a 100.

- 33 -

3.11. Resumen entre sistema de telefonía tradicional o básico y paquetizado (VoIP).

Para concluir se muestra a continuación, en la Tabla 1, una serie de comparaciones entre

ambos sistemas de telefonía.

Uso del Ancho de Banda

* Depende de la compresión usada y el canal es compartido con el tráfico de datos.

* 64kbps a tiempo completo y sólo para canal de voz

Redes * Uso de la red privada aunque a veces el medio es el Internet

* Dominio de la red pública sobre la red privada

Teleservicios Básicos

* Llamadas entre equipos fijos dentro de la red privada y hacia terminales fijos dentro de la red pública.

* Llamadas entre terminales fijos dentro de la red pública.

Conmutación de Circuitos Voz Paquetizada

Elementos Básicos

* “Gateways” * “Gatekeepers” * MCU * “Call Agent” * Servidores * Terminales

* Centrales Telefónicas * Rutas y Troncales * Líneas de Subscriptores * Terminales

Topología * Bus * Cualquiera usada en redes IP.

* Estrella * Bus * Anillo

Transmisión

* Señales digitalizadas. * Información transmitida por medio de paquetes usando protocolos de redes de datos. * Redes de alta capacidad.

* Combinación del mundo analógico con el digital. * Técnicas FDM con TDM para asignación de canales de voz. * Modems de velocidad limitada hasta 230kbps.

Señalización

* Se usa un sólo protocolo a lo largo del proceso. * Los protocolos más comunes son el SIP y el H.323

* Se requieren diversos tipos de señalización. * En nuestro país se usa el MFCR2 y el SS7

- 34 -

Tabla 1. Comparación entre sistemas telefónicos.

3.12. Herramientas para VoIP En el mercado actual se pueden apreciar distintas herramientas para el manejo de VoIP, cada

una con especificaciones y funciones distintas de las otras. Luego de una revisión se escogieron

algunas de ellas para un exhaustivo análisis entre las cuales tenemos:

• OpenSER (Open SIP Express Router)

En el año 2005, Voice System anunció la creación de OpenSER. La razón de dicha creación, se

debió a la falta de progreso y contribución al proyecto SER por parte de los miembros su comunidad.

Los desarrolladores de Voice System de SER, sentían que iptel.org fue quién tomó las decisiones

finales en el lanzamiento de los códigos, además de que no había podido agregar nuevas

contribuciones y había sido demasiado lento en lanzar las nuevas versiones de SER.

La sensación general era que las nuevas características ofrecidas eran buenas, pero la mayoría

de la gente percibía que sería más sencillo para la comunidad si tanto la estabilidad y garantía de

calidad encontrada en SER se podría combinar en el mismo proyecto con las metas de OpenSER.

Hablando propiamente de OpenSER, éste es un servidor SIP con arquitectura flexible y

modular. Puede ser usado en sistemas con recursos limitados así como también en servidores de

transporte, escalando hasta miles de llamadas por segundo. Está escrito en lenguaje C para sistemas

Unix/Linux, presentando además un alto rendimiento. Dependiendo de la configuración, OpenSER es

Conmutación de Circuitos Voz Paquetizada

Transmisión de Fax

* Envío de imágenes de mayor calidad almacenadas en el computador o impresas mediante el fax.

* Envío de imágenes con poca resolución y con velocidad limitada.

Otros Servicios

Funciones que pueden aplicarse a este sistema telefónico: * Recepción de alarmas * Autentificación de usuarios * Desvío de llamadas * Transferencia de llamadas * Identificador de llamadas * Marcación por nombre * Conferencia * Envío de Mensajes de texto. * Mensajes de voz * Grabación de llamadas

Funciones que pueden aplicarse a este sistema telefónico: * Recepción de alarmas * Desvío de llamadas * Conferencias * Llamada en Espera * Identificador de llamadas * Mensajes de voz

- 35 -

capaz de operar como un Servidor Proxy, Servidor de Registro, Servidor de Redireccionamiento,

Servidor de Localización, Gateway para SMS/XMPP1, o servidores VoIP de aplicaciones avanzadas [40].

Por el Proxy SIP pasan todas las peticiones de un usuario, siendo éste el que le permite

acceder a la red, localizar a otros usuarios y establecer la comunicación VoIP SIP.

OpenSER es un proyecto de software libre que tiene como fin desarrollar un servidor SIP

seguro y extensible para proporcionar servicios modernos de VoIP.

Entre las características de OpenSER pueden mencionarse:

• Es un Servidor SIP robusto que puede incluir: Servidor Proxy, Servidor de Localización,

Servidor de redireccionamiento, Servidor de Registro.

• Presenta la habilidad de agregar nuevas extensiones sin necesidad de modificar el núcleo,

asegurando por lo tanto gran estabilidad a los componentes del núcleo.

• Arquitectura modular lo cual permite extender la funcionalidad del servidor.

• Autentificación, Autorización a Aprovisionamiento (AAA) a través de la base de datos (MySQL,

Postgress, archivos de texto). RADIUS y DIAMETER.

• Uso de pseudovariables para acceder y manejar parte de los mensajes SIP y atributos

específicos de los usuarios y servidor.

• SER (SIP Express Router)

Es un servidor SIP de libre distribución, desarrollado por la compañía alemana Iptel.org. Es

capaz de actuar como un servidor Proxy, de Registro o Redireccionamiento. Funciona bajo el sistema

operativo Linux, y está escrito en lenguaje C. Al igual que OpenSER, se encuentra programado de

forma modular, por lo que el administrador puede cargar los módulos requeridos, así como crear sus

propios módulos en caso de ser necesario. Tiene la capacidad de manejar miles de llamadas por

segundo en una máquina con CPU dual, y cientos de llamadas por segundo en una Compaq IPAQ.

Adicionalmente, SER ofrece una interfaz de usuario-servidor (SERWeb), soporte de presencia, servicios

como: monitoreo de estado del servidor, seguridad FCP2, autorización de acceso, gestión de cuentas.

Además, puede ser configurado vía web usando bases de datos.

• Asterisk

Es una aplicación de código abierto3 basada en una PBX tal como si fuera una central de tipo

hardware. Asterisk ofrece las funciones propias de las centrales tradicionales y además características

avanzadas, pudiendo trabajar tanto con sistemas de telefonía estándar tradicionales como con

sistemas de Voz sobre IP. Trabaja con VoIP con los protocolos SIP, H.323, MGCP e IAX, por lo que

1 Protocolo abierto y extensible basado en XML ideado para mensajería instantánea [41]. 2 Protocolo usado para controlar filtros de paquetes usando controladores externos. 3 Software Libre

- 36 -

incluye las ventajas que ofrece el trabajar con redes de datos paquetizadas. La solución de telefonía

basada en Asterisk dispone de un extenso conjunto de funciones, entre las que se pueden mencionar:

• Provee servicios de mensajes de voz, llamada en espera, identificación de llamadas, IVR4,

conferencias, y música en espera [42].

• Conexión de los empleados trabajando desde su casa a las redes de la oficina usando para ello

las redes de banda ancha [43].

Asterisk fue originalmente desarrollado para el sistema operativo Linux, pero actualmente

también funciona en BSD, MacOSX, Solaris y Microsoft Windows [44]. Está escrito en lenguaje C.

Para una mejor visión, se presenta a continuación, en la Tabla 2, una lista de criterios tomados

para una mejor comparación junto con sus detalles dentro de cada una de las opciones.

Criterios SER OpenSER Asterisk

Frecuencia de Liberación / Nuevas

Características

Ciclos de liberación largos, se necesita usar la versión experimental o versiones “HEAD”

para nuevas características

Liberaciones menos frecuentes (0.a.x) con nuevas características.

Cambios mayores disponibles en

liberaciones mayores (0.a.x), pero no hay historia de esto por

ahora.

Liberaciones frecuentes con nuevas características

Comunidad de Usuarios

Buena comunidad establecida por la cuenta de correo [email protected]. Varios contribuyentes

activos. Las preguntas o comentarios deben ser escritas correctamente para poder obtener respuesta alguna.

El núcleo del sistema de voz del OpenSER es

muy activo y la mayoría de las preguntas son

contestadas.

Digium, el creador, ha construido un foro en su sitio web. Es el mejor para que los novatos y

demás usuarios respondan sus dudas de una forma amigable. La información se presenta

en un formato organizado.

Calidad / Estabilidad de las liberaciones

El largo ciclo entre las liberaciones y la amplia comunidad existente reduce el riesgo de

“gusanos” si se usa una configuración estable.

La alta concentración en nuevas características y

las liberaciones frecuentes aumentan la aparición de “gusanos” en configuraciones estables. La política para la estabilidad es

liberar las configuraciones a

menudo.

Existe soporte para la instalación de las actualizaciones.

Documentación El manual de

Administrador en iptel.org está

Muy enfocados en la documentación. Los archivos README de

Buena documentación, en la página principal se encuentra el manual y

4 Aplicaciones Interactivas de Voz

- 37 -

desactualizado, pero es útil. La fuente principal de la documentación de los módulos son los README que se

encuentran en cada uno. La documentación del OpenSER 0.9.x es recomendada y es un

buen comienzo.

cada módulo al igual que algunos tutoriales pueden ser encontrados en la pagina principal de

OpenSER.

algunos ejemplos de configuración.

Soporte para varias

arquitecturas

La persona responsable de compilar las

arquitecturas trabaja en SER.

Difícil de decir, probablemente los desarrolladores de OpenSER tratan de fusionar en las arquitecturas los

cambios del SER CVS (Sistema de Versiones

Concurrentes)

Soporte de varios protocolos y múltiples hardwares y sistemas

operativos.

Participación del desarrollo

Código disponible en: http://developer.berlios.

de/projects/ser/. Parches en:

http://bugs.sip-router.org/. Módulos o extensiones de código

pueden ser suministrados en [email protected]

Código disponible en: http://sourceforge.net/p

rojects/openser/ Enviar mails al

[email protected]

Código disponible en: http://www.asterisk.org/d

ownload. Enviar mails al:

[email protected] y

[email protected]

Soporte comercial

Iptelorg.com vende licencias comerciales del SER. Las consultas son

presentadas en [email protected]

El sistema de voz ofrece software y consultas. La disponibilidad de otros

consultores es desconocida.

Tiene el soporte de la empresa DigiumTM

Funcionalidad Servidor SIP Servidor SIP Orientado a las PBXs

Facilidad para Customizar

Único código fuente de fácil configuración con

manuales para la sencilla incorporación de

enrutamientos.

Único código fuente de fácil configuración con

manuales para la sencilla incorporación de

enrutamientos.

Varios códigos fuente, cada uno especializado en un área específica del

sistema.

Tabla 2. Comparación entre SER, OpenSER y Asterisk

CAPÍTULO IV: METODOLOGÍA

En este capítulo se explica la metodología utilizada en el desarrollo de la pasantía. Se

presentan en forma detallada cada una de las fases que conforman el proyecto. Para facilitar la

presentación, se exponen en orden cuatro fases que agrupan un conjunto de actividades.

4.1. Revisión Técnica Para un mejor entendimiento del enrutamiento de Voz sobre IP, fue necesario realizar una

exhaustiva documentación usando como herramienta fundamental Internet. Entre los tópicos

estudiados destacan: el protocolo de señalización SIP, revisión de las soluciones de Proxy SIP

existentes en el mercado, características de configuración de la aplicación a desarrollar, así como

también, las herramientas de trabajo y programación requeridas.

Con ayuda de Internet fueron investigados puntos relacionados con VoIP, señalización SIP,

redes de computadoras, muchos de los cuales son fundamentales para el entendimiento del proyecto y

por ello forman parte del Marco Teórico.

• Se descargaron de la Web, libros y publicaciones como parte del material bibliográfico.

• Se hicieron consultas por medio de Internet como apoyo al material bibliográfico recopilado.

• Se buscó información referente a las soluciones para el enrutamiento de Voz Sobre IP

existentes en el mercado: SER, OpenSER y Asterisk.

• Se hizo un estudio de las necesidades de CANTV referentes al enrutamiento del Voz sobre IP.

• Se realizó una investigación sobre las herramientas de trabajo y programación requeridas, así

como los requerimientos de hardware y software de las mismas.

4.2. Investigación y selección de las herramientas Para el desarrollo del proyecto se requiere contar con un grupo de herramientas que permitan

el desarrollo de la aplicación Web, acceso remoto al servidor, manejo de la base de datos, pruebas de

tráfico, captura de los mensajes SIP en la red. Por ello, en esta etapa fue necesario hacer un estudio

de todas las herramientas requeridas para el proyecto con el fin de garantizar la compatibilidad de las

mismas con los recursos de los cuales se disponía.

4.2.1. Aplicaciones En el contexto del proyecto, aplicación se refiere a un programa o conjunto de programas

diseñados para realizar tareas específicas definidas bajo el control del administrador.

• Se identificaron las aplicaciones VoIP de software libre disponibles en el mercado.

• Se investigaron los requerimientos a nivel de hardware de cada una de las aplicaciones.

• Se seleccionó la aplicación OpenSER como solución al Servidor Proxy SIP a ser desarrollado.

- 39 -

• Se descargaron de la página oficial de Internet los paquetes necesarios para la instalación de

OpenSER.

• Se seleccionó la aplicación OpenVPN para la implementación de una Red Virtual Privada, y se

procedió a descargar el software correspondiente.

4.2.2. Sistema Operativo Consiste en un conjunto de programas destinados a permitir la comunicación del usuario con

su ordenador, gestionar los recursos de la máquina ejecutando servicios para los procesos, así como

brindar una interfase al usuario para ejecutar instrucciones [45].

• Se evaluaron las diferentes opciones de sistemas operativos existentes en el mercado y su

compatibilidad con la aplicación a desarrollar.

• Debido a las ventajas que ofrece, se seleccionó Linux como Sistema Operativo.

• Se seleccionó Fedora Core 4 como distribución a utilizar.

• Se descargó de la Web el software correspondiente.

4.2.3. Servidor

En este caso se refiere al ordenador físico en el cual reside una aplicación que realiza ciertas

funciones en nombre de los usuarios.

Debido a que en la empresa había disponibilidad de varios servidores, se escogió uno que

cumpliera los requerimientos técnicos, funcionales y de compatibilidad con la aplicación a desarrollar.

4.2.4. Herramientas complementarias

Fue necesario definir el conjunto de herramientas requeridas realizar la configuración de la

aplicación, para desarrollar la aplicación Web, así como para realizar las pruebas.

• Se escogió Mysql-Front para el manejo de la base de datos de OpenSER

• Se eligió el programa Macromedia Dreamweaver para el diseño y la programación Web.

• Se investigó sobre las herramientas disponibles generadoras de tráfico para el protocolo SIP

eligiendo para ello SIPp.

• Se estudiaron diversas opciones para el seguimiento de las trazas de los mensajes SIP.

• Se escogieron dos programas para el monitoreo y análisis de las trazas: Ngrep y Ethereal.

• Se identificaron los diferentes softphone disponibles en el mercado

• Se seleccionó y descargó a través de la web el softphone X-Lite.

Al momento de desarrollar el proyecto se disponía de antemano el servidor en el cual se iba a

desarrollar la aplicación, por ello, en este caso se verificó la compatibilidad de las aplicaciones

requeridas con el mismo

- 40 -

4.3. Evaluación de la aplicación

En esta etapa se procedió a hacer un extenso análisis de los módulos que integran OpenSER,

así como del archivo de configuración original. Además es necesario investigar los requerimientos a

nivel de software y de hardware de la aplicación a desarrollar.

• Se evaluaron los requerimientos de hardware y de software para la instalación de OpenSER.

• Se revisó el archivo de configuración original de OpenSER.

• Se analizaron los módulos que lo forman así como los parámetros de configuración relevantes.

• Se planteó una configuración inicial de OpenSER.

4.4. Instalación de las herramientas y configuración de la Aplicación

4.4.1. Software

• Sistema Operativo Fedora Core 4

Para instalar Fedora Core, se debe iniciar el equipo por medio del cdrom. Actualmente, la

mayoría de los equipos presentan como primer equipo de arranque el cdrom, en caso de no ser así, se

debe entrar a la BIOS del computador y elegir “cdrom” como dispositivo de inicio.

La instalación de Fedora incluye la desfragmentación del disco duro para ordenar la

distribución física de los datos, así como un particionamiento del mismo.

Luego se comienza con la selección de las opciones de instalación, donde de eligen las

opciones de configuración como IP, máscara de red, Gateway, DNS Primario, DNS Secundario, usuario

y contraseña, así como el grupo de paquetes que deben instalarse, todo esto en función de las

necesidades que se tengan. Para mayores detalles acerca de la instalación del Sistema Operativo

Fedora Core 4 ver Anexo 1).

Fedora Core 4 tiene la ventaja de que trae incluidos los paquetes para a instalación de MySQL,

Apache, FTP, entre otros. Es por ello que para la instalación de los mismos simplemente deben

seleccionarse entre el grupo de paquetes a instalar.

• OpenSER

� Instalación

El proceso de instalación de OpenSER es como se muestra a continuación:

� Se deben descargar de la Web los paquetes:

openser-1.0.0-rhel3.0.i386.rpm

openser-cpl-1.0.0-rhel3.0.i386.rpm

openser-mysql-1.0.0-rhel3.0.i386.rpm

openser-1.0.1-tls_src.tar.gz

� Instalar los paquetes:

openser-1.0.0-rhel3.0.i386.rpm

- 41 -

openser-cpl-1.0.0-rhel3.0.i386.rpm

openser-mysql-1.0.0-rhel3.0.i386.rpm

� Crear las bases de datos y tablas de OpenSER.

� Configuración del usuario para el acceso a FTP.

� Instalar el conector entre PHP y MySQL.

� Reiniciar los servicios openser, httpd, vsftpd, mysqld, crond (para mayores

detalles ver Anexo1, sección 6.1).

� Configuración Para la configuración de OpenSER se siguió una lógica estructurada con el fin de mantener

una cierta organización, debido a ello, OpenSER puede definirse básicamente en siete secciones:

Sección de Definiciones Globales, Sección de Módulos, Sección de configuración de los Módulos,

Bloque de Ruta Principal, Bloque de Ruta Secundaria, Bloque de Ruta de Respuesta y Bloque de Ruta

de Falla. El proceso seguido para la configuración de OpenSER se muestra a continuación:

� Definición de los parámetros de configuración global.

� Especificación de los módulos a ser incluidos en la ejemplificación.

� Configuración de los parámetros de los módulos que forman parte de la

ejemplificación.

� Desarrollo de la lógica de Enrutamiento Principal y Bloque de Ruta

Secundaria.

� Desarrollo del bloque de Ruta de Respuesta y Ruta de Falla.

A medida que se modifica el archivo de configuración de OpenSER se debe

compilar el mismo, esto con la finalidad de ir depurando el código de errores de

sintaxis.

• VPN

Debido a que el servidor se encuentra dentro de la red privada de CANTV, es necesario poder

tener acceso al mismo desde la red pública, para ello se usa la VPN ya que ésta permite una extensión

de la red local sobre la red pública o no controlada.

Para crear una Red Privada Virtual es necesario dirigirse al panel de control de la PC, abrir la

carpeta Conexiones de Red, y en el menú Archivo se selecciona la opción Nueva Conexión. (Los

detalles de configuración se muestran en el Anexo1, sección 10.6)

• Acceso Remoto al Servidor

El acceso remoto permite acceder desde una ubicación externa y de manera segura a la

información almacenada en el servidor, tal y como si se encontrara trabajando físicamente en el

- 42 -

mismo. Para lograr la conexión desde Windows debe crearse un cliente SSH para acceso remoto,

pudiendo usar para ello el programa Putty.

Este programa es un ejecutable, por lo tanto luego de descargarlo sólo es necesario realizar la

configuración del mismo. (Los pasos para la instalación del Programa Putty se muestran en el Anexo1,

sección 10.4).

� Descargar el software de la Web

� Configurar la conexión al servidor, esto incluye la dirección IP, protocolo a usar y

nombre para guardar esa configuración. (Los detalles se muestran en el Anexo1,

sección 10.4)

• Manejo de la Base de Datos

Para la administración de la base de datos se usó la herramienta MySQL Front ya que a través

de su interfaz se pueden realizar tareas como la obtención de información del contenido y estructura

de las tablas, así como acciones básicas de añadir, modificar o borrar campos o tablas.

� Se descargó el software de la Web.

� Se instaló el archivo ejecutable.

� Se configuró la conexión al servidor. (Para mayores detalles de la instalación ver

Anexo1, sección 10.7 ).

• Ngrep

Esta herramienta permite hacer un monitoreo de la red, es decir se puede analizar el tráfico de

la red de manera similar a como lo hacen otros “sniffers” de red. Usando capacidades avanzadas de

comparación de strings, Ngrep puede capturar los paquetes que se encuentran dentro de la red.

� Se descargó de la web y se instaló el paquete ngrep-1.44-1.tar.bz2

� Se instaló el programa en el servidor. Para detalles acerca del proceso de instalación

de Ngrep, ver Anexo1, sección 10.5.

• Ethereal

Otro programa empleado para hacer el monitoreo de la red es Ethereal. Consiste en un

potente analizador de protocolos de redes para máquinas Unix y Windows que permite realizar análisis

y solucionar problemas en redes de comunicaciones. Puede capturar los datos directamente de la red

u obtener la información a partir de una captura realizada en disco [46]. Además permite ver todo el

tráfico que pasa a través de una red mediante una interfaz gráfica, incluyendo además muchas

opciones para la organización y el filtrado de la información.

- 43 -

• Softphone Xlite

� Se descargó de la web el paquete X-Lite_Win32_1006e_340255.

� Se instaló el Programa.

� Se configuraron las opciones necesarias para el correcto funcionamiento del

softphone. (Para mayores detalles ver Anexo1, sección 10.8)

• Generación de Tráfico para el Protocolo SIP

A fin de determinar el tráfico del protocolo SIP soportado por la aplicación desarrollada, fue

necesario hacer pruebas de tráfico. Para ello se utilizó el programa SIPp, esta herramienta de prueba

permite crear múltiples llamadas usando los métodos INVITE, y BYE. En el Anexo1, sección 10.9 se

muestra la explicación del uso del programa.

4.4.2. Aplicación Web

Para el desarrollo de la Aplicación Web fue necesario trabajar con la herramienta Macromedia

Dreamweaver como editor de HTML para el diseño visual y la administración de sitios6 y páginas Web.

Para cargar el sitio en el Servidor Web, se puede usar Dreamweaver con FTP, de esta forma se

pueden controlar y mantener automáticamente los vínculos, a medida que se realicen modificaciones

en las páginas.

• Delimitación de la funcionalidad de la página Web.

• Diseño de cada una de las páginas que conforman la aplicación Web del administrador

de OpenSER.

• Codificación en lenguaje PHP y HTML de la aplicación Web.

4.4.3. Manuales Técnico y Web

Para poder documentar todo el trabajo realizado, tanto del servidor como de la aplicación

Web, se desarrollaron dos manuales, uno llamado Manual de OpenSER (ver Anexo 1) y el otro Manual

SerWeb del Administrador (ver Anexo 2).

En el primer manual se muestra, con detalle, todo lo referente a la configuración del OpenSER

y uso del servidor, instalación y uso de programas usados, instalación de plataforma usada y

diversidad de herramientas para el manejo de la aplicación desarrollada.

En el segundo manual se detalla acerca de la creación de la aplicación Web así como también

las herramientas usadas para la misma, además de ahondar en el uso correcto de la aplicación.

4.5. Verificación y Pruebas. Para comprobar el correcto funcionamiento de la aplicación debieron hacerse diversas pruebas.

Las mismas se mencionan a continuación:

5 Aplicación que simula un teléfono IP. 6 Conjunto de documentos vinculados con atributos compartidos.

- 44 -

4.5.1. Funcionamiento de la aplicación

• Se verificó el correcto funcionamiento de cada regla de enrutamiento.

• Se verificó el correcto funcionamiento entre la base de datos y OpenSER.

• Se comprobó la correcta salida de llamadas hacia teléfonos fijos y móviles.

4.5.2. Página Web A medida que la página Web se fue construyendo, se verificó el correcto funcionamiento a

nivel de redireccionamientos hechos por los links, y la restricción de acceso a la página mediante la

petición de usuario y clave.

Se comprobó el correcto funcionamiento de la configuración de OpenSER vía Web. Esto abarca

la correcta inclusión del código escrito vía Web en el archivo de configuración de OpenSER mediante

los puntos de inserción7.

4.5.3. Pruebas de tráfico

• Se utilizó el programa SIPp Para la evaluación cuantitativa del número de llamadas

simultáneas (mensajes SIP) que OpenSER está en capacidad de manejar.

• Se fue aumentando el número de llamadas concurrentes hasta que el servidor dejó de

responder exitosamente.

• Se anotaron los resultados obtenidos.

7 Indica en qué parte del archivo se va a escribir el código

CAPÍTULO V: RESULTADOS

5.1. Selección de las herramientas

Después de haber realizado y analizado la tabla comparativa expuesta en el Capítulo 3 en la

sección 3.11, se puede observar que todos los softwares investigados tienen en común un esquema de

desarrollo bajo el concepto de software libre, es decir son programas en los cuales el usuario puede

disponer del código fuente sin restricciones y que puede a su vez modificar y redistribuir sin

limitaciones. Esto, asociado a una serie de ventajas entre las cuales se pueden mencionar:

� Al disponer del código fuente de los programas en su totalidad, éstos pueden ser

analizados por terceras personas ajenas a sus autores en busca de fallas de diseño o de

implementación.

� La posibilidad de realizar modificaciones libremente al código fuente y distribuirlas permite

que cualquiera pueda ofrecer mejoras sobre éste. Estas mejoras pueden ser nuevas

funcionalidades que se incorporen al mismo o parches que corrijan problemas detectados

anteriormente [47].

� La posibilidad de modificar libremente el software permite que las organizaciones lo

adapten a sus propias necesidades, pudiendo eliminar funcionalidades que no le sean de

interés. En el mundo de la seguridad existe el postulado de “lo más sencillo es más

seguro”; por esta razón el poder eliminar funciones innecesarias de las herramientas las

puede convertir de forma inmediata en más seguras (porque no podrán ser utilizadas

estas funcionalidades para subvertirlas) [47].

� Las características del software libre hacen que no sea lógico cargar costes sobre el

software en sí (dado que se distribuye sin cargo), lo que permite que este tipo de software

pueda ser utilizado por organizaciones y personas con menos recursos económicos. Esto

se presenta como una ventaja cuando se compara con los precios de lo que cuesta el

software de seguridad propietario hoy en día (licencias de firewalls, vpns, sistemas de

detección de intrusos, entre otras). El software libre pone en manos de cualquiera el tipo

de tecnología que, hoy por hoy, sólo podrían tener grandes corporaciones [47].

Luego de esto, se tuvo que decidir cuál de los softwares investigados debía ser el utilizado

para el desarrollo del Servidor Proxy SIP. Después de realizar un análisis detallado para los softwares

en función de las características ofrecidas por cada uno así como las necesidades de CANTV y el

conocimiento que se tenía en la empresa de cada uno de ellos, se decidió escoger OpenSER como

solución a la aplicación Proxy SIP.

OpenSER constituye uno de los proyectos líderes en lo que se refiere a un Servidor SIP de

código abierto. Presenta un gran conjunto de características y funcionalidades, que se encuentran

sostenidas por un desarrollo constante. Además está soportado por una amplia comunidad de usuarios

- 46 -

alrededor del mundo. Este programa puede ser ejecutado en diversos Sistemas Operativos como

Linux, FreeBSD, OpenBSD, NetBSD, y Solaris [40]. Al ser OpenSER una aplicación de licencia libre, el

mismo se pudo descargar de la página web oficial sin mayores inconvenientes.

Luego de haber identificado el software a utilizar para la aplicación a desarrollar fue necesario

delimitar cómo y qué iba a incluir la misma. Esto se refiere específicamente a los módulos necesarios,

los parámetros a configurar y las rutinas a desarrollar con el fin de que OpenSER funcionara como

Servidor Proxy.

Para la facilitar la verificación del funcionamiento de OpenSER resultó fundamental contar con

un NGREP como programa de captura del tráfico que pasa por la red. Esta herramienta permite

detectar a través de la traza de la llamada (en caso de que la misma no pueda completarse) en qué

punto se está produciendo la falla.

Para la gestión de la base de datos de OpenSER se utilizó MySQL Front debido a que permite

manejar y darle mantenimiento de una forma más amigable a las tablas existentes en la misma.

Debido a que inicialmente el servidor estaba en una ubicación física lejana, fue necesario

utilizar Putty como herramienta para el acceso remoto al servidor.

Paralelamente a la configuración de OpenSER se fue diseñando y desarrollando la aplicación

Web del administrador usando como herramienta de diseño el programa Macromedia Dreamweaver

MX 2004. Mediante esta página Web se le permite al administrador manejar externamente OpenSER,

es decir la inclusión de nuevas rutinas y reglas de enrutamiento, así como módulos y parámetros, sin

necesidad de tener que acceder vía consola al archivo de configuración. Así mismo, se puede tener un

manejo de la base de datos, en lo que se refiere a la inclusión, modificación o eliminación de prefijos

numéricos usados para el enrutamiento de las llamadas, en función de las reglas que se hayan

desarrollado.

Un aspecto muy importante es que además de la ejemplificación realizada resultaba

fundamental para CANTV la realización de un manual Técnico que englobara todo lo referente al

proyecto desarrollado. De acuerdo con esto, se planteó que el manual a realizar debía seguir a grosso

modo la estructura descrita a continuación:

• Pasos para la instalación de las herramientas utilizadas.

• Pasos para la instalación de OpenSER.

• Información básica de OpenSER: ubicación de los archivos, secciones de OpenSER, sintaxis

para las reglas de enrutamiento.

• Servicios involucrados con el funcionamiento de OpenSER.

• Pruebas para verificar el correcto funcionamiento de la aplicación.

• Realización de la página Web.

• Manejo de la aplicación Web.

• Código de la ejemplificación con su respectiva explicación.

- 47 -

La finalidad de este manual técnico era que quedara asentado por completo el manejo de

OpenSER, desde el proceso de instalación del Sistema Operativo en el servidor, hasta la puesta en

funcionamiento de la aplicación. De esta forma CANTV se podía asegurar de contar con un Servidor

SIP del cual tuviesen un total dominio, con la garantía de poder minimizar el tiempo necesario para la

instalación y puesta en funcionamiento del mismo. Dicho manual se encuentra en el Anexo 1.

Una vez culminado el desarrollo de la aplicación, así como el correcto funcionamiento de la

misma, se pensó que era necesario hacer un análisis a manera de determinar el promedio de llamadas

concurrentes que OpenSER está en capacidad de manejar de forma exitosa. Para ello se descargó de

la web el software SIPp que como se mencionó en la sección 4.4.1, es una herramienta de prueba que

permite generar tráfico del protocolo SIP. En la Figura 25 se muestra la lógica de envío de los

mensajes SIP.

Para la realización de esta prueba es necesario instalar SIPp en dos computadoras. Una de

ellas actúa como Servidor, y la otra como Cliente.

En la PC que actúa como servidor se configura el número de llamadas por segundo que se

quieren realizar así como el tiempo estimado de cada una de ellas, en función de esto, dicha máquina

enviará a OpenSER los mensajes SIP. Para el momento de la prueba es necesario que el archivo de

configuración de OpenSER contenga una rutina que desvíe todas las peticiones de llamadas (para ello

reenvía las peticiones SIP) hacia el dominio donde se encuentra instalado SIPp como cliente. Luego de

que las peticiones son enviadas por la PC que actúa como servidor se puede observar a través de la

consola el número de llamadas que OpenSER reenvió exitosamente.

En función de ello, mediante las pruebas realizadas se buscaba estimar el promedio de

llamadas que OpenSER es capaz de manejar.

Figura 25. Lógica de envío de los mensajes SIP para las pruebas de tráfico

5.1.1. OpenSER

Para esta aplicación se investigaron cuáles eran los requerimientos de hardware y las

arquitecturas que soportaba a fin de garantizar el correcto funcionamiento de la misma. Éstas se

muestran a continuación:

PC SIPp Cliente UAC

Servidor OpenSER

161.196.58.48

PC SIPp Servidor UAS

Envía peticiones SIP Reenvía peticiones SIP

Monitoreo

- 48 -

Arquitecturas:

• Linux/i386, Linux/armv4l, FreeBSD/i386, OpenBSD/i386, Solaris/sparc64, NetBSD/sparc64

(Para otras arquitecturas los Makefiles pueden necesitar ser corregidos). Hay varias opciones

de configuración definidas en el Makefile.

Requerimientos:

• gcc o icc: gcc≥2.9x; 3.[12] recomendada (Trabajará con versiones anteriores pero requiere la

modificación de algunas opciones para un mejor funcionamiento).

• Bison8 ó Yacc9 (Berkley Yacc).

• Flex10.

• GNU11 make (en Linux corresponde al estándar “make”, en FreeBSD y Solaris “gmake”)

Versión ≥3.79.

• Sed12 y Tr13 (usado en los makefiles).

• GNU tar (“atar en Solaris”) y gzip si es necesario ejecutar “make tar” para trabajar.

• Instalación GNU ó BSD14 (en Solaris “ginstall”) si se quiere hacer “make install”, “make bin”,

“make sunpkg”.

• Openssl si se quiere compilar con soporte TLS.

• Libmysqlclient & libz (zlib) si se quiere el soporte de la base de datos MySQL (Módulo MySQL).

• Libpq / Postgresql si se quiere el soporte de la base de datos Postgres. (Módulo Postgres).

• Unixodbc si se quiere el soporte de la base de datos Unixodbc (Módulo Unixodbc).

• Libexpat si se quiere tener el soporte del gateway Jabber (Módulo Jabber).

• Libxml2 si se quieren usar los módulos cpl-c (Lenguaje de Procesamiento de Llamada) y pa

(Agente de Presencia).

5.1.2. Dreamweaver

Sistema Operativo y detalles de los requerimientos:

• Microsoft Windows 2000 / XP – Pentium III – 800 MHz – RAM 256 MB – HD 650 MB

• Apple MacOS X 10.3 – PowerPC G3 – 600MHz – RAM 256 MB – HD 300 MB

• Apple MacOS X 10.4 – PowerPC G3 – 600 MHz – RAM 256 MB – HD 300 MB

• Periféricos: Monitor XGA

8 Generador de Analizadores Sintácticos. 9 Generador de analizador léxico y sintáctico 10 Fast Lexical Analizer. herramienta para la generación de programas que realizan concordancia de patrones en texto [47]. 11 GNU´s Not Unix. Sistema Operativo no libre, totalmente compatible con Unix. 12 Editor especial para modificar archivos de forma automática. 13 Comando para traducir o borrar caracteres. 14 Berkeley Software Distribution. Sistema Operativo derivado del sistema Unix.

- 49 -

5.1.3. Ngrep

Ngrep está disponible en muchas plataformas Unix y Win32. En la Tabla 3 se muestran los

requerimientos del programa.

Sistema Operativo Arquitectura

Linux 2.0 – 2.6 X86, SPARC, Alpha, MIPS

MacOS X + PowerPC

Solaris 2.5.1 + X86, SPARC

FreeBSD 2.2.5 + X86

OpenBSD 2.4 + X86, SPARC

NetBSD 1.5 + X86

Digital Unix V4.0D (OSF/1),

Tru64 UNIX 5.0 & 5.1A Alpha?

HPUX 11 PA-RISC

IRIX MIPS

AIX 4.3.3.0 PowerPC

BeOS version 5 X86

Windows 95, 98, NT, 2000, XP,

2003 X86

Tabla 3. Plataformas soportadas por Ngrep [49]

5.1.4. MySQL Front y Putty:

Soporta las plataformas: Win95/98/NT/ME/2000/XP

5.1.5. SIPp

Soporta las plataformas: UNIX: HPUX, Tru64, Linux (Red Hat, Debian, FreeBSD),

Solares/SunOS.

5.2. Archivo de Configuración La verificación del funcionamiento de OpenSER se realizó en varios pasos. Para que OpenSER

se ejecute en el servidor es necesario iniciar el servicio “openser”. Cada vez que el archivo de

configuración es modificado es necesario detener y volver a iniciar el servicio. Por esto mismo, la

primera prueba a realizar es constatar que el archivo de configuración esté funcionando correctamente

y sin errores de compilación. En caso de realizar alguna modificación al archivo de configuración es

necesario reiniciar el servicio. Si se obtiene un error al iniciarlo, como se muestra en la Figura 26,

quiere decir que ocurrió algún problema a la hora de subirlo, el más común es el de error en la sintaxis

- 50 -

del archivo de configuración por lo cual será necesario revisarlo y hacer las correcciones

correspondientes.

Figura 26. Error de compilación del archivo de configuración

Luego de que el archivo es compilado exitosamente se habrá superado la primera etapa de las

pruebas del archivo de configuración de OpenSER.

Posteriormente se plantearon posibles escenarios, de acuerdo a ciertas reglas de enrutamiento

requeridas por la compañía, con el fin de verificar que efectivamente OpenSER está trabajando como

se desea.

Para verificar el correcto funcionamiento se analiza conjuntamente la traza de la llamada

realizada con los mensajes de diálogo. Los mensajes de diálogo se incluyen en las rutinas de openser,

los mismos sirven para la depuración de errores ya que mediante ellos se puede ir haciendo el

seguimiento de la ejecución del código. Referente a la traza, a través de la misma se observa en

detalle el envío secuencial de los mensajes SIP entre cada uno de los elementos involucrados.

Pudiendo entonces detectar, ante una falla, cuál es el elemento que está generando problemas.

5.2.1. Diseño Tomando en cuenta las necesidades de la empresa se organizaron una serie de reglas para

poder cumplir con las mismas, éstas se muestran en un diagrama de flujo para así poder reorganizar

las ideas y desarrollar la codificación del archivo de configuración.

En la Figura 27 se expone un diagrama general donde se muestra el papel que juega el

servidor SIP Proxy implementado configurado en OpenSER.

Figura 27. Diagrama General del Archivo de configuración

En la Figura 28 se muestra un diagrama de la estructura general del archivo de configuración

de Openser.

TOMA DE DECISIÓN (Archivo

Configuración OpenSER)

Llega un mensaje SIP

Se envía un mensaje SIP (respuesta)

- 51 -

Figura 28. Estructura general del Archivo de Configuración de OpenSER

Cuando el método del mensaje recibido es INVITE, el servidor empieza a realizar un chequeo

basándose en las reglas descritas en él para así poder tomar una decisión, este proceso se conoce

como enrutamiento por medio de reglas, el cual es mostrado en la Figura 29 mediante un diagrama de

flujo.

Mensaje SIP

10 Reenvíos?

Mensaje SIP “483, Too Many Hops”

SI

Mensaje SIP “513, Message too big”

Mensaje mayor a 2048 bytes?

SI

NO

SI

NO

Method = NOTIFY?

NO

Mensaje SIP “200, OK”

Enrutamiento (ver más adelante)

SI

Method = OPTIONS?

NO

Route 1 SI

Method = CANCEL?

Method = BYE?

Terminar la llamada SI

SI

NO

NO

Method = REGISTER?

NO

Autorizado?

Mensaje SIP “200, OK”

Mensaje SIP “401, Unauthorized”

SI

SI

NO

Method = INVITE?

NO

Salir

- 52 -

Figura 29. Proceso de revisión y enrutamiento por reglas.

Después de revisar que proceso está activo se procede a ejecutar la regla como tal, se pueden

ejecutar varios procesos a la vez, comentando o no los mismos. En la Figura 30 se muestra el

Enrutamiento por URI, en la Figura 31 el Enrutamiento por FROM, en la Figura 32 el Enrutamiento por

TO, en la Figura 33 el Enrutamiento por HORA y por último, en la Figura 34 se muestra el

Enrutamiento por Compartición de Carga.

URI (ACTIVO)

URI = regla 1? INVITE dominio 1 SI

INVITE dominio 2 URI = regla 2? SI

NO

URI = regla 3?

NO

INVITE dominio 3 SI

URI = regla X?

NO

INVITE dominio X SI

NO

Route 1

Method = INVITE

Por URI? ENRUTAMIE NTO POR URI

SI

ENRUTAMIENTO POR FROM Por FROM?

SI

NO

Por TO?

NO

ENRUTAMIENTO POR TO

SI

Por HORA?

NO

ENRUTAMIENTO POR HORA

SI

Compartición de Carga?

ENRUTAMIENTO POR COMPARTICIÓN DE

CARGA

SI

NO

NO

Route 1

- 53 -

Figura 30. Enrutamiento por URI

Figura 31. Enrutamiento por FROM


TO (ACTIVO)

TO = regla 1? INVITE dominio 1 SI

INVITE dominio 2 TO = regla 2? SI

NO

TO = regla 3?

NO

INVITE dominio 3 SI

TO = regla X?

NO

INVITE dominio X SI

NO

Route 1

FROM (ACTIVO)

FROM = regla 1? INVITE dominio 1 SI

INVITE dominio 2 FROM = regla 2? SI

NO

FROM = regla 3?

NO

INVITE dominio 3 SI

FROM = regla X?

NO

INVITE dominio X SI

NO

Route 1

- 54 -



COMPARTICIÓN DE CARGA (ACTIVA)

REGLA COMPARTICIÓN

= regla 1? INVITE dominio 1

SI

INVITE dominio 2 REGLA HORA =

regla 2? SI

NO

REGLA HORA = regla X?

NO

INVITE dominio X SI

NO

Route 1

HORA (ACTIVO)

REGLA HORA = regla 1? INVITE dominio 1

SI

INVITE dominio 2 REGLA HORA =

regla 2? SI

NO

REGLA HORA = regla 3?

NO

INVITE dominio 3 SI

REGLA HORA = regla X?

NO

INVITE dominio X SI

NO

Route 1

- 55 -

5.2.2. Posibles Escenarios para la Ubicación del OpenSER dentro de la Red de CANTV.

A continuación se exponen algunos posibles escenarios para la futura implementación del

servicio del SIP Server OpenSER.

En la Figura 35. Se muestra a OpenSER entre el Servidor SIP y el Servidor de Aplicaciones.

Openser tendría como función modificar los parámetros del encabezado de los mensajes de

señalización que llegan desde el Servidor SIP para luego ser enviados al servidor de aplicaciones.

Figura 35. Posible escenario de Ubicación del OpenSER dentro de la Red de CANTV

En la Figura 36 se muestra al OpenSER entre el “softswitch” SoftX3000 y el Servidor de

Aplicaciones. De igual forma que el escenario anterior, OpenSER tendría como función modificar

parámetros del encabezado de los mensajes de señalización que llegan desde el “softswitch”

SoftX3000 y que posteriormente envía al Servidor de Aplicaciones.

Backbone IP

PSTN

ITSP SIP/H.323

SS7

INTERNET

ABA Voz

UMG

SBC

Central

Servidor de Aplicación de Tarificación

POTS

SIP

MGCP

H.323

M2UA(SIGTRAN)

E1(TDM/SS7)

OpenSER Servidor SIP Proxy

Servidor SIP

“softswitch”

SoftX3000

- 56 -


En la Figura 37 se muestra al OpenSER entre el Servidor de Aplicaciones y el “softswitch”

SoftX3000, en este escenario, OpenSER funcionaría como puente de conexión entre ambas

aplicaciones pudiendo así modificar parámetros del encabezado de los mensajes de señalización.

Backbone IP

PSTN

ITSP SIP/H.323

SS7

INTERNET

ABA Voz

UMG

SBC

Central

Servidor de Aplicación de Tarificación

POTS

SIP

MGCP

H.323

M2UA(SIGTRAN)

E1(TDM/SS7


“softswitch”

SoftX3000 Servidor SIP

- 57 -


Existen otras posibles ubicaciones aunque todavía están siendo evaluadas y chequeadas de

forma de que alguno de los servicios no vaya a fallar a la hora de introducir el OpenSER.

5.2.3. Pruebas de Configuración Después de desarrollar todos los diagramas se comenzó con la configuración del archivo de

OpenSER, para luego probar cada una de las reglas y poder constatar que el arreglo elaborado era

eficiente y cumplía con los requisitos necesarios. Para elaborar las pruebas se diseñó un diagrama,

mostrado en la Figura 38, con el cual se trabajó para probar cada parte del programa.

Backbone IP

PSTN

ITSP SIP/H.323

SS7

INTERNET

ABA Voz

UMG

SBC

Central

App Server Rating

POTS

SIP

MGCP

H.323

M2UA(SIGTRAN)

E1(TDM/SS7)


“softswitch” SoftX3000

Servidor SIP

- 58 -

Figura 38. Esquema general de Pruebas

La primera etapa de las pruebas consiste en revisar que el archivo de configuración no

presente ningún error en la sintaxis, para ello, cada vez que se modifica cualquier parte del mismo, el

servicio OpenSER debe reiniciarse. Si se presenta algún error, como lo indica la Figura 26, debe

revisarse el log del OpenSER y depurar el error allí mostrado. Para mayor información ir al Anexo1

sección 6.2 del Manual de OpenSER.

La segunda etapa de las pruebas consiste en corroborar el correcto funcionamiento de

OpenSER, después de haber conseguido un reinicio del sistema exitoso. Estas pruebas consisten en:

• Probar cada sección del archivo de configuración.

• Probar que las trazas de las llamadas sean las correctas.

• Probar que las llamadas hechas son recibidas por teléfonos en la red PSTN.

• Probar la capacidad de tráfico que soporta el servidor.

Para probar cada sección del archivo de configuración se procedió a colocar líneas de

mensajes en el mismo para que estas salgan impresas en el log del servicio. Esto se hace para realizar

un seguimiento desde el archivo de mensajes y poder ver cuál sección se está ejecutando y cuál no.

REVISIÓN DEL ARCHIVO DE

CONFIGURACIÓN

COMPILA? NO

PRUEBAS ESPECÍFICAS PARA CADA RUTINA

SI

LA RUTINA SE EJECUTA

CORRECTAMENTE?

NO

SIGUIENTES PRUEBAS

SI

SI

FIN

SE TERMINARON LAS PRUEBAS?

NO

- 59 -

Cuando no se ejecutaba una regla se procedía a cambiar el archivo de configuración. Para mayores

detalles ver las secciones 6.2 y 6.3 del Anexo1.

Para verificar que las llamadas salieran a la PSTN se utilizó el programa Asterisk como gateway

para poder reenrutar las llamadas generadas por el OpenSER hacia la PSTN, (esto se logró gracias a

un número que se registró con el servicio ABA voz por medio del cual las llamadas realizadas salían al

exterior, ver Figura 39, con esto se usaba un numero registrado dentro del dominio de OpenSER y se

realizaban llamadas a números fijos y teléfonos celulares, presentando los resultados generales

mostrados en la Tabla 4, donde la calidad alcanzada tiene la más alta ponderación. Se está utilizando

la escala deficiente, suficiente y buena, y dentro del retardo se tiene la escala muy apreciable,

apreciable, poco apreciable y no apreciable. Con esto se puede decir que la calidad del servicio, en

conjunto, es bastante buena.

Figura 39. Diagrama de conexión para la prueba de llamadas salientes.

Número telefónico Calidad de Voz Retardo Locales Buena No apreciable Celulares Buena Poco apreciable Nacionales Buena Poco apreciable

Tabla 4. Tabla de resultados obtenidos de llamadas realizadas

Para probar que las trazas de las llamadas fueran las correctas, se utilizó un programa llamado

Ngrep, instalado en el servidor SIP para poder así monitorear los mensajes SIP recibidos y enviados

por el servidor, con el cual se podía revisar con exactitud el desenvolvimiento de la herramienta. Así se

podía establecer la ruta seguida por los mensajes y corregir el error en el enrutamiento del mismo.

Para mayor información ver la sección 6.4 del Anexo1.

Teléfono IP

OpenSER

Asterisk

ABA voz

Teléfono PSTN

Realiza una llamada IP

Envía una petición

Se registra con un número asignado

Realiza una llamada a través de la PSTN

Reenvía la petición recibida

- 60 -

En las Figuras 40, 41, 42 y 43; se muestran los diagramas de flujo de llamada, construidos con

los mensajes y peticiones enviados por los servidores tomados éstos de las trazas que se encuentran

en los Anexos 3, 4, 5 y 6 respectivamente.

Figura 40. Flujo de Mensajes entre teléfono IP y número en la PSTN (éste cuelga)

Figura 41. Flujo de Mensajes entre teléfono IP (éste cuelga) y número en la PSTN

OpenSER Asterisk ABA Voz

INVITE INVITE INVITE

TRYING TRYING TRYING

ACK

SESSION PROGRESS SESSION PROGRESS SESSION PROGRESS RINGING RINGING RINGING

Teléfono IP Teléfono PSTN

RINGING

200 OK 200 OK 200 OK

LLAMADA

BYE BYE

BYE

200 OK 200 OK 200 OK




ACK

SESSION PROGRESS SESSION PROGRESS SESSION PROGRESS RINGING RINGING RINGING

Teléfono IP Teléfono PSTN

RINGING

200 OK 200 OK 200 OK

LLAMADA

BYE BYE BYE 200 OK

200 OK 200 OK

- 61 -

Figura 42. Flujo de Mensajes entre teléfono IP y número celular (éste cuelga)

Figura 43. Flujo de Mensajes entre teléfono IP (éste cuelga) y celular.

Como última prueba se generó trafico sobre el servidor para ver la respuesta obtenida ante

una prueba de stress. Con esto se pudo conocer un estimado de cuántas llamadas soporta el servidor

en una hora pico.




ACK

SESSION PROGRESS SESSION PROGRESS SESSION PROGRESS

Teléfono IP

RINGING

200 OK 200 OK 200 OK

LLAMADA

BYE BYE

BYE

200 OK 200 OK 200 OK

Teléfono Celular




ACK

SESSION PROGRESS SESSION PROGRESS SESSION PROGRESS

Teléfono IP

RINGING 200 OK 200 OK 200 OK

LLAMADA

BYE BYE BYE 200 OK

200 OK 200 OK

Teléfono Celular

- 62 -

Para realizar la prueba se usó la herramienta SIPp la cual genera el tráfico adecuado para ir

analizando la respuesta obtenida por el OpenSER. Para conocer la respuesta del servidor se trabajó

con los valores mostrados en la Tabla 5. Donde la columna “llamadas por segundo” representan, como

su nombre lo indica, la cantidad de llamadas que el servidor recibirá por segundo; la columna

“duración promedio de la llamada” indica el tiempo estimado de duración de cada llamada; la columna

“erlang” es una medida de densidad de tráfico la cual describe el volumen total de tráfico que existe

en una hora; la columna “cantidad de llamadas concurrentes”, como su nombre lo indica, es la

cantidad de llamadas que se establecen o se mantienen en el mismo instante y por último, la columna

“soporte” implica si el servidor funcionó correctamente al tráfico generado sobre él.

LLAMADAS POR SEGUNDO

(calls/sec)

DURACIÓN PROMEDIO DE LA LLAMADA (seg)

ERLANG

⋅

3600

)( duraciónllamadas

LLAMADAS CONCURRENTES (aproximado ±6)

SOPORTE

20 120 2400 2400 SI 30 120 3600 3600 SI 32 120 3840 3840 SI 34 120 4080 4080 SI 35 120 4200 4200 SI 38 120 4560 4560 SI 30 180 5400 5400 SI 32 180 5760 5760 SI 33 180 5940 5940 SI 34 180 6120 6120 SI 35 180 6300 6300 NO 50 180 9000 9000 NO

Tabla 5. Pruebas con SIPp

Al momento de iniciar la herramienta se muestra una pantalla como la mostrada en la Figura

44, donde:

1: Aparecen todas las especificaciones de la prueba, la cantidad de llamadas por segundo, la

cantidad de llamadas concurrentes, los puertos abiertos, la IP usada, la cantidad pico de llamadas y el

momento en el cual ocurrió.

2: Se muestran los mensajes enviados y recibidos por la herramienta.

3: Se observan las estadísticas de tiempo resultantes de la prueba.

4: El resumen global del total de llamadas realizadas durante la prueba.

- 63 -

Figura 44. Partes de pantalla de pruebas.

A continuación se muestran los resultados obtenidos en algunas de las pruebas:

• Prueba 1: 20 calls/seg. con 120 seg. de duración de la llamada, en la Figura 45 se puede

apreciar el escenario del servidor UAC.

1

2

3

4

- 64 -

Figura 45. Resultados UAC Prueba 1

• Prueba 2: 30 calls/seg. con 120 seg. de duración de la llamada, en la Figura 46 se puede

apreciar el escenario del servidor UAC y en la Figura 47 se observa el consumo del servidor

cuando se está manejando esa cantidad de llamadas (se usa el comando “top” en la consola).

- 65 -


- 66 -

Figura 47. Consumo de memoria del Servidor

• Prueba 3: 32 calls/seg con 120 seg de duración de la llamada, en la Figura 48 se puede

apreciar el escenario del servidor UAC y en la Figura 49 se muestra el consumo del servidor

cuando se está manejando esa cantidad de llamadas.

- 67 -


- 68 -



observa el escenario del servidor UAC y en la Figura 51 se puede apreciar el consumo del

servidor cuando se está manejando esa cantidad de llamadas.

- 69 -


- 70 -


• Prueba 5: 35 calls/seg con 120 seg de duración de la llamada, en la Figura 52 muestra el

escenario del servidor UAC y en la Figura 53 se observa el consumo del servidor cuando se

está manejando esa cantidad de llamadas.

- 71 -


- 72 -



apreciar el escenario del servidor UAC y en la Figura 55 se observa el consumo del servidor


- 73 -


- 74 -



apreciar el escenario del servidor UAC.

- 75 -



observar el escenario del servidor UAC.

- 76 -


• Prueba 9: 33 calls/seg con 180 seg de duración de la llamada, en la Figura 58 se muestra el

escenario del servidor UAC y en la Figura 59 se puede apreciar el consumo del servidor cuando

se estan manejando esa cantidad de llamadas.

- 77 -


- 78 -

Figura 59. Consumo de Memoria del Servidor.


apreciar el escenario del servidor UAC y en la Figura 61 se puede ver el consumo del servidor


- 79 -


- 80 -

Figura 61. Consumo de Memoria del Servidor.

5.3. Página Web

5.3.1. Diseño

Luego de evaluar las funcionalidades requeridas por el administrador para la aplicación web,

se determinó que la misma debía incluir básicamente dos opciones, como se muestran en la Figura 62

y en la Figura 63.

- 81 -

Figura 62. Diagrama de las funciones de la página Web.

• Cambiar los prefijos de Enrutamiento.

• Modificar el archivo de configuración de OpenSER.

Página de Inicio de Sesión

Modificar Archivo de Configuración

Cambiar Prefijos de Enrutamiento

Se puede seleccionar

Insertar:

Links Asociados:

* Enrutamiento por URI * Enrutamiento por FROM * Enrutamiento por TO * Enrutamiento por HORA * Enrutamiento por Repartición de Carga

Está formado por

* Módulo * Parámetro * Regla de Enrutamiento por URI * Regla de Enrutamiento por FROM * Regla de Enrutamiento por TO * Regla de Enrutamiento por HORA * Regla de Enrutamiento por Repartición de carga

* Ver más información * Ver código * Ver dependencias entre módulos

Seleccionar

Dentro de cada página a seleccionar

tenemos:

* Tabla con Prefijos Existentes * Opciones para los prefijos: * Agregar * Editar * Link para Archivo de configuración

- 82 -

Figura 63. Opciones para el administrador en la página web

5.3.2. Modificación del archivo de configuración de OpenSER

La primera opción le permite al administrador de OpenSER modificar el archivo de

configuración, bien sea agregar ó eliminar código, con la ventaja de que puede hacerlo directamente

desde dicha página.

En la página de modificación del archivo de configuración de OpenSER, ver Figura 64, se

decidió además, agregar tres links que contienen información relacionada con el desarrollo del archivo

de configuración.

Ver más información: contiene un resumen de la sintaxis básica a seguir para agregar un

módulo, modificar un parámetro, desarrollar una regla de enrutamiento, entre otras. Si se desean

mayores detalles será necesario dirigirse al Manual de OpenSER.

Ver Código: le ofrece la ventaja al administrador de visualizar en un archivo de texto la

configuración actual de OpenSER.

Dependencias entre módulos: en este archivo de Word se encuentra un resumen de los

módulos que conforman OpenSER y las dependencias existentes entre ellos, con el fin de facilitarle al

administrador el proceso de inclusión de módulos en el archivo de configuración.

- 83 -

Figura 64. Página para la modificación del archivo de configuración

Para la modificación del archivo de configuración, el administrador deberá elegir alguna de las

opciones, y posteriormente escribir el código en el cuadro de texto. De esta forma, el código escrito se

incluirá en el lugar adecuado en el archivo de configuración.

La Página Principal de Enrutamiento, ver Figura 65, permite al administrador tener un

completo manejo de la base de datos donde se encuentran almacenados los dominios

correspondientes a cada prefijo y tipo de enrutamiento. De esta forma, el administrador podrá

escoger mediante una lista desplegable el tipo de enrutamiento con el que desea trabajar. De acuerdo

con el diseño desarrollado, luego de elegir el tipo de enrutamiento se hace un redireccionamiento a la

página (Ver Figura 66) donde se mostrarán los prefijos existentes para ese tipo de enrutamiento, y

donde además se podrá agregar un nuevo prefijo, y editar o eliminar un prefijo existente.

- 84 -

Figura 65. Página Principal de Enrutamiento

- 85 -

Figura 66. Opciones para un enrutamiento en específico

Luego de que un prefijo es modificado o agregado, se hace un redireccionamiento a la página

del enrutamiento correspondiente, en la que se podrá ver la tabla actualizada de los prefijos.

CAPÍTULO VI: CONCLUSIONES Y RECOMENDACIONES

Luego de que se culminaron y alcanzaron todos los objetivos que fueron propuestos para el

proyecto de pasantía, resulta importante resumir los puntos más relevantes que se desprendieron del

mismo. En este capítulo se presentan algunas de las conclusiones a las cuales se llegó, así como

algunas recomendaciones relacionadas con los puntos más significativos que se abarcaron durante la

pasantía.

Primero, podemos señalar que se cumplieron todos los objetivos planteados al inicio de la

pasantía, con lo cual se concreta la posibilidad de implementar un servidor “Proxy” SIP para el

enrutamiento de llamadas VoIP propio de CANTV y del cual se tenga un completo dominio.

La herramienta desarrollada es de gran utilidad y potencialidad para la comunicación entre

servidores dentro de la misma compañía sin tener que involucrar a un proveedor o depender del

mismo. Además con ella, se pueden desarrollar servicios que actualmente dependen de algunos

proveedores para así tener control absoluto de ellos.

La investigación teórica realizada en las primeras semanas de pasantía permitió ampliar los

conocimientos en aspectos relacionados a los sistemas VoIP y al protocolo de señalización SIP.

Además, constituyó la base mediante la cual se pudo definir cuál sería la solución existente en el

mercado usada para el desarrollo del proyecto.

Al estudiar más en detalle las distintas soluciones comerciales para el desarrollo del servidor

Proxy SIP, se determinó que OpenSER era la solución que mejor se perfilaba. Esto debido a que

presentaba una buena documentación además de una amplia comunidad de usuarios. Sin embargo,

otro aspecto determinante en la elección fue el hecho de que en la empresa, OpenSER era la

herramienta de la que se tenía conocimiento y básicamente de la que se interesaba tener el control.

Adicional al proceso de configuración del servidor Proxy, diseño y desarrollo de la aplicación

web, fue necesario realizar un par de manuales que contienen el proceso de configuración e

instalación de cada una de las herramientas requeridas durante el desarrollo del proyecto, así como

una explicación detallada del proceso de instalación y configuración de OpenSER. Este material

resultará fundamental para el momento en que se necesite hacer una reinstalación del Servidor Proxy

o bien realizar alguna modificación en la configuración del mismo.

Al ahondar un poco en el aspecto referente a la escalabilidad presentada por OpenSER se

decidió corroborar que efectivamente el mismo está en capacidad de manejar alrededor de 5000

llamadas por segundo. Para estas pruebas se empleó el programa SIPP con el fin de generar el tráfico

requerido. Se pudo comprobar que efectivamente OpenSER, trabajando bajo las características de

hardware del servidor utilizado, está en la capacidad de manejar alrededor de 6000 llamadas por

segundo.

87

En lo que respecta a la realización del proyecto, podemos señalar que los objetivos planteados

fueron satisfechos, pero además se fueron incorporando nuevas metas que enriquecieron la solución

final, logrando de esta manera aportar mayores conocimientos en lo que se refiere a OpenSER.

Entre los aspectos adicionales incluidos en la pasantía, se pueden mencionar: la configuración

de OpenSER no sólo como Proxy, sino también como Register, la realización de las pruebas de tráfico

mediante las cuales se pudo estimar para el servidor empleado la cantidad de llamadas concurrentes

que puede manejar OpenSER. Igualmente, se desarrolló la aplicación Web para la configuración de

OpenSER y la base de datos donde se encuentran los prefijos para el enrutamiento.

Referente a las recomendaciones y sugerencias que se presentaron a lo largo del desarrollo de

la pasantía, se recomienda no descargar la última versión de OpenSER del sitio oficial debido a que

actualmente la documentación solamente se encuentra disponible hasta la penúltima versión (1.0). Por

ello, las funciones incluidas en la nueva versión, así como los cambios de sintaxis para una

determinada función pueden no ser las mismas al igual que al instalar la última versión no se garantiza

estabilidad en la misma limitando así la ejecución de algún desarrollo.

También resulta fundamental contar con respaldos del archivo de configuración de OpenSER,

por ello se recomienda que cada vez que se hayan incorporado cambios importantes y funcionales, se

guarde dicho archivo de configuración en una carpeta destinada exclusivamente para ello. De esta

forma, en caso de corromper el archivo de configuración de OpenSER, esté podrá ser recuperado

rápidamente.

Con respecto a la Aplicación Web, se recomienda estudiar la factibilidad de incorporar una

funcionalidad que permita eliminar código del archivo de configuración de OpenSER via web, sin

necesidad de tener que hacerlo directamente en la consola.

88

REFERENCIAS

[1] H.323. Consultado en URL: http://es.wikipedia.org/wiki/H.323. 20 de Noviembre de 2006.

[2] Jitter. Consultado en URL:

http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci213534,00.html. 20 de Noviembre de

2006.

[3] Login Name. Consultado en URL:

http://www.learnthenet.com/Spanish/glossary/login.htm 21 de Noviembre de 2006.

[4] PBX. Consultado en URL: http://es.wikipedia.org/wiki/PBX. 21 de Noviembre de 2006.

[5] Reseña Histórica de CANTV. Consultado en URL:

http://www.cantv.com.ve/seccion.asp?pid=1&sid=1243. 8 de Noviembre de 2006.

[6] Trabajos presentados asignatura Redes de Ordenadores. Consultado en URL:

http://www.uv.es/~montanan/redes/trabajos. 8 de Noviembre de 2006.

[7] Superintendencia delegada para acueducto, alcantarillado y aseo. Algunas definiciones

importantes. Consultado en URL:

http://www.superservicios.gov.co/telecomunicaciones_definiciones.htm. 8 de Noviembre de 2006.

[8] Telefonía IP. Consultado en URL: http://www.monografias.com/trabajos16/telefonía-

señalización/telefonía-señalización.shtml. 9 de Noviembre de 2006.

[9] MARTIN, J. Telecommunications and the computer. Englewood Clifss, NJ Prentice Hall. 1990.

[10] VILLAVICENCIO, M. Red de Señalización por Canal Común Nº 7. Consultado en URL:

http://neutron.ing.ucv.ve/revista-e/No6/Villavicencio/trabSisT1.htm. 9 de Noviembre de 2006.

[11] GUEVARA, M. La Nueva Red Pública de Telecomunicaciones. Consultado en URL:

http://www.pe.ipv6tf.org/editorial/20051012. 10 de Noviembre de 2006.

[12] RTB/C (Red Telefónica Básica). Consultado en URL:

http://www.salazarweb.com/antbuspre.asp?Cod=648&nombre=648&orden=True. 10 de Noviembre de

2006.

[13] “Softswitch”. Consultado en URL: http://www.recursosvoip.com/colabora/”softswitch”1.php. 13 de

Noviembre de 2006.

[14] VAN DEER VEER, H. “The voice of the future: Next Generation Networks. Abril 2002”. White

Paper.

[15] SIERNA, L. Señalización en telefonía. Sistema de señalización Nº 7 (primera parte). Diciembre

2001. Consultado en URL: http://www.cinit.org.mx/articulo.php?idArticulo=7. 9 de Noviembre de

2006.

[16] FERNANDEZ, C. Diseño de una herramienta de monitoreo de señalización y control en la

plataforma VoIP de CANTV que permite mejorar los procesos de evaluación, monitoreo y soporte

técnicos de los servicios NGN. Diciembre 2006.

89

[17] Glosario Recursos VoIP M-R. Consultado en URL: http://www.recursosvoip.com/glosario/M-R.php.

13 de Noviembre de 2006.

[18] WAN. Consultado en URL: http://es.wikipedia.org/wiki/wan. 9 de Noviembre de 2006.

[19] Fundamentos de una red de área local. Consultado en URL:

http://www.geocities.com/siliconvalley/8195/redes.html. 9 de Noviembre de 2006.

[20] MOULTON, P. Telecommunications Survival Guide, The: Understanding and Applying

Telecommunications Technologies to Save Money and Develop New Business. Prentice Hall. 2001.

[21] SOTO, M. Protocolos TCP/IP. Consultado en URL: http://usuarios.lycos.es/janjo/janjo1.html.


[22] El Protocolo IP. Consultado en URL: http://neo.lcc.uma.es/evirtual/cdd/red/ip.html. 10 de

Noviembre de 2006].

[23] El Protocolo TCP. Consultado en URL:

http://neo.1cc.uma.es/evirtual/cdd/tutorial/transporte/tcp.html. 10 de Noviembre de 2006.

[24] User Datagram Protocol. Consultado en URL: http://es.wikipedia.org/wiki/udp 13 de Noviembre

de 2006.

[25] El protocolo UDP. Consultado en URL:

http://neo.lcc.uma.es/evirtual/cdd/tutorial/transporte/udp.html 13 de Noviembre de 2006.

[26] Router. Consultado en URL: http://www.webopedia.com/term/r/router.html 13 de Noviembre de

2006.

[27] Puerta de enlace. Consultado en URL: http://es.wikipedia.org/Puerta_de_Enlace. 15 de

Noviembre de 2006.

[28] Servidor. Consultado en URL: http://es.wikipedia.org/wiki/Servidor. 14 de Noviembre de 2006.

[29] How Virtual Private Network Work. Consultado en URL:

http://www.howstuffworks.com/vpn.htm. 14 de Noviembre de 2006.

[30] NADER, R. VPN Redes Virtuales Privadas. Consultado en URL:

http://www.monografías.com/trabajos11/repri/repri.shtml. 14 de Noviembre de 2006.

[31] Red Hat. Consultado en URL: http://fedora.redhat.com/docs/release_notes/fc4/errata/. 16 de

Noviembre de 2006.

[32] La voz sobre IP: hacia la convergencia. Consultado en URL:

http://www.fundacionauna.org/areas/25_publicaciones/09_VOIP%20.pdf 14 de Noviembre de 2006.

[33] SUN MYCROSYSTEMS NC. The “Softswitch” with Sun Microsystems. Mayo 2002.

[34] HANDLEY, M. et all. SIP Session Initiation Protocol (RFC 2543). Marzo 1999. Consultado en URL:

http://www.ietf.org/rfc/rfc2543.txt 7 de Noviembre de 2006.

[35] COLLINS, D. Carrier Grade Voice Over IP. McGraw-Hill. 2003.

[36] Iptel.org. Sip Network Elements. Consultado en URL: http://www.iptel.org/sip/intro/elements. 7

de Noviembre de 2006.

90

[37] Tema 2: Tráfico Telefónico. Consultado en URL:

http://www.terra.es/personal/ignaciorb/telefonia/conmutación/conmutación_2.htm. 04 de Diciembre

de 2006.

[38] FICHE, G. HÉBUTERNE, G. Communicating Systems & Networks: Traffic & Performance. Kogan

Page Science. London and Sterling, VA. 2004.

[39] PARK, K. QoS in Packet Networks. Springer. United States of America. 2005.

[40] OpenSER-GPL Sip Server. Consultado en URL:

http://www.openser.org/index?phpoption=com_frontpage&Itemid=1. 24 de Noviembre de 2006.

[41] XMPP. Consultado en URL: http://es.wikipedia.org/wiki/Xmpp. 24 de Noviembre de 2006.

[42] Telefonía IP Asterisk Open Source PBX. Consultado en URL: http://consultorianet.com/voip.htm.


[43] Asterisk. Consultado en URL: http://www.voip-info.org/wiki/view/Asterisk+introduction. 24 de

Noviembre de 2006.

[44] Asterisk. Consultado en URL: http://es.wikipedia.org/wiki/Asterisk. 24 de Noviembre de 2006.

[45] Sistema Operativo. Consultado en URL: http://es.wikipedia.org/wiki/Sistema_operativo. 17 de

Noviembre de 2006.

[46] Análisis de tráfico y calidad de servicio. Consultado en URL: http://eslared.org.ve/walc2004/apc-

aa/archivos-aa/1e60354f4717edb9fb793dbc5219499d/Practica_QoS.doc. 13 de Diciembre de 2006.

[47] Seguridad Informática y Software Libre. Consultado en URL: http://es.tldp.org/Informes/informe-

seguridad-SL/informe-seguridad-SL.pdf. 27 de Noviembre de 2006.

[48] Flex, versión 2.5. Consultado en URL: http://ditec.um.es/~aflores/dile/flex/flex-es.html#SEC1. 21

de Noviembre de 2006.

[49] NGREP – Network NGREP. Consultado en URL:

http://ngrep.sourceforge.net/download.html. 22 de Noviembre de 2006.

- 91 -

ANEXO 1: Manual de OpenSER

1. Información básica de SIP

1.1. Arquitectura SIP SIP es un protocolo de señalización que maneja el inicio, la modificación y la finalización de

sesiones multimedia. En combinación con otros protocolos, es usado para describir las características

de sesión de los potenciales participantes de la misma. Estrictamente hablando, SIP está escrito de

forma tal que los medios que se utilizarán en una sesión dada pueden usar cualquier protocolo de

transporte, usando comúnmente el protocolo RTP.

La señalización SIP puede ser considerada por separado de los medios. Ésto es importante ya

que esta señalización puede ser pasada por uno o más proxies o servidores de redireccionamiento

mientras que el flujo de datos de media toma un camino más directo.

1.2. Historia de SER SER (“SIP Express Router”) fue creado por un grupo de desarrolladores, empleados por

Fraunhofer Fokus, un grupo de investigación alemán. El proyecto de iptel.org era construir un sitio

Web que tuviese información de VoIP y ofrecer servicios gratis del mismo. SER fue desarrollado como

parte del esfuerzo de Jiri Kuthan. Es un proyecto de código abierto, siendo iptel.org el punto de

entrada de información referente a SER, así como también de tutoriales sobre SIP.

Fraunhofer Fokus hizo girar iptel.org como una empresa para el desarrollo de SER (para

propósitos tanto comerciales como de código abierto) y para ofrecer servicios y paquetes de software

basados en los proyectos desarrollados por dicha empresa. Iptel.org tiene principalmente el control y

responsabilidad en el desarrollo de SER, el servidor SIP de código abierto.

2. OpenSER

2.1. Historia En el año 2005, Voice System anunció la creación de OpenSER. La razón de dicha creación, se

debió a la falta de progreso y contribución al proyecto SER por parte de los miembros su comunidad.

Los desarrolladores de Voice System de SER, sentían que iptel.org fue quién tomó las decisiones

finales en el lanzamiento de los códigos, además de que no había podido agregar nuevas

contribuciones y había sido demasiado lento en lanzar las nuevas versiones de SER.

La sensación general era que las nuevas características ofrecidas eran buenas, pero la mayoría

de la gente percibía que sería más sencillo para la comunidad si tanto la estabilidad y garantía de

calidad encontrada en SER se podría combinar en el mismo proyecto con las metas de OpenSER.

- 92 -

2.2. Descripción OpenSER es un servidor SIP, tiene una arquitectura flexible y presenta una amplia colección de

extensiones. El servidor implementa un Proxy, herramientas para el registro, la redirección y

localización de servicios SIP/VoIP.

Un servidor SIP es un elemento primordial en la constitución de una red VoIP basada en el

estándar SIP, un elemento de control de sesión entre usuarios y servicios. Por el Proxy SIP pasan

todas las peticiones de un usuario, le permite acceder a la red, localizar a otros usuarios y establecer la

comunicación VoIP SIP.

3. Ubicación de OpenSER en el servidor

3.1. Originales y Documentación Los archivos originales del OpenSER junto con los manuales, las librerías, los archivos

ejecutables de los módulos, información referente al OpenSER, ejemplos se encuentran en la carpeta:

/home/openser/openser-1.0.1-tls en el servidor con IP:161.196.58.48.

3.2. Backups En la carpeta /etc/openser/backup se encuentra un archivo openser.cfg de respaldo y uno

original (tal cual como cuando se instaló el servicio), para que cuando ocurra algún error y no se

pueda solventar, se pueda sustituir el archivo y seguir con la programación actual sin problema

alguno.

Además se recomienda ir guardando los archivos con nuevas modificaciones en la misma

carpeta para tener respaldo de los avances y, al momento de tener que deshacer modificaciones, sea

más fácil el cambio.

- 93 -

3.3. Archivo openser.cfg El archivo openser.cfg es el núcleo de OpenSER, por lo tanto éste es el que se debe modificar

si se desea agregar una nueva funcionalidad a OpenSER.

Este archivo se encuentra ubicado en: /etc/openser

4. Archivo de configuración

4.1. Descripción Este archivo contiene todos los parámetros de configuración del OpenSER como tal, es el

núcleo del servicio.

4.2. Estructura Este archivo presenta siete secciones lógicas principales:

4.2.1. Sección de definiciones globales: esta porción de openser.cfg usualmente

contiene la dirección IP, el puerto que está siendo escuchado, el nivel de detalles en los

mensajes de detección de errores. Los cambios en esta sección afectan al demonio de

OpenSER en si mismo.

4.2.2. Sección de módulos: contiene una lista de librerías externas que son necesarias

para exponer la funcionalidad no proporcionada por el núcleo. Estos módulos son

Carpeta donde está el archivo

Archivo de configuración

- 94 -

archivos compartidos (presentan extensión .so) y son cargados con el comando

loadmodule.

4.2.3. Sección de configuración de los módulos: la mayoría de las librerías externas

especificadas en la sección de los módulos son necesarias para habilitar los parámetros

del mismo, para que éste funcione correctamente. Estos parámetros del módulo se fijan

por medio del comando modparam, el cual toma la forma: modparam (“nombre del

módulo”, “parámetro del módulo”, valor del parámetro).

- 95 -

4.2.4. Bloque de ruta principal (enrutamiento): es análogo a la función principal de los

programas escritos en lenguaje C. Este es el punto de acceso para controlar mensajes

SIP y controlar cómo cada mensaje recibido será manejado.

4.2.5. Bloque de ruta secundaria (rutas): adicionalmente al bloque de ruta principal,

openser.cfg puede contener bloques de rutas adicionales que pueden ser llamadas por

el bloque de ruta principal ó, por otros bloques de rutas secundarios. Un bloque de ruta

secundario es análogo a una subrutina.

- 96 -

4.2.6. Bloque de ruta de respuesta: de forma opcional, los bloques de rutina de

respuesta pueden ser utilizados para manejar respuestas a mensajes SIP. La mayoría de

estos mensajes de respuesta son OK.

4.2.7. Bloque de ruta de falla: opcionalmente pueden agregarse bloques de rutas de

fallas que pueden ser usados cuando se necesitan procesos especiales para manejar

condiciones de falla, como fin de tiempo de espera, o congestión, entre otras.

4.3. Insertar o modificar código Si se desea editar el archivo, esto debe hacerse directo desde consola, pero para insertar algo

nuevo dentro del mismo se tienen dos opciones, modificar directamente en la consola el archivo de

configuración “openser.cfg” o modificar el archivo de configuración vía Web (solo podrá agregar código

al archivo de configuración, en caso de que se necesite eliminar código o realizar alguna modificación

en el mismo, esto deberá de hacerse directamente desde consola).

Ruta de falla

- 97 -

Al acceder a la página Web (después de registrarte como administrador), se observará por

pantalla lo siguiente:

Se elige en la lista desplegable la opción deseada, y en el cuadro de texto se escribe el código,

luego se pulsa el botón enviar. En este momento, los cambios se habrán realizado en su archivo de

configuración.

Para modificar el archivo desde consola, debe ubicarse en la carpeta donde se encuentra el

mismo y ejecutar el comando: vi openser.cfg para luego acceder al modo “insert” (presionando la tecla

I) y luego se procede a editarlo.

- 98 -

Advertencia: siempre que se realicen modificaciones en el archivo de configuración, OpenSER

debe detenerse e iniciarse ya que ésta es la única manera de que los cambios efectuados sean

tomados en cuenta.

Para reiniciar openser, debe ejecutar desde la consola el siguiente comando:

service ./openser restart

De esta forma, los cambios realizados en el archivo de configuración de OpenSER serán

tomados en cuenta.

4.4. Guardar o no los cambios del archivo openser.cfg Para guardar las modificaciones hechas en el archivo de configuración de OpenSER desde la

consola, se presiona la tecla “Esc” para salir del modo “insert” y se escribe:

“:q!” si no se quieren guardar los cambios hechos y se desea salir del editor.

“:wq” si se quieren guardar los cambios y salir del editor.

“:w” si solo se quieren guardar los cambios sin salir del editor.

“:q” si se quiere salir del editor sin haber hecho ningún cambio.

Nota: las comillas no deben colocarse.

4.5. Ejecutar o no un trozo de código Para hacer esto existen dos opciones, si se desea que una línea no se ejecute, es decir, tenerla

comentada (para pruebas u otra acción) se debe colocar un signo de numeral “#” al inicio de la línea

y automáticamente ésta no será ejecutada al reiniciar el servicio. Si por otro lado, lo que se quiere es

que no se ejecute un trozo de código, se debe colocar al inicio del bloque un slash con un asterisco

“/*” y al final del bloque se invierte y se coloca primero el asterisco y luego es slash “*/” para cerrar el

comentario y así no permitir la ejecución de ese trozo o bloque de código al reiniciar el servicio.

De igual forma si se quiere comentar línea por línea en un trozo o bloque de código puede

hacerse, así se puede comentar o no cualquier línea por separado de las otras.

Trozo de código que no se ejecuta

Línea que no se ejecuta

- 99 -

5. Uso del archivo openser.cfg

5.1. Módulos OpenSER está formado por un conjunto de módulos, cada uno de ellos contiene parámetros y

funciones exportadas. Para poder hacer uso de las mismas, los módulos deben cargarse previamente

de la forma: loadmodule “nombre_del_módulo”

Estos pueden listarse, según la versión del OpenSER instalado (en este caso v.1.0), en la

página: http://www.openser.org/docs/modules/1.0.x/.

Es importante saber que hay módulos que presentan dependencia de otros, por lo tanto antes

de cargar un módulo es necesario chequear si presenta dependencia con alguno, y en caso de ser así,

éste debe cargarse primero.

Módulos cargados

- 100 -

5.1.1. Ubicación Los módulos vienen ya incluidos en los archivos de instalación del OpenSER. Cuando se instala

OpenSER, automáticamente los archivos de configuración de cada módulo son instalados, mas no

cargados (sólo se cargan aquellos que se encuentren especificados en el archivo de configuración,

openser.cfg).

Además, cada versión de OpenSER viene con sus módulos adaptados para la misma, por ende

no se pueden agregar módulos de versiones distintas a la del OpenSER instalado.

5.1.2. Dependencia de los módulos: A continuación se listan los módulos de OpenSER con sus respectivas dependencias.

• Acc: Tm, Rr

• Alias_Db: MySQL, Dbtext

• Auth: Sl

• Auth_Db: Auth, Db

• Auth_Diameter: Sl

• Auth_Radius: Auth

• Avpops: Db

• Cpl-C: Tm, Sl, Usrloc.

• Dbtext: ninguna dependencia

• Msilo: Tm y Db

• Mysql: ninguna dependencia

• Nathelper: Usrloc

• Options: Sl

• Pa: ninguna dependencia

• Pdt: Db

• Permissions: ninguna dependencia

• Pike: ninguna dependencia

• Registrar: Usrloc, Sl

El módulo uac presenta dependencia

de tm y rr

Los módulos tm y rr deben cargarse en líneas anteriores

- 101 -

• Dispatcher: ninguna dependencia

• Diversion: ninguna dependencia

• Domain: Db

• Enum: ninguna dependencia

• Exec: ninguna dependencia

• Flatstore: ninguna dependencia

• Gflags: ninguna dependencia

• Group: Db

• Group_Radius: ninguna dependencia

• Jabber: Db, Pa

• Lcr: Tm, Db

• Maxfwd: ninguna dependencia

• Mediaproxy: ninguna dependencia

• Rr: ninguna dependencia

• Sl: ninguna dependencia

• Sms: Tm

• Speeddial: Db, Sl

• Textops: ninguna dependencia

• Tm: ninguna dependencia

• Uac: Tm, Rr

• Uac_Redirect: Tm, Acc

• Uri: ninguna dependencia

• Uri_db: Db

• Uri_radius: ninguna dependencia

• Usrloc: ninguna dependencia

• Xlog: ninguna dependencia

5.1.3. Cargar los módulos En el archivo de configuración de OpenSER, openser.cfg, existe un trozo de código destinado

para cargar los módulos deseados, para ello se escribe loadmodule “modulo.so”. Se debe tomar en

cuenta el orden en que se cargan los mismos para que no ocurran errores de dependencias.

5.2. Parámetros

5.2.1. Existentes Cada módulo tiene un conjunto de parámetros únicos, éstos se encuentran explicados dentro

de la descripción de cada uno en http://www.openser.org/docs/modules/1.0.x/. Además se puede

obtener una lista completa de todos los parámetros de cada módulo en

http://www.openser.org/dokuwiki/doku.php/modules:1.0.x:index-parameters, donde hace una

redirección al lugar especifico dentro de la descripción del módulo donde se encuentra todo lo

referente al parámetro.

- 102 -

5.2.2. Configuración Cada uno de los módulos, que forman parte de OpenSER, están constituidos por un conjunto

de parámetros. Al cargar un módulo en el archivo de configuración, los parámetros del mismo ya se

encontrarán disponibles y traen un valor por defecto.

Para ver los parámetros de cada módulo y los valores que pueden tomar, dirigirse al link

indicado en la sección anterior.

Para configurar un parámetro (cambiar el valor que trae por defecto) se escribe dentro del

archivo de configuración de openser la siguiente línea de código:

“modparam (“modulo”, “parámetro”, “modo”)”, donde:

• “módulo”: nombre del módulo al cual pertenece el parámetro.

• “parámetro”: nombre del parámetro a modificar.

• “modo”: valor que tomará el parámetro en sí.

De forma equivalente, se puede agregar un parámetro mediante la página de configuración vía

Web. Al acceder a la página Web, se observará por pantalla lo siguiente:

- 103 -

Se elige en la lista desplegable la opción “Insertar parámetro” y en el cuadro de texto se

escribe el siguiente código:

modparam (“modulo”, “parámetro”, “modo”),

luego se pulsa el botón enviar y con eso los cambios se realizarán en el archivo de configuración.

Para modificar el archivo desde la consola, debe ubicarse en la carpeta donde se encuentra el

mismo: (/etc/openser), posteriormente se ejecuta el comando: “vi openser.cfg” para luego acceder al

modo “insert” (presionando cualquier tecla “I”) y editar el archivo.

Advertencia: siempre que se realicen modificaciones en el archivo de configuración, debe

detenerse e iniciarse el servicio openser ya que ésta es la única manera de que los cambios

efectuados sean tomados en cuenta.

5.3. Enrutamiento

5.3.1. Partes Dentro de esta sección se encuentra como tal el manejo de las llamadas, donde se puede

diferenciar qué hace el script cada vez que se encuentra con un mensaje SIP proveniente de algún

teléfono IP o de alguna llamada pasando a través del servicio.

5.3.2. Enrutamiento por URI

5.3.2.1. Descripción Este enrutamiento consiste en cambiar la ruta o dominio destino de una llamada según reglas

preestablecidas donde se revisa el número SIP del URI de la llamada. Para ello, cuando llega el INVITE

se chequea el numero SIP al cual va dirigida la llamada y según el número que sea se cambia el

dominio al cual va dirigido.

5.3.2.2. Insertar o modificar Para modificar una regla de enrutamiento, es necesario hacerlo directamente en el archivo de

configuración de OpenSER. Por otro lado, para agregar una regla se tienen dos opciones: agregar la

regla directamente en el archivo de configuración de openser: openser.cfg ó agregar, solamente, una

regla mediante la página de configuración vía Web.

Al acceder a la página Web, se observará por pantalla lo siguiente:

- 104 -

Se elige en la lista desplegable la opción “Insertar regla de enrutamiento (URI)” y en el cuadro

de texto se escribe el siguiente código:

if(uri=~"^sip:númeroSIP") { prefix("XX");

prefix2domain("X");

};

donde “númeroSIP” es el número que se quiere buscar (por ejemplo, si se coloca 2, todos los números

de teléfono que comienzan por 2 serán redireccionados al dominio especificado al igual que si se

coloca el número 0416 o cualquier otro número), la función prefix(prefijo) le agrega un prefijo al

número para poder ubicarlo en la tabla de prefix_domain y poder hacer la búsqueda del dominio

referente a ese prefijo, por último la función prefix2domain(mode), dependiendo del modo que se elija

reenvía el INVITE con o sin el prefijo agregado.

Luego se pulsa el botón enviar y con eso los cambios se realizarán en el archivo de

configuración.

- 105 -

Para modificar el archivo desde la consola, nos ubicamos en la carpeta donde se encuentra el

mismo y hacemos “vi openser.cfg” para luego acceder al modo “insert” (presionando la tecla “I”) y

proceder a editarlo.

Nota: siempre que se realicen modificaciones en el archivo de configuración, debe detenerse e

iniciarse el servicio OpenSER ya que ésta es la única manera de que los cambios efectuados

sean tomados en cuenta.

5.3.3. Enrutamiento por FROM


preestablecidas donde se revisa una coincidencia con el campo FROM del mensaje INVITE. Para ello,

cuando llega el INVITE se chequea el campo FROM de donde proviene la llamada y según sea su

coincidencia se cambia el dominio al cual va dirigido.

5.3.3.2. Función “search()” La función search (re) sirve para revisar o buscar, como su nombre lo indica, dentro de un

mensaje SIP, la coincidencia de alguna expresión regular dentro del mismo mensaje.

5.3.3.3. ¿Cómo se modifica o agrega otra regla? Para editar o eliminar una regla de enrutamiento, debe modificarse directamente el archivo de

configuración de OpenSER directamente desde la consola usando para ello un editor, sin embargo,

para agregar una regla se puede trabajar directamente en el archivo de configuración y escribir el

código correspondiente en la sección: Enrutamiento por campo: “from”.

Ó agregar la regla mediante la página de configuración vía Web.

- 106 -

Nota: al agregar una nueva regla de enrutamiento FROM, debe asegurarse de no modificar el

comentario: #INSERTE REGLA DE ENRUTAMIENTO POR FROM AQUÍ, debido a que el mismo además

de ser un comentario para facilitarle al administrador la codificación directamente en el archivo de

configuración, es un punto de inserción del servidor web, si el mismo se modifica, o se elimina, el

servidor web fallará.

Si se desea agregar una regla de enrutamiento usando el servidor web, se observará por

pantalla:

Se elige en la lista desplegable la opción “Insertar regla de enrutamiento (FROM) y en el

cuadro de texto se escribe el siguiente código:

If (search(“[Ff][Rr][Oo][Mm]: númeroSIP”)) { prefix("XX");

prefix2domain("X");

};

donde el “númeroSIP” es el número que se quiere buscar (por ejemplo, si se coloca 2, todos los

números de teléfono que en su campo FROM comienzan por 2 serán redireccionados al dominio

- 107 -

especificado, al igual que si se coloca el número 0416 o cualquier otro número), la función

prefix(prefijo) le agrega un prefijo al numero para poder ubicarlo en la tabla de prefix_domain y poder

hacer la búsqueda del dominio referente a ese prefijo, por último la función prefix2domain(mode),

dependiendo del modo que se elija reenvía el INVITE con o sin el prefijo agregado.


configuración.


mismo y escribimos el comando “vi openser.cfg” (sin comillas) para luego acceder al modo “insert”

(presionando la tecla “I”) y después editarlo.

Nota: siempre que se realicen modificaciones en el archivo de configuración, debe detenerse

e iniciarse el servicio openser ya que ésta es la única manera de que los cambios efectuados

sean tomados en cuenta.

5.3.4. Enrutamiento por TO


preestablecidas donde se revisa una coincidencia con el campo “TO” del mensaje INVITE. Para ello,

cuando llega el INVITE se chequea el campo “TO” a dónde va la llamada y según sea su coincidencia

se cambia el dominio al cual va dirigido.

5.3.4.2. Función “search()” La función search (re) sirve para revisar o buscar, como su nombre lo indica, dentro de un

mensaje SIP, la coincidencia de alguna expresión regular dentro del mismo mensaje.

5.3.4.3. Insertar o modificar una regla? Para editar o eliminar una regla de enrutamiento, debe modificarse directamente el archivo de

configuración desde la consola, sin embargo para agregar una regla se tienen dos opciones: modificar

directamente en la consola el archivo de configuración de openser: openser.cfg ó agregar, la regla

mediante la pagina de configuración vía Web.

- 108 -


Se elige en la lista desplegable la opción “Insertar regla de enrutamiento (TO) y en el cuadro

de texto se escribe el siguiente código:

If (search(“[Tt][Oo]: númeroSIP”)) { prefix("XX");

prefix2domain("X");

};

- 109 -

donde el “númeroSIP” es el número que se busca (por ejemplo, si se coloca 2, todos los números de

teléfono que en su campo TO comienzan por 2 serán redireccionados al dominio especificado, al igual

que si se coloca el número 0416 o cualquier otro número), la función prefix(prefijo) le agrega un

prefijo al numero para poder ubicarlo en la tabla de prefix_domain y poder hacer la búsqueda del

dominio referente a ese prefijo, por último la función prefix2domain(mode), dependiendo del modo

que se elija, se encargará de reenviar el INVITE con o sin el prefijo agregado.


configuración.

Para modificar el archivo desde la consola, debe ubicarse en la carpeta donde se encuentra el

mismo y ejecutar el comando: vi openser.cfg para luego acceder al modo “insert” (presionando la

tecla I) y poder editarlo.

Nota: siempre que se realicen modificaciones en el archivo de configuración, es necesario

detener e iniciar el servicio openser ya que ésta es la única manera de que los cambios


Además, al agregar una nueva regla de enrutamiento TO, debe asegurarse de no modificar el

comentario: #INSERTE REGLA DE ENRUTAMIENTO POR TO AQUÍ, debido a que el mismo además de

ser un comentario para facilitarle al administrador la codificación directamente en el archivo de

configuración, es un punto de inserción del servidor Web, si el mismo se modifica, o se elimina, el

servidor Web fallará.

5.3.5. Enrutamiento por HORA

5.3.5.1. Descripción Este enrutamiento consiste en cambiar la ruta o dominio destino de una llamada según las

reglas y el rango de horas preestablecidas desde la página Web. Según el rango de horas establecido

se chequea en la base de datos el dominio asignado y se reenvía la llamada al dominio

correspondiente.

5.3.5.2. Insertar o modificar una regla Para agregar una regla se tienen dos opciones: agregar la regla directamente en el archivo de

configuración de OpenSER: openser.cfg (accediendo desde la consola) ó agregar la regla usando la

página de configuración vía Web. Si se desea editar o eliminar alguna regla de enrutamiento, esto se

deberá hacer directamente en el archivo de configuración de OpenSER, accediendo al mismo desde la

consola.

- 110 -


Se elige en la lista desplegable la opción “Insertar regla de enrutamiento (HORA) y en el

cuadro de texto se escribe el siguiente código:

if(uri=~"^sip:númeroSIP") { prefix("XX");

prefix2domain("X");

};

donde el “númeroSIP” es el número que se quiere buscar (por ejemplo, si se coloca 2, todos los

números de teléfono que comienzan por 2 serán redireccionados al dominio especificado, al igual que

si se coloca el número 0412 o cualquier otro número), la función prefix(prefijo) le agrega un prefijo al

número para poder ubicarlo en la tabla de prefix_domain y poder hacer la búsqueda del dominio

referente a ese prefijo, por último la función prefix2domain(mode), dependiendo del modo que se elija

reenvía el INVITE con o sin el prefijo agregado.

Luego se pulsa el botón enviar y con ello los cambios se realizarán en el archivo de

configuración.

- 111 -


mismo (/etc/openser) y se ejecuta el comando “vi openser.cfg” para luego acceder al modo “insert”

(presionando la tecla “I”) y después editarlo.

Nota: siempre que se realicen modificaciones en el archivo de configuración, el servicio

openser debe detenerse e iniciarse ya que ésta es la única manera de que los cambios


Así como se ha explicado en los otros tipos de enrutamiento, al agregar una nueva regla de

enrutamiento por hora, debe asegurarse de no modificar el comentario: #INSERTE REGLA DE

ENRUTAMIENTO POR HORA AQUÍ, debido a que el mismo además de ser un comentario para

facilitarle al administrador la codificación directamente en el archivo de configuración, es un punto de

inserción del servidor web, si el mismo se modifica, o se elimina, el servidor web fallará.

5.4. Rutas

5.4.1. Descripción Son bloques de rutas adicionales que pueden ser llamadas por el bloque de ruta principal

(enrutamiento) ó, por otros bloques de rutas secundarios. Un bloque de ruta secundario es análogo a

una subrutina.

5.4.2. Función Sirven para cambiar el destino final de la llamada o simplemente para notificar sobre algún

evento ocurrido.

5.4.3. Uso Para crear una ruta sólo basta con escribir al final de la parte de enrutamiento el siguiente

código:

route[X] {

………………………… };

donde “X” indica el número de ruta y los puntos suspensivos indican el código para enrutamiento o

envío de algún mensaje SIP en respuesta a algún evento que suceda.

Para llamar la subrutina desde cualquier parte del código basta se escribe “route(X);” para así

poder ejecutar la ruta luego del salto.

5.5. Funciones Usadas

5.5.1. Función "acc_db_request(comment, table)" "acc_diam_request(comment)"

- 112 -

"acc_log_request(comment)" "acc_rad_request(comment)" "add_diversion(reason)" "add_rcv_param()" "add_rr_param(param)" "add_sock_hdr(hdr_name)" "add_uri_param(param)" "alias_db_lookup(table_name)" "allow_refer_to(allow_file, deny_file)" "allow_refer_to(basename)" "allow_register(allow_file, deny_file)" "allow_register(basename)" "allow_routing()" "allow_routing(allow_file,deny_file)" "allow_routing(basename)" "allow_trusted()" "append_hf(hf)" "append_rpid_hf()" "append_rpid_hf(prefix, suffix)" "append_time()" "append_to_reply(txt)" "append_urihf(prefix, suffix)" "avp_check(name,op_value) " "avp_copy(old_name,new_name) " "avp_db_delete(source,name)" "avp_db_load(source,name) " "avp_db_store(source,name)" "avp_delete(name) " "avp_load_radius(user)" "avp_op(name,op_value) " "avp_print()" "avp_printf(dest, format) " "avp_pushto(destination,name) " "avp_subst(avps, subst)" "avp_write(value,name)" "check_from()" "check_route_param(re)" "check_to()" "client_nat_test("type) "consume_credentials()" "cpl_process_register()" "cpl_process_register_norpl()" "cpl_run_script(type,mode)" "decode_contact()" "decode_contact_header()" "diameter_is_user_in(who, group)" "diameter_proxy_authorize(realm)" "diameter_www_authorize(realm)" "does_uri_exist()" "ds_select_domain(set, alg)" "ds_select_dst(set, alg)" "encode_contact(encoding_prefix)" "end_media_session(")

"enum_query(),enum_query("suffix"), enum_query("suffix", "service")" "exec_dset(command)" "exec_msg(command)" "fix_contact(") "fix_nated_contact()" "fix_nated_register()" "fix_nated_sdp(mode)" "flush" (integer) "force_rtp_proxy()" "force_rtp_proxy(flags)" "force_rtp_proxy(flags, ip_address)" "from_gw()" "get_redirects(max)" "get_redirects(max,reason)" "handle_subscription(domain)" "has_totag()" "is_avp_set(name) " "is_direction(dir)" "is_from_local()" "is_from_user_e164()" "is_gflag(flag)" "is_method(name)" "is_present_hf(hf_name)" "is_rpid_user_e164()" "is_uri_host_local()" "is_user(username)" "is_user_in(URI, group)" "jab_exit_jconf()" "jab_go_offline()" "jab_go_online()" "jab_join_jconf()" "jab_send_message()" "load_contacts()" "load_gws()" "lookup("domain)" "loose_route()" "m_dump()" "m_store(mode)" "mf_process_maxfwd_header(max_value)" "nat_uac_test(flags)" "next_contacts()" "next_gw()" "options_reply()" "pike_check_req()" "prefix2domain("mode)" "proxy_authorize(realm, table)" "proxy_challenge(realm, qop)" "radius_is_user_in(URI, group)" "radius_proxy_authorize(realm)" "radius_www_authorize(realm)" "record_route()" "record_route_preset(string)"

- 113 -

"registered("domain)" "remove_hf(hname)" "replace("re, txt)" "replace_all(re, txt)" "reset_gflag(flag)" "save("domain)" "save_memory(domain)" "save_noreply(domain)" "sd_lookup(table)" "sdp_mangle_ip(pattern, newip)" "sdp_mangle_port(offset)" "search("re)" "search_append(re, txt)" "set_accept_filter(filter,flags) " "set_deny_filter(filter,flags) " "set_gflag(flag)" "sl_reply_error()" "sl_send_reply(code, reason)" "sms_send_msg()" "sms_send_msg_to_net(network_name)" "strict_route()" -- deprecated "subst("'/re/repl/flags')" "subst_uri('/re/repl/flags')" "subst_user('/re/repl/flags')" "t_check_status(re)" "t_check_trans()" "t_flush_flags()" "t_forward_nonack(ip, port)" "t_forward_nonack_udp(ip, port)" "t_forward_nonack_tcp(ip, port)" "t_forward_nonack_tls(ip, port)" "t_forward_nonack_uri()" "t_local_replied(reply)" "t_lookup_request()" "t_newtran()" "t_on_branch(branch_route)" "t_on_failure(failure_route)" "t_on_reply(reply_route) " "t_relay()" "t_relay_to_udp(ip, port), t_relay_to_tcp(ip, port), t_relay_to_tls(ip, port)" "t_release()" "t_replicate(ip, port) t_replicate_udp(ip, port) t_replicate_tcp(ip, port)" "t_reply(code, reason_phrase)" "t_retransmit_reply()" "t_was_cancelled()" "t_write_fifo(info,fifo) t_write_unix(info,sock)" "tel2sip(")" "to_gw()" "uac_auth()" "uac_replace_from(display,uri)"

"uac_replace_from(uri)" "uac_restore_from()" "unforce_rtp_proxy()" "uri_param(param)" "uri_param(param,value)" "use_media_proxy"() "www_authorize(realm, table)" "www_challenge(realm, qop)" "xdbg(format)" "xlog( [level,] format)" Parámetros de openSER: "acc_db_table" (string) "acc_domain_column" (string) "acc_dst_leg_column" (string) "acc_from_uri_column" (string) "acc_fromtag_column" (string) "acc_function" (string) "acc_i_uri_column" (string) "acc_o_uri_column" (string) "acc_sip_callid_column" (string) "acc_sip_from_column" (string) "acc_sip_method_column" (string) "acc_sip_status_column" (string) "acc_sip_to_column" (string) "acc_src_leg_column" (string) "acc_time_column" (string) "acc_to_uri_column" (string) "acc_totag_column" (string) "acc_user_column" (string) "accept" (string) "accept_encoding" (string) "accept_filter" (string) "accept_language" (string) "add_username" (integer) "alias_domain_column" (str) "alias_user_column" (str) "aliases" (string) "allow_suffix" (string) "append_branches" (integer) "append_fromtag" (integer) "append_hf(hf)" append_hf(hf)" "append_time()" append_time()" "append_to_reply(txt)" append_to_reply(txt)" "append_urihf(prefix, suffix)" "attribute_column" (string) "avp_aliases" (string) "avp_table" (string) "avp_url" (string) "branch_flag_mask" (string) "buf_size" (integer) "cache_time" (integer) "calculate_ha1" (integer)

- 114 -

"callee_service_type" (integer) "caller_service_type" (integer) "callid_column" (string) "case_sensitive" (int) "case_sensitive" (integer) "check_all_branches" (integer) "check_time" (int) "check_time" (integer) "clean_period" (int) "clean_time" (integer) "contact_avp" (string) "contact_column" (string) "contact_flds_separator" (string) "cpl_db" (string) "cpl_dtd_file" (string) "cpl_table" (string) "credential" (string) "cseq_column" (string) "db_extra" (string) "db_flag" (integer) "db_localtime" (int) "db_missed_flag" (integer) "db_mode" (integer) "db_mode" (integer) "db_mode" (integer) "db_scheme" (string) "db_table" (string) "db_table" (string) "db_table_acc" (string) "db_table_missed_calls" (string) "db_url" (str) "db_url" (string) "default_allow_file" (string) "default_deny_file" (string) "default_expires" (integer) "default_expires" (integer) "default_filter" (string) "default_net" (string) "default_q" (integer) "delay_time" (integer) "delete_timer" (integer) "deny_filter" (string) "deny_suffix" (string) "desc_time_order" (integer) "desc_time_order" (integer) "diameter_client_host" (string) "diameter_client_host" (string) "diameter_client_port" (int) "diameter_client_port" (int) "diameter_flag" (integer) "diameter_missed_flag" (integer) "diamter_extra" (string) "domain_col" (string)

"domain_column" (str) "domain_column" (string) "domain_column" (string) "domain_column" (string) "domain_column" (string) "domain_column" (string) "domain_column" (string) "domain_prefix" (str) "domain_prefix" (string) "domain_str" (string) "domain_suffix" (string) "domain_table" (string) "dst_leg_avp_id" (integer) "early_media" (integer) "enable_double_rr" (integer) "enable_full_lr" (integer) "exec_timer" (UNUSED, placeholder only) (integer) "expire_time" (int) "expires_column" (string) "failed_transaction_flag" (integer) "flags" (int) ts "flags_column" (string) "flush" (integer) "force_color" (integer) "force_dst" (int) "force_socket" (string) "fr_inv_timer" (integer) "fr_inv_timer" (integer) "fr_inv_timer_avp" (string) "fr_inv_timer_avp" (string) "fr_inv_timer_next" (integer) "fr_timer" (integer) "fr_timer_avp" (string) "from_col" (string) "from_restore_mode" (string) "from_uri_column" (string) "group_column" (string) "grp_id_column" (string) "gw_name_column" (string) "gw_table" (string) "gw_uri_avp" (string) "hsize_2pow" (integer) "initial" (string) "ip_addr_column" (string) "is_method(name)" is_method(name)" "is_present_hf(hf_name)" "jaddress" (string) "jdomain" (string) "jport" (integer) "lcr_table" (string) "links" (string) "list_file" (string)

- 115 -

"load_credentials" (string) "log_dir" (string) "log_extra" (string) "log_flag" (integer) "log_fmt" (string) "log_level" (integer) "log_missed_flag" (integer) "lookup_append_branches" (int) "lookup_domain" (string) "max_contacts" (integer) "max_expires" (integer) "max_jobs" (integer) "max_limit" (integer) "max_sms_parts" (integer) "mediaproxy_socket" (string) "method_column" (string) "min_expires" (integer) "modems" (string) "multi_leg_enabled" (integer) "nat_flag" (int) "nat_flag" (integer) "natping_interval" (integer) "natping_interval" (integer) "networks" (string) "new_uri_column" (string) "noisy_ctimer" (integer) "nonce_expire" (integer) "password_column" (string) "password_column_2" (string) "ping_nated_only" (integer) "port_column" (string) "prefix" (string) "prefix_column" (string) "prefix_column" (string) "priority_column" (string) "proto_col" (string) "proxy" (string) "proxy_recurse" (int) "proxy_route" (int) "q_column" (string) "radius_config" (string) "radius_config" (string) "radius_config" (string) "radius_extra" (string) "radius_flag" (integer) "radius_missed_flag" (integer) "realm_prefix" (string) "realm_prefix" (string) "realm_prefix" (string) "received_avp" (integer) "received_avp" (integer) "received_column" (string) "received_param" (integer)

"registrar" (string) "registrar" (string) "remove_hf(hname)" remove_hf(hname)" "remove_latency" (integer) "replace(""re, txt)" "replace_all(re, txt)" "report_ack" (integer) "report_cancels" (integer) "reqs_density_per_unit" (integer) "restart_fr_on_each_reply" (integer) "retr_timer1p1" (integer) "retr_timer1p2" (integer) "retr_timer1p3" (integer) "retr_timer2" (integer) "retry_after" (integer) "rpid_avp" (string) "rpid_avp" (string) "rpid_prefix" (string) "rpid_suffix" (string) "rr_store_param" (string) "rtp_asymmetrics" (string) "rtpproxy_disable" (integer) "rtpproxy_disable_tout" (integer) "rtpproxy_retr" (integer) "rtpproxy_sock" (string) "rtpproxy_tout" (integer) "ruri_matching" (integer) "ruri_user_avp" (string) "sampling_time_unit" (integer) "sd_domain_column" (string) "sd_user_column" (string) "search(""re)" search(""re)" "search_append(re, txt)" "secret" (string) "service_type" (integer) "service_type" (integer) "setvars" (integer) "sip_asymmetrics" (string) "sip_natping_flag" (integer) "sipping_from" (string) "sipping_method" (string) "sleep_time" (integer) "sms_report_type" (integer) "sock_flag" (integer) "sock_hdr_name" (string) "socket_column" (string) "source_col" (string) "src_leg_avp_id" (integer) "subscriber_domain_column" (string) "subscriber_table" (string) "subscriber_user_column" (string) "subst(""'/re/repl/flags')" subst(""'/re/repl/flags')"

- 116 -

"subst_uri('/re/repl/flags')" subst_uri('/re/repl/flags')" "subst_user('/re/repl/flags')" subst_user('/re/repl/flags')" "suffix" (string) "support" (string) "sync_time" (integer) "table" (string) "tel_uri_params" (string) "timer_avp" (string) "timer_interval" (integer) "transport_column" (string) "trusted_table" (string) "tw_append" (string) "type_column" (string) "unix_tx_timeout" (integer) "uri_domain_column" (string) "uri_scheme_column" (string) "uri_table" (string) "uri_uriuser_column" (string) "uri_user_column" (string) "use_branch_flags" (integer) "use_contact" (int) "use_contact" (integer) "use_domain" (int) "use_domain" (int) "use_domain" (int) "use_domain" (integer) "use_domain" (integer) "use_domain" (integer) "use_domain" (integer) "use_domain" (integer) "use_domain" (integer) "use_domain" (integer) "use_uri_table" (integer) "user_agent_column" (string) "user_column" (str) "user_column" (string) "user_column" (string) "user_column" (string) "user_column" (string) "username_column" (string) "uuid_column" (string) "value_column" (string) "via1_matching" (integer) "workers" (integer) "wt_timer" (integer)

5.5.2. Ubicación Todas las funciones existentes en la versión usada se encuentran explicadas dentro de cada

módulo, además se puede ver una lista detallada de las mismas en la página:

http://www.openser.org/dokuwiki/doku.php/modules:1.0.x:index-functions.

5.6. Búsqueda de números SIP Típicamente, cuando se desarrollan reglas de enrutamiento, dependiendo del parámetro en

base al cual se esté haciendo el enrutamiento, es necesario seguir una sintaxis específica. Como es el

caso del enrutamiento por URI, FROM, TO.

Las entidades SIP identifican a los usuarios con las SIP URI, definidas en el RFC 2396. Una SIP

URI consta de un usuario y un dominio, delimitado por una @.

Por ejemplo si se desea hacer un enrutamiento por URI en función de los primeros dos dígitos

del teléfono, la sintaxis es la siguiente:

uri=~"^sip:dígitos",

por ejemplo:

if (uri=~"^sip:04"){

regla a ejecutar;

}

Entonces, para ese caso, todos los números 04xx-xxx-xxxx, serán enrutados en función de la

regla desarrollada.

Ahora, pueden presentarse situaciones en las cuales la regla de enrutamiento sea en función del

último digito del número, como es el caso del enrutamiento por repartición de carga, en este caso la

sintaxis a seguir es la siguiente:

uri=~"^sip[0-9]{cantidad_de_nùmeros_a_esperar}dígito_final",

en este caso es necesario especificar la cantidad de números que se espera recibir antes del digito

deseado.

Por ejemplo:

(uri=~"^sip:[0-9]{10}1"),

Continuando el ejemplo anterior si se desea enrutar todos los teléfonos cuyo último dígito sea

impar hacia un dominio en específico, la sintaxis a seguir deberia ser:

Aquí se especifica el dígito en que debe terminar el número. En este caso, 1.

Los primeros diez dígitos pueden ser cualquier número [0-9]

- 118 -

if ((uri=~"^sip:[0-9]{10}1")||(uri=~"^sip:[0-9]{10}3")||(uri=~"^sip:[0-9]{10}5")||(uri=~"^sip:[0-9]{10}7")||(uri=~"^sip:[0-9]{10}9")){ prefix("7"); xlog("REPARTICION DE CARGA"); prefix2domain("2"); };

6. Ejecución del servicio

6.1. Reiniciar el servicio Se necesita reiniciar el servicio cuando se ha hecho alguna modificación dentro del archivo de

configuración ya sea a través de la consola o vía Web, para hacer esto, se ejecuta desde la consola el

siguiente comando:

service ./openser restart,

Sin importar en qué directorio se esté ubicado. Luego para chequear que el servicio se ha iniciado

correctamente (esto no quiere decir necesariamente que el programa hace lo que se quiere, sino que

esta libre de errores de sintaxis) se escribe:

service ./openser status

6.2. Errores del archivo openser.cfg Si cuando se reinicia el servicio, openser no se inicia y cuando se pide el status resulta que el

mismo se encuentra detenido, quiere decir que hay algún error en el archivo de configuración. Para

ver que clase de error es el que impide que el servicio inicie correctamente debe ubicarse en

/var/log:

cd /var/log

Una vez ubicado en el directorio especificado, se ejecuta el comando:

tail –f messages

Este comando permite seguir en tiempo real, los errores y mensajes (logs y xlogs que se

encuentran dentro del archivo de configuración que sirven de información o de punto de referencia

para depurar errores) que ocurren en el archivo de configuración.

- 119 -

6.3. Depuración de errores Para depurar el archivo de configuración es necesario saber la línea donde está ocurriendo el

error. Si es de sintaxis, se debe corregir el mismo y volver a reiniciar el servicio para ver si funciona

correctamente. Si es de linealidad (algún paréntesis o punto y coma), el error puede estar en la línea

correspondiente o antes de ella, para ello es recomendable mantener el archivo con cierto orden para

poder ubicar el error más fácil. Por ultimo, si el error es que no se está ejecutando alguna línea o

algún trozo de código, es recomendable escribir líneas de mensajes para depurar el archivo, así que si

éstas no aparecen en el log de mensajes quiere decir que no esta ejecutando ese trozo de código y ahí

se puede ir viendo, poco a poco, donde está el error.

6.4. Trazas de las llamadas realizadas sobre openSER Para ver el barrido de los mensajes SIP de una llamada o de los mensajes de registro de

números se puede usar la herramienta NGREP, para acceder a ella se coloca en la consola:

ngrep –d “interfaz_de_red” port “puerto”

Donde “interfaz_de_red” es la interfaz que se quiere escuchar, eth0 o eth1 o simplemente any

y el “puerto” es, como dice su nombre, el puerto por el cual se quiere escuchar.

Con esta herramienta también se pueden resolver problemas o errores pero no de código sino

de enrutamiento ya que se pueden diferenciar los mensajes que se mandan entre servidores para

poder hacer que una llamada sea exitosa. De esta forma se puede detectar exactamente en qué punto

está ocurriendo la falla.

Para observar la información debemos ubicarnos en la carpeta:

Colocamos tail –f messages

- 120 -

7. Conexión a la Base de Datos

El OpenSER, para realizar sus llamadas, se conecta con la base de datos Mysql para poder

revisar dentro de una base de ciertas tablas algunos datos o atributos que ayudan con el enrutamiento

de la misma o sencillamente sirven de referencia. Además, el OpenSER tiene la capacidad de

almacenar datos referentes a llamadas o usuarios para el mejor manejo de las llamadas.

7.1. Estructura de las tablas • Accounting (ACC): esta tabla es usada por el módulo ACC para reportar las llamadas exitosas

realizadas.

• Active sessions (active_sessions): esta tabla es usada por SERWeb. No es usada por OpenSER.

• Administrative Privileges (admin_privileges): lista de control de acceso multi-dominio SERWeb

(ACL). No es usada por OpenSER.

• Aliases (aliases): similar a la tabla “location”.

• Database Aliases (dbaliases): esta tabla es usada por el módulo alias_db como alternativa para

los alias del usuario vía userloc.

• Domains (domain): es usada por el módulo domain para determinar si el host de un URI es

local o no.

• Groups (grp): esta tabla es usada por el módulo group como medio para chequear la

membresía a un grupo. Es usado principalmente para el Control de Acceso a listas (ACL’s).

• Gateways (gw): contiene definiciones del gateway de enrutamiento.

• Gateway Groups (gw_grp): esta tabla es usada para propósitos administrativos, con el fin de

asociar nombres con la identificación de grupo del gateway.

• Least Cost Routing (lcr): dicha tabla es usada por las reglas LCR (Least Cost Routing).

- 121 -

• User Locations (location): contiene información perteneciente al usuario registrado en un

momento dado.

• Missed Calls (missed_calls): esta tabla es similar a la acc, pero es usada para reportar

llamadas perdidas.

• Pending (pending): usada por SERWeb. Peticiones de suscripción no confirmadas.

• Phone Book (phonebook): usada por la interfaz del usuario. Contiene la libreta de teléfonos de

los usuarios.

• Server Monitoring (Server_monitoring): No es usada por OpenSER.

• Server Monitoring (Server_monitoring_agg): No es usada por OpenSER.

• Offline Message Storage (silo): esta tabla es usada por el módulo msilo para proveer el

almacenamiento de mensajes offline.

• Subscriber (subscriber): usada para proporcionar información de autentificación.

• Trusted (trusted): usada por el módulo permissions para determinar si una llamada presenta

los permisos apropiados para ser establecida.

• URI (uri): esta tabla es usada por el módulo uri_db para implementar algunos chequeos

concernientes al URI del mensaje SIP.

• User Preferentes (usr_preferentes): es usada por el módulo AVP para implementar “Attribute

Value Pairs AVP’s”

• Table Versions (version): esta tabla contiene los nombres de las tablas de OpenSER, y número

de versión. Es usada por algunas rutinas de OpenSER para asegurar que la versión correcta de

una tabla en particular está siendo usada.

8. Errores Frecuentes

• No se está ejecutando un trozo del archivo ¿Qué hago? Revisa el archivo de configuración y

verifica que el trozo que quieres que se ejecute no este comentado o dentro de algún

comentario mas grande, luego reinicia el servicio. Si no es eso revisa, con logs, que la

ejecución esté pasando por ese trozo de código.

NOTA: la función de xlog([level,] format) sólo puede ser usada por bloques de ruta de petición, de

falla, de respuesta o de salto.

• Dañé el archivo de configuración ¿Qué hago? En el directorio etc/openser/backup se encuentra

el archivo openser_original.cfg. Éste es el archivo base de openser. En caso de no poder

recuperar el archivo de configuración con el que se estaba trabajando, puede dirigirse a esta

carpeta y mediante el comando:

cp openser_original.cfg /etc/openser/openser.cfg

- 122 -

Se sobrescribe el contenido del openser.cfg con el de ese archivo y se puede volver a

comenzar todo. Para no tener que empezar desde cero se recomienda guardar un archivo

“backup” de su configuración cada cierto tiempo. Es recomendable, cuando se hayan logrado

configurar nuevas funcionalidades en el archivo de openser, hacer respaldos del mismo.

9. F.A.Q.

• ¿Cómo acceder remotamente al servidor donde se encuentra instalado OpenSER? Putty es un

cliente software libre de SSH con el que se puede conectar a través de un servidor remoto y

realizar algunas tareas a través del entorno Shell que es una interfaz que permite interactuar a

través de comandos con el sistema operativo, para que éste a su vez nos permita interactuar

con la máquina.

• ¿Cómo se si el OpenSER reinició correctamente? Al ejecutar el comando: service ./openser

restart en la consola comienzan a salir mensajes donde se indica cuál es el status:

Si el mensaje de “Starting openser” es como el mostrado anteriormente, quiere decir

que el servicio se reinicio perfectamente, de no ser así quiere decir que hay un error en el

archivo de configuración.

Otra forma de verificar el inicio exitoso de OpenSER se logra escribiendo en la consola

el comando ps –ax ya que el mismo permite ver cuáles son los procesos que se encuentran

activos en ese instante, si openser se encuentra dentro de ellos, quiere decir que se inició

correctamente.

- 123 -

• ¿Cómo sé si se cargó un módulo sin haber cargado su dependencia? si se carga un módulo

que dependa de otro y éste no ha sido cargado, o fue cargado luego (esto se refiere a una

línea posterior), se mostrará un mensaje de error similar al que se muestra a continuación:

• ¿Sólo puedo trabajar con los mensajes de INVITE? No, se puede trabajar con cualquier

mensaje SIP, lo que se tiene que hacer es configurar el archivo de configuración para que de

la misma manera que lee los mensajes INVITE pueda hacer algo referente a los otros

mensajes.

• ¿Qué pasa si quiero modificar un parámetro o usar una función pero el módulo al cual

pertenece no está cargado? si se hace uso de una función o parámetro y el módulo no fue

cargado en la sección de módulos se mostrará el siguiente error (en el ejemplo que se

muestra, se está haciendo uso de parámetros contenidos en el módulo TM):

• ¿Cómo compilo un módulo de nuevo? En caso de que se desee volver a compilar algún

módulo, debe borrarse de OpenSER el archivo con extensión .so correspondiente al mismo

(rm módulo.so), luego debe hacerse make clean y por ultimo make.

• ¿Cómo busco una línea que tiene un error dentro del openser.cfg? Cuando OpenSER reporta

errores, lo hace indicando la línea del error y un pequeño comentario referente al mismo. Una

forma útil de ubicar esa línea en la consola es:

:número_de_la_línea [ENTER]

No se puede fijar el parámetro del módulo

Módulo TM no encontrado

Línea de error

- 124 -

• ¿Cómo se que hay errores en el script? Cuando se reinicia el servicio y da alguna falla en la

pantalla se muestra:

Se puede observar que se indica que ocurrió una falla iniciando el servicio openser, y

se especifica que existe un error.

Para observar en detalle a qué se debe el error y dónde se encuentra el mismo,

deberá ubicarse en el directorio: /var/log, y ejecutare el comando:

tail –f messages

Una vez corregido el error, se reinicia el servicio de nuevo, si los errores fueron

solventados con éxito, se observará por pantalla:

• ¿Cómo sé que tipo de error esta ocurriendo? Primero debe dirigirse a /var/log y luego escribir

en consola: tail –f messages, para ver el log de mensajes del OpenSER. En este log se

muestra cualquier mensaje escrito desde el archivo de configuración y cualquier error que el

mismo tenga. Luego todo depende del comentario que acompañe al error, por ejemplo, si

faltan las “” o se coloca un nombre de parámetro errado puede salir:

• ¿Cómo hago si quiero que el OpenSER no ejecute una regla o alguna línea de código? Para

hacer que el OpenSER no ejecute algún comando o un trozo de código, basta con comentar la

línea o el trozo de código y así al reiniciar el servicio no se ejecutará la parte comentada.

Para comentar una línea, comience la misma con el carácter #. Para comentar un

trozo de código coloque al inicio del mismo los caracteres: /* y al final */. De esta forma, el

código que se encuentra entre los caracteres: /* */ no se ejecutará.

Línea donde se encuentra el error

- 125 -

• No se está ejecutando un trozo del archivo ¿Qué hago? Revisa el archivo de configuración y

verifica que el trozo que quieres que se ejecute no este comentado o dentro de algún

comentario mas grande, luego reinicia el servicio. Si no es eso revisa, con logs, que la

ejecución esté pasando por ese trozo de código.

NOTA: la función de xlog([level,] format) sólo puede ser usada por bloques de ruta de

petición, de falla, de respuesta o de salto.

• ¿Qué es un log? Un log es un mensaje que se imprime por pantalla en /var/log, con estos logs

se puede ver que parte del script se está ejecutando en ese momento. Para incluir un log en el

archivo sólo se agrega una línea como la siguiente:

xlog(nivel, “TU COMENTARIO VA AQUI”)

xlog([level,] format): La función xlog imprime un mensaje usando la función LOG. El

significado de los parámetros es como se muestra.

• Level: el nivel que será usado en la función log. Puede ser:

o L_ALERT (-3): este nivel será usado si el error requiere una acción inmediata.

o L_CRIT (-2): el nivel debe ser usado si el error involucra una situación crítica.

o L_ERR (-1): este nivel debe ser usado para reportar errores durante el procesamiento

de data, pero que no cause un mal funcionamiento del sistema.

o L_WARN (1): este nivel debe usarse para escribir mensajes de alerta.

o L_NOTICE (2): este nivel debe usarse para reportar situaciones no usuales.

o L_INFO (3): este nivel se usa para escribir mensajes de información.

o L_DBG (4): debe usarse para escribir mensajes para la depuración de errores.

El valor por defecto de este parámetro es L_ERR.

• Format: es la cadena de caracteres que será impresa.

Nota: esta función puede ser usada por: REQUEST_ROUTE, FAILURE_ROUTE, ONREPLY_ROUTE,

BRANCH_ROUTE.

• ¿Qué pasa si daño el archivo de configuración del openser? En el directorio

etc/openser/backup se encuentra el archivo openser_original.cfg. Éste es el archivo base de

openser. En caso de no poder recuperar el archivo de configuración con el que se estaba

trabajando, puede dirigirse a esta carpeta y mediante el comando:

cp openser_original.cfg /etc/openser/openser.cfg

- 126 -

Se sobrescribe el contenido del openser.cfg con el de ese archivo y se puede volver a

comenzar todo. Para no tener que empezar desde cero se recomienda guardar un archivo

“backup” de su configuración cada cierto tiempo. Es recomendable, cuando se hayan logrado

configurar nuevas funcionalidades en el archivo de openser, hacer respaldos del mismo.

• ¿Qué es y cómo funciona el prefix2domain? Es una función del módulo PDT la cual revisa

dentro de la base de datos si el prefijo que existe dentro de cualquier número SIP está dentro

de la lista guardada y de ser así reenruta la llamada al dominio asignado a ese prefijo.

• ¿Cómo hago para ejecutar un script automáticamente? En la aplicación desarrollada, resulta

muy útil la ejecución de scripts de forma automática, bien sea por la hora a la cual se quiere

que se ejecute, o debido a que el script es utilizado para realizar actualizaciones en alguna

base de datos. Para esto puede usarse el comando “cron”.

Cron es un administrador regular de procesos en segundo plano (demonios) que

ejecuta programas a intervalos regulares de tiempo. Los procesos que deben ejecutarse y la

hora para hacerlo, se ejecutan en el archivo crontab.

Los usuarios habilitados para crear su archivo crontab se especifican en

/etc/cron.allow, así mismo, los que no tienen permitido el acceso se especifican en

/etc/cron.deny.

Para agregar, editar o eliminar procesos, se debe ejecutar la orden crontab –e, de

esta forma se cargará el crontab correspondiente al usuario. La sintaxis que debe seguirse es

la siguiente:

Si el comando a ejecutar es un archivo, este deberá tener todos los permisos, para

ello, diríjase a través de la consola a la carpeta donde se encuentra ubicado el mismo, y

ejecute el comando:

chmod 777 nombre_del_archivo

- 127 -

Deberá verificar que el demonio crond esté iniciado, para ello ejecute en la consola el

comando:

service ./crond status

En caso de estar detenido, ejecute la orden:

service ./crond start

10. Apéndice 1: Instalación de programas

10.1. Instalación Fedora Core4 De acuerdo con los requerimientos de programación, se recomienda instalar Fedora como se

muestra a continuación:

1. Welcome to Fedora Core: OK 2. Language Selection: English 3. Keyboard Selection: Es (Español) 4. System to upgrade: Reinstall System 5. Installation Type: What type of system would you like to install: Custom 6. Disk partitioning setup: Autopartition 7. Automatic Partitioning: Remove all partitions on this system 8. Warning: You have chosen to remove all partitions (ALL DATA) on the following drives: OK 9. Which boot loader would you like to use?: Use GRUB Boot Loader. 10. Boot loader Password: ****** (garabato) 11. Boot Loader Configuration:

Default Boot Label Device * Fedora Core /dev/VolGroup00/logVol00

12. Where do you want to install Boot Loader: /dev/ida/c0d0 13. Network Configuraton for Eth0: [*] Activate on boot

14. IP Address: 161.196.58.48

Netmask: 255.255.255.0

15. Network configuration for Eth1: [*] Configure using DHCP 16. Gateway: ________________ (161.196.58.1)

Primary DNS: ____________ (161.196.64.2) Secondary DNS: __________ (161.196.64.3)

17. Hosname Configuration: [*] Manually: admin

- 128 -

18. Firewall: Disable 19. Security Enhanced Linux: Disable

20. Time Zone Selection: América/La_Paz

21. Root Password: garabato

22. Package Group Selection :

[ ] X Window System [ ] GNOME Desktop Enviroment [ ] KDE (K Desktop Enviroment) [ ] Editors [ ] Engineering and Scientific [ ] Graphical Internet [*] Text-based Internet [ ] Office/Productivity [ ] Sound and video [ ] Authoring and publishing [ ] Graphics [ ] Games and Etertainment [*] Server Configuration Tools [*] Web Server [ ] Mail Server [ ] Windows File Server [ ] DNS Name Server [*] FTP Server [ ] PostgreSQL Database [*] MySQL Database [ ] News Server [ ] Network Servers [ ] Legacy Network Server [*] Development Tools [*] X Software Devlopment [ ] GNOME Software Development [ ] KDE Software Development [ ] Legacy Software Development [ ] Java Development [ ] Eclipse [ ] Language Support [*] Administration Tools [*] System Tools [ ] Printing Support [ ] Everything Nota: si se escogen los paquetes seleccionados, sólo se podrá trabajar en modo texto.

23. Installation to begin: OK

o Required Install Media: Continue

- 129 -

10.2. Instalación de OpenSER por paquetes: 1. Descargar del siguiente link: http://www.openser.org/pub/openser/1.0.0/packages/rhel-3.0/

los siguientes archivos y se colocan en la ruta /home/openser:

• openser-1.0.0-rhel3.0.i386.rpm

• openser-cpl-1.0.0-rhel3.0.i386.rpm

• openser-mysql-1.0.0-rhel3.0.i386.rpm

• Openser-1.0.1-tls_src.tar.gz

2.Iniciar mysql. Para ello, debe escribir el siguiente comando en la consola:

mysql –u root –p

3. Posteriormente, deben instalarse los paquetes:

yum install openser-1.0.0-rhel3.0.i386.rpm

rpm –Uvh openser-cpl-1.0.0-rhel3.0.i386.rpm

rpm –Uvh openser-mysql-1.0.0-rhel3.0.i386.rpm

Nota: esto debe hacerse desde la ruta /home/openser

4. Crear la base de datos y tablas de openser

Dirigirse a la ruta /usr/bin y ejecutar el comando: ./openser_mysql.sh create

Para comprobar que la base de datos y tablas de openser se crearon correctamente, ejecutar los

siguientes comandos en la consola:

mysql –u root Show databases;

Al ejecutar dicho comando, debería observar:

Si se ejecutan los comandos:

use openser;

show tables;

Se observará una lista con todas las tablas contenidas en la base de datos de openser.

Base de datos de openser

- 130 -

5. Para tener acceso a ftp, dirigirse a la ruta: /etc/vsftpd, en ella se encuentra un archivo

llamado user_list, debera acceder al él y eliminar al usuario root, de esta forma se le está permitiendo

el acceso al mismo a ftp.

Para que el cambio realizado en el archivo tenga efecto, es necesario reiniciar el servicio,

ejecutando para ello el comando: service ./vsftp restart

6. Instalación del conector php-mysql. Esto es necesario para que las páginas webs

desarrolladas puedan comunicarse sin problemas con la base de datos de openser.

Para ello, debe ejecutarse el comando yum install php-mysql.

10.3. Instalación OpenSER por código fuente 1. Descargar openser-mysql-module_1.1.0-0_i386.deb del siguiente link:

http://www.openser.org/pub/openser/1.1.0/packages/deb-stable/openser-mysql-module_1.1.0-

0_i386.deb

Tablas contenidas en la Base de datos de openser

- 131 -

2. Hacer la instalación de openser-mysql-module_1.1.0-0_i386.deb en /home de la siguiente

forma: rpm –Uvh openser-mysql-module_1.1.0-0_i386.deb

3. Descargar el paquete (código fuente): openser-1.1.0-notls_src.tar.gz de la página web:

http://www.openser.org/pub/openser/latest/src/openser-1.1.0-notls_src.tar.gz

4. Descomprimir el archivo haciendo: tar –zxvf openser-1.1.0-notls_src.tar.gz

En la carpeta donde descargamos el paquete openser-1.1.0-notls_src hacemos:

make prefix=/

make openser prefix=/

make modules prefix=/

Se hace la instalación: make prefix=/ install

Los archivos binarios y ejecutables fueron instalados en: /sbin

-openser

-openserctl

-openserunix

En /home/openser-1.1.0-notls/scripts se encuentran los archivos :

-gen_ha1

-mysql.sh

Para crear la base de datos de MySQL se tiene que utilizar el script mysql.sh

Hacemos: ./mysql.sh create

Para chequear que todo está correcto, introducir: openser –V

En dicho caso, se debe observar un mensaje como el que se muestra a continuación:

Openser -V

Mensaje devuelto: Incluye versión instalada

de OpenSER, fecha de instalación

- 132 -

10.4. Instalación Putty

Uso de Putty

Al iniciar el programa se muestra la siguiente pantalla:

Se puede observar que se indica el nombre del host (“Host Name”), puerto (“port”) y las

sesiones almacenadas (“saved sessions”).

2. Crear sesión

Para esto, se debe ingresar el nombre del host, protocolo y un nombre para guardar la

configuración.

En nuestro caso, el nombre del host corresponde a la dirección ip del servidor donde se

encuentra instalado OpenSER (161.196.58.47), Openser es el nombre que se le asignó a la sesión, el

puerto es el 22, y se debe ecoger como protocolo SSH.

Putty no necesita instalarse, sólo lo ejecutas y entras

- 133 -

Iniciar Sesión

La primera vez que se acceda a un servidor, el programa nos pedirá nuestro consentimiento

para poder acceder al mismo.

Por último, se debe ingresar el login y password, con lo cual se habrá iniciado sesión.

- 134 -

10.5. Instalación ngrep Se deben realizar los siguientes pasos estando registrado como root. Para una mayor seguridad,

se pueden realizar la mayoría de estos pasos como un usuario ordinario, pero un paso requiere estar

registrado como root.

1.- Dirigirse a http://ngrep.sourceforge.net para descargar el paquete. Descargar el archivo:

ngrep-1.44-1.tar.bz2. Se puede salvar el archivo en el directorio /home.

2.- Dirigirse a la consola y asegurarse que el archivo descargado se encuentra en el directorio

actual.

3.- Descomprimir el archivo con el comando

bzip2 –dc ngrep-1.44-1.tar.bz2 | tar xvf -

Se creará entonces un subdirectorio llamado: ngrep-1.44-1.

4.- ./configure [ENTER]

5.- make

6.- para el paso siguiente se debe estar registrado como root, si no se encuentra registrado

como root, colocar el comando su en la consola y responder al password preguntado (este password

se refiere al del usuario root).

7.- make install

El programa ngrep será ahora instalado en el directorio /home.

8.- Para el paso siguiente no es necesario estar registrado como root. Colocar exit para volver a

la sesión ordinaria del usuario.

9.- Ahora está instalado el programa ngrep.

10.6. Creación de una conexión VPN

- 135 -

1. Desde el botón Inicio, dirigirse al menú Configuración, hacer click Panel de Control y luego en

Conexiones de red y Acceso Telefónico. Después deberá hacer doble clic en el ícono Realizar

conexión nueva.

2. Luego de que se ha iniciado el Asistente para Conexión de Red, hacer clic en el botón

siguiente.

3. Se observará una una pantalla como la mostrada a continuación. En ella se deberá elegir la

opción “Conectar a una red privada a través de Internet”, y hacer clic en Siguiente.

4. En la siguiente pantalla, seleccionar la opción “No usar la conexión inicial”, y hacer clic en

siguiente.

- 136 -

5. Posteriormente, deberá especificarse la dirección IP del equipo al cual se está conectando. En

nuestro caso: 200.44.0.200

6. Por último deberá especificarse el nombre con el cual se desea identificar a la conexión, luego

hacer clic en el botón Finalizar.

7. Cuando se desee conectar a la VPN, aparecerá una pantalla como la mostrada. Deberá

introducir el nombre de usuario y contraseña.

- 137 -

10.7. Instalación de MySQL Front 1. Se descargó de la web la versión de prueba de MySQL Front.

2. Al iniciar el proceso de instalación, se observará una pantalla como la que se muestra. Deberá

hacer clic en la opción: Siguiente.

3. Aceptar los términos de licencia, y hacer clic en la opción: Siguiente:

- 138 -

4. Especificar la ruta donde se instalará el programa

5. Seleccionar la carpeta de menú de inicio, es decir, donde se colocan los íconos de acceso

directo al programa.

6. Seleccionar las tareas adicionales a ejecutar, y hacer clic en Siguiente:

- 139 -

7. Aparecerá una pantalla como la que se muestra a continuación. En este instante, el programa

ya se encuentra listo para instalarse. Hacer clic en el botón instalación.

Con esto, puede darse por finalizado el proceso de instalación. Ahora será necesario realizar la

configuración de la sesión.

10.7.1. Configuración de MySQL Front 1. Al abrir el programa, dirigirse al menú “Files”, y hacer clic en la opción “Connection”.

Aparecerá una ventana de diálogo como la que se muestra a continuación. La misma permitirá

crear la sesión para manejar la base de datos del servidor.

2. Para crear una sesión debe hacerse clic en la opción “New”, y se mostrará una pantalla como

la siguiente:

- 140 -

En la pestaña General debe especificarse el nombre de la sesión.

En la pestaña Conection debe colocarse la dirección IP del servidor. En nuestro caso: 161.196.58.48.

En la pestaña Login se debe colocar el nombre de usuario y contraseña y la correspondiente base de

datos con la cual se quiere establecer la conexión.

10.8. Instalación de X-lite 1. Descargar la versión 3 de X-lite del siguiente link:

http://www.xten.com/index.php?menu=download

2. Ejecutar el archivo haciendo doble clic. Al hacer esto, aparecerá una pantalla como la que se

muestra a continuación:

3. Posteriormente se presentará una ventana de verificación. Seleccionar la opción “I accept the

agreement” y hacer clic en el botón Next.

- 141 -

4. Se debe seleccionar cuál será el destino donde se instalará X-Lite, y luego hacer clic en el

botón Next.

5. Se pueden seleccionar opciones adicionales según se desee.

- 142 -

6. Luego de esto se da por iniciado el proceso de instalación

7. Por último aparecerá una ventana como la mostrada. En este momento habrá finalizado el

proceso de instalación de X-Lite. Debe chequear que la opción Launch X-Lite se encuentre

seleccionada, ya que de esta forma se cargará automáticamente la aplicación al presionar el

boton Finish. Posteriormente se prosigue con la configuración.

Configuración X-Lite

1. Luego de la instalación de X-Lite aparecerá una pantalla como la siguiente, en este momento

se puede configurar el Softphone.

- 143 -

2. Al hacer clic en la opción Sip Account Settings, se mostrará una pantalla como la siguiente:

Se debe marcar la opción enabled y hacer clic en el botón add. De esta forma, se está

agregando una cuenta. Al hacer esto aparecerá una ventana donde se deberán modificar un grupo de

parámetros.

“Display Name”: acá debe colocar el nombre completo

“User name”: debe ingresar el número de teléfono que tien asignado.

“Password”: ingrese su contraseña

“Authorization user name”: nombre que aparecerá cuando se realiza la llamada.

“Domain”: dominio que se está usando

- 144 -

10.9. SIPp SIPp es una herramienta de código abierto para realizar pruebas de generación de tráfico

sobre el protocolo SIP. Incluye algunos escenarios de agentes de usuario SipStone15 (Agentes de

Usuario Cliente y Agentes de Usuario Servidor) y puede establecer y liberar múltiples llamadas con los

métodos de INVITE y BYE. Presenta una muestra dinámica de las estadísticas de las pruebas activas

(ver figura X), descargas periódicas de las versiones con nuevas características, TCP y UDP sobre

multiples “sockets” con retransmisión supervisada y ajuste dinámico de la tasa de llamadas.

Algunas de características presentadas por SIPp son el soporte de IPv6, TLS, autentificación

SIP, escenarios condicionales, retransmisiones UDP, robustez ante errores, expresiones regulares Posix

para extraer y re-insertar cualquier campo en el protocolo, ejecutar acciones en función del comando

recibido, entre otras.

SIPp puede además enviar tráfico de media RTP a través de “RTP echo”16 y “RTP/pcap”17. La

media puede ser audio o audio y video.

Mientras se optimiza el tráfico, stress y el funcionamiento de la prueba, SIPp puede ser usado

para ejecutar una sola llamada y salir, dando como resultado un veredicto de aprobado o fallido.

También puede ser usado para probar equipos SIP como SIP proxies, B2BUAs, servidores de

media SIP, SIP/x gateways, SIP PBX. Además es muy útil para emular miles de agentes de usuario

llamando a un sistema SIP a evaluar.

Escenario de SIPp

15 Es un “benchmark” para los SIP Proxy y Servidores de Redireccionamiento. El término “benchmark” se refiere a una técnica para medir la capacidad del manejo de peticiones SIP de un Servidor SIP o un grupo de ellos. 16 La característica “RTP echo” permite a SIPp escuchar una o dos direcciones IP locales y el puerto para la media RTP. 17 La característica “PCAP Play” hace uso de la librería PCAP para reenviar trazas de streams RTP hacia su destino.

- 145 -

10.9.1. Versiones de SIPp Como otros proyectos de código abierto, existen dos versiones de SIPp: la estable y la

inestable. La versión estable, como su nombre lo indica ha sido probada en detalle. Por ello se puede

estar seguro de que las características mencionadas funcionarán correctamente.

Los creadores de SIPp recomiendan trabajar con la versión estable para el uso diario si no se

necesita una característica específica que se encuentra solamente en la versión inestable.

Las nuevas características y arreglos se colocan en la página de SIPp tan pronto como éstas se

encuentren disponibles.

Cada noche se hace una extracción automática y el código fuente de dicha versión está

disponible.

Los creadores de SIPp recomiendan usar la versión inestable solamente en caso de que se

necesite un parche o una nueva característica que no se encuentra disponible en la versión estable.

Pasos para la instalación de SIPp

Para instalar SIPp se debe descargar el ejecutable sipp-1.1rc6.win32-setup.exe que se

encuentra en la página http://sourceforge.net/project/showfiles.php?group_id=104305 y correr el

mismo.

10.9.2. Plataformas Disponibles SIPp está disponible en la mayoría de las plataformas UNIX: HPUX, Tru64, Linux (RedHat,

Debian, FreeBSD), Solaris/Sun/OS.

10.9.3. Características Principales Sipp permite generar una o varias llamadas SIP a un sistema remoto. La herramienta es

iniciada desde la línea de comando. En el ejemplo mostrado, dos sipp son puestos en marcha uno en

frente de otro para demostrar las capacidades de sipp.

Ejecución de SIPp en un escenario de servidor (uas):

• sipp.exe –sn uas

Ejecución de SIPp en un escenario de cliente

• sipp.exe -sn uac 127.0.0.1

10.9.4. Control de Tráfico SIPp genera tráfico SIP de acuerdo al escenario especificado, ya que se puede controlar el

número de llamadas que se iniciarán por segundo. Esto se puede hacer de dos maneras:

De forma interactiva, presionando en el teclado:

• La tecla ‘+’ incrementa la tasa de llamadas en 1.

• La tecla ‘-’ decrementa la tasa de llamadas en 1.

- 146 -

• La tecla ‘*’ incrementa la tasa de llamadas en 10.

• La tecla ‘/’ decrementa la tasa de llamadas en 10.

Al momento de inicio, especificando los parámetros en la línea de comando.

• “-r” para especificar la tasa de llamadas en número de llamadas por segundo.

• “-rp” para especificar el periodo en milisegundos para la tasa de la llamada (el valor

por defecto es 1000ms/1s). Esto permitirá tener “n” llamadas cada una de “m” milisegundos.

(Mediante el uso de –r n –rp m).

Por ejemplo, para correr SIPp a 7 llamadas cada 2 segundos (3.5 llamadas por segundo). Para

ello debe colocarse:

Cliente:

Sipp.exe –sn uac –r 7 2000 161.196.58.48

Servidor:

sipp.exe –sn uas

También puede detenerse el tráfico presionando la tecla ‘p’. SIPp detendrá el establecimiento

de nuevas llamadas y esperará hasta que todas las llamadas actuales culminen. Se podrá reiniciar el

tráfico presionando la tecla ‘p’ de nuevo.

Para quitar SIPp se debe presionar la tecla ‘q’. SIPp detendrá el establecimiento de nuevas

llamadas y esperará a que todas las llamadas actuales lleguen a su fin. En ese momento se podrá salir

de SIPp.

Se pueden colocar un número definido de llamadas y salir de SIPp cuando las mismas hayan

finalizado. Use para ello la opción –m en la línea de comando.

10.9.5. Consumo de memoria Para tener conocimiento del consumo de memoria que está originando SIPp, debe ejecutarse

el comando top en la línea de comandos.

Al hacer esto, se observará una pantalla como la que se muestra en la siguiente figura

- 147 -

Consumo de memoria

Este comando muestra en tiempo real la situación de los procesos que se están ejecutando en

el sistema, ordenados por defecto según el porcentaje la CPU que estén usando. Al ejecutarlo se podrá

ver otra información adicional, como la cantidad de usuarios que están en el sistema, cuántos procesos

están corriendo y de estos cuántos estas activos, cuántos durmiendo, cuántos en proceso de terminar

(ZOMBIE) y cuántos finalizados. Además se podrá ver la cantidad e memoria física total, la cantidad

usada y la cantidad libre; así como también se podrá obtener la misma información de la memoria

swap.

Lo más importante es que esta información de irá actualizando automáticamente cada cierto

tiempo, por defecto 5 segundos, de esta forma se tiene conocimiento de la evolución de la memoria a

medida que SIPp y el resto de los programas se están ejecutando.

11. Apéndice 2: Explicación de las líneas del archivo de configuración del OpenSER

# # $Id: openser.cfg,v 1.6 2006/02/15 18:23:46 bogdan_iancu Exp $ # # simple quick-start config script # #------------------------------------------------------------------------------------- # parametros de configuracion global #------------------------------------------------------------------------------------- 1. debug=3 # nivel de depuración (cmd line: -dddddddddd) 2. fork=yes

- 148 -

3. log_stderror=no # (cmd line: -E) /* Descomente esto para agregar líneas de modo de depuración 4. fork=no 5. log_stderror=yes */ 6. check_via=no # (cmd. line: -v) 7. dns=no # (cmd. line: -r) 8. rev_dns=no # (cmd. line: -R) 9. port=5060 10. listen=eth0:5060 11. children=4 12. fifo="/tmp/openser_fifo" 13. fifo_db_url="mysql://openser:[email protected]/openser" # # Descomente las siguientes líneas para soporte TLS 14. #disable_tls = 0 15. #listen = tls:your_IP:5061 16. #tls_verify = 1 17. #tls_require_certificate = 0 18. #tls_method = TLSv1 19. #tls_certificate = "//etc/openser/tls/user/user-cert.pem" 20. #tls_private_key = "//etc/openser/tls/user/user-privkey.pem" 21. #tls_ca_list = "//etc/openser/tls/user/user-calist.pem" #------------------------------------------------------------------------------------- # Modulos iniciales cargados #------------------------------------------------------------------------------------- 22. mpath="/usr/lib/openser/modules" 23. loadmodule "mysql.so" 24. loadmodule "sl.so" 25. loadmodule "tm.so" 26. loadmodule "rr.so" 27. loadmodule "maxfwd.so" 28. loadmodule "usrloc.so" 29. loadmodule "registrar.so" 30. loadmodule "textops.so" #------------------------------------------------------------------------------------- # Más módulos #------------------------------------------------------------------------------------- 31. loadmodule "uri.so" 32. loadmodule "uac.so" # tm.so & rr.so deben haberse cargado! 33. loadmodule "mediaproxy.so" 34. loadmodule "acc.so" # tm.so & rr.so deben haberse cargado! 35. loadmodule "permissions.so"

- 149 -

36. loadmodule "xlog.so" 37. loadmodule "enum.so" # mysql.so deben haberse cargado antes de cargar los siguientes módulos! loadmodule "auth.so" # Descomente esto si quiere procesar la autentificación loadmodule "auth_db.so" # Descomente esto si quiere procesar la autentificación 38. loadmodule "domain.so" 39. loadmodule "group.so" 40. loadmodule "avpops.so" 41. loadmodule "lcr.so" 42. loadmodule "uri_db.so" 43. loadmodule "pdt.so" 44. loadmodule "nathelper.so" #INSERTE MODULO NUEVO AQUI #------------------------------------------------------------------------------------ # Inicialización de los parámetros específicos de cada modulo #------------------------------------------------------------------------------------ # -- parámetros de usrloc -- 45. modparam("usrloc", "db_mode", 2) #Los cambios ocurren en memoria y en la base de datos # -- parametros de permisions -- 46. modparam("permissions", "default_allow_file", "/etc/openser/permissions.allow") 47. modparam("permissions", "default_deny_file", "/etc/openser/permissions.deny") 48. modparam("permissions", "db_mode", 1) #La base de datos se va modificando 49. modparam("permissions", "trusted_table", "trusted") #Nombre de la tabla base en la base de datos # -- parámetros de auth -- # Descomente esto si esta usando el modulo auth # Este es el URL de la base de datos q se va a usar 50. modparam("auth_db|permissions|uri_db|usrloc|acc|msilo|grp|domain|lcr", "db_url", "mysql://openser:[email protected]/openser") 51. modparam("auth_db", "calculate_ha1", yes) #la columna señalada contiene la contraseña en texto y con esta calcula el HA1 52. modparam("auth_db", "password_column", "password") #Este es el nombre de la columna que contiene las contrasenas. # -- parámetros de group -- 53. modparam("group", "table", "grp") #Nombre de la tabla que contiene los grupos y sus miembros 54. modparam("group", "use_domain", 0) #Deshabilita la búsqueda por dominio y sólo queda por nombre de usuario 55. modparam("group", "user_column", "username") #Nombre de la columna que contiene los nombres de usuario 56. modparam("group", "domain_column", "domain") 57. modparam("group", "group_column","grp") #Nombre de la columna que contiene los grupos # -- parámetros de rr -- 58. modparam("rr", "enable_full_lr", 1) # Ayuda con los UAs que eliminan el parámetro ";lr"

- 150 -

59. modparam("rr", "append_fromtag", 1) #Si esta encendido, las peticiones de la etiqueta from se anexan al "record_route", útil para entender los siguientes mensajes o peticiones # -- parámetros de tm -- 60. modparam("tm", "fr_timer", 20) #Tiempo de espera por una petición o un ACK por respuesta a un INVITE negativo 61. modparam("tm", "fr_inv_timer", 45) #Tiempo de espera por la respuesta a un INVITE después de un mensaje provisional (sec) 62. modparam("tm", "wt_timer", 20) # Tiempo de transacción en memoria para absorber mensajes retrasados, si el tiempo expira se retrasnmiten CANCEL localmente. 63. #modparam("tm", "noisy_ctimer", 1) # Si esta activo, las transacciones del INVITE fr_timer serán canceladas. # -- parámetros de acc -- 64. modparam("acc", "db_flag", 1) #Bandera que lleva la contabilidad de las transacciones realizadas 65. modparam("acc", "db_missed_flag", 3) #Bandera que lleva la contabilidad de las llamadas perdidas 66. modparam("acc", "log_level", 3) #Nivel al cual son mostrados los mensajes en el syslog 67. modparam("acc", "log_flag", 1) #Activar para llevar la contabilidad de las transacciones 68. modparam("acc", "log_missed_flag", 3) #Activar para llevar la contabilidad de llamadas perdidas 69. modparam("acc", "log_fmt", "cdfimorstup") #Indica que parte de los encabezados muestra el syslog 70. modparam("acc", "report_ack", 1) # Mantiene un reporte de los ACK de las llamadas 71. modparam("acc", "report_cancels", 1) #Reporta los CANCEL en las llamadas para llevar su contabilidad 72. modparam("acc", "failed_transaction_flag", 4) #Dice si la transacción puede ser contabilizada en caso de falla. 73. modparam("acc","db_table_missed_calls","missed_calls") #Nombre de la tabla de contabilidad de llamadas perdidas 74. modparam("acc","db_table_acc","acc") #Nombre de la tabla de de llamadas exitosas # -- parámetros de pdt -- 75. modparam("pdt", "db_table", "prefix_domain") # Nombre de la tabla de prefijos 76. modparam("pdt", "domain_column", "domain") # Nombre de la columna de dominio 77. modparam("pdt", "prefix_column", "prefix") # Nombre de la columna de prefijo 78. modparam("pdt", "db_url", "mysql://openser:[email protected]/openser") #nombre

de la base de datos # -- parámetros de domain -- 79. modparam("domain", "domain_table", "domain") # Nombre de la tabla que contiene los nombres de los dominios locales los cuales son responsabilidad del proxy 80. modparam("domain", "domain_col", "domain") #Nombre de la columna que contiene los dominios # -- parámetros de msilo -- 81. #modparam("msilo", "registrar", "sip:[email protected]) #The SIP address used to

#inform users that destination of their message is not online and the message will be #delivered next time when thst users goes online. MAKE SURE THIS IS THE LOCAL OR #RUSTED DOMAIN

# --parámetros de nathelper --

- 151 -

82. modparam("nathelper","natping_interval",10) #Tiempo (seg) entre el envío de pings NATs a los UAs # -- parámetros de registrar -- 83. modparam("registrar","nat_flag", 6) #Si esta bandera está en alto entonces el registro viene detrás de un NAT. 84. modparam("registrar","default_expires",1800) # Crea nuevos registros en los USRLOCS 85. modparam("registrar","min_expires",60) # El mínimo tiempo en que expira el valor de un contacto 86. modparam("registrar","max_expires",120) #El máximo tiempo en que expira el valor de un contacto 87. modparam("registrar","retry_after",30) # Genera un mensaje de respuesta 88. modparam("registrar","append_branches",1) # Sólo la petición con mas alto valor Q es sobrescrita # -- parámetros de avpops -- 89. modparam("avpops", "avp_url", "mysql://openser:[email protected]/openser") 90. modparam("avpops", "avp_table", "usr_preferences") 91. modparam("avpops","avp_aliases","email=s:email_addr;fwd=i:753;$Tf=s:time;$from=$fU") 92. modparam("avpops","uuid_column","uuid") 93. modparam("avpops","username_column","username") 94. modparam("avpops","domain_column","domain") 95. modparam("avpops","attribute_column","attribute") 96. modparam("avpops","value_column","value") 97. modparam("avpops","type_column","type") # -- parámetros de uac -- 98. modparam("uac","from_restore_mode","auto") #Las peticiones y respuestas son guardadas

#automáticamente en el URI # -- parámetros de xlog -- 99. modparam("xlog","buf_size",8192) # Tamaño máximo del mensaje en el log #INSERTE PARAMETRO NUEVO AQUI #------------------------------------------------------------------------------------- # Lógica de Petición de Ruta #------------------------------------------------------------------------------------- # Lógica de rutina principal 100. route{ 101. append_time(); # Mostrar la hora en las respuestas de peticiones #----------------------------------------------------------------------------- # Chequeo inicial #----------------------------------------------------------------------------- 102. # max_forwards==0, o peticiones excesivamente largas 103. if (!mf_process_maxfwd_header("10")) { 104. log(1, "WARNING: Too many hops\n"); 105. sl_send_reply("483","Too Many Hops, forward count exceeded limit\n");

- 152 -

106. exit; 107. }; 108. if (msg:len >= 2048 ) { 109. log(1, "WARNING: Messge too large >=2048 bytes\n"); 110. sl_send_reply("513", "Message too big, exceeded the limit\n"); 111. exit; 112. }; #----------------------------------------------------------------------------- # Sección de "Keep-Alive" con NOTIFY (mantener activa la conexión) #----------------------------------------------------------------------------- 113. if ((method=="NOTIFY")&& search("^Event: keep-alive")) { 114. sl_send_reply("200","OK"); 115. exit; 116. } #----------------------------------------------------------------------------- # Sección de OPTIONS #----------------------------------------------------------------------------- 117. if (method=="OPTIONS") { 118. ###options_reply(); 119. exit; 120. } #------------------------------------------------------------------------------- # Sección de grabación de ruta # # se guardan todas las rutas de los mensajes -- para estar seguros que los otros # mensajes siguientes puedan ir a través del proxy; esto es particularmente # bueno si los entes de entrada y salida usan distintos protocolos de transporte #------------------------------------------------------------------------------- 121. if (!method=="REGISTER" && !method=="ACK") { 122. setflag(1); 123. setflag(2); 124. }; #----------------------------------------------------------------------------- # No enviar al correo de voz si es BYE o CANCEL y es usado para terminar la # llamada antes de contestar o por que se acabo el tiempo #----------------------------------------------------------------------------- 125. if (method=="CANCEL" || method=="BYE") { 126. #end_media_session(); 127. setflag(1); 128. setflag(3); 129. }; #----------------------------------------------------------------------------- # Sección de Registro

- 153 -

#----------------------------------------------------------------------------- 130. if (method=="REGISTER") { 131. if (!www_authorize("161.196.58.48", "subscriber")) 132. { 133. www_challenge("161.196.58.48", "0"); 134. 135. exit; 136. }; 137. if (!check_to()){ 138. sl_send_reply("401","Unauthorized"); 139. exit; 140. } # Guardar en la base de datos de usuarios, si el chequeo indico que # el usuario esta disponible 141. log(1, "REGISTER: User Authenticated Correctly\n"); 142. save("location"); 143. exit; 144. }; #------------------------------------------------------------------------------ # Rechazo de llamadas con ID desconocido #----------------------------------------------------------------------------- 145. if ((method=="INVITE")&&(search("^(f|F)rom:.*(a|A)nonymous")||(search("^(f|F)rom:.*(u|U)nknow")))){ 146. log(1,"From:Anonymous"); 147. route(5); 148. exit; 149. }; #------------------------------------------------------------------------------ # Sección de ruta débil # # Los mensajes siguientes sin dialogo pueden tomar el camino determinado por el # camino registrado "record-routing" #------------------------------------------------------------------------------ 150. if (loose_route()) { # marcar la lógica de petición de enrutamiento 151. append_hf("P-hint: rr-enforced\r\n"); 152. route(1); 153. }; #------------------------------------------------------------------------------ # Sección de enrutamiento por Alias #------------------------------------------------------------------------------ 154. lookup("aliases"); 155. if (!uri==myself) { 156. append_hf("P-hint: outbound\r\n");

- 154 -

157. route(1); 158. }; #------------------------------------------------------------------------------ # si la petición es de otro dominio usar el Usrloc (en caso de que no funcione, # usar los siguientes comandos con los nombres apropiados y las direcciones # adecuadas (usar la sección del INVITE) #------------------------------------------------------------------------------ #------------------------------------------------------------------------------ # Redireccionamiento #------------------------------------------------------------------------------ /* 159. rewriteuri("sip:[email protected]"); # reescribe el URI actual 160. # append_branch("sip:[email protected]:9"); 161. sl_send_reply("300", "Redirect"); #Redireccionar */ #------------------------------------------------------------------------------ # HORA Y METODO EN EL LOG #------------------------------------------------------------------------------ 162. xlog("$Tf"); #imprime en el syslog el campo "Date" 163. xlog("time $Tf method <$rm> r-uri <$ru>\n"); #------------------------------------------------------------------------------ # Seccion de INVITE #------------------------------------------------------------------------------ 164. if (uri==myself) { 165. if (method=="INVITE"){ 166. append_time(); 167. setflag(1); 168. setflag(2); 169. setflag(3); #--------------------------------------------------------------------- # ENRUTAMIENTO POR URI #--------------------------------------------------------------------- #------------------------------------------------------------- /* # Llamadas a voip.brujula.net #------------------------------------------------------------- 170. if (uri=~"^sip:8"){ 171. log(1,"CALL: Call to voip.brujula.net (8) \n"); 172. route(4); 173. }; 174. if (uri=~"^sip:\*"){ 175. xlog("CALL: Call to voip.brujula.net (*) \n"); 176. strip(1);

- 155 -

177. route(2); 178. }; #------------------------------------------------------------- # Llamadas por prefix to domain #------------------------------------------------------------- 179. if (uri=~"^sip:04"){ 180. prefix("7"); 181. xlog("CALL: Llamadas a números móviles (04XX-XXX-XX-XX)\n"); 182. prefix2domain("2"); 183. }; 184. if (uri=~"^sip:02"){ 185. prefix("7"); 186. xlog("CALL: Llamadas a números nacionales (02XX-XXX-XX-XX)\n"); 187. prefix2domain("2"); 188. }; 189. if (uri=~"^sip:00"){ 190. prefix("7"); 191. xlog("CALL: Llamadas a números internacionales (00-país-área-número)\n"); 192. prefix2domain("2"); 193. }; 194. if (uri=~"^sip:7"){ 195. xlog("CALL: Call to PSTN (7) \n"); 196. prefix2domain("2"); 197. }; 198. if (uri=~"^[0-9]2"){ 199. prefix("0001"); 200. xlog ("PAAAAAAAAR"); 201. prefix2domain("1"); 202. }; #------------------------------------------------------------- # Llamadas a Asterisk #------------------------------------------------------------- 203. if (uri=~"^sip:1112"){ 204. xlog("CALL: Call to Asterisk (1112) \n"); 205. }; #------------------------------------------------------------- # Llamadas a brekeke #------------------------------------------------------------- 206. if (uri=~"^sip:2"){ 207. log(1,"CALL: Call to Brekeke (2) \n");

- 156 -

208. route(6); 209. }; */ # INSERTE REGLA DE ENRUTAMIENTO POR URI AQUI #--------------------------------------------------------------------- # ENRUTAMIENTO POR CAMPO:"FROM" --------------------------------------------------------------------- /* 210. if (search("[Ff][Rr][Oo][Mm]: 1111")){ 211. xlog("ENRUTAMIENTO POR FROM"); 212. prefix("7"); 213. prefix2domain("2"); 214. }; */ # INSERTE REGLA DE ENRUTAMIENTO POR FROM AQUI #--------------------------------------------------------------------- # ENRUTAMIENTO POR CAMPO:"TO" #--------------------------------------------------------------------- 215. /* if (search("[Tt][Oo]: <sip:04")){ 216. xlog("ENRUTAMIENTO POR FROM"); 217. prefix("7"); 218. prefix2domain("2"); 219. };*/ # INSERTE REGLA DE ENRUTAMIENTO POR TO AQUI #--------------------------------------------------------------------- # ENRUTAMIENTO POR "HORA" #--------------------------------------------------------------------- 220. /* if (uri=~"^sip:04"){ 221. prefix("7"); 222. xlog("CALL: Llamadas a números móviles (04XX-XXX-XX-XX)\n"); 223. prefix2domain("2"); 224. }; 225. if (uri=~"^sip:02"){ 226. prefix("7"); 227. xlog("CALL: Llamadas a números nacionales (02XX-XXX-XX-XX)\n"); 228. prefix2domain("2"); 229. }; 230. if (uri=~"^sip:00"){ 231. prefix("7"); 232. xlog("CALL: Llamadas a números internacionales (00-país-área-número)\n"); 233. prefix2domain("2"); 234. }; 235. if (uri=~"^sip:7"){ 236. xlog("CALL: Call to PSTN (7) \n");

- 157 -

237. prefix2domain("2"); 238. }; */ # INSERTE REGLA DE ENRUTAMIENTO POR HORA AQUI #--------------------------------------------------------------------- # REPARTICION DE CARGA #--------------------------------------------------------------------- 239. if((uri=~"^sip:[0-9]{10}1")||(uri=~"^sip:[0-9]{10}3")||(uri=~"^sip:[0-9]{10}5")||(uri=~"^sip:[0-9]{10}7")||(uri=~"^sip:[0-9]{10}9")){ 240. prefix("7"); 241. xlog("REPARTICION DE CARGA"); 242. prefix2domain("2"); 243. }; 244. if((uri=~"^sip:[0-9]{10}2")||(uri=~"^sip:[0-9]{10}4")||(uri=~"^sip:[0-9]{10}6")||(uri=~"^sip:[0-9]{10}8")||(uri=~"^sip:[0-9]{10}0")){ 245. prefix("7"); 246. xlog("REPARTICION DE CARGA"); 247. prefix2domain("2"); 248. }; # INSERTE REGLA DE ENRUTAMIENTO POR CARGA AQUI 249. }; 260. route(1); 261. }; #--------------------------------------------------------------------- # Destinos propios de SIP son manejados por la base de datos USRLOC #--------------------------------------------------------------------- 262. if (!lookup("location")) { 263. log(1,"404 not found"); 264. sl_send_reply("404", "Not Found"); 265. exit; 266. }; 267. append_hf("P-hint: usrloc applied\r\n"); 268. route(1); 269. } #------------------------------------------------------------------------------------ # Sección de Rutas #------------------------------------------------------------------------------------

- 158 -

270. route[1] { # enviarlo fuera, usar reenvío con seguimiento de estados incluso para UDP2TCP 271. if (!t_relay()) { 272. sl_reply_error(); 273. setflag(1); 274. setflag(2); 275. setflag(3); 276. }; 277. t_on_failure("1"); 278. exit; 279. } 280. route[2] { 281. rewritehost("65.110.41.100"); 282. forward(65.110.41.100,5060); 283. setflag(1); 284. setflag(2); 285. setflag(3); 286. t_on_failure("1"); 287. exit; 288. } 289. route[3]{ 290. exit; 291. } 292. route[4]{ 293. rewriteuri("sip:[email protected]"); # reescribe el URI actual 294. sl_send_reply("300", "Redirect"); #Redireccionar 295. setflag(1); 296. setflag(2); 297. setflag(3); 298. t_on_failure("1"); 299. exit; 300. } 301. route[5]{ 302. log(1,"Anonymous call rejection \n"); 303. rewriteuri("sip:[email protected]"); 304. t_on_failure("1"); 305. log(1,"Anonymous call rejection 1\n"); 306. #t_on_reply("1"); 307. if (!t_relay()) { 308. sl_reply_error(); 309. }; 310. } 311. route[6]{ 312. rewritehost("161.196.169.238");

- 159 -

313. forward(161.196.169.238,5060); 314. setflag(1); 315. setflag(2); 316. setflag(3); 317. t_on_failure("1"); 318. exit; 319. } 320. route[7]{ 321. rewritehost("161.196.58.47"); 322. forward(161.196.58.47,5060); 323. setflag(1); 324. setflag(2); 325. setflag(3); 326. t_on_failure("1"); 327. exit; 328. } #INSERTE RUTA AQUI 329. failure_route[1]{ 330. log(1,"SECOND ROUTE 161.196.58.48\n"); 331. append_branch("sip:[email protected]"); 332. t_on_failure("2"); 333. t_relay(); 334. } 335. failure_route[2] { 336. log(1,"NO MORE ROUTE\n"); 337. t_reply("503", "Service not available"); 338. }

OpenSER está construido en base a un núcleo de procesos que recibe mensajes SIP y habilita

funciones básicas para el manejo de los mismos. La mayor parte de la funcionalidad de OpenSER se

ofrece a través de sus módulos. Por el hecho de tener una estructura modular, el OpenSER es capaz

de tener un núcleo reducido, rápido y estable. Los módulos de OpenSER permiten el uso de algunas

funciones dentro del archivo de configuración de OpenSER, openser.cfg. Este archivo de configuración

controla cuáles módulos serán cargados así como también su comportamiento según las variables

fijadas en cada uno.

Línea 1: OpenSER tiene información para la depuración de errores que puede ser habilitada o

suprimida usando la instrucción ‘debug’. El valor nominal “3”, es especificado usualmente para

obtener una gran cantidad de información cuando ocurren errores. La instrucción ‘debug’, especifica

cuánta información se escribirá en el syslog. Para números más altos, la información se hará más

- 160 -

extensa y detallada (siendo “9” el nivel más alto), ocasionando además, que el tiempo de inicio de

OpenSER sea mayor.

Línea 2: la instrucción ‘fork’ le indica al demonio OpenSER si puede o no bifurcarse, creando

así un proceso para cada interfaz de red. El valor inicial del mismo es “yes”.

Línea 3: este parámetro permite, al OpenSER, escribir logs o mensajes de chequeo en el

“Standard error”. Si el comando se encuentra negado: ‘log_stderror’=no, los mensajes son escritos

en el syslog.

Líneas 7 - 8: estas líneas tienen como función evitar que OpenSER realice operaciones de

búsqueda de su dirección IP en el DNS. Mediante la incorporación de estas dos líneas en el archivo

openser.cfg, se elimina cualquier advertencia si su IP no se encuentra en el Servidor DNS.

Línea 10: la función ‘listen’ le indica a OpenSER qué debe escuchar, ya sea una direccion IP,

dominio, una interfaz de red o una combinación de [protocolo]:[dirección]:[puerto]. Si se omite este

comando, OpenSER escuchará todas las interfaces.

Este parámetro puede soportar cambios en el archivo de configuración dándole distintos

dominios y/o puertos.

Línea 11: el comando ‘children’ le indica a OpenSER cuántos procesos se van a generar

cuando el servidor inicie. El valor por defecto es 8, el maximo valor que puede tomar es 32.

Línea 12: el comando ‘fifo’ especifica la localización del FIFO de OpenSER. El FIFO puede ser

usado si se desea agregar un nuevo mensaje SIP directamente en el Proxy SIP con una aplicación

externa. Un buen ejemplo de ello es serctl el cual usualmente se encuentra localizado en

/usr/local/sbin/. Con él se pueden manejar usuarios, hacer ping a URIs SIP, enviar correos a

usuarios SIP. Serctl hace todo esto internamente usando FIFO.

El FIFO se puede localizar en cualquier parte del disco, sin embargo OpenSER debe ser capaz

de crear el FIFO en el directorio especificado. Si este no se especifica, el servicio no iniciará.

Línea 13: el comando fifo_db_url es también incluido para suprimir las advertencias que si no,

aparecerían al incluir el soporte de mysql. No se usa fifo_db_url directamente en openser.cfg, sin

embargo, otras herramientas como openserctl lo usa para agregar usuarios en la base de datos.

- 161 -

Línea 22: sirve para especificar la ruta donde se encuentran los módulos, de esta forma al

agregar un módulo sólo es necesario escribir: loadmodule “modulo.so”. En caso contrario, se debe

especificar la ruta completa.

Línea 23: el soporte de mysql es añadido fácilmente incluyendo el módulo mysql.so en la

sección loadmodule. Un aspecto importante es que este módulo debe ser cargado antes que el resto.

Esto ya que mysql.so no presenta dependencias con ningún módulo, sin embargo, módulos como

uri_db si dependen de mysql.so

Líneas 24 – 30: Aquí se tienen módulos externos que son necesarios para el funcionamiento del

Proxy.

Si está imaginando cómo saber cuál módulo o módulos necesitará, en principio no hay forma

clara de saberlo. En general, los módulos mostrados aquí serán necesarios por cualquier configuración

Proxy. Cuando se necesita agregar funcionalidades adicionales, como conectividad Mysql, entonces

deberá cargar el módulo apropiado, en este caso el módulo mysql.so.

Algunos módulos presentan parámetros que necesitan ser activados en el archivo openser.cfg

para el funcionamiento adecuado del servicio. Otros módulos, sin embargo, operan normalmente en la

mayoría de los casos sin necesidad de hacer un ajuste de los parámetros.

Línea 45: el módulo USRLOC es responsable de no perder de vista las localizaciones del registro

del cliente SIP. En otras palabras, cuando un cliente SIP se registra con el Proxy SIP, OpenSER

almacenará la información del contacto en una tabla. Esta tabla es consultada cuando otro cliente SIP

hace una llamada. La localización de esta tabla depende del valor del parámetro db_mode.

0.- deshabilita la base de datos completamente. Solamente será usada la memoria. Los

contactos no sobreviven a un reinicio. Usar este valor si se necesita realmente un usrloc rápido y no

es necesaria la persistencia del contacto, o la misma es proporcionada por otros medios.

1.- Esquema Write-Through. Todos los cambios en el usrloc son reflejados inmediatamente en

la base de datos también. Esto resulta muy lento pero confiable. Se recomienda usar este esquema si

la velocidad no es prioridad pero se necesita estar seguro de que no se perderán los usuarios

registrados durante una falla o reinicio.

2.- Esquema Write-Back. Es una combinación de los dos esquemas previos. Todos los cambios

son realizados en la memoria y la sincronización de la base de datos es hecha en el contador de

tiempo. Este contador elimina a todos los contactos que han expirado y limpia todas las modificaciones

o nuevos contactos en la base de datos. Usar este esquema si se tienen picos de mucha carga y se

quieren procesar tan rápido como sea posible. Este modo no ayudará si la carga es alta en toda hora.

- 162 -

También, la latencia de este modo es mucho menor que la del modo “1”, pero levemente mayor que la

del modo “0”.

Línea 48: el módulo permissions necesita saber si se tiene que conectar con MySQL para

encontrar los datos.

Línea 50: los módulos: “auth_db”, “permissions”, “uri_db”, “usrloc”, “acc”, “msilo”, “grp”,

“domain”, lcr”, necesitan tener acceso a la base de datos MySQL, por ello se agrega a la lista del

parámetro db_url.

Línea 58: El parámetro llamado enable_full_lr es realmente para trabajar en base a clientes SIP

viejos que no manejan propiamente los encabezados del SIP record-route.

Línea 66: el parámetro log_level indica el nivel de detalle al cual son mostrados los mensajes en

el syslog.

Líneas 89 – 90: el envío de la llamada es dependiente del módulo avpops. Este módulo

necesita tener acceso a la base de datos de mysql para leer las preferencias de envío de llamada de un

suscriptor en la tabla usr_preferences. Por ello, aquí se especifica la base de datos mysql y la tabla

para las preferencias de envío de llamada.

Línea 99: indica el tamaño máximo del mensaje en el log.

Línea 100: es el comienzo de la lógica de procesamiento. Esta línea define el bloque de ruta

principal. Un bloque de ruta principal debe tener una llave de principio y final. (100 y 269

respectivamente).

El bloque de ruta principal es donde todos los mensajes SIP recibidos son enviados. Desde el

bloque de ruta principal puede llamar otros bloques de ruta, chequear mensajes para ciertas

condiciones, rechazar el mensaje, retransmitirlo, entre otras, de acuerdo a las necesidades que se

tengan.

Línea 103: mf_process_maxfwd_header es un chequeo de seguridad que siempre se debe

incluir como la primera línea del bloque de ruta principal. Esta función se expone en el módulo

maxforward.so y se utiliza para no perder de vista cuántas veces ha pasado el mensaje SIP a través de

OpenSER. Archivos erróneos de openser.cfg pueden enviar mensajes SIP a lugares equivocados y

- 163 -

causar condiciones de ciclos infinitos. También otros Proxy SIP con los que OpenSER interactúa hacen

lo mismo.

La regla básica es que si la función siempre retorna ‘true’, entonces es necesario dejar de

procesar el mensaje con problemas para evitar un lazo infinito.

Línea 104: la function log() imprime el mensaje especificado en el syslog. Sirve para la

depuración de errores.

Línea 105: si se detecta un ciclo infinito, OpenSER necesita tener una manera de informar al

cliente SIP que ha ocurrido un error. La función sl_send_reply() permite hacer esto. Dicha función

se encuentra presente en el módulo sl.so, y todo lo que hace es enviar un mensaje sin seguimiento de

estado al cliente SIP. Esto significa que envía el mensaje y se olvida del mismo. No tratará de

reenviarlo en caso de que no llegue al destinatario o no se tenga una respuesta.

Se puede especificar un mensaje de error apropiado como se muestra. El mensaje de error

puede solamente ser seleccionado de los códigos de error y mensajes SIP definidos. Muchos teléfonos

SIP lo mostrarán en forma del mensaje de texto al usuario.

Línea 106: la sentencia ‘exit’ le indica a OpenSER que debe detener el procesamiento del

mensaje SIP y salir del bloque de ruta que está ejecutando en ese instante. Puesto que se está

llamando a la sentencia ‘exit’ en el bloque de ruta principal, OpenSER detendrá completamente el

procesamiento del mensaje actual.

Línea 108: msg:len es una función del núcleo de OpenSER que retorna la longitud en bytes del

mensaje SIP actual. Entonces, como la función mf_process_maxfwd_header() debe ser llamada al

comienzo del bloque de ruta principal en todos los archivos de configuración openser.cfg.

Esta sentencia simplemente chequea que la longitud del mensaje SIP no sea mayor que el

máximo permitido. Si el mensaje SIP es muy largo, entonces se detendrá el proceso ya que se habrá

detectado un potencial desbordamiento del buffer.

Línea 110: OpenSER necesita tener una manera de informar al cliente SIP que ha ocurrido un

error. La función sl_send_reply() permite hacer esto. Dicha función se encuentra presente en el

módulo sl.so, y todo lo que hace es enviar un mensaje sin seguimiento de estado al cliente SIP. Esto

significa que envía el mensaje y se olvida del mismo. No tratará de reenviarlo en caso de que no llegue

al destinatario o no se tenga una respuesta.

- 164 -

Se puede especificar un mensaje de error apropiado como se muestra. El mensaje de error

puede solamente ser seleccionado de los códigos de error y mensajes SIP definidos. Muchos teléfonos

SIP lo mostrarán en forma del mensaje de texto al usuario.

Línea 111: ver línea 106.




Línea 125: cuando se recibe un mensaje BYE o CANCEL, se debe asumir que es para una

llamada que se ha establecido con un mediaproxy. Inmediatamente se debe procurar terminar la

sesión del RTP Proxy. Es perfectamente seguro llamar a la función end_media_session(), incluso

para llamadas que no provengan de un Proxy RTP.

Línea 126: le indica al mediaproxy que debe terminar la sesión de la llamada actual.

Línea 130: en esta línea se chequea si el mensaje recibido es un mensaje REGISTER, en caso

de no serlo, esta parte de la rutina es obviada. La palabra ‘method’ es proporcionada por el núcleo de

openser y permite encontrar qué tipo de mensaje SIP se está manejando.

Línea 131: la función www_authorize() es usada para chequear las credenciales del usuario

contra los valores almacenados en la tabla “subscriber” de mysql. Si las credenciales proveídas son

correctas, la función retorna “true”, en caso contrario retorna “false”.

El primer parámetro especifica el dominio en el cual autentificar el usuario. El segundo valor le

dice a OpenSER cuál tabla de mysql debe usar para encontrar las credenciales de la cuenta del

usuario.

Línea 133: aquí realmente se envía un mensaje “401 unauthorized” al cliente SIP para que

éste retransmita la petición con las credenciales digest incluidas.

La function www_challenge() toma dos argumentos. El primero es el dominio, el cual

también aparecerá en el encabezado www-Authorize que OpenSER le envía al cliente SIP. Si se coloca

un valor aquí, entonces el dominio le aparecerá al cliente SIP cuando se retransmite la petición de las

credenciales.

El segundo valor afecta la inclusión del parámetro gop en la petición de las credenciales. Es

recomendable colocar este valor en “1”. Para una completa descripción de la autentificación digest,

- 165 -

referirse al RFC2617. es importante destacar que algunos teléfonos IP no soportan la autentificación

gop.

Línea 135: al enviar el mensaje de error 401 en la línea previa, no es necesario mantener este

mensaje de registro. Luego, se usa el comando ‘exit’ para retornar al bloque de ruta principal.

Línea 137: cuando se opera un proxy SIP, se debe estar seguro de que cuentas de usuario

válidas, que fueron registradas satisfactoriamente, no pueden ser usadas por usuarios no

autentificados. Debido a ello, OpenSER incluye la función check_to().

Se llama a la función check_to() antes de validar el mensaje de registro.

Esto hace que OpenSER valide el campo “To:” contra las credenciales previamente validadas. Si

no coinciden, debe rechazarse el mensaje REGISTER y enviar un mensaje de error.

Línea 138 - 139: si la función check_to() retorna “false”, debe enviarse un mensaje “401

Unauthorized” al cliente SIP. Luego se llama al comando “exit” para retornar al bloque de ruta

principal.

Línea 142: la función save() es responsable de almacenar la información de registro del cliente

SIP en la tabla “location”.

Línea 147: reenvía el mensaje al destino.

Línea 150: la función loose_route() prueba para ver si el mensaje SIP debe ser enrutado

libremente o no. Si el mensaje debe ser enrutado libremente, entonces OpenSER simplemente debe

reenviar el mensaje al siguiente destino especificado en el encabezado Record-Route.

En todos los archivos openser.cfg se debe llamar a la función loose_route() después de la

función record_route(). Referirse a RFC3261 para una explicación completa de loose_route().

Línea 152: si la prueba de enrutamiento libre retorna ‘true’, entonces se deberá reenviar el

mensaje sin otro procesamiento. Para hacer esto, se pasa el control del bloque en ejecución al bloque

de ruta[1].


Línea 262: lookup(“location”) trata de encontrar dónde se encuentra localizada físicamente la

persona a la que se está llamando.

- 166 -

Línea 264: si la parte que está siendo llamada no puede ser localizada, entonces OpenSER

reenviará un mensaje de error: “404 User Not Found”.

Línea 272: si la función t_relay() en la línea 281 no envía el mensaje SIP, entonces

sl_reply_error() enviará el error al cliente SIP para informar que ha ocurrido un error en él.

Línea 277: la función t_on_failure() informa a OpenSER que se quiere tener un manejo

especial de la llamada cuando ocurren condiciones de falla. En este contexto, se refieren condiciones

de falla a códigos de respuesta de tipo: 4xx, 5xx.

Línea 281: La función rewritehost() es usada para modificar el R-URI de modo que el

mensaje sea retransmitido al gateway de la PSTN. Se debe pasar la dirección IP del gateway de la

PSTN a esta función. De dicha forma, OpenSER enviará el mensaje INVITE al gateway de la PSTN

correctamente cuando se llama a la función t_relay().

Línea 293: la función rewriteuri() sobrescribe el URI actual.

Línea 282: necesario para enrutar la llamada hacia el dominio especificado.














12. Apéndice 3: Características del hardware.

Para identificar las características de hardware del servidor fue necesario trabajar con el DSA

“Dynamic System Analysis”. El mismo se encarga de colectar y analizar la información del sistema, con

- 167 -

la finalidad de diagnosticar problemas en él. Es soportado tanto en los ambientes Microsoft®

Windows® y Linux®.

DSA colecta información referente a:

• Configuración del sistema.

• Aplicaciones instaladas.

• Interfaces de red y configuración.

• Dispositivos de arranque y servicios de sistema.

• Datos del funcionamiento y detalles de los procesos que están corriendo.

• Inventario del hardware, incluyendo la información PCI.

• Configuración ServeRAID.

• Aplicación, sistema, seguridad, ServeRAID y registros (logs) de los acontecimientos del

sistema.

Para la instalación de DSA deben seguirse los siguientes pasos:

• Descargar de la web el paquete: ibm_utl_dsa_131i_rhel3_i386.rpm, y guardarlo

en la ruta: /etc.

• Desde la ruta donde se encuentra el paquete, ejecutar el comando:

rpm -ivh ibm_utl_dsa_131i_rhel3_i386.rpm

• Verificar que en la ruta /usr/bin se tiene instalada la librería libstdc++.so.5. En

caso de no ser así, se deberá descargar, para ello ejecutar el comando:

yum install libstdc++.so.5

• Al instalar el paquete DSA, se creará la ruta /opt/IBM/DSA. Deberá dirigirse a la

misma y ejecutar el comando:

./collectall –v –c –d /tmp/hardware

• Luego de esto, la información del sistema será almacenada en la ruta

/tmp/hardware. Se podrá especificar la ruta deseada.

• Dirigirse vía ftp a la ruta que se especificó en la parte anterior (/tmp/hardware), en

ella encontrará una carpeta que contiene las páginas donde está toda la información de

sistema. Se deberá guardar en la PC la carpeta que se encuentra descomprimida.

• En la carpeta descargada encontrará un archivo llamado index.html. En dicho

navegador encontrará toda la información referente a la información del sistema.

- 168 -

Al acceder a la página se mostrará en el navegador web

Página principal que contiene las características del sistema

Se muestra la página principal que contiene las características del sistema. Así mismo, del lado

derecho se encuentran links que redireccionan al resto de la información colectada por el DSA.

13. Apéndice 4: Creación de nuevos usuarios en Linux.

Para la creación de nuevos usuarios en Linux es necesario usar el comando useradd. La

sintaxis que debe seguirse se muestra a continuación.

1. Para añadir el usuario al sistema debe ejecutarse el comando:

useradd nombre_del_usuario

2. Posteriormente debe escribirse un password para el usuario ejecutando el comando:

passwd nombre_del_usuario

Y repetirlo a fin de evitar errores. Por motivos de seguridad no se verá el password que se

está escribiendo. Se puede además cambiar el password del usuario, usando el comando

- 169 -

passwd. Si está conectado como usuario root puede cambiarse el password de cualquier

usuario.

3. Luego es necesario cambiar los permisos de los archivos que se desea que el usuario tenga

control.

El usuario creado tiene como inconveniente que no posee el conjunto de permisos requeridos

para poder detener e iniciar servicios de los cuales es necesario tener el control cuando se

trabaja con la aplicación de OpenSER.

Es por ello que se hace necesario recurrir a la opción de SUDO, mejor conocida como Super

Usuario. SUDO “Superuser DO” es una herramienta que permite otorgar a un usuario o grupo

de usuarios normales, permisos para ejecutar algunos comandos como si fuese el usuario

root18 (o como otros usuarios) sin necesidad de conocer su password.

13.1. Configuración del Super Usuario

Para configurar sudo será necesario seguir una serie de pasos:

1. Ejecutar el comando visudo.

2. Como se muestra en la figura, en archivo será necesario agregar la siguiente línea:

nombre_del_usuario ALL=/etc/init.d

Para efectuar este cambio será necesario que se esté iniciado como usuario root.

3. Luego de modificar el archivo de configuración, el usuario estará en la capacidad de reiniciar

los servicios, para ello debe dirigirse a la siguiente ubicación:

cd /etc/init.d

En este directorio se encuentran todos los “scripts” que facilitan el inicio y cierre de los

demonios (programas). Estos “scripts” normalmente toman argumentos del tipo: “stop”, “start”,

“status”, “restart”.

Entre estos demonios pueden mencionarse:

• Vsftpd

• Httpd

• Openser

• Mysq

18 Usuario que posee acceso completo al sistema.

Línea a agregar

- 170 -

ANEXO 2. Manual SERWeb Administrador

1. Introducción

El siguiente manual tiene como finalidad facilitarle al administrador el manejo de la aplicación web

de OpenSER. En el mismo se explica el funcionamiento de cada una de las partes que la conforman,

siguiendo un esquema más o menos similar al que puede encontrarse en el modo de trabajo habitual.

La aplicación aquí descrita se encuentra escrita enteramente en lenguaje PHP y trabaja con cualquier

browser moderno.

Para poder acceder a la aplicación, deberá ingresar a través de la página web de “Login” por

medio del par usuario/contraseña.

2. Entrada a la Aplicación

Al entrar a la página el administrador debe introducir su nombre de usuario y contraseña, si estos

son válidos, se observará una página como la mostrada en la Figura 1:

Figura 1: Página de Inicio

- 171 -

En ella, se presentan dos opciones:

• Modificar archivo de configuración de OpenSER

• Modificar tablas de prefijos

2.1. Modificación del Archivo de Configuración de OpenSER

Si se desea eliminar parte del archivo de configuración, o editarlo, será necesario que el

administrador lo realice directamente en la consola.

Si tiene dudas de cómo acceder al archivo de configuración de OpenSER desde la consola, ver

detalles en el manual de OpenSER que se encuentra en el Anexo1 de este libro.

En caso de que se deseen agregar nuevas reglas de enrutamiento, parámetros de configuración

de OpenSER, cargar otros módulos, u otra ruta, esto puede hacerse a través del servidor web, el cual

se encargará de insertar el código en el lugar apropiado.

Para modificar el archivo de configuración de OpenSER desde serweb, se debe escoger la opción

“Modificar el Archivo de Configuración” de la lista desplegable mostrada en la Figura 1. Al hacer esto,

se dirigirá a una página como la que se muestra en la Figura 2.

Figura 2: Modificación del archivo de configuración

Archivo de configuración de openser

Manual

de ayuda

Agregar código en el

archivo de configuración

- 172 -

En esta página, se tienen tres opciones:

1.- Manual de Ayuda.

2.- Agregar código en el archivo de configuración.

3.- Ver archivo de configuración de OpenSER.

2.1.1. Manual de Ayuda

Le permite al administrador de una manera rápida, recordar la sintaxis básica para modificar el

valor de un parámetro, insertar un módulo, o insertar una nueva ruta.

2.1.2. Ver archivo de configuración de OpenSER

El link ver código le permite al administrador abrir en un documento de texto el archivo de

configuración de OpenSER, de esta forma se puede ver fácilmente qué parámetros se encuentran

inicializados, cuáles son los módulos que están cargados, las reglas de enrutamiento, etc.

2.1.3. Agregar código

Agregar código en la página web consiste de un cuadro de texto y una lista desplegable. El

archivo de configuración puede estructurarse básicamente en cuatro partes:

• Módulos

• Parámetros

• Reglas de Enrutamiento

• Rutas

Para agregar código en el archivo de configuración, se elige en la lista desplegable la opción

deseada, y en el cuadro de texto se escribe el código, luego se pulsa el botón enviar. En este

momento, los cambios se habrán realizado en su archivo de configuración de OpenSER.

NOTA: Es importante destacar que esto debe realizarse con pleno cuidado y seguridad ya que si

se incluye el código en un lugar errado (esto se refiere a elegir una opción equivocada en la lista

desplegable) muy probablemente OpenSER fallará o no se ejecutará correctamente.

Uso:

Esta herramienta permite realizar cambios tanto internos como externos a OpenSER. Se dice que

un cambio es interno a OpenSER, cuando las modificaciones se realizan directamente en el archivo de

configuración de OpenSER (openser.cfg), lo cual implica que es necesario reiniciar el servicio de

OpenSER para que los cambios efectuados sean tomados en cuenta.

Por otro lado, se dice que un cambio es externo a OpenSER cuando éste no se realiza en el

archivo de configuración, sino por ejemplo en la base de datos de OpenSER. Cuando esto ocurre no es

- 173 -

necesario reiniciar el servicio de OpenSER ya que no han ocurrido cambios dentro del archivo de

configuración.

Como desarrollador, la idea consiste en ofrecer la posibilidad de modificar vía Web los dominios

para el enrutamiento de las llamadas a través de OpenSER, sin necesidad de tener que acceder a la

base de datos.

Una vez ingresado al portal, se encontrará una página como la que se muestra a continuación:

2.2. Modificar tablas de Prefijos

Figura 3: Página Principal de Enrutamiento

El administrador debe elegir alguna de las opciones de la lista desplegable, en función de los

parámetros que desee modificar para el enrutamiento de las llamadas telefónicas.

Enrutamiento por URI: permite dirigir las llamadas hacia uno u otro dominio según el número

destinatario, en función de las reglas asignadas en el archivo de configuración openser.cfg.

- 174 -

Por ejemplo, podría asignarse un dominio para las llamadas realizadas a dispositivos móviles,

otro dominio para las llamadas realizadas hacia números nacionales, y otro para las llamadas

internacionales. El criterio a usar dependerá de las necesidades que se tengan.

Si se escoge de la lista desplegable la opción “Enrutamiento por URI”, se mostrará la tabla de

los prefijos existentes con sus correspondientes dominios. Adicionalmente, se presentan como links las

opciones EDITAR, AGREGAR y VOLVER AL INICIO.

Figura 4: Enrutamiento por URI

• Editar: al hacer click en esta opción, se observará una página similar a la mostrada en

la Figura 5:

- 175 -

Figura 5: Editar Prefijo en el Enrutamiento por el campo URI

Editar un prefijo, consiste en cambiar el dominio actual de un prefijo existente dado, por uno

nuevo. Es necesario que el prefijo que se desea editar se encuentre dentro de la tabla de prefijos, en

caso contrario se mostrará un mensaje de error.

• Agregar: si se elige esta opción, se observará una pantalla como la que se muestra:

- 176 -

Figura 6: Agregar un Prefijo en el Enrutamiento por URI

Muy parecida a la de opción editar, en este caso se debe introducir un nuevo prefijo con su

correspondiente dominio. Resulta importante señalar que no se puede agregar un prefijo si éste ya

existe en la tabla ya que un mismo prefijo no puede tener dos dominios diferentes, en dicho caso el

dominio no será agregado, y se mostrará un mensaje de error.

• Volver al inicio: como su nombre lo indica, nos permite regresar a la página principal.

Enrutamiento por From: permite enrutar las llamadas hacia uno otro dominio en función del

usuario que inició la llamada. Esto, de acuerdo a las reglas de enrutamiento establecidas en el archivo

de configuración de OpenSER.

Por ejemplo, podría asignarse un dominio en específico a las llamadas realizadas por teléfonos

con un determinado código de área.

- 177 -

Figura 7: Enrutamiento por el campo From

En la página principal de enrutamiento por el campo “From”, se muestra una tabla con los

prefijos y sus correspondientes dominios. Además se presentan tres links con opciones de EDITAR,

AGREGAR y VOLVER AL INICIO.

• Editar: permite modificar el dominio de un prefijo existente en la tabla. Si se hace clic

en esta opción, observará una pantalla como la siguiente:

- 178 -

Figura 8: Editar Prefijo en el enrutamiento por From

Se deberá colocar el prefijo a editar, y el nuevo dominio al cual se enrutarán las llamadas que

presenten dicho prefijo numérico.

En caso de que el prefijo no se encuentre en la tabla, se mostrará un mensaje de error.

• Agregar: permite agregar un nuevo prefijo para el enrutamiento por el campo From,

con su correspondiente dominio a la tabla prefix2domain.

- 179 -

Figura 9: Agregar Prefijo en el enrutamiento por From


Enrutamiento por To: muy similar al enrutamiento por “URI”, las reglas de enrutamiento se

hacen en función del parámetro “To” del mensaje INVITE.

- 180 -

Figura 10: Enrutamiento por el campo To

Similar a las tablas correspondientes a los enrutamientos anteriores, se muestra una tabla con

los prefijos y sus respectivos dominios para el enrutamiento en función del campo “To” del INVITE.

También se presentan los links para EDITAR y AGREGAR prefijos en la tabla, así como para VOLVER

AL INICIO.

• Editar: si se desea modificar el dominio de un prefijo existente en la tabla de

enrutamiento en función del campo “To”.

- 181 -

Figura 11: Editar Prefijo en el enrutamiento por To

• Agregar: permite añadir un nuevo prefijo, con su correspondiente dominio, al

enrutamiento en función del campo “To”. En caso de que el prefijo que de desee “agregar” ya

se encuentre en la tabla, se mostrará un mensaje de error.

- 182 -

Figura 12: Agregar Prefijo en el enrutamiento por To


Enrutamiento por Hora: permite dirigir las llamadas, en un determinado rango de hora hacia un

dominio en específico, en función de las necesidades que se tengan. Con esta opción, al igual que en

los casos anteriores, se mostrará una tabla que contiene los prefijos y sus dominios para este tipo de

enrutamiento.

- 183 -

Figura 13: Enrutamiento por el campo Hora

• Editar: esta opción sirve para modificar el dominio y/o el rango de horas entre las

cuales estará activo el enrutamiento de las llamadas de un prefijo ya existente en la tabla.

- 184 -

Figura 14: Editar Prefijo en el enrutamiento por Hora

• Agregar: permite añadir un nuevo prefijo para realizar enrutamientos de llamadas en

función de la hora.

- 185 -

Figura 15: Agregar Prefijo en el enrutamiento por Hora

Enrutamiento por Repartición de Carga: permite enrutar las llamadas en función del último

dígito del número llamado. Esto puede justificarse ya que por ejemplo, hay servidores que en horas

pico no tienen la capacidad para manejar completamente el tráfico sino que es necesario repartir el

mismo hacia dos o más dominios.

- 186 -

Figura 16: Enrutamiento por Compartición de Carga

• Editar: esta opción sirve para modificar un prefijo existente, o cambiar el dominio

hacia el cual se enrutarán las llamadas.

- 187 -

Figura 17: Editar Prefijo en el Enrutamiento por Compartición de Carga

• Agregar: esta opción, al igual que como se explicó en los enrutamientos anteriores,

permite agregar nuevos prefijos para realizar enrutamientos mediante repartición de carga.

- 188 -

Figura 18: Agregar Prefijo en el Enrutamiento por Compartición de Carga

• volver al inicio: permite regresar a la página principal de enrutamiento.

- 189 -

3. Mantenimiento y modificaciones en la página web

La página web de la aplicación se encuentra montada en el servidor con IP 161.196.58.48 en la

ruta /var/www/html. La misma se encuentra formada por los archivos que se listan a continuación

• Agregar_openser.php

• Agregar_prefijo_carga.php

• Agregar_prefijo_carga_html.php

• Agregar_prefijo_from.php

• Agregar_prefijo_from_html.php

• Agregar_prefijo_hora.php

• Agregar_prefijo_hora_html.php

• Agregar_prefijo_to.php

• Agregar_prefijo_to_html.php

• Agregar_prefijo_uri.php

• Agregar_prefijo_uri_html.php

• Editar_prefijo_carga.php

• Editar_prefijo_carga_html.php

• Editar_prefijo_from.php

• Editar_prefijo_from_html.php

• Editar_prefijo_hora.php

• Editar_prefijo_hora_html.php

• Editar_prefijo_to.php

• Editar_prefijo_to_html.php

• Editar_prefijo_uri.php

• Editar_prefijo_uri_html.php

• Enrutamiento_ppal.php

• Frames.php

• Indice.html

• Modificar_openser.php

• Mostrar_prefijos_CARGA.php

• Mostrar_prefijos_FROM.php

• Mostrar_prefijos_HORA.php

• Mostrar_prefijos_TO.php

• Mostrar_prefijos_URI.php

• Pagina_inicio.php

• LoginSW.php

• ProblemconnSW.php

• UserhandlerSW.php

• ValidateSW.php

Si se desea colocar la página web en un servidor con una dirección IP diferente, en principio

será necesario modificar en los archivos que se indican a continuación la correspondiente dirección IP

para lograr el establecimiento de la conexión con la base de datos:

ProblemconnSW.php Mediante este archivo se establece la conexión con la base de datos. En él se especifica el host,

la base de datos, el usuario su correspondiente contraseña.

LoginSW.php Este archivo consiste en un formulario en el cual se recoge el nombre de usuario y contraseña,

las cuales son posteriormente pasadas a otro archivo php que se encargará de realizar la validación y

por ende, permitir o denegar el acceso a la aplicación web.

- 190 -

ValidateSW.php

Se encarga de corroborar los datos introducidos por el usuario. En caso de que el ingreso sea

exitoso, se le permite el acceso al usuario a la página principal.

Por motivos de seguridad, se utilizan las cookies. Una cookie es una porción de información que

se guarda en el navegador permitiendo identificar el mismo por cierto intervalo de tiempo, estando la

información disponible entre varias páginas del mismo sitio.

La asignación de la cookie se hace desde la función setcookie(). Esta función envía una cookie,

pero lo hace junto a la cabecera de la página, por esto es muy importante enviar las cookies antes de

mandar a imprimir cualquier cosa en la página, es decir si hay que enviar una cookie, para que no

genere error de cabeceras hay que enviarla antes de enviar cualquier “echo” u otro tipo de salida.

Userhandler.php Mediante el archivo validateSW.php, el usuario ya tiene las cookies en su sistema. Sin embargo,

es necesario comprobar en las páginas que se desee, si el login es correcto, que el usuario además

posee las cookies y que éstas son válidas. Para ello se crea este archivo, el cual se encarga de leer las

cookies y decir si es un usuario registrado y que ha hecho el respectivo ingreso al sistema.

Pagina_inicio.php

Es la página principal de la aplicación web. En ella el administrador puede elegir que actividad

desea llevar a cabo.

Modificar Archivo de configuración

Cambiar prefijos de enrutamiento

Frames.php

Como su nombre lo indica, consiste en una división de la pantalla del navegador en dos cuadros

que muestran contenidos de indice.html y modificar_openser.php

Modificar_openser.php

Mediante este archivo se hace básicamente una lectura al archivo de configuración de openser,

guardándolo en un archivo de extensión .txt para su posterior uso.

Además, aquí se genera la lista desplegable con las diferentes opciones de código a insertar en

el archivo de configuración de OpenSER.

Agregar_openser.php

Se encarga de crear los puntos de inserción para los módulos, parámetros, rutas y cada regla de

enrutamiento con el fin de lograr incluir de forma exitosa el código en el archivo de configuración de

openser.

- 191 -

Un punto de inserción es una clase de identificador o marca de una línea específica de un

código. De esta forma, los puntos de inserción pueden por ejemplo ser reemplazados por cierto

código.

A continuación se muestran los puntos de inserción para cada una de las opciones existentes:

Opciones:

Insertar módulo: #INSERTE MODULO NUEVO AQUI

Insertar parámetro: #INSERTE PARAMETRO NUEVO AQUI

Insertar Regla de Enrutamiento por Uri: #INSERTE REGLA DE ENRUTAMIENTO POR URI AQUI

Insertar Regla de Enrutamiento por From: #INSERTE REGLA DE ENRUTAMIENTO POR FROM AQUI

Insertar Regla de Enrutamiento por To: #INSERTE REGLA DE ENRUTAMIENTO POR TO AQUI

Insertar Regla de Enrutamiento por Hora: #INSERTE REGLA DE ENRUTAMIENTO POR HORA AQUI

Insertar Regla de Enrutamiento por Repartición de Carga: #INSERTE REGLA DE ENRUTAMIENTO

POR CARGA AQUI

Insertar Ruta: #INSERTE RUTA AQUI

Básicamente se define de acuerdo a la opción escogida, el punto de inserción correspondiente, y

posteriormente se hace una concatenación del mismo con el código enviado por el administrador vía

Web.

Esto con la finalidad de que el punto de inserción sea reemplazado por el código + el punto de

inserción. De esta forma el punto de inserción siempre estará presente.

Al irrumpir los computadores en el mundo el gran problema estaba era en el espacio de

almacenamiento, era necesario maximizarlo lo más que se pudiera, fue por ello que la gente de Unix

decidió utilizar dos caracteres para el fin de línea.

La consecuencia de esta estandarización es que cada vez que se trabaja con un archivo que fue

creado en otro sistema operativo (que no sea Windows) se producen problemas con el fin de línea.

Además resulta importante señalar que es necesario hacer un manejo del retorno del carro.

Para poder agregar código en el archivo de configuración, es necesario hacer una lectura del

archivo de configuración de openser (openser.cfg), realizar las respectivas modificaciones desde la

página web, y posteriormente pulsar el botón Enviar, con lo que los cambios se habrán llevado a cabo.

Sin embargo, cuando se hace eso, aparece al final de cada línea (de la codificación que se agregó vía

web) el caracter ^M:

Figura 19: Retorno del carro

- 192 -

Es por ello que se procede a guardar el archivo de configuración modificado en un nuevo

archivo y luego se ejecuta el comando:

System(“tr -d '\015' < input_file > output_file”)

Enrutamiento_ppal.php

Como su nombre lo indica, es la página principal de enrutamiento.

En ella se muestran a través de una lista desplegable las diferentes opciones de enrutamiento

que se tienen establecidas. Por lo tanto, si se desea agregar una nueva funcionalidad a la página web,

muy probablemente deba añadirse a la lista desplegable donde se encuentran el resto de las opciones.

Figura 20: Lista desplegable de los tipos de enrutamiento

Agregar_prefijo_Xphp Esta explicación aplica para todos los tipos de enrutamiento (URI, FROM, TO, hora, Repartición

de Carga) es por ello que se ha puesto la letra x como un genérico a todos los tipos de enrutamiento.

Como su nombre lo indica, este programa establece una conexión en la base de datos e inserta

en la tabla “prefix_domain” el prefijo con su correspondiente dominio, así como el tipo de

enrutamiento al cual pertenece el mismo.

Agregar_prefijo_x_html.php

Esta explicación aplica para todos los tipos de enrutamiento (URI, FROM, TO, hora, Repartición


Muestra una caja de texto (ver Figuras 6, 9, 12, 15, y 18) en ellas el administrador deberá

introducir el prefijo a añadir con su correspondiente dominio. Los datos recopilados en este formulario

se entregan a su correspondiente archivo Agregar_prefijo_x.php.

Agregar_prefijo_URI_html.php → Agregar_prefijo_URI.php

Acá deberá agregarse la nueva opción

- 193 -

Agregar_prefijo_FROM_html.php → Agregar_prefijo_FROM.php

Agregar_prefijo_TO_html.php → Agregar_prefijo_TO.php

Agregar_prefijo_hora_html.php → Agregar_prefijo_hora.php

Agregar_prefijo_carga_html.php → Agregar_prefijo_carga.php

Editar_prefijo_x.php

Por su parte, y como su nombre lo indica, este programa se encarga de editar o modificar el

dominio para un prefijo en específico, esto lo hace estableciendo una conexión con la base de datos y

editando en la tabla “prefix_domain” el dominio para el prefijo insertado por el administrador vía

web .

Editar_prefijo_x_html.php

De forma similar a Agregar_prefijo_x_html.php, establece una caja de texto (Ver Figuras 5, 8,

11, 14, 17), en ellas el administrador introduce el prefijo y el nuevo dominio al cual se enrutarán las

llamadas cuando se reciban llamadas con dicho prefijo numérico.

Los datos recopilados en este formulario se entregan a su correspondiente archivo

Editar_prefijo_x.php.

Editar_prefijo_URI_html.php → Editar_prefijo_URI.php

Editar_prefijo_FROM_html.php → Editar_prefijo_FROM.php

Editar_prefijo_TO_html.php → Editar_prefijo_TO.php

Editar_prefijo_hora_html.php → Editar_prefijo_hora.php

Editar_prefijo_carga_html.php → Editar_prefijo_carga.php

Índice.html Contiene links a documentos que sirven de ayuda al administrador web.

En caso de que se desee agregar nueva información a la página, será necesario incluir la misma

en la ruta /var/www/html al igual que todos los archivos que conforman la página web.

Figura 21: Índice de links

- 194 -

Para agregar un nuevo link siguiendo el esquema desarrollado hasta ahora, será necesario

agregar una línea de código como la mostrada a continuación. En ella debe especificarse el archivo así

como el link con el cual se desea aparezca en la página web.

<tr><td height=”27”><a ref. “nombre_del_archivo” target=“_blank”><p align=“center” class= “style2 style5”>

Nombre_del_link </p></td></tr>

Mostrar_prefijos_x.php Esta explicación aplica para todos los tipos de enrutamiento (URI, FROM, TO, hora, Repartición


Este archivo hace una conexión con la base de datos de openser, y recupera de la misma todos

los prefijos con sus correspondientes dominios para el tipo de enrutamiento seleccionado y luego los

muestra en forma tabulada. Los datos recopilados se entregan a su correspondiente archivo

Mostrar_prefijos_x_html.php con el fin de hacer una tabla dinámica en la que se muestren los prefijos.

Mostrar_prefijo_URI_html.php → Mostrar_prefijo_URI.php

Mostrar_prefijo_FROM_html.php → Mostrar_prefijo_FROM.php

Mostrar_prefijo_TO_html.php → Mostrar_prefijo_TO.php

Mostrar_prefijo_hora_html.php → Mostrar_prefijo_hora.php

Mostrar_prefijo_carga_html.php → Mostrar_prefijo_carga.php

Además en ella se encuentran los links hacia las otras páginas que ofrecen el resto de

funcionalidades en lo que respecta al manejo de los prefijos para los enrutamientos.

Al igual que en la página explicada anteriormente, si se desea agregar una nueva funcionalidad

referente al manejo de los prefijos debe seguirse la misma sintaxis.

Mostrar_prefijos_x_html.php Es la interfaz donde se le muestra al administrador, para cada enrutamiento, una tabla con los

prefijos y su correspondiente dominio, así como los links hacia las páginas que permiten bien sea

agregar o modificar un prefijo para esa clase de enrutamiento.

4. FAQ

1. ¿Por qué no puedo agregar un prefijo si éste no se encuentra en la tabla?

Esto se debe a que el prefijo que se intenta agregar ya esta siendo usado en alguno de los otros

tipos de enrutamiento. Verifique si esto es asi, y elja un prefijo que no esté siendo usado en ningún

otro enrutamiento.

2. ¿Por qué no puedo acceder al ftp con mi usuario root?

- 195 -

Probablemente este problema se debe a que cuando se realizó el proceso de instalación del

programa se obvió eliminar el usuario root de la lista de usuarios que no tienen permitido el acceso a

ftp.

Para esto, diríjase a la ruta /etc/vsftpd con el siguiente comando:

cd /etc/vsftpd

Edite el archivo user_list: vi user_list

Allí saldrá una lista de usuarios, elimine de ella el usuario con el cual está accediendo al ftp,

guarde los cambios: esc : wq! Y posteriormente proceda a reiniciar el servicio ftp para que sus

cambios tomen efecto. Para ello ejecute la instrucción: service ./vsftpd restart

3. ¿Por qué no tengo acceso a mi base de datos?

Si se tiene un error como el que se muestra a continuación:

Error:

PHP Fatal error: Call to undefined function mysql_connect() in /var/www/html/..

Este error se debe a que al momento de la instalación se olvidó instalar el conector entre la base de datos y mysql. Para esto, ejecute el siguiente comando en la consola:

yum install php-mysql

4. ¿Por qué no puedo acceder a la página web?

El problema puede deberse a que reinició el servidor, y no el servicio httpd.

Para esto ejecute el siguiente comando: service ./httpd restart

5. ¿por qué se deben colocar los archivos en la ruta /var/www/html?

Esto ya que es el DocumentRoot predeterminado, que es el directorio raíz del servidor Web que

contiene la mayoría de los ficheros HTML que se entregarán en respuesta a peticiones.

Por ejemplo, el servidor puede recibir una petición para el siguiente documento:

http://dominio/index.html

El servidor buscará el fichero en el siguiente directorio por defecto:

/var/www/html/foo.html

6. ¿Qué debo modificar si se coloca la página web en un servidor con una dirección IP distinta a

la 161.196.58.48?

Todos los archivos que se listan a continuación presentan en al menos una línea de código un

redireccionamiento a otra página web, es por ello que será necesario sustituir la dirección en caso de

que la aplicación web se monte en un servidor con dirección IP distinta.

- 196 -

Por ejemplo: supongamos que ahora la dirección IP del servidor en que se va a montar la

aplicación web es: 161.158.70.54

Para un archivo en el cual aparezca un redireccionamiento como el mostrado:

<meta http-equiv="refresh" content="4; URL=http://161.196.58.48/editar_prefijo_carga.php">

Será necesario sustituir la URL por la nueva dirección:

<meta http-equiv="refresh" content="4; URL=http://161.158.70.54/editar_prefijo_carga.php">

A continuación se lista un grupo de archivos que conforman la aplicación web. En los mismos se

deberán modificar las correspondientes URL en función de la nueva dirección IP que se tenga.

• agregar_prefijo_carga.php

• agregar_prefijo_from.php

• agregar_prefijo_hora.php

• agregar_prefijo_to.php

• agregar_prefijo_uri.php

• agregar_prefijo_.php

• decisión_inicio.php

• editar_prefijo_carga.php

• editar_prefijo_from.php

• editar_prefijo_hora.php

• editar_prefijo_to.php

• editar_prefijo_uri.php

• modificar_openser.php

• mostrar_prefijos_carga.php

• mostrar_prefijos_from.php

• mostrar_prefijos_hora.php

• mostrar_prefijos_to.php

• mostrar_prefijos_uri.php

• toma_decisión.php

7. ¿Qué se debe hacer si se desea cambiar el nombre de alguno de los archivos que conforman la

aplicación web?

Como se sabe, una aplicación web típicamente está formada por un conjunto de archivos que se

llaman unos a otros en función de la estructura de programación que se haya realizado. Debido a esto,

internamente en la programación, es usual que un

En la figura anterior se muestra un ejemplo de ello. Si el archivo agregar_prefijo_carga.php cambia de

nombre y éste no se modifica en el archivo agregar_prefijo_carga_html.php se tendrá error y las

modificaciones no se llevarán a cabo en la base de datos.

El archivo agregar_prefijo_carga_html.php hace uso de agregar_prefijo_carga.php

- 198 -

Es por ello que resulta necesario siempre q se cambie el nombre de alguno de los archivos, realizar los

cambios correspondientes en el resto.

ANEXO 3. Trazas de una llamada desde un teléfono IP hacia un teléfono en la PSTN

conlgando éste.

interface: eth0 (161.196.58.0/255.255.255.0) filter: (ip) and ( port 5060 ) # U 161.196.168.122:9375 -> 161.196.58.48:5060

INVITE sip:[email protected] SIP/2.0..To: <sip:[email protected]>..From: 1112<sip:[email protected]>;ta g=7b3f434c..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-555568460-1--d87543-;rport..Call-ID: 2e71af224e7 24d51..CSeq: 1 INVITE..Contact: <sip:[email protected]:9375>..Max-Forwards: 70..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..Content-Type: application/sdp..User-Agent: eyeBeam release 3006o stamp 175 51..Content-Length: 246....v=0..o=- 13437707 13437740 IN IP4 161.196.168.122..s=eyeBeam..c=IN IP4 161.196.168.122..t=0 0 ..m=audio 9728 RTP/AVP 8 0 3 18 101..a=alt:1 1 : 25FE3DE2 000000AD 161.196.168.122 9728..a=fmtp:101 0-15..a=rtpmap:101 t elephone-event/8000..a=sendrecv.. # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 100 trying -- your call is important to us..To: <sip:[email protected]>..From: 1112<sip:[email protected]. 48>;tag=7b3f434c..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-555568460-1--d87543-;rport=9375..Call-ID: 2e71af224e724d51..CSeq: 1 INVITE..Date: Thu, 04 Jan 2007 15:47:43 GMT..Date: Thu, 04 Jan 2007 15:47:43 GMT..Server: Open Ser (1.0.0 (i386/linux))..Content-Length: 0..Warning: 392 161.196.58.48:5060 "Noisy feedback tells: pid=21961 req_src_i p=161.196.168.122 req_src_port=9375 in_uri=sip:[email protected] out_uri=sip:[email protected] via_cnt= =1".... # U 161.196.58.48:5060 -> 161.196.58.47:5060

INVITE sip:[email protected] SIP/2.0..To: <sip:[email protected]>..From: 1112<sip:[email protected]>;t ag=7b3f434c..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKa0fe.6bb463a.0..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z 9hG4bK-d87543-555568460-1--d87543-;rport=9375..Call-ID: 2e71af224e724d51..CSeq: 1 INVITE..Contact: <sip:[email protected] .122:9375>..Max-Forwards: 69..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..Content -Type: application/sdp..User-Agent: eyeBeam release 3006o stamp 17551..Content-Length: 246....v=0..o=- 13437707 13437740 IN IP4 161.196.168.122..s=eyeBeam..c=IN IP4 161.196.168.122..t=0 0..m=audio 9728 RTP/AVP 8 0 3 18 101..a=alt:1 1 : 25FE 3DE2 000000AD 161.196.168.122 9728..a=fmtp:101 0-15..a=rtpmap:101 telephone-event/8000..a=sendrecv.. # U 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKa0fe.6bb463a.0;received=161.196.58.48..Via: SIP/2.0/UDP

- 200 -

161.196.168.122:9375;branch=z9hG4bK-d87543-555568460-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=7b3f 434c..To: <sip:[email protected]>..Call-ID: 2e71af224e724d51..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: I NVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Content-Length: 0 .... # U 161.196.58.47:5060 -> 200.109.126.164:5060

INVITE sip:[email protected];user=phone SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK1ce48ce4; rport..From: "1112" <sip:[email protected]>;tag=as010aa68f..To: <sip:[email protected];user=phon e>..Contact: <sip:[email protected]>..Call-ID: [email protected]: 102 INV ITE..User-Agent: Asterisk PBX..Max-Forwards: 70..Date: Thu, 04 Jan 2007 15:31:03 GMT..Allow: INVITE, ACK, CANCEL, OPTION S, BYE, REFER, SUBSCRIBE, NOTIFY..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161 .196.58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 5212 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCM A/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK1ce48ce4;rport=5060..From: "1112" <sip:2123360502@ sipproxy.cantv.net>;tag=as010aa68f..To: <sip:[email protected];user=phone>..Call-ID: 2145884a7b64b8aa3f63371 [email protected]: 102 INVITE.... # U 161.196.58.47:5060 -> 200.109.126.164:5060

ACK sip:[email protected];user=phone SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK1ce48ce4;rpo rt..From: "1112" <sip:[email protected]>;tag=as010aa68f..To: <sip:[email protected];user=phone>; tag=1167923394-9031411168826535-21..Contact: <sip:[email protected]>..Call-ID: 2145884a7b64b8aa3f63371b1fc076c1@s ipproxy.cantv.net..CSeq: 102 ACK..User-Agent: Asterisk PBX..Max-Forwards: 70..Content-Length: 0.... # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK6a5b643f;rport=5060..From: "1112" <sip:2 [email protected]>;tag=as010aa68f..To: <sip:[email protected];user=phone>;tag=1167923394-91326611 68836660-21..Call-ID: [email protected]: 103 INVITE..Contact: <sip:02125001824@2 00.109.126.164:5060;transport=udp>..Content-Type: application/sdp..Content-Length: 210....v=0..o=hiQ9200/CN0/010/052/121 05256520070004114821 171180153 IN IP4 200.109.126.164..s=Phone Call via hiQ9200 SIPCA..c=IN IP4 200.109.126.164..t=0 0. .m=audio 35364 RTP/AVP 8..a=rtpmap:8 PCMA/8000..a=sendrecv..

- 201 -

# U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK6a5b643f;rport=5060..From: "1112" <sip:2 [email protected]>;tag=as010aa68f..To: <sip:[email protected];user=phone>;tag=1167923394-91326611 68836660-21..Call-ID: [email protected]: 103 INVITE..Contact: <sip:02125001824@2 00.109.126.164:5060;transport=udp>..Content-Length: 0.... # U 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKa0fe.6bb463a.0;received=161.196.58.48..Via: S IP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-555568460-1--d87543-;rport=9375..From: 1112<sip:[email protected] >;tag=7b3f434c..To: <sip:[email protected]>;tag=as390a5302..Call-ID: 2e71af224e724d51..CSeq: 1 INVITE..User-Agen t: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]. 58.47>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161.196.58.47..s=session..c=I N IP4 161.196.58.47..t=0 0..m=audio 6010 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telep hone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-555568460-1--d87543-;rport=937 5..From: 1112<sip:[email protected]>;tag=7b3f434c..To: <sip:[email protected]>;tag=as390a5302..Call-ID: 2e71af2 24e724d51..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. .Contact: <sip:[email protected]>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161.196.58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 6010 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rt pmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK6a5b643f;rport=5060..From: "1112" <sip:2123360502 @sipproxy.cantv.net>;tag=as010aa68f..To: <sip:[email protected];user=phone>;tag=1167923394-9132661168836660- 21..Call-ID: [email protected]: 103 INVITE..Contact: <sip:[email protected] 6.164:5060;transport=udp>..Content-Length: 0.... # U 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKa0fe.6bb463a.0;received=161.196.58.48..Via: SIP/2.0/UD P 161.196.168.122:9375;branch=z9hG4bK-d87543-555568460-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=7b3

- 202 -

f434c..To: <sip:[email protected]>;tag=as390a5302..Call-ID: 2e71af224e724d51..CSeq: 1 INVITE..User-Agent: Asteri sk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..C ontent-Length: 0.... # U 161.196.58.47:5060 ->161.196.58.48:5060

SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK6a5b643f;rport=5060..From: "1112" <sip:2123360502 @sipproxy.cantv.net>;tag=as010aa68f..To: <sip:[email protected];user=phone>;tag=1167923394-9132661168836660- 21..Call-ID: [email protected]: 103 INVITE..Contact: <sip:[email protected] 6.164:5060;transport=udp>..Content-Length: 0.... # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-555568460-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=7b3f434c..To: <sip:[email protected]>;tag=as390a5302..Call-ID: 2e71af224e724d51 ..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Content-Length: 0.... # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK6a5b643f;rport=5060..From: "1112" <sip:2123360502@sipp roxy.cantv.net>;tag=as010aa68f..To: <sip:[email protected];user=phone>;tag=1167923394-9132661168836660-21..C all-ID: [email protected]: 103 INVITE..Contact: <sip:[email protected] :5060;transport=udp>..Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER..Accept-Language: en; q=0.0..Content-Type : application/sdp..Content-Length: 210....v=0..o=hiQ9200/CN0/010/052/121 05256520070004114821 171180153 IN IP4 200.109.1 26.164..s=Phone Call via hiQ9200 SIPCA..c=IN IP4 200.109.126.164..t=0 0..m=audio 35364 RTP/AVP 8..a=rtpmap:8 PCMA/8000.. a=sendrecv.. # U 161.196.58.47:5060 -> 200.109.126.164:5060

ACK sip:[email protected]:5060;transport=udp SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK5748b2 e1;rport..From: "1112" <sip:[email protected]>;tag=as010aa68f..To: <sip:[email protected];user=p hone>;tag=1167923394-9132661168836660-21..Contact: <sip:[email protected]>..Call-ID: 2145884a7b64b8aa3f63371b1fc0 [email protected]: 103 ACK..User-Agent: Asterisk PBX..Max-Forwards: 70..Content-Length: 0.... # U 161.196.58.47:5060 -> 161.196.58.48:5060

- 203 -

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKa0fe.6bb463a.0;received=161.196.58.48..Via: SIP/2.0/UDP 161 .196.168.122:9375;branch=z9hG4bK-d87543-555568460-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=7b3f434c ..To: <sip:[email protected]>;tag=as390a5302..Call-ID: 2e71af224e724d51..CSeq: 1 INVITE..User-Agent: Asterisk PB X..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Conten t-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2794 IN IP4 161.196.58.47..s=session..c=IN IP4 161.196. 58.47..t=0 0..m=audio 6010 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/800 0..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-555568460-1--d87543-;rport=9375..From: 1112< sip:[email protected]>;tag=7b3f434c..To: <sip:[email protected]>;tag=as390a5302..Call-ID: 2e71af224e724d51..CSe q: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip :[email protected]>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2794 IN IP4 161.196 .58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 6010 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/80 00..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 200.109.126.164:5060 -> 161.196.58.47:5060

BYE sip:[email protected] SIP/2.0..Via: SIP/2.0/UDP 200.109.126.164:5060;branch=z9hG4bKv10cub00cg21fb0iq7s1sd0o02 i82.1..From: <sip:[email protected];user=phone>;tag=1167923394-9132661168836660-21..To: "1112" <sip:21233605 [email protected]>;tag=as010aa68f..Max-Forwards: 68..CSeq: 205201 BYE..Call-ID: 2145884a7b64b8aa3f63371b1fc076c1@sip proxy.cantv.net..Content-Length: 0..Accept-Language: en; q=0.0.... # U 161.196.58.47:5060 -> 200.109.126.164:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 200.109.126.164:5060;branch=z9hG4bKv10cub00cg21fb0iq7s1sd0o02i82.1;received=200.109.126 .164..From: <sip:[email protected];user=phone>;tag=1167923394-9132661168836660-21..To: "1112" <sip:212336050 [email protected]>;tag=as010aa68f..Call-ID: [email protected]: 205201 BYE..Us er-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:2123360502@161 .196.58.47>..Content-Length: 0..X-Asterisk-HangupCause: Normal Clearing.... # U 161.196.58.47:5060 -> 161.196.168.122:9375

BYE sip:[email protected]:9375 SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK7b00404a;rport..From: <sip:

- 204 -

[email protected]>;tag=as390a5302..To: 1112<sip:[email protected]>;tag=7b3f434c..Contact: <sip:702125001824@161 .196.58.47>..Call-ID: 2e71af224e724d51..CSeq: 102 BYE..User-Agent: Asterisk PBX..Max-Forwards: 70..Content-Length: 0.... # U 161.196.168.122:9375 -> 161.196.58.47:5060

SIP/2.0 200 OK..To: 1112<sip:[email protected]>;tag=7b3f434c..From: <sip:[email protected]>;tag=as390a5302..Via : SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK7b00404a;rport=5060;received=161.196.58.47..Call-ID: 2e71af224e724d51..CS eq: 102 BYE..Contact: <sip:[email protected]:9375>..Content-Length: 0....

ANEXO 4. Trazas de una llamada desde un teléfono IP, colgando éste, hacia un teléfono en

la PSTN.

interface: eth0 (161.196.58.0/255.255.255.0) filter: (ip) and ( port 5060 ) # 161.196.168.122:9375 -> 161.196.58.48:5060

INVITE sip:[email protected] SIP/2.0..To: <sip:[email protected]>..From: 1112<sip:[email protected]>;ta g=e159c21f..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-497890199-1--d87543-;rport..Call-ID: 6b3730519b0 fb428..CSeq: 1 INVITE..Contact: <sip:[email protected]:9375>..Max-Forwards: 70..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..Content-Type: application/sdp..User-Agent: eyeBeam release 3006o stamp 175 51..Content-Length: 246....v=0..o=- 13555960 13556074 IN IP4 161.196.168.122..s=eyeBeam..c=IN IP4 161.196.168.122..t=0 0 ..m=audio 9728 RTP/AVP 8 0 3 18 101..a=alt:1 1 : B2233825 000000E8 161.196.168.122 9728..a=fmtp:101 0-15..a=rtpmap:101 t elephone-event/8000..a=sendrecv.. # 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 100 trying -- your call is important to us..To: <sip:[email protected]>..From: 1112<sip:[email protected]. 48>;tag=e159c21f..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-497890199-1--d87543-;rport=9375..Call-ID: 6b3730519b0fb428..CSeq: 1 INVITE..Date: Thu, 04 Jan 2007 15:49:42 GMT..Date: Thu, 04 Jan 2007 15:49:42 GMT..Server: Open Ser (1.0.0 (i386/linux))..Content-Length: 0..Warning: 392 161.196.58.48:5060 "Noisy feedback tells: pid=21962 req_src_i p=161.196.168.122 req_src_port=9375 in_uri=sip:[email protected] out_uri=sip:[email protected] via_cnt= =1".... # 161.196.58.48:5060 -> 161.196.58.47:5060

INVITE sip:[email protected] SIP/2.0..To: <sip:[email protected]>..From: 1112<sip:[email protected]>;t ag=e159c21f..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bK513c.c8b42013.0..Via: SIP/2.0/UDP 161.196.168.122:9375;branch= z9hG4bK-d87543-497890199-1--d87543-;rport=9375..Call-ID: 6b3730519b0fb428..CSeq: 1 INVITE..Contact: <sip:[email protected] 8.122:9375>..Max-Forwards: 69..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..Conten t-Type: application/sdp..User-Agent: eyeBeam release 3006o stamp 17551..Content-Length: 246....v=0..o=- 13555960 1355607 4 IN IP4 161.196.168.122..s=eyeBeam..c=IN IP4 161.196.168.122..t=0 0..m=audio 9728 RTP/AVP 8 0 3 18 101..a=alt:1 1 : B22 33825 000000E8 161.196.168.122 9728..a=fmtp:101 0-15..a=rtpmap:101 telephone-event/8000..a=sendrecv.. # 161.196.58.47:5060 -> 161.196.58.48:5060

- 206 -

SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bK513c.c8b42013.0;received=161.196.58.48..Via: SIP/2.0/UD P 161.196.168.122:9375;branch=z9hG4bK-d87543-497890199-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=e15 9c21f..To: <sip:[email protected]>..Call-ID: 6b3730519b0fb428..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Content-Length: 0.... # 161.196.58.47:5060 -> 200.109.126.164:5060

INVITE sip:[email protected];user=phone SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK5dfdde07; rport..From: "1112" <sip:[email protected]>;tag=as1d25fc2e..To: <sip:[email protected];user=phon e>..Contact: <sip:[email protected]>..Call-ID: [email protected]: 102 INV ITE..User-Agent: Asterisk PBX..Max-Forwards: 70..Date: Thu, 04 Jan 2007 15:33:01 GMT..Allow: INVITE, ACK, CANCEL, OPTION S, BYE, REFER, SUBSCRIBE, NOTIFY..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161 .196.58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 9336 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCM A/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK5dfdde07;rport=5060..From: "1112" <sip:2123360502@ sipproxy.cantv.net>;tag=as1d25fc2e..To: <sip:[email protected];user=phone>..Call-ID: 32316029369155616999758 [email protected]: 102 INVITE.... # 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK40ad24d3;rport=5060..From: "1112" <sip:2 [email protected]>;tag=as1d25fc2e..To: <sip:[email protected];user=phone>;tag=1167923513-23146111 68154974-21..Call-ID: [email protected]: 103 INVITE..Contact: <sip:02125001824@2 00.109.126.164:5060;transport=udp>..Content-Type: application/sdp..Content-Length: 210....v=0..o=hiQ9200/CN0/010/052/120 05256620070004115019 171180152 IN IP4 200.109.126.164..s=Phone Call via hiQ9200 SIPCA..c=IN IP4 200.109.126.164..t=0 0. .m=audio 35374 RTP/AVP 8..a=rtpmap:8 PCMA/8000..a=sendrecv.. # 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK40ad24d3;rport=5060..From: "1112" <sip:2 [email protected]>;tag=as1d25fc2e..To: <sip:[email protected];user=phone>;tag=1167923513-23146111

- 207 -

68154974-21..Call-ID: [email protected]: 103 INVITE..Contact: <sip:02125001824@2 00.109.126.164:5060;transport=udp>..Content-Length: 0.... # 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bK513c.c8b42013.0;received=161.196.58.48..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-497890199-1--d87543-;rport=9375..From: 1112<sip:[email protected] 8>;tag=e159c21f..To: <sip:[email protected]>;tag=as02b47578..Call-ID: 6b3730519b0fb428..CSeq: 1 INVITE..User-Age nt: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected] .58.47>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161.196.58.47..s=session..c= IN IP4 161.196.58.47..t=0 0..m=audio 7460 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 tele phone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-497890199-1--d87543-;rport=937 5..From: 1112<sip:[email protected]>;tag=e159c21f..To: <sip:[email protected]>;tag=as02b47578..Call-ID: 6b37305 19b0fb428..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. .Contact: <sip:[email protected]>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161.196.58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 7460 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rt pmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK40ad24d3;rport=5060..From: "1112" <sip:2123360502 @sipproxy.cantv.net>;tag=as1d25fc2e..To: <sip:[email protected];user=phone>;tag=1167923513-2314611168154974- 21..Call-ID: [email protected]: 103 INVITE..Contact: <sip:[email protected] 6.164:5060;transport=udp>..Content-Length: 0.... # 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bK513c.c8b42013.0;received=161.196.58.48..Via: SIP/2.0/U DP 161.196.168.122:9375;branch=z9hG4bK-d87543-497890199-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=e1 59c21f..To: <sip:[email protected]>;tag=as02b47578..Call-ID: 6b3730519b0fb428..CSeq: 1 INVITE..User-Agent: Aster isk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>.. Content-Length: 0.... #

- 208 -

161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 180 Ringing..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-497890199-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=e159c21f..To: <sip:[email protected]>;tag=as02b47578..Call-ID: 6b3730519b0fb428 ..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Content-Length: 0.... # 161.196.58.47:5060 -> 200.109.126.164:5060

ACK sip:[email protected]:5060;transport=udp SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK424a5e 3e;rport..From: "1112" <sip:[email protected]>;tag=as1d25fc2e..To: <sip:[email protected];user=p hone>;tag=1167923513-2314611168154974-21..Contact: <sip:[email protected]>..Call-ID: 32316029369155616999758024d1 [email protected]: 103 ACK..User-Agent: Asterisk PBX..Max-Forwards: 70..Content-Length: 0.... # 161.196.168.122:9375 -> 161.196.58.47:5060

ACK sip:[email protected] SIP/2.0..To: <sip:[email protected]>;tag=as02b47578..From: 1112<sip:1112@161. 196.58.48>;tag=e159c21f..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-926500350-1--d87543-;rport..Call-ID : 6b3730519b0fb428..CSeq: 1 ACK..Contact: <sip:[email protected]:9375>..Max-Forwards: 70..User-Agent: eyeBeam release 3006o stamp 17551..Content-Length: 0.... # 161.196.168.122:9375 -> 161.196.58.47:5060

BYE sip:[email protected] SIP/2.0..To: <sip:[email protected]>;tag=as02b47578..From: 1112<sip:1112@161. 196.58.48>;tag=e159c21f..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-931560588-1--d87543-;rport..Call-ID : 6b3730519b0fb428..CSeq: 2 BYE..Contact: <sip:[email protected]:9375>..Max-Forwards: 70..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..User-Agent: eyeBeam release 3006o stamp 17551..Content-Length: 0 .... # 161.196.58.47:5060 -> 161.196.168.122:9375

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-931560588-1--d87543-;received=161.196.168.12 2;rport=9375..From: 1112<sip:[email protected]>;tag=e159c21f..To: <sip:[email protected]>;tag=as02b47578..Call- ID: 6b3730519b0fb428..CSeq: 2 BYE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Content-Length: 0..X-Asterisk-HangupCause: Normal Clearing.... # 161.196.58.47:5060 -> 200.109.126.164:5060

BYE sip:[email protected]:5060;transport=udp SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK54822d

- 209 -

62;rport..From: "1112" <sip:[email protected]>;tag=as1d25fc2e..To: <sip:[email protected];user=p hone>;tag=1167923513-2314611168154974-21..Contact: <sip:[email protected]>..Call-ID: 32316029369155616999758024d1 [email protected]: 104 BYE..User-Agent: Asterisk PBX..Max-Forwards: 70..Authorization: Digest username="2123 360502", realm="sip.ops.cantv.net", algorithm=MD5, uri="sip:[email protected]:5060", nonce="3089300540-7373191 f87ba3a5fc82b6820d51b3161", response="3dc319f56609afe793044819aff7dd8d", opaque="", qop=auth, cnonce="440581e2", nc=0000 0002..Content-Length: 0.... # 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK54822d62;rport=5060..From: "1112" <sip:2123360502@sipp roxy.cantv.net>;tag=as1d25fc2e..To: <sip:[email protected];user=phone>;tag=1167923513-2314611168154974-21..C

all-ID: [email protected]:

ANEXO 5. Trazas de una llamada desde un teléfono IP hacia un teléfono celular, colgando

éste.


INVITE sip:[email protected] SIP/2.0..To: <sip:[email protected]>..From: 1112<sip:[email protected]>;ta g=d1774231..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-735001294-1--d87543-;rport..Call-ID: e731d418904 2c723..CSeq: 1 INVITE..Contact: <sip:[email protected]:9375>..Max-Forwards: 70..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..Content-Type: application/sdp..User-Agent: eyeBeam release 3006o stamp 175 51..Content-Length: 244....v=0..o=- 9268981 9269023 IN IP4 161.196.168.122..s=eyeBeam..c=IN IP4 161.196.168.122..t=0 0.. m=audio 9728 RTP/AVP 8 0 3 18 101..a=alt:1 1 : 16B56C63 000000D7 161.196.168.122 9728..a=fmtp:101 0-15..a=rtpmap:101 tel ephone-event/8000..a=sendrecv.. # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 100 trying -- your call is important to us..To: <sip:[email protected]>..From: 1112<sip:[email protected]. 48>;tag=d1774231..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-735001294-1--d87543-;rport=9375..Call-ID: e731d4189042c723..CSeq: 1 INVITE..Date: Thu, 04 Jan 2007 14:38:14 GMT..Date: Thu, 04 Jan 2007 14:38:14 GMT..Server: Open Ser (1.0.0 (i386/linux))..Content-Length: 0..Warning: 392 161.196.58.48:5060 "Noisy feedback tells: pid=21963 req_src_i p=161.196.168.122 req_src_port=9375 in_uri=sip:[email protected] out_uri=sip:[email protected] via_cnt= =1".... # U 161.196.58.48:5060 -> 161.196.58.47:5060

INVITE sip:[email protected] SIP/2.0..To: <sip:[email protected]>..From: 1112<sip:[email protected]>;t ag=d1774231..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKbc78.333fd176.0..Via: SIP/2.0/UDP 161.196.168.122:9375;branch= z9hG4bK-d87543-735001294-1--d87543-;rport=9375..Call-ID: e731d4189042c723..CSeq: 1 INVITE..Contact: <sip:[email protected] 8.122:9375>..Max-Forwards: 69..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..Conten t-Type: application/sdp..User-Agent: eyeBeam release 3006o stamp 17551..Content-Length: 244....v=0..o=- 9268981 9269023 IN IP4 161.196.168.122..s=eyeBeam..c=IN IP4 161.196.168.122..t=0 0..m=audio 9728 RTP/AVP 8 0 3 18 101..a=alt:1 1 : 16B56 C63 000000D7 161.196.168.122 9728..a=fmtp:101 0-15..a=rtpmap:101 telephone-event/8000..a=sendrecv.. # U 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKbc78.333fd176.0;received=161.196.58.48..Via: SIP/2.0/UD

- 211 -

P 161.196.168.122:9375;branch=z9hG4bK-d87543-735001294-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=d17 74231..To: <sip:[email protected]>..Call-ID: e731d4189042c723..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Content-Length: 0.... # U 161.196.58.47:5060 -> 200.109.126.164:5060

INVITE sip:[email protected];user=phone SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK39788cb9; rport..From: "1112" <sip:[email protected]>;tag=as1ab24c88..To: <sip:[email protected];user=phon e>..Contact: <sip:[email protected]>..Call-ID: [email protected]: 102 INV ITE..User-Agent: Asterisk PBX..Max-Forwards: 70..Date: Thu, 04 Jan 2007 14:21:34 GMT..Allow: INVITE, ACK, CANCEL, OPTION S, BYE, REFER, SUBSCRIBE, NOTIFY..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161 .196.58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 6844 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCM A/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK39788cb9;rport=5060..From: "1112" <sip:2123360502@ sipproxy.cantv.net>;tag=as1ab24c88..To: <sip:[email protected];user=phone>..Call-ID: 4d686319232c3306250aee9 [email protected]: 102 INVITE.... # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK1bbac563;rport=5060..From: "1112" <sip:2 [email protected]>;tag=as1ab24c88..To: <sip:[email protected];user=phone>;tag=1167919226-90079411 68820020-21..Call-ID: [email protected]: 103 INVITE..Contact: <sip:04168269381@2 00.109.126.164:5060;transport=udp>..Content-Type: application/sdp..Content-Length: 210....v=0..o=hiQ9200/CN0/010/064/125 05251020070004103852 171966589 IN IP4 200.109.126.164..s=Phone Call via hiQ9200 SIPCA..c=IN IP4 200.109.126.164..t=0 0. .m=audio 35288 RTP/AVP 8..a=rtpmap:8 PCMA/8000..a=sendrecv.. # U 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKbc78.333fd176.0;received=161.196.58.48..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-735001294-1--d87543-;rport=9375..From: 1112<sip:[email protected] 8>;tag=d1774231..To: <sip:[email protected]>;tag=as6ea6ed3e..Call-ID: e731d4189042c723..CSeq: 1 INVITE..User-Age nt: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]

- 212 -

.58.47>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161.196.58.47..s=session..c= IN IP4 161.196.58.47..t=0 0..m=audio 7512 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 tele phone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-735001294-1--d87543-;rport=937 5..From: 1112<sip:[email protected]>;tag=d1774231..To: <sip:[email protected]>;tag=as6ea6ed3e..Call-ID: e731d41 89042c723..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. .Contact: <sip:[email protected]>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161.196.58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 7512 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rt pmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK1bbac563;rport=5060..From: "1112" <sip:2123360502@sipp roxy.cantv.net>;tag=as1ab24c88..To: <sip:[email protected];user=phone>;tag=1167919226-9007941168820020-21..C all-ID: [email protected]: 103 INVITE..Contact: <sip:[email protected] :5060;transport=udp>..Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER..Accept-Language: en; q=0.0..Content-Type : application/sdp..Content-Length: 210....v=0..o=hiQ9200/CN0/010/064/125 05251020070004103852 171966589 IN IP4 200.109.1 26.164..s=Phone Call via hiQ9200 SIPCA..c=IN IP4 200.109.126.164..t=0 0..m=audio 35288 RTP/AVP 8..a=rtpmap:8 PCMA/8000.. a=sendrecv.. # U 161.196.58.47:5060 -> 200.109.126.164:5060

ACK sip:[email protected]:5060;transport=udp SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK3e17ac 9c;rport..From: "1112" <sip:[email protected]>;tag=as1ab24c88..To: <sip:[email protected];user=p hone>;tag=1167919226-9007941168820020-21..Contact: <sip:[email protected]>..Call-ID: 4d686319232c3306250aee9464a2 [email protected]: 103 ACK..User-Agent: Asterisk PBX..Max-Forwards: 70..Content-Length: 0.... # U 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKbc78.333fd176.0;received=161.196.58.48..Via: SIP/2.0/UDP 16 1.196.168.122:9375;branch=z9hG4bK-d87543-735001294-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=d177423 1..To: <sip:[email protected]>;tag=as6ea6ed3e..Call-ID: e731d4189042c723..CSeq: 1 INVITE..User-Agent: Asterisk P

- 213 -

BX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Conte nt-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2794 IN IP4 161.196.58.47..s=session..c=IN IP4 161.196 .58.47..t=0 0..m=audio 7512 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/80 00..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-735001294-1--d87543-;rport=9375..From: 1112< sip:[email protected]>;tag=d1774231..To: <sip:[email protected]>;tag=as6ea6ed3e..Call-ID: e731d4189042c723..CSe q: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip :[email protected]>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2794 IN IP4 161.196 .58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 7512 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/80 00..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 161.196.168.122:9375 -> 161.196.58.47:5060

ACK sip:[email protected] SIP/2.0..To: <sip:[email protected]>;tag=as6ea6ed3e..From: 1112<sip:1112@161. 196.58.48>;tag=d1774231..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-807099364-1--d87543-;rport..Call-ID : e731d4189042c723..CSeq: 1 ACK..Contact: <sip:[email protected]:9375>..Max-Forwards: 70..User-Agent: eyeBeam release 3006o stamp 17551..Content-Length: 0.... # U 200.109.126.164:5060 -> 161.196.58.47:5060

BYE sip:[email protected] SIP/2.0..Via: SIP/2.0/UDP 200.109.126.164:5060;branch=z9hG4bKbhf11d00787hjbk0d181sd0o00 ik1.1..From: <sip:[email protected];user=phone>;tag=1167919226-9007941168820020-21..To: "1112" <sip:21233605 [email protected]>;tag=as1ab24c88..Max-Forwards: 68..CSeq: 204905 BYE..Call-ID: 4d686319232c3306250aee9464a2eeae@sip proxy.cantv.net..Content-Length: 0..Accept-Language: en; q=0.0.... # U 161.196.58.47:5060 -> 200.109.126.164:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 200.109.126.164:5060;branch=z9hG4bKbhf11d00787hjbk0d181sd0o00ik1.1;received=200.109.126 .164..From: <sip:[email protected];user=phone>;tag=1167919226-9007941168820020-21..To: "1112" <sip:212336050 [email protected]>;tag=as1ab24c88..Call-ID: [email protected]: 204905 BYE..Us er-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:2123360502@161 .196.58.47>..Content-Length: 0..X-Asterisk-HangupCause: Normal Clearing.... #

- 214 -

U 161.196.58.47:5060 -> 161.196.168.122:9375

BYE sip:[email protected]:9375 SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK4b8ca203;rport..From: <sip: [email protected]>;tag=as6ea6ed3e..To: 1112<sip:[email protected]>;tag=d1774231..Contact: <sip:704168269381@161 .196.58.47>..Call-ID: e731d4189042c723..CSeq: 102 BYE..User-Agent: Asterisk PBX..Max-Forwards: 70..Content-Length: 0.... # U 161.196.168.122:9375 -> 161.196.58.47:5060

SIP/2.0 200 OK..To: 1112<sip:[email protected]>;tag=d1774231..From: <sip:[email protected]>;tag=as6ea6ed3e..Via : SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK4b8ca203;rport=5060;received=161.196.58.47..Call-ID: e731d4189042c723..CS eq: 102 BYE..Contact: <sip:[email protected]:9375>..Content-

ANEXO 6. Trazas de una llamada desde un teléfono IP, colgando éste, hacia un teléfono

celular.


INVITE sip:[email protected] SIP/2.0..To: <sip:[email protected]>..From: 1112<sip:[email protected]>;ta g=5663e06f..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-660490420-1--d87543-;rport..Call-ID: 12416543776 feb46..CSeq: 1 INVITE..Contact: <sip:[email protected]:9375>..Max-Forwards: 70..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..Content-Type: application/sdp..User-Agent: eyeBeam release 3006o stamp 175 51..Content-Length: 246....v=0..o=- 10116493 10116950 IN IP4 161.196.168.122..s=eyeBeam..c=IN IP4 161.196.168.122..t=0 0 ..m=audio 9728 RTP/AVP 8 0 3 18 101..a=alt:1 1 : 3E25CD6B 000000CD 161.196.168.122 9728..a=fmtp:101 0-15..a=rtpmap:101 t elephone-event/8000..a=sendrecv.. # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 100 trying -- your call is important to us..To: <sip:[email protected]>..From: 1112<sip:[email protected]. 48>;tag=5663e06f..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-660490420-1--d87543-;rport=9375..Call-ID: 12416543776feb46..CSeq: 1 INVITE..Date: Thu, 04 Jan 2007 14:52:22 GMT..Date: Thu, 04 Jan 2007 14:52:22 GMT..Server: Open Ser (1.0.0 (i386/linux))..Content-Length: 0..Warning: 392 161.196.58.48:5060 "Noisy feedback tells: pid=21961 req_src_i p=161.196.168.122 req_src_port=9375 in_uri=sip:[email protected] out_uri=sip:[email protected] via_cnt= =1".... # U 161.196.58.48:5060 -> 161.196.58.47:5060

INVITE sip:[email protected] SIP/2.0..To: <sip:[email protected]>..From: 1112<sip:[email protected]>;t ag=5663e06f..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKf4bd.2d13ebc5.0..Via: SIP/2.0/UDP 161.196.168.122:9375;branch= z9hG4bK-d87543-660490420-1--d87543-;rport=9375..Call-ID: 12416543776feb46..CSeq: 1 INVITE..Contact: <sip:[email protected] 8.122:9375>..Max-Forwards: 69..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..Conten t-Type: application/sdp..User-Agent: eyeBeam release 3006o stamp 17551..Content-Length: 246....v=0..o=- 10116493 1011695 0 IN IP4 161.196.168.122..s=eyeBeam..c=IN IP4 161.196.168.122..t=0 0..m=audio 9728 RTP/AVP 8 0 3 18 101..a=alt:1 1 : 3E2 5CD6B 000000CD 161.196.168.122 9728..a=fmtp:101 0-15..a=rtpmap:101 telephone-event/8000..a=sendrecv.. # U 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKf4bd.2d13ebc5.0;received=161.196.58.48..Via: SIP/2.0/UD

- 216 -

P 161.196.168.122:9375;branch=z9hG4bK-d87543-660490420-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=566 3e06f..To: <sip:[email protected]>..Call-ID: 12416543776feb46..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Content-Length: 0.... # U 161.196.58.47:5060 -> 200.109.126.164:5060

INVITE sip:[email protected];user=phone SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK1c14fc44; rport..From: "1112" <sip:[email protected]>;tag=as50626e58..To: <sip:[email protected];user=phon e>..Contact: <sip:[email protected]>..Call-ID: [email protected]: 102 INV ITE..User-Agent: Asterisk PBX..Max-Forwards: 70..Date: Thu, 04 Jan 2007 14:35:42 GMT..Allow: INVITE, ACK, CANCEL, OPTION S, BYE, REFER, SUBSCRIBE, NOTIFY..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161 .196.58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 5684 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCM A/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 100 Trying..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK1c14fc44;rport=5060..From: "1112" <sip:2123360502@ sipproxy.cantv.net>;tag=as50626e58..To: <sip:[email protected];user=phone>..Call-ID: 3246dcb166b35b445ab20e7 [email protected]: 102 INVITE.... # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK60e65157;rport=5060..From: "1112" <sip:2 [email protected]>;tag=as50626e58..To: <sip:[email protected];user=phone>;tag=1167920074-67886911 68598943-21..Call-ID: [email protected]: 103 INVITE..Contact: <sip:04168269381@2 00.109.126.164:5060;transport=udp>..Content-Type: application/sdp..Content-Length: 210....v=0..o=hiQ9200/CN0/010/048/123 05251720070004105300 170918011 IN IP4 200.109.126.164..s=Phone Call via hiQ9200 SIPCA..c=IN IP4 200.109.126.164..t=0 0. .m=audio 35302 RTP/AVP 8..a=rtpmap:8 PCMA/8000..a=sendrecv.. # U 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKf4bd.2d13ebc5.0;received=161.196.58.48..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-660490420-1--d87543-;rport=9375..From: 1112<sip:[email protected] 8>;tag=5663e06f..To: <sip:[email protected]>;tag=as4020aa7c..Call-ID: 12416543776feb46..CSeq: 1 INVITE..User-Age nt: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]

- 217 -

.58.47>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161.196.58.47..s=session..c= IN IP4 161.196.58.47..t=0 0..m=audio 6544 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 tele phone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 183 Session Progress..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-660490420-1--d87543-;rport=937 5..From: 1112<sip:[email protected]>;tag=5663e06f..To: <sip:[email protected]>;tag=as4020aa7c..Call-ID: 1241654 3776feb46..CSeq: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY. .Contact: <sip:[email protected]>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2793 IN IP4 161.196.58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 6544 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rt pmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK60e65157;rport=5060..From: "1112" <sip:2123360502@sipp roxy.cantv.net>;tag=as50626e58..To: <sip:[email protected];user=phone>;tag=1167920074-6788691168598943-21..C all-ID: [email protected]: 103 INVITE..Contact: <sip:[email protected] :5060;transport=udp>..Allow: REGISTER, INVITE, ACK, BYE, CANCEL, NOTIFY, REFER..Accept-Language: en; q=0.0..Content-Type : application/sdp..Content-Length: 210....v=0..o=hiQ9200/CN0/010/048/123 05251720070004105300 170918011 IN IP4 200.109.1 26.164..s=Phone Call via hiQ9200 SIPCA..c=IN IP4 200.109.126.164..t=0 0..m=audio 35302 RTP/AVP 8..a=rtpmap:8 PCMA/8000.. a=sendrecv.. # U 161.196.58.47:5060 -> 200.109.126.164:5060

ACK sip:[email protected]:5060;transport=udp SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK60d8cf 1b;rport..From: "1112" <sip:[email protected]>;tag=as50626e58..To: <sip:[email protected];user=p hone>;tag=1167920074-6788691168598943-21..Contact: <sip:[email protected]>..Call-ID: 3246dcb166b35b445ab20e7c04ea [email protected]: 103 ACK..User-Agent: Asterisk PBX..Max-Forwards: 70..Content-Length: 0.... # U 161.196.58.47:5060 -> 161.196.58.48:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.58.48;branch=z9hG4bKf4bd.2d13ebc5.0;received=161.196.58.48..Via: SIP/2.0/UDP 16 1.196.168.122:9375;branch=z9hG4bK-d87543-660490420-1--d87543-;rport=9375..From: 1112<sip:[email protected]>;tag=5663e06 f..To: <sip:[email protected]>;tag=as4020aa7c..Call-ID: 12416543776feb46..CSeq: 1 INVITE..User-Agent: Asterisk P

- 218 -

BX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Conte nt-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2794 IN IP4 161.196.58.47..s=session..c=IN IP4 161.196 .58.47..t=0 0..m=audio 6544 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/80 00..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 161.196.58.48:5060 -> 161.196.168.122:9375

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-660490420-1--d87543-;rport=9375..From: 1112< sip:[email protected]>;tag=5663e06f..To: <sip:[email protected]>;tag=as4020aa7c..Call-ID: 12416543776feb46..CSe q: 1 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip :[email protected]>..Content-Type: application/sdp..Content-Length: 239....v=0..o=root 2793 2794 IN IP4 161.196 .58.47..s=session..c=IN IP4 161.196.58.47..t=0 0..m=audio 6544 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/80 00..a=rtpmap:101 telephone-event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 161.196.168.122:9375 -> 161.196.58.47:5060

ACK sip:[email protected] SIP/2.0..To: <sip:[email protected]>;tag=as4020aa7c..From: 1112<sip:1112@161. 196.58.48>;tag=5663e06f..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-769809811-1--d87543-;rport..Call-ID : 12416543776feb46..CSeq: 1 ACK..Contact: <sip:[email protected]:9375>..Max-Forwards: 70..User-Agent: eyeBeam release 3006o stamp 17551..Content-Length: 0.... # U 161.196.168.122:9375 -> 161.196.58.47:5060

BYE sip:[email protected] SIP/2.0..To: <sip:[email protected]>;tag=as4020aa7c..From: 1112<sip:1112@161. 196.58.48>;tag=5663e06f..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-528442032-1--d87543-;rport..Call-ID : 12416543776feb46..CSeq: 2 BYE..Contact: <sip:[email protected]:9375>..Max-Forwards: 70..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO..User-Agent: eyeBeam release 3006o stamp 17551..Content-Length: 0 .... # U 161.196.58.47:5060 -> 161.196.168.122:9375

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.168.122:9375;branch=z9hG4bK-d87543-528442032-1--d87543-;received=161.196.168.12 2;rport=9375..From: 1112<sip:[email protected]>;tag=5663e06f..To: <sip:[email protected]>;tag=as4020aa7c..Call- ID: 12416543776feb46..CSeq: 2 BYE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY..Contact: <sip:[email protected]>..Content-Length: 0..X-Asterisk-HangupCause: Normal Clearing.... #

- 219 -

U 161.196.58.47:5060 -> 200.109.126.164:5060

BYE sip:[email protected]:5060;transport=udp SIP/2.0..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK0b9ab9 84;rport..From: "1112" <sip:[email protected]>;tag=as50626e58..To: <sip:[email protected];user=p hone>;tag=1167920074-6788691168598943-21..Contact: <sip:[email protected]>..Call-ID: 3246dcb166b35b445ab20e7c04ea [email protected]: 104 BYE..User-Agent: Asterisk PBX..Max-Forwards: 70..Authorization: Digest username="2123 360502", realm="sip.ops.cantv.net", algorithm=MD5, uri="sip:[email protected]:5060", nonce="3089266154-3d1de69 fdafd426b2d1b5437d5375953", response="d60485275601af1ff4879a3e8c12f425", opaque="", qop=auth, cnonce="284f24e5", nc=0000 0002..Content-Length: 0.... # U 200.109.126.164:5060 -> 161.196.58.47:5060

SIP/2.0 200 OK..Via: SIP/2.0/UDP 161.196.58.47:5060;branch=z9hG4bK0b9ab984;rport=5060..From: "1112" <sip:2123360502@sipp roxy.cantv.net>;tag=as50626e58..To: <sip:[email protected];user=phone>;tag=1167920074-6788691168598943-21..C all-ID: [email protected]: 104 BYE..Content-Length: 0....

asterisk

Documents

Transcript of asterisk