De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft het gebruik van Cisco Voice Manager en Telemate om spraakkwaliteit in een VoIP-netwerk te beheren. Alle inhoud is gebaseerd op een echte wereld implementatie van IP-telefonie. Dit document richt zich op de toepassing van de producten en niet op het gebruik van de producten. U dient al bekend te zijn met CVM en Telemate en toegang te hebben tot de vereiste productdocumentatie. Zie Verwante informatie voor een lijst met bijbehorende documentatie.
Wanneer u een grootschalig VoIP-netwerk beheert, moet u de benodigde gereedschappen hebben om de spraakkwaliteit in het netwerk objectief te bewaken en te rapporteren. Het is niet mogelijk alleen op feedback van gebruikers te vertrouwen, omdat deze subjectief en onvolledig is. CVM kan samen met Telemate een deel van deze functie leveren. Het rapporteert over spraakkwaliteit door gebruik te maken van de IOS-gateway (Impairment/Calculated Impairment Planning Factor) (Icpif) voor elke oproep. Dit stelt de netwerkbeheerder in staat om plaatsen te identificeren die lijden aan slechte spraakkwaliteit en met hen op passende wijze te omgaan.
Zodra u probleemsites identificeert, hebt u mogelijk andere gereedschappen nodig om mogelijke QoS-problemen bij het netwerk op te lossen. Twee tools zijn Internetwork Performance Monitor (IPM) en Cisco Service Assurance Agent (CSAA). Deze onderwerpen worden besproken in een ander document dat op onze website is geplaatst.
Lezers van dit document zouden kennis moeten hebben van deze onderwerpen:
Cisco Voice Manager en TelePresence
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.
Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.
De volgende secties geven een overzicht van spraakkwaliteitskwesties:
De ITU standaard G.113 specificeert hoe u de spraakkwaliteit kunt meten. Deze methode dicteert dat u de kwaliteit van spraakoproepen kunt bepalen door het IPFI te berekenen. Op IOS gebaseerde gateways berekenen de waarde van IPF voor elke vraag en registreren het als deel van het CDR-record. Daarnaast kan het een QoV-val (Quality of Voice of Voice) via SNMP verzenden als de IPF-waarde van een oproep groter is dan een vooraf ingestelde waarde. Dit betekent dat de gateways ingebouwde mogelijkheden voor het meten van de spraakkwaliteit hebben. Het enige dat nodig is, is het verzamelen van deze metingen en het analyseren van de gegevens om eventuele trends te identificeren.
De spraakkwaliteit van VoIP wordt voornamelijk beïnvloed door QoS-netwerken. De oproepanalyse zal zich daarom richten op het per-site vaststellen van problemen met de spraakkwaliteit. Als sites met een groot aantal oproepen met een slechte spraakkwaliteit kunnen worden geïdentificeerd, kunnen we ons richten op alle QoS-problemen in het netwerkpad naar en van die sites.
Het volgende gedeelte is slechts een kort overzicht; raadpleeg de G.113-standaard voor meer informatie.
Het algemene idee achter G.113 is om een verzwaringsfactor te berekenen voor elk onderdeel van de apparatuur langs het spraakpad en ze vervolgens op te tellen om de totale verzwakking te krijgen. Er zijn verschillende soorten beperkingen (ruis, vertraging, echo, enz.) en de ITU verdeelt deze in vijf categorieën. Voeg ze toe om de totale bijzondere waardevermindering Itot te krijgen:
Inetot = Io + Iq + ID + ID + Ie
Deze worden als volgt gedefinieerd (volgens de ITU-terminologie):
Io-beperkingen veroorzaakt door een niet-optimaal algemene luidheidsscore en/of hoog stroomruis.
IQ: beperkingen veroorzaakt door PCM-type waarmee de vervorming wordt gekwantificeerd.
Idte-verstandsstoornissen veroorzaakt door talkecho.
Idd-spraak communicatie problemen veroorzaakt door lange eenrichtingverkeer (vertraging).
Ie-beschadigingen veroorzaakt door speciale apparatuur, in het bijzonder non-Wave-standaard codecs met een lage beeldverhouding.
Wanneer Cisco IOS-software Itot berekent, negeert het Io en Iq als verwaarloosbaar en stelt ID in op 0. De binnenlandse waarde is afgeleid uit de volgende tabel, die uit G.113 komt:
Vertraging | ID |
---|---|
150 | 0 |
200 | 3 |
250 | 10 |
300 | 15 |
400 | 25 |
500 | 30 |
600 | 35 |
800 | 40 |
Normaal is Ie een vaste waarde, die alleen afhankelijk is van het codetype. G.113 specificeert de waarden voor codecs die gewoonlijk door Cisco gateways worden gebruikt zoals in de volgende tabel wordt getoond:
Code | Ie |
---|---|
G.711 | 0 |
G.729/G.729a | 10 |
Omdat deze codecs echter in een pakketspraakomgeving worden gebruikt, is de werkelijke insufficiëntie afhankelijk van het pakketverlies. Hoe hoger het pakketverlies, hoe hoger de verzwakking. Cisco-engineering heeft de spraakkwaliteit met PSQM (ITU P.861) gemeten op verschillende niveaus van pakketverlies. In de volgende tabel worden de waarden voor spraakvervorming weergegeven in verhouding tot de niveaus voor pakketverlies voor bepaalde codecs:
Verlies pakketverlies % | G.711 | G.729/G.729a |
---|---|---|
0 | 0 | 10 |
1 | 8 | 15 |
2 | 12 | 20 |
3 | 18 | 25 |
4 | 22 | 30 |
5 | 26 | 34 |
6 | 28 | 38 |
7 | 30 | 40 |
8 | 32 | 42 |
9 | 34 | 44 |
Zoals verwacht is G.729 vatbaarder voor pakketverlies dan G.711.
Spraakkwaliteit gaat over de menselijke perceptie en verwachting. De serviceniveaus van de gebruikers van de mobiele telefoon zijn lager dan die van de gebruikers van de vaste lijn. Bij de berekening van het Icpif houden we hiermee rekening door Itot te verlagen met de menselijke verwachtingsfactor A. De formule hiervoor is:
Icpif = tot - A
G.113 biedt ook verwachtingsfactoren voor typische spraaknetwerken. Zie de volgende tabel:
Toegangsmethode voor spraaknetwerk | Verwacht factor A |
---|---|
Standaardlijn PSTN | 0 |
Local Area Wireless (draadloze telefoon) | 5 |
Breed gebied draadloos (mobiele telefoon) | 10 |
satelliet | 20 |
G.113 heeft ook een tabel die tussen de waarde en de spraakkwaliteit van Icpif kaart gaat. In de volgende tabel is dit aangegeven:
Toegangsmethode voor spraaknetwerk | Verwacht factor A |
---|---|
5 | Heel goed |
10 | goed |
20 | adequaat |
30 | Beperkingszaak |
45 | Uitzonderlijk beperkende zaak |
55 | Gebruikers die waarschijnlijk sterk klagen |
Een Icpif waarde van nul voor een aanroep is een perfecte score. Dit moet ons doel zijn voor VoIP-netwerken.
In een traditioneel spraaknetwerk berekent de ontwerper het totale budget voor bijzondere waardevermindering.
Bijvoorbeeld, Io = 0; Iq = 0; Idte = 0; IDD = 3; Ie = 7, wat Itot = 10 geeft.
Als de gebruiker het netwerk vanuit een draadloze telefoon benadert, is de maximale verwachtingsfactor die kan worden afgetrokken 5, dus het eindresultaat is:
Icpif = Itot - A = 10 - 5 = 5
Volgens de vorige tabel zullen de gebruikers de spraakkwaliteit dan waarschijnlijk zeer goed ervaren.
Dit document bespreekt een oplossing die de waarde van IPCP gebruikt voor het controleren van spraakkwaliteit in plaats van het voor planningsdoeleinden te gebruiken.
In de volgende paragrafen wordt besproken hoe de spraakkwaliteit met CVM en Telemate moet worden beheerd:
Hoewel de voorgestelde oplossing enige beperkingen heeft, lijkt er geen andere schaalbare gereedschappen beschikbaar te zijn. Bekende beperkingen zijn onder meer:
Alleen oproepen via een poort zijn onderworpen aan kwaliteitscontrole. U kunt geen vraag van IPhone aan IPhone meten. De gateway ziet deze oproepen niet en CallManager ondersteunt momenteel G.113 niet.
De IPCP-berekening houdt alleen rekening met pakketverlies en vertragingen. Echo is niet opgenomen in de Icpif berekeningen. Daarom kan een telefoontje ernstige echo vertonen en nog steeds een perfecte Icpif score behalen.
De kwaliteit van de spraak wordt alleen gemeten in de richting van de IP-telefoon naar de gateway. De waarde van IPF in een netwerk van de pakketspraak is waarschijnlijk asymmetrisch in de twee richtingen. Alle problemen van QoS-netwerken met een unidirectioneel netwerk in de gateway-naar-IPhone-richting worden niet weerspiegeld in de Icpif-waarde die door de gateway wordt berekend.
De kwesties van de spraakkwaliteit zijn over het algemeen meer van een probleem in WAN. De oplossing wordt besproken past het best in een milieu met gecentraliseerde gateways, aangezien de vraag van IPtelefoons op verre plaatsen WAN moet oversteken om tot de gateways toegang te hebben. Als gateways worden verspreid (d.w.z., zal elke afgelegen plaats door een lokale gateway worden onderhouden), dan zullen de meeste gateway-oproepen niet het WAN oversteken. VoIP-oproepen via WAN zullen voornamelijk IPhone-to-IPshone zijn, en deze zijn niet zichtbaar voor de gateway.
Als onderdeel van de voorgestelde oplossing moeten alle gateways worden geconfigureerd voor CDR-collectie:
dial-control-mib max-size <max-number-of-cdr> dial-control-mib retain-timer 600
Alle gateways moeten ook de eigenschap van de QoV-val hebben ingeschakeld. Deze optie is standaard uitgeschakeld:
Calibra#show dial-peer voice 99 | include QOV|Icpif Expect factor = 0, Icpif = 20, VAD = enabled, Poor QOV Trap = disabled,
Deze optie is ingeschakeld per VoIP-dial-peers door het volgende toe te voegen:
dial-peer voice XYZ voip snmp enable peer-trap poor-qov icpif <threshold> expect-factor 0
Wanneer een oproep voltooid is, berekent de gateway de totale bijzondere waardevermindering (Itot) voor die oproep. Vervolgens trekt u de geconfigureerde verwachtingsfactor van Itot af om bij de eigenlijke Icpif-waarde te komen. Als dit getal de Icpif drempel overschrijdt, wordt een QoV-val verzonden. De aanroep moet minimaal 10 seconden duren voor de gateway om de Icpif waarde voor de aanroep te berekenen.
Laten we een voorbeeld bekijken, waar de configuratie van de poort als volgt is:
dial-peer voice XYZ voip icpif 10 expect-factor 5
Stel dat een oproep voltooid is met een Itot-waarde van 20. De gateway trekt dan een verwachtingsfactor 5 af van dit getal, met een Icpif waarde van 15. Omdat 15 meer dan 10 is, genereert de gateway een QoV SNMP-val.
Mondiaal gezien is het nodig om QoV-vallen naar CVM te kunnen sturen:
snmp-server enable traps voice poor-qov snmp-server host 10.x.x.x.x public<----- CVM station
Let op dat spraakgateways verbinding/koppeling van SNMP-trap genereren telkens wanneer een oproep wordt ingesteld of afgebroken. Dit kan neerkomen op een enorm aantal vallen op de poort met hoge dichtheid. Zorg ervoor dat u deze vallen uitschakelt door de volgende opdracht toe te voegen:
interface serial1/0:15no snmp trap link-status
CVM en Telemate zijn volledig afzonderlijke toepassingen. Zoals de naam impliceert, is CVM een Cisco ontwikkeld product. Telemate is daarentegen een product van derden dat Cisco samen met CVM verkoopt.
CVM vervult een groot aantal functies. De twee functies die we gaan benutten zijn:
Verzamelen van Call Detail Records (CDR) vanaf de gateways via SNMP.
Ontvangend Quality of Voice (QoV) SNMP-traps vanuit de gateways.
Na het verzamelen van deze informatie, formatteert CVM de gegevens en geeft deze door aan Telemate via eenvoudig delen van bestanden. Telemate verwerkt deze gegevens en slaat deze op in een Microsoft SQL-database. Het eindresultaat is een database met een lijst met oproepen met hun respectievelijke details, inclusief de IPCP-waarde. Diverse rapporten kunnen dan worden uitgevoerd tegen de database, waaronder QoV-rapporten.
Het rapport van Telemate QoV waar we in geïnteresseerd zijn is het rapport "Packet Voice Call with Quality of Service Traps". Dit rapport beschrijft alle oproepen waarvoor de poort een QoV-val genereerde. We zijn niet geïnteresseerd in de individuele oproepen. wij zijn veeleer geïnteresseerd in de eventuele sites met een bovengemiddeld percentage spraakoproepen van hoge kwaliteit . Om dit te bereiken, moet Telemate de gesprekken per site kunnen categoriseren. Dit wordt besproken in de volgende paragraaf.
Door de Telemate folder met kennis van welke extensies op welke sites wonen, kunnen we Telemate gebruiken om gesprekken per site te categoriseren.
De Telemate folder is een hiërarchie van vijf lagen, met de volgende niveaus:
Niveau 1 - Bedrijf
Afdeling Niveau 2
Niveau 3 - afdeling
Niveau 4 - gebruiker
Niveau 5 - uitbreiding
U kunt meerdere extensies koppelen aan één gebruiker.
Idealiter zouden we willen dat elke oproep in het QoV rapport wordt gerangschikt onder de naam van de afdeling. We kunnen dan de naam van de afdeling gebruiken om een bepaalde site te vertegenwoordigen. Dit laat ons toe om telefoontjes te sorteren per afdeling/plaats. Maar omdat verlengingen alleen met gebruikers kunnen worden geassocieerd, moeten we dit op een wat lastige manier bereiken. In feite maken we per site één dummy gebruiker en maken we de naam van deze gebruiker de naam van de site of de site code. Deze dummy gebruiker krijgt dan alle extensies toegewezen voor die plek. We kunnen de telefoontjes dan sorteren door de gebruiker, wat dan het equivalent wordt van het sorteren per site.
Met het oog op QoV-rapportage geven we ons geen zorgen over de top drie niveaus van de directory hiërarchie, en deze kunnen willekeurig worden toegewezen.
Voor deze implementatie zijn er 200 locaties met 45.000 verlengingen toegewezen, hoewel niet noodzakelijk allemaal in gebruik. De folder bevat 200 dummy gebruikers en elke dummy gebruiker is gekoppeld aan de reeks extensies voor hun site. Het handmatig invullen van de folder zou een onmogelijke taak zijn, dus doen we dit semi-automatisch door een CSV-bestand te genereren met één regel per extensie, en dan gebruiken we de Telemate importoptie om het bestand in de folder te importeren. Elke regel in dit CSV-bestand heeft de volgende indeling:
Company,Division,Department,User,Extension
Het genereren van het CSV-bestand zelf wordt ook semi-automatisch uitgevoerd door een Unix shell script uit te voeren. Dit script neemt een zaadbestand als input. Dit zaadbestand maakt een lijst van de sites en de bijbehorende uitbreidingsbereik. Elke regel in het zaadbestand heeft dit formaat:
site_name,extention_start,extension_end
Het shell script zelf is heel simpel en ziet er zo uit:
#--------------------------- Telemate script start ------------------------ #!/bin/ksh for i in `cat ./$1` do ( echo $i | awk 'BEGIN{FS=","}{for (j=($2+0);j<($3+0);++j) printf "Company,Division,Dept,%s,%s\n", $1,j}' ) done #--------------------------- Telemate script end ------------------------
Aangenomen dat het script zelf 'make_dir' heet en dat het zaadbestand 'seedfile.csv' wordt genoemd, wordt het import CSV telemate_dir.csv bestand aangemaakt door de volgende opdracht uit te voeren in de Unix-melding:
unix$ make_dir seedfile.csv > telemate_dir.csv
Het uitvoerbestand telemate_dir.csv wordt dan geïmporteerd in Telemate. Raadpleeg de Telemate-documentatie voor uitgebreide instructies hoe u dit kunt doen.
Tijdens het uitvoeren van een Telemate rapport, kunt u de uitvoerbestemming selecteren. Voor grote rapporten wordt aanbevolen het bestand in CSV-indeling te maken. U kunt het rapport vervolgens manipuleren in Excel, waar het er zo uit zou zien:
Duur | Geknipt # | Locatie | Datum | tijd | terrein | Afsluiten. |
---|---|---|---|---|---|---|
0:00:57 | 3-573-7783 | 10.200.16.33 | 10/05/2000 | 16:49:45 | BLM | 37569 |
0:00:57 | 3-573-7783 | 10.200.16.33 | 10/05/2000 | 16:49:45 | BLM | 37569 |
0:00:38 | 3-577-2958 | 10.200.16.33 | 10/05/2000 | 16:28 | BLM | 37576 |
0:00:38 | 3-577-2958 | 10.200.16.33 | 10/05/2000 | 16:28 | BLM | 37576 |
0:00:52 | 3-577-2985 | 10.200.16.33 | 10/05/2000 | 21:33 | BLM | 37593 |
0:01:19 | 3-577-1770 | 10.200.16.33 | 10/05/2000 | 19:26 | BMC | 34270 |
0:00:23 | 3-577-1770 | 10.200.16.33 | 10/05/2000 | 20:08:27 | BMC | 34270 |
0:00:23 | 3-577-1770 | 10.200.16.33 | 10/05/2000 | 20:08:27 | BMC | 34270 |
0:00:11 | 4-566-5302 | 10.132.16.33 | 10/05/2000 | 19:05 | COR | 42791 |
0:00:32 | 4-567-0417 | 10.132.16.33 | 10/05/2000 | 17:29 | COR | 42805 |
0:00:32 | 4-567-0417 | 10.132.16.33 | 10/05/2000 | 17:29 | COR | 42805 |
0:00:36 | 4-232-8545 | 10.132.16.33 | 10/05/2000 | 17:42 | COR | 42823 |
0:00:36 | 4-232-8545 | 10.132.16.33 | 10/05/2000 | 17:42 | COR | 42823 |
0:00:39 | 4-472-5011 | 10.132.16.33 | 10/05/2000 | 17:59 | COR | 46578 |
0:00:39 | 4-472-5011 | 10.132.16.33 | 10/05/2000 | 17:59 | COR | 46578 |
0:00:28 | 4-236-7687 | 10.132.16.33 | 10/05/2000 | 19:17 | COR | 46578 |
0:00:17 | 6-867-9766 | 10.132.16.35 | 10/05/2000 | 16:08 | GIS | 64197 |
0:00:17 | 6-867-9766 | 10.132.16.35 | 10/05/2000 | 16:08 | GIS | 64197 |
0:00:30 | 6-868-6889 | 10.132.16.35 | 10/05/2000 | 18:15 | GIS | 68549 |
0:00:30 | 6-868-6889 | 10.132.16.35 | 10/05/2000 | 18:15 | GIS | 68549 |
0:01:26 | 6-876-5223 | 10.132.16.35 | 10/05/2000 | 19:10 | HAH | 68369 |
0:01:26 | 6-876-5223 | 10.132.16.35 | 10/05/2000 | 19:10 | HAH | 68369 |
0:00:52 | 6-876-2223 | 10.132.16.35 | 10/05/2000 | 17:37 | HAH | 68397 |
0:01:05 | 4-477-5402 | 10.132.16.33 | 10/05/2000 | 16:23 | JVL | 47162 |
0:00:24 | 4-478-8848 | 10.132.16.33 | 10/05/2000 | 19:07 | JVL | 47168 |
0:00:24 | 4-478-8848 | 10.132.16.33 | 10/05/2000 | 19:07 | JVL | 47168 |
0:00:44 | 4-387-1333 | 10.132.16.33 | 10/05/2000 | 19:49 | KIB | 49252 |
0:00:44 | 4-387-1333 | 10.132.16.33 | 10/05/2000 | 19:49 | KIB | 49252 |
0:01:14 | 4-389-4299 | 10.132.16.33 | 10/05/2000 | 16:07 | KIB | 49254 |
0:01:14 | 4-389-4299 | 10.132.16.33 | 10/05/2000 | 16:07 | KIB | 49254 |
0:00:29 | 4-387-1337 | 10.132.16.33 | 10/05/2000 | 16:45 | KIB | 49256 |
0:00:29 | 4-387-1337 | 10.132.16.33 | 10/05/2000 | 16:45 | KIB | 49256 |
0:00:41 | 4-384-9269 | 10.132.16.33 | 10/05/2000 | 16:09:38 | KIB | 49261 |
0:00:41 | 4-384-9269 | 10.132.16.33 | 10/05/2000 | 16:09:38 | KIB | 49261 |
0:00:41 | 4-384-9269 | 10.132.16.33 | 10/05/2000 | 16:09:38 | KIB | 49261 |
0:00:17 | 4-387-1344 | 10.132.16.33 | 10/05/2000 | 16:33 | KIB | 49263 |
0:00:17 | 4-387-1344 | 10.132.16.33 | 10/05/2000 | 16:33 | KIB | 49263 |
0:00:31 | 6-367-5103 | 10.132.16.35 | 10/05/2000 | 20:44:46 | LEV | 64233 |
0:00:31 | 6-367-5103 | 10.132.16.35 | 10/05/2000 | 20:44:46 | LEV | 64233 |
0:00:30 | 6-368-9088 | 10.132.16.35 | 10/05/2000 | 16:11 | LEV | 64247 |
0:00:30 | 6-368-9088 | 10.132.16.35 | 10/05/2000 | 16:11 | LEV | 64247 |
0:00:38 | 4-570-2450 | 10.132.16.33 | 10/05/2000 | 16:08:26 | LHT | 43636 |
0:00:38 | 4-570-2450 | 10.132.16.33 | 10/05/2000 | 16:08:26 | LHT | 43636 |
Gebruik de optie "subtotalen" van Excel om het aantal slechte oproepen per gebruiker/site te tellen. Maak vervolgens een Excel-macro om het subtotaleren te halveren. Zie het volgende voorbeeld:
Duur | Geknipt # | Locatie | Datum | tijd | terrein | Afsluiten. |
---|---|---|---|---|---|---|
BCM-aantal | 5 | |||||
BMC aantal | 3 | |||||
COR-aantal | 8 | |||||
GIS-aantal | 4 | |||||
HAH Count | 3 | |||||
JVL Count | 3 | |||||
Hib aantal | 11 | |||||
aantal LEV | 4 | |||||
LHT Count | 2 | |||||
Groot aantal | 43 |
De kolom Site bevat nu het aantal slechte aanroepen naar/van die site. De kolom Locatie in het rapport is het IP-adres van het andere uiteinde van het VoIP-been en komt uit het CDR-record van de gateway. In een CallManager (CCM) omgeving, zijn de signalering en media eindpunten twee verschillende IP-adressen. Het IP-adres dat in de lijst staat, is het signalerende eindpunt (d.w.z. het CallManager). Er is een DDTS (CSCds23283) ingediend om een knop aan te vragen waarmee de CDR kan registreren om het IP-adres van de media te loggen. Dit zou slechte aanroepen toe om door middel van een netwerk te worden gesorteerd. Dit geeft een betere granulariteit omdat er meestal meerdere subnetten per site zijn. Als slechts een paar van deze subnetten met QoV-problemen kampen, kunnen deze worden geïdentificeerd.
Wij raden u aan om de planner van de Telemate in te stellen om automatisch het rapport "Packet Voice Call met Quality of Service Traps" één keer per dag uit te voeren. De voltooide verslagen kunnen dan per e-mail worden toegezonden aan een geselecteerd operationeel personeel. Deze personeelsleden doen vervolgens dagelijks een QoV-controle gedurende de afgelopen 24 uur. De rapporten moeten minstens een maand worden gearchiveerd zodat elke verslechtering van QoV gecorreleerd kan worden met netwerkveranderingen die rond die tijd worden uitgevoerd.
Opmerking: De telemate versie 4.7 of later is vereist voor de rapportage om correct te werken met gateways die in een CallManager omgeving werken. Eerdere versies van Telemate gaan ervan uit dat de lokale extensies altijd aan de POTS kant van de gateway zijn. In een milieu CallManager, zijn de lokale uitbreidingen (IPtelefoons) aan de kant van VoIP van de gateway. Als gevolg daarvan zijn eerdere versies van Telemate in de war en zijn de rapporten van beperkte waarde.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
1.0 |
26-Jun-2019 |
Eerste vrijgave |