Descripción de las Tecnologías usadas

El objetivo general de este proyecto es crear una pequeña aplicación que permita el intercambio de mensajes de texto, al estilo de un Chat, entre un teléfono celular y algún softphone, aprovechando la mensajería instantánea que provee el protocolo SIP, la implementación se hará en la plataforma J2ME.

J2ME

Esta versión de Java está enfocada a la aplicación de la tecnología Java en dispositivos electrónicos con capacidades computacionales y gráficas muy reducidas, tales como teléfonos móviles, PDAs o electrodomésticos inteligentes. Esta edición tiene unos componentes básicos que la diferencian de las otras versiones, como el uso de una máquina virtual denominada KVM (Kilo Virtual Machine, debido a que requiere sólo unos pocos Kilobytes de memoria para funcionar) en vez del uso de la JVM clásica, inclusión de un pequeño y rápido recolector de basura y otras diferencias que ya iremos viendo más adelante.

• Componentes de J2ME

J2ME está compuesto de varios componentes, a continuación se describe cada uno de ellos:
• Máquinas virtuales: existe un conjunto de máquinas virtuales con diferentes requisitos, cada para distintos tipos de dispositivos, esto debido a que para distintos tipos de dispositivos J2ME suprime algunas características con el fin de obtener una implementación menos exigente. Las maquinas virtuales son:
• KVM, corresponde a la máquina virtual más pequeña desarrollada por Sun, su nombre proviene de kilobyte, ocupa entre 40 y 80 kilobytes de memoria, dependiendo de la plataforma, está orientada a dispositivos con baja capacidad computacional y de memoria.
• CVM o compact virtual machine, está orientada a dispositivos electrónicos con procesadores de 32 bits de gama alta y en torno a 2Mb o más de memoria RAM. Soporta las mismas características que J2SE,
• Configuraciones: una configuración es el conjunto mínimo de APIs Java que permiten desarrollar aplicaciones para un grupo de dispositivos. Existen 2 configuraciones en J2ME:
• Configuración de dispositivos con conexión o CDC (Connected Device Configuration), está orientada a dispositivos con cierta capacidad computacional y de memoria. Por ejemplo, decodificadores de televisión digital, televisores con Internet, algunos electrodomésticos y sistemas de navegación en automóviles. CDC usa una Máquina Virtual Java similar en sus características a una de J2SE, pero con limitaciones en el apartado gráfico y de memoria del dispositivo. Ésta Máquina Virtual es la que hemos visto como CVM (Compact Virtual Machine).
  Configuración de dispositivos limitados con conexión, CLDC (Connected Limited Device Configuration). La CLDC está orientada a dispositivos dotados de conexión y con limitaciones en cuanto a capacidad gráfica, cómputo y memoria. Un ejemplo de estos dispositivos son: teléfonos móviles, buscapersonas (pagers), PDAs, organizadores personales, etc. CLDC está orientado a dispositivos con ciertas restricciones, algunas de estas restricciones vienen dadas por el uso de la KVM, necesaria al trabajar con la CLDC debido a su pequeño tamaño.
