Programmazione SIP per lo sviluppatore Java

Session Initiation Protocol (SIP) è un protocollo di controllo (segnalazione) sviluppato dall'Internet Engineering Task Force (IETF) per gestire sessioni IP multimediali interattive tra cui telefonia IP, presenza e messaggistica istantanea. La SIP Servlet Specification (Java Specification Request 116), sviluppata tramite il Java Community Process, fornisce un modello di programmazione API Java standard per la fornitura di servizi basati su SIP. Derivato dalla popolare architettura servlet Java di Java Platform, Enterprise Edition (Java EE è il nuovo nome di Sun per J2EE), SIP Servlet offre funzionalità di sviluppo di applicazioni Internet alle soluzioni SIP.

IT e telecomunicazioni stanno convergendo. Le applicazioni IT di rete, tipicamente orientate ai dati, si stanno fondendo con le applicazioni di comunicazione. Il numero crescente di pulsanti di chiamata che appaiono sulle pagine Web è un esempio di questa integrazione. La specifica del servlet SIP offre agli sviluppatori Java un modello di programmazione familiare per la creazione di applicazioni convergenti. Questo articolo fornisce un'introduzione passo passo su come utilizzare SIP Servlet per creare un semplice servizio di chat echo.

Protocollo di Inizializzazione Sessione

Definito in Request for Comments 3261, SIP è un protocollo per stabilire, modificare e terminare le sessioni di comunicazione IP multimediale. La figura 1 è un semplice esempio di utilizzo di SIP per stabilire una chiamata VoIP (voice-over Internet Protocol):

Tutte le linee bianche nella Figura 1 rappresentano le comunicazioni SIP. Il chiamante invia una richiesta SIP INVITE per invitare il "chiamato" a stabilire una sessione vocale. Il destinatario della chiamata risponde prima con un messaggio che ha un codice di stato 180 per indicare che il telefono sta squillando. Non appena il telefono viene sollevato, una risposta con un codice di stato 200 viene inviata al chiamante per accettare l'invito. Il chiamante conferma con un messaggio ACK e la sessione viene stabilita. Una volta stabilita la sessione, l'effettiva conversazione vocale digitalizzata trasmette tipicamente tramite Realtime Transmission Protocol (RTP) con la sessione, come indica la linea rossa nella Figura 1. Al termine della conversazione, viene inviata una richiesta SIP BYE, seguita da una risposta con un codice di stato 200 per confermare la chiusura della sessione.

Di seguito è riportato un esempio di una richiesta SIP INVITE e una risposta con un codice di stato 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)

Risposta 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)

Come puoi vedere, il formato di SIP è simile a HTTP. Tuttavia, rispetto a HTTP, SIP è:

  • Responsabile della gestione delle sessioni. Il contenuto multimediale effettivo, come messaggi istantanei, voce e video, può o non può essere trasmesso tramite SIP.
  • Asincrono e stateful. Per ogni richiesta SIP, potrebbero esserci più risposte. Ciò significa che l'applicazione deve elaborare ogni messaggio SIP all'interno di un contesto di stato appropriato.
  • Un protocollo applicativo che può essere eseguito su un trasporto affidabile e inaffidabile. Pertanto, l'applicazione deve garantire la consegna del messaggio con la ritrasmissione e il riconoscimento del messaggio.
  • Un protocollo peer-to-peer in cui non esiste una chiara distinzione tra client e server. Entrambe le parti devono essere in grado di inviare e ricevere richieste e risposte.

Servizi basati su SIP

I servizi basati su SIP sono server SIP che offrono servizi, come il routing dei messaggi, a endpoint SIP, come i telefoni IP. Ad esempio, nella Figura 2, il server di registrazione SIP e il server proxy offrono la registrazione SIP ei servizi proxy per aiutare gli endpoint SIP a localizzarsi e comunicare tra loro.

La Figura 2 illustra quanto segue:

  1. Callee si registra al server di registrazione inviando una richiesta REGISTER.
  2. Il server di registrazione accetta la registrazione, che contiene l'indirizzo del nome del chiamato, rispondendo con un codice di stato 200 OK.
  3. Il chiamante richiede di stabilire una sessione di comunicazione con il chiamato inviando una richiesta INVITE al server proxy. Il contenuto del messaggio INVITE in genere contiene la descrizione della sessione di comunicazione che il chiamante desidera stabilire, come il tipo di supporto, la sicurezza o l'indirizzo IP. La descrizione è in genere nel formato SDP (Session Description Protocol).
  4. Il server proxy cerca il server di registrazione per scoprire l'indirizzo corrente del chiamato. Tieni presente che la ricerca è un problema di implementazione che non fa parte di SIP.
  5. Il server proxy inoltra la richiesta INVITE dal chiamante al chiamato in base al suo indirizzo corrente.
  6. Il destinatario della chiamata accetta l'invito rispondendo con un codice di stato 200 OK. La risposta 200 OK a una richiesta INVITE contiene in genere la descrizione della sessione di comunicazione che il chiamato può stabilire con il chiamante.
  7. Il server proxy inoltra una risposta 200 OK dal chiamato al chiamante.
  8. Il chiamante conferma l'istituzione della sessione inviando un messaggio ACK al server proxy. Il messaggio ACK può contenere l'accordo finale sulla sessione.
  9. A sua volta, il server proxy inoltra l'ACK al chiamato. Pertanto, l'handshake a tre vie viene completato tramite il server proxy e viene stabilita una sessione.
  10. Ora avviene la comunicazione tra chiamante e chiamato. Il protocollo utilizzato per la comunicazione può essere o meno SIP. Ad esempio, i messaggi istantanei possono essere trasmessi tramite SIP. Le conversazioni vocali vengono generalmente trasmesse tramite RTP.
  11. Ora, il chiamato termina la conversazione e desidera terminare la sessione inviando una richiesta BYE.
  12. Il chiamante risponde con un codice di stato 200 OK per accettare la chiusura della sessione.

Nello scenario precedente, il server proxy SIP instrada semplicemente i messaggi all'indirizzo corrente del chiamato. Come puoi immaginare, possono esserci servizi di routing più interessanti e intelligenti. Ad esempio, il server proxy può "seguire un utente" instradando i messaggi dove può essere raggiunto, ad esempio un telefono cellulare, anche se qualcuno sta chiamando sul telefono dell'ufficio.

Servlet SIP

Definita nella richiesta di specifica Java 116, la specifica servlet SIP fornisce un modello di programmazione contenitore-servlet per applicazioni SIP. Poiché deriva dall'architettura servlet Java in Java EE, JSR 116 offre agli sviluppatori Java EE un approccio familiare alla creazione di servizi SIP.

La tabella seguente riassume la somiglianza tra HTTPServlete SIPServlet.

Confronto tra un servlet HTTP e SIP

  HTTP SORSO
Classe servlet HttpServlet SipServlet
Sessione HttpSession SipSession
Pacchetto applicativo GUERRA SAR
Descrittore di distribuzione web.xml sip.xml

Proprio come i servlet HTTP, i servlet SIP estendono la javax.servlet.sip.SipServletclasse, che a sua volta estende la javax.servlet.GenericServletclasse. Come avrai intuito, SipServletsovrascrive il service(ServletRequest request, ServletResponse response)metodo per gestire diversi tipi di messaggi 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.

Discussioni più avanzate sul SipSessionciclo di vita e la sua relazione con il dialogo SIP vanno oltre lo scopo di questo articolo. Fortunatamente, il contenitore gestisce la maggior parte della complessità, come il ciclo di vita e le transizioni di stato, e SipSessionpuò essere semplicemente utilizzato come archiviazione per i dati di sessione.

Un esempio completo: EchoServlet

EchoServlet è un servlet SIP che può riprodurre i messaggi istantanei digitati in Windows Messenger: