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
Un aspecto importante de los equipos
móviles de última generación es su capacidad de procesamiento, esto
permite que estos equipos se puedan utilizar como herramientas de
trabajo.
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 es una sigla de Session Initation
Protocol o protocolo de inicio de sesión. SIP es un protocolo de
señalización que se utiliza para iniciar sesiones interactivas
multimedia entre usuarios de redes IP. Normalmente estas sesiones
pueden ser de mensajería instantánea, en aplicaciones como MSN
Messenger, o de telefonía como la Voz sobre IP.
Este protocolo, como muchos otros, está definido dentro de la base de
datos del RFC, siendo un protocolo libre con posibilidad de incorporar
nuevas aplicaciones. SIP esta limitado solo a la configuración,
modificación y término de la sesión. Entre las características
principales de SIP están:
- 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.
Dadas las posibilidades que brinda este protocolo es factible y muy
rentable la implementación de su stack, debido al número de posibles
usuarios desarrollar una aplicación para plataformas móviles.
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:
INVITE |
Inicio de Sesión (setup) |
ACK |
Reconocimiento de Invite |
BYE |
Terminación de sesión |
CANCEL |
Cancelación de Invite |
REGISTER |
Registro de URL |
OPTIONS |
Preguntar por opciones y capacidades |
INFO |
Transporte de información en llamada |
PRACK |
Reconocimiento Provisional |
COMET |
Notificación de precondición |
REFER |
Transferencia a otra URL |
SUSCRIBE |
Requerir notificación de Evento |
UNSUSCRIBE |
Cancelar notificación de Evento |
NOTIFY |
Notificación de Evento |
MESSAGE |
Mensaje Instantáneo |
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:
1xx |
Provisiona |
El requerimiento ha sido
recibido y se continúa su procesamiento |
2xx |
Success |
La acción fue satisfactoriamente recibida,
entendida y aceptada |
3xx |
Redirection |
Se necesitan ser llevadas acciones
adicionales para llevar a cabo el requerimiento |
4xx |
Client Error |
El requerimiento contiene una mala sintaxis
que no permite que pueda ser procesado |
5xx |
Server Error |
El servidor no ha podido procesar un
requerimiento aparentemente correcto |
6xx |
Global Failure |
El requerimiento no puede ser procesado en
ningún servidor |
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
|