Videoneuvottelusiltojen ketjutus Raportti

Transkriptio

1 Videoneuvottelusiltojen ketjutus Raportti Jani Tiihonen Jussi Talaskivi Timo Hatakka Timo Ervasti CSC Jyväskylän yliopisto LTKK Oulun yliopisto

2 2 Sisällys Johdanto... 2 Videoneuvottelusiltojen (MCU) asetukset ja Gatekeeperin käynnistäminen... 2 CSC - CUseeMe Conference Server 5.01 (CUCS)... 2 Jyväskylän yliopisto - RadVision MCU LTKK - RadVision MCU Oulun yliopisto - Accord MGC Siltojen ketjuttaminen... 4 Radvisionin ketjuttaminen CUCS:iin... 4 Radvisionin ketjuttaminen Radvisioniin... 5 Accordin ketjuttaminen CUCS:iin... 5 Client yhteydet MCU laitteisiin... 5 I yhteyskokeilu II yhteyskokeilu III yhteyskokeilu Yhteenveto... 8 Linkit... 9 Johdanto Tämän raportin tarkoitus on informoida suoritetuista CSC:n, Jyväskylän yliopiston, LTKK:n ja Oulun yliopiston välisistä videoneuvottelusiltojen ketjutuskokeiluista. Ketjutus tarkoittaa usean eri videoneuvottelusillan/palvelimen (MCU - Multipoint Control Unit) yhdistämistä toisiinsa niin, että jokaiseen MCU:hin kytkeytyneet H.323 clientit (päätelaitteet) näkevät toisensa samassa kokouksessa ja voivat kommunikoida ristiin video ja äänineuvottelun avulla. Kun yksittäisen yliopiston videoneuvottelulaitteiden määrä kasvaa ja kaikki haluavat ottaa yhteyttä samaan kokoukseen, on järkevää että yhteys muodostetaan oman sillan avulla. Laitteet kootaan yhteen kokoukseen omaan siltaan, joka sitten liitetään yksittäisenä pisteenä etäkokoukseen. Tämä säästää verkkokapasiteettia ennenkaikkea ulkomaan yhteyksissä. Raportin yksityiskohdissa ei ole tarkoitus mennä jokaisen clientin asetusten konfikuroimiseen vaan keskittyä lähinnä MCU -siltojen asetusten määrittämiseen ja muokkaamiseen ketjutuksen onnistumiseksi. Raportin alkuosa antaa tarvittavat tekniset taustatiedot yhteyksien muodostamiseen. Yhteyskokeilu-luvuissa kerrotaan ketjutustesteistä yleisellä tasolla ja niistä on tarkoituksella jätetty pois teknisten yksityiskohtien selvittäminen. Videoneuvottelusiltojen (MCU) asetukset ja Gatekeeperin käynnistäminen CSC - CUseeMe Conference Server 5.01 (CUCS) Conference ID:

3 3 Zone Prefix: Ei tuettu Teoreettinen maximi käyttäjämäärä on 25 (käytännössä n.15) Bandwidth: 768 Frames per second: 30 Continuous Presence: No Audio codec: G.711U Video codec: H.261 Resolution: CIF Asetukset ovat kokouskohtaisia ja koskevat tässä kokousta TF Stream CUCS ei tue Zone Prefis määrittelyä, joten ketjuttaminen tulee tehdä kokouskohtaisesti. CUCS:in Gatekeeper käynnistetään ketjuttamista varten administrator-tunnuksilla logattaessa kohdasta Network -> Members. Tämän jälkeen valitaan ketjutettava serveri ja klikataan Edit. Sivun alalaidasta valitaan Use CUseeMe Conference Server's Gatekeeper. Lisäksi samalta sivulta pitää määritellä E.164 Address Prefix, mikä on tässä tapauksessa 5409 ja Endpoint Identifier Suffix: WPINE. Address Prefix numero 5409 määrittelee Conference ID:n alkuosan. Loppuosa tulee CUCS:iin luodun kokouksen numerosta, mikä on tässä tapauksessa Conference ID:n loppuosan tulee kuitenkin olla viisi numeroinen, joten siksi 8001 eteen tulee lisätä nolla. Tästä saadaan ketjutettavan kokouksen Conference ID Jyväskylän yliopisto - RadVision MCU-323 Conference ID: Zone Prefix: Tuettu Teoreettiset käyttäjämäärät: 9 käyttäjää 384 kbit/s nopeudella 5 käyttäjää 768 kbit/s nopeudella 3 käyttäjää 1.5 Mbit/s nopeudella Bandwidth: 768 Frames per second: 30 Continuous Presence: No Audio codec: G.711U Video codec: H.261 Resolution: CIF Koska RadVision ei suostu toimimaan kunnolla muussa kuin täydellisessä H.323 ympäristössä, käytetään laitteen kanssa aina Gatekeeper toimintoa. Tämä voidaan hoitaa joko laitteen sisäänrakennetulla GateKeeperillä tai sitten ulkoisella laitteella. Laitteen asennuksen yhteydessä valitaan toimintamalli RadVisionin OnLan Configure ohjelmalla. Asennuksen yhteydessä määritellään käytettävät kokoustyypit ja nopeudet. Tämän lisäksi määritellään miten laitteeseen voi rekisteröityä. Laitteen voi määritellä joko avoimeksi tai sitten voi vaatia että käytettyjen laitteiden IP-numerot kirjataan edeltäkäsin siltaan. Jokainen kokoustyyppi saa oman prefiksinsä jonka liittäminen kokouksen numeron alkuun valitsee kokouksen tyypin. Esim. prefiksillä 65 löytyy Continuous Presence

4 4 tyyppinen 384Kbs kokous. Tällöin kokouksen numero olisi (eli XXYYYY jossa XX on tyyppi ja YYYY uniikki tunnistin). Numeron kokonaispituutta ei ole erikseen rajoitettu. LTKK - RadVision MCU-323 Conference ID: Zone Prefix: Tuettu Teoreettiset käyttäjämäärät: 9 käyttäjää 384 kbit/s nopeudella 5 käyttäjää 768 kbit/s nopeudella 3 käyttäjää 1.5 Mbit/s nopeudella Bandwidth: 768 Frames per second: 30 Continuous Presence: No Audio codec: G.711U Video codec: H.261 Resolution: CIF Gatekeererin käynnistäminen: ks. Jyväskylän yliopisto - RadVision MCU-323 Oulun yliopisto - Accord MGC-100 Conference ID: ei käytössä Zone Prefix: Tuettu Käyttäjämäärä: 24 Bandwidth: 768 Frames per second: 30 Continuous Presence: No Audio codec: G.711U Video codec: H.261 Resolution: CIF Siltojen ketjuttaminen Radvisionin ketjuttaminen CUCS:iin Koska CUCS ei tue Zone Prefix määrittelyä täytyy RadVisionin MCU:ssa CUCS:ia varten tehdä yksi endpoint joka määritelään 'allways on'-tyyppiseksi. Asetus tehdään Radvisionin GateKeeperin Zone Definition tauluun. IP numeroksi laitetaan CUCS:in IP ja numeroksi CUCS:in Conferencce ID Tämän jälkeen CUCS:in yksittäinen kokous kutsutaan RadVisioniin. Invite eli kokoukseen kutsumisen voi tehdä RadVisionissa kahdella eri tavalla. Voidaan joko käyttää laitteen WWW-käyttöliittymää, joka ilmestyy silloin kun kokous on avattu ja otetaan selaimella yhteys sillan IP-numeroon (sisäänkirjautumiseen käytettään kokouksen numeroa esim ). WWW-liittymässä on painike Invite, joka avaa kentän johon

5 5 syötetään kutsuttavan tahon E.164 numero (tämä pitää siis tietää). E.164 numeron pitää olla jotenkin sillan tunnistettavissa. Nämä numerot voidaan määritellä sillalle kahdella eri tavalla. Terminaali laitteet kertovat GateKeeper rekisteröinnin yhteydessä sillalle oman E.164 numeronsa. Numeroita voi määritellä myös itse sillan hallintaohjelmalla. Tätä tapaa käytettiin CSC:n CUCS:n kanssa. Invite voidaan tehdä myös suoraan numeronvalinnan yhteydessä. Tällöin lisätään kokouksen numeron perään kutsuttavan tahon E.164 numero kahdella tähdellä eroteltuna (esim **449900). Käytännössä asetuksen tekeminen tarkoitti sitä että CUCS:in yksittäinen kokous liitettiin RadVisionin GateKeeper zonessa olevaksi päätteeksi (terminal). Tällainen asetus toimii siis vain tähän yhteen kokoukseen eikä mahdollista yhteyden ottamista muihin CUCS:in kokouksiin. Radvisionin ketjuttaminen Radvisioniin Jyväskylän ja Lappeenrannan RadVisionit on yhdistetty siten että niille on ristiin määritelty toinen laite naapuri Gatekeeperiksi (Neighbor Gatekeeper table). Siellä Radvisionille kerrotaan toisen laitteen IP ja laitteelle annetaan prefiksi, jolla laite tunnistetaan E.164 koodeista. Esimerkiksi Lappeenrannan Radvisionille on kerrottu että Jyväskylän laitteen prefiksi on 11, jolloin jos numeroa edeltää 11, kutsu laitetaan Jyväskylään. Lisäksi laitteessa on määriteltävä samainen prefiksi "Zone prefix":ksi palvelujen listaan. Eli esimerkiksi Jyväskylän laiteeseen on määritelty että oma Zone prefix on 11, muuten laite ei tunnista sitä omakseen ja kai hylkäisi Lappenrannasta tulevan 11 -alkuisen numeron. Tämän määrityksen jälkeen tarkoittaa Lappeenrannan sillan istuntoa ja Jyväskylän sillan istuntoa. Accordin ketjuttaminen CUCS:iin Oulun yliopiston Accord sillan ketjuttaminen CSC:n CUCS:iin hoidettiin kutsumenettelyn kautta. CUCS:in Callout -appletilla ( Appletista valitiin testikokous 8001 TF Stream ja soitettiin Accordin IP osoitteeseen. Ketjutettu linkki Accordin ja CUCS:in välille yhteys saatiin muodostettua. Accordiin määriteltiin yksi ip-portti sisäänsoittoa varten dial-in:iksi. Portin parametrit ovat name, interface type (ISDN/H.323/ATM/MPI), connection type (dial-in/out), participant IP sekä valinnaisesti alias name, alias type (H323Id, E164, URLId, Id, TransportId, Party number), video bit rate (ellei auto), video protocol (auto, H.261, H.263). Client yhteydet MCU laitteisiin Client yhteys ketjutettuun kokoukseen muodostetaan soittamalla manuaalisesti oman MCU:n Conference ID numeroon. Lisäksi clientin asetuksiin pitää määritellä MCU:n Gatekeeper Address, mikä on kyseisen MCU:n IP-numero. Esimerkiksi CUCS:in ketjutettuun kokoukseen soittaminen tapahtuu määrittelemällä H.323 clientin Gatekeeper Addressiksi CUCS:n IP-osoite ja soittamalla manuaalisesti ketjutettuun Conference ID numeroon

6 6 I yhteyskokeilu Yhteyskokeilu kokoonpanolla: CSC - CUseeMe Conference Server 5.01 Jyväskylä - RadVision MCU-323 Aluksi CSC:n ja RadVisionin silloista käynnistettiin Gatekeeperit. Tämän jälkeen Radvivionilla otettiin yhteys CUCS:in Conference ID:hen Jyväskylän sillasta. Tämän jälkeen molempiin siltoihin otettiin client-yhteydet ja neuvottelu saatiin toimimaan välittömästi. Seuraavaksi yhteys yritettiin muodostaa Continuous Presence toiminto päällä. Asetukset olivat muuten samat. Ääni tuli läpi, mutta videokuva jäi näkymättä. Tämän jälkeen molempien siltojen asetukset yhdenmukaistettiin balansoimalla yhteysnopeus ja laittamalla Frame Ratet samoiksi. Continuous Presenceä ei saatu toimimaan. Zone-soittokäytäntöön perustuvaa järjestelmää ei voitu käyttää CUCS:in kanssa, koska tämä ei tue Zone-prefiksejä. Zonejen avulla voitaisiin rakentaa dynaaminen soittojärjestelmä jolloin yksittäisiä kokouksia ei tarvitse määritellä erikseen Gatekeepereihin. II yhteyskokeilu Yhteyskokeilu kokoonpanolla: CSC - CUseeMe Conference Server 5.01 Jyväskylä - RadVision MCU-323 Lappeenranta - RadVision MCU-323 Ketjutuksen keskipisteeksi valittiin Jyväskylän RadVision. Tämä ei ollut verkkoliikenteen kannalta optimaalisin vaihtoehto mutta jouduimme tähän tyytymään, koska Lappeenrannan sillalla oli välittömästi muuta käyttöä eikä sen konfigurointiin voitu ryhtyä. (Kuva 1) Jyväskylä Kuva 1 CSC Lappenranta Jyväskylän RadVisioniin on tehty jo aikaisemmin asetus Lappeenrannan MCU:n osoitteesta (Zone määrityksien mukaisesti). Molempiin laitteisiin on myös konfiguroitu yhteinen kokous, jossa on identtiset asetukset.

7 7 Kokouksen muodostaminen aloitettiin sillä että jokainen otti yhteyttä omaan MCUlaitteeseen. CSC:ssä avattiin kokous , Lappeenrannassa ja Jyväskylässä Tämän jälkeen avattiin Jyväskylän RadVisionin www-liittymä ja kutsutiin Jyväskylän siltaan mukaan CSC:n kokous. CUCS ilmestyi RadVisionin hallintaliittymään. Tämän jälkeen otettiin mukaan Lappeenrannan kokous. Yhteydet muodostuivat hetkessä ja kokous oli kasassa. Lappeenranta tunnettiin tässä testissä Jyväskylässä Zone prefiksillä 10. Urheilullisuutta haluavat voivat naputella Jyväskylässä kokouksen pystyyn yhdellä numerolla: ** ** Tämä siis avaa cascade-kokouksen, jossa keskipisteenä on Jyväskylän MCU. Teoriassa tämän saa pystyyn myös Lappeenrannasta numerolla: ** ** (Tämä tosin jäi varmistamatta ja riippuu siitä antaako RadVision mudostaa ulkoa tulevia yhteyksiä edelleen ulkopuolelle.) III yhteyskokeilu Yhteyskokeilu kokoonpanolla: CSC - CUseeMe Conference Server 5.01 Jyväskylä - RadVision MCU-323 Lappeenranta - RadVision MCU-323 Oulun yliopisto - Accord MGC-100 Kokouksen muodostaminen aloitettiin samoin kuin edellisissä kokeilussa eli jokainen otti yhteyttä omaan MCU-laitteeseen. Lappeenrannassa , Jyväskylässä ja CSC:ssä Tämän jälkeen avattiin Jyväskylän RadVision kutsui siltaan mukaan CSC:n kokouksen. Tämän jälkeen otettiin mukaan Lappeenrannan kokous. Seuraavaksi CSC:n siltaan kutsuttiin mukaan Oulu IP-osoitteella CUCS:in Callout -appletin kautta. Kokouksen muodostaminen onnistui hyvin, mutta kokouksen verkkoliikenneratkaisun odettiin olevan huono. Lappeenrannan kuva kiersi CSC:hen ja Ouluun Jyväskylän kautta (Kuva 2). Oulu Jyväskylä CSC Lappenranta Kuva 2 Seuraavaksi päätettiin kokeilla verkkoliikenteen kannalta parempaa ratkaisua, jossa CSC:n CUCS olisi keskipisteenä. Jyväskylä ja Lappeenranta kutsui CSC:n kokouksen omiin siltoihinsa ja Oulu saatiin mukaan käyttämällä CUCS:in Callout - applettia. Näin saatiin parempi ratkaisu verkkokuormituksen kannalta (Kuva 3).

8 8 Oulu Jyväskylä Kuva 3 CSC Lappenranta Yhteenveto Ketjuttaminen sujui kaikissa yhden kuvan kokouksessa ongelmitta ja yhteys saatiin muodostettua nopeasti. Testijärjestelyissä oli ainoastaan yksi asiakasohjelma (client) yhtä siltaa kohti, joten aivan realistista megakonfrenssimaista testitilannetta emme pystyneet järjestämään. Ketjutus onnistuu myös useamman H.323 clientin kanssa. Ketjuttamisessa tulee ottaa huomioon MCU:den verkkotopologia. Vähiten liikennettä aiheutetaan verkon ollessa tähtimäinen. Ketjutettu videoneuvottelu toimii parhaiten tähtimallisessa verkkotopologiassa (Kuva 3). Yksittäisen terminaalin etäisyys toisesta terminaalista tai MCU-laitteesta on mahdollisimman lyhyt. Vaikka verkkokapasiteetti riittäisi toisenlaisiin yhdistelmiin niin suuremman ongelman aiheuttaa viiveet, joita tulee jokaisessa solmukohdassa lisää. Videoneuvottelu on erittäin aikakriittistä liikennettä, jossa puolisekuntia myöhässä oleva paketti on käytännössä hyödytön. CSC:n CUCS:in sijainti on ihanteellinen liikennekuorman minimoimiseksi, sillä se sijaitsee parhaassa mahdollisessa solmukohdassa. Kuvan laatu pysyi testien ajan kohtalaisena. CUCS:in kanssa oli ongelmia kuvan laadun heikkenemisessä. Varsinkin testijärjestelyissä, jossa CUCS oli ketjutuksen keskipisteenä, kuvan laadussa ilmeni haamukuvia hitaan kuvapäivityksen takia. Huonoa kuvan laatua voisi parantaa ketjuttamalla sillat siten, että Jyväskylän Radvision olisi siltojen keskipisteenä. CUCS:in sillan tekniset rajat tulivat vastaan sillä ketjuttaminen onnistuu CUCS:illa ainoastaan kokouskohtaisesti. CUCS ei tue Zone Prefix numeromäärittelyjä minkä etuna olisi eri kokousten ketjuttaminen toisiinsa dynaamisesti jolloin yksittäisiä kokouksia ei tarvitsisi määritellä erikseen. Jyväskylän ja Lappeenranna Radvisionien välillä käytettiin Zone -määrittelyjä. III ketjutuskokeilussa yritettiin saada Oulun Accordissa määritellyn yhden kokouksen liittämistä Jyväskylän RadVisioniin samalla tavalla kuin CSC:n CUCS:n kanssa. Ongelmaksi tuli se että Accordista ei sillä hetkellä löydetty ConferenceID:tä, jonka olisin voinut syöttää RadVisionille. Accordista yrtitettiin myös löytää Zone prefix toimintoa mutta se liittyy laitteen GateKeeper-toimintoihin joihin ei oltu tässä vaiheessa vielä tutustuttu. Tätä testataan toivottavasti myöhemmin lisää.

9 9 Kun laitteiden välillä tehdään ketjutusta ja käytössä on Continuous Presence tila niin mukaan tulee lisää asetuksia ja toimintoja joiden keskinäinen toimivuus voi olla epävarmaa. Tärkeimpänä näistä lienee Slave ja Master määritys, joka pitää laitteisiin asettaa. Yksi laitteista toimii Masterina ja toinen on Slave. Toinen asetus on kuvakoon määrittely. Continuous Presencissä yksittäisen terminaalin kuvakoko on useimmiten QCIF ja koostetun kuvan koko on CIF. Näiden asetusten neuvottelu pitäisi tapahtua H.323 yhteyden alkuvaiheessa (H.245 protokolla) automattisesti mutta eri valmistajien laitteiden välillä on eroja. Tätä pitää testata lisää. Hyvänä käytännön sovellutuksena katjutuskokeiluille voisi olla viimeistään toukokuussa järjestettävä kansallinen Megakonfrenssi. Tilaisuuteen ottaa osaa kymmeniä eri clientteja, joten yhden sillan kapasiteetti ei riitä kaikkien tarpeiden tyydyttämiseen. III yhteyskokeilun yhdistelmässä, jossa oli neljä siltaa ketjutettuna voisi taata kaikille osallistujille pääsyn konferenssiin. Linkit CUseeMe Conference Server RadVision MCU Accord MGC Jani Tiihonen CSC - Tieteellinen Laskenta Oy Puh: GSM: jani.tiihonen@csc.fi Jussi Talaskivi Jyväskylän yliopisto Puh: GSM: jussi.talaskivi@jyu.fi Timo Hatakka LTKK GSM: Puh: timo.hatakka@lut.fi Timo Ervasti Oulun yliopisto Puh: GSM: timo.ervasti@oulu.fi