Programmation SIP pour le développeur Java

Le protocole SIP (Session Initiation Protocol) est un protocole de contrôle (signalisation) développé par l'IETF (Internet Engineering Task Force) pour gérer les sessions IP multimédias interactives, y compris la téléphonie IP, la présence et la messagerie instantanée. La spécification de servlet SIP (Java Specification Request 116), développée via le Java Community Process, fournit un modèle de programmation API Java standard pour la fourniture de services SIP. Dérivé de l'architecture de servlet Java populaire de Java Platform, Enterprise Edition (Java EE est le nouveau nom de Sun pour J2EE), SIP Servlet apporte des capacités de développement d'applications Internet aux solutions SIP.

L'informatique et les télécommunications convergent. Les applications réseau-IT, généralement orientées données, fusionnent avec les applications de communication. Le nombre croissant de boutons Appelez-moi apparaissant sur les pages Web est un exemple de cette intégration. La spécification de servlet SIP apporte un modèle de programmation familier aux développeurs Java pour la création d'applications convergées. Cet article donne une introduction étape par étape sur la façon d'utiliser le servlet SIP pour créer un service de chat d'écho simple.

séance d'initiation au protocoles

Défini dans la demande de commentaires 3261, SIP est un protocole pour établir, modifier et terminer des sessions de communication IP multimédia. La figure 1 est un exemple simple d'utilisation de SIP pour établir un appel VoIP (Voice-over Internet Protocol):

Toutes les lignes blanches de la figure 1 représentent les communications SIP. L'appelant envoie une demande SIP INVITE pour inviter «l'appelé» à établir une session vocale. L'appelé répond d'abord par un message comportant un code d'état 180 pour indiquer que le téléphone sonne. Dès que le téléphone est décroché, une réponse avec un code d'état 200 est envoyée à l'appelant pour accepter l'invitation. L'appelant confirme avec un message ACK et la session est établie. Une fois la session établie, la conversation vocale numérisée réelle est généralement transmise via le protocole de transmission en temps réel (RTP) avec la session, comme l'indique la ligne rouge de la figure 1. Lorsque la conversation se termine, une demande SIP BYE est envoyée, suivie d'une réponse avec un code d'état 200 pour confirmer la fin de la session.

Voici un exemple de requête SIP INVITE et une réponse avec un code d'état 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)

Réponse 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)

Comme vous pouvez le voir, le format de SIP ressemble à HTTP. Cependant, comparé à HTTP, SIP est:

  • Responsable de la gestion des sessions. Le contenu multimédia réel, tel que les messages instantanés, la voix et la vidéo, peut ou non être transmis via SIP.
  • Asynchrone et avec état. Pour chaque demande SIP, il peut y avoir plusieurs réponses. Cela signifie que l'application doit traiter chaque message SIP dans un contexte d'état approprié.
  • Un protocole d'application qui peut s'exécuter à la fois sur un transport fiable et non fiable. Ainsi, l'application doit garantir la remise du message avec retransmission et acquittement du message.
  • Un protocole peer-to-peer où il n'y a pas de distinction claire entre client et serveur. Chaque côté doit être en mesure d'envoyer et de recevoir des demandes et des réponses.

Services basés sur SIP

Les services SIP sont des serveurs SIP qui offrent des services, tels que le routage de messages, vers des points de terminaison SIP, tels que des téléphones IP. Par exemple, dans la figure 2, le serveur d'enregistrement SIP et le serveur proxy offrent des services d'enregistrement et de proxy SIP pour aider les points d'extrémité SIP à se localiser et à communiquer entre eux.

La figure 2 illustre ce qui suit:

  1. L'appelé s'enregistre auprès du serveur du registraire en envoyant une demande REGISTER.
  2. Le serveur d'enregistrement accepte l'enregistrement, qui contient l'adresse du nom de l'appelé, en répondant avec un code d'état 200 OK.
  3. L'appelant demande d'établir une session de communication avec l'appelé en envoyant une demande INVITE au serveur proxy. Le contenu du message INVITE contient généralement la description de la session de communication que l'appelant souhaite établir, comme le type de média, la sécurité ou l'adresse IP. La description est généralement au format SDP (Session Description Protocol).
  4. Le serveur proxy recherche le serveur d'enregistrement pour connaître l'adresse actuelle de l'appelé. Notez que la recherche est un problème d'implémentation qui ne fait pas partie de SIP.
  5. Le serveur proxy transmet la demande INVITE de l'appelant à l'appelé en fonction de son adresse actuelle.
  6. L'appelé accepte l'invitation en répondant avec un code d'état 200 OK. La réponse 200 OK à une demande INVITE contient généralement la description de la session de communication que l'appelé peut établir avec l'appelant.
  7. Le serveur proxy transmet une réponse 200 OK de l'appelé à l'appelant.
  8. L'appelant confirme l'établissement de la session en envoyant un message ACK au serveur proxy. Le message ACK peut contenir l'accord final sur la session.
  9. À son tour, le serveur proxy transmet l'ACK à l'appelé. Ainsi, la prise de contact à trois est effectuée via le serveur proxy et une session est établie.
  10. Maintenant, la communication entre l'appelant et l'appelé se produit. Le protocole utilisé pour la communication peut être ou non SIP. Par exemple, les messages instantanés peuvent être transmis via SIP. Les conversations vocales sont généralement transmises via RTP.
  11. Maintenant, l'appelé termine la conversation et souhaite terminer la session en envoyant une demande BYE.
  12. L'appelant répond avec un code d'état 200 OK pour accepter la fin de session.

Dans le scénario ci-dessus, le serveur proxy SIP achemine simplement les messages vers l'adresse actuelle de l'appelé. Comme vous pouvez l'imaginer, des services de routage plus intéressants et intelligents peuvent se produire. Par exemple, le serveur proxy peut «suivre un utilisateur» en acheminant les messages vers des endroits où il peut être atteint, comme un téléphone portable, même si quelqu'un appelle sur son téléphone de bureau.

Servlet SIP

Définie dans la demande de spécification Java 116, la spécification de servlet SIP fournit un modèle de programmation conteneur-servlet pour les applications SIP. Puisqu'il est dérivé de l'architecture de servlet Java dans Java EE, JSR 116 apporte une approche familière de la création de services SIP aux développeurs Java EE.

Le tableau ci-dessous résume la similitude entre HTTPServletet SIPServlet.

Comparaison entre un servlet HTTP et SIP

  HTTP siroter
Classe de servlet HttpServlet SipServlet
Session HttpSession SipSession
Paquet d'application GUERRE SAR
Descripteur de déploiement web.xml sip.xml

Tout comme les servlets HTTP, les servlets SIP étendent la javax.servlet.sip.SipServletclasse, qui à son tour étend la javax.servlet.GenericServletclasse. Comme vous l'avez peut-être deviné, SipServletremplace la service(ServletRequest request, ServletResponse response)méthode pour gérer différents types de messages 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.

Des discussions plus avancées sur le SipSessioncycle de vie et sa relation avec le dialogue SIP dépassent la portée de cet article. Heureusement, le conteneur gère la majeure partie de la complexité, comme le cycle de vie et les transitions d'état, et SipSessionpeut simplement être utilisé comme stockage pour les données de session.

Un exemple complet: EchoServlet

L'EchoServlet est un servlet SIP qui peut faire écho aux messages instantanés que vous saisissez dans Windows Messenger: