Session Initiation Protocol: istunnon aloitusprotokolla

hyväksymispäivä arvosana arvostelija Session Initiation Protocol: istunnon aloitusprotokolla Heikki Kontio Helsinki 7.5.2004 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty/Section Laitos Institution Department Matemaattis-luonnontieteellinen Tietojenkäsittelytieteen laitos Tekijä Författare Author Heikki Kontio Työn nimi Arbetets titel Title Session Initiation Protocol: istunnon aloitusprotokolla Oppiaine Läroämne Subject Tieteellisen kirjoittamisen kurssi Työn laji Arbetets art Level Tutkielma Tiivistelmä Referat Abstract Aika Datum Month and year 7.5.2004 Sivumäärä Sidoantal Number of pages 26 Tämä tutkielma on osa Helsingin Yliopiston kevään 2004 Tieteellisen kirjoittamisen kurssia. Istunnon aloitusprotokolla SIP (Session Initiation Protocol) IETF:n (Internet Engineering Task Force) standardisoima merkinantoprotokolla (signaling protocol) istuntojen aloittamiseen, muokkaamiseen ja lopettamiseen eri osapuolten välillä. Protokolla on alun perin kehitetty Voice Over IP (VoIP)-puhelinten väliseksi yhteydenottotavaksi, mutta sitä on viime vuosina kehitetty myös matkapuhelinten käyttöön. Protokollaa on laajennettu myös läsnäolo- (Presence) ja pikaviestintäpalveluihin (Instant Messaging). Läsnäolopalvelussa käyttäjän päätelaitteet päivittävät läsnäolotietoa protokollan laajennusta tukeville palvelimille, josta toiset päätelaitteet voivat sitä käydä kysymässä. Pikaviestinnässä viestit upotetaan osaksi tavallisia SIPviestejä. Toteutus on yksinkertainen, mutta jättää huomioimatta mm. ruuhkanhallinnan ja reitityksen, joka on pikaviestinnässä tärkeää. Avainsanat Nyckelord Keywords SIP, Presence, pikaviestintä Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information

Sisällysluettelo 1JOHDANTO... 1 2KOMPONENTIT JA ARKKITEHTUURIN KÄYTTÄMÄT PROTOKOLLAT... 2 2.1KOMPONENTIT...2 2.1.1Käyttäjäagentti (user agent)... 3 2.1.2Rekisterinpitäjä (registrar)... 3 2.1.3Välipalvelin (proxy server)...4 2.1.4Edelleenohjauspalvelin (redirect server)... 4 2.2SIP-ARKKITEHTUURIN KÄYTTÄMÄT PROTOKOLLAT...5 2.2.1SIP-protokolla... 5 2.2.2UDP-protokolla...10 2.2.3SDP-protokolla...10 3ESIMERKKI PROTOKOLLAN KÄYTÖSTÄ...11 4PIKAVIESTINTÄ JA LÄSNÄOLOPALVELU... 12 4.1PIKAVIESTINNÄSTÄ JA LÄSNÄOLOPALVELUSTA... 12 4.2SIMPLE...12 4.3LÄSNÄOLOPALVELU... 13 4.3.1Läsnäolo-informaation tietokentät...14 4.3.2Miten läsnäolopalvelu toimii?... 16 4.3.3Esimerkki SIMPLE-laajennuksen mukaisesta läsnäolopalveluviestistä...17 4.4PIKAVIESTINTÄ... 18 4.4.1Miten pikaviestintä toimii SIMPLE:llä?...18 4.4.2Esimerkki SIMPLE-laajennuksen mukaisesta pikaviestistä...19 4.4.3SIP/SIMPLE:n soveltuvuus pikaviestintään... 20 5YHTEENVETO... 21 6LÄHTEET... 22

1 1 Johdanto Tämä tutkielma on osa Helsingin yliopiston Tieteellisen kirjoittamisen kurssia keväällä 2004. Aiheena on istunnon aloitusprotokolla SIP (Session Initiation Protocol). Aluksi perehdytään protokollan taustaan, tämän jälkeen kuvataan itse protokolla ja sen käyttö esimerkkien avulla. Lisäksi perehdytään SIP:n käyttöön Presence-läsnäolopalvelussa ja pikaviestinnässä. Huomattava osa aineistosta perustuu muutamaan perusteokseen ja RFC-dokumenttiin (Request For Comments), sillä tieteellisiä julkaisuja SIP:stä on vielä varsin niukasti. Vaikka kaikkiin lähteisiin ei tutkielmassa olekaan viitattu, on niitä käytetty tutkielmaa kirjoittaessa. Niitä voi käyttää haluttaessa tutustua aihealueeseen syvemmin. Viestinnän määrä tietokoneohjelmistojen välillä on jatkuvassa kasvussa. Suuri haaste on mahdollistaa saumaton viestintäyhteyden jatkuminen myös silloin, kun joku viestinnän osapuoli vaihtaa paikkaa tai käyttämäänsä laitetta. Kysyntää lisenssivapaille ratkaisuille riittää tulevaisuudessa. Tällaisen ratkaisun riippumattomuus teknisestä alustasta on tärkeää, jotta viestiyhteyden (kutsutaan myöhemmin istunnoksi) jatkuvuuden hallinta pystytään pitämään mahdollisimman yksinkertaisena. Eräs ratkaisuvaihtoehto on istunnon aloitusprotokolla SIP (Session Initiation Protocol). Se on IETF:n (Internet Engineering Task Force) standardisoima merkinantoprotokolla (signaling protocol) istuntojen aloittamiseen, muokkaamiseen ja lopettamiseen eri osapuolten välillä [Ros02a]. Protokollaa käytetään IP-verkossa (Internet Protocol). Se kehitettiin IETF:n MMUSIC-työryhmässä (Multiparty Multimedia Session Control) ja sen pääkehittäjinä ovat Henning Schulzrinne ja Jonathan Rosenberg. Protokollan alkutaival juontaa aina vuodesta 1996 asti, jolloin kaksi vaihtoehtoista protokollaa yhdistettiin yhdeksi. Ensimmäinen ehdotus standardiksi tuotiin IETF:lle 2. helmikuuta 1999 ja se standardisoitiin 17. maaliskuuta 1999 (RFC 2543). Uusin standardisoitu versio on kesäkuulta 2002 (RFC 3261). Protokolla itse on osa IETF:n viime vuosina kehittämää multimedia-arkkitehtuuria, johon kuuluvat esimerkiksi RTP (Real-Time Transport Protocol), RTSP (Real-Time Streaming Protocol), MGCP (Media Gateway Control Protocol), SDP (Session Description Protocol), SAP (Session Announcement Protocol) ja TRIP (Telephony Routing over IP). Sille on myös luotu ja luodaan parhaillaan uusia laajennuksia erikoistuen johonkin tiettyyn osa-alueeseen, esimerkiksi SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions).

