Estudio, desarrollo e implementación de un servicio de Telefonía SIP

Transcripción

1 Estudio, desarrollo e implementación de un servicio de Telefonía SIP

2 Índice Índice Resumen 1 Introducción 1.1 Telefonía Internet 1.2 SIP, The Session Initiation Protocol 1.3 SDP, The Session Description Protocol 2 El servicio Sip Service 2.1 Arquitectura de Red 2.2 Arquitectura de Servicio 2.3 Sesión de usuario 3 Implementación del servicio Sip Service 3.1 Sip Client 3.2 Sip Proxy 3.3 Sip Service 4 Conclusiones y desarrollos futuros Anexo A Diagramas de flujo de Sip Service Abreviaturas y acrónimos Bibliografía i

3 Resumen Resumen El objetivo principal de este proyecto es el desarrollo e implementación de un servicio de Telefonía sobre IP. El servicio de Telefonía sobre IP implementado consiste en una arquitectura: Agente < > Proxy < > Agente El proxy es realmente el que implementa la lógica del servicio. El servicio realiza un control de la identificación del usuario consultando el DB del servicio donde éste debe aparecer subscrito. Además, realiza un análisis de la situación actual del llamado (controla si está conectado actualmente, y en caso de estarlo, mira en que dirección/es IP) mediante la consulta del objeto creado por el Proxy para cada agente conectado alguna vez a él. El usuario agente consiste en un paquete que deberá instalar el usuario en su PC multimedia. Para que sea posible el establecimiento de llamada el PC del usuario debe disponer de tarjeta de sonido full-duplex, así como de altavoces y micrófono. El usuario deberá descargarse la JVM 1.1.8, en caso de no disponer ya de ella, y el SipClient.zip. Al descomprimir SipClient.zip se instala en el PC del usuario el usuario agente. Para lanzarlo simplemente debe ejecutarse el script correspondiente. La interfaz del usuario agente es sencilla y de un tamaño mínimo para que su utilización sea fácil y cómoda, sin interrumpir el trabajo que se está realizando en ese momento con el ordenador. Consta de los botones: - Call: para realizar una llamada. - Hang Up: para finalizar la llamada. - Propertie: para configurar las propiedades del usuario. - Logout: para iniciar una nueva sesión de usuario. - Exit: para salir de la aplicación. La necesidad de señalización distingue la telefonía sobre Internet de otros servicios multimedia en Internet, como servicios broadcast o servicios de datos bajo demanda. Actualmente existen dos estándares de señalización de la telefonía sobre IP, la recomendación H.323 (propuesta por la ITU-T) y SIP (propuesto por el IETF). Como segundo objetivo del proyecto se estudia y demuestra la conveniencia de la utilización de SIP para la implementación de este servicio y, en general, para la transmisión de voz sobre IP. Llegándose a la conclusión de que SIP presenta mayores beneficios que H.323 en cuanto a: simplicidad, escalabilidad, extensibilidad y neutralidad con respecto al protocolo de transporte. Además se comprueba que SIP ofrece una gran facilidad para la implementación de servicios de Red Inteligente de la red telefónica tradicional en la telefonía IP. Como lenguaje de programación para el desarrollo de la aplicación se elige Java, con objetivo de demostrar las múltiples ventajas que éste presenta frente a la implementación en otros lenguajes de programación. Las características principales que llevan a su elección son: - Es un lenguaje multiplataforma. - La posibilidad de reutilización de las clases. - Es un lenguaje totalmente orientado a objetos. - Las interfaces son nativas del lenguaje. - La gestión de errores es obligatoria. - Posee muchos mecanismos de seguridad. 1

4 Introducción Capítulo 1 Introducción El objetivo principal de este proyecto es el desarrollo e implementación de un servicio de Telefonía sobre IP. Durante los últimos años, la telefonía Internet ha evolucionado de considerarse un juguete a ser una tecnología que, en un futuro no demasiado distante, pueda sustituir la existente red telefónica de conmutación de circuitos. Soportando el extenso uso de la telefonía Internet requiere un host de protocolos estandarizados para asegurar la calidad del servicio (QoS), el transporte de datos audio y vídeo, proporcionar servicios de directorio, y permitir señalización. Los protocolos de señalización son de particular interés porque son la base para los servicios avanzados tales como movilidad, números universales, conferencias multiparty, buzón de voz y distribución de llamada automática. Dos protocolos de señalización han surgido para satisfacer dicha necesidad: el protocolo H.323 del ITU-T (International Telecommunication Union-Telecommunication) y SIP (Session Initiation Protocol), desarrollado por el IETF (Internet Engineering Task Force). Como segundo objetivo del proyecto se pretende estudiar y demostrar la conveniencia de la utilización del Protocolo SIP (Session Initiation Protocol) para la implementación de este servicio y, en general, para la transmisión de voz sobre IP. Se presenta una visión general del protocolo y su arquitectura, y se describe como puede ser utilizado para proporcionar un número de servicios avanzados. La discusión desde algunos puntos clave de SIP su simplicidad, escalabilidad, extensibilidad, neutralidad con respecto al protocolo de transporte, servicios analiza porqué éstos son componentes críticos para un protocolo de señalización para la telefonía IP. Se demostrará que SIP es una herramienta valiosa, no únicamente para servicios IP extremo a extremo sino también para controlar los existentes servicios telefónicos. En el desarrollo de la telefonía Internet, se pretende que todas las características soportadas por los modernos sistemas de telefonía avanzada sean soportadas también por ésta. Como un tercer objetivo se plantea demostrar la facilidad de la implementación de servicios de la Red Inteligente tradicional en la telefonía Internet mediante la utilización del protocolo SIP. 2

5 Introducción Como lenguaje de programación para el desarrollo de la aplicación se elige Java, con objetivo de demostrar las múltiples ventajas que éste presenta frente a la implementación en otros lenguajes de programación. Las características principales que llevan a su elección son: - Es un lenguaje multiplataforma. - La posibilidad de reutilización de las clases. - Es un lenguaje totalmente orientado a objetos. - Las interfaces son nativas del lenguaje. - La gestión de errores es obligatoria. - Posee muchos mecanismos de seguridad. El servicio de Telefonía sobre IP consiste en una arquitectura: Agente < > Proxy < > Agente. El servicio realiza un control de la identificación del usuario consultando el DB del servicio donde éste debe aparecer subscrito. Además, realiza un análisis de la situación actual del llamado (controla si está conectado actualmente, y en caso de estarlo, mira en que dirección/es IP) mediante la consulta del objeto creado por el Proxy para cada agente conectado alguna vez a él. El proxy es realmente el que implementa la lógica del servicio. El usuario agente consiste en un paquete que deberá instalar el usuario en su PC multimedia. Para que sea posible el establecimiento de llamada el PC del usuario debe disponer de tarjeta de sonido full-duplex, así como de altavoces y micrófono. El usuario deberá descargarse la JVM 1.1.8, en caso de no disponer ya de ella, y el SipClient.zip. Al descomprimir SipClient.zip se instala en el PC del usuario el usuario agente. Para lanzarlo simplemente debe ejecutarse el script correspondiente. La interfaz del usuario agente es sencilla y de un tamaño mínimo para que su utilización sea fácil y cómoda, sin interrumpir el trabajo que se está realizando en ese momento con el ordenador. Consta de los botones de Call, Hang Up, Properties, Logout y Exit. 1.1 Telefonía Internet Actualmente, la mayor parte de la telefonía se basa en la tradicional red pública de conmutación de circuitos PSTN (Public Switched Telephone Network). En la cual, para llevar a cabo una llamada se reserva una conexión entre dos usuarios y nadie más puede usarla. Cuando la llamada finaliza la línea queda libre y de nuevo utilizable por el resto de usuarios. Una nueva tendencia que está emergiendo en los últimos años es la oferta de servicios telefónicos sobre redes IP, lo que se conoce como Telefonía IP o Voz sobre IP. Este nuevo tipo de telefonía se está convirtiendo en una amenaza para la telefonía tradicional basada en PSTN. Cada día el número de compañías interesadas en esta nueva modalidad de telefonía incrementa. En general, el concepto de Telefonía IP, se refiere al transporte de datos en tiempo real como voz y vídeo sobre una red IP, proporcionando comunicaciones interactivas entre los usuarios de Internet. En la telefonía IP, dado que el transporte se realiza sobre una red IP, es posible enviar paquetes entre dos o más usuarios sin necesidad de reservar la conexión. Esto se realiza digitalizando las señales audio, registradas usando el micrófono del ordenador, y encapsulándolas en paquetes para su posterior envío a través de la red usando los protocolos de Internet. En el receptor, se desencapsulan los paquetes y se escucha el mensaje original a través de los altavoces del ordenador. Las ventajas más significativas de la telefonía IP, y principales causantes de su evolución, son el ahorro de costes en la llamada y la fácil implementación de servicios innovadores: 3

6 Introducción En el futuro, los ITSP (Internet Telephony Service Providers), probablemente, usarán una única infraestructura para proveer tanto el acceso a Internet como la telefonía sobre Internet. Los conmutadores orientados a datos podrían ser desarrollados tanto para la conmutación de datos como para la paquetización de voz. Además, la multiplexación de datos y voz tendría como resultado una mejor utilización del ancho de banda que en los actuales enlaces de alta tecnología, únicamente para voz o datos. Ahora, los clientes de la telefonía IP pueden aprovechar la ventaja de tasación plana de Internet, en vez de la tasación jerárquica de la PSTN, y ahorrar dinero haciendo que sus llamadas a larga distancia sean encaminadas sobre la red Internet. Los usuarios de la telefonía IP pueden aprovecharse de su naturaleza orientada al software. El desarrollo de nuevos servicios telefónicos IP requiere menores inversiones en términos de tiempo y dinero que en el ambiente PSTN tradicional. Una de las mayores ventajas con la telefonía IP es la ausencia de restricción a un único tipo de datos, comparándola con la PSTN, la ventaja es la transparencia hacia el medio de transporte. Pero el gran desarrollo de este mercado está todavía obstaculizado, principalmente, por dos factores. En primer lugar, por la menor calidad de voz, particularmente por un más alto retardo y jitter. En segundo lugar, por la facilidad de operación y funcionalidad ofrecidas al usuario final, que deben ser al menos la misma que la ofrecida por la telefonía tradicional. Esta condición requiere a la arquitectura de la telefonía IP proveer una infraestructura de señalización que ofrezca al menos las mismas características y capacidad que el SS7 (Signaling System 7) de la arquitectura PSTN. Además, permanecen todavía abiertos muchos aspectos técnicos como: accounting, billing, charging, roaming, etc. El lado negativo de este nuevo método de telefonía es la dificultad de garantizar calidad de servicio (QoS), no hay modo de garantizar cuando llega un paquete. Este problema podría ser minimizado usando, en vez de la red Internet, redes privadas donde este garantizada una cierta QoS. La necesidad de señalización distingue la telefonía sobre Internet de otros servicios multimedia en Internet, como servicios broadcast o servicios de datos bajo demanda. Actualmente dos estándares compiten por conquistar la señalización de la telefonía sobre IP. El más veterano de ambos, la recomendación H.323, propuesta por la ITU-T, define un sistema de comunicaciones multimedia sobre redes de conmutación de paquetes, incluyendo redes IP. Y el Session Initation Protocol (SIP), propuesto por el grupo de trabajo MMUSIC (Multiparty Multimedia Session Control) del IETF, que es un protocolo del nivel de aplicación para el control y señalización de la creación, modificación y finalización de sesiones, de uno o más participantes, de conferencias multimedia Internet, de llamadas de teléfono Internet y de distribución multimedia. 1.2 SIP, The Session Initiation Protocol SIP es un protocolo de control para la creación, modificación y finalización de sesiones con uno o más participantes. Estas sesiones incluyen conferencias multimedia Internet, llamadas de teléfono sobre Internet y distribución multimedia. Los miembros en una sesión pueden comunicarse vía multicast, vía una mezcla de relaciones unicast, o una combinación de éstas. SIP soporta descripciones de la sesión que permiten a los participantes ponerse de acuerdo en el tipo de medio de comunicación a utilizar. También soporta movilidad del usuario gracias al paso o redirección de peticiones, a través de un proxy o servidor, a la localización actual del usuario. SIP no está atado a ningún protocolo de control de conferencia en particular. Existe un interés extendido en el protocolo, especialmente en lo relativo a las aplicaciones de telefonía. 4

