Videomöten biter sig fast i nätverket på ett sätt som få andra affärsapplikationer gör. Ljudet tål inte fördröjning, videon behöver jämnt flöde och uppkopplingen måste orka toppar när flera rum kopplas upp samtidigt. I små miljöer räcker ofta standardinställningar, men i större nätverk med många kontor, hybrida arbetsmönster och blandad infrastruktur avgör bandbreddsarkitekturen om möten uppfattas som professionella eller plågsamma. Här följer en genomgång, byggd på erfarenheter från drift av hundratals rum och tusentals samtidiga klienter, av hur du designar och fintrimmar förutsättningarna.
Vad som faktiskt äter bandbredd
En typisk videoström i 1080p med H.264 ligger runt 2 till 3 Mbit/s för video och 24 till 64 kbit/s för ljud med Opus eller AAC, plus overhead. Lägg till 15 till 20 procent för RTP, UDP, IP och Ethernet. 720p hamnar oftast på 1 till 1,5 Mbit/s. 4K spränger ramarna med 8 till 15 Mbit/s per ström beroende på codec och rörelse i bilden. Skärmdelning varierar mycket, från 500 kbit/s när bilden är statisk upp till 3 till 5 Mbit/s under animerade presentationer.
Multiplicera detta med antalet samtidiga flöden. Ett större kontor med 15 aktiva mötesrum i 1080p och 200 softklienter i öppet landskap gör plötsligt vågor på WAN-länken, även om varje individ använder måttlig bitrate. Värre blir det när externa gäster ansluter via dålig Wi-Fi, vilket ökar FEC och återsändningar, eller när ett möte växlar från SVC-lager 1 till lager 2 och 3 på grund av att många tittare kräver högre kvalitet.
För att kunna styra måste du först förstå topologin som videon tar. Vissa plattformar, som Microsoft Teams, använder mediareläer i molnet och försöker hitta närmaste edge. Cisco Webex likaså. Klassisk MCU-arkitektur samlar alla mediaflöden i en brygga, ofta i molnet eller i ett datacenter. SFU, som Zoom och många WebRTC-baserade tjänster, reläar separata flöden och skalar bättre, men multiplicerar antalet strömmar per deltagare. Detta styr hur du kalkylerar kapacitet per site och per internetbrytpunkt.
Mät först, optimera sen
Att börja med teoretiska profiler leder ofta fel. Jag har sett länkar som mäter 1 procent paketförlust dagtid enbart på grund av policers i ett mellanliggande MPLS-nät, något som inte syns i vanliga throughput-tester. Videon tolkar detta som konstant mikrohicka. Därför, bygg en baslinje med fokus på:
- RTT och jitter mellan varje site och respektive molnregion ni använder, både direkt till internet och via SD-WAN. Paketförlust i procent, separerat för peak och off-peak. DSCP-bevarande i hela kedjan, ända till leverantörens edge. Faktiskt utnyttjande under måndagsmorgnar och direkt efter helg, då många synkar och kör uppstartsmöten.
Använd NetFlow eller sFlow för att få applikationssynlighet, inte bara port 443 statistik. För vissa plattformar finns detaljerade endpoints du kan ping-tracea, till exempel Teams media reläer i definierade FQDN-mönster. SNMP kan ge Q-depth i köer på access- och distributionsswitchar när det smäller till vid hel- eller halvtimmesbytet.
Kapacitetsplanering utan gissningar
Planeringen vinner på enkelhet och konservativa marginaler. Börja på site-nivå, räkna separat för rumssystem och softklienter. Videokonferenssystem i rum, särskilt med professionell konferensutrustning, tenderar att hålla jämnare bitrate än bärbara datorer som varierar med CPU-belastning och nätvillkor.
Här är en rak metod som brukar fungera i praktiken:
- Kartlägg vilka plattformar ni använder och var media landar, till exempel Teams, Webex och Zoom. Notera andelen möten internt respektive med externa parter. Inventera antalet rum, sittplatser och förväntad samtidighet per site. För softklienter utgå från 10 till 20 procent samtidighet i större kontor, 5 till 10 procent i produktionsmiljöer. Sätt kvalitetsnivåer. 720p för de flesta rum, 1080p för ledningsrum eller demo. Tillåt dynamisk nedväxling. Beräkna bandbredd per ström med 20 procent overhead, lägg 30 procent buffert för toppar och FEC. Summera per site. Verifiera i drift och justera. Kör en planerad belastningsperiod, till exempel en fredag 14.00, med många testmöten och mät både WAN och LAN-queuer.
Med detta får du siffror som tål livet utanför labbet. Ett exempel: en site med 8 aktiva rum i 1080p, 60 samtidiga softklienter på 720p och 20 samtidiga skärmdelningar kan summera till cirka 200 till 300 Mbit/s i riktningen ut, och något lägre in, beroende på plattform och topologi.
QoS som faktiskt fungerar
QoS kan inte skapa bandbredd, men den kan förhindra att ljudet drunknar när allt annat slåss om utrymmet. Riktlinjer som håller i verkligheten:
- Klassificera audio som EF, DSCP 46, och ge den prioriterad kö med strikt prioritet och tydlig poliser för att undvika att andra applikationer maskerar sig som röst. Begränsa prio-kön till exempelvis 10 procent av länken, ibland 5 procent räcker. Klassificera video som AF41, DSCP 34, och ge dedikerad kö med garanterad bandbredd och WRED. Skärmdelning kan i vissa plattformar flaggas som AF42, kontrollera leverantörens rekommendationer. Signaleringsflöden, SIP eller TLS-kontroll, hamnar ofta som CS3, DSCP 24. Verifiera märkning end to end. På klienter, i konferensutrustning från Cisco eller Microsoft Teams Rooms, i accesswitchar och på WAN-edge. Kontrollera att internetleverantören inte nollställer DSCP, i så fall kan ni åtminstone behålla QoS inom ert nät och prioritera utgående köer. Använd policers på guest VLAN och icke-kritiska klasser så att ett LAN-stormliknande scenario inte svälter video. Shaping på WAN-edge ger bättre kontroll mot moln och MPLS.
Jag har sett störst effekt när ljud får obestridd prioritet och video får stabilt utrymme med aktiv WRED, så att flöden börjar backa innan fyllning. Det är alltid en balans, men fördröjning under 150 ms RTT och jitter under 30 ms är bra målnivåer för att undvika att buffertarna behöver jobba för hårt.
Codecval, upplösningar och hur de styr flödet
Att jaga senaste codec kan verka lockande, men stöd i era rum och klienter styr mer än specifikationen. H.264 är fortfarande arbetshästen för bred kompatibilitet. H.265 sparar bandbredd, ofta 20 till 40 procent, men hårdvarustöd i äldre enheter är ojämnt och licenser komplicerar. AV1 är effektivt, särskilt i låg bitrate, men kräver modern hårdvara eller stark CPU.
SVC, skalbar video, gör större skillnad i multipartsamtal. Videokonferenssystem som stöder SVC, och plattformar som SFU-reläar lager, låter varje mottagare få ett lager som motsvarar dess kapacitet. Det dämpar toppar och ger bättre upplevelse på blandade nät. Aktivera om möjligt, men mät CPU-last på endpoints.
Ljudet ska nästan alltid ligga på Opus 24 till 32 kbit/s för tal, med möjlighet att kliva upp till 48 kbit/s i större rum. Sänkning under 16 kbit/s kompromissar tydlighet i flerspråkiga möten och när folk pratar samtidigt.
MCU, SFU och vad som händer i molnet
Jag får ofta frågan om det är bättre att föra allt via ett centralt bryggekluster i datacentret, eller låta molnet sköta det. I de flesta större organisationer är svaret att låta plattformens edge göra jobbet. Skälen:
- När ni använder Teams eller Webex hamnar media i deras globalt distribuerade noder, nära användaren. Ni vinner på närhet och lastbalansering. SFU-lösningar som Zoom ger bättre skalning i stora möten och sänker belastningen på era centrala länkar, men multiplicerar flöden från varje sändare. Egen MCU i datacenter passar när ni har strikt datasuveränitet eller lokala integrationskrav. Då måste ni dimensionera datacenterlänkar för att bära all media, och räkna med mer interntrafik mellan sajter.
I hybridmodellen, där vissa samtal är on-net interna via Cisco-infrastruktur och andra går mot moln, blir routingregler och preferenslistor viktiga. Cisco Expressway eller liknande kan fortfarande ha sin plats, men räkna på helheten så att ni inte gör era WAN-länkar till en flaskhals.
Splittunnling, säkerhet och SD-WAN
Många upplever det stora lyftet när de inför splittunnling för media. Istället för att alla videoströmmar går in i VPN eller genom ett centralt datacenter bryter klienterna ut direkt mot internet. För Teams och Webex finns tydliga FQDN-listor att tillåta. Vinsten är lägre RTT och mindre kapacitetstryck i er kärna.
Säkerheten kräver bedömning. Med modern DNS-filtrering, klientskydd och TLS-inspektion på rätt ställen går det att få både prestanda och skydd. SD-WAN gör det hanterbart att skicka videomedier ut lokalt samtidigt som annan trafik går via hub. Viktigt att låta SD-WAN:et förstå applikationssignaturer, inte bara portar, och att inte bryta DSCP-märkning.
Ett gott råd är att starta med pilot på två till tre kontor, jämför MOS eller upplevd kvalitet före och efter, och därefter rulla ut widereglage per site.
LAN, Wi‑Fi och var paketen faktiskt försvinner
Wi‑Fi är oftare boven än internetlänken. I öppna kontor med många klienter sker kollisionsdominerade toppar som QoS inte kan rädda. För att mota detta:
- Kör 5 GHz och 6 GHz där ni kan, med begränsat kanalantal och låg sändareffekt för att minska co-channel interference. 2,4 GHz bör vara reserv. Aktivera WMM och mappa DSCP till AC VO för ljud och ACVI för video. Testa i verkligheten, vissa AP-plattformar kräver explicit policy. Lägg rumssystem på trådat nät. Videokonferensutrustning som Cisco Room-serien och Microsoft Teams Rooms levererar stabilare flöde över kabel, särskilt vid 4K delning. Sätt tak för gästers bandbredd och isolera deras SSID. Video över gästnät kostar annars dyr QoS-kapacitet.
På switch-sidan, kontrollera att buffertstorlekar räcker på accessportar anslutna till rumsljudprocessorer och kameror. Billiga switchar med minimala buffertar kan släppa paket vid mikroburst, vilket syns som konstig bildstöt vid applåd eller när någon rör kameran snabbt.
Konfigurationer som gör skillnad i praktiken
Små detaljer spelar stor roll. Ett par exempel från fältet:
- DSCP preservation genom brandväggar. Många NGFW nollställer DSCP om du inte explicit tillåter. Sätt policy per applikation och verifiera med paketfångst, inte bara GUI. Jitterbuffert på endpoint. En del videokonferenssystem erbjuder manuellt läge. I nät med små men frekventa variationer kan en något större buffert jämna ut hack utan att skapa märkbart eko. FEC och retransmission. Under 1 procent varaktig förlust räcker baseline FEC bra. Över 1,5 procent bör ni leta fel, inte öka FEC aggressivt, för det slösar bandbredd. MTU och path MTU discovery. Fel MTU i SD-WAN overlay kan ge fragmentering som äter prestanda. Verifiera med icmp och DF-flagga mot molnedge.
Plattformsspecifika iakttagelser
När infrastrukturen ska bära både klassiska rum och softklienter på flera plattformar vinner du på att känna till deras särdrag. Några exempel som återkommer:
- Videokonferensutrustning Cisco. Room-serien och Webex-enheter märker ofta audio till EF och video till AF41 out of the box. Säkerställ att switcharna accepterar ingress trust på dessa portar, annars skriv om DSCP vid access. Cisco har även stöd för OBTP och kalenderintegration, men tänk på att skärmdelning i 4K kan toppa 12 Mbit/s per ström vid animerat material. Videokonferensutrustning Teams, det vill säga Microsoft Teams Rooms på Windows eller Android, hanterar QoS via Group Policy eller Intune. För att DSCP ska sättas korrekt krävs ofta att ni definierar portintervall och policy för realtidsmedia. När ni aktiverar splittunnling, se till att FQDN för media är korrekt tillåtna i SD-WAN och brandvägg, annars faller klienten tillbaka till mindre fördelaktig väg. BYOD-läge och USB-ingest. När en bärbar ansluter till rummet via USB-C eller HDMI och kör Zoom eller Google Meet lokalt, går media inte via rumsenhetens codec. Det flyttar belastningen till klientens Wi‑Fi. Detta är en vanlig felkälla som bör adresseras i användarpolicy och rumsdesign, till exempel genom att föredra inbyggd plattformsanslutning.
Övervakning som åtgärdar innan folk klagar
Det som räddar möten är ofta tidiga varningar. Sätt SLO:er som går att mäta, till exempel:
- Andel möten med paketförlust under 1 procent. Median-RTT under 120 ms till respektive mediakluster. Andel möten där videon håller 720p eller högre minst 80 procent av tiden.
Plattformar som Teams och Webex erbjuder call analytics i sina adminportaler. Kombinera dessa med nätmätningar från era edge-routrar. Sätt larm på när jitter stiger över 30 ms under mer än 2 minuter på en viss site, eller när WRED-drops i videokön ökar över ett tröskelvärde. Hellre lite för många larm första månaden och sedan justera, än att missa ett mönster.
Ett praktiskt knep är syntetiska möten. Kör schemalagda testklienter som ansluter till ett internt testmöte och streamar video, samt loggar kvalitet. Det är enkel kod med WebRTC-klienter i headless-läge och ger er en baseline när ingen människa sitter i möte.
När ska du begränsa istället för att bygga ut
All bandbredd går att äta upp. I vissa sites är det mer effektivt att lägga en övre gräns. Sänk maxupplösning till 720p på softklienter i trånga nät, eller begränsa frame rate till 15 fps vid skärmdelning med mycket text. På rumssystem i stora kontor kan 1080p vara kvar, medan filialer med 50 Mbit/s internet mår bättre av ett konservativt läge. Det är inte nederlag att reducera ambitionsnivån, tvärtom ger kontrollerad kvalitet en jämnare upplevelse.
Två typfall från verkligheten
I en nordisk region med 12 kontor, där ett huvudkontor hade 1 Gbit/s och filialer låg på 100 till 200 Mbit/s, upplevdes hack i början av varje hel- och halvtimme. Mätning visade spikar i gästnätet när anställda strömmade internvideo. Lösning: ljud och konferensutrustning begränsa gästnätets totala bandwidth, prioritera EF och AF41, och införa 720p som standard i softklienter, 1080p i rum. Resultat var bortfall under 0,5 procent och klagomålen upphörde.
I ett industriföretag med SD-WAN över LTE-reservlänkar föll videon ofta tillbaka i läge med hög FEC och låg upplösning när produktionsnoder uppdaterade firmware. Orsak: policers i nätets middle-mile som inte tog hänsyn till DSCP. Efter omsättning till shaping, och ett separat uppdateringsfönster, kunde de köra 1080p i ledningsrummet igen utan att störa produktionen.
Kort jämförelse av strategier
- Lokal internetbrytning med splittunnling ger lägst latens och bäst upplevelse för molnplattformar, men kräver tydliga säkerhetskontroller nära användaren. Centraliserad breakout via datacenter förenklar kontroll och inspektion, men adderar latens och slår hårt vid toppar, särskilt i SFU-scenarier. Högupplöst video i alla rum stärker intrycket vid kundmöten, men kostar mycket i nät och kräver stabil Wi‑Fi om BYOD är vanligt. Strikt QoS och CAC, call admission control, skyddar kritiska flöden, men för hårda tak kan dra ner kvaliteten i onödan vid korta toppar. Standardisering av konferensutrustning underlättar drift, men lämna utrymme för plattformsspecifika optimeringar, som DSCP-policyer i videokonferensutrustning Cisco eller Intune-profiler för videokonferensutrustning Teams.
Incidentspelbok för när videon hackar
- Kontrollera om det är brett eller lokalt. Jämför två rum på samma site och en softklient. Om alla ser problem i samma tidsfönster, titta på WAN och brandvägg. Kolla DSCP och köstatistik på närmaste switch och edge. Om EF inte når prio-kön, är märkningen borta någonstans. Mät RTT och paketförlust till leverantörens mediakluster. Över 150 ms eller över 1 procent förlust, byt breakout-väg eller styr om via annan internetkant. Sänk temporärt maxupplösning i adminportalen för den berörda plattformen och avaktivera 4K delning, observera om upplevelsen stabiliseras. Felsök Wi‑Fi vid lokala problem. Kör spektrumanalys, prova trådad anslutning för att isolera radiolagret.
Så knyter du ihop det i en större IT‑miljö
Det är frestande att se videon som en separat bubbla, men den påverkas av samma byggstenar som allt annat. CMDB och nettodokumentation ska veta vilka VLAN, köer och policys som gäller för rummen. Change-processen ska inkludera syntetiska mötestester efter förändringar i SD-WAN eller brandväggsregler. Tjänsteägare för nät och för samarbetsplattformar behöver dela samma dashboards, samma språk och samma mål. När någon säger att mötet hackade, och någon annan säger att länken var lugn, pekar en gemensam mätvy ut sanningen.
Att optimera bandbredd är inte ett enskilt projekt, det är ett arbetssätt. När ni har baslinje, mätpunkter och tydliga principer för QoS, codec och topologi, blir resten rullande förbättringar. Nya plattformar eller ny konferensutrustning ska in i samma ramverk, inte kräva speciallösningar vid varje site.
I slutänden är målet enkelt, att samtal känns naturliga. Ljudet utan hack eller eko, bilden utan pixligt flimmer, skärmdelningen som följer talarens tempo. Med rätt design i ryggen brukar det vara fullt möjligt, även i nät där trafiken bär både verksamhetskritiska applikationer och vardagens alla småningar. Och när du väl hittar den balansen, märks det främst genom vad folk inte längre säger, att videon strulade. Då arbetar nätet i tysthet, som det ska.
Fredsforsstigen 22-24, 168 67 Bromma Varumottagning vån 2 tel:08-568 441 00 [email protected]