SIP програмиране за разработчика на Java

Session Initiation Protocol (SIP) е контролен (сигнализиращ) протокол, разработен от Internet Engineering Task Force (IETF) за управление на интерактивни мултимедийни IP сесии, включително IP телефония, присъствие и незабавни съобщения. Спецификацията на SIP сървлети (Заявка за спецификация на Java 116), разработена чрез процеса на Java Community, предоставя стандартен модел за програмиране на Java API за предоставяне на базирани на SIP услуги. Произведен от популярната архитектура на Java сървлети на Java Platform, Enterprise Edition (Java EE е новото име на Sun за J2EE), SIP Servlet предлага възможности за разработване на интернет приложения за SIP решения.

ИТ и телекомът се сближават. Мрежовите ИТ приложения, обикновено ориентирани към данни, се сливат с комуникационни приложения. Нарастващият брой бутони за повикване, появяващи се на уеб страници, е пример за тази интеграция. Спецификацията SIP Servlet предоставя познат програмен модел на разработчиците на Java за изграждане на конвергирани приложения. Тази статия дава стъпка по стъпка въведение за това как да използвате SIP Servlet за изграждане на проста услуга за ехо чат.

Протокол за иницииране на сесия

Дефиниран в Искане за коментари 3261, SIP е протокол за установяване, модифициране и прекратяване на мултимедийни IP сесии за комуникация. Фигура 1 е прост пример за използване на SIP за установяване на повикване VoIP (гласов интернет протокол):

Всички бели линии на фигура 1 представляват SIP комуникациите. Повикващият изпраща заявка SIP INVITE, за да покани "повикания" да установи гласова сесия. Callee първо отговаря със съобщение, което има код на състоянието 180, за да покаже, че телефонът звъни. Веднага щом телефонът бъде вдигнат, на повикващия се изпраща отговор с код за състояние 200, за да приеме поканата. Повикващият потвърждава със съобщение ACK и сесията е установена. След като сесията бъде установена, действителният дигитализиран гласов разговор обикновено се предава чрез протокол за предаване в реално време (RTP) със сесията, както показва червената линия на фигура 1. Когато разговорът приключи, се изпраща SIP BYE заявка, последвана от отговор с код на състоянието 200 за потвърждение на прекратяването на сесията.

Ето пример за заявка за SIP INVITE и отговор с код за състояние 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)

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)

Както можете да видите, форматът на SIP прилича на HTTP. Въпреки това, в сравнение с HTTP, SIP е:

  • Отговаря за управлението на сесии. Действителното мултимедийно съдържание, като незабавни съобщения, глас и видео, може или не може да се предава чрез SIP.
  • Асинхронен и държавен. За всяка SIP заявка може да има множество отговори. Това означава, че приложението трябва да обработва всяко SIP съобщение в подходящ контекст на състоянието.
  • Протокол за приложение, който може да работи както на надежден, така и на ненадежден транспорт. По този начин приложението трябва да гарантира доставката на съобщението с повторно предаване и потвърждение на съобщението.
  • Протокол peer-to-peer, при който няма ясно разграничение между клиент и сървър. И двете страни трябва да могат да изпращат и получават заявки и отговори.

SIP-базирани услуги

Базираните на SIP услуги са SIP сървъри, които предлагат услуги като маршрутизиране на съобщения до SIP крайни точки, като например IP телефони. Например, на Фигура 2, SIP регистрационният сървър и прокси сървърът предлагат SIP регистрация и прокси услуги, за да помогнат на SIP крайните точки да се намират и комуникират помежду си.

Фигура 2 илюстрира следното:

  1. Callee се регистрира на сървъра на регистратора, като изпраща заявка за РЕГИСТРИРАНЕ.
  2. Сървърът на регистратора приема регистрацията, която съдържа адреса на името на повикващия, като отговаря с код за състояние 200 OK.
  3. Исканията на повикващия за установяване на сесия за комуникация с извикан, като изпращат покана за ПОКАНА до прокси сървъра. Съдържанието на съобщението INVITE обикновено съдържа описанието на комуникационната сесия, която повикващият иска да установи, като тип носител, защита или IP адрес. Описанието обикновено е във формат на протокол за описание на сесията (SDP).
  4. Прокси сървърът търси сървъра на регистратора, за да разбере текущия адрес на извикания. Имайте предвид, че търсенето е проблем с изпълнението, който не е част от SIP.
  5. Прокси сървърът препраща заявката INVITE от повикващия към повикващия въз основа на текущия си адрес.
  6. Callee приема поканата, като отговаря с код за състояние 200 OK. Отговорът 200 OK на заявка INVITE обикновено съдържа описанието на комуникационната сесия, която повиканият може да установи с повикващия.
  7. Прокси сървърът препраща 200 OK отговор от повикан до повикващ.
  8. Повикващият потвърждава установяването на сесията, като изпраща ACK съобщение до прокси сървъра. Съобщението ACK може да съдържа окончателното споразумение за сесията.
  9. На свой ред прокси сървърът препраща ACK към повикания. По този начин трипосочното ръкостискане завършва чрез прокси сървъра и се установява сесия.
  10. Сега комуникацията между повикващия и повикания се случва. Протоколът, използван за комуникация, може да бъде или да не е SIP. Например незабавни съобщения могат да се предават през SIP. Гласовите разговори обикновено се предават през RTP.
  11. Сега извиканият завършва разговора и иска да прекрати сесията, като изпрати заявка за BYE.
  12. Повикващият отговаря с код за състояние 200 OK, за да приеме прекратяване на сесията.

В горния сценарий SIP прокси сървърът просто насочва съобщенията към текущия адрес на извикания. Както можете да си представите, могат да се случат по-интересни и интелигентни маршрутизационни услуги. Например прокси сървърът може да „следва потребител“, като пренасочва съобщенията до мястото, където той може да бъде достигнат, например мобилен телефон, дори ако някой се обажда на неговия офис телефон.

SIP сървлет

Дефинирана в заявка за спецификация на Java 116, спецификацията на SIP сървлета предоставя модел за програмиране на контейнер-сервлет за SIP приложения. Тъй като е получен от архитектурата на Java сървлета в Java EE, JSR 116 предлага познат подход за изграждане на SIP услуги за разработчиците на Java EE.

Таблицата по-долу обобщава сходството между HTTPServletи SIPServlet.

Сравнение между HTTP и SIP сървлет

  HTTP SIP
Сервлет клас HttpServlet SipServlet
Сесия HttpSession SipSession
Пакет за кандидатстване ВОЙНА SAR
Deployment descriptor web.xml sip.xml

Much like HTTP servlets, SIP servlets extend the javax.servlet.sip.SipServlet class, which in turn extends the javax.servlet.GenericServlet class. As you might have guessed, SipServlet overrides the service(ServletRequest request, ServletResponse response) method to handle different types of SIP messages.

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.

По-напредналите дискусии за SipSessionжизнения цикъл и връзката му с диалога SIP надхвърлят обхвата на тази статия. За щастие контейнерът се справя с по-голямата част от сложността, като например жизнен цикъл и преходи на състоянието, и SipSessionможе просто да се използва като място за съхранение на данни от сесията.

Пълен пример: EchoServlet

EchoServlet е SIP сървлет, който може да еховира незабавните съобщения, които въвеждате в Windows Messenger: