January 24, 2008
Posted by soczekJak obiecałem umieszczę krótki opis działania usług Mobicents. Jako dalsza część projektu zadaniem mojej grupy było wykonanie sesji SIP oraz wgłębienie się w “wnętrze” Mobicenta aby przedstawić działanie całej usługi. Do nadsłuchiwania sieci użyliśmy programu Wireshark. Chciałbym więc opisać przykład sesji SIP w trakcie poprawnej rozmowy dwóch użytkowników. Użytkownik A (192.168.153.130) – torosvi@nist.gov dzwoni do użytkownika B (192.168.153.131) - hugo@nist.gov. Serwer to 192.168.153.128.
Jak widać wyżej na Graph Analysis:
- • Pierwszym połączeniu programu następuje rejestracja użytkownika poleceniem REGISTER od użytkownika do serwera, a ten odpowiada OK 200.
• Następnie gdy użytkownicy A (192.168.153.130) oraz B (192.168.153.131) chcą się komunikować użytkownik nawiązujący połączenie zaprasza drugiego użytkownika poleceniem INVITE które odbiera serwer (192.168.153.128) i przekazuje do drugiego użytkownika B.
• Ten odpowiada wiadomością TRYING o kodzie 100. Kiedy próba połączenia sygnalizowana jest dzwonkiem wysyła on odpowiedź, tj. wiadomość 180 RINGING. Gdy połączenie zostaje odebrane, wysyła odpowiedź 200 OK. Ta wiadomość dociera do użytkownika A, który wysyła żądanie potwierdzenia ACK.
• Połączenie jest ustanowione i pracę przejmuje protokół RTP, który przesyła głos.
• Gdy połączenie ma zostać zakończone, ostatnia transakcja polega na wysłaniu żądania BYE do serwera który przekierowuje je do użytkownika A ten odpowiada wiadomością 200 OK.
Jeśli chodzi o komponenty SBB oraz Resource Adapter który stanowi połączenie (most) pomiędzy siecią a wewnętrznym środowiskiem oraz Event Router który przekazuje informację pomiędzy komponentami w systemie schemat rozmowy opisanej w sesji SIP wyżej wygląda następująco:
- • Z zewnątrz przychodzi pakiet z zaproszeniem do rozmowy INVITE
• JAIN SIP RA odbiera go i zamienia na zdarzenie INVITE, z argumentami (nadawca, odbiorca)
• Wysyła je do wnętrza systemu, gdzie Event Router wysyła żądanie akcji do kolejnych komponentów SBB (wg priorytetów).
• Istnieje 5 SBB, Proxy, Registrar, oraz 3 odpowiedzialne za usługi
• Załóżmy, że rozmowa nie będzie ani blokowana, ani przekierowana tylko odbędzie się zwykłe połączenie. Po kolei akcję odbierają SBB o coraz niższych priorytetach i odrzucają ją dopóki nie dojdzie do ProxySbb. Ustawia ono odpowiednią flagę w środowisku, dzięki czemu pozostałe Sbb nie będą reagowały na zdarzenie.
• ProxySbb sprawdza czy odbiorca rozmowy jest zalogowany (komunikuje się z RegistrarSbb). Jeśli tak, to przekierowuje INVITE do odbiorcy. W między czasie wysyła do Event Routera zdarzenie 100 Trying, a ten poprzez RA odsyła to poza sieć.
• Odbiorca wysyła do ProxySbb tą samą drogą (SIP RA -> Event Router) wiadomość 180 Ringing, która jest przekierowywane do nadawcy. Stan ten trwa dopóki odbiorca nie odbierze (200 OK) lub nie odrzuci połączenia (486 BUSY HERE).
• Jeżeli użytkownik nie jest zalogowany, to ProxySbb wysyła do Event Routera wiadomość 480 Temporarily Unavailable, a ten poprzez RA odsyła to poza sieć.
0 Comments 
