Büromitarbeiterin im HomeOffice auf 450€ Basis gesucht

Die cubewerk GmbH bietet seit 2005 IT- und Kommunikationslösungen für Unternehmen mit hohen Anforderungen an die Sicherheit und Zuverlässigkeit. In den Kernbereichen IT-Support, IT-Beratung und IT-Sicherheit versorgen wir Sie mit wirtschaftlichen und etablierten Lösungen.

Wir suchen ab sofort – Büromitarbeiterin auf 450€ Basis
(2 Tage/Woche a 5 1/2 Stunden) im HomeOffice

Ihre Aufgaben:

Bestandsdatenpflege unserer Kunden/Partner/Lieferanten im CRM-System
Regelmäßiger vertrieblicher telefonischer Kontakt zu Kunden/Partnern
Erstellung der Monatsrechnungen
Ablage von aus- und eingehenden Dokumenten/Rechnungen/Belegen im DMS-System
Annahme von Telefonaten und Weiterleitung von Anfragen an Ticket-System
Planung/Organisation von Veranstaltungen mit Partnern/Kunden
(IT-Stammtische, Workshops, Produktvorstellungen, Schulungen, Sommerfest)

Was wir erwarten:

Wohnort im Umkreis von 20km von Trostberg (da Einarbeitung in Trostberg, 2-3 mal jährlich interne Veranstaltung in Trostberg)
Einwandfreies Deutsch in Wort und Schrift
Sicher im Umgang mit dem PC (Office-Umgebung, Recherche im Internet, Preisvergleiche, Adresssuchen)
Interesse an der IT-Branche / keine Abneigung, das eigene Wissen zu erweitern

Wie bewerben?

Ausschließlich per E-Mail an vertrieb@cubewerk.de

Asterisk registertimeout und Anpassung bei mehreren Peers

Grundlagen:

Man nehme eine Asterisk TK-Anlage hinter einer FritzBox. Alle 90 Sekunden registriert sich in der Regel die Anlage beim Provider (z.B. Easybell).

Ist dies dem Anbieter zu häufig, antwortet er auf die Registrierung mit einem

Contact: <sip:nummer@IP:5060>;expires=600

expires=600 ist eine Aufforderung an den Client, zukünftig nur alle 600 Sekunden eine neue Registrierung anzustoßen.

Das tritt auch auf, wenn man z.B. mehrere Rufnummern in Askozia einzeln beim Provider registriert. Das führt dann zu zu häufigen Registrierungen.

Die Probleme:

Damit der Anbieter eingehende Anrufe an die Asterisk signalisieren kann, besteht eine mehr oder weniger dauerhafte Verbindung zwischen Asterisk und dem Provider.  Firewalls vor der Asterisk benötigen regelmäßigen Verkehr, damit die Verbindung auch in der Firewall dauerhaft aufrecht erhalten bleibt.

Wie sieht das konkret aus:

12:16:03.692450 IP askoziapbx.local.5060 > 195.185.37.60.5060: SIP: REGISTER sip:sip.easybell.de SIP/2.0
12:16:03.727299 IP 195.185.37.60.5060 > askoziapbx.local.5060: SIP: SIP/2.0 401 Unauthorized
12:16:03.728225 IP askoziapbx.local.5060 > 195.185.37.60.5060: SIP: REGISTER sip:sip.easybell.de SIP/2.0
12:16:03.771253 IP 195.185.37.60.5060 > askoziapbx.local.5060: SIP: SIP/2.0 200 OK

Nach diesen 4 Paketen ist die Nummer registriert und es besteht eine zeitlich beschränkte Verbindung zwischen Asterisk und Anbieter.

Bug/Problem 1:

Das Easybell-Providertemplate von Askozia (ist Asterisk) nutzt Port 5064 als Port zu Registrierung. Dieser Port wird jedoch im ausgehenden REGISTER ignoriert. Dies scheint ein bekannter Asterisk-Bug zu sein. In obigem TCPDUMP wird 5060 statt 5064 verwendet.

Dies alleine wäre noch nicht so fatal – die Nummer ist ja registriert.

