PROYECTO CONVOCATORIA A BECAS PARA PARTICIPACIÓN EN EVENTO LACNIC XII. Denominación: Ing. Mariano Javier MARTIN Universidad Nacional de Villa María

Save this PDF as:
 WORD  PNG  TXT  JPG

Tamaño: px
Comenzar la demostración a partir de la página:

Download "PROYECTO CONVOCATORIA A BECAS PARA PARTICIPACIÓN EN EVENTO LACNIC XII. Denominación: Ing. Mariano Javier MARTIN Universidad Nacional de Villa María"

Transcripción

1 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 Página 1 -

2 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 Página 2 -

3 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 -

4 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 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 -

5 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 -

6 SDP codificados como texto plano (ISO UTF-8) cuyos nombres de campo y atributos usan US- ASCII pero los demás emplean 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 -

7 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) UAC INVITE UA (B) UAS UAS BYE UAC - Página 7 -

8 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: Alcanzable en: Location Database UA REGISTER (Sin Credenciales) Registrar 407 (Error) Almacena REGISTER REGISTER (Con Credenciales) :5060 OK 200 OK 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 302: Moved Temporarily Servidor Redirect USUARIO A INVITE #2 USUARIO B - Página 8 -

9 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 Proxy A Proxy B INVITE Usuario A BYE Usuario B - Página 9 -

10 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 -

11 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 -

12 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 -

13 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: Alcanzable en: Location Database UA REGISTER (Sin Credenciales) Registrar 407 (Error) Almacena REGISTER REGISTER (Con Credenciales) :5060 OK 200 OK 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 -

14 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 CON REGISTRO DE RUTAS UA 1 SIP Proxy UA 2 BYE UA 1 SIP Proxy UA 2 BYE OK BYE OK OK - Página 14 -

15 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 Proxy ARIU SIP: REGISTER, INVITE, UNREGISTER RIU LAN UNIVERSIDAD 2 SIP: REGISTER, INVITE, UNREGISTER ROUTER NAT UNIVERSIDAD 2 Teléfono IP (Llamado) ROUTER NAT UNIVERSIDAD 1 SIP: REINVITE, BYE Flujo RTP IMPOSIBLE! 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: IP privada: IP pública del router NAT: Página 15 -

16 Usuario SIP destino: SIP URI: IP pública: IP pública del router NAT: Proxy SIP: Dominio: riu.edu.ar IP pública: El mensaje SIP INVITE que enviaría el usuario origen será: Ing. Mariano Javier Martín Universidad Nacional de Villa María INVITE SIP/2.0 (*) Via: SIP/2.0/UDP :5060;rport;branch=z9hG4bKjyofoqmp Max-Forwards: 70 To: From: "UNVM" >;tag=nrrrx Call-ID: CSeq: 800 INVITE (**)Contact: 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= IN IP s=- (***)c=in IP t=0 0 (****)m=audio 8000 RTP/AVP 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: a=ptime:20 a=zrtp En negrita se señalan los problemas ocasionados por estar detrás de NAT: - Página 16 -

17 (*)La cabecera Via: SIP/2.0/UDP :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: 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 IP 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 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 -

18 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 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 Inicio Test STUN SIP: Register, Invite, Unregister RIU ROUTER NAT UNIVERSIDAD 2 LAN UNIVERSIDAD 2 Teléfono IP (Llamado) 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 Página 18 -

19 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 -

20 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 -

21 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/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/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 -

22 El caso de un usuario detrás de NAT y otro con IP Pública Ing. Mariano Javier Martín Universidad Nacional de Villa María 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 -

23 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. SIP Proxy RTP Proxy ARIU RIU Mensajes SIP Flujo RTP LAN UNIVERSIDAD 2 Mensajes SIP Flujo RTP ROUTER NAT UNIVERSIDAD 2 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 -

24 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 RIU SIP: Reinvite, Bye / Flujo RTP LAN UNIVERSIDAD 2 B2BUA Server Teléfono IP (Llamado) B2BUA Server LAN UNIVERSIDAD 1 SIP: Register, Invite, Reinvite, Bye, Unregister / Flujo RTP 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 -

25 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 -

26 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 SIP Proxy ARIU Teléfono IP Teléfono IP Teléfono IP - Página 26 -

27 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 1 Asterisk 2 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 -

28 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) SIP Proxy ARIU Teléfono IP / IAX2 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 -

29 PSTN RIU GATEWAY FXOs Servidor Asterisk PBX Tradicional LAN VoIP SIP Proxy ARIU Teléfono IP Teléfono IP - Página 29 -

30 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 -

31 N Orden Prefijos de Marcado Universidad Nacional Prefijo 0 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 -

32 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 Parte del equipo de desarrollo se desplazó, con los derechos del mismo, a una nueva compañía denominada Iptel.org en el año 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 -

33 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 -

34 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 -

35 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 -

36 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 -

37 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 -

38 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 -

39 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: 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 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 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 -

40 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 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 -

41 Servidor WEB y LAMP Pasarela de internet DESARROLLO Desarrollo base Desarrollo en C/C++ Entorno de creación RPM Ing. Mariano Javier Martín Universidad Nacional de Villa María 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: Lla dirección específica del repositorio para el sistema operativo empleado es la siguiente: y.repo En este encontramos entre otros los siguientes paquetes que son de nuestro interés: kamailio x86_64.rpm kamailio-bdb x86_64.rpm kamailio-cpl x86_64.rpm kamailio-dbtext x86_64.rpm kamailio-debuginfo x86_64.rpm kamailio-debugsource x86_64.rpm kamailio-jabber x86_64.rpm kamailio-mysql x86_64.rpm kamailio-odbc x86_64.rpm kamailio-perl x86_64.rpm kamailio-pgsql x86_64.rpm kamailio-radius 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 -

42 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 -

43 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 -

44 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 -

45 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 -

Aplicaciones sobre una red de telefonía IP. Presentado por: Tamara Ramírez Andrade Jaime Díaz Rojas

