Programación SIP para el desarrollador de Java

El Protocolo de inicio de sesión (SIP) es un protocolo de control (señalización) desarrollado por el Grupo de trabajo de ingeniería de Internet (IETF) para administrar sesiones IP multimedia interactivas, incluida la telefonía IP, la presencia y la mensajería instantánea. La Especificación de Servlet SIP (Solicitud de Especificación de Java 116), desarrollada a través del Proceso de la Comunidad de Java, proporciona un modelo de programación API de Java estándar para entregar servicios basados ​​en SIP. Derivado de la popular arquitectura de servlet Java de Java Platform, Enterprise Edition (Java EE es el nuevo nombre de Sun para J2EE), SIP Servlet trae capacidades de desarrollo de aplicaciones de Internet a las soluciones SIP.

Las tecnologías de la información y las telecomunicaciones están convergiendo. Las aplicaciones de TI de red, normalmente orientadas a datos, se están fusionando con aplicaciones de comunicación. El creciente número de botones Llámame que aparecen en las páginas web es un ejemplo de esta integración. La Especificación de servlet SIP ofrece un modelo de programación familiar a los desarrolladores de Java para crear aplicaciones convergentes. Este artículo ofrece una introducción paso a paso sobre cómo utilizar SIP Servlet para crear un servicio de chat de eco simple.

protocolo de Iniciacion de Sesion

Definido en la Solicitud de comentarios 3261, SIP es un protocolo para establecer, modificar y finalizar sesiones de comunicación IP multimedia. La Figura 1 es un ejemplo simple de cómo usar SIP para establecer una llamada VoIP (Voice-over Internet Protocol):

Todas las líneas blancas en la Figura 1 representan las comunicaciones SIP. La persona que llama envía una solicitud SIP INVITE para invitar al "destinatario" a establecer una sesión de voz. El destinatario de la llamada responde primero con un mensaje que tiene un código de estado 180 para indicar que el teléfono está sonando. Tan pronto como se atiende el teléfono, se envía una respuesta con un código de estado 200 a la persona que llama para que acepte la invitación. La persona que llama confirma con un mensaje ACK y se establece la sesión. Una vez que se establece la sesión, la conversación de voz digitalizada real generalmente se transmite a través del Protocolo de transmisión en tiempo real (RTP) con la sesión, como indica la línea roja en la Figura 1. Cuando finaliza la conversación, se envía una solicitud SIP BYE, seguida de una respuesta con un código de estado 200 para confirmar la finalización de la sesión.

A continuación, se muestra un ejemplo de una solicitud SIP INVITE y una respuesta con un código de estado 200 OK:

SIP INVITE request: INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP pc.caller.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Callee From: Caller ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 142
(content (SDP) is not shown)

Respuesta SIP 200 OK:

SIP/2.0 200 OK Via: SIP/2.0/UDP pc.caller.com;branch=z9hG4bK776asdhds;received=192.0.2.1 To: Callee ;tag=a6c85cf From: Caller ;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: Content-Type: application/sdp Content-Length: 131
(content (SDP) is not shown)

Como puede ver, el formato de SIP se parece a HTTP. Sin embargo, en comparación con HTTP, SIP es:

• Responsable de la gestión de sesiones. El contenido multimedia real, como mensajes instantáneos, voz y video, puede o no transmitirse a través de SIP.
• Asincrónico y con estado. Para cada solicitud SIP, podría haber varias respuestas. Esto significa que la aplicación tiene que procesar cada mensaje SIP dentro de un contexto de estado adecuado.
• Un protocolo de aplicación que puede ejecutarse tanto en transporte confiable como no confiable. Por tanto, la aplicación debe garantizar la entrega del mensaje con retransmisión y acuse de recibo.
• Un protocolo de igual a igual en el que no existe una distinción clara entre cliente y servidor. Cualquiera de las partes debe poder enviar y recibir solicitudes y respuestas.

Servicios basados ​​en SIP

Los servicios basados ​​en SIP son servidores SIP que ofrecen servicios, como enrutamiento de mensajes, a puntos finales SIP, como teléfonos IP. Por ejemplo, en la Figura 2, el servidor de registro SIP y el servidor proxy ofrecen registro SIP y servicios de proxy para ayudar a los terminales SIP a ubicarse y comunicarse entre sí.

La figura 2 ilustra lo siguiente:

1. El destinatario se registra en el servidor de registro enviando una solicitud de REGISTRO.
2. El servidor de registro acepta el registro, que contiene la dirección del nombre de la persona que llama, respondiendo con un código de estado 200 OK.
3. La persona que llama solicita establecer una sesión de comunicación con la persona que llama enviando una solicitud de INVITACIÓN al servidor proxy. El contenido del mensaje INVITE generalmente contiene la descripción de la sesión de comunicación que la persona que llama desea establecer, como el tipo de medio, la seguridad o la dirección IP. La descripción suele estar en formato de Protocolo de descripción de sesión (SDP).
4. El servidor proxy busca el servidor de registro para averiguar la dirección actual del destinatario. Tenga en cuenta que la búsqueda es un problema de implementación que no forma parte de SIP.
5. El servidor proxy reenvía la solicitud INVITE de la persona que llama a la persona que llama en función de su dirección actual.
6. El destinatario acepta la invitación respondiendo con un código de estado 200 OK. La respuesta 200 OK a una solicitud INVITE generalmente contiene la descripción de la sesión de comunicación que la persona que llama puede establecer con la persona que llama.
7. El servidor proxy envía una respuesta 200 OK de la persona que llama a la persona que llama.
8. La persona que llama confirma el establecimiento de la sesión enviando un mensaje ACK al servidor proxy. El mensaje ACK puede contener el acuerdo final de la sesión.
9. A su vez, el servidor proxy reenvía el ACK al destinatario. Por lo tanto, el protocolo de enlace de tres vías se completa a través del servidor proxy y se establece una sesión.
10. Ahora ocurre la comunicación entre la persona que llama y la persona que llama. El protocolo utilizado para la comunicación puede ser SIP o no. Por ejemplo, los mensajes instantáneos se pueden transmitir a través de SIP. Las conversaciones de voz se transmiten normalmente a través de RTP.
11. Ahora, el destinatario finaliza la conversación y desea finalizar la sesión enviando una solicitud BYE.
12. La persona que llama responde con un código de estado 200 OK para aceptar la terminación de la sesión.

En el escenario anterior, el servidor proxy SIP simplemente enruta los mensajes a la dirección actual del destinatario. Como puede imaginar, pueden suceder servicios de enrutamiento más interesantes e inteligentes. Por ejemplo, el servidor proxy puede "seguir a un usuario" enrutando los mensajes a un lugar donde se le pueda localizar, como un teléfono celular, incluso si alguien está llamando desde el teléfono de su oficina.

Servlet SIP

Definida en la Solicitud de especificación de Java 116, la Especificación de servlet SIP proporciona un modelo de programación de servlet-contenedor para aplicaciones SIP. Dado que se deriva de la arquitectura de servlet de Java en Java EE, JSR 116 ofrece un enfoque familiar para la creación de servicios SIP para los desarrolladores de Java EE.

La siguiente tabla resume la similitud entre HTTPServlety SIPServlet.

Comparación entre un servlet HTTP y SIP

HTTP sorbo Clase de servlet HttpServlet SipServlet Sesión HttpSession SipSession Paquete de aplicación GUERRA SAR Descriptor de implementación web.xml sip.xml

Al igual que los servlets HTTP, los servlets SIP amplían la javax.servlet.sip.SipServletclase, que a su vez amplía la javax.servlet.GenericServletclase. Como habrás adivinado, SipServletanula el service(ServletRequest request, ServletResponse response)método para manejar diferentes tipos de mensajes SIP.

Since SIP is asynchronous, only one of the request and response arguments in the service() method is valid; the other one is null. For example, if the incoming SIP message is a request, only the request is valid and the response is null, and vice versa. The default implementation of the SipServlet class dispatches requests to doXXX() methods and responses to doXXXResponse() methods with a single argument. For example, doInvite(SipServletRequest request) for a SIP invite request and doSuccessResponse(SipServletResponse response) for SIP 2xx class responses. Typically SIP servlets override doXXX() methods and/or doXXXResponse() methods to provide application logic.

How do you send SIP responses if there is no response object in the doXXX() methods? In SIP servlets, you must call one of the createResponse() methods in the javax.servlet.sip.SipServletRequest class to create a response object. Then, call the send() method on the response object to send the response.

How about creating a SIP request in a SIP servlet? There are two ways to create SIP requests: Call either one of the createRequest() methods on the SipSession class to create a SIP request within the session, or one of the createRequest() methods on javax.servlet.sip.SipFactory to create a SIP request within a new SipSession. To get an instance of SipFactory, you must call getAttribute("javax.servlet.sip.SipFactory") on the ServletContext class.

The SipFactory is a factory interface in the SIP Servlet API for creating various API abstractions, such as requests, address objects, and application sessions. One interesting object created by SipFactory is javax.servlet.sip.SipApplicationSession. The intention of JSR 116 is to create a unified servlet container that can run both an HTTP and a SIP servlet. SipApplicationSession provides a protocol-agnostic session object to store application data and correlate protocol-specific sessions, such as SipSession and HttpSession. Hopefully this concept will be adopted by future versions of the Servlet API to make it javax.servlet.ApplicationSession instead of javax.servlet.sip.SipApplicationSession.

The SipApplicationSession manages protocol-specific sessions like SipSession. The SipSession interface represents the point-to-point relationship between two SIP endpoints and roughly corresponds to a SIP dialog defined in Request for Comments 3261. SipSession is inherently more complicated than its HTTP counterpart due to SIP's asynchronous and unreliable nature mentioned above. For example, Figure 3 shows the SipSession state transitions defined in JSR 116:

Typically, an HttpSession is created when a user logs in and destroyed after logout. A SipSession typically represents one logical conversation, even if you have multiple conversations between the same endpoints. So SipSession is more dynamic and has a shorter lifespan.

Las discusiones más avanzadas sobre el SipSessionciclo de vida y su relación con el diálogo SIP van más allá del alcance de este artículo. Afortunadamente, el contenedor maneja la mayor parte de la complejidad, como el ciclo de vida y las transiciones de estado, y SipSessionpuede usarse simplemente como almacenamiento para los datos de sesión.

Un ejemplo completo: EchoServlet

El EchoServlet es un servlet SIP que puede hacer eco de los mensajes instantáneos que escribe en Windows Messenger: