MASTEROPPGAVE - NTNUpeople.item.ntnu.no/~lillk/stud-proj/Hallingstad.pdf · 2004. 6. 17. ·...

NORGES TEKNISK-NATURVITENSKAPELIGE UNIVERSITET

FAKULTET FOR INFORMASJONSTEKNOLOGI, MATEMATIKK OG ELEKTROTEKNIKK

MASTEROPPGAVE Kandidatens navn: Lars Kristian Hallingstad Fag: Telematikk Oppgavens tittel (norsk): Multimedia og multimodalitet for CallCenter Oppgavens tittel (engelsk): 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

i

Multimedia og multimodalitet for CallCenter Masteroppgave av Lars Kristian Hallingstad

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.

ii


Forord

Denne masteroppgaven ble utført ved Norges Teknisk Naturvitenskaplige Universitet

(NTNU), institutt for Telematikk, i perioden januar til juni 2004.

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

iii


Innholdsfortegnelse

Sammendrag ........................................................................................................................ i Forord.................................................................................................................................. ii Innholdsfortegnelse............................................................................................................ iii Forkortelsesliste ................................................................................................................. vi Figurliste .......................................................................................................................... viii Tabelliste............................................................................................................................ ix 1. Innledning ................................................................................................................... 1 2. Bakgrunn..................................................................................................................... 4

2.1 Multimedia og multimodalitet ............................................................................ 4 2.2 CallCenter ........................................................................................................... 6

2.2.1 Tradisjonelt CallCenter............................................................................... 6 2.2.2 Muligheter................................................................................................... 7

3. Session Initiation Protocol (SIP)............................................................................... 11 3.1 Adresser ............................................................................................................ 14 3.2 Metoder og respons........................................................................................... 14

3.2.1 Opprinnelige metoder ............................................................................... 14 3.2.2 Vanlige utvidelsesmetoder (extensions) ................................................... 15 3.2.3 Respons ..................................................................................................... 16

3.3 Headere ............................................................................................................. 17 3.4 SIP-servere........................................................................................................ 18

3.4.1 Registrar-server......................................................................................... 18 3.4.2 Proxy-server.............................................................................................. 19 3.4.3 Redirect-server.......................................................................................... 20 3.4.4 Presence-server ......................................................................................... 21

3.5 SIP-endepunkt................................................................................................... 23 3.5.1 Brukerklienter ........................................................................................... 24 3.5.2 Gatewayer ................................................................................................. 24

3.6 Session Description Protocol (SDP) ................................................................. 24 3.7 Instant Messaging (IM)..................................................................................... 25 3.8 Mobilitet............................................................................................................ 25 3.9 Sikkerhet ........................................................................................................... 26 3.10 Brannmurer og Network Address Translation (NAT) ...................................... 28 3.11 Tjenestekvalitet (QoS) ...................................................................................... 28 3.12 JAIN SIP ........................................................................................................... 29

4. Parlay ........................................................................................................................ 33 4.1 Parlay Open Service Access ............................................................................. 33 4.2 Parlay X Web Services ..................................................................................... 34 4.3 Parlay Multi-Media Call Control ...................................................................... 35 4.4 Parlay og CallCentre ......................................................................................... 36

5. Synchronized Multimedia Integration Language (SMIL) ........................................ 37 6. Aksessteknologier og terminaler............................................................................... 39

6.1 Aksessteknologier ............................................................................................. 39 6.1.1 Public Switsjed Telephone Network (PSTN) ........................................... 39

iv


6.1.2 Global System for Mobile Communication (GSM).................................. 40 6.1.3 General Packet Radio System (GPRS) ..................................................... 41 6.1.4 Enhanced Data for Global Evolution (EDGE).......................................... 44 6.1.5 Universal Mobile Telecommunication System (UMTS).......................... 45 6.1.6 Bredbånd................................................................................................... 47 6.1.7 Wireless LAN (WLAN)............................................................................ 49 6.1.8 LAN .......................................................................................................... 50

6.2 Terminaler......................................................................................................... 51 6.2.1 PSTN-terminal .......................................................................................... 51 6.2.2 Mobiltelefon.............................................................................................. 51 6.2.3 Håndholdt datamaskin .............................................................................. 54 6.2.4 PC.............................................................................................................. 55 6.2.5 SIP-telefon ................................................................................................ 56 6.2.6 Terminalmuligheter................................................................................... 57

7. Sammenligning og integrasjon ................................................................................. 58 7.1 Sammenligning ................................................................................................. 58 7.2 Integrasjon......................................................................................................... 59 7.3 Andre standarder for integrasjon av IP og PSTN ............................................. 62

7.3.1 PSTN and INTerworking (PINT) ............................................................. 63 7.3.2 Servers in the PSTN Initiating Requests to InTernet Servers (SPIRITS). 63

8. CallCenter-løsning .................................................................................................... 64 8.1 Spesifikasjon ..................................................................................................... 64

8.1.1 Supporttjeneste.......................................................................................... 65 8.1.2 CallCenter-server ...................................................................................... 66 8.1.3 Agentklient................................................................................................ 66 8.1.4 Kundeklient............................................................................................... 67

8.2 Design ............................................................................................................... 67 8.2.1 SIP-meldingsdiagrammer ......................................................................... 68 8.2.2 JAIN SIP Applikasjoner ........................................................................... 73 8.2.3 Kontrollenhet ............................................................................................ 76 8.2.4 Medieserver............................................................................................... 78 8.2.5 Agentklient................................................................................................ 81 8.2.6 Kundeklient............................................................................................... 82

8.3 Utvidelser og alternative løsninger ................................................................... 82 8.3.1 Agent transfer............................................................................................ 82 8.3.2 SIP kontroller ............................................................................................ 83 8.3.3 Statistikk og presence til kunder ............................................................... 84 8.3.4 Medietolkning ........................................................................................... 84 8.3.5 Kundeklient............................................................................................... 85 8.3.6 Tastelyder.................................................................................................. 85

9. Diskusjon og utfordringer ......................................................................................... 86 10. Konklusjon................................................................................................................ 88 11. Referanser ................................................................................................................. 90 12. Vedlegg 1 Installasjonsbeskrivelse ........................................................................... 95

12.1 Kontrollenhet .................................................................................................... 95 12.2 Medieserver....................................................................................................... 95

v


12.3 Agentklient........................................................................................................ 96 13. Vedlegg 2 Kontrollenhet........................................................................................... 97

13.1 Strukturdiagrammer .......................................................................................... 97 13.1.1 System CallCenter .................................................................................... 97 13.1.2 Package env .............................................................................................. 97 13.1.3 Package ejb ............................................................................................... 98 13.1.4 Actor CallCenter ....................................................................................... 98 13.1.5 Actor CallerAgent..................................................................................... 99 13.1.6 Actor CallCenterGroup........................................................................... 100

13.2 Meldingsdiagrammer ...................................................................................... 101 13.2.1 StartCallCenter........................................................................................ 101 13.2.2 Login ....................................................................................................... 102 13.2.3 Logoff ..................................................................................................... 103 13.2.4 Call.......................................................................................................... 104 13.2.5 CallAgent ................................................................................................ 106 13.2.6 CallAgentSetup ....................................................................................... 107 13.2.7 CallExp ................................................................................................... 108 13.2.8 ImsExp .................................................................................................... 109 13.2.9 RemoveCallerAgent................................................................................ 110

13.3 Tilstandsdiagrammer....................................................................................... 111 14. Vedlegg 3 SIP-meldinger........................................................................................ 119

vi


Forkortelsesliste

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

vii


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

viii


Figurliste

Figur 3-1 Meldingsdiagram for en enkel SIP-sesjon ........................................................ 11 Figur 3-2 Oversikt over internett protokoller som viser at SIP kan benytte både UDP og TCP [1].............................................................................................................................. 12 Figur 3-3 RTP-mediestrømmen vil ikke nødvendigvis gå samme vei som SIP-signaleringen ..................................................................................................................... 13 Figur 3-4 Eksempel på bruk av REFER-metoden. ........................................................... 16 Figur 3-5 Brukeren registreres i en Registrar-server ........................................................ 19 Figur 3-6 Oppsett og terminering av SIP-sesjon med Proxy-server. ................................ 20 Figur 3-7 Oppsett av sesjon ved bruk av en Redirection-server....................................... 21 Figur 3-8 En bruker abonnerer på presenceinformasjon fra en annen bruker ved en Presence Agent server....................................................................................................... 22 Figur 3-9 En bruker abonnerer på presenceinformasjon fra en annen bruker ved en Presence Proxy server ....................................................................................................... 23 Figur 3-10 Oppsett av en SIP-sesjon med autentisering for både en Proxy server og en annen klient....................................................................................................................... 27 Figur 3-11 JAIN SIP objekt arkitektur [6]........................................................................ 30 Figur 3-12 Transaksjonskontroll i JAIN SIP [6]............................................................... 31 Figur 4-1 Oversikt over oppbygningen av Parlay [24] ..................................................... 33 Figur 4-2 Parlay X Web Service oversikt [27] ................................................................. 35 Figur 5-1 Eksempel på SMIL-dokument [31] .................................................................. 38 Figur 6-1 Oppsett av sesjon ved IMS, med vist rekkefølge for sending av forespørsel. [51].................................................................................................................................... 47 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............................................ 52 Figur 6-3 Pocket PC 2003 enheten HP Ipaq 4150 og den Palm OS baserte Sony CLIE PEG-UX50........................................................................................................................ 54 Figur 6-4 Eksempel på SIP-telefon fra Pingtel [66] ......................................................... 57 Figur 7-1 Oversikt over integrasjon av PSTN og IP-nett med signalering, media og gateway [2]........................................................................................................................ 59 Figur 7-2 Meldingsdiagram for PSTN (ISUP) til SIP-gateway [2] .................................. 61 Figur 7-3 Modell over PINT [2] ....................................................................................... 63 Figur 8-1 Hovedenheter i en CallCenter-løsning.............................................................. 64 Figur 8-2 Eksempel på menystruktur................................................................................ 65 Figur 8-3 Overordnet struktur av CallCenter løsningen. .................................................. 68 Figur 8-4 SIP-meldingsdiagram Call ................................................................................ 70 Figur 8-5 SIP-meldingsdiagram Transfer ......................................................................... 72 Figur 8-6 SIP Communicator – applikasjons design [7]................................................... 74 Figur 8-7 JAIN-SIP – brukeragent klient [7].................................................................... 74 Figur 8-8 JAIN SIP – brukeragent server [7].................................................................... 75 Figur 8-9 Flere mediekilder settes sammen til en prosessor............................................. 79 Figur 8-10 Alternativ løsning med SIP kontroller ............................................................ 83

ix


Tabelliste

Tabell 3-1 Opprinnelige SIP-metoder............................................................................... 14 Tabell 3-2 SIP-utvidelsesmetoder..................................................................................... 15 Tabell 3-3 Responskoder .................................................................................................. 17 Tabell 3-4 SIP-headere ..................................................................................................... 18 Tabell 6-1 Hastigheter og maks rekkevidde for aktuelle DSL-teknologier [52][53]........ 48 Tabell 7-1 Oversetting mellom SIP-, ISUP- og ISDN-meldinger og parametere [2]....... 60

Kapittel 1 - Innledning 1


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 IP-

protokollen 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.



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.



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 2 - Bakgrunn 4


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.



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.



2.2 CallCenter

2.2.1 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 CallCenter-

applikasjoner 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.



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.

2.2.2.1 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



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.

2.2.2.2 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.

2.2.2.3 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ø.

2.2.2.4 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.



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.

2.2.2.5 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.

2.2.2.6 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.

2.2.2.7 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



forskjellige typer aksessnettverk og benytte ulike typer terminaler med forskjellige

egenskaper. Dette kan være med på å bestemme hvor kundene skal rutes.

2.2.2.8 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 3 - Session Initiation Protocol (SIP) 11


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.

Media Session

INVITE

180 RINGING

200 OK

ACK

200 OK

BYE

Figur 3-1 Meldingsdiagram for en enkel SIP-sesjon



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 (www.ietf.org). 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 1999. I 1999 ble det også opprettet en egen arbeidsgruppe for SIP i IETF, som

erstattet RFC 2543 med RFC 3261 i 2002.

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 SIP-

servere 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]



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).

SIP

RTP Media

SIP

SIP

SIP-server

SIP-klient

SIP-server

SIP-klient

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:[email protected] SIP/2.0 Via: SIP/2.0/UDP 129.241.200.223:12394 Max-Forwards: 70 From: "Lars" <sip:[email protected]>;tag=1a1eae3b6c4f478f943d772e2bbb3c35;epid=f0aa1a6409 To: <sip:[email protected]> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:129.241.200.223:12394> User-Agent: RTC/1.2 Content-Type: application/sdp Content-Length: 694



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:[email protected]. 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

2543. Flere metoder blir definert i egne RFC-er som utvidelser (extensions) til SIP.

3.2.1 Opprinnelige metoder

Metode Beskrivelse

INVITE 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.

ACK Bekrefter den endelige responsen til en INVITE (respons 2xx, 3xx,

4xx, 5xx og 6xx).

BYE Avslutter en sesjon. Kan sendes av alle deltagende parter i en

sesjon.

CANCEL Terminerer INVITE meldinger under behandling. Kan sendes av

både brukeragenter og Proxy-servere.

REGISTER Forteller en SIP-Registrar hvilken IP-adresse og URL brukeren kan

kontaktes på.

OPTIONS Brukes for å finne en server eller en brukeragent sine kapabiliteter

og tilgjengelighet.

Tabell 3-1 Opprinnelige SIP-metoder



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 SIP-

metode 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.



INVITE

180 RINGING

200 OK

ACK

200 OK

REFER

Media Session

INVITE

180 RINGING

200 OK

ACK

Bruker A Bruker CBruker B

100 TRYING

Refer-To: C

BYE

200 OK

Media Session

Figur 3-4 Eksempel på bruk av REFER-metoden.

3.2.3 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.



Klasse Beskrivelse

1xx Informasjon. Viser status på forespørsel som er under behandling, men ikke

fullført.

2xx Suksess. Forespørsel er fullført med suksess.

3xx Re-direksjon. Viser til alternative lokasjoner.

4xx Klientfeil. Viser til en feilmelding hos klienten.

5xx Serverfeil. Viser til en feilmelding hos serveren. Forespørselen kan gjentas til

en annen lokasjon.

6xx 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 Beskrivelse

To 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.

From Tilsvarende som To, men URL til SIP-enheten som sender en

forespørsel.

Via Lagrer veien en forespørsel har tatt fra sender til mottaker. Benyttes

for å route en respons tilbake igjen.

Call-ID En unik ID som identifiserer en sesjon mellom to brukeragenter.

Består av en tilfeldig streng, @ og en IP-adresse eller servernavn.

CSeq Sekvensnummer som øker for hver forespørsel (unntatt CANCEL og

ACK) og benyttes til å kaste meldinger som ikke er gyldige.



Contact Mottakeren av meldingen svarer til denne SIP-adressen. Trenger ikke

være lik From-headeren, men vil ofte være det.

Content-Type Spesifiserer internett medietypen i meldingens ”body”, på formen:

type/sub-type. Application/sdp er standardverdi.

Content-Length Angir antall oktetter i meldingens ”body”.

Refer-To 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.

Referred-By 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 SIP-

serveren, 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.

3.4.1 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.



Registrar-serverne bør benytte autentisering for å hindre uvedkommende i å registrere en

SIP-adresse til sin egen eller en annen uriktig IP-adresse.

REGISTER

200 OK

Registrar

Figur 3-5 Brukeren registreres i en Registrar-server

3.4.2 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”.



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.

INVITE

180 RINGING

200 OK

ACK

200 OK

BYE

Media Session

INVITE

180 RINGING

200 OK

ACK

200 OK

BYE

Proxy

Figur 3-6 Oppsett og terminering av SIP-sesjon med Proxy-server.

3.4.3 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.



INVITE

ACK

Media Session

INVITE

180 RINGING

200 OK

302 Moved Temporarily

Redirect

Figur 3-7 Oppsett av sesjon ved bruk av en Redirection-server

3.4.4 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. Presence-

informasjonen 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



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

SUBSCRIBE

200 OK

UPDATE PRENSENCE (non SIP)NOTIFY

200 OK

REGISTER

200 OK

Figur 3-8 En bruker abonnerer på presenceinformasjon fra en annen bruker ved en Presence Agent

server.



Presence Proxy ServerSUBSCRIBE

200 OK

SUBSCRIBE

200 OK

NOTIFY

200 OK

NOTIFY

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.



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 IP-

adressen.

3.5.2 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,



mens ”a=” angir ett attributt. For en fullstendig definisjon av SDP parametere henvises

