moonjumper's admin blog

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.

Soweit laufen unsere Vistamaschinen sehr stabil und es gab bisher auch keine Probleme. Aber heute mal wieder was neues.
Beim Anmelden eines Benutzers an Windows Vista kommt die Meldung "Die Anmeldung des Dienstes "Benutzerprofildienst" ist fehlgeschlagen.".
Das ein Benutzerprofil mal nicht gealden werden kann, kennt man ja auch von Windows XP oder Windows 2000. Hier hat man dann einfach den Profilordner unter "C:\Dokumente und Einstellungen\" umbenannt und schon wurde ein neues Profil angelegt. Wenn man Glück hatte wurde der benutzer einfach mit einem temporören Profil angemeldet, was anch einem Neustart des Rechners aber wieder behoben war und die Benutzereinstellungen normal geladen wurden.
Natürlich versucht man dies auch gleich erstmal bei Windows Vista. Aber erfolgreich war ich dabei nicht. das Umbennen des Profilordners ist nur mit Adminrechten möglich, was bei Vista mit eingeschalteter Benutzerkontensteuerung einige Bestätigungen abverlangt. Aber es ging immer noch nicht. Also wurde dann doch mal gesucht und dann die Lösung gefunden.

1. Als erstes den Rechner im abgesicherten Modus booten (Taste F8 vor dem Windows-Start)
2. In der Registry den defekten User unter dem Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList ausfindig machen. Wahrscheinlich ist der Schlüsselname mit der Endung .bak versehen.
3. Den Schlüssel umbenennen, also das .bak aus dem Schlüsselnamen entfernen und den Wert "state" auf "0" setzen.

Wenn ein Benutzerprofil defekt ist aber der Administrator sich noch anmelden kann, so kann dies auch direkt unter dem Administrator gemacht werden und das Booten im abgesicherten Modus kann weggelassen werden.

Nachdem wir ja auch diverse Probleme mit den Web'n'Walk Express Card's hatten, haben wir uns testhalber mal ein paar "T-Mobile web'n'walk Stick IV" bestellt.
"Kleiner" schneidiger USB Stick, bei dem schon mal das Problem der Softwaresuche ein Ende hat. Da die Software auf dem Stick ist, kann so auch mal schnell der UMTS Stick an einen anderen Kollegen gegeben werden und er kann die Software in Ruhe auf der Reise installieren, ohne dazu online sein zu müssen.
Leidig ist nur nach wie vor, dass nach der Installation der Rechner neu gebootet werden muss.
Das Design der Software ist aber ansprechend und im Gegensatz zum Web'n'Walk Manager nicht so überladen. Auch der Empfang scheint besser zu eine als die der Express Cards, die ja PCMCIA Karten sind und eine kleine ausklappbare Antenne haben. Zu dieser Lösung sei gesagt, dass ich nun schon drei Karten hier habe bei den entweder die Antenne abgebrochen ist oder sich nicht mehr einklappen oder ausklappen lässt.

Wir werden jedenfalls nach und nach auf den USB Stick "T-Mobile web'n'walk Stick IV" umsteigen, da dieser eleganter ist und besser funktioniert.

Sobald ich hier irgendwelche Probleme habe werde ich davon berichten.