Arkitektur og SIP-infrastruktur for sanntidsløsninger i UH-sektoren

Transkript

1 Fagspesifikasjon Arkitektur og SIP-infrastruktur for sanntidsløsninger i UH-sektoren Vedlegg: Sanntidstjenester i UNINETT

2 VEDLEGG IV 1 VEDLEGG: SANNTIDSTJENESTER I UNINETT Dette vedlegget dokumenterer sanntidstjenester i UNINETT, og illustrerer bruk av komponenter og prinsipper som er omtalt i selve UFSen. Alle eksemplene på systemløsninger er hentet fra UNINETTs tjenester, slik disse er implementerte tidlig 2017.

3 1.1 UNINETT sanntidstjeneste Programvare Følgende programvare er benyttet i UNINETT Sanntid infrastruktur: Rolle Programvare Lenke SIP proxy KAMAILIO SIP SBC KAMAILIO Registrar KAMAILIO MGW Asterisk B2BUA Asterisk Faks-tjeneste Asterisk KAMAILO Telefonkonferanse Asterisk Videokonferanse KAMAILO Cisco Meeting Server KAMAILIO Mediaproxy RTPEngine SIP tracing SIP Capture HOMER Databasesystem MySQL Databasesystem MariaDB DNS server Bind9 ACL iptables / ip6tables Syslog server rsyslog Syslog lagring og UNINETT analyse LaaS Web-servere Apache2 Versjonskontroll git Logging og monitorering Syslog Syslog er et viktig og godt verktøy for å følge med på logger. Systemer i bruk bør tilstrebe å bruke dette fremfor egne loggfiler for å logge både lokalt og sentralt. Sentral logging ønsker man av flere grunner. Det er ikke gitt at logger er tilgjengelig lokalt etter at en tjeneste f.eks. har krasjet. Med sentralisert logging og gode verktøy på den siden, vil det være mye lettere å søke i logger, analysere, lage grafer og se hvordan f.eks. en hendelse rammer flere av tjenestene. Også metainformasjon om samtaler kan inneholde sensitive data. Syslogging over nettverk til sentrale servere bør gjøres kryptert. I Sanntid logger alle relevante prosesser til en sentralisert syslog-server via TLS. Denne videresender til LaaS som gir den ønskede funksjonaliteten for analyser, grafer og søkbarhet. SIP-sporing 2

4 Noen ganger kan det være behov for å granske et samtaleforløp for å f.eks. å finne ut hvor noe gikk galt. Til det trenger man ofte tilgang til en kopi av selve SIP-pakkene som ble sendt, ikke bare gjennom et bestemt punkt, men også gjennom alle punkt på veien mellom partene. Det finnes verktøy som gjør dette. Det anbefales da at man arkiverer SIP-pakkene på den enkelte server fremfor å sende alt inn til en sentral database. Det sparer nettverkstrafikk og en sentral databasebelastning som kan få kapasitetsutfordringer om det er nok servere som sender inn sine data. Søk i arkivet er ikke noe en gjør veldig ofte. Da er det bedre å la systemet hente inn dataene fra de ulike serverne etter behov. Benytter man SIP over TLS kan sporing og arkivering av SIP by på utfordringer. Kommunikasjonen er kryptert, og man kan kun klare å lese dette med de rette nøkler. Det er allikevel mer hensiktsmessig å la prosessen som gjør jobben med kryptering/dekryptering, sende en kopi til arkivering. I Sanntid benyttes verktøyet Homer til denne oppgaven. Homer kan fungere med en distribuert database og har et webbasert grensesnitt for søk og analyse. Det finnes moduler og applikasjoner til flere forskjellige SIP-produkter om forenkler arkiveringen. Samtalekvalitet For en måling av samtalekvalitet, audio så vel som video, brukes verdien «Mean Opinion Score» (MOS). Dette var opprinnelig beregnet ut i fra subjektive målinger, men er nå for det aller meste erstattet av teknisk beregning. Rangeringen går fra 1 til 5, med 1 som dårlig. Eksempelvis er en verdi på 4.4 ansett som veldig bra for en telefonsamtale, da det er den beste mulige rangeringen å oppnå med mediekompresjonen som brukes for PSTN (G711). Teknisk er det mye som har betydning for kvaliteten på en samtale: Tilgjengelig båndbredde (og type tilknytning) Hvilken mediekompresjon som benyttes Det tekniske utstyret Forsinkelser i nettverket Pakketap Jitter (variasjon i overføringstid) For mediet sendt over RTP har vi også RTCP som kontroll og kvalitetsrapport. Disse kan benyttes til å beregne MOS for en samtale. Det tidligere nevnte verktøyet Homer er i stand til dette, men forutsetter at dens agenter har tilgang til RTCP-flyten og SIP-pakkene. 1.2 Sanntid tale telefoni (PSTN) som en tjeneste For organisasjoner i infrastrukturen er PSTN teknisk å se på som en av flere tjenester. Det er en svært mye brukt tjeneste, men det er like fullt bare et endepunkt for SIP-samtaler. I motsetning til tradisjonelle tanker om hvordan telefoni over SIP leveres, eksisterer ikke konseptet trunk mellom organisasjonene og tjenesten, bare en rute som brukes veldig mye. Definisjonen av en trunk er at det er en ende-til-ende-forbindelse mellom bare to parter som bærer informasjon som senere i kommunikasjonsløpet skal distribueres ut til andre parter. Alle utgående samtaler fra organisasjonen sjekkes mot ENUM. Finnes ikke nummeret der, eller hvis henvendelse mot SIP URI fra ENUM feiler, vil samtalen i stedet gå til tjenesten for PSTN. 3

5 Før det skjer, vil de nødvendige sikringsmekanismer inkluderes for at tjenesten skal akseptere henvendelsen. Samtaleruting til tjenesten er statisk, med støtte for redundant failover. Som et grensepunkt mellom PSTN og SIP, er det viktig at det legges spesielt mye arbeid i sikring i dette punktet mot både misbruk og ulike typer feil. I UNINETT Sanntid er tilgangen til tjenesten spesielt streng, og en rekke autentiserings- og verifiseringsmekanismer begrenser adgangen til kun et utvalg adresser fra autoriserte organisasjoner. Bruk av SIP over TLS med verifisering av sertifikat kan med fordel også brukes i denne sammenhengen. Tjenesten vil gjøre de nødvendige tilpasninger av formatet til SIP for å passe operatørens behov, før samtalen sendes videre på trunken. Innkommende samtaler fra PSTN til en organisasjon rutes ved hjelp av statiske tabeller. Disse tabellene matcher på nummer-prefix slik at en hel serie på f.eks nummer kan matches med en linje i tabellen. Ved match returneres det tilhørende domenet, og så gjøres oppslag i DNS mot NAPTR og SRV på vanlig måte. Dette kunne også blitt gjort med oppslag i ENUM, men siden alle nummer er kjent, gir denne teknikken et raskere oppslag og mye lavere belastning på DNS. Tjenesten vil uansett cache de nødvendige data fra DNS slik at man kan bevare funksjonalitet om sentrale DNS-servere skulle bli utilgjengelige over kortere perioder. Tjenesten vil også gjøre de eventuelle nødvendige omskrivninger av SIP fra operatør før den sender videre til samtalens tilhørende organisasjon. 1.3 Webmøter Adobe Connect Tegningene av systemløsningene viser: Øverst: funksjonalitet Høyre side: samtrafikk mellom UH-institusjoner og andre Nederst: infrastrukturkomponenter Til venstre: klienter og sluttbrukerutstyr UNINETT leverer en webmøtetjeneste basert på Adobe Connect. Tjenesten kan brukes for nettbaserte møter og undervisning. Den støtter flerpartskonferanser i nettleseren med deling av lyd, bilde, chat, dokumenter, skjerm, applikasjoner osv. Adobe Connect er også velegnet for gjennomføring av (større) webinarer. Tjenesten er bygd opp som illustrert under. 4

6 Figur 1: Adobe Connect Brukeren trenger en webklient eller en app, og hele tjenesten bor på en webløsning. Tilgangsstyring bruker Feide for møteverter, mens deltakere også kan få helt åpen tilgang til møtevertens møterom. Både ansatte og studenter kan være møteverter, og det er utstrakt grad av selvbetjening. Løsningen er lik for alle brukere. Institusjonen må være vertsorganisasjon i Feide. For å være møtevert må man logge seg på med Feide. 1.4 Samordnet kommunikasjon Skype for Business Mange universiteter og høgskoler har etablert løsninger for Skype for Business, enten lokalt eller gjennom den felles tjenesten for sektoren. Fellesløsningen er skissert under. Som det fremgår av tegningen, kan løsningen tilpasses hver enkelt institusjon, og lokale utvidelser kan legges til. 5

7 Figur 2: Samordnet kommunikasjon Skype for Business De gule boksene viser komponenter som gjenbrukes fra den felles Sanntids-infrastrukturen. Sanntid leverer samtrafikk med offentlig telenett (SIP-trunk til PSTN), og samordning av taletrafikk mot en rekke systemer. Nummeroppslag gjøres både for innkommende og utgående samtaler. Tilgangsstyring gjenbruker mekanismene i UH-AD, som er en føderert AD-struktur for universiteter og høgskoler. Fordi sluttbrukeren ikke i utgangspunktet bruker en webklient, er det ikke naturlig å bruke Feide-innlogging. Gjennom UH-AD beholder institusjonene brukerkontroll og har egen brukerdatabase. Felles oppsett av Skype for Business (SfB) Sentralt oppsatt, redundant SfB-infrastruktur Føderert med andre SfB-institusjoner Valg av egen sentralbordløsning 6

8 Valg av egne tilleggstjenester for telefoni Institusjon beholder egen brukerdatabase og brukerkontroll PSTN tilknytning via UNINETT Sanntid Knytning mot andre UNINETT-tjenester Gjennom tjenesten Samordnet kommunikasjon forvalter UNINETT leveransen av verktøyet Skype for Business til UH-sektoren. Med Skype for Business kan brukeren samarbeide og ha nettbaserte møter med hvem som helst, på ulike enheter, og fra hvor som helst. Verktøyet tilbyr instant messaging (IM), lyd- og videosamtaler, online møter og deling av bilder, dokumenter og filer generelt, samt deling av skrivebord, programmer og tavle. Fjernstyring av andres skrivebord er mulig. Også de som ikke bruker Skype for Business kan delta på møter, så lenge de har telefon- eller internettforbindelse. Samtaler beskyttes gjennom godkjenning og kryptering. Brukeren kan se påloggingsstatus til sine kontakter, og planlegge møter i Outlook. Skype for Business settes opp med sertifikater for å sikre kommunikasjonen, og sertifikatene leveres av UNINETTs sertifikattjeneste. 1.5 Telefonkonferanser UNINETT telefonkonferanse tilbyr et brukervennlig grensesnitt for å bestille og gjennomføre telefonkonferanser. Den ansvarlige for et møte angir starttidspunkt og varighet for sin telefonkonferanse. Deretter får vedkommende tildelt et konferanserom og en PIN-kode som sikrer konfidensialitet. Dette sender han eller hun så til sine møtedeltakere. Man kan invitere så mange møtedeltakere man ønsker. Den som skal sette opp og invitere til telefonkonferanse må benytte Feide-innlogging. For øvrig kan hvem som helst inviteres til å delta i en oppsatt konferanse. UNINETT telefonkonferanse gir mange valgmuligheter: Man kan planlegge faste tider for telefonkonferanser, for eksempel til en fast tid hver dag, hver uke eller hver måned. På den måten slipper man å bestille sine faste møtetider hver gang. Man kan kreve at møtedeltakere oppgir sitt navn ved innringing. Nye innringere vil da bli annonsert i konferansen, enten ved navneopprop eller lydsignal. Det er mulig å ha en moderator i møtet (som bruker en annen PIN enn møtedeltakerne). En moderator kan regulere lydnivået opp og ned, skru lyd av/på, eller kaste ut siste ankomne møtedeltaker osv. Man kan bestille telefonkonferanse direkte fra egen kalender. Systemet vil oppdatere kalenderinnslag med informasjon om konferanserom og PIN. Også andre inviterte møtedeltakere vil få denne informasjonen via kalenderen UNINETT telefonkonferanse tilbyr integrasjon med kalender. Her baserer vi oss på icalendar 2.0-formatet, som er støttet av mange større kalender- og e-postsystemer, herunder Microsoft Exchange/Outlook, Google Gmail/Calendar og Mozilla Thunderbird/Lightning. For å delta på konferansen må møtedeltakerne ringe inn til: Telefonnr: , eller: SIP: conference@uninett.no 1.6 Videobro som sanntidstjeneste Videosamtaler er kanskje mer utbredt brukt med flerpartsdeltakelse enn ved telefoni. I motsetning til telefoni hvor det i praksis bare dreier seg om å samle alle lydbølgene og 7

9 distribuere dette som en mediestrøm, har video i tillegg behov for mer båndbredde og en måte å organisere eller samordne de ulike videobildene. Enkelte tjenester har denne funksjonaliteten innebygget. Det finnes også flere selvstendige tjenester basert på deltakelse via en spesielt utviklet klient og/eller WebRTC. Men igjen er det ulike standarder i bruk og også forskjellige metoder. Mens noen systemer bare samler alle videostrømmene til en mosaikk i et samlet bilde, vil andre bruke flere videostrømmer på ulike måter. I en infrastruktur kan det være aktuelt å levere en tjeneste hvor brukere kan møtes via video. Det er da viktig å vurdere behovene til brukerne og møte disse. Idealet om tilgjengelighet på tvers av ulike plattformer kan i praksis være vanskelig å møte. Man er ikke bare begrenset av de ulike protokollers manglende kompatibilitet, men også de tekniske mulighetene til endeutstyret. Tema som vil være gjenstand for en vurdering: Brukergrupper og omfang i samtidighet, både for løsningen som helhet og for det enkelte møtet. Støtte for de mest brukte protokoller og klienter: SfB, SIP, H323 og WebRTC. Støtte for IPv6 i tillegg til IPv4. Støtte for integrasjon med andre systemer, f.eks. for brukerautentisering, læringssystemer, opptak, streaming, m.m. Støtte for spesielle funksjoner tilpasset sin brukergruppe, f.eks. break-out, voting, chat, presentasjonsdeling/skjermdeling, m.m. Sikring av løsningen som helhet, brukere og det enkelte møterom. Det finnes flere ulike løsninger på markedet som dekker ulike behov: Virtuelle møterom med WebRTC der alle klienter må være WebRTC Virtuelle møterom hvor deltakelse er primært via en dedikert klient eller nettleser utvidelse. Kanskje også støtte for deltakelse fra andre, kjente systemer som SfB, SIP og H323. Virtuelle møterom uten støtte for deltakelse med nettleser. Brofunksjonalitet for oversettelse mellom ulike typer system (MGW). En kombinasjon av både brofunksjonalitet og virtuelle møterom, både med og uten deltakelse via nettleser. Noen av disse løsningene er skybaserte og noen baserer seg på installasjon på egen plattform. Det er også flere selskaper som har installert en løsning på egen plattform og selger dette som en skytjeneste. Hvor godt en slik løsning kan integreres med egen infrastruktur er opp til hva det enkelte produkt kan levere. Men for en løsning som støtter SIP enten som en innkommende forbindelse eller mer gjennomført, vil det være mulig å benytte infrastruktur med domenebasert ruting til også å rute samtaler inn til løsningen ved hjelp av egne domener. Rollen til proxy vil i så fall være å videreformidle til tjenesten, eventuelt med de nødvendige omskrivninger av URI og protokoller. For et produkt som kan fungere som en bro mellom ulik teknologi, kan den også utnyttes til å ha en rolle som en MGW og på den måten gi konnektivitet mellom ulik teknologi, f.eks. mellom H.323 og SIP eller Skype for Business og SIP. 8

10 H323 SfB Bro og virtuell møteplass Proxy SBC WebRTC UNINETTs tjeneste Videobro er en tjeneste som skal forenkle bruken av video for kommunikasjon og møter. Den gir en virtuell møteplass for flerparts videokonferanse. Tjenesten oversetter mellom ulike formater, og gjør det mulig for ulike typer endeutstyr å snakke sammen. Den gir en sømløs oversettelse mellom SIP- og Skype for Business-klienter. Tjenesten gir oversettelse mellom videosystemer av ulik type: Skype for Business, SIP, H.323 og WebRTC samt også deltakelse fra telefon, slik at det er mulig for disse å kommunisere sammen. Dette gjøres med en tett integrasjon med UNINETT Sanntid, som blant annet gir en sømløs oversettelse mellom Skype for Business/Lync og SIP, og et URI-format for adressering som inngår i den domenebaserte strukturen som er innført gjennom UNINETT Sanntid. Skype for Business Ekstern SfB klient SfB Klient Ekstern Skype klient SfB Edge SfB Front End SfB Mediation Server WebRTC WebRTC web-server Videobro kjernefunksjon / bro Sanntid TURN server Videobro SIP Proxy + H323 Gatekeeper for tjenesten Organisasjoners SBC / Proxy registrar.uninett.no Ekstern H323 IP UA H323 UA Ekstern SIP IP UA Ekstern SIP UA / PSTN SIP UA Tjenesten tilbyr tre valgfrie hovedfunksjoner: 1. Virtuelle møterom. Det tilbys ubegrenset antall virtuelle møterom. 2. Bro mellom videoendepunkter, eksempelvis slik at Skype for Business-brukere kan nås fra andre videoendepunkter. 9

11 3. Sluttbrukere som klienter direkte på Videobro. Oversettelse mellom videosystemer av ulik type krever bruk av kanaler. Den årlige tjenesteavgiften for tjenesten baserer seg på abonnement av disse kanalene. Det settes i utgangspunktet ikke en hard grense for begrensning av bruk av kanaler, men den enkelte kunde kan selv velge å låse maksimalt tillatte brukte kanaler. Videobro er en felles oversettelsesfunksjon som setter de fleste typer systemer i stand til å snakke video med hverandre. Figuren under viser komponentene i Videobro, og hvordan denne gjenbruker eksisterende infrastrukturelementer. Videobro kobler sammen mange typer klienter, og gjør det mulig å kommunisere uten å vite hvilken type system de i andre ender bruker. Figur 3: Videobro 10

12 Videobro må fungere med et minste felles multiplum av løsninger, og siden det er både mange løsninger og mange generasjoner av løsningstyper, så blir minimum ganske lite. For tilgangskontroll er det stort sett bare delt hemmeligheter (i praksis PIN-koder) som kan brukes, fordi spennet av klienter og implementasjon er så stort. Siden Videobro kan snakke med mange typer systemer, er det mulig å plugge inn funksjonalitet fra eksterne løsninger, enten direkte i videobroen som illustrert med Mediasite Join eller fra ulike leverandører som illustrert øverst til høyre. 11

13 Adresse: 7465 Trondheim Sentralbord: E-post: Web: