Teknillinen Korkeakoulu Teletekniikan laboratorio S-38.128 Teletekniikan erikoistyö VoIP-tekniikat ja toteutustapoja PK-yrityskäytössä Tekijä: Ohjaaja: Valvoja: Mika Ylipieti 45703K mylipiet@cc.hut.fi Vesa Kosonen Jätetty: 31.10.2000
- i - TIIVISTELMÄ Tässä työssä käydään läpi IP:n (Internet Protocol) avulla tapahtuvaan puheensiirtoon (Voice over IP, VoIP) liittyviä tekniikoita. Näitä ovat muun muassa UDP kuljetuskerroksella, reaaliaikaista tietoa siirtävä RTP, sekä palvelunlaadun ja yhteysparametrien neuvotteluun tarvittavat protokollat. Kaikkien protokollien esittelyt on tehty VoIP-näkökulmasta, selittäen niiden toimintaa puheensiirtoon liittyen. Tekniikoiden jälkeen esitetään esimerkein erilaisia verkkotopologioita. Lopuksi käydään vielä läpi eri toteutusvaihtoehtoja yrityskäyttöön liittyen ja esitellään lyhyesti markkinoilla olevia tuotteita. Työn tarkoituksena on ollut tutustua IP-verkossa tapahtuvaan puheensiirtoon liittyviä tekniikoita ja oppia tuntemaan niiden toimintaa. Tämän takia lähestymistapa on hieman oppikirjamainen, eli selittävä ja perusteleva. Tarkoituksena on, että tässä työssä läpikäytyjen tekniikoiden avulla lukija, sekä työn kirjoittaja, pystyy arvioimaan myynnissä olevia VoIP-tuotteita ja ymmärtää mainosteksteissä taajaan vilahtelevien termien merkityksen.
- ii - SISÄLLYSLUETTELO SISÄLLYSLUETTELO......II LYHENTEET...... III 1. JOHDANTO......1 2. KESKEISET TEKNIIKAT......3 2.1 KERROSRAKENTEESTA L2 IP UDP/TCP RTP...3 2.2 UDP JA TCP...5 2.2.1 User Datagram Protocol (UDP)...5 2.2.2 Transmission Control Protocol (TCP)...6 2.3 RTP - REAALIAIKAISEN TIEDON SIIRTÄMINEN...8 2.3.1 Real-time Transport Protocol (RTP)...9 2.3.2 RTP Control Protocol (RTCP)...12 2.3.3 Audio- ja videokonferenssi profiili...14 2.4 H.323...15 2.4.1 H.323-verkon rakenne ja toiminta...16 2.5 SESSION INITATION PROTOCOL...21 2.5.1 SIP viestien rakenne...22 2.5.2 Invite - Yhteyden pyytäminen...23 2.5.3 Käyttäjän paikallistaminen...24 2.5.4 SIP Universal Resource Locator...24 2.6 LAADUN TAKAAMINEN...25 2.6.1 Resource Reservation Protocol (RSVP)...25 2.6.2 Differentiated Services (DiffServ)...26 3. ERI TAPOJA VOIP-PALVELUJEN TOTEUTTAMISELLE...29 3.1 VOIP-VERKON TOPOLOGIAT, VERKON ELEMENTIT, ESIMERKKEJÄ...29 3.2 VOIP-VERKON HALLINTA...31 4. VOIP-PALVELUN ETUJA/HAITTOJA YRITYKSELLE...33 5. KATSAUS MARKKINOILLA OLEVIIN TUOTTEISIIN...34 5.1 MYYNNISSÄ OLEVIA LAITTEITA...34 5.2 YHDYSKÄYTÄVÄPALVELUJA...34 6. YHTEENVETO...36 7. LÄHTEET...37
- iii - LYHENTEET ACF ACK ADSL ARQ Acknowledgement confirmation kuittauksen vahvistus Acknowledgement kuittaus Asymmetric Digital Subscriber Line epäsymmetrinen digitaalinen tilaajalinja Acknowledgement Request - kuittauspyyntö ASN.1 Abstract Syntax Notation Number One käsitteellinen merkintäsyntaksi numero yksi, ITU-T:n standardi tietorakenteiden kuvaamiseen ATM BRI CCITT CS DNS DS DSL FM FTP GK GSM GW HTML Asynchronous Transfer Mode asynkroninen toimintamuoto Basic Rate Interface perusliitäntä (ISDN) Consultative Committee for International Telegraph and Telephone ITU:n telestandardisointisektori, nykyiseltä nimeltään ITU-T Circuit Switched - piirikytkentäinen Domain Name System nimipalvelinjärjestelmä Differentiated Services eriytetyt palvelut Digital Subscriber Line - digitaalinen tilaajalinja Frequency Modulation - taajuusmodulointi File Transfer Protocol - tiedonsiirtoprotokolla Gatekeeper - portinvartija Global System for Mobile Telecommunications ETSI:n globaali matkapuhelinjärjestelmä Gateway - yhdyskäytävä Hypertext Markup Language hypertekstin merkintäkieli
- iv - HTTP IANA IBM ICMP ID IEEE IETF IN IP Hypertext Transfer Protocol hypertekstin siirtoprotokolla Internet Assigned Number Authority internetin numeroiden määritelyviranomainen International Business Machines kansainväliset toimistokoneet, yleensä vain muodossa IBM Internet Control Message Protocol internetin hallintaprotokolla Identity - identiteetti Institute of Electrical and Electronics Engineers kansainvälinen sähkö- ja elektroniikkainsinöörien järjestö Internet Engineering Task Force internetin tekninen työryhmä Intelligent Networks - älyverkot Internet Protocol - internetprotokolla IPv4 Internet Protocol version 4 internetprotokolla versio 4 IPv6 Internet Protocol version 6 internetprotokolla versio 6 ISDN Integrated Services Digital Network digitaalinen monipalveluverkko ISO International Organization for Standardization Kansainvälinen Standardoimisjärjestö ITU International Telecommunications Union - Kansainvälinen Televiestintäliitto ITU-T ITU Telecommunication Standadization Sector ITU:n telestandardisointisektori JPEG Joint Photographic Experts Group ISO:n ja ITU-T:n yhteinen kuvien koodaamiseen erikoistunut työryhmä LDAP Lightweight Directory Access Protocol kevytrakenteinen hakemiston käsittelyprotokolla
- v - MBONE MC MCU MP MPLS NASA NT Multicast Backbone monipistelähetysrunkoverkko Multipoint Controller - monipistesteohjain Multipoint Control Unit - monipisteohjainyksikkö Multipoint Processor - monipistekäsittelijä Multiprotocol Label Switching - leimakytkentä National Aeronautics and Space Administration kansallinen ilmailu- ja avaruusalan järjestö New Technology uusi teknologia OSI Open Systems Interconnection avointen järjestelmien yhteenliittäminen PBX PC PPP PRI PSTN PT RAS RFC ROM RR RSVP RTCP RTP Private Branch Exchange - tilaajavaihde Personal Computer henkilökohtainen tietokone Point to Point Protocol - kaksipisteyhteysprotokolla Primary Rate Interface järjestelmäliitäntä (ISDN) Public Switched Telephone Network yleinen puhelinverkko Packet Type paketin tyyppi Registration, Admission and Status rekisteröinti, hallinta ja tilatieto Request for Comments - kommentointipyyntö Read Only Memory - lukumuisti Receiver Report vastaanottajan raportti Resource Reservation Protocol resurssien varausprotokolla RTP Control Protocol RTP:n hallintaprotokolla Real-time Transport Protocol reaaliaikainen tiedonsiirtoprotokolla
- vi - SDES SDH SDP SIP SMTP Source Description lähdekuvaus Synchronous Digital Hierarchy synkroninen digitaalinen hierarkia Session Description Protocol yhteyden kuvausprotokolla Session Initiation Protocol yhteydenmuodostusprotokolla Simple Mail Transfer Protocol yksinkertainen postinsiirtoprotokolla SNMP Simple Network Management Protocol yksinkertainen verkonhallintaprotokolla SR SSRC TCP Sender Report lähettäjän raportti Synchronization Source - sykronointilähde Transmission Control Protocol - tiedonsiirtoprotokolla TFTP Trivial File Transport Protocol hyvin yksinkertainen tiedonsiirtoprotokolla TTL UDP USB VoFR VoIP Time to Live elinaika User Datagram Protocol käyttäjän datasähkeprotokolla Universal Serial Bus yleinen sarjaväylä Voice over Frame Relay puheen siirto kehysvälityksen avulla Voice over IP puheen siirto internetprotokollan avulla WWW World Wide Web maailmanlaajuinen tietoverkko
- 1-1. JOHDANTO Voice over Internet Protocol (VoIP) on usean vuoden ajan ollut yksi teletekniikan eniten puhutuista osa-alueista. VoIP lupaa meille pienempiä kustannuksia, lähes loputtoman määrän uusia palveluita yhdistyneen data- ja puheliikenteen ansiosta, sekä paljon muuta hyvää puhujasta riippuen. Myös useat laitevalmistajat tarjoavat jo tänä päivänä erilaisia VoIP-tuotteita, lähtien itsenäisistä modeemin tai verkkokortin sisältävistä päätelaitteista aina verkkojen välisiä tietomuunnoksia tekeviin yhdyskäytäviin (gateway). VoIP-puhelu on mahdollinen kahden käyttäjän välillä, riippumatta näiden fyysisestä sijainnista. Ainoana vaatimuksena on liitäntä yhteiseen IP-verkkoon, siis esimerkiksi Internetiin, ja samoja ylemmän tason protokollia käyttävät ohjelmat kummassakin päätelaitteessa. Kahden tavallisen modeemilla Internet -palveluntarjoajaan yhteyden ottavan henkilön välinen VoIP-puhelu ei vielä yllä läheskään samalle laadulliselle tasolle yleisen kytkennällisen puhelinverkon kanssa. Tämä johtuu lähinnä modeemin hitaasta liityntänopeudesta (tyypillinen nopeus on vain 33 kbit/s), mikä aiheuttaa ison lisäviiveen puheensiirtoon (tyypillinen arvo 150 ms), joka yhdessä PCkoneen ohjelmiston (+150 ms) ja yhdyskäytävän (+150 ms) viiveiden kanssa muodostaa jo 450 millisekunnin yhdensuuntaisen viiveen IP-verkon aiheuttaman viiveen lisäksi. Tällöin modeemilla VoIP-puheluyhteydessä olevat henkilöt tuntevat "puhuvansa kuuhun". Kolme tärkeintä viiveen aiheuttajaa tällaisessa modeemiyhteydessä ovat puskurointi, varsinaiseen lähetykseen kulunut aika ja yleisesti IP-puheen huono hyötysuhde [1]. Tosin otsikoiden osuutta tietovirrasta voidaan vähentää käyttämällä otsikoiden pakkausta [2], mutta nämä tekniikat eivät ole vielä yleisessä käytössä. Valtaosa Internet-käyttäjistä ottaa yhteyden verkkoon modeemia käyttäen, niinpä VoIP-tekniikka ei vielä ole erityisen kilpailukykyinen liityntätekniikkana näiden asiakkaiden suhteen. Nopeat kaapelimodeemi- ja DSL-yhteydet toisivat VoIP-tekniikan myös nykyisen PSTN-palvelun tilaavien asiakkaiden käyttöön,
- 2 - mutta esimerkiksi Forrester Research Inc:n arvion mukaan vielä vuonna 2000 yleisin kuluttajatason Internet-liityntä perustuu modeemitekniikkaan 87,9 prosentin osuudella. Niinpä tässä työssä tutkitaan VoIP-puheluita lähinnä nopeita laajakaistaverkkoja tiedonsiirrossa käyttäen. VoIP-tekniikka on kuitenkin tulossa runkoverkkoihin, esimerkiksi uuden sukupolven matkapuhelinrunkoverkoissa tieto siirtynee IP-muodossa, jotkin teleoperaattorit käyttävät jo nykyään ulkomaanpuheluiden tehokkaampaan välitykseen IP:tä ja pk-yrityksissä välitetään puheluita dataverkon kautta. Lisäksi IP-verkon joustavuuden ansiosta esimerkiksi yritysten työntekijöiden työpisteiden vaihdot onnistuvat lennosta tarvitsematta puhelinnumeroiden uudelleen kytkemisiä, hakien tarvittavat verkkoasetukset automaattisesti ja ilmoittaen lopulta sijaintinsa henkilön kotipalvelimelle. VoIP-tekniikkaa on standardoinut Internet Engineering Task Force (IETF), International Telecommunications Union (ITU-T) ja lukuisat pienemmät yhteenliittymät, sekä yksittäiset laitevalmistajat. Näistä tärkeimmät standardit pyritään käymään läpi kappaleessa kaksi, joissa kerrotaan keskeisistä tekniikoista. Kappaleessa kolme puolestaan esitetään VoIP-verkon rakentamiseen liittyviä asioita, eli käydään läpi kappaleessa kaksi esitettyjen tekniikoiden avuilla toteutettavissa olevia verkkoja. Etuja ja haittoja VoIP-verkon toteuttamisesta pk-yrityksen kannalta tutkitaan kappaleessa neljä. Kappaleessa viisi luodaan katsaus myynnissä oleviin valmiisiin tuotteisiin ja palveluihin.
- 3-2. KESKEISET TEKNIIKAT Voice over IP -puhelinsovellus vaatii teknisesti paljon alla olevalta verkolta. Äänipuhelulle tärkeää on saavuttaa mahdollisimman pieni viive (luokkaa kymmeniä millisekunteja), sekä korkea luotettavuus pakettien perillemenosta. Äänitieto siirretäänkin yleensä pieniviiveisellä UDP (User Datagram Protocol)- protokollalla, jonka virheenhavaitsemismekanismeja ei yleensä käytetä, eikä paketteja numeroida. UDP-protokollaa käsitellään kohdassa 3.2.1. Myöskin puuttumaan jäänyt paketti, eli verkossa hävinnyt pala äänitietoa, joudutaan jotenkin korvaamaan (joko hiljaisuudella tai sitten muista paloista ekstrapoloimalla/interpoloimalla). Hukkuneiden pakettien havaitseminen VoIPyhteydellä kuitenkin onnistuu, samoin kuin paketin järjestykseen laittaminen, sillä lisäksi käytetään RTP (Real Time Protocol) -protokollaa, joka huolehtii näistä asioista. RTP-protokollaa käsitellään kohdassa 2.2. 2.1 KERROSRAKENTEESTA L2 IP UDP/TCP RTP Internet Protocol (IP) on hyvin joustava alla olevan tekniikan suhteen. Itse asiassa IP-protokollan määrittelyssä ei edes mainita mitä palveluja alla olevan siirtoyhteyskerroksen protokollan pitää pystyä tarjoamaan IP:lle [3] ja IP:n joukkolähetystä (broadcast) käsittelevä standardikin olettaa alla olevalta verkolta vain tehokasta joukkolähetystä, toisin sanoen, verkon koneiden pitää saada vastaanotettua suurimman osan joukkolähetyspaketeista [4]. Tämän takia IP-pohjaisia verkkoja voidaan rakentaa lähes minkä tahansa verkkotekniikan päälle, yleisimpänä Ethernet liittymäverkoissa (access networks, tilaajaverkko) ja ATM runkoverkoissa. Nykyään IP-liikennettä kuljetaan myös mm. SDH, Sonet ja gigabit Ethernet verkoissa. Kerrosrakenteen avulla ymmärretään miten eri tekniikat ja protokollat suhtautuvat toisiinsa. Kuvassa 1 on esitetty IP-kerrosmalli sellaisena kuin se on alkuperäisessä IP:n määrittelevässä standardissa, sekä rinnalle on lisätty parhaiten vastaavat ISO:n (International Organization for Standadization) OSI (Open Systems Interconnect)-mallin mukaiset kerrokset.
- 4 - +------+ +-----+ +-----+ +-----+ OSI-kerrokset 5-7: Telnet FTP TFTP...... Sovellus-, esitystapa- ja +------+ +-----+ +-----+ +-----+ istuntokerrokset +-----+ +-----+ +-----+ TCP UDP...... OSI-kerros 4: +-----+ +-----+ +-----+ Kuljetuskerros +--------------------------+----+ Internet Protocol & ICMP OSI-kerros 3: +--------------------------+----+ Verkkokerros +---------------------------+ Local Network Protocol OSI-kerrokset 1 ja 2: +---------------------------+ Linkkiyhteys- ja fyysinenkerros Kuva 1. IP-kerrosmalli alkuperäisen standardin mukaisesti ja vastaavat OSI-kerrokset [3]. Kuvasta nähdään, että IP-protokolla toimii linkkikerroksen yläpuolella. Linkkikerros tarjoaa IP:lle tiedonsiirtopalvelun samassa fyysisessä verkossa oleviin koneisiin ja se voi olla toteutettu esimerkiksi Ethernet-tekniikalla. IP puolestaan tarjoaa tiedonsiirtopalvelun toisissa fyysisissä verkoissa oleviin koneisiin ja mahdollistaa isojen datalohkojen paloittelun pienempiin, alemmalle kerrokselle sopiviin palasiin - sekä vastaavasti näiden palojen kokoamisen toisessa päässä. IP-paketista on esitetty esimerkki 2. Tavu: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Versio Ots.pit Palv. tyyppi Paketin koko pituus (ots+data) Lohkon tunniste Liput Datan paikka lohkossa Max.elinaika Datan protok. Otsikon tarkastussumma Lähdeosoite Kohdeosoite Optiot Täyte / IP-data, esim TCP-paketin otsikko + sitä seuraava / / varsinainen hyötykuorma. Max noin 64 kilotavua. / +---------------------------------------------------------------+ Kuva 2. IP-paketti, otsikkokentät ja dataosuus.
- 5-2.2 UDP JA TCP 2.2.1 User Datagram Protocol (UDP) IP:n päällä käytetään VoIP-liikenteessä yleensä UDP-protokollaa. UDP mahdollistaa usean yhteyden kanavoinnin (multiplexing) samassa koneessa. Näin yksi kone, jolla on yksi IP-osoite voi luoda monta samanaikaista yhteyttä erottamalla ne toisistaan UDP-porttiosoitteen perusteella. Esimerkiksi UDP portti numero 67 on varattu Bootstrap Protocol -palvelimelle, jolta levyttömät verkkokoneet voivat ladata käyttöjärjestelmänsä. UDP:n porteista 1024 ensimmäistä onkin varattu erilaisten palvelujen käyttöön, jotta asiakaskoneet tietäisivät suoraan mihin porttiin pakettinsa osoittavat halutessaan yhteyden johonkin tiettyyn palveluun [5]. Koska portti määritellään UDP-paketissa 16 bitillä, niin porttien kokonaislukumäärä on 65538. Porttien määräämisestä eri palveluille huolehtii Internet Assigned Numbers Authority (IANA), jonka on perustanut Yhdysvaltojen hallituksen alainen National Science Foundation. UDP:ssä olisi myös mahdollisuus datan virheenhavaitsemiseen tarkistussumman avulla, mutta tämä on valinnainen toiminto ja useimmissa toteutuksissa sitä ei käytetä. Lisäksi UDP-paketissa on vain lähde- ja kohdeporttinumerot, sekä paketin pituuden tavuina ilmoittava kenttä. Kuvassa 3 on UDP-paketin rakenne. UDP-paketin otsikkoa edeltävässä IP-otsikossa pitää protokollakentässä olla numero 17, jolloin vastaanottaja tietää kyseisen IPpaketin dataosuuden sisältävän UDP-paketin. UDP on kaikessa yksinkertaisuudessaan hyvin sopiva pienten levyttömien koneiden siirtoprotokollaksi (UDP-ohjelman toteutus vie vähän tilaa ROM-muistista) ja pienen käsittelyviiveen vaativille VoIP-ohjelmille, sillä muutaman otsikkokentän käsittely vie vähän aikaa ja tehoa. UDP:n määrittelevä RFC-dokumenttikin on vain kolmesivuinen. [6] Tavu: 0 7 8 15 16 23 24 31 +--------+--------+--------+--------+ Lähdeportti Kohdeportti +--------+--------+--------+--------+ Pituus Tarkistussumma +--------+--------+--------+--------+ data +----------------... Kuva 3. UDP-paketti
- 6-2.2.2 Transmission Control Protocol (TCP) Transmission Control Protocol (TCP) on UDP-protokollaa huomattavasti monipuolisempi siirtoprotokolla. TCP lisää UDP:n ominaisuuksiin mm. bittivirheiden havaitsemisen ja pakettien järjestyksen muuttumisen sekä hukkumisen havaitsemisen. Internetin liikenteestä suurin osa käyttää TCP:tä, tärkeimpinä HTTP (HyperText Transfer Protocol) ja FTP (File Transport Protocol) -protokollat. Virheidenhallintansa takia TCP soveltuukin hyvin tiedostojen ja WWW-sivujen siirtoon. TCP-toteutukset ovat kuitenkin varsin monimutkaisia ja isoja, erilaisten ikkuna-algoritmien ja uudelleenlähetysominaisuuksien takia, joten ne soveltuvat UDP:tä huonommin reaaliaikaisen VoIP-liikenteen välitykseen. TCP:n määrittelevä RFC-793 onkin 85 sivua ja sisältää vain osan toteutuksessa tarvittavista yksityiskohdista - lisää löytyy kymmenistä myöhemmistä RFC:istä, joissa käsitellään mm. parempia ikkunanhallinta-algoritmeja ja yksityiskohtaisempia toteutuksia, sekä monia muita laajennuksia. TCP tarjoaa sitä käyttäville ohjelmille luotettavan tavuvirran IP-verkon yli. Toisin sanoen lähdekoneessa TCP-sokettiin (socket, eli pistoke, on TCP/IP-pinon ja ohjelman välinen rajapinta) kirjoitetut tavut tulevat samanlaisina ja samassa järjestyksessä kohdekoneen soketista ulos. Tämän ansiosta TCP:n käyttäminen eri ohjelmissa on helppoa. TCP:n toiminnallisuutta voidaan luonnehtia viiden pääominaisuuden avulla: [7] 1. Tavuvirtaluonne. Kahden sovellusohjelman siirtäessä suurta määrää dataa verkon yli, voidaan dataa luonnehtia jonoksi kahdeksan bitin tavuja, jotka kohdekoneen tavuvirran tulopalvelu välittää vastaanottajalle täsmälleen samassa järjestyksessä kuin ne olivat lähetettäessä. 2. Virtuaalinen piirikytkentäinen yhteys. TCP on yhteydellinen protokolla, ja yhteyden luonti on analoginen puhelinsoiton kanssa ensin muodostetaan yhteys vastapuolen kanssa ja vasta sitten siirretään dataa, lopuksi yhteys katkaistaan. Jos yhteyden luonti ei onnistu, niin ohjelmalle annetaan virheilmoitus, eikä dataa yritetä siirtää (UDP esimerkiksi lähettäisi paketin kohdekoneelle mitään etukäteen kyselemättä).
- 7-3. Puskuroitu tiedonsiirto. TCP-protokolla osaa kerätä dataa suuremmaksi paketiksi, sitä käyttävän ohjelman ohjeiden mukaisesti, ennen datan lähettämistä verkon yli. Tällöin suurta keskisiirtonopeutta vaativissa sovelluksissa voidaan käyttää suurta paketin kokoa ja pientä viivettä vaativissa pientä paketin kokoa. 4. Rakenteeton tavuvirta. TCP:n vastaanottajalle toimittama tavuvirta ei muodosta mitään rakennetta, joten vastaanottavan ohjelman pitää itse osata tulkita tätä dataa TCP:n kannalta siirrettävä data on vain 8-bittisiä paloja. 5. Kaksisuuntainen yhteys. TCP-yhteydellä voidaan siirtää dataa molempiin suuntiin, joten ohjelmien kannalta TCP-yhteys muodostuu kahdesta tavuvirrasta. Kaksisuuntaisuuden etuna on, että TCP-protokolla voi lähettää kontrollitietoa vastapuolelle samalla kun se lähettää dataa siihen suuntaan. Kuvassa 4 on TCP-paketin rakenne, lisäksi edeltävään IP-paketin otsikkokenttään tulee protokollanumeroksi 7, jotta vastaanottaja osaa tulkita IPpaketin dataosan TCP-paketiksi. Tavu: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Lähdeportti Kohdeportti Sarjanumero Kuittausnumero Offset Varattu Liput Ikkuna Tarkistussumma Osoitin kiiredataan Optiot (jos yhtään) Täyte data +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-... Kuva 4. TCP-paketin rakenne Käyttämällä UDP/IP:tä saadaan siis useita erotettavissa olevia samanaikaisia puheluyhteyksiä oman ja toisessa verkossa olevan IP-koneen välille. VoIPpuhelun toteuttamiseksi tarvitaan vielä keino pakettien järjestyksen erottamiseksi, jotta huomataan tietovirrassa tapahtuneet pakettien järjestyksen muuttumiset, sekä pakettien hukkumiset. TCP mahdollistaisi nämä toiminnot, mutta sen käyttäminen on usein liian hidasta ja raskasta kun tavoitellaan mahdollisimman pieniviiveistä VoIP-puheyhteyttä.
- 8-2.3 RTP - REAALIAIKAISEN TIEDON SIIRTÄMINEN Reaaliaikainen tiedonsiirtoprotokolla (Real-Time Transfer Protocol, RTP) on IETF:n standardiehdotus (proposed standard), jonka avulla ääntä ja videota voidaan siirtää tahdistetusti ja siten, että hukkuneet tai järjestystä vaihtaneet paketit havaitaan. Ilman RTP:tä ongelmana olisivat esimerkiksi videokonferenssissa se, että paljon kaistaa vaativa video voisi saapua vastaanottajalle eri aikaan kuin vähän kaistaa vaativa puhe ja lisäksi varsinkin videon siirrossa pienetkin pakettien järjestyksen muuttumiset tekisivät kuvasta epämiellyttävän katsella. RTP-protokolla on yleensä toteutettu suoraan ohjelmissa, eikä käyttöjärjestelmän protokollapinon yhteydessä kuten TCP-, UDP- ja IPprotokollat. RTP on myöskin varsin uusi standardi, sillä se on määritelty vuonna 1996, mutta tästä huolimatta sitä käytetään jo monissa ohjelmissa. RTP:tä käytetään yleensä UDP/IP:n päällä, sillä esimerkiksi TCP:n uudelleenlähetysominaisuuksista olisi lähinnä haittaa (myöhässä tulleen paketin toistohetki olisi jo mennyt ohitse ja paketti hylättäisiin, uudelleenlähetys siis vain lisää verkon ruuhkaisuutta ilman mitään hyötyä). RTP ei takaa pakettien perillemenoa, eikä se takaa paketin perille tuloa ajoissa - RTP:ssä ei siis ole palvelunlaatutoimintoja (QoS). Jos ehdottomasti tarvitaan varmuutta perillemenosta, niin on käytettävä jotain muuta tekniikkaa sen varmistamiseksi, esimerkiksi TCP:tä alemmalla tasolla. RTP:tä käytetään myös MBONE-verkossa, joka on tavallisen Internet-verkon päälle tunneloimalla rakennettu joukkolähetysverkko, jossa välitetään videota ja ääntä muun muassa IETF:n kokouksista ja NASA:n tapahtumista [8]. RTP onkin jo alunperin suunniteltu tukemaan joukkolähetyksiä. RTP-palvelun tarjoamiseksi on sovellusohjelman, esimerkiksi VoIP-ohjelman, toteutettava kaksi protokollaa: itse RTP, jonka tehtävä on kuljettaa data, ja RTCP (RTP Control Protocol), jonka tehtävä on yhteyden hallinta ja valvonta [8]. Näiden toiminta käydään läpi seuraavissa kappaleissa.
- 9-2.3.1 Real-time Transport Protocol (RTP) RTP-paketti sisältää aikaleiman ja järjestysnumeron pakettien järjestyksen muuttumisen ja hukkumisen havaitsemiseksi. RTP-paketin otsikko on kuvassa 5 [9]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Ver T X määrä M sis.tyyppi sarjanumero aikaleima synkronointilähteen tunniste (SSRC) +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ osallistuvien lähteiden tunnisteet (max. 16 kpl)... Kuva 5. RTP-paketti [9]. Kenttien merkitykset ovat seuraavat [8], [9]: Ver: Versiokenttä, arvo 2. T: Täyte, jos arvo on 1, niin lopussa on täytettä paketin viimeisen oktetin ilmoittaman määrän verran. X: Laajennusotsikko, jos arvo on 1, niin normaalien otsikkokenttien jälkeen seuraa yksi ylimääräinen otsikkokenttä. Tämä mahdollistaa protokollan toiminnallisuuden myöhemmän laajentamisen. Määrä: Kertoo montako synkronointilähteen tunnistekenttää otsikkoon sisältyy. M: Merkkibitti, varattu tulevaa käyttöä varten. Sis.tyyppi: Kertoo paketin sisältämän datan tyypin, esimerkiksi GSM-pakatun äänen tyyppi on 3.
- 10 - Sarjanumero: Juokseva sarjanumerointi, jolla pakettien järjestys selvitetään vastaanottopäässä. Aikaleima: Kertoo milloin paketin datan ensimmäinen oktetti on näytteistetty. Tämän avulla eri lähteistä tulevat tietovirrat osataan toistaa samaan aikaan (esimerkiksi puhe videokuvan kanssa synkronoidusti). Synkronointilähteen tunniste: Tunniste RTP-lähteelle. Jokaisella lähteellä eri, joten vastaanottaja tietää tämän avulla mitkä RTP-paketit kuuluvat kenellekin. Esimerkiksi videoneuvottelussa jokaisen osallistujan mikrofonille voitaisiin antaa oma tunniste, jolloin vastaanottaja tietää kuka puhuu. Osallistuvien lähteiden tunnisteet: Mikäli tämän paketin tietovirtaan on sekoitettu useampi lähde mikserillä, niin näissä kentissä kerrotaan kaikkien mukana olijoiden tunnisteet. Esimerkiksi videoneuvottelussa osallistujien keskellä oleva mikrofoni voisi lähettää ääntä, jonka osallistujiksi olisi tässä kentässä listattu kaikki paikalla olevat. Esimerkki tietovirrasta kahden videoneuvottelijan välillä on kuvassa 6.
- 11 - VoIP -ohjelma VoIP -ohjelma RTP RTP UDP UDP IP Internet IP... IP UDP RTP Data... IP UDP RTP Data... Kuva 6. VoIP-neuvottelu. Jokainen puhetta/videota sisältävä paketti koostuu siis kaikkien alapuolella olevien protokollien otsikoista. Tämä laskee tiedonsiirron hyötysuhteen usein varsin alhaiseksi, sillä hitailla yhteyksillä (kuten modeemiyhteyksillä) joudutaan käyttämään pieniä näytteistyspaketteja siedettävän viiveen saamiseksi. Tällöin pakettien koosta saattaa olla jopa yli puolet otsikkotietoja. Jokainen paketti sisältää samat otsikkokentät sarjanumeroita ja aikaleimoja lukuun ottamatta, eli samoja otsikkokenttiä toistetaan kokoajan. Otsikkojen viemän kapasiteetin pienentämiseksi on tehty muutamia parannusehdotuksia. RFC-2508:ssä esitellään IP/UDP/RTP -otsikkokenttien pakkausmenetelmä, jossa samoina pysyviä otsikkokenttiä ei lähetetä toistuvasti, vaan vain silloin kun niiden sisältämä tieto muuttuu (esimeriksi RTPyhteydelle tulee mukaan uusi lähde). Tämä mahdollistaa paremman puheen ja
- 12 - videon laadun erityisesti hitailla yhteyksillä, kuten 28,8 kbit/s modeemiyhteyksillä. Lisäksi tämä otsikkokenttien pakkaaminen on suunniteltu toteutettavaksi tilaajayhteyksillä, eli käyttäjän ja verkon reunalaitteen välillä. Käyttäjän lähetettyä ensimmäisen pakettinsa, verkon reunalaite pistää sen otsikkokentät muistiin ja tämän jälkeen käyttäjä voi lähettää seuraavat paketit lyhyellä 2-4 tavun otsikolla, johon verkon reunalaite lisää puuttuvat kentät ennen verkkoon lähetystä. Samoin menetellään tulevan pakettivirran kanssa. Useampi yhtäaikainen pakettivirta erotetaan toisistaan IP:n kohde/lähtöosoitteiden, kohde/lähtö UDP-porttien ja RTP:n lähdetunnisteen muodostaman viisikon avulla. RFC-2508 on vasta standardiehdotus (proposed standard), sillä se on varsin uusi (vuodelta 1999). [10] Toinen idea VoIP-liikenteen hyötysuhteen parantamiseksi on käyttää verkkotekniikkana MPLS:ää [11]. MPLS muodostaa lyhyellä tunnisteella (leimalla) erotettuja yhteyksiä (voita), jolloin tietty reitti verkon läpi on tunnistettavissa tämän lyhyen leiman avulla. Yhteyden muodostamisen jälkeen PPP/IP/UDP/RTP -otsikkokentät (49 tavua) voidaan korvata lyhyellä 13 tavun tunnisteella. Lisäksi on olemassa valmistajakohtaisia ratkaisuja, kuten Motorolan VoFR-ratkaisu, jossa otsikkojen tiedot kuvataan kehysvälitysotsikkoihin [11]. 2.3.2 RTP Control Protocol (RTCP) RTP control protocol (RTCP) on RTP-yhteyden hallintaprotokolla. RTP osaa lähettää vain datapaketteja ja RTCP:tä tarvitaan kertomaan lähettäjälle tietoa miten nämä paketit saapuvat perille. Esimerkiksi ruuhkatilanteessa RTCP:llä voidaan pyytää lähettäjää hiljentämään vauhtia. RTCP lähettää pakettinsa vastapuolen UDP-porttiin, joka on yhdellä isompi kuin käytetyn RTP-portin numero (RTP-portin pitää olla parillinen numero, joten RTCP-portti on aina pariton).
- 13-0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 V=2 P RC PT=RR=201 pituus otsikko SSRC-tunniste +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ SSRC_1 (ensimmäisen lähteen SSRC-tunniste) raportti lohko hukkunut osa hukkuneiden pakettien kumulatiivinen määrä 1 suurin vastaanotettu paketin sarjanumero viiveen värinä edellisen SSRC_1:ltä saadun raportin aikaleima aikaero kun edellinen raportti vastaanotettu (1/65536 s) +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ SSRC_2 (toisen lähteen SSRC-tunniste) raportti lohko :... : 2 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ profiilin mukaiset laajennusotsikot Kuva 7. Vastaanottajan raportti on tyypillinen RTCP-paketti. [9] Kuvassa 7 on vastaanottajan raportti (receiver report, RR) RTCP-pakettina. Tämä on RTP-lähetyksessä yleisin RTCP-pakettityyppi. Muita mahdollisia RTCP-pakettityyppejä olisivat lähettäjän raportti (sender report, SR), lähetyksen kuvaus (source description, SDES), osallistumisen lopetus (end of participation, BYE) ja sovellutuskohtainen toiminto (application specific function, APP). [9] Vastaanottajan raportissa voidaan kertoa montako pakettia on hukkunut sitten edellisen raportoinnin, montako pakettia kaikkiaan on hukkunut, mikä on tuorein vastaanotettu paketti, kuinka suuri värinä (viiveen vaihtelu) on, mikä edellisen vastaanotetun lähettäjäraportin aikaleima oli ja kuinka kauan sen vastaanottamisesta on (yksikkönä 1/65536 sekuntia) [9]. Näiden tietojen avulla lähettäjä voi laskea vastaanottajan kokeman viiveen ja mahdollisesti pienentää lähettämiensä pakettien kokoa lyhentääkseen sitä. Samoin jos paketteja on hukkunut huomattava osa, niin lähettäjä voi pienentää lähetysnopeutta laadun parantamiseksi. RTCP-paketteja lähetetään eri väliajoin, riippuen esimerkiksi siitä kuinka monta osallistujaa konferenssissa on. RTP-määrityksessä suositellaan, että RTCPliikenteelle pitäisi varata 5% istunnon kaistanleveydestä ja että RTCP-paketteja lähetetään korkeintaan viiden sekunnin välein. Lisäksi RTCP-pakettien lähetysajan kerroin arvotaan väliltä [0.5, 1.5]. [9]
- 14-2.3.3 Audio- ja videokonferenssi profiili RTP:lle voidaan määritellä eri käyttötarkoitusten mukaisia profiileja, jolloin RTP ja RTCP pakettien kenttien tiedot voidaan tulkita eri tavoin. RFC-1890:ssa on määriteltynä oletusprofiili, joka määrittelee RTP-paketin sisällön tyyppi kentän tulkinnat taulukon 1 mukaisesti Taulukko 1. Sisällön tyyppi -kentän tulkinnat A/V profiilin mukaisesti. [12] sisällön esitystavan audio/video näytteistys- (audio) tyyppi nimi (A/V) taajuus (Hz) kanavia 0 PCMU A 8000 1 1 1016 A 8000 1 2 G721 A 8000 1 3 GSM A 8000 1 4 vapaa A 8000 1 5 DVI4 A 8000 1 6 DVI4 A 16000 1 7 LPC A 8000 1 8 PCMA A 8000 1 9 G722 A 8000 1 10 L16 A 44100 2 11 L16 A 44100 1 12 vapaa A 13 vapaa A 14 MPA A 90000 15 G728 A 8000 1 16--23 vapaa A 24 vapaa V 25 CelB V 90000 26 JPEG V 90000 27 vapaa V 28 nv V 90000 29 vapaa V 30 vapaa V 31 H261 V 90000 32 MPV V 90000 33 MP2T AV 90000 34--71 vapaa? 72--76 varattu 77--95 vapaa? 96--127 dynaaminen? Tyypit 96-127 on varattu dynaamisille määrittelyille, jolloin käytetty RTP-ohjelma voi määritellä näiden tarkoituksen yhteyden aikana. VoIP-sovellutus voisi siis esimerkiksi sopia hallintayhteydellä, että tyyppi 96 tarkoittaisi dolby surround koodattua 44100 khz stereoääntä ja tyyppi 123 tarkoittaisi GSM-pakattua 8000 hertsillä näytteistettyä stereoääntä. Perusvaatimuksena pidetään, että tätä oletusprofiilia käyttävä ohjelma tukisi vähintään tyyppejä 0 (mono 8 khz PCMU) ja 5 (mono 8 khz DVI4), jotta myös sellaiset ohjelmat jotka eivät tue esitystapaneuvottelua voisivat kommunikoida keskenään. [12]
- 15 - Taulukossa 2 on esitetty äänen esitystapojen ominaisuuksia. Taulukosta nähdään, että esimerkiksi GSM-esitystapa on kehyspohjainen ja yhden kehyksen pituus on 20 ms. Tämä tarkoittaa, että GSM-muodossa yksi 20 ms näyte pakataan erillisenä ja lopputulokseksi saadaan pienempi, yleensä vakiokokoinen, kehys. Vastaavasti nähdään, että G.722-esitystapa on näytemuotoinen ja yksi näyte on kooltaan 8 bittiä. Tällöin saadaan tasainen tietovirta, jota sitten pyritään pakkaamaan ja lopputuloksena on myös tasainen tietovirta (vrt. kehyspohjainen purskeinen tietovirta). Taulukko 2. Äänen esitystapojen ominaisuuksia. esitystapa näyte/kehys bittiä/näyte ms/kehys 1016 kehys - 30 DVI4 näyte 4 G721 näyte 4 G722 näyte 8 G728 kehys - 2.5 GSM kehys - 20 L8 näyte 8 L16 näyte 16 LPC kehys - 20 MPA kehys - PCMA näyte 8 PCMU näyte 8 VDVI näyte vaihtelee Lisäksi RFC-1890:ssä on annettu ohjeet uusien esitystapojen rekisteröimiselle. Rekisteröinnistä vastaa Internet Assigned Numbers Authority (IANA). Esimerkiksi stereomuotoisia esitystapoja ei ole määrättynä kuin yksi (L16, joka on lisäksi pakkaamaton), joten lähiaikoina kirjoittajan mielestä on odotettavissa joitain lisäyksiä FM-radiotasoisen stereomuodon kiinteälle määrittelylle (toki nykyiset ohjelmat voivat käyttää dynaamisia tyyppejä stereolähetyksiin keskusteltuaan tästä ensin keskenään, mutta se asettaa sovellutusohjelmien toteutuksille lisävaatimuksia). 2.4 H.323 VoIP-yhteyden muodostamiseksi ilman sovelluskohtaisia yhteensovituksia tarvitaan vielä esimerkiksi ITU-T:n H.323-protokollan toteutus, jonka avulla eri valmistajien VoIP-ohjelmat voivat keskustella keskenään (esimerkiksi kutsua toista osapuolta ja sopia datan esitystavasta ennen varsinaisen puheyhteyden muodostamista). Lisäksi RTCP:lla, RTP-yhteyden hallintaprotokollalla, ei voida suorittaa yhteyden muodostamisessa tarvittavia toimintoja, koska RTCP rajoittuu lähinnä lähteiden yksilöimiseen ja yhteyden laadun raportointiin.
- 16 - H.323 standardin ensimmäinen versio on jo vuodelta 1996 (version 2 vuodelta 1998 ja versio 3 vuodelta 1999) ja se esittelee joukon standardeja multimediayhteyksien luomiseksi laatua takaamattomien pakettiverkkojen yli. Tällaisia verkkotekniikoita ovat esimerkiksi Ethernet ja Token Ring -tekniikat. H.323 on hyvin kattava standardikokoelma ja samalla määrityksissään joustava, joten sen mukaisia päätelaitteita voivat olla niin yksinkertaiset käsipuhelimet kuin täysimittaiset videoneuvottelulaitteistotkin. H.323 standardin suosiolle on useita syitä, muun muassa se, että standardi hyödyntää nykyisin hyvin yleisiä lähiverkkotekniikoita, joiden nopeudet ovat lisäksi eksponentiaalisessa kasvussa ja lisäksi koska H.323 ratkaisee terminaalien yhteensopivuusongelmat, määrittelee eri verkkotekniikoiden yhteentoimimisen (mahdollistaen esim. tavallisen puhelinverkon ja lähiverkon välisen yhteyden) ja mahdollistaa lisäksi verkon H.323-liikenteen määrän hallinnan. [13] 2.4.1 H.323-verkon rakenne ja toiminta 2.4.1.1 Verkon laitteet H.323 määrittelee tekniset vaatimukset multimediayhteyksille epäluotettavan pakettiverkon yli. H.323-järjestelmä koostuu päätelaitteista, yhdyskäytävistä (gateway, GW), portinvartijoista (gatekeeper, GK), monipisteohjamista (multipoint controller, MC), monipistekäsittelijöistä (multipoint processor, MP) ja monipisteohjainyksiköistä (multipoint controller unit, MCU). H.323:n mukaisen verkon osat on esitelty kuvassa 8.
- 17 - H.323 päätelaite H.323 portinvartija H.323 MCU pakettiverkko H.323 päätelaite H.323 yhdyskäytävä H.323 päätelaite Yhdeydet GSTN, N-ISDN ja B-ISDN -verkkoihin, joissa voi olla tavallisia POTS/ISDN-puhelimia, sekä V.70, H.320, H.321, H.322 ja H.324 mukaisia päätelaitteita. Kuva 8. H.323:n mukaisen verkon osat. H.323 standardin mukaisen terminaalin pitää sisältää vähintään järjestelmän hallintayksikkö (system control unit), audiokoodekki, H.225-kerros ja verkkoliityntä. H.225-kerros muodostaa rajapinnan verkkoon päin ja huolehtii mm. siirrettävän tiedon pilkkomisesta paketteihin ja muusta tarvittavasta muotoilusta (RTP-protokollan avulla), sekä signalointitietoa sisältävien pakettien ollessa kyseessä varmistaa niiden perillemenon. Järjestelmän hallintayksikkö puolestaan sisältää yhteyden muodostamiseen, purkamiseen ja hallintaan tarvittavat toiminnot, jotka on määritelty standardeissa H.225 ja H.245. Näitä toimintoja ovat mm. H.225:n soitettavan sijainnin kysyminen (location request), kaistanvarauspyyntö portinvartijalle (bandwidth request) ja yhdenlopetusviesti (disengage request) [15], sekä H.245:n loogisten kanavien avaus- ja sulkupyynnöt ja vuonhallintaviestit. H.245:n viestit on määritelty käyttämällä ASN.1-kuvauskieltä. Lisäksi jos päätelaite haluaa salata yhteyden, sen tulee käyttää standardissa H.235 kuvattua tapaa. Kuvassa 9 on esimerkki H.323 mukaisesta päätelaitteesta.
- 18 - Videorajapinta Videokoodekit H.261, H.263 datarajapinta T.120 ja muut Audiokoodekit G.711, G.722, G.723, G.728, G.729 Järjestelmän hallinta Audiorajapinta H.225.0- kerros Lähiverkkoliityntä Käyttöliityntä järjestelmän hallintayksikköön H.245 kontrolli puhelunhallinta H.225.0 RAS kontrolli H.225.0 Kuva 9. Esimerkki H.323-mukaisesta päätelaitteesta. Standardiin H.323 kuuluvat osat ovat vahvennetulla. [14] H.323-verkko jaetaan alueisiin (zone), jonka sisällä pitää olla vähintään yksi portinvartija. Portinvartija vastaa alueensa H.323-verkon resurssien käytöstä, eli toimii kuvainnollisesti alueensa johtajana. 2.4.1.2 H.323 verkon toiminta H.323-verkon päätelaitteet keskustelevat joko suoraan toistensa kanssa tai valinnaisen portinvartijan läsnäollessa sitä apunaan käyttäen. Vaikka portinvartija ei ole H.323-verkossa pakollinen, on siitä huomattavaa hyötyä, sillä se pystyy tekemään osoitteiden muunnoksia (esim. sähköpostiosoite IPosoitteeksi), huolehtimaan pääsynhallinnasta ja tiedonsiirtokapasiteetin käytöstä, sekä kaupallisten sovellutusten kannalta välttämättömästä laskutustiedon keräämisestä. Portinvartijan avulla voidaan siten määritellä, ettei verkkoa kuormiteta VoIP-liikenteellä esimerkiksi yli 50% käyttöasteella ja samalla osoitteenmuunnospalvelun avulla voidaan muodostaa yhteys toisiin päätelaitteisiin niiden tarkkaa osoitetta etukäteen tietämättä. [14,16] 2.4.1.2.1 Esimerkkisoitto H.323-päätelaitteen halutessa puheluyhteyden vastapuoleen, verkossa jossa on portinvartija, pitää sen ensin rekisteröidä itsensä. Tämä tapahtuu automaattisen portinvartijan paikannustoiminnon avulla. Rekisteröinti tapahtuu käytännössä
- 19 - IP-verkossa siten, että päätelaite lähettää TCP/IP-paketin tunnettuun joukkolähetysosoitteeseen (multicast address) ja odottaa portinvartijan vastausta viisi sekuntia. Jos vastausta ei kuulu, voi päätelaite yrittää uudestaan tai kysyä käyttäjältä portinvartijan osoitetta. Rekisteröinnin onnistuessa päätelaite saa portinvartijalta vahvistuksen, joka voi lisäksi sisältää rekisteröinnin voimassaoloajan ja päätelaitteelle varatun aliaksen (esim. sähköpostiosoite tai E.164 numero). Rekisteröinnin voi purkaa joko portinvartija tai päätelaite rekisteröinninperuutusviestillä (unregister request). [14,16] Kun päätelaite on rekisteröitynyt, se pyytää portinvartijalta tarvitsemaansa kaistaa soittoa varten ja samalla kysyy portinvartijalta tavoittelemansa vastapuolen aliasta vastaavaa osoitetta. Esimerkiksi mylipiet@cc.hut.fi voisi muuttua IP-osoitteeksi 130.233.45.67 tai E.164-numeroksi +35894681234. Jos vastauksena tulee E.164-numero tai muu erityyppisen verkon osoite, joutuu päätelaite keskustelemaan mahdollisen yhdyskäytävän kanssa muodostaakseen yhteyden tähän ulkopuolisessa verkossa olevaan vastapuoleen. Jos vastapuoli puolestaan on samassa verkossa, eli vastaus on esimerkin mukainen IP-osoite, päätelaite lähettää yhteyspyynnön yleensä suoraan tähän osoitteeseen. Tosin H.323 mahdollistaisi myös portinvartijan käytön viestien välittäjänä, mutta oletetaan tässä esimerkissä suoran päätelaitteiden välisen merkinannon olevan käytössä. Tavoitellun päätelaitteen saadessa yhteyspyynnön (setup-viesti), sekin joutuu ensin pyytämään portinvartijalta tarvitsemaansa kaistaa ja tämän jälkeen mahdollinen yhteys voidaan muodostaa - jos siis tavoiteltu osapuoli vastaa puhelimeen. Esimerkin mukaiset merkinantoviestit on esitetty kuvassa 10.
- 20 - Soittaja Portinvartija Soitettu ARQ ACF Setup Call Proceeding ARQ ACF Alerting Connect Yhteys muodostettu Kuva 10. Merkinantoviestit esimerkissä. Tummennetulla merkityt viestit käyttävät epäluotettavaa kuljetustapaa (RAS signalling) ja muut käyttävät luotettavaa kuljetustapaa (H.225.0 signalling). [14] Kuvassa ARQ on kaistanvarauspyyntö (admission request) ja ACF vahvistus siihen (admission confirm). Vahvistus voi sisältää myös pyydettyä pienemmän yhteysnopeuden, jolloin päätelaite joutuu käyttämään tätä pienempää nopeutta. Setup-viesti on yhteyspyyntö soitetulle osapuolelle ja Call Proceeding -viesti on tieto soittajalle, että puhelun käsittely etenee. Alerting-viesti kertoo, että vastapuolen puhelin tms. hälyttää ja Connect-viestin mukana saapuu yksilöllinen yhteystunniste ja puheludataa voidaan alkaa siirtämään. [14] Yhteys puretaan kolmivaiheisella merkinannolla päätelaitteiden kesken ja yhteyden purkamisen onnistuttua kummatkin päätelaitteet ilmoittavat portinvartijalle, etteivät ne enää tarvitse varaamaansa kaistaa. H.323 määrittelee yllä olevan esimerkin lisäksi kymmenen muuta merkinantojärjestystä, joilla yhteys voidaan muodostaa. Erikoistilanteita ovat esimerkiksi: toinen osapuoli ei ole rekisteröitynyt portinvartijalle, soittajalla ja soitetulla on eri portinvartijat ja toisen osapuolen portinvartija edelleenvälittää viestit (gatekeeper routed call signalling).
- 21-2.4.1.3 Nopea yhteydenmuodostus H.323-verkko pystyy tarjoamaan nopeaa yhteydenmuodostusta vaativille sovellutuksille nk. fast connect toiminnon. Tämän toiminnon avulla soittaja voi lisätä lähettämäänsä Setup-viestiin kaikki yhteyden muodostamiseen tarvittavat parametrit, jolloin soitettu voi nämä parametrit hyväksyessään aloittaa multimedialähetyksen. Näin meneteltäessä yhteyden muodostusaika tulee olemaan vain yhden kiertoaikaviiveen suuruinen.[14] 2.4.1.4 Konferenssipuhelu Jos verkossa on MCU, eli monipisteohjainyksikkö, niin usean käyttäjän välinen multimediayhteys on mahdollinen keskitettynä konferenssina (centralized multipoint conference). Tällöin esimerkiksi videokokouksen osallistujat voisivat olla kukin eri paikassa. Monipisteohjainyksikön perusajatus on yhdistää eri käyttäjiltä tulevat tietovirrat sopivalla tavalla ja jakaa tämä yhdistetty tieto osallistujille. MCU voidaan käyttää ottamalla se mukaan kun kahden käyttäjän välinen yhteys laajenee kolmen väliseksi, tai yhteydet voidaan alusta lähtien muodostaa MCU:n kautta. Ensiksi mainitussa tapauksessa portinvartija joutuu ohjaamaan osallistujat käyttämään MCU:ta ja jälkimmäisessä tapauksessa käyttäjät lähettävät yhteyspyyntönsä MCU:lle samalla tavalla kuin kahdenvälisestä yhteyttä muodostettaessa (siis esimerkiksi kuvan 10 tavalla). Vaihtoehtoinen tapa konferenssiyhteyden muodostamiseksi on, että jokainen osallistuja lähettää datansa jokaiselle muulle konferenssinosallistujalle joukkolähetyksenä (multicast) [14]. Tämän tavan etuna on, ettei verkossa tarvitse olla erityistä MCU:n toimintoja toteuttavaa laitetta. Tällöin kuitenkin edellytetään toimivaa joukkolähetystoteutusta verkolta ja sen reitittimiltä. Myös konferenssiin kutsuminen, liittyminen ja poistuminen on määritelty erilaisia toteutuksia silmälläpitäen. 2.5 SESSION INITATION PROTOCOL Session Initation Protocol (SIP) on Internet Engineering Task Forcen (IETF) reilun vuoden ikäinen ehdotettu standardi. SIP on tekstipohjainen, samaan
- 22 - tyyliin kuin HTML ja SMTP, protokolla vuorovaikutteisten käyttäjien välisten yhteyksien avaamiseen. Näillä yhteyksillä voidaan siirtää esimerkiksi ääntä, videota, tekstiä, pelitietoa tai keinotodellisuustietoa. [17] 2.5.1 SIP viestien rakenne SIP viestit koostuvat pyynnöistä ja vastauksista, sekä näihin mahdollisesti liitetyistä otsikkokentistä. Pyyntöjä on kuutta eri tyyppiä, samoin kuin vastausluokkia nämä vaihtoehdot on lueteltu taulukossa 3. [18] Taulukko 3. SIP viestiluokat. Pyyntö Selitys Vastaus Selitys INVITE Käyttäjän tai palvelun mukaan pyytäminen 1xx Tiedotus ACK Vahvistaa viimeisen Invite-vastauksen 2xx Onnistuminen OPTIONS Kysyy palvelimen ominaisuudet 3xx Uudelleenohjaus BYE Katkaise yhteys 4xx Asiakkaan virhe CANCEL Peru lähetetyt pyynnöt 5xx Palvelimen virhe REGISTER Rekisteröidy SIP palvelimelle 6xx Globaali virhe Nämä viestit voivat lisäksi sisältää joukon otsikkokenttiä, joiden avulla tarkennetaan viestin tarkoitusta. Kaikki SIP-standardissa määritellyt otsikot ovat taulukossa 4. Näiden lisäksi voidaan määritellä omia sovellutuskohtaisia otsikoita helposti. [18] Taulukko 4. SIP-viestien mahdolliset otsikkokentät. Otsikkokenttä Kohta SIP-määrittelyssä Accept Kappale 6.7 SIP-määritellyssä Accept-Encoding Kappale 6.8 Accept-Language Kappale 6.9 Call-ID Kappale 6.12 Contact Kappale 6.13 CSeq Kappale 6.17 Date Kappale 6.18 Encryption Kappale 6.19 Expires Kappale 6.20 From Kappale 6.21 Record-Route Kappale 6.29 Timestamp Kappale 6.36 To Kappale 6.37 Via Kappale 6.40 Content-Encoding Kappale 6.14 Content-Length Kappale 6.15 Content-Type Kappale 6.16 Authorization Kappale 6.11 Contact Kappale 6.13 Hide Kappale 6.22 Max-Forwards Kappale 6.23 Organization Kappale 6.24 Priority Kappale 6.25 Proxy-Authorization Kappale 6.27 Proxy-Require Kappale 6.28 Route Kappale 6.33 Require Kappale 6.30 Response-Key Kappale 6.31 Subject Kappale 6.35 User-Agent Kappale 6.39 Allow Kappale 6.10 Proxy-Authenticate Kappale 6.26 Retry-After Kappale 6.32 Server Kappale 6.34 Unsupported Kappale 6.38 Warning Kappale 6.41 WWW-Authenticate Kappale 6.42
- 23-2.5.2 Invite - Yhteyden pyytäminen SIP-palvelimen avulla soittaja voi kutsua vastapuolta tietämättä hänen senhetkistä olinpaikkaa. Soittajan VoIP-pääteohjelma toimii SIPasiakasohjelmana, kun se lähettää Invite-viestin verkossa olevalle SIPpalvelimelle. Soittaja saa erilaisen vastauksen riippuen siitä onko SIP-palvelin asetettu toimimaan uudelleenohjaus- (Redirect) vaiko edelleenvälitystilassa (Proxy). Jos SIP-palvelin on uudelleenohjaustilassa, niin soittaja saa tavoittelemansa henkilön voimassaolevan kutsuosoitteen ja jos SIP-palvelin toimii edelleenvälitystilassa, niin palvelin kutsuu itse vastapuolta ja ilmoittaa soittajalle vasta kun yhteys on valmis muodostettavaksi tai kun vastapuoli on hylännyt puhelun. Uudelleenlähetystilassa toimivasta SIP-palvelimesta on esimerkki kuvassa 11. Soittaja INVITE 100 Trying 180 Ringing 200 OK ACK SIP palvelin 1 INVITE 100 Trying 180 Ringing 200 OK ACK SIP palvelin 2 Soitettu INVITE 180 Ringing 200 OK ACK Yhteys muodostettu Kuva 11. Uudelleenlähettävä SIP palvelin välittää kutsun soitetulle, joka hyväksyy yhteyden, käytännössä eli vastaa puhelimeen. [19] SIP-asiakasohjelman lähettämä Invite-kutsu sisältää yleensä kaiken tarpeellisen tiedon yhteyden muodostamiseksi. SIP on varsin laaja standardi, sillä sen sanomiin on määritelty lähes 40 otsikkokenttää. Eräät näistä otsikkokentistä ovat Content-alkuisia ja niiden avulla voidaan lisätä viestiin jonkin toisen protokollan sanoma, mikä lisää SIP:n monimuotoisuutta entisestään. [18] Tätä
- 24 - ominaisuutta hyödynnetäänkin yhteyttä avattaessa tällöin Invite-viestiin sisältyy SDP:n (Session Description Protocol [20]) avulla määritelty yhteyden kuvaus. Esimerkki tällaisesta SDP-kuvauksen sisältävästä SIP Invite-viestistä on seuraavanlainen: INVITE sip:soitettu@sipserver.keskus.hut.fi SIP/2.0 Via: SIP/2.0/UDP asunto.tky.hut.fi:5060 From: Soittaja <sip:soittaja@hut.fi> To: Soitettu <sip:soitettu@keskus.hut.fi> Call-ID: 12345600@asunto.tky.hut.fi CSeq: 1 INVITE Contact: Soittaja <sip:soittaja@hut.fi> Content-Type: application/sdp Content-Length: 147 v=0 o=soittaja 2890844526 2890844526 IN IP4 asunto.tky.hut.fi s=juttutuokio erikoistyosta c=in IP4 130.233.25.71 t=0 0 m=audio 49170 RTP/AVP 0 Tällä viestillä pyydettäisiin yhteyttä, joka olisi RTP ääniyhteys, tyyppiä 0 (PCMU mono 8000 khz). 2.5.3 Käyttäjän paikallistaminen Kun käyttäjä lähettää Invite-viestin palvelimelle, pitää palvelimen jotenkin selvittää vastapuolen käyttämä SIP-palvelin. Tämä tapahtuu kysymällä Location Service tietokannasta. SIP-palvelin voi käyttää kysymyksen tekoon esimerkiksi SIP-määrittelyssä ehdotettuja finger[21], rwhois[22], LDAP[23] tai multicast user directory[24] palvelua tai jotain muuta toteutuskohtaista protokollaa käyttäen. Jotta tietokannassa olisi aina ajantasainen tieto käyttäjän olinpaikasta, pitää käyttäjän rekisteröityä käyttämälleen SIP-palvelimelle, joka sitten välittää tiedon käyttäjän sijainnista Location Service -tietokantaan. [18] 2.5.4 SIP Universal Resource Locator Jokainen SIP-käyttäjä yksilöidään tunnisteella, joka on muotoa sip:käyttäjä@kone tai sip:puhelinnumero@yhdyskäytäväkone [18]. Eli esimerkkejä tällaisista osoitteista ovat: mika.ylipieti@sipserver.hut.fi ja +358-9-4551234@sipgateway.hut.fi.Lisäksi voidaan käyttää lyhyempää muotoa, esimerkiksi mika.ylipieti@hut.fi, jos hut.fi koneen DNS-tiedoissa on
- 25 - merkintä käytettävästä SIP-palvelimesta. Yhteyttä muodostettaessa SIPosoitteen loppuun voidaan lisätä yhteyskohtaisia lisäparametrejä, ";"-merkillä erotettuna, kuten käytettävä TTL-arvo tai protokolla, lisäksi PSTN-verkkoon soitettaessa osoitteen perään tulisi merkitä user=phone [18]. 2.6 LAADUN TAKAAMINEN Tähän mennessä VoIP-yhteyden tiedonsiirto- ja hallintaprotokollat on käyty läpi. Eli vastapuoli on paikallistettu ja puheyhteys on saatu avattua. Mutta koska kyseessä on yleensä jaettu media, kuten lähiverkko, on yhteyden mahdollista ruuhkaantua ja puheenlaadun siitä kautta heikentyä. H.323-verkossa tosin on mahdollista, ettei portinvartija hyväksy uusia yhteyksiä, jos käynnissä on jo maksimimäärä yhteyksiä, tai uuden yhteyden vaatimuksia ei muutoin pystyttäisi täyttämään. Yleensä H.323-portinvartijaa ei kuitenkaan ole käytettävissä, jolloin laadun takaamiseksi käytetään joko IP-paketin palvelunlaatukentän (Type of Service field) uudelleenmäärittelevää DiffServ-palvelua tai kapasiteettivarauksen koko verkon läpi tekevää Resource ReSerVation Protocol (RSVP) -protokollaa. Näitä kahta tapaa käsitellään seuraavissa kohdissa. 2.6.1 Resource Reservation Protocol (RSVP) Resource reservation protocol (RSVP) siis takaa yhteyden laadun (pakettien hukkumistodennäköisyyden, viiveen ja kapasiteetin, sekä näiden vaihtelun). RSVP on IETF:n protokolla ja se on määritelty, jotta verkon omistaja voisi hallita linkkien kapasiteettien jakoa eri liikenneluokkien kesken. Tällainen protokolla mahdollista niin sanotut yhdistetyt palvelut (Integrated Services, tosiaikaiset ja best-effort palvelut samassa IP-verkossa) [25]. RSVP-protokollaa käytetään sekä päätelaitteessa (VoIP-puhelin) että verkon reitittimissä. Päätelaite voi pyytää verkosta tietyt laatuvaatimukset täyttävää yhteyttä, esimerkiksi hyvin pieniviiveistä yhteyttä videoneuvottelua varten. Pyynnön saatuaan verkon reunareititin tarkistaa, saako kyseinen asiakas tehdä tällaista varausta ja voiko verkko tarjota kyseistä palvelua näitä tarkistuksia kutsutaan menettelytavan tarkastukseksi (policy control) ja pääsynhallinnaksi (admission control) [26]. Kuvassa 3.3.1.1 on esitetty RSVP-protokollaa käyttävä reititin.
- 26 - Reititin RSVP-varauspyyntöjä RSVP-varauspyyntöjä RSVP prosessi sitten ohjeistus ensin tarkistus reititysprosessi menettylytavan tarkastus pääsynhallinta paketteja pakettien luokittelija pakettien ajoitin (scheduler) paketteja Kuva 3.3.1.1. RSVP-reititin tarkistaa varauspyynnöt ja käsittelee paketit sen mukaisesti. RSVP-varauspyynnöt menevät koko verkon läpi ja jokaisen välillä olevan reitittimen pitää hyväksyä yhteys ennen kuin se voidaan muodostaa. Tämän takia kaikkien yhteyttä käyttävien pakettien pitää kulkea samaa reittiä pitkin. Reititin voi hylätä varauspyynnön jos esimerkiksi asiakas on varaamassa suurempaa kapasiteettia, kuin on yhteydentarjoajan kanssa sopinut tai jos verkossa on ruuhkaa ja olemassa olevien yhteyksien laadun takaamiseksi varauspyyntöön ei voida suostua. RSVP on hidas, koska se joutuu varmistamaan yhteyden etukäteen, ennen kuin yhtäkään pakettia voidaan siirtää. Samalla RSVP kuitenkin on varma, koska se pystyy takaamaan täydellä varmuudella muodostetun yhteyden laadun. RSVP sopiikin tämän takia paremmin suljettuihin verkkoympäristöihin, joissa RSVPprotokolla voidaan asentaa kaikkiin verkon laitteisiin ja päätelaitteisiin, sekä verkkoihin joissa yhteyden laadun takaaminen on erityisen tärkeää (koneiden etäohjaus, etälääketiede, yms.). Tavallisen, muutaman yksityishenkilön välisen, VoIP-yhteyden laadun takaamiseksi RSVP on usein liian raskas. Seuraavassa kohdassa käsitellään kevyempää, eriytetyt palvelut mahdollistavaa protokollaa. 2.6.2 Differentiated Services (DiffServ) Toinen yleinen tapa paremman palvelunlaadun saamiseksi on merkitä toiset paketit tärkeämmiksi kuin toiset. Tämä periaate oli käytössä jo alkuperäisessä IPv4-määrittelyssä [3] palvelunlaatukentän avulla, mutta sitä ei hyödynnetty yleisessä käytössä väärinkäytösten helppouden takia. Eriytettyjen palvelujen