Probleemoplossing voor CallConnector op TC-endpoints die zijn geregistreerd in Cisco CallManager

Inleiding

Dit document verklaart een aantal van de gebruikelijke problemen met betrekking tot gespreksfalen waarmee Tandberg Codec (TC)-endpoints worden geconfronteerd en die voor Cisco CallManager zijn geregistreerd, en stelt oplossingen voor.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

Hoe u H.323 vastlegt, debug-kaarten

Opmerking: Zorg ervoor dat de Secure Socket Host (SSH) sessieuitvoer wordt opgenomen.

1. SSH in de codec CLI en voer deze opdrachten in:
   • log CX H.323 Packet debug 9
   • Loguitvoer op (Deze uitvoer voert alle logbestanden uit naar het SSH-sessietraster.)
2. Begin een gesprek en herhaal het probleem.
3. Voer de loguitvoer van en logctx H.323 Packet in om opdrachten af te breken.

Vastlegging sessieInitiation Protocol (SIP) oplossen

Opmerking: Zorg ervoor dat de SSH-sessie wordt opgenomen.

1. SSH in de codec CLI en voer deze opdrachten in:
   • logCX SIPALPacket debug 9
   • Loguitvoer op (Deze uitvoer voert alle logbestanden uit naar het SSH-sessietraster.)
2. Begin een gesprek en herhaal het probleem.
3. Voer de loguitvoer van en de logoptie Ctx SIPacket in om de opdrachten van de taak te debug.

Capture/endpoint-kaarten verzamelen bij TC-endpoints

1. Kies in de webGUI diagnostiek > Log bestanden en laat uitgebreide vastlegging met volledige pakketvastlegging mogelijk.
2. Begin een gesprek en herhaal het probleem. Let op dat de pakketvastlegging slechts 3 minuten kan worden ingeschakeld.
3. Kies in de webGUI diagnostiek > Logbestanden en download het volledige logarchief en de pakketvastlegging.

Overige informatie vereist

• Complete aanloopstroom met alle betrokken apparaten
• Bel en bellen
• Datum en tijdstip van uitgifte

Gebruikte componenten

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.

Probleem: Gespreksfouten vanwege Call Search Space (CSS)/Partition Issue in CallManager

De verbinding tussen twee endpoints die bij Cisco Unified Communications Manager (CUCM) zijn geregistreerd, kan onjuist zijn door een probleem met CSS/Partition op het CUCM.

Leg de oproepende SIP-logs vast. Dit bericht "404 Not Found" verschijnt op SIP-logs met endpoints die afkomstig zijn van CUCM:

 |SIP/2.0 404 Not Found
 Via: SIP/2.0/TCP 172.16.2.55:5060;branch=z9hG4bK26e12a6fbed832;received=172.16.2.55
 Call-ID: 77fec00-564180a1-1eec8b-370210ac@172.16.2.55
 CSeq: 101 INVITE
 From: <sip:1502@172.16.2.55>;tag=158127671
 To: <sip:4659@172.16.2.53>;tag=654ba920aeef9e74
 User-Agent: Cisco-CUCM10.5
 Content-Length: 0

Oplossing

Voltooi deze stappen om de CSS van het Calling-eindpunt en de verdeling van het opgeroepen eindpunt te controleren. Zorg ervoor dat de CSS van het Calling-eindpunt de scheiding van het opgeroepen eindpunt heeft.

U kunt een CSS op het niveau van het apparaat en de lijn toewijzen op het eindpunt:

1. Kies apparaat > telefoon, selecteer het eindpunt en klik op de lijn en controleer de zoekruimte (CSS) op het lijnniveau. In dit voorbeeld worden er geen CSS op lijnniveau geconfigureerd. Als er echter een CSS is op het niveau van het directoraatnummer, moet een van de CSS-instellingen een deel van het opgeroepen nummer hebben:

   

2. Controleer de CSS op het telefoonniveau. Kies apparaat > telefoon en selecteer het aanroepende eindpunt in kwestie:

   

3. Controleer de verdeling van het geroepen nummer. Kies apparaat > telefoon, selecteer het opgeroepen apparaat, klik op de lijn en controleer de routeoptie:

   

4. Nadat u de Partiton en CSS op beide eindpunten hebt geverifieerd, controleert u of de CSS van het oproepende apparaat de opdeling van het opgeroepen apparaat heeft:

   

   Is dit niet het geval, dan is dit mogelijk de oorzaak van de fout "404 Not found".

Probleem: SIP-gespreksdaling na 15 minuten (of na een specifieke tijd)

Over het algemeen worden aanroepen vallen op specifieke tijdstippen veroorzaakt door SIP-timers of TCP-onderbreking die op firewalls, routers, enzovoort is ingesteld.

Oplossing

Wanneer de verbinding op precies 15 minuten wordt verbroken, is het bekende probleem dat wordt gezien de TCP-onderbreking die op het netwerk is ingesteld (firewalls, routers) minder dan de SIP-sessie verloopt. De standaardinstelling voor CallManager is dat de SIP Session Expire Timer is ingesteld op 1800 seconden.

Om dit te verifiëren, kies Cisco Unified CM-beheer > Systeem > Serviceparameters > Cisco Call Manager Service > Zoeken naar - SIP-sessie Verloopt timer.

Alle endpoints die geregistreerd zijn op CUCM gebruiken deze timer. Wanneer het eindpunt op vraag met een ander ver eindpunt is, moet één van de partijen de sessie verfrissen en een nieuwe INVITE of UPDATE sturen. Dit verfrissen moet worden verstuurd voordat de helft van de Session Verloopt Timer (1800/2 = 900 seconden = 15 minuten). Als er geen verfrissingsbericht wordt ontvangen, wordt de vraag losgekoppeld.

Schakel deze optie in op sessiemtimer in het oorspronkelijke INVITE. U dient een verfrissing (INVITE / UPDATE) te ontvangen voordat deze tijd afloopt:

|INVITE sip:+1234@10.108.64.22:5060;transport=tcp SIP/2.0
 Via: SIP/2.0/TCP 10.110.68.38:5060;branch=z9hG4bK00eed555
 Call-ID: dbfe0000-4491f669-9fd00-16406c0a@10.108.64.22
 CSeq: 1 INVITE
 Contact: <sip:30048@example.com;gr=urn:uuid:f7a3a098-ead8-5512-85ef-26ae544d6547
   >;isfocus;x-cisco-tip
 From: "TP Conference 30048 - Test" <sip:30048@10.110.68.6>;tag=86251172C3B60000
 To: <sip:1234@10.108.64.22>;tag=25983910~226bf657-9d6c-4ad9-98a2-cf842fe1d733-52629917
 Max-Forwards: 70
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Route: <sip:proxy-call-id=53a00ced-68e1-4ecd-872b-1edbb9abc75b
 @10.110.68.6:5060;transport=tcp;lr>
 Allow: INVITE,ACK,CANCEL,OPTIONS,UPDATE,INFO,SUBSCRIBE,NOTIFY,BYE
 User-Agent: TANDBERG/518 (TC6.2.0.20b1616)
 Supported: timer,outbound,record-aware,X-cisco-callinfo
 Session-Expires: 1800;refresher=uac

Op basis van de initiële User Agent Client/User Agent Server (UAC/UAS)-onderhandeling, verfrist een van de eindpunten de sessie wanneer deze opnieuw wordt gestart. Als de herhaling UAC is, is de initiatiefnemer van de oproep verantwoordelijk om de sessie te verfrissen. Als de extra waarde UAS is, moet de server de sessie verfrissen. Verzamel het SIP debug-logbestanden van beide eindpunten en controleer deze items:

Voorbeeld: Bel van partij A naar CUCM naar partij B. Als de drempel UAC op partij A en VS op partij B is:

1. Partij A moet het opnieuw INVITE / UPDATE naar de CUCM sturen.
2. CUCM moet een nieuw INVITE / UPDATE naar partij B sturen.
3. Partij B ontvangt het bericht opnieuw INVITE en reageert daarop met een OK van 200.
4. CUCM moet 200 OK sturen naar partij A.

Als het ene eindpunt het opnieuw INVITE-bericht naar het CUCM stuurt, stuurt CUCM een nieuwe INVITE naar de andere partij. Als dit echter niet door de afgelegen zijde wordt ontvangen, kan dit zijn vanwege bepaalde netwerkapparaten ertussen. Het is zeer mogelijk dat de herINVITE/respons niet aan één kant komt door de SIP-inspectie of netwerkinstellingen.

Als de eindpunten niet opnieuw INVITE starten, kan dit een probleem zijn met het eindpunt. Neem contact op met Cisco Technical Assistance Center (TAC) om verder te onderzoeken.

Probleem: H.323 gespreksdruppels na een bepaald tijdstip

Zoals met SIP, in H.323 vraag daalt de vraag bij een specifiek tijdinterval gewoonlijk door netwerk of de configuratie van de firewalltijd.

Oplossing

In H.323-oproepen wordt elke 30 seconden tussen endpoints en sequentienummers een RTDR-bericht (round Trip Delay Application) verzonden. Voor elk verzoek wordt een antwoord verwacht.

Cisco Endpoint maakt gebruik van het RTDR/Ronde Trip Delay Response-bericht, dat deel uitmaakt van het H.245 Multimedia System Control-bericht. Dit houdt de H.245 TCP sessie levend tijdens de vraag die voor actief telefoonbeheer wordt gebruikt. Als het eindpunt een reactie voor RTDR ontvangt aanvankelijk en geen reactie tijdens de vraag wordt ontvangen, beëindigt het eindpunt de vraag.

In dit scenario, verzamelt u de H.323 debug-logbestanden en endpointlogs om het probleem te isoleren. Van de H.323 debug logbestanden, controleer dan naar de RTDR-aanvraag en de antwoordberichten en ontdek of deze vallen.

In deze voorbeelduitvoer, stuurt het eindpunt een RTDR- verzoek naar het verre eindpunt en het ontvangt geen antwoord van het verre eind. Het sluit derhalve de oproep af:

 014-09-23T21:37:01+10:00 corevcs1 tvcs: UTCTime="2014-09-23 11:37:01,
 711"Module="network.H.323" Level="DEBUG":  Dst-ip="10.0.20.11"  
 Dst-port="11012" Sending H.245 PDU: value MultimediaSystemControlMessage
 ::= request : roundTripDelayRequest : {   sequenceNumber 120

De verzoeken en antwoorden kunnen worden gevolgd met sequentienummers.

Dit voorbeeld van de eindpunten toont de oorzaak voor de ontkoppeling:

2977610.83 H.323Call I: H.323_call_handler::handleDiscInd(p=349, s=1) 
Received disconnectindication (Cause: 12:18, H.323 cause: 3:18)- 
NetworkRejected Q85012977610.84 MC I: RemoteParticipant::
reevalRefMode(p=349,ch=2) set ref [Video (2): vid-off0x0@0.0  0k ] 
q= auto, t60=600012977610.84 ModesController I: ModesController::
resetRateLimit(ch=2)12977610.84 MC I: RemoteParticipant::modeChanged
(p=349, ch=2): ModesController wants torun mode: Video (2): vid-off 0x0@0.0  0k

Probleem: Oproeproutering als gevolg van fouten in de toewijzing van mediamiddelen

In het geval van videogesprekken, worden oproepen die mislukken vanwege een fout in de toewijzing van media gezien. Als bijvoorbeeld het aanroepen en het aangeroepen eindpunt geen gemeenschappelijke codec ondersteunen dan is een transcoder vereist, voor een Dual Tone Multi Frequency (DTMF) mismatch een Media Termination Point (MTP) is vereist op de Call Manager.

Oplossing

Voor videotranscodering is een Packet Voice Digital Module-transcoder (PVDM3) voor digitale signaalprocessor (DSP) vereist, omdat transcoders op PVDM2 geen video ondersteunen. Als er geen transcoder/MTP beschikbaar is, wordt er een 503 Service-onbeschikbaar bericht naar het eindpunt verzonden:

SIP/2.0 503 Service UnavailableVia: SIP/2.0/TCP 10.101.15.13:
5060;branch=z9hG4bK954956da2012413dfb6ef80d6bc9e373.1;rportFrom:
 <sip:3550@10.102.254.4>;tag=47c4717d0db85e1aTo:
 <sip:1281@10.102.254.4>;tag=176803~66dd1c7a-eac9-42af-a69b-
18da1695a800-31478649Date: 
Wed, 19 Feb 2014 16:10:05 GMTCall-ID: 
c05df2acedcafd063eb5cf947ebc1efcCSeq: 100 INVITEAllow-Events: 
presenceReason: Q.850;cause=47Content-Length: 0 

Om dit op te lossen, controleert u de configuratie van de Media Resource Group/Media Resource Group (MRG/MRGL) en controleert u of er videotranscoder/MTP beschikbaar is. Een MRGL kan aan een apparaat op het niveau van de telefoon of het niveau van de pool van het apparaat worden toegewezen:

1. Kies in CallManager apparaat > telefoon en selecteer het apparaat dat het probleem heeft en controleer de Apparaatpool en de instellingen voor MRGL:

   

2. Als de MRGL-instelling op de telefoon Geen is, moet u de instellingen van de pool van het apparaat controleren om er zeker van te zijn dat er een transcoder is.
3. Kies Systeem > Apparaatpool en selecteer de pool die aan het apparaat is toegewezen:

   

4. Kies Media Resources > Media Resource Group List en selecteer de MRGL die is toegewezen op het niveau van de telefoon-/apparaatpool en controleer de MRG’s:

   

5. Merk de MRG's op en kies Media Resources > Media Resource Group en selecteer de genoteerde MRG's. Zorg ervoor dat u een PVDM3 hardwaretranscoder/MTP toegevoegd hebt.

   

Probleem: Gespreksfouten vanwege onvoldoende bandbreedte

Vaker dan niet zijn er scenario's waar een vraag wordt losgekoppeld vanwege de ontoereikende bandbreedteconfiguratie in Gebied/Plaats op het apparaat in CUCM. Wanneer het gebied wordt ingesteld op een lage bandbreedte die het eindpunt niet kan ondersteunen, stuurt CallManager een "488 Niet Aanvaardbare Media" met oorzaak 125 die "Uit bandbreedte" of "Onvoldoende Bandbreedte" betekent nadat de SIP media onderhandeling plaatsvond.

U moet de SIP-logs op het eindpunt vastleggen zoals beschreven en naar dit bericht zoeken:

1459.81 SipPacket I: PacketDump: Proto: SIP, Direction: Incoming, Name: 488 
Not Acceptable Media, CSeq: 100 INVITE, RemoteAddress: 10.106.85.219:5060, 
CallId: 207b6ddb148ddf900ae2e2f844115837, Time: 1459811
	1459.81 SipPacket   SIP/2.0 488 Not Acceptable Media
	1459.81 SipPacket   Via: SIP/2.0/TCP 10.106.85.231:56280;
branch=z9hG4bK64e2eb4a1a3afd5f956a1547eb1c05ad.1;rport
	1459.82 SipPacket   Call-ID: 207b6ddb148ddf900ae2e2f844115837
	1459.82 SipPacket   CSeq: 100 INVITE
	1459.82 SipPacket   From: <sip:4657@example.com>;tag=2d98ee2065ba492d
	1459.82 SipPacket   To: <sip:1112@10.106.85.219>;
tag=10543~8c84fc84-78bb-de4d-3ac7-da2a9cab63d5-19683975
	1459.83 SipPacket   Server: Cisco-CUCM10.5
	1459.83 SipPacket   Date: Sun, 07 May 2015 14:36:41 GMT
	1459.83 SipPacket   Allow-Events: presence
	1459.83 SipPacket   Warning: 370 10.106.85.219 "Insufficient Bandwidth"
	1459.83 SipPacket   Reason: Q.850 ;cause=125
	1459.83 SipPacket   Content-Length: 0
	1459.83 SipPacket   
	1459.83 SipStack I: SipDialog(ui=3,s=9) sendInviteRejToStack (488:Not Acceptable Media)
	1459.84 SipCall I: sip_call_handler::handleSIPMCallRej(3/9/-1): Call rejected
 (cause: Not Acceptable Media)
	1459.84 MainEvents I: CallDisconnectRequested(p=3) remoteURI='sip:1112@10.106.85.219'
 cause=[normal('') 'LocalDisconnect']
	1459.84 MainEvents I: ParticipantLeftConference(c=2,p=3)
	1459.85 APPL_Media ERROR: AudioCtrlImpl::execute_disconnectInputOutput 
No mixer for (p=1,ch=61)
	1459.85 MainEvents I: CallDisconnected(p=3) remoteURI='sip:1112@10.106.85.219' 
causeToLocal=[disconnected('Not Acceptable Media') 'RemoteDisconnect'] 
causeToRemote=[normal('') 'LocalDisconnect']

Oplossing

Als dit probleem zich voordoet, controleert u de regio die op beide eindpunten is geconfigureerd en controleert u de regionale relatie tussen de eindpunten:

1. Kies apparaat > telefoon en selecteer beide apparaten. Controleer het apparaat dat aan de apparaten is toegewezen:

   

2. Nadat u de Apparaatpool controleert, kiest u Systeem > Apparaatpool op de CUCM en controleert u de regio die is geconfigureerd op beide Apparaatpools:

   

3. Kies systeem > informatie over de regio > regio's en controleer de relatie met de regio. Controleer de audio-video-bandbreedte in het gebied en zorg ervoor dat het eindpunt bij de audio/video bandbreedte zoals geselecteerd kan werken:

   

In de bovenstaande screenshots wordt aangenomen dat het ene eindpunt in de regio "Trunk Region" ligt en het andere in de "Local Endpoints Region".

Een andere oplossing is om het videogesprek als Audio Call te proberen als de bandbreedte voor de videoroep onvoldoende is. Gebruik deze procedure om de configuratie van het apparaat te controleren en in te stellen:

1. Klik op Apparaat > Telefoon en selecteer het aanroepende Apparaat met het probleem. Controleer of de parameter in deze screenshot is ingeschakeld. Als er geen controle op is, controleer dit dan zodat een videogesprek terugvalt naar audio in geval van problemen met bandbreedte:

   

   Deze kwestie zou door plaatsinstellingen op CallManager kunnen gebeuren.

   De locaties kunnen worden toegewezen op het niveau van de telefoon of op het niveau van de pool van het apparaat (het telefoonniveau neemt een hogere prioriteit).

2. Om de plaatsinstellingen van het Niveau van de Telefoon te controleren, kies Apparaten > Telefoons en controleer de plaats op zowel oproepend als geroepen eindpunt:

   

   De locatie kan ook worden toegepast op het niveau van de apparaatpool. Controleer daarom eerst de apparaatpool van beide eindpunten:

   

3. Kies Systeem > Apparaatpool. In de apparaatpool controleert u de locatie die is toegewezen op zowel de oproepende als opgeroepen eindpunten. In dit voorbeeld wordt geen locatie toegewezen op het niveau van de apparaatpool. De configuratie van de telefoonlocatie wordt gebruikt:

   

4. Controleer of er voldoende bandbreedte is ingesteld tussen de oproepende en opgeroepen eindpunten. In dit voorbeeld wordt verondersteld dat één eindpunt in de plaats van de Lokale Eindpunten is en het andere in de plaats Hub_Geen is en de bandbreedte voor audio/video en de onderdompeling vraag wordt gevormd als Onbeperkt:

   

Er kunnen andere redenen zijn voor het afsluiten. Zie pagina 178 van de Cisco Unified Communications Manager Call Detail Administration Guide, release 10.0(1) voor codes van de disconnectie-oorzaak.