Technische Voraussetzungen für unsere Cloudtelefonie

Unsere Telefonanlage basiert auf STARFACE und wird in unserem eigenen Rechenzentrum betrieben. Damit Tischtelefone, DECT-Systeme und STARFACE Apps zuverlässig funktionieren, müssen die folgenden Anforderungen im Kundennetz erfüllt sein.

A

Darum kümmert sich Ihr EDV-Betreuer

Am besten nehmen Sie Ihren Ansprechpartner für IT direkt mit ins Boot und leiten ihm diese Seite weiter.

1. Kompatible Endgeräte

Empfohlene Tisch-, Konferenz- und Spezialtelefone

Die folgenden Modelle werden unterstützt und unterstützen gleichzeitig auch verschlüsselte Telefonie:

  • Gigaset: P810 IP Pro, P810B IP Pro, P820 IP PRO, P825 IP PRO, P850W IP PRO, P855BW IP PRO
  • snom: D715, D717, D735, D785, D810W, D812, D815W, D815WB, D862, D865, D385
  • Yealink: CP925, CP965, T31, T46U, T53W, T54W, T57W, T58W, T73U, T73W, T74U, T74W, T85W, T87W, VP59

Empfohlene DECT-Systeme

Cloud-fähige, verschlüsselte Basisstationen:

  • Gigaset PRO: N610 PRO, N670 PRO, N870 PRO
  • snom: M400, M900
  • Yealink: W70B, W75 Mini MC

Aktuelle Mobilteile:

  • Gigaset PRO: SL800H, S700H, R700H
  • snom: M25, M65, M70, M80, M85, M90
  • Yealink: W73H, W74H, W78H, W59R Pro

Analoge Adapter und Gateways

  • Grandstream HT802, HT812 und HT814: aktuell, ausschließlich für Faxbetrieb vorgesehen; nicht für Türsprechstellen, Alarmanlagen, Modems oder Aufzüge.

Der Einsatz weiterer Modelle muss vorab projektbezogen abgestimmt werden.

2. Firewall- und Portfreigaben

Grundsatz für das Kundennetz

Die Endgeräte und Apps bauen die Verbindungen zur Telefonanlage in der Cloud auf. Deshalb ist am Kundenstandort normalerweise keine Portweiterleitung vom Internet in das lokale Netz erforderlich. Freizugeben sind ausgehende Verbindungen von den Telefon- und Client-Geräten/Netzen zum bereitgestellten Telefonanlagen-Ziel zugehöriger Rückverkehr muss ebenfalls zugelassen werden.

Hardwaretelefone und DECT-Basisstationen

Zweck Protokoll / Port Erforderlichkeit Hinweis
SIP-Signalisierung UDP/TCP 5060 je nach Konfiguration Unverschlüsselte Signalisierung; nur verwenden, wenn erforderlich.
SIP über TLS TCP 5061 bevorzugt Verschlüsselte Signalisierung für kompatible Geräte. UDP 5061 nur freigeben, wenn das konkrete Gerät dies verlangt.
RTP-Audio UDP 10000–20000 und UDP 1025–65535 erforderlich Gemäß STARFACE-Portübersicht zwischen Endgerät und STARFACE; auf STARFACE-Ziel und Telefonnetz begrenzen.
Provisionierung / Telefonmenü TCP 50080 modellabhängig Für manuelle bzw. One-Touch-Provisionierung und Telefonmenüs.
Verschlüsselte Provisionierung TCP 50081 modellabhängig Nur für Geräte und Verfahren, die diesen Port verwenden.
DNS UDP/TCP 53 erforderlich Üblicherweise zum lokalen DNS-Resolver.
Zeitabgleich UDP 123 empfohlen Üblicherweise zum lokalen NTP-Dienst.

STARFACE Desktop- und Mobile-Apps

Zweck Protokoll / Port Erforderlichkeit Hinweis
Grundfunktionen / Adressbuch TCP 443 erforderlich HTTPS zur STARFACE.
SIP UDP 5060 konfigurationsabhängig Entfällt bei ausschließlicher Nutzung von SIP über TLS.
SIP über TLS TCP 5061 bevorzugt Verschlüsselte Signalisierung.
XMPP-Anmeldung TCP 5222 erforderlich Anmeldung und Präsenzfunktionen.
gRPC-Anmeldung TCP 9092 ab STARFACE 10 erforderlich Für die Anmeldung aktueller Apps.
RTP-Audio UDP 10000–20000 und UDP 1025–65535 erforderlich Gemäß STARFACE-Portübersicht bidirektional.
RTSP-Kamera UDP 554 / TCP 8554 optional Nur für Kamerastreams in der Windows-App.

Zusätzlich müssen für Updates beziehungsweise mobile Push-Funktionen folgende Ziele über HTTPS erreichbar sein:

  • www.starface-cdn.de
  • push-cluster.starface.de

Herstellerdienste für Zero-Touch-Provisionierung können weitere Ziele benötigen. Diese werden nur für die tatsächlich eingesetzten Modelle freigegeben. Für Yealink nennt STARFACE unter anderem dm.yealink.com, api-dm.yealink.com, rps.yealink.com, rpscloud.yealink.com und pscloud.yealink.com sowie zusätzliche herstellerspezifische Ports.

3. Erforderliche Router-, NAT- und Firewall-Einstellungen

STARFACE nennt für Endgeräte hinter NAT folgende Werte:

Einstellung Sollwert
TCP Aging 600 Sekunden
UDP Aging / UDP-NAT Timeout / Connection Tracking 600 Sekunden
Bestandsdauer eines UDP-Eintrags in der NAT-Tabelle mindestens 61 Minuten

Autoprovisionierte Telefone senden standardmäßig alle 60 Sekunden Keep-alive-Pakete und registrieren sich etwa alle 60 Minuten neu. Zu kurze NAT-Laufzeiten führen typischerweise dazu, dass Telefone nach einiger Zeit nicht mehr erreichbar sind.

Folgende Funktionen sind für den Verkehr zur Telefonanlage zu deaktivieren oder durch eine gezielte Ausnahme zu umgehen:

  • SIP ALG
  • SIP Inspection
  • H.323 Helper
  • VoIP-bezogene UTM-/Application-Inspection
  • TLS-/HTTPS-Inspection für STARFACE- und Provisionierungsziele

Bei mehreren Internetzugängen muss Telefonieverkehr während einer Sitzung immer denselben WAN-Pfad verwenden. Lastverteilung, asymmetrisches Routing oder ein Wechsel der öffentlichen Absender-IP während einer Sitzung kann Registrierung und Sprachübertragung unterbrechen.

4. Weitere empfohlene Netzwerkeinstellungen

  • QoS: RTP-Sprachverkehr an tatsächlichen Engpässen priorisieren. SIP-Signalisierung ebenfalls priorisieren, aber unterhalb des Sprachverkehrs.
  • Bandbreite: Die Kapazität nach der maximalen Zahl gleichzeitiger Gespräche planen. G.711 kann laut STARFACE bis zu rund 84 kbit/s pro Gespräch benötigen; als Planungswert sollten einschließlich Reserve mindestens 100 kbit/s je Richtung und gleichzeitigem Gespräch vorgesehen werden.
  • DNS und Zertifikate: Den bereitgestellten FQDN verwenden, nicht dauerhaft eine einzelne IP-Adresse in den Endgeräten hinterlegen. DNS-Auflösung muss aus allen Telefon- und Client-Netzen funktionieren.
  • Verkabelung und WLAN: Stationäre Telefone nach Möglichkeit kabelgebunden betreiben. Bei WLAN-Telefonen Abdeckung, Roaming, Auslastung und priorisierte Übertragung vor der Inbetriebnahme prüfen.
  • Keine unnötigen Proxys: SIP und RTP nicht über Web-Proxys führen. HTTPS-Zugriffe der Apps und Provisionierung nicht durch Inhaltsfilter verändern.

Fragen? Dann rufen Sie uns an!

0 29 41 – 27 26 30