7 Introducción SIP está fuertemente basado en los protocolos del IETF: SMTP (Simple Mail Transfer Protocol) y el HTTP (HyperText Transfer Protocol). Del mismo modo que ambos, SIP es un protocolo cliente-servidor textual. SIP reutiliza mucha de la sintaxis y semántica de HTTP, incluyendo su arquitectura de código de respuesta, muchas cabeceras de mensaje y su completa operación. Cada petición SIP es una tentativa de invocar algún método en el servidor. Existen seis métodos SIP: - INVITE: para invitar a un usuario a una llamada. - ACK: para confirmar que el cliente ha recibido una respuesta final a un INVITE. - OPTIONS: para solicitar información acerca de las capacidades del llamado, pero no establece una llamada. - BYE: utilizado por el cliente agente usuario (tanto llamante como llamado) para indicar al servidor que quiere abandonar la llamada. - CANCEL: para finalizar una petición pendiente, pero no una llamada completa. - REGISTER: para transportar información de localización a un servidor SIP. Existen dos clases de mensajes SIP: peticiones (requests) y respuestas (responses). Los clientes emiten peticiones y los servidores responden con respuestas. Las peticiones y las respuestas usan un formato genérico de mensaje el cual consiste en: una línea de inicio, uno o más campos de cabecera (para describir los detalles de la comunicación), una línea en blanco indicando el final de los campos de cabecera y un opcional cuerpo del mensaje. Existen 37 cabeceras, y pueden ser divididas en cuatro grupos diferentes de cabeceras: 1) generales; 2) entidad; 3) petición; 4) respuesta. Y seis clases de respuesta diferentes: 1xx: Informational Petición recibida, continúa el procesamiento de la petición. 2xx: Success La acción fue recibida con éxito, entendida y aceptada. 3xx: Redirection Necesarias acciones adicionales para completar la petición. 4xx: Client Error Error de sintaxis en la petición. 5xx: Server Error Fallo del servidor al resolver una petición aparentemente válida. 6xx: Global Failure La petición no puede ser resuelta en ningún servidor. SIP es un protocolo del nivel de aplicación que no requiere el soporte de un protocolo de transporte seguro. A diferencia de lo que ocurre en HTTP y SMTP, SIP puede funcionar tanto sobre TCP (Transmission Control Protocol) como sobre UDP (User Datagram Protocol), incluso también sobre IPX, Frame Relay, ATM o X.25. SIP soporta el mapeo de nombres y servicios de redireccionamiento, permitiendo la implementación de servicios ISDN y de Red Inteligente, que proporcionan al usuario una movilidad personal. SIP soporta cinco facetas del establecimiento y de la finalización de comunicaciones multimedia: 1) localización del usuario; 2) capacidades del usuario; 3) disponibilidad del usuario; 4) establecimiento de llamada; 5) finalización de llamada. Un sistema SIP posee únicamente dos componentes: agentes usuario (user agents) y servidores de red (networks servers). Un agente usuario es un sistema final que actúa en conducta de alguien que quiere participar en llamadas. En general, un agente usuario contiene ambos: un protocolo cliente llamado agente usuario cliente (UAC, User Agent Client) usado para iniciar la llamada, y un protocolo servidor llamado agente usuario servidor (UAS, User Agent Server) usado para responder la llamada. Además de los agentes usuarios, SIP proporciona dos tipos diferentes de servidores de red: proxy server y redirect server. Un proxy server SIP actúa prácticamente del mismo modo que un proxy HTTP, recibe una petición, determina a que servidor la debe enviar, y entonces redirige la petición, posiblemente tras la modificación de algunos de los campos de cabecera. El 5

