Disseny d’una xarxa de videoconferència d’alta qualitat per camins òptics

TREBALL DE FI DE CARRERA TÍTOL: Disseny d’una xarxa de videoconferència d’alta qualitat per camins òptics AUTOR: Montserrat Buch i Tarrats DIRECTOR: Alcober Segura, Jesús DATA: 24 febrer 2006 2 2 Títol: Disseny d’una xarxa de videoconferència d’alta qualitat per camins òptics Autor: Montserrat Buch i Tarrats Director: Alcober Segura, Jesús Data: 24 febrer 2006 Resum Aquest treball estudia un escenari de videoconferència d’alta qualitat per camins de fibra òptica. Es fa una descripció dels equips que intervenen, protocols i millores que es poden posar. Maximitzar el rendiment i minimitzar els costos d’una futura implementació de l’escenari de videoconferència són els objectius d’aquest projecte. Utilitzant programari de lliure distribució i de codi obert. Primer es fa un estudi dels protocols que intervindran a l’escenari; El protocol SIP és el protocol de senyalització que s’utilitza per iniciar sessions interactives multimèdia entre els usuaris. És un protocol lliure y obert a noves tecnologies. El GMPLS és el protocol de transport que proporciona gran ample de banda i pensat per aplicacions de videoconferència. Amb el protocol SNMP podem gestionar nodes d’una xarxa, comunicar la informació de gestió entre estacions de gestió de xarxa. També nomenarem el SOAP/HTTP necessari per la invocació de processos remots, el MSML s’encarrega del control i configuració de recursos mèdia; crear una conferència, afegir nous participants... S’usa per invocar diferents classes de serveis en sessions individuals, sessions en grup i conferències i el MOML defineix objectes per el processat de fluxos de multimèdia com play i record. Es veuran els elements que utilitzen aquests protocols i com a poc a poc es va formant el disseny d’una xarxa de videoconferència d’alta qualitat per camins òptics. 3 Title: Design of a high quality scene of videoconference by optical fiber ways Author: Montserrat Buch i Tarrats Director: Alcober Segura, Jesús Date: February, 24th 2006 Overview This work studies high quality scene of videoconference by optical fiber ways. We make a description of the elements, protocols and improvements of this scene. To maximize the yield and to diminish the costs of a future implementation of the videoconference scene are the objectives of the project. We made use free software and open code software. First study becomes of the protocols that take part to the scene; The SIP protocol is the signalling protocol that is used to initiate interactive multimedia sessions between users. Is a free protocol an open to a new technologies. The GMPLS protocol is the transport protocol that provides great bandwidth and is used for applications of videoconference. With the SNMP protocol we can manage nodes of the network, to communicate the information of management between stations of network management. Also we will name the SOAP/HTTP that is necessary for the invocation of remote processes; the MSML is in charge of the control and the configuration of media resources; to create a conference, to add new participants... It is used to invoke different types of service in individual sessions, sessions in group and conferences and the MOML defines objectives for the processing of flows of multimedia like play and record. We will see the elements that use these protocols and how the design of the scene take body and result the network of high quality videoconference by optical ways. 4 Agraïments Agraeixo la col·laboració i el recolzament d’algunes de les persones que m’han ajudat directament o indirectament a la realització d’aquest projecte. • A Jesús Alcober, director i supervisor del projecte, per la seva experiència i ajuda en la realització del treball. • A Pedro Díaz i Alberto Gonzalez per estar sempre al meu costat quan em perdia durant el projecte. • A Pedro Lorente per ajudar-me en fer les proves dels escenaris a MediaCAT. • A la família pel recolzament moral. • A companys i companyes universitaris i del pis pels consells i els dinars a la platja. 5 ÍNDEX DE CONTINGUTS CAPÍTOL 1. INTRODUCCIÓ.........................................................................9 1.1 Motivació i objectius..........................................................................9 1.1.1 ¿Què és I2Cat?.............................................................................9 1.1.2 Projecte PROMISE.......................................................................9 1.1.3 Motivació.....................................................................................10 1.1.4 Objectius del projecte .................................................................10 1.1.5 Recursos.....................................................................................10 1.2 Conceptes projecte PROMISE ........................................................ 11 1.2.1 Estat............................................................................................ 11 1.2.2 Aplicacions HDTV.......................................................................11 1.3 Altres conceptes..............................................................................14 1.3.1 GUNI...........................................................................................14 1.3.2 Mòdul Transcodificador...............................................................14 CAPÍTOL 2. ESTAT DE L’ART................................................................... 15 2.1 Protocols ..........................................................................................15 2.1.1 SIP (session Initiation Protocol)..................................................15 2.1.2 SNMP (Simple Network Management Protocol).........................15 2.1.3 GMPLS (Multi-Protocol Label Switching)....................................16 2.1.4 SOAP/HTTP................................................................................17 2.2 Mòdul Transcodificador ..................................................................18 2.2.1 Descripció del maquinari.............................................................18 2.3 GUNI..................................................................................................19 2.3.1 Descripció...................................................................................19 CAPÍTOL 3. DISSENY DE L’ARQUITECTURA..........................................21 3.1 Esquema de la xarxa........................................................................21 3.1.1 Usuari .........................................................................................21 3.1.2 Servidor d’aplicacions................................................................. 22 3.1.3 GUNI...........................................................................................22 3.1.4 Servidor de media....................................................................... 23 3.1.5 Processadors de media.............................................................. 23 3.1.6 Xarxa òptica................................................................................23 CAPÍTOL 4. IMPLEMENTACIÓ.................................................................. 24 4.1 Escenari 1......................................................................................... 24 4.1.1 Funcionament.............................................................................24 6 4.1.2 Proves de l’escenari 1.................................................................25 4.1.3 Conclusions ................................................................................27 4.2 Escenari 2......................................................................................... 27 4.2.1 Funcionament.............................................................................27 4.2.2 Proves de l’escenari 2.................................................................27 4.2.3 Conclusions ................................................................................29 4.3 Escenari 3......................................................................................... 30 CAPÍTOL 5. PLANIFICACIÓ I COSTOS.....................................................31 5.1 Costos...............................................................................................31 5.2 Planificació.......................................................................................31 CAPÍTOL 6. CONCLUSIONS...................................................................... 33 6.1 Objectius........................................................................................... 33 6.2 Conclusions personals....................................................................33 6.3 Impacte medi ambiental ..................................................................33 CAPÍTOL 7. BIBLIOGRAFIA ......................................................................35 7.1 Referències.......................................................................................35 7.2 Projectes...........................................................................................35 Annexa 1. Intercanvi de missatges SIP.....................................................37 Annexa 2. Funcionament dels protocols MSML i MOML......................... 41 7.3 MSML ................................................................................................41 7.4 MOML................................................................................................41 Annexa 3. Mòdul de transcodificador.......................................................43 7.5 Funcionalitats del sistema;............................................................. 43 7.5.1 Localització de recursos media................................................... 43 7.5.2 Execució de recursos média.......................................................43 7.5.3 Gestió de búsqueda de recursos................................................43 7.6 Diagrames de cas d’us....................................................................43 7.6.1 Mòdul Autentificació....................................................................43 7.6.2 Mòdul de localització de recursos............................................... 43 7 7.6.3 Mòdul de localització de processadors de media........................44 7.6.4 Mòdul provisió de serveis ...........................................................44 7.6.5 Mòdul de Gestió..........................................................................45 7.6.6 Mòdul de funcionalitats de grups ................................................47 7.6.7 Mòdul d’informació del sistema...................................................47 7.7 Descripció.........................................................................................48 7.7.1 JAIN SIP.....................................................................................48 7.7.2 SipServlet ...................................................................................48 7.7.3 Tomcat........................................................................................ 49 Annexa 4. Configuració X-Lite...................................................................50 7.8 Servei VoIP SIP - VIDECAT..............................................................50 7.8.1 Usuaris de prova.........................................................................50 7.8.2 Configuració X-Lite .....................................................................50 8 ÍNDEX D’IMATGES Fig. 1.1 – Esquema de l’escenari 1 de PROMISE............................................12 Fig. 1.2 – Esquema de l’escenari 2 de PROMISE............................................13 Fig. 1.3 – Esquema escenari 3 de PROMISE .................................................. 13 Fig. 2.4 - GMPLS work per Plane.....................................................................16 Fig. 2.5 – mòdul transcodificador .....................................................................18 Fig. 2.6 – Disseny del G-UNI............................................................................20 Fig. 3.7 - Xarxa per una comunicació que requereix gran ample de banda.....21 Fig. 3.8 – esquema escenari 1 amb connexió a Internet..................................24 Fig. 4.9 – Client Web de MediaCAT................................................................. 25 Fig. 4.10 – Petició del vídeo sota demanda de l’escenari 1 ............................. 25 Fig. 4.11 – esquema escenari 2 amb xarxa privada......................................... 27 Fig. 4.12 – Petició del vídeo de l’escenari amb xarxa privada.......................... 28 Fig. 4.13 – Esquema escenari 3 amb el GUNI................................................. 30 Fig. 5.14 – Planificació del treball..................................................................... 32 Fig. 5.15 progressió del projecte......................................................................32 9 CAPÍTOL 1. INTRODUCCIÓ En aquest capítol es farà una introducció del projecte, els seus objectius i la definició de conceptes per tal d’entendre el seu funcionament. 1.1 Motivació i objectius Abans de començar l’explicació dels motius i dels objectius del treball final de carrera vull destacar que aquest projecte forma part d’un projecte integrat. Per tant, s’ha fet una petita explicació al respecte, així com descriure el treball fet prèviament pel fi de comprendre millor els objectius que pretén aquest projecte. 1.1.1 ¿Què és I2Cat? “i2Cat és una Fundació privada sense ànim de lucre, que té com a finalitat impulsar la innovació i la recerca en l’àmbit d’Internet de segona generació a Catalunya”. i2Cat realitza projectes de recerca i d’innovació aplicada que es re-alimenten entre sí.” [1] La fundació i2CAT va ser creada per la Generalitat de Catalunya a través de la Secretaria de Telecomunicacions i Societat de la Informació (STSI) i el Cidem, amb la universitat Politècnica de Catalunya (UPC) i la Fundació Catalana per a la Recerca. També hi participen diferents entitats i empreses tant de l’àmbit públic com del privat. 1.1.2 Projecte PROMISE La pàgina web de PROMISE és http://www.celticinitiative.org/Projects/PROMISE/default.asp. PROMISE proporcionarà unes solucions per construir i demostrar experimentalment el transport d’una xarxa òptica dinàmica, self-organitzada i fully service-oriented, per trobar les futures necessitats dels serveis òptics per el tràfic de dades. El projecte suportarà serveis avançats d’alta capacitat, de ample de banda sota demanda en VPNs òptiques, qui et garantirà qualitat punt a punt i sobre una infraestructura de xarxa òptica adaptable. PROMISE treballarà amb la investigació de; la implementació, elements de xarxa, programari de control, programari de gestió i especialment els serveis i aplicacions que aprofiten al màxim el rendiment i la capacitat de la xarxa. El resultat essencial serà el pla de control del test-bed per mostrar el aprovisionament i el manteniment dels serveis òptics en un context real com a prova de la viabilitat de proporcionar serveis avançats i com a eina per identificar les edicions que es resoldran abans del desplegament comercial. El projecte enfocarà els següents objectius; • Experimentar i demostrar flexibles i intel·ligents solucions de xarxa òptica, un prototip de construcció avançada de la innovació del transport, control i pla de gestió. 16 Quan una entitat de protocol envia un missatge, realitza les següents accions; 1. Construeix la PDU apropiada com un objecte definit amb el llenguatge ANS.1 2. Ho envia, juntament amb un nom de comunitat i les direccions de transport d’origen i destí, a un servei d’autentificació. Aquest servei generarà com a resposta un altre objecte en ASN.1 3. Ara, l’entitat construeix un missatge usant l’objecte que l’ha tornat el servei d’autentificació i el nom de comunitat 4. Aquest nou objecte s’envia a l’entitat destí utilitzant un servei de transport. Quan una entitat de protocol rep un missatge, realitza les següents accions; 1. Fa un petit anàlisis per veure si el paquet rebut correspon amb un missatge en ASN.1. Si no el reconeix, el paquet és descartat i l’entitat no realitza més accions. 2. Observa el número de versió. Si no concorda, el paquet és descarta. 3. Passa les dades d’usuari, el nom de comunitat i les direccions de transport d’origen i destí del servei d’autentificació. Si és correcte, aquest torna un objecte. Si no ho és, envia una indicació d’error. Llavors l’entitat de protocol pot generar una trama (trap), descarta el paquet i no realitza més accions 4. L’entitat intenta reconèixer la PDU. Si no la reconeix, descarta el paquet. En cas contrari, segons el nom de la comunitat adopta un perfil i processa la PDU. Si la PDU exigeix resposta, l’entitat iniciarà la resposta. 2.1.3 GMPLS (Multi-Protocol Label Switching) És un protocol de transport que té moltes especificacions però que he considerat en aquest punt és el RFC3945 Generalized Multi-Protocol Label Switching (GMPLS) Architecture. GMPLS ens proporciona l’ample de banda necessari per la utilització d’aplicacions de Videoconferència. Realitza el control de la trucada i funcions de control de connexió. Per la senyalització, el pla de control instal·la i realitza connexions i pot les pot restaurar en cas d’errors. GMPLS consisteix en un conjunt de protocols que suporten la creació d’una capa de control unificada on tots els dispositius de commutació es comuniquen punt a punt. Fig. 2.4 - GMPLS work per Plane 17 2.1.3.1 RSVP-TE (Resource ReserVation Protocol - Traffic Engineering) Hi ha un acord entre dos possibles nodes que cooperen amb els altres nodes que proporcionen accés a la xarxa. Per tant, hauria d’incloure “capability exchange”, control de policia, autorització i seguretat. S’utilitza per facilitar i administrar una sèrie de connexions que proporcionen serveis punt a punt. Mentre les connexions requereixen un estat pel manteniment dels nodes al llarg del camí de la xarxa, les trucades no involucren la participació dels nodes de transit excepte per transportar les trucades de demanda d’administració com missatges transparents. La trucada es pot establir i mantenir independentment de les connexions que suporta. Hi ha una relació entre trucades i connexions. Una o varies connexions han d’estar associades a una trucada. Una connexió no hauria de formar part de més d’una trucada. Una connexió podria existir sense una trucada. En GMPLS RSVP-TE [RFC3473], una connexió s’identifica amb el GMPLS TE Tunnel. El números de identificació de les trucades són únics en el context del parell d’adreces que són l’origen i el destí de la trucada. Els números d’identificació del Tunnel són únics dintre del context de la Sessió (que és la destinació del Tunnel). Les aplicacions poden trobar convenient això d’agafar el número d’identificació únic del Tunnel dins del context d’una trucada. Al igual que la resta de números d’identificació, el LSP (Label Switched Path) és únic dintre del context del Tunnel. [4] 2.1.4 SOAP/HTTP SOAP és un protocol d’alt nivell que està especificat al RFC3288 i al RFC3902. És un protocol de missatgeria XML que forma la base dels Serveis Web i utilitzat per la invocació de processos remots. SOAP proporciona un mecanisme simple que permet a una aplicació enviar missatges XML a una altre aplicació. Els missatges es poden combinar per suportar molts comportaments de comunicació incloent-hi sol·licitació / resposta, resposta sol·licitada, missatgeria asíncrona, o inclòs notificació. SOAP defineix l’estructura del missatge i unes poques normes pel seu processament. És completament independent del protocol de transport, per això els missatges SOAP es poden intercanviar sobre HTTP, JMS o protocols de transport de correu electrònic. Actualment el protocol HTTP és el més utilitzat. o Avantatges  No està associat a cap llenguatge  No s’associa a cap protocol de transport  No està lligat a cap infraestructura d’objecte distribuït  Reutilitza els estàndards existents a la industria  Permet la interoperabilitat entre múltiples entorns 18 2.2 Mòdul Transcodificador El transcodificador és un servidor capaç d’adaptar els diferents protocols propietaris dels processadors media de contingut audiovisual al protocol estàndard. El seu objectiu és proporcionar senyalització de serveis a usuaris mitjançant el protocol H323, SIP o HTTP/SOAP, per permetre l’accés als serveis de transport de processadors de media. Fig. 2.5 – mòdul transcodificador El projecte es centrarà en el mòdul de camí òptic que s’aplicarà al servei d’aplicació del mòdul de transcodificador. (Al annexa 3 hi ha l’especificació del transcodificador; funcionalitats i diagrames de cas d’us, i al annexa 2 explica el funcionament dels protocols MSML/MOML que surten a la figura 2.5) 2.2.1 Descripció del maquinari A continuació es fa una breu descripció del maquinari que forma el mòdul de transcodificador. 2.2.1.1 Servidor d’aplicacions El servidor d’aplicacions usat és el Tomcat i el llenguatge de programació és amb Java. És un element que rep una petició d’un recurs de media i és capaç de processar-la i servir-la. La petició ha d’indicar 1. Nom del recurs (títol de la pel·lícula) 2. direcció IP on s’ha d’enviar el flux 3. número de port que escolta el reproductor de media. Processa la petició i indica al controlador de servidors de media que comenci a executar el recurs (play o stop). 2.2.1.2 Servidor media Plataforma que executa accions de media a temps real (play, pausa, stop o moderar una so / vídeo conferència. S’encarrega d’executar la petició enviada per el servidor d’aplicacions i és qui coneix els protocols propietaris existents. 19 El servidor media pot ser el VLS (Video LAN Server). El VLS pot realitzar streaming de MPEG-1, MPEG-2, fitxers MPEG-4, DVD, canals de satèl·lit digital, canals de televisió terrestre digital. Està dedicat a servidors que compilen sota LINUX, Windows i Mac OS X. Tal i com indica a la pàgina web el VLS no està en un desenvolupament molt actiu i la funció del streaming de sortida aconsellen utilitzar el VLC (Video Lan Client). El VLC media player es pot utilitzar com un servidor de streaming MPEG-1, MPEG-2 i MPEG-4 / fitxers DivX, DVDs o com un client. Treballa sota Linux, Windows, Mac OS X, BeOS, *BSD, Solaris, Familiar Linux i QNX. 2.2.1.3 Processadors de media Elements que contenen físicament els recursos. 1. VideoLAN – Servidor de streaming, que permet emetre fluxos de dades de vídeo a temps real (arxius MPEG-1, MPEG-2, PEG-4, DVD, canals digitals per satèl·lit o vídeos en temps real a través d’una xarxa unicast o multicast) 2. Darwin – Servidor que envia streaming d’arxius en format QuikTime, MPEG-4, 3GPP a través dels protocols RTP/RTSP 3. Asterix – Servidor que ofereix totes les característiques d’una centraleta telefònica (PBX). Ofereix missatges de veu, comunicació d’una trucada [5] 2.3 GUNI Actualment, el mòdul de transcodificació ens permet, als usuaris, consultar i accedir a serveis multimèdia com Veu sota demanda, Vídeo sota demanda, Veu i Vídeo conferencia, Televisió i Radio. Com s’ha dit anteriorment el que volem aconseguir és que tots aquests serveis multimèdia estableixin els seus camins òptics automàticament, que per això hem d’afegir un nou servidor que es comunica amb el mòdul de camí òptic; el GUNI 2.3.1 Descripció El llenguatge de programació utilitzat per aquest projecte serà el Java. Els serveis s’implementaran com uns serveis web, usant l’últim estàndard WSDL d2isponible. La plataforma que usarem per desenvolupar-ho tot serà el Jakarta Tomcat v5.0. El servidor serà el Apache Axis v1.2. que compleix l’especificació WSDL. G-Uni proporciona Gestió de la connexió (manageConnection) i funcionalitats de monitoratge(monitorConnection). Les funcionalitats de monitoratge encara no està definit. En canvi, la gestió de la connexió si que té definides unes funcions genèriques; getConnection – obrirà una connexió en una xarxa òptica, donant uns pocs paràmetres endConnection – Tancarà una connexió oberta isReachable – verificarà que el node està en una xarxa òptica 20 isAvailable – verificarà que el node és apte per obrir una connexió, donant uns pocs paràmetres. Hi haurà un servei d’alt nivell per cada un d’aquests casos. S’usarà un software. També definirem algunes classes de sistema; GUNIConnection – classe domini que representarà una probable connexió amb la xarxa òptica. Al menys tindrà un atribut, idConnection, que identificarà una connexió única. GUNIException – Del java.lang.Exception, per exemple, es responsabilitzarà de representar un error quan n’hi hagi un. GUNIConnectionController – Controlador per cas del manageConnection GUNIMonitorController – El controlador del cas del monitorConnection Les classes del controlador es desenvoluparà en una infraestructura de servei, donant accés a ells com serveis als seus mètodes públics. Aquests mètodes públics seguirà el diagrama de funcionalitats. Fig. 2.6 – Disseny del G-UNI 21 CAPÍTOL 3. DISSENY DE L’ARQUITECTURA Aquest capítol s’explica el disseny de l’arquitectura estudiada de la xarxa de videoconferència i el seu funcionament teòric. 3.1 Esquema de la xarxa Aquest és un esquema de la xarxa que es pretén implementar per aconseguir que una comunicació Unicast que requereix un ample de banda molt pesant arribi al client per la xarxa òptica automàticament. Fig. 3.7 - Xarxa per una comunicació que requereix gran ample de banda 3.1.1 Usuari L’usuari té dues formes de comunicar-se al mòdul transcodificador. La primera és utilitzar una aplicació Web i l’altre és mitjançant un client SIP. Es va fer d’aquesta manera perquè abans de demanar la reproducció del recurs és provable que l’usuari primer vulgui buscar els recursos disponibles. http://luigi.i2cat.net:8080/axis/services/ GUNIConnectionController http://84.88.32.17:8080/examples/ Vistas/index.jsp 22 Per això l’aplicació Web. Aquesta comunicació es realitzarà a través d’una interfase basada en HTTP/SOAP1. El client SIP que utilitzarem és el X-Lite (al annexa 4 hi ha una configuració del X-Lite amb un proxy SER). Software de lliure distribució i que es pot descarregar a la pàgina http://www.xten.com/ . Tal i com ens explica a la guia del X-Lite, el programa és un SIP User Agent, és una aplicació que pot transformar el PC o el Pocket PC en un telèfon. SIP és el protocol de senyalització usat per establir les sessions entre hosts d’una xarxa IP Un altre client que s’usarà també serà el VLC (Video LAN Client). També és un programa de lliure distribució i que es pot descarregar de la pàgina http://www.videolan.org/ . Es pot fer servir per realitzar streaming de mpeg-1, mpeg-2, fitxers MPEG-4 i DVD o utilitzar-se com a client per rebre aquests fluxos de vídeo. 3.1.2 Servidor d’aplicacions És l’element que rep una petició d’un recurs de multimèdia i és capaç de processar-la i servir-la. Per exemple, el client envia una petició com pot ser la reproducció d’una pel·lícula. Aquesta petició ha de tenir el nom del recurs (com per exemple el títol de la pel·lícula), el nom del processador de media que oferirà el recurs, la direcció IP i el port pel qual escolta el reproductor de media. Hem de tenir en conte que la direcció IP corresponen al de la xarxa òptica pel qual escolta, no és la direcció IP pel qual el client fa la petició, que correspon a la IP d’una xarxa de Internet. Aleshores el servidor d’aplicacions envia una petició al GUNI perquè li estableixi el camí òptic en el Vídeo LAN i el client. Una cop arribats a aquest punt, el servidor d’aplicacions processarà la petició i li indicarà al controlador de servidors de media que comenci a executar el recurs (play, stop... ). La comunicació entre el servidor d’aplicacions i el servidor de media és per MSML/MOML2 sobre SIP. Els protocols MSML i MOML estan explicats al annexa 2. 3.1.3 GUNI El GUNI s’encarrega d’establir el camí òptic entre l’usuari i el VideoLAN per SNMP3. Si s’ha pogut establir un camí òptic a la xarxa GMPLS el protocol SNMP és el que s’encarrega de tornar un missatge de conformitat o un Trap (missatge d’error) en cas contrari. La Xarxa GMPLS troba un camí òptic gràcies al protocol RSVP-TE4 1 El protocol SOAP està explicat a l’apartat 2.1.4 2 MSML(Media Session Markup Language) / MOML (Media Object Markup Language) 3 SNMP és un protocol ja descrit al punt 2.1.2 4 Mireu l’apartat 2.1.3 per recordar el funcionament dl RSVP-TE 23 3.1.4 Servidor de media El servidor de media és la plataforma que s’encarrega d’executar les accions de media a temps real (play, pause, stop d’un recurs, o moderar una so/vídeo conferència. És el que es comunica directament amb el processador de media, per tant ha de conèixer els protocols propietaris existents i traduirà al protocol propietari de cada processador de media. 3.1.5 Processadors de media Són els elements que contenen físicament els recursos. Aquests elements ja estan estudiats al apartat 2.2.1.3 3.1.6 Xarxa òptica La xarxa òptica a la que disposem funciona sobre el protocol GMPLS també estudiat al punt 2.1.3 24 CAPÍTOL 4. IMPLEMENTACIÓ En aquest capítol s’explicaran les fases que s’han seguit per l’estudi de la xarxa explicada al capítol anterior. 4.1 Escenari 1 Aquest és l’escenari més senzill. Consta en connectar el client i el mòdul transcodificador a la xarxa de Internet. L’esquema correspon a la figura següent; Fig. 3.8 – esquema escenari 1 amb connexió a Internet 4.1.1 Funcionament Els clients per la reproducció de vídeo usarem el VLC. L’adreçament del client serà públic. La implementació de la aplicació Web es fa possible mitjançant pàgines JSPs que són ateses per un servlet. Quan el servlet rep la petició busca quin gestor s’encarregarà d’atendre’l. Una vagada que té el gestor adequat executa la petició i torna els resultats a la pàgina JSP A continuació es mostra una figura de la pàgina JSP on se li envia la petició i ell busca el recurs i l’envia al client de vídeo, que en aquest cas és el VLC. 25 Fig. 4.9 – Client Web de MediaCAT Recordem que tot el flux viatja per Internet. I això suposa un càrrega per la xarxa i un cert retard. Les mesures es faran amb el Ethereal, software de codi obert, que fa una captura dels paquets que arriben al client VLC i des de on podrem treure totes les conclusions d’aquest escenari. 4.1.2 Proves de l’escenari 1 Fig. 4.10 – Petició del vídeo sota demanda de l’escenari 1 32 Fig. 5.14 – Planificació del treball PDM(Precedence Diagramming Method) és un mètode que es basa en la utilització d’una xarxa en la que figura les activitats i el temps en els nodes, a la vagada que mostra la dependència. Permet la reflexió de diferents relacions de procedència entre tasques. Fig. 5.15 progressió del projecte Nota: La planificació del projecte s’anirà completant a mida d’anar progressant en el projecte. 33 CAPÍTOL 6. CONCLUSIONS 6.1 Objectius Recordem que els objectius del projecte son; Dissenyar i implementar una xarxa de Videoconferència sobre fibra òptica. • Dissenyar una xarxa de videoconferència unint diferents projectes ja creats per diferents plataformes de i2Cat. • Proposar una millora; mòdul d’establiment del camí òptic • El test-bed; Implementació de la xarxa de Videoconferència. No s’han pogut implementar tots els escenaris per falta de temps i per la dificultat que suposa acordar-se amb altres projectes en tan curt termini. Per això s’ha explicat en detall el que es feria i quins haurien de ser els resultats teòrics per facilitar el pròxim estudi. En quant al usuari, li proporciona facilitats a l’hora de comunicar-se sense la necessitat de desplaçar-se, en unes qualitats més òptimes i segures que les que proporciona Internet. Els escenaris estudiats són una via de millora per les aplicacions de videoconferència o futurs projectes que necessitin aquestes infraestructures pels seus estudis. Es poden implementar millores com; Dissenyar una nova aplicació que integri un client SIP per la reproducció de flux multimèdia. Integrar el servei de conferència amb l’aplicació. Desenvolupar nous serveis com pot ser la creació d’una videoconferència Fer les proves en escenaris reals de fibra òptica. 6.2 Conclusions personals El fet d’utilitzar una xarxa privada per la utilització de serveis que requereixen gran ample de banda és una millora pel fet que augmenta al màxim el rendiment de les aplicacions que necessiten d’aquest ample de banda i treuen l’apuro que tenen els operadors de reservar tals quantitats d’ample de banda que va tan escàs en la actualitat. Així es deixa també que les aplicacions que no és necessari tant ample de banda maximitzi el seu rendiment i no quedi en un últim pla. 6.3 Impacte medi ambiental El projecte no té un impacte ambiental molt gran. Potser pensareu que no té gaire sentit parlar d’aquest tema al projecte però si ens parem a pensar, les 34 màquines que intervenen als escenaris tenen un gasto energètic, i aquí ja hi ha un impacte ambiental per petit que sigui. Els equips, routers, ordinadors... estan oberts les 24 hores del dia i durant tot l’any. Això suposa un gasto energètic molt gran i aconsello utilitzar una energia renovable. Un aspecte important en aquest camp és que la videoconferència estalvia els desplaçaments i per tant la contaminació que podria fer el medi de transport utilitzat. També hem de tenir en comte el tema del cablejat de la xarxa de fibra òptica. Actualment ja hi ha molt cablejat de fibra òptica, però encara queda molt per fer i això també suposa un cost tan econòmic com mediambiental. 35 CAPÍTOL 7. BIBLIOGRAFIA 7.1 Referències [1] www.i2Cat.net [2] http://www.xten.com/index.php?menu=products&smenu=download pàgina web per descarregar-se el client SIP. [3] http://www.iptel.org/ser/ aquí es trobarà tota classe d’informació del SER [4] http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-ason-04.txt http://www.elrincondelprogramador.com/default.asp?pag=articulos/leer.asp&id= 29 Æ patrons de disseny [5] http://www.asterisk.org/ [6] Æ ajuda per la planificació del projecte. http://www.getec.etsit.upm.es/docencia/gproyectos/planificacion/planificacion.ht m 7.2 Projectes [7] Pedro Díaz, Implementación de una capa de control de Media Server, 20 de gener de 2005 36 ANNEXOS TÍTOL: Disseny d’una xarxa de videoconferència d’alta qualitat per camins òptics AUTOR: Montserrat Buch i Tarrats DIRECTOR: Alcober Segura, Jesús DATA: 24 febrer 2006 37 Annexa 1. Intercanvi de missatges SIP Per mirar el funcionament del SIP he utilitzat un programa de lliure distribució; X-lite [1] que actua com a client SIP (UA). La xarxa utilitza un servidor Proxy SER (SIP Express Router) [2]. Finalment he instal·lat el client SIP i he donat d’alta els UA, com a test2 i test3. Abans d’establir el camí òptic hi ha hagut una sèrie d’intercanvi de missatges (annexa 1) que es mostren al següent esquema; Aquest és l’intercanvi de missatges; Test2 vol comunicar-se amb el Test 3. Per això el UAS envia un REQUEST; INVITE al Servidor SER al què està donat d’alta (en el nostre exemple SER és sipedu.i2cat.net.) El format del missatge es pot veure a continuació; [email protected] t UAS [email protected] UAC SER UAC UAS INVITE 407, PROXY AUTH. ACK INVITE 100, TRAYING 100, TRAYING INVITE 180, RINGING 180, RINGING 200, OK 200, OK ACK ACK Accepta la trucada Camí òptic 38 El Servidor SER li reenvia un RESPONSE d’error, 407, Proxy Authentication Required. Llavors el UAS li envia un ACK per confirmar que ha rebut el missatge i seguidament li envia el INVITE, REQUEST amb el camp Proxy-Autrorization afegit. 39 Ara el servidor SER reenvia el REQUEST; INVITE al destinatari; test3. El SER li afageix un Via: amb la seva IP Quan UAC rep el INVITE, envia automàticament un RESPONSE; 100: Trying. Significa que està en el procés entre que rep la invitació i els tons de la trucada. Aquest missatge el rep del proxy SER on està registrat el UAC, test3, i el proxy l’envia al UAS, test2. A continuació, el UAC indica amb un RESPONSE; 180 Ringing indicant que el destinatari ja rep un to. Aquest també arriba al UAS. 40 Llavors passen un temps fins que el destinatari no accepta la trucada. Una cop acceptada la trucada el UAC del test3 envia un OK 200. I el UAS del test2 envia un ACK; Després d’aquest últim missatge s’estableix una comunicació òptica, és a dir, que els nodes entremitjos ja no intervenen en la comunicació. Tots aquest intercanvis de missatges correspon a una transacció, la transacció INVITE. 41 Annexa 2. Funcionament dels protocols MSML i MOML MSML i MOML permet que els servidors de media suportin funcions SIP. Podem trobar més informació del MSML a http://vesuvio.ipv6.cselt.it/internetdrafts/draft-melanchuk-sipping-msml-07.txt i el MOML a http://www.ietf.org/internet-drafts/draft-melanchuk-sipping-moml-06.txt 7.3 MSML MSML (Media Sessions Markup Language) s’encarrega del control i configuració de recursos media; crear una conferència, afegir nous participants... S’usa per invocar diferents classes de serveis en sessions individuals, sessions en grup i conferències. Una connexió de xarxa és establerta per el media server usant SIP. També permet fer i canviar serveis dinàmicament gràcies a un applications server durant el diàleg SIP. Protocol basat en objectes i enllaços. Un objecte és un element que genera, rep o manipula fluxos de media Un enllaç es un flux de media entre dos objectes Una petició MSML pot contenir una o vàries accions a realitzar per el servidor de media. Si la petició conté més de una acció, el missatge MAML se processa de forma seqüencial. Quan el servidor de media rep una petició ha d’assegurar-se que té recursos suficients per executar el missatge MSML, en cas contrari, no processa el missatge. És possible que durant l’execució del missatge es produeix quelcom error, en aquest cas l’execució es para i torna una resposta indicant el motiu del fallo i quina part del missatge s’ha executat correctament. Algun dels elements que defineix MSML són: <alias> Permet assignat un nom a una connexió. En aquest cas ajudarà al servidor de media a determinar quin protocol propietari ha d’usar per comunicar-se amb el processador de media. <dialogstart><dialogend> Obre i tanca un diàleg que permet fer operacions sencilles o en conjunt, com la reproducció d’un recurs de media. <join><unjoin> Crea i elimina un flux media entre dos objectes. És el element usat per afegir participants a un conferència. <createconference><destroyconference> Crea i elimina una conferència. Té atributs per especificar paràmetres de la conferència com són el número de participants. 7.4 MOML El protocol defineix objectes per el processat de fluxos de media com play i record, proporciona eines per agrupar aquests objectes. 48 7.7 Descripció 7.7.1 JAIN SIP JAIN és un conjunt de APIs (Application Programming Interface) que té com a funció principal agrupar i implementar interfícies necessàries pel desenvolupament de nous serveis a l’àmbit de les telecomunicacions. Es basa en el llenguatge de programació JAVA. Dins de la comunitat JAIN s’hi troba JAIN SIP que és la part encarregada de implementar les interfícies, per la utilització del protocol SIP. Alguna de les seves funcionalitats són; Mètodes pel format dels missatges Capacitat a l’aplicació per poder rebre i enviar missatges Capacitat per poder analitzar els missatges rebuts i accedir als seus camps Transport d’informació de control generada en una sessió (RFC 2976) Missatgeria instantànea (RFC 3428) 7.7.2 SipServlet És la tecnologia creada per treballar amb el protocol SIP (Session Initation Protocol). Per això crea un contenidor on es defineixen classes i mètodes que permeten processar els missatges SIP. Igual que els Servlets, sipServlet té un funcionament orientat a events, de manera que es pot definir el seu compartiment en funció del missatge SIP 49 rebut. A diferència dels Servlets, sipServlet pot rebre i generar tantes peticions com respostes. Aquesta diferència es a causa de que SIP és un protocol peer to peer mentre que HTTP està basat en l’arquitectura client/servidor 7.7.3 Tomcat Tomcat és una implementació de referència de J2EE que fa les funcions de servidor d’aplicacions. 50 Annexa 4. Configuració X-Lite 7.8 Servei VoIP SIP - VIDECAT 7.8.1 Usuaris de prova Els usuaris que poden utilitzar-se per provar el servei de VoIP SIP són els sigüents: Usuari Contrasenya test1 test1 test2 test2 test3 test3 7.8.2 Configuració X-Lite 1. Descarregar el client x-lite de www.xten.com 2. Configurar los paràmetres d’usuari en el menú System Settings / Sip Proxy / Default com s’il·lustra a la Figura 1 i Figura 2 : a. Modificar els valors de Display Name, Username, Authorization User amb el nom de l’usuari b. Configurar la contrasenya de l’usuari c. En los paràmetres SIP Proxy y Out Bound Proxy introduir la direcció sipedu.i2cat.net d. Verificar que el paràmetr Register estigui en Always e. Finalment Dial Prefix ha d’estar en blanc 51 Figura 1 Paràmetres d’usuari Figura 2 Paràmetres d’usuari 3. Configurar els paràmetres de xarxa al menú System Settings / Network a. Verificar que el valor de Auto Detect IP sigui No b. Introduir a Listen on IP la direcció IP de ‘equipo en el qual s’ha instal·lat X-lite 52 Figura 3 Paràmetres de Xarxa