Call Troubleshooting
Der Cisco Callmanager arbeitet immer nach dem gleichen Schema Anrufe ab.
Sollte einmal bei einem Anruf ein Fast Busy (schnelles Tuten) im Hörer zu hören sein, gibt es verschiedene Punkte welche man prüfen kann und wo man ein Troubleshooting ansetzen sollte.
- Ist das Telefon ordnungsgemäß registriert?
- Hat der User ausreichend Rechte und ist die DN / User richtig konfiguriert?
- Ist das Dial Format im Telefon richtig?
- Ist der SIP Trunk von CUCM zu Gateway aktiv?
- Ist der SIP Trunk von Gateway zum Easybell Provider aktiv?
- Kommen die Anrufe richtig am Gateway an?
- Behandelt das Gateway die Anrufe richtig?
- Stimmt der ausgehandelte Codec?
Ist das Telefon ordnungsgemäß registriert?
Das sieht man sofort im Jabber oder am Hardphone selbst. Dies wird durch „Registering“ oder „No Connection“ angezeigt. Sollte das Telefon eine Registrierung suchen oder kann keine Verbindung zum Callmanager herstellen, kann auch kein Anruf nach außen oder innen getätigt werden. Der Callmanager sieht das Telefon als nicht aktiv an.
Hat der User ausreichend Rechte und ist die DN / User richtig konfiguriert?
Jeder User sollte eine eigene DN haben welche in einer Partition und in einem Calling Search Space liegt.
Hierbei gibt die Partition an (Bildlich gesprochen) in welcher Abteilung der User ist.
Der Calling Search Space gibt wiederum an, mit welchen anderen Abteilungen der User sprechen darf.
Sollte der User nicht die Berechtigung haben in einen anderen CSS / Partition zu rufen schlägt der Anruf fehl. Das passiert oft wenn es einen CSS für Nationale und einen CSS für Internationale Gespräche gibt. Sollte der User nur den Nationalen CSS inne haben, darf dieser auch nur Nationale Rufnummern Formate verwenden (0! Oder +49!). Internationale CSS User haben dann meist den nationalen und Internationalen CSS. Somit sollten die höher liegenden Gruppen immer berechtigt mit den niedrigeren zu kommunizieren.
Ist das Dial Format im Telefon richtig?
Hierbei spielen die Route und Translation Pattern eine wichtige Rolle.
Der Translation Pattern hat die Aufgabe ein empfangenes Rufnummern-Format umzuwandeln -> zum Beispiel: ich wähle 29 und der Translation Pattern macht daraus +497033XXXXXXX.
Der Route Pattern hingegen entscheidet wo ein Übersetzter Anruf hin gerouted werden soll. Hier in unserem Beispiel muss der Route Pattern merken, dass der Angerufene eine Interner User ist und muss diesen einem Registrierten Endgerät zustellen.
Also der Route List RL_CUCM_PUB-SUB. Das ändert sich dann je nach gewählten Rufnummern Format.
Ob ein Call von intern nach Extern richtig vom Callmanager behandelt wird lässt sich super mit dem DNA (Dialed Number Analyser) testen. Hierzu geht man auf Cisco Serviceabilty und wählt DNA aus.
Dort wechseln wir dann auf ANALYSIS und geben die Daten des Calls ein, den wir testen wollen. Sprich Calling Party, Called Party, Partition und CSS der Calling Party.
Danach wird eine Auswertung geöffnet welche euch den genauen Weg des Calls anzeigt, ob dieser überhaupt gerouted wird bzw. welche Pattern genutzt werden, welche Translation vorgenommen wird und welche RouteList am Ende steht. Sollte hier alles funktional aussehen müsst Ihr weiter zum SIP Trunk / Gateway wechseln für das Troubleshooting.
Das gleiche geht auch mit SIP-Uri’s wie loopback@rtp.ciscotac.net, dazu benötigt Ihr einen SIP-Route Pattern. Nicht vergessen.
Sollte wiedererwarten der Call nicht geroutet werden, sollte dort „Block this Pattern“ stehen und weiter unten dann der Grund für den Block Pattern. Hier wäre es „Unallocated Number“. Das heißt der Callmanager weiß nicht wohin er den Call routen soll, da das Format keinem bekannten Route Pattern entspricht. Hier solltet Ihr dann euren Dialplan überarbeiten.
Ist der SIP Trunk von CUCM zu Gateway aktiv?
Das lässt sich am schnellsten über CUCM -> Device -> Trunks validieren bzw. auch über das RTMT. Hierzu sollte dann der SIP Trunk „In Service“ geflaggt sein, wenn Ihr den „Options Ping“ im Sip Profil des Trunks enabled habt.
Ist der SIP Trunk von Gateway zum Easybell Provider aktiv?
Dazu müssen wir auf das entsprechende Voice Gateway und die SIP UA Konfiguration und die Verbindungen von TCP und UDP prüfen.
Dazu muss man den SIP UA Service mit folgenden Befehlen prüfen:
#sh SIP-Ua service SIP Service is up #sh SIP-UA connections tcp brief Total active connections : 2 No. of send failures : 1 No. of remote closures : 1 No. of conn. failures : 0 No. of inactive conn. ageouts : 230 -------------- SIP Transport Layer Listen Sockets --------------- Conn-Id Local-Address =========== ============================= 40 [192.168.178.2]:5060: #sh SIP-UA connections udp brief Total active connections : 1 No. of send failures : 11 No. of remote closures : 0 No. of conn. failures : 0 No. of inactive conn. ageouts : 441 -------------- SIP Transport Layer Listen Sockets --------------- Conn-Id Local-Address =========== ============================= 3 [192.168.178.2]:5060: 1#sh SIP-UA registration status registrar Line destination expires(sec) contact transport call-id peer ============================================================ 004ccccccccc sip.easybell.de 39 63.189.203.16 UDP XXXX-XXXXXX-XXXXX-XXXXX
Kommen die Anrufe richtig am Gateway an?
Dazu braucht man das Debugging auf dem Gateway an sich. Dieses sollte nur für die einzelnen Module die benötigt werden aktiviert sein und muss nach dem Debug auch wieder deaktiviert werden. Solltet ihr einmal „#debug all“ eingeben wollen, kann es sein das Ihr die Verbindung zum Gateway verliert, weil es komplett überlastet ist. Danach hilft nur neustarten.
Gut, um zu sehen wie ein Call genau ankommt ist der Befehl „#debug ccsip messages“ wichtig.
Mit #terminal monitor wird der Debug dann Live an der Console ausgegeben.
Aug 18 09:56:49.357: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Received: INVITE sipNummer@192.168.178.2:5060 SIP/2.0 Via: SIP/2.0/TCP 10.1.2.10:5060;branch=z9hG4bK52eb32d0ea088 From: "Nummer" <sip:s.hertel@deliberate.de>;tag=1102287~44f3066d-2cda-482c-a9df-fc44b76bcd16-24180421 To: <sip:Nummer@192.168.178.2> Date: Fri, 18 Aug 2017 09:56:49 GMT Call-ID: 8c280c00-9961b9e1-5191f-a02010a@10.1.2.10 Supported: timer,resource-priority,replaces Min-SE: 1800 User-Agent: Cisco-CUCM11.5 Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY CSeq: 101 INVITE Expires: 180 Allow-Events: presence, kpml Supported: X-cisco-srtp-fallback,X-cisco-original-called Call-Info: ;method="NOTIFY;Event=telephone-event;Duration=500" Session-ID: 00000c8300105000a000d050995c597b;remote=00000000000000000000000000000000 Cisco-Guid: 2351434752-0000065536-0000070933-0167903498 Session-Expires: 1800 P-Asserted-Identity: "Nummer" <sip:s.hertel@deliberate.de;x-cisco-number=+Nummer> Remote-Party-ID: "Nummer" <sip:s.hertel@deliberate.de;x-cisco-number=+Nummer>;party=calling;screen=yes;privacy=off Contact: <sip:s.hertel@10.1.2.10:5060;transport=tcp>;+u.sip!devicename.ccm.cisco.com="CSFHertel";bfcp Max-Forwards: 69 Content-Type: application/sdp Content-Length: 196
In diesen SIP Paketen kann man dann prüfen ob das Rufnummernformat eingehend sowie ausgehend stimmen und ob diese zum Dialpeer passen.
Behandelt das Gateway die Anrufe richtig?
Dazu verwendet man man z.B.: #debug ccsip translate oder transport dabei gilt es wie die Anrufe auf den incoming Dialpeers behandelt werden und ob diese überhaupt den outgoing Dialpeer treffen können.
Stimmt der ausgehandelte Codec?
Dazu verwendet man z.B.: #debug ccsip media und kann dann alle Codec’s prüfen und ob diese überhaupt ausgehandelt werden.
Let's go and write a comment