Programování

Programování SIP pro vývojáře Java

Session Initiation Protocol (SIP) je kontrolní (signalizační) protokol vyvinutý Internet Engineering Task Force (IETF) pro správu interaktivních multimediálních IP relací včetně IP telefonie, přítomnosti a okamžitých zpráv. Specifikace SIP Servlet (Java Specification Request 116), vyvinutá v rámci Java Community Process, poskytuje standardní programovací model Java API pro poskytování služeb založených na SIP. SIP Servlet, odvozený od populární architektury servletů Java platformy Java Platform, Enterprise Edition (Java EE je nový název Sunu pro J2EE), přináší do řešení SIP řešení pro vývoj internetových aplikací.

IT a telekomunikace se sbližují. Network-IT aplikace, obvykle datově orientované, se slučují s komunikačními aplikacemi. Příkladem této integrace je rostoucí počet tlačítek Zavolej mi, která se objevují na webových stránkách. Specifikace SIP Servlet přináší vývojářům Java známý programovací model pro vytváření konvergovaných aplikací. Tento článek poskytuje podrobný úvod o tom, jak pomocí SIP Servlet vytvořit jednoduchou echo chatovou službu.

Protokol zahájení relace

Definovaný v požadavku na komentář 3261, SIP je protokol pro vytváření, úpravu a ukončení multimediálních IP komunikačních relací. Obrázek 1 je jednoduchý příklad použití SIP k navázání volání VoIP (Voice-over Internet Protocol):

Všechny bílé čáry na obrázku 1 představují komunikaci SIP. Volající odešle požadavek SIP INVITE na pozvání volaného k navázání hlasové relace. Callee nejprve odpoví zprávou, která má stavový kód 180, což znamená, že telefon zvoní. Jakmile je telefon zvednut, je volajícímu odeslána odpověď se stavovým kódem 200, aby přijal pozvání. Volající potvrdí zprávou ACK a relace je navázána. Jakmile je relace navázána, skutečná digitalizovaná hlasová konverzace se obvykle přenáší přes Realtime Transmission Protocol (RTP) s relací, jak naznačuje červená čára na obrázku 1. Když konverzace končí, odešle se požadavek SIP BYE, následovaný odpovědí se stavovým kódem 200 k potvrzení ukončení relace.

Zde je příklad požadavku SIP INVITE a odpovědi se stavovým kódem 200 OK:

SIP INVITE požadavek: INVITE sip: [email protected] SIP / 2.0 Via: SIP / 2.0 / UDP pc.caller.com; branch = z9hG4bK776asdhds Max-Forwards: 70 Komu: Callee Od: Caller; tag = 1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 POZVAT Kontakt: Typ obsahu: aplikace / sdp Délka obsahu: 142

(obsah (SDP) se nezobrazí)

SIP 200 OK odpověď:

SIP / 2.0 200 OK Přes: SIP / 2.0 / UDP pc.caller.com; větev = z9hG4bK776asdhds; přijato = 192.0.2.1 Komu: Callee; tag = a6c85cf Od: Caller; tag = 1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Kontakt: Typ obsahu: aplikace / sdp Délka obsahu: 131

(obsah (SDP) se nezobrazí)

Jak vidíte, formát SIP se podobá protokolu HTTP. Ve srovnání s HTTP je však SIP:

  • Odpovědný za správu relace. Skutečný multimediální obsah, jako jsou rychlé zprávy, hlasové zprávy a videa, může nebo nemusí být přenášen prostřednictvím protokolu SIP.
  • Asynchronní a stavové. Na každý požadavek SIP může být více odpovědí. To znamená, že aplikace musí zpracovávat každou SIP zprávu ve správném kontextu stavu.
  • Aplikační protokol, který lze spustit na spolehlivém i nespolehlivém přenosu. Aplikace tedy musí zaručit doručení zprávy opětovným přenosem a potvrzením zprávy.
  • Protokol peer-to-peer, kde není jasný rozdíl mezi klientem a serverem. Každá strana musí být schopna odesílat a přijímat žádosti a odpovědi.

Služby založené na protokolu SIP

Služby založené na SIP jsou servery SIP, které nabízejí služby, jako je směrování zpráv, na koncové body SIP, jako jsou IP telefony. Například na obrázku 2 nabízí registrační server SIP a proxy server registraci SIP a služby proxy, které pomáhají koncovým bodům SIP najít a komunikovat mezi sebou.

Obrázek 2 ilustruje následující:

  1. Callee se zaregistruje na server registrátora zasláním požadavku REGISTRACE.
  2. Server registrátora přijímá registraci, která obsahuje volanou adresu, odpovědí stavovým kódem 200 OK.
  3. Volající požádá o navázání komunikační relace s volaným odesláním požadavku INVITE na server proxy. Obsah zprávy INVITE obvykle obsahuje popis komunikační relace, kterou chce volající navázat, například typ média, zabezpečení nebo IP adresa. Popis je obvykle ve formátu Session Description Protocol (SDP).
  4. Server proxy vyhledá server registrátora a zjistí aktuální adresu volaného. Všimněte si, že vyhledávání je problém implementace, který není součástí SIP.
  5. Proxy server přeposílá požadavek INVITE od volajícího na volání na základě jeho aktuální adresy.
  6. Callee přijme pozvání odpovědí stavovým kódem 200 OK. Odpověď 200 OK na požadavek INVITE obvykle obsahuje popis komunikační relace, kterou může volající navázat s volajícím.
  7. Proxy server přepošle 200 OK odpověď od volaného volajícímu.
  8. Volající potvrdí vytvoření relace odesláním zprávy ACK na server proxy. Zpráva ACK může obsahovat konečnou dohodu o relaci.
  9. Na druhé straně proxy server předá ACK volanému. Trojcestné handshake je tedy dokončeno přes proxy server a je navázána relace.
  10. Nyní probíhá komunikace mezi volajícím a volaným. Protokol používaný pro komunikaci může, ale nemusí být SIP. Okamžité zprávy lze například přenášet přes SIP. Hlasové konverzace se obvykle přenášejí přes RTP.
  11. Nyní Callee dokončí konverzaci a přeje si ukončit relaci zasláním požadavku BYE.
  12. Volající odpoví stavovým kódem 200 OK, aby přijal ukončení relace.

