Politechnika Gdańska
WYDZIAA
ELEKTRONIKI
TELEKOMUNIKACJI I INFORMATYKI
Katedra Teleinformatyki
Wielousługowe architektury IP
IMS  Część 2 - usługi
Dr hab. inż. Wojciech Molisz
Prof. Nadzwyczajny P.G.
Usługa obecności IMS
Usługi obecności i komunikatora (szerzej:
komunikacji internetowej) zmieniają model
komunikacji osobistej i korporacyjnej.
Przewiduje się iż usługa obecności będzie
sercem całej komunikacji i nową metodą
funkcjonowania telefonii.
Obecność będzie także istotnym z
ródłem
dochodów zarówno dla operatorów jak i
dostawców usług.
Wojciech Molisz 2
Istota usługi obecności
Obecność jest dynamicznym profilem
użytkownika, który jest widoczny dla innych i
używany do jego reprezentowania oraz
wymiany informacji.
Obecność może być widziana jako status
użytkownika postrzegany przez innych lub
jako status innych użytkowników
postrzegany przez danego użytkownika.
Informacje zawarte w obecności są osobiste,
ponieważ są zawsze związane z konkretną
osobą.
Wojciech Molisz 3
Istota usługi obecności (2)
Status użytkownika może zawierać takie
informacje jak:
status osobisty,
status urządzenia,
lokalizacja,
możliwości terminala,
preferowana metoda kontaktu,
usługi które użytkownik pragnie wykorzystywać
do komunikacji z innymi, włączając w to mowę,
wideo, komunikator bądz
wspólną grę.
Wojciech Molisz 4
Istota usługi obecności (3)
Usługa obecności opiera się na dwóch podstawowych
zasadach:
umożliwienia innym oglądania statusu danego użytkownika,
umożliwienia dostępu użytkownikowi do statusu innych.
Informacje usługi obecności mogą obejmować:
dostępność użytkownika i terminala,
preferencje komunikacyjne,
możliwości terminala,
aktywność w danej chwili,
lokalizację,
usługi dostępne w danej chwili.
Wojciech Molisz 5
Usługa obecności - przykładowe menu
Książka telefoniczna w Książka telefoniczna z
dzisiejszych telefonach usługą obecności
komórkowych
y
ródło: The IMS, 2e  M. Poikselk� et al., Wiley, 2006
Wojciech Molisz 6
Rozszerzenie protokołu SIP
Protokół SIP został rozbudowany poprzez stworzenie pakietu
zdarzeń o nazwie  obecność (ang. presence). Podczas próby
nawiązania połączenia, terminal użytkownika wstawia token
 obecność w nagłówku Event.
Stworzone zostały nowe pojęcia dla usługi obecności:
Presentity  stacja protokołu, która dostarcza informacji usługi
obecności do serwera tej usługi,
Watcher  stacja protokołu, która żąda informacji (presence) o
zasobach (presentities),
Presence Agent (PA)  agent obecności mający możliwość
przechowywania i generowania powiadomień,
Presence User Agent (PUA)  agent użytkownika obecności który
przetwarza informacje obecności przeznaczone dla presentity i je
publikuje.
Presentity wysyła informacje obecności przy użyciu metody
PUBLISH.
Wojciech Molisz 7
Watcher
Architektura obecności IMS
Presence
Proxy
P-CSCF
PUA (informacje obecności
dostarczane przez zewnętrzne
elementy)
S-CSCF
PUA (informacje obecności
Informacje obecności
dostarczane przez
użytkownika)
S- I-
Presence Server
CSCF CSCF
(sieć domowa)
Presentity
HSS (HLR)
Presence Proxy
MSC Server/VLR
SGSN
HSS (HLR)
S-
CSCF
GGSN GMLC
PUA (informacje
obecności
dostarczane przez sieć)
Wojciech Molisz 8
Architektura obecności IMS
RLS
PUA (AS)
PA (AS)
Watcher (AS)
Pen (AS)
ISC
Pi=ISC
PUA,Watcher
Pw=ISC
Access Network
Px=Cx
HSS
S-CSCF
P-CSCF
Px=Dx
Px=Cx
Pw=Mw SLF
PUA,Watcher
Access Network
Px=Dx
P-CSCF
Peu=Pw=Gm
I-CSCF
RLS  Resource List Server
(zarządza subskrypcjami)
Wojciech Molisz 9
Architektura obecności IMS
Zadania elementów składowych architektury obecności:
Presence Server  zarządza informacjami usługi
obecności nadesłanymi przez stacje PUA i nadzoruje
żądania subskrypcji do usługi obecności
Watcher Presence Proxy  identyfikuje sieć docelową
dla stacji presentity
Presentity Presence Proxy  identyfikuje serwer
obecności przypisany do konkretnej presentity
Presence User Agent  gromadzi i dostarcza
informacje obecności do serwera
Resource List Server  zarządza subskrypcjami do list
zasobów.
Wojciech Molisz 10
Pakiet schematów informacji obserwatora
Użytkownicy abonują (subskrybują) otrzymywanie
informacji o stanie konkretnego zasobu wykorzystując
pakiet zdarzeń (zwany również  pakietem głównym ).
Użytkownicy sprawdzają w ten sposób kto subskrybuje
ich informacje obecności i jaki jest status tej
subskrypcji.
Informacja dostarczana subskrybentowi informacji
zawiera dwa istotne składniki: status każdej subskrypcji
stworzony przez obserwatorów pakietu głównego oraz
zdarzenie które spowodowało zmianę poprzedniego
statusu na obecny.
Wojciech Molisz 11
Graf przejść stanów pakietu informacji
Stany pakietu informacji obserwatora (RFC 3857):
Init  żaden stan nie jest przypisany do subskrypcji.
Terminated  istnieje polityka która nie pozwala
obserwatorowi na subskrypcję do pakietu głównego
zdarzeń.
Active  istnieje polityka zezwalająca obserwatorowi
na subskrypcję do pakietu głównego.
Pending  nie istnieje żadna polityka dla danego
obserwatora.
Waiting  użytkownik próbował subskrybować
pakiet główny ale subskrypcja wygasła zanim
stworzona została polityka.
Wojciech Molisz 12
Graf przejść stanów pakietu informacji
subscribe,
policy=reject
Terminated
noresource
noresource
rejected
rejected
giveup
deactivated
approved
probation
noresource
timeout
rejected
deactivated
probation
giveout
subscribe approved
Init Pending Active
no policy
subscribe
policy=accept
Waiting
timeout
Wojciech Molisz 13
Udana subskrypcja usługi obecności
UE-1 P-CSCF S-CSCF I-CSCF HSS S-CSCF AS (PS)
SUBSCRIBE
SUBSCRIBE
SUBSCRIBE
Pytanie o
lokalizacje
uzytkownika
SUBSCRIBE
SUBSCRIBE
200 OK
200 OK
200 OK
200 OK
200 OK
NOTIFY
NOTIFY
NOTIFY
200 OK
200 OK
200 OK
Wojciech Molisz 14
Publikowanie obecności
Publikacja informacji obecności może być
osiągnięta przy użyciu rozszerzenia protokołu
SIP.
Nagłówek Event żądania PUBLISH przenosi
token obecności.
Domyślnym czasem wygaśnięcia publikacji
jest 3600 sekund.
Wojciech Molisz 15
Udana publikacja informacji obecności
UE P-CSCF
AS (PS)
S-CSCF
PUBLISH
PUBLISH
PUBLISH
200 OK
200 OK
200 OK
Na rysunku wyżej pokazano przykładową wymianę wiadomości stacji presentity
której udało się pomyślnie opublikować informacje obecności. W tym scenariuszu
UE zachowuje się jak Presentity User Agent (PUA).
Wojciech Molisz 16
Subskrypcja listy zasobów
UE P-CSCF
AS (PS)
S-CSCF
SUBSCRIBE
SUBSCRIBE
SUBSCRIBE
200 OK
200 OK
200 OK
NOTIFY
NOTIFY
NOTIFY
200 OK
200 OK
200 OK
Rysunek wyżej pokazuje przykładowy przepływ sygnalizacji użytkownika dla
stworzonej wcześniej subskrypcji listy zasobów informacji obecności. Lista
presentities (zasobów) pobierana jest przy wykorzystaniu SIP URI.
Wojciech Molisz 17
Współpraca presence server,
watcher, presentity
Presentity Watcher
Subscribe (presence)
Subscribe (winfo)
Notify
Notify
Presence
Server
Publish
Wojciech Molisz 18
Subskrypcja informacji o obserwatorze
UE P-CSCF
AS (PS)
S-CSCF
SUBSCRIBE
SUBSCRIBE
SUBSCRIBE
200 OK
200 OK
200 OK
NOTIFY
NOTIFY
NOTIFY
200 OK
200 OK
200 OK
Rysunek wyżej przedstawia sposób wymiany wiadomości pomiędzy PUA i
domeną komutacji pakietów PS kiedy użytkownik subskrybuje otrzymywanie
powiadomień o zmianach stanu obserwatorów
Wojciech Molisz 19
Usługa komunikatora w IMS
Usługa komunikatora w IMS przyjmuje
jedną z trzech postaci:
bezpośredniej komunikacji;
komunikacji opartej na sesji;
komunikacji z opóz
nionym dostarczaniem
wiadomości.
Tylko dwie pierwsze postaci usługi
bezpośrednio wykorzystują architekturę IMS.
Wojciech Molisz 20
Komunikator bezpośredni
W komunikatorze bezpośrednim, terminal użytkownika
(UE) generuje metodę MESSAGE, dodaje pożądaną
zawartość (przeważnie tekst, choć może to być też
dz
więk lub obraz) i do żądania request-URI wpisuje
adres odbiorcy.
Żądanie to jest kierowane poprzez infrastrukturę IMS
w podobny sposób jak INVITE, aż do chwili kiedy trafi
do UE odbiorcy.
Może pojawić się odpowiedz
, ale kontekst tej sesji
istnieje tylko w świadomości uczestniczących w niej
stron  nie jest tu użyty żaden protokół sesji  każda
wiadomość jest niezależną transakcją i nie jest
powiązana z żadnym poprzednim żądaniem.
Wojciech Molisz 21
Komunikator bezpośredni
UE P/I/S-CSCF
UE
P/I/S-CSCF
MESSAGE
MESSAGE
MESSAGE
200 OK
200 OK
200 OK
Na rysunku wyżej pokazano przykładową wymianę wiadomości komunikatora
bezpośredniego.
Wojciech Molisz 22
Komunikator bezpośredni
Jeżeli próba dostarczenia wiadomości zostanie
podjęta kiedy użytkownik jest w stanie off-line lub
niezarejestrowany, wtedy zostanie ona skierowana do
serwera aplikacji AS.
AS może przechować wiadomość do czasu kiedy jej
odbiorca zarejestruje się w sieci (wtedy może
dostarczyć mu wiadomość).
Wiadomości są na ogół adresowane identyfikatorem
publicznym odbiorcy wiadomości.
Użytkownik IMS może stworzyć alias przy użyciu
adresu SIP w formie PSI (ang. Public Service
Identifier) i rozesłać go podając zestaw SIP URI
należący do użytkowników  adresatów wiadomości.
Wojciech Molisz 23
Komunikator oparty na sesji
Komunikator oparty na sesji nawiązuje do
popularnego modelu IRC (ang. Internet Relay Chat).
Tutaj użytkownik bierze udział w sesji w której główny
składnik mediów często zawiera krótkie wiadomości
tekstowe.
Każda sesja ma zdefiniowany czas życia: sesja
wiadomości rozpoczyna się kiedy strony zaczynają
sesję, wykorzystując protokoły SIP i SDP, a kończy
się kiedy zamykają oni sesję.
Po nawiązaniu sesji strumień mediów przepływa od
jednego uczestnika wymiany do drugiego.
Wojciech Molisz 24
Komunikator oparty na sesji
UE P/I/S-CSCF
UE
P/I/S-CSCF
INVITE
INVITE
INVITE
200 OK
200 OK
200 OK
ACK
ACK
ACK
SEND
OK
BYE
BYE
BYE
200 OK
200 OK
200 OK
Wojciech Molisz 25
Komunikator oparty na sesji
Komunikacja oparta na sesji może odbywać się na
zasadzie równy z równym, podobnie do normalnej
rozmowy telefonicznej.
Jedyną różnicą jest to, że strumienie mediów mają
postać sesji wymiany wiadomości.
Możliwe jest połączenie innych sesji multimedialnych z
sesją wiadomości.
Przykładem może być rozmowa wideo z dodanym z
boku kanałem tekstu pomagająca ludziom
upośledzonym słuchowo.
Używany jest protokół Message Session Relay
Protocol (MSRP), umiejscowiony nad protokołem TCP.
Wojciech Molisz 26
Architektura komunikatora IMS
Chat
rozpoczęty
HSS
P-CSCF
S-CSCF
MRFC
AS
H.248
IMS Terminal 2
MRFP
HSS
HSS
P-CSCF
S-CSCF
AS
IMS Terminal 1
MRFC - Media Resource Function Controller
MRFP - Media Resource Function Processor
MRSP:Visit/OK
MRSP:Visit/OK
Wojciech Molisz 27
Scenariusz IMS CHAT
IMS Terminal 1 P-CSCF 1 S-CSCF 1 MRFC MRFP S-CSCF P-CSCF IMS TERMINAL 2
1. Invite
Ocena
2. 100 trying
kryteriów
filtracji
3. Invite
wstępnej
4. 100 trying
5. Invite
6. 100 trying
7. H.248
8. MRSP Visit
9. MRSP:200 OK
10. H.248
11. 200 OK
12. 200 OK
13. 200 OK
14. ACK
15. ACK
16. ACK
17. Invite
18. 100 trying
Wojciech Molisz 28
Scenariusz IMS CHAT (2)
IMS Terminal 1 P-CSCF S-CSCF MRFC MRFP S-CSCF P-CSCF IMS TERMINAL 2
19. Invite
20. 100 trying
21. Invite
Ocena
kryteriów
22. 100 trying
filtracji
wstępnej
23. H.248
24. MRSP Visit
25. MRSP:200 OK
26. H.248
27. 200 OK
28. 200 OK
29. 200 OK
30. ACK
31. ACK
32. ACK
33. MRSP:SEND
35. MRSP:SEND
34. MRSP:200 OK
36. MRSP:200 OK
Wojciech Molisz 29
Scenariusz IMS CHAT - komentarz
Terminal-1 IMS wysyła INVITE do MRFC poprzez P-CSCF i S-CSCF.
MRFC wysyła wiadomość H.248 do MRPF.
MRPF wysyła sygnał MRSP Visit do terminala-1 IMS.
MRFC wysyła wiadomość H.248 do MRPF.
MRFC wysyła sygnał MRSP 200 OK do terminala-1 IMS.
Terminal-1 wysyła wiadomość ACK do MRFC.
Terminal-2 IMS wysyła INVITE do MRFC.
MRFC wysyła wiadomość H.248 do MRFP.
MRFP wysyła sygnał MRSP Visit do terminala-2 IMS
Terminal-2 IMS odpowiada: MRSP 200 OK.
MRFC wysyła wiadomość H.248 do MRPF.
MRFC wysyła sygnał OK do terminala-2 IMS .
Terminal-2 IMS odpowiada: ACK.
MRSP kontynuuje wysyłanie Send/200 OK pomiędzy MRFP a terminalami
IMS.
Sesja Chat została rozpoczęta.
Wojciech Molisz 30
Komunikacja z opóz
nionym
dostarczaniem wiadomości
Komunikacja z opóz
nionym dostarczaniem wiadomości
jest w rzeczywistości dobrze znaną usługą MMS (ang.
Multimedia Messaging Service).
Podjęta została decyzja, że wymagania przedstawione
przez 3GPP dotyczące IMS Messaging Stage 1
powinny być zgodne z wymaganiami dotyczącymi
MMS.
W praktyce oznacza to, iż MMS jest wykorzystywana
do trybu opóz
nionego dostarczania wiadomości w IMS.
Wojciech Molisz 31
Usługa  Push to talk over Cellular (PoC)
Usługa Push to talk over Cellular (PoC) umożliwia
bezpośrednią komunikację pomiędzy użytkownikami
w modelu jeden do jednego lub jeden do wielu.
Użytkownik wybiera osoby lub grupy z którymi chce
się komunikować i naciska specjalny klawisz zwany
 talk key w celu rozpoczęcia rozmowy.
Sesje są zestawiane w jedną stronę w czasie
rzeczywistym  kiedy jedna osoba mówi, inne mogą
tylko słuchać.
Opcjonalnie użytkownik może wybrać funkcję
uczestnictwa w sesji tylko po akceptacji zaproszenia
do niej.
Wojciech Molisz 32
Usługa  Push to talk over Cellular (PoC)
W usłudze Push to talk
Serwer PoC
over Cellular (PoC)
Pakiety RTP
każdy użytkownik
Pakiety RTP
wysyła pakiety RTP do
dedykowanego
IMS SIP
serwera PoC, a ten, w
SIP
przypadku sesji
SIP
grupowej, powiela je i
wysyła do wszystkich
odbiorców.
Wojciech Molisz 33
Usługa  Push to talk over Cellular (PoC)
Usługa PoC działa przezroczyście zarówno dla sieci
komórkowych jak i stacjonarnych.
Wynika to z faktu, że nie jest potrzebny protokół
komunikacji grupowej ani w sieci dostępowej ani
szkieletowej, a mobilność jest zarządzana przez sieć
radiową.
Kontrola sesji PoC i inna sygnalizacja są oparte na
protokole SIP, a ruch rozmówny jest przenoszony
przez protokół Real-Time Transport Protocol/Real-
time Transport Control Protocol (RTP/RTCP).
Wojciech Molisz 34
Usługa  Push to talk over Cellular (PoC)
PoC wykorzystuje dostęp i medium radiowe bardziej
efektywnie niż usługi w sieci z komutacją kanałów.
Zasoby sieciowe są rezerwowane tylko w jedną
stronę na czas trwania ciągu pakietów mowy zamiast
dwukierunkowej rezerwacji na cały czas trwania sesji.
W porównaniu z konwencjonalnymi rozwiązaniami
jak Land Mobile Radio (LMR), Professional Mobile
Radio (PMR) czy Family Radio Service, PoC oferuje
lepszy zasięg ponieważ wykorzystuje zasięg
oferowany przez sieci GSM/WCDMA/CDMA.
Wojciech Molisz 35
Architektura PoC
Głównymi elementami architektury PoC są:
serwer aplikacji PoC,
PoC XML Document Management Server
(XDMS).
XDMS przechowuje ustawienia konfiguracyjne
aplikacji.
Serwer XDMS który przechowuje dane dla
PoC jest nazywany  PoC XDMS .
Wojciech Molisz 37
Serwer PoC
Serwery PoC:
mogą przenosić dokumenty związane z PoC (np. listy
dostępu) (przy wykorzystaniu punktu odniesienia
POC-8);
mogą przenosić ogólne listy jak np. lista członków
grupy [e-mail] ze
współdzielonego serwera XMDS (przy wykorzystaniu
punktu odniesienia POC-5);
obsługują  paczki pakietów podczas trwania sesji;
(rezerwacja zasobów dla jednego użytkownika,
sterowanie sesją PoC);
oferują interfejsy do systemów zarządzania i nadzoru
operatora i tworzą dane bilingowe w postaci rekordów
Charging Detail Records (CDR).
Wojciech Molisz 38
Serwer PoC
Serwer PoC:
nadzoruje procedurę zestawiania połączenia sesyjnego,
wymusza politykę zdefiniowaną dla sesji grupowych PoC:
kto ma zezwolenie na dołączenie się do sesji,
kto ma zezwolenie na zapraszanie nowych członków,
decyduje czy sesja powinna być zwolniona kiedy któryś z
użytkowników ją opuszcza,
decyduje czy inni użytkownicy powinni zostać zaproszeni jeśli
określony użytkownik się dołącza),
dostarcza informacji o grupach użytkowników (np. informuje o
dołączeniu lub opuszczeniu grupy przez użytkownika);
odpowiada za dystrybucję i adaptację strumienia mediów,
nadzoruje zarówno płaszczyznę sterowania jak i płaszczyznę
użytkownika ruchu związanego z usługą PoC.
Wojciech Molisz 39
Architektura serwera PoC
Architektura serwera PoC jest pokazana na rys. niżej:
Sygnalizacja klienta
PoC zawsze
Funkcja
przechodzi przez
uczestnictwa
serwer z funkcją
Funkcja Funkcja
uczestnictwa
nadzoru uczestnictwa
Klient B
Klient A
usługi
Strumień
usługi PoC
PoC
multimedialny może
Klient C
ominąć serwer z
usługi
funkcją uczestnictwa
PoC
Klient D
usługi
PoC
Wojciech Molisz 40
Architektura serwera PoC
W specyfikacji OMA zdefiniowane zostały dwie różne
role serwera PoC:
funkcja uczestnictwa w PoC;
funkcja nadzoru PoC.
Przypisanie roli serwerowi ma miejsce podczas
zestawiania sesji - tylko jeden z serwerów otrzymuje
funkcję nadzoru PoC, a dwa lub więcej serwerów PoC
otrzymują funkcję uczestnictwa w zależności od liczby
uczestników sesji PoC.
Sygnalizacja SIP od użytkowników zawsze trafia
najpierw do funkcji uczestnictwa PoC, która wysyła
ruch sygnalizacyjny SIP dalej do funkcji nadzoru.
Wojciech Molisz 41
Komunikacja PoC
Modele komunikacji PoC:
Grupy dial-out (tworzone na żądanie strony
inicjującej)
Zdefiniowane wcześniej grupy PoC,
Okazjonalne grupy dial-out (ad hoc PoC).
Grupy join-in (do nich dołączają zainteresowni)
Otwarte grupy Chat PoC,
Zamknięte grupy Chat PoC.
Wojciech Molisz 42
Sesje PoC
Istnieją dwa modele sesji PoC:
sesja na żądanie (on demand),
sesja zestawiona wcześniej (pre-established).
W modelu na żądanie, wykorzystywana jest tradycyjna
metoda SIP, czyli parametry strumieni są negocjowane
kiedy użytkownik wysyła żądanie sesji PoC.
W modelu pre-established użytkownik zestawia sesję z
funkcją uczestnictwa serwera PoC i negocjuje
wszystkie parametry przed przesłaniem zaproszenia
do nawiązania sesji PoC do innych użytkowników PoC.
Wojciech Molisz 43
Model zestawiania sesji PoC pre-established
Serwer uczestniczący Serwer uczestniczący
PoC PoC
1. INVITE (parametry) 1. INVITE (parametry)
2. 200 OK (parametry) 2. 200 OK (parametry)
3. ACK 3. ACK
IMS IMS
Serwer uczestniczący
Serwer uczestniczący Użytkownik
i kontrolujący PoC
Użytkownik
PoC Paweł
Tomasz 2. INVITE (parametry)
1. REFER 6. Talk Burst Control
3. 202 Accepted 5. 200 OK (parametry)
4. NOTIFY/200 OK 7. ACK
11. Talk Burst Control
8. NOTIFY/200 OK 10. Talk Burst Control
9. Talk Burst Control
IMS
Wojciech Molisz 45
Model zestawiania sesji PoC pre-established
W górnej części rysunku na poprzedniej stronie, użytkownicy PoC
ustanawiają sesje pre-established.
W dolnej części Tomasz chce skontaktować się z Pawłem.
Klient PoC Tomasza wysyła żądanie SIP REFER które zawiera
identyfikator Pawła jako użytkownika docelowego.
Serwer Tomasza będzie odgrywał rolę zarówno sterującą jak i
uczestnictwa, i wyśle żądanie SIP INVITE poprzez IMS w kierunku
sieci docelowej.
Serwer PoC Pawła (funkcja uczestnictwa) otrzymuje żądanie SIP
INVITE i natychmiast akceptuje sesję ponieważ Paweł
wykorzystuje model sesji pre-established, a tryb jego odpowiedzi
jest ustawiony na automatyczny.
Paweł otrzymuje od swojego serwera wiadomość o kontroli
strumienia ruchu.
Wojciech Molisz 46
Model zestawiania sesji PoC pre-established
Wiadomość ta wskazuje iż rozmowa pochodzi od
Tomasza.
Klient PoC Pawła potwierdza tę wiadomość.
Kiedy funkcja sterująca PoC serwera Tomasza
otrzyma wiadomość 200 OK, wyśle do niego
wiadomość o nadzorze strumienia ruchu wskazując
jednocześnie, iż otrzymał on zezwolenie na rozmowę.
Z drugiej strony podobna wiadomość przesłana zostaje
przez funkcję sterującą do klienta PoC Pawła,
wskazując iż zezwolenie na przesyłanie strumienia
medialnego zostało przyznane Tomaszowi.
Wojciech Molisz 47
Typy list
Zostały zdefiniowane 3 typy list PoC:
Listy kontaktów,
Listy grup,
Listy dostępu:
Listy akceptacji dostępu,
Listy odmowy dostępu.
Wojciech Molisz 48