det til RFC 2327 - 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 IP4 129.241.200.223 s=session c=IN IP4 129.241.200.223 b=CT:128 t=0 0 m=audio 17164 RTP/AVP 97 111 112 6 0 8 4 5 3 101 k=base64:JjWSS4C9PPhxzX5Qi1JphkZRkDRlaUZ6PcwEM4z1mU0 a=rtpmap:5 DVI4/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=encryption:optional m=video 54822 RTP/AVP 34 31 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 3428. [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.



- 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 ikke-

benekting.

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 SIP-

melding 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



med en WWW-Authenticate header i en 401 Unauthorized respons. Klienten vil da

sende den opprinnelige forespørselen på nytt med en Autorization header.

INVITE

100 Trying

200 OK

ACK

Media Session

INVITE

200 OK

ACK

ProxyINVITE

INVITE

407 Proxy Authentication Required

ACK

INVITE

401 Unauthorized

100 Trying

401 Unauthorized

ACK

ACK

Proxy-Authenticate

Proxy-Authorization

WWW-Authenticate

WWW-Authenticate

Proxy-Authorization, Autorization

Autorization

Proxy-Authorization, Autorization

Autorization

Figur 3-10 Oppsett av en SIP-sesjon med autentisering for både en Proxy server og en annen klient

I SIP kan både header og body krypteres, men informasjon som brukes til å rute

meldingene kan ikke krypteres dersom meldingen går via Proxy-servere som ikke støtter

kryptering. Kryptering på underliggende lag, som for eksempel IPSec eller Transport

Layer Security (TLS), kan også benyttes i kombinasjon med SIP.



Det er dessuten mulig å signere SIP meldingene for å hindre ikke-benektning.

3.10 Brannmurer og Network Address Translation (NAT) I tilegg til sikkerhetsfunksjonaliteten definert i SIP-protokollen er det viktig at SIP virker

sammen med andre sikkerhetsmekanismer som brannmurer og NAT. Disse enhetene

skaper imidlertid problemer for SIP fordi SIP-protokollen benytter IP-adresser og

transportprotokollporter i meldingene. Dette kan løses ved å konfigurere enhetene for

bruk av SIP.

Mange lokalnett og intranett bruker i dag brannmurer som kun slipper inn den trafikken

som er definert. I de fleste brannmurer må det åpnes for spesifikke tjenester ved å åpne de

respektive portene. For å tillate SIP-meldinger inn til nettverket kan port 5060, som er

standard SIP-port, åpnes. Dette løser imidlertid kun signaleringsdelen, og det vil fortsatt

oppstå problemer når mediesesjonen skal settes opp, som angitt i SDP-parametrene i SIP-

meldingen. En måte å løse dette på kan være at brannmuren tolker SIP-meldingen og

åpner for den porten som er gitt i SDP og stenger den igjen når sesjonen er ferdig.

NAT kan føre til problemer ved bruk av SIP, da SIP benytter IP-adresser i meldingene på

applikasjonslaget. NAT vil endre de lokale IP-adressene på IP-laget, men ikke

nødvendigvis i SIP-meldingene og SDP-dataene. Dette kan føre til at en SIP-respons vil

bli sendt til feil sted. Måten dette blir løst på for signaleringsdelen er at for hvert ”hopp”

må IP-adressen på IP-laget sjekkes mot Via-adressen i SIP-meldingen. Dersom disse er

ulike har meldingen blitt sendt gjennom en NAT, og Via-headeren må endres til den

faktiske IP-adressen. Denne metoden benyttes for signaleringsdelen av en sesjon og andre

løsninger må benyttes for selve mediedelen, som for eksempel RTP.

3.11 Tjenestekvalitet (QoS) For at tjenester som IP-telefoni og videokonferanser skal kunne virke over et IP-nett, må

det være en viss tjenestekvalitet på de underliggende nettverkene (Quality of Service,



QoS). QoS kan måles ved tekniske mål som båndbredde (hastighet), forsinkelse og

variasjon i forsinkelse eller som brukerens opplevelse av kvaliteten.

IP-nett har som standard ingen bestemt QoS, men er basert på en best mulig (best-effort)

teknologi. Det er mulig å differensiere brukere og tjenester, for eksempel med IntServ

eller DiffServ. QoS parametere kan utveksles i SIP meldinger (ved SDP). Dersom

serverne eller andre klienter som skal benyttes eller delta i en sesjon ikke blir enige om

krav til QoS vil ikke sesjonen bli satt opp.

3.12 JAIN SIP Internettstandarder definerer protokoller som beskriver hva som skal sendes over

internett, mens det er opp til den enkelte leverandør eller utvikler å definere hvordan

maskinene som sender data skal oppføre seg. For å gjøre det enklere å benytte

protokollene som er definert, lages det API’er som utviklere kan benytte seg av. Disse

API’ene trenger ikke å være åpne standarder, men kan være leverandør- eller

operativsystemspesifikke.

Java Integrated Network (JAIN) SIP er et åpent standard-API for å utvikle applikasjoner i

Java som benytter SIP. Det definerer et felles grensesnitt mot SIP som er uavhengig av

SIP-implementasjonen (SIP-stakken). Ved å bruke dette API’et konsekvent i stedet for å

programmere direkte mot en SIP-stakk, kan en bytte SIP-stakk uten å gjøre endringer i

koden (kun noen konfigurasjons endringer). Gjeldende versjonsnummer av JAIN SIP er

1.1. [6] [21]

JAIN SIP støtter SIP funksjonaliteten i RFC 3261, utvidelsesmetodene i Tabell 3-1, samt

andre alternative eller fremtidige utvidelse ved grensesnittene EXTENSION_METHOD

og ExtensionHeader. Gjennom grensesnittet kan det spesifiseres om SIP-stakken skal

utføre retransmisjon. [6] [21]

Det er definert fire fabrikkgrensesnitt (Factories) i JAIN SIP:

- SipFactory: Oppretter den aktuelle SIP-stakken.



- AddressFactory: Lager SIP-URI’er og TelURL’er.

- HeaderFactory: Lager SIP-headere.

- MessageFactory: Lager SIP-meldinger, både forespørsler og responser.

SIP-applikasjonen må implementere en SIP-lytter som oppretter en SIP-stakk ved hjelp

av SipFactory. Når SIP-stakken opprettes må det angis parametere som IP-adresse og

hvilken implementasjon av stakken samt eventuelt standard SIP Proxy- og Registrar-

server som skal benyttes (Figur 3-11). SIP-stakken oppretter en SIP Provider som tar seg

av sending og mottak av meldinger. SIP-lytteren vil da motta meldingene som sendes til

denne IP-adressen i form av en Event som inneholder meldingen.

Figur 3-11 JAIN SIP objekt arkitektur [6]

JAIN SIP har støtte for håndtering av tilstandskontroll over SIP protokollen på

forskjellige nivåer:

- Transaksjonstilstandsløs: Hver SIP forespørsel overføres som en selvstendig

melding. Applikasjonen må håndtere eventuell tilstand.



- Transaksjonstilstandsfull: Meldingene overføres ved en transaksjon. En vil da

opprette meldinger via en transaksjon, som inneholder de andre meldingene som

er sendt i transaksjonen.

- Dialogtilstandsfull: Ende til ende transaksjonskontroll. Opprettes ved første

INVITE eller SUBSCRIBE meldinger i en sesjon. En får da tilgang til kontekst

informasjon om sesjonen og også de andre meldingene som er sendt i dialogen.

Disse nivåene for tilstandskontroll er vist i Figur 3-12, hvor en dialog kan inneholde flere

transaksjoner og en transaksjon kan inneholde flere meldinger.

Figur 3-12 Transaksjonskontroll i JAIN SIP [6]

Nedenfor vises noen JAIN SIP kode eksempler.

//Oppretter Factories SipFactory sipFactory = SipFactory.getInstance();



String sipStackPath = Utils.getProperty("net.java.sip.communicator.sip.STACK_PATH"); sipFactory.setPathName(sipStackPath); AddressFactory addressFactory = sipFactory.createAddressFactory(); HeaderFactory headerFactory = sipFactory.createHeaderFactory(); MessageFactory messageFactory = sipFactory.createMessageFactory(); //Oppretter SIP stack, propeties angir IP adresse, stack navn o.s.v. SipStack sipStack = sipFactory.createSipStack(System.getProperties()); //Oppretter en SIP URI SipURI sipURI = sipManCallback.addressFactory.createSipURI(null,"[email protected]"); //Oppretter ReferToHeader fra en SIP URI ReferToHeader rth = sipManCallback.headerFactory.createReferToHeader(sipURI); //Oppretter REFER request fra en eksisterende dialog Request refer = dialog.createRequest(Request.REFER); //Kobler ReferToHeaderen til REFER requesten refer.setHeader(rth);

Kapittel 4 - Parlay 33


4. Parlay

The Parlay Group er et konsortium bestående av flere av de største telekommunikasjons-

og IT-selskapene, som for eksempel Microsoft, Nortel Networks, Siemens, AT&T, Cisco,

Ericsson, IBM og Lucent. To norske selskaper, Telenor og Net4Call, er også medlemmer

av gruppen. Gruppen ble opprettet i 1998 for å lage en standard for å integrere

kommunikasjonssystemer i IT-applikasjoner. Dette gjør det mulig å åpne telenettene for

en tredjepart som kan utvikle og tilby tjenester til brukerne. [22]

4.1 Parlay Open Service Access Parlay Open Service Access (OSA) er et API som åpner telenettet for tredjeparts

applikasjoner gjennom et åpent standardisert grensesnitt. Dette skal gjøre det mulig for

IT-utviklere med lite kjennskap til telekommunikasjonssystemer å utvikle applikasjoner

og tjenester som benytter telenettet. [23] Deler av OSA er også akseptert av 3GPP. [73]

Figur 4-1 Oversikt over oppbygningen av Parlay [24]

En Parlay-gateway består av et sett med Service Capability Servers (SCS) og ett

rammeverk for å kontrollere disse serverne og brukerne av gatewayen. (Figur 4-1).

framework UserLocation

Call control

HLR CSE WGWWPP

Servers

E.g. Location server Billing server

Service capability servers

iinntteerrffaacceeccllaassss

OOSSAA AAPPIIAApppplliiccaattiioonn

AApppplliiccaattiioonnsseerrvveerr

NNoott ssttaannddaarrddiizzeedd

OOSSAA IInntteerrnnaall AAPPII



Parlay API’et tilbyr tjenester (API’er og SCS’er) for: mobilitet, lokasjon, tilgjengelighet,

”call control”, bruker interaksjon, meldinger, innholdsbasert betaling and ”Policy

Management”. [25][26]

Parlay API’et gjør applikasjonsutviklingen uavhengig av de underliggende

nettverkselementene. API’et tilbyes gjennom et distribuert grensesnitt, som for eksempel

Parlay OSA OMG-IDL (Object Management Group’s Interface Definition Language).

[26]

JAIN gruppen har definert JAIN Service Provider API (JAIN SPA) som er en lokal Java

API realisering av Parlay OSA API’et. Fordelene ved å tilby en lokal API er at API’et er

tilpasset programmeringsspråket. Grensesnittet er definert ved programmeringsspråket

Java og benytter Java navnekonvensjoner, designmønstre og objektorientert struktur. Det

er distribusjons uavhengig, noe som gjør at dersom de nødvendige adapterne er på plass

kan Java-applikasjonen benytte hvilken som helst teknologi for å distribuere API’et, som

for eksempel CORBA, SOAP eller RMI. [26]

4.2 Parlay X Web Services Parlay X Web Services er en ny standard fra Parlay gruppen som skal gjøre det enda

lettere å utvikle applikasjoner som bruker teletjenester. Standarden tilbyr de fleste av

tjenestene fra Parlay OSA, men fokuset i denne standarden ligger på å gjøre det enkelt

istedenfor å tilby all funksjonaliteten som Parlay OSA har. For å gjøre utviklingen så

enkel som mulig er Parlay X foreløpig tilstandsløs. Ved å benytte Web Services kan

tjenestene benyttes uavhengig av det underliggende nettverket og programmeringsspråk.

[27]

Parlay X Web Services er et forsøk på å stimulere IT utviklere som har liten kunnskap

om telekommunikasjon til å begynne å utvikle applikasjoner som benytter telenettet.

I de fleste tilfeller vil Parlay X Web Services kalle metoder på en Parlay gateway, men

det er også mulig å kommunisere direkte med nettverkselementene som vist i Figur

4-2.[28]



Parlay Gateway

Parlay X Web Services

Parlay X APIs

Parlay APIs

Parlay XApplications

ParlayApplications

Network Protocols (e.g. SIP, INAP etc)

Network Elements

Increasingabstraction

Figur 4-2 Parlay X Web Service oversikt [27]

Parlay X Web Services er en forholdsvis ny standard (versjon 1.0) og vil sannsynligvis

bli utvidet bl.a. med tilstandskontroll.

4.3 Parlay Multi-Media Call Control Multi-Media Call Control Service Capability Function (SCF) er en del av Parlay OSA

API’et (del 4,4). Funksjonen kan benytte SIP for å sette opp sesjoner. Parlay OSA API’et

vil da få støtte for å sette opp alle typer multimedia sesjoner som beskrevet i kapittelet om

SIP. Det er også mulig å benytte andre signaleringsprotokoller enn SIP, som for eksempel

H.323. Det finnes i midlertidig lite informasjon om standarden utenom

spesifikasjonen[29], og heller ingen kjente implementasjoner av denne delen av API’et.



4.4 Parlay og CallCentre Ved å benytte Parlay vil det bli ett standard grensesnitt for teletjenestene som benytter

nettverkselementer. Dette vil gjøre det lettere å utvikle CallCenter-applikasjoner som kan

styre telenettet. Det vil dermed bli mulig å kontrollere talesamtaler, finne lokasjon til

terminaler, sende SMS og MMS og samle inn tastetrykk fra kunden. Dette er nærmere

beskrevet og implementert i prosjektoppgaven ”CallCenter in Amigos” [30]. Parlay gjør

det altså mulig å utvikle applikasjoner mot et standardisert og relativt enkelt grensesnitt

istedenfor å utvike applikasjoner mot spesifikke nettelementer. Selskaper som ønsker et

CallCenter kan da få tilgang til Parlay gatewayen og benytte egne CallCenter-

applikasjoner. En vil da fortsatt ha de samme fordelene som et IN-CallCenter, bl.a. at en

slipper trunkering og at køhåndtering kan foregå i telenettet.

Parlay X Web Service standarden kan kun benyttes til veldig enkle CallCenter-

applikasjoner da den ikke har tilstands kontroll. Dette er fordi den ved mottak av en

samtale med en gang må bestemme hva som skal gjøres med samtalen, Etter dette er det

ikke mulig å gjøre noe mer med den, og samtalen kan ikke settes over fra en IVR til en

agent eller fra en agent til en annen agent.

Støtte for multimedia og multimodalitet i Parlay er avhengig av hvordan Multi-Media

Call Control API’et blir utviklet og i hvor stor grad det blir tatt i bruk. Det er mulig å

sende multimedia i MMS meldinger, men disse kan som regel ikke mottas mens en

samtale er aktiv (se kapittel 6.1.3).

Kapittel 5 - Synchronized Multimedia Integration Language (SMIL) 37


5. Synchronized Multimedia Integration Language (SMIL)

SMIL (uttales "smile") er en standard for å presentere multimedia innhold. SMIL

benyttes for å integrere flere typer media som lyd, video, bilder og tekst. En SMIL-

applikasjon blir skrevet som et XML-dokument med tids- og synkroniserings

informasjon. Hvert medieelement blir angitt ved en URL, og SMIL-applikasjonen

beskriver hvordan disse skal vises frem. [32]

SMIL standarden spesifiserer XML-elementer og attributter for å kontrollere

presentasjonen av multimedia komponenter i sekvens, parallell eller "exclusive".

Spesifikasjonen definerer også en del elementer og attributter for å kontrollere

synkronisering og interaktivitet. [32]

Gjeldende versjon av SMIL er 2.0. Målet med utviklingen av denne versjonen var å

utvide SMIL til et deklarativt, XML-basert og synkronisert språk. Timing modellen måtte

da utvides, og SMIL 2.0 støtter nå følgende funksjonalitet:[31]

- Animering

- Innholdskontroll

- Layout

- Linking

- Integrasjon av medieobjekter

- Metainformasjon

- Struktur

- Timing og synkronisering

- Tidsmanipulering

- Overgangseffekter

Figur 5-1 viser et eksempel på i en SMIL-applikasjon (det er kun apllikasjonens”body”

som er vist). Eksempelet demonstrerer bruken av parallell (par) og eksklusiv (excl). To

bilder blir vist som knapper. Når brukeren klikker på en knapp, vil riktig sekvens bli spilt

av. Dersom Story velges vil det vises en tekst samtidig som en video spilles av, og

Kapittel 5 - Synchronized Multimedia Integration Language (SMIL) 38


dersom Weather velges vil det vises et bilde mens en lydfil spilles (par). Det vil kun være

en sekvens som kan spilles om gangen (excl). [31]

<par> <a href="#Story"> <img src="button1.jpg"/> </a> <a href="#Weather"> <img src="button2.jpg"/></a> <excl> <par id="Story" begin="0s"> <video src="video1.mpg"/> <text src="captions.html"/> </par> <par id="Weather"> <img src="weather.jpg"/> <audio src="weather_rpt.mp3"/> </par> </excl> </par>

Figur 5-1 Eksempel på SMIL-dokument [31]

Multimedia Messaging Service (MMS) er en tjeneste som er basert på SMIL. MMS er en

“store and forward” meldingstjeneste som gjør det mulig å sende multimedia meldinger

fra en mobil enhet. Mottakeren kan være ett telefonnummer eller en e-post adresse. MMS

virker på samme måte som SMS, men støtter i tillegg til tekst også bilder, lyd og video

samt kombinasjoner av disse. Det kan sendes flere medieelementer i hver melding, og

hver melding kan sendes til flere mottakere.

SMIL vil ikke være egnet til å styre en video- eller talesesjon i forbindelse med et

CallCenter, men vil kunne presentere multimedia informasjon hentet fra en CallCenter-

applikasjon for eksempel ved å sende en MMS melding. Det kan også være aktuelt å

bruke SMIL i en interaktiv meny hvor mediefiler spilles av. SMIL kan da styre en

interaktiv medieserver, og eventuelt bruke en link for å koble kunden til en agent for

personlig behandling.

Kapittel 6 - Aksessteknologier og terminaler 39


6. Aksessteknologier og terminaler

I dette kapittelet vil forskjellige aksessteknologier og terminaltyper studeres. Dette vil

omfatte både eksisterende teknologier og terminaler, og de som forventes å komme i

løpet av den nærmeste tiden. Det vil ikke legges noe særlig vekt på tekniske detaljer, men

mer på hvilke muligheter som finnes for multimedia og multimodalitet generelt og i

forbindelse med SIP.

6.1 Aksessteknologier I dette kapittelet vil det være fokus på multimedia og ikke multimodalitet da

aksessteknologiene kun overfører media, mens det er terminalene som vil presentere eller

samle inn disse. For å se hvilke muligheter for multimedia som ligger i de forskjellige

aksessteknologiene må en se på hvilke tjenester som støttes og QoS parametere som for

eksempel hastighet og tilgjengelighet. For de aksessteknologiene som er i drift vil også

prismodeller for de forskjellige tjenestene i aksessteknologien gjennomgås, da dette er en

viktig faktor for hvor godt egnet teknologien er for multimediebruk. De mest aktuelle

mobile, trådløse og faste teknologiene som en terminal kan benytte vil studeres. Dette vil

ikke nødvendigvis være kun aksessteknologier, men kan også inkludere hele systemer

som kan benyttes som aksessteknologier. Gjennom disse aksessteknologiene kan

terminalene koble seg til enheter som igjen kan benytte andre aksessteknologier, som for

eksempel fiber, til å koble seg til internett.

6.1.1 Public Switsjed Telephone Network (PSTN)

PSTN betegner vanlige linjesvitsjede telefonlinjer og telefoniapparatene som brukes kan

enten være analoge telefoner (Plain Old Telphone Service, POTS) eller ISDN-telefoner

(Integrated Services Digital Network).

Det analoge telenettet ble utviklet for å håndtere talesamtaler, men det er nå mulig å

sende data med en hastighet på opptil 56 kbps over en analog telefonlinje ved hjelp av et

MODEM (Modulator Demodulator).



ISDN benytter datalinjer (D-linjer) på 64 kbps (i noen land 56 kbps), og styringslinjer (B-

linjer) på 16 kbps. For å sette opp en talesamtale benyttes en D-linje, mens det er mulig å

benytte flere D-linjer til å sette opp en data forbindelse. Til privat bruk er det vanlig med

et basisabonnement med 2 D-linjer og 1 B-linje, som gir en maksimal

dataoverføringshastighet på 128 kbps.

For å benytte PSTN tjenester må en ha ett abonnement, som faktureres per måned. For

hver samtale betales en startkostnad og deretter en takst per tidsenhet. Ved ISDN betales

en tidstakst per D-linje som benyttes, slik at en betaler dobbelt så mye for å benytte en

dataoverføringshastighet på 128 kbps i forhold til 64 kbps eller en talesamtale.

Da PSTN nettet er linjesvitsjet og en betaler for tiden en er koblet på internett, vil det

være lite aktuelt med multimedia og SIP-sesjoner over IP-nett. Grunnen til dette er at en

må være koblet til internett for å kunne motta sesjoner. Brukeren må da betale for å være

koblet på internett selv om forbindelsen ikke benyttes aktivt. Han vil heller ikke få den

garanterte tjenestekvaliteten som han har ved en linjesvitsjet talesamtale. Det kan

imidlertid være behov for å koble seg på et IP-nett dersom personen som skal nåes kun er

tilgjengelig over dette (ingen gateway tilgjengelig) eller hvis det for eksempel skal sendes

SIP-tekstmeldinger. Ved bruk av ISDN kan flere D-linjer benyttes slik at en får

dataoverføringshastigheter som er høye nok til å kunne overføre multimediesesjoner som

videokonferanser.

6.1.2 Global System for Mobile Communication (GSM)

GSM ble lansert på begynnelsen av 1990-tallet og er i dag den vanligste standarden for

mobiltelefoni. GSM er basert på linjesvitsjet (CS) teknologi, og omtales som andre

generasjons mobil nett (2G) etter første generasjons analoge mobil nett som var NMT.

Tjenester som tilbys i GSM er tale, data, fax og SMS.



GSM benytter en kombinasjon av TDMA og FDMA med 8 tidsluker pr. frekvens. Det er

mulig å overføre data i GSM ved Circuit Svitsjed Data (CSD). Den opprinnelige

datahastigheten i en tidsluke var 9,6 kbps, som er utvidet til 14,4 kbps ved hjelp av en ny

modulasjonsteknikk. Ved å benytte High Speed Circuit Switched Data (HSCSD) er det

mulig å kombinere flere tidsluker, som oftest 2 eller 3, for å øke hastigheten. De fleste litt

avanserte GSM terminaler har støtte for HSCSD.

Det finnes mange forskjellige prisklasser og GSM-abonnementer i dagens marked. Det

mest vanlige er en prisstruktur tilsvarende PSTN, men med noe lavere fast avgift og

høyere samtalepriser. Dette gjelder for tale, data og fax, mens SMS faktureres per

melding som sendes. Ved å benytte HSCSD vil en som oftest måtte betale for flere

tidsluker.

GSM ble utviklet for linjesvitsjet tale og er best egnet til dette formålet. Det er mulig å

benytte SIP og IP-telefoni over CSD og HSCSD, men tilvarende PSTN må en være

påkoblet internett for å kunne motta sesjoner. SIP-meldinger vil være mulig på samme

måte som ved PSTN. Til videokonferanse vil HSCSD (og dermed også CSD) ha for lav

overføringshastighet, men streaming med tilpasset innhold vil kunne være mulig over

HSCDS.

6.1.3 General Packet Radio System (GPRS)

GPRS ble utviklet som en pakkesvitsjet utvidelse til GSM og standardisert av ETSI i

1997. GPRS benytter eksisterende GSM infrastruktur og teknologi (hvor noe må

oppgraderes), i tillegg til GPRS-spesifikt utstyr som Gateway GPRS Service Node

(GGSN) og Serving GPRS Service Node (SGSN). GPRS betegnes som 2,5G da

teknologien er et steg på vei mot 3G. GPRS er nå tilgjengelig i de fleste GSM-nett og nær

sagt alle GSM-terminaler som selges i dag har støtte for standarden. [40]

Den teoretiske maksimumshastigheten i GPRS er på 171,2 kbps ved å benytte alle de åtte

tidslukene i en frekvens. De fleste GPRS terminalene støtter kun 3-4 samtidige tidsluker.



Dersom terminalene hadde hatt støtte for åtte tidsluker ville dette likevel vært vanskelig å

få tildelt, da de skal fordeles mellom GSM og GPRS brukere og GPRS er nedprioritert i

forhold til GSM. I praksis vil en med GPRS oppnå en hastighet på ca. 30-40 kbps

nedstrøms og 10 kbps oppstrøms.

GPRS terminaler er delt inn i tre klasser etter dens muligheter for å kombinere GSM og

GPRS tjenester: [41]

- Klasse A: Terminalen kan være koblet til både GSM- og GPRS-tjenester

samtidig.

- Klasse B: Terminalen kan være koblet til både GSM- og GPRS-tjenester, men

kun en tjeneste om gangen. Dersom en GPRS-tjeneste er aktiv kan enheten både

initiere og motta samtaler og SMS, men vil da koble ned GPRS-tjenesten. Når

samtalen er avsluttet eller SMS er overført vil GPRS-tjenesten automatisk

fortsette.

- Klasse C: Terminalen kan være koblet til enten en GSM- eller en GPRS-tjeneste,

og brukeren må bytte manuelt mellom dem.

De fleste GPRS-terminaler er av klasse B, og kan derfor ikke benytte GSM og GPRS

samtidig. Dermed er det ikke mulig å motta mediefiler eller sesjoner mens en har en aktiv

CS samtale, noe som ville ha vært mulig med klasse A terminaler. Klasse A terminaler er

lite utbredt fordi terminalen da må bruke to forskjellige frekvenser, en til pakkesvitsjet og

en til linjesvitsjet overføring. Terminalen må da ha to sendere og mottakere, noe som vil

ta mer plass og bruke mer strøm. GSM har nå standardisert Dual Transfer Mode (DTM)

som er en teknologi for å sende pakke- og linjesvitsjede data på samme frekvens. Når

denne teknologien kommer på markedet vil det bli mer aktuelt å lage klasse A terminaler.

[42]

GPRS var den første aksessteknologien som gjorde det mulig å sende og motta MMS fra

en mobiltelefon. GPRS brukes også for å koble terminaler til internett, enten med vanlige

internettprotokoller som HTTP eller med Wireless Application Protocol (WAP) gjennom

en WAP-gateway. WAP er en standardprotokoll for å koble en mobilenhet til en server i



mobile nettverket. Men WAP har ikke blitt så stort som forventet, delvis fordi

terminalene har hatt et tungvint brukergrensesnitt for WAP.

For å benytte GPRS må en ha et GSM-abonnement som støtter GPRS. Da betaler en kun

for den datamengden som faktisk sendes. Dette gjør at en alltid kan være koblet på et IP-

nett med GPRS uten at det koster noe dersom data ikke sendes. I dag har operatørene en

”trappesystem” pris, hvor du betaler mye for de første dataene i hver måned (ca. 50 kr. pr.

MB), mens prisen synker etter hvert (til ca. 10 kr. pr. MB). Det er en utfordring å

prissette GPRS data, da det er stor forskjell på tjenestene som benyttes. Dette vil gjøre det

relativt billig med overføring av tekst over GPRS, mens det blir forholdsvis dyrt med

video. MMS faktureres per melding som sendes, som SMS men noe dyrere.

Ved at man alltid kan være koblet på internett men kun betaler for dataene som sendes

egner GPRS seg godt sammen med for eksempel SIP-tekstmeldinger (MESSAGE). Det

vil være en del billigere å sende SIP-tekstmeldinger enn å sende SMS. En annen forskjell

er at meldingen kommer frem ”øyeblikkelig” som beskrevet i kapittel 3.7.

Overføring av talesamtaler over GPRS er mulig, men i praksis blir hastigheten ofte for

lav ved at GPRS data prioriteres under GSM. En ny tjeneste som har blitt lansert i flere

mobilnett er ”Push To Talk”. Denne tjenesten vil la brukeren sende ”øyeblikklige”

lydmeldinger til en eller flere andre brukere, ved for eksempel å holde inn en knapp, og

kan sammenlignes med Walkie Talkie. Dette kan være en nyttig tjeneste dersom brukeren

ikke snakker kontinuerlig men sender korte talemeldinger eller dersom han sender

talemeldinger til flere andre brukere, for eksempel ved bruk i taxi-sentraler.[ 43]

På grunn av den relativt lave oppstrømshastigheten er ikke GPRS egnet til overføring av

videokonferanser. Streaming med innhold som er optimalisert (ved å benytte en

kodingsteknikk tilpasset GPRS) vil derimot være mulig på grunn av høyere hastighet ned

enn opp.



6.1.4 Enhanced Data for Global Evolution (EDGE)

EDGE er en utvidelse av GPRS som ble definert i 1997, men først nå begynner

operatører å tilby støtte for standarden i mobilnettene. Det ble også definert en EDGE

utvidelse av CSD i standarden, men denne delen har det vært lite fokus på og det er uvisst

om den vil bli satt i drift. GPRS utbygd med EDGE kalles EGPRS. Det benyttes samme

pakkehåndteringsprotokoller som GPRS, SGSN og GGSN, og det er kun oppdatering av

basestasjonene som må til for å gjøre nettet klart for EDGE. I Norge har Telenor planer

om å innføre EDGE i løpet av 2004, mens NetCom foreløpig ikke har offentliggjort noen

eventuell lanseringsdato. [44][45][46]

Den teoretiske maksimale overføringskapasiteten i hver tidsluke vil ved bruk av EDGE

tredobles i forhold til GPRS til opptil 59,2 kbps. Dette oppnås ved hjelp av en ny

moduleringsteknikk. Ved å benytte alle åtte tidsluker kan en oppnå 473,6 kbps. I praksis

vil hastigheten ligge på maksimum 48 kbps pr. tidsluke og gi en maksimumshastighet på

384 kbps ved åtte tidsluker. EDGE vil da ha omtrent like stor hastighet som UMTS vil ha

ved oppstarten, men teknologien har ikke det samme utvidelsespotensialet som UMTS.

Under normale forhold vil det være mulig å oppnå opptil 200 kbps.[44] [46]

GSM/EDGE Radio Access Network (GERAN) er en standard fra 3GPP for å koble seg til

UMTS nettverk fra EDGE. En vil da ha tilgang til IP Multimedia Subsystem (IMS) og de

samme tjenestene og QoS klassene som er definert for UMTS (beskrives i kapittel 6.1.5).

På steder hvor UMTS ikke er bygd ut vil EDGE kunne erstatte UMTS og dermed virke

som ett supplement til UMTS. [44]

Mulighetene for multimedia i EDGE vil være tilvarende GPRS, men bedre ved at EDGE

vil ha høyere hastighet og støtte for 3GPP tjenester som IMS. Dermed vil EDGE være

bedre egnet til SIP og multimedia, og gjøre det mulig med bl.a. videokonferanser.



6.1.5 Universal Mobile Telecommunication System (UMTS)

UMTS er en standard for tredje generasjons mobilkommunikasjonssystemer (3G). Målet

med UMTS er å kunne tilby avanserte mobile tjenester som multimediesesjoner, høye

dataoverføringshastigheter, samt global roaming. ETSI var ansvarlig for

standardiseringen av UMTS, mens det nå er Third Generation Partnership Project (3GPP)

som videreutvikler den tekniske spesifikasjonen. [47]

UMTS har tatt i bruk andre frekvenser enn GSM og også en annen kodingsteknikk:

Wideband Code Division Multiple Access (W-CDMA). UMTS Terrestrial Radio Access

Network (UTRAN) er radioaksessnett som tar seg av dette. [47]

Kjernenettet (CN) er delt opp i en linjesvitsjet og en pakkesvitsjet del. Den linjesvitsjede

delen har mye til felles med GSM og benytter Asynchronous Transfer Mode (ATM)

Adaptation Layer type 2 (AAL2), mens den pakkesvitsjede delen benytter mange av de

samme nettverkselementene som GPRS og AAL5. Med WCDMA blir det mulig å

benytte både den linjesvitsjede og den pakkesvitsjede delen samtidig. [42]

UMTS kan tilby en datahastighet på opptil 2 Mbps. Den maksimale hastigheten er

definert innenfor tre områder: [47]

- 144 kbps: grisgrendte strøk og steder hvor satellitter må brukes.

- 384 kbps: utendørs i byer og tettsteder.

- 2048 kbps: innendørs og ved liten bevegelse utendørs i byer.

UMTS har også definert fire tjenestekvalitets (QoS) klasser for dataoverføring (bærer

tjenesten): [47]

- Interaktiv: Interaktive sesjoner. For eksempel web browsing.

- Bakgrunn: Dataoverføring med lav prioritering. For eksempel filoverføring.

- Streaming: Kontrollert hastighet med lav forsinkelse. For eksempel musikk- og

videoavspilling.

- Samtale: Sanntid data, kontrollert hastighet og minimum forsinkelse. For

eksempel IP-telefoni og videokonferanse.



En av grunnene til at UMTS har blitt utviklet er muligheten for å kunne håndtere

avanserte multimedietjenester. I UMTS Release 1 til 4 (96-99) vil multimedietjenester

med sanntidskrav, som for eksempel videokonferanser, overføres over den linjesvitsjede

delen. 3GPP har standardisert 3G-H.324M protokollen, som brukes til linjesvitsjede

multimediesesjoner.[48] I tillegg til å tilby en ”best-effort” pakkesvitsjet tjeneste har

3GPP utviklet et multimediesystem som tilbyr ende til ende multimediesesjoner med

tjenestekvalitetsgaranti, kalt IP Multimedia Subsystem (IMS). Systemet ble definert i

UMTS Release 5 som ble fryst i 2002 og vil benytte SIP som signaleringsprotokoll. Det

vil også være mulig å bruke IP-tjenester over den pakkesvitsjede delen i Release 1 til 4,

men det vil være ved egne programmer og uten ende til ende tjenestekvalitetsgarantiene

som er definert for IMS. IMS må benytte IP versjon 6 (IPv6). Ved IMS innføres tre typer

Call State Control Function (CSCF) enheter i nettet for sesjonskontroll, som er vist i

Figur 6-1 ved oppsett av en sesjon:[49][ 50][ 51]

- Proxy-CSCF (P-CSCF): Tilsvarer en SIP Proxy-server og er SIP-klientens første

kontaktpunkt i nettet.

- Serving-CSCF (S-CSCF): Håndterer tilstandskontroll i nettet. Kan inneholde både

Registrar-, Proxy- og applikasjonsservere.

- Interrogating-CSCF (I-CSCF): En operatørs kontaktpunkt inn til nettet. Dette

gjelder for både operatørens kunder og for gjester som befinner seg i nettet.

Operatøren kan ha flere forskjellige I-CSCF’er. Disse vil finne riktige S-CFCS

som kan brukes.



Figur 6-1 Oppsett av sesjon ved IMS, med vist rekkefølge for sending av forespørsel. [51]

High Speed Downlink Packet Access (HSDPA) er en fremtidig utvidelse av W-CDMA.

HSDPA vil få en teoretisk maksimumshastighet på ca. 10Mbps, og vil være

bakoverkompatibel med W-CDMA.

6.1.6 Bredbånd

Bredbånd brukes som en samlebetegnelse for høyhastighetsoppkobling mot internett.

Uttrykket er ofte brukt om Digital Subscriber Line (DSL) teknologier som for eksempel

ADSL og SHDSL, men kan også være forbindelser ved kabelmodem, satellitt o.s.v.

Hvilke hastigheter som betegnes som bredbånd er imidlertid omdiskutert. I praksis

benyttes bredbånd om hastigheter som er vesentlig høyere enn ved ISDN (ca. 500 kbps

mot 64 kbps eller 128 kbps). DSL teknologiene er enten asymmetriske ved at de støtter

en lavere hastighet oppstrøms enn nedstrøms eller symmetriske med lik hastighet begge

veier. Fremover vil tilbudet av DSL teknologier bli utvidet med ADSL2, ADSL2+ og



VDSL, som støtter overføringshastigheter opp mot 52 Mbps. Tabell 6-1 viser en oversikt

over hastigheter og maks rekkevidde for de aktuelle DSL teknologiene.

Akronym Betydning Datarate

nedstrøms

Datarate

oppstrøms

Maks

rekkevidde

ADSL Asymmetrisk

DSL

0,5 – 8

Mbps

64 – 640

Mbps

5,5 km

SDSL Symmetrisk

DSL

128 kbps –

2,32 Mbps

128 kbps –

2,32 Mbps

3,7 km

SHDSL Single-pair

High speed

DSL

192 kbps –

2,3 Mbps

192 kbps –

2,3 Mbps

6,1 km

VDSL Very high

bitrate DSL

13 – 52

Mbps

1,6 – 2,3

Mbps

1,4 km

ADSL 2 Asymmetrisk

DSL 2

- 12 Mbps - 1 Mbps 5,5 km

ADSL 2+ Asymmetrisk

DSL 2+

- 24 Mbps - 3 Mbps 3 km

ADSL 2++ Asymmetrisk

DSL 2++

- 48 Mbps - 3 Mbps

Tabell 6-1 Hastigheter og maks rekkevidde for aktuelle DSL-teknologier [52][53]

Et alternativ til DSL-teknologiene er den trådløse bredbåndsstandarden WiMAX.

WiMAX er basert på IEEE standarden 802.16 og kan tilby en overføringshastighet på

opptil 50 Mbps og en maksimal rekkevidde på 70 kilometer. Som ved de fleste

bredbåndsteknologier får en heller ikke her maks hastighet dersom en befinner seg ytterst

i dekningsområdet. Denne standarden kan være et godt alternativ i grisgrendte strøk hvor

det ikke er lønnsomt å bygge ut DSL teknologier. [54]

For å benytte disse bredbåndsteknologiene betales det som regel en fast månedsavgift for

å få fri tilgang til internett.



Ved bredbånd vil brukerne få en stasjonær høyhastighetsforbindelse til internett. Denne

forbindelsen vil gjøre det mulig å bruke avanserte multimedieteletjenester. Tjenester som

”video on demand”, spill, musikkvideoer o.s.v. vil også bli mer aktuelt. Kvaliteten på

”fullskjerm” video vil ikke bli optimal med de laveste DSL hastighetene. Etter hvert som

nye DSL teknologier kommer, som for eksempel VDSL, vil ikke dette lenger være noen

flaskehals.

For å koble seg til bredbåndsaksesspunktet vil brukerne ofte benytte et LAN eller et

WLAN.

6.1.7 Wireless LAN (WLAN)

WLAN er et trådløst lokalnett. IEEE har utviklet WLAN standardfamilien 802.11, som

definerer det fysiske laget og link laget. De mest brukte 802.11 standardene er 802.11a,

802.11b og 802.11g. 802.11a benytter frekvenser på rundt 5 GHz mens de to sistnevnte

benytter frekvenser i 2.4 GHz området.

802.11b var den første standarden av disse tre. Den benytter Direct Sequence Spread

Spectrum (DDSS), tilbyr en overføringshastighet på opptil 11 Mbps og har en rekkevidde

på opptil 91 meter innendørs og 460 meter utendørs. [55]

802.11g regnes som en utvidelse av 802.11b da de benytter de samme frekvensene og

teknologiene er veldig like. Ved å bruke Orthogonal Frequency Division Multiplexing

(OFDM) støttes hastigheter på opptil 54 Mbps, men 802.11g kan også bruke DSSS for å

være bakoverkompatibel med 802.11b. Rekkevidden er lik som ved 802.11b. [55]

802.11a bruker tilsvarende 802.11g OFDM og støtter hastigheter på opptil 54 Mbps.

Rekkevidde for WLAN som bruker 802.11a standarden er inntil 91 meter innendørs og

3005meter utendørs. Standarden bruker andre frekvenser enn 802.11b og 802.11g, og er



derfor ikke kompatibel med disse. Det finnes imidlertid utstyr som støtter alle disse

standardene. [55]

Et WLAN kan settes opp hjemme eller i en kontorbygning og tilby aksess til et lokalt

nettverk. Aksesspunkt til WLAN er nå blitt rimelig (fra ca. 500 kroner), og når utstyret

først er kjøpt er selve bruken av WLAN’et gratis. For å koble seg til internett vil det

benyttes et annet nett som for eksempel en av bredbåndstypene fra forrige kapittel.

Det begynner også å bli utbredt med WLAN-soner hvor en kan logge seg på et

aksesspunkt der det er tilgjengelig. Dette kan for eksempel være fra hoteller, restauranter,

bensinstasjoner o.s.v. En kan da enten ha et abonnement hvor det betales en fast pris eller

en pris per datamengde som overføres, eller en kan kjøpe en forhåndsbetalt aksesstilgang

på for eksempel en dag eller en time.

WLAN vil gi god hastighet for multimedietjenester, men det er problemer med roaming

mellom WLAN nett. Dette gjør at en bruker kan miste forbindelsen når han beveger seg

fra et WLAN aksesspunkt til et annet. SIP løser dette ved å sende REGISTER og Re-

INVITE, men dette kan forårsake en liten forsinkelse. En annen teknologi som kan løse

roaming problemet er Mobil IP, hvor brukeren vil beholde IP adressen etter å ha skiftet

nettverk. Det arbeides også med å lage løsninger for roaming mellom WLAN og

mobilsystemer.

6.1.8 LAN

Et Local Area Network (LAN) benyttes for å koble sammen datamaskiner innenfor et

område. Ethernet standarden 802.3 har nesten blitt ensbetydende med LAN p.g.a. den

store utbredelsen av denne standarden. 802.3 standarden 100BASE-T, kalt Fast Ethernet,

er nå den mest vanlige standarden og støtter en hastighet på opptil100 Mbps. Den

raskeste av de tilgjengelige versjonene er 802.3a som støtter opptil 10 Gbps.[56]



I et LAN vil ikke datahastigheten være noen hindring for å sette opp multimediesesjoner,

men tilsvarende WLAN benyttes andre typer nett for å koble sammen LAN eller koble

seg til internett, og begrensningen vil som oftest ligge i disse nettene.

6.2 Terminaler I dette kapittelet vil forskjellige typer terminaler som er aktuelt å bruke i forbindelse med

et CallCenter studeres. Disse typene er delt inn i fem kategorier, men overganger mellom

de forskjellige terminaltypene er flytende. Det vil være fokus på hvilke aksessteknologier

som kan brukes og hvilke multimodalitets muligheter som finnes. Dette innebærer

muligheter for å presentere de forskjellige media som blir overført med

aksessteknologien og forskjellige typer input samt hvordan disse kan overføres. Det vil

også studeres hvilke SIP-applikasjoner som eksisterer for de terminaltypene hvor dette er

aktuelt. Alle terminalene som benytter EDGE og UMTS vil ”indirekte” ha støtte for SIP

dersom IP-sesjonene settes opp med IMS.

6.2.1 PSTN-terminal

PSTN-terminaler håndterer hovedsakelig talesamtaler. Disse kan enten benytte det

analoge telenettet, ISDN eller en leid linje. Det har vært vanlig å skille mellom terminaler

tilkoblet PSTN direkte og terminaler tilkoblet lokale sentraler, såkalte ”svarte” og ”grå”

terminaler. Terminaler tilkoblet lokale sentraler har ofte hatt noe mer funksjonalitet enn

enkeltstående terminaler direkte tilkoblet PSTN.

Avanserte ISDN terminaler kan ha mulighet for å håndtere videokonferanser ved å

kombinere flere D-linjer. Dette vil som regel være enheter laget kun for videokonferanser

og som benytter H.320 protokollen.

6.2.2 Mobiltelefon

Mobiltelefoner har til nå vært GSM-terminaler med støtte for relativt enkle tjenester som

tale og SMS. Med støtte for GPRS har mobiltelefonene fått større muligheter til å bruke



tjenester som internett, WAP og MMS. Ved innføringen av EDGE og spesielt UMTS vil

det i framtiden bli bedre muligheter for å håndtere avanserte multimedietjenester som

videokonferanser og streaming med mobiltelefoner.

Det har i det siste blitt laget stadig mindre mobilterminaler samtidig som de har fått mer

funksjonalitet, som bl.a. større skjermer med farger, kameraer med både foto og video

muligheter, kraftigere prosessorer og mer minne. Telefonene vil ikke nødvendigvis bli

mindre, men kan få rikere muligheter for input og output. Eksempler på dette kan være at

enheten får større tastatur eller at skjermen kan være trykkfølsom. Trykkfølsomme

skjermer gjør at brukeren kan trykke på ikoner og i mange tilfeller at telefonen kan tolke

håndskrift. Dette vil gjøre det mulig å benytte flere modaliteter, for eksempel ved at

mobiltelefonene kan vise og ta opp video, og at det blir mulig å styre den med

talekommandoer eller håndskrift.

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.



Mobiltelefonene har etter hvert utviklet seg til avanserte enheter hvor en kan installere

egne programmer. Det er da viktig at programmene som utvikles kan benyttes på flere

ulike telefoner. For at dette skal bli lettere er det en tendens til at mobilselskapene

begynner å bruke standard operativsystemer istedenfor å utvikle sine egne. Flere av de

største mobilselskapene, som Nokia, Sony Ericsson, Siemens og Samsung, har gått

sammen om å utvikle Symbian til ett felles operativ system for sine telefoner. Microsoft

har også utviklet et operativsystem for mobiltelefoner som kalles Smartphone, og har

designet referansemodeller for disse enhetene som mobilselskaper kan benytte for å

utvikle Smartphone-enheter. Qtek (som også produserer HP Ipaq) har levert de fleste

Smartphone-enhetene til nå. Disse selges ofte under operatørnavn, noe bl.a. Orange har

gjort. Også mer tradisjonelle mobiltelefonselskaper som for eksempel Motorola utvikler

Smartphone-enheter. Ved å benytte standardiserte operativsystemer vil det bli et større

marked for å utvikle tredjeparts programmer til disse enhetene, som også kan bidra til at

utviklingsvektøyene vil bli bedre.

De fleste mobiltelefoner har støtte for å installere Java-applikasjoner, oftest som en

Mobile Information Device Profile (MIDP) applikasjon. MIDP benyttes sammen med

Connected Limited Device Configuration (CLDC) for å tilby et høynivå API for

mobilenheter, med bl.a. brukergrensesnitt og nettverksfunksjonalitet. Disse benytter igjen

Java 2 Platform Micro Edition (J2ME), som er en nedskalert versjon av desktop-

versjonen (J2SE) tilpasset forbrukerenheter.[57][58] Mange nye mobilenheter støtter nå

MIDP versjon 2.0 og har mulighet for ”socket” kommunikasjon. Disse enhetene vil

kunne håndtere SIP-sesjoner direkte (UMTS og EDGE kan benytte SIP ved IMS) ved å

kjøre en nedskalert versjon av JAIN SIP kalt JAIN SIP Lite (JSR 125). National Institute

of Standards and Technology (NIST) er nå i gang med å lage en implementasjon av JAIN

SIP Lite grensesnittet som de kaller NIST-SIP Port to J2ME MIDP 2.0, og som er lansert

i en ALPHA versjon. [10][20]



6.2.3 Håndholdt datamaskin

Håndholdte datamaskiner har tradisjonelt vært enheter som er noe større enn

mobiltelefoner og med kraftigere prosessorer, større og trykkfølsomme skjermer og med

mulighet for WLAN enten innebygd eller i form av et utvidelseskort. Skillet mellom

disse to typene er i ferd med å bli uklart, da de håndholdte enhetene kan ha støtte for

GSM og GPRS, og mobiltelefonene får kraftigere prosessorer og kan ha trykkfølsomme

skjermer.

Figur 6-3 Pocket PC 2003 enheten HP Ipaq 4150 og den Palm OS baserte Sony CLIE PEG-UX50.

Palm har lenge vært standarden for håndholdte enheter, men har i de senere årene fått

sterk konkurranse fra Microsoft-baserte Pocket PC’er fra store selskaper som for

eksempel HP, Dell, Toshiba og Fujitsu Siemens. Palm har på grunn av dette delt opp

selskapet i palmsource og palmOne. palmsource utvikler operativsystemet til enhetene,

mens palmOne utvikler selve enhetene. Dette ble gjort i et forsøk på å øke bruken av

systemet ved at andre selskaper skal kunne utvikle enheter som benytter Palm

operativsystemet.

Ved at håndholdte enheter kan bruke WLAN til å koble seg på internett vil terminalene få

god støtte for å benytte avanserte multimedieteletjenester. Det kan også være aktuelt å

bruke GSM eller GPRS for å koble seg til internett enten i form av en innebygd modul, et



utvidelseskort eller ved å koble til en mobiltelefon via IR eller Bluetooth. Mulighetene

for multimedieteletjenestene vil da bli mer begrenset (som beskrevet i kapitlene 6.1.2 og

6.1.3). Ved at de håndholdte enhetene har relativt stor skjerm sammenlignet med

mobiltelefoner har de i utgangspunktet bedre muligheter for å håndtere multimodalitet.

Input til enhetene kan være ved en trykkfølsom skjerm, en mikrofon, kameraer eller et

fysisk- eller softwarebasert tastatur.

Microsoft-baserte Pocket PC’er kommer med Messenger-programmet forhåndsinstallert,

men Pocket PC-versjonen har i motsetning til PC-versjonen ikke støtte for SIP. Dette vil

sannsynligvis komme i en fremtidig utgave. Microsoft Research har imidlertid utviklet

programmet Portrait for Pocket PC som støtter SIP. Programmet støtter både

tekstmeldinger, IP-telefoni og videokonferanser. [59] Palm enheter blir vanligvis ikke

levert med en SIP-klient, men det er mulig å installere tredjeparts SIP klienter som for

eksempel PalmGphone. [60] Det finnes i dag ingen JAVA VM’er som kjører J2SE på

håndholdte enheter, men for både Pocket PC’er og Palm-baserte enheter finnes det J2ME

VM’er. Disse er kompatible med CLDC 1.0 og MIDP 1.0. JAIN SIP Lite versjonen må

da benyttes for å utvikle applikasjoner ved JAIN SIP. [61][62][63]

6.2.4 PC

En PC kan brukes som en avansert telefon med gode muligheter for multimediesesjoner

og multimodal brukerinteraksjon. Nærmest alle former for input og output kan kobles til

en PC, og de har ofte stor nok skjerm til å håndtere gode brukergrensesnitt og video med

høy oppløsning.

Det er vanlig å skille mellom stasjonære og bærbare PC’er. Stasjonære PC’er står fast på

et sted eller flyttes en sjelden gang ved å skru av maskinen, flytte den og starte den opp

igjen. Stasjonære PC’er kan i prinsippet bruke alle mulige aksessteknologier ved å bruke

utvidelsesenheter eller trådløse forbindelser mot mobile enheter. Det mest aktuelle vil

være å koble den til et LAN som igjen er koblet til internett, fordi LAN er en stasjonær

teknologi med høy hastighet. Bærbare PC’er kan flyttes rundt mens de brukes. Også



bærbare PC’er kan benytte alle aksessteknologiene som er studert i denne oppgaven, men

det vil være mest interessant å se på mulighetene ved mobile og trådløse nett. Maskinen

kan da flyttes mens en sesjon pågår. Ved trådløse nettverk kan da Mobil IP benyttes for å

beholde sesjoner når enheten skifter fra et nettverk til et annet (som nevnt i kapittel 3.8 og

6.1.7). Roaming mellom mobile og trådløse nett er også et aktuelt tema som er under

utforskning.

De aller fleste PC’er kan kjøre en J2SE VM som vil gjøre det mulig å benytte JAIN SIP-

grensesnittet og applikasjoner basert på dette.

Det finnes nå flere programvarebaserte SIP-klienter til PC, såkalte SoftPhones. De mest

aktuelle som er testet i forbindelse med denne oppgaven er:

- MS Windows Messenger: versjon 4.6 og 5.0. 4.6 har ikke støtte for REFER.[64]

- MS Portrait: Har god SIP støtte.[59]

- SIP Communicator: Støtter foreløpig ikke MESSAGE og REFER. Beskrives i

kapittel 8.2.2.1. [8]

- Xten Pro: Støtter ikke videosesjoner. [65]

6.2.5 SIP-telefon

Det lages egne telefonapparater for SIP og disse kan sammenlignes med tradisjonelle

telefonapparater som blir laget for bruk i PSTN. SIP-telefonene vil være mer avanserte

med mulighetene som SIP åpner for, og vil være koblet til en internettforbindelse

istedenfor PSTN. SIP-telefoner kan dessuten også være trådløse ved å benytte et WLAN.



Figur 6-4 Eksempel på SIP-telefon fra Pingtel [66]

6.2.6 Terminalmuligheter

Der det før var klare skiller mellom forskjellige enheter begynner disse å bli uklare.

Skillene vil sannsynligvis bli mer uklare framover, ved at terminaler får støtte for flere

forskjellige typer aksessteknologier og får flere muligheter for input og output. Mobile

enheter får mer funksjonalitet og prosesseringskraft, og en kan da få tilgang til de fleste

tjenester fra en liten terminal. Disse terminalene kan da hele tiden bruke den

aksessteknologien og de modalitetene som er optimal for tjenestene brukeren benytter, og

automatisk veksle mellom disse. Et eksempel kan være at en bruker deltar i en

videokonferanse over UMTS på vei til jobb. Når han ankommer kontoret vil terminalen

automatisk bytte over til WLAN (som sannsynligvis vil være billigere og ha høyere

overføringshastighet) og få skjermbildet vist på en større stasjonær skjerm.

Kapittel 7 - Sammenligning og integrasjon 58


7. Sammenligning og integrasjon

I dette kapittelet vil Parlay, SMIL og SIP bli sammenlignet og muligheter for integrasjon

mellom disse teknologiene vil bli diskutert. Andre standarder som kan være aktuelle for å

integrere PSTN og IP-nett vil også diskuteres kort.

7.1 Sammenligning SIP er en signaleringsprotokoll for å sette opp og kontrollere sesjoner, altså definisjonen

på selve protokollen og hvordan denne skal benyttes. Ved hjelp av SIP vil det bl.a. være

mulig å styre talesesjoner i IP-nett som tradisjonelt kun har vært tilgjengelig i

linjesvitsjede nett.

Parlay er en gruppe som tilbyr standardiserte grensesnitt mot nettverkselementer for å

styre telenettet. Tjenestene utviklet med Parlay grensesnittet er basert på

samtalehåndtering av vanlig linjesvitsjede nett, som PSTN eller GSM nett, men også

meldingstjenester som SMS og MMS. Det vil også bli mulig å lokalisere terminaler med

Parlay grensesnittet. Parlay definerer ingen protokoller, men bruker ulike protokoller

avhengig av tjeneste og underliggende lag. Disse protokollene skjules for utvikleren, som

dermed kun får tilgang til et grensesnitt som skal benyttes. Parlay er forsøk på å gjøre

funksjoner i telenettet mer tilgjengelig for utviklere.

Parlay grensesnittet JAIN SPA kan sammenliknes med JAIN SIP grensesnittet. JAIN SIP

er derimot et grensesnitt kun beregnet for SIP. En må ha relativt god innsikt i hvordan

SIP protokollen virker for å kunne utvikle JAIN SIP applikasjoner. For eksempel må

utvikleren håndtere SIP-headere og meldinger direkte. JAIN SPA ligger på et høyere nivå

og kan tilby flere ulike tjenester, og kan også få mulighet til å håndtere SIP-sesjoner

gjennom Multi-Media Call Control modulen.

SMIL er et interaktivt presentasjonsformat og vil som oftest benyttes for å presentere

informasjon, i form av mediefiler, fra et system til en bruker. SIP og Parlay egner seg

godt til å kontrollere sesjoner, noe SMIL vil ikke kunne gjøre.



7.2 Integrasjon I lang tid fremover vil det være noen som benytter PSTN og noen som benytter IP-nett til

telefonitjenester. For at det skal være praktisk mulig å innføre IP-telefoni, må disse

systemene kunne snakke sammen.

Figur 7-1 Oversikt over integrasjon av PSTN og IP-nett med signalering, media og gateway [2]

Parlay vil som sagt gjøre det mulig å kontrollere SIP-sesjoner ved Multi-Media Call

Control. Parlay-gatewayen bør da kunne oversette mellom signalering og media i PSTN

og IP-nett, enten i Parlay-gatewayen eller ved å benytte en dedikert PSTN/SIP gateway.

En annen mulighet er å lage en kontrollerapplikasjon som styrer både en Parlay-gateway

og en SIP-server og som kobler sesjoner fra de ulike nettene til en PSTN/SIP gateway

dersom det er behov for dette. For eksempel kan et CallCenter ha agenter både i PSTN og

IP-nettet. Dersom alle agentene på PSTN nettet er opptatt og det kommer en ny kunde på

dette nettet, kan kontrollerapplikasjonen styre denne samtalen til en PSTN/SIP gateway

og kobles til en SIP-agent. Ved begge tilfellene må det være PSTN/SIP gatewayen som



håndterer oversettelsen av både signalering og mediestrømmer (som beskrevet i kapittel

3.5.2).

Gatewayen vil oversette signaleringen fra PSTN- til SIP-meldinger og motsatt. Ved

ISDN vil dette være fra ISDN User Part (ISUP) eller Channel Associated Signaling

(CAS) Tabell 7-1 definerer oversettelsen mellom SIP-, ISUP- og ISDN-meldinger og

parametere. Noen meldinger og parametere vil mistes i denne oversettelsen da det ikke

finnes noen tilsvarende melding i det andre signaleringssystemet. Dersom en samtale

rutes fra ISDN til SIP og så tilbake til ISDN kan nyttige parametere mistes. SIP

Telephony (SIP-T) løser dette ved å overføre ISDN signaleringen i SIP meldinger som

MIME vedlegg, som så kan generere de opprinnelige ISDN meldingene i SIP til ISDN-

gatewayen. En ulempe er at SIP-T viderefører den relativt kompliserte signaleringen fra

ISDN som en egentlig ikke vil ha med seg over i IP-domenet. Figur 7-2 viser et eksempel

på oppsett og terminering av en samtale ved bruk av en ISDN (ISUP) til SIP-gateway.[2]

SIP-melding eller respons ISUP-melding ISDN-melding

INVITE IAM eller SAM Setup

INFO USR User

BYE REL Release

CANCEL REL Release

ACK - -

REGISTER - -

18x ACM eller CPG Alerting

200 til INVITE ANM eller CON Connect

200 til BYE RLC Release Complete

4xx, 5xx, 6xx REL Release

Tabell 7-1 Oversetting mellom SIP-, ISUP- og ISDN-meldinger og parametere [2]



IAM

ACM

ANM

RLC

REL

RTP MedieSession

INVITE

180 RINGING

200 OK

ACK

200 OK

BYE

GatewayPSTN-svitsj SIP-klient

One-way speech

100 TRYING

Two-way speech

Figur 7-2 Meldingsdiagram for PSTN (ISUP) til SIP-gateway [2]

I PSTN benyttes vanligvis 64-kbps pulse-coded modulation (PCM) kodet tale. For å

overføre tale til et IP-nett må gatewayen kode om mediestrømmen fra PCM til et

passende format som gatewayen og SIP-klienten blir enige om, og deretter sette opp en

RTP-forbindelse til SIP-klienten. Det er også mulig å sende mediestrømmen direkte uten

å kode dem om ved å benytte RTP/AVP (Audio Video Profile) 0. Dersom det skal settes

opp en sesjon fra IP-telefoni til PSTN må sesjonen inneholde lyd, og eventuelle andre

medier vil bli fjernet.



Det må være mulig å ringe et vanlig nummer fra en SIP-telefon og bli overført til

telenettet og motsatt. For at det skal være mulig å ringe en SIP-telefon fra PSTN må det

lages en forbindelse med et ”vanlig” E.164 nummer til SIP-adressen, slik at det er mulig

å komme frem til SIP-adressen fra en telefon med kun siffertaster. Dette gjøres i en PSTN

til SIP-gateway ved å benytte DNS med topp domenet e164.arpa som beskrevet i RFC-

2916 [33].

Ved å benytte en SIP til PSTN-gateway må adressen være på formen;

sip:telefonnummer@operatørgateway, som for eksempel: sip:[email protected].

Operatørgatewayen trenger ikke å angis spesifikt, for en kan eventuelt bruke en SIP

proxy-server som igjen finner en gateway.

Når det blir mange forskjellige gatewayer som kan terminere en IP-telefoni samtale i

PSTN nettet vil det bli behov for store rutingtabeller i SIP. Telephony Routing over IP

(TRIP) er en protokoll for å finne den beste gatewayen å terminere en samtale fra et IP-

nett til et PSTN. Protokollen er basert på IP Border Gateway Protocol (BGP) og dermed

designet for å skalere. TRIP benyttes også ofte dersom en samtale fra et PSTN til et annet

PSTN rutes via et IP-nett. [2][34][35]

Både Parlay og SIP kan benytte SMIL til å presentere innhold. Parlay benytter allerede

SMIL, ved at Parlay kan sende og motta MMS-meldinger som er basert på SMIL

standarden. Det vil også være mulig å sende SMIL som vedlegg i SIP-protokollen. Dette

kan for eksempel gjøres ved å legge SMIL-filen som vedlegg i INFO-metoden. Det kan

også være aktuelt å benytte SIP-lenker i ett SMIL-dokument. Dette kan for eksempel

være at en kan trykke på et bilde i en SMIL-presentasjon for å sette opp en SIP-sesjon.

7.3 Andre standarder for integrasjon av IP og PSTN I tillegg til integrasjonsmulighetene som er beskrevet tidligere finnes det andre

teknologier for å integrere PSTN og IP-nett. To aktuelle standarder er PINT og SPIRITS,

som vil introduseres kort i dette kapittelet.



7.3.1 PSTN and INTerworking (PINT)

PINT er en IETF standard for å initiere PSTN tjenester fra Internet, som for eksempel

”click to call”. PINT benytter en utvidelse av SIP definert i RFC 2848 [37]. Dette er

egentlig en utvidelse av SDP for å benytte PINT, men SIP meldingene vil også ha noe

annen mening enn i ”vanlig” SIP. For eksempel vil en INVITE melding fra en PINT-

klient til en PINT-server ikke sette opp en samtale til PINT-klienten, men sende en

forespørsel til serveren om å sette opp en forbindelse mellom to andre telefoner (som vist

i Figur 7-3). PINT serveren vil da sette opp sesjonen ved å benytte Service Support

Transfer Protocol (SSTP) mot elementene i telenettet. [36][2]

Figur 7-3 Modell over PINT [2]

7.3.2 Servers in the PSTN Initiating Requests to InTernet Servers (SPIRITS)

SPIRITS er IETF’s standard for forespørsler som går motsatt vei av PINT, d.v.s. at

hendelser i PSTN nettet initierer hendelser i internett. SPIRITS er også basert på SIP

signalering. [39]

SPIRITS gjør det mulig å styre IN-tjenester via internett. Et eksempel er når en person

benytter telefonlinjen til å koble seg på internett og noen prøver å ringe personen. Det kan

da være mulig å gi brukeren beskjed om dette over internett og han kan bestemme

hvordan samtalen skal håndteres. Brukeren kan da for eksempel få valget mellom å koble

ned internettforbindelsen og besvare samtalen eller å viderekoble samtalen til en

telefonsvarer. Denne teknologien vil være mest aktuell dersom en har PSTN aksessnett

med en linje eller eventuelt med flere linjer hvor alle ofte er i bruk.[38]

Kapittel 8 - CallCenter-løsning 64


8. CallCenter-løsning

I dette kapittelet vil det bli spesifisert og designet deler av en CallCenter-løsning som

benytter SIP. Dette vil bli gjort med utgangspunkt i en spesifisert eksempeltjeneste. For å

designe enkelte av SIP-enhetene er det tatt utgangspunkt i en åpenkildekodebasert klient

som vil bli beskrevet. Den designede løsningen er implementert og ligger på vedlagt CD.

Installasjons beskrivelse er vedlagt i: Vedlegg 1 Installasjonsbeskrivelse.

8.1 Spesifikasjon CallCenter-løsningen skal være en løsning hvor sesjonskontrollen vil være basert på SIP.

Den delen av CallCenteret som vil bli lagt mest vekt på i denne oppgaven er den delen av

en CallCenter-server som setter opp og kontrollerer multimediesesjoner. Løsningen skal

implementeres i Java, ved bruk av JAIN SIP grensesnittet.

Hovedenhetene i en CallCenter-løsning vil være en CallCenter-server, agentklienter og

kundeklienter. Figur 8-1 viser en oversikt over disse enhetene samt signaleringen mellom

dem. Det vil som regel være flere agenter logget på CallCenter-serveren og flere

samtidige kunder som blir behandlet av CallCenteret.

SIP

SIP

CallCenter-domeneKundedomene

Kundeklient CallCenter-server

Agentklient

Figur 8-1 Hovedenheter i en CallCenter-løsning.



I denne løsningen er det ikke sett på integrasjon mot Parlay og PSTN, da det ikke har

vært noen gateway tilgjengelig for å teste dette.

8.1.1 Supporttjeneste

For å demonstrere mulighetene for multimedia og multimodalitet i et CallCenter vil

denne løsningen baseres på et eksempel med en supporttjeneste.

Når en kunde kobler seg til CallCenteret vil han få se videoer med informasjon og

valgmuligheter som i en meny. Dersom kunden ikke har støtte for- eller ikke ønsker å få

spilt av videofiler vil det være mulig å få spilt av kun lydfiler tilsvarende en IVR. Kunden

kan da gjøre valg ved å skrive inn valgene og sende dem som SIP-tekstmeldinger.

Valgene vil i dette eksempelet være tall, men det kunne også være en vilkårlig definert

tekst, som for eksempel et produktnavn. Figur 8-2 viser strukturen på menyen.

Menysystemet vil være fleksibelt ved at hvert menyelement kan inneholde en mediefil og

eventuelt kobles til et nummer og en ny meny som kunden kan velge. Dybden på menyen

kan dermed variere etter hvilke valg om blir gjort.

Velkommen til kundesupportSend 1 for produkt ASend 2 for produkt B

…Send 9 for personlig betjening

Send 1 for feil ASend 2 for feil B

…Send 9 for personlig betjening

Send 0 for å gå tilbake til forrige meny

FeilrettingSend 9 for personlig betjening

Send 0 for å gå tilbake til forrige meny

Figur 8-2 Eksempel på menystruktur



Kunden har mulighet for å bli satt over til en agent for personlig betjening i de menyene

der det er et alternativ. Dersom kunden velger dette og det finnes ledige agenter vil det

settes opp en forbindelse til en agent. Ved eventuell kø, vil det spilles av mediefiler som

er definert for køen mens kunden venter. Dersom det ikke er noen agenter logget på

CallCenteret vil kunden få melding om dette og bli satt tilbake til menyen han var i.

Kundens sesjon mot CallCenteret avsluttes når en av partene kobler ned forbindelsen.

8.1.2 CallCenter-server

CallCenter-serveren vil bestå av tre hoveddeler: en SIP-server, en interaktiv medieserver

og en kontrollenhet. SIP-serveren må inneholde en Registrar-server og en Proxy-server.

Medieserveren og agentklientene vil registrere seg på Registrar-serveren. Proxy-serveren

vil videresende SIP-meldinger. Medieserveren skal ta imot forespørsler fra kunder og

spille av de mediefilene som styringsenheten bestemmer. Medieserveren sender videre de

valgene kunden gjør til kontrollenheten som behandler disse, og instruerer medieserveren

i henhold til kontrollenhetens logikk. Dersom kunden velger å bli satt over til en agent vil

kontrollenhet koble ned forbindelsen mellom kunden og medieserveren, og sette opp en

forbindelse mellom kunden og en agent.

Kontrollenheten vil være basert på prosjektoppgaven: ”Call Center in Amigos” [30], men

må tilpasses til både et nytt signaleringssystem og et nytt eksempel. Denne vil holde

kontrollen over tilstanden kundene og agentene befinner seg i, og handle i henhold til

dette.

8.1.3 Agentklient

For å kunne ha tale- og videosesjoner med en kunde, må agentklientene vil være en SIP-

klient som støtter multimedia. Denne klienten må varsle kontrollenheten om hendelsene

som gjør at agentens tilstand endres. Dette vil være når agenten logger inn eller ut av

klienten, og ved mottak eller nedkobling av en sesjon.



8.1.4 Kundeklient

Forskjellige SIP-klienter som kundene kan benytte er studert, men det er ikke lagt vekt på

å utvikle noen egen CallCenter-klient. Dette er fordi en CallCenter-løsning i fremtiden

burde kunne virke med de aller fleste SIP-klienter.

Kundeklienten i denne løsningen må ha støtte for å sette opp en video- eller talesesjon for

å kunne kommunisere med medieserveren eller en agent. For å gjøre valg i medieserveren

må det være støtte for sending av SIP-metoden MESSAGE, og for å kunne bli

viderekoblet til en agent dersom kunden velger dette må klienten ha støtte for SIP-

metoden REFER.

8.2 Design I dette kapittelet vil det designes en løsning for CallCenteret som spesifisert i kapittel 8.1.

Figur 8-3 er en utvidelse av Figur 8-1 med de tre spesifiserte enhetene i CallCenter-

serveren tegnet inn. I tillegg vil kunden som regel benytte en Registrar og Proxy SIP-

server i sitt domene. Når kunden setter opp en sesjon mot CallCenteret kan

signaleringsveien gå gjennom flere SIP Proxy-servere. I figuren er det tegnet inn en SIP-

server i kundens domene. Mediestrømmene som settes opp vil først være mellom kunden

og den interaktive medieserveren, og så eventuelt mellom kunden og en agent. Disse

mediestrømmene vil benytte RTP-protokollen. Kommunikasjonen med kontrollenheten

vil foregå ved Web Services, da dette er en standardisert protokoll som er uavhengig av

operativsystem, programmeringsspråk og utviklingsverktøy. Dette gjør det enkelt å skifte

ut en enhet i CallCenter-løsningen dersom spesifikasjonen for enheten endres. Alle

forbindelsene i løsningen vil benytte Internett Protokollen (IP) for overføring av data.



SIP

RTP Media

RTP Media

SIP

SIP

SIP

CallCenter-domeneKundedomene

WS

WS

Kundens SIP-serverKundeklient CallCenter SIP-server

Medieserver

Agentklient

Kontrollenhet

Figur 8-3 Overordnet struktur av CallCenter løsningen.

8.2.1 SIP-meldingsdiagrammer

Signaleringen mellom enhetene i systemet skal benytte SIP-protokollen. Med bakgrunn i

eksempelet som er definert og RFC’ene som omhandler SIP skal systemets SIP

signalering være som vist i sekvensdiagrammene, Figur 8-4 og Figur 8-5. Operasjonene

og Web Service kallene vil beskrives nærmere under hver enhet i de neste kapitlene.

Medieserveren må først logges på CallCenterets SIP-server. Deretter kan agenter logge

seg på kontrollenheten og SIP-serveren. De må logge på SIP-serveren ved å sende en

REGISTER-melding som beskrevet i kapittel 3.4.1, slik at SIP-serveren vet hvor de skal

videresende meldingene til enhetene. Agentene må i tillegg logges på kontrollenheten slik

at kontrollenheten vet hvilke agenter som er tilgjengelig. For agentene vil dette gjøres

samtidig, slik at agentene kun logger inn en gang.



Figur 8-4 viser første del av sekvensdiagrammet hvor en kunde kobler seg til

CallCenteret. Kunden vil først prøve å sende en INVITE til medieserveren via kundens

og CallCenterets SIP server. Da kundens SIP server krever autentisering vil kunden få

responsen Proxy Authentiacation Required med en utfordring tilbake. Kunden svarer på

denne med en ACK og så en ny INVITE med en Proxy-Authorization header som

inneholder autoriseringsinformasjon. Medieserveren vil da svare med responsene

TRYING, RINGING og OK. Ved at kundeklienten bekrefter OK responsen med en ACK

blir mediesesjonen satt i henhold til medieparameterne utvekslet i meldingene.

Kunden vil da få spilt av mediefiler, og kan gjøre valg ved å sende en MESSAGE som

medieserveren vil besvare med OK. Medieserveren vil da kalle kontrollenhetens Web

Service metode returnNumber med nummeret som kom i meldingen. Kontrollenheten

prosesserer det returnerte nummeret og instruerer medieserveren til å spille av nye filer

gjennom medieserverens Web Service metode play. Dette vil være mulig helt til kunden

legger på ved å sende en BYE melding eller eventuelt velger å bli satt over til en agent

for personlig behandling.

SIP-meldingene ligger i: Vedlegg 3 SIP-meldinger.



Call

Media Server AgentKundeklient Call Center SIP server

100 TRYING

INVITE

INVITE

100 TRYING

180 RINGING

180 RINGING

200 OK

200 OK

ACK

ACK

Media session

MESSAGEMESSAGE

200 OK200 OK

Loop(0,*)

Kundens SIP server

INVITE

ACK

100 TRYING

180 RINGING

200 OK

MESSAGE

200 OK

INVITE


ACK

alt

200 OK200 OK

200 OK

BYE BYEBYE

Ref Transfer

Figur 8-4 SIP-meldingsdiagram Call



Dersom kunden velger å bli satt over til en agent, vil kontrollenheten kalle

medieserverens Web Service metode refer istedenfor play. Medieserveren vil da sende en

REFER-melding med SIP-adressen til riktig agent. Kundeklienten svarer med OK og

forbindelsen kobles ned ved å sende BYE. Kundeklienten vil da koble seg til agenten ved

å sende en INVITE til SIP-adressen den fikk returnert. Denne sesjonen vil bli satt opp på

tilsvarende måte som når kunden koblet seg til medieserveren. Kunden og agenten vil da

bli enige om å sette opp en sesjon, som avsluttes når en av partene sender BYE.



Transfer

Media Server AgentKundeklient Call Center SIP server

REFER

Kundens SIP server

BYEBYE

BYE

Media session

200 OK

200 OK200 OK

REFERREFER

100 TRYING

INVITE

INVITE

100 TRYING

180 RINGING

180 RINGING

200 OK

200 OK

ACK

ACK

INVITE

ACK

100 TRYING

180 RINGING

200 OK

INVITE


ACK

200 OK200 OK

200 OK

200 OK200 OK

200 OK

BYEBYE

BYE

Figur 8-5 SIP-meldingsdiagram Transfer



8.2.2 JAIN SIP Applikasjoner

Det finnes åpen kildekode SIP-servere og klienter som benytter JAIN SIP. Disse skal

virke med alle SIP-stakker som implementerer JAIN SIP.

National Institute of Standards and Technology (NIST) har utviklet en implementasjon av

JAIN SIP 1.1, kalt NIST SIP. Denne SIP stakken er standard SIP 2.0, og gjør at

applikasjoner som bruker denne stakken vil kunne kommunisere med alle andre SIP

enheter som støtter SIP 2.0, som for eksempel MS Messenger. I CallCenter-løsningen vil

NIST SIP versjon 1.2 benyttes i medieserveren og i agentklientene.

8.2.2.1 SIP Communicator

SIP Communicator er en SIP multimedieklient implementert i Java. Den benytter JAIN

SIP og Java Media Framework (JMF). Klienten har mulighet for å sette opp tale- og

videosesjoner ved å benytte mediestrømmer og RTP-protokollen. Den har også støtte for

å håndtere flere samtidige sesjoner. Klienten er under utvikling og blir kontinuerlig

oppdatert med støtte for nye funksjoner. MESSAGE- og REFER-metodene er foreløpig

ikke implementert. Denne klienten vil brukes som utgangspunkt for både medieserveren

og agentklientene i CallCenter-løsningen. [8]



Figur 8-6 SIP Communicator – applikasjons design [7]

Figur 8-6 viser klientens overordnede design inkludert de tre hovedenhetene for å

håndtere SIP kommunikasjon ved JAIN SIP, media ved JMF og ett brukergrensesnitt

(GUI) ved Java Swing. Hovedklassen i SIP Communicator klienten er SipCommunicator.

Den oppretter en SipManager, MediaManager og GUIManager for å håndtere de

respektive delene.

Figur 8-7 JAIN-SIP – brukeragent klient [7]



Figur 8-7 viser hovedkomponentene i SIP Communicator for å håndtere SIP-sesjoner, og

ett eksempel på hvordan en SIP-melding blir sendt. I dette tilfellet opprettes en

transaksjon som det sendes en INVITE-forespørsel med. SipManager består av en

Processor Pool gruppe for å håndtere SIP-meldinger. JAIN SIP grensesnittet benyttes for

å opprette en SIP stakk samt SIP meldinger, headere og adresser, som beskrevet i kapittel

3.12.

Figur 8-8 JAIN SIP – brukeragent server [7]

Figur 8-8 viser hvordan en melding mottas av klientens serverdel. Mottak av en INVITE

melding vil sende responsen Ringing tilbake og deretter varsle brukeren via GUI’en om

at det er en innkommende sesjonsforespørsel. OK-responsen vil ikke bli sendt før

brukeren trykker på Answer knappen i GUI’en.



8.2.2.2 JAIN SIP Server

NIST Proxy/Registrar/Presence Server er en åpen kildekode standard SIP-server basert på

JAIN SIP. Denne vil benyttes som SIP-server i CallCenter-løsningen uten endringer.

Serverens Registrar vil brukes for å registrere medieserveren og agentene slik at SIP-

meldingene kommer frem til riktig IP-adresse. Proxy delen vil kun videresende

meldinger, mens Presence-delen ikke vil i brukt i eksempelet som er definert for denne

CallCenter-løsningen. [21]

8.2.3 Kontrollenhet

Kontrollenheten bygger på prosjektoppgaven: ”Call Center in Amigos” [30]. Opprinnelig

kommuniserte denne med en IVR, en Parlay-gateway og agenter. Kommunikasjonen med

Parlay-gatewayen holdt kontrollen over den linjesvitsjede samtalen som først var mot

IVR’en og eventuelt mot en agent. Agentene som var logget på kommuniserte med

kontrollenheten gjennom Amigos systemet. Amigos (Advances Multimedia In Group

Organized Services) er en tjeneste plattform hvor brukere kan skape møteplasser med

diverse funksjonalitet og tilpasset aksess som utvikles på PATS labben.[72]

Ved å benytte SIP vil det ikke være behov for noen enhet tilsvarende Parlay-gatewayen,

fordi medieserveren og agentene selv vil behandle signaleringen ved SIP-meldinger.

Amigos systemet kunne godt ha vært valgt også i dette tilfellet for kommunikasjonen

mellom kontrollenheten og agentene, men da måtte agentklientene også ha vært en

Amigos klient. For å få et standardisert grensesnitt er det valgt å bruke et Web Service

grensesnitt.

Kontrollenheten benytter ActorFrame-rammeverket. Ideen med dette rammeverket er at

aktører opprettes og spiller roller. Aktørene er objekter med en tilstandsmaskin og

eventuelt indre aktører som opererer i parallell. Disse aktørene kommuniserer med

hverandre ved å sende asynkrone Java Message Service (JMS) meldinger. En aktør kan

starte et play men en annen aktør ved å sende en role request message. Hver aktør har en



unik adresse som består av et aktørnavn og en aktørtype. For mer informasjon om

ActorFrame rammeverket henvises det til Melby’s masteroppgave [67].

I eksempelet med denne CallCenter-løsningen vil det kun være en gruppe av agenter da

agentene ikke deles inn etter egenskaper, som for eksempel lokasjon eller fagfelt. Det vil

imidlertid være mulig å opprette flere grupper i CallCenteret dersom dette blir aktuelt.

Etter endringene som er forklart vil CallCenterets struktur være som vist i vedlegg

kapittel 13.1. Meldings- og tilstandsdiagrammer for den interne oppførselen i

kontrollenheten ligger som vedlegg i kapittel 13.2 og 13.3.

CallCenteret vil holde oversikt over kundenes tilstand. Dette vil gjøres ved definerte

tilstander i CallerAgent, men det vil også brukes en tabell for å bestemme hvor kunden

befinner seg i menyen. Kundens CallerAgent vil da være i tilstanden connectedIvr. Dette

gjør at menyen kan endres uten at CallerAgent aktøren må oppdateres. Denne tabellen vil

bestå av feltet stateId og en liste med menuItem, returnNumber og nextState. En meny

representeres da ved en stateId, hvor de elementene som ligger i menuItem spilles av. Når

kontrollenheten får returnert et tall sjekkes dette mot de elementene som ligger i

returnNumber og den neste tilstanden velges ved tilsvarende nextState i listen. Dersom

det returnerte tallet ikke ligger i listen vil den gjeldende menyen spilles av på nytt.

Kontrollenheten holder oversikt over tilstanden til kundene som er i kontakt med

CallCenteret og alle agentene som er logget inn. For å oppdatere denne tilstanden tilbyr

kontrollenheten to Web Services, ImsWS til medieserveren og AgentWS til agentene.

ImsWS:

- boolean callReq(String callId, String anr): Blir kalt når kunden setter opp en

sesjon mot CallCenteret. Kunden vil alltid bli koblet til medieserveren først, som

kaller denne metoden. Det vil da opprettes en CallerAgent som representerer

kunden, og kontrollenheten vil instruere medieserveren til å spille av en meny.



- boolean returnNumber(String callId, String number): Blir kalt når en kunde

sender et nummer for å gjøre valg. Dette nummeret sendes til kundens

CallerAgent som bestemmer hva som skal gjøres videre.

- boolean onHook(String callId): Blir kalt når kunden avslutter en sesjon uten å

være i kontakt med en agent. Kundens CallerAgent vil da bli fjernet, og slettet fra

køen dersom kunden står i kø.

AgentWS:

- boolean login(String agentSipAddress): En agent kaller denne metoden med sin

SIP-adresse for å logge seg på CallCenteret og kunne ta imot samtaler. Det vil da

opprettes en UserSession aktør som representerer denne agenten.

- boolean logoff(String agentSipAddress): Logger av den aktuelle agenten.

Agentens UserSession vil da fjernes igjen. Dersom agenten er i en samtale vil den

ikke få lov til å logge av før den har avsluttet samtalen.

- boolean connected(String callId, String agentSipAddress): Denne metoden

blir kalt når en agent mottar INVITE fra en kunde som har blitt overført fra

medieserveren. Både agenten og kunden vil da bli opptatt (tilstand connected).

- boolean onHook(String callId): Blir kalt når kunden eller agenten avslutter

sesjonen. Agenten vil da bli ledig igjen (idle) og kundens sesjon mot CallCenteret

vil termineres. Kundens CallerAgent blir da fjernet.

Denne kontrolleren kunne også ha styrt en Parlay gateway og eventuelt en PSTN til IP-

gateway dersom CallCenteret skulle ha behandlet kunder fra linjesvitsjede nett.

8.2.4 Medieserver

Medieserveren vil være interaktiv ved at den spiller av mediefiler basert på kundens valg

og streamer disse til kundens klient ved å sette opp en RTP-forbindelse. Denne serveren

bygger på SIP Communicator klienten, men må modifiseres slik at den handler i henhold

til spesifikasjonen. SIP Communicator har støtte for å håndtere flere samtidige sesjoner

som er nødvendig for at den skal kunne operere som en server.



Medieserveren skal spille av mediefiler til kunden med bakgrunn i kundens valg. Disse

filene vil bli spilt av i form av mediestrømmer over en RTP-forbindelse. For å spille av

filer over en RTP-forbindelse i JMF settes det opp en prosessor med referanse til en

mediekilde som inneholder en bestemt fil. Etter at SIP-sesjonen er satt opp er det ikke

ønskelig å sende en SIP Re-INVITE hver gang det skal spilles av en ny fil. En må derfor

spille av filene over samme RTP-forbindelse. Det må da være mulighet for å skifte

mellom filer som skal sendes over RTP-forbindelsen. Når en forbindelse er satt opp i

JMF er det derimot ikke mulig å koble denne til en ny prosessor eller å koble prosessoren

til en ny mediekilde. En løsning på dette vil være å lage en ny mediekilde som kan ta

imot mediestrømmer fra andre prosessorer vekselvis. Alle mediefilene i CallCenteret får

da sin egen mediekilde og prosessor, og det opprettes en output prosessor med en

vekslende mediekilde, som vist i Figur 8-9.

Mediekilde Prosessor



VekslendeMediekilde Prosessor

Figur 8-9 Flere mediekilder settes sammen til en prosessor

For å løse dette må MediaManager klassen utvides. Ved opprettelse av en

MediaManager vil start metoden bli kjørt. Denne metoden må utvides til å lese inn alle

mediefilene som skal brukes. Den opprettes så en vekslende mediekilde,

SuperGlueDataSource (og SuperGlueStream), som er hentet fra Sun Microsytems

eksempel kode; Concatenating Multiple Inputs.[69] Dette eksemplet setter sammen flere

mediefiler til en mediefil. Med bakgrunn i informasjon fra bl.a. innlegg på nyhetsgrupper,

må SuperGlueDataSource endres for å kunne brukes i denne løsningen. [70] I



medieserveren skal mediefilene streames over en RTP-forbindelse, som skal spille av en

gitt sekvens av mediefiler helt til kunden velger en annen meny med en ny sekvens.

Følgende endringer må gjøres i SuperGlueDataSource:

- public SuperGlueDataSource(ProcInfo pInfo[]): endres ved å legge til en liste

med gjeldende sekvens som skal spilles av, definere start verdi for denne

sekvensen og koble denne til output prosessoren.

- synchronized boolean handleEOM: endres til å spille av sekvensen på nytt helt

til en annen sekvens blir valgt eller forbindelsen koblet ned (ved BYE).

- switchDataSource(String menuItem): legges til for å kunne skifte gjeldende

sekvens.

Når medieserveren mottar en INVITE-melding vil den sende en forespørsel om å ta imot

en ny sesjon til kontrollenheten ved å kalle Web Service metoden callReq. Dersom den

godtas ved å returnere true vil medieserveren svare på INVITE-meldingen ved å kjøre en

autoAnswer metode. Dette er gjort ved å utvide processRequest(RequestEvent

requestReceivedEvent) metoden i SipManager, i tilfellet hvor forespørselen er en

INVITE. Metoden autoAnswer er lagt til i SipCommunicator for å utføre den samme

operasjonen som en bruker ville ha initiert ved å trykke på Answer knappen i SIP

Communicator klienten. SIP-meldingen OK vil da returneres til kunden, og sesjonen vil

bli satt opp.

Når medieserveren mottar et valg i form av et tall fra kunden vil den sende valget videre

til kontrollenheten. Dette gjøres i metoden fireMessageReceived(Request message) i

SipManager ved å kalle kontrollenhetens Web Service metode returnNumber med tallet

som ble mottatt. Kontrollenheten vil bestemme hva medieserveren skal gjøre videre.

Dette vil enten være å spille av en ny sekvens av mediefiler eller sette kunden over til en

agent. For at kontrollenheten skal kunne styre dette tilbys den en Web Service fra

medieserveren med metodene:

- boolean play(String callId, int[] menu)

- boolean refer(String callId, String sipAddress)



Denne Web Servicen vil så sende en melding med valget og parameterne til medieserver

applikasjonen. Dette gjøres ved å benytte JMS-meldinger, med en type-parameter for å

bestemme hvilken WS metode som ble kalt, samt de parametere som er angitt for hver

metode. Meldingen blir sendt til en kø som medieserverapplikasjonen vil lytte på.

SipCommunicator klassen må da utvides til å implementere grensesnittet

MessageListener og dermed metoden onMessage(Message message). Når applikasjonen

mottar en melding vil den sjekke typeparameteren og avhengig av denne verdien utføre

en av følgende alternativer:

- Play: vil kalle switchDataSource metoden i SuperGlueDataSource med en liste

over de kildene og prosessorene som skal spilles av i gitt rekkefølge for den

valgte menyen.

- Refer: vil kalle refer(String callId, String sipAddress) metoden i SipManager

som igjen vil kalle sendRefer(String callId, String sipAddress) metoden i

CallProcessing. sendRefer finner Call objektet og tilhørende Dialog for callId’en,

og sender så REFER-meldingen i denne dialogen.

I tillegg til endringene forklart i dette kapittelet er det noen mindre endringer som må

gjøres. Alle endringer vil merkes og kommenteres i kildekoden.

8.2.5 Agentklient

I denne løsningen vil agentklienten være en standard SIP-klient med støtte for

multimedia, som tale-, tekst- og videosesjoner. SIP Communicator vil bli brukt med noen

utvidelser for å gjøre Web Service kall til kontrollenheten. Dette vil være for å informere

om hendelsene: login, logout, connected og disconnected. Disse kallene kunne ha vært

gjort i SIP-serveren i stedet, men ved å implementere disse Web Service kallene i

klienten kan standard SIP-servere benyttes uten å måtte gjøre noen endringer.

Følgende endringer må gjøres for å håndtere de ulike hendelsene:

- Login: Legge til et kall til login med agentens SIP-adresse ved metoden register i

klassen SipManager. (Ved SIP-metoden REGISTER)



- Logout: Legge til et kall til logoff med agentens SIP-adresse ved metoden

unregister i klassen SipManager. (Ved SIP-metoden REGISTER)

- Connected: Legge til et kall til connected med gjeldende callId og agentens SIP-

adresse ved metoden callStateChanged i klassen SipCommunicator dersom

sesjonens tilstand skifter til connected (Ved SIP-metoden INVITE)

- Disconnected: Legge til et kall til onHook med gjeldende callId ved metoden

callStateChanged i klassen SipCommunicator dersom sesjonens tilstand skifter til

disconnected. (Ved SIP-metoden BYE)

8.2.6 Kundeklient

I denne oppgaven er det ikke utviklet noen egen kundeklient fordi det er lagt vekt på at

løsningen skal virke med standard SIP-klienter, men Pocket PC klienten Portrait og

klientene som er beskrevet i kapittel 6.2.4 er brukt til testing.

8.3 Utvidelser og alternative løsninger Et CallCenter kan utvides med mange funksjoner. I dette kapittelet vil det fokuseres på de

funksjonene og mulighetene som vil bli mulig ved å ta i bruk multimedia, multimodalitet

og SIP.

8.3.1 Agent transfer

Transfer fra en agent til en annen er ikke implementert i denne løsningen, men burde

være mulig i en CallCenter-applikasjon. Dette løses på akkurat samme måte som ved

transfer fra medieserveren til en agent, og det vil kun være en utvidelse av agentklienten

og kontrollenheten som trengs for å implementere denne funksjonen. En agentklient

burde også ha mulighet for å få opp informasjon om samtalen, som kundeinformasjon,

hvilke agenter kunden har snakket med og informasjon fra de andre agentene. Dette kan

gjøres ved å lagre tilstandene kundens CallerAgent i kontrollenheten har befunnet seg i

og en database med kundeinformasjon hvor agentene kan skrive inn relevant data i

forbindelse med en betjening.



8.3.2 SIP kontroller

Det er to måter å behandle ”call transfer” på ved bruk av SIP. En måte er å benytte

REFER-metoden ved at et SIP-endepunkt ber et annet om å sette opp en ny sesjon slik

som det er gjort i CallCenter-løsningen. Den andre måten er å ha en kontroller i form av

en SIP-klient som behandler SIP-meldinger og sender de videre til riktig enhet i

CallCenteret. Kunden vil da ha kontakt med kun et SIP-endepunkt, som hele tiden vil

være i signaleringsveien.

SIP

RTP Media

RTP Media

SIP

SIP og WS

SIP

Call CenterKunde

Kunde SIP serverKunde Call Center SIP Server

Media Server

Agent

Kontrollenhet

SIP

Figur 8-10 Alternativ løsning med SIP kontroller

Med denne løsningen vil alle SIP-meldingene gå gjennom kontrolleren. For å holde

oversikt over agenter og deres tilstand kan det da være ett alternativ å gjøre dette direkte i

kontrolleren ved at den tolker REGISTER-, INVITE- og BYE-meldingene. Det vil da bli

unødvendig å implementere Web Service kallene til kontrollenheten fra agentklientene.



Ved bruk av denne løsningen må det være sikkert at SIP-meldingene går gjennom denne

SIP-kontrolleren. Det vil da være valgfritt hvilken SIP-klient agentene vil bruke. Denne

SIP-kontrolleren kunne ha vært integrert i kontrollenheten som er designet for

CallCenter-løsningen, som vist i Figur 8-10.

Det er i dag flere SIP-klienter som støtter REFER-metoden og det ser ut til at dette vil bli

standard i SIP-klienter fremover. CallCenter-løsningen i denne oppgaven kunne ha

benyttet begge mulighetene som foreslått for ”call transfer”. I denne løsningen er det lagt

vekt på å utvikle en interaktiv medieserver og en kontrollenhet vil REFER-metoden

benyttes istedenfor å lage en egen SIP-kontroller.

8.3.3 Statistikk og presence til kunder

Ved å ta i bruk statistikk og presenceinformasjon i forbindelse med SIP, kan kundene få

informasjon om når det er ledige behandlere. Kundene kan da for eksempel abonnere på

ledige agenter ved å sende SUBSCRIBE og bli varslet om det ved NOTIFY, tilsvarende

Figur 3-8.

Ved bruk av SIP vil det være mulig å sende statistikk om for eksempel kø posisjon og

annen informasjon i tekstmeldinger ved MESSAGE. Dersom informasjonen ikke er

relevant for alle kundene kan det også her være aktuelt å abonnere på informasjonen og

bli varslet ved NOTIFY.

8.3.4 Medietolkning

Fremover burde det være mulig å styre medieserveren med flere forkjellige modaliteter,

som for eksempel ved talegjenkjenning. Dette kan løses uten ekstra funksjonalitet i

klientene, men ved at lyden sendes til en stemmegjenkjenningsmaskin i tilknytning til

medieserveren og tolkes der. Denne maskinen vil da styre kontrollenheten. I tillegg til

talegjenkjenning kan det også være aktuelt med tolkning av håndskrift eller fri tekst.



8.3.5 Kundeklient

Selv om de fleste SIP-klienter burde kunne brukes som en kundeklient, ville det ha vært

nyttig å utvikle et eksempel på hvordan en slik klient kunne ha vært med en

brukervennlig GUI for CallCenter-tjenester.

8.3.6 Tastelyder

For at nye CallCenter-applikasjoner skal kunne tas i bruk må det være mulig å betjene

kunder som ikke har SIP-klienter. Dersom CallCenteret ikke har mulighet for

talegjenkjenning, må det være mulig å styre CallCenteret med tastelyder (DTMF). Disse

tastelydene må da enten tolkes av PSTN til SIP-gatewayen som benyttes eller av

medieserveren. Dersom gatewayen skal tolke disse lydene, må den først samle de inn.

Dette kan for eksempel gjøres av en Parlay gateway med User Interaction SCF. Videre

må den sende verdien av disse tastelydene i SIP-meldinger slik at medieserveren forstår

disse. Medieserveren kan også prosessere tastelydene selv, men da vil de komme i

mediestrømmen og ikke som SIP-meldinger. Medieserveren må da ha en enhet for å

kunne tolke mediestrømmene og varsle om DTMF lyder.

Kapittel 9 - Diskusjon og utfordringer 86


9. Diskusjon og utfordringer

SIP har til nå hatt relativ lav utbredelse. IP-telefoni får imidlertid stadig flere brukere og

SIP ser ut til å bli den foretrukne standarden for å sette opp og kontrollere disse

sesjonene. Det er kun Telio som tilbyr IP-telefoni til private kunder i Norge i dag, og de

benytter SIP for sesjonskontroll. Flere er i ferd med å komme med IP-telefoni på det

private markedet, og Telenor har sagt at de skal lansere en løsning i løpet av året. I

bedriftsmarkedet har flere tilbydere allerede vært på markedet en stund. Flere selskaper

og grupper, som for eksempel iptel.org, tilbyr gratis SIP-kontoer, men for å kommunisere

med PSTN vil det i tillegg være nødvendig å ha tilgang til en gateway. Når IP-telefoni

ved bruk av SIP begynner å bli utbredt vil overgangen til multimedia tjenester bli

lettere.[74][75]

Dersom en allerede har fri tilgang til internett er det i prinsippet gratis å sette opp

samtaler mellom IP-telefoner. Dette blir som å sette opp en hvilken som helst

dataforbindelse. Men dersom IP-telefonen vil flytte på seg og få en ny IP-adresse vil en

trenge en IP-telefoniserver (SIP Registar) for å finne ut hvilken IP-adresse telefonen

befinner seg på. Ved å sette opp en ”tilfeldig” dataforbindelse har men heller ingen

tjenestekvalitetsgaranti (QoS). For å kunne tilby garantert tjenestekvalitet må nettene ha

mulighet for å reservere ressurser til sesjoner. Dette er noe operatørene kan ta seg betalt

for og det er da nødvendig å autentisere brukeren.

Telenor vil åpne sitt UMTS-nett i løpet av 2004, mens NetCom har sagt de vil vente til

2005. [75] Denne åpningen har flere ganger blitt utsatt på grunn av problemer med

roamingen mellom UMTS og GSM, liten tilgang på UMTS terminaler og

markedsmessige grunner. Det er også ventet at EDGE vil lanseres innen året er omme.

[45] Disse teknologiene vil få god støtte for multimedietjenester, men bruken av dette vil

være avhengige av brukskostnadene. Multimedietjenester vil nok bli for dyrt dersom en

prismodell tilsvarende GPRS innføres, med en relativt høy pris per datamengde. Et

alternativ som kan gjøre at multimedia tjenester vil slå an blant brukerne, kan være å sette

Kapittel 9 - Diskusjon og utfordringer 87


en pris per tjeneste. For eksempel ved å bruke en fast pris for å hente ned ett spill,

streame ett filmklipp eller en tidstakst ved videokonferanse.

For at kundene av et CallCenter skal begynne å bruke nye tjenester med multimedia og

multimodalitet må det være enkelt å bruke, og ikke særlig vanskeligere enn en vanlig

telefon. De må også oppfatte tjenestekvaliteten (QoS) som tilnærmet like god som ved

bruk av linjesvitsjede nett.

Det har i denne oppgaven vært vanskelig å få tak i informasjon om Parlay Multi-Media

Call Control. Bl.a. har Telenor som er ”affiliate” medlem av Parlay gruppen ikke hatt mer

tilgjengelig informasjon enn standarden som ligger åpent på internett. Utvikleren må ha

relativt god kjennskap til SIP-standarden for å utvikle applikasjoner ved bruk av JAIN

SIP, mens ved Parlay har de underliggende nettverksprotokollene blitt skjult for

utvikleren. Dersom Parlay Multi-Media Call Control blir tilsvarende de andre

grensesnittene i Parlay API’et vil det bli forholdsvis enkelt å sette opp og kontrollere

multimediesesjoner. Dette vil gjøre det lettere for utviklere uten

telekommunikasjonskunnskaper å utvikle applikasjoner som kan kontrollere

multimediesesjoner.

Teknologien som skal til for å utvikle multimedia teletjenester vil sannsynligvis i løpet av

nær framtid være god nok. Dette vil gjøre det mulig å ta i bruk nye tjenester med for

eksempel video. Det gjenstår å se når (eller) om det kommer tjenester som gjør at

forbrukerne tar disse i bruk. For et CallCenter kan det være ved at kunden får bedre

informasjon fra CallCenteret eller ved at dette blir en fordel for selskapet som har et

CallCenter.

Kapittel 10 - Konklusjon 88


10. Konklusjon

I denne oppgaven har jeg studert og beskrevet hvilke muligheter som åpner seg ved bruk

av multimedia og multimodalitet i et CallCenter.

Mange typer aksessteknologier og terminaler har nå god støtte for multimedia og

multimodalitet. Dette gjelder spesielt løsninger fra den tradisjonelle ”datasiden”. Flere

mobilsystemer vil sannsynligvis også få bedre støtte for multimedia og multimodalitet

innen kort tid. Dette gjelder særlig ved innføringen av EDGE og UMTS, som vil gi økt

hastighet, og etter hvert introduksjonen av et nytt IP Multimedia Subsystem (IMS). Nye

avanserte mobilterminaler vil ha prosesseringskraft nok til å behandle multimedia og

bedre input og output muligheter, noe som åpner for flere modaliteter.

For å sette opp og kontrollere multimediesesjoner vil SIP være godt egnet fordi den

støtter de fleste medietyper, er en relativ enkel protokoll og bygger på kjente prinsipper

fra andre internett protokoller.

Støtten for multimedia-håndtering i Parlay er i dag begrenset til å håndtere enkeltstående

tjenester som for eksempel ”call control”, SMS, ”user interaction” og MMS hver for seg.

Fremover vil denne støtten være avhengig av hvordan Multi-Media Call Control

funksjonen blir utviklet og tatt i bruk.

SMIL vil være best egnet for å presentere multimedia, men kan også initiere

multimediesesjoner. I CallCenter sammenheng kan SMIL brukes til å presentere

multimedia multimodalt og SMIL kan for eksempel styre en interaktiv medieserver.

JAIN SIP er et standardgrensesnittet mot SIP som gir utvikleren hjelp til å lage

applikasjoner som benytter protokollen. Ved bruk av JAIN SIP har en full kontroll over

SIP, men det krever at utvikleren må kjenne SIP protokollen og dens oppførsel relativt

godt. SIP protokollen er likevel langt enklere å forstå enn tradisjonelle

Kapittel 10 - Konklusjon 89


signaleringsprotokoller og dersom utvikleren har kjennskap til SIP kan han relativt enkelt

utvikle avanserte multimedia teletjenester.

I denne oppgaven er en CallCenter løsning spesifisert, designet og implementert etter en

definert eksempeltjeneste og ved bruk av JAIN SIP grensesnittet. Denne løsningen viser

noen eksempler på hvilke muligheter som finnes ved å ta i bruk multimedia og

multimodalitet i CallCenter-løsninger, og hvordan SIP kan brukes for å kontrollere disse.

Kapittel 11 - Referanser 90


11. Referanser

[1] Alan B. Johnston, Henry Sinnreich, Internet Communication Using SIP, Wiley, 2001

[2] Alan B. Johnston, SIP: Understanding the Session Initiation Protocol, Artech

House, 2001 [3] Ingunn Amdal, Multimodalitet presentasjon,

Multimodalitet_idistudenter_mai2003.ppt [4] W3C, Multimodal Interaction Activity, http://www.w3.org/2002/mmi/ [5] K Kvale, J Rugelbak, I Amdal, How do non-expert users exploit simultaneous

inputs in multimodal interaction, Human Factors in Telecommunication 2003, Berlin, Germany, Dec 2003, http://www.korfint.no/ingunn/publications/HFT2003_MUST.pdf

[6] Phelim O’Doherty, Mudumbai Ranganathan, JAIN SIP Tutorial,

http://java.sun.com/products/jain/JAIN-SIP-Tutorial.pdf [7] Emil Ivov, JAIN-SIP & SIP Communicator, JAIN Tech Day in Munich, Germany

Feb.12.2004, https://sip-communicator.dev.java.net/files/documents/343/3086/ file_3086.dat?filename=SIP Communicator@JAIN Tech Day.pdf

[8] SIP Communicator Project, https://sip-communicator.dev.java.net/ [9] Session Initiation Protocol (SIP), http://www.cs.columbia.edu/sip/ [10] NIST, IP telephony project, http://www-x.antd.nist.gov/proj/iptel/ [11] IETF Network Working Group, RFC: 2543 SIP: Session Initiation Protocol,

http://www.ietf.org/rfc/rfc2543.txt [12] IETF Network Working Group, RFC: 3261 SIP: Session Initiation Protocol,

http://www.ietf.org/rfc/rfc3261.txt [13] IETF Network Working Group, RFC: 2976, The SIP INFO Method,

http://www.ietf.org/rfc/rfc2976.txt [14] IETF Network Working Group, RFC: 3262, Reliability of Provisional Responses

in the Session Initiation Protocol (SIP), http://www.ietf.org/rfc/rfc3262.txt [15] IETF Network Working Group, RFC: 3515, The Session Initiation Protocol (SIP)

Refer Method, http://www.ietf.org/rfc/rfc3515.txt



[16] IETF Network Working Group, RFC: 3265, Session Initiation Protocol (SIP)-Specific Event Notification, http://www.ietf.org/rfc/rfc3265.txt

[17] IETF Network Working Group, RFC: 3428, Session Initiation Protocol (SIP)

Extension for Instant Messaging http://www.ietf.org/rfc/rfc3428.txt [18] IETF Network Working Group, RFC: 2327, SDP: Session Description Protocol,

http://www.ietf.org/rfc/rfc2327.txt [19] Internet Engineering Task Force SIMPLE WG, Internet Draft, SIP Extensions for

Presence, http://www.ietf.org/proceedings/01dec/I-D/draft-ietf-simple-presence-04.txt

[20] Java Community Process, JSR-000032 JAIN™ SIP Specification,

http://jcp.org/aboutJava/communityprocess/first/jsr032/index.html [21] java.net, jain-sip Project home, https://jain-sip.dev.java.net/ [22] The Parlay Group, http://www.parlay.org/ [23] Zygmunt Lozinski, Parlay/OSA - a New Way to Create Wireless Services,

http://www.parlay.org/docs/2003_06_01_Parlay_for_IEC_Wireless.pdf [24] Chelo Abarca, Andy Bennett, Ard-Jan Moerdijk, Musa Unmehopa, Parlay/OSA:

an open API for service development, http://www.parlay.org/docs/feb2002mm/16_AllAboutParlayOSA.ppt

[25] The Parlay Group Specifications, http://www.parlay.org/specs/index.asp [26] The Parlay Group, Open Service Access (OSA); Application Programming

Interface (API); Part 1: Overview (Parlay 4), http://www.parlay.org/specs/4.1_082103/es_20291501Overview.zip

[27] Parlay X Web Services Specification, http://www.parlay.org/specs/Parlay_X_Web_Services_Specification_V1_0.zip [28] Parlay X Web Services White Paper, Version 1.0,

http://www.parlay.org/specs/library/ParlayX-WhitePaper-1.0.pdf [29] Parlay Multi-Media Call Control,

http://www.parlay.org/specs/4.1_082103/es_2029150404MultiMediaCallCtrl.zip [30] Lars Kr. Hallingstad, CallCenter in Amigos, Prosjektoppgave ved item, NTNU

desember 2003, http://www.item.ntnu.no/lab/nettint1/activities/prosjekter/host2003/HallingstadRapport.pdf



[31] The World Wide Web Consortium (W3C), Synchronized Multimedia

http://www.w3.org/AudioVideo/ [32] W3C, Synchronized Multimedia Integration Language (SMIL 2.0), W3C

Recommendation 07 August 2001, http://www.w3.org/TR/smil20/ [33] IETF Network Working Group, RFC: 1916, E.164 number and DNS,

http://www.ietf.org/rfc/rfc2916.txt [34] IETF, IP Telephony, http://www.ietf.org/html.charters/iptel-charter.html [35] IETF Network Working Group, RFC: 3219, Telephony Routing over IP (TRIP),

http://www.ietf.org/rfc/rfc3219.txt [36] PSTN and Internet Internetworking (PINT),

http://www.ietf.org/html.charters/pint-charter.html [37] IETF Network Working Group, RFC: 2848, The PINT Service Protocol:

Extensions to SIP and SDP for IP Access to Telephone Call Services, http://www.ietf.org/rfc/rfc2848.txt

[38] IETF Network Working Group, RFC: 3136, The SPIRITS Architecture,

http://www.ietf.org/rfc/rfc3136.txt [39] IETF Network Working Group, RFC: 2848, The PINT Service Protocol:

Extensions to SIP and SDP for IP Access to Telephone Call Services, http://www.ietf.org/rfc/rfc2848.txt

[40] GSM World – GPRS, http://www.gsmworld.com/technology/gprs/intro.shtml [41] GSM World – GPRS klasser,

http://www.gsmworld.com/technology/gprs/class.shtml [42] Ulf Olsson og Mats Nilsson, Combinational services – The pragmatic first step

toward all-IP, Ericsson Review 2/2003, s.66-71 [43] Nokia, Push to Talk over Cellular – Real-time always-on voice service

http://www.nokia.com/poc/PoC_WP_A4.pdf [44] Ericsson, EDGE, Introduction of high-speed data in GSM/GPRS networks,

White Paper, http://www.ericsson.com/products/white_papers_pdf/edge_wp_technical.pdf

[45] digi.no, NetCom venter mens Telenor kjører i vei,

http://www.digi.no/php/art.php?id=105356&f=katnav



[46] digi.no, Telenor starter utbygging av Edge,


[47] UMTS World, Overview of The Universal Mobile Telecommunication System, http://www.umtsworld.com/technology/overview.htm

[48] 3GPP, Technical Specification Group Services and System Aspects; Codec for

circuit switched multimedia telephony service; Modifications to H.324 (Release 1999) http://www.3gpp.org/ftp/Specs/archive/26_series/26.111/26111-340.zip

[49] 3GPP, Overview of the features in 3GPP Release 5

http://www.3gpp.org/Releases/Rel5_features_v_2003_09_09.htm [50] 3GPP IP Multimedia Subsystem (IMS); Stage 2, Release 5,

ftp://ftp.3gpp.org/specs/2002-12/Rel-5/23_series/23228-570.zip [51] K. Daniel Wong og Vijay K. Varma (Telcordia Technologies),

Supporting Real-Time IP Multimedia Services in UMTS, IEEE Communications Magazine, November 2003, s.148-155

[52] digi.no, Ny ADSL-teknologi fra Nextgentel til høsten,

http://www.digi.no/php/art.php?id=104590 [53] DSL Forum, http://dslforum.org/ [54] Telenor utelukkes fra WiMax-auksjoner,

http://www.digi.no/php/art.php?id=104570&f=katnav [55] INTEL, Wireless LAN Technology,

http://www.intel.com/business/bss/infrastructure/wireless/solutions/ technology.htm

[56] IEEE 802.3 CSMA/CD (ETHERNET), http://grouper.ieee.org/groups/802/3/ [57] Sun, Java 2 Platform, Micro Edition (J2ME); JSR 68 Overview,

http://java.sun.com/j2me/overview.html [58] Sun, Mobile Information Device Profile (MIDP); JSR 37, JSR 118 Overview,

http://java.sun.com/products/midp/overview.html [59] Microsoft Portrait, http://research.microsoft.com/~jiangli/portrait/ [60] VLI Gphone, http://www.vliusa.com/index.php



[61] Lancaster University, Java Support on Pocket PC, http://www.comp.lancs.ac.uk/computing/users/fittond/ppcjava.html

[62] palmsource, Java on the Palm OS, http://www.palmos.com/dev/tech/java/ [63] Sun, J2ME MIDP for Palm OS, http://java.sun.com/products/midp4palm/ [64] Microsoft Windows Messenger, http://www.microsoft.com/windows/messenger/ [65] Xten, http://www.xten.com/ [66] Pingtel, www.pingtel.com [67] Geir Melby, Master Thesis, Agder University College 2003, Using J2EE

Technologies for Implementation of ActorFrame Based UML2.0 Models, http://siving.hia.no/ikt03/ikt6400/g22/rapport.pdf

[68] Discussion list for the JAIN(tm) SIP API,

http://archives.java.sun.com/jain-sip-interest.html [69] Sun, Concatenating Multiple Inputs,

http://java.sun.com/products/java-media/jmf/2.1.1/solutions/Concat.html [70] Discussion list for Java Media Framework API, http://archives.java.sun.com/cgi-

bin/wa?A2=ind0201&L=jmf-interest&F=&S=&P=15719

[71] Java Community Process, JSR 125: JAIN™ SIP Lite,

http://www.jcp.org/jsr/detail/125.jsp

[72] Program for Advanced Telecom Services, http://www.pats.no/

[73] 3GPP, Technical Specification Group Services and System Aspects; Virtual

Home Environment/Open Service Access (Release 5),

ftp://ftp.3gpp.org/specs/2002-12/Rel-5/23_series/23127-520.zip

[74] Telio, www.telio.no

[75] digi.no, Norge sist i Europa med UMTS,


Kapittel 12 - Vedlegg 1 Installasjonsbeskrivelse 95


12. Vedlegg 1 Installasjonsbeskrivelse

Alle enhetene krever at J2SE 1.4.2 og Ant versjon 1.6 er installert. Versjonene angitt i

dette kapittelet er de som er testet og ligger i katalogen programs på den vedlagte CD’en.

Alle enhetene ligger på den vedlagte CD’en i katalog med samme navn som enhetene, og

må kopieres over til en skrivbar disk.

12.1 Kontrollenhet Krav:

- J2EE 1.4 beta 2

- JBOSS 4.0 Developer Release 1

- ActorFrame

Konfigurasjon:

- build.xml: Endre IP-adressen til medieserveren.

Deployes ved: ant deploy

Startes ved: ant start

12.2 Medieserver Krav:

- J2EE 1.4 beta 2

- JBOSS 4.0 Developer Release 1

- JMF 2.1.1e

Konfigurasjon:

- build.xml: IP-adressen til kontrollenheten

- sip-communicator.xml: medieserverens SIP-adresse og SIP-adresser til de SIP-

servere som skal benyttes.

Deployes ved: ant deploy

Startes ved: ant run

Kapittel 12 - Vedlegg 1 Installasjonsbeskrivelse 96


12.3 Agentklient Krav: JMF 2.1.1e

Konfigureres ved oppstart.

Startes ved: ant run

Kapittel 13 - Vedlegg 2 Kontrollenhet 97


13. Vedlegg 2 Kontrollenhet

13.1 Strukturdiagrammer

13.1.1 System CallCenter

System CallCenter

Package ejb Package env

13.1.2 Package env

Package env

ImsWS AgentWS



13.1.3 Package ejb

Package ejb

<<actor>>CallCenter

13.1.4 Actor CallCenter

<<actor>>CallCenter

CallerAgent

0..*

CallCenterGroup

0..*



13.1.5 Actor CallerAgent

<<actor>>CallerAgent

ImsCall

1



13.1.6 Actor CallCenterGroup

<<actor>>CallCenterGroup

UserSession

0..*



13.2 Meldingsdiagrammer

13.2.1 StartCallCenter

StartCallCenter

:CallCenterGroup

CallCenter

RoleCreateMsg()

StartCallCenter

CreateCCGMsg(ccpInfo(name, menuItems, x, y))

RoleCreateAckMsg()

RolePlayMsg

RoleConfirmMsg

RoleRequestMsg

Loop



13.2.2 Login

Login

AgentWSCallcenter :CallCenterGroup

:UserSession

LoginCCMsg(agentAdr, ccGroup, null)

LoginCCMsg(agentAdr, ccGroup, org)

RolePlayMsg()

RoleConfirmMsg()

LoginCCOkMsg(org)

LoginCCOkMsg()

GetCallCenterGroupsMsg()

CallCentersMsg(callCenterGroups)

alt

LoginCCNokMsg(errMsg, org)

LoginCCNokMsg(errMsg)

opt

ReturnUserAgentMsg(Sender)

:CallerAgent

RoleDeniedMsg()

GetCallCenterGroupsMsg

CallCentersMsg(callCenterGroups)

alt

LoginCCMsg(ccGroup)

RoleRequestMsg()



LoginCCOkMsg()



13.2.3 Logoff

Logoff

AgentWSCallcenter :CallCenterGroup :UserSession

LogoffCCMsg(anr, ccGroup, null)

LogoffCCMsg(anr, org)

RoleReleaseMsg()

RoleReleaseAckMsg()

LogoffCCOkMsg(org)

LogoffCCOkMsg()

alt

LogoffCCNokMsg(errMsg, org)LogoffCCNokMsg(errMsg)

LogoffCCMsg(ccGroup)

alt

LogoffCCNokMsg(errMsg)

LogoffCCNokMsg(errMsg)

LogoffCCOkMsg()



13.2.4 Call

exp

Call

:CallCenterGroup :UserSession

:CallerAgent

CallCenter

CallReqMsg(CallId, anr)

RolePlayMsg

RoleConfirmMsg

ImsWS

:ImsCall

CallReqMsg(CallId, anr, ccpInfo)

RoleCreateMsg

RoleCreateAckMsg

{idle}

RoleRequestMsg

RoleDeniedMsg()

callReq(CallId, anr)

callReqNok(callId)

callReqOk(callId)

callReqOk(callId)

AgentWS



Call

:CallCenterGroup :UserSession:CallerAgent CallCenterImsWS :ImsCall

Loop(1,*)PlayIvrMsg(callId, menuItems)

ReturnNumberMsg(callId, number)

play(callId, menu)

Ref Remove CalerAgent

playOk()

playNok()

alt

Ref IvrExp

Ref CallAgent

opt


{connectedIms}

AgentWS

optGetUserAgentMsg()

NoUserAgentLoggedInMsg(){waitUA}

{connectedIms}

Add message first in menuItems!



13.2.5 CallAgent

CallAgent

:CallCenterGroup :UserSession:CallerAgent CallCenterImsWS

GetUserAgentMsg()

ReturnUserAgentMsg(ua)

NoUserAgentFreeMsg()


alt

:ImsCall

PlayIvrMsg(callId, musicId)

play(callId, musicId)

{waitUA}

{queueUA}

playOk()

playNok()

alt

Ref IvrExp

Ref CallAgentSetup

A user agent mustbe logged in.

Happens when a useragent is available.

AgentWS



13.2.6 CallAgentSetup

CallAgentSetup

:CallCenterGroup :UserSession:CallerAgent CallCenter

CallResMsg()

ImsWS

ReferMsg(callId, sipAddress)

:ImsCall

refer(callId, sipAddress){waitConnect}

{connected}

ConnectedOkMsg(agentAdr)

{connected}

CallReqMsg()

{waitConnect}

ConnectedOkMsg(agentAdr)

ConnectedOkMsg()

AgentWS

Connected(agentAdr)



13.2.7 CallExp

Call


Loop(1,*)PlayIvrMsg(callId, menuItems)


play(callId, menu)


playOk()

playNok()

alt

Ref IvrExp

Ref CallAgent

opt


{connectedIms}

AgentWS

optGetUserAgentMsg()

NoUserAgentLoggedInMsg(){waitUA}

{connectedIms}

Add message first in menuItems!



13.2.8 ImsExp

exp

opt

ImsExp


IvrNotOk()

{connectedIms}

OnHook(){queueUA}

AgentWS




13.2.9 RemoveCallerAgent

RemoveCallerAgent


RoleReleaseMsg()

RoleRemoveMsg()

RoleRemoveMsg()

RolePlayEndedMsg()

RolePlayEndedMsg()

AgentWS



13.3 Tilstandsdiagrammer

13.3.1.1 Actor CallCenter

idle

OnHookMsg(callId)

OnHookMsg(callId) To CallerAgent(callId)

idle

ReturnNumberMsg (callId, number)

ReturnNumberMsg (CallId, number) To CallerAgent(callId)

CreateCCPMsg (ccgInfo)

RoleRequestMsg (Sender.getName()) To self

asm.ccgInfo.add(ccgInfo)

AgentOnHookMsg (agentAdr)

AgentOnHookMsg (agentAdr) To CallCenterGroup

idle

GetCallCenterGroupsMsg()

CallCenterGroupsMsg (callCenterGroups) To Sender

idle

CallReqMsg(callId, anr)

RoleConfirmMsg() From CallerAgent

CallReqMsg(callId, anr, CallCenterGroupInfo) To Sender

RoleRequestMsg (”CallerAgent”)) To Self

