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

Transkript

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

2 Arkitektur og SIP-infrastruktur for sanntidsløsninger i UH-sektoren UFS nr.: 151 Versjon: 0.72 Status: Utkast Dato: Tittel: Arkitektur og SIP-infrastruktur for sanntidsløsninger i UHsektoren Forfattere: Ingrid Melve, Jardar Leira, Magnus Strømdal, Thorleif Hallén, Håvar Fosstveit Ansvarlig: UNINETT Kategori: Anbefaling

3 Sammendrag Dette dokumentet inneholder dokumentasjon av felles infrastrukturkomponenter for bruk i sanntidskommunikasjon for universiteter og høgskoler, samt beskrivelse av hvordan ulike tjenester for samhandling bruker disse felleskomponentene. Dokumentet er utarbeidet i forbindelse med ecampus-programmet, og tar derfor utgangspunkt i brukerkrav knyttet til utdanning og læring. Grunnleggende krav til en sanntidskommunikasjonsinfrastruktur: Det må tilbys samtrafikk med alle aktuelle parter Det må tilbys konfidensialitet Det må tilbys dataintegritet Det må være en tilgjengelighet og nåbarhet Det må være støtte for åpne standarder, åpne grensesnitt og åpne protokoller Komponentene bør være modulære og gjenbrukbare De generelle arkitekturprinsippene for UH-sektoren innebærer at infrastrukturkomponenter bør realiseres ved bruk av: Felleskomponenter som er nåbare fra mange tjenester, og som kan gjenbrukes Applikasjonstjenester som kan deles mellom mange institusjoner, realisert enten i UHsky eller offentlig sky Tilgangskontroll som i størst mulig grad gjenbrukes fra Feide, UH-AD og andre etablerte mekanismer SIP som protokoll for å sette opp sanntidskommunikasjon ENUM som mekanisme for nummeroppslag for samtaleruting Gjenbruk av sikkerhetsmekanismer fra andre tjenester: sertifikater, brannmur, rutingkontroll, nettovervåkning Sanntidstjenester som har bruk for brannmurtraversering må gjøre vurdering av mekanismer (statiske tunneler mellom gatewayer, STUN/TURN) sammen med sikkerhetsvurdering 2

4 Innholdsfortegnelse 1 DOKUMENTSTRUKTUR DETTE DOKUMENTET FAGSPESIFIKASJONER FOR UTSTYR OG KRAV TIL ROM 7 2 ENDRINGER I DENNE REVISJONEN 7 3 AVGRENSINGER 7 4 HVA ER SANNTIDSTJENESTER BAKGRUNN KRAV TIL INFRASTRUKTUR FOR SANNTIDSTJENESTER KOMPONENTER FOR SANNTIDSINFRASTRUKTUR 9 5 SITUASJONSBESKRIVELSE SAMHANDLING OG SAMTRAFIKK SKYTJENESTER OG SANNTIDSLØSNINGER VALG AV SIP SOM PRIMÆR PROTOKOLL FOR EN SANNTID INFRASTRUKTUR GJENBRUK AV FELLESKOMPONENTER OG ANNEN INFRASTRUKTUR IPV LOGGING OG OVERVÅKING 14 6 ARKITEKTUR ARKITEKTURPRINSIPPER FOR UH-SEKTOREN INSTITUSJONSBEHOV BRUKERBEHOV INFRASTRUKTURKRAV 17 7 EN SIPBASERT INFRASTRUKTUR FOR SANNTID TEKNISKE ROLLER I SIP DNS FOR SIP I SANNTID SIP HOS ORGANISASJONEN SIP FOR EN TJENESTE SANNTID SOM SIP-INFRASTRUKTUR SÆRLIGE HENSYN VED BRUK AV SIP-PROTOKOLL DIALEKTER AV SIP-STANDARDEN UDP SOM TRANSPORT NETTVERKSTRAVERSERING FOR RTP SIKKERHET MED SIP TELEFONIFUNKSJONER I INFRASTRUKTUREN TEKNISK TILKNYTNING MOT OPERATØR NUMMERPLAN: E NUMMEROPPSLAG: ENUM TJENESTER SOM ER REALISERBARE MED PSTN OG ENUM 31 8 REFERANSER 33 9 DEFINISJONER OG TERMINOLOGI 35 3

5 10 VEDLEGG: SANNTIDSTJENESTER I UNINETT UNINETT SANNTIDSTJENESTE PROGRAMVARE LOGGING OG MONITORERING SANNTID TALE TELEFONI (PSTN) SOM EN TJENESTE WEBMØTER ADOBE CONNECT SAMORDNET KOMMUNIKASJON SKYPE FOR BUSINESS TELEFONKONFERANSER VIDEOBRO SOM SANNTIDSTJENESTE 43 4

6 Endringslogg: Versjon Dato Kapitler Endring Ansvarlig Godkjent Alle Struktur på denne anbefalingen IM/JL 0.2 Alle Fyller på med innhold JL/SO Alle Endring av struktur og en del nytt IM/TH innhold Alle Tegninger av komponenter og tjenester IM Alle Revisjon av tegninger IM/JL Alle Samlet fremstilling av komponenter IM Alle Tekstgjennomgang, rydding av IM, MS struktur , Vedlegg Informasjon om SIP og strukturer JL, HAF 1,2 knyttet til SIP Alle Sammensying av informasjon, restrukturering IM av SIP-kapittel , alle Kvalitetssikring av SIP-kapittel, JL generelle kommentarer faglig Alle Språkvask SME, LF 0.8 Alle Versjon til høring i UH-sektoren 0.9 Alle Kommentarer fra høringsrunde 0.91 Alle Kvalitetssikring 0.92 Alle Språkvask etter revisjon 1.0 Alle Publisert versjon Arbeidsgruppen som har jobbet med denne anbefalingen er fra prosjektet knyttet til arbeidet med digital eksamen, og har hatt følgende deltakere: Ingrid Melve, UNINETT Jardar Leira, UNINETT Thorleif Hallén, UNINETT Håvar Aambø Fosstveit, UNINETT Magnus Strømdal, UNINETT I tillegg er grunnlagsarbeid for dokumentet også utført av Jan Meijer, UNINETT Simon Skrødal, UNINETT Stefan Otto, UNINETT Vidar Faltinsen, UNINETT 5

7 I INTRODUKSJON Det er utarbeidet fagspesifikasjoner (UFS) som beskriver anbefalte løsninger og beste praksis i universitets- og høgskolesektoren. De anbefalte løsningene er basert på erfaringer samlet inn gjennom arbeidssamlinger og teknisk arbeid. UNINETT har i regi av ecampus-programmet arbeidet spesielt med bruk av sanntidstjenester for undervisning, men anbefalingene i dette dokumentet gjelder også generelt for sanntidstjenester. UFS-dokumentene er ment å være arbeidsverktøy ved planlegging av og tilrettelegging for gjennomføring av undervisning, læring, møter og samtaler over nett. Målgruppen er primært teknisk personell og rådgivere som har ansvaret for disse oppgavene. Dette dokumentet fokuserer på krav som stilles til sanntidsinfrastruktur. Krav til programvare, servere, virtualiseringsløsninger, brannmurer og overvåkingsløsninger følger av hvilke programvareløsninger som velges. 6

8 1 DOKUMENTSTRUKTUR 1.1 Dette dokumentet Dette dokumentet beskriver: Bakgrunn for sanntidsarkitektur (kap. 4 5) Sanntidsarkitektur (kap. 6) Implementasjon av sanntidsarkitektur basert på SIP-protokollen (kap. 7) 1.2 Fagspesifikasjoner for utstyr og krav til rom Sanntidskommunikasjon har behov for f.eks. mikrofoner og kamera. Krav til klientutstyr og rom for bruk av AV-utstyr er beskrevet i en serie fagspesifikasjoner: UFS 116: Funksjonsbeskrivelse AV-utstyr for undervisnings- og møterom Anbefalinger for AV-utstyr, herunder sanntidsutstyr og støttefunksjoner (Støfringsdal, Funksjonsbeskrivelse AV-utstyr for undervisnings- og møterom (UFS116), 2013). UFS 119: Tekniske og funksjonelle systemkrav for AV-utstyr Felles støttedokument for UFS116 og UFS120, dokumenterer tekniske og funksjonelle systemkrav for de ulike komponentene (Støfringsdal, Teknisk og funksjonelle systemkrav for AV-utstyr (UFS119), 2013). UFS 120: Driftsstøttesystem og overføring av lyd og bilde Støttedokument for UFS116, omhandler felles ressurser for flere rom som benyttes i forbindelse med driftsstøtte og overføring av lyd og bilde. (Støfringsdal, Driftstøttesystem og overføring av lyd og bilde (UFS120), 2011). 2 ENDRINGER I DENNE REVISJONEN Dette er en høringsversjon av denne anbefalingen (UFS 151). For oversikt over tidligere revisjoner i utarbeidelse av dokumentet, se tabell etter innholdsfortegnelsen. 3 AVGRENSINGER Denne anbefalingen fokuserer på arkitektur for sanntidsløsninger på tvers i UH-sektoren, og dokumenterer forhold knyttet til infrastruktur og teknologi. Institusjonsinterne forhold og løsninger er ikke diskutert. Dokumentet beskriver løsninger ut i fra en rolle som transportør av telefoni og ikke som operatør for telefoni. For en operatør av offentlig telenett, stilles det juridiske og tekniske krav som ikke diskuteres. Det blir heller ikke diskutert problemstillinger relatert til knytning mot det offentlige telenettet som går utover kravene til nødvendig samtrafikk. En følge av at institusjonsinterne løsninger og offentlige telenett ikke drøftes, er at hverken fakturering eller lovpålagt avlyttingsløsninger/logging som omtalt i Ekom-loven (Samferdselsdepartementet, 2015) er omtalt i dokumentet. Klientløsningene er kun drøftet i det omfang som er nødvendig for å klargjøre krav til sanntidsløsninger på tvers i UH-sektoren. Arkitekturprinsippene for UH-sektoren (Bergh-Hoff, et al., 2015) er lagt til grunn for arbeidet. 7

9 GRUNNLAG II 4 HVA ER SANNTIDSTJENESTER 4.1 Bakgrunn Sanntidstjenester er i dette dokumentet brukt til å beskrive tjenester som tilbyr sluttbrukeren flerveiskommunikasjon som er helt eller tilnærmet umiddelbar mellom to eller flere parter, for eksempel telefoni og videosamtaler. Ulike behov og historie har ført til at det i dag finnes mye ulik teknologi og metoder for å løse ikke bare ulike oppgaver, men også samme oppgaver. Historisk eksisterte telefoni, eller «Public switched telephone network» (PSTN), lenge før Internett, og disse har lenge levd som parallelle nettverk. Med moderne og raske nett har mye av telefonien beveget seg over til å flyte over Internett. Samtidig eksisterer deler av mer tradisjonell telefoniinfrastruktur for å støtte eldre teknisk utstyr. Videokommunikasjon har før vært brukt via telenettet eller dedikerte linjer, mens den nå nesten utelukkende er å finne på Internett. Med Internett har det også dukket opp mange muligheter for tekniske løsninger. Alt dette bidrar til å øke kompleksiteten og utfordringene med gjensidig kommunikasjon på tvers av ulike løsninger. For brukerne er det mange løsninger å velge mellom, og ikke alle snakker godt sammen. 4.2 Krav til infrastruktur for sanntidstjenester Det er svært mange tjenester og løsninger som skal spille sammen for å gi gode brukeropplevelser og nyttige tjenester innen sanntidsområdet. I dette dokumentet bryter vi ned kompleksiteten og ser på mulighet for bruk av moduler. Modulære løsninger gir mulighet for gjenbruk og enkel oppgradering gjennom å bytte ut mindre deler av løsningen, samtidig som det er enklere å bruke eksisterende tjenester og funksjonalitet inn i løsningene. En helhetlig tilnærming til sanntidstjenestene sikrer at både samtrafikk, adressering og trafikkflyt følger beste praksis. Infrastrukturen bør ikke gjøre forskjell på typen sanntidskommunikasjon (samtaleinnhold og samtaleform), men legge til rette for nåbarhet gjennom enhetlig adressering. Der sanntidsteknologien som tilknyttes ikke følger de grunnleggende prinsippene, bør det suppleres med ulike former for oversettere i tilknytningen (se Figur 1). Blant de grunnleggende prinsippene har vi at normal Internett-ruting av datatrafikk skal kunne benyttes og at samtaleinnhold skal kunne gå så direkte som mulig mellom partene. Med dette oppnås en global nåbarhet og tilknytning av tjenester som da kan leveres av hvem som helst lettes, noe som legger til rette for varierte sourcingstrategier. 8

10 Tjeneste Oversetter Tjeneste Tjeneste Endepunkt Oversetter Tjeneste Figur 1: En infrastruktur av tjenester og endepunkt med kompatibel kommunikasjon. Oversettere for tjenester som ikke er kompatible Det er noen grunnleggende krav til en slik infrastruktur: Det må tilbys samtrafikk med alle aktuelle parter. Det må tilbys konfidensialitet. Det må tilbys dataintegritet. Det må være en tilgjengelighet og nåbarhet. Det må være støtte for åpne standarder, åpne grensesnitt og åpne protokoller. Komponentene bør være modulære og gjenbrukbare. 4.3 Komponenter for sanntidsinfrastruktur Figur 2 viser infrastrukturkomponenter for sanntidskommunikasjon. Klientene kan være nettbrett, telefon eller PC. Klientene kommuniserer enten direkte med tjenesten, eller via offentlige telenett (direkte med tjenesten er vist via teknisk samtrafikk for å forenkle oversikten, siden det er et utall ulike tjenester). Komponentene vist i gult er etablert for UH-sektoren. En typisk samtale vil bruke komponentene: Ønske om samtale sendes til tjenestens samtrafikkpunkt. Nummeroppslag gjøres for å nå riktig person/utstyr i andre enden. o Nummeroppslag kan benytte ENUM-protokollen. Samtalen settes opp gjennom ruting for samtalekontroll. o SIP benyttes for å sette opp samtale. o Eventuell oversettelse av samtaleinnpakking gjøres i Medie-GW. o Eventuell tilgangsstyring kan kreve koder fra brukeren. Samtaleinnholdet sendes over. o Eventuell oversettelse av samtaleinnhold gjøres i Medie-GW. o Eventuell støtte til nettverkstraversering. Samtale avsluttes gjennom ruting for samtalekontroll. 9

11 Figur 2: Infrastrukturkomponenter for sanntidstrafikk De gule komponentene utgjør til sammen funksjoner for å koble sammen sanntidstjenester for UH-sektoren, enten det er tale (som i telefoni) eller mer sammensatte kommunikasjonstyper. Nummeroppslag: For å nå frem til riktig person, er det nødvendig å gjøre et oppslag av nummer, og her har UNINETT en ENUM-komponent som holder informasjon om UH-sektorens nummer. Både utgående og inngående samtale bruker nummeroppslag. Ruting, samtalekontroll: Som vist på tegningen kan samtaler initieres enten innenfra UHsektoren (heltrukken linje) eller utenfra (stiplet linje). De tekniske komponentene for samtrafikk sikrer at dette er usynlig sett fra sluttbrukeren. Ruting, samtaleinnhold: Innholdet i samtalen kan ha behov for nettverkstraversering for å slå (kontrollerte) hull gjennom brannmurer og lignende. Innholdet i samtalen kan ha behov for oversettelse mellom ulike formater og innpakninger, og dette kan gjøres i en felles medie-gateway (merket Medie-GW på tegningen over). Tilgangsstyring: For UNINETT Sanntid er her vist kun tilgangsstyring med delt hemmelighet, siden dette er det minste felles multiplum for sanntidstjenester. For andre tjenester vil det være aktuelt med gjenbruk av funksjonalitet fra UH-AD og/eller Feide, men dette er avhengig av støtte i endesystemene. Bruk av TLS med sertifikatautentisering er også en mulighet. 10

12 5 SITUASJONSBESKRIVELSE 5.1 Samhandling og samtrafikk Sanntidstjenester lever i et sammensatt landskap av svært mange komponenter som alle må fungere godt sammen for at brukerne enkelt skal kunne snakke sammen. Økningen i kompleksitet utløser et behov for å se på hvordan løsninger aktivt spiller sammen for å bygge opp under undervisning, samarbeid og læringsmiljø. Situasjonen i dag er at det er et villnis av systemer, og villniset vokser. Selv om noen løsninger (for eksempel Skype for Business) er mye brukt, er det alltid partnere utenfor egen institusjon som har andre løsninger. Det vil derfor være behov for oversettelsesfunksjonalitet, felles standarder og at flere systemer kan brukes samtidig. Figur 3: Funksjonalitet i samordnet kommunikasjon Det skjer en stor økning i bruken av sanntidskommunikasjon, med økende krav ut over det å snakke sammen supplert med video. De fleste institusjonene bruker videokonferanse for utdanningsformål i noen utvalgte fag, og noe bruk av videokonferanse for møteformål. Samhandlingsløsninger og samarbeidsverktøy befinner seg i et sammensatt landskap av svært mange komponenter som alle må fungere godt sammen for at brukerne enkelt skal kunne snakke sammen. Økningen i kompleksitet utløser et behov for å se på hvordan løsninger aktivt spiller sammen for å bygge opp under undervisning, samarbeid og læringsmiljø. For å illustrere den økende kompleksiteten, gjengis det i tabellen eksempler på mye brukte kommunikasjonsteknologier og deres iboende muligheter til å kommunisere med de andre løsningene. SIP H.323 WebRTC Skype (privat) Skype for Business Fasttelefoni Mobiltelefoni SIP Ja Nei Nei 1 Nei Nei Nei Nei H.323 Nei Ja Nei Nei Nei Nei Nei WebRTC Nei 1 Nei Ja/Nei 2 Nei Nei Nei Nei Skype (privat) Nei Nei Nei Ja Ja 3 Ja 4 Ja 4 Skype for Business Nei Nei Nei Ja 3 Ja Ja 5 Ja 5 11

