MODEL WARSTWOWY USTANAWIANIA SESJI WEBRTC 1

Transkrypt

1 STUDIA INFORMATICA 2016 Volume 37 Number 2 (124) Agnieszka CHODOREK Politechnika Świętokrzyska, Katedra Systemów Informatycznych Robert Ryszard CHODOREK AGH Akademia Górniczo-Hutnicza, Katedra Telekomunikacji MODEL WARSTWOWY USTANAWIANIA SESJI WEBRTC 1 Streszczenie. Artykuł przedstawia warstwowy model opisujący ustanawianie sesji WebRTC, uzyskany na podstawie analizy dokumentacji protokołów biorących udział w ustanawianiu sesji oraz kodów źródłowych przeglądarek internetowych. Prezentację modelu zilustrowano przykładami transmisji multimedialnej pomiędzy przeglądarkami WWW oraz pomiędzy przeglądarką a terminalem Vo. Słowa kluczowe: architektura, JSEP, model, SDP, WebRTC A LAYERED MODEL OF THE WEBRTC SESSION ESTABLISHMENT Summary. This paper presents a layered model of the WebRTC session establishment, extracted from documentation and software implementation. The model's presentation is illustrated by examples of multimedia transmissions carried out directly between Web browsers and between a Web browser and a Vo terminal. Keywords: architecture, JSEP, model, SDP, WebRTC 1. Wprowadzenie W obecnych czasach można spotkać się z sytuacją, gdy najpierw tworzone jest skomplikowane oprogramowanie, a dopiero potem (o ile stosowna dokumentacja nie istnieje lub jest nieaktualna) powstaje opis wytworzonej w ten sposób architektury. Osoba podejmująca się opracowania takiego opisu stawiana jest w roli nie wynalazcy, lecz 1 Prace prezentowane w niniejszym artykule były finansowane z funduszu prac statutowych KT AGH (nr umowy ).

2 118 A. Chodorek, R.R. Chodorek odkrywcy. Jej zadaniem nie jest wytworzenie nowej, brakującej architektury, ale nowego, brakującego opisu, możliwie najlepiej oddającego istniejącą architekturę. Działania te są o tyle utrudnione, że architektura nie jest zawarta w liniach kodu w sposób jawny, a w dodatku może ona ewoluować wraz z rozwojem aplikacji [1]. Proces ekstrakcji architektury z oprogramowania jest bardzo czasochłonny. Próbuje się go uprościć, wprowadzając pełną bądź częściową automatyzację [2]. Ekstrakcja taka dotyczy również aplikacji webowych [3]. Technika WebRTC (ang. Web Real-Time Communications) [4, 5] jest używana do budowy systemów multimedialnych, przeznaczonych do transmisji mediów lokalnych w czasie rzeczywistym pomiędzy przeglądarkami WWW. W systemach tych strona WWW pełni rolę interfejsu użytkownika. Wraz z rozwojem WebRTC podejmowane były działania zmierzające do standaryzacji protokołów i mechanizmów protokołowych. Proces ten jeszcze się nie zakończył i niektóre protokoły, jak chociażby JSEP (ang. JavaScript Session Establishment Protocol) [6], nadal są rozwijane i pozostają na etapie propozycji standardu (dokument roboczy Internet Draft). Podjęto również działania zmierzające do usystematyzowania architektury WebRTC. W tym miejscu warto wspomnieć opisy architektury WebRTC wykonane w postaci modeli warstwowych przez Salvatore Loreto i Simona Pietro Romano [4], przez Ilyę Grigorika [5] oraz przez Randella Jesupa, Salvatore Loreto i Michaela Tuexena [7]. Te trzy alternatywne modele warstwowe opisują tę samą architekturę, na tym samym etapie jej rozwoju. Są one jednak niekompletne [8]. Brakuje w nich, między innymi, protokołów używanych do ustanawiania sesji WebRTC, jak SDP (ang. Session Description Protocol) [9] czy wspomniany wyżej JSEP. Niniejszy artykuł systematyzuje budowę podsystemu WebRTC odpowiedzialnego za ustanawianie sesji. Celem artykułu jest wykonanie opisu ustanawiania sesji WebRTC w postaci modelu warstwowego. Model taki mógłby stanowić rozszerzenie dla wspomnianych wcześniej trzech modeli architektury WebRTC. Artykuł składa się z czterech rozdziałów. Rozdział drugi omawia ustanawianie sesji WebRTC oraz modele architektury WebRTC. Rozdział trzeci przedstawia propozycję opisu podsystemu ustanawiania sesji WebRTC w postaci modelu warstwowego, wyekstrahowanego z dokumentacji i oprogramowania. Rozdział czwarty podsumowuje artykuł.

3 Model warstwowy ustanawiania sesji WebRTC Ustanawianie zdalnej sesji WebRTC Ustanowienie zdalnej sesji WebRTC wymaga wymiany pomiędzy systemami końcowymi (przeglądarkami WWW) sesyjnej informacji konfiguracyjnej. Informacja ta zapisywana jest w formacie protokołu SDP [9], który dostarcza spójnej usługi opisu sesji multimedialnej, niezależnej od zastosowanych rozwiązań sprzętowych, programowych i protokołowych. SDP przenosi zarówno opis sesji jako całości (opis poziomu sesji), jak i opis poszczególnych strumieni medialnych (opis poziomu mediów). Typowo informacje konfiguracyjne strumieni medialnych nie są ze sobą skojarzone. W przypadku WebRTC opisy poziomu sesji i mediów zostały formalnie podzielone na pięć komponentów semantycznych. Są to komponenty [10]: metadanych sesyjnych, opisu sieci, opisu strumienia, opisu bezpieczeństwa, opisów QoS (ang. Quality of Service) i grupowania. Nazwy komponentów odpowiadają przenoszonej informacji. Opisy SDP przenoszone są w postaci komunikatów tekstowych. Protokół SDP nie przesyła swoich komunikatów, wykorzystując do tego celu inne protokoły sygnalizacyjne. Sposób użycia SDP do przekazywania opisu sesji systemom końcowym korzystającym z techniki WebRTC został wyspecyfikowany w dokumencie roboczym [10]. W technice WebRT protokół SDP współpracuje z protokołem JSEP [6]. Moduł audio WebRTC C++ API (PeerConnection) Zarządzanie sesją/abstrakcja sygnalizacji Moduł wideo Transport Kodeki isac/ilbc NetEQ Kasowanie echa/ Redukcja szumów Kodek VP8 Bufor wideo elminujący jitter Poprawa jakości obrazu SRTP Multipleksacja P2P STUN+TURN+ICE Przechwytywanie audio/renderowanie Przechwytywanie wideo Rys. 1. Ogólna architektura WebRTC [11] Fig. 1. The overall architecture of the WebRTC [11] Interfejs we/wy sieci Obecnie istnieje kilka modeli architektury WebRTC, z których każdy obejmuje wybrane elementy sesji zdalnej. Najbardziej znaczące z nich, to modele warstwowe Jesup-Loreto-Tuexen [7], Loreto-Romano [4] oraz Grigorika [5]. Model Jesup-Loreto-Tuexen odzwierciedla cztery funkcje techniki WebRTC: bezpołączeniową transmisję datagramową przenikającą przez firewalle i NAT-y, przesyłanie danych medialnych, otwieranie kanałów transmisyjnych do przesyłania danych niemedialnych oraz przesyłanie danych niemedialnych. Model Loreto-

4 120 A. Chodorek, R.R. Chodorek Romano przedstawia trzy funkcje techniki WebRTC: przenikanie przez firewalle i NAT-y, transmisję mediów w czasie rzeczywistym oraz zarządzanie kluczami kryptograficznymi. Model Grigorika lokuje technikę WebRTC na tle przeglądarki. Obrazuje on dwie funkcje techniki WebRTC: przesyłanie danych medialnych oraz przesyłanie danych niemedialnych. Analiza porównawcza powyższych modeli została zamieszczona w artykule [8]. Żaden spośród modeli zamieszczonych w [4, 5, 7] nie zawiera w sobie ani protokołów SDP i JSEP, bezpośrednio biorących udział w ustanawianiu sesji, ani jakiegokolwiek odniesienia do podsystemu odpowiedzialnego za ustanawianie sesji. Odniesienie takie znajduje się w modelu architektury WebRTC zamieszczonym na stronie WWW webrtc.org [11]. Na schemacie blokowym ogólnej architektury WebRTC, obrazującym powiązania funkcjonalne pomiędzy elementami tej techniki (rys. 1 na rysunku pominięto odniesienia do aplikacji, pozostawiając jedynie model WebRTC), wyróżniono blok Zarządzania Sesją i Abstrakcji Sygnalizacyjnej (ang. Session management/abstract signaling). W technice WebRTC abstrakcja sygnalizacyjna opiera się na metadanych zawartych w opisie SDP. Zarządzanie Sesją i Abstrakcja sygnalizacyjna jest blokiem, którego działanie ma wpływ na trzy podstawowe bloki funkcjonalne (głos, wideo, transport strumieni mediów pomiędzy przeglądarkami). Drugim blokiem, wyróżnionym na rysunku 1, jest blok transportu strumieni mediów. Twórcy modelu [11] wydzielili w nim trzy bloki funkcjonalne: protokołu transportowego SRTP (ang. Secure Real-time Transport Protocol), multipleksacji połączeń transportowych i przenikania przez NAT-y (dla transmisji peer-to-peer). 3. Ustanawianie sesji WebRTC ekstrakcja modelu Rozdział zawiera omówienie modelu warstwowego ustanawiania sesji WebRTC, wyekstrahowanego z dokumentacji i oprogramowania Ekstrakcja modelu z dokumentacji i oprogramowania Większość opracowań dotyczących WebRTC wskazuje, iż protokół SDP korzysta z protokołu JSEP, przy czym nie precyzuje sposobu tej współpracy. Ze specyfikacji protokołu JSEP [6] wynika, że dostarcza on maszyny stanów do generowania oferty i odpowiedzi SDP z wykorzystaniem odpowiedniego interfejsu API (ang. Application Programming Interface). Można zatem, z dużym prawdopodobieństwem, przyjąć, że SDP i JSEP tworzą stos protokołowy SDP/JSEP, bez dodatkowego protokołu pośredniczącego. Hipoteza ta została

5 Model warstwowy ustanawiania sesji WebRTC 121 potwierdzona analizą kodów źródłowych przeglądarek Mozilla Firefox (wersje [12] i [13]) i Google Chrome (wersja [14]). Protokół SDP samodzielnie nie przesyła swoich komunikatów, wykorzystuje do tego celu protokoły podkładowe. Zgodnie z [6], protokół JSEP nie może zrealizować tej funkcji, gdyż nie posiada własnej pakietyzacji (enkapsulacji) ani własnych mechanizmów transmisji danych. Nie ma również zdefiniowanego styku międzywarstwowego z konkretnym protokołem transportowym (lub innym podkładowym). Specyfikacja [6] nakazuje natomiast wysyłanie komunikatu oferty SDP z wykorzystaniem "preferowanego mechanizmu sygnalizacyjnego (np. WebSockets)" 2. Oznacza to, de facto, pozostawienie tego zagadnienia architekturalnego do decyzji producenta przeglądarki internetowej. W efekcie tę część modelu można uszczegółowić jedynie przez ekstrakcję z kodów źródłowych przeglądarek. Dodatkową trudność stanowi konieczność uwzględnienia w modelu części wyniesionej bramki sygnalizacyjnej, umożliwiającej współpracę terminalu WebRTC z terminalem Vo korzystającym z sygnalizacji S. Model bramki sygnalizacyjnej został opracowany na podstawie dokumentacji i kodów źródłowych oprogramowania JsS v [15] oraz Kamailio v4.4.0 [16]. Bezpieczna Transportowa SDP JSEP Transportowa S WebSocket TLS terminal WebRTC bramka S Rys. 2. Wyekstrahowany model warstwowy ustanawiania sesji WebRTC Fig. 2. The extracted layered model of the WebRTC session Technika WebRTC jest obecnie standaryzowana przez grupę roboczą MMUSIC (z ang. Multiparty MUltimedia SessIon Control) IETF (ang. Internet Engineering Task Force). Przed kilkunastoma laty grupa ta opracowała architekturę MMUSIC [17][18], której sztandarowymi protokołami są transportowy RTP (ang. Real-time Transport Protocol) i sesyjny S (ang. Session Initiation Protocol). Z analizy dokumentacji WebRTC oraz kodów źródłowych przeglądarek Mozilla Firefox i Google Chrome wynika, że ustanawianie sesji WebRTC 2 "The offer is then sent off to the remote side over its preferred signaling mechanism (e.g., WebSockets)" [6].

6 122 A. Chodorek, R.R. Chodorek przypomina ideę zestawiania i rozgłaszania sesji, opracowaną na potrzeby architektury MMUSIC. Wyekstrahowany warstwowy model podsystemu ustanawiania sesji WebRTC pokazany został na rysunku 2. Obejmuje on protokoły od warstwy trzeciej (sieciowej) do piątej (sesji) modelu OSI/ISO. Wspólną platformę protokołową dla modelu stanowią protokół warstwy sieciowej modelu OSI/ISO oraz protokół SDP warstwy sesji. Tak jak w architekturze MMUSIC, protokół stanowi wspólną platformę dla całej techniki WebRTC (por. modele zawarte w pracach [4, 5, 7]). SDP realizuje funkcję abstrakcji sygnalizacyjnej z modelu [11]. Model składa się z dwóch zasadniczych części, terminalowej (obligatoryjnej) i bramki (opcjonalnej), których granica przebiega w poprzek warstw, a linię podziału wyznacza stosowalność protokołu JSEP (rys. 2). Część terminalowa to część, w której protokołem podkładowym dla SDP jest protokół JSEP. Jest ona używana do komunikacji pomiędzy terminalami WebRTC (przeglądarkami WWW). Część, w której protokołem podkładowym dla SDP jest protokół S, to część wyniesiona (do przeglądarki) bramki sygnalizacyjnej, pośredniczącej w transmisji pomiędzy terminalem WebRTC a terminalem S. Transmisja taka może być wykonywana podczas łączenia terminalu WebRTC z systemem telefonii Vo lub dowolnym innym systemem komunikacji multimedialnym zbudowanym zgodnie z MMUSIC Ekstrakcja modelu terminalu W przypadku części terminalowej, protokół SDP współpracuje bezpośrednio z protokołem JSEP. Protokół JSEP dostarcza maszynę stanu, która realizuje obsługę komunikatów SDP zgodnie z modelem Oferta/Odpowiedź (ang. Offer/Answer). Ponieważ SDP nie wysyła samodzielnie swoich komunikatów, JSEP jest odpowiedzialny (na poziomie warstwy sesji) za wymianę komunikatów oferty SDP i odpowiedzi SDP. Należy przypomnieć, że (w przeciwieństwie do protokołu S) również i JSEP nie wysyła własnych komunikatów, wewnątrz których przesyłałby wiadomości SDP. Do tego celu wykorzystywana jest usługa transportowa dostarczana przez protokoły podkładowe. Dokument roboczy [6] nie precyzuje, za pomocą których protokołów i w jaki sposób mają zostać przesłane oferta SDP i odpowiedź SDP. Wskazuje jedynie, że należy to robić metodą preferowaną przez nadawcę. Wskazywana w dokumentacji dowolność doboru mechanizmu transportowego została uwzględniona w modelu warstwowym ustanawiania sesji WebRTC przez umieszczenie tam dwóch warstw (bloków funkcjonalnych): Transportowa oraz Bezpieczna Transportowa. Są to dowolne usługi transmisyjne, realizowane z wykorzystaniem dowolnego protokołu transportowego oraz dowolnej metody ochrony kryptograficznej (lub bez ochrony przesyłanych danych).

7 Model warstwowy ustanawiania sesji WebRTC 123 Przykładową usługą transportową podaną w dokumencie [6] do przesyłania komunikatów SDP jest usługa oparta na interfejsie gniazd WebSockets (WS). Komunikaty SDP są wówczas przesyłane wewnątrz pakietów Websockets 3, które następnie są kapsułkowane w pakiety, a te z kolei kapsułkowane są w datagramach. Analiza komunikatów wysyłanych przez przeglądarki Mozilla Firefox, Google Chrome oraz Microsoft Edge i przechwyconych za pomocą programu WireShark wykazała, że przesyłały one komunikaty SDP za pomocą interfejsu gniazd WS. Na podstawie analizy kodu źródłowego przeglądarek Mozilla Firefox i Google Chrome można stwierdzić, że w praktyce istnieje również możliwość skorzystania z "bezpiecznego" interfejsu gniazd WebSockets (ang. WebSockets Security, WSS), w którym pakiet WebSockets przenoszący komunikat protokołu SDP jest zabezpieczany kryptograficznie z wykorzystaniem protokołu TLS 4. Przykład ustanawiania sesji pomiędzy dwiema przeglądarkami WWW, z których prawa implementuje część terminalową i bramkę, a lewa tylko obligatoryjną część terminalową, został pokazany na rysunku 3. Widoczne na rysunku przeglądarki komunikują się ze sobą z wykorzystaniem typowego stosu protokołowego WS//. Bezpieczna SDP SDP JSEP JSEP S WebSocket Bezpieczna WebSocket TLS TLS Rys. 3. Ustanawianie sesji WebRTC pomiędzy dwiema przeglądarkami WWW Fig. 3. The connection setup between two Web browsers 3.3. Ekstrakcja modelu bramki Typowo terminale Vo budowane są zgodnie z architekturą MMUSIC. Ze względu na różne protokoły sygnalizacyjne (JSEP w WebRTC, S w Vo), terminal WebRTC nie jest w stanie bezpośrednio połączyć się z terminalem Vo, choć wykorzystanie tego samego protokołu transportowego (RTP) pozwala na przesyłanie pomiędzy tymi terminalami informacji multimedialnej. Rozwiązaniem tego problemu jest zastosowanie bramki sygnalizacyjnej S, która dokonuje konwersji sygnalizacji z SDP/JSEP na SDP/S. Współpraca terminalu 3 Interfejs gniazd WebSockets wprowadza własną pakietyzację. 4 Komunikaty SDP są wówczas wysyłane z wykorzystaniem stosu protokołowego WS/TLS// (stosowany jest również zapis: WSS//).

8 124 A. Chodorek, R.R. Chodorek WebRTC z terminalami używającymi S została omówiona, między innymi, w pracy [19]. Typowo, bramka sygnalizacyjna S funkcjonalnie składa się z: części wyniesionej, strukturalnie należącej do przeglądarki, części pośredniczącej, pozostającej w strukturze bramki. Część wyniesiona dokonuje konwersji sygnalizacji. Z analizy oprogramowania JsS v wynika, że w praktyce odbywa się to przez bezpośrednie wysłanie z terminalu WebRTC komunikatu SDP (oferty lub odpowiedzi) przenoszonego wewnątrz komunikatu S. Część wyniesiona bramki sygnalizacyjnej pomija zatem protokół JSEP i korzysta bezpośrednio ze stosu protokołowego SDP/S (rys. 2). W tej sytuacji część pośrednicząca bramki sygnalizacyjnej S odbiera komunikat S i jedynie dokonuje konwersji transportu ze stosu protokołowego WS/ (ewentualnie WSS/) na protokół transportowy wykorzystywany przez terminal Vo. W przykładzie pokazanym na rysunku 4 jest to protokół UDP. SDP SDP JSEP S S S Bezpieczna WebSocket TLS WebSocket TLS UDP UDP Rys. 4. Ustanawianie sesji WebRTC pomiędzy przeglądarką WWW a terminalem Vo Fig. 4. The connection setup between a browser and a Vo terminal 4. Zakończenie W artykule został zaprezentowany model warstwowy ustanawiania sesji WebRTC, opracowany na podstawie analizy dokumentacji i zaimplementowanego oprogramowania. Model ten pokazuje powiązania funkcjonalne stosu protokołowego SDP/JSEP, biorącego udział w ustanawianiu sesji, oraz umiejscawia stos protokołowy SDP/JSEP na schemacie blokowym podsystemu WebRTC odpowiedzialnego za ustanawianie sesji. Model zawiera również stos protokołowy SDP/S, wykorzystywany podczas połączeń z terminalami Vo. Proponowany model może posłużyć do uzupełnienia istniejących modeli warstwowych WebRTC o blok ustanawiania sesji. Może też stanowić punkt wyjścia do opracowania nowego modelu warstwowego (funkcjonalnego, strukturalnego lub hybrydowego).

9 Model warstwowy ustanawiania sesji WebRTC 125 BIBLIOGRAFIA 1. Ducasse S., Pollet D.: Software Architecture Reconstruction: A Process-Oriented Taxonomy. IEEE Trans. on Software Engineering, vol. 35, No. 4, 2009, s Lutellier T., Chollak D., Garcia J., Tan L., Rayside D., Kroeger R.: Comparing Software Architecture Recovery Techniques Using Accurate Dependencies. 37 th IEEE International Conference on Software Engineering (ICSE), IEEE/ACM Vol. 2, 2015, s Hassan A. E., Holt R. C.: Architecture recovery of Web Applications. Proceedings of the 24 rd International Conference on Software Engineering, ICSE 2002, s Loreto S., Romano S.P.: Real-Time Communication with WebRTC: Peer-to-Peer in the Browser. O'Reilly Media, Inc., Grigorik I.: High Performance Browser Networking, O'Reilly Media, Uberti J., Jennings C., Rescorla E. (ed.): Javascript Session Establishment Protocol. Internet-Draft draft-ietf-rtcweb-jsep-14, March 21, Jesup R., Loreto S., Tuexen M.: WebRTC Data Channels. Internet-Draft draft-ietfrtcweb-data-channel-13, January 4, Chodorek A., Chodorek R.R.: Analiza porównawcza wybranych modeli architektury WEBRTC. Przegląd Telekomunikacyjny, 89 (6), Handley M., Jacobson V., Perkins C.: SDP: Session Description Protocol. Request for Comments: 4566, July Nandakumar S., Jennings C.: SDP for the WebRTC. Internet-Draft draft-ietf-rtcwebsdp Architecture. URL: URL: source.tar.xz 13. URL: source.tar.xz 14. Download Chromium tarball. URL: JsS: The JavaScript S Library. URL: Kamailio S Server. URL: Handley M., Crowcroft J., Bormann C., Ott J.: The Internet Multimedia Conferencing Architecture. Internet-Draft draft-ietf-mmusic-confarch-03, Chodorek R.R., Pach A.R.: Transmisja multikastowa w sieciach. Wydawnictwo Fundacji Postępu Telekomunikacji, Kraków 2003.

10 126 A. Chodorek, R.R. Chodorek 19. Chodorek R.R., Rzym G., Wajda K., Chodorek A.: Współpraca techniki WEBRTC z systemami wykorzystującymi S. Przegląd Telekomunikacyjny, 89 (6), Abstract The Session Description Protocol (SDP) [9] and the Javascript Session Establishment Protocol (JSEP) [6] are signaling protocols that are used during the WebRTC connection setup and session establishment. Although the overall architecture of the WebRTC (Fig. 1) reported in [11] shows the Session management/abstract signaling functional block, layered models of the WebRTC [4][5][7] contain no protocol stacks used for session establishment. In this paper a new, layered model of the WebRTC session establishment, made based on the literature and an analysis of software implementations, is presented. This model is shown in Fig. 2 and consists of two parts, the WebRTC terminal and the S gateway, that mirror structural features of WebRTC applications. The WebRTC terminal part is obligatory for WebRTC applications. Its layered model focuses on relationships between the SDP/JSEP protocol stacks and the underlying protocols. The WebRTC terminal consists of four protocol stacks. Because, as is mentioned in [6], SDP messages (offer and answer) should be send to the remote station using "its preferred signaling mechanism", the first two stacks use a general Secure Transport Service (STS, "Bezpieczna Transportowa" in Fig. 2.) or a general Transport Service (TS, " Transportowa" in Fig. 2.). They are SDP/JSEP/TS/ and SDP/JSEP/STS/ protocol stacks. The second two stacks uses WebSockets (WS) API (SDP/JSEP/WS//) and secure WebSockets (SDP/JSEP/ WS/TLS// stack). An example of multimedia transmission carried out directly between WebRTC terminals (Web browsers) using WebSockets is depicted in Fig. 3. The S gateway part is optional. It contains protocol stacks, which functionally belong to a S signaling gateway - SDP/S/WS// and SDP/S/WS/TLS//. Fig. 4 shows an example of voice transmission carried out between a WebRTC terminal (Web browser - left) and a Vo terminal (right) with the use of a signaling gateway (in the middle). Adresy Agnieszka CHODOREK: Politechnika Świętokrzyska, Katedra Systemów Informatycznych, Al. Tysiąclecia Państwa Polskiego 7, Kielce, a.chodorek@tu.kielce.pl Robert Ryszard CHODOREK: AGH Akademia Górniczo-Hutnicza, Katedra Telekomunikacji, Al. A. Mickiewicza 30, Kraków, chodorek@agh.edu.pl