Save Msg in CRMquene

Get callId and anr from CRMqueue, standard CCP

ConnectedOkMsg (agentAdr)


Find CallCenterGroup From agentAdr

Find CallCenterGroup From agentAdr



idle

LoginCCMsg(anr, ccGroup, null)

LoginCCMsg(anr, ccGroup, Sender) To ccGroup

idle

LoginCCOkMsg (org)

LoginCCOkMsg() To org

LoginCCNokMsg (org)

LoginCCNokMsg() To org

idle

LogoffCCMsg(anr, ccGroup, null)

LogoffCCMsg(anr, ccGroup, Sender) To ccGroup

idle

LogoffCCOkMsg (org)

LogoffCCOkMsg() To org

LogoffCCNokMsg (org)

LogoffCCNokMsg() To org



13.3.1.2 Actor CallCenterGroup

Idle

LoginCCMsg(anr, org)

LoginCCOkMsg() To Parent

LoginCCNokMsg(org) To Parent

Idle

RoleRequestMsg (anr, ”UserSession) To self

Idle

GetUserAgentMsg()

Idle

freeUserAgents.size() > 0

NoUserAgentMsg() To SenderReturnUserAgent

Msg(ua) To Sender

Idle

waitingCallers > 0?

ReturnUserAgentMsg (Sender) To ca

Idle

freeUserAgents.add(Sender)

Idle

RoleConfirmMsg()

Idle

ca = waitingCallers.remove(0);caUa.add(ca, Sender);

ua = freeUserAgents.remove(0);caUa.add(Sender, ua);

waitingCallers.add (Sender)

Asm.childs.size() > 0

NoUserAgentLoggedInMsg() To Sender

true

true

false

false

truefalse

RoleDeniedMsg(anr, UserSession)

Idle

Remove LgoginCCMsg from agentLoginMsgList

Remove LgoginCCMsg from agentLoginMsgList

Save LgoginCCMsg in agentLoginMsgList


ConnectedOkMsg() To ua

Idle

Idle

Find ua from agentAdr



LogoffCCOkMsg (org) To Parent

Idle

LogoffCCNokMsg(errMsg, org) To Parent

Idle

Idle

OnHookMsg()

Idle

waitingCallers.remove(Sender);

Idle

LogoffCCMsg(anr, org)

freeUserAgentscontains anr

truefalse

RoleReleaseMsg() To UserSession(anr)

freeUserAgents.remove(anr);

Idle

AgentOnHookMsg (agentAdr)

AgentOnHookMsg() To ua

Idle

waitingCallers > 0?

Idle

ReturnUserAgentMsg (ua) To ca

ca = waitingCallers.remove(0);caUa.add(Sender, ua);

freeUserAgents.add(ua)

truefalse

Find ua from agentAdrcaUa.remove(Sender, ua);



13.3.1.3 Actor UserSession

idle

CallReqMsg ()

CallResMsg() To asm.ca

waitConnect

connectedwaitConnect

AgentOnHookMsg()

idle

ConnectedOkMsg()

asm.ca = Sender

connected

OnHookMsg()To asm.ca

AgentOnHookMsg()

idle

OnHookMsg()To asm.ca



13.3.1.4 Actor CallerAgent

idle

CallReqMsg(callId, CallCenterGroupInfo)

connectedIms

asm.callId = callId;asm.ccgi = CallCenterGroupInfo;

OnHookMsg(callId)

RoleRemove() To Self

PlayImsMsg(callId, menuItems) To IvrCall

connectedIms

ReturnNumberMsg (callId,number)

waitUA

number=agentnr

PlayImsMsg(callId, menuItems) To IMSCall

connectedIms

GetUserAgentMsg To CCP

else

true

OnHookMsg(callId)


Find new menuItems

ImsNotOk()

DisconnectMsg (null) To CCG




NoUserAgentFreeMsg()

queueUA

PlayImsMsg(callId, musicId) To IvrCall

waitUA


asm.ua = ua;asm.bnr = ua.anr;

(SIPaddress)

NoUserAgentLoggedInMsg()

connectedIms

PlayImsMsg(callId, alternativeMenu) To IvrCall

ReferMsg (callId,SIPaddress) To ImsCall

waitConnect

CallReqMsg() To ua

OnHookMsg()

OnHookMsg() To asm.ccgi


queueUA

ImsNotOk()

OnHook (null) To CCG


OnHookMsg()

OnHookMsg() To asm.ccgi



asm.ua = ua;asm.bnr = ua.anr;

(SIPaddress)

RefertImsMsg (callId,SIPaddress) To ImsCall

waitConnect

CallReqMsg() To ua



waitConnect

CallResMsg()

connected

OnHookMsg(callId)


connected

OnHookMsg(callId)


13.3.1.5 Actor ImsCall

Idle

Idle

res = play(callId, menuItems)

PlayImsMenuMsg(callId, menuItems)

IvrNok() To Parent

refer(callId, sipAddress)

ReferMsg(callId, sipAddress)

res

true

false

Kapittel 14 - Vedlegg 3 SIP-meldinger 119


14. Vedlegg 3 SIP-meldinger

Nedenfor vises SIP-meldingene for systemet ved et tilfelle hvor kunden sender inn

valgene 1, 2 og 9, som gjør at han mottar SIP-meldingen REFER og blir satt over til en

agent (ved meldingsdiagrammene Figur 8-4 og Figur 8-5). SIP-enhetene som benyttes er

som i Figur 8-3 med IP- og SIP-adresser som vist i tabellen under.

Navn Server-/SIP-adresse IP-adresse

Medieserver [email protected] 129.241.208.142

CallCenter SIP server 129.241.208.134 129.241.208.134

Agent [email protected] 129.241.208.56

Kundens SIP server iptel.org 195.37.77.101

Kunde [email protected] 129.241.200.198

[media server] REGISTER sip:129.241.208.134:5060;transport=udp SIP/2.0 Call-ID: [email protected] CSeq: 1 REGISTER From: "l" <sip:[email protected]:5060;transport=udp>;tag=709763 To: "l" <sip:[email protected]:5060;transport=udp> Via: SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bK50a153c2b72dacc6e29e7c244f0573f4 Max-Forwards: 70 Expires: 3600 Contact: "l" <sip:129.241.208.142:5060;transport=udp> Content-Length: 0 [cc] SIP/2.0 200 OK Call-ID: [email protected] CSeq: 1 REGISTER From: "l" <sip:[email protected]:5060;transport=udp>;tag=709763 To: "l" <sip:[email protected]:5060;transport=udp> Via: SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bK50a153c2b72dacc6e29e7c244f0573f4 Max-Forwards: 70 Contact: "l" <sip:129.241.208.142:5060;transport=udp>;expires=3600 Content-Length: 0 [agent] REGISTER sip:129.241.208.134:5060;transport=udp SIP/2.0 Call-ID: [email protected] CSeq: 1 REGISTER From: "Lars" <sip:[email protected]:5060;transport=udp>;tag=1506732 To: "Lars" <sip:[email protected]:5060;transport=udp> Via: SIP/2.0/UDP 129.241.208.56:5060;branch=z9hG4bK99e066fd69810805ab24303dde87e1a3 Max-Forwards: 70



Expires: 3600 Contact: "Lars" <sip:129.241.208.56:5060;transport=udp> Content-Length: 0 [cc] SIP/2.0 200 OK Call-ID: [email protected] CSeq: 1 REGISTER From: "Lars" <sip:[email protected]:5060;transport=udp>;tag=1506732 To: "Lars" <sip:[email protected]:5060;transport=udp> Via: SIP/2.0/UDP 129.241.208.56:5060;branch=z9hG4bK99e066fd69810805ab24303dde87e1a3 Max-Forwards: 70 Contact: "Lars" <sip:129.241.208.56:5060;transport=udp>;expires=3600 Content-Length: 0 [kunde] REGISTER sip:iptel.org SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: <sip:[email protected]>;tag=bb180cd9-8fc3-4868-a8bf-1a5fef24c49f To: <sip:[email protected]> Call-ID: [email protected] CSeq: 1 REGISTER Contact: <sip:129.241.200.198:15437>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK" User-Agent: Windows RTC/1.0 Expires: 1200 Event: registration Allow-Events: presence Content-Length: 0 [kunde server] SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: <sip:[email protected]>;tag=bb180cd9-8fc3-4868-a8bf-1a5fef24c49f To: <sip:[email protected]>;tag=794fe65c16edfdf45da4fc39a5d2867c.27c4 Call-ID: [email protected] CSeq: 1 REGISTER WWW-Authenticate: Digest realm="iptel.org", nonce="40c985d0e4b80abf8d91239f3eabd94fe0b8172a" Server: Sip EXpress router (0.8.12-tcp_nonb-tls (i386/linux)) Content-Length: 0 Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=28118 req_src_ip=129.241.200.198 req_src_port=3019 in_uri=sip:iptel.org out_uri=sip:iptel.org via_cnt==1" [kunde] REGISTER sip:iptel.org SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: <sip:[email protected]>;tag=bb180cd9-8fc3-4868-a8bf-1a5fef24c49f To: <sip:[email protected]> Call-ID: [email protected] CSeq: 2 REGISTER Contact: <sip:129.241.200.198:15437>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK" User-Agent: Windows RTC/1.0 Expires: 1200 Event: registration Allow-Events: presence



Authorization: Digest username="lkh", realm="iptel.org", algorithm="md5", uri="sip:iptel.org", nonce="40c985d0e4b80abf8d91239f3eabd94fe0b8172a", response="22f64e72fc5406ba0af594d94f41badd" Content-Length: 0 [kunde server] SIP/2.0 200 OK Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: <sip:[email protected]>;tag=bb180cd9-8fc3-4868-a8bf-1a5fef24c49f To: <sip:[email protected]>;tag=794fe65c16edfdf45da4fc39a5d2867c.27c4 Call-ID: [email protected] CSeq: 2 REGISTER Contact: <sip:129.241.200.198:13996>;q=0.00;expires=660 Contact: <sip:129.241.200.198:15437>;q=0.00;expires=1200 Server: Sip EXpress router (0.8.12-tcp_nonb-tls (i386/linux)) Content-Length: 0 Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=28130 req_src_ip=129.241.200.198 req_src_port=3019 in_uri=sip:iptel.org out_uri=sip:iptel.org via_cnt==1" [kunde] INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 1 INVITE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Type: application/sdp Content-Length: 543 v=0 o=lars-3l6ja1sclm 0 0 IN IP4 129.241.200.198 s=session c=IN IP4 129.241.200.198 b=CT:1000 t=0 0 m=audio 26756 RTP/AVP 97 111 112 6 0 8 4 5 3 101 a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:5 DVI4/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 m=video 34218 RTP/AVP 34 31 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 [kunde server]



SIP/2.0 407 Proxy Authentication Required Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=794fe65c16edfdf45da4fc39a5d2867c.27c4 Call-ID: [email protected] CSeq: 1 INVITE Proxy-Authenticate: Digest realm="iptel.org", nonce="40c985e8f358168416b60b1756e8c6fea4d79e89" Server: Sip EXpress router (0.8.12-tcp_nonb-tls (i386/linux)) Content-Length: 0 Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=28132 req_src_ip=129.241.200.198 req_src_port=3019 in_uri=sip:[email protected]:5060 out_uri=sip:[email protected]:5060 via_cnt==1" [kunde] ACK sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=794fe65c16edfdf45da4fc39a5d2867c.27c4 Call-ID: [email protected] CSeq: 1 ACK Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Length: 0 [kunde] INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Proxy-Authorization: Digest username="lkh", realm="iptel.org", algorithm="md5", uri="sip:[email protected]:5060", nonce="40c985e8f358168416b60b1756e8c6fea4d79e89", response="e66acb6f83e9e7fe8d34f194d62d2902" Content-Type: application/sdp Content-Length: 543 v=0 o=lars-3l6ja1sclm 0 0 IN IP4 129.241.200.198 s=session c=IN IP4 129.241.200.198 b=CT:1000 t=0 0 m=audio 26756 RTP/AVP 97 111 112 6 0 8 4 5 3 101 a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:5 DVI4/8000



a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 m=video 34218 RTP/AVP 34 31 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 [kunde server] INVITE sip:[email protected]:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK3729.29c23e84.0 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Proxy-Authorization: Digest username="lkh", realm="iptel.org", algorithm="md5", uri="sip:[email protected]:5060", nonce="40c985e8f358168416b60b1756e8c6fea4d79e89", response="e66acb6f83e9e7fe8d34f194d62d2902" Content-Type: application/sdp Content-Length: 543 P-hint: OUTBOUND v=0 o=lars-3l6ja1sclm 0 0 IN IP4 129.241.200.198 s=session c=IN IP4 129.241.200.198 b=CT:1000 t=0 0 m=audio 26756 RTP/AVP 97 111 112 6 0 8 4 5 3 101 a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:5 DVI4/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 m=video 34218 RTP/AVP 34 31 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 [kunde server] SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060> Call-ID: [email protected]



CSeq: 2 INVITE Server: Sip EXpress router (0.8.12-tcp_nonb-tls (i386/linux)) Content-Length: 0 Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=28123 req_src_ip=129.241.200.198 req_src_port=3019 in_uri=sip:[email protected]:5060 out_uri=sip:[email protected]:5060 via_cnt==1" [cc] INVITE sip:129.241.208.142:5060 SIP/2.0 Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bKf9e9af9ddacea1169fe0de1248d13fba,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK3729.29c23e84.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Proxy-Authorization: Digest username="lkh",realm="iptel.org",algorithm="md5",uri="sip:[email protected]:5060",nonce="40c985e8f358168416b60b1756e8c6fea4d79e89",response="e66acb6f83e9e7fe8d34f194d62d2902" P-hint: OUTBOUND Content-Type: application/sdp Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Content-Length: 543 v=0 o=lars-3l6ja1sclm 0 0 IN IP4 129.241.200.198 s=session c=IN IP4 129.241.200.198 b=CT:1000 t=0 0 m=audio 26756 RTP/AVP 97 111 112 6 0 8 4 5 3 101 a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:5 DVI4/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 m=video 34218 RTP/AVP 34 31 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 [media server] SIP/2.0 100 Trying Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on>



Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK3729.29c23e84.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Content-Length: 0 [cc] SIP/2.0 100 Trying Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bKf9e9af9ddacea1169fe0de1248d13fba,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK3729.29c23e84.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Content-Length: 0 [media server] SIP/2.0 180 Ringing Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bKf9e9af9ddacea1169fe0de1248d13fba,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK3729.29c23e84.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Content-Length: 0 [cc] SIP/2.0 180 Ringing Max-Forwards: 9 Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK3729.29c23e84.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Content-Length: 0 [kunde server] SIP/2.0 180 Ringing Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected]



CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Content-Length: 0 P-NAT-Check: YES [media server] SIP/2.0 200 OK Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bKf9e9af9ddacea1169fe0de1248d13fba,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK3729.29c23e84.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Content-Type: application/sdp Contact: "l" <sip:129.241.208.142:5060;transport=udp> Content-Length: 148 v=0 o=pats 0 0 IN IP4 129.241.208.142 s=- c=IN IP4 129.241.208.142 t=0 0 m=audio 22224 RTP/AVP 4 3 0 5 6 8 15 m=video 22222 RTP/AVP 34 26 31 [cc] SIP/2.0 200 OK Max-Forwards: 9 Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK3729.29c23e84.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Content-Type: application/sdp Contact: "l" <sip:129.241.208.142:5060;transport=udp> Content-Length: 148 v=0 o=pats 0 0 IN IP4 129.241.208.142 s=- c=IN IP4 129.241.208.142 t=0 0 m=audio 22224 RTP/AVP 4 3 0 5 6 8 15 m=video 22222 RTP/AVP 34 26 31 [kunde server] SIP/2.0 200 OK Max-Forwards: 9



Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Content-Type: application/sdp Contact: "l" <sip:129.241.208.142:5060;transport=udp> Content-Length: 148 P-NAT-Check: YES v=0 o=pats 0 0 IN IP4 129.241.208.142 s=- c=IN IP4 129.241.208.142 t=0 0 m=audio 22224 RTP/AVP 4 3 0 5 6 8 15 m=video 22222 RTP/AVP 34 26 31 [kunde] ACK sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 2 ACK Route: <sip:129.241.208.134:5060> Route: "l"<sip:129.241.208.142:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Length: 0 [kunde server] ACK sip:129.241.208.134:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=0 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 2 ACK Route: "l"<sip:129.241.208.142:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Length: 0 P-hint: rr-enforced [cc] ACK sip:129.241.208.142:5060 SIP/2.0 Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bKfa504ae9d82c9378c2ad56ca5a2e9e1d,SIP/2.0/UDP 195.37.77.101;branch=0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3



To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 2 ACK Route: "l" <sip:129.241.208.142:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 P-hint: rr-enforced Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Content-Length: 0 [kunde] MESSAGE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 1 MESSAGE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Type: text/plain; charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIAMABTAGgAZQBsAGwAJQAyADAARABsAGcAOwAgAEUARgA9ADsAIABDAE8APQAwADsAIABDAFMAPQAwADsAIABQAEYAPQAwAA0ACgANAAoA Content-Length: 1 1 [kunde server] MESSAGE sip:[email protected]:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK1b96.1bed6481.0 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 1 MESSAGE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Type: text/plain; charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIAMABTAGgAZQBsAGwAJQAyADAARABsAGcAOwAgAEUARgA9ADsAIABDAE8APQAwADsAIABDAFMAPQAwADsAIABQAEYAPQAwAA0ACgANAAoA Content-Length: 1 P-hint: OUTBOUND 1 [cc] MESSAGE sip:129.241.208.142:5060 SIP/2.0 Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bKdf27692d7e2ee407c824c25eea5c9ad0,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK1b96.1bed6481.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba



To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 1 MESSAGE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 P-hint: OUTBOUND Content-Type: text/plain;charset=UTF-8 Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Content-Length: 1 1 [media server] SIP/2.0 200 OK Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bKdf27692d7e2ee407c824c25eea5c9ad0,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK1b96.1bed6481.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 1 MESSAGE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Content-Length: 0 [cc] SIP/2.0 200 OK Max-Forwards: 9 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 1 MESSAGE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK1b96.1bed6481.0 Content-Length: 0 [kunde server] SIP/2.0 200 OK Max-Forwards: 9 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 1 MESSAGE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK1b96.1bed6481.0 Content-Length: 0 [kunde] MESSAGE sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437



From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 4 MESSAGE Route: <sip:129.241.208.134:5060> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Type: text/plain; charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIAMABTAGgAZQBsAGwAJQAyADAARABsAGcAOwAgAEUARgA9ADsAIABDAE8APQAwADsAIABDAFMAPQAwADsAIABQAEYAPQAwAA0ACgANAAoA Content-Length: 1 2 [kunde server] MESSAGE sip:129.241.208.134:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKca96.8081d043.0 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 4 MESSAGE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Type: text/plain; charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIAMABTAGgAZQBsAGwAJQAyADAARABsAGcAOwAgAEUARgA9ADsAIABDAE8APQAwADsAIABDAFMAPQAwADsAIABQAEYAPQAwAA0ACgANAAoA Content-Length: 1 P-hint: rr-enforced 2 [cc] MESSAGE sip:129.241.208.142:5060 SIP/2.0 Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK9ddf9cc77c43e700cc570cd65a965501,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKca96.8081d043.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 4 MESSAGE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 P-hint: rr-enforced Content-Type: text/plain;charset=UTF-8 Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Content-Length: 1 2



[media server] SIP/2.0 200 OK Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK9ddf9cc77c43e700cc570cd65a965501,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKca96.8081d043.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 4 MESSAGE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Content-Length: 0 [cc] SIP/2.0 200 OK Max-Forwards: 9 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 4 MESSAGE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKca96.8081d043.0 Content-Length: 0 [kunde server] SIP/2.0 200 OK Max-Forwards: 9 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 4 MESSAGE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKca96.8081d043.0 Content-Length: 0 [kunde] MESSAGE sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 7 MESSAGE Route: <sip:129.241.208.134:5060> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Type: text/plain; charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIAMABTAGgAZQBsAGwAJQAyADAARABsAGcAOwAgAEUARgA9ADsAIABDAE8APQAwADsAIABDAFMAPQAwADsAIABQAEYAPQAwAA0ACgANAAoA Content-Length: 1



9 [kunde server] MESSAGE sip:129.241.208.134:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKba96.44d08311.0 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 7 MESSAGE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Type: text/plain; charset=UTF-8;msgr=WAAtAE0ATQBTAC0ASQBNAC0ARgBvAHIAbQBhAHQAOgAgAEYATgA9AE0AUwAlADIAMABTAGgAZQBsAGwAJQAyADAARABsAGcAOwAgAEUARgA9ADsAIABDAE8APQAwADsAIABDAFMAPQAwADsAIABQAEYAPQAwAA0ACgANAAoA Content-Length: 1 P-hint: rr-enforced 9 [cc] MESSAGE sip:129.241.208.142:5060 SIP/2.0 Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK1b968d949430765cb4e2ceecf5d7bd63,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKba96.44d08311.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 7 MESSAGE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 P-hint: rr-enforced Content-Type: text/plain;charset=UTF-8 Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Content-Length: 1 9 [media server] SIP/2.0 200 OK Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK1b968d949430765cb4e2ceecf5d7bd63,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKba96.44d08311.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 7 MESSAGE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Content-Length: 0



[cc] SIP/2.0 200 OK Max-Forwards: 9 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 7 MESSAGE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKba96.44d08311.0 Content-Length: 0 [kunde server] SIP/2.0 200 OK Max-Forwards: 9 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 7 MESSAGE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on> Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bKba96.44d08311.0 Content-Length: 0 [media server] REFER sip:sip:[email protected] SIP/2.0 Max-Forwards: 9 To: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 From: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 1 REFER Via: SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bK35633fea54771a5b04b71c20bd12a0e1 Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on>,<sip:129.241.200.198:15437> Contact: <sip:[email protected]:5060> Refer-To: <sip:sip:[email protected]> Content-Length: 0 [cc] REFER sip:sip:[email protected] SIP/2.0 Max-Forwards: 8 To: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 From: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 1 REFER Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hg4bk8fa0573e3a57107ebd05902e1bfff126,SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bK35633fea54771a5b04b71c20bd12a0e1 Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on>,<sip:129.241.200.198:15437> Contact: <sip:[email protected]:5060>



Refer-To: <sip:sip:[email protected]> Content-Length: 0 [kunde server] REFER sip:129.241.200.198:15437 SIP/2.0 Record-Route: <sip:[email protected];ftag=19934057;lr=on> Max-Forwards: 7 To: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 From: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 1 REFER Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK6729.ef4b89f3.0 Via: SIP/2.0/UDP 129.241.208.134:5060;rport=5060;branch=z9hg4bk8fa0573e3a57107ebd05902e1bfff126,SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bK35633fea54771a5b04b71c20bd12a0e1 Contact: <sip:[email protected]:5060> Refer-To: <sip:sip:[email protected]> Content-Length: 0 P-hint: rr-enforced [kunde] SIP/2.0 200 OK Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK6729.ef4b89f3.0 Via: SIP/2.0/UDP 129.241.208.134:5060;rport=5060;branch=z9hg4bk8fa0573e3a57107ebd05902e1bfff126,SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bK35633fea54771a5b04b71c20bd12a0e1 From: <sip:[email protected]:5060>;tag=19934057 To: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 Call-ID: [email protected] CSeq: 1 REFER Content-Length: 0 [kunde server] SIP/2.0 200 OK Via: SIP/2.0/UDP 129.241.208.134:5060;rport=5060;branch=z9hg4bk8fa0573e3a57107ebd05902e1bfff126,SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bK35633fea54771a5b04b71c20bd12a0e1 From: <sip:[email protected]:5060>;tag=19934057 To: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 Call-ID: [email protected] CSeq: 1 REFER Content-Length: 0 P-NAT-Check: YES [cc] SIP/2.0 200 OK Via: SIP/2.0/UDP 129.241.208.134:5060;rport=5060;branch=z9hg4bk8fa0573e3a57107ebd05902e1bfff126,SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bK35633fea54771a5b04b71c20bd12a0e1 From: <sip:[email protected]:5060>;tag=19934057 To: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 Call-ID: [email protected] CSeq: 1 REFER Content-Length: 0



P-NAT-Check: YES [kunde] BYE sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=7777b507-ac39-4f6c-afc4-18e7d4121eba To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 9 BYE Route: <sip:129.241.208.134:5060> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Proxy-Authorization: Digest username="lkh", realm="iptel.org", algorithm="md5", uri="sip:[email protected];ftag=7777b507-ac39-4f6c-afc4-18e7d4121eba;lr=on", nonce="40c9862b3a4dd0b1b9257f34d947ede011d44bca", response="d9f3e5f2f95f7504014ca0db3769c926" Content-Length: 0 [kundeserver] BYE sip:129.241.208.134:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK4729.890ffbe6.0 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 3 BYE Route: "l"<sip:129.241.208.142:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Length: 0 P-hint: rr-enforced [ccserver] BYE sip:129.241.208.134:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK090df67aef729274f522c9d81f3cbcfc,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK4729.890ffbe6.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 3 BYE Route: "l" <sip:129.241.208.142:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 P-hint: rr-enforced Content-Length: 0 [medieserver] SIP/2.0 200 OK Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on>



Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK090df67aef729274f522c9d81f3cbcfc,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK4729.890ffbe6.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 3 BYE Content-Length: 0 [ccserver] SIP/2.0 200 OK Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK4729.890ffbe6.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 3 BYE Content-Length: 0 [kundeserver] SIP/2.0 200 OK Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=fb473081-7f59-4551-b4c6-c88866e1f9a3;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK4729.890ffbe6.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=fb473081-7f59-4551-b4c6-c88866e1f9a3 To: <sip:[email protected]:5060>;tag=19934057 Call-ID: [email protected] CSeq: 3 BYE Content-Length: 0 [kunde] INVITE sip:[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Proxy-Authorization: Digest username="lkh", realm="iptel.org", algorithm="md5", uri="sip:[email protected]:5060", nonce="40c98637b56fcbe8019328b2f491868ca64c307e", response="eb12d562d422a1a618ffe33af4e074b1" Content-Type: application/sdp Content-Length: 543 v=0 o=lars-3l6ja1sclm 0 0 IN IP4 129.241.200.198 s=session c=IN IP4 129.241.200.198 b=CT:1000 t=0 0 m=audio 38300 RTP/AVP 97 111 112 6 0 8 4 5 3 101



a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:5 DVI4/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 m=video 37422 RTP/AVP 34 31 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 [kundeserver] INVITE sip:[email protected]:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK04fc.57398511.0 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Proxy-Authorization: Digest username="lkh", realm="iptel.org", algorithm="md5", uri="sip:[email protected]:5060", nonce="40c98637b56fcbe8019328b2f491868ca64c307e", response="eb12d562d422a1a618ffe33af4e074b1" Content-Type: application/sdp Content-Length: 543 P-hint: OUTBOUND v=0 o=lars-3l6ja1sclm 0 0 IN IP4 129.241.200.198 s=session c=IN IP4 129.241.200.198 b=CT:1000 t=0 0 m=audio 38300 RTP/AVP 97 111 112 6 0 8 4 5 3 101 a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:5 DVI4/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16



m=video 37422 RTP/AVP 34 31 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 [kundeserver] SIP/2.0 100 trying -- your call is important to us Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Server: Sip EXpress router (0.8.12-tcp_nonb-tls (i386/linux)) Content-Length: 0 Warning: 392 195.37.77.101:5060 "Noisy feedback tells: pid=28110 req_src_ip=129.241.200.198 req_src_port=3019 in_uri=sip:[email protected]:5060 out_uri=sip:[email protected]:5060 via_cnt==1" [ccserver] INVITE sip:129.241.208.56:5060 SIP/2.0 Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK6a1495e0df4d9b3368b9a1950b01e74d,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK04fc.57398511.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Proxy-Authorization: Digest username="lkh",realm="iptel.org",algorithm="md5",uri="sip:[email protected]:5060",nonce="40c98637b56fcbe8019328b2f491868ca64c307e",response="eb12d562d422a1a618ffe33af4e074b1" P-hint: OUTBOUND Content-Type: application/sdp Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Content-Length: 543 v=0 o=lars-3l6ja1sclm 0 0 IN IP4 129.241.200.198 s=session c=IN IP4 129.241.200.198 b=CT:1000 t=0 0 m=audio 38300 RTP/AVP 97 111 112 6 0 8 4 5 3 101 a=rtpmap:97 red/8000 a=rtpmap:111 SIREN/16000 a=fmtp:111 bitrate=16000 a=rtpmap:112 G7221/16000 a=fmtp:112 bitrate=24000 a=rtpmap:6 DVI4/16000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:4 G723/8000 a=rtpmap:5 DVI4/8000 a=rtpmap:3 GSM/8000



a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 m=video 37422 RTP/AVP 34 31 a=rtpmap:34 H263/90000 a=rtpmap:31 H261/90000 [agent] SIP/2.0 100 Trying Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK04fc.57398511.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Content-Length: 0 [ccserver] SIP/2.0 100 Trying Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK6a1495e0df4d9b3368b9a1950b01e74d,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK04fc.57398511.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060> Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Content-Length: 0 [agentr] SIP/2.0 180 Ringing Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK6a1495e0df4d9b3368b9a1950b01e74d,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK04fc.57398511.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Content-Length: 0 [ccserver] SIP/2.0 180 Ringing Max-Forwards: 9 Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK04fc.57398511.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 2 INVITE



Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Content-Length: 0 [kundeserver] SIP/2.0 180 Ringing Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Content-Length: 0 P-NAT-Check: YES [agent] SIP/2.0 200 OK Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK6a1495e0df4d9b3368b9a1950b01e74d,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK04fc.57398511.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Content-Type: application/sdp Contact: "Lars" <sip:129.241.208.56:5060;transport=udp> Content-Length: 146 v=0 o=pats 0 0 IN IP4 129.241.208.56 s=- c=IN IP4 129.241.208.56 t=0 0 m=audio 22224 RTP/AVP 0 3 4 5 6 8 15 m=video 22222 RTP/AVP 26 34 31 [ccserver] SIP/2.0 200 OK Max-Forwards: 9 Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK04fc.57398511.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Content-Type: application/sdp Contact: "Lars" <sip:129.241.208.56:5060;transport=udp> Content-Length: 146



v=0 o=pats 0 0 IN IP4 129.241.208.56 s=- c=IN IP4 129.241.208.56 t=0 0 m=audio 22224 RTP/AVP 0 3 4 5 6 8 15 m=video 22222 RTP/AVP 26 34 31 [kundeserver] SIP/2.0 200 OK Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 2 INVITE Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Content-Type: application/sdp Contact: "Lars" <sip:129.241.208.56:5060;transport=udp> Content-Length: 146 P-NAT-Check: YES v=0 o=pats 0 0 IN IP4 129.241.208.56 s=- c=IN IP4 129.241.208.56 t=0 0 m=audio 22224 RTP/AVP 0 3 4 5 6 8 15 m=video 22222 RTP/AVP 26 34 31 [kunde] ACK sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 2 ACK Route: <sip:129.241.208.134:5060> Route: "Lars"<sip:129.241.208.56:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Length: 0 [kundeserver] ACK sip:129.241.208.134:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=0 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 2 ACK Route: "Lars"<sip:129.241.208.56:5060;transport=udp> Contact: <sip:129.241.200.198:15437>



User-Agent: Windows RTC/1.0 Content-Length: 0 P-hint: rr-enforced [ccserver] ACK sip:129.241.208.56:5060 SIP/2.0 Max-Forwards: 9 Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bK48f3990f8d6755abdb6750453a3a9a5f,SIP/2.0/UDP 195.37.77.101;branch=0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 2 ACK Route: "Lars" <sip:129.241.208.56:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 P-hint: rr-enforced Record-Route: <sip:129.241.208.134:5060>,<sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Content-Length: 0 [kunde] BYE sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on SIP/2.0 Via: SIP/2.0/UDP 129.241.200.198:15437 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 3 BYE Route: <sip:129.241.208.134:5060> Route: "Lars"<sip:129.241.208.56:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Length: 0 [kundeserver] BYE sip:129.241.208.134:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK14fc.26f06e04.0 Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 3 BYE Route: "Lars"<sip:129.241.208.56:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 Content-Length: 0 P-hint: rr-enforced [ccerver] BYE sip:129.241.208.134:5060 SIP/2.0 Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on>



Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bKaca46c025a7ff7d23b5ced6bd8a5bd48,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK14fc.26f06e04.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 3 BYE Route: "Lars" <sip:129.241.208.56:5060;transport=udp> Contact: <sip:129.241.200.198:15437> User-Agent: Windows RTC/1.0 P-hint: rr-enforced Content-Length: 0 [agent] SIP/2.0 200 OK Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Via: SIP/2.0/UDP 129.241.208.134:5060;branch=z9hG4bKaca46c025a7ff7d23b5ced6bd8a5bd48,SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK14fc.26f06e04.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 3 BYE Content-Length: 0 [ccerver] SIP/2.0 200 OK Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Via: SIP/2.0/UDP 195.37.77.101;branch=z9hG4bK14fc.26f06e04.0,SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 3 BYE Content-Length: 0 [kundeserver] SIP/2.0 200 OK Max-Forwards: 10 Record-Route: <sip:[email protected];ftag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8;lr=on> Via: SIP/2.0/UDP 129.241.200.198:15437;rport=3019 From: "lkh" <sip:[email protected]>;tag=77f8dbdc-40b9-41f0-a95c-006d7a5d91c8 To: <sip:[email protected]:5060>;tag=16874657 Call-ID: [email protected] CSeq: 3 BYE Content-Length: 0 P-NAT-Check: YES [agent] REGISTER sip:129.241.208.134:5060;transport=udp SIP/2.0 Call-ID: [email protected] CSeq: 2 REGISTER From: "Lars" <sip:[email protected]:5060;transport=udp>;tag=1506732 To: "Lars" <sip:[email protected]:5060;transport=udp>



Via: SIP/2.0/UDP 129.241.208.56:5060;branch=z9hG4bKb21e241453479a72cfc4202451a8fd7b Max-Forwards: 70 Expires: 0 Contact: "Lars" <sip:129.241.208.56:5060;transport=udp> Content-Length: 0 [ccserver] SIP/2.0 200 OK Call-ID: [email protected] CSeq: 2 REGISTER From: "Lars" <sip:[email protected]:5060;transport=udp>;tag=1506732 To: "Lars" <sip:[email protected]:5060;transport=udp> Via: SIP/2.0/UDP 129.241.208.56:5060;branch=z9hG4bKb21e241453479a72cfc4202451a8fd7b Max-Forwards: 70 Expires: 0 Content-Length: 0 [medieserver] REGISTER sip:129.241.208.134:5060;transport=udp SIP/2.0 Call-ID: [email protected] CSeq: 2 REGISTER From: "l" <sip:[email protected]:5060;transport=udp>;tag=709763 To: "l" <sip:[email protected]:5060;transport=udp> Via: SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bKd370c9313ee5c42c4cfd8762ea0cf629 Max-Forwards: 70 Expires: 0 Contact: "l" <sip:129.241.208.142:5060;transport=udp> Content-Length: 0 [ccserver] SIP/2.0 200 OK Call-ID: [email protected] CSeq: 2 REGISTER From: "l" <sip:[email protected]:5060;transport=udp>;tag=709763 To: "l" <sip:[email protected]:5060;transport=udp> Via: SIP/2.0/UDP 129.241.208.142:5060;branch=z9hG4bKd370c9313ee5c42c4cfd8762ea0cf629 Max-Forwards: 70 Expires: 0 Content-Length: 0

MASTEROPPGAVE - NTNUpeople.item.ntnu.no/~lillk/stud-proj/Hallingstad.pdf · 2004. 6. 17. ·...

Documents

Transcript of MASTEROPPGAVE - NTNUpeople.item.ntnu.no/~lillk/stud-proj/Hallingstad.pdf · 2004. 6. 17. ·...