3cx Kennwort auslesen für Verwaltungskonsole
Eintrag folgt nach Verifizierung. Bitte kurz durchklingeln bei uns telefonisch. Passwort kann in wenigen Minuten zurückgesetzt werden.
3cx – Telefone werden dauerhaft als online (grün) angezeigt
3CX macht hier alles richtig – Grandstream nicht so ganz mit der Default-Einstellung in meinen Augen. Schaltet man sein Telefon abends wie üblich einfach aus, bleibt die Nebenstelle in 3CX dauerhaft grün/online. Warum?
Weil die Grandstream-Telefone standardmäßig im REGISTER-Paket das Expires: auf ‚0‘ setzen.
Schnell im Telefone geändert auf einen sinnvollen Wert und schon wird die Nebenstelle nach Ablauf der Zeit als offline/rot markiert. So sieht das in den Einstellungen von Grandstream aus:
Zusätzlich gibt es noch eine Unregister-Funktion im SIP-Protokoll. Damit kann sich z.B. ein Softclient „sauber“ direkt abmelden ohne auf den Ablauf von Timern zu warten.
3cx Anklopfen aktivieren für Signalisierungsgruppe
Einerseits muss im Telefon Call Waiting / Anklopfen usw. aktiviert sein. Exemplarisch ein Bild von einem Grandstream Telefon (schlechte Übersetzung):
Zusätzlich muss in der 3CX konfiguriert werden, dass sich die Anlage nicht auf den 3CX-Status eines Telefons verlassen soll (also belegt oder frei) sondern auf den Status des Telefons.
Umstieg von Askozia auf 3CX – Lizenzen und Preise
Für Umsteiger von Askozia auf 3CX stellt sich die Frage nach der Lizenzierung. Besitzer einer gültigen Askozia Lizenz erhalten kostenlos eine 8 Kanal Professional Lizenz von 3CX ohne zeitliche Begrenzung.
Sprechen Sie uns an! Was tun bei mehr als 8 benötigten Kanälen? Hierzu gibt es Upgrade-Pakete zur Erweiterung der Kanäle. Alle Preise und Upgrade-Möglichkeiten finden Sie in unserer Preisübersicht.
Askozia wird 3CX – das Ende von Askozia – 3CX übernimmt Askozia
Heute wurden die Askozia Partner informiert, dass Askozia mit 3CX fusioniert und das Produkt „Askozia“ stirbt. Partner werden animiert, zukünftig 3CX zu vermarkten. Ab sofort sind keine Askozia Produkte mehr erhältlich.
Zum 31.12.2017 wird der offizielle Askozia-Support eingestellt.
Die cubewerk GmbH setzt an dieser Stelle zukünftig auf die Bereitstellung von 3CX Telefonanlagen. Falls bei Ihnen noch eine Askozia TK-Anlage im Einsatz ist, beraten wir Sie gerne zum Umstieg und übernehmen die Migration der Anlage. Bitte Beachten Sie unsere weitere Seite zum Thema 3CX Versionen und Migrationswege für Askozia.
Gründe für die Portierungsablehnung bei Rufnummernportierung
Für jeden Dienstleister oder Anbieter von Telefonielösungen ist die Portierung von Rufnummern von Fremdanbietern ein wichtiger Baustein des Serviceangebotes. Wer will schon auf seine Nummern verzichten beim Wechsel.
Durch die enorme Anzahl unterschiedlicher Anbieter, nicht kompatibler Portierungssysteme und dem Faktor Mensch, hat sich die Bundesnetzagentur als hoheitliche Instanz ein Konzept überlegt, wie der Portierungsprozess ablaufen kann und auch muss.
Hierzu gibt es das Dokument Spezifikation Version 3.0 Ablauf bei der Vorabstimmung (Stand 2012), was die wesentliche Portierung beschreibt.
Wichtig bei der Rufnummernportierung sind häufig die Ablehnungsgründe – also was habe ich falsch ausgefüllt bzw. was fehlt. Hierzu gibt es folgende standardisierte Gründe für die Ablehnung:
RNG = Rufnummer nicht geschaltet (Hinweis: Sofern EKPauf mind. Eine
richtige Rufnummer in der Vorabstimmungsanfrage angegeben
hat, nennt EKPabg in der Ablehnung alle bei EKPabg
bereitgestellten Rufnummern des Kunden. Nennt EKPabg keine
richtige Rufnummer, erfolgt nur die Ablehnung ohne Angabe der
Rufnummern).
ADF = Adresse falsch (je falschem Adresselement ein Code)
AIF = Anschlussinhaber falsch (ist nur der Vorname falsch, erfolgt AIF mit
Zusatz „Vorname falsch“)
WAI = Weitere Anschlussinhaber
KNI = Kunde nicht identifizierbar (anzuwenden, wenn gar keine
Identifizierung eines Kunden anhand eines Merkmals möglich ist)
VAE = Vorabstimmung anderer EKP liegt vor
SON = Sonstiges (immer mit Begründung im Freitext)
Quelle: Bundesnetzagentur
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.
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.