Zum Inhalt

Mindestanforderungen

Infrastruktur

Konnektivitäts- und Bandbreitenanforderungen

  • Einweg-Latenz (Mund zu Ohr) nicht mehr als 150 ms
  • 100 kbit/s UP/DOWN pro gleichzeitigen Sprachanruf
  • Web-Traffic für die Daktela-Weboberfläche: min. 1 Mbit/s DOWN pro aktiven Agenten. Ein einzeln arbeitender Agent (z. B. im Homeoffice) benötigt eine Verbindung mit mindestens 5 Mbit/s DOWN / 1 Mbit/s UP.
  • Verlust nicht mehr als 1 Prozent bei IP-Vermittlungen, VoIP-Netzwerken
  • Durchschnittlicher Einweg-Jitter mit einem Zielwert von unter 30 ms
  • Optional: Sprachverkehr sollte gemäß der QoS-Baseline und RFC 3246 mit DSCP EF markiert werden
  • Bei Verwendung einer Firewall muss der Kunde diese für den VoIP- und Datenstrom konfigurieren und ändern, um die Kommunikation zwischen der On-Premise-Instanz, ihren Telefonen und der Daktela-Plattform zu ermöglichen
  • SIP-ALG standardmäßig auf LAN-Geräten und der Firewall deaktiviert. Kann in einigen bestimmten Fällen aktiviert werden.
  • Aufgrund ihrer Komplexität bietet Daktela keinen Support für die LAN-Infrastruktur und die Firewalls des Kunden!
  • Professionelle LAN-Netzwerkinfrastruktur auf Basis von mindestens Vollduplex-Switches mit 100 Mbit/s und Verkabelung vom Typ CAT5e oder besser.
  • Das Netzwerk darf auch in Spitzenzeiten nicht mit voller Auslastung laufen. Für den erwarteten Sprachverkehr muss ausreichend Kapazität verfügbar sein. Idealerweise werden die Telefoniedaten getrennt und priorisiert, z. B. über ein VLAN.
  • Für einen hohen Datenaustausch über das lokale Netzwerk werden separate Switches für IP-Telefone und PCs empfohlen.
  • IP-Telefonen muss über einen DHCP-Server eine gültige IP-Konfiguration einschließlich eines für den Sprachverkehr bestimmten Internet-Gateways zugewiesen werden.

Firewall

Kunde verwendet SIP/SIPS/WebRTC-Telefone zur TK-Anlage in der Daktela Cloud

  • etablierte Verbindungen zulassen
  • ausgehend 80/tcp, 443/tcp, 443/udp zur IP-Liste (Web)
  • ausgehend 5060/udp, 5060/tcp, 5061/tcp, 8089/tcp zur IP-Liste (SIP)
  • ausgehend 10000-20000/udp zur IP-Liste (RTP-Stream)

  • eingehend – hängt davon ab, welche Art von NAT vorhanden ist (RTP-Stream)

  • UDP-Verkehr ist nicht bidirektional, daher muss Folgendes sichergestellt werden >> UDP Hole Punching auf FW/Router zulassen

    • RFC5128 3.3
    • Methoden der Übersetzung
    • optional eingehend 10000-20000/udp aus der IP-Liste zulassen (RTP-Stream)
    • ausgehend 990/tcp, 44000-44100/tcp zur IP-Liste (FTPS-Befehls- und Datenkanal)
    • ausgehend 636/tcp (LDAPS) zur IP-Liste – optional aktivieren, je nachdem, ob ein solcher Dienst genutzt wird Kunde verwendet SIP/SIPS/WebRTC-Telefone zur On-Premise-TK-Anlage

  • etablierte Verbindungen zulassen

  • eingehend 22/tcp (ssh) von 82.113.42.139, 95.80.200.192 zur On-Premise-TK-Anlage
  • ausgehend 10051/tcp (zabbix) von der On-Premise-TK-Anlage zu 82.113.42.131
  • ausgehend 80/tcp, 443/tcp, 443/udp zur IP-Liste (Web)
  • ausgehend 5060/udp, 5060/tcp, 5061/tcp, 8089/tcp zur IP-Liste (SIP)
  • eingehend 5060/udp, 5060/tcp, 5061/tcp aus der IP-Liste (SIP)
  • ausgehend 10000-20000/udp zur IP-Liste (RTP-Stream)
  • ausgehend 80/tcp, 443/tcp, 443/udp von der On-Premise-TK-Anlage zu 95.80.209.239 (Dienste – SMS, Social-Integrationen)
  • eingehend 80/tcp, 443/tcp, 443/udp von 95.80.209.239 zur On-Premise-TK-Anlage (Dienst-Callbacks – SMS, Social-Integrationen)

  • eingehend – hängt davon ab, welche Art von NAT vorhanden ist (RTP-Stream)

  • UDP-Verkehr ist nicht bidirektional, daher muss Folgendes sichergestellt werden >> UDP Hole Punching auf FW/Router zulassen

    • RFC5128 3.3
    • Methoden der Übersetzung
    • optional eingehend 10000-20000/udp aus der IP-Liste zulassen (RTP-Stream)
    • ausgehend 990/tcp, 44000-44100/tcp zur IP-Liste (FTPS-Befehls- und Datenkanal)
    • ausgehend 636/tcp (LDAPS) zur IP-Liste – optional aktivieren, je nachdem, ob ein solcher Dienst genutzt wird

IP-Liste

  • DC Prag (LIR): 194.176.107.3/32, 194.176.107.4/32, 194.176.107.5/32, 194.176.107.6/32, 194.176.107.7/32, 194.176.107.12/32, 194.176.107.13/32, 194.176.107.14/32, 95.80.246.230/32
  • DC Prag (Cloudflare): 45.133.137.215/32, 45.133.137.217/32, 45.133.137.219/32, 45.133.137.221/32, 45.133.137.224/32, 45.133.137.225/32, 45.133.137.229/32, 45.133.137.189/32, 45.133.137.179/32
  • DC OVH DE: 51.68.176.67/32, 51.68.176.69/32, 51.68.176.70/32
  • DC OVH UK: 51.89.161.247/32, 51.89.161.243/32, 51.89.161.244/32
  • DC OVH SG: 15.235.157.148/32
  • Daktela Repository: 95.80.209.247 auf Port 443

Info

Sie müssen außerdem die IP-Adresse Ihrer TK-Anlage hinzufügen. Sie erhalten sie über ping -c 1 mypbx.daktela.com und erlauben den gesamten Verkehr von der IP 82.113.42.139/32.

Browser

Mindestanforderungen an den Browser

Daktela unterstützt die neuesten Versionen von Chrome, Firefox, Opera, Safari, Edge.

Mindestanforderungen für Daktela Wallboards

Daktela unterstützt die neuesten Versionen von Chrome, Firefox, Opera, Safari, Edge. Wallboards können auch auf Smart-TVs und LCDs mit den neuesten Versionen der unterstützten Browser laufen.

Hardware und Telefone

Software-IP-Telefone

Warning

Support

Obwohl Daktela V6 mit allen oben genannten SW-Telefonen funktionieren sollte, bietet Daktela nur für das Daktela Software Phone Support.

Hardware-IP-Telefone

Allgemeine Anforderungen

Alle aufgeführten Tischtelefone erfüllen die folgenden Standards:

  • SIP-Protokoll-konform (RFC-Standard)
  • Kompatibel mit Asterisk-basierten Systemen (z. B. Daktela)
  • Unterstützen den Codec G.711 A-law und SIP über UDP (bevorzugt), TCP und TLS
  • TLS 1.2+ unterstützt; TLS 1.3 auf den meisten modernen Modellen
  • Aktiv vom Hersteller unterstützt (nicht End-of-Life oder End-of-Support) Unterstützte SIP-Tischtelefone nach Hersteller Yealink
T4U-Serie: T5W-Serie: DECT-Modelle:
SIP-T43U SIP-T53W W73P
SIP-T44U SIP-T54W W78P
SIP-T46U SIP-T57W
SIP-T48U

Poly

CCX-Serie: Hinweis:
CCX 400 Die VVX-Serie ist End-of-Life und sollte nicht eingesetzt werden.
CCX 500
CCX 600

Cisco

Unterstützte Modelle: Hinweis:
8811 (MPP) Wichtig: MPP-Firmware erforderlich. Nur Geräte mit Cisco Multiplatform Firmware (MPP) werden unterstützt. Enterprise-Firmware ist mit SIP/Asterisk-Umgebungen nicht kompatibel.
8841 (MPP)
8851 (MPP)
8861 (MPP)
8865 (MPP)
Snom

| D7xx-Serie: | | --- | | D715 | | D717 | | D725N | | D735 | Grandstream

GRP-Serie: GXP21xx-Serie:
GRP2612 GXP2130 v2/v3
GRP2613 GXP2140
GRP2614 GXP2160
GRP2615 GXP2170
GRP2616
iPECS (Ericsson-LG)
Unterstützte Modelle: Hinweis:
LIP-9071 Ältere Modelle LIP-8800/9800 nicht einbeziehen.
LIP-9040
LIP-9030
Microsoft-Teams-Kompatibilität über SIP-Gateway
Microsoft Teams unterstützt SIP-Geräte nicht nativ. Microsoft bietet jedoch ein SIP-Gateway an, um ausgewählte zertifizierte SIP-Telefone für grundlegende Anruffunktionen mit Teams zu verbinden.
Anforderungen:
  • Das Gerät muss auf der Liste der zertifizierten Geräte stehen (Yealink, Poly, Cisco)
  • Muss TLS/SRTP unterstützen und zugelassene Firmware ausführen
  • Erfordert eine Microsoft-365-Lizenz (z. B. E1/E3/E5)

  • Das Provisioning umfasst die Konfiguration zu sip.pstnhub.microsoft.com und die Teams-Anmeldung Unterstützte Beispiele:

  • Yealink:

  • T56A, T58A

  • MP54, MP56, MP58

  • Poly:

  • CCX 400, 500, 600

  • Trio C60

  • Cisco:

  • 8845, 8865 (nur Teams-zertifizierte Firmware) Hinweise:

  • Das Teams SIP-Gateway bietet nur grundlegende Anruffunktionen (kein Kalender, kein Video, keine Verzeichnissynchronisierung)

  • Geeignet für Hybrid-Bereitstellungen während des Übergangs zu Microsoft Teams Abschließende Empfehlungen Für eine zuverlässige und zukunftssichere Bereitstellung:

  • Erste Wahl: Yealink T4U- und T5W-Serie

  • Teams-fähige Optionen: Poly CCX-Serie, Cisco 8800 MPP, Yealink MP-Serie
  • Sicher und flexibel: Snom D7xx, Grandstream GRP/GXP21xx
  • Hybride UC-Unterstützung: Ausgewählte zertifizierte Modelle über das Microsoft SIP-Gateway

Mindestanforderungen an den Computer

  • PC mit CPU min. 2,0 GHz (4+ Kerne), min. 16 GB RAM, Audio-Ein-/Ausgang
  • MacBook mit min. 16 GB RAM

E-Mails und Tickets

Anforderungen zum Senden und Empfangen von E-Mails über den Daktela-Helpdesk

  • Daktela muss der einzige Mail-Client sein, der das Postfach nutzt.
  • Der Kunde muss sich der Menge der gesendeten E-Mails bewusst sein, um Sperrungen usw. zu vermeiden.

  • Der Kunde muss Folgendes bereitstellen:

  • Zugang zum eingehenden und ausgehenden Mailserver.

  • alle weiteren erforderlichen Parameter.
  • die maximale Anzahl an Titelzeichen beträgt 128.

Warning

Für Kunden, die den Daktela-Helpdesk nutzen, empfehlen wir, die Konfigurationen für DKIM (DomainKeys Identified Mail) und DMARC (Domain-based Message Authentication, Reporting, and Conformance) auf Ihrem Mailserver zu überprüfen. Diese Einstellungen beziehen sich ausschließlich auf Ihren Mailserver und sind unabhängig von unserem Helpdesk-System. Fehlerhafte oder fehlende Konfigurationen können Ihre E-Mails jedoch als verdächtig markieren. Um solche Probleme zu beheben, empfehlen wir, sich an dieser Anleitung zu orientieren: DKIM wird konfiguriert:

  • Auf dem Mailserver (z. B. Exchange, Postfix, Gmail usw.).

  • Im DNS der Domain wird ein TXT-Eintrag erstellt, der den öffentlichen Schlüssel enthält (z. B. default._domainkey.yourdomain.com). DMARC wird konfiguriert:

  • Im DNS der Domain wird ein TXT-Eintrag erstellt (z. B. _dmarc.yourdomain.com).

  • Dieser Eintrag enthält Regeln, etwa die Strenge der SPF/DKIM-Prüfungen und wohin Berichte gesendet werden sollen (z. B. v=DMARC1; p=quarantine; rua=mailto:report@yourdomain.com). Wo und wie werden diese Einstellungen konfiguriert?

  • DNS-Einträge:

  • Melden Sie sich bei der Oberfläche Ihres DNS-Anbieters an (z. B. Wedos, Cloudflare oder Ihres Domain-Anbieters).

  • Fügen Sie die erforderlichen TXT-Einträge hinzu:

    • DKIM: Enthält den öffentlichen Schlüssel.
    • DMARC: Enthält die Regeln.

  • Mailserver:

  • Stellen Sie sicher, dass Ihr Mailserver DKIM unterstützt (z. B. werden in Exchange Schlüssel generiert und der DNS-Eintrag konfiguriert).

  • Implementieren Sie SPF, falls noch nicht konfiguriert (SPF ist ein weiterer Schutzmechanismus zur Überprüfung der Absender-IP-Adressen).

  • Testen:

  • Testen Sie mit Online-Tools wie Mail-tester oder MXToolbox.

SSL-Zertifikate

Beim Erstellen von SSL-Zertifikaten gibt es im Allgemeinen 3 Schritte:

  1. Erstellen Sie einen privaten RSA- (2048–4096 Bit) oder ECDSA-Schlüssel (256–384 Bit).
  2. Generieren Sie einen Certificate Signing Request (CSR).

  3. Lassen Sie den CSR von einer Zertifizierungsstelle signieren, um ein SSL-Zertifikat zu erstellen. Kunden können den gesamten Prozess selbst durchführen oder Daktela um Unterstützung bei einem der obigen Schritte bitten (kostenpflichtiger Service) – in diesem Fall muss der Kunde Folgendes angeben:

  4. Domain

  5. Firmenname und -adresse

  6. Bestätigungs-E-Mail-Adresse Wenn Kunden Daktela ihre eigenen Zertifikate bereitstellen:

  7. Der bereitgestellte private Schlüssel darf nicht passwortgeschützt sein, oder das Passwort muss angegeben werden, falls er es ist.

  8. Das Format muss PEM sein (PFX und DER werden ebenfalls akzeptiert).
  9. Sie müssen die Intermediate-CA-Kette der Zertifizierungsstelle bereitstellen.