Session Initiation Protocol (SIP) er en kontrollprotokoll (signalering) utviklet av Internet Engineering Task Force (IETF) for å administrere interaktive IP-økter med multimedia, inkludert IP-telefoni, tilstedeværelse og direktemeldinger. SIP Servlet Specification (Java Specification Request 116), utviklet gjennom Java Community Process, gir en standard Java API programmeringsmodell for å levere SIP-baserte tjenester. SIP Servlet er hentet fra den populære Java-servletarkitekturen til Java Platform, Enterprise Edition (Java EE er Suns nye navn for J2EE), og gir SIP-løsninger utviklingsfunksjoner for Internett-applikasjoner.
IT og telekom nærmer seg. Nettverk-IT-applikasjoner, vanligvis dataorientert, smelter sammen med kommunikasjonsapplikasjoner. Det økende antall Call Me-knappene som vises på websidene er et eksempel på denne integrasjonen. SIP Servlet Specification gir en kjent programmeringsmodell til Java-utviklere for å bygge konvergerte applikasjoner. Denne artikkelen gir en trinnvis introduksjon om hvordan du bruker SIP Servlet til å bygge en enkel ekko chat-tjeneste.
Session Initiation Protocol
Definert i Forespørsel om kommentarer 3261, er SIP en protokoll for å etablere, endre og avslutte multimedia IP-kommunikasjonssessioner. Figur 1 er et enkelt eksempel på bruk av SIP til å opprette en VoIP-samtale:
Alle de hvite linjene i figur 1 representerer SIP-kommunikasjonen. Caller sender en SIP INVITE-forespørsel om å invitere "callee" til å etablere en talesession. Callee svarer først med en melding som har en 180-statuskode for å indikere at telefonen ringer. Så snart telefonen er hentet, sendes et svar med 200 statuskode til den som ringer for å godta invitasjonen. Oppringeren bekrefter med en ACK-melding, og økten er opprettet. Når økten er etablert, overføres den faktiske digitaliserte talesamtalen vanligvis via RTP (Realtime Transmission Protocol) med økten, slik den røde linjen i figur 1 indikerer. Når samtalen avsluttes, sendes en SIP BYE-forespørsel, etterfulgt av et svar med en 200 statuskode for å bekrefte avslutningen av økten.
Her er et eksempel på en SIP INVITE-forespørsel og et svar med en 200 OK-statuskode:
SIP INVITE forespørsel: 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 Kontakt: Content-Type: application / sdp Content-Length: 142
(innhold (SDP) vises ikke)
SIP 200 OK svar:
SIP / 2.0 200 OK Via: SIP / 2.0 / UDP pc.caller.com; branch = z9hG4bK776asdhds; mottatt = 192.0.2.1 Til: Callee; tag = a6c85cf Fra: Caller; tag = 1928301774 Ring-ID: a84b4c76e66710 CSeq: 314159 INVITE Kontakt: Innholdstype: applikasjon / sdp Innholdslengde: 131
(innhold (SDP) vises ikke)
Som du kan se, ligner SIP-formatet HTTP. Imidlertid, sammenlignet med HTTP, er SIP:
- Ansvarlig for øktledelse. Det faktiske multimediainnholdet, for eksempel direktemeldinger, tale og video, kan eller ikke overføres via SIP.
- Asynkron og statelig. For hver SIP-forespørsel kan det være flere svar. Dette betyr at applikasjonen må behandle hver SIP-melding i riktig tilstandskontekst.
- En applikasjonsprotokoll som kan kjøres både pålitelig og upålitelig transport. Dermed må søknaden garantere levering av meldinger med melding på nytt og bekreftelse.
- En peer-to-peer-protokoll der det ikke er noe klart skille mellom klient og server. Hver av sidene må kunne sende og motta forespørsler og svar.
SIP-baserte tjenester
SIP-baserte tjenester er SIP-servere som tilbyr tjenester, for eksempel meldingsruting, til SIP-endepunkter, for eksempel IP-telefoner. For eksempel, i figur 2, tilbyr SIP-registrarserveren og proxy-serveren SIP-registrering og proxy-tjenester for å hjelpe SIP-endepunktene med å finne og kommunisere med hverandre.
Figur 2 illustrerer følgende:
- Callee registrerer seg selv til registrarserveren ved å sende en REGISTER-forespørsel.
- Registrarserveren godtar registreringen, som inneholder navnet på adressen, ved å svare med en 200 OK-statuskode.
- Ringer ber om å etablere en kommunikasjonsøkt med callee ved å sende en INVITE-forespørsel til proxy-serveren. INVITE-meldingens innhold inneholder vanligvis beskrivelsen av kommunikasjonssessionen innringeren ønsker å opprette, for eksempel mediatype, sikkerhet eller IP-adresse. Beskrivelsen er vanligvis i SDP-format (Session Description Protocol).
- Fullmaktsserveren slår opp registrarserveren for å finne ut den nåværende adressen til callee. Merk at oppslag er et implementeringsproblem som ikke er en del av SIP.
- Fullmaktsserveren videresender INVIT-forespørselen fra innringer til callee basert på den nåværende adressen.
- Callee godtar invitasjonen ved å svare med en 200 OK-statuskode. 200 OK-svaret på en INVITE-forespørsel inneholder vanligvis beskrivelsen av kommunikasjonsøkten som callee kan opprette med innringeren.
- Fullmaktsserveren videresender et svar på 200 OK fra callee til den som ringer.
- Oppringeren bekrefter sesjonsopprettelsen ved å sende en ACK-melding til proxy-serveren. ACK-meldingen kan inneholde den endelige avtalen om økten.
- I sin tur videresender proxy-serveren ACK til callee. Dermed fullføres treveishåndtrykket via proxy-serveren, og en økt opprettes.
- Nå skjer kommunikasjonen mellom innringer og callee. Protokollen som brukes til kommunikasjon kan være SIP. For eksempel kan direktemeldinger overføres via SIP. Talesamtaler overføres vanligvis via RTP.
- Nå avslutter callee samtalen og ønsker å avslutte økten ved å sende en BYE-forespørsel.
- Oppringeren svarer med en 200 OK-statuskode for å godta øktavslutning.
I scenariet ovenfor dirigerer SIP proxy-serveren bare meldingene til callee nåværende adresse. Som du kan forestille deg, kan mer interessante og smarte rutetjenester skje. For eksempel kan proxy-serveren "følge en bruker" ved å dirigere meldingene dit han kan nås, for eksempel en mobiltelefon, selv om noen ringer på kontortelefonen hans.
SIP Servlet
SIP Servlet Specification er definert i Java-spesifikasjonsforespørsel 116 og gir en container-servlet-programmeringsmodell for SIP-applikasjoner. Siden den er hentet fra Java-servlettarkitekturen i Java EE, gir JSR 116 en kjent tilnærming til å bygge SIP-tjenester til Java EE-utviklere.
Tabellen nedenfor oppsummerer likheten mellom HTTPServlet og SIPServlet.
Sammenligning mellom en HTTP og SIP-servlet
|
I likhet med HTTP-servlets utvider SIP-servlets javax.servlet.sip.SipServlet klasse, som igjen utvider javax.servlet.GenericServlet klasse. Som du kanskje har gjettet, SipServlet overstyrer service (ServletRequest forespørsel, ServletResponse svar) metode for å håndtere forskjellige typer SIP-meldinger.
Siden SIP er asynkron, er bare ett av forespørselen og svarargumentene i service() metoden er gyldig; den andre er null. For eksempel, hvis den innkommende SIP-meldingen er en forespørsel, er bare forespørselen gyldig og svaret er null, og omvendt. Standard implementering av SipServlet klasse sender forespørsler til doXXX () metoder og svar på doXXXResponse () metoder med et enkelt argument. For eksempel, doInvite (SipServletRequest forespørsel) for en SIP invitasjonsforespørsel og doSuccessResponse (SipServletResponse respons) for SIP 2xx klassesvar. Vanligvis overstyrer SIP-servlets doXXX () metoder og / eller doXXXResponse () metoder for å gi applikasjonslogikk.
Hvordan sender du SIP-svar hvis det ikke er noe svarobjekt i doXXX () metoder? I SIP-servlets må du ringe en av createResponse () metoder i javax.servlet.sip.SipServletRequest klasse for å lage et responsobjekt. Ring deretter sende() metode på responsobjektet for å sende svaret.
Hva med å opprette en SIP-forespørsel i en SIP-servlet? Det er to måter å lage SIP-forespørsler på: Ring til en av createRequest () metoder på SipSession klasse for å opprette en SIP-forespørsel i løpet av økten, eller en av createRequest () metoder på javax.servlet.sip.SipFactory for å opprette en SIP-forespørsel i en ny SipSession. For å få en forekomst av SipFactory, må du ringe getAttribute ("javax.servlet.sip.SipFactory") på ServletContext klasse.
De SipFactory er et fabrikkgrensesnitt i SIP Servlet API for å lage forskjellige API-abstraksjoner, for eksempel forespørsler, adresseobjekter og applikasjonsøkter. Et interessant objekt opprettet av SipFactory er javax.servlet.sip.SipApplicationSession. Hensikten med JSR 116 er å lage en enhetlig servletbeholder som kan kjøre både en HTTP og en SIP-servlet. SipApplicationSession gir et protokoll-agnostisk øktobjekt for å lagre applikasjonsdata og korrelere protokollspesifikke økter, for eksempel SipSession og HttpSession. Forhåpentligvis vil dette konseptet bli vedtatt av fremtidige versjoner av Servlet API for å gjøre det javax.servlet.ApplicationSession i stedet for javax.servlet.sip.SipApplicationSession.
De SipApplicationSession administrerer protokollspesifikke økter som SipSession. De SipSession grensesnitt representerer punkt-til-punkt-forholdet mellom to SIP-endepunkter og tilsvarer omtrent en SIP-dialog som er definert i Forespørsel om kommentarer 3261. SipSession er iboende mer komplisert enn HTTP-motstykke på grunn av SIPs asynkrone og upålitelige natur som nevnt ovenfor. For eksempel viser figur 3 SipSession tilstandsoverganger definert i JSR 116:
Vanligvis er en HttpSession opprettes når en bruker logger på og ødelegges etter utlogging. EN SipSession representerer vanligvis en logisk samtale, selv om du har flere samtaler mellom de samme endepunktene. Så SipSession er mer dynamisk og har kortere levetid.
Mer avanserte diskusjoner om SipSession livssyklus og dets forhold til SIP dialog går utover denne artikkelen. Heldigvis håndterer containeren det meste av kompleksiteten, for eksempel livssyklus og tilstandsoverganger, og SipSession kan ganske enkelt brukes som lagring for øktdata.
Et komplett eksempel: EchoServlet
EchoServlet er en SIP-servlet som kan ekko direktemeldingene du skriver i Windows Messenger:
