Anteproyecto Beca LACNIC XII - Dirección General de Informática
Transcripción
Anteproyecto Beca LACNIC XII - Dirección General de Informática
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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María (*)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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María PSTN RIU GATEWAY FXOs PBX Tradicional Servidor Asterisk LAN VoIP Teléfono IP Teléfono IP - Página 29 - SIP Proxy ARIU Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 Generating a 1024 bit RSA private key ..++++++ ................................++++++ writing new private key to 'ARIU_SERVER.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. ----- - Página 57 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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]]: 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 Generating a 1024 bit RSA private key ...++++++ ...............++++++ writing new private key to 'UNVM_CLIENT.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) [CORDOBA]: Locality Name (eg, city) [VILLA MARIA]: Organization Name (eg, company) [UNVM]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:UNVM_CLIENT Email Address [[email protected]]: 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 - Ing. Mariano Javier Martín – Universidad Nacional de Villa María 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 -