• Perfiles: un perfil es un conjunto de APIs orientado a un ámbito de aplicación determinado. Los perfiles identifican un grupo de dispositivos por la funcionalidad que proporcionan (electrodomésticos, teléfonos móviles, etc.) y el tipo de aplicaciones que se ejecutarán en ellos. Las librerías de la interfaz gráfica son un componente muy importante en la definición de un perfil. Aquí nos podemos encontrar grandes diferencias entre interfaces, desde el menú textual de los teléfonos móviles hasta los touchscreen de los PDAs.
• A continuación se analizan los distintos perfiles:
• Foundation Profile: Este perfil define una serie de APIs sobre la CDC orientadas a dispositivos que carecen de interfaz gráfica como, por ejemplo, decodificadores de televisión digital.
• Personal Profile: El Personal Profile es un subconjunto de la plataforma J2SE v1.3, y proporciona un entorno con un completo soporte gráfico AWT. El objetivo es el de dotar a la configuración CDC de una interfaz gráfica completa, con capacidades web y soporte de applets Java. Este perfil requiere una implementación del Foundation Profile.
• RMI Profile: Este perfil requiere una implementación del Foundation Profile se construye encima de él. El perfil RMI soporta un subconjunto de las APIs J2SE v1.3 RMI. Este perfil permite trabajar con rmi para acceder a metodos remotos.
• PDA Profile: El PDA Profile está construido sobre CLDC. Pretende abarcar PDAs de gama baja, tipo Palm, con una pantalla y algún tipo de puntero (ratón o lápiz) y una resolución de al menos 20000 pixels (al menos 200x100 pixels) con un factor 2:1. No es posible dar mucha más información porque en este momento este perfil se encuentra en fase de definición.
• Mobile Information Device Profile (MIDP): Este perfil está construido sobre la configuración CLDC. Al igual que CLDC fue la primera configuración definida para J2ME, MIDP fue el primer perfil definido para esta plataforma. Este perfil está orientado para dispositivos con reducida capacidad computacional y de memoria, conectividad limitada (en torno a 9600 bps), capacidad gráfica muy reducida (mínimo un display de 96x54 pixels monocromo), entrada de datos alfanumérica reducida.
• Los tipos de dispositivos que se adaptan a estas características son: teléfonos móviles, buscapersonas (pagers) o PDAs de gama baja con conectividad. Actualmente este perfil tiene 2 versiones, la última proporciona APIs para los nuevos dispositivos, tales como los últimos teléfonos

Podemos resumir la arquitectura de una aplicación J2ME en la siguiente figura:

Ilustración 1 Arquitectura de una aplicación J2ME

En el desarrollo de este proyecto se asume la utilización de teléfonos celulares y/o PDAs, es por eso que la máquina virtual a utilizar será KVM en una configuración CLDC y un perfil MIDP. En un ambiente CLDC/MIDP las aplicaciones deben derivar de la clase Midlet, un MIDlet es una aplicación Java realizada con el perfil MIDP sobre la configuración CLDC. Además el perfil MIDP es el único disponible actualmente.

J2ME es actualmente utilizado para el desarrollo de juegos para celulares, sin embargo las posibilidades están limitadas por las características de la API, los recursos de la plataforma y la imaginación del programador. Muchas de las aplicaciones solo están limitadas por el tamaño de la pantalla.

Sip

• SIP permite el establecimiento de la ubicación del usuario, esto es traducir el nombre del nombre de usuario su actual dirección en la red.
• SIP proporciona la negociación de características, de modo que todos los participantes de una sesión puedan acordar las características soportadas por ellos.
• SIP es un mecanismo para manejo de llamadas, por ejemplo permite agregar, eliminar o transferir participantes.
• SIP permite cambiar las características de una sesión cuando esta está en progreso.
  

Su funcionamiento se muestra a continuación:

Ilustración 2 Transacciones protocolo SIP

El Proxy SIP se encarga de direccionar, registrar las sesiones SIP. Además responde a las peticiones de un terminal SIP o bien puede prestar servicios a los terminales, tales como localización de un usuario. También es posible realizar una comunicación directa entre terminales por lo que el servidor no es imprescindible.

Dentro de las funciones de SIP tenemos:

• Resolución de Direcciones
• Funciones de Sesión:
  Establecimiento
  Negociación de medios
  Modificación
  Terminación
  Cancelación
  Señalización en llamada
  Control de llamada
  Configuración de QoS
• No relacionadas con la sesión:
  Movilidad
  Transporte de Mensajes
  Suscripción a eventos
  Autenticación
  Otras funciones (SIP es Extensible)

Para realizar las funciones especificadas en SIP se utilizan los siguientes métodos:

Como se puede apreciar el protocolo se encarga solo de manejar la sesión, la transmisión de los datos se puede realizar mediante otro protocolo, generalmente es usado el protocolo de tiempo real (RTP).