13 SIP H.323 WebRTC Skype (privat) Skype for Business Fasttelefoni Mobiltelefoni Fasttelefoni Nei Nei Nei Nei Ja 5 Ja Ja Mobiltelefoni Nei Nei Nei Nei Ja 5 Ja Ja 1. WebRTC er en web-protokoll mellom klient og tjener og ikke en sanntidsprotokoll i seg selv. Men den bruker ofte SIP til dette. Det er da bare som en innkapslet protokoll mellom klient og tjener. 2. To ulike tjenester med WebRTC kan i utgangspunktet ikke snakke direkte med hverandre. 3. Skype og Skype for Business kan kommunisere med hverandre dersom Skype privat-kontoen er av Microsofttypen (ikke den opprinnelige typen) og Skype for Business-installasjonen har føderert med Skype. 4. Muligheten til å ringe til fasttelefoner og mobiltelefoner er tilgjengelig som ekstratjeneste. 5. Krever at Skype for Business har installert de nødvendige komponenter, har de nødvendige ekstra lisenser (Enterprise Voice) og en tilknytning mot en telefonitilbyder. 5.2 Skytjenester og sanntidsløsninger Vi har sett en rask vekst i bruk av skytjenester også for sanntidsområdet. UNINETT har koordineringsansvar for UH-skyprogrammet (UNINETT, 2016) som skal gjøre skytjenester tilgjengelig og avklare forhold knyttet til anskaffelse og bruk av skytjenester. Mobile enheter, sanntidsklienter og webmøter bruker oftere skytilnærming for tjenesteleveranser. Mange skytjenester, spesielt SaaS (Software-as-a-Service), er rent webbaserte tjenester, mens noen kan enten ha egne klienter for PC/Mac eller apper for mobil og nettbrett. Både fra teknologitrender for sanntidstjenester (som WebRTC-utviklingen) og fra skytjenesteutbredelse kommer det sterke føringer i retning av at mest mulig funksjonalitet skal ha brukergrensesnitt i webleseren, mens tjenesten består av et sett moduler i nettet som kalles inn etter behov. Analysene rundt WebRTC-teknologi viser at det er i ferd med å skje store endringer innen samarbeidstjenester (Meijer & Skrødal, WebRTC Requirements and R&E Deployment Roadmap, 2016). Denne analysen fant flere endringer knyttet til forhold som er viktige for utdanning: Enklere å bruke samarbeidstjenestene som blir tilgjengelige i nettlesere fra skyen. Enkelt å legge samarbeidstjenester (WebRTC) inn som del av en arbeidsflate, lett å få som del av webtjenester, lett å flytte data til/fra tjenestene. Skytjenester er tilgjengelige i stort omfang, og det er både spesialiserte samarbeidsverktøy og hele pakker som f.eks. Office365. Leveranseplattform for UNINETTs sanntidstjenester er etablert i en privat sky, der IaaS (Infrastructure-as-a-Service) benyttes for skalering og effektiv drift. 5.3 Valg av SIP som primær protokoll for en sanntid infrastruktur De to bruksområdene som først ble identifisert var telefoni og videosamtaler. Senere har også webmøter kommet som en mye brukt tjeneste. Vi har identifisert Session Initiation Protocol (SIP) som den mest brukte protokollen på dette området. SIP er i utgangspunktet standardisert gjennom RFC 3261, men SIP har også svært mange tilleggsstandarder og i praksis også flere mer eller mindre proprietære variasjoner tilpasset av produsenter. SIP er en av flere mulige protokoller som også ofte brukes til signalering i forbindelse med WebRTC, og den benyttes i moderne mobiltelefoni gjennom «IP Multimedia Subsystem» (IMS). SIP har vist seg som en robust og fleksibel protokoll som gjennom svært mange implementasjoner viser en sterk vekst. 12

14 H.323 er en protokoll fra «ITU Telecommunication Standardization Sector» (ITU-T) som teknisk kan oppfylle mange av de samme behovene som SIP for både telefoni og video. Tradisjonelt har denne protokollen vært sterkere representert enn SIP i videokommunikasjon. Det er gode argumenter for begge alternativene, men den sterke veksten av SIP spås å utkonkurrere H.323 allerede på kort sikt. H.323 er fortsatt anbefalt i Standardkatalogen (Difi, 2016) av hensyn til kommunikasjon med gammelt utstyr. I SIP kan det benyttes flere typer transportprotokoller for mediestrømmene. Den vanligste er Real-Time Transport Protocol (RTP). RTP benyttes over UDP-protokollen fordi dette er en tidskritisk overføring. Det er viktigere at pakkene kommer frem raskt enn at det er noen som mangler. Det er da to adskilte RTP-strømmer som går. En strøm kommer fra hver av partene til den porten som den mottakende part har angitt som tilgjengelig for medietrafikk. I tillegg går det RTP Control Protocol (RTCP) periodisk som kontroll og for løpende rapport på kvalitet. I noen sammenhenger kan det være andre mekanismer for nettverkstraversering som gjør denne RTP-utvekslingen mindre synlig på nettverket. Dette fordi RTP i stedet sendes på andre måter, f.eks. gjennom en form for TCP-basert tunnel. 5.4 Gjenbruk av felleskomponenter og annen infrastruktur IPv6 Alle offentlig tilgjengelige tjenester bør ha støtte for IPv4 og IPv6 (Difi, 2016). Selv om dette er et mål, er det i praksis ikke like lett. Operatører av offentlig telefoni har f.eks. sjeldent støtte for dette. Mye utstyr og programvare mangler også fortsatt denne støtten. SIP kan fint benyttes over IPv6. Den forutsetter da IPv6-adresser også for RTP i ymse tabeller og aksesslister. Det er teknisk relativt uproblematisk å bygge tilsvarende og helt selvstendige infrastrukturer basert på IPv4 eller IPv6. Utfordringene kommer når det skal være en sameksistens. Om en part med IPv4 skal kommunisere med en part på IPv6, så kreves det en oversettelse som krever en fullstendig omskrivning av alle IP-adresser en omskrivning som kan minne om nivået på omskrivningen mellom NAT og rutebare nett. Det innebærer blant annet bruk av MGW/medieproxy og en proxy på veien som har støtte for både IPv4 og IPv6 med støtte for den nødvendige håndteringen. Adressering og nåbarhet vil også kunne medføre praktiske utfordringer. Når man skal kommunisere med en ekstern part, er det ikke gitt at man kjenner til den andre parts preferanser og tilgjengelighet før man har prøvd. Velger man da å prøve IPv6 først, for så å eventuelt feile, og deretter prøve med IPv4? Eller velger man omvendt? Hvis den andre parten har gjort en god jobb med riktige registreringer i DNS, kan mye være løst. Men ikke alt utstyr og programvare støtter en slik failover. Vår anbefaling er at det bør være støtte for IPv6 ved bygging av en infrastruktur for samordnet kommunikasjon, og planleggingen av dette bør foregå parallelt med planleggingen av støtten for IPv4. Å legge til støtten i ettertid kan bety mye tilleggsarbeid og kanskje en ikke fullt så dynamisk løsning. Ta gjerne utgangpunkt i en parallell og selvstendig infrastruktur basert på IPv6, men med strategiske samtrafikkpunkter og funksjoner for nødvendig oversettelse mellom IPv4 og IPv6. Dette kan f.eks. koordineres i samme prosesser som oversetter mellom RTP/SRTP og som ellers har rollen som B2BUA. Det bør være et langsiktig mål om at IPv6 over tid skal være den dominante protokollen for infrastrukturen. 13

15 5.4.2 Logging og overvåking God logging og overvåking av tjenestene er viktig for å kunne ivareta en god kvalitet og minimere nedetid. Det er også viktig for å dokumentere og oppdage uønsket adferd, og det er til god hjelp når man i ettertid trenger å gjøre feilsøking. Det er lurt å planlegge den tekniske strategien for logging og overvåking tidlig. Senere kan det bli vanskeligere å implementere optimalt. 14

16 6 ARKITEKTUR 6.1 Arkitekturprinsipper for UH-sektoren Arkitekturprinsippene for UH-sektoren (Bergh-Hoff, et al., 2015) bygger på Overordnede ITarkitekturprinsipper for offentlig sektor (Difi, 2012), og konkretiserer prinsippene innenfor de syv områdene tjenesteorientering interoperabilitet tilgjengelighet sikkerhet åpenhet fleksibilitet skalerbarhet Kritisk viktige områder for sanntidstjenestene er åpenhet, fleksibilitet, interoperabilitet og tjenesteorientering. Samtidig må sikkerhet, skalerbarhet og tilgjengelighet ivaretas også for sanntidstjenester. Av de mest sentrale kravene for sanntidstjenester, spesielt når det skal sikres samtrafikk på tvers av ulike løsninger, er: Grensesnitt som er åpne standarder brukes der de finnes, sekundært åpne grensesnitt. Åpne grensesnitt og formater er sikret gjennom krav. IKT-løsninger og komponentene de består av er tilstrekkelig modularisert, løst koblet og benytter veldefinerte åpne grensesnitt. Standardiserte grensesnitt og protokoller brukes der de finnes. Fellestjenester som tilfredsstiller målgruppens behov brukes der slike eksisterer. 6.2 Institusjonsbehov Universiteter og høgskoler har behov for at ansatte, studenter og samarbeidspartnere kan jobbe sammen over nett. Institusjonene legger til rette for et begrenset sett løsninger, innenfor sine økonomiske, brukervennlige og sikkerhetsmessige rammebetingelser. Universiteter og høgskoler har en svært stor kontaktflate nasjonalt og internasjonalt, og mye kommunikasjon krysser organisasjonsgrenser. Samarbeid er viktig, og det er svært mange forskningsprosjekter. Dette skiller UH-institusjonene fra tradisjonelle bedrifter, der mye mer av kommunikasjonen skjer enten internt eller som en kunderelasjon. Konsekvensen er at bedriftsløsninger ikke alltid er tilpasset behovet for det høye antallet samarbeidspartnere i UH-sektoren. Brukerne har stor frihet i hvordan de arbeider, og fagnære løsninger kan ha helt spesielle behov. Samtidig har UH-institusjonene behov for kostnadskontroll og å ivareta regelverk, for eksempel for informasjonssikkerhet. Erfaringsmessig har de største sikkerhetsutfordringene for sanntidstjenestene vært knyttet til: Aggressiv skanning av endesystemer. Målrettede angrep mot institusjoner eller enkeltpersoner ved institusjonen. Hacking for å skaffe tilgang som brukes til kostbar telefoni/video. Dette kan medfører store utgifter. Avlytting for å skaffe tilgang til samtaler og møter, i noen tilfeller også kidnapping av endepunkter både i og utenfor egen institusjon. 15

17 6.3 Brukerbehov Brukerne har behov for å jobbe sammen over nett. Bruksscenarioene (møter, undervisning og fellesdiskusjoner) har litt ulike krav, men i praksis er det stort nok overlapp til at mange behov kan fylles med samme løsning. UNINETTs arbeidet med webmøter (Meijer & Melve, Web conference discussion memo, 2010) i ecampus-programmet, identifisert tre bruksområder for samarbeidstjenester: Møter med behov for å snakke sammen, se video av den som snakker, møteinnkalling, referat, chat, dele filer og dele skjerm. Undervisning med behov for å se video av den som snakker, se video av hverandre, chat, deler filer, gi tilgang til læringsressurser, dele i smågrupper og dele skjerm. Fellesdiskusjoner med behov for å snakke sammen, se video av hverandre, chat, dele filer, dele arbeidsflate og dele skjerm. Fellestrekkene for alle scenarioene er at det er behov for minimum å snakke sammen (tale og chat, se video av den som snakker, dele filer og dele skjerm). For møter er det bruk for støtte til møteinnkalling og referat, og det er ikke alltid nødvendig å se video av alle deltakerne. For undervisning er det til stor hjelp å se alle som deltar, og det er behov for å gi tilgang til ulike læringsressurser, og det er nyttig å kunne dele undervisningsgruppen i smågrupper som jobber sammen. For samarbeid over nett, kan det noen ganger være nok å bare dele arbeidsflate/skjerm, men oftest er det nyttig med chat/tale i tillegg. Fellesdiskusjoner er det scenarioet som har størst variasjon i krav, fordi det er avhengig av både faget, samarbeidsformen og vanene til de som jobber sammen. Møter Undervisning Fellesdiskusjoner Primært bruksområde Organisatoriske møter Nettbasert undervisning Kollokviegrupper, prosjektsamtaler, gruppearbeid osv. Brukergrupper Ansatte Undervisere og studenter Studenter, forskere og ansatte Antall deltakere per møte Typisk 5 10 Maksimalt 20 Typisk Maksimalt 400 (?) Typisk 2 7 Maksimalt 20 Varighet av samarbeid Permanent eller pro- Semester Dag eller prosjekt- Skalering sjekt Følger organisasjonsstruktur (ansatte, avdelinger, møter) Antall kurs, deltakere per kurs Antall klasser per kurs lengde Alle studenter Alle ansatte Alle samarbeidspartnere Planleggingshorisont Dager og måneder Uker, semester Timer, dager for møteavtaler Finne deltakere Kalender, organisatorisk katalog, e-post Læringsplattform Nøkkelintegrasjoner Organisatorisk AD Læringsplattform Opptaksmulighet Kanskje Viktig Nyttig Tilknyttede ressurser Innkalling, kalender, Læringsplattform, sakspapir, referat læringsressurser Kompislister, e-post, sosiale medier Fagstoff, møtenotat, referater 16

18 6.4 Infrastrukturkrav Arkitekturprinsippene om åpne standarder, krav til åpne grensesnitt og standardisering innebærer at SIP brukes i kjernen av sanntidsinfrastrukturen. SIP brukes som protokoll for å sette opp sanntidskommunikasjon. Andre protokoller oversettes til SIP, slik at kjernefunksjonalitet i størst mulig grad kan gjenbrukes. Arkitekturprinsippene om modularisering, fellestjenester, tilgjengelighet og åpne grensesnitt innebærer at det ikke bør være begrensinger på hvilke medier klientene kan bruke. SIP brukes for alle typer medier, og gjør det mulig å frakte vilkårlige mediestrømmer. Arkitekturprinsippene om åpenhet og interoperabilitet innebærer at offentlige adresser og nummer bør brukes. ENUM brukes for nummeroppslag og nummerruting. Etablerte mekanismer som URIer, SRV for navneoppslag, NAPTR, bør gjenbrukes for sanntidstjenester. Oppsummert så betyr arkitekturprinsippene at infrastrukturkomponenter realiseres ved bruk av felleskomponenter som er nåbare fra mange tjenester, og som kan gjenbrukes applikasjonstjenester som kan deles mellom mange institusjoner, realisert enten i UH-sky eller offentlig sky tilgangskontroll som i størst mulig grad gjenbrukes fra Feide, UH-AD og andre etablerte mekanismer SIP som protokoll for å sette opp sanntidskommunikasjon ENUM som mekanisme for nummeroppslag for samtaleruting gjenbruk av sikkerhetsmekanismer fra andre tjenester: sertifikater, brannmur, rutingkontroll og nettovervåkning sanntidstjenester som har bruk for brannmurtraversering må gjøre vurdering av mekanismer (statiske tunneler mellom gatewayer, STUN/TURN) sammen med sikkerhetsvurdering 17

19 7 EN SIP-BASERT INFRASTRUKTUR FOR SANNTID Dette kapittelet beskriver hvordan en SIP-basert infrastruktur for sanntidstjenester er implementert i UNINETT i dag, basert på arkitektur og avveininger som beskrevet tidligere i dokumentet. I UNINETTs tjeneste Sanntid er kompleksiteten fra villniset av sanntidsløsninger brutt ned og avgrenset til noen nøkkelprotokoller og funksjoner som benytter åpne standarder. Med dette dannes grunnlaget for en teknologisk inkluderende infrastruktur gjennom anvendelse av beste praksis. Infrastrukturen gjør ingen distinksjon på typen sanntidskommunikasjon (mediet), men legger til rette for nåbarhet gjennom enhetlig adressering. Der sanntidsteknologien som tilknyttes ikke følger de grunnleggende prinsippene, suppleres det med ulike former for oversettere i tilknytningen. Noen av de grunnleggende prinsippene er at normal Internett-ruting av datatrafikk skal kunne benyttes og at mediet skal kunne gå så direkte som mulig mellom partene. Med dette oppnås en global nåbarhet, og tilknytning av tjenester som kan leveres av hvem som helst lettes. Med en slik nåbarhet følger også naturlig at sikkerhetsaspektet får særlig oppmerksomhet. På samme måte som det kan sies at Internett er summen av alle tilknyttede enheter, er Sanntid summen av alle tilknyttede kommunikasjonssystemer og tjenester. 7.1 Tekniske roller i SIP I en SIP-infrastruktur har man gjerne definert ulike roller. Teknisk kan disse ofte leveres av samme prosess eller enhet. Produsenter av løsninger kan godt finne på å gi disse andre navn, men oppgavene de løser er som oftest essensielt de samme. I SIP kan man kontakte den andre parten direkte med IP/FQDN, eller man kan oppgi en SIPadresse som kalles en SIP Uniform Resource Identifier (SIP URI). Denne er i form svært lik en e-postadresse på formen sip:navn@domene. F.eks. sip:ola@uninett.no eller sip:ola.nordmann@uninett.no. Det kan også være et telefonnummer som f.eks. sip: @uninett.no. Formen kan utvides videre til å inkludere spesifikk IP/FQDN og angi både port og protokoll. Mediegateway (MGW) Dette er en oversetter. Den kan også kalles en Back-to-Back User Agent (B2BUA). Det kan være å oversette mellom ulik teknologi, f.eks. mellom ISDN og SIP, mellom ulike medieformat eller mediekompresjon (codec), eller den kan stå som oversetter mellom to nettverk, f.eks. mellom et privat nettverk med private adresser (innside) og et offentlig nettverk (utside). Dens rolle som oversetter gjør at mediestrømmene flyter gjennom enheten. Medieproxy Dette er en bro for medietrafikken. Den kan ikke gjøre noen oversettelse av medieformatet, men den tar imot og sender videre. Dette kan være for å skjule endepunktene fra hverandre, oversette mellom private nettverk og offentlige nettverk, eller mellom f.eks. IPv4 og IPv6. En medieproxy kan også tenkes brukt for å øke redundans i en tjeneste. Den kan ikke fungere alene, men må fungere sammen med en Session Border Controller eller en proxy. Session Border Controller (SBC) Dette er en portvokter ved grensen. Dens oppgave er å sørge for at bare ønsket trafikk og trafikkmønster slipper igjennom. Den er ikke påkrevd, men anbefalt. De praktiske implementasjoner er mange og med varierte metoder, alt fra enkel verifisering av SIP-adresser til dyp analyse og sperring på IP-nivå. Det er normalt kun signaleringen (SIP) som flyter gjennom en SBC mens mediestrømmene går utenom. Flere implementasjoner setter denne i kombinasjon med en MGW eller medieproxy for å kontrollere også mediestrømmene, men det er ikke et krav til funksjonen. 18

20 Proxy Dette er en ruter. Dens jobb er å ta imot en henvendelse og sende den videre dit den skal. Valg av rute kan gjøres gjennom en mengde forskjellige teknikker, som f.eks. basert på IP, DNS, telefonnummer, m.m. Ulike proxy vil kunne gjøre dette på ulike måter. Det er normalt kun signaleringen (SIP) som flyter gjennom en proxy mens mediestrømmene går utenom. Den kan også fungere i samarbeid med en medieproxy for å også kunne rute mediestrømmen. User Agent (UA) Også kalt «endepunkt» i mange sammenhenger. Dette er punktet hvor samtalen er terminert og består av to ender: den som kaller opp og den som besvarer. Ofte blir dette forstått som et fysisk telefonapparat eller videosystem, men det kan også være klientprogramvare på brukerens datamaskin eller smarttelefon. En flerpartssamtale er flere av disse UA-til-UA-forbindelsene, men hvor den ene enden har flere slike forbindelser samtidig og sørger for at alle forbindelsene utveksler nødvendig lyd og eventuell videoinformasjon. En MGW er i realiteten en UA som besvarer på den ene siden og en UA som spør videre på den andre siden. Tjenester for videokonferanser og telefonkonferanser kan vi se på som en UA som er i stand til å håndtere mange samtaler og koble disse på ulike måter. Registrar For at UA skal kunne være nåbar med en SIP URI eller telefonnummer, må den registrere seg mot en registrar. En UA kan fungere uten, men må da nås via IP/FQDN direkte. En UA er som regel også avhengig av en registrar og bakenforliggende systemer for å kunne nå andre ved hjelp av SIP URI eller telefonnummer. Ellers må den benytte IP/FQDN for utgående samtaler. En registrar benyttes som oftest som en måte å sikre seg at kun godkjente UA får benytte kommunikasjonsressursene. Derfor er det som regel behov for brukernavn og passord når en UA skal knytte seg mot en registrar. En registrar gjør det også mulig å beskytte UA bak sikrede nettverk eller for UA å forflytte seg mellom ulike IP-adresser og nettverk, men beholde nåbarhet og ressurstilgang. Rollen registrar omfatter bare registreringen og oversikten over UA. For å få funksjon med ruting av samtaler, må den settes i sammenheng med en proxy. Derfor er disse rollene ofte slått sammen. Annen teknologi UA MGW Registrar Proxy Medieproxy SBC Ekstern UA/SBC Proxy SIP signallering MGW Mediestrøm Annen protokoll Annen teknologi Figur 4: De ulike roller satt i relasjon til hverandre. Flere kombinasjoner er mulige. 19

21 7.2 DNS for SIP i Sanntid Sanntid består av mange tjenester som kommuniserer sammen på en definert måte. I denne sammenheng er f.eks. et telefonsystem en tjeneste, en videobro en tjeneste og en konferansebro en tjeneste. Det er mange telefonisystemer og andre like typer tjenester som kan tjene hver sin organisasjon. Andre eksterne tjenester eller endepunkt kan kommunisere med de ulike tjenestene i Sanntid, avhengig av ønsket egenskap og rettigheter. Grunnlaget for ruting og nåbarhet i Sanntid er bruk av offentlig tilgjengelig DNS. Oppslag i DNS på NAPTR angir ønsket protokoll (UDP, TCP eller TLS) og oppslag i DNS på SRV angir ønskede servere for å håndtere henvendelsen. Alle deltakende organisasjoner har sitt grunndomene registrert i DNS med NAPTR og SRV, pekende mot en proxy som kan rute de ulike typene samtaler videre etter kapasitet og eventuelt type. I tillegg er det NAPTR, SRV og til sist FQDN med egne domener eller sub-domener for ulike andre tjenester. SRV gir også mulighet for lastdeling og redundans gjennom å oppgi flere poster med ulike FQDN hvor disse kan gis ulik prioritering og vekting innad i en prioritering. For å øke redundansen og avlaste sentrale DNS-servere, kan det være lurt å benytte seg av lokale eller interne DNS-servere som cachende DNS. Mye brukte oppslag vil dermed være tilgjengelig raskere og i tilfelle sentrale DNS-servere skulle bli midlertidig utilgjengelig. Alle proxy i Sanntid har innebygget DNS-caching. I tillegg kjøres det lokale DNS-servere på serveren som DNS cache, for å støtte også serverens øvrige behov for oppslag. server1.uninett.no UA server2.uninett.no NAPTR uninett.no? Pri 1: TLS Pri 2: TCP Pri 3: UDP SRV for TLS uninett.no? Pri 1: server1.uninett.no port 5061 Pri 2: server2.uninett.no port 5061 Figur 5: Forenklet fremstilling av rekkefølgen av DNS oppslag i NAPTR og SRV for domenebasert ruting. UA eller en ekstern proxy sjekker først protokollpreferanse, så serverpreferanse for den foretrukne protokoll. 20

22 7.3 SIP hos organisasjonen For eksterne som tar kontakt med en organisasjon sine tjenester, vil den første rollen som møter dem være en SBC. Bak denne vil det ligge en proxy som håndterer rutingen. Ruting kan skje mot en eller flere ulike lokale tjenester, eller henvise videre mot eksterne tjenester. Lokale tjenester kan være f.eks. en eller flere telefonisystemer, videosystemer, svartjenester og/eller andre endepunkt direkte eller indirekte. Avhengig av typer telefoni- og videosystemer organisasjonen har, vil det kunne være ulike typer MGW for å gjøre den nødvendige oversettelsen. Proxy vil sørge for at intern trafikk kan flyte mellom de ulike systemene, og ellers at utgående trafikk blir sendt på riktig måte. Telefon PRI MGW Telefon SIP Video UA MGW Registrar Proxy SBC Tjeneste X Figur 6: Proxy vil gjøre det mulig å rute intern trafikk mellom ulike tjenester, endepunkt og funksjoner. Det er også mulig for proxy å inkludere enkelte eksterne tjenester som «intern trafikk» for å utvide nåbarhet via eget domene. F.eks. en ekstern videobro-tjeneste eller en ekstern faks-tjeneste. Dette gjør det mulig å oppnå intern kommunikasjon mellom ulike egne tjenester som ellers ville vært adskilt, og den modulære strukturen gjør det fleksibelt med ulike tilpasninger for den enkelte organisasjon. Med en overordnet ruting-logikk i proxy i samarbeid med MGW, vil det f.eks. være mulig å oppnå en intern flyt av telefonisamtaler mellom to ulike telefonsystemer. F.eks. vil det være mulig å enkelt flytte på egne brukere mellom systemene uten å måtte ta hensyn til nummerserier eller telefonitilbyder. Dette kan utnyttes i forbindelse med sømløs migrasjon av brukere fra ett telefonisystem til ett annet. Man kan også splitte innkommende samtaler slik at brukere kan være på begge telefonisystemer samtidig og besvare eller ringe ut fra det systemet brukeren selv måtte ønske. 7.4 SIP for en tjeneste En tjeneste som tilbys i Sanntid, som f.eks. telefonkonferanse eller en møteplass for video, vil typisk også være beskyttet av en SBC. Slike tjenester kan operere med egne domener eller subdomener avhengig av hvordan tjenesten benyttes og hva som ønskes. F.eks. vil en tjeneste som ikke er knyttet mot en annen tjeneste, ha et eget domene, mens en tjeneste som ønskes tilgjengelig via organisasjonens eget domene, kan operere med et vilkårlig sub-domene som bare er brukt for teknisk ruting. Da vil organisasjonens proxy sørge for den nødvendige rutingen. Tjenesten er ikke nødvendigvis basert på SIP, men kan være basert på en annen teknologi, f.eks. en analog FAX-tjeneste eller et H.323-system. Den nødvendige konvertering er i så fall gjort for å være tilpasset SIP. 21

23 MGW Proxy SBC SBC Tjeneste Figur 7: Proxy hos organisasjon har fått opprettet en dedikert rute til tjenesten. Logisk henger denne bak proxy (stiplet grønn linje), teknisk går den via infrastrukturen. Henvendelser til organisasjonens domene men som skal til tjenesten eller omvendt, går logisk via proxy (blå strek). 7.5 Sanntid som SIP-infrastruktur Når man setter sammen de ulike organisasjonene med deres tjenester, og øvrige tjenester, får man frem bildet av infrastrukturen. Tjeneste Tjeneste Organisasjon B Tjeneste A Organisasjon C Tjeneste B Organisasjon A Endepunkt Tjeneste Tjeneste Figur 8: Alle i den grønne skyen kan kommunisere direkte mellom hverandre via Internett. Siden denne kommunikasjonen følger RFC-standard, vil det i realiteten kunne være en verdensomspennende sky og ikke avgrenset til egen løsning. 22

24 Dette gir en distribuert og robust arkitektur hvor kommunikasjonen mellom de ulike partene kan rutes direkte, uten sentral avhengighet. Dersom hver tjeneste i seg selv også bygges redundant i både funksjon og lokasjon, vil det ytterligere styrke denne robustheten. 7.6 Særlige hensyn ved bruk av SIP-protokoll Dialekter av SIP-standarden SIP er ikke en enkeltstående standard, men har mange tilleggsstandarder for å kunne tilpasses ulike behov. Som en tekstbasert protokoll er den veldig fleksibel. Dette har gjort at flere produkter har valgt å gjøre mindre eller større endringer også utenfor standardene for å tilpasse den til egne behov. Det kan også være produkter og tjenester som rett og slett ikke har implementert standardene riktig. Det gjør at det i praksis kan oppstå flere dialekter som man kanskje må ta hensyn til. Noen ganger er det så enkelt som å måtte gjøre noen små justeringer med håndteringen av SIP i egen Proxy/SBC, andre ganger er forskjellen så stor at en fullstendig omskrivning må til ved hjelp av en MGW/B2BUA. I Sanntid benyttes det SIP som følger standardene i all kommunikasjon mellom de ulike tjenester. Internt kan det likevel være tilfeller av nødvendig omskrivning og tilpasning mot produkter og tjenester som avviker UDP som transport I standarden for SIP står det spesifisert at en SIP-pakke med innhold over 1300 bytes ikke skal benytte UDP som transportprotokoll. Dette fordi en UDP-pakke over totalt 1500 bytes vil bli fragmentert dersom dette overstiger størrelsen av MTU, som ofte er på 1500 bytes. Men MTU kan også være litt lavere dersom en forbindelse f.eks. er tunnelert over et nettverk som har MTU på 1500 bytes. Et UDP-fragment inneholder ikke en angivelse av port, og vil derfor av mange «Access List» (ACL) og brannmurer bli stoppet, mens det første fragmentet, som inneholder portangivelsen, kommer igjennom. Om en SIP-enhet mottar en SIP-pakke som ikke er komplett, skal den forkastes. Dermed vil mottakeren i realiteten aldri motta SIP-pakken. For hvert hopp en SIP-pakke tar, vil det bli lagt til felt som bygger på den totale pakkestørrelsen. Da kan det skje at man kommer over grensen for fragmentering selv om man ikke var det i utgangspunktet. Det kan også skje dersom det legges til definisjon av ekstra codec eller kryptering. Dette er grunnen til at man ofte ser videosystemer med SIP som ikke støtter SIP over UDP i det hele tatt. Man bør derfor vurdere å alltid bruke SIP over TCP, implisitt om man bruker TLS, der det er mulig. Av hensyn til kompatibilitet med eksterne parter, bør likevel SIP over UDP tilbys som en best effort. Dette vil i praksis som oftest fungere for samtaler som bare er lyd Nettverkstraversering for RTP Tilsvarende som SIP, og dens problemer med å komme gjennom brannmurer og ACL, kan RTP også ha problemer med å nå frem til målet. Dette er et velkjent problem som kan skyldes stengte porter på lokal enhet, NAT, brannmurer og ACL m.fl. Det er kommet flere standarder for å løse dette problemet, deriblant RFC 5245 «Interactive Connectivity Establishment», omtalt med forkortelsen ICE. ICE er en protokoll for å prøve å liste opp alle mulige adresser og porter der et 23

25 gitt endepunkt er tilgjengelig for å motta RTP. Dette gjøres tilsvarende av begge endepunkter i en samtale, og disse listene av adresser og porter kombineres og utveksles mellom endepunktene. Adressene og portene vektes ut fra best til verst, og det forsøkes å sende trafikk mellom endepunktene ifølge listen til du ender opp på de beste mulige adressene og på portene som fungerer. ICE kan kombineres med både RFC 5389 «Session Traversal Utilities for NAT» (STUN) og RFC 5766 «Traversal Using Relays around NAT» (TURN) protokollene slik at endepunktene har størst mulighet for å lykkes i å utveksle mediestrømmer. For å være WebRTC-kompatibelt må et gitt endepunkt bruke ICE. STUN og TURN er protokoller der endepunkter i samarbeid med sentral infrastruktur forsøker å gjøre seg tilgjengelig for RTP utover sine lokale porter direkte på sin lokale IP. Gjennom disse protokollene allokerer endepunktet en eller flere porter på den sentrale infrastrukturen der det kan være tilgjengelig for RTP. Dette vil eksempelvis kunne omgå problemer der porter på endepunktets lokale IP er blokkert av ACL Sikkerhet med SIP SIP er en åpen og tekstbasert protokoll. Dette gir en forholdsvis lav terskel for noen som skulle ønske å utfordre de tekniske grensene på en SIP-kapabel enhet. Når man har en infrastruktur tilgjengelig på Internett, må man derfor være svært bevisst på hvordan man tilgjengeliggjør og bruker ens SIP-baserte løsninger. Som med alle tjenester er det alltid en viss risiko ved å være tilgjengelig, men med riktige forholdsregler og tiltak vil man kunne beskytte seg mot det aller meste, kanskje unntatt den mest kompetente angriper. Som med alle tjenester må man gjennom en risiko- og sårbarhetsanalyse vurdere den reelle faren opp mot verdien på det man ønsker å sikre. At noe er potensielt farlig betyr ikke nødvendigvis at det er en reell fare. Trusler man må være bevisst på: Skanning o Det er meget vanlig at uvedkommende gjør testing av allment tilgjengelige SIPkapable og H323-kapable enheter i stor skala. Spesielt er det SIP-metodene OPTIONS (litt tilsvarende en ping ), INVITE (oppsett av samtale) og REGISTER (registrere som bruker) som benyttes. Først er det gjerne OPTIONS for å finne SIP-enheter, så er det tusenvis av INVITE og kanskje REGISTER for å se om det er mulig å finne svakheter i konfigurasjonen eller brukerkontoer med standard passord/dårlige passord. Dette er gjerne tilknyttet at telefoni misbrukes til å foreta dyre internasjonale anrop over PSTN. Det kan i løpet av timer eller få dager bli kostnader som utgjør ubehagelige store beløp. Slike skanninger er sjeldent spesielt smart utført og de skiller ikke mellom telefonisystemer og f.eks. videosystemer. INVITE som når frem til et endepunkt kan merkes i form av en mengde plagsomme oppringninger fra gjerne uvanlige nummer, og uten at det er noen i andre enden om man svarer. Enkelte systemer eller enheter som ikke er så godt bygget, tåler ikke denne massive mengden henvendelser, og kan låse seg eller kanskje fylle lagringsplassen på logger. Målrettet angrep o Til forskjell fra skanning så er dette et angrep rettet direkte mot ens enheter eller systemer. Dette blir utført av noen som allerede kjenner til at man har SIP tilgjengelig. Dette vil være utført gjennom ulik manipulering og skreddersøm av 24

26 SIP-pakker med ønske å kartlegge ens infrastruktur, utnytte kjente svakheter ved et produkt, sabotasje, misbruk av telefoni, identitetstyveri eller spionasje. Slike aktiviteter vil som regel kreve høyere kompetanse hos angriperen og blir ikke nødvendigvis avslørt gjennom unormal adferd ved endepunkt på samme måte som ved skanning. Hacking av servere/enheter o Som for andre systemer og enheter, utgjør dette en fare ved at hackeren får en tilgang som ikke er tilsiktet. Gjennom en slik tilgang kan funksjon til SIP endres. Man-in-the-Middle o Som et resultat av et målrettet angrep, DNS-manipulering, hacking av enheter på systemnivå, misbruk av produkttilgang o.l., kan noen tenkes å operere et sted på veien mellom to UA. Det kan være både i og utenfor egen organisasjon. Ved å manipulere SIP-informasjonen på veien, kan man omdirigere ønskede samtaler eller samle informasjon. Avlytting o SIP og mediestrømmen går sjeldent samme vei hele veien. Men om en hacker får tilgang til enten nettverket der mediestrømmen går, eller en server der mediestrømmen går gjennom, kan samtaler avlyttes ved å gjøre en enkel pakkedump. Det kan også være at programvaren som håndterer mediestrømmene på serveren er i stand til å lagre lydfiler direkte. Tiltak for å redusere farene: Alltid benytt en SBC som vern mellom omverden og egne SIP-baserte tjenester og enheter. En smart SBC som kan analysere adferdsmønster og kanskje også kjenner mye brukte metoder og skannere, vil kunne stanse skanninger og de fleste målrettede angrep allerede før de kan få svar. En SBC kan også brukes til å analysere utgående samtaler for å avsløre om det er et misbruk fra en kompromittert enhet på innsiden. En SBC kan være et kommersielt produkt eller med tilstrekkelig kompetanse kan den konfigureres selv ved hjelp av programvare som er gratis og har åpen kildekode. Det finnes noen svært gode programmer tilgjengelig. Vurder å redusere egen synlighet på SIP. SIP over UDP og TCP bruker som oftest port Det må ikke være disse portene, og det er heller ikke nødvendig om man har domenebasert ruting. Skannere vil som regel prøve bare mot denne porten. Dersom man legger sine eksterne porter på en annen port, vil man bli litt vanskeligere å finne og dermed heller ikke bli så utsatt for videre skanning. Benytt nettverksfiltrering aktivt (ACL, iptables, o.l.), og begrens tilgang til det teknisk nødvendige. Vern alle SIP-kapable og H.323-kapable enheter mot direkte ekstern SIP/H.323-tilgang. Vurder også egne, dedikerte server-nett og klient-nett om man er en organisasjon av en slik størrelse. All SIP-kommunikasjon bør gå via proxy og en SBC. Bruker man en registrar, vern tilgangen om mulig. Benytt gode passord for alle brukere. Sørg for at alle servere og endepunkt med systemtilgang/webtilgang er sikret med gode passord, og helst også mot ekstern tilgang. Vurder om det er nødvendig med SIP topology hiding for å skjule bakenforliggende infrastruktur. Vurder om man skal benytte TLS for SIP-trafikken. Dette krever også bruk av sertifikater. Sertifikater kan enten være private eller offentlige. Sertifikatbruken for sikker identifikasjon av den andre part eller for kanalsikring. Vær obs på at en TLS-kryptert SIP- 25

27 forbindelse bare varer til neste hopp. Dersom det neste hoppet sender SIP videre ukryptert, vil det være mulig å se innholdet. Vurder om man skal benytte kryptering for mediestrømmen (SRTP/zRTP). Mediestrømmen søker å gå direkte mellom UA, men om mediestrømmen går via en MGW/medieproxy som sender videre ukryptert, vil det være mulig å avlytte. Bruk av et kryptert medium er ikke alltid mulig fordi det kan være forskjellig implementasjon i ulike UA. Noen vil f.eks. ikke godta et kryptert medium som opsjon, men at det enten er påkrevd eller ikke tilbudt. Logging. Helst også samtidig til en ekstern loggserver. Logg så mye som relevant for å kunne verifisere tilstanden til tjenesten og helst også oppdage unormal adferd. Om noen skulle klare å hacke seg til administrativ tilgang og slette loggene på serveren, vil man allikevel ha sentrale logger frem til det punktet. Avvik i logger på en sentral eller en lokal server vil også være avslørende. Automatisert varsling og deteksjon av trafikkavvik. Sørg for å ha på plass monitoreringssystemer som kan varsle og eventuelt handle dersom det oppdages uønskede eller uventede avvik. F.eks. en automatisk sperre for uønskede IP-adresser (skanneangrep) eller sperring av forbindelser (unormale anropsmønster). Manuelle rutiner for monitorering og vedlikehold av systemene. En rutinert administrator vil kunne oppdage mistenkelige avvik som ikke fanges opp av automatiserte systemer. Systemer må kontinuerlig vedlikeholdes og holdes oppdatert dersom sikkerhet skal kunne ivaretas, da sikring mot stadig nye angrepsmetoder er en kontinuerlig prosess. ACL SBC Kun offentlig tilgjengelige SIP porter Proxy Registrar UA Kun RTP-porter MGW Kun RTP-porter Medieproxy Kun RTP-porter Figur 9: Logisk sammenheng mellom de ulike roller og tilgang gjennom brannmur/acl. Det er kun SBC som bør ha ekstern tilgang via SIP. Alle andre roller bør gå via denne. Det er flere interne roller som har behov for RTP. Dette kan enten åpnes direkte eller gå via en medieproxy som del av SBC-løsningen. 26

28 7.7 Telefonifunksjoner i infrastrukturen Gjennom en SIP-infrastruktur er det mulig å tilby telefonitjenester via en telefonioperatør som leverer «Public Switched Telephone Network» (PSTN). Mange operatører leverer i dag tilknytning via SIP (også ofte kalt trunk ) på en eller annen form. Ved å knytte disse mot infrastrukturen som en tjeneste, er det mulig å tilby organisasjoner vanlig telefoni gjennom en felles operatørforbindelse og samlet avtale, fremfor at alle organisasjoner skal ha hver sine forbindelser og egne avtaler. Tjeneste Tjeneste Organisasjon B Tjeneste A Organisasjon C Tjeneste B Organisasjon A Endepunkt Tjeneste PSTN Tjeneste Operatør Figur 9: Her er PSTN lagt inn som en tjeneste i infrastrukturen. På denne måten tilgjengelig for alle organisasjoner som ønsker tjenesten. Det er enkelt å gjøre tilgjengelig flere samtidige PSTN-tjenester med ulike operatører på denne måten. Å organisere tilknytning til tradisjonell telefoni gir flere fordeler: En operatør selger som oftest tilknytning i form av en pris for et gitt antall linjer. En samlet tilknytning utnytter samtalers samtidighet slik at den beregnede overkapasiteten på linjer som den enkelte organisasjon måtte ha selv, kan deles på alle deltakende organisasjoner. Dette kan gi en signifikant besparelse i forhold til behovet for totalt antall linjer. Man kan unngå flere løpende abonnement for i stedet å samle alle i en stor pott. Det er mulig å ha flere operatører samtidig. Det kan være at en operatør gir gode priser for samtaler til mobiltelefoner, mens en annen gir gode priser for samtaler til fasttelefoner. Man kan også ha tilknytninger til operatører i utlandet for å oppnå gunstige priser på utenlandssamtaler til land man ringer mye til. Samtaler kan enkelt fordeles til ønsket operatør for hver enkelt samtale, basert på kriterier som f.eks. tid på døgnet, destinasjonsprefix, organisasjon som ringer osv. 27

29 Enkel portering til annen operatør. Det er ikke behov for lokal teknisk omlegging hos den enkelte organisasjon med eventuelle konsulentkostnader det måtte innebære. Omlegging skjer sentralt, og kan gjøres enten øyeblikkelig eller gradvis over en lengre periode. Sterk teknisk kontroll med leverandør. Det er lettere å avdekke feil, korrigere leverandør og drive frem nye tekniske løsninger når man står samlet enn om hver enkelt organisasjon står isolert. Samtalestatistikk for økonomisk og strategisk planlegging. Med oversikt over trafikk er det enklere å planlegge besparende tiltak gjennom optimale avtaler og tekniske løsninger. Økt trygghet mot misbruk. Et selvlærende system kan settes inn sentralt for å overvåke og varsle om noe avviker fra normalen (anomalideteksjon). Effektive mottiltak kan iverksettes straks uten avhengighet til leverandørens responstid. Robustifisering og redundans. Ved å utnytte robustifiseringen og redundansen man har fått gjennom å bygge en solid SIP-infrastruktur, kan man få en langt høyere grad av redundans enn det man normalt oppnår med normale telefonitilknytninger. Om all SIPforbindelse skulle være utilgjengelig, kan man vurdere om det er nødvendig med f.eks. enkle ISDN eller mobile forbindelser lokalt hos den enkelte organisasjon. Enkel tilgjengeliggjøring av telefonifunksjoner også for videosystemer, egne SIPløsninger, fellestjenester, m.m Teknisk tilknytning mot operatør Selv om en operatør tilbyr en SIP-forbindelse over en trunk, betyr ikke det nødvendigvis at operatøren gjør dette på en god måte. En slik felles trunk må også kunne skille mellom de ulike organisasjonene som ringer for å kunne fakturere samtalekostnader riktig. Åpne standarder på feltet inkluderer både relevante ITU-T Recommendations og IETF RFC. En oppsummering av krav til kommunikasjonen mellom de forskjellige enhetene er gitt av SIPforum i SIP-PBX/Service Provider Interoperability (Hutton & Salgueiro, 2017). Dette danner et godt utgangspunkt for en kravspesifikasjon som må tilfredsstilles av operatør, og det er krav de bør bli møtt med. Men det gir ikke en garanti for at operatøren faktisk er teknisk i stand til å levere på denne måten. I praksis kan operatør være prisgitt sitt tekniske utstyr og egen kompetanse for å møte kravene. Man kan derfor måtte velge en dyrere leverandør, eller kanskje stå uten noen kvalifiserte leverandører. Alternativet er et kompromiss der man gjør de nødvendige tilpasninger på egen side. Muligheten for dette må vurderes opp mot kostnader og egen kompetanse. For den tekniske leveransen er mulighetene mange. Eksempelvis: Felles samling av tradisjonelle PRI-forbindelser med MGW til SIP SIP over dedikerte forbindelser fra operatør SIP over VPN via Internett SIP over Internett som dedikerte B2BUA-forbindelser Normal, rutet SIP via dedikerte proxy Uansett løsning vil en god teknisk dialog med operatøren, både i forkant og under kundeforholdet, være av stor betydning for leveransens tekniske kvalitet og tilgjengelighet. 28

30 7.7.2 Nummerplan: e164 e164 er The international public telecommunication numbering plan fra ITU-T og beskriver en verdensdekkende nummerplan for PSTN. Den består av maks 15 siffer, inklusive landskoden, og er ofte gjenkjent ved tegnet + før tallene, for eksempel: Siden et nummer på e164-format er internasjonalt unikt, er det også dette formatet som operatører vil kreve av nummer som blir utvekslet over en SIP-trunk. Dette bør også være formatet som benyttes når telefonisamtaler formidles over infrastrukturen. I Sanntid er dette et krav for å få tilgang til PSTN-tjenesten. Brukere er sjeldent vant til å måtte legge på + og landskode for alle utgående samtaler. Man utelater som regel dette helt, eller bruker 00 som prefix etterfulgt av landskoden ved utenlandssamtaler. En formatkonvertering fra dette til e164 bør gjøres så nært brukeren som mulig for å sikre unik identifisering, lette samtalerutingen og sikre at nummerformatet stemmer for transport til PSTN. Tilsvarende bør eventuelle behov for å formatkonvertere fra e164 til andre lokale format, gjøres så nært brukeren som mulig. Så nært brukeren som mulig vil i praksis ofte være i organisasjonens telefonisystem UA Proxy PSTN UA Proxy PSTN Figur 10: Forenklet eksempel på nummerformatkonvertering. Klienten (UA) ser og bruker alltid nummer på lokalt format, eventuelt benytter ekstra prefix. Proxy konverterer til enhetlig e164-format Nummeroppslag: ENUM e164 NUmber Mapping (ENUM - RFC 6116) er en metode hvor man i DNS kan legge inn NAPTR-poster for nummer på e164-format. Forenklet forklart kan man ved å gjøre et DNSoppslag få svar på om nummeret er tilgjengelig via SIP, og hvor man skal sende invitasjonen for å nå det. Det er ikke en forutsetning for ENUM at man har PSTN via SIP, men nummeret bør fungere om man ringer med SIP over Internett. Svaret får man i form av en URI og kan være en hvilken som helst URI man ønsker å legge inn. Eksempel: $ORIGIN nrenum.net. IN NAPTR "u" "E2U+sip" "!^.*$!sip: @uninett.no!". En sonefil for ENUM kan inneholde 1 nummer, 10 nummer, 100 nummer, 1000 nummer osv. I eksempelet over vil man få URIen sip: @uninett.no til svar. Det kunne også vært f.eks. sip:sentralbord@uninett.no. I Sanntid har vi valgt å holde dette til samme nummer som det som slås opp. Dette gjøres av flere grunner: Ikke avsløre mer informasjon enn nødvendig. Oppslag kan ellers utnyttes til å avsløre noe om bruken av nummeret. 29

31 Holde informasjonen i sonefilene så statisk som mulig. Fra et administrativt perspektiv er det mye enklere å forholde seg til et enkelt nummer-til-nummer-format, enn å måtte ta hensyn til mulig endring av brukernavn eller å vedlikeholde alternativ ruting. I den grad det er nødvendig med oversettelse av nummer til f.eks. brukernavn, overlates det til det mottakende SIP-systemet. For ENUM har man enten egne trær eller man kan ta del i et eksisterende tre. Et tre kan være i en privat DNS, eller en offentlig. Et globalt offentlig tre, også omtalt som The Golden Tree, er e164.arpa. Dette er underlagt kontrollen til det enkelte lands kommunikasjonsmyndighet/domenemyndighet. Det er strenge krav til registrering og verifisering av eierskap før nummer kan legges inn. Det gjør at kvaliteten på informasjonen i e164.arpa i teorien blir svært høy. For å opprettholde kvaliteten på informasjonen, må det være en kontinuerlig oppfølging av det enkelte nummer for å verifisere at det fortsatt eksisterer og har det samme eierskapet. Dessverre gjør slike praktiske, men nødvendige hensyn at treet blir dyrt å drive og derfor ikke tilgjengelig i alle land. Interessen har vært såpass liten at de er få land som tilbyr dette treet. I Norge var det tilgjengelig i noen år som pilot, men ble lagt ned da interessen for 4.7.e164.arpa var for liten utenfor Sanntid til å forsvare en produksjon. Som NREN gikk derfor Sanntid over til å benytte nrenum.net. Dette er en akademisk tjeneste for NREN og drives ut i fra forutsetningen at den enkelte deltakende NREN tar ansvar for at numrene for egne organisasjoner er riktig. I et offentlig telenett vil det også være mange private og mindre bedrifter som øker kompleksiteten med kontroll og ettersyn. Normalt sett er det enkelt for en NREN å vedlikeholde informasjonen, da numrene som organisasjonene har generelt er ganske statiske. Har man i tillegg en PSTN-tjeneste, har man nødvendigvis også nøyaktig oversikt over hvilke nummer som finnes. Som med e164.arpa er nrenum.net offentlig tilgjengelig, dvs. at enhver kan gjøre et oppslag. Dette gir den fordel at andre, f.eks. fra andre land, som ønsker å nå ditt nummer, kan finne en direkte oppkobling via Internett istedenfor å bruke kostbare samtaler via PSTN. I Sanntid blir alle ringte nummer fra deltakende organisasjoner (utgående samtaler) sjekket mot ENUM, både i nrenum.net og i e164.arpa. Dermed vil samtaler mellom organisasjoner og andre som ligger i ENUM, gå via Internett og ikke via PSTN. Brukerne merker i praksis ingen forskjell for dette skjer automatisk og med tilbakefall til PSTN om ikke veien over Internett allikevel fungerer. 30

32 server1.uninett.no Proxy PSTN I ENUM? sip: @uninett.no NAPTR / SRV for uninett.no Figur 11: I dette tilfellet: Proxy sjekker om nummeret er tilgjengelig i DNS gjennom et oppslag i ENUM. Om ikke FQDN er spesifisert, sjekkes så NAPTR og SRV mot oppgitt domene på vanlig måte. Feiler samtalen, sendes den til PSTN Tjenester som er realiserbare med PSTN og ENUM Har man PSTN tilgjengelig i infrastrukturen, åpner det seg muligheter for å knytte telefonnummer til flere tjenester og funksjoner. Dette kan enten være for å tilby billigere tjenester enn typiske tredjepartsprodukter, gi enklere tjenester og større fleksibilitet eller telefoni til funksjoner som ellers ikke har denne muligheten tilgjengelig. Eksempler på slike tjenester og funksjoner kan være: Fakstjeneste. Ta imot faks og send videre som vedlegg i mail, og omvendt. Det er stadig mindre behov for faks og mange organisasjoner ønsker ikke å ha utstyr til dette. Denne typen tjenester koster gjerne en del penger, men er enkel å bygge og kan tilbys egne organisasjoner billig. Telefonkonferanse. En så enkel tjeneste som å møtes på et nummer for en telefonkonferanse kan koste overraskende mye penger å bruke. Ikke alle telefoniløsninger har denne muligheten, men det er relativt enkelt å lage en slik tjeneste selv. Den kan i tillegg ha fordelen med å kunne gi deltakelse også via SIP, WebRTC, o.l. Det er mange videoendepunkt med numeriske fjernkontroller og som bruker IP-adresser for adressering. Ved å gi dem et telefonnummer og utnytte ENUM, kan man ringe med telefonnummer i stedet. Det gir mye enklere betjening for fjernkontrollen. Det gir også videoendepunktet muligheten til å fungere som en møteromstelefon/høyttalende telefon. Også videotjenester som en videobro kan gjøres tilgjengelig via telefoni ved å rute telefonsamtaler via SIP. Omrutingstjenester. For mer avansert omruting av samtaler, som f.eks. i forbindelse med tekniske feil, flytting av brukere til nye nummerserier eller spesielle svarmeldinger, kan dette sentraliseres som en tjeneste uavhengig av hva telefonitilbyder kan tilby og med stor fleksibilitet. Telefoni via WebRTC. Brukere kan logge inn med en WebRTC-kapabel nettleser og få tilgang til telefonitjenester gjennom nettleseren. Dette kan f.eks. være til nytte ved reiser og i andre sammenhenger hvor vanlig telefoni er utilgjengelig eller dyrt. Integrert opplysningstjeneste. Når man får innkommende samtaler fra PSTN, kan man knytte dette opp mot nummeropplysning og/eller egen database for å legge til navnet på innringer («Display Name»). Dette vil så kunne vises hos den mottakende klient som støtter slikt (f.eks. Skype for Business og SIP-klienter). 31

33 Nummeromskrivning. Det kan være at man ønsker at alle utgående eller innkommende samtaler blir omskrevet til andre nummer. F.eks. kan det være at man ikke ønsker at egne brukere ringer til dyre nummer, men skriver om dette automatisk til billigere alternative nummer der det finnes. Slikt kan da gjøres sentralt eller hos den enkelte organisasjon. Det kan også være at man ønsker at alle egne nummer i en serie fremstår som ett annet nummer ved utgående samtaler. 32

34 REFERANSER III 8 REFERANSER Bergh-Hoff, H., Sørensen, C.-F., Garshol, J. E., Jakobsen, B. H., Vangen, G. M., Pettersen, Ø. D., & Hansen, J. (2015). Felles IKT-arkitekturprinsipper for universitets- og høgskolesektoren. UNINETT. Difi. (2012, 09 17). Overordnede ITarkitekturprinsipper for offentlig sektor. Hentet fra Difi. (2016). Referansekatalogen for bruk av standarder i offentlig sektor. Hentet fra Hutton, A., & Salgueiro, G. (2017). SIP-PBX / Service Provider Interoperability, SIPconnect 2.0 Technical Recommendation. SIP-forum. Meijer, J., & Melve, I. (2010). Web conference discussion memo. Hentet fra ecampus webmøter: 09.pdf Meijer, J., & Skrødal, S. (2016, 04 30). WebRTC Requirements and R&E Deployment Roadmap. Hentet fra GÉANT project: RandE-Deployment-Roadmap.pdf Norges lover. (2003). Lov om elektronisk kommunikasjon (ekomloven). Hentet fra Lovdata: Samferdselsdepartementet. (2015). Lov om elektronisk kommunikasjon (ekomloven). Hentet fra Lovdata: Sekretariat for informasjonssikkerhet i UH-sektoren, UNINETT. (2016). Krav til bruk av skytjenester (UFS150). Hentet fra Skrødal, S., & Otto, S. (2016). WebRTC in UC - an Architecture Overview. GÉANT. Støfringsdal, B. (2011). Driftstøttesystem og overføring av lyd og bilde (UFS120). Hentet fra tjenester/campustjenester/@campus/ufs/pdf/ufs120.pdf Støfringsdal, B. (2013). Funksjonsbeskrivelse AV-utstyr for undervisnings- og møterom (UFS116). Hentet fra Støfringsdal, B. (2013). Teknisk og funksjonelle systemkrav for AV-utstyr (UFS119). Hentet fra UNINETT. (2016). Hentet fra Juridisk veileder for skytjenester: UNINETT. (2016). UH-sky. Hentet fra UH-sky: 33

35 UNINETT fagspesifikasjoner er tilgjengelige fra 34

36 9 DEFINISJONER OG TERMINOLOGI Sanntid Med begrepet sanntid menes synkrone tjenester, der samtaler og samarbeid skjer samtidig hos begge parter. Et eksempel er en telefonsamtale. Et annet eksempel er et webmøte med deling av skjerm. Sanntidstrafikk stiller ofte krav til liten forsinkelse og liten tidsvariasjon for dataflyt i samtalen, og har et krav om at aktørene i samtalen er samtidig til stede. Samtrafikk Samtrafikk er utveksling av trafikk mellom ulike aktører. I dette dokumentet vil samtrafikk dekke både trafikk som utveksles gjennom det offentlige telenettet og med aktører som nås via de nasjonale og internasjonale forskningsnettene. Ruting For sanntidstjenester skiller vi ofte mellom ruting av samtalekontroll og ruting av samtaleinnhold. Ruting av samtalekontroll handler om å etablere, kontrollere og avslutte samtaler. Ruting av samtaleinnhold handler om å sende alt samtaleinnhold mellom partene, og kan involvere flere kanaler som bærer ulikt innhold eller gatewayer som oversetter mellom ulike protokoller. SIP SIP er en protokoll for å sette opp, kontrollere og avslutte samtaler over Internett. Samtalene kan ha mange ulike medietyper, fra bare tekst eller bare tale til komplekse sammensatte samtaler med video, lyd, tale, tilstedeværelse, fildeling, arbeidsflatedeling, spill og en rekke andre medieformer. SIP bruker URI for adressering, og adressene er bygget opp i samme grunnformat som vi kjenner fra e-post, der en typisk SIP URI er på formen sip:brukernavn@domenenavn. Medie-GW Medie-GW (medie-gateway)/mgw er en oversetterfunksjon mellom ulike formater, slik at personer som har forskjellige klientsystemer som ikke i utgangspunktet snakker sammen, kan få til en samtidig samtale. Det finnes for eksempel en rekke videoformater, og en medie-gateway sørger for at video blir transformert til et format som passer klientene på hver side av samtalen. ENUM ENUM står for E.164 Number to URI Mapping, og er en standard som avbilder telefonnummer inn i DNS (til IP-adresser eller URIer for SIP), slik at telefonnummer kan brukes på Internett. B2BUA Back-to-back User Agent RTP Protokoll for sanntidstjenester. RTP står for Realtime Transfer Protocol. Tilgangsstyring Tilgangsstyring for sanntidssystemer har flere sider. Sett fra brukernes ståsted handler det om hvem som kan snakke sammen eller delta på møter. Brukerne kan møte krav om innlogging, enten med PIN-kode eller brukernavn/passord. Passord vil normalt gå enten mot UH-AD eller Feide, og i begge typer løsning kan brukeren skrive sitt vanlige campus-brukernavn og passord. 35

37 Sett fra institusjonene handler tilgangskontroll om å holde oversikt over brukere og hvilke rettigheter hver enkelt bruker skal ha opp mot institusjonens tjenester. Sett fra infrastruktursiden handler tilgangskontroll om hvilke institusjoner som skal ha tilgang til felleskomponenter. Sett fra tjenestekomponentene handler tilgangskontroll om å hente informasjon om adgangsrettigheter. Offentlige telenett (PSTN) Telenett tilgjengelige for offentligheten. I tegninger og faglitteratur benyttes ofte den engelske forkortelsen PSTN for Public Switched Telephone Network, selv om dette dekker mye mer enn bare telefoni. Ekom-loven (Norges lover, 2003) definerer offentlig telefoninett som elektronisk kommunikasjonstjeneste som direkte eller indirekte oppretter og mottar nasjonale eller nasjonale og internasjonale taleforbindelser ved hjelp av ett eller flere numre i en nasjonal eller internasjonal telefonnummerplan og som er tilgjengelig for allmennheten eller beregnet til bruk for allmennheten. SaaS SaaS står for Software-as-a-Service, og brukes for å beskrive sluttbrukerrettede tjenester som bor i skyen. For sanntid kan slike tjenester for eksempel være transkoding eller opptaksløsninger for å gjøre møteopptak. 36

38 VEDLEGG IV 10 VEDLEGG: SANNTIDSTJENESTER I UNINETT Vedlegg knyttet til UFS151: Sanntidskomponenter, arkitektur for samhandlingstjenester UFS Vedleggsnavn Sanntidstjenester i UNINETT Dato URL Hvor legges dette? for oppdatert versjon Kontaktpunkt sanntid@uninett.no 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

39 10.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 KAMAILO Videokonferanse 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 LaaS analyse 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 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 38

40 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 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. 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. 39

41 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 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. 40

42 Figur 12: 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 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. 41

43 Figur 13: 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 42

44 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 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 10.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 distribuere dette 43

45 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. 44

46 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. 45

47 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 14: Videobro 46