So nach langem Schweigen gibt es hier mal wieder ein paar aktuelle Sachen, mit denen ich mich rumgeärgert habe. Da es nun so ist, dass ich mehr und mehr im Netzwerk rumbastel werden die Themen in Zukunft etwas mehr auf Cisco eingehen, was aber sicher auch nicht schlecht ist. Weiterhin werde ich mal versuchen, ein paar für mich interessante Dinge zu posten, die natürlich auch IT bezogen sind.
Ich arbeite immer noch fleißig an meinem Cisco Certified Voice Professional (CCVP) und komme so auch ab und an mal auf Themen aus der VoIP Telefonie zu sprechen.
So haben wir hier ein neues Voicegateway (Cisco 2811) installiert, da das Alte 2600XM keine Config mehr speichern wollte. Nun zum Glück ist es mir aufgefallen, da wir in den letzten 2,5 Jahren keinen Stromausfall oder etwas in der Art hatten und ich dann vor einem Gateway gestanden hätte, was keine Config mehr hat.
Nun ein 2811 ist eigentlich aktuell und auch gut auf dem Markt verbreitet. Problematisch war hierbei nur, dass wir den Cisco 2811 als H323 Gateway einbinden mussten weil der Callmanager noch Version 3.3 ist und diese Version natürlich noch keine 2800er Geräte kennt und so auch nicht MGCP angewendet werden konnte.
Das macht die ganze Aktion natürlich etwas spannender und man kann sein angeeignetes Wissen auch mal praktisch anwenden. Nach mehreren Fehlversuchen hat es dann auch irgendwann funktioniert. Auch SRST hat auf Anhieb funktioniert, was ich nicht gedacht hätte.
Nun aber mal mein Probleme bei den ersten Versuchen und deren Lösung.
Beim ersten Versuch habe ich das Voicegateway mit entsprechender Config angeschlossen und kam nicht drauf. Kein Ping möglich nichts. Ethernet war aber up. Naja dummer Fehler, denn ich hatte den Port auf dem Switch nicht in das entsprechende VLAN gebracht und somit kam natürlich auch keine Verbindung zustande.
Als das dann gelöst war kam auch schon mal das Gateway hoch und hat auch die 32 Leitungen eines PRI hoch gebracht. Ein "show isdn status" sollte dann ein "MULTIPLE_FRAME_ESTABLISHED" anzeigen.
Global ISDN Switchtype = primary-net5
ISDN Serial0/0/0:15 interface
dsl 0, interface ISDN Switchtype = primary-net5
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Nur bei den ersten Testanrufen war schon zu sehen, dass auf dem Gatway die 0 von der Vorwahl abgeschnitten wurde, was man mit einem "debug isdn q931" sehr gut sehen konnte. Bei ankommenden Anrufen war auch noch ein Fehler. Bei jedem Call kam nur eine Debug-Meldung "Cause i = 0x8081 - Unallocated/unassigned number". Also telefonieren war nicht wirklich möglich. Nun der erste Gedanke ist, es muss was mit den Translation-Rules zu tun haben. Also nochmal nachgeschaut und keine Fehler gefunden. Aber was mir aufgefallen war, dass eine Translation-Rule ja die angerufene Nummer (DNIS) auf die drei Stellen der Durchwahl kürzt. Somit hat mein dial-peer nicht mehr gepasst, der noch auf die komplette Nummer gematched hat. Also dial-peer angepasst und schon ging es.
Alte (falsche) Config:
voice translation-rule 1
rule 1 /^555420/ /900/
rule 2 /^55542\(...\)/ /\1/
!
dial-peer voice 1 voip
destination-pattern 55542[1-9]..
Neue Config:
voice translation-rule 1
rule 1 /^555420/ /900/
rule 2 /^55542\(...\)/ /\1/
!
dial-peer voice 1 voip
destination-pattern .T
Ausgehen hatte ich aber immer noch das Problem mit der fehlenden 0. War dies nun auch ein Problem einer Translation-rule oder wurde es vom Callmanager schon falsch übergeben? Nochmals alles rules durchgeschaut und keinen Fehler gefunden. Also war es der Callmanager. Nach einigem Suchen und probieren war die Ursache gefunden und gleich noch einen weiteren Fehler gefunden. Die Lösung lag auch hier wieder an dem Dial-peer, diesmal allerding das pots dial-peer und am Callmanager.
Um einen externen Anruf zu tätigen muss man ja erstmal eine 0 für die Amtshohlung wählen und dann eben die komplette Nummer mit Vorwahl der Stadt, die ja auch eine 0 beinhaltet. Da auf dem Gateway aber gar keine 0 ankam musste es auch zwei Stellen geben an den die 0 abgeschnitten wird.
Das passende Route-Pattern "0.0[^0]XXX" hat schon mal die erste 0 weggekürzt mit "Discard digits - PreDot". Das Gateway hat dann also die Nummer mit nur einer 0 bekommen und das destination-pattern bei dem dial-peer war auf 0T konfiguriert, was dann noch die verbliebene 0 wegschneidet. Also einfach auf dem Callmanager "Discard digits - None" eingetragen und schon funktionieret auch das.
Das zusätzlich entdeckte Problem betrifft auch die Route-Pattern. Da das alte Gateway ein MGCP Gateway war hat es einfach alles genommen, was der Callmanager an Ziffern übergeben hat und hat diese brav an das PSTN weiter gegeben. So hat der Callmanager solange gewartet bis das erste Route-Pattern gepasst hat und hat dann alles an das entsprechende Gateway weiter gegeben auch Nummern die nachgewählt werden. Wenn also jemand vier Ziffern gewählt hatte ging es schon ab ins Telefonnetz. Nun H323 nimmt aber nur den ersten Teil, der vom Callmanager kommt und ignoriert alles was nachgewählt wird. Somit kam bei einem Anruf an die 089555420 mit dem Route-Pattern 0.0[^0]XXX nur 08955 auf dem Gateway an, was keine komplette Nummer darstellt. Die Route-Pattern mussten also auch noch angepasst werden auf 0.0[^0]!, was zur Folge hat, dass der Callmanager wartet ob fertig gewählt wurde. Hier greift dann entweder der T302 Timer, der standardmäßig auf 15 Sekunden eingestellt ist. Wir haben ihn jetzt auf 5 Sekunden eingestellt. Man kann aber auch einfach am Ende der Nummer noch eine # wählen, das ist das Zeichen, woran der Callmanager erkennt, dass die Nummer komplett ist und schon mal an das Gateway weiter geben kann.
Bei dem T302 Timer muss man aber aufpassen, denn dieser ist nicht nur für das interdigit timeout verantwortlich sondern gibt auch vor wie lange der Callmanager wartet bis ein Call zustande kommt bevor er meldet, dass die Nummer unbekannt ist. Beide Male wird also auf ein "Setup Ack" gewartet.
"T302 Timer : This parameter specifies an timer for sending the SETUP ACK message."
Nun nach all den Sachen funktioniert das Gateway seitdem ohne Probleme und verrichtet brav seinen Dienst.