El protocolo de inicio de sesión se encuentra estructurado en capas, esto significa que su comportamiento puede ser descrito por un conjunto etapas de procesamiento, esto con el propósito de presentación permitiendo así describir funciones comunes en una sección. La capa más baja es la capa de sintaxis y codificación. La cual define el formato que debe tener cada campo, por ejemplo que el SIP URI debe ser de la forma sip:[usuario]@[dominio].

La segunda capa es la capa de transporte, que define como el cliente y el servidor reciben requerimientos y envía respuestas sobre la red.

La tercera capa es la capa de transacciones. Las transacciones son un componente fundamental es SIP, una transacción es un requerimiento enviado por un cliente de transacciones a un servidor de transacciones, a través de la capa de transporte, incluyendo las respuestas que el servidor envíe de vuelta al cliente. Esta capa se encarga de todas las respuestas, retransmisiones y timeouts que se produzcan.

La capa que se encuentra por sobre la capa de transacciones es llamada transaction user (TU). Cada entidad SIP es un TU, excepto los proxies sin estado. Cuando un TU desea enviar un requerimiento crea una instancia de una transacción cliente y la envía a través de la red. Un TU puede cancelar esta transacción, cuando esto ocurre se detiene el procesamiento de la transacción, se vuelve al estado anterior y se genera una respuesta especifica de error, esto se logra con un requerimiento tipo CANCEL, el cual constituye en si mismo una transacción, pero referida a la transacción a ser cancelada.

Los requerimientos en SIP son enviados en la primera línea del mensaje (start line), esta línea contiene el nombre del método, la URI SIP del AU al que se le está haciendo el requerimiento y la versión del protocolo separados por un espacio en blanco y finalizado con un fin de línea, los métodos son REGISTER para registrar la información de contacto, INVITE, ACK y CANCEL para el manejo de las sesiones, OPTIONS para hacer consultas sobre las capacidades del servidor. Estos métodos son los definidos en el RFC, pero pueden implementarse métodos propios.

Las respuestas a los requerimientos se envían especificando el código de la respuesta (status code), en la primera línea del mensaje de respuesta. Esta línea esta compuesta por la versión del protocolo, el status-code que corresponde a un número que puede ser entendido por la máquina y una frase que pueda ser entendida por las personas (status-phrase).

Los status-code se pueden organizar en distintos grupo, según cual sea la primera cifra de estos, existen 6 clases de status-code en SIP 2.0 estos son:

Mensajería instantánea

El siguiente ejemplo muestra el uso de la mensajería instantánea en SIP

Ilustración 3 Ejemplo de mensajería instantánea.

Se puede observar que el funcionamiento de la mensajería instantánea en SIP es muy simple, solo se envían mensajes con el método MESSAGE y se responde con un mensaje cuyo status code es 200 OK.

El contenido del mensaje MESSAGE puede ser el siguiente:

MESSAGE sip:s.possion@dist.probability.org SIP/2.0
Via SIP/2.0/TCP lecturehall21.academy.ru:5060;branch=z9hG4bK3gtr2
Max-Forwards: 70
To: M. Poisson <sip:s.possion@dist.probability.org>
From: P. L. Chebychev <sip:chebychev@academy.ru>;tag=4542
Call-ID: 9dkei93vjq1ei3
CSeq: 15 MESSAGE
Allow: ACK, INVITE, CANCEL, BYE, NOTIFY, SUBSCRIBE, MESSAGE
Content-Type: text/plain
Content-Length: 9

Hi There!

Mientras la respuesta es:

SIP/2.0 200 OK
Via SIP/2.0/TCP lecturehall21.academy.ru:5060;branch=z9hG4bK3gtr2;received=19.34.3.1
To: M. Poisson <sip:s.possion@dist.probability.org>;tag=2321
From: P. L. Chebychev <sip:chebychev@academy.ru>;tag=4542
Call-ID: 9dkei93vjq1ei3
CSeq: 15 MESSAGE
Content-Length: 0