Anteproyecto Beca LACNIC XII - Dirección General de Informática

Transcripción

Ing. Mariano Javier Martín – Universidad Nacional de Villa María
PROYECTO
CONVOCATORIA A BECAS
PARA PARTICIPACIÓN EN EVENTO LACNIC XII
Denominación:
“Implementación de un servicio de encaminamiento de llamadas de voz sobre IP bajo
protocolo SIP entre Universidades Nacionales a través de RIU”
Ing. Mariano Javier MARTIN
Universidad Nacional de Villa María
INFORME
PERÍODO: JULIO-DICIEMBRE 2009
VILLA MARÍA, CÓRDOBA, ARGENTINA
2009
- Página 1 -
CONTENIDOS
C.01 Objetivos del Proyecto
Pág. 03
C.02 Introducción al Proyecto
Pág. 04
C.03 Características del Protocolo SIP
Pág. 05
C.04 Entidades que componen una red basada en SIP
Pág. 07
C.05 Mensajes, Transacciones y Diálogos SIP
Pág. 10
C.06 Tipos de Servidores Proxy SIP
Pág. 12
C.07 Escenarios de Registro, Inicio y Finalización de Sesión
Pág. 13
C.08 Problemática de NAT empleando SIP y RTP
Pág. 15
C.09 Arquitectura de Red VoIP propuesta para RIU
Pág. 23
C.10 Escenarios por Universidad según plataforma disponible
Pág. 26
C.11 Definición de rutas y prefijos de marcado
Pág. 30
C.12 Servidor Proxy SIP: Definiendo el Software a utilizar
Pág. 32
C.13 Arquitectura OpenSER / Kamailio
Pág. 34
C.14 Virtualización y Despliegue
Pág. 40
C.15 Configuración de Kamailio
Pág. 46
C.16 Seguridad en la Red
Pág. 49
C.17 Conclusiones: Vinculación con Otros Proyectos
Pág. 51
A.01 Anexo I: Archivo de Configuración “kamailio.cfg”
Pág. 53
A.02 Anexo II: Instalación de OpenVPN
Pág. 56
R.01 Referencias
Pág. 61
- Página 2 -
CAPÍTULO 1
Objetivos

Permitir la comunicación eficaz, directa y sin costo entre todos los miembros de la
comunidad académica, científica y personal administrativo de las Universidades
Nacionales.

Fomentar los trabajos colaborativos mediante el incremento de
los niveles de
comunicación ente comunidades académicas.

Integrar los diferentes servicios de Telefonía IP existentes en las UU.NN. dentro de
RIU y asesorar a aquellas UU.NN. que no dispongan de esta tecnología para su pronta
incorporación.

Emplear protocolos de comunicación abiertos y escalables y con soporte de servicios
colaborativos para mejorar la comunicación de voz sobre IP mediante el uso de la
infraestructura de la RIU.
Aportes y Contribuciones
Cabe mencionar la buena predisposición puesta de manifiesto en todo momento por
el equipo técnico de ARIU y fundamentalmente el apoyo del Sr. Gerardo José Venier,
Director General de Informática de la Universidad Nacional de Villa María, que puso a
disposición del proyecto recursos materiales y humanos de su parte para poder alcanzar los
objetivos antes mencionados.
- Página 3 -
CAPÍTULO 2
Introducción
Para este proyecto se propone como mecanismo de control de llamada la utilización
del protocolo SIP (Session Initiation Protocol). Se trata de un estándar del IETF (Internet
Engineering Task Force) y su RFC (Request For Comments) es el número 3261.
El eje central del proyecto se definió como “un enrutador de llamadas” empleando el
protocolo SIP. Para comprender acabadamente los fundamentos del mismo, será necesario
en primera instancia, definir conceptos relacionados con SIP tales como: principio de
funcionamiento, entidades lógicas que participan y la forma en que interactúan.
De esta manera se hace posible entender el diseño y arquitectura de red propuesto
teniendo en cuenta las particularidades de RIU (Red de Interconexión Universitaria) y de los
nodos que intervienen (Universidades Nacionales).
- Página 4 -
CAPÍTULO 3
Características del protocolo SIP
SIP es un protocolo genérico de establecimiento de sesiones multimedia. El inicio de
la sesión, cambio o término de la misma, son independientes del tipo de medio o aplicación
que establece la llamada; una sesión puede incluir varios tipos de datos, incluyendo audio,
video y muchos otros formatos.
SIP es un protocolo de capa de aplicación, cuyo diseño permite una fácil
implementación y una buena escalabilidad y flexibilidad. Se encuentra disponible en su
versión 2.0 y está documentado a través del RFC 3261; el cual reemplaza a la versión
anterior (RFC2543).
SIP se complementa con otros protocolos tales como SDP (Sesion Description
Protocol) y RTP/RTCP (Real Time Protocol) para completar la comunicación. RTP/RTCP se
emplea para transportar los datos multimedia en tiempo real mientras que SDP se utiliza
para describir las características de los participantes de la sesión multimedia. Es un protocolo
orientado a conexiones End-to-End. Toda la lógica se encuentra almacenada en los
dispositivos finales (salvo el ruteo de mensajes).
Las funciones principales de SIP son:




Establecer, modificar y finalizar las sesiones entre dos o más participantes.
Registro y localización de participantes (Movilidad)
Gestión del conjunto de participantes y de los componentes del sistema.
Describir las características de las sesiones y negociar las capacidades de los
participantes.
Algunas de sus características son:





Basado en Texto. (Similar a HTTP)
Uso de Identificador Universal de Recursos (URIs con esquemas sip, sips y tel)
Métodos básicos: INVITE, ACK, BYE, CANCEL, REGISTER, OPTIONS.
Los mensajes se agrupan en transacciones y llamadas (diálogos).
Las descripciones de sesiones multimedia (SDP) se encuentran en el cuerpo de los
mensajes.
 Localización basada en DNS.
Protocolo SDP (Session Description Protocol)
Este protocolo fue diseñado para transportar información de la sesión/medios hacia los
destinatarios. Permite asociar más de un flujo de medios a una misma sesión (Audio y Video). Para
ello se establece una descripción y negociación de los parámetros de sesión a través de mensajes
- Página 5 -
SDP codificados como texto plano (ISO 10646 UTF-8) cuyos nombres de campo y atributos usan USASCII pero los demás emplean 10646. Se eligió este formato para aumentar la “portabilidad” hacia
sistemas Web.
Protocolo RTP / RTCP (Real Time Protocol / Real Time Control Protocol)
El RFC 1889 se refiere a este protocolo como “Transporte y Monitoreo de Flujos en Tiempo
Real”. (Real Time Media Streaming).
Sus funciones principales son:




Identificación del tipo de carga útil transportada (Codecs de Audio/Video)
Verificación de la entrega de los paquetes en orden (Marca de tiempo) y si resulta necesario
reordenar los bloques fuera de orden.
Transporte de información de sincronismo para la codificación y decodificación
Monitoreo de la entrega de la información.
- Página 6 -
CAPÍTULO 4
Entidades que componen una red basada en SIP
A continuación se definen las diferentes entidades que componen una red basada en
protocolo SIP. Esto es importante para definir conceptos tenidos en cuenta en este proyecto.




Agentes de Usuario (User Agent)
Servidor Registrar
Servidor Redirect
Servidor Proxy
Agentes de Usuario (UA)
Se denominan Agentes de Usuario (UA: User Agent) a los terminales que utilizan SIP
para encontrar y negociar con otros terminales las características de la sesión.
Cada Agente de Usuario (UA) se compone lógicamente de dos entidades:
 Agente de Usuario Cliente (UAC)
 Agente de Usuario Servidor (UAS)
El UAC es la parte del agente de usuario que genera peticiones y recibe respuestas a
esas peticiones. El UAS es la parte del agente de usuario que recibe peticiones y genera
respuestas.
Un agente de usuario se comporta como UAC o UAS dependiendo de la situación.
Por ejemplo un agente de usuario que realiza una llamada se comporta como UAC cuando
envía mensaje de INVITE y recibe las respuestas a ese pedido. Un agente de usuario llamado
se comporta como UAS cuando recibe el mensaje de INVITE y envía las respuestas. Pero esta
situación cambia cuando la parte llamada decide enviar un mensaje BYE para terminar la
sesión. En este caso el agente de usuario llamado se comporta como UAC (enviando un BYE)
y el agente de usuario llamante se comporta como UAS.
SIP: AGENTES DE USUARIO
UA (A)
UA (B)
INVITE
UAC
UAS
UAS
UAC
BYE
- Página 7 -
Servidor “Registrar”
Este elemento de Red posee la función de autenticar y validar la cuenta de un usuario contra
una base de datos interna o externa y “registrar” la localización actual del mismo. Este tipo de
servicio, la mayoría de las veces se implementa en forma conjunta con el servidor Proxy SIP.
SIP: REGISTRO
Registro de Base de Datos
Usuario: sip:[email protected]
Alcanzable en: [email protected]:5060
UA
Location
Database
Registrar
REGISTER
(Sin Credenciales)
407
(Error)
Almacena
REGISTER
(Con Credenciales)
sip:[email protected]
REGISTER
200 OK
OK
170.210.68.247:5060
Servidor
Registrar
Servidor “Redirect”
Esta entidad que integra una red SIP escucha peticiones y regresa respuestas que contienen
la localización actual de un usuario en particular. Estas respuestas son mensajes SIP de clase 3XX.
El usuario o Proxy que realizó la petición original extrae la información de las respuestas y
envía otra petición “redirigida” en base al resultado de la búsqueda.
SIP: REDIRECT
INVITE #1
Servidor
Redirect
302: Moved Temporarily
INVITE #2
USUARIO A
USUARIO B
- Página 8 -
Servidor “Proxy”
Son aplicaciones que reciben los pedidos de los clientes SIP e inician nuevas
peticiones hacia los agentes de usuario de destino o hacia otros servidores Proxy. Es decir,
actúan enrutando los mensajes SIP, en base a reglas predefinidas.
Los Proxy SIP tienen la habilidad de conocer varias rutas alternativas para localizar a
un agente de usuario y pueden intentar el proceso de bifurcación en forma secuencial o en
paralelo dependiendo de cómo este configurado el Proxy.
SIP: RUTEO
INVITE
INVITE
Proxy
Usuario A
BYE
Usuario B
INVITE
INVITE
INVITE
Proxy A
Proxy B
Usuario A
BYE
- Página 9 -
Usuario B
CAPÍTULO 5
Mensajes, Transacciones y Diálogos SIP
Mensajes SIP
SIP es un protocolo textual que usa una semántica semejante a la del protocolo HTTP.
Como se vio anteriormente, los UAC realizan las peticiones y los UAS retornan respuestas a
las peticiones de los clientes. SIP define la comunicación a través de dos tipos de mensajes.
Las solicitudes (métodos) y las respuestas (códigos de estado) emplean el formato de
mensaje genérico establecido en el RFC 2822 , que consiste en una línea inicial seguida de un
o más campos de cabecera (headers), una línea vacía que indica el final de las cabeceras, y
por último, el cuerpo del mensaje que es opcional.
Peticiones, Solicitudes o Métodos SIP
Las peticiones SIP son caracterizadas por la línea inicial del mensaje, llamada
Request-Line, que contiene el nombre del método, el identificador del destinatario de la
petición (Request-URI) y la versión del protocolo SIP. Existen seis métodos básicos SIP que
describen las peticiones de los clientes:
- INVITE: Permite invitar un usuario o servicio para participar en una sesión o para
modificar parámetros en una sesión ya existente.
- ACK: Confirma el establecimiento de una sesión.
- OPTION: Solicita información sobre las capacidades de un servidor.
- BYE: Indica la terminación de una sesión.
- CANCEL: Cancela una petición pendiente.
- REGISTER: Registrar al User Agent.
Sin embargo, existen otros métodos adicionales que pueden ser utilizados,
publicados en otros RFCs como los métodos INFO, SUBSCRIBER,etc.
Respuestas (Códigos de estado) SIP
Después de la recepción e interpretación del mensaje de solicitud SIP, el receptor del
mismo responde con un mensaje. Este mensaje, es similar al anterior, difiriendo en la línea
inicial, llamada Status-Line, que contiene la versión de SIP, el código de la respuesta (Status–
Code) y una pequeña descripción (Reason-Phrase). El código de la respuesta está compuesto
- Página 10 -
por tres dígitos que permiten clasificar los diferentes tipos existentes. El primer dígito define
la clase de la respuesta.
Código - Clases
1xx - Mensajes provisionales.
2xx - Respuestas de éxito.
3xx - Respuestas de redirección.
4xx - Respuestas de fallo de método.
5xx - Respuestas de fallos de servidor.
6xx - Respuestas de fallos globales.
Transacciones y Diálogos SIP
Una Transacción SIP es una secuencia de mensajes entre dos elementos de Red. Corresponde
a una petición y todas sus respuestas. Una transacción puede incluir cero o más respuestas
provisionales y una o más respuestas finales (INVITE puede ser dividido por un Proxy, por lo tanto
tendrá múltiples respuestas finales).
Un Diálogo SIP es una conversación peer-to-peer entre dos UA (Agentes de Usuario). Los
diálogos son identificados usando los campos Call-ID (Id. de llamada), From (De) y To (Para). Los
mensajes con estos campos iguales pertenecerán al mismo diálogo. Un diálogo es una secuencia de
transacciones.
SIP: TRANSACCIONES Y DIALOGOS
UA 1
UA 2
INVITE
TRYING
TRANSACCIÓN N° 1
RINGING
OK
DIÁLOGO
ACK
RTP Streams
BYE
TRANSACCIÓN N° 2
OK
- Página 11 -
CAPÍTULO 6
Tipos de Servidores Proxy SIP
Existen dos tipos de servidores Proxy: Stateful y Stateless.
• Stateful Proxy (Dialog & Transaction)
Los servidores Proxy Stateful retienen cierta información (estado) durante la llamada.
Respecto del tipo de información que pueden retener los servidores Proxy Stateful cabría
realizar una nueva clasificación. Es muy común encontrarse con aplicaciones como por
ejemplo aquellas basadas en SER (Sip Express Router) que solamente actúan manteniendo el
estado para una simple transacción SIP (minimal state). En esta caso se dice que estamos en
presencia de un servidor tipo “Transaction Stateful Proxy”. En el caso que se almacene el
estado durante todo el tiempo que dure el establecimiento de una llamada estaremos en
presencia de un “Dialog Stateful Proxy”.
• Stateless Proxy
Los servidores Proxy Stateless, procesan un mensaje SIP y olvidan todo lo referente a
la llamada hasta que vuelven a recibir otro mensaje SIP. La implementación Stateless provee
buena escalabilidad, pues los servidores no requieren mantener información referente al
estado de la llamada una vez que la transacción ha sido procesada. Además, esta solución es
muy robusta dado que el servidor no necesita “recordar” nada en relación con una llamada.
Sin embargo, no todas las funcionalidades pueden ser implementadas en un servidor proxy
stateless, por ejemplo, las funcionalidades relativas al accounting y facturación de las
llamadas puede requerir funcionalidades proxy stateful, de manera que se les pueda “seguir
el rastro” a todos los mensajes y estados de una comunicación.
- Página 12 -
CAPÍTULO 7
Escenarios de Registro, Inicio y Finalización de Sesión
Escenario de Registro SIP
Para que un usuario pueda ser llamado por otro, este debe registrarse primero ante el
Registrar (o Proxy). El registro consiste en el envío de un mensaje REGISTER seguido de su
correspondiente respuesta 200 OK. Si el usuario no da credenciales válidas recibirá por respuesta un
mensaje 407, con lo cual tendrá que reenviar el mensaje de Registro hasta que tenga éxito.
SIP: REGISTRO
Registro de Base de Datos
Usuario: sip:[email protected]
Alcanzable en: [email protected]:5060
Location
Database
UA
Registrar
REGISTER
(Sin Credenciales)
407
(Error)
Almacena
REGISTER
(Con Credenciales)
sip:[email protected]
REGISTER
200 OK
OK
170.210.68.247:5060
Servidor
Registrar
Escenario de Inicio de Sesión SIP
La invitación a realizar un inicio de sesión SIP comienza con el mensaje INVITE dirigido
comúnmente al Servidor Proxy. Éste responde con un mensaje TRYING (100) para evitar posibles
retransmisiones y reenvía las peticiones hacia el usuario llamado. Todas las respuestas provisionales
generadas por el usuario llamado son regresadas al usuario origen, por ejemplo RINGING (180). Una
respuesta 200 (Ok) es generada en cuanto el usuario llamado contesta.
- Página 13 -
SIP: ESCENARIO DE INVITACIÓN DE SESIÓN
UA 1
SIP Proxy
UA 2
INVITE
TRYING
INVITE
TRYING
RINGING
RINGING
OK
OK
ACK
RTP Stream
RTP Stream
Escenario de Finalización de Sesión SIP
Una sesión finaliza cuando uno de los usuarios envía el mensaje BYE al otro extremo. El otro
usuario confirma el final de la conversación enviando por respuesta un mensaje 200 (Ok). La
transacción para terminar la sesión se realizará de un extremo a otro sin pasar por el Proxy (sólo si no
existe un registro de ruta).
Registro de Ruta: Hay situaciones en las que el Proxy requiere estar presente en la ruta de todos los
mensajes con fines de control del tráfico, o por ejemplo, cuando existe un router NAT como veremos
más adelante. Esto se logra por medio de la inserción del campo RECORD ROUTE en los encabezados
de los mensajes SIP.
SIP: ESCENARIO DE TERMINACIÓN DE SESIÓN
SIN REGISTRO DE RUTAS
UA 1
SIP Proxy
CON REGISTRO DE RUTAS
UA 2 UA 1
BYE
SIP Proxy
UA 2
BYE
OK
BYE
OK
OK
- Página 14 -
CAPÍTULO 8
Problemática de NAT empleando SIP y RTP
El uso de NAT, ampliamente extendido en nuestras redes IPv4, acarrea numerosas
dificultades para las comunicaciones VoIP que emplean el protocolo de señalización de
llamadas SIP.
En un escenario simple como el representado por la figura siguiente cada teléfono IP
o UAC (User Agent Client) se encuentra conectado a RIU a través de un Router haciendo
NAT.
SIP: REGISTER,
INVITE,
UNREGISTER
SIP Proxy
ARIU
LAN
UNIVERSIDAD 2
RIU
ROUTER NAT
UNIVERSIDAD 2
SIP: REGISTER,
INVITE,
UNREGISTER
Teléfono IP
(Llamado)
SIP: REINVITE, BYE
Flujo RTP
¡IMPOSIBLE!
ROUTER NAT
UNIVERSIDAD 1
LAN
UNIVERSIDAD 1
Teléfono IP
(Llamante)
Supongamos entonces, que un cliente SIP detrás de NAT ubicado en una de las Universidades
Nacionales, trata de comunicarse con otro fuera de su NAT, ambos usuarios usan el mismo Proxy SIP
ubicado en el Data Center de ARIU.
Usuario SIP origen:
SIP URI: [email protected]
IP privada: 192.168.128.101
IP pública del router NAT: 170.210.68.100
- Página 15 -
Usuario SIP destino:
SIP URI: [email protected]
IP pública: 192.168.1.100
IP pública del router NAT: 170.210.69.100
Proxy SIP:
Dominio: riu.edu.ar
IP pública: 170.210.0.100
El mensaje SIP INVITE que enviaría el usuario origen será:
INVITE sip:[email protected] SIP/2.0
(*) Via: SIP/2.0/UDP 192.168.128.101:5060;rport;branch=z9hG4bKjyofoqmp
Max-Forwards: 70
To: <sip:[email protected]>
From: "UNVM" <sip:[email protected] >;tag=nrrrx
Call-ID: [email protected]
CSeq: 800 INVITE
(**)Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,PRACK,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE
Supported: replaces,norefersub,100rel
User-Agent: Grandstream/1.1
Content-Length: 312
v=0
o=841101 1090098764 894503441 IN IP4 192.168.128.101
s=(***)c=IN IP4 192.168.128.101
t=0 0
(****)m=audio 8000 RTP/AVP 98 97 8 0 3 101
a=rtpmap:98 speex/16000
a=rtpmap:97 speex/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=zrtp
En negrita se señalan los problemas ocasionados por estar detrás de NAT:
- Página 16 -
(*)La cabecera Via: SIP/2.0/UDP 192.168.128.101:5060 no supone problema pues
nuestro Proxy SIP añadirá su propio "Via" indicando al llamado por dónde debe rutear las
respuestas al mensaje INVITE.
(**)La cabecera Contact: <sip:[email protected]:5060> indicará al receptor
donde enviar los mensajes de nuevas transacciones, es decir, la dirección y puerto a la que el
receptor deberá enviar el BYE si quiere colgar, el INVITE si quiere hacer un re-INVITE (p.ej:
poner en espera), el REFER si quiere transferir la llamada. Todos estos mensajes
pertenecerían al mismo diálogo o comunicación SIP (diálogo = conjunto de transacciones
que comparten mismo "Caller-Id" y tags en "To" y "From"), pero serían nuevas transacciones
(transacción = mensaje SIP + respuestas) por lo que no se rutearían por la cabecera "Via".
Obviamente se trata de una IP privada no direccionable desde fuera de la red privada del
origen.
(***)La cabecera SDP c=IN IP4 192.168.128.101 indicará al receptor dónde enviar el
tráfico de audio RTP. Lo mismo, es una IP privada no direccionable.
(****)La cacebera SDP m=audio 8000 indicará al receptor a qué puerto enviar el
tráfico de audio RTP. Ese puerto es irrelevante en cuanto a que la IP es privada no
direccionable.
De acuerdo a los problemas expuestos anteriormente, la comunicación SIP y RTP se
ve imposibilitada.
A continuación se describe dicha problemática y sus posibles soluciones. Las mismas
pueden clasificarse en: soluciones NAT del lado del cliente y del lado del servidor.
Soluciones NAT del lado del cliente
En esta sección se comentan brevemente algunas soluciones para NAT que existen en
el lado del cliente, es decir, o bien en su dispositivo SIP o bien en su router/firewall NAT:
STUN (Simple Traversal of UDP through NAT)
Un dispositivo que usa STUN, antes de registrarse y/o hacer llamadas, se pone en
contacto con un servidor STUN que previamente se indicó en su configuración (ej:
stun.ekiga.net) y a través de él, se entera de si está detrás de NAT y qué tipo de NAT.
A continuación se verá con más detalle lo que ocurre:
Se inicia el dispositivo SIP. Este tiene configurado usar STUN contra un servidor STUN
predeterminado. En su configuración SIP y RTP tienen puertos asignados, supongamos SIP
5060 y RTP 8000. Inicia el test de STUN contra el servidor de STUN. Dicho test realiza una
serie de consultas:
Hola servidor STUN, ¿con qué IP y puerto me ves?
Entonces el dispositivo se entera de si está detrás de NAT. En caso afirmativo continúa el test
con la siguiente consulta:
- Página 17 -
Te envío un paquete desde mi puerto local 5060 y luego otro desde el 8000, ¿tú qué IP y
puertos mapeados en mi router NAT recibes?
Esto le permite al dispositivo conocer con qué IP y puertos saldría vía IP pública desde su
router NAT (hay que tener en cuenta que un router NAT puede manejar más de una IP
pública).
¿Y si hago la misma consulta pero a tu segunda IP pública? ¿ves la misma IP y puertos?
Esto es crucial y sirve para detectar el NAT simétrico, el único que impide el
funcionamiento de STUN. Si el servidor STUN ve la misma IP y puertos origen entonces el
dispositivo ya sabe qué IP pública y puertos debe indicar en sus mensajes SIP corrigiendo los
que aparecían en negrita.
Supongamos que el puerto SIP 5060 se mapea en el router NAT al 15060 y el RTP
8000 al 1800, entonces el dispositivo SIP indicaría esos valores en su mensaje INVITE en vez
de los indicados en negrita. Con esto sencillamente se consigue que nuestro dispositivo SIP
aparente tener IP pública.
SIP Proxy
Servidor STUN
SIP:
Register,
Invite,
Unregister
Inicio Test
STUN
SIP:
Register,
Invite,
Unregister
Inicio Test
STUN
LAN
UNIVERSIDAD 2
RIU
Teléfono IP
(Llamado)
ROUTER NAT
UNIVERSIDAD 2
ROUTER NAT
UNIVERSIDAD 1
LAN
UNIVERSIDAD 1
SIP:
Reinvite, Bye
Flujo RTP/UDP
Teléfono IP
(Llamante)
Aclaración: En realidad el test se parece poco a lo descripto anteriormente. Además de
tener en cuenta otras consideraciones como bloqueos de puertos y demás. Para verlo en
detalle referirse a RFC 3489 sección 10.2.
- Página 18 -
Limitaciones de STUN
STUN no funciona con NAT simétrico (bastante implementado en routers NAT típicos
ofrecidos por las operadoras para ADSL). Esto es debido a que este tipo de NAT no garantiza
que si se contacta con distintas IP's externas éstas lo vean con el mismo puerto público. Es
decir, el test de STUN no serviría puesto que no se sabe con qué puertos lo verá el destino
SIP.
STUN necesita mantener el keepalive de SIP para que el router NAT no cierre la
entrada de nuevos mensajes SIP transcurrido un cierto tiempo (por ejemplo: 20 segundos).
Esto no es problema puesto que el propio cliente podría enviar mensajes SIP periódicos al
destino (como un OPTIONS).
STUN sólo sirve para UDP y no para TCP. Esto es debido a la forma en la que un
router NAT detecta las conexiones establecidas para permitir nuevo tráfico entrante hacia la
LAN. En UDP se considera "misma comunicación" si anteriormente un paquete UDP ha salido
en sentido contrario hacia la IP y puerto público desde el que se reciben ahora nuevos
paquetes UDP. Pero en TCP (protocolo orientado a conexión) el router/firewall NAT sólo
considera una conexión TCP establecida si se ha seguido el protocolo para ello existente en
el propio TCP, es decir: SYN, SYN/ACK y ACK.
Flujo RTP a través de NAT con STUN
Supongamos dos dispositivos SIP ubicados detrás de routers haciendo NAT
registrados contra un servidor SIP con IP pública. Ambos usan STUN.
Para los mensajes SIP no existe inconveniente ya que la señalización SIP de la llamada
se realiza a través del servidor proxy SIP que posee IP Pública (dicho proxy SIP permanece en
el "callpath" añadiendo cabeceras "Record-Route") permitiendo la entrada de mensajes
manteniendo el keepalive. Es decir, podría funcionar tanto SIP sobre UDP como SIP sobre
TCP.
Para el caso de RTP ocurre algo difícil de explicar. Un usuario llama al otro y en el
establecimiento de llamada SIP ambos se indican entre sí sus IP públicas y puertos RTP
(averiguados con STUN). Supongamos que el llamante envía el tráfico RTP un poco antes que
el llamado. Esos primeros paquetes no atravesarán el router NAT del destino ya que este no
asocia el tráfico a ninguna "conexión" UDP existente. Pero luego de un tiempo, el destino
empieza a enviar tráfico RTP al puerto público del llamante. En ese momento el router del
llamado permitirá la entrada del tráfico UDP que al principio impedía.
Nota: STUN se considera solución del lado del cliente aunque en realidad requiere de un
servidor STUN en la red pública. Como dicho servidor no debe soportar demasiada carga y
además existen un gran número de ellos disponibles al público no se considera solución del
lado del servidor.
TURN (Traversal Using Relay NAT)
TURN se emplea para complementar los casos donde STUN no puede actuar (NAT
simétrico y TCP) pero con el gran costo añadido de requerir de un servidor TURN por donde
- Página 19 -
se enviará el tráfico. Es decir, un servidor STUN sólo interviene en la consulta inicial de los
clientes SIP, en cambio, un servidor TURN se emplea para enviar a través suyo el tráfico final.
Obviamente en términos de RTP el uso de TURN debe ser la última opción a considerar.
Además, puesto que el servidor TURN debe reunir requisitos de ancho de banda apropiados,
la opción de TURN debe considerarse como una solución del lado del cliente y del servidor.
ICE (Interactive Connectivity Establishment)
ICE no es en realidad un nuevo protocolo, sino una metodología que permite a los
clientes investigar qué solución de lado cliente (por ejemplo STUN ó TURN) es la más
adecuada según el escenario.
ALG (Application Layer Gateway)
AGL es un sistema implementado en el router/firewall que examina los paquetes SIP
que lo atraviesan y modifican las IP's y puertos para adecuarlos a su situación de NAT. Es,
digamos, una solución transparente para el cliente. No obstante, por implementarse en su
red local se considera solución de lado cliente.
Problemas con ALG
Al parecer muchas implementaciones ALG para SIP que vienen en los routers ADSL
son nefastas y reescriben los puertos con valores incorrectos (fuera del rango de 2^16), lo
que impide la transmisión del audio. Debido a este problema, en algunos routers es
necesario desactivar ALG de SIP vía telnet.
Redirección de puertos
La solución que nos queda por comentar sería la apertura y redirección de puertos
para SIP y RTP en el router hacia nuestro dispositivo SIP de la LAN. Obviamente esta solución
es completamente inaceptable si disponemos de un cierto número de dispositivos SIP
puesto que habría que poner un puerto SIP y RTP diferente en cada uno y hacer las
consiguientes redirecciones.
Soluciones NAT del lado del Servidor
En esta sección comento algunas soluciones para el NAT que existen en el lado del
servidor, lo que conlleva a la total transparencia desde el punto de vista del cliente. En este
caso será el servidor/proxy SIP el que tome medidas.
- Página 20 -
Proxy RTP
Un proxy RTP sirve como "pasarela" del tráfico RTP, de tal forma que el llamante y el
llamado envían su tráfico RTP a través de él. Dicho proxy RTP es manejado desde un servidor
SIP y debe disponer de IP pública para que sea accesible a los usuarios.
Supongamos que un usuario tras NAT llama a través de su proxy SIP a un usuario SIP
con IP pública:
Un usuario tras NAT y sin ninguna solución del lado del cliente hace una llamada a
través de su proxy SIP.
El proxy detecta que el INVITE proviene de una IP privada (mirando las cabeceras) así
que modifica las IP's y puertos del contacto SIP reemplazándolos por los valores de la IP y
puertos públicos del router.
Además reescribe la IP y puerto del SDP poniendo la IP del proxy RTP y un puerto que
en una consulta previa dicho proxy RTP le haya ofrecido.
Entonces se rutea el INVITE al destino, el cuál verá como punto de contacto SIP la IP
pública del NAT llamante y como contacto RTP la IP pública del proxy RTP.
Así pues la comunicación SIP pasa por el proxy SIP (como debe ser) mientras que el
tráfico de audio pasa por el proxy RTP que se encarga de puentear los flujos RTP de llamante
y llamado.
Obsérvese también, que si el proxy SIP ha añadido cabeceras "Record-Route" para
permanecer toda la llamada en el path, y como el proxy SIP ha puesto la IP pública NAT del
llamante en la cabecera "Contact" del INVITE que luego ha rutado al llamado, entonces si el
llamado cuelga la llamada enviará algo como:
BYE sip:[email protected]:15060 SIP/2.0
Así que el proxy SIP ruteará ese mensaje a la IP pública del llamante. Si esta cabecera
no se hubiese corregido entonces sería:
BYE sip:[email protected]:5060 SIP/2.0
Lo que provocaría que el proxy SIP no podría rutearla ya que intentaría rutearla a una
IP privada.
Otras consideraciones
También hay que tener en cuenta el caso en el que el llamado esté tras NAT. En ese
caso el proxy SIP debe detectarlo en la respuesta del llamado ("Trying", "Ringing", "OK"...).
Proxy's RTP disponibles
Las opciones más extendidas (al menos en el mundo del software libre) son RTP
Proxy y Media Proxy, ambos compatibles con OpenSer y con SER, los dos proxy SIP más
populares.
- Página 21 -
El caso de un usuario detrás de NAT y otro con IP Pública
Existe el falso mito de que "si un usuario está tras NAT (sin usar STUN u otras
soluciones NAT de lado de cliente) y otro con IP pública entonces no es necesario proxy RTP.
Esto es completamente falso salvo con una excepción que se verá luego.
Hace falta proxy RTP por la sencilla razón de que el usuario tras NAT no sabe porqué
puerto va a salir nateado su audio y tampoco tiene forma de saberlo su proxy SIP así que no
hay forma de que se lo pueda indicar al llamado (y da igual que el llamado tenga IP pública).
La excepción comentada en el párrafo anterior se da cuando el equipo que tiene IP
pública soporta lo que se conoce como "Comedia". Esta funcionalidad, soportada por
ejemplo por todos los gateways de Cisco, Sonus, etc, lo que hace es enviar el RTP a la IP y
puerto en los que él recibe RTP, independientemente de lo que diga el SDP. Así, el RTP
enviado por el gateway al usuario es aceptado por el router que haga NAT, incluso con NAT
simétrico.
- Página 22 -
CAPÍTULO 9
Arquitectura de Red VoIP propuesta para RIU
Diseño empleando único Servidor Proxy SIP y RTP
De acuerdo a lo expuesto en el capítulo 8, podríamos plantear para nuestra red como
solución al problema de SIP detrás de NAT el uso de un servidor proxy SIP en forma conjunta
con un servidor proxy RTP en el nodo central de RIU. De esta manera aseguraríamos no solo
una correcta señalización SIP sino también permitiríamos la llegada del flujo de audio vía RTP
en los dos sentidos.
Mensajes SIP
Flujo RTP
SIP Proxy
RTP Proxy
ARIU
LAN
UNIVERSIDAD 2
RIU
ROUTER NAT
UNIVERSIDAD 2
Mensajes SIP
Flujo RTP
Teléfono IP
(Llamado)
ROUTER NAT
UNIVERSIDAD 1
LAN
UNIVERSIDAD 1
Teléfono IP
(Llamante)
El esquema de la figura anterior, requiere de un adecuado dimensionamiento de
hardware en el servidor y ancho de banda de la red. Este hecho escapa de alguna manera a
uno de los principales objetivos del proyecto ya que se hace necesaria una mayor inversión.
Aún contando con el hardware y la infraestructura de red adecuada para
implementar el esquema anterior, el mismo presenta otra limitación: la necesidad de
requerir el registro de cada teléfono IP (UAC) en el servidor central de ARIU lo cual haría
prácticamente imposible su administración dado el volumen de los mismos.
- Página 23 -
Diseño empleando un Servidor Proxy SIP Central y varios Servidores B2BUA distribuidos
Las aplicaciones “back-end user” pueden actúar como punto intermedio (“middle
man”) para los mensajes SIP, para el audio vía RTP, o ambos a la vez. Cada UA entonces
dialogará con este punto intermedio (“middle man”) y nada conocerá del UA remoto. Los
servidores que corren este tipo de aplicaciones reciben el nombre de “B2BUA”. Teniendo en
cuenta esto, se plantea como arquitectura de nuestra red la existencia de un único servidor
proxy SIP ubicado en el nodo central o Data Center de RIU, el cual dispondrá en su
configuración de las rutas adecuadas basadas en prefijos predefinidos a los fines de poder
redireccionar la señalización SIP hacia los destinos que correspondan en las diferentes
UU.NN y por otro lado la existencia en cada Universidad Nacional interesada en participar
del proyecto de su propio servidor actuando como B2BUA. El nuevo esquema de red sería el
siguiente:
SIP: Register,
Invite, Unregister
SIP Proxy
SIP: Register,
Invite, Unregister
SIP: Reinvite,
Bye / Flujo RTP
LAN
UNIVERSIDAD 2
RIU
Teléfono IP
(Llamado)
B2BUA Server
SIP: Register,
Invite, Reinvite,
Bye, Unregister
/ Flujo RTP
B2BUA Server
LAN
UNIVERSIDAD 1
SIP: Register,
Invite, Reinvite,
Bye, Unregister
/ Flujo RTP
Teléfono IP
(Llamante)
En la figura anterior se puede apreciar claramente la separación de la comunicación
en tres estadios. El primero (marcado con negro) es inherente a cada Universidad y está
definido libremente de acuerdo a sus propias necesidades. El mismo consiste establecer la
comunicación entre un cliente (UAC) y su servidor B2BUA local. Tendrá también a su cargo la
autenticación y el registro de dicho cliente. Este mismo servidor será el encargado de
- Página 24 -
validarse en el proxy SIP de ARIU y encontrar la ruta adecuada que le permitirá llegar al
servidor destino de la comunicación en otra Universidad. (proceso marcado con negrita) Una
vez ubicado el servidor destino, se establece otra etapa en la comunicación hacia su propio
cliente, el cual es el verdadero destinatario de la llamada. Finalmente se puede ver que
existe una etapa intermedia de señalización SIP y flujo o streaming de audio RTP entre los
servidores locales de cada Universidad donde nada tienen que ver los clientes. Es decir, la
llamada se realiza por etapas:
Etapa 1: Cliente Origen – Servidor B2BUA Universidad Origen
Etapa 2: Servidor B2BUA Universidad Origen – Servidor B2BUA Universidad Destino
Etapa 3: Servidor B2BUA Universidad Destino – Cliente Destino
- Página 25 -
CAPÍTULO 10
Escenarios por Universidad según plataforma disponible
Servidores Locales: Etapa 1 y 3
Universidad con plataforma de VoIP Centralizada (PBX IP única)
El UAC que origina la llamada (User Agent Client) ubicado en la red interna de la
Universidad Origen, no accede directamente al UAC destino de la misma. Ni siquiera el SIP
Proxy de RIU accede directamente a los UACs. Por lo tanto el tráfico RTP no fluye entre estos
de manera directa evitando los numerosos problemas que genera el empleo de NAT en las
redes internas.
Si bien esta topología requiere que cada Universidad cuente con su propio servidor
B2BUA actuando como nexo entre los clientes de su red interna y el resto de las UU.NN, en
la mayoría de los casos la funcionalidad requerida se encuentra desplegada en la propia PBX
IP (Central Telefónica IP). En el caso que no exista se recomienda su implementación a través
de Asterisk o similar.
RIU
Servidor
Asterisk
LAN VoIP
Teléfono IP
SIP Proxy
ARIU
Teléfono IP
Teléfono IP
- Página 26 -
Universidad con plataforma VoIP descentralizada (más de una PBX IP)
Si las dimensiones de la red requieren el uso más de un PBX IP, sería recomendable el
uso de algún software específico tal como OpenSER en conjunto con Media Proxy o RTP
Proxy. También es posible centralizar el ruteo externo hacia RIU a través de uno de los PBXs.
SIP Proxy
ARIU
RIU
OpenSER + RTP Proxy
LAN VoIP
Asterisk 2
Asterisk 1
Teléfono IP
Teléfono IP
Teléfono IP
Universidad con plataforma VoIP con protocolos diferentes
Como ya se mencionó anteriormente la etapa 1 y 3 son de libre diseño para las
diferentes UU.NN. Lo cual permite el empleo de otros protocolos de comunicación de voz
sobre IP como pueden ser IAX2 (Inter-Asterisk eXchange Protocol) o SCCP (Skinny Client
Control Protocol) de Cisco. En tal caso será necesario reemplazar el B2BUA por un servidor
que realice las funciones de Trunking SIP entre la red interna y el Servidor Proxy SIP de ARIU.
En el caso de IAX2 esto puede realizarse directamente con Asterisk incorporando un trunk
SIP y definiendo las rutas adecuadas para su empleo. Para el caso de una solución Cisco, será
necesario definir esto de manera similar empleando Cisco Call Manager.
- Página 27 -
Es decir, se deja con total libertad de acción a cada Universidad para seguir
empleando la plataforma de voz sobre IP que posean o definir una nueva de acuerdo a sus
necesidades sin limitación impuesta por RIU.
TRUNK SIP
RIU
Servidor
Asterisk
(IAX2)
LAN VoIP
(IAX2)
Teléfono IP / IAX2
SIP Proxy
ARIU
Teléfono IP / IAX2
Teléfono IP / IAX2
Universidad sin plataforma de VoIP o con plataforma Híbrida
El siguiente caso contempla la utilización de una plataforma híbrida con una central
telefónica convencional a la cual se le añade un Gateway que puede consistir en n puertos
analógicos FXO o directamente una línea digital ISDN Pri o directamente una trama digital
E1. Esto permitirá, por ejemplo, vincular la central convencional con una central teléfonica IP
tipo Asterisk con extensiones IP asociadas (o no). De esta manera, y empleando como nexo
el servidor Asterisk, se podrá acceder al resto de la red de telefonía IP de las UU.NN.
empleando el servidor proxy SIP de ARIU.
Cabe aclarar que el Gateway que vincula las dos centrales puede consistir
directamente en una placa interna ubicada en el servidor Asterisk tipo Digium o similar.
- Página 28 -
PSTN
RIU
GATEWAY
FXOs
PBX
Tradicional
Servidor
Asterisk
LAN VoIP
Teléfono IP Teléfono IP
- Página 29 -
SIP Proxy
ARIU
CAPÍTULO 11
Definición de rutas y prefijos de marcado
Para una de las primeras etapas del proyecto se definió realizar un relevamiento de
las diferentes plataformas de Voip con las cuales contaban las UU.NN. a fin de adaptar de
común acuerdo algunos componentes de la Red a los fines de lograr el objetivo de
conectividad. Pero posteriormente, y debido a la dimensión de algunas instituciones, la
diversidad de tecnologías empleadas y el grado de descentralización de sus instalaciones se
plantea como pauta básica dejar completamente librado a la decisión de cada una la
conformación de su propia plataforma de voz sobre IP y solamente prestar el servicio básico
de ruteo de llamadas a quienes acepten participar de común acuerdo y registrar sus prefijos
y extensiones en la red.
El objetivo central del proyecto plantea resolver la necesidad básica de los usuarios
de acceder desde un terminal de telefonía ubicado en la Red VoIP de una Universidad
Nacional realizando la marcación del prefijo y el número de extensión correspondiente al
destinatario a través de un teclado convencional de 12 dígitos. Proyectos como SIP.edu
buscan unificar el acceso de un terminal telefónico empleando para ello la entidad correo
electrónico, pero esto implica de alguna manera facilitar su ingreso, y esto solo es posible, al
menos con fácil acceso, a través de terminales IP por software.
En un principio se pensó asignar a cada Universidad Nacional un prefijo basado en la
propia característica empleada por la telefonía fijo y móvil a nivel nacional pero esto además
de plantear algún grado de confusión, se hace difícil ya que existen instituciones
centralizadas y descentralizadas, ubicadas en diferentes regiones y otras comparten la zona
de influencia. Por lo tanto se pensó en asignar un prefijo independiente de otro sistema de
comunicación ya existente. Para su distribución se pudo emplear un carácter aleatorio pero
se prefirió asignar a cada institución un prefijo de 3 dígitos basado en el código
presupuestario empleado a nivel nacional por la Secretaría de Políticas Universitarias
perteneciente al Ministerio de Cultura y Educación. La lista de instituciones y sus prefijos es
la siguiente:
- Página 30 -
Prefijos de Marcado
N° Universidad Nacional
Orden
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
ARIU
BUENOS AIRES
CATAMARCA
CENTRO
COMAHUE
CORDOBA
CUYO
ENTRE RIOS
FORMOSA
GENERAL SAN MARTIN
GENERAL SARMIENTO
JUJUY
LA MATANZA
LA PAMPA
LA PATAGONIA SAN JUAN BOSCO
LA PLATA
LA RIOJA
LITORAL
LOMAS DE ZAMORA
LUJAN
MAR DEL PLATA
MISIONES
NORDESTE
QUILMES
RIO CUARTO
ROSARIO
SALTA
SAN JUAN
SAN LUIS
SANTIAGO DEL ESTERO
SUR
TECNOLOGICA
TUCUMAN
LA PATAGONIA AUSTRAL
LANUS
TRES DE FEBRERO
VILLA MARIA
INSTIT. UNIVERSITARIO DEL ARTE
CHILECITO
NOROESTE PCIA. BUENOS AIRES
RIO NEGRO
CHACO AUSTRAL
- Página 31 -
Prefijo
800
806
807
808
809
810
811
812
813
814
815
816
817
818
826
819
837
820
821
822
823
824
825
827
828
829
830
831
832
833
834
835
836
842
839
840
841
843
845
846
847
855
CAPÍTULO 12
Servidor Proxy: Definición del Software a utilizar
Introducción
En el marco del proyecto, se han estudiado las posibles soluciones de código abierto
basadas en SER (Sip Express Router). SER es una desarrollo con licencia GNU GPL. Se trata de
una aplicación que implementa un servidor proxy SIP. Su implantación es muy versátil,
permitiendo su instalación tanto en sistemas que posean recursos limitados como así
también en grandes servidores. Está escrito completamente en C y orientado principalmente
a equipos Linux/Unix. Esta aplicación tiene muchas características interesantes, entre las que
podemos destacar las siguientes:





Location Service
Registrar Server
Proxy Server
Redirect Server
Gateway hacia otras redes que no son SIP
Evolución y Desarrollo del Software
SER fue desarrollado inicialmente por el Instituto Fraunhofer en el año 2001. Parte
del equipo de desarrollo se desplazó, con los derechos del mismo, a una nueva compañía
denominada Iptel.org en el año 2004. Dos de los cinco desarrolladores del núcleo de SER
comenzaron a trabajar en un nuevo proyecto de software libre y abierto denominado
OpenSER. SER y OpenSER continuaron por caminos diferentes. El proyecto SER permaneció
siendo de código libre y abierto. En el año 2005 la compañía IPtel.org fue comprada por la
empresa TEKELEC..
OpenSER es un proyecto comenzado por varios de los colaboradores de la
implementación anterior (que permanecieron en el instituto Fraunhofer FOKUS) también
sujeto a licencia GNU GPL. La principal diferencia SER es el hecho de que OpenSER está
integrado por una comunidad de desarrollo en lugar de una empresa, lo que hace que
rápidamente se implementen mejoras.
Posteriormente, y por diferencia entre dos de sus principales desarrolladores el
proyecto OpenSER toma dos caminos diferentes. OpenSER fue renombrada como Kamailio
para evitar conflictos con marcas similares. Y a su vez, nace el proyecto OpenSIPS como un
fork de OpenSER/Kamailio.
- Página 32 -
En noviembre de 2008 los desarrolladores de OpenSER/Kamailio y SER se pusieron de
acuerdo y anunciaron la creación de un proyecto integrador denominado Sip-Router cuyo
objetivo entre otros es promover el trabajo colaborativo entre ambos para evitar esfuerzos
duplicados y fundamentalmente asegurar la credibilidad de los proyectos que en la
actualidad ha sido puesta en duda por el surgimiento de numerosos forks durante la corta
vida de ambos.
La elección: ¿SER, Kamailio u OpenSIPS?
Teniendo en cuenta la evolución que ha tenido el software antes descripto y luego de
un análisis de cada uno de los proyectos activos en cuanto a soporte, documentación en
línea y perspectivas futuras se optó para su implementación por el uso de OpenSER /
Kamailio.
Otro de los factores que influyó en la elección es la reciente creación del proyecto SIP
Router: un framework de tipo colaborativo entre SER y OpenSER cuyo objetivo principal es
aumentar la credibilidad del proyecto SER y promover la construcción de código abierto
sólido. También, los desarrolladores y comunidad de usuarios de ambos proyectos se
comprometen a trabajar mancomunadamente en el desarrollo de un núcleo flexible,
extensible y escalable evitando la duplicación de esfuerzos.
Todo ello, lleva a pensar que la elección de OpenSER / Kamailio es la correcta. De
cualquier manera, si hubiese necesidad de migrar hacia OpenSIPs, el cambio no
representaría un hecho traumático ya que entre ambos no existen en la actualidad
diferencias sustantivas.
- Página 33 -
CAPÍTULO 13
Arquitectura OpenSER / Kamailio
Núcleo y Módulos
OpenSER basa su funcionamiento en un núcleo que recibe y procesa mensajes SIP. La
mayor parte de su funcionalidad se brinda a través de módulos extra. Al poseer una
arquitectura modular, OpenSER posee un núcleo muy pequeño, rápido y estable. Las
funcionalidades de los módulos se emplean a través del archivo de configuración de
OpenSER (kamailio.cfg). Este archivo de configuración controla que módulos serán cargados
y define como se comportaran a través de las variables de módulo. Se puede pensar a este
archivo de configuración (kamailio.cfg) como el cerebro del SIP router.
Archivo de Configuración: Kamailio.cfg
Kamailio.cfg consta de siete secciones lógicas:
1. Sección de Definiciones Globales: Esta parte del archivo .cfg normalmente contiene el
IP y puerto donde el servicio se encuentra escuchando peticiones, el nivel de
depuración empleado (debug level), etc. Las definiciones de esta sección afectan
directamente al servicio (SER daemon).
2. Sección de Módulos: Esta sección contiene una lista de las librerías externas que se
necesesitan para brindar funcionalidad no provista por el núcleo. Estos módulos son
archivos de objetos compartidos “.so” y se cargan con la directiva “loadmodule”;
3. Sección de Configuración de Módulos: Muchas de las librerías especificadas en la
“Sección de Módulos” necesitan del seteo de algunos parámetros para su
funcionamiento. Estos parámetros se setean a través del comando “modparam” bajo
la siguiente forma: modparam (“nombre_modulo”, ”parámetro_modulo”,
valor_modulo).
4. Bloque Principal de Ruteo: Este bloque se asemeja a la función principal (main) de un
programa escrito en C. Este es el punto de entrada del procesamiento de un mensaje
SIP y controla como maneja cada mensaje recibido.(route[1])
5. Bloques Secundarios de Ruteo: Además del bloque principal de ruteo, el archivo .cfg
puede contener otros bloques adicionales de ruteo llamados desde el bloque
principal o desde otro bloque secundario. Un bloque secundario de ruteo es análogo
a una subrutina. (route[x])
- Página 34 -
6. Bloque de Ruteo de Respuesta: Se pueden utilizar bloques opcionales destinados a
manejar respuestas a mensajes SIP la mayoría de los cuales son mensajes “OK”.
(on_reply_route[x])
7. Bloques de Ruteo de Falla: Se pueden utilizar bloques opcionales cuando se necesita
procesar o manejar diferentes condiciones de falla como por ejemplo un mensaje
“BUSY” o un “timeout”. (failure_route*x+)
SIP: Transacciones, Diálogos y Sesiones
A fines de entender apropiadamente el funcionamiento del archivo de configuración
.cfg, se necesita comprender tres conceptos básicos:
 Transacción SIP: Esta compuesta por un mensaje SIP (y cualquier reenvío) y su
respuesta directa (y casi siempre inmediata). Por ejemplo: Un Agente de Usuario
(UA) envía un mensaje “REGISTER” a OpenSER y recibe de su parte un mensaje “OK”;
 Diálogo SIP: Se trata de una relación entre dos o más transacciones que existen por
un cierto tiempo. Por ejemplo: Se establece un diálogo entre un mensaje “INVITE”
finalizado por un “BYE”);
 Sesión: Se corresponde con el flujo o stream de audio de una conversación entre dos
teléfonos SIP.
Procesamiento del archivo de configuración .cfg
Se puede entender al archivo kamailio.cfg como un script que se ejecuta cada vez que
se recibe un mensaje SIP. Por ejemplo, un agente de usuario (UA) envía un mensaje INVITE a
otro UA para establecer una conversación. En este caso al recibir el mensaje INVITE,
OpenSER comienza a procesarlo a través de los comandos encontrados en el bloque de
ruteo principal (main route []).
Luego, el proceso continua hasta que se alcanza un punto en el cual se toma la
decisión acerca de donde enviar el INVITE (usando el comando t_relay()), devolver al origen
una respuesta con error (usando sl_send_reply()), o simplemente descartar el INVITE (ya sea
llegando al final de la ruta principal o por encontrarse con un comando break). Por supuesto,
esto último no se recomienda.
El destinatario responderá al INVITE con un mensaje OK. El mensaje OK es una
respuesta directa al mensaje inicial INVITE por lo tanto es controlado por la sección del
archivo de configuración denominada on_reply_route[x]. Si el destinatario no responde, o
responde con un error (busy, etc), se llama a la rutina failure_route[x].
Finalmente, si la respuesta sin existen error, el origen enviará un mensaje “ACK” para
indicar al destinatario que todo fue recibido y aceptado.
- Página 35 -
Cuando se emplea t_relay(), el comportamiento se manifiesta de acuerdo a lo
expuesto anteriormente, entonces se dice que OpenSER trabaja como “trasaction stateful
proxy”.
Cabe aclarar que un diálogo como el descripto en el ejemplo anterior incluye otras
respuestas intermedias antes del OK, pero las mismas no fueron contempladas por
simplificación.
Todos los mensajes que encabezan una nueva transacción SIP entran al tope de la
ruta principal (main route[]). En OpenSER existe una total libertad en la manera que se
procesan los mensajes SIP. A continuación se presentan algunos ejemplos de funciones:
 save(“location”): Se emplea para registrar cuando un usuario esta disponible o en
línea.
 lookup(“location”): Esta función retorna la dirección IP del usuario destino de la
llamada.
 setflag(x): Permite el almacenamiento de cierta información limitada acerca de
los usuaros en forma de banderas o flags.
Estándar RFC-3261
Dentro de la lógica empleada en el archivo de configuración .cfg se debe asegurar
que cada mensaje SIP sea correctamente manejado. Es decir que cada mensaje fluya de una
manera adecuada y en lo posible que cada respuesta a una transacción sea apropiadamente
tratada dando respuesta correcta o incorrecta a través de las rutas dedicadas a ello.
(on_reply_route y failure_route). Esto último puede llevarse acabo de diferentes maneras y
en ciertos casos puede convertirse en algo complejo. A veces, los cambios en el archivo de
configuración pueden afectar fácilmente más de un mensaje SIP fuera del objetivo inicial
planteado.
De acuerdo a lo anterior, es necesario aclarar que OpenSER es capaz de procesar
apropiadamente cualquier mensaje SIP cumpliendo el estándar RFC3261. Pero esto ya no
depende del propio SER sino de la lógica de procesamiento empleada en el archivo de
configuración correspondiente. Y Cualquier error introducido el mismo puede tener un
impacto importante en el router haciendo desviar su cumplimiento de dicho estándar.
Stateful vs Stateless
Suele ser difícil de comprender acabadamente el concepto de procesamiento stateful
versus stateless de un servidor proxy SIP. El descripción del punto anterior es un ejemplo de
procesamiento stateful. Esto significa que OpenSER conoce que el OK recibido pertenece al
mensaje INVITE inicial. Esto permite procesar las respuestas a través del bloque
onreply_route[]. procesamiento de tipo stateless (forwarding simple) cada mensaje de un
- Página 36 -
mismo diálogo es procesado de manera independiente fuera de todo contexto. Se emplea
“Stateless Forwarding”, por ejemplo, para un proceso simple de redistribución de carga.
A los fines de implementar funcionalidades avanzadas como: tarifado , renvío por
ocupado, correo de voz, y otras se necesitara emplear procesamiento stateful. Cada
transacción SIP permanecerá en memoria a los fines de que cada respuesta, falla o
retransmisión pueda ser reconocida. Cuando se emplea la función t_relay(), OpenSER
reconoce si un nuevo mensaje INVITE es un reenvío y actúa en consecuencia. Si se usa
procesamiento stateless, un reenvío de INVITE será tratado como si fuera el primero
recibido.
Hay que tener en cuenta el hecho de que OpenSER emplea procesamiento stateful
por cada una de las transacciones SIP que componen un diálogo y no por el diálogo en sí. La
consecuencia directa es que OpenSER no puede finalizar una llamada en curso ya que lo
desconoce. Por lo tanto no puede calcular la duración de la misma a los fines de realizar una
tarifación (accounting). Sin embargo, es posible almacenar cierta información sobre los
mensajes INVITE y BYE correspondientes a un mismo diálogo en forma conjunta con el
campo Caller-Id. De esta manera, otra aplicación destinada a realizar la tarifación, puede
encontrar la correspondencia entre los mensajes INVITE y BYE y calcular la duración de la
llamada.
Entendiendo SIP y RTP
SIP es un protocolo de señalización que permite manejar o controlar una llamada:
invitando a que la misma se realice (INVITE), cancelando durante el timbrado (CANCEL),
cortando una vez establecida (BYE), etc.
Los mensajes SIP pueden ser intercambiados directamente entre agentes de usuario
(UA), aunque a menudo se emplean SIP servers a los fines de ubicar los destinatarios.
Cuando un servidor SIP como OpenSER recibe un mensaje, puede decidir si permanece en el
medio del loop o no. Si no lo hace, OpenSER proveerá al UA la información necesaria para
contactar al otro UA y luego los mensajes SIP se intercambiaran directamente entre los dos
UAs.
Si OpenSER permanece en el loop, por ejemplo para asegurar que un mensaje BYE
sea recibido a los fines de tarifar la comunicación, OpenSER debe insertar un encabezado de
ruta (Route header) en el mensaje SIP usando la función record_route() para indicarle a los
demás que quiere participar. A los fines de que esto funcione, OpenSER y el resto de los
servidores SIP que intervienen deben realizar lo que se denomina “liberar la ruta” (“loose
routing”). Esto significa que los mensajes SIP no deben enviarse directamente al UA sino a
través de aquellos que pusieron un encabezado de ruta (route header) en el mensaje SIP.
Para chequear esto se emplea la función “loose_route()”.
- Página 37 -
Un mensaje SIP puede contener información adicional, por ejemplo relacionada
sobre como configurar una llamda con audio y video stream. (llamado SDP, Session
Description Protocol).
La información SDP resultará en uno o más sesiones RTP a ser configuradas,
normalmente entre los dos UA. OpenSER no participa de esto. RTP son por naturaleza de
procesamiento de ancho de banda intensivo. Sin embargo, como se describe después,
OpenSER puede asegurar que otra aplicación como un B2BUA (“Back to Back User Agent”) o
RTP Proxy puede convertirse en intermediarios. (“middle man”).
Finalmente, de Real-Time Control Protocol (RTCP) transmite información acerca de
los streams RTP entre UA. RTCP puede emplear el puerto RTP + 1 o un puerto indicado en el
propio mensaje SDP.
Aplicaciones Back-End
Está claro que OpenSER no mantiene información de estado sobre un diálogo SIP,
solo transfiere mensajes SIP (como parte de transacciones) entre dos agentes. La
consecuencia de esto es que OpenSER no puede ser un “peer” en el diálogo.
Si se necesita proveer capacidades de correo de voz o simplemente reproducir un
aviso indicando que el usuario no está disponible se necesitará algo que actúe de
intermediario como UA. Para ello existen módulos extra que proveen dicha funcionalidad
denominadas “back-end user applications”. Estas aplicaciones pueden actúar como “middle
man” para los mensajes SIP, para el audio va RTP, o ambos a la vez. Cada UA entonces
dialogará con este punto intermedio (“middle man”) y nada conocerá del UA remoto. Los
servidores que corren este tipo de aplicaciones reciben el nombre de “B2BUA”.
NAT, STUN y RTP Proxy
Ya se describió el problema que causa la presencia de agentes de usuario (UA) detrás
de dispositivos NAT que intentan comunicarse con otros agentes en Internet o detrás de
otros dispositivos NAT. Los dispositivos NAT pueden ser routers ADSL, firewalls, routers
Wireless, etc. A fin de entender el uso de proxies con NAT y RTP, se debe comprender que
ocurre cuando un agente de usuario se registra contra un Servidor Registrar y cuando se
inicia una llamada.
OpenSER ofrece dos formas diferentes de tratar NAT y RTP. Una es a través de una
aplicación denominada Rtpproxy y la otra es el uso Mediaproxy. Estas dos soluciones
funcionan de manera independiente una de otra.
El módulo “nathelper” se considera parte de la aplicación Rtpproxy, sin embargo es
posible emplear sus funciones con Mediaproxy.
- Página 38 -
URI, R-URI, y Ramas (Branches)
Para identificar un usuario de manera unívoca se emplea el identificador URI
(Uniform Resource Identifier). La denominación URI se emplea como una dirección del
contacto destino. La forma típica de un identificador SIP (URI) es la siguiente:
sip:[email protected]. El identificador URI original ubicado en la primera línea
de un mensaje SIP se llama request-URI (R-URI). Este URI es referenciado dentro del archivo
de configuración .cfg usando la expresión “uri”. Ejemplo: if (uri=~sip:username@.*)
Un URI puede ser manipulado a través del archivo de configuración a través de
diversas funciones desde diferentes módulos. Por ejemplo: lookup(“location”) tomará la
expresión uri modificada a lo largo del proceso, buscará en la base de datos “location” y
reescribirá el URI usando la información de contacto correcta (incluyendo @ipaddress:port).
Al ejectuarse t_relay() el mismo empleará como URI destino la forma final luego de las
transformaciones realizadas.
Algunas funciones, tales como lookup(“location”) pueden agregar ramas al conjunto
de URIs destino. Esto significa que cuando se ejecuta t_relay(), el mensaje INVITE se duplica
hacia todas las (potenciales) formas transformadas. El comando a nivel de núcleo
denominado “revert_uri()” reemplazara el actual URI destino con el valor original dado por
el campo “request-URI”.
- Página 39 -
CAPÍTULO 14
Virtualización y Despliegue
Software
A continuación se detalla el software instalado y el hardware puesto a disposición de
RIU de manera temporal en la primera etapa de prueba a los fines de llevar a cabo el
proyecto y comenzar con los primeros ensayos.
Software:
Sistema Operativo: Linux
Distribución: OpenSuse 11.0 de 64 bits
SIP Proxy: OpenSER / Kamailio versión 1.4
VPN Server: OpenVPN versión 2.0.9
Virtualización de Hardware
Se comenzó trabajando en un ambiente virtualizado a través de VMWARE versión. Se
configuró cada máquina virtual de la siguiente manera:
Procesador AMD Athlon Neo64 o Athlom II M300,
Memoria principal con 768Mb de capacidad,
HD de 8gb en interfaz virtual SCSI,
Red Ethernet, en modos bridge o NAT para las diferentes pruebas,
En cada una de estas máquinas virtuales se realizó la instalación de S.O. Linux
OpenSuse versión 11.0 de 64 bits, de acuerdo con la siguiente selección de paquetes:
SISTEMA BASE
Sistema base mejorado
Herramientas de consola
Administracion del sistema YAST
Entorno de tiempo de ejecucion de 32 bits
Paquetes de instalacon YAST
Gestion de software
FUNCIONES DE SERVIDOR
Administracion de RED
Servidor de Impresión
- Página 40 -
Servidor WEB y LAMP
Pasarela de internet
DESARROLLO
Desarrollo base
Desarrollo en C/C++
Entorno de creación RPM
Contando con esta plataforma de equipamiento y sistema operativo, instalado y en
funcionamiento, con acceso a internet, se procedió con la instalación de kamailio 1.4, a
partir de los repositorios de opensuse, donde se encuentran los repositorios del software
relacionado con telefonía ip. Este se puede encontrar en la siguiente dirección:
http://www.kamailio.org/mos/view/Download/.
Lla dirección específica del repositorio para el sistema operativo empleado es la siguiente:
http://download.opensuse.org/repositories/network:/telephony/openSUSE_11.0/network:telephon
y.repo
En este encontramos entre otros los siguientes paquetes que son de nuestro interés:
kamailio-1.4.0-9.16.x86_64.rpm
kamailio-bdb-1.4.0-9.16.x86_64.rpm
kamailio-cpl-1.4.0-9.16.x86_64.rpm
kamailio-dbtext-1.4.0-9.16.x86_64.rpm
kamailio-debuginfo-1.4.0-9.16.x86_64.rpm
kamailio-debugsource-1.4.0-9.16.x86_64.rpm
kamailio-jabber-1.4.0-9.16.x86_64.rpm
kamailio-mysql-1.4.0-9.16.x86_64.rpm
kamailio-odbc-1.4.0-9.16.x86_64.rpm
kamailio-perl-1.4.0-9.16.x86_64.rpm
kamailio-pgsql-1.4.0-9.16.x86_64.rpm
kamailio-radius-1.4.0-9.16.x86_64.rpm
La selección, e instalación de paquetes se realice median YAST, seleccionando los
que necesitemos instalar. Para nuestra configuración los paquetes relacionados, son los de la
configuración básica de kamailio, con el soporte para mysql. Incluimos la siguiente captura a
modo de ejemplo:
- Página 41 -
Completada la instalación procedemos a configurar kamailio, editando sus archivos
de configuración de acuerdo con lo visto en el Capitulo N° 14 de este mismo documento.
Una vez configurado procedemos a iniciar el servicio, en la máquina virtual:
Iniciando el servicio:
Comprobando su ejecución:
- Página 42 -
Utilizando el monitor de kamailio:
Sobre estas máquinas virtuales trabajamos además en la instalación de Elastix 1.6
basado en CentOS 5.3 y Asterisk 1.4.x. para contar con un entorno de trabajo similar a un
caso real de comunicaciones entre ARIU y las Universidades.
Se crearon extensiones telefónicas en cada servidor Elastix; se generaron los
troncales SIP correspondientes en cada Elastix para vincular las PBX con OpenSER / Kamailio
y en cada Proxy se dieron de alta las cuentas (“subscribers”) correspondientes a cada Elastix
a los fines de permitir el acceso al router. Se crearon las rutas de prueba correspondientes
para cada Elastix en Kamailio.
Vemos la web de administración de elastix, de la central correspondiente a ARIU:
- Página 43 -
En la siguiente captura observamos la lista de las extensiones creadas:
Del mismo modo observamos la web de administración de la central correspondiente a una
universidad:
- Página 44 -
Despliegue de Hardware
Por parte de la UNVM se ha provisto el siguiente hardware a modo de prueba:
Procesador: Intel Xeon 4 núcleos, 2,6 ghz
Memoria: 4 GB RAM
HD: SATA, 160GB, 7200 RPM
- Página 45 -
CAPÍTULO 15
Configuración de Kamailio
A continuación se analizará la configuración de OpenSER básica que asegura el
funcionamiento del servidor realizando las siguientes funciones:




Instalar un servidor Proxy SIP destinado al nodo central de RIU.
Permitir conectar los B2BUA de cada Universidad al servidor Proxy SIP
Autentificar los teléfonos B2BUA usando soporte de base de datos MySQL
Realizar llamadas entre teléfonos IP de cada Universidad en forma indirecta a través
de cada B2BUA registrados directamente al servidor ProxySIP
Definición de Parámetros Iniciales en el Servidor
Como primer paso se debe editar el archivo kamctlrc ubicado en:
/usr/local/etc/kamailio
El contenido es el siguiente:
# Nombre de dominio (IP del Servidor en nuestro caso):
SIP_DOMAIN={IP DEL SERVIDOR}
Para utilizar base de datos en MySQL se debe agregar lo siguiente:
# Motor del Servidor de la Base de Datos
DBENGINE=MYSQL
# Host del Servidor de la Base de Datos
DBHOST=localhost
# Nombre de la Base de Datos
DBNAME=openser
# Usuario de la Base de Datos (read/write user)
DBRWUSER=openser
# Password para la Base de datos (read/write user)
DBRWPW="openserrw"
## Usuario de Solo Lectura (read only user)
DBROUSER=openserro
## Password para read only user
DBROPW=openserro
## Super Usuario para Base de Datos
DBROOTUSER="root"
# Columna Nombre de Usuario
USERCOL="username"
## Modo de Funcionamiento del Motor (FIFO or UNIXSOCK)
CTLENGINE="FIFO"
- Página 46 -
Creación de Bases de Datos
En este paso se crean las Tablas de MySQL desde consola con los comandos:
kamdbctl create
MySQL password for root:
INFO: test server charset
INFO: creating database openser ...
INFO: Core OpenSER tables succesfully created.
Install presence related tables? (y/n): y
INFO: creating presence tables into openser ...
INFO: Presence tables succesfully created.
Install tables for imc cpl siptrace domainpolicy carrierroute? (y/n): y
INFO: creating extra tables into openser ...
INFO: Extra tables succesfully created.
Inicio del Servicio
Se inicializa Kamailio con el comando:
kamctl start
Para asegurar su funcionamiento se chequea el proceso correspondiente con:
#ps aux
Alta de Usuarios correspondientes a los B2BUA
Agregamos los usuarios ariu y unvm con el comando:
“kamctl add <nombre_usuario> <password>”:
kamctl add ariu openserariu
kamctl add unvm openserunvm
Archivo de configuración kamailio.cfg
A continuación se presenta el archivo de configuración “kamailio.cfg” utilizado en
este proyecto. El mismo puede presentar variaciones ya que durante las etapas de puesta en
marcha y despliegue final puede ser necesario introducir algunas modificaciones. El mismo
se encuentra descripto y comentado por secciones de acuerdo a la clasificación realizada en
el capítulo anterior:
La primera sección destinada a las definiciones globales tiene por objeto:
 Definir el nivel de registro de eventos para la depuración. En este caso
“debug=3” permite obtener suficiente información cuando ocurra algún error
sin sobrecargar el servidor.
- Página 47 -
 Con “log_stderror=no”, evitamos mostrar los eventos por pantalla ya que
corremos en modo servicio.
 Con “Fork=yes”, corremos la aplicación como servicio (en background).
 “Listen” y “port” permiten asignar una dirección IP y puerto en particular
donde el servicio se encuentra escuchando.
 Children especifica los procesos “hijos” correrán una vez iniciado el servidor.
 La variable “mpath” define la ubicación de los módulos.
 Las líneas “Dns=no ; Rev_DNS=no” previenen que OpenSER busque su propio
IP en el servidor DNS. Con esto se previenen posibles alertas al respecto.
 La variable “fifo” define la ubicación de la pila de mensajes SIP recibidos que
luego serán procesados por el servidor. Esta carpeta debe tener derechos de
escritura para el usuario que corre el servicio.
En el Anexo 2 puede verse en detalle el archivo de configuración correspondiente al
proyecto.
- Página 48 -
CAPÍTULO 16
Seguridad en la Red
Como es sabido, durante el proceso de señalización de la llamada, el protocolo SIP
emplea mensajes en texto plano y durante la transmisión de la voz en tiempo real (RTP), se
transmiten tramas UDP conteniendo el audio codificado bajo alguna técnica conocida (G711,
GSM, G729, etc) pero sin encriptación alguna. Atento a este hecho, y considerando que el
aseguramiento de dichos protocolos es posible mediante el uso de algunas
técnicas/protocolos específicos se consideró que la solución más adecuada en esta primera
etapa será el uso de Redes Privadas Virtuales, para lo cual se analizaron diferentes
alternativas y se decidió por implementar varias a los fines de que cada Universidad emplee
el acceso que mejor se adapte a sus necesidades.
Las tecnologías VPN disponibles básicamente emplean los siguientes protocolos:
PPTP, SSL e IPSec.
PPTP
Una VPN del tipo PPTP, funciona a través del establecimiento de una sesión PPP con
el destinatario a través del protocolo de ”tunneling” GRE. Otra conexión de red es necesaria
para iniciar y hacer la gestión de la sesión PPP, corriendo en el puerto 1723-TCP. Aquí sólo es
necesario indicar cuáles son los usuarios con acceso a conexiones VPN-PPTP, así como la
gama de direcciones que será usada por los clientes.
IPSec
La tecnología IPSec (IP security) es una suite de protocolos que garantiza la
confidencialidad, integridad y autenticidad en la transmisión de datos en redes IP. A
diferencia del protocolo SSL que opera al nivel de la capa de transporte, IPSec opera a nivel
de la capa de red garantizando de este modo una encriptación de datos a ese nivel. Para
configurar una conexión VPN entre dos redes, es necesario la configuración adecuada del
túnel IPSec en los equipos origen y destino.
SSL
Una VPN-SSL utiliza el protocolo de encriptación SSL para garantizar privacidad e
integridad de datos entre las dos partes, una vez que el protocolo permite autenticación y
encriptación de datos. SSL se basa en el protocolo TCP perteneciente a la capa de transporte
y utiliza el concepto de criptografía de clave pública. Este concepto especifica que cada una
- Página 49 -
de las partes posee una Clave Privada y una Clave Pública que puede ser distribuida por
quien pretende establecer comunicación cifrada. Los datos cifrados a través de Clave Pública
sólo pueden ser descifrados por la Clave Privada correspondiente.
Soluciones disponibles:
 PPTP Server bajo Linux
 IPSEC bajo Linux con Openswan
 OpenVPN.
Diagrama de red implementando modelo de seguridad a través de túnel VPN
PROXY SIP
+
SERVER VPN
ARIU
VP
N
PROXY SIP
+
CLIENTE VPN
Universidad
Nacional
1
RIU
PROXY SIP
+
CLIENTE VPN
PROXY SIP
+
CLIENTE VPN
Universidad
Nacional
2
- Página 50 -
Universidad
Nacional
3
CAPÍTULO 17
Conclusiones: Vinculación con otros proyectos
Otros Proyectos Similares
A los fines de enriquecer este proyecto, durante el período Julio-Septiembre de 2009
se han estudiado los lineamientos básicos de los proyectos SIP.edu y ClaraTel. Se encuentran
puntos en común en sus objetivos y en las conclusiones y trabajos realizados hasta el
momento. Se arribaron a las siguientes conclusiones:
Proyecto SIP.edu
El proyecto SIP.edu tiene como objetivo la convergencia las identidades de voz con
las identidades de correo electrónico, así como la promoción de los servicios de voz sobre IP
que emplean SIP como protocolo dentro del marco de las Universidades. Este proyecto
presenta un grado de avance significativo y se encuentra implementado totalmente en
numerosas Instituciones educativas a nivel mundial. De cualquier manera, el mismo no
resuelve algunos planteos realizados por el proyecto RIU como por ejemplo el acceso desde
un terminal telefónico fijo hacia otro dentro de la red.
Conociendo la dirección de e-mail (corporativa) de la persona a contactar, a través
del propio servidor de nombres de dominio (DNS) se localiza el servicio de traducción de
direcciones SIP que inmediatamente procede a localizar la extensión (user-agent) dentro de
una base de datos de e-mail y extensiones procediendo a enrutar la llamada al servidor
correspondiente donde se encuentra registrado el destinatario de la misma.
En una próxima etapa sería interesante incorporar la Red de Interconexión
Universitaria (RIU) al proyecto SIP.edu.
Red Clara
El proyecto de la red Clara, llevado a cabo por el Grupo de Trabajo en VoIp (ClaraTec)
tiene en sus objetivos mayores puntos en común con el proyecto RIU, los mismos se refieren
a: Elaborar un plano de integración entre las redes que ya operan un servicio de VoIP
dentro del ámbito de CLARA; Elaborar una recomendación de plataforma básica para el uso
de VoIP integrado con Clara y llevar a cabo capacitación para nivelación de conocimientos
en VoIP para preparar las NRENS a integrarse a la red VoIP. Este grupo de trabajo a realizado
avances en el estudio de alternativas de software libre disponibles pero aún no posee un
grado significativo de avance en cuanto a la implementación definitiva de alguna solución en
este aspecto.
Aprovechando que ARIU tiene sus representantes ante la Red Clara y más
específicamente en lo que respecta al grupo de trabajo en VoIP de ClaraTec sería interesante
establecer con ellos un mayor intercambio de experiencias a los fines realizar la
convergencia de alguno de nuestros proyectos.
- Página 51 -
Conclusiones
Debido a que SIP es un protocolo simple en su constitución, requiere menos código
en su implementación lo cual reduce los requerimientos de procesamiento y memoria de los
equipos involucrados sean menores. La conclusión es que con SIP es posible procesar más
llamadas para una determinada capacidad del sistema o emplear menor capacidad del
sistema para un determinado número de llamadas procesadas. Esto permite reducir costos
en cuanto al desarrollo de aplicaciones de usuario y también de los equipos a emplear por
parte de los operadores de servicios de VoIP. Además, SIP contempla funciones diseñadas
específicamente para su ampliación permitiendo realizarlo de manera más simple que con
otros protocolos.
Se concluye a través de este proyecto que SIP surge en principio como un protocolo
sencillo a la hora de su definición pero complicado desde el punto de vista del despliegue de
una red de voz sobre Ip con todas sus funcionalidades para lo cual es necesario tener en
cuenta numerosos aspectos. Es por ello que se considera que este documento puede servir,
al margen del proyecto en sí, como una guía ante numerosos cuestiones a ser tenidas en
cuenta en futuros proyectos o ampliaciones del mismo.
A los fines de cumplir con los objetivos, se definió la arquitectura de red más
adecuada en función de minimizar el impacto de costos en recursos económicos y humanos
destinados a ponerlo en marcha; en el capítulo 9 se menciona este hecho.
También fueron relevantes otros aspectos como la elección del software a utilizar. En
todo momento se buscó una solución abierta y escalable. Una solución derivada de SER (Sip
Express Router) pareció ser lo más acertado en este sentido.
- Página 52 -
Anexo I: Archivo de Configuración “kamailio.cfg”
#######################################
####### Definiciones Globales #########
#######################################
debug=3
log_stderror=no
fork=yes
children=4
listen=10.8.0.100
port=5060
dns=no
rev_dns=no
fifo=”/tmp/ser_fifo”
fifo_db_url=”mysql://ser:heslo@localhost/ser”
mpath="/usr/lib/openser/modules/"
########################
####### Módulos ########
########################
loadmodule
loadmodule
loadmodule
loadmodule
loadmodule
loadmodule
loadmodule
"mysql.so"
"sl.so"
"tm.so"
"rr.so"
"maxfwd.so"
"usrloc.so"
"registrar.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "uri_db.so"
#########################################
####### Configuración de Módulos ########
#########################################
# ----- usrloc params ----modparam("usrloc", "db_mode",
2)
modparam("usrloc|uri_db|auth_db","db_url","mysql://root:@localhost/openser")
# ----- auth params ----modparam("auth_db","calculate_ha1",0)
modparam("auth_db","password_column","ha1")
modparam("auth_db","password_column_2","ha1b")
modparam("auth_db","user_column","username")
modparam("auth_db","domain_column","domain")
# ----- rr params ----modparam("rr", "enable_full_lr", 1)
##########################################
####### Bloque Principal de Ruteo ########
##########################################
route {
# ----------------------------------------------------------------# Chequeo de Seguridad contra Malformación de mensajes SIP
# -----------------------------------------------------------------
- Página 53 -
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483", "Too Many Hops");
return;
};
if (msg:len > max_len) {
sl_send_reply("513", "Message Overflow");
return;
};
# ----------------------------------------------------------------# Registro de Ruta (Record Route)
# ----------------------------------------------------------------if (method!="REGISTER") {
record_route();
};
# ----------------------------------------------------------------# Liberación de Ruta
# ----------------------------------------------------------------if (loose_route()) {
route(1);
return;
};
# ----------------------------------------------------------------# Sección de Procesamiento de Llamada
# ----------------------------------------------------------------if (uri!=myself) {
exit;
};
if (method=="REGISTER") {
route(2);
return;
};
if (method=="INVITE") {
route(3);
return;
}
route(4);
route(1);
return;
}
###########################################
####### Bloque Secundario de Ruteo ########
###########################################
# ----------------------------------------------------------------# Ruta por Defecto
# ----------------------------------------------------------------route[1]
{
if (!t_relay()) {
sl_reply_error();
}
}
# ----------------------------------------------------------------# Procesamiento de mensaje REGISTER
# ----------------------------------------------------------------
- Página 54 -
route[2]
{
sl_send_reply("100", "Trying");
if (!www_authorize("","subscriber")) {
www_challenge("","0");
return;
};
if (!check_to()) {
sl_send_reply("401", "Unauthorized");
return;
};
consume_credentials();
if (!save("location")) {
sl_reply_error();
};
}
# ----------------------------------------------------------------# Procesamiento de Mensaje INVITE
# ----------------------------------------------------------------route[3] {
if (!proxy_authorize("","subscriber")) {
proxy_challenge("","0");
return;
} else if (!check_from()) {
sl_send_reply("403", "Use From=ID");
return;
};
consume_credentials();
route(4);
route(1);
return;
}
###########################################################
# Define Rutas con Prefijos de Acuerdo a Cada Universidad #
###########################################################
Route[4]
{
if (uri=~”sip:800[0-9]{3}.+@*”)
{
Strip(3);
rewritehostport(“IP_B2BUA_ARIU:5060”);
}
if (uri=~”sip:841[0-9]{4}@*”)
{
Strip(3);
rewritehostport (“IP_B2BUA_UNVM:5060”);
}
# Modificar para UUNN en particular
if (uri=~”sip:8XX[0-9].+@*”)
{
Strip(3);
rewritehostport(“IP_B2BUA_UUNN_X:5060”);
}
}
- Página 55 -
Anexo II
Instalación de Open VPN
A continuación se describen los pasos seguidos para la instalación de un servidor
OpenVPN y sus clientes asociados. En nuestro caso utilizaremos el mismo hardware
destinado a ser empleado como SIP Proxy.
1) Instalación de librerías de compresión de datos lzo.
Para ello, desde consola se ingresa:
cd /usr/src
Se descarga el siguiente archivo fuente:
wget http://www.oberhumer.com/opensource/lzo/download/lzo-2.03.tar.gz
Se descomprime:
tar -xf lzo-2.03.tar.gz
cd lzo-2.03
Se compila e instala:
./configure
make
make check
make install
2) Instalación de OpenVPN
Se descarga el siguiente archivo fuente:
cd ..
wget http://www.openvpn.net/release/openvpn-2.0.9.tar.gz
Se descomprime:
tar -xf openvpn-2.0.9.tar.gz
cd openvpn-2.0.9
Se compila e instala:
./configure
make
make install
Se crea el siguiente directorio donde se almacenaran los archivos de configuración:
mkdir /etc/openvpn
- Página 56 -
3) Definición de datos generales para la generación de claves en el Servidor
cd easy-rsa/
mkdir /usr/local/sbin/keys
nano vars
export KEY_DIR=/usr/local/sbin/keys
export KEY_COUNTRY=AR
export KEY_PROVINCE=Ciudad Autónoma de Buenos Aires
export KEY_CITY=Buenos Aires
export KEY_ORG="ARIU"
export [email protected]
Ctrl-O Ctrl-X
4) Generación de archivo de parámetros Diffie Hellman (dh1024.pem)
cd easy-rsa
./build-dh
5) Creación de la Autoridad Certificante (Certificate Authority)
Para inicializar el proceso se ingresa:
. ./vars
NOTE: when you run ./clean-all, I will be doing a rm -rf on /usr/local/sbin/openvpn/keys
./clean-all
A continuación se genera el certificado y la clave (ca.crt y ca.key)
./build-ca
Generating a 1024 bit RSA private key
....++++++
...................++++++
writing new private key to 'ca.key'
----You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
----Country Name (2 letter code) [AR]:
State or Province Name (full name) [Ciudad Autónoma de Buenos Aires]:
Locality Name (eg, city) [Buenos Aires]:
Organization Name (eg, company) [ARIU]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:ARIU_SERVER
Email Address [[email protected]]:
6) Creación de clave para el servidor (ARIU_SERVER.key)
./build-key-server ARIU_SERVER
..++++++
................................++++++
writing new private key to 'ARIU_SERVER.key'
-----
- Página 57 -
Country Name (2 letter code) [AR]:
State or Province Name (full name) [Ciudad Autónoma de Buenos Aires]:
Locality Name (eg, city) [Buenos Aires]:
Organization Name (eg, company) [ARIU]:
Common Name (eg, your name or your server's hostname) []:ARIU_SERVER
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /usr/src/openvpn-2.0.9/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName
:PRINTABLE:'AR'
stateOrProvinceName
:PRINTABLE:'Ciudad Autónoma de Buenos Aires'
localityName
:T61STRING:'Buenos Aires'
organizationName
:PRINTABLE:'ARIU'
commonName
:PRINTABLE:'ARIU_SERVER'
emailAddress:IA5STRING:'[email protected]'
Certificate is to be certified until Dec 1 11:47:48 2018 GMT (3650 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
7) Creación de archivo de configuración en el servidor (ARIU_SERVER.conf)
cd /etc/openvpn
nano ARIU_SERVER.conf
port 1194
proto udp
dev tun
ca /usr/local/sbin/keys/ca.crt
cert /usr/local/sbin/keys/server.crt
key /usr/local/sbin/keys/server.key
dh /usr/local/sbin/keys/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
max-clients 30
persist-key
persist-tun
log openvpn.log
log-append openvpn.log
verb 3
management localhost 7505
client-to-client
8) Arranque automático del servicio OpenVPN
Script de inicio:
cd /usr/src/openvpn-2.0.9/sample-scripts/
cp openvpn.init /etc/rc.d/init.d/openvpn
chkconfig --add openvpn
chkconfig openvpn on
Por último:
/etc/init.d/openvpn start
- Página 58 -
Si no existen errores, con ifconfig podemos ver la nueva red funcionando:
tun0
Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:73 errors:0 dropped:0 overruns:0 frame:0
TX packets:96 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:24242 (23.6 KiB) TX bytes:41235 (40.2 KiB)
Instalación del servicio Open VPN en un cliente:
Se deberán seguir los pasos descriptos anteriormente para el caso del servidor
OpenVPN obviando los pasos 3 al 5. El paso número 6 se deberá cambiar por el siguiente:
6) Creación de claves para los clientes (UNXX_CLIENT.key)
Esto deber ejecutado en el mismo equipo y directorio donde se crearon las claves
para el servidor (/usr/local/sbin/keys). Además siempre recordar inicializar las variables de
entorno a través del scrip:
. ./vars
Luego:
./build-key UNVM_CLIENT
...++++++
...............++++++
writing new private key to 'UNVM_CLIENT.key'
----Country Name (2 letter code) [AR]:
State or Province Name (full name) [CORDOBA]:
Locality Name (eg, city) [VILLA MARIA]:
Organization Name (eg, company) [UNVM]:
Common Name (eg, your name or your server's hostname) []:UNVM_CLIENT
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /usr/src/openvpn-2.0.9/easy-rsa/openssl.cnf
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName
:PRINTABLE:'AR'
stateOrProvinceName
:PRINTABLE:'CORDOBA'
localityName
:T61STRING:'VILLA MARIA'
organizationName
:PRINTABLE:'UNVM'
commonName
:PRINTABLE:'UNVM_CLIENT'
emailAddress
:IA5STRING:'[email protected]'
Certificate is to be certified until Dec 1 11:49:15 2018 GMT (3650 days)
Sign the certificate? [y/n]:y
- Página 59 -
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Y el paso número 7 se reemplaza por el siguiente:
7) Creación del archivo de configuración (ARIU.conf)
Este archivo debe ser creado en: /etc/openvpn
cd /etc/openvpn
nano ARIU.conf
client
dev tun
proto udp
remote {IP_SERVER_OPENVPN} 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert unvm_client.crt
key unvm_client.key
ns-cert-type server
comp-lzo
verb 3
Certificado y Clave
Copiar los siguientes archivos en el directorio /etc/openvpn
ca.crt
UNVM_CLIENT. crt
UNVM_CLIENT.key
Firewall:
El servidor OpenVPN usa como puerto predefinido 1194, por lo tanto será necesario tenerlo
en cuenta a la hora de usar iptables:
Ingresar:
nano /etc/sysconfig/iptables
Añadir:
# OPENVPN server port
-A INPUT -p tcp --dport 1194 -j ACCEPT
-A INPUT -p udp --dport 1194 -j ACCEPT
Reiniciar iptables:
service iptables restart
- Página 60 -
REFERENCIAS
Referencia sobre otros Proyectos:
Expediente Nº 6925/2008 - “Proyecto Telefonía IP”
Universidad Nacional de Villa María
http://www.internet2.edu/sip.edu
http://mit.edu/sip/sip.edu/deployments.shtml
http://www.freenum.org/
http://voztovoice.org/?q=node/103
http://www.voip-info.org
Referencia sobre Software:
http://www.iptel.org/
http://www.kamailio.org/
http://www.opensips.org/
http://sip-router.org/
http://openvpn.se/files/install_packages/openvpn-2.0.9-gui-1.0.3-install.exe
http://technorati.com/tags/OpenVPN
Referencia sobre Protocolo SIP:
RFC3261 - SIP: Session Initiation Protocol
RFC3263 - Session Initiation Protocol (SIP): Locating SIP Servers
RFC2617 - HTTP Authentication: Basic and Digest Access Authentication
Referencia sobre problemática de SIP y NAT:
http://blog.aliax.net/2007/08/aclarando-sip-y-nat.html
Autor del Blog: Iñaki Baz Castillo (Terrassa, Barcelona, España)
Sector de la VoIP con OpenSer, Asterisk, Linux Debian y software libre.
Referencias de ICE
http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-00.html
Interactive Connectivity Establishment (ICE): A Methodology for NAT Traversal for SIP
Referencias de TURN
http://www.jdrosen.net/papers/draft-rosenberg-sipping-ice-00.html
Traversal Using Relay NAT (TURN) - draft-rosenberg-midcom-turn-07
- Página 61 -
Internet Drafts
Autor: J. Rosenberg
Referencias de ALG
http://tools.ietf.org/html/rfc2663
RFC2663: IP Network Address Translator (NAT) Terminology and Considerations
http://sitsotd.org/
Sitsotd: Solución SIP para Iptables
Referencias de STUN
RFC 3489: STUN - Simple Traversal of User Datagram Protocol (UDP)
http://tools.ietf.org/html/rfc3489
- Página 62 -

Anteproyecto Beca LACNIC XII - Dirección General de Informática

Transcripción

Documentos relacionados

Descargar - Ministerio de Defensa

71a Asamblea General Inter American Press Association Sociedad