Da jedoch Firewalls nicht jede Verbindung dauerhaft offen halten (FritzBox¹ z.B. max 5 Minuten für UDP-Verbindungen), muss innerhalb von 5 Minuten mindestens einmal Verkehr zum Provider stattfinden, damit die Verbindung dauerhaft besteht und eingehende Anrufe signalisiert werden können.

Entweder man registriert die Rufnummer in einem kurzen Intervall (< 5 Minuten) ständig neu, oder man nutzt Keep-Alive (Ping-Pong) Pakete zwischen Provider und Asterisk.

Diese Pakete sehen wie folgt aus:

12:15:44.082202 IP askoziapbx.local.5060 > 195.185.37.60.5064: SIP: OPTIONS sip:sip.easybell.de SIP/2.0
12:15:44.112037 IP 195.185.37.60.5064 > askoziapbx.local.5060: SIP: SIP/2.0 200 Alive

Problem 2:

Diese Pakete sind jedoch wertlos für die eigentliche Anrufsignalisierung des Providers, da hier die Ports anders sind. Hier verwendet Asterisk den korrekten Port 5064.

Durch obige Keep-Alive-Pakete hat die Firewall in ihrer NAT-Tabelle einen Eintrag in der Form:

askoziapbx.local.5060 > 195.185.37.60.5064

Antworten (genau andersrum) von

195.185.37.60.5064 > askoziapbx.local.5060

werden automatisch weitergeleitet und können einer Verbindung zugeordnet werden.

Eingehende Anrufe werden jedoch vom Anbieter in folgender Form signalisiert:

11:57:14.713468 IP 195.185.37.60.5060 > askoziapbx.local.5060: SIP: INVITE sip:zielnummer@öffentliche-IP:5060 SIP/2.0

Man beachte die Ports. Diese passen nicht zur obigen erwarteten Verbindung Provider:5060 an eigene-IP:5060 und werden deshalb verworfen.

Lösung(en)?

Bug in Asterisk fixen (lassen). Ticket bei Askozia ist offen seit Juni 2017. Alterantiv den Standardport 5060 im Providertemplate nutzen, damit OPTIONS- und REGISTER-Ports zusammen passen.

UDP-Timeout in Firewall erhöhen auf > Registrierdauer bei Provider

Mit Netcat ständig Verbindung zwischen Anlage & Provider aufrecht erhalten

Verkehr generieren, der die UDP-Verbindung in FW aufrecht erhält.

Grausiger Workaround – Dummy-Sip-Nummer in FritzBox registrieren – das hat dazu geführt, dass der Port 5060 irgendwie offen bleibt für Geräte dahinter. Jedoch nur bis zu einer bestimmten Anzahl von SIP-Nummern. Eigentlich keine Lösung.

¹ https://avm.de/service/fritzbox/fritzbox-7360-sl/wissensdatenbank/publication/show/907_Anwendung-z-B-SSH-verliert-gelegentlich-die-Verbindung-zu-Gegenstellen-im-Internet/

Askozia Fritzbox und Easybell – eine unglückliche Verkettung

Bei einigen Installationen ist uns aufgefallen, dass eingehenden Anrufe gelegentlich nicht durch die FritzBox weitergeleitet werden an die TK-Anlage dahinter. Nach etwas Diagnose sahen wir in der FritzBox folgendes Paket:

Destination unreachable: Administratively prohibited

Nach längerer Suche war uns klar, die FritzBox blockiert zurecht, da der Provider auf Port 5060 signalisiert – hier läuft jedoch die Telefonie der FritzBox. Laut Easybell besteht auch ein alternativer Port 5064.

In Askozia ist dieser Port jedoch hinterlegt – ausgehende REGISTER Pakete verwenden jedoch Port 5060. Klarer Bug in der Uraltversion von Asterisk in Askozia. Aktuell heißt es auf ein Bugfix zu warten.

Komischerweise haben die OPTIONS-Pakete den richtigen Port 5064.

Kopano mit Outlook – Stand Juni 2017

Wir sind ja Kopano Partner und von der Lösung überzeugt – verwenden sie auch selbst. Es hat sich einiges die letzten Wochen/Monate im Hause Kopano getan.

Wie ist der Stand Juni 2017?

Die Outlookanbindung an Kopano geht aktuell mit Outlook 2013/2016 reibungslose über ActiveSync. Menügeführte Installation über die Outlook GUI ohne Drittsoftware.

Möchte man jedoch zusätzliche Features wie fremde Kalender öffnen, benötigt man die KOE – ein kleines Plugin um das ActiveSync Protokoll aufzubohren.

Den alten MAPI-Client (zarafa mapi) sollte man nicht mehr verwenden – hat dieser doch seit dem letzten Microsoft-Update das Problem, die „Alle Antworten“ Funktion bereitzustellen.

Nachteile der ActiveSync-Anbindung?

Wer es gewohnt ist, in Outlook seine Elemente farblich mit Fahnen zu markieren wird feststellen ,dass nur noch die Farbe rot zur Verfügung steht.

Auch die Verfolgung von Elemente (Erinnerung auf E-Mails z.B) steht (noch) nicht wieder zur Verfügung. Für viele ein unbekanntes Feature – für einige jedoch „lebensnotwendig“ :)

Dies und das:

Klare Ausrichtung von Kopano geht in Richtung DeskApp und WebApp. Die DeskApp ist mit aktueller Stable Version 1.3 mehr als nur ein Browser in the Box. Setzen als Standardmailclient, Direkter FS-Zugriff und Provisionierungsfunktionen machen die Arbeit des Admins einfacher.

Leider gibt es auch noch einige Bugs. Das seit Monaten oder fast Jahren angekündigte/gelobte S/MIME Plugin funktioniert zwar, aber nicht mit Outlook-Absendern.

Das Kopano Files Plugin – kann im Jahr 2017 keine Umlaute in Datei- und Ordnernamen.

WebMeeting funktioniert hervorragend. Jedoch nur mit einem funktionierenden Turn-Server um die nötigen Ports für Sprach- und Video einfach durch eine FW zu bekommen. Empfehlung ist Coturn-Turnserver oder den Kopano Turnserver, der gehostet wird und frei verwendbar ist mit gültiger Lizenz.

Heute am 30. Juni hat man sich entschieden, Mattermost – eine Chat-Umgebung in die DeskApp zu integrieren. Wieso WebMeeting dafür nicht taugt, ist mir unklar – dort gibt es ebenso eine Chatfunktion.

IT-Awareness in der Praxis – Infoveranstaltung am 28.06.2017

IT-Awareness in der Praxis

– Wie schützen Sie sich vor Cyberangriffen –
Infoveranstaltung am 28.06.2017

Sehr geehrte Damen und Herren,

Verschlüsselungstrojaner, Datendiebstahl, Hackerangriffe und Spionage sind Themen, auf die ein Unternehmer die richtigen Antworten parat haben sollte. Was es für Angriffsmöglichkeiten gibt, wie Hacker vorgehen, wie Abwehrmaßnahmen aussehen und eine Schadensbegrenzung möglich ist, erfahren Sie in der Informationsveranstaltung

am Mittwoch, den 28.06.2017 um 18.30 Uhr
im Seminargebäude der VHS-Traunreut,
Marienstraße 22, 83301 Traunreut.

Ablauf:

Begrüßung
Karola Drenth, Geschäftsführerin VHS-Traunreut

Angriffe auf heimische Unternehmen – wie arbeiten Hacker?
Kriminalhauptkommissar Witgar Neumaier, Leiter Abteilung Cybercrime, Kriminalpolizeiinspektion Rosenheim

Technische Abwehrmaßnahmen für Unternehmen
Stefan Bauer, Geschäftsführer cubewerk GmbH, Trostberg

Versicherungsrechtliche Möglichkeiten zur Schadensbegrenzung
Dipl.-Wi.-Ing Martin Hohlweger, Versicherungsbüro Hohlweger, Traunreut

Fragen an die Experten

Die Teilnehmerzahl ist begrenzt. Wir bitten Sie um Ihre verbindliche Anmeldung bis 25.06.2017
per E-Mail an events@cubewerk.de

Wir freuen uns auf Ihr Kommen!

Mit freundlichen Grüßen

Stefan Bauer

Dies ist eine Gemeinschaftsveranstaltung des Treffpunkt Trostberg e. V. sowie der cubewerk GmbH.

