NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK MASTEROPPGAVE

Transkript

1 NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK MASTEROPPGAVE Kandidatens navn: Fag: Oppgavens tittel (norsk): Oppgavens tittel (engelsk): Lars Kristian Hallingstad Telematikk Multimedia og multimodalitet for CallCenter Multimedia and multimodality in CallCenter Oppgavetekst: Tradisjonelt har CallCenter- og andre interaktive telefoniapplikasjoner hatt et enkelt brukergrensesnitt, med talemeldinger den ene veien og DTMF den andre veien. Dataapplikasjoner har ofte et rikere brukergrensesnitt med tekst, ikoner, farger osv, men har tradisjonelt hatt problemer med å bruke tale interaktivt. I denne oppgaven skal studenten ha fokus på multimodale- og multimedia grensesnitt og se på hvilke muligheter som åpner seg med forskjellige terminaler og aksessteknologier. Studenten skal sette seg inn i SIP protokollen og JAIN SIP grensesnittet samt se på hvordan disse kan benyttes i en slik sammenheng. Andre aktuelle teknologier som skal vurderes er SMIL og Parlay. Studenten skal vurdere bruk av disse sammen med SIP og se på hvordan teknologiene kan integreres i en telefoniapplikasjon. Studenten skal spesifisere, designe og implementere deler av en CallCenter løsning som benytter SIP protokollen. Oppgaven gitt: 22. januar 2004 Besvarelsen leveres innen: 17. juni 2004 Besvarelsen levert: Utført ved: Institutt for telematikk Veileder: Arild Herstad, Telenor FoU Trondheim, 3. mars 2004 Lill Kristiansen Faglærer

2

3 Sammendrag Hovedmålet med denne oppgaven var å studere hvilke muligheter man får ved å ta i bruk multimedia og multimodalitet i en CallCenter-løsning. Det har vært fokus på hvordan dette kan gjøres ved bruk av forskjellige terminaler og aksessteknologier Faste, trådløse og mobile aksessteknologier er studert. Flere av disse teknologiene er nå eller vil i nærmeste fremtid være i stand til å overføre avanserte multimediesesjoner. Oppgaven har tatt for seg forskjellige typer terminaler, men skillene mellom typene er i ferd med å bli mindre. Avanserte mobile terminaler kan benytte flere forskjellige aksessteknologier og noen er allerede i stand til å håndtere sanntidsmultimedia og flere modaliteter. SIP er en protokoll for å håndtere sesjoner over IP-nett. I denne oppgaven har det vært fokus på hvordan protokollen egner seg for å kontrollere multimediesesjoner og da spesielt i forbindelse med CallCenter-tjenester. JAIN SIP grensenittet er utviklet for å tilby et standard Java-grensesnitt til SIP. Dette grensesnittet krever at utvikleren har relativ god kjennskap til protokollen, og vil da gi god kontroll over protokollen. Parlay-grensesnittet og SMIL-standarden er også studert. Det er spesielt sett på hvordan disse teknologiene kan brukes ved multimedia og multimodalitet i en CallCenter-løsning og i kombinasjon med SIP. En CallCenter-løsning som viser eksempler på multimedia og multimodalitet er spesifisert, designet og implementert ved bruk av SIP-protokollen og JAIN SIP grensesnittet. Denne løsningen viser at det er relativt enkelt å utvikle teletjenester som tar i bruk multimedia innhold og sesjoner ved å benytte disse teknologiene. i

4

5 Forord Denne masteroppgaven ble utført ved Norges Teknisk Naturvitenskaplige Universitet (NTNU), institutt for Telematikk, i perioden januar til juni Masteroppgaven er en del av Program for Advanced Telecommunication Services (PATS), som er et forskningssamarbeid mellom NTNU, Sintef, Telenor og Ericsson. Hensikten med PATS er å etablere plattformer, rammeverk og metoder som understøtter rask og sikker utvikling av avanserte hybride tjenester. Jeg vil gjerne takke professor Lill Kristiansen ved NTNU og min veileder Arild Herstad fra Telenor FoU for deres råd, hjelp og inspirasjon i forbindelse med denne oppgaven. Trondheim, juni 2004 Lars Kr. Hallingstad ii

6 Innholdsfortegnelse Sammendrag... i Forord... ii Innholdsfortegnelse...iii Forkortelsesliste... vi Figurliste...viii Tabelliste... ix 1. Innledning Bakgrunn Multimedia og multimodalitet CallCenter Tradisjonelt CallCenter Muligheter Session Initiation Protocol (SIP) Adresser Metoder og respons Opprinnelige metoder Vanlige utvidelsesmetoder (extensions) Respons Headere SIP-servere Registrar-server Proxy-server Redirect-server Presence-server SIP-endepunkt Brukerklienter Gatewayer Session Description Protocol (SDP) Instant Messaging (IM) Mobilitet Sikkerhet Brannmurer og Network Address Translation (NAT) Tjenestekvalitet (QoS) JAIN SIP Parlay Parlay Open Service Access Parlay X Web Services Parlay Multi-Media Call Control Parlay og CallCentre Synchronized Multimedia Integration Language (SMIL) Aksessteknologier og terminaler Aksessteknologier Public Switsjed Telephone Network (PSTN) iii

7 6.1.2 Global System for Mobile Communication (GSM) General Packet Radio System (GPRS) Enhanced Data for Global Evolution (EDGE) Universal Mobile Telecommunication System (UMTS) Bredbånd Wireless LAN (WLAN) LAN Terminaler PSTN-terminal Mobiltelefon Håndholdt datamaskin PC SIP-telefon Terminalmuligheter Sammenligning og integrasjon Sammenligning Integrasjon Andre standarder for integrasjon av IP og PSTN PSTN and INTerworking (PINT) Servers in the PSTN Initiating Requests to InTernet Servers (SPIRITS) CallCenter-løsning Spesifikasjon Supporttjeneste CallCenter-server Agentklient Kundeklient Design SIP-meldingsdiagrammer JAIN SIP Applikasjoner Kontrollenhet Medieserver Agentklient Kundeklient Utvidelser og alternative løsninger Agent transfer SIP kontroller Statistikk og presence til kunder Medietolkning Kundeklient Tastelyder Diskusjon og utfordringer Konklusjon Referanser Vedlegg 1 Installasjonsbeskrivelse Kontrollenhet Medieserver iv

8 12.3 Agentklient Vedlegg 2 Kontrollenhet Strukturdiagrammer System CallCenter Package env Package ejb Actor CallCenter Actor CallerAgent Actor CallCenterGroup Meldingsdiagrammer StartCallCenter Login Logoff Call CallAgent CallAgentSetup CallExp ImsExp RemoveCallerAgent Tilstandsdiagrammer Vedlegg 3 SIP-meldinger v

9 Forkortelsesliste 3GPP IN AAA AAL ADSL API ATM CAS CC CSCF CSD DSL DTMF EDGE ETSI GERAN GGSN GPRS HSCSD HSDPA HTML IDL IM IMS IP IVR ISUP JAIN JCP JMS MIME MMS NIST OMG OSA PINT POTS PSTN RTP SCF SCS SDP SGSN 3rd Generation Partnership Project Intelligent Network Authorization, Authentication, and Accounting ATM Adaptation Layer Asymmetric Digital Subscriber Line Application Programming Interface Asynchronous Transfer Mode Channel Associated Signaling Call Control Call State Control Function Circuit Svitsjed Data Digital Subscriber Line Dual Tone Multi Frequency Enhanced Data for Global Evolution European Telecommunications Standards Institute GSM/EDGE Radio Access Network Gateway GPRS Service Node General Packet Radio System High Speed Circuit Switched Data High Speed Downlink Packet Access Hypertext Markup Language Interface Definition Language Instant Messaging IP Multimedia Subsystem Internet Protocol Interactive Voice Response ISDN User Part Integrated Network APIs for the Java platform Java Community Process Java Message Service Multipurpose Internet Mail Extensions Multimedia Message Service National Institute of Standards and Technology Object Management Group Open Service Architecture PSTN and Internet inter-networking Plain Old Telephone Service Public Switched Telephone Network Real-time Transport Protocol Service Capability Feature Service Capability Server Session Description Protocol Serving GPRS Service Node vi

10 SIP SIP-T SMIL SMS SMTP SOAP SPA URI URL UMTS UTRAN W3C WAP WS W-CDMA WSDL XML Session Initiation Protocol SIP Telephony Synchronized Multimedia Integration Language Short Message Service Simple Mail Transfer Protocol Simple Object Access Protocol Service Provider API Uniform Resource Identifier Uniform Resource Locator Universal Mobile Telecommunication System UMTS Terrestrial Radio Access Network World Wide Web Consortium Wireless Application Protocol Web Service Wideband Code Division Multiple Access Web Service Definition Language Extensible Markup Language vii

11 Figurliste Figur 3-1 Meldingsdiagram for en enkel SIP-sesjon Figur 3-2 Oversikt over internett protokoller som viser at SIP kan benytte både UDP og TCP [1] Figur 3-3 RTP-mediestrømmen vil ikke nødvendigvis gå samme vei som SIPsignaleringen Figur 3-4 Eksempel på bruk av REFER-metoden Figur 3-5 Brukeren registreres i en Registrar-server Figur 3-6 Oppsett og terminering av SIP-sesjon med Proxy-server Figur 3-7 Oppsett av sesjon ved bruk av en Redirection-server Figur 3-8 En bruker abonnerer på presenceinformasjon fra en annen bruker ved en Presence Agent server Figur 3-9 En bruker abonnerer på presenceinformasjon fra en annen bruker ved en Presence Proxy server Figur 3-10 Oppsett av en SIP-sesjon med autentisering for både en Proxy server og en annen klient Figur 3-11 JAIN SIP objekt arkitektur [6] Figur 3-12 Transaksjonskontroll i JAIN SIP [6] Figur 4-1 Oversikt over oppbygningen av Parlay [24] Figur 4-2 Parlay X Web Service oversikt [27] Figur 5-1 Eksempel på SMIL-dokument [31] Figur 6-1 Oppsett av sesjon ved IMS, med vist rekkefølge for sending av forespørsel. [51] Figur 6-2 Mobiltelefonene SonyEricsson S700 med GSM og GPRS støtte, og Nokia 6630 som i tillegg har støtte for EDGE og UMTS Figur 6-3 Pocket PC 2003 enheten HP Ipaq 4150 og den Palm OS baserte Sony CLIE PEG-UX Figur 6-4 Eksempel på SIP-telefon fra Pingtel [66] Figur 7-1 Oversikt over integrasjon av PSTN og IP-nett med signalering, media og gateway [2] Figur 7-2 Meldingsdiagram for PSTN (ISUP) til SIP-gateway [2] Figur 7-3 Modell over PINT [2] Figur 8-1 Hovedenheter i en CallCenter-løsning Figur 8-2 Eksempel på menystruktur Figur 8-3 Overordnet struktur av CallCenter løsningen Figur 8-4 SIP-meldingsdiagram Call Figur 8-5 SIP-meldingsdiagram Transfer Figur 8-6 SIP Communicator applikasjons design [7] Figur 8-7 JAIN-SIP brukeragent klient [7] Figur 8-8 JAIN SIP brukeragent server [7] Figur 8-9 Flere mediekilder settes sammen til en prosessor Figur 8-10 Alternativ løsning med SIP kontroller viii

12 Tabelliste Tabell 3-1 Opprinnelige SIP-metoder Tabell 3-2 SIP-utvidelsesmetoder Tabell 3-3 Responskoder Tabell 3-4 SIP-headere Tabell 6-1 Hastigheter og maks rekkevidde for aktuelle DSL-teknologier [52][53] Tabell 7-1 Oversetting mellom SIP-, ISUP- og ISDN-meldinger og parametere [2] ix

13 1. Innledning CallCentre og andre tradisjonelle teletjenester har til nå hatt relativt enkle brukergrensesnitt med kun tale og lydsignaler som kommunikasjonsmedia. Teletjenester har i løpet av de siste par tiårene gjennomgått en stor utvikling i forbindelse med innføringen og utviklingen av Intelligente Nett (IN). Dette har åpnet telenettet for interaktive teletjenester som for eksempel CallCentre, automatiske opplysningstelefoner, personlige telefonsvarere og viderekobling i nettet. Dette vil antageligvis bare være begynnelsen på utviklingen av avanserte teletjenester. Det har frem til i dag hovedsaklig vært tre forskjellige typer nettverk tilgjengelig for forbrukerne; data-, tale- og tv nettverk. I hver av disse nettverkstypene har det igjen vært mange inkompatible systemer. Teleoperatørene har tradisjonelt benyttet utstyr basert på linjesvitsjing (både i ryggradnettet og i aksessnettene) for å håndtere telefoni, mens det har blitt utviklet egne datanett for å koble sammen datamaskiner og lokale datanettverk. Disse nettene er nå i ferd med å smelte sammen til et felles nett. De fleste teleoperatører har allerede skiftet eller har planer om å skifte ut ryggradnettene til pakkesvitsjede datanett. Nye aksessteknologier er i ferd med å overta for de tradisjonelle linjesvitsjede aksessteknologiene som POTS og ISDN. Dette gjelder både trådløse, mobile og faste nett som for eksempel GPRS, UMTS, WLAN og ADSL. Disse nye datanettene gir høyere hastigheter som åpner for nye tjenester. Sammensmeltingen av nettene gjør det mulig å tilby ett felles nett for alle tele- og datatjenester, og tjenester som opprinnelig var utviklet for en type nett kan nå bli mer tilgjengelig. Ett eksempel på dette er at det er mulig å få internettilgang fra mobiltelefoner og å ringe fra datamaskiner. Det kan virke som om IPprotokollen vil bli en standard nettverkslagsprotokoll for både tele- og datanett. Dette åpner for telefoni over IP-protokollen (IP-telefoni), men også mer avanserte teletjenester med video, tekstmeldinger, bilder og presenceinformasjon der det før kun har vært tale og lydsignaler. Kontrollen av telenettet er i dag sentralt styrt av teleoperatører med (store) svitsjer i nettet, og med relativt enkle terminaler eller telefonsentraler (PBX er) i endepunktene. Kapittel 1 - Innledning 1

14 Ved innføring av IP-telefoni vil mer av styringen (tilstandskontroll og funksjonalitet), i tråd med prinsippene i internetteknologien, bli flyttet fra sentrale enheter til endepunktene. Fremover kan disse endepunktene være mange forskjellige typer enheter som for eksempel avanserte telefoner og datamaskiner. Nye mobile terminaltyper med fargeskjermer, kameraer (både for foto og video), touchskjermer og kraftige prosessorer har kommet. Fremover vil det sannsynligvis komme flere og mer avanserte terminaler. Det er en tendens til at mobile terminaler blir mindre, noe som gjør input til tastaturet og output fra skjermen til en utfordring. Muligheten for å kombinere forskjellige typer input og output, multimodalitet, vil da kunne ha stor betydning for brukerens opplevelse av tjenesten. Dette kan for eksempel gjøres ved å ta i bruk stemmegjenkjenning og kameraer i tillegg til tastatur som input, samt ved å bruke talesyntese og video som output. Det blir også viktig å kombinere flere typer media og presentere disse på en god måte til brukeren, noe SMIL standarden prøver å gjøre. For å kunne sette opp og kontrollere samtaler og andre sesjoner i IP baserte nettverk er standarden Session Initiation Protocol (SIP) utviklet. SIP er en signaleringsprotokoll som har støtte for å kontrollere mange typer multimediesesjoner ved at den benytter Session Description Protocol (SDP) til å utveksle og forhandle parametere for en sesjon. Mediestrømmene vil ikke bli overført ved SIP, men vil benytte en protokoll som partene blir enige om, som for eksempel Real-Time Transport Protocol (RTP). SIP protokollen er basert på prinsipper fra HTML og SMTP, noe som gjør den relativt lett å sette seg inn i og forstå. Det vil nok ta lang tid før PSTN og andre linjesvitsjede aksessteknologier vil erstattes helt av nye IP-baserte teknologier, og det er derfor viktig at det lages systemer som gjør at disse virker sammen. Ved å benytte gatewayer mellom PSTN-nettet og internett blir det mulig å initiere samtaler mellom nettene, og ved hjelp av Parlay vil det bli enklere for en tredjepart å utvikle applikasjoner som kontrollerer linjesvitsjede nett. Kapittel 1 - Innledning 2

15 I kapittel 2 vil bakgrunnen for denne oppgaven beskrives, med en forklaring av begrepene "multimedia og multimodalitet og hvilke muligheter som finnes ved å bruke disse i et CallCenter. Deretter vil standardene SIP(kapittel 3), Parlay(kapittel 4) og SMIL (kapittel 5) studeres. Det vil legges vekt på SIP da dette er en viktig standard for å gjøre multimedia tilgjengelig i teletjenester og fordi det i denne oppgaven skal lages en løsning som benytter SIP. Kapittel 6 vil gjennomgå hvilke tjenester og muligheter som finnes, og hva som kan komme av aktuelle aksessteknologier og terminaler. I kapittel 7 vil SMIL, Parlay og SIP standardene sammenliknes, og det vil studeres hvordan disse kan integreres. Til slutt en CallCenter løsning som benytter SIP protokollen vil det spesifiseres og designes i kapittel 8. Løsningen vil bli implementert i Java ved JAIN SIP grensesnittet. Kapittel 9 vil ta for seg diskusjon og utfordringen fremover, før det tilslutt vil være en konklusjon i kapittel 10. Kapittel 1 - Innledning 3

16 2. Bakgrunn Dette kapittelet vil først beskrive multimedia og multimodalitet, deretter fortelle kort om hva et CallCenter er. Til slutt studeres hvilke muligheter som finnes ved å bruke multimedia og multimodalitet i et CallCenter. 2.1 Multimedia og multimodalitet Multimodalitet kan defineres som multikanalkommunikasjon mellom bruker og system. Det er vanlig å forveksle begrepene multimedia og multimodalitet. For å se hva begrepene betyr og hva som er forskjellen på dem, kan en først se på betydningen av de tre begrepene multi, media og modalitet i denne sammenhengen. Media brukes om forkjellige måter å presentere informasjon på, for eksempel auditivt som tale og musikk eller visuelt som bilder eller tekst. Modalitet er en tolkning eller oppfatning av disse mediene (ved både input og output). Multi betyr at det kan være en kombinasjon av flere medier eller modaliteter. Video med lyd (auditivt) og bilde (visuelt) vil være et eksempel på multimedia, mens sammensetningen av disse mediene til en video og oppfatningen av denne er multimodalitet. [3] [4] Mennesker kommuniserer multimodalt og benytter fem sanser eller modaliteter: hørsel, syn, følelse, smak og lukt. Ved å ta i bruk flere av disse modalitetene kan det lages bedre menneske maskin grensesnitt (MMI). Det er da tre modaliteter som er aktuelle: auditivt (lyd, tale o.s.v.), visuelt (tekst, grafikk, ikoner, video o.s.v.) og berøring (tastatur, mus/penn, håndskrift o.s.v.). Det kommer an på situasjonen hvilken eller hvilke modaliteter som egner seg best. Det optimale vil være å la brukeren velge modalitet avhengig av tid, sted og personlige preferanser. [3][5] Et system kan være multimodalt ved at brukerne får tilgang til tilnærmet samme informasjon med ulike medier og på ulike måter. For eksempel kan et alternativ være å ringe et CallCenter for å få informasjon om et produkt, mens et annet alternativ kan være å hente informasjon over internett i en webleser. Kapittel 2 - Bakgrunn 4