8 Introducción proxy SIP puede ser stateful o stateless. Un redirect server recibe peticiones, pero en lugar de redirigirlas hacia el próximo servidor, éste dice al cliente que debe contactar el próximo servidor directamente. SIP ofrece un número de beneficios clave, frente a H.323, que lo convierten en el protocolo de señalización más conveniente para la implementación de servicios de transmisión de voz sobre IP: Simplicidad: es el más sencillo de los dos, posee únicamente 37 cabeceras mientras que H.323 define cientos de elementos y sus especificaciones son más extensas. Extensibilidad: se ha construido un rico conjunto de funciones de extensibilidad y compatibilidad, además, por defecto, las cabeceras y valores desconocidos son ignorados. En cambio, H.323 no tiene un mecanismo para permitir que los terminales se intercambien información acerca de que extensiones soportan cada uno, y las extensiones están limitadas únicamente a aquellos lugares donde un parámetro no estándar ha sido añadido. Neutralidad con respecto al protocolo de transporte: puede apoyarse tanto en TCP como en UDP pero, desafortunadamente, H.323 requiere el uso de un protocolo de transporte seguro. Integración con otros protocolos: buena integración con la Web, , aplicaciones y protocolos de flujo de datos, y otros servicios de red. Servicios avanzados: proporciona una gran facilidad para implementar servicios avanzados y de Red Inteligente. 1.3 SDP, The Session Description Protocol SDP (Session Description Protocol) es el protocolo que se utiliza para describir una sesión multimedia dentro de un mensaje de petición SIP. El propósito de éste es transportar información acerca de los medios de comunicación en sesiones multimedia, permitiendo a los diferentes usuarios recibir una descripción de la sesión para participar en ésta. SDP es puramente un formato para descripción de sesiones. No incorpora un protocolo de transporte, es más, está pensado para utilizar diferentes protocolos de transporte como: el Session Announcement Protocol, Session Initiation Protocol, Real-Time Streameing Protocol, correos electrónicos usando extensiones MIME y el HyperText Transport Protocol. En general, SDP debe transportar suficiente información para permitir unirse a una sesión (con la posible excepción de claves de encriptación) y anunciar que recursos utilizables existen a los no participantes. Una descripción SDP incluye las siguientes informaciones: Nombre y propósito de la sesión. Tiempo en que la sesión está activa. Los datos que la sesión abarca. Información de cómo recibir esos datos, tal como direcciones, puertos y formatos. Además puede incluir una información adicional, como: El ancho de banda que será usado en la conferencia. Información de contacto para la persona responsable del establecimiento de la sesión. SDP está pensado para ser de propósito general, así que, éste puede ser usado por una rango más amplio de entornos de red y aplicaciones que los directorios de sesiones multicast. Sin embargo, no ha sido pensado para soportar la negociación de los contenidos de la sesión o de codificadores de media. 6

9 Capítulo 2 El servicio Sip Service Capítulo 2 El servicio Sip Service El objetivo principal de este proyecto es implementar un servicio de telefonía sobre IP, el cual ha sido bautizado como Sip Service. Básicamente este servicio permite a un usuario realizar una llamada a través de la red IP a otro usuario que se encuentre registrado al servicio en ese momento. Si el usuario destino acepta la llamada, tiene lugar una conversación en tiempo real entre ambos. En caso de que el usuario destino no la acepte o no esté registrado en ese preciso momento, al usuario origen le llega un mensaje que le informará de porqué no se ha podido establecer la comunicación. Este servicio proporciona la gran ventaja de que pueden reducirse considerablemente los costes de las llamadas de larga distancia, pues todas se tarifarán como si de llamadas locales se tratase. En los próximos párrafos se describe el servicio Sip Service, la Arquitectura de Red, que muestra la estructura con la que se ha implementado el servicio en el nivel de red, y la Arquitectura de Servicio. En la sesión de usuario se refleja la sucesión de las distintas fases que el participante supera cada vez que interacciona con el servicio. 2.1 Arquitectura de Red La propuesta del servicio Sip Service, como servicio integrado en el escenario Internet- Telecom, prevé un futuro bastante prometedor en este ámbito. La arquitectura de red estudia la estructura en la que dicho servicio se ha implementado. La estructura con la que se ha implementado el servicio Sip Service podría resumirse como: Agente Usuario < > Proxy Server < > Agente Usuario DB A continuación se procede a la descripción de cada uno de los elementos de la estructura: Usuario con PC multimedia. No se trata de un usuario anónimo, ya que para hacer uso del servicio Sip Service ha necesitado subscribirse y registrarse a éste. El usuario hace uso del servicio mediante la aplicación Java que previamente ha debido instalarse en su PC. Ésta 7

10 Capítulo 2 El servicio Sip Service aplicación Java consiste en una interfaz gráfica que implementa el role de Usuario Agente (Sip Client). En el momento en que ha sido enviado por parte del llamante el correspondiente mensaje de INVITE al llamado, y el llamado acepta la llamada enviando un mensaje de OK al llamante, es cuando realmente se activa la conexión entre ambos usuarios y comienza la comunicación. Para ello hace uso de un cliente de VoIP, llamado ITACA (Internet Telephony Application for Callcenter Assistance), el cual realiza una codificacióndecodificación de voz en IP. Cada usuario requiere un PC multimedia, que conste de una tarjeta de sonido full-duplex, micrófono y altavoces. El Sip-Proxy Server. Funciona como un servidor proxy para el servicio de telefonía sobre IP implementado. Este servidor controla la señalización y el establecimiento de llamada. El proxy accede a la base de datos que contiene la información de cada usuario subscrito al servicio, así en el momento de la autenticación puede saber si el username y password son los correctos, y utilizar las URLs introducidas, como la foto, sonido y homepage. La Base de Datos (DB, Data Base). Se encarga de almacenar todos los datos que el usuario facilita en su subscripción al servicio. Dichos datos son utilizados a lo largo del servicio dado que proporcionan información específica del usuario, como el username, el password, URL de la foto, URL del sonido, URL de la homepage. 2.2 Arquitectura de Servicio Dominio de usuario En el servicio Sip Service, el dominio de usuario contiene a todos los usuarios que se han subscrito al servicio. En la subscripción, cada usuario debe facilitar todos los datos obligatorios que se le solicitan como: nombre, apellidos, dirección, etc., también son imprescindibles el username y password, que le servirán para registrarse cada vez que desee utilizar la aplicación. Además puede o no introducir unos datos adicionales como son unas determinadas URLs (para indicar una foto, un sonido específico, una homepage). Existe una página de presentación del servicio Sip Service, desde la cual puede descargarse el fichero SipClient.zip, el cual contiene todo lo necesario para que el usuario pueda instalarse el cliente Sip en su PC. Para su instalación basta descomprimirlo directamente en la unidad C:\, y automáticamente se crea el directorio SipClient con una estructura de directorios interna. El usuario, una vez subscrito al servicio, accede al servicio gracias a la interfaz gráfica que se arranca por medio del script C:\SipClient\run_client.bat. Para poder establecer una comunicación de voz sobre IP, necesita un cliente VoIP. El cliente con el que ha sido desarrollado el servicio es ITACA, (implementado en CSELT) Dominio de servidor El primer componente que se crea cuando se inicia el servicio es la SipProxySvcFactory. El objetivo de este objeto no sólo es el preparar el ambiente del servicio, sino también el de proporcionar la referencia remota de la lógica (SipProxySvcLogicRef). La SipProxySvcLogic implementa la lógica del servicio y controla las operaciones desarrolladas en dicho servicio. Autentica cada vez que un usuario quiere hacer uso del servicio. Proporciona los datos del participante, datos proporcionados por éste en el momento de la subscripción. Estos datos pueden ser modificados mediante llamadas remotas a la lógica del servicio de subscripción que, mediante llamadas remotas al DB, efectúa las modificaciones solicitadas. 8

11 Capítulo 2 El servicio Sip Service Contiene el estado de una llamada telefónica propuesta por un usuario, que será aceptada o rechazada por el participante al cual va dirigida. 2.3 Sesión de usuario El usuario antes de la utilización del servicio, como ya se ha comentado anteriormente, accederá a la homepage de éste, en la cual se realiza una pequeña presentación y se indican los pasos a seguir para su utilización e instalación. En el momento no se ha pensado como será la tasación de este servicio. Para su primera etapa, de experimentación y utilización, será un servicio gratuito pero será necesario que el usuario se subscriba para poder utilizarlo. Una vez que el usuario se ha subscrito a uno de los dominios proporcionados por el proveedor, el siguiente paso es la descarga del fichero que contiene la aplicación Java que implementa el agente usuario. El agente usuario, denominado SipClient, se entrega comprimido en un fichero.zip, y puede descargarse desde la página de presentación del servicio Sip. El procedimiento que debe seguirse para la instalación de SipClient en el PC del usuario ha sido pensado para que sea simple y claro, pues cualquier complicación podría provocar que un futuro usuario desistiera de utilizar la aplicación. Basta con descomprimir el fichero SipClient.zip directamente en la unidad C:\, creándose el directorio SipClient y toda una estructura de directorios interna. Resumiendo, la estructura de directorios que se crea es la siguiente: C:\SipClient\bin: contiene el ejecutable que se encarga de la codificación de voz. C:\SipClient\cfg: contiene el fichero de configuración del usuario agente. C:\SipClient\lib: contiene todas las clases Java. C:\SipClient\log: contiene los ficheros de log que se crean durante la ejecución de Sip Client, con la finalidad de poder ser consultados en caso de producirse algún error. C:\SipClient\run_client.bat: consiste en el script que se utiliza para arrancar la aplicación. El usuario deberá editar el fichero de configuración client.cfg que se encuentra bajo el directorio C:\SipClient\cfg\, en él se hallan todos los parámetros configurables de la aplicación. De todos ellos el usuario debe introducir los siguientes: INVITER_ID: nombre del usuario que ha sido indicado en los datos de subscripción (corresponde con el username dado); INVITER_DOMAIN: nombre del dominio al que se ha subscrito el usuario; Estos parámetros son utilizados para que por defecto cada vez que el usuario arranque la aplicación en la ventana de autenticación aparezcan rellenados los campos de username y domain con el INVITER_ID e INVITER_DOMAIN respectivamente. Del resto de parámetros debe hacerse especial mención a los siguientes, y asegurarse de que están correctamente populados: USE_LOCAL_PROXY: indica si se desea utilizar un proxy, en caso afirmativo debe estar a TRUE. domainname_proxy_ip: corresponde a la dirección IP del proxy server; dado que existe un proxy por cada dominio deberá existir una variable para cada uno de ellos. 9

12 Capítulo 2 El servicio Sip Service domainname_proxy_port: corresponde al puerto del proxy server, y por tanto deberá existir una variable por cada dominio. STREAMER_PROGRAM: contiene el comando que debe ejecutarse en el momento del lanzamiento del programa que se encarga de la codificación de la voz. Su inicialización requiere que el símbolo \ de separación entre directorios sea representado como \\, es decir, quedaría por ejemplo del siguiente modo: STREAMER_PROGRAM=c:\\SipClient\\bin\\Tisip.exe. STREAMER_NAVIGATOR: contiene el comando necesario para la ejecución del navegador. Debe seguirse para la separación entre directorios la misma nomenclatura que en el caso de STREAMER_PROGRAM. En este punto se puede decir que se ha finalizado la fase de instalación y subscripción al servicio, ahora puede procederse a su utilización. El servicio Sip Service en el lado del usuario se lanza mediante un script: C:\SipClient\run_client.bat. Como se observa en la primera ventana que aparece tras la ejecución de dicho script (véase Figura 2-1), la sesión de usuario se inicia con la autenticación del mismo, mediante el username y password con que el usuario se ha subscrito al servicio. Figura 2-1 Autenticación del usuario Si el username y password introducidos son los correctos de un usuario subscrito al servicio se accede al teléfono. Si, en cambio, éstos no correspondiesen a ningún usuario subscrito aparece una alerta como la que se muestra en la Figura 2-2, volviendo a la ventana de autenticación. Figura 2-2 Alerta que avisa de un error de Login En el momento que la autenticación ha sido realizada con éxito se muestra el teléfono al usuario. Véase en la Figura 2-3 su aspecto. Se ha pensado en que tenga esa forma y tamaño en especial para que el usuario pueda tener abierta esta aplicación mientras realiza su trabajo en el PC, sin que resulte molesto para él. 10

13 Capítulo 2 El servicio Sip Service Figura 2-3 SipClient Se pretende que el teléfono realice las funciones elementales de Call y Hang Up, como cualquier teléfono de la red fija. Pero además, consta de otros tres botones: Properties, Logout y Exit, cuyas funcionalidades son explicadas a continuación. Properties El teléfono implementado posee algunas propiedades configurables, y para poder cambiarlas se ha creado el botón Properties. Tras pulsarlo aparece la interfaz que se muestra en la Figura 2-4. Los campos que se muestran en primer lugar son campos pertenecientes al perfil del usuario, User s Profile. Éstos son: Nickname: el usuario puede utilizar si lo desea un nickname. Si este campo es rellenado, en el mensaje de invitación de llamada que recibe el usuario destino aparece adicionalmente esta información. Sip Url: corresponde a la dirección Sip del usuario. El campo aparece sombreado en gris para hacer visual el hecho de que no es editable. El usuario sólo podría cambiar su dirección Sip variando sus datos de subscripción. Ip Address: contiene la dirección Ip a la que se encuentra registrado el usuario en ese momento. Se trata de un campo no editable para el usuario, la aplicación se encarga de recoger esa información directamente del PC en el que ha sido lanzada. Listener Port: muestra el número de puerto que está siendo utilizado. Del mismo modo que los dos campos anteriores, su color gris indica que no es editable. Aunque este parámetro sí es configurable desde el fichero de configuración. Alt. Url: contiene el valor de una dirección web. Si el usuario en un momento dado recibe una llamada pero no puede aceptarla, tiene dos opciones: rechazarla directamente, o bien, permitir que a la persona que le ha llamado se le abra el navegador con la dirección web indicada en este campo, que se supone se trata de una página que aporta algún tipo de información relacionada con él. El protocolo SIP presenta una gran facilidad para implementar servicios de los tradicionales protocolos de Red Inteligente. Con motivo de dejar constancia de ello se han implementado en este proyecto tres servicios: TCS (Terminating Call Screening): Este servicio consiste en realizar un filtrado en las llamadas terminantes. Si el campo Allow es rellenado, se controlará si la dirección Sip que en éste aparece coincide con la del llamante, en caso de que así sea la llamada procederá con normalidad, en caso contrario al llamante le aparecerá una alerta con el mensaje Forbidden. OCS (Originating Call Screening): Este servicio consiste en la realización de un filtrado en las llamadas originantes. Si el campo Deny ha sido cumplimentado con una dirección Sip, cada vez que este usuario desee realizar una llamada se comprobará si ésta coincide con la del usuario al que se desea llamar, de ser así le aparecerá la alerta de Forbidden, en caso contrario la llamada seguirá su curso con normalidad. CRD (Call Rerouting Distribution): Este servicio implementa la redirección de la llamada a la dirección Sip indicada en el campo On Busy Sip Url, en caso de que el usuario esté ocupado en ese momento con otra llamada. O la redirección a 11

14 Capítulo 2 El servicio Sip Service la dirección indicada en el campo After n rings Sip Url, en el caso de que hayan sonado n tonos y el destinatario no haya respondido todavía a la invitación de llamada. Figura 2-4 Interfaz para la definición de Propiedades Cuando el usuario ha finalizado de introducir todos los parámetros de configuración del servicio, para que estos datos se almacenen en el servidor debe pulsar el botón Ok. Mediante el botón Cancel puede anular la operación, y mediante Delete borrar el contenido de todos los campos editables. Call Obviamente, el botón Call posee la funcionalidad de realización de llamada. En el momento que es pulsado aparece una ventana denominada Place Call (véase Figura 2-5), en la que se introduce la información de: la dirección del destinatario (To), y el tema de la llamada (Subject), para que el receptor de la invitación pueda saber antes de decidir aceptarla o no de que se trata. También se observa un campo de prioridad (Priority), pero de momento es no editable, se ha introducido para un uso futuro, sirviendo para discriminar unas llamadas con respecto a otras de mayor prioridad en ocasiones de tráfico elevado. 12

15 Capítulo 2 El servicio Sip Service Figura 2-5 Campos a cumplimentar para realizar una llamada Junto al campo To se observa un pequeño botón el cual simula la funcionalidad de un buscador, en este caso un buscador de direcciones de usuarios. Al pulsarlo aparece una lista de usuarios (Users List) similar a la que se presenta en la Figura 2-6, esta lista contiene a todos los usuarios subscritos al servicio Sip Service. A medida que el usuario se va desplazando por cada una de las direcciones Sip de la lista, en el campo existente en el lado inferior izquierdo de la ventana aparece la notificación de si ese usuario está registrado en ese momento al servicio (REGISTER), no lo está (NOT_REGISTER), o no ha podido comprobarse (NOT_CHECK), que puede ser porque el servidor se haya caído en ese momento, o se haya dado un time-out. Figura 2-6 Lista de usuarios subscritos Figura 2-7 Realización de una llamada El campo To es requerido para la realización de la llamada, en caso de no ser populado o tener un formato incorrecto aparece un mensaje de error, en cambio, el campo Subject es opcional. Una vez han sido cumplimentados los datos basta pulsar Call para que la llamada 13

