Najprostsze środowisko do poznawania SIP Servlet API składa się z - jednego komputera, w którym są uruchomione:

• IDE (np. Eclipse)
• serwer aplikacyjny Java EE z obsługą SIP/SIP Servlet (np. Oracle Communications Converged Application Server - OCCAS)
• softphone (np. X-Lite)

Podczas Javarsovia 2008 posługiwałem się troszkę bardziej złożonym "laboratorium", dzięki któremu łatwiej testować ciekawsze aplikacje korzystające z SIP Servlet API. Można je zbudować stosunkowo niewielkim kosztem.
Poniżej opis takiego mikro-laboratorium.

Jedną z trudności podczas testowania w środowisku składającym się z jednego telefonu SIP jest brak możliwości ustanowienia połączenia telefonicznego (lub wideofonicznego). M.in. dlatego, że blokowane są kanały audio w komputerze lub powstają sprzężenia. Naturalne wydaje się zatem poszerzenie środowiska o dodatkowe telefony. Jeśli ktoś ma dostęp do innego komputera, to wystarczy skomunikować oba komputery przez sieć (np. poprzez switch, czy WiFi), a na tym dodatkowym komputerze zainstalować drugi softphone. To już pozwoli ustanowić normalne połączenie telefoniczne (VoIP - Voice over IP), a jeśli softphone obsługuje video (jak np. X-Lite), to - po podłączeniu kamer - nawet połączenie wideofoniczne (Video over IP). Warto sprawdzić, czy oba komputery "widzą" się bez przeszkód (np. działa ping między nimi), a także zadbać o odpowiednią konfigurację oprogramowania firewall. Protokół SIP ma domyślny port 5060 i często firewall blokuje ten port. Oprócz tego do przesyłania SIP i mediów - dźwięk, obraz wideo - używane są zarówno TCP, jak i UDP. Dobre telefony mają obsługę NAT (STUN, ICE, itd.), ale trzeba na poprawność połączeń sieciowych zwrócić większą uwagę niż przy budowie np. aplikacji webowych.
Trzeba oczywiście skonfigurować drugi telefon, tak, aby:

• miał unikalną nazwę (to pozwoli identyfikować skąd dany komunikat SIP przyszedł albo do którego telefonu/użytkownika jest skierowany)
• wysyłał i odbierał komunikaty (oraz rejestrował się) do/z serwera aplikacyjnego (tu: OCCAS 4.0)
  Konfiguracja nowego softphone'u jest podobna do opisanej wcześniej.

Mając do dyspozycji drugi telefon SIP można już pokusić się o zbudowanie SIP Servlet'ów o bardziej złożonej logice, np.:

• rejestrator połączeń (czyli jeśli jeden telefon wywołuje drugi, to komunikat o takim wywołaniu przechodzi przez serwer aplikacyjny SIP. Taka próba połączenia może być zapisana, np. w logu, czy w bazie danych. Zresztą rejestrować można różne komunikaty, nie tylko INVITE, ale także BYE, a nawet skorelować INVITE i BYE, tak, aby zapisywać na serwerze czas trwania połączenia)
• filtrowanie połączeń (czyli SIP servlet przepuści tylko wybrane komunikaty, np. tylko od telefonu 1 do telefonu 2 albo przepuści tylko wtedy, gdy zewnętrzny system - np. na podstawie danych w bazie danych - na to pozwoli)

Poniższy rysunek pokazuje takie środowisko, rozbudowane o dodatkowy komputer z SIP softphone:

Oczywiście, nic nie stoi na przeszkodzie, aby w ten sposób podłączać kolejne softphone'y.

Kolejna rozbudowa może polegać na dodaniu "prawdziwych" telefonów, czyli kawałka sprzętu, który wygląda i działa jak normalny telefon - tyle, że jest to telefon IP (dokładniej SIP) i zamiast wtyczki telefonicznej (RJ-11) ma zwykłe gniazdko Ethernet. Z doświadczenia wiem też, że większość ludzi bardzo sceptycznie podchodzi do demonstracji, gdy pokazuje im się coś na softphone. Ale, gdy robi się takie demo z użyciem "normalnie" wyglądających, a do tego znajomo dzwoniących telefonów, to poziom zainteresowania bardzo rośnie (czasem nawet słychać echo opadających szczęk). Ludzie podchodzą, dotykają telefonu (też tak robiłem). Dziwna sprawa - cóż psychologia ;-)))

Wybór tego rodzaju telefonów jest przeogromny - od prostych po wideotelefony i kombajny biurowe. Są także takie z obsługą WiFi (odpada problem kabli). Do moich demonstracji używam stosunkowo tanich (ok. 170-200 PLN) telefonów Grandstream BT-200. Mają co trzeba, czyli obsługę protokołu SIP 2.0, wyświetlacz i konfigurowalne muzyczki :-). Poniżej parę zdjęć tego telefonu:

Widok z tyłu (gniazdka):

Widok z góry:

Widok z boku:

Wygląd z góry (wraz z objaśnieniem klawiszy):

Wyświetlacz:

Taki telefon podłącza się po prostu poprzez Ethernet do switch'a, a po uruchomieniu telefonu nadawany jest mu adres IP (albo z DHCP albo wpisany na stałe) - u mnie jest to 192.168.0.201 i 192.168.0.202. Następnie, w przeglądarce wpisuje się ten adres (np. http://192.168.0.202) i pojawia się strona do logowania (domyślne hasło dla BT-200 jest: admin):

Po zalogowaniu można już skonfigurować telefon:

Opcji jest bez liku, ale najważniejsze jest skonfigurowanie połączenia do serwera SIP (czyli w naszym przypadku serwera aplikacyjnego - OCCAS). Należy zatem przejść na zakładkę ACCOUNT i podać nazwy identyfikujące ten telefon (właściwie to konto użytkownika w tym telefonie) - przede wszystkim adres serwera SIP, który będzie odbierał komunikaty SIP wysyłane przez ten telefon i przesyłał komunikaty SIP do tego telefonu (czyli pole SIP Server wypełnić adresem serwera OCCAS):

Jak widać jest to podobna operacja do tej, jaką wykonywaliśmy wcześniej, konfigurując softphone (X-Lite) na komputerze (laptopie). W zasadzie to taki telefon SIP jest normalnym komputerem (jak widać ma nawet wbudowany serwer www, używany do konfiguracji), ma swój adres IP (można go ping'ować - nawet należy, po to, aby upewnić się, że wszystko jest OK na warstwie połączeń sieciowych).

Czyli mikro-laboratiorum rozbudowane o telefony SIP wyglądałoby następująco:

To pozwoli na łatwiejsze przetestowanie typowych scenariuszy, np.:

• rejestracji telefonów (np. prostej bazy danych, która trzyma nazwę użytkownika i adres SIPowy - w tym adres IP - telefonu tego użytkownika), co pozwoli na wywoływanie telefonów po krótkiej nazwie (np. xlite1, zamiast 192.168.0.200)
• find-me-follow-me - czyli usługi, której logika polega na wywoływaniu w odpowiedniej kolejności poszczególnych telefonów (np. wywołując "waldek", najpierw dzwoniłby telefon "SIP Phone 1", potem "SIP Phone 2", a potem "SIP Softphone 2"). Tę logikę można oczywiście rozbudować, np. uzależnić sekwencję wywołań od pory dnia, czy danych w jakiejś zewnętrznej bazie danych.
• click-to-call (inne nazwy: click-to-dial, click-to-service) - czyli możliwość ustanowienia z poziomu strony web telekonferencji pomiędzy dwoma telefonami. Bez media serwera, czy innego komponentu zdolnego do zmieszania mediów - tj. dźwięku lub wideo - z więcej niż dwóch źródeł, to taka telekonferencja będzie w praktyce możliwa tylko pomiędzy dwoma telefonami. Oczywiście, wywołanie może pójść do więcej niż dwóch telefonów, ale po odebraniu media będą przesyłane tylko pomiędzy dwoma telefonami. Od razu uprzedzam też pytanie: media są przesyłane bezpośrednio pomiędzy telefonami, nie przechodzą przez serwer aplikacyjny. Gdybyśmy dodali do tego środowiska jakiś media serwer/gateway, to wtedy telefony komunikowałyby się bezpośrednio z tym media serverem. On dokonywałby zmiksowania mediów płynących z pozostałych telefonów i w ten sposób byłaby możliwa pełna telekonferencja. Jednym z łatwiej dostępnych media server'ów / gateway'ów jest choćby Asterisk, który także ma obsługę protokołu SIP (ale nie SIP Servlet, więc Asterisk nie zbyt nadaje się na serwer aplikacyjny, choć pewną - stosunkowo prostą - logikę połączeń można na nim skonfigurować).

Przy okazji click-to-call można także pobawić się dodatkową możliwością jaką daje SIP Servlet, czyli możliwość łączenia sesji HTTP z sesjami SIP. Pozwala to zrobić inteligentne przekierowywanie połączeń. Dla przykładu: mamy sklep internetowy ze stronami, na których umieszczono opisy produktów. Na każdej takiej stronie umieszczamy link (lub przycisk) "Kliknij, aby porozmawiać z konsultantem i dowiedzieć się więcej o tym produkcie". Po naciśnięciu tego linku nastąpi zestawienie połączenia telefonicznego (SIPowego, choć dzięki pokazanym dalej bramkom SIP-PSTN, może to być połączenie z dowolnym numerem telefonicznym), pomiędzy klientem sklepu a konsultantem. Z tym, że jako właściciele tego sklepu, chcielibyśmy, aby klient był połączony do właściwego konsultanta, tj. tego, który zna się na danym produkcie (a nie tylko jest wolny). Czyli chcielibyśmy przesłać kontekst z kanału webowego (w tym dane z sesji HTTP tego użytkownika) do kanału telefonicznego. Czyli spiąć HTTP z SIP (a dokładniej HTTP Servlet z SIP Servlet). Tego rodzaju mechanizmy łączenia obu sesji (a nawet wielu sesji razem) są częścią standardu SIP Servlet (i w postaci API są opisane w specyfikacji SIP Servlet).

Nic nie stoi też na przeszkodzie, aby skorzystać z telefonu komórkowego. Takie demo to już w ogóle wzbudza applauz - nie ma kabli a dzwoni ! ;-)
Wiele dzisiejszych modeli ma wbudowanego klienta VoIP, obsługującego SIP poprzez WiFi (np. wiele z nowszych modeli telefonów Nokia ma taką możliwość). W swoich zabawach używałem Nokia E61i. Wystarczy w "Ustawieniach SIP" utworzyć nowy profil, w którym jako serwer proxy należy podać adres i port serwera aplikacyjnego. Wcześniej należy także skonfigurować połączenie WiFi (no i trzeba mieć WiFi access point wpięty do sieci ;-)).
Czyli mikro-lab wyglądałoby to następująco:

Poza efektem "wow", to do zrobienia nowych scenariuszy użycie telefonu VoIP/WiFi specjalnie nic nowego nie wnosi. Ale można się pokusić, np. o:
- usługę "emergency call" - czyli, gdy z jakiegokolwiek telefonu wpiszemy "997" albo "112", to zawsze będzie dzwonić komórka (a właściwie klient SIP w komórce).
Nie szperałem w dokumentacji, ale może dałoby się oprogramować moduł GPS wbudowany w niektóre telefony i przesyłać co jakiś czas aktualną pozycję telefonu w postaci komunikatu (np. komunikatu SIP, bo SIP jest na tyle "pojemny", że pozwoli taki mechanizm obsłużyć). To by dopiero było świetne demo !
Być może upowszechnienie się Google Android (który w odróżnieniu od Apple iPhone wydaje się szczególnie przyjaznym telefonem dla deweloperów Java) jeszcze bardziej ułatwi nam życie. The sky is the limit...

Jeszcze ciekawszą opcją jest dodanie do mikro-lab'u bramki SIP-PSTN, czyli możliwość podłączenia się do ogólnodostępnych sieci telefonicznych, co pozwoli dzwonić do i odbierać połączenia od innych użytkowników (nie ma tu ograniczeń - sieć stała, mobilna, VoIP, Skype, ...). Czyli coś takiego:

To nie jest dużo droższa zabawa, bo taka najprostsza bramka kosztuje ok. 200 PLN. Bardziej zaawansowane modele mogą kosztować i 1500 PLN (pomijam profesjonalne urządzenia).
Zresztą podobnie jak i wcześniej, tak i tu, do zbudowania bramki można skorzystać z Asteriska (nie robiłem tego, ale wydaje mi się, że nie powinno to być zbyt skomplikowane).

To tyle - miłego eksperymentowania z SIP i SIP Servlet API !