Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

SCCP-reservekopieën en -failover

Levensmiddelen behouden

failover

Normale failover

Uitgestelde failover

Terugloop

voordeel

SIP te behouden

Op primair

Naar secundair

Aanmelden vereist

Relevante links

Telefonisch opnemen

Capture from CUCM

Case Studie 1.2

Beschrijving van probleem

Problemen oplossen

Resolutie

Case Study 2.

Beschrijving van probleem

Problemen oplossen

Analyse

Oorzaak van de overlevingsdruppels

Inleiding

Dit document beschrijft informatie die kan worden gebruikt om problemen met uw configuratie op te lossen.

Cisco IP-telefoon gebruikt een mechanisme voor het behoud van het toepassingsniveau naast het TCP-niveau om het mechanisme in leven te houden. Houd-Alive mechanisme voor Secure Call Control Protocol (SCCP) en Session Initiation Protocol (SIP)-apparaten garandeert dat het apparaat geregistreerd blijft met Call Control Protocol. Ze zijn ook bedoeld om de verbinding van apparaten met oproepcontrole te herstellen.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

SCCP-reservekopieën en -failover

SCCP gebruikt TCP-protocol voor transport en het gebruikt de poort 2000 en 2443 (voor beveiligd) om verbinding te maken met Call Manager. De SCCP-telefoons moeten een TCP-verbinding maken met Cisco Unified Communications Manager (CUCM) voordat ze zich er in registreren. Waarna, zal een TCP 3 manier handshake op poort 2000 plaatsvinden om een communicatiekanaal op te zetten. De telefoon initieert deze verbinding door een SYN (synchroon) naar CUCM te verzenden en CUCM reageert met SYN, ACK (ontvangstbevestiging). De telefoon antwoordt op zijn beurt met een ACK en de TCP verbinding wordt gevestigd.

Levensmiddelen behouden

Er zijn twee methoden om in leven te houden: Toepassingsniveau (SKINNY-inlevingsniveau) en netwerkniveau (TCP-inlevingsniveau)

failover

In een ideaal scenario houdt een SCCP-telefoon een TCP-verbinding die ingesteld is op het primaire CUCM en de eerste back-up-CUCM. SCCP-telefoon houdt-in-leven naar alle CUCM waaraan het de TCP-verbinding heeft ingesteld. Primaire server reageert vervolgens op de SCCP-persistentie. Het tijdsinterval is 30 seconden tot primaire server en 60 seconden tot de reserveserver.

Het primaire CUCM antwoordt terug met SCCP keeplevive ACK die zowel SCCP als TCP verbinding erkent. De back-up-CUCM stuurt gewoon een TCP-ACK naar de in leven gehouden telefoon. Wanneer de telefoon geen back-up maakt van CUCM omdat de Call Manager-service niet beschikbaar is of omdat de TCP-verbinding zelf niet beschikbaar is met de primaire CUCM, gebruikt zij twee soorten mechanismen om de primaire CM-storing te detecteren en deze zijn normaal en vertraagd.

Normale failover

Deze methode gebruikt een algoritme om het gemiddelde van de tijd te berekenen die de CUCM heeft genomen om de eerdere "bewaaralives" te erkennen.

Als de gemiddelde tijd die door CUCM is genomen bijvoorbeeld X seconden is om te reageren op de afgelopen 10000 Conservation-alives, zal de telefoon X seconden wachten voordat hij de storing van CUCM detecteert. Daarna probeert het zich te registreren bij de back-up-CUCM.

Uitgestelde failover

In dit mechanisme wacht de telefoon op de 3 bewaarde intervallen om de mislukking van het primaire CUCM te detecteren.

Terugloop

Netwerken waar de transittijd van pakketten fluctueert, vertraagde failover helpt onnodige desregistratie te vermijden.

Voorbeeld van fluctuatie van de reistijd (noteer de tijdvertraging voor pingreactie):

64 bytes from 10.106.97.150: icmp_seq=1 ttl=63 time=0.100 ms

64 bytes from 10.106.97.150: icmp_seq=2 ttl=63 time=200 ms

64 bytes from 10.106.97.150: icmp_seq=3 ttl=63 time=0.180 ms

64 bytes from 10.106.97.150: icmp_seq=4 ttl=63 time=0.678 ms

64 bytes from 10.106.97.150: icmp_seq=5 ttl=63 time=590 ms

64 bytes from 10.106.97.150: icmp_seq=6 ttl=63 time=0.100 ms

64 bytes from 10.106.97.150: icmp_seq=7 ttl=63 time=345 ms

64 bytes from 10.106.97.150: icmp_seq=8 ttl=63 time=456 ms

64 bytes from 10.106.97.150: icmp_seq=9 ttl=63 time=0.345 ms

voordeel

Dit mechanisme kan in de vertragingsgevoelige netwerken worden gebruikt.

SIP te behouden

De SIP-telefoon registreert bij het CUCM en stuurt elke 120 seconden ingedrukt te houden volgens de instellingen in CUCM. Wanneer de telefoon het eerste register naar primair CUCM verstuurt, wordt de timer verloopt naar 3600 seconden ingesteld (standaard ingesteld in SIP-profiel dat op de telefoon wordt toegepast). CUCM stuurt een ACK door de timer te wijzigen naar 120 seconden zoals per de waarde ingesteld in Service parameter.

Daarom stuurt de telefoon om de 120 seconden in leven (in werkelijkheid 115 seconden, wat 120 min de delta waarde is die in SIP-profiel is ingesteld, dat standaard 5 seconden is). In dit geval stuurt de telefoon elke 115 seconden in leven.

SIP-telefoon geeft het Registratiebericht aan Backup CUCM door Extend veld in te stellen op 0.

Op primair

REGISTER sip:10.106.114.161 SIP/2.0

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

Max-Forwards: 70

Date: Wed, 15 Jul 2015 12:42:56 GMT

CSeq: 11435 REGISTER

User-Agent: Cisco-CP7975G/9.3.1

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-6.0.0,X-cisco-xsi-8.5.1

Content-Length: 0

Expires: 3600

SIP/2.0 100 Trying

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Content-Length: 0

SIP/2.0 200 OK

Via: SIP/2.0/TCP 10.106.114.185:53006;branch=z9hG4bKd451a4fa

From: <sip:5678@10.106.114.161>;tag=0024142ddf242c6644b6e5d2-f01c795a

To: <sip:5678@10.106.114.161>;tag=1708299782

Date: Wed, 15 Jul 2015 12:42:59 GMT

Call-ID: 0024142d-df24000a-44da4e09-0de51424@10.106.114.185

CSeq: 11435 REGISTER

Expires: 120

Contact: <sip:9e9e1ffb-0206-4ea1-6d77-ba04a72017f7@10.106.114.185:53006;transport=tcp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024142ddf24>";+u.sip!devicename.ccm.cisco.com="SEP0024142DDF24";+u.sip!model.ccm.cisco.com="437"

Supported: X-cisco-srtp-fallback,X-cisco-sis-6.0.0

Content-Length: 0

Naar secundair

REGISTER sip:10.60.1.12:5060;transport=tcp SIP/2.0

Via: SIP/2.0/TCP 10.60.63.21:3784;rport;branch=z9hG4bKPjdcJ819aZtTCtmvr0VBheV6p0uL8aC.pG

Max-Forwards: 70

From: <sip:6836@10.60.1.12>;tag=5oI-ew53.DGjTDu5LB9orkdDpZlccNbv

To: <sip:6836@10.60.1.12>

Call-ID: HxTK.m6BH9qxjstVwexTbhVnUxNeuxle

CSeq: 18800 REGISTER

Expires: 0

Contact: <sip:e2b0f175-feae-d664-befa-b7cd0837fcc6@10.60.63.21:5060;transport=TCP>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-e0d1730ac1b1>";+u.sip!devicename.ccm.cisco.com="SEPE0D1730AC1B1";+u.sip!model.ccm.cisco.com="592";expires=0;cisco-keep-alive

Content-Length:  0

Aanmelden vereist

Om te kunnen achterhalen waarom de telefoon is uitgezet, verzamelt u informatie over:

- Toepassingsvenster en systeemmeldingen - biedt alarmcodes/foutcodes voor het niet registreren van telefoons en voor het gebruik van de functies die we kunnen oplossen.

- Packet shot van de telefoon en de CUCM (zowel primair als back-up) tegelijkertijd helpen bij het isoleren van het IP-netwerkperspectief.

- Cisco Call Manager Traces.

Relevante links

Verzamelen van pakketvastlegging via CUCM

Verzamelen van opname vanaf IP-telefoon

CUCM-sporen verzamelen

De vastlegging en pakketvastlegging analyseren

- EndPoint-niet-geregistreerde boodschap in het venster Application Viewer afdrukken en bovendien een verwante redeneringscodes.

Example: 31 uc-ucm-01 local7 3 : 41679: uc-ucm-01.pcce.local Jul 02 2015 06:22:31 UTC :   %UC_CALLMANAGER-3-EndPointUnregistered: %[DeviceName=SEPE0D1730A8137][IPAddress=10.60.98.210][Protocol=SIP][DeviceType=592][Description=Phone][Reason=13][IPAddrAttributes=0][LastSignalReceived=SIPStationDPrimaryLineTimeout][AppID=Cisco CallManager][ClusterID=StandAloneCluster][NodeID=uc-ucm-01]: An endpoint has unregistered

De codes van de reden voor EndPointUnregistration zijn te vinden in documentatie van systeemfoutmeldingen.

Logboeken voor draadloos haai lezen

Wanneer Captures van beide kanten worden verzameld, om te verifiëren dat het behouden dat per telefoon wordt verstuurd daadwerkelijk het CUCM bereikt of niet.

Volgnummer van het TCP-pakket zal helpen het TCP-verkeer tussen telefoon en CUCM bij het opsporen van scherpschutters eenvoudig te volgen.

Telefonisch opnemen

Bel een pakket met volgnummer 2991996107 en controleer of dit pakket de CUCM bereikt.

Capture from CUCM

Het volgnummer dat in de telefoonsnuffelopname wordt weergegeven, moet in de CUCM-opname worden weergegeven.

Case Studie 1.2

Beschrijving van probleem

SCCP-telefoons blijven regelmatig opnieuw starten.

Problemen oplossen

Het logbestand van het evenement Viewer geeft aan dat de telefoons die opnieuw beginnen als gevolg van het ontbreken van een beveiliging, alives met foutcode 13 bevatten.

Event Viewer Message.

Verzamel pakketvastlegging vanaf IP-telefoon en CUCM.  In dit scenario, kwam de laatste in leven gehouden die van IP Telefoon werd verstuurd niet CUCM te bereiken.

Image.

Levend blijven is om deze reden gedaald:

Wanneer de telefoon een ARP stuurde om het MAC-adres van CUCM te krijgen, kwam de reactie binnen van ARP Proxy met ASA mac-adres. Het eerste antwoord kwam duidelijk niet van CUCM. Maar omdat de telefoon het eerst ontvangt, wordt het frame naar de schakelaar verzonden met het MAC-adres van het andere apparaat.

Dit gebeurt meestal wanneer ARP-proxy is ingeschakeld op ASA.

Resolutie

ARP Proxy op ASA uitschakelen om het probleem aan te pakken.

Case Study 2.

Beschrijving van probleem

Cisco IP-telefoonmodel 8961 telefoons worden elke 16 minuten gereset en registreren op secundaire CUCM. Na 2 minuten valt de telefoon terug op Primair CUCM en gaat dit programma door.

Problemen oplossen

Verzamel Packet-opnamen van de telefoon- en CUCM-sporen. De niet-registratie was te wijten aan het feit dat SIP de IP-telefoon niet wist te overleven.

Analyse

De SIP-telefoon registreert bij het CUCM en wordt elke 120 seconden ingedrukt volgens de instellingen in CUCM.

Wanneer de telefoon het beginregister verstuurt, wordt de timer verlopen naar 3600 seconden (standaard ingesteld in SIP-profiel dat op de telefoon wordt toegepast). CUCM erkent het door de timer te wijzigen naar 120 seconden zoals per de waarde die in Service parameter is ingesteld.

De telefoon verstuurt Keeplive elke 120 seconden ( het interval dat de bewaar leeft is 115 seconden dat 120 min de delta waarde gevormd in SIP profiel is, dat 5 seconden door standaard is). In dit geval stuurt de telefoon elke 115 seconden in leven.

In dit probleemscenario verstuurt de telefoon de eerste keeplevend op 115 seconden en wordt het in het netwerk laten vallen. Dit resulteert in het terugsturen van de keeplevend in 0,01 seconden (100 ms). Het krijgt een antwoord van CUCM voor het REGISTER-verzoek.

De telefoon stuurt de tweede keeplevat op 115 seconden en wordt in het netwerk gevallen. Nu verhoogt de telefoon het regISTER-interval tot 0,02 seconden (200 milliseconde).

Iedere keer als de telefoon na 115 de keeplevenden verstuurt, wordt hij in het netwerk gevallen en maakt hij de telefoon om het pakket opnieuw te verzenden. Ook de telefoon verhoogt exponentieel het interval van het opnieuw proberen. Na weinig van dergelijke bewaaralives neemt de telefoons opnieuw toe tot 14 seconden.

De telefoon wordt na 14 seconden opnieuw uitgezonden en krijgt een ACK van de CUCM.

De volgende keer dat de telefoon in leven houdt, gaat het verloren en dan stuurt de telefoon REGISTER-aanvraag na 28 seconden terug. De CUCM kan niet 28 seconden wachten. Hij wacht slechts 15 seconden (na de jaren 115). Daarna wordt het niet-geregistreerde signaal verzonden.

De behoudtijd en de RTO bedragen 16 minuten en een paar seconden.

Na 16 minuten vanwege het niet-registreren signaal van CUCM, registreren de telefoons op secundair CUCM en na 2 minuten registreren ze terug op Primair. Dit gaat zo door.

Oorzaak van de overlevingsdruppels

Wanneer de switchpoort werd ingesteld met poortbeveiliging, werd de poortvergrijzing ingesteld met inactieve timer. De timer is ingesteld op één minuut, wat minder is dan de timer voor de SIP-behoud. Dit resulteerde in switchpoort die de telefoon MAC elke minuut spoelde. De pakketten blijven vallen aangezien het SIP interval om de 2 minuten in leven is.