Ve výše uvedeném scénáři server SIP proxy jednoduše směruje zprávy na aktuální adresu volaného. Jak si dokážete představit, mohou nastat zajímavější a chytřejší služby směrování. Například proxy server může „sledovat uživatele“ tím, že směruje zprávy tam, kde je zastižitelný, například na mobilní telefon, i když někdo volá na jeho pracovním telefonu.

SIP servlet

Definováno v požadavku 116 na specifikaci Java, specifikace SIP Servlet poskytuje model programování kontejner-servlet pro aplikace SIP. JSR 116 je odvozen z architektury servletů Java v prostředí Java EE a přináší vývojářům prostředí Java EE známý přístup k vytváření služeb SIP.

Níže uvedená tabulka shrnuje podobnost mezi HTTPServlet a SIPServlet.

Porovnání servletu HTTP a SIP

 HTTP SIP
Třída servletůHttpServletSipServlet
ZasedáníHttpSessionSipSession
Balíček aplikaceVÁLKASAR
Deskriptor nasazeníweb.xmlsip.xml

Stejně jako servlety HTTP rozšiřují SIP servlety javax.servlet.sip.SipServlet třída, což zase rozšiřuje javax.servlet.GenericServlet třída. Jak jste možná uhodli, SipServlet přepíše služba (požadavek ServletRequest, odpověď ServletResponse) metoda pro zpracování různých typů zpráv SIP.

Protože SIP je asynchronní, pouze jeden z argumentů požadavku a odpovědi v servis() metoda je platná; druhý je nulový. Pokud je například příchozí zpráva SIP požadavek, je platný pouze požadavek a odpověď je nulová a naopak. Výchozí implementace SipServlet třída odesílá požadavky do doXXX () metody a reakce na doXXXResponse () metody s jediným argumentem. Například, doInvite (požadavek SipServletRequest) pro žádost o pozvání SIP a doSuccessResponse (odpověď SipServletResponse) pro odpovědi třídy SIP 2xx. Typicky přepisují SIP servlety doXXX () metody a / nebo doXXXResponse () metody zajišťující logiku aplikace.

Jak odesíláte odpovědi SIP, pokud v souboru není žádný objekt odpovědi doXXX () metody? V servletech SIP musíte zavolat jednomu z createResponse () metody v javax.servlet.sip.SipServletRequest třídy k vytvoření objektu odpovědi. Poté zavolejte poslat() metoda na objektu odpovědi k odeslání odpovědi.

Co takhle vytvořit požadavek SIP v servletu SIP? Existují dva způsoby, jak vytvořit požadavky SIP: Volejte některý z uživatelů createRequest () metody na SipSession třídy k vytvoření požadavku SIP v rámci relace nebo jedné z createRequest () metody na javax.servlet.sip.SipFactory vytvořit požadavek SIP v novém SipSession. Chcete-li získat instanci SipFactory, musíte zavolat getAttribute ("javax.servlet.sip.SipFactory") na ServletContext třída.

The SipFactory je tovární rozhraní v SIP Servlet API pro vytváření různých abstrakcí API, jako jsou požadavky, objekty adres a relace aplikace. Jeden zajímavý objekt vytvořil SipFactory je javax.servlet.sip.SipApplicationSession. Záměrem JSR 116 je vytvořit jednotný kontejner servletu, který může spouštět servlet HTTP i SIP. SipApplicationSession poskytuje objekt protokolu-agnostické relace pro ukládání dat aplikace a korelaci relací specifických pro protokol, například SipSession a HttpSession. Doufejme, že tento koncept bude přijat budoucími verzemi Servlet API, aby byl vytvořen javax.servlet.ApplicationSession namísto javax.servlet.sip.SipApplicationSession.

The SipApplicationSession spravuje relace specifické pro protokol jako SipSession. The SipSession interface představuje vztah point-to-point mezi dvěma koncovými body SIP a zhruba odpovídá dialogu SIP definovanému v Request for Comments 3261. SipSession je ze své podstaty komplikovanější než jeho protějšek HTTP kvůli výše uvedené asynchronní a nespolehlivé povaze SIP. Například obrázek 3 ukazuje SipSession přechody stavu definované v JSR 116:

Typicky, HttpSession je vytvořen, když se uživatel přihlásí a po odhlášení je zničen. A SipSession obvykle představuje jednu logickou konverzaci, i když máte více konverzací mezi stejnými koncovými body. Tak SipSession je dynamičtější a má kratší životnost.

Pokročilejší diskuse o SipSession životní cyklus a jeho vztah k dialogu SIP přesahuje rámec tohoto článku. Naštěstí kontejner zvládá většinu složitosti, například přechody životního cyklu a stavu, a SipSession lze jednoduše použít jako úložiště pro data relace.

Úplný příklad: EchoServlet

EchoServlet je servlet SIP, který může odrážet okamžité zprávy, které zadáváte v programu Windows Messenger:

$config[zx-auto] not found$config[zx-overlay] not found