16 Capítulo 2 El servicio Sip Service empiece a cursarse. El botón Cancel tiene la funcionalidad de volver a la pantalla anterior sin realizar la llamada. El Sip Client posee un campo de texto donde va apareciendo en cada momento información del estado de la llamada. En la Figura 2-8 se observa como el usuario romero@domain1 está llamando a dolz@domain2, y como en el PC del usuario destinatario de la llamada aparece una ventana indicando que existe una invitación de llamada. Figura 2-8 Recepción de la invitación de llamada En la ventana denominada Incoming Call aparecen los campos From y Subject, que indican de quien proviene la invitación y el tema de la llamada, respectivamente. Además, si el usuario origen ha decidido utilizar un nickname (introduciéndolo en Properties), éste también aparece reflejado en el mensaje de llamada entrante. El llamado posee tres alternativas de acción dependiendo de cual de los tres botones pulse: Accept, Busy y Homepage. Con Accept: se acepta la llamada. En el momento que el usuario destino pulsa este botón se inicia la comunicación y ambos usuarios pueden comenzar a conversar (véase Figura 2-9). Figura 2-9 Comunicación activa Con Busy: el usuario destino no acepta la invitación de llamada. Al usuario origen le llega un mensaje de que el usuario al que llamaba a rechazado su invitación (véase Figura 2-10). Figura 2-10 Llamada rechazada 14

17 Capítulo 2 El servicio Sip Service Con Homepage: el usuario destino en ese momento decide que no puede o desea conversar con el llamante pero, en cambio, desea que éste vea la información de su homepage. En el PC del llamante se abre el navegador y se visualiza la página que corresponde con la URL que el usuario destino ha indicado en el campo correspondiente de sus propiedades. Hang Up Una vez establecida la comunicación, ambos usuarios están capacitados para en el momento que lo deseen finalizar la conversación, para ello simplemente basta con pulsar el botón de Hang Up. Cuando uno de ellos decide hacer Hang Up al otro usuario le llega un mensaje de que la otra parte ha colgado y, por tanto, se termina la conversación. Obsérvese en las diferentes pantallas anteriormente mostradas, que ilustran el proceso de la llamada, que una vez que el botón de Call ha sido pulsado éste queda inhabilitado, y no se habilitará hasta que se pulse el botón de Hang Up. Y entonces, queda habilitado el botón de Call e inhabilitado el de Hang Up. Logout El botón Logout sirve para cuando se desea seguir utilizando la aplicación pero por otro usuario, de este modo se indica al servidor que este usuario ya no está registrado en esa dirección IP y aparece de nuevo la ventana de autenticación, para que un nuevo usuario realice el Login. Un mismo usuario puede estar registrado desde más de una posición IP. Lo que sucede en este caso es que cuando un usuario desee establecer una comunicación con él le llegará una invitación de llamada a cada uno de los lugares donde esté registrado en ese instante. En el momento que se acepte la llamada desde una de las posiciones se iniciará la comunicación entre el usuario origen y el destinatario que se encuentra en la posición desde la cual se ha aceptado. En el resto de posiciones donde está registrado el usuario destino desaparecerá la invitación de llamada. Si el usuario al que se desea llamar en ese instante no se encuentra registrado en ningún lugar, el llamante recibirá una notificación y se cancelará la invitación de llamada. La Figura 2-11 muestra la alerta que recibe el usuario que origina la invitación cuando el usuario al cual ésta va dirigida no se encuentra registrado. Exit Figura 2-11 Alerta usuario no registrado Cuando un usuario desea cerrar la aplicación basta con pulsar Exit, de este modo se cierra la ventana del teléfono y se comunica al servidor que dicho usuario ya no está registrado en dicha dirección IP. 15

18 Capítulo 3 Implementación del servicio Sip Service Capítulo 3 Implementación del servicio Sip Service En este capítulo se expone la implementación del servicio Sip Service. El servicio Sip Service está constituido por dos agentes usuario, que corresponden al llamante y al llamado, y un proxy, que es el servidor. La implementación del usuario agente se ha denominado Sip Client. Consiste en una aplicación Java que, tras su debida instalación en el PC del usuario, le permite, de un modo transparente, enviar mensajes SIP del tipo: REGISTER, INVITE, CANCEL, BYE, ACK, y de este modo, poder registrarse en el proxy server, así como establecer una llamada con otro Sip Client. La implementación del proxy server se ha denominado Sip Proxy, y ha sido realizada en Java, dado que Java presenta múltiples ventajas para el propósito de este proyecto. En este capítulo se expone como han sido implementados el Sip Client y el Sip Proxy. Con motivo de proporcionar una visión dinámica del servicio Sip Service se recurre a la inserción de varios diagramas de flujo y diagramas temporales (véase Anexo A). 3.1 Sip Client El Sip Client es lanzado en el PC del usuario mediante un script. El script ejecuta la clase ClientEndPoint (véase Figura A-0, Anexo A), pasando como parámetro el fichero de configuración del cliente. Inicialmente se comprueba que el número de parámetros introducidos al llamar al programa es el correcto. En caso de no ser el adecuado, se muestra por pantalla un mensaje de error, que indica el porqué del error y cual es el modo de lanzar ClientEndPoint. ClienEndPoint ha sido programado para que si se desea pueda ser ejecutado también en modo applet. Cuando se desea utilizar en modo applet debe inicializarse la variable boolena 16

19 Capítulo 3 Implementación del servicio Sip Service isapplet a true. La diferencia se encuentra en que si se ejecuta en modo applet los parámetros de configuración se obtienen del applet, en cambio, en modo aplicación gráfica se obtienen del fichero de configuración. Tras la instancia de la clase ClientEndPoint, se ejecuta un método de inicialización de las variables. Se determina si se va a utilizar en modo applet o en modo aplicación gráfica, y dependiendo de ello se obtienen los parámetros de configuración del applet o del fichero de configuración, respectivamente. Al final del método existe una llamada que instancia la clase LoginGUI, la cual crea la interfaz gráfica de la ventana de autenticación de usuario Implementación de Login La interfaz gráfica de la ventana de autenticación de usuario es creada mediante la clase LoginGUI. En el diagrama temporal de la Figura A-1 (Anexo A) pueden observarse las acciones que tienen lugar durante la realización del login del usuario. El usuario, tras introducir su username, domain y password, pulsa el botón Login y entonces el Sip Client comprueba que todos los campos son distintos de null. En caso de que alguno de ellos no haya sido rellenado por el usuario, se instancia la clase ErrorMssgGUI, a la cual se le pasa como parámetro el tipo de error de que se trata, para así mostrar una ventana de diálogo con el mensaje de error adecuado (siendo en esta ocasión un mensaje que indica que todos los campos deben ser populados). En caso de que todos los datos hayan sido introducidos por el usuario, se envía un mensaje REGISTER al Sip Proxy para corroborar que son correctos. El mensaje REGISTER para el caso de "LOGIN se envía con la particularidad que en el campo contact se introduce el username@domain del usuario que va a registrarse. Si username, domain y password son correctos se recibe un mensaje de respuesta OK_CODE al REGISTER enviado al proxy, y se pasa a instanciar la clase ClientGUI, la cual es la encargada de crear la interfaz gráfica del teléfono. En cambio, si no son correctos, se instancia la clase ErrorMssgGUI, con el mensaje de Login error. Y se muestra de nuevo el frame logingui Implementación de Properties Partiendo del frame clientgui, pueden ser ejecutadas diferentes acciones dependiendo del botón que se pulse. En caso que el usuario desee visualizar o actualizar las diferentes propiedades configurables por él mismo, éste presionará el botón Properties, instanciándose de este modo la clase PropertiesGUI, que se encarga de generar la interfaz gráfica donde se le muestran al usuario todas la propiedades configuradas en una sesión anterior y donde se le permite su modificación. Cuando el usuario se registra al servicio, como ya ha sido visto en el apartado de implementación de Login, éste envía un mensaje de REGISTER. El proxy en su mensaje de respuesta envía en el campo contact las propiedades actuales del usuario junto con la lista de los usuarios suscritos al servicio. El Sip Client almacena las propiedades mediante el método setproperties y la lista de usuarios suscritos mediante el método setsubscribedusers. Tras instanciarse PropertiesGUI (Figura A-2, Anexo A), tiene lugar la ejecución de un método de inicialización que muestra el valor correspondiente de cada propiedad en la interfaz. El usuario, en este momento, procede a modificar las propiedades que desea. 17

20 Capítulo 3 Implementación del servicio Sip Service Si cambiase de idea y no desease actualizar ninguna de las propiedades, bastará pulsar el botón Cancel para anular la acción, y cerrar la interfaz de Properties. Las acciones para la actualización de las propiedades, son ordenadas mediante la pulsación del botón Ok, y consisten en realizar un set de las propiedades en el Sip Client, y enviar un mensaje de tipo REGISTER al proxy, para que el servidor también las actualice. El mensaje REGISTER contiene el nombre de las propiedades en el campo contactextensionnames, y sus respectivos valores en el campo contactextensionvalues. El Sip Client recibirá un mensaje de respuesta del proxy al REGISTER, y si la actualización ha sido realizada con éxito su código de respuesta será OK_CODE. En este momento se inicializa la interfaz Client GUI Implementación de Call Cuando se pretende realizar una llamada se pulsa el botón Call de la interfaz gráfica Client GUI, en este momento se desencadena la ejecución de las acciones que han sido implementadas para que se realice la llamada. El diagrama de flujo de la Figura A-3 (Anexo A) ayuda a visualizar éstas. En primer lugar, se instancia la clase CallGUI, la cual genera la interfaz gráfica donde el usuario deberá introducir los datos necesarios para la realización de la llamada, es decir, el campo To (requerido), correspondiente al llamado, y el campo Subject (opcional), correspondiente al argumento de la llamada. Además, la interfaz Client GUI se inicializa en modo llamada. En un momento inicial los botones de la aplicación Client se encuentran todos activos, excepto el botón Hang Up, el cual no puede ser pulsado. En cambio, cuando ya ha sido presionado Call, este botón pasa a inactivo y se activa el de Hang Up. Es lógico que ocurra esto, y no volverán a su posición inicial hasta que no finalice o se cancele la llamada en curso. El usuario tiene dos opciones: introducir el campo To manualmente, o a través de un buscador de usuarios, para ello debe pulsar el botón?, que proporciona el listado de todos los usuarios suscritos al servicio. Cuando el botón? es pulsado, se instancia la clase UsersListGUI, que genera una interfaz gráfica donde aparece una lista con todos los usuarios suscritos al servicio, y un campo de texto que indica si el usuario está o no registrado al servicio en ese momento. Para obtener dicha información, se envía al proxy un mensaje REGISTER, en el que en el campo contact se envía el string USER_REGISTER (para que el proxy entienda que se trata de un mensaje que requiere este tipo de información). En el servicio, existen usuarios suscritos a diferentes proxies, y cada uno de ellos posee información únicamente de sus propios usuarios. Por tanto, cada mensaje REGISTER deberá ser enviado al proxy correspondiente al usuario del que se desee obtener la información. El proxy devolverá un mensaje de respuesta al REGISTER, con código de respuesta OK_CODE, si el usuario está en ese momento registrado y, por tanto, se indicará en la interfaz mediante REGISTER, o con código de respuesta DOES_NOT_EXIST_ANYWHERE_CODE, si el usuario no está registrado en el momento, lo cual se indicará en el campo de texto de la interfaz mediante NOT_REGISTER. 18