2 2 Komponentit ja arkkitehtuurin käyttämät protokollat 2.1 Komponentit Yleinen käyttötapaus SIP-protokollan käytöstä voidaan jakaa muutamaan vaiheeseen [Sta03]: - Käyttäjän sijainti: istunnon osapuoli tulee paikantaa ennen istunnon aloittamista ja se voi vaihtaa paikkaa kesken istunnon. - Käyttäjän saatavuus (availability): tässä vaiheessa otetaan selville, onko istunnon kutsuttu osapuoli halukas tai pystyvä istunnon aloittamiseen - Käyttäjän kykenevyys: tässä vaiheessa otetaan selville, mitä yhteisiä protokollia osapuolet tukevat ja päätetään käytetty protokolla. - Istunnon aloitus: istunto luodaan käyttäen sovittua protokollaa ja sen käyttö aloitetaan. - Istunnon hallinta: vaihe voi koostua istunnon siirtämistä esimerkiksi toiseen IPosoitteeseen, istunnon lopettamista, osapuolten lisäämisestä istuntoon, istuntokohtaisten palvelujen herättämisestä yms. Itse protokollan ympärillä oleva arkkitehtuuri koostuu neljästä eri komponentista: käyttäjäagentista (user agent), rekisterinpitäjästä (registrar), välipalvelimesta (proxy server) ja edelleenohjauspalvelimesta (redirect server) [Sch00]. Tavallisesti istunnon aloitusvaiheessa SIP-viestit voivat kulkea useamman komponentin kautta, mutta itse istunnon aikana komponentit voivat keskustella suoraan keskenään ilman välikomponentteja [Sch00, Sch01].

3 Kuva 1. SIP-arkkitehtuurin komponentit ja protokollat [Sta03]. 2.1.1 Käyttäjäagentti (user agent) Käyttäjäagentti ottaa yhteyttä toisiin (käyttäjä)agentteihin ja istunnot luodaan näiden välille. Se voi toimia siis sekä istunnon alku- että päätepisteenä. Esimerkiksi käyttäjäagentista käyvät VoIP-puhelimet (Voice over IP) ja pikaviestintäohjelmistot (Instant Messaging) matkapuhelimissa. 2.1.2 Rekisterinpitäjä (registrar) Rekisterinpitäjä on ohjelma, joka pitää kirjaa toimialueellaan (domain) sijaitsevista käyttäjistä. Esimerkiksi kaikki x.y@macrosoft.com -tunnukselliset käyttäjät rekisteröityvät macrosoft.com-toimialueen rekisterinpitäjään [Sch00].

4 2.1.3 Välipalvelin (proxy server) Välipalvelin on sovellustasolla toimiva reititin. Välipalvelimen pääasiallisena tehtävänä on välittää saamansa viestit komponentille, joka on lähempänä vastaanottajaa kuin välipalvelin. Välipalvelin voi tulkita saamansa viestit ja kirjoittaa jopa osia viestistä uudelleen tarpeen mukaan. Sillä voidaan myös toteuttaa rajoituksia (saako kutsuja x ottaa yhteyttä vastaanottaja y:hyn). 2.1.4 Edelleenohjauspalvelin (redirect server) Edelleenohjauspalvelinta käytetään istunnon aloitusvaiheessa, kun pitää saada selville kutsuttavan osapuolen osoite. Tällöin osoitteen tietävä palvelin palauttaa kutsujalle kutsuttavan URI:n (Uniform Resource Identifier), johon kutsuja ottaa seuraavaksi yhteyttä.

5 2.2 SIP-arkkitehtuurin käyttämät protokollat Istunnon aloitusprotokollan arkkitehtuuri käyttää oman protokollansa lisäksi muitakin protokollia. Tiedonsiirtokerroksena voidaan käyttää oikeastaan mitä tahansa soveltuvaa protokollaa, mutta UDP:tä (User Datagram Protocol) suositellaan käytettäväksi, sillä se välttyy TCP:n (Transmission Control Protocol) viiveiltä yhteyttä luotaessa ja purettaessa [Ros02a]. SDP-protokollaa (Session Description Protocol) käytetään, kun halutaan määrittää, minkälaisia datavirtoja osapuolet pystyvät ja haluavat vastaanottaa istunnon aikana. 2.2.1 SIP-protokolla Tämä protokolla on tekstipohjainen protokolla, jonka viestit muistuttavat hyvin paljon HTTP:tä (Hypertext Transfer Protocol). On olemassa kahdenlaisia SIP-viestejä: pyyntöjä (requests) ja vastauksia (responses). 2.2.1.1 Pyynnöt Protokolla tarjoaa seuraavat metodit: REGISTER, INVITE, ACK, CANCEL, BYE ja OPTIONS. INVITE-metodin rivit käsitellään tässä tarkasti, muista näytetään esimerkki. 1. INVITE Tällä pyynnöllä kutsutaan osapuoli mukaan sessioon. Esimerkki: INVITE sip:tvirtane@pliplop.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bkkjshdyff To: sip:tvirtane@pliplop.com From: sip:alice@wonderland.com Call-Id: 1234@a.wonderland.com Cseq: 1 INVITE Contact: sip:alice@a.wonderland.com

6 c=in IP4 128.59.19.38 m=audio 3456 RTP/AVP 0 Ensimmäinen rivi sisältää metodin nimen, kutsuttavan SIP-osoitteen (SIP URI) ja käytettävän SIP-protokollan versionumeron. Via-alkuinen rivi näyttää polun, jota pitkin pyyntö kulki kutsuttavalle. Vastaus kulkee tätä samaa tietä takaisinpäin. To-alkuinen rivi sisältää vastaanottajan näyttönimen (display name) ja From-rivi taas kutsujan vastaavan. Call-Id -alkuinen rivi sisältää maailmanlaajuisesti ainutlaatuisen (globally unique) tunnisteen tälle kutsulle, joka on luotu satunnaisen merkkijonon ja IP-osoitteen / DNSnimen (Domain Name Service) yhdistelmästä. CSeq-rivi sisältää istunnon aikana juoksevan numeron ja metodin nimen. Juoksevaa numeroa käytetään, jotta pystytään erottamaan pyynnön uudelleenlähetys täysin uudesta pyynnöstä. Contact-alkuinen rivi sisältää kutsujan suoran SIP-osoitteen. c- ja m-alkuiset rivit kuuluvat viestin runkoon ja ovat SDP-protokollaa, sitä käsitellään myöhemmin. 2. REGISTER Käyttäjäagentti rekisteröityy tällä pyynnöllä toimialueensa rekisterinpitäjä-komponentille. Esimerkki: REGISTER sip:@sip.pliplop.com SIP/2.0 From: Tapio Virtanen <sip:tvirtane@pliplop.com> To: "T. Virtanen" <sip:tvirtane@pliplop.com> CSeq: 19 REGISTER Expires: 1800 Call-ID: 39485832@tapsankone.pliplop.com Contact: sip:tvirtane@tapsankoti.pliplop.com Accept: application/sip-cgi, application/sdp, text/html Authorization: Basic am9lonbhc3n3b3jkafbx Content-Length: 0 Ensimmäisellä rivillä REGISTER kertoo metodin tarkoituksen, Accept-alkuinen rivi ilmaisee käyttäjäagentin tukemat sisältötyypit (content types) ja Authorization-rivillä kerrotaan todentamistavan tyyppi, joka tässä on HTTP:n perustodentamistapa. Content- Length rivi kertoo viestin rungon koon, joka tässä tapauksessa on 0 (tyhjä). Muiden rivien merkitys on selitetty INVITE-pyynnön kohdalla.

7 3. ACK Vahvistaa viestien vaihdon tapahtuneen luotettavasti. ACK-alkuinen rivi ilmaisee, että kyse on vahvistusviestistä. Muiden rivien merkitys on selitetty INVITE-pyynnön kohdalla. Esimerkki: ACK sip:tvirtane@pliplop.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bkkjshdyff To: Tapsa <sip:tvirtane@pliplop.com>;tag=99sa0xk From: Alice <sip:alice@wonderland.com>;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 ACK 4. CANCEL Lopettaa odottavassa tilassa olevan kutsun, muttei peruuta jo käsiteltyjen kutsujen tulosta. CANCEL-rivi ilmaisee komennon. Muiden rivien merkitys on selitetty INVITEpyynnön kohdalla. Esimerkki: CANCEL sip:tvirtane@pliplop.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hg4bkkjshdyff To: sip:tvirtane@pliplop.com From: sip:alice@wonderland.com Call-Id: 1234@a.wonderland.com Cseq: 1 CANCEL Contact: sip:alice@a.wonderland.com

8 5. BYE Lopettaa istunnon kahden osapuolen välillä. BYE-alkuinen rivi ilmaisee komennon, Route-alkuiset rivit ilmaisevat reitin, mitä pitkin BYE-komento kulkee. Reitin jokaisessa solmukohdassa viestistä poistetaan ko. solmukohdan osoite ja viesti välitetään seuraavalle. Lopputuloksena on vain yksi Route-rivi viimeiseen solmukohtaan päässeessä BYE-viestissä [Ros02a]. Esimerkki: BYE sip:caller@u1.example.com SIP/2.0 Route: <sip:p4.domain.com;lr> Route: <sip:p3.middle.com> Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr> 6. OPTIONS Pyytää kutsuttavalta tietoa tämän kykenevyydestä käyttää eri protokollia, laajennuksia, sisältötyyppejä yms. ilman, että luodaan pyyntö istunnon aloittamisesta. OPTIONS-rivi kertoo tarkoituksen ja Max-Forwards alkuinen ilmaisee, että välikomponenttien määrä reitillä saa olla maksimissaan 70. Muiden rivien merkitys on selitetty INVITE-pyynnön kohdalla. Esimerkki: OPTIONS sip:tvirtane@pliplop.com SIP/2.0 Via: SIP/2.0/UDP pc33.wonderland.com;branch=z9hg4bkhjhs8ass877 Max-Forwards: 70 To: <sip:tvirtane@pliplop.com> From: Alice <sip:alice@wonderland.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:alice@pc33.wonderland.com> Accept: application/sdp Content-Length: 0

9 2.2.1.2 Vastaukset Myös SIP-vastaukset muistuttavat huomattavassa määrin HTTP-protokollan viestejä; niiden numerointi on pitkälti identtinen. Kun käyttäjäagentti (tai muu SIP-vastauksiin kykenevä komponentti) vastaanottaa SIP-pyynnön, sen vastaus & statuskoodi kutsujalle riippuu pyynnön perusteella suoritetun tehtävän tuloksesta. Statuskoodit on jaettu seuraaviin kategorioihin [Sta03, Ros02a]: - Tilapäinen (1xx): pyyntö vastaanotettiin ja sitä käsitellään. - Menestys (2xx): pyyntö on suoritettu menestyksekkäästi. - Edelleenohjaus (3xx): Vastaukset antavat tietoa kutsuttavan uudesta sijainnista tai muista vaihtoehtoisista tavoista, jotta pyyntö voidaan suorittaa menestyksekkäästi. - Virhe pyynnössä (4xx): pyyntöä ei voitu suorittaa, koska se oli virheellinen (voi myös johtua kutsujan riittämättömistä oikeuksista kutsujalle). Pyyntöä pitää muuttaa, jotta se voidaan suorittaa menestyksekkäästi. - Palvelinvirhe (5xx): kun palvelimessa tapahtuu virhe eikä pyyntöä voida menestyksekkäästi suorittaa, palautetaan 5xx-kategorian virhe. - Globaalit virheet (6xx): tämä on uusi kategoria, jota ei ole HTTP 1.1:ssä. Tämän kategorian virhe palautetaan, kun pyyntöä ei voida suorittaa menestyksekkäästi mitenkään. Esimerkkinä 200 OK -statusviesti: SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com Via: SIP/2.0/UDP bigbox3.site3.atlanta.com Via: SIP/2.0/UDP 12.26.17.91:5060 To: Bob <sip:bob@biloxi.com;tag=a6c85cf From: Alice <sip:alice@atlanta.com;tag=1928301774 Call-ID: a84b4c76e66710@12.26.17.91 CSeq: 314159 INVITE Contact: <sip:bob@biloxi.com> Content-Type: application/sdp Content-Length: 131 Ensimmäisellä rivillä kerrotaan käytettävän protokollan versio ja statuskoodi. Muiden rivien merkitys on selvitetty osiossa 3.2.1.1 INVITE-pyynnön kohdalla.

10 2.2.2 UDP-protokolla User Datagram Protocol UDP on suositeltu kuljetusprotokolla SIP-viesteille, koska - kuten aikaisemmin jo mainittiin - se ei kärsi TCP-protokollan aiheuttamasta viiveestä istuntoa aloittaessa ja purettaessa. Protokolla on määritelty RFC 768:ssa (elokuussa 1980), sen tarkoituksena on luoda kuljetuskerros mahdollisimman yksinkertaisella tekniikalla. UDP-paketit kulkevat IP-verkossa samalla tavalla kuin TCP-paketitkin, mutta niiden perillemenosta ei ole takeita. Esimerkki UDP-paketista [Pos80]: 2.2.3 SDP-protokolla Istunnon kuvausprotokolla SDP on määritelty RFC 2327:ssä [Han98]. Sitä käytetään, kun halutaan määrittää, minkälaisia datavirtoja SIP-istunnon osapuolet pystyvät ja haluavat vastaanottaa istunnon aikana. Protokollaa käytetään yksinkertaisessa tekstimuodossa. Viestit kulkevat SIP-viestien rungossa (body). Luvussa 3.2.1.1 esitelty INVITE-pyyntö sisälsi viimeisenä kahtena rivinä SDP-viestin, joka koostui mediamerkinnöistä (media entry). Jokainen merkintä sisältää ko. mediatyypin (audio, video yms.) IP-osoitteet ja portit, tuetut datatyypit, lähetyksen alku- ja loppuajat ja tietoa itse viestin lähettäjästä.

11 3 Esimerkki protokollan käytöstä Kuva 2. Yhteydenotto ja istunnon aloitus kahden VoIP-puhelimen välillä [Sta03]. Kuvassa 2 näkyy yhteydenotto Alicen ja Bobin välillä. Ensin Alicen puhelin eli käyttäjäagentti lähettää INVITE-pyynnön sille konfiguroidulle välipalvelimelle (1). Palvelin hyväksyy pyynnön (2). Tämän jälkeen palvelin pyytää DNS-palvelimelta Bobib välipalvelimen (biloxi.com) IP-osoitetta (3), joka tulee vastauksessa takaisin (4). Nyt Alicen välipalvelin lähettää INVITE-viestin suoraan Bobin välipalvelimelle (5), joka vastaanottaa ja hyväksyy viestin (6). Seuraavaksi Bobin välipalvelin ottaa Bobin sijainnin ja statuksen selville (7,8). Vihdoin voi Bobin välipalvelin lähettää INVITE-viestin Bobin käyttäjäagentille (9). Ilmoitus puhelimen soimisesta välittyy takaisin Alicelle (10-12). Kun Bob vastaa puhelimeen, siitä tulee OK-ilmoitus Alicelle (13-15). Tämän jälkeen Alicen käyttäjäagentti vahvistaa Bobin käyttäjäagentin OK-ilmoituksen (16). Nyt istunto on valmis ja sen data kuljetetaan RTP-protokollalla, jota kannattaa käyttää multimedian siirtämiseen istunnon osapuolten välillä [Sch01, Sch96a, Sch96b].

12 4 Pikaviestintä ja läsnäolopalvelu 4.1 Pikaviestinnästä ja läsnäolopalvelusta Mitä on pikaviestintä? Pikaviestintä tarkoittaa käyttäjien välistä viestinvälitystä lähes reaaliajassa [Ros02d]. Yleensä yksittäiset viestit ovat lyhyehköjä, ja niitä vaihdetaan niin nopeassa tahdissa, että kyseessä on tekstimuotoinen keskustelu. Esimerkiksi pikaviestinohjelmista käyvät IRC, MSN Messenger ja Yahoo! Messenger. Pikaviestintä on kasvanut räjähdysmäisesti viime vuosien aikana, kun etenkin nopeat internet-yhteydet (yli 256 kbit/s) ovat yleistyneet. Eri pikaviestintäohjelmat käyttävät kuitenkin eri protokollia viestinvälityksessä, joten käytännössä käyttäjillä on kussakin ohjelmassa omat tunnuksensa (ja usea ohjelma kerralla näytöllä). On tarvetta yhdelle protokollalle, jonka avulla kaikki pikaviestintäohjelmat voisivat viestiä toistensa kanssa riippumatta siitä, missä päätelaitteessa ne sijaitsevat. Olennaisena osana pikaviestintää on myös läsnäolo- eli Presence-palvelu. Palvelun avulla pikaviestintäohjelmien käyttäjät voivat nähdä, ovatko toiset käyttäjät saavutettavissa ja hallita sitä, miten muut käyttäjät näkevät oman tilanteen. extensible Messaging and Presence Protocol XMPP ja SIMPLE (SIP for Instant Messaging and Presence Leveraging Extensions) ovat toistensa kanssa kilpailevia XML-pohjaisia protokollia, jotka on suunniteltu pikaviestintää ja Presence-palvelua varten. Seuraavassa käsitellään SIMPLE:ä. 4.2 SIMPLE SIP for Instant Messaging and Presence Leveraging Extensions eli SIMPLE on yritys toteuttaa läsnäolo- ja pikaviestintäpalvelut SIP-protokollan laajennuksena [Hil03]. Laajennusta on kehittänyt mm. SIP-protokollan kehittäjänä toiminut Jonathan Rosenberg. Laajennus on IETF:n kehityksen alla ja sen ovat ottaneet omakseen mm. IBM ja Microsoft.

13 4.3 Läsnäolopalvelu Mitä läsnäolo- eli Presence-palvelu oikeastaan tarkoittaa? Se on (epäsuorasti) kuvattu RFC 2778:ssa konseptiksi, joka mahdollistaa käyttäjän kommunikointistatuksen (s. o. kykenevyyden / halukkuuden) tiedottamisen ja tiedotusten tilaamisen ("subscription to and notification of changes in the communications state of a user") [Ros02c]. Läsnäolopalvelu on jo ollut vuosia käytössä tietokonepuolella erilaisissa pikaviestintäohjelmissa. Viimeisen parin-kolmen vuoden aikana se on yrittänyt löytää tietään myös matkapuhelimiin. Tätä tekniikkaa ovat olleet työstämässä vuodesta 2001 alkaen isot matkapuhelinvalmistajat Nokia, Motorola ja Sony Ericsson (aiemmin Ericsson). Ne muodostivat Wireless Village -yhteisön "uusien ja innovatiivisten Presence- ja pikaviestintäsovellusten ympärille" [Nok03a]. Wireless Village -yhteisö yhdistettiin Open Mobile Alliance -järjestöön (OMA) lokakuun alussa 2002. Nykyään kehitystyö tapahtuu OMA Instant Messaging and Presence Service Working Group (OMA IMPS WG) -yhteisön alaisuudessa. Yhteisö määrittelee spesifikaatiot mobiilipuolen Presence- ja pikaviestintätoiminnallisuuksille, kuten myös prosesseja ja työkaluja toiminnan varmistamiseksi eri päätelaitteiden ja ohjelmistojen välillä [Nok03a]. Läsnäolopalvelu voidaan käsittää dynaamisena profiilina, joka sisältää tietoa käyttäjän läsnolosta (onko verkossa eli ei), tunnetilasta ("mood", esim. "ei just nyt huvita jutella"), suositelluista yhteydenottotavoista jne. Palvelu toteuttaa rajapinnat, joiden avulla toiset käyttäjät tai ohjelmistot voivat kysellä esimerkiksi miten ottaa yhteyttä käyttäjään. Osa saadusta tiedosta voi olla hyvinkin staattista, esimerkiksi puhelinnumero, sähköpostiosoite ja kotiosoite. Toiset tiedot taas voivat olla dynaamisia, esimerkiksi parhaillaan käynnissä olevat istunnot - datan haku, puhelimessa yms. -, asiayhteydet (kokoukset, lomalla...) ja tapa, jolla käyttäjä haluaa itseensä otettavan yhteyttä (soitto, tekstiviesti jne.)

14 4.3.1 Läsnäolo-informaation tietokentät Oheinen taulukko ilmaisee tietokentät, jotka muodostavat läsnäolotiedon perustan. Tietokentän nimi Kuvaus OnlineStatus onko käyttäjä kirjautunut Presencepalvelimelle Registration onko käyttäjä kirjautuneena matkapuhelinverkkoon ClientInfo tietoa käyttäjän ohjelmistosta: ohjelmiston nimi, versio yms. TimeZone käyttäjän paikallinen aikavyöhyke GeoLocation Käyttäjän sijainti Address Käyttäjän osoite FreeTextLocation Vapaamuotoinen kuvaus käyttäjän sijainnista PLMN Verkon, johon käyttäjä on kirjautunut, PLMN-koodi CommCap käyttäjän kommunikointikyvykkyys UserAvailability Käyttäjän saatavuus PreferredContacts suositellut yhteydenottotavat PreferredLanguage suositeltu käyttökieli StatusText käyttäjän määrittelemä statusteksti StatusMood käyttäjän tunnetila Alias käyttäjän salanimi (alias) StatusContent mediainformaatiota käyttäjän tilasta ContactInfo käyttäjän "käyntikortti", VCard Taulukko 1. Läsnäolotiedon muodostavat tietokentät. Riippuen tietokenttien sisältämästä tiedosta, ne voidaan jakaa kahteen kategoriaan: käyttölaitteen (client) ja käyttäjän (user) tilatietoihin.

15 4.3.1.1 Käyttölaitteen tilatiedot Käyttölaitteen tilatietojen tietokentät kuvaavat itse käyttäjän käyttämän laitteen ja ohjelmiston tilaa. Ne sisältävät tietoa laitteen tilasta verkossa ja muuta yksityiskohtaisempaa tietoa, esimerkiksi ohjelmiston versionumeron. Verkon tilatiedot sisältävät laitteen rekisteröitymis- ja läsnäolotiedot, kuten myös osoite- ja sijaintitiedot [Ros02b, Nok03a]. 4.3.1.2 Käyttäjän tilatiedot Käyttäjän tilatiedot sisältävät itse käyttäjästä saatavat tiedot, kuten käyttäjän saatavuuden, suositellut yhteydenottotavat ja käyttäjän yhteystiedot. Lisäksi löytyvät vapaasti kuvatut tiedot käyttäjän tilasta, tilatieto sisällöllä lisättynä (esimerkiksi kuva) ja käyttäjän tunnetila [Ros02b, Nok03a]. 4.3.1.3 Kontaktilistat Kontaktilista on käyttäjän tekemä lista muista käyttäjistä, joille hän voi jakaa oikeuksia liittyen omaan läsnäolotietoonsa ja sen päivitykseen. Esimerkiksi käyttäjä Alice (alice@pliplop.com) voi antaa oikeuden Bobille (bob@macrosoft.com) tilata Alicen läsnäolotilan päivitykset. Listaa päivitetään Presence-palvelimelle.

16 4.3.2 Miten läsnäolopalvelu toimii? Allaoleva kuva kuvaa prosessia, miten läsnäolotietoa päivitetään Presence-palvelimelle (palvelin, joka pitää sisällään käyttäjien läsnäolotietoja ja kontaktilistoja) ja sitä käyttäville asiakkaille. Kuva 4. Esimerkki käyttäjän läsnäolotiedon päivityksestä [Nok03b]. Vaihe 1: käyttäjä A julkaisee läsnäolotietonsa Presence-palvelimella. Vaihe 2: käyttäjät B ja C tilaavat palvelimelta käyttäjän A läsnäolon päivitystiedot. Vaihe 3: käyttäjä voi päivittää läsnäolotietonsa joko itse laitteellaan, tai verkkoelementit voivat tehdä sen Vaihe 4: Käyttäjät B ja C vastaanottavat päivityksen käyttäjän A tilassa, koska he ovat tilanneet A:n päivitystiedot. Vaihe 5: Toiset käyttäjät (esim. käyttäjä D) voivat myös noutaa käyttäjän A päivitystiedot manuaalisesti ilman tilausta. Vaihe 6: Kontaktilistoja käytetään valtuutukseen käyttäjä A voi kontaktilistalla valtuuttaa käyttäjän D tilaamaan A:n päivitystiedot.

17 Keskeisessä asemassa läsnäolopalvelussa ovat Presence-palvelimet, jotka sisältävät tuen SIP:n SIMPLE-laajennukselle ja mahdollisuuden säilyttää & jakaa eteenpäin kontaktilistoja. Presence-palvelimet sopivat hyvin SIP-edelleenohjaus- ja välipalvelinten laajennukseksi [Ros02c]. 4.3.3 Esimerkki SIMPLE-laajennuksen mukaisesta läsnäolopalveluviestistä Miltä SIMPLE-laajennuksen mukaiset SIP-viestit sitten näyttävät? Ne ovat periaatteessa pitkälti samanlaisia kuin tavalliset SIP-viestitkin, mutta sisältävät muutamia muutoksia. Läsnäolopalvelu tuo mukanaan kaksi uutta metodia: NOTIFY ja SUBSCRIBE. Ohessa esimerkki viestistä. NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com;branch=z9hg4bkna998sk From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com Event: presence Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 1 NOTIFY Content-Type: application/cpim-pidf+xml Content-Length:.. NOTIFY-komentoa käytetään, kun käyttäjän tilassa tapahtuu jokin muutos, josta joku toinen SIP-käyttäjä on tilannut päivitystietoa SUBSCRIBE-pyynnöllä [Roa02]. Komennon ensimmäinen rivi kertoo komennon tyypin, vastaanottajan osoitteen (tiedotuksia vastaanottavalla palvelimella) ja käytettävän protokollan versionumeron. Subscription-State -rivi kertoo käyttäjän tilan ja kestoajan. Muut rivit on selitetty SIPprotokollan viestien esittelyn yhteydessä luvussa 3.2.1.1, INVITE-pyynnössä.

18 4.4 Pikaviestintä 4.4.1 Miten pikaviestintä toimii SIMPLE:llä? Käyttämällä SIP-protokollan SIMPLE-laajennusta voidaan lähettää pikaviestejä istunnon eri osapuolten välillä. Allaoleva kuva selvittää viestien kulun, kun lähetetään yksi pikaviesti yhden välityspalvelimen kautta käyttältä 1 käyttäjälle 2. Kuva 5. Esimerkki SIMPLE-pikaviestin kulusta [Ros02d]. Vaiheessa F1 käyttäjä K1 lähettää viestin käyttäjälle K2. Viesti kulkee ensin välipalvelimelle P1. P1 tarkastaa tietokannastaan, mistä K2 löytyy, löytää sieltä K2:n SIPosoitteen ja lähettää viestin K2:lle (F2). K2 vastaanottaa viestin oikein ja lähettää 200 OK -vastauksen takaisin K1:lle P1:n kautta (F3). P1 vastaanottaa viestin ja välittää sen edelleen K1:lle (F4).

19 4.4.2 Esimerkki SIMPLE-laajennuksen mukaisesta pikaviestistä SIMPLE tuo pikaviestintään uuden metodin: MESSAGE. Ohessa esimerkki MESSAGE-metodin mukaisesta viestistä [Ros02d]. MESSAGE sip:user2@domain.com SIP/2.0 Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hg4bk776sgdkse Max-Forwards: 70 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 Watson, come here. Viestin ensimmäinen rivi ilmaisee, minkänimistä metodia käytetään. Lisäksi se sisältää vastaanottajan nimen ja käytettävän protokollan versionumeron. Via-alkuinen rivi kertoo, mistä DNS-osoitteesta viesti on lähetetty ja Max-Forwards-rivi antaa viestille hyppyjen maksimimäärän (maksimimäärä solmuja, jonka läpi viesti voi tuhoutumatta mennä). From-rivi kertoo lähettäjän osoitteen, To-rivi puolestaan vastaanottajan. Call-Id -alkuinen rivi sisältää maailmanlaajuisesti ainutlaatuisen (globally unique) tunnisteen tälle kutsulle, joka on luotu satunnaisen merkkijonon ja IP-osoitteen / DNSnimen (Domain Name Service) yhdistelmästä. CSeq-rivi sisältää istunnon aikana juoksevan numeron ja metodin nimen. Juoksevaa numeroa käytetään, jotta pystytään erottamaan pyynnön uudelleenlähetys täysin uudesta pyynnöstä. Content-Type -alkuinen rivi kertoo viestin muodon ja Content-Length viestin rungon pituuden.

20 4.4.3 SIP/SIMPLE:n soveltuvuus pikaviestintään Marshall T. Rose murskaa artikkelissaan On Helicopters and Submarines - ACM Queue Vol. 1, no. 8 November 2003 [Ros03] - SIP-protokollan käytön pikaviestinnässä täysin. Hänen mukaansa SIP-protokollan laajennusten kehitys ja käyttö on hyväksi silloin, kun ne ovat johdonmukaisia suhteessa protokollan alkuperäiseen käyttötarkoitukseen, ja sitä SIP:n käyttö pikaviestintään ei ole. Syy johtuu ns. sivutusmallin käytöstä SIP-pikaviestinnässä. Sivutusmalli toimii siten, että SIP-viestien runkoon sisällytetään itse pikaviestit [Ros03]. Viestienvälitys toimii samalla tavalla kuin SIP-yhteyksiä luodessa. Muutaman viestin tapauksessa tämä ei ole ongelma, mutta kun pikaviestintää käyttävien käyttäjien määrä verkossa kasvaa, alkaa tulla ongelmia. SIP:n kuljetuskerrokseksi suositellaan UDP-protokollaa, eikä SIP:ssä ole ruuhkanhallintaa. Kun viestejä kulkee verkossa, niitä käsitellään samalla prioriteetilla kuin esim. RealAudio-liikennettä eli takeita perillemenosta ei ole. Jopa SIP-pikaviestintään kehitetty RFC 3248 myöntää tämän [Ros02d]. Lisäksi joka kerta, kun SIP-pikaviestejä lähetetään, tapahtuu kättely. Käytännössä tämä johtaa siihen, että yhtä viestiä kohti lähetetään useampi paketti. Hidastaa ja muuttaa toimintaa entistäkin tehottomammaksi [Ros02d, Ros03]. Rose jatkaa vielä, että pikaviestinnässä tärkeää on reititys (hyvän polun löytäminen kahden päätepisteen välillä), ja siihen SIP ei ole suunniteltu. Se on suunniteltu yhteyden luomiseen kahden käyttäjän välille. Näinollen siihen on kehitetty paljon sellaista toiminnallisuutta, jota tarvitaan juuri yhteyden muodostamisessa, muttei taas niitä ominaisuuksia, joita pikaviestinnässä tarvitaan. Lopputuloksena SIP-protokollan käyttöönotto pikaviestintään aiheuttaa suuria kustannuksia, muttei silti saa aikaan hyvää lopputulosta.

21 5 Yhteenveto Tässä tutkielmassa on esitelty istunnon aloitusprotokollaa SIP ja sen laajennusta läsnäolo- ja pikaviestintäpalveluihin. Tietokonepohjaisen viestinnän ja mitä erilaisimpien viestintälaitteiden lisääntyessä tällä hetkellä melkoista vauhtia, on tarvetta hyvälle yhtenäiselle yhteydenottotavalle. Siinä SIP-protokolla toimii hyvin. Yksinkertainen ja yhtenäinen tapa aloittaa istunto erilaisten päätelaitteiden välillä vähentää kustannuksia ja nopeuttaa kehitystä. Protokollaan pätee kuitenkin hyvin vanha sananparsi "hyvä renki, mutta huono isäntä". Se ei ole tarkoitettu itse istunnon datan kuljettamiseen, sillä muut protokollat toimivat siinä suhteessa paremmin. Esimerkiksi pikaviestinnässä SIP-protokollan käyttö aiheuttaa vain lisää kustannuksia ja vähentää tehokkuutta. Protokollan ympärille tehdyt laajennukset ovat hyvästä silloin, kun ne tukevat alkuperäistä konseptia, so. istunnon luomista. Presence-palvelun lisäämisestä ei aiheudu haittaa; se täydentää yhteydenottoa. Protokollasta ovat monet ennustaneet tulevaksi teleoperaattoreiden monopolin murtaja tulevaisuudessa. Vallankumous ei kuitenkaan tule yhdessä yössä, ja varsinaisen muutoksen aiheuttaa IPv6:n (Internet Protocol version 6) tulo maailmanlaajuisesti käyttöön Internetissä. Tällöin IP-osoitteita tulee riittämään maapallon jokaiselle matkapuhelimelle. Silloin SIP tulee arvoonsa työkaluna, jolla matkapuhelimet voivat ottaa toisiinsa yhteyttä. Perinteisten palveluoperaattoreiden asema tullee kutistumaan, koska puhelu- yms. liikenne muuttuu pelkäksi bittivirraksi muiden joukossa. Varsinainen data tulee kuitenkin aina kuljettaa jotakin rajapintaa (ilma-, maa- jne.) pitkin, ja siitä verkkooperaattorit pystyvät aina ottamaan kohtuullisen taksan.

22 6 Lähteet Ahm04 Ashir Ahmed et. al., A guideline on message headers and URI in SIP/SIMPLE framework, IETF Internet Draft, February 2004. Work in progress. Fie99 R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee, Hypertext transfer protocol HTTP/1.1, Request for Comments 2616, Internet Engineering Task Force, June 1999 Han98 M. Handley and V. Jacobson, SDP: Session Description Protocol, Request for Comments 2327, Internet Engineering Task Force, Apr. 1998 Hil03 J. Hildebrand, Nine IM Accounts and Counting, ACM Queue Volume 1, Issue 8, November 2003 Kur03 Kurose, J. F., Ross, K.W. Computer Networking - A Top-Down Approach Featuring the Internet, toinen painos, Addison Wesley, 2003 Nok03a Forum Nokia, Presence Application Development Guide, April 2003 Nok03b Forum Nokia, Presence Server 1.1, Service Developer s Guide, Reference Document, October 2003 Pos80 J. Postel, "User Datagram Protocol", Request For Comment 768, Internet Engineering Task Force, August 1980 Roa02 A.B. Roach, "Session Initiation Protocol (SIP)-Specific Event Notification", Request for Comments 3265, Internet Engineering Task Force, June 2002 Ros00b J. Rosenberg et al., SIP extensions for instant messaging, Internet Draft, Internet Engineering Task Force, June 2000. Work in progress. Ros02a J. Rosenberg, H. Schulzrinne et al., "SIP: Session Initiation Protocol", Request for Comments 3261, Internet Engineering Task Force, June 2002

23 Ros02b J. Rosenberg et al., "A Model for Presence and Instant Messaging", Request for Comments 2778, Internet Engineering Task Force, February 2002 Ros02c J. Rosenberg et al., SIP extensions for presence, Internet Draft, Internet Engineering Task Force, September 2002. Work in progress. Ros02d J. Rosenberg et al., "Session Initiation Protocol (SIP) for Instant Messaging", Request for Comments 3428, Internet Engineering Task Force, December 2002 Ros03 Marshall T. Rose, "On Helicopters and Submarines", ACM Queue vol. 1, no. 8 - November 2003 Sch00 H. Schulzrinne & J. Rosenberg, "The Session Initiation Protocol: Internet- Centric Signaling," IEEE Communications Magazine, Oct. 2000 Sch01 H. Schulzrinne & E. Wedlund, "Application-Layer Mobility Using SIP," Mobile Computing and Communications Review, Volume 4, Number 3, March 2001 Sch96a H. Schulzrinne, RTP profile for audio and video conferences with minimal control, Request for Comments 1890, Internet Engineering Task Force, Jan. 1996 Sch96b H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, RTP: a transport protocol for real-time applications, Request for Comments 1889, Internet Engineering Task Force, Jan. 1996 Sta03 William Stallings, "The Session Initiation Protocol", Cisco Systems, The Internet Protocol Journal, March 2003