17 Det er et problem at mobile terminaler blir mindre samtidig som informasjonen som skal presenteres blir mer kompleks. Ved å benytte multimodalitet på en god måte kan dette problemet reduseres. Dersom systemet vet noe om brukerens tilstand som gjør at en modalitet skal brukes, kan det forbedre systemets brukergrensesnitt. For eksempel kan stemmegjenkjenning være aktuelt når brukeren bruker hendene til noe annet, eller ved å bruke tekst og bilder istedenfor lyd når brukeren er i en samtale. Sentrale begreper innen multimodalitet: [3] - Fusjon: Kombinere signaler fra flere modaliteter og tolker dem sammen, sekvensielt eller synkront. - Fisjon: Splitte informasjonen fra systemet til de ulike modaliteter. - Dialog: Måten systemet samarbeider med en bruker. En utfordring med multimodalitet er hvordan betydningen til ulike modaliteter skal representeres. D.v.s. hvordan modalitetene skal kombineres ved fusjon slik at hensikten til brukeren blir tolket rett. Det må dessuten bestemmes hva skal vises på skjermen og hva skal leses opp ved fisjon. Dialogen må utformes slik at brukervennlighet blir best mulig for ulike tjenester. [3] De mest aktuelle mediene i en CallCenter-løsning vil være lyd, tekst, bilder, ikoner og video. Innen hvert av disse mediene vil det også skilles på om det er sanntidskommunikasjon eller ikke. Det vil stilles høyere krav til sanntidsinformasjon, for det kreves lavere forsinkelse ved samtaler og videokonferanser enn ved nedlastning av tale og video. Berøring og bevegelse, som for eksempel mus/penn og håndskrift, kan også være en viktig modalitet i et CallCenter. Kapittel 2 - Bakgrunn 5

18 2.2 CallCenter Tradisjonelt CallCenter Et CallCenter kan enten være et utgående eller et inngående CallCenter. Et utgående CallCenter er et system hvor det (automatisk) blir satt opp samtaler ut til eksiterende eller potensielle kunder basert på ringelister. Dette er som oftest salgssentre. Et inngående CallCenter er et telefonsystem der kundene ringer inn til et felles nummer, og kan for eksempel være et salgssenter eller en supporttjeneste. I enkleste form blir kunden koblet direkte til en kundebetjener, i CallCenter-terminologi kalt agent. Agentene har som oftest mulighet for å sette kunden over til en annen agent. Men et CallCenter kan også benytte automatiserte tjenester som for eksempel en talemaskin (Interactive Voice Response, IVR). Denne vil lese opp forskjellige valgmuligheter for kunden, som kan taste inn et nummer for å gjøre et valg. På bakgrunn av valgene kunden gjør, vil han få lest opp riktig informasjon fra IVR en eller bli koblet til en agent for personlig betjening. IN-teknologien har gjort det mulig å plassere CallCentre i telenettet. En fordel med dette er at bedrifter kan leie plass hos en teleoperatør istedenfor å investere i eget utstyr. Dette kan være en mulighet for mindre bedrifter til å innføre automatiserte CallCentre. En annen fordel ved å plassere CallCentre i telenettet er at bedriftene slipper å betale ekstra dersom samtalen må settes over til en ny agent et annet sted, kalt trunkering. CallCenteret vil da ta ned forbindelsen til den første agenten og sette opp en ny forbindelse til den andre. Ved at tjenester i telenettet og i datanettverk sammenkobles kan for eksempel CallCenterapplikasjoner benytte tjenester som finnes på internett til å finne informasjon om innringeren og dermed bestemme hvilken agent kunden skal rutes til. Men mediet som benyttes er fortsatt kun tale og valgene fra kundene gjøres ved Dual Tone Multi Frequency (DTMF), som er den lyden som blir sendt når det trykkes et siffer, * eller # på telefonen. I den siste tiden har det også kommet løsninger hvor en kan styre et CallCenter med tale, for eksempel ved å si ja eller nei. Kapittel 2 - Bakgrunn 6

19 2.2.2 Muligheter Ved bruk av IP-baserte nettverk vil det bli lettere å utvikle nye tjenester i nettet, da en slipper å endre eksisterende IN-systemer. Der man før skilte ved å ha et CallCenter i nettet ved å benytte IN eller lokalt vil dette med et IP-basert CallCenter i praksis nesten bli det samme. Dette er fordi CallCenteret uansett befinner seg i et IP-nettverk. Forskjellen ligger i om en skal drifte CallCenteret selv eller om det skal settes bort til en teleoperatør. Tilknytning til PSTN-gatewayer vil også være viktig for et IP-basert CallCenter. En må ta stilling til om en skal sette opp en slik gateway selv eller benytte en som allerede eksisterer. Det er også viktig å ha tilstrekelig tjenestekvalitet (QoS) i det aktuelle IP-nettet slik at kunden blir fornøyd med tjenesten. De neste kapitlene viser nye muligheter som åpner det seg for CallCenter-tjenester ved å ta i bruk IP-nett, multimedia og multimodalitet Multimedia Frem til nå har det mest brukte mediet vært tale. Fremover vil det bli mulig å benytte flere typer medier i telefoniapplikasjoner som video, bilder og tekst. Dette kan for eksempel være videokonferanse mellom kunde og agent, eller kunden kan få tilsendt og vist bilder eller tekst i sin telefoniapplikasjon. Ved å benytte videokonferanse der kunden og kundebehandleren ser hverandre, kan det skapes et tettere bånd mellom partene som kommuniserer. I forhold til kun å snakke med kundebehandleren kan dette virke tryggere for kunden, og gjøre det mulig å flytte flere kunder fra personlig betjening i bedriftens lokaler til et CallCenter. Ved et support CallCenter kan kunden lettere forklare et problem ved å filme et defekt produkt slik at supportagenten lettere kan finne feilen. Agenten har også mulighet til å filme mens han løser det aktuelle problemet, slik at kunden kan se hvordan det skal gjøres. Dersom CallCenteret er et utgående senter som for eksempel et salgssenter, har de muligheten til å få vist frem produktet som selges i form av bilder eller video. Det finnes Kapittel 2 - Bakgrunn 7

20 flere muligheter med et inngående CallCenter, og i denne oppgaven vil jeg konsentrere meg om denne typen CallCenter. Flere av mulighetene kan imidlertid brukes ved begge CallCenter-typene Medieservere En interaktiv medieserver kan erstatte en IVR og vil med bakgrunn i valg kunden foretar seg automatisk sende ulike mediestrømmer til kunden. Dette kan i tillegg til lyd, som ved en IVR, også være video, bilder eller tekst. Mediene vil da bli streamet og vist frem for kunden. For eksempel kan et support CallCenter benytte video til å vise frem hvordan de mest aktuelle problemene kan løses. Kunden vil da kunne velge en løsning ved hjelp av en meny, men kan også snakke eller skrive inn problemet som CallCenteret deretter tolker for så å returnere riktig løsning Statistikk til kunder Det vil bli mulig å sende statistikk til kundene på andre måter enn ved talemeldinger. Et eksempel på dette kan være at kundene mottar tekstmeldinger med kølengde og forventet ventetid i kø som kan vises i kundens klient. Dette kan være aktuelt både under en sesjon mens kunden venter, men enda mer aktuelt ved at kunden kan ha mulighet til å sende en forespørsel før han setter opp sesjonen. Kunden kan da vente med å sette opp sesjonen dersom det er lang kø Informasjon om agentens tilgjengelighet Dersom kunden vil ha kontakt med en bestemt agent (eller eventuelt en gruppe av agenter) kan kunden sjekke agentens tilgjengelighet eller status før han prøver å sette opp sesjonen. Hvis agenten er ledig kan kunden sette opp sesjonen. Dette krever at agentene eller CallCenteret først må godkjenne at kundene kan sjekke informasjon om agentenes tilgjengelighet. Kapittel 2 - Bakgrunn 8

21 Det er en mulighet at kunden kan velge å bli ringt opp igjen dersom det er kø i de fleste CallCenter-applikasjoner. En annen mulighet kan være at kunden melder ifra om hvilken agent han ønsker å kontakte, for så å bli varslet når agenten blir ledig. Han vil da få valget om han vil sette opp sesjonen eller ikke Brukergrensesnitt Brukergrensesnittet på automatiserte telefonitjenester har til nå vært begrenset, med hovedsaklig talemeldinger en vei og DTMF den andre. I fremtiden vil brukergrensesnittet kun være begrenset av terminalens egenskaper, som for eksempel skjermstørrelse, prosesseringskraft og aksessteknologien som benyttes. Dette gjør det mulig å bruke mer brukervennlige grensesnitt, med grafiske menyer, videoer, taleinstrukser o.s.v. Det mest aktuelle vil være å tilby kundene en standard multimedia telefoniapplikasjon som en valgfri SIP klient, et web grensesnitt eller lignende. Dersom CallCenter operatørene ønsker et spesielt brukergrensesnitt for tjenesten, kan de tilpasse det akkurat slik de ønsker, ved at kundene får lastet ned et program tilpasset sin terminal Integrasjon mot andre systemer Integrasjon mot andre datasystemer vil bli enklere fordi CallCenter-applikasjonen vil befinne seg på ett IP-nett. Systemer som det vil være aktuelt å koble ett CallCenter mot kan være opplysningstjenester på internett for å finne ut hvem som ringer, CRM systemer for å få mer informasjon om kunden o.s.v Agent-ruting I tillegg til å hente inn informasjon fra andre systemer vil det bli mulig å få mer informasjon om for eksempel terminalkapabiliteter og aksessteknologi fra kunden. Med dette som bakgrunn kan det foretas bedre transfer til agenter, ved at agentene også vil ha ulike egenskaper både tekniske og personlige. Agentene kan også befinne seg i Kapittel 2 - Bakgrunn 9

22 forskjellige typer aksessnettverk og benytte ulike typer terminaler med forskjellige egenskaper. Dette kan være med på å bestemme hvor kundene skal rutes Medietolkning Når det blir mulig å overføre flere medier mellom kunden og CallCenteret vil det bli mulig å styre CallCenteret med flere modaliteter. Dette kan for eksempel være talegjenkjenning, teksttolkning og skrifttolkning. Tolkningen kan enten foregå i lokalt i terminalen eller sentralt i en server. Fordelene ved å tolke dette lokalt er at terminalen eller systemet lettere kan tilpasse seg brukeren, for eksempel ved å kjenne igjen brukerens håndskrift. Dersom terminalene er forholdsvis enkle vil det ofte være mest hensiktsmessig å tolke dette i en server i nettet. Et eksempel på dette kan være når tjenesten skal utføre talegjenkjenning ved bruk av PSTN-telefoner. Kapittel 2 - Bakgrunn 10

23 3. Session Initiation Protocol (SIP) SIP er en signaleringsprotokoll for å sette opp og kontrollere sesjoner i IP-nett. Dette kan være alle typer multimedia sesjoner, som IP-telefoni, videokonferanser eller tekstmeldinger samt kontekst informasjon som for eksempel brukerens tilstedeværelse (presence). Dette kapittelet er skrevet med bakgrunn i bøkene [1] og [2], diverse RFC er referert til i kapittelet og ut i fra egen erfaring med SIP (se kapittel 8 CallCenter-løsning). SIP er en tekstlig applikasjonsprotokoll som bygger på mange av de samme prinsippene som Hyper Text Transfer Protocol (HTTP) og Simple Mail Transport Protocol (SMTP). SIP benytter en klient/tjenerarkitektur med forespørsler og responser, og URL er slik som HTTP. Tilsvarende SMTP benytter den bl.a. headere som TO, FROM o.s.v. Fordi protokollen er tekstlig er den relativt lett å lese og å forstå. Figur 3-1 viser et meldingsdiagram for oppsett og terminering av en enkel SIP-sesjon. INVITE 180 RINGING 200 OK ACK Media Session BYE 200 OK Figur 3-1 Meldingsdiagram for en enkel SIP-sesjon Kapittel 3 - Session Initiation Protocol (SIP) 11

24 Internet Engineering Task Force (IETF) er ansvarlig for utviklingen av SIP. Denne utviklingen bygger på dokumenter, Internet-Drafts (I-D), som alle interesserte kan bidra til og som kan resultere i et standard dokument; Request for Comments (RFC). Dokumentene er åpne standarder som fritt kan lastes ned fra internett ( SIP 1.0 ble spesifisert som et I-D i 1997, SIP 2.0 I-D kom i 1998 og ble publisert som et RFC (2543) i I 1999 ble det også opprettet en egen arbeidsgruppe for SIP i IETF, som erstattet RFC 2543 med RFC 3261 i Protokollen bygger på prinsippene fra internetteknologier med størst mulig grad av enkelhet og minst mulig tilstand i nettverkselementene. Endepunktene vil være relativt avanserte terminaler med tilstandskontroll. SIP benytter IP som nettverksprotokoll og kan benytte enten TCP eller UDP som transportprotokoll (Figur 3-2). Fordi SIP støtter retransmisjon benytter den som oftest UDP, da UDP er designet for å være en rask best-effort protokoll. UDP-pakkene inneholder en sjekksum for å oppdage feil ved dataoverføring. Hvis denne sjekksummen ikke stemmer med forventet sjekksum blir pakken kastet. SIP vil sørge for at den blir sendt på nytt ved hjelp av timere. Bruk av TCP vil som regel føre til at det vil ta lengre til å sende hver melding da det først må settes opp en forbindelse ved three-way handshake mellom hver SIP-enhet (endepunkt eller server) som benyttes. Mellom SIPservere som ofte kommuniserer kan det imidlertid være hensiktsmessig å sette opp en TCP-forbindelse. Figur 3-2 Oversikt over internett protokoller som viser at SIP kan benytte både UDP og TCP [1] Kapittel 3 - Session Initiation Protocol (SIP) 12

25 SIP brukes kun til å sette opp og kontrollere sesjonene, mens det benyttes andre protokoller for å overføre mediestrømmene, som for eksempel RTP. Hvilke protokoller og parametere som skal brukes utveksles og forhandles frem ved hjelp av parametere i SIP-meldingene. Til dette benyttes Session Description Protocol (SDP). Når endepunktene er enige om hvilke medier som skal benyttes i sesjonen vil denne bli satt opp. Ved SIP er signalerings- og medieveien uavhengige. Det vil si at mediestrømmen ikke trenger å gå samme veien som SIP-meldingene, men finner sin egen vei mellom endepunktene, som vist i Figur 3-3. Tekstmeldinger kan sendes i SIP-meldingene direkte (ved MESSAGE eller NOTIFY). RTP Media SIP-klient SIP SIP SIP-klient SIP SIP-server SIP-server Figur 3-3 RTP-mediestrømmen vil ikke nødvendigvis gå samme vei som SIP-signaleringen Eksempel på SIP melding (Content (SDP) er fjernet og vises i eksempelet i kapittel 3.6): INVITE sip:imr@ SIP/2.0 Via: SIP/2.0/UDP :12394 Max-Forwards: 70 From: "Lars" <sip:lkh@iptel.org>;tag=1a1eae3b6c4f478f943d772e2bbb3c35;epid=f0aa1a6409 To: <sip:imr@ > Call-ID: 87da5236acf3462f884de27411a0efd5@ CSeq: 1 INVITE Contact: <sip: :12394> User-Agent: RTC/1.2 Content-Type: application/sdp Content-Length: 694 Kapittel 3 - Session Initiation Protocol (SIP) 13

26 3.1 Adresser Til adressering i SIP brukes URL er som ligner på e-post adresser med protokoll:bruker@server, og med prefikset sip: som for eksempel: sip:lkh@iptel.org. Det er også mulig å gi med parametere som for eksempel subject. 3.2 Metoder og respons SIP benytter en forespørsel/respons arkitektur kjent fra HTTP. I SIP-terminologi kalles forespørslene metoder. De første seks SIP-metodene ble definert i SIP-standarden RFC Flere metoder blir definert i egne RFC-er som utvidelser (extensions) til SIP Opprinnelige metoder Metode INVITE ACK BYE CANCEL REGISTER OPTIONS Beskrivelse Initierer media sesjoner mellom SIP-endepunkt. Inneholder informasjon om hvilken type sesjon som ønskes. INVITE med en eksiterende Call-ID, kalt Re-INVITE, kan brukes for å endre en sesjon. Bekrefter den endelige responsen til en INVITE (respons 2xx, 3xx, 4xx, 5xx og 6xx). Avslutter en sesjon. Kan sendes av alle deltagende parter i en sesjon. Terminerer INVITE meldinger under behandling. Kan sendes av både brukeragenter og Proxy-servere. Forteller en SIP-Registrar hvilken IP-adresse og URL brukeren kan kontaktes på. Brukes for å finne en server eller en brukeragent sine kapabiliteter og tilgjengelighet. Tabell 3-1 Opprinnelige SIP-metoder Kapittel 3 - Session Initiation Protocol (SIP) 14

27 3.2.2 Vanlige utvidelsesmetoder (extensions) SIP har støtte for utvidelse i form av nye metoder og headere. Disse må godkjennes av IETF og må utgis som egne RFC-er for å bli en offisiell utvidelse til SIP. Nye utvidelser kan imidlertid brukes uten å være godkjente av IETF eller implementert i SIP-servere. Dersom en server ikke støtter utvidelsen blir meldingen behandlet som en OPTIONS metode, og dersom det andre endepunktet ikke støtter metoden, vil den returnere: 420 Bad Extension. Tabell 3-2 viser oversikt over offisielle utvidelsesmetoder til SIP. Metode Beskrivelse INFO Sender signaleringsinformasjon under en sesjon, men kan ikke endre sesjonen. (F.eks. ved ISDN signalering i SIP.) [13] PRACK Bekrefter en pålitelig foreløpig respons til en INVITE (respons 1xx, for eksempel pålitelig 180 Ringing). [14] REFER Sender forespørsel til mottageren om å referere til en SIP adresse med en gitt metode. [15] SUBSCRIBE Abonnere på tjenester, som for eksempel informasjon eller presence. [16] UNSUBSCRIBE Avslutter abonnementet. [16] NOTIFY Sender informasjon eller presence til abonnenter. [16] MESSAGE Sender en tekstlig melding. Trenger ikke å være i en eksisterende sesjon. [17] Tabell 3-2 SIP-utvidelsesmetoder I denne oppgaven vil REFER-metoden studeres og brukes. Det kan refereres til en SIPmetode samt en SIP-adresse, hvor standard metode er INVITE. REFER-metoden gjør det mulig å foreta tredjepart sesjonskontroll ved å initiere metoder, som for eksempel call transfer. Brukeragenten som sender REFER kan bli varslet om utfallet av forespørselen. REFER benytter Refer-To og Referred-By headerne (forklart kapittel 3.3). Et eksempel på bruk av REFER-metoden er vist Figur 3-4. Kapittel 3 - Session Initiation Protocol (SIP) 15

28 Bruker A Bruker B Bruker C INVITE 100 TRYING 180 RINGING 200 OK ACK Media Session REFER Refer-To: C 200 OK INVITE BYE 200 OK 180 RINGING 200 OK ACK Media Session Figur 3-4 Eksempel på bruk av REFER-metoden Respons SIP benytter responskoder på samme måte og med samme inndeling som HTTP; det vil si 1xx for informasjon, 2xx for vellykket forespørsel, o.s.v. SIP har lagt til en del egne koder i forhold til HTTP slik at disse passer inn i det samme systemet. Kapittel 3 - Session Initiation Protocol (SIP) 16

29 Klasse 1xx 2xx 3xx 4xx 5xx 6xx Beskrivelse Informasjon. Viser status på forespørsel som er under behandling, men ikke fullført. Suksess. Forespørsel er fullført med suksess. Re-direksjon. Viser til alternative lokasjoner. Klientfeil. Viser til en feilmelding hos klienten. Serverfeil. Viser til en feilmelding hos serveren. Forespørselen kan gjentas til en annen lokasjon. Globalfeil. Forespørselen har feilet, og skal ikke gjentas. Tabell 3-3 Responskoder 3.3 Headere Headerne i SIP er basert på prinsippet som brukes i SMTP, med formen: Header : Value. Tabell 3-4 viser standard SIP-headere, samt de headerne som er relevante i denne oppgaven. Header To From Via Call-ID CSeq Beskrivelse URL til SIP-enheten som en forespørsel sendes til. Dette gjelder også ved en respons, d.v.s. ved en respons er To lik URL-en til den som sender responsen. Kan i tillegg inneholde en tag for å identifisere en sesjon og et navn. Tilsvarende som To, men URL til SIP-enheten som sender en forespørsel. Lagrer veien en forespørsel har tatt fra sender til mottaker. Benyttes for å route en respons tilbake igjen. En unik ID som identifiserer en sesjon mellom to brukeragenter. Består av en tilfeldig og en IP-adresse eller servernavn. Sekvensnummer som øker for hver forespørsel (unntatt CANCEL og ACK) og benyttes til å kaste meldinger som ikke er gyldige. Kapittel 3 - Session Initiation Protocol (SIP) 17

30 Contact Content-Type Content-Length Refer-To Referred-By Mottakeren av meldingen svarer til denne SIP-adressen. Trenger ikke være lik From-headeren, men vil ofte være det. Spesifiserer internett medietypen i meldingens body, på formen: type/sub-type. Application/sdp er standardverdi. Angir antall oktetter i meldingens body. Brukes ved REFER-metoden. Angir en URL som det skal refereres til samt metoden som skal benyttes hvor INVITE er standard og eventuelt andre parametere. Brukes i metoden som sendes som utfall av en REFER-melding. Angir hvem som har sendt REFER-meldingen. Tabell 3-4 SIP-headere For en mer detaljert oversikt over SIP-headere henvises det til [2]. 3.4 SIP-servere SIP-servere handler i henhold til forespørsler fra andre SIP-enheter. De kan operere som både server og klient. En SIP-server vil operere som en server ved at den tar i mot forespørsler, behandler og svarer på disse, og som en klient ved at den sender forespørsler til andre enheter. Disse forespørslene er som oftest et resultat av en forespørsel til SIPserveren, men de kan også sendes uten å først ha mottatt en forespørsel fra en annen enhet. SIP-serverne deles opp i logiske enheter, men en SIP-serverapplikasjon kan inneholde flere logiske enheter. Logiske SIP-servere som vil bli behandlet i dette kapittelet er Registrar, Proxy, Redirect og Presence Registrar-server En bruker registrerer seg på en Registrar-server ved å sende en REGISTER-melding. Denne serveren oppdaterer registre eller databaser slik at den til enhver tid vet hvor brukeren befinner seg og kan fortelle dette til andre brukere som vil finne vedkommende. Kapittel 3 - Session Initiation Protocol (SIP) 18

31 Registrar-serverne bør benytte autentisering for å hindre uvedkommende i å registrere en SIP-adresse til sin egen eller en annen uriktig IP-adresse. REGISTER Registrar 200 OK Figur 3-5 Brukeren registreres i en Registrar-server Proxy-server Proxy-serveren videresender forespørsler fra andre SIP-enheter til riktig lokasjon ut ifra SIP-adressen i SIP-meldingen og oppslag i en database eller Registrar-server. Fordi brukerne kan logge seg på sin SIP Registrar-server med samme SIP-adresse fra forskjellige steder og med forskjellige IP-adresser, vet ikke de som prøver å kontakte denne SIP-adressen hvilken IP-adresse som skal kontaktes. Vedkommende sender da en forespørsel til Proxy-serveren som sender den videre til riktig IP-adresse ( next hop ). En SIP Proxy-server kan enten være tilstandsløs eller ha kontroll over brukernes tilstander. En Proxy-server som har kontroll over tilstander kan utføre retransimisjon uten forespørsel fra den opprinnelige senderen av meldingen. Den har også mulighet for å utføre autentisering. En spesiell type tilstandsfull SIP Proxy-server kan også utføre forking, ved at den kan sende ut en innkommende INVITE til flere potensielle adresser. En tilstandsløs Proxy-server sender kun forespørsler videre og lagrer ingen informasjon om sesjonene, men har mulighet for å oppdage loops. Kapittel 3 - Session Initiation Protocol (SIP) 19

32 Når Proxy-serveren videresender SIP-forespørsler legger den til en Via-Header over de andre Via-Headerene som finnes i forespørselen. Dermed kan en respons finne veien tilbake til senderen av forespørselen, ved å følge listen av Via-Headere. Dette gjøres ved at Proxy-serveren fjerner den øverste Via-Headeren i en respons dersom den tilsvarer Proxy-serverens adresse og sender den videre til neste. Dersom disse adressene ikke er like har meldingen blitt sendt feil og den vil bli kastet. Proxy INVITE INVITE 180 RINGING 200 OK 180 RINGING 200 OK ACK ACK Media Session BYE BYE 200 OK 200 OK Figur 3-6 Oppsett og terminering av SIP-sesjon med Proxy-server Redirect-server En Redirect-server mottar forespørsler om hvilken IP-adresse en SIP-adresse befinner seg på og svarer med en redirection-respons (3xx) om hvor den tror SIP-adressen er. Denne serveren sender kun en melding tilbake til klienten som sendte forespørselen, men ikke videre til den forespurte. Klienten vil da som regel prøve å sende meldingen til adressen som ble returnert i Contact-headeren. Kapittel 3 - Session Initiation Protocol (SIP) 20

33 Redirect INVITE 302 Moved Temporarily INVITE 180 RINGING 200 OK ACK Media Session Figur 3-7 Oppsett av sesjon ved bruk av en Redirection-server Presence-server Informasjon om presence gjør det mulig for en bruker å bestemme sin egen status og dermed kontrollere når han kan bli nådd. Brukeren kan da sette sin status til for eksempel ledig, opptatt eller utilgjengelig. Den som ringer kan da først sjekke hans status (med godkjennelse), og dersom statusen tillater det prøve å sette opp en samtale. Presenceinformasjonen kan hentes fra for eksempel brukerens kalender slik at den oppdateres automatisk. En Presence server kan enten være en Presence Agent- eller en Presence Proxy-server som videresender meldinger. [19] - Dersom den oppfører seg som en Presence Agent vil den holde oversikt over brukernes presence og svare på SUBSCRIBE-meldinger. Brukerens presenceinformasjon vil den få fra brukerens Registrar eller en annen database Kapittel 3 - Session Initiation Protocol (SIP) 21

34 hvor brukeren melder fra om presence (trenger ikke å være ved SIP-meldinger). Når brukeren endrer status vil Presence agenten sende en NOTIFY til brukeren som har abonnert på informasjonen. - Dersom serveren oppfører seg som en Presence Proxy server vil den kun videresende SUBSCRIBE og NOTIFY meldingene til riktige agenter, som så svarer på dem. Presence Agent Server REGISTER 200 OK SUBSCRIBE 200 OK NOTIFY UPDATE PRENSENCE (non SIP) 200 OK Figur 3-8 En bruker abonnerer på presenceinformasjon fra en annen bruker ved en Presence Agent server. Kapittel 3 - Session Initiation Protocol (SIP) 22

35 Presence Proxy Server SUBSCRIBE SUBSCRIBE 200 OK 200 OK NOTIFY NOTIFY 200 OK 200 OK Figur 3-9 En bruker abonnerer på presenceinformasjon fra en annen bruker ved en Presence Proxy server 3.5 SIP-endepunkt SIP-endepunkt kalles også brukeragenter (User Agents). Hver brukeragent består av både en klient og en server del: User Agent Client (UAC) og User Agent Server (UAS). En User Agent Client er den delen av brukeragenten som initierer en sesjon. Den vil sende forespørsler som inneholder en SIP-metode. En User Agent Server vil lytte på den aktuelle SIP-porten og ta imot forespørsler fra en annen brukeragent. Den vil da prosessere disse og eventuelt sende en respons tilbake. Begge brukes vanligvis under en sesjon, noe som er ulikt mange andre server/klient arkitekturer. Det er brukeragentene som håndterer tilstanden i sesjonene gitt ved headerne: To, From, Call-Id og Cseq. Brukeragentene er hovedsakelig delt inn i to kategorier: brukerklienter og gatewayer. Kapittel 3 - Session Initiation Protocol (SIP) 23

36 3.5.1 Brukerklienter Brukerklienter er klienter som benytter SIP-protokollen. Disse vil sette opp og kontrollere sesjoner ut i fra brukerens handlinger. Brukeren av klienten vil som regel være en person, men kan også være en applikasjon eller en protokoll. Brukerklientene kan være enten dedikerte SIP-telefoner eller forskjellige typer datamaskiner. En SIP-brukeragent kan nå en annen brukeragent direkte dersom den kjenner den andres IP-adresse. Dersom denne ikke er kjent kan en SIP-server benyttes for å finne IPadressen Gatewayer En SIP gateway kobler sammen SIP og andre typer nettverk, som for eksempel PSTN eller IP-telefoni systemet H.323. Den vil oppføre seg som en spesiell brukeragent, som terminerer SIP-signaleringen og oversetter denne til riktig signaleringsprotokoll for det andre nettet, og motsatt. SIP-gatewayen vil også i noen tilfeller terminere mediestrømmene og kode disse om til riktig format som sendes videre. Dette må skje i en gateway mellom SIP og PSTN, men trenger ikke skje mellom SIP og H.323 dersom RTP forbindelsen settes opp mellom de endelige endepunktene. En SIP gateway vil kunne betjene mange SIP sesjoner samtidig. 3.6 Session Description Protocol (SDP) SDP benyttes for å forhandle frem parametere som skal brukes i en SIP-sesjon. Dette er egentlig ikke en protokoll slik en vanligvis definerer protokoller i et kommunikasjonssystem, men et dataformat med parametere på formen: x=verdi, hvor x angir en bokstav. SDP inneholder bl.a. informasjon om IP-adresser eller servernavn, portnumre, medietyper og mediekoding. For eksempel vil m= angi medieinformasjon, Kapittel 3 - Session Initiation Protocol (SIP) 24

37 mens a= angir ett attributt. For en fullstendig definisjon av SDP parametere henvises det til RFC SDP: Session Description Protocol [18]. SDP dokumentet under viser en del av vedlegget i fra eksempelmetoden i begynnelsen av dette kapittelet. Her angis det at brukeren ønsker å sette opp en sesjon med lyd og video, ved m=audio og m=video, og hvilke attributter som ønskes for hver av disse. v=0 o=- 0 0 IN IP s=session c=in IP b=ct:128 t=0 0 m=audio RTP/AVP k=base64:jjwss4c9pphxzx5qi1jphkzrkdrlauz6pcwem4z1mu0 a=rtpmap:5 DVI4/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp: a=encryption:optional m=video RTP/AVP k=base64:xm0ohorit9v4y5bw61y4g8kh+t1en6j1bmim4pqcmhy a=recvonly a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 a=encryption:optional 3.7 Instant Messaging (IM) IM er meldinger som kommer frem øyeblikkelig. I motsetning til store and foreward tjenester, som for eksempel SMS, vil disse meldingene sendes direkte til mottakeren uten å lagres noe sted. IM vil være nyttig dersom det sendes flere meldinger frem og tilbake, for å få mindre tidsforsinkelse mellom meldingene. Denne tjenesten vil ofte benytte presence for å finne ut om mottakeren er tilgjengelig, før meldingene sendes. I SIP støttes IM ved MESSAGE metoden, som beskrevet i RFC en [17] 3.8 Mobilitet En av viktigste egenskaper i SIP er god støtte for følgende typer mobilitet: - Terminalmobilitet; at en kan ta med seg en SIP terminal og benytte den andre steder. Dette kan både være diskret og kontinuerlig. Kapittel 3 - Session Initiation Protocol (SIP) 25

38 - Personalmobilitet; at en bruker kan benytte flere forskjellige terminaler uavhengig av fysisk lokasjon med samme SIP-adresse. - Sesjonsmobilitet; at en sesjon opprettholdes når en SIP-klient forflyttes. SIP støtter mobilitet ved å sende REGISTER-meldinger når terminalen skifter IP-adresse. Brukeren som initierer en sesjon kan benytte en Proxy- eller Redirect-server for å finne den andre parten. SIP støtter også adresseportabilitet ved at en bruker kan velge hvilken operatør eller tjenestetilbyder som skal drifte tjenesten. Dette tilsvarer nummerportabilitet ved PSTN. Operatøren eller tjenestetilbyderen vil da videresende forespørslene til riktig IP-adresse. Mobilitet i SIP og andre mobilitetssystemer som for eksempel Mobil IP utfyller hverandre, ved at SIP-klienten da vil beholde sin IP-adresse når den forflyttes. Dette gjør at SIP-klienten slipper å registrere seg på nytt og sende en Re-INVITE. Det er imidlertid et problem ved bruk av Mobil IP at den må bruke både home-agent og foreign-agent, som kan skape forsinkelser ved overgang til et nytt nett. 3.9 Sikkerhet Sikkerhetsfunksjonaliteten i SIP-protokollen består av: autentisering, kryptering og ikkebenekting. SIP støtter to typer autentisering av klientene, da det er enkelt å sende en falsk From header (vises i Figur 3-10): - SIP Proxy-server: for å få lov til å bruke serveren. Serveren svarer med respons: 407 Proxy Authentication Required og en utfordring i en Proxy-Authenticate header dersom klienten må autentisere seg. Klienten vil da sende en ny SIPmelding med autentiseringsinformasjon i en Proxy-Authorization header. - Annen SIP-enhet: for at den andre enheten skal være sikker på hvem den oppretter en sesjon med. Denne enheten kan være en annen klient eller en server som for eksempel en Registrar- eller Redirect-server. Den andre enheten vil svare Kapittel 3 - Session Initiation Protocol (SIP) 26