Aplicaciones sobre una red de telefonía IP. Presentado por: Tamara Ramírez Andrade Jaime Díaz Rojas Aplicaciones sobre una red de telefonía IP Presentado por: Tamara Ramírez Andrade Jaime Díaz Rojas Que es la telefonía IP? La telefonía IP es una tecnología que permite que las señales de voz viajen a

Más detalles

Red de Telefonía IP en Universidades Públicas de Argentina Introducción

Red de Telefonía IP en Universidades Públicas de Argentina Introducción Introducción RED DE INTERCONEXIÓN UNIVERSITARIA Grupo de Trabajo en Voz sobre IP UNIVERSIDAD NACIONAL DE VILLA MARIA (Arg) Ing. Mariano Javier MARTÍN (marianojm@gmail.com) UNIVERSIDAD NACIONAL DE SAN LUIS

Más detalles

ATEL ASESORES C.A IP Multimedia Subsystem Prof. Diógenes Marcano

ATEL ASESORES C.A IP Multimedia Subsystem Prof. Diógenes Marcano SIP Capítulo 3 Pág. 1 SIP es un protocolo para señalización definido por el IETF según el RFC3261. SIP permite establecer, liberar y modificar sesiones multimedia y está basado en un modelo de transacciones

Más detalles

Universidad Católica de El Salvador Miembro RAICES

Universidad Católica de El Salvador Miembro RAICES Universidad Católica de El Salvador Miembro RAICES LABORATORIO DE VOZ SOBRE IP (VoIP) Y SU IMPLEMENTACIÓN EN LAS REDES AVANZADAS UTILIZANDO CÓDIGO ABIERTO. Junio de 2011 Financiamiento Proyecto autorizado

Más detalles

Servicio de tecnología de voz IP VoIP. - Telefonía tradicional - Funcionamiento de VoIP - Protocolos VoIP - Elementos VoIP

Servicio de tecnología de voz IP VoIP. - Telefonía tradicional - Funcionamiento de VoIP - Protocolos VoIP - Elementos VoIP Servicio de tecnología de voz IP VoIP - Telefonía tradicional - Funcionamiento de VoIP - Protocolos VoIP - Elementos VoIP Servicio de tecnología de voz IP Voz sobre Protocolo de Internet, también llamado

Más detalles

GUIA DE CONFIGURACIÓN TRONCAL SIP RIU para ASTERISK

GUIA DE CONFIGURACIÓN TRONCAL SIP RIU para ASTERISK GUIA DE CONFIGURACIÓN TRONCAL SIP RIU para ASTERISK Información requerida Esta guia, sirve para configurar un troncal SIP con el Proxy SIP perteneciente a RIU, actualmente hosteado en la Universidad Nacional

Más detalles

ELEMENTOS DE UNA RED VoIP. Page 1

ELEMENTOS DE UNA RED VoIP. Page 1 ELEMENTOS DE UNA RED VoIP Page 1 Page 2 Protocolo H.323 Es una especificación de la ITU-T para transmitir audio, video y datos a través de una red IP (incluida la propia Internet) sin garantizar QoS. H.323

Más detalles

VoIP. Voice Over IP. Gerard Sales Mariano Gracia Julian H. Del Olmo Jose M. Vila

VoIP. Voice Over IP. Gerard Sales Mariano Gracia Julian H. Del Olmo Jose M. Vila VoIP Voice Over IP Gerard Sales Mariano Gracia Julian H. Del Olmo Jose M. Vila Índice 1! Definición VoIP.! Idea Básica.! Ventajas.! Inconvenientes.! Aplicaciones. Índice 2! Estándares. H.323. SIP. H.248/Megaco.!

Más detalles

SIP. Capacidades de SIP. Integración con Protocolos IETF. Que es SIP? Session Initiation Protocol

SIP. Capacidades de SIP. Integración con Protocolos IETF. Que es SIP? Session Initiation Protocol Capacidades de SIP SIP Session Initiation Protocol Ing. Agustín Eijo Universidad Tecnológica Nacional Facultad Regional La Plata SIP soporta cinco facetas en el establecimiento y

Más detalles

Protocolos de Voz sobre IP (continuación)

Protocolos de Voz sobre IP (continuación) Protocolos de Voz sobre IP (continuación) Protocolos de señalización de llamada Para simplificar la explicación vamos a utilizar un ejemplo de una llamada directa entre dos terminales (teléfonos IP o softphones)

Más detalles

VIDEOCONFERENCIAS SOBRE SIP

VIDEOCONFERENCIAS SOBRE SIP VIDEOCONFERENCIAS SOBRE SIP ING. ALFREDO FLORES E-mail: floresa@ucv.ve RESUMEN SIP (Session Initiation Protocol) fue desarrollado por la IETF ( Internet Engineering Task Force) y definido inicialmente

Más detalles

UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE INGENIERÍA ESTUDIOS DE POSTGRADO TRANSMISIÓN DE DATOS Y TELEMETRÍA

UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE INGENIERÍA ESTUDIOS DE POSTGRADO TRANSMISIÓN DE DATOS Y TELEMETRÍA UNIVERSIDAD CENTRAL DE VENEZUELA FACULTAD DE INGENIERÍA ESTUDIOS DE POSTGRADO TRANSMISIÓN DE DATOS Y TELEMETRÍA INTEGRANTES Barrios, Angellen C.I. 84.430.220 De Arco, Rafael C.I. 17.696.894 PROFESOR: Fernández,

Más detalles

Tecnología de voz sobre IP aplicada a la integración de plataformas de telefonía en instituciones académicas públicas de Argentina

Tecnología de voz sobre IP aplicada a la integración de plataformas de telefonía en instituciones académicas públicas de Argentina Tecnología de voz sobre IP aplicada a la integración de plataformas de telefonía en instituciones académicas públicas de Argentina a,b Mariano Javier Martin, a,c Fernando Aversa a Asociación Redes de Interconexión

Más detalles

Ing. Tania Díaz tdiaz@conatel.com.uy

Ing. Tania Díaz tdiaz@conatel.com.uy Sistemas de telefonía IP de gran porte basados en open source (Asterisk, sip-router) Ing. Tania Díaz tdiaz@conatel.com.uy 1 Agenda Generalidades Asterisk. Generalidades SIP router/kamailio. Diseño de un

Más detalles

Grupo de Trabajo en VoIP de RIU Informe de lo Actuado Período May 2010 Sep 2011

Grupo de Trabajo en VoIP de RIU Informe de lo Actuado Período May 2010 Sep 2011 Informe de lo Actuado Período May 2010 Sep 2011 RED DE INTERCONEXIÓN UNIVERSITARIA Grupo de Trabajo en Voz sobre IP UNIVERSIDAD NACIONAL DE VILLA MARIA (Arg) Ing. Mariano Javier MARTÍN (marianojm@gmail.com)

Más detalles

La telefonía tradicional

La telefonía tradicional VoIP y Asterisk La telefonía tradicional Red telefónica básica RTB: Cada línea RTB tiene asignada una numeración específica. Físicamente está constituida por dos hilos metálicos (par de cobre), que se

Más detalles

TCP/IP. IRI 2 do cuatrimestre 2015

TCP/IP. IRI 2 do cuatrimestre 2015 TCP/IP IRI 2 do cuatrimestre 2015 Redes y Protocolos Una red es un conjunto de computadoras o dispositivos que pueden comunicarse a través de un medio de transmisión en una red. Los pedidos y datos de

Más detalles

1. Parámetros de configuración de red... 2. 1.1 Configuración automática de los parámetros de red... 2. 2. El protocolo DHCP... 3

1. Parámetros de configuración de red... 2. 1.1 Configuración automática de los parámetros de red... 2. 2. El protocolo DHCP... 3 DHCP. Configuración dinámica de la red Índice 1. Parámetros de configuración de red... 2 1.1 Configuración automática de los parámetros de red... 2 2. El protocolo DHCP... 3 2.1 Funcionamiento de DHCP...

Más detalles

Manual del Módulo de Telefonía IP v1.23a. Titulo

Manual del Módulo de Telefonía IP v1.23a. Titulo Manual del Módulo de Telefonía IP v1.23a Titulo Contenido 1 INTRODUCCIÓN... 3 2 ARQUITECTURA Y CONCEPTOS... 3 3 CAPACIDADES Y ESQUEMAS DE CONEXIÓN... 5 3.1 EDOMO COMO CENTRALITA TELEFÓNICA: INTERCOMUNICACIÓN...

Más detalles

1. PARAMETROS DE CALIDAD DE SERVICIO. -PERDIDAS DE PAQUETES EN LOS ROUTERS: Vía TCP son recuperables, pero las retransmisiones TCP son

1. PARAMETROS DE CALIDAD DE SERVICIO. -PERDIDAS DE PAQUETES EN LOS ROUTERS: Vía TCP son recuperables, pero las retransmisiones TCP son TEMA 6: APLICACIONES MULTIMEDIA EN TIEMPO REAL Internet es una red de computadoras TCP/IP que basa su funcionamiento en la tecnología de conmutación de paquetes mediante un servicio no orientado a conexión.

Más detalles

Mónica Cortés Dpto. de Ingeniería de Sistemas Telemáticos

Mónica Cortés Dpto. de Ingeniería de Sistemas Telemáticos VOIP Voz sobre IP Mónica Cortés Dpto. de Ingeniería de Sistemas Telemáticos Multimedia en IETF! Real Time Protocol (RTP) paquetes multimedia! Real Time Control Protocol (RTCP) monitorizar & reportar! Session

Más detalles

Seguridad en VoIP. Seguridad

Seguridad en VoIP. Seguridad Seguridad en VoIP Seguridad Seguridad en VoIP Entender como instalar Asterisk es importante pero: Tanto como para un CRACKER como para un Ethical Hacker es vital entender como funciona el nucleo de la

Más detalles

Convocatoria Becas LACNIC XII. UNIVERSIDAD NACIONAL DE VILLA MARIA Dirección General de Informática

Convocatoria Becas LACNIC XII. UNIVERSIDAD NACIONAL DE VILLA MARIA Dirección General de Informática UNIVERSIDAD NACIONAL DE VILLA MARIA Dirección General de Informática Responsables Técnicos ante ARIU Gerardo José Venier (gvenier@unvm.edu.ar) Mariano Javier Martín (marianojm@unvm.edu.ar) - Mayo de 2010

Más detalles

CAPÍTULO 1: CONCEPTOS BÁSICOS DE TELEFONÍA

CAPÍTULO 1: CONCEPTOS BÁSICOS DE TELEFONÍA CAPÍTULO 1: CONCEPTOS BÁSICOS DE TELEFONÍA 1.1 INTRODUCCIÓN La tecnología ha avanzado rápidamente a lo largo de los años innovando la comunicación entre los seres humanos. Dentro de estos grandes logros

Más detalles

Asterisk - Central Telefónica PBX

Asterisk - Central Telefónica PBX Asterisk - Central Telefónica PBX Asterisk es una aplicación software libre de una central telefónica (PBX). Como cualquier PBX, se puede conectar un número determinado de teléfonos para hacer llamadas

Más detalles

CAPITULO III. TECNOLOGÍA SNMP

CAPITULO III. TECNOLOGÍA SNMP CAPITULO III. TECNOLOGÍA SNMP En este capitulo haremos una presentación sobre la estructura básica del protocolo de monitoreo SNMP. El objetivo de este protocolo es poder realizar un monitoreo del estado

Más detalles

8 Conjunto de protocolos TCP/IP y direccionamiento IP

8 Conjunto de protocolos TCP/IP y direccionamiento IP 8 Conjunto de protocolos TCP/IP y direccionamiento IP 8.1 Introducción a TCP/IP 8.1.1 Historia de TCP/IP El Departamento de Defensa de EE.UU. (DoD) creó el modelo de referencia TCP/IP porque necesitaba

Más detalles

Cuándo nace VoIP? telefonía IP (Internet Protocol)

Cuándo nace VoIP? telefonía IP (Internet Protocol) Introducción VoIP Cuándo nace VoIP? En 1995 la empresa VocalTec realiza la primera llamada telefónica de PC a PC a través de Internet, es aquí donde nace el término de telefonía IP (Internet Protocol)

Más detalles

Telefonía IP. Diseño e Implementación del Sistema RENZO TACO COAYLA. e-mail: renzo@itsperu.com url: http://www.itsperu.com blog: http://www.oxaseis.

Telefonía IP. Diseño e Implementación del Sistema RENZO TACO COAYLA. e-mail: renzo@itsperu.com url: http://www.itsperu.com blog: http://www.oxaseis. Telefonía IP Diseño e Implementación del Sistema RENZO TACO COAYLA e-mail: renzo@itsperu.com url: http://www.itsperu.com blog: http://www.oxaseis.tk CONSULTORIA EMPRESARIAL EN TI Evolución 1995 Israel.-

Más detalles

Dirección General de Educación Superior Tecnológica INSTITUTO TECNOLÓGICO DE SALINA CRUZ

Dirección General de Educación Superior Tecnológica INSTITUTO TECNOLÓGICO DE SALINA CRUZ Dirección General de Educación Superior Tecnológica INSTITUTO TECNOLÓGICO DE SALINA CRUZ UNIDAD: 3 CAPA DE RED Y DIRECCIONAMIENTO DE LA RED: IPv4 ACTIVIDAD: REPORTE DEL CAPITULO 6 DE CISCO MATERIA: FUNDAMENTOS

Más detalles

Estructura del protocolo OSI

Estructura del protocolo OSI Semana 14 14 Empecemos! En esta última semana del 9no semestre te queremos felicitar por haber llegado hasta aquí con éxito, enfrentando y resolviendo retos relacionados a los tipos de redes. Esperamos

Más detalles

1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones.

1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones. Módulo Profesional: Servicios en Red. Código: 0227. Resultados de aprendizaje y criterios de evaluación. 1. Instala servicios de configuración dinámica, describiendo sus características y aplicaciones.

Más detalles

VPN RED PRIVADA VIRTUAL INTEGRANTES: ALEXANDER BERNAL RAMIREZ CARLOS TRANCA JOSUE FLORES MIGUEL ANGEL VILLANUEVA

VPN RED PRIVADA VIRTUAL INTEGRANTES: ALEXANDER BERNAL RAMIREZ CARLOS TRANCA JOSUE FLORES MIGUEL ANGEL VILLANUEVA VPN RED PRIVADA VIRTUAL INTEGRANTES: ALEXANDER BERNAL RAMIREZ CARLOS TRANCA JOSUE FLORES MIGUEL ANGEL VILLANUEVA CONCEPTO VPN DEFINICIÓN, QUE SE PUEDE HACER CON UN VPN TIPOS DE VPN - ARQUITECTURA VPN ACCESO

Más detalles

1.Introducción. 2.Direcciones ip

1.Introducción. 2.Direcciones ip 1.Introducción El papel de la capa IP es averiguar cómo encaminar paquetes o datagramas a su destino final, lo que consigue mediante el protocolo IP. Para hacerlo posible, cada interfaz en la red necesita

Más detalles

VOIP LA NUEVA REVOLUCION

VOIP LA NUEVA REVOLUCION VOIP LA NUEVA REVOLUCION Con la aparición de redes IP, se revolucionó la forma como nos comunicamos, ahora podemos enviar imágenes, textos, archivos de audio y video; a partir de la década de los 90, se

Más detalles

Capítulo 1: Introducción

Capítulo 1: Introducción Capítulo 1: Introducción El presente trabajo se ubica en el área de administración de redes inalámbricas de computadoras y tiene como objetivo crear una propuesta de solución para permitir un manejo más

Más detalles

Cómo funciona Solución mwatcher Let's connect

Cómo funciona Solución mwatcher Let's connect Cómo funciona Solución mwatcher Let's connect Introducción En este documento vamos a explicar cuáles son las problemáticas que nos encontramos a la hora de realizar un telemantenimiento o acceso remoto

Más detalles

Jorge De Nova Segundo

Jorge De Nova Segundo UD9: Instalación y administración de otros servicios de red e Internet Servicio de tecnología de voz IP VoIP. Jorge De Nova Segundo Telefonía tradicional. El teléfono es un dispositivo de telecomunicación

Más detalles

Última modificación: 7 de junio de 2010. www.coimbraweb.com

Última modificación: 7 de junio de 2010. www.coimbraweb.com SISTEMAS DE SEÑALIZACIÓN Contenido 1.- Concepto de señalización. 2.- Señalización de abonado. 3.- Señalización entre centrales. 4.- Señalización asociada al canal. 5.- Señalización ió por canal común.

Más detalles

PROYECTO. Solución Empresarial Ingeniería y Desarrollo de Software www.solucionempresarial.com.ar - info@solucionempresarial.com.

PROYECTO. Solución Empresarial Ingeniería y Desarrollo de Software www.solucionempresarial.com.ar - info@solucionempresarial.com. PROYECTO 1 ÍNDICE 1. Presentación 2. Que es OpenVPN 3. Uso de las VPN s 4. Implementación 5. Seguridad 6. Ventajas 6. Requisitos 7. Objetivos 8. Presupuesto 2 Presentación Es una solución multiplataforma

Más detalles

MÓDULO: SERVICIOS E RED. Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio]

MÓDULO: SERVICIOS E RED. Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio] MÓDULO: SERVICIOS E RED Nombre: Curso: 2º SMR (9-6-2011) [Examen Final Junio] PARTE 1: Responde las siguientes preguntas tipo TEST. Solo hay una respuesta correcta. Dos respuestas incorrectas anulan una

Más detalles

Univ. de Concepción del Uruguay Facultad de Ciencias Agrarias Ingeniería Agrónoma

Univ. de Concepción del Uruguay Facultad de Ciencias Agrarias Ingeniería Agrónoma INFORMÁTICA Univ. de Concepción del Uruguay Facultad de Ciencias Agrarias Ingeniería Agrónoma Informática Teoría Unidad 5 Prof. Ing Ezequiel Benavente Ciclo lectivo 2014 Diferencias entre un Modem y un

Más detalles

Capítulo 7 Multimedia en Redes de Computadores

Capítulo 7 Multimedia en Redes de Computadores Capítulo 7 Multimedia en Redes de Computadores Material tomado de: Computer Networking: A Top Down Approach Featuring the Internet, 3 rd edition. Jim Kurose, Keith Ross Addison-Wesley, July 2004. 7: Multimedia

Más detalles

TEMA: PROTOCOLOS TCP/IP

TEMA: PROTOCOLOS TCP/IP TEMA: PROTOCOLOS TCP/IP HISTORIA: El Protocolo de Internet (IP) y el Protocolo de Transmisión (TCP), fueron desarrollados inicialmente en 1973 por el informático estadounidense Vinton Cerf como parte de

Más detalles

Voz sobre IP con GNU/Linux y Asterisk PBX. Comunidad de usuarios Debian de El Salvador René Mayorga rmayorga@debian.org.sv

Voz sobre IP con GNU/Linux y Asterisk PBX. Comunidad de usuarios Debian de El Salvador René Mayorga rmayorga@debian.org.sv Voz sobre IP con GNU/Linux y Asterisk PBX Comunidad de usuarios Debian de El Salvador René Mayorga rmayorga@debian.org.sv 27 de mayo de 2008 Índice general 0.1. Qué es una PBX?.........................

Más detalles

Jornadas Técnicas de RedIRIS 2010 Córdoba, 17-19 de Noviembre

Jornadas Técnicas de RedIRIS 2010 Córdoba, 17-19 de Noviembre Jornadas Técnicas de RedIRIS 2010 Córdoba, 17-19 de Noviembre COMUNICACIONES UNIFICADAS ENTRE ORGANIZACIONES VÍA INTERNET Guillermo Sanz Sanz Comunicaciones Unificadas entre organizaciones vía Internet

Más detalles

Bloque IV: El nivel de red. Tema 10: Enrutamiento IP básico

Bloque IV: El nivel de red. Tema 10: Enrutamiento IP básico Bloque IV: El nivel de red Tema 10: Enrutamiento IP básico Índice Bloque IV: El nivel de red Tema 10: Enrutamiento IP básico Introducción Tabla de enrutamiento Algoritmo de enrutamiento Direcciones IP

Más detalles

Semestre I Aspectos básicos de Networking

Semestre I Aspectos básicos de Networking Semestre I Aspectos básicos de Networking Capítulo 6: Direccionamiento de la red Ip v4 1 Estructura de una dirección Ip v4 Cada dispositivo de una red debe ser definido en forma exclusiva. En la capa de

Más detalles

Informe Implementación Proyecto de Título Tareas a Realizar. Esteban De La Fuente y Eduardo Díaz

Informe Implementación Proyecto de Título Tareas a Realizar. Esteban De La Fuente y Eduardo Díaz Informe Implementación Proyecto de Título Tareas a Realizar Esteban De La Fuente y Eduardo Díaz 2 nov 2009 Índice general 1. Introducción 3 2. Objetivos 4 2.1. Objetivos generales..................................

Más detalles

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA)

Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) Examen de Redes de Datos Tecnólogo en Telecomunicaciones (ROCHA) SOLUCIÓN (más completa que el mínimo requerido para obtener los máximos puntajes) Pregunta 1 En el sistema de nombre de dominio (DNS): a)

Más detalles

Rodríguez Marcela Esmeralda Villafranco Nahúm de Jesús Villafranco Magdiel Esaú

Rodríguez Marcela Esmeralda Villafranco Nahúm de Jesús Villafranco Magdiel Esaú Cátedra: Redes II Catedrático: Ing. Manuel Flores Villatoro Tema: Implementación de Planta Telefónica IP Integrantes: Rodríguez Marcela Esmeralda Villafranco Nahúm de Jesús Villafranco Magdiel Esaú Introduccion

Más detalles

Voz sobre IP El futuro es hoy. Rafael Loscos Sanz

Voz sobre IP El futuro es hoy. Rafael Loscos Sanz Voz sobre IP El futuro es hoy Rafael Loscos Sanz 1.- Qué es la tecnología VoIP. Consiste en aprovechar la infraestructura desplegada para la transmisión de datos para transmitir voz, utilizando el protocolo

Más detalles

GUÍAS FÁCILES DE LAS TIC

GUÍAS FÁCILES DE LAS TIC GUÍAS FÁCILES DE LAS TIC del COLEGIO OFICIAL DE INGENIEROS DE TELECOMUNICACIÓN Trabajo Premiado 2006 Autor: Router IP D. José María Jurado García-Posada 17 de Mayo 2006 DIA DE INTERNET Guía fácil Router

Más detalles

LACNIC Foro Latinoamericano de IPv6 FLIP6. Mayo, 2011

LACNIC Foro Latinoamericano de IPv6 FLIP6. Mayo, 2011 LACNIC Foro Latinoamericano de IPv6 FLIP6 Mayo, 2011 Tutor: Ing. Álvaro Sánchez Pablo Rico Matías Sentanaro Horacio Ruiz Diseñar e implementar un ambiente de pruebas de laboratorio para VoIP y calidad

Más detalles

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN Los protocolos de capa de aplicación de TCP/IP más conocidos son aquellos que proporcionan intercambio de la información

Más detalles

Introducción Internet no tiene una estructura real, pero existen varios backbone principales. Estos se construyen a partir de líneas y routers de alta velocidad. Conectados a los backbone hay redes regionales

Más detalles

PRACTICA NO.25: HOW TO INSTALL AND CONFIGURE ELASTIX CENTRAL IP

