SIP-programmering til Java-udvikleren

Session Initiation Protocol (SIP) er en kontrolprotokol (signalering) udviklet af Internet Engineering Task Force (IETF) til at styre interaktive multimedie-IP-sessioner, herunder IP-telefoni, tilstedeværelse og instant messaging. SIP Servlet Specification (Java Specification Request 116), udviklet gennem Java Community Process, giver en standard Java API programmeringsmodel til levering af SIP-baserede tjenester. Afledt af den populære Java-servletarkitektur på Java Platform, Enterprise Edition (Java EE er Suns nye navn til J2EE), bringer SIP Servlet SIP-løsninger til udvikling af internetapplikationer.

IT og telekom er sammenfaldende. Netværk-it-applikationer, typisk dataorienterede, fusionerer med kommunikationsapplikationer. Det stigende antal Call Me-knapper, der vises på websider, er et eksempel på denne integration. SIP Servlet Specification giver en velkendt programmeringsmodel til Java-udviklere til opbygning af konvergerede applikationer. Denne artikel giver en trinvis introduktion til, hvordan du bruger SIP Servlet til at opbygge en simpel ekko chat-tjeneste.

Sessionsinitieringsprotokol

Defineret i anmodning om kommentarer 3261, SIP er en protokol til etablering, ændring og afslutning af multimedie-IP-kommunikationssessioner. Figur 1 er et simpelt eksempel på brug af SIP til at etablere et VoIP-opkald (voice-over Internet Protocol):

Alle de hvide linjer i figur 1 repræsenterer SIP-kommunikationen. Opkalder sender en SIP INVITE-anmodning om at invitere "callee" til at etablere en stemmesession. Callee svarer først med en besked, der har en 180-statuskode for at indikere, at telefonen ringer. Så snart telefonen er hentet, sendes et svar med en 200-statuskode til den, der ringer op for at acceptere invitationen. Opkald bekræfter med en ACK-besked, og sessionen oprettes. Når sessionen er oprettet, transmitterer den faktiske digitaliserede stemmesamtale typisk via Realtime Transmission Protocol (RTP) med sessionen, som den røde linje i figur 1 indikerer. Når samtalen slutter, sendes en SIP BYE-anmodning efterfulgt af et svar med en 200 statuskode for at bekræfte sessionens afslutning.

Her er et eksempel på en SIP INVITE-anmodning og et svar med en 200 OK-statuskode:

SIP INVITE-anmodning: INVITE sip: [email protected] SIP / 2.0 Via: SIP / 2.0 / UDP pc.caller.com; branch = z9hG4bK776asdhds Max-forward: 70 To: Callee From: Caller; tag = 1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Kontakt: Content-Type: application / sdp Content-Length: 142
(indhold (SDP) vises ikke)

SIP 200 OK svar:

SIP / 2.0 200 OK Via: SIP / 2.0 / UDP pc.caller.com; branch = z9hG4bK776asdhds; modtaget = 192.0.2.1 Til: Callee; tag = a6c85cf Fra: Caller; tag = 1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Kontakt: Indholdstype: applikation / sdp Indholdslængde: 131
(indhold (SDP) vises ikke)

Som du kan se, ligner SIP-formatet HTTP. Sammenlignet med HTTP er SIP imidlertid:

Ansvarlig for session management. Det faktiske multimedieindhold, såsom onlinemeddelelser, stemme og video, overføres muligvis eller ikke via SIP.
Asynkron og stateful. For hver SIP-anmodning kan der være flere svar. Dette betyder, at applikationen skal behandle hver SIP-besked i en korrekt tilstandskontekst.
En applikationsprotokol, der kan køre på både pålidelig og upålidelig transport. Således skal applikationen garantere meddelelseslevering med genudsendelse og bekræftelse af meddelelse.
En peer-to-peer-protokol, hvor der ikke er nogen klar skelnen mellem klient og server. Hver af siderne skal kunne sende og modtage anmodninger og svar.

SIP-baserede tjenester

SIP-baserede tjenester er SIP-servere, der tilbyder tjenester, såsom meddelelsesrute, til SIP-slutpunkter, såsom IP-telefoner. For eksempel i figur 2 tilbyder SIP-registrarserveren og proxyserveren SIP-registrering og proxytjenester for at hjælpe SIP-slutpunkterne med at lokalisere og kommunikere med hinanden.

Figur 2 illustrerer følgende:

Callee registrerer sig selv på registrarserveren ved at sende en REGISTER-anmodning.
Registratorserveren accepterer registreringen, som indeholder callee's navneadresse, ved at svare med en 200 OK statuskode.
Opkald anmoder om at etablere en kommunikationssession med callee ved at sende en INVITE-anmodning til proxyserveren. INVITE-meddelelsens indhold indeholder typisk beskrivelsen af den kommunikationssession, som den, der ringer op, ønsker at etablere, såsom medietype, sikkerhed eller IP-adresse. Beskrivelsen er typisk i SDP-format (Session Description Protocol).
Proxy-serveren ser op på registrarserveren for at finde ud af callee's aktuelle adresse. Bemærk, at opslag er et implementeringsproblem, der ikke er en del af SIP.
Proxy-serveren videresender INVITE-anmodningen fra den, der ringer til callee baseret på dens aktuelle adresse.
Callee accepterer invitationen ved at svare med en 200 OK statuskode. 200 OK-svaret på en INVITE-anmodning indeholder typisk beskrivelsen af den kommunikationssession, som callee kan etablere med den, der ringer op.
Proxy-serveren videresender et svar på 200 OK fra callee til den, der ringer op.
Opkalderen bekræfter sessionens etablering ved at sende en ACK-besked til proxyserveren. ACK-meddelelsen kan indeholde den endelige aftale om sessionen.
Til gengæld videresender proxyserveren ACK til callee. Således afsluttes trevejshåndtrykket via proxyserveren, og der oprettes en session.
Nu sker kommunikationen mellem opkalderen og callee. Protokollen, der bruges til kommunikation, er muligvis SIP. For eksempel kan onlinemeddelelser overføres via SIP. Stemmesamtaler transmitteres typisk via RTP.
Nu afslutter callee samtalen og ønsker at afslutte sessionen ved at sende en BYE-anmodning.
Opkalderen svarer med en 200 OK statuskode for at acceptere sessionens afslutning.

I ovenstående scenario dirigerer SIP-proxyserveren simpelthen meddelelserne til callee's aktuelle adresse. Som du kan forestille dig, kan der ske mere interessante og smarte routingtjenester. For eksempel kan proxyserveren "følge en bruger" ved at dirigere beskederne, hvor han kan nås, f.eks. En mobiltelefon, selvom nogen ringer til sin kontortelefon.

SIP Servlet

SIP Servlet Specification er defineret i Java-specifikationsanmodning 116 og giver en container-servlet-programmeringsmodel til SIP-applikationer. Da det er afledt af Java-servletarkitekturen i Java EE, bringer JSR 116 en velkendt tilgang til opbygning af SIP-tjenester til Java EE-udviklere.

Tabellen nedenfor opsummerer ligheden mellem HTTPServlet og SIPServlet.

Sammenligning mellem en HTTP- og SIP-servlet

	HTTP	nippe til
Servlet klasse	`HttpServlet`	`SipServlet`
Session	`HttpSession`	`SipSession`
Ansøgningspakke	KRIG	SAR
Implementeringsbeskrivelse	web.xml	sip.xml

Meget som HTTP-servlets udvider SIP-servlets javax.servlet.sip.SipServlet klasse, som igen udvider javax.servlet.GenericServlet klasse. Som du måske har gættet, SipServlet tilsidesætter service (ServletRequest anmodning, ServletResponse svar) metode til at håndtere forskellige typer SIP-meddelelser.

Da SIP er asynkron, er kun en af anmodnings- og svarargumenterne i service() metoden er gyldig; den anden er nul. For eksempel, hvis den indgående SIP-meddelelse er en anmodning, er kun anmodningen gyldig, og svaret er nul og omvendt. Standardimplementeringen af SipServlet klasse sender anmodninger til doXXX () metoder og svar på doXXXResponse () metoder med et enkelt argument. For eksempel, doInvite (SipServletRequest anmodning) for en anmodning om SIP-invitation og doSuccessResponse (SipServletResponse respons) til SIP 2xx klassesvar. Typisk tilsidesætter SIP-servlets doXXX () metoder og / eller doXXXResponse () metoder til at give applikationslogik.

Hvordan sender du SIP-svar, hvis der ikke er noget svarobjekt i doXXX () metoder? I SIP-servlets skal du ringe til et af createResponse () metoder i javax.servlet.sip.SipServletRequest klasse for at oprette et svarobjekt. Ring derefter til sende() metode på svarobjektet for at sende svaret.

Hvad med at oprette en SIP-anmodning i en SIP-servlet? Der er to måder at oprette SIP-anmodninger på: Ring til en af createRequest () metoder til SipSession klasse for at oprette en SIP-anmodning inden for sessionen eller en af createRequest () metoder til javax.servlet.sip.SipFactory at oprette en SIP-anmodning inden for en ny SipSession. For at få en forekomst af SipFactory, skal du ringe getAttribute ("javax.servlet.sip.SipFactory") på den ServletContext klasse.

Det SipFactory er en fabriksgrænseflade i SIP Servlet API til oprettelse af forskellige API-abstraktioner, såsom anmodninger, adresseobjekter og applikationssessioner. Et interessant objekt skabt af SipFactory er javax.servlet.sip.SipApplicationSession. Hensigten med JSR 116 er at oprette en samlet servletcontainer, der kan køre både en HTTP og en SIP-servlet. SipApplicationSession giver et protokolagnostisk sessionsobjekt til at gemme applikationsdata og korrelere protokolspecifikke sessioner, såsom SipSession og HttpSession. Forhåbentlig vil dette koncept blive vedtaget af fremtidige versioner af Servlet API for at gøre det javax.servlet.ApplicationSession i stedet for javax.servlet.sip.SipApplicationSession.

Det SipApplicationSession administrerer protokolspecifikke sessioner som SipSession. Det SipSession interface repræsenterer punkt-til-punkt-forholdet mellem to SIP-slutpunkter og svarer omtrent til en SIP-dialog, der er defineret i Anmodning om kommentarer 3261. SipSession er i sagens natur mere kompliceret end dets HTTP-modstykke på grund af SIP's asynkrone og upålidelige karakter nævnt ovenfor. For eksempel viser figur 3 SipSession tilstandsovergange defineret i JSR 116:

Typisk er en HttpSession oprettes, når en bruger logger ind og ødelægges efter logout. EN SipSession repræsenterer typisk en logisk samtale, selvom du har flere samtaler mellem de samme slutpunkter. Så SipSession er mere dynamisk og har en kortere levetid.

Mere avancerede diskussioner af SipSession livscyklus og dets forhold til SIP-dialog rækker ud over denne artikels anvendelsesområde. Heldigvis håndterer containeren det meste af kompleksiteten, såsom livscyklus og tilstandsovergange, og SipSession kan simpelthen bruges som lagring af sessionsdata.