- Hjem
- /
- Artikkel
I denne artikkelenNy og endret informasjon
Denne tabellen dekker nye funksjoner eller funksjoner, endringer i eksisterende innhold og eventuelle større feil som ble rettet i Distribusjonsveiledning .
Hvis du vil ha informasjon om programvareoppdateringer for Webex Video Mesh-noden, kan du sehttps://help.webex.com/en-us/article/jgobq2/Webex-Video-Mesh-release-notes .
Dato | Endre |
|---|---|
9. februar 2024 |
|
31. august 2023 |
|
31. juli 2023 |
|
28. juli 2023 |
|
15. juni 2023 |
|
| 16. mai 2023 |
|
27. mars 2023 |
|
2. mars 2023 |
|
7. juli 2022 |
|
30. juni 2022 | La til informasjon om de nye masseklargjøringsskriptene påhttps://github.com/CiscoDevNet/webex-video-mesh-node-provisioning . |
14. juni 2022 | Endret trinn for å utveksle sertifikatkjeder for å inkludere ECDSA-sertifikater i Utveksle sertifikatkjeder mellom Unified CM og videonettnoder |
18. mai 2022 | Endret nedlastingsnettstedet for Reflector Tool tilhttps://github.com/CiscoDevNet/webex-video-mesh-reflector-client . |
29. april 2022 | La til informasjon om den nye funksjonen i Oppbevar mediene dine i videonett for alle eksterne Webex-møter . |
25. mars 2022 | Oppdateringer av portbruk i Porter og protokoller for administrasjon . |
10. desember 2021 | Lagt til CMS 2000 og registrerte oppgraderingsproblem for eldre CMS 1000s ved oppgradering til ESXi 7 i System- og plattformkrav for programvare for videonettnode . |
30. august 2021 | La til informasjon om å bekrefte at Webex har riktig kildeland for distribusjonen i Kontroller at kildelandet er riktig . |
27. august 2021 | La til merknad om analyserapporters synlighet i Støtte og begrensninger for private møter . |
13. august 2021 | La til informasjon om den nye private møter-funksjonen i:
|
22. juli 2021 | La til informasjon om hvordan du bekrefter at systemet har riktig kildeplassering for samtaler. Riktige kildeplasseringer bidrar til effektiv ruting. Se Kontroller at kildelandet er riktig . |
25. juni 2021 | Merket at funksjonen for Webex Experience med alle funksjoner i Webex-appen er inkompatibel med Video Mesh i Klienter og enheter som bruker videonettnode . |
7. mai 2021 | Rettet den anbefalte klyngestørrelsen til 100 tommer Retningslinjer for distribusjon av videonettklynge . |
12. april 2021 | Oppdatert Konfigurer Expressway TCP SIP-trafikkruting for videonett for å bruke Webex-sonen i stedet for en ny DNS-sone. |
09. februar 2021 |
|
11. desember 2020 |
|
22. oktober 2020 |
|
| 19. oktober 2020 |
|
| 18. september 2020 |
|
| 26. august 2020 |
|
4. august 2020 |
|
| 9. juli 2020 |
|
26. juni 2020 |
|
| 9. juni 2020 |
|
| 21. mai 2020 | Oppdatert Porter og protokoller for administrasjon og Krav for proxy-støtte for videonett . |
| 15. mai 2020 | Oppdatert Oversikt over videonett . |
| 25. april 2020 |
|
22. januar 2020 |
|
12. desember 2019 |
|
10. desember 2019 |
|
4. november 2019 |
|
| 18. oktober 2019 |
|
26. september 2019 |
|
13. september 2019 |
|
| 29. august 2019 |
|
24. juli 2019 |
|
9. juli 2019 |
|
24. mai 2019 |
|
25. april 2019 |
|
11. april 2019 |
|
Oversikt over Webex-videonett
Med Webex-videonett kan du finne den optimale blandingen av lokale ressurser og ressurser for skykonferanser på en dynamisk måte. Lokale konferanser blir på stedet når det er nok lokale ressurser. Når lokale ressurser er oppbrukt, overføres konferanser til skyen.
videonettnode er programvare som installeres på en lokal Cisco UCS -server, registrert i skyen og administrert i Control Hub. Webex-møter, Webex personlig møterom, Webex Space Meetings og Webex-appen mellom to personer kan rutes til de lokale nettbaserte videonettnodene. Videonett velger den mest effektive måten å bruke de tilgjengelige ressursene på.
Videonett gir disse fordelene:
Forbedrer kvaliteten og reduserer ventetiden ved å la deg holde samtaler lokalt.
Sender samtalene dine til skyen når lokale ressurser har nådd grensen eller er utilgjengelige.
Administrer videonettklyngene dine fra skyen med ett enkelt administrativt grensesnitt: Control Hub (https://admin.webex.com ).
Optimaliser ressurser og kapasitet etter behov.
Kombinerer funksjonene til nettskybaserte og lokale konferanser i en sømløs brukeropplevelse.
Reduserer kapasitetsproblemer, fordi skyen alltid er tilgjengelig når det er behov for ytterligere konferanseressurser. Du trenger ikke å planlegge kapasitet for «verste tilfelle»-situasjoner.
Gir avansert rapportdata av kapasitet og bruk og feilsøkingsrapportdata ihttps://admin.webex.com .
Bruker lokal mediebehandling når brukere ringer inn til et Webex-møte fra lokale standardbaserte SIP-endepunkter og -klienter:
SIP-baserte endepunkter og klienter (Cisco-endepunkter, Jabber, tredjeparts SIP), registrert til lokal samtalekontroll (Cisco Unified Communications Manager eller Expressway), som kaller inn til et Cisco Webex møte.
Webex-app (inkludert paret med romenheter) som blir med i et Webex-møte.
Webex rom- og skrivebordsenheter som blir direkte med i et Webex-møte.
Tilbyr optimalisert interaktiv talerespons (IVR) for lyd og video til SIP-baserte endepunkter og klienter på nettet.
Endepunkter for H.323, IP-innringning og Skype for Business (S4B) fortsetter å bli med i møter fra skyen.
Støtter 1080p 30fps HD-video som et alternativ for møter, hvis møtedeltakere som kan støtte 1080p er vert via de lokale lokale videonettnodene. (Hvis en deltaker blir med i et pågående møte fra skyen, fortsetter lokale brukere å oppleve 1080p 30 bps på støttede endepunkter.)
Forbedret og differensiert QoS-merking (Quality of Service): separat lyd (EF) og video (AF41).
Webex Video Mesh støtter for øyeblikket ikke Webex Webinars.Støtter ende-til-ende-krypterte møter (E2EE-møter). Hvis en kunde distribuerer Video Mesh og velger møtetypen E2EE, legger det til et ekstra sikkerhetslag, noe som sikrer at dataene (medier, filer, tavler, merknader) forblir sikre og blokkerer tredjeparter fra å få tilgang til eller endre dem. Hvis du vil detaljert informasjon, se Distribuer Zero-Trust Meetings .
Private møter støtter for øyeblikket ikke ende-til-ende-kryptering.
Klienter og enheter som bruker videonettnode
Vi bestreber oss på å gjøre Video Mesh interoperabel med relevante klienter og enhetstyper. Selv om det ikke er mulig å teste alle scenarier, dekker testingen som disse dataene er basert på, de fleste vanlige funksjonene til de oppførte endepunktene og infrastrukturen. Fraværet av en enhet eller klient innebærer mangel på testing og mangel på offisiell støtte fra Cisco.
Klient- eller enhetstype | Bruker videonettnode på punkt-til-punkt-anrop | Bruker videonettnode på møte med flere |
|---|---|---|
Webex-app (skrivebord og mobil) | Ja | Ja |
Webex-enheter, inkludert romenheter og Webex Board. (Se Krav til endepunkter og Webex-app delen for en fullstendig liste.) | Ja | Ja |
Trådløs deling på rommet mellom Webex-appen og støttede rom-, skrivebord- og tavleenheter. | Ja | Ja |
Unified CM-registrerte enheter (inkludert IX-endepunkter) og klienter (inkludert Jabber VDI 12.6 og nyere, og Webex VDI 39.3 og nyere), som ringer inn til et planlagt Webex-møte eller et Webex Personal Room-møte.* | Nei | Ja |
VCS/Expressway-registrerte enheter som ringer inn til et planlagt Webex-møte eller et Webex Personal Room-møte.* | Nei | Ja |
Webex Ring Mitt videosystem til Webex skyregistrerte videoenheter | N/A | Ja |
Webex App-nettklient (https://web.webex.com ) | Ja | Ja |
Telefoner registrert for Cisco Webex Calling | Nei | Nei |
Webex Ring Mitt videosystem til lokalt registrerte SIP-enheter | N/A | Nei |
* Det er ikke mulig å garantere at alle lokale enheter og klienter har blitt testet med Video Mesh-løsningen.
Inkompatibilitet med videonett med Webex Experience med alle funksjoner
Hvis du aktiverer Webex Experience med alle funksjoner for Webex-appen, støttes ikke Webex-appen med videonettnodene. Denne funksjonen sender for øyeblikket signalisering og medier direkte til Webex. Fremtidige utgivelser vil gjøre Webex-appen og videonettet kompatible. Som standard aktivert vi ikke denne funksjonen for kunder med Video Mesh.
Du kan ha problemer med videonett og den komplette Webex-opplevelsen:
Hvis du la til Video Mesh i distribusjonen etter introduksjonen av denne funksjonen.
Hvis du aktiverte den funksjonen uten å vite hvilken innvirkning det har på Video Mesh.
Hvis du merker problemer, kan du kontakte Cisco-kontoteamet for å deaktivere bryteren for alle funksjoner i Webex Experience.
Tjenestekvalitet på videonettnode
Videonettnoder overholder anbefalte anbefalte beste praksis for tjenestekvalitet (QoS) ved å aktivere portområder som lar deg skille mellom lyd- og videostrømmer i alle flyter til og fra videonettnodene. Denne endringen lar deg opprette QoS-policyer og effektivt merke trafikk til og fra videonettnodene.
Til disse portendringene følger QoS-endringer. Videomesh-noder merker automatisk medietrafikk fra SIP-registrerte endepunkter (lokal Unified CM eller VCS Expressway-registrert) for både lyd (EF) og video (AF41) separat med passende tjenesteklasse og bruker kjente portområder for bestemte medietyper .
Kildetrafikken fra de lokale registrerte endepunktene bestemmes alltid av konfigurasjonen på samtalekontroll (Unified CM eller VCS Expressway).
Hvis du vil ha mer informasjon, kan du se QoS-tabellen på Porter og protokoller som brukes av videonett og fremgangsmåten for å aktivere eller deaktivere QoS i Oppgaveflyt for distribusjon av videonett
Webex-appen fortsetter å koble til Video Mesh-noder over delt port 5004. Disse portene brukes også av Webex-appen og endepunkter for STUN-tilgjengelighetstester til Video Mesh-noder. Videonett-node til Videonett-node for overlappende enheter bruker målportområdet 10000–40000.Proxy-støtte for videonett
Videomesh støtter eksplisitte, gjennomsiktige proxyer for inspeksjon og ikke-inspeksjon. Du kan knytte disse proxyene til Video Mesh-distribusjonen, slik at du kan sikre og overvåke trafikk fra bedriften og ut til skyen. Denne funksjonen sender signal- og administrasjonsbasert https-trafikk til proxyen. For gjennomsiktige proxyer videresendes nettverksforespørsler fra videonettnoder til en bestemt proxy gjennom rutingsregler for bedriftsnettverk. Du kan bruke administratorgrensesnittet for Video Mesh for sertifikatbehandling og den generelle tilkoblingsstatusen etter at du har implementert proxyen med nodene.
| Medier beveger seg ikke gjennom proxyen. Du må fremdeles åpne de nødvendige portene for mediestrømmer for å nå skyen direkte. Se Porter og protokoller for administrasjon . |
Følgende proxy-typer støttes av videonett:
Eksplisitt proxy (inspeksjons eller ikke-inspeksjons) – Med eksplisitt proxy forteller du klienten (videonettnoder) hvilken proxy-server som skal brukes. Dette alternativet støtter én av følgende godkjenningstyper:
Ingen – Ingen ytterligere godkjenning er nødvendig. (For eksplisitt proxy for HTTP eller HTTPS.)
Grunnleggende – Brukes for en HTTP-brukeragent til å angi brukernavn og passord når du foretar en forespørsel, og bruker Base64-koding. (For eksplisitt proxy for HTTP eller HTTPS.)
Sammendrag – Brukes til å bekrefte identiteten til kontoen før sensitiv informasjon sendes, og bruker en hash-funksjon på brukernavnet og passordet før det sendes over nettverket. (For eksplisitt HTTPS-proxy.)
NTLM – I likhet med Digest brukes NTLM til å bekrefte identiteten til kontoen før sensitiv informasjon sendes. Bruker Windows-legitimasjon i stedet for brukernavn og passord. Denne godkjenningsplanen krever flere utvekslinger for å fullføre. (For eksplisitt HTTP-proxy.)
Gjennomsiktig proxy (ikke-inspeksjon) – Noder for videonett er ikke konfigurert til å bruke en bestemt proxy-serveradresse, og bør ikke trenge endringer for å fungere med en ikke-inspeksjons-proxy.
Gjennomsiktig proxy (inspeksjon) – Noder for videonett er ikke konfigurert til å bruke en bestemt proxy-serveradresse. Ingen konfigurasjonsendringer for http(s) er nødvendige på videonett, men nodene for videonett trenger et rotsertifikat for å kunne klarere proxyen. Inspeksjons-proxyer brukes vanligvis av IT til å håndheve retningslinjer om hvilke nettsteder som kan besøkes, og hvilke typer innhold som ikke er tillatt. Denne typen proxy dekrypterer all trafikken din (til og med HTTPS).
Støttede oppløsninger og bildefrekvenser for videonett
Denne tabellen dekker støttede oppløsninger og bildefrekvenser fra et avsender-mottaker-perspektiv i et møte som er vert på en videonett-node. Avsenderklienten (app eller enhet) er på tvers av den øverste raden i tabellen, mens mottakerklienten er i venstre kolonne i tabellen. Den tilsvarende cellen mellom de to deltakerne fanger opp den forhandlede innholdsoppløsningen, bilder per seksjon og lydkilde.
| Oppløsningen påvirker samtalekapasitet på en hvilken som helst videonettnoder. Hvis du vil ha mer informasjon, se Kapasitet for videonettnoder . |
Verdien for oppløsning og bildefrekvens kombineres som XXXpYY – for eksempel betyr 720p10 720p med 10 bilder per sekund.
Definisjonsforkortelsene (SD, HD og FHD) i avsenderraden og mottakerkolonnen refererer til den øvre oppløsningen til klienten eller enheten:
SD – standardoppløsning (576p)
HD – høy oppløsning (720p)
FHD – full høyoppløsning (1080p)
Mottaker | Avsender | ||||||
|---|---|---|---|---|---|---|---|
Webex-app | Webex-app for mobil | SIP-registrerte enheter (HD) | SIP-registrerte enheter (FHD) | Webex-registrerte enheter (SD) | Webex-registrerte enheter (HD) | Webex-registrerte enheter (FHD) | |
Webex-app på skrivebordet | 720p10 Blandet lyd* | 720p10 Blandet lyd | 720p30 Blandet lyd | 720p30 Blandet lyd | 576p15 Innholdslyd** | 720p30 Blandet lyd | 720p30 Blandet lyd |
Webex-app for mobil | — | — | — | — | — | — | — |
SIP-registrerte enheter (HD) | 720p30 Innholdslyd | 720p15 Blandet lyd | 1080p15 Blandet lyd | 1080p15 Blandet lyd | 576p15 Blandet lyd | 1080p15 Blandet lyd | 1080p15 Blandet lyd |
SIP-registrerte enheter (FHD) | 1080p30 Blandet lyd | 720p15 Blandet lyd | 1080p15 Blandet lyd | 1080p30 Blandet lyd | 576p15 Blandet lyd | 1080p15 Blandet lyd | 1080p30 Blandet lyd |
| Webex-registrerte enheter (SD) | 1080p15 Blandet lyd | 720p15 Blandet lyd | 1080p15 Blandet lyd | 1080p15 Blandet lyd | 576p15 Blandet lyd | 1080p15 Blandet lyd | 1080p15 Blandet lyd |
Webex-registrerte enheter (FHD) | 1080p30 Blandet lyd | 720p15 Blandet lyd | 1080p15 Blandet lyd | 1080p30 Blandet lyd | 576p15 Blandet lyd | 1080p15 Blandet lyd | 1080p30 Blandet lyd |
* Innholdslyd refererer til lyden som spilles av fra det bestemte innholdet som deles, for eksempel en strømming av video. Denne lydstrømmen er atskilt fra vanlig møtelyd.
** Blandet lyd refererer til en blanding av møtedeltaker lyd og lyd fra innholdsdelingen.
Krav for videonett
Videonett er tilgjengelig med tilbudene dokumentert i Lisenskrav for hybridtjenester .
Krav til samtalekontroll og møteintegrering for videonett
Samtalekontroll og eksisterende møteinfrastruktur er ikke nødvendig for å bruke Video Mesh, men du kan integrere de to. Hvis du integrerer Video Mesh med samtalekontroll og møteinfrastrukturen, må du kontrollere at miljøet oppfyller minimumskriteriene som er dokumentert i tabellen nedenfor.
Komponent Formål | Minimum støttet versjon |
|---|---|
Lokal samtalekontroll | Cisco Unified Communications Manager, versjon 11.5(1) SU3 eller nyere. (Vi anbefaler den nyeste SU-versjonen.) Cisco Expressway-C eller E, versjon X8.11.4 eller nyere. (Se delen «Viktig informasjon» i Versjonsmerknader for Expressway for mer informasjon.) |
Møteinfrastruktur | Webex Meetings WBS33 eller nyere. (Du kan bekrefte at Webex-nettsted ditt er på riktig plattform hvis listen Medieressurstype er tilgjengelig i nettstedsalternativene for møterom for skysamarbeid.)
Hvis du vil sikre at nettstedet ditt er klart for Video Mesh, kontakter du din kundesuksessansvarlige (CSM) eller partner. |
Håndtering av failover | Cisco Expressway-C eller E, versjon X8.11.4 eller nyere. (Se delen «Viktig informasjon» i Versjonsmerknader for Expressway for mer informasjon.) |
Krav til endepunkter og Webex-app
Komponent Formål | Detaljer |
|---|---|
Støttede endepunkter | |
Støttede versjoner av Webex-appen | Videomesh støtter Webex-appen for skrivebord (Windows, Mac) og mobil (Android, iPhone og iPad). Hvis du vil laste ned appen for en støttet plattform, går du tilhttps://www.webex.com/downloads.html . |
Støttede kodeker | Se Webex| Videospesifikasjoner for samtaler og møter for lyd- og videokodekene som støttes. Merk disse forbeholdene for videonett:
|
Støttede Webex-registrerte rom-, skrivebords- og tavleenheter | Følgende enheter er testet og bekreftet å fungere med Video Mesh-noder: |
System- og plattformkrav for programvare for videonettnode
Produksjonsmiljøer
I produksjonsdistribusjoner er det to måter å distribuere videonettnode programvare på en bestemt maskinvarekonfigurasjon:
Du kan konfigurere hver server som én virtuell maskin, noe som er best for distribusjoner som inkluderer mange SIP-endepunkter.
Ved hjelp av VMNLite-alternativet kan du konfigurere hver server med flere mindre virtuelle maskiner. VMNLite er best for distribusjoner der flertallet av klienter og enheter er Webex-app og Webex-registrerte endepunkter.
Disse kravene er felles for alle konfigurasjoner:
VMware ESXi 7 eller 8, vSphere 7 eller 8
Hyperthreading aktivert
Videonett-nodene som kjører uavhengig av plattformmaskinvaren, trenger dedikerte vCPU-er og RAM. Deling av ressurser med andre programmer støttes ikke. Dette gjelder for alle bilder av Video Mesh-programvaren.
For VMNLite-bilder (Video Mesh Lite) på en CMS-plattform støtter vi bare å ha VMNLite-bilder. Ingen andre Video Mesh-bilder eller ikke-Video Mesh-applikasjoner kan være på CMS-maskinvaren med VMNLite-programvaren.
Maskinvarekonfigurasjon | Produksjonsdistribusjon som én virtuell maskin | Produksjonsdistribusjon med virtuelle VMNLite-er | Merknader | ||
|---|---|---|---|---|---|
Cisco Meeting Server 1000 (CMS 1000) |
| Distribuer som 3 identiske virtuell maskin , hver med:
| Vi anbefaler denne plattformen for videonettnode.
| ||
Spesifikasjonsbasert konfigurasjon (2,6 GHz Intel Xeon E5-2600v3 eller nyere-prosessor kreves) |
| Distribuer som 3 identiske virtuell maskin , hver med:
| Hver virtuell maskin for Video Mesh må ha CPU, RAM og harddisker reservert for seg selv. Bruk enten CMS1000 eller VMNLite alternativet under konfigurasjonen. Topp IOP-er (inndata-/utdataoperasjoner per sekund) for NFS-lagring er 300 IOPS. | ||
Cisco Meeting Server 2000 (CMS 2000) | Distribuer som 8 identiske virtuell maskin , hver med:
| Distribuer som 24 identiske virtuell maskin , hver med:
| Vi anbefaler denne plattformen for videonettnode. Hvert blad må være en komplett Cisco Meeting Server 1000 med reservert CPU, RAM og harddisker per blad. Topp IOP-verdier for NFS-lagring er 300 IOPS. |
Demomiljøer
For grunnleggende demoformål kan du bruke en spesifikasjonsbasert maskinvarekonfigurasjon, med følgende minimumskrav:
14vCPU-er (12 for videonettnode, 2 for ESXi)
8 GB hovedminne
20 GB lokal harddiskplass
2,6 GHz Intel Xeon E5-2600v3 eller nyere-prosessor
| Denne konfigurasjonen av Video Mesh støttes ikke av Cisco TAC . |
Hvis du vil ha mer informasjon om demoprogramvaren, se Demoprogramvare for videonettnode .
Krav til båndbredde
Videonettnoder må ha en minimumsbåndbredde til Internett på 10 Mbps for at både opplasting og nedlasting skal fungere som den skal.
Krav for proxy-støtte for videonett
Vi støtter offisielt følgende proxy-løsninger som kan integreres med Video Mesh-nodene dine.
Cisco Web Security Appliance (WSA) for gjennomsiktig proxy
Squid for eksplisitt proxy
For en eksplisitt proxy eller gjennomsiktig inspeksjons-proxy som inspiserer (dekrypterer trafikk), må du ha en kopi av proxyens rotsertifikat som du må laste opp til klareringslageret for Video Mesh-noden i webgrensesnitt.
Vi støtter følgende eksplisitte kombinasjoner av proxy- og godkjenningstyper:
Ingen godkjenning med http og https
Enkel godkjenning med http og https
Sammendragsgodkjenning kun med https
NTLM-godkjenning kun med http
For gjennomsiktige proxyer må du bruke ruteren/bryteren til å tvinge HTTPS/443-trafikk til å gå til proxyen. Du kan også tvinge Web Socket til å gå til proxy. (Web Socket bruker https.)
Video Mesh krever web-socket-tilkoblinger til skytjenester, slik at nodene fungerer som de skal. På eksplisitt inspeksjons- og transparente inspeksjons proxyer kreves http-hoder for en riktig websocket-tilkobling. Hvis de endres, vil websocket-tilkoblingen mislykkes.
Når websocket- tilkoblingsfeil oppstår på port 443 (med transparent inspeksjons-proxy aktivert), fører det til en advarsel etter registrering i Control Hub: «SIP-anrop for Webex-videonett fungerer ikke som det skal.» Den samme alarmen kan oppstå av andre årsaker når proxy ikke er aktivert. Når websocket-overskrifter blokkeres på port 443, flyter ikke medier mellom apper og SIP-klienter.
Hvis mediet ikke flyter, skjer dette ofte når https-trafikk fra noden over port 443 svikter:
Port 443-trafikk er tillatt av proxyen, men det er en inspeksjons proxy og bryter websocket.
For å løse disse problemene må du kanskje «omgå» eller «skjøte» (deaktivere inspeksjon) på port 443 til: *.wbx2.com og *.ciscospark.com.
Kapasitet for videonettnoder
Siden Video Mesh er et programvarebasert medieprodukt, varierer kapasiteten til Video Mesh-nodene. Spesielt legger møtedeltakere i Webex-skyen en tyngre belastning på nodene. Du får lavere kapasitet når du har flere overlappinger til Webex-skyen. Andre faktorer som påvirker kapasiteten er:
Enhetstyper og klienter
Videooppløsning
Nettverkskvalitet
Toppbelastning
Distribusjonsmodell
| Bruk av videonett påvirker ikke antall Webex-lisenser. |
Generelt sett dobler ikke kapasiteten ved å legge til flere noder i klyngen på grunn av kostnadene for å sette opp overlappende enheter. Bruk disse tallene som generell veiledning. Vi anbefaler følgende:
Test ut vanlige møtescenarier for distribusjonen din.
Bruk analysene i Control Hub for å se hvordan distribusjonen utvikler seg, og legg til kapasitet etter behov.
| Overflyt ved lavt samtalevolum (spesielt SIP-anrop som kommer lokalt) er ikke en sann refleksjon av skala. Videonettanalyse (under Kontroller Hub > Ressurser > Samtaleaktivitet ) angir anropsdelene som kommer fra lokalt. De angir ikke samtalestrømmene som kom inn gjennom overlappingen til videonett-noden for mediebehandling. Etter hvert som antall eksterne deltakere øker i et møte, øker gjennomgripende grupper og bruker lokale medieressurser på videonett-noden. |
Denne tabellen viser kapasitetsområder for forskjellige blandingsdeltakere og endepunkter på vanlige videonettnoder. Testingen vår inkluderte møter med alle deltakerne på den lokale noden og møter med en blanding av lokale deltakere og skydeltakere. Med flere deltakere på Webex-skyen kan du forvente at kapasiteten din faller i den nedre enden av området.
Scenario | Oppløsning | Deltakerkapasitet |
|---|---|---|
Møter med bare deltakere i Webex-appen | 720p | 100–130 |
1080p | 90–100 | |
Møter og 1-til-1-samtaler med bare deltakere i Webex-appen | 720p | 60–100 |
1080p | 90–100 | |
Møter med kun SIP-deltakere | 720p | 70–80 |
Møter med kun SIP-deltakere | 1080p | 30–40 |
Møter med Webex-appen og SIP-deltakere | 720p | 75–110 |
|
|
Kapasitet for VMNLite
Vi anbefaler VMNLite for distribusjoner som hovedsakelig inkluderer Webex-appen og skyregistrerte endepunkter. I disse distribusjonene bruker nodene mer svitsjing og færre transkodingsressurser enn standardkonfigurasjonen gir. Distribusjon av flere mindre virtuelle maskiner på verten optimaliserer ressursene for dette scenariet.
Denne tabellen viser kapasitetsområder for forskjellige blandinger av deltakere og endepunkter. Testingen vår inkluderte møter med alle deltakerne på den lokale noden og møter med en blanding av lokale deltakere og skydeltakere. Med flere deltakere på Webex-skyen kan du forvente at kapasiteten din faller i den nedre enden av området.
Scenario | Oppløsning | Deltakerkapasitet med 3 VMNLite-noder på en server |
|---|---|---|
Møter med bare deltakere i Webex-appen | 720p | 250–300 |
1080p | 230–240 | |
Møter og 1-til-1-samtaler med bare deltakere i Webex-appen | 720p | 175–275 |
1080p | 230–240 |
| Grunnoppløsningen for Webex-appmøter er 720p. Men når du deler, er deltakerminiatyrbildene på 180p. |
Klynger i videonett
Du distribuerer Video Mesh-noder i klynger. En klynge definerer videonettnoder med lignende attributter, for eksempel nettverksnærhet. Deltakerne bruker en bestemt klynge eller skyen, avhengig av følgende forhold:
En klient på et bedriftsnettverk som kan nå en lokal klynge, kobles til den – den primære preferansen for klienter på bedriftsnettverk.
Klienter som blir med i et privat møte med Video Mesh, kobles bare til lokale klynger. Du kan opprette en egen klynge spesielt for disse private møtene.
En klient som ikke kan nå en lokal klynge, kobles til skyen – tilfellet for en mobilenhet som ikke er koblet til bedriftsnettverk.
Den valgte klyngen avhenger også av ventetid, i stedet for bare plassering. For eksempel kan en skyklynge med lavere STUN-tur-retur-forsinkelse (SRT) enn en videonettklynge være en bedre kandidat for møtet. Denne logikken forhindrer en bruker i å lande på en geografisk fjern klynge med høy SRT-forsinkelse.
Hver klynge inneholder logikk som gjennomgriper møter, unntatt private møter i Video Mesh, på tvers av andre skymøteklynger, etter behov. Overlappende funksjoner gir en databane for medier mellom klienter i møtene sine. Møter er fordelt på tvers av noder, og klienter lander på den mest effektive noden nærmest dem, avhengig av faktorer som nettverkstopologi, WAN-kobling og ressursutnyttelse.
Klientens mulighet til å pinge medienoder avgjør tilgjengeligheten. Et faktisk anrop bruker en rekke potensielle tilkoblingsmekanismer, for eksempel UDP og TCP. Før samtalen registreres Webex-enheten (rom, skrivebord, tavle og Webex-app) med Webex-skyen, som gir en liste over klyngekandidater for samtalen.
| Nodene i en videonett-klynge krever uhindret kommunikasjon med hverandre. De krever også uhindret kommunikasjon med nodene i alle de andre videonett-klyngene. Kontroller at brannmurene tillater all kommunikasjon mellom videonettnodene. |
Klynger for private møter
Du kan reservere en videonett-klynge for private møter. Når den reserverte klyngen er full, overføres de private møtemediene til de andre videonett-klyngene dine. Når den reserverte klyngen er full, deler private møter og ikke-private møter ressursene til de gjenværende klyngene.
Ikke-private møter bruker ikke en reservert klynge, og disse ressursene reserveres for de private møtene. Hvis et ikke-privat møte går tom for ressurser på nettverket, overføres det til Webex-skyen i stedet.
Hvis du vil ha mer informasjon om funksjonen for private møter i videonett, se Private møter .
| Du kan ikke bruke adresseformatet for kort video (meet@your_site ) hvis du reserverer alle Video Mesh-klynger for private møter. Disse anropene mislykkes for øyeblikket uten en riktig feilmelding. Hvis du lar noen klynger være ureserverte, kan samtaler med formatet for korte videoadresser kobles til gjennom disse klyngene. |
Retningslinjer for distribusjon av videonettklynge
I typiske bedriftsdistribusjoner anbefaler vi at kunder bruker opptil 100 noder per klynge. Det er ingen faste grenser i systemet for å blokkere en klyngestørrelse med mer enn 100 noder. Hvis du imidlertid trenger å opprette større klynger, anbefaler vi på det sterkeste at du går gjennom dette alternativet med Cisco-teknologi gjennom ditt Cisco-kontoteam.
Opprett færre klynger når ressursene har lignende nettverksnærhet (tilhørighet).
Når du oppretter klynger, må du bare legge til noder som er i samme geografiske område og samme datasenter. Klynger over Wide Area Network (WAN) støttes ikke.
Vanligvis distribuerer du klynger i bedrifter som er vert for hyppige lokaliserte møter. Planlegg hvor du plasserer klynger på båndbredden som er tilgjengelig på forskjellige WAN-plasseringer i bedriften. Over tid kan du distribuere og vokse klynge for klynge basert på observerte brukermønstre.
Klynger som befinner seg i forskjellige tidssoner, kan effektivt betjene flere geografiske områder ved å dra nytte av forskjellige anropsmønstre med peak/ travel time .
Hvis du har to Video Mesh-noder i to separate datasentre (EU og NA, for eksempel), og du har endepunkter som kobles sammen gjennom hvert datasenter, vil nodene i hvert datasenter overlappe hverandre til én enkelt Video Mesh-node i skyen. Disse kaskader ville gå over Internett. Hvis det finnes en skydeltaker (som blir med før en av Video Mesh-deltakerne), vil nodene bli koblet gjennom skydeltakerens medianode.
Mangfold i tidssone
Mangfold mellom tidssoner kan tillate deling av klynger i dårlige perioder. For eksempel: Et selskap med en klynge i Nord-California og en klynge i New York kan oppleve at den samlede nettverksforsinkelsen ikke er så høy mellom de to stedene som betjener en geografisk variert brukergruppe. Når ressursbruken er på topp i Nord-California-klyngen, vil New York-klyngen sannsynligvis være lav og ha ekstra kapasitet. Det samme gjelder for Nord-California-klyngen, i rushtiden i New York-klyngen. Dette er ikke de eneste mekanismene som brukes for effektiv distribusjon av ressurser, men de er de to viktigste.
Overflyt til skyen
Når kapasiteten til alle lokale klynger er nådd, flyter en lokal deltaker over til Webex-skyen. Dette betyr ikke at alle samtaler er vert i skyen. Webex sender bare deltakerne som enten er eksterne eller ikke kan koble til en lokal klynge, til skyen. I en samtale med både lokale og skydeltakere, er den lokale klyngen koblet (overlappende) til skyen for å kombinere alle deltakerne til én enkelt samtale.
Hvis du konfigurerer møtet som den private møtetypen, beholder Webex alle samtalene i de lokale klyngene dine. Private møter flyter aldri over til skyen.
Webex-enhet registreres med Webex
I tillegg til å bestemme tilgjengelighet, utfører klientene også periodiske forsinkelsestester tur/retur ved hjelp av enkel gjennomkjøring av UDP gjennom NAT (STUN). STUN-tur-retur-forsinkelse (SRT) er en viktig faktor når du velger potensielle ressurser under en faktisk samtale. Når flere klynger distribueres, er de primære utvalgskriteriene basert på den lærte SRT-forsinkelsen. Tilgjengelighetstester utføres i bakgrunnen, initiert av en rekke faktorer, inkludert nettverksendringer, og introduserer ikke forsinkelser som påvirker tidspunktet for oppsett av samtaler. De følgende to eksemplene viser mulige resultater fra tester for nåbarhet.
Tester med forsinkelser tur/retur – skyenheten når ikke den lokale klyngen
Tester med forsinkelser tur/retur – skyenheten når den lokale klyngen
Lært tilgjengelighetsinformasjon leveres til Webex-skyen hver gang en samtale konfigureres. Denne informasjonen lar skyen velge den beste ressursen (klynge eller sky), avhengig av den relative plasseringen av klienten til tilgjengelige klynger og samtaletypen. Hvis ingen ressurser er tilgjengelige i den foretrukne klyngen, testes alle klyngene for tilgjengelighet basert på SRT-forsinkelse. En foretrukket klynge velges med lavest SRT-forsinkelse. Samtaler betjenes lokalt fra en sekundær klynge når den primære klyngen er opptatt. Lokale videonettressurser som kan nås, prøves først, i rekkefølge etter laveste SRT-forsinkelse. Når alle lokale ressurser er oppbrukt, kobler deltakeren seg til skyen.
Klyngedefinisjon og plassering er avgjørende for en distribusjon som gir den beste generelle opplevelsen for deltakerne. Ideelt sett bør en distribusjon gi ressurser der klientene befinner seg. Hvis det ikke er tildelt nok ressurser der klientene foretar de fleste samtalene, brukes mer intern nettverksbåndbredde for å koble brukere til fjerne klynger.
Lokal og skysamtale
Lokale Webex-enheter som har samme klyngetilhørighet (preferanse, basert på nærhet til klyngen), kobler til den samme klyngen for en samtale. Lokale Webex-enheter med forskjellige lokale klyngetilhørigheter kobles til forskjellige klynger, og klyngene deretter gjennomgripende til skyen for å kombinere de to miljøene til én enkelt samtale. Dette oppretter en hub- og taledesign med Webex-sky som hub og de lokale klyngene som fungerer som taler i møtet.
Lokal samtale med forskjellige klyngetilknytninger
Webex-enheten kobles til enten lokal klynge eller sky basert på tilgjengeligheten. Følgende viser eksempler på de vanligste scenariene.
Webex Cloud enhet kobles til skyen
Den lokale Webex-enheten kobles til den lokale klyngen
Lokal Webex-enhet kobles til skyen
Skyklyngevalg for overflyt basert på 250 ms eller høyere STUN tur-retur-forsinkelse
Selv om preferansen for nodevalg er de lokalt distribuerte Video Mesh-nodene, støtter vi et scenario der STUN-tur-retur-forsinkelsen til en lokal Video Mesh-klynge overskrider den tolererbare tur-retur forsinkelsen på 250 ms (som skjer vanligvis hvis den lokale klyngen er konfigurert på et annet kontinent), velger systemet den nærmeste skymedienoden i det geografiske området i stedet for en videonett-node.
Webex-appen eller Webex-enheten er på bedriftsnettverket i San Jose.
San Jose- og Amsterdam-klynger er fulle eller utilgjengelige.
SRT-forsinkelse til Shanghai-klyngen er større enn 250 ms og vil sannsynligvis føre til problemer med mediekvaliteten.
San Francisco-skyklyngen har en optimal SRT-forsinkelse.
Shanghai-videonett-klyngen er ekskludert fra vurdering.
Som et resultat av dette flyter Webex-appen over til San Francisco-skyklyngen.
Private møter
Private møter isolerer alle medier til nettverket ditt via Video Mesh. I motsetning til vanlige møter, hvis de lokale nodene er fulle, overføres ikke mediene til Webex-skyen. Men som standard kan private møter gå gjennom til forskjellige videonett-klynger på nettverket ditt. For private møter på tvers av geografiske steder må videonettklyngene dine ha direkte tilkobling til hverandre for å tillate overlappende klynger, for eksempel HQ1_ VMN til Remote1_ VMN i figuren.
Kontroller at de nødvendige portene er åpne i brannmuren, for å tillate uhindret overlapping mellom klynger. Se Porter og protokoller for administrasjon .
Alle deltakere i et privat møte må tilhøre møtevertens Webex-organisasjon. De kan bli med ved hjelp av Webex-appen eller et autentisert videosystem (SIP-endepunkter registrert på UCM/VCS eller Webex-registrert videoenhet). Deltakere med VPN- eller MRA-tilgang til nettverket ditt kan bli med i et privat møte. Men ingen kan bli med på et privat møte utenfor nettverket ditt.
Distribusjonsmodeller som støttes av videonett
- Støttes i en distribusjon av videonett
-
Du kan distribuere en videonettnode i enten et datasenter (foretrukket) eller i demilitarisert sone (DMZ). Hvis du vil ha veiledning, se Porter og protokoller som brukes av videonett .
For en DMZ-distribusjon kan du konfigurere videonettnodene i en klynge med det to nettverksgrensesnitt (NIC). Denne distribusjonen lar deg skille bedriftens interne nettverkstrafikk (brukes til interbokskommunikasjon, overlappende nodeklynger og for å få tilgang til nodens administrasjonsgrensesnitt) fra den eksterne skynettverkstrafikken (brukes for tilkobling til omverdenen og gjennomgripende til skyen).
Dobbelt nettverkskort fungerer på den fullstendige VMNLite- og demoversjonen av nodeprogramvaren for Video Mesh. Du kan også distribuere videonettet bak et 1:1 NAT-oppsett.
Du kan integrere Video Mesh-noder med samtalekontroll . For eksempel distribusjoner med Video Mesh integrert med Unified CM, se Distribusjonsmodeller for Video Mesh og Cisco Unified Communications Manager .
Følgende typer adresseoversettelse støttes:
Dynamisk oversettelse av nettverksadresse (NAT) ved hjelp av et IP-utvalg
Dynamisk oversettelse av portadresse (PAT)
1:1 NAT
Andre former for NAT skal fungere så lenge de riktige portene og protokollene brukes, men vi støtter ikke offisielt dem fordi de ikke har blitt testet.
IPv4
Statisk IP-adresse for videonettnode
- Støttes ikke i en distribusjon av videonett
-
IPv6
DHCP for videonettnode
En klynge med en blanding av enkelt og to nettverkskort
Klynger av videonettnoder over WAN (Wide Area Network)
Lyd, video eller medier som ikke går gjennom en videonettnode:
Lyd fra telefoner
Node-til-node-anrop mellom Webex-appen og standardbasert endepunkt
Lydavslutning på videonettnode
Medier sendt gjennom Expressway C/E-par
Videosamtale tilbakeringing fra Webex
Distribusjonsmodeller for Video Mesh og Cisco Unified Communications Manager
Disse eksemplene viser vanlige Video Mesh-distribusjoner og hjelper deg å forstå hvor Video Mesh-klynger kan passe inn i nettverket ditt. Husk at distribusjon av Video Mesh avhenger av faktorer i nettverkstopologien:
Steder for datasenter
Kontorplasseringer og størrelse
Sted og kapasitet for Internett-tilgang
Generelt kan du prøve å knytte Video Mesh-nodene til Unified CM eller SME-klynger ( Session Management Edition ). Som en beste praksis bør du holde nodene så sentralisert som mulig til de lokale avdelingene.
Video Mesh støtter SME ( Session Management Edition ). Unified CM -klynger kan kobles til via en SME, og deretter må du opprette en SME-trunk som kobles til Video Mesh-nodene.
Hub- og Spoke-arkitektur
Denne distribusjonsmodell innebærer sentralisert nettverk og Internett-tilgang. Det sentrale stedet har vanligvis høy konsentrasjon av ansatte. I dette tilfellet kan en videonett-klynge plasseres sentralt for optimalisert mediehåndtering.
Plassering av klynger i filialer vil kanskje ikke gi fordeler på kort sikt, og kan føre til suboptimal ruting. Vi anbefaler at du bare distribuerer klynger i en gren hvis det er hyppig kommunikasjon mellom grenene.
Geografisk distribusjon
Den geografisk distribuerte distribusjonen er sammenkoblet, men kan ha merkbar forsinkelse mellom regioner. Mangel på ressurser kan føre til at det settes opp suboptimale kaskader på kort sikt når det er møter mellom brukere på hvert geografisk sted. I denne modellen anbefaler vi at du tilordner videonettnoder i nærheten av regional Internett-tilgang.
Geografisk distribusjon med SIP-oppringing
Denne distribusjonsmodell inneholder regionale Unified CM -klynger. Hver klynge kan inneholde en SIP-trunk for å velge ressurser i den lokale videonett-klyngen. En andre trunk kan gi en failover-bane til et Expressway-par hvis ressursene blir begrenset.
Porter og protokoller som brukes av videonett
For å sikre en vellykket distribusjon av Video Mesh og for problemfri drift av Video Mesh-nodene, åpner du følgende porter på brannmuren for bruk med protokollene.
Se Nettverkskrav for Webex-tjenester for å forstå de generelle nettverkskravene for Webex Teams.
Se Hvitbok for gjennomgang av brannmur hvis du vil ha mer informasjon om brannmur- og nettverkspraksis for Webex-tjenester.
Hvis du vil redusere potensielle problemer med DNS-spørringer, følger du veiledningen Anbefalte fremgangsmåter for DNS, nettverksbeskyttelse og angrepsidentifikasjon dokumentasjonen når du konfigurerer bedriftens brannmur.
Hvis du vil ha mer designinformasjon, kan du se Foretrukket arkitektur for hybridtjenester, CVD .
Porter og protokoller for administrasjon
| Nodene i en videonett-klynge krever uhindret kommunikasjon med hverandre. De krever også uhindret kommunikasjon med nodene i alle de andre videonett-klyngene. Kontroller at brannmurene tillater all kommunikasjon mellom videonettnodene. |
Videonettnodene i en klynge må være i samme VLAN- eller nettverksmaske.
Hensikt | Kilde | Destinasjon | Kilde-IP | Kildeport | Transportprotokoll | Destinasjons-IP | Målport |
|---|---|---|---|---|---|---|---|
Administrasjon | Administrasjonsdatamaskin | Videonett-node | Etter behov | Hvilke som helst | TCP, HTTPS | Videonett-node | 443 |
SSH for tilgang til administrasjonskonsollen for Video Mesh | Administrasjonsdatamaskin | Videonett-node | Etter behov | Hvilke som helst | TCP | Videonett-node | 22 |
Intraklyngekommunikasjon | Videonett-node | Videonett-node | IP-adresse til andre Video Mesh-noder i klyngen | Hvilke som helst | TCP | Videonett-noder | 8443 |
Administrasjon | Videonett-node | Webex-sky | Etter behov | Hvilke som helst | UDP, NTP UDP, DNS TCP, HTTPS (WebSockets) | Hvilke som helst | 123* 53* |
Overlappende signalisering | Videonett-node | Webex-sky | Hvilke som helst | Hvilke som helst | TCP | Hvilke som helst | 443 |
Overlappende medier | Videonett-node | Webex-sky | Videonett-node | Alle*** | UDP | Hvilke som helst Hvis du vil ha spesifikke adresseområder, kan du se delen «IP-delnett for Webex Media-tjenester» i Nettverkskrav for Webex-tjenester . | 5004 50000 til 53000 Hvis du vil ha mer informasjon, kan du se delen «Webex-tjenester – portnumre og protokoller» i Nettverkskrav for Webex-tjenester . |
Overlappende signalisering | Vido-nettklynge (1) | Vido-nettklynge (2) | Hvilke som helst | Hvilke som helst | TCP | Hvilke som helst | 443 |
Overlappende medier | Vido-nettklynge (1) | Vido-nettklynge (2) | Vido-nettklynge (1) | Alle*** | UDP | Hvilke som helst | 5004 50000 til 53000 |
Administrasjon | Videonett-node | Webex-sky | Etter behov | Hvilke som helst | TCP, HTTPS | Alle** | 443 |
Administrasjon | Videonett-node (1) | Videonett-node (2) | Videonett-node (1) | Hvilke som helst | TCP, HTTPS (WebSockets) | Videonett-node (2) | 443 |
Intern kommunikasjon | Videonett-node | Alle andre videonettnoder | Videonett-node | Hvilke som helst | UDP | Hvilke som helst | 10000 til 40000 |
* Standardkonfigurasjonen i OVA er konfigurert for NTP og DNS. OVA krever at du åpner disse portene utgående til Internett. Hvis du konfigurerer en lokal NTP- og DNS-server, trenger du ikke å åpne portene 53 og 123 gjennom brannmuren.
** Siden enkelte nettadresser for nettskytjenester kan endres uten forvarsel, er ANY det anbefalte målet for problemfri drift av videonettnodene. Hvis du foretrekker å filtrere trafikk basert på nettadresser, kan du se Webex Teams-URL-adresser for hybridtjenester
delen av Nettverkskrav for Webex-tjenester hvis du vil ha mer informasjon.
***Portene varierer avhengig av om du aktiverer QoS. Med QoS aktivert er portene 52.500-59499, 63000-64667, 59500-62999 og 64688-65500. Med QoS av er portene 34.000–34.999.
Trafikksignaturer for videonett (tjenestekvalitet aktivert)
For distribusjoner der Video Mesh-noden befinner seg på bedriftssiden av DMZ eller i brannmuren, finnes det en konfigurasjonsinnstilling for videonettnode i Webex Control Hub som lar administrator optimalisere portområdene som brukes av videonettnode for QoS nettverksmerking. Denne innstillingen for tjenestekvalitet er aktivert som standard og endrer kildeportene som brukes til lyd-, video- og innholdsdeling til verdiene i denne tabellen. Denne innstillingen lar deg konfigurere retningslinjer for QoS-merking basert på UDP-portområder for å skille lyd fra video eller innholdsdeling og merke all lyd med anbefalt verdi på EF og Video og innholdsdeling med en anbefalt verdi på AF41.
Tabellen og diagrammet viser UDP-porter som brukes til lyd- og videostrømmer, som er hovedfokuset for QoS-nettverkskonfigurasjoner. Mens retningslinjer for nettverks- QoS-merking for medier over UDP er fokuset i tabellen nedenfor, avslutter Webex Video Mesh-noder også TCP-trafikk for presentasjon og innholdsdeling for Webex-app ved hjelp av flyktige porter 52500–65500. Hvis det er en brannmur mellom Video Mesh-nodene og Webex-app, må disse TCP-portene også tillates for at de skal fungere som de skal.
| videonettnode merker trafikk innebygd. Denne interne merkingen er asymmetrisk i noen flyter og avhenger av om kildeportene er delte porter (enkel port som 5004 for flere flyter til forskjellige destinasjoner og målporter) eller om de ikke er det (der porten faller i et område, men er unik for den spesifikke toveisøkten). Hvis du vil forstå den opprinnelige merkingen av en videonettnode, merker du at videonettnoden merker lyd EF når den ikke bruker 5004-porten som kildeport. Noen toveisflyter som overlappende videonett til videonett eller Videonett til Webex-appen vil være asymmetrisk merket, noe som er en grunn til å bruke nettverket til å merke trafikk basert på de oppgitte UDP-portområdene. |
| Kilde-IP-adresse | Destinasjons-IP-adresse | Kilde UDP-porter | UDP-målporter | Innebygd DSCP-merking | Mediatype |
Videonettnode | Webex skymedietjenester | 35000 til 52499 | 5004 | AF41 | Test STUN-pakker |
| Videonettnode | Webex skymedietjenester | 52500 til 59499 | 5004 | EF | Lyd |
| Videonettnode | Webex skymedietjenester | 63000 til 64667 | 5004 | AF41 | Video |
| Videonettnode | Webex skymedietjenester | 59500 til 62999 | 50 000 til 51499 | EF | Lyd |
| Videonettnode | Webex skymedietjenester | 64668 til 65500 | 51500 til 53000 | AF41 | Video |
| Videonettnode | Videonettnode | 10000 til 40000 | 10000 til 40000 | — | Lyd |
| Videonettnode | Videonettnode | 10000 til 40000 | 10000 til 40000 | — | Video |
| Videonettnode | Unified CM SIP-endepunkter | 52500 til 59499 | Unified CM SIP-profil | EF | Lyd |
| Videonettnode | Unified CM SIP-endepunkter | 63000 til 64667 | Unified CM SIP-profil | AF41 | Video |
Videonett-klynge | Videonett-klynge | 52500 til 59499 | 5004 | EF | Lyd |
Videonett-klynge | Videonett-klynge | 63000 til 64667 | 5004 | AF41 | Video |
Videonett-klynge | Videonett-klynge | 59500 til 62999 | 50 000 til 51499 | EF | Lyd |
Videonett-klynge | Videonett-klynge | 64668 til 65500 | 51500 til 53000 | AF41 | Video |
| Videonettnode | Webex Teams-program eller endepunkt* | 5004 | 52000 til 52099 | AF41 | Lyd |
| Videonettnode | Webex Teams-program eller endepunkt | 5004 | 52100 til 52299 | AF41 | Video |
* Retningen på medietrafikk avgjør DSCP-merkingene. Hvis kildeportene kommer fra videonett-noden (fra videonett-noden til Webex Teams-app), merkes trafikken bare som AF41. Medietrafikk som kommer fra Webex Teams-app eller Webex-endepunkter, har de separate DSCP-merkingene, men det har ikke returtrafikken fra de delte portene for videonettnoden.
| UDP-kildeportdifferensiering (Windows Webex-appklienter): Ta kontakt med det lokale kontoteamet hvis du vil at UDP-kildeportdifferensiering skal aktiveres for organisasjonen din. Hvis dette ikke er aktivert, kan ikke lyd- og videodeling skilles fra Windows OS. Kildeportene vil være de samme for lyd, video og innholdsdeling på Windows-enheter. |
Trafikksignaturer for videonett (tjenestekvalitet deaktivert)
For distribusjoner der Video Mesh-noden befinner seg i DMZ, finnes det en konfigurasjonsinnstilling for videonettnode i Webex Control Hub som lar deg optimalisere portområdene som brukes av Video Mesh-noden. Denne innstillingen for tjenestekvalitet, når den er deaktivert (aktivert som standard), endrer kildeportene som brukes til lyd-, video- og innholdsdeling fra Video Mesh-noden til området 34000 til 34999. Videonett-noden merker deretter all lyd-, video- og innholdsdeling til én enkelt DSCP for AF41.
| Siden kildeportene er de samme for alle medier uavhengig av mål, kan du ikke skille mellom lyd og video eller innholdsdeling basert på portområde med denne innstillingen deaktivert. Denne konfigurasjonen lar deg konfigurere brannmurhull for medier på en enklere måte enn når tjenestekvalitet er aktivert. |
Tabellen og diagrammet viser UDP-porter som brukes til lyd- og videostrømmer når QoS er deaktivert.
| Kilde-IP-adresse | Destinasjons-IP-adresse | Kilde UDP-porter | UDP-målporter | Innebygd DSCP-merking | Mediatype |
| Videonettnode | Webex skymedietjenester | 34000 til 34999 | 5004 | AF41 | Lyd |
| Videonettnode | Webex skymedietjenester | 34000 til 34999 | 5004 | AF41 | Video |
| Videonettnode | Webex skymedietjenester | 34000 til 34999 | 50 000 til 51499 | AF41 | Lyd |
| Videonettnode | Webex skymedietjenester | 34000 til 34999 | 51500 til 53000 | AF41 | Video |
| Videonettnode | Videonettnode | 10000 til 40000 | 10000 til 40000 | AF41 | Lyd |
| Videonettnode | Videonettnode | 10000 til 40000 | 10000 til 40000 | AF41 | Video |
Videonett-klynge | Videonett-klynge | 34000 til 34999 | 5004 | AF41 | Lyd |
Videonett-klynge | Videonett-klynge | 34000 til 34999 | 5004 | AF41 | Video |
Videonett-klynge | Videonett-klynge | 34000 til 34999 | 50 000 til 51499 | AF41 | Lyd |
Videonett-klynge | Videonett-klynge | 34000 til 34999 | 51500 til 53000 | AF41 | Video |
| Videonettnode | Unified CM SIP-endepunkter | 52500 til 59499 | Unified CM SIP-profil | AF41 | Lyd |
| Videonettnode | Unified CM SIP-endepunkter | 63000 til 64667 | Unified CM SIP-profil | AF41 | Video |
Videonettnode | Webex skymedietjenester | 35000 til 52499 | 5004 | AF41 | Test STUN-pakker |
| Videonettnode | Webex Teams-program eller endepunkt | 5004 | 52000 til 52099 | AF41 | Lyd |
| Videonettnode | Webex Teams-program eller endepunkt | 5004 | 52100 til 52299 | AF41 | Video |
Porter og protokoller for Webex Meetings trafikk
Hensikt | Kilde | Destinasjon | Kilde-IP | Kildeport | Transportprotokoll | Destinasjons-IP | Målport |
|---|---|---|---|---|---|---|---|
Innkaller til møte | Apper (Webex-appen for skrivebord og mobilapper) Webex-registrerte enheter | Videonett-node | Etter behov | Hvilke som helst | UDP og TCP (brukes av Webex-appen) SRTP (alle) | Alle** | 5004 |
SIP-enhet som ringer til møte (SIP-signalisering) | samtalekontroll i Unified CM eller Cisco Expressway | Videonett-node | Etter behov | Kortvarig (>=1024) | TCP eller TLS | Alle** | 5060 eller 5061 |
Overlapping | Videonett-node | Webex-sky | Etter behov | 34000 til 34999 | UDP, SRTP (alle)* | Alle** | 5004 50000 til 53000*** |
Overlapping | Videonett-node | Videonett-node | Etter behov | 34000 til 34999 | UDP, SRTP (alle)* | Alle** | 5004 |
| Port 5004 brukes for alle skymedier og lokale videonettnoder. Webex-appen fortsetter å koble til Video Mesh-noder over delte porter 5004. Disse portene brukes også av Webex-appen og Webex-registrerte endepunkter for STUN-tester til videonettnoder. Videonett-node til Videonett-node for overlappende enheter bruker målportområde på 10000–40000. * TCP støttes også, men foretrekkes ikke fordi det kan påvirke mediekvaliteten. |
** Hvis du vil begrense etter IP-adresser, kan du se IP-adresse som er dokumentert i Nettverkskrav for Webex-tjenester .
*** Expressway bruker allerede dette portområdet for Webex-skyen. Så de fleste distribusjoner krever ingen oppdateringer for å støtte dette nye kravet for Video Mesh. Men hvis distribusjonen har strengere brannmurregler, kan det hende du må oppdatere brannmurkonfigurasjonen for å åpne disse portene for videonett.
For å få den beste opplevelsen av å bruke Webex i organisasjonen din, konfigurer brannmuren til å tillate all utgående TCP- og UDP-trafikk som er bestemt til portene 5004, i tillegg til alle innkommende svar på denne trafikken. Portkravene som er oppført ovenfor, forutsetter at videonettnoder distribueres enten i lokalnettet (foretrukket) eller i en DMZ, og at Webex-appen er i lokalnettet.
Videokvalitet og skalering for videonett
Nedenfor finner du noen vanlige møtescenarier når en overlapping opprettes. Video Mesh er tilpasningsdyktig avhengig av tilgjengelig båndbredde og fordeler ressurser deretter. For enheter i møtet som bruker Video Mesh-noden, gir den overlappende koblingen fordelen med å redusere gjennomsnittlig båndbredde og forbedre møteopplevelsen for brukeren.
| For retningslinjer for båndbreddeklargjøring og kapasitetsplanlegging , se Dokumentasjon for foretrukket arkitektur . |
Basert på de aktive talerne i møtet, etableres overlappende koblinger. Hver overlapping kan inneholde opptil 6 strømmer, og overlappingen er begrenset til 6 deltakere (6 i retning av Webex-app/SIP til Webex-sky og 5 i motsatt retning). Hver medieressurs (sky og videonett) ber den eksterne siden om strømmene som er nødvendige for å oppfylle de lokale endepunktkravene til alle eksterne deltakere på tvers av overlappingen.
For å gi en fleksibel brukeropplevelse kan Webex-plattformen gjøre flerstrømsvideo til møtedeltakere. Den samme muligheten gjelder for overlappende kobling mellom Video Mesh-noder og skyen. I denne arkitekturen varierer båndbreddekravene avhengig av en rekke faktorer, for eksempel endepunktoppsettene.
Arkitektur
I denne arkitekturen sender Cisco Webex endepunkter signalisering til skyen og medier til svitsjetjenestene. Lokale SIP-endepunkter sender signalisering til samtalekontroll (Unified CM eller Expressway), som deretter sender den til videonett-noden. Medier sendes til transkodingstjenesten.
Deltakere i skyen og lokaler
Lokale lokale deltakere på Video Mesh-noden ber om de ønskede strømmene basert på oppsettkravene deres. Disse strømmene viderekobles fra Video Mesh-noden til endepunktet for lokal enhetsgjengivelse.
Hver sky- og videonettnode ber om HD- og SD-oppløsninger fra alle deltakere som er skyregistrerte enheter eller Webex-app. Avhengig av endepunktet vil den sende opptil 4 oppløsninger, vanligvis 1080p, 720p, 360p og 180p.
Kaskader
De fleste Cisco-endepunkter kan sende 3 eller 4 strømmer fra én kilde i en rekke oppløsninger (fra 1080p til 180p). Oppsettet til endepunktet dikterer kravet til strømmene som trengs på den andre enden av overlappingen. For aktiv tilstedeværelse er videostrøm 1080p eller 720p, og videorutene (PiPS) er 180p. For lik visning er oppløsningen i de fleste tilfeller 480p eller 360p for alle deltakerne. Kaskaden som opprettes mellom Video Mesh-noder og skyen, sender også 720p, 360p og 180p i begge retninger. Innhold sendes som én strømming, og lyd sendes som flere strømmer.
Overlappende båndbreddegrafer som gir måling per klynge, er tilgjengelige på Analytics-menyen i Webex Control Hub. Du kan ikke konfigurere overlappende båndbredde per møte i Control Hub.
| Maksimal forhandlet overlappende båndbredde per møte er 20 Mbps for hovedvideo for alle kilder og flere hovedvideostrømmer de kan sende. Denne maksimumsverdien inkluderer ikke innholdskanalen eller lyden. |
Eksempel på hovedvideo med flere oppsett
Diagrammene nedenfor viser et eksempel på et møtescenario og hvordan båndbredden påvirkes når flere faktorer spiller inn. I eksemplet overfører alle Webex-app og Webex-registrerte enheter1x 720p,1x 360p og1x 180p strømmer til Video Mesh. På kaskaden overføres strømmer på 720p, 360p og 180p i begge retninger. Årsaken er fordi det er Webex-app og Webex-registrerte enheter som mottar 720p, 360p og 180p på begge sider av overlappingen.
| I diagrammene er båndbreddetallene for overførte og mottatte data kun for eksempelformål. De er ikke en uttømmende dekning av alle mulige møter og tilhørende båndbreddekrav. Ulike møtescenarier (med deltakere, enhetsfunksjoner, innholdsdeling i møtet, aktivitet på et gitt tidspunkt i løpet av møtet) vil gi forskjellige båndbreddenivåer. |
Diagrammet nedenfor viser et møte med registrerte endepunkter i skyen og lokaler og en aktiv taler.
I det samme møtet viser diagrammet nedenfor et eksempel på en kaskade som er opprettet mellom videonettnodene og skyen i begge retninger.
I det samme møtet viser diagrammet nedenfor et eksempel på en kaskade fra skyen.
Diagrammet nedenfor viser et møte med de samme enhetene ovenfor, sammen med en Webex Meetings -klient. Systemet sender den aktiv taler og den siste aktiv taler i HD, sammen med en ekstra HD-strøm av den aktiv taler for Webex Meeting-klienter fordi videonettnoder ikke støtter Webex Meetings for øyeblikket.
Krav for Webex-tjenester
Samarbeid med partneren din, Customer Suksess Manager (CSM) eller prøveversjonsrepresentanten for å klargjøre Cisco Webex nettstedet og Webex-tjenester for videonett på riktig måte:
Du må ha en Webex-organisasjon med et betalt abonnement på Webex-tjenester.
Hvis du vil dra full nytte av Video Mesh, må du sørge for at Webex-nettsted ditt er på videoplattform versjon 2.0. (Du kan bekrefte at nettstedet ditt er på videoplattform versjon 2.0 hvis det har listen Medieressurstype tilgjengelig i nettstedsalternativene for møterom for skysamarbeid.)
Du må aktivere CMR for Webex-nettsted ditt under brukerprofiler. (Du kan gjøre dette i en CSV-fil for masseoppdatering med SupportCMR-attributtet).
Hvis du vil ha mer informasjon, se Funksjonssammenligning og overføringsbane fra samarbeidsmøterom-hybrid til videonett i vedlegget.
Kontroller at kildelandet er riktig
Videonett bruker de globalt distribuerte mediefunksjonene (GDM) i Webex for å oppnå bedre medieruting. For å oppnå optimal tilkobling velger Webex den nærmeste skymedienoden til bedriften når du utfører videonettoverlappinger til Webex. Trafikken går deretter gjennom Webex-ryggraden for å samhandle med Webex-mikrotjenestene for møtet. Denne rutingen minimerer ventetiden og holder mesteparten av trafikken på Webex-ryggraden og utenfor Internett.
For å støtte GDM bruker vi MaxMind som leverandør av GeoIP-plassering for denne prosessen. Kontroller at MaxMind identifiserer plasseringen av den offentlige IP-adresse på riktig måte for å sikre effektiv ruting.
| 1 | I en nettleser skriver du inn denne URL-adressen med den offentlige IP-adresse til Expresswayen eller endepunktet på slutten. Du mottar et svar som følgende: |
| 2 | Kontroller at |
| 3 | Hvis plasseringen er feil, sender du en forespørsel om å korrigere plasseringen av den offentlige IP-adresse din til MaxMind påhttps://support.maxmind.com/geoip-data-correction-request/correct-a-geoip-location . |
Fullfør forutsetningene for videonett
Bruk denne sjekklisten for å sikre at du er klar til å installere og konfigurere videonett-noder og integrere et Webex-nettsted med videonett.
| 1 | Sørg for at du:
| ||
| 2 | Arbeid med partneren din, kundesuksessansvarlig eller prøveversjonsrepresentanten for å forstå og klargjøre Webex-miljøet slik at det er klart til å koble til Video Mesh. Hvis du vil ha mer informasjon, se Krav for Webex-tjenester . | ||
| 3 | Ta opp følgende nettverksinformasjon som skal tilordnes til Video Mesh-nodene:
| ||
| 4 | Før du starter installasjonen, må du kontrollere at Webex-organisasjonen din er aktivert for videonett. Denne tjenesten er tilgjengelig for organisasjoner med bestemte betalte Webex-tjenesteabonnement som dokumentert i Lisenskrav for Cisco Webex . Kontakt din Cisco-partner eller kontoadministrator for å få hjelp. | ||
| 5 | Velg en støttet maskinvare eller spesifikasjonsbasert konfigurasjon for Video Mesh-noden, som beskrevet i System- og plattformkrav for programvare for videonettnode . | ||
| 6 | Kontroller at serveren din kjører VMware ESXi 7 eller 8, og vSphere 7 eller 8, med en VM-vert operativ. | ||
| 7 | Hvis du integrerer Video Mesh med Samtalekontrollmiljøet i Unified CM og du vil at deltakerlistene skal være konsekvente på tvers av møteplattformer, må du samtalekontroll at sikkerhetsmodusen for Unified CM-klynge er satt til blandet modus slik at den støtter TLS-kryptert trafikk. Ende-til-ende-kryptert trafikk er nødvendig for at denne funksjonaliteten skal fungere. Se kapitlet om TLS-oppsett i sikkerhetsveiledning for Cisco Unified Communications Manager hvis du vil ha mer informasjon om hvordan du bytter Unified CM -miljø til blandet modus. Se Veiledning for Active Control-løsninger hvis du vil ha mer informasjon om funksjonene og om hvordan du konfigurerer ende-til-ende-kryptering. | ||
| 8 | Hvis du integrerer en proxy (eksplisitt, gjennomsiktig inspeksjon eller gjennomsiktig ikke-inspeksjon) med Video Mesh, må du sørge for at du følger kravene som er dokumentert i Krav for proxy-støtte for videonett . |
Hva nå?
Oppgaveflyt for distribusjon av videonett
Før du starter
| 1 | Installer og konfigurer programvaren for videonettnode Bruk denne fremgangsmåten til å distribuere en videonettnode til vertsserveren som kjører VMware ESXi eller vCenter. Du installerer den lokale programvaren som oppretter en node, og deretter utfører du den første konfigurasjonen, for eksempel nettverksinnstillinger. Du registrerer den i skyen senere. |
| 2 |
Logg på konsollen for første gang. Programvaren for videonettnode har et standardpassord. Du må endre denne verdien før du konfigurerer noden. |
| 3 | Angi nettverkskonfigurasjon for videonettnode i konsollen Bruk denne fremgangsmåten til å konfigurere nettverksinnstillinger for videonettnode hvis du ikke konfigurerte dem da du konfigurerte noden på en virtuell maskin. Du angir en statisk IP-adresse og endrer FQDN/vertsnavn og NTP-servere. DHCP støttes for øyeblikket ikke. |
| 4 | Bruk disse trinnene for å konfigurere det eksterne grensesnittet for en distribusjon med to nettverksgrensesnitt (dual NIC):
Når noden er tilkoblet igjen og du har bekreftet den interne nettverkskonfigurasjon, kan du konfigurere det eksterne nettverksgrensesnitt hvis du distribuerer videonettnode i nettverkets DMZ, slik at du kan isolere bedriftstrafikken (internt) fra utsiden (eksternt). ) trafikk. Du kan også gjøre unntak eller overstyringer av standard rutingsregler. |
| 5 | Registrer videonettnode til Webex Cloud Bruk denne fremgangsmåten til å registrere videonett-noder til Webex-skyen og fullføre ytterligere konfigurasjon. Når du bruker Control Hub til å registrere noden, oppretter du en klynge som noden er tilordnet. En klynge inneholder én eller flere medienoder som betjener brukere i et bestemt geografisk område. Registreringstrinnene konfigurerer også innstillinger for SIP-samtale , angi en oppgraderingsplan og abonnere på e-postvarsler. |
| 6 | Aktiver og verif Quality of Service (QoS) med følgende oppgaver:
Aktiver QoS hvis du vil at Video Mesh-noder automatisk skal merke SIP-trafikk (lokale SIP-registrerte endepunkter) for både lyd (EF) og video (AF41) separat med passende tjenesteklasse og bruke kjente portområder for bestemte medietyper. Denne endringen lar deg opprette QoS-policyer og effektivt kommentere returtrafikk fra skyen hvis du ønsker det. Bruk trinnene i Reflector Tool for å kontrollere at de riktige portene er åpnet på brannmuren. |
| 7 | Konfigurer videonettnode for proxy-integrering Bruk denne fremgangsmåten til å angi hvilken type proxy du vil integrere med et videonett. Hvis du velger en gjennomsiktig inspeksjons-proxy, kan du bruke nodens grensesnitt til å laste opp og installere rotsertifikat, kontrollere proxyen og feilsøke potensielle problemer. |
| 8 | Følg Integrer videonett med oppgaveflyt for samtalekontroll og velg ett av følgende, avhengig av samtalekontroll, sikkerhetskrav og om du vil integrere Video Mesh med samtalekontroll :
SIP-enheter støtter ikke direkte tilgjengelighet, så du må bruke Unified CM eller VCS Expressway-konfigurasjon for å etablere et forhold mellom lokale registrerte SIP-enheter og videonettklynger. Du trenger bare å trunke Unified CM eller VCS Expressway til videonettnode, avhengig av samtalekontroll . |
| 9 | Utveksle sertifikatkjeder mellom Unified CM og videonettnoder I denne oppgaven laster du ned sertifikater fra Unified CM og Video Mesh-grensesnittene og laster opp det ene til det andre. Dette trinnet etablerer sikker tillit mellom de to produktene, og, sammen med den sikre trunkkonfigurasjonen, lar kryptert SIP-trafikk og SRTP-medier i organisasjonen din lande på Video Mesh-noder. |
| 10 | Aktiver mediekryptering for organisasjons- og videonettklynger Bruk denne fremgangsmåten til å aktivere mediekryptering for organisasjonen og individuelle videonett-klynger. Denne innstillingen tvinger ende-til-ende TLS-oppsett, og du må ha en sikker TLS SIP-trunk på plass på Unified CM som peker til Video Mesh-nodene. |
| 11 | Aktiver videonett for Webex-nettstedet Hvis du vil bruke optimalisert media til videonettnode for et Webex-møte til alle Webex-app og -enhetene som skal delta, må denne konfigurasjonen være aktivert for Webex-nettsted. Aktivering av denne innstillingen kobler Video Mesh- og møteforekomster i skyen sammen, og tillater at overlappinger oppstår fra Video Mesh-noder. Hvis denne innstillingen ikke er aktivert, vil ikke Webex-app og -enhetene bruke videonettnoden for Webex-møter. |
| 12 | |
| 13 | Kontroller møteopplevelsen på det sikre endepunktet Hvis du bruker mediekryptering gjennom ende-til-ende TLS-oppsettet, bruker du disse trinnene for å bekrefte at endepunktene er registrert på en sikker måte, og at riktig møteopplevelse vises. |
Skript for masseklargjøring for videonett
Hvis du trenger å distribuere mange noder i Video Mesh-distribusjonen, er prosessen tidkrevende. Du kan bruke skriptet påhttps://github.com/CiscoDevNet/webex-video-mesh-node-provisioning distribuere videonettnoder på VMWare ESXi-servere raskt. Les gjennom Viktig-filen for instruksjoner om hvordan du bruker skriptet.
Installer og konfigurer programvaren for videonettnode
Bruk denne fremgangsmåten til å distribuere en videonettnode til vertsserveren som kjører VMware ESXi eller vCenter. Du installerer den lokale programvaren som oppretter en node, og deretter utfører du den første konfigurasjonen, for eksempel nettverksinnstillinger. Du registrerer den i skyen senere.
Du må laste ned programvarepakken (OVA) fra Control Hub (https://admin.webex.com ), i stedet for å bruke en tidligere nedlastet versjon. Denne OVA-en er signert av Cisco-sertifikater og kan lastes ned etter at du har logget på Control Hub med administrator for kunde.
Før du starter
Se System- og plattformkrav for programvare for videonettnode for støttede maskinvareplattformer og spesifikasjonskrav for videonettnode.
Kontroller at du har disse obligatoriske elementene:
En datamaskin med:
VMware vSphere-klient 7 eller 8.
Du finner en liste over operativsystemer som støttes, i VMware-dokumentasjonen.
OVA-fil for Video Mesh-programvare lastet ned.
Last ned den nyeste Video Mesh-programvaren fra Control Hub, i stedet for å bruke en tidligere nedlastet versjon. Du kan også få tilgang til programvaren fra denne koblingen . (Filen er på omtrent 1,5 GB.)
Eldre versjoner av programvarepakken (OVA) vil ikke være kompatible med de nyeste Video Mesh-oppgraderingene. Dette kan føre til problemer under oppgradering av applikasjonen. Pass på at du laster ned den nyeste versjonen av OVA-filen fra denne koblingen .
En støttet server med VMware ESXi eller vCenter 7 eller 8 installert og kjører
Deaktiver sikkerhetskopiering av virtuell maskin og direkteoverføring. videonettnode -klynger er sanntidssystemer. eventuelle pauser i virtuell maskin kan gjøre disse systemene ustabile. (For vedlikeholdsaktiviteter på en videonettnode, bruk vedlikeholdsmodus fra Control Hub.)
| 1 | Åpne VMware vSphere-klienten ved hjelp av datamaskinen og logg på vCenter- eller ESXi-systemet på serveren. | ||||
| 2 | Gå til . | ||||
| 3 | På Velg en OVF-mal side, klikk Lokal fil , deretter Velg Filer . Naviger til der videomesh.ova filen er plassert, velger du filen og klikker på Neste .
| ||||
| 4 | På Velg et navn og en mappe side, skriver du inn en Navn på virtuell maskin for videonettnode (for eksempel «Video_ Mesh_ Node_ 1"), velg et sted der nodedistribusjonen for den virtuell maskin kan ligge, og klikk deretter Neste . Det kjøres en valideringskontroll. Når den er fullført, vises maldetaljene. | ||||
| 5 | Kontroller maldetaljene, og klikk deretter på Neste . | ||||
| 6 | På Konfigurasjon velger du type distribusjonskonfigurasjon, og klikker deretter Neste .
Alternativene er oppført i rekkefølgen etter økende ressurskrav.
| ||||
| 7 | På Velg lagring side, må du kontrollere at standard diskformat for Tykk provisjon Lazy nullstilt og retningslinjer for VM-lagring for Datalager som standard er valgt, og klikk deretter Neste . | ||||
| 8 | På Velg nettverk -siden, velger du nettverksalternativet fra listen over oppføringer for å gi ønsket tilkobling til den virtuelle maskinen.
For en DMZ-distribusjon kan du konfigurere Video Mesh-noden med det to nettverksgrensesnitt (NIC). Denne distribusjonen lar deg skille den interne nettverkstrafikken for bedriften (brukes til interbokskommunikasjon, overlapping mellom nodeklynger og for å få tilgang til nodens administrasjonsgrensesnitt) fra den eksterne skynettverkstrafikken (brukes for tilkobling til omverdenen og gjennomgripende til Webex). Alle nodene i en klynge må være i dobbel NIC-modus. en blanding av enkelt og to nettverkskort støttes ikke.
| ||||
| 9 | På Tilpass mal side, konfigurerer du følgende nettverksinnstillinger:
Hvis du foretrekker det, kan du hoppe over konfigurasjonen av nettverksinnstillinger og følge trinnene i Angi nettverkskonfigurasjon for videonettnode i konsollen etter at du logger på noden. | ||||
| 10 | På Klar til å fullføre på siden, kontroller at alle innstillingene du anga, samsvarer med retningslinjene i denne prosedyren, og klikk deretter på Fullfør . Når distribusjonen av OVA er fullført, vises videonettnode i listen over virtuelle datamaskiner. | ||||
| 11 | Høyreklikk på den videonettnode , og velg deretter . Programvaren for videonettnode installeres som gjest på VM-verten. Du er nå klar til å logge på konsollen og konfigurere videonettnode. Du kan oppleve en forsinkelse på noen minutter før nodebeholderne kommer opp. Det vises en brobrannmurmelding på konsollen ved første oppstart, der du ikke kan logge på. |
Hva nå?
Logg på videonettnode
Logg på konsollen for første gang. Programvaren for videonettnode har et standardpassord. Du må endre denne verdien før du konfigurerer noden.
| 1 | Fra VMware vSphere-klienten går du til den videonettnode , og deretter velger du Konsoll . Den videonettnode starter opp, og det vises en påloggingsmelding. Hvis påloggingsmeldingen ikke vises, trykker du på Gå inn . Du kan en kort stund se en melding som angir at systemet initialiseres. |
| 2 | Bruk følgende standard brukernavn og passord for å logge på: Fordi du logger på videonettnode for første gang, må du endre passordfrasen (passordet) for administrator . |
| 3 | For (gjeldende) passord skriver du inn standard passord (ovenfra), og deretter trykker du på Gå inn . |
| 4 | For nytt passord skriver du inn en ny passordfrase, og deretter trykker du på Gå inn . |
| 5 | Hvis du vil skrive inn nytt passord på nytt, skriver du inn den nye passordfrasen på nytt, og deretter trykker du på Gå inn . Meldingen «Passord ble endret» vises, og deretter vises det første skjermbildet for videonettnode med en melding om at uautorisert tilgang er forbudt. |
| 6 | Trykk på Gå inn for å laste hovedmeny. |
Hva nå?
Angi nettverkskonfigurasjon for videonettnode i konsollen
Bruk denne fremgangsmåten til å konfigurere nettverksinnstillinger for videonettnode hvis du ikke konfigurerte dem da du konfigurerte noden på en virtuell maskin. Du angir en statisk IP-adresse og endrer FQDN/vertsnavn og NTP-servere. DHCP støttes for øyeblikket ikke.
Disse trinnene er obligatoriske hvis du ikke konfigurerte nettverksinnstillinger på tidspunktet for OVA-distribusjon.
| Det indre grensesnittet (standardgrensesnittet for trafikk) brukes til CLI, SIP-trunker, SIP-trafikk og nodebehandling. Det eksterne (eksterne) grensesnittet er for HTTPS- og websockets-kommunikasjon til Webex, sammen med den overlappende trafikken fra nodene til Webex. |
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten, og logg deretter på med administratorlegitimasjonen. Etter førstegangs oppsett av nettverksinnstillinger , og hvis videonettverket er tilgjengelig, kan du få tilgang til nodegrensesnittet via sikkert skall (SSH). | ||
| 2 | Velg alternativ fra hovedmeny i videonettnode 2 Rediger konfigurasjon og klikk deretter Velg . | ||
| 3 | Les meldingen om at samtalene avsluttes på videonettnode, og klikk deretter på Ja . | ||
| 4 | Klikk på Statisk , angi IP-adresse for det interne grensesnittet, Maske , Gateway , og DNS verdier for nettverket ditt.
| ||
| 5 | Angi organisasjonens NTP-server eller en annen ekstern NTP-server som kan brukes i organisasjonen. Når du har konfigurert NTP-server og lagret nettverksinnstillinger, kan du følge trinnene i Kontroller tilstanden til videonettnode fra konsoll for å bekrefte at klokken synkroniseres riktig gjennom de angitte NTP-serverne.
| ||
| 6 | (Valgfritt) Endre vertsnavnet eller domenet om nødvendig.
| ||
| 7 | Klikk på Lagre , og klikk deretter Lagre endringer og start på nytt . Under lagringen utføres DNS-validering hvis du oppga et domene. Det vises en advarsel hvis FQDN (vertsnavn og domene) ikke kan løses ved hjelp av de oppgitte DNS-server . Du kan velge å lagre ved å ignorere advarselen, men anrop fungerer ikke før FQDN kan løses til DNS-en som er konfigurert på noden. Etter at videonettnode har startet på nytt, trer endringene i nettverkskonfigurasjon i kraft. |
Hva nå?
Når programvareavbildningen er installert og konfigurert med nettverksinnstillinger (IP-adresse, DNS, NTP og så videre) og tilgjengelig på bedriftsnettverket, kan du gå videre til neste trinn for sikker registrering av det til skyen. IP-adresse som er konfigurert på videonettnode , er bare tilgjengelig fra bedriftsnettverket. Fra et sikkerhetsperspektiv er noden skjerpet, slik at bare kundeadministratorer har tilgang til nodegrensesnittet for å utføre konfigurasjon.
Angi det eksterne nettverksgrensesnittet for videonettnode
Når noden er tilkoblet igjen og du har bekreftet den interne nettverkskonfigurasjon, kan du konfigurere det eksterne nettverksgrensesnitt hvis du distribuerer videonettnode i nettverkets DMZ, slik at du kan isolere bedriftstrafikken (internt) fra utsiden (eksternt). ) trafikk.
| 1 | Velg alternativ fra hovedmeny i videonettnode 5 Ekstern IP-konfigurasjon og klikk deretter Velg . | ||
| 2 | Klikk på 1 Aktiver/deaktiver , deretter Velg , og deretter Ja for å aktivere alternativene for ekstern IP-adresse på noden. | ||
| 3 | Som du gjorde med den første nettverkskonfigurasjon, skriver du inn IP-adresse (eksternt), Maske , og Gateway verdier.
| ||
| 4 | Klikk på Lagre og start på nytt . Noden starter på nytt for å aktivere den doble IP-adresse, og konfigurerer deretter automatisk de grunnleggende statiske rutingsreglene. Disse reglene bestemmer at trafikk til og fra en IP-adresse for privat klasse bruker et internt grensesnitt. trafikk til og fra en offentlig IP-adresse bruker et eksternt grensesnitt. Senere kan du opprette dine egne rutingsregler – for eksempel hvis du må konfigurere en overstyring og gi tilgang til et eksternt domene fra det interne grensesnittet.
| ||
| 5 | Hvis du vil bekrefte konfigurasjonen av den interne og eksterne IP-adresse , går du til konsollens hovedmeny 4 Diagnostikk , og velg deretter Ping . | ||
| 6 | I ping -feltet, angi en destinasjonsadresse du vil teste, for eksempel en ekstern destinasjon eller en intern IP-adresse, og klikk deretter på OK .
|
Hva nå?
API-er for videonettnode
API-er for videonettnode gjør det mulig for organisasjonsadministratorer å administrere passord, interne og eksterne nettverksinnstillinger, vedlikeholdsmodus og serversertifikater relatert til Video Mesh Node. Disse API-ene kan startes via et hvilket som helst API-verktøy som Postman, eller du kan opprette ditt eget skript for å kalle dem. Brukeren må ringe API-ene ved hjelp av riktig endepunkt (du kan bruke enten node-IP eller FQDN), metode, brødtekst, overskrifter, autorisasjon osv. for å utføre den ønskede handlingen og få et passende svar, i henhold til informasjonen nedenfor.
API-er for VMN-administrasjon
API vedlikeholdsmodus og passord for administratorkonto for videonettnodene.
Få status for vedlikeholdsmodus
Henter gjeldende status for vedlikeholdsmodus (Forventet status: på, av, venter eller forespurt).
[FÅ] https://<node_ip> /api/v1/external/maintenanceMode
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Success"
},
"result": {
"isRegistered": true,
"maintenanceMode": "pending/requested/on/off",
"maintenanceModeLastUpdated": 1691135731847
}
}Eksempelrespons 2:
{
"status": {
"code": 401,
"message": "login failed: incorrect password or username"
}
}Eksempelrespons 3:
{
"status": {
"code": 429,
"message": "Too Many Requests"
}
}Aktivere eller deaktivere vedlikeholdsmodus
Når du setter en Video Mesh-node i vedlikeholdsmodus, utfører den en elegant avslutning av anropstjenester (slutter å godta nye anrop og venter i opptil 2 timer på at eksisterende anrop fullføres).
[PUT] https://<node_ip> /api/v1/external/maintenanceMode
| Kall bare dette API-et når det ikke finnes noen aktive samtaler. |
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"maintenanceMode": "on"
}maintenanceMode – Status for vedlikeholdsmodus som skal angis – «på» eller «av».
Forespørselshoder:
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Your request to enable/disable maintenance mode was successful."
}
}Eksempelrespons 2:
{
"status": {
"code": 409,
"message": "Maintenance Mode is already on/off"
}
}Eksempelrespons 3 :
{
"status": {
"code": 400,
"message": "Bad Request - wrong input"
}
}Endre administratorpassord
Endrer passordet til administratorbrukeren.
[PUT] https://<node_ip> /api/v1/external/password
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"newPassword": "new"
}newPassword – Det nye passordet som skal angis for «admin»-kontoen til videonettnode.
Forespørselshoder:
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully set the new passphrase for user admin."
}
}Eksempelrespons 2:
{
"status": {
"code": 400,
"message": "Enter a new passphrase that wasn't used for one of the previous 3 passphrases."
}
}API-er for VMN-nettverk
Video Mesh Network API-er gjør det mulig for organisasjonsadministratorer å administrere interne og eksterne nettverksinnstillinger.
Hent konfigurasjon av eksternt nettverk
Oppdager om det eksterne nettverket er aktivert eller deaktivert. Hvis det eksterne nettverket er aktivert, henter det også den eksterne IP-adressen, den eksterne nettverksmaske og den eksterne gatewayen.
[FÅ] https://<node_ip> /api/v1/external/externalNetwork
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully fetched external network configuration."
},
"result": {
"ip": "1.1.1.1",
"mask": "2.2.2.2",
"gateway": "3.3.3.3"
}
}Eksempelrespons 2:
{
"status": {
"code": 200,
"message": "External network not enabled."
}
}Eksempelrespons 3:
{
"status": {
"code": 500,
"message": "Failed to get external network configuration."
}
}Rediger ekstern nettverkskonfigurasjon
Endrer innstillingene for eksternt nettverk. Denne API-en kan brukes til å aktivere det eksterne nettverket i tillegg til å angi eller redigere det eksterne nettverksgrensesnittet med ekstern IP-adresse, ekstern nettverksmaske og ekstern gateway. Den kan også brukes til å deaktivere det eksterne nettverket. Når du har gjort endringer i nettverkskonfigurasjon , startes noden på nytt for å ta i bruk disse endringene.
[PUT] https://<node_ip> /api/v1/external/externalNetwork
| Du kan bare konfigurere dette for nylig distribuerte videonettnoder, der standard administratorpassord er endret. Ikke bruk dette API-et etter at du har registrert noden for en organisasjon. |
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
Aktiverer eksternt nettverk:
{
"externalNetworkEnabled": true,
"externalIp": "1.1.1.1",
"externalMask": "2.2.2.2",
"externalGateway": "3.3.3.3"
}Deaktiverer eksternt nettverk:
{
"externalNetworkEnabled": false
}externalNetworkEnabled – Boolsk verdi (sann eller usann) for å aktivere/deaktivere eksternt nettverk
ekstern IP – den eksterne IP-en som skal legges til
externalMask – Nettverksmasken for det eksterne nettverket
externalGateway – Gatewayen for det eksterne nettverket
Forespørselshoder:
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully saved the external network configuration. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}Eksempelrespons 2:
{
"status": {
"code": 200,
"message": "Successfully disabled the external network. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}Eksempelrespons 3:
{
"status": {
"code": 400,
"message": "One or more errors in the input: Value should be boolean for 'externalNetworkEnabled'"
}
}Eksempelrespons 4:
{
"status": {
"code": 400,
"message": "External network configuration has not changed; skipping save of the external network configuration."
}
}Få detaljer om det interne nettverket
Henter konfigurasjonsdetaljene for det interne nettverkskonfigurasjon, som inkluderer nettverksmodus, IP-adresse, nettverksmaske, gateway, detaljer om DNS-bufring, DNS-servere, NTP-servere, MTU for internt grensesnitt, vertsnavn og domene.
[FÅ] https://<node_ip> /api/v1/external/internNettverk
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully fetched internal network details"
},
"result": {
"dhcp": false,
"ip": "1.1.1.1",
"mask": "2.2.2.2",
"gateway": "3.3.3.3",
"dnsCaching": false,
"dnsServers": [
"4.4.4.4",
"5.5.5.5"
],
"mtu": 1500,
"ntpServers": [
"6.6.6.6"
],
"hostName": "test-vmn",
"domain": ""
}
}Eksempelrespons 2:
{
"status": {
"code": 500,
"message": "Failed to get Network details."
}
}Eksempelrespons 3:
{
"status": {
"code": 500,
"message": "Failed to get host details."
}
}Rediger DNS-servere
Oppdaterer DNS-servere med nye.
[PUT] https://<node_ip> /api/v1/external/internNetwork/dns
| Sett noden i vedlikeholdsmodus før du gjør denne endringen. Se Aktivere eller deaktivere vedlikeholdsmodus hvis du vil ha mer informasjon om hvordan du flytter en node til vedlikeholdsmodus. |
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"dnsServers": "1.1.1.1 2.2.2.2"
}dnsServers – DNS-servere som skal oppdateres. Flere områdeseparerte DNS-servere er tillatt.
Forespørselshoder:
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully saved DNS servers"
}
}Eksempelrespons 2:
{
"status": {
"code": 409,
"message": "Requested DNS server(s) already exist."
}
}Eksempelrespons 3:
{
"status": {
"code": 424,
"message": "Maintenance Mode is not enabled. Kindly enable Maintenance Mode and try again for this node."
}
}Rediger NTP-servere
Oppdaterer NTP-servere med nye.
[PUT] https://<node_ip> /api/v1/external/internNetwork/ntp
| Sett noden i vedlikeholdsmodus før du gjør denne endringen. Se Aktivere eller deaktivere vedlikeholdsmodus hvis du vil ha mer informasjon om hvordan du flytter en node til vedlikeholdsmodus. |
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"ntpServers": "1.1.1.1 2.2.2.2"
}ntpServers – NTP-servere som skal oppdateres. Flere plassdelte NTP-servere er tillatt.
Forespørselshoder:
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully saved the NTP servers."
}
}Eksempelrespons 2:
{
"status": {
"code": 409,
"message": "Requested NTP server(s) already exist."
}
}Eksempelrespons 3:
{
"status": {
"code": 424,
"message": "Maintenance Mode is not enabled. Kindly enable Maintenance Mode and try again for this node."
}
}Rediger vertsnavn og domene
Oppdaterer vertsnavnet og domenet for videonettnode.
[PUT] https://<node_ip> /api/v1/external/interntNettverk/vert
| Sett noden i vedlikeholdsmodus før du gjør denne endringen. Noden starter på nytt for å bruke endringen. Se Aktivere eller deaktivere vedlikeholdsmodus hvis du vil ha mer informasjon om hvordan du flytter en node til vedlikeholdsmodus. |
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"hostName": "test-vmn",
"domain": "abc.com"
}vertsnavn – det nye vertsnavnet for noden.
domene – Det nye domenet for vertsnavnet til noden (valgfritt).
Forespørselshoder:
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully saved the host FQDN. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}Eksempelrespons 2:
{
"status": {
"code": 400,
"message": "Unable to resolve FQDN"
}
}Eksempelrespons 3:
{
"status": {
"code": 409,
"message": "Entered hostname and domain already set to same."
}
}Aktiver eller deaktiver DNS-bufring
Aktiverer eller deaktiverer DNS-bufring. Vurder å aktivere hurtigbufring hvis DNS-kontroller ofte tar over 750 ms å løse, eller hvis det er anbefalt av Cisco kundestøtte.
[PUT] https://<node_ip> /api/v1/external/internNetwork/dnsCaching
| Sett noden i vedlikeholdsmodus før du gjør denne endringen. Noden starter på nytt for å bruke endringen. Se Aktivere eller deaktivere vedlikeholdsmodus hvis du vil ha mer informasjon om hvordan du flytter en node til vedlikeholdsmodus. |
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"dnsCaching": true
}dnsCaching – konfigurasjon av DNS-bufring. Godtar boolsk verdi (sann eller usann).
Forespørselshoder:
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully saved DNS settings changes. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}Eksempelrespons 2:
{
"status": {
"code": 400,
"message": "One or more errors in the input: 'dnsCaching' field value should be a boolean"
}
}Eksempelrespons 3:
{
"status": {
"code": 409,
"message": "dnsCaching is already set to false"
}
}Rediger grensesnitt MTU
Endrer maksimal overføringsenhet (MTU) for nodens nettverksgrensesnitt fra standardverdi på 1500. Verdier mellom 1280 og 9000 er tillatt.
[PUT] https://<node_ip> /api/v1/external/internalNetwork/mtu
| Sett noden i vedlikeholdsmodus før du gjør denne endringen. Noden starter på nytt for å bruke endringen. Se Aktivere eller deaktivere vedlikeholdsmodus hvis du vil ha mer informasjon om hvordan du flytter en node til vedlikeholdsmodus. |
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"internalInterfaceMtu": 1500
}internalInterfaceMtu – maksimal overføringsenhet for nodens nettverksgrensesnitt. Verdien skal være mellom 1280 og 9000.
Forespørselshoder:
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully saved the internal interface MTU settings. This node will reboot soon to apply the changes. Please wait for a minute and relogin to the node to verify that all changes were applied."
}
}Eksempelrespons 2:
{
"status": {
"code": 400,
"message": "One or more errors in the input: 'internalInterfaceMtu' field value should be a number"
}
}Eksempelrespons 3:
{
"status": {
"code": 400,
"message": "Please enter a number between 1280 and 9000."
}
}VMN Server Certificate API-er
Video Mesh Server Certificate API-er gjør det mulig for organisasjonsadministratorer å opprette, oppdatere, laste ned og slette sertifikatene relatert til videonettnoder. Hvis du vil ha mer informasjon, se Utveksle sertifikatkjeder mellom Unified CM og videonettnoder .
Opprett CSR-sertifikatet
Genererer et CSR-sertifikat (Certificate Signing Request) og den private nøkkelen, basert på informasjonen som er oppgitt.
[POST] https://<node_ip> /api/v1/externalCertManager/generateCsr
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"csrInfo":
{
"commonName": "1.2.3.4",
"emailAddress": "abc@xyz.com",
"altNames": "1.1.1.1 2.2.2.2",
"organization": "VMN",
"organizationUnit": "IT",
"locality": "BLR",
"state": "KA",
"country": "IN",
"passphrase": "",
"keyBitSize": 2048
}
}commonName – IP/FQDN for videonettnode angitt som fellesnavn. (obligatorisk)
emailAddress – brukerens e-postadresse. (valgfritt)
altNames – Alternativt(e) emnenavn (valgfritt). Flere områdeseparerte FQDN-er er tillatt. Hvis det er oppgitt, må det inneholde det vanlige navnet. Hvis altNames ikke er oppgitt, tar det commonName som verdien av altNames.
organisasjon – Organisasjons-/Bedriftsnavn. (valgfritt)
organisationUnit – organisasjonsenhet eller avdelings- eller gruppenavn osv. (valgfritt)
sted – by/sted. (valgfritt)
delstat – delstat/provins. (valgfritt)
land – land/region. Forkortelse på to bokstaver. Ikke oppgi mer enn to bokstaver. (valgfritt)
passordfrase – Passfrase for privat nøkkel. (valgfritt)
keyBitSize – Privat nøkkelbitstørrelse. Godkjente verdier er 2048, som standard, eller 4096. (valgfritt)
Forespørselshoder :
Innholdstype: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully generated CSR"
},
"result": {
"caCert": {},
"caKey": {
"fileName": "VideoMeshGeneratedPrivate.key",
"localFileName": "CaPrivateKey.key",
"fileLastModified": "Fri Jul 21 2023 08:12:25 GMT+0000 (Coordinated Universal Time)",
"uploadDate": 1689927145422,
"size": 1678,
"type": "application/pkcs8",
"modulus": "S4MP1EM0DULU2"
},
"certInstallRequestPending": false,
"certInstallStarted": null,
"certInstallCompleted": null,
"isRegistered": true,
"caCertsInstalled": false,
"csr": {
"keyBitsize": 2048,
"commonName": "1.2.3.4",
"organization": "VMN",
"organizationUnit": "IT",
"locality": "BLR",
"state": "KA",
"country": "IN",
"emailAddress": "abc@xyz.com",
"altNames": [
"1.1.1.1",
"2.2.2.2"
],
"csrContent": "-----BEGIN CERTIFICATE REQUEST-----\nS4MP1E_C3RT_C0NT3NT\n-----END CERTIFICATE REQUEST-----"
},
"encryptedPassphrase": null
}
}Eksempelrespons 2:
{
"status": {
"code": 400,
"message": "Private key already exists. Delete it before generating new CSR."
}
}Eksempelrespons 3:
{
"status": {
"code": 400,
"message": "CSR certificate already exists. Delete it before generating new CSR."
}
}Eksempelrespons 4:
{
"status": {
"code": 400,
"message": "CSR certificate and private key already exist. Delete them before generating new CSR."
}
}Eksempelrespons 5:
{
"status": {
"code": 400,
"message": "There were one or more errors while generating the CSR: The \"Country\" field must contain exactly two A-Z characters."
}
}Last ned CSR-sertifikatet
Laster ned det genererte CSR-sertifikatet.
[FÅ] https://<node_ip> /api/v1/externalCertManager/csr
Du kan også laste ned filen via Send og last ned alternativet.
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
-----BEGIN CERTIFICATE REQUEST-----
S4MP1E_C3RT_C0NT3NT
-----END CERTIFICATE REQUEST-----Eksempelrespons 2:
{
"status": {
"code": 404,
"message": "Could not download, CSR certificate does not exist."
}
}Last ned den private nøkkelen
Laster ned den private nøkkelen som genereres sammen med CSR-sertifikatet.
[FÅ] https://<node_ip> /api/v1/externalCertManager/key
Du kan også laste ned filen via Send og last ned alternativet.
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
-----BEGIN RSA PRIVATE KEY-----
S4MP1E_PR1V4T3_K3Y
-----END RSA PRIVATE KEY-----Eksempelrespons 2:
{
"status": {
"code": 404,
"message": "Could not download, private key does not exist."
}
}Slett CSR-sertifikatet
Sletter det eksisterende CSR-sertifikatet.
[DELETE] https://<node_ip> /api/v1/externalCertManager/csr
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully deleted the CSR certificate"
}
}Eksempelrespons 2:
{
"status": {
"code": 404,
"message": "CSR certificate does not exist."
}
}Slett den private nøkkelen
Sletter den eksisterende private nøkkelen.
[DELETE] https://<node_ip> /api/v1/externalCertManager/key
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully deleted the private key"
}
}Eksempelrespons 2:
{
"status": {
"code": 404,
"message": "Private key does not exist."
}
}Installer det CA-signerte sertifikatet og den private nøkkelen
Laster opp det oppgitte CA-signerte sertifikatet og den private nøkkelen på videonettnoden og installerer sertifikatet på noden.
[POST] https://<node_ip> /api/v1/externalCertManager/uploadInstallCaCert
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
Bruk «form-data» for å laste opp følgende filer:
CA-signert sertifikatfil (.crt) med nøkkel som «crtFile».
Privat nøkkel (.key)-fil med nøkkel som 'keyFile'.
Forespørselshoder :
Innholdstype: «flerpart/skjema-data»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully installed certificate and key. It might take a few seconds to reflect on the node."
},
"result": {
"caCert": {
"fileName": "videoMeshCsr.crt",
"localFileName": "CaCert.crt",
"fileLastModified": 1689931788598,
"uploadDate": 1689931788605,
"size": 1549,
"type": "application/x-x509-ca-cert",
"certStats": {
"version": 0,
"subject": {
"countryName": "IN",
"stateOrProvinceName": "KA",
"localityName": "BLR",
"organizationName": "VMN",
"organizationalUnitName": "IT",
"emailAddress": "abc@xyz.com",
"commonName": "1.2.3.4"
},
"issuer": {
"countryName": "AU",
"stateOrProvinceName": "Some-State",
"organizationName": "ABC"
},
"serial": "3X4MPL3",
"notBefore": "2023-07-21T09:28:19.000Z",
"notAfter": "2024-12-02T09:28:19.000Z",
"signatureAlgorithm": "sha256WithRsaEncryption",
"fingerPrint": "11:22:33:44:AA:BB:CC:DD",
"publicKey": {
"algorithm": "rsaEncryption",
"e": 65537,
"n": "3X4MPL3",
"bitSize": 2048
},
"altNames": [],
"extensions": {}
}
},
"caKey": {
"fileName": "VideoMeshGeneratedPrivate.key",
"localFileName": "CaPrivateKey.key",
"fileLastModified": 1689931788629,
"uploadDate": 1689931788642,
"size": 1678,
"type": "application/pkcs8",
"modulus": "S4MP1EM0DULU2"
},
"certInstallRequestPending": true,
"certInstallStarted": null,
"certInstallCompleted": null,
"isRegistered": true,
"caCertsInstalled": false,
"csr": {
"keyBitsize": 2048,
"commonName": "1.2.3.4",
"organization": "VMN",
"organizationUnit": "IT",
"locality": "BLR",
"state": "KA",
"country": "IN",
"emailAddress": "abc@xyz.com",
"altNames": [
"1.1.1.1",
"2.2.2.2"
],
"csrContent": "-----BEGIN CERTIFICATE REQUEST-----\nS4MP1E_C3RT_C0NT3NT\n-----END CERTIFICATE REQUEST-----"
},
"encryptedPassphrase": null
}
}Eksempelrespons 2:
{
"status": {
"code": 400,
"message": "Could not parse the certificate file. Make sure it is a properly formatted certificate and try again."
}
}Eksempelrespons 3:
{
"status": {
"code": 400,
"message": "Private Key does not match Certificate (different modulus)"
}
}Eksempelrespons 4:
{
"status": {
"code": 202,
"message": "Certificate and private key PENDING installation. It might take a few seconds to reflect on the node. If the node is in maintenance mode, it will get installed once it is disabled."
}
}Last ned det CA-signerte sertifikatet
Laster ned det CA-signerte sertifikatet som er installert på noden.
[FÅ] https://<node_ip> /api/v1/externalCertManager/caCert
Du kan også laste ned filen via Send og last ned alternativet.
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
-----BEGIN CERTIFICATE-----
S4MP1E_C3RT_C0NT3NT
-----END CERTIFICATE-----Eksempelrespons 2:
{
"status": {
"code": 404,
"message": "Could not download, CA certificate does not exist."
}
}Slett det CA-signerte sertifikatet
Sletter det CA-signerte sertifikatet som er installert på noden.
[DELETE] https://<node_ip> /api/v1/externalCertManager/caCert
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully deleted the CA certificate."
}
}Eksempelrespons 2:
{
"status": {
"code": 404,
"message": "CA certificate does not exist."
}
}Felles API-svar
Nedenfor finner du noen eksempler på svar du kan støte på når du bruker en av API-ene nevnt ovenfor.
Eksempelrespons 1: Feil legitimasjon angitt i den grunnleggende autorisasjonen.
{
"status": {
"code": 401,
"message": "login failed: incorrect password or username"
}
}Eksempelrespons 2: VMN er ikke oppgradert til den obligatoriske versjonen som støtter disse API-ene.
{
"status": {
"code": 421,
"message": "Misdirected Request 1:[undefined]"
}
}Eksempelrespons 3: Feil referer angitt i toppteksten (når topptekst ikke var forventet).
{
"status": {
"code": 421,
"message": "Misdirected Request 2:[https://x.x.x.x/setup]"
}
}Eksempelrespons 4: Frekvensgrensen er overskredet. Prøv etter en stund.
{
"status": {
"code": 429,
"message": "Too Many Requests"
}
}Legg til interne og eksterne rutingsregler
I en distribusjon med to nettverksgrensesnitt (NIC) kan du finjustere rutingen for videonettnoder ved å legge til brukerdefinerte ruteregler for eksterne og interne grensesnitt. Standardrutene legges til nodene, men du kan gjøre unntak – for eksempel eksterne delnett eller vertsadresser som må få tilgang via det interne grensesnittet, eller interne delnett eller vertsadresser som må få tilgang fra det eksterne grensesnittet. Utfør følgende trinn etter behov.
| 1 | Fra grensesnittet for Video Mesh-noden velger du 5 Ekstern IP-konfigurasjon og klikk deretter Velg . | ||
| 2 | Velg 3 Behandle rutingsregler , og klikk deretter Velg . Første gang du åpner denne siden, vises standard systemrutingsregler i listen. Som standard går all intern trafikk gjennom det interne grensesnittet og ekstern trafikk gjennom det eksterne grensesnittet.
Du kan legge til manuelle overstyringer av disse reglene i de neste trinnene. | ||
| 3 | Følg disse trinnene etter behov:
Når du legger til hver regel, vises de i listen over rutingsregler, kategorisert som brukerdefinerte regler.
|
 | Egendefinerte rutingsregler kan skape potensial for konflikter med annen ruting. Du kan for eksempel definere en regel som fryser SSH-tilkoblingen til grensesnittet for videonettnode . Hvis dette skjer, gjør du ett av følgende, og deretter fjerner eller endrer du rutingsregelen:
|
Registrer videonettnode til Webex Cloud
Bruk denne fremgangsmåten til å registrere videonett-noder til Webex-skyen og fullføre ytterligere konfigurasjon. Når du bruker Control Hub til å registrere noden, oppretter du en klynge som noden er tilordnet. En klynge inneholder én eller flere medienoder som betjener brukere i et bestemt geografisk område. Registreringstrinnene konfigurerer også innstillinger for SIP-samtale , angi en oppgraderingsplan og abonnere på e-postvarsler.
Før du starter
Når du starter registreringen av en node, må du fullføre den innen 60 minutter, ellers må du starte på nytt.
Kontroller at eventuelle popup-blokkeringer i nettleseren din er deaktivert eller at du tillater et unntak forhttps://admin.webex.com .
For best resultat kan du distribuere alle nodene i en klynge i det samme datasenter. Se Klynger i videonett for hvordan de fungerer og beste praksis.
Fra verten eller maskinen der du registrerer videonettnoder til skyen, må du ha tilkobling til Webex-skyen og IP-adressene for videonettverket som registreres (i et dobbelt NIC-miljø, nærmere bestemt de interne IP-adressene til videoen Nettnoder).
| 1 | Logg på Kontrollhub . Du logger på Control Hub ved hjelp av administratorlegitimasjonen. Control Hub-administratorfunksjonaliteten er bare tilgjengelig for brukere som er definert som administratorer i Control Hub. Se Kundekontoroller hvis du vil ha mer informasjon. | ||
| 2 | Gå til og velg én:
| ||
| 3 | Kontroller at du har installert og konfigurert videonettnode. Klikk på Ja, jeg er klar til å registrere meg... , og klikk deretter Neste . | ||
| 4 | I Opprett en ny eller velg en klynge , velg én:
| ||
| 5 | I Angi FQDN- eller IP-adresse , angi det fullt kvalifisert domenenavn (FQDN) eller den interne IP-adresse til videonettnode , og klikk deretter på Neste .
Et FQDN må løses direkte til IP-adresse , ellers er det ikke brukbart. Vi utfører valideringen på FQDN for å utelukke skrivefeil eller konfigurasjonsfeil.
| ||
| 6 | Under Oppgraderingsplan , velg tid, frekvens og tidssone. Standarden er en daglig oppgraderingsplan. Du kan endre den til en ukentlig tidsplan på en bestemt dag. Når en oppgradering er tilgjengelig, oppgraderes programvaren for videonettnode automatisk i løpet av den tiden du velger.
| ||
| 7 | Under E-postvarsler , legg til administrator -e-postadresser for å abonnere på varsler om tjenestealarmer og programvareoppgraderinger. administrator e-postadresse din legges til automatisk. Du kan fjerne den hvis du vil. | ||
| 8 | Veksle på Videokvalitet innstillingen på for å aktivere 1080p 30 bilder per sekund. Med denne innstillingen kan SIP-deltakere som blir med i et møte som er vert i en videonettnode , bruke 1080p 30 bilder per sekund hvis alle er innenfor bedriftsnettverk og bruker en HD-kompatibel enhet. Innstillingen gjelder for alle klynger med noder.
| ||
| 9 | Les informasjonen under Fullfør registreringen , og klikk deretter Gå til Node for å registrere noden til Webex-skyen. En ny nettleserfane åpnes for å kontrollere noden. Dette trinnet sikrer videonettnode ved hjelp av IP-adresse til noden. Under registreringsprosessen omdirigerer Control Hub deg til videonettnode. IP-adresse må være på en sikker liste, ellers mislykkes registreringen. Registreringsprosessen må fullføres fra bedriftsnettverket der noden er installert. | ||
| 10 | Sjekk Gi tilgang til noden for Webex- videonettnode , og klikk deretter Fortsett . | ||
| 11 | Klikk på Tillat . Kontoen din er validert, videonettnode er registrert og meldingen Registrering fullført vises, noe som indikerer at videonettnode nå er registrert i Webex. videonettnode henter maskinlegitimasjon basert på organisasjonens rettigheter. Den genererte maskinlegitimasjonen utløper regelmessig og oppdateres. | ||
| 12 | Klikk på portalkoblingen eller lukk fanen for å gå tilbake til siden Videonett. På siden Videonett ser du nå den nye klyngen som inneholder videonettnode for videonett som du registrerte.
På dette tidspunktet er videonettnode klar til å kommunisere med Cisco-skytjenester over de sikrede kanalene ved hjelp av et token som er utstedt for autentisering. videonettnode kommuniserer også med Docker Hub (docker.com, docker.io). Docker brukes av Video Mesh-noden til å lagre beholdere for distribusjon til forskjellige Video Mesh-noder over hele verden. Bare Cisco har legitimasjon til å skrive til Docker Hub. Videonettnodene kan nå Docker Hub ved hjelp av skrivebeskyttet legitimasjon for å laste ned beholderne for oppgraderinger.
|
Ting du bør huske på
Husk følgende informasjon om videonettnode og hvordan den fungerer når den er registrert i Webex-organisasjonen din:
Når du distribuerer en ny videonettnode, vil ikke Webex-appen og den Webex-registrerte enheten gjenkjenne den nye noden på opptil to timer. Klientene sjekker om klyngen er tilgjengelig under oppstart, nettverksendring eller hurtigbufferutløp. Du kan vente i to timer eller, som en løsning, starte Webex-appen på nytt eller starte Webex-rommet eller -skrivebordet på nytt. Deretter registreres samtaleaktivitet i videonettrapportene i Control Hub.
En videonettnode registreres til én Webex-organisasjon. det er ikke en enhet med flere tenantgrupper.
Hvis du vil vite hva som bruker videonettnode og hva som ikke gjør det, kan du se tabellen i Klienter og enheter som bruker videonettnode .
videonettnode kan koble til Webex-nettsted ditt eller til en annen kundes eller partners Webex-nettsted. Nettsted A distribuerte for eksempel en videonettnode klynge og registrerte den med domenet example1.webex.com. Hvis brukere i nettsted A ringer inn til mymeeting@example1.webex.com, bruker de videonettnode , og det kan opprettes en gjennomgripende overgang. Hvis brukerne i nettsted A ringer dittmøte@example2.webex.com, vil brukerne av nettsted A bruke sin lokale videonettnode og koble til møtet i nettsted Bs Webex-organisasjon.
Hva nå?
Hvis du vil registrere flere noder, gjentar du disse trinnene.
Hvis en oppgradering er tilgjengelig, anbefaler vi at du tar den i bruk så snart som mulig. Fullfør følgende trinn for å oppgradere:
Klargjøringsdataene sendes til Webex-skyen av Ciscos utviklingsteam over sikre kanaler. Klargjøringsdataene er signert. For beholderne inneholder klargjøringsdataene navn, kontrollsum, versjon og så videre. videonettnode henter også klargjøringsdataene fra Webex-skyen over sikre kanaler.
Når videonettnode får klargjøringsdataene sine, autentiseres noden med skrivebeskyttet legitimasjon og laster ned beholderen med bestemt sjekksum og navn, og oppgraderer systemet. Hver beholder som kjører på videonettnode , har et bildenavn og en kontrollsum. Disse attributtene lastes opp til Webex-skyen ved hjelp av sikre kanaler.
Aktiver Quality of Service (QoS) for videonettnode
Før du starter
Gjør de nødvendige endringene i brannmurporten som er dekket i diagrammet og tabellen. Se Porter og protokoller som brukes av videonett .
For at Video Mesh-noder skal aktiveres for QoS, må nodene være tilkoblet. Noder i vedlikeholdsmodus eller frakoblet tilstander ekskluderes når du aktiverer denne innstillingen.
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til , klikk Rediger innstillinger på Video Mesh-kortet. | ||
| 2 | Bla til Tjenestekvalitet og klikk Aktiver . Når den er aktivert, får du det store, diskrete portområdet (bestemt av lokal konfigurasjon for samtalekontroll ) som brukes til lyd og video for lokale SIP-klienter/endepunkter og intraklyngekaskader med unike DSCP-merkinger:.
All SIP- og overlappende trafikk fra Video Mesh-noder er merket med EF for lyd og AF41 for video. De diskrete portområdene brukes som kildeporter for overlappende medier til andre Video Mesh-noder og skymedienoder, samt kilde- og målporter for SIP-klientmedier. Webex Teams-apper og overlappende medier fortsetter å bruke den delte målporten på 5004 og port ramge 50000–53000.
Det vises en statusmelding som viser hvilke noder som aktiveres, én etter én for QoS-portområdet. Du kan klikke gjennomgå ventende noder for å se en liste over noder som venter på QoS. Det kan ta opptil to timer å aktivere denne innstillingen, avhengig av samtaletrafikken på nodene. | ||
| 3 | Hvis QoS ikke er fullstendig aktivert om to timer, åpne en sak med støtte for videre etterforskning. Nodene starter på nytt og oppdateres med det nye portområdet. |
Hvis du bestemmer deg for å deaktivere innstillingen, får du det lille, konsoliderte portområdet som brukes for både lyd og video (34000–34999). All trafikk fra Video Mesh-noder (SIP, overlappende, skytrafikk og så videre) får én enkelt merking av AF41.
Kontroller portområder for videonettnode med reflektorverktøy i nettgrensesnittet
Reflektorverktøyet (en kombinasjon av en server på Video Mesh-noden og klient gjennom et Python-skript) brukes til å bekrefte om de nødvendige TCP/UDP-portene er åpne fra Video Mesh-nodene.
Før du starter
Last ned en kopi av Reflector Tool Client (et Python-skript) frahttps://github.com/CiscoDevNet/webex-video-mesh-reflector-client .
For at skriptet skal fungere som det skal, må du kontrollere at du kjører Python 2.7.10 eller nyere i miljøet ditt.
For øyeblikket støtter dette verktøyet SIP-endepunkter til videonettnoder og intraklyngebekreftelse.
| 1 | Fra kundevisningen ihttps://admin.webex.com , aktiver vedlikeholdsnoden for videonettnode ved å følge disse instruksjonene . |
| 2 | Vent til noden viser statusen Klar for vedlikehold i Control Hub. |
| 3 | Åpne nodegrensesnittet for Webex-videonett. Hvis du vil ha instruksjoner, se Behandle videonettnode fra nettgrensesnittet . |
| 4 | Bla til Refleksverktøy , og start deretter enten TCP Reflector Server eller UDP Reflector Server , avhengig av hvilken protokoll du vil bruke. |
| 5 | Klikk på Start Reflector Server , og vent deretter til serveren starter. Du ser et varsel når serveren starter. |
| 6 | Fra et system (for eksempel en PC) i et nettverk som du vil at Video Mesh-nodene skal nå, kjører du skriptet med følgende kommando:
På slutten av kjøringen viser klienten en vellykket melding hvis alle nødvendige porter er åpne:
Klienten viser en mislykket melding hvis noen nødvendige porter ikke er åpne:
|
| 7 | Løs eventuelle portproblemer på brannmuren, og kjør deretter trinnene ovenfor på nytt. |
| 8 | Kjør klienten med
|
Konfigurer videonettnode for proxy-integrering
Bruk denne fremgangsmåten til å angi hvilken type proxy du vil integrere med et videonett. Hvis du velger en gjennomsiktig inspeksjons-proxy eller en eksplisitt proxy, kan du bruke nodens grensesnitt til å laste opp og installere rotsertifikatet, kontrollere proxy-tilkoblingen og feilsøke potensielle problemer.
Før du starter
Se Proxy-støtte for videonett for en oversikt over proxy-alternativene som støttes.
| 1 | Angi nettadressen for oppsett av videonett | ||||||||||
| 2 | Gå til Klareringslager og proxy, og velg deretter et alternativ:
Følg de neste trinnene for en gjennomsiktig inspeksjons-proxy eller eksplisitt proxy. | ||||||||||
| 3 | Klikk på Last opp et rotsertifikat eller sluttenhetssertifikat, og deretter finn og velg rotsertifikatet for den eksplisitte eller gjennomsiktige inspeksjons-proxyen. Sertifikatet er lastet opp, men er ennå ikke installert fordi noden må startes på nytt for å installere sertifikatet. Klikk på pilen ved navnet på sertifikatutstederen for å få flere detaljer, eller klikk på Slett hvis du har gjort en feil og vil laste opp filen på nytt. | ||||||||||
| 4 | Hvis du vil ha gjennomsiktige inspeksjons-proxyer eller eksplisitte proxyer, klikker du på Kontroller proxy-tilkobling for å teste nettverkstilkoblingen mellom videonettnoden og proxyen. Hvis tilkoblingstesten mislykkes, ser du en feilmelding som viser årsaken og hvordan du kan løse problemet. | ||||||||||
| 5 | Når tilkoblingstesten er bestått, for eksplisitt proxy, slår du bryteren på til Rut alle https-forespørsler fra port 443 fra denne noden gjennom den eksplisitte proxyen . Denne innstillingen trer i kraft etter 15 sekunder. | ||||||||||
| 6 | Klikk på Installer alle sertifikater i klareringslageret (vises hver gang et rotsertifikat ble lagt til under proxy-installasjonen) eller Start på nytt (vises hvis det ikke ble lagt til noe rotsertifikat), les ledeteksten, og klikk deretter på Installer hvis du er klar. Noden starter på nytt i løpet av noen få minutter. | ||||||||||
| 7 | Når noden har startet på nytt, logger du på igjen om nødvendig, og deretter åpner du Oversikt-siden for å kontrollere tilkoblingskontrollene for å sikre at alle har grønn status. Proxy-tilkoblingskontrollen tester bare et underdomene av webex.com. Hvis det oppstår tilkoblingsproblemer, er et vanlig problem at noen av skydomenene som er oppført i installasjonsinstruksjonene, blokkeres ved proxyen. |
Integrer videonett med oppgaveflyt for samtalekontroll
Konfigurere SIP-trunker til å rute SIP-oppringing for Webex-møter på videonett. SIP-enheter støtter ikke direkte tilgjengelighet, så du må bruke Unified CM eller VCS Expressway-konfigurasjon for å etablere et forhold mellom lokale SIP-enheter og Video Mesh-klynger.
Før du starter
Se Distribusjonsmodeller for Video Mesh og Cisco Unified Communications Manager for å forstå vanlige eksempler på distribusjon.
Video Mesh støtter enten TCP eller TLS mellom Unified CM og SIP-signalisering. SIP TLS støttes ikke for VCS Expressway.
I Unified CM kan hver SIP-trunk støtte opptil 16 videonettdestinasjoner (IP-adresser).
I Unified CM kan innkommende porter på SIP-trunk - sikkerhetsprofil være standard (Non Secure SIP-trunkprofil).
Videonett støtter to rutemønstre: nettstedsnavn.webex.com og meet.ciscospark.com . Andre rutemønstre støttes ikke.
Videonett støtter 3 rutemønstre: webex.com (for korte videoadresser ), nettstedsnavn.webex.com og meet.ciscospark.com . Andre rutemønstre støttes ikke.
Når du bruker formatet for kort videoadresse ( møte@webex.com ), behandler videonett-noden alltid anropet. Noden håndterer anropet selv om anropet er til et nettsted som ikke har videonett aktivert.
Velg ett av disse alternativene, avhengig av samtalekontroll og sikkerhetskravene:
|
Konfigurer Unified CM Secure TLS SIP-trafikkruting for videonett
| 1 | Opprett en SIP-profil for videonettklynger: | ||
| 2 | Legg til en ny SIP-trunk - sikkerhetsprofil for videonettklynger: | ||
| 3 | Legg til en ny SIP-trunk for å peke til videonettklyngene dine:
| ||
| 4 | Opprett en SIP-trunk som peker til en Expressway for Webex-skyfailover.
| ||
| 5 | Opprett en ny rutegruppe for anrop til videonettklynger: | ||
| 6 | For overflyt til skyen oppretter du en ny rutegruppe for anrop til Expressway: | ||
| 7 | Opprett en ny ruteliste for anrop til videonettklynger og Expressway: | ||
| 8 | Opprett et SIP-rutemønster for kort videoadresse oppringingsformat for Webex-møter: Med funksjonen for oppringing av korte videoadresser trenger ikke brukere lenger å huske navnet på Webex-nettsted for å bli med i et Webex-møte eller -hendelse ved hjelp av et videosystem. De kan bli med på møtet raskere fordi de bare trenger å vite møte- eller hendelsesnummeret. | ||
| 9 | Opprett et SIP-rutemønster for Webex-nettsted: | ||
| 10 | Opprett et SIP-rutemønster for Webex-appmøter (bakoverkompatibilitet): |
Konfigurer Unified CM TCP SIP-trafikkruting for videonett
| 1 | Opprett en SIP-profil for videonettklynger: | ||
| 2 | Legg til en ny SIP-trunk - sikkerhetsprofil for videonettklynger: | ||
| 3 | Legg til en ny SIP-trunk for å peke til videonettklyngene dine:
| ||
| 4 | Opprett en ny SIP-trunk for å peke til en Expressway.
| ||
| 5 | Opprett en ny rutegruppe for anrop til videonettklynger: | ||
| 6 | For overflyt til skyen oppretter du en ny rutegruppe for anrop til Expressway: | ||
| 7 | Opprett en ny ruteliste for anrop til videonettklynger og Expressway: | ||
| 8 | Opprett et SIP-rutemønster for kort videoadresse oppringingsformat for Webex-møter: Med funksjonen for oppringing av korte videoadresser trenger ikke brukere lenger å huske navnet på Webex-nettsted for å bli med i et Webex-møte eller -hendelse ved hjelp av et videosystem. De kan bli med på møtet raskere fordi de bare trenger å vite møte- eller hendelsesnummeret. | ||
| 9 | Opprett et SIP-rutemønster for Webex-nettsted: | ||
| 10 | Opprett et SIP-rutemønster for Webex-appmøter: |
Konfigurer Expressway TCP SIP-trafikkruting for videonett
| 1 | Opprett en sone som peker til videonettklynger: | ||||||||||||||||||||||
| 2 | Opprett oppringingsmønstre for videonettklynger for Webex-nettsteder:
| ||||||||||||||||||||||
| 3 | Opprett et traverseringsklient og sonepar som peker til skyen Expressway for failover: | ||||||||||||||||||||||
| 4 | Opprett en reservesøkeregel til Traversal-klientsonen som fører til Expressway-E: | ||||||||||||||||||||||
| 5 | Fra Expressway-E, gå til . Klikk på Nyhet og legg til Webex Zone. I versjoner før X8.11 opprettet du en ny DNS-sone for dette formålet. | ||||||||||||||||||||||
| 6 | Opprett et oppringingsmønster for Expressway-skyen: | ||||||||||||||||||||||
| 7 | For SIP-enheter som er registrert på Expressway-C, åpner du enhetens IP-adresse i en nettleser, går du til Oppsett , bla til SIP , og velg Standarder fra Skriv inn rullegardinmenyen. |
Utveksle sertifikatkjeder mellom Unified CM og videonettnoder
Fullfør en sertifikatutveksling for å etablere toveis klarering mellom Unified CM og Video Mesh-grensesnittene. Med den sikre trunkkonfigurasjonen tillater sertifikatene kryptert SIP-trafikk og SRTP-medier i organisasjonen fra klarerte Unified CM-er å lande på klarerte videonettnoder.
| I et klyngemiljø må du installere CA- og serversertifikater på hver node individuelt. |
Før du starter
Av sikkerhetshensyn anbefaler vi at du bruker et CA-signert sertifikat på Video Mesh-nodene i stedet for nodens standard selvsignert sertifikat.
| 1 | Åpne nodegrensesnittet for Videonett (IP-adresse/oppsett, for eksempel, | ||||
| 2 | Gå til Serversertifikater og be om og last opp et sertifikat og nøkkelpar etter behov:
| ||||
| 3 | I en annen nettleserfane, fra Cisco Unified OS-administrasjon, går du til . Skriv inn søkekriterier og klikk Finn , velg filnavnet for sertifikatet eller klareringslisten for sertifikater (CTL), og klikk på Last ned . Lagre Unified CM -filen et sted som er lett å huske, og la Unified CM -forekomsten være åpen i nettleserfanen. | ||||
| 4 | Gå tilbake til kategorien Grensesnitt for videonettnode, klikk på Trust Store og proxy , og velg deretter et alternativ:
En skyregistrert Video Mesh-node avsluttes elegant og venter i opptil to timer på at eventuelle samtaler avsluttes. Noden startes automatisk på nytt for å installere CallManager.pem-sertifikatet. Når den kobles til igjen, vises en melding når CallManager.pem-sertifikatet installeres på videonett-noden. Du kan deretter laste inn siden på nytt for å vise det nye sertifikatet. | ||||
| 5 | Gå tilbake til Cisco Unified OS-administrasjon -fanen, og klikk på Last opp sertifikat/sertifikatkjede . Velg sertifikatnavn fra Sertifikat Formål rullegardinliste, bla til filen du lastet ned fra nodegrensesnittet for videonett, og klikk deretter på Åpne . | ||||
| 6 | Hvis du vil laste opp filen til serveren, klikker du på Last opp fil . Hvis du laster opp en sertifikatkjede, må du laste opp alle sertifikatene i kjeden.
|
Aktiver mediekryptering for organisasjons- og videonettklynger
Bruk denne fremgangsmåten til å aktivere mediekryptering for organisasjonen og individuelle videonett-klynger. Denne innstillingen fremtvinger et ende-til-ende TLS-oppsett, og du må ha en sikker TLS SIP-trunk på plass på Unified CM som peker til Video Mesh-nodene.
Innstillinger | Resultat |
|---|---|
Unified CM er konfigurert med en sikker trunk, og denne innstillingen for Video Mesh Control Hub er ikke aktivert. | Samtaler mislykkes. |
Unified CM er ikke konfigurert med en sikker trunk, og denne innstillingen for Video Mesh Control Hub er aktivert. | Samtaler mislykkes ikke, men de faller tilbake til usikker sikker modus. |
| Cisco-endepunkter må også konfigureres med en sikkerhetsprofil og TLS-forhandling for at ende-til-ende-kryptering skal fungere. Ellers flyter samtaler over til skyen fra endepunkter som ikke er konfigurert med TLS. Vi anbefaler at du bare aktiverer denne funksjonen hvis alle endepunkter kan konfigureres til å bruke TLS. |
Før du starter
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til , og klikk deretter Innstillinger på Video Mesh-kortet. |
| 2 | Bla til Mediekryptering og slå på innstillingen. Denne innstillingen gjør kryptering obligatorisk på alle mediekanaler som går gjennom videonettnoder i organisasjonen. Legg merke til den foregående tabellen og forsiktighetsmerknaden for situasjoner der anrop kan mislykkes, og hva som kreves for at ende-til-ende-kryptering skal fungere. |
| 3 | Klikk på Vis alle og gjenta følgende trinn for hver Video Mesh-klynge du vil aktivere for sikker SIP-trafikk. |
Aktiver videonett for Webex-nettstedet
Hvis du vil bruke optimalisert media til videonettnode for et Webex-møte til alle Webex-app og -enhetene som skal delta, må denne konfigurasjonen være aktivert for Webex-nettsted. Aktivering av denne innstillingen kobler Video Mesh- og møteforekomster i skyen sammen, og tillater at overlappinger oppstår fra Video Mesh-noder. Hvis denne innstillingen ikke er aktivert, vil ikke Webex-app og -enhetene bruke videonettnoden for Webex-møter.
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til klikker du på Webex-nettsted fra Møter-kortet, og deretter klikker du Innstillinger |
| 2 | Tilgang Fellesinnstillinger ved å klikke på Tjeneste > Møte > Nettstedsinnstillinger . Fra Fellesinnstillinger , klikk Møterom for skysamarbeid (CMR) , velg Videonett for Medieressurstype , og klikk deretter Lagre nederst.
Denne innstillingen kobler Video Mesh- og møteforekomster i skyen sammen, og tillater at overlappinger oppstår fra Video Mesh-noder. Innstillingen skal fylles ut i miljøet ditt etter 15 minutter. Webex-møter som starter etter at denne endringen er fylt ut, henter den nye innstillingen. Hvis du lar dette feltet være angitt til Sky ( standardvalg), vert alle møtene i skyen, og noden for videonett brukes ikke. |
Tilordne møterom for samarbeid til brukere av Webex-appen
Kontroller møteopplevelsen på det sikre endepunktet
Bruk denne fremgangsmåten til å kontrollere at endepunktene er registrert på en sikker måte, og at riktig møteopplevelse vises.
| 1 | Bli med i et møte fra det sikrede endepunktet. |
| 2 | Kontroller at møtelisten vises på enheten. Dette eksemplet viser hvordan møtelisten ser ut på et endepunkt med et berøringspanel:
|
| 3 | Under møtet får du tilgang til Webex-konferanseinformasjonen fra Samtaledetaljer. |
| 4 | Kontroller at krypteringsdelen viser Type som AES-128, og Status som På.
|
Videonettanalyse
Analyse gir informasjon om hvordan du bruker de lokale videonettnodene og -klyngene i Webex-organisasjonen din. Med de historiske data i målevisningen kan du administrere videonettressursene dine mer effektivt ved å overvåke kapasiteten, bruken og tilgjengeligheten til de lokale ressursene dine. Du kan for eksempel bruke denne informasjonen til å ta beslutninger om å legge til flere videonettnoder i en klynge eller opprette nye klynger. Videonettanalyse finner du i Control Hub under .
For å hjelpe deg med å analysere dataene i organisasjonen kan du zoome inn på data som vises i grafen, og isolere en bestemt tidsperiode. For Analytics kan du også dele opp og terningsrapporter for å vise mer detaljerte detaljer.
| Videonettanalyse- og feilsøkingsrapporter viser data i tidssone som er angitt for den lokale nettleseren. |
Analyser
Videonettanalyse gir en langsiktig trend (opptil 3 måneder med data) i kategoriene engasjement, ressursbruk og båndbreddebruk.
sanntidsovervåking
Fanen for direkteovervåking gir deg en oversikt over aktiviteten i organisasjonen din i nesten sanntid: opptil 1 minutt aggregering og muligheten til å vise de siste 4 timene eller 24 timene på alle klynger eller bestemte klynger. Denne fanen i Control Hub oppdateres automatisk – hvert 1. minutt de siste 4 timene og hvert 10. minutt de siste 24 timene.
Få tilgang til, filtrer og lagre sanntidsovervåking for Video Mesh
Rapporter for liveovervåking av Video Mesh er tilgjengelige på feilsøkingssiden i Control Hub (https://admin.webex.com ), når Video Mesh er aktiv og har en klynge med minst én registrert Video Mesh-node.
| 1 | Fra kundevisningen ihttps://admin.webex.com , velg Analyse , og klikk deretter Videonett øverst til høyre på skjermen.
| ||||
| 2 | Fra bryteren til venstre velger du et alternativ for å filtrere etter hvor langt tilbake i tid du vil vise data.
| ||||
| 3 | Samhandle med diagrammene ved å bruke følgende alternativer etter behov:
| ||||
| 4 | Når du har filtrert dataene i rapportene, klikker du på mer
|
for å få en kort beskrivelse av diagrammet.
Få tilgang til, filtrer og lagre analyse av videonett
Beregningsrapporter for videonett er tilgjengelige på Analytics-siden i Control Hub (https://admin.webex.com ), når Video Mesh er aktiv og har en klynge med minst én registrert Video Mesh-node.
| 1 | Fra kundevisningen ihttps://admin.webex.com , velg Analyse , og klikk deretter Videonett øverst til høyre på skjermen. | ||||||
| 2 | Klikk på en kategori, avhengig av hvilken type data du leter etter:
| ||||||
| 3 | Fra rullegardinmenyen til høyre velger du et alternativ for å filtrere etter hvor langt tilbake i tid du vil vise data.
| ||||||
| 4 | Samhandle med diagrammene eller smultringgrafene ved å bruke følgende alternativer etter behov:
| ||||||
| 5 | Når du har filtrert dataene i rapportene, klikker du på mer
| ||||||
| 6 | Fjern alle filtrene fra filterlinjen hvis du vil tilbakestille analysevisningen. |
Tilgjengelig analyse for Video Mesh
Hvis du vil ha mer informasjon om tilgjengelig analyse i Control Hub, kan du se delen Videonett i Analyse for skysamarbeidsporteføljen din .
Overvåkingsverktøy for videonett
Overvåkingsverktøyet i Kontrollhub hjelper organisasjonen din med å overvåke tilstanden til Video Mesh-distribusjonen. Du kan kjøre følgende tester på Video Mesh-nodene, -klyngene eller begge deler for å få resultater for bestemte parametere.
Test av signalisering – Tester om SIP-signalisering og mediesignalering skjer mellom videonett-noden og Webex skymedietjenester.
Kaskadetest – Tester om det kan etableres en overlapping mellom videonett-noden og Webex skymedietjenester.
Test for tilgjengelighet – Tester om videonett-noden kan nå målportene for mediestrømmer i Webex skymedietjenester. Den tester også om Video Mesh-noden er i stand til å kommunisere med skyklyngene som er knyttet til mediebeholdere via disse portene.
Når du kjører en test, oppretter verktøyet et simulert møte. Når testen er fullført, ser du et enkelt resultat der det angis om den er bestått eller mislykket, med innebygde feilsøkingstips i rapporten. Du kan planlegge at testen skal kjøres regelmessig eller kjøre testen ved behov. Hvis du vil ha mer informasjon, se Mediehelseovervåking for videonett .
Kjør en test umiddelbart
Bruk denne fremgangsmåten til å kjøre en behovsbetinget overvåkingstest for medietilstand på alle noder i videonett som er i klynger registrert i Control Hub-organisasjonen. Resultatene registreres i Control Hub og aggregeres hver 6. time fra kl. 00:00 UTC.
| 1 | Logg inn på Kontrollhub , og deretter gå til . | ||
| 2 | Klikk på Konfigurer test , klikk Test nå , og kontroller deretter nodene og/eller klyngene du vil teste.
| ||
| 3 | Klikk på Kjør test . |
Hva nå?
Resultatene vises som data på oversiktssiden for overvåkingsverktøyet i Control Hub. Som standard vises resultatene fra alle testene samtidig. Klikk på Signalering , Overlapp , eller Tilgjengelighet for å filtrere resultatene i henhold til den spesifikke testen.
Punktene på tidslinjen med glidebryteren viser aggregerte testresultater for hele organisasjonen. Tidslinjene på klyngenivå viser aggregerte resultater for hver klynge.
| Tidslinjen kan vise datoer i USA-format. Endre språket ditt i profilinnstillingene for å vise datoer i ditt lokale format. |
Du kan holde pekeren over prikkene på tidslinjen for å se testresultatene. Du kan også se testresultatene for hver node. Klikk på et punkt på tidslinjen på klyngenivå for å vise detaljerte resultater.
Resultatene vises i et sidepanel og delt inn i Signaling, Cascasde og Reachabilty. Du kan se om testen var vellykket, om den ble hoppet over eller om testen mislyktes. Feilkoder med mulige rettelser vises også sammen med resultatene.
Bruk bryteren som følger med for å vise suksessratene for forskjellige parametere i form av en tabell.
| En hoppet over test, delvis feil eller feil er ikke kritisk med mindre den skjer kontinuerlig over en viss tid. |
Konfigurer regelmessige tester
Bruk denne fremgangsmåten til å konfigurere og starte regelmessig mediehelseovervåking og tilgjengelighetstester. Disse testene kjøres hver 6. time som standard. Du kan kjøre disse testene på tvers av klynger eller på klyngespesifikke eller nodespesifikke nivåer. Resultatene registreres i Control Hub og aggregeres hver 6. time fra kl. 00:00 UTC.
| 1 | Logg inn på Kontrollhub , og deretter gå til . |
| 2 | Klikk på Konfigurer test , klikk Periodisk test , og kontroller deretter nodene og/eller klyngene du vil teste. |
| 3 | Velg et alternativ:
|
| 4 | Klikk på Neste. |
| 5 | Se gjennom listen over klynger og noder for å kjøre de periodiske testene. Hvis du er fornøyd, klikker du på Konfigurer for å planlegge gjeldende konfigurasjon. |
Hva nå?
Resultatene vises som data på oversiktssiden for overvåkingsverktøyet i Control Hub. Som standard vises resultatene fra alle testene samtidig. Klikk på Signalering , Overlapp , eller Tilgjengelighet for å filtrere resultatene i henhold til den spesifikke testen.
Punktene på tidslinjen med glidebryteren viser aggregerte testresultater for hele organisasjonen. Tidslinjene på klyngenivå viser aggregerte resultater for hver klynge.
| Tidslinjen kan vise datoer i USA-format. Endre språket ditt i profilinnstillingene for å vise datoer i ditt lokale format. |
Du kan holde pekeren over prikkene på tidslinjen for å se testresultatene. Du kan også se testresultatene for hver node. Klikk på et punkt på tidslinjen på klyngenivå for å vise detaljerte resultater.
Resultatene vises i et sidepanel og delt inn i Signaling, Cascasde og Reachabilty. Du kan se om testen var vellykket, om den ble hoppet over eller om testen mislyktes. Feilkoder med mulige rettelser vises også sammen med resultatene.
Bruk bryteren som følger med for å vise suksessratene for forskjellige parametere i form av en tabell.
| En hoppet over test, delvis feil eller feil er ikke kritisk med mindre den skjer kontinuerlig over en viss tid. |
Aktiver 1080p HD-video for lokale SIP-enheter i videonettnode for videonett
Denne innstillingen gjør at organisasjonen kan favorisere 1080p HD-video for lokale registrerte SIP-endepunkter, med en avveining av lavere møtekapasitet. En videonettnode må være vert for møtet. Deltakerne kan bruke 1080p 30 bilder per sekund forutsatt at:
De er alle i bedriftsnettverk.
De bruker en lokal registrert SIP-enhet med HD-funksjonalitet .
Innstillingen gjelder for alle klynger som inneholder videonettnoder.
| Skyregistrerte enheter fortsetter å sende og motta 1080p-strømmer, uavhengig av om denne innstillingen er slått på eller av. |
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til , og klikk deretter Innstillinger på Video Mesh-kortet. |
| 2 | Slå på Videokvalitet . Hvis denne innstillingen er deaktivert, er standarden 720p. |
Hvis du vil ha videooppløsninger som Webex-appen støtter, kan du se Videospesifikasjoner for samtaler og møter .
Private møter
Funksjonen for privat møte forbedrer sikkerheten for møtet ved å avslutte mediene i dine omgivelser. Når du planlegger et privat møte, avsluttes alltid mediene på videonettnodene i bedriftsnettverk uten skyoverlapping.
Som vist her, gjennomgriper aldri private møter medier til skyen. Mediet avsluttes utelukkende på videonettklyngene dine. Videonett-klyngene kan bare gå gjennom hverandre.
Du kan reservere en videonett-klynge for private møter. Når den reserverte klyngen er full, overføres de private møtemediene til de andre videonett-klyngene dine. Når den reserverte klyngen er full, deler private møter og ikke-private møter ressursene til de gjenværende klyngene.
Ikke-private møter bruker ikke reserverte klynger, og disse ressursene reserveres for de private møtene. Hvis et ikke-privat møte går tom for ressurser på nettverket, overføres det til Webex-skyen i stedet.
| Webex-appen med alle funksjonene i Webex Experience aktivert er inkompatibel med videonett. Hvis du vil ha mer informasjon, se Klienter og enheter som bruker videonettnode . |
Støtte og begrensninger for private møter
Videonett støtter private møter på følgende måte:
Private møter er tilgjengelige på Webex versjon 40.12 og nyere.
Bare planlagte møter kan bruke den private møtetypen. Se Planlegg et privat møte i Cisco Webex artikkelen for detaljer.
Private møter er ikke tilgjengelig for møter med alle funksjoner startet eller ble med fra Webex-appen.
Du kan bruke alle nåværende enheter som støttes av Video Mesh.
Nodene dine kan bruke et hvilket som helst gjeldende bilde: 72vCPU og 23vCPU.
Privat møtelogikk oppretter ikke hull i målinger. Vi samler inn de samme målingene for Control Hub som for ikke-private møter.
Siden noen brukere ikke aktiverer denne funksjonen, vises ikke analyserapportene for private møter hvis organisasjonen din ikke har et privat møte om 90 dager.
Private møter støtter enveis tavle fra et video-endepunkt.
Begrensninger
Private møter har disse begrensningene:
Private møter støtter bare VoIP for lyd. De støtter ikke Webex Edge Audio eller PSTN.
Du kan ikke bruke et personlig møterom (PMR) til et privat møte.
Private møter støtter ikke Webex-funksjoner som krever en tilkobling til skyen, for eksempel skyopptak, transkripsjon og Webex Assistant.
Du kan ikke bli med i et privat møte fra et uautentisert skyregistrert videosystem, selv ikke et som er paret til Webex-app.
Bruk private møter som standard møtetype
I Control Hub kan du angi at fremtidige planlagte møter for organisasjonen skal være private møter.
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til . |
| 2 | Klikk på Rediger innstillinger fra Videonett kortet. Bla til Private møter og aktiver innstillingen. |
| 3 | Lagre endringen. |
Når du aktiverer denne innstillingen, gjelder den for alle møter for organisasjonen, også de som er planlagt tidligere.
(Valgfritt) Reserver en klynge for private møter
Private og ikke-private møter bruker vanligvis de samme videonettressursene. Men fordi private møter må holde mediene lokale, kan de ikke sette opp overflyt til skyen når de lokale ressursene er oppbrukt. For å redusere denne muligheten kan du konfigurere en videonettklynge til kun å være vert for private møter.
I Control Hub konfigurerer du klyngen utelukkende for å være vert for private møter. Denne innstillingen forhindrer at ikke-private møter bruker denne klyngen. Private møter bruker denne klyngen som standard. Hvis klyngen går tom for ressurser, overlapper private møter bare de andre videonett-klyngene.
Vi anbefaler at du klargjør en privat klynge for å håndtere forventet maksimal bruk fra private møter.
| Du kan ikke bruke adresseformatet for kort video (meet@your_site ) hvis du reserverer alle Video Mesh-klynger for private møter. Disse anropene mislykkes for øyeblikket uten en riktig feilmelding. Hvis du lar noen klynger være ureserverte, kan samtaler med formatet for korte videoadresser kobles til gjennom disse klyngene. |
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til og klikk Vis alle på Video Mesh-kortet. |
| 2 | Velg videonett-klyngen fra listen, og klikk på Rediger klyngeinnstillinger. |
| 3 | Bla til Private møter og aktiver innstillingen. |
| 4 | Lagre endringen. |
Feilmeldinger for private møter
Denne tabellen viser mulige feil som brukere kan se når de blir med i et privat møte.
Feilmelding | Brukerhandling | Årsak |
|---|---|---|
Ekstern nettverkstilgang nektet Du må være på bedriftsnettverk for å delta på det private møtet. Parede Webex-enheter utenfor bedriftsnettverk vil ikke kunne bli med på møtet. I et slikt scenario kan du prøve å koble den bærbare datamaskinen, mobilen til bedriftsnettverk og bli med på møtet i ikke-sammenkoblet modus. | En ekstern bruker blir med fra utenfor bedriftsnettverk uten VPN eller MRA. | For å bli med i et privat møte må eksterne brukere ha tilgang til bedriftsnettverk via en VPN eller MRA. |
En ekstern bruker er på VPN, men de er paret til en ikke-autentisert enhet. | Enhetsmedier tunnelerer ikke til bedriftsnettverk via VPN. Enheten kan ikke bli med i et privat møte. I stedet, etter å ha koblet til VPN, bør den eksterne brukeren bli med på et privat møte i ikke-paret enhetsmodus fra skrivebords- eller mobilklienten. | |
Ingen tilgjengelige klynger Klyngene som er vert for dette private møtet, har høy kapasitet, kan ikke nås, er frakoblet eller ikke registrert. Ta kontakt med IT-administratoren din for å få hjelp. | En bruker er på bedriftsnettverk (lokalt eller eksternt via VPN), men kan ikke delta i et privat møte. | Videonett-klyngene dine er:
|
Ikke autorisert Du har ikke tillatelse til å delta på dette private møtet fordi du ikke er medlem av vertsorganisasjonen. Ta kontakt med verten for møtet. | En bruker fra en annen organisasjon enn vertsorganisasjonen prøver å bli med i det private møtet. | Bare brukere som tilhører vertsorganisasjonen, kan delta i et privat møte. |
En enhet fra en annen organisasjon enn vertsorganisasjonen prøver å bli med i det private møtet. | Bare enheter som tilhører vertsorganisasjonen, kan bli med i et privat møte. |
Oppbevar mediene dine i videonett for alle eksterne Webex-møter
Når mediene kjører gjennom de lokale Video Mesh-nodene, får du bedre ytelse og bruker mindre båndbredde til Internett.
I tidligere utgivelser kontrollerte du bruken av videonett bare for møter for de interne nettstedene dine. For møter som er vert på eksterne Webex-nettsteder, kontrollerte disse nettstedene om videonettverket kunne overlappe Webex. Hvis et eksternt nettsted ikke tillot overlappende videonett, brukte media alltid Webex-skynodene.
Med Foretrekk videonett for alle eksterne Webex Meetings Hvis Webex-nettsted ditt har tilgjengelige videonett-noder, kjøres mediene gjennom disse nodene for møter som er vert på eksterne Webex-nettsteder. Denne tabellen oppsummerer virkemåten for deltakerne som blir med i Webex-møter:
| Innstillingen er … | Møte på internt Webex-nettsted med overlappende videonett aktivert | Møte på internt Webex-nettsted med overlappende videonett deaktivert | Møte på eksternt Webex-nettsted med videonett-overlappende aktivert | Møte på eksternt Webex-nettsted med overlappende videonett deaktivert |
|---|---|---|---|---|
| Aktivert | Media bruker videonettnodene dine. | Media bruker skynoder. | Media bruker videonettnodene dine. | Media bruker videonettnodene dine. |
| Deaktivert | Media bruker videonettnodene dine. | Media bruker skynoder. | Media bruker videonettnodene dine. | Media bruker skynoder. |
Denne innstillingen er deaktivert som standard, noe som opprettholder virkemåten fra tidligere utgivelser. I disse versjonene ble ikke videonettverket ditt overlappet til Webex, og deltakerne ble med gjennom Webex-skynodene.
| 1 | I kundevisningen ihttps://admin.webex.com , gå til og klikk Vis alle på Video Mesh-kortet. |
| 2 | Velg videonett-klyngen i listen, og klikk på Rediger innstillinger . |
| 3 | Bla til Foretrekk videonett for alle eksterne Webex Meetings og aktiver innstillingen. |
| 4 | Lagre endringen. |
Optimaliser bruken av Video Mesh-distribusjonen
Du kan lande alle klientene dine på Video Mesh-klynger for en forbedret brukeropplevelse gjennom Video Mesh. Hvis videonettklyngekapasiteten er midlertidig nede eller du har økt bruk, kan du optimalisere bruken av videonettklynge ved å kontrollere hvilke klienttyper som lander på videonettklynger. Dette bidrar til å administrere den eksisterende kapasiteten din på en effektiv måte frem til du kan legge til flere noder for å dekke etterspørselen.
Se Analyseportal på Control Hub for å forstå trender for bruk, bruk, omdirigering og overflyt. Basert på disse trendene kan du for eksempel velge å la skrivebordsklientene eller SIP-enhetene lande på Video Mesh-klynger, og la mobilklientene lande på Webex-skynoder. Sammenlignet med mobilklientene støtter skrivebordsklientene og SIP-enhetene høyere oppløsning, har større skjermer og bruker mer båndbredde, og du kan optimalisere brukeropplevelsen for deltakerne som bruker disse klienttypene.
Du kan også optimalisere klyngekapasiteten og maksimere brukeropplevelsen ved å la klienttypene som de fleste kundene bruker, lande på Video Mesh-klynger.
| 1 | Logg på Control Hub , og deretter velge . – eller – Velg . |
| 2 | Under Innstillinger for inkludering av klienttype , er alle klienttyper kontrollert som standard. Fjern merket for klienttypene du vil ekskludere fra bruk av videonett-klynger. Disse klyngene er vert på Webex-skynoder. |
| 3 | Klikk på Lagre. |
Avregistrer videonettnode
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til . |
| 2 | Klikk på Vis alle på Video Mesh-kortet. |
| 3 | Fra listen over ressurser går du til riktig klynge og velger noden. |
| 4 | Klikk på . Det vises en melding som ber deg bekrefte at du vil slette noden. |
| 5 | Når du har lest og forstått meldingen, klikker du på Avregistrere node . |
Flytt videonettnode
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til , og velg deretter Vis alle på Video Mesh-kortet. |
| 2 | Velg noden du vil flytte, fra listen, og klikk deretter Handlinger (den vertikale ellipsen). |
| 3 | Velg Flytt node . |
| 4 | Velg riktig alternativknapp for dit du vil flytte noden:
|
| 5 | Klikk på Flytt node . Noden flyttes til den nye klyngen.
|
Angi oppgraderingsplan for videonettklynge
Du kan angi en bestemt oppgraderingsplan eller bruke standardplanen på 03.00 Daglig USA: Amerika/Los Angeles. Du kan velge å utsette en kommende oppgradering om nødvendig.
Programvareoppgraderinger for Video Mesh gjøres automatisk på klyngenivå, noe som sikrer at alle nodene alltid kjører den samme programvareversjon. Oppgraderinger utføres i henhold til oppgraderingsplanen for klyngen. Når en programvareoppgradering blir tilgjengelig, kan du oppgradere klyngen manuelt før det planlagte oppgraderingstidspunktet.
Før du starter
| Hasteoppgraderinger tas i bruk så snart de er tilgjengelige. |
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til , og klikk deretter Vis alle på Video Mesh-kortet. | ||
| 2 | Klikk på en medieressurs , og klikk deretter på Rediger klyngeinnstillinger . | ||
| 3 | På Innstillinger side, bla til Oppgrader , og velg deretter tid, frekvens og tidssone for oppgraderingsplanen.
| ||
| 4 | (Valgfritt) Klikk om nødvendig Utsette for å utsette oppgraderingen én gang, til neste vindu. Under tidssone vises dato og klokkeslett for neste tilgjengelige oppgradering. |
- Virkemåte for oppgradering
-
Noden sender regelmessige forespørsler til skyen for å se om en oppdatering er tilgjengelig.
Skyen gjør ikke oppgraderingen tilgjengelig før klyngen når oppgraderingsvinduet sitt. Når oppgraderingsvinduet kommer, leverer nodens neste regelmessige oppdateringsforespørsel til skyen oppdateringsinformasjonen.
Noden henter oppdateringer over en sikker kanal.
Eksisterende tjenester avsluttes elegant for å stoppe ruting av innkommende anrop til noden. Den elegante avslutningen gir også eksisterende samtaler tid til å fullføre (opptil 2 timer).
Oppgraderingen installeres.
Skyen utløser bare oppgraderingen for en prosentandel av nodene i en klynge om gangen.
Slett videonett-klynge
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til , og klikk deretter Vis alle . | ||
| 2 | Fra listen over ressurser blar du til videonettressursen du vil slette, og klikker deretter Rediger klyngeinnstillinger .
| ||
| 3 | Klikk på Slett klynge , og velg deretter én:
|
Deaktiver videonett
Før du starter
Før du deaktiverer Video Mesh, vil du avregistrere alle Video Mesh-noder.
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til , velg Innstillinger på Video Mesh-kortet. |
| 2 | Klikk på Deaktiver . |
| 3 | Se gjennom listen over klynger, og les ansvarsfraskrivelsen i dialogboksen. |
| 4 | Merk av i avmerkingsboks for å bekrefte at du forstår denne handlingen, og klikk på Deaktiver i dialogboksen. |
| 5 | Når du er klar til å deaktivere videonettet, klikker du på Deaktiver tjenesten . Deaktivering fjerner alle Video Mesh-noder og -klynger. Videonett er ikke lenger konfigurert. |
Feilsøke registrering av videonettnode
Denne delen inneholder mulige feil du kan støte på under registreringen av Video Mesh-noden til Webex-skyen, og foreslåtte trinn for å rette dem.
Kunne ikke løse domenet
Denne meldingen vises hvis DNS-innstillingene som er konfigurert på Video Mesh-noden, ikke er riktige.
Logg på konsollen til Video Mesh-noden, og kontroller at DNS-innstillingene er riktige.
Kunne ikke koble til nettstedet ved hjelp av port 443 via SSL
Denne meldingen vises hvis videonett-noden ikke kan koble til Webex-skyen.
Kontroller at nettverket tillater tilkobling på portene som kreves for Video Mesh. Hvis du vil ha mer informasjon, se Porter og protokoller som brukes av videonett .
ThousandEyes-integrering med Video Mesh
Video Mesh-plattformen er nå integrert med ThousandEyes-agenten, slik at du kan utføre ende-til-ende overvåking på tvers av det hybride digitale økosystemet. Denne integreringen utstyrer deg med et bredt utvalg av nettverksovervåkingstester som åpner for innsyn i områder som proxyer, gatewayer og rutere. Problemer hvor som helst langs en kundes nettverksinfrastruktur kan begrenses og diagnostiseres med større presisjon, noe som forbedrer effektiviteten i distribusjonen.
Fordeler med ThousandEyes-integrering
- Gir deg flere testtyper å velge mellom. Du kan konfigurere én eller flere tester som passer for applikasjonen eller ressursen du vil overvåke.
- Gir deg mulighet til å angi testterskler som er spesifikke for kravene dine.
- Testresultatene er tilgjengelige via ThousandEyes-nettappen og ThousandEyes API i sanntid.
- Større synlighet i feilsøking – Kunder kan identifisere årsaken til et problem i nettverket, noe som reduserer løsningstiden.
Aktiverer ThousandEyes for videonett
Bruk denne fremgangsmåten for å aktivere ThousandEyes-agent for Video Mesh-distribusjonen.
| 1 | Fra Kontrollhub , klikk Hybrid nederst til venstre på skjermen. | ||
| 2 | Klikk på Rediger innstillinger på Videonett kortet. | ||
| 3 | Bla ned til ThousandEyes-integrering . Bryteren vil være deaktivert som standard. Klikk på bryteren for å aktivere den. | ||
| 4 | Klikk på ThousandEyes-brukerprofil , åpnes ThousandEyes-nettportalen. Logg på med administratorlegitimasjonen. | ||
| 5 | Det vises et sidepanel med Kontogruppetoken . | ||
| 6 | Klikk på visningsikonet, og klikk deretter Kopier .
| ||
| 7 | Gå tilbake til Control Hub-fanen, lim inn tokenet i Agenttoken felt. | ||
| 8 | Klikk på Aktiver , ThousandEyes er nå aktivert for videonettdistribusjon. |
Hva nå?
- Etter 5 minutter går du tilbake til ThousandEyes-nettsiden, klikker Sky- og bedriftsagenter , og klikk deretter Agentinnstillinger . Du skal kunne se alle nodene dine oppført som agenter under Bedriftsagenter . Hvis agentene ikke vises, kontrollerer du ThousandEyes-integrasjonskortet på Control Hub for feilmeldinger.
- Hvis det vises en feilmelding , klikker du på bryteren og deretter på Deaktiver . Gjenta trinnene for å aktivere ThousandEyes-agent, og sørg for at riktig kontogruppetoken kopieres og limes inn i Agenttoken felt.
| For øyeblikket støtter ikke ThousandEyes-tester Video Mesh-noder bak en proxy. |
Konfigurere tester ved hjelp av ThousandEyes
Nettverkstest – agent-til-agent
Agent-til-agent-nettverkstesten lar brukere av ThousandEyes ha ThousandEyes-agenter i begge ender av en overvåket bane, noe som muliggjør testing av banen i en av eller begge to retninger: kilde til mål eller mål til kilde. Hvis du vil detaljert informasjon om hvordan du konfigurerer en agent-til-agent-test, se Oversikt over test av agent-til-agent .
Et eksempel på en dialog for oppretting av tester vises nedenfor.
SIP-servertest
SIP-servertester forenkler nettverksmålinger, BGP-datainnsamling og, viktigst av alt, tilgjengelighet og ytelsestesting av SIP-tjenester mot SIP-basert VoIP-infrastruktur.
Hvis du vil ha detaljert informasjon om hvordan du konfigurerer en SIP-servertest, se Testinnstillinger for SIP-serveren .
Et eksempel på en dialog for oppretting av tester vises nedenfor.
RTP-strømtest
En RTP-strømtest oppretter en simulert taledatastrøm mellom to ThousandEyes-agenter som fungerer som VoIP-brukeragenter. RTP-pakker sendes mellom én eller flere agenter og en målagent, ved hjelp av UDP som transportprotokoll, for å hente målinger for gjennomsnittlig meningsscore (MOS), pakketap, forkastelser, latens og PDV (Packet Delay Variation). Produserte målinger er enveis målinger (kilde til mål). RTP-strømtesten gir serverport, samtalevarighet, bufferstørrelse for jitter og konfigurasjonsalternativer for kodeken.
Hvis du vil detaljert informasjon om konfigurering av en RTP-strømtest, se Innstillinger for RTP-strømtest .
Et eksempel på en dialog for oppretting av tester vises nedenfor.
URL-test for Webex HTTP-server
Denne testen overvåker den primære landingssiden som brukerne kobler seg til når de bruker Webex. Et eksempel på en dialog for oppretting av tester vises nedenfor.
Autoritativ test av Webex DNS-server
Denne testen brukes til å sikre at Webex-domenet ditt løses på riktig måte både internt og eksternt. Når du bruker Enterprise-agenter, må du oppdatere DNS-servere for å bruke de interne navnetjenerne dine. Hvis du bruker Cloud Agents for ekstern synlighet, bruker du Oppslagsservere for å automatisk fylle ut de autoritative eksterne navnetjenerne. Dette eksemplet viser skyagenter som løser cisco.webex.com. Du må oppdatere den til organisasjonens domene.
Et eksempel på en dialog for oppretting av tester vises nedenfor.
'
Behandle videonettnode fra nettgrensesnittet
Før du kan gjøre nettverksendringer i Video Mesh-noder som er registrert i skyen, må du bruke Control Hub til å sette dem i vedlikeholdsmodus. Hvis du vil ha mer informasjon og en fremgangsmåte som må følges, se Flytt en node til vedlikeholdsmodus .
| Vedlikeholdsmodus er kun ment å forberede en node for avslutning eller omstart, slik at du kan gjøre bestemte endringer i nettverksinnstillinger (DNS, IP, FQDN) eller forberede deg på maskinvarevedlikehold, for eksempel bytte ut RAM, harddisk og så videre. Oppgraderinger skjer ikke når en node settes i vedlikeholdsmodus. |
Når du setter en node i vedlikeholdsmodus, foretar den en elegant avslutning av anropstjenester (stopper å godta nye anrop og venter i opptil 2 timer på at eksisterende anrop skal fullføres). Formålet med å avslutte anropstjenester på en elegant måte er å tillate omstart eller avslutning av noden uten å forårsake avbrutte anrop.
Slik får du tilgang til oversikten over videonett
Du kan åpne webgrensesnitt på én av disse måtene:
Hvis du er fullstendig administrator og allerede har registrert noden i skyen, kan du få tilgang til noden fra Control Hub.
Fra kundevisningen ihttps://admin.webex.com , gå til . Under Ressurser på Video Mesh-kortet klikker du Vis alle . Klikk på klyngen, og klikk deretter på noden du vil ha tilgang til. Klikk på Gå til Node .
Bare en fullstendig administrator for Webex-organisasjonen din kan bruke denne funksjonen. Andre administratorer, inkludert partnere og fullstendige eksterne administratorer, har ikke Gå til node alternativet for ressursene for videonett.
I en nettleserfane går du til
<IP address>/setup, for eksempelhttps://192.0.2.0/setup. Angi administratorlegitimasjonen du konfigurerte for noden, og klikk deretter Logg på .Hvis administratorkontoen er deaktivert, er ikke denne metoden tilgjengelig. Se delen Deaktiver eller aktiver den lokale administratorkontoen fra nettgrensesnittet på nytt.
Oversikten er standardsiden og har følgende informasjon:
Samtalestatus – Gir antall pågående samtaler gjennom noden.
Nodedetaljer – Gir nodetype, programvarebilde, programvareversjon, OS-versjon, QoS vedlikeholdsmodus .
Nodehelse – Gir bruksdata (CPU, minne, disk) og tjenestestatus (Management Service, Messaging Service, NTP-synkronisering).
Nettverksinnstillinger – Gir nettverksinformasjon: vertsnavn, grensesnitt, IP, gateway, DNS, NTP og om dobbel IP er aktivert.
Registreringsdetaljer – Gir registreringsstatus, organisasjonsnavn, organisasjons-ID, klynge noden er en del av og klynge-ID.
Skytilkobling –Kjører en serie tester fra noden til Webex-skyen og tredjepartsdestinasjoner som noden må ha tilgang for å kjøre på riktig måte.
Det kjøres tre typer tester: DNS-oppløsning, serverresponstid og båndbredde.
DNS-tester bekrefter at noden kan løse et bestemt domene. Disse testene rapporterer som mislykket hvis serveren ikke svarer innen 10 sekunder. De vises som «Bestått» med en oransje «advarselsfarge» hvis responstiden er mellom 1,5 og 10 sekunder. De periodiske DNS-kontrollene på noden genererer alarmer hvis DNS-responstiden er lengre enn 1,5 sekunder.
Connect-tester bekrefter at noden kan koble til en bestemt HTTPS-URL og motta et svar (andre svar enn proxy- eller gatewayfeil godtas som bevis på tilkobling).
Listen over tester som kjøres fra oversiktssiden er ikke uttømmende og inkluderer ikke websocket-tester.
Noden sender alarmer hvis anropsprosessene ikke kan fullføre websocket-tilkoblinger til skyen eller koble til anropsrelaterte tjenester.
Resultatet Godkjent eller Ikke bestått vises ved siden av hver test. du kan holde pekeren over denne teksten for å se mer informasjon om hva som ble kontrollert da testen kjørte.
Som vist i skjermbildet som følger, kan alarmvarsler også vises i sidepanelet hvis det ble generert alarmer av noden. Disse varslene identifiserer potensielle problemer på noden og gir forslag til hvordan du kan feilsøke eller løse disse problemene. Hvis det ikke ble generert noen alarmer, vises ikke varslingspanelet.
Konfigurere nettverksinnstillinger fra nettgrensesnitt for videonettnode
Hvis nettverkstopologien endres, kan du bruke webgrensesnitt for hver Webex-videonettnode og endre nettverksinnstillinger der. Det kan hende at du ser en advarsel om endring av nettverksinnstillinger, men du kan likevel lagre endringene i tilfelle du gjør endringer i nettverket etter at du har endret nodeinnstillingene for Webex-videonett.
| 1 | Åpne nodegrensesnittet for Webex-videonett. | ||
| 2 | Gå til Nettverk . Gjeldende nettverksinnstillinger for noden vises. | ||
| 3 | Endre følgende innstillinger for Verts- og nettverkskonfigurasjon etter behov:
| ||
| 4 | Klikk på Lagre verts- og nettverkskonfigurasjon , og etter at popup-vinduet som sier at noden må startes på nytt, klikker du Lagre og starte på nytt . Under lagringen blir alle felt validert på serversiden. Advarsler som vises, angir vanligvis at serveren ikke kan nås, eller at det ikke ble returnert et gyldig svar ved spørsmål – for eksempel hvis FQDN ikke kan løses ved hjelp av de oppgitte DNS-server . Du kan velge å lagre ved å ignorere advarselen, men anrop fungerer ikke før FQDN kan løses til DNS-en som er konfigurert på noden. En annen mulig feiltilstand er hvis gateway-adressen ikke er i samme delnett som IP-adresse. Etter at videonettnode har startet på nytt, trer endringene i nettverkskonfigurasjon i kraft. | ||
| 5 | Endre følgende innstillinger for NTP-servere etter behov:
| ||
| 6 | Klikk på Lagre NTP-servere .
Hvis NTP-server er en FQDN og det ikke kan løses, returneres en advarsel. Hvis FQDN for NTP-server er løst, men den løste IP-en ikke kan søkes etter NTP-tid, returneres en advarsel. |
Angi det eksterne nettverksgrensesnittet fra webgrensesnittet for videonettnode
Hvis nettverkstopologien endres, kan du bruke webgrensesnitt for hver Webex-videonettnode og endre nettverksinnstillinger der. Du kan se en advarsel om endring av nettverksinnstillinger. Du kan imidlertid fortsatt lagre endringene i tilfelle du gjør endringer i nettverket etter at du har endret nodeinnstillingene for Webex Video Mesh.
Du kan konfigurere det eksterne nettverksgrensesnitt hvis du distribuerer videonettnode i nettverkets DMZ, slik at du kan isolere bedriftstrafikken (intern) fra ekstern (ekstern) trafikk.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Nettverk . Gjeldende nettverksinnstillinger for noden vises. |
| 3 | Klikk på Avansert . |
| 4 | Slå på Aktiver eksternt nettverk og klikk deretter Ok for å aktivere alternativene for ekstern IP-adresse på noden. |
| 5 | Skriv inn Ekstern IP-adresse , Ekstern nettverksmaske , og Ekstern gateway verdier. |
| 6 | Klikk på Lagre ekstern nettverkskonfigurasjon . |
| 7 | Klikk på Lagre og starte på nytt for å bekrefte endringen. Noden starter på nytt for å aktivere den doble IP-adresse, og konfigurerer deretter automatisk de grunnleggende statiske rutingsreglene. Disse reglene bestemmer at trafikk til og fra en IP-adresse for privat klasse bruker et internt grensesnitt. trafikk til og fra en offentlig IP-adresse bruker et eksternt grensesnitt. Senere kan du opprette dine egne rutingsregler – for eksempel hvis du må konfigurere en overstyring og gi tilgang til et eksternt domene fra det interne grensesnittet. |
| 8 | Hvis det finnes feil, klikker du Ok for å lukke dialogboks, fikse feilene og klikk på Lagre ekstern nettverkskonfigurasjon igjen. |
Hva nå?
Hvis du vil bekrefte den interne og eksterne konfigurasjonen av IP-adresse , følger du trinnene i Kjør et ping fra nettgrensesnittet for videonettnode .
Test en ekstern destinasjon (eksempel, cisco.com); hvis vellykket, viser resultatene at målet ble åpnet fra det eksterne grensesnittet.
Test en intern IP-adresse; hvis vellykket, viser resultatene at adressen ble åpnet fra det interne grensesnittet.
Legg til interne og eksterne rutingsregler fra nettgrensesnitt for videonettnode
I en distribusjon med to nettverksgrensesnitt (NIC) kan du finjustere rutingen for videonettnoder ved å legge til brukerdefinerte ruteregler for eksterne og interne grensesnitt. Standardrutene legges til nodene, men du kan gjøre unntak – for eksempel eksterne delnett eller vertsadresser som må få tilgang via det interne grensesnittet, eller interne delnett eller vertsadresser som må få tilgang fra det eksterne grensesnittet. Utfør følgende trinn etter behov.
Før du starter
| 1 | Åpne nodegrensesnittet for Webex-videonett. | ||
| 2 | Gå til Nettverk . Gjeldende nettverksinnstillinger for noden vises. Hvis du har konfigurert det eksterne nettverket, vises Rutingsregler-fanen. | ||
| 3 | Klikk på Rutingsregler -fanen. Første gang du åpner denne siden, vises standard systemrutingsregler i listen. Som standard går all intern trafikk gjennom det interne grensesnittet og ekstern trafikk gjennom det eksterne grensesnittet. Du kan legge til manuelle overstyringer av disse reglene i de neste trinnene. | ||
| 4 | Hvis du vil legge til en regel, klikker du på Legg til rutingregel , og velg deretter ett av følgende alternativer:.
| ||
| 5 | Klikk på Legg til rutingregel . Når du legger til hver regel, vises de i listen over rutingsregler, kategorisert som brukerdefinerte regler. | ||
| 6 | Hvis du vil slette én eller flere brukerdefinerte regler, merker du av i avmerkingsboks i kolonnen til venstre for reglene, og deretter klikker du Slett rutingsregler .
|
| Egendefinerte rutingsregler kan skape potensial for konflikter med annen ruting. Du kan for eksempel definere en regel som fryser SSH-tilkoblingen til grensesnittet for videonettnode . Hvis dette skjer, gjør du ett av følgende, og deretter fjerner eller endrer du rutingsregelen:
|
Konfigurere containernettverk fra nettgrensesnitt for videonettnode
Videonett-noden reserverer et delnettområde for intern bruk i noden. Standardområdet er 172.17.42.0–172.17.42.63. Nodene svarer ikke på ekstern-til-video-nettnodetrafikk som kommer fra dette området. Det kan være lurt å bruke nodekonsollen til å endre IP-adresse for containerbroen for å unngå konflikter med andre enheter i nettverket.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Nettverk . Gjeldende nettverksinnstillinger for noden vises. |
| 3 | Klikk på Avansert . |
| 4 | Endre verdiene for Beholderens IP-adresse og Nettverksmaske for beholder , etter behov, og klikk deretter Lagre konfigurasjon for containernettverk . |
| 5 | Klikk på Lagre og starte på nytt for å bekrefte endringen. |
| 6 | Hvis det finnes feil, klikker du Ok for å lukke dialogboks, fikse feilene og klikk på Lagre konfigurasjon for containernettverk igjen. |
Angi MTU-størrelser for nettverksgrensesnitt
Alle Webex Video Mesh-noder har bane-MTU (PMTU)-oppdaging aktivert som standard. Med PMTU kan noden oppdage MTU-problemer og justere MTU-størrelsen automatisk. Når PMTU mislykkes på grunn av brannmur- eller nettverksproblemer, kan noden ha tilkoblingsproblemer til skyen fordi pakker som er større enn MTU-en, faller bort. Manuell innstilling av en lavere MTU-størrelse kan løse dette problemet.
Før du starter
Hvis du allerede har registrert noden, må du sette noden i vedlikeholdsmodus før du kan endre MTU-innstillingene.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Nettverk . Gjeldende nettverksinnstillinger for noden vises. |
| 3 | Klikk på Avansert . |
| 4 | I Innstillinger for grensesnitt MTU , angi en MTU-verdi mellom 1280 og 9000 byte i gjeldende felt. Hvis du har aktivert det eksterne grensesnittet, kan du angi størrelsen på både det interne og det eksterne grensesnittets MTU separat. |
Hva nå?
Hvis du setter noden i vedlikeholdsmodus for å endre MTU, må du slå av vedlikeholdsmodus.
Aktiver eller deaktiver DNS-bufring
Hvis DNS-svar til Video Mesh-nodene regelmessig tar mer enn 750 ms, eller hvis Cisco TAC anbefaler det, kan du aktivere DNS-bufring. Når DNS-bufring er på, bufrer noden DNS-svar lokalt. Med hurtigbufferen er forespørsler mindre utsatt for forsinkelser eller tidsavbrudd som kan føre til tilkoblingsalarmer, avbrudd i samtalen eller problemer med samtalekvaliteten. DNS-bufring kan også redusere belastningen på DNS-infrastrukturen.
Før du starter
Flytt noden til vedlikeholdsmodus. Når statusen for vedlikeholdsmodus er På (aktive samtaler er fullført eller har avbrutt på slutten av den ventende perioden), kan du aktivere eller deaktivere DNS-bufring.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Nettverk . Gjeldende nettverksinnstillinger for noden vises. |
| 3 | Klikk på Avansert . |
| 4 | I delen Konfigurasjon av DNS-bufring velger du Aktiver DNS-bufring på eller av. |
| 5 | Klikk på i bekreftelsesdialogboksen Lagre og starte på nytt . |
| 6 | Når noden har startet på nytt, åpner du nodegrensesnittet for Webex Video Mesh på nytt og bekrefter at tilkoblingskontrollene er vellykket på Oversikt-siden. |
Når du aktiverer DNS-bufring, vil Statistikk for DNS-hurtigbuffer viser følgende statistikk:
Statistikk | Beskrivelse |
|---|---|
Bufferoppføringer | Antall tidligere DNS-oppløsninger som DNS-hurtigbufferserveren har lagret |
Buffertreff | Antall ganger siden hurtigbufferen ble tilbakestilt at hurtigbufferen behandlet en DNS-forespørsel fra Video Mesh, uten å forespørre kundens DNS-server |
Buffer feil | Antall ganger siden tilbakestillingen av hurtigbufferen kunde DNS-server behandlet en DNS-forespørsel fra Video Mesh i stedet for gjennom hurtigbufferen |
Prosent treff på hurtigbuffer | Prosentandelen av DNS-forespørsler fra Video Mesh som hurtigbufferen behandlet uten å spørre kundens DNS-server |
Hurtigbufferserverens utgående DNS-spørringer | Antall DNS-spørringer som DNS-hurtigbufferserveren for Video Mesh utførte mot kundens DNS-servere |
Innkommende DNS-spørringer for hurtigbufferserver | Antall DNS-spørringer som Video Mesh utførte mot sin interne DNS-hurtigbufferserver |
Spørringsforhold utgående til innkommende | Forholdet mellom DNS-spørringer gjort av Video Mesh mot kundens DNS-server og spørringene gjort av Video Mesh mot den interne DNS-hurtigbufferserveren |
Innkommende søk per sekund | Gjennomsnittlig antall DNS-spørringer per sekund som Video Mesh utførte mot den interne DNS-hurtigbufferserveren |
Utgående søk per sekund | Gjennomsnittlig antall DNS-spørringer per sekund som Video Mesh utførte mot kundens DNS-servere |
Utgående DNS-forsinkelse [tidsintervall] | Prosentandelen av DNS-spørringer som Video Mesh utførte mot kundens DNS-servere der responstiden falt innenfor det beskrevne tidsintervall |
Bruk Tøm DNS-hurtigbuffer for å tilbakestille DNS-hurtigbufferen når TAC ber om det. Når du har tørket DNS-hurtigbufferen, ser du en høyere Spørringsforhold utgående til innkommende etter hvert som hurtigbufferen fylles på. Du trenger ikke å sette noden i vedlikeholdsmodus for å tørke hurtigbufferen.
Hva nå?
Flytt noden ut av vedlikeholdsmodus. Gjenta deretter oppgaven på alle andre noder som krever en endring.
Last opp sikkerhetssertifikater
Konfigurer et klareringsforhold mellom noden og en ekstern server, for eksempel en syslog-server.
| I et klyngemiljø må du installere CA- og serversertifikater på hver node individuelt. |
| 1 | Åpne nodegrensesnittet for Webex-videonett. | ||
| 2 | Når du konfigurerer TLS med en annen server, for eksempel en syslog-serveren , vi anbefaler Av sikkerhetshensyn bruker du et CA-signert sertifikat på videonettnodene i stedet for nodens standard selvsignert sertifikat. Hvis du vil opprette og laste opp sertifikatet og nøkkelparene på videonettnoden, går du til Serversertifikater , og følg denne fremgangsmåten:
| ||
| 3 | Velg et alternativ avhengig av hvordan CA-sertifikat for den eksterne serveren er signert:
| ||
| 4 | Hent sertifikatet eller klareringsliste for sertifikater (CTL) som den eksterne serveren bruker. Som med nodesertifikatet for Video Mesh, lagrer du den eksterne serverfilen et sted som er lett å huske. | ||
| 5 | Gå tilbake til fanen for nodegrensesnitt for Webex-videonett, klikk på Trust Store og proxy , og velg deretter et alternativ:
En videonett-node som er registrert i skyen, venter i opptil to timer på at eventuelle samtaler avsluttes, og setter seg selv i en midlertidig inaktiv tilstand (hviler). For å installere sertifikatet må noden starte på nytt og gjør det automatisk. Når den kobles til igjen, vises en melding når sertifikatet er installert på videonett-noden, og du kan deretter laste inn siden på nytt for å vise det nye sertifikatet. | ||
| 6 | Gjenta opplastingen av sertifikatet eller sertifikatkjede på annenhver videonett-node i den samme klyngen. |
Generer videonettlogger for støtte
Du kan bli bedt om å sende logger direkte til Cisco, eller du kan laste dem ned selv for å legge dem ved en sak. Bruk denne fremgangsmåten fra webgrensesnitt til å generere logger og sende dem til Cisco eller laste dem ned fra en hvilken som helst videonettnoder. Den genererte loggpakken inneholder medielogger, systemlogger og beholderlogger. Pakken inneholder nyttig informasjon om tilkobling til Webex, plattformproblemer og samtaleoppsett eller medier, slik at Cisco kan feilsøke videonett-nodedistribusjonen for deg.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Feilsøking , og velg deretter et alternativ ved siden av Send logger :
Genererte logger lagres historisk på noden og forblir på noden selv etter omstart. En opplastingsidentifikator vises på siden. Støtte bruker denne verdien til å identifisere de opplastede loggene dine. |
| 3 | Når du åpne en sak eller samhandle med Cisco TAC , inkluderer opplastingsidentifikatorverdien slik at kundestøtteteknikeren får tilgang til loggene. Hvis du sendte loggen til Cisco direkte, trenger du ikke å laste opp loggpakken til TAC-saken. |
Hva nå?
Mens logger lastes opp til Cisco eller lastes ned, kan du kjøre pakkelagring fra samme skjermbilde.
Generer pakkeopptak for videonett for støtte
Du kan kjøre en pakkelagring (PCAP) og sende den til Cisco for videre analyse. En pakkelagring tar et øyeblikksbilde av datapakker som går gjennom nodens nettverksgrensesnitt. Etter at pakkene er fanget opp og sendt inn, kan Cisco analysere den innsendte registreringen og hjelpe med feilsøking av Video Mesh-nodedistribusjonen.
Før du starter
| pakkelagring er kun ment for feilsøkingsformål. Hvis du kjører en pakkelagring på en live Video Mesh-node som er vert for aktive samtaler, kan pakkelagring påvirke ytelsen til noden, og den genererte filen kan bli overskrevet. Dette fører til tap av registrerte data. Vi anbefaler at du bare kjører pakkelagring i dårlige timer eller når anropsantallet er mindre enn 3 på noden. |
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Feilsøking . Du kan starte pakkelagring og laste opp logger samtidig. |
| 3 | (Valgfritt) I Pakkeopptak kan du begrense registreringen til pakker på et bestemt grensesnitt, filtrere etter pakker til eller fra bestemte verter, eller filtrere etter pakker på én eller flere porter. |
| 4 | Hvis du vil starte prosessen, slår du på Start pakkeopptak innstillingen. |
| 5 | Når du er ferdig, slår du av Start pakkeopptak innstillingen. |
| 6 | Velg én:
Når et pakkeopptak er lastet opp, vises en opplastingsidentifikator på siden. Støtte bruker denne verdien til å identifisere den opplastede pakkelagring. Maksimal størrelse for pakkeopptak er 2 GB. |
| 7 | Når du åpne en sak eller samhandle med Cisco TAC , inkluderer du opplastingsidentifikatorverdien slik at kundestøtteteknikeren din får tilgang til pakkelagring. |
Kjør et ping fra nettgrensesnittet for videonettnode
Du kan kjøre en ping fra webgrensesnitt for Video Mesh-noden . Dette trinnet tester en destinasjon du angir, og ser om videonettnoden kan nå den.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Feilsøking , bla til Ping , og angi deretter en destinasjonsadresse du vil teste i FQDN- eller IP-adresse felt under Test tilkoblingen ved hjelp av ping . |
| 3 | Klikk på Ping . Testen kjøres, og du ser en melding om vellykket ping eller feil. Testen har ingen tidsavbrudd. Hvis du får en feil eller testen kjører på ubestemt tid, kontrollerer du målverdien du anga, og nettverksinnstillinger. |
Kjør en sporingsrute fra webgrensesnitt for videonett
Du kan kjøre en traceroute fra webgrensesnitt for Video Mesh-noden . Dette trinnet viser ruten som pakker tar fra noden til destinasjonen du angir. Visning av traceroute-informasjonen hjelper deg med å finne ut hvorfor en bestemt tilkobling kan være dårlig, og kan hjelpe deg med å identifisere problemer.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Feilsøking , bla til Traceroute , og angi deretter en destinasjonsadresse du vil teste i FQDN- eller IP-adresse felt under Spor rute til vert . Testen kjøres, og du får en melding om vellykket sporing eller feil. Testen tidsavbrytes etter 16 sekunder. Hvis du får en feil eller testen blir tidsavbrutt, kontrollerer du målverdien du anga, og nettverksinnstillinger. |
Kontroller NTP-serveren fra nettgrensesnittet for videonettnode
Du kan angi en FQDN- eller IP-adresse for en NTP-server (Network Time Protocol) for å bekrefte at noden for videonett har tilgang til serveren. Denne testen er nyttig hvis du merker problemer med tidssynkronisering og ønsker å utelukke tilgjengeligheten til NTP-server.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Feilsøking , bla til Sjekk NTP-serveren , og angi deretter en destinasjonsadresse du vil teste i FQDN- eller IP-adresse felt under Vis svar på SNTP-spørring . Testen kjøres, og du ser en melding om at spørringen var vellykket eller mislyktes. Testen har ingen tidsavbrudd. Hvis du får en feil eller testen kjører på ubestemt tid, kontrollerer du målverdien du anga, og nettverksinnstillinger. |
Identifisere portproblemer med Reflector Tool i nettgrensesnittet
Reflektorverktøyet (en kombinasjon av en server på Video Mesh-noden og klient gjennom et Python-skript) brukes til å bekrefte om de nødvendige TCP/UDP-portene er åpne fra Video Mesh-nodene.
Før du starter
Last ned en kopi av Reflector Tool Client (et Python-skript) frahttps://github.com/CiscoDevNet/webex-video-mesh-reflector-client .
For at skriptet skal fungere som det skal, må du kontrollere at du kjører Python 2.7.10 eller nyere i miljøet ditt.
For øyeblikket støtter dette verktøyet SIP-endepunkter til videonettnoder og intraklyngebekreftelse.
| 1 | Fra kundevisningen ihttps://admin.webex.com , aktiver vedlikeholdsnoden for videonettnode ved å følge disse instruksjonene . |
| 2 | Vent til noden viser statusen Klar for vedlikehold i Control Hub. |
| 3 | Åpne nodegrensesnittet for Webex-videonett. Hvis du vil ha instruksjoner, se Behandle videonettnode fra nettgrensesnittet . |
| 4 | Bla til Refleksverktøy , og start deretter enten TCP Reflector Server eller UDP Reflector Server , avhengig av hvilken protokoll du vil bruke. |
| 5 | Klikk på Start Reflector Server , og vent deretter til serveren starter. Du ser et varsel når serveren starter. |
| 6 | Fra et system (for eksempel en PC) i et nettverk som du vil at Video Mesh-nodene skal nå, kjører du skriptet med følgende kommando:
På slutten av kjøringen viser klienten en vellykket melding hvis alle nødvendige porter er åpne:
Klienten viser en mislykket melding hvis noen nødvendige porter ikke er åpne:
|
| 7 | Løs eventuelle portproblemer på brannmuren, og kjør deretter trinnene ovenfor på nytt. |
| 8 | Kjør klienten med
|
Aktiver feilsøkingsbrukerkonto fra nettgrensesnitt for videonettnode
Hvis Cisco TAC krever tilgang til noden for Webex-videonett, kan du midlertidig aktivere en brukerkonto slik at brukerstøtte kan kjøre ytterligere feilsøking.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Feilsøking , og slå deretter på Aktiver feilsøkingsbruker innstillingen. Det vises en kryptert passordfrase som du kan oppgi til Cisco TAC. |
| 3 | Kopier passordfrasen, lim den inn i kundestøttebilletten eller direkte til kundestøtteteknikeren, og klikk deretter OK når du har den lagret. |
brukerkonto for feilsøking er gyldig i 3 dager, og deretter utløper den.
Hva nå?
Du kan deaktivere kontoen før den utløper hvis du går tilbake til Feilsøking side, og slå deretter av Aktiver feilsøkingsbruker innstillingen.
Tilbakestill en videonettnode til fabrikkstandard fra nettgrensesnittet
Som en del av oppryddingen av registreringen kan du tilbakestilling til fabrikkinnstillinger fra webgrensesnitt. Dette trinnet fjerner all konfigurasjon du satte på plass mens noden var aktiv, men fjerner ikke oppføringen for den virtuell maskin . Senere kan det være lurt å registrere denne noden på nytt som en del av en annen klynge du bygger fra bunnen av.
Før du starter
Du må bruke Control Hub til å avregistrere videonett-noden fra klyngen som er registrert i Control Hub.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Feilsøking , bla til Tilbakestill til fabrikkinnstillinger , og klikk deretter Tilbakestill node . |
| 3 | Kontroller at du forstår informasjonen i varselet som vises, og klikk deretter på Tilbakestill og start på nytt . Noden starter automatisk på nytt etter tilbakestillingen til tilbakestilling til fabrikkinnstillinger. |
Deaktiver eller aktiver den lokale administratorkontoen fra nettgrensesnitt på nytt
Når du installerer en Webex Video Mesh-node, logger du først på med en innebygd lokal konto med brukernavnet «admin». Når du har registrert noden i Webex-skyen, kan du bruke administrasjonslegitimasjonen for Webex-organisasjonen din til å administrere Video Mesh-nodene fra Control Hub. På denne måten gjelder retningslinjene for administratorkonto og administrasjonsprosessene som gjelder for Control Hub, også for videonettnodene dine. For ytterligere kontroll kan du deaktivere den innebygde «admin»-kontoen slik at Control Hub håndterer all administrator og administrasjon.
Bruk disse trinnene etter at du har registrert noden i skyen for å deaktivere (eller aktivere senere) brukerkonto. Når du deaktiverer administratorkontoen, må du bruke Control Hub for å få tilgang til nodens webgrensesnitt.
| Bare en fullstendig administrator for Webex-organisasjonen din kan bruke denne funksjonen. Andre administratorer, inkludert partnere og fullstendige eksterne administratorer, har ikke Gå til node alternativet for ressursene for videonett. |
| 1 | Fra kundevisningen ihttps://admin.webex.com , gå til . | ||
| 2 | Under Ressurser på Video Mesh-kortet klikker du Vis alle . | ||
| 3 | Klikk på klyngen, og klikk deretter på noden du vil ha tilgang til. Klikk på Gå til Node . | ||
| 4 | Gå til Administrasjon . | ||
| 5 | Veksle på Aktiver innlogging for administratorbruker slå av for å deaktivere kontoen, eller på for å aktivere den på nytt.
| ||
| 6 | Klikk på på bekreftelsesskjermen Deaktiver eller Aktiver for å fullføre endringen. |
Når du har deaktivert administratorbrukeren, kan du ikke logge på Video Mesh-noden via WebUI eller CLI lansert fra SSH. Du kan imidlertid logge på ved hjelp av legitimasjonen for administratoren via en CLI som startes fra VMware ESXi-konsollen.
Endre passordfrase for administrator fra nettgrensesnitt
Bruk denne fremgangsmåten til å endre administrator (passordet) for Webex-videonett-noden ved hjelp av webgrensesnitt.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Administrasjon , og ved siden av Endre passordfrase , klikk Endre . |
| 3 | Skriv inn Gjeldende passordfrase , og angi deretter en ny passordfraseverdi i begge Ny passordfrase og Bekreft ny passordfrase . |
| 4 | Klikk på Lagre passordfrase . Meldingen «passord endret» vises, og deretter går du tilbake til påloggingsskjermen. |
| 5 | Logg på med den nye administratorpålogging og passordfrasen (passord). |
Endre utløpsintervall for passordfrase fra nettgrensesnittet
Bruk denne fremgangsmåten til å endre standard utløpsintervall for passordfrasen på 90 dager ved hjelp av webgrensesnitt. Når intervallet er ute, blir du bedt om å angi en ny passordfrase når du logger på videonett-noden.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Administrasjon , og ved siden av Endre utløpsdato for passordfrase , angi en ny verdi for Utløpsintervall (dager) (opptil 365 dager), og klikk deretter Lagre utløpsintervall for passordfrase . Et vellykket skjermbilde vises, og du kan deretter klikke OK for å fullføre. |
Den Administrasjon siden viser også datoer for siste endring av passordfrasen og neste gang passordet utløper.
Angi ekstern logging til en Syslog-server
Hvis du har en syslog-server, kan du angi at noden for Webex-videonett skal logges på informasjonen om revisjonssporet for den eksterne serveren, for eksempel:
Detaljer om administrator
Konfigurasjonsendringer (inkludert slå vedlikeholdsmodus på eller av)
Programvareoppdateringer
Noden aggregerer loggene, hvis noen, og sender dem til serveren hvert tiende minutt.
| 1 | Åpne nodegrensesnittet for Webex-videonett. |
| 2 | Gå til Administrasjon . |
| 3 | Ved siden av Ekstern logging , slå på Aktiver ekstern logging . |
| 4 | For Detaljer om Syslog-server , skriver du inn vertens IP-adresse eller det fullstendige domenenavn og syslog-porten. Hvis serveren ikke kan DNS-løses fra noden, bruker du en IP-adresse i Vert felt. |
| 5 | Velg Protokoll – UDP eller TCP. Hvis du vil bruke TLS-kryptering, velger du TCP og slå deretter på Aktiver TLS . Kontroller at du også laster opp og installerer sikkerhetssertifikatene som kreves for TLS-kommunikasjon mellom noden og syslog-serveren. Hvis det ikke er installert noen sertifikater, bruker noden som standard sine egensignerte sertifikater. Hvis du vil ha hjelp, se Last opp sikkerhetssertifikater . |
| 6 | Klikk på Lagre konfigurasjon for ekstern logging . |
Egenskapene for loggmeldingen har dette formatet: Melding om prioritert tidsstempel Vertsnavn-tag .
Egenskap | Beskrivelse |
|---|---|
Prioritet | Verdien er alltid 131, basert på formelen: Prioritet = (anleggskode * 8) + alvorlighetsgrad. Anleggskoden er 16 for «local0». Alvorlighetsgraden er 3 for «varsel». |
Tidsstempel | Tidsstempelformatet er «Mmm dd tt:mm:ss». |
Vertsnavn | Vertsnavnet for videonett-noden. |
stikkord | Verdien er alltid syslogAuditMsg. |
Melding | Meldingen er en JSON-streng på minst 1 kB. Størrelsen avhenger av antall aggregerte hendelser i løpet av timinuttersintervallet. |
Her er en eksempelmelding:
{
"events": [
{
"event": "{\hostname\": \"test-machine\", \"event_type\": \"login_success\",
\"event_category\": \"node_events\", \"source\": \"mgmt\", \"session_data\":
{\"session_id\": \"j02wH5uFTKB22SqdYCrzPrqDWkXIAKCz\", \"referer\":
\"https://IP address/signIn.html?%2Fsetup\", \"url\":
\"https://IP address/api/v1/auth/signIn\", \"user_name\": \"admin\",
\"remote_address\": \"IP address\", \"user_agent\": \"Mozilla/5.0
(Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko)
Chrome/87.0.4280.67 Safari/537.36\"}, \"event_data\": {\"type\": \"Conf_UI\"},
\"boot_id\": \"6738705b-3ae3-4978-8502-13b74983e999\", \"timestamp\":
\"2020-12-07 22:40:27 (UTC)\", \"uptime\": 358416.23, \"description\":
\"Log in to Console or Web UI successful\"}"
},
{
"event": "{\hostname\": \"test-machine\", \"event_type\":
\"software_update_completed\", \"event_category\": \"node_events\", \"source\":
\"mgmt\", \"event_data\": {\"release_tag\": \"2020.12.04.2332m\"}, \"boot_id\":
\"37a8d17a-69d8-4b8c-809d-3265aec56b53\", \"timestamp\":
\"2020-12-07 22:17:59 (UTC)\", \"uptime\": 137.61, \"description\":
\"Completed software update\"}"
}
]
}Webhooks for videonettvarsler
Video Mesh støtter Webhook-varsler som gjør det mulig for organisasjonsadministratorer å motta varsler om bestemte hendelser. Administratorer kan velge å bli varslet om hendelser som anropsoverflyt og anropsomdirigeringer, noe som minimerer behovet for å logge på Control Hub for å overvåke distribusjonen. Dette oppnås ved å opprette et webhook-abonnement der en mål-URL oppgis av administratoren, som varsler vil bli sendt til. Bruk av webhooks for varsler tillater også overvåking av parametere uten å bruke de tilknyttede utvikler-API-ene.
Følgende hendelsestyper kan overvåkes via webhooks:
Omdirigeringer av klyngeanrop – Samtaler omdirigert fra en bestemt klynge.
Organisasjonsanropsoverflyt – Totalt antall samtaleoverflyt til skyen for en organisasjon.
Opprett et Webhook-abonnement
| 1 | Logg på Cisco Webex utvikler portal ved hjelp av administratorlegitimasjon. |
| 2 | På utviklerportalen klikker du på Dokumentasjon. |
| 3 | Fra rullefeltet til venstre blar du ned og klikker Fullstendig API-referanse . |
| 4 | Fra alternativene som vises nedenfor, blar du ned og klikker Webhooks > Opprett en Webhook. |
| 5 | Opprett et abonnement ved å angi følgende parametere: |
navn : eksempel – Video Mesh Webhook-varsler
targetUrl : eksempel - https://10.1.1.1/webhooks
ressurs : videoMeshAlerts
hendelsen : utløst
eidAv : org
| URL-adressen som angis i targetUrl-parameteren, må være tilgjengelig for Internett og ha en server som er konfigurert til å godta POST-forespørsler sendt av Webex Webhook. |
Angi terskelkonfigurasjoner med utvikler-API-er
Du kan angi terskelverdier for hendelsene (Org Call Overflows og Cluster Call Redirects) med utvikler-API-er for Video Mesh. Du kan angi en prosentverdi for tersklene som et webhook-varsel skal utløses over. Hvis terskelverdi for eksempel er satt til 20 for organisasjonssamtaleoverflyt, sendes det et varsel når mer enn 20 prosent av samtalene renner over til skyen.
Et sett med fire API-er er tilgjengelige for innstilling og oppdatering av terskler i Cisco Webex Developer Portal, og de er listet opp nedenfor:
Konfigurasjon av listehendelsesterskel
Hent konfigurasjon av hendelsesterskel
Oppdater konfigurasjon for hendelsesterskel
Tilbakestill konfigurasjon av hendelsesterskel
API-ene er tilgjengelige påhttps://developer.webex.com/docs/api/v1/video-mesh .
Scenario 1 – angi terskelverdi for organisasjonssamtaler overflyt
| 1 | Klikk på Konfigurasjon av listehendelsesterskel API. | ||
| 2 | Angi | ||
| 3 | Du vil motta et svar som ligner på det vist nedenfor. | ||
| 4 | Kopier verdien i | ||
| 5 | Lim inn verdien i | ||
| 6 | Klikk på Oppdater konfigurasjon for hendelsesterskel API. | ||
| 7 | Lim inn JSON-strukturen i brødteksten til Oppdater konfigurasjon for hendelsesterskel API. | ||
| 8 | Angi | ||
| 9 |
Klikk på Kjør , terskelen din for Organisasjonsanropsoverflyt settes til den nye verdien. |
Hva nå?
Hvis du vil vise terskelen som er angitt for en bestemt hendelsesterskel-ID,
Klikk på Hent konfigurasjon av hendelsesterskel API.
Lim inn hendelsesterskel-ID-en i toppteksten for API-en, klikk Kjør .
Standard terskelverdi og den angitte terskelverdi vises i svaret.
Scenario 2 – Angi terskelverdi for klyngesamtaler omdirigert
| 1 | Klikk på Konfigurasjon av listehendelsesterskel API. | ||
| 2 | Angi | ||
| 3 | Svaret viser konfigurasjoner for alle klynger i organisasjonen. | ||
| 4 |
Kopier verdien i | ||
| 5 | Lim inn verdien i | ||
| 6 | Klikk på Oppdater konfigurasjon for hendelsesterskel API. | ||
| 7 | Lim inn JSON-strukturen i brødteksten til Oppdater konfigurasjon for hendelsesterskel API. | ||
| 8 | Angi | ||
| 9 |
Klikk på Kjør , terskelen din for Klyngesamtaler omdirigert settes til den nye verdien. |
Hva nå?
Hvis du vil vise terskelen som er angitt for en bestemt hendelsesterskel-ID,
Klikk på Hent konfigurasjon av hendelsesterskel API.
Lim inn hendelsesterskel-ID-en i toppteksten for API-en, klikk Kjør .
Standard terskelverdi og den angitte terskelverdi vises i svaret.
Scenario 3 – Tilbakestilling av terskelverdier
| 1 | Klikk på Tilbakestill konfigurasjon av hendelsesterskel API. | ||
| 2 | Kopier hendelsesterskel-ID-en for en klynge eller organisasjonen, og lim den inn i | ||
| 3 | Lim inn JSON-strukturen i brødteksten og klikk Kjør . | ||
| 4 |
terskelverdi settes til standard minimumsverdi. |
Utvikler-API-er for videonett
Utvikler-API-ene for Video Mesh er en måte å hente analyse- og overvåkingsdata for Video Mesh-distribusjonene via Webex Developer Portal. API-ene er tilgjengelige påhttps://developer.webex.com/docs/api/v1/video-mesh. En prøveklient er tilgjengelig påhttps://github.com/CiscoDevNet/video-mesh-api-client .
Demoprogramvare for videonettnode
Bruk demoprogramvaren for videonettnode kun til grunnleggende demoformål. Ikke legg til en demo-node i en eksisterende produksjonsklynge. Demo-klyngen godtar færre anrop enn produksjon og utløper 90 dager etter at den er registrert i skyen.
|
|
Last ned bildet av demoprogramvaren fra denne koblingen .
Spesifikasjoner
Se System- og plattformkrav for programvare for videonettnode for den spesifikasjonsbaserte konfigurasjonen for programvaren videonettnode .
Demoprogramvaren støtter enten ett enkelt nettverksgrensesnitt eller et to nettverksgrensesnitt.
Kapasitet
Vi tester ikke demobildet for kapasitet. Du bør bare bruke den til å teste ut grunnleggende møtescenarier. Se brukstilfellene som følger for veiledning.
Bruksområder for demoprogramvaren for videonettnode
- Medier forankret til lokalt
-
Distribuer og konfigurer noden med demoprogramvaren.
Kjør et møte som inkluderer følgende deltakere: en Webex-app-deltaker, Webex-endepunktdeltaker og et Cisco Webex Board.
Etter at møtet er over, kan du se fra kundenhttps://admin.webex.com , gå til Analyse for å få tilgang til videonett-rapportene. I rapportene kan du se at mediene forble lokale.
- Møte med deltakere i skyen og lokale
-
Kjør et nytt møte med et par Webex-deltakere lokale og én i skyen.
Vær oppmerksom på at alle deltakerne sømløst kan bli med og delta i møtet.
Behandle videonettnode fra konsollen
Før du kan gjøre nettverksendringer i Video Mesh-noder som er registrert i skyen, må du bruke Control Hub til å sette dem i vedlikeholdsmodus. Hvis du vil ha mer informasjon og en fremgangsmåte som må følges, se Flytt en node til vedlikeholdsmodus .
| Vedlikeholdsmodus er kun ment å forberede en node for avslutning eller omstart, slik at du kan gjøre bestemte endringer i nettverksinnstillinger (DNS, IP, FQDN) eller forberede deg på maskinvarevedlikehold, for eksempel bytte ut RAM, harddisk og så videre. Oppgraderinger skjer ikke når en node settes i vedlikeholdsmodus. |
Når du setter en node i vedlikeholdsmodus, foretar den en elegant avslutning av anropstjenester (stopper å godta nye anrop og venter i opptil 2 timer på at eksisterende anrop skal fullføres). Formålet med å avslutte anropstjenester på en elegant måte er å tillate omstart eller avslutning av noden uten å forårsake avbrutte anrop.
Endre nettverksinnstillinger for videonettnode i konsollen
Hvis nettverkstopologien endres, må du åpne konsollgrensesnittet for hver videonettnode og endre nettverksinnstillinger der. Det kan hende at du ser en advarsel om endring av nettverksinnstillinger, men du kan likevel lagre endringene i tilfelle du gjør endringer i nettverket etter at du har endret nodeinnstillingene for Videonett.
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten, og logg deretter på med administratorlegitimasjonen. Etter førstegangs oppsett av nettverksinnstillinger , og hvis videonettverket er tilgjengelig, kan du få tilgang til nodegrensesnittet via sikkert skall (SSH). | ||
| 2 | Velg alternativ fra hovedmeny i videonettnode 2 Rediger konfigurasjon og klikk deretter Velg . | ||
| 3 | Les meldingen om at samtalene avsluttes på videonettnode, og klikk deretter på Ja . | ||
| 4 | Klikk på Statisk , angi IP-adresse for det interne grensesnittet, Maske , Gateway , og DNS verdier for nettverket ditt.
| ||
| 5 | Angi organisasjonens NTP-server eller en annen ekstern NTP-server som kan brukes i organisasjonen. Når du har konfigurert NTP-server og lagret nettverksinnstillinger, kan du følge trinnene i Kontroller tilstanden til videonettnode fra konsoll for å bekrefte at klokken synkroniseres riktig gjennom de angitte NTP-serverne.
| ||
| 6 | (Valgfritt) Endre vertsnavnet eller domenet om nødvendig.
| ||
| 7 | Klikk på Lagre , og klikk deretter Lagre endringer og start på nytt . Under lagringen utføres DNS-validering hvis du oppga et domene. Det vises en advarsel hvis FQDN (vertsnavn og domene) ikke kan løses ved hjelp av de oppgitte DNS-server . Du kan velge å lagre ved å ignorere advarselen, men anrop fungerer ikke før FQDN kan løses til DNS-en som er konfigurert på noden. Etter at videonettnode har startet på nytt, trer endringene i nettverkskonfigurasjon i kraft. |
Endre passordfrasen for administrator for videonettnode
Bruk denne fremgangsmåten til å endre administrator (passordet) for videonettnoden i nodens konsoll.
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten eller SSH til en tilgjengelig IP-adresse, og logg deretter på med administratorlegitimasjonen. |
| 2 | Åpne og logg på VMware ESXi-konsollen til den virtuelle maskinen for Video Mesh-noden. |
| 3 | Velg alternativ på hovedmeny 3 Administrer passordfrase for administrator , deretter 1 Endre passordfrase for administrator , og klikk deretter Gå inn . |
| 4 | Les informasjonen på siden for utløpt passord, klikk på Gå inn , og klikk deretter på den igjen etter meldingen om passordutløpet. |
| 5 | Trykk på Enter. |
| 6 | Når du har logget ut av konsollen, går du tilbake til påloggingsskjermen, og deretter logger du på med administratorpålogging . Du blir bedt om å endre passordet ditt.
|
| 7 | For Gammelt passord , angi gjeldende passordfrase, og trykk deretter på Gå inn . |
| 8 | For Nytt passord , angi en ny passordfrase, og trykk deretter på Gå inn . |
| 9 | For Skriv inn nytt passord på nytt , skriv inn den nye passordfrasen på nytt, og trykk deretter på Gå inn . Meldingen «passord endret» vises, og deretter går du tilbake til påloggingsskjermen.
|
| 10 | Logg på med den nye administratorpålogging og passordfrasen (passord). |
Kjør et ping fra videonettnode for videonett
Du kan kjøre en ping fra grensesnittet for nodekonsollen for Video Mesh. Dette trinnet tester en destinasjon du angir, og ser om videonettnoden kan nå den.
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten eller SSH til en tilgjengelig IP-adresse, og logg deretter på med administratorlegitimasjonen. |
| 2 | Fra Video Mesh-nodekonsollen går du til 4 Diagnostikk , og velg deretter Ping . |
| 3 | I ping -feltet, angi en destinasjonsadresse du vil teste, for eksempel en IP-adresse eller vertsnavn, og klikk deretter på OK . Testen kjøres, og du ser en melding om vellykket ping eller feil. Hvis du får en feil, kontrollerer du målverdien du anga, og nettverksinnstillinger. |
Aktiver feilsøking av brukerkonto gjennom konsoll
Hvis støtte krever tilgang til Video Mesh-noden, kan du bruke konsollgrensesnittet til å midlertidig aktivere en feilsøkingsbrukerkonto , slik at støtte kan kjøre ytterligere feilsøking på noden.
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten eller SSH til en tilgjengelig IP-adresse, og logg deretter på med administratorlegitimasjonen. |
| 2 | Fra Video Mesh-nodekonsollen går du til 4 Diagnostikk , velg 2 Aktiver feilsøkingsbrukerkonto , og klikk på etter ledeteksten Ja . |
| 3 | Når det vises en melding om at brukerkonto ble opprettet, klikker du på OK for å vise den krypterte passordfrasen. Du sender den krypterte passordfrasen til support. De bruker denne midlertidige kontoen og dekrypterte passordfrasen for å få sikker tilgang til Video Mesh-noden for feilsøking. Denne kontoen utløper etter 3 dager, eller du kan deaktivere den når støtten er fullført. |
| 4 | Velg starten og slutten på de krypterte dataene, og kopier og lim dem inn i kundestøttebilletten eller e-posten du sender til kundestøtte. |
| 5 | Når du har sendt denne informasjonen til support, går du tilbake til nodekonsollen for videonett og trykker på en hvilken som helst tast for å gå tilbake til hovedmeny. |
Hva nå?
Kontoen utløper om 3 dager, men når støtte indikerer at de fullførte feilsøkingen på noden, kan du returnere nodekonsollen for Video Mesh, gå til 4 Diagnostikk , og velg deretter 3 Deaktiver feilsøkingsbrukerkonto for å deaktivere kontoen før den utløper.
Send logger fra videonettnode for videonett
Du kan bli bedt om å sende logger direkte til Cisco eller gjennom sikker kopi (SCP). Bruk denne fremgangsmåten til å sende logger direkte fra alle Video Mesh-noder du har registrert, til skyen.
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten eller SSH til en tilgjengelig IP-adresse, og logg deretter på med administratorlegitimasjonen. |
| 2 | Klikk på alternativ i hovedmeny 4 Diagnostikk og trykk deretter på Gå inn . |
| 3 | Klikk på 4 Eksporter loggfiler , gi tilbakemelding hvis du vil, og klikk deretter Neste . |
| 4 | Velg et alternativ:
|
| 5 | Velg OK for å gå tilbake til hovedmeny for Videonett-noden . |
| 6 | (Valgfritt) Velg 5 Kontroller status for loggfiler som er sendt til Cisco hvis du sendte loggene til Cisco. |
Hva nå?
 | Når du har sendt logger, anbefaler vi at du sender tilbakemelding direkte fra Webex-appen, slik at kundestøttekontaktene dine har all informasjonen de trenger for å hjelpe deg. |
Kontroller tilstanden til videonettnode fra konsoll
Du kan vise nodehelsen direkte fra selve videonettnoden. Resultatene er informative, men kan hjelpe med feilsøkingstrinn – hvis NTP-synkronisering for eksempel ikke fungerer, kan du kontrollere NTP-server i nettverksinnstillinger.
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten eller SSH til en tilgjengelig IP-adresse, og logg deretter på med administratorlegitimasjonen. |
| 2 | Fra Video Mesh-nodekonsollen går du til 4 Diagnostikk , og velg deretter 6 Kontroller nodens tilstand for å vise følgende informasjon om noden:
|
Konfigurer containernettverk på videonettnode
Videonett-noden reserverer et delnettområde for intern bruk i noden. Standardområdet er 172.17.42.0–172.17.42.63. Nodene svarer ikke på ekstern-til-video-nettnodetrafikk som kommer fra dette området. Det kan være lurt å bruke nodekonsollen til å endre IP-adresse for containerbroen for å unngå konflikter med andre enheter i nettverket.
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten eller SSH til en tilgjengelig IP-adresse, og logg deretter på med administratorlegitimasjonen. |
| 2 | Fra hovedmeny i nodekonsollen for Video Mesh går du til 4 Diagnostikk , og velg deretter 7 Konfigurer containernettverk . Etter advarselen som sier at aktive samtaler avsluttes på noden, klikker du Ja . |
| 3 | Endre verdiene for Container Bridge IP og Nettverksmaske , etter behov, og klikk deretter Lagre . Du får se et skjermbilde som viser nettverksinformasjonen for beholderen, inkludert IP-adresse som er reservert for interne operasjoner på videonett-noden. |
| 4 | Klikk på OK. |
Identifisere portproblemer med Reflector Tool i konsoll
Reflektorverktøyet (en kombinasjon av en server på Video Mesh-noden og klient gjennom et Python-skript) brukes til å bekrefte om de nødvendige TCP/UDP-portene er åpne fra Video Mesh-nodene.
Før du starter
Last ned en kopi av Reflector Tool Client (Python-skript) og pakke deretter ut filen til et sted som er lett å finne. Zip-filen inneholder skriptet og en readme-fil.
For at skriptet skal fungere som det skal, må du kontrollere at du kjører Python 2.7.10 eller nyere i miljøet ditt.
For øyeblikket støtter dette verktøyet SIP-endepunkter til videonettnoder og intraklyngebekreftelse.
| 1 | Fra kundevisningen ihttps://admin.webex.com , aktiver vedlikeholdsnoden for videonettnode ved å følge disse instruksjonene . |
| 2 | Vent til noden viser statusen Klar for vedlikehold i Control Hub. |
| 3 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten eller SSH til en tilgjengelig IP-adresse, og logg deretter på med administratorlegitimasjonen. |
| 4 | Fra grensesnittet for videonettnode går du til Diagnostikk > Reflector Server > Reflector Server for TCP eller (UDP) . Start serveren enten for TCP eller for UDP. |
| 5 | Bla til Refleksverktøy , og start deretter enten TCP Reflector Server eller UDP Reflector Server , avhengig av hvilken protokoll du vil bruke. |
| 6 | Klikk på Start Reflector Server , og vent deretter til serveren starter. Du ser et varsel når serveren starter. |
| 7 | Fra et system (for eksempel en PC) i et nettverk som du vil at Video Mesh-nodene skal nå, kjører du skriptet med følgende kommando:
På slutten av kjøringen viser klienten en vellykket melding hvis alle nødvendige porter er åpne:
Klienten viser en mislykket melding hvis noen nødvendige porter ikke er åpne:
|
| 8 | Løs eventuelle portproblemer på brannmuren, og kjør deretter trinnene ovenfor på nytt. |
| 9 | Kjør klienten med
|
Tilbakestill en videonettnode fra konsoll til fabrikkstandard
Som en del av oppryddingen av registreringen kan du tilbakestilling til fabrikkinnstillinger . Dette trinnet fjerner all konfigurasjon du satte på plass mens noden var aktiv, men fjerner ikke oppføringen for den virtuell maskin . Senere kan det være lurt å registrere denne noden på nytt som en del av en annen klynge du bygger fra bunnen av.
Før du starter
Du må bruke Control Hub til å avregistrere videonett-noden fra klyngen som er registrert i Control Hub.
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten eller SSH til en tilgjengelig IP-adresse, og logg deretter på med administratorlegitimasjonen. |
| 2 | Fra Video Mesh-nodekonsollen går du til 4 Diagnostikk , og velg deretter 8 Tilbakestilling til fabrikkinnstillinger . |
| 3 | Kontroller at du forstår informasjonen i merknaden som vises, og klikk deretter Tilbakestill . Noden starter automatisk på nytt etter tilbakestillingen til tilbakestilling til fabrikkinnstillinger. |
Overfør en eksisterende maskinvareplattform til videonettnode
Du kan overføre en eksisterende støttet plattform (for eksempel en CMS1000 som kjører Cisco Meeting Server) til Video Mesh. Bruk denne fremgangsmåten til å veilede deg gjennom overføringsprosessen.
| Trinnene varierer, avhengig av den medfølgende versjonen av ESXi på maskinvareplattform. |
Før du starter
Last ned en ny versjon av den nyeste versjonen Programvare for videonettnode bilde (OVA). Ikke distribuer en ny videonettnode med en tidligere nedlastet OVA.
| 1 | Logg på grensesnittet for den virtuell maskin , og avslutt deretter programvaren som kjører på plattformen. |
| 2 | Slett programvaren som kjørte på plattformen. Det må ikke være noen programvarebilder igjen på plattformen. Du kan heller ikke kjøre nodeprogramvare for Video Mesh sammen med annen programvare på samme plattform.
|
| 3 | Distribuer en ny virtuell maskin fra en ny OVF- eller OVA-fil. |
| 4 | Angi et navn på den virtuell maskin, og velg OVA-filen for videonettnoden. |
| 5 | Endre diskklargjøring til Tykk. |
| 6 | Last opp mfusion.ova programvarebilde du lastet ned.
|
| 7 | Når den virtuell maskin kjører, går du tilbake til Logg på videonettnode og fortsett den første konfigurasjonen av Video Mesh-noden. |
Funksjonssammenligning og overføringsbane fra samarbeidsmøterom-hybrid til videonett
Sammenligning av funksjoner
Funksjon | Videonett og Cisco Webex Meeting Center -video | CMR Hybrid |
|---|---|---|
Møtetyper | Planlagt Ett klikk (øyeblikkelig) Personlig møte (PMR) Konsekvent opplevelse for lokaler og skybaserte møter | Kun planlagt |
Planlegging | Webex-produktivitetsverktøy (Windows og Mac) Hybridkalenderplanlegging med @webex Webex-portal | Webex-aktiverte TelePresence- Produktivitetsverktøy for Windows og Mac TMS-planlegging |
Alternativer for å bli med i møte | Oppringing og Utringing PIN-beskyttet (vert) Énknapp å trykke på (OBTP) | Kun innringing OBTP |
Opplevelse i møtet | Unified Roster (Webex-klient) Samlede kontroller (Webex-klient) Lås/lås opp møte Demp/slå på demping av TelePresence-deltakere | Ingen enhetlig liste (Webex-klient og TelePresence Server) Separate kontroller (Webex-klient og TelePresence Server) |
Kapasitet og distribusjonsmodell | Ubegrenset kapasitet Lokal og automatisk overflyt Bytting og omkoding | Transkodingskapasiteten er begrenset til TelePresence-serveren |
Sjekkliste for overføringsbane
Nedenfor finner du en oversikt på høyt nivå over hvordan du overfører et eksisterende nettsted til videoplattform versjon 2.0 og klargjør nettstedet for integrering med Video Mesh. Fremgangsmåten kan variere, avhengig av det eksisterende miljøet. Jobb med partneren din eller kundesuksessansvarlig for å sikre en jevn overføring.
Kontroller at funksjonen for videokonferanse i Meeting Center er klargjort på Webex-nettsted.
Nettstedsadministratoren mottar administrasjonsportalkontoen sin. Administratoren distribuerer deretter videonettnoder for Webex-organisasjonen.
Nettstedsadministratoren tilordner CMR-rettigheten for å aktivere alle eller noen CMR Hybrid -hybridbrukere med Cisco Webex Meeting Center -video.
(Valgfritt) Deaktiver økttypen for CMR Hybrid for dette delsettet, og aktiver deretter Cisco Webex Meeting Center -video i brukerprofil.
Nettstedsadministratoren konfigurerer videonett, og velger deretter Hybrid som medieressurs under Alternativer for møterom for skysamarbeid .
Nettstedsadministratoren konfigurerer den lokale TelePresence Management Suite (TMS) og One Button to Push (OBTP) til å fungere med Cisco Webex Meeting Center -video. Se Distribusjonsveiledning for Cisco Webex Meeting Center -videokonferanser for bedrifter for veiledning.
Når CMR-rettigheten er aktivert for en bruker, bruker Webex- Produktivitetsverktøy som standard Cisco Webex Meeting Center -videoversjonen. Alle nye møter som er planlagt av brukerne, er Cisco Webex Meeting Center -videomøter.
Hvis konferanserom er inkludert i invitasjonen, sendes OBTP-informasjon til konferanserommet via TMS (kun for CMR Hybrid -hybridmøter).
Eksisterende møter som ble konfigurert av CMR Hybrid -brukere før de ble byttet til Cisco Webex Meeting Center -video, skal fortsette å fungere så lenge kunden beholder de lokale MCU- og TMS-innstillingene.
Eksisterende CMR Hybrid -hybridmøter kan ikke endres eller oppdateres for å gjenspeile informasjonen om Cisco Webex Meeting Center -videomøte. Hvis brukere vil bruke en ny invitasjon, må de slette de gamle møtene og opprette nye møter.
Hvis kunden ønsker å avvikle den lokale MCU-en, TMS-en, fungerer ikke gamle CMR Hybrid . Nye møter med Cisco Webex Meeting Center Videoinformasjon må opprettes.
TelePresence-interoperabilitetsprotokoll og segmentbytte
Videonett støtter forhandling av TelePresence Interoperability Protocol (TIP) og multiplex (MUX) for både 1-skjerms og 3-skjerms IX- og TX-endepunkter.
For endepunkter med tre skjermer skal alle tre skjermene vise video hvis det er nok deltakere i konferansen. Et annet system med tre skjermer i konferansen resulterer i segmentbytte i stedet for rombytte. Dette betyr at i stedet for at alle tre skjermene blir store når noen i et annet system med tre skjermer snakker, blir bare den aktive ruten stor. De to andre rutene fylles ut av video fra andre systemer. Når den er liten, gjengis alle tre rutene sammen (for alle enheter, én eller tre skjermer) med én avgrensningsramme og navneetikett.
Avhengig av vertsressursene i skyen, vil noen endepunkter vise alle de tre skjermene i et rom med tre skjermer i filmstripen, mens andre bare viser én rute. Webex-appen viser bare én rute, selv om mediet er lokalt.
For store møter som flyter over fra én node og gjennomgriper til en andre, vises det samme av alle endepunkter som er vert på en annen node enn den som er vert for systemet med tre skjermer (kun én rute er synlig i oppsettet). Presentasjonsdeling krever at BFCP forhandles gjennom anropsbanen.
Ny og endret informasjon
Denne tabellen dekker nye funksjoner eller funksjoner, endringer i eksisterende innhold og eventuelle større feil som ble rettet i Distribusjonsveiledning .
Hvis du vil ha informasjon om programvareoppdateringer for Webex Video Mesh-noden, kan du sehttps://help.webex.com/en-us/article/jgobq2/Webex-Video-Mesh-release-notes .
Dato | Endre |
|---|---|
9. februar 2024 |
|
31. august 2023 |
|
31. juli 2023 |
|
28. juli 2023 |
|
15. juni 2023 |
|
| 16. mai 2023 |
|
27. mars 2023 |
|
2. mars 2023 |
|
7. juli 2022 |
|
30. juni 2022 | La til informasjon om de nye masseklargjøringsskriptene påhttps://github.com/CiscoDevNet/webex-video-mesh-node-provisioning . |
14. juni 2022 | Endret trinn for å utveksle sertifikatkjeder for å inkludere ECDSA-sertifikater i Utveksle sertifikatkjeder mellom Unified CM og videonettnoder |
18. mai 2022 | Endret nedlastingsnettstedet for Reflector Tool tilhttps://github.com/CiscoDevNet/webex-video-mesh-reflector-client . |
29. april 2022 | La til informasjon om den nye funksjonen i Oppbevar mediene dine i videonett for alle eksterne Webex-møter . |
25. mars 2022 | Oppdateringer av portbruk i Porter og protokoller for administrasjon . |
10. desember 2021 | Lagt til CMS 2000 og registrerte oppgraderingsproblem for eldre CMS 1000s ved oppgradering til ESXi 7 i System- og plattformkrav for programvare for videonettnode . |
30. august 2021 | La til informasjon om å bekrefte at Webex har riktig kildeland for distribusjonen i Kontroller at kildelandet er riktig . |
27. august 2021 | La til merknad om analyserapporters synlighet i Støtte og begrensninger for private møter . |
13. august 2021 | La til informasjon om den nye private møter-funksjonen i:
|
22. juli 2021 | La til informasjon om hvordan du bekrefter at systemet har riktig kildeplassering for samtaler. Riktige kildeplasseringer bidrar til effektiv ruting. Se Kontroller at kildelandet er riktig . |
25. juni 2021 | Merket at funksjonen for Webex Experience med alle funksjoner i Webex-appen er inkompatibel med Video Mesh i Klienter og enheter som bruker videonettnode . |
7. mai 2021 | Rettet den anbefalte klyngestørrelsen til 100 tommer Retningslinjer for distribusjon av videonettklynge . |
12. april 2021 | Oppdatert Konfigurer Expressway TCP SIP-trafikkruting for videonett for å bruke Webex-sonen i stedet for en ny DNS-sone. |
09. februar 2021 |
|
11. desember 2020 |
|
22. oktober 2020 |
|
| 19. oktober 2020 |
|
| 18. september 2020 |
|
| 26. august 2020 |
|
4. august 2020 |
|
| 9. juli 2020 |
|
26. juni 2020 |
|
| 9. juni 2020 |
|
| 21. mai 2020 | Oppdatert Porter og protokoller for administrasjon og Krav for proxy-støtte for videonett . |
| 15. mai 2020 | Oppdatert Oversikt over videonett . |
| 25. april 2020 |
|
22. januar 2020 |
|
12. desember 2019 |
|
10. desember 2019 |
|
4. november 2019 |
|
| 18. oktober 2019 |
|
26. september 2019 |
|
13. september 2019 |
|
| 29. august 2019 |
|
24. juli 2019 |
|
9. juli 2019 |
|
24. mai 2019 |
|
25. april 2019 |
|
11. april 2019 |
|
Oversikt over Webex-videonett
Med Webex-videonett kan du finne den optimale blandingen av lokale ressurser og ressurser for skykonferanser på en dynamisk måte. Lokale konferanser blir på stedet når det er nok lokale ressurser. Når lokale ressurser er oppbrukt, overføres konferanser til skyen.
videonettnode er programvare som installeres på en lokal Cisco UCS -server, registrert i skyen og administrert i Control Hub. Webex-møter, Webex personlig møterom, Webex Space Meetings og Webex-appen mellom to personer kan rutes til de lokale nettbaserte videonettnodene. Videonett velger den mest effektive måten å bruke de tilgjengelige ressursene på.
Videonett gir disse fordelene:
Forbedrer kvaliteten og reduserer ventetiden ved å la deg holde samtaler lokalt.
Sender samtalene dine til skyen når lokale ressurser har nådd grensen eller er utilgjengelige.
Administrer videonettklyngene dine fra skyen med ett enkelt administrativt grensesnitt: Control Hub (https://admin.webex.com ).
Optimaliser ressurser og kapasitet etter behov.
Kombinerer funksjonene til nettskybaserte og lokale konferanser i en sømløs brukeropplevelse.
Reduserer kapasitetsproblemer, fordi skyen alltid er tilgjengelig når det er behov for ytterligere konferanseressurser. Du trenger ikke å planlegge kapasitet for «verste tilfelle»-situasjoner.
Gir avansert rapportdata av kapasitet og bruk og feilsøkingsrapportdata ihttps://admin.webex.com .
Bruker lokal mediebehandling når brukere ringer inn til et Webex-møte fra lokale standardbaserte SIP-endepunkter og -klienter:
SIP-baserte endepunkter og klienter (Cisco-endepunkter, Jabber, tredjeparts SIP), registrert til lokal samtalekontroll (Cisco Unified Communications Manager eller Expressway), som kaller inn til et Cisco Webex møte.
Webex-app (inkludert paret med romenheter) som blir med i et Webex-møte.
Webex rom- og skrivebordsenheter som blir direkte med i et Webex-møte.
Tilbyr optimalisert interaktiv talerespons (IVR) for lyd og video til SIP-baserte endepunkter og klienter på nettet.
Endepunkter for H.323, IP-innringning og Skype for Business (S4B) fortsetter å bli med i møter fra skyen.
Støtter 1080p 30fps HD-video som et alternativ for møter, hvis møtedeltakere som kan støtte 1080p er vert via de lokale lokale videonettnodene. (Hvis en deltaker blir med i et pågående møte fra skyen, fortsetter lokale brukere å oppleve 1080p 30 bps på støttede endepunkter.)
Forbedret og differensiert QoS-merking (Quality of Service): separat lyd (EF) og video (AF41).
Webex Video Mesh støtter for øyeblikket ikke Webex Webinars.Støtter ende-til-ende-krypterte møter (E2EE-møter). Hvis en kunde distribuerer Video Mesh og velger møtetypen E2EE, legger det til et ekstra sikkerhetslag, noe som sikrer at dataene (medier, filer, tavler, merknader) forblir sikre og blokkerer tredjeparter fra å få tilgang til eller endre dem. Hvis du vil detaljert informasjon, se Distribuer Zero-Trust Meetings .
Private møter støtter for øyeblikket ikke ende-til-ende-kryptering.
Klienter og enheter som bruker videonettnode
Vi bestreber oss på å gjøre Video Mesh interoperabel med relevante klienter og enhetstyper. Selv om det ikke er mulig å teste alle scenarier, dekker testingen som disse dataene er basert på, de fleste vanlige funksjonene til de oppførte endepunktene og infrastrukturen. Fraværet av en enhet eller klient innebærer mangel på testing og mangel på offisiell støtte fra Cisco.
Klient- eller enhetstype | Bruker videonettnode på punkt-til-punkt-anrop | Bruker videonettnode på møte med flere |
|---|---|---|
Webex-app (skrivebord og mobil) | Ja | Ja |
Webex-enheter, inkludert romenheter og Webex Board. (Se Krav til endepunkter og Webex-app delen for en fullstendig liste.) | Ja | Ja |
Trådløs deling på rommet mellom Webex-appen og støttede rom-, skrivebord- og tavleenheter. | Ja | Ja |
Unified CM-registrerte enheter (inkludert IX-endepunkter) og klienter (inkludert Jabber VDI 12.6 og nyere, og Webex VDI 39.3 og nyere), som ringer inn til et planlagt Webex-møte eller et Webex Personal Room-møte.* | Nei | Ja |
VCS/Expressway-registrerte enheter som ringer inn til et planlagt Webex-møte eller et Webex Personal Room-møte.* | Nei | Ja |
Webex Ring Mitt videosystem til Webex skyregistrerte videoenheter | N/A | Ja |
Webex App-nettklient (https://web.webex.com ) | Ja | Ja |
Telefoner registrert for Cisco Webex Calling | Nei | Nei |
Webex Ring Mitt videosystem til lokalt registrerte SIP-enheter | N/A | Nei |
* Det er ikke mulig å garantere at alle lokale enheter og klienter har blitt testet med Video Mesh-løsningen.
Inkompatibilitet med videonett med Webex Experience med alle funksjoner
Hvis du aktiverer Webex Experience med alle funksjoner for Webex-appen, støttes ikke Webex-appen med videonettnodene. Denne funksjonen sender for øyeblikket signalisering og medier direkte til Webex. Fremtidige utgivelser vil gjøre Webex-appen og videonettet kompatible. Som standard aktivert vi ikke denne funksjonen for kunder med Video Mesh.
Du kan ha problemer med videonett og den komplette Webex-opplevelsen:
Hvis du la til Video Mesh i distribusjonen etter introduksjonen av denne funksjonen.
Hvis du aktiverte den funksjonen uten å vite hvilken innvirkning det har på Video Mesh.
Hvis du merker problemer, kan du kontakte Cisco-kontoteamet for å deaktivere bryteren for alle funksjoner i Webex Experience.
Tjenestekvalitet på videonettnode
Videonettnoder overholder anbefalte anbefalte beste praksis for tjenestekvalitet (QoS) ved å aktivere portområder som lar deg skille mellom lyd- og videostrømmer i alle flyter til og fra videonettnodene. Denne endringen lar deg opprette QoS-policyer og effektivt merke trafikk til og fra videonettnodene.
Til disse portendringene følger QoS-endringer. Videomesh-noder merker automatisk medietrafikk fra SIP-registrerte endepunkter (lokal Unified CM eller VCS Expressway-registrert) for både lyd (EF) og video (AF41) separat med passende tjenesteklasse og bruker kjente portområder for bestemte medietyper .
Kildetrafikken fra de lokale registrerte endepunktene bestemmes alltid av konfigurasjonen på samtalekontroll (Unified CM eller VCS Expressway).
Hvis du vil ha mer informasjon, kan du se QoS-tabellen på Porter og protokoller som brukes av videonett og fremgangsmåten for å aktivere eller deaktivere QoS i Oppgaveflyt for distribusjon av videonett
Webex-appen fortsetter å koble til Video Mesh-noder over delt port 5004. Disse portene brukes også av Webex-appen og endepunkter for STUN-tilgjengelighetstester til Video Mesh-noder. Videonett-node til Videonett-node for overlappende enheter bruker målportområdet 10000–40000.Proxy-støtte for videonett
Videomesh støtter eksplisitte, gjennomsiktige proxyer for inspeksjon og ikke-inspeksjon. Du kan knytte disse proxyene til Video Mesh-distribusjonen, slik at du kan sikre og overvåke trafikk fra bedriften og ut til skyen. Denne funksjonen sender signal- og administrasjonsbasert https-trafikk til proxyen. For gjennomsiktige proxyer videresendes nettverksforespørsler fra videonettnoder til en bestemt proxy gjennom rutingsregler for bedriftsnettverk. Du kan bruke administratorgrensesnittet for Video Mesh for sertifikatbehandling og den generelle tilkoblingsstatusen etter at du har implementert proxyen med nodene.
| Medier beveger seg ikke gjennom proxyen. Du må fremdeles åpne de nødvendige portene for mediestrømmer for å nå skyen direkte. Se Porter og protokoller for administrasjon . |
Følgende proxy-typer støttes av videonett:
Eksplisitt proxy (inspeksjons eller ikke-inspeksjons) – Med eksplisitt proxy forteller du klienten (videonettnoder) hvilken proxy-server som skal brukes. Dette alternativet støtter én av følgende godkjenningstyper:
Ingen – Ingen ytterligere godkjenning er nødvendig. (For eksplisitt proxy for HTTP eller HTTPS.)
Grunnleggende – Brukes for en HTTP-brukeragent til å angi brukernavn og passord når du foretar en forespørsel, og bruker Base64-koding. (For eksplisitt proxy for HTTP eller HTTPS.)
Sammendrag – Brukes til å bekrefte identiteten til kontoen før sensitiv informasjon sendes, og bruker en hash-funksjon på brukernavnet og passordet før det sendes over nettverket. (For eksplisitt HTTPS-proxy.)
NTLM – I likhet med Digest brukes NTLM til å bekrefte identiteten til kontoen før sensitiv informasjon sendes. Bruker Windows-legitimasjon i stedet for brukernavn og passord. Denne godkjenningsplanen krever flere utvekslinger for å fullføre. (For eksplisitt HTTP-proxy.)
Gjennomsiktig proxy (ikke-inspeksjon) – Noder for videonett er ikke konfigurert til å bruke en bestemt proxy-serveradresse, og bør ikke trenge endringer for å fungere med en ikke-inspeksjons-proxy.
Gjennomsiktig proxy (inspeksjon) – Noder for videonett er ikke konfigurert til å bruke en bestemt proxy-serveradresse. Ingen konfigurasjonsendringer for http(s) er nødvendige på videonett, men nodene for videonett trenger et rotsertifikat for å kunne klarere proxyen. Inspeksjons-proxyer brukes vanligvis av IT til å håndheve retningslinjer om hvilke nettsteder som kan besøkes, og hvilke typer innhold som ikke er tillatt. Denne typen proxy dekrypterer all trafikken din (til og med HTTPS).
Støttede oppløsninger og bildefrekvenser for videonett
Denne tabellen dekker støttede oppløsninger og bildefrekvenser fra et avsender-mottaker-perspektiv i et møte som er vert på en videonett-node. Avsenderklienten (app eller enhet) er på tvers av den øverste raden i tabellen, mens mottakerklienten er i venstre kolonne i tabellen. Den tilsvarende cellen mellom de to deltakerne fanger opp den forhandlede innholdsoppløsningen, bilder per seksjon og lydkilde.
| Oppløsningen påvirker samtalekapasitet på en hvilken som helst videonettnoder. Hvis du vil ha mer informasjon, se Kapasitet for videonettnoder . |
Verdien for oppløsning og bildefrekvens kombineres som XXXpYY – for eksempel betyr 720p10 720p med 10 bilder per sekund.
Definisjonsforkortelsene (SD, HD og FHD) i avsenderraden og mottakerkolonnen refererer til den øvre oppløsningen til klienten eller enheten:
SD – standardoppløsning (576p)
HD – høy oppløsning (720p)
FHD – full høyoppløsning (1080p)
Mottaker | Avsender | ||||||
|---|---|---|---|---|---|---|---|
Webex-app | Webex-app for mobil | SIP-registrerte enheter (HD) | SIP-registrerte enheter (FHD) | Webex-registrerte enheter (SD) | Webex-registrerte enheter (HD) | Webex-registrerte enheter (FHD) | |
Webex-app på skrivebordet | 720p10 Blandet lyd* | 720p10 Blandet lyd | 720p30 Blandet lyd | 720p30 Blandet lyd | 576p15 Innholdslyd** | 720p30 Blandet lyd | 720p30 Blandet lyd |
Webex-app for mobil | — | — | — | — | — | — | — |
SIP-registrerte enheter (HD) | 720p30 Innholdslyd | 720p15 Blandet lyd | 1080p15 Blandet lyd | 1080p15 Blandet lyd | 576p15 Blandet lyd | 1080p15 Blandet lyd | 1080p15 Blandet lyd |
SIP-registrerte enheter (FHD) | 1080p30 Blandet lyd | 720p15 Blandet lyd | 1080p15 Blandet lyd | 1080p30 Blandet lyd | 576p15 Blandet lyd | 1080p15 Blandet lyd | 1080p30 Blandet lyd |
| Webex-registrerte enheter (SD) | 1080p15 Blandet lyd | 720p15 Blandet lyd | 1080p15 Blandet lyd | 1080p15 Blandet lyd | 576p15 Blandet lyd | 1080p15 Blandet lyd | 1080p15 Blandet lyd |
Webex-registrerte enheter (FHD) | 1080p30 Blandet lyd | 720p15 Blandet lyd | 1080p15 Blandet lyd | 1080p30 Blandet lyd | 576p15 Blandet lyd | 1080p15 Blandet lyd | 1080p30 Blandet lyd |
* Innholdslyd refererer til lyden som spilles av fra det bestemte innholdet som deles, for eksempel en strømming av video. Denne lydstrømmen er atskilt fra vanlig møtelyd.
** Blandet lyd refererer til en blanding av møtedeltaker lyd og lyd fra innholdsdelingen.
Krav for videonett
Videonett er tilgjengelig med tilbudene dokumentert i Lisenskrav for hybridtjenester .
Krav til samtalekontroll og møteintegrering for videonett
Samtalekontroll og eksisterende møteinfrastruktur er ikke nødvendig for å bruke Video Mesh, men du kan integrere de to. Hvis du integrerer Video Mesh med samtalekontroll og møteinfrastrukturen, må du kontrollere at miljøet oppfyller minimumskriteriene som er dokumentert i tabellen nedenfor.
Komponent Formål | Minimum støttet versjon |
|---|---|
Lokal samtalekontroll | Cisco Unified Communications Manager, versjon 11.5(1) SU3 eller nyere. (Vi anbefaler den nyeste SU-versjonen.) Cisco Expressway-C eller E, versjon X8.11.4 eller nyere. (Se delen «Viktig informasjon» i Versjonsmerknader for Expressway for mer informasjon.) |
Møteinfrastruktur | Webex Meetings WBS33 eller nyere. (Du kan bekrefte at Webex-nettsted ditt er på riktig plattform hvis listen Medieressurstype er tilgjengelig i nettstedsalternativene for møterom for skysamarbeid.)
Hvis du vil sikre at nettstedet ditt er klart for Video Mesh, kontakter du din kundesuksessansvarlige (CSM) eller partner. |
Håndtering av failover | Cisco Expressway-C eller E, versjon X8.11.4 eller nyere. (Se delen «Viktig informasjon» i Versjonsmerknader for Expressway for mer informasjon.) |
Krav til endepunkter og Webex-app
Komponent Formål | Detaljer |
|---|---|
Støttede endepunkter | |
Støttede versjoner av Webex-appen | Videomesh støtter Webex-appen for skrivebord (Windows, Mac) og mobil (Android, iPhone og iPad). Hvis du vil laste ned appen for en støttet plattform, går du tilhttps://www.webex.com/downloads.html . |
Støttede kodeker | Se Webex| Videospesifikasjoner for samtaler og møter for lyd- og videokodekene som støttes. Merk disse forbeholdene for videonett:
|
Støttede Webex-registrerte rom-, skrivebords- og tavleenheter | Følgende enheter er testet og bekreftet å fungere med Video Mesh-noder: |
System- og plattformkrav for programvare for videonettnode
Produksjonsmiljøer
I produksjonsdistribusjoner er det to måter å distribuere videonettnode programvare på en bestemt maskinvarekonfigurasjon:
Du kan konfigurere hver server som én virtuell maskin, noe som er best for distribusjoner som inkluderer mange SIP-endepunkter.
Ved hjelp av VMNLite-alternativet kan du konfigurere hver server med flere mindre virtuelle maskiner. VMNLite er best for distribusjoner der flertallet av klienter og enheter er Webex-app og Webex-registrerte endepunkter.
Disse kravene er felles for alle konfigurasjoner:
VMware ESXi 7 eller 8, vSphere 7 eller 8
Hyperthreading aktivert
Videonett-nodene som kjører uavhengig av plattformmaskinvaren, trenger dedikerte vCPU-er og RAM. Deling av ressurser med andre programmer støttes ikke. Dette gjelder for alle bilder av Video Mesh-programvaren.
For VMNLite-bilder (Video Mesh Lite) på en CMS-plattform støtter vi bare å ha VMNLite-bilder. Ingen andre Video Mesh-bilder eller ikke-Video Mesh-applikasjoner kan være på CMS-maskinvaren med VMNLite-programvaren.
Maskinvarekonfigurasjon | Produksjonsdistribusjon som én virtuell maskin | Produksjonsdistribusjon med virtuelle VMNLite-er | Merknader | ||
|---|---|---|---|---|---|
Cisco Meeting Server 1000 (CMS 1000) |
| Distribuer som 3 identiske virtuell maskin , hver med:
| Vi anbefaler denne plattformen for videonettnode.
| ||
Spesifikasjonsbasert konfigurasjon (2,6 GHz Intel Xeon E5-2600v3 eller nyere-prosessor kreves) |
| Distribuer som 3 identiske virtuell maskin , hver med:
| Hver virtuell maskin for Video Mesh må ha CPU, RAM og harddisker reservert for seg selv. Bruk enten CMS1000 eller VMNLite alternativet under konfigurasjonen. Topp IOP-er (inndata-/utdataoperasjoner per sekund) for NFS-lagring er 300 IOPS. | ||
Cisco Meeting Server 2000 (CMS 2000) | Distribuer som 8 identiske virtuell maskin , hver med:
| Distribuer som 24 identiske virtuell maskin , hver med:
| Vi anbefaler denne plattformen for videonettnode. Hvert blad må være en komplett Cisco Meeting Server 1000 med reservert CPU, RAM og harddisker per blad. Topp IOP-verdier for NFS-lagring er 300 IOPS. |
Demomiljøer
For grunnleggende demoformål kan du bruke en spesifikasjonsbasert maskinvarekonfigurasjon, med følgende minimumskrav:
14vCPU-er (12 for videonettnode, 2 for ESXi)
8 GB hovedminne
20 GB lokal harddiskplass
2,6 GHz Intel Xeon E5-2600v3 eller nyere-prosessor
| Denne konfigurasjonen av Video Mesh støttes ikke av Cisco TAC . |
Hvis du vil ha mer informasjon om demoprogramvaren, se Demoprogramvare for videonettnode .
Krav til båndbredde
Videonettnoder må ha en minimumsbåndbredde til Internett på 10 Mbps for at både opplasting og nedlasting skal fungere som den skal.
Krav for proxy-støtte for videonett
Vi støtter offisielt følgende proxy-løsninger som kan integreres med Video Mesh-nodene dine.
Cisco Web Security Appliance (WSA) for gjennomsiktig proxy
Squid for eksplisitt proxy
For en eksplisitt proxy eller gjennomsiktig inspeksjons-proxy som inspiserer (dekrypterer trafikk), må du ha en kopi av proxyens rotsertifikat som du må laste opp til klareringslageret for Video Mesh-noden i webgrensesnitt.
Vi støtter følgende eksplisitte kombinasjoner av proxy- og godkjenningstyper:
Ingen godkjenning med http og https
Enkel godkjenning med http og https
Sammendragsgodkjenning kun med https
NTLM-godkjenning kun med http
For gjennomsiktige proxyer må du bruke ruteren/bryteren til å tvinge HTTPS/443-trafikk til å gå til proxyen. Du kan også tvinge Web Socket til å gå til proxy. (Web Socket bruker https.)
Video Mesh krever web-socket-tilkoblinger til skytjenester, slik at nodene fungerer som de skal. På eksplisitt inspeksjons- og transparente inspeksjons proxyer kreves http-hoder for en riktig websocket-tilkobling. Hvis de endres, vil websocket-tilkoblingen mislykkes.
Når websocket- tilkoblingsfeil oppstår på port 443 (med transparent inspeksjons-proxy aktivert), fører det til en advarsel etter registrering i Control Hub: «SIP-anrop for Webex-videonett fungerer ikke som det skal.» Den samme alarmen kan oppstå av andre årsaker når proxy ikke er aktivert. Når websocket-overskrifter blokkeres på port 443, flyter ikke medier mellom apper og SIP-klienter.
Hvis mediet ikke flyter, skjer dette ofte når https-trafikk fra noden over port 443 svikter:
Port 443-trafikk er tillatt av proxyen, men det er en inspeksjons proxy og bryter websocket.
For å løse disse problemene må du kanskje «omgå» eller «skjøte» (deaktivere inspeksjon) på port 443 til: *.wbx2.com og *.ciscospark.com.
Kapasitet for videonettnoder
Siden Video Mesh er et programvarebasert medieprodukt, varierer kapasiteten til Video Mesh-nodene. Spesielt legger møtedeltakere i Webex-skyen en tyngre belastning på nodene. Du får lavere kapasitet når du har flere overlappinger til Webex-skyen. Andre faktorer som påvirker kapasiteten er:
Enhetstyper og klienter
Videooppløsning
Nettverkskvalitet
Toppbelastning
Distribusjonsmodell
| Bruk av videonett påvirker ikke antall Webex-lisenser. |
Generelt sett dobler ikke kapasiteten ved å legge til flere noder i klyngen på grunn av kostnadene for å sette opp overlappende enheter. Bruk disse tallene som generell veiledning. Vi anbefaler følgende:
Test ut vanlige møtescenarier for distribusjonen din.
Bruk analysene i Control Hub for å se hvordan distribusjonen utvikler seg, og legg til kapasitet etter behov.
| Overflyt ved lavt samtalevolum (spesielt SIP-anrop som kommer lokalt) er ikke en sann refleksjon av skala. Videonettanalyse (under Kontroller Hub > Ressurser > Samtaleaktivitet ) angir anropsdelene som kommer fra lokalt. De angir ikke samtalestrømmene som kom inn gjennom overlappingen til videonett-noden for mediebehandling. Etter hvert som antall eksterne deltakere øker i et møte, øker gjennomgripende grupper og bruker lokale medieressurser på videonett-noden. |
Denne tabellen viser kapasitetsområder for forskjellige blandingsdeltakere og endepunkter på vanlige videonettnoder. Testingen vår inkluderte møter med alle deltakerne på den lokale noden og møter med en blanding av lokale deltakere og skydeltakere. Med flere deltakere på Webex-skyen kan du forvente at kapasiteten din faller i den nedre enden av området.
Scenario | Oppløsning | Deltakerkapasitet |
|---|---|---|
Møter med bare deltakere i Webex-appen | 720p | 100–130 |
1080p | 90–100 | |
Møter og 1-til-1-samtaler med bare deltakere i Webex-appen | 720p | 60–100 |
1080p | 90–100 | |
Møter med kun SIP-deltakere | 720p | 70–80 |
Møter med kun SIP-deltakere | 1080p | 30–40 |
Møter med Webex-appen og SIP-deltakere | 720p | 75–110 |
|
|
Kapasitet for VMNLite
Vi anbefaler VMNLite for distribusjoner som hovedsakelig inkluderer Webex-appen og skyregistrerte endepunkter. I disse distribusjonene bruker nodene mer svitsjing og færre transkodingsressurser enn standardkonfigurasjonen gir. Distribusjon av flere mindre virtuelle maskiner på verten optimaliserer ressursene for dette scenariet.
Denne tabellen viser kapasitetsområder for forskjellige blandinger av deltakere og endepunkter. Testingen vår inkluderte møter med alle deltakerne på den lokale noden og møter med en blanding av lokale deltakere og skydeltakere. Med flere deltakere på Webex-skyen kan du forvente at kapasiteten din faller i den nedre enden av området.
Scenario | Oppløsning | Deltakerkapasitet med 3 VMNLite-noder på en server |
|---|---|---|
Møter med bare deltakere i Webex-appen | 720p | 250–300 |
1080p | 230–240 | |
Møter og 1-til-1-samtaler med bare deltakere i Webex-appen | 720p | 175–275 |
1080p | 230–240 |
| Grunnoppløsningen for Webex-appmøter er 720p. Men når du deler, er deltakerminiatyrbildene på 180p. |
Klynger i videonett
Du distribuerer Video Mesh-noder i klynger. En klynge definerer videonettnoder med lignende attributter, for eksempel nettverksnærhet. Deltakerne bruker en bestemt klynge eller skyen, avhengig av følgende forhold:
En klient på et bedriftsnettverk som kan nå en lokal klynge, kobles til den – den primære preferansen for klienter på bedriftsnettverk.
Klienter som blir med i et privat møte med Video Mesh, kobles bare til lokale klynger. Du kan opprette en egen klynge spesielt for disse private møtene.
En klient som ikke kan nå en lokal klynge, kobles til skyen – tilfellet for en mobilenhet som ikke er koblet til bedriftsnettverk.
Den valgte klyngen avhenger også av ventetid, i stedet for bare plassering. For eksempel kan en skyklynge med lavere STUN-tur-retur-forsinkelse (SRT) enn en videonettklynge være en bedre kandidat for møtet. Denne logikken forhindrer en bruker i å lande på en geografisk fjern klynge med høy SRT-forsinkelse.
Hver klynge inneholder logikk som gjennomgriper møter, unntatt private møter i Video Mesh, på tvers av andre skymøteklynger, etter behov. Overlappende funksjoner gir en databane for medier mellom klienter i møtene sine. Møter er fordelt på tvers av noder, og klienter lander på den mest effektive noden nærmest dem, avhengig av faktorer som nettverkstopologi, WAN-kobling og ressursutnyttelse.
Klientens mulighet til å pinge medienoder avgjør tilgjengeligheten. Et faktisk anrop bruker en rekke potensielle tilkoblingsmekanismer, for eksempel UDP og TCP. Før samtalen registreres Webex-enheten (rom, skrivebord, tavle og Webex-app) med Webex-skyen, som gir en liste over klyngekandidater for samtalen.
| Nodene i en videonett-klynge krever uhindret kommunikasjon med hverandre. De krever også uhindret kommunikasjon med nodene i alle de andre videonett-klyngene. Kontroller at brannmurene tillater all kommunikasjon mellom videonettnodene. |
Klynger for private møter
Du kan reservere en videonett-klynge for private møter. Når den reserverte klyngen er full, overføres de private møtemediene til de andre videonett-klyngene dine. Når den reserverte klyngen er full, deler private møter og ikke-private møter ressursene til de gjenværende klyngene.
Ikke-private møter bruker ikke en reservert klynge, og disse ressursene reserveres for de private møtene. Hvis et ikke-privat møte går tom for ressurser på nettverket, overføres det til Webex-skyen i stedet.
Hvis du vil ha mer informasjon om funksjonen for private møter i videonett, se Private møter .
| Du kan ikke bruke adresseformatet for kort video (meet@your_site ) hvis du reserverer alle Video Mesh-klynger for private møter. Disse anropene mislykkes for øyeblikket uten en riktig feilmelding. Hvis du lar noen klynger være ureserverte, kan samtaler med formatet for korte videoadresser kobles til gjennom disse klyngene. |
Retningslinjer for distribusjon av videonettklynge
I typiske bedriftsdistribusjoner anbefaler vi at kunder bruker opptil 100 noder per klynge. Det er ingen faste grenser i systemet for å blokkere en klyngestørrelse med mer enn 100 noder. Hvis du imidlertid trenger å opprette større klynger, anbefaler vi på det sterkeste at du går gjennom dette alternativet med Cisco-teknologi gjennom ditt Cisco-kontoteam.
Opprett færre klynger når ressursene har lignende nettverksnærhet (tilhørighet).
Når du oppretter klynger, må du bare legge til noder som er i samme geografiske område og samme datasenter. Klynger over Wide Area Network (WAN) støttes ikke.
Vanligvis distribuerer du klynger i bedrifter som er vert for hyppige lokaliserte møter. Planlegg hvor du plasserer klynger på båndbredden som er tilgjengelig på forskjellige WAN-plasseringer i bedriften. Over tid kan du distribuere og vokse klynge for klynge basert på observerte brukermønstre.
Klynger som befinner seg i forskjellige tidssoner, kan effektivt betjene flere geografiske områder ved å dra nytte av forskjellige anropsmønstre med peak/ travel time .
Hvis du har to Video Mesh-noder i to separate datasentre (EU og NA, for eksempel), og du har endepunkter som kobles sammen gjennom hvert datasenter, vil nodene i hvert datasenter overlappe hverandre til én enkelt Video Mesh-node i skyen. Disse kaskader ville gå over Internett. Hvis det finnes en skydeltaker (som blir med før en av Video Mesh-deltakerne), vil nodene bli koblet gjennom skydeltakerens medianode.
Mangfold i tidssone
Mangfold mellom tidssoner kan tillate deling av klynger i dårlige perioder. For eksempel: Et selskap med en klynge i Nord-California og en klynge i New York kan oppleve at den samlede nettverksforsinkelsen ikke er så høy mellom de to stedene som betjener en geografisk variert brukergruppe. Når ressursbruken er på topp i Nord-California-klyngen, vil New York-klyngen sannsynligvis være lav og ha ekstra kapasitet. Det samme gjelder for Nord-California-klyngen, i rushtiden i New York-klyngen. Dette er ikke de eneste mekanismene som brukes for effektiv distribusjon av ressurser, men de er de to viktigste.
Overflyt til skyen
Når kapasiteten til alle lokale klynger er nådd, flyter en lokal deltaker over til Webex-skyen. Dette betyr ikke at alle samtaler er vert i skyen. Webex sender bare deltakerne som enten er eksterne eller ikke kan koble til en lokal klynge, til skyen. I en samtale med både lokale og skydeltakere, er den lokale klyngen koblet (overlappende) til skyen for å kombinere alle deltakerne til én enkelt samtale.
Hvis du konfigurerer møtet som den private møtetypen, beholder Webex alle samtalene i de lokale klyngene dine. Private møter flyter aldri over til skyen.
Webex-enhet registreres med Webex
I tillegg til å bestemme tilgjengelighet, utfører klientene også periodiske forsinkelsestester tur/retur ved hjelp av enkel gjennomkjøring av UDP gjennom NAT (STUN). STUN-tur-retur-forsinkelse (SRT) er en viktig faktor når du velger potensielle ressurser under en faktisk samtale. Når flere klynger distribueres, er de primære utvalgskriteriene basert på den lærte SRT-forsinkelsen. Tilgjengelighetstester utføres i bakgrunnen, initiert av en rekke faktorer, inkludert nettverksendringer, og introduserer ikke forsinkelser som påvirker tidspunktet for oppsett av samtaler. De følgende to eksemplene viser mulige resultater fra tester for nåbarhet.
Tester med forsinkelser tur/retur – skyenheten når ikke den lokale klyngen
Tester med forsinkelser tur/retur – skyenheten når den lokale klyngen
Lært tilgjengelighetsinformasjon leveres til Webex-skyen hver gang en samtale konfigureres. Denne informasjonen lar skyen velge den beste ressursen (klynge eller sky), avhengig av den relative plasseringen av klienten til tilgjengelige klynger og samtaletypen. Hvis ingen ressurser er tilgjengelige i den foretrukne klyngen, testes alle klyngene for tilgjengelighet basert på SRT-forsinkelse. En foretrukket klynge velges med lavest SRT-forsinkelse. Samtaler betjenes lokalt fra en sekundær klynge når den primære klyngen er opptatt. Lokale videonettressurser som kan nås, prøves først, i rekkefølge etter laveste SRT-forsinkelse. Når alle lokale ressurser er oppbrukt, kobler deltakeren seg til skyen.
Klyngedefinisjon og plassering er avgjørende for en distribusjon som gir den beste generelle opplevelsen for deltakerne. Ideelt sett bør en distribusjon gi ressurser der klientene befinner seg. Hvis det ikke er tildelt nok ressurser der klientene foretar de fleste samtalene, brukes mer intern nettverksbåndbredde for å koble brukere til fjerne klynger.
Lokal og skysamtale
Lokale Webex-enheter som har samme klyngetilhørighet (preferanse, basert på nærhet til klyngen), kobler til den samme klyngen for en samtale. Lokale Webex-enheter med forskjellige lokale klyngetilhørigheter kobles til forskjellige klynger, og klyngene deretter gjennomgripende til skyen for å kombinere de to miljøene til én enkelt samtale. Dette oppretter en hub- og taledesign med Webex-sky som hub og de lokale klyngene som fungerer som taler i møtet.
Lokal samtale med forskjellige klyngetilknytninger
Webex-enheten kobles til enten lokal klynge eller sky basert på tilgjengeligheten. Følgende viser eksempler på de vanligste scenariene.
Webex Cloud enhet kobles til skyen
Den lokale Webex-enheten kobles til den lokale klyngen
Lokal Webex-enhet kobles til skyen
Skyklyngevalg for overflyt basert på 250 ms eller høyere STUN tur-retur-forsinkelse
Selv om preferansen for nodevalg er de lokalt distribuerte Video Mesh-nodene, støtter vi et scenario der STUN-tur-retur-forsinkelsen til en lokal Video Mesh-klynge overskrider den tolererbare tur-retur forsinkelsen på 250 ms (som skjer vanligvis hvis den lokale klyngen er konfigurert på et annet kontinent), velger systemet den nærmeste skymedienoden i det geografiske området i stedet for en videonett-node.
Webex-appen eller Webex-enheten er på bedriftsnettverket i San Jose.
San Jose- og Amsterdam-klynger er fulle eller utilgjengelige.
SRT-forsinkelse til Shanghai-klyngen er større enn 250 ms og vil sannsynligvis føre til problemer med mediekvaliteten.
San Francisco-skyklyngen har en optimal SRT-forsinkelse.
Shanghai-videonett-klyngen er ekskludert fra vurdering.
Som et resultat av dette flyter Webex-appen over til San Francisco-skyklyngen.
Private møter
Private møter isolerer alle medier til nettverket ditt via Video Mesh. I motsetning til vanlige møter, hvis de lokale nodene er fulle, overføres ikke mediene til Webex-skyen. Men som standard kan private møter gå gjennom til forskjellige videonett-klynger på nettverket ditt. For private møter på tvers av geografiske steder må videonettklyngene dine ha direkte tilkobling til hverandre for å tillate overlappende klynger, for eksempel HQ1_ VMN til Remote1_ VMN i figuren.
Kontroller at de nødvendige portene er åpne i brannmuren, for å tillate uhindret overlapping mellom klynger. Se Porter og protokoller for administrasjon .
Alle deltakere i et privat møte må tilhøre møtevertens Webex-organisasjon. De kan bli med ved hjelp av Webex-appen eller et autentisert videosystem (SIP-endepunkter registrert på UCM/VCS eller Webex-registrert videoenhet). Deltakere med VPN- eller MRA-tilgang til nettverket ditt kan bli med i et privat møte. Men ingen kan bli med på et privat møte utenfor nettverket ditt.
Distribusjonsmodeller som støttes av videonett
- Støttes i en distribusjon av videonett
-
Du kan distribuere en videonettnode i enten et datasenter (foretrukket) eller i demilitarisert sone (DMZ). Hvis du vil ha veiledning, se Porter og protokoller som brukes av videonett .
For en DMZ-distribusjon kan du konfigurere videonettnodene i en klynge med det to nettverksgrensesnitt (NIC). Denne distribusjonen lar deg skille bedriftens interne nettverkstrafikk (brukes til interbokskommunikasjon, overlappende nodeklynger og for å få tilgang til nodens administrasjonsgrensesnitt) fra den eksterne skynettverkstrafikken (brukes for tilkobling til omverdenen og gjennomgripende til skyen).
Dobbelt nettverkskort fungerer på den fullstendige VMNLite- og demoversjonen av nodeprogramvaren for Video Mesh. Du kan også distribuere videonettet bak et 1:1 NAT-oppsett.
Du kan integrere Video Mesh-noder med samtalekontroll . For eksempel distribusjoner med Video Mesh integrert med Unified CM, se Distribusjonsmodeller for Video Mesh og Cisco Unified Communications Manager .
Følgende typer adresseoversettelse støttes:
Dynamisk oversettelse av nettverksadresse (NAT) ved hjelp av et IP-utvalg
Dynamisk oversettelse av portadresse (PAT)
1:1 NAT
Andre former for NAT skal fungere så lenge de riktige portene og protokollene brukes, men vi støtter ikke offisielt dem fordi de ikke har blitt testet.
IPv4
Statisk IP-adresse for videonettnode
- Støttes ikke i en distribusjon av videonett
-
IPv6
DHCP for videonettnode
En klynge med en blanding av enkelt og to nettverkskort
Klynger av videonettnoder over WAN (Wide Area Network)
Lyd, video eller medier som ikke går gjennom en videonettnode:
Lyd fra telefoner
Node-til-node-anrop mellom Webex-appen og standardbasert endepunkt
Lydavslutning på videonettnode
Medier sendt gjennom Expressway C/E-par
Videosamtale tilbakeringing fra Webex
Distribusjonsmodeller for Video Mesh og Cisco Unified Communications Manager
Disse eksemplene viser vanlige Video Mesh-distribusjoner og hjelper deg å forstå hvor Video Mesh-klynger kan passe inn i nettverket ditt. Husk at distribusjon av Video Mesh avhenger av faktorer i nettverkstopologien:
Steder for datasenter
Kontorplasseringer og størrelse
Sted og kapasitet for Internett-tilgang
Generelt kan du prøve å knytte Video Mesh-nodene til Unified CM eller SME-klynger ( Session Management Edition ). Som en beste praksis bør du holde nodene så sentralisert som mulig til de lokale avdelingene.
Video Mesh støtter SME ( Session Management Edition ). Unified CM -klynger kan kobles til via en SME, og deretter må du opprette en SME-trunk som kobles til Video Mesh-nodene.
Hub- og Spoke-arkitektur
Denne distribusjonsmodell innebærer sentralisert nettverk og Internett-tilgang. Det sentrale stedet har vanligvis høy konsentrasjon av ansatte. I dette tilfellet kan en videonett-klynge plasseres sentralt for optimalisert mediehåndtering.
Plassering av klynger i filialer vil kanskje ikke gi fordeler på kort sikt, og kan føre til suboptimal ruting. Vi anbefaler at du bare distribuerer klynger i en gren hvis det er hyppig kommunikasjon mellom grenene.
Geografisk distribusjon
Den geografisk distribuerte distribusjonen er sammenkoblet, men kan ha merkbar forsinkelse mellom regioner. Mangel på ressurser kan føre til at det settes opp suboptimale kaskader på kort sikt når det er møter mellom brukere på hvert geografisk sted. I denne modellen anbefaler vi at du tilordner videonettnoder i nærheten av regional Internett-tilgang.
Geografisk distribusjon med SIP-oppringing
Denne distribusjonsmodell inneholder regionale Unified CM -klynger. Hver klynge kan inneholde en SIP-trunk for å velge ressurser i den lokale videonett-klyngen. En andre trunk kan gi en failover-bane til et Expressway-par hvis ressursene blir begrenset.
Porter og protokoller som brukes av videonett
For å sikre en vellykket distribusjon av Video Mesh og for problemfri drift av Video Mesh-nodene, åpner du følgende porter på brannmuren for bruk med protokollene.
Se Nettverkskrav for Webex-tjenester for å forstå de generelle nettverkskravene for Webex Teams.
Se Hvitbok for gjennomgang av brannmur hvis du vil ha mer informasjon om brannmur- og nettverkspraksis for Webex-tjenester.
Hvis du vil redusere potensielle problemer med DNS-spørringer, følger du veiledningen Anbefalte fremgangsmåter for DNS, nettverksbeskyttelse og angrepsidentifikasjon dokumentasjonen når du konfigurerer bedriftens brannmur.
Hvis du vil ha mer designinformasjon, kan du se Foretrukket arkitektur for hybridtjenester, CVD .
Porter og protokoller for administrasjon
| Nodene i en videonett-klynge krever uhindret kommunikasjon med hverandre. De krever også uhindret kommunikasjon med nodene i alle de andre videonett-klyngene. Kontroller at brannmurene tillater all kommunikasjon mellom videonettnodene. |
Videonettnodene i en klynge må være i samme VLAN- eller nettverksmaske.
Hensikt | Kilde | Destinasjon | Kilde-IP | Kildeport | Transportprotokoll | Destinasjons-IP | Målport |
|---|---|---|---|---|---|---|---|
Administrasjon | Administrasjonsdatamaskin | Videonett-node | Etter behov | Hvilke som helst | TCP, HTTPS | Videonett-node | 443 |
SSH for tilgang til administrasjonskonsollen for Video Mesh | Administrasjonsdatamaskin | Videonett-node | Etter behov | Hvilke som helst | TCP | Videonett-node | 22 |
Intraklyngekommunikasjon | Videonett-node | Videonett-node | IP-adresse til andre Video Mesh-noder i klyngen | Hvilke som helst | TCP | Videonett-noder | 8443 |
Administrasjon | Videonett-node | Webex-sky | Etter behov | Hvilke som helst | UDP, NTP UDP, DNS TCP, HTTPS (WebSockets) | Hvilke som helst | 123* 53* |
Overlappende signalisering | Videonett-node | Webex-sky | Hvilke som helst | Hvilke som helst | TCP | Hvilke som helst | 443 |
Overlappende medier | Videonett-node | Webex-sky | Videonett-node | Alle*** | UDP | Hvilke som helst Hvis du vil ha spesifikke adresseområder, kan du se delen «IP-delnett for Webex Media-tjenester» i Nettverkskrav for Webex-tjenester . | 5004 50000 til 53000 Hvis du vil ha mer informasjon, kan du se delen «Webex-tjenester – portnumre og protokoller» i Nettverkskrav for Webex-tjenester . |
Overlappende signalisering | Vido-nettklynge (1) | Vido-nettklynge (2) | Hvilke som helst | Hvilke som helst | TCP | Hvilke som helst | 443 |
Overlappende medier | Vido-nettklynge (1) | Vido-nettklynge (2) | Vido-nettklynge (1) | Alle*** | UDP | Hvilke som helst | 5004 50000 til 53000 |
Administrasjon | Videonett-node | Webex-sky | Etter behov | Hvilke som helst | TCP, HTTPS | Alle** | 443 |
Administrasjon | Videonett-node (1) | Videonett-node (2) | Videonett-node (1) | Hvilke som helst | TCP, HTTPS (WebSockets) | Videonett-node (2) | 443 |
Intern kommunikasjon | Videonett-node | Alle andre videonettnoder | Videonett-node | Hvilke som helst | UDP | Hvilke som helst | 10000 til 40000 |
* Standardkonfigurasjonen i OVA er konfigurert for NTP og DNS. OVA krever at du åpner disse portene utgående til Internett. Hvis du konfigurerer en lokal NTP- og DNS-server, trenger du ikke å åpne portene 53 og 123 gjennom brannmuren.
** Siden enkelte nettadresser for nettskytjenester kan endres uten forvarsel, er ANY det anbefalte målet for problemfri drift av videonettnodene. Hvis du foretrekker å filtrere trafikk basert på nettadresser, kan du se Webex Teams-URL-adresser for hybridtjenester
delen av Nettverkskrav for Webex-tjenester hvis du vil ha mer informasjon.
***Portene varierer avhengig av om du aktiverer QoS. Med QoS aktivert er portene 52.500-59499, 63000-64667, 59500-62999 og 64688-65500. Med QoS av er portene 34.000–34.999.
Trafikksignaturer for videonett (tjenestekvalitet aktivert)
For distribusjoner der Video Mesh-noden befinner seg på bedriftssiden av DMZ eller i brannmuren, finnes det en konfigurasjonsinnstilling for videonettnode i Webex Control Hub som lar administrator optimalisere portområdene som brukes av videonettnode for QoS nettverksmerking. Denne innstillingen for tjenestekvalitet er aktivert som standard og endrer kildeportene som brukes til lyd-, video- og innholdsdeling til verdiene i denne tabellen. Denne innstillingen lar deg konfigurere retningslinjer for QoS-merking basert på UDP-portområder for å skille lyd fra video eller innholdsdeling og merke all lyd med anbefalt verdi på EF og Video og innholdsdeling med en anbefalt verdi på AF41.
Tabellen og diagrammet viser UDP-porter som brukes til lyd- og videostrømmer, som er hovedfokuset for QoS-nettverkskonfigurasjoner. Mens retningslinjer for nettverks- QoS-merking for medier over UDP er fokuset i tabellen nedenfor, avslutter Webex Video Mesh-noder også TCP-trafikk for presentasjon og innholdsdeling for Webex-app ved hjelp av flyktige porter 52500–65500. Hvis det er en brannmur mellom Video Mesh-nodene og Webex-app, må disse TCP-portene også tillates for at de skal fungere som de skal.
| videonettnode merker trafikk innebygd. Denne interne merkingen er asymmetrisk i noen flyter og avhenger av om kildeportene er delte porter (enkel port som 5004 for flere flyter til forskjellige destinasjoner og målporter) eller om de ikke er det (der porten faller i et område, men er unik for den spesifikke toveisøkten). Hvis du vil forstå den opprinnelige merkingen av en videonettnode, merker du at videonettnoden merker lyd EF når den ikke bruker 5004-porten som kildeport. Noen toveisflyter som overlappende videonett til videonett eller Videonett til Webex-appen vil være asymmetrisk merket, noe som er en grunn til å bruke nettverket til å merke trafikk basert på de oppgitte UDP-portområdene. |
| Kilde-IP-adresse | Destinasjons-IP-adresse | Kilde UDP-porter | UDP-målporter | Innebygd DSCP-merking | Mediatype |
Videonettnode | Webex skymedietjenester | 35000 til 52499 | 5004 | AF41 | Test STUN-pakker |
| Videonettnode | Webex skymedietjenester | 52500 til 59499 | 5004 | EF | Lyd |
| Videonettnode | Webex skymedietjenester | 63000 til 64667 | 5004 | AF41 | Video |
| Videonettnode | Webex skymedietjenester | 59500 til 62999 | 50 000 til 51499 | EF | Lyd |
| Videonettnode | Webex skymedietjenester | 64668 til 65500 | 51500 til 53000 | AF41 | Video |
| Videonettnode | Videonettnode | 10000 til 40000 | 10000 til 40000 | — | Lyd |
| Videonettnode | Videonettnode | 10000 til 40000 | 10000 til 40000 | — | Video |
| Videonettnode | Unified CM SIP-endepunkter | 52500 til 59499 | Unified CM SIP-profil | EF | Lyd |
| Videonettnode | Unified CM SIP-endepunkter | 63000 til 64667 | Unified CM SIP-profil | AF41 | Video |
Videonett-klynge | Videonett-klynge | 52500 til 59499 | 5004 | EF | Lyd |
Videonett-klynge | Videonett-klynge | 63000 til 64667 | 5004 | AF41 | Video |
Videonett-klynge | Videonett-klynge | 59500 til 62999 | 50 000 til 51499 | EF | Lyd |
Videonett-klynge | Videonett-klynge | 64668 til 65500 | 51500 til 53000 | AF41 | Video |
| Videonettnode | Webex Teams-program eller endepunkt* | 5004 | 52000 til 52099 | AF41 | Lyd |
| Videonettnode | Webex Teams-program eller endepunkt | 5004 | 52100 til 52299 | AF41 | Video |
* Retningen på medietrafikk avgjør DSCP-merkingene. Hvis kildeportene kommer fra videonett-noden (fra videonett-noden til Webex Teams-app), merkes trafikken bare som AF41. Medietrafikk som kommer fra Webex Teams-app eller Webex-endepunkter, har de separate DSCP-merkingene, men det har ikke returtrafikken fra de delte portene for videonettnoden.
| UDP-kildeportdifferensiering (Windows Webex-appklienter): Ta kontakt med det lokale kontoteamet hvis du vil at UDP-kildeportdifferensiering skal aktiveres for organisasjonen din. Hvis dette ikke er aktivert, kan ikke lyd- og videodeling skilles fra Windows OS. Kildeportene vil være de samme for lyd, video og innholdsdeling på Windows-enheter. |
Trafikksignaturer for videonett (tjenestekvalitet deaktivert)
For distribusjoner der Video Mesh-noden befinner seg i DMZ, finnes det en konfigurasjonsinnstilling for videonettnode i Webex Control Hub som lar deg optimalisere portområdene som brukes av Video Mesh-noden. Denne innstillingen for tjenestekvalitet, når den er deaktivert (aktivert som standard), endrer kildeportene som brukes til lyd-, video- og innholdsdeling fra Video Mesh-noden til området 34000 til 34999. Videonett-noden merker deretter all lyd-, video- og innholdsdeling til én enkelt DSCP for AF41.
| Siden kildeportene er de samme for alle medier uavhengig av mål, kan du ikke skille mellom lyd og video eller innholdsdeling basert på portområde med denne innstillingen deaktivert. Denne konfigurasjonen lar deg konfigurere brannmurhull for medier på en enklere måte enn når tjenestekvalitet er aktivert. |
Tabellen og diagrammet viser UDP-porter som brukes til lyd- og videostrømmer når QoS er deaktivert.
| Kilde-IP-adresse | Destinasjons-IP-adresse | Kilde UDP-porter | UDP-målporter | Innebygd DSCP-merking | Mediatype |
| Videonettnode | Webex skymedietjenester | 34000 til 34999 | 5004 | AF41 | Lyd |
| Videonettnode | Webex skymedietjenester | 34000 til 34999 | 5004 | AF41 | Video |
| Videonettnode | Webex skymedietjenester | 34000 til 34999 | 50 000 til 51499 | AF41 | Lyd |
| Videonettnode | Webex skymedietjenester | 34000 til 34999 | 51500 til 53000 | AF41 | Video |
| Videonettnode | Videonettnode | 10000 til 40000 | 10000 til 40000 | AF41 | Lyd |
| Videonettnode | Videonettnode | 10000 til 40000 | 10000 til 40000 | AF41 | Video |
Videonett-klynge | Videonett-klynge | 34000 til 34999 | 5004 | AF41 | Lyd |
Videonett-klynge | Videonett-klynge | 34000 til 34999 | 5004 | AF41 | Video |
Videonett-klynge | Videonett-klynge | 34000 til 34999 | 50 000 til 51499 | AF41 | Lyd |
Videonett-klynge | Videonett-klynge | 34000 til 34999 | 51500 til 53000 | AF41 | Video |
| Videonettnode | Unified CM SIP-endepunkter | 52500 til 59499 | Unified CM SIP-profil | AF41 | Lyd |
| Videonettnode | Unified CM SIP-endepunkter | 63000 til 64667 | Unified CM SIP-profil | AF41 | Video |
Videonettnode | Webex skymedietjenester | 35000 til 52499 | 5004 | AF41 | Test STUN-pakker |
| Videonettnode | Webex Teams-program eller endepunkt | 5004 | 52000 til 52099 | AF41 | Lyd |
| Videonettnode | Webex Teams-program eller endepunkt | 5004 | 52100 til 52299 | AF41 | Video |
Porter og protokoller for Webex Meetings trafikk
Hensikt | Kilde | Destinasjon | Kilde-IP | Kildeport | Transportprotokoll | Destinasjons-IP | Målport |
|---|---|---|---|---|---|---|---|
Innkaller til møte | Apper (Webex-appen for skrivebord og mobilapper) Webex-registrerte enheter | Videonett-node | Etter behov | Hvilke som helst | UDP og TCP (brukes av Webex-appen) SRTP (alle) | Alle** | 5004 |
SIP-enhet som ringer til møte (SIP-signalisering) | samtalekontroll i Unified CM eller Cisco Expressway | Videonett-node | Etter behov | Kortvarig (>=1024) | TCP eller TLS | Alle** | 5060 eller 5061 |
Overlapping | Videonett-node | Webex-sky | Etter behov | 34000 til 34999 | UDP, SRTP (alle)* | Alle** | 5004 50000 til 53000*** |
Overlapping | Videonett-node | Videonett-node | Etter behov | 34000 til 34999 | UDP, SRTP (alle)* | Alle** | 5004 |
| Port 5004 brukes for alle skymedier og lokale videonettnoder. Webex-appen fortsetter å koble til Video Mesh-noder over delte porter 5004. Disse portene brukes også av Webex-appen og Webex-registrerte endepunkter for STUN-tester til videonettnoder. Videonett-node til Videonett-node for overlappende enheter bruker målportområde på 10000–40000. * TCP støttes også, men foretrekkes ikke fordi det kan påvirke mediekvaliteten. |
** Hvis du vil begrense etter IP-adresser, kan du se IP-adresse som er dokumentert i Nettverkskrav for Webex-tjenester .
*** Expressway bruker allerede dette portområdet for Webex-skyen. Så de fleste distribusjoner krever ingen oppdateringer for å støtte dette nye kravet for Video Mesh. Men hvis distribusjonen har strengere brannmurregler, kan det hende du må oppdatere brannmurkonfigurasjonen for å åpne disse portene for videonett.
For å få den beste opplevelsen av å bruke Webex i organisasjonen din, konfigurer brannmuren til å tillate all utgående TCP- og UDP-trafikk som er bestemt til portene 5004, i tillegg til alle innkommende svar på denne trafikken. Portkravene som er oppført ovenfor, forutsetter at videonettnoder distribueres enten i lokalnettet (foretrukket) eller i en DMZ, og at Webex-appen er i lokalnettet.
Videokvalitet og skalering for videonett
Nedenfor finner du noen vanlige møtescenarier når en overlapping opprettes. Video Mesh er tilpasningsdyktig avhengig av tilgjengelig båndbredde og fordeler ressurser deretter. For enheter i møtet som bruker Video Mesh-noden, gir den overlappende koblingen fordelen med å redusere gjennomsnittlig båndbredde og forbedre møteopplevelsen for brukeren.
| For retningslinjer for båndbreddeklargjøring og kapasitetsplanlegging , se Dokumentasjon for foretrukket arkitektur . |
Basert på de aktive talerne i møtet, etableres overlappende koblinger. Hver overlapping kan inneholde opptil 6 strømmer, og overlappingen er begrenset til 6 deltakere (6 i retning av Webex-app/SIP til Webex-sky og 5 i motsatt retning). Hver medieressurs (sky og videonett) ber den eksterne siden om strømmene som er nødvendige for å oppfylle de lokale endepunktkravene til alle eksterne deltakere på tvers av overlappingen.
For å gi en fleksibel brukeropplevelse kan Webex-plattformen gjøre flerstrømsvideo til møtedeltakere. Den samme muligheten gjelder for overlappende kobling mellom Video Mesh-noder og skyen. I denne arkitekturen varierer båndbreddekravene avhengig av en rekke faktorer, for eksempel endepunktoppsettene.
Arkitektur
I denne arkitekturen sender Cisco Webex endepunkter signalisering til skyen og medier til svitsjetjenestene. Lokale SIP-endepunkter sender signalisering til samtalekontroll (Unified CM eller Expressway), som deretter sender den til videonett-noden. Medier sendes til transkodingstjenesten.
Deltakere i skyen og lokaler
Lokale lokale deltakere på Video Mesh-noden ber om de ønskede strømmene basert på oppsettkravene deres. Disse strømmene viderekobles fra Video Mesh-noden til endepunktet for lokal enhetsgjengivelse.
Hver sky- og videonettnode ber om HD- og SD-oppløsninger fra alle deltakere som er skyregistrerte enheter eller Webex-app. Avhengig av endepunktet vil den sende opptil 4 oppløsninger, vanligvis 1080p, 720p, 360p og 180p.
Kaskader
De fleste Cisco-endepunkter kan sende 3 eller 4 strømmer fra én kilde i en rekke oppløsninger (fra 1080p til 180p). Oppsettet til endepunktet dikterer kravet til strømmene som trengs på den andre enden av overlappingen. For aktiv tilstedeværelse er videostrøm 1080p eller 720p, og videorutene (PiPS) er 180p. For lik visning er oppløsningen i de fleste tilfeller 480p eller 360p for alle deltakerne. Kaskaden som opprettes mellom Video Mesh-noder og skyen, sender også 720p, 360p og 180p i begge retninger. Innhold sendes som én strømming, og lyd sendes som flere strømmer.
Overlappende båndbreddegrafer som gir måling per klynge, er tilgjengelige på Analytics-menyen i Webex Control Hub. Du kan ikke konfigurere overlappende båndbredde per møte i Control Hub.
| Maksimal forhandlet overlappende båndbredde per møte er 20 Mbps for hovedvideo for alle kilder og flere hovedvideostrømmer de kan sende. Denne maksimumsverdien inkluderer ikke innholdskanalen eller lyden. |
Eksempel på hovedvideo med flere oppsett
Diagrammene nedenfor viser et eksempel på et møtescenario og hvordan båndbredden påvirkes når flere faktorer spiller inn. I eksemplet overfører alle Webex-app og Webex-registrerte enheter1x 720p,1x 360p og1x 180p strømmer til Video Mesh. På kaskaden overføres strømmer på 720p, 360p og 180p i begge retninger. Årsaken er fordi det er Webex-app og Webex-registrerte enheter som mottar 720p, 360p og 180p på begge sider av overlappingen.
| I diagrammene er båndbreddetallene for overførte og mottatte data kun for eksempelformål. De er ikke en uttømmende dekning av alle mulige møter og tilhørende båndbreddekrav. Ulike møtescenarier (med deltakere, enhetsfunksjoner, innholdsdeling i møtet, aktivitet på et gitt tidspunkt i løpet av møtet) vil gi forskjellige båndbreddenivåer. |
Diagrammet nedenfor viser et møte med registrerte endepunkter i skyen og lokaler og en aktiv taler.
I det samme møtet viser diagrammet nedenfor et eksempel på en kaskade som er opprettet mellom videonettnodene og skyen i begge retninger.
I det samme møtet viser diagrammet nedenfor et eksempel på en kaskade fra skyen.
Diagrammet nedenfor viser et møte med de samme enhetene ovenfor, sammen med en Webex Meetings -klient. Systemet sender den aktiv taler og den siste aktiv taler i HD, sammen med en ekstra HD-strøm av den aktiv taler for Webex Meeting-klienter fordi videonettnoder ikke støtter Webex Meetings for øyeblikket.
Krav for Webex-tjenester
Samarbeid med partneren din, Customer Suksess Manager (CSM) eller prøveversjonsrepresentanten for å klargjøre Cisco Webex nettstedet og Webex-tjenester for videonett på riktig måte:
Du må ha en Webex-organisasjon med et betalt abonnement på Webex-tjenester.
Hvis du vil dra full nytte av Video Mesh, må du sørge for at Webex-nettsted ditt er på videoplattform versjon 2.0. (Du kan bekrefte at nettstedet ditt er på videoplattform versjon 2.0 hvis det har listen Medieressurstype tilgjengelig i nettstedsalternativene for møterom for skysamarbeid.)
Du må aktivere CMR for Webex-nettsted ditt under brukerprofiler. (Du kan gjøre dette i en CSV-fil for masseoppdatering med SupportCMR-attributtet).
Hvis du vil ha mer informasjon, se Funksjonssammenligning og overføringsbane fra samarbeidsmøterom-hybrid til videonett i vedlegget.
Kontroller at kildelandet er riktig
Videonett bruker de globalt distribuerte mediefunksjonene (GDM) i Webex for å oppnå bedre medieruting. For å oppnå optimal tilkobling velger Webex den nærmeste skymedienoden til bedriften når du utfører videonettoverlappinger til Webex. Trafikken går deretter gjennom Webex-ryggraden for å samhandle med Webex-mikrotjenestene for møtet. Denne rutingen minimerer ventetiden og holder mesteparten av trafikken på Webex-ryggraden og utenfor Internett.
For å støtte GDM bruker vi MaxMind som leverandør av GeoIP-plassering for denne prosessen. Kontroller at MaxMind identifiserer plasseringen av den offentlige IP-adresse på riktig måte for å sikre effektiv ruting.
| 1 | I en nettleser skriver du inn denne URL-adressen med den offentlige IP-adresse til Expresswayen eller endepunktet på slutten. Du mottar et svar som følgende: |
| 2 | Kontroller at |
| 3 | Hvis plasseringen er feil, sender du en forespørsel om å korrigere plasseringen av den offentlige IP-adresse din til MaxMind påhttps://support.maxmind.com/geoip-data-correction-request/correct-a-geoip-location . |
Fullfør forutsetningene for videonett
Bruk denne sjekklisten for å sikre at du er klar til å installere og konfigurere videonett-noder og integrere et Webex-nettsted med videonett.
| 1 | Sørg for at du:
| ||
| 2 | Arbeid med partneren din, kundesuksessansvarlig eller prøveversjonsrepresentanten for å forstå og klargjøre Webex-miljøet slik at det er klart til å koble til Video Mesh. Hvis du vil ha mer informasjon, se Krav for Webex-tjenester . | ||
| 3 | Ta opp følgende nettverksinformasjon som skal tilordnes til Video Mesh-nodene:
| ||
| 4 | Før du starter installasjonen, må du kontrollere at Webex-organisasjonen din er aktivert for videonett. Denne tjenesten er tilgjengelig for organisasjoner med bestemte betalte Webex-tjenesteabonnement som dokumentert i Lisenskrav for Cisco Webex . Kontakt din Cisco-partner eller kontoadministrator for å få hjelp. | ||
| 5 | Velg en støttet maskinvare eller spesifikasjonsbasert konfigurasjon for Video Mesh-noden, som beskrevet i System- og plattformkrav for programvare for videonettnode . | ||
| 6 | Kontroller at serveren din kjører VMware ESXi 7 eller 8, og vSphere 7 eller 8, med en VM-vert operativ. | ||
| 7 | Hvis du integrerer Video Mesh med Samtalekontrollmiljøet i Unified CM og du vil at deltakerlistene skal være konsekvente på tvers av møteplattformer, må du samtalekontroll at sikkerhetsmodusen for Unified CM-klynge er satt til blandet modus slik at den støtter TLS-kryptert trafikk. Ende-til-ende-kryptert trafikk er nødvendig for at denne funksjonaliteten skal fungere. Se kapitlet om TLS-oppsett i sikkerhetsveiledning for Cisco Unified Communications Manager hvis du vil ha mer informasjon om hvordan du bytter Unified CM -miljø til blandet modus. Se Veiledning for Active Control-løsninger hvis du vil ha mer informasjon om funksjonene og om hvordan du konfigurerer ende-til-ende-kryptering. | ||
| 8 | Hvis du integrerer en proxy (eksplisitt, gjennomsiktig inspeksjon eller gjennomsiktig ikke-inspeksjon) med Video Mesh, må du sørge for at du følger kravene som er dokumentert i Krav for proxy-støtte for videonett . |
Hva nå?
Oppgaveflyt for distribusjon av videonett
Før du starter
| 1 | Installer og konfigurer programvaren for videonettnode Bruk denne fremgangsmåten til å distribuere en videonettnode til vertsserveren som kjører VMware ESXi eller vCenter. Du installerer den lokale programvaren som oppretter en node, og deretter utfører du den første konfigurasjonen, for eksempel nettverksinnstillinger. Du registrerer den i skyen senere. |
| 2 |
Logg på konsollen for første gang. Programvaren for videonettnode har et standardpassord. Du må endre denne verdien før du konfigurerer noden. |
| 3 | Angi nettverkskonfigurasjon for videonettnode i konsollen Bruk denne fremgangsmåten til å konfigurere nettverksinnstillinger for videonettnode hvis du ikke konfigurerte dem da du konfigurerte noden på en virtuell maskin. Du angir en statisk IP-adresse og endrer FQDN/vertsnavn og NTP-servere. DHCP støttes for øyeblikket ikke. |
| 4 | Bruk disse trinnene for å konfigurere det eksterne grensesnittet for en distribusjon med to nettverksgrensesnitt (dual NIC):
Når noden er tilkoblet igjen og du har bekreftet den interne nettverkskonfigurasjon, kan du konfigurere det eksterne nettverksgrensesnitt hvis du distribuerer videonettnode i nettverkets DMZ, slik at du kan isolere bedriftstrafikken (internt) fra utsiden (eksternt). ) trafikk. Du kan også gjøre unntak eller overstyringer av standard rutingsregler. |
| 5 | Registrer videonettnode til Webex Cloud Bruk denne fremgangsmåten til å registrere videonett-noder til Webex-skyen og fullføre ytterligere konfigurasjon. Når du bruker Control Hub til å registrere noden, oppretter du en klynge som noden er tilordnet. En klynge inneholder én eller flere medienoder som betjener brukere i et bestemt geografisk område. Registreringstrinnene konfigurerer også innstillinger for SIP-samtale , angi en oppgraderingsplan og abonnere på e-postvarsler. |
| 6 | Aktiver og verif Quality of Service (QoS) med følgende oppgaver:
Aktiver QoS hvis du vil at Video Mesh-noder automatisk skal merke SIP-trafikk (lokale SIP-registrerte endepunkter) for både lyd (EF) og video (AF41) separat med passende tjenesteklasse og bruke kjente portområder for bestemte medietyper. Denne endringen lar deg opprette QoS-policyer og effektivt kommentere returtrafikk fra skyen hvis du ønsker det. Bruk trinnene i Reflector Tool for å kontrollere at de riktige portene er åpnet på brannmuren. |
| 7 | Konfigurer videonettnode for proxy-integrering Bruk denne fremgangsmåten til å angi hvilken type proxy du vil integrere med et videonett. Hvis du velger en gjennomsiktig inspeksjons-proxy, kan du bruke nodens grensesnitt til å laste opp og installere rotsertifikat, kontrollere proxyen og feilsøke potensielle problemer. |
| 8 | Følg Integrer videonett med oppgaveflyt for samtalekontroll og velg ett av følgende, avhengig av samtalekontroll, sikkerhetskrav og om du vil integrere Video Mesh med samtalekontroll :
SIP-enheter støtter ikke direkte tilgjengelighet, så du må bruke Unified CM eller VCS Expressway-konfigurasjon for å etablere et forhold mellom lokale registrerte SIP-enheter og videonettklynger. Du trenger bare å trunke Unified CM eller VCS Expressway til videonettnode, avhengig av samtalekontroll . |
| 9 | Utveksle sertifikatkjeder mellom Unified CM og videonettnoder I denne oppgaven laster du ned sertifikater fra Unified CM og Video Mesh-grensesnittene og laster opp det ene til det andre. Dette trinnet etablerer sikker tillit mellom de to produktene, og, sammen med den sikre trunkkonfigurasjonen, lar kryptert SIP-trafikk og SRTP-medier i organisasjonen din lande på Video Mesh-noder. |
| 10 | Aktiver mediekryptering for organisasjons- og videonettklynger Bruk denne fremgangsmåten til å aktivere mediekryptering for organisasjonen og individuelle videonett-klynger. Denne innstillingen tvinger ende-til-ende TLS-oppsett, og du må ha en sikker TLS SIP-trunk på plass på Unified CM som peker til Video Mesh-nodene. |
| 11 | Aktiver videonett for Webex-nettstedet Hvis du vil bruke optimalisert media til videonettnode for et Webex-møte til alle Webex-app og -enhetene som skal delta, må denne konfigurasjonen være aktivert for Webex-nettsted. Aktivering av denne innstillingen kobler Video Mesh- og møteforekomster i skyen sammen, og tillater at overlappinger oppstår fra Video Mesh-noder. Hvis denne innstillingen ikke er aktivert, vil ikke Webex-app og -enhetene bruke videonettnoden for Webex-møter. |
| 12 | |
| 13 | Kontroller møteopplevelsen på det sikre endepunktet Hvis du bruker mediekryptering gjennom ende-til-ende TLS-oppsettet, bruker du disse trinnene for å bekrefte at endepunktene er registrert på en sikker måte, og at riktig møteopplevelse vises. |
Skript for masseklargjøring for videonett
Hvis du trenger å distribuere mange noder i Video Mesh-distribusjonen, er prosessen tidkrevende. Du kan bruke skriptet påhttps://github.com/CiscoDevNet/webex-video-mesh-node-provisioning distribuere videonettnoder på VMWare ESXi-servere raskt. Les gjennom Viktig-filen for instruksjoner om hvordan du bruker skriptet.
Installer og konfigurer programvaren for videonettnode
Bruk denne fremgangsmåten til å distribuere en videonettnode til vertsserveren som kjører VMware ESXi eller vCenter. Du installerer den lokale programvaren som oppretter en node, og deretter utfører du den første konfigurasjonen, for eksempel nettverksinnstillinger. Du registrerer den i skyen senere.
Du må laste ned programvarepakken (OVA) fra Control Hub (https://admin.webex.com ), i stedet for å bruke en tidligere nedlastet versjon. Denne OVA-en er signert av Cisco-sertifikater og kan lastes ned etter at du har logget på Control Hub med administrator for kunde.
Før du starter
Se System- og plattformkrav for programvare for videonettnode for støttede maskinvareplattformer og spesifikasjonskrav for videonettnode.
Kontroller at du har disse obligatoriske elementene:
En datamaskin med:
VMware vSphere-klient 7 eller 8.
Du finner en liste over operativsystemer som støttes, i VMware-dokumentasjonen.
OVA-fil for Video Mesh-programvare lastet ned.
Last ned den nyeste Video Mesh-programvaren fra Control Hub, i stedet for å bruke en tidligere nedlastet versjon. Du kan også få tilgang til programvaren fra denne koblingen . (Filen er på omtrent 1,5 GB.)
Eldre versjoner av programvarepakken (OVA) vil ikke være kompatible med de nyeste Video Mesh-oppgraderingene. Dette kan føre til problemer under oppgradering av applikasjonen. Pass på at du laster ned den nyeste versjonen av OVA-filen fra denne koblingen .
En støttet server med VMware ESXi eller vCenter 7 eller 8 installert og kjører
Deaktiver sikkerhetskopiering av virtuell maskin og direkteoverføring. videonettnode -klynger er sanntidssystemer. eventuelle pauser i virtuell maskin kan gjøre disse systemene ustabile. (For vedlikeholdsaktiviteter på en videonettnode, bruk vedlikeholdsmodus fra Control Hub.)
| 1 | Åpne VMware vSphere-klienten ved hjelp av datamaskinen og logg på vCenter- eller ESXi-systemet på serveren. | ||||
| 2 | Gå til . | ||||
| 3 | På Velg en OVF-mal side, klikk Lokal fil , deretter Velg Filer . Naviger til der videomesh.ova filen er plassert, velger du filen og klikker på Neste .
| ||||
| 4 | På Velg et navn og en mappe side, skriver du inn en Navn på virtuell maskin for videonettnode (for eksempel «Video_ Mesh_ Node_ 1"), velg et sted der nodedistribusjonen for den virtuell maskin kan ligge, og klikk deretter Neste . Det kjøres en valideringskontroll. Når den er fullført, vises maldetaljene. | ||||
| 5 | Kontroller maldetaljene, og klikk deretter på Neste . | ||||
| 6 | På Konfigurasjon velger du type distribusjonskonfigurasjon, og klikker deretter Neste .
Alternativene er oppført i rekkefølgen etter økende ressurskrav.
| ||||
| 7 | På Velg lagring side, må du kontrollere at standard diskformat for Tykk provisjon Lazy nullstilt og retningslinjer for VM-lagring for Datalager som standard er valgt, og klikk deretter Neste . | ||||
| 8 | På Velg nettverk -siden, velger du nettverksalternativet fra listen over oppføringer for å gi ønsket tilkobling til den virtuelle maskinen.
For en DMZ-distribusjon kan du konfigurere Video Mesh-noden med det to nettverksgrensesnitt (NIC). Denne distribusjonen lar deg skille den interne nettverkstrafikken for bedriften (brukes til interbokskommunikasjon, overlapping mellom nodeklynger og for å få tilgang til nodens administrasjonsgrensesnitt) fra den eksterne skynettverkstrafikken (brukes for tilkobling til omverdenen og gjennomgripende til Webex). Alle nodene i en klynge må være i dobbel NIC-modus. en blanding av enkelt og to nettverkskort støttes ikke.
| ||||
| 9 | På Tilpass mal side, konfigurerer du følgende nettverksinnstillinger:
Hvis du foretrekker det, kan du hoppe over konfigurasjonen av nettverksinnstillinger og følge trinnene i Angi nettverkskonfigurasjon for videonettnode i konsollen etter at du logger på noden. | ||||
| 10 | På Klar til å fullføre på siden, kontroller at alle innstillingene du anga, samsvarer med retningslinjene i denne prosedyren, og klikk deretter på Fullfør . Når distribusjonen av OVA er fullført, vises videonettnode i listen over virtuelle datamaskiner. | ||||
| 11 | Høyreklikk på den videonettnode , og velg deretter . Programvaren for videonettnode installeres som gjest på VM-verten. Du er nå klar til å logge på konsollen og konfigurere videonettnode. Du kan oppleve en forsinkelse på noen minutter før nodebeholderne kommer opp. Det vises en brobrannmurmelding på konsollen ved første oppstart, der du ikke kan logge på. |
Hva nå?
Logg på videonettnode
Logg på konsollen for første gang. Programvaren for videonettnode har et standardpassord. Du må endre denne verdien før du konfigurerer noden.
| 1 | Fra VMware vSphere-klienten går du til den videonettnode , og deretter velger du Konsoll . Den videonettnode starter opp, og det vises en påloggingsmelding. Hvis påloggingsmeldingen ikke vises, trykker du på Gå inn . Du kan en kort stund se en melding som angir at systemet initialiseres. |
| 2 | Bruk følgende standard brukernavn og passord for å logge på: Fordi du logger på videonettnode for første gang, må du endre passordfrasen (passordet) for administrator . |
| 3 | For (gjeldende) passord skriver du inn standard passord (ovenfra), og deretter trykker du på Gå inn . |
| 4 | For nytt passord skriver du inn en ny passordfrase, og deretter trykker du på Gå inn . |
| 5 | Hvis du vil skrive inn nytt passord på nytt, skriver du inn den nye passordfrasen på nytt, og deretter trykker du på Gå inn . Meldingen «Passord ble endret» vises, og deretter vises det første skjermbildet for videonettnode med en melding om at uautorisert tilgang er forbudt. |
| 6 | Trykk på Gå inn for å laste hovedmeny. |
Hva nå?
Angi nettverkskonfigurasjon for videonettnode i konsollen
Bruk denne fremgangsmåten til å konfigurere nettverksinnstillinger for videonettnode hvis du ikke konfigurerte dem da du konfigurerte noden på en virtuell maskin. Du angir en statisk IP-adresse og endrer FQDN/vertsnavn og NTP-servere. DHCP støttes for øyeblikket ikke.
Disse trinnene er obligatoriske hvis du ikke konfigurerte nettverksinnstillinger på tidspunktet for OVA-distribusjon.
| Det indre grensesnittet (standardgrensesnittet for trafikk) brukes til CLI, SIP-trunker, SIP-trafikk og nodebehandling. Det eksterne (eksterne) grensesnittet er for HTTPS- og websockets-kommunikasjon til Webex, sammen med den overlappende trafikken fra nodene til Webex. |
| 1 | Åpne grensesnittet for nodekonsollen via VMware vSphere-klienten, og logg deretter på med administratorlegitimasjonen. Etter førstegangs oppsett av nettverksinnstillinger , og hvis videonettverket er tilgjengelig, kan du få tilgang til nodegrensesnittet via sikkert skall (SSH). | ||
| 2 | Velg alternativ fra hovedmeny i videonettnode 2 Rediger konfigurasjon og klikk deretter Velg . | ||
| 3 | Les meldingen om at samtalene avsluttes på videonettnode, og klikk deretter på Ja . | ||
| 4 | Klikk på Statisk , angi IP-adresse for det interne grensesnittet, Maske , Gateway , og DNS verdier for nettverket ditt.
| ||
| 5 | Angi organisasjonens NTP-server eller en annen ekstern NTP-server som kan brukes i organisasjonen. Når du har konfigurert NTP-server og lagret nettverksinnstillinger, kan du følge trinnene i Kontroller tilstanden til videonettnode fra konsoll for å bekrefte at klokken synkroniseres riktig gjennom de angitte NTP-serverne.
| ||
| 6 | (Valgfritt) Endre vertsnavnet eller domenet om nødvendig.
| ||
| 7 | Klikk på Lagre , og klikk deretter Lagre endringer og start på nytt . Under lagringen utføres DNS-validering hvis du oppga et domene. Det vises en advarsel hvis FQDN (vertsnavn og domene) ikke kan løses ved hjelp av de oppgitte DNS-server . Du kan velge å lagre ved å ignorere advarselen, men anrop fungerer ikke før FQDN kan løses til DNS-en som er konfigurert på noden. Etter at videonettnode har startet på nytt, trer endringene i nettverkskonfigurasjon i kraft. |
Hva nå?
Når programvareavbildningen er installert og konfigurert med nettverksinnstillinger (IP-adresse, DNS, NTP og så videre) og tilgjengelig på bedriftsnettverket, kan du gå videre til neste trinn for sikker registrering av det til skyen. IP-adresse som er konfigurert på videonettnode , er bare tilgjengelig fra bedriftsnettverket. Fra et sikkerhetsperspektiv er noden skjerpet, slik at bare kundeadministratorer har tilgang til nodegrensesnittet for å utføre konfigurasjon.
Angi det eksterne nettverksgrensesnittet for videonettnode
Når noden er tilkoblet igjen og du har bekreftet den interne nettverkskonfigurasjon, kan du konfigurere det eksterne nettverksgrensesnitt hvis du distribuerer videonettnode i nettverkets DMZ, slik at du kan isolere bedriftstrafikken (internt) fra utsiden (eksternt). ) trafikk.
| 1 | Velg alternativ fra hovedmeny i videonettnode 5 Ekstern IP-konfigurasjon og klikk deretter Velg . | ||
| 2 | Klikk på 1 Aktiver/deaktiver , deretter Velg , og deretter Ja for å aktivere alternativene for ekstern IP-adresse på noden. | ||
| 3 | Som du gjorde med den første nettverkskonfigurasjon, skriver du inn IP-adresse (eksternt), Maske , og Gateway verdier.
| ||
| 4 | Klikk på Lagre og start på nytt . Noden starter på nytt for å aktivere den doble IP-adresse, og konfigurerer deretter automatisk de grunnleggende statiske rutingsreglene. Disse reglene bestemmer at trafikk til og fra en IP-adresse for privat klasse bruker et internt grensesnitt. trafikk til og fra en offentlig IP-adresse bruker et eksternt grensesnitt. Senere kan du opprette dine egne rutingsregler – for eksempel hvis du må konfigurere en overstyring og gi tilgang til et eksternt domene fra det interne grensesnittet.
| ||
| 5 | Hvis du vil bekrefte konfigurasjonen av den interne og eksterne IP-adresse , går du til konsollens hovedmeny 4 Diagnostikk , og velg deretter Ping . | ||
| 6 | I ping -feltet, angi en destinasjonsadresse du vil teste, for eksempel en ekstern destinasjon eller en intern IP-adresse, og klikk deretter på OK .
|
Hva nå?
API-er for videonettnode
API-er for videonettnode gjør det mulig for organisasjonsadministratorer å administrere passord, interne og eksterne nettverksinnstillinger, vedlikeholdsmodus og serversertifikater relatert til Video Mesh Node. Disse API-ene kan startes via et hvilket som helst API-verktøy som Postman, eller du kan opprette ditt eget skript for å kalle dem. Brukeren må ringe API-ene ved hjelp av riktig endepunkt (du kan bruke enten node-IP eller FQDN), metode, brødtekst, overskrifter, autorisasjon osv. for å utføre den ønskede handlingen og få et passende svar, i henhold til informasjonen nedenfor.
API-er for VMN-administrasjon
API vedlikeholdsmodus og passord for administratorkonto for videonettnodene.
Få status for vedlikeholdsmodus
Henter gjeldende status for vedlikeholdsmodus (Forventet status: på, av, venter eller forespurt).
[FÅ] https://<node_ip> /api/v1/external/maintenanceMode
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Success"
},
"result": {
"isRegistered": true,
"maintenanceMode": "pending/requested/on/off",
"maintenanceModeLastUpdated": 1691135731847
}
}Eksempelrespons 2:
{
"status": {
"code": 401,
"message": "login failed: incorrect password or username"
}
}Eksempelrespons 3:
{
"status": {
"code": 429,
"message": "Too Many Requests"
}
}Aktivere eller deaktivere vedlikeholdsmodus
Når du setter en Video Mesh-node i vedlikeholdsmodus, utfører den en elegant avslutning av anropstjenester (slutter å godta nye anrop og venter i opptil 2 timer på at eksisterende anrop fullføres).
[PUT] https://<node_ip> /api/v1/external/maintenanceMode
| Kall bare dette API-et når det ikke finnes noen aktive samtaler. |
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"maintenanceMode": "on"
}maintenanceMode – Status for vedlikeholdsmodus som skal angis – «på» eller «av».
Forespørselshoder :
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Your request to enable/disable maintenance mode was successful."
}
}Eksempelrespons 2:
{
"status": {
"code": 409,
"message": "Maintenance Mode is already on/off"
}
}Eksempelrespons 3 :
{
"status": {
"code": 400,
"message": "Bad Request - wrong input"
}
}Endre administratorpassord
Endrer passordet til administratorbrukeren.
[PUT] https://<node_ip> /api/v1/external/password
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Brødtekst :
{
"newPassword": "new"
}newPassword – Det nye passordet som skal angis for «admin»-kontoen til videonettnode.
Forespørselshoder :
«Innholdstype»: «application/json»
Eksempel på svar :
Eksempelrespons 1:
{
"status": {
"code": 200,
"message": "Successfully set the new passphrase for user admin."
}
}Eksempelrespons 2:
{
"status": {
"code": 400,
"message": "Enter a new passphrase that wasn't used for one of the previous 3 passphrases."
}
}API-er for VMN-nettverk
Video Mesh Network API-er gjør det mulig for organisasjonsadministratorer å administrere interne og eksterne nettverksinnstillinger.
Hent konfigurasjon av eksternt nettverk
Oppdager om det eksterne nettverket er aktivert eller deaktivert. Hvis det eksterne nettverket er aktivert, henter det også den eksterne IP-adressen, den eksterne nettverksmaske og den eksterne gatewayen.
[FÅ] https://<node_ip> /api/v1/external/externalNetwork
Autorisasjon: Grunnleggende autentisering ved hjelp av brukernavnet for Video Mesh (admin) og passordet.
Eksempel på svar :
Eksempelrespons 1: