PROYECTO FIN DE GRADOoa.upm.es/52129/1/TFG_ESTHER_BENAYAS_MELERO.pdf · 2018-09-10 · Asterisk es un B2BUA, por lo que, de manera análoga, todos los nodos de una red IMS que funcionen

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA Y SISTEMAS DE TELECOMUNICACIÓN

PROYECTO FIN DE GRADO

TÍTULO: Diseño y Despliegue de un entorno de pruebas virtualizado de una red IMS

AUTOR: Esther Benayas Melero

TITULACIÓN: Grado en Ingeniería Telemática

DIRECTOR: Mary Luz Mouronte López

TUTOR: Ana Belén García Hernando

DEPARTAMENTO: INGENIERÍA TELEMÁTICA Y ELECTRÓNICA

VºBº

Miembros del Tribunal Calificador: PRESIDENTE: Eduardo Nogueira Díaz TUTOR: Ana Belén García Hernando SECRETARIO: Carlos Ramos Nespereira Fecha de lectura:

Calificación:

El Secretario,

Diseño y Despliegue de un Entorno de Pruebas Virtualizado de una Red IMS

1

Resumen

Este proyecto, Diseño y Despliegue de un entorno de pruebas virtualizado de una red IMS,

tiene como finalidad proporcionar un entorno de pruebas virtualizado de una red IMS. Este

entorno virtualizado pretende facilitar el estudio de la interacción de los principales nodos de

una red IMS y de su interacción con elementos externos, tales como centralitas o servidores

de aplicaciones, cuando una llamada de voz es transmitida a través de dicha red.

Al ser un entorno virtualizado, son posibles diferentes arquitecturas de despliegue en función

de dónde esté el foco o interés del estudio, de tal manera que, cada uno de los elementos del

laboratorio podrían desplegarse sobre diferentes máquinas físicas conectadas a través de una

red LAN o cada uno de los nodos podrían ser desplegados en diferentes máquinas virtuales

conectadas a través de una red virtualizada alojada en una única máquina física, o se podría

utilizar cualquier combinación de las anteriores, por ejemplo, varios nodos de la red podrían

ser desplegados en diferentes máquinas virtuales conectadas mediante una red virtualizada

sobre una misma máquina física, mientras que otros podrían ser desplegados sobre otra

máquina física. También podríamos desplegar la funcionalidad de varios nodos de la red

sobre la misma máquina virtual, desplegando el resto de nodos en otra máquina virtual

conectada mediante una red virtualizada sobre la misma máquina física o en otra máquina

virtual conectada mediante una red LAN sobre otra máquina física. Como se puede ver las

posibilidades son infinitas y la manera de tomar una decisión acertada sobre la arquitectura de

despliegue a utilizar dependerá, como se ha indicado anteriormente, de dónde se encuentre el

foco del estudio.

Para conseguir dicho objetivo, se han utilizado herramientas de libre distribución, tanto para

implementar cada uno de los nodos del laboratorio, como para realizar las pruebas que

demuestran el correcto funcionamiento de éste. Se han elegido dos herramientas clave que son

capaces de funcionar como los dos elementos clave de una red IMS. En una red IMS nos

podemos encontrar con dos tipos de nodos o elementos: el SIP Proxy y el B2BUA. Existen

muchos nodos en una red IMS, cada uno de ellos con diferentes características entre sí, pero

con una característica común y que determinará su naturaleza. Y es que, cada uno de los

nodos de una red IMS funcionará o bien como un SIP Proxy o bien como un B2BUA. La

elección del software utilizado para el laboratorio, así como la decisión de los nodos que se

iban a representar, ha sido tomada basándose en esta característica. Kamailio es un SIP Proxy,

por lo que todos los nodos de una red IMS que funcionan como SIP Proxy podrán ser

simulados con una instancia de Kamailio con su correspondiente configuración. Por otro lado,

Asterisk es un B2BUA, por lo que, de manera análoga, todos los nodos de una red IMS que

funcionen como un B2BUA podrán ser simulados con una instancia de Asterisk con su

correspondiente configuración.

Gracias a la naturaleza del software elegido, de la naturaleza virtualizada del entorno y a las

características de las redes IMS, este laboratorio es fácilmente escalable, de manera que será


2

fácil introducir más nodos al laboratorio o introducir diferentes redes IMS pertenecientes a

diferentes dominios, cada una de ellas con sus correspondientes nodos y la interconexión con

otras redes de la misma índole. Esto proporciona una herramienta docente muy potente y que

brinda la posibilidad de estudiar escenarios cada vez más complejos.

Dada la evolución que han sufrido las comunicaciones en los últimos años y la previsión de

crecimiento de dichas redes a corto-medio plazo, se hace interesante brindar dicha

posibilidad, puesto que las redes IMS han representado un papel importante en los últimos 10

años, y aunque el “durante cuánto tiempo” es aún un misterio, como todo en lo referente a las

comunicaciones, lo que sí sabemos es que las redes IMS seguirán representado un papel más

importante aún durante algún tiempo más.


3

Abstract

The purpose of this project, Design and Deployment a Virtualized Test Environment for an

IMS Network, consists of providing a virtualized test environment for IMS Networks. This

virtualized environment tries to make easier the study about interaction among main IMS

network nodes and their interaction with extern elements, such as phone centrexs or

application servers, when a voice call is transmitted towards said network.

Due to it is a virtualized environment, different architectures of deployment are possible

according to where focus or interest of the study is found, in such a way that, every element of

the laboratory could be deployed on different physical machines which are connected by a

LAN network or every node could be deployed on a only virtual machine and all nodes are

connected by virtualized network hosted, all of it, on an only physical machine or any

combination of the last options could be used, for instance, several network nodes could be

deployed on different virtual machines that are connected by virtualized network on an only

physical machine, meanwhile other nodes could be deployed on another physical machine. As

it can be seen the possibilities are endless and the way to make a right decision on the

deployment architecture to use will depend, as it has been said above, on where the study

focus is.

Free distribution tools have been used in order to achieve this aim, both to implement every

node of the laboratory and to perform the tests that show the right performance of the nodes.

Two key tools have been chosen which are able to work as the two key elements of an IMS

network. In an IMS network we can find two types of nodes or elements: sip proxy and back

to back user agent (B2BUA). There are many nodes in an IMS network, everyone with

different characteristics, but all of them with a common characteristic which determines its

nature. And it is that, each and every node, on an IMS network, will function either as a sip

Proxy or as a B2BUA. Both the choice of the software used for the laboratory, and the

decision on the nodes to be represented, has been taken based on this characteristic. Kamailio

is a sip proxy, so all of the IMS network nodes which work as sip proxy can be simulated with

a Kamailio instance with its right configuration. On the other hand, Asterisk is a B2BUA, so

that, similarly, all of IMS network nodes witch work as a B2BUA can be simulated with an

Asterisk instance with its right configuration.

Thanks to the chosen software nature, the environment's virtualized nature and the IMS

networks' characteristics, this laboratory is easily scalable, so it will be easy to introduce more

network nodes to the laboratory or add different IMS networks belonging to different

domains, each one of them with their corresponding nodes and the interconnection among the

different IMS networks. This provides a very powerful teaching tool and gives you the

possibility to study increasingly complex scenarios.

Given the evolution of communications for the last years and the growth forecast for such

networks in the short-medium term, it is interesting to offer such possibility, since IMS


4

networks have played an important role in the last 10 years, and even although the "how long"

is still a mystery, as all in communications field, what we do know is that IMS networks will

continue to play a highly remarkable role for a while.


5

Índice de contenido

Resumen .......................................................................................................................... 1

Abstract ........................................................................................................................... 3

Índice de contenido ......................................................................................................... 5

Índice de figuras ............................................................................................................. 7

Lista de acrónimos .......................................................................................................... 9

1 Introducción ...................................................................................................... 11

1.1 Marco y motivación del proyecto ....................................................................... 11

1.2 Objetivos técnicos y académicos ........................................................................ 11

1.3 Estructura del resto de la memoria ..................................................................... 11

2 Marco tecnológico ............................................................................................. 13

2.1 IMS o IP-Multimedia Subsystem ....................................................................... 13

2.1.1 Estructuración en Capas de la arquitectura IMS........................................................................... 14 2.1.2 La capa de control (Call State Control Function) .......................................................................... 15 2.1.3 Modelo de subscripción (HSS)...................................................................................................... 17 2.1.4 SIP (Session Initation Procotocol)................................................................................................. 24

3 Especificaciones y restricciones de diseño ...................................................... 43

4 Descripción de la solución propuesta .............................................................. 45

4.1 Herramientas utilizadas ...................................................................................... 45

4.2 Arquitecturas de despliegue posibles .................................................................. 48

4.3 Arquitectura de despliegue utilizada .................................................................. 49

4.3.1 Proxy CSCF ................................................................................................................................. 51 4.3.2 Interrogating CSCF ....................................................................................................................... 52 4.3.3 Serving CSCF ............................................................................................................................... 52 4.3.4 HSS y elementos adicionales ...................................................................................................... 53 4.3.5 Servidor de aplicaciones ............................................................................................................... 53 4.3.6 PBX Registrada............................................................................................................................. 58 4.3.7 PBX No registrada ........................................................................................................................ 59 - Como usuarios de la red IMS........................................................................................................ 59 - Como usuarios de la PBX registrada ............................................................................................ 59 - Como usuarios de la PBX No registrada ...................................................................................... 59

5 Resultados .......................................................................................................... 61

5.1 Llamada desde una extensión de PBX a otra extensión de la misma PBX ........ 61

5.2 Llamada de SIP a SIP ......................................................................................... 63

5.3 Llamada SIP a SIP con Desvío incondicional a otro SIP ................................... 64

5.4 Llamada SIP a SIP con Re-Routing a otro SIP ................................................... 65

5.5 Llamada desde una extensión de PBX no Registrada a un SIP .......................... 65

5.6 Llamada desde un SIP a una extensión de PBX no Registrada .......................... 67


6

6 Conclusiones ...................................................................................................... 69

6.1 Conclusiones ....................................................................................................... 69

6.2 Trabajos futuros .................................................................................................. 70

7 Referencias ........................................................................................................ 73

8 Bibliografía ........................................................................................................ 81

Anexo A. Presupuesto .................................................................................................. 83

Anexo B. Manual de usuario ....................................................................................... 85

B.1 Guía de Instalación ............................................................................................. 85

B.1.1 Preparación del entorno IMSLab .................................................................................................. 85 B.1.2 HSS ............................................................................................................................................. 106 B.1.3 Asterisk ....................................................................................................................................... 115 B.1.4 Kamailio ...................................................................................................................................... 119

B.2 Manual de Usuario ............................................................................................ 121

B.2.1 Asterisk-AS ................................................................................................................................. 123 B.2.2 Asterisk-PBX ............................................................................................................................... 124 B.2.3 DNSServer .................................................................................................................................. 126 B.2.4 OM: Scripts ................................................................................................................................. 130 B.2.5 OpenIMSCore ............................................................................................................................. 132 B.2.6 RTPProxy .................................................................................................................................... 137 B.2.7 STUNServer ................................................................................................................................ 138 B.2.8 WireShark ................................................................................................................................... 139


7

Índice de figuras

Figura 1. Arquitectura red IMS: Estructuración en Capas [F.1] ...............................................................15

Figura 2. Modelo de subscripción (HSS) ................................................................................................18

Figura 3. Trigger Points definidos ...........................................................................................................20

Figura 4. Trigger point para usuarios llamantes ......................................................................................20

Figura 5. Ejemplo de Application Server definidos en el HSS.................................................................21

Figura 6. iFCs ........................................................................................................................................22

Figura 7. Ejemplo de configuración de un iFC ........................................................................................22

Figura 8. Definición de un Service Profile ...............................................................................................23

Figura 9. Flujo de registro de un usuario IMS .........................................................................................30

Figura 10. Flujo de una llamada simple IMS – IMS .................................................................................32

Figura 11. Flujo llamada PBX_NoReg – SIP...........................................................................................35

Figura 12. Flujo llamada SIP - PBX_NoReg ...........................................................................................37

Figura 13. Routing ..................................................................................................................................41

Figura 14. Arquitectura de despliegue ....................................................................................................49

Figura 15. Arquitectura de despliegue detallada .....................................................................................51

Figura 16. Configuración disparos HSS ..................................................................................................55

Figura 17. Flujo Desvío de llamada ........................................................................................................56

Figura 18. Flujo redirección de llamada ..................................................................................................57

Figura 19. Puntos de entrada al core IMS. .............................................................................................60

Figura 20. Configuración Softphone para la RPBX Ext A .......................................................................61

Figura 21. Configuración Softphone para la RPBX Ext B .......................................................................61

Figura 22. Proceso de registro contra una PBX ......................................................................................62

Figura 23. Flujo llamada local de la PBX ................................................................................................62

Figura 24. Configuración softphone SIP A ..............................................................................................63

Figura 25. Configuración softphone SIP C ..............................................................................................63

Figura 26. Configuración softphone SIP B ..............................................................................................64

Figura 27. Configuración softphone para la UPBX Ext A .......................................................................66

Figura 29. Pantalla Nombre y Sistema Operativo ...................................................................................85

Figura 30. Pantalla Tamaño de memoria ................................................................................................86

Figura 31. Tipo de archivo de disco duro ................................................................................................87

Figura 32. Ubicación y tamaño del disco duro virtual ..............................................................................88

Figura 33. Cargar imagen iso en la unidad de CD virtual........................................................................89

Figura 34. Adaptador de red, interfaz red interna ...................................................................................90

Figura 35. Adaptador de red, interfaz con la máquina física ...................................................................90

Figura 36. PCSCF, reglas de reenvío de puertos ...................................................................................91

Figura 37. PBX, reglas de reenvío de puertos ........................................................................................91

Figura 38. HSS, reglas de reenvío de puertos ........................................................................................92

Figura 39. Orden de arranque.................................................................................................................95

Figura 40. Pestaña Services .................................................................................................................107


8

Figura 41. Pestaña User Identities ........................................................................................................108

Figura 42. IMPUs ..................................................................................................................................109

Figura 43. Definición de una pbx-reg ....................................................................................................110

Figura 44. Configuración PSI ................................................................................................................111

Figura 45. PSI para servicios originantes .............................................................................................112

Figura 46. PSI para servicios terminantes ............................................................................................112

Figura 47. Configuración de conexión a las bases de datos .................................................................114

Figura 48. Prompt usuario ims ..............................................................................................................121

Figura 49. Contenido $HOME del usuario ims ......................................................................................122

Figura 50. Contenido directorio interfacesConf .....................................................................................122

Figura 51. Contenido directorio Asterisk-AS .........................................................................................123

Figura 52. Contenido directorio Asterisk-AS/bin ...................................................................................123

Figura 53. Contenido directorio Asterisk-AS/etc ...................................................................................124

Figura 54. Contenido directorio Asterisk-PBX .......................................................................................124

Figura 55.Contenido directorio Asterisk-PBX/reg-pbx ...........................................................................125

Figura 56. Contenido directorio DNSServer ..........................................................................................126

Figura 57. Contenido directorio DNSServer/bin ....................................................................................126

Figura 58. Contenido directorio DNSServer/deploy ..............................................................................128

Figura 59. Contenido directorio DNSServer/etc ....................................................................................129

Figura 60. Contenido directorio logs .....................................................................................................129

Figura 61. Contenido directorio om .......................................................................................................130

Figura 62. Contenido directorio OpenIMSCore .....................................................................................132

Figura 63. Contenido directorio OpenIMSCore/FHoSS ........................................................................132

Figura 64. Contenido directorio OpenIMSCore/FHoSS/bin ..................................................................133

Figura 65. Contenido directorio OpenIMSCore/FHoSS/conf ................................................................133

Figura 66. Contenido directorio OpenIMSCore/X-CSCF ......................................................................133

Figura 67.Contenido directorio OpenIMSCore/X-CSCF/bin ..................................................................134

Figura 68. Contenido directorio OpenIMSCore/X-CSCF/etc .................................................................135

Figura 69. Contenido directorio OpenIMSCore/X-CSCF/etc/icscf .........................................................135

Figura 70. Contenido directorio OpenIMSCore/X-CSCF/etc/pcscf ........................................................136

Figura 71.Contenido directorio OpenIMSCore/X-CSCF/etc/scscf .........................................................136

Figura 72. Contenido directorio RTPProxy............................................................................................137

Figura 73. Contenido directorio STUNServer ........................................................................................138

Figura 74. Captura de tráfico desde WireShark ....................................................................................139

Figura 75. Configuración WireShark para decodificar Diameter ...........................................................140

Figura 76. WireShark. Ventana emergente de VoIP Calls ....................................................................141

Figura 77. Flujo VoIP Calls parte 1. ......................................................................................................142

Figura 78. Flujo Voip Calls parte 2 ........................................................................................................142

Figura 79. Flujo VoIP Calls parte 3. ......................................................................................................143


9

Lista de acrónimos

AS - Application Server

B2BUA – Back to Back User Agent

BGCF – Breakout Gateway Control

CSCF - Call Service Control Function

DTMF – Dual-Tone Multi-Frequency

HSS - Home Subscriber Server

I-CSCF - Interrogating CSCF

IMPU - IP Multimedia Public Identity

IMPI - IP Multimedia Private Identity

IMS - IP Multimedia Subsystem

IMSU – IP Multimedia Subscriber

IVR – Interactive Voice Response

LIR/LIA - Location Info Request/Answer

MAR/MAA – Multimedia Auth Request/Answer

MS – Media Server

P-CSCF - Proxy CSCF

PBX - Private Branch Exchange

PE – Presence Enabler

PRACK –Reliability of Provisional Response ACKnowledgement

PSI - Public Service Identities

SIP – Session Initiation Protocol

SBC – Session Border Controller

S-CSCF - Serving CSCF

SAR/SAA – Server Assignment Request/Answer

UAR/UAA - User Authorization Request/Answer


10

VM - Virtual Machine

VoIP - Voice Over Internet Protocol

VoLTE – Voice Over LTE


11

1 Introducción

1.1 Marco y motivación del proyecto

El proyecto se enmarca en el diseño y despliegue de un entorno de pruebas virtualizado

orientado a cubrir las necesidades docentes del estudio de redes IMS. Por otro lado, el entorno

podría ser utilizado también en un ambiente comercial como banco de pruebas para el

despliegue de nuevos nodos de la red IMS o como banco de pruebas para el despliegue de la

implementación comercial de uno o varios de los nodos ya existentes. Por tanto, estamos ante

un proyecto con dos objetivos principales.

En primer lugar, el entorno puede utilizarse para realizar llamadas de voz ip, capturar trazas

de red y realizar un análisis de dichas trazas. Lo que proporcionará una visión clara del

funcionamiento de una red IMS que respeta el estándar.

En segundo lugar, y gracias al despliegue de las herramientas en un entorno virtualizado, es

muy fácil sustituir uno de los nodos por otra implementación de dicho nodo, ya sea una

implementación comercial o de libre distribución, o, como se ha comentado anteriormente,

también hace posible la introducción de nuevos nodos para verificar su correcto

funcionamiento antes de realizar el despliegue de dichos nodos en un entorno real.

1.2 Objetivos técnicos y académicos

Los objetivos de este proyecto fin de grado son:

Profundizar en el conocimiento de las herramientas Kamalio y Asterisk. Durante la

realización del proyecto, se ha realizado una costosa labor de investigación sobre

diferentes parámetros de Kamailio y Asterisk para conseguir que éstos tuvieran el

comportamiento deseado.

Adquisición de conocimientos sobre redes virtualizadas, así como de las interfaces

necesarias para dar conectividad a la maqueta utilizada desde diferentes puntos.

Obtener un profundo conocimiento del protocolo SIP, necesario para el análisis y

búsqueda de problemas durante la integración de los diferentes nodos.

1.3 Estructura del resto de la memoria

En los próximos capítulos de esta memoria se dará información, en primer lugar, del contexto

tecnológico en el que se mueve el proyecto. Se explicará la arquitectura IMS y especialmente

del protocolo SIP. A continuación se hablará de las características principales de las

herramientas que se han utilizado para montar la maqueta de laboratorio haciendo especial


12

hincapié en las posibilidades que ofrecen, se hayan utilizado o no las mismas para la

realización del presente proyecto.

Tras comentar las herramientas utilizadas, se pasará a describir el trabajo realizado, y a

comentar con detalle la arquitectura de despliegue, para finalmente, terminar exponiendo las

conclusiones a las que se han llegado tras la realización del proyecto y ofreciendo una

pequeña lista de posibles propuestas para aumentar el alcance del laboratorio de IMS.

Finalmente se ha adjuntado un manual de usuario que será muy útil para los alumnos o

profesores que deseen utilizar el laboratorio IMSLab para estudiar y analizar llamadas de

VoIP. En este manual se detallarán los pasos a seguir para arrancar los diferentes nodos, para

configurar las máquinas virtuales de manera que tengan conectividad tanto a nivel de

transporte, a nivel SIP o a nivel de RTP y para realizar llamadas. Además se ha incluido un

pequeño manual de análisis de trazas de red, exponiendo algunas características de Wireshark.


13

2 Marco tecnológico

El gran desarrollo de Internet ha permitido la implementación de muchos servicios de gran

éxito, como las aplicaciones de mensajería, de correo electrónico, de compartición de datos,

etc. Era cuestión de tiempo que se planteara la telefonía como una aplicación más entre todas

las demás, lo que obliga a los operadores de telecomunicaciones a evolucionar hacia

operadores de servicios globales. Abandonando la idea de ser sólo proveedores de telefonía

básica a través de las antiguas redes de telecomunicaciones y convirtiéndose en proveedores

de todo tipo de servicios. Para ello, se hace imprescindible que estos operadores implementen

una red con arquitectura IMS.

2.1 IMS o IP-Multimedia Subsystem

IMS es un conjunto de especificaciones definidas por el grupo 3rd Generation Partnership

Project, las cuáles pretenden definir y estandarizar una arquitectura de red basada en

intercambio de paquetes sobre TCP/IP. Esta arquitectura de red es capaz de soportar tráfico de

voz, datos y contenidos multimedia, con independencia del medio de acceso: teléfonos

móviles, fijos; ordenadores personales; y todo dispositivo que pueda tener una dirección IP en

la red.

¿Por qué necesitamos IMS?

El campo de las telecomunicaciones ha sido un campo que durante las últimas décadas ha

crecido enormemente con cierto desorden. Cada una de las tecnologías que fueron surgiendo a

lo largo de los años fueron tecnologías adaptadas a objetivos concretos del momento. Lo

mismo ocurrió con los dispositivos que soportaban dichas tecnologías.

Por ejemplo, los teléfonos móviles fueron diseñados originalmente para establecer llamadas

con otros teléfonos móviles conectados a una red del mismo tipo, una red GSM.

Originalmente no se pensó en los teléfonos móviles, ni en la red GSM, como capaces de ser el

soporte para la transmisión de videos multimedia, sino que tanto los dispositivos como la red

GSM fueron pensados por y para la transmisión de voz. Lo mismo ocurrió con otras

tecnologías como la televisión, la radio e incluso los ordenadores personales, que

originalmente no fueron pensados para la transmisión de voz o de contenidos multimedia.

Por tanto, lo que teníamos era un conjunto de diferentes redes de comunicaciones separadas e

incapaces de comunicarse entre ellas debido a que usaban protocolos de comunicación

totalmente diferentes. En este escenario, se pensó en crear un estándar que hiciera posible la

transmisión de todo tipo de datos sobre la arquitectura más extendida hasta el momento. La

arquitectura de internet.

https://es.wikipedia.org/wiki/3GPP

https://es.wikipedia.org/wiki/3GPP


14

Con IMS es posible ofrecer todo tipo de servicios, tanto servicios de voz como servicios

multimedia o de datos, en una única plataforma accesible desde cualquier medio (ya sea

fijo o móvil) con conexión a internet y que sea capaz de iniciar una sesión mediante

protocolo SIP (Session Initation Protocol).

Además de crear una arquitectura de red de esta índole, con el paso de los años, el grupo

3GPP ha ido añadiendo diferentes normas y estándares a IMS, los cuáles hacen posible

la comunicación de la red IMS con redes específicas, como son la red GSM, UMTS,

GPRS, RDSI, etc. Por tanto, IMS no es sólo una red, sino que es una arquitectura de red

donde están incluidos nodos de inter-conexión con otras redes. Esto hace posible, que

los diferentes dispositivos puedan aprovechar las prestaciones de los servicios ofrecidos

por la red IMS aun estando conectados a otra red.

2.1.1 Estructuración en Capas de la arquitectura IMS

La red IMS puede ser dividida en varias capas funcionales, teniendo en cuenta la

diferente funcionalidad de cada una de ellas:

- La capa de acceso: a esta capa, pertenecen los nodos destinados al acceso (de alta

velocidad) de los diferentes dispositivos a la red IMS.

- La capa de transporte: es una red IP, y como tal, puede contener diferentes

mecanismos de seguridad o de calidad de servicios. Está compuesta por diferentes

encaminadores o routers unidos entre sí por una red de transmisión. Esta red de

transmisión puede ser de diferente naturaleza.

- La capa de control: esta capa es la realmente relevante a nivel IMS. Las dos

anteriores no son específicas de IMS, sino que son comunes a otras redes. Esta

capa está compuesta por una serie de nodos encargados del enrutamiento de la

señalización SIP entre usuarios y de la invocación de servicios. Estos nodos se

denominan “Call State Control Function” o CSCF.

- La capa de aplicación: a esta capa pertenecen aquellos nodos destinados a

proporcionar los servicios de valor agregado a los usuarios. Pertenecen a esta capa

los Servidores de aplicaciones (AS, Application Server) o los servidores de Media

IP (MRF, Multimedia Resource Function).

Esta división en capas, y el hecho de que los servidores de CSCF o S-CSCF puedan ser

asignados de manera dinámica a los usuarios, hace posible que las redes IMS sean

totalmente escalables e independientes del nivel de tráfico.

La siguiente figura muestra la estructura de capas descripta anteriormente.


15

Otras redes IMS

PTSN/GSM

IPv4/IPv6

Capa de Control o núcleo IMS

Capa de Aplicación

IPv4 externa

IPv6 externa

BG

S-CSCF I-CSCF

P-CSCF

BGCF

MGCFSGW

IMS-MGW

BGCF

HSS

IMS

CSCF

ASs

Capas de Acceso/Transporte

UMTS/GPRS

GGSN

SGSN

Figura 1. Arquitectura red IMS: Estructuración en Capas

2.1.2 La capa de control (Call State Control Function)

Como se ha mencionado anteriormente, la capa más interesante de la arquitectura IMS es la

capa de control. Esta capa está formada por una serie de nodos capaces de interpretar el

protocolo SIP. Esta capa se puede dividir en el CSCF (Call State Control Function) o núcleo

de red IMS, y en una serie de nodos adicionales que sirven de interconexión con otras redes.

El núcleo de red IMS o CSCF está formado por tres diferentes tipos de nodos

interconectados, los cuáles son considerados el centro neurálgico de la red IMS y son los

responsables de controlar todo el tráfico de sesiones existentes en la red:

- PCSCF o Proxy CSCF es el punto de acceso para los usuarios de la red IMS. Por

tanto, todo tráfico de señalización SIP desde los UAs (User Agents) será enviado a

través de este nodo. De igual manera, todos los mensajes SIP hacia el usuario o

UA se enviarán desde el PCSCF.


16

Durante el proceso de registro, el usuario se registra a través de un PCSCF

en la red IMS, y éste queda asignado a dicho usuario durante todo el proceso

(Ver Figura 9. Flujo de registro de un usuario IMS).

- ICSCF o Interrogating CSCF es un proxy SIP situado al borde de un

dominio administrativo, siendo el nodo de interconexión entre varios

dominios administrativos dentro de la misma red IMS o siendo el nodo de

interconexión entre diferentes redes IMS. La dirección del ICSCF debe estar

contenida en el DNS Server, de manera que debe ser accesible desde

cualquier punto de la red.

- SCSCF o Serving CSCF es el nodo más importante por ser el responsable de

los procesos de registro, de aplicar la lógica de enrutamiento, de mantener

los estados de la sesión y de recuperar (del HSS) los perfiles de los abonados

y aplicarlos.

- Adicionalmente a estos nodos, hay otro, que a pesar de no ser estrictamente

un nodo perteneciente al CSCF sí está muy ligado al núcleo de red. Hasta el

punto de ser considerado parte de él. Se trata del Home Subscriber Server o

HSS. Este nodo es considerado una evolución del HLR o Home Location

Register utilizado en la red GSM, aunque también implementa la

funcionalidad del AuC (Autentication Centre). Básicamente es una base de

datos que sirve como repositorio central de datos relacionada con el usuario.

Estos datos incluyen, entre otras cosas, información de ubicación, de

seguridad (como la información de autenticación), información del perfil de

usuario incluyendo los servicios que el usuario tiene contratados y el

S-CSCF asignado al usuario ( Para más información ver Modelo de

subscripción)

Como se ha comentado antes, además de los nodos considerados núcleo de red

IMS, existen una serie de nodos adicionales responsables de la interconexión con

otras redes.

- MGCF o Media Gateway Control Function es el nodo encargado de realizar las

conversiones entre el protocolo SIP, parte de la arquitectura IMS, y el protocolo

ISUP (ISDN User Part), parte de la arquitectura de circuitos conmutados típica en la

telefonía convencional. El MGCF no sólo es capaz de hacer la traducción entre los

protocolos de señalización de las redes de circuitos y la red IMS, sino que también es

el encargado de realizar la conversión del audio. Es decir, es capaz de transformar el

audio proveniente de la red IMS sobre protocolo RTP y transformarla en uno o más

PCM (Pulse Code Modulation) para conectarse a la red de circuitos, y viceversa. En

este nodo también se produce cualquier tipo de transformación en los códecs de

audio cuando ambos terminales, terminal IMS y terminal de circuitos, no soportan

códecs compatibles.


17

- BGCF o Breakout Gateway Control Function es un proxy SIP encargado de enrutar

llamadas desde un Serving CSCF cuando éste ha determinado que la sesión no puede ser

enrutada en base a un ENUM. Es decir, cuando el Serving CSCF no es capaz de enrutar la

llamada utilizando el plan de numeración contenido en el ENUM, enrutará la llamada a

este nodo. En este nodo se aplica funcionalidad de enrutado en base a números de teléfono.

2.1.3 Modelo de subscripción (HSS)

La información contenida en el HSS es muy diversa, sin embargo, es necesario hacer especial

hincapié en la información de subscripción del usuario. Esta información es la

correspondiente a cuatro datos importantes. Cada usuario tendrá asociada una IMSU (IMS

Subscription), una IMPI (IP Multimedia Private Identity), una o varias IMPUs (IP Multimedia

Public Identity) y un perfil de servicios o Service Profile. Dicho Service Profile contendrá los

servicios que hay que disparar para el usuario.

2.1.3.1 Identidades de usuario

En cuanto a las identidades de usuario, es importante conocer al menos, dos de las identidades

de usuario que se manejan en las redes IMS:

- IMPI o IP Multimedia Private Identity es la identidad asignada por el operador de red

local. Es única y permanente, de manera que un usuario sólo puede tener un única IMPI.

Se utiliza, por ejemplo, en el proceso de registro o en la petición de autorización. Es

como el identificador del usuario.

- IMPU o IP Multimedia Public Identity es una identidad por la que se puede llamar al

usuario. Una IMPI puede tener varias IMPUs asociadas, pero una IMPU puede estar

asociada a varias IMPIs, como ocurriría por ejemplo en el caso de un mismo número de

teléfono para toda una familia.

Ambas, IMPI e IMPU no son números de teléfono o series de dígitos, sino que son URIs o

Uniform Resource Identifier, las cuáles pueden ser de dos tipos, Tel URI si contienen dígitos,

como por ejemplo tel:+917968546, o SIP URI, si está formada de caracteres alfanuméricos,

como por ejemplo sip:[email protected].

En la Figura 2. Modelo de subscripción (HSS) se ha intentado representar la relación entre

estos cuatro elementos con un ejemplo gráfico, nótese la compartición de una de las IMPUs

entre los dos usuarios, usuario A y usuario B.

tel:+917968546

sip:[email protected]


18

IMSU_A IMPI_A

IMPU_A1

IMPU_A2

IMPU_A3 e IMPU_B1

IMSU_B IMPI_B IMPU_B2

IMPU_B3

Service Profile (SP)

Figura 2. Modelo de subscripción (HSS)

Lo explicado anteriormente hace referencia a las identidades de usuario. A continuación

se explicará el modo en el que dichas identidades quedan asociadas a un perfil de

usuario.

2.1.3.2 Initial Filter Criteria

El initial filter criteria o iFC es un elemento utilizado para almacenar la información

relativa a la subscripción de un usuario a una aplicación concreta. Los iFCs asociados a

un usuario se almacenan en el HSS y son descargadas por el S-CSCF en el proceso de

registro (Ver Figura 9. Flujo de registro de un usuario IMS) mediante una petición SAR

(Server-Assignment-Request). Tanto las identidades de usuario como los iFCs

asociados al usuario son enviados por el HSS al S-CSCF en el mensaje SAA (Server-

Assignment-Answer) en un el AVP User-Data (606) en forma de xml.

En el caso de los usuarios no registrados, la petición SAR no se realiza en el proceso de

registro debido a su inexistencia. En este caso, la petición SAR se realizará bajo

demanda provocado por una PSI (Public Service Identity) contenida en la Request URI

de un mensaje INVITE entrante al S-CSCF.


19

En cualquiera de los dos casos un iFC está compuesto de los siguientes campos:

- Priority: determina el orden en el que serán aplicados los diferentes iFC a un usuario

- Triggers Points: es un conjunto de condiciones que determinan si el iFC aplica o no

para el usuario. El trigger point se evaluará en tiempo real sobre los mensajes SIP

que inician un diálogo.

- Application Server Uri: Contiene la Uri que será añadida en la cabecera Route (por

tanto se utilizará loose Route (ver punto 2.1.4.6 Routing) para el enrutado) cuando la

evaluación de los triggers point determine que aplica el servicio.

Hay dos tipos de iFCs:

Shared o compartidos: La diferencia radica en que sólo un número identificativo es

asignado al usuario durante la provisión. Durante el proceso de registro (o en la

petición bajo demanda para el caso de usuarios no registrado) sólo se envía al S-

CSCF este número identificativo, no el XML completo con toda la provisión. Dicho

XML completo se carga en el S-CSCF al ser provisionado, por lo que ya está

cargado en el S-CSCF cuando el registro se realiza. Es preferible, no utilizar este tipo

de iFCs salvo en casos muy específicos, porque sobrecargamos la memoria interna

del S-CSCF cargando en memoria todos los iFCs de este tipo cuando quizás no haya

ningún usuario que los vaya a utilizar.

Non-shared o no compartidos: En este caso, el XML con toda la provisión se asocia

al usuario durante la provisión. Durante el proceso de registro (o en la petición bajo

demanda para el caso de usuarios no registrados) se envía al S-CSCF el XML

completo con toda la provisión en el mensaje SAA.

En nuestro despliegue sólo vamos a utilizar los iFCs Non-Shared, aunque podrían ser

utilizados los iFCs shared puesto que son soportados por el HSS de Fokus.

Para clarificar todo esto, a continuación se muestra a modo de ejemplo, parte de la

configuración que se ha definido en el HSS de Fokus.

- En primer lugar, se requiere establecer uno o varios trigger points. Como mínimo es

recomendable definir al menos dos, salvo que se quieran prestar servicios sólo

servicios terminantes o sólo servicios originantes. Como no es el caso que nos ocupa,

sería recomendable definir dos trigger points diferentes:


20

Figura 3. Trigger Points definidos

Uno para usuarios originantes y otro para usuarios terminantes. Esto es necesario para

determinar qué servicios serán proporcionados para usuarios originadores de la

llamada y qué servicios serán proporcionados para usuarios llamados.

A continuación se muestra la configuración de uno de ellos a modo de ejemplo.

Figura 4. Trigger point para usuarios llamantes

Como se puede apreciar en la Figura 4, en este punto se definen como condición para que

este trigger point aplique que el S-CSCF se encuentre aplicando la lógica originante


21

(Origin Session) y que el mensaje que se esté tratando sea un mensaje INVITE o un

CANCEL.

Sería en este punto donde deberíamos añadir cualquier otra condición, por ejemplo, si el

contenido de una cabecera del mensaje es condición para que se dé un servicio o no, lo

incluiríamos aquí. En la Figura 4. Trigger point para usuarios llamantes se ha añadido, a

modo de ejemplo, la cabecera P-Access-Network-Info con un valor como

condición para que se aplique el iFC al que esté asociado este trigger point. En este caso,

significaría que sólo los usuarios que hayan sido disparados desde una red externa a la red

IMSLab, usuarios provenientes de la red de circuitos y que estén conectados a través de

una celda concreta disfrutarían de este servicio.

- En segundo lugar, debemos definir los Servidores de Aplicaciones. En este punto, no sólo

se definen los servidores de aplicaciones que se van a disparar, sino que además se

establecerán los triggers. Por tanto, tendremos que definir tantos ASs como triggers deban

ser ejecutados.

En la Figura 5. Ejemplo de Application Server definidos en el HSS se muestra un

ejemplo de esto:

Figura 5. Ejemplo de Application Server definidos en el HSS

Como se puede ver en la Figura 5. Ejemplo de Application Server definidos en el HSS, se

han definido 4 servidores de aplicaciones. Este elemento, a pesar de denominarse

Application Server, no se corresponde con el Application Server de la red IMS, en cuanto

a que aquí tenemos sólo un nodo AS y sin embargo estamos definiendo cuatro diferentes

Application Server en el HSS.

Definimos un Application Server por cada trigger diferente que queramos disparar contra

el nodo AS.


22

- Finalmente, una vez definidos los Application Server y los trigger points, ya estamos

en disposición de definir un iFC.

En la Figura 6. iFCs podemos observar cómo se han definido cuatro iFCs diferentes.

Dos originantes y dos terminantes, es decir, dos asociados al trigger point originating

y dos asociados al trigger point terminating.

Igualmente, dos para usuarios registrados y los otros dos para usuarios no

registrados.

Figura 6. iFCs

En la Figura 7. Ejemplo de configuración de un iFC se muestra la definición de uno

de los iFCs mostrados en la Figura 5. Ejemplo de Application Server definidos en el

HSS. Como se puede apreciar, en el iFC es donde se asocia un Application Server

determinado con un trigger point.

Figura 7. Ejemplo de configuración de un iFC


23

- Finalmente, aunque no forme parte de la configuración de un iFC, es interesante mostrar el

elemento que agrupa los iFCs para ser asociados a un usuario, más concretamente a un

IMPU.

Estamos hablando del Service Profile. El service profile es un elemento que permite

asociar iFCs y darles una prioridad. En la Figura 8. Definición de un Service Profile se

muestra la definición un Service Profile, el cuál agrupa dos iFCs.

Figura 8. Definición de un Service Profile

Es el service profile lo que se asocia a los usuarios, concretamente se asocia a las IMPUs.

De esta manera un usuario tendrá asociado un service profile, el cual tendrá asociados uno

o varios iFCs. Cuando un mensaje SIP llega el S-CSCF se ejecutará lógica originante o

lógica terminante según corresponda (Ver puntos 2.1.4.3 Flujo de llamada simple, 2.1.4.4

Flujo de una llamada desde un usuario no registrado y 2.1.4.5 Flujo de una llamada a un

usuario no registrado).

Durante la ejecución de la lógica originante, se comprueba (analizando los trigger points de

cada iFC) para el usuario originador de la llamada (usuario contenido en la cabecera P-

Asserted-Identity o From en su defecto) si algún iFC de los contenidos en su service

profile aplica. Si es así se ejecuta hasta que se han ejecutado todos los que apliquen. En

este caso, sólo aplicaría el primero, puesto que estamos ejecutando lógica originante.

Una vez se han terminado de ejecutar todos los iFCs para el usuario originador de la

llamada, el S-CSCF pasará a ejecutar la lógica terminante. En este punto, y sobre el

Service Profile del usuario llamado (usuario contenido en la Request-Uri), se comprobará

si aplica alguno de los iFCs del usuario llamado, analizando los trigger points asociados a

cada iFC.


24

2.1.4 SIP (Session Initation Procotocol)

El protocolo SIP es el protocolo utilizado en el nivel de control o en el núcleo de las

redes IMS. Este protocolo permite el establecimiento, modificación y liberación de las

sesiones multimedia. Sería el equivalente a los protocolos ISUP (ISDN User Part) e

INAP (Intelligent Network User Part) del mundo de la telefonía. El protocolo SIP se

apoya en un modelo basado en transacciones en arquitectura cliente/servidor. Para cada

una de estas transacciones existe una entidad SIP que genera peticiones y que cumple el

rol de cliente y otra entidad SIP que recibe las peticiones y devuelve respuestas, en este

caso cumpliendo el rol de servidor. No es necesario apuntar, que una misma entidad SIP

puede cubrir el rol de cliente para una transacción mientras que cubre el rol de servidor

en otra transacción. Es el caso de un SIP Proxy. Entra en juego, en este punto, la

definición de transacción o diálogo SIP, haciendo referencia a una petición y al

conjunto de respuestas que origina dicha petición.

Una transacción o diálogo se establece a través del envío de un mensaje SIP, un mensaje

INVITE. Este mensaje es el único que utiliza un protocolo de tres vías (INVITE – 200

OK – ACK) en lugar de dos. De manera que este mensaje es el único cuyo 200 OK de

respuesta generará el envío de un ACK en el cliente. En los puntos 0 y 0 se explicará

brevemente pero más en detalle un proceso de registro y el flujo de una llamada SIP

simple.

2.1.4.1 Formato de los mensajes SIP

El protocolo SIP es un protocolo basado en texto, lo que lo hace muy manejable para

clientes externos a la red, ya que además, éstos pueden incluir información no estándar.

Como se ha comentado anteriormente, existen dos tipos de mensajes SIP. Las peticiones

y las respuestas.

- Una petición o Request siempre consta de varias líneas de texto. La primera de ellas

se denomina Request-Line y es de este tipo:

INVITE sip:[email protected] SIP/2.0

En esta primera línea siempre nos encontraremos con los siguientes campos:

Method Request-Uri SIP-Version

El campo denominado method indica el tipo de petición. A continuación se

muestran algunos de los métodos disponibles. Existen otros métodos SIP

disponibles, sin embargo, se ha preferido no incluirlos puesto que no se van a

utilizar en el despliegue actual.


25

Método Descripción

INVITE Como su propio nombre indica, su propósito es la

de invitar al usuario llamado a participar en una

sesión

REGISTER Este mensaje es enviado por los agentes SIP para

indicar a la red IMS de su localización

ACK El mensaje ACK se envía para indicar que se ha

recibido la respuesta final a un INVITE.

CANCEL El mensaje SIP Cancel se envía para cancelar

todas las transacciones que haya pendientes

BYE Permite a los usuarios abandonar la sesión en

curso

OPTIONS Este mensaje se utiliza como keep-alive para

comprobar la comunicación entre diferentes

nodos. Se puede utilizar también para consultar

las capacidades de un servidor. Por ejemplo, los

métodos que admite, el SDP, etc.

SUBSCRIBE Este mensaje se utiliza para solicitar la

subscrición a la presencia de un usuario.

Habitualmente, sólo se permite la subscrición a la

presencia del propio usuario.

Tabla 1. Métodos SIP

Por otro lado, el campo denominado Request-URI, contiene la información sobre el

usuario al que va dirigida la petición. La Request-URI es del tipo URI y contiene o puede

contener las siguientes partes:

Parte de usuario

Dominio o dirección IP y puerto

Parámetros de usuario

Parámetros de la URI

Dependiendo de qué tipo de URI sea, algunos de las partes comentadas anteriores no son

posibles, por ejemplo, en el caso de una TelURI (numérica) no es posible que contenga

ningún tipo de parámetro, ni tampoco un dominio. Es decir, según el tipo de URI:

SipURI:

sip:User-Part[;userParam1=value1;userParam2=value2….]@Dominio/IP-

Addres:puerto[uriParam1=value1;uriParam1=value2….]

TelURI:

tel: User-Part


26

En el caso de la TelURI, a pesar de ser una uri de tipo numérico, es posible que sea

Global, lo que permitiría que el usuario estuviera expresado en formato

internacional con el carácter ‘+’ por delante.

- Una respuesta o Response podemos decir que también consta de varias líneas de

texto, y que la primera línea, en este caso será del siguiente tipo:

SIP/2.0 100 Trying

En este caso, en la primera línea siempre nos encontraremos con los siguientes

campos:

SIP-Version Status-Code Reason-phase

Cada respuesta tiene un código que indica el estado de la transacción, es el Status-

Code. Hay códigos estándares que representan mensajes estándares y hay una serie

de códigos que se han dejado sin definir para poder ser utilizados como códigos en

los diferentes servidores de aplicaciones, y que por tanto, tendrán un significado

diferente en cada red. A continuación se muestra una tabla donde se especifican por

rangos los códigos utilizados.

Código Tipo

100-199 Informativo, como por ejemplo el 180 Ringing o el 100 Trying.

200-299 Respuesta de éxito, como por ejemplo el 200 OK

300-399 Este rango indica que ha habido una redirección. Por ejemplo,

en el caso del 301 indica que la solicitud original URI ya no es

válida y la nueva dirección se da en la cabecera de Contacto.

400-499 Este código de respuesta indica un error de cliente, como por

ejemplo, 404 Not Found, que indica que el usuario no ha sido

encontrado.

500-599 Este código de respuesta indica un error en el servidor, como

por ejemplo, el 503 Unavailable Service.

600-699 Este código de respuesta indica un fallo general

Tabla 2. Definición Respuestas SIP por rango

Además de la primera línea, que difiere entre peticiones y respuestas, existen una

serie de elementos comunes a todos los mensajes SIP. Estos son las cabeceras o

Headers.


27

Los elementos de la red IMS realizan las operaciones en base al análisis de las cabeceras

contenidas en los mensajes recibidos y eliminando o modificando algunas de ellas en los

mensajes enviados. Por tanto, cuando un elemento de la red IMS recibe un mensaje SIP,

analizará todas o algunas de las cabeceras (las que sean de interés dependiendo de la

funcionalidad que cubra dicho elemento) y según ese análisis realizará alguna acción, como

por ejemplo enviar un mensaje Diameter al HSS para que almacene la información de registro

(es el caso del mensaje REGISTER entrante en el SCSCF). Tras realizar las operaciones que

tenga que realizar, progresará el mensaje añadiendo, modificando o eliminando las cabeceras

oportunas (si dicho elemento funciona como un proxy) o creará una nueva sesión (si dicho

elemento funciona como un B2BUA) y enviará otro mensaje por la nueva sesión, copiando en

el nuevo mensaje las cabeceras oportunas procedentes del mensaje recibido.

Cuando el rol que cumple el elemento es el de un B2BUA, a veces, un mensaje recibido no

genera un mensaje enviado, sino que dicho mensaje es bloqueado. Es la principal diferencia

entre un Proxy SIP y un B2BUA.

Centrándonos en las cabeceras SIP, hay que decir que hay muchas cabeceras definidas en el

estándar de SIP y otras para las que se han añadido nuevas RFCs al estándar. En cualquiera de

los dos casos, estas cabeceras son consideradas estándar y su comportamiento, o mejor dicho,

el comportamiento que provocan en los elementos de una red IMS está definido en el

estándar. Sin embargo, como se ha comentado anteriormente, los elementos de una red IMS, o

incluso clientes externos, pueden añadir información no estándar. La manera de hacerlo es

incluyendo cabeceras propietarias. De manera que entre dos elementos de una red, es posible

acordar un comportamiento en base a una cabecera propietaria recibida. Esto hace que las

posibilidades del protocolo sean infinitas.

Dicho esto, a continuación se muestra una tabla con algunas de las cabeceras estándar más

utilizadas, y de las cuáles se ha hecho uso durante la elaboración del proyecto, y su

descripción.

Cabecera Descripción

Request-URI Es una URI que indica la identidad del destinatario del mensaje. No

es una cabecera como tal, sino que es parte de la Request-Line

From Es una URI que indica la identidad del remitente del mensaje.

Puede contener cualquier información que el remitente quiera y por

ello, a menudo se utiliza para indicar qué se debe mostrar al

destinatario final del mensaje.

P-Asserted-Identity Es una URI que indica la identidad del remitente del mensaje. Es

introducida por el PCSCF. La identidad que contiene tiene que ser

una IMPU registrada.

P-Served-User Es una URI utilizada para indicar a los servidores de aplicaciones a

quién debe darle servicio.

To Es una URI que contiene la identidad del destinatario del mensaje.

Sin embargo, esta cabecera es meramente informativa y no es

utilizada para encaminar la llamada, ya que puede contener

cualquier información que elija el remitente.


28

Contact Es una URI utilizada para hacer accesible servidores de manera

directa, sin estar incluidos en la ruta de señalización. Los servidores

de aplicaciones suelen incluír su dirección ip y puerto en la

cabecera Contact de la nueva sesión.

Via La cabecera vía contiene todos los elementos proxy por los que

pasa una petición. Es responsabilidad de cada proxy añadirse al Via

como si de una cola LIFO se tratara (en la parte superior). De

manera que el último en incluirse será el primero en consumirse.

Una vez la respuesta a dicha petición se envíe, se hará consumiendo

dichas cabeceras Vía. Cada vez que una respuesta llega a un proxy,

éste elimina su dirección de la cabecera Via, dejando que la

dirección ip del siguiente salto quede en la parte superior, y utiliza

dicha dirección para enrutar la respuesta. Esto garantiza que las

respuestas siguen el mismo camino que siguió la petición.

Route Esta cabecera fuerza el enrutamiento de una petición a través de una

lista de nodos contenida en esta cabecera y predefinida. Cuando un

proxy recibe una petición con cabeceras route, eliminará su

dirección de la lista y la siguiente pasará a la parte superior y será

utilizada para enrutar. Este procedimiento se denomina Loose Route

(Ver 0).

Record-Route Esta cabecera es utilizada por los elementos proxy cuando quieren

forzar que todas las peticiones pertenecientes a la misma sesión

sean enviadas hacia ellos. Por ejemplo, el SCSCF incluye una

cabecera Record-Route en el mensaje INVITE inicial, para forzar

que tanto los ACKs como los mensajes BYEs como los mensajes

Re-INVITEs sean encaminados hacia él.

Path Esta cabecera es utilizada para forzar a que todas las peticiones sean

cursadas a través de un nodo. Es utilizada, por ejemplo, por el

PCSCF, que añade esta cabecera en el mensaje REGISTER

forzando al SCSCF a encaminar todo el tráfico terminante a través

del PCSCF, en lugar de enrutar el tráfico directamente del SCSCF

al usuario final. Esto es necesario debido a que la lógica de NAT se

ejecuta en el PCSCF, por tanto, si el usuario final está detrás de

NAT no sería alcanzable por el SCSCF.

CallID Es un identificador único de la sesión. Los elementos que funcionan

como proxy no modifican su valor, sin embargo, aquellos

elementos que funcionan como B2BUA, como es el caso de los

servidores de aplicaciones, generarán un nuevo CallID para la

nueva sesión. Todos los mensajes SIP pertenecientes a una misma

sesión (originada mediante un mensaje INVITE) contendrán el

mismo callID.

Tabla 3. Cabeceras SIP


29

2.1.4.2 Proceso de registro

Lo primero que un usuario debe hacer si quiere acceder a los servicios de una red IMS es

proceder a registrarse en dicha red. En el proceso de registro todos los nodos del núcleo de red

IMS están involucrados. El registro es necesario puesto que es la manera de indicar a la red

IMS la localización de cada usuario.

Debido a estar restricción, se terminó por incluir la definición de las PSIs o Public Service

Identities. Como su nombre indica, estas identidades, son identidades asociadas a los

servicios, no a los usuarios. Mediante la definición de este tipo de identidades se hace posible

la ejecución de los servicios asociados a ellas y no la ejecución de los servicios asociados a un

usuario en concreto. Por tanto, aunque el proceso de registro es totalmente necesario para la

ejecución de servicios IMS de una manera pura, más adelante se detallará la ejecución de

servicios en base a PSIs, y en ese caso, se verá como el proceso de Registro no se produce.

Siguiendo con el caso en el que es necesario el proceso de registro, vemos que cuando el

dispositivo del usuario envía dicha solicitud de registro, ésta se encamina a través del PCSCF

a un Serving. Sólo en el caso de que se hayan desplegado varios SCSCFs en la red local del

usuario será necesario encaminar la llamada hacia un ICSCF para descubrir el Serving que

dará servicio al usuario. En este caso, el ICSCF realizará una consulta de localización (UAR)

al HSS. El Interrogating, con la información contenida en la respuesta a la consulta de

localización (UAA) es capaz de encaminar la llamada hacia un Serving concreto, responsable

de dar servicio al usuario. Esta arquitectura es a menudo desplegada en entornos de

producción para balancear la carga entre varios S-CSCF y para ser tolerantes antes fallos de

caída de los nodos.

Finalmente, cuando la solicitud de registro llega a un SCSCF, éste se descarga los datos de

autenticación del HSS a través de una petición MAR (Multimedia Authentication Request). Y

con la información contenida en la respuesta MAA, el SCSCF rechaza este primer registro

indicándole al usuario los datos que necesita incluir en la petición para que ésta sea validada.

El usuario, al recibir este primer rechazo vuelve a intentarlo, en este caso incluyendo una

cabecera Digest en el mensaje de registro, indicando en esta cabecera los datos que le han sido

pedidos.

En este caso, este mensaje REGISTER no viajará a través del ICSCF, puesto que ya se sabe el

Serving que dará servicio al usuario. Por lo que la llamada será encaminada directamente

hacia dicho Serving. Cuando este segundo mensaje REGISTER con la cabecera Digest llega

al S-CSCF, la petición que se realiza al HSS es una petición de asignación de Serving, es

decir, en este caso, y mediante esta petición se autentifica al usuario, y si todo va bien en el

HSS, el usuario y el Serving quedarán asociados hasta que se produzca un nuevo registro por

parte del usuario. Además de autentificar al usuario, esa petición SAR hace que se descargue

el perfil del usuario al S-CSCF, de esta manera el perfil estará disponible para ser aplicado. Y

a partir de este momento, se puede considerar el usuario registrado y el SCSCF comienza a

supervisar el estado del registro. Además, a partir de este momento, el usuario es capaz de

iniciar y recibir llamadas. A continuación se muestra gráficamente lo que se ha comentado.


30

SIP Phone A P-CSCF S-CSCF I-CSCF HSS

(1)REGISTER

(2)REGISTER

(5)REGISTER

(3)Diameter UAR

(4)Diameter UAA

(6)Diameter MAR

(7)Diameter MAA

(8) 401 Unauthorized(9) 401

Unauthorized(10) 401 Unauthorized

(11)REGISTER

(12)REGISTER

(13)Diameter SAR

(14)Diameter SAA

(15) 200 OK

(16) 200 OK

(17) 200 OK

Figura 9. Flujo de registro de un usuario IMS


31

2.1.4.3 Flujo de llamada simple

Una vez un usuario de una red IMS está registrado, ya está en disposición de invitar a otro

usuario a establecer una llamada. Para ello, el dispositivo que inicia la llamada enviará un

mensaje INVITE a la IP y puerto que se haya configurado como proxy, en este caso la

ip/puerto del PCSCF. Por lo que el mensaje INVITE entrará en la red IMS a través del

PCSCF. Cada uno de los nodos del core de red o CSCF enviará un mensaje de respuesta

provisional 100 Trying para indicar que ha recibido el mensaje pero sin dar una respuesta

definitiva. En este punto ocurre lo mismo que con el mensaje REGISTER, si en la red local

sólo existe un SCSCF el mensaje será encaminado hacia él, si no es así, el mensaje se

encaminará hacia el ICSCF local, el cuál determinará qué SCSCF dará servicio al usuario.

En la Figura 10, se ha supuesto que sólo hay un SCSCF en la red local, por este motivo el

INVITE es encaminado directamente hacia el Serving local.

Al llegar el mensaje INVITE al SCSCF se ejecuta lógica originante, eso es así debido a que el

Proxy introduce una marca en el mensaje INVITE para indicar el SCSCF que debe ejecutar

lógica originante, de no ser así, el SCSCF ejecutaría por defecto lógica terminante. En el caso

de kamailio, el PCSCF introduce una cabecera Route con la partícula orig como usuario de la

URI, es decir, Route: sip:[email protected]:6060;lr. Esta cabecera le indica al

Serving, que debe ejecutar lógica originante sobre el usuario contenido en la cabecera

P-Asserted-Identity.

La lógica originante que se aplica se reduce básicamente a recuperar de memoria el service

profile almacenado para el usuario en el proceso de registro (iFCs contenidos en el mensaje

SAA) y comprobar las condiciones del trigger point asociado a cada iFC del service profile.

El SCSCF crea una lista con todos los iFCs que aplican, es decir cuyos trigger points han

determinado que deben aplicar. Una vez creada la lista, se ejecutará cada iFC según el orden

de prioridad de manera secuencial.

Esto generará, en nuestro escenario, un disparo al Servidor de aplicaciones, en este punto nos

estamos refiriendo al disparo de los servicios originantes. El SCSCF se encarga de añadir en

el mensaje INVITE saliente del core IMS la cabecera P-Served-User con el usuario

originador de la llamada, de este modo le indica al servidor de aplicaciones a quién debe dar

servicio.

Por otro lado, el mensaje INVITE entrante en el servidor de aplicaciones contendrá dos

cabeceras Route, la primera contendrá la dirección ip y puerto del servidor de aplicaciones

junto con alguna marca que indique si hay que prestar servicios originantes o terminantes si

fuera necesario. La segunda cabecera Route será la cabecera utilizada para encaminar el

mensaje INVITE de vuelta. Es decir, en los servidores de aplicaciones se suele utilizar un

método para enrutar las llamadas denominado “loose route” (Ver 0). Este método consiste en

eliminar la primera cabecera Route y utilizar la segunda para enrutar. Para utilizar este

método, es necesario que el elemento anterior indique dos cabeceras route, la primera será la

sip:[email protected]:6060;lr


32

que ha llevado el mensaje INVITE hasta este nodo utilizando el mismo método y la segunda

será el siguiente destino.

En este caso, el SCSCF se encarga de introducir las dos cabeceras, la cabecera Route que

enruta la llamada hacia el servidor de aplicaciones y la segunda cabecera Route con la propia

dirección ip y puerto del SCSCF. Por tanto, una vez ejecutados los servicios originantes, el

servidor de aplicaciones progresará el mensaje INVITE y lo enviará de vuelta al Serving.

SIP Phone A P-CSCF Home S-CSCF HSSSIP Phone BRemote

S-CSCFRemoteP-CSCF

Home AS Remote ASRemote I-CSCF

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

ACK

ACK

ACK

ACK

ACK

ACKACK

Diameter LIR

Diameter LIA

Figura 10. Flujo de una llamada simple IMS – IMS


33

Ya en el SCSCF se seguirán aplicando todos los iFCs de la lista formada en el paso anterior

hasta que todos los iFCs de la lista hayan sido ejecutados, en nuestro caso sólo tenemos un

iFC originanting, por lo que la lista habrá finalizado tras el disparo del trigger originating. En

este punto se encaminará la llamada hacia el ICSCF, que será quién determinará, mediante

una consulta de localización (LIR) al HSS, cuál es el SCSCF de la red remota que tratará la

llamada, y finalmente, el mensaje INVITE será encaminado hacia dicho SCSCF. En este

punto, el SCSCF remoto ejecutará la lógica terminante para el usuario contenido en la

Request-Uri. Dicha lógica es análoga a la lógica originante en cuanto a que se recupera de

memoria el service profile durante el proceso de registro de la entidad llamada y se evalúan

los iFCs del usuario llamado. Nuevamente se creará una lista con los iFCs que aplican para el

usuario llamado y se procederá a ejecutar cada uno de los iFCs.

Esto generará el disparo de los servicios terminantes sobre el servidor de aplicaciones. En este

caso, también es responsabilidad del SCSCF añadir la cabecera P-Served-User conteniendo,

en este caso, al usuario llamado (Request-Uri) y, también, introducir dos cabeceras Route para

que el mensaje INVITE pueda ser enrutado mediante el método de “loose route” (Ver 0).

Nuevamente, una vez ejecutados los servicios terminantes en el servidor de aplicaciones, éste

encamina la llamada de vuelta al Serving, quién continuará con la ejecución de la lista de iFCs

cargada anteriormente. Nuevamente, en nuestro caso, esta lista sólo contiene un iFC

terminante, por lo que la lista finalizará con el disparo de los servicios terminating. Una vez,

todos los iFCs de la lista han sido ejecutados, la llamada termina siendo enrutada hacia el

PCSCF al que está conectado el dispositivo llamado, y desde aquí, la llamada será finalmente

encaminada hacia éste.

Cuando el dispositivo llamado recibe la invitación de llamada a través de un mensaje

INVITE, responde con una respuesta provisional 180 Ringing, la cual es procesada hasta el

dispositivo originador de la llamada. Cuando el usuario llamado descuelga la llamada

aceptando la invitación, un mensaje de respuesta final 200 OK es enviado hacia el dispositivo

originador de la llamada aceptando la invitación.

Finalmente, el dispositivo originador de la llamada envía una petición ACK indicando que ha

recibido la respuesta 200 OK al mensaje INVITE. A partir de este momento la llamada queda

establecida entre el originador de la llamada y el usuario llamado, y se abre una sesión RTP

con el audio de la llamada. Los códecs de audio de la llamada, o parámetros de esta sesión

RTP se negocian mediante protocolo SDP contenido en el body de los mensajes INVITE y

200 OK. En la Figura 10 se puede ver gráficamente todo lo explicado anteriormente.

2.1.4.4 Flujo de una llamada desde un usuario no registrado

En un escenario de este tipo, tenemos que el usuario originador de la llamada no está

registrado en la red IMS, es decir, no se ha producido el proceso de registro para el usuario A.

En cambio, sí se ha producido dicho proceso de registro para el usuario B. En este escenario,

el usuario originador de la llamada se ha registrado contra la PBX no registrada, por tanto, el


34

intercambio de mensajes de registro se ha producido entre el dispositivo A y la PBX No

registrada. Esto significa, que desde el punto de vista del dispositivo originador de la llamada,

éste se encuentra registrado aunque no esté registrado en la red IMS. Esto es importante,

puesto que un dispositivo SIP nunca enviará una invitación para establecer una sesión si no

está en estado registrado.

En estas circunstancias, cuando el dispositivo que inicia la llamada envía un mensaje INVITE

a la IP y puerto que se haya configurado como proxy, en este caso la ip/puerto de la PBX No

Registrada, dicho mensaje es encaminado hasta este elemento. La PBX No Registrada

modificará la Request-URI del mensaje INVITE saliente de la centralita, añadiendo un

prefijo. Este prefijo será quien determinará los servicios que se van a ejecutar en el servidor

de aplicaciones, para este usuario. Seguidamente, y con dichas modificaciones, el mensaje

INVITE será enrutado hacia el ICSCF local. En este escenario, como en el anterior, cada uno

de los nodos del core de red o CSCF enviará un mensaje de respuesta provisional 100 Trying

para indicar que ha recibido el mensaje pero sin dar una respuesta definitiva. El ICSCF

determinará qué SCSCF dará servicio al usuario mediante una consulta de localización (LIR)

al HSS. Para los usuarios no registrados el Serving local es asignado de manera estática en el

HSS, asignando un Serving por defecto asociado a la Public Service Identity.

Al llegar el mensaje INVITE al SCSCF se ejecuta lógica terminante puesto que no se ha

introducido ninguna marca en el mensaje INVITE para indicar el SCSCF que haga lo

contrario.

La lógica terminante, para los usuarios no registrados, es algo diferente. Como el usuario no

está registrado no hay ningún service profile cargado en memoria, cuando sucede esto, el

Serving hace una consulta SAR al HSS para intentar recuperar el service profile del usuario

contenido en la Request-Uri. Como este usuario no existe en el HSS, éste hace un último

intento antes de devolver un error de User not Found, busca entre todas las Public Service

Identities definidas si alguna coincide el usuario contenido en la Request-Uri, si es así,

devolverá el service profile asociado a dicha PSI, y si no es así, devolverá el temido error

User Unknown. Este proceso de búsqueda entre todas las PSIs definidas en el HSS es bastante

costoso, por eso mismo, en entornos de producción es aconsejable tener un único SCSCF para

procesar las llamadas de usuarios no registrados, de manera que quede separado el tráfico de

usuarios registrados y usuarios no registrados.

Una vez descargado el service profile asociado a la PSI el proceso es bastante parecido al

proceso de una llamada SIP. Es decir, se evalúan los iFCs descargados y se creará una lista

con los iFCs que aplican y seguidamente se procederá a ejecutar cada uno de los iFCs.


35

SIP Phone A PBX-NoReg Home S-CSCF HSSSIP Phone BRemote

S-CSCFRemoteP-CSCF

Home AS Remote ASHome I-CSCF

INVITE

INVITE

INVITE

INVITE

INVITE

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

ACK

ACK

ACK

ACK

ACK

ACKACK

Diameter LIR

Diameter LIA

Diameter SAR

Diameter SAA

INVITE

100 Trying

INVITE

100 Trying

INVITE

100 Trying

INVITE

100 Trying

INVITE

100 Trying

INVITE

100 Trying

Figura 11. Flujo llamada PBX_NoReg – SIP


36

Esto generará el disparo de los servicios originantes para pbx no registradas, en nuestro

ejemplo upbx_originating, sobre el servidor de aplicaciones. En este caso, también es

responsabilidad del SCSCF añadir la cabecera P-Served-User conteniendo, en este caso, al

usuario llamado (Request-Uri) y, también, introducir dos cabeceras Route para que el mensaje

INVITE pueda ser enrutado mediante el método de “loose route” (Ver 0). Nótese que, en este

caso, la Request-Uri y por tanto, la cabecera P-Served-User contendrán un usuario precedido

de un prefijo. Esto es algo que se tendrá que tener en cuenta en el servidor de aplicaciones.

Una vez ejecutados los servicios originantes para el usuario no registrado, el servidor de

aplicaciones enrutará la llamada de nuevo al Serving. Es importante, que el servidor de

aplicaciones se encargue de eliminar el prefijo que fue añadido en la Request-Uri para

provocar la ejecución de los servicios originantes sobre un usuario no registrado. Esta

modificación de la Request-Uri provocará una revaluación de los servicios terminantes sobre

el “nuevo destino”, en este caso el usuario llamado real.

A partir de aquí, y puesto que la parte llamada en este ejemplo es un usuario de la red IMS, el

proceso es exactamente igual al del caso anterior. Es decir, se encaminará la llamada hacia el

ICSCF, que será quién determinará, mediante una consulta de localización (LIR) al HSS, cuál

es el SCSCF de la red remota que tratará la llamada, y finalmente, el mensaje INVITE será

encaminado hacia dicho SCSCF, donde se ejecutará nuevamente lógica terminante para el

usuario llamado. En la Figura 11 se puede ver gráficamente todo lo explicado anteriormente.

2.1.4.5 Flujo de una llamada a un usuario no registrado

En este escenario, el usuario originador de la llamada es un usuario registrado en la red IMS,

por lo que la ejecución de los servicios originantes para el usuario llamante será igual a lo que

ocurría en el caso del punto 0. Una vez se han ejecutado todos los iFCs originantes del

usuario llamante, el SCSCF pasará a ejecutar la lógica terminante. La primera acción que se

realiza en este punto es una consulta al HSS para descargar el profile del usuario terminante.

Si el SCSCF es capaz de conseguir dicho profile, éste seguirá ejecutando los servicios

terminantes del usuario. Sin embargo, en este caso, al ser el usuario un usuario no registrado,

no está dado de alta en el HSS, por lo que esta consulta no devuelve como resultado ningún

perfil de usuario. Esto provoca que el Serving realice una consulta al ENUM. Dicha consulta

tiene un cometido claro, si la consulta al ENUM devuelve una respuesta, el SCSCF entiende

que el usuario es un usuario IMS o, como ocurre en nuestro caso, que aunque no lo sea, la

llamada debe permanecer en el dominio IMS. Si la consulta al ENUM falla, la llamada será

enrutada hacia el PSTN Gateway, o lo que es lo mismo, hacia la red de circuitos. En este caso,

esta consulta no sólo no produce un fallo sino que el ENUM provoca un cambio significativo

en el usuario. En este caso, el ENUM añade un prefijo al usuario, y por tanto, dicho prefijo es

añadido a la Request-Uri. Esto significa que es completamente obligatorio que el rango de

extensiones de la PBX No registrada sea dado de alta en el ENUM y que se instruya a éste

para añadir un prefijo a todas las extensiones que pertenezcan a dicho rango.

Para que las llamadas hacia usuarios no registrados funcionen sólo hay dos opciones, una es

dar de alta el rango de extensiones de la PBX no registrada en el HSS como PSI, en cuyo caso


37

la consulta al HSS devolvería el profile asociado a la PSI sin necesidad de acudir al ENUM, y

la otra manera es dar de alta ese rango en el ENUM, instruyendo a éste para añadir un prefijo

que provoque la ejecución de los servicios terminantes del usuario. Este prefijo tendrá que ser

dado de alta en el HSS como PSI (Wildcarded PSI).

SIP Phone A P-CSCF Home S-CSCF HSSSIP Phone BRemote

S-CSCFPBX_NoRegHome AS Remote ASRemote

I-CSCF

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

INVITE

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

100 Trying

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

180 Ringing

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

200 OK

ACK

ACK

ACK

ACK

ACK

ACKACK

Diameter LIR

Diameter LIA

Diameter SAR

Diameter SAA

Figura 12. Flujo llamada SIP - PBX_NoReg


38

En nuestro escenario, hemos supuesto que utilizábamos el ENUM. Por tanto, una vez, se ha

ejecutado la consulta al ENUM y el prefijo ha sido añadido, la llamada es enrutada hacia el

ICSCF.

En este escenario, como en los anteriores, cada uno de los nodos del core de red o CSCF

enviará un mensaje de respuesta provisional 100 Trying para indicar que ha recibido el

mensaje pero sin dar una respuesta definitiva. El ICSCF determinará qué SCSCF dará

servicio al usuario mediante una consulta de localización (LIR) al HSS. Para los usuarios no

registrados, como ya se han indicado en el anterior escenario, el Serving local es asignado de

manera estática en el HSS, asignando un Serving por defecto asociado a la Public Service

Identity.

Al llegar el mensaje INVITE al SCSCF se ejecutará lógica terminante, de igual manera que

ocurría en el caso de que un usuario no registrado iniciara una llamada. Al igual que ocurría

en este caso, como el usuario no está registrado no hay ningún service profile cargado en

memoria, por lo que el Serving hace una consulta SAR al HSS para intentar recuperar el

service profile del usuario contenido en la Request-Uri. Como este usuario no existe en el

HSS, éste busca entre todas las Public Service Identities definidas si alguna coincide el

usuario contenido en la Request-Uri, y si es así, devolverá el service profile asociado a dicha

PSI, y si no es así, devolverá el temido error User Unknown. Una vez descargado el service

profile asociado a la PSI se evaluarán los iFCs descargados y se creará una lista con los iFCs

que aplican y seguidamente se procederá a ejecutar cada uno de los iFCs.

En este punto, y una vez ejecutados los servicios terminantes del usuario en el servidor de

aplicaciones, es responsabilidad de éste realizar el enrutado final. Puesto que el usuario no es

un usuario registrado, el core IMS no tiene información sobre dónde enrutar la llamada, por

eso, suele ser el servidor de aplicaciones quien proporciona esta información añadiendo una

segunda cabera Route con la dirección IP y el puerto donde el serving debe enviar el mensaje

INVITE, en este caso la PBX No Registrada. También es posible, que el servidor de

aplicaciones tenga que indicar mediante algún parámetro el trunk por donde se debe enrutar la

llamada. No es éste nuestro caso, que con la dirección ip y el puerto es suficiente. Para más

detalles sobre el routing aplicado en este escenario ver punto 0. Como en casos anteriores en

la Figura 12 se expone de manera gráfica lo explicado en este punto.

2.1.4.6 Routing

En cuanto al Routing, podemos hablar de dos tipos de elementos en una red IMS. Son

aquellos elementos que funcionan como un SIP Proxy, como es el caso de los elementos del

core de red o CSCF, y aquellos elementos o nodos que funcionan como User Agent. Estos

pueden ser agentes SIP finales, como son los dispositivos SIP que originan (clientes) o en los

que finalizan las llamadas (servidores), o pueden ser elementos intermedios que funcionan

como usuarios receptores de una transacción (servidores) e iniciadores de otra (clientes). A

este grupo pertenecen los servidores de aplicaciones, SBCs o PBXs.


39

Según el rol que presente un elemento, su manera de enrutar será diferente.

- SIP Proxy

Un SIP proxy, como su propio nombre indica, va a progresar la llamada. No iniciará ni

terminará ninguna transacción. Para encaminar la llamada utiliza el método de “loose route”

o en determinados casos de “strict route”.

El método de LOOSE ROUTE, consiste en enrutar la llamada según lo que indique la

primera cabecera Route. Lo que hace un proxy (o un B2BUA) que utilice este método es

eliminar la primera cabecera Route si contiene su dirección ip y su puerto, esto indica que el

elemento anterior también utilizó el método loose route para encaminar la llamada, y

utilizar la siguiente cabera Route, si existe, para enrutar. Si no existe ninguna cabecera

Route más, utilizará la Request-Uri para enrutar. Además, si quiere indicar al siguiente

elemento el o los próximos saltos en la ruta, añadirá tantas cabeceras Route como saltos

desee indicar.

En el caso del método STRICT ROUTE, lo que se hace es eliminar la primera cabecera

Route si contiene su dirección ip y su puerto y utilizar la siguiente cabecera Route para

enrutar. Hasta aquí, el procedimiento es el mismo que cuando se hace loose route. La

diferencia radica en que, en el caso del strict route, se intercambian el contenido de la

cabecera Route y de la Request-Uri. Y, por tanto, se utiliza la Request-Uri para enrutar. El

nodo de destino debe soportar el strict route, y debe saber que el usuario llamado se

encuentra en la cabecera Route, no en la Request-Uri. Este método no es el más extendido, y

es bastante obsoleto, sin embargo no está de más conocerlo.

Además de encaminar la llamada hacia el siguiente elemento, un SIP proxy se incluirá como

cabecera Via, para forzar a que las respuestas asociadas a la petición que está procesando

sean enviadas a través de él. Y, hará lo propio en una cabecera Record-Route, si quiere que

las nuevas peticiones sean progresadas hacia él también.

Por el contrario, irá consumiendo cabeceras Via en las respuestas y cabeceras Route en las

peticiones.

- B2BUA o UserAgent

Un B2BUA combina las funcionalidades de un User Agent Server (UAS) y de un User

Agent Client (UAC). Un B2BUA opera entre dos puntos finales de una comunicación de

VoIP y divide el canal de comunicación en dos “call legs”, operando para uno de los “end

points” como UAS, para el “end point” originador de la llamada, y como UAC para el otro

“end point”, para el destinatario de la llamada. Por tanto, se encarga de manejar toda la

señalización SIP entre ambos “end points” desde el establecimiento de la llamada y hasta su

finalización.


40

Como toda la señalización SIP de la llamada pasa a través del B2BUA, éste puede

proporcionar servicios de valor añadido durante la llamada. Como ya se ha dicho, en la

“originating call leg”, el B2BUA actúa como un User Agent Server, y es responsable

de emitir las respuestas hacia el User Agent originador de la llamada. Una vez

aplicada la lógica de servicio si procede, la llamada será progresada hacia la

“terminante call leg”, para la cual el B2BUA actúa como un User Agent Client. En

este punto, el B2BUA será responsable de crear y enviar las peticiones SIP pertinentes

para crear una nueva llamada. El B2BUA mantiene el estado completo para todas las

llamadas que maneja.

La principal responsabilidad de un B2BUA, en cuanto a routing, es que debe

almacenar las cabeceras Via y Record-Route de una transacción, y recuperarlas para

ser añadidas en los mensajes de respuesta y/o en las nuevas peticiones. A

continuación, se pasará a explicar el comportamiento de un UAC (User Agent Client)

y de un UAS (User Agent Server) en cuanto al routing.

Cuando un UA recibe un mensaje INVITE, utilizará las cabeceras Via para enrutar las

respuestas asociadas a dicho mensaje INVITE. Respuestas tanto provisionales como

finales.

Cuando un UA desea enviar una nueva petición, ya sea un ACK al 200 OK, un

mensaje BYE o Re-INVITE hará uso de las cabeceras Record-Route recibidas en el

último mensaje para enrutar la nueva petición.

De manera que para un UAC, en el establecimiento de llamada, el último mensaje

recibido será el 200 OK al mensaje INVITE, mientras que para un UAS, el último

mensaje recibido será el propio mensaje INVITE. Se invertirá el orden de dichas

cabeceras Record-Route y se transformarán en cabeceras Route, añadiendo la cabecera

Contact recibida en la última respuesta como Request-Uri. Una vez consumidas las

cabeceras Route por los proxis de la red, la Request-Uri (conteniendo la cabecera

Contact en ese caso) será utilizada para enrutar. Ver método “loose route” explicado

anteriormente en este mismo punto.

Por último, un UA siempre añade la cabecera Contact con su dirección ip y su puerto.

Puede indicar incluso el protocolo de transporte que se debe usar para acceder a él, por

ejemplo transport=tcp. Esta cabecera es muy importante, puesto que la cabecera

Contact recibida es utilizada por los UAs para añadirla en la Request-Uri y que,

finalmente, los proxis la usen una vez consumidas todas las cabeceras Route para

enrutar.


41

En la Figura 13, se puede ver gráficamente todo lo que se ha explicado en este punto.

SIP Phone AP-CSCF S-CSCF SIP Phone BAS I-CSCF

INVITE

INVITE

100 Trying

100 Trying

Via: SIP phone A Addres/portContact: SIP phone A Address/port

Via: PCSCF Address/portVia: SIP phone A Addres/portRecord-Route: PCSCF Address/portContact: SIP phone A Address/port

INVITE

Via: PCSCF Address/portVia: SIP phone A Addres/portRecord-Route: PCSCF Address/portContact: SIP phone A Address/port

INVITE

Via: SCSCF Address/portVia: PCSCF Address/portVia: SIP phone A Addres/portRecord-Route: SCSCF Address/portRecord-Route: PCSCF Address/portContact: SIP phone A Address/port

INVITE

Via: SCSCF Address/portVia: AS Address/portRecord-Route: SCSCF Address/portContact: AS Address/port

INVITE

Via: AS Address/portContact: AS Address/port

INVITE

Via:PCSCF Address/portVia: SCSCF Address/portVia: AS Address/portRecord-Route: PCSCF Address/portRecord-Route: SCSCF Address/portContact: AS Address/port

Via: SIP phone Addres/port

Via: PCSCF Address/portVia: SIP phone Addres/port

Via: PCSCF Address/portVia: SIP phone Addres/portRecord-Route: PCSCF Address/port

100 Trying

100 Trying

Via: SCSCF Address/portVia: PCSCF Address/portVia: SIP phone Addres/portRecord-Route: SCSCF Address/portRecord-Route: PCSCF Address/portContact: AS Address/port

100 Trying

Via: AS Address/port

200 OK

Via:PCSCF Address/portVia: SCSCF Address/portVia: AS Address/portRecord-Route: PCSCF Address/portRecord-Route: SCSCF Address/portContact: SIP Phone B address/port

200OK

Via:PCSCF Address/portVia: SCSCF Address/portVia: AS Address/portRecord-Route: PCSCF Address/portRecord-Route: SCSCF Address/portContact: SIP Phone B address/port

200OK

Via: SCSCF Address/portVia: AS Address/portRecord-Route: PCSCF Address/portRecord-Route: SCSCF Address/portContact: SIP Phone B address/port

200OK

Via: SCSCF Address/portVia: PCSCF Address/portVia: SIP phone A Addres/portRecord-Route: SCSCF Address/portRecord-Route: PCSCF Address/portContact: AS Address/port

200OK

Via: SCSCF Address/portVia: PCSCF Address/portVia: SIP phone A Addres/portRecord-Route: SCSCF Address/portRecord-Route: PCSCF Address/portContact: AS Address/port

200OK

Via: PCSCF Address/portVia: SIP phone A Addres/portRecord-Route: SCSCF Address/portRecord-Route: PCSCF Address/portContact: AS Address/port

ACK

RURI: AS Address/portVia: SIP phone Addres/portRoute: PCSCF Address/portRoute: SCSCF Address/portContact: SIP phone A address/port

ACK

RURI: AS Address/portVia: PCSCF Address/portVia: SIP phone Addres/portRoute: PCSCF Address/portRoute: SCSCF Address/portContact: SIP phone A address/port

ACK

RURI: AS Address/portVia: SCSCF Address/portVia: PCSCF Address/portVia: SIP phone Addres/portRoute: SCSCF Address/portContact: SIP phone A address/port

ACK

RURI: SIP Phone B address/portVia: AS Address/portRoute: SCSCF Address/portRoute: PCSCF Address/portContact: AS Address/port

ACK

RURI: SIP Phone B address/portVia: SCSCF Address/portVia: AS Address/portRoute: SCSCF Address/portRoute: PCSCF Address/portContact: AS Address/port

ACK

RURI: SIP Phone B address/portVia: PCSCF Address/portVia: SCSCF Address/portVia: AS Address/portRoute: PCSCF Address/portContact: AS Address/port

Figura 13. Routing


42


43

3 Especificaciones y restricciones de diseño

La elaboración del proyecto se ha basado en la necesidad real que existe en muchos de los

centros de estudios de este país para proporcionar al alumnado un banco de pruebas donde

poder aplicar los conocimientos teóricos adquiridos en asignaturas de voz sobre IP.

Durante el diseño del laboratorio IMS se ha tomado como guía la definición de Core IMS

realizada por la 3GPP, teniendo en cuenta los nodos más característicos de dicha

definición. Por simplicidad, se ha diseñado y desplegado una única red IMS y no se han

incluido nodos de interconexión con otras redes IMS dejando la posible ampliación del

laboratorio para trabajos futuros.

Además, se han dejado fuera del diseño la convergencia con otras redes

(UMTS/GSM/PTSN…) debido a la falta del hardware necesario. Por este motivo el

diseño se ha centrado en una red IMS pura donde todos los dispositivos utilizados son

dispositivos IP. Sin embargo, y a modo de demostración de cómo sería la convergencia

con redes externas de naturaleza diferente, se ha introducido como elemento una pbx no

registrada que muestra el disparo de servicios de una red IMS para usuarios que no

pertenecen a dicha red. En un entorno real, estos usuarios podrían ser usuarios de la red

conmutada de circuitos (usuarios registrados en la red GSM o usuarios conectados a la red

fija (PTSN)), y que acceden a la red IMS a través de un nodo SBC, obteniendo los

servicios de dicha red IMS a través del disparo de dichos servicios por PSI.


44


45

4 Descripción de la solución propuesta

A continuación se pasará a comentar las herramientas utilizadas para el despliegue del

laboratorio IMS. Seguidamente se hablará de la arquitectura general, pasando a continuación

a detallar cada uno de los elementos de la red.

4.1 Herramientas utilizadas

Se han utilizado herramientas de libre distribución, o en su defecto herramientas en su versión

trial, tanto para la implementación del laboratorio IMS como para realizar cualquier actividad

derivada del testeo de dicho laboratorio.

A continuación se pasa a enumerar y dar una breve descripción de dichas herramientas:

- Software de virtualización. Necesario para alojar la máquina virtual que contiene el

laboratorio IMS, así como para crear la red virtualizada de interconexión de los diferentes

elementos. Se ha utilizado VirtualBox [3.1]. Esta herramienta es una de las más

conocidas y potentes para esta función. Se ha elegido esta herramienta frente a VMWare

por ser de libre distribución.

- Sistema Operativo para las máquinas virtuales. En este caso se ha utilizado Debian, por

ser la distribución de Linux recomendada para funcionar tanto con Kamailio como con

Asterisk. En un primer momento se utilizó la versión Wheezy, teniendo que hacer una

actualización a Debian Jessy más tarde, debido a nuevas dependencias introducidas por

kamailio 4.3 con algunas librerías del sistema que no estaban disponibles en la versión

Wheezy de Debian.

- Software de enrutado de paquetería SIP o SIP Proxy. Necesario para la implementación

del core IMS. Existen varias herramientas de libre distribución capaces de realizar esta

función. Las más conocidas son Kamailio[3.2] y OpenSIPS[3.3], ambas son herramientas

de libre distribución y de código abierto, y ambas tienen a sus espaldas empresas,

Asipto[3.4] en el caso de kamailio y AG Project[3.5] en el caso de OpenSIPS, que dan

soporte, ayuda y/o consultoría. En este caso, la elección de Kamailio frente a OpenSIPS

no fue basada en razones racionales sino más bien en el conocimiento del alumno.

Se ha utilizado Kamailio para la implementación de los principales nodos de la red IMS

(P-CSCF, I-CSCF y S-CSCF). En un primer momento, se utilizó la versión 4.2.3 de

Kamailio por ser la versión estable más avanzada. Finalmente, y debido a que durante la

elaboración del proyecto salió otra versión estable de Kamailio y más avanzada, se

decidió actualizar a dicha versión para entregar el software lo más actualizado posible.


46

- Software para la implementación del HSS. Necesario por ser un nodo perteneciente

a la red IMS. En este caso su utilización es más dependiente del interés por

representar todos los nodos de la red IMS y la interconexión entre todos ellos para

su estudio que por una necesidad real [1]

.

Se ha utilizado FHoSS o Fokus HSS[3.7] por ser el más conocido en Internet. En

cuanto a la versión, se ha utilizado la única versión que hay disponible de este

software, ya que es un proyecto muerto desde hace tiempo y no ha sufrido

modificaciones en los últimos años.

- Software para implementación de servicios de Voz. Necesario para la

implementación de un Servidor de Aplicaciones que proporcione servicios de voz a

los usuarios de la red IMS. En este caso se ha utilizado Asterisk[3.8], dado que es el

software de libre distribución más famoso en este ámbito y dada la cantidad de

información que es posible encontrar en Internet.

Para el presente despliegue, se ha optado por incluir este software también como

dos diferentes tipos de PBX, diferentes por su interacción con la red IMS. Asterisk

funciona como un B2BUA (Back-to-back User Agent) en cualquiera de los tres

roles que adopta en este despliegue, PBX registrada, PBX no registrada y Servidor

de aplicaciones. En cuanto a la versión, comentar que se ha utilizado Asterisk 13,

por ser la versión más avanzada al inicio del proyecto.

- Proxy RTP. Necesario si tenemos Kamailio detrás de NAT o se hace necesaria la

transmisión de tráfico RTP a través de Firewalls. En la arquitectura que se ha

utilizado y que se comentará en el siguiente capítulo no sería realmente necesario,

puesto que Kamailio no se encuentra detrás de NAT y los terminales se encuentran

sobre la misma máquina física, en un escenario como éste, el tráfico RTP es directo

entre los terminales que son visibles unos a otros. Sin embargo, se haría necesario

si decidiésemos desplegar el laboratorio sobre una red LAN. Se ha utilizado para

este fin RTPProxy[3.9] en su versión 2.0.0, que es el software recomendado por

Kamailio y para el cuál Kamailio da un soporte completo.

- Servidor de Base de Datos. Debido a la utilización tanto de Kamailio como de

FHoSS, se hace necesario alojar tres bases de datos utilizadas por este software.

Base de datos del HSS

Base de datos del I-CSCF

Base de datos de Kamailio

1 Kamailio proporciona la posibilidad de acceder directamente a una base de datos interna donde se pueden dar

de alta los usuarios de la red IMS, de este modo, Kamailio puede cubrir la funcionalidad del HSS. Sin embargo,

como ya se ha indicado, se ha preferido la inclusión de un nodo adicional con esta funcionalidad para que fuera

posible el estudio de la interfaz Cx (Diameter [3.6]).


47

Las dos primeras se utilizan por el FHoSS y la segunda por el propio Kamailio. En el

primer caso, FHoSS sólo da soporte para bases de datos de MySQL[3.10], por tanto no

había mucho que decidir. En el caso de Kamailio, la variedad es más amplia y se podría

haber utilizado Postgres[3.11], Oracle[3.12] o incluso ficheros de texto, sin embargo,

puesto que FHoSS obligaba a la utilización de MySQL se ha optado por su utilización

para todas las bases de datos.

- Software para la consulta de dominios. Necesario para la implementación de un Servidor

de DNS[3.13] y del ENUM [3.14]. Se ha utilizado el software Bind[3.15] incluido en la

propia distribución del sistema operativo para la implementación tanto del servidor de

DNS como del ENUM.

- SIP phones. Necesarios para la realización de las pruebas. Se han utilizado varios SIP

phones libres o en sus versiones Trial.

Sleipner [3.16].

Kapanga[3.17]

PhonerLite [3.18]

X-lite [3.19]

Zoiper [3.20]

- Herramienta de análisis de tráfico. Necesario para analizar el tráfico SIP, Diameter, etc.

Se ha utilizado WireShark[3.21], debido al conocimiento del alumno sobre la

herramienta.

- Cliente de sesiones ssh y ftp. Utilizado para el acceso a las máquinas virtuales. Se ha

elegido MobaXterm[3.21] por el conocimiento del alumno sobre la herramienta y por la

variedad de posibilidades que ofrece.


48

4.2 Arquitecturas de despliegue posibles

Dada la naturaleza de la arquitectura que se ha montado, son posibles diferentes

configuraciones a la hora de desplegar el laboratorio de acuerdo al foco del estudio o a las

restricciones de recursos informáticos disponibles. Puesto que el software se ha entregado en

una máquina virtual, cualquiera de las configuraciones de despliegue implican que todos los

elementos están alojados en una o varias máquinas virtuales.

A continuación se enumeran algunos ejemplos de diferentes configuraciones en el despliegue:

- Sobre una red LAN. Se despliega una instancia del IMSLab por cada elemento de la

red, de manera que cada elemento se despliega en una máquina virtual en solitario. Cada

máquina virtual se aloja sobre una máquina física diferente perteneciente a una red

LAN, y por tanto, se utiliza dicha LAN para conectar cada uno de los elementos entre

sí. Las máquinas virtuales utilizarán la dirección IP de las máquinas físicas y la

configuración de red del software de virtualización debe incluir un adaptador de puente.

- Sobre una única máquina física. Se despliega una instancia del IMSLab por cada

elemento de la red, de manera que cada elemento se despliega en una máquina virtual en

solitario. Todas las máquinas virtuales se alojan en una única máquina física que aloja

una red virtualizada para interconectar todas las máquinas virtuales. Las máquinas

virtuales utilizan una dirección IP perteneciente a dicha red virtualizada y la

configuración de red del software de virtualización debe incluir un adaptador de red

interna (configuración actual (Figura 14. Arquitectura de despliegue)).

- Una combinación de las anteriores:

o Varios elementos pueden ser desplegados cada uno en su VM y alojados en una misma

máquina física, conectándose a través de una red virtualizada con los elementos con

los comparten máquina física y a través de la LAN con los elementos externos a dicha

máquina física. Al menos uno de los elementos debe utilizar la dirección IP de la

máquina física (adaptador puente) siendo utilizado dicho elemento como punto de

entrada. Esta configuración es interesante si no poseemos un equipo tan potente como

para alojar todas las máquinas virtuales. Es una manera de dividir la carga de

procesamiento entre dos o más máquinas sin llegar a necesitar una máquina física por

cada elemento.

o Varios elementos pueden ser desplegados en una única máquina virtual, interactuando

entre ellos como diferentes procesos. Esta configuración es interesante cuando el foco

de nuestro estudio es muy concreto y no nos interesa prestar atención a la

interconexión de todos los elementos sino de uno o dos en concreto con el resto. Por

ejemplo, es interesante desplegar todos los nodos del core IMS (P-CSCF, I-CSCF, S-

CSCF y HSS), en la misma máquina virtual cuando lo que nos interesa es estudiar el

comportamiento del servidor de aplicaciones.


49

4.3 Arquitectura de despliegue utilizada

En el caso que nos ocupa se ha elegido desplegar todos los elementos sobre una única

máquina física. Esta elección ha sido basada principalmente en los recursos informáticos

disponibles del alumno, pero también, en el especial interés por asegurar el correcto

funcionamiento del laboratorio en un entorno totalmente autónomo. En la siguiente figura se

muestra la arquitectura de despliegue general utilizada.

IMSLab (PCSCF configuration)

IMSLab (Additional elements)

IMSLab (AS configuration)

IMSLab (RegPBX configuration)

IMSLab (UnRegPBX configuration)

IMSLab (SCSCF configuration)

IMSLab (ICSCF configuration)

IMSLab_network (open-ims.lab.es: 172.16.0.80/24)

NAT access with port forwarding:

ssh: 6022 à22


ssh: 4022 à22 pcscf: 44060 à 4060


ssh: 5022 à22


ssh: 8022 à22 http: 8888 à 8080 mysql: 8306 à3306

scscf.open-ims.lab.espcscf.open-ims.lab.es

hss.open-ims.lab.es

icscf.open-ims.lab.es

Additional Elements

* HSS * DNS Server/ENUM * RTP Proxy * Databases:

- Kamailio database - Icscf database - hss database


ssh: 7022 à22rpbx.open-ims.lab.es


ssh: 1022 à22 pbx: 18060 à8060

as.open-ims.lab.es

upbx.open-ims.lab.es


ssh: 2022 à22 pbx: 28060 à8060

1 Virtual LAN

7 Virtual Machine

7NAT access from phisical machine

Símbolo Total Descripción

Subtítulo de leyenda

Leyenda

Figura 14. Arquitectura de despliegue

Como se puede observar en la Figura 14. Arquitectura de despliegue, se han desplegado seis

máquinas virtuales. Para cada una de ellas se han habilitado dos interfaces de red, una interfaz

perteneciente a la red virtualizada IMSLab_network (172.16.0.80/24) y otra interfaz para

hacer posible la comunicación con la máquina física en la que están alojadas las máquinas

virtuales.

Esta segunda interfaz que habilita la comunicación con la máquina física se hace necesaria

para algunos de los elementos y cómoda para el resto. Se hace necesaria en aquellos

elementos que son puntos de entrada a la red. Estos elementos son los siguientes:


50

- El P-CSCF. Es el punto de entrada a la red IMS para aquellos usuarios que son

usuarios IMS de la red y que se registran directamente en ésta.

- La PBX registrada. Es el punto de entrada a la red IMS para aquellos usuarios que

son usuarios de la centralita. Estos usuarios se registran directamente en la

Centralita y es la Centralita, como entidad única, la que se registra en el núcleo de

la red IMS.

- La PBX no registrada. De manera análoga a los usuarios de la PBX registrada, los

usuarios de esta PBX se registran en esta centralita. La diferencia con respecto a la

anterior reside en que esta centralita no se registra en el núcleo de la red IMS. La

prestación de servicios para los usuarios de este elemento se hace mediante la

aplicación de PSIs (Public Service Identities).

- El HSS. En el caso del HSS, esta segunda interfaz habilita el acceso a la interfaz

web que ofrece este elemento para su configuración desde el navegador de la

máquina física.

Para el resto de elementos se ha habilitado también esta segunda interfaz, pero en estos

casos, ha sido por comodidad. Esta segunda interfaz permite acceder a cada una de las

máquinas virtuales utilizando un cliente ssh. Hay infinidad de clientes ssh que hacen

más rápida y cómoda la navegación entre las diferentes máquinas virtuales o el traspaso

de ficheros entre las máquinas virtuales y la máquina física.

En la Figura 15. Arquitectura de despliegue detallada se puede observar de manera más

detallada la arquitectura desplegada, haciendo especial hincapié en los elementos

desplegados en cada máquina virtual.


51

P-CSCF

S-CSCF

I-CSCF

Additional elements

REG PBXUNREG PBX

AS

kamailio

icscf hss_db

HSS

kamailio(pcscf)

kamailio(scsf config)

kamailio(icscf config)

Local mysql queries

asterisk(registered

pbx)asterisk

(unregistered pbx)

asterisk(application

server config)

Diameter Cx

Diameter Cx

mysql queries

mysql queries

SIP

SIP

SIP

SIP Phone SIP Phone

SIP Phone

SIP tru

nk

127.0.0.1:44060

17

2.1

6.0

.40

:40

60

12

7.0

.0.1

:18

06

0

12

7.0

.0.1

:28

06

0

172.16.0.10:8060

172.16.0.60:6060

172.16.0.20:8060

172.16.0.50:5060

17

2.1

6.0

.50

:38

69

172.16.0.60:3870

17

2.1

6.0

.60

:60

60

17

2.1

6.0

.60

:60

60

172.16.0.80:3868

172.16.0.80:3306

172.16.0.70:7060

IMS Core elements

IMS extern elements

Figura 15. Arquitectura de despliegue detallada

En la Figura 15. Arquitectura de despliegue detallada se han marcado los elementos que

forman el núcleo de la red IMS en amarillo, en el caso concreto de este despliegue son, los

elementos del CSCF, el HSS y todas las bases de datos utilizadas por estos elementos.

Por otro lado, se han marcado los elementos que se consideran externos al núcleo de red en

color rosado, estos son las PBXs y el Servidor de aplicaciones.

Se han representado también la interconexión entre los diferentes elementos, las interfaces

que se usan para cada uno de ellas, etc. A continuación se pasará a comentar detalladamente

la figura.

4.3.1 Proxy CSCF

El Proxy CSCF o P-CSCF o simplemente Proxy ha sido desplegado en solitario sobre una

máquina virtual. Se han definido dos interfaces SIP en dicha máquina virtual, una

perteneciente a la red IMSLab_network y otra con la máquina física. Como se ha comentado


52

anteriormente, los usuarios tienen varias opciones a la hora de acceder a los servicios

prestados por la red IMS. La primera de ellas es darse de alta como usuarios de la red.

Estos usuarios serán dados de alta en el HSS y se registrarán directamente a través del

P-CSCF. En este caso, se usarán softphones corriendo directamente en la máquina física

y accederán a la red IMS a través P-CSCF por su interfaz local2.

La interfaz local del P-CSCF es únicamente utilizada como punto de acceso de los

dispositivos SIP a la red. Sin embargo, la interfaz que pertenece a la red

IMSLab_network, es utilizada como punto de acceso de las PBX registradas a la red,

pero también, como punto de conexión con el S-CSCF en escenarios originantes, en los

cuáles se utiliza el Serving local, y con el I-CSCF en escenarios terminantes, en los

cuáles es necesario invocar al Interrogating CSCF para descubrir el Serving CSCF del

usuario llamado.

Adicionalmente, a estas dos interfaces SIP, el P-CSCF realiza queries MySQL en

remoto a la base de datos de Kamailio desplegada en el nodo HSS. Estas queries son las

referentes a la localización. Debido a la activación del módulo de NAT en Kamailio, el

P-CSCF almacena en la base de datos de Kamailio todas las IPs desde donde se reciben

mensajes de un mismo usuario. Más tarde, estas IPs serán utilizadas por el S-CSCF para

encaminar las llamadas terminantes para este usuario.

4.3.2 Interrogating CSCF

El Interrogating CSCF o I-CSCF o simplemente Interrogating, ha sido desplegado en

solitario sobre una máquina virtual. Se ha definido una única interfaz SIP perteneciente

a la red IMSLab_network, la cual es utilizada como punto de conexión con el S-CSCF y

con el P-CSCF únicamente en la parte terminante de las llamadas, puesto que, en la

parte originante el Proxy y el Serving se comunican directamente.

Adicionalmente a esta interfaz SIP, se ha definido una conexión Diameter con el HSS

en el puerto 3869. A través de esta conexión el Interrogating implementa la interfaz Cx

para comunicarse con HSS y recuperar información sobre el Serving al que hay que

dirigir la llamada. Esta información es recuperada de la base de datos icscf de manera

local por el HSS.

4.3.3 Serving CSCF

El Serving CSCF o S-CSCF o simplemente Serving, ha sido desplegado en solitario

sobre una máquina virtual. Se ha definido una única interfaz SIP perteneciente a la red

IMSLab_network, la cual es utilizada de tres maneras diferentes:

o Análogamente a como es utilizada en el Proxy y en el Interrogating, en este caso,

también utilizada como punto de conexión con el P-CSCF en la parte originante de la

llamada y con el I-CSCF en la parte terminante de las llamadas.

2 Para hacer posible esta conexión ha sido necesario añadir en la máquina virtual donde está desplegado el

P-CSCF un reenvío desde el puerto 44060 local al puerto 4060 de la máquina virtual


53

o Además, es utilizada como punto de interconexión con la PBX no registradas. Estas

PBX invocan directamente al Serving. Es importante remarcar, que para este tipo de

elementos siempre se ejecuta lógica terminante en el Serving.

o Finalmente, también se utiliza como punto de conexión con el Servidor de

aplicaciones. El AS será invocado en lógica originante y/o en lógica terminante,

dependiendo de los servicios originantes y/o terminantes que tenga el perfil del

usuario.

Adicionalmente a esta interfaz SIP, se ha definido una conexión Diameter con el HSS en el

puerto 3870. A través de esta conexión el Serving implementa la interfaz Cx para

comunicarse con HSS y recuperar información sobre los perfiles de los usuarios. Esta

información es recuperada de la base de datos hss_db de manera local por el HSS.

4.3.4 HSS y elementos adicionales

El HSS, ha sido desplegado junto con otros elementos sobre una máquina virtual. La

comunicación con el HSS no es mediante protocolo SIP, sino que es mediante protocolo

Diameter. En el caso concreto del S-CSCF y del I-CSCF, que es el caso que nos ocupa, es

mediante la interfaz Diameter Cx. Por este motivo, la máquina del HSS ofrece un punto de

acceso Diameter en el puerto 3868, donde escucha peticiones LIR (consultas de localización)

y SAR (descarga de perfil de abonado) desde el Interrogating y Serving respectivamente. La

información para responder a estas peticiones se consulta localmente en las bases de datos

icscf, para el primer caso, y hss_db para el segundo.

Adicionalmente a estas dos bases de datos, otra base de datos ha sido desplegada en este

nodo. Es la base de datos de Kamailio, y es accedida mediante peticiones MySQL remotas por

el Proxy y por el Serving. Para ello, se ha habilitado el puerto 3306 que maneja estas

peticiones.

A pesar de no estar representados en el esquema de la Figura 15. Arquitectura de despliegue

detallada, existen dos elementos adicionales que han sido desplegados junto al HSS y las

bases de datos. Estos elementos son:

- DNS Server/ ENUM

- RTP Proxy

4.3.5 Servidor de aplicaciones

El Servidor de aplicaciones ha sido desplegado en solitario sobre una máquina virtual. En este

caso, se ha definido una única interfaz SIP perteneciente a la red IMSLab_network. Esta

interfaz es utilizada como punto de conexión con la red IMS a través del S-CSCF.


54

Durante el desarrollo del proyecto, el foco principal no ha sido el desarrollo de servicios

avanzados en este servidor de aplicaciones, sino más bien, la interconexión de todos los

nodos y la comunicación entre ellos. Por tanto, tan sólo se ha implementado una

reducida lista de servicios, los necesarios para el estudio de una serie de escenarios que

parecieron interesantes.

Aun así, se hace imprescindible hacer algunos comentarios sobre este nodo:

Se ofrecen servicios tanto originantes como terminantes.

Hay ciertos servicios que se consideran servicios originantes, otros que se

consideran servicios terminantes, y otros que pueden darse tanto en el disparo

terminante como en el disparo originante.

Por ejemplo, un desvío de llamada no tiene sentido como servicio originante,

mientras que una restricción de llamada, podría darse tanto para restringir las

llamadas saliente (servicio originante) o restringir las llamadas entrantes (servicio

terminante).

Para diferenciar los disparos originantes de los disparos terminantes se ha decidido

utilizar la cabecera Route.

Esta cabecera contendrá la cadena “originating” para indicarle al servidor de

aplicaciones que debe ejecutar los servicios originantes configurados para el

usuario llamante. Por otro lado, contendrá la cadena “terminating” para indicar al

AS que debe ejecutar los servicios configurados para el usuario llamado.

Adicionalmente, se diferenciarán a los usuarios de la PBX no registrada, por ser un

tanto especiales. Para estos usuarios lo que llegará en la cabecera Route será

“upbx_originating” para los disparos originantes y “upbx_terminating” para los

disparos terminantes. En la Figura 16. Configuración disparos HSS se muestra una

captura de la configuración en el HSS .


55

Figura 16. Configuración disparos HSS

Escenarios de Cambio de destino en terminante

Cuando se produce un cambio de destino en un disparo terminante, se pueden producir

dos situaciones:

o Lo más conocido en estos casos, es cuando ese cambio de destino es debido a un

desvío de llamada configurado. En este caso, se crea una llamada nueva, y por tanto,

el núcleo IMS debe reevaluar los servicios originantes del antiguo destino y los

terminantes del nuevo. Lo que se produce en este caso a nivel de red, sería el

equivalente al siguiente escenario:

Usuario A llama al usuario B,

Usuario B llama al usuario C

En la Figura 17. Flujo Desvío de llamada se muestra un flujo de un escenario de

desvío de llamada. Nótese que el flujo no está completo, se ha dejado fuera la

comunicación con el HSS, así como todas las respuestas provisionales, ACKs, etc.


56

SIP Phone A P-CSCF S-CSCF I-CSCF

SIP Phone B

AS

SIP Phone C

INVITE BINVITE B

INVITE B (originating services

for A)

INVITE B

INVITE B

INVITE BINVITE B (terminating

services for B)

INVITE BINVITE B

INVITE B

486 BUSY

486 BUSY

486 BUSY

INVITE C

INVITE C (originating services

for B)

INVITE CINVITE C

INVITE CINVITE C

(terminating services

for C)

INVITE C

INVITE C

INVITE C

Figura 17. Flujo Desvío de llamada

o El otro caso que nos ocupa es el rerouting. A veces el cambio de destino es

debido a un servicio contratado por el usuario, por ejemplo, un servicio de

encolado de llamadas. El destino original sería el número de servicio o número

de cabecera, mientras que la ejecución del servicio de encolado provocará una

llamada saliente al agente. En este caso, no se considera una nueva llamada y

por tanto, el núcleo IMS tiene la responsabilidad de revaluar sólo los servicios

terminantes para el nuevo destino.

En la Figura 18. Flujo redirección de llamada se muestra un flujo de un

escenario de redirección de llamada. Nótese que, al igual que en la Figura 17.

Flujo Desvío de llamada, el flujo no está completo.


57

SIP Phone A P-CSCF S-CSCF I-CSCF

SIP Phone B

AS

SIP Phone C

INVITE BINVITE B

INVITE B (originating services

for A)

INVITE B

INVITE B

INVITE BINVITE B (terminating

services for B)

INVITE CINVITE C

INVITE CINVITE C

(terminating services

for C)

INVITE C

INVITE C

INVITE C

Figura 18. Flujo redirección de llamada

La principal diferencia entre estos dos escenarios es la ejecución de los servicios

originantes del destino original. Esto tiene diversas implicaciones. Una de ellas

puede ser la aplicación de servicios de restricción de llamada. Por ejemplo, si el

operador del destino original hubiera decidido aplicar una restricción de todas las

llamadas salientes al usuario, por un impago por ejemplo, esta restricción haría que el

desvío no funcionase. Esta restricción se aplicaría en el disparo originante. Sin

embargo, en el escenario de redirección, al no aplicarse los servicios originantes del

usuario, esta restricción no aplicaría, y la llamada llegaría al nuevo destino.

Otra implicación es la facturación, los desvíos de llamadas provocan un cobro

adicional al destino original, el de la nueva llamada. En el segundo caso, ese cobro

no se realiza. Las implicaciones de la aplicación de uno u otro escenario dependen de

la configuración del núcleo de red.


58

Routing a pbx no registrada

Para la integración con elementos no registrados es necesario que al servidor de

aplicaciones realice un enrutado especial. Esto es debido a que el núcleo IMS no

es capaz de determinar dónde se encuentran estos usuarios al no haberse

producido un registro. Para ello, el servidor de aplicaciones debe añadir una

cabecera Route, que fuerce al núcleo de la red IMS a encaminar la llamada

directamente a la PBX No registrada.

4.3.6 PBX Registrada

La PBX registrada ha sido desplegada en solitario sobre una máquina virtual. Se han

definido dos interfaces SIP en dicha máquina virtual. La primera, perteneciente a la red

IMSLab_network, que es utilizada como punto de conexión con el P-CSCF. La otra

interfaz SIP, es la interfaz con la máquina física o interfaz local, que da acceso a los

usuarios de la centralita.

Como ya se ha comentado, los usuarios tienen varias opciones a la hora de acceder a los

servicios prestados por la red IMS. Anteriormente se ha hablado de la primera opción, la

de darse de alta como usuarios de la red IMSLab y acceder a la red directamente

registrándose en el core IMS. Es el momento de hablar de la segunda opción. En este

caso los usuarios pueden darse de alta como usuarios de la PBX registrada, y acceder a

los servicios de la red IMS a través de ésta.

Estos usuarios serán dados de alta en REG PBX y se registrarán a través de ésta usando

la interfaz local de la centralita3. En este caso, el número de cabecera de la centralita

será dado de alta como usuario del HSS y las extensiones de la centralita se añadirán

como IMPUs de dicho número de cabera. Esto implicará, que cuando la centralita se

registre en el HSS, todas las extensiones asociadas a la centralita se considerarán

registradas.

Todas las llamadas salientes de la centralita serán enrutadas a través del P-CSCF, y

todas las llamadas hacia una extensión de dicha centralita serán enrutadas hacia ésta,

independientemente de que la extensión esté realmente registrada en la centralita o no.

En el caso, de que dicha extensión no esté realmente registrada, será la centralita la

encargada de notificar del destino inalcanzable.

3 Para hacer posible esta conexión ha sido necesario añadir en la máquina virtual donde está desplegada la PBX

registrada un reenvío desde el puerto 18060 local al puerto 8060 de la máquina virtual


59

4.3.7 PBX No registrada

La PBX No registrada es la tercera opción que tiene un usuario para acceder a los servicios

prestados por la red IMS. La PBX No registrada ha sido desplegada en solitario sobre una

máquina virtual, y, al igual que en el caso de la PBX registrada, se han definido dos interfaces

SIP. La primera interfaz SIP pertenece a la red IMSLab_network, pero en este caso, es

utilizada como punto de conexión, con el S-CSCF. La otra interfaz SIP, es la interfaz con la

máquina física o interfaz local, que da acceso a los usuarios de la centralita, análogamente al

caso de la PBX registrada.

Los usuarios de la centralita no registrada serán dados de alta en UNREG PBX y se

registrarán en ésta usando la interfaz local de la centralita4. En este caso, estos usuarios

accederán a la red IMS a través de un Trunk, disparando directamente al S-CSCF. Será

necesario dar de alta en el HSS dos PSIs, una que ejecutará los servicios originantes para las

extensiones de la centralita y otra que ejecutará los servicios terminantes de dicha centralita.

Estos usuarios serán usuarios no registrados y, por tanto, no será necesario su registro en el

core IMS para la prestación de los servicios.

En la Figura 19. Puntos de entrada al core IMS., se muestra los puntos de entrada al core IMS

y la conexión de éste con el AS. Merece la pena destacar, las tres opciones que tienen los

usuarios a la hora de acceder a los servicios de la red IMS.

- Como usuarios de la red IMS

- Como usuarios de la PBX registrada

- Como usuarios de la PBX No registrada

4 Para hacer posible esta conexión ha sido necesario añadir en la máquina virtual donde está desplegada la PBX

no registrada un reenvío desde el puerto 28060 local al puerto 8060 de la máquina virtual


60

REG PBX

AS

UNREG PBX

IMSopen-ims.lab.es

asterisk(registered pbx)

SIP Phone

12

7.0

.0.1

:18

06

0

172.16.0.10/24:8060

asterisk(application

server config)

172.16.0.70/24:7060

asterisk(unregistered

pbx)

SIP Phone

12

7.0

.0.1

:28

06

0

172.16.0.20/24:8060

SIP Phone

P-CSCF 127.0.0.1:44060

P-CSCF172.16.0.40/24:4060 SIP tru

nk

SCSCF 172.16.0.60/24:6060

Figura 19. Puntos de entrada al core IMS.

Adicionalmente a los puntos de entrada comentados anteriormente, se ha representado

en la Figura 19. Puntos de entrada al core IMS., la conexión del core IMS con el

Servidor de Aplicaciones. Como se puede apreciar, el punto de conexión del Servidor

de Aplicaciones con el core IMS es el S-CSCF.


61

5 Resultados

Como se comentó en el punto 4.3, se ha elegido desplegar cada nodo en una máquina virtual.

Cada una de las máquinas virtuales que alojan un nodo de la red IMS se ha interconectado

entre sí con el resto de nodos a través de una red virtualizada. Todas las pruebas realizadas

han sido hechas sobre esta arquitectura de despliegue. A continuación se explicarán con

detalle las pruebas realizadas y los resultados obtenidos.

5.1 Llamada desde una extensión de PBX a otra extensión de la misma PBX

Para esta prueba registraremos dos softphones en una de las PBX. En este caso, es indiferente

el tipo de PBX. Así que podremos utilizar la pbx registrada RPBX o la pbx no registrada

UPBX. Para la prueba en cuestión se ha utilizado la pbx registrada, en concreto las dos

primeras extensiones de dicha pbx. Se usará como extensión A, la extensión 231 y como

extensión B, la extensión 232.

Figura 20. Configuración Softphone para la RPBX

Ext A

Figura 21. Configuración Softphone para la RPBX

Ext B


62

El proceso de registro, tal y como se indicaba en el punto ‘Proceso de registro’, se

realiza, en este caso, contra la pbx. Por lo tanto el proceso de registro es local y todos

los mensajes SIP serán manejados por la pbx, tal y como se indica en la Figura 22

SIP Phone A RPBX

(1)REGISTER

(2) 401 Unauthorized

(3)REGISTER

(4) 200 OK

Figura 22. Proceso de registro contra una PBX

Una vez registrados ambos softphones en la pbx, realizaremos una llamada desde el

softphone donde hemos registrado la extensión A hasta la extensión B, marcando por

número corto. Es decir, que marcaremos 232. La llamada llegará a la extensión B, quien

descuelga el teléfono y comprobamos que hay audio en ambos sentidos. La marcación

por número corto le indica a la pbx que la llamada es una llamada local, por lo que al

analizar las trazas de red con wireshark comprobaremos que la llamada no ha salido de

la pbx. En este caso, la propia pbx ha enrutado la llamada hacia el destino local sin

enrutar la llamada hacia el core IMS. En la Figura 23 se puede ver el flujo observado en

las trazas de red.

SIP Phone A RPBX

(1)INVITE

(3) 100 Trying

SIP Phone B

(2)INVITE

(4)180 Ringing

(6) 200 OK

(8)ACK

(5) 180 Ringing

(7) 200 OK

(9)ACK

Figura 23. Flujo llamada local de la PBX


63

5.2 Llamada de SIP a SIP

Para esta prueba registraremos los softphones contra el P-CSCF, de manera que serán

usuarios de la red IMS y se registrarán en el HSS.

Figura 24. Configuración softphone SIP A

Figura 25. Configuración softphone SIP C

El proceso de registro en este caso, se realizará acorde a lo mostrado en la Figura 9. Una vez

registrados ambos softphones, se realizará una llamada desde el número A al número C.

Cuando la llamada llegue al destino, el número C descolgará la llamada y se comprobará que

existe audio en ambos sentidos.

Tras la realización de la prueba, se puede comprobar analizando las trazas de red, que el flujo

de la llamada se corresponde con el mostrado en la Figura 10. Es importante utilizar el usuario

A y el usario C para realizar esta prueba, puesto que en el servidor de aplicaciones se ha

configurado algunos servicios a los usuarios. De manera que, si usaramos para esta prueba al

usuario B como usuario terminante, tendríamos un cambio de destino y la llamada terminaría

llegando a C. O si, en vez de hacer la llamada desde A hasta C, hiciéramos la llamada desde C

hasta A, tendríamos un desvío de llamada configurado y la llamada terminaría llegando de

nuevo


64

5.3 Llamada SIP a SIP con Desvío incondicional a otro SIP

Para esta prueba registraremos los softphones contra el P-CSCF, de manera que serán usuarios de

la red IMS y se registrarán en el HSS, al igual que en la prueba del apartado 5.2.

Usaremos los usuarios A, B y C por lo que utilizaremos los datos reflejados en la Figura 24,

Figura 26 y la Figura 25, respectivamente.

Figura 26. Configuración softphone SIP B

El proceso de registro en este caso y al igual que sucedía en la prueba expuesta en el

punto 5.2, se realizará acorde a lo mostrado en la Figura 9. Una vez registrados todos

softphones, se realizará una llamada, esta vez desde el número B al número A. En el

servidor de aplicaciones se ha configurado un desvío incondicional para el número A, lo

que implica que todas las llamadas dirigidas al número A nunca llegarán a su destino

original, serán desviadas hacia el número C. Cuando la llamada llegue al destino final,

el número C descolgará la llamada y se comprobará que existe audio en ambos sentidos.

Tras la realización de la prueba, se puede comprobar analizando las trazas de red, que el

flujo de la llamada se corresponde con el mostrado en la Figura 17. Es importante

prestar especial interés en que, tal y como se explicaba en el punto 4.3.5. Servidor de

aplicaciones sección Escenarios de Cambio de destino en terminante, en este caso,

habrá revaluación de triggers originantes del destino original y terminantes del nuevo

destino.


65

5.4 Llamada SIP a SIP con Re-Routing a otro SIP

Para esta prueba se usarán los tres usuarios utilizados en el punto 5.3, por lo que utilizaremos

los datos reflejados en la Figura 24, Figura 26 y la Figura 25, respectivamente, para el

registro.

El proceso de registro en este caso y al igual que sucedía en las pruebas expuestas en los

puntos 5.2 y 5.3, se realizará acorde a lo mostrado en la Figura 9. Una vez registrados todos

softphones, se realizará una llamada, esta vez desde el número A al número B. En el servidor

de aplicaciones se ha configurado un re-routing para el número B, lo que implica que todas las

llamadas dirigidas al número B nunca llegarán a su destino original, sino que serán re-

enrutadas hacia el número C. Cuando la llamada llegue al destino final, el número C

descolgará la llamada y se comprobará que existe audio en ambos sentidos. Tras la realización

de la prueba, se puede comprobar analizando las trazas de red, que el flujo de la llamada se

corresponde con el mostrado en la Figura 18. Flujo redirección de llamada. Es importante

prestar especial interés en que, tal y como se explicaba en el punto 4.3.5. Servidor de

aplicaciones sección Escenarios de Cambio de destino en terminante, en este caso, habrá sólo

revaluación de triggers terminantes del nuevo destino, por encontrarnos ante un caso de re-

enrutado.

5.5 Llamada desde una extensión de PBX no Registrada a un SIP

Para esta prueba se usará un usuario SIP y una extensión de una pbx no registrada. Como

usuario SIP usaremos al usuario C, puesto que no tiene servicios terminantes configurados en

el servidor de aplicaciones. Si utilizáramos cualquiera de los otros dos usuarios, B o C,

veríamos que independientemente de que la llamada haya sido originada en una PBX no

registrada, al llegar a la parte terminante, se aplicaría el desvío de llamada o el reenrutado, tal

y como ocurría en las pruebas expuestas en los puntos 5.3 y 5.4. Por tanto, para el registro de

la extensión SIP C utilizaremos los datos reflejados en la Figura 25. Configuración softphone

SIP C, y para el registro de la extensión de la pbx no registrada utilizaremos los datos

reflejados en la Figura 27


66

Figura 27. Configuración softphone para la UPBX Ext A

El proceso de registro en este caso y al igual que sucedía en la prueba expuesta en el

punto 5.1, se realizará acorde a lo mostrado en la Figura 22. Proceso de registro contra

una PBXFigura 9. Una vez registrados todos softphones, se realizará una llamada, esta

vez desde la extensión de PBX, UPBX_Ext_A al número C. Cuando la llamada llegue

al destino, el número C descolgará la llamada y se comprobará que existe audio en

ambos sentidos. Tras la realización de la prueba, se puede comprobar analizando las

trazas de red, que el flujo de la llamada se corresponde con el mostrado en la Figura 11.

Es necesario hacer especial hincapié en el disparo de servicios IMS a través de PSI

(Public Service Identity), ya que es el único modo de prestar servicios IMS a usuarios

que no están registrados en la red IMS.


67

5.6 Llamada desde un SIP a una extensión de PBX no Registrada

Para esta prueba se usará un usuario SIP y una extensión de una pbx no registrada. Al igual

que en el punto 5.5, se usará como usuario SIP al usuario C, en este caso, es irrelevante qué

usuario SIP usar, puesto que no hay servicios originantes configurados para ninguno de ellos.

Por tanto, para el registro de la extensión SIP C utilizaremos los datos reflejados en la Figura

25. Configuración softphone SIP C, y para el registro de la extensión de la pbx no registrada

utilizaremos los datos reflejados en la Figura 27.

El proceso de registro en este caso y al igual que sucedía en la prueba expuesta en los puntos

5.1 y 5.5, se realizará acorde a lo mostrado en la Figura 22. Proceso de registro contra una

PBXFigura 9. Una vez registrados todos softphones, se realizará una llamada, esta vez desde

el usuario SIP C hasta la extensión de PBX, UPBX_Ext_A. Cuando la llamada llegue al

destino, la extensión de PBX descolgará la llamada y se comprobará que existe audio en

ambos sentidos. Tras la realización de la prueba, se puede comprobar analizando las trazas de

red, que el flujo de la llamada se corresponde con el mostrado en la Figura 12. De nuevo, es

necesario hacer especial hincapié en el disparo de servicios IMS a través de PSI (Public

Service Identity), en este caso, en la parte terminante y, en este caso, también es necesario

hacer especial hincapié en el enrutado hacia la PBX, explicado en el punto 0.


68


69

6 Conclusiones

6.1 Conclusiones

Desde el punto de vista de los conocimientos adquiridos por el proyectante, se puede

decir que la elección de las herramientas a utilizar ha sido una gran elección. Kamailio y

Asterisk fueron elegidas inicialmente basándose en la lectura de una serie de artículos

en internet, donde eran recomendados. Tras la elaboración del proyecto y tras el

conocimiento adquirido sobre estas herramientas, ha de ser en este caso el propio

proyectante quien recomiende su uso.

Kamailio y Asterisk son herramientas que implementan los dos tipos de nodos que

existen en una red IMS, un SIP Proxy y un B2BUA respectivamente, por lo que

cualquier nodo existente en una red IMS podrá ser simulado con una instancia de

Asterisk o con una instancia de Kamailio. Además, ambos son enteramente

configurables, lo que hace posible mediante configuración hacerlos funcionar como lo

haría cualquier nodo de una red IMS y además, y más importante, hace necesario el

conocimiento total sobre el estándar y el funcionamiento de cada nodo para ser capaz de

configurar los nodos. Esto obliga a la investigación, estudio y conocimiento del

estándar, lo que hace atractivo su uso para instar al aprendizaje.

Tras la elaboración del proyecto, el proyectante ha adquirido un conocimiento profundo

sobre el protocolo SIP, sobre las redes IMS, sobre el funcionamiento de un SIP Proxy y

de un B2BUA y las diferencias entre ellos. Por este motivo, tras la realización del

proyecto el proyectante es capaz de pensar en la mejor manera de introducir nuevas

funcionalidades a la red, si se debería usar un SIP Proxy o un B2BUA para ello y qué

implicaría en cada caso.

Finalmente, el objetivo del proyecto era proporcionar un banco de pruebas sobre un

entorno virtualizado, de manera que fuera posible, tanto para el alumnado como para el

profesorado, experimentar con una red IMS. Dicho objetivo se ha visto cubierto con la

elaboración del proyecto; tanto que se puede afirmar que, tras la realización del

proyecto y tras el análisis y observación de las pruebas realizadas, se concluye que el

laboratorio IMS desplegado es fiel a la realidad y respeta el estándar de SIP. El tráfico

de red generado por las pruebas realizadas se ajusta a lo esperado teóricamente, por lo

que, el laboratorio IMS es una estupenda herramienta para la docencia y también para la

investigación y análisis de las redes IMS.


70

6.2 Trabajos futuros

A pesar de que el objetivo inicial del proyecto se haya visto cubierto tras su realización, es

necesario apuntar que dicho proyecto podría ser ampliado de diversas formas para

proporcionar un entorno con más funcionalidades. Dichas ampliaciones incluyen tanto

funcionalidades futuras que a día de hoy ni siquiera se conocen y que pueden ser introducidas

sobre las redes IMS en el futuro, como funcionalidades que ya existen pero que no se han

introducido en esta fase del proyecto.

No se puede hablar sobre aquellas funcionalidades futuras, puesto que se desconocen en este

momento. Lo que sí es posible es comentar algunas de las funcionalidades que ya existen en

redes IMS desplegadas en entornos de producción, pero que sin embargo, se han dejado fuera

del despliegue actual. A continuación se pasará a enumerar y describir brevemente algunas de

estas funcionalidades:

- Tráfico IPTV: se ha excluido el tráfico IPTV del laboratorio, siendo posible incluir

fácilmente otro Servidor de aplicaciones dedicado exclusivamente al tráfico IPTV en el

futuro. Es necesario destacar, que el establecimiento de sesión para este tipo de tráfico es

idéntico al intercambio de mensajes entre los nodos de la red para establecer una sesión de

voz sobre IP y el protocolo SIP es utilizado también para estos casos. La diferencia entre

ambos tipos de tráfico, VOIP o IPTV, radica en el protocolo RTP que se intercambia entre

los dispositivos finales o entre los nodos B2BUA y los dispositivos finales. Por otro lado,

se indica que Asterisk no soporta IPTV por lo que se deberá buscar otro software de código

abierto para proporcionar dichos servicios, como por ejemplo Open Streaming Server.

- Servidor de Presencia: no se ha definido ningún servidor de presencia en el laboratorio.

Sería posible la intrusión de un servidor de presencia que se encargue del procesamiento de

los mensajes SUBSCRIBE y NOTIFY, ofreciendo información de estado a los usuarios y

permitiendo la utilización de algunos softphones, como por ejemplo, a partir de la versión

12 del softphone 3CX, que requiere un servidor de presencia para registrarse correctamente

en la red IMS. Este servidor de presencia o PE puede ser implementado usando Kamailio

como software.

- Servidor de locuciones o MS: no se ha introducido ningún servidor de locuciones en el

laboratorio que proporcione locuciones informando al usuario cuando un error se ha

producido en el AS o en el propio core IMS por ejemplo. Para este cometido podría

utilizarse Asterisk.

- Nodo IVR: De manera similar al servidor de locuciones, el IVR es un servidor de

media que permite al usuario interactuar. Por ejemplo, en el caso anterior en el que

un error se produce en el AS o en el core IMS, un nodo IVR informaría del error al

usuario proporcionándole además varias acciones a realizar, por ejemplo, abandonar

la llamada o intentarlo con otro destino en caso de que el error sea destino

inalcanzable o incluso conectar la llamada con el número de soporte del operador en

caso de que el error sea un error grave de red, dando la oportunidad al usuario


71

mediante marcación por tonos o DTMFs de elegir una de ellas. Una vez recibido el

código DTMF en el nodo IVR, el nodo IVR debe informar al AS o al core IMS de la

acción elegida por el usuario para llevarla a cabo. En este caso se suelen utilizar

mensajes INFO para dicha comunicación. Para este cometido también es posible

utilizar Asterisk como nodo IVR, puesto que Asterisk soporta códigos DTMF.

- Nodos de interconexión de redes: como se han indicado varias veces durante el

proyecto, para simplificar, sólo se ha desplegado una red IMS. En este caso, la

propuesta de mejora, sería la de desplegar dos o más redes IMS con diferentes

dominios utilizando nodos de interconexión de redes como el BGCF. De este modo,

se podría analizar y estudiar el comportamiento de la red cuando el usuario llamante

se encuentra registrado en un dominio diferente al dominio al que pertenece la red

donde se encuentra registrado el usuario llamado.

- Implementación de un softphone que simule a los dispositivos VoLTE: el software

utilizado en el laboratorio, Kamailio y Asterisk soportan VoLTE, sin embargo, no

existe en el momento de la elaboración del proyecto ningún softphone gratuito que

simule el comportamiento de los dispositivos VoLTE. Por tanto, sería buena idea

implementar un softphone que introdujera las características de dichos dispositivos

para poder estudiar y analizar las diferencias con softphones de voz sobre IP.

Algunas de las características que introducen estos dispositivos a la red IMS serían:

Reserva de recursos anterior al ringing del terminal destino realizando una

negociación de precondiciones. Debido a esta reserva de recursos, se introducen

cambios importantes en el protocolo SDP y en la señalización SIP de

establecimiento de la llamada.

El uso obligado de los mensajes PRACKs o ACKs a respuestas provisionales,

antes de VoLTE este mensaje ya existía, pero su uso no era obligado. En el caso

de los terminales VoLTE su uso es obligado para garantizar la continuidad de la

llamada cuando se produce un cambio de cobertura. (de 4G a 3G)

El uso obligado de los mensajes UPDATE, como ocurre con los PRACKs, el

mensaje UPDATE ya existía anteriormente, sin embargo era un mensaje que era

utilizado por los nodos de red, no por los dispositivos. Con las redes VoLTE es

necesario el uso de dicho mensaje por los dispositivos ya que en el

establecimiento de llamada se realiza una reserva de recursos (precondiciones)

que debe ser actualizada antes de establecerse la llamada definitivamente.

Uso obligado de las cabeceras Supported/Required

Como ya se ha comentado anteriormente, estas son sólo algunas de las líneas en las que

se puede continuar el trabajo comenzado con este proyecto. Como se puede ver, las

posibilidades son muchas y variadas.


72


73

7 Referencias

[3.1]. Virtual Box. [En línea] https://www.virtualbox.org/.

[3.10]. MySQL. [En línea] https://www.mysql.com/.

[3.11]. Postgres. [En línea] http://www.postgresql.org.es/.

[3.12]. Oracle Database. [En línea] https://www.oracle.com/database/index.html.

[3.13]. Wikipedia. DNS Server. [En línea]

https://es.wikipedia.org/wiki/Domain_Name_System.

[3.14]. Telephone Number Mapping. Enum. [En línea]

https://en.wikipedia.org/wiki/Telephone_number_mapping.

[3.15]. Bind. [En línea] https://www.isc.org/downloads/bind/.

[3.16]. Sleipner. [En línea] http://sleipner.software.informer.com/.

[3.17]. Kapanga. [En línea] http://www.kapanga.net/IP/home.cfm.

[3.18]. PhonerLite. [En línea] http://phonerlite.de/index_en.htm.

[3.19]. X-Lite. [En línea] http://www.counterpath.com/x-lite/.

[3.2]. Kamailio. [En línea] https://www.kamailio.org/w/.

[3.20]. Zoiper. [En línea] http://www.zoiper.com/en.

[3.21]. MobaXTerm. [En línea] http://mobaxterm.mobatek.net/.

[3.21]. WireShark. [En línea] https://www.wireshark.org/.

[3.3]. OpenSIPS. [En línea] http://www.opensips.org/.

[3.4]. Asipto. [En línea] http://www.asipto.com/sw/.

[3.5]. AG Project. [En línea] http://ag-projects.com/.

[3.6] . Diameter Protocol. RFC 6733. [En línea] https://tools.ietf.org/html/rfc6733.

[3.7]. FHoSS. [En línea] http://www.openimscore.org/docs/FHoSS/index.html.

[3.8]. Asterisk. [En línea] http://www.asterisk.org.

[3.9]. RTP Proxy. [En línea] http://www.rtpproxy.org/.

[6.21]. Open Streaming Server. [En línea] https://sourceforge.net/projects/openstreaming/.


74

Anónimo. 2012. [F01]Creada con Microsoft Visio 2010 tomando como referencia

Arquitectura IMS. Edadmovil. [En línea] 2012.

https://edadmovil.files.wordpress.com/2012/08/ims2.jpg. Figura 1. Arquitectura red IMS:

Estructuración en Capas.

Benayas, Esther. 2016. [F02] Modelo de subscripción (HSS). [En línea] 2016. Figura 2.

Modelo de subscripción (HSS).

Benayas, Esther. 2016. [F03] Trigger Points - Search Results. Fokus testbed. IMSLab:

Captura de la interfaz web del HSS (FHoSS). [En línea] 2016.

http://127.0.0.1:8888/hss.web.console/. Figura 3. Trigger Points definidos..

Benayas, Esther. 2016. [F04] Trigger Points - Search Results. Fokus testbed. IMSLab:


http://127.0.0.1:8888/hss.web.console/. Figura 4. Trigger point para usuarios llamantes.

Benayas, Esther. 2016. [F05] Application Server - Search Results. Fokus testbed. IMSLab:


http://127.0.0.1:8888/hss.web.console/. Figura 5. Ejemplo de Application Server definidos en

el HSS.

Benayas, Esther. 2016. [F06] Initial Filter Criteria - Search Results. Fokus testbed. IMSLab:


http://127.0.0.1:8888/hss.web.console. Figura 6. iFCs.

Benayas, Esther. 2016. [F07] Trigger Point -PT-. Fokus testbed. IMSLab: Captura de la

interfaz web del HSS (FHoSS). [En línea] 2016. http//:127.0.0.1:8888/hss.web.console/.

Figura 7. Ejemplo de configuración de un iFC.

Benayas, Esther. 2016. [F08] Service Profile -SP-. Fokus testbed. IMSLab: Captura de la

interfaz web del HSS (FHoSS). [En línea] 2016. http://127.0.0.1:8888/hss.web.console. Figura

8. Definición de un Service Profile.

Benayas, Esther. 2016. [F09] Creado con Microsoft Visio 2010. [En línea] 2016. Figura 9.

Flujo de registro de un usuario IMS.

Benayas, Esther. 2016. [F10] Creado con Microsoft Visio 2010. [En línea] 2016. Figura 10.

Flujo de una llamada simple IMS – IMS.

Benayas, Esther. 2016. [F11] Creado con Microsoft Visio 2010. 2016. Figura 11. Flujo

llamada PBX_NoReg – SIP.


llamada SIP - PBX_NoReg.

Benayas, Esther. 2016. [F13] Creado con Microsoft Visio 2010. 2016. Figura 13. Routing.

Benayas, Esther. 2016. [F14] Creado con Microsoft Visio 2010. 2016. Figura 14.

Arquitectura de despliegue.


75

Benayas, Esther. 2016. [F15] Creado con Microsoft Visio 2010. 2016. Figura 15.

Arquitectura de despliegue detallada.

Benayas, Esther. 2016. [F16] Application Server - Search Results. Fokus testbed. IMSLab:


http://127.0.0.1:8888/hss.web.console. Figura 16. Configuración disparos HSS.


Desvío de llamada.


redirección de llamada.

Benayas, Esther. 2016. [F19] Creado con Microsoft Visio 2010. 2016. Figura 19. Puntos de

entrada al core IMS.

Benayas, Esther. 2016. [F20] Softphone Sleipner: Captura de la interfaz de configuración.

2016. Figura 20. Configuración Softphone para la RPBX Ext A.


2016. Figura 21. Configuración Softphone para la RPBX Ext B.

Benayas, Esther. 2016. [F22] Creado con Microsoft Visio 2010. 2016. Figura 22. Proceso de

registro contra una PBX.


llamada local de la PBX.


2016. Figura 24. Configuración softphone SIP A.


2016. Figura 25. Configuración softphone SIP B.


2016. Figura 26. Configuración softphone SIP C.


2016. Figura 27. Configuración softphone para la UPBX Ext A.

Benayas, Esther. 2016. [F28] VirtualVox: Captura de la interfaz de configuración. Pantalla

Nombre y Sistema Operativo. 2016. Figura 29. Pantalla Nombre y Sistema Operativo.

Benayas, Esther. 2016. [F30] VirtualBox: Captura de la interfaz de configuración. Pantalla

Tamaño de memoria. 2016. Figura 30. Pantalla Tamaño de memoria.

Benayas, Esther. [F31] VirtualBox: Captura de pantalla Crear disco duro virtual (1). Figura

31. Tipo de archivo de disco duro.


76

Benayas, Esther. [F32] VirtualBox: Captura de pantalla Crear disco duro virtual (2). Figura

32. Ubicación y tamaño del disco duro virtual.

Benayas, Esther. [F33] VirtualBox: Captura de pantalla Configuración - Almacenamiento.

Figura 33. Cargar imagen iso en la unidad de CD virtual.

Benayas, Esther. [F34] VirtualBox: Captura de pantalla Configuración - Network. Figura

34. Adaptador de red, interfaz red interna.

Benayas, Esther. [F35] VirutalBox: Captura pantalla Configuración - Network. Figura 35.

Adaptador de red, interfaz con la máquina física.

Benayas, Esther. [F36] VirtualBox: Captura de pantalla Configuración - Network - Reenvío

de puertos. Figura 36. PCSCF, reglas de reenvío de puertos.

Benayas, Esther. [F37] VirtualBox: Captura de pantalla configuración - Network - Reenvío

de puertos. Figura 37. PBX, reglas de reenvío de puertos.

Benayas, Esther. [F38] VirtualBox: Captura de pantalla Configuración - Network - Reenvío

de puertos. Figura 38. HSS, reglas de reenvío de puertos.

Benayas, Esther. [F39] VirtualBox: Captura de pantalla Configuración - Sistema. Figura 39.

Orden de arranque.

Benayas, Esther. 2016. [F40]. Fokus testbed. IMSLab: Captura de la interfaz web del HSS

(FHoSS). [En línea] 2016. http://127.0.0.1:8888/hss.web.console. Figura 40. Pestaña Services.

Benayas, Esther. 2016. [F41] User Identities. Fokus testbed. IMSLab: Captura de la interfaz

web del HSS (FHoSS). [En línea] 2016. http://127.0.0.1:8888/hss.web.console. Figura 41.

Pestaña User Identities.

Benayas, Esther. 2016. [F42] Public User Identity - Search Results. Fokus testbed. IMSLab:


http://127.0.0.1:8888/hss.web.console. Figura 42. IMPUs.

Benayas, Esther. 2016. [F43] Private User Identity -IMPI-. Fokus testbed. IMSLab: Captura

de la interfaz web del HSS (FHoSS). [En línea] 2016. http://127.0.0.1:8888/hss.web.console.

Figura 43. Definición de una pbx-reg.

Benayas, Esther. 2016. [F44] Public User Identity -IMPU-. Fokus testbed. IMSLab: Captura


Figura 44. Configuración PSI.



Figura 45. PSI para servicios originantes.


77



Figura 46. PSI para servicios terminantes.

Benayas, Esther. [F47] Squirrel: Captura de pantalla Configuración. Figura 47.

Configuración de conexión a las bases de datos.

Benayas, Esther. [F48] MobaXTerm: Captura prompt usuario. Figura 48. Prompt usuario

ims.

Benayas, Esther. [F49] MobaXTerm: Captura directorio ftp. Figura 49. Contenido $HOME

del usuario ims.

Benayas, Esther. [F50] MobaXTerm: Captura diretorio ftp. Figura 50. Contenido directorio

interfacesConf.

Benayas, Esther. [F51] MobaXTerm: Captura directorio ftp. Figura 51. Contenido directorio

Asterisk-AS.


Asterisk-AS/bin.


Asterisk-AS/etc.


Asterisk-PBX.

Benayas, Esther. [F55] MobaXTerm: Captura directorio ftp. Figura 55.Contenido directorio

Asterisk-PBX/reg-pbx.


DNSServer.


DNSServer/bin.


DNSServer/deploy.


DNSServer/etc.


logs.


om.


78


OpenIMSCore.


OpenIMSCore/FHoSS.


OpenIMSCore/FHoSS/bin.


OpenIMSCore/FHoSS/conf.


OpenIMSCore/X-CSCF.


OpenIMSCore/X-CSCF/bin.


OpenIMSCore/X-CSCF/etc.


OpenIMSCore/X-CSCF/etc/icscf.


OpenIMSCore/X-CSCF/etc/pcscf.


OpenIMSCore/X-CSCF/etc/scscf.


RTPProxy.


STUNServer.

Benayas, Esther. [F74] WireShark: captura pantalla tráfico. Figura 74. Captura de tráfico

desde WireShark.

Benayas, Esther. [F75] WireShark: Configuración - Protocolos. Figura 75. Configuración

WireShark para decodificar Diameter.

Benayas, Esther. [F76] WireShark: Captura pantalla VoIP Calls. Figura 76. WireShark.

Ventana emergente de VoIP Calls.

Benayas, Esther. [F77] WireShark: Captura pantalla VoIP Calls. Figura 77. Flujo VoIP

Calls parte 1.

Benayas, Esther. [F78] WireShark: Captura pantalla VoIP Calls. Figura 78. Flujo Voip

Calls parte 2.


79

Benayas, Esther. [F79] WireShark: Captura pantalla VoIP Calls. Figura 79. Flujo VoIP

Calls parte 3.


80


81

8 Bibliografía

[A.1]. Amazon. [En línea] [Citado el: 12 de 02 de 2017.] https://www.amazon.es/Dell-

Latitude-E5550-Ordenador-

port%C3%A1til/dp/B00SBNL4NK/ref=sr_1_2?ie=UTF8&qid=1486925785&sr=8-

2&keywords=latitude+e5550.

[A.2]. Doiser. [En línea] [Citado el: 12 de 02 de 2017.] https://www.doiser.com/renting-

ordenadores-portatiles-expertus-servicios-informaticos.html.

[A.3] . Licencias Legales. [En línea] Windows 7. [Citado el: 12 de 02 de 2017.]

http://licenciaslegales.eu/sistemas-operativos/57-windows-7-professional-64bit-download-

0885370258998.html.

[A.4]. Licencias legales. [En línea] Microsoft Office. [Citado el: 12 de 02 de 2017.]

http://licenciaslegales.eu/office/10-microsoft-office-2010-home-business-download-

0885370025095.html?search_query=office&results=1.

[A.5]. TresBizz. [En línea] Microsfot Visio Professional 2010. [Citado el: 12 de 02 de 2017.]

http://www.tresbizz.com/es/es/software/office/office-2010/microsoft-visio-professional-

2010.html.


82


83

Anexo A. Presupuesto

En la elaboración del proyecto en curso se ha hecho uso de unos determinados recursos de

hardware, de software y humanos por los que se ha incurrido en un coste. A continuación se

pasará a exponer de manera detallada cuál ha sido el coste de la elaboración del proyecto.

En lo referente al equipamiento, se ha utilizado un portátil con las siguientes características:

- Intel Core i5 con 2.3 GHz y 8GB de memoria Ram con Windows 7 Enterprise instalado.

Se ha investigado tanto la opción de compra como la opción de alquilar el equipo. Ambas

opciones tienen sus ventajas y sus inconvenientes. La primera opción tiene un coste elevado

de aproximadamente 1000€, pero el coste sería fijo y conocido desde el inicio del proyecto,

por otro lado, la segunda opción sería la más económica pero sería difícil de saber con

exactitud cuál será el coste real. El alquiler de un equipo con estas características es de

aproximadamente 30€/mes. Sin embargo, las empresas de Renting informático suelen exigir

un periodo mínimo del alquiler que suele estar alrededor de 3 años. Si sumamos todas las

cuotas de los 3 años que estamos obligados a mantener el alquiler del equipo el coste sería de

1089€. Por otro lado, si suponemos que el proyecto sólo asumirá el coste del alquiler del

equipo durante el tiempo necesario para la elaboración del proyecto, el coste de alquiler es

mucho menor que el de compra del equipo, 100€.

En cuanto a la licencias del sistema operativo y del software utilizado para la elaboración de

la memoria, tenemos lo siguiente:

Microsoft Windows 7 Enterprise 30€.

Microsoft Visio 242€

Microsoft Office 99,90€

En cuanto al software utilizado para el despliegue del laboratorio, ha sido en todo momento

herramientas de libre distribución. Por lo que, no se ha realizado ningún gasto adicional en

licencias para la adquisición de este software.

Finalmente, el mayor incremento en el coste del proyecto se ha debido a las horas dedicadas a

investigación, diseño y desarrollo del proyectante. Las horas utilizadas para la elaboración del

proyecto han alcanzado las 250 horas. El sueldo medio de un graduado en Telecomunicaciones

con menos de 5 años de experiencia es de 25.730,70 € brutos/anuales según el escrito “El

Ingeniero de Telecomunicación: Perfil Socio-Profesional” [AnexoA.1] publicado por Colegio

Oficial de Ingenieros de Telecomunicación. Esto se corresponde con 14,619 € brutos/hora, por lo

que el coste de personal del proyecto asciende a 3654,92€.


84


85

Anexo B. Manual de usuario

B.1 Guía de Instalación

B.1.1 Preparación del entorno IMSLab

B.1.1.1 Preparación de la máquina virtual

Lo primero que necesitamos es una máquina virtual con un sistema operativo. En este caso, el

sistema operativo que se ha elegido ha sido Debian, primero en su versión Wheezy y más tarde

en su versión Jessy, como ya fue indicado en la sección 4.1. Para crear dicha máquina virtual

necesitaremos ejecutar Oracle VM VirtualBox, también mencionado en la sección 4.1.

Tras abrir la aplicación, utilizaremos el acceso directo “Nuevo” desde la barra de tareas o el

elemento “Nuevo” del menú “Máquina” para crear una máquina virtual nueva.

En la pantalla emergente debida a la función “Nuevo”, se nos pedirá el nombre que le queremos

dar a la máquina virtual, el tipo de sistema operativo que instalaremos en ella y finalmente si

instalaremos la versión de 32 bits o la de 64. La Figura 28 muestra lo datos utilizados para crear

la máquina virtual que dará soporte al laboratorio.

Figura 28. Pantalla Nombre y Sistema Operativo

A continuación haremos clic en el botón “Next”. La Figura 29 muestra la siguiente pantalla que

veremos y en la que se nos pide que especifiquemos la memoria RAM que será reservada para la

máquina virtual. En el caso del laboratorio se ha establecido un valor de 512MB.


86

Este tamaño será suficiente puesto que nuestro laboratorio no tiene una interfaz gráfica que

pudiera hacer más elevado el consumo de memoria RAM. Por otro lado, se ha considerado

oportuno ajustar lo máximo posible el tamaño de la memoria RAM reservada para cada

instancia de la máquina virtual, ya que varias instancias del laboratorio serán ejecutadas al

mismo tiempo (una por cada nodo) en una misma máquina física.

Figura 29. Pantalla Tamaño de memoria

Tras establecer el tamaño de la memoria RAM, tendremos que establecer las propiedades

del disco duro virtual. Elegiremos la opción “Crear un disco duro virtual ahora”, y le

daremos a “Next”. En la Figura 30Figura 30 se pueden ver los diferentes formatos que se

ofrecen para almacenar nuestro disco duro virtual. En el caso del laboratorio se ha

utilizado la primera opción, que es el formato por defecto utilizado por Virtual Box. Sin

embargo, quizás hubiera sido más acertado elegir la segunda opción “VMDK”. Este

formato es el formato por defecto utilizado por VMWare y compatible con Virtual Box.

De este modo tendríamos un disco duro que podría ser arrancado tanto desde Virtual Box

como desde VMWare. Sin embargo, es posible hacer la transformación después, por lo

que no debe preocuparnos en exceso el hacer una mala elección.


87

Figura 30. Tipo de archivo de disco duro

Después de decidir el formato en el que se almacenará el disco duro, tendremos que especificar

si queremos que el tamaño del disco duro debe ser “Reservado dinámicamente” o tendrá un

“Tamaño fijo”. En nuestro caso elegiremos la primera opción, eligiendo en la siguiente

pantalla (mostrada en la Figura 31) el tamaño máximo que alcanzará el disco duro y su

ubicación.

Es posible elegir un tamaño fijo para el disco duro, sin embargo, hay que tener en cuenta que

esto implicaría que nuestra máquina virtual ocupará todo el tamaño que elijamos como máximo

para nuestro disco duro estemos usando el espacio o no. Eligiendo la opción de reservar el

tamaño de forma dinámica, nuestra máquina virtual tendrá un tamaño real e irá creciendo a

medida que almacenemos más datos o instalemos más funcionalidades en el disco duro virtual.


88

Figura 31. Ubicación y tamaño del disco duro virtual

Una vez tengamos creada nuestra máquina virtual, el siguiente paso es la instalación del

sistema operativo.

Para ello debemos acceder a las pantallas de configuración de la máquina para cargar una

imagen iso con el sistema operativo Debian en la unidad de CD virtual y arrancar la

máquina para que arranque desde el CD-Rom, a partir de ese momento la instalación será

como sería en un sistema físico real.

Para cargar la imagen iso en la unidad de CD-Rom de la máquina virtual debemos ir a la

configuración de la máquina virtual. Hay varias maneras de hacerlo, desde usar el botón

“Configuración” del menú desplegable que surge al hacer clic con el botón derecho sobre

la máquina virtual, hasta seleccionar la máquina virtual y usar el acceso directo

“Configuración” de la barra de tareas. De cualquiera de las maneras, se arrancará la

pantalla de configuración de la máquina virtual, donde podremos ver las diferentes

configuraciones que hemos establecido durante la creación de la máquina pero también

otras. Por ejemplo, la configuración de red que veremos más adelante en esta misma

sección.

La configuración para la unidad de CD-Rom de la máquina virtual se encuentra en la

pantalla de “Almacenamiento”. Tras seleccionar el controlador IDE podemos cargar en la

unidad óptica la imagen iso del sistema operativo. Todo esto se muestra en la Figura 32.


89

Figura 32. Cargar imagen iso en la unidad de CD virtual

Una vez cargada la imagen iso con el sistema operativo, ya sólo queda configurar las interfaces

de red para tener acceso a internet, ya que durante la instalación es posible que necesitemos

acceso a internet.

B.1.1.2 Configuración de las interfaces de Red

En la misma pantalla de configuración está el menú de “Red”, donde podremos configurar

dichas interfaces. Como se comentó en la sección 4.3, cada instancia de la máquina virtual

tendrá dos interfaces de red configuradas, una interfaz perteneciente a la red virtualizada

IMSLab_network (172.16.0.80/24) y otra interfaz para hacer posible la comunicación con la

máquina física en la que están alojadas las máquinas virtuales.

Para configurar la primera interfaz, es decir, la perteneciente a la red virtualizada

IMSLab_network deberemos configurar en cada una de las máquinas virtuales un adaptador de

red asociado a una red interna. La Figura 33 muestra la configuración para el adaptador 1.


90

Figura 33. Adaptador de red, interfaz red interna

Para configurar la segunda interfaz, es decir, la interfaz con la máquina física utilizaremos el

adaptador 2. En este caso, configuraremos un adaptador de tipo NAT, es decir, un adaptador

que obtendrá su dirección IP de la propia máquina física.

Figura 34. Adaptador de red, interfaz con la máquina física


91

Lo más importante de esta configuración es el “Reenvío de puertos”. Mediante esta funcionalidad

seremos capaces de desviar todo el tráfico dirigido hacia un puerto de nuestra máquina física a un

puerto de la máquina virtual. Como ya se comentó en la sección Arquitectura de despliegue

utilizada, esta interfaz se hace necesaria en aquellos nodos en los que sirven de puntos de entrada a

la red virtualizada. En la Figura 35 se muestra la configuración necesaria para el PCSCF. En esta

imagen se puede ver dos reglas de reenvío de puertos. La primera es la regla que hace accesible el

puerto 4060 de la máquina virtual desde el exterior a través del puerto 44060. Esto significa que

para registrar un softphone en el core IMS desde la máquina física deberemos usar como proxy la

IP/puerto 127.0.0.1:44060.

Figura 35. PCSCF, reglas de reenvío de puertos

La segunda regla que se muestra en la Figura 35 es la regla que hace posible acceder a la máquina

virtual mediante sesiones de ssh. Esta regla no es necesaria pero sí muy útil como se comentó en

la sección Arquitectura de despliegue utilizada. Mediante esta regla se hace posible el acceso

mediante ssh a la máquina virtual que aloja al PCSCF a través del puerto 4022.

Figura 36. PBX, reglas de reenvío de puertos


92

En la Figura 36 se muestran las reglas de reenvío de puertos establecidas para las PBX. En

este caso la primera regla hace posible el registro desde un softphone instanciado en la

máquina física en la PBX registrada a través del puerto 1060. Esto significa que para

registrar un softphone en la PBX registrada desde la máquina física deberemos usar como

proxy la IP/puerto 127.0.0.1:1060. De manera análoga, en la configuración de la PBX no

registrada existirá una regla que redirige el puerto 2060 de la máquina física al puerto 8060

de la máquina virtual. De manera que para registrar un softphone que corre en la máquina

física en la PBX no registrada deberemos usar como proxy la IP/puerto 127.0.0.1:2060.

Para ambos casos, PBX registrada y no registrada, existirá una segunda regla que, al igual

que ocurre en la máquina virtual del PCSCF hace posible el acceso a la máquina virtual

usando ssh. Para el caso de la máquina virtual que aloja la PBX registrada se utilizará el

puerto 1022, mientras que para el caso de la PBX no registrada se utilizará el puerto 2022.

Figura 37. HSS, reglas de reenvío de puertos

En la Figura 37 se muestra la configuración para el desvío de puertos de la máquina virtual

que aloja al HSS y a los elementos adicionales. En este caso, nos encontramos con tres

reglas. La primera es la que hace posible el acceso a la interfaz web del HSS. Con esta regla

es posible acceder a dicha interfaz mediante un navegador web utilizando la url

http://127.0.0.1:8888/hss.web.console/

La segunda regla es la que hace posible el acceso a las bases de datos alojadas en el HSS de

forma remota. Estas son las bases de datos del propio HSS, del ICSCF y de Kamailio. Esta

regla tampoco es estrictamente necesaria, pero sí es muy útil, ya que permite la conexión a

las bases de datos desde clientes MySql gráficos, como pueden ser Squirrel o Toad. (Ver

punto Configuración ODBC para acceder a las bases de datos desde un Cliente MySql

gráfico).



93

Por último, la tercera regla que se puede apreciar en la Figura 37 es la relativa a la interfaz ssh del

nodo HSS. Análogamente a lo que ocurría con los nodos anteriores, esta regla hace posible el

acceso a la máquina virtual mediante ssh. En este caso, el puerto utilizado para el acceso será el

puerto 8022.

Finalmente, sólo comentar que aunque estos cuatro nodos, PBX reg y no reg, PCSCF y HSS son

los nodos de entrada a la red y para los cuáles es estrictamente necesario configurar un segundo

adaptador de red con al menos una regla de reenvío de puertos, se ha configurado dicho adaptador

en todas las máquinas virtuales y se ha definido la regla relativa al acceso por ssh para facilitar la

tarea de la administración de los nodos. En el caso del SCSCF se ha utilizado el puerto 6022, para

el ICSCF el puerto 5022 y, para AS, se ha utilizado el puerto 7022.

Un último detalle es necesario para tener las interfaces de red totalmente configuradas y

funcionando. Sin embargo es algo que tendremos que hacer sobre la configuración del sistema

operativo huésped. Por lo tanto, los siguientes pasos sólo podremos hacerlos tras haber instalado el

sistema operativo en la máquina virtual, que se describe en la sección B.1.1.3.

Una vez instalado el sistema operativo editaremos el fichero “insterfaces” como usuario root. Este

fichero se encuentra en el directorio /etc/network. Este fichero describe las interfaces de red

disponibles en el sistema.

La configuración del adaptador 1 es la correspondiente a la interfaz eth0 y la configuración del

adaptador 2 es la correspondiente a la interfaz eth1. Partiendo de la premisa de que hemos

configurado en el adaptador 1 la red interna y en el adaptador 2 la configuración de NAT,

tendremos la siguiente configuración:

# The loopback network interface auto lo iface lo inet loopback allow-hotplug eth1 iface eth1 inet dhcp # the primary network interface auto eth0 allow-hotplug eth0 iface eth0 inet static address 172.16.0.40 network 172.16.0.0 broadcast 172.16.0.255

En la anterior configuración podemos apreciar cómo se establecen tres interfaces de red. La

primera es la interfaz de “loopback” o “lo”, esta dirección se suele utilizar cuando una

transmisión de datos tiene como destino el propio host. La configuración de esta interfaz es

automática. La segunda interfaz definida es la interfaz eth0, que es la correspondiente a la red

virtual interna del laboratorio. Para cada uno de los nodos les asignaremos una dirección IP fija o

estática. En este caso, como la configuración mostrada es la correspondiente al PCSCF, la

dirección que se muestra es la 172.16.0.40/24. Las direcciones IP del resto de nodos se pueden ver

en la Figura 15. Arquitectura de despliegue detallada.


94

Por último, la última interfaz que se define es la interfaz eth1, que corresponde con la

interfaz NAT. Para esta interfaz se definirá DHCP para la obtención de la dirección IP.

Tras modificar el fichero interfaces tendremos que reiniciar las interfaces de red, para que

los cambios tengan efecto. Para ello ejecutaremos el siguiente comando:

ims@IMSLab:~$ sudo /etc/init.d/networking restart

Tras el reinicio de las interfaces podemos utilizar el comando “ifconfig –a” para comprobar

si la configuración de las interfaces es correcta: ims@IMSLab:~$ ifconfig -a

eth0 Link encap:Ethernet HWaddr 08:00:27:0c:29:f1 inet addr:172.16.0.40 Bcast:172.16.0.255 Mask:255.255.0.0 inet6 addr: fe80::a00:27ff:fe0c:29f1/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:28 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9576 (9.3 KiB) TX bytes:468 (468.0 B) eth1 Link encap:Ethernet HWaddr 08:00:27:6c:ed:90 inet addr:10.0.3.15 Bcast:10.0.3.255 Mask:255.255.255.0 inet6 addr: fe80::a00:27ff:fe6c:ed90/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:409 errors:0 dropped:0 overruns:0 frame:0 TX packets:292 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:33551 (32.7 KiB) TX bytes:31492 (30.7 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:8 errors:0 dropped:0 overruns:0 frame:0 TX packets:8 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:400 (400.0 B) TX bytes:400 (400.0 B)

B.1.1.3 Instalación Sistema Operativo

Para instalar el sistema operativo nos aseguraremos que tenemos configurado el arranque de

la máquina virtual desde el Cd-Rom. En la Figura 38Figura 38 se muestra la pantalla donde

debemos configurar el orden de arranque. Será en la pantalla de configuración en el menú de

sistema. Debemos asegurarnos de que la unidad de “Óptica” está por delante en el orden de

arranque que la unidad de “Disco duro”. Tras verificar esto, sólo nos queda iniciar la

máquina virtual. Como la unidad óptica contiene cargada la imagen iso con el sistema

operativo Debian, la máquina virtual arrancará desde la unidad de Cd-Rom. La instalación

del sistema operativo se hará como se haría desde una máquina física.


95

No se incluye los pasos de esta instalación en este documento puesto que no tiene ninguna

característica especial por el hecho de ser instalado en una máquina virtual, y por tanto, no tiene

ningún interés para el alcance de este documento.

Figura 38. Orden de arranque

Tras la instalación del sistema operativo y antes de comenzar con la instalación del software

específico del laboratorio debemos hacer una actualización del sistema. Para ello debemos ejecutar

como usuario root/root el siguiente comando:

root@IMSLab:~# apt-get update

B.1.1.4 Configuración de la ip del DNS Server

Para que todas las máquinas virtuales accedan al DNS que se ha configurado y que contiene todas

las direcciones IP de todos los nodos, es necesario configurar esta IP en todas las máquinas

virtuales. La instalación por defecto de Debian establece el fichero /etc/resolv.conf como

inmutable, lo que hará que no seamos capaces de editarlo ni siquiera como usuario root. Por ello,

primero debemos hacer que el fichero sea “mutable”. Para ello, debemos ejecutar el siguiente

comando:

root@IMSLab:~#sudo chattr –i /etc/resolv.conf

Una vez hecho esto, ya podemos editar el fichero para establecer la dirección IP de nuestro

DNSServer:

root@IMSLab:~#sudo vi /etc/resolv.conf

nameserver 172.16.0.80 search open-ims.lab.es domain open-ims.lab.es


96

Como se puede apreciar, lo que ponemos en este fichero es la IP del DNSServer, el cual se

encuentra desplegado en la misma máquina virtual que el HSS. El fichero /etc/resolv.conf de

todas las máquinas virtuales debe contener las líneas anteriormente mostradas excepto el

fichero /etc/resolv.conf del HSS, que no será modificado y se mantendrá con su contenido

por defecto. Una vez editado el fichero, será guardado y se volverá a restablecer su

propiedad de inmutable para evitar que sea machacado con cada reinicio:

root@IMSLab:~#chattr +i /etc/resolv.conf

Para que estos cambios tengan efecto, las máquinas virtuales deben ser reiniciadas.

B.1.1.5 Instalación de Asterisk

En primer lugar, antes de instalar Asterisk como tal, vamos a instalar las herramientas de

desarrollo para ser capaces de compilar. Como usuario root/root ejecutaremos el siguiente

comando para conseguir la instalación de las herramientas de desarrollo necesarias para ello:

root@IMSLab:~# apt-get install build-essential checkinstall

Además de las herramientas de desarrollo vamos a necesitar una serie de librerías de las

cuáles hace uso Asterisk (y algunas de ellas también Kamalio). Para instalarlas ejecutaremos

el siguiente comando, también como usuario root/root:

root@IMSLab:~# apt-get install -y build-essential linux-headers-`uname -r` mysql-

server mysql-client bison flex php5 php5-curl php5-cli php5-mysql php-pear php-db

php5-gd curl sox libncurses5-dev libssl-dev libmysqlclient-dev mpg123 libxml2-dev

libnewt-dev sqlite3 libsqlite3-dev pkg-config automake libtool autoconf git

subversion unixodbc-dev uuid uuid-dev libasound2-dev libogg-dev libvorbis-dev

libcurl4-openssl-dev libical-dev libneon27-dev libsrtp0-dev libspandsp-dev

libiksemel-dev libiksemel-utils libiksemel3

Descargando y preparando Asterisk

1. Creamos el directorio principal del laboratorio

root@IMSLab:~# mkdir –p /opt/OpenIMSCore

2. Utilizamos WGET para descargarnos el código de Asterisk

root@IMSLab:/opt/OpenIMSCore#wget

http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz

* Asterisk 13 es la última versión disponible durante la elaboración de este documento.

http://downloads.asterisk.org/pub/telephony/asterisk/asterisk-13-current.tar.gz


97

3. Una vez descargado los fuentes de Asterisk, descomprimiremos el fichero:

root@IMSLab:/opt/OpenIMSCore # tar zxvf asterisk-13-current.tar.gz

4. Desde el directorio asterisk-13.0.0 ejecutamos los siguiente comandos para arrancar la

consola de configuración de Asterisk

root@IMSLab:/opt/OpenIMSCore/asterisk-13.0.0 #./configure

root@IMSLab:/opt/OpenIMSCore/asterisk-13.0.0 #make menuselect

5. En el menú de configuración que se carga a continuación debemos comprobar que los

siguientes módulos aparezcan seleccionado, es decir, marcados con un asterisco [*]:

Channel Drivers / chan_sip

Resource Modules / res_crypto

Resource Modules / res_rtp_asterisk

Si alguno no está seleccionado es porque no hemos cumplido con los requisitos necesarios. En

ese caso, en la parte inferior se indica cuál es el componente que se requiere, y deberemos

instalarlo mediante APT. Normalmente se necesitan los paquetes de desarrollo, es decir, si en la

nota de la parte inferior de la consola de configuración se indica que es necesario el componente

“uuid”, tendremos que instalar el paquete “uuid-dev”. Una vez instaladas las dependencias,

deberemos volver a ejecutar los comandos del punto 4.

Además de lo anterior, vamos a seleccionar también la colección de sonidos en español:

Core Sound Packages / CORE-SOUNDS-ES-GSM

Una vez que todo esté bien configurado, los siguientes pasos son compilar, instalar, añadir los

scripts de arranque para arrancar Asterisk como servicio a través de init.d y finalmente añadir la

configuración del “logrotate”. Para todo ello, deberemos ejecutar por orden los siguientes

comandos:

root@IMSLab:/opt/OpenIMSCore/asterisk-13.0.0#make

root@IMSLab:/opt/OpenIMSCore/asterisk-13.0.0#make install

root@IMSLab:/opt/OpenIMSCore/asterisk-13.0.0#make config

root@IMSLab:/opt/OpenIMSCore/asterisk-13.0.0#make install-logrotate

Por último, podemos instalar una configuración completa de Asterisk que nos servirá como

ejemplo para ir viendo la sintaxis:

root@IMSLab:/opt/OpenIMSCore/asterisk-13.0.0 #make samples


98

Tras esto, ya es posible arrancar Asterisk como servicio al iniciar la máquina virtual. Para

ello es necesario arrancar Asterisk mediante el comando:

root@IMSLab:/opt/OpenIMSCore/asterisk-13.0.0 #/etc/init.d/asterisk start

Con la configuración anterior, lo que conseguimos es que Asterisk se arranque como

servicio al iniciar la máquina virtual. En estas circunstancias, Asterisk se arrancará con la

configuración que hay en el directorio /etc/asterisk. Sin embargo, esto sólo nos permite

levantar una instancia de Asterisk, mientras que para el laboratorio IMS necesitamos tres

instancias de Asterisk (una para el AS, y dos más para las PBX, reg y no reg

respectivamente). Por este motivo, se decidió ejecutar Asterisk en modo “standalone”,

indicando en el arranque el fichero donde se encuentra la configuración que se debe cargar

para cada instancia.

Para que no haya colisión entre Asterisk en modo “standalone” y Asterisk como servicio,

debemos desactivar el servicio. La manera más rápida de hacerlo es quitar los permisos de

ejecución:

root@IMSLab:#cd /etc/init.d

root@IMSLab:/etc/init.d#chmod –x asterisk

A partir de este momento, podemos arrancar tantas instancias de Asterisk como queramos

indicando el fichero de configuración mediante el parámetro “-C”. Por ejemplo,

asterisk -C asterisk.conf (siendo asterisk.conf la configuración que queremos cargar)

En el caso del laboratorio, el comando de ejecución de Asterisk se ha introducido en una

serie de scripts de arranque que se comentarán en la sección B.2B.2.4, por lo que no será

necesario utilizar el comando tal y como se muestra a continuación o, de manera análoga,

para la pbx no registrada o para el servidor de aplicaciones:

root@IMSLab:#/usr/bin/asterisk/asterisk -C /home/ims/Asterisk/PBX/reg-

pbx/etc/asterisk.conf > /home/ims/logs/reg-pbx/asterisk.log

Para entrar en la consola de asterisk debemos ejecutar

root@IMSLab:#/usr/bin/asterisk/asterisk -C /home/ims/Asterisk/PBX/reg-

pbx/etc/asterisk.conf –r

Pero tal y como ocurría en el caso anterior, ya existen scripts implementados para que estos

comandos sean transparentes al usuario (Ver sección B.2B.2.4).

mailto:root@IMSLab:/etc/init.d#chmod

mailto:root@IMSLab:#/usr/bin/asterisk/asterisk -C /home/ims/Asterisk/PBX/reg-pbx/etc/asterisk.conf





99

B.1.1.6 Instalación del HSS

Como se ha comentado con anterioridad, el HSS que se utilizará en el laboratorio será el HSS de

Fokus, de ahora en adelante FHoSS. Para instalar el HSS necesitaremos instalar una serie de

módulos.

- En primer lugar necesitaremos instalar el módulo de Subversion para poder descargarnos el

código de FHoSS. Para ello ejecutaremos el siguiente comando:

root@IMSLab:#apt-get install subversion

- En segundo lugar necesitamos una versión de Java igual o superior a Java 1.5. Para ello, lo

primero será desinstalar la versión de OpenJDK que viene por defecto en la instalación de

Debian.

root@IMSLab:#sudo apt-get remove openjdk-6-jre*

A continuación instalaremos Oracle JDK. Para ello deberemos añadir el repositorio:

root@IMSLab:#sudo add-apt-repository ppa:webupd8team/java

En este punto, nos podemos encontrar con que la ejecución del parámetro anterior origine

como resultado un error de que no se ha podido encontrar la orden. En ese caso, deberemos

editar el fichero /etc/apt/sources.list y añadir las siguientes líneas:

deb http://ppa.launchpad.net/webupd8team/java/ubuntu precise main

deb-src http://ppa.launchpad.net/webupd8team/java/ubuntu precise main

Las líneas anteriores definen las direcciones donde encontrar el repositorio. Además,

deberemos tener permisos para acceder al repositorio, por lo que deberemos instalar las

claves públicas:

root@IMSLab:#sudo apt-key adv –keyserver keyserver.ubuntu.com –recv-keys

EEA14886

Actualizamos el repositorio:

root@IMSLab:#sudo apt-get update

Y por último, descargamos e instalamos Oracle JDK:

root@IMSLab:#sudo apt-get install oracle-java7-installer

- En tercer lugar, vamos a necesitar Ant para la compilación del código:

root@IMSLab:#sudo apt-get install ant

http://ppa.launchpad.net/webupd8team/java/ubuntu

http://ppa.launchpad.net/webupd8team/java/ubuntu


100

- Finalmente, necesitaremos tener MySQL Server instalado y corriendo en la máquina.

Para la instalación tan sólo será necesario ejecutar el siguiente comando:

root@IMSLab:#apt-get install mysql-server mysql-client

Para arrancar, parar o reiniciar el demonio de MySQL se usarán los siguientes

comandos, siempre como usuario root:

root@IMSLab:# /etc/init.d/mysql start/stop/restart

Tras la instalación y arranque del demonio de MySQL, deberíamos ser capaces de

entrar en la consola de MySQL Server como usuario root. Sin embargo, en algunas

ocasiones esto no es posible. Por lo que hay que realizar una serie de acciones para

habilitar el acceso. Dichas acciones serán enumeradas a continuación:

Paramos el demonio y lo arrancamos en modo seguro sin contraseña

root@IMSLab:#mysqld_safe –skip-grant-tables

Desde otro terminal, ya somos capaces de entrar como usuario root sin contraseña.

root@IMSLab:#mysql –u root

Una vez en la consola de MySQL, cambiamos la contraseña de root

mysql> use mysql

mysql> update user set password=PASSWORD(“mysql” where User=’root’;

mysql> flush privileges;

mysql> quit

Reiniciamos el demonio de MySQL para que salga del modo seguro sin contraseña

root@IMSLab:#/etc/init.d/mysql restart

- A partir de este momento, ya seremos capaces de entrar en la consola de MySQL con

usuario root/mysql.

root@IMSLab:#mysql –u root –p

Enter password: mysql

mailto:root@IMSLab:#/etc/init.d/mysql

mailto:root@IMSLab:#/etc/init.d/mysql


101

Descargando FHoSS.

1. Creamos el directorio principal del laboratorio (si no lo hemos hecho anteriormente)


2. Creamos un directorio llamado FHoSS y utilizamos Subversion para descargarnos el

código.

root@IMSLab:~# mkdir –p /opt/OpenIMSCore/FHoSS

root@IMSLab:~# cd /opt/OpenIMSCore

root@IMSLab:~# svn checkout

https://svn.code.sf.net/p/openimscore/code/FHoSS/trunk FHoSS

3. Compilamos el código con Ant.

root@IMSLab:~#cd FHoSS

root@IMSLab:~#ant compile deploy

4. Una vez instalado el HSS, debemos crear la base de datos donde el HSS mantendrá la

información de los usuarios. Por suerte, el código que nos hemos descargado contiene una

serie de scripts que ejecutados sobre el servidor de MySQL que debemos tener instalado y

corriendo, crearán la base de datos que necesitamos. Para ejecutar dichos scripts debemos

ejecutar los siguientes comandos como usuario root.

root@IMSLab:~#mysql –u root –p –h localhost <

/opt/OpenIMSCore/FHoSS/scripts/hss_db.sql


/opt/OpenIMSCore/FHoSS/scripts/hss_db_migrate_as_register.sql


/opt/OpenIMSCore/FHoSS/scripts/hss_db_migrate_dsai.sql

Antes de ejecutar el siguiente script, debemos editar el script y modificar algunos

valores. Básicamente debemos reemplazar en todo el script el valor

“open-ims.test” por “open-ims.lab.es”.


/opt/OpenIMSCore/FHoSS/scripts/userdata.sql

5. Para evitar que el software del HSS accede a la base de datos como usuario root, se creará

un nuevo usuario al que se le darán todos los privilegios sobre la base de datos que

acabamos de crear, hss_db. Para ello, ejecutaremos los siguientes comandos:

mysql> GRANT ALL ON hss_db.* TO kamailio@’%’ IDENTIFIED BY ‘kamailio’;

https://svn.code.sf.net/p/openimscore/code/FHoSS/trunk


102

Con el último comando, se ha creado el usuario kamailio con contraseña kamailio

para poder acceder a la base de datos hss_db tanto en local como en remoto y con

todos los privilegios sobre dicha base de datos.

Además, para que la base de datos admita conexiones remotas debemos editar el

fichero /etc/mysql/my.conf y modificar la siguiente línea:

bind-address = 0.0.0.0

6. Por último, debemos copiar algunos ficheros y crear los siguientes links simbólicos

en el directorio donde arrancaremos el HSS, en el caso del IMSLab en

/home/ims/OpenIMSCore/FHoSS:

ims@IMSLab:#mkdir –d /home/ims/OpenIMSCore/FHoSS

ims@IMSLab:#cd /home/ims/OpenIMSCore/FHoSS

ims@IMSLab: /home/ims/OpenIMSCore/FHoSS#cp -r

/opt/OpenIMSCore/FHoSS/deploy/* .

ims@IMSLab: /home/ims/OpenIMSCore/FHoSS # rm –r webapps lib

ims@IMSLab:~#ln –s /opt/OpenIMSCore/FHoSS/deploy/webapps webapps

ims@IMSLab:~#ln –s /opt/OpenIMSCore/FHoSS/deploy/lib lib

B.1.1.7 Instalación de Kamailio

Antes de comenzar con la instalación de Kamailio debemos asegurarnos de que tenemos

todos los recursos que vamos a necesitar disponibles en el sistema operativo. Por ello,

debemos hacer una actualización del sistema si no la hemos hecho con anterioridad, y

descargarnos los recursos que vamos a necesitar para la instalación de Kamailio:

Para el primer punto, actualización del sistema operativo debemos ejecutar, como usuario

root/root dicha actualización:

root@IMSLab:~# apt-get update

Una vez actualizado el sistema debemos descargarnos las utilidades que nos van a hacer

falta para el despliegue de Kamailio. Por tanto, ejecutamos como usuario root/root.

root@IMSLab:~# apt-get install git-core gcc flex bison libmysqlclient-dev

make libssl-dev libcurl4-openssl-dev libxml2-dev libpcre3-dev sqlite3

libsqlite3-dev libsqlite3-0 libpq-dev libexpat1-dev libradiusclient-ng-dev

Adicionalmente a estos paquetes, para RTP Proxy vamos a necesitar el siguiente paquete:

root@IMSLab:~# apt-get install rtpproxy

Una vez que tenemos listo el sistema operativo para la instalación de Kamailio,

comenzamos.


103

Descargando y preparando Kamailio

1. Creamos el directorio principal de Kamailio (si no lo hemos creado ya)


2. Utilizamos GIT para descargarnos los fuentes de Kamailio

root@IMSLab:/opt/OpenIMSCore# git clone --depth 1 --no-single-branch git://git.sip-

router.org/sip-router kamailio

3. Una vez descargados los fuentes de Kamailio, ejecutamos el comando “checkout” de GIT

para actualizarlos

root@IMSLab:/opt/OpenIMSCore/kamailio# git checkout -b 4.2.3 4.2.3

4. A continuación ejecutaremos el siguiente comando para generar la configuración de

Kamailio

root@IMSLab:/opt/OpenIMSCore/kamailio#make cfg

Tras la ejecución del comando anterior, se habrá generado en el path

/opt/OpenIMSCore/kamailio un fichero llamado modules.lst. Este fichero contiene los

módulos de Kamailio que queremos tener disponibles en nuestro despliegue. El fichero

modules.lst generado por defecto por la compilación es un fichero básico que no contiene

todos los módulos que vamos a utilizar, por lo que debemos editarlo y añadir algunas

cosas. Una vez tengamos este fichero tal y como queremos, es importante guardar su

contenido, puesto que cada vez que actualicemos Kamailio contra el repositorio tendremos

que ejecutar el comando make cfg y este fichero será machacado.

Durante el desarrollo del proyecto se han ido detectando varios problemas, algunos de ellos

solucionados añadiendo algún módulo a este fichero. A continuación se puede ver el

contenido final del fichero:

- modules.lst

# this file is autogenerated by make modules-cfg

# the list of sub-directories with modules

modules_dirs:=modules

# the list of module groups to compile

cfg_group_include=

# the list of extra modules to compile

include_modules= cdp cdp_avp xlog ims_icscf siptrace debugger tls enum uac ims_qos pike htable

dispatcher path rtpproxy nat_traversal nathelper ctl cfg_rpc xmlrpc ims_diameter_ro


104

ims_registrar_scscf ims_auth ims_isc db_text db_mysql dialplan ims_usrloc_pcscf ims_registrar_pcscf

db_sqlite dialog_ng ims_usrloc_scscf presence_xml presence sdpops

# the list of static modules

static_modules=

# the list of modules to skip from compile list

skip_modules=

# the list of modules to exclude from compile list

exclude_modules= cnxcc geoip2 erlang acc_radius app_java app_lua app_mono app_perl app_python

auth_ephemeral auth_identity auth_radius carrierroute cdp cdp_avp cpl-c db2_ldap db_berkeley

db_cassandra db_mongodb db_mysql db_oracle db_perlvdb db_postgres db_sqlite db_unixodbc

dialog_ng dialplan dnssec evapi geoip gzcompress h350 ims_auth ims_charging ims_icscf ims_isc

ims_qos ims_registrar_pcscf ims_registrar_scscf ims_usrloc_pcscf ims_usrloc_scscf iptrtpproxy json

jsonrpc-c kazoo lcr ldap memcached mi_xmlrpc misc_radius ndb_cassandra ndb_mongodb ndb_redis

osp outbound peering presence presence_conference presence_dialoginfo presence_mwi

presence_profile presence_reginfo presence_xml pua pua_bla pua_dialoginfo pua_mi pua_reginfo

pua_usrloc pua_xmpp purple regex rls sctp snmpstats tls utils uuid websocket xcap_client xcap_server

xhttp_pi xmlops xmlrpc xmpp $(skip_modules) $(skip_modules)

modules_all= $(filter-out modules/CVS,$(wildcard modules/*))

modules_noinc= $(filter-out $(addprefix modules/, $(exclude_modules) $(static_modules)),

$(modules_all))

modules= $(filter-out $(modules_noinc), $(addprefix modules/, $(include_modules) ))

$(modules_noinc)

modules_configured:=1

5. Finalmente, debemos ejecutar el resto de “makes” que serán necesarios

root@IMSLab:/opt/OpenIMSCore/kamailio# make all

root@IMSLab:/opt/OpenIMSCore/kamailio# make install

B.1.1.8 Actualización a Kamailio 4.3

Al inicio del proyecto, la última versión de Kamailio disponible era la versión 4.2.3, sin

embargo, durante la realización del proyecto esta versión fue reemplazada por la versión

4.3, por lo que se decidió hacer una actualización de versión. Esta actualización implicó

hacer una actualización del kernel de Debian, de la versión Wheeze instalada inicialmente

a la versión Jessy. A continuación se enumerarán los pasos a realizar para la actualización

del kernel de Debian, así como de la versión 4.2.3 a la versión 4.3 de Kamailio. El objetivo

de esta actualización es, principalmente, tener un ejemplo de lo que sería una actualización

de Kamailio.


105

Actualización del kernel de Debian de Wheeze a Jessi.

1. Lo primero que tenemos que hacer, es asegurarnos de que Wheeze está actualizado

root@IMSLab:/#apt-get update

2. A continuación, ya estamos preparados para hacer el “upgrade”

root@IMSLab:/#apt-get upgrade

root@IMSLab:/#apt-get dist-upgrade

3. A continuación nos aseguremos que los comandos anteriores no han dejado ningún paquete

a medio instalar o bloqueado. Para ello ejecutaremos los siguientes comandos y no

continuaremos con el “upgrade” salvo que no nos devuelvan ningún error.

root@IMSLab:/#dpkg --audit

root@IMSLab:/#dpkg --get-selections | grep hold

4. Una vez, los comandos anteriores no devuelvan ningún error, podemos proseguir con el

“upgrade”. El siguiente paso es modificar el fichero sources.list y reemplazar el contenido

por las siguientes líneas:

root@IMSLab:/#nano /etc/apt/sources.list

deb http://ftp.de.debian.org/debian/ jessie main contrib non-free

deb-src http://ftp.de.debian.org/debian/ jessie main contrib non-free

deb http://httpredir.debian.org/debian jessie-updates main contrib non-free deb-src http://httpredir.debian.org/debian jessie-updates main contrib non-free

deb http://security.debian.org/ jessie/updates main contrib non-free

deb-src http://security.debian.org/ jessie/updates main contrib non-free

5. Una vez, editado y guardado el fichero sources.list con el contenido mostrado en el punto

anterior, debemos ejecutar los siguientes comandos para realizar la actualización del kernel.

root@IMSLab:/#apt-get update

root@IMSLab:/#apt-get upgrade

6. Finalmente, será necesario hacer un reinicio de la máquina para que el nuevo kernel se

cargue.

root@IMSLab:/#reboot

7. Finalmente, tras reiniciar la máquina virtual, podemos consultar la versión del kernel que

está instalada comprobando el contenido del fichero /etc/os-release

ims@IMSLab:~$ cat /etc/os-release PRETTY_NAME="Debian GNU/Linux 8 (jessie)" NAME="Debian GNU/Linux" VERSION_ID="8" VERSION="8 (jessie)" ID=debian HOME_URL="http://www.debian.org/"

http://ftp.de.debian.org/debian/

http://ftp.de.debian.org/debian/

http://httpredir.debian.org/debian

http://httpredir.debian.org/debian

http://security.debian.org/

http://security.debian.org/


106

SUPPORT_URL="http://www.debian.org/support" BUG_REPORT_URL=https://bugs.debian.org/

Actualización a Kamailio 4.3

Para realizar el “upgrade” de Kamailio a la versión 4.3 deberemos ejecutar los puntos c y

d de la guía de instalación de Kamailio (Ver sección Instalación de Kamailio), indicando la

versión 4.3 en vez de la versión 4.2.3.

Antes de realizar esto, debemos guardar el fichero modules.lst, ya que, como se indicó en

la sección Instalación de Kamailio este fichero se regenera cada vez que se ejecuta el

comando “make cfg”.

Una vez ejecutado el comando “make cfg”, recuperaremos el fichero modules.lst que

habíamos guardado y reemplazaremos el nuevo fichero con el antiguo.

Además debemos añadir en este fichero los módulos erlang y geoip2 en la sección de

módulos excluidos.

Antes de seguir con la instalación necesitaremos instalar las siguientes librerías:

root@IMSLab:/# apt-get install libevent-dev

root@IMSLab:/# apt-get install libhiredis-dev

Por último, debemos dar permisos de ejecución al siguiente script para evitar que falle la

compilación.

root@IMSLab:/#cd /opt/OpenIMSCore/kamailio/4.3/modules/tls

root@IMSLab:/#chmod 744 sip-router_cert.sh

Finalmente, ya podemos seguir con el resto de la instalación y ejecutar los “makes” que

nos faltan.

root@IMSLab:/opt/OpenIMSCore/kamailio# make all

root@IMSLab:/opt/OpenIMSCore/kamailio# make install

B.1.2 HSS

B.1.2.1 Configuración de usuarios y perfiles

La configuración del HSS se realizará utilizando la consola web del FHoSS. Para acceder a

ella sólo tendremos que acceder a la siguiente url: http://127.0.0.1:8888/hss.web.console/.

En la sección 0 se explicó con detalle los elementos que son necesarios crear para la

definición de un iFC usando como ejemplo los datos creados por la consola del HSS. Por

lo que, en esta sección no se dedicarán muchas líneas a ello.

https://bugs.debian.org/



107

La ejecución del script userdata.sql que se hizo en la instalación del HSS (Ver punto Instalación

del HSS) habrá generado los datos necesarios en la pestaña “Network Configuration”, por lo que

no será necesario configurar nada más en esta pestaña.

Empezaremos centrándonos en la pestaña “Services”. En esta pestaña es donde se definirán los

servidores de aplicaciones, así como los servicios originantes o terminantes que se van a disparar

para cada usuario. Es decir, en esta pestaña se definirán los perfiles de servicios, que más tarde

serán asociados a los diferentes usuarios en la pestaña “User Identities”.

Figura 39. Pestaña Services

El objetivo final de esta pestaña es la de crear un perfil de servicios que más tarde podamos

asociar a un usuario. Un perfil de servicios está compuesto por varios iFCs y cada iFC asocia un

trigger point, donde se definen las condiciones necesarias para aplicar o no un disparo, y un

servidor de aplicaciones, que pese a la nomenclatura, se refiere a un trigger o disparo.

Es necesario comentar que la relación “Application Servers” y “Trigger Points” se realiza

mediante uno o varios “Initial Filter Criteria”, lo que significa que el mismo “Trigger Point”

puede ser asoaciado a diferentes “Application Servers” mediante diferentes “Initial Filter

Criteria”, y , también, un mismo “Application Server” puede estar asociado a diferentes “Trigger

Points” mediante diferentes “Initial Filter Criteria”.


108

Figura 40. Pestaña User Identities

Una vez creados los diferentes perfiles de servicios, es hora de crear los usuarios y

asociarlos a dichos perfiles.

Para ello debemos hacer una cierta diferenciación entre los diferentes tipos de extensiones

o usuarios que tendremos en el laboratorio.

- extensiones SIP

- extensiones reg-pbx

- extensiones unreg-pbx

Extensiones SIP: La configuración para las extensiones SIP es la configuración más

inmediata. Deberemos crear una IMSU, una IMPI y al menos una IMPU. Para crear

este tipo de extensiones podemos hacer uso del script “imslab-mng-user.sh“, el cuál se

comentará más en detalle en la sección B.2B.2.4.


109

Figura 41. IMPUs

Por ejemplo, en el caso de que ejecutemos el script para el usuario +3460000000111 se

crearán una serie de IMPUs que dependerán de los parámetros del script (ver sección

B.2B.2.4), todas ellas asociadas a una IMPI, [email protected], también

creada por el script y a un service profile que ya debe haber sido creado anteriormente de

manera manual (descrito anteriormente en esta misma sección) y que es indicado como

parámetro del script, en este caso “as.imsLab.es”. Dicha IMPI estará asociada a una IMSU

que también es creada por el script.

Esto será suficiente para tener una extensión SIP que disparará los servicios establecidos en

el perfil de servicios al que se asocie.

Extensiones de una pbx registrada: La configuración para las extensiones de una pbx

registrada es algo peculiar. Básicamente, para una pbx registrada, tendremos un número de

cabecera o número de la pbx. Este número de cabecera identificará de manera unívoca a la

pbx y por tanto se utilizará para crear la IMSU y la IMPI. Las extensiones de la pbx se

definirán como IMPUs, de manera que cuando la pbx registrada se registre en el HSS con su

número de cabecera se darán por registradas todas sus extensiones.

mailto:[email protected]


110

Figura 42. Definición de una pbx-reg

Extensiones de una pbx no registrada: Como se comentó en la sección 4.3.7, los

usuarios de la centralita no registrada no se registrarán en el core IMS y serán

desconocidos para el core IMS. Para lograr este comportamiento es necesario crear

dos PSIs o “Public Service Identities”. Este comportamiento se describió en detalle en

las secciones 0 y 0.

Una PSI no es más que un usuario del core IMS un tanto especial, ya que no debe estar

registrado.

Crearemos una IMSU y una IMPI con identidad [email protected]. Y después

crearemos dos IMPUs que asociaremos a esta IMSU/IMPI, como se muestra en la

Figura 43Figura 43

mailto:[email protected]


111

Figura 43. Configuración PSI

Las IMPUs que se crearán para definir las PSIs serán un tanto espciales, ya que serán

creadas como “Wildcarded_PSI”. Además debemos definir un patrón de disparo en la

casilla “Wildcard PSI”, que básicamente es el patrón que se debe cumplir para que se

dispare la PSI.

Las figuras Figura 44. PSI para servicios originantes y Figura 45. PSI para servicios

terminantes muestran la definición de ambas PSIs. Como se puede apreciar en dichas

figuras, se han creado dos perfiles diferentes, uno para disparar los servicios originantes

(oUpbx.imsLab.es) y otro para disparar los servicios terminantes (tUpbx.imsLab.es). Ambas

IMPUs han sido definidas como Distinct_PSI y la definición del Wildcard PSI es

sip:977+34* para los servicios originantes y sip:988+34* para los servicios terminantes. Es

necesario hacer especial mención al User-Status. El estado, para este tipo de IMPUs es

UN-REGISTERED, y es una manera de marcar a estos usuarios como usuario que no se

pueden registrar.

sip:977+34*

sip:988+34*


112

Figura 44. PSI para servicios originantes

Figura 45. PSI para servicios terminantes


113

B.1.2.1 Configuración ODBC para acceder a las bases de datos desde un Cliente MySql gráfico

En el punto Instalación del HSS se comentó la posibilidad de conectarse a las bases de datos del

HSS, del ICSCF y de Kamailio desde lientes MySql gráficos, como Squirrer o Toad. Se

comentaba que la segunda regla de reenvío de puertos mostrada en la Figura 37. HSS, reglas de

reenvío de puertos era la que hacía posible esta conexión. Sin embargo, esta regla no es lo único

necesario para acceder a las bases de datos alojadas en la máquina del HSS desde el exterior.

Además de la regla, será necesario instalar ODBC en Linux. Esto hará posible la definición de

un DSN y el acceso desde la máquina física a dichas bases de datos.

A continuación se detallará el procedimiento para la instalación de ODBC en Linux y para la

configuración de Squirrel para el acceso desde la máquina física a las bases de datos.

En primer lugar, necesitamos instalar los paquetes necesarios para tener ODBC en Linux. Para

ello ejecutaremos el siguiente comando:

root@IMSLab:/#apt-get install tdsodbc unixodbc

En segundo lugar debemos editar el fichero /etc/odbc.ini y reemplazar su contenido con lo

siguiente:

root@IMSLab:/#vi /etc/odbc.ini

[IMSLab_hss_db] Description = Hss db Driver = MySQL Database = hss_db Server = localhost Port = Option = 3 Socket = [IMSLab_icscf_db] Description = icscf db Driver = MySQL Database = icscf Server = localhost Port = Option = 3 Socket = [IMSLab_kamailio_db] Description = kamailio db Driver = MySQL Database = kamailio Server = localhost Port = Option = 3 Socket =

El fichero odbc.ini contiene la definición de los DSNs. Como se puede apreciar se han definido

tres DSNs, uno por cada una de las bases de datos que serán accesibles desde la máquina física.


114

En tercer lugar, debemos editar el fichero odbcinst.ini y reemplazar su contenido con las

siguientes líneas:

root@IMSLab:/#vi /etc/odbcinst.ini [MySQL] Description = MySQL driver Driver = libmyodbc.so Setup = libodbcmyS.so

Finalmente, podemos probar que la conexión a la base de datos es posible usando el DSN,

de este modo comprobaremos que el DSN se ha definido correctamente.

root@IMSLab:/#Isql IMSLab_hss_db kamailio kamailio ;

+---------------------------------------+ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | +---------------------------------------+ SQL>

A continuación se muestra la configuración del cliente MySql Squirrel para conectarse a

cada una de las bases de datos mencionadas.

Figura 46. Configuración de conexión a las bases de datos


115

B.1.3 Asterisk

La configuración de Asterisk se realiza a través de una serie de ficheros que se encuentran en el

directorio “etc” de cada una de las instancias de Asterisk del laboratorio. Los ficheros

“asterisk_rpbx.conf”, “asterisk_upbx.conf” y “asterisk_as.conf” son indicados como parámetro

en el arranque de cada una de las instancias, y contienen algunos paths importantes para la

ejecución de Asterisk, como por ejemplo, el path del resto de ficheros donde Asterisk encontrará

la configuración necesaria para la pbx registrada, pbx no registrada y para el servidor de

aplicaciones respectivamente.

Asterisk funciona como un B2BUA (Ver punto 0), por lo que posee dos características

principales, entre otras muchas, que nos ayudarán a entender su configuración:

- En primer lugar y repitiendo lo que se dijo en el punto 0, un B2BUA opera entre dos

puntos finales de una comunicación de VoIP y divide el canal de comunicación en dos

canales, operando para uno de los “end points” como UAS, (para el “end point”

originador de la llamada), y como UAC para el otro “end point”, (para el destinatario de

la llamada)

- En segundo lugar, un B2BUA puede funcionar como proveedor de servicios de valor

añadido

Los ficheros de configuración más importantes y donde se establece el comportamiento de

Asterisk son el fichero sip.conf y el fichero extensions.conf. El fichero sip.conf es donde

podremos configurar los canales de comunicación, tanto de entrada como de salida de Asterisk,

por lo que el fichero sip.conf es donde se encuentra la configuración necesaria para cubrir la

primera característica de un B2BUA. Por otro lado, en el fichero extensions.conf es donde se

encuentra la configuración necesaria para cubrir su segunda característica, es decir, es donde se

encuentra la lógica de servicio necesaria para proporcionar servicios de valor añadido.

B.1.3.1 Sip.conf

Como se ha expresado anteriormente, el fichero Sip.conf contiene la configuración de los canales

de comunicación. Este fichero se encuentra dividido en secciones, lo que en Asterisk se

denominan contextos.

Hay predefinido un contexto general o por defecto (“[general]”) en el que se definirán aquellos

parámetros globales que aplicarán a todos los contextos, y por tanto a todos los canales SIP de

comunicación. Todos los parámetros que se definirán a lo largo de la sección pueden ser

utilizados en cualquier contexto, sin embargo, se indicarán en el contexto cuyo uso es más

extendido. Por ejemplo, los parámetros que se usan más comúnmente en el contexto general, son

los siguientes:


116

- Bindport: es el puerto que utilizará Asterisk para escuchar tráfico SIP entrante.

- Udpbindaddr: es la interfaz de red que utilizará Asterisk para atender las

conexiones SIP entrantes. El valor por defecto es el 0.0.0.0, que significa que

Asterisk escuchará cualquier conexión SIP entrante por cualquiera de las interfaces

de red.

- Domain: dominio del core IMS.

- Allowguest: puede valer “yes” o “no”, y determina si se permitirá o no la conexión

de identidades que no estén explícitamente indicadas en el fichero de extensiones.

- Context: es el contexto definido en el fichero extensions.conf (ver punto B.1.3.2

Extensions.conf) que se aplicará a la llamadas entrantes o salientes cuando no hay

definido otro contexto. Básicamente es el contexto por defecto aplicado cuando no

se ha indicado otro explícitamente.

- Tcpenable: permite habilitar o deshabilitar el soporte a TCP en las llamadas

entrantes.

- Transport: permite indicar si se usará TCP o UDP para las llamadas salientes.

- Register: permite indicar, en caso de que fuera necesario, contra qué cscf se

registrará el Asterisk. El formato es el siguiente:

Register => IMPI:password:IMPU@ip_pcscf:puerto_pcscf

Por ejemplo, para nuestra pbx registrada:

Register=> [email protected]:123456:sip:[email protected] @pcscf.open-ims.lab.es:4060

A continuación tendremos que definir tantos contextos como canales de comunicación SIP

tengamos. En el caso de las centralitas deberemos definir un contexto para cada una de las

extensiones de la centralita y añadir dos cuentas más, una para llamadas salientes hacia el

core IMS y otro para llamadas entrantes desde el core IMS.

En el caso del servidor de aplicaciones, sólo harán falta estas dos últimas, puesto que no

hay extensiones que se vayan a registrar en el servidor directamente.

Asterisk proporciona la posibilidad de usar “máscaras” comunes donde los parámetros

comunes serán definidos. De este modo se podrá “heredar” estos parámetros y

sobreescribir o incluir nuevos en los contextos “hijos”. Se utilizará (!) junto al nombre de

la sección para especificar que dicha sección actuará como una máscara y se indicará entre

paréntesis el nombre de la sección que actúa como máscara junto a las secciones que

quieran “heredar” los parámetros de dicha sección. Por ejemplo, como hacemos en las

centralitas,

[office-phone](!)

type=friend

context=LocalContext

host=dynamic

nat=force_rport,comedia


117

dtmfmode=auto

disallow=all

allow=g722

allow=ulaw

allow=alaw

[220](office-phone)

secret=123456

[221](office-phone)

secret=123456

….

Algunos parámetros comúnmente utilizados a la hora de definir las cuentas sip son los

siguientes:

- Type: define el tipo de conexión que tendrá el cliente. Hay tres tipos posibles:

Peer: sólo puede recibir llamadas (UAS)

User: sólo puede realizar llamadas (UAC)

Friend: puede tanto recibir como realizar llamadas (UAS/UAC)

- Allow: permite especificar los códecs de sonido que se van a utilizar.

- Disallow: permite especificar los códecs de sonido que no se quieren permitir.

- Secret: es la contraseña con la que se realizará la autenticación en Asterisk.

- Context: es el contexto asociado al cliente en el dialplan de Asterisk, es decir, contexto

que se aplicará y que debe estar definido en el fichero extensions.conf, el cuál se

comentará en detalle en la sección B.1.3.2.

B.1.3.2 Extensions.conf

En el fichero Extensions.conf es donde se define la lógica de Asterisk, es decir, las acciones a

realizar para cada usuario. Al igual que el fichero sip.conf está dividido en diferentes secciones.

En el fichero sip.conf y para cada una de las extensiones se debe definir un contexto que debe

estar definido en este fichero.

La primera sección de este fichero es la sección “globals”, en esta sección se indicarán las

variables globales que más tarde pueden ser utilizadas en el resto de secciones. Por ejemplo,

SOUNDS_DIR=/home/ims/Asterisk-PBX/reg-pbx/var/sounds

NETWORK_DOMAIN=open-ims.lab.es

PBX_HN=+347007777

PBX_MN=230

PBX_ORIG_PSI=

PBX_CC=34

PANI_VALUE=open-ims.lab.es\;link=8888230-0


118

A continuación se deberán definer todos los contextos a los que se ha hecho referencia

desde el fichero sip.conf. Por ejemplo, en el caso de las centralitas en las que se han

definido una serie de extensiones que se registrarán directamente en la centralita, se hizo

referencia al contexto LocalContext, por lo que, en el fichero extensions.conf de las

centralitas nos encontraremos con una sección con este nombre:

[LocalContext]

En cada una de los contextos se especificará la lógica que hay que ejecutar para cada

extensión. Por ejemplo, lo primero que se establece en el LocalContext, es que si la

llamada se realiza por el número corto, entonces la llamada debe salir como número corto

por el mismo LocalContext. Esto hace que las llamadas entre extensiones de las centralitas

no salgan al core IMS, sino que sean enrutadas por la misma centralita hacia su destino.

exten => _23X,1,Dial(SIP/${EXTEN}) ;

Por el contrario, cuando la llamada es marcada por el número largo, la llamada será

enrutada a través de contexto PCSCF-Outgoing definido en el fichero sip.conf. Pero no sin

antes, realizar una serie de acciones:

exten => _+[0-9a-zA-Z].,1,Set(callerIDString=${CALLERID(num)})

same => n,Set(CALLERID(all)=<${PBX_HN}${callerIDString}>)

same => n,SIPAddHeader(P-Access-Network-Info: ${PANI_VALUE});

same => n,Dial(SIP/${PBX_ORIG_PSI}+${EXTEN:1}@PCSCF-Outgoing)

El código anterior lo que le está indicando a Asterisk es que haga lo siguiente:

1. Transformar el CallerId de un número a una cadena de caracteres para poder ser

utilizado después.

2. Establece en la cabecera From, tanto en el display name como en la parte de usuario,

al siguiente usuario:

${PBX_HN}$callerIDString, es decir, +34700777723X

Siendo los últimos tres números la extensión que está realizando la llamada.

3. Añade la cabecera P-Access-Network-Info con la valor contenido en la variable

PANI_VALUE, definida en la sección “globals”.

4. Finalmente, enruta la llamada eliminando el ‘+’ y añadiendo la PBX_ORIG_PSI, que

en este caso está vacío. El enrutamiento se hace a través del PCSCF-Outgoing.

5. Puesto que el contexto PCSCF-Outgoing, define otro contexto en el fichero

extensions.conf, la llamada ejecutará dicho contexto (TrunkingContext) antes de ser

enrutada hacia PCSCF.


119

B.1.4 Kamailio

Kamailio es un SIP Proxy y como tal, su principal cometido es el de redirigir paquetes SIP. Para

hacer esto Kamailio puede nutrirse de información en bases de datos, información obtenida

desde el HSS a través de su interfaz Cx, información obtenida en ENUM, datos recibidos en los

mensajes SIP, etc.

B.1.4.1 Configuración

La configuración de Kamailio se realiza a través de una serie de ficheros que se encuentran en el

directorio “etc” de cada una de las instancias de Kamailio del laboratorio. Los ficheros

“pkamailio.cfg”, “ikamailio.cfg” y “skamailio.cfg” son indicados como parámetro en el

arranque de cada una de las instancias y contienen la configuración para indicarle a Kamailio que

debe comportarse como un P-CSCF, un I-CSCF y un S-CSCF respectivamente.

La instrucción “include_file” permite la separación de la configuración en diferentes ficheros, de

tal manera que, por ejemplo, en el fichero skamailio.cfg se incluyen otros dos ficheros:

- include_file "scscf.cfg"

- include_file "scripts.cfg"

En el primero, se han incluido el valor de una serie de constantes, de manera que sea más fácil

habilitar o deshabilitar algunas funcionalidades. Estas constantes son utilizadas en el fichero

skamailio.cfg para aplicar un funcionamiento u otro.

En el segundo, se ha incluido la implementación de dos métodos,

“scripts_isChangeOfDestination”, el cuál devolverá en la variable

“scripts_isChangeOfDestination_result” si el destino ha variado tras el disparo de un trigger al

servidor de aplicaciones, y un segundo método,

“scripts_isNecessaryToRevaluateOriginatingServices”, el cuál devolverá en la variable

“scripts_isNecessaryToRevaluateOriginatingServices_result” si es necesario o no revaluar los

servicios originantes. Estos métodos serán utilizados para permitir a Kamailio saber si debe

revaluar los servicios terminantes en un escenario de ReRouting y, para saber si se deben

reevaluar los servicios originantes en un escenario de Forwarding (ver sección - ).

La instrucción “loadmodule” permite cargar los diferentes módulos que se van a utilizar, todos y

cada uno de los módulos que se carguen mediante esta instrucción deben haber sido incluidos en

el fichero “modules.lst” durante la compilación de Kamailio (ver sección B.1.1.7).

Con la instrucción “modparam” es posible dar el valor deseado para los parámetros utilizados

por dichos módulos. Los parámetros que admite cada módulo, junto con sus posibles valores y

descripción pueden ser consultados en la documentación en línea de Kamailio

(http://www.kamailio.org/docs/modules/4.1.x/modules/).

Una vez cargados y configurados los diferentes módulos de Kamailio que se van a utilizar se

pasará a la sección “route”, que contiene la lógica que Kamailio ejecutará en primer lugar. Esta

sección “route” sería el equivalente al método “main” definido en algunos lenguajes de

programación tales como Java o C/C++.

http://www.kamailio.org/docs/modules/4.1.x/modules/


120

Desde esa sección es posible la invocación de otras secciones creadas por el usuario a lo

largo del fichero xkamailio.cfg o de cualquier otro fichero cfg incluído con la instrucción

“include_file”. Y por supuesto, desde cualquier sección, tanto desde la sección “route”

como desde cualquier otra sección creada por el usuario, es posible la invocación de

métodos implementados en cualquiera de los módulos que han sido cargados con la

instrucción “loadmodule”. Nuevamente, la descripción de los dichos métodos puede ser

consultada en la documentación en línea de Kamailio. Por ejemplo, las siguientes líneas

invocan al método “is_method” del módulo “textops” cargado anteriormente con la

instrucción “loadmodule” para determinar si el mensaje entrante es un mensaje

REGISTER. De ser así, saltaremos a la sección REGISTER del fichero skamailio.cfg para

seguir la ejecución en desde dicho punto, una vez ejecutado el código contenido en la

sección REGISTER se ejecutará la instrucción “exit” que interrumpe el resto del código

contenido en la sección principal “route”.

# Handle Registrations:

if (is_method("REGISTER")) {

route(REGISTER);

exit;

}

Las nuevas secciones creadas por el usuario deben ser definidas con la palabra “route” y

con el nombre de la sección entre corchetes. Por ejemplo, en el caso anterior deberíamos

definir la sección REGISTER del siguiente modo:

route[REGISTER] {

……

}

Las nuevas secciones creadas por el usuario pueden ser invocadas tanto desde la sección

principal “route” como desde cualquier otra sección. De modo, que el código puede ser

ordenado en secciones a criterio del usuario. Una de las cosas a tener en cuenta, es que la

instrucción “exit” únicamente interrumpirá la ejecución de la sección actual.

Como se pude ver, las posibilidades de Kamailio son infinitas, y su configuración es tan

potente como compleja. La cantidad de funcionalidad implementada en módulos por la

comunidad de Kamailio es muy grande, aun así, si el usuario necesitara alguna

funcionalidad no implementada o muy específica siempre sería posible implementar un

nuevo módulo en código C++ para ser invocado desde los ficheros cfgs.


121

B.2 Manual de Usuario

En el $HOME del usuario se ha definido un fichero llamado .profileIMS. Este fichero se ejecuta

desde el fichero .profile del usuario “ims”, el cuál es ejecutado por el sistema operativo al entrar

en la máquina IMSLab como usuario “ims”. En este fichero (.profileIMS) se han definido una

serie de variables de entorno, en su mayoría, para facilitar el acceso a los diferentes directorios.

Además, al ejecutar este fichero se muestra por pantalla información de todas estas variables, de

manera que el usuario conozca dichas variables, junto con las direcciones y puertos de cada

nodo.

Por tanto, al entrar en la máquina IMSLab como usuario ims/ims, lo primero que veremos será lo

siguiente:

Figura 47. Prompt usuario ims

Según la Figura 47, podemos utilizar, por ejemplo, la variable OPEN_IMS_HOME para

movernos al directorio /home/ims/OpenIMSCore haciendo “cd $OPEN_IMS_HOME”. Así

mismo, podemos utilizar las variables HSS_HOME, CSCF_HOME, AS_HOME,

RPBX_HOME, UPBX_HOME, etc, del mismo modo.


122

Adicionalmente a las variables comentadas anteriormente, se han definido tres alias para

facilitar ciertas operaciones. Por ejemplo, si tecleamos en el terminal “logs”, se ejecutará

“cd /home/ims/logs”, por lo que nos moveremos al directorio de logs desde cualquier sitio

en el que nos encontremos. Los alias imslab-mng-system e imslab-mng-user ejecutarán los

scripts con el mismo nombre que se comentarán en el punto B.2.4.

En el home del usuario ims/ims tenemos los siguientes directorios:

Figura 48. Contenido $HOME del usuario ims

Cada uno de ellos contiene la configuración y los scripts de arranque de cada uno de los

nodos del laboratorio IMSLab, exceptuando el directorio “interfacesConf”, que contiene el

fichero “/etc/network/interface” que debe ser utilizado para arrancar la máquina virtual en

modo “Standalone” (todos los elementos en una máquina virtual, fichero marcado en

verde), en modo “Isolated” (cada elemento en una máquina virtual diferente, los ficheros

marcados en azul), o en modo “Mix” (HSS, PCSCF, ICSCF y SCSCF en una misma

máquina virtual, y el resto de elementos en máquinas virtuales diferentes, ficheros

marcados en rojo).

Figura 49. Contenido directorio interfacesConf


123

Estos ficheros se han almacenado en este directorio a modo de ayuda, de manera que

dependiendo de la arquitectura que se quiera utilizar para arrancar el laboratorio será necesario,

de manera manual, reemplazar el fichero “/etc/network/interfaces” por el fichero correspondiente

de este directorio.

A continuación veremos uno a uno qué es lo que contiene cada uno del resto de directorios del

home del usuario ims, haciendo algunos comentarios sobre los ficheros más relevantes.

B.2.1 Asterisk-AS

Figura 50. Contenido directorio Asterisk-AS

En la Figura 50, se muestra el contenido del directorio Asterisk-AS. De todos los subdirectorios

que se pueden apreciar en dicha figura se hará especial hincapié en tres de ellos. El directorio

bin, el directorio etc y el directorio sounds.

B.2.1.1 bin

Figura 51. Contenido directorio Asterisk-AS/bin

El directorio bin contiene un único script. Es el script de arranque del Application Server, el cuál

será invocado desde el script de arranque general ims-mng-system (Ver sección B.2.4) cuando se

invoca con la opción “-m as” o cuando se invoca con ninguna opción.

Este script admite los siguientes parámetros:

Usage: asterisk_as.sh <start|stop|status|purge|cli>

start: arranca una instancia de asterisk con la configuración del AS

stop: para la instancia de asterisk que ha sido arrancada con la configuración

del AS


124

status: muestra el estado del AS

purge: elimina los logs generados por el AS.

cli: ejecuta la consola de asterisk sobre la instancia del AS.

Adicionalmente, este script admite el parámetro help, que mostrará

información sobre el script y sus parámetros.

En general, no es necesario usar este script directamente, puesto que lo normal será

utilizarlo desde el script general de manejo del laboratorio IMSLab, ims-mng-system (Ver

sección B.2.4).

B.2.1.2 etc

Figura 52. Contenido directorio Asterisk-AS/etc

El directorio etc contiene la configuración de Asterisk para que se comporte como un

servidor de aplicaciones. Una breve descripción de los parámetros más relevantes de la

configuración de Asterisk se hizo en la sección B.1.3.

B.2.1.3 Sounds

El directorio sounds es especial del Servidor de aplicaciones. Es un directorio que no se

verá ni en la pbx registrada ni en la pbx no registrada, a pesar de ser instancias de Asterisk

también. Este directorio contiene los ficheros .wav disponibles para las locuciones. En este

caso, este fichero está presente porque el AS del laboratorio es un AS + MRF. Es decir, no

sólo es un servidor de aplicaciones, sino que también es un servidor de locuciones.

B.2.2 Asterisk-PBX

Figura 53. Contenido directorio Asterisk-PBX


125

En la Figura 53. Contenido directorio Asterisk-PBX, se muestra el contenido del directorio

Asterisk-PBX. Como su nombre indica, este directorio contiene la configuración y scripts de

arranque de las pbxs del laboratorio. En este caso hay dos tipos de pbxs según su modo de

funcionamiento, registrada y no registrada. Los dos directorios que cuelgan del directorio

Asterisk-PBX hacen honor a esta distinción. Por tanto, podemos ver dos subdirectorios, reg-pbx,

el cual contiene la configuración y los scripts de arranque para la pbx registrada, y el

subdirectorio unreg-pbx, que, de manera análoga, contiene los mismos datos para la pbx no

registrada.

Figura 54.Contenido directorio Asterisk-PBX/reg-pbx

En la Figura 54, se muestra el contenido del directorio reg-pbx, que es exactamente el mismo

que el contenido del directorio unreg-pbx y muy parecido al contenido del directorio Asterisk-

AS. Esto es debido a que tanto las pbxs como el servidor de aplicaciones del laboratorio son

instancias de Asterisk y por tanto, la estructura de directorios y los ficheros de configuración

necesarios serán los mismos. La diferencia radicará en el contenido de dichos ficheros de

configuración. Los parámetros más relevantes de la configuración de Asterisk fue comentada en

la sección B.1.3.

En el directorio bin se encuentra el script de arranque, $RPBX_HOME/bin/asterisk_rpbx.sh para

la pbx registrada y su análogo, $UPBX_HOME/bin/asterisk_upbx.sh para la pbx no registrada.

Estos scripts, al igual que ocurría en el caso del servidor de aplicaciones, serán invocados desde

el script de arranque general ims-mng-system (Ver sección B.2.4), cuando dicho script se invoca

con la opción “-m rpbx” o “-m upbx” respectivamente, o cuando se invoca sin especificar ningún

modo de funcionamiento.

Ambos scripts, admiten los siguientes parámetros:

Usage: asterisk_rpbx.sh <start|stop|status|purge|cli>

start: arranca una instancia de asterisk con la configuración del AS

stop: para la instancia de asterisk que ha sido arrancada con la configuración

del AS


126

status: muestra el estado del AS

purge: elimina los logs generados por el AS.

cli: ejecuta la consola de asterisk sobre la instancia del AS.

Adicionalmente, estos scripts admiten el parámetro help, que mostrará

información sobre los parámetros que se admiten.

Como ocurría en el caso del servidor de aplicaciones, en general, no se suele utilizar estos

scripts directamente, sino que se usan desde el script general de manejo del laboratorio

IMSLab, imslab-mng-system (Ver sección B.2.4).

B.2.3 DNSServer

Figura 55. Contenido directorio DNSServer

En la Figura 55 se puede ver el contenido del directorio DNSServer. Dicho directorio

contiene tres subdirectorios que se comentarán a continuación.

B.2.3.1 Bin

Figura 56. Contenido directorio DNSServer/bin

El directorio bin contiene una serie de scripts que serán ejecutados para arrancar el servidor

de DNS. Desde el script general de arranque ims-mng-system se invocará al script

dns-full-enable.

Básicamente este script ejecutará el resto de scripts que se ven en la Figura 56, los cuáles

realizarán las siguientes tareas:


127

- Dns-deploy.sh: Este script se encarga de generar los ficheros de configuración del

DNSServer correctamente. Los ficheros contenidos en el directorio etc contienen la

configuración del servidor de DNS, sin embargo, en lugar de contener IPs reales, lo que

contienen en su lugar es una serie de cadenas de caracteres. Este script, se encarga de

descubrir la ip local donde es desplegado el DNSServer, y de sustituir la ip local

descubierta y otras ips contenidas en variables definidas en el propio script en dichos

ficheros de configuración. Finalmente los ficheros con las ips reales son copiados en el

directorio deploy. Los ficheros en el directorio deploy son los ficheros que serán

utilizados finalmente. Sin embargo, hay que tener en cuenta que cualquier modificación

de estos ficheros será machacada en el arranque (Ver sección B.1.1.4). Es importante

tener en cuenta, que si queremos realizar alguna modificación sobre la configuración del

Servidor de DNS debe ser hecha en los ficheros de configuración que cuelgan del

directorio etc.

Las variables definidas en el propio script son las siguientes:

Para los puertos, en cualquier modo de arranque se utilizarán las siguientes

variables:

PCSCF_PORT=4060

SCSCF_PORT=6060

ICSCF_PORT=5060

RPBX_PORT=1060

UPBX_PORT=2060

AS_PORT=7060

Las direcciones ips utilizadas dependerán del modo de arranque.

- Si el modo de arranque es “-m all”, entonces todas las ips se cargarán con el

valor de $LOCALIP, que contiene la ip local de la máquina.

- Si el modo de arranque es “-m ims_core”, entonces todas las ips de los nodos del

core IMS se cargarán con el valor de $LOCALIP. Para el resto de ips se

utilizarán los valores:

AS_IP=172.16.0.80

RPBX_IP=172.16.0.10

UPBX_IP=172.16.0.20

- Si el modo de arranque es cualquier otro, se utilizarán los siguientes valores:

HSS_IP=172.16.0.80

DNS_IP=172.16.0.80

PRESENCE_IP=172.16.0.80

PCSCF_IP=172.16.0.40


128

SCSCF_IP=172.16.0.50

ICSCF_IP=172.16.0.60

RPBX_IP=172.16.0.10

UPBX_IP=172.16.0.20

AS_IP=172.16.0.70

- Dns-localservice.sh y Dns-override-resolv.conf.sh: estos dos scripts se encargan

de copiar los ficheros resolv_DNSServer.conf o resolv_DNSClient.conf y

named.conf.local del directorio /home/ims/DNSServer/etc al directorio /etc, desde

donde se carga la configuración por el servicio bind del sistema operativo. Que

este script utilice el fichero resolv_DNSServer.conf o el fichero

resolv_DNSClient.conf para reemplazar al fichero resolv.conf del directorio /etc

dependerá del parámetro “-m” con el que se ha invocado al script imslab-mng-

system. Se utilizará el fichero resolv_DNSServer.conf en aquellos nodos en los que

se encuentra el servidor de DNS, es decir, con la opción “-m hss” cuando estamos

arrancando en modo “Isolated” y el nodo es el HSS, “-m all” o sin opciones cuando

estamos arrancando en modo “Standalone” y “-m ims_core” cuando estamos

arrancando en modo “Mix”.

- Dns-start.sh: inicia el servicio bind del sistema operativo con la configuración

contenida en el directorio /etc (este directorio contiene la configuración correcta

gracias a la ejecución de los scripts dns-localservice.sh y dns-

override-resolv.conf.sh)

- Dns-stop.sh: para el servicio bind del sistema operativo.

B.2.3.2 Deploy

Figura 57. Contenido directorio DNSServer/deploy

Este directorio contiene los ficheros de configuración que especifican la traducción de

nombres para el Servidor DNS. Es un directorio que se regenera cada vez que se arranca el

servidor, como ya se ha explicado en la sección B.1.1.4, por lo que cualquier cambio que

se realice en estos ficheros será perdido en el siguiente reinicio. El contenido de estos

ficheros, se obtiene en el arranque del servidor a partir de los ficheros de configuración que

cuelgan del directorio etc, tras pasar un proceso de sustitución de ciertos parámetros por el

contenido de algunas variables que indican la ips reales del despliegue.


129

B.2.3.3 Etc

Figura 58. Contenido directorio DNSServer/etc

Este directorio contiene los ficheros base a partir de los cuáles se generarán los ficheros que

usará el servidor de DNS. En estos ficheros están definidos los dominios del laboratorio

IMSLab. En estos ficheros existen una serie de cadenas de caracteres en lugar de direcciones ip.

Tras el arranque del servidor dichas cadenas de caracteres serán sustituidas en estos ficheros

dando lugar a los ficheros contenidos en el directorio deploy (Ver sección B.1.1.4).

B.2.3.4 Logs

Figura 59. Contenido directorio logs

En la Figura 59 se muestra el contenido del directorio de logs cuando todos los nodos son

arrancados sobre la misma máquina virtual. Por tanto, el directorio de logs sólo contendrá los

logs correspondientes a los nodos que se hayan arrancado para cada máquina. Se pueden apreciar

los logs generados por cada una de las instancias de Kamailio, icscf.log contiene los logs del

icscf, pcscf.log contiene los logs del pcscf y, por último, scscf.log contiene los logs del scscf.

También vemos que los logs del hss se reparten entre tres ficheros diferentes, hss.activities.log,

hss.log y hss.server.log.

Por otro lado, puede apreciar el fichero stun.log que contiene los logs del servidor de STUN. Y

por último, vemos tres directorios que contienen los logs generados por las instancias de

Asterisk.


130

B.2.4 OM: Scripts

Figura 60. Contenido directorio om

La Figura 60 muestra el contenido del directorio om. Este directorio contiene los scripts

generales de manejo del laboratorio. Se puede apreciar un directorio, user_prov_scripts, el

cual contiene los script mysql generados por el script imslab-mng-user.sh. Este directorio

no debe ser eliminado ni manipulado, puesto que si eliminamos los scripts que se han

generado automáticamente por el script de creación de usuarios, no seremos capaces de

eliminar un usuario creado automáticamente.

A continuación se comentará detalladamente el funcionamiento de los scripts.

- ims-mng-system.sh: es el script de arranque del laboratorio. Si ejecutamos el script

con el parámetro “help”, se mostrará una ayuda sobre el uso del script.


Uso: ims-mng-system.sh [-m pcscf|scscf|icscf|hss|imscore] <start|stop|status|purge>

Uso: ims-mng-system.sh [-m as|rpbx|upbx|all] <start|stop|status|purge|cli>

-m o –mode pcscf|scscf|icscf|hss|imscore|as|rpbx|upbx|all: es un parámetro

opcional. Si no se indica se ejecutará en modo “all”.

pcscf: se arrancará sólo una instancia de Kamailio con la configuración

de un pcscf.

scscf: se arrancará sólo una instancia de Kamailio con la configuración

de un scscf.

icscf: se arrancará sólo una instancia de Kamailio con la configuración

de un icscf.

Hss: se arrancarán los elementos adicionales, es decir, hss, rtpproxy,

Imscore: se arrancarán todos los nodos del core ims (pcscf, icscf y

scscf), junto con los elementos adicionales

As: se arrancará Asterisk con la configuración del AS

Rpbx: se arrancará Asterisk con la configuración de la pbx registrada

Upbx: se arrancará Asterisk con la configuración de la pbx no

registrada.

All: se arrancarán todos los nodos del core ims, los elementos

adicionales, el as, y las pbx.


131

Además del modo de arranque, es necesario indicar la acción a realizar. Este

parámetro se pasa directamente a los scripts contenidos en los directorios bin de

cada nodo.

Start: arranca el nodo o nodos indicados con el parámetro –m o -mode

Stop: para el nodo o nodos indicados con el parámetro –m o -mode

Status: indica el estado para el nodo o nodos indicados con el parámetro –m o

-mode

Purge: elimina los logs generados por el nodo o nodos indicados en el

parámetro –m o -mode

Cli: Sólo para las instancias de Asterisk (as, rpbx y upbx) es posible ejecutar

la consola cli de Asterisk a través de este script.

- imslab-mng-user.sh: es un script de generación de usuarios en el HSS. Actúa

directamente sobre el modelo de datos de la base de datos hss_db creando o eliminando los

registros necesarios para dar de alta o de baja un usuario en el hss. Este script sólo da de alta

o de baja usuarios sip. De manera que la creación de las extensiones de la pbx no registrada

o las psis necesarias para la pbx no registrada deben ser dadas de alta a través de la Web del

HSS. Cuando se ejecuta el script sin especificar ningún parámetro se muestran los

parámetros que admite el script. Se muestra a continuación dicha descripción

Uso: imscore-mng-user.sh -u <user> [-s <service-profile>] [-t] [-x

<additional_formats_flags>] [-i <infix>] [-r <realm>] [-p <password>] [-a|-d]

[-c]

-u <user>: The username (e.g. '+491234567890')

-s <service-profile>: The name of the service profile

-t: Include tel-uri version, as well as a sip-uri with user=phone version

-x <additional_formats_flags>: Four 1/0 values, activating/deactivating the

impus with the formats international_with_00_prefix, national and

national_with_0_prefix respectively

-h <prefix>: Prefix to add before +CC

-i <infix>: Infix to include between CC and NSN

-r <realm>: The realm. Default is 'open-ims.lab.es'

-p <password>: The password. Default is value of -u option

-a: Automatically apply created add script

-d: Automatically apply created delete script

-c: Delete the scripts afterwards (by default they are not deleted)

-b: Include uri finishing with port

Supported CC list: +34 +49 +31 +420 +353 +30 +39 +15


132

B.2.5 OpenIMSCore

Figura 61. Contenido directorio OpenIMSCore

La Figura 61 muestra el contenido del directorio OpenIMSCore, que contiene la

configuración y los scripts de arranque del HSS (FHoSS) y de los nodos del CSCF(X-

CSCF). A continuación se detallará el contenido de dichos directorios.

B.2.5.1 FHoSS

Figura 62. Contenido directorio OpenIMSCore/FHoSS

La Figura 62 muestra el contenido del directorio FHoSS. Este directorio contiene la

configuración y el script de arranque de nodo HSS. Este directorio contiene tres ficheros de

configuración importantes:

- DiameterPeerHSS.xml, que contiene la configuración de los peers de Diameter

establecidos entre el HSS-ICSCF y el HSS-SCSCF

- hibernate.properties, que contiene los datos de conexión con la base de datos del

HSS.

- hss.properties, que contiene, entre otras cosas, la ip y el puerto de escucha del

HSS.


133

Además, es necesario hacer especial mención a los links simbólicos webapps y lib, que

contienen referencias al directorio donde se descargó el software del HSS (Ver sección B.1.1.6).

Por otro lado, este directorio contiene varios sub-directorios, de los cuáles, los más relevantes

son el directorio bin y el directorio bin, que serán comentados en detalle a continuación.

B.2.5.1.1 Bin

Figura 63. Contenido directorio OpenIMSCore/FHoSS/bin

Como se puede ver en la Figura 63 en el directorio bin se encuentra el script de arranque del

HSS. Este script es invocado desde el script de arranque general ims-mng-system (Ver

sección B.2.4), cuando se invoca con ninguna opción, o con las opciones “-m hss” o “-m

imscore”. Este script arrancará tanto el nodo HSS como la interfaz web de dicho nodo.

B.2.5.1.2 Conf

Figura 64. Contenido directorio OpenIMSCore/FHoSS/conf

El directorio conf contiene la configuración de la página web del HSS. Por ejemplo, en el fichero

tomcat-users.xml están definidos los usuarios de acceso para interfaz web. En nuestro caso el

usuario será hss/hssAdmin.

B.2.5.2 X-CSCF

Figura 65. Contenido directorio OpenIMSCore/X-CSCF


134

La Figura 65 muestra el contenido del directorio X-CSCF. Este directorio contiene la

configuración y los scripts de arranque de los tres nodos que constituyen nuestro core IMS,

es decir, el P-CSCF, el I-CSCF y el S-CSCF. A continuación se detallan los directorios

más relevantes y su contenido.

B.2.5.2.1 Bin

Figura 66.Contenido directorio OpenIMSCore/X-CSCF/bin

El directorio bin contiene los scripts de arranque de cada uno de los nodos del Core IMS.

Como se puede ver en la Figura 66, existen tres scripts, cada uno de ellos, como su propio

nombre indica, controla una instancia de Kamailio diferente. Cada una de ellas configurada

para funcionar como cada uno de los nodos del laboratorio. Cada uno de los scripts es

invocado desde el script de arranque general (Ver sección B.2.4), cuando se invoca con

ninguna opción, o con las opciones “-m icscf”, “-m pcscf”, “-m scscf” o “-m imscore”,

respectivamente. Todos los scripts admiten los mismos parámetros:

Usage: icscf/pcscf/scscf start|stop|status

start: arranca una instancia de kamailio con la configuración del icscf/pcscf/scscf

respectivamente.

stop: para la instancia de kamailio que se arrancó con la configuración del

icscf/pcscf/scscf respectivamente

status: muestra el estado de cada uno de los nodos.


135

B.2.5.2.2 Etc

Figura 67. Contenido directorio OpenIMSCore/X-CSCF/etc

La Figura 67 muestra el contenido del directorio etc. Este directorio contiene la configuración

necesaria para que Kamailio funcione en modo icscf, pcscf y scscf respectivamente. Para todos los

nodos encontraremos ficheros comunes, como son:

- ikamailio.cfg/pkamailio.cfg/skamailio.cfg: Estos ficheros contienen la configuración de la

lógica de kamailio. Qué hacer en cada caso, tras la recepción de cada uno de los mensajes

SIP que puedan alcanzar cada nodo.

- icscf.cfg/pcscf.cfg/scscf.cfg: Estos ficheros contienen el valor de algunas variables

utilizadas en los ficheros xkamalio.cfg, como dominios, ips, y la activación o desactivación

de funcionalidades.

- network-interface.cfg: contiene la ip de cada uno de los nodos. Este fichero es generado en

el arranque por los scripts de arranque que descubren la ip local y la almacenan en este

fichero. Luego esta ip local es utilizada para arrancar las instancias de kamailio.

A continuación se comentará el contenido no común de cada nodo.

Icscf

Figura 68. Contenido directorio OpenIMSCore/X-CSCF/etc/icscf

La Figura 68 muestra el contenido del directorio icscf, el cual contiene la configuración de

Kamailio necesaria para funcionar en modo icscf. Como se puede ver en la figura, además de los

ficheros comunes a todos los nodos comentados en la sección B.1.4.1, existe un nuevo fichero, el

icscf.xml. En este fichero se encuentra la configuración del peer de Diameter que se establece

entre el HSS y el ICSCF.


136

Pcscf

Figura 69. Contenido directorio OpenIMSCore/X-CSCF/etc/pcscf

La Figura 69 muestra el contenido del directorio pcscf, el cual contiene la

configuración de Kamailio necesaria para funcionar en modo pcscf. Como se

puede ver en la figura, además de los ficheros comunes a todos los nodos

comentados en la sección B.1.4.1, existen varios nuevos ficheros:

- pcscf.xml: Este fichero no se utiliza, puesto que el pcscf no se comunica

con el HSS.

- dispatcher.lst: contiene la lista de scsfs disponibles. En nuestro despliegue

sólo hay un scscf, sin embargo, y con la utilización de este fichero el pcscf

es capaz de actuar como balanceador de carga entre varios scscfs.

- modules_path.cfg: contiene una variable donde se especifica el path donde

se encuentran los módulos de Kamailio.

- tls.cfg: contiene el path donde se encuentran las claves públicas y privadas

de Kamailio. Sólo se utiliza en caso de tener el módulo tls activo. En

nuestro caso no se utiliza.

Scscf

Figura 70.Contenido directorio OpenIMSCore/X-CSCF/etc/scscf


137

La Figura 70 muestra el contenido del directorio scscf, el cual contiene la configuración

de Kamailio necesaria para funcionar en modo scscf. Como se puede ver en la figura,

además de los ficheros comunes a todos los nodos comentados en la sección B.1.4.1,

existen varios nuevos ficheros:

- scscf.xml: De manera análoga a lo que ocurría en el icscf, en este fichero se

encuentra la configuración del peer de Diameter que se establece entre el HSS y el

SCSCF.

- dispatcher.list: contiene la lista de servidores de aplicaciones disponibles. En

nuestro despliegue sólo hay un as, sin embargo, y con la utilización de este fichero

el scscf es capaz de actuar como balanceador de carga entre varios servidores de

aplicaciones.

- scripts.cfg: contiene una serie de métodos que se han implementado para calcular

si ha habido cambio de destino y para, en caso de haberlo, calcular si es necesario

la revaluación de los servicios originantes (Desvío de llamada) o sólo los servicios

terminantes (Re-Routing de llamada). Estos métodos se invocan desde el fichero

skamailio.cfg.

- CxDataType_Rel6.xsd/CxDataType_Rel7.xsd: Estos ficheros contienen la

definición de la estructura de datos intercambiada entre el HSS y el SCSCF.

B.2.6 RTPProxy

Figura 71. Contenido directorio RTPProxy

Como se puede ver en la Figura 71, en el directorio RTPProxy/bin se encuentra el script de arranque

del proxy de RTP (ver sección 4.1). Este script es invocado desde el script de arranque general ims-

mng-system (Ver sección B.2.4), cuando se invoca con ninguna opción, o con las opciones “-m hss”

o “-m imscore”.


Usage: rtpproxy <start|stop|status>

start: arranca una instancia del Servidor de RTP

stop: para la instancia del servidor de RTP

status: muestra el estado del servidor de RTP.

Adicionalmente, este script admite el parámetro help, que mostrará información sobre el

script y sus parámetros.


138

B.2.7 STUNServer

Figura 72. Contenido directorio STUNServer

En el Directorio STUNServer se ha definido un servidor de Stun. Un servidor de Stun permite

a los usuarios del laboratorio que se encuentran detrás de un servidor de NAT descubrir su IP

pública. Esta funcionalidad es únicamente válida para aquellos softphones que la soporten,

como por ejemplo Zoipper. El protocolo STUN está definido en el a RFC 5989 [8.7]. Pero

básicamente se trata de un protocolo basado en arquitectura cliente/servidor en la que el

cliente STUN (teléfonos o software VoIP que incorporan un cliente STUN) envía una petición

a un servidor de STUN. Este responde al cliente informándole de la IP pública por la que ha

llegado dicha petición y del puerto NAT que se ha utilizado. Con esta información, el cliente

de VoIP será capaz de crear un canal de comunicación de voz incluso detrás de NAT.

Como se puede ver en la Figura 72, en el directorio bin del servidor de STUN, tan sólo reside

un único script. Es el script de arranque del servidor. Este script es invocado desde el script de

arranque general ims-mng-system (Ver sección B.2.4), cuando se invoca con ninguna opción

o con las opciones “-m hss” o “-m imscore”.


Usage: stun.sh <start|stop|status|purge>

start: arranca una instancia del Servidor de STUN

stop: para la instancia del servidor de STUN

status: muestra el estado del servidor de STUN.

purge: elimina los logs generados por el Servidor de STUN

Adicionalmente, este script admite el parámetro help, que mostrará información sobre

el script y sus parámetros.


139

B.2.8 WireShark

WireShark es una herramienta de captura y análisis de tráfico de red. Esta herramienta nos permitirá

analizar el tráfico de red capturado con tcpdump desde las máquinas virtuales, así como capturar y

analizar el tráfico en la máquina física.

Captura de tráfico

Desde las máquinas virtuales podemos ejecutar el siguiente comando para capturar tráfico en

cualquier interfaz de red y guardarlo en “/home/ims/logs/test.pcap”.

ims@IMSLab:~$ sudo /usr/sbin/tcpdump -c 100000 -s 65535 -i any -w

/home/ims/logs/test.pcap

Desde la máquina física, ejecutaremos la aplicación WireShark, seleccionaremos todas las

interfaces de red valiéndonos de la tecla “Control” o de la tecla “Mayús” izquierda y presionaremos

el botón “Start” en la sección “Capture” de la aplicación para analizar el tráfico entre los softphones

y el P-CSCF, PBX-REG o PBX-UNREG. Este tráfico también puede ser capturado utilizando

tcpdump desde las máquinas virtuales que ejecutan dichos nodos.

Figura 73. Captura de tráfico desde WireShark


140

Análisis de tráfico

Ya sea capturando el tráfico directamente con WireShark desde la máquina física como

capturándolo en alguna de las máquinas virtuales con tcpdump, tendremos en nuestro poder

un fichero pcap que podrá ser abierto con WireShark para poder ser analizado.

Antes de pasar al análisis de las trazas capturadas deberíamos configurar WireShark de tal

manera que sea capaz de decodificar el tráfico Diameter y para traducir las direcciones IP por

un nombre más vistoso e intuitivo. Para ello debermos hacer una serie de cosas. Esto sólo será

necesario hacerlo una vez:

- Decodificación del tráfico Diameter: básicamente le diremos a WireShark que todo

el tráfico TCP procedente y con destino un determinado puerto, es tráfico Diameter y

debe decodificarlo como tal. Para hacer esto, iremos al menú Edità Preferences. En

la ventana emergente tenemos una lista a la izquierda donde debemos expandir la

pestaña de “Protocols” y buscar el protocolo “DIAMETER”. En la parte de la

derecha debemos indicar los puertos TCP que deben considerarse tráfico Diameter.

En nuestro caso los puertos 3868, 3869 y 3870.

Figura 74. Configuración WireShark para decodificar Diameter

- Para que WireShark sea capaz de traducir las direcciones IP por una cadena de

caracteres, debemos hacer lo siguiente:

1. Iremos al menú Edit à Preferences. En la ventana emergente tenemos una

lista a la izquierda donde debemos pinchar en el elemento Name Resolution y

marcar “Resolve Network (IP) address” y desmarcar “User an External

Network Name Resolver” y “Enable concurrent DNS Name Resolution”. Con

esta configuración WireShark usará un fichero para la traducción de nombres.

2. Debemos establecer la traducción de nombres en el fichero hosts. Editamos el

fichero %USERPROFILE%\AppData\Roaming\Wireshark\hosts y

establecemos la siguiente traducción:


141

172.16.0.40 pcscf.open-ims.lab.es

10.0.3.15 pcscf.open-ims.lab.es

172.16.0.50 icscf.open-ims.lab.es

172.16.0.60 scscf.open-ims.lab.es

172.16.0.70 as.open-ims.lab.es

172.16.0.80 hss.open-ims.lab.es

Una vez realizada esta configuración previa, ya estamos en disposición de analizar las trazas

capturadas.

1. Abrimos el fichero pcap desde el Menú File à Open

2. Si filtramos por “sip or diameter”, sólo veremos los mensajes SIP y los mensajes Diameter

contenidos el fichero pcap.

3. Además, si la configuración de traducción de nombres ha ido bien, veremos en la columna

“Source” y en la columna “Destination” los nombres que hemos definido en el fichero

“hosts” en vez de las IPs de origen y destino de los mensajes.

4. Si queremos ver la llamada de VoIP de manera más gráfica, WireShark ofrece una

funcionalidad que nos permitirá hacerlo. Únicamente indicar que en este gráfico sólo se

mostrarán los mensajes SIP procedentes de la comunicación de VoIP, por lo tanto quedarán

fuera tanto los mensajes Diameter como los mensajes SIP relativos al registro o mensajes

“OPTIONS” utilizados como “keepalives”, etc.

Para hacer uso de esta funcionalidad gráfica bastará con ir al menú Telephony àVoIP

Calls. En la pantalla emergente pulsaremos en el botón “Select All” o seleccionaremos de la

lista ayuda de la tecla “Control” o de la tecla “Mayús” izquierda las llamadas que queramos

incluir en el flujo gráfico, y finalmente, pulsaremos sobre el botón “Flow”.

Figura 75. WireShark. Ventana emergente de VoIP Calls


142

Esto nos mostrará un flujo gráfico como el mostrado en la Figura 76, Figura 77 y

Figura 78.

Figura 76. Flujo VoIP Calls parte 1.

Figura 77. Flujo Voip Calls parte 2


143

Figura 78. Flujo VoIP Calls parte 3.

5. Finalmente, si lo que queremos es ver el tráfico RTP debemos ser conscientes de que el

tráfico RTP es tráfico extremo a extremo y que por tanto, no todas las capturas de tráfico

realizadas en las máquinas virtuales tendrán tráfico de este tipo. Sólo las capturas de tráfico

realizadas en el Servidor de aplicaciones y las capturas de tráfico realizadas en la máquina

física donde corren los softphone contendrán tráfico RTP. Para estas capturas si vamos al

menú Telephony à RTP y pulsamos en “Show all stream” en la pantalla emergente,

seremos capaces de ver los paquetes RTP. En esta misma pantalla y seleccionando

previamente el paquete que queremos analizar, si pulsamos sobre “Analyze” se abrirá una

nueva pantalla emergente que contendrá el fichero de audio transmitido por RTP.

Seleccionando el paquete y pulsando en “Player” podremos escuchar el audio que se ha

transmitido.

Documents

PROYECTO FIN DE GRADOoa.upm.es/52129/1/TFG_ESTHER_BENAYAS_MELERO.pdf · 2018-09-10 · Asterisk es un B2BUA, por lo que, de manera análoga, todos los nodos de una red IMS que funcionen