Breitband ante portas – Das Ende von ISDN ist nah

Sehr geehrte Damen und Herren,

die ISDN-Technik ist durch alle Provider langfristig abgekündigt und das gesteckte Ziel 2018 für
die Abschaltung rückt näher. Wie sich die Telefonie und Kommunikation in Unternehmen verän-
dert, was der Breitbandmarkt für Lösungen bietet, wie ein Technologiewechsel für ein Unterneh-
men konkret aussehen kann und welche Chancen und Fallstricke die Umstellung bietet, möchten
wir Ihnen gerne näher erläutern.

Wir möchten Sie herzlich

am Donnerstag, den 29.06.2017 um 18.30 Uhr
im Gasthof Pfaubräu,
Vormarkt 2, 83308 Trostberg

zu einer Informationsveranstaltung einladen.

Ablauf:

Begrüßung
Bürgermeister Karl Schleid
Dr. Birgit Seeholzer, Geschäftsführerin Wirtschaftsförderungs GmbH

Chancen und Risiken der IP-Telefonie – was ist zu tun?
Stefan Bauer, Geschäftsführer, cubewerk GmbH, Trostberg

Von Schmalband zu Breitband
Stefan Bratzdrum, Geschäftsführer, Stadtwerke Trostberg GmbH

Wechsel auf IP-Telefonie in der Praxis
Melanie Laufke, Leitung IT, Architekturbüro Zeller & Romstätter, Traunstein

Fragen an die Experten

Die Teilnehmerzahl ist begrenzt. Wir bitten Sie um Ihre verbindliche Anmeldung bis 26.06.2017
mit beiliegendem Antwortfax oder per E-Mail an marianne.graspointner@traunstein.bayern

Wir freuen uns auf Ihr Kommen!

Mit besten Grüßen

Stefan Bauer
1. Vorstand

Treffpunkt Trostberg e. V.

Herzog-Otto-Str. 32
83308 Trostberg
Tel: 08621-9024033

ipfire nat problem mit sip Verkehr

Mit ipfire core Version 100 bis zur aktuellen 110 haben wir das Phänomen, dass eingehende SIP INVITES von der FW blockiert wurden, obwohl es einen ständigen Ping Pong gibt zwischen TK-Anlage dahinter und Provider in der Form:

IP 192.168.2.251.5060 > 195.185.37.60.5064: SIP: OPTIONS sip:sip.easybell.de SIP/2.0
IP 195.185.37.60.5064 > 192.168.2.251.5060: SIP: SIP/2.0 200 Alive

Kommt jetzt jedoch ein Anruf rein, wird dieser durch die ipfire FW blockiert:

06:06:08.098003 IP 195.185.37.60.5060 > 192.168.2.251.5060: SIP: INVITE sip:zielnummer@öffentliche-IP:5060 SIP/2.0
May 17 06:06:23 ipfire kernel: DROP_FORWARD IN=red0 OUT=green0 MAC=BEKANNT SRC=195.185.37.60 DST=192.168.2.251 LEN=764 TOS=0x00 PREC=0x00 TTL=57 ID=63961 DF PROTO=UDP SPT=5060 DPT=5060 LEN=744

Wir haben uns jetzt mit einer FW-Regel beholfen, die eingehend obigen Block ausnimmt. Da wir davor noch eine weitere FW besitzen, die korrekt nattet, sehen wir hier kein Sicherheitsproblem. Die FW davor hat korrekt erkannt, dass dies Teil einer bestehenden Verbindung ist.

Ubiquity Unify AP – Controller umziehen auf neuen Server

Möchte man den installierten Controller von einem Server auf einen neuen Server mit selber IP umziehen, reicht es, über die Oberfläche Settings – > Maintenance ein Backup zu ziehen und dies im neuen einzuspielen.

Hat der neue Server jedoch eine neue IP, ist es nötig, die AccessPoints zurückzusetzen. Am Einfachsten geht das über den noch aktiven alten Kontroller. AP auswählen und Forget auswählen. Dadurch wird der AP in den Auslieferungszustand versetzt und kann jetzt vom neuen Kontroller adoptiert werden.