PRACTICA NO.25: HOW TO INSTALL AND CONFIGURE ELASTIX CENTRAL IP PRACTICA NO.25: HOW TO INSTALL AND CONFIGURE ELASTIX CENTRAL IP Jose Arturo Beltre Castro 2013-1734 ING. JOSE DOÑE Sistemas Operativos III Elastix Elastix es una distribución libre de Servidor de Comunicaciones

Más detalles

Proyecto Implementación de un nodo para una red libre (Wi-Fi) Redes de computadores I

Proyecto Implementación de un nodo para una red libre (Wi-Fi) Redes de computadores I Proyecto Implementación de un nodo para una red libre (Wi-Fi) Redes de computadores I Integrantes Patricio Jaque González Jorge Pareja Ayala Profesor Agustín González V. RESUMEN Una red libre con tecnología

Más detalles

CAPITULO V RESULTADOS ALCANZADOS. 1.- Funcionamiento del servidor TrixBox (Asterisk).

CAPITULO V RESULTADOS ALCANZADOS. 1.- Funcionamiento del servidor TrixBox (Asterisk). CAPITULO V RESULTADOS ALCANZADOS. Para la implementación de la propuesta, es necesario realizar la evaluación del funcionamiento del servicio de voz sobre IP para Interconectar a un usuario remoto a través

Más detalles

Repaso de conceptos Tema 1.- Introducción

Repaso de conceptos Tema 1.- Introducción Clases 2 y 3 Repaso de conceptos Tema 1.- Introducción Dr. Daniel Morató Redes de Ordenadores Ingeniero Técnico de Telecomunicación Especialidad en Sonido e Imagen, 3º curso Material parcialmente adaptado

Más detalles

Borja Gª de Vinuesa O. Desarrollo e implantación de un sistema de VoIP basado en Asterisk Resumen

Borja Gª de Vinuesa O. Desarrollo e implantación de un sistema de VoIP basado en Asterisk Resumen Universidad Carlos III de Madrid Borja Gª de Vinuesa O. Desarrollo e implantación de un sistema de VoIP basado en Asterisk Resumen Universidad Carlos III de Madrid Av. Universidad, 30 Leganés Índice de

Más detalles

Última modificación: 1 de mayo de 2010. www.coimbraweb.com

Última modificación: 1 de mayo de 2010. www.coimbraweb.com TELEFONÍA IP Contenido 1.- Introducción. 2.- Telefonía tradicional. 3.- Codificación de voz. 4.- Telefonía sobre IP. 5.- Equipamiento VoIP. 6.- Calidad de servicio en VoIP. Última modificación: ió 1 de

Más detalles

Manual de Extensión. Portal de Usuario, Códigos de marcación & correo de voz para Central Telefónica 3CX Versión 6.0

Manual de Extensión. Portal de Usuario, Códigos de marcación & correo de voz para Central Telefónica 3CX Versión 6.0 Manual de Extensión Portal de Usuario, Códigos de marcación & correo de voz para Central Telefónica 3CX Versión 6.0 Derechos Reservados 2006-2008, 3CX ltd. http:// E-mail: info@3cx.com La información de

Más detalles

UNIDAD 1.1 - MODELO OSI/ISO

UNIDAD 1.1 - MODELO OSI/ISO UNIDAD 1.1 - MODELO OSI/ISO El modelo de referencia OSI es el modelo principal para las comunicaciones por red. Aunque existen otros modelos, en la actualidad la mayoría de los fabricantes de redes relacionan

Más detalles

Sistema de telefonía IP de emergencia para Banca

Sistema de telefonía IP de emergencia para Banca Sistema de telefonía IP de emergencia para Banca Descripción El sistema de telefonía IP de emergencia orientado a Banca se basa en el uso de un teléfono o interfono exclusivo denominado IPefono Handset,

Más detalles

Asterisk, proxies SIP, servidores de aplicaciones A qué se puede jugar? jesusr@voztele.com

Asterisk, proxies SIP, servidores de aplicaciones A qué se puede jugar? jesusr@voztele.com Asterisk, proxies SIP, servidores de aplicaciones A qué se puede jugar? jesusr@voztele.com Qué es SIP Definido en RFC3261... y unas cuantas más! Formato texto Similar a HTTP Sólo señalización Complicado,

Más detalles

Centralita Virtual y Operador IP

Centralita Virtual y Operador IP Centralita Virtual y Operador IP Barcelona, 10 de Noviembre de 2015 Fax: 93.198.06.09 http://www.innovatalk.com - 1 - Qué es Asterisk? Asterisk es una solución de centralita IP por software que proporciona

Más detalles

Protocolo de Internet (IP)

Protocolo de Internet (IP) Semana 12 Empecemos! Estimado y estimada participante, esta semana tendrás la oportunidad de aprender sobre protocolo de Internet (IP), el cual permite enlazar computadoras de diferentes tipos, ser ejecutado

Más detalles

Descripción y Contenido del Curso VoIP basado en Asterisk PBX

Descripción y Contenido del Curso VoIP basado en Asterisk PBX Descripción y Contenido del Curso VoIP basado en Asterisk PBX Capacity Academy Educación en Tecnología de la Información Online, Efectiva y Garantizada Qué aprenderá si toma este Curso? En este curso aprenderás

Más detalles

Modelo TCP/IP. Página 1. Modelo TCP/IP

Modelo TCP/IP. Página 1. Modelo TCP/IP Modelo TCP/IP Página 1 Índice: Página 1.-Introducción 3 2.-Arquitectura TCP/IP 3 3.-Protocolo IP 8 4.-Direccionamiento IP 9 5.-Otros Protocolos de la capa de Red. 12 6.-Ejercicios 13 7.-Protocolos de resolución

Más detalles

UNIVERSIDAD DE LAS FUERZAS ARMADAS ESPE EXTENSIÓN LATACUNGA

UNIVERSIDAD DE LAS FUERZAS ARMADAS ESPE EXTENSIÓN LATACUNGA UNIVERSIDAD DE LAS FUERZAS ARMADAS ESPE EXTENSIÓN LATACUNGA TESIS PRESENTADA COMO REQUISITO PREVIO A LA OBTENCIÓN DEL GRADO DE INGENIERO EN ELECTRÓNICA E INSTRUMENTACIÓN CAICEDO ROMERO IRMA YOLANDA CHANGO

Más detalles

Paquete: Puerto: Socket: TCP: NAT: RDSI: LAN: WAN: Gateway OSI: Router: Línea Dedicada: MRouter: MultiCasting: Máscara de Subred: Dirección IP:

Paquete: Puerto: Socket: TCP: NAT: RDSI: LAN: WAN: Gateway OSI: Router: Línea Dedicada: MRouter: MultiCasting: Máscara de Subred: Dirección IP: - 2001-11-17! Este texto sólo intenta ser una ayuda para que cualquier usuario comprenda unos conceptos que hoy en día se perfilan como imprescindibles en una red. Antes, debemos familiarizarnos y entender

Más detalles

CAPITULO I FORMULACION DEL PROBLEMA

CAPITULO I FORMULACION DEL PROBLEMA CAPITULO I FORMULACION DEL PROBLEMA TITULO DESCRIPTIVO DEL PROYECTO. Implementación de un servidor proxy para el control de tráfico de la red y gestión de los servicios de Internet en los centros de cómputo

Más detalles

Diego Mauricio Cortés Quiroga

Diego Mauricio Cortés Quiroga Diego Mauricio Cortés Quiroga 1150209 Instalación del Servicio SQUID (proxy transparente) en Fedora 17 Qué es SQUID? Es un popular programa de software libre que implementa un servidor proxy y un dominio

Más detalles

Capas del Modelo ISO/OSI

Capas del Modelo ISO/OSI Modelo ISO/OSI Fue desarrollado en 1984 por la Organización Internacional de Estándares (ISO), una federación global de organizaciones que representa aproximadamente a 130 países. El núcleo de este estándar

Más detalles

La vida en un mundo centrado en la red

La vida en un mundo centrado en la red La vida en un mundo centrado en la red Aspectos básicos de networking: Capítulo 3 1 Objetivos En este capítulo aprenderá a: Describir cómo las funciones de las tres capas superiores del modelo OSI que

Más detalles

Normat_P V.2.0 RED IP DE TELEFÓNICA DE ESPAÑA GUÍA DE USUARIO DE LA FUNCIONALIDAD DE PROXY-CACHÉ

Normat_P V.2.0 RED IP DE TELEFÓNICA DE ESPAÑA GUÍA DE USUARIO DE LA FUNCIONALIDAD DE PROXY-CACHÉ Normat_P V.2.0 RED IP DE TELEFÓNICA DE ESPAÑA GUÍA DE USUARIO DE LA FUNCIONALIDAD DE PROXY-CACHÉ RED IP DE TELEFÓNICA DE ESPAÑA: GUÍA DE USUARIO DE LA FUNCIO- NALIDAD DE PROXY-CACHÉ ÍNDICE 1. INTRODUCCIÓN...

Más detalles

Agenda. Duración aprox.: 2 horas.

Agenda. Duración aprox.: 2 horas. Agenda 1 Objetivos de la implementación. 2 Que es un Softswitch? 3 Estructuras, de Red,Interna y Externa. 4 - Stack SIP, Estructuras SIP y SDP 5 - Clases de Código y cabecera 5 Mensajes de Error 6 - Formas

Más detalles

1. Qué codec de audio seleccionaría para minimizar el ancho de banda?

1. Qué codec de audio seleccionaría para minimizar el ancho de banda? Voz Video y Telefonía sobre IP Preguntas múltiple opción 1. Qué codec de audio seleccionaría para minimizar el ancho de banda? a) G.711 b) G.729 c) G.723.1 d) RTAudio 2. El ancho de banda en la LAN en

Más detalles

Qué es la Telefonía sobre IP (ToIP)?

Qué es la Telefonía sobre IP (ToIP)? Telefonía sobre IP (ToIP) Luís Merayo Servicios Qué es la telefonía sobre IP? Cómo funciona? Qué ventajas ofrece al usuario? Resuelva estas y otras dudas en este interesante artículo. Qué es la Telefonía

Más detalles

UNIVERSIDAD NACIONAL DEL COMAHUE

UNIVERSIDAD NACIONAL DEL COMAHUE UNIVERSIDAD NACIONAL DEL COMAHUE Redes de computadoras Internet Juan Carlos Brocca Redes - Internet Descripción Redes - Internet Descripción Física Redes - Internet Descripción Física Sistemas terminales

Más detalles

Fundamentos de Redes LI. Unidad III Modelos de Comunicaciones 3.1 Modelo de referencia OSI.

Fundamentos de Redes LI. Unidad III Modelos de Comunicaciones 3.1 Modelo de referencia OSI. 3.1 Modelo de referencia OSI. Durante las últimas dos décadas ha habido un enorme crecimiento en la cantidad y tamaño de las redes. Muchas de ellas sin embargo, se desarrollaron utilizando implementaciones

Más detalles

MX250 Características Técnicas del Sistema MX 250 de Zultys Technologies.

MX250 Características Técnicas del Sistema MX 250 de Zultys Technologies. MX250 Características Técnicas del Sistema MX 250 de Zultys Technologies. Total funcionalidad como Central Telefónica con correo de voz integrado Basado en estándares abiertos: SIP, Linux, Voice XML, TAPI,

Más detalles

Yo no hice nada por accidente, ni tampoco fueron así mis invenciones; ellas vinieron por el trabajo

Yo no hice nada por accidente, ni tampoco fueron así mis invenciones; ellas vinieron por el trabajo PREPARACIÓN DEL EXAMEN DE CICLOS VOZ-IP Introducción Yo no hice nada por accidente, ni tampoco fueron así mis invenciones; ellas vinieron por el trabajo Edison Y Guille La voz sobre IP o VoIP consiste

Más detalles

Seguridad en Redes Convergentes: Seguridad en Voz sobre IP (VoIP) Internet Security Auditors Daniel Fernández Bleda CISSP, OPST/OPSA Trainer

Seguridad en Redes Convergentes: Seguridad en Voz sobre IP (VoIP) Internet Security Auditors Daniel Fernández Bleda CISSP, OPST/OPSA Trainer Seguridad en Redes Convergentes: Seguridad en Voz sobre IP (VoIP) Internet Security Auditors Daniel Fernández Bleda CISSP, OPST/OPSA Trainer Co-Founder www.isecauditors.com 1 Índice Qué es VoIP? Protocolos

Más detalles

INSTALACIÓN, OPERACIÓN Y PROGRAMACIÓN DE EQUIPOS Y SISTEMAS TELEFÓNICOS

INSTALACIÓN, OPERACIÓN Y PROGRAMACIÓN DE EQUIPOS Y SISTEMAS TELEFÓNICOS 09-06-2015 1 Descripción y funcionamiento de una central PABX 09-06-2015 2 Un PBX o PABX (siglas en inglés de Private Branch Exchange y Private Automatic Branch Exchange para PABX), la cual es la red telefónica

Más detalles

Arquitectura y seguridad

Arquitectura y seguridad En el desarrollo del SIGOB nos hemos enfrentado a diversos problemas que nos han llevado a investigar y desarrollar nuestras propias tecnologías. En este documento presentamos cada uno de los desarrollos

Más detalles

CAPITULO 8. Planeamiento, Arquitectura e Implementación

CAPITULO 8. Planeamiento, Arquitectura e Implementación CAPITULO 8 Planeamiento, Arquitectura e Implementación 8.1 Replicación en SQL Server La replicación es un conjunto de tecnologías destinadas a la copia y distribución de datos y objetos de base de datos

Más detalles

Anexos Remotos para Lyric MG.

Anexos Remotos para Lyric MG. Anexos Remotos para Lyric MG. White Paper versión 1.0 Fecha: Septiembre 2014 Historia del Documento. Version Fecha Cambios 1.0 Sep 10, 2014 1. Versión Inicial Tabla de Contenidos. Historia del Documento.

Más detalles

Modelo de infraestructura común para el Servicio de correo electrónico para la Comunidad RedIRIS

Modelo de infraestructura común para el Servicio de correo electrónico para la Comunidad RedIRIS Modelo de infraestructura común para el Servicio de correo electrónico para la Comunidad RedIRIS Octubre 2008 1. Situación actual Actualmente el correo electrónico junto con el web y la red son servicios

Más detalles

Soluciones Voz IP con software libre

Soluciones Voz IP con software libre Soluciones Voz IP con software libre 1 Índice Índice de Contenidos Presentación de Asterisk Funcionalidades de Asterisk Casos Prácticos y Posibilidades de Integración 2 Presentación de Asterisk Que es

Más detalles

Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT

Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT Instituto Tecnológico y de Estudios Superiores de Monterrey Práctica de Laboratorio 4 Implementación de un NAPT Marco teórico: La red más grande del mundo, Internet, ha tenido un gran crecimiento en la

Más detalles

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN

PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN PRACTICA CAPITULO 2 MODULO 1 PROTOCOLOS Y LA FUNCIONALIDAD DE LA CAPA DE APLICACIÓN Los protocolos de capa de aplicación de TCP/IP más conocidos son aquellos que proporcionan intercambio de la información

Más detalles

Tema 6: Servicios multimedia bajo demanda

Tema 6: Servicios multimedia bajo demanda Tema 6 1 Índice Tema 6: Contenido 6.1 Problemática del servicio de streaming en Internet Real-Time Streaming Protocol (RTSP) Tema 6 2 Ref Bibliografía Bibliografía básica Weinstein, Stephen. The Multimedia

Más detalles

Protocolos de Voz sobre IP

Protocolos de Voz sobre IP Protocolos de Voz sobre IP Introducción Existen una gran cantidad de protocolos que proponen formas distintas de establecer y controlar comunicaciones voz sobre redes IP. Mucho se habla de ellos, y la

Más detalles

WAN y Enrutamiento WAN

WAN y Enrutamiento WAN WAN y Enrutamiento WAN El asunto clave que separa a las tecnologías WAN de las LAN es la capacidad de crecimiento, no tanto la distancia entre computadoras Para crecer, la WAN consta de dispositivos electrónicos

Más detalles

11 Número de publicación: 2 314 637. 51 Int. Cl.: 74 Agente: Carpintero López, Mario

11 Número de publicación: 2 314 637. 51 Int. Cl.: 74 Agente: Carpintero López, Mario 19 OFICINA ESPAÑOLA DE PATENTES Y MARCAS ESPAÑA 11 Número de publicación: 2 314 637 1 Int. Cl.: H04L 12/66 (06.01) H04L 29/12 (06.01) 12 TRADUCCIÓN DE PATENTE EUROPEA T3 96 Número de solicitud europea:

Más detalles

Q-expeditive Publicación vía Internet

Q-expeditive Publicación vía Internet How to Q-expeditive Publicación vía Internet Versión: 2.0 Fecha de publicación 11-04-2011 Aplica a: Q-expeditive 3 Índice Introducción... 3 Publicación de servicios... 3 Ciudadanos... 3 Terminales de auto

Más detalles

Introducción a SIP y OpenSER

Introducción a SIP y OpenSER Imagine there is no PSTN... Saúl Ibarra Corretgé http://www.saghul.net Un poco de historia Conmutación de circuitos La telefonía tradicional se basaba en conmutación de circuitos. Desde el comienzo hasta

Más detalles

Servicio de tecnología de voz IP VoIP. Jesús Torres Cejudo

Servicio de tecnología de voz IP VoIP. Jesús Torres Cejudo 1 - Telefonía tradicional. La telefonía fija o convencional, que es aquella que hace referencia a las líneas y equipos que se encargan de la comunicación entre terminales telefónicos no portables, y generalmente

Más detalles