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 een aantal van de best practices om spraakfouten in een Cisco IOS®/IOS XE® spraakrouter te verzamelen.
Voor de toepassing van dit document worden de volgende componenten gebruikt:
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 zorgen dat u de potentiële impact van elke opdracht begrijpt.
Het proces van debug collectie in deze platforms heeft uitdagingen en kan mogelijk invloed hebben op de prestaties van het apparaat. De uitdagingen en risico's nemen toe wanneer er meerdere actieve oproepen zijn die in een spraakrouter zijn gemaakt. In sommige scenario's, als de debugs niet correct worden verzameld, kan het tot hoge CPU leiden die de capaciteit van de router zou kunnen beschadigen en zelfs een softwarerecrisis veroorzaken. Dit document heeft betrekking op het verschil tussen een Cisco Unified Border Element (CUBE) en een Time-Division Multiplexing (TDM)/analoge gateway.
TDM-spraakgateways worden voornamelijk gebruikt om een intern telefoonsysteem te verbinden met een andere Private Branch Exchange (PBX) of het Public Switched Telephony Network (PSTN). Het type verbindingen dat in TDM-gateways wordt gebruikt, is T1/E1-controllers (ISDN of CAS) en analoge circuits zoals FXS- en FXO-poorten. Een Digital Signal Processor (DSP) converteert het geluid van zijn onbewerkte vorm naar RTP-pakketten. Op een gelijkaardige manier, worden de pakketten van RTP omgezet in ruwe audio nadat DSP de pakketten van RTP heeft verwerkt en de audio op de specifieke kring verzendt. Deze gateways kunnen interworking met H323, MGCP of Skinny Call Control Protocol (SCCP) aan de VoIP-kant en aan de TDM-kant zijn ISDN PRI-circuits of analoog als de meest gebruikelijke verbindingen met het PSTN of de eindpunten.
Zoals in het beeld wordt getoond, bieden de TDM-gateways een brug tussen uw interne VoIP-infrastructuur en de analoge of ISDN-serviceproviders:
Met de introductie van VoIP begonnen klanten hun bestaande systemen snel te veranderen in een moderne VoIP-infrastructuur. Hetzelfde is gebeurd aan de kant van de serviceproviders, waar zij nu verbindingen gebruiken om on-Premises telefonieservices te verbinden met de VoIP-infrastructuur voor serviceproviders en hun mogelijkheden uit te breiden om betere services te kunnen leveren. Het meest gebruikte VoIP-protocol is het Session Initiation Protocol (SIP) en wordt momenteel wereldwijd gebruikt door klanten en Internet Telephony Service Providers (ITSP).
CUBE is geïntroduceerd om een manier te bieden om die interne VoIP-systemen met de externe wereld te verbinden via de ITSP’s met SIP als het primaire VoIP-protocol. CUBE is gewoon een IP-IP gateway waarvoor het niet langer een TDM-type verbinding nodig heeft, zoals T1/E1-controllers of analoge poorten. CUBE wordt uitgevoerd op dezelfde platforms als TDM-gateways.
Het meest gebruikte VoIP-protocol is SIP, voor het instellen van oproepen en het verwijderen van de oproepen, en RTP voor mediatransport. In CUBE is geen DSP nodig tenzij een transcoder vereist is. De RTP-verkeersstromen eindigen van de ITSP naar het eindpunt, en CUBE fungeert als de tussenpersoon met adresverberging als een van de vele functies die het biedt.
Zoals in het beeld wordt getoond, biedt CUBE een scheiding tussen uw interne VoIP-infrastructuur en de SIP ITSP:
Spraakfuncties die worden uitgevoerd op een andere lijst van platforms, zoals ISR, ASR's, CAT8Ks, enz.; Ze maken echter gebruik van een veel gebruikte software die Cisco IOS of Cisco IOS XE is (de verschillen tussen Cisco IOS en Cisco IOS XE worden niet in dit artikel besproken). Dit zijn de basisbeginselen voor toegang tot de Cisco IOS-router.
Routers hebben, net als alle andere op CLI gebaseerde apparaten, een eindmonitor nodig om toegang te krijgen tot de opdrachten via Secure Shell (SSH) of Telnet. SSH is het meest voorkomende protocol dat tegenwoordig wordt gebruikt om toegang te krijgen tot de opgegeven apparaten. Het biedt een beveiligde en versleutelde verbinding met het apparaat. Enkele gemeenschappelijke eindmonitoren die worden gebruikt om tot CLI van de routers toegang te hebben zijn:
Er zijn verschillende manieren om de uitvoer van de CLI te verzamelen. Het is aan te raden om de informatie van de CLI van de router te exporteren naar een afzonderlijk bestand. Dit maakt het makkelijker om de informatie te delen met derden.
Een paar manieren om de uitgangen van het apparaat te verzamelen zijn:
Later kunt u de informatie van de eindmonitor met de optie Alles kopiëren naar klembord verzamelen en de uitvoer in een tekstbestand plakken:
Opmerking: Als er geen andere naam is opgegeven, wordt de standaardnaam van het logbestand gebruikt. Klik op de knop Bladeren om precies te weten waar het bestand wordt opgeslagen om het later te vinden. Zorg er ook voor dat u geen ander putty.log bestand overschrijven in hetzelfde bestand pad.
Toon bevelen zijn nodig om basisinformatie van de router te verzamelen alvorens om het even welke debug inzameling plaatsvindt. Toon opdrachten snel te verzamelen zijn, en voor het grootste deel, hebben geen invloed op de prestaties op de router. Isolatie van het probleem kon onmiddellijk met enkel een output van het showbevel beginnen.
Zodra verbonden met de router, kan de eindlengte aan 0 worden geplaatst. Dit kan de inzameling sneller maken om alle output meteen te tonen, en het gebruik van de ruimtebar te vermijden. De ene opdracht die gedetailleerde informatie over de router verzamelt, is show technologie, en anders, kunt u verzamelen show tech spraak die gegevens meer specifiek toont voor de spraakfuncties die in de router zijn ingeschakeld:
Router# terminal length 0
Router# show tech
!or
Router# show tech voice
Router# terminal default length !This cmd restores the terminal length to default
Debug uitvoerverzameling in Cisco IOS/IOS XE kan soms een uitdaging zijn omdat er een risico is op een routercrash. Enkele van de best practices worden in de volgende secties uitgelegd om problemen te voorkomen.
Alvorens u om het even welke debugs toelaat, moet u ervoor zorgen er genoeg geheugen is om de output in de buffer op te slaan.
Voer de opdracht tonen procesgeheugen om te weten te komen hoeveel geheugen u kunt toewijzen om alle uitvoer in de buffer te registreren:
Tip: Gebruik de opdrachtterminallengte standaard of terminallengte <num_lines> om terug te gaan naar een beperkt aantal lijnen dat in de terminal wordt weergegeven.
Router# show process memory
Processor Pool Total: 8122836952 Used: 456568400 Free: 7666268552
lsmpi_io Pool Total: 6295128 Used: 6294296 Free: 832
In het voorbeeld, is er 7666268552 bytes (7.6GB) vrij om door de router worden gebruikt. Dit geheugen wordt gedeeld door de router onder alle systeemprocessen. Dit betekent dat u niet het gehele vrije geheugen kunt gebruiken om de output in de buffer te registreren, maar u kunt een goede hoeveelheid systeemgeheugen gebruiken zoals nodig.
De meeste scenario's vereisen minstens 10MB om genoeg te verzamelen debug uitvoer alvorens de output wordt verloren of overschreven. In zeldzame gevallen is een grotere hoeveelheid gegevens vereist. In die specifieke scenario's, kunt u 50MB tot 100MB van output in de buffer krijgen, of u kunt hoger gaan zolang er geheugen beschikbaar is.
Als Free Memory laag is, is er mogelijk een probleem met geheugenlekkage. Als dit het geval is, neem dan contact op met het Architecture TAC team om te herzien wat de oorzaak van zo weinig geheugen zou kunnen zijn.
De CPU wordt beïnvloed door de hoeveelheid processen, functies en aanroepen die in het systeem actief zijn. Hoe meer functies of aanroepen actief zijn in het systeem, hoe drukker de CPU is.
Een goede benchmark is te verzekeren dat de router de CPU bij 30% of minder heeft, wat betekent dat u veilig debugs van basis naar geavanceerd kunt inschakelen (houd altijd een oogje op de CPU wanneer geavanceerde debugs worden gebruikt). Als de router CPU op ongeveer 50% ligt, dan kunnen eenvoudige debugs worden uitgevoerd en kan de CPU zorgvuldig worden bewaakt. Als de CPU hoger is dan 80%, stopt u onmiddellijk de debugs (zie verderop in dit artikel) en start u TAC voor ondersteuning.
Gebruik het cpu van het showproces gesorteerd | sluit 0.00 uit om de laatste 5s, 60s en 5min CPU-waarden te controleren, samen met de bovenste processen.
Router# show processes cpu sorted | exclude 0.00
CPU utilization for five seconds: 1%/0%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
211 4852758 228862580 21 0.15% 0.06% 0.07% 0 IPAM Manager
84 3410372 32046994 106 0.07% 0.04% 0.05% 0 IOSD ipc task
202 3856334 114790390 33 0.07% 0.05% 0.05% 0 VRRS Main thread
In de output, heeft de router niet veel activiteit, is cpu laag, en debugs kan veilig worden toegelaten.
Voorzichtig: Besteed extra aandacht aan de top CPU processen die actief zijn. Als de CPU 50% of hoger is en het bovenste proces alleen een spraakproces is, kunnen eenvoudige debugs worden ingeschakeld. Controleer de CPU voortdurend met de opdracht om er zeker van te zijn dat de algehele prestaties van de router niet worden beïnvloed.
Elke router heeft verschillende capaciteitsdrempels. Het is belangrijk om te controleren hoeveel oproepen in de router actief zijn om er zeker van te zijn dat deze niet dicht bij de maximale capaciteit zit. Het gegevensblad Cisco Unified Border Element versie 12 biedt informatie over elke platformcapaciteit voor raadpleging.
Gebruik het bevel van de showvraag actieve totaal-vraag om een idee te krijgen op hoeveel vraag in het systeem actief is:
Router# show call active total-calls
Total Number of Active Calls : 0
Gebruik het bevel van de showvraag actieve stemsamenvatting om meer gedetailleerde informatie van de specifieke vraagtypes te krijgen die actief zijn:
Router# show call active voice summary
Telephony call-legs: 0
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
STCAPP call-legs: 0
Multicast call-legs: 0
Total call-legs: 0
Enkele gemeenschappelijke waarden zijn:
Om de router te vormen om op te slaan debug uitvoer in de buffer, wordt de Configure eindmodus ingevoerd om de instellingen in de CLI handmatig te knijpen. Deze configuratie heeft geen invloed op de router, echter, zoals in vorige secties wordt getoond, toon technologie of toon in werking stelt -in werking stellen-config bevel van de router is nodig in het geval dat de configuratie moet worden gerold.
Vervolgens is er een configuratievoorbeeld, dat een veelgebruikte basislijn is die door TAC Engineers wordt gebruikt. Het voorbeeld wijst een 10MB buffergeheugen toe maar het kan worden verhoogd zoals nodig:
# configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers
logging buffered 10000000
no logging console
no logging monitor
logging queue-limit 10000
logging rate-limit 10000
voice iec syslog
Deze opdrachten vervullen de volgende taken:
Soms kunnen problemen willekeurig zijn, en vereisen een manier om continu debugs te verzamelen tot de gebeurtenis gebeurt. Wanneer u de debugs in de buffer opslaat, verzamelt het deze continu. Merk op dat het beperkt is tot de hoeveelheid geheugen die u kunt toewijzen en zodra het die hoeveelheid geheugen bereikt, de buffer cirkelt rond en laat vallen de oudste berichten, die tot onvolledige waardevolle informatie leidt die nodig is om het probleem te isoleren.
Met Syslog kan de router alle debug-berichten naar een externe server sturen, waar de Syslog Server-software het in tekstbestanden opslaat. Hoewel het een goede manier is om de debug output te verzamelen, is het niet de voorkeursmethode voor logcollectie. Syslog-servers hebben de neiging lijnen van de ontvangen uitvoer over te slaan of te laten vallen vanwege stremmingen op de server. Aangezien debug-uitvoer de server kan overweldigen, kunnen pakketten worden gedropt vanwege netwerkomstandigheden. In sommige scenario's is syslog echter de enige manier om vooruitgang te boeken in een kwestie.
Gebruik indien mogelijk een betrouwbare transportmethode zoals TCP om verlies van informatie te voorkomen en sluit als suggestie de Syslog-server aan op dezelfde switch waar de router is aangesloten, of zo dicht mogelijk bij de router. Het garandeert nog steeds niet dat alle gegevens in de bestanden worden opgeslagen, maar vermindert de kans op gegevensverlies.
Standaard gebruiken syslog servers UDP als transportprotocol op poort 514.
#configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers
!Optional in case you still want to store debug output in the buffer.
logging buffered 10000000
no logging console
no logging monitor
logging trap debugging
!Replace the 192.168.1.2 with the actual Syslog Server IP Address
logging host 192.168.1.2 transport [tcp|udp] port
Zodra de opdrachten zijn geconfigureerd, stuurt de router de berichten onmiddellijk door naar de syslogserver IP-adres.
Zodra de debugs zijn ingeschakeld, moet de buffer worden gewist voordat het probleem wordt gereproduceerd. Dit wordt gedaan om ervoor te zorgen dat de output zo schoon mogelijk is en om te voorkomen dat extra gegevens nodig zijn voor de analyse. Voer de opdracht clear log uit. Hierdoor wordt de buffer gewist. Als er andere vraag actief in de router is, en debugs wordt toegelaten, drukt de output onmiddellijk in de buffer.
Router# clear log
Clear logging buffer [confirm]
Router#
Nadat het probleem is gereproduceerd, schakelt u de debugs direct uit om meer output in de buffer te stoppen. Dan, verzamel de logboeken. U kunt alle uitvoer in de terminal dumpen met de opdrachten:
Router# undebug all
Router# terminal length 0
Router# show log
Soms sluit PuTTY aangezien het niet alle output meteen behandelt. Dit is normaal en het betekent niet dat er een mislukking is gebeurd. Als dit gebeurt, opent u de sessie opnieuw en gaat u normaal verder. In scenario's waar de logboekbuffer te groot is of de eindmonitor crasht vanwege de hoeveelheid gegevens die moet worden afgedrukt, kopieer de bufferoutput direct naar een extern apparaat met het showlogboek | opdracht omleiden:
Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt
De opdracht kopieert de gehele bufferoutput naar een ftp met IP-adres 192.168.1.2 met de bestandsnaam debug.txt. De bestandsnaam moet altijd worden opgegeven. Andere voor de uitvoer beschikbare bestemmingen zijn:
Router# sh log | redirect ?
bootflash: Uniform Resource Locator
flash: Uniform Resource Locator
ftp: Uniform Resource Locator
harddisk: Uniform Resource Locator
http: Uniform Resource Locator
https: Uniform Resource Locator
nvram: Uniform Resource Locator
tftp: Uniform Resource Locator
Elke call flow en elk type functies (TDM, CUBE of SCCP Media Resources) zijn verschillend en er zijn specifieke debugs die u kunt inschakelen. Alle vereiste debugs moeten tegelijkertijd worden ingeschakeld. Wanneer slechts één debug tegelijkertijd wordt opgenomen, is het ineffectief en geeft het meer verwarring wanneer de gegevens worden geanalyseerd.
Debugs zijn ingeschakeld binnen de CLI exec prompt level Router# die vereist dat u geprivilegieerde machtigingen voor de uitvoeringsmodus hebt.
Er zijn basis en geavanceerde debugs. Basis debugs worden gebruikt om signaleringsinformatie in SIP, H323 of MGCP te verzamelen, die de gesprekken toont die de router met zijn peer apparaten heeft.
Geavanceerde debugs zijn zeer gedetailleerd, en worden normaal gebruikt om meer informatie te verzamelen in het geval van interne stapelfouten die de basis debugs niet kunnen tonen. Deze debugs zijn gewoonlijk CPU-intensief.
Tip: Nadat de debugs zijn ingeschakeld, onthoud om de duidelijke vastlegging opdracht uit te voeren. Deze opdracht zorgt ervoor dat de buffer wordt gewist voor een schonere opname van de debugs.
Binnen elke Cisco IOS/IOS XE router is er een API voor gespreksbeheer die verantwoordelijk is voor de communicatie tussen verschillende VoIP-toepassingen of -protocollen en de componenten van het gegevensplane, zoals RTP, DSP, spraakkaarten enzovoort. Om gegevens van deze laag op te nemen, is er één specifieke debug die kan worden gebruikt:
debug voip ccapi inout
Er zijn andere opties voor deze debug; nochtans, debug voip capi inout behandelt alle fundamentele wijzerplaat-plan en vraag vestigingsinformatie die normaal meer dan genoeg is om te begrijpen wat de staten van deze laag zijn.
Tip: debug voip capi inout heeft meestal een minimale impact op de CPU van de router en het wordt aanbevolen om samen met signalering debugs in te schakelen om een volledige set logbestanden te voorzien van informatie over de oproep(s) en de verschillende toestanden.
Deze debugs zijn de meest gebruikte voor SIP-gespreksstromen, en ze kunnen worden ingeschakeld binnen CUBE en TDM-gateways met een SIP-been tussen de router en CUCM of een andere SIP-server of proxy.
debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.
debug ccsip all
debug ccsip verbose
debug voice ccapi inout
Deze debugs zijn van toepassing op Primary Rate Interfances (PRI) T1/E1 of Basic Rate Interfaces (BRI):
debug isdn q931
debug isdn q921
Deze debugs worden gebruikt wanneer er analoge circuits betrokken zijn zoals Foreign eXchange Subscriber (FXS) of Foreign eXchange Office (FXO) poorten:
debug vpm signal
debug voip vtsp all
Deze debugs worden gebruikt wanneer MGCP gebruikt wordt als het Voice Protocol tussen een spraakgateway en CUCM.
debug mgcp packets
debug mgcp errors
De ccm-manager debugt wordt gebruikt om de configuratiedownload, en de backhaul-berichten van MoH en PRI/BRI tussen CUCM en de spraakgateway te volgen. Deze debugs worden gebruikt op de gewenste basis en zijn afhankelijk van het mislukkingsscenario.
debug ccm-manager backhaul !For PRI and BRI Deployments
debug ccm-manager errors
debug ccm-manager events
debug ccm-manager config-download !Troubleshoot Configuration download issues from CUCM TFTP
debug ccm-mananger music-on-hold !Troubleshoot internal MoH Process
debug mgcp all
Hoewel H323 niet veel wordt gebruikt, zijn er nog steeds enkele implementaties met H323 geconfigureerd:
debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events
debug cch323 h225
debug cch323 h245
debug cch323 all
Deze debugs worden gebruikt om problemen met SCCP Media Resources op te lossen die betrekking hebben op Media Termination Point (MTP) of Transcoders die zijn geregistreerd op een CUCM-server:
debug sccp messages
debug sccp events
debug sccp errors
debug sccp all
Met de introductie van Cisco IOS XE 17.4.1 en 17.3.2 is er een nieuwe optie om spraaklogs binnen het Cisco Unified Border Element (CUBE) op te nemen. Deze nieuwe functie wordt VoIP Trace genoemd. Dit is een nieuw servicability framework gemaakt om SIP signalering en gebeurtenissen te loggen zonder de noodzaak om debugs in te schakelen.
VoIP Trace is standaard ingeschakeld en kan naar behoefte op elk moment worden uitgeschakeld. VoIP Trace neemt alleen specifieke informatie op voor SIP-oproepen:
VoIP Trace logt geen informatie in met betrekking tot SIP-berichten die buiten het dialoogvenster staan:
VoIP Trace in HA wordt ondersteund, maar deze voorbehouden zijn van toepassing:
Zoals vermeld, wordt deze functie standaard ingeschakeld. De opdracht om deze functie in te schakelen is:
Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#
Om deze functie uit te schakelen, hebt u de volgende opdrachten:
Router(conf-serv-trace)# no trace
!or
Router(conf-serv-trace)# shutdown
Voorzichtig: Nadat VoIP Trace is uitgeschakeld, wordt al het geheugen gewist en wordt informatie verloren.
De opdrachten die beschikbaar zijn in de modus voor overtrekken zijn:
Router(conf-serv-trace)# ?
default Set a command to its defaults
exit Exit from voice service voip trace mode
memory-limit Set limit based on memory used
no Negate a command or set its defaults
shutdown Shut Voip Trace debugging
De geheugenlimiet bepaalt hoeveel geheugen door VoIP Trace wordt gebruikt om de gegevens op te slaan. Standaard is het 10% van het beschikbare geheugen in het platform, maar dit kan worden veranderd in maximaal 1 GB en een minimum van 10MB. Het geheugen wordt dynamisch toegewezen, wat betekent dat de functie alleen geheugen gebruikt als dat nodig is en afhankelijk is van het volume van de oproep. Zodra het de max beschikbare geheugen bereikt, cirkelt het rond en verwijdert oudere items.
Wanneer de geheugenlimiet is gewijzigd zodat deze groter is dan het 10% beschikbare geheugen, wordt een bericht weergegeven in de Command Line Interface:
Router(conf-serv-trace)# memory-limit 1000
Warning: Setting memory limit more than 10% of available platform memory (166 MB) will affect system performance.
Om de standaardinstelling op 10% geheugengebruik in te stellen, kan het commando memory-limit platform worden gebruikt:
Router(conf-serv-trace)# memory-limit platform
Reducing the memory-limit clears all VoIP Trace statistics and data.
If you wish to copy this data first, enter 'no' to cancel,
otherwise enter 'yes' to proceed. Continue? [no]:
Voorzichtig: Wanneer de geheugenlimiet wordt verlaagd, gaan alle VoIP Trace-gegevens verloren. Een back-up van de gegevens moet worden verzameld voordat het geheugen wordt verkleind.
Om de gegevens van VoIP Trace weer te geven, moet u specifieke showopdrachten gebruiken. De gegevens kunnen worden weergegeven in dezelfde terminal sessie of kunnen ook worden verzonden via syslog naar een off-box syslog server.
Opmerking: Sporen worden gedumpt na 32 seconden vanaf het moment dat een BYE wordt ontvangen voor een oproep.
Opmerking: De SIP-signalering wordt per been weergegeven en wordt niet gecombineerd als reguliere debugs. Regelmatig debuggen zoals debug CCSIP-berichten, toont de SIP-signalering van een oproep in de exacte volgorde waarin de gebeurtenissen plaatsvonden. In VoIP Trace is elk been apart. Om de juiste volgorde te bepalen, worden de tijdstempels gebruikt.
De beschikbare opdrachten om de gegevens te tonen zijn:
Router# show voip trace ?
all Display all VoIP Traces
call-id Filter traces based on Internal Call Id
correlator Filter traces based on FPI Correlator
cover-buffers Display the summary of all cover buffers
session-id Filter traces based on SIP Session ID
sip-call-id Filter traces based on SIP Call Id
statistics Display statistics for VoIP Trace
Deze opdracht geeft alle VoIP Trace-gegevens weer die in de buffer beschikbaar zijn. Het gebruik van deze opdracht heeft invloed op de prestaties van de router. Zodra het commando is ingevoerd, verschijnt er een waarschuwingsbericht om te waarschuwen voor het risico en te bevestigen dat u doorgaat:
Router# show voip trace all
Displaying 11858 cover buffers
This may severely impact system performance.
Continue? [yes/no] no
Deze opdracht geeft een overzicht van de gespreksdetails voor alle oproepen die onder VoIP Trace worden gemeld. Elke call leg heeft een cover buffer gecreëerd die een samenvatting van de geregistreerde vraag bevat.
Router# show voip trace cover-buffers
------------------ Cover Buffer ---------------
Search-key = 8845:3002:659
Timestamp = *Sep 30 01:17:33.615
Buffer-Id = 1
CallID = 659
Peer-CallID = 661
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 20857880-1ec12085-13b930-411b300a@10.48.27.65
SIP Session ID = 2b1289c400105000a0002c3ecf872659
GUID = 208578800000
-----------------------------------------------
------------------ Cover Buffer ---------------
Search-key = 8845:3002:661
Timestamp = *Sep 30 01:17:33.634
Buffer-Id = 2
CallID = 661
Peer-CallID = 659
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 8D6DEC28-1F111EB-829FD797-1B22F6DB@10.48.55.11
SIP Session ID = 0927767800105000a0005006ab805584
GUID = 208578800000
-----------------------------------------------
Raadpleeg de volgende tabel voor meer informatie over elk veld:
Veld |
Beschrijving |
Zoektoets |
Bevat een combinatie van bellen, nummer en call-id |
tijdstempel |
Tijd van aanmaken van afdekbuffer |
Buffer-ID |
Buffer-ID van de dekkingsbuffer |
Bel-id |
Nummerherkenning van de respectieve oproeppoot van de buffer naar de afdekbuffer |
Peer-CallID |
Bel-id van het peer-been |
correlator |
FPI-correlator van de oproep |
Oproepnummer |
Oproepnummer van de respectieve oproeppoot van de dekkingsbuffer |
Telefoonnummer |
Roepnummer van de respectieve oproeppoot van de dekkingsbuffer |
SIP-gespreks-id |
SIP-oproepnummer van de respectieve oproeppoot van de afdekbuffer |
SIP-sessie-id |
SIP-sessie-id van de respectieve call-leg van de cover buffer |
GUID |
GUID van de respectieve roep van de dekkingsbuffer |
ankerbeen |
De ankerpoot wordt op ja ingesteld als de respectieve aanroeppoot een ankerpoot is in de oproepvorkstroom of de media-proxyinzet |
gevorkt been |
Forked Leg is op ja ingesteld als de respectievelijke call-leg een ankerpoot is in de call forking flow of media proxy-implementatie |
Gekoppelde CalI-id’s |
Nummerherkenning van de bijbehorende gevorkte poten |
Om de afdekbuffers te filteren kunt u de opdrachten Inclusief en paragraaf gebruiken:
Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
!or
Router# show voip trace cover-buffers | section Search-key | 8845 | 3002
Search-key = 8845:3002:661
In combinatie met de vorige opdracht, tonen voip spoor call-id kan worden gebruikt om de vraag te vinden. Nadat de call-id is geïdentificeerd, kan deze opdracht worden gebruikt om alle informatie over de specifieke call-leg weer te geven:
Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
Router# show voip trace call-id 661
Deze show commando toont gedetailleerde uitvoer over status, geheugenverbruik, fouten of storingen, succesvolle oproepen, tijdstempels van de nieuwste en oudste vermeldingen en meer.
Router# show voip trace statistics
VoIP Trace Statistics
Tracing status : ENABLED at *Sep 12 06:44:02.349
Memory limit configured : 803209216 bytes
Memory consumed : 254550928 bytes (31%)
Total call legs dumped : 2
Oldest trace dumped : *Sep 12 07:29:21.077 Search-key: 9898:30000:64
Latest trace dumped : *Sep 12 07:29:21.010 Search-key: 9898:30000:63
Total call legs captured : 11858
Total call legs available : 11858
Oldest trace available : *Sep 12 06:57:23.923, Search-key: 5250001:4720001:11
Latest trace available : *Sep 13 05:08:25.353, Search-key: 19074502232:30000:13177
Total traces missed : 0
Raadpleeg de volgende tabel voor meer informatie over elk veld:
Veld |
Beschrijving |
Overtrekstatus |
Hiermee wordt de overtrekstatus weergegeven, inclusief de datum en tijd waarop VoIP-overtrekken is ingeschakeld. |
Geheugenlimiet ingesteld |
Hier wordt de ingestelde geheugenlimiet weergegeven. Dit is 10% van het geheugen van de processorpool |
Verbruikt geheugen |
Geeft de hoeveelheid geheugen weer die dynamisch wordt verbruikt voor VoIP Trace |
Totale gedumpte vraagbenen |
Toont het aantal ontbroken vraagbenen die in logboekbuffer worden gedumpt. Gedumpte aanroepen verwijst naar aanroepbenen geassocieerd met IEC-fouten |
oudste spoor gedumpt |
Weergave tijdstempels en zoeksleutel van de oudste mislukte aanroep sinds VoIP Trace ingeschakeld was |
Laatste spoor gedumpt |
Weergave tijdstempels en zoeksleutel van de laatste mislukte aanroep sinds VoIP Trace ingeschakeld was |
Totaal aantal opgenomen callbenen |
Hiermee worden totale benen weergegeven die zijn opgenomen nadat VoIP Trace is ingeschakeld |
Totale beschikbare vraagbenen |
Hiermee worden in totaal beschikbare aanroepbenen in de geschiedenis weergegeven. Dit kan hetzelfde of anders zijn in vergelijking met Total call legs opgenomen, het hangt af van de geheugenlimiet. |
Oudste spoor beschikbaar |
Toont tijdstempel en zoeksleutel van de oudste cover buffer beschikbaar in het geheugen |
Nieuwste spoor beschikbaar |
Weergave van tijdstempel en zoeksleutel van de nieuwste cover buffer beschikbaar in het geheugen |
Totaal gemiste sporen |
Het aantal gemiste vraagbenen van vertoningen wegens geheugengrens. |
Veld |
Gebruik |
Beschrijving |
voip trace correlator tonen <correlator> |
toon voip spoor correlator 4 |
Filters en displays VOIP Trace voor een specifieke call-id vanaf de afdekbuffer |
voip-trace-id tonen <sessie-id> |
spraaktracering sessie-id tonen 87003120822b5dbd8fd80f62d8e57c48 |
Filters en displays VOIP Trace voor een oproep op basis van de SIP-sessie-id. Of lokale of externe UUID van de sessie-ID-header van het SIP-bericht kan worden gebruikt om beide benen van de oproep weer te geven. |
sip-call-id voor voip-trace tonen <call-id> |
voip-spoor sip-call-id 10e60dfa9d8442848336d79e3155a8a1 weergeven |
Filters en displays VOIP-tracering op basis van SIP Call-ID |
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
3.0 |
13-Feb-2025 |
Bijgewerkte branding Vereisten, stijlvereisten, opmaak en grammatica. |
2.0 |
13-Apr-2023 |
Toegevoegd Alt Text.
Bijgewerkte Titel, Inleiding, Branding Vereisten, Stijl Vereisten, Rondingen, het Opmaken en Grammatica. |
1.0 |
13-Aug-2021 